Как автоматизировать рекомендации AWS IAM с использованием принципа наименьших привилегий

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

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

Неудивительно, что пользователи — то есть ваши клиенты — это то, что отличает Business™ от Fun Side Project™. Если вы не осведомлены об уязвимостях безопасности и передовых практиках, связанных с вашим поставщиком облачных услуг, вы можете столкнуться с лучшим способом потерять указанных клиентов: утечка данных.

Klotho — это набор инструментов для разработчиков, который поможет вам с обеими частями этого уравнения:

а) абстрагироваться от сложности создания облачных приложений (узнайте больше об этом здесь) за счет создания готовых к развертыванию шаблонов инфраструктуры как кода в Pulumi или Terraform на основе аннотаций в код вашего приложения и

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

Генерация IaC из кода приложения довольно изящна! Но…наименьшие привилегии? Опять эта фраза. Это явно кажется частью какого-то понятия AWS Best Practices 101, но почему? Как мы этого достигаем? Как Клото помогает? Ответим на эти.

IAM и принцип наименьших привилегий

«IAM Кто я есть».

AWS Identity and Access Management (IAM) — это веб-сервис, который позволяет пользователям назначать детальные разрешения AWS людям и приложениям. Вы используете IAM, чтобы убедиться, что кто-то является тем, кем он себя называет (аутентификация), и контролировать его разрешения на использование ресурсов, которые он хочет использовать (авторизация).

Вкратце: вместо прямого предоставления пользователям доступа к ресурсам самым безопасным способом предоставления доступа в AWS является использование ролей и политик IAM.

• Роль – это определение доверенного объекта и того, что он может делать. Принятие роли похоже на надевание костюма и получение всех связанных с ним привилегий.
• Роли не назначаются человеку с паролем на постоянной основе, а только предполагаются(через AssumeRole call) на короткое время службами (например, лямбда-функцией). Затем пользователь службы получает временные учетные данные безопасности, чтобы делать то, что ему нужно для своего сеанса (кроме получения фактического токена сеанса).
• Для авторизации у роли есть доступ, предоставленный ей политиками — разрешения на доступ к другим ресурсам AWS (например, корзинам S3), — которые прикреплены к ней.

Собираем все вместе: хотите, чтобы ваше приложение, развернутое в экземпляре EC2, читало из корзин S3?Приложение должно взять на себя роль, к которой привязана политика он разрешает s3:GetObject вызовы API.

Существует более 200 сервисов AWS и более 7000 различных вызовов API AWS, при этом некоторым, казалось бы, простым функциям неинтуитивно требуется доступ ко всем видам других сервисов AWS, каждый из которых имеет свои особенности. Просто взгляните, например, на Документы AWS IAM по действиям, ресурсам и ключам условий.

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

Что делает это идеальным переходом в…

Ползучесть привилегий

Слишком часто доступ к этим учетным записям пользователей root и привилегированным ролям IAM предоставляется гораздо шире, чем это действительно необходимо. Хуже того, эти привилегии часто используются разово или вообще не используются, но все равно остаются, либо потому, что о них забыли за годы разработки, либо из-за менталитета «лучше иметь это и не нуждаться в этом».

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

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

💡 Нарушение Capital One в 2019 году — это поучительная история о том, что произойдет, если ваши разрешения слишком широки. Это произошло, когда злоумышленник использовал скомпрометированный сервер (через подделку запросов на стороне сервера), получил учетные данные AWS с помощью метаданных EC2 и обнаружил, что сервер имеет чрезмерные привилегии для доступа к корзинам S3, некоторые из которых содержат данные клиентов.

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

Наименьшие привилегии — что, почему и как.

Что — достаточно безопасный, сбалансированный вариант по умолчанию.

Принцип наименьших привилегий (PoLP) берет свое начало в документе Министерства обороны США Критерии оценки доверенных компьютерных систем Министерства обороны в 1985 году и был в основном расширением информации о необходимости знать. только на основе», чтобы охватить секретные данные в эпоху цифровых технологий.

Техническое описание этого метода заключается в том, что вы хотите предоставить пользователям и системам доступ толькок ресурсам, которые им нужны для их варианта использования, на уровнях доступа, соответствующих их вариант использования. Например, политика IAM имеет разрешения на доступ к определенной корзине S3 (ресурс) только с действиями «Чтение» (уровень доступа).

Идеальный? Нет. Но всегда безопаснее начинать с роли с минимальными правами доступа и добавлять разрешения по мере необходимости, чем начинать с root-доступа и удалять разрешения, делая бреши одним недосмотром или неуместным секретным ключом.

Почему? Они ограничивают радиус взрыва.

В форме «инфраструктура как код» потенциально опасная, слишком разрешительная политика IAM будет выглядеть примерно так:

Это позволит участнику IAM (роли или пользователю) запускать GetObject из любогосегмента S3 в аккаунте AWS. Этот чрезмерно разрешительный доступ к корзинам S3 — т. е. широкий радиус действия — вместе с SSRF стал причиной взлома Capital One.

Как мы могли бы исправить это? Что ж, мы могли бы вручную переписать эту политику IAM с минимальными привилегиями.

Теперь мы ограничили действие S3:GetObject конкретным сегментом S3, к которому вашей роли требуется доступ, а это означает, что даже если кто-то получит несанкционированный доступ, у него не будет доступа для выполнения любые повреждения за пределами этого конкретного ведра S3. Вы ограничили радиус взрыва, даже если бомба действительновзорвалась.

Как — это чертовски сложно.

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

В большинстве случаев вместо этого вы будете делать один (или все) из них:

1. Создайте всех новых пользователей/организаций AWS, чтобы предоставить каждой команде разработчиков собственную учетную запись в песочнице с полными правами администратора, вместо того, чтобы возиться с формулированием гранулированных наименее привилегированных IAM. Эй, плохо настроенная роль/политика представляет гораздо меньший риск в песочнице, чем в рабочей среде, верно?
2. Стремление к безопасности сдерживает разработку, поэтому просто добавьте Управляемые политики AWS к своим инстансам EC2, чтобы IAM перестал ломать ваше приложение, говоря себе, что вы напишете настоящую политику в другой раз (а вы этого не сделаете).
3. Полностью откажитесь, делайте наилучшие предположения относительно вызовов API AWS, которые вы выполняете, и используйте для них подстановочные знаки, чтобы вместо этого вы могли заняться созданием интересных вещей.

Чтобы было ясно, ни один из этих подходов не является идеальным, но отрасль в ее нынешнем состоянии оценивает инженеров только с точки зрения скорости и количества реализованных функций, а небезопасности. Штраф в размере 80 миллионов долларов, уплаченный Capital One, вполне мог быть меньше, чем стоимость «правильного поведения». Пока это не изменится, менеджеры будут поощрять тот подход, который окажется быстрее.

Так что… не делай ничего из этого. Вместо этого используйте Клото.

Наименьшие привилегии IAM в секундах с Klotho

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

На самом деле, если приложению требуется хранилище KV для карты в памяти, разработчикам нужно буквально использовать только аннотацию в своем коде, чтобы обозначить свое намерение для этого…

… и автоматизация должна расшифровать это намерение только из кода этого приложения, проанализировав его, чтобы он означал:

«Привет. Мне нужен экземпляр DynamoDB для некоторых книг, которые мне нужно хранить, с таблицей с именем «книги» и безопасным CRUD-доступом к ресурсу по адресу arn:aws:dynamodb:us-west-2:123456789012:table/books и его индексу. , потоковая передача, резервное копирование и экспорт. Спасибо!»

Вот и все. Когда вы компилируете этот код с помощью Klotho, он генерирует из него инфраструктуру как код и автоматически формулирует для вас политики IAM наименее привилегированным образом.

Klotho обладает неотъемлемыми преимуществами по сравнению с другими инструментами для управления IAM, потому что…

1. Вместо того, чтобы допускать сбой при первом запуске, а затем проверять журналы CloudWatch постфактум, чтобы решить, какие разрешения необходимы, он может напрямую проанализировать ваш аннотированный код приложения, чтобы выяснить, что вы имели в виду, а затем динамически сформулируйте безопасную, передовую политику IAM с минимальными привилегиями для вашего облачного приложения на основе этого анализа, когда оно генерирует код Pulumi/Terraform.
2. По мере роста вашего приложения и неизбежного изменения ваших требований к службам и связанных с ними разрешений анализ кода вашего приложения, проведенный Klotho, будет автоматически корректировать облачные зависимости и применять минимальные привилегии ко всем из них.

Продолжая наш пример, тогда:

Klotho использует параметры Pulumi для динамического создания ресурсов на основе вашего кода, включая роли, политики и разрешения, которые гарантируют, что участники имеют доступ только к тому, что им нужно, динамически заполняя ARN, чтобы ваше приложение могло выполнять операции CRUD в этих конкретных таблицах. , индексы, потоки, резервные копии и экспорт…

…Вместо утомительного написания той же политики IAM вручную. Для каждого ARN, каждой таблицы.

Может ли Klotho заменить инструменты облачной безопасности?

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

Итак, что именно делает Клото, а что нет? Давай выясним.

Что делает Клото…

• С Klotho разработчикам нужно только определить ресурсы, к которым им нужен доступ, а Klotho абстрагирует сложность политик IAM от своих процессов разработки, генерируя достаточно безопасные значения по умолчанию при создании готовой к развертыванию облачной версии локального приложения. .
• Операторам больше не нужно применять слишком строгую политику IAM по умолчанию, не посоветовавшись сначала с командой приложения или продуктом, или диагностировать страницы журналов Cloudwatch позже, чтобы увидеть, какие разрешения были нарушены, просмотреть документы, поговорить со всеми разработчиками — промыть и повторить.
• Klotho автоматически вносит изменения в IaC и ваши разрешения в зависимости от того, как меняется ваше приложение по мере его роста, и каждый раз автоматически создает наименее привилегированные политики IAM.
• Klotho создает только роли и разрешения IAM, а не новых пользователей. Таким образом, вы сохраняете гибкость, поскольку любому будущему пользователю в вашей организации, например сторонним аудиторам, может быть предоставлен специальный временный доступ через роли без необходимости настраивать для них новые учетные данные root.
• Вы полностью сводите на нет один вектор атаки, потому что с IaC от Klotho и автоматически сгенерированным IAM вам никогда не придется встраивать ключи доступа/секретные ключи AWS в код вашего приложения (где их может быть трудно сменить, а .gitignore goof-ups может подвергнуть их вредоносному ПО). актеры).

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

…и не делает.

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

Таким образом, идеальный рабочий процесс AWS должен состоять в том, чтобы использовать Klotho для создания IaC (в конвейере CI/CD) и наименее привилегированного IAM на основе кода вашего приложения… периодические проверки прав доступа. RepoKid использует под капотом AWS Access Advisor, чтобы определить, к скольким сервисам и ресурсам AWS имеет доступ субъект IAM, сколько из них он использовал за последние X дней/месяцев, и автоматически отменяет устаревшие политики.

В итоге

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

Непростая задача — заставить каждого разработчика, которого вы нанимаете, работать с AWS IAM в дополнение к коду приложения и постоянно реконструировать ваши приложения, чтобы обеспечить их безопасность. Здесь Клото может помочь вам двигаться быстрее и сэкономить время и деньги, особенно если ваши конкуренты более склонны к риску.

Используя автоматизацию Klotho для предоставления облачной инфраструктуры через инфраструктуру как код (Klotho может создавать IaC для Pulumi, Terraform или aws-cdk) и автоматически генерировать безопасные значения IAM по умолчанию, вы можете перейти к использованию облака в своем приложении. за секунды — предоставляя пользователям и процессам только минимальный уровень доступа, необходимый для выполнения их задач, уменьшая поверхность атаки и сводя к минимуму радиус взрыва, если произойдет немыслимое.

Дополнительная литература