Sota el model de responsabilitat compartida d'AWS, mentre que AWS gestiona la «Seguretat DEL Núvol» (centres de dades físics, maquinari amfitrió, hipervisors), el client manté la responsabilitat total de la «Seguretat AL Núvol» —específicament la governança de la identitat, la higiene de les credencials i el control d'accés. El compromís d'un compte Root d'AWS sense restriccions o d'una credencial d'IAM amb privilegis permet als atacants desplegar milers de dòlars en instàncies GPU il·lícites per a mineria de criptomonedes, exfiltrar llacs de dades privats a S3 o executar eliminacions catastròfiques de dades per rescat (ransomware).
El MFA és obligatori per a tots els usuaris de la consola d'administració i innegociable per al compte Root d'AWS.
AWS permet registrar fins a 8 testimonis FIDO2 i TOTP virtuals diferents per compte, eliminant els punts únics de fallada.
Una política de denegació condicional global d'IAM bloqueja totes les crides a l'API no autoritzades fins que es valida el MFA actiu.
Línies base de compliment al núvol: CIS Benchmark i marcs regulatoris
Tant si la vostra organització d'enginyeria cerca la conformitat amb SOC 2 Type II, la certificació ISO 27001, la validació PCI DSS 4.0 o l'alineació amb el pilar de seguretat d'AWS Well-Architected, la implementació de MFA a totes les identitats d'IAM és un requisit fonamental de bloqueig:
| Estàndard / Norma de compliment | Especificació del control | Gravetat / Obligació | Mecanisme de validació d'auditoria |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Nivell 1 (Obligatori) | Avaluació automatitzada amb AWS Security Hub / Prowler |
| PCI DSS 4.0 | Requisit 8.4.2 | Obligatori | Auditoria de consola i API a l'Entorn de Dades de Titulars de Targetes (CDE) |
| SOC 2 Type II (Criteris de confiança) | CC6.1 / CC6.2 | Control clau | Inspecció independent per part de censors jurats de comptes (CPA) dels informes de credencials d'IAM |
| Desplegament obligatori de MFA d'AWS | Política d'AWS 2024–2026 | Aplicació de la plataforma | Bloqueig de la passarel·la d'inici de sessió de Root fins a completar el registre de MFA |
L'imperatiu absolut de protegir el compte Root d'AWS
Dins dels límits d'un compte d'AWS, el compte Root representa la identitat omnipotent creada en el moment de la seva constitució. A diferència dels rols o usuaris d'IAM, les accions del compte Root no es poden restringir mitjançant polítiques basades en la identitat d'IAM ni mitjançant polítiques de control de serveis (SCP) en comptes independents.
Radi d'impacte catastròfic d'un compte Root compromès:
- Tancament irreversible del compte: Els atacants poden fer clic a «Tanca el compte», programant la destrucció permanent de tota la infraestructura.
- Segrest financer i de facturació: Redirigir factures, substituir les targetes de pagament corporatives i desplegar centenars d'instàncies spot de GPU a més de 30 regions d'AWS per minar criptomonedes il·lícitament.
- Desarticulació de l'estructura d'AWS Organizations: Eliminar comptes membres dels arbres de gestió, desmantellant la monitorització de compliment organitzatiu.
- Modificació dels contactes principals de seguretat: Modificar els registres de correu i telèfon de root talla permanentment els canals oficials d'intervenció del suport d'AWS.
- Zero claus d'accés per a Root: Auditeu els informes de credencials d'IAM per confirmar que no existeixen claus d'accés (Access Keys) per al compte Root. Si n'hi ha, elimineu-les immediatament.
- Custòdia compartida de la contrasenya: Genereu una contrasenya aleatòria de més de 32 caràcters, dividiu la frase de pas entre el responsable de seguretat (CISO) i el departament jurídic, i guardeu les parts en caixes fortes físiques ignífugues.
- Redundància de múltiples dispositius (fins a 8 dispositius): Registreu com a mínim dues claus físiques de maquinari FIDO2 (YubiKeys) més un dispositiu TOTP virtual secundari desconnectat i emmagatzemat en fred.
Matriu de selecció de MFA: TOTP virtual vs. FIDO2 de maquinari (YubiKey)
AWS admet tres classes principals de dispositius MFA. Els arquitectes de núvol han d'alinear la selecció segons els models d'amenaça i els nivells de privilegis administratius:
Aplicacions TOTP virtuals
Testimonis estàndard segons l'RFC 6238 (Google Authenticator, 1Password, 2FA-Tool). Incorporació ràpida, sense friccions d'adquisició. Ideal per a desenvolupadors estàndard.
Sèrie YubiKey 5
Criptografia resistent al phishing. Les assercions de clau pública vinculades a l'origen frustren els conjunts d'eines de phishing per servidor intermediari invers. Obligatori per a Root i administradors.
Targetes Gemalto / Thales
Targeta TOTP autònoma, aïllada físicament (air-gapped) amb pantalla LCD. Essencial per a instal·lacions segures aïllades (SCIF) on es prohibeixen els telèfons intel·ligents i les claus USB.
MFA de maquinari empresarial FIPS 140-2 Nivell 3 i protocols de caixa forta amb custòdia compartida:
Per a les empreses de Fortune 500 i els contractistes de defensa, la seguretat del compte Root exigeix claus físiques dedicades (per exemple, clauers SafeNet/Gemalto IDPrime) certificades sota FIPS 140-2 Nivell 3. A diferència de les aplicacions per a telèfons intel·ligents, aquests clauers físics no disposen d'interfícies sense fil, ni ràdios Bluetooth, i no es poden interceptar mitjançant programari espia mòbil.
Governança física de doble custòdia: En els protocols de centres de dades empresarials, l'accés a Root requereix dues persones diferents: un custodi té les credencials del correu principal, mentre que un oficial de seguretat independent té la clau física d'una caixa forta que conté el testimoni de maquinari de Root. Cap de les dues parts no pot accedir al compte Root d'AWS de manera unilateral.
Aplicació de MFA mitjançant polítiques IAM (implementació JSON)
Les línies base de seguretat no poden dependre de l'acció voluntària dels empleats. La governança al núvol requereix una aplicació a nivell de polítiques: els usuaris sense autenticació MFA activa han de tenir denegades sistemàticament totes les accions a l'API i a la consola d'AWS, excepte la capacitat d'autoregistrar el seu propi dispositiu MFA.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "BlockAllAccessUnlessMFAAuthenticated",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"iam:GetUser"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
La declaració 4 avalua la clau de condició global "aws:MultiFactorAuthPresent": "false" utilitzant una denegació explícita (Deny). Com que una denegació explícita preval sobre qualsevol declaració d'autorització (Allow), les sessions sense MFA es bloquegen immediatament a totes les API d'AWS, canalitzant l'usuari directament cap a la pantalla d'autoregistre.
Autenticació MFA per a AWS CLI i SDK: testimonis de sessió temporals d'STS
Quan les polítiques d'IAM apliquen l'ús obligatori de MFA, els desenvolupadors que executin ordres com ara aws s3 ls o executin codi de Terraform rebran errors de tipus AccessDenied. Les claus d'accés a llarg termini no poden sol·licitar codis OTP de manera interactiva.
Els enginyers han d'utilitzar AWS STS (Security Token Service) per intercanviar les claus a llarg termini + un testimoni TOTP de 6 dígits per credencials efímeres:
Script d'automatització (aws-mfa-session.sh):
Deseu aquest script d'ajuda al vostre entorn local (~/.aws/aws-mfa-session.sh) per automatitzar l'obtenció del testimoni:
# Intercanvi de claus a llarg termini d'AWS + codi MFA per un testimoni de sessió STS
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Introduïu el codi 2FA OTP de 6 dígits: "
read -r TOKEN_CODE
SESSION_JSON=$(aws sts get-session-token \
--serial-number "$MFA_ARN" \
--token-code "$TOKEN_CODE" \
--duration-seconds 43200 \
--output json)
if [ $? -eq 0 ]; then
export AWS_ACCESS_KEY_ID=$(echo "$SESSION_JSON" | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo "$SESSION_JSON" | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo "$SESSION_JSON" | jq -r '.Credentials.SessionToken')
echo "✅ Autenticat! Sessió temporal exportada (vàlida durant 12 hores)."
else
echo "❌ L'autenticació ha fallat. Comproveu el codi del testimoni o la desviació horària del dispositiu."
fi
AssumeRole entre comptes amb restriccions de MFA
En arquitectures empresarials amb múltiples comptes, els enginyers amb privilegis solen autenticar-se en un compte centralitzat d'identitat (Identity) i pivotar cap als comptes de destinació (Producció, Staging) mitjançant sts:AssumeRole. Per assegurar-se que els permisos elevats de producció no es poden segrestar mitjançant credencials filtrades, la relació de confiança del rol de producció ha d'aplicar una condició de MFA:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Aquest patró d'arquitectura garanteix que, fins i tot si un atacant compromet les credencials del compte central d'identitat, qualsevol intent d'assumir el rol de destinació sense satisfer el MFA generarà immediatament un error d'AccessDenied al límit del testimoni de seguretat.
Auditoria amb CloudTrail i alertes en temps real d'EventBridge
La validació automatitzada del compliment requereix una detecció immediata quan qualsevol usuari accedeix a la consola de gestió d'AWS sense autenticació multifactor. En capturar els esdeveniments d'AWS CloudTrail i encaminar-los a través d'Amazon EventBridge, els equips de SecOps aconsegueixen alertes en temps real:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
En rebre l'esdeveniment, EventBridge activa una notificació d'Amazon SNS al dispositiu de guàrdia del Centre d'Operacions de Seguretat (SOC) o invoca una funció d'AWS Lambda que revoca immediatament la sessió activa de l'usuari d'IAM.
Governança multicompte: AWS Organizations i IAM Identity Center
En entorns empresarials que gestionen desenes o centenars de comptes d'AWS mitjançant Landing Zones, aprovisionar usuaris d'IAM individuals a cada compte és un antipatró.
Federació centralitzada d'identitats:
Desplegueu AWS IAM Identity Center (abans AWS SSO) al vostre compte de gestió (Management Account) designat. Federeu les identitats amb els proveïdors d'identitat (IdP) corporatius (Okta, Microsoft Entra ID, PingFederate). Apliqueu el MFA corporatiu al nivell de l'IdP, mentre vinculeu polítiques de control de serveis (SCP) a l'arrel de l'organització per denegar accions de root als membres:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
SCP per a entorns de producció: Aplicació de restriccions de MFA a tots els comptes membres
A les grans organitzacions, els administradors de comptes individuals poden atorgar privilegis excessius sense voler. En vincular una política de control de serveis (SCP, Service Control Policy) a l'arrel de l'organització o al nivell de la unitat organitzativa (OU), l'equip de governança del núvol estableix una barrera de seguretat immutable: les crides a l'API d'alt impacte es deneguen incondicionalment llevat que s'autoritzin mitjançant una sessió de MFA activa:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCriticalActionsWithoutMFA",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:CreateLoginProfile",
"s3:DeleteBucket",
"kms:ScheduleKeyDeletion",
"ec2:TerminateInstances"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
Encadenament de rols i límits de durada dels testimonis STS:
Quan les identitats d'IAM assumeixen rols intermedis que posteriorment assumeixen rols secundaris («encadenament de rols» o role chaining), AWS STS elimina el context original d'aws:MultiFactorAuthPresent del testimoni de la sessió derivada! Per mantenir un compliment estricte de punta a punta a través de fluxos entre comptes, dissenyeu grafs d'assumpció de rols directament des de la sessió autenticada d'IAM Identity Center en lloc d'encadenar múltiples rols d'IAM intermedis.
Recuperació davant desastres: protocol per pèrdua del dispositiu MFA de Root
Què passa si tots els testimonis de maquinari i dispositius virtuals de MFA registrats per a Root es destrueixen en una catàstrofe?
Seqüència oficial de recuperació fora de banda:
- Inicieu la sessió com a Root: Introduïu el correu electrònic del compte Root i la contrasenya mestra a la consola d'AWS.
- Resoleu problemes de MFA: A la sol·licitud de MFA, feu clic a «Troubleshoot MFA» (Resolució de problemes de MFA).
- Verificació del correu principal: AWS envia un enllaç de verificació amb límit de temps a l'adreça de correu principal de Root. Valideu el desafiament del correu.
- Desafiament de veu automatitzat: Feu clic a «Call me now» (Truca'm ara). El sistema automatitzat de verificació d'AWS truca al número de telèfon principal registrat al compte i recita un PIN de confirmació de 6 dígits.
Si la vostra organització ha canviat de número de telèfon o la persona de contacte ha marxat de l'empresa sense actualitzar la configuració del compte d'AWS, la recuperació automatitzada fallarà. La resolució manual requereix presentar escriptures de registre corporatives compulsades davant de notari a l'equip d'AWS Trust & Safety, amb un temps de revisió d'entre 3 i 7 dies laborables.
Preguntes freqüents per a arquitectes de núvol empresarial
Es poden compartir testimonis de MFA de Root d'AWS dins d'un equip de DevOps? ▼
Està estrictament prohibit. Compartir credencials de MFA de Root incompleix totes les auditories de compliment (SOC 2, ISO 27001). L'administració rutinària ha de canalitzar-se mitjançant rols d'IAM Identity Center amb responsabilitat individual. Les credencials de Root han de romandre tancades en caixes fortes físiques sota doble custòdia, exclusivament per a situacions catastròfiques d'emergència (break-glass).
Com millora la seguretat la clau de condició aws:MultiFactorAuthAge? ▼
Aquesta clau aplica la frescor de la sessió. Configurar "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} exigeix que el testimoni de MFA s'hagi presentat durant els 3.600 segons anteriors (1 hora). Les accions d'alt risc (com ara eliminar clústers de RDS) es bloquejaran si la sessió és més antiga, protegint contra el segrest de sessions de llarga durada.
Puc utilitzar l'autenticador en línia de 2FA-Tool per configurar el MFA virtual d'AWS? ▼
Sí. El MFA virtual d'AWS compleix estrictament les especificacions TOTP de l'RFC 6238 (HMAC-SHA1, interval de 30 segons, 6 dígits). Podeu introduir la cadena secreta en Base32 a 2FA-Tool.com per generar els dos codis d'autenticació consecutius requerits per al registre, de forma 100% local al vostre navegador.
Proveu testimonis TOTP empresarials de forma segura
Genereu codis de verificació TOTP estàndard segons l'RFC 6238 a l'instant amb l'API Web Crypto del W3C. Sense crides a servidors, aïllament absolut en memòria i zero filtracions.