Una clau d'accés d'AWS consta de dues cadenes que, juntes, permeten que un programa actuï com un usuari d'IAM: l'ID de clau d'accés, que identifica la clau, i la clau d'accés secreta, que en demostra la possessió. La gent les cerca amb tres noms, access key i secret key, secret access key o simplement AWS secret key, i tots designen el mateix parell. El parell apareix en configuracions de la CLI, en pipelines d'integració contínua i, massa sovint, en un missatge de Slack.
Aquesta guia explica què són les dues meitats, com crear-les i configurar-les, com rotar-les sense aturar el servei, què fer quan se n'escapa una i la pregunta que torna cada vegada que s'incorpora un desenvolupador o comença un contractista: com fer arribar una clau secreta a una persona sense posar-la en un correu.
ID de clau d'accés i clau d'accés secreta
| ID de clau d'accés | Clau d'accés secreta | |
|---|---|---|
| Aspecte | AKIAIOSFODNN7EXAMPLE (20 caràcters) | 40 caràcters amb majúscules, minúscules i símbols |
| Funció | Identifica quina clau signa la sol·licitud | Signa la sol·licitud; demostra que la teniu |
| És secreta? | No, tracteu-la com un nom d'usuari | Sí, tracteu-la com una contrasenya |
| Es pot veure després? | Sí, a la consola d'IAM | Mai després de crear-la |
Les claus de llarga durada comencen per AKIA. Les credencials
temporals d'STS, que també porten un testimoni de sessió, comencen per
ASIA i caduquen soles. Si trobeu una clau ASIA en un fitxer de
configuració, deixarà de funcionar en poques hores, i està pensada
així.
Cap de les dues meitats no dona permisos. La clau s'autentica com un usuari d'IAM, i les polítiques associades a aquest usuari decideixen què pot fer aquella identitat. Una clau filtrada d'un usuari de només lectura és un problema. Una clau filtrada d'un administrador és un incident.
Quan cal realment una clau de llarga durada
La resposta sincera: menys sovint del que es pensa.
- Les càrregues de treball a AWS (EC2, Lambda, ECS, EKS) haurien de fer servir rols d'IAM. L'SDK obté automàticament credencials de curta durada i no hi ha res per rotar ni per filtrar.
- Les persones haurien d'iniciar la sessió amb IAM Identity Center
o amb un inici de sessió únic federat i obtenir credencials temporals
amb
aws sso login. - Els sistemes d'integració contínua, com GitHub Actions, poden assumir un rol mitjançant OIDC sense cap clau desada.
- Les claus de llarga durada queden per als casos que no poden fer res de tot això: una eina en un portàtil sense suport per a l'inici de sessió únic, un servei de tercers que només accepta claus estàtiques, una tasca antiga que encara no heu migrat.
Si en necessiteu una, creeu-la en un usuari d'IAM dedicat amb la política més restringida que permeti fer la feina, i mai en el compte d'administrador d'una persona.
Crear i configurar una clau
A la consola d'IAM, obriu l'usuari, trieu «Security credentials» i després «Create access key». Trieu el cas d'ús que demana AWS, llegiu l'alternativa que us proposa i continueu. El secret es mostra exactament una vegada. Deseu-lo directament al gestor de secrets o al gestor de contrasenyes, o baixeu el CSV i suprimiu-lo després d'importar-lo. Cada usuari d'IAM pot tenir com a màxim dues claus alhora, i això és el que fa possible la rotació.
En una màquina, configureu un perfil amb nom en lloc del perfil per defecte:
aws configure --profile deploy-tool
# AWS Access Key ID [None]: AKIA...
# AWS Secret Access Key [None]: ...
# Default region name [None]: eu-west-1
Això escriu ~/.aws/credentials i ~/.aws/config. Restringiu el
fitxer al vostre usuari amb chmod 600. Per a contenidors i
integració contínua, injecteu AWS_ACCESS_KEY_ID i
AWS_SECRET_ACCESS_KEY com a secrets des del magatzem de la
plataforma, no com a variables en text pla en un fitxer YAML, i no les
passeu mai en una línia d'ordres, perquè acaben a l'historial de
l'intèrpret d'ordres.
Rotar sense trencar res
La rotació és una seqüència de quatre passos, possible gràcies al límit de dues claus.
- Creeu la segona clau al mateix usuari.
- Actualitzeu tots els consumidors perquè facin servir la clau nova: configuracions, secrets de la integració contínua, l'entrada del gestor de secrets. La consola d'IAM mostra quan es va fer servir cada clau per última vegada, i així sabeu si se us n'ha escapat cap.
- Desactiveu la clau antiga. Espereu un dia o un cicle de desplegament. Si alguna cosa falla, torneu-la a activar, corregiu el consumidor i torneu-ho a provar.
- Suprimiu la clau antiga quan ja no la faci servir res.
Feu-ho periòdicament per a les claus que hagin d'existir, i davant de qualsevol esdeveniment per a totes: una baixa, un canvi de proveïdor, un portàtil perdut, una sospita de filtració. AWS Config i IAM Access Analyzer poden assenyalar les claus més antigues del que permet la vostra política.
Quan una clau queda exposada
Considereu compromesa qualsevol clau que hagi aparegut en un repositori, un registre, un tiquet o un xat, encara que s'hagi suprimit un minut després. Els escàners troben els secrets publicats en qüestió de segons.
- Desactiveu la clau a IAM ara mateix. No espereu a crear primer la substituta, tret que la interrupció sigui pitjor que l'exposició.
- Creeu-ne una de substituta i actualitzeu els consumidors.
- Llegiu CloudTrail per veure totes les accions fetes amb aquell ID de clau d'accés des de l'exposició. Busqueu usuaris o claus d'IAM nous, instàncies noves, polítiques de bucket modificades i regions que no reconegueu.
- Reviseu la factura i Cost Explorer per si hi ha pics de despesa amb la forma típica de la mineria de criptomonedes.
- Traieu el secret del codi, dels registres i de l'historial de
git. AWS mateix pot associar la política
AWSCompromisedKeyQuarantinea l'usuari quan detecta una filtració pública; deixeu-la on és fins que hàgiu acabat la neteja. - Suprimiu la clau antiga i després esbrineu per on hi va arribar i tanqueu aquella via.
Com compartir una clau secreta d'AWS amb una persona
De vegades la clau ha d'arribar a una persona: un contractista que la necessita per a una eina de desplegament, un desenvolupador que entra en un projecte abans que s'hagi configurat l'inici de sessió únic, una integració d'un proveïdor que demana enganxar-la al seu tauler. El correu, Slack i els tiquets en conserven còpies, i un secret de 40 caràcters es pot llegir durant anys en qualsevol d'aquests llocs.
El procediment segur porta un minut:
- Creeu una clau per a aquella persona en un usuari d'IAM dedicat, amb la política que necessita la seva tasca i res més. No compartiu una clau que faci servir cap altra cosa.
- Enganxeu només la clau d'accés secreta en un enllaç secret d'un sol ús. Es xifra al vostre navegador abans de desar-se, la còpia desada es destrueix la primera vegada que s'obre l'enllaç, i l'enllaç caduca al cap d'una hora, un dia o una setmana si ningú no l'obre.
- Envieu l'enllaç amb una línia de context. Envieu l'ID de clau d'accés, la regió i el nom del perfil en un missatge a part; cap d'aquestes dades no és secreta per si sola.
- Afegiu una frase de contrasenya amb un compte Pro per a qualsevol clau que no sigui de només lectura, i comuniqueu-la per SMS o en una trucada.
- Confirmeu que l'han obert. Si l'enllaç indica que ja s'ha vist i la persona no l'ha obert, desactiveu la clau i torneu a començar.
- Desactiveu la clau quan acabi l'encàrrec, i suprimiu-la després.
La guia sobre claus d'API aplica el mateix patró a altres proveïdors, i la guia sobre compartir enllaços de manera segura per a desenvolupadors explica com automatitzar el lliurament amb scripts durant la incorporació.