Folosește AWS Organizations cu conturi separate per mediu și workload

Această practică implică utilizarea serviciului AWS Organizations pentru a gestiona centralizat un set de conturi AWS distincte, alocând câte un cont pentru fiecare mediu (de exemplu, Development, Staging, Production) sau pentru workload-uri critice. Separarea la nivel de cont oferă izolare naturală a costurilor, permisiunilor și a datelor, reducând drastic riscul de „drift” de configurare sau acces neautorizat între echipe. Dacă ignori această abordare și menții totul într-un singur cont, o greșeală umană simplă, cum ar fi ștergerea accidentală a bazei de date de producție, poate afecta întregul ecosistem, iar auditarea devine haotică și imprecisă.

Cum o aplici

1. Creează un cont „Management” (sau „Payer”) în AWS Organizations pentru a centraliza facturarea și politica de securitate.
2. Folosește AWS Control Tower sau CLI pentru a genera automat conturi noi în organizație.
3. Alocă fiecare cont nou unui „OU” (Organizational Unit) specific, precum Production sau Development.
4. Aplica SCPs (Service Control Policies) la nivel de OU pentru a restricționa acțiunile permise (ex: interzice ștergerea resurselor critice în Prod).
5. Configurează IAM Roles cu permisiuni limitate pentru utilizatorii din fiecare cont, asigurându-te că nu există acces cross-account implicit fără verificare explicită.

Exemplu

Configurația greșită presupune definirea tuturor resurselor într-un singur cont, unde un developer are drepturi AdministratorAccess:

// Greșit: Permisiuni excesive într-un cont monolitic
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Configurația corectă folosește o SCP la nivel de OU pentru a bloca acțiuni periculoase în mediul de producție:

// Corect: Restricție la nivel de organizație pentru Production OU
{
  "Effect": "Deny",
  "Action": [
    "ec2:TerminateInstances",
    "rds:DeleteDBInstance"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalOrgID": "o-abc123"
    }
  }
}

Cum verifici

Verifică vizual structura în consola AWS Organizations pentru a te asigura că conturile sunt distribuite corect în OUs. Utilizează comanda aws organizations list-accounts pentru a valida numărul și starea conturilor. Pentru securitate, rulează simulări IAM Policy Simulator pentru a confirma că o acțiune interzisă (ex: DeleteDBInstance) este respinsă în contul de Production, chiar dacă utilizatorul are drepturi de admin în acel cont specific. Monitorizează rapoartele de costuri AWS Cost Explorer filtrate pe tag-ul aws:PrincipalOrgPath pentru a vedea dacă cheltuielile sunt clare și separate.

Greșeli frecvente

1. Supraîncărcarea conturilor: Crearea unui cont separat pentru fiecare microserviciu duce la o gestionare infernală; este mai bine să grupezi serviciile afine în același cont.
2. Ignorarea transferului de costuri: Uitat să configurezi AWS Budgets și alertele de cost la nivel de cont, ceea ce duce la facturi surpriză neidentificate rapid.
3. Complexitatea IAM: Subestimarea efortului de a gestiona identități și permisiuni între conturi; începe cu politici simple și extinde treptat, evitând accesul direct între conturi fără necesitate.