Zabezpieczenia Azure Lighthouse i uprawnienia: jak bezpiecznie zarządzać dostępem do chmury w wielu dzierżawach
By Mirko Peters ·
Dowiedz się, jak działają zabezpieczenia Azure Lighthouse, jak egzekwować zasadę najmniejszych uprawnień w wielu dzierżawach oraz jak klienci zachowują pełną kontrolę nad swoją chmurą.
Automatically translated with AI from the original post. Read the English original

Zabezpieczenia Azure Lighthouse opierają się na zasadzie najmniejszych uprawnień, logicznych projekcjach zasobów oraz ściśle kontrolowanych przez klienta granicach, dzięki czemu dostawcy usług zarządzanych mogą obsługiwać środowiska chmury w wielu dzierżawach, nigdy nie posiadając haseł administratorów. Wykorzystują wbudowane role Azure i trwałe ślady audytowe.
Najważniejsze wnioski
- Klienci zachowują pełną kontrolę nad swoimi dzierżawami Azure, definiując precyzyjne zakresy i wbudowane role.
- Definicje i przypisania rejestracji działają jak trwały mechanizm uzgadniania, który Azure sprawdza przy każdej operacji.
- Pełne role Owner oraz dostęp do warstwy danych są w delegacjach Azure Lighthouse całkowicie nieobsługiwane.
- Dostawcy działają za pomocą logicznych projekcji we własnym portalu, nie udostępniając haseł ani poświadczeń użytkowników.
- Dzienniki aktywności rejestrują każdą zmianę w dzierżawie klienta, zapewniając przejrzysty ślad audytowy.
Architektura zabezpieczeń Azure Lighthouse
Zarządzanie wieloma środowiskami chmury wymagało tradycyjnie tworzenia dedykowanych kont administratorskich w każdej dzierżawie klienta. Ta dawna metoda wiązała się z poważnym ryzykiem bezpieczeństwa, rozproszonymi arkuszami z hasłami tymczasowymi oraz zapomnianymi poświadczeniami pozostającymi w systemach zewnętrznych. Azure Lighthouse zasadniczo zmienia ten model, wprowadzając bezpieczne, kryptograficznie powiązane przejście między oddzielnymi światami chmury.
Zamiast łączyć dzierżawy lub udostępniać poświadczenia, Lighthouse wykorzystuje logiczną projekcję. Zasoby klienta pozostają w całości w jego własnym środowisku chmury – w jego dzierżawie, subskrypcji i grupach zasobów. Dostawca usług zarządzanych widzi te zasoby przez bezpieczne przejście ze swojej dzierżawy zarządzającej. Każde żądanie wysłane przez dostawcę przechodzi przez główną warstwę walidacji Azure, która stale sprawdza dokumentację autoryzacyjną, zanim pozwoli na wykonanie jakiegokolwiek polecenia.
Uzgadnianie w dwóch elementach
Zabezpieczenia w Azure Lighthouse nie opierają się na ślepym zaufaniu; są oparte na dwóch niezmiennych plikach konfiguracyjnych w formacie JSON, wdrażanych bezpośrednio przez administratora najwyższego poziomu klienta.
Pierwszym elementem jest definicja rejestracji. Ten dokument znajduje się w koncie klienta i szczegółowo określa, która zewnętrzna organizacja jest zaufana oraz jakie konkretne wbudowane role otrzymuje. Drugim elementem jest przypisanie rejestracji, które pełni funkcję adresu, wskazując definicję konkretnej subskrypcji lub grupie zasobów.
Ponieważ te komponenty znajdują się w dzierżawie klienta, to klient ma pełną kontrolę. Jeśli umowa dobiegnie końca, klient może usunąć przypisanie rejestracji, natychmiast blokując dostęp bez konieczności współpracy z dostawcą usług.
Wdrażanie zasady najmniejszych uprawnień w środowiskach wielodzierżawczych
Zasadą fundamentalną nowoczesnego bezpieczeństwa chmury jest zasada najmniejszych uprawnień, czyli przydzielanie użytkownikom i systemom wyłącznie minimum uprawnień niezbędnych do wykonywania ich zadań. Azure Lighthouse ułatwia egzekwowanie tej zasady, przypisując uprawnienia do grup zabezpieczeń, jednostek usługi i kont automatyzacji, a nie do poszczególnych użytkowników.
Na przykład dostawca usług zarządzanych może podzielić dostęp swojego zespołu na odrębne poziomy:
- Zespół wsparcia: Otrzymuje rolę Czytelnik, dzięki której może sprawdzać kondycję maszyn wirtualnych i dzienniki diagnostyczne bez wprowadzania zmian.
- Inżynierowie migracji: Otrzymują rolę Współautor w określonych grupach zasobów, aby wdrażać obciążenia i stosować aktualizacje.
- Skrypty automatyzacji: Otrzymują zawężone niestandardowe konta usługi, aby wykonywać nocne kopie zapasowe i zbierać dane telemetryczne.
Ten szczegółowy podział gwarantuje, że błąd ludzki lub przejęte poświadczenia po stronie dostawcy nie mogą spowodować katastrofalnych szkód we wszystkich zarządzanych środowiskach klientów.
Ograniczenia wbudowanych ról jako zabezpieczenia
Aby chronić organizacje przed nadmiernym przydzielaniem uprawnień, Azure Lighthouse egzekwuje ścisłe ograniczenia dotyczące tego, co można, a czego nie można delegować. Przede wszystkim rola najwyższego poziomu Właściciel jest w delegowaniu Lighthouse całkowicie nieobsługiwana. Dostawca nigdy nie może otrzymać możliwości przypisywania uprawnień innym osobom ani przejęcia pełnej własności subskrypcji klienta.
Ponadto role przyznające dostęp do płaszczyzn danych, na przykład odczyt plików w kontenerach Azure Blob Storage czy przeglądanie rekordów bazy danych, nie mogą być delegowane za pośrednictwem Lighthouse. Lighthouse zarządza płaszczyznami sterowania infrastrukturą, dzięki czemu nadzór administracyjny nigdy nie wykracza poza granicę naruszenia prywatności danych.
Ścieżki audytu i śledzenie zgodności
Osoby odpowiedzialne za zgodność często wpadają w panikę na myśl o dostępie zewnętrznych dostawców do kluczowej infrastruktury chmurowej przedsiębiorstwa. Azure Lighthouse łagodzi ten niepokój, prowadząc skrupulatny, odporny na manipulacje ślad po stronie klienta.
Każde działanie wykonane przez użytkownika dostawcy, czy to ponowne uruchomienie maszyny wirtualnej, zmiana reguły zapory, czy aktualizacja ustawień sieciowych, jest zapisywane bezpośrednio w dzienniku Azure Activity Log klienta. Ponieważ dzienniki te znajdują się w dzierżawie klienta, zewnętrzny dostawca nie może ich zmienić ani usunąć. Administratorzy IT mogą przeprowadzać regularne audyty, aby odpowiedzieć na kluczowe pytania dotyczące bezpieczeństwa: Kto miał dostęp do tego zasobu? Kiedy został zmodyfikowany? Jakie dokładnie polecenie zostało wykonane?
Ponadto przedsiębiorstwa mogą połączyć Azure Lighthouse z usługą Privileged Identity Management (PIM), aby wymagać podwyższania uprawnień na żądanie (just-in-time). Zamiast stale posiadać uprawnienia Współautora, inżynierowie dostawcy mogą zażądać dostępu wyłącznie w momencie wystąpienia incydentu, przy czym zatwierdzenia są rejestrowane, a limity czasowe egzekwowane automatycznie.
Podsumowanie
Azure Lighthouse rozwiązuje wieloletnie napięcie między solidnym bezpieczeństwem chmury a wydajnym zarządzaniem wieloma dzierżawami. Zastępując udostępnianie haseł kryptograficznie weryfikowanym, kontrolowanym przez klienta delegowanym zarządzaniem zasobami, liderzy IT mogą skalować swoje operacje bez kompromitowania poziomu bezpieczeństwa. Aby poznać podstawowe koncepcje tej architektury, koniecznie posłuchaj pełnego odcinka podcastu M365 FM, który w przystępny sposób, bez żargonu, wyjaśnia nowoczesne zarządzanie chmurą.
Często zadawane pytania
Czy dostawca Azure Lighthouse może zobaczyć hasła mojej organizacji?
Nie. Azure Lighthouse nigdy nie ujawnia, nie przesyła ani nie udostępnia haseł ani poświadczeń użytkowników między dzierżawami. Dostawcy uwierzytelniają się za pomocą własnych systemów tożsamości przedsiębiorstwa, a działają na Twoich zasobach dzięki logicznym projekcjom.
Co się dzieje z dostępem Azure Lighthouse, jeśli dostawca zostanie zhakowany?
Ponieważ dostęp jest ściśle ograniczony do konkretnych wbudowanych ról i zasobów zdefiniowanych w przypisaniu rejestracji, a rola Właściciel jest wykluczona, zasięg potencjalnych szkód pozostaje ściśle ograniczony. Ponadto klient może natychmiast cofnąć dostęp, usuwając przypisanie rejestracji we własnym portalu.
Czy Azure Lighthouse obsługuje niestandardowe role RBAC?
Nie. Azure Lighthouse obsługuje wyłącznie wbudowane role platformy Azure udostępniane przez firmę Microsoft. Niestandardowych ról utworzonych w dzierżawie dostawcy lub klienta nie można użyć w definicjach rejestracji.
Kto ma uprawnienia do skonfigurowania Azure Lighthouse w dzierżawie klienta?
Tylko użytkownik z uprawnieniami wysokiego poziomu – konkretnie konto z uprawnieniami do przypisywania ról na poziomie subskrypcji lub grupy zasobów, takimi jak User Access Administrator lub Owner – może wdrożyć szablon rejestracji i nawiązać połączenie.