GCP - Basic Information
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
Google Cloud gebruik 'n Hulpbron hiërargie wat, konseptueel, soortgelyk is aan dié van 'n tradisionele lêerstelsel. Dit bied 'n logiese ouer/kind werkstroom met spesifieke aanhegpunte vir beleide en toestemmings.
Op 'n hoë vlak lyk dit soos volg:
'n Virtuele masjien (genoem 'n Compute Instance) is 'n hulpbron. 'n Hulpbron woon in 'n projek, waarskynlik langs ander Compute Instances, stoor emmers, ens.
Dit is moontlik om 'n projek sonder enige organisasie na 'n organisasie met die toestemmings roles/resourcemanager.projectCreator en roles/resourcemanager.projectMover te migreer. As die projek binne 'n ander organisasie is, is dit nodig om GCP-ondersteuning te kontak om eerstens uit die organisasie te beweeg. Vir meer inligting, kyk hierdie.
Laat jou toe om beheer oor jou organisasie se wolkhulpbronne te sentraliseer:
Sentraliseer beheer om beperkings te konfigureer oor hoe jou organisasie se hulpbronne gebruik kan word.
Definieer en stel bewakings vir jou ontwikkelingspan in om binne nakomingsgrense te bly.
Help projek eienaars en hul spanne om vinnig te beweeg sonder om bekommerd te wees oor die verbreking van nakoming.
Hierdie beleide kan geskep word om die hele organisasie, vouer(s) of projek(te) te affekteer. Afstammelinge van die geteikende hulpbron hiërargie node erf die organisasie beleid.
Om 'n organisasie beleid te definieer, kies jy 'n beperking, wat 'n spesifieke tipe beperking teen 'n Google Cloud diens of 'n groep Google Cloud dienste is. Jy konfigureer daardie beperking met jou gewenste beperkings.
Beperk hulpbrondeling gebaseer op domein.
Beperk die gebruik van Identiteit en Toegang Bestuur diens rekeninge.
Beperk die fisiese ligging van nuut geskepte hulpbronne.
Deaktiveer diensrekening skepping.
Daar is baie meer beperkings wat jou fynbeheer oor jou organisasie se hulpbronne gee. Vir meer inligting, sien die lys van alle Organisasie Beleid Diens beperkings.
Hierdie is soos IAM beleide in AWS aangesien elke rol 'n stel toestemmings bevat.
Echter, anders as in AWS, is daar geen sentrale repo van rolle nie. In plaas daarvan, gee hulpbronne X toegang rolle aan Y prinsipes, en die enigste manier om uit te vind wie toegang tot 'n hulpbron het, is om die get-iam-policy metode oor daardie hulpbron te gebruik.
Dit kan 'n probleem wees omdat dit beteken dat die enigste manier om uit te vind watter toestemmings 'n prinsipe het, is om elke hulpbron te vra aan wie dit toestemmings gee, en 'n gebruiker mag nie toestemming hê om toestemming van alle hulpbronne te verkry nie.
Daar is drie tipes rolle in IAM:
Basiese/Primitive rolle, wat die Eienaar, Redigeerder, en Kykers rolle insluit wat voor die bekendstelling van IAM bestaan het.
Vooraf gedefinieerde rolle, wat fyn toegang bied vir 'n spesifieke diens en deur Google Cloud bestuur word. Daar is baie vooraf gedefinieerde rolle, jy kan almal daarvan met die voorregte wat hulle het hier sien.
Pasgemaakte rolle, wat fyn toegang bied volgens 'n gebruiker-gespesifiseerde lys van toestemmings.
Daar is duisende toestemmings in GCP. Om te kyk of 'n rol 'n toestemming het, kan jy hier die toestemming soek en sien watter rolle dit het.
Jy kan ook hier vooraf gedefinieerde rolle soek wat deur elke produk aangebied word. Let daarop dat sommige rolle nie aan gebruikers geheg kan word nie en slegs aan SA's omdat sommige toestemmings wat hulle bevat. Boonop, let daarop dat toestemmings slegs in werking sal tree as hulle aan die relevante diens geheg is.
Of kyk of 'n pasgemaakte rol 'n spesifieke toestemming hier kan gebruik.
GCP - IAM, Principals & Org Policies EnumIn GCP konsole is daar geen Gebruikers of Groepe bestuur nie, dit word in Google Workspace gedoen. Alhoewel jy 'n ander identiteit verskaffer in Google Workspace kan sinkroniseer.
Jy kan toegang tot Workspace gebruikers en groepe in https://admin.google.com.
MFA kan afgedwing word op Workspace gebruikers, egter, 'n aanvaller kan 'n token gebruik om GCP via cli te benader wat nie deur MFA beskerm sal word nie (dit sal slegs deur MFA beskerm word wanneer die gebruiker aanmeld om dit te genereer: gcloud auth login).
Wanneer 'n organisasie geskep word, word verskeie groepe sterk aanbeveel om geskep te word. As jy enige van hulle bestuur, mag jy al die of 'n belangrike deel van die organisasie gecompromitteer het:
Groep
Funksie
gcp-organization-admins
(groep of individuele rekeninge benodig vir kontrolelys)
Bestuur enige hulpbron wat aan die organisasie behoort. Ken hierdie rol spaarzaam toe; organisasie admins het toegang tot al jou Google Cloud hulpbronne. Alternatiewelik, omdat hierdie funksie hoogs bevoordeeld is, oorweeg om individuele rekeninge te gebruik eerder as om 'n groep te skep.
gcp-network-admins
(benodig vir kontrolelys)
Skep netwerke, subnetwerke, vuurmuur reëls, en netwerk toestelle soos Cloud Router, Cloud VPN, en wolk laaibalansers.
gcp-billing-admins
(benodig vir kontrolelys)
Stel faktureringsrekeninge op en monitor hul gebruik.
gcp-developers
(benodig vir kontrolelys)
Ontwerp, kodeer, en toets toepassings.
gcp-security-admins
Stel en bestuur sekuriteitsbeleide vir die hele organisasie, insluitend toegang bestuur en organisasie beperking beleide. Sien die Google Cloud sekuriteitsfondasies gids vir meer inligting oor die beplanning van jou Google Cloud sekuriteitsinfrastruktuur.
gcp-devops
Skep of bestuur end-to-end pyplyne wat deurlopende integrasie en aflewering, monitering, en stelsels voorsiening ondersteun.
gcp-logging-admins
gcp-logging-viewers
gcp-monitor-admins
gcp-billing-viewer
(nie meer standaard nie)
Monitor die besteding op projekte. Tipiese lede is deel van die finansiële span.
gcp-platform-viewer
(nie meer standaard nie)
Herbekend hulpbron inligting oor die Google Cloud organisasie.
gcp-security-reviewer
(nie meer standaard nie)
Herbekend wolk sekuriteit.
gcp-network-viewer
(nie meer standaard nie)
Herbekend netwerk konfigurasies.
grp-gcp-audit-viewer
(nie meer standaard nie)
Bekyk oudit logs.
gcp-scc-admin
(nie meer standaard nie)
Bestuur Sekuriteits Command Center.
gcp-secrets-admin
(nie meer standaard nie)
Bestuur geheime in Secret Manager.
Dwing sterk wagwoorde af
Tussen 8 en 100 karakters
Geen hergebruik
Geen vervaldatum
As mense toegang tot Workspace deur 'n derdeparty verskaffer verkry, word hierdie vereistes nie toegepas nie.
Dit is die prinsipes wat hulpbronne kan he geheg en toegang het om maklik met GCP te kommunikeer. Byvoorbeeld, dit is moontlik om die auth token van 'n Diensrekening geheg aan 'n VM in die metadata te benader.
Dit is moontlik om 'n paar konflikte te ondervind wanneer jy beide IAM en toegang skope gebruik. Byvoorbeeld, jou diensrekening mag die IAM rol van compute.instanceAdmin hê, maar die instansie wat jy gecompromitteer het, is beperk met die skope beperking van https://www.googleapis.com/auth/compute.readonly. Dit sal jou verhinder om enige veranderinge te maak met die OAuth token wat outomaties aan jou instansie toegeken word.
Dit is soortgelyk aan IAM rolle van AWS. Maar nie soos in AWS nie, kan enige diensrekening aan enige diens geheg word (dit hoef nie via 'n beleid toegelaat te word nie).
Verskeie van die diensrekeninge wat jy sal vind, is eintlik outomaties gegenereer deur GCP wanneer jy 'n diens begin gebruik, soos:
However, it's also possible to create and attach to resources custom service accounts, which will look like this:
Daar is 2 hoof maniere om toegang tot GCP te verkry as 'n diensrekening:
Deur OAuth tokens: Dit is tokens wat jy sal ontvang van plekke soos metadata eindpunte of deur http versoeke te steel en hulle is beperk deur die toegangskoppe.
Sleutels: Dit is publieke en private sleutelpare wat jou sal toelaat om versoeke as die diensrekening te teken en selfs OAuth tokens te genereer om aksies as die diensrekening uit te voer. Hierdie sleutels is gevaarlik omdat dit moeiliker is om te beperk en te beheer, daarom beveel GCP aan om hulle nie te genereer nie.
Let daarop dat elke keer as 'n SA geskep word, genereer GCP 'n sleutel vir die diensrekening wat die gebruiker nie kan toegang nie (en nie in die webtoepassing gelys sal word nie). Volgens hierdie draad word hierdie sleutel intern deur GCP gebruik om metadata eindpunte toegang te gee om die toeganklike OAuth tokens te genereer.
Toegangskoppe is aangewend op gegenereerde OAuth tokens om toegang tot die GCP API eindpunte te verkry. Hulle beperk die toestemmings van die OAuth token. Dit beteken dat as 'n token aan 'n Eienaar van 'n hulpbron behoort, maar nie die in die token se omvang het om toegang tot daardie hulpbron te verkry nie, die token nie gebruik kan word om (mis)bruik te maak van daardie voorregte nie.
Google beveel eintlik aan dat toegangskoppe nie gebruik word nie en om heeltemal op IAM te vertrou. Die webbestuursportaal handhaaf dit eintlik, maar toegangskoppe kan steeds programmaties op instansies toegepas word met behulp van persoonlike diensrekeninge.
Jy kan sien watter koppe toegeken is deur te vra:
Die vorige scopes is diegene wat verstek gegenereer word met gcloud om toegang tot data te verkry. Dit is omdat wanneer jy gcloud gebruik, jy eers 'n OAuth-token skep, en dit dan gebruik om die eindpunte te kontak.
Die belangrikste scope van hulle is waarskynlik cloud-platform, wat basies beteken dat dit moontlik is om toegang tot enige diens in GCP te verkry.
Jy kan 'n lys van alle moontlike scopes hier vind.
As jy gcloud blaaierskredensiaal het, is dit moontlik om 'n token met ander scopes te verkry, deur iets soos te doen:
Soos gedefinieer deur terraform in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam gebruik maak van terraform met GCP, is daar verskillende maniere om 'n prinsiep toegang tot 'n hulpbron te gee:
Lidmaatskappe: Jy stel prinsipes as lede van rolle sonder beperkings oor die rol of die prinsipes. Jy kan 'n gebruiker as 'n lid van 'n rol stel en dan 'n groep as 'n lid van dieselfde rol stel en ook daardie prinsipes (gebruiker en groep) as lede van ander rolle stel.
Bindings: Verskeie prinsipes kan aan 'n rol gebind word. Daardie prinsipes kan steeds aan ander rolle gebind of lede daarvan wees. As 'n prinsiep wat nie aan die rol gebind is nie, as lid van 'n gebinde rol gestel word, sal die volgende keer wanneer die binding toegepas word, die lidmaatskap verdwyn.
Beleide: 'n beleid is geauthoriseerd, dit dui rolle en prinsipes aan en dan, kan daardie prinsipes nie meer rolle hê nie en daardie rolle kan nie meer prinsipes hê nie tensy daardie beleid gewysig word (nie eers in ander beleide, bindings of lidmaatskappe nie). Daarom, wanneer 'n rol of prinsiep in 'n beleid gespesifiseer word, is al sy voorregte beperk deur daardie beleid. Dit kan natuurlik omseil word as die prinsiep die opsie gegee word om die beleid of voorregte-eskalasie toestemmings te wysig (soos om 'n nuwe prinsiep te skep en hom aan 'n nuwe rol te bind).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
