Amazon SCS-C02: Сетевое взаимодействие и безопасность VPC — Руководство по подготовке

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

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

VPC-эндпоинты и политики эндпоинтов

VPC-эндпоинты позволяют направлять трафик к сервисам AWS в пределах сети AWS, минуя публичный интернет, NAT-шлюзы и интернет-шлюзы. Существует два структурно различных типа эндпоинтов, и их путаница — одна из самых распространенных ошибок при проектировании.

Шлюзовые эндпоинты (Gateway endpoints) существуют только для Amazon S3 и DynamoDB. Они представляют собой записи в таблице маршрутизации — вы связываете эндпоинт с таблицами маршрутизации, и трафик, предназначенный для префикс-листа сервиса (например, pl-63a5400a для S3 в us-east-1), незаметно перенаправляется через эндпоинт. Они бесплатны, и к ним нельзя получить доступ извне VPC, к которому они подключены.

Интерфейсные эндпоинты (Interface endpoints), работающие на базе AWS PrivateLink, — это сетевые интерфейсы (ENI) с частными IP-адресами, размещенные в ваших подсетях. Они необходимы для всех сервисов, кроме S3 и DynamoDB, — Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR и сотен других. Если инстансу EC2 в частной подсети без NAT-шлюза необходимо выполнить GetSecretValue из Secrets Manager, шлюзовой эндпоинт не поможет; вы должны создать интерфейсный эндпоинт com.amazonaws.<region>.secretsmanager и включить Private DNS, чтобы стандартное имя хоста сервиса разрешалось в частный IP-адрес эндпоинта.

Политики эндпоинтов ограничивают, что можно делать через эндпоинт, независимо от IAM-политик вызывающей стороны. Два наиболее важных ключа условий (condition keys) для предотвращения эксфильтрации данных — это aws:PrincipalOrgID (субъект, выполняющий вызов, должен принадлежать вашей организации) и aws:ResourceOrgID (затрагиваемый ресурс, например бакет S3 или ключ KMS, должен принадлежать вашей организации). Применение обоих ключей закрывает классический путь эксфильтрации, когда скомпрометированный инстанс с легитимными правами доступа к S3 записывает данные в бакет злоумышленника за пределами вашей организации — учетные данные по-прежнему действительны для S3, но эндпоинт отказывается перенаправлять такой запрос.

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

Политика эндпоинта по умолчанию является полностью разрешающей ("Action":"*" для "Resource":"*"), поэтому подсеть, имеющая только шлюзовой эндпоинт и IAM с минимальными привилегиями, все равно может быть использована для эксфильтрации, если вы не ужесточите саму политику эндпоинта.

Гибридное подключение: VPN и Direct Connect

Site-to-Site VPN устанавливает два туннеля IPsec между виртуальным частным шлюзом (virtual private gateway) или Transit Gateway и устройством на стороне клиента (customer gateway device). Такое подключение быстро настраивается, шифруется по умолчанию и проходит через публичный интернет, поэтому пропускная способность и задержка зависят от маршрута вашего интернет-провайдера.

AWS Direct Connect предоставляет выделенный физический канал через точку присутствия Direct Connect. Он обеспечивает предсказуемо низкую задержку и высокую, стабильную пропускную способность (1/10/100 Гбит/с), что важно для «разговорчивого» трафика локальных баз данных. Сам по себе Direct Connect не шифруется на уровне 3; фреймы передаются по частному оптоволокну. Для рабочих нагрузок, требующих одновременно и низкой задержки, и шифрования IPsec, каноническим решением является Direct Connect в сочетании с Site-to-Site VPN, работающим поверх публичного VIF (или Transit Gateway с MACsec на более новых портах DX). VPN сам по себе также является рекомендуемым зашифрованным резервным каналом для основного подключения Direct Connect, обеспечивая отказоустойчивость в случае сбоя основного канала.

Только Direct Connect: низкая задержка, приватность, но без шифрования на IP-уровне.
Только VPN: шифрование, быстрое развертывание, но задержка и джиттер зависят от пути в интернете.
Direct Connect + VPN: низкая задержка и шифрование IPsec; также стандартная схема для высокой доступности (HA).

Группы безопасности, NACL, DHCP и проверка источника/назначения

Группы безопасности (Security groups) работают с отслеживанием состояния (stateful): если вы разрешаете входящий запрос, ответ на него разрешается автоматически. Они поддерживают только разрешающие правила и применяются на уровне каждого ENI.

Списки контроля доступа к сети (NACL) работают без отслеживания состояния (stateless) и действуют на границе подсети. Для каждого потока данных требуется два правила — одно для исходного направления и одно для обратного трафика в диапазоне эфемерных портов (для Linux обычно 32768–60999, для Windows 49152–65535, а для NLB/ELB используется 1024–65535). NACL, который разрешает входящий трафик по TCP-порту 443, но забывает разрешить исходящий трафик в диапазоне TCP 1024–65535, незаметно нарушит работу TLS. ICMP — это не TCP/UDP: ответные пакеты «echo reply» должны быть разрешены явно, а механизм Path MTU Discovery зависит от ICMP тип 3 код 4, который легко случайно заблокировать. Правила NACL также обрабатываются в порядке их номеров, применяется первое совпавшее правило, а в конце списка находится неявное запрещающее правило.

Наборы опций DHCP (DHCP option sets) определяют, какие параметры VPC передает инстансам при загрузке: domain-name-servers, domain-name, NTP-серверы, NetBIOS. Замена стандартного AmazonProvidedDNS на собственный локальный DNS-резолвер может быть оправданной, но это имеет реальные последствия для безопасности. Сервисы, такие как GuardDuty, формируют свои заключения на основе DNS-запросов (например, обнаружение «криптовалюты» и «доменов C&C»), анализируя запросы, проходящие через Route 53 Resolver. Как только вы направите инстансы на сторонний DNS-сервер, GuardDuty перестанет видеть эти запросы, и соответствующие типы находок исчезнут — так можно случайно «ослепить» систему обнаружения.

Проверка источника/назначения (Source/destination checking) — это атрибут ENI, который отбрасывает любой пакет, если его IP-адрес источника или назначения не совпадает с IP-адресом ENI. Это поведение по умолчанию является правильным для обычных инстансов, но нарушает работу любых устройств, чья задача — перенаправлять трафик: NAT-инстансов, виртуальных межсетевых экранов (Palo Alto, Fortinet, Check Point), транзитных маршрутизаторов, VPN-концентраторов. Для таких ENI эту проверку необходимо отключить:

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

Пиринг VPC, общие VPC через RAM и архитектура NAT

Пиринг VPC — это одноранговое, нетранзитивное соединение 3-го уровня. Если VPC A соединен с B, а B — с C, то A не может достичь C. Для этого необходимо напрямую соединить A и C или использовать Transit Gateway. Таблицы маршрутизации с обеих сторон должны содержать маршруты к CIDR-блоку пира, а группы безопасности могут ссылаться на ID групп безопасности пира только в пределах одного региона.

Общие VPC, предоставляемые через AWS Resource Access Manager (RAM), позволяют сетевой учетной записи владеть VPC и делиться отдельными подсетями с учетными записями-участниками. Участники запускают ресурсы в общих подсетях, но не могут изменять VPC, таблицы маршрутизации или конечные точки — владелец сохраняет контроль над политикой подключения. Это часто дешевле и проще, чем пиринг множества VPC.

Для исходящего интернет-трафика из частных подсетей развертывайте NAT-шлюз в каждой зоне доступности и направляйте каждую частную подсеть на NAT-шлюз в ее собственной зоне доступности. Один NAT-шлюз создает межзональную зависимость и является узким местом в масштабировании и доступности. Когда ваше приложение обращается к стороннему сервису, который добавляет ваш исходящий IP в белый список (например, к платежному процессору), вы регистрируете Elastic IP NAT-шлюза. Поскольку весь исходящий трафик от инстансов в группе Auto Scaling идет через этот фиксированный EIP, исходный IP-адрес не меняется при масштабировании группы. Размещение инстансов EC2 и базы данных RDS в частных подсетях и завершение только HTTP/HTTPS на ALB завершает этот паттерн.

Route 53 Resolver: пересылка и логирование запросов

Route 53 Resolver (адрес .2 в каждом VPC) является ключевым элементом для гибридного DNS. Исходящие конечные точки преобразователя (outbound resolver endpoints) пересылают запросы для указанных доменных имен из AWS на локальные DNS-серверы с помощью правил условной пересылки. Это используется, например, чтобы corp.example.internal разрешался через ваш Active Directory. Входящие конечные точки преобразователя (inbound resolver endpoints) делают обратное, предоставляя локальным хостам частный IP-адрес в вашем VPC, который они могут запрашивать для разрешения *.eu-west-1.compute.internal и частных размещенных зон (Private Hosted Zones).

Логирование запросов преобразователя (resolver query logging) записывает каждый DNS-запрос, сделанный из VPC, в CloudWatch Logs, S3 или Kinesis Firehose. Это авторитетная запись для расследования подозреваемой эксфильтрации данных или неправомерного использования, которая дополняет, но не заменяет GuardDuty. Помните, что если набор опций DHCP перенаправляет инстансы на преобразователь, отличный от Amazon, то и логирование запросов, и выводы GuardDuty по DNS перестают работать, поскольку запросы никогда не достигают Route 53 Resolver.

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

Сценарий: Meridian Financial использует среду AWS с несколькими учетными записями и сетью топологии hub-and-spoke: в VPC для общих сервисов, предоставленном через RAM, размещены центральные NAT Gateways, конечные точки Route 53 Resolver и подключения к Transit Gateway, в то время как несколько VPC приложений соединены пирингом или подключены к Transit Gateway. Локальные дата-центры подключены через Direct Connect с аварийным переключением на VPN, а команды используют централизованные наборы опций DHCP и общие конечные точки преобразователя для гибридного разрешения DNS.

Проблема: Недавний инцидент показал, что доступ к конфиденциальным объектам S3 осуществлялся через публичный интернет, поскольку периферийные VPC маршрутизировали трафик через общий NAT вместо конечных точек VPC. Также DNS-запросы для внутренних зон утекали на публичные преобразователи, а инстанс EC2, использовавшийся как импровизированный маршрутизатор (с отключенной проверкой источника/назначения), обеспечил возможность горизонтального перемещения.

Рекомендуемый подход:

Развернуть шлюзовые конечные точки VPC (Gateway VPC Endpoints) для S3 и DynamoDB и интерфейсные конечные точки (Interface Endpoints, AWS PrivateLink) для Secrets Manager и KMS в VPC для общих сервисов. Прикрепить явные политики конечных точек, ограничивающие доступ к указанным бакетам и субъектам-службам.
Переработать архитектуру NAT так, чтобы подсети приложений использовали конечные точки VPC для AWS API и S3; сохранить NAT Gateways только для действительно необходимого исходящего интернет-трафика со строгими правилами исходящего трафика в группах безопасности и Flow Logs в CloudWatch/S3.
Повторно включить проверку источника/назначения на всех инстансах EC2, за исключением задокументированных устройств маршрутизации; перенести маршрутизацию на подключения Transit Gateway или управляемые инстансы NAT и обеспечить принцип наименьших привилегий для таблиц маршрутизации.
Ужесточить группы безопасности и NACL подсетей до принципа запрета по умолчанию и применить централизованные базовые конфигурации IAM и групп безопасности через SCP в AWS Organizations и правила AWS Config.
Усилить защиту гибридного DNS путем развертывания входящих/исходящих конечных точек Route 53 Resolver, настроить условную пересылку и правила DNS Firewall, включить логирование запросов преобразователя в CloudWatch Logs и использовать наборы опций DHCP для принудительного использования внутренних преобразователей во всех VPC, предоставленных через RAM.

Обоснование: Этот подход устраняет ненужный исходящий интернет-трафик за счет использования конечных точек VPC с политиками, централизует и контролирует маршрутизацию через Transit Gateway/Direct Connect, восстанавливает защиту на уровне инстансов и предотвращает утечку DNS-запросов с помощью конечных точек преобразователя и логирования, что соответствует лучшим практикам AWS в области сетей и многоуровневой защиты.

Эндпоинты VPC и политики эндпоинтов

Эндпоинты VPC позволяют рабочим нагрузкам внутри VPC обращаться к API сервисов AWS, не выходя в публичный интернет и не используя NAT-шлюз. Существует два архитектурных варианта, и выбор неправильного из них — частая причина неверной маршрутизации трафика.

Шлюзовые эндпоинты (Gateway endpoints): Используются только для Amazon S3 и DynamoDB. Они реализуются как цель в таблице маршрутизации (prefix list pl-xxxxxxxx, указывающий на vpce-xxxxxxxx). Сетевой интерфейс (ENI) не создается, изменения в DNS не требуются, и почасовая оплата отсутствует.
Интерфейсные эндпоинты (Interface endpoints, PrivateLink): Используются для KMS, SQS, SNS, Secrets Manager, STS, EC2 API и большинства других сервисов. Они создают сетевые интерфейсы (ENI) с приватными IP-адресами в выбранных подсетях и тарифицируются почасово плюс за гигабайт трафика.

Для меж-аккаунтной пакетной задачи, где EC2-инстансы в аккаунте B читают из бакета S3 в аккаунте A, зашифрованного KMS-ключом из аккаунта A, правильным решением будет использование шлюзового эндпоинта для S3 и интерфейсного эндпоинта для KMS. Шлюзовой эндпоинт не выпускает в интернет трафик для s3:GetObject, s3:PutObject, s3:PutObjectAcl и s3:ListBucket; интерфейсный эндпоинт делает то же самое для kms:Decrypt, kms:Encrypt и kms:GenerateDataKey. Поскольку ARN KMS-ключа использует стандартное имя хоста kms.<region>.amazonaws.com, у интерфейсного эндпоинта должна быть включена опция Private DNS, чтобы SDK без изменений в коде разрешал это имя хоста в IP-адрес ENI эндпоинта, а не в публичный IP-адрес сервиса KMS. Без Private DNS (или если на уровне VPC не включены DNS hostnames и DNS resolution), клиент все равно обращался бы к публичному эндпоинту — следовательно, требование «без изменений в коде» неявно подразумевает использование Private DNS.

Политики эндпоинтов — это второй, независимый уровень авторизации. По умолчанию существует разрешающая политика, но её ужесточение для конкретного бакета и ключа выглядит так:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

Просто создать эндпоинт недостаточно. Часто встречаются два сценария сбоя: (1) эндпоинт существует, но в таблице маршрутизации приватной подсети нет записи для prefix list S3, поэтому трафик по-прежнему уходит через NAT-шлюз; (2) политика эндпоинта не включает необходимое действие, например s3:PutObjectAcl, или указывает на неверный ARN бакета, что приводит к тихой блокировке вызовов, которые IAM в противном случае разрешил бы. И политика бакета, и политика эндпоинта должны разрешать запрос — их разрешения пересекаются, а не объединяются.

Группы безопасности, сетевые ACL и быстрое сдерживание

Группы безопасности (Security groups) и списки контроля доступа к сети (NACL) решают схожие задачи на разных уровнях, и на экзамене часто требуется выбрать между ними для реагирования на инциденты.

Группы безопасности (Security groups): С состоянием (stateful), применяются на уровне ENI. Ответный трафик разрешается автоматически. Существуют только разрешающие правила. Идеальны для политик на уровне хоста («веб-уровень может обращаться к уровню приложений по порту 8080»).
Сетевые ACL (NACL): Без состояния (stateless), применяются на границе подсети. Существуют как разрешающие, так и запрещающие правила, обрабатываемые в порядке их номеров. Идеальны для грубых блокировок на уровне всей подсети — особенно для внесения диапазона IP в черный список или блокировки определенного порта для всех инстансов в подсети.

Когда вспышка вредоносного ПО требует заблокировать исходящий трафик по TCP/2905 на IP-адреса командных центров (C&C) для множества инстансов, правильным инструментом будет запрещающее правило в NACL. Группы безопасности не поддерживают запрещающие правила, и для блокировки пришлось бы перечислять и изменять каждую группу безопасности, используемую затронутыми ENI. Одно запрещающее правило в NACL на уровне подсети с низким номером (например, 90) мгновенно затронет все инстансы в этой подсети, сохраняя при этом остальной трафик, который будет обработан последующими разрешающими правилами.

Поскольку NACL не отслеживают состояние соединений, помните, что правила нужны для обоих направлений трафика. Блокировка исходящего трафика по порту 2905 не требует правила для входящего трафика, но если вы хотите также отклонять входящие ответы, необходимо добавить правило для входящего трафика. Кроме того, должны существовать разрешающие правила для входящего трафика на эфемерные порты (1024–65535), чтобы пропускать легитимный ответный трафик.

NAT-шлюзы, маршрутизация и независимость от AZ

NAT-шлюз — это зональный ресурс. Канонический паттерн — один NAT-шлюз на каждую зону доступности (AZ), при этом таблица маршрутизации каждой приватной подсети направляет трафик 0.0.0.0/0 на NAT-шлюз в той же AZ:

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

Использование одного NAT-шлюза для нескольких AZ кажется дешевле, но создает две проблемы: плата за передачу данных между зонами доступности за каждый пакет и жесткая зависимость от доступности — если эта AZ выйдет из строя, все приватные подсети потеряют выход в интернет. Паттерн с зональными NAT-шлюзами также позволяет избежать проблем с асимметричной маршрутизацией при использовании инспекции трафика через Transit Gateway (см. ниже).

VPC Flow Logs для расследований

VPC Flow Logs собирают метаданные о трафике в виде 5-tuple (IP-адрес и порт источника/назначения, протокол, действие ACCEPT/REJECT, байты, пакеты) на уровне VPC, подсети или ENI. Чтобы выявить инстансы, отправляющие сигналы на C&C-хосты по TCP/2905, включите Flow Logs на уровне VPC с типом трафика REJECT (поскольку NACL теперь отбрасывает этот трафик) и выполните запрос в CloudWatch Logs Insights или Athena:

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

Колонка srcaddr покажет IP-адреса зараженных инстансов с минимальными усилиями — без захвата пакетов и установки агентов на хосты. Выбор типа трафика “ALL” тоже сработает, но сгенерирует больше данных и приведет к большим затратам; выбор только “ACCEPT” полностью упустит из виду заблокированные попытки, которые как раз и нужно увидеть.

PrivateLink, Transit Gateway и Network Firewall

PrivateLink расширяет модель интерфейсных эндпоинтов на ваши собственные сервисы: VPC-провайдер предоставляет NLB через сервис эндпоинта VPC, а потребители создают интерфейсные эндпоинты для доступа к нему без пиринга VPC или совместного использования маршрутов. Соединение является однонаправленным и полностью скрывает CIDR провайдера.

Transit Gateway (TGW) — это центральный узел для связности по принципу «многие ко многим» между VPC и локальными сетями. Распространенный паттерн — это централизованный VPC для инспекции трафика (inspection VPC), в котором работают AWS Network Firewall или сторонние устройства. Таблицы маршрутизации TGW направляют трафик между периферийными сетями (spoke-to-spoke) через этот инспекционный VPC. По умолчанию такая схема не работает, потому что TGW хэширует потоки между ENI в разных AZ, и обратный путь может проходить через другую AZ, нежели прямой. Межсетевые экраны с отслеживанием состояния (stateful) отбрасывают пакеты в середине потока, для которых они не видели SYN.

Требуется внести два исправления одновременно. Во-первых, включите Appliance Mode для подключения TGW к инспекционному VPC; это привязывает каждый двунаправленный поток к одному и тому же ENI в одной AZ, чтобы прямой и обратный трафик проходили через один и тот же эндпоинт межсетевого экрана. Во-вторых, настройте таблицы маршрутизации TGW так, чтобы подключения периферийных сетей (spoke) отправляли трафик на подключение инспекционного VPC, а отдельная таблица маршрутизации для инспекционного VPC (post-inspection) возвращала трафик в нужную периферийную сеть. Если пропустить любой из этих шагов — использовать только Appliance Mode без таблиц маршрутизации или только таблицы маршрутизации без Appliance Mode — асимметричные отбрасывания пакетов сохранятся.

Сам Network Firewall использует правила, совместимые с Suricata, и для поддержания состояния потоков зависит от симметричной маршрутизации. Его совместное использование с Flow Logs как в инспекционном VPC, так и в периферийных VPC, предоставляет след для расследования (forensic trail), необходимый для доказательства того, какая периферийная сеть инициировала сессию и разрешил ли или заблокировал ее межсетевой экран.

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

Сценарий: Компания Meridian Financial использует мультиаккаунтную среду AWS с производственными VPC в трех зонах доступности (AZ) в регионе us-east-1, соединенными через AWS Transit Gateway с центральным VPC безопасности. Они используют NAT Gateway в каждой AZ для исходящего трафика, S3 Gateway Endpoints и Interface Endpoints (PrivateLink) для партнерских SaaS, а также централизованный AWS Network Firewall наряду с Security Groups и NACL; VPC Flow Logs передаются в CloudWatch для мониторинга.

Задача: Производственный инстанс EC2 подозревается в попытках горизонтального перемещения и эксфильтрации данных на внешний IP-адрес и в S3. Компании Meridian необходимо быстро изолировать угрозу во всех AZ, не нарушая работу других критически важных для бизнеса VPC.

Рекомендуемый подход:

Немедленно поместить скомпрометированный инстанс в карантин, заменив его Security Groups на ограничивающую «карантинную» SG, которая запрещает весь входящий и исходящий трафик, и пометить инстанс тегом для автоматического исправления через Systems Manager; одновременно применить правила Network ACL на уровне подсети для блокировки исходящего трафика на подозрительные внешние IP-диапазоны.
Изолировать VPC на Transit Gateway, удалив или изменив подключение таблицы маршрутизации TGW для затронутого VPC на карантинную таблицу маршрутизации TGW (с маршрутом blackhole или без маршрутов к другим подключениям), чтобы остановить горизонтальное перемещение в другие VPC.
Перенаправить оставшийся исходящий трафик VPC через централизованный AWS Network Firewall, обновив записи в TGW и таблицах маршрутизации, чтобы принудительно проводить инспекцию и блокировать известные вредоносные назначения, сохраняя независимость AZ за счет использования NAT Gateway в каждой AZ для отказоустойчивого и инспектируемого исходящего трафика.
Усилить контроль на уровне данных (data plane), применив ограничивающие политики для VPC Endpoint на S3/DynamoDB Gateway Endpoints, чтобы запретить операции Put/Get от неавторизованных субъектов (principals), и убедиться, что внутренние API используют Interface Endpoints (PrivateLink) во избежание маршрутов через интернет.
Использовать VPC Flow Logs с CloudWatch Logs Insights и AWS CloudTrail для проведения расследования (форензики), затем устранить уязвимость (пересоздать образ, сменить ключи) и вернуть инстанс в работу только после проверки; обеспечить соблюдение правил с помощью AWS Firewall Manager/AWS Config.

Обоснование: Эта последовательность действий обеспечивает быструю изоляцию с минимальными привилегиями как на уровне хоста, так и на уровне сети, централизует инспекцию с помощью Network Firewall и маршрутизации Transit Gateway для минимизации радиуса поражения, сохраняет отказоустойчивость на уровне AZ благодаря NAT в каждой зоне и использует VPC Flow Logs для подотчетного расследования — что соответствует лучшим практикам AWS по созданию глубокоэшелонированной обороны.

← Защита данных и S3 · Все домены · Безопасность периметра и приложений →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Сдайте экзамен →

Просмотреть Amazon →