Колонка Алексея Синцова: Безопасность AWS

Я уже не однажды касался вопросов безопасности в 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, создали бэкдор, и, когда те попытались почиститься, злодеи все удалили, так как имели альтернативный доступ к аккаунту. В итоге компания закрыла свой бизнес. Всем безопасных и приятных облаков!