Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 5)

• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 3)
• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 4)

В этой статье, состоящей из нескольких частей, мы обсуждаем, как использовать AWS Identity and Access Management (IAM) для создания пользователей и групп и управления ими, а также для назначения им разрешений, чтобы детально контролировать, как они могут получить доступ к вашим ресурсам AWS. В части 1 мы говорили об основах IAM: как это работает, о пользователях и группах, аутентификации и учетных данных. Затем мы представили концепцию IAM-политик. Во второй части мы более подробно рассмотрели тему IAM-политик, разрешений и ролей, а также то, как интегрировать IAM в федеративную среду. В части 3 мы продолжили обсуждение политик с некоторыми особенностями работы с управляемыми политиками с помощью Консоли управления AWS и интерфейса командной строки AWS. В прошлый раз, в части 4, рассказывалось о некоторых советах по регистрации событий IAM с помощью AWS CloudTrail.

Сегодня в нашей последней части, части 5, мы рассмотрим, как устранять проблемы с IAM.

Что возможно могло пойти не так?

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

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

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

Устранение неполадок с сообщениями «Отказано в доступе»

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

Разрешения и политики

Если пользователь получает сообщение «отказано в доступе» при выполнении запроса к сервису AWS, первое, что нужно сделать, — это проверить и убедиться, что учетная запись пользователя имеет разрешение на выполнение предпринятого действия на конкретном ресурсе. Иногда в политиках будут заданы условия для отдельной учетной записи пользователя, группы, частью которой является пользователь, или роли, назначенной пользователю. Пользователь должен будет выполнить эти условия, чтобы получить доступ к ресурсу. Например, может существовать набор условий, который позволяет пользователю получать доступ к ресурсу только после проверки подлинности с помощью MFA (многофакторной проверки подлинности).

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

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

Подписанные вручную запросы

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

Запрос, подписанный вручную, — это запрос, сделанный без использования AWS SDK или интерфейса командной строки AWS, который будет подписывать запросы для вас в рамках создания и отправки запросов в AWS. Вам просто нужно настроить их с помощью ключа доступа.

Подпись версии 2 или подписи версии 4 можно использовать для подписи запросов, созданных программным путем, но рекомендуется использовать версию 4, если ее поддерживает конкретная служба. Код для подписи запроса должен иметь правильный синтаксис и содержать необходимую информацию для подписи. Вы можете найти процесс подписания запросов с использованием Signature Version 4 здесь:

http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html

Выполнение запросов с временными учетными данными

Иногда пользователи могут получить ужасное сообщение «отказано в доступе», когда они используют временные учетные данные безопасности для доступа к AWS. Многие сервисы AWS поддерживают использование временных учетных данных. Однако некоторые сервисы AWS этого не делают, поэтому первым шагом по устранению неполадок будет убедиться, что сервис принимает временные учетные данные.

Временные учетные данные генерируются действиями AWS STS (Security Token Service). STS — это веб-служба, с помощью которой вы можете получить временные учетные данные для пользователей IAM с ограниченными правами. Одно из больших различий между этими временными учетными данными и обычными долгосрочными учетными данными заключается в том, что они временные. Это означает, что они истекают через определенный период времени и больше не могут быть использованы. Если пользователь попытается сделать запрос к сервису AWS с просроченными учетными данными, в доступе будет отказано.

Запуск экземпляра EC2 с ролью

Иногда, когда вы пытаетесь запустить экземпляр в службе EC2 с ролью, вы можете получить ошибку «Отказано в доступе». Первое, что нужно сделать при устранении неполадок в этой ситуации, — попробовать запустить экземпляр без профиля экземпляра. Таким образом вы сможете определить, связана ли проблема с ролями IAM для ваших инстансов EC2.

Вы должны убедиться, что пользователь IAM, который делает запрос, имеет правильные разрешения и что вы используете допустимый профиль экземпляра. Если профиль экземпляра пуст (не имеет роли), вы можете получить сообщение «отказано в доступе». Возможно, вам потребуется создать роль с помощью Консоли управления AWS, интерфейса командной строки или API IAM. Роли позволяют приложениям безопасно отправлять запросы от инстансов EC2, не требуя от вас управления учетными данными, используемыми приложениями.

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

Пользователь root и сегмент S3

Еще один сценарий «отказа в доступе», который иногда всплывает, возникает, когда вы вошли в систему как пользователь root, но не можете получить доступ к корзине S3. Это может сбивать с толку, потому что учетная запись root должна предоставлять полный доступ ко всем ресурсам в учетной записи. Amazon фактически рекомендует не использовать учетную запись пользователя root, а вместо этого хранить ее учетные данные в безопасном месте и создавать обычную учетную запись пользователя IAM, которой вы назначаете права администратора для большинства административных задач.

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

Это не означает, что пользователь root не может получить доступ к корзине — это просто означает, что вам нужно использовать небольшой обходной путь: вы можете, как пользователь root, изменить политику корзины самостоятельно и предоставить пользователю root явный доступ к ведро. Задача решена!

Резюме

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

• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 3)
• Защитите сервисы и ресурсы с помощью AWS Identity and Access Management (часть 4)