Безопасность контейнеров повышается, чтобы справиться с проблемами уязвимостей контейнеров
Контейнерная технология быстро стала повсеместной в ИТ-индустрии, и большинство компаний внедрили контейнерную технологию на том или ином уровне или планируют внедрить ее в ближайшее время. Опрос, проведенный Portworx и Aqua Security, показал, что 87 % опрошенных ИТ-специалистов (по сравнению с 67 % в предыдущем году) используют контейнерные технологии в той или иной степени, при этом более 90 % из них работают в производственной среде. Тенденция к внедрению контейнеров продолжает усиливаться, поскольку предприятия и команды DevOps все больше склоняются к легкости и гибкости облачной модели, которая поддерживает непрерывную интеграцию и развертывание (CI/CD) и архитектуру микросервисов. Сокращение накладных расходов упрощает развертывание контейнеров для выполнения повторяющихся процессов, таких как пакетные задания и функции ETL (извлечение, преобразование и загрузка), которые часто выполняются в фоновом режиме. Однако в течение 2019 года уязвимости контейнерных технологий были резко выявлены, что требует от компаний уделять первоочередное внимание защите контейнеров на нескольких уровнях или рискует раскрыть конфиденциальные данные.
Безопасность контейнеров и уязвимости контейнеров
На вопрос об основных проблемах, с которыми они столкнулись при внедрении контейнеров, 51% респондентов опроса Portworx и Aqua Security назвали безопасность главной проблемой при переходе на облачную модель. На самом деле, многие компании, которых привлекают более низкие затраты и более высокая скорость развертывания контейнерных технологий, часто принимают уязвимости безопасности контейнеров и образов контейнеров как часть риска вместо того, чтобы активно решать проблемы до их возникновения. В отчете Tripwire о состоянии контейнерной безопасности, опубликованном в начале 2019 года, эта проблема была освещена, когда выяснилось, что 47% опрошенных организаций используют уязвимые контейнеры, в то время как колоссальные 46% не уверены, есть ли в развернутых контейнерах уязвимости, о которых они не знали. Шестьдесят процентов всех опрошенных организаций сталкивались с инцидентами безопасности контейнеров в течение следующего года, а 42 процента ограничивали внедрение контейнеров из-за проблем с безопасностью. Колоссальные 98% искали дополнительные возможности безопасности для контейнерных сред.
В феврале обнаружение уязвимости runC, затронувшей Docker, Kubernetes и даже Apache Mesos, показало, что реализации контроля доступа пользователей Docker для ограничения привилегий доступа по-прежнему недостаточно, чтобы помешать злоумышленникам получить root-доступ к хост-серверам. Он выделялся среди многих крупных уязвимостей, обнаруженных в контейнерных средах, как пример того, почему самые популярные контейнерные технологии не были самыми безопасными. Еще одна серьезная уязвимость копирования в Docker была исправлена в ноябре, что подтверждает суть дела. Все эти уязвимости были признаками того, что организациям необходимо взять на себя ответственность за обеспечение того, чтобы они включили безопасность в конвейер DevOps и CI/CD, процесс, известный как DevSecOps. Вместо того, чтобы просто исправлять уязвимости по мере их обнаружения, часто даже после взлома или атаки, организации теперь выделяют ресурсы и профессионалов для решения задачи автоматизации конфигураций безопасности и продуктов в конвейере DevOps.
Kubernetes требует специализированных решений безопасности
Имя, которое у всех на устах с точки зрения оркестровки контейнеров, — Kubernetes, но платформа предлагает только базовые меры безопасности, требуя, чтобы организации сами обеспечивали мониторинг безопасности и соблюдение нормативных требований. Для преодоления этого разрыва были разработаны различные сторонние инструменты, о которых вы можете прочитать здесь. Эксперты указали на несколько серьезных проблем с безопасностью в Kubernetes. Серьезная проблема связана с видимостью, поскольку автоматическое перемещение контейнеров Kubernetes может скрыть проблемы и ошибки конфигурации, а развертывание скомпрометированных образов контейнеров может привести к серьезным нарушениям безопасности, если они не будут обнаружены и немедленно исправлены. Сложность системы также создает проблемы с четкостью прав доступа и разрешений, поскольку разработчикам могут быть случайно предоставлены права на данные, к которым у них не должно быть доступа. Это в сочетании с множеством точек конфигурации может создавать уязвимости, поскольку разработчики допускают серьезные ошибки конфигурации, позволяющие избежать выхода из контейнера.
В этом году было повторно предложено несколько решений для защиты кластеров Kubernetes для защиты модулей от злоумышленников, которые стремятся воспользоваться конфигурациями по умолчанию, позволяющими им выполнять вредоносные операции с содержимым кластеров. Эксперты предлагают использовать минималистскую операционную систему, чтобы предотвратить выполнение вредоносных операций внутри модуля и защитить связь между модулями, чтобы предотвратить распространение вредоносного ПО. Использование пространств имен для каждого приложения в кластере также может ограничивать разрешения и защищать модули. Получение информации о коммуникациях внутри кластера с помощью различных инструментов безопасности, доступных для Kubernetes, может гарантировать наличие надежной системы мониторинга и оповещения.
Безопасность Service Mesh находится на подъеме
Многие организации были виновны в переходе на контейнеры, чтобы избежать процесса постоянного исправления и обновления, но им пришлось на горьком опыте осознать, что контейнеры тоже необходимо постоянно обновлять и защищать, и они должны быть проверены, чтобы убедиться, что они не содержат незакрытых уязвимостей. Вместо того, чтобы подвергать себя атакам нулевого дня и рисковать развертыванием скомпрометированных контейнеров путем внесения исправлений безопасности ближе к концу разработки приложений, организации реализуют политику безопасности в виде кода и автоматизируют правила и конфигурации безопасности в конвейере CI/CD прямо на начальном этапе. этапы развития. Среды контейнеров и платформы оркестрации также постоянно отслеживаются на протяжении всего жизненного цикла сборки, поставки и запуска, чтобы обеспечить немедленное устранение уязвимостей и быструю изоляцию скомпрометированных контейнеров.
Архитектуры сервисной сетки, такие как Istio и Linkerd, используются организациями как средство абстрагирования сетей путем создания сетки прокси-серверов, которые сервисы могут использовать для вызова друг друга. Это повышает видимость и безопасность сети, обеспечивая аутентификацию микросервисов внутри приложения, а также шифрование трафика между сервисами. Встраивая безопасность в свою сервисно-сетевую архитектуру, организации автоматизируют отчеты о мониторинге, которые предупредят их, если злоумышленник попытается проникнуть в контейнер или платформу оркестрации и выполнить вредоносные операции.
Облако 2.0 означает рост количества атак
Хакеры не оставили незамеченными плохие методы обеспечения безопасности организаций, которые массово переходят на облачные среды разработки и производства, поскольку многие организации продемонстрировали готовность пожертвовать безопасностью ради гибкости. Однако по мере роста количества атак, обнаружения и исправления уязвимостей организации на горьком опыте узнают, что безопасность должна быть неотъемлемой частью их перехода к облаку 2.0. По мере того как организации внедряют архитектуры микросервисов на основе контейнеров, поверхность атаки будет только увеличиваться. Команды DevOps, которым не удается интегрировать безопасность в свои сервисные сетки, будут изо всех сил пытаться устранить нарушения, такие как, когда в публичном облаке Tesla в 2018 году были обнаружены контейнеры для криптомайнинга, развернутые Kubernetes, или когда червь криптоджекинга по прозвищу Graboid был обнаружен на более чем 2000 незащищенных хостах Docker. год.
Есть эксперты по безопасности, которые предполагают, что уязвимости контейнерных сред будут накапливаться до тех пор, пока система не выйдет из строя, что сделает быстрорастущие Kubernetes и Docker устаревшими в ближайшем будущем, поскольку инфраструктура окажется скорее помехой, чем активом. Однако ИТ-специалисты, которые осознают потенциал контейнеров в конвейере DevOps и могут использовать зрелый, ориентированный на безопасность подход к внедрению контейнеров, могут воспользоваться преимуществами сокращения накладных расходов и гибкости, предлагаемых инновацией.