GCP - Basic Information
Hierarchia zasobów
Google Cloud używa Hierarchii zasobów, która jest koncepcyjnie podobna do tradycyjnego systemu plików. Zapewnia to logiczny przepływ rodzic/dziecko z określonymi punktami przyłączenia dla polityk i uprawnień.
Na wysokim poziomie wygląda to tak:
Maszyna wirtualna (nazywana Compute Instance) jest zasobem. Zasób znajduje się w projekcie, prawdopodobnie obok innych Compute Instances, storage buckets, itp.
Migracja Projektów
Możliwe jest migracja projektu bez organizacji do organizacji z uprawnieniami roles/resourcemanager.projectCreator i roles/resourcemanager.projectMover. Jeśli projekt znajduje się w innej organizacji, należy skontaktować się z pomocą techniczną GCP, aby najpierw przenieść go poza organizację. Więcej informacji znajdziesz tutaj.
Polityki Organizacyjne
Pozwalają na centralizację kontroli nad zasobami chmurowymi organizacji:
Centralizacja kontroli w celu konfigurowania ograniczeń dotyczących sposobu używania zasobów organizacji.
Definiowanie i ustanawianie barier ochronnych dla zespołów deweloperskich, aby pozostawały w granicach zgodności.
Pomoc właścicielom projektów i ich zespołom w szybkim działaniu bez obaw o naruszenie zgodności.
Te polityki mogą być tworzone, aby wpływać na całą organizację, folder(y) lub projekt(y). Potomkowie docelowego węzła hierarchii zasobów dziedziczą politykę organizacyjną.
Aby zdefiniować politykę organizacyjną, wybierasz ograniczenie, które jest określonym typem ograniczenia wobec usługi Google Cloud lub grupy usług Google Cloud. Konfigurujesz to ograniczenie z pożądanymi restrykcjami.
Typowe przypadki użycia
Ograniczenie udostępniania zasobów na podstawie domeny.
Ograniczenie użycia kont usług Identity and Access Management.
Ograniczenie fizycznej lokalizacji nowo utworzonych zasobów.
Wyłączenie tworzenia kont usług
Istnieje wiele innych ograniczeń, które dają szczegółową kontrolę nad zasobami organizacji. Aby uzyskać więcej informacji, zobacz listę wszystkich ograniczeń usługi Organization Policy.
Domyślne Polityki Organizacyjne
IAM Roles
Są podobne do polityk IAM w AWS, ponieważ każda rola zawiera zestaw uprawnień.
Jednak w przeciwieństwie do AWS, nie ma centralnego repozytorium ról. Zamiast tego, zasoby przyznają X role dostępu Y podmiotom, a jedynym sposobem, aby dowiedzieć się, kto ma dostęp do zasobu, jest użycie metody get-iam-policy na tym zasobie.
Może to być problem, ponieważ oznacza to, że jedynym sposobem, aby dowiedzieć się, jakie uprawnienia ma podmiot, jest zapytanie każdego zasobu, komu przyznaje uprawnienia, a użytkownik może nie mieć uprawnień do uzyskania uprawnień od wszystkich zasobów.
Istnieją trzy typy ról w IAM:
Podstawowe/Primitivne role, które obejmują role Owner, Editor i Viewer, które istniały przed wprowadzeniem IAM.
Zdefiniowane role, które zapewniają szczegółowy dostęp do określonej usługi i są zarządzane przez Google Cloud. Istnieje wiele zdefiniowanych ról, możesz zobaczyć wszystkie z nich z uprawnieniami, które mają tutaj.
Role niestandardowe, które zapewniają szczegółowy dostęp zgodnie z listą uprawnień określoną przez użytkownika.
W GCP istnieją tysiące uprawnień. Aby sprawdzić, czy rola ma uprawnienia, możesz wyszukać uprawnienia tutaj i zobaczyć, które role je mają.
Możesz również wyszukać tutaj zdefiniowane role oferowane przez każdy produkt. Należy zauważyć, że niektóre role nie mogą być przypisane do użytkowników i tylko do SAs z powodu niektórych uprawnień, które zawierają. Ponadto, należy zauważyć, że uprawnienia będą działać tylko wtedy, gdy są przypisane do odpowiedniej usługi.
Lub sprawdź, czy rola niestandardowa może używać określonego uprawnienia tutaj.
GCP - IAM, Principals & Org Policies EnumUżytkownicy
W konsoli GCP nie ma zarządzania Użytkownikami ani Grupami, to jest realizowane w Google Workspace. Chociaż można zsynchronizować innego dostawcę tożsamości w Google Workspace.
Możesz uzyskać dostęp do użytkowników i grup Workspaces w https://admin.google.com.
MFA może być wymuszone dla użytkowników Workspaces, jednak atakujący może użyć tokena do uzyskania dostępu do GCP przez cli, który nie będzie chroniony przez MFA (będzie chroniony przez MFA tylko wtedy, gdy użytkownik zaloguje się, aby go wygenerować: gcloud auth login).
Grupy
Kiedy tworzona jest organizacja, sugeruje się utworzenie kilku grup. Jeśli zarządzasz którąkolwiek z nich, możesz mieć skompromitowaną całą lub ważną część organizacji:
Grupa | Funkcja |
| Administrowanie dowolnym zasobem należącym do organizacji. Przypisuj tę rolę oszczędnie; administratorzy organizacji mają dostęp do wszystkich zasobów Google Cloud. Alternatywnie, ponieważ ta funkcja jest wysoce uprzywilejowana, rozważ użycie indywidualnych kont zamiast tworzenia grupy. |
| Tworzenie sieci, podsieci, reguł zapory i urządzeń sieciowych, takich jak Cloud Router, Cloud VPN i load balancers w chmurze. |
| Konfigurowanie kont rozliczeniowych i monitorowanie ich użycia. |
| Projektowanie, kodowanie i testowanie aplikacji. |
| Ustanawianie i zarządzanie politykami bezpieczeństwa dla całej organizacji, w tym zarządzanie dostępem i politykami ograniczeń organizacyjnych. Zobacz przewodnik po podstawach bezpieczeństwa Google Cloud po więcej informacji na temat planowania infrastruktury bezpieczeństwa Google Cloud. |
| Tworzenie lub zarządzanie pipeline'ami end-to-end, które wspierają ciągłą integrację i dostarczanie, monitorowanie i provisioningu systemu. |
| |
| |
| |
| Monitorowanie wydatków na projekty. Typowi członkowie to część zespołu finansowego. |
| Przeglądanie informacji o zasobach w całej organizacji Google Cloud. |
| Przeglądanie bezpieczeństwa chmury. |
| Przeglądanie konfiguracji sieci. |
| Przeglądanie logów audytu. |
| Administrowanie Security Command Center. |
| Zarządzanie sekretami w Secret Manager. |
Domyślna Polityka Haseł
Wymuszanie silnych haseł
Między 8 a 100 znaków
Brak ponownego użycia
Brak wygaśnięcia
Jeśli ludzie uzyskują dostęp do Workspace przez zewnętrznego dostawcę, te wymagania nie są stosowane.
Service accounts
Są to podmioty, które zasoby mogą mieć przypisane i dostęp do łatwej interakcji z GCP. Na przykład, możliwe jest uzyskanie dostępu do auth token konta usługi przypisanego do VM w metadanych.
Możliwe jest napotkanie konfliktów podczas używania zarówno IAM, jak i zakresów dostępu. Na przykład, twoje konto usługi może mieć rolę IAM compute.instanceAdmin, ale instancja, którą przejąłeś, została ograniczona zakresem https://www.googleapis.com/auth/compute.readonly. To uniemożliwiłoby wprowadzanie jakichkolwiek zmian za pomocą tokena OAuth, który jest automatycznie przypisany do twojej instancji
Jednakże możliwe jest również tworzenie i dołączanie do zasobów niestandardowych kont usługowych, które będą wyglądać tak:
Access scopes
Access scope są przypisane do generowanych tokenów OAuth w celu uzyskania dostępu do punktów końcowych API GCP. Ograniczają one uprawnienia tokena OAuth. Oznacza to, że jeśli token należy do właściciela zasobu, ale nie ma w zakresie tokena dostępu do tego zasobu, token nie może być użyty do (nadużywania) tych uprawnień.
Google faktycznie zaleca, aby nie używać access scopes i całkowicie polegać na IAM. Portal zarządzania webowego faktycznie to wymusza, ale access scopes mogą nadal być stosowane do instancji przy użyciu niestandardowych kont serwisowych programowo.
Możesz zobaczyć, jakie scopes są przypisane poprzez zapytanie:
Poprzednie scopes są generowane domyślnie przy użyciu gcloud do dostępu do danych. Dzieje się tak, ponieważ gdy używasz gcloud, najpierw tworzysz token OAuth, a następnie używasz go do kontaktu z endpointami.
Najważniejszym zakresem z tych potencjalnych jest cloud-platform, co w zasadzie oznacza, że możliwe jest uzyskanie dostępu do dowolnej usługi w GCP.
Możesz znaleźć listę wszystkich możliwych zakresów tutaj.
Jeśli masz gcloud poświadczenia przeglądarki, możliwe jest uzyskanie tokena z innymi zakresami, robiąc coś takiego:
Terraform IAM Policies, Bindings and Memberships
Jak zdefiniowano przez terraform w https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam używając terraform z GCP istnieją różne sposoby przyznawania dostępu do zasobu:
Memberships: Ustawiasz principals jako członków ról bez ograniczeń dotyczących roli lub principals. Możesz umieścić użytkownika jako członka roli, a następnie umieścić grupę jako członka tej samej roli i również ustawić tych principals (użytkownika i grupę) jako członków innych ról.
Bindings: Kilku principals może być powiązanych z rolą. Ci principals mogą nadal być powiązani lub być członkami innych ról. Jednakże, jeśli principal, który nie jest powiązany z rolą, zostanie ustawiony jako członek powiązanej roli, następnym razem, gdy binding zostanie zastosowany, członkostwo zniknie.
Policies: Polityka jest autorytatywna, wskazuje role i principals, a następnie, ci principals nie mogą mieć więcej ról, a te role nie mogą mieć więcej principals, chyba że polityka zostanie zmodyfikowana (nawet w innych politykach, bindings lub memberships). Dlatego, gdy rola lub principal jest określony w polityce, wszystkie jego przywileje są ograniczone przez tę politykę. Oczywiście, można to obejść, jeśli principal ma możliwość modyfikacji polityki lub uprawnień do eskalacji przywilejów (jak stworzenie nowego principal i powiązanie go z nową rolą).
References
Last updated
