Last updated
Google Cloud maak gebruik van 'n Hulpbronhiërargie wat konseptueel soortgelyk is aan dié van 'n tradisionele lêersisteem. Dit bied 'n logiese ouer/kind-werkvloei met spesifieke aanhegtingspunte vir beleide en toestemmings.
Op 'n hoë vlak lyk dit soos dit:
'n Virtuele masjien (genoem 'n Rekeningsinstansie) is 'n hulpbron. 'n Hulpbron bly in 'n projek, moontlik langs ander Rekeningsinstansies, stoorhouers vir data, ens.
Dit is moontlik om 'n projek sonder enige organisasie te migreer na 'n organisasie met die toestemmings roles/resourcemanager.projectCreator en roles/resourcemanager.projectMover. As die projek binne 'n ander organisasie is, moet daar met GCP-ondersteuning gekontak word om hulle eerstens uit die organisasie te skuif. Vir meer inligting, kyk hier.
Dit maak dit moontlik 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 riglyne vas vir jou ontwikkelingsspanne om binne die nakomingsgrense te bly.
Help projek-eienaars en hul spanne om vinnig te beweeg sonder om bekommerd te wees oor die oortreding van nakomings.
Hierdie beleide kan geskep word om die volledige organisasie, vouer(s) of projek(te) te beïnvloed. Afstammelinge van die geteikende hulpbronhiërargienoot erf die organisasiebeleid.
Om 'n organisasiebeleid te definieer, kies jy 'n beperking, wat 'n spesifieke tipe beperking teen 'n Google Cloud-diens of 'n groep Google Cloud-diens is. Jy konfigureer daardie beperking met jou gewenste beperkings.
Beperk die deel van hulpbronne op grond van domein.
Beperk die gebruik van Identiteit- en Toegangsbestuurdienst-rekeninge.
Beperk die fisiese ligging van nuut geskepte hulpbronne.
Deaktiveer die skepping van diensrekening.
Daar is baie meer beperkings wat jou fynkontrole oor jou organisasie se hulpbronne gee. Vir meer inligting, sien die lys van alle Organisasiebeleiddiensbeperkings.
Hierdie is soos IAM-beleide in AWS aangesien elke rol 'n stel toestemmings bevat.
Tog, in teenstelling met AWS, is daar geen gesentraliseerde bewaarplek van rolle nie. In plaas daarvan gee hulpbronne X-toegangsrolle aan Y-prinsipale, 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 prinsipaal het, is om elke hulpbron te vra aan wie dit toestemmings gee, en 'n gebruiker mag nie toestemmings hê om toestemmings van alle hulpbronne te kry nie.
Daar is drie tipes rolle in IAM:
Basiese/Primitiewe rolle, wat die Eienaar, Redakteur, en Kykrolle insluit wat bestaan het voordat IAM ingevoer is.
Voorafbepaalde rolle, wat fyn toegang vir 'n spesifieke diens bied en deur Google Cloud bestuur word. Daar is baie voorafbepaalde rolle, jy kan al hulle sien met die voorregte wat hulle het hier.
Aangepaste rolle, wat fyn toegang volgens 'n lys van toestemmings wat deur die gebruiker gespesifiseer is, bied.
Daar is duisende toestemmings in GCP. Om te kontroleer of 'n rol toestemmings het, kan jy die toestemming hier soek en sien watter rolle dit het.
Jy kan ook hier voorafbepaalde rolle soek wat deur elke produk aangebied word. Let daarop dat sommige rolle nie aan gebruikers geheg kan word nie en net aan SAs geheg kan word as gevolg van sommige toestemmings wat hulle bevat. Verder, let daarop dat toestemmings slegs van krag sal wees as hulle aan die betrokke diens geheg is.
Of kontroleer of 'n aangepaste rol 'n spesifieke toestemming hier kan gebruik.
GCP - IAM, Principals & Org Policies EnumIn die GCP-konsole is daar geen Gebruikers of Groepe bestuur nie, dit word in Google Workspace gedoen. Alhoewel jy 'n ander identiteitsverskaffer in Google Workspace kan sinchroniseer.
Jy kan Werkspasies gebruikers en groepe bereik by https://admin.google.com.
MFA kan aan Werkspasies-gebruikers opgelê word, maar 'n aanvaller kan 'n token gebruik om toegang tot GCP te kry via cli wat nie deur MFA beskerm sal word (dit sal slegs deur MFA beskerm word wanneer die gebruiker aanmeld om dit te genereer: gcloud auth login).
Wanneer 'n organisasie geskep word, word dit sterk aanbeveel om verskeie groepe te skep. As jy enige van hulle bestuur, kan jy dalk die hele organisasie of 'n belangrike deel daarvan kompromitteer:
Groep | Funksie |
| Administrasie van enige hulpbron wat aan die organisasie behoort. Ken hierdie rol spaarsaam toe; org-admins het toegang tot al jou Google Cloud-hulpbronne. Alternatief, omdat hierdie funksie hoogs bevoorreg is, oorweeg om individuele rekeninge te gebruik in plaas van 'n groep te skep. |
| Netwerke, subnetwerke, firewall-reëls en netwerktoestelle soos Cloud Router, Cloud VPN, en wolk balanseringstelsels skep. |
| Opstel van faktureringsrekeninge en monitering van hul gebruik. |
| Ontwerp, kodering, en toetsing van aansoeke. |
| Vasstel en bestuur van sekuriteitsbeleide vir die hele organisasie, insluitend toegangsbestuur en organisasiebeleidsbeperkings. Sien die Google Cloud-sekuriteitsgrondslae-gids vir meer inligting oor die beplanning van jou Google Cloud-sekuriteitsinfrastruktuur. |
| Skep of bestuur van begin tot einde-pyplyne wat voortdurende integrasie en aflewering, monitering, en stelselvoorsiening ondersteun. |
| |
| |
| |
| Monitering van die spandering op projekte. Tipiese lede is deel van die finansiële span. |
| Hersiening van hulpbroninligting regoor die Google Cloud-organisasie. |
| Hersiening van wolksekuriteit. |
| Hersiening van netwerkkonfigurasies. |
| Hersiening van ouditlogs. |
| Administrasie van Security Command Center. |
| Bestuur van geheime in Secret Manager. |
Dwing sterk wagwoorde af
Tussen 8 en 100 karakters
Geen hergebruik
Geen verval
As mense toegang tot Werkspasies deur 'n derde partyverskaffer verkry, word hierdie vereistes nie toegepas nie.
Dit is die beginsels wat hulpbronne kan hê geheg en toegang hê om maklik met GCP te interaksieer. Byvoorbeeld, dit is moontlik om die outentiseringsleutel van 'n Diensrekening geheg aan 'n VM in die metadata te kry.
Dit is moontlik om enkele konflikte te ervaar wanneer jy beide IAM en toegangsbereike gebruik. Byvoorbeeld, jou diensrekening mag die IAM-rol van compute.instanceAdmin hê, maar die instansie wat jy oortree het, is beperk met die omvangsbeperking van https://www.googleapis.com/auth/compute.readonly. Dit sal voorkom dat jy enige veranderinge kan maak met die OAuth-token wat outomaties aan jou instansie toegewys is.
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 toegelaat te word via 'n beleid nie).
Verskeie van die diensrekeninge wat jy sal vind, is eintlik outomaties gegenereer deur GCP wanneer jy begin om 'n diens te gebruik, soos:
Dit is egter ook moontlik om aangepaste diensrekeninge te skep en daaraan te koppel, wat soos volg sal lyk:
Toegangsbereike word geheg aan gegenereerde OAuth-tokens om toegang te verkry tot die GCP-API-eindpunte. Hulle beperk die regte van die OAuth-token. Dit beteken dat as 'n token aan 'n Eienaar van 'n hulpbron behoort, maar nie die reikwydte in die token het om daardie hulpbron te benader nie, kan die token nie gebruik word om daardie regte te misbruik nie.
Google beveel eintlik aan dat toegangsbereike nie gebruik word nie en dat u heeltemal op IAM moet staatmaak. Die webbestuursportaal dwing dit eintlik af, maar toegangsbereike kan steeds op instansies toegepas word deur middel van aangepaste diensrekeninge programmaties.
U kan sien watter reikwydtes is toegewys deur navraag te doen:
Die vorige omvang is diegene wat standaard gegenereer word deur gcloud te gebruik om data te ontsluit. Dit is omdat wanneer jy gcloud gebruik, skep jy eers 'n OAuth-token, en gebruik dit dan om die eindpunte te kontak.
Die belangrikste omvang van daardie potensieel is cloud-platform, wat basies beteken dat dit moontlik is om enige diens in GCP te ontsluit.
Jy kan 'n lys van alle moontlike omvang hier vind.
As jy gcloud-blaaiergelde het, is dit moontlik om 'n token met ander omvang te verkry, deur iets soos:
Soos gedefinieer deur terraform in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam deur terraform met GCP te gebruik, is daar verskillende maniere om 'n hoof toegang tot 'n hulpbron te verleen:
Lede: Jy stel hoofde as lede van rolle sonder beperkings oor die rol of die hoofde. Jy kan 'n gebruiker as 'n lid van 'n rol plaas en dan 'n groep as 'n lid van dieselfde rol plaas en ook daardie hoofde (gebruiker en groep) as lid van ander rolle plaas.
Bindings: Verskeie hoofde kan aan 'n rol gebind word. Daardie hoofde kan steeds gebind word of lede van ander rolle wees. Indien 'n hoof wat nie aan die rol gebind is nie, as lid van 'n gebinde rol ingestel word, sal die volgende keer dat die binding toegepas word, die lidmaatskap verdwyn.
Beleide: 'n Beleid is gesaghebbend, dit dui rolle en hoofde aan en dan kan daardie hoofde nie meer rolle hê en daardie rolle kan nie meer hoofde hê tensy daardie beleid gewysig word (selfs nie in ander beleide, bindings of lede nie). Daarom, wanneer 'n rol of hoof in 'n beleid gespesifiseer word, is al sy voorregte beperk deur daardie beleid. Dit kan natuurlik omseil word in die geval waar die hoof die opsie gegee word om die beleid te wysig of voorreg-escalasie-permissies te verkry (soos die skep van 'n nuwe hoof en hom 'n nuwe rol bind).
