Zabezpieczanie środowiska platformy Azure
Teraz, gdy już wiesz, jak kontrolować środowiska i zabezpieczać potoki wdrażania, możesz rozważyć wyłączenie dostępu człowieka do kontrolowanych środowisk. W tej lekcji dowiesz się, jak strukturę uprawnień użytkowników do środowisk platformy Azure. W tym, jak zezwolić na dostęp w sytuacjach awaryjnych i jak przeprowadzać inspekcję wszelkich zmian w infrastrukturze platformy Azure.
Blokuj dostęp człowieka
Blokując dostęp człowieka do kontrolowanych środowisk, upewnij się, że przypadkowe lub złośliwe zmiany nie mogą pominąć przeglądu zespołu i zautomatyzowanych procesów wdrażania. Jeśli nie zablokujesz dostępu człowieka, ktoś może przypadkowo obejść mechanizmy kontroli, które spędziłeś tyle czasu na planowaniu i wdrażaniu w całym repozytorium i potokach.
Bez blokowania kontrolek można również łatwo, aby ktoś przypadkowo coś złamał. Załóżmy na przykład, że użytkownik ma dwie kopie otwartego portalu Azure. Jeden jest przeznaczony dla środowiska testowego, a drugi jest przeznaczony dla środowiska produkcyjnego. Gdy użytkownik przełącza się z powrotem i z powrotem między kartami przeglądarki, łatwo jest je przypadkowo wprowadzić zmiany w środowisku produkcyjnym, które zostały przeznaczone dla środowiska testowego.
Aby zablokować dostęp człowieka, możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure. W kontroli dostępu opartej na rolach można utworzyć przypisania ról w celu zdefiniowania:
- Którzy użytkownicy, grupy lub jednostki usługi mogą uzyskiwać dostęp do zdefiniowanego zestawu zasobów platformy Azure ( zakresu).
- Co użytkownicy, grupy lub jednostki usługi mogą zrobić, gdy uzyskują dostęp do zasobów ( roli).
Kontrola dostępu oparta na rolach platformy Azure udostępnia wiele wbudowanych typów ról, w tym:
- Czytelnik, który ma dostęp tylko do odczytu do środowiska.
- Współautor, który może modyfikować zasoby.
- Właściciel, który może modyfikować zasoby i udzielać dostępu innym osobom.
Ważne jest, aby udzielić dostępu w odpowiednim zakresie. Jeśli Twoja organizacja stosuje zalecaną praktykę korzystania z dedykowanych subskrypcji platformy Azure dla każdego środowiska, rozważ użycie grup zarządzania platformy Azure w celu uproszczenia zakresu przypisań ról. Jeśli Twoja organizacja korzysta z jednej subskrypcji platformy Azure dla wszystkich Twoich środowisk, unikaj udzielania ludziom dostępu do całej subskrypcji, ponieważ wszystkie zasoby, w tym środowiska kontrolowane, dziedziczą to uprawnienie.
Napiwek
Przypisania ról to zasoby usługi Azure Resource Manager (ARM). Oznacza to, że można skonfigurować przypisania ról RBAC platformy Azure w kodzie, na przykład przy użyciu Bicep.
Podczas planowania przypisań ról musisz zdecydować, co ma sens dla twojej organizacji. Załóżmy na przykład, że organizacja tworzy oddzielne subskrypcje dla każdego środowiska. Możesz przyznać administratorom i deweloperom dostęp czytelnika do kontrolowanych środowisk. Dzięki tej roli mogą oni uzyskiwać dostęp do środowiska produkcyjnego w witrynie Azure Portal, aby przejrzeć konfigurację zasobów, wyświetlić metryki i dzienniki oraz zbadać problemy lub błędy bez wprowadzania żadnych zmian w środowisku.
Poniżej przedstawiono sposób konfigurowania przypisań ról dla środowisk firmy toy, zarówno dla administratorów platformy Azure, jak i deweloperów, którzy piszą kod i skrypty:
| Nazwa środowiska | Poziom kontroli | uprawnienie Administracja istrator | Uprawnienie dewelopera |
|---|---|---|---|
| Opracowywanie zawartości | Kontrolowane | Czytelnik | Czytelnik |
| Przetestuj | Kontrolowane | Czytelnik | Czytelnik |
| Przygotowanie | Kontrolowane | Czytelnik | Czytelnik |
| Produkcyjne | Kontrolowane | Czytelnik | Czytelnik |
| Wersja demonstracyjna | Niekontrolowane | Właściciel | Współautor |
| Testowanie wydajności | Niekontrolowane | Właściciel | Brak |
| Testy penetracyjne | Niekontrolowane | Właściciel | Brak |
| Przeglądy żądań ściąg | Niekontrolowane | Właściciel | Właściciel |
| Piaskownice programowania | Niekontrolowane | Właściciel | Właściciel |
Podczas planowania przypisań ról upewnij się, że dokładnie je testujesz. Czasami operacje zarządzania mogą wymagać uprawnień, które nie są oczywiste. Nadaj członkom zespołu możliwość testowania wszystkich codziennych prac z uprawnieniami, których planujesz użyć. Przejrzyj wszelkie problemy, które występują.
Regularnie przeprowadzaj inspekcję przypisań ról. Upewnij się, że nie udzielono ci przypadkowo dostępu do niewłaściwych osób lub udzielono dostępu, który jest zbyt szeroki.
Dostęp do płaszczyzny danych
Istnieją dwa typy operacji na platformie Azure:
- Operacje płaszczyzny sterowania w celu zarządzania zasobami w ramach subskrypcji.
- Operacje płaszczyzny danych w celu uzyskania dostępu do funkcji udostępnianych przez zasób.
Na przykład użyjesz operacji płaszczyzny sterowania, aby utworzyć konto magazynu. Użyjesz operacji płaszczyzny danych, aby nawiązać połączenie z kontem magazynu i uzyskać dostęp do zawartych w nim danych.
W przypadku blokowania bezpośredniego dostępu użytkowników do zasobów platformy Azure należy również rozważyć, jak to ograniczenie dotyczy operacji płaszczyzny danych. Na przykład proces wdrażania może przechowywać klucz konta magazynu w miejscu, do którego administrator może uzyskać dostęp. Ten administrator może potencjalnie użyć klucza, aby obejść kontrolę i uzyskać bezpośredni dostęp do płaszczyzny danych konta magazynu.
Coraz większa liczba zasobów platformy Azure obsługuje konfigurowanie kontroli dostępu do płaszczyzny danych przy użyciu identyfikatora Entra firmy Microsoft. Ta obsługa zmniejsza prawdopodobieństwo wycieku kluczy lub nieumyślnego udzielenia dostępu do płaszczyzny danych. Dobrym rozwiązaniem jest użycie identyfikatora Entra firmy Microsoft do uzyskiwania dostępu do płaszczyzny danych wszędzie tam, gdzie można.
Dostęp awaryjny
Czasami zdarza się sytuacja kryzysowa i ktoś musi szybko uzyskać dostęp do środowiska produkcyjnego w celu zbadania lub rozwiązania problemu. Ważne jest, aby zaplanować i sprawdzić, jak chcesz reagować na te sytuacje awaryjne na znacznie przed ich wystąpieniem. Nie chcesz walczyć, aby odpowiedzieć w środku awarii.
Jednym z podejść do rozważenia jest konto typu break-glass, które jest specjalnym kontem użytkownika, które ma wyższe poziomy uprawnień niż zwykle użytkownicy. Nazywa się to kontem o nazwie break-glass , ponieważ wymaga czegoś niezwykłego, aby uzyskać dostęp do jego poświadczeń, podobnie jak łamiąc szkło na panelu alarmowym. Możesz zapewnić bezpieczny sposób dla operatorów, aby uzyskać dostęp do poświadczeń dla konta break-glass. Te operatory mogą następnie zalogować się jako konto w celu przeprowadzenia zmian awaryjnych.
Sekwencja kroków dotyczących korzystania z konta z szklenia jest następująca:
- Użytkownik próbuje dokonać zmiany awaryjnej przy użyciu normalnego konta, ale operacja jest zablokowana, ponieważ normalne konto użytkownika nie ma wystarczających uprawnień.
- Użytkownik uzyskuje dostęp do poświadczeń konta break-glass i loguje się jako ten użytkownik.
- Użytkownik (działający jako konto z szklenia) może wykonać operację.
Korzystanie z kont z break-glass wymaga wysokiego poziomu dyscypliny. Ich stosowanie powinno być zarezerwowane w rzeczywistych sytuacjach awaryjnych. Starannie zarządzaj poświadczeniami i chroń je, ponieważ konto jest wysoce uprzywilejowane. Dobrym rozwiązaniem jest częste zmienianie poświadczeń dla kont z szklenia, aby zminimalizować ryzyko ujawnienia lub naruszenia zabezpieczeń.
Konta break-glass są często udostępniane w zespole, więc trudno jest prześledzić, kto ich użył i co zrobili ci użytkownicy. Alternatywnym podejściem do kont z break-glass jest wdrożenie funkcji Microsoft Entra Privileged Identity Management (PIM). Umożliwia tymczasowe przyznanie użytkownikowi uprawnień wyższego poziomu uprawnień.
Sekwencja kroków dotyczących korzystania z usługi PIM to:
Użytkownik próbuje dokonać zmiany awaryjnej przy użyciu normalnego konta, ale operacja jest zablokowana, ponieważ normalne konto użytkownika nie ma wystarczających uprawnień.
Użytkownik kontaktuje się z usługą PIM i żąda tymczasowego podniesienia uprawnień.
Usługa PIM może przeprowadzić dalszą walidację tożsamości użytkownika lub poprosić o zatwierdzenie od kogoś, w zależności od tego, jak jest on skonfigurowany dla organizacji.
Jeśli żądanie jest autoryzowane, usługa PIM tymczasowo aktualizuje uprawnienia użytkownika.
Użytkownik może wykonać operację.
Po upływie zdefiniowanego okresu usługa PIM odwołuje podwyższone uprawnienia przyznane użytkownikowi.
Zarówno usługa PIM, jak i platforma Azure zapisują kompleksowe dzienniki inspekcji, aby ułatwić zrozumienie, kto zażądał podniesionych uprawnień i dlaczego. Dzienniki śledzą również, co zrobili w twoim środowisku po udzieleniu uprawnień.
Uwaga
Usługa PIM wymaga licencji Premium dla identyfikatora Entra firmy Microsoft.
Po zakończeniu sytuacji awaryjnej
Po zakończeniu awarii ważne jest, aby proces powrotu do normalnych operacji. Należy postępować zgodnie z tym procesem przed upływem zbyt dużej ilości czasu lub ryzykować zapomnienie ważnych informacji lub pozostawienie konfiguracji w stanie niezabezpieczonym.
Dokładnie przejrzyj dzienniki inspekcji platformy Azure i usługi PIM, aby zrozumieć zmiany, które zostały wykonane w kontrolowanych środowiskach, a zwłaszcza środowisko produkcyjne.
Ważne
Osoba, która korzysta z usługi PIM lub konta ze szkła, może mieć możliwość udzielenia konta zwykłego użytkownika szerszego dostępu niż powinno. Mogą również używać tymczasowych uprawnień, aby uzyskać dostęp do kluczy płaszczyzny danych, które mogą nadal używać po odwołaniu uprawnień.
Dokładnie przeprowadź inspekcję wszystkich zastosowań kont z break-glass lub PIM. Odwoływanie lub obracanie wszystkich kluczy, które mogły zostać ujawnione w nagłych wypadkach.
Wkrótce po awarii ponownie zsyncchronizuj zasoby infrastruktury jako kodu z wszelkimi zmianami, które zostały wprowadzone w nagłych wypadkach. Załóżmy na przykład, że w ramach rozwiązania pilnego problemu administrator ręcznie zwiększył jednostkę SKU planu usługi aplikacja systemu Azure. Zaktualizuj szablony wdrażania, aby uwzględnić nową jednostkę SKU w konfiguracji zasobów. W przeciwnym razie podczas następnego regularnego wdrażania z potoku jednostka SKU może zostać zresetowana do poprzedniej wartości i spowodować inną awarię.
Przeprowadzanie inspekcji zmian w środowisku platformy Azure
Dobrym rozwiązaniem jest również skonfigurowanie inspekcji i rejestrowania w całym środowisku platformy Azure oraz monitorowanie pod kątem określonych zdarzeń lub zagrożeń.
Rozważ użycie narzędzia do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM), takiego jak Microsoft Sentinel. To narzędzie służy do zbierania i analizowania dzienników z majątku platformy Azure, a nawet z usług Azure DevOps, GitHub i innych systemów. Usługa Sentinel umożliwia monitorowanie nieoczekiwanych lub nieautoryzowanych zmian zasobów platformy Azure. Możesz również zaimportować dzienniki inspekcji potoku i wyzwolić alerty w przypadku wystąpienia zdarzeń, na przykład gdy administrator zmieni zasady ochrony gałęzi w repozytorium.