PCI-DSS 3.2.1에 대한 AKS 기준 클러스터의 작업 모니터링(7/9부)

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

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

정기적으로 네트워크 모니터링 및 테스트

요구 사항 10—네트워크 리소스 및 카드 소유자 데이터에 대한 모든 액세스 추적 및 모니터링

AKS 기능 지원

Azure는 AKS 클러스터를 포함하여 컨테이너를 모니터링하는 컨테이너 인사이트 기능을 제공합니다. 자세한 내용은 컨테이너 인사이트 개요를 참조하세요.

AKS는 시스템 및 데이터를 사전에 보호하는 데 유용할 수 있는 여러 수준의 감사 로그를 제공합니다. 활동 로그는 계정과 비밀 관리, 진단 설정 관리, 서버 관리와 관련된 작업과 기타 리소스 액세스 작업에 대한 정보를 제공합니다. 모든 로그는 날짜, 시간, ID 및 기타 자세한 정보와 함께 기록됩니다. AKS 클러스터에 대한 모든 API 호출의 모든 시간순 레코드에 액세스할 수도 있습니다. 로그에는 호출자, 호출이 이루어진 시점, 호출이 시작된 소스 등에 대한 정보가 포함됩니다. 자세한 내용은 AKS 컨트롤 플레인/리소스 로그를 참조하세요.

RBAC(역할 기반 액세스 제어)를 사용하여 Azure에서 리소스 액세스 정책을 표준 사례로 관리할 수 있습니다.

모든 로그는 고객 소유 스토리지 계정 또는 Azure Monitor 로그에 저장해야 합니다. 이렇게 하면 대량의 데이터에서 인사이트를 빠르게 생성할 수 있습니다. 모든 로그는 한 지역에서 3개 이상의 복사본으로 유지됩니다. 지역 간 백업 또는 복제를 사용하도록 설정하여 더 많은 복사본을 가질 수 있습니다. 모든 로그 항목은 보안 HTTP(s) 채널을 통해서만 사용할 수 있습니다.

Azure의 경고 프레임워크를 사용하면 의심스러운 액세스를 검색하도록 경고를 구성할 수 있습니다. 발생해야 하는 경고와 이벤트를 설정할 수 있습니다. 사용자는 활동 유형, 활동 콘텐츠 또는 활동 호출자를 기반으로 하는 필터링 기능이 있는 Log Analytics를 사용하여 전체 로그를 수동으로 확인할 수도 있습니다.

사용자의 책임

요구 사항 11 - 정기적으로 보안 시스템 및 프로세스 테스트

AKS 기능 지원

AKS는 Azure 모니터링 서비스와 통합됩니다.

• 컨테이너용 Microsoft Defender는 다양한 보안 검사 기능을 제공합니다. 예를 들어 컨테이너용 Defender는 컨테이너 레지스트리로 끌어오고, 밀어넣고, 가져온 이미지를 검사하고 권장 사항을 제공합니다. 자세한 내용은 취약성 평가를 참조하세요.

• 시스템 무결성 및 보안을 보호하기 위해 Azure Monitor를 사용하여 이벤트 유형을 기반으로 하는 경고를 설정할 수 있습니다. AKS 노드에서 예상되는 시스템 오류가 있는 경우 AKS는 시스템 처리를 중단하지 않고 리소스를 적시에 자동으로 복구합니다.

AKS 클러스터는 WAF(웹 애플리케이션 방화벽)가 있는 Azure Application Gateway로 보호되며 검색 모드에서 경고 및 위협을 기록하도록 구성할 수 있습니다. 탐지된 침입 및 공격을 능동적으로 차단하는 방지 모드를 사용하는 것이 더 좋습니다. 자세한 내용은 AKS(Azure Kubernetes Service)의 네트워크 연결 및 보안에 대한 모범 사례를 참조하세요.

사용자의 책임

요구 사항 10.1

시스템 구성 요소에 대한 모든 액세스를 각 개별 사용자에게 연결하도록 감사 내역을 구현합니다.

사용자의 책임

다음 방법을 사용하여 각 구성 요소에서 수행되는 작업을 조사하는 것이 좋습니다.

• Azure Monitor 활동 로그. 활동 로그는 Azure 리소스 작업의 유형 및 시간에 대한 정보를 제공합니다. 또한 작업을 시작한 ID를 로그합니다. 기본적으로 사용하도록 설정되며, 리소스 작업이 완료되는 즉시 정보가 수집됩니다. 감사 내역은 변경할 수 없으며 삭제할 수 없습니다.

  데이터는 90일 동안 유지됩니다. 더 긴 보존 옵션을 위해 활동 로그 항목을 Azure Monitor 로그로 보내고 보존 및 보관 정책을 구성하는 것이 좋습니다.

  

• Azure Diagnostic 설정. 진단 설정은 설정이 적용되는 Azure 리소스 및 플랫폼에 대한 진단 및 감사 정보를 제공합니다. AKS 및 시스템의 다른 구성 요소(예: Azure Blob Storage 및 Key Vault)에 대한 진단 설정을 사용하도록 설정하는 것이 좋습니다. 리소스 종류에 따라 대상으로 보낼 로그 및 메트릭 데이터의 유형을 선택할 수 있습니다. 진단 대상은 필수 보존 기간을 충족해야 합니다.

  • 제공된 AKS 범주에서 Kubernetes 감사 로그를 사용하도록 설정합니다. 진단 설정에는 kube-audit 또는 kube-audit-admin 및 guard가 포함됩니다.

    클러스터 상태를 수정할 수 있는 로그 기반 API 서버 호출을 확인하려면 kube-audit-admin을 사용하도록 설정합니다. 모든 API 서버 상호 작용(읽기 요청과 같은 수정되지 않는 이벤트 포함)에 대한 감사 내역이 필요한 경우 kube-audit를 대신 사용하도록 설정합니다. 이러한 이벤트가 다작이며, 노이즈를 일으키고, 소비 비용을 증가시킬 수 있습니다. 이러한 로그에는 요청을 수행하는 데 사용되는 액세스 및 ID 이름에 대한 정보가 있습니다.

    관리되는 Microsoft Entra ID 및 Azure RBAC(역할 기반 액세스 제어) 감사를 추적하려면 guard 로그를 사용하도록 설정합니다.

  • 사용자 기반 로그 외에도 Kubernetes 컨트롤 플레인의 로그(kube-apiserver 및 kube-controller-manager 포함)를 고려합니다. 이러한 로그는 일반적으로 사용자와 연결되지 않지만, 사용자가 수행한 시스템 변경 내용을 상호 연결하는 데 도움이 될 수 있습니다.

    자세한 내용은 컨트롤 플레인 구성 요소 로그 보기를 참조하세요.

  이 참조 구현은 cluster-autoscaler, kube-controller-manager, kube-audit-admin 및 guard 로그를 사용하도록 설정하고 Log Analytics 작업 영역으로 전달합니다. 작업 영역 보존 기간은 90일로 설정됩니다.

  

• AKS(Azure Kubernetes Service) 진단은 노드 오류와 같은 클러스터 관련 문제를 감지하고 해결하는 데 도움이 됩니다. 추가 비용이 발생하지 않는 네트워킹별 진단 데이터도 포함됩니다. 이 데이터는 일반적으로 사용자 활동과 연결되지 않지만, 사용자가 수행한 시스템 변경의 영향을 파악해야 하는 경우에 도움이 될 수 있습니다. 자세한 내용은 Azure Kubernetes Service 진단을 참조하세요.

리소스를 배포할 때 이전 감사 내역 메커니즘을 구현해야 합니다. 이러한 구성이 CDE에서 실수로 또는 악의적으로 사용하도록 설정되지 않도록 하려면 Azure Policy도 활성화해야 합니다.

요구 사항 10.2

다음 이벤트를 다시 구성하도록 모든 시스템 구성 요소에 대해 자동화된 감사 내역을 구현합니다.

• 10.2.1 카드 소유자 데이터에 대한 모든 개인 사용자 액세스
• 10.2.2 루트 또는 관리자 권한이 있는 개인이 수행한 모든 작업
• 10.2.3 모든 감사 추적에 대한 액세스
• 10.2.4 잘못된 논리적 액세스 시도
• 10.2.5 식별 및 인증 메커니즘 사용 및 변경 내용(새 계정 만들기 및 권한 상승을 망라한 여러 항목) 및 루트나 관리 권한이 있는 계정에 대한 모든 변경 내용, 추가 또는 삭제
• 10.2.6 감사 로그 초기화, 중지 또는 일시 중지
• 10.2.7 시스템 수준 개체 만들기 및 삭제

사용자의 책임

AKS는 요구 사항 10.1에서 설명한 대로 감사 로그를 여러 수준에서 제공합니다. 몇 가지 주요 사항은 다음과 같습니다.

• 활동 로그는 기본적으로 중요한 Azure 리소스 작업에 대한 정보를 제공합니다. 모든 로그에는 작업을 시작한 상태, 시간 및 ID가 포함됩니다.
• AKS 클러스터에 대한 모든 API 호출의 모든 레코드에 액세스하려면 진단 설정을 사용하도록 설정합니다. 로그는 요청자, 타임스탬프, 요청 원본 및 요청 콘텐츠에 대한 세부 정보를 제공합니다. 적절한 보존 기간을 사용하여 로그를 Log Analytics 작업 영역에 저장합니다. 감사 내역에 대한 액세스도 기록되도록 Log Analytics 작업 영역 로깅을 사용하도록 설정합니다.
• Container Insights를 사용하여 syslog 컬렉션을 사용하도록 설정 하여 Log Analytics 작업 영역에서 AKS 노드 수준 운영 체제 보안 및 상태 이벤트 로그를 캡처합니다. 이러한 로그는 SIEM으로도 수집되어야 합니다.
• 빌드 에이전트 및 점프 상자 같은 다른 컴퓨팅에 대한 OS 및 사용량 감사 로깅을 포함합니다. 루트로 직접 시스템에 대한 액세스를 사용하지 않도록 설정합니다. 모든 작업이 특정 ID로 수행되고 있는지 확인합니다.
• 실패한 액세스 시도를 로그합니다. 여기에는 Azure Storage, Azure Key Vault, AKS API 서버 및 다른 시스템에 대한 RDP/SSH 액세스와 같은 구성 요소에 대한 액세스 요청이 포함됩니다.
• 타사 보안 에이전트에서 제공하는 기능을 활용하여 AKS 클러스터 내의 사용자 패턴을 분석할 수 있습니다. 이러한 기능은 사용자 액세스 감사 데이터에 유용할 수 있습니다.

요구 사항 10.3

각 이벤트의 모든 시스템 구성 요소에 대해 최소한 다음 감사 내역 항목을 기록합니다.

• 10.3.1 사용자 ID
• 10.3.2 이벤트 유형
• 10.3.3 날짜 및 시간
• 10.3.4 성공 또는 실패 표시
• 10.3.5 이벤트의 발생 위치
• 10.3.6 영향을 받는 데이터, 시스템 구성 요소 또는 리소스의 ID 또는 이름

사용자의 책임

요구 사항 10.2에서 설명한 대로 AKS에 대한 진단 설정을 사용하도록 설정하여 클러스터에서 감사 로그를 가져올 수 있습니다. 로그에는 이벤트 가져오기, 나열, 만들기, 업데이트, 삭제, 패치 및 게시에 대한 자세한 정보가 포함됩니다. 이러한 로그에는 요구 사항에 지정된 정보가 포함되어 있습니다. 정보를 쿼리할 수 있도록 로그를 스토리지 계정에 저장합니다.

예를 들어 다음 쿼리를 실행하여 kube-audit-admin 이벤트에 대한 이전 정보 세트를 확인하려고 합니다.

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

결과 집합에서 정보는 log_s 필드의 일부로 표시됩니다.

컨트롤 플레인 로그에 대한 자세한 내용은 AKS 컨트롤 플레인/리소스 로그를 참조하세요.

요구 사항 10.4

시간-동기화 기술을 사용하여 모든 중요한 시스템 시계 및 시간을 동기화하고 시간 획득, 배포 및 저장에 대해 다음이 구현되었는지 확인합니다.

• 10.4.1 중요 시스템의 시간이 올바르고 정확합니다.
• 10.4.2 시간 데이터를 보호합니다.
• 10.4.3 시간 설정을 업계에서 인정하는 시간 원본에서 받습니다.

참고: 시간 동기화 기술의 한 가지 예로 NTP(네트워크 시간 프로토콜)가 있습니다.

사용자의 책임

AKS는 기본 Azure 호스트의 NTP를 사용하며, NTP를 지원하기 위한 아웃바운드 네트워크 트래픽 허용량이 필요하지 않습니다. CDE에 추가하는 기타 VM은 ntp.ubuntu.org(및 해당 풀) 같은 외부 NTP 서버를 시간 동기화 원본으로 사용할 수 있습니다. CDE로 가져오는 추가 컴퓨팅은 선택한 NTP 소스를 명시적으로 사용하고 문서화해야 합니다.

요구 사항 10.5

감사 내역 보기를 업무와 관련하여 필요한 개인으로 제한합니다.

• 10.5.1 감사 내역 보기를 업무와 관련하여 필요한 개인으로 제한합니다.
• 10.5.2 감사 추적 파일이 무단으로 수정되지 않게 보호합니다.
• 10.5.3 감사 추적 파일을 변경이 어려운 중앙 집중식 로그 서버나 미디어에 즉시 백업합니다.
• 10.5.4 안전한 중앙 집중식 내부 로그 서버나 미디어 디바이스에 외부 연결 기술에 대한 로그를 기록합니다.
• 10.5.5 로그에서 파일 무결성 모니터링이나 변경 내용 검색 소프트웨어를 사용하여 기존 로그 데이터가 경고 생성 없이 변경되지 않게 합니다(새 데이터 추가는 경고를 생성하지 않더라도).

사용자의 책임

여러 로깅 싱크를 사용하면 감사 내역 데이터의 보안, 검토, 분석 및 쿼리에 대한 오버헤드가 추가됩니다. 전체 감사 내역 격리와 관리 문제 간의 균형을 유지하기 위해 감사 내역 토폴로지를 계획합니다.

가능한 경우 로그를 통합합니다. 장점은 데이터를 효율적으로 검토, 분석 및 쿼리할 수 있다는 것입니다. Azure는 몇 가지 기술 옵션을 제공합니다. Azure Monitor 컨테이너 인사이트를 사용하여 로그를 Log Analytics 작업 영역에 쓸 수 있습니다. 또 다른 옵션은 데이터를 Microsoft Sentinel과 같은 SIEM(보안 정보 및 이벤트 관리) 솔루션에 통합하는 것입니다. 다른 인기 있는 타사 선택 항목은 Splunk, QRadar 및 ArcSight입니다. 클라우드용 Microsoft Defender 및 Azure Monitor는 이러한 솔루션을 모두 지원합니다. 이러한 솔루션은 내역을 변경할 수 없도록 하는 추가 전용 데이터 싱크입니다.

클라우드용 Defender는 결과를 구성된 간격으로 내보낼 수 있습니다. 자세한 내용은 연속 내보내기를 참조하세요.

모든 로그는 한 지역에서 3개 이상의 복사본으로 유지됩니다. 백업 전략으로 지역 간 백업 또는 복제를 사용하도록 설정하여 더 많은 복사본을 가질 수 있습니다. 모든 로그 항목은 보안 HTTP(s) 채널을 통해서만 사용할 수 있습니다.

Log Analytics 및 Microsoft Sentinel은 감사 내역 액세스를 관리하기 위한 다양한 역할 기반 액세스 제어를 지원합니다. 역할이 조직의 역할 및 책임에 매핑되도록 합니다.

Log Analytics 작업 영역에서 작업 및 규정 준수 요구 사항을 모두 지원하도록 합니다. SIEM 솔루션에 전달되는 범위 내 클러스터에 대한 전용 작업 영역을 고려합니다.

AKS의 로깅 대부분은 stdout/stderr에서 제공되며 Azure Monitor 컨테이너 인사이트에서 수집됩니다. 수동으로 만든 다른 로그가 있는 경우 신뢰할 수 있는 전달 스트림으로 보내고 변조되지 않는 방식으로 데이터를 내보내는 것이 좋습니다.

요구 사항 10.6

모든 시스템 구성 요소에 대한 로그 및 보안 이벤트를 검토하여 변칙 또는 의심스러운 활동을 식별합니다.

• 10.6.1 최소한 다음을 매일 검토합니다.
  • 모든 보안 이벤트
  • CHD 및/또는 SAD를 저장, 처리 또는 전송하는 모든 시스템 구성 요소의 로그
  • 모든 중요 시스템 구성 요소의 로그
  • 보안 기능을 수행하는 모든 서버 및 시스템 구성 요소(예: 방화벽, IDS/IPS(침입 탐지 시스템/침입 방지 시스템), 인증 서버, 전자 상거래 리디렉션 서버 등)의 로그
• 10.6.2 조직의 연간 위험 평가에서 결정한 대로 조직의 정책 및 위험 관리 전략에 따라 다른 모든 시스템 구성 요소의 로그를 정기적으로 검토합니다.
• 10.6.3 검토 프로세스 중에 확인된 예외와 비정상 부분에 대해 후속 조치를 수행합니다.

사용자의 책임

Azure 모니터링 서비스인 Azure Monitor 및 클라우드용 Microsoft Defender는 비정상 활동을 검색할 때 알림 또는 경고를 생성할 수 있습니다. 이러한 경고에는 심각도, 상태 및 활동 시간과 같은 컨텍스트 정보가 포함됩니다.

경고가 생성되면 수정 전략을 갖추고 진행 상황을 검토합니다. 한 가지 방법은 클라우드용 Microsoft Defender에서 보안 점수를 추적하고 기록 결과와 비교하는 것입니다.

Microsoft Sentinel과 같은 SIEM 솔루션을 사용하여 데이터를 단일 보기로 중앙 집중화합니다. 데이터를 통합하면 풍부한 경고 컨텍스트를 제공할 수 있습니다.

또는 스토리지의 전체 로그를 수동으로 확인합니다. 예를 들어 Azure Monitor 로그에서 활동 유형, 활동 콘텐츠 또는 활동 호출자를 기반으로 하는 필터링 기능을 사용할 수 있습니다.

경고 및 이벤트를 정기적인 주기로 검토하고 특정 개선 목표가 있는 이니셔티브를 계획하는 조직 정책을 갖춥니다. Log Analytics에서 사용자 지정 저장된 쿼리를 사용하여 의도한 로그 쿼리를 문서화하고 쿼리를 더 쉽게 만듭니다. 이렇게 하면 10.6과 관련하여 팀에서 검토해야 하는 중요한 사항을 알 수 있고 이 프로세스와 관련된 모든 수동 작업이 일관된 워크플로를 따르게 됩니다.

요구 사항 10.7

최소 1년 간의 감사 내역 기록을 유지하고, 최소 3개월은 분석에 즉시 사용할 수 있습니다(예: 온라인, 보관 또는 백업에서 복원 가능).

사용자의 책임

기본적으로, 로그는 무기한 보존되지 않습니다. 쿼리될 수 있는 방식으로 유지되도록 Azure 활동 로그 및 진단 설정을 구성해야 합니다. 리소스에 대한 진단 설정을 사용하도록 설정하는 경우 3개월의 보존 기간을 지정합니다. Azure Monitor 로그는 장기 보관을 지원하므로 감사 또는 오프라인 분석에 사용할 수 있습니다. 한 번 쓰기, 여러 번 읽기 원칙에 맞게 장기 보관 솔루션을 구현합니다.

요구 사항 10.8

10.8.1 서비스 공급자에만 해당하는 추가 요구 사항: 중요한 보안 제어의 실패에 적시에 대응합니다. 보안 제어의 오류에 대처하기 위한 프로세스는 다음을 포함해야 합니다.

• 보안 기능 복원
• 보안 실패 기간(시작에서 종료까지의 날짜와 시간) 식별 및 문서화
• 근본 원인을 포함한 실패 원인 식별 및 문서화와, 근본 원인 해결을 위해 필요한 조치 문서화
• 실패 중 발생한 보안 문제의 식별 및 해결
• 보안 실패의 결과로 추가적인 조치가 필요한지 여부를 판단하기 위한 위험 평가 수행
• 실패 원인의 재발이 방지되도록 제어 구현
• 보안 제어의 모니터링 재개

사용자의 책임

실용적인 경우 중요한 보안 제어가 있음을 나타내는 경고를 갖춥니다. 그렇지 않으면 감사 프로세스에서 예상되는 보안 제어의 부족을 적시에 감지할 수 있도록 합니다. AKS 클러스터에서 실행되는 보안 에이전트 및 Azure 리소스에 대한 액세스 제어(IAM 및 네트워크)와 같은 제어를 고려합니다. AKS 클러스터가 프라이빗 클러스터인지 확인, NSG(네트워크 보안 그룹) 규칙을 통해 네트워크 공개 지점 확인 또는 예기치 않은 공용 IP 확인과 같은 설정을 포함합니다. DNS, 네트워크 라우팅, 방화벽 및 Microsoft Entra ID의 예기치 않은 변경도 포함합니다.

요구 사항 10.9

네트워크 리소스 및 카드 소유자 데이터에 대한 모든 액세스를 모니터링하기 위한 보안 정책 및 운영 절차를 문서화하고, 사용 중이며 영향을 받는 모든 당사자에게 알려야 합니다.

사용자의 책임

프로세스 및 정책에 대한 완전한 설명서를 유지 관리하는 것이 중요합니다. 적용된 정책에 대한 설명서를 유지 관리합니다. 모니터링 작업의 일환으로 사용자는 감사 로그를 사용하도록 설정하고 확인하고 일반적인 위험을 식별하고 수정하는 교육을 받아야 합니다. 정책 관점에서 승인 프로세스에 참여하는 사용자에게 중요합니다.

요구 사항 11.1

무선 액세스 지점(802.11)의 존재 여부를 테스트하는 프로세스를 구현하고, 권한이 있거나 없는 모든 무선 액세스 지점을 분기별로 검색하고 식별합니다.

외부 네트워크는 이 설명서의 범위를 벗어나며, 별도로 평가해야 합니다.

사용자의 책임

이 아키텍처와 구현은 무선 연결을 통해 온-프레미스 또는 회사 네트워크에서 클라우드로의 트랜잭션을 지원하도록 설계되지 않았습니다. 고려 사항은 공식 PCI-DSS 3.2.1 표준 지침을 참조하세요.

요구 사항 11.2

최소한 분기마다 그리고 다음과 같은 중요한 네트워크 변경 이후에 내부 및 외부 네트워크 취약성 검사를 실행합니다.

• 새 시스템 구성 요소 설치
• 네트워크 토폴로지의 변화
• 방화벽 규칙 수정
• 제품 업그레이드

자세한 내용은 PCI(지불 카드 업계) 데이터 보안 표준 승인된 검사 공급업체를 참조하세요.

사용자의 책임

AKS 클러스터, 네트워크 구성, 컨테이너 레지스트리 및 아키텍처의 다른 구성 요소에 대한 변경 내용을 확인하는 프로세스를 갖춥니다.

네트워크에 변경 내용이 있는 경우 프로세스에서 검사가 필요한지 평가해야 합니다. 예를 들어 클러스터가 이제 공용 인터넷에 공개되나요? 새 방화벽 규칙이 지나치게 허용되고 있나요? 클러스터 내에서 Pod 간의 흐름에 보안 격차가 있나요?

인프라와 관련하여 중요한 변경 내용에 대한 명확하고 합의된 정의를 갖춥니다. 몇 가지 예는 다음과 같습니다.

• NSG 또는 Azure Firewall 규칙 구성
• 가상 네트워크 피어링
• DNS 설정
• Azure Private Link 구성
• 기타 네트워크 구성 요소

적용 대상: 11.2.1

분기별 취약성 검사는 Azure 네트워킹 및 Kubernetes 네트워킹 개념을 깊이 이해하는 숙련된 직원이 실행해야 합니다. 심각도 수준을 사용하여 결과를 요구 사항 6.1에 매핑하고 우선 순위가 높은 항목을 확인합니다. 중요한 변경 내용이 있는 경우 예약된 분기별 검사 전에 검사를 실행합니다. 이렇게 하면 새로운 취약성을 검색하여 사전에 문제를 해결할 수 있습니다.

이 검사는 클러스터 내(Pod 간) 네트워크도 포함해야 합니다.

적용 대상: 11.2.2

Azure 네트워킹 및 Kubernetes에 대한 광범위한 경험이 있는 ASV(승인된 검사 공급업체)를 선택합니다. 이렇게 하면 제안된 수정의 깊이와 특이성이 제공됩니다.

요구 사항 11.3

다음을 포함하는 침투 테스트 방법론을 구현합니다.

• 업계에서 인정하는 침투 테스트 방법(예: NIST SP800-115)을 기반으로 합니다.
• 전체 CDE 경계 및 중요 시스템에 대한 적용 범위를 포함합니다.
• 네트워크 내부 및 외부 테스트를 모두 포함합니다.
• 모든 조각화 및 범위 감소 제어에 대한 유효성을 검사하는 테스트를 포함합니다.
• 적어도 요구 사항 6.5에 나열된 취약성을 포함하도록 애플리케이션 계층 침투 테스트를 정의합니다.
• 운영 체제 및 네트워크 기능을 지원하는 구성 요소를 포함하도록 네트워크 레이어 침투 테스트를 정의합니다.
• 지난 12개월 동안 경험한 위협 및 취약성에 대한 검토 및 고려 사항을 포함합니다.
• 침투 테스트 결과 및 수정 작업 결과를 보존하도록 지정합니다.

사용자의 책임

정보를 수집하고, 취약성을 분석하고, 보고하여 보안 격차를 찾는 침투 테스트를 수행합니다. 일반적인 시나리오와 기준을 설정하는 데 필요한 작업을 처리하려면 PTES(침투 테스트 실행 표준)에서 제공하는 업계 지침을 따르는 것이 좋습니다.

침투 테스트 실무자는 연간 구분 테스트가 광범위하게 적용되도록 온-프레미스 및 Azure 네트워킹에 대해 깊이 이해해야 합니다. 테스트 방법론을 클러스터 내 네트워크로 확장합니다. 이 사람은 Kubernetes 네트워킹 개념에 대한 풍부한 경험이 필요합니다.

테스트는 CDE에서 실행되는 애플리케이션과 데이터 계층을 포함해야 합니다.

침투 테스트 연습에서 실무자는 전체 조직의 중요한 데이터에 액세스해야 할 수 있습니다. 액세스 및 의도가 오용되지 않도록 참여 규칙을 따릅니다. 시뮬레이션된 공격을 계획하고 실행하는 방법에 관한 참고 자료는 침투 테스트 참여 규칙을 참조하세요.

요구 사항 11.4

침입 탐지 및/또는 침입 방지 기술을 사용하여 네트워크에 대한 침입을 탐지 및/또는 방지합니다. 카드 소유자 데이터 환경의 주변 지점 및 중요 지점의 모든 트래픽을 모니터링합니다. 의심되는 손상에 대해 담당자에게 경고합니다.

사용자의 책임

WAF(웹 애플리케이션 방화벽)를 사용하여 인바운드 트래픽을 검사하여 AKS 클러스터를 보호합니다. 이 아키텍처에서는 통합 WAF를 사용하는 Azure Application Gateway에서 침입을 방지합니다. 방지 모드를 사용하여 탐지된 침입 및 공격을 능동적으로 차단합니다. 검색 모드만 사용하면 안 됩니다. 자세한 내용은 AKS(Azure Kubernetes Service)의 네트워크 연결 및 보안에 대한 모범 사례를 참조하세요.

다른 옵션은 Azure Firewall 프리미엄에서 침입 탐지 및/또는 침입 방지 기능을 사용하는 것입니다. 자세한 내용은 IDPS를 참조하세요.

또 다른 옵션은 Azure Monitor Network Insights를 사용하도록 설정하는 것입니다. 그러면 연결 모니터, NSG(네트워크 보안 그룹)에 대한 흐름 로깅 및 트래픽 분석과 같은 네트워크 모니터링 기능에 대한 액세스가 제공됩니다.

CDE의 다양한 구성 요소에 적용되는 Microsoft Defender 계획을 사용하도록 설정합니다. 예를 들어 Azure SQL을 사용하여 CHD를 저장하는 경우 Microsoft Defender for SQL은 데이터 계층 침입이 탐지되는지 확인합니다.

또한 NSG 흐름 로그를 중앙 집중식 SIEM 솔루션(예: Microsoft Sentinel)에 연결하여 트래픽 패턴의 변칙을 검색합니다. 이 참조 구현에서 로그는 감사 로그에 대한 변경 내용 추적을 최소화하는 추가 전용 모드입니다. 그러나 장기 스토리지를 위해 외부 싱크로 보내는 모든 로그는 수정하면 안 됩니다. 한 번 쓰기/여러 번 읽기 방법을 따라야 합니다. FIM(파일 무결성 모니터링) 솔루션에서 이러한 외부 엔터티를 포함하여 변경 내용을 검색하도록 합니다.

요구 사항 11.5

중요한 시스템 파일, 구성 파일 또는 콘텐츠 파일의 무단 수정을 담당자에게 경고하도록 변경 내용 추적 솔루션(예: 파일 무결성 모니터링 솔루션)을 배포합니다. 적어도 매주 중요한 파일 비교를 수행하도록 제품을 구성합니다.

사용자의 책임

클러스터에서 Kubernetes 인식 보안 에이전트와 함께 FIM(파일 무결성 모니터링) 솔루션을 실행하여 노드 수준 변경이 발생할 수 있는 파일 및 시스템 수준 액세스를 검색합니다. FIM 솔루션을 선택하는 경우 해당 기능과 검색 깊이를 명확히 이해합니다. 평판이 좋은 공급업체에서 개발한 소프트웨어를 고려합니다.

FIM 도구의 모든 기본 설정을 확인하여 값에서 적용하려는 시나리오를 검색하는지 확인하고 해당 설정을 적절하게 조정합니다.

로그를 모니터링 또는 SIEM 솔루션에 보내 경고를 생성하는 솔루션을 사용하도록 설정합니다. 로그 스키마 변경 내용을 알고 있어야 합니다. 그렇지 않으면 중요한 경고를 놓칠 수 있습니다.

CDE의 다른 컴퓨팅에는 변경 내용 추적을 사용하도록 설정되어 있어야 합니다.

요구 사항 11.6

보안을 모니터링하고 테스트하기 위한 보안 정책 및 운영 절차를 문서화하고, 사용 중이며 영향을 받는 모든 당사자에게 알려야 합니다.

사용자의 책임

프로세스 및 정책에 대한 완전한 설명서를 유지 관리하는 것이 중요합니다. 적용된 정책에 대한 설명서를 유지 관리합니다. 테스트 작업의 일환으로 검토의 주기와 검토 기준을 포함합니다. 팀은 침투 테스트의 측면을 이해해야 합니다. 검색된 위험을 완화하기 위해 문서화된 수정 계획을 갖춥니다.

정책 관점에서 승인 프로세스에 참여하는 사용자에게 중요합니다.

다음 단계

모든 직원에 대한 정보 보안을 처리하는 정책을 유지 관리합니다.