Режимы шифрования и обязательная защита при передаче

Использование AWS Security для разработчиков

Rahul Singh

Technical Product Manager

Две гарантии, один режим по умолчанию

Приложение отправляет объект в бакет Amazon S3. Зелёная скобка с подписью «при передаче» охватывает сетевой переход, а вторая зелёная скобка с подписью «при хранении» — сохранённый объект; ниже указано, что SSE-S3 применяется, если в запросе не указано иное.

При хранении: байты на диске
При передаче: байты в сети

Две гарантии, один режим по умолчанию

При хранении: байты на диске
При передаче: байты в сети
Уже сделано: SSE-S3 для каждого нового объекта
Остаётся вам: какой режим и кто хранит ключ, решаете вы

Где заканчивается открытый текст

На стороне сервера

AWS получает читаемые байты
S3 шифрует при записи

Серверный сценарий. Ваш процесс хранит открытый текст, передаёт его по TLS-соединению, а Amazon S3 шифрует данные при записи. Полоса внизу отслеживает байты, разделённая пунктирной линией на границе S3: участок до неё подписан «ваши байты: читаемы здесь» и показан красным, участок после — «шифртекст» и показан зелёным.

Где заканчивается открытый текст

На стороне сервера

AWS получает читаемые байты
S3 шифрует при записи

На стороне клиента

Вы шифруете данные перед отправкой
AWS хранит только шифртекст

Клиентский сценарий. Ваш процесс сначала шифрует данные, отправляет шифртекст по TLS-соединению, а Amazon S3 сохраняет полученное без изменений. Полоса внизу отслеживает байты, разделённая пунктирной линией внутри вашего процесса: короткий участок до неё подписан «ваши байты: читаемы здесь» и показан красным, всё после неё — «шифртекст» и показано зелёным.

Четыре режима, одно различие

Один алгоритм, четыре владельца ключей

Режим передаётся в заголовке запроса PUT
SSE-S3: ключ AWS, управлять не нужно
SSE-KMS: ваш ключ, CloudTrail и политика ключа, определяющая, кому он отвечает

Четыре карточки друг под другом с названиями SSE-S3, SSE-KMS, DSSE-KMS и SSE-C. Вертикальная шкала слева идёт от контроля AWS вверху к вашему контролю внизу, и на каждой карточке указано только значение заголовка запроса, выбирающее этот режим.

Четыре режима, одно различие

Один алгоритм, четыре владельца ключей

Режим передаётся в заголовке запроса PUT
SSE-S3: ключ AWS, управлять не нужно
SSE-KMS: ваш ключ, CloudTrail и политика ключа, определяющая, кому он отвечает
DSSE-KMS: два независимых слоя
SSE-C: ваш ключ при каждом запросе, вы отвечаете за его сохранность

Стоимость как аргумент против SSE-KMS

Два ряда. Без Bucket Keys шесть стрелок идут от Amazon S3 к AWS KMS — по одной на каждый запрос объекта. С Bucket Keys остаётся одна стрелка от ключа уровня бакета, хранящегося внутри S3. Ниже указано, что Bucket Keys недоступны при использовании DSSE-KMS.

Без Bucket Keys: один вызов KMS на объект
С Bucket Keys: один недолговечный ключ, используется повторно
Недоступно с DSSE-KMS
До 99% меньше запросов к KMS

Шифруйте поле, а не таблицу

Шифрование при хранении уже включено

Запрос возвращает открытый текст любому, у кого есть доступ на чтение

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

Шифруйте поле, а не таблицу

Шифрование при хранении уже включено

Запрос возвращает открытый текст любому, у кого есть доступ на чтение

AWS Database Encryption SDK

Шифруйте выбранные атрибуты в коде
Ключ раздела и ключ сортировки — поля, по которым DynamoDB находит элементы, — остаются открытыми, так как по ним строится индекс

TLS доступен, но не обязателен

Доступно, но не обязательно

S3 одинаково отвечает на HTTP и HTTPS

Два сценария. Без условий на бакете и HTTPS-, и HTTP-клиент получают доступ к объекту. При наличии запрещающего условия путь HTTP останавливается на красном крестике, и соединение не устанавливается.

TLS доступен, но не обязателен

Доступно, но не обязательно

S3 одинаково отвечает на HTTP и HTTPS

Сделайте это требованием

Политика бакета: запрет, если aws:SecureTransport равно false
Легитимные клиенты ничего не заметят

Какой удостоверяющий центр ручается за имя

Публичное имя

ACM: общедоступное доверие, бесплатно, продлевается автоматически

Имя, которое резолвит только ваша сеть

AWS Private CA: собственный удостоверяющий центр
Никогда не вызывает доверия в публичном интернете

Две карточки друг под другом с заголовком «кто может выпустить сертификат». Верхняя карточка, публичное имя, указывает reports.example.com как резолвимое имя и ACM как издателя, которому доверяют везде. Нижняя карточка, внутреннее имя, указывает admin.example.internal, резолвимое только внутри вашего VPC, и AWS Private CA как издателя.

Закрытая часть — ваша ответственность

Кто хранит ключ

ACM: хранит AWS
Пара ключей EC2 или любой SSH-ключ: закрытую часть храните вы, причём только один раз

Две карточки друг под другом с заголовком «кто хранит какую часть». Верхняя карточка, публичная часть, говорит, что она хранится в AWS или на инстансе. Нижняя оранжевая карточка, закрытая часть, содержит три строки: у вас одна копия без запасной, хранить в Secrets Manager — зелёная галочка, и никогда в репозитории, на ноутбуке или в чате — оранжевый крестик.

Закрытая часть — ваша ответственность

Кто хранит ключ

ACM: хранит AWS
Пара ключей EC2 или любой SSH-ключ: закрытую часть храните вы, причём только один раз

Если ключ ваш

Secrets Manager, а не репозиторий
Меняйте по расписанию

Три ответа, а не один

Три пронумерованные карточки — режим, контроль ключа и передача данных, на каждой указан заголовок или условие, которое на него отвечает. Строка ниже отмечает, что только третья проверка находится вне настроек шифрования.

Режим: чем записан объект
Контроль ключа: кто может его расшифровать — в этом аккаунте или в другом
Передача: обязательна или только доступна

Давайте потренируемся!

Использование AWS Security для разработчиков