Amazon ANS-C01: Сетевая безопасность и соответствие требованиям — Руководство по подготовке

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Часть AWS Advanced Networking Specialty ANS-C01 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Основная концепция

Сетевая безопасность в AWS является многоуровневой: средства контроля периметра, средства контроля на уровне VPC, средства контроля на уровне хостов и приложений, а также мониторинг и инспекция. На границе VPC для применения общих правил контроля доступа используются группы безопасности (виртуальные брандмауэры с отслеживанием состояния, ориентированные на хосты и применяемые к ENI) и сетевые списки контроля доступа (NACL) (фильтрация на уровне подсети без отслеживания состояния, правила которой оцениваются по номеру). Группы безопасности отслеживают состояние соединения, поэтому установленный ответный трафик разрешается автоматически. Это делает их идеальным решением для разрешения соединений, инициированных клиентом, к подам или инстансам. NACL требуют явных разрешающих записей в обоих направлениях или дополнительных правил для обратного трафика; они оцениваются в порядке возрастания номеров правил и поэтому подходят для общего усиления безопасности на уровне подсети, например, для блокировки целых диапазонов CIDR или применения временных исключений для списков экстренной блокировки.

Инспекция и централизованное применение политик обеспечиваются управляемыми и самоуправляемыми сервисами. AWS Network Firewall может реализовывать на периметре VPC защиту с отслеживанием состояния, подобную Suricata, фильтрацию по спискам доменов и сигнатуры в стиле систем предотвращения вторжений с помощью явных политик брандмауэра и групп правил. Брандмауэр для веб-приложений (AWS WAF) ориентирован на приложения для защиты на уровне HTTP(S) и интегрируется с Application Load Balancer, Amazon CloudFront и API Gateway для применения защиты от угроз OWASP, правил на основе частоты запросов и проверок пользовательских заголовков. Защита от DDoS-атак обеспечивается сервисом AWS Shield (Standard предоставляется автоматически и бесплатно; Shield Advanced обеспечивает инжиниринг трафика, защиту от непредвиденных расходов и интеграцию с WAF для смягчения атак на уровне приложений). Сервисы обнаружения, такие как Amazon GuardDuty, анализируют VPC Flow Logs, DNS-логи и CloudTrail для выявления разведки, сканирования портов и поведения скомпрометированных инстансов.

Видимость и захват пакетов завершают эту модель. VPC Flow Logs записывают метаданные потоков для каждого ENI и могут доставляться в CloudWatch Logs, Amazon S3 или Kinesis Data Firehose для анализа с помощью Athena. Для полного захвата пакетов или более глубокой инспекции Traffic Mirroring позволяет зеркалировать трафик ENI на устройство IDS/захвата пакетов (сенсор на EC2 с зеркалируемым ENI или цель Network Load Balancer), где работают такие инструменты, как Suricata или Zeek. Вместе эти средства контроля обеспечивают глубокоэшелонированную защиту, в которой присутствуют предотвращение, обнаружение и расследование инцидентов.

Ключевые сервисы и конфигурация

Несколько сервисов AWS играют центральную роль в сетевой безопасности, и для каждого из них необходимо знать определенные шаблоны конфигурации и API:

Security Groups
Network ACLs (NACLs)
AWS Network Firewall
AWS WAF
AWS Shield (Standard и Advanced)
Amazon GuardDuty
VPC Flow Logs
Traffic Mirroring

Группы безопасности настраиваются для каждого ENI через EC2 API или консоль; чтобы добавить правило для входящего трафика, используйте команду «aws ec2 authorize-security-group-ingress –group-id sg-123 –protocol tcp –port 443 –cidr 0.0.0.0/0». Не забывайте использовать CIDR с минимальными привилегиями и прикреплять отдельные группы безопасности для балансировщиков нагрузки и бэкенд-подов, чтобы избежать чрезмерно широких правил. Создавайте NACL с помощью команды «aws ec2 create-network-acl» и добавляйте пронумерованные записи с помощью «aws ec2 create-network-acl-entry», указывая номер правила, действие, протокол, диапазон портов и флаг исходящего трафика (egress).

AWS Network Firewall использует группы правил и политики брандмауэра, привязанные к ресурсу брандмауэра, созданному в подсети VPC. Используйте «aws network-firewall create-rule-group» для определения правил с отслеживанием или без отслеживания состояния, «aws network-firewall create-firewall-policy» для их компоновки и «aws network-firewall create-firewall» для развертывания. Выбирайте группы правил с отслеживанием состояния для инспекции с учетом протокола и сигнатурных правил, совместимых с Suricata; используйте правила без отслеживания состояния для очень высокой пропускной способности и фильтрации первого прохода.

AWS WAF прикрепляет Web ACL к ALB и может применять правила на основе совпадения с наборами IP-адресов, совпадения строк в заголовках или частоты запросов. Используйте «aws wafv2 create-web-acl» и укажите правила, которые проверяют заголовки (например, блокируют запросы, не содержащие пользовательский заголовок, который вы добавляете на доверенном входе). AWS Shield Advanced включается для всего аккаунта и предоставляет доступ к команде реагирования на DDoS-атаки, а также дополнительную защиту для ресурсов, зарегистрированных в Shield Advanced.

Включите GuardDuty с помощью команды «aws guardduty create-detector» и интегрируйте его находки с CloudWatch Events или EventBridge для автоматизации. Для сбора телеметрии создайте VPC Flow Logs с помощью команды «aws ec2 create-flow-logs –resource-type VPC –resource-id vpc-123 –traffic-type ALL –log-destination-type cloud-watch-logs –log-group-name /aws/vpc/flowlogs». Для захвата пакетов используйте команды «aws ec2 create-traffic-mirror-target», «aws ec2 create-traffic-mirror-filter» и «aws ec2 create-traffic-mirror-session», чтобы направить зеркалированный трафик на ENI устройства или NLB.

Шаблоны проектирования и компромиссы

Сквозное шифрование с взаимной аутентификацией TLS, при котором балансировщик нагрузки не должен терминировать TLS, требует использования шаблона сквозной передачи на уровне 4. Используйте Network Load Balancer (NLB) перед бэкенд-подами, чтобы сессия TLS устанавливалась напрямую с конечными точками сервиса. В Kubernetes на EKS разверните сервис типа LoadBalancer, использующий NLB, и зарегистрируйте поды в качестве целей по IP-адресу; AWS Load Balancer Controller или устаревшие аннотации Service гарантируют, что тип цели будет IP, а протокол целевой группы — TCP. Для высокой конкурентности, характерной для gRPC и множества долгоживущих соединений HTTP/2, NLB сохраняет исходные IP-адреса и создает меньшие накладные расходы на одно соединение по сравнению с прокси-серверами уровня 7. Если требуется терминирование TLS на ALB (например, для маршрутизации на основе URL), необходимо терминировать TLS на ALB с помощью сертификата ACM, а затем перенаправлять трафик на бэкенды; сохраняйте IP-адрес клиента, используя заголовок

undefined

(ALB) или применяя NLB с поддержкой Proxy Protocol v2 для бэкендов, которым нужен исходный IP-адрес источника на уровне L4.

Для масштабируемых архитектур с несколькими аккаунтами и VPC, где требуются централизованные сервисы, PrivateLink (AWS VPC Endpoint Services) является наиболее безопасным и масштабируемым выбором. Предоставьте доступ к централизованным сервисам из VPC для общих сервисов через сервис конечной точки AWS PrivateLink. Каждый аккаунт-потребитель создает интерфейсную конечную точку VPC для этого сервиса; владелец сервиса может требовать подтверждения для конечной точки и применять контроль на основе групп безопасности к ее ENI. Эта модель удерживает трафик в сети AWS, позволяет избежать ограничений масштабирования пиринговых соединений и обеспечивает гранулярную безопасность для каждого потребителя. Transit Gateway с сегментацией и Network Firewall можно использовать для транзита на сетевом уровне и централизованной инспекции, но это более уместно, когда требуется полная маршрутизируемая связность со сложными политиками маршрутизации, а не изоляция на уровне отдельных сервисов.

При диагностике использования пропускной способности по нескольким VIF в Direct Connect в первую очередь уделяйте внимание метаданным: включите и запрашивайте VPC Flow Logs, агрегированные в S3 или CloudWatch, и анализируйте их с помощью Athena, чтобы сопоставить IP-потоки с большим объемом данных с конкретными VPC и подсетями. Дополняйте данные журналов потоков метриками CloudWatch для виртуальных интерфейсов Direct Connect, а если вам нужна инспекция на уровне полезной нагрузки или поддержка гетерогенных протоколов, разверните Traffic Mirroring для захвата пакетов и их отправки в IDS на базе EC2. Traffic Mirroring создает значительную нагрузку и влечет за собой затраты; используйте его только для тех сессий или временных окон, когда данных из журналов потоков и результатов GuardDuty недостаточно.

Распространенные ошибки и критерии выбора

Распространенная ошибка — полагаться только на группы безопасности для общей защиты периметра и не использовать NACL или Network Firewall там, где требуется инспекция на уровне подсети или с отслеживанием состояния. Группы безопасности применяются на уровне ENI и просты в управлении, но они плохо масштабируются в качестве централизованного уровня управления для множества VPC в разных аккаунтах; используйте AWS Firewall Manager для централизации правил WAF и Network Firewall между аккаунтами. Другая ошибка — терминирование TLS на балансировщике нагрузки без учета сохранения IP-адреса клиента; ALB вставляет заголовки X-Forwarded-For, но логирование в приложении должно явно считывать этот заголовок, и должно быть установлено доверие (например, только ALB должен его отправлять). Для строгой гарантии того, что только Global Accelerator может обращаться к ALB, не полагайтесь исключительно на DNS; вместо этого ограничьте слушатели ALB с помощью групп безопасности, разрешив доступ только с опубликованных диапазонов IP-адресов акселератора (автоматизируйте обновления с помощью ip-ranges.json или управляемых списков префиксов), или, где это возможно, используйте внутренний ALB и разместите перед ним эндпоинт акселератора.

Выбирайте между PrivateLink и Transit Gateway, взвешивая гранулярность на уровне сервисов и полносвязную маршрутизацию. PrivateLink обеспечивает контроль доступа на уровне отдельных сервисов с фильтрацией на уровне групп безопасности и масштабируется без разрастания таблиц маршрутизации; Transit Gateway необходим, когда вам нужна связность на основе маршрутов между множеством VPC и локальными сетями, а также когда требуется централизованная инспекция пакетов с помощью AWS Network Firewall. Для высокой пропускной способности отдавайте предпочтение правилам Network Firewall без отслеживания состояния на периметре в сочетании с целевыми группами правил с отслеживанием состояния для критически важных потоков; обработка без отслеживания состояния масштабируется, но теряет осведомленность о протоколе.

Практическая задача: сценарий использования

Компания: Meridian Payments — задача: реализовать API для платежей на базе gRPC в EKS, требующий сквозного взаимного TLS (mTLS) (без терминирования TLS на промежуточных узлах), поддерживать тысячи одновременных долгоживущих соединений, автомасштабирование подов и идентификацию исходных IP-адресов клиентов для логирования и обнаружения мошенничества.

Подход: Развернуть Amazon Network Load Balancer перед сервисом EKS, настроенным с типом цели IP, чтобы ENI подов регистрировались напрямую в целевых группах NLB. Использовать AWS Load Balancer Controller для создания Service, поддерживаемого NLB, с аннотациями, чтобы протокол целевой группы был TCP на порту 443, а проверки состояния использовали TCP. Терминировать mTLS на бэкенд-подах; настроить Istio или sidecar-библиотеку для TLS, если требуется стандартизированная ротация сертификатов, используя Kubernetes Secrets, заполненные из AWS Certificate Manager Private Certificate Authority или AWS Secrets Manager. Сохранять IP-адреса клиентов, поскольку NLB сохраняет исходный IP-адрес; убедиться, что правила networkPolicy и групп безопасности для бэкенд-подов разрешают исходные диапазоны от NLB/клиентов. Использовать HPA и Cluster Autoscaler для масштабирования подов; убедиться, что задержка дерегистрации целевой группы настроена для корректного завершения соединений.
Подход к наблюдаемости и анализу инцидентов: Включить VPC Flow Logs для VPC кластера EKS с отправкой в CloudWatch Logs и агрегировать в S3 через Kinesis Firehose для хранения и выполнения запросов с помощью Athena, сопоставляя потоки с высокой пропускной способностью. Включить GuardDuty для обнаружения аномалий в потоках VPC и DNS. Если во время окон предполагаемой мошеннической активности требуется более глубокая инспекция пакетов, создать сессии Traffic Mirror на проблемных ENI, направляя трафик на сенсор на EC2 с запущенным Suricata; управлять фильтрами зеркалирования, чтобы захватывать только релевантный трафик для ограничения затрат.

Обоснование со стороны AWS: NLB обеспечивает сквозную передачу на уровне L4, поэтому TLS и mTLS устанавливаются в сквозном режиме, и бэкенд видит истинный IP-адрес клиента. Это удовлетворяет требованиям, согласно которым трафик не расшифровывается промежуточными прокси, а системы логирования/анализа мошенничества видят исходный источник. Регистрация подов по IP и использование AWS Load Balancer Controller интегрируется с автомасштабированием EKS. VPC Flow Logs, GuardDuty и Traffic Mirroring обеспечивают градуированную видимость от метаданных до полного захвата пакетов для масштабируемого и экономически эффективного обеспечения соответствия требованиям и реагирования на инциденты.

← Балансировка нагрузки и управление трафиком · Все домены · Доставка контента и периферийные сети →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →