W zamierzchłych czasach, gdy dominowały lokalne serwery Unix z rozległymi systemami plików, przedsiębiorstwa opracowywały skomplikowane reguły zarządzania strukturą katalogów oraz strategie kontroli dostępu do poszczególnych folderów, przeznaczone dla różnych użytkowników.
Zazwyczaj platforma organizacji obsługuje zróżnicowane grupy użytkowników, które charakteryzują się odmiennymi potrzebami, poziomami poufności lub definicjami treści. W przypadku firm o zasięgu globalnym może to nawet oznaczać segregację zasobów ze względu na lokalizację, a więc w praktyce – pomiędzy użytkownikami z różnych państw.
Kolejne typowe przykłady obejmują:
- Izolację danych między środowiskami programistycznymi, testowymi i produkcyjnymi.
- Ograniczenie dostępu do materiałów sprzedażowych dla szerokiego grona odbiorców.
- Dostępność treści regulacyjnych specyficznych dla danego kraju, niedostępnych dla użytkowników z innych regionów.
- Materiały projektowe, gdzie „dane kierownicze” powinny być dostępne jedynie dla ograniczonej grupy osób, itp.
Lista tego typu sytuacji jest niemal nieskończona. Kluczowe jest to, że zawsze istnieje potrzeba uporządkowania praw dostępu do plików i danych pomiędzy wszystkimi użytkownikami, którym platforma umożliwia dostęp.
W przypadku rozwiązań stacjonarnych, było to zadanie rutynowe. Administrator systemu plików po prostu konfiguruje odpowiednie reguły za pomocą wybranego narzędzia, a następnie przypisuje użytkowników do grup, a grupy do konkretnych folderów lub punktów montowania, do których mają uzyskać dostęp. Dodatkowo, definiowany jest poziom dostępu – tylko do odczytu lub do odczytu i zapisu.
Przyglądając się obecnym platformom chmurowym, takim jak AWS, staje się jasne, że użytkownicy będą mieć podobne potrzeby w zakresie ograniczenia dostępu do treści. Rozwiązanie tego problemu musi być jednak inne. Pliki nie znajdują się już na serwerach Unix, ale w chmurze (i potencjalnie są dostępne nie tylko dla całej organizacji, ale nawet dla całego świata), a ich zawartość nie jest przechowywana w katalogach, lecz w zasobnikach S3.
Poniżej przedstawiono alternatywną metodę podejścia do tego wyzwania. Bazuje ona na rzeczywistych doświadczeniach zdobytych podczas projektowania takich rozwiązań dla konkretnego projektu.
Proste, lecz bardzo manualne podejście
Jedną z możliwości rozwiązania problemu bez żadnej automatyzacji jest stosunkowo proste podejście:
- Utwórz osobny zasobnik dla każdej wyodrębnionej grupy użytkowników.
- Skonfiguruj uprawnienia dostępu do danego zasobnika tak, aby tylko ta konkretna grupa miała do niego dostęp.
To rozwiązanie jest z pewnością możliwe, gdy potrzebne jest bardzo szybkie i nieskomplikowane wdrożenie. Warto jednak pamiętać o pewnych ograniczeniach.
Domyślnie, w ramach jednego konta AWS można utworzyć maksymalnie 100 zasobników S3. Limit ten można zwiększyć do 1000, zgłaszając odpowiedni wniosek do działu wsparcia AWS. Jeżeli te ograniczenia nie stanowią problemu w twoim konkretnym przypadku, możesz przydzielić każdej odrębnej grupie użytkowników osobny zasobnik S3 i uznać sprawę za załatwioną.
Problemy mogą pojawić się, gdy istnieją grupy o współdzielonej odpowiedzialności lub gdy niektóre osoby potrzebują dostępu do treści z wielu domen jednocześnie. Przykładowo:
- Analitycy danych, analizujący dane z różnych obszarów i regionów.
- Zespół testowy, udostępniający usługi różnym zespołom programistycznym.
- Użytkownicy raportujący, potrzebujący analiz opartych na danych z różnych krajów tego samego regionu.
Jak łatwo sobie wyobrazić, lista ta może rozrastać się w miarę potrzeb organizacji. Im bardziej złożona się staje, tym bardziej skomplikowana musi być orkiestracja praw dostępu, aby zapewnić odpowiednim grupom dostęp do różnych zasobników S3. Konieczne będzie użycie dodatkowych narzędzi, a może nawet dedykowany administrator, aby zarządzać listami uprawnień i aktualizować je przy każdej zmianie (co zdarza się bardzo często, szczególnie w dużych organizacjach).
Jak zatem osiągnąć to samo w bardziej uporządkowany i zautomatyzowany sposób?
Jeśli podejście typu „zasobnik na domenę” nie jest wystarczające, każde inne rozwiązanie będzie polegało na udostępnianiu zasobników dla większej liczby grup użytkowników. W takiej sytuacji konieczne jest zbudowanie logiki nadawania praw dostępu w miejscu, które można łatwo zmieniać i dynamicznie aktualizować.
Jednym ze sposobów na osiągnięcie tego celu jest wykorzystanie tagów w zasobnikach S3. Używanie tagów jest zalecane w każdym przypadku (choćby dla lepszej kategoryzacji kosztów). Tag można zmienić w dowolnym momencie w przyszłości dla dowolnego zasobnika.
Jeśli cała logika jest oparta na tagach zasobników, a reszta jest zależna od konfiguracji wartości tych tagów, uzyskujemy dynamikę, ponieważ przeznaczenie zasobnika można przedefiniować, aktualizując jedynie wartości tagów.
Jakich tagów użyć, aby to zadziałało?
To zależy od konkretnego przypadku użycia. Na przykład:
- Może być konieczne rozdzielenie zasobników według typu środowiska. W takim przypadku jeden z tagów powinien mieć nazwę „ENV” z wartościami „DEV”, „TEST”, „PROD” itd.
- Możesz chcieć rozdzielić zasoby na podstawie kraju. W takiej sytuacji innym tagiem będzie „KRAJ” z odpowiednią nazwą kraju jako wartością.
- Możesz też chcieć oddzielić użytkowników w zależności od ich działu, np. analitycy biznesowi, użytkownicy hurtowni danych, analitycy danych itp. Tworzysz tag „TYP_UŻYTKOWNIKA” z odpowiadającą mu wartością.
- Inną opcją może być zdefiniowanie stałej struktury katalogów dla określonych grup użytkowników (aby nie tworzyli bałaganu w strukturze folderów). Można to zrobić ponownie za pomocą tagów, określając katalogi robocze, takie jak: „dane/import”, „dane/przetworzone”, „dane/błąd” itp.
Idealnie, tagi powinny być tak zdefiniowane, aby można je było łączyć, tworząc całą strukturę katalogów w zasobniku.
Możesz na przykład połączyć następujące tagi, aby utworzyć dedykowaną strukturę katalogów dla różnych typów użytkowników z różnych krajów z predefiniowanymi katalogami importu:
- /
/ / /
Zmieniając wartość
Pozwoli to na używanie tego samego zasobnika przez wiele grup użytkowników. Zasobniki nie obsługują folderów bezpośrednio, ale obsługują „etykiety”. Etykiety te działają ostatecznie jak podfoldery, ponieważ użytkownicy muszą przejść przez serię etykiet, aby dotrzeć do swoich danych (podobnie jak w przypadku podfolderów).
Po zdefiniowaniu tagów w przydatny sposób, następnym krokiem jest stworzenie polityk zasobników S3, które wykorzystują tagi.
Gdy zasady korzystają z nazw tagów, tworzy się tak zwane „zasady dynamiczne”. Oznacza to, że zasady będą działać inaczej w zależności od wartości tagów zasobników, do których się odnoszą za pomocą zmiennych lub symboli zastępczych.
Ten etap obejmuje oczywiście pisanie niestandardowego kodu zasad dynamicznych, ale można go uprościć za pomocą narzędzia edytora zasad Amazon AWS, które przeprowadzi Cię przez ten proces.
W samej polityce należy zakodować konkretne prawa dostępu, które będą stosowane do zasobnika oraz ich poziom (odczyt, zapis). Logika odczyta tagi zasobników i utworzy strukturę folderów (tworząc etykiety na podstawie tagów). Na podstawie konkretnych wartości tagów, utworzone zostaną podfoldery i przydzielone odpowiednie uprawnienia.
Zaletą tej dynamicznej polityki jest możliwość stworzenia jednej takiej polityki i przypisania jej do wielu zasobników. Będzie ona działać inaczej w zależności od wartości tagów danego zasobnika, ale zawsze będzie zgodna z oczekiwaniami dotyczącymi zasobnika o takich wartościach tagów.
Jest to skuteczny sposób zarządzania prawami dostępu w zorganizowany i scentralizowany sposób dla dużej liczby zasobników, gdzie każdy z nich ma działać zgodnie z określonymi z góry szablonami i być używany przez użytkowników w całej organizacji.
Zautomatyzuj proces wdrażania nowych podmiotów
Po zdefiniowaniu polityk dynamicznych i przypisaniu ich do zasobników, użytkownicy mogą zacząć korzystać z tych samych zasobników, bez ryzyka, że osoby z różnych grup uzyskają dostęp do treści (przechowywanej w tym samym zasobniku) w strukturze katalogów, do której nie powinny mieć uprawnień.
Dodatkowo, dla grup z szerszym dostępem, dane będą łatwo dostępne, ponieważ wszystkie będą przechowywane w tym samym zasobniku.
Ostatnim krokiem jest uproszczenie procesu wdrażania nowych użytkowników, zasobników i tagów. Wymaga to dalszego pisania niestandardowego kodu, ale nie musi być on bardzo skomplikowany, zakładając, że proces wdrażania ma jasne zasady, które można ująć w prostą logikę algorytmu (w ten sposób można udowodnić, że proces ma sens, a nie jest chaotyczny).
Może to być tak proste, jak utworzenie skryptu wykonywanego za pomocą polecenia AWS CLI z parametrami potrzebnymi do wdrożenia nowego podmiotu. Może to być nawet seria skryptów CLI, wykonywanych w określonej kolejności, na przykład:
- create_new_bucket(
, , , , ..) - create_new_tag(
, , ) - update_existing_tag(
, , ) - create_user_group(
, ,<środowisko>) - itp.
Chodzi o samą ideę. 😃
Porada profesjonalisty 👨💻
Jeśli chcesz, jest jedna wskazówka, którą można łatwo zastosować.
Polityki dynamiczne można wykorzystać nie tylko do przydzielania uprawnień dostępu do katalogów, ale również do automatycznego przypisywania uprawnień do korzystania z usług dla zasobników i grup użytkowników!
Wystarczy rozszerzyć listę tagów w zasobnikach, a następnie dodać dynamiczne prawa dostępu do polityk, aby korzystać z określonych usług przez konkretne grupy użytkowników.
Przykładowo, może istnieć grupa użytkowników, która potrzebuje dostępu do serwera klastra bazy danych. Można to osiągnąć za pomocą dynamicznych zasad wykorzystujących tagi zasobników, zwłaszcza jeśli dostęp do usług oparty jest na rolach. Należy dodać do kodu polityki dynamicznej element, który przetworzy tagi dotyczące specyfikacji klastra bazy danych i przypisze uprawnienia dostępu bezpośrednio do tego klastra DB i grupy użytkowników.
W ten sposób wdrożenie nowej grupy użytkowników będzie możliwe tylko dzięki jednej dynamicznej polityce. Ponadto, ponieważ jest dynamiczna, ta sama polityka może zostać wykorzystana do wdrożenia wielu różnych grup użytkowników (zakładając, że działają zgodnie z tym samym szablonem, ale niekoniecznie z tymi samymi usługami).
Możesz również rzucić okiem na te polecenia AWS S3 do zarządzania zasobnikami i danymi.