Ваш уровень облачной безопасности определяется в коде задолго до того, как что-либо будет развернуто. Открытость хранилища, наличие у IAM-роли разрешений с подставочными знаками, а также правильное шифрование и изоляция производственной базы данных определяются в Terraform, OpenTofu, CloudFormation или манифестах Kubernetes за несколько дней до того, как ресурсы фактически появятся. Управление инфраструктурой как кодом (IaC) — это способ контролировать то, что разрешено указывать в этих файлах.

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

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

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

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

Что мы рассмотрим:

Что такое управление IaC и почему оно относится к сфере ответственности лидеров по безопасности?
Четыре столпа руководства
Как расставить приоритеты, когда все кажется срочным
Метрики, доказывающие эффективность руководства
Типичные ошибки, с которыми сталкиваются новые лидеры по безопасности
Управление IaC — это набор элементов контроля, которые гарантируют, что ваш инфраструктурный код создает инфраструктуру, которая является безопасной, соответствует требованиям и ожиданиям как до, так и после развертывания.
Оно относится к безопасности, потому что рискованное решение теперь принимается в текстовом файле, а не в консоли.
Четыре столпа по порядку: измерение дрейфа и покрытия политиками, устранение пробелов в аудиторском следе, внедрение защитных механизмов политик в виде кода в пайплайн, проведение обзоров доступа с постоянной периодичностью.
Ранжируйте бэклог по произведению радиуса поражения на вероятность и сначала исправляйте многократно используемые паттерны.
Отслеживайте покрытие, дрейф и долю изменений, проходящих через IaC. Игнорируйте сырые подсчеты находок.

Что такое управление IaC и почему оно относится к сфере ответственности лидеров по безопасности?

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

До развертывания управление означает проверку кода на соответствие вашим правилам, пока он все еще находится в виде пулл-реквеста: никаких публичных бакетов, никаких незашифрованных томопов, никаких групп безопасности, открытых для 0.0.0.0/0 на порту 22 — всего того, с чем ваша организация решила не мириться.
После развертывания это означает, что вы можете ответить на базовые вопросы о работающей среде. Соответствует ли работающая инфраструктура коду? Кто изменил ее последним? Можете ли вы доказать это аудитору без недельного поиска по логам?

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

Когда инфраструктура подготавливалась вручную, безопасность могла проверить результат и выявить проблемы в среде. Теперь рискованное решение — политика IAM с подставочными знаками или отключенное логирование — могло быть принято в текстовом файле, который разработчик объединил в случайный полдень.

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

Есть и практическая причина. Разработчики быстро продвигаются с IaC, в чем и заключается вся его суть.

Я помню, как во времена VMware создавал шаблоны ВМ и золотые образы, будучи уверенным, что предварительное создание машины ускорит развертывание. Это помогало, но вы все равно клонировали шаблон, а затем дорабатывали каждый вручную. IaC находится на другом уровне. Один модуль может поднять всю среду, включая сеть, за то время, которое раньше уходило на настройку одного сервера, а затем использоваться повторно в десятках проектов.

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

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

Столп 1: Измерьте дрейф и покрытие политиками в первую очередь

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

Инвентаризация

Сначала найдите все места, где определяется инфраструктура. Это означает очевидные репозитории Terraform и CloudFormation, а также чарты Helm, манифесты Kubernetes, проекты Pulumi, которые кто-то из команды работы с данными запустил, и приложение CDK, которое понимает только один человек.

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

Измерение дрейфа

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

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

Отображение покрытия политиками

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

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

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

Столп 2: Устраните пробелы в вашем аудиторском следе

Как только вы узнаете, что существует, следующий вопрос, который задаст аудитор или специалист по реагированию на инциденты — кто это изменил, когда и почему.

В зрелой конфигурации IaC вы можете получить ответ на этот вопрос из трех объединенных источников: истории изменений кода в Git, логов CI/CD, которые показывают, что и кем было применено, а также записей самого облачного провайдера, таких как CloudTrail или журнал действий Azure. Когда они совпадают, у вас есть четкая картина каждого изменения.

Пробелы возникают там, где они не совпадают. Самый распространенный случай — это изменение вне основного процесса: кто-то с доступом к консоли изменяет ресурс напрямую, поэтому запись в CloudTrail есть, а соответствующего коммита в Git и запуска пайплайна нет.

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

Затем возникает проблема атрибуции. Пайплайны обычно применяют изменения через учетную запись службы или роль CI, что означает, что в ваших облачных логах отображается «terraform-ci внес 400 изменений» без какой-либо связи с человеком, который одобрил слияние.

Устранение этого пробела означает сопоставление запуска пайплайна с запросом на слияние (pull request) и человеком, который нажал кнопку одобрения. Некоторые команды передают метаданные коммита на этап применения, чтобы цепочка оставалась связанной; как минимум, убедитесь, что логи пайплайна хранятся столько же времени, сколько и облачные логи, и что вы можете связать их по идентификатору запуска.

Стоит обратить внимание еще на несколько уязвимостей:

Принудительные пуши (force-pushes), которые перезаписывают историю в ветках IaC
Прямые правки файла состояния Terraform — они могут изменить то, чем управляет код, не затрагивая сам код
Экстренный доступ (break-glass) — предоставление прав администратора во время инцидента, который предполагается проверять после, но это делается редко

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

Столп 3: Внедрение защитных механизмов «политика как код» в пайплайн

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

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

Инструменты грубо делятся на:

Движки политик общего назначения — Open Policy Agent (с его языком Rego) и HashiCorp Sentinel
Специализированные сканеры IaC — Checkov, Trivy и KICS, которые поставляются с большими библиотеками заранее написанных проверок
Контроллеры допуска Kubernetes — Kyverno и Gatekeeper
Защитные механизмы облачного провайдера, упомянутые выше, — политики управления службами AWS (SCP), политика Azure и политика организации GCP; отличная страховка, поскольку они применяются даже к ресурсам, созданным за пределами вашего пайплайна

Два решения определяют, как это работает на практике.

Первое — это то, на каком этапе процесса выполняется проверка. Вы можете запускать сканеры на этапе предварительной фиксации (pre-commit) для быстрой обратной связи на машине разработчика, в качестве обязательной проверки статуса для каждого пулл-реквеста, на этапе планирования (plan), чтобы оценивать реальный набор изменений, и в качестве жесткого барьера на этапе применения (apply). Более ранние проверки позволяют быстрее выявить проблемы; более поздние сложнее обойти. Большинство команд в конечном итоге запускают проверки в нескольких из этих точек.

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

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

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

Столп 4: Превратите проверки доступа в регулярный процесс

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

Составьте список того, кто и что может делать во всей цепочке поставок IaC:

Кто может выполнять слияние (merge) в репозитории, определяющие продакшн
Кто может инициировать или одобрять применение изменений (apply)
У кого все еще есть прямой доступ к консоли или CLI для продакшн-аккаунтов
У кого есть учетные данные для бэкенда состояния — для Terraform это фактически ключи от всего, так как файл состояния содержит сведения о ресурсах, а иногда и секреты
Какие учетные службы и роли CI существуют и что им разрешено делать

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

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

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

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

Запустите оценку из первого столпа, и вы обнаружите больше проблем, чем сможете исправить за этот квартал. Публичные бакеты, избыточные роли, отсутствие шифрования, неуправляемые учетные записи, устаревшие учетные данные служб — все они борются за одно и то же внимание. Инстинкт исправить все сразу — это то, из-за чего программы буксуют.

Оцените по двум критериям: какой ущерб может нанести проблема и насколько легко ее использовать прямо сейчас.

Бакет S3, открытый для публичного интернета, получает высокие оценки по обоим критериям. В первую очередь.
Слишком широкая роль IAM, доступная только из внутренней сети, серьезна, но ее не так просто использовать немедленно. На ступень ниже.
Отсутствие тега ресурса важно для управления, но из-за него вас не взломают. Это может подождать.

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

У столпов есть своя последовательность:

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

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

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

Покрытие политиками — это процент определенных вами правил безопасности, которые инструмент реально применяет к инфраструктуре как коду (IaC). Это прямой показатель того, как со временем сокращается разрыв первого компонента. Наблюдайте за тем, как он растет по мере того, как вы превращаете правила со страниц вики в обязательные проверки.

Дрифт (отклонение) измеряется двумя показателями:

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

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

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

Что касается самого пайплайна, отслеживайте еще два:

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

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

Несколько ошибок совершаются снова и отново теми, кто берется за это впервые. Знание их заранее обходится дешевле, чем обучение на собственном опыте:

Отношение к управлению как к проекту с конечной датой — это постоянная функция. Устраненный дрифт возвращается, добавляются новые сервисы, а права доступа расползаются, стоит только потерять бдительность. Команда, которая проводит оценку один раз, исправляет найденное и объявляет о победе, снова сталкивается с дрифтом в течение квартала.
Покупка инструмента до проведения оценки — пропуск первого компонента и переход сразу к сканеру кажется эффективным шагом, но без понимания пробелов в покрытии и самых серьезных рисков вы не сможете определить, какой инструмент подходит или какие правила включать в первую очередь. В итоге вы получаете дорогой продукт, выдающий сотни малоценных предупреждений.
Слишком быстрое ужесточение контроля — жесткие блокировки в первый день, до настройки политик и понимания их разработчиками, быстро вызывают недовольство, а это недовольство превращается в давление с целью вообще все отключить. Сначала предупреждайте, а блокируйте уже после того, как исчезнет лишний шум.
Оставление файла состояния без защиты — состояние Terraform содержит конфиденциальные детали ресурсов, а иногда и секреты в открытом виде, и его можно отредактировать, чтобы изменить управляемое кодом содержимое без затрагивания самого кода. Множество аккуратных команд защищают свои репозитории и пайплайны, оставляя бэкенд состояния со слабыми разрешениями. Относитесь к нему как к конфиденциальным производственным данным.
Недооценка процесса обработки исключений — без четкого и фиксируемого способа получения легитимного исключения люди придумывают «грязные» обходные пути: закомментированную проверку, пропущенный этап пайплайна, ресурс, полностью выведенный из-под управления IaC. Быстрый путь для исключений с датой окончания и назначенным ответственным не дает обычному давлению разрушить ваши средства контроля незаметным для вас образом.
Попытка справиться со всем в одиночку — это актуально именно для инженеров по безопасности. Управление IaC затрагивает рабочие процессы разработчиков, платформенные инструменты и архитектуру пайплайнов, поэтому навязывание его со стороны безопасности без поддержки платформ и разработчиков приводит к средствам контроля, которые люди тихонько обходят. Жизнеспособной оказывается лишь та версия, которой владеют совместно: безопасность пишет правила, а платформа внедряет их в привычные для разработчиков рабочие процессы.

Spacelift — это платформа оркестрации инфраструктуры, которая управляет полным жизненным циклом как традиционной инфраструктуры как кода, так и инфраструктуры, подготавливаемой с помощью ИИ, поддерживая такие инструменты, как OpenTofu, Terraform, Ansible, Pulumi, Kubernetes и CloudFormation.

Безопасность является одним из главных приоритетов Spacelift. Продукт включает в себя такие функции, как политика как код, шифрование, единый вход (SSO), многофакторная аутентификация (MFA) и пулы частных воркеров. Spacelift имеет сертификат SOC 2 Type II и предоставляет артефакты соответствия и безопасности, включая ресурсы GDPR и DPA через Spacelift Trust Center.

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

Сила Spacelift заключается в полностью автоматизированном подходе. Как только вы создали стек Spacelift для своего проекта, изменения в файлах инфраструктуры как кода в вашем репозитории автоматически применяются к вашей инфраструктуре.

Для некритичных рабочих нагрузок, таких как тесты, концептуальные проверки (POC) и демоверсии, Spacelift Intelligence добавляет уровень на базе ИИ, который обеспечивает подготовку инфраструктуры на естественном языке, диагностику и оперативную аналитику, позволяя разработчикам запрашивать инфраструктуру без написания конфигурационного кода, в то время как платформенные команды сохраняют полный контроль и видимость.

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

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

С помощью Spacelift вы также получаете:

Политики (на базе Open Policy Agent) — вы можете контролировать, сколько одобрений требуется для запуска, какие виды ресурсов вы можете создавать и какими параметрами эти ресурсы могут обладать, а также управлять поведением при открытии или слиянии пул-реквеста.
Многомодульные рабочие процессы IaC — комбинируйте Terraform с Kubernetes, Ansible и другими инструментами инфраструктуры как кода (IaC), такими как OpenTofu, Pulumi и CloudFormation, создавайте зависимости между ними и делитесь выходными данными.
Создание инфраструктуры самообслуживания — вы можете использовать Blueprints (чертежи) и шаблоны для создания инфраструктуры самообслуживания; заполните форму для подготовки инфраструктуры на основе Terraform и других поддерживаемых инструментов.
Подготовка и диагностика на базе ИИ — Spacelift Intelligence добавляет подготовку на естественном языке, диагностику и операционные инсайты как в традиционные, так и в управляемые ИИ рабочие процессы, помогая вам создавать безопасную и соответствующую требованиям инфраструктуру в масштабе.
Интеграция с любыми сторонними инструментами — Вы можете интегрировать свои любимые сторонние инструменты и даже создавать для них политики. Например, узнайте, как интегрировать инструменты безопасности в ваши рабочие процессы с помощью пользовательских входных данных (Custom Inputs).

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

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

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

Команды, у которых это приживается, — это те, которые делают путь по правилам самым простым путем, так что для разработчика, отправляющего код в пятницу в 17:00, безопасный выбор также является наименее трудоемким. Сделайте это правильно, и большая часть остального разрешится сама собой.

Часто задаваемые вопросы

Что такое управление IaC (IaC governance)? Управление IaC — это структура политик, элементов контроля и процессов, которые поддерживают соответствие инфраструктурного кода стандартам безопасности, соответствия и операционной деятельности на протяжении всего его жизненного цикла. Обычно оно объединяет политику как код, контроль доступа, экспертные оценки и автоматизированное сканирование для обеспечения защитных барьеров до того, как изменения попадут в продакшн.

Что такое управление IaC?

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

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

Как часто следует запускать обнаружение дрейфа?

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

Требует ли SOC 2 ежеквартального пересмотра доступа? Не напрямую. SOC 2 требует периодического пересмотра доступа в соответствии с пунктами CC6.2 и CC6.3, но оставляет периодичность на усмотрение организации с учетом рисков. Ежеквартальные проверки являются отраслевым стандартом для привилегированного доступа, в то время как для групп с более низким уровнем риска по-прежнему принимаются полугодовые или ежегодные проверки.

Требует ли SOC 2 ежеквартального пересмотра доступа?