Содержание статьи
Я уже не однажды касался вопросов безопасности в AWS в том или ином контексте. На этот раз я решил рассказать про основные механизмы безопасности, а также про типовые грабли, на которые наступают счастливые админы и разработчики. Попробуем обобщить и систематизировать требования и необходимые процедуры по обеспечению надежной защиты сервисов, которые мы хотим развернуть в облаке Amazon’a.
Защищай аккаунт
Самое ценное, что есть у тебя, — это админский доступ к аккаунту. Он позволяет создавать/удалять инстансы, управлять ролями и ключами, прикреплять секурити-группы, настраивать роутинг, менять настройки балансера, менять сертификаты SSL и многое другое. Этот доступ надо защищать, впрочем, как и любой другой доступ к админской (и не только) консоли, — ведь может быть много пользователей, ролей и ключей.
- Аутентификация: логин + пароль
Классика жанра, добавить тут нечего, кроме разве что пары вещей: парольной политики и двухфакторной аутентификации. AWS позволяет настроить политику, которая будет ограничивать минимальную длину пароля, заставлять использовать регистры, цифры и спецсимволы, ну и также проверять обновление пароля в течение определенного срока, а кроме того, запоминать хеш предыдущих N паролей, чтобы пользователь не смог их использовать повторно. Короче, просто и понятно. Двухфакторка тоже не инновация — используй хардварный или виртуальный MFA, генератор одноразовых паролей, который будет их генерировать каждые 30 секунд, таким образом ты должен ввести логин + пароль + одноразовый код. Виртуальный MFA может быть установлен на телефоне. Все вместе это довольно стандартное и надежное средство защиты парольной аутентификации.
- Аутентификация по симметричному ключу
Но это не единственный способ, есть еще ключи доступа, которые привязываются к пользователю. Ключи генерируются прямо из консоли и могут быть скачаны в виде файла. Фактически это просто длинная, случайная строка, как пароль, только является ключом (симметричного криптоалгоритма). Этот ключ секретный и хранится на сервере и у клиента. Он используется для доступа к REST API и привязан к конкретному пользователю. И если про логин и пароль все ясно, то к этому ключу почему-то разработчики относятся менее серьезно. Довольно часто бывает, что его можно найти в исходниках на GitHub’е или зашитым в исходники Android/iOS-приложения. А ведь это ключ доступа, и если юзер этого ключа — админ, то и любой API-запрос — админский, включая запрос на создание нового пользователя или инстанса. Поэтому ключ надо защищать, это важный момент.
- Подписанные запросы API (SOAP)
Кроме симметричной криптографии, AWS позволяет использовать асимметричную. Ты генерируешь RSA-ключи, делаешь сертификат с открытым ключом, прикрепляешь этот сертификат к пользователю в AWS-консоли, после чего можешь использовать SOAP API с XML signatures (не везде, в EC2/S3, например, только REST, только хардкор, там лишь Access Key). Естественно, закрытую часть ключа надо защищать…
Ротацию ключей/сертификатов можно и нужно поддерживать! Все перечисленные методы и настройки — часть так называемого AWS IAM (AWS Identity and Access Management) и могут быть настроены как через API или шаблоны (AWS CloudFormation), так и вручную в консоли.
Роли и группы
Не все пользователи должны быть админами, это очевидно, поэтому AWS IAM имеет еще сущности: роли, группы и политики. Политика — это описание доступа. Например, админская политика выглядит так:
{ "Statement":[{ "Effect":"Allow", "Action":"*", "Resource":"*" } ]}По-деревенски: разрешать делать ВСЕ для ВСЕГО. Соответственно, ограничиваем права для доступа к IAM так:
"Statement": [ { "Effect": "Allow", "Action": [ "iam:GetGroup", "iam:GetLoginProfile", "iam:GetUser", "iam:ListAccessKeys", "iam:ListAccountAliases", "iam:ListGroupPolicies", "iam:ListGroups", "iam:ListGroupsForUser", "iam:ListMFADevices", "iam:ListSigningCertificates", "iam:ListUsers", "iam:GetServerCertificate", "iam:ListServerCertificates", ], "Resource": "*" }]Effect — разрешить или запретить.
Action — какой запрос API конкретно, то есть какое действие.
Resource — какой конкретно ресурс может быть объектом для данной политики, в данном контексте IAM — группа или пользователь, на которых распространяются эти правила (в нашем примере это все группы и пользователи).
Еще есть дополнительная группа Condition, в которой можно указать дополнительные условия политик, например IP-адрес источника (фильтр по IP).
Ну и понятна логика для Actions: все, что не разрешено, запрещено. Эти политики можно приписать как роли, так и отдельно пользователю. Потом на основе ролей создавать группы. При этом группу можно также назначить пользователю. То есть можно «давать права» либо пользователям, либо ролям, которые входят в группы. Пользователям можно состоять в одной группе или в нескольких. То есть получается весьма гибкая ролевая модель.
При довольно большой инфраструктуре, где у нас много пользователей — для деплоя, для сканера, для аудита, для логов и так далее, есть вероятность намудрить и запутаться — очень много правил: одним можно писать в s3, другим только читать… И конечно, это огромное поле для сокрытия бэкдора :). Например, бэкдорная полиси может быть добавлена в роль или к пользователю, при этом список пользователей, ролей и групп не изменится.
Еще больше доступа к аккаунту
Казалось бы, точки входа и права — все оно тут есть и описано. Но есть еще много черных ходов.
- Доверенные аккаунты.
На роль можно прицепить юзера с другого аккаунта. Это очень мило, берем роль админа и цепляем к нему пользователя с хакерского аккаунта. Заметить это можно только в графе Trusted Relationship в списке ролей — в списке пользователей его видно не будет.
- Роль инстанcа.
Все инстансы могут обращаться к API метаданных без ключа (http://169.254.169.254/latest/meta-data/>). С этого API инстанс (и хацкер, который запывнил бокс) может получить кучу инфы. Ирония в том, что можно прицепить роль к самому инстансу, таким образом можно использовать AWS API, и тогда будет генерироваться временный Access Key, который можно слить через эти же метаданные: http://169.254.169.254/latest/meta-data/iam/security-credentials/.
Используя этот ключ, можно делать то, что прописано в политиках роли. То есть фактически достаточно простой SSRF, чтобы полностью захватить аккаунт (при излишне небезопасных настройках, конечно).
- SAML Providers.
А ведь можно еще добавить провайдер для SSO-аутентификации. То есть где-то у тебя есть, например, свой LDAP, можно добавить его в AWS-аккаунт, тогда аутентификация юзера будет проходить там, и в случае успеха доступ этот юзер получит в AWS-аккаунте с определенной ролью...
Защищаем инстансы
Да, вторая часть защиты облака — это защита непосредственно виртуалок. В 90% это вопросы защиты ОС, сервисов и прочие баяны. Главное — помнить несколько моментов: инстансы имеют доступ к API AWS, иностранцы могут иметь доступ к внутренней сети и к другим инстансам и даже к локальной сети или ЦоД за пределами AWS. Это я на тему SSRF-атак или в случае компрометации бокса про развитие атак. Так или иначе, кроме механизмов защиты ОС, есть еще и механизмы AWS, и это уже вышеупомянутые VPC, а кроме того, Security Groups и ELB сегментация сети, даже виртуальной, — это довольно важно.
- VPC (Amazon Virtual Private Cloud).
Фактически это возможность рулить локальными подсетями — с фильтрацией и роутингом трафика так, как удобно клиенту. Например, можно прокинуть VPN из дата-центра или офиса в подсетку нашего амазона, объединив их в некую логическую подсеть. А можно просто напиливать зоны типа DMZ, бэкенд и так далее. Этот механизм сильно расширяет наши возможности по сравнению со стандартным EC2.
- Security Groups.
Это обычный способ фильтровать трафик между инстансами. Фактически это простой список с правилами фильтрации — откуда, куда, какой порт. Кроме того, если говорить о фильтрации в VPC, там есть отдельные правила фильтрации между сетями — Network ACL. А Security Groups применимы непосредственно к инcтансам. Хотя данный механизм довольно неудобен, так как имеет ряд ограничений: в EC2 нельзя добавлять группы к уже существующим инстансам. Либо менять текущие группы, либо передеплоить инстанс уже с новым сетом групп.
- ELB (Elastic Load Balancing).
Данная сущность является «встроенным» балансером, а также может играть роль SSL-терминатора, так что после генерации ключика и сертификата SSL они аплоадятся именно туда. Опять же есть косяк — в EC2 нельзя прилепить фильтрацию к балансерам, то есть если ты хочешь ограничить доступ с определенных IP. ELB доступен для всех, всегда. Второй косяк, даже еще более мерзкий, — если у тебя SSL за ELB, то ты теряешь Source IP — X-Forwarded-For не добавляется к заголовку (зашифрован). Ну а если ты форвардишь SSH через ELB, то да... это провал :).
Все три описанных механизма позволят фильтровать и раздавать трафик более продуманно с точки зрения безопасности, впрочем, как и создавать дыры и проблемы…
CloudFormation
Важная часть безопасности — это унификация и стандартизация конфигов, доступа и прочего. То есть один раз конфигурируем типовое решение, проверяем, что безопасно, удобно и быстро, — далее применяем. Это позволит избежать велосипедов и снизить «человеческий фактор», ну и главное — удобно мониторить. Задали, допустим, секурити-группе имя — и знаем, что это за группа, что там, про что она, а иначе была бы куча одинаковых групп на разных акках с разными названиями. И еще надо убедиться, что и внутри все ОК.
CloudTrail
Если у нас нет логирования событий AWS, то все довольно печально. Кто и когда пользовался API? Кто логинился? Кто менял политики и прятал бэкдор? Все это будет тебе неизвестно. Очень важный элемент безопасности для мониторинга и расследования инцидентов. Анализ логов можно и нужно автоматизировать, но про это я уже писал, просто не мог не упомянуть тут ;).
Регионы
Очевидно, но все же тема важная. Аккаунт делится на регионы, и если IAM-пользователи, например, на весь аккаунт, то уже инстансы и политики — нет. Тот же CloudTrail может быть настроен не на все регионы. Этот момент надо помнить и контролировать, собственно, как я писал выше, — очевидная вещь, но забывать не стоит.
Финал
Многое тут не уместилось, но, надеюсь, главное показать удалось — тонкие места в настройках, архитектуре или места для бэкдора (особенно в политиках). Короче, основные узлы безопасности аккаунта AWS и, как следствие, всей облачной платформы. Если что, предлагаю вспомнить историю одной компании, у которой украли акк от AWS, создали бэкдор, и, когда те попытались почиститься, злодеи все удалили, так как имели альтернативный доступ к аккаунту. В итоге компания закрыла свой бизнес. Всем безопасных и приятных облаков!
