Tard o d'hora, tots els equips arriben al punt en què les credencials són en
massa llocs: un .env a cada portàtil, un missatge fixat a Slack, un full de
càlcul que es diu «accessos», una variable de CI que algú va definir fa dos
anys. Un gestor de secrets al núvol serveix per reunir tot això en un sol
lloc xifrat, amb control d'accés i auditat.
Aquesta guia explica què fa un gestor de secrets al núvol, com triar entre les opcions principals, com implantar-lo sense una migració llarga i l'única feina que no fa: fer arribar un secret a una persona que no és dins del vostre compte al núvol.
Què fa un gestor de secrets al núvol
Un gestor de secrets desa valors confidencials i els lliura a les identitats autoritzades quan els demanen. Les funcions bàsiques són les mateixes a tots els proveïdors:
- Emmagatzematge xifrat de les dades desades, amb les claus al servei de gestió de claus del proveïdor, i TLS durant la transmissió.
- Accés basat en la identitat: cada secret té una política que indica quins usuaris, rols o càrregues de treball el poden llegir, modificar o rotar. Una aplicació s'autentica amb la seva pròpia identitat, no amb una contrasenya mestra.
- Registre d'auditoria de cada lectura, escriptura i rotació, amb qui, què i quan.
- Versions i rotació: es pot preparar un valor nou, fer que les aplicacions hi passin i retirar la versió antiga. Molts gestors roten automàticament les credencials de les bases de dades.
- Obtenció en temps d'execució: l'aplicació obté el secret quan s'inicia o quan el necessita, de manera que el valor no s'escriu mai al codi, a les imatges ni als fitxers de configuració.
Un secret és qualsevol cosa que dona accés. La configuració que només descriu un comportament, com un número de port o un indicador de funció, va a la configuració normal. Barrejar-les omple de soroll el magatzem de secrets i fa perillós el de configuració.
Com triar-ne un
La decisió sol dependre d'on s'executen les càrregues de treball i del nombre de núvols que feu servir.
| Opció | Encaixa millor amb | Atenció a |
|---|---|---|
| AWS Secrets Manager / Parameter Store | Càrregues de treball que ja són a AWS, identitats IAM arreu | Preu per secret a Secrets Manager; Parameter Store és més barat per a valors simples |
| Google Secret Manager | Projectes de GCP, càrregues de treball a Cloud Run i GKE | Opcions de replicació regional |
| Azure Key Vault | Càrregues de treball a Azure, gestió del cicle de vida dels certificats | Caixes fortes separades per entorn perquè les polítiques siguin simples |
| HashiCorp Vault | Diversos núvols o servidors propis, credencials dinàmiques de curta durada | Haver-lo de gestionar vosaltres, si no feu servir la versió allotjada |
| Doppler, Infisical, 1Password Secrets Automation | Equips petits que volen una sincronització còmoda per a desenvolupadors amb moltes plataformes | Un proveïdor més a la cadena de confiança |
Quatre preguntes resolen la majoria de decisions. S'integra amb les eines de desplegament i l'entorn d'execució sense codi de connexió fet a mida? Les càrregues de treball s'hi poden autenticar amb la identitat que ja tenen? Rota els tipus de credencials que teniu de debò? I els registres d'auditoria arriben allà on ja mira l'equip de seguretat? El preu, les regions i les certificacions de compliment venen després d'aquestes quatre.
Implantar-lo sense un projecte de sis mesos
- Feu inventari i assigneu responsables. Feu la llista de cada secret, on és, què el fa servir i qui en respon. La persona responsable decideix la política de rotació i la llista d'accés.
- Configureu primer les identitats. Creeu els rols o els comptes de servei per a cada càrrega de treball i cada entorn abans de moure cap valor. Les polítiques d'accés del tipus «aquest servei, aquest entorn, només lectura» són precisament l'objectiu.
- Migreu per ordre de risc. Primer les contrasenyes de les bases de dades de producció i les claus de pagament, després les claus d'API de tercers i després tota la resta. Traieu cada valor del codi, de les variables de CI i dels fitxers de configuració a mesura que el moveu, i roteu-lo en entrar, perquè el valor antic ja s'ha copiat per tot arreu.
- Canvieu com les aplicacions llegeixen els secrets. Substituïu els valors escrits al codi i els fitxers d'entorn per una crida a l'SDK del gestor en iniciar-se, o injecteu-los amb la integració nativa de la plataforma.
- Activeu la rotació de tot el que el gestor pugui rotar sol, i escriviu una funció de rotació o un procediment per a la resta.
- Configureu alertes per al que sigui inusual. Una lectura d'un secret des d'una identitat nova, un pic de lectures o una lectura des d'una regió on no desplegueu mereixen un avís a la persona de guàrdia.
Els errors habituals són previsibles: deixar les còpies antigues on eren després de la migració, donar a una càrrega de treball accés de lectura a tot el magatzem en lloc de només als seus secrets i escriure el valor obtingut als registres de l'aplicació.
El buit que un gestor de secrets no cobreix
Un gestor de secrets està pensat per a màquines i per a les persones que són dins del vostre sistema d'identitats. No està pensat per al moment en què una credencial ha d'arribar a algú de fora: un col·laborador extern que necessita una contrasenya temporal d'una base de dades, un client que rep el seu primer accés d'administrador, un enginyer d'un proveïdor que necessita un testimoni per a una tarda, una persona nova el primer dia, abans que tingui el compte d'inici de sessió únic.
Aquests lliuraments passen igualment, i sense una via autoritzada passen per correu i per xat, que és precisament d'on els gestors de secrets havien de treure les credencials. La via autoritzada és un enllaç secret d'un sol ús. El valor es xifra al vostre navegador abans de desar-se, el missatge només porta un enllaç, la còpia desada es destrueix la primera vegada que s'obre l'enllaç i, si ningú no l'obre, l'enllaç caduca al cap d'un temps fixat.
El patró que funciona: el gestor de secrets és el sistema de referència, i l'enllaç d'un sol ús és el mitjà de lliurament quan una persona de fora del sistema necessita un valor una sola vegada. Genereu la credencial, deseu-la al gestor, envieu-la a la persona amb un enllaç d'un sol ús i roteu-la quan se li acabi l'accés. Enllaços secrets o gestors de contrasenyes aplica el mateix raonament al gestor de contrasenyes de l'equip, i la guia sobre les credencials entre equips explica la rutina.
Una llista de comprovació breu
- Cada secret té una persona responsable, una política d'accés i una regla de rotació.
- Les càrregues de treball s'autentiquen amb la seva pròpia identitat, mai amb una clau compartida.
- Després de la migració no queda cap secret al codi, a les imatges, a les variables de CI ni al xat.
- Les lectures es registren en un lloc on algú mira de debò.
- Les persones de fora del sistema d'identitats reben els secrets amb un enllaç d'un sol ús, no amb un missatge.
Feu aquestes cinc coses i el gestor de secrets deixarà de ser un producte que vau comprar i passarà a ser el motiu pel qual les credencials han deixat de filtrar-se.