AWS

Безопасны ли ваши сегменты AWS S3?

Научитесь раскрывать весь потенциал политик IAM и начните использовать элемент политики «Условие».

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

Безопасность в целом сводится к двум вещам: аутентификации и авторизации. Аутентификация определяет кто вы, а авторизация определяет , что вы можете делать (после аутентификации). При работе с облаком AWS IAM (Identity and Access Management) играет роль привратника, таким образом заботясь о двух аспектах, которые мы обсуждали. Политики IAM управляют частью авторизации и действительно важны для ограничения того, что пользователи могут / не могут делать.

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

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

Для начала рекомендуется разделить ведро S3 и разрешения, связанные с объектами, на отдельные разделы. AWS называет их Заявлениями в документе о политике.

Кому нужен доступ?

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

На этом этапе такая служба, как EC2, которая сопоставлена ​​с ролью IAM arn:aws:iam::<requester_account_id>:roleaccess-s3-objects, может получать динамические временные учетные данные из конечной точки метаданных экземпляра по адресу http://169.254.169.254. Это автоматически обрабатывается официальными SDK и CLI, поэтому пользователю не нужно беспокоиться об этом.

Что необходимо получить?

В приведенной выше формулировке проблемы упоминается корзина S3, к которой необходимо получить доступ из другой учетной записи. Он становится элементом Ресурс в политике IAM. Предположим, что имя частного сегмента будет my-test-bucket

Для разных разделов вы можете соответствующим образом определить элементы ресурсов. Первое относится к ведру в целом, второе - к объектам внутри

Какие действия следует разрешить в ведре S3?

Это определяется элементом Действие в структуре политики IAM. Здесь очень важно соблюдать принцип минимальных привилегий и любой ценой избегать чего-то вроде s3:*. Кроме того, с помощью AWS Policy Simulator можно проводить простые тесты для имитации / отладки.

Для этого сценария пользователю достаточно иметь 3 основных разрешения s3:List ucketVersions, s3:ListBucket и s3:GetObject.

В течение каких интервалов дат должен быть разрешен доступ?

Введите Условия

Условия налагают политику IAM на стероиды. Теперь вы можете начать играть с детальным контролем, который они позволяют вам применять. В этом примере предположим, что вы хотите разрешить запросы только между 2020-04-01T00:00:00Z и 2020-05-30T23:59:59Z. Вы можете использовать любой формат ISO 8601 для определения этих сроков. Есть два варианта условных ключей: глобальные и специфичные для службы. После их введения политика IAM выглядит так:

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

Не только Дата, вы также хотите разрешить трафик, исходящий только из определенной сети.

Предположим, что исходящий шлюз NAT или общедоступный IP-адрес экземпляра - 13.126.87.165. Вы можете ограничить трафик, исходящий только из этого источника.

Ограничьте доступ только к подмножеству данных

Как описано в формулировке проблемы, вы также хотите контролировать доступ к ресурсам, который должен быть ограничен только некоторыми префиксами в корзине. При таком подходе вы можете ограничить то, что видят разные пользователи, и что они могут в дальнейшем загружать из этого набора. Допустим, вы просто хотите ограничить возможность перечисления папок с префиксами test/ иtest/sample-folder.

Кроме того, пользователь должен иметь возможность загружать только те объекты, которые имеют тег available:yes.

Этого можно добиться с помощью других интересных условных ключей:

Здесь важно отметить, что S3 в веб-консоли выглядит как типичная структура каталогов. Однако внутри это просто префиксы имен, с помощью которых вы можете ссылаться на отдельные объекты.

Полный текст Политики IAM доступен здесь, если вы хотите скопировать или отредактировать ее.

Заключение и дальнейшее чтение

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

На заметку

  • Не все ключи условий могут присутствовать всегда, будь то глобальные или специфичные для службы. Не забудьте проверить, какие параметры S3 и какие условные ключи поддерживают.
  • Если речь идет о безопасности, подумайте об использовании границ политики. Они определяют максимальную область разрешений, до которой пользователи вашей учетной записи могут повышать свои привилегии.
  • Разделите разрешения на уровне объекта и сегмента для большей ясности
  • Если вас также интересуют другие методы обеспечения безопасности при использовании EC2 или эффективное управление вашими паролями, не стесняйтесь проверять другие мои сообщения

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

До следующего раза, tschüss!