Лучшие практики использования ключей доступа AWS IAM с AWS SDK

Лучшие практики использования ключей доступа AWS IAM с AWS SDK

Я хочу узнать о лучшей практике, используемой крупными компаниями для программного доступа к нескольким сервисам AWS, поскольку есть несколько программ, которым нужен доступ к разным-2 сервисам, так как это управляется? Создали ли они несколько ключей доступа для каждой программы для разных-2 сервисов или создали один с доступом ко всем сервисам?

решение1

Для таких ресурсов AWS, как EC2/Lambda и т. д., лучше всего использовать роли IAM, подробно описанныездесь. Короче говоря, вы не создаете пользователя для сервера, вы создаете роль, которую может принять служба, имеющая набор разрешений, связанный с сервером EC2.

Этот сервер с ролью получает "временные" учетные данные, когда он работает, чтобы иметь доступ к любой службе, которую разрешает роль IAM. Когда я говорю "временные", учетные данные, предоставляемые службе, являются недолговечными, может быть, 24 часа, но когда они истекают, выдаются новые учетные данные. Обычно это прозрачно, если только вы не пишете программное обеспечение, которое их использует, в этом случае вам нужно время от времени их проверять. Я могу не совсем точно знать все тонкости, но это более или менее верно.

В AWS есть предопределенные политики, которые могут упростить определение ролей.

Например, вы можете определить роль, которая гласит: «Серверы EC2 с этой ролью могут отправлять данные в SQS, получать данные из SQS, выполнять эту лямбда-функцию», и все, что явно не предоставлено, будет отклонено. Иногда требуется немного поэкспериментировать, чтобы получить необходимые разрешения. Лучше всего использовать минимальные привилегии, чтобы в случае взлома ресурса, например сервера EC2, у него не было прав администратора в AWS, и он не мог удалить все или, скажем, начать майнинг криптовалют.

Если вы работаете в крупной компании, выполняющей работу с AWS, я предлагаю вам пройти обучение по AWS. Онлайн-обучение на должность AWS Architect Associate в месте вроде Cloud Guru — это минимум, который вам понадобится. AWS — это сложная система. Я работаю в AWS полный рабочий день уже много лет, но каждый день узнаю что-то новое.

решение2

Прежде всего, вам нужны предопределенные политики доступа к ресурсам (например, SQS, EC2, ElastiCache и т. д.). После этого вы можете добавить пользователя с программным доступом и сохранить учетные данные безопасным способом или использовать роли, чтобы назначить их службам для доступа. Например: создайте роль IAM для доступа к RDS и назначьте ее экземпляру ec2, затем попробуйте получить доступ к нашей базе данных из экземпляра ec2.

Связанный контент