Облачная инфрастуктура основы

Cloud Fundamentals — базовые принципы работы с облачной инфраструктурой: управление доступом, создание изолированных сетей, запуск виртуальных машин, хранение объектов и фильтрация сетевого трафика.

В качестве основного примера ниже используется Amazon Web Services (AWS). Те же концепции существуют у других облачных провайдеров, хотя названия сервисов, отдельные возможности и синтаксис настроек отличаются.

Облачные ресурсы обычно создаются через:

• веб-консоль провайдера;
• CLI, например AWS CLI;
• SDK для языков программирования;
• Infrastructure as Code: Terraform, AWS CloudFormation и другие инструменты.

Пример получения сведений о текущей AWS-учётной записи:

aws sts get-caller-identity

Пример результата:

{
  "UserId": "AIDAEXAMPLE",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/developer"
}

Содержание

• Основные сервисы облака
• Модель общей ответственности
• Регионы и зоны доступности
• IAM пользователи, роли и политики
• VPC подсети и маршрутизация
• EC2 виртуальные машины в облаке
• S3 объектное хранилище
• Security Groups
• Общий пример архитектуры
• Практические рекомендации

Основные сервисы облака

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

Модели облачных услуг

EC2 — пример сервиса, близкого к IaaS: провайдер управляет физическим оборудованием и гипервизором, а пользователь — гостевой ОС и установленными приложениями.

S3 — управляемый сервис объектного хранения: пользователю не требуется администрировать файловые серверы или дисковые массивы.

Основные категории сервисов

Вычисления

Сервисы вычислений запускают виртуальные машины, контейнеры и функции:

• EC2 — виртуальные машины;
• ECS/EKS — запуск контейнеров;
• Lambda — выполнение функций без управления серверами;
• аналоги: Azure Virtual Machines, Azure Functions, Google Compute Engine, Cloud Run.

Хранение данных

Облако предлагает несколько типов хранения:

• объектное — S3;
• блочное — EBS;
• файловое — EFS;
• архивное — классы хранения S3 Glacier.

Эти типы не взаимозаменяемы. Например, EBS обычно подключается как диск к EC2, а S3 хранит объекты и предоставляет доступ к ним через API.

Сеть

К сетевым сервисам относятся:

• VPC — изолированная виртуальная сеть;
• подсети;
• таблицы маршрутизации;
• Internet Gateway и NAT Gateway;
• балансировщики нагрузки;
• DNS;
• VPN и выделенные подключения.

Идентификация и безопасность

IAM определяет, кто и какие действия может выполнять. Сетевые средства, включая Security Groups, ограничивают доступ к приложениям и виртуальным машинам.

Базы данных

Облачные провайдеры предлагают управляемые реляционные, документные, key-value и аналитические базы данных. В AWS это, например, RDS, Aurora, DynamoDB и Redshift.

Эластичность и масштабирование

Вертикальное масштабирование — изменение мощности одного ресурса, например переход EC2 с t3.micro на t3.large.

Горизонтальное масштабирование — увеличение или уменьшение количества экземпляров:

1 EC2 → 3 EC2 → 10 EC2

Эластичность означает, что объём ресурсов можно менять в соответствии с нагрузкой. Для автоматического горизонтального масштабирования EC2 применяется Auto Scaling Group.

Оплата по потреблению

В облаке часто оплачиваются:

• время работы вычислительных ресурсов;
• объём хранимых данных;
• количество операций;
• исходящий сетевой трафик;
• дополнительные управляемые сервисы.

Остановка виртуальной машины не всегда прекращает все расходы: могут продолжать тарифицироваться диски EBS, снимки, статические IP-адреса, балансировщики и другие ресурсы.

Модель общей ответственности

Безопасность облака разделена между провайдером и клиентом.

Провайдер обычно отвечает за:

• физические дата-центры;
• серверное и сетевое оборудование;
• базовую инфраструктуру облака;
• гипервизор и доступность управляемых сервисов в рамках заявленных условий.

Клиент обычно отвечает за:

• IAM-пользователей, роли и политики;
• настройки сети и межсетевых экранов;
• обновление гостевых ОС на виртуальных машинах;
• конфигурацию приложений;
• шифрование и классификацию данных;
• резервное копирование и сроки хранения;
• публичность ресурсов;
• безопасное управление секретами.

Граница ответственности зависит от типа сервиса. Для EC2 пользователь управляет ОС значительно больше, чем для полностью управляемого сервиса.

Регионы и зоны доступности

Регион — географическая область, в которой провайдер размещает инфраструктуру. В AWS регионы обозначаются кодами:

eu-central-1
us-east-1
ap-southeast-1

Availability Zone, AZ — отдельная зона доступности внутри региона. Один регион содержит несколько зон:

eu-central-1a
eu-central-1b
eu-central-1c

Ресурсы могут иметь разную область действия:

Для повышения отказоустойчивости компоненты приложения размещают как минимум в нескольких зонах доступности одного региона.

IAM: пользователи, роли и политики

AWS Identity and Access Management, IAM — сервис управления идентификацией и разрешениями. IAM отвечает на два основных вопроса:

1. Кто выполняет запрос?
2. Разрешено ли ему выполнить действие над указанным ресурсом?

Root user

При создании AWS-аккаунта появляется корневой пользователь — root user. Он обладает полным доступом к учётной записи.

Для root user рекомендуется:

• включить многофакторную аутентификацию;
• не создавать постоянные access keys;
• не использовать его для повседневной работы;
• хранить данные доступа отдельно и безопасно;
• использовать только для операций, которым действительно нужны root-права.

IAM user

IAM user представляет человека или приложение, которому требуется постоянная идентичность внутри AWS-аккаунта.

У пользователя могут быть:

• пароль для входа в консоль;
• access key для программного доступа;
• членство в IAM-группах;
• напрямую назначенные политики.

Постоянные ключи доступа требуют осторожного обращения. Для рабочих нагрузок внутри AWS предпочтительнее роли с временными учётными данными.

IAM group

IAM group объединяет пользователей. Политика, назначенная группе, применяется к её участникам.

IAM group: developers
├── alice
├── bob
└── charlie

Группы упрощают назначение одинаковых разрешений нескольким пользователям. Роли нельзя добавлять в IAM-группы, а группы не вкладываются друг в друга.

IAM role

IAM role — идентичность с набором разрешений, которую можно временно принять. У роли нет постоянного пароля и обычной пары access key/secret key.

Роли применяются для:

• доступа EC2 к S3;
• выполнения Lambda-функций;
• CI/CD-процессов;
• доступа пользователей через федерацию;
• доступа между AWS-аккаунтами;
• выдачи временных полномочий.

Для EC2 роль связывается с экземпляром через instance profile. Приложение получает временные credentials автоматически и не должно хранить ключи в конфигурационном файле.

EC2 instance
    ↓ принимает роль
IAM role: app-role
    ↓ разрешает
s3:GetObject для нужного bucket

У роли есть два разных вида настроек:

• trust policy — кто может принять роль;
• permissions policies — что разрешено делать после принятия роли.

Пример trust policy, позволяющей сервису EC2 принимать роль:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

IAM policy

IAM policy — JSON-документ, описывающий разрешённые или запрещённые действия.

Основные элементы политики:

Пример политики чтения объектов из определённого bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::company-documents"
    },
    {
      "Sid": "ReadObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::company-documents/*"
    }
  ]
}

Bucket и объекты имеют разные ARN:

arn:aws:s3:::company-documents
arn:aws:s3:::company-documents/*

Первый ARN относится к bucket, второй — к объектам внутри него.

Identity-based и resource-based policies

Identity-based policy назначается пользователю, группе или роли и определяет, что эта идентичность может делать.

Resource-based policy назначается ресурсу и определяет, кто может к нему обращаться. Пример — bucket policy в S3.

Пример bucket policy, разрешающей чтение роли из определённого аккаунта:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowApplicationRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/app-role"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::company-documents/*"
    }
  ]
}

Логика проверки разрешений

Упрощённая модель:

1. По умолчанию доступ запрещён — implicit deny.
2. Подходящий Allow может разрешить действие.
3. Подходящий явный Deny имеет приоритет над Allow.

Explicit Deny > Allow > Implicit Deny

На итоговое решение могут также влиять resource policies, permissions boundaries, session policies и организационные ограничения.

Принцип наименьших привилегий

Пользователю или сервису следует выдавать только те разрешения, которые необходимы для конкретной задачи.

Нежелательный вариант:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Более безопасный вариант:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": "arn:aws:s3:::company-documents/reports/*"
}

MFA и временные credentials

MFA требует дополнительный фактор кроме пароля. MFA особенно важна для привилегированных пользователей.

Временные credentials обычно состоят из:

• access key ID;
• secret access key;
• session token;
• времени истечения.

Их выдаёт AWS Security Token Service при принятии роли или создании временной сессии.

Проверка текущей идентичности

aws sts get-caller-identity

Получение списка ролей:

aws iam list-roles

AWS CLI использует credentials из выбранного профиля, переменных окружения, роли вычислительного ресурса или других поддерживаемых источников.

VPC: подсети и маршрутизация

Virtual Private Cloud, VPC — логически изолированная виртуальная сеть в выбранном регионе AWS.

При создании VPC задаётся диапазон IP-адресов в формате CIDR:

10.0.0.0/16

Такой IPv4-диапазон содержит адреса от 10.0.0.0 до 10.0.255.255 — всего 65 536 адресов до учёта особенностей их использования провайдером.

CIDR

CIDR-запись состоит из адреса сети и длины префикса:

10.0.1.0/24

Чем больше длина префикса, тем меньше сеть:

AWS резервирует часть IPv4-адресов в каждой подсети, поэтому не все адреса доступны для ресурсов.

Подсеть

Subnet — часть адресного пространства VPC, расположенная в одной Availability Zone.

Пример разделения VPC:

VPC 10.0.0.0/16
├── public-a   10.0.1.0/24   AZ-a
├── public-b   10.0.2.0/24   AZ-b
├── private-a  10.0.11.0/24  AZ-a
└── private-b  10.0.12.0/24  AZ-b

Подсеть называют публичной или приватной не из-за имени, а из-за маршрутизации и доступности ресурсов.

Публичная подсеть

Публичная подсеть имеет маршрут к Internet Gateway:

0.0.0.0/0 → Internet Gateway

Чтобы EC2 могла обмениваться IPv4-трафиком с интернетом напрямую, обычно необходимы одновременно:

• маршрут через Internet Gateway;
• публичный IPv4-адрес или Elastic IP;
• разрешение в Security Group;
• отсутствие блокирующих правил Network ACL;
• работающая служба на виртуальной машине.

Наличие одного Internet Gateway не делает каждый ресурс VPC публичным автоматически.

Приватная подсеть

У приватной подсети нет прямого маршрута к Internet Gateway. Серверы приложений и базы данных часто размещают именно в приватных подсетях.

Для исходящего доступа IPv4 из приватной подсети может использоваться NAT Gateway:

Private EC2
    ↓
Route table: 0.0.0.0/0 → NAT Gateway
    ↓
NAT Gateway в публичной подсети
    ↓
Internet Gateway
    ↓
Интернет

NAT Gateway позволяет инициировать исходящие соединения, но сам по себе не публикует приватную EC2 для входящих соединений из интернета.

Internet Gateway

Internet Gateway, IGW подключается к VPC и служит целью маршрута для интернет-трафика.

Типичная запись в таблице маршрутизации публичной подсети:

Маршрут local обеспечивает связь между подсетями внутри VPC. Он создаётся автоматически для CIDR VPC.

Route table

Route table содержит маршруты, определяющие, куда направлять сетевой трафик.

У каждого маршрута есть:

• destination — сеть назначения;
• target — следующий сетевой компонент.

Пример таблицы приватной подсети:

Применяется наиболее специфичный подходящий маршрут. Например, маршрут 10.0.0.0/16 специфичнее, чем 0.0.0.0/0.

Каждая подсеть связана с одной route table. Одна route table может быть связана с несколькими подсетями.

Public и private IP

Private IP используется для связи внутри VPC и связанных частных сетей. Он не маршрутизируется напрямую через общедоступный интернет.

Public IP обеспечивает интернет-адресацию при наличии соответствующей маршрутизации и правил безопасности.

Elastic IP — статический публичный IPv4-адрес AWS, который можно назначать поддерживаемым ресурсам. Неиспользуемые и некоторые используемые публичные IPv4-адреса могут тарифицироваться согласно действующим условиям провайдера.

IPv6

VPC и подсети могут получать IPv6-диапазоны. Для IPv6 не используется NAT как обязательный механизм сохранения частных адресов. Публичный исходящий и входящий трафик может проходить через Internet Gateway при наличии маршрута и разрешающих правил.

Для исходящего IPv6-доступа без принятия входящих соединений применяется egress-only Internet Gateway.

Пример маршрута IPv6:

::/0 → Internet Gateway

Network ACL

Network ACL, NACL — дополнительный сетевой фильтр на уровне подсети.

Основные отличия от Security Group:

Для большинства задач основным средством фильтрации ресурсов являются Security Groups. NACL может использоваться как дополнительный уровень контроля подсети.

VPC Endpoint

VPC Endpoint позволяет обращаться к поддерживаемым AWS-сервисам без прохождения трафика через общедоступный интернет.

Например, gateway endpoint для S3 может дать приватным EC2 доступ к S3 без NAT Gateway:

Private EC2 → VPC Endpoint → S3

Это может повысить изоляцию и уменьшить зависимость от интернет-маршрута.

Базовая схема VPC

Internet
   │
Internet Gateway
   │
Public route table
   ├── Public subnet A: Load Balancer, NAT Gateway
   └── Public subnet B: Load Balancer, NAT Gateway
             │
             ▼
Private route tables
   ├── Private subnet A: Application EC2
   └── Private subnet B: Application EC2

EC2: виртуальные машины в облаке

Amazon Elastic Compute Cloud, EC2 — сервис запуска виртуальных серверов, называемых instances.

При создании экземпляра выбираются:

• образ операционной системы;
• тип экземпляра;
• VPC и подсеть;
• диски;
• Security Groups;
• IAM role;
• способ доступа и дополнительные настройки.

AMI

Amazon Machine Image, AMI — шаблон, на основе которого запускается EC2.

AMI определяет:

• операционную систему;
• базовое программное обеспечение;
• настройки корневого диска;
• разрешения на использование образа;
• архитектуру процессора.

Один AMI можно использовать для запуска нескольких одинаковых экземпляров.

Тип экземпляра

Тип EC2 определяет сочетание CPU, памяти, сети и других характеристик.

Примеры семейств:

Конкретный размер указывается после семейства:

t3.micro
m7i.large
c7g.xlarge

Жизненный цикл EC2

Основные состояния:

pending → running → stopping → stopped → shutting-down → terminated

• running — экземпляр запущен;
• stopped — вычисления остановлены, но подключённые EBS-тома обычно сохраняются;
• terminated — экземпляр удалён; восстановить его как тот же экземпляр нельзя.

При остановке и повторном запуске автоматически назначенный публичный IPv4-адрес может измениться. Elastic IP остаётся статическим, пока не будет освобождён или переназначен.

EBS

Elastic Block Store, EBS предоставляет блочные тома для EC2. Для операционной системы такой том выглядит как диск.

EBS используется для:

• корневого диска;
• файловой системы приложения;
• данных, которым требуется блочное хранилище;
• создания snapshots.

EBS-том создаётся в конкретной Availability Zone и обычно подключается к экземпляру в той же зоне.

Instance store

Некоторые типы EC2 предоставляют локальное временное хранилище instance store. Оно связано с физическим хостом и не подходит для единственной копии важных данных.

Данные instance store могут быть потеряны при остановке, завершении или неисправности экземпляра.

Подключение по SSH

Для Linux-экземпляра типичная команда выглядит так:

ssh -i ~/.ssh/app-server.pem ec2-user@203.0.113.10

Приватный ключ следует защитить правами файловой системы:

chmod 600 ~/.ssh/app-server.pem

Security Group должна разрешать TCP-порт 22 от доверенного адреса. Не рекомендуется открывать SSH для всего интернета:

0.0.0.0/0 → TCP 22

Предпочтительнее ограничить административный доступ конкретной сетью, использовать VPN, bastion host или управляемый механизм удалённого доступа, например AWS Systems Manager Session Manager.

User data

User data позволяет выполнить сценарий первоначальной настройки при запуске экземпляра.

Пример для Linux:

#!/bin/bash
set -e

dnf install -y nginx
systemctl enable --now nginx

echo '<h1>Hello from EC2</h1>' > /usr/share/nginx/html/index.html

User data удобно использовать для начальной установки, но сложную конфигурацию лучше делать воспроизводимыми инструментами: готовыми образами, Ansible или другими средствами управления конфигурацией.

IAM role для EC2

Не следует сохранять постоянные AWS access keys на виртуальной машине:

/home/ec2-user/.aws/credentials

Вместо этого EC2 назначают IAM role. AWS SDK и CLI могут автоматически получать временные credentials через метаданные экземпляра.

Пример команды, выполняемой на EC2 с подходящей ролью:

aws s3 cp s3://company-documents/config/app.yml /opt/app/app.yml

Метаданные экземпляра

EC2 Instance Metadata Service предоставляет сведения об экземпляре локально. Для повышения защиты следует использовать IMDSv2, который требует токен сессии.

Пример получения токена и идентификатора экземпляра:

TOKEN=$(curl -sS -X PUT \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
  http://169.254.169.254/latest/api/token)

curl -sS \
  -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

Доступ приложения к метаданным необходимо учитывать при защите от SSRF и настройке сетевых переходов IMDS.

Модели оплаты

Распространённые варианты:

• On-Demand — оплата без долгосрочного обязательства;
• Savings Plans/Reserved capacity — скидка в обмен на обязательство по использованию или оплате;
• Spot Instances — свободная мощность со скидкой, но экземпляр может быть прерван;
• Dedicated Hosts/Instances — выделенные варианты размещения.

Spot подходит для отказоустойчивых и прерываемых задач: batch-обработки, очередей, некоторых CI-задач.

Масштабирование и балансировка

Типичная отказоустойчивая схема:

Internet
   ↓
Application Load Balancer
   ├── EC2 в AZ-a
   └── EC2 в AZ-b
        ↑
Auto Scaling Group

Load Balancer распределяет запросы, а Auto Scaling Group поддерживает требуемое количество экземпляров и может изменять его по метрикам.

S3: объектное хранилище

Amazon Simple Storage Service, S3 — сервис объектного хранения.

S3 хранит данные как объекты внутри bucket:

s3://company-documents/reports/2026/september.pdf

Здесь:

• company-documents — bucket;
• reports/2026/september.pdf — key объекта;
• содержимое файла — data;
• дополнительные сведения — metadata.

Объектное и файловое хранение

S3 не является обычной сетевой файловой системой.

Символ / в ключе создаёт визуальное представление папок, но остаётся частью имени ключа.

Bucket

Bucket создаётся в выбранном регионе. Имя bucket должно соответствовать правилам S3 и быть уникальным в применимом глобальном пространстве имён AWS.

Пример создания bucket через AWS CLI:

aws s3api create-bucket \
  --bucket company-documents-123456789012 \
  --region eu-central-1 \
  --create-bucket-configuration LocationConstraint=eu-central-1

Синтаксис создания может отличаться для отдельных регионов.

Операции с объектами

Загрузка файла:

aws s3 cp report.pdf \
  s3://company-documents-123456789012/reports/report.pdf

Скачивание:

aws s3 cp \
  s3://company-documents-123456789012/reports/report.pdf \
  ./report.pdf

Список объектов:

aws s3 ls \
  s3://company-documents-123456789012/reports/ \
  --recursive

Синхронизация каталога:

aws s3 sync ./public/ \
  s3://company-site-123456789012/

Удаление объекта:

aws s3 rm \
  s3://company-documents-123456789012/reports/report.pdf

Доступ к S3

Доступ может определяться несколькими механизмами:

• IAM policies;
• bucket policies;
• access point policies;
• Block Public Access;
• ACL для устаревших или специальных сценариев;
• ключами шифрования KMS и их policies;
• VPC endpoint policies;
• организационными ограничениями.

Для большинства приватных bucket рекомендуется:

• включить S3 Block Public Access;
• использовать IAM и bucket policies;
• отключить использование ACL там, где это возможно;
• выдавать минимальные разрешения.

Block Public Access

S3 Block Public Access помогает предотвратить случайное открытие bucket или объектов. Настройки могут применяться на уровне аккаунта и отдельного bucket.

Публичный доступ следует включать только осознанно. Для публикации веб-контента часто безопаснее использовать CDN с приватным origin, чем делать bucket полностью публичным.

Versioning

Versioning сохраняет несколько версий одного ключа. Это помогает восстановиться после случайного удаления или перезаписи.

Включение versioning:

aws s3api put-bucket-versioning \
  --bucket company-documents-123456789012 \
  --versioning-configuration Status=Enabled

Versioning не заменяет полноценную стратегию резервного копирования: необходимо учитывать права удаления версий, репликацию, сроки хранения и независимость резервных копий.

Шифрование

Данные следует защищать при передаче и хранении.

Для передачи используется HTTPS/TLS. Шифрование на стороне сервера может выполняться с ключами, управляемыми S3, или с ключами AWS KMS.

Пример загрузки с указанием SSE-KMS:

aws s3 cp backup.tar.gz \
  s3://company-backups-123456789012/ \
  --sse aws:kms \
  --sse-kms-key-id alias/company-backups

При использовании KMS субъекту нужны не только разрешения S3, но и соответствующие разрешения на KMS key.

Классы хранения

Класс хранения выбирают по частоте доступа, требованиям к задержке, доступности и сроку хранения.

У некоторых классов есть минимальная продолжительность хранения, минимальный тарифицируемый размер объекта или стоимость извлечения.

Lifecycle rules

Lifecycle policy автоматически переводит объекты в другие классы или удаляет их по заданным условиям.

Пример конфигурации:

{
  "Rules": [
    {
      "ID": "archive-logs",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ],
      "Expiration": {
        "Days": 2555
      }
    }
  ]
}

Перед удалением данных необходимо проверить требования к срокам хранения и возможность восстановления.

Presigned URL

Presigned URL предоставляет временный доступ к конкретной операции без выдачи пользователю постоянных AWS credentials.

Пример ссылки на скачивание сроком на 15 минут:

aws s3 presign \
  s3://company-documents-123456789012/reports/report.pdf \
  --expires-in 900

Ссылка наследует возможности субъекта, который её создал, и действует ограниченное время.

CORS

Если веб-приложение обращается к S3 из браузера с другого origin, может потребоваться настройка CORS.

Пример:

[
  {
    "AllowedOrigins": [
      "https://app.example.com"
    ],
    "AllowedMethods": [
      "GET",
      "PUT"
    ],
    "AllowedHeaders": [
      "*"
    ],
    "ExposeHeaders": [
      "ETag"
    ],
    "MaxAgeSeconds": 3600
  }
]

CORS не является механизмом авторизации. Он управляет поведением браузера, а реальный доступ всё равно определяется IAM и политиками ресурса.

Статический веб-сайт

S3 может размещать статические файлы HTML, CSS и JavaScript. Однако website endpoint не заменяет полноценную CDN-конфигурацию и имеет ограничения безопасности. Для HTTPS и контроля доступа обычно используют CDN перед S3.

Security Groups

Security Group, SG — виртуальный stateful firewall для сетевого интерфейса ресурса, например EC2.

Security Group содержит:

• inbound rules — входящий трафик;
• outbound rules — исходящий трафик.

Правила только разрешают трафик. Явного Deny в Security Groups нет.

Stateful-фильтрация

Security Groups являются stateful. Если входящий запрос разрешён, ответный трафик пропускается автоматически независимо от outbound rules для ответного потока.

То же относится к ответам на разрешённые исходящие соединения.

Структура правила

Правило включает:

• протокол;
• порт или диапазон портов;
• источник для inbound либо назначение для outbound;
• необязательное описание.

Пример правил веб-сервера:

Если используется IPv6, правила для 0.0.0.0/0 не распространяются на IPv6. Для всего IPv6-пространства используется:

::/0

Ссылки на другие Security Groups

Вместо IP-диапазона источником можно указать другую Security Group.

Пример трёхуровневого приложения:

Internet
   ↓ TCP 443
SG: load-balancer
   ↓ TCP 8080
SG: application
   ↓ TCP 5432
SG: database

Правила:

load-balancer-sg:
  inbound TCP 443 from 0.0.0.0/0

application-sg:
  inbound TCP 8080 from load-balancer-sg

database-sg:
  inbound TCP 5432 from application-sg

Это устойчивее, чем разрешение по динамическим IP-адресам экземпляров.

Ссылка на Security Group означает разрешение трафика от сетевых интерфейсов, связанных с указанной SG, при выполнении сетевых условий. Она не означает, что правила исходной SG автоматически копируются или что одна группа «входит» в другую.

Несколько Security Groups

К сетевому интерфейсу можно привязать несколько Security Groups. Их разрешающие правила объединяются.

SG-A разрешает TCP 443
SG-B разрешает TCP 22
Итог: разрешены TCP 443 и TCP 22

Нельзя использовать одну Security Group для отмены разрешения, выданного другой группой, поскольку запрещающих правил нет.

Пример AWS CLI

Создание группы:

aws ec2 create-security-group \
  --group-name web-sg \
  --description "Web server security group" \
  --vpc-id vpc-0123456789abcdef0

Разрешение HTTPS:

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

Разрешение SSH только с одного IPv4-адреса:

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 22 \
  --cidr 203.0.113.10/32

Типичные ошибки

Открытие административных портов всему интернету

Небезопасный пример:

TCP 22 from 0.0.0.0/0
TCP 3389 from 0.0.0.0/0

Следует ограничивать доступ доверенными IP, VPN или управляемыми средствами администрирования.

Открытие базы данных всему интернету

Нежелательный вариант:

TCP 5432 from 0.0.0.0/0

Безопаснее разрешить доступ только от Security Group приложения.

Избыточный outbound-доступ

Разрешение всего исходящего трафика удобно, но для критичных систем может быть слишком широким. Исходящие правила можно ограничить необходимыми направлениями и портами с учётом DNS, обновлений, API и ответного трафика.

Путаница между Security Group и процессом приложения

Разрешённый порт в Security Group не запускает службу. Для доступности приложения одновременно нужны:

• процесс слушает нужный порт;
• процесс слушает подходящий интерфейс, например 0.0.0.0, а не только 127.0.0.1;
• локальный firewall ОС разрешает соединение;
• Security Group разрешает трафик;
• маршрутизация и адреса настроены правильно;
• NACL не блокирует соединение.

Общий пример архитектуры

Рассмотрим веб-приложение, которое работает на EC2 и сохраняет пользовательские файлы в S3.

Требования

• HTTPS-доступ из интернета;
• приложение не имеет публичных IP-адресов;
• серверы размещены в двух Availability Zones;
• доступ приложения к S3 выполняется без постоянных ключей;
• S3 bucket закрыт от публичного доступа;
• административный доступ не требует открытого SSH.

Схема

Users
  │ HTTPS 443
  ▼
Application Load Balancer
  │ SG: alb-sg
  ├──────────────────────┐
  ▼                      ▼
Private subnet A         Private subnet B
EC2 application          EC2 application
SG: app-sg               SG: app-sg
  │                      │
  └──────────┬───────────┘
             │ IAM role + VPC endpoint
             ▼
      Private S3 bucket

Сеть

VPC: 10.0.0.0/16

Public subnets:
  10.0.1.0/24 — AZ-a
  10.0.2.0/24 — AZ-b

Private application subnets:
  10.0.11.0/24 — AZ-a
  10.0.12.0/24 — AZ-b

Публичные подсети имеют маршрут:

0.0.0.0/0 → Internet Gateway

EC2 располагаются в приватных подсетях. Для доступа к S3 создаётся VPC endpoint. Если экземплярам нужен общий исходящий IPv4-доступ в интернет, добавляются NAT Gateway и соответствующие маршруты.

Security Groups

alb-sg:

Inbound:
  TCP 443 from 0.0.0.0/0
  TCP 443 from ::/0

Outbound:
  TCP 8080 to app-sg

app-sg:

Inbound:
  TCP 8080 from alb-sg

Outbound:
  HTTPS 443 к необходимым сервисам или endpoint

Прямой входящий доступ из интернета к EC2 отсутствует.

IAM role приложения

EC2 получает роль application-role. Политика разрешает работу только с выделенным префиксом bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListUploads",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::company-app-data",
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "uploads/*"
          ]
        }
      }
    },
    {
      "Sid": "ManageUploadObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::company-app-data/uploads/*"
    }
  ]
}

Приложению не выдаются разрешения на изменение bucket policy или удаление всего bucket.

S3

Для bucket включаются:

• Block Public Access;
• шифрование по умолчанию;
• versioning при необходимости восстановления версий;
• lifecycle rules для устаревших объектов;
• журналирование и аудит в соответствии с требованиями проекта.

Приложение получает временные credentials через роль EC2 и работает с S3 через SDK:

import boto3

s3 = boto3.client("s3")

s3.upload_file(
    "photo.jpg",
    "company-app-data",
    "uploads/photo.jpg",
)

В коде нет статических access keys. SDK использует цепочку поиска credentials и получает временные данные роли экземпляра.

Последовательность запроса

1. Пользователь отправляет HTTPS-запрос на Load Balancer.
2. Security Group балансировщика разрешает TCP 443.
3. Load Balancer перенаправляет запрос на EC2 по TCP 8080.
4. app-sg принимает TCP 8080 только от alb-sg.
5. Приложение получает временные credentials IAM role.
6. Приложение загружает объект в разрешённый префикс S3.
7. S3 проверяет IAM policy, bucket policy и дополнительные ограничения.
8. Объект сохраняется с настроенным шифрованием.

Практические рекомендации

IAM

• Включайте MFA для root user и привилегированных учётных записей.
• Не используйте root user для повседневных операций.
• Предпочитайте временные credentials и IAM roles постоянным access keys.
• Следуйте принципу наименьших привилегий.
• Ограничивайте Action, Resource и при необходимости добавляйте Condition.
• Регулярно проверяйте неиспользуемые учётные данные и разрешения.
• Не помещайте access keys в Git, AMI, user data и образы контейнеров.

VPC

• Планируйте CIDR заранее и избегайте пересечения сетей, которые могут соединяться.
• Размещайте публично доступными только те компоненты, которым это необходимо.
• Распределяйте отказоустойчивые компоненты по нескольким Availability Zones.
• Используйте отдельные route tables для разных типов подсетей, если их маршрутизация отличается.
• Применяйте VPC endpoints для приватного доступа к поддерживаемым сервисам.
• Проверяйте маршруты, Security Groups, NACL и DNS как единую цепочку.

EC2

• Используйте актуальные и доверенные AMI.
• Устанавливайте обновления ОС и приложений.
• Назначайте IAM role вместо сохранения ключей на сервере.
• Включайте IMDSv2 и ограничивайте доступ к метаданным.
• Не храните единственную копию важных данных в instance store.
• Настраивайте мониторинг, логи и резервное копирование.
• Используйте Auto Scaling и несколько AZ для критичных приложений.
• Удаляйте неиспользуемые экземпляры, диски, snapshots и адреса с учётом требований хранения.

S3

• Включайте Block Public Access, если публичность не является явным требованием.
• Используйте HTTPS и шифрование данных.
• Настраивайте versioning и lifecycle rules осознанно.
• Ограничивайте доступ конкретными bucket, префиксами и операциями.
• Учитывайте стоимость хранения, запросов, извлечения и передачи данных.
• Не воспринимайте versioning как полную замену резервного копирования.
• Используйте presigned URLs для ограниченного временного доступа.

Security Groups

• Не открывайте административные и служебные порты для 0.0.0.0/0 и ::/0 без необходимости.
• Используйте ссылки на Security Groups между уровнями приложения.
• Добавляйте описания к правилам.
• Удаляйте устаревшие правила.
• Ограничивайте исходящий трафик там, где это оправдано требованиями безопасности.
• Помните, что Security Group не заменяет обновление ОС, безопасную конфигурацию приложения и контроль IAM.

Контрольный список диагностики соединения с EC2

Если сервис недоступен, последовательно проверьте:

1. Экземпляр находится в состоянии running.
2. Приложение запущено и слушает ожидаемый порт.
3. Приложение слушает нужный сетевой интерфейс.
4. Локальный firewall ОС разрешает трафик.
5. Security Group разрешает входящий трафик от нужного источника.
6. Security Group назначения разрешает требуемый исходящий трафик.
7. NACL разрешает прямой и обратный трафик.
8. Route table содержит необходимый маршрут.
9. Для интернет-доступа настроены IGW, публичный адрес или NAT в зависимости от направления.
10. DNS-имя разрешается в ожидаемый IP-адрес.
11. Load Balancer считает target здоровым, если используется балансировка.

Контрольный список доступа к S3

Если операция S3 получает AccessDenied, проверьте:

1. Какая идентичность используется: aws sts get-caller-identity.
2. Есть ли подходящий Allow в identity-based policy.
3. Правильно ли указаны ARN bucket и объектов.
4. Нет ли явного Deny в IAM или bucket policy.
5. Не блокирует ли доступ permissions boundary или session policy.
6. Не ограничивает ли запрос VPC endpoint policy.
7. Есть ли права на KMS key при SSE-KMS.
8. Не запрещён ли запрос условиями aws:SourceVpc, aws:SourceVpce, IP или TLS.
9. Совпадают ли регион, имя bucket и key объекта.
10. Не пытается ли команда выполнить дополнительное действие, например s3:ListBucket.

Главный принцип облачной архитектуры: идентичность определяет, кто может выполнить действие; сеть определяет, откуда и куда может пройти трафик; конфигурация ресурса определяет, как сервис обработает разрешённый запрос.