Сканирование IaC: фантастическая, но недооцененная возможность обучения

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

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

As Мелинда Маркс из ESG говорится в отчете компании: «83% организаций столкнулись с увеличением количества неправильных конфигураций шаблонов IaC», поскольку они продолжают внедрять эту технологию.

Мы знаем из работы, проделанной Cloud Security Alliance («Главные угрозы для облачных вычислений: вопиющая одиннадцать“) и другие, неправильные конфигурации по-прежнему представляют главный риск в облаке.

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

В небольших командах, где элементы философии DevOps Dev и Ops объединены, это имеет смысл. IaC позволяет этим небольшим командам использовать один и тот же язык — код — для описания всего, что они делают.

Вот почему мы видим абстракции даже более высокого уровня, чем такие инструменты, как Terraform или AWS CloudFormation. CDK AWS и такие проекты, как cdk8s. Эти высокоуровневые абстракции более удобны для разработчиков.

Перспектива эксплуатации/SRE/платформы облачной службы будет сильно отличаться от точки зрения разработчика той же службы. Разработчик посмотрит на службу очередей и погрузится в ее интерфейс — простую конечную точку для добавления и одну для чтения? Продал. Это простая интеграция.

Эта операционная перспектива направлена ​​на поиск краев. Итак, когда эта очередь достигает своего предела? Производительность постоянна или радикально меняется под нагрузкой?

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

В результате именно здесь часто обостряются проблемы безопасности.

Большинство инструментов — коммерческих или с открытым исходным кодом — ориентированы на выявление ошибок в шаблонах инфраструктуры. Эта
хорошая конструкция. Изготовление этой
было бы плохо. Эти инструменты предназначены для получения этих результатов в рамках конвейера непрерывной интеграции/непрерывной доставки (CI/CD).

Это отличное начало. Но это перекликается с той же языковой проблемой.

Кто говорит и кто слушает?

Когда инструмент IaC выявляет проблему, кто будет ее решать? Если это команда разработчиков, достаточно ли у нее информации, чтобы понять, почему это было отмечено как проблема? Если это оперативная группа, изложены ли в отчете последствия проблемы?

Для разработчиков часто бывает так, что они просто корректируют конфигурацию, чтобы пройти тестирование IaC.

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

Нужен контекст. Инструментарий безопасности IaC дает представление о том, что будет (надеюсь) построено. Цель состоит в том, чтобы остановить проблемы до они попадают в производство.

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

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

Например, когда при сканировании указывается, что у правила группы безопасности нет описания, какое это имеет значение? Простое получение предупреждения с надписью «Добавьте описание для контекста» никому не поможет улучшить работу.

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

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

Об авторе

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