다음을 통해 공유

AKS 보안

  • 아티클

이 문서에서는 솔루션을 구현하기 전에 고려해야 할 AKS(Azure Kubernetes Service) 보안 거버넌스의 측면을 안내합니다.

이 문서에서는 Azure 및 오픈 소스 소프트웨어를 사용하여 솔루션을 구현하는 방법에 중점을 둡니다. 엔터프라이즈 규모 랜딩 존을 만들 때 내리는 결정은 거버넌스를 부분적으로 미리 정의할 수 있습니다. 거버넌스 원칙을 이해하려면 엔터프라이즈 규모 보안 거버넌스 및 규정 준수를 참조하세요.

공격 표면

Kubernetes 클러스터에 대한 보안 전략을 만들 때 다음 5가지 공격 노출 영역을 고려합니다.

  • 빌드
  • 등록
  • 클러스터
  • 노드
  • 애플리케이션

각 범주에 대해 고려해야 할 주요 위험과 해당 위험에 대한 대책에 대해 설명합니다.

보안 빌드

보안 빌드는 컨테이너 이미지와 함께 DevSecOps를 적절하게 사용하는 것입니다.

주요 위험

잘못된 이미지 구성으로 인해 파이프라인의 보안 취약성이 발생할 수 있습니다. 예를 들어 필요한 것보다 더 큰 권한으로 실행되는 컨테이너가 있을 수 있습니다. 컨테이너는 특정 네트워크 액세스를 허용하도록 구성될 수도 있으며, 이로 인해 시스템이 위험에 처할 수 있습니다. 컨테이너의 안전한 작동에 필요한 호출에 허용되는 시스템 호출을 제한하지 않으면 손상된 컨테이너의 위험이 증가할 수 있습니다.

또 다른 취약성은 컨테이너가 호스트의 중요한 디렉터리에 액세스하도록 허용하거나 컨테이너가 호스트의 기본 기능을 제어하는 위치를 변경할 수 있도록 하는 것입니다.

불량 컨테이너는 환경에서 계획되지 않은 컨테이너입니다. 개발자가 테스트 환경에서 코드를 테스트한 결과일 수 있습니다. 이러한 컨테이너는 취약성에 대한 엄격한 검사를 거치지 않았거나 제대로 구성되지 않았을 수 있습니다. 이러한 취약성은 공격자에게 진입점을 제공할 수 있습니다.

신뢰할 수 있는 원본이 아니거나 보안 업데이트로 최신 상태가 아닌 기본 이미지를 사용하면 빌드하는 데 사용하는 컨테이너의 취약성이 발생할 수 있습니다.

위험 대책

보안 빌드는 보안을 왼쪽으로 이동하고 파이프라인 아래로의 이동을 시작하기 전에 대부분의 문제를 수정하기 위한 DevSecOps의 구현에 관한 것입니다. 모든 소유권을 개발자에게 부여하는 것이 아니라 운영과 소유권을 공유하는 것입니다. 그러면 개발자가 실제로 해결할 수 있는 취약성 및 규정 준수 문제를 확인하고 수정할 수 있습니다.

하나 또는 10개의 중요한 취약성이 있으므로 빌드를 검사하고 실패하는 파이프라인을 빌드할 수 있습니다. 더 나은 방법은 다음 계층을 아래로 보는 것입니다. 공급업체 상태에 따라 책임 지점 분할을 시작할 수 있습니다.

취약성의 상태 계층에서 임계값을 설정합니다. 현재와 같이 Open, Will not fix 또는 Deferred 상태의 모든 항목은 SecOps가 위험에 액세스할 수 있는 파이프라인 아래로 계속 흐르고 있습니다. 사용 가능한 공급업체 수정 상태의 취약성은 개발자가 해결할 수 있는 문제입니다. 유예 기간을 사용하면 개발자가 취약성을 수정할 수 있습니다.

취약성 평가와 함께 규정 준수 평가가 있습니다. 예를 들어 이미지가 루트 로 실행되도록 허용하거나 SSH를 노출하면 대부분의 기업의 규정 준수 태세가 중단됩니다. 배포하는 동안 대신 빌드하는 동안 이 문제를 해결합니다.

일반적으로 Docker CIS 벤치마크에 대해 이미지를 검사합니다. 이러한 유형의 흐름을 사용하는 경우 보안 수정을 도입하여 개발을 중단하지 않지만 전체 인라인에서 기업의 보안 태세를 개선할 수 있습니다.

기업에 적합한 전략을 효과적으로 구현하기 위해 이러한 기능을 지원하는 도구를 사용해야 합니다. 기존 도구는 종종 컨테이너 내에서 취약성을 감지할 수 없으므로 잘못된 보안 감각으로 이어질 수 있습니다. 컨테이너 에코시스템을 적절하게 보호하려면 파이프라인 기반 빌드 접근 방식과 컨테이너 기술의 변경할 수 없는 선언적 특성을 고려한 도구가 필요합니다.

이러한 도구에는 다음과 같은 속성이 있습니다.

  • 빌드 프로세스의 시작부터 레지스트리, 런타임까지 이미지의 전체 수명과 통합됩니다.
  • 이미지의 기본 계층, 애플리케이션 프레임워크 및 사용자 지정 소프트웨어를 포함하여 이미지의 모든 계층에서 취약성을 표시합니다.
  • 조직에서 빌드 및 배포 프로세스의 각 단계에서 품질 게이트를 만들 수 있도록 적절한 수준의 세분성을 갖춘 정책 기반 적용.

레지스트리 보안

레지스트리 보안은 다음과 같습니다.

  • 빌드에서 드리프트 컨트롤.
  • 오염된 이미지의 푸시/풀 방지
  • 이미지 서명.

주요 위험

이미지에는 종종 조직의 소스 코드를 포함한 독점 정보가 포함됩니다. 레지스트리에 대한 연결이 적절히 안전하지 않은 경우 이미지의 콘텐츠는 조직 내에서 전송되는 다른 형태의 데이터만큼 기밀성 위험을 초래할 수 있습니다. 레지스트리에 취약한 오래된 버전이 있는 오래된 이미지는 실수로 배포된 경우 보안 위험을 증가시킬 수 있습니다.

또 다른 보안 취약성에는 컨테이너 레지스트리에 대한 인증 및 권한 부여 제한이 부족할 수 있습니다. 이러한 레지스트리는 이미지에 중요한 소유 자산을 포함할 수 있습니다.

콘텐츠가 빌드되고 배포될 때 이 콘텐츠의 배포는 많은 공격 벡터 중 하나입니다. 배포를 위해 준비된 콘텐츠가 의도한 엔드포인트에 전달되는 것과 동일한 콘텐츠인지 확인하려면 어떻게 해야 할까요?

위험 대책

개발 도구, 네트워크 및 컨테이너 런타임이 암호화된 채널을 통해서만 레지스트리에 연결되도록 배포 프로세스를 설정합니다. 또한 콘텐츠가 신뢰할 수 있는 원본에서 제공되는지 확인합니다. 부실 이미지 사용으로 인한 위험을 줄이려면 다음을 수행합니다.

  • 컨테이너 레지스트리에서 더 이상 사용하지 않아야 하는 안전하지 않고 취약한 이미지를 제거합니다.
  • 사용할 특정 버전의 이미지를 지정하는 변경할 수 없는 이름을 사용하여 이미지에 액세스합니다. 최신 태그 또는 특정 버전의 이미지를 사용하여 이 구성을 구현할 수 있습니다. 태그는 새로 고침을 보장하지 않습니다. 이러한 이유로 Kubernetes 오케스트레이터가 가장 최근의 고유 번호를 사용하거나 최신 태그가 최신 버전을 나타내는지 확인하는 프로세스를 마련합니다.

중요한 이미지를 포함하는 레지스트리에 액세스하려면 인증 및 권한 부여가 필요합니다. 모든 쓰기 액세스에는 인증도 필요합니다. 예를 들어 정책을 통해 개발자는 책임이 있는 특정 리포지토리에만 이미지를 푸시할 수 있습니다.

이러한 레지스트리에 대한 액세스는 페더레이션되어야 하며 비즈니스 라인 수준 액세스 정책을 활용해야 합니다. 예를 들어 취약성 검사 규정 준수 평가 및 품질 관리 테스트를 통과한 후에만 이미지를 리포지토리에 푸시하도록 CI/CD 파이프라인을 구성할 수 있습니다.

이제 아티팩트 레지스트리로 간주되는 컨테이너 레지스트리는 컨테이너 이미지뿐만 아니라 모든 콘텐츠 형식을 배포하는 기본 수단이 되고 있습니다. 모든 클라우드는 클라우드 공급자 내에서 온-프레미스 또는 프라이빗 호스팅에 사용할 수 있는 오픈 소스 프로젝트 및 공급업체 제품을 포함하는 레지스트리를 제공합니다. 콘텐츠는 초기 빌드에서 프로덕션 배포에 이르기까지 레지스트리 내부 및 전체에서 승격됩니다.

레지스트리에 들어온 콘텐츠의 무결성이 레지스트리에서 나오는 것과 동일한 콘텐츠인지 확인하려면 어떻게 해야 할까요? 이미지 서명 솔루션을 채택하면 배포가 신뢰할 수 있는 레지스트리에서만 제공되고 신뢰할 수 있는 콘텐츠를 배포해야 합니다.

클러스터 보안

클러스터 보안은 다음과 같습니다.

  • 인증 및 권한 부여.
  • 네트워크 보안.
  • 취약성 및 규정 준수 관리.

주요 위험

경우에 따라 단일 Kubernetes 클러스터를 사용하여 액세스 수준 요구 사항이 다른 다른 팀에서 관리하는 다른 애플리케이션을 실행할 수 있습니다. 액세스가 제한 없이 또는 필요에 따라 개인에게 제공되는 경우 악의적이거나 부주의한 사용자는 액세스 권한이 있는 워크로드 및 클러스터의 다른 자산을 손상시킬 수 있습니다.

클러스터의 사용자 디렉터리가 권한 부여 및 인증을 관리할 때 또 다른 보안 취약성이 발생할 수 있습니다. 조직 인증 디렉터리가 더 엄격하게 제어되는 경우가 많습니다. 이러한 계정은 높은 권한이 있고 더 자주 분리되기 때문에 손상된 계정의 가능성이 높아집니다.

이 시나리오는 클러스터 또는 시스템 전체의 취약성으로 이어질 수 있습니다. 컨테이너 볼륨에 의해 저장된 데이터는 오케스트레이터에서 관리되며, 호스트되는 노드에 관계없이 데이터에 액세스할 수 있어야 합니다.

기존 네트워크 필터는 전송 중인 데이터를 암호화하도록 설계된 네트워크 오버레이로 인해 보안 실명이 있을 수 있습니다. 이 설계로 인해 클러스터 내의 트래픽을 모니터링하기가 어렵기 때문에 Kubernetes 클러스터를 모니터링하기 위해 특별한 프로비전이 필요할 수 있습니다.

동일한 클러스터를 공유하는 다른 애플리케이션의 트래픽은 공개 웹 사이트 및 중요한 중요한 비즈니스 프로세스를 실행하는 내부 애플리케이션과 같은 다른 민감도 수준을 가질 수 있습니다. 클러스터 내에서 동일한 가상 네트워크를 공유하면 중요한 데이터가 손상될 수 있습니다. 예를 들어 공격자는 인터넷에 노출된 공유 네트워크를 사용하여 내부 애플리케이션을 공격할 수 있습니다.

취약성 및 규정 준수 문제로부터 클러스터 자체를 실행하는 구성 요소를 보호합니다. 수정을 활용하려면 가능한 최신 버전의 Kubernetes에서 실행 중인지 확인합니다.

위험 대책

Kubernetes 클러스터 사용자 액세스는 최소 권한 액세스 모델을 사용해야 합니다. 작업을 수행하는 데 필요한 특정 호스트, 컨테이너 및 이미지에 대한 특정 작업을 수행할 수 있는 액세스 권한만 사용자에게 부여합니다. 프로덕션의 컨테이너에 대한 테스트 팀 멤버의 액세스 권한은 제한되거나 없어야 합니다. 클러스터 전체 액세스 권한이 있는 사용자 계정은 엄격하게 제어하고 아쉽게 사용해야 합니다.

다단계 인증과 같은 강력한 인증 방법을 사용하여 이러한 계정에 대한 액세스를 보호합니다. 조직 사용자 디렉터리를 사용하여 동일한 수준의 정책 및 컨트롤이 없을 수 있는 클러스터별 사용자 계정이 아닌 Single Sign-On을 통해 클러스터를 관리해야 합니다.

컨테이너가 실행 중인 호스트에 관계없이 컨테이너가 데이터에 제대로 액세스할 수 있도록 하는 암호화 방법을 사용합니다. 이러한 암호화 도구는 액세스 권한이 없는 동일한 노드 내에서도 다른 컨테이너에서 데이터에 무단으로 액세스하지 못하도록 방지해야 합니다.

민감도 수준별로 네트워크 트래픽을 개별 가상 네트워크 또는 서브넷으로 구분하도록 Kubernetes 클러스터를 구성합니다. 애플리케이션별 구분도 가능할 수 있지만 민감도 수준으로 네트워크를 정의하는 것으로 충분할 수 있습니다. 예를 들어 중요한 트래픽이 있는 내부 애플리케이션을 제공하는 것과 분리된 고객 연결 애플리케이션에 대한 가상 네트워크는 최소한 구현되어야 합니다.

taint 및 허용 오차를 사용하여 민감도 수준으로 특정 노드 집합에 대한 배포를 격리할 수 있습니다. 민감도가 낮은 워크로드와 동일한 노드 내에서 매우 중요한 워크로드를 호스팅하지 않습니다. 별도의 관리형 클러스터를 사용하는 것이 더 안전한 옵션입니다.

컨테이너를 목적, 민감도 및 스레드 태세별로 분할하여 중요한 워크로드에 대한 추가 보호를 제공합니다. 이러한 방식으로 컨테이너를 분할하면 한 세그먼트에 대한 액세스 권한을 얻은 공격자가 다른 세그먼트에 액세스하는 것이 더 어렵습니다. 이 구성은 캐시 또는 볼륨 탑재와 같은 잔차 데이터가 민감도 수준으로 격리되도록 하는 추가적인 이점이 있습니다.

Kubernetes 클러스터는 다음과 같이 구성해야 합니다.

  • 애플리케이션에서 실행되는 애플리케이션에 대한 보안 환경을 제공합니다.
  • 노드가 클러스터에 안전하게 추가되었는지 확인합니다.
  • 수명 주기 내내 보안을 보장하는 데 도움이 되는 영구 ID를 갖습니다.
  • 네트워킹 및 클러스터 내의 노드를 포함하여 클러스터 상태에 대한 정확한 라이브 정보를 제공합니다.

손상된 노드는 클러스터의 성능에 영향을 주지 않고 클러스터에서 쉽게 격리하고 제거해야 합니다. AKS는 이를 간단하게 수행합니다.

컨테이너 런타임 구성 표준을 정의하여 자동으로 규정 준수를 보장합니다. Azure 내에는 이 프로세스를 쉽게 만드는 많은 정책이 있으며 사용자도 자체 정책을 만들 수 있습니다. Azure 보안 기능을 사용하여 환경 전체의 구성 설정을 지속적으로 평가하고 적극적으로 적용합니다.

Kubernetes 구성 요소의 취약성이 자동으로 해결되는지 확인합니다. 개발, 테스트 및 프로덕션에 각각 고유한 컨트롤과 RBAC(역할 기반 액세스 제어)를 사용하여 컨테이너 관리를 위한 별도의 환경을 사용합니다. 모든 컨테이너 만들기를 개별 사용자 ID와 연결하고 감사를 위해 기록해야 합니다. 이 구성은 불량 컨테이너의 위험을 줄이는 데 도움이 됩니다.

노드 보안

노드 보안은 다음과 같습니다.

  • 런타임 보호.
  • 취약성 및 규정 준수 관리.

주요 위험

작업자 노드에는 노드의 모든 구성 요소에 대한 권한 있는 액세스 권한이 있습니다. 공격자는 네트워크에 액세스할 수 있는 모든 서비스를 진입점으로 사용할 수 있으므로 여러 지점에서 호스트에 대한 액세스를 제공하면 공격 표면이 심각하게 증가할 수 있습니다. 공격 노출 영역이 클수록 공격자가 노드 및 해당 운영 체제에 액세스할 가능성이 높아집니다.

또한 AKS 노드에서 사용되는 것과 같은 컨테이너별 운영 체제는 일반 운영 체제에서 데이터베이스와 웹 서버를 직접 실행할 수 있는 라이브러리를 포함하지 않으므로 공격 표면이 더 적습니다. 공유 커널을 사용하면 별도의 가상 머신의 컨테이너보다 동일한 환경에서 실행되는 컨테이너에 대한 공격 표면이 커집니다. AKS 노드에서 실행되는 컨테이너별 운영 체제가 사용 중인 경우에도 이 경우입니다.

호스트 운영 체제는 취약성과 규정 준수 위험이 있을 수 있는 기본 시스템 구성 요소를 제공합니다. 하위 수준 구성 요소이므로 해당 취약성 및 구성은 호스트되는 모든 컨테이너에 영향을 줄 수 있습니다. AKS는 AKS에서 실행되는 노드에서 정기적인 OS 업데이트를 통해 이러한 취약성을 처리하고 작업자 노드의 준수 상태를 유지 관리하여 사용자를 보호합니다.

부적절한 사용자 액세스 권한은 사용자가 AKS 컨트롤 플레인을 통해서가 아니라 컨테이너를 관리하기 위해 노드에 직접 로그인할 때 보안 위험을 초래할 수도 있습니다. 직접 로그인하면 사용자가 액세스 권한이 있어야 하는 애플리케이션 이상으로 애플리케이션을 변경할 수 있습니다.

또한 악성 컨테이너로 인해 호스트 OS 파일 시스템이 변조될 수 있습니다. 예를 들어 컨테이너가 호스트 OS에서 중요한 디렉터리를 탑재할 수 있는 경우 해당 컨테이너가 파일을 변경할 수 있습니다. 변경 내용은 호스트에서 실행되는 다른 컨테이너의 보안에 영향을 줄 수 있습니다.

위험 대책

SSH 액세스를 제한하여 노드 액세스를 제한합니다.

AKS 노드에서 컨테이너별 OS를 사용하면 일반적으로 다른 서비스 및 기능을 사용할 수 없으므로 공격 노출 영역이 줄어듭니다. 또한 읽기 전용 파일 시스템을 가지고 있으며 기본적으로 다른 클러스터 강화 방법을 사용합니다.

Azure 플랫폼은 OS 보안 패치를 야간에 Linux 및 Windows 노드에 자동으로 적용합니다. Linux OS 보안 업데이트에서 호스트를 다시 부팅해야 하는 경우 자동으로 다시 부팅되지 않습니다. AKS는 이러한 특정 패치를 적용하기 위해 다시 부팅하는 메커니즘을 제공합니다.

Microsoft는 OS를 관리하므로 AKS Linux 및 Windows 노드에는 서버용 Microsoft Defender를 적용할 수 없습니다. AKS가 배포된 구독에 다른 가상 머신이 없는 경우 서버용 Microsoft Defender를 안전하게 사용하지 않도록 설정할 수 있습니다.

엔터프라이즈 규모 랜딩 존 권장 Azure 정책을 포함하여 환경이 배포된 경우 불필요한 비용을 방지하기 위해 서버용 Microsoft Defender를 자동으로 사용할 수 있도록 관리 그룹의 정책 할당에 대한 제외를 구성할 수 있습니다.

애플리케이션 보안

애플리케이션 보안은 다음과 같습니다.

  • 런타임 보호.
  • 취약성 및 규정 준수 관리.

주요 위험

이미지는 애플리케이션을 실행하는 데 필요한 모든 구성 요소를 포함하는 파일입니다. 이러한 구성 요소의 최신 버전을 사용하여 이미지를 만들 때는 알려진 취약성이 없을 수 있지만 빠르게 변경할 수 있습니다.

패키지 개발자가 정기적으로 보안 취약성을 식별하기 때문에 이러한 파일을 최신 버전으로 최신 상태로 유지해야 합니다. 일반적으로 호스트에서 업데이트되는 기존 애플리케이션과 달리 컨테이너를 만드는 데 사용되는 이미지를 업데이트하여 컨테이너 업데이트를 업스트림 방식으로 추가로 만듭니다.

악성 파일을 이미지에 포함할 수도 있습니다. 그러면 시스템의 다른 컨테이너 또는 구성 요소를 공격하는 데 사용할 수 있습니다. 타사 컨테이너는 가능한 공격 벡터일 수 있습니다. 특정 세부 정보는 알 수 없으며 데이터가 누출될 수 있습니다. 컨테이너가 필요한 보안 업데이트로 최신 상태로 유지되지 않았을 수 있습니다.

또 다른 공격 벡터는 이미지 파일 시스템 내에서 직접 암호 및 연결 문자열 같은 비밀을 포함하는 것입니다. 이 방법은 이미지에 액세스할 수 있는 모든 사용자가 비밀에 액세스할 수 있기 때문에 보안 위험을 초래할 수 있습니다.

교차 사이트 스크립팅 또는 SQL 삽입에 취약한 애플리케이션과 같이 애플리케이션 자체에 결함이 있을 수 있습니다. 결함이 있는 경우 취약성을 사용하여 다른 컨테이너 또는 호스트 OS 내에서 중요한 정보에 무단으로 액세스할 수 있습니다.

AKS 컨테이너 런타임을 사용하면 Azure에서 사용할 수 있는 다양한 보안 도구를 사용하여 취약성을 쉽게 모니터링할 수 있습니다. 자세한 내용은 Kubernetes용 Microsoft Defender 소개를 참조 하세요.

또한 컨테이너가 보안 데이터를 호스팅하는 환경이나 인터넷과 같은 다양한 민감도 수준의 네트워크에서 트래픽을 보낼 수 없도록 컨테이너로 전송되는 송신 네트워크 트래픽을 제어해야 합니다. Azure는 다양한 네트워크 및 AKS 보안 기능을 사용하여 이 제어를 쉽게 수행할 수 있습니다.

기본적으로 Kubernetes 스케줄러는 크기 조정을 추진하고 노드에서 실행되는 워크로드의 밀도를 극대화하는 데 집중합니다. 해당 호스트에 사용 가능한 리소스가 가장 많기 때문에 서로 다른 민감도 수준의 Pod를 동일한 노드에 배치할 수 있습니다. 이 시나리오는 공격자가 공용 워크로드에 대한 액세스를 사용하여 동일한 호스트에서 더 중요한 프로세스를 실행하는 컨테이너를 공격할 때 보안 인시던트가 발생할 수 있습니다. 손상된 컨테이너는 네트워크를 검사하여 공격자가 악용할 수 있는 다른 취약성을 찾는 데 사용할 수도 있습니다.

위험 대책

비밀을 애플리케이션 코드 또는 파일 시스템에 저장하지 않습니다. 비밀은 키 저장소에 저장하고, 필요에 따라 런타임에 컨테이너에 제공해야 합니다. AKS는 특정 키에 액세스해야 하는 컨테이너만 키에 액세스할 수 있고 이러한 비밀이 디스크에 유지되지 않도록 할 수 있습니다. 예를 들어 Azure Key Vault는 이러한 비밀을 안전하게 저장하고, 필요에 따라 AKS 클러스터에 제공할 수 있습니다. 또한 이러한 비밀이 저장 및 전송 중에 암호화되도록 하는 것도 간단합니다.

신뢰할 수 없는 이미지 및 레지스트리를 사용하지 말고 신뢰할 수 있는 집합의 이미지만 클러스터에서 실행할 수 있는지 확인합니다. 다중 계층 접근 방식의 경우:

  • 신뢰할 수 있는 이미지와 레지스트리를 중앙에서 정확하게 제어합니다.
  • 암호화 서명을 통해 각 이미지를 개별적으로 식별합니다.
  • 모든 호스트가 승인된 세트의 이미지만 실행하도록 하는 정책을 배치합니다.
  • 실행하기 전에 이러한 서명의 유효성을 검사합니다.
  • 취약성 및 구성 요구 사항이 변경됨에 따라 이러한 이미지와 레지스트리를 모니터링하고 업데이트합니다.

보안 컴퓨팅 프로필을 사용하여 컨테이너를 제한하고 런타임에 할당해야 합니다. 사용자 지정 프로필을 만들고 컨테이너 런타임에 전달하여 해당 기능을 추가로 제한할 수 있습니다. 최소한 컨테이너가 기본 프로필로 실행되는지 확인합니다. 위험 수준이 높은 애플리케이션을 실행하는 컨테이너에 대해 더 제한적인 사용자 지정 프로필을 사용하는 것이 좋습니다.

도구는 동작 학습을 사용하여 애플리케이션을 자동으로 프로파일하고 변칙을 검색할 수 있습니다. 타사 솔루션을 사용하여 런타임 시 변칙을 검색할 수 있습니다. 변칙에는 다음과 같은 이벤트가 포함될 수 있습니다.

  • 잘못되었거나 예기치 않은 프로세스 실행 또는 시스템 호출입니다.
  • 보호된 구성 파일 및 이진 파일에 대한 변경 내용입니다.
  • 예기치 않은 위치 및 파일 형식에 씁니다.
  • 예기치 않은 네트워크 수신기 만들기
  • 예기치 않은 네트워크 대상으로 전송된 트래픽입니다.
  • 맬웨어 스토리지 및 실행.

Microsoft Defender for Kubernetes는 현재 이 영역에 투자하고 있습니다.

컨테이너는 읽기 전용 모드에서 루트 파일 시스템 실행하여 정의된 디렉터리에 대한 쓰기를 격리해야 하며, 이러한 도구는 쉽게 모니터링할 수 있습니다. 이 구성을 사용하면 이러한 특정 위치에 대한 변조를 격리하기 때문에 컨테이너가 손상의 복원력을 높일 수 있습니다. 애플리케이션의 나머지 부분과 쉽게 분리할 수 있습니다.

디자인 고려 사항

AKS에는 Microsoft Entra ID, Azure Storage 및 Azure Virtual Network와 같은 다른 Azure 서비스에 대한 여러 인터페이스가 있습니다. 이러한 서비스를 사용하려면 계획 단계에서 특별한 주의가 필요합니다. 또한 AKS는 인프라 환경의 나머지 부분에서와 동일한 보안 거버넌스/규정 준수 메커니즘 및 제어를 적용하는 것을 고려해야 하는 추가적인 복잡성을 추가합니다.

AKS 보안 거버넌스 및 규정 준수에 대한 몇 가지 다른 디자인 고려 사항은 다음과 같습니다.

  • 엔터프라이즈 규모 랜딩 존 모범 사례에 따라 배포된 구독에서 AKS 클러스터를 만드는 경우 클러스터가 상속할 Azure 정책을 숙지합니다. 자세한 내용은 Azure 랜딩 존 참조 구현에 포함된 정책을 참조 하세요.
  • 기본값인 인터넷(IP 제한 권장)을 통해 클러스터의 컨트롤 플레인에 액세스할 수 있는지 또는 Azure의 프라이빗 네트워크 내에서만 액세스할 수 있는지 또는 프라이빗 클러스터로 온-프레미스에서만 액세스할 수 있는지 결정합니다. 조직에서 엔터프라이즈 규모 랜딩 존 모범 사례를 Corp 따르는 경우 관리 그룹에는 클러스터를 비공개로 강제 적용하는 Azure Policy가 연결되어 있습니다. 자세한 내용은 Azure 랜딩 존 참조 구현에 포함된 정책을 참조 하세요.
  • 기본 제공 AppArmor Linux 보안 모듈을 통해 평가하여 읽기, 쓰기, 실행 또는 시스템 기능(예: 파일 시스템 탑재)과 같이 컨테이너에서 수행할 수 있는 작업을 제한합니다. 예를 들어 모든 구독에는 모든 AKS 클러스터의 Pod가 권한 있는 컨테이너를 만들지 못하게 하는 Azure 정책이 있습니다. 자세한 내용은 Azure 랜딩 존 참조 구현에 포함된 정책을 참조 하세요.
  • 프로세스 수준에서 seccomp(보안 컴퓨팅)를 통해 평가하여 컨테이너에서 수행할 수 있는 프로세스 호출을 제한합니다. 예를 들어 Azure Policy는 Kubernetes에 대한 Azure 정책을 통해 루트 사용 seccomp에 대한 컨테이너 권한 에스컬레이션을 방지하기 위해 랜딩 존 관리 그룹에서 일반 엔터프라이즈 규모 랜딩 존 구현의 일부로 적용되었습니다.
  • 컨테이너 레지스트리가 인터넷을 통해 액세스할 수 있는지 또는 특정 가상 네트워크 내에서만 액세스할 수 있는지 여부를 결정합니다. 컨테이너 레지스트리에서 인터넷 액세스를 사용하지 않도록 설정하면 공용 연결을 사용하여 액세스하는 다른 시스템에 부정적인 영향을 미칠 수 있습니다. 예를 들어 연속 통합 파이프라인 또는 이미지 검사를 위한 Microsoft Defender가 있습니다. 자세한 내용은 Azure Private Link를 사용하여 컨테이너 레지스트리에 비공개로 연결을 참조하세요.
  • 프라이빗 컨테이너 레지스트리가 여러 랜딩 존에서 공유되는지 또는 각 랜딩 존 구독에 전용 컨테이너 레지스트리를 배포하는지 여부를 결정합니다.
  • Microsoft Defender for Kubernetes와 같은 보안 솔루션을 위협 탐지에 사용하는 것이 좋습니다.
  • 컨테이너 이미지에서 취약성을 검사하는 것이 좋습니다.
  • 불필요한 비용을 방지하기 위해 AKS가 아닌 가상 머신이 없는 경우 AKS 구독에서 서버용 Microsoft Defender를 사용하지 않도록 설정하는 것이 좋습니다.

디자인 권장 사항

Important

클라우드용 Microsoft Defender 이미지 검사는 Container Registry 엔드포인트와 호환되지 않습니다. 자세한 내용은 Private Link를 사용하여 컨테이너 레지스트리에 비공개로 연결을 참조하세요.