Puncte:0

Politica compartimentului AWS S3 pentru obținere și încărcare

drapel si

Am două găleți fiecare cu propriile obiective. Până acum nu pot înțelege configurația complicată a setărilor găleții. Se pare că sunt trei lucruri de configurat

  1. Blocați accesul publicului
  2. Politica găleții
  3. ACL

Știu că, dacă opresc (1), tot ceea ce vreau să realizez funcționează. Chiar dacă acestea sunt cele mai lipsite de sens patru setări pe care le-am văzut vreodată (de ce mi-ar păsa să restricționez accesul la o găleată în funcție de momentul în care a fost modificată o politică?)

Se pare că ceea ce adaug la (2) nu prea contează. De exemplu, am o politică care permite numai GetObject, dar pot DeleteObject și PutObject din SDK. Am o altă politică care permite DeleteObject, GetObject și PutObject, dar numai ștergerea funcționează și put aruncă un acces refuzat (de la un cont IAM care are acces administrativ la tot ce este sub soare).

Nici măcar nu știu rostul lui (3). De ce aș vrea vreodată să permit permisiuni orice Utilizator AWS? Oricum..

Am două găleți cu două goluri și nu-mi dau seama combinația de lucruri de făcut.

R: Buchetă publică pentru site-ul web static

Pentru aceasta, am acces public Bock la OFF și o politică de genul acesta (care cred că nu face nimic). Oricine poate vizualiza conținutul compartimentului (bine!), dar această politică nu ar trebui să permită niciun PutObject, dar o face.

{
    „Versiune”: „2012-10-17”,
    „Id”: „Policy1632669906301”,
    "Afirmație": [
        {
            „Sid”: „Stmt1632669869776”,
            „Efect”: „Permite”,
            „Principal”: „*”,
            „Acțiune”: „s3:GetObject”,
            „Resurse”: „arn:aws:s3:::publicwebsite/*”
        }
    ]
}

De ce pot încărca și șterge când este definit doar GetObject?

B: găleată securizată pentru copii de rezervă

Această găleată este pentru aplicația mea pentru a trimite copii de siguranță ale datelor. Deci singurul lucru care ar trebui să poată citi/scrie este aplicația mea. Dar dacă activez Blocarea accesului public, nu pot încărca, dar pot șterge. Din nou, nu are deloc sens. Dacă dezactivez Blocarea accesului public, pot face totul. Aici este politica

{
    „Versiune”: „2012-10-17”,
    „Id”: „Policy1635858319261”,
    "Afirmație": [
        {
            „Sid”: „Stmt1635858317672”,
            „Efect”: „Permite”,
            „Principal”: {
                „AWS”: „arn:aws:iam::XXXXXXXXX:utilizator/utilizator de rezervă”
            },
            "Acțiune": [
                "s3:DeleteObject",
                „s3:GetObject”,
                „s3:PutObject”
            ],
            „Resurse”: „arn:aws:s3:::backups/*”
        }
    ]
}

De ce pot să șterg, dar să nu pun?


În plus, Amazon este ADAMANT despre păstrarea permanentă a blocării accesului public, dar nici măcar nu puteți modifica o politică Bucket dacă aceasta este activată! Aceasta este o nebunie!!!!!!


Iată constatările mele după câteva teste.

Conturile mele sunt ca atare

  1. cont root, proprietar al găleții
  2. Cont IAM (administrator) cu totul administrativ
  3. Cont IAM (Utilizator) fără nicio autoritate de a face nimic

Pentru politicile de grup, consultați-o pe cea de-a doua postată mai sus.

Explorez ce face combinația dintre setările de politică și Blocare acces public. Ei continuă să aibă nici un sens.

Cazul 1

  • Blocați tot accesul public: OFF
  • Politica compartimentului: EMPTY
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate încărca și șterge, utilizatorul nu poate face nimic

Cazul 2

  • Blocați tot accesul public:
    • [x] liste noi de control al accesului
  • Politica compartimentului: EMPTY
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate șterge, dar nu poate încărca, utilizatorul nu poate face nimic

Cazul 3

  • Blocați tot accesul public:
    • [x] liste noi de control al accesului
    • [x] orice liste de control al accesului
  • Politica compartimentului: EMPTY
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate șterge, dar nu poate încărca, utilizatorul nu poate face nimic

Cazul 4

  • Blocați tot accesul public:
    • [x] liste noi de control al accesului
    • [x] orice liste de control al accesului
    • [x] noi politici privind punctele de acces
  • Politica compartimentului: EMPTY
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate șterge, dar nu poate încărca, utilizatorul nu poate face nimic

Cazul 5

  • Blocați tot accesul public: ACTIVAT
  • Politica compartimentului: EMPTY
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate șterge, dar nu poate încărca, utilizatorul nu poate face nimic

Concluzie: Blocarea accesului public atunci când este setată la ON permite totul. Orice altă configurație permite ștergerea (și poate mai mult, cum ar fi get), dar nu pune.


Cazul 6

  • Blocați tot accesul public: OFF
  • Politica compartimentului: Administrator (Obținere/Pune/Ștergere obiect) Utilizator (nimic)
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate încărca și șterge, utilizatorul nu poate face nimic

Cazul 7

  • Blocați tot accesul public:
    • [x] liste noi de control al accesului
  • Politica compartimentului: Administrator (Obținere/Pune/Ștergere obiect) Utilizator (nimic)
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate șterge, utilizatorul nu poate face nimic

Cazul 8

  • Blocați tot accesul public:
    • [x] liste noi de control al accesului
    • [x] orice liste de control al accesului
  • Politica compartimentului: Administrator (Obținere/Pune/Ștergere obiect) Utilizator (nimic)
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate șterge, utilizatorul nu poate face nimic

Cazul 9

  • Blocați tot accesul public:
    • [x] liste noi de control al accesului
    • [x] orice liste de control al accesului
    • [x] noi politici privind punctele de acces
  • Politica compartimentului: Administrator (Obținere/Pune/Ștergere obiect) Utilizator (nimic)
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate șterge, utilizatorul nu poate face nimic

Cazul 10

  • Blocați tot accesul public: ACTIVAT
  • Politica compartimentului: Administrator (Obținere/Pune/Ștergere obiect) Utilizator (nimic)
  • ACL: proprietarul găleții (lista, scrie | citește, scrie)

Rezultat: administratorul poate șterge, utilizatorul nu poate face nimic

Concluzie: Politica găleții nu are literalmente niciun efect asupra nimicului


TLDR: Se pare că politica Bucket nu face nimic.Numai Blocarea accesului public are un efect măsurabil, singura opțiune utilizabilă fiind dezactivarea acestuia. De asemenea, mi-am eliminat politica privind compartimentele din categoria mea publică și, de asemenea, nu s-a schimbat nimic.

Concluzia mea este că fie politica Bucket este încălcată, că documentația nu este suficientă, fie că setările în sine sunt contra-intuitive și nu fac de fapt ceea ce spun. Sau orice combinație de orice.

Prefer să-mi găzduiesc conținutul pe un server FTP în subsolul meu în acest moment.

drapel vn
Ce folosești pentru a pune obiectele? Am văzut biblioteci care necesită nu doar PutObject, ci și PutObjectAcl, de exemplu.
pbuzz007 avatar
drapel si
SDK-ul Node.js
drapel vn
Puteți afișa anumite apeluri utilizate și mesajul de eroare specific primit?
pbuzz007 avatar
drapel si
Nu e nimic cu adevărat. Apelez funcția `s3.upload` furnizată de SDK-ul AWS și primesc eroarea `Access Denied`. Totuși, pot șterge foarte bine.
Tim avatar
drapel gp
Tim
Din păcate, nu avem suficiente informații pentru a vă ajuta aici. Pentru a investiga pe deplin acest lucru, aș dori să văd permisiunile IAM, politica de compartiment, ACL pentru fiecare compartiment, blocarea setărilor de acces public, apoi a rulat comanda CLI și rezultatele. Ar fi mult de lucru.Poate fi complex să rezolvi asta, dar te asigur că funcționează așa cum este documentat. Ați făcut vreo formare AWS? Fie specific pentru securitatea S3, fie chiar mai bine AWS architect associate / AWS security training. AWS este o platformă de întreprindere foarte complexă, oamenii petrec ani de zile învățând-o.
pbuzz007 avatar
drapel si
Am enumerat combinațiile celor trei setări principale de permisiuni ale găleții. Dacă îi iau ani de zile pentru ca cineva să înțeleagă asta, este un fel de ridicol. Vreau doar o grupă privată cu CRUD pentru un utilizator IAM și nimeni altcineva și o grupă cu GET pentru oricine și CRUD pentru un utilizator IAM și nimeni altcineva. Am încercat literalmente toate combinațiile posibile, iar rezultatele sunt aiurea. Blocarea accesului public este una dintre cele mai prost definite și formulate setări pe care mi le pot imagina.
pbuzz007 avatar
drapel si
De asemenea, am enumerat fiecare lucru pe care l-ați cerut, inclusiv setările IAM (Admin = totul, Utilizator = nimic). Comenzile sunt rulate de la Node JS SDK și rezultatele sunt pur și simplu „Acces refuzat” sau succes, punct. Sincer, nu e mare lucru. Pur și simplu nu funcționează așa cum este descris. Politicile nu funcționează corect.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.