Udostępnij za pośrednictwem

Tożsamość i nie tylko — punkt widzenia jednego architekta

  • Artykuł

W tym artykule Alex Shteynberg, główny architekt techniczny w firmie Microsoft, omawia najważniejsze strategie projektowania dla organizacji korporacyjnych przyjmujących platformę Microsoft 365 i inne usługi w chmurze firmy Microsoft.

Informacje o autorze

Alex Shteynberg zdjęcie.

Jestem głównym architektem technicznym w New York Microsoft Technology Center. Pracuję głównie z dużymi klientami i złożonymi wymaganiami. Mój punkt widzenia i opinie są oparte na tych interakcjach i mogą nie mieć zastosowania do każdej sytuacji. Jednak z mojego doświadczenia wiem, że jeśli możemy pomóc klientom w rozwiązywaniu najbardziej złożonych wyzwań, możemy pomóc wszystkim klientom.

Zwykle pracuję z ponad 100 klientami każdego roku. Chociaż każda organizacja ma unikatowe cechy, warto zobaczyć trendy i podobieństwa. Na przykład jednym z trendów jest zainteresowanie wielu klientów między branżami. Po tym wszystkim, oddział banku może być również kawiarnia i centrum społeczności.

W mojej roli skupiam się na pomaganiu klientom w dotarciu do najlepszego rozwiązania technicznego w celu osiągnięcia ich unikatowego zestawu celów biznesowych. Oficjalnie skupiam się na tożsamościach, zabezpieczeniach, ochronie prywatności i zgodności. Uwielbiam fakt, że dotykają one wszystkiego, co robimy. Daje mi to możliwość zaangażowania się w większość projektów. To działanie sprawia, że jestem zajęty i cieszę się tą rolą.

Mieszkam w Nowym Jorku (najlepsze!) i naprawdę cieszyć się różnorodnością jego kultury, żywności i ludzi (nie ruchu). Uwielbiam podróżować, kiedy mogę i mam nadzieję zobaczyć większość świata w moim życiu. Obecnie badam podróż do Afryki, aby dowiedzieć się więcej o dzikiej przyrodzie.

Przewodnie

  • Proste jest często lepsze: możesz zrobić (prawie) wszystko za pomocą technologii, ale to nie znaczy, że powinieneś. Szczególnie w obszarze bezpieczeństwa wielu klientów nadmiernie obsługuje rozwiązania. Podoba mi się ten film z konferencji Google Stripe, aby podkreślić ten punkt.
  • Osoby, proces, technologia: projektowanie dla ludzi w celu ulepszenia procesu, a nie technologii. Nie ma żadnych "doskonałych" rozwiązań. Musimy zrównoważyć różne czynniki ryzyka i decyzje, które mogą być różne dla każdej firmy. Zbyt wielu klientów projektuje podejście, których użytkownicy później unikają.
  • Skup się na "dlaczego" najpierw i "jak" później: Bądź irytującym 7-letnim dzieckiem z milionem pytań. Nie możemy uzyskać właściwej odpowiedzi, jeśli nie znamy właściwych pytań do zadawania. Wielu klientów przyjmuje założenia dotyczące tego, jak wszystko musi działać, zamiast definiować problem biznesowy. Zawsze istnieje wiele ścieżek, które można wykonać.
  • Długi koniec poprzednich najlepszych rozwiązań: rozpoznaj, że najlepsze rozwiązania zmieniają się z małą prędkością. Jeśli przyjrzeliśmy się Microsoft Entra ponad trzy miesiące temu, prawdopodobnie jesteś nieaktualny. Wszystko w tym miejscu może ulec zmianie po publikacji. "Najlepsza" opcja dzisiaj może nie być taka sama od sześciu miesięcy.

Pojęcia dotyczące planu bazowego

Nie pomijaj tej sekcji. Często uważam, że muszę cofnąć się do tych artykułów, nawet dla klientów, którzy od lat korzystają z usług w chmurze. Niestety, język nie jest precyzyjnym narzędziem. Często używamy tego samego słowa, aby oznaczać różne pojęcia lub różne słowa, aby oznaczać tę samą koncepcję. Często używam poniższego diagramu, aby ustalić terminologię punktu odniesienia i "model hierarchii".

Ilustracja przedstawiająca dzierżawę, subskrypcję, usługę i dane.

Kiedy nauczysz się pływać, lepiej zacząć w basenie, a nie w środku oceanu. Nie staram się być technicznie dokładne z tego diagramu. Jest to model do omówienia niektórych podstawowych pojęć.

Na diagramie:

  • Tenant = wystąpienie Tożsamość Microsoft Entra. Jest na "górze" hierarchii lub na poziomie 1 na diagramie. Możemy uznać ten poziom za "granicę", w której dzieje się wszystko inne (Microsoft Entra B2B na bok). Wszystkie usługi firmy Microsoft w chmurze dla przedsiębiorstw należą do jednej z tych dzierżaw. Usługi konsumenckie są oddzielne. "Dzierżawa" jest wyświetlana w dokumentacji jako dzierżawa platformy Microsoft 365, dzierżawa platformy Azure, dzierżawa usługi WVD itd. Często uważam, że te odmiany powodują zamieszanie dla klientów.
  • Usługi/subskrypcje, poziom 2 na diagramie, należą do jednej dzierżawy i tylko jednej dzierżawy. Większość usług SaaS ma wartość 1:1 i nie może się poruszać bez migracji. Platforma Azure jest inna. Możesz przenieść rozliczenia i/lub subskrypcję do innej dzierżawy. Istnieje wielu klientów, którzy muszą przenosić subskrypcje platformy Azure. Ten scenariusz ma różne implikacje. Obiekty istniejące poza subskrypcją nie są przenoszone. Na przykład kontrola dostępu oparta na rolach (AZURE RBAC), obiekty Microsoft Entra (grupy, aplikacje, zasady itp.) oraz niektóre usługi (azure Key Vault, cegły danych itp.). Nie migruj usług bez potrzeby biznesowej. Niektóre skrypty, które mogą być przydatne podczas migracji, są udostępniane w usłudze GitHub.
  • Dana usługa zwykle ma pewnego rodzaju granicę "podpoziomu" lub poziom 3 (L3). Ta granica jest przydatna do zrozumienia podziału zabezpieczeń, zasad, ładu itd. Niestety, nie ma jednolitej nazwy, którą znam. Przykładowe nazwy L3 to: Subskrypcja platformy Azure = zasób; Dynamics 365 CE = wystąpienie; Power BI = obszar roboczy; Power Apps = środowisko; itd.
  • Poziom 4 to miejsce, w którym znajdują się rzeczywiste dane. Ta "płaszczyzna danych" to złożony artykuł. Niektóre usługi używają Tożsamość Microsoft Entra rbac, inne nie. Omówię to nieco, gdy przejdziemy do artykułów delegowania.

Niektóre inne pojęcia, które uważam za wiele klientów (i pracowników firmy Microsoft), są zdezorientowane lub mają pytania dotyczące następujących problemów:

  • Każda osoba może utworzyć wiele dzierżaw bez poniesienia kosztów. Nie potrzebujesz usługi aprowizowanej w niej. Mam dziesiątki. Każda nazwa dzierżawy jest unikatowa w globalnej usłudze firmy Microsoft w chmurze (innymi słowy, żadna z dwóch dzierżaw nie może mieć tej samej nazwy). Wszystkie są w formacie TenantName.onmicrosoft.com. Istnieją również procesy, które automatycznie tworzą dzierżawy (dzierżawy niezarządzane). Na przykład ten wynik może wystąpić, gdy użytkownik zarejestruje się w usłudze przedsiębiorstwa z domeną poczty e-mail, która nie istnieje w żadnej innej dzierżawie.
  • W dzierżawie zarządzanej można zarejestrować wiele domen DNS . Ten wynik nie zmienia oryginalnej nazwy dzierżawy. Obecnie nie można łatwo zmienić nazwy dzierżawy (innej niż migracja). Chociaż nazwa dzierżawy nie jest technicznie krytyczna w dzisiejszych czasach, niektórzy ludzie mogą czuć się ograniczeni przez tę rzeczywistość.
  • Należy zarezerwować nazwę dzierżawy dla swojej organizacji, nawet jeśli nie planujesz jeszcze wdrażania żadnych usług. W przeciwnym razie ktoś może go zabrać od Ciebie i nie ma prostego procesu, aby go odzyskać (ten sam problem co nazwy DNS). Słyszę to zbyt często od klientów. Nazwa dzierżawy powinna być również artykułem dyskusyjnym.
  • Jeśli jesteś właścicielem przestrzeni nazw DNS, należy dodać wszystkie te przestrzenie nazw do dzierżaw. W przeciwnym razie można utworzyć dzierżawę niezarządzaną o tej nazwie, co spowoduje zakłócenie zarządzania nią.
  • Przestrzeń nazw DNS (na przykład contoso.com) może należeć do jednej dzierżawy. To wymaganie ma wpływ na różne scenariusze (na przykład udostępnianie domeny poczty e-mail podczas fuzji lub przejęcia itd.). Istnieje sposób zarejestrowania podsystemu DNS (takiego jak div.contoso.com) w innej dzierżawie, ale należy tego unikać. Rejestrując nazwę domeny najwyższego poziomu, zakłada się, że wszystkie poddomeny należą do tej samej dzierżawy. W scenariuszach obejmujących wiele dzierżaw (jak wyjaśniono poniżej) zwykle zalecam użycie innej nazwy domeny najwyższego poziomu (takiej jak contoso.ch lub ch-contoso.com).
  • Kto powinien "posiadać" dzierżawę? Często widzę klientów, którzy nie wiedzą, kto obecnie jest właścicielem dzierżawy. Ten brak wiedzy jest znaczącą czerwoną flagą. Zadzwoń do pomocy technicznej firmy Microsoft jak najszybciej. Równie problematyczne jest, gdy właściciel usługi (często administrator programu Exchange) jest wyznaczony do zarządzania dzierżawą. Dzierżawa zawiera wszystkie usługi, które mogą być potrzebne w przyszłości. Właściciel dzierżawy powinien być grupą, która może podejmować decyzje dotyczące włączania wszystkich usług w chmurze w organizacji. Innym problemem jest monitowanie grupy właścicieli dzierżawy o zarządzanie wszystkimi usługami. Ta metoda nie jest skalowana dla dużych organizacji.
  • Nie ma koncepcji dzierżawy podrzędnej/super. Z jakiegoś powodu ten mit powtarza się. Ta koncepcja dotyczy również dzierżaw usługi Azure Active Directory B2C . Słyszę zbyt wiele razy: "Moje środowisko B2C znajduje się w mojej dzierżawie XYZ" lub "Jak mogę przenieść dzierżawę platformy Azure do mojej dzierżawy platformy Microsoft 365?"
  • Ten dokument koncentruje się głównie na chmurze komercyjnej na całym świecie, ponieważ z tego właśnie korzysta większość klientów. Czasami warto wiedzieć o suwerennych chmurach. Suwerenne chmury mają inne implikacje do omówienia, które są poza zakresem tej dyskusji.

Artykuły dotyczące tożsamości punktu odniesienia

Istnieje wiele dokumentacji dotyczącej platformy tożsamości firmy Microsoft — Tożsamość Microsoft Entra. Dla ludzi, którzy dopiero zaczynają, często czuje się przytłaczające. Nawet po zapoznaniu się z tym, nadążanie za ciągłymi innowacjami i zmianami może być trudne. W moich interakcjach z klientami często uważam się za "tłumacza" między celami biznesowymi a podejściami "Good, Better, Best" w celu rozwiązania tych problemów (i ludzkimi "notatkami z klifu" dla tych artykułów). Rzadko istnieje doskonała odpowiedź, a "właściwa" decyzja jest równowagą różnych czynników ryzyka. Poniżej przedstawiono niektóre z typowych pytań i obszarów pomyłek, które zwykle omawiam z klientami.

Inicjowania obsługi

Tożsamość Microsoft Entra nie rozwiązuje problemu z powodu braku ładu w świecie tożsamości! Ład w zakresie tożsamości powinien być elementem krytycznym niezależnym od wszelkich decyzji w chmurze. Wymagania dotyczące ładu zmieniają się wraz z upływem czasu, dlatego jest to program, a nie narzędzie.

Microsoft Entra Connect a Microsoft Identity Manager (MIM) a czymś innym (inną firmą lub niestandardową)? Zapisz sobie problemy teraz i w przyszłości i przejdź do Microsoft Entra Connect. W tym narzędziu istnieją różne rodzaje rozwiązań inteligentnych, które umożliwiają obsługę specyficznych konfiguracji klientów i ciągłych innowacji.

Niektóre przypadki brzegowe, które mogą prowadzić do bardziej złożonej architektury:

  • Mam wiele lasów usługi AD bez łączności sieciowej między nimi. Istnieje nowa opcja o nazwie Cloud Provisioning.
  • Nie mam usługi Active Directory ani nie chcę jej instalować. Microsoft Entra Connect można skonfigurować do synchronizacji z protokołu LDAP (może być wymagany partner).
  • Muszę aprowizować te same obiekty w wielu dzierżawach. Ten scenariusz nie jest technicznie obsługiwany, ale zależy od definicji "tego samego".

Czy należy dostosować domyślne reguły synchronizacji (filtrować obiekty, zmieniać atrybuty, alternatywny identyfikator logowania itd.)? Unikaj tego! Platforma tożsamości jest tak samo cenna jak usługi, które z niej korzystają. Mimo że możesz wykonywać różnego rodzaju konfiguracje orzechowe, aby odpowiedzieć na to pytanie, musisz przyjrzeć się wpływowi na aplikacje. Jeśli filtrujesz obiekty z obsługą poczty, wartość GAL dla Usługi online jest niekompletna. Jeśli aplikacja korzysta z określonych atrybutów, filtrowanie tych atrybutów ma nieprzewidywalne skutki itd. To nie jest decyzja zespołu ds. tożsamości.

XYZ SaaS obsługuje aprowizację just in time (JIT), dlaczego wymagasz ode mnie synchronizacji? Zobacz poprzedni akapit. Wiele aplikacji wymaga informacji o profilu dla funkcji. Nie można mieć gal, jeśli wszystkie obiekty z włączoną obsługą poczty nie są dostępne. To samo dotyczy aprowizowania użytkowników w aplikacjach zintegrowanych z Tożsamość Microsoft Entra.

Uwierzytelnianie

Synchronizacja skrótów haseł (PHS) a uwierzytelnianie przekazywane (PTA) a federacja.

Zazwyczaj jest namiętna debata wokół federacji. Prostsze jest zwykle lepsze i dlatego używać PHS, chyba że masz dobry powód, aby tego nie robić. Istnieje również możliwość skonfigurowania różnych metod uwierzytelniania dla różnych domen DNS w tej samej dzierżawie.

Niektórzy klienci włączają federację i phs głównie dla:

Często przeprowadzam klientów przez przepływ uwierzytelniania klienta, aby wyjaśnić pewne nieporozumienia. Wynik wygląda podobnie do poniższego obrazu, który nie jest tak dobry jak interaktywny proces dotarcia do tego miejsca.

Przykładowa konwersacja tablicy.

Ten typ rysunku tablicy ilustruje, gdzie zasady zabezpieczeń są stosowane w przepływie żądania uwierzytelniania. W tym przykładzie zasady wymuszane za pośrednictwem usługi Active Directory Federation Service (AD FS) są stosowane do pierwszego żądania obsługi, ale nie do kolejnych żądań obsługi. To zachowanie jest co najmniej jednym z powodów, aby jak najwięcej przenieść mechanizmy kontroli zabezpieczeń do chmury.

Goniliśmy marzenie o logowaniu jednokrotnym (SSO) tak długo, jak pamiętam. Niektórzy klienci uważają, że mogą osiągnąć logowanie jednokrotne, wybierając dostawcę "właściwej" federacji (STS). Tożsamość Microsoft Entra może znacznie pomóc w włączeniu funkcji logowania jednokrotnego, ale żaden sts nie jest magiczny. Istnieje zbyt wiele "starszych" metod uwierzytelniania, które są nadal używane w aplikacjach krytycznych. Rozszerzenie Tożsamość Microsoft Entra o rozwiązania partnerskie może rozwiązać wiele z tych scenariuszy. Logowania jednokrotnego to strategia i podróż. Nie można się tam dostać bez przechodzenia do standardów dla aplikacji. Ten artykuł jest związany z podróżą do uwierzytelniania bez hasła , które również nie ma magicznej odpowiedzi.

Uwierzytelnianie wieloskładnikowe (MFA) jest obecnie niezbędne (tutaj , aby uzyskać więcej informacji). Dodaj do niego analizę zachowań użytkowników i masz rozwiązanie, które zapobiega najczęstszym cyberatakom. Nawet usługi konsumenckie są przenoszone, aby wymagać uwierzytelniania wieloskładnikowego. Nadal jednak spotykam się z wieloma klientami, którzy nie chcą przechodzić do nowoczesnych metod uwierzytelniania . Największym argumentem, jaki słyszę, jest to, że ma to wpływ na użytkowników i starsze aplikacje. Czasami dobry rzut może pomóc klientom poruszać się - Exchange Online ogłosił zmiany. Wiele Microsoft Entra raportów jest teraz dostępnych, aby pomóc klientom w tym przejściu.

Autoryzacji

Zgodnie z wikipedią "autoryzacja" polega na zdefiniowaniu zasad dostępu. Wiele osób patrzy na to jako możliwość definiowania kontroli dostępu do obiektu (pliku, usługi itd.). W obecnym świecie zagrożeń cybernetycznych koncepcja ta szybko ewoluuje w kierunku dynamicznej polityki, która może reagować na różne wektory zagrożeń i szybko dostosowywać mechanizmy kontroli dostępu w odpowiedzi na nie. Jeśli na przykład uzyskam dostęp do konta bankowego z nietypowej lokalizacji, otrzymam dodatkowe kroki potwierdzenia. Aby podejść do tej rzeczywistości, musimy wziąć pod uwagę nie tylko samą politykę, ale także ekosystem metodologii wykrywania zagrożeń i korelacji sygnału.

Aparat zasad Tożsamość Microsoft Entra jest implementowany przy użyciu zasad dostępu warunkowego. Ten system zależy od informacji z innych systemów wykrywania zagrożeń w celu podejmowania dynamicznych decyzji. Prosty widok będzie podobny do poniższej ilustracji:

Aparat zasad w Tożsamość Microsoft Entra.

Połączenie wszystkich tych sygnałów pozwala na dynamiczne zasady, takie jak te:

  • Jeśli na urządzeniu zostanie wykryte zagrożenie, dostęp do danych zostanie ograniczony tylko do Internetu bez możliwości pobrania.
  • Jeśli pobierasz niezwykle dużą ilość danych, wszystko, co pobierasz, jest szyfrowane i ograniczone.
  • Jeśli uzyskujesz dostęp do usługi z urządzenia niezarządzanego, nie masz dostępu do wysoce poufnych danych, ale możesz uzyskiwać dostęp do danych bez ograniczeń bez możliwości kopiowania ich do innej lokalizacji.

Jeśli zgadzasz się z tą rozszerzoną definicją autoryzacji, musisz zaimplementować dodatkowe rozwiązania. Zaimplementowane rozwiązania zależą od tego, jak dynamiczne mają być zasady i jakie zagrożenia chcesz nadać priorytet. Oto kilka przykładów takich systemów:

Oprócz Tożsamość Microsoft Entra różne usługi i aplikacje mają własne modele autoryzacji. Niektóre z tych modeli zostały omówione w dalszej części sekcji delegowania.

Inspekcji

Tożsamość Microsoft Entra ma szczegółowe możliwości inspekcji i raportowania. Jednak te raporty zazwyczaj nie są jedynym źródłem informacji potrzebnych do podejmowania decyzji dotyczących zabezpieczeń. Zobacz więcej dyskusji na ten temat w sekcji delegowania.

Brak programu Exchange

Nie panikuj! Program Exchange nie jest przestarzały (lub program SharePoint itd.). Nadal jest to podstawowa usługa. Mam na myśli to, że od dłuższego czasu dostawcy technologii przechodzą środowiska użytkownika (UX) w celu objęcia składników wielu usług. W usłudze Microsoft 365 prostym przykładem są "nowoczesne załączniki", w których załączniki do wiadomości e-mail są przechowywane w usłudze SharePoint Online lub OneDrive.

Dołączanie pliku do wiadomości e-mail.

Patrząc na klienta programu Outlook, w ramach tego środowiska można zobaczyć wiele usług, które są "połączone", a nie tylko program Exchange. Przykłady obejmują grupy Tożsamość Microsoft Entra, Microsoft Search, Apps, Profile, compliance i Microsoft 365.

Interfejs programu Outlook z objaśnieniami.

Przeczytaj o Elastyczna struktura firmy Microsoft, aby zapoznać się z nadchodzącymi możliwościami. Teraz w wersji zapoznawczej mogę odczytywać konwersacje w usłudze Teams i odpowiadać na nie bezpośrednio w programie Outlook. W rzeczywistości klient usługi Teams jest jednym z bardziej znanych przykładów tej strategii.

Ogólnie rzecz biorąc, coraz trudniej jest wyznaczyć jasną linię między platformą Microsoft 365 a innymi usługami w chmurach firmy Microsoft. Uważam to za wielką korzyść dla klientów, ponieważ mogą oni korzystać z całkowitej innowacji we wszystkim, co robimy, nawet jeśli używają jednego składnika. Całkiem fajne i ma daleko idące implikacje dla wielu klientów.

Obecnie uważam, że wiele grup IT klientów jest ustrukturyzowanych wokół "produktów". Jest to logiczne dla środowiska lokalnego, ponieważ potrzebujesz eksperta dla każdego konkretnego produktu. Jednak cieszę się, że nie muszę debugować bazy danych usługi Active Directory ani programu Exchange, ponieważ te usługi zostały przeniesione do chmury. Automatyzacja (którą zasadniczo jest chmura) usuwa niektóre powtarzające się zadania ręczne (zobacz, co się stało z fabrykami). Jednak te zadania są zastępowane bardziej złożonymi wymaganiami w celu zrozumienia interakcji między usługami, efektu, potrzeb biznesowych itd. Jeśli chcesz się uczyć, transformacja chmury zapewnia ogromne możliwości. Przed przejściem do technologii często rozmawiam z klientami na temat zarządzania zmianami w umiejętnościach IT i strukturach zespołów.

Dla wszystkich fanów i deweloperów programu SharePoint przestań pytać "Jak mogę zrobić XYZ w usłudze SharePoint Online?" Używaj usługi Power Automate (lub Flow) do przepływu pracy, jest to znacznie bardziej zaawansowana platforma. Użyj platformy Azure Bot Framework , aby utworzyć lepsze środowisko użytkownika dla listy elementów 500-K. Zacznij używać programu Microsoft Graph zamiast CSOM. Usługa Microsoft Teams obejmuje program SharePoint, ale także świat bardziej. Istnieje wiele innych przykładów, które mogę wymienić. Jest tam ogromny i wspaniały wszechświat. Otwórz drzwi i rozpocznij eksplorowanie.

Innym typowym efektem jest obszar zgodności. To podejście obejmujące wiele usług wydaje się całkowicie mylić wiele zasad zgodności. Ciągle widzę organizacje, które stwierdzają: "Muszę zapisać wszystkie wiadomości e-mail do systemu zbierania elektronicznych materiałów dowodowych". Co tak naprawdę oznacza ta instrukcja, gdy wiadomość e-mail nie jest już tylko wiadomością e-mail, ale oknem na inne usługi? Platforma Microsoft 365 oferuje kompleksowe podejście do zgodności, ale zmiana osób i procesów jest często znacznie trudniejsza niż technologia.

Istnieje wiele innych osób i implikacje procesu. Moim zdaniem ten czynnik jest krytycznym i niedostatecznie dyskutowanym obszarem. Być może więcej w innym artykule.

Opcje struktury dzierżawy

Jedna dzierżawa a wiele dzierżaw

Ogólnie rzecz biorąc, większość klientów powinna mieć tylko jedną dzierżawę produkcyjną. Istnieje wiele powodów, dla których wiele dzierżaw jest wymagających (nadaj mu wyszukiwanie Bing) lub przeczytaj ten oficjalny dokument. Jednocześnie wielu klientów korporacyjnych, z których pracuję, ma inną (małą) dzierżawę na potrzeby uczenia się, testowania i eksperymentowania IT. Dostęp do platformy Azure między dzierżawami jest łatwiejszy dzięki usłudze Azure Lighthouse. Platforma Microsoft 365 i wiele innych usług SaaS ma limity dla scenariuszy obejmujących wiele dzierżaw. Istnieje wiele do rozważenia w Microsoft Entra scenariuszach B2B.

Wielu klientów kończy działalność z wieloma dzierżawami produkcyjnymi po fuzji i przejęciu (M&A) i chce się skonsolidować. Obecnie nie jest to proste i wymagałoby usług Microsoft Consulting Services (MCS) lub partnera oraz oprogramowania innych firm. Trwają prace inżynieryjne dotyczące różnych scenariuszy z klientami z wieloma dzierżawami w przyszłości.

Niektórzy klienci wybierają więcej niż jedną dzierżawę. To powinna być staranna decyzja i prawie zawsze oparta na przyczynach biznesowych! Przykłady obejmują następujące przyczyny:

  • Struktura firmy typu holdingu, w której łatwa współpraca między różnymi jednostkami nie jest wymagana i istnieje silne potrzeby administracyjne i inne potrzeby w zakresie izolacji.
  • Po przejęciu podejmowana jest decyzja biznesowa o oddzieleniu dwóch jednostek.
  • Symulacja środowiska klienta, które nie zmienia środowiska produkcyjnego klienta.
  • Opracowywanie oprogramowania dla klientów.

W tych scenariuszach obejmujących wiele dzierżaw klienci często chcą zachować taką samą konfigurację w różnych dzierżawach lub raportować zmiany konfiguracji i dryfy. Często oznacza to przejście od ręcznych zmian do konfiguracji jako kodu. Obsługa usługi Microsoft Premiere oferuje warsztaty dotyczące tego typu wymagań opartych na tym publicznym adresie IP: https://Microsoft365dsc.com.

Wiele obszarów geograficznych

Do wielu obszarów geograficznych lub nie do wielu obszarów geograficznych. To jest pytanie. Za pomocą rozwiązania Microsoft 365 Multi-Geo można aprowizować i przechowywać dane magazynowane w lokalizacjach geograficznych, które zostały określone w celu spełnienia wymagań dotyczących przechowywania danych . Istnieje wiele nieporozumień dotyczących tej możliwości. Należy pamiętać o następujących kwestiach:

  • Nie zapewnia korzyści z wydajności. Może to pogorszyć wydajność, jeśli projekt sieci nie jest poprawny. Pobierz urządzenia "blisko" do sieci firmy Microsoft, niekoniecznie do danych.
  • Nie jest to rozwiązanie dotyczące zgodności z RODO. RODO nie koncentruje się na niezależności danych ani lokalizacjach magazynu. Istnieją inne struktury zgodności dotyczące niezależności danych lub lokalizacji magazynu.
  • Nie rozwiązuje delegowania administracji (patrz poniżej) ani barier informacyjnych.
  • Nie jest to to samo, co wiele dzierżaw i wymaga większej liczby przepływów pracy aprowizacji użytkowników .
  • Nie przenosi dzierżawy (twojej Tożsamość Microsoft Entra) do innej lokalizacji geograficznej.

Delegowanie administracji

W większości dużych organizacji separacja obowiązków i kontroli dostępu opartej na rolach (RBAC) jest niezbędną rzeczywistością. Z wyprzedzeniem przeproszę. To działanie nie jest tak proste, jak niektórzy klienci. Wymagania dotyczące klientów, przepisów prawnych, zgodności i innych są różne i czasami są sprzeczne na całym świecie. Prostota i elastyczność często znajdują się po przeciwnych stronach. Nie zmyl mnie, możemy zrobić lepszą robotę w tym celu. W czasie nastąpiła (i będzie) znacząca poprawa. Odwiedź lokalne Centrum technologii Firmy Microsoft , aby wypracować model, który spełnia Twoje wymagania biznesowe bez konieczności czytania 379 230 dokumentów! Tutaj skupiam się na tym, o czym należy myśleć, a nie na tym, dlaczego tak jest. Zbliża się pięć różnych obszarów do zaplanowania i niektóre z typowych pytań, które napotykam.

centra administracyjne Tożsamość Microsoft Entra i platformy Microsoft 365

Istnieje długa i rosnąca lista wbudowanych ról. Każda rola składa się z listy uprawnień ról pogrupowanych w celu umożliwienia wykonywania określonych akcji. Te uprawnienia można wyświetlić na karcie "Opis" wewnątrz każdej roli. Alternatywnie możesz zobaczyć bardziej czytelną dla człowieka wersję tych uprawnień w centrum Administracja Microsoft 365. Nie można modyfikować definicji wbudowanych ról. Ogólnie rzecz biorąc, pogrupuję te role w trzy kategorie:

  • administrator globalny: Ta rola "wszystkie zaawansowane" powinna być wysoce chroniona, tak jak w innych systemach. Typowe zalecenia obejmują: brak stałego przypisania i używanie Microsoft Entra Privileged Identity Management (PIM); silne uwierzytelnianie itd. Co ciekawe, ta rola domyślnie nie zapewnia dostępu do wszystkich elementów. Zwykle widzę nieporozumienia dotyczące dostępu do zgodności i dostępu do platformy Azure, omówione później. Jednak ta rola zawsze może przypisywać dostęp do innych usług w dzierżawie.
  • Administratorzy określonych usług: niektóre usługi (Exchange, SharePoint, Power BI itd.) korzystają z ról administracyjnych wysokiego poziomu z Tożsamość Microsoft Entra. To zachowanie nie jest spójne we wszystkich usługach i później omówiono więcej ról specyficznych dla usługi.
  • Funkcjonalne: istnieje długa (i rosnąca) lista ról skoncentrowanych na określonych operacjach (osoba zapraszana gości itd.). Okresowo więcej tych ról jest dodawanych w zależności od potrzeb klientów.

Nie można delegować wszystkich elementów (chociaż różnica maleje), co oznacza, że rola administratora globalnego musiałaby być czasami używana. Zamiast członkostwa osób w tej roli należy rozważyć konfigurację jako kod i automatyzację.

Uwaga: Centrum administracyjne platformy Microsoft 365 ma bardziej przyjazny dla użytkownika interfejs, ale ma podzestaw możliwości w porównaniu do środowiska administratora Microsoft Entra. Oba portale używają tych samych ról Microsoft Entra, więc zmiany są wprowadzane w tym samym miejscu. Porada: jeśli chcesz mieć interfejs użytkownika administratora skoncentrowany na zarządzaniu tożsamościami bez bałaganu na platformie Azure, użyj polecenia https://aad.portal.azure.com.

Co jest w nazwie? Nie przyjmuj założeń z nazwy roli. Język nie jest precyzyjnym narzędziem. Celem powinno być zdefiniowanie operacji, które należy delegować przed sprawdzeniem, jakie role są potrzebne. Dodanie kogoś do roli "Czytelnik zabezpieczeń" nie powoduje wyświetlenia ustawień zabezpieczeń we wszystkim.

Możliwość tworzenia ról niestandardowych jest typowym pytaniem. Ta funkcja jest obecnie ograniczona w Microsoft Entra (jak wyjaśniono później), ale z czasem zwiększy możliwości. Uważam, że te role niestandardowe mają zastosowanie do funkcji w Tożsamość Microsoft Entra i mogą nie obejmować "w dół" modelu hierarchii (jak wcześniej wspomniano). Za każdym razem, gdy mam do czynienia z "niestandardowe", mam tendencję do powrotu do mojego dyrektora "proste jest lepsze."

Innym typowym pytaniem jest możliwość określania zakresu ról do podzbioru katalogu. Jednym z przykładów jest "Administrator pomocy technicznej tylko dla użytkowników w UE". Jednostki administracyjne mają na celu rozwiązanie tego scenariusza. Jak wcześniej opisano, uważam, że te zakresy mają zastosowanie do funkcji w Tożsamość Microsoft Entra i mogą nie obejmować "w dół". Zakres niektórych ról nie ma sensu (administratorzy globalni, administratorzy usług itd.).

Obecnie wszystkie te role wymagają bezpośredniego członkostwa (lub przypisania dynamicznego, jeśli używasz Microsoft Entra pim). Oznacza to, że klienci muszą zarządzać tą rolą bezpośrednio w Tożsamość Microsoft Entra, a te role nie mogą być oparte na członkostwie w grupie zabezpieczeń. Nie jestem fanem tworzenia skryptów do zarządzania tymi rolami, ponieważ musi być uruchamiany z podwyższonym poziomem uprawnień. Ogólnie zalecam integrację interfejsu API z systemami przetwarzania, takimi jak ServiceNow, lub przy użyciu narzędzi do zarządzania partnerami, takich jak Saviynt. Trwają prace inżynieryjne nad rozwiązaniem tego problemu w czasie.

Wspomniałem o Microsoft Entra PIM kilka razy. Istnieje odpowiednie rozwiązanie Microsoft Identity Manager (MIM) Privileged Access Management (PAM) dla kontrolek lokalnych. Warto również przyjrzeć się stacjom roboczym z dostępem uprzywilejowanym (PAW) i Zarządzanie tożsamością Microsoft Entra. Istnieją również różne narzędzia innych firm, które mogą włączyć just in time, just-enough i dynamiczne podniesienie roli. Ta funkcja jest zwykle częścią szerszej dyskusji na temat zabezpieczania środowiska.

Czasami scenariusze wymagają dodania użytkownika zewnętrznego do roli (zobacz poprzednią sekcję z wieloma dzierżawami). Ten wynik działa dobrze. Microsoft Entra B2B to kolejny duży i zabawny artykuł do chodzenia klientów, być może w innym artykule.

portale zgodności usługi Microsoft Defender XDR i Microsoft 365 Purview

Email & role współpracy w portalu Microsoft Defender i *Grupy ról dla rozwiązań Microsoft Purview w portalu zgodności usługi Microsoft 365 Purview są kolekcją "grup ról", które różnią się od ról Microsoft Entra. Może to być mylące, ponieważ niektóre z tych grup ról mają taką samą nazwę jak role Microsoft Entra (na przykład Czytelnik zabezpieczeń), ale mogą mieć inne członkostwo. Wolę korzystać z ról Microsoft Entra. Każda grupa ról składa się z co najmniej jednej "ról" (zobacz, co mam na myśli w przypadku ponownego użycia tego samego słowa?) i mają członków z Tożsamość Microsoft Entra, które są obiektami z obsługą poczty e-mail. Ponadto można utworzyć grupę ról o takiej samej nazwie jak rola, która może lub nie może zawierać tej roli (unikaj tego pomyłek).

W pewnym sensie te uprawnienia są ewolucją modelu grup ról programu Exchange. Jednak Exchange Online ma własny interfejs zarządzania grupami ról. Niektóre grupy ról w Exchange Online są zablokowane i zarządzane z Tożsamość Microsoft Entra lub portali zgodności usługi Microsoft Defender XDR i Microsoft 365 Purview, ale inne mogą mieć takie same lub podobne nazwy i są zarządzane w Exchange Online (dodawanie do pomyłek). Zalecam unikanie używania Exchange Online interfejsu użytkownika, chyba że potrzebujesz zakresów do zarządzania programem Exchange.

Nie można tworzyć ról niestandardowych. Role są definiowane przez usługi utworzone przez firmę Microsoft i rosną w miarę wprowadzania nowych usług. To zachowanie jest podobne w koncepcji do ról zdefiniowanych przez aplikacje w Tożsamość Microsoft Entra. Po włączeniu nowych usług często należy tworzyć nowe grupy ról, aby przyznać lub delegować do nich dostęp (na przykład do zarządzania ryzykiem wewnętrznym.

Te grupy ról również wymagają bezpośredniego członkostwa i nie mogą zawierać Microsoft Entra grup. Niestety, obecnie te grupy ról nie są obsługiwane przez Microsoft Entra PIM. Podobnie jak w przypadku ról Microsoft Entra, zalecam zarządzanie tymi grupami ról za pośrednictwem interfejsów API lub produktu ładu partnera, takiego jak Saviynt lub inne.

Microsoft Defender portalu i portalu microsoft 365 Purview role portalu zgodności obejmują platformę Microsoft 365 i nie można określić zakresu tych grup ról do podzestawu środowiska (tak jak w przypadku jednostek administracyjnych w Tożsamość Microsoft Entra). Wielu klientów pyta, w jaki sposób mogą subdelegate. Na przykład "utwórz zasady DLP tylko dla użytkowników z UE". Obecnie, jeśli masz prawa do określonej funkcji w portalach zgodności usługi Microsoft Defender XDR i Microsoft 365 Purview, masz prawa do wszystkich elementów objętych tą funkcją w dzierżawie. Jednak wiele zasad ma możliwości kierowania do podzestawu środowiska (na przykład "udostępnij te etykiety tylko tym użytkownikom"). Prawidłowy ład i komunikacja są kluczowym składnikiem umożliwiającym uniknięcie konfliktów. Niektórzy klienci decydują się zaimplementować podejście "konfiguracja jako kod", aby rozwiązać problem z poddelegacją w portalach zgodności usługi Microsoft Defender XDR i Microsoft 365 Purview. Niektóre określone usługi obsługują poddelegację (zobacz następną sekcję).

Specyficzna dla usługi

Jak wspomniano wcześniej, wielu klientów chce osiągnąć bardziej szczegółowy model delegowania. Typowy przykład: "Zarządzanie usługą XYZ tylko dla użytkowników i lokalizacji w dziale X" (lub inny wymiar). Możliwość wykonania tej operacji zależy od każdej usługi i nie jest spójna między usługami i możliwościami. Ponadto każda usługa może mieć oddzielny i unikatowy model RBAC. Zamiast omawiać wszystkie te modele (co trwałoby wiecznie), dodaję odpowiednie linki dla każdej usługi. Ta lista nie jest kompletna, ale może rozpocząć pracę.

  • Exchange Online — (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online — (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams — (/microsoftteams/itadmin-readiness)
  • eDiscovery — (.. /compliance/index.yml)
    • Filtrowanie uprawnień — (.. /compliance/index.yml)
    • Granice zgodności — (.. /compliance/set-up-compliance-boundaries.md)
    • eDiscovery (Premium) — (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage — (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-geo — (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 — (/dynamics365/)

Uwaga

Ten link znajduje się w katalogu głównym dokumentacji. Istnieje wiele typów usług z odmianami w modelu administratora/delegowania.

  • Power Platform — (/power-platform/admin/admin-documentation)

    • Power Apps — (/power-platform/admin/wp-security)

      Uwaga

      Istnieje wiele typów z odmianami w modelach administratora/delegowania.

    • Power Automate — (/power-automate/environments-overview-admin)

    • Power BI — (/power-bi/service-admin-governance)

      Uwaga: zabezpieczenia i delegowanie platformy danych (które jest składnikiem usługi Power BI) to złożony obszar.

  • Intune — (/mem/intune/fundamentals/role-based-access-control)

  • Ochrona punktu końcowego w usłudze Microsoft Defender — (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR — (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps — (/cloud-app-security/manage-admins)

  • Stream — (/stream/assign-administrator-user-role)

  • Bariery informacyjne — (.. /compliance/information-barriers.md)

Dzienniki aktywności

Platforma Microsoft 365 ma ujednolicony dziennik inspekcji. Jest to bardzo szczegółowy dziennik, ale nie odczytaj zbyt wiele w nazwie. Może nie zawierać wszystkiego, czego potrzebujesz lub czego potrzebujesz, aby spełniać wymagania dotyczące zabezpieczeń i zgodności. Ponadto niektórzy klienci są bardzo zainteresowani inspekcją (Premium).

Przykłady dzienników platformy Microsoft 365, do których uzyskuje się dostęp za pośrednictwem innych interfejsów API, obejmują następujące funkcje:

Ważne jest, aby najpierw zidentyfikować wszystkie źródła dzienników potrzebne do programowania zabezpieczeń i zgodności. Należy również pamiętać, że różne dzienniki mają różne limity przechowywania on-line.

Z perspektywy delegowania administratora większość dzienników aktywności platformy Microsoft 365 nie ma wbudowanego modelu RBAC. Jeśli masz uprawnienia do wyświetlenia dziennika, możesz zobaczyć w nim wszystko. Typowym przykładem wymagań klienta jest: "Chcę mieć możliwość wykonywania zapytań tylko dla użytkowników z UE" (lub innego wymiaru). Aby osiągnąć to wymaganie, musimy przenieść dzienniki do innej usługi. W chmurze firmy Microsoft zalecamy przeniesienie go do usługi Microsoft Sentinel lub usługi Log Analytics.

Diagram wysokiego poziomu:

diagram źródeł dzienników dla programu zabezpieczeń i zgodności.

Diagram przedstawia wbudowane możliwości wysyłania dzienników do usług Event Hubs i/lub Azure Storage i/lub Azure Log Analytics. Nie wszystkie systemy zawierają to gotowe do użycia. Istnieją jednak inne metody wysyłania tych dzienników do tego samego repozytorium. Na przykład zobacz Ochrona aplikacji Teams za pomocą usługi Microsoft Sentinel.

Połączenie wszystkich dzienników w jednej lokalizacji magazynu obejmuje dodatkowe korzyści, takie jak korelacje krzyżowe, niestandardowe czasy przechowywania, rozszerzanie o dane potrzebne do obsługi modelu RBAC itd. Gdy dane są w tym systemie magazynu, możesz utworzyć pulpit nawigacyjny usługi Power BI (lub inny typ wizualizacji) przy użyciu odpowiedniego modelu RBAC.

Dzienniki nie muszą być kierowane tylko do jednego miejsca. Korzystne może być również zintegrowanie dzienników platformy Microsoft 365 z Microsoft Defender for Cloud Apps lub niestandardowym modelem RBAC w usłudze Power BI. Różne repozytoria mają różne korzyści i odbiorców.

Warto wspomnieć, że w usłudze o nazwie Microsoft Defender XDR istnieje bogaty wbudowany system analizy zabezpieczeń, zagrożeń, luk w zabezpieczeniach itd.

Wielu dużych klientów chce przenieść te dane dziennika do systemu innej firmy (na przykład SIEM). Istnieją różne podejścia do tego wyniku, ale ogólnie Azure Event Hubs i Graph są dobrymi punktami początkowymi.

Azure

Często pojawia się pytanie, czy istnieje sposób rozdzielenia ról o wysokich uprawnieniach między Tożsamość Microsoft Entra, platformą Azure i usługą SaaS (np. administrator globalny dla platformy Microsoft 365, ale nie platformy Azure). Nie do końca. Architektura wielodostępna jest wymagana, jeśli wymagana jest całkowita separacja administracyjna, ale zwiększa to znaczną złożoność (jak wspomniano wcześniej). Wszystkie te usługi są częścią tej samej granicy zabezpieczeń/tożsamości (jak pokazano w modelu hierarchii).

Ważne jest, aby zrozumieć relacje między różnymi usługami w tej samej dzierżawie. Pracuję z wieloma klientami, którzy budują rozwiązania biznesowe obejmujące platformę Azure, Microsoft 365 i power platformę (a często także usługi lokalne i usługi w chmurze innych firm). Jeden typowy przykład:

  1. Chcę współpracować nad zestawem dokumentów/obrazów/itp. (Microsoft 365)
  2. Wysyłanie każdego z nich w procesie zatwierdzania (Power Platform)
  3. Po zatwierdzeniu wszystkich składników zmontuj te elementy w ujednolicone elementy dostarczane (azure) microsoft interfejs Graph API jest najlepszym przyjacielem tutaj. Nie jest to niemożliwe, ale znacznie bardziej złożone do projektowania rozwiązania obejmującego wiele dzierżaw.

Usługa Azure Role-Based Access Control (RBAC) umożliwia szczegółowe zarządzanie dostępem do platformy Azure. Korzystając z kontroli dostępu opartej na rolach, możesz zarządzać dostępem do zasobów, udzielając użytkownikom najmniejszej liczby uprawnień wymaganych do wykonywania zadań. Szczegóły tego dokumentu są poza zakresem, ale aby uzyskać więcej informacji na temat kontroli dostępu opartej na rolach, zobacz Co to jest kontrola dostępu oparta na rolach (RBAC) na platformie Azure? Kontrola dostępu oparta na rolach jest ważna, ale tylko część zagadnień dotyczących ładu dla platformy Azure. Cloud Adoption Framework jest doskonałym punktem wyjścia, aby dowiedzieć się więcej. Podoba mi się, jak mój przyjaciel, Andres Ravinet, prowadzi klientów krok po kroku przez różne składniki, aby zdecydować się na podejście. Widok wysokiego poziomu dla różnych elementów (nie tak dobry jak proces uzyskiwania rzeczywistego modelu klienta) jest podobny do następującego:

Widok wysokiego poziomu składników platformy Azure na potrzeby administracji delegowanej.

Jak widać na powyższym obrazie, wiele innych usług należy traktować jako część projektu (np. Azure Policies, Azure Blueprints, Grupy zarządzania itd.).

Wniosku

Ten artykuł rozpoczął się jako krótkie podsumowanie, które zakończyło się dłużej, niż się spodziewałem. Mam nadzieję, że teraz możesz zapoznać się z szczegółowym omówieniem tworzenia modelu delegowania dla organizacji. Ta konwersacja jest bardzo powszechna w przypadku klientów. Nie ma jednego modelu, który działa dla wszystkich. Czekanie na kilka planowanych ulepszeń inżynierii firmy Microsoft przed udokumentowaniem typowych wzorców, które widzimy w różnych klientach. W międzyczasie możesz współpracować z zespołem ds. konta Microsoft, aby zorganizować wizytę w najbliższym Centrum technologii Firmy Microsoft. Do zobaczenia!