Devsecops — Cis Benchmark Для Docker И Docker Bench Для Безопасности: Почему, Как И Когда?

Я только что узнал о Docker Bench для безопасности и Тест CIS для Docker Community Edition.

Почему, как и когда я должен использовать эти инструменты?

#докер #devsecops

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

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

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

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

ИМХО, если вы обучаете контейнерам с точки зрения разработчика, стоит указать на такие инструменты. Конечно, по моему опыту, разработчики совершенно не осознают, что запуск контейнеров, которые они нашли в Docker Hub, от имени пользователя root — не самый разумный способ обеспечить безопасность. Я ожидал бы, что такие инструменты будут подробно рассмотрены в курсах, обучающих аналитиков безопасности аудиту систем, использующих Docker.

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

Тем не менее, я лично считаю, что советы CIS неоднозначны при работе с Docker. Некоторые из предложений выглядят как копирование рекомендаций, данных для обеспечения безопасности физических физических систем, а не изолированного приложения. И некоторые из рекомендуемых практик, странные вещи, такие как отказ от использования ADD in a Dockerfile, have little security reasoning (anything you can include with an COPY tar, который вы могли бы включить в ADD of a full directory) and will flag just about every image you are running since ADD используется в качестве первого шага почти каждого базового изображения. Они дают список других советов, которые практически не связаны с безопасностью и представляют собой всего лишь рекомендуемый параметр конфигурации, который нельзя применять во всех средах.

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

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