AWS безопасна лишь настолько, насколько слабы учетные данные, установленные для ваших разработчиков.

Вопрос профилактики и смягчения последствий

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

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

Аутентификация запросов

Я называю это действие вызовом HTTP API. HTTP API-вызовы должны быть подписаны с помощью процесса, называемого Signature Version 4, который добавляет подпись к HTTP-запросу в заголовке или в качестве параметра строки запроса; это позволяет аутентифицировать запросы.

Вы можете реализовать процесс Signature Version 4 самостоятельно, но общепринятой лучшей практикой является использование существующих и проверенных решений, таких как AWS SDK, независимо от используемого языка программирования (если он поддерживается). Если вы не реализуете приложение и вам нужен доступ к AWS API из командной строки, вам подойдет AWS CLI.

AWS SDKs и AWS CLI — это два примера инструментов разработчика, используемых для доступа к службам AWS через аутентифицированный API, но вы можете найти и другие, например, AWS Toolkit for Visual Studio. Все эти инструменты разработчика инкапсулируют процесс подписания SigV4, описанный ранее. Ключ подписи, используемый для создания подписи SigV4, берется из ключа доступа, то есть ваших учетных данных безопасности. Если вы имеете дело с недолговечными учетными данными безопасности, запрос API содержит токен сессии, который вы получили от AWS STS.

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

Цепочка поставщиков учетных данных

Как AWS CLI, так и SDK ищут учетные данные безопасности, следуя цепочке поставщиков учетных данных.

С локальной точки зрения основными звеньями этой цепочки являются переменные окружения и общие конфигурационные файлы. В основном, переменные окружения имеют приоритет над общими конфигурационными файлами. Если переменные окружения не установлены, инструменты разработчика ищут учетные данные в файле $HOME/.aws/credentials; в последнюю очередь они ищут учетные данные в файле $HOME/.aws/config. Последний из них не предполагается использовать в качестве контейнера конфиденциальной информации, но вы можете использовать его для этой цели. Вы даже можете использовать сторонний инструмент для генерации учетных данных по требованию, указав ключ credentials_process в файле $HOME/.aws/config.

Где можно найти учетные данные AWS ЛОКАЛЬНО?

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

В зависимости от инструментов, которые вы используете на своей машине, могут быть и другие места, где злоумышленник может найти конфиденциальную информацию. Например, злоумышленник может найти учетные данные AWS в кодовой базе одного из ваших приложений, независимо от того, игнорируются ли они вашим инструментом контроля версий (если вы используете git, используйте файл .gitignore).

Незаметное, но заслуживающее внимания место, где учетные данные могут быть найдены в истории команд, доступной как на машинах Linux, так и на macOS. Представьте, что вы экспортировали долгосрочные учетные данные как переменные среды с помощью команды export; так вот, эта конфиденциальная информация будет храниться в истории до тех пор, пока вы не очистите историю команд.

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

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

Описанные выше объекты являются примерами распространенных мест, где злоумышленник может найти конфиденциальную информацию. Вы все еще можете найти их в пользовательских местах; например, что касается общих конфигурационных файлов AWS, вы можете установить пользовательское местоположение как для учетных данных, так и для экспорта конфигурационных файлов, соответственно, переменные среды AWS_CONFIG_FILE и AWS_SHARED_CREDENTIALS_FILE.

Как ваша машина может быть скомпрометирована?

Будьте внимательны при настройке доступа к личному или рабочему ноутбуку. Всегда рекомендуется использовать надежный пароль, чтобы защитить его от взлома. В лучшем случае, кто-то из ваших милых коллег может ввести несколько забавных шуток в вашу среду разработки (не таких забавных для вас)!

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

А что если я полностью контролирую свой ноутбук? Может ли что-то произойти? Ну, как уже говорилось, злоумышленником может быть как человек, так и программное обеспечение. Если я не знаю о вредоносной программе, установленной на моем ноутбуке, она может использовать уязвимости, открытые непропатченным легальным ПО. Интересным примером вредоносного программного обеспечения, развернутого с целью кражи учетных данных AWS, является скрипт TeamTNT. В данном случае предполагается, что вредоносные скрипты запускаются не на ноутбуках разработчиков, а на экземплярах AWS EC2 и контейнерах AWS ECS. Он крадет учетные данные AWS через URL-адреса их метаданных (169.254.169.254 для AWS EC2 и 169.254.170.2 для AWS ECS), а также переменные окружения из систем Docker.

Модель разделенной ответственности

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

В двух словах, AWS отвечает за безопасность облака, а не за безопасность в облаке. Это означает, что AWS обеспечивает безопасность оборудования, программного обеспечения, сетей и средств, на которых работают облачные сервисы AWS. С другой стороны, пользователь AWS отвечает за выбор и настройку сервисов и ресурсов в облаке, в своих учетных записях AWS. Это включает в себя настройку управления идентификацией и доступом в соответствии с лучшими практиками. Конфигурация Identity and Access Management влияет на то, что IAM-персонал может делать на каком ресурсе и при каких условиях. Я считаю полезным подробный обзор логики IAM Policy Evaluation, поскольку он дает представление о потоке авторизации аутентифицированного вызова HTTP API.

Блок-схема оценки политики

Стратегии смягчения последствий кражи учетных данных AWS

Давайте рассмотрим некоторые из лучших практик для снижения вероятности ущерба в случае компрометации локальных учетных данных AWS.

1 — Не используйте учетные данные учетной записи root

Учетные данные корневой учетной записи должны использоваться только во время первоначальной настройки учетной записи AWS для создания пользователя AWS IAM с правами администратора. Затем учетные данные root-аккаунта должны храниться в безопасности в менеджере паролей, например, LastPass или Bitwarden. Распространение учетных данных root крайне опасно, поскольку после кражи их невозможно аннулировать.

2 — Включите MFA везде!

Независимо от того, входите ли вы в AWS через федерацию SAML или через учетные данные пользователя IAM, включение многофакторной аутентификации добавляет уровень безопасности к процессу входа. По сути, она требует от пользователя указания кода в дополнение к основной информации для входа. Код может быть сгенерирован либо виртуальным устройством (например, приложением Google Authenticator), либо физическим (например, YubiKeys). Помните, что при использовании функции цепочки ролей AWS информация MFA передается только в том случае, если пользователь IAM с поддержкой MFA принимает роль, требующую передачи информации MFA в вызове API assumeRole.

Передача информации MFA из AWS CLI может быть громоздкой, но вы можете использовать Dev Tools, такие как Leapp, чтобы упростить этот процесс.

Я рекомендую не использовать плагины аутентификатора MFA для браузера. Если вы вошли в менеджер паролей, наличие плагина аутентификатора MFA, установленного в браузере, практически ломает механизм «знание + владение», поскольку второй фактор (код MFA) может быть получен с вашего ноутбука вместе с базовой информацией об аутентификации, полученной через менеджер паролей.

3 — Предпочитайте краткосрочные учетные данные

Как вы знаете, AWS позволяет подписывать HTTP API запросы как краткосрочными, так и долгосрочными учетными данными.

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

С другой стороны, использование краткосрочных учетных данных уменьшает радиус взрыва при краже учетных данных. Помните, что диапазон продолжительности краткосрочных полномочий варьируется в зависимости от стратегии доступа: краткосрочные полномочия, созданные на основе ключа доступа IAM User, имеют продолжительность от 15 минут до максимум 36 часов; краткосрочные полномочия, созданные с помощью API assumeRoleWithSAML и assumeRole, имеют продолжительность от 15 минут до максимум 12 часов.

4 — Ротация учетных данных

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

5 — Применяйте принцип наименьших привилегий

Я хочу обратить на это внимание, даже если это не то, что вы можете сделать локально, не имея доступа к учетным записям AWS.

Учетные данные, которые управляются на вашей локальной машине, всегда ссылаются на IAM Principal, который имеет те или иные привилегии доступа в ваших учетных записях AWS.

То, что вы можете делать внутри этих учетных записей, зависит, как минимум, от того, как были установлены политики доступа, политики ресурсов и политики управления сервисами (вероятно, кем-то, кто отвечает за безопасность вашей организации). Для безопасности ваших облачных активов очень важно, чтобы каждый IAM-принципал имел набор разрешений, соответствующий его роли в одной или нескольких рабочих нагрузках. Следование этой передовой практике смягчает ущерб в случае кражи учетных данных и, в целом, обеспечивает защиту задач, подверженных человеческим ошибкам.

6 — Использование внешнего идентификатора

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

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

7 — Не храните секреты в системе управления исходными текстами

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

Эти секреты являются возможным источником для атаки, и в Интернете существует множество зловредных ботов, которые регулярно сканируют публичные репозитории, например, на GitHub (они публичны и доступны всем), или даже неправильно настроенные ведра S3 (неправильные разрешения, публичный доступ) в поисках секретов для эксплуатации учетных записей или сервисов.

Суть в том, что всегда игнорируйте секреты в файлах .gitignore, а еще лучше старайтесь хранить и извлекать их программно из безопасных хранилищ, таких как System Vault или сервисы вроде AWS Secret Manager.

8 — Регулярно ставьте заплатки и обновляйте свою ОС

Очень важно понимать, что каждый день во многих программах или даже в коде ОС обнаруживаются новые уязвимости, которые потенциально могут быть использованы для получения доступа к вашей системе, получения важной информации и злонамеренных действий от вашего имени. Это особенно актуально, когда вы являетесь разработчиком и у вас установлены такие инструменты, как npm.

Чем больше приложение содержит активно используемых библиотек сторонних разработчиков, тем выше шансы подвергнуться уязвимости.

Чтобы избежать уязвимостей, всегда старайтесь следить за тем, чтобы ваше программное обеспечение и ОС были исправлены и обновлены.

Следите за предупреждениями сборки при компиляции решения и проверяйте сообщения npm при установке новой библиотеки. Обновляйте их по мере необходимости.

Если вы храните свой проект на GitHub, проверяйте сообщения DependaBot, они обычно содержат ценную информацию об уязвимостях, найденных в вашей кодовой базе.

Повышайте культуру безопасности в своей организации

Как описано в этой статье блога Натана Кейса, очень важно быть вовлеченным в цикл разработки, повышать осведомленность вашей организации о проблемах безопасности, лучших практиках, а также стратегиях предотвращения и смягчения последствий кражи учетных данных. Более того, важно поощрять использование стандартных инструментов для унификации и облегчения процессов разработчиков. Что касается локального управления учетными данными AWS, Leapp приходит на помощь со своим настольным приложением и интерфейсом командной строки. Он определяет последовательный способ управления конфигурацией доступа, сохраняет конфиденциальную информацию в зашифрованном виде и генерирует временные учетные данные, которые могут быть использованы инструментами разработчика, такими как AWS CLI, для выполнения операций в облаке.

Вот и все, друзья!

Я надеюсь, что вы найдете эту статью полезной для внедрения некоторых лучших практик в ваш ежедневный рабочий процесс, и что она дала возможность задуматься о некоторых вопросах безопасности, которые могут касаться вашей организации. Отзывы и комментарии всегда приветствуются, поэтому не стесняйтесь и не стесняйтесь писать мне прямые сообщения или обращаться в наш Slack-канал Leapp.

Помните, что AWS безопасен лишь настолько, насколько слабы учетные данные, установленные для ваших разработчиков.