Защита контейнеров Windows

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

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

Безопасность контейнера Windows определяется степенью совместного использования ресурсов в его узле. Граница безопасности контейнера состоит из механизмов изоляции, которые разделяют контейнеры и узел. Что важнее всего, эти механизмы изоляции определяют, какие процессы в контейнере могут взаимодействовать с узлом. Если архитектура контейнера допускает взаимодействие с узлом для процесса с правами администратора (с повышенными привилегиями), то в рекомендациях корпорации Майкрософт граница безопасности такого контейнера не считается надежной.

Сравнительный анализ контейнеров Windows Server и контейнеров Linux

Контейнеры Windows Server с изоляцией процессов и контейнеры Linux предоставляют сходные уровни изоляции. Для контейнеров обоих типов разработчик обязан предполагать, что любые атаки, осуществляемые с использованием процесса с повышенными привилегиями в узле, могут осуществляться и с использованием процесса с повышенными привилегиями в контейнере. Оба типа работают за счет примитивных возможностей, предоставляемых ядрами узлов. Образы контейнеров содержат двоичные файлы пользовательского режима, которые используют предоставленные ядром узла API-интерфейсы. Ядро узла предоставляет аналогичные возможности по управлению и изоляции ресурсов для каждого контейнера, работающего в пользовательском пространстве. В случае компрометации ядра компрометируются и все контейнеры, использующие это ядро.

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

Изоляция ядра от контейнеров на уровне гипервизора

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

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

Критерии обслуживания для безопасности контейнера

Корпорация Майкрософт твердо намерена исправлять любые эксплойты и способы проникновения, которые могут нарушать созданную границу изоляции для контейнеров Windows любого типа. Но процесс MSRC (Microsoft Security Response Center) применяется только к тем эксплойтам, которые нарушают границу безопасности. Только контейнеры с изоляцией на уровне гипервизора обеспечивают хорошую границу безопасности, но не контейнеры с изоляцией на уровне процессов. Единственный способ создать ошибку, которая будет считаться способом проникновения для контейнера, изолированного на уровне процессов, — предоставление возможности доступа к узлу некоторому процессу без прав администратора. Если эксплойт позволяет злоумышленнику выйти за пределы контейнера с использованием процесса с правами администратора, то корпорация Майкрософт будет считать эксплойт ошибкой, не относящейся к безопасности, и применит исправления в рамках обычного процесса обслуживания. Если эксплойт позволяет злоумышленнику выполнить действия, нарушающие границу безопасности, с использованием процесса без прав администратора, то корпорация Майкрософт будет расследовать эту ошибку по установленным критериям обслуживания системы безопасности.

В каких случаях рабочая нагрузка в среде с несколькими клиентами считается вредоносной?

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

Вы можете предпринять меры, снижающие вероятность возникновения эксплойтов (например, использовать политики безопасности pod, AppArmor или управления доступом на основе ролей (RBAC)). Но такие меры не гарантируют полной защиты от злоумышленника. Мы рекомендуем следовать нашим рекомендациям по изоляции кластера в любых сценариях с несколькими клиентами.

Когда следует использовать учетные записи ContainerAdmin и ContainerUser

Контейнеры Windows Server предоставляют две учетные записи пользователей по умолчанию (ContainerAdministrator и ContainerUser), каждая из которых предназначена для определенной цели. Учетная запись ContainerAdministrator позволяет использовать контейнер для административных целей, например устанавливать службы и программное обеспечение (в том числе настраивать службы IIS в контейнере), вносить изменения в конфигурацию и создавать новые учетные записи. Эти задачи важны во многих сценариях, которые могут выполняться в пользовательских локальных средах развертывания.

Учетная запись ContainerUser предназначена для всех остальных сценариев, в которых не требуются права администратора Windows. Например, в Kubernetes пользователь с учетной записью ContainerAdministrator может подключить папку .ssh и добавить открытый ключ, если разрешено подключение hostvolume к этому объекту pod. Учетная запись ContainerUser не позволяет выполнить этот пример действия. Это ограниченная учетная запись пользователя, предназначенная исключительно для приложений, которые не требуют взаимодействия с узлом. Мы настоятельно рекомендуем выполнять все приложения с учетной записью ContainerUser, если сервер Windows развернут в любой среде с несколькими клиентами. В среде с несколькими клиентами обязательно следует соблюдать принцип минимально необходимых привилегий, так как это снижает вероятность воздействия на общий ресурс и соседние рабочие нагрузки из скомпрометированной рабочей нагрузки. Контейнеры, работающие с учетной записью ContainerUser, в целом значительно снижают вероятность компрометации среды. Но и эти меры не создают надежной границы безопасности. Поэтому следует использовать контейнеры с изоляцией на уровне гипервизора во всех сценариях, в которых есть основания беспокоиться о безопасности.

Чтобы изменить учетную запись пользователя, можно использовать инструкцию USER в dockerfile:

USER ContainerUser

Вы также можете создать нового пользователя.

RUN net user username ‘<password>’ /ADD
USER username

Службы Windows

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

При контейнеризации и защите рабочей нагрузки, работающей в качестве службы Windows, следует учитывать несколько дополнительных аспектов. Во-первых, контейнер не будет рабочей нагрузкой, ENTRYPOINT так как служба выполняется в качестве фонового процесса, обычно ENTRYPOINT это будет инструмент, например монитор службы) или монитор журнала). Во-вторых, учетная запись безопасности, в которой работает рабочая нагрузка, будет настроена службой, а не директивой USER в dockerfile. Вы можете проверка какую учетную запись служба будет запускаться, выполнив команду Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName.

Например, при размещении веб-приложения IIS с помощью образа ENTRYPOINT ASP.NET (Реестр артефактов Microsoft) контейнера "C:\\ServiceMonitor.exe", "w3svc"является . Это средство можно использовать для настройки службы IIS, а затем отслеживать службу, чтобы убедиться, что она остается запущенной и выходной, таким образом, останавливает контейнер, если служба останавливается по какой-либо причине. По умолчанию служба IIS и, таким образом, веб-приложение выполняются под учетной записью с низким уровнем привилегий в контейнере, но средство мониторинга служб требует прав администратора для настройки и мониторинга службы.