Контейнеры повсюду: как их защитить?

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

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

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

Проблемы безопасности при развертывании контейнеров

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

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

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

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

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

Как обезопасить свои контейнеры

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

Обеспечьте видимость ваших контейнеров

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

Не доверять программному обеспечению контейнера — отличная отправная точка. Вы должны проверить это очень тщательно, чтобы понять, «откуда они берутся, как они были произведены и их соответствующие источники», как указал Дирк Хондел, вице-президент VMware, на Саммите лидеров открытого исходного кода 2019 года.

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

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

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

Контролировать корневой доступ

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

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

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

Проверьте время выполнения контейнера

Национальный институт стандартов и технологий (NIST) SP 800-190 «Руководство по безопасности контейнеров приложений» указывает, что среды выполнения контейнеров также уязвимы для атак. Хотя это не является обычным пробелом в безопасности, NIST указывает, что уязвимости безопасности во время выполнения контейнера могут быть «особенно опасными », если они допускают сценарии, в которых вредоносное программное обеспечение может атаковать ресурсы в других контейнерах и самой хост-ОС.

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

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

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

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

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

Укрепите операционную систему

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

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

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

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

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

Безопасность контейнеров превыше всего

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