Planowanie rozwiązania do weryfikacji Zweryfikowany identyfikator Microsoft Entra

Usługa Zweryfikowany identyfikator Microsoft Entra firmy Microsoft (Microsoft Entra VC) umożliwia ufanie dowodom tożsamości użytkownika bez rozszerzania granicy zaufania. Za pomocą programu Microsoft Entra VC można tworzyć konta lub federować z innym dostawcą tożsamości. Gdy rozwiązanie implementuje wymianę weryfikacji przy użyciu weryfikowalnych poświadczeń, umożliwia aplikacjom żądanie poświadczeń, które nie są powiązane z określoną domeną. Takie podejście ułatwia żądanie i weryfikowanie poświadczeń na dużą skalę.

Jeśli jeszcze tego nie zrobiono, zalecamy przejrzenie przeglądu architektury Zweryfikowany identyfikator Microsoft Entra. Chcesz również zapoznać się z artykułem Planowanie rozwiązania do wystawiania Zweryfikowany identyfikator Microsoft Entra.

Zakres wskazówek

Ta zawartość obejmuje techniczne aspekty planowania weryfikowalnego rozwiązania do weryfikacji poświadczeń przy użyciu produktów i usług firmy Microsoft. Interfejsy rozwiązania z systemem zaufania, w którym obecnie obsługiwana jest sieć Web DID. DID Web to scentralizowana infrastruktura kluczy publicznych.

Technologie pomocnicze, które nie są specyficzne dla rozwiązań weryfikacji, są poza zakresem. Na przykład witryny internetowe są używane w weryfikowalnym rozwiązaniu do weryfikacji poświadczeń, ale planowanie wdrożenia witryny internetowej nie zostało szczegółowo omówione.

Podczas planowania rozwiązania weryfikacji należy rozważyć, jakie możliwości biznesowe są dodawane lub modyfikowane. Należy również wziąć pod uwagę możliwości IT, które można użyć ponownie, oraz możliwości, które należy dodać, aby utworzyć rozwiązanie. Należy również rozważyć, jakie szkolenia są potrzebne dla osób zaangażowanych w proces biznesowy oraz osób, które obsługują użytkowników końcowych i pracowników rozwiązania. Te artykuły nie są omówione w tej zawartości. Zalecamy zapoznanie się z platformą Microsoft Azure Well-Architected Framework , aby uzyskać informacje dotyczące tych artykułów.

Składniki rozwiązania

W ramach planu rozwiązania weryfikacji należy włączyć interakcje między weryfikatorem, podmiotem i wystawcą. W tym artykule terminy jednostki uzależnionej i weryfikatora są używane zamiennie. Na poniższym diagramie przedstawiono składniki architektury weryfikacji.

usługa Zweryfikowany identyfikator Microsoft Entra

W kontekście rozwiązania weryfikatora usługa Zweryfikowany identyfikator Microsoft Entra jest interfejsem między składnikami rozwiązania firmy Microsoft a systemem zaufania. Usługa aprowizuje klucz ustawiony na usługę Key Vault, aprowizuje identyfikator zdecentralizowany (DID).

Dzierżawa Microsoft Entra

Usługa wymaga dzierżawy firmy Microsoft Entra, która zapewnia płaszczyznę kontroli zarządzania tożsamościami i dostępem (IAM) dla zasobów platformy Azure, które są częścią rozwiązania. Każda dzierżawa firmy Microsoft Entra używa usługi Zweryfikowany identyfikator Microsoft Entra z wieloma dzierżawami i wystawia pojedynczy dokument DID reprezentujący weryfikatora. Jeśli masz wiele jednostek uzależnionych korzystających z usługi weryfikacji, wszystkie używają tego samego weryfikatora DID. Weryfikator DID udostępnia wskaźniki do klucza publicznego, który umożliwia podmiotom i wystawcom weryfikowanie komunikatów pochodzących z jednostki uzależnionej.

Azure Key Vault

Usługa Azure Key Vault przechowuje klucze weryfikatora, które są generowane po włączeniu usługi wystawiania Zweryfikowany identyfikator Microsoft Entra. Klucze są używane do zapewnienia zabezpieczeń komunikatów. Każdy weryfikator ma jeden zestaw kluczy używany do podpisywania, aktualizowania i odzyskiwania komputerów wirtualnych. Ten zestaw kluczy jest używany za każdym razem, gdy wykonujesz żądanie weryfikacji. Zestaw kluczy firmy Microsoft używa obecnie kryptografii krzywej eliptycznej (ECC) SECP256k1. Eksplorujemy inne schematy podpisów kryptograficznych, które są przyjęte przez szerszą społeczność DID.

Interfejs API usługi żądania

Interfejsy programowania aplikacji (API) zapewniają deweloperom metodę abstrakcji interakcji między składnikami rozwiązania w celu wykonywania operacji weryfikacji.

System zaufania

obecnie obsługuje Zweryfikowany identyfikator Microsoft EntraDID Web as a trust system, gdzie dokument DID jest hostowany na serwerze internetowym wystawców.

Aplikacja Microsoft Authenticator

Microsoft Authenticator to aplikacja mobilna. Aplikacja Authenticator organizuje interakcje między użytkownikiem, usługą Zweryfikowany identyfikator Microsoft Entra a kontraktem używanym do wystawiania komputerów wirtualnych. Działa jako portfel cyfrowy, w którym posiadacz VC przechowuje VC, w tym klucz prywatny podmiotu VC. Authenticator jest również mechanizmem używanym do prezentowania komputerów wirtualnych do weryfikacji.

Jednostka uzależniona (RP)

Fronton sieci Web

Fronton internetowy jednostki uzależnionej używa interfejsu API usługi żądań do weryfikowania maszyn wirtualnych przez generowanie linków bezpośrednich lub kodów QR używanych przez portfel podmiotu. W zależności od scenariusza fronton może być publicznie dostępny lub wewnętrzną witryną internetową, aby umożliwić użytkownikom końcowym środowiska wymagające weryfikacji. Jednak punkty końcowe, do których uzyskuje dostęp portfel, muszą być publicznie dostępne. W szczególności steruje przekierowaniem do portfela z określonymi parametrami żądania.

Logika biznesowa

Możesz utworzyć nową logikę lub użyć istniejącej logiki specyficznej dla jednostki uzależnionej i ulepszyć logikę przy użyciu prezentacji komputerów wirtualnych.

Projekty specyficzne dla scenariusza

Poniżej przedstawiono przykłady projektów spełniających określone przypadki użycia. Pierwszą z nich jest dołączanie kont, używane do skrócenia czasu, kosztów i ryzyka związanego z dołączaniem nowych pracowników. Drugi to odzyskiwanie konta, które umożliwia użytkownikowi końcowemu odzyskanie lub odblokowanie konta przy użyciu mechanizmu samoobsługi. Trzeci jest przeznaczony do uzyskiwania dostępu do aplikacji i zasobów o wysokiej wartości, w szczególności w przypadku przypadków użycia biznesowych, w których dostęp jest udzielany osobom pracującym dla innych firm.

Dołączanie konta

Poświadczenia weryfikowalne mogą służyć do szybszego dołączania, zastępując niektóre interakcje człowieka. Komputery wirtualne mogą służyć do dołączania pracowników, uczniów, obywateli lub innych osób w celu uzyskania dostępu do usług. Na przykład zamiast pracownika, który musi przejść do biura centralnego, aby aktywować wskaźnik pracownika, może użyć vc, aby zweryfikować swoją tożsamość w celu aktywowania wskaźnika dostarczonego do nich zdalnie. Zamiast obywatel otrzymuje kod, który musi zrealizować w celu uzyskania dostępu do usług rządowych, może użyć VC, aby udowodnić swoją tożsamość i uzyskać dostęp.

Inne elementy

Portal dołączania: fronton internetowy, który organizuje interfejs API usługi żądań, wywołuje prezentację i walidację VC oraz logikę dołączania kont.

Logika niestandardowa/przepływy pracy: określona logika z krokami specyficznymi dla organizacji przed i po zaktualizowaniu konta użytkownika. Przykłady mogą obejmować przepływy pracy zatwierdzania, inne weryfikacje, rejestrowanie, powiadomienia itd.

Docelowe systemy tożsamości: repozytoria tożsamości specyficzne dla organizacji, z którymi portal dołączania musi korzystać podczas dołączania tematów. Systemy do integracji są określane na podstawie rodzajów tożsamości, które chcesz dołączyć z weryfikacją VC. Typowe scenariusze weryfikacji tożsamości na potrzeby dołączania obejmują:

• Tożsamości zewnętrzne dołączane przez firmę Microsoft Entra ID przy użyciu interfejsów API do wydawania zaproszeń między firmami (B2B) lub przypisywania zarządzania upoważnieniami do pakietów.

• Tożsamości pracowników, które w scentralizowanych systemach tożsamości są już dołączane za pośrednictwem systemów zasobów ludzkich (HR). W takim przypadku weryfikacja tożsamości może zostać zintegrowana w ramach istniejących etapów przepływów pracy kadr.

Zagadnienia dotyczące projektowania

• Wystawca: dołączanie konta jest dobrym rozwiązaniem dla zewnętrznej usługi sprawdzania tożsamości jako wystawcy maszyn wirtualnych. Przykłady kontroli dołączania obejmują: sprawdzanie aktualności, sprawdzanie poprawności dokumentu wydanego przez instytucje rządowe, adres lub potwierdzenie numeru telefonu itd.

• Przechowywanie atrybutów VC: jeśli to możliwe, nie przechowuj atrybutów z komputerów wirtualnych w magazynie specyficznym dla aplikacji. Należy zachować szczególną ostrożność w przypadku danych osobowych. Jeśli określone przepływy w aplikacjach wymagają tych informacji, rozważ pobranie oświadczeń na żądanie przez vc.

• Korelacja atrybutów VC z systemami zaplecza: podczas definiowania atrybutów VC za pomocą wystawcy ustanów mechanizm korelowania informacji w systemie zaplecza po przedstawieniu vc przez użytkownika. Mechanizm zazwyczaj używa powiązanego czasowo, unikatowego identyfikatora w kontekście rp w połączeniu z odbieranymi oświadczeniami. Kilka przykładów:

  • Nowy pracownik: gdy przepływ pracy kadr osiągnie punkt, w którym wymagane jest sprawdzanie tożsamości, dostawca zasobów może wygenerować link z unikatowym identyfikatorem powiązanym czasowo. Następnie rp wysyła go na adres e-mail kandydata w systemie KADR. Ten unikatowy identyfikator powinien być wystarczający do skorelowania informacji, takich jak firstName, lastName z żądania weryfikacji VC do rekordu HR lub danych bazowych. Atrybuty w VC mogą służyć do ukończenia atrybutów użytkownika w systemie KADR lub do weryfikowania dokładności atrybutów użytkownika dotyczących pracownika.

  • Tożsamości zewnętrzne — zaproszenie: gdy użytkownik zewnętrzny zostanie zaproszony do systemu docelowego, dostawca usług sieciowych może wygenerować link z unikatowym identyfikatorem reprezentującym transakcję zaproszenia. Ten link można wysłać na adres e-mail użytkownika zewnętrznego. Ten unikatowy identyfikator powinien być wystarczający, aby skorelować żądanie weryfikacji VC z rekordem zaproszenia lub podstawowymi danymi i kontynuować przepływ pracy aprowizacji. Atrybuty w vc mogą służyć do sprawdzania poprawności lub ukończenia atrybutów użytkownika zewnętrznego.

  • Tożsamości zewnętrzne — samoobsługa: gdy tożsamości zewnętrzne zarejestrują się w systemie docelowym za pośrednictwem samoobsługi (na przykład aplikacji B2C), atrybuty w vc mogą służyć do wypełniania początkowych atrybutów konta użytkownika. Atrybuty VC mogą również służyć do ustalenia, czy profil już istnieje.

• Interakcja z docelowymi systemami tożsamości: komunikacja między frontonem internetowym a docelowymi systemami tożsamości musi być zabezpieczona jako wysoce uprzywilejowany system, ponieważ może tworzyć konta. Udziel frontonowi sieci Web możliwie najmniej uprzywilejowanych ról. Przykłady obejmują:

  • Aby utworzyć nowego użytkownika w usłudze Microsoft Entra ID, witryna internetowa rp może użyć jednostki usługi, która ma przyznany zakres User.ReadWrite.All MS Graph do tworzenia użytkowników, oraz zakres UserAuthenticationMethod.ReadWrite.All resetowania metody uwierzytelniania.

  • Aby zaprosić użytkowników do identyfikatora Entra firmy Microsoft przy użyciu współpracy B2B, witryna internetowa rp może użyć jednostki usługi, która ma przyznany zakres User.Invite.All MS Graph do tworzenia zaproszeń.

  • Jeśli dostawca zasobów działa na platformie Azure, użyj tożsamości zarządzanych, aby wywołać program Microsoft Graph. Użycie tożsamości zarządzanych powoduje usunięcie ryzyka związanego z zarządzaniem poświadczeniami jednostki usługi w kodzie lub plikach konfiguracji. Aby dowiedzieć się więcej o tożsamościach zarządzanych, zobacz Tożsamości zarządzane dla zasobów platformy Azure.

Uzyskiwanie dostępu do aplikacji o wysokiej wartości w organizacjach

Poświadczenia weryfikowalne mogą służyć jako inny dowód dostępu do poufnych aplikacji w organizacji. Na przykład komputery wirtualne mogą być również używane do zapewniania pracownikom dostępu do aplikacji biznesowych w oparciu o osiągnięcie określonych kryteriów, takich jak certyfikacja.

Inne elementy

Fronton internetowy jednostki uzależnionej: jest to fronton internetowy aplikacji, która jest rozszerzona za pomocą interfejsu API usługi żądań na potrzeby prezentacji i walidacji VC na podstawie wymagań biznesowych.

Logika autoryzacji dostępu użytkowników: warstwa logiki w aplikacji, która autoryzuje dostęp użytkowników i jest rozszerzona o używanie atrybutów użytkownika wewnątrz vc w celu podejmowania decyzji dotyczących autoryzacji.

Inne usługi zaplecza i zależności: reprezentuje pozostałą część logiki aplikacji, która zwykle pozostaje niezmieniona przez włączenie weryfikacji tożsamości za pośrednictwem maszyn wirtualnych.

Zagadnienia dotyczące projektowania

• Cel: cel scenariusza określa, jakiego rodzaju poświadczenia i wystawca jest potrzebny. Typowe scenariusze obejmują:

  • Autoryzacja: W tym scenariuszu użytkownik przedstawia vc do podjęcia decyzji o autoryzacji. Komputery wirtualne przeznaczone do weryfikacji ukończenia szkolenia lub posiadania określonego certyfikatu są dobrym rozwiązaniem dla tego scenariusza. Atrybuty VC powinny zawierać szczegółowe informacje sprzyjające podejmowaniu decyzji dotyczących autoryzacji i inspekcji. Na przykład vc służy do certyfikowania osoby fizycznej jest szkolony i może uzyskiwać dostęp do poufnych aplikacji finansowych. Logika aplikacji może sprawdzić oświadczenie działu pod kątem szczegółowej autoryzacji i używać identyfikatora pracownika do celów inspekcji.

  • Potwierdzenie weryfikacji tożsamości: W tym scenariuszu celem jest potwierdzenie, że ta sama osoba, która początkowo została dołączona, jest rzeczywiście tą, która próbuje uzyskać dostęp do aplikacji o wysokiej wartości. Poświadczenie od wystawcy weryfikacji tożsamości byłoby dobrym rozwiązaniem. Logika aplikacji powinna sprawdzić, czy atrybuty z vc są zgodne z użytkownikiem, który zalogował się do aplikacji.

• Sprawdź odwołanie: w przypadku uzyskiwania dostępu do poufnych zasobów przy użyciu komputerów wirtualnych często sprawdza się stan vc z oryginalnym wystawcą i odmawia dostępu odwołanym komputerom wirtualnym. Podczas pracy z wystawcami upewnij się, że odwołanie jest jawnie omówione w ramach projektowania scenariusza.

• Środowisko użytkownika: w przypadku uzyskiwania dostępu do poufnych zasobów przy użyciu komputerów wirtualnych można rozważyć dwa wzorce.

  • Uwierzytelnianie krokowe: użytkownicy rozpoczynają sesję z aplikacją przy użyciu istniejących mechanizmów uwierzytelniania. Użytkownicy muszą przedstawić vc dla określonych operacji o wysokiej wartości w aplikacji, takich jak zatwierdzenia przepływów pracy biznesowych. Jest to dobre rozwiązanie w scenariuszach, w których takie operacje o wysokiej wartości można łatwo identyfikować i aktualizować w przepływach aplikacji.

  • Ustanowienie sesji: użytkownicy muszą przedstawić vc w ramach inicjowania sesji z aplikacją. Prezentowanie vc jest dobrym rozwiązaniem, gdy charakter całej aplikacji jest wysokiej wartości.

Uzyskiwanie dostępu do aplikacji poza granicami organizacji

Poświadczenia weryfikowalne mogą być również używane przez jednostki uzależnione, które chcą udzielić dostępu lub korzyści na podstawie członkostwa lub relacji zatrudnienia innej organizacji. Na przykład portal handlu elektronicznego może oferować korzyści, takie jak rabaty dla pracowników konkretnej firmy, studentów danej instytucji itp.

Zdecentralizowany charakter poświadczeń weryfikowalnych umożliwia ten scenariusz bez ustanawiania relacji federacji.

Inne elementy

Fronton internetowy jednostki uzależnionej: jest to fronton internetowy aplikacji, która jest rozszerzona za pomocą interfejsu API usługi żądań na potrzeby prezentacji i walidacji VC na podstawie wymagań biznesowych.

Logika autoryzacji dostępu użytkowników: warstwa logiki w aplikacji, która autoryzuje dostęp użytkowników i jest rozszerzona o używanie atrybutów użytkownika wewnątrz vc w celu podejmowania decyzji dotyczących autoryzacji.

Inne usługi zaplecza i zależności: reprezentuje pozostałą część logiki aplikacji, która zwykle pozostaje niezmieniona przez włączenie weryfikacji tożsamości za pośrednictwem maszyn wirtualnych.

Zagadnienia dotyczące projektowania

• Cel: cel scenariusza określa, jakiego rodzaju poświadczenia i wystawca jest potrzebny. Typowe scenariusze obejmują:

  • Uwierzytelnianie: w tym scenariuszu użytkownik musi posiadać vc, aby udowodnić zatrudnienie lub relację z określonymi organizacjami. W takim przypadku należy skonfigurować dostawcę usług w celu akceptowania maszyn wirtualnych wystawionych przez organizacje docelowe.

  • Autoryzacja: na podstawie wymagań aplikacji aplikacje mogą korzystać z atrybutów VC na potrzeby precyzyjnych decyzji dotyczących autoryzacji i inspekcji. Jeśli na przykład witryna internetowa handlu elektronicznego oferuje rabaty dla pracowników organizacji w określonej lokalizacji, może zweryfikować uprawnienia rabatu na podstawie oświadczenia kraju/regionu w VC (jeśli istnieje).

• Sprawdź odwołanie: w przypadku uzyskiwania dostępu do poufnych zasobów przy użyciu komputerów wirtualnych często sprawdza się stan vc z oryginalnym wystawcą i odmawia dostępu odwołanym komputerom wirtualnym. Podczas pracy z wystawcami upewnij się, że odwołanie jest jawnie omówione w ramach projektowania scenariusza.

• Środowisko użytkownika: użytkownicy mogą prezentować vc w ramach inicjowania sesji z aplikacją. Zazwyczaj aplikacje udostępniają również alternatywną metodę uruchamiania sesji w celu uwzględnienia przypadków, w których użytkownicy nie mają komputerów wirtualnych.

Odzyskiwanie konta

Poświadczenia weryfikowalne mogą służyć jako podejście do odzyskiwania konta. Jeśli na przykład użytkownik musi odzyskać swoje konto, może uzyskać dostęp do witryny internetowej, która wymaga od nich przedstawienia vc i zainicjowania resetowania poświadczeń firmy Microsoft Entra przez wywołanie interfejsów API programu MS Graph, jak pokazano na poniższym diagramie.

Uwaga

Chociaż scenariusz opisany w tej sekcji jest specyficzny dla odzyskiwania kont Microsoft Entra, to podejście może być również używane do odzyskiwania kont w innych systemach.

Inne elementy

Portal konta: fronton internetowy, który organizuje wywołania interfejsu API na potrzeby prezentacji i walidacji VC. Ta aranżacja może obejmować wywołania programu Microsoft Graph w celu odzyskania kont w identyfikatorze Entra firmy Microsoft.

Logika niestandardowa lub przepływy pracy: logika z krokami specyficznymi dla organizacji przed i po zaktualizowaniu konta użytkownika. Logika niestandardowa może obejmować przepływy pracy zatwierdzania, inne walidacje, rejestrowanie, powiadomienia itp.

Microsoft Graph: uwidacznia interfejsy API transferu stanu reprezentacji (REST) i biblioteki klienckie w celu uzyskania dostępu do danych firmy Microsoft Entra używanych do odzyskiwania konta.

Katalog Microsoft Entra enterprise: dzierżawa firmy Microsoft Entra zawierająca konta, które są tworzone lub aktualizowane za pośrednictwem portalu kont.

Uwagi dotyczące projektowania

Korelacja atrybutów VC z identyfikatorem Entra firmy Microsoft: podczas definiowania atrybutów VC we współpracy z wystawcą upewnij się, że zgadzasz się na oświadczenia identyfikujące użytkownika. Jeśli na przykład dostawca weryfikacji tożsamości weryfikuje tożsamość przed dołączaniem pracowników, upewnij się, że wystawiony vc zawiera oświadczenia, które mogą być dopasowane do systemów wewnętrznych. Takie roszczenia mogą być numerem telefonu, adresem lub datą urodzenia. Rp może poprosić o informacje, które nie znajdują się w VC w ramach tego procesu, takie jak ostatnie cztery cyfry ich numeru ubezpieczenia społecznego (SSN).

Rola komputerów wirtualnych z istniejącymi funkcjami resetowania poświadczeń firmy Microsoft: identyfikator Entra firmy Microsoft ma wbudowaną funkcję samoobsługowego resetowania hasła (SSPR). Poświadczenia weryfikowalne mogą służyć do zapewnienia innego sposobu odzyskiwania w przypadkach, gdy użytkownicy nie mają dostępu do metody samoobsługowego resetowania hasła lub ich utraty. W scenariuszach, w których użytkownik stracił zarówno komputer, jak i urządzenia przenośne, użytkownik może ponownie połączyć vc z wystawcy dowodu tożsamości i przedstawić go w celu zdalnego odzyskania konta.

Podobnie możesz użyć vc, aby wygenerować tymczasowy dostęp, który umożliwia użytkownikom resetowanie metod uwierzytelniania wieloskładnikowego bez hasła.

Autoryzacja: utwórz mechanizm autoryzacji, taki jak grupa zabezpieczeń sprawdzana przez dostawcę zasobów przed kontynuowaniem odzyskiwania poświadczeń. Na przykład tylko użytkownicy w określonych grupach mogą kwalifikować się do odzyskania konta za pomocą vc.

Interakcja z identyfikatorem Entra firmy Microsoft: komunikacja między frontonem internetowym i identyfikatorem Entra firmy Microsoft musi być zabezpieczona jako wysoce uprzywilejowany system, ponieważ może resetować poświadczenia pracowników. Udziel frontonowi sieci Web możliwie najmniej uprzywilejowanych ról. Przykłady obejmują:

• Udziel witrynie internetowej rp możliwość używania jednostki usługi przyznanej zakresowi UserAuthenticationMethod.ReadWrite.All programu MS Graph w celu zresetowania metod uwierzytelniania. Nie udzielaj User.ReadWrite.All, co umożliwia tworzenie i usuwanie użytkowników.

• Jeśli dostawca zasobów działa na platformie Azure, użyj tożsamości zarządzanych, aby wywołać program Microsoft Graph. Tożsamości zarządzane usuwa zagrożenia związane z zarządzaniem poświadczeniami jednostki usługi w kodzie lub plikach konfiguracji. Aby uzyskać więcej informacji, zobacz Tożsamości zarządzane dla zasobów platformy Azure.

Planowanie zarządzania tożsamościami

Poniżej przedstawiono zagadnienia związane z zarządzaniem dostępem i tożsamościami podczas dołączania komputerów wirtualnych do jednostek uzależnionych. Jednostki uzależnione to zazwyczaj aplikacje.

Uwierzytelnianie

• Podmiot VC musi być człowiekiem.

• Człowiek ma VC w portfelu i musi interaktywnie przedstawić VC. Przepływy nieinterakcyjne, takie jak on-behalf-of, nie są obsługiwane.

Autoryzacja

• Udaną prezentację VC można uznać za gruboziarnistą bramę autoryzacji. Atrybuty VC można również używać w celu podejmowania precyzyjnych decyzji dotyczących autoryzacji.

• Ustal, czy wygasła maszyna wirtualna ma znaczenie w aplikacji; jeśli tak, sprawdź wartość exp oświadczenia (czas wygaśnięcia) VC w ramach kontroli autoryzacji. Przykładem, w którym wygaśnięcie nie jest istotne, jest wymaganie dokumentu wydanego przez rząd, takiego jak prawo jazdy, aby sprawdzić, czy podmiot jest starszy niż 18 lat. Data roszczenia urodzenia jest prawidłowa, nawet jeśli VC wygasła.

• Ustal, czy odwołany vc ma znaczenie dla twojej decyzji o autoryzacji.

  • Jeśli nie jest to istotne, pomiń wywołanie, aby sprawdzić interfejs API stanu (który jest domyślnie włączony).

  • Jeśli jest to istotne, dodaj odpowiednią obsługę wyjątków w aplikacji.

Profile użytkowników

Aby utworzyć profil użytkownika, możesz użyć informacji w przedstawionych komputerach wirtualnych. Jeśli chcesz użyć atrybutów do utworzenia profilu, rozważ następujące elementy.

• Po wydaniu vc zawiera migawkę atrybutów jako wystawiania. Komputery wirtualne mogą mieć długie okresy ważności i należy określić wiek atrybutów, które będą akceptowane jako wystarczająco świeże do użycia w ramach profilu.

• Jeśli vc musi być prezentowane za każdym razem, gdy temat rozpoczyna sesję z rp, rozważ użycie danych wyjściowych prezentacji VC do utworzenia nietrwałego profilu użytkownika z atrybutami. Nietrwale profil użytkownika pomaga zmniejszyć ryzyko prywatności związane z przechowywaniem właściwości użytkownika magazynowanych. Aplikacja może wymagać lokalnego zapisania atrybutów podmiotu. Jeśli tak, zapisz tylko oświadczenia wymagane przez aplikację. Nie zapisuj całego vc.

• Jeśli aplikacja wymaga trwałego magazynu profilów użytkownika:

  • Rozważ użycie sub oświadczenia jako niezmiennego identyfikatora użytkownika. Jest to nieprzezroczystym atrybutem unikatowym, który jest stały dla danej pary podmiotu/rp.

  • Zdefiniuj mechanizm anulowania aprowizacji profilu użytkownika z aplikacji. Ze względu na zdecentralizowany charakter systemu Zweryfikowany identyfikator Microsoft Entra nie ma cyklu życia aprowizacji użytkowników aplikacji.

  • Nie przechowuj oświadczeń dotyczących danych osobowych zwróconych w tokenie VC.

  • Przechowuj tylko oświadczenia wymagane dla logiki jednostki uzależnionej.

Planowanie wydajności

Podobnie jak w przypadku dowolnego rozwiązania, należy zaplanować wydajność. Obszary fokusu obejmują opóźnienia, przepływność i skalowalność. W początkowych fazach cyklu wydawania wydajność nie powinna być istotna. Jednak gdy wdrożenie rozwiązania powoduje zweryfikowanie wielu weryfikowalnych poświadczeń, planowanie wydajności może stać się krytyczną częścią rozwiązania.

Poniższe elementy zawierają obszary, które należy wziąć pod uwagę podczas planowania wydajności:

• Usługa wystawiania Zweryfikowany identyfikator Microsoft Entra jest wdrażana w regionach świadczenia usługi Azure Azure Europa Zachodnia, Europa Północna, Zachodnie stany USA 2 i Zachodnio-środkowe stany USA. Aby ograniczyć opóźnienie, wdróż fronton weryfikacji (witrynę internetową) i magazyn kluczy w najbliższym regionie.

• Model oparty na przepływności:

  • Pojemność weryfikacji VC podlega limitom usługi Azure Key Vault.

  • Każda weryfikacja vc wymaga jednej operacji podpisu usługi Key Vault.

  • Nie można kontrolować ograniczania przepustowości; Zalecamy jednak przeczytanie wskazówek dotyczących ograniczania przepustowości usługi Azure Key Vault, aby zrozumieć, jak ograniczanie przepustowości może mieć wpływ na wydajność.

Planowanie niezawodności

Aby najlepiej zaplanować wysoką dostępność i odzyskiwanie po awarii, zalecamy następujące elementy:

• usługa Zweryfikowany identyfikator Microsoft Entra jest wdrażana w regionach Europa Zachodnia, Europa Północna, Zachodnie stany USA 2 i Zachodnio-środkowe stany USA, Australia i Japonia. Rozważ wdrożenie pomocniczych serwerów internetowych i aplikacji pomocniczych w jednym z tych regionów, w szczególności w tych, z których większość ruchu weryfikacyjnego ma pochodzić.

• Przejrzyj i uwzględnij najlepsze rozwiązania z zakresu dostępności i nadmiarowości usługi Azure Key Vault podczas projektowania celów dotyczących dostępności i nadmiarowości.

Planowanie pod kątem zabezpieczeń

Podczas projektowania pod kątem zabezpieczeń należy wziąć pod uwagę następujące kwestie:

• Wszystkie jednostki uzależnione (RPs) w jednej dzierżawie mają tę samą granicę zaufania, ponieważ współużytkują tę samą wartość DID.

• Zdefiniuj dedykowaną jednostkę usługi dla witryny internetowej, która uzyskuje dostęp do usługi Key Vault.

• Tylko usługa Zweryfikowany identyfikator Microsoft Entra i jednostki usługi witryny internetowej powinny mieć uprawnienia do używania usługi Key Vault do podpisywania komunikatów przy użyciu klucza prywatnego.

• Nie przypisuj żadnych uprawnień administracyjnych tożsamości człowieka do usługi Key Vault. Aby uzyskać więcej informacji na temat najlepszych rozwiązań usługi Key Vault, zobacz Punkt odniesienia zabezpieczeń platformy Azure dla usługi Key Vault.

• Zapoznaj się z artykułem Zabezpieczanie środowisk platformy Azure przy użyciu identyfikatora Entra firmy Microsoft, aby uzyskać najlepsze rozwiązania dotyczące zarządzania usługami pomocniczymi dla rozwiązania.

• Ograniczanie ryzyka fałszowania przez:

  • Implementowanie weryfikacji DNS w celu ułatwienia klientom identyfikowania znakowania wystawców.

  • Używaj domen, które mają znaczenie dla użytkowników końcowych.

• Ograniczenie ryzyka ograniczania przepustowości zasobów rozproszonej odmowy usługi (DDOS) i usługi Key Vault. Każde żądanie prezentacji VC generuje operacje podpisywania usługi Key Vault, które są naliczane w kierunku limitów usług. Zalecamy ochronę ruchu przez włączenie alternatywnego uwierzytelniania lub captcha przed wygenerowaniem żądań wystawiania.

Planowanie operacji

Podczas planowania operacji zalecamy zaplanowanie przechwycenia każdej próby weryfikacji poświadczeń w ramach inspekcji. Te informacje służą do przeprowadzania inspekcji i rozwiązywania problemów. Ponadto rozważ wygenerowanie unikatowych identyfikatorów transakcji (identyfikatorów), do których klienci i inżynierowie pomocy technicznej mogą odwoływać się w razie potrzeby.

W ramach planowania operacyjnego rozważ monitorowanie następujących elementów:

• W celu zapewnienia skalowalności:

  • Monitorowanie nieudanej weryfikacji vc w ramach end-to-end metryk zabezpieczeń aplikacji.

  • Monitoruj kompleksowe opóźnienie weryfikacji poświadczeń.

• W przypadku niezawodności i zależności:

  • Monitorowanie podstawowych zależności używanych przez rozwiązanie weryfikacji.

  • Postępuj zgodnie z instrukcjami monitorowania i alertów usługi Azure Key Vault.

• Zabezpieczenia:

  • Włącz rejestrowanie dla usługi Key Vault, aby śledzić operacje podpisywania oraz monitorować i ostrzegać o zmianach konfiguracji. Aby uzyskać więcej informacji, zobacz Jak włączyć rejestrowanie usługi Key Vault.

  • Archiwizowanie dzienników w systemach zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM), takich jak Microsoft Sentinel na potrzeby długoterminowego przechowywania.

Następne kroki

Dowiedz się więcej o tworzeniu architektury rozwiązań VC

• omówienie Zweryfikowany identyfikator Microsoft Entra

• Planowanie rozwiązania do wystawiania Zweryfikowany identyfikator Microsoft Entra

Implementowanie weryfikowalnych poświadczeń

• Wprowadzenie do Zweryfikowany identyfikator Microsoft Entra

• Wprowadzenie do weryfikowalnych poświadczeń

Często zadawane pytania