비밀 관리

1) 왜 그리고 우리가 정확히 "비밀" 로 간주하는 것

비밀-공개가 시스템 또는 데이터를 손상시키는 모든 자료: 암호, API 토큰, OAuth/JWT 개인 키, SSH 키, 인증서, 암호화 키 (KEK/DEK), 웹 후크 서명 키, DSN 데이터베이스/캐시, 공급 업체 키 (결제, 메일/SMS 제공 업체), 쿠키 소금/후추, 봇 토큰 토큰, 라이름.
비밀은 코드, 설정, 환경, 컨테이너 이미지, CI/CD, Terraform/Ansible, 로그/덤프-비밀 관리 작업: 계정 → 스토리지 → 전달 → 사용 → 회전 → 응답 → 감사 → 활용에 있습니다.

2) 건축 원칙

중앙화. 저장, 발급 및 감사를위한 하나의 신뢰할 수있는 계층 (Vault/Cloud Secret Manager/KMS).
최소 특권 (PoLP). 최소 기간 동안 필요한 서비스/역할에만 액세스하십시오.
짧은 인생. TTL/lease의 동적/시간 비밀이 선호됩니다.
암호화 민첩성. 다운 타임없이 알고리즘/키 길이를 변경하는 기능.
코드/이미지에서 비밀을 분리합니다. 리포지토리에 암호가없고 Docker 이미지가 없습니다.
관찰 및 감사. 발행/읽기 비밀의 각 작업이 기록되고 삭제됩니다.
자동 회전. 회전은 수동 조치가 아닌 파이프 라인 프로세스입니다.

3) 전형적인 솔루션 및 구성 요소 역할

KMS/HSM. 루트 트러스트, 암호화/키 포장 작업 (봉투).
비밀 관리자/금고. 비밀 버전 저장소, ACL, 감사, 동적 비밀 (DB, 클라우드 -IAM, PKI), 회전 템플릿.
PKI/CA. 수명이 짧은 mSL/SS/JWT 서명 발행.
요원/사이드카. 런타임으로 비밀을 전달합니다 (tmpfs, in-memory k/v, 핫 재 장전 파일).
CSI 드라이버/운영자. Kubernetes와의 통합 (Secret Store CSI Driver, 인증 관리자).
Git의 암호화 계층. SOPS/age, git-crypt (인프라 코드 용).

4) 분류 및 정책

중요도 (P0/P1/P2) 및 손상량 (테넌트 범위, 환경 범위, 조직 전체) 별도의 비밀. 각 클래스마다 다음을 지정하십시오

TTL/임대 및 회전 주파수;

출력 방법 (역학 대 정적), 형식, 매체;

액세스 정책 (누가/어디서/언제/왜), mSL 및 상호 인증 요구 사항;

감사 (우리가 얼마나 많이 저장하고 누가 검토하는지 기록);

브레이크 글래스 절차 및 리콜.

5) 비밀 수명주기

1. 생성: 메타 데이터 (소유자, 태그, 범위) 가있는 비밀 관리자 API를 통해.
2. 스토리지: 암호화 (엔벨로프: KMS/HSM의 KEK로 감싼 DEK).
3. 배송: 승인 된 엔티티 (OIDC/JWT, SPIFFE/SVID, mSL) 의 요청에 따라.
4. 사용: 독점적으로 메모리/tmpfs에서; 벌목/덤프 금지.

5. 회전: TTL 또는 이벤트 별 (타협); 병렬 버전 지원 (N-1)

6. 리콜/차단: 대상 시스템의 임대, 계정/키 장애가 즉시 만료됩니다.
7. 처분: 버전/재료, 명확한 감사 체인의 파괴.

6) 동적 비밀 (기본적으로 권장)

아이디어: 비밀은 짧은 시간 동안 발행되며 자동으로 만료됩니다. 예:

TTL 15-60 분의 데이터베이스 자격 증명 (Postgres/MySQL).
서비스 역할별 임시 클라우드 키 (AWS/GCP/Azure).
SS 인증서 (5-30 분), 함수 인증서 (시간/일).
서명 요청, 세션 티켓 중개인을위한 임시 JWT.
장점: 최소한의 폭발 반경, 단순화 된 리콜 (세계에는 아무것도 남아 있지 않습니다).

7) 런타임에 비밀 전달

쿠 베르네 테스:

Secret Store CSI Driver → 외부 관리자로부터 파일로 포드로 비밀을 설치합니다 (tmpfs).
Kubernetes Secret을 유일한 소스로 피하십시오 (base64 환경 암호화). 필요한 경우 etcd에 KMS 공급자를 활성화하십시오.
자동 임대 임대 및 핫 재 장전 기능이있는 사이드카 에이전트 (Vault Agent/Secrets Store).
VM/Bare-metal: Vault/Secret Manager의 시스템 에이전트 + mTLS, 메모리 캐시, 최소 TCB.
서버리스: 환경 변수/파일로 비밀을 투명하게 대체하는 클라우드 통합이지만 오래 지속되는 엔바를 피하십시오 (바람직하게는 파일/인 메모리).

예 (Kubernetes + CSI, 개념적으로)

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8) CI/CD 및 IaC 통합

CI: OIDC (Workroad Identity) 에 따라 근로자는 단기 토큰을받습니다. 통나무에 들어가는 "마스크 된" 비밀을 금지하십시오. 단계 "누설 스캔" (trufflehog/gitleaks).
CD: 배포는 디스플레이 시점에 비밀을 취하고 아티팩트에 기록하지 않습니다.
IaC: Terraform은 Secret Manager에 변수를 저장합니다. 상태가 암호화되고 액세스가 제한됩니다.
SOPS/age: KMS의 제어하에 repos (저장 암호화 된 표현, 키) 의 경우.

예 (SOPS 단편)

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9) 액세스 정책 및 워크로드 인증

워크로드 아이덴티티: SPIFFE/SPIRE, Kubernetes SA → OIDC → IAM-ро독점, mTLS.
임시 토큰: 짧은 TTL, 좁은 범위.
비밀 관리자의 ABAC/RBAC: "Y 환경에서 X 비밀을 읽을 수있는 사람" 은 "생성/회전 할 수있는 사람" 과 분리되어 있습니다.
멀티 테넌시: 테넌트 당 별도의 네임 스페이스/키 링이 있습니다. 개별 정책 및보고.

10) 회전, 버전 및 호환성

비밀 ID와 해당 버전 ('비밀/앱/db # v17') 을 분리하십시오.
논스톱 회전을 위해 두 가지 활성 버전 (N 및 N-1) 을 지원합니다.
회전은 이벤트 기반입니다. 해고, 타협, 공급자 변경, 알고리즘 마이그레이션.
자동화: Vault/비밀 관리자 + 웹 후크 트리거에서 크론/백엔드 회전으로 응용 프로그램 재시작/번역.

미니 레시피 "2 키" 웹훅 회전

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11) 오프 런타임 스토리지: 백업 및 아티팩트

아티팩트 (이미지, 로그 아카이브, 덤프) 에 들어 가지 마십시오.
비밀 관리자 백업-암호화, 동일한 루프 외부의 스토리지 키 (작업 분리).
태그 및 DLP 스캔: S3/Blob/GCS, Git, CI 아티팩트의 비밀 탐지.

12) 관찰 가능성, 감사 및 SLO

지표: 문제 수/비밀/서비스, 만료 된 임대 비율, 평균 TTL, 회전 시간, 수렴 시간 (새 버전을 "수락" 하기 몇 초/분 전).
감사 로그: 누가/무엇/언제/어디서/왜; 별도로 저장하고 암호화하십시오.
SLO: 99% 출력 <200 ms; 로그에 0 누출; 비밀의 100% 에는 소유자/TTL/태그가 있습니다. 100% 중요한 비밀-동적 또는 회전 약 30 일.
경고: 비밀은 <7 일 (정적), 인증 오류 저장, 비밀 읽기> N 일 (죽음), 예기치 않은 지오/ASN 소스가 만료됩니다.

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

Git/이미지의 비밀. SOPS/age 및 스캐너 사용; "베어" 라인을 금지하는 정책.
장기 매체로서의 Envvars. tmpfs/in-memory 파일을 선호합니다. 포크/덤프에서 환경을 청소하십시오.
v/stage/prod에 대한 동일한 비밀. 환경별로 나눕니다.
수명이 긴 정적 암호. 동적/수명으로 전환하십시오.
모든 것을위한 단일 마스터 키 ". "임차인/프로젝트/서비스로 나눕니다.
뜨거운 재 장전이 없습니다. 응용 프로그램은 회전 중에 취약점 창을 다시 시작해야합니다.

14) 통합의 예 (회로도)

Vault 다이나믹 포스트 그레스 액세스

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

요청의 JWT 서명 (단기)

개인 키는 비밀 관리자에 저장됩니다. 서비스는 단기 서명 토큰을 요청하고 로컬 에이전트는 페이로드에 서명합니다 (키는 문자열로 응용 프로그램에 전달되지 않음).

관리자에 대한 <> SSH 인증서

영구 키를 배포하지 않고 SSO (OIDC) 를 통해 10 분 동안 SSH- 인증을 발급합니다.

15) 가장자리 주위의 안전

로그/트레일/메트릭: 소독제, 알려진 키/패턴에 대한 필터; "비밀" 필드-APM으로 마스킹.
덤프/충돌 보고서: 기본적으로 삭감; 필요한 경우-암호화 및 청소.
클라이언트 응용 프로그램/모바일: 오프라인 비밀을 최소화하고 플랫폼 스토리지 (키 체인/키 스토어) 를 사용하며 장치 바인딩, 비상 롤링을 통한 TLS 피닝.

16) 준수

PCI DSS: 암호화없이 PAN/비밀 저장을 금지합니다. 엄격한 액세스 제어 및 회전.

ISO 27001/SOC 2-자산 관리, 로깅, 액세스 제어, 재구성 요구 사항

GDPR/로컬 규제 기관: 최소화, 필요에 따른 액세스, 감사.

17) 프로세스 및 런북

커미셔닝

1. 비밀 목록 (리포지토리, CI, 이미지, 런타임, 백업).
2. 분류 및 태그 (소유자, 환경, 테넌트, 회전 정책).
3. Vault/Cloud SM + KMS/HSM 통합.
4. 워크로드 아이덴티티 (OIDC/SPIRE) 별로 출력을 설정합니다.

5. DB/Cloud/PKI의 동적 비밀 사용

6. 자동 회전 및 핫 재 장전; 만료시 경고.
7. 누출 스캐너 및 데이터 카탈로그/ET 설정.

비상 시나리오

의심되는 누출: 액세스 정지 목록, 즉시 회전, 인증서/키 철회, 토큰 재발행, 감사 증가, RCA 가능.
TTL이 낮은 메모리의 로컬 캐시, 기능 저하, 새로운 연결 제한, 수동 브레이크 글래스 단계 등 비밀 관리자를 사용할 수 없습니다.
루트 키 타협: 키 계층 구조 재생, 모든 DEK 재 포장, 위험 창의 모든 노출 확인.

18) 점검표

판매하기 전에

코드/이미지에서 제거 된 비밀; 누출 스캐너가 포함되었습니다.
중요한 비밀을 위해 동적 메커니즘이 활성화되어 있습니다
뜨거운 재 장전, 내구성있는 엔바가없는 사이드카/CSI/tmpf를 통한 배달.
워크로드 아이덴티티로 구성된 IAM/ABAC 정책.
호환성을위한 자동 회전 및 이중 버전 (N, N-1).
메트릭/알림/감사 활성화; 분해 테스트가 통과되었습니

작동

월간 보고서: 소유자, TTL, 만료 된 비밀, 미사용.
누출 경로 (로그, 덤프, 아티팩트) 의 정기 회전 및 침투 테스트.
암호화 민첩성 계획 및 CA/루트의 긴급 교체.

19) FAQ

Q: KMS가없는 비밀 관리자입니까?
A: 기본 수준의 경우-예, 그러나 봉투 암호화를 사용하는 것이 좋습니다: KMS/HSM의 KEK, 비밀-포장. 이것은 피드백과 준수를 단순화합니다.

Q: 무엇을 선택해야합니까? 정적 또는 역학?
A: 기본값은 역학입니다. 지원되는 공급자가없는 경우에만 정적으로 유지하고 최대 일/시간 + 자동 회전까지 TTL을 연소하십시오.

Q: 비밀을 마이크로 서비스에 안전하게 던지는 방법?
원격: 워크로드 아이덴티티 → mTLS 비밀 관리자 → 사이드카/CSI → 로그도없고 "영원히" Envvar도 없습니다.

Q: Kubernetes Secret에 비밀을 유지할 수 있습니까?
A: KMS 제공 업체 및 엄격한 정책을 사용하여 etcd 암호화 만 가능합니다. 외부 스토리지 및 CSI를 선호합니다.

Q: 임차인의 액세스를 어떻게 "암호화" 합니까?
A: Secret Manager에서 정책을 취소/차단하고 모든 임대, 주요 회전/재생을 무효화합니다. KMS를 사용할 때-해당 KEK의 랩을 비활성화하십시오.

비밀 관리

비밀 관리

예 (Kubernetes + CSI, 개념적으로)

예 (SOPS 단편)

미니 레시피 "2 키" 웹훅 회전

요청의 JWT 서명 (단기)

작동

문의하기

빠른 연결

영상이 곧 업데이트됩니다

현재 프로젝트로 매우 바쁜 상태입니다