Przygodę z chmurą publiczną rozpocząć jest łatwo – to jedna z wielu jej dobrych cech. “Próg wejścia” nie jest zbyt wysoki – w kilka minut zakładasz konto np. w AWS, bardzo szybko uruchamiasz pierwszą wirtualną maszynę lub dowolny inny serwis.
Co ważne – nie musisz być członkiem ogromnej organizacji, aby zacząć korzystać z chmury. Nie musisz nawet pracować w ŻADNEJ firmie – jesteś Panem samego siebie, w dowolnej chwili każdy z nas może stać się zdobywcą Cloud Computingu. Wielu już tak zrobiło – a Ty? 🙂
Dzisiaj jednak przyjrzymy się bardzo istotnemu tematowi: zarządzaniu kontami AWS w firmie: dużej, średniej, małej – KAŻDEJ.
Początek tej historii jest prosty ? Zaczyna ją wizyta Szefa, który z uśmiechem na ustach oznajmia, iż strona projektu X ma działać w chmurze AWS. Ale Ty jesteś już gotowy na każde wyzwanie – masz prywatny, chmurowy profil, pierwsze treningi za sobą, a może nawet popełniłeś już pierwsze projekty z kategorii “szara strefa”. W przeciągu kilku chwil zakładasz wymagane konto firmowe w AWS.
Kolejne kroki także wyglądają jak z bajki – projektujesz architekturę aplikacji, następnie trafia ona do deweloperów, jeszcze tylko wdrożenie i za chwilę jesteś cześcią firmowego sukcesu. Aplikacja hula jak należy! Ale jak to w życiu bywa – apetyt rośnie w miarę jedzenie i pojawiają się nowe potrzeby. Przychodzi czas na następną aplikację webową, w kolejce ustawia się zapotrzebowanie na przeniesienie środowisk dev/test oraz połączenie wszystkiego z lokalnym data center.
I zaczynają się schody – musisz stworzyć założenia architektury wielośrodowiskowej, pomyśleć o podziale kont, uwzględnić kwestie związane z rozliczaniem kosztów i wiele innych tematów.
Czytaj więc dalej uważnie, gdyż już za chwilę podpowiem Ci, w jaki sposób ułożyć najważniejsze elementy tej arcyciekawej, chmurowej układanki. Do dzieła!
Struktura Kont – Puzzle Dla Dorosłych
Struktura kont w każdej firmie zawsze będzie inna, poszczególne podmioty mają własną charakterystykę działania. Systemy i aplikacje różnią się od siebie, indywidualnie podchodzimy także do kwestii wymiany danych, rozliczania kosztów, bezpieczeństwa i regulacji itd.
Nie zmienia to faktu, iż myśląc o strukturze kont koniecznie weź pod uwagę:
- Kwestie finansowe:
- Kto płaci, w jaki sposób będzie rozliczane wykorzystanie zasobów, kto odpowiada za koszty oraz ich wysokość.
- W jaki sposób możesz zmniejszać i optymalizować opłaty: zakup rezerwacji zasobów, volume discounts.
- Nie wymyślaj koła, posiłkuj się dedykowanymi narzędziami jak np. Trusted Advisor.
- Limity i możliwości platformy chmurowej:
- Czekają na ciebie progi górne i dolne w możliwościach usług AWS.
- Zwróć uwagę na ograniczenia związane z ilością zasobów, jakie możesz uruchomić per konto/region. Uwzględnij limity “miękkie”, które możesz zmieniać oraz fizyczne, na które nie będziesz mieć wpływu.
- Bezpieczeństwo informacji i dostęp do nich:
- Czyli strategiczne ważne (jak zawsze) – zarządzanie dostępem dla użytkowników oraz innych zasobów.
- Dobrze przemyśl przepływ danych między systemami oraz ograniczenia z tym związane.
Przykładowa, modelowa struktura kont została przedstawiona poniżej.
Konta centralne (Central accounts) pełnią role zwane serwisowymi, czyli np. agregują i rozliczają koszty. Mają także zadanie zbierania, zabezpieczania i analizy logów z pozostałych kont oraz uruchomionych w nich systemów. Inne cele to dostarczanie usług współdzielonych jak np. dedykowane połączenie do lokalnego data center.
Rolą pozostałych kont (Use case-based accounts) jest już dostarczanie “prawdziwych” usług. Na tych kontach implementowane są aplikacje i uruchamiane konkretne usługi AWS. Konta te zazwyczaj dzielone są per aplikacje, typy środowisk czy choćby jednostki biznesowe.
Jednak z punktu kosztowego wciąż mamy jedno konto Billingowe, odpowiedzialne za rozliczanie i opłacanie usług AWS. Pozostałe konta są z nim jedynie połączone, co ładnie demonstruje obraz poniżej.
Architektura Sieci – Rozmnażamy Virtual Private Clouds
Kolejnym znaczącym elementem organizacji i zarządzania kontami jest architektura sieci. W ramach każdego z kont należy skonfigurować segmenty sieciowe (tzw. Virtual Private Cloud – VPC), które w zależności od typu konta mogą mieć różne architektury.
Oto przykładowe charakterystyki elementów VPC:
- Niektóre zawierają usługi do użytku wewnętrznego,
- Inne prezentują zasoby do Internetu (aplikacje internetowe),
- Część z nich musi komunikować się między sobą (poprzez np. VPC Peering),
- Dodatkowo, niektóre łączą się z zasobami w lokalnym DC (poprzez VPN, połączenie dedykowane).
Po uwzględnieniu VPC nasza przykładowa topologia kont zyskała kolejne, cenne elementy.
Jak widzisz powyżej konto usług współdzielonych zapewnia połączenie do lokalnego DC. Co więcej – współdzieli to połączenie z innymi kontami, w których aplikacje wymagają np. dostępu do danych w DC czy innych usług jak Active Directory.
Bezpieczeństwo, Ach To Bezpieczeństwo
Teraz dotkniemy bardzo ważnego i czułego aspektu struktury kont AWS – bezpieczeństwa. W tym obszarze nie uda się przedstawić jedynie słusznego wzorca, gdyż duża część konfiguracji będzie (jak zawsze) indywidualna, na co wpływ mają uruchomione na danym koncie usługi.
Dobra wiadomość – na każdym koncie możesz wyróżnić konfigurację bazową, wspólną dla wszystkich. Do takich ustawień należy:
- Kontrola dostępu, polityka haseł, uprawnienia dla administratorów.
- Zabezpieczenie konta root, MFA itp.
- Konfiguracja zbierania logów: CloudTrail, Flog Logs.
- Zarządzanie konfiguracją i wprowadzanymi zmianami: AWS Config.
Ustawienia te kontrolują podstawowe kwestie związane z zabezpieczeniami, w tym ochronę i blokowanie użycia konta root do codziennej pracy. Wydzielenie dedykowanego konta do zbierania i analizy logów pomoże Ci dopilnować, aby logi nie tylko były zbierane, ale również zabezpieczone przed umyślnym bądź nieumyślnym usunięciem.
Wprowadzenie wyżej wspomnianych elementów konfiguracji to implementacja podstawowego zestawu zabezpieczeń. Wszystkie logi z każdego z kont agregowane są na jednym koncie centralnym, do którego dostęp powinny mieć tylko wyznaczone osoby.
Kontrola Dostępu – Co Dla Kogo?
Cieszy fakt, iż każde z kont ma własną konfigurację IAM – katalog użytkowników, grup, uprawnień i ról. Część z tych ustawień będzie wspólna, np. dostęp administracyjny czy operacyjny. Jednak pozostałe opcje konfiguracyjne będą zależne od rodzaju konta. Deweloperzy powinni mieć prawo do środowisk deweloperskich, ale nie produkcyjnych. Do konta z logami wgląd będzie mieć jedynie dział bezpieczeństwa.
Nie zapominajmy też o Active Directory lub innych mechanizmach autentykacji – część z kont będzie wymagała dostępu do nich.
Głowa do góry! Do dyspozycji masz wiele możliwości pomagających zarządzać kontami i kontrolą dostępu:
- Cross-account role – pozwalające nadawawać uprawnienia użytkonikom z jednego konta do zasobów i serwisów na innym koncie (IAM, AWS Directory Service)
- Federated Access – czyli integracja z zewnętrznymi serwisami (tzw. Identity Providers) z wykorzystaniem np SAML.
Oto topologia wzbogacona o kolejne elementy, służące w tym przypadku szeroko rozumianej ochronie.
Konto z usługami współdzielonymi zarządza kontami użytkowników i grupami, ewentualnie integruje się z zewnętrznymi Identity Providers. Dostęp do pozostałych kont AWS zarządzany jest z wykorzystaniem IAM Role.
Na Szczęście – Są Dodatkowe Narzędzia, Jest Automatyzacja
Wiem, do tej pory mnożyliśmy tylko kolejne opcje stale zwiększając trudność zapanowania nad wszystkimi elementami. W kolejnym kroku pomogę Ci zyskać większą kontrolę nad tym procesem i przede wszystkim – znacząco go uprościć. Kluczowymi hasłami będą więc: spójna konfiguracja dla wszystkich kont oraz automatyzacja powtarzających się zadań.
AWS CloudFormation – siła template’u
To bardzo przydatne rozwiązanie, które poprzez przygotowane wcześniej template’y pozwala wdrażać konfigurację w postaci tzw stacków. Dla każdego konta wykorzystywany jest taki sam, zatwierdzony wcześniej template, co daje ogromną pewność, że konfiguracja jest spójna. Przez przyjęty proces weryfikacji, kontroli i akceptacji przechodzi nie tylko postać bazowa template’u ale również wszystkie zmiany, co daje Ci pełną kontrolę nad jego cyklem życia.
AWS CloudFormation StackSets – w stronę większej automatyzacji
Ta opcja pojawiła się stosunkowo niedawno wzbogacając omawianą wcześniej usługę Cloud Formation. Pozwala ona implementować całą grupę stacków na wielu kontach bądź grupach kont zorganizowanych w Organization Unity (ale o tym za chwilę).
W takim wypadku w strukturze naszych kont pojawia się dodatkowe konto administracyjne, którego rolą jest globalna implementacja ustawień.
Dla przykładu – polityka firmy głosi “nie używamy konta root do pracy z AWS”. Dodatkowo, dział security chce mieć pewność, że nikt nie loguje się na to konto. Możesz więc stworzyć template CloudFormation, który wdroży pożądany monitoring logowania na użytkownika root. Zrobienie tego na jednym koncie to nie problem, wyklikasz to szybko. Gdy jednak kont jest już kilka to klikanie w każde po kolei zajmie dużo czasu. I wtedy właśnie świetnie sprawdzi się opcja StackSets, pamiętaj o niej koniecznie!
AWS Organizations
Brawo! Dotarłeś do momentu, gdzie potrafisz zapanować nad zarządzaniem konfiguracją wielu kont. Ale w jaki sposób będziesz mógł uprościć sam proces tworzenia niezbędnych kont i ich wstępnej konfiguracji?
Mam coś dla Ciebie – to AWS Organizations, które jest dedykowanym serwisem do zarządzania kontami AWS oraz grupowania ich w tzw Organization Unit (OU). W ramach zarządzania kontami możesz:
- Tworzyć nowe konta,
- Dodawać konta już istniejące,
- Usuwać konta z organizacji,
- Likwidować/zamykać konta.
Dodatkowo, na konta zgrupowane w OU:
- Nałożysz Service Control Policies – to kontrola, jakie usługi i akcje użytkownicy na danym koncie mogą wykonywać.
- Zaimplementujesz template’y CloudFormation – dzięki integracji z omawianym wcześniej CloudFormation StackSets.
Podsumowanie
Opisane przeze mnie rozwiązania wdrażane są bardzo często w dużych firmach. Ale to nie oznacza, że nie mogą z nich korzystać również te mniejsze.
Mam przekonanie graniczące z pewnością, iż nawet jeżeli Twoja firma stawia swoje pierwsze kroki w chmurze, to już za chwilę kolejne konta zaczną wyrastać jak grzyby po deszczu. Warto od samego początku przemyśleć ich hierarchie, role i metodę zarządzania w odniesieniu do opisanych wcześniej aspektów. Dzięki temu zyskasz łatwiejszą kontrolę nad docelowym środowiskiem chmurowym, niezależnie od jego skali.
W Chmurowisku od samego początku wykorzystujemy serwisy AWS Organizations i CloudFormations ponieważ widzimy, że znacząco ułatwiają one zarządzanie już przy niewielkiej skali.
Pojawią się także przypadki bardziej wymagających firm, gdzie opisane powyżej rozwiązania nie zaspokoją wszystkich potrzeb – zwłaszcza tych nietypowych. Ale nie ma się czym przejmować – platforma AWS łatwo się integruje z innymi narzędziami i dodatkowo pozwala na tworzenie własnych, customowych integracji. W prosty sposób będziesz mógł wzbogacić swoje środowisko o dodatkowe możliwości, obsługa nieszablonowych sytuacji jest jak najbardziej możliwa.
Podsumowując – bez względu na skalę firmy naprawdę warto od samego początku zatroszczyć się o dobre i przemyślane zarządzanie kontami. Trochę więcej pracy na początku to dużo mniej na głowie na dalszych etapach.
I pamiętaj – chmura sama w sobie nie przyspieszy i nie usprawni Twojej pracy. Daje za to narzędzia i możliwości, dzięki którym możesz to osiągnąć. Cheers! ?
TEN ARTYKUŁ UKAZAŁ SIĘ NA ŁAMACH BLOGA CHMUROWISKO.PL
Zbuduje swoje bezpieczne środowisko AWS.
