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

В этой статье вы найдете подробное описание шагов, которые вы можете предпринять для защиты, аудита и резервного копирования ваших таблиц DynamoDB и его данных через AWS IAM. , CloudTrail и S3.

Основы AWS IAM

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

Политики и типы

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

  • Политика на основе личных данных - предоставление разрешения пользователю, группе или роли в вашей учетной записи.
  • Политика на основе ресурсов - разрешение на прикрепление к ресурсу. Возможно только для определенных сервисов, например S3. Невозможно с DynamoDB.

Ресурсы, действия, эффекты и принципы

Политика может быть построена из разных элементов. Основные из них:

  • Принципал - определяет пользователя, службу или учетную запись, которые получают разрешения. Применимо только для политик на основе ресурсов. Для политик на основе идентичности роль, к которой будет привязана политика, является неявным принципом.
  • Ресурс - имена ресурсов Amazon (ARN) ресурсов, к которым будет применяться политика.
  • Действие - действие, которое будет разрешено. Ознакомьтесь с полным списком всех действий для всех сервисов в документации AWS.
  • Эффект: allow или deny. Явный deny всегда будет перезаписан.

Условия

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

Достижение минимальных привилегий для DynamoDB

Теперь у нас есть основы, поэтому мы можем определить наши правила контроля доступа как можно более строгие.

Ресурсы и операции

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

  • Таблица: arn:aws:dynamodb:region:$ACCOUNT_ID:table/$TABLE
  • Индекс: arn:aws:dynamodb:region:ACC_ID:$TABLE/$TABLE/index/$INDEX
  • Поток: arn:aws:dynamodb:region:ACC_ID:table/$TABLE/stream/$STREAM

Работа с Terraform или CloudFormation позволяет легко ограничить ваши политики именно тем ресурсом, который вы хотите, ссылаясь на него, вместо того, чтобы создавать ARN самостоятельно и / или значения жесткого кодирования.

  • Terraform - ссылайтесь на свой aws_dynamodb_table напрямую или экспортируйте его через output, чтобы вы могли использовать его в своих модулях.
  • CloudFormation - укажите свой AWS::DynamoDB::Table через GetAtt - у вас есть доступ к ARN таблицы, а также к ARN потока.

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

Границы разрешений

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

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

В Terraform вы можете расширить роль границей, указав ее через permissions_boundary. Если вы строго применяете новую инфраструктуру через определенную роль, граница может легко гарантировать, что вы по ошибке не предоставите широкий спектр действий или ресурсов.

Условия для детальной политики

Помимо управления доступом к действиям DynamoDB API, также можно ограничить доступ к отдельным элементам данных или даже атрибутам. Это особенно привлекательный вариант, если вы используете одностоловый дизайн.

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

На AWS есть хорошая документация с большим количеством примеров, вариантов использования и описаний.

Аудит с CloudTrail

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

CloudTrail позволяет вам постоянно отслеживать и регистрировать все действия, касающиеся вашей инфраструктуры. Все эти действия, такие как создание или удаление таблиц, могут регистрироваться в S3 или CloudWatch.

Но это еще не все - есть также возможность использовать События данных, которые также доступны для DynamoDB. Благодаря этому вы сможете регистрировать доступ DynamoDB к API объектного уровня.

Это позволяет отслеживать роли или личности в вашей учетной записи, которые претерпевают изменения в ваших таблицах. Вы можете найти подробное описание того, как настроить это с помощью Terraform здесь, гарантируя, что только ожидаемые роли имеют доступ к таблицам.

Автоматическое резервное копирование

Мы позаботились о том, чтобы наши правила контроля доступа соответствовали требованиям и были проверены, поэтому мы получаем уведомления в случае подозрительного поведения. Но человеческая ошибка и злонамеренное поведение по-прежнему возможны, поэтому всегда необходимо регулярно выполнять резервное копирование.

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

Оба эти типа управляются исключительно AWS.

  • С помощью по требованию вы сами запускаете создание резервной копии (например, с помощью запланированной лямбда-функции), а DynamoDB создаст моментальный снимок текущего состояния, включая все данные.
  • Если вы предпочитаете непрерывный вариант, вы можете активировать Восстановление на определенный момент времени (PITR). Это позволит DynamoDB создавать непрерывные инкрементные резервные копии, что позволяет восстанавливать таблицу до любой точки за последние 35 дней (цена более высокая).

S3 экспорт

Оба управляемых параметра не защищают вас от (случайного) удаления таблиц. Вот почему рекомендуется регулярный экспорт в S3. Это также функция AWS (требуется включение PITR).

const { DynamoDB } = require('aws-sdk')
const ddb = new DynamoDB({ region: 'eu-central-1' })
ddb.exportTableToPointInTime({
  TableArn: '$TABLE_ARN',
  S3Bucket: '$BUCKET_NAME',
  ExportTime: 1596232100,
  S3Prefix: 'backups',
  ExportFormat: 'DYNAMODB_JSON'
})

Основная цель экспортированной резервной копии в S3 заключается в том, что вы можете включить Блокировку объектов, либо с помощью…

  • Режим управления - объекты можно изменять / удалять только с определенными разрешениями или
  • Режим соответствия - объекты не могут быть изменены / удалены вообще, даже пользователем root.

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

S3 Репликация в другую учетную запись

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

Но что произойдет, если ваш аккаунт будет удален? В этом случае даже режим соответствия не защитит, и резервные копии исчезнут навсегда.

Вот почему вам следует реплицировать резервные копии в другую выделенную учетную запись для резервного копирования. Это легко возможно путем предоставления разрешений между учетными записями и автоматической репликации всех файлов из вашего основного ведра в репликационный с уведомлениями S3, запускающими лямбда-функцию.

Заключение

Мы рассмотрели принципы AWS IAM и способы их использования, чтобы максимально ограничить наши разрешения. Кроме того, мы изучили CloudTrail, чтобы обеспечить возможность аудита и наблюдения. Наконец, мы рассмотрели, как автоматически создавать резервные копии в DynamoDB или S3, включая репликацию в другие учетные записи в качестве второго уровня.

Спасибо за чтение. Я надеюсь, что вы взяли с собой хотя бы одно новое ценное открытие. 🎉

Чего-то не хватает? Не стесняйтесь использовать раздел комментариев. 💫

Больше контента на plainenglish.io