Trebuie păstrat secret ID-ul contului AWS? Se poate face ceva folosind doar ID-ul contului AWS?
Din documentația AWS :
ID-ul contului AWS este un număr din 12 cifre, cum ar fi 123456789012, pe care îl utilizați pentru a construi numele de resurse Amazon (ARN). Când vă referiți la resurse, cum ar fi un utilizator IAM sau un seif Amazon Glacier, ID-ul contului vă distinge resursele de resursele din alte conturi AWS.
Răspuns
Un ID de cont AWS poate fi partajat, atunci când este necesar.
Așa cum spune documentația, principalul lucru pe care oricine îl poate folosi este AWS Numărul de cont pentru este să construiască ARN. De exemplu, dacă aș avea un cont AWS care deținea o funcție AWS Lambda și cineva dintr-un alt cont, căruia i-am acordat explicit permisiunea, ar dori să îl manipuleze, l-ar folosi după cont numărul din ARN.
arn:aws:lambda:us-east-1:123456789012:function:ProcessKinesisRecords Din nou, acest lucru este total limitat de permisiunile aplicate în contul dvs. Chiar dacă am avut un ARN complet, cu excepția cazului în care Acces la contul AWS, nu voi putea face nimic cu el.
Cheile API sunt lucrurile care acordă controlul de la distanță a lucrurilor și sunt periculoase.
Comentarii
- Este corect. AWS vă permite acum să partajați straturi lambda disponibile public, care sunt partajate prin ARN-uri care conțin ID-ul contului dvs. Deși este întotdeauna mai bine să nu partajați nimic, cu excepția cazului în care trebuie să faceți acest lucru – trebuie doar să distribuiți ID-ul contului dvs. sub forma unui ARN.
Răspundeți
Cunoașterea unui ID de cont AWS nu vă expune la niciun atac în sine, dar poate face mai ușor pentru un atacator obținerea altor informații compromițătoare.
Rhino Security Laboratoarele demonstrează un potențial vector de compromis prin roluri IAM neconfigurate într-o postare de blog aici :
ID-urile de cont AWS identifică în mod unic fiecare cont AWS și sunt mai sensibile decât s-ar putea crede. În timp ce divulgarea ID-ului nu expune în mod direct un cont la compromisuri, un atacator poate folosi aceste informații în alte atacuri. Ar trebui depus un efort rezonabil pentru a păstra AWS ID-urile contului sunt private, dar în practică, acestea sunt adesea expuse publicului neintenționat.
[…]
Această postare – și scriptul însoțitor pe care l-am lansat – se adresează usi un ID cont AWS pentru a identifica rolurile existente. Ca o extensie a acestui concept, atacatorii pot face un pas mai departe și își pot asuma roluri IAM neconfigurate pentru a obține acces neautorizat.
Acest lucru va fi eficient doar în cazul în cazul în care un utilizator permite asumarea rolului din * sau dintr-o gamă prea largă de resurse, dar din experiențele mele permisiunile IAM sunt complexe și rezonabil de greu de auditat bine, iar atacurile de acest fel sunt greu de detectat:
Această tehnică și acest script de forțare brută vor genera o cantitate mare de jurnale „iam: AssumeRole” CloudTrail în contul pe care îl utilizați pentru enumerare. Orice cont pe care îl vizați nu va vedea nimic în jurnalele sale CloudTrail până când nu vă asumați cu succes un rol configurat greșit, deci înseamnă că enumerarea nu este complet înregistrată în contul țintă.
Cu alte cuvinte – nu este un risc intrinsec, dar reduce în mod semnificativ suprafața de atac a contului dvs. pentru a păstra ID-ul în afara publicului.
Comentarii
- Am ' am citit și eu acel articol, că postarea înfrumusețează puțin lucrurile, aveau nevoie să aibă un cred IAM real + actul AWS. I ' spune dacă cineva are un login la acțiune ' intră deja în joc în funcție de tipul de situație. Scurgerea ID-ului de acțiune AWS cu greu a precipitat atacul.