데이터 보호는 전체 데이터 수명 주기 동안 무단 액세스, 반출 및 오용으로부터 중요한 정보를 보호합니다. 검색 및 분류를 구현하여 데이터 인벤토리를 설정하고, 전송 중 및 미사용 데이터를 보호하기 위한 암호화, 암호화 무결성을 유지하기 위해 키 및 인증서 관리를 관리합니다. 이 계층화된 접근 방식은 제로 트러스트 원칙 및 심층 방어 전략에 부합합니다.
포괄적인 데이터 보호가 없으면 조직은 중요한 정보의 반출로 인한 데이터 위반, 규제 처벌 및 평판 손상에 직면합니다.
다음은 데이터 보호 보안 도메인의 세 가지 핵심 핵심 요소입니다.
데이터를 알고 분류합니다. 중요한 정보를 검색하고 일관된 레이블을 적용하여 위험 기반 컨트롤을 사용하도록 설정합니다.
관련 컨트롤:
암호화를 사용하여 데이터 보호: 최신 암호화 표준을 사용하여 전송 중 및 미사용 데이터에 대한 포괄적인 암호화를 구현합니다.
관련 컨트롤:
암호화 인프라 관리: 자동화된 회전 및 포괄적인 감사 로깅을 사용하여 암호화 키 및 인증서에 대한 훈련된 수명 주기 관리를 설정합니다.
관련 컨트롤:
DP-1: 중요한 데이터 검색, 분류 및 레이블 지정
Azure Policy:Azure 기본 제공 정책 정의 DP-1을 참조하세요.
보안 원칙
모든 리포지토리에서 데이터를 검색, 분류 및 레이블 지정하여 중요한 데이터의 포괄적인 인벤토리를 설정하고 유지 관리합니다. 이를 통해 위험 기반 액세스 제어, 암호화 정책 및 모니터링을 통해 무단 액세스 및 반출을 방지할 수 있습니다.
완화할 리스크
위협 행위자가 중요한 데이터의 가시성 부족 및 일관되지 않은 처리를 악용하여 고가의 정보를 반출하거나 남용합니다. 중요한 데이터가 검색, 분류 또는 레이블이 지정되지 않은 경우:
- 추적되지 않은 규제 데이터: 관리되지 않는 위치(섀도 IT)에 저장된 PCI, PHI, PII는 필요한 암호화, 보존 또는 모니터링 컨트롤을 무시합니다.
- 초과 권한 액세스: 민감도 및 비즈니스 영향이 식별되지 않으므로 광범위한 사용자/서비스 액세스가 유지됩니다.
- 복제본 확산: 분석, 테스트 또는 내보내기 파이프라인에 대한 데이터 복제는 중요한 콘텐츠를 낮은 신뢰 환경으로 분산합니다.
- 법의학 사각지대: 인시던트 응답자는 부재 중이거나 잘못된 민감도 메타데이터로 인해 폭발 반경의 범위를 빠르게 지정할 수 없습니다.
- 자동화 실패: 거버넌스(DLP, 조건부 액세스, 암호화 워크플로)는 일관된 레이블 지정 없이 트리거되지 않습니다.
기본 분류가 부족하면 거주 시간이 증가하고, 횡적 이동 기회가 확대되며, 규제 및 평판 노출이 높아집니다.
MITRE ATT&CK
- 정찰(TA0043): 스토리지 계정, 스키마 카탈로그 및 분류 메타데이터를 열거하여 고가치 리포지토리를 프로파일링함으로써 피해자 신원/데이터 자산(T1596)을 수집합니다.
- 검색(TA0007): 계정 및 권한 열거(T1087, T1069)를 통해 수평 또는 수직 데이터 액세스를 증가시키는 불필요한 역할 바인딩을 나타냅니다.
- 컬렉션(TA0009): 레이블이 지정되지 않은 Blob 컨테이너 또는 추적 태그가 없는 관리되지 않는 내보내기를 추출하여 클라우드 스토리지(T1530)에서 데이터를 수집하는 것입니다.
- 반출(TA0010): 레이블 지정/정책 게이트가 없는 임시 내보내기 엔드포인트를 통해 웹 서비스(T1567)를 통한 반출.
- 반출(TA0010): 스크립트 기반의 페이지 매김/루프를 사용하여 자동 반출(T1020)을 통해 잘못 분류된 데이터 집합을 은밀히 수집합니다.
DP-1.1: 중요한 데이터 검색, 분류 및 레이블 지정
Microsoft Purview를 사용하여 전체 데이터 자산에서 중요한 정보를 자동으로 검색, 분류 및 레이블 지정하는 포괄적인 데이터 맵을 빌드합니다. Microsoft Purview Information Protection을 구현하여 인프라 수준 암호화를 넘어 보호를 확장하여 이동 시 데이터를 따르는 영구 문서 수준 암호화 및 사용 권한을 적용합니다. 이 기본 기능을 사용하면 데이터 손실 방지, 조건부 액세스 및 암호화 정책과 같은 다운스트림 보안 제어가 위치만 사용하는 것이 아니라 데이터 민감도에 따라 작동할 수 있습니다.
데이터 검색 및 분류:
- Microsoft Purview를 배포하여 Azure, 온-프레미스, Microsoft 365 및 다중 클라우드 환경에서 중요한 데이터를 검색, 분류 및 레이블을 지정합니다.
- Microsoft Purview 데이터 맵을 사용하여 Azure Storage, Azure SQL Database, Azure Synapse Analytics 및 기타 지원되는 서비스를 비롯한 데이터 원본을 자동으로 검색하고 카탈로그화합니다.
- Purview 데이터 맵에서 민감도 레이블 을 사용하도록 설정하여 데이터 콘텐츠 패턴 및 조직 정책에 따라 분류 레이블(예: 기밀, 극비, PII, PHI)을 자동으로 적용합니다.
문서 수준 암호화 및 보호:
- Microsoft Purview Information Protection을 배포하여 민감도 레이블에 따라 문서 및 전자 메일에 영구 암호화 및 사용 권한을 적용합니다. 파일을 자동으로 암호화하고, 워터마크를 적용하고, 전달을 제한하고, 만료 날짜를 설정하고, 데이터가 조직을 떠난 후에도 액세스를 취소하도록 레이블을 구성합니다.
- Azure RMS(Azure Rights Management Service)는 데이터가 저장되거나 공유되는 위치에 관계없이 유지되는 사용 정책(보기 전용, 복사 없음, 인쇄 안 됨)을 사용하여 문서 및 이메일을 암호화하는 기본 보호 기술로 사용하도록 설정합니다.
데이터베이스 분류 및 통합:
- Azure SQL 데이터베이스의 경우 SQL Data Discovery 및 Classification 을 사용하여 신용 카드 번호, 주민 등록 번호 또는 상태 레코드와 같은 중요한 데이터가 포함된 열을 식별, 분류 및 레이블 지정할 수 있습니다.
- 분류 메타데이터를 다운스트림 컨트롤과 통합: Microsoft Purview에서 DLP(데이터 손실 방지) 정책을 구성하고, Entra ID에 조건부 액세스 규칙을 적용하고, 민감도 레이블에 따라 암호화 정책을 적용합니다.
- 데이터 자산이 발전함에 따라 새로 만들거나 수정된 중요한 데이터 자산을 지속적으로 검색하도록 정기적인 검사 일정을 설정합니다.
구현 예제
글로벌 금융 서비스 조직은 Microsoft Purview 데이터 맵을 배포하여 200개 이상의 Azure Storage 계정, 50개의 SQL 데이터베이스 및 Synapse Analytics 작업 영역에서 중요한 데이터를 자동으로 검색하고 분류했습니다.
도전: 조직은 빠르게 성장하는 Azure 데이터 자산에서 중요한 데이터가 어디에 있는지 파악할 수 없습니다. 수동 데이터 분류가 일관되지 않고, 거버넌스 적용이 지연되고, 규정 준수 격차가 생겼습니다. 자동화된 검색이 없으면 규제된 데이터(PHI, PII, PCI)가 관리되지 않는 위치에서 보호되지 않은 상태로 유지되고 데이터 손실 방지 정책이 적절하게 트리거되지 않습니다.
솔루션 접근 방식:
- 데이터 검색을 위한 Microsoft Purview 데이터 맵 배포: Purview 계정을 만들고 데이터 원본(Azure Storage 계정, SQL 데이터베이스, Synapse Analytics 작업 영역)을 등록하고, 관리 ID 인증을 사용하여 원본을 검색하도록 데이터 맵을 구성하고, 검사 ID 읽기 권한(db_datareader 역할)을 카탈로그 스키마에 부여하고 중요한 열을 검색합니다.
- 분류 및 민감도 검색 구성: SSN, 신용카드 번호, 의료 기록 번호, SWIFT 코드를 포함한 중요한 패턴을 검색하도록 검사 규칙을 설정하고, 데이터 분류 정책에 맞는 사용자 정의 분류 규칙을 정의합니다(비즈니스에 민감한 데이터의 경우 "기밀 - 내부", PHI/PCI/PII 데이터의 경우 "극비 - 규제"). 자동 레이블 지정 임계값을 구성하여 단일 자산에서 ≥3개의 PII 패턴이 감지되면 "극비"가 적용되도록 합니다. 데이터 중요도에 따라 검사 일정을 설정하는데, 프로덕션 데이터는 매주, 아카이브는 매월 검사합니다. 새로운 고감도 데이터가 발견되었을 때 보안 팀에 알리도록 경고를 구성합니다.
- 문서 수준 암호화를 위해 Microsoft Purview Information Protection을 배포 합니다. 보호 설정을 사용하여 Purview 규정 준수 포털에서 민감도 레이블 만들기(공용: 암호화 없음, 시각적 표시만 해당; 내부: 워터마크, 전달 제한 없음; 기밀: Azure RMS를 사용하여 암호화하고, 직원에 대해서만 보기/편집을 허용하고, 전달/인쇄를 차단합니다. 기밀 - 규제: Azure RMS로 암호화, 보기 전용 액세스, 복사/인쇄/전달 없음, 90일 만료, 취소 가능한 액세스), 레이블 정책(범위: 재무, 법률, 집행 부서)을 통해 사용자에게 민감도 레이블을 게시하고, 레이블을 자동으로 적용하도록 자동 레이블 지정 정책을 구성합니다(≥10 SSNs → "극비 - 규제", ≥5개의 신용 카드 번호 → "극비 - 규제됨"), SharePoint에 저장된 레이블이 지정된 문서에 대해 Azure RMS 보호를 사용하도록 설정 OneDrive 및 Azure Storage 계정은 저장/보내기 전에 사용자에게 문서를 분류하라는 메시지를 표시하도록 Office 애플리케이션에 대한 클라이언트 쪽 레이블 지정을 구성합니다.
결과: Purview 데이터 맵 자동 검색은 첫 주 내에 규제된 데이터를 포함하는 15,000개 이상의 데이터 자산을 식별하여 검색 시간을 월에서 일로 줄입니다. Information Protection 자동 레이블 지정은 72시간 이내에 8,500개의 문서에 암호화를 적용했습니다. 민감도 레이블은 데이터가 관리되지 않는 디바이스로 이동하는 경우에도 연속 데이터 자산 가시성 및 영구 보호를 사용하도록 설정했습니다.
중요도 수준
있어야 합니다.
컨트롤 매핑
- CIS 컨트롤 v8.1: 3.2, 3.7, 3.13
- NIST SP 800-53 Rev.5: RA-2, SC-28
- PCI-DSS v4: 3.2.1, 12.3.1
- NIST CSF v2.0: 홍보. DS-1, PR. DS-5
- ISO 27001:2022: A.8.11
- SOC 2: CC6.1
DP-2: 중요한 데이터를 대상으로 하는 변칙 및 위협 모니터링
Azure Policy:Azure 기본 제공 정책 정의 DP-2를 참조하세요.
보안 원칙
중요한 데이터 액세스를 모니터링하고 무단 반출, 내부자 위협 또는 손상된 계정을 나타내는 변칙에 대한 전송 활동을 모니터링합니다. 동작 기준 및 데이터 민감도 컨텍스트를 사용하여 큰 전송, 비정상적인 액세스 시간 또는 예기치 않은 데이터 이동과 같은 비정상적인 패턴을 검색합니다.
완화할 리스크
적과 악의적인 내부자는 은밀하거나 감지하기 어려운 행동을 사용하여 민감한 데이터를 탈취, 저장, 또는 탐색하려고 시도합니다. 데이터 민감도와 연결된 연속적인 컨텍스트 인식 변칙 모니터링이 없는 경우:
- 은밀한 데이터 반출: 대량 내보내기, 큰 결과 집합, 또는 점진적 유출은 기준선 부족으로 인해 탐지되지 않습니다.
- 내부자 오용: 합법적인 자격 증명은 거친 모니터링을 우회하는 비정상적인 시퀀스(하루 중 시간, 볼륨, 지역성)를 수행합니다.
- 스테이징 및 열거형: 공격자는 대량 추출 전에 스키마/레이블을 매핑하여 높은 값의 대상의 우선 순위를 지정합니다.
- 레거시 시스템 활용 쿼리: 표준 관리 도구는 일반적인 운영 환경의 소음 속에서 정찰을 은폐합니다.
- 매장 간 회피: 여러 서비스에 분산된 액세스는 단일 저장소 임계값 및 상관 관계를 방지합니다.
부적절한 이상 탐지는 사고 대응 효율성을 침식시키고 거의 무난하게 정찰에서 본격적인 반출로 에스컬레이션을 허용합니다.
MITRE ATT&CK
- 컬렉션(TA0009): 중요한 컨테이너에서 비정상적인 대량 또는 광범위한 팬아웃 읽기를 통한 클라우드 스토리지(T1530)의 데이터입니다.
- 자격 증명 액세스(TA0006): 유효한 계정(T1078)은 손상된 자격 증명이나 내부자 자격 증명을 악용하여 합법적인 트래픽 기준에 은밀히 섞이려 합니다.
- 반출(TA0010): 경고 임계값을 방지하기 위해 설계된 스크립팅된 제한된 쿼리를 사용하는 자동화된 반출(T1020)입니다.
- 반출(TA0010): 클라우드 스토리지(T1567.002)로의 데이터 반출 및 공격자가 제어하는 지역이나 계정에 데이터를 배치하여 나중에 검색하는 방법.
- 명령 및 제어/반출(TA0011/TA0010): 일반 DB/API 호출을 통해 중요한 행을 터널링하는 애플리케이션 계층 프로토콜(T1071)입니다.
- 검색(TA0007): 시스템/서비스 검색(T1082, T1046) 엔드포인트를 열거하여 고가의 저장소에 대한 횡적 이동 경로를 차트로 지정합니다.
DP-2.1: 데이터 서비스에 대한 위협 탐지 사용
Microsoft Defender 서비스를 배포하여 데이터 스토리지 및 데이터베이스 플랫폼에서 실시간 위협 감지 및 변칙 모니터링을 제공합니다. 이러한 서비스는 동작 분석 및 위협 인텔리전스를 사용하여 SQL 삽입 시도, 비정상적인 쿼리 패턴, 비정상적인 데이터 액세스 볼륨 및 기존 액세스 제어에서 감지할 수 없는 잠재적 반출 지표와 같은 의심스러운 활동을 식별합니다.
데이터 서비스에 대한 위협 탐지를 사용하도록 설정합니다.
- 맬웨어 검색 및 중요한 데이터 위협 검색을 사용하여 Microsoft Defender for Storage 를 사용하도록 설정하여 Azure Storage 계정에서 비정상적인 액세스 패턴, 비정상적인 업로드/다운로드 볼륨 및 잠재적인 데이터 반출 시도를 모니터링합니다.
- SQL용 Microsoft Defender를 사용하도록 설정하여 SQL 삽입 시도, 비정상적인 쿼리 패턴, 비정상적인 데이터 내보내기 작업 및 익숙하지 않은 위치에서의 액세스 등 의심스러운 데이터베이스 활동을 검색할 수 있습니다.
- Azure Cosmos DB용 Microsoft Defender를 사용하도록 설정하여 비정상적인 데이터베이스 액세스 패턴, 잠재적인 데이터 반출 및 의심스러운 운영 활동을 검색합니다.
- 오픈 소스 데이터베이스(PostgreSQL, MySQL, MariaDB)의 경우 오픈 소스 관계형 데이터베이스에 대해 Microsoft Defender 를 사용하도록 설정하여 무차별 암호 대입 공격, 의심스러운 액세스 패턴 및 비정상적인 관리 작업을 검색할 수 있습니다.
DP-2.2: 데이터 반출 모니터링 및 방지
사전 데이터 손실 방지 컨트롤 및 동작 모니터링을 구현하여 성공하기 전에 무단 데이터 전송을 감지하고 차단합니다. 정책 기반 DLP를 내부자 위험 관리, SIEM 상관 관계 및 자동화된 대응과 결합하여 여러 채널에서 반출 시도를 중지하는 심층 방어 방법을 만드는 동시에 인시던트 조사를 위한 법의학적 증거를 제공합니다.
DLP 및 내부자 위험 제어 배포:
- Microsoft Purview DLP(데이터 손실 방지) 정책을 사용하여 Azure 서비스, Microsoft 365 및 엔드포인트에서 분류된 데이터의 무단 전송을 모니터링하고 차단하여 중요한 데이터 반출을 방지합니다.
- Microsoft Purview Insider Risk Management를 배포하여 기계 학습 및 행동 분석을 사용하여 위험한 사용자 동작을 검색합니다. 비정상적인 데이터 다운로드, USB/개인 클라우드 스토리지에 파일 복사, 정상 근무 시간 외의 중요한 리소스 액세스 또는 사직 날짜 전에 데이터 액세스 급증을 포함한 지표를 모니터링합니다. 내부 위험 관리는 Microsoft 365, Azure, HR 시스템 및 보안 도구의 신호를 상호 연결하여 잠재적인 데이터 도난 또는 정책 위반을 식별합니다.
모니터링 및 응답 구성:
- 데이터 서비스에 대한 진단 로그를 구성하고 Azure Monitor 또는 Microsoft Sentinel로 라우팅하여 동작 기준을 설정하고 일반적인 액세스 패턴에서 편차를 검색합니다.
- 데이터 서비스 로그를 Microsoft Sentinel 과 통합하여 대량 다운로드, 근무 시간 외부 액세스 또는 의심스러운 쿼리 동작과 같은 비정상적인 데이터 액세스 패턴을 검색하기 위한 분석 규칙을 만듭니다.
- Azure Logic Apps 또는 Microsoft Sentinel 플레이북을 사용하여 자동화된 인시던트 대응 워크플로를 구현하여 손상된 ID를 격리하고, 액세스를 해지하고, 데이터 반출 시도가 감지되면 보안 팀에 알립니다.
메모: 호스트 기반 DLP 요구 사항의 경우 Azure Marketplace에서 Microsoft Purview 엔드포인트 DLP 기능 또는 타사 솔루션을 배포하여 엔드포인트 수준 데이터 보호 제어를 적용합니다.
구현 예제
의료 공급자는 Microsoft Defender for Storage 및 Defender for SQL을 사용하여 Azure Storage 계정 및 SQL 데이터베이스에서 환자 데이터를 대상으로 하는 변칙 및 위협을 모니터링할 수 있도록 했습니다.
도전: 조직은 무단 데이터 액세스 및 반출 시도를 감지하는 데 사각지대를 경험했습니다. 기존의 경계 방어는 내부자 위협 및 대량 다운로드를 수행하는 손상된 서비스 주체를 놓쳤습니다. 동작 분석 및 변칙 검색이 없으면 의심스러운 액세스 패턴이 장기간 눈에 띄지 않게 되어 위반 위험 및 유지 시간이 증가했습니다.
솔루션 접근 방식:
- 스토리지용 Microsoft Defender를 사용하도록 설정합니다. 중요한 데이터가 포함된 스토리지 계정에 대해 구독 수준에서 Defender for Storage를 사용하도록 설정하고, Blob Storage에서 악성 파일을 검색 및 격리하도록 맬웨어 검사를 구성하고, Purview 중요한 정보 유형을 사용하여 중요한 데이터 위협 탐지를 사용하도록 설정하여 PHI/PII 패턴을 식별하고, 트랜잭션별 검사 한도 또는 월별 한도를 설정하여 비용을 제어하고, 의료 이미징 및 EHR 내보내기를 호스팅하는 프로덕션 스토리지 계정을 포함하는 리소스 그룹에 보호를 적용합니다.
- SQL용 Microsoft Defender를 사용하도록 설정합니다. Azure SQL Database 및 SQL Managed Instance에 대한 구독 수준에서 Defender for SQL을 사용하도록 설정하고, 반복 검사를 사용하여 취약성 평가를 구성하고, 검사 결과에 대한 스토리지 계정을 지정하고, 식별된 취약성의 보안 팀에 경고하도록 이메일 알림을 설정하고, Advanced Threat Protection을 사용하여 SQL 삽입 시도, 비정상적인 쿼리 패턴, 익숙하지 않은 지역의 비정상적인 액세스를 검색할 수 있습니다. 및 잠재적인 데이터 반출
- Microsoft Sentinel과 통합: 데이터 커넥터를 사용하여 Microsoft Defender for Microsoft Sentinel에 연결, 진단 설정 구성(스토리지 작업 및 SQL 감사 로그에 대한 진단 로그 사용, Log Analytics 작업 영역으로 라우팅), 변칙을 검색하는 Sentinel Analytics 규칙을 만듭니다(1시간 이내에 다운로드 >에 대한 대량 다운로드 경고 10GB, 근무 시간 외 데이터베이스 액세스, 의심스러운 쿼리 패턴), 손상된 ID를 격리하도록 자동화된 응답 플레이북 구성, 스토리지 액세스를 취소하고 보안 팀에 알립니다.
- 행동 위협 탐지를 위한 Microsoft Purview 내부 위험 관리 배포: 내부 위험 관리를 사용하도록 설정하고 정책 템플릿을 구성합니다(퇴사 예정 사용자가 30~90일 전에 비정상적인 파일 다운로드를 탐지하는 것, USB/클라우드 저장소 복사를 모니터링하는 일반 데이터 누출, 높은 권한 역할에 대한 향상된 모니터링이 있는 우선 순위 사용자의 데이터 유출), 위험 지표 및 임계값을 구성합니다(누적 파일 다운로드 볼륨 경고, 근무 시간 외 접근 급증, 여러 위험 신호를 결합하는 시퀀스 탐지), 데이터 소스를 통합합니다(Azure 활동 로그, Microsoft 365 감사 로그, Defender for Cloud Apps, HR 시스템, 엔드포인트 DLP 이벤트), 경고 심사 워크플로를 구성하여 중간/높은 심각도의 경고를 전용 조사 큐로 라우팅합니다.
결과: Defender for Storage는 48시간 이내에 손상된 서비스 주체에서 비정상적인 대량 다운로드 작업을 검색했습니다. 자동화된 응답은 ID를 격리하고 몇 분 내에 SOC에 통보하여 검색 시간을 일에서 15분 미만으로 줄입니다. 내부 위험 관리는 개인 기준보다 훨씬 높은 연구 데이터를 개인 클라우드 스토리지에 다운로드하는 직원을 플래그로 지정하여 신속한 개입을 가능하게 했습니다.
중요도 수준
있어야 합니다.
컨트롤 매핑
- CIS 컨트롤 v8.1: 3.13
- NIST SP 800-53 Rev.5: AC-4, SI-4
- PCI-DSS v4: 3.2.1, 10.4.1
- NIST CSF v2.0: DE.CM-1, PR.DS-5
- ISO 27001:2022: A.8.11, A.8.16
- SOC 2: CC6.1, CC7.2
DP-3: 전송 중인 중요한 데이터 암호화
Azure Policy:Azure 기본 제공 정책 정의 DP-3을 참조하세요.
보안 원칙
강력한 암호화(예: TLS 1.2 이상)를 사용하여 전송 중인 데이터를 보호하여 가로채기, 변조 및 무단 액세스를 방지합니다. 데이터 민감도에 따라 내부 네트워크 보호를 고려하면서 외부 및 공용 네트워크 트래픽의 우선 순위를 지정하여 암호화가 필수인 네트워크 경계 및 서비스 범위를 정의합니다.
완화할 리스크
암호화되지 않거나 약하게 보호되는 네트워크 채널은 중요한 데이터를 가로채기, 조작 및 다운그레이드 남용에 노출합니다. 적용된 최신 전송 암호화가 없습니다(TLS 1.2 이상):
- 수동 가로채기: 네트워크 관찰자는 자격 증명, 토큰, API 페이로드 또는 규제된 데이터를 일반 텍스트로 캡처합니다.
- 맨인 더 미들: 공격자는 쿼리를 변경하거나 페이로드를 삽입하거나 세션 자료를 수집합니다.
- 프로토콜 다운그레이드: 레거시 대체(SSL/TLS < 1.2, 일반 텍스트 HTTP/FTP)를 사용하면 사용되지 않는 암호 그룹을 악용할 수 있습니다.
- 세션 하이재킹: 채널 무결성이 부족하여 횡적 이동을 위한 토큰 재생 또는 쿠키 도난이 허용됩니다.
- 무결성 조작: 변조하면 분석이 손상되거나 사기성 트랜잭션이 트리거됩니다.
- 보이지 않는 횡적 경로: 내부 평문 트래픽은 진입 이후 정찰 자료가 됩니다.
전송 중에 강력한 암호화를 적용하지 않으면 위반 폭발 반경이 증폭되고 자격 증명 손상이 가속화되며 제로 트러스트 가정이 훼손됩니다.
MITRE ATT&CK
- TA0006(자격 증명 액세스) : 토큰/세션 자료를 노출하는 일반 텍스트 또는 다운그레이드된 TLS 세션 중에 보호되지 않는 자격 증명(T1552)이 가로채집니다.
- 컬렉션(TA0009): 네트워크 스니핑(T1040)을 통해 취약한 암호화 또는 일반 텍스트 경로를 통과하는 API 페이로드와 비밀을 수집.
- 반출(TA0010): 합법적인 API 엔드포인트를 통해 구조화된 데이터를 스트리밍하는 웹 서비스(T1567)를 통한 반출입니다.
- 방어 회피(TA0005): TLS 다운그레이드를 강제로 유도하거나, 트래픽을 보기/수정하기 위해 가로채기 프록시를 삽입하는 중간자 공격(T1557)입니다.
- 명령 및 제어(TA0011): 모니터링을 우회하기 위해 비 애플리케이션 계층 프로토콜(T1095)을 레거시 또는 덜 검사된 전송으로 되돌려줍니다.
DP-3.1: 데이터 서비스 및 애플리케이션에 TLS 암호화 적용
모든 고객 연결 서비스 및 데이터 플랫폼에서 최신 전송 계층 보안 표준을 설정하여 가로채기, 변조 및 중간 공격으로부터 보호합니다. 스토리지, 웹 애플리케이션, 데이터베이스 및 API 게이트웨이에서 최소 TLS 1.2 또는 1.3을 적용하면서 암호화 다운그레이드 공격에 데이터를 노출하는 레거시 프로토콜 및 약한 암호 그룹을 사용하지 않도록 설정합니다.
데이터 서비스 및 애플리케이션에 TLS 적용:
- 모든 클라이언트 연결이 Blob, 파일, 큐 및 테이블 작업에 TLS 1.2 이상을 사용하도록 Azure Storage 계정에 대한 보안 전송(HTTPS만 해당) 을 적용합니다.
- Azure App Service에서 호스트되는 웹 애플리케이션의 경우 "HTTPS만" 설정을 사용하도록 설정하고 최소 TLS 버전을 1.2 또는 1.3 으로 구성하여 다운그레이드 공격을 방지하고 최신 암호화 표준을 보장합니다.
- 프런트 엔드 수신기 및 백 엔드 연결 암호화(엔드투엔드 TLS)에 대해 TLS 1.2/1.3 최소 버전을 적용하도록 Azure Application Gateway 를 구성합니다.
- Azure SQL Database 및 기타 PaaS 데이터 서비스의 경우 "보안 연결 필요" 또는 이와 동등한 설정이 암호화된 연결을 적용하는지 확인합니다. 일반 텍스트 연결을 거부합니다.
- API Management, Azure Front Door 및 기타 게이트웨이 서비스의 경우 TLS 1.2 이상을 적용하고 약한 암호 그룹을 사용하지 않도록 최소 TLS 버전 정책을 구성합니다.
메모: Azure는 MACsec(계층 2)과 TLS(계층 7)를 사용하여 Azure 데이터 센터 간의 모든 트래픽을 자동으로 암호화합니다. 대부분의 Azure PaaS 서비스는 기본적으로 TLS 1.2+를 사용하도록 설정하지만 고객이 구성할 수 있는 정책(스토리지, App Service, Application Gateway, API Management, Front Door)을 사용하여 서비스에 대한 최소 TLS 버전 설정을 확인합니다.
DP-3.2: 보안 원격 액세스 및 파일 전송 프로토콜
운영 작업 중에 자격 증명 및 중요한 데이터를 노출하는 일반 텍스트 관리 액세스 및 레거시 파일 전송 프로토콜을 제거합니다. 안전하지 않은 프로토콜(FTP, 암호화되지 않은 RDP/SSH)을 최신 암호화된 대안으로 바꾸고 중앙 집중식 요새를 통해 권한 있는 액세스를 라우팅하여 관리 인터페이스의 직접 인터넷 노출을 제거합니다.
보안 원격 관리 프로토콜:
- Azure 가상 머신의 원격 관리를 위해 보안 프로토콜만 사용합니다.
- Linux VM: 키 기반 인증과 함께 SSH(포트 22)를 사용합니다. 암호 인증을 사용하지 않도록 설정합니다.
- Windows VM: NLA(네트워크 수준 인증)를 사용하도록 설정된 상태에서 TLS(포트 3389)를 통해 RDP를 사용합니다.
- 권한 있는 액세스:Azure Bastion 을 통해 관리 연결을 라우팅하여 공용 IP 노출을 제거하고 TLS를 통해 브라우저 기반 또는 네이티브 클라이언트 액세스를 제공합니다.
보안 파일 전송 프로토콜:
- 파일 전송 작업의 경우 보안 프로토콜을 사용하고 레거시 대안을 사용하지 않도록 설정합니다.
- Azure Blob Storage에서 SFTP 지원을 사용합니다(계층 구조 네임스페이스 필요).
- Azure App Service 및 Azure Functions에서 FTPS를 사용합니다.
- 레거시 FTP 프로토콜(일반 텍스트)을 사용하지 않도록 설정합니다.
- Azure Policy를 사용하여 환경 전체에서 보안 전송 정책을 적용하고 TLS 버전 요구 사항에 대한 규정 준수를 모니터링합니다.
구현 예제
전자 상거래 플랫폼은 PCI-DSS 4.0 요구 사항을 충족하기 위해 모든 고객 관련 서비스에 TLS 1.3 최소 버전을 적용했습니다.
도전: 레거시 TLS 1.0/1.1 프로토콜 및 약한 암호 그룹은 고객 지불 데이터를 가로채기 공격에 노출시켰습니다. 애플리케이션 계층 간 TLS 적용이 일관되지 않아 공격자가 연결을 다운그레이드할 수 있는 보안 격차가 발생했습니다. 중앙 집중식 TLS 정책 적용이 없으면 수동 구성 드리프트를 통해 안전하지 않은 프로토콜이 프로덕션 환경에서 지속될 수 있습니다.
솔루션 접근 방식:
- TLS 1.3용 Azure App Service 구성: 고객 연결 웹 애플리케이션 및 API의 경우 최소 TLS 버전을 1.3으로 설정하고, HTTPS 전용 모드를 사용하여 모든 HTTP 트래픽을 HTTPS로 자동으로 리디렉션하고, 관리되는 인증서 또는 사용자 지정 인증서가 강력한 암호 그룹을 사용하는지 확인합니다.
- 엔드투엔드 TLS에 대한 Azure Application Gateway 구성: SSL 정책 AppGwSslPolicy20220101(CustomV2 정책을 사용하는 TLS 1.3 최소)을 사용하여 프런트 엔드 HTTPS 수신기 구성, TLS 인증서 업로드 또는 인증서 관리를 위한 Key Vault와 통합 HTTPS 연결에 대한 백 엔드 설정 구성(포트 443에서 HTTPS로 백 엔드 프로토콜 설정, 백 엔드 App Services가 Azure 관리 인증서를 사용하는 경우 "잘 알려진 CA 인증서 사용" 사용, 백 엔드 연결의 경우 최소 TLS 버전을 1.2로 설정) TLS 사용 설정을 사용하여 HTTPS 수신기를 백 엔드 풀에 연결하는 라우팅 규칙을 만듭니다.
- Azure Storage에 보안 전송 적용: Blob, 파일, 큐 및 테이블 작업에 대해 HTTPS 전용을 적용하려면 "보안 전송 필요" 설정을 사용하도록 설정하고, 모든 스토리지 연결에 대해 최소 TLS 버전을 1.2로 설정하고, 모든 SAS 토큰 및 공유 키가 HTTPS 연결을 통해서만 작동하는지 확인합니다.
- 보안 원격 액세스를 위해 Azure Bastion을 구성 합니다. 허브 VNet에 Azure Bastion을 배포하여 TLS 1.2를 통해 브라우저 기반 RDP/SSH 액세스를 제공하고, VM에서 공용 IP를 제거하고, Bastion을 통해서만 모든 관리 액세스를 라우팅합니다.
결과: Azure Storage 계정은 서비스 경계에서 HTTP 연결을 거부하고, Application Gateway는 TLS 1.2 백 엔드 암호화를 사용하는 프런트 엔드 연결에 TLS 1.3을 적용하고, Azure Bastion은 VM 관리에 대한 공용 IP 노출을 제거합니다.
중요도 수준
있어야 합니다.
컨트롤 매핑
- CIS 컨트롤 v8.1: 3.10
- NIST SP 800-53 Rev.5: SC-8
- PCI-DSS v4: 4.2.1, 4.2.2
- NIST CSF v2.0: 홍보. DS-2
- ISO 27001:2022: A.8.24
- SOC 2: CC6.1, CC6.7
DP-4: 기본적으로 미사용 데이터 암호화 사용하도록 설정
Azure Policy:Azure 기본 제공 정책 정의 DP-4를 참조하세요.
보안 원칙
기본적으로 저장 시 암호화를 사용하도록 설정하여 기본 스토리지, 물리적 미디어 도난, 스냅샷 노출 또는 손상된 인프라 액세스를 통해 무단 액세스로부터 데이터를 보호합니다. 암호화는 스토리지 수준 보안이 무시되는 경우에도 데이터를 보호하도록 하여 액세스 제어를 보완합니다.
완화할 리스크
암호화되지 않거나 선택적으로 암호화된 스토리지 계층을 사용하면 대역 외 액세스(인프라 손상, 도난된 미디어, 스냅샷 남용)를 가진 공격자가 중요한 데이터를 대규모로 수집할 수 있습니다. 기본 암호화가 없는 경우:
- 원시 미디어에서 데이터 수집: 도난당한 디스크, 백업 또는 관리되지 않는 스냅샷은 전체 일반 텍스트 데이터 세트를 노출합니다.
- 권한 경계 침식: 플랫폼 관리자 또는 손상된 호스트 에이전트는 암호화 분리가 없는 테넌트 데이터를 읽을 수 있습니다.
- 자동 복사 및 반출: 암호화되지 않은 복제본(테스트, 분석, 내보내기)은 마찰이 적은 반출 채널이 됩니다.
- 무결성 변조: 공격자는 휴면 데이터(악성 DLL, 구성 또는 참조 데이터)를 수정하여 이후 단계에서 손상을 유발합니다.
- 규정 비준수: 시스템 암호화가 부족하여 많은 업계 인증에 필요한 보증이 약화됩니다.
- 키 없는 복구 노출: 재해 복구 이미지 및 콜드 아카이브는 복구 가능한 일반 텍스트로 중요한 콘텐츠를 무기한 보존합니다.
범용 암호화 저장 방식을 적용하지 않으면 보안 위반의 규모가 커지고 포렌식 범위가 복잡해지며, 후속 운영 및 법적 위험이 확대됩니다.
MITRE ATT&CK
- 컬렉션(TA0009): 암호화되지 않은 스냅샷, 복제본 또는 분리된 디스크를 추출하여 클라우드 스토리지(T1530)의 데이터입니다.
- 방어 회피(TA0005): 오프라인 미디어/스냅샷 액세스 후 로그를 편집하거나 제거하는 지표 제거(T1070)
- 영향(TA0040): 암호화되지 않은 휴면 자산을 손상하여 다운스트림 프로세스를 방해하는 데이터 소멸(T1485)
- 영향(TA0040): 시스템 복구(T1490) 암호화되지 않은 백업 및 복구 카탈로그를 삭제하거나 변경하는 것을 금지합니다.
- 영향(TA0040): 저장된 참조 또는 구성 데이터를 미묘하게 수정하여 이후 단계 논리 오류를 발생시키는 데이터 조작(T1565)
DP-4.1: 기본적으로 미사용 데이터 암호화 사용
인프라 손상, 도난당한 미디어 또는 무단 스냅샷으로부터 무단 액세스로부터 보호하기 위해 Azure에 저장된 모든 데이터가 미사용 시 암호화되었는지 확인합니다. 대부분의 Azure 서비스는 기본적으로 암호화를 사용하도록 설정하지만, 가상 머신, 스토리지 계정 및 데이터베이스에서 적용 범위를 확인하고, 매우 중요한 워크로드에 대해 추가 암호화 계층(호스트에서 암호화, 인프라 암호화, 기밀 컴퓨팅 및 열 수준 암호화)을 사용하도록 설정하여 규제 및 데이터 주권 요구 사항을 충족합니다.
VM 및 스토리지에 암호화 사용:
- 데이터가 Azure Storage에 도달하기 전에 Azure Virtual Machines에 대한 호스트에서 암호화 를 사용하도록 설정하여 임시 디스크, OS 디스크 캐시, 데이터 디스크 캐시 및 임시 OS 디스크를 암호화합니다. 구독 수준에서 EncryptionAtHost 기능을 등록하고 지원되는 VM 크기(예: DSv3, Easv4, Dadsv5 시리즈)를 사용하여 VM을 배포합니다.
- 추가 암호화 계층이 필요한 Azure Storage 계정에 대해 인프라 암호화(이중 암호화) 를 사용하도록 설정합니다. 이렇게 하면 서비스 및 인프라 수준에서 서로 다른 키를 사용하여 두 개의 AES-256 암호화 계층을 제공합니다. 스토리지 계정을 만든 후에는 사용하도록 설정할 수 없으므로 스토리지 계정을 만드는 동안 구성됩니다.
기밀 컴퓨팅 및 열 수준 암호화 배포:
- 내보내기 제어 또는 중요한 데이터를 처리하는 높은 규제 워크로드에 대한 기밀 디스크 암호화를 사용하여 Azure 기밀 VM 을 배포합니다. VTPM 바인딩 디스크 암호화 키와 함께 DCasv5/DCadsv5 시리즈(AMD SEV-SNP) 또는 ECasv5/ECadsv5 시리즈(Intel TDX)를 사용하여 처리 중에 데이터가 암호화된 상태로 유지되도록 합니다.
- Azure SQL Database의 경우 데이터베이스 관리자, 클라우드 운영자 및 권한이 높지만 권한이 없는 사용자로부터도 데이터가 암호화된 상태로 유지되는 매우 중요한 데이터(SSN, 신용 카드 번호, 의료 레코드)에 대한 클라이언트 쪽 열 수준 암호화를 제공하도록 Always Encrypted 를 구현합니다. Always Encrypted를 사용하여 보안 Enclave(Intel SGX)와 함께 암호화된 열에서 더 풍부한 쿼리를 사용할 수 있도록 설정합니다.
암호화 준수 모니터링 및 적용:
- 구독 또는 관리 그룹 범위에서 "가상 머신이 호스트에서 암호화를 사용하도록 설정해야 함", "스토리지 계정에 인프라 암호화가 있어야 함" 및 "SQL 데이터베이스의 투명한 데이터 암호화를 사용하도록 설정해야 함"과 같은 기본 제공 정책을 할당하여 Azure Policy 를 사용하여 암호화 규정 준수를 적용합니다.
- Azure Resource Graph를 사용하여 환경 전체에서 암호화 구성을 쿼리하고 인벤토리화하여 호스트에서 암호화가 없는 VM, 인프라 암호화가 없는 스토리지 계정 또는 TDE를 사용하도록 설정하지 않은 데이터베이스를 식별합니다.
메모: 많은 Azure 서비스(Azure Storage, Azure SQL Database, Azure Cosmos DB)는 2년마다 자동으로 회전하는 서비스 관리형 키를 사용하여 인프라 계층에서 기본적으로 미사용 데이터 암호화를 사용하도록 설정되어 있습니다. 암호화가 기본적으로 사용되지 않는 경우 기술 타당성 및 워크로드 요구 사항에 따라 스토리지, 파일 또는 데이터베이스 수준에서 사용하도록 설정합니다.
구현 예제
다국적 제조 회사는 Azure 환경에서 미사용 암호화를 표준화하여 ERP 데이터, 공급망 애플리케이션 및 엔지니어링 영업 비밀을 보호했습니다.
도전: 일관되지 않은 암호화 적용 범위로 인해 중요한 데이터가 인프라 손상 및 스냅샷 도난에 취약해졌습니다. 임시 디스크 데이터 및 임시 스토리지는 암호화되지 않은 상태로 유지되어 규정 준수 격차가 발생했습니다. 체계적인 암호화 적용이 없으면 엔지니어링 영업 비밀 및 공급망 데이터는 도난당한 디스크, 무단 스냅샷 또는 손상된 호스트 에이전트를 통해 노출될 수 있습니다.
솔루션 접근 방식:
- Azure Virtual Machines에 대해 호스트에서 암호화를 사용하도록 설정합니다 . 구독 수준에서 EncryptionAtHost 기능을 등록하고, 지원되는 VM 크기(DSv3, Easv4, Dadsv5 시리즈)를 사용하여 VM에 대한 호스트에서 암호화를 사용하도록 설정하고, 암호화는 임시 디스크, OS 디스크 캐시, 데이터 디스크 캐시 및 임시 OS 디스크를 포함합니다.
- Azure Storage에 대한 인프라 암호화(이중 암호화)를 사용하도록 설정합니다 . Azure Storage 서비스 암호화(SSE)가 사용하도록 설정되어 있는지 확인합니다(기본적으로 AES-256 암호화). 중요한 스토리지 계정은 스토리지 계정을 만드는 동안 인프라 암호화를 사용하도록 설정합니다(만든 후에는 사용할 수 없음), 결과: 서로 다른 키를 사용하는 AES-256 암호화의 두 계층.
- 높은 규제 워크로드를 위해 Azure 기밀 VM을 배포합니다. 적절한 기밀 VM 시리즈(AMD SEV-SNP DCasv5/DCadsv5 시리즈 또는 Intel TDX용 ECasv5/ECadsv5 시리즈)를 선택하고, 플랫폼 관리 키를 사용하여 기밀 디스크 암호화를 사용하도록 설정하고(디스크 암호화 키를 VM의 가상 TPM에 바인딩), 증명을 위해 보안 부팅 및 vTPM을 사용하도록 설정합니다. 내보내기 제어 기술 데이터 또는 고도로 규제된 PII를 처리하는 워크로드를 위해 배포합니다. 여기서 데이터는 처리 중에 암호화된 상태로 유지되어야 합니다.
- 중요한 데이터베이스 열에 대해 Always Encrypted를 구현합니다: Azure SQL Database에서 열 수준 암호화가 필요한 매우 중요한 열(SSN, CreditCardNumber, MedicalRecordNumber)을 식별하고, CEK(열 암호화 키) 및 CMK(열 마스터 키)를 생성하여 CMK를 Azure Key Vault에 저장하고, CEK로 데이터 열을 암호화하고 CMK로 CEK를 암호화합니다. 암호화된 데이터에 대해 보다 풍부한 쿼리를 허용하도록 Always Encrypted(Intel SGX)를 사용하도록 설정하고, 중요한 열을 결정적 암호화(동등성 조회용) 또는 임의 암호화(최대 보안)를 사용하여 암호화합니다. 애플리케이션 연결 문자열을 열 암호화 설정=활성화됨으로 구성하여 투명한 암호화/암호 해독을 구현합니다.
- Azure Resource Graph를 사용한 인벤토리 암호화 구성: 인프라 암호화가 없는 호스트 및 스토리지 계정 암호화가 없는 VM에 대한 암호화 상태를 쿼리하고, 결과를 CSV로 내보내고, 수정 작업을 리소스 소유자에게 할당합니다.
결과: 호스트에서 암호화는 임시 디스크 데이터가 이전에 암호화되지 않은 규정 준수 격차를 해결했습니다. 두 개의 암호화 계층이 있는 인프라 암호화 보호 엔지니어링 파일. 기밀 VM은 클라우드 관리자로부터도 내보내기 제어 데이터가 암호화된 상태로 유지되도록 했습니다. 항상 암호화된 보호된 중요한 데이터베이스 열 - 데이터베이스 관리자가 암호화된 열에서 일반 텍스트를 읽을 수 없음을 확인하여 규정 준수 요구 사항을 충족합니다.
중요도 수준
있어야 합니다.
컨트롤 매핑
- CIS 컨트롤 v8.1: 3.11
- NIST SP 800-53 Rev.5: SC-28
- PCI-DSS v4: 3.5.1, 3.6.1
- NIST CSF v2.0: 보호.DS-1
- ISO 27001:2022: A.8.24
- SOC 2: CC6.1
DP-5: 필요한 경우 미사용 데이터 암호화에서 고객 관리형 키 옵션 사용
Azure Policy:Azure 기본 제공 정책 정의 DP-5를 참조하세요.
보안 원칙
규정 준수, 계약 요구 사항 또는 데이터 민감도가 키 생성, 회전 및 해지 기관을 비롯한 암호화 키 수명 주기를 직접 제어해야 하는 경우 고객 관리형 키를 사용합니다. 운영 오버헤드를 처리하기 위해 적절한 키 관리 프로세스가 마련되어 있는지 확인합니다.
완화할 리스크
규정, 계약 또는 분리 보증이 테넌트 제어를 요구하는 서비스 관리 키에만 의존하면 규정 준수 및 집중 위험이 발생합니다. 올바르게 관리되는 CMK(고객 관리형 키)가 없는 경우:
- 부적절한 규제 보증: 감사자는 키 양육권, 회전 주기 또는 해지 기관을 입증할 수 없는 경우 암호화 제어의 증거를 거부할 수 있습니다.
- 해지 대기 시간: 손상된 플랫폼 키를 신속하게 해지하거나 회전할 수 없는 경우 자격 증명 또는 공급망 이벤트 후 노출 기간이 연장됩니다.
- 관할권 노출: 데이터 주권 의무에는 테넌트 운영 또는 HSM 지원 키가 필요할 수 있습니다. 부재로 인해 지역 배포 실행 가능성이 손상됩니다.
- 테넌트 간 폭발 반경: 다중 테넌트 플랫폼 키 손상은 암호화 격리가 충분하지 않은 경우 광범위한 데이터 세트에 영향을 줄 수 있습니다.
- 그림자 확산: 수명 주기 관리 및 거버넌스가 없는 임시 CMK 배포는 부실, 소외된, 또는 약한 키로 이어질 수 있습니다.
- 운영 취약성: 잘못된 회전 자동화 또는 누락된 종속성 매핑으로 인해 키 롤오버 중에 애플리케이션이 중단됩니다.
부적절하거나 생략된 CMK 사용은 암호화 보증을 약화시키고 중요한 워크로드에 대한 전략적 규정 준수 위치를 약화합니다.
MITRE ATT&CK
- 자격 증명 액세스(TA0006): 약하게 보호되거나 부적절하게 분할된 플랫폼 키로 노출되는 보호되지 않는 자격 증명(T1552)입니다.
- 영향(TA0040): 데이터 접근을 막기 위해 CMK 회전/해지를 악용하여 데이터(T1486)를 암호화합니다.
- 영향(TA0040): 보호 계층을 비동기화하기 위해 암호화 상태 메타데이터를 수정하는 데이터 조작(T1565)
- 반출(TA0010): 데이터를 클라우드 계정(T1537)으로 전송하여 데이터 세트를 다시 암호화하고 공격자가 제어하는 스토리지로 내보냅니다.
- 반출(TA0010): 일반 서비스 패턴에 따라 대용량 키 사용 대량 내보내기 오케스트레이션하는 웹 서비스(T1567)를 통한 반출입니다.
DP-5.1: 필요한 경우 미사용 데이터 암호화에서 고객 관리형 키 옵션 사용
규정 준수, 데이터 주권 의무 또는 계약 의무에 따라 암호화 키 관리, 회전 일정 및 해지 기관을 직접 제어해야 하는 경우 고객 관리형 키를 구현합니다. Microsoft에서도 데이터의 암호를 해독할 수 없는 최종 제어가 필요한 워크로드의 경우 조직이 Azure 외부에서 두 번째 암호화 키를 유지하는 DKE(이중 키 암호화)를 구현합니다. Azure Key Vault 또는 관리형 HSM을 사용하여 키 수명 주기 관리, 재해 복구 계획 및 키 관리 오류로 인한 잠재적인 서비스 가용성 영향의 운영 복잡성을 분산하면서 암호화 제어를 유지합니다.
CMK 요구 사항을 평가하고 키 인프라를 프로비전합니다.
- 규정, 규정 준수 또는 비즈니스 요구 사항을 평가하여 플랫폼 관리형 키 대신 CMK(고객 관리형 키) 가 필요한 워크로드를 결정합니다. 일반적인 동인에는 데이터 주권, 감사 요구 사항 또는 직접 키 양육권에 대한 계약상의 의무가 포함됩니다.
- 고객 관리형 암호화 키를 저장하고 관리하기 위해 Azure Key Vault (표준 또는 프리미엄) 또는 Azure Key Vault 관리형 HSM 을 프로비전합니다. FIPS 140-3 수준 3 유효성이 검사된 하드웨어 보호가 필요한 워크로드에 관리형 HSM을 사용합니다.
- 키 생성 기능을 사용하여 Azure Key Vault 내에서 암호화 키를 생성하거나, 최대 이식성 및 제어를 위해 BYOK(Bring Your Own Key)를 사용하여 온-프레미스 HSM에서 키를 가져옵니다.
CMK를 구성하고 키 계층 구조를 설정합니다.
- 극단적인 제어 요구 사항을 위해 중요한 문서에 암호 해독을 위해 두 개의 키가 필요한 DKE(이중 키 암호화) 를 구현합니다. 하나는 Microsoft(Azure RMS)에서 관리되고 두 번째 키는 조직 온-프레미스 또는 사용자 고유의 외부 키 관리 서비스에서 단독으로 관리됩니다. DKE를 사용하면 암호 해독에 필요한 두 번째 키를 제어하므로 법적 절차에 의해 강제되는 경우에도 Microsoft에서 데이터의 암호를 해독할 수 없습니다.
- Key Vault 키 URI를 참조하여 CMK를 사용하도록 Azure 서비스(Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Disk Encryption 등)를 구성합니다. 자동 키 회전 정책을 사용하도록 설정하여 수동 작업 부담을 줄입니다.
- KEK(Key Vault에 저장됨)가 DEK(서비스에서 사용)를 암호화하여 키 회전이 서비스 가용성에 미치는 영향을 최소화하는 KEK(키 암호화 키) 및 DEK(데이터 암호화 키) 계층 구조를 설정합니다.
- 키 회전 일정, 손상된 키에 대한 해지 프로세스, 키 사용 중지 워크플로 및 재해 복구 절차를 포함한 주요 수명 주기 절차를 문서화합니다. 조직 변경 관리 프로세스에 키 관리를 통합합니다.
메모: 고객 관리형 키에는 키 수명 주기 관리, 액세스 제어 관리, 모니터링 및 재해 복구 계획을 비롯한 지속적인 운영 투자가 필요합니다. 부적절한 키 관리로 인해 데이터를 사용할 수 없거나 손실될 수 있으므로 CMK를 채택하기 전에 운영 준비를 보장합니다.
구현 예제
규제 대상 금융 기관은 거래 데이터 및 고객 재무 기록에 대한 직접 암호화 제어에 대한 규제 요구 사항을 충족하기 위해 Azure 서비스에 CMK(고객 관리형 키)를 배포했습니다.
도전: 규제 감사는 키 관리, 회전 기관 및 해지 기능을 포함하여 암호화 제어를 입증해야 했습니다. 서비스 관리형 키는 테넌트 제어 키 수명 주기의 증거를 제공할 수 없습니다. 고객 관리형 키가 없으면 조직은 보안 인시던트 중에 액세스를 신속하게 취소할 수 없었고 지역 배포에 대한 데이터 주권 요구 사항을 충족할 수 없었습니다.
솔루션 접근 방식:
- Azure Key Vault 관리형 HSM 프로비저닝: 고가용성을 위해 최소 3개의 HSM 파티션으로 관리형 하드웨어 보안 모듈(FIPS 140-3 인증 레벨 3)을 만듭니다. 지리적으로 분산된 오프라인 금고에 저장된 키 조각으로 분할되는 쿼럼 키를 사용하여 보안 도메인을 내보내 관리형 HSM을 활성화합니다. 그런 다음 키 작업, 즉 키 래핑, 해제, 암호화, 복호화를 수행할 수 있는 암호화 키(RSA-4096, KEK-Prod-2024로 명명)를 생성합니다.
- Azure 서비스에 대한 고객 관리형 키를 구성합니다. Azure Storage에서 CMK 암호화 유형을 사용하도록 스토리지 계정을 구성하려면 Key Vault 관리형 HSM을 키 원본으로 선택하고, 관리형 HSM 암호화 서비스 암호화 사용자 역할을 사용하여 사용자 할당 관리 ID를 사용하도록 설정합니다. Azure SQL Database에서 고객 관리형 키를 TDE 보호기로 사용하도록 SQL Database를 구성하고, 관리형 HSM에서 키를 선택하고, 자동 회전을 사용하도록 설정합니다. Azure Cosmos DB의 경우 Cosmos DB 계정에 고객 관리형 키를 사용하도록 설정하고, 관리형 HSM 키를 선택하고, Cosmos DB 관리 ID 액세스 권한을 부여합니다.
- 자동화된 키 회전 구현: 90일 회전 빈도로 회전 정책을 구성하고, 자동 회전을 사용하도록 설정하고, 만료 알림(만료 7일 전 경고)을 구성하고, 키 만료 메트릭에 대한 Azure Monitor 경고를 만들어 보안 팀에 알립니다.
- 준수를 위해 감사 로깅을 사용하도록 설정합니다. Managed HSM(AuditEvent 로그)에 대한 진단 로깅을 사용하도록 설정하고, 변경할 수 없는 스토리지(변조 방지 감사 내역의 경우 90일 보존)를 사용하여 Log Analytics 작업 영역으로 로그를 보내고, 키 액세스 로그를 쿼리하여 암호화, 암호 해독, WrapKey 및 UnwrapKey 작업을 모니터링합니다.
- 문서 키 수명 주기 절차: 긴급 해지 Runbook(키 해지 단계, 인시던트 응답 연락처, 보안 도메인 쿼럼 키를 사용하는 복구 절차)을 만들고, 탁상 연습을 통해 분기별로 Runbook을 테스트하고, CMK 작업을 IT 서비스 관리 변경 승인 워크플로에 통합합니다.
결과: 관리형 HSM의 RSA-4096 KEK는 Azure Storage, SQL Database 및 Cosmos DB에 대한 서비스 수준 DEK를 암호화합니다. 분기별 자동화된 회전은 DEK만 다시 암호화하여 가동 중지 시간을 최소화합니다. 보안 도메인 쿼럼은 완전한 지역 오류가 발생하더라도 재해 복구를 보장합니다.
중요도 수준
있어야 합니다.
컨트롤 매핑
- CIS 컨트롤 v8.1: 3.11
- NIST SP 800-53 Rev.5: SC-12, SC-28
- PCI-DSS v4: 3.5.1, 3.6.1, 12.3.2
- NIST CSF v2.0: 보호. DS-1, ID.AM-3
- ISO 27001:2022: A.8.24
- SOC 2: CC6.1
DP-6: 보안 키 관리 프로세스 사용
Azure Policy:Azure 기본 제공 정책 정의 DP-6을 참조하세요.
보안 원칙
생성, 배포, 스토리지, 회전 및 해지와 같은 전체 키 수명 주기를 제어하는 보안 키 관리 프로세스를 구현합니다. 강력한 액세스 제어가 있는 전용 키 자격 증명 모음 서비스를 사용하고, 암호화 표준을 유지 관리하고, 업무 분리를 적용하고, 키가 정기적으로 회전되고 손상될 때 즉시 해지되도록 합니다.
완화할 리스크
약하거나 관리되지 않는 암호화 키 수명 주기는 암호화에서 제공하는 보증을 저하시키고 시스템적 타협을 가능하게 할 수 있습니다. 구조적 키 생성, 회전, 보호 및 해지 없이:
- 키 스프롤 및 분리: 추적되지 않은 키는 비즈니스 필요 이상으로 유지되며 의도하지 않은 암호 해독 권한을 유지합니다.
- 부실 암호화: 암호가 자주 갱신되지 않으면 알고리즘 다운그레이드, 무차별 공격 또는 사이드 채널 공격에 대한 취약성이 증가합니다.
- 권한 오버리치: 역할 분리가 없으므로 관리자는 키를 관리하고 사용할 수 있으므로 내부자 오용이 가능합니다.
- 감지되지 않은 손상: 무결성 모니터링이나 버전 계보로는 키가 악의적으로 교체되었는지 확인할 수 없습니다.
- 해지 실패: 인시던트 대응은 의심스러운 위반 후 데이터 액세스를 암호화하여 포함할 수 없습니다.
- 일관되지 않은 계층 구조: KEK/DEK 계층화가 누락되어 회전 폭발 반경이 곱해져 작동 가동 중지 시간이 증가합니다.
키 관리가 부족하면 암호화가 진화하는 위협에 대한 지속적인 완화가 아닌 특정 시점 제어로 바뀝니다.
MITRE ATT&CK
- TA0006(자격 증명 액세스): 잘못 저장되거나 캐시된 키 자료를 추출하는 암호 저장소(T1555)의 자격 증명 또는 광범위한 키 관리 RBAC 역할을 악용하여 키를 잘못 액세스하거나 회전하는 유효한 계정(T1078).
- 방어 회피(TA0005): 사용되지 않는 알고리즘을 유지하는 암호화(T1600) 약화/암호화 강도를 줄이기 위한 키 크기가 부족합니다.
- 영향(TA0040): 파괴적인 제거 또는 잘못 처리된 해지 이벤트를 실행하는 데이터 소멸(T1485)
- 영향(TA0040): 데이터 조작(T1565)는 암호화 흐름을 리디렉션하거나 사용 중지시키기 위해 키 버전을 대체하거나 변경하는 것을 포함합니다.
DP-6.1: 주요 관리 정책 및 인프라 설정
중앙 집중식 키 스토리지를 설정하고, 암호화 표준을 정의하고, 워크로드 민감도에 따라 적절한 보호 수준을 선택하여 암호화 키 관리를 위한 거버넌스 기반을 구축합니다. 포괄적인 감사 로깅을 구현하는 동시에 Azure Key Vault를 키 작업의 단일 원본으로 배포하여 규정 준수 및 포렌식 목적으로 모든 키 액세스 및 관리 변경 내용을 추적합니다.
중앙 집중식 키 관리 인프라를 설정합니다.
- Azure Key Vault를 중앙 집중식 암호화 키 관리 서비스로 사용하여 생성, 배포, 스토리지, 회전 및 해지와 같은 전체 키 수명 주기를 제어합니다.
- 최소 암호화 표준을 지정하는 키 정책을 정의하고 적용합니다.
- 키 유형: RSA(권장: 4096비트 또는 3072비트 최소) 또는 EC(P-256, P-384, P-521 곡선).
- 키 작업: 최소 권한 원칙에 따라 허용되는 작업(암호화, 암호 해독, 서명, 확인, 래핑, 래핑 해제)을 제한합니다.
- 유효 기간: 정품 인증 및 만료 날짜를 설정하여 시간 제한 키 사용을 적용합니다.
적절한 키 보관소 계층을 선택합니다.
- 워크로드의 보안 및 규정 준수 요구 사항에 따라 적절한 Key Vault 계층을 선택합니다.
- 소프트웨어 보호 키(표준 및 프리미엄 SKU): FIPS 140-2 수준 1 유효성 검사
- HSM 보호 키(프리미엄 SKU): FIPS 140-2 수준 2 검증(공유 다중 테넌트 HSM 백엔드)
- 관리형 HSM: FIPS 140-3 3단계 검증 완료(전용 단일 사용자 HSM 풀)
- 보안을 강화하기 위해 Azure Key Vault 관리 HSM을 사용하여 단일 테넌트, FIPS 140-3 레벨 3 검증을 받은 HSM 보호를 제공합니다. 관리형 HSM은 백업 및 재해 복구를 위한 암호화 도메인 을 지원합니다.
- 감사 및 규정 준수를 위해 모든 키 액세스, 회전 이벤트 및 관리 작업을 추적하도록 Azure Key Vault 로깅 을 구성하고 로그를 Azure Monitor 또는 Microsoft Sentinel로 라우팅합니다.
DP-6.2: 키 수명 주기 자동화 구현
키 회전을 자동화하고 키 계층 구조를 설정하여 운영 부담을 줄이고, 사용자 오류를 최소화하며, 서비스 중단 없이 신속한 키 교체를 사용하도록 설정합니다. 전체 데이터 세트가 아닌 작은 키 번들을 다시 암호화하여 효율적인 회전을 허용하는 KEK/DEK 패턴을 구현하고 재해 복구 절차를 통합하여 지역 오류 또는 치명적인 이벤트에서 키 가용성을 유지합니다.
자동화된 키 회전 구현:
- Azure Key Vault에서 자동화된 키 회전 정책을 구현합니다.
- 규정 준수 요구 사항에 따라 회전 빈도를 구성합니다(일반적인 간격: 90일, 180일 또는 매년).
- 키 만료 전에 운영 팀에 경고하도록 회전 알림을 사용하도록 설정합니다.
- 수동 개입 없이 새 키 버전을 생성하도록 자동 회전을 구성합니다.
키 계층 구조 및 BYOK를 설정합니다.
- KEK(키 암호화 키) 및 DEK(데이터 암호화 키)를 구분하는 키 계층 구조를 설정합니다.
- 제한된 액세스 제어를 사용하여 Azure Key Vault에 KEK를 저장합니다.
- KEK로 암호화된 서비스 수준 DEK를 생성하여 키 회전의 폭발 반경을 최소화합니다.
- KEK를 회전하려면 전체 데이터 세트가 아닌 DEK를 다시 암호화해야 하므로 가동 중지 시간이 0인 효율적인 키 회전이 가능합니다.
- BYOK(Bring Your Own Key) 시나리오의 경우 온-프레미스 FIPS 140-2 수준 2+ HSM에서 키를 생성하고 BYOK 전송 키 메커니즘을 사용하여 키를 Azure Key Vault 또는 관리형 HSM으로 안전하게 가져와 키 원본 및 양육권에 대한 암호화 증명을 유지합니다.
재해 복구 절차 구현:
- 보조 지역에 지리적으로 복제된 Key Vault를 만드십시오.
- 키 백업 및 복원을 통해 지역 전체에서 키 가용성을 유지합니다.
- 정의된 RTO/RPO 대상을 사용하여 재해 복구 절차를 문서화하고 테스트합니다.
DP-6.3: 키 액세스에 대한 의무 분리 적용
키 관리 역할과 암호화 작업 역할을 분리하여 내부자 위협 및 권한 남용을 방지하여 단일 ID가 키를 만들고 데이터 암호화 또는 암호 해독에 사용할 수 없도록 합니다. 지속적인 모니터링을 구현하여 비정상적인 키 액세스 패턴을 검색하고 보안 인시던트 또는 규정 준수 감사 중에 신속한 영향 평가를 가능하게 하는 포괄적인 주요 인벤토리를 유지 관리합니다.
의무 분리 적용:
- RBAC(역할 기반 액세스 제어) 또는 액세스 정책을 구현하여 의무 분리를 적용합니다.
- 키 관리자를 위한 별도의 역할(키를 만들거나 회전/삭제할 수 있지만 암호화 작업을 수행할 수 없음).
- 키 사용자에 대한 별도의 역할(암호화/암호 해독 작업을 수행할 수 있지만 키를 관리할 수 없음).
- 역할 예: Key Vault Crypto 책임자(관리자), Key Vault 암호화 사용자(애플리케이션/사용자)
- 단일 ID에 권한 남용을 방지하기 위한 관리 및 운영 키 액세스 권한이 없는지 확인합니다.
키 액세스를 모니터링하고 인벤토리를 유지 관리합니다.
-
Microsoft Sentinel과 키 액세스 모니터링을 통합하여 변칙을 탐지합니다.
- 비정상적인 키 액세스 패턴(익숙하지 않은 IP 주소 또는 지역에서의 액세스).
- 대량 키 작업(짧은 기간 내에 과도한 작업)
- 업무 시간 외 관리 변경(업무 시간 외 키 삭제 또는 회전).
- 키 인벤토리의 키 이름, 용도, 회전 일정 및 종속 서비스를 추적하여 관리합니다. 보안 검토 중에 정기적으로 인벤토리를 검토합니다.
구현 예제
의료 SaaS 공급자는 다중 테넌트 플랫폼에서 PHI 암호화를 위해 HSM으로 보호되는 키와 함께 Azure Key Vault Premium SKU를 사용하여 암호화 키 관리를 중앙 집중화했습니다.
도전: 개발 팀 간에 조각화된 키 관리로 인해 보안 인시던트 중에 키 스프롤, 일관되지 않은 회전 사례 및 키 사용 추적에 어려움이 발생했습니다. 광범위한 RBAC 권한을 통해 관리자는 키를 관리하고 사용할 수 있으므로 내부자 위험이 발생합니다. 자동화된 회전 및 업무 분리가 없으면 조직은 확장된 키 손상 기간과 감사 요구 사항 미준수에 직면했습니다.
솔루션 접근 방식:
- HSM 보호 키를 사용하여 Azure Key Vault Premium을 프로비전 합니다. HSM 보호 키를 지원하는 프리미엄 계층이 있는 Azure Key Vault를 만들고, 보존 기간 동안 영구 삭제를 방지하기 위해 제거 보호를 사용하도록 설정하고, 실수로 삭제된 키를 복구할 수 있도록 90일 보존으로 일시 삭제를 사용하도록 설정하고, 하드웨어 지원 키 형식으로 RSA-3072 HSM 보호 암호화 키(KEK-PHI-Prod)를 생성합니다.
- 자동화된 키 회전 정책 구현: 180일 회전 빈도로 회전 정책을 구성하고, 자동 회전을 사용하도록 설정하고, 만료 30일 전에 알림을 설정하고, 키가 만료되면 보안 운영 팀에 알리도록 Azure Monitor 작업 그룹을 만들고, 새 키 버전을 자동으로 생성하도록 회전 작업을 구성합니다.
- RBAC 의무 분리 구성: 보안 팀 구성원에게 Key Vault Crypto Officer 역할 할당(권한: 키 수명 주기를 관리하지만 암호화/암호 해독 작업을 수행할 수 없음), 애플리케이션 관리 ID에 Key Vault Crypto 사용자 역할 할당(권한: 키 관리 권한 없이 암호화/암호 해독 작업 수행), ID에 Crypto Officer 및 Crypto 사용자 역할이 모두 없는지 확인하여 업무 분리를 확인합니다.
- 빠른 키 회전을 위해 KEK/DEK 계층 구조를 설정합니다 . 환자 데이터를 암호화하기 위한 애플리케이션 코드(AES-256 키) 내에서 애플리케이션 수준 DEK(데이터 암호화 키)를 생성하고, 암호화된 DEK를 암호화된 데이터와 함께 저장하고, Key Vault KEK를 사용하여 WrapKey 작업을 통해 DEK를 래핑/암호화하고, 환자 데이터를 해독할 때 UnwrapKey 작업을 사용하여 DEK를 검색 및 래핑 해제합니다. 혜택: KEK를 회전하려면 전체 환자 데이터베이스 대신 DEK를 다시 암호화해야 합니다.
- Microsoft Sentinel과 Key Vault 로그 통합: Key Vault에 대한 진단 설정을 사용하도록 설정하고 Log Analytics 작업 영역에 로그를 보내고, Sentinel 분석 규칙을 만들어 비정상적인 키 액세스 패턴, 대량 키 작업, 근무 시간외 관리 변경을 검색합니다.
- 온-프레미스 HSM에서 BYOK(Bring Your Own Key) 전송: Key Vault에서 BYOK 전송 키를 다운로드하고, Key Vault의 BYOK 전송 공개 키로 래핑된 온-프레미스 HSM에서 키를 내보내고, 키 계보의 암호화 증명을 유지 관리하고, 래핑된 키를 일반 텍스트 노출 없이 HSM으로 보호된 Key Vault로 가져옵니다.
결과: RSA-3072 키는 자동화된 알림으로 180일마다 회전합니다. RBAC 분리는 권한 남용을 방지합니다. KEK/DEK 계층 구조를 사용하면 DEK만 다시 암호화하여 신속하게 회전할 수 있습니다. 일시 삭제는 실수로 삭제된 키를 복구합니다. Microsoft Sentinel은 익숙하지 않은 IP 액세스 또는 근무 시간 외부 수정과 같은 변칙을 검색합니다.
중요도 수준
있어야 합니다.
컨트롤 매핑
- CIS 컨트롤 v8.1: N/A
- NIST SP 800-53 Rev.5: IA-5, SC-12, SC-28
- PCI-DSS v4: 3.6.1, 8.3.2
- NIST CSF v2.0: PR.AC-1, PR.DS-1
- ISO 27001:2022: A.8.24, A.8.3
- SOC 2: CC6.1, CC6.2
DP-7: 보안 인증서 관리 프로세스 사용
Azure Policy:Azure 기본 제공 정책 정의 DP-7을 참조하세요.
보안 원칙
인벤토리, 자동화된 갱신, 강력한 암호화 표준 및 시기 적절하게 해지를 포함하는 중앙 집중식 프로세스를 통해 인증서 수명 주기를 관리합니다. 중요한 서비스에 대한 인증서가 만료 전에 추적, 모니터링 및 갱신되어 서비스 중단을 방지하고 암호화된 보안 통신을 유지 관리해야 합니다.
완화할 리스크
제대로 관리되지 않는 인증서 수명 주기는 서비스 중단을 초래하고 암호화 채널의 보안을 약화시키며 위조를 허용합니다. 중앙 집중식 인벤토리, 정책 적용 및 자동화된 갱신이 없는 경우:
- 예기치 않은 만료: 만료된 인증서는 프로덕션 중단을 트리거하여 API, ID 페더레이션 또는 클라이언트 신뢰 경로를 중단합니다.
- 약한 암호화 지속성: 레거시 키 크기/서명 알고리즘(예: SHA-1, RSA < 2048)은 사용 중단 이후에도 계속 사용됩니다.
- 와일드카드 및 자체 서명 인증서 남용: 광범위하거나 관리되지 않는 자체 서명 인증서는 횡적 가장 및 TLS 다운그레이드의 위험을 유발할 수 있습니다.
- 감지되지 않은 손상: 도난당한 프라이빗 키는 회전할 때까지 투명하게 중간자 공격 및 트래픽 암호 해독을 허용합니다.
- 섀도 인증서: 승인된 CA 외부의 허가되지 않은 발급은 거버넌스를 조각화하고 해지 사각지대를 증가합니다.
- 수동 갱신 오류: 일치하지 않는 대체 시퀀싱으로 인해 트러스트 체인의 불일치 및 부분 환경 드리프트가 발생합니다.
인증서 관리가 부족하면 암호화된 보증이 저하되고 중요한 서비스에서 안정성과 보안 불안정성이 모두 발생합니다.
MITRE ATT&CK
- 방어 회피(TA0005): 유효성 검사를 우회하기 위해 사기성/불량 인증서를 발급하거나 도입하는 트러스트 제어(T1553) 전복
- 리소스 개발(TA0042): 향후 침입 단계를 위해 인증서 또는 도구를 위조하는 기능(T1587)을 개발합니다.
- 방어 회피(TA0005): 암호화 약화(T1600)는 검증 보증을 줄이고 있는 구식 서명 알고리즘을 지속해서 사용합니다.
- TA0006(자격 증명 액세스): 안전하지 않은 파일 저장소 또는 프로세스 메모리에서 프라이빗 키를 추출하는 보호되지 않는 자격 증명(T1552)입니다.
- 지속성(TA0003): 인증서 기반 인증 흐름을 다시 작성하는 인증 프로세스(T1556)를 수정하여 수명이 긴 액세스를 포함합니다.
DP-7.1: 인증서 정책 및 CA 통합 설정
인증서 거버넌스 표준을 정의하고 신뢰할 수 있는 인증 기관을 통합하여 인프라 전체에서 일관된 암호화 품질 및 자동화된 발급을 보장합니다. 프라이빗 키가 손상될 때 공격 노출 영역을 확장하는 자체 서명된 인증서 및 와일드카드 인증서와 같은 위험한 사례를 제거하면서 최신 키 크기, 서명 알고리즘 및 유효 기간을 적용하는 정책을 설정합니다.
인증서 관리 인프라 설정:
- Azure Key Vault를 사용하여 만들기, 가져오기, 갱신, 회전, 해지 및 보안 삭제와 같은 전체 인증서 수명 주기를 중앙에서 관리합니다.
- Azure Key Vault에서 인증서 정책을 정의하여 조직 보안 표준을 적용합니다.
- 키 유형 및 크기: RSA 2048비트 최소값(수명이 긴 인증서의 경우 3072비트 또는 4096비트 권장) 타원 곡선 인증서의 경우 EC P-256 이상
- 서명 알고리즘: SHA-256 이상(SHA-1 및 MD5 금지)
- 유효 기간: 공용 TLS 인증서의 경우 최대 397일(CA/브라우저 포럼 기준 요구 사항당); 노출 감소에 권장되는 기간(90일)이 짧습니다.
- 인증 기관: 승인된 통합 CA(DigiCert, GlobalSign) 또는 조직의 프라이빗 CA만 사용합니다.
인증 기관 통합:
- 공용 TLS/SSL 인증서에 대해 Azure Key Vault와 통합된 파트너 인증 기관을 사용합니다.
- DigiCert: OV(조직 유효성 검사) TLS/SSL 인증서
- GlobalSign: OV(조직 유효성 검사) TLS/SSL 인증서
- 프라이빗/내부 서비스의 경우 자동화된 인증서 발급을 위해 조직의 내부 인증 기관(예: Active Directory 인증서 서비스 - ADCS)을 Azure Key Vault와 통합합니다.
- 프로덕션 환경에서 자체 서명된 인증서 및 와일드카드 인증서를 사용하지 마세요.
- 자체 서명된 인증서: 타사 유효성 검사가 부족하고, 공용 CRL/OCSP를 통해 해지할 수 없으며, 최신 브라우저/클라이언트에서 거부됩니다.
- 와일드카드 인증서: 광범위한 범위는 손상된 경우 위험을 증가합니다. 대신 명시적 FQDN과 함께 SAN(주체 대체 이름) 인증서를 사용합니다.
메모: 간단한 시나리오의 경우 Azure App Service 관리 인증서(사용자 지정 도메인에 대한 무료 자동 갱신 인증서)를 사용할 수 있습니다.
DP-7.2: 자동화된 인증서 갱신 구현
만료되기 전에 트리거되는 갱신 워크플로를 자동화하여 만료된 인증서로 인한 서비스 중단을 제거하고 수동 개입 없이 종속 서비스에서 인증서를 원활하게 업데이트합니다. 관리 ID를 사용하여 Key Vault에서 갱신된 인증서를 자동으로 검색하도록 Azure 서비스를 구성하여 운영 수고를 줄이고 휴일 또는 직원 전환 중에 수동 갱신이 잊혀질 위험을 제거합니다.
자동화된 갱신 구성:
- 지정된 인증서 수명 백분율로 갱신을 트리거하도록 수명 작업을 구성하여 Azure Key Vault에서 자동화 된 인증서 갱신을 사용하도록 설정합니다.
- 권장 트리거: 유효 기간의 80-90%(예: 397일 인증서의 경우 ~318일).
- 작업: 자동으로 갱신(Key Vault는 수동 개입 없이 CA에서 갱신을 요청합니다).
- 자동 갱신 트리거 전에 예정된 인증서 만료를 관리자에게 알리도록 알림 연락처를 구성합니다.
자동 인증서 바인딩 사용:
- 자동 인증서 회전을 지원하는 Azure 서비스(Azure App Service, Azure Application Gateway, Azure Front Door)의 경우 관리 ID 또는 적절한 Key Vault 액세스 정책이 있는 서비스 주체를 사용하여 Key Vault에서 업데이트된 인증서를 자동으로 검색하도록 다음 서비스를 구성합니다.
- Azure 서비스는 갱신될 때 새 인증서 버전을 자동으로 바인딩합니다(일반적으로 24시간 이내에 서비스를 다시 시작할 필요가 없음).
- Key Vault 인증서를 자동으로 사용할 수 없는 애플리케이션의 경우 운영 Runbook 및 모니터링 경고를 사용하여 수동 인증서 회전 워크플로 를 구현하여 만료 관련 중단을 방지합니다.
- Azure Key Vault 추적 인증서 이름, 목적, 만료 날짜, 종속 서비스 및 갱신 상태의 모든 인증서 인벤토리를 유지 관리합니다.
DP-7.3: 인증서 수명 주기 모니터링 및 해지 처리
만료가 가까워지거나, 사용되지 않는 암호화를 사용하거나, 적절한 거버넌스가 부족한 인증서를 표시하는 자동화된 모니터링, 인벤토리 쿼리 및 대시보드를 통해 인증서 상태에 대한 지속적인 가시성을 유지합니다. 손상된 인증서에 대해 신속한 해지 절차를 수립하고, 업계 위협 인텔리전스와 연계하여 손상된 인증 기관에서 발급된 인증서가 중간자 공격에 사용되기 전에 사전에 차단합니다.
모니터링 및 경고 구성:
- 인증서 만료 이벤트에 대한 Azure Monitor 경고를 구성합니다 .
- 만료 30일 전에 경고를 만듭니다(경고 알림).
- 만료 7일 전에 경고를 만듭니다(보안 팀에 에스컬레이션이 있는 중요한 경고).
인증서 인벤토리 및 대시보드 유지 관리:
-
Azure Resource Graph를 사용하여 인증서 인벤토리를 쿼리합니다.
- 만료가 가까워지는 인증서를 쿼리합니다(30/60/90일 이내).
- 자체 서명된 인증서를 쿼리합니다.
- 사용되지 않는 알고리즘(예: SHA-1)을 사용하여 인증서를 쿼리합니다.
- 시각화를 사용하여 인증서 감사 대시보드(예: Power BI)를 만듭니다.
- 시간 버킷별 인증서 만료 타임라인입니다.
- 리소스 그룹별 자체 서명된 인증서 수입니다.
- 사용되지 않는 암호화 표준을 사용하는 인증서입니다.
- 보안 검토 모임 중에 정기적으로 인증서 감사 대시보드를 검토합니다(권장: 분기별).
해지 절차를 설정합니다.
- 손상된 인증서 또는 사용 중지된 인증서에 대한 인증서 해지 절차를 설정합니다.
- 문서 해지 프로세스(Key Vault에서 인증서 사용 안 함, 종속 서비스 알림)
- 인증서 손상 시나리오에 대한 인시던트 대응 Runbook을 유지 관리합니다.
- 손상된 루트 또는 중간 CA 인증서에 대한 업계 권고를 모니터링하고 즉시 차단합니다.
구현 예제
200개 이상의 공용 웹 애플리케이션이 있는 엔터프라이즈는 DigiCert와 통합된 Azure Key Vault를 인증 기관으로 사용하여 인증서 수명 주기 관리를 중앙 집중화했습니다.
도전: 수동 인증서 갱신 프로세스로 인해 인증서가 예기치 않게 만료될 때 여러 프로덕션 중단이 발생했습니다. 와일드카드 인증서는 프라이빗 키가 손상되었을 때 과도한 폭발 반경을 생성했습니다. 팀 간에 조각화된 인증서 관리로 인해 섀도 인증서, 일관되지 않은 암호화 표준, 보안 인시던트 중 해지 지연이 발생했습니다. 자동화된 갱신 및 중앙 집중식 인벤토리가 없으면 조직은 규정 준수 오류 및 서비스 중단에 직면했습니다.
솔루션 접근 방식:
- Azure Key Vault와 인증 기관 통합 구성: 자동화된 인증서 요청에 대한 API 자격 증명을 사용하여 Key Vault에 DigiCert(또는 기타 파트너 인증 기관)를 추가합니다.
-
보안 표준을 적용하는 인증서 정책을 정의하십시오: 인증서 정책 정의에는 인증서 이름(www-contoso-com-2024), 발급자(DigiCert), 주체(CN=www.contoso.com), DNS 이름(SAN:
www.contoso.com, api.contoso.com, portal.contoso.com - 와일드카드 인증서를 피하십시오), 키 유형(RSA 4096비트), 서명 알고리즘(SHA-256), 유효 기간(CA/브라우저 포럼 기준 최대 397일), 자동 갱신을 위한 수명 작업 구성(397일 인증서의 경우 인증서 수명의 약 80%인 318일에 트리거 설정), 작업: 자동으로 갱신(Key Vault는 수동 개입 없이 DigiCert에서 갱신을 요청합니다). - Azure 서비스에 대한 자동 인증서 바인딩 구성: Key Vault에서 Azure App Service 가져오기 인증서의 경우 Key Vault 비밀 사용자 역할을 사용하여 사용자 할당 관리 ID를 할당하고, 자동 인증서 업데이트를 사용하도록 설정합니다(App Service는 갱신 시 24시간 이내에 새 인증서 버전을 바인딩하고 다시 시작은 필요하지 않음). Azure Application Gateway가 Key Vault에서 인증서를 검색하도록 수신기를 구성하고, Key Vault 비밀 사용자 및 인증서 사용자 역할을 사용하여 사용자 할당 관리 ID를 할당하기 위해 Application Gateway는 Key Vault에서 인증서를 갱신할 때 업데이트된 인증서를 자동으로 검색합니다.
- 인증서 만료 경고 구성: Azure Monitor에서 30일 만료 경고(플랫폼 엔지니어링 Slack 채널에 알림 보내기), 7일 만료 중요 경고(수동 검토를 위해 Jira 티켓을 열고 보안 팀에 전자 메일 보내기)의 두 가지 경고 규칙을 만듭니다.
-
SAN 인증서를 위해 와일드카드 인증서를 제거합니다. Key Vault에서 기존 와일드카드 인증서(*.contoso.com)를 감사하고 명시적 DNS 이름(api.contoso.com)
www.contoso.com이 포함된 SAN 인증서로 바꿉니다. 프라이빗 키가 손상된 경우 나열된 FQDN만 영향을 받습니다(모든 하위 도메인이 아님). - 인증서 만료 모니터링: Azure Resource Graph를 사용하여 인증서 인벤토리를 쿼리하고 만료(30일 이내), 자체 서명된 인증서 또는 사용되지 않는 SHA-1 서명 알고리즘을 사용하는 인증서를 식별하려면 보안 검토 모임 중에 분기별로 대시보드를 검토합니다.
결과: 인증서 수명이 80%일 때 자동 갱신이 시작됩니다. Azure App Service 및 Application Gateway는 관리 ID를 통해 24시간 이내에 업데이트된 인증서를 검색합니다(다시 시작 필요 없음). Azure Monitor 경고는 만료 전에 플랫폼 엔지니어링에 알립니다. SAN 인증서는 와일드카드 인증서를 대체하여 손상 폭발 반경을 줄입니다.
중요도 수준
있어야 합니다.
컨트롤 매핑
- CIS 컨트롤 v8.1: N/A
- NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
- PCI-DSS v4: 3.6.1, 8.3.2
- NIST CSF v2.0: PR.AC-1, ID.AM-3
- ISO 27001:2022: A.8.3
- SOC 2: CC6.1, CC6.2
DP-8: 키 및 인증서 리포지토리의 보안 보장
Azure Policy:Azure 기본 제공 정책 정의 DP-8을 참조하세요.
보안 원칙
최소 권한 액세스, 네트워크 격리, 포괄적인 로깅 및 모니터링, 백업 및 복구 기능, 필요한 경우 HSM으로 지원되는 보호 등 심층 방어 제어를 통해 키 볼트 서비스를 보호합니다. 키 저장소는 암호화와 인증에 사용되는 암호 키와 인증서를 보호하는 중요한 인프라입니다.
완화할 리스크
키 및 인증서 리포지토리의 손상은 업스트림 암호화, 서명 및 ID 보증을 무효화합니다. 강화된 금고 액세스, 모니터링 및 격리가 없는 경우:
- 키 반출: 도난당한 KEK/HSM 자료는 저장된 데이터 및 트래픽 가로채기의 대량 암호 해독을 허용합니다.
- 그림자 행정 액세스: 지나치게 광범위한 RBAC 또는 정책의 잘못된 구성은 무단 키 내보내기, 삭제 또는 버전 롤백을 가능하게 합니다.
- 은밀한 변조: 악성 키 교체는 탐지되지 않는 중간자 공격 또는 위조된 코드/서명 실행을 가능하게 합니다.
- 네트워크 노출: 퍼블릭 엔드포인트 남용(자격 증명 스터핑, API 검색)은 무차별 암호 대입 또는 토큰 재생에 대한 공격 노출 영역을 증가합니다.
- 실수로 파괴적인 작업: 일시 삭제/제거 보호가 누락된 경우 되돌릴 수 없는 암호화 데이터 손실이 발생합니다.
- 감사 계보가 부족합니다. 변경할 수 없는 로그가 없으면 인시던트 대응 및 규정 증명 요구 사항이 손상됩니다.
- 비분리된 테넌트: 단일 ID 손상 후 혼합된 애플리케이션 키는 횡적 이동 범위를 넓힙니다.
리포지토리의 약점은 종속 워크로드에서 시스템 기밀성, 무결성 및 가용성 오류로 빠르게 전파됩니다.
MITRE ATT&CK
- 자격 증명 액세스(TA0006): 잘못 구성된 볼트 역할 또는 네트워크 정책으로 인해 획득된 보호되지 않은 자격 증명/자격 증명 보관소(T1552/T1555).
- 방어 회피(TA0005): 중간자 공격(T1557)으로 자격 증명 모음 대상 트래픽을 캡처하여 키/인증서를 가로채거나, 강력한 키를 공격자 제어 자료로 대체하여 암호화를 약화하는 방법(T1600).
- 권한 상승(TA0004): 과도하게 광범위한 금고 운영자 역할을 악용하여 비밀을 열거하고 변경하는 유효한 계정(T1078) 활용.
- 영향(TA0040): 복원을 방지하는 파괴적인 제거 시퀀스를 수행하는 데이터 소멸/복구 억제(T1485/T1490).
DP-8.1: Key Vault에 대한 액세스 제어 구현
권한 없는 키 액세스를 방지하고, 관리 권한을 정당화된 시간 기간으로 제한하고, 관리 ID를 통해 자격 증명 스토리지를 제거하는 엄격한 ID 기반 액세스 제어를 적용하여 인프라의 암호화 기반을 보호합니다. 단일 손상된 ID가 암호화 자료를 관리하고 악용하는 것을 방지하기 위해 주요 관리자와 주요 사용자 간의 업무 분리를 구현합니다.
RBAC 구현 및 의무 분리:
-
Key Vault용 Azure RBAC를 구현하여 최소 권한 액세스 제어를 적용합니다.
- Azure Key Vault 관리형 HSM의 경우: 기본 제공 역할(관리형 HSM Crypto Officer, Crypto User, Crypto 감사자)을 사용하여 개별 키, 비밀 및 인증서 수준에서 로컬 RBAC를 사용합니다.
- Azure Key Vault 표준/프리미엄의 경우: 논리적 분리를 적용하기 위해 애플리케이션 또는 환경별로 전용 자격 증명 보관소를 별도로 생성하고, 역할 기반 액세스 제어(RBAC) 역할(Key Vault 관리자, 비밀 책임자, 인증서 책임자)을 애플리케이션별 범위로 할당합니다.
- 업무 분리 적용: 암호화 작업(암호화/암호 해독에 키를 사용할 수 있는 사용자)과 키 관리를 위한 별도의 역할(키를 만들거나 회전할 수 있는 사용자).
관리 ID 및 JIT 액세스 사용:
- 애플리케이션 코드 또는 구성 파일에 자격 증명을 저장하는 대신 Azure 리소스(App Services, VM, Azure Functions 등)에 대한 관리 ID 를 사용하여 Key Vault에 액세스합니다. 관리 ID는 자격 증명 스토리지 및 회전 복잡성을 제거합니다.
- Key Vault에 대한 Just-In-Time 관리 액세스를 위해 Azure AD PIM(Privileged Identity Management) 을 구현합니다.
- Key Vault 관리자 역할에 대한 적격 할당을 구성합니다(영구 할당이 아님).
- 활성화를 위해 근거, MFA 및 승인이 필요합니다.
- 최대 활성화 기간(예: 8시간)을 설정합니다.
- 정기적인 액세스 검토를 수행하여 불필요한 대기 권한을 취소합니다.
DP-8.2: Key Vault 네트워크 보안 강화
가상 네트워크 내의 프라이빗 엔드포인트를 통해 모든 Key Vault 액세스를 라우팅하여 인터넷 연결 공격 노출 영역을 제거하고, 외부 위협 행위자로부터 자격 증명 스터핑, 무차별 암호 대입 시도 및 정찰을 방지합니다. CI/CD 시나리오에서 공용 액세스를 피할 수 없는 경우 엄격한 IP 허용 목록 및 방화벽 규칙을 구현하여 가능한 가장 작은 노출 창을 만듭니다.
Private Link를 배포하고 방화벽을 구성합니다.
- Azure Private Link 를 사용하여 Azure Key Vault에 대한 네트워크 액세스를 보호하여 Key Vault를 공용 인터넷에 노출하지 않고 VNet에서 프라이빗 연결을 설정합니다.
- Private Link를 사용할 수 없는 시나리오에 대해 특정 IP 범위 또는 VNet에 대한 액세스를 제한하도록 Key Vault 방화벽 을 구성합니다.
- 가능한 경우 공용 액세스를 사용하지 않도록 설정합니다(Key Vault는 프라이빗 엔드포인트를 통해서만 액세스할 수 있음).
- 공용 액세스가 필요한 경우(예: CI/CD 파이프라인의 경우) IP 허용 목록이 좁은 선택한 네트워크에서만 액세스를 허용합니다.
-
프라이빗 DNS 영역(예:
privatelink.vaultcore.azure.net)을 만들어 VNet에 연결하여 프라이빗 엔드포인트에 대한 적절한 DNS 확인을 보장합니다.
DP-8.3: Key Vault 보호 및 모니터링 활성화
FIPS 유효성이 검사된 보안이 필요한 프로덕션 워크로드에 HSM 지원 키를 사용하는 동안 일시 삭제 및 제거 보호를 통해 돌이킬 수 없는 암호화 데이터 손실을 방지하는 심층 방어 보호를 구현합니다. Microsoft Defender for Key Vault 및 Microsoft Sentinel을 사용하여 포괄적인 모니터링을 배포하여 암호화 인프라를 대상으로 하는 손상, 내부자 위협 또는 정찰 활동을 나타내는 비정상적인 액세스 패턴, 비정상적인 키 작업 및 관리 변칙을 검색합니다.
일시 삭제 및 제거 보호를 사용하도록 설정합니다.
- 모든 Azure Key Vault에서 일시 삭제 및 제거 보호를 사용하도록 설정하여 키, 비밀 및 인증서의 우발적이거나 악의적인 삭제를 방지합니다.
- 일시 삭제를 사용하면 보존 기간(기본값: 90일) 내에서 복구할 수 있습니다.
- 제거 보호는 보존 기간 동안 영구 삭제를 방지합니다.
- 기본 제공 정책을 사용하여 Azure Policy에 이러한 설정을 적용합니다. "키 자격 증명 모음은 일시 삭제를 사용하도록 설정해야 합니다." 및 "키 자격 증명 모음은 제거 보호를 사용하도록 설정해야 합니다."(deployIfNotExists 효과).
- 키 수명 주기 정책을 구현하여 데이터의 암호화 삭제를 방지합니다.
- 암호화된 데이터를 삭제하기 전에 필요한 데이터 보존 기간 동안 암호화 키가 유지되는지 확인합니다.
- 키를 해제할 때 감사 목적으로 키 메타데이터를 유지하면서 실수로 인한 데이터 손실을 방지하기 위해 삭제 대신 사용 안 함 작업을 사용합니다.
- 재해 복구 시나리오에 대한 Key Vault 백업 절차를 만들고 테스트합니다.
HSM 지원 키 및 BYOK를 사용합니다.
- 강력한 암호화 보호가 필요한 프로덕션 워크로드에 HSM 지원 키를 사용합니다.
- Azure Key Vault 프리미엄: FIPS 140-2 수준 2 유효성이 검사된 HSM(공유 다중 테넌트)으로 보호되는 RSA-HSM 및 EC-HSM 키입니다.
- Azure Key Vault 관리형 HSM: FIPS 140-3 수준 3 유효성이 검사된 HSM(전용 단일 테넌트 풀)으로 보호되는 RSA-HSM 및 EC-HSM 키입니다.
- BYOK(Bring Your Own Key) 시나리오의 경우 온-프레미스 FIPS 140-2 수준 2+ HSM에서 키를 생성하고 BYOK 전송 키 메커니즘을 사용하여 키를 Azure Key Vault로 안전하게 가져와 키 원본 및 양육권에 대한 암호화 증명을 유지합니다.
모니터링 및 위협 감지를 사용하도록 설정합니다.
- Azure Key Vault에 대한 진단 로깅 을 사용하도록 설정하고 로그를 Azure Monitor, Log Analytics 또는 Microsoft Sentinel로 라우팅하여 모든 관리 평면 및 데이터 평면 작업을 캡처합니다. 비정상적인 키 액세스 패턴, 실패한 인증 시도 및 관리 변경을 비롯한 의심스러운 활동을 모니터링합니다.
- Key Vault용 Microsoft Defender를 사용하도록 설정하여 비정상적인 액세스 패턴, 비정상적인 키 작업 및 자격 증명 남용, 의심스러운 키 검색 또는 관리 이상과 같은 잠재적 위협을 검색할 수 있습니다. Defender for Key Vault 경고를 인시던트 대응 워크플로와 통합합니다.
- Key Vault 로그를 Microsoft Sentinel 과 통합하여 비정상적인 지역 액세스, 잠재적 무차별 암호 대입 시도 또는 의심스러운 관리 작업과 같은 변칙을 검색하기 위한 분석 규칙을 만듭니다. 자동화된 응답 플레이북을 구현하여 손상된 ID를 격리하고 보안 팀에 알립니다.
메모: 모든 Key Vault SKU는 의도적으로 키 내보내기 방지; 암호화 작업은 보안 HSM 경계 내에서 수행됩니다. Azure Key Vault 외부의 일반 텍스트로 키를 내보내거나 저장하지 않습니다.
구현 예제
다국적 기술 회사는 500개 이상의 마이크로 서비스에 대한 암호화 키, API 비밀 및 TLS 인증서를 보호하는 Azure Key Vault 인프라에 대한 심층 방어 보안을 구현했습니다.
도전: 광범위한 RBAC 권한을 통해 개발자는 프로덕션 Key Vault에 직접 액세스하여 내부자 위험 및 규정 준수 위반을 초래했습니다. 공용 인터넷 노출은 자격 증명 스터핑 공격 및 정찰 시도를 가능하게 했습니다. 포괄적인 모니터링 및 자동화된 응답이 없으면 의심스러운 키 액세스 패턴이 검색되지 않습니다. 일시 삭제 및 제거 보호가 부족하여 인시던트 중에 영구적인 암호화 데이터가 손실될 위험이 있습니다.
솔루션 접근 방식:
- 논리 구분을 위해 전용 Key Vault를 배포합니다 . 명명 규칙 kv-{businessunit}-{environment}-{region}(예: kv-finance-prod-eastus2, kv-finance-dev-eastus2)을 사용하여 환경 및 사업부당 Key Vault를 만들고, 환경당 별도의 리소스 그룹에 배포하여 격리를 적용합니다(손상된 개발 서비스 주체는 프로덕션 키에 액세스할 수 없음).
- 최소 권한 액세스를 위해 RBAC를 구성합니다 . 비프로덕션 Key Vault(개발/스테이징)의 경우 개발자 보안 그룹에 Key Vault 비밀 사용자(읽기 전용)를 할당합니다. 개발자는 개발/스테이징에서 비밀을 읽을 수 있지만 프로덕션 Key Vault에 대한 액세스 권한은 없습니다. 프로덕션 Key Vault의 경우 KEY Vault 비밀 사용자를 CI/CD 서비스 주체(Azure DevOps 파이프라인 관리 ID)에 할당하고, 범위를 특정 명명된 비밀로 제한하고, 프로덕션 키에 대한 대화형 개발자 액세스가 없습니다.
- Azure Private Link를 사용하여 네트워크 보안 강화: Key Vault에 대한 프라이빗 엔드포인트 배포(VNet 및 서브넷 선택, 프라이빗 DNS 영역 privatelink.vaultcore.azure.net 만들기 및 VNet에 대한 링크 만들기), Key Vault 방화벽을 구성합니다(CI/CD에 필요한 공용 액세스가 승인된 Azure VNet 서브넷 및 CI/CD 에이전트 IP 주소 범위를 사용하여 선택한 네트워크에서만 액세스를 허용하는 경우 프라이빗 엔드포인트를 통해서만 액세스할 수 있는 Key Vault를 사용하여 공용 액세스를 사용하지 않도록 설정).
- Key Vault용 Microsoft Defender를 사용하도록 설정합니다. 구독 수준에서 Key Vault용 Microsoft Defender를 사용하도록 설정하고, Defender는 비정상적인 지리적 액세스, 의심스러운 열거형(정찰을 나타내는 빠른 목록 작업), 비정상적인 관리 작업(대량 비밀 삭제)을 비롯한 변칙을 모니터링합니다.
- 자동화된 응답을 위해 Microsoft Sentinel과 통합: Sentinel에 Microsoft Defender for Cloud 데이터 커넥터를 추가하고, 비정상적인 지역 액세스, 잠재적 무차별 암호 대입, 의심스러운 관리 작업에 대한 Sentinel Analytics 규칙을 만들고, 의심스러운 ID를 사용하지 않도록 자동화된 응답 플레이북을 구성하고, 보안 팀에 알립니다.
- 진단 로그를 Log Analytics로 스트리밍: AuditEvent(모든 키/비밀/인증서 작업), AllMetrics(사용 빈도, 대기 시간)를 사용하여 Key Vault에 대한 진단 로깅을 사용하도록 설정하고, 2년 보존 기간으로 Log Analytics 작업 영역으로 보내고, 잠재적인 무차별 암호 대입 검색(5분 동안 10회 이상의 무단 시도), 비활성화된 일시 삭제 작업(사보타주 표시기)을 비롯한 변칙 검색에 대한 사용자 지정 KQL 쿼리를 만듭니다.
- Azure AD PIM을 사용하여 Just-In-Time 관리자 액세스 구현: Key Vault 관리자 역할에 대한 적격 할당 구성(자격 없는 영구 할당으로 보안 팀 구성원 추가, 활성화를 위한 근거 및 MFA 필요, 최대 활성화 기간 8시간 설정, 고위 보안 설계자의 승인 필요), 모든 Key Vault 관리자 역할 할당에 대한 분기별 액세스 검토 수행; 불필요한 액세스를 취소합니다.
결과: 환경당 전용 Key Vault는 분할을 적용합니다. RBAC는 개발자가 읽기 전용 비프로덕션 액세스로 제한합니다. Private Link는 공용 인터넷 노출을 제거합니다. Microsoft Defender에서 변칙을 검색합니다. Sentinel 플레이북은 의심스러운 아이덴티티를 자동으로 비활성화합니다. PIM은 Just-In-Time 관리자 액세스를 가능하게 하여 대기 권한을 크게 줄입니다.
중요도 수준
있어야 합니다.
컨트롤 매핑
- CIS 컨트롤 v8.1: N/A
- NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
- PCI-DSS v4: 3.6.1, 8.3.2
- NIST CSF v2.0: 홍보. AC-1, PR. DS-1
- ISO 27001:2022: A.8.3, A.8.24
- SOC 2: CC6.1, CC6.2