Grupează conturile în OU-uri (Security, Workloads, Sandbox)

Grupează conturile AWS în Organizational Units (OU) logice pentru a aplica politicile de securitate și guvernanța accesului la nivel de ierarhie, nu la fiecare cont individual. Această structură creează o separare clară între mediile de producție, dezvoltare și testare, simplificând managementul permisiunilor și reducând riscul de expunere accidentală a datelor sensibile. Dacă ignori această practică, vei avea un „haos” de conturi izolate, unde aplicarea manuală a regulilor de securitate devine imposibilă de scalat, crescând exponențial riscul de configurări incorecte și vulnerabilități.

Cum o aplici

1. Creează o structură ierarhică în AWS Organizations bazată pe ciclul de viață al aplicației și funcționalitate.
2. Definește OU-uri principale precum Security (pentru conturile de logging/monitoring centralizat), Workloads (pentru producție) și Sandbox (pentru experimente).
3. Asociază Service Control Policies (SCPs) cu fiecare OU pentru a restricționa acțiunile permise la acel nivel.
4. Migrează sau creează conturi noi direct în OU-urile corespunzătoare, asigurându-te că etichetele (tags) reflectă apartenența.

Exemplu

O structură incorectă ar plasa toate conturile de dezvoltare și producție în rădăcina organizației (r-xxxx), fără nicio separare.

Structura corectă ar arăta astfel:

Root (r-123456)
├── OU: Security (SCP: Blochează ștergerea CloudTrail)
│   └── Cont: Audit-Account
├── OU: Workloads (SCP: Restricționează regiunile la eu-central-1)
│   ├── Cont: Prod-Frontend
│   └── Cont: Prod-Backend
└── OU: Sandbox (SCP: Limită costuri și servicii)
    └── Cont: Dev-Test-User1

În acest exemplu, SCP-ul aplicat pe OU-ul Workloads va preveni orice cont din acea ramură să lanseze instanțe în regiuni neautorizate, indiferent de cine este utilizatorul final.

Cum verifici

Folosește comanda AWS CLI aws organizations list-roots pentru a vizualiza topologia organizației. Verifică politicile atașate fiecărui OU folosind aws organizations list-policies --filter SERVICE_CONTROL_POLICY. Pentru validare, încearcă să execuți o acțiune restricționată (de ex., activarea unui serviciu interzis într-un cont din Sandbox) și confirmă că primești o eroare de permisiune (AccessDenied).

Greșeli frecvente

• Over-engineering: Crearea unei ierarhii prea adânci (mai mult de 3-4 niveluri) care complică administrarea fără a aduce beneficii clare de securitate.
• Ignorarea migrării: Crearea OU-urilor dar lăsarea conturilor existente în rădăcina organizației, ceea ce anulează beneficiul guvernanței centralizate.
• SCPs prea permissive: Aplicarea unor politici care permit aproape totul, transformând OU-ul într-o simplă etichetă organizatorică fără efect real de control.