Practica „Conturi și organizare” se referă la separarea logică a resurselor AWS în conturi distincte, grupate pe baza mediului (dev, staging, prod) sau a departamentului, gestionate centralizat. Ignorarea acestei structuri duce rapid la „bloated accounts”, unde permisiunile devin haotice, costurile sunt greu de alocat și riscul de securitate crește exponențial. Un singur cont pentru tot proiectul transformă orice eroare umană într-o potențială catastrofă operațională, afectând toate echipările și serviciile dependente.
Cum o aplici
- Definirea structurii: Creează conturi separate pentru fiecare mediu critic. Folosește AWS Organizations pentru a le gestiona ierarhic.
- Politici SCP: Aplică Service Control Policies la nivel de organizație sau unitate organizatorică pentru a restricționa acțiunile periculoase (ex: ștergerea VPC-urilor în dev).
- Identitatea Centralizată: Folosește AWS IAM Identity Center (fostul SSO) pentru a gestiona accesul utilizatorilor peste toate conturile, evitând crearea de utilizatori IAM locali redundanți.
- Etichetare (Tagging): Impune o strategie strictă de etichetare (ex:
Environment,CostCenter) pentru a facilita raportarea costurilor și identificarea resurselor.
Exemplu
În loc să ai un singur cont cu toate resursele amestecate, folosește AWS Organizations.
Varianta greșită:
Toate resursele (inclusiv cele de producție) într-un singur cont AWS ID: 123456789012. Utilizatorii au drepturi AdministratorAccess direct pe acel cont.
Varianta corectă: O structură de tip „Sandbox” sau „Landing Zone”:
- Contul
OrganizationRoot- OU
Security(contul principal de audit) - OU
Development- Cont
Dev-Account(permisiuni limitate, SCP care blochează zonele premium)
- Cont
- OU
Production- Cont
Prod-Account(SCP strict, acces doar prin pipeline-uri CI/CD)
- Cont
- OU
// Exemplu SCP pentru a bloca ștergerea resurselor critice în contul de Prod
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:Delete*",
"rds:Delete*"
],
"Resource": "*"
}
]
}
Cum verifici
- AWS Cost Explorer: Verifică dacă costurile sunt clare și alocate corect pe conturi/etagete.
- IAM Access Analyzer: Identifică resursele expuse public sau cu permisiuni excesive.
- AWS Config Rules: Rulează reguli automate pentru a detecta deviațiile de la standardele de securitate (ex: „s3-bucket-public-read-prohibited”).
- Audit Logs: Analizează CloudTrail pentru a vedea cine a efectuat modificări sensibile și din ce cont.
Greșeli frecvente
- Prea multe conturi mici: Creezi un cont pentru fiecare microserviciu, ceea ce crește complexitatea administrativă fără beneficii reale de izolare.
- Ignorarea SCP-urilor: Permiți utilizatorilor drepturi de administrator în conturile non-producție, riscând ștergerea accidentală a infrastructurii de bază.
- Lipsa automatizării: Creezi conturile manual prin consolă. Trebuie să folosești Terraform sau AWS Control Tower pentru reproducibilitate și audit.
Resurse gratuite
Subteme
- Folosește AWS Organizations cu conturi separate per mediu și workload
- Creează un landing zone cu AWS Control Tower
- Grupează conturile în OU-uri (Security, Workloads, Sandbox)
- Aplică guardrails cu Service Control Policies (SCP)
- Protejează utilizatorul root cu MFA și nu-l folosi zilnic
- Centralizează gestionarea accesului root pentru conturile membre
- Centralizează logurile într-un cont dedicat de Log Archive
- Configurează contactele alternative pentru billing, operațiuni și securitate
- Restricționează regiunile permise prin SCP