Windows 컨테이너 보호

적용 대상: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

컨테이너는 다양한 리소스에 대한 제한된 액세스를 제공하기 위해 호스트에 의존할 수 있다는 사실에 축소된 이미지 크기를 제공합니다. 컨테이너가 호스트가 특정 작업 집합을 수행하는 데 필요한 기능을 제공할 수 있다는 것을 알고 있는 경우 컨테이너는 해당 기본 이미지에 관련 소프트웨어를 포함할 필요가 없습니다. 그러나 발생하는 리소스 공유의 범위는 컨테이너의 성능과 보안 모두에 큰 영향을 미칠 수 있습니다. 리소스가 너무 많이 공유되면 애플리케이션이 호스트에서 프로세스로 실행되기만 하면 됩니다. 리소스가 너무 적게 공유되면 컨테이너는 VM과 구별할 수 없게 됩니다. 두 구성 모두 많은 시나리오에 적용할 수 있지만 컨테이너를 사용하는 대부분의 사용자는 일반적으로 중간에 있는 항목을 선택합니다.

Windows 컨테이너의 보안은 호스트와 발생하는 공유 정도에서 파생됩니다. 컨테이너의 보안 경계는 컨테이너를 호스트와 분리하는 격리 메커니즘에 의해 구성됩니다. 가장 중요한 것은 이러한 격리 메커니즘은 컨테이너에서 호스트와 상호 작용할 수 있는 프로세스를 정의합니다. 컨테이너의 디자인으로 관리자 권한(관리자) 프로세스가 호스트와 상호 작용할 수 있는 경우 Microsoft는 이 컨테이너를 강력한 보안 경계로 간주하지 않습니다.

Windows Server 컨테이너 및 Linux 컨테이너

프로세스 격리 Windows Server 컨테이너 및 Linux 컨테이너는 비슷한 수준의 격리를 공유합니다. 두 컨테이너 유형 모두에 대해 개발자는 호스트의 관리자 권한 프로세스를 통해 수행할 수 있는 모든 공격을 컨테이너의 관리자 권한 프로세스를 통해 수행할 수 있다고 가정해야 합니다. 둘 다 해당 호스트 커널에서 제공하는 기본 기능을 통해 작동합니다. 컨테이너 이미지는 호스트 커널에서 제공하는 API를 활용하는 사용자 모드 이진 파일을 포함하는 빌드됩니다. 호스트 커널은 사용자 공간에서 실행되는 각 컨테이너에 동일한 리소스 격리 및 관리 기능을 제공합니다. 커널이 손상된 경우 해당 커널을 공유하는 모든 컨테이너도 마찬가지입니다.

Linux 및 Windows 서버 컨테이너의 기본 디자인은 유연성을 위해 보안을 사용합니다. Windows Server 및 Linux 컨테이너는 OS에서 제공하는 기본 구성 요소를 기반으로 빌드됩니다. 이렇게 하면 컨테이너 간에 리소스와 네임스페이스를 공유할 수 있는 유연성이 있지만, 복잡성이 더해져서 악용의 문이 열립니다. 커널을 적대적인 다중 테넌트 워크로드에 대한 충분한 보안 경계로 간주하지 않습니다.

하이퍼바이저로 격리된 컨테이너를 통한 커널 격리

하이퍼바이저 격리 컨테이너는 프로세스 격리 Windows Server 또는 Linux 컨테이너보다 높은 수준의 격리를 제공하며 강력한 보안 경계로 간주됩니다. 하이퍼바이저 격리 컨테이너는 초경량 VM에 래핑된 Windows Server 컨테이너로 구성된 다음, Microsoft의 하이퍼바이저를 통해 호스트 OS와 함께 실행됩니다. 하이퍼바이저는 호스트와 다른 컨테이너 간의 매우 강력한 보안 경계를 포함하는 하드웨어 수준 격리를 제공합니다. 취약점 공격이 Windows Server 컨테이너를 탈출하더라도 하이퍼바이저로 격리된 VM 내에 국한됩니다.

Windows Server 컨테이너 또는 Linux 컨테이너는 Microsoft가 강력한 보안 경계로 간주하는 것을 제공하지 않으며 적대적인 다중 테넌트 시나리오에서 사용해서는 안 됩니다. 불량 컨테이너 프로세스가 호스트 또는 다른 테넌트와 상호 작용하는 것을 방지하려면 컨테이너를 전용 VM으로 제한해야 합니다. 하이퍼바이저 격리를 사용하면 이러한 수준의 분리를 가능하게 하는 동시에 기존 VM보다 몇 가지 성능이 향상됩니다. 따라서 적대적인 다중 테넌트 시나리오에서는 하이퍼바이저 격리 컨테이너가 선택되는 것이 권장됩니다.

컨테이너 보안 서비스 조건

Microsoft는 모든 Windows 컨테이너 유형의 설정된 격리 경계를 깨뜨리는 모든 악용 및 이스케이프를 패치하기 위해 최선을 다하고 있습니다. 그러나 보안 경계를 깨뜨리는 악용은 MSRC(Microsoft Security Response Center) 프로세스를 통해서만 처리됩니다. 하이퍼바이저로 격리된 컨테이너만 보안 경계를 제공하며 프로세스 격리 컨테이너는 그렇지 않습니다. 프로세스 격리 컨테이너 이스케이프에 대한 버그를 생성하는 유일한 방법은 관리자가 아닌 프로세스가 호스트에 액세스할 수 있는 경우입니다. 악용이 관리 프로세스를 사용하여 컨테이너를 이스케이프하는 경우 Microsoft는 이 버그를 비보안 버그로 간주하고 일반 서비스 프로세스에 따라 패치합니다. 악용이 관리자가 아닌 프로세스를 사용하여 보안 경계를 위반하는 작업을 수행하는 경우 Microsoft는 설정된보안 서비스 기준에 따라 조사합니다.

다중 테넌트 워크로드가 적대적인 이유는 무엇인가요?

다중 테넌트 환경은 여러 워크로드가 공유 인프라 및 리소스에서 작동할 때 존재합니다. 인프라에서 실행되는 하나 이상의 워크로드를 신뢰할 수 없는 경우 다중 테넌트 환경은 적대적인 것으로 간주됩니다. Windows Server 및 Linux 컨테이너는 모두 호스트 커널을 공유하므로 단일 컨테이너에서 수행된 모든 악용은 공유 인프라에서 실행되는 다른 모든 워크로드에 영향을 미칠 수 있습니다.

예를 들어 Pod 보안 정책, AppArmor 및 RBAC(역할 기반 액세스 제어)를 사용하여 악용이 발생할 가능성을 줄이는 조치를 취할 수 있지만 공격자에 대한 보장된 보호를 제공하지는 않습니다. 다중 테넌트 시나리오에 대한 클러스터 격리 대한 모범 사례를 따르는 것이 좋습니다.

ContainerAdmin 및 ContainerUser 사용자 계정을 사용하는 경우

Windows Server 컨테이너는 각각 고유한 용도로 두 개의 기본 사용자 계정인 ContainerUser 및 ContainerAdministrator를 제공합니다. ContainerAdministrator 계정을 사용하면 서비스 및 소프트웨어 설치(예: 컨테이너 내에서 IIS 사용), 구성 변경, 새 계정 만들기 등 관리 목적으로 컨테이너를 사용할 수 있습니다. 이러한 작업은 사용자 지정 온-프레미스 배포 환경에서 실행될 수 있는 여러 IT 시나리오에 중요합니다.

ContainerUser 계정은 Windows의 관리자 권한이 필요하지 않은 다른 모든 시나리오에 대해 존재합니다. 예를 들어 Kubernetes에서 사용자가 ContainerAdministrator이고 hostvolumes를 Pod에 탑재할 수 있는 경우 사용자는 .ssh 폴더를 탑재하고 공개 키를 추가할 수 있습니다. ContainerUser로 이 예제는 불가능합니다. 호스트와 상호 작용할 필요가 없는 애플리케이션용으로 설계된 제한된 사용자 계정입니다. 애플리케이션이 ContainerUser 계정을 통해 실행되는 모든 다중 테넌트 환경에 Windows 서버 컨테이너를 배포할 때 사용하는 것이 좋습니다. 다중 테넌트 환경에서는 공격자가 워크로드를 손상하는 경우 공유 리소스 및 인접 워크로드도 영향을 받을 가능성이 낮기 때문에 항상 최소 권한 원칙을 따르는 것이 가장 좋습니다. ContainerUser 계정으로 컨테이너를 실행하면 환경 전체가 손상될 가능성이 크게 줄어듭니다. 그러나 이는 여전히 강력한 보안 경계를 제공하지 않으므로 보안이 우려되는 경우 하이퍼바이저 격리 컨테이너를 사용해야 합니다.

사용자 계정을 변경하려면 dockerfile에서 USER 문을 사용할 수 있습니다.

USER ContainerUser

또는 새 사용자를 만들 수 있습니다.

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

Windows 서비스

이전의 NT 서비스로 알려진 Microsoft Windows 서비스를 사용하면 자체 Windows 세션에서 실행되는 장기 실행 실행 애플리케이션을 만들 수 있습니다. 이러한 서비스는 운영 체제가 시작될 때 자동으로 시작되고, 일시 중지 및 다시 시작할 수 있으며, 사용자 인터페이스를 표시하지 않을 수 있습니다. 로그온한 사용자 또는 기본 컴퓨터 계정과 다른 특정 사용자 계정의 보안 컨텍스트에서 서비스를 실행할 수도 있습니다.

Windows 서비스로 실행되는 워크로드를 컨테이너화하고 보호하는 경우 주의해야 할 몇 가지 추가 고려 사항이 있습니다. 첫째, 서비스가 백그라운드 프로세스로 실행되므로 컨테이너의 ENTRYPOINT 워크로드가 되지 않습니다. 일반적으로 ENTRYPOINT서비스 모니터) 또는 로그 모니터)와 같은 도구가 됩니다. 둘째, 워크로드가 작동하는 보안 계정은 dockerfile의 USER 지시문이 아닌 서비스에 의해 구성됩니다. Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName실행하여 서비스가 실행될 계정을 확인할 수 있습니다.

예를 들어 ASP.NET(Microsoft Artifact Registry) 이미지를 사용하여 IIS 웹 애플리케이션을 호스팅하는 경우, 컨테이너의 ENTRYPOINT는 "C:\\ServiceMonitor.exe", "w3svc"입니다. 이 도구를 사용하여 IIS 서비스를 구성한 다음 서비스를 모니터링하여 서비스가 계속 실행되고 종료되는지 확인할 수 있으므로 어떤 이유로든 서비스가 중지되면 컨테이너를 중지할 수 있습니다. 기본적으로 IIS 서비스 및 웹 애플리케이션은 컨테이너 내의 낮은 권한 계정으로 실행되지만 서비스 모니터 도구에는 서비스를 구성하고 모니터링하기 위한 관리 권한이 필요합니다.