Защита веб-точки входа с AWS WAF

Введение

Веб-приложение должно блокировать внутренний путь экспорта, сохраняя доступность проверки состояния. Вы подключите правило пути, проверите, достигают ли запросы бэкенда, и обновите правило перед очисткой.

Сначала выполните Начало работы с AWS на LabEx и Предоставление читателю отчётов минимальных привилегий. Эта новая VM предоставляет приложение и независимую стадию REST API; прежние ресурсы API или сети не нужны.

Связь с сертификацией

Эта лабораторная работа помогает на практике изучить следующие темы экзаменов.

Cloud Practitioner (CLF-C02) · Задача 2.4: Связывание веб-ACL WAF и правила фильтрации запросов.
Solutions Architect – Associate (SAA-C03) · Задача 1.2: Связывание веб-ACL WAF и правила фильтрации запросов.
Security – Specialty (SCS-C03) · Задача 3.1: Базовая практика: Связывание веб-ACL WAF и правила фильтрации запросов.
Solutions Architect – Professional (SAP-C02) · Задача 2.3: Базовая практика: Связывание веб-ACL WAF и правила фильтрации запросов.

Создание регионального Web ACL

На этом шаге вы определите правило запросов AWS WAF внутри списка контроля веб-доступа (Web ACL). WAF проверяет запросы до их поступления в приложение. Предоставленный REST API имеет именованную стадию, которую можно связать с региональным Web ACL; эта точка входа отличается от HTTP API курса API/Cognito.

Откройте AWS View рядом с Terminal, чтобы сравнивать правила, связь со стадией и достижение бэкенда каждым запросом. Сохраните несвязанные эталонные Web ACL и стадию.

Правило сочетает условие совпадения с действием. Действие по умолчанию применяется, когда ни одно правило не совпало. Мы будем блокировать /internal/ и разрешать другие пути.

Перейдите в каталог проекта и подтвердите подготовленную идентификацию оператора. Предоставленный stage-arn.txt содержит ARN стадии приложения, а не учётные данные. Подстановка команды сохраняет это значение для последующего связывания.

cd /home/labex/project

aws sts get-caller-identity --query Arn --output text

STAGE_ARN=$(cat stage-arn.txt)

Ожидайте labex-sec05-operator. До связывания любого Web ACL синтетический внутренний экспорт достигает бэкенда. curl выполняет настоящий HTTP-запрос; -sS убирает вывод прогресса, сохраняя ошибки соединения, а -w выводит статус ответа.

curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/internal/export

Ожидайте HTTP 200 и синтетический ответ бэкенда. Запишите файл правила с here-document в кавычках: строки между <<'EOF' и EOF становятся файлом JSON точно в записанном виде. UriPath выбирает путь, STARTS_WITH сопоставляет префикс, а NONE предотвращает его преобразование. Меньшие числовые приоритеты выполняются первыми; этот ACL имеет одно правило с приоритетом ноль. Настройки видимости отключают необязательные выборки и метрики для этого целевого упражнения. Сохраните те же настройки в visibility.json для самого ACL и его последующего обновления.

cat > rules-internal.json <<'EOF'
[{
  "Name": "block-private-export",
  "Priority": 0,
  "Action": {"Block": {}},
  "Statement": {"ByteMatchStatement": {
    "SearchString": "/internal/",
    "FieldToMatch": {"UriPath": {}},
    "PositionalConstraint": "STARTS_WITH",
    "TextTransformations": [{"Priority": 0, "Type": "NONE"}]
  }},
  "VisibilityConfig": {"SampledRequestsEnabled": false, "CloudWatchMetricsEnabled": false, "MetricName": "labex-sec05-owned-export"}
}]
EOF

Создайте региональный ACL с Allow по умолчанию. --cli-binary-format raw-in-base64-out указывает AWS CLI v2 интерпретировать SearchString как буквальные входные байты, а не ожидать строку base64. file:// загружает документ правила; --query выбирает только полученный идентификатор ACL.

cat > visibility.json <<'EOF'
{
  "SampledRequestsEnabled": false,
  "CloudWatchMetricsEnabled": false,
  "MetricName": "labex-sec05-owned-export"
}
EOF

ACL_ID=$(aws wafv2 create-web-acl \
  --name labex-sec05-owned-export \
  --scope REGIONAL \
  --default-action Allow={} \
  --visibility-config file://visibility.json \
  --rules file://rules-internal.json \
  --cli-binary-format raw-in-base64-out \
  --query Summary.Id \
  --output text)

ACL_ARN=$(aws wafv2 get-web-acl \
  --name labex-sec05-owned-export \
  --scope REGIONAL \
  --id "$ACL_ID" \
  --query WebACL.ARN \
  --output text)

aws wafv2 get-web-acl \
  --name labex-sec05-owned-export \
  --scope REGIONAL \
  --id "$ACL_ID" \
  --query 'WebACL.{Name:Name,Default:DefaultAction,Rules:Rules[].Name}'

Ожидайте ACL упражнения, Allow по умолчанию и block-private-export. Создание политики не подключает её к конечной точке. AWS View по-прежнему должен показывать отсутствие связи с целью.

Связывание ACL и проверка реальных запросов

На этом шаге вы подключите свою политику к предоставленной стадии REST API и сравните общедоступный запрос с запросом экспорта, совпадающим с правилом. Стадия определяет развёрнутое окружение API; связь применяет ACL к запросам этой стадии.

WAF перед бэкендом

Связанный Web ACL отклоняет внутренний путь до его поступления в бэкенд.

Свяжите только свой ACL с предоставленным целевым ARN. Несвязанная эталонная стадия уже имеет собственный эталонный ACL; не заменяйте его.

aws wafv2 associate-web-acl --web-acl-arn "$ACL_ARN" --resource-arn "$STAGE_ARN"

aws wafv2 get-web-acl-for-resource \
  --resource-arn "$STAGE_ARN" \
  --query WebACL.Name \
  --output text

Ожидайте labex-sec05-owned-export. Проверьте общедоступный путь проверки состояния, который не совпадает с /internal/, затем внутренний путь экспорта.

curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/health

curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/internal/export

Ожидайте HTTP 200 для проверки состояния и HTTP 403 с block-private-export для экспорта. Решение Block возвращает ответ до выполнения бэкенда. AWS View должен показывать Executed для запроса проверки состояния и Not reached для заблокированного запроса. Одного связывания в сервисе недостаточно; эти реальные результаты HTTP доказывают применение защиты.

Пример AWS View: проверка состояния достигает бэкенда, а внутренний экспорт блокируется до выполнения.

Обновление правила и наблюдение текущего поведения

На этом шаге вы перенесёте защиту на префикс admin и покажете изменившееся поведение без перезапуска приложения. Обновление Web ACL заменяет список правил. Его токен блокировки защищает от перезаписи одновременного изменения; получите его из текущей конфигурации сервиса непосредственно перед обновлением и сохраните в переменной.

Создайте новый документ правила, заменив префикс URI в прежнем файле. sed преобразует текст, а > записывает новый файл, сохраняя исходный документ правила.

sed 's|/internal/|/admin/|' rules-internal.json > rules-admin.json

LOCK_TOKEN=$(aws wafv2 get-web-acl \
  --name labex-sec05-owned-export \
  --scope REGIONAL \
  --id "$ACL_ID" \
  --query LockToken \
  --output text)

aws wafv2 update-web-acl \
  --name labex-sec05-owned-export \
  --scope REGIONAL \
  --id "$ACL_ID" \
  --lock-token "$LOCK_TOKEN" \
  --default-action Allow={} \
  --visibility-config file://visibility.json \
  --rules file://rules-admin.json \
  --cli-binary-format raw-in-base64-out \
  --query NextLockToken \
  --output text

Возвращённый токен блокировки определяет новую редакцию ACL; он не является учётными данными аутентификации. Теперь прежний внутренний префикс должен проходить по действию Allow по умолчанию, а экспорт admin должен блокироваться.

curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/internal/export

curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/admin/export

Ожидайте HTTP 200, затем HTTP 403. AWS View должен показывать новый префикс /admin/, прежний заблокированный внутренний запрос и текущую пару разрешённого внутреннего и заблокированного admin запросов. Запросы используют текущее правило сервиса; перезапуск VM или приложения не требуется. Неподдерживаемые типы политик в этой целевой среде приводят к отказу доступа, поэтому используйте только изученную здесь конструкцию правила.

Пример AWS View после обновления префикса: внутренний экспорт разрешён, а экспорт admin заблокирован.

Отключение и удаление только ACL упражнения

На этом шаге вы удалите свою политику и подтвердите возвращение обычной маршрутизации приложения. Сначала завершите предыдущие функциональные проверки. Удаление связи прекращает применение защиты на этой стадии; последующее удаление ACL удаляет ресурс политики упражнения.

Отключите свой Web ACL от целевой стадии и проверьте связь успешным запросом сервиса. Ожидайте пустую связь, не считая ошибку аутентификации доказательством удаления.

aws wafv2 disassociate-web-acl --resource-arn "$STAGE_ARN"

aws wafv2 get-web-acl-for-resource --resource-arn "$STAGE_ARN" --query WebACL

Ранее заблокированный экспорт admin теперь должен снова достигать предоставленного бэкенда.

curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/admin/export

Ожидайте HTTP 200. Получите текущий токен блокировки, удалите только ACL упражнения и успешно запросите оставшиеся ACL. Имя упражнения должно отсутствовать, а labex-sec05-reference — остаться.

LOCK_TOKEN=$(aws wafv2 get-web-acl \
  --name labex-sec05-owned-export \
  --scope REGIONAL \
  --id "$ACL_ID" \
  --query LockToken \
  --output text)

aws wafv2 delete-web-acl \
  --name labex-sec05-owned-export \
  --scope REGIONAL \
  --id "$ACL_ID" \
  --lock-token "$LOCK_TOKEN"

aws wafv2 list-web-acls --scope REGIONAL --query 'WebACLs[].Name'

Сохраните обе предоставленные стадии API и эталонный ACL неизменными. Удалите локальные документы правил и видимости, затем выполните проверку этого шага до удаления временного профиля CLI.

rm -f rules-internal.json rules-admin.json visibility.json

rm -f /home/labex/.aws/credentials /home/labex/.aws/config

unset STAGE_ARN ACL_ID ACL_ARN LOCK_TOKEN

Резюме

Вы создали региональный Web ACL, связали его со стадией REST API и проверили реальное разрешение и блокировку HTTP-запросов. Совпадающий запрос остановился до бэкенда, а запросы проверки состояния продолжили работать. Обновление префикса URI изменило текущую маршрутизацию; удаление связи восстановило конечную точку. Вы удалили только ACL упражнения и сохранили предоставленные стадии и эталонную политику.