Я установил политику безопасности Google Cloud Armor со ссылкой на https://cloud.google.com/armor/docs/rules-language-reference. Работало нормально. Была обнаружена моя имитированная SQL инъекционная атака из моего офиса, и последующий доступ был заблокирован. Запись в журнале Stackdriver показывает соответствующий результат принудительного примененияSecurityPolicy «deny» и примененный идентификатор выражения был «ow asp -crs-v030001-id942421-sqli». Ключевое правило WAF выглядит следующим образом:
valuPreconfiguredExpr ('xss-stable') &&valuPreconfiguredExpr ('sqli-stable')
Одна точка, которой я не могу управлять. После моей симулированной атаки все доступы из моего офиса все время блокировались. После отсоединения и повторного присоединения политики безопасности Cloud Armor к LB доступ из моего офиса по-прежнему блокируется. Удаление этой политики безопасности и ее повторное создание не помогает. Это означает, что существует невидимая постоянная база данных о злоумышленниках SQLi & XSS, и в ней может быть зарегистрирован IP моего офиса, что приводит к постоянному отказу.
Вопрос: как я могу удалить свой IP из та невидимая база данных «черного списка SQLi & XSS» для восстановления доступа к бэкэнду без изменения правил? В нашей производственной операции Cloud Armor однажды запрещенный IP-адрес может захотеть восстановить доступ к целевой бэкэнд-службе после удаления источника атаки.
Конечно, если я добавлю правило разрешения с более высоким приоритетом, чем правило WAF, я могу восстановить доступ к целевому бэкэнду, но проверка WAF будет обойдена, а это не то, чего я хочу.
Заранее спасибо за ваше время.
R.Kurishima