Технические учетные записи в облаке могут стать основной мишенью для злоумышленников. В этой статье рассматриваются шаблоны аутентификации для защиты ваших учетных записей от несанкционированного доступа и предлагаются конкретные примеры использования этих шаблонов в Azure и AWS.
Лабиринты — это испытание, по крайней мере, если не смотреть с высоты птичьего полета. Аутентификация технических учетных записей представляет собой аналогичную проблему для облачных инженеров.
Технические учетные записи являются основой конвейеров CI/CD, инфраструктуры как кода и любой формы автоматизации ИТ- или бизнес-процессов. Они позволяют инженерам развертывать и настраивать полноценные облачные арендаторы или приложения. Этот факт означает, что хакеры могут использовать их не по назначению для уничтожения целых облачных клиентов и ландшафта корпоративных приложений. Технические учетные записи для резервного копирования имеют доступ ко всем неконфиденциальным и конфиденциальным данным , что является золотой жилой для хакеров, если они смогут завладеть любой из них. Короче говоря, технические отчеты при неправильном использовании оказывают воздействие ядерной бомбы.
В этой статье я представляю наиболее актуальные шаблоны безопасности и аутентификации, а также конкретные примеры функций контроля доступа для использования в Azure и AWS, чтобы помочь облачным инженерам и архитекторам сориентироваться в лабиринте.
Межсетевые экраны представляют собой типичный, очень грубый первый фильтр и уровень защиты (рис. 1). Они блокируют явно нелегитимный сетевой трафик, например, трафик из Антарктиды во внутреннюю ERP-систему компании в Италии. Второй, более детальный фильтр или уровень — это аутентификация. Аутентификация гарантирует – путем проверки личности пользователя – что только нужные люди (или системы) имеют доступ. Это основная тема, которую мы здесь обсудим.
Аутентификация с использованием удостоверений облачной платформы
Аутентификация в облаке очень проста, если все работает в рамках одной облачной экосистемы. Большинство предприятий не соблюдают это условие. У них смешанные рабочие нагрузки: одно ведущее облако, небольшие точки с другими поставщиками облачных услуг , локальные серверы и внешние веб-сервисы. Таким образом, инженерам приходится ориентироваться в различных шаблонах контроля доступа.
Самый безопасный подход к аутентификации в облаке — беспарольный и основан на удостоверениях, управляемых облаком, или, в терминологии Microsoft Azure, управляемых удостоверениях . Шаблон устраняет необходимость аутентификации и, следовательно, риск взлома и кражи секретов. Инженеры просто предоставляют права доступа к облачным рабочим нагрузкам в облачном IAM. Функция Azure, обращающаяся к Cosmos DB, является типичным сценарием для этого шаблона.
Паттерн также работает для приложений, работающих на облачной ВМ , и для доступа к ресурсам в том же облаке, но лишь с небольшой адаптацией. Облачный IAM не знает приложений на ВМ, поэтому назначить роли приложениям невозможно. Но есть хитрость: облачная платформа знает ВМ, и мы можем предоставить права доступа к ВМ. Тогда приложения, работающие на конкретной ВМ, смогут наследовать или использовать права доступа ВМ.
В Azure это работает следующим образом: во-первых, виртуальной машине требуется удостоверение, чтобы сообщить о ней облачному IAM. Далее мы назначаем этой виртуальной машине необходимые роли, например роль читателя для конкретной учетной записи хранения. Теперь приложения, работающие на этой виртуальной машине, могут запрашивать роли, предоставленные виртуальной машине, без аутентификации — простое решение, по крайней мере, для самостоятельно разработанного или стандартного программного обеспечения, реализующего этот подход.
Этот подход к аутентификации имеет один важный побочный эффект: каждый компонент, работающий на виртуальной машине, может получить доступ к облачным ресурсам с учетными данными виртуальной машины. Поэтому важно знать, что делают приложения и компоненты, а также защищать их от хакеров. Альтернативно, приложения, работающие на облачной виртуальной машине, могут реализовать следующую стратегию управления доступом.
Аутентификация через представителей платформы
Всё меняется, когда приложение не запускается в облаке, но требует доступа к определённым облачным ресурсам. Самый сложный шаблон управления доступом и аутентификацией для этого сценария основан на представителях приложений в облаке IAM. Microsoft называет их субъектами службы . Внешнее приложение аутентифицирует себя с помощью секретного сертификата. После этого он может получить доступ ко всем ресурсам, к которым имеет доступ субъект-служба.
Существенным преимуществом представителей приложений является прозрачность: облачный IAM знает их и может предоставить отчет со всеми их правами доступа к облаку. Кроме того, работает управление доступом на основе ролей.
На рис. 5 представлена аналогичная конструкция AWS. В то время как Azure строго различает субъекты-службы, такие как удостоверения рабочей нагрузки и учетные записи обычных пользователей, AWS знает учетные записи пользователей, а учетные записи пользователей могут иметь дополнительные ключи доступа для программного доступа приложений.
Слабым звеном в этой конструкции AWS является аутентификация через доступный в Интернете API с использованием всего одного фактора: ключа доступа. Azure работает аналогичным образом: если инженер по ошибке предоставляет такой ключ (или копирует его при увольнении), нежелательный доступ становится детской игрой. Подвергая технические учетные записи такому риску, это нарушает все передовые методы обеспечения безопасности и управления рисками. Ограничения IP-адресов являются решением, т. е. ограничением диапазона IP-адресов, из которого принимаются запросы аутентификации. Внутренний диапазон IP-адресов является очевидной отправной точкой. Функция условного доступа Azure — один из способов реализации таких требований.
Последний вариант актуален для более сложных корпоративных настроек IAM. Существует возможность аутентификации представителя приложения через внешнего поставщика удостоверений, которому доверяет облако IAM. Федерация идентификации рабочей нагрузки Azure AD попадает в эту категорию.
Предоставление локального доступа, управляемого службами
Последний подход к аутентификации в облаке вносит одно существенное изменение: доступ к облачным ресурсам в обход пользователей и ролей в облачном IAM. На рис. 6 представлены два примера того, как Azure реализует этот шаблон, оба связаны с учетными записями хранения. Первый — это ключ доступа. Каждое приложение, знающее ключ (и учетную запись хранения), может подключиться и получить доступ к данным. Это упрощенная модель доступа без ролей.
Второй пример — более сложная функция доступа к учетной записи хранения: подписи общего доступа. Они предоставляют не «реальные» роли, а скорее концепции защиты для ограничения доступа, например, срок действия подписи или диапазоны IP-адресов, с которых разрешен вход в систему (рис. 6, №2).
Шаблон локального доступа, например, с помощью ключей доступа , широко распространен. Для разработчиков это очень удобно: сгенерируйте ключ доступа, добавьте его в свой код и все работает. Зачем иметь дело с лабиринтом аутентификации и рисковать заблудиться, если у вас есть топор и взрывчатка, чтобы расчистить им путь? Однако этот шаблон локального доступа является кошмаром безопасности. У кого какой ключ доступа? Кто манипулировал данными? На простые вопросы практически невозможно ответить, если лишь несколько сервисов и приложений следуют этой схеме. Если быть реалистом: служба безопасности ненавидит этот шаблон, но есть одно оправдание его использованию. Существуют сценарии, в которых все остальные шаблоны не работают.
В заключение, директора по информационной безопасности, менеджеры облачных платформ и архитекторы должны уточнить, какие стратегии контроля доступа к облаку следует продвигать и какой сценарий, а какие следует искоренить из ландшафта корпоративной архитектуры.
Управляемые удостоверения внутри экосистемы безопасны; Представители приложений для доступа к облачным ресурсам также находятся в безопасности, если тщательно проверять аутентификацию. Напротив, управление доступом к конкретным услугам по своей сути сопряжено с более высоким риском. Таким образом, при выборе шаблонов аутентификации для технических учетных записей в облаке выбор наиболее быстрых в реализации вариантов означает облегчение жизни хакеров. Если вы отвечаете за безопасность или архитектуру, вам не следует слишком много слушать скорби инженеров, обеспокоенных необходимостью пройти еще одну короткую лишнюю милю. Технические учетные записи слишком важны для принципа невмешательства в управление доступом.
