PCI-DSS 3.2.1에 대한 AKS 기준 클러스터의 액세스 관리(6/9부)

이 문서에서는 PCI-DSS 3.2.1(지불 카드 업계 데이터 보안 표준)에 따라 구성된 AKS(Azure Kubernetes Service) 클러스터에 대한 고려 사항을 설명합니다.

이 문서는 시리즈의 일부입니다. 소개를 읽어보세요.

Kubernetes에는 Kubernetes API에 대한 권한을 관리하는 원시 RBAC(역할 기반 액세스 제어)가 있습니다. Kubernetes 리소스에 대한 특정 권한이 있거나 작업을 수행할 수 있는 몇 가지 기본 제공 역할이 있습니다. AKS(Azure Kubernetes Service)는 세분화된 제어를 위해 이러한 기본 제공 역할 및 사용자 지정 역할을 지원합니다. 이러한 작업 권한은 Kubernetes RBAC를 통해 사용자에게 부여되거나 거부될 수 있습니다.

이 아키텍처 및 구현은 온-프레미스 리소스 또는 데이터 센터에 대한 물리적 액세스 제어를 제공하도록 설계되지 않았습니다. 에지 또는 데이터 센터의 플랫폼과 달리 Azure에서 CDE를 호스트할 경우의 이점 중 하나는 물리적 액세스 제한이 이미 대부분 Azure 데이터 센터 보안을 통해 처리된다는 것입니다. 조직에 물리적 하드웨어 관리 책임이 없습니다.

강력한 액세스 제어 조치 구현

요구 사항 7 — 비즈니스에서 알아야 할 카드 소유자 데이터에 대한 액세스 제한

AKS 기능 지원

AKS는 ID 공급자로서 Microsoft Entra ID와 완전히 통합됩니다.

Kubernetes에 대한 별도의 사용자 ID 및 자격 증명을 관리할 필요가 없습니다. Kubernetes RBAC에 대한 Microsoft Entra 사용자를 추가할 수 있습니다. 이 통합을 통해 Microsoft Entra 사용자에게 역할 할당을 수행할 수 있습니다. Microsoft Entra RBAC는 뷰어, 기록기, 서비스 관리자, 클러스터 관리자와 같은 역할 정의를 기본 제공 역할로 지원합니다. 또한 보다 세부적인 제어를 위해 사용자 지정 역할을 만들 수 있습니다.

기본적으로 Azure RBAC는 모두 거부로 설정되므로 권한이 부여되지 않은 리소스에 액세스할 수 없습니다. AKS는 AKS 작업자 노드에 대한 SSH 액세스를 제한하고 AKS 네트워크 정책을 사용하여 Pod의 워크로드에 대한 액세스를 제어합니다.

자세한 내용은 Kubernetes 권한 부여에 Azure RBAC 사용 및 Azure Policy를 사용하여 클러스터 보호를 참조하세요.

사용자의 책임

요구 사항	책임
요구 사항 7.1	시스템 구성 요소 및 카드 소유자 데이터에 대한 액세스 권한을 작업에 액세스해야 하는 개인으로 제한합니다.
요구 사항 7.2	사용자의 알아야 할 필요에 따라 액세스를 제한하고 특별히 허용되지 않으면 "모두 거부"로 설정하는 시스템 구성 요소의 액세스 제어 시스템을 설정합니다.
요구 사항 7.3	카드 소유자 데이터에 대한 액세스를 제한하기 위해 보안 정책과 운영 절차가 문서화되고 사용 중이며 모든 해당 당사자가 알고 있어야 합니다.

요구 사항 7.1

시스템 구성 요소 및 카드 소유자 데이터에 대한 액세스 권한을 작업에 액세스해야 하는 개인으로 제한합니다.

사용자의 책임

다음은 몇 가지 고려 사항입니다.

• 구현이 조직의 요구 사항 및 ID 관리에 대한 규정 준수 요구 사항에 부합하는지 확인합니다.
• 특히 중요한 영향 계정의 경우 대기 권한을 최소화합니다.
• 최소 권한 액세스 원칙을 따릅니다. 작업을 완료하기에 충분한 액세스 권한만 제공합니다.

요구 사항 7.1.1

다음을 비롯한 각 역할에 필요한 액세스를 정의합니다.

• 각 역할이 해당 작업 함수에 액세스해야 하는 시스템 구성 요소 및 데이터 리소스
• 리소스에 액세스 하기 위해 필요한 권한 수준(예: 사용자, 관리자 등).

사용자의 책임

범위 내 구성 요소 및 Azure 리소스와의 상호 작용에 필요한 작업 및 책임에 따라 역할을 정의합니다. 다음과 같은 광범위한 범주로 시작할 수 있습니다.

• Azure 관리 그룹, 구독 또는 리소스 그룹별 범위
• 워크로드 또는 구독에 대한 Azure Policy
• 컨테이너 작업
• 비밀 관리
• 빌드 및 배포 파이프라인

이러한 영역에 대한 역할 및 책임의 정의는 팀 구조와 관련이 있을 수 있지만 워크로드의 요구 사항에 집중하세요. 예를 들어 보안, 격리, 배포 및 가시성을 유지할 책임이 있는 사람이 있습니다. 다음은 몇 가지 예입니다.

• 애플리케이션 보안, Kubernetes RBAC, 네트워크 정책, Azure 정책 및 다른 서비스와의 통신에 대한 결정.
• Azure Firewall, WAF(웹 애플리케이션 방화벽), NSG(네트워크 보안 그룹)성의 구성 및 유지 관리와 DNS 구성.
• 서버 보안, 패치, 구성 및 엔드포인트 보안을 모니터링하고 수정합니다.
• Azure 리소스를 관리하기 위해 RBAC, 클라우드용 Microsoft Defender, 관리자 보호 전략 및 Azure Policy 사용에 대한 방향을 설정합니다.
• 인시던트 모니터링 및 응답 팀. SIEM(보안 정보 및 이벤트 관리) 또는 클라우드용 Microsoft Defender에서 보안 인시던트를 조사하고 수정합니다.

그런 다음, 워크로드 및 인프라와 관련하여 역할에 필요한 액세스 수준을 결정하여 정의를 공식화합니다. 다음은 설명을 위한 간단한 정의입니다.

역할	담당 작업	액세스 수준
애플리케이션 소유자	비즈니스 결과에 맞게 기능을 정의하고 우선 순위를 지정합니다. 기능이 워크로드의 규정 준수 범위 지정에 미치는 영향을 이해하고 고객 데이터 보호 및 소유권과 비즈니스 목표의 균형을 조정합니다.	애플리케이션에서 내보낸 로그 및 메트릭에 대한 읽기 권한. 워크로드 또는 클러스터에 액세스할 수 있는 권한이 필요하지 않습니다.
애플리케이션 개발자	애플리케이션을 개발합니다. 모든 애플리케이션 코드는 규정 준수, 증명 및 릴리스 관리 프로세스를 유지하는 교육 및 품질 게이트의 적용을 받습니다. 빌드 파이프라인은 관리할 수 있지만 일반적으로 배포 파이프라인은 관리할 수 없습니다.	워크로드 범위에 있는 Kubernetes 네임스페이스 및 Azure 리소스에 대한 읽기 권한. 시스템의 상태를 배포하거나 수정하기 위한 쓰기 권한이 없습니다.
애플리케이션 운영자(또는 SRE)	코드 베이스, 관찰 가능성 및 연산을 깊이 이해합니다. 라이브 사이트 심사 및 문제 해결을 수행합니다. 애플리케이션 개발자와 함께 애플리케이션의 가용성, 확장성 및 성능을 개선합니다. "최종 단계의" 배포 파이프라인을 관리하고 빌드 파이프라인을 관리하는 데 도움이 됩니다.	관련 Kubernetes 네임스페이스 및 Azure 리소스를 포함하는 애플리케이션 범위 내에서 높은 권한이 부여됩니다. Kubernetes 클러스터의 일부에 대한 대기 액세스 권한이 있을 수 있습니다.
인프라 소유자	연결 및 구성 요소의 기능을 포함하여 비용 효율적인 아키텍처를 설계합니다. 이 범위에는 클라우드 및 온-프레미스 서비스가 포함될 수 있습니다. 기능 데이터 보존, 비즈니스 연속성 기능 등을 결정합니다.	플랫폼 로그 및 비용 센터 데이터에 액세스합니다. 클러스터 내에서는 액세스 권한이 필요 없습니다.
인프라 운영자(또는 SRE)	클러스터 및 종속 서비스와 관련된 작업. 워크로드가 배포되는 클러스터의 파이프라인을 빌드, 배포 및 부트스트랩합니다. 대상 노드 풀과 예상 크기 조정 및 크기 조정 요구 사항을 설정합니다. 컨테이너 호스팅 인프라 및 종속 서비스의 상태를 모니터링합니다.	워크로드 네임스페이스에 대한 읽기 권한. 클러스터에 대한 높은 액세스 권한.
정책, 보안 소유자	보안 또는 규정 준수에 대한 전문 지식이 있습니다. 회사 직원, 자산 및 회사 고객의 보안 및 규정 준수를 보호하는 정책을 정의합니다. 정책이 적용되고 모든 단계를 통해 감사될 수 있도록 다른 모든 역할과 함께 작동합니다.	워크로드 및 클러스터에 대한 읽기 권한. 로그 및 감사 데이터에도 액세스합니다.
네트워크 운영자	엔터프라이즈 전체의 가상 네트워크 및 서브넷 할당. Azure Firewall, WAF, NSG의 구성 및 유지 관리와 DNS 구성.	네트워킹 계층에서 높은 권한이 부여됩니다. 클러스터 내에서 쓰기 권한이 없습니다.

요구 사항 7.1.2

권한 있는 사용자 ID에 대한 액세스를 직무를 수행하는 데 필요한 최소한의 권한으로 제한합니다.

사용자의 책임

직무에 따라 중단을 일으키지 않고 액세스를 최소화하기 위해 노력합니다. 다음은 몇 가지 모범 사례입니다.

• ID에는 작업을 완료하기에 충분한 액세스 권한이 있어야 합니다.
• 특히 범위 내 구성 요소에 액세스할 수 있는 중요한 영향 ID에 대한 대기 권한을 최소화합니다.
• 가능한 경우 제한을 추가합니다. 한 가지 방법은 액세스 조건에 따라 조건부 액세스를 제공하는 것입니다.
• 읽기 액세스에 대해서도 구독에 액세스할 수 있는 사용자 및 그룹에 대한 정기적인 검토 및 감사를 수행합니다. 외부 ID 초대를 방지합니다.

요구 사항 7.1.3

개별 담당자의 작업 분류 및 직무에 따라 액세스 권한을 할당합니다.

사용자의 책임

개인의 명확하게 할당된 직무에 따라 사용 권한을 결정합니다. 시스템 또는 직원의 재임 기간과 같은 매개 변수를 사용하지 않습니다. 단일 사용자 또는 그룹에 액세스 권한을 부여합니다.

몇 가지 예제는 다음과 같습니다.

직군	역할
제품 소유자는 워크로드의 범위를 정의하고 기능의 우선 순위를 지정합니다. 고객 데이터 보호 및 소유권과 비즈니스 목표의 균형을 조정합니다. 보고서, 비용 센터 또는 Azure 대시보드에 액세스해야 합니다. 클러스터 내부 액세스 또는 클러스터 수준 권한은 필요 없습니다.	애플리케이션 소유자
소프트웨어 엔지니어는 애플리케이션 코드를 설계, 개발 및 컨테이너화합니다. Azure 내에서 정의된 범위(예: Application Insights) 및 워크로드 네임스페이스 내에서 대기 읽기 권한이 있는 그룹. 이러한 범위와 권한은 사전 프로덕션 환경과 프로덕션 환경 간에 다를 수 있습니다.	애플리케이션 개발자
사이트 안정성 엔지니어는 라이브 사이트 심사를 수행하고, 파이프라인을 관리하고, 애플리케이션 인프라를 설정합니다. 할당된 네임스페이스 내에서 모든 권한을 가진 그룹 A. 대기 권한은 필요하지 않습니다. 워크로드에 대한 일상적인 작업을 위한 그룹 B. 할당된 네임스페이스 내에서는 대기 권한을 가질 수 있지만 높은 권한이 부여되지 않습니다.	애플리케이션 운영자
클러스터 운영자는 안정적이고 안전한 AKS 클러스터를 설계하고 플랫폼에 배포합니다. 클러스터 작동 시간 유지 관리를 담당합니다. 할당된 네임스페이스 내에서 모든 권한을 가진 그룹 A. 대기 권한은 필요하지 않습니다. 워크로드에 대한 일상적인 작업을 위한 그룹 B. 할당된 네임스페이스 내에서는 대기 권한을 가질 수 있지만 높은 권한이 부여되지 않습니다.	인프라 운영자
네트워크 엔지니어는 엔터프라이즈 전체의 가상 네트워크 및 서브넷, 온-프레미스에서 클라우드 연결 및 네트워크 보안을 할당합니다.	인프라 운영자

요구 사항 7.1.4

필수 권한을 지정하는 권한 있는 당사자에 의한 문서화된 승인이 필요합니다.

사용자의 책임

권한의 초기 할당을 포함하여 역할 및 권한의 변경 내용을 승인하기 위한 제어된 프로세스가 있어야 합니다. 해당 승인이 문서화되어 검사에 사용할 수 있는지 확인합니다.

요구 사항 7.2

사용자의 알아야 할 필요에 따라 액세스를 제한하고 특별히 허용되지 않으면 "모두 거부"로 설정하는 시스템 구성 요소의 액세스 제어 시스템을 설정합니다.

사용자의 책임

요구 사항 7.1을 수행한 후에는 조직 및 워크로드에 적용할 수 있는 역할 및 책임을 평가해야 합니다. 범위 내 아키텍처의 모든 구성 요소에 제한된 액세스 권한이 있어야 합니다. 여기에는 워크로드, 데이터 스토리지, 네트워크 액세스 및 CHD(카드 소유자 데이터) 처리에 참여하는 다른 모든 서비스를 실행하는 AKS 노드가 포함됩니다.

역할 및 책임에 따라 인프라의 RBAC(역할 기반 액세스 제어)에 역할을 할당합니다. 해당 메커니즘은 다음과 같습니다.

• Kubernetes RBAC는 Kubernetes API 서버를 통해 노출되는 Kubernetes 컨트롤 플레인에 대한 액세스를 제어하는 원시 Kubernetes 권한 부여 모델입니다. 이 권한 세트는 API 서버로 수행할 수 있는 작업을 정의합니다. 예를 들어 사용자에게 Pod를 만들거나 나열할 수 있는 권한을 거부할 수 있습니다.
• Azure RBAC는 Azure 컨트롤 플레인에 대한 액세스를 제어하는 Microsoft Entra ID 기반 권한 부여 모델입니다. 이는 Microsoft Entra 테넌트를 Azure 구독과 연결한 것입니다. Azure RBAC를 사용하면 네트워크, AKS 클러스터 및 관리 ID와 같은 Azure 리소스를 만들 수 있는 권한을 부여할 수 있습니다.

클러스터 운영자(인프라 운영자 역할에 매핑됨)에게 사용 권한을 부여해야 한다고 가정해 보세요. 인프라 운영자 책임이 할당된 모든 사용자는 Microsoft Entra 그룹에 속합니다. 7.1.1에서 설정한 대로 이 역할에는 클러스터에서 가장 높은 권한이 필요합니다. Kubernetes에는 이러한 요구 사항을 충족하는 기본 제공 RBAC 역할(예: cluster-admin)이 있습니다. 역할 바인딩을 만들어 인프라 운영자용 Microsoft Entra 그룹을 바인딩해야 cluster-admin 합니다. 다음과 같이 두 가지 방법이 있습니다. 기본 제공 역할을 선택할 수 있습니다. 또는 기본 제공 역할이 요구 사항을 충족하지 않는 경우(예: 과도한 권한이 부여된 경우) 바인딩에 대한 사용자 지정 역할을 만듭니다.

참조 구현은 원시 Kubernetes RBAC를 사용하여 이전 예제를 보여 줍니다. Azure RBAC를 사용하여 동일한 연결을 수행할 수 있습니다. 자세한 내용은 Azure Kubernetes Service에서 Kubernetes 역할 기반 액세스 제어 및 Microsoft Entra ID를 사용하여 클러스터 리소스에 대한 액세스 제어를 참조 하세요.

클러스터 수준 또는 네임스페이스 수준에서 사용 권한 범위를 선택할 수 있습니다. 애플리케이션 운영자와 같이 범위가 지정된 책임이 있는 역할의 경우 워크로드의 네임스페이스 수준에서 권한이 할당됩니다.

또한 역할이 작업을 수행할 수 있도록 Azure RBAC 권한이 필요합니다. 예를 들어 클러스터 운영자는 포털을 통해 Azure Monitor에 액세스해야 합니다. 따라서 인프라 운영자 역할에는 적절한 RBAC 할당이 있어야 합니다.

사용자 및 해당 역할 외에도 Azure 리소스와 클러스터 내의 Pod에는 관리 ID가 있습니다. 이러한 ID에는 Azure RBAC를 통한 사용 권한 세트가 필요하며 예상 작업에 따라 엄격하게 범위가 지정되어야 합니다. 예를 들어 Azure Application Gateway에는 Azure Key Vault에서 비밀(TLS 인증서)을 가져올 수 있는 권한이 있어야 합니다. 비밀을 수정할 수 있는 권한이 없어야 합니다.

다음은 몇 가지 모범 사례입니다.

• 각 역할 및 할당된 권한에 대한 세심한 설명서를 유지 관리합니다. JIT 권한과 대기 권한을 명확하게 구분합니다.

• 역할의 변경 내용(예: 할당 또는 역할 정의 변경 내용)을 모니터링합니다. 변경 내용의 숨은 의도를 파악해야 하는 경우에도 변경 내용에 대한 경고를 만듭니다.

요구 사항 7.2.1

모든 시스템 구성 요소 포함

사용자의 책임

액세스 제어 조치를 유지 관리하는 몇 가지 모범 사례는 다음과 같습니다.

• 대기 액세스 권한이 없습니다. Just-In-Time AD 그룹 멤버 자격을 사용하는 것이 좋습니다. 이 기능을 사용하려면 Microsoft Entra Privileged Identity Management가 필요합니다.

• 클러스터에 대한 Microsoft Entra ID에서 조건부 액세스 정책을 설정합니다. 이렇게 하면 Kubernetes 컨트롤 플레인에 대한 액세스가 추가로 제한됩니다. 조건부 액세스 정책을 사용하면 다단계 인증을 요구하거나, Microsoft Entra 테넌트에서 관리하는 디바이스로 인증을 제한하거나, 일반적이지 않은 로그인 시도를 차단할 수 있습니다. 높은 권한으로 Kubernetes 역할에 매핑된 Microsoft Entra 그룹에 이러한 정책을 적용합니다.

  참고 항목

  JIT 및 조건부 액세스 기술 선택 모두 Microsoft Entra ID P1 또는 P2가 필요합니다.

• 클러스터 노드에 대한 SSH 액세스를 사용하지 않도록 설정하는 것이 좋습니다. 이 참조 구현은 해당 용도로 SSH 연결 세부 정보를 생성하지 않습니다.

• 점프 상자와 같은 추가 컴퓨팅은 권한이 있는 사용자가 액세스해야 합니다. 전체 팀에서 사용할 수 있는 일반 로그인을 만들지 마세요.

요구 사항 7.2.2

작업 분류 및 직무에 따라 개인에게 권한 할당

사용자의 책임

7.1.3에 따라 클러스터 작업에는 많은 역할이 포함됩니다. 표준 Azure 리소스 역할 외에도 액세스 범위 및 프로세스를 정의해야 합니다.

예를 들어 클러스터 운영자 역할을 고려합니다. 클러스터 심사 활동에 대해 명확하게 정의된 플레이북이 있어야 합니다. 워크로드 팀의 액세스는 얼마나 다른가요? 조직에 따라 똑같을 수도 있습니다. 고려해야 할 사항은 다음과 같습니다.

• 클러스터에 액세스하는 방법
• 액세스가 허용되는 원본
• 클러스터에 대해 필요한 권한
• 이러한 권한이 할당되는 시기

워크로드 운영자 및 클러스터 운영자에 대한 거버넌스 설명서, 정책 및 교육 자료에 정의가 문서화되어 있는지 확인합니다.

요구 사항 7.2.3

기본 "모두 거부" 설정.

사용자의 책임

구성을 시작할 때 제로 트러스트 정책으로 시작합니다. 필요에 따라 예외를 만들고 자세히 문서화합니다.

• Kubernetes RBAC는 기본적으로 모두 거부를 구현합니다. 모두 거부 설정을 역으로 적용하는 권한 높은 클러스터 역할 바인딩을 추가하여 재정의하지 마세요.

• 또한 Azure RBAC는 기본적으로 모두 거부를 구현합니다. 모두 거부 설정을 역으로 적용하는 RBAC 할당을 추가하여 재정의하지 마세요.

• 모든 Azure 서비스, Azure Key Vault 및 Azure Container Registry는 기본적으로 모두 거부 권한 세트를 사용합니다.

• 점프 상자와 같은 모든 관리 액세스 지점은 초기 구성에서 모든 액세스를 거부해야 합니다. 모든 관리자 권한은 모두 거부 규칙에 명시적으로 정의해야 합니다.

요구 사항 7.3

카드 소유자 데이터에 대한 액세스를 제한하기 위해 보안 정책과 운영 절차가 문서화되고 사용 중이며 모든 해당 당사자가 알고 있어야 합니다.

사용자의 책임

프로세스 및 정책에 대한 완전한 설명서를 유지 관리하는 것이 중요합니다. 여기에는 Azure 및 Kubernetes RBAC 정책과 조직 거버넌스 정책이 포함됩니다. 규제된 환경을 운영하는 사용자는 보안 보증을 지원할 수 있도록 교육을 받고 정보를 얻고 인센티브를 받아야 합니다. 이는 정책 관점에서 승인 프로세스의 일부인 사용자에게 특히 중요합니다.

요구 사항 8 — 시스템 구성 요소에 대한 액세스 식별 및 인증

AKS 기능 지원

AKS 및 Microsoft Entra 통합으로 인해 액세스 관리, 식별자 개체 관리 등을 비롯한 ID 관리 및 권한 부여 기능을 활용할 수 있습니다. 자세한 내용은 AKS에서 관리하는 Microsoft Entra 통합을 참조 하세요.

사용자의 책임

요구 사항	책임
요구 사항 8.1	다음과 같이 모든 시스템 구성 요소에서 소비자가 아닌 사용자와 관리자에게 적절한 사용자 식별 관리를 보장하는 정책 및 절차를 정의하고 구현합니다.
요구 사항 8.2	고유 ID를 할당하는 것 외에도 모든 사용자를 인증하기 위해 다음 방법 중 하나 이상을 사용하여 모든 시스템 구성 요소에서 소비자가 아닌 사용자 및 관리자에 대해 적절하게 사용자 인증 관리하도록 합니다.
요구 사항 8.3	다단계 인증을 사용하여 모든 개별 비 콘솔 관리 액세스 및 CDE에 대한 모든 원격 액세스를 보호합니다.
요구 사항 8.4	다음을 비롯한 모든 사용자에게 인증 정책 및 절차를 문서화하고 전달합니다.
요구 사항 8.5	다음과 같이 그룹 ID, 공유 ID 일반 ID, 암호 또는 다른 인증 방법을 사용하지 마세요.
요구 사항 8.6	다른 인증 메커니즘을 사용하는 경우(예: 실제 또는 논리 보안 토큰, 스마트 카드, 인증서 등) 이러한 인증 메커니즘을 사용하도록 다음과 같이 할당되어야 합니다.
요구 사항 8.7	카드 소유자 데이터를 포함하는 데이터베이스에 대한 모든 액세스(애플리케이션, 관리자 및 다른 모든 사용자에 의한 액세스 포함)는 다음과 같이 제한됩니다.
요구 사항 8.8	식별 및 인증을 위한 보안 정책과 운영 절차가 문서화되고 사용 중이며 모든 해당 당사자가 알고 있어야 합니다.

요구 사항 8.1

다음과 같이 모든 시스템 구성 요소에서 소비자가 아닌 사용자와 관리자에게 적절한 사용자 식별 관리를 보장하는 정책 및 절차를 정의하고 구현합니다.

• 8.1.1 사용자가 시스템 구성 요소 또는 카드 소유자 데이터에 액세스하도록 허용하기 전에 고유 ID를 할당합니다.
• 8.1.2 사용자 ID, 자격 증명 및 기타 식별자 개체를 추가, 삭제 및 수정하도록 제어합니다.
• 8.1.3 해지된 사용자에 대한 액세스 권한을 즉시 종료합니다.
• 8.1.4 90일 이내에 비활성 사용자 계정을 제거/비활성화합니다.
• 8.1.5 다음과 같이 원격 액세스를 통해 시스템 구성 요소에 액세스, 지원 또는 유지 관리하기 위해 타사에서 사용하는 ID를 관리합니다.
  • 필요한 기간 동안만 활성화되고 사용하지 않을 때는 비활성화됩니다.
  • 사용 중일 때 모니터링됩니다.
• 8.1.6 6번이 넘지 않게 시도한 후에 사용자 ID를 잠금으로써 반복되는 액세스 시도를 제한합니다.
• 8.1.7 잠금 기간을 최소 30분 또는 관리자가 사용자 ID를 사용하도록 설정할 때까지로 설정합니다.
• 8.1.8 세션이 15분 동안 유휴 상태였을 경우 사용자가 터미널 또는 세션을 다시 활성화하기 위해 다시 인증해야 합니다.

사용자의 책임

이 요구 사항에 대한 전반적인 고려 사항은 다음과 같습니다.

적용 대상: 8.1.1, 8.1.2, 8.1.3

CDE의 기능적으로 다른 부분에 대한 ID를 공유하거나 다시 사용하지 마세요. 예를 들어 팀 계정을 사용하여 데이터 또는 클러스터 리소스에 액세스하지 마세요. ID 설명서에 공유 계정 사용 금지가 명시되어 있는지 확인합니다.

이 ID 주체를 Azure의 관리 ID 할당으로 확장합니다. Azure 리소스 간에 사용자 관리 ID를 공유하지 마세요. 각 Azure 리소스에 고유한 관리 ID를 할당합니다. 마찬가지로 AKS 클러스터에서 Microsoft Entra 워크로드 ID 사용하는 경우 광범위한 ID를 사용하는 대신 워크로드의 각 구성 요소가 자체 ID를 수신하는지 확인합니다. 사전 프로덕션 및 프로덕션에서 동일한 관리 ID를 사용하지 마세요.

AKS(Azure Kubernetes Service)의 액세스 및 ID 옵션

적용 대상: 8.1.2, 8.1.3, 8.1.4

Microsoft Entra ID를 ID 저장소로 사용합니다. 클러스터와 모든 Azure 리소스는 Microsoft Entra ID를 사용하므로 Microsoft Entra ID 액세스를 사용하지 않도록 설정하거나 취소하면 모든 리소스에 자동으로 적용됩니다. Microsoft Entra ID로 직접 지원되지 않는 구성 요소가 있는 경우 액세스를 제거하는 프로세스가 있는지 확인합니다. 예를 들어 사용자가 더 이상 유효하지 않은 경우 점프 상자에 액세스하기 위한 SSH 자격 증명을 명시적으로 제거해야 할 수 있습니다.

적용 대상: 8.1.5

공급업체, 파트너 등의 타사 계정을 게스트 사용자로 호스트하도록 설계된 Microsoft Entra B2B(Business-to-Business)를 활용합니다. 조건부 정책을 사용하여 회사 데이터를 보호하여 적절한 수준의 액세스 권한을 부여합니다. 이러한 계정에는 최소한의 대기 권한과 필수 만료 날짜가 있어야 합니다. 자세한 내용은 Microsoft Entra B2B의 게스트 사용자 액세스란?을 참조하세요.

조직에는 공급업체 및 유사한 액세스 권한에 대한 명확하고 문서화된 패턴이 있어야 합니다.

적용 대상: 8.1.6, 8.1.7, 8.1.8

사용자의 책임

Microsoft Entra ID는 로그인 시도 실패 후 사용자를 잠그는 스마트 잠금 기능을 제공합니다. 잠금을 구현하는 권장 방법은 Microsoft Entra 조건부 액세스 정책을 사용하는 것입니다.

유사한 기능을 지원하지만 Microsoft Entra ID(예: 점프 상자와 같은 SSH 지원 컴퓨터)로 지원되지 않는 구성 요소에 대한 잠금을 구현합니다. 이렇게 하면 잠금을 사용하여 액세스 시도 남용을 방지하거나 느리게 할 수 있습니다.

AKS 노드는 정기적으로 액세스하도록 설계되지 않았습니다. 클러스터 노드에 대한 직접 SSH 또는 원격 데스크톱 연결을 차단합니다. SSH 액세스는 고급 문제 해결 작업 시에만 고려해야 합니다. 액세스를 면밀히 모니터링하고 특정 이벤트가 완료된 후 즉시 되돌려야 합니다. 이렇게 할 경우 노드 수준 변경으로 인해 클러스터 지원이 중단될 수 있습니다.

요구 사항 8.2

고유한 ID를 할당하는 것 외에도 모든 사용자를 인증하는 데 다음 방법 중 하나 이상을 사용하여 모든 시스템 구성 요소에서 비 소비자 사용자 및 관리자를 위한 적절한 사용자 인증 관리를 보장합니다. 암호 또는 암호문 같이 사용자가 기억하는 것, 토큰 디바이스 또는 스마트 카드 같이 사용자가 보유하고 있는 것, 생체 인식과 같은 사용자의 신체 일부.

• 8.2.1 강력한 암호화를 사용하여 모든 시스템 구성 요소에 전송 또는 스토리지하는 동안 읽을 수 없는 모든 인증 자격 증명(예: 암호/구)을 렌더링합니다.
• 8.2.2 암호 재설정을 수행하거나, 새 토큰을 프로비전하거나, 새 키를 생성하는 등 인증 자격 증명을 수정하기 전에 사용자 ID를 확인합니다.
• 8.2.3 암호/구는 다음을 충족해야 합니다.
  • 최소한 길이가 7자여야 합니다.
  • 숫자와 문자를 모두 포함합니다.
• 8.2.4 사용자 암호를 90일마다 한 번 이상 변경합니다.
• 8.2.5 개인 사용자는 누군가가 사용하는 최근 4개의 암호/액세스 코드와 동일한 새 암호/액세스 코드를 전송할 수 없습니다.
• 8.2.6 처음으로 사용할 암호/액세스 코드를 설정한 후에, 각 사용자에게 고유한 값으로 다시 설정하고, 처음 사용한 후 즉시 변경합니다.

사용자의 책임

클러스터에 대한 Microsoft Entra ID에서 조건부 액세스 정책을 설정합니다. 이렇게 하면 Kubernetes 컨트롤 플레인에 대한 액세스가 추가로 제한됩니다.

이전 요구 사항 집합 중 일부는 Microsoft Entra ID에 의해 자동으로 처리됩니다. 다음은 몇 가지 예입니다.

• 암호 보안

  Microsoft Entra ID는 강력한 암호 사용을 적용하는 기능을 제공합니다. 예를 들어 전역 금지 암호 목록에 속하는 약한 암호는 차단됩니다. 이 방법으로는 충분한 보호가 될 수 없습니다. Microsoft Entra Password Protection 기능을 추가하여 조직별 금지 목록을 만드는 것이 좋습니다. 암호 정책은 기본적으로 적용됩니다. 특정 정책은 수정할 수 없으며 이전 요구 사항 세트 중 일부를 포함합니다. 여기에는 암호 만료 및 허용되는 문자가 포함됩니다. 전체 목록은 Microsoft Entra 암호 정책을 참조하세요. 유출된 사용자 이름 및 암호 쌍을 검색하는 사용자 위험 기반 조건부 액세스 같이 조건부 액세스 정책을 사용하여 적용할 수 있는 고급 기능을 사용하는 것이 좋습니다. 자세한 내용은 조건부 액세스: 사용자 위험 기반 조건부 액세스를 참조하세요.

  참고

  암호 없는 옵션을 고려하는 것이 좋습니다. 자세한 내용은 Microsoft Entra ID에서 암호 없는 인증 배포 계획을 참조하세요.

• 사용자 본인 확인

  로그인 위험 조건부 액세스 정책을 적용하여 요청 ID에 의해 인증 요청이 발급되었는지 검색할 수 있습니다. 요청은 위협 인텔리전스 원본을 기준으로 유효성을 검사합니다. 여기에는 암호 스프레이 및 IP 주소 변칙이 포함됩니다. 자세한 내용은 조건부 액세스: 로그인 위험 기반 조건부 액세스를 참조하세요.

SSH를 사용하여 점프 상자에 액세스하는 것과 같이 Microsoft Entra ID를 사용하지 않는 구성 요소가 있을 수 있습니다. 이러한 경우 RSA 2048 키 크기 이상의 공개 키 암호화를 사용합니다. 항상 암호를 지정합니다. 알려진 승인된 공개 키를 추적하는 유효성 검사 프로세스가 있습니다. 공개 키 액세스를 사용하는 시스템은 인터넷에 노출되어서는 안 됩니다. 대신 프라이빗 키 유출의 영향을 줄이기 위해 Azure Bastion과 같은 중개자를 통해 모든 SSH 액세스를 허용해야 합니다. 직접 암호 액세스를 사용하지 않도록 설정하고 암호 없는 대체 솔루션을 사용합니다.

요구 사항 8.3

다단계 인증을 사용하여 모든 개별 비 콘솔 관리 액세스 및 CDE에 대한 모든 원격 액세스를 보호합니다. 참고: 다단계 인증은 인증하기 위해 최소한 두 가지 인증 방법(인증 방법에 대한 설명은 요구 사항 8.2 참조)을 사용해야 합니다. 1단계를 두 번 사용하는 것(예: 두 개의 별도 암호 사용)은 다단계 인증으로 간주되지 않습니다.

사용자의 책임

조건부 액세스 정책을 사용하여 다단계 인증을 적용합니다(특히 관리 계정을 대상으로). 이러한 정책은 몇 가지 기본 제공 역할에 권장됩니다. 높은 권한으로 Kubernetes 역할에 매핑된 Microsoft Entra 그룹에 이러한 정책을 적용합니다.

이 정책은 추가 정책으로 더욱 강화될 수 있습니다. 다음은 몇 가지 예입니다.

• Microsoft Entra 테넌트에서 관리하는 디바이스로 인증을 제한할 수 있습니다.
• 클러스터 네트워크 외부의 네트워크에서 액세스가 시작되는 경우 다단계 인증을 적용할 수 있습니다.

자세한 내용은 다음을 참조하세요.

• 조건부 액세스: 관리자용 MFA 필요
• 방법: 조건부 액세스를 사용하는 클라우드 앱 액세스에 대한 관리 디바이스 필요
• 방법: 조건부 액세스를 사용하는 신뢰할 수 없는 네트워크에서의 액세스에 대한 MFA 필요

요구 사항 8.4

다음을 비롯한 모든 사용자에게 인증 정책 및 절차를 문서화하고 전달합니다.

• 강력한 인증 자격 증명을 선택하는 지침
• 사용자가 해당 인증 자격 증명을 보호하는 방법에 대한 지침
• 이전에 사용한 암호를 다시 사용하지 않는 지침
• 암호가 손상될 수 있는 경우 암호를 변경하는 지침.

사용자의 책임

적용된 정책에 대한 설명서를 유지 관리합니다. ID 온보딩 교육의 일환으로 암호 재설정 절차에 대한 지침과 자산 보호에 대한 조직 모범 사례를 제공합니다.

요구 사항 8.5

다음과 같이 그룹 ID, 공유 ID 일반 ID, 암호 또는 다른 인증 방법을 사용하지 마세요.

• 일반 사용자 ID는 비활성화되거나 제거됩니다.
• 공유 사용자 ID는 시스템 관리 및 기타 중요 기능에 존재하지 않습니다.
• 공유 및 일반 사용자 ID는 시스템 구성 요소를 관리하는 데 사용되지 않습니다.

사용자의 책임

클러스터 또는 Pod의 기능적으로 다른 부분에 대한 ID를 공유하거나 다시 사용하지 마세요. 예를 들어 팀 계정을 사용하여 데이터 또는 클러스터 리소스에 액세스하지 마세요. ID 설명서에 공유 계정 사용 금지가 명시되어 있는지 확인합니다.

CDE에서 루트 사용자를 사용하지 않도록 설정합니다. 사용자가 CDE 내의 클러스터에 대한 기본 제공 --admin 액세스를 사용할 수 없도록 Kubernetes 로컬 계정 사용을 사용하지 않도록 설정합니다.

요구 사항 8.6

다른 인증 메커니즘을 사용하는 경우(예: 실제 또는 논리 보안 토큰, 스마트 카드, 인증서 등) 이러한 인증 메커니즘을 사용하도록 다음과 같이 할당되어야 합니다.

• 인증 메커니즘은 개별 계정에 할당되고 여러 계정 간에 공유되지 않아야 합니다.
• 물리적 및/또는 논리 컨트롤은 원래 사용하려던 계정만이 액세스 권한을 얻기 위해 해당 메커니즘을 사용할 수 있도록 해야 합니다.

사용자의 책임

CDE에 대한 모든 액세스가 사용자별 ID에 제공되고 물리적 또는 가상 토큰으로 확장되었는지 확인합니다. 여기에는 CDE 네트워크에 대한 모든 VPN 액세스가 포함되므로 엔터프라이즈 지점 및 사이트 간 액세스(있는 경우)가 해당 인증 흐름의 일부로 사용자별 인증서를 사용하도록 보장됩니다.

요구 사항 8.7

카드 소유자 데이터를 포함하는 데이터베이스에 대한 모든 액세스(애플리케이션, 관리자 및 다른 모든 사용자에 의한 액세스 포함)는 다음과 같이 제한됩니다.

• 모든 사용자 액세스, 사용자 쿼리 및 데이터베이스에 대한 사용자 조치는 프로그래밍 방식을 통해 수행됩니다.
• 데이터베이스 관리자만이 데이터베이스를 직접 액세스하거나 쿼리할 수 있습니다.
• 데이터베이스 애플리케이션에 대한 애플리케이션 ID는 해당 애플리케이션에서만 사용할 수 있습니다(다른 개별 사용자 또는 애플리케이션이 아닌 프로세스는 불가).

사용자의 책임

역할 및 책임에 따라 액세스를 제공합니다. 사용자는 자신의 ID를 사용할 수 있지만 최소한의 대기 권한을 사용하여 알아야 할 사항을 기준으로 액세스가 제한되어야 합니다. 사용자가 애플리케이션 ID를 사용하면 안 되며 데이터베이스 액세스 ID가 공유되면 안 됩니다.

가능하면 관리 ID를 통해 애플리케이션에서 데이터베이스에 액세스합니다. 그렇지 않을 경우 연결 문자열 및 자격 증명에 대한 노출을 제한합니다. Kubernetes 비밀을 사용하여 Pod 정의와 같이 쉽게 검색할 수 있는 위치를 유지하는 대신 중요한 정보를 저장합니다. 또 다른 방법은 Azure Key Vault 같은 관리되는 저장소에 비밀을 저장하고 해당 저장소에서 로드하는 것입니다. AKS 클러스터에 관리 ID가 사용하도록 설정된 상태에서 액세스 권한을 얻으려면 Key Vault에 자체적으로 인증해야 합니다.

요구 사항 8.8

식별 및 인증을 위한 보안 정책과 운영 절차가 문서화되고 사용 중이며 모든 해당 당사자가 알고 있어야 합니다.

사용자의 책임

프로세스 및 정책에 대한 완전한 설명서를 유지 관리하는 것이 중요합니다. 적용된 정책에 대한 설명서를 유지 관리합니다. ID 온보딩 교육의 일환으로 암호 재설정 절차에 대한 지침과 자산 보호에 대한 조직 모범 사례를 제공합니다. 규제된 환경을 운영하는 사용자는 보안 보증을 지원할 수 있도록 교육을 받고 정보를 얻고 인센티브를 받아야 합니다. 이는 정책 관점에서 승인 프로세스의 일부인 사용자에게 특히 중요합니다.

요구 사항 9 — 카드 소유자 데이터에 대한 물리적 액세스 제한

AKS 기능 지원

이 요구 사항에 적용 가능한 AKS 기능은 없습니다.

사용자의 책임

이 아키텍처 및 구현은 온-프레미스 리소스 또는 데이터 센터에 대한 물리적 액세스 제어를 제공하도록 설계되지 않았습니다. 고려 사항은 공식 PCI-DSS 3.2.1 표준 지침을 참조하세요.

다음은 기술 컨트롤 적용에 대한 몇 가지 제안 사항입니다.

• CDE의 점프 상자와 같은 관리 콘솔 액세스에서 세션 시간 제한을 조정하여 액세스를 최소화합니다.

• 조건부 액세스 정책을 조정하여 Azure Portal 같은 액세스 지점에서 Azure 액세스 토큰의 TTL을 최소화합니다. 자세한 내용은 다음 문서를 참조하세요.

  • 조건부 액세스를 사용하여 인증 세션 관리를 구성합니다.
  • 구성 가능한 토큰 수명 - Microsoft ID 플랫폼

• 클라우드 호스트 CDE의 경우 물리적 액세스 및 하드웨어 관리에 대한 책임이 없습니다. 회사 네트워크 물리적 및 논리적 컨트롤에 의존합니다.

• 온-프레미스 대상으로 CHD 백업 내보내기를 최소화합니다. Azure에서 호스트되는 솔루션을 사용하여 백업에 대한 물리적 액세스를 제한합니다.

• 온-프레미스에 대한 백업을 최소화합니다. 이 작업이 필요한 경우 온-프레미스 대상이 감사 범위에 포함된다는 사실에 유의하세요.

다음 단계

네트워크 리소스 및 카드 소유자 데이터에 대한 모든 액세스를 추적하고 모니터링합니다. 보안 시스템 및 프로세스를 정기적으로 테스트합니다.