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 pracy rodzic/dziecko z określonymi punktami przyczepienia dla polityk i uprawnień.
Na wysokim poziomie wygląda to tak:
Maszyna wirtualna (nazywana Instancją Obliczeniową) jest zasobem. Zasób znajduje się w projekcie, prawdopodobnie obok innych Instancji Obliczeniowych, koszyków pamięci 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 z organizacji. Więcej informacji znajdziesz w tym.
Polityki organizacyjne
Pozwalają na centralizację kontroli nad zasobami chmurowymi Twojej organizacji:
Centralizacja kontroli w celu konfigurowania ograniczeń dotyczących sposobu, w jaki zasoby Twojej organizacji mogą być używane.
Definiowanie i ustanawianie ograniczeń dla zespołów deweloperskich, aby pozostał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 w celu wpływania 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 szczególnym rodzajem ograniczenia wobec usługi Google Cloud lub grupy usług Google Cloud. Konfigurujesz to ograniczenie z pożądanymi ograniczeniami.
Typowe przypadki użycia
Ograniczenie udostępniania zasobów na podstawie domeny.
Ograniczenie użycia kont serwisowych Identity and Access Management.
Ograniczenie fizycznej lokalizacji nowo tworzonych zasobów.
Wyłączenie tworzenia kont serwisowych.
Istnieje wiele innych ograniczeń, które dają Ci szczegółową kontrolę nad zasobami Twojej organizacji. Aby uzyskać więcej informacji, zobacz listę wszystkich ograniczeń Polityki Organizacyjnej.
Domyślne polityki organizacyjne
Role IAM
Są one 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 dla tego zasobu.
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ń ze wszystkich zasobów.
Istnieją trzy typy ról w IAM:
Podstawowe/Prymitywne role, które obejmują role Właściciela, Edytora i Widoku, które istniały przed wprowadzeniem IAM.
Role zdefiniowane, które zapewniają szczegółowy dostęp do konkretnej usługi i są zarządzane przez Google Cloud. Istnieje wiele zdefiniowanych ról, możesz zobaczyć wszystkie z nich z ich uprawnieniami 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ć uprawnienie tutaj i zobaczyć, które role je mają.
Możesz również wyszukać tutaj role zdefiniowane oferowane przez każdy produkt. Zauważ, że niektóre role nie mogą być przypisane do użytkowników, a tylko do kont serwisowych z powodu niektórych uprawnień, które zawierają. Ponadto zauważ, że uprawnienia będą miały skutek tylko wtedy, gdy będą przypisane do odpowiedniej usługi.
Lub sprawdź, czy rola niestandardowa może używać konkretnego uprawnienia tutaj.
GCP - IAM, Principals & Org Policies EnumUżytkownicy
W konsoli GCP nie ma zarządzania Użytkownikami ani Grupami, to odbywa się w Google Workspace. Chociaż możesz zsynchronizować innego dostawcę tożsamości w Google Workspace.
Możesz uzyskać dostęp do użytkowników i grup w Workspace w https://admin.google.com.
MFA może być wymuszone dla użytkowników Workspace, jednak atakujący może użyć tokena do uzyskania dostępu do GCP za pomocą CLI, co nie będzie chronione przez MFA (będzie chronione przez MFA tylko wtedy, gdy użytkownik loguje się, aby go wygenerować: gcloud auth login).
Grupy
Gdy organizacja jest tworzona, zaleca się utworzenie kilku grup. Jeśli zarządzasz którąkolwiek z nich, możesz skompromitować całą lub ważną część organizacji:
Grupa | Funkcja |
| Administrowanie wszelkimi zasobami, które należą do organizacji. Przypisz tę rolę oszczędnie; administratorzy organizacji mają dostęp do wszystkich zasobów Google Cloud. Alternatywnie, ponieważ ta funkcja jest wysoko uprzywilejowana, rozważ użycie kont indywidualnych zamiast tworzenia grupy. |
| Tworzenie sieci, podsieci, reguł zapory i urządzeń sieciowych, takich jak Cloud Router, Cloud VPN i równoważniki obciążenia 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ądzaniem dostępem i politykami ograniczeń organizacyjnych. Zobacz przewodnik po podstawach bezpieczeństwa Google Cloud, aby uzyskać więcej informacji na temat planowania infrastruktury bezpieczeństwa Google Cloud. |
| Tworzenie lub zarządzanie end-to-end pipeline'ami, które wspierają ciągłą integrację i dostarczanie, monitorowanie i provisionowanie systemów. |
| |
| |
| |
| Monitorowanie wydatków na projektach. Typowi członkowie to część zespołu finansowego. |
| Przeglądanie informacji o zasobach w organizacji Google Cloud. |
| Przeglądanie bezpieczeństwa w chmurze. |
| Przeglądanie konfiguracji sieci. |
| Przeglądanie dzienników audytowych. |
| Administrowanie Centrum Dowodzenia Bezpieczeństwa. |
| Zarządzanie sekretami w Menedżerze Sekretów. |
Domyślna polityka haseł
Wymuszaj silne hasła
Od 8 do 100 znaków
Brak ponownego użycia
Brak wygaśnięcia
Jeśli osoby uzyskują dostęp do Workspace za pośrednictwem dostawcy zewnętrznego, te wymagania nie są stosowane.
Konta serwisowe
To są podmioty, które zasoby mogą mieć przypisane i uzyskać dostęp do interakcji z GCP. Na przykład, możliwe jest uzyskanie dostępu do tokena autoryzacji Konta Serwisowego przypisanego do VM w metadanych.
Możliwe jest napotkanie pewnych konfliktów podczas korzystania zarówno z IAM, jak i zakresów dostępu. Na przykład, Twoje konto serwisowe może mieć rolę IAM compute.instanceAdmin, ale instancja, którą naruszyłeś, została ograniczona przez ograniczenie zakresu https://www.googleapis.com/auth/compute.readonly. To uniemożliwiłoby Ci wprowadzenie jakichkolwiek zmian za pomocą tokena OAuth, który jest automatycznie przypisywany do Twojej instancji.
Jest to podobne do ról IAM z AWS. Ale w przeciwieństwie do AWS, jakiekolwiek konto serwisowe może być przypisane do jakiejkolwiek usługi (nie musi być to dozwolone przez politykę).
Kilka kont serwisowych, które znajdziesz, jest w rzeczywistości automatycznie generowanych przez GCP po rozpoczęciu korzystania z usługi, takich jak:
Jednak możliwe jest również tworzenie i dołączanie do zasobów niestandardowych kont serwisowych, które będą wyglądać następująco:
Klucze i Tokeny
Istnieją 2 główne sposoby uzyskania dostępu do GCP jako konto usługi:
Za pomocą tokenów OAuth: Są to tokeny, które można uzyskać z miejsc takich jak punkty końcowe metadanych lub kradnąc żądania http i są ograniczone przez zakresy dostępu.
Klucze: Są to pary kluczy publicznych i prywatnych, które pozwalają na podpisywanie żądań jako konto usługi, a nawet generowanie tokenów OAuth do wykonywania działań jako konto usługi. Te klucze są niebezpieczne, ponieważ są bardziej skomplikowane do ograniczenia i kontrolowania, dlatego GCP zaleca ich niegenerowanie.
Należy zauważyć, że za każdym razem, gdy tworzone jest konto SA, GCP generuje klucz dla konta usługi, do którego użytkownik nie ma dostępu (i nie będzie on wymieniony w aplikacji internetowej). Zgodnie z tym wątkiem ten klucz jest używany wewnętrznie przez GCP do umożliwienia punktom końcowym metadanych generowania dostępnych tokenów OAuth.
Zakresy dostępu
Zakresy dostępu są przypisane do generowanych tokenów OAuth w celu uzyskania dostępu do punktów końcowych API GCP. Ograniczają uprawnienia tokenu OAuth. Oznacza to, że jeśli token należy do właściciela zasobu, ale nie ma w zakresie tokenu dostępu do tego zasobu, token nie może być użyty do (nadużywania) tych uprawnień.
Google faktycznie zaleca, aby zakresy dostępu nie były używane i aby całkowicie polegać na IAM. Portal zarządzania w sieci faktycznie egzekwuje to, ale zakresy dostępu mogą być nadal stosowane do instancji przy użyciu niestandardowych kont usługowych programowo.
Możesz zobaczyć, jakie zakresy są przypisane przez zapytanie:
Poprzednie zakresy to te, które są generowane domyślnie przy użyciu gcloud do uzyskiwania 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 punktami końcowymi.
Najważniejszym zakresem z tych potencjalnych jest cloud-platform, co zasadniczo 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 dane uwierzytelniające przeglądarki, możliwe jest uzyskanie tokena z innymi zakresami, robiąc coś takiego:
Polityki IAM Terraform, Powiązania i Członkostwa
Jak zdefiniowano w terraformie 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:
Członkostwa: Ustawiasz principals jako członków ról bez ograniczeń dotyczących roli lub principals. Możesz dodać użytkownika jako członka roli, a następnie dodać grupę jako członka tej samej roli i również ustawić tych principals (użytkownika i grupę) jako członków innych ról.
Powiązania: Kilku principals może być powiązanych z rolą. Ci principals mogą nadal być powiązani lub być członkami innych ról. Jednak jeśli principal, który nie jest powiązany z rolą, zostanie ustawiony jako członek powiązanej roli, następnym razem, gdy powiązanie zostanie zastosowane, członkostwo zniknie.
Polityki: 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 ta polityka zostanie zmodyfikowana (nawet w innych politykach, powiązaniach lub członkostwach). Dlatego, gdy rola lub principal jest określona w polityce, wszystkie jej uprawnienia są ograniczone przez tę politykę. Oczywiście, można to obejść, jeśli principal ma możliwość modyfikacji polityki lub uprawnienia do eskalacji uprawnień (jak stworzenie nowego principal i powiązanie go z nową rolą).
Odniesienia
Last updated
