Managementul secret

Managementul secret

1) De ce și ce anume considerăm un „secret”

Secret - orice material a cărui dezvăluire duce la compromiterea sistemului sau a datelor: parole, jetoane API, chei private OAuth/JWT, chei SSH, certificate, chei de criptare (KEK/DEK), chei de semnătură webhook, baze de date/cache DSN, chei furnizor (plăți, furnizori de e-mail/SMS), săruri cookie/piper, jetoane bot/chat, licențe.
Secretele trăiesc în cod, o configurație, un mediu, imagini container, CI/CD, Terraform/Ansible, bușteni/dumps - o sarcină de gestionare a secretelor: cont stocare livrare utilizare rotație răspuns audit de utilizare.

2) Principii de arhitectură

Centralizare. Un singur strat de încredere (Vault/Cloud Secret Manager/KMS) pentru stocare, emitere și audit.
Cele mai mici privilegii (PoLP). Acces numai la serviciile/rolurile necesare, pe o perioada minima.
Viaţă scurtă. Sunt preferate secretele dinamice/de timp cu TTL/leasing.
Cripto-agilitate. Abilitatea de a schimba algoritmii/lungimile cheii fără întreruperi.
Separarea secretelor de cod/imagini. Fără parole în depozite, fără imagini Docker.
Observabilitate și audit. Fiecare operațiune de eliberare/citire a secretelor este înregistrată și ștearsă.
Rotaţie automată. Rotația este un proces în conductă, nu o acțiune manuală.

3) Soluții tipice și roluri componente

KMS/HSM. Root trust, operațiuni de criptare/ambalare a cheilor (plic).
Secret Manager/Vault. Magazin de versiuni secrete, ACL, audit, secrete dinamice (DB, cloud-IAM, PKI), șabloane de rotație.
PKI/CA. Emiterea semnăturilor mTLS/SSH/JWT de scurtă durată.
Agent/ataş. Livrarea secretelor în timpul rulării (tmpfs, in-memory k/v, fișiere de reîncărcare la cald).
Șoferi/operatori CSI. Integrarea cu Kubernetes (Secret Store CSI Driver, cert-manager).
Strat de criptare în Git. SOPS/age, git-crypt (pentru codul de infrastructură).

4) Clasificarea și politica

• TTL/frecvență de închiriere și rotație;
• metoda de ieșire (dinamică vs statică), format, media;
• politica de acces (cine/unde/când/de ce), mTLS și cerințele de autentificare reciprocă;
• audit (pe care îl înregistrăm cât de mult stocăm, cine recenzează);
• proceduri de spargere a sticlei și rechemări.

5) Ciclul de viață secret

1. Creare: prin API-ul Secret Manager cu metadate (proprietar, etichete, domeniu de aplicare).
2. Stocare: criptat (plic: DEK învelit cu KEK de la KMS/HSM).
3. Livrare: la cererea unei entități autorizate (OIDC/JWT, SPIFFE/SVID, mTLS).
4. Utilizare: exclusiv în memorie/în tmpfs; interzicerea exploatării forestiere.

5. Rotație: prin TTL sau eveniment (compromis); Suport pentru versiuni paralele (N-1)

6. Rechemare/blocare: expirarea imediată a contractului de leasing, dezactivarea contului/cheii în sistemul țintă.
7. Eliminarea: distrugerea versiunilor/materialelor, lanțul de audit clar.

6) Secretele dinamice (recomandate în mod implicit)

• Acreditări de baze de date (Postgres/MySQL) cu TTL 15-60 min.
• Chei temporare nor (AWS/GCP/Azure) de rol de serviciu.
• Certificate SSH (5-30 minute), certificate X.509 (oră/zi).
• JWT temporar pentru semnarea cererilor, sesiune de bilete de brokeri.
• Pro: rază minimă de explozie, rechemare simplificată (nimic nu va „rămâne” în lume).

7) Livrarea secretelor în timpul rulării

• Secret Store CSI Driver → de montare secrete de la un manager extern la pod ca fișiere (tmpfs).
• Evitați Kubernetes Secret ca singura sursă (base64 ≠ criptare); Dacă este necesar, activați furnizorul KMS pentru etcd.
• Agent lateral (Vault Agent/Secrets Store) cu închiriere auto-renevală și reîncărcare la cald.
• VM/Bare-metal: agent de sistem + mTLS la Vault/Secret Manager, memorie cache, TCB minim.
• Serverless: integrarea în cloud cu substituirea transparentă a secretelor ca variabile/fișiere de mediu, dar evitați envvars de lungă durată - de preferință fișiere/în memorie.

Exemplu (Kubernetes + CSI, conceptual)

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) integrări CI/CD și IaC

CI: lucrătorii primesc jetoane de scurtă durată conform OIDC (Workload Identity). Interzicerea secretelor „mascate” care intră în jurnale; etapa „scanare a scurgerilor” (trufflehog/gitleaks).
CD: Implementarea ia secrete în momentul afișării, nu le scrie în artefacte.
IaC: Terraform stochează variabile în Secret Manager; statul este criptat și accesul restricționat.
SOPS/vârstă: pentru repo - stocați manifeste criptate, chei - sub controlul KMS.

Exemplu (fragment 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) Politicile de acces și autentificarea volumului de muncă

Identitatea volumului de lucru: SPIFFE/SPIRE, Kubernetes SA→OIDC→IAM - роль, mTLS.
Jetoane temporare: scurt TTL, domeniul de aplicare îngust.
ABAC/RBAC în Secret Manager: „cine poate citi secretul X în mediul Y” este separat de „cine poate crea/roti”.
Multi-chirie: spații de nume separate/inele-cheie pe chiriaș; politicile individuale și raportarea.

10) Rotație, versiuni și compatibilitate

Separați ID-ul secret și versiunea sa ('secret/app/db # v17').
Suportă două versiuni active (N și N-1) pentru rotație non-stop.
Rotația se bazează pe evenimente: pe concediere, compromis, schimbarea furnizorului, migrarea algoritmilor.
Automatizați: rotația cron/backend în declanșatoarele Vault/Secret Manager + webhook pentru repornirea/reneval aplicației.

Mini rețetă „cu două taste” rotație cârlig web

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) stocare off-runtime: backup-uri și artefacte

Nu intra în artefacte (imagini, arhive jurnal, dumps).
Backup-uri Secret Manager - criptare, chei de stocare în afara aceleiași bucle (separarea sarcinilor).
Etichete și scanări DLP: detectarea secretelor în S3/Blob/GCS, Git, artefacte CI.

12) Observabilitate, audit și SLO

Valori: numărul de probleme/secret/serviciu, cota de leasing expirat, media TTL, timpul de rotație, timpul de convergență (secunde/minute înainte de a „accepta” noua versiune).
Jurnale de audit: cine/ce/când/unde/de ce; stocare separat, de asemenea, criptate.
SLO: 99% putere <200 ms; 0 scurgeri în jurnale; 100% din secrete au proprietar/TTL/tag-uri; 100% secrete critice - dinamice sau de rotație ≤ 30 de zile.
Alerte: secretul expiră <7 zile (pentru static), spike în eșecuri de autentificare la stocare, nici un secret citește> N zile (mort), surse neașteptate geo/ASN.

13) Greșeli frecvente și cum să le evitați

Secrete în Git/imagini. Utilizați SOPS/vârstă și scanere; politica de interzicere a liniilor „goale”.
Envvars ca un mediu pe termen lung. Acordați preferință fișierelor tmpfs/in-memory; curățați mediul la furculițe/halde.
Aceleași secrete pentru dev/stage/prod. Împărțiți în funcție de mediu.
Parole statice de lungă durată. Treceți la dinamic/de scurtă durată.
O singură cheie principală "pentru orice. "Împărțiți pe chiriași/proiect/serviciu.
Fără reîncărcare la cald. Aplicația necesită o repornire → ferestrei de vulnerabilitate în timpul rotației.

14) Exemple de integrări (schematice)

Acces dinamic la seif Postgres

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)

Semnarea JWT a cererilor (pe termen scurt)

Cheia privată este stocată în Secret Manager; serviciul solicită un semnătură de scurtă durată, iar agentul local semnează sarcina utilă (cheia nu este trecută în aplicație ca șir).

Certificate SSH pentru administratori

Emiterea SSH-cert timp de 10 minute prin SSO (OIDC), fără a distribui chei permanente.

15) Siguranță în jurul marginilor

Busteni/trasee/metrici: dezinfectanti, filtre pentru chei/modele cunoscute; câmpuri „secrete” - mascarea în APM.
Dumps/Crash Reports: Taie în mod implicit; dacă este necesar - cripta și curat.
Aplicații client/mobil: minimizați secretele offline, utilizați stocarea platformei (Keychain/Keystore), legarea dispozitivului, fixarea TLS cu rulare de urgență.

16) Conformitate

PCI DSS: interzice stocarea PAN/secretelor fără criptare; control strict al accesului și rotație.

ISO 27001/SOC 2 - Gestionarea activelor, exploatarea forestieră, controlul accesului, cerințe de reconfigurare

GDPR/autorități locale de reglementare: minimizare, acces după cum este necesar, audit.

17) Procese și runbook

Punerea în funcțiune

1. Inventarul secretelor (depozite, CI-uri, imagini, runtime, backup-uri).
2. Clasificare și etichete (proprietar, mediu, chiriaș, politica de rotație).
3. Integrare Vault/Cloud SM + KMS/HSM.
4. Configurați ieșirea prin identitatea volumului de lucru (OIDC/SPIRE).
5. Activați secretele dinamice pentru DB/Cloud/PKI.
6. Auto-rotație și la cald-reîncărcare; alerte privind expirarea.
7. Configurarea scanerelor de scurgere și a catalogului de date/ET.

Scenarii de urgență

Suspect de scurgere: lista de oprire a accesului, rotație imediată, revocarea certificatelor/cheilor, re-emiterea jetoanelor, permite creșterea auditului, RCA.
Secret Manager nu este disponibil: cache local în memorie cu TTL scăzut, degradarea funcției, restricționarea conexiunilor noi, pași manuali de spargere a sticlei.
Compromisul cheie: regenerarea ierarhiei cheie, refacerea tuturor DEK-urilor, verificarea tuturor expunerilor pentru fereastra de risc.

18) Liste de verificare

Înainte de vânzare

• Secretele eliminate din cod/imagini; scanere de scurgere incluse.
• Mecanismele dinamice sunt activate pentru secretele critice.
• Livrare prin sidecar/CSI/tmpfs cu reîncărcare la cald, fără envvars durabile.
• Politicile IAM/ABAC configurate, legate de identitatea volumului de lucru.
• Auto-rotație și versiuni duale (N, N-1) pentru compatibilitate.
• Metrica/alerte/audituri activate; testele de degradare au trecut.

Funcționare

• Raport lunar: proprietari, TTL, secrete expirate, neutilizate.
• Rotații periodice și teste de penetrare a căilor de scurgere (bușteni, halde, artefacte).
• planul de cripto-agilitate și înlocuirea de urgență a CA/rădăcini.

19) ÎNTREBĂRI FRECVENTE

Î: Este managerul secret fără KMS suficient?
R: Pentru nivelul de bază - da, dar este mai bine să utilizați criptarea plicului: KEK în KMS/HSM, secretele - înfășurate. Acest lucru simplifică feedback-ul și conformitatea.

Î: Ce să alegeți - static sau dinamic?
R: Dinamica implicită este. Lăsați static numai în cazul în care nu există furnizori acceptați și ardeți TTL până la zile/ore + rotație automată.

Î: Cum să aruncați în siguranță secretele în microservice?
: Identitatea volumului de lucru mTLS Secret Manager sidecar/CSI tmpfs + încărcare la cald. Fără buşteni, fără envvaruri „pentru totdeauna”.

Î: Pot păstra secrete în Kubernetes Secret?
R: Numai cu criptarea etcd activată cu furnizorul KMS și politici stricte. Preferați stocarea externă și CSI.

Î: Cum „ștergeți cripto” accesul unui chiriaș?
R: Revocați/blocați politicile sale în Secret Manager, invalidați toate contractele de leasing, rotația/regenerarea cheilor; atunci când se utilizează KMS - dezactivați despachetarea KEK corespunzătoare.

• „La criptare de odihnă”
• „În criptarea tranzitului”
• „Managementul și rotația cheilor”
• „Autentificare S2S”
• „Semnează și verifică cererile”