Защита вашей инфраструктуры AWS с помощью IAM

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

Amazon Web Services является невероятным инструментом для стартапов и других команд для быстрого создания приложений и инфраструктуры. Эти команды часто имеют более сильный опыт разработки, чем правильные системные операции.

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

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

Управление идентификацией и доступом (IAM), сердце безопасности AWS

IAM, Identity and Access Management, является ядром системы безопасности AWS. Это позволяет вам управлять пользователями, группами и различными ролями в вашей инфраструктуре. Вы можете создавать разные функциональные группы с разными разрешениями и добавлять людей в эти группы. Это позволяет легко изменять разрешения, когда люди переходят в другие группы, и им больше не нужен доступ ко всем частям системы.

Вы можете прикрепить несколько политик к пользователю, группе или роли, которые охватывают доступ к различным сервисам AWS или различным ресурсам.

Документация IAM проста для чтения и, безусловно, интересна для просмотра. Он доступен в формате HTML, PDF или для вашего Kindle, так что вы даже можете прочитать его во время поездки.

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

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

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

Создать учетную запись пользователя для каждого человека

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

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

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

Например, для следующего пользователя не включены два фактора. Добавив его и следуя указаниям мастера, вы можете значительно повысить свою безопасность.

Использование нескольких ключей для ролей с указанными возможностями

Как мы уже говорили ранее, вы никогда не должны использовать основной ключ своей учетной записи AWS для доступа к API. Это не значит просто создать пользователя-администратора и использовать этот ключ везде.

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

Не используйте ключи внутри экземпляров EC2

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

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

Создать роль в IAM

Сначала вы начинаете с создания новой роли в IAM для EC2. Вы можете создавать роли для различных сервисов, таких как Opsworks, которые могут выполнять вызовы AWS API для вас.

Затем вы создаете политику, которая позволяет вам получить доступ к конкретному S3 Bucket

Импортируйте следующую политику в мастер:

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

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

Здесь мы устанавливаем роль для checkbot

Теперь, когда вы вызываете API AWS, вам не нужно предоставлять какие-либо ключи, поскольку они будут автоматически созданы для вас с правильными разрешениями. Отныне больше не нужно больше ключей внутри экземпляра, что делает всю установку намного чище и проще в использовании.

Включить Cloudtrail

Cloudtrail — это новый сервис, выпущенный на AWS: reInvent в ноябре прошлого года. Он будет автоматически регистрировать каждый вызов API AWS в S3 Bucket. Это может помочь с проверкой в ​​будущем.

Это займет несколько кликов и менее 30 секунд для настройки, будет стоить почти ничего (вы платите только за корзину S3, но не за Cloudtrail) и может спасти вас в будущем. Просто сделай это!

Выводы

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

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

Корабль долго и процветать!

Дальнейшая информация

• Советы AWS, которые я хотел бы знать, прежде чем начать
• Вращающаяся документация по учетным данным в AWS
• Сообщение в блоге управления учетными данными Тревора Роу
• Документация по разрешениям и политикам в AWS
• Документация об именах ресурсов Amazon