Blokér offentlig Cloud Storage-adgang – Signed URLs virker stadig

Håndhæv Public Access Prevention på et Google Cloud Storage-bucket for at blokere adgang via offentlige IAM- og ACL-rettigheder. Googles funktionsbeskrivelse fastslår, at både nye og eksisterende rettigheder til allUsers og allAuthenticatedUsers overstyres, mens gyldige Signed URLs fortsat virker. De gamle offentlige rettigheder bliver stående, så indstillingen bør ikke forveksles med oprydning i adgangspolitikken.

Den sikre rækkefølge er at finde tjenester, der bruger offentlige objektadresser, kontrollere nedarvet organisationspolitik og først derefter håndhæve indstillingen. Afprøv direkte adgang, signerede links og eventuelle cachelag hver for sig. En tjeneste, som henter offentlige objekter, kan ellers stoppe, selv om deling via Signed URLs fortsætter.

Kortlæg offentlig brug før ændringen

Find de objekter, som faktisk bliver hentet uden individuel adgangstilladelse. Gennemgå bucketets IAM-politik for allUsers og allAuthenticatedUsers og kontrollér IAM-politikker på eventuelle managed folders. Undersøg også objekt-ACL’er, hvis de bruges til adgangsstyring; med Uniform bucket-level access styrer objekt-ACL’er ikke adgangen.

En offentlig rettighed viser, at adgang kan være mulig, men fortæller ikke, hvilke tjenester der er afhængige af den. Sammenhold derfor rettighederne med hjemmesider, applikationer og integrationspunkter, der henviser direkte til objekterne. Cloud Storages usage logs kan hjælpe med at finde anmodninger til offentlige ressourcer; Cloud Audit Logs registrerer derimod ikke adgang til objekter, mens den er offentlig.

Skeln mellem en almindelig offentlig objektadresse og en adresse med signatur. Hvis en applikation bruger den første, skal dens leveringsvej ændres, før blokeringen aktiveres. Et privat flow med passende tilladelser eller et tidsbegrænset Signed URL kan være relevant, når brugen kræver afgrænset adgang. En hjemmeside, der serverer statiske filer direkte fra offentlige objekter, kræver særskilt planlægning.

Kontrollér, om buckettet allerede arver reglen

Et bucket med status inherited kan allerede være beskyttet. Organisationspolitikken storage.publicAccessPrevention kan være håndhævet på projekt-, mappe- eller organisationsniveau, og bucketets lokale status viser ikke alene den effektive adgang. Kontrollér derfor både bucketindstillingen og den effektive politik for projektet, før du ændrer noget.

I Google Cloud-konsollen vises bucketets status under Permissions og Public access. På kommandolinjen kan den lokale indstilling læses med gcloud storage buckets describe gs://BUCKET_NAME --format="default(public_access_prevention)". Hvis svaret er inherited, skal projektets effektive organisationspolitik undersøges særskilt; inherited betyder ikke nødvendigvis, at offentlig adgang er tilladt.

Et bucket, som lokalt er sat til enforced, forbliver beskyttet, selv hvis en overordnet politik senere ophæves. Omvendt kan en bucketadministrator ikke gøre et enkelt bucket offentligt ved at ændre dets lokale indstilling, når en overordnet politik håndhæver Public Access Prevention. Det er afgørende for både ændringen og en eventuel tilbagerulning.

Håndhæv Public Access Prevention på buckettet

Når offentlige afhængigheder er håndteret, køres gcloud storage buckets update gs://BUCKET_NAME --public-access-prevention. Googles kommandovejledning angiver dette flag for håndhævelse og beskriver statuskontrol og tilbageførsel. Erstat BUCKET_NAME med det konkrete bucketnavn; den lokale indstilling bliver enforced.

Det samme kan gøres i Google Cloud-konsollen ved at åbne buckettet, vælge Permissions og derefter Prevent public access i kortet Public access. Ændringen kræver tilladelserne storage.buckets.update og storage.buckets.setIamPolicy. Rollen Storage Admin på buckettet indeholder de nødvendige tilladelser.

Indstillingen overstyrer eksisterende offentlige IAM- og ACL-poster og afviser forsøg på at tilføje nye offentlige tildelinger. Behold et overblik over de gamle poster, så de kan fjernes kontrolleret. At status skifter til enforced, betyder ikke, at posterne er slettet fra politikkerne.

Afprøv direkte adgang og cache

Læs bucketets status igen, og prøv en kendt objektadresse uden login, adgangstoken eller signatur. Et opslag, som før blev godkendt via allUsers, skal afvises med HTTP 401 eller 403, når håndhævelsen er slået igennem. Test direkte mod Cloud Storage, så et svar fra en mellemliggende cache ikke forveksles med bucketets aktuelle adgangskontrol.

Test også allAuthenticatedUsers særskilt, hvis den principal havde adgang før ændringen. En anonym anmodning afprøver ikke en rettighed, der gælder indloggede brugere. Brug en indlogget testkonto uden anden adgang til objektet, så en eventuel tilladelse ikke skyldes en anden IAM-rolle.

Håndhævelsen kan tage op til 10 minutter om at slå igennem. Tidligere offentligt indhold kan desuden fortsat være tilgængeligt fra en internetcache afhængigt af objektets Cache-Control-indstilling. Kontrollér derfor både det direkte svar fra Cloud Storage og den leveringsvej, brugerne faktisk benytter; et cachehit siger ikke, at den offentlige rettighed stadig virker på buckettet.

Prøv Signed URLs som et separat flow

Et Signed URL bruger en signatur til at give adgang til en bestemt ressource og handling i en afgrænset periode. Googles vejledning om Signed URLs beskriver, at enhver med et gyldigt link kan bruge det uden egen Google-konto, og at linkene bruger Cloud Storages XML API-endepunkter. Et signeret link er derfor en anden adgangsvej end en offentlig IAM- eller ACL-tildeling.

Afprøv et gyldigt link til et objekt, som delingsflowet faktisk skal udlevere, uden modtagerens Google-login. Kontrollér den tilsigtede handling og linkets udløbstid. Kontoen, der bruges til at signere, skal selv have tilladelse til den anmodning, linket giver adgang til; ellers siger et mislykket opslag intet om Public Access Prevention.

Et link bør også prøves gennem den adresse, som modtageren får. Dermed opdages fejl i den konkrete levering, eksempelvis en ændret signatur eller en adresse, der peger på et andet end det forventede endepunkt. Et udløbet link er en test af linkets gyldighed, ikke af bucketets blokering af offentlig adgang.

Rul tilbage uden at genåbne gamle rettigheder

Hvis en nødvendig tjeneste stopper, så fastslå først, hvilken adgangsvej den brugte. Var det en offentlig objektadresse, skal den afhængighed enten omlægges eller behandles som en bevidst undtagelse i adgangsdesignet. Fungerer et Signed URL ikke, skal signatur, udløb, handling og signeringskonto undersøges, før bucketindstillingen ændres.

For et bucket, som lokalt er sat til enforced, sætter gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention indstillingen tilbage til inherited. En overordnet organisationspolitik kan stadig håndhæve blokeringen. Fjern eller ret gamle offentlige IAM- og ACL-poster, før beskyttelsen ophæves, hvis buckettet fortsat skal være privat: ellers kan posterne få virkning igen. Gentag til sidst testen af direkte adgang og det signerede link som to separate kontroller.

Læs også:

• Brug Copilot i Teams uden referat – men Purview kan stadig gemme spor
• Claude åbner tre cyberniveauer – adgang kræver stadig godkendelse
• Kritisk Atlassian-fejl rammer otte Data Center-produkter – Cloud er lappet