Безопасность облачного хранилища и риски раскрытия данных
Узнайте, как неправильно настроенные контейнеры S3, Azure Blob и GCS приводят к раскрытию данных и как применять политики контейнеров и средства управления доступом.
«Безопасность облачного хранилища и риски раскрытия данных» — бесплатный урок Cloud & IT Cert Prep на CoddyKit. Это урок 2 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Cloud & IT Cert Prep, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Cloud & IT Cert Prep содержит 4 уроков всего.
Основы объектного хранилища в облаке
Облачное объектное хранилище — AWS S3, Azure Blob Storage и Google Cloud Storage (GCS) — хранит файлы в виде объектов в плоских пространствах имён, называемых bucket или контейнерами. В отличие от традиционных файловых систем, разрешения задаются политиками, прикреплёнными к bucket и объектам, а не списками ACL файловой системы. Объектное хранилище подходит для работы с большими объёмами данных, но требует тщательной настройки разрешений: всего один неправильно настроенный bucket может открыть терабайты конфиденциальных данных всему Интернету.
Неправильная конфигурация общедоступных bucket
Самая распространённая уязвимость облачного хранилища — общедоступный bucket, то есть bucket, политика доступа которого разрешает анонимное чтение (или запись). Такая ошибка конфигурации стала причиной десятков крупных утечек: Verizon (14 млн записей клиентов), FedEx (119 000 паспортов), Capital One (100 млн заявок на кредитные карты). Злоумышленники используют автоматические сканеры для поиска общедоступных bucket по всем известным шаблонам имён аккаунтов AWS, поэтому после появления неправильной конфигурации обнаружить такой bucket очень просто.
# Check if S3 bucket is publicly accessible
aws s3api get-bucket-policy --bucket my-bucket
aws s3api get-bucket-acl --bucket my-bucket
# Block all public access (AWS recommended default)
aws s3api put-public-access-block \
--bucket my-bucket \
--public-access-block-configuration \
'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'Политики bucket и списки ACL
Облачное хранилище использует два типа средств управления доступом, которые могут конфликтовать. Политики bucket — это документы JSON, прикреплённые к bucket и определяющие, какие субъекты какие действия могут выполнять. Списки контроля доступа (ACL) — устаревший способ назначения разрешений для отдельных объектов. AWS рекомендует отключать ACL и использовать вместо них политики bucket для единообразия. Если применяются оба механизма, действует наиболее разрешающая политика, то есть чрезмерно разрешающий ACL может открыть публичный доступ, даже если политика bucket его ограничивает.
# S3 bucket policy example — restrict to specific account
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': { 'AWS': 'arn:aws:iam::123456789012:root' },
'Action': 's3:GetObject',
'Resource': 'arn:aws:s3:::my-bucket/*'
}]
}
# All other principals implicitly deniedШифрование объектов в состоянии покоя
Провайдеры облачного хранилища предлагают серверное шифрование объектов в состоянии покоя. SSE-S3 (AWS) автоматически использует ключи, управляемые AWS. SSE-KMS использует ключи, которыми заказчик управляет в AWS Key Management Service, обеспечивая более подробные журналы аудита (каждая расшифровка записывается в CloudTrail) и управление ротацией ключей. SSE-C использует ключи, предоставленные заказчиком, который полностью управляет ими за пределами AWS. Для конфиденциальных данных SSE-KMS с ключами, управляемыми заказчиком, обеспечивает наиболее полный контроль и убедительные свидетельства соответствия требованиям.
# Enforce encryption on S3 bucket (deny unencrypted uploads)
{
'Effect': 'Deny',
'Principal': '*',
'Action': 's3:PutObject',
'Resource': 'arn:aws:s3:::my-secure-bucket/*',
'Condition': {
'StringNotEquals': {
's3:x-amz-server-side-encryption': 'aws:kms'
}
}
}Шифрование при передаче
Даже правильно зашифрованные данные в состоянии покоя могут быть раскрыты при передаче по незашифрованным каналам. Доступ ко всем API облачного хранилища следует осуществлять исключительно через HTTPS/TLS. Для S3 политики bucket могут принудительно требовать HTTPS, запрещая запросы с параметром aws:SecureTransport: false. Предварительно подписанные URL — временные URL с аутентификацией, предоставляющие ограниченный по времени доступ к объектам, — всегда должны использовать HTTPS и иметь короткий срок действия, чтобы при перехвате сократить период возможного раскрытия данных.
# S3 bucket policy — deny HTTP (require HTTPS)
{
'Effect': 'Deny',
'Principal': '*',
'Action': 's3:*',
'Resource': ['arn:aws:s3:::my-bucket', 'arn:aws:s3:::my-bucket/*'],
'Condition': {
'Bool': { 'aws:SecureTransport': 'false' }
}
}Классификация данных и уровни хранения
Не всем данным требуется одинаковый уровень защиты. Конфиденциальные данные (PII, PHI, финансовые записи) необходимо хранить в зашифрованных bucket с ограниченным доступом и включённым журналом аудита. Для менее конфиденциальных данных доступ может быть более широким. Метки классификации данных следует назначать при создании объекта и использовать для автоматической маршрутизации данных в хранилища с соответствующей конфигурацией. Политики, автоматически перемещающие данные в более защищённое хранилище на основании меток классификации, снижают вероятность попадания конфиденциальных данных в недостаточно защищённые bucket.
Ведение журналов и мониторинг доступа к облачному хранилищу
Ведение журналов доступа необходимо для обнаружения несанкционированного доступа постфактум и проведения аудита соответствия требованиям. Журналы доступа AWS S3 и ведение журналов событий данных CloudTrail записывают каждый вызов API на уровне объекта: кто запросил объект, с какого IP и в какое время. Диагностические журналы Azure Blob и журналы аудита GCS предоставляют аналогичные возможности. Без этих журналов после обнаружения утечки данных не останется криминалистических свидетельств, и определить масштаб раскрытия будет невозможно.
# Enable S3 access logging
aws s3api put-bucket-logging \
--bucket my-bucket \
--bucket-logging-status '{
"LoggingEnabled": {
"TargetBucket": "my-access-logs-bucket",
"TargetPrefix": "my-bucket-logs/"
}
}'Риски межаккаунтного доступа
Облачное хранилище часто используется совместно несколькими аккаунтами (разработка, подготовка, рабочая среда, сторонние партнёры). Неосторожно настроенный межаккаунтный доступ может предоставить чрезмерные разрешения. Рекомендуется указывать в политиках bucket конкретные идентификаторы аккаунтов, а не субъектов-шаблонов, использовать AWS Organizations SCPs, чтобы вообще ограничить список внешних аккаунтов, которым можно предоставлять доступ, регулярно проверять межаккаунтные разрешения и отдавать предпочтение AWS PrivateLink перед публичным Интернетом при передаче данных между аккаунтами.
Версионирование и защита от удаления
Версионирование объектов сохраняет все версии объекта, включая удалённые. Это защищает от случайного удаления, шифрования объектов программами-вымогателями и угроз со стороны инсайдеров. Для критически важных данных сочетайте версионирование с Object Lock (аналог S3 Glacier Vault Lock) — политикой WORM (однократная запись, многократное чтение), которая запрещает удаление или изменение в течение заданного срока хранения. Object Lock может удовлетворять нормативным требованиям к неизменяемым записям в финансовой сфере и здравоохранении.
# Enable S3 versioning
aws s3api put-bucket-versioning \
--bucket my-critical-bucket \
--versioning-configuration Status=Enabled
# Enable Object Lock (immutable storage)
aws s3api put-object-lock-configuration \
--bucket my-critical-bucket \
--object-lock-configuration \
'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=365}}'Обнаружение неправильных конфигураций хранилища с помощью CSPM
Инструменты Cloud Security Posture Management (CSPM) автоматически проверяют конфигурации облачного хранилища по эталонам безопасности. Проверки CSPM включают: есть ли общедоступные bucket? Включено ли шифрование в состоянии покоя? Включено ли ведение журналов? Включено ли версионирование для критически важных bucket? Не являются ли политики bucket чрезмерно разрешающими? Такие инструменты CSPM, как Prisma Cloud, Wiz и AWS Security Hub, обеспечивают непрерывный мониторинг соответствия требованиям и предупреждают об изменениях конфигурации до того, как их обнаружат злоумышленники.
Предварительно подписанные URL и временный доступ
Предварительно подписанные URL предоставляют ограниченный по времени доступ к определённым объектам без необходимости иметь учётные данные AWS. Они удобны для обмена файлами с внешними сторонами. Риски безопасности включают: чрезмерно длительный срок действия URL, из-за которого они остаются доступными после предполагаемого периода обмена; пересылку URL получателями за пределы предусмотренной аудитории; появление токенов, встроенных в URL, в журналах серверов. Всегда устанавливайте минимально возможный срок действия и не допускайте записи предварительно подписанных URL в журналы.
# Generate a pre-signed URL (expires in 3600 seconds)
aws s3 presign s3://my-bucket/report.pdf \
--expires-in 3600
# Returns a URL valid for 1 hour
# After expiry, the URL returns 403 Forbidden
# Best practice: shortest expiry viable for the use caseБыстрая проверка
Проверьте понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.
Итоги урока
В этом уроке Вы узнали, что неправильная конфигурация общедоступных bucket является самой распространённой причиной утечек данных из облачного хранилища, SSE-KMS обеспечивает наиболее полный контроль шифрования и ведение журналов аудита через CloudTrail, а версионирование объектов в сочетании с Object Lock защищает критически важные данные от программ-вымогателей и удаления инсайдерами. Далее мы рассмотрим облачные удостоверения, роли IAM и сервисные аккаунты.
Часто задаваемые вопросы
Урок «Безопасность облачного хранилища и риски раскрытия данных» бесплатный?
Да — полный текст урока «Безопасность облачного хранилища и риски раскрытия данных» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Cloud & IT Cert Prep, подпишись на CoddyKit PRO. Курс Cloud & IT Cert Prep содержит 4 уроков всего.
Чему я научусь в уроке «Безопасность облачного хранилища и риски раскрытия данных»?
Узнайте, как неправильно настроенные контейнеры S3, Azure Blob и GCS приводят к раскрытию данных и как применять политики контейнеров и средства управления доступом. Ты практикуешь Cloud & IT Cert Prep с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать Cloud & IT Cert Prep?
Предыдущий опыт не требуется. Cloud & IT Cert Prep на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 2 из 4.
Сколько времени занимает урок «Безопасность облачного хранилища и риски раскрытия данных»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке Cloud & IT Cert Prep?
Да. Каждый урок Cloud & IT Cert Prep включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Модель общей ответственности: IaaS, PaaS, SaaS
- Безопасность облачного хранилища и риски раскрытия данных
- Облачная идентификация: роли IAM и сервисные учётные записи
- Управление состоянием безопасности облака (CSPM)