Zabezpieczanie kontenerów systemu Windows

Dotyczy: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Kontenery zmniejszają rozmiar obrazów dzięki temu, że mogą polegać na hoście, co zapewnia im ograniczony dostęp do różnych zasobów. Jeśli kontener wie, że host będzie mógł zapewnić funkcjonalność wymaganą do wykonania określonego zestawu akcji, kontener nie musi dołączać odpowiedniego oprogramowania do obrazu podstawowego. Zakres udostępniania zasobów, który występuje, może mieć jednak znaczący wpływ zarówno na wydajność, jak i bezpieczeństwo kontenera. Jeśli udostępniono zbyt wiele zasobów, aplikacja może być również uruchamiana jako proces na hoście. Jeśli zasoby są zbyt małe, kontener staje się nie do odróżnienia od maszyny wirtualnej. Obie konfiguracje mają zastosowanie do wielu scenariuszy, ale większość osób korzystających z kontenerów zazwyczaj wybiera coś w środku.

Zabezpieczenia kontenera systemu Windows pochodzą ze stopnia udostępniania, który występuje z jego hostem. Granica zabezpieczeń kontenera jest częścią mechanizmów izolacji, które oddzielają kontener od hosta. Co najważniejsze, te mechanizmy izolacji określają, które procesy w kontenerze mogą współdziałać z hostem. Jeśli projekt kontenera pozwala na interakcję z hostem poprzez proces o podwyższonym poziomie uprawnień (administrator), firma Microsoft nie uważa tego kontenera za mającego solidną granicę zabezpieczeń.

Kontenery systemu Windows Server a kontenery systemu Linux

Kontenery systemu Windows Server i kontenery systemu Linux odizolowane od procesów mają podobny stopień izolacji. W przypadku obu typów kontenerów deweloper musi zakładać, że każdy atak, który można wykonać poprzez proces z podwyższonym poziomem uprawnień na hoście, można również przeprowadzić poprzez proces o podwyższonym poziomie uprawnień w kontenerze. Obie działają za pośrednictwem pierwotnych możliwości oferowanych przez ich odpowiednie jądra hostów. Obrazy kontenerów są tworzone z plikami binarnymi trybu użytkownika, które korzystają z interfejsów API udostępnianych przez jądro hosta. Jądro hosta zapewnia te same możliwości izolacji zasobów i zarządzania dla każdego kontenera uruchomionego w przestrzeni użytkownika. Jeśli bezpieczeństwo jądra zostanie naruszone, oznacza to, że każdy kontener współużytkuje to jądro.

Podstawowy projekt kontenerów systemu Linux i Windows Server wymienia zabezpieczenia w celu zapewnienia elastyczności. Kontenery systemu Windows Server i Linux są oparte na podstawowych składnikach dostarczanych przez system operacyjny. Zapewnia to elastyczność udostępniania zasobów i przestrzeni nazw między kontenerami, ale zwiększa to dodatkową złożoność, która otwiera drzwi do wykorzystania. Ogólnie rzecz biorąc, nie uważamy jądra za wystarczającą granicę zabezpieczeń dla wrogich obciążeń wielodostępnych.

Izolacja jądra z kontenerami izolowanymi przez hiperwizor

Kontenery izolowane przez funkcję Hypervisor zapewniają wyższy stopień izolacji niż kontenery systemu Windows Server lub Linux i są uważane za niezawodne granice zabezpieczeń. Kontenery izolowane przez funkcję Hypervisor składają się z kontenera systemu Windows Server opakowanego w ultralekkiej maszynie wirtualnej, a następnie uruchamiane razem z systemem operacyjnym hosta za pośrednictwem funkcji hypervisor firmy Microsoft. Funkcja hypervisor zapewnia izolację na poziomie sprzętu, która obejmuje wysoce niezawodną granicę zabezpieczeń między hostem a innymi kontenerami. Nawet jeśli program wykorzystujący luki w zabezpieczeniach miał zostać usunięty z kontenera systemu Windows Server, byłby on zawarty na maszynie wirtualnej izolowanej przez funkcję hypervisor.

Klastry kontenerów Windows Server ani klastery kontenerów Linux nie zapewniają tego, co Microsoft uważa za solidną granicę bezpieczeństwa i nie powinny być używane w wrogich środowiskach obejmujących wiele najemców. Kontener musi być ograniczony do dedykowanej maszyny wirtualnej, aby zapobiec interakcji nieautoryzowanego procesu kontenera z hostem lub innymi dzierżawcami. Izolacja funkcji Hypervisor umożliwia ten stopień separacji, a także oferuje kilka wzrostów wydajności w przypadku tradycyjnych maszyn wirtualnych. Dlatego zdecydowanie zaleca się, aby w wrogich środowiskach wielodzierżawczych kontenery izolowane przez hiperwizor były preferowanym wyborem.

Kryteria obsługi zabezpieczeń kontenerów

Firma Microsoft zobowiązuje się do stosowania poprawek wszystkich luk w zabezpieczeniach i ucieczki, które przerywają ustanowioną granicę izolacji dowolnego typu kontenera systemu Windows. Jednak tylko luki w zabezpieczeniach, które przerywają granicę zabezpieczeń, są obsługiwane za pośrednictwem procesu Microsoft Security Response Center (MSRC). Tylko kontenery izolowane przez hiperwizor zapewniają granicę bezpieczeństwa, a kontenery izolowane przez proces nie. Jedynym sposobem wygenerowania błędu umożliwiającego ucieczkę z kontenera o izolowanym procesie jest, gdy proces inny niż administracyjny może uzyskać dostęp do hosta. Jeśli program wykorzystujący luki wykorzystuje proces administratora do ucieczki kontenera, firma Microsoft uważa, że jest to usterka niezwiązana z zabezpieczeniami i poprawa go zgodnie z normalnym procesem obsługi. Jeśli program wykorzystujący luki w zabezpieczeniach używa procesu innego niż administrator do wykonania akcji, która narusza granicę zabezpieczeń, firma Microsoft zbada ją zgodnie z ustalonymi kryteriami obsługi zabezpieczeń.

Co sprawia, że obciążenie dla wielu najemców jest niesprzyjające?

Środowiska wielodostępne istnieją, gdy wiele obciążeń działa na współużytkowanej infrastrukturze i zasobach. Jeśli co najmniej jedno obciążenie uruchomione na infrastrukturze nie może być zaufane, środowisko wielodostępne jest uznawane za wrogie. Kontenery systemu Windows Server i Linux współużytkują jądro hosta, więc wszystkie luki wykonywane w jednym kontenerze mogą mieć wpływ na wszystkie inne obciążenia uruchomione w udostępnionej infrastrukturze.

Możesz podjąć kroki, aby zmniejszyć prawdopodobieństwo wystąpienia luki w zabezpieczeniach, na przykład przy użyciu polityk bezpieczeństwa podów, AppArmor i kontroli dostępu opartej na rolach (RBAC), ale nie zapewniają one gwarantowanej ochrony przed atakami. Zalecamy stosowanie naszych najlepszych praktyk dotyczących izolacji klastra dla dowolnego scenariusza z wieloma dzierżawcami.

Kiedy należy używać kont użytkowników ContainerAdmin i ContainerUser

Kontenery systemu Windows Server oferują dwa domyślne konta użytkowników, ContainerUser i ContainerAdministrator, z których każdy ma własny cel. Konto ContainerAdministrator umożliwia używanie kontenera do celów administracyjnych: instalowanie usług i oprogramowania (na przykład włączanie usług IIS w kontenerze), wprowadzanie zmian konfiguracji i tworzenie nowych kont. Te zadania są ważne w wielu scenariuszach IT, które mogą działać w niestandardowych, lokalnych środowiskach wdrażania.

Konto ContainerUser istnieje dla wszystkich innych scenariuszy, w których uprawnienia administratora w systemie Windows nie są potrzebne. Na przykład w rozwiązaniu Kubernetes, jeśli użytkownik ma uprawnienia ContainerAdministrator i hostvolumes mogą być instalowane w zasobniku, użytkownik może zainstalować folder ssh i dodać klucz publiczny. Jako ContainerUser ten przykład nie byłby możliwy. Jest to ograniczone konto użytkownika przeznaczone wyłącznie dla aplikacji, które nie muszą korzystać z hosta. Zdecydowanie zalecamy, aby podczas wdrażania kontenera systemu Windows Server w współdzielonym środowisku, aplikacja działała za pośrednictwem konta ContainerUser. W środowisku wielodostępnym zawsze najlepiej przestrzegać zasady najmniejszych uprawnień, ponieważ jeśli osoba atakująca naruszy obciążenie, wówczas zasoby współdzielone i sąsiednie obciążenia mają mniejszą szansę na negatywny wpływ. Uruchamianie kontenerów przy użyciu konta ContainerUser znacznie zmniejsza prawdopodobieństwo naruszenia zabezpieczeń środowiska jako całości. Jednak to nadal nie zapewnia solidnej granicy zabezpieczeń, więc gdy zabezpieczenia są problemem, należy użyć kontenerów izolowanych przez hypervisor.

Aby zmienić konto użytkownika, możesz użyć instrukcji USER w pliku dockerfile:

USER ContainerUser

Alternatywnie możesz utworzyć nowego użytkownika:

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

Usługi systemu Windows

Usługi systemu Microsoft Windows, dawniej znane jako usługi NT, umożliwiają tworzenie długotrwałych aplikacji wykonywalnych uruchamianych we własnych sesjach systemu Windows. Te usługi można uruchamiać automatycznie po uruchomieniu systemu operacyjnego, można wstrzymać i ponownie uruchomić i nie wyświetlać żadnego interfejsu użytkownika. Usługi można również uruchamiać w kontekście zabezpieczeń określonego konta użytkownika, które różni się od zalogowanego użytkownika lub domyślnego konta komputera.

Podczas konteneryzowania i zabezpieczania obciążenia, które działa jako usługa systemu Windows, należy pamiętać o kilku dodatkowych zagadnieniach. Po pierwsze, ENTRYPOINT kontenera nie będzie obciążeniem, ponieważ usługa działa jako proces w tle, zazwyczaj ENTRYPOINT będzie narzędziem, na przykład monitorem usługi ) lub monitorem dzienników ). Po drugie, konto zabezpieczeń, w ramach którego działa obciążenie, zostanie skonfigurowane przez usługę, a nie przez dyrektywę USER w pliku dockerfile. Możesz sprawdzić, w którym koncie będzie działać usługa, uruchamiając Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName.

Na przykład podczas hostowania aplikacji sieciowej w usługach IIS przy użyciu obrazu ASP.NET (Microsoft Artifact Registry), ENTRYPOINT kontenera to "C:\\ServiceMonitor.exe", "w3svc". To narzędzie może być używane do konfigurowania usługi IIS, a następnie monitoruje usługę, aby upewnić się, że pozostaje aktywna, i w przypadku jej zatrzymania z jakiegokolwiek powodu kończy działanie, co prowadzi do zatrzymania kontenera. Domyślnie usługa IIS, a tym samym aplikacja internetowa działa w ramach konta niskiego poziomu uprawnień w kontenerze, ale narzędzie monitora usług wymaga uprawnień administracyjnych do konfigurowania i monitorowania usługi.