S3 Înregistrează problema evenimentului

Există vreo modalitate de a vedea ce acțiuni efectuează utilizatorul IAM „g2” în S3 și de pe ce IP-uri rulează? Am activat deja înregistrarea acțiunilor S3.

Un punct pe care încă nu reușesc să-mi dau seama este că atunci când încerc să găsesc jurnalele în Cloud trail folosind o cheie de acces AWS sau un nume de utilizator în ambele cazuri, obțin rezultate ca Fără potriviri. Dar de-a lungul zilei acel utilizator (g2) interacționează cu S3, pe baza orelor în care se pare că este un CRON care rulează pe un server. Cum să-l identifici?

Am analizat istoricul evenimentelor CloudTrail și am folosit CloudWatch Logs Insights pentru a afla adresa IP de înregistrare a accesului timp de 90 de zile utilizând atât „nume de utilizator”, cât și „Cheie de acces AWS”, dar se pare că nu este prea mult. ajutor pentru găsirea datelor utilizatorului âg2â. Utilizatorul âg2â IAM are acces de administrator. Utilizatorul nu are acces la managementul consolei. Bănuiesc că face doar un „ls” pentru a verifica existența unor fișiere. Cred că aceleași acțiuni vor avea loc în fiecare zi pentru asta

Știu data/ora la care utilizatorul execută și resursa (S3), dar asta este tot (fără bucket, fără IP, etc). Putem face ceva cu aceste informații?

Am testat deja aceste interogări, dar nu am reușit să obțin rezultatul 

    câmpurile @timestamp, eventName, eventType, requestParameters.bucketName, requestParameters.key, resources.0.ARN
    | filtru sursăIPAddress == „xx.xx.xx.xx” și userIdentity.sessionContext.sessionIssuer.userName == „g2” și eventSource == „s3.amazonaws.com”
    | sort @timestamp desc
    | limita 100

    câmpurile @timestamp, @message
    | filtru userIdentity.userName == „g2”
    | sort @timestamp desc
    | limita 20

    câmpurile @timestamp, @message
    | filtru sursăIPAddress == „192.168.1.1”
    | sort @timestamp desc
    | limita 20
    â

Interogarea Athena a CloudTrail Logs poate fi utilă? Instrumentul CLI, jurnalul CloudTrail va fi util pentru scenariul meu? Ma poate ajuta cineva cu asta?

Am creat un nou Trail pentru a testa asta. Procesul a fost acesta:

1. Creați un nou CloudTrail, permițând livrarea către CloudWatch așa cum a sugerat @Tim și, de asemenea, activați Data Events pe S3. Poate doriți doar să activați Data Events pe S3 și să filtrați pentru găleata în cauză, altfel ați putea genera o mulțime de jurnale!
2. Am copiat unele fișiere într-o găleată de test (foo.txt)
3. CloudWatch -> Grupuri de jurnal -> Grupul meu -> „Afișează în statistici de jurnal”

Odată ce încep să sosească jurnalele, pot face cu ușurință următoarele:

Găsiți utilizare de pe IP-ul meu (dacă știți că IP-ul înlocuiește 192.168.1.1):

câmpurile @timestamp, @message
| filtru sursăIPAddress == „192.168.1.1”
| sort @timestamp desc
| limita 20

Găsiți activitate din rolul pe care mi-l asum:

câmpurile @timestamp, @message
| filtru userIdentity.sessionContext.sessionIssuer.userName == „Administrator”
| sort @timestamp desc
| limita 20

Apoi pot extinde oricare dintre rânduri cu săgeata din stânga pentru a găsi mai multe câmpuri utile. Orice câmp poate fi adăugat la câmpuri listă pentru a se afișa frumos, de ex. utilizați IP & Rol & Service pentru a restrânge o căutare și a afișa informații utile:

câmpurile @timestamp, eventName, eventType, requestParameters.bucketName, requestParameters.key, resources.0.ARN
| filtru sourceIPAddress == „xx.xx.xx.xx” și userIdentity.sessionContext.sessionIssuer.userName == „Admin” și eventSource == „s3.amazonaws.com”
| sort @timestamp desc
| limita 100

Actualizare rapidă: m-am conectat la contul meu de stocare de rezervă, pentru a găsi un utilizator IAM real, cheia este:

filtru userIdentity.userName == „iam-user-name”