0Pricing
AWS Solutions Architect · Урок

Управление доступом S3: политики контейнеров и ACL

Напишите политики контейнеров, сравните их с ACL и настройте блокировку общедоступного доступа для безопасного размещения.

«Управление доступом S3: политики контейнеров и ACL» — бесплатный урок AWS Solutions Architect на CoddyKit. Это урок 2 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения AWS Solutions Architect, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс AWS Solutions Architect содержит 4 уроков всего.

Обзор контроля доступа S3

S3 предлагает несколько пересекающихся механизмов контроля доступа: политики IAM (основанные на идентификации, определяют, что могут делать субъекты), политики бакетов (политики JSON, основанные на ресурсах бакета), списки контроля доступа (ACL) (устаревшие разрешения для каждого объекта или бакета) и S3 Block Public Access (переопределение на уровне учетной записи или бакета, блокирующее любой публичный доступ независимо от других политик). В большинстве современных случаев рекомендуется использовать политики бакетов вместе с Block Public Access; ACL считаются устаревшими.

Политики Bucket: JSON на основе ресурсов

Политика Bucket — это документ JSON, непосредственно прикреплённый к S3 Bucket. В ней указано, какие субъекты (пользователи IAM, роли, аккаунты AWS, сервисы или общедоступные пользователи) могут выполнять какие действия над какими ресурсами (Bucket и/или определёнными префиксами ключей). Политики Bucket поддерживают доступ между аккаунтами без необходимости использовать роли IAM: Вы можете предоставить роли IAM другого аккаунта AWS доступ на чтение определённых объектов непосредственно в политике Bucket. Для каждого Bucket можно задать одну политику, максимальный размер которой составляет 20 КБ.

# Allow a specific IAM role from another account to read objects
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': {
      'AWS': 'arn:aws:iam::999999999999:role/PartnerReadRole'
    },
    'Action': 's3:GetObject',
    'Resource': 'arn:aws:s3:::my-bucket/partner-data/*'
  }]
}

Предоставление объектам общедоступного доступа на чтение

Чтобы предоставлять общедоступное содержимое (например, ресурсы статического веб-сайта или общедоступные наборы данных), Вы можете сделать объекты общедоступными для чтения с помощью политики Bucket. Сначала отключите Block Public Access на уровне Bucket, затем добавьте в политику Bucket оператор с Principal: '*' и Action: s3:GetObject. Необходимо одновременно отключить настройку Block Public Access и добавить Allow в политике Bucket: включение только одного из них не сработает. Всегда ограничивайте Resource конкретным префиксом, а не всем Bucket, если только Вы намеренно не хотите открыть все объекты для общего доступа.

# Public read policy for static website assets
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': '*',
    'Action': 's3:GetObject',
    'Resource': 'arn:aws:s3:::my-website-bucket/public/*'
  }]
}

Настройки S3 Block Public Access

S3 Block Public Access — это защитный механизм с четырьмя настройками, которые имеют приоритет над политиками Bucket и ACL: BlockPublicAcls (отклоняет запросы на установку общедоступных ACL), IgnorePublicAcls (игнорирует существующие общедоступные ACL), BlockPublicPolicy (отклоняет политики Bucket, предоставляющие общий доступ) и RestrictPublicBuckets (ограничивает доступ на основе общедоступной политики). По умолчанию все четыре настройки включены. Вы также можете включить Block Public Access на уровне аккаунта, запретив общий доступ для всех Bucket независимо от индивидуальных настроек Bucket. Это особенно удобно для предотвращения случайного раскрытия данных.

# Enable all Block Public Access settings on a bucket
aws s3api put-public-access-block \
  --bucket my-private-bucket \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Списки контроля доступа (ACLs): устаревший механизм

S3 ACLs — это исходный механизм контроля доступа, появившийся до IAM. ACL предоставляет предопределённые разрешения (READ, WRITE, FULL_CONTROL) аккаунтам AWS или предопределённым группам (всем пользователям, аутентифицированным пользователям AWS, службе доставки журналов). ACL можно применять на уровне Bucket или отдельного объекта. Сейчас AWS рекомендует отключать ACLs (настройка S3 «Bucket Owner Enforced» делает владельца Bucket владельцем всех объектов и отключает ACLs) и вместо них использовать политики Bucket и IAM. ACLs по-прежнему проверяются на экзамене SAA-C03 как устаревшая концепция.

# Disable ACLs by setting ownership to BucketOwnerEnforced
aws s3api put-bucket-ownership-controls \
  --bucket my-bucket \
  --ownership-controls '{"Rules":[{"ObjectOwnership":"BucketOwnerEnforced"}]}'

Origin Access Control для CloudFront

Когда Вы предоставляете содержимое S3 через CloudFront, Bucket должен оставаться закрытым, но CloudFront должен иметь возможность получать объекты. Используйте Origin Access Control (OAC) — современную замену Origin Access Identity (OAI). OAC создаёт идентификатор CloudFront, которому Вы предоставляете разрешение s3:GetObject в политике Bucket, сохраняя включённым Block Public Access. Таким образом, пользователи должны обращаться через CloudFront (для кэширования, WAF и HTTPS) и не могут получать доступ к Bucket напрямую. Это распространённый шаблон безопасной архитектуры на экзамене SAA-C03.

# Bucket policy granting CloudFront OAC access
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': {
      'Service': 'cloudfront.amazonaws.com'
    },
    'Action': 's3:GetObject',
    'Resource': 'arn:aws:s3:::my-bucket/*',
    'Condition': {
      'StringEquals': {
        'AWS:SourceArn': 'arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE'
      }
    }
  }]
}

Доступ к S3 между аккаунтами

Предоставить другому аккаунту AWS доступ к Вашему S3 Bucket можно двумя способами. Вариант 1 — политика Bucket: добавьте оператор, указав ARN внешнего аккаунта в качестве Principal и нужные действия S3. Пользователям и ролям IAM внешнего аккаунта всё равно нужны разрешения IAM для вызова S3, а политика Bucket должна дополнительно предоставить им Allow. Вариант 2 — роль IAM с политикой доверия: создайте в своём аккаунте роль, которой доверяет внешний аккаунт; субъекты внешнего аккаунта принимают эту роль и получают разрешения Вашего Bucket. Политика Bucket проще для сценариев, где требуется только чтение, а роли лучше подходят для операционного доступа.

Конфигурация CORS для веб-приложений

Cross-Origin Resource Sharing (CORS) позволяет веб-приложению, размещённому в одном домене, выполнять запросы JavaScript fetch к S3 Bucket в другом домене. Без конфигурации CORS браузеры блокируют такие запросы в целях безопасности. Вы добавляете в Bucket конфигурацию CORS, в которой указываются разрешённые источники, методы HTTP и заголовки. CORS часто требуется, когда React SPA, размещённое в example.com, получает изображения или файлы непосредственно по URL S3 Bucket.

# Apply a CORS configuration
aws s3api put-bucket-cors \
  --bucket my-website-bucket \
  --cors-configuration '{"CORSRules":[{"AllowedOrigins":["https://example.com"],"AllowedMethods":["GET"],"AllowedHeaders":["*"],"MaxAgeSeconds":3600}]}'

Предварительно подписанные URL для временного доступа

Предварительно подписанный URL предоставляет ограниченный по времени доступ к закрытому объекту S3 (для GET или PUT), не изменяя разрешения Bucket или объекта. URL содержит Ваши учётные данные и срок действия. Любой, у кого есть этот URL, может получить доступ к объекту до истечения срока действия. Используйте предварительно подписанные URL, чтобы позволить аутентифицированным пользователям Вашего приложения скачивать закрытые файлы, разрешить клиентам загружать данные непосредственно в S3 без обращения к серверной части или временно предоставлять доступ к отчётам. Срок действия может составлять от 1 секунды до 7 дней (при использовании временных учётных данных STS максимум составляет 12 часов).

# Generate a pre-signed GET URL valid for 24 hours
aws s3 presign s3://my-private-bucket/reports/invoice.pdf \
  --expires-in 86400

# Generate a pre-signed PUT URL (for client uploads)
aws s3 presign s3://my-private-bucket/uploads/new-file.pdf \
  --expires-in 3600 \
  --method PUT

Условия политики Bucket для безопасности

Используйте условия политики Bucket для добавления контекстных ограничений безопасности. Распространённые варианты: aws:SourceIp ограничивает доступ определёнными диапазонами IP (например, конечными точками VPC или корпоративными сетями); aws:SecureTransport: true принудительно требует HTTPS, отклоняя запросы через HTTP (это рекомендуемая практика для всех Bucket, в которых хранятся конфиденциальные данные); s3:x-amz-server-side-encryption гарантирует, что объекты будут загружаться с шифрованием на стороне сервера; а aws:PrincipalOrgID ограничивает доступ субъектами внутри Вашей организации AWS, предотвращая вывод данных во внешние аккаунты.

# Deny non-HTTPS access to the bucket
{
  'Effect': 'Deny',
  'Principal': '*',
  'Action': 's3:*',
  'Resource': [
    'arn:aws:s3:::my-secure-bucket',
    'arn:aws:s3:::my-secure-bucket/*'
  ],
  'Condition': {
    'Bool': {'aws:SecureTransport': 'false'}
  }
}

Конечные точки S3 VPC для закрытого доступа

По умолчанию экземпляры EC2 в закрытой подсети получают доступ к S3 через интернет (через шлюз NAT), что приводит к затратам на NAT и позволяет трафику выходить в общедоступный интернет. Шлюзовые конечные точки S3 обеспечивают закрытое подключение к S3 из VPC без шлюза NAT и не требуют дополнительной платы. Вы добавляете шлюзовую конечную точку в таблицу маршрутизации, после чего трафик к S3 автоматически направляется через закрытую сеть AWS. Вы также можете добавить в политику Bucket условия с использованием aws:SourceVpce, чтобы разрешить доступ только запросам, поступающим через эту конечную точку.

# Create an S3 gateway endpoint and associate with route tables
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-12345678

Быстрая проверка

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

Итоги урока

В этом уроке Вы узнали, что политики Bucket — это документы JSON на основе ресурсов, которые управляют доступом между аккаунтами и доступом сервисов к S3, S3 Block Public Access — это защитное переопределение, предотвращающее случайное раскрытие данных, а предварительно подписанные URL, конечные точки VPC и конфигурации CORS предназначены для безопасной реализации определённых сценариев доступа. Далее мы рассмотрим управление версиями S3, MFA Delete и репликацию.

Часто задаваемые вопросы

Урок «Управление доступом S3: политики контейнеров и ACL» бесплатный?

Да — полный текст урока «Управление доступом S3: политики контейнеров и ACL» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс AWS Solutions Architect, подпишись на CoddyKit PRO. Курс AWS Solutions Architect содержит 4 уроков всего.

Чему я научусь в уроке «Управление доступом S3: политики контейнеров и ACL»?

Напишите политики контейнеров, сравните их с ACL и настройте блокировку общедоступного доступа для безопасного размещения. Ты практикуешь AWS Solutions Architect с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать AWS Solutions Architect?

Предыдущий опыт не требуется. AWS Solutions Architect на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 2 из 4.

Сколько времени занимает урок «Управление доступом S3: политики контейнеров и ACL»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке AWS Solutions Architect?

Да. Каждый урок AWS Solutions Architect включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. Контейнеры, объекты и регионы
  2. Управление доступом S3: политики контейнеров и ACL
  3. Версионирование, MFA Delete и репликация
  4. Классы хранилищ и политики жизненного цикла
← Назад к AWS Solutions Architect