Zaplanuj rozwiązanie weryfikacji dla Microsoft Entra Verified ID

Przegląd

Usługa Microsoft Entra Verified ID (Microsoft Entra VC) firmy Microsoft 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, zapoznaj się z omówieniem architektury zweryfikowanego identyfikatora firmy Microsoft. Zapoznaj się również z artykułem Planowanie rozwiązania do wystawiania zweryfikowanego identyfikatora firmy Microsoft.

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. Rozwiązanie interfejsuje z systemem zaufania, w którym obecnie obsługiwany jest 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 tematy nie są omówione w tej zawartości. Aby uzyskać więcej informacji, zapoznaj się z platformą Microsoft Azure Well-Architected Framework.

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.

Diagram składników rozwiązania weryfikacji.

Usługa Microsoft Entra Verified ID

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

Dzierżawca usługi 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 Microsoft Entra korzysta z usługi wielodostępnej Microsoft Entra Verified ID i wystawia jeden 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

Diagram składników rozwiązania weryfikacji z wyróżnioną usługą Azure Key Vault.

Usługa Azure Key Vault przechowuje klucze weryfikatora, które są generowane po włączeniu usługi wystawiania zweryfikowanego identyfikatora firmy Microsoft. Klucze są używane do zapewnienia zabezpieczeń komunikatów. Każdy weryfikator ma jeden zestaw kluczy używany do podpisywania, aktualizowania i odzyskiwania Zweryfikowanych Poświadczeń. Zweryfikowany identyfikator używa tego zestawu kluczy za każdym razem, gdy będziesz obsługiwać żądanie weryfikacji. Zestaw kluczy firmy Microsoft używa obecnie kryptografii krzywej eliptycznej (ECC) SECP256k1. Są również oceniane inne schematy podpisów kryptograficznych przyjęte przez szerszą społeczność DID.

API Żądania Usługi

Diagram składników rozwiązania weryfikacji z wyróżnionym interfejsem 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

Diagram składników rozwiązania weryfikacji z wyróżnionym systemem zaufania.

Microsoft Entra Verified ID obecnie obsługuje DID Web jako system zaufania, w którym dokument DID jest hostowany na serwerze internetowej wystawców.

Aplikacja Microsoft Authenticator

Diagram składników rozwiązania weryfikacji z wyróżnioną aplikacją Microsoft Authenticator.

Microsoft Authenticator to aplikacja mobilna. Authenticator organizuje interakcje między użytkownikiem, usługą Microsoft Entra VC i kontraktem używanym do wydawania wiarygodnych poświadczeń. 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 poświadczeń weryfikowalnych do weryfikacji.

Strona ufająca (RP)

Diagram składników rozwiązania weryfikacji z wyróżnionymi składnikami jednostki uzależnionej.

Fronton internetowy

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 front-end może być publicznie dostępny lub stanowić wewnętrzną witrynę internetową, aby umożliwić użytkownikom końcowym korzystanie ze środowisk wymagających 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 za pomocą określonych parametrów żą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 wdrażania, zastępując niektóre interakcje międzyludzkie. 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 udać się do biura centralnego, aby aktywować identyfikator, może on użyć wideokonferencji do zweryfikowania swojej tożsamości i zdalnie aktywować identyfikator dostarczony do niego. Zamiast otrzymywać kod do zrealizowania w celu uzyskania dostępu do usług rządowych, obywatel może użyć weryfikowalnych poświadczeń (VC), aby udowodnić swoją tożsamość i uzyskać dostęp.

Diagram przedstawiający scenariusz dołączania konta.

Inne elementy

Portal dołączania: interfejs użytkownika w aplikacji internetowej, który koordynuje wywołania API usługi żądań do prezentacji i weryfikacji poświadczeń VC oraz logiki 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 onboardingowy musi korzystać podczas dołączania podmiotów. Systemy do integracji są określane na podstawie rodzajów tożsamości, które chcesz wprowadzić przy użyciu weryfikacji VC. Typowe scenariusze weryfikacji tożsamości na potrzeby procesu wdrażania obejmują:

  • Tożsamości zewnętrzne, które Microsoft Entra ID dołącza przy użyciu interfejsów API do wydawania zaproszeń biznesowych B2B lub zarządzania uprawnieniami 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.

Uwagi dotyczące projektowania

  • Wystawca: dołączanie konta dobrze pasuje do zewnętrznej usługi weryfikacji tożsamości jako wystawcy uwierzytelnialnych poświadczeń. Przykłady kontroli w procesie dołączania obejmują: sprawdzanie czy osoba jest żywa, weryfikacja dokumentów wydanych przez rząd, potwierdzenie adresu lub numeru telefonu itd.

  • Przechowywanie atrybutów VC: jeśli to możliwe, nie przechowuj atrybutów z systemów kontroli wersji 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ż poproszenie o VC, aby pobierało oświadczenia na żądanie.

  • Korelacja atrybutów VC z systemami zaplecza: podczas definiowania atrybutów VC z wystawcą, ustanów mechanizm korelowania informacji w systemie zaplecza po tym, jak użytkownik przedstawi VC. Mechanizm zazwyczaj używa ograniczonego czasowo, unikatowego identyfikatora w kontekście RP w połączeniu z otrzymywanymi 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, RP może wygenerować link z czasowym unikatowym identyfikatorem. Następnie RP wysyła go na adres e-mail kandydata w systemie HR. 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 uzupełnienia atrybutów użytkownika w systemie kadr lub do weryfikowania dokładności atrybutów użytkownika odnoszących się do 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 zaproszeniem lub podstawowymi danymi i kontynuować proces aprowizacji. Atrybuty w VC mogą służyć do sprawdzania poprawności lub uzupełniania atrybutów użytkownika zewnętrznego.

    • Tożsamości zewnętrzne – samoobsługa: Gdy tożsamości zewnętrzne zapiszą się w systemie docelowym za pomocą samoobsługi (np. aplikacji B2C), atrybuty w VC mogą być użyte 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 interfejsem sieciowym a docelowymi systemami tożsamości musi być zabezpieczona, ponieważ jest to system o wysokim poziomie uprawnień, który może tworzyć konta. Udziel frontonowi sieci Web możliwie najmniej uprzywilejowanych ról. Oto kilka przykładów:

    • 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 Microsoft Entra ID przy użyciu współpracy B2B, witryna RP może użyć jednostki usługi, która ma przyznany zakres MS Graph User.Invite.All do tworzenia zaproszeń.

    • Jeśli Twoje RP działa na platformie Azure, użyj zarządzanych tożsamości, aby wywołać 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.

Diagram składników rozwiązania weryfikacji z innymi dołączonymi elementami.

Inne elementy

Interfejs użytkownika strony internetowej strony zależnej jest interfejsem użytkownika aplikacji, która jest rozszerzona za pomocą interfejsu API usługi żądań na potrzeby prezentacji i walidacji VC, zgodnie z wymaganiami biznesowymi.

Logika autoryzacji dostępu użytkowników to warstwa logiki aplikacji, która autoryzuje dostęp użytkowników. Został ulepszony, aby korzystać z 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.

Uwagi dotyczące projektowania

  • Cel: Cel scenariusza określa, jakiego rodzaju poświadczeń i wystawcy są potrzebne. Typowe scenariusze obejmują:

    • Autoryzacja: W tym scenariuszu użytkownik przedstawia zweryfikowane poświadczenia (VC) do podjęcia decyzji dotyczącej autoryzacji. Poświadczenia zaprojektowane do potwierdzenia ukończenia szkolenia lub posiadania określonego certyfikatu dobrze pasują do 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 poświadczania, że osoba fizyczna jest przeszkolona 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 została początkowo zarejestrowana, jest rzeczywiście tą, która próbuje uzyskać dostęp do aplikacji o dużej 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.

  • Sprawdzenie unieważnienia: w przypadku uzyskiwania dostępu do poufnych zasobów przy użyciu zweryfikowanych poświadczeń często sprawdza się ich status u oryginalnego wystawcy i odmawia dostępu dla unieważnionych poświadczeń. Podczas pracy z wystawcami upewnij się, że odwołanie jest jawnie omówione w ramach projektowania scenariusza.

  • Doświadczenie użytkownika: Korzystając z wirtualnych certyfikatów do uzyskiwania dostępu do poufnych zasobów, możesz rozważyć dwa schematy.

    • Uwierzytelnianie krokowe: użytkownicy rozpoczynają sesję z aplikacją przy użyciu istniejących mechanizmów uwierzytelniania. Użytkownicy muszą przedstawić dokument weryfikacyjny dla określonych transakcji o dużej 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 podczas rozpoczynania sesji z aplikacją. Prezentacja VC jest dobrym rozwiązaniem, gdy charakter całej aplikacji ma wysoką wartość.

Uzyskiwanie dostępu do aplikacji poza granicami organizacji

Poświadczenia weryfikowalne mogą być również używane przez podmioty zaufane, które chcą udzielić dostępu lub korzyści na podstawie członkostwa lub stosunku zatrudnienia z inną organizacją. 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.

Diagram składników rozwiązania weryfikacji pokazującego, że dostęp odbywa się spoza granicy zaufania.

Inne elementy

Interfejs internetowy strony zależnej: jest to interfejs internetowy aplikacji rozszerzony za pomocą API usługi żądań na potrzeby przedstawiania i walidacji danych VC zgodnie z wymaganiami biznesowymi.

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.

Uwagi dotyczące projektowania

  • Cel: Cel scenariusza określa, jakiego rodzaju poświadczeń i wystawcy są potrzebne. Typowe scenariusze obejmują:

    • Uwierzytelnianie: w tym scenariuszu użytkownik musi posiadać VC, aby udowodnić zatrudnienie lub relację z określoną organizacją (lub organizacjami). W takim przypadku należy skonfigurować RP, aby akceptować potwierdzalne poświadczenia wystawione 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).

  • Sprawdzenie unieważnienia: w przypadku uzyskiwania dostępu do poufnych zasobów przy użyciu zweryfikowanych poświadczeń często sprawdza się ich status u oryginalnego wystawcy i odmawia dostępu dla unieważnionych poświadczeń. Podczas pracy z wystawcami upewnij się, że odwołanie jest jawnie omówione w ramach projektowania scenariusza.

  • Środowisko użytkownika: Użytkownicy mogą prezentować świadectwa uwierzytelnienia jako część 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ą świadectw uwierzytelnienia.

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 usługi MS Graph, jak pokazano na poniższym diagramie.

Uwaga / Notatka

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.

Diagram składników rozwiązania weryfikacji przedstawiającego scenariusz odzyskiwania konta.

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: udostępnia interfejsy API REST i biblioteki klienckie umożliwiające dostęp do danych Microsoft Entra używanych do odzyskiwania kont.

Katalog przedsiębiorstwa Microsoft Entra: jednostka dzierżawy 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 przyjmowaniem 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 trakcie tego procesu, takie jak ostatnie cztery cyfry numeru ubezpieczenia społecznego osób, których dane dotyczą (SSN).

Rola inwestorów venture capital z istniejącymi możliwościami resetowania poświadczeń Microsoft Entra: Microsoft Entra ID ma wbudowaną funkcję samoobsługowego resetowania hasła (SSPR). Poświadczenia wiarygodne 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 utracili nad nią kontrolę. W scenariuszach, w których użytkownik stracił zarówno komputer, jak i telefon komórkowy, użytkownik może ponownie uzyskać VC od wystawcy dowodu tożsamości i przedstawić go w celu zdalnego odzyskania konta.

Podobnie możesz użyć VC, aby wygenerować tymczasową przepustkę dostępu, która umożliwia użytkownikom resetowanie metod uwierzytelniania wieloskładnikowego bez hasła.

Autoryzacja: Utwórz mechanizm autoryzacji, taki jak grupa zabezpieczeń, którą dostawca zasobów sprawdza, zanim przejdzie do odzyskiwania poświadczeń. Na przykład tylko użytkownicy w określonych grupach mogą mieć możliwość odzyskania konta za pomocą VC.

Interakcja z Microsoft Entra ID: Komunikacja między front-endem sieciowym a Microsoft Entra ID musi być zabezpieczona jako system o wysokim poziomie uprawnień, ponieważ może resetować poświadczenia pracowników. Udziel frontonowi sieci Web możliwie najmniej uprzywilejowanych ról. Oto kilka przykładów:

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

  • Jeśli Twoje RP działa na platformie Azure, użyj zarządzanych tożsamości, aby wywołać Microsoft Graph. Zarządzane tożsamości eliminują ryzyko związane z zarządzaniem poświadczeniami głównego identyfikatora usługi w kodzie lub plikach konfiguracyjnych. 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 tożsamościami i dostępem (IAM) podczas włączania wiarygodnych poświadczeń dla stron polegających. Jednostki uzależnione to zazwyczaj aplikacje.

Uwierzytelnianie

  • Podmiot VC musi być człowiekiem.

  • Użytkownik ma VC w portfelu i musi w sposób interaktywny 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łe poświadczenie ma znaczenie w twojej aplikacji; jeśli tak, sprawdź wartość exp (czas wygaśnięcia) jako część kontroli autoryzacyjnej. 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. Twierdzenie dotyczące daty urodzenia jest ważne, nawet jeśli certyfikat wygasł.

  • 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ę swoich atrybutów w momencie wystawienia. Zweryfikowane referencje mogą mieć długie okresy ważności, a należy określić wiek atrybutów, które zaakceptujesz 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 wyników prezentacji VC do utworzenia nietrwałego profilu użytkownika zawierającego atrybuty. Nietrwały profil użytkownika pomaga zmniejszyć ryzyko związane z prywatnością przy przechowywaniu właściwości użytkownika w stanie spoczynku. 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 nieprzezroczysty atrybut unikatowy, który jest stały dla danej pary podmiot/RP.

    • Zdefiniuj mechanizm usunięcia profilu użytkownika w aplikacji. Ze względu na zdecentralizowany charakter systemu Microsoft Entra Verified ID nie ma cyklu życia udostępniania użytkowników aplikacji.

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

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

Planowanie na potrzeby 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 zweryfikowanego identyfikatora firmy Microsoft jest wdrażana w regionach Azure: Europa Zachodnia, Europa Północna, Zachodnie USA 2 i Zachodnio-centralne USA. Aby ograniczyć opóźnienia, wdroż front weryfikacji (witrynę internetową) oraz magazyn kluczy w najbliższym regionie.

  • Model oparty na przepływności:

Planowanie niezawodności

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

  • Usługa Microsoft Entra Verified ID 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 strony polegające (RPs) w jednym dzierżawcy mają tę samą granicę zaufania, ponieważ dzielą ten sam DID.

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

  • Tylko usługa Microsoft Entra Verified ID 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 identyfikacji marki wystawcy.

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

  • Zmniejsz ryzyko rozproszonej odmowy usługi (DDOS) i ograniczania dostępu do zasobów usługi Key Vault. Każde żądanie prezentacji VC generuje operacje podpisywania Key Vault, które są naliczane do limitów usług. Ochrona ruchu przez włączenie alternatywnego uwierzytelniania lub captcha przed wygenerowaniem żądań wystawiania.

Planowanie operacji

Podczas planowania operacji przechwyć każdą próbę 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:

    • Monitoruj nieudaną weryfikację VC jako część kompleksowych metryk zabezpieczeń aplikacji.

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

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

  • 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 .

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

Dalsze kroki

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

Implementowanie weryfikowalnych poświadczeń

Często zadawane pytania

  • Last updated on