Organizacja zasobów w Google Cloud - jak to zrobić?

Organizacja zasobów, czyli fundament

Pierwszym krokiem przed porządkowaniem zasad IT panujących w organizacji jest… uporządkowanie samej organizacji. Czy jest jasno podzielona na poszczególne jednostki (departamenty, działy, dywizje), czy wiadomo kto odpowiada za jakie procesy? Kto do jakiego typu danych potrzebuje dostępu? A komu ze względów bezpieczeństwa należy je ograniczyć? Dla dojrzałych przedsiębiorstw tego typu zagadnienia to oczywistość, ale w mniejszych firmach, albo takich, które gwałtownie urosły (np. w rok liczba pracowników potroiła się), nie jest to oczywiste. Wiele procesów nie jest sformalizowanych, a pojawiające się problemy rozwiązuje się ad hoc, bez przyjmowania systemowych rozwiązań.

Jeżeli zarządzający przedsiębiorstwem czy inną organizacją (urzędem, fundacją, etc.) mają uporządkowane procesy, przechodzimy do etapu planowania, czyli ustalania jak odwzorować strukturę w IT. Istnieje pokusa, żeby jak najszybciej przejść do wdrażania, czyli migracji zasobów IT na platformę Google Cloud, ale zachęcamy do dobrego zaplanowania tego procesu. Nawet tak banalna sprawa jak wypracowanie odpowiedniej konwencji nazewniczej folderów, pozwoli użytkownikom na wygodną pracę na co dzień i dostosowanie się do zmian organizacyjnych w przyszłości.

ABC Google Cloud

Swoją przygodę z Google Cloud można rozpocząć od tworzenia projektów w płaskiej, niezorganizowanej strukturze. Szybko się okazuje, że przy ich większej liczbie, zarządzanie odpowiednimi uprawnieniami robi się utrudnione lub wręcz niemożliwe. Spójrzmy, z czego składa się organizacja zasobów w Google Cloud oraz jakimi instrumentami możemy się posługiwać.

Uprawnienia do zasobów są dziedziczone w modelu “od ogółu do szczegółu” czy też “od góry do dołu”. Od “góry” rozpoczniemy też ich prezentowanie. Poniżej przedstawiamy diagram hierarchii zasobów:

Źródło: IAM policy inheritance, Google LLC

Organization

Jest to nadrzędny poziom grupujący zasoby przedsiębiorstwa. Tworzenie organizacji nie jest wymagane, aby korzystać z Google Cloud, ale rekomendujemy jej założenie. Jeżeli nie założymy organizacji, część operacji na poziomie tzw. Resource Managera nie będzie dostępna. Najprościej można przyrównać ten byt do całej naszej firmy - organizacja to firma. Kolejną analogią będzie tu firmowa domena.

Folders

Foldery grupują projekty lub inne foldery. Można przyjąć, że każdy dział w firmie ma swój folder. Dzięki takiemu zabiegowi możemy je odseparować np. uprawnieniami, ponieważ uprawnienia nadane folderowi są automatycznie nadane dla zasobów poniżej (podfolderów, projektów, zasobów w projektach). Foldery można dowolnie zagnieżdżać, np. kiedy bezpośrednio pod poziomem “Organization” znajduje się lista folderów (każdy folder na jeden dział, lub na produkt), wewnątrz można podzielić taki folder np. na osoby, klientów, czy środowiska.

Decyzję o tym, jak używać folderów uzależniamy od potrzeb organizacji oraz jej specyfiki. Prawie zawsze rekomendujemy wprowadzenie tego poziomu i używanie go, choć - analogicznie jak na poziomie organizacji - zakładanie folderów jest opcjonalne. Aby używać folderów, musisz najpierw posiadać założoną organizację. Folderami można dowolnie zarządzać po ich utworzeniu.

Projects

Projekty można przyrównać do instancji produktu, który mamy do uruchomienia. Jeśli dysponujemy na przykład oprogramowaniem sklepu internetowego wraz z bazą danych i szeregiem usług dodatkowych (np. mikroserwisów odpowiedzialnych za obsługę płatności, wysyłkę SMS, czy choćby obsługę przepływu towarów) to taka kompletna instancja sklepu to właśnie projekt. Może występować w kilku wersjach, chociażby w takich trzech podstawowych, np. odwzorowujących środowiska uruchomieniowe:

• development - wersja służąca pracom rozwojowym i wewnętrznym testom przeprowadzanym przez programistów;
• test - wersja służąca testom przeprowadzanym przez testerów i właścicieli biznesowych;
• production - wersja działająca produkcyjnie i udostępniona końcowym użytkownikom.

Każda z przytoczonych w powyższym przykładzie wersji mogłaby być projektem. Taką właśnie separację zasobów rekomendujemy najczęściej naszym klientom.

Zasoby powołane w obrębie danego projektu są widoczne tylko na jego poziomie. Jest to ważna cecha z wielu względów - pozwala choćby na odseparowanie środowisk, co jest kluczowe dla zachowania odpowiedniego poziomu bezpieczeństwa i efektywnej organizacji pracy.

Do projektów można przypisywać etykiety (Labels), za pośrednictwem których można filtrować np. informacje o bilingu. Etykietowanie to bardzo dobry nawyk pozwalający na wielowymiarowe grupowanie projektów i zasobów. Etykiet można przypisywać wiele, mają one formę “klucz: wartość” i mogą być związane z dowolną informacją (np. właścicielem biznesowym danego projektu, użytkownikiem, który go powołał, szczegółami dotyczącymi jego specyfiki).

Przenoszenie projektów między folderami jest bardzo proste i można wykonać to samodzielnie. Natomiast przeniesienie projektu między organizacjami wymaga odpowiedniego przygotowania i kontaktu z działem wsparcia Google.

Resources

Zasoby to byty takie jak maszyny wirtualne, platformy orkiestracji kontenerów, bazy danych, kolejki, storage. Czyli wszystko, co składa się na prawidłowe działanie projektu i jest jego integralną częścią. Jest to jednocześnie najniższy poziom abstrakcji dziedziczenia uprawnień.

Uwaga: przeniesienie zasobu między projektami jest niemożliwe i zwykle oznacza konieczność odtworzenia zasobu w nowym projekcie, np. z backupu, obrazu dysku czy korzystając z mechanizmu Infrastructure as code. Do zasobów, tak jak do projektów, można przypisywać etykiety, co zdecydowanie warto robić.

Pierwsze kroki

Oto kroki, które należy wykonać przed migracją przedsiębiorstwa do Google Cloud i/lub G Suite.

1. Założenie organizacji

Własną organizację Google można założyć na 3 sposoby:

• wykupując usługę G Suite;
• wykupując usługę Cloud Identity Premium;
• skorzystać z darmowej usługi Cloud Identity Free, której ograniczenia omówimy za chwilę.

Dwie pierwsze usługi są płatne. Licencje kupujemy na poszczególne konta użytkowników, a w ramach nich otrzymujemy: W przypadku G Suite - pełny pakiet biurowy pod własną domeną (poczta Gmail, Google Drive, Google Docs i inne) oraz konsolę służącą do kompleksowego zarządzania organizacją np. użytkownikami czy politykami bezpieczeństwa. Szczegóły: cennik G Suite. W przypadku Cloud Identity Premium - konsolę do zarządzania organizacją, użytkownikami, politykami bezpieczeństwa i wiele innych, ale bez usług biurowych. Szczegóły znajdziesz tutaj.

Korzystanie z trzeciej możliwości, czyli Cloud Identity Free nie wiąże się z żadnymi kosztami, ale jest limitowane do 50 kont. Szczegółowe porównanie wersji Cloud Identity Free i Premium.

Aby móc korzystać z usług Google Cloud (bez organizacji) korzystając z firmowego adresu e‑mail, należy:

• wejść tutaj;
• założyć nowe konto, wybierając opcję: “Zamiast tego użyj mojego obecnego adresu e‑mail” i podać służbowy adres e‑mail.

Dla konta firmowego zostanie stworzone Google Cloud Identity, które pozwoli na korzystanie z konsoli Google Cloud i innych usług Google.

2. Założenie grup użytkowników

Zgodnie z najlepszymi praktykami dostępy do konkretnych folderów, projektów czy zasobów powinny być przyznawane za pomocą grup użytkowników, nie zaś poszczególnym osobom. Przynależność do grup powinna być ograniczona i zarządzana przez administratorów na poziomie Cloud Identity.

Grupa Google stworzona w ramach organizacji posiada domenę tej organizacji, np. nazwa-grupy@example.com. Na tym etapie warto wypracować odpowiednią konwencję nazewniczą grup, aby po samej jej nazwie można było zidentyfikować co najmniej cztery następujące kwestie:

• wiemy, że ten adres e‑mail to grupa;
• wiemy kto powinien być członkiem grupy, a przede wszystkim kogo powinno w niej nie być;
• wiemy do jakich środowisk (folderów w Google Cloud, projektów) ma dostęp dana grupa;
• wiemy jakimi uprawnieniami powinna charakteryzować się dana grupa oraz z jakim rodzajem ogólnej odpowiedzialności wiąże się uczestnictwo w niej.

Przykład takiej konwencji:

• group-{org, prod, test, dev}-[app1,moduł2]-{admin, editor, viewer}-[ext]@example.com.

Po zastosowaniu takiej konwencji można przytoczyć kilka przykładów:

• group-prod-viewer@example.com - grupa posiadająca dostęp tylko do odczytu do wszystkich aplikacji produkcyjnych (np. Departament Bezpieczeństwa);
• group-prod-reports-viewer-ext@example.com - grupa zawierająca osoby spoza organizacji, posiadająca dostęp “tylko do odczytu” do modułów raportowych, we wszystkich aplikacjach produkcyjnych;
• group-test-editor@example.com - grupa posiadająca dostęp do wszystkich zasobów Google Cloud na środowisku testowym z uprawnieniami do edycji/tworzenia/usuwania, ale bez możliwości modyfikacji drzewa uprawnień.

Po ustaleniu konwencji i stworzeniu odpowiednich grup można przypisać do nich pierwszych użytkowników i wykorzystywać adresy tych grup do nadawania uprawnień dla konkretnych zasobów w Google Cloud. Nie należy przy tym specjalnie unikać i obawiać się sytuacji, w której w danej grupie znajdzie się jedna lub dwie osoby. To niewielki nakład pracy, który zaprocentuje, gdy organizacja będzie rosnąć i zmieniać się - wystarczy wtedy dodać pracownika do danej grupy.

Możliwości integracji z Active Directory (i Azure AD) lub LDAP

Jeśli w swojej firmie dotychczas korzystałeś z Microsoft Active Directory bądź LDAP (Lightweight Directory Access Protocol) - nadal możesz to robić. Nie ma potrzeby zakładania użytkownikom dodatkowych kont. Polecamy lekturę artykułów:

• Federating Google Cloud with Active Directory;
• Federating Google Cloud with Azure Active Directory.

3. Organizacja folderów

Opisany wcześniej wariant z podziałem folderów względem departamentów w organizacji jest rekomendowany przez Google.

Istnieją też inne warianty rozplanowania folderów w organizacjach. W przypadku mniejszych firm, bez rozbudowanej struktury organizacyjnej, polecamy zasadę tworzenia folderów na poszczególne środowiska (DEV/TEST/STAGE/PROD), w ramach których zgrupowane są wszystkie projekty z podziałem na odpowiednie środowiska. Dzięki takiemu podejściu można łatwo nadać dostęp odpowiedniej grupie (np. Departamentowi Bezpieczeństwa) do przeglądania wszystkich projektów testowych i produkcyjnych. Taki dostęp określa się wówczas na poziomie folderu (w tym przypadku TEST i PROD), a nie konkretnych projektów. Ma to oczywistą zaletę - kiedy pojawia się nowy projekt, Departament Bezpieczeństwa od razu może go eksplorować.

Niezależnie od konwencji dobrą praktyką jest stworzenie na tym etapie odpowiednich folderów.

4. Utworzenie projektu i powołanie zasobów

Na typ etapie można już utworzyć projekt i powołać konkretne zasoby niezbędne do jego realizacji. Dzięki dobrej organizacji na wcześniejszych etapach będziemy mogli odseparować środowiska, a także wygodnie i bezpiecznie nadać uprawnienia, co wykonamy w kroku następnym.

5. Pierwsza konfiguracja IAM z wykorzystaniem wcześniej założonych grup

Teraz możemy przystąpić do konfiguracji IAM (Identity and Access Management). Jest to etap, w którym definiujemy dostępy poszczególnych kont oraz grup do określonych zasobów. Możemy określić tam “kto”, może wykonać “jakiego rodzaju czynności”, w obrębie “jakiego zasobu”. Warto pamiętać, żeby wykorzystywać wyłącznie grupy użytkowników. Kiedy na tym etapie określimy, że lista lub zakres grup są nieadekwatne do naszych potrzeb, możemy je dowolnie modyfikować. Pamiętajmy tylko o dobrej zasadzie nadawania minimalnych, wymaganych do realizacji zadań, uprawnień (ang. “least privilege principle”).

6. Założenie konta bilingowego

Aby móc korzystać z Google Cloud należy mieć konto billingowe. Pozwala ono na zdefiniowanie szczegółów dot. rozliczeń, takich jak informacje o karcie kredytowej czy dane firmy.

Koszty korzystania z Google Cloud lub G Suite zależą nie tylko od wykorzystanych zasobów, ale też od partnera, za pośrednictwem którego kupuje się dostęp do usług. Konta bilingowe rozliczane przez Chmurę Krajową charakteryzują się bardzo preferencyjnymi warunkami cenowymi. Dlatego zachęcamy do podpięcia swojego konta bilingowego pod nasze konto “master”, aby od razu obniżyć koszty.

7. Migracja projektów z/do innej organizacji

Kiedy masz już projekt w innej organizacji możesz zmigrować go do swojej, wiąże się to jednak z kilkoma krokami “przed” oraz kontaktem z zespołem wsparcia Google Cloud. Więcej na ten temat możesz przeczytać pod tym adresem.

Projekty stworzone przed założeniem organizacji (czy nieprzypisane do żadnej organizacji) można łatwo, samodzielnie przypisać do swojej organizacji. Więcej na ten temat.

Rozliczaj Google Cloud przez Chmurę Krajową i płać mniej

Jeżeli już jesteś użytkownikiem Google Cloud, możesz w łatwy sposób obniżyć rachunek za korzystanie z chmury publicznej. Jest to tylko zmiana sposobu rozliczania - nie wymaga migracji, nie wpływa na dostępność usług. W tym celu należy skontaktować się z naszym działem sprzedaży, podpisać umowę i skorzystać z preferencyjnych warunków cenowych za pomocą podłączenia konta bilingowego pod nasze konto master. Oto jak wygląda ten proces technicznie po podpisaniu umowy:

1. Zaloguj się do konsoli Google Cloud.
2. Z listy wyboru na górnym pasku wybierz projekt, dla którego chcesz podłączyć/zmienić konto billingowe.
3. Widząc Dashboard wybranego projektu, z “hamburger menu” po lewej wybierz “Billing”.
4. Jeżeli posiadasz już własne konto billingowe, dostajesz wybór “Go to linked billing account” lub “Manage Billing Accounts” - wybierz tę drugą opcję, “Manage Billing Accounts”.
5. Przełącz widok na “My Projects”.
6. Na liście widzisz wszystkie swoje projekty, między nimi ten, dla którego chcesz zmienić billing.
7. Kliknij w 3 kropki w kolumnie “Actions” przy konkretnym projekcie i wybierz “Change billing”, pojawia się okno “Set the billing account…” - wybierz z listy konto: “Chmura Krajowa - <TWOJA_NAZWA_KLIENTA> - (…)”.

Mamy nadzieję, że pomogliśmy odnaleźć się w świecie organizacji Google Cloud. W razie pytań - zapraszamy do kontaktu.

Do zobaczenia w chmurze!