Artykuł pochodzi z wydania: Maj 2023
Wiele organizacji nadal traktuje przejście do chmury z dużą dozą sceptycyzmu. Warto jednak zastanowić się, czy utrzymując witrynę internetową lub serwery pocztowe u zewnętrznych dostawców, przypadkiem od dawna już się w niej nie znajdują.
Kwestie funkcjonowania w chmurze niezmiennie wywołują sporo znaków zapytania. Jeszcze więcej pojawi się ich przy próbie przeniesienia zasobów do chmury publicznej. W niniejszym artykule pokażemy, w jaki sposób rozwiązać problemy zgodności na przykładzie środowiska Microsoftu.
Tuż przed Wielkanocą pojawiła się informacja, że firma uruchomiła polski region dla swojej chmury Azure, dzięki czemu możemy uruchamiać niektóre usługi na terenie naszego kraju. W kontekście np. zgodności przetwarzania danych z rozmaitymi regulacjami słowo „możemy” jest tutaj kluczowe. Chmura Microsoftu ma zasięg globalny. Mamy możliwość uruchamiania przeróżnych usług w serwerowniach zlokalizowanych w wielu zakątkach świata. Oprócz umiejscowienia usługi pojawiają się inne zagrożenia, np. łatwe udostępnienie usługi lub serwera w sieci publicznej. Nowe możliwości chmury wiążą się niestety z kolejnymi niebezpieczeństwami bądź błędami, które możemy popełnić na etapie konfiguracji.
Organizacja zasobów
Każdą usługę lub serwis, które chcemy uruchomić w Azure, należy umieścić w odpowiedniej grupie zasobów. To rozwiązanie pozwala na ich logiczne organizowanie, a także na delegowanie uprawnień oraz przypisywanie zasad. Wszystkie zasoby w ramach jednej grupy mają taki sam cykl życia, ponieważ usuwając ją, pozbywamy się również wszystkich znajdujących się w niej usług.
Grupa zasobów może obejmować wszystkie usługi potrzebne do uruchomienia i utrzymania konkretnej aplikacji, np. konta magazynu do przechowywania danych, maszyny bądź sieci wirtualnej czy bramy aplikacji. Innym przykładem wykorzystania grup zasobów może być podział ze względu na delegowanie uprawnień – jedna grupuje wówczas wszystkie usługi sieciowe, a inna usługi przetwarzania danych. W tym drugim przypadku można np. przekazać uprawnienia do zarządzania poszczególnymi zasobami różnym zespołom administratorów. Scenariuszy można oczywiście przytoczyć znacznie więcej.
Każdy zasób musi znajdować się w grupie. Warto w tym miejscu podkreślić, że tylko w jednej. Nie można znajdować się jednocześnie w dwóch grupach. Można natomiast przenosić usługi między nimi, choć w tej kwestii istnieją pewne ograniczenia. Zanim jednak zajmiemy się przemieszczaniem zasobów, powinniśmy zapoznać się z dokumentacją. Grupy umiejscowione są w subskrypcjach podpiętych pod konto Azure. Zaznaczmy, że jedno konto może mieć wiele subskrypcji. Można wdrażać do nich grupy zarządzania, czyli logiczne kontenery, do których przypisywane są subskrypcje. Grupy mogą tworzyć strukturę hierarchiczną złożoną z dziewięciu poziomów, do których możemy przypisywać odpowiednie uprawnienia oraz kontrolować zgodność za pomocą zasad. Informacje o logicznej strukturze zasobów w chmurze są istotne w kontekście wdrażania zasad.
Zgodność przetwarzania
Na administratorów uruchamiających zasoby w chmurze czekają nowe wyzwania, wynikające z wielu możliwości konfiguracyjnych, regulacji prawnych lub wewnętrznych procedur. Na przykład – na maszynie wirtualnej wdrażamy aplikację, która będzie przetwarzała dane osobowe. W tym przypadku mamy konkretne ograniczenia – ustawa wymusza, by dane były przetwarzane na terenie Unii Europejskiej oraz dodatkowo wewnętrznie narzucamy sobie np. obowiązek przechowywania dzienników transakcyjnych przez okres dziesięciu lat w systemie uniemożliwiającym ich modyfikację. Dodatkowo wewnętrzne procedury zakładają, że aplikacja nie może być dostępna przez publiczny adres IP z pominięciem zapory ogniowej. Podobne problemy mogą dotyczyć tworzenia zasobów w środowisku lokalnym, może z wyjątkiem umieszczenia zasobów poza terytorium Polski, chyba że posiadamy centra danych zlokalizowane w innym kraju.
W rozwiązaniu problemów zgodności i wymuszania standardów w całej organizacji pomocą służy Azure Policy (Zasady). Usługa pozwala na wdrażanie standardów na podstawie wbudowanych lub utworzonych przez siebie definicji zasad. Zasadami można zarządzać za pomocą portalu administracyjnego Azure oraz narzędziami PowerShell i Azure CLI (Command-Line Interface). Szablony wszystkich wbudowanych zasad dostępne są pod linkiem Definicje w obszarze Tworzenie. Po wybraniu tego linku pojawi się lista wszystkich wbudowanych oraz utworzonych przez nas zasad i inicjatyw. Za pomocą PowerShella listę wszystkich definicji zasad otrzymamy, uruchamiając polecenie: Get-AzPolicyDefinition.
Zasada jest opisem wymagań lub zgodności zasobów realizowanym w formacie JavaScript Object Notation (JSON). Platforma Azure dostarcza wielu wbudowanych definicji zasad, pozwalając jednocześnie organizacjom tworzyć własne bądź importować je z platformy GitHub. Zasada definiuje wymagania w stosunku do jej zasobów. Mogą one wymuszać właściwą konfigurację lub sygnalizować pożądaną. W pierwszym przypadku, gdy administrator tworzy nowy zasób, który nie odpowiada wymaganiom zasady, usługa kontrolująca dostęp do zasobów zablokuje tę operację. Jeżeli zasada „sygnalizuje” pożądaną konfigurację, ARM (Azure Resource Manager) pozwoli utworzyć zasób nawet w sytuacji, w której nie jest on zgodny z pożądaną konfiguracją. Dzięki temu działaniu uzyskujemy informacje na temat zgodności zasobów z wdrożonymi zasadami.
[…]
Marek Krupa
Autor jest niezależnym konsultantem oraz szkoleniowcem w zakresie usług chmurowych, zarządzania systemami informatycznymi oraz ochrony danych osobowych.
