Avalike S3, Azure Blob ja GCS salvestuste leidmine ühe pärastlõunaga

Igal kolmel suurel pilveplatvormil on üksikutest bucketitest kõrgemal lüliti, mis alistab kõik, mida keegi on selle all seadistanud. Teie pärastlõunal on kaks ülesannet: leida üles see, mis on juba avatud, ja seejärel need lülitid sisse lülitada, et järgmine hooletu poliitika midagi ei mõjutaks. Tehke seda just selles järjekorras, sest lülitid rikuvad kõik, mis sõltub avalikkusest.

Mida tähendab "avalik" igal platvormil

Definitsioonid erinevad ning audit peab otsima igaüht neist.

S3 käsitleb bucketi poliitikat avalikuna, kuni pole tõestatud vastupidist. Mitteavalikuks loetakse see ainult siis, kui see annab ligipääsu fikseeritud väärtustele, ilma metamärkide või poliitikamuutujateta, näiteks kindlale principalile või CIDR-plokkide hulgale aws:SourceIp kaudu. Metamärgiga principal seega testi ei läbi.

Azure'is peavad mõlemad tingimused olema täidetud. Kui konto anonüümset ligipääsu ei luba, pole konteineri seadel tähtsust. Kui konto lubab, jääb konteiner siiski privaatseks, kuni keegi seab selle tasemeks Container või Blob.

Samm 1: leidke, mis on avatud

S3. AWS-i juhend soovitab avalike bucketite ülevaatamiseks IAM Access Analyzer for S3 tööriista, nii et alustage sealt. Seejärel kontrollige igal kontol nelja Block Public Access seadet: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy ja RestrictPublicBuckets. Pange tähele, et GetBucketAcl tagastab efektiivsed õigused. Avaliku ACL-iga bucket, kus IgnorePublicAcls on sisse lülitatud, näitab ACL-i, mis peidab tegeliku.

Azure. Portaal annab esmalt anonüümsete päringute arvu. Avage storage accountis Monitoring ja seejärel Metrics. Kasutage nimeruumi Blob, mõõdikut Transactions, agregatsiooni Sum ning lisage filter, kus Authentication on võrdne väärtusega Anonymous.

Et näha, millised konteinerid on kaasatud, looge diagnostic setting, mis saadab logid Log Analytics workspace'i. Seejärel käivitage see päring, mis hõlmab viimast seitset päeva:

StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri

Veerg Uri nimetab konteinerid ja blobid, mida loetakse. Mõõdikud ja logid näitavad ainult seda, kes loeb anonüümselt, mitte seda, mis on avatud, nii et avatud konteiner, mida keegi pole pärinud, jääb nähtamatuks. Kontrollige seetõttu ka konteinerite ligipääsutasemeid.

Google Cloud. Vaadake bucketite IAM-poliitikad läbi ja otsige rolle, mis on antud allUsers või allAuthenticatedUsers põhimõtetele. Cloud Asset Inventory näitab kõigi projekti, kausta või organisatsiooni bucketite poliitikaid, mis säästab teid bucketite kaupa käimisest. Objektide ACL-e tuleb vaadata eraldi ja managed folderitel on oma IAM-poliitikad. Lülitage sisse usage logs, et näha, millised töökoormused avalike andmetega kokku puutuvad. Cloud Audit Logs ei jälgi ligipääsu avalikele objektidele, seega sellest siin abi ei ole.

Samm 2: lülitage kaitsepiirded sisse

S3. AWS soovitab lubada kõik neli seadet konto tasemel. Samuti soovitab see kõiki nelja igal bucketil, et täita Security Hub control S3.8. Mitme konto puhul kasutage organisatsioonitaseme poliitikat. See poliitika on kõik või mitte midagi, ilma seadete kaupa valikuta, ja see alistab valitud liikmekontode kontotaseme seaded. S3 rakendab tasemete vahel kõige piiravamat kombinatsiooni, nii et bucket ei saa nõrgendada seda, mida konto jõustab.

Rakendage eriti BlockPublicPolicy konto tasemel. Muidu saab igaüks, kes tohib bucketi poliitikat muuta, lisada poliitika, mis lülitab bucketi taseme seade välja. Kontotaseme muudatused kehtivad kõigis regioonides, kuid ei jõua kõikjale tingimata korraga. Access pointide seadeid saab määrata ainult loomise ajal, seega kontrollige neid eraldi.

Azure. Seadke AllowBlobPublicAccess igal storage accountil väärtusele False. See alistab iga konteineri seade, seega ei pea te konteinereid puutuma. See nõuab Azure Storage resource provideri versiooni 2019-04-01 või uuemat. Kasutajal peab olema õigus Microsoft.Storage/storageAccounts/write, mis on rollidel Owner, Contributor ja Storage Account Contributor. Hoidke need rollimäärangud kitsad.

Google Cloud. Jõustage bucketitel public access prevention või seadke organisatsioonipoliitika piirang storage.publicAccessPrevention projekti, kausta või organisatsiooni tasemel. Google soovitab jõustada kõrgeimal võimalikul tasemel. Bucketi olek on kas enforced või inherited. Bucket, millel on jõustatud seade, jääb jõustatuks ka siis, kui hiljem kõrgemal tasemel oleva piirangu välja lülitate.

Mis katki läheb ja mis mitte

Arvestage katkiminekutega, sest see ongi harjutuse mõte.

• S3: Seaded ei muuda olemasolevaid poliitikaid ega ACL-e. Seade eemaldamine teeb kõik, millel on avalik poliitika või ACL, uuesti avalikuks, seega koristage ära ka aluseks olevad õigused. Vaadake üle ka identiteedipõhised poliitikad ja ressursipoliitikad, näiteks KMS-võtmete poliitikad, mida Block Public Access ei kata.
• Azure: Anonüümsed lugemised hakkavad ebaõnnestuma. Veakood sõltub teenuse versioonist: 401 versioonide 2019-12-12 ja uuemate puhul, muidu 409, kui konto anonüümset ligipääsu ei luba, ja 404, kui lubab.
• Google Cloud: Päringud, mis kasutavad allUsers, ebaõnnestuvad HTTP-koodiga 401 või 403. Olemasolevad sidumised jäävad paika, kuid need alistatakse. Katsed neid lisada ebaõnnestuvad vastusega 412 Precondition Failed. Signed URL-e see ei mõjuta. Jõustamine võib võtta kuni 10 minutit ja vahemällu salvestatud objektid võivad jääda avalikuks Cache-Control eluea jooksul, mis on vaikimisi 3600 sekundit.

Tõeliselt avalik sisu, näiteks staatiline veebisait, vajab erandit. Azure soovitab viia selle eraldi storage accounti, mis on reserveeritud anonüümseks ligipääsuks. Google Cloudis lülitage prevention välja konkreetsel projektil, mis bucketit hoiab. S3-s kohandage üksikuid seadeid nende bucketite jaoks, kes seda vajavad.

Kust alustada

1. Tehke nimekiri kõigist AWS-i kontodest, Azure'i tellimustest ja Google Cloudi projektidest, kus on salvestusruumi, sealhulgas neist, mille loomist keegi ei mäleta.
2. Tehke ülalkirjeldatud avastustöö: Access Analyzer for S3, Azure'i anonüümsete päringute mõõdik ja logipäring ning Cloud Asset Inventory bucketite IAM-poliitikate jaoks.
3. Otsustage iga avaliku leiu puhul, kas see on tahtlik. Viige legitiimne avalik sisu eraldi kontodele või projektidesse.
4. Lülitage sisse konto- või organisatsioonitaseme kontrollid: kõik neli S3 seadet, AllowBlobPublicAccess väärtusele False ja piirang storage.publicAccessPrevention.
5. Käivitage päringud paari päeva pärast uuesti, et veenduda, et anonüümsed päringud on langenud nulli, ning seadke häire Azure'i anonüümsete päringute mõõdikule.
6. Kui soovite väljastpoolt kontrolli selle kohta, mis on endiselt kättesaadav, katab pilve avatuse meie läbistustestimise teenus ja meie konsultatsioonimeeskond saab üle vaadata teie kontode struktuuri.