Задачи по обеспечению безопасности инфраструктуры, которые разработчики могут автоматизировать

Для разработчиков главное — скорость, от нее зависит их производительность. Именно поэтому безопасность не всегда является для них главным приоритетом — она воспринимается как замедление или преграда, пишет на портале TechBeacon Гай Айзенкот, старший директор по управлению продуктами платформы Prisma Cloud компании Palo Alto Networks.

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

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

1. Исправление неправильных конфигураций в открытом исходном коде

Обычно разработчики и команды DevOps опираются на Open Source-модули для быстрого масштабирования нативных облачных приложений и инфраструктуры. Модули Terraform, шаблоны CloudFormation и Helm-диаграммы Kubernetes — все это примеры строительных блоков инфраструктуры как кода (IaC), которыми можно легко делиться для повторного использования:

• Terraform стала одной из ведущих систем обеспечения разработки мультиоблачных решений. Ее реестр, который в июне 2019 г. насчитывал всего 50 модулей, на данный момент содержит более 6500 модулей;
• Helm — лучший выбор для управления приложениями Kubernetes, снижающий необходимость в написании и управлении Kubernetes YAML вручную. В исследовании «Cloud Native Computing Foundation Survey 2020» 63% респондентов заявили, что Helm является их инструментом для упаковки приложений Kubernetes;
• CloudFormation является AWS-native и позволяет изменять ресурсы AWS контролируемым и предсказуемым образом. Используя новый публичный реестр AWS CloudFormation Public Registry, вы можете использовать расширения сторонних разработчиков для автоматизации инициализации ресурсов инфраструктуры и приложений без необходимости использования пользовательских скриптов или ручных процессов.

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

В ходе собственного исследования мы обнаружили, что почти половина модулей Terraform с открытым исходным кодом содержит неверные конфигурации. Кроме того, при сканировании Artifact Hub мы обнаружили, что неверные конфигурации содержали 71% из 618 отсканированных репозиториев Helm и 46,5% из 2300 отсканированных диаграмм Helm.

Использование Open Source-ресурсов облегчает разработчикам процесс создания и модификации IaC. Но, опять же, главное для них — скорость и эффективность. В идеальном мире разработчик мог бы просто взять любой старый график Helm из Artifact Hub или GitHub и сразу же узнать, безопасен ли он. Должны быть четкие оговорки или указания на то, что нужно сделать, чтобы защитить модуль, если он не безопасен.

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

2. Интеграция защитных ограждений в весь конвейер

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

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

Возможно, самым простым местом для внедрения автоматизации в масштабах организации или команды являются конвейеры непрерывной интеграции и доставки (CI/CD). Добавление автоматизированных проверок в конвейер, через который все ваши разработчики проталкивают код, — лучший способ гарантировать, что только хорошо написанный код попадет в ваш репозиторий.

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

Используйте все свои инструменты по максимуму.

Ваша система контроля версий также обладает некоторыми скрытыми суперспособностями автоматизации безопасности. Например, вы можете сэкономить немного времени, интегрировавшись с сервисом, который сканирует ваш код перед запуском в конвейер CI/CD при создании новых коммитов или запросов pull/merge. Ожидание завершения сборки только для того, чтобы она завершилась неудачей, — не самое лучшее использование времени, поэтому более раннее введение защитных мер безопасности позволяет получить более итеративную обратную связь.

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

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

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

3. Выявление нарушений нормативно-правового соответствия

Инициативы компании по обеспечению соответствия нормативным требованиям зависят от отрасли, местоположения, типа собираемых данных и т. д. Для поддержания соответствия нормативным требованиям компании должны постоянно демонстрировать, что они учли определенный перечень рисков. Этот список может быть длинным. Системы обеспечения соответствия, такие как HIPAA, PCI-DSS, SOC-2 и др., содержат сотни, а то и тысячи страниц руководств и политик.

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

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

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

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

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

4. Разметка облачных ресурсов, от кода к облаку

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

Вам нужно быстро определить веб-серверы из тысяч или десятков тысяч ресурсов в регионе в вашем аккаунте AWS? Теги помогут вам в этом. Или, если вы хотите организовать несколько ресурсов в разных службах AWS, вы можете использовать теги для создания групп ресурсов.

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

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

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

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

5. Мониторинг разрешений IAM

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

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

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

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

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

Уменьшить трение

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

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