휴식 시간 암호화

휴식 암호화 중

1) 필요한 이유와 정확히 우리가 보호하는 것

정의. 정지 상태의 암호화는 미디어에 작성된 데이터 (디스크, 스냅 샷, 백업, 객체, 로그, 메모리 덤프) 를 보호하여 실제 미디어 또는 "원시" 스토리지에 대한 무단 액세스가 컨텐츠를 공개하지 않도록합니다.

• 블록/파일 볼륨, 객체 저장 장치, 데이터베이스, 대기열/캐블, 캐시 덤프, 로그/트레일, 백업, 내보내기/가져 오기, VM/컨테이너 스냅 샷, 커널/프로세스 덤프, 교환/교환.
• 다중 임대 시나리오: 클라이언트/프로젝트/환경 간 격리.

우리가 완전히 다루지 않는 것: 메모리 세션 도난, 라이브 프로세스 공격, 응용 프로그램 취약성, 자격 증명 손상. 기내 암호화, 강력한 인증/인증, 권한 최소화 및 모니터링이 필요합니다 (관련 기사: "인증 및 인증", "요청 서명 및 확인" 참조).

2) 위협 모델 및 제어 목표

• 미디어 손실/도난 (디스크, 테이프, USB, 개발자 장치).
• 백업/스냅 샷/로그에 대한 무단 액세스.
• 플랫폼/하이퍼 바이저/스토리지 노드 레벨에서 권한 남용.
• 구성 오류에 대한 세입자 교차.
• 인공물과 이미지에 속하는 임시 파일과 덤프.

1. 매체에서 데이터의 비밀 유지.

2. 세입자/환경의 암호화 격리.

3. 주요 관리 가능성 (생성, 저장, 회전, 취소).

4. 감사성 (키를 언제 사용했는지).

5. 사고시 운영 위험을 최소화합니다.

3) 건축 기초

기본적으로 모든 것을 암호화합니 위험 수준에서 예외없이 옵트 아웃을 허용하지 않습니다.
주요 계층 구조 (엔벨로프 암호화). 루트/KEK → DEK (데이터 암호화 키) → 데이터베이스 객체/파일/페이지.
신뢰의 원천으로서의 KMS/HSM. KMS/HSM의 KEK 생성 및 스토리지, 키 포장/배포 작업이 수행됩니다.
테넌트/데이터 세트 당 키. 격리 및 회전 요구 사항에 대한 세분성.
의무 분리. 플랫폼 명령은 테넌트 키 소유자입니다. 최소 권한 (PoLP).
암호화 민첩성. 알고리즘/키 길이를 안전하게 마이그레이션하는 기능.
이벤트가 아닌 프로세스로서의 회전. 키와 데이터는 "롤링" 교체를 지원해야합니다.

4) 암호화 알고리즘 및 모드

객체/파일/레코드: AES-256-GCM 또는 AES-256-SIV (인증 기능이있는 AEAD).
블록 장치/볼륨의 경우: AES-XTS-256/512 (블록 순열에 대한 보호; AEAD가 아님-무결성이 중요한 MAC의 파일 형식을 사용하십시오).

데이터베이스의 경

TDE (투명 데이터 암호화)

필드/라인 암호화 (FPE/결정 론적 암호화) - 암호화 된 필드의 검색 기능/조인 용; 신중하게 적용하십시오.
주요 생성 및 스토리지: KEK-KMS/HSM에서; 저장하는 동안 수명이 짧은 응용 프로그램 메모리에서 DEK는 포장 된 것입니다.

5) 핵심 계층 및 KMS/HSM

1. 루트 키 (법정, HSM/KMS). HSM/KMS 경계를 떠나지 않습니다.

2. KEK (키 암호화 키). 프로젝트/환경/테넌트. DEK 수명주기를 관리합니다.

3. DEK (데이터 암호화 키). 객체/파일/테이블/세그먼트당. 수명이 짧고 회전하는 논스톱.

• 모든 포장/배포 작업은 감사와 함께 KMS API를 통해 이루어집니다.
• 정치인: 키를 "제어" 할 수있는 키를 "사용" 할 수있는 사람.
• 주요 지리 분포: 지역 간 핀투 지역 + 이중 제어.
• 위험이 높은 작업에는 "2 점검" 모델 (2 명의 연산자) 이 가능합니다.
• 세입자 당 별도의 키 링을 강력하게 분리합니다.

6) 회전, 리콜 및 준수

DEK 회전: 투명하고 일정합니다 (객체/페이지 레벨에서 재 암호화 롤링).
KEK 회전: 주기적 (예: 6-12 개월마다) + 손상된 것으로 의심되는 경우 즉시 리콜.
액세스 취소: KMS 정책을 통한; 랩 해제 작업 차단 = 데이터의 즉각적인 "암호화 구축성".
감사 기록: 언제 어떤 권리가 열쇠를 사용했는지; 별도로 저장하고 암호화하십시오.
규정 및 표준: 업계 요구 사항 (예: GDPR/PCI 허가/로컬 규제 기관) 에 중점을두고 인증 된 암호화 모듈 (예: 인증 수준 준수 준수) 을 사용합니다.

7) 저장 유형별 패턴

7. 1 블록/파일 볼륨 및 VM/컨테이너

KMS를 통한 전체 디스크 암호화 (XTS) + 키 관리 (마운트 중 볼륨 초기화).
교체, 충돌 덤프, tmp 디렉토리, 컨테이너 오버레이 레이어 및/AMI 이미지를 보호하십시오.
스냅 샷/스냅 샷-항상 별도의 DEK로 암호화됩니다.

7. 2 개체 저장소

봉투 암호화: 객체당 고유 한 DEK; 헤더/메타 데이터 - PII 누출 없음.
세입자 및 환경에 의해 KMS 키에 대한 액세스를 제어합니다.
서버 측 암호화 (자체 KMS가있는 SSE) 또는 클라이언트 측 (CSE) -트러스트 모델에 따라 선택하십시오.

7. 데이터베이스 3 개

사용 가능한 경우 TDE 사용; 플러그인/확장을 통해 데이터베이스 키를 KMS에 바인딩합니

특히 민감한 필드-데이터베이스에 입력하기 전에 응용 프로그램 암호화 (AEAD)

재실행 로그/트랜잭션 로그, 아카이브 로그, 덤프-개별적으로 암호화, 키-분리.

7. 4 개의 로그/트레일/메트릭

기본적으로 민감한 데이터가없는 로그 형식 (위생).
로그 아카이브-별도의 키 및 짧은 TTL 스토리지.
A&A 및 감사를 통한 프록시 서비스를 통한 로그 읽기 액세스.

7. 백업 및 오프라인 미디어 5 개

테이프/클라우드에 쓰기 전에 항상 클라이언트에서 암호화합니다.
별도의 제어 기능이있는 에스크로를 별도로 (대역 외) 저장하십시오.
비상 사태의 경우 비밀 (예: m-of-n) 을 분할하여 마스터 액세스를 복원하십시오.

8) 멀티 테넌트

세입자의 열쇠: KEK-per-Tennent + DEK-per-dataset.
정책 격리: KMS 네임 스페이스, IAM 경계, 개별 IDP 역할.
클라이언트의 요청에 따라 제거: "암호 지우기" -임차인의 KEK를 철회하고 DEK를 파괴하십시오.
클라이언트보고: 규정 준수 아티팩트, 주요 액세스 로그, 회전 확인.

9) 성능 및 운영

하드웨어 가속 (AES-NI/x86, ARMv8 크립토 확장).
핫 경로 프로파일 링: I/O 경계에서 암호화하고 불필요하게 이중 암호화를 피하십시오.
KMS 세션 풀, 캐싱 포장 된 DEK 메모리 (TTL 및 덤프 보호 포함).
SLO/메트릭: 포장 해제 대기 시간, "재 암호화 된" 객체의 비율, KMS 오류, 백업 암호화 속도.

10) 참조 런북

0 단계-데이터 인벤토리. 모든 리포지토리 및 누출 경로 (tmp, 덤프, 수출, 분석 버킷) 를 카탈로그합니다.
1 단계-핵심 계층 구조 설계. 우리는 KEK/DEK 수준, 세분성, 지역, 역할을 결정합니다.
2 단계-모드/라이브러리를 선택하십시오. 승인 된 알고리즘, 암호화 라이브러리, 버전 정책.
3 단계-KMS/HSM과의 통합. 세대/포장/감사, IAM 정책, 지오 피닝.

4 단계-쓰기 당 암호화. 기본적으로 배경 재 암호화를 통한 기존 데이터 마이그레이션을 사용하십시오

5 단계-회전 및 비상 시나리오. 규정, "키 타협" 테스트, "KMS를 사용할 수 없습니다".
6 단계-모니터링 및 감사. 대시 보드, 경고, 정기 준수 보고서.
7 단계 - 훈련 및 "보안 코딩. "엔지니어를위한 가이드, 로그/덤프에 비밀을 표시하는 것을 금지합니다.

11) 테스트 및 검증

암호화 장치 테스트: AEAD의 정확성 (태그 확인), 바이트 변경시 고장 검증.
실패 테스트: 오래된 키 버전 인 KMS를 비활성화하면 KEK가 취소되었습니다.
빨간색/파란색 테스트: "원시" 디스크/스냅 샷/백업을 읽으려고 시도합니다.
호환성 검사: 알고리즘/키 길이의 마이그레이션 (암호화 민첩성).
라이브러리 증명: 검증 된 암호화 모듈 만 사용하십시오. 커밋 버전.

12) 빈번한 실수와 피하는 방법

의미없는 이중 암호화. 추가 대기 시간과 복잡성. 원하는 세분성과 격리를 제공하는 층을 유지하십시오.
데이터 옆에 키를 저장합니다. 키는 항상 다른 액세스 모델에서 분리되어 있습니다.

잊혀진 유물. 암호화되지 않은 임시 파일, CS 내보내기, 덤프 지원. CI/CD 및 데이터 손실 방지에서 모니터링 사용

회전 부족. 수동 절차가 아닌 파이프 라인/크론의 회전 부분을 만드십시오.
민감한 데이터가있는 로그. 로그 형식 및 자동 소독제 계약을 입력하십시오.

13) 미니 레시피 (의사 코드)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) 점검표

• 모든 스토리지 유형에서 기본 암호화가 활성화됩니다.
• 주요 계층 구조가 설명되고 구현됩니다. 역할 및 IAM 정책이 구성됩니다.
• KMS/HSM 통합 주요 운영 감사가 활성화되었습니다.
• DEK/KEK 회전이 자동화됩니다. 타협 시나리오가 해결되었습
• 백업, 스냅 샷, 로그 및 덤프-암호화; 키는 별도로 저장됩니다.
• KMS 오류, AEAD 태그 편차, 암호화되지 않은 아티팩트 비율에 대한 경고 설정.
• KMS 사용 불가능 및 주요 취소 테스트가 통과되었습니다.

• 주요 사용 및 액세스 시도에 대한 월간 보고서.
• 통증없는 알고리즘 마이그레이션을위한 암호화 민첩성 계획 및 창.
• 원시 매체에서 데이터를 추출하는 정기 적색 팀.

15) Q&A (FAQ)

Q: 전체 디스크 암호화가 충분합니까?
A: 물리적 위험의 경우-그렇습니다. 그러나 세입자를 격리하고 유연한 회전을 위해 DEK-on-천체/세트로 더 나은 봉투.

Q: KEK가 손상되면 어떻게해야합니까?
A: 즉시 KEK를 KMS에 리콜하고, 새로운 것을 다시 릴리스하고, 모든 DEK를 다시 포장하고, 로그를 확인하고 RCA를 실행하십시오.

Q: 찾고있는 필드를 어떻게 암호화합니까?
A: 엄격한 위험 평가 (패턴 렉) 에서만 결정 론적 체계 또는 FPE를 사용하십시오. 민감한 필드에 색인화 된 개방형 뷰가 필요하지 않도록 쿼리를 설계하는 것이 좋습니다.

Q: 키에 대한 별도의 명령이 필요합니까?
A: Crypto/KMS 운영자는 별도의 권리와 절차를 가진 역할로 권장됩니다.

• "키 관리 및 회전"
• "S2S 인증"
• "서명 및 확인 요청"
• "커널에서 OAuth2/OpenID 연결"
• "웹훅 배송 보증"