Как я могу обеспечить возможность аудита и минимальные привилегии на основе пользователей AWS внутри образа EC2?
Я стажируюсь в компании, которая работает в среде AWS и начинает изучать возможность ограничения прав пользователей, поэтому я ищу способы защитить экземпляры EC2. В частности, я хочу найти способ избежать передачи пары ключей, которая предоставляет безусловный доступ к ec2-user, который с политикой sudo Amazon Linux по умолчанию, по сути, является root и имеет дополнительный недостаток в том, что нет журнала аудита (поэтому, если кто-то запускает что-то вредоносное, пока SSH подключено к экземпляру EC2, нет способа узнать, кто, потому что пользователь Linux, выполняющий команды, всегда ec2-user).
Моя первая мысль заключалась в том, чтобы сделать это через PAM, подобно тому, как LDAP интегрирован в PAM через pam_ldap или что-то в этом роде, но я не могу найти ничего, что позволило бы мне использовать IAM как серверную часть аутентификации. Я мог бы просто вручную добавлять пользователей, поскольку доступ действительно нужен очень небольшому количеству людей, но это, кажется, подвержено человеческим ошибкам, а также со временем неизбежно станет все более и более непоследовательным.
Я тоже искал в Интернете безуспешно.
Какая здесь лучшая практика?
Моя первая мысль заключалась в том, чтобы сделать это через PAM, аналогично тому, как LDAP интегрирован в PAM через pam_ldap или что-то подобное, но я не могу найти ничего, что позволило бы мне использовать IAM в качестве бэкэнда аутентификации
Я думаю, вы неправильно думаете об этом, попробуйте для начала расширить свой домен в IAM, чтобы пользователи входили в AWS с учетными данными своего домена, а не с отдельными учетными данными IAM. наиболее полезным аспектом IAM является доступ на основе ролей и политики для пользователей AWS - это не распространяется на экземпляры облака, поэтому необходимо настроить более традиционную доменность, например создание виртуального частного облака (VPC - чтение VPN) и самозагрузку экземпляров, чтобы они были настроены специально для вашего домена.
В частности, я хочу найти способ избежать выдачи пары ключей, которая предоставляет безусловный доступ пользователю ec2, который с политикой sudo Amazon Linux по умолчанию, по сути, является пользователем root и имеет дополнительный недостаток, заключающийся в отсутствии журнала аудита (так что, если кто-то запускает что-то вредоносное, пока SSH подключено к экземпляру EC2, невозможно определить, кто именно, потому что пользователь Linux, выполняющий команды, всегда является пользователем ec2).
загрузка экземпляров облака
как вы знаете, когда вы загружаете экземпляр в облаке, вы связываете экземпляр с образом, сетью, группой безопасности, открытым ключом и т. д., а затем вы можете ssh или rdp в экземпляр с секретным ключом или паролем , обычно в качестве пользователя ec2-user или admin для Windows, но вы также можете загрузить экземпляр с помощью службы под названием cloud-init, при запуске экземпляра выберите `` дополнительные параметры ''
Внутри текстового поля вы можете вставить свой сценарий cloud-init, cloud-init - это ваш основной загрузчик, вы можете использовать его для установки пакетов, запуска сценариев, изменения системы, добавления пользователей и групп и т. Д., Это облако называется «Userdata». экземпляры ищут любые предоставленные пользователем данные, выполняя HTTP-запрос на адрес обратной связи экземпляра (который перенаправляется)
GET http://169.254.169.254/2009-04-04/user-data
так вот пример скрипта, который добавит некоторых пользователей и другие авторизованные ключи
#cloud-config
users:
- name: demo
groups: sudo
shell: /bin/bash
sudo: ['ALL=(ALL) NOPASSWD:ALL']
ssh-authorized-keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDf0q4PyG0doiBQYV7OlOxbRjle026hJPBWD+eKHWuVXIpAiQlSElEBqQn0pOqNJZ3IBCvSLnrdZTUph4czNC4885AArS9NkyM7lK27Oo8RV888jWc8hsx4CD2uNfkuHL+NI5xPB/QT3Um2Zi7GRkIwIgNPN5uqUtXvjgA+i1CS0Ku4ld8vndXvr504jV9BMQoZrXEST3YlriOb8Wf7hYqphVMpF3b+8df96Pxsj0+iZqayS9wFcL8ITPApHi0yVwS8TjxEtI3FDpCbf7Y/DmTGOv49+AWBkFhS2ZwwGTX65L61PDlTSAzL+rPFmHaQBHnsli8U9N6E4XHDEOjbSMRX user@example.com
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDcthLR0qW6y1eWtlmgUE/DveL4XCaqK6PQlWzi445v6vgh7emU4R5DmAsz+plWooJL40dDLCwBt9kEcO/vYzKY9DdHnX8dveMTJNU/OJAaoB1fV6ePvTOdQ6F3SlF2uq77xYTOqBiWjqF+KMDeB+dQ+eGyhuI/z/aROFP6pdkRyEikO9YkVMPyomHKFob+ZKPI4t7TwUi7x1rZB1GsKgRoFkkYu7gvGak3jEWazsZEeRxCgHgAV7TDm05VAWCrnX/+RzsQ/1DecwSzsP06DGFWZYjxzthhGTvH/W5+KFyMvyA+tZV4i1XM+CIv/Ma/xahwqzQkIaKUwsldPPu00jRN user@desktop
runcmd:
- touch /test.txt
Такой подход позволит вам разработать способ привязки учетных записей пользователей и разрешений к загрузке (точно так же, как настраивается пользователь ec2). Или вы можете использовать cloud-init или формирование облака для присоединения экземпляров к домену при загрузке.
http://cloudinit.readthedocs.io/en/latest/
надеюсь, это поможет.