Najlepsze praktyki dotyczące zabezpieczeń właściwości aplikacji w Microsoft Entra ID

Bezpieczeństwo to ważna koncepcja podczas rejestrowania aplikacji w usłudze Microsoft Entra ID i jest krytyczną częścią jej użycia biznesowego w organizacji. Każda błędna konfiguracja aplikacji może spowodować przestój lub naruszenie zabezpieczeń. W zależności od uprawnień dodanych do aplikacji mogą istnieć efekty dla całej organizacji.

Ponieważ zabezpieczone aplikacje są niezbędne dla organizacji, wszelkie przestoje tych aplikacji z powodu problemów z zabezpieczeniami mogą mieć wpływ na firmę lub krytyczną usługę, od której zależy firma. Dlatego ważne jest, aby przydzielić czas i zasoby, aby zapewnić, że aplikacje zawsze pozostają w dobrej kondycji i bezpiecznym stanie. Przeprowadzaj okresową ocenę zabezpieczeń i kondycji aplikacji, podobnie jak ocenę modelu zagrożeń bezpieczeństwa dla kodu. Aby uzyskać szerszą perspektywę dotyczącą zabezpieczeń w organizacjach, zobacz cykl życia bezpiecznego programowania (SDL).

W tym artykule opisano najlepsze rozwiązania dotyczące zabezpieczeń dla następujących właściwości i scenariuszy aplikacji:

• Typ tożsamości
• Akredytacje
• Identyfikatory URI przekierowania
• Konfiguracja niejawnego przepływu
• Identyfikator URI aplikacji (znany również jako URI identyfikatora)
• Wersja tokenu dostępu
• Blokada instancji aplikacji
• Właściciel aplikacji

Typ tożsamości

Prawdopodobnie znajdziesz tutaj informacje na temat najlepszych rozwiązań w zakresie zabezpieczeń aplikacji Firmy Microsoft — nazywanych również rejestracjami aplikacji lub obiektami aplikacji. Istnieje jednak inny typ tożsamości, który może służyć do uzyskiwania dostępu do zasobów chronionych przez firmę Entra, nazywanych tożsamościami zarządzanymi dla zasobów platformy Azure.

Zarządzane tożsamości Azure są domyślnie bezpieczne i nie wymagają ciągłej konserwacji ani dodatkowego obciążenia. Rozważ użycie tożsamości zarządzanej zamiast aplikacji Microsoft Entra dla tożsamości aplikacji, jeśli wszystkie następujące elementy są spełnione:

• Usługa działa w chmurze platformy Azure
• Aplikacja nie musi logować użytkowników
• Aplikacja nie musi działać jako zasób w procesie przepływu tokenów (nie jest interfejsem API)
• Aplikacja nie musi działać w wielu dzierżawach

W pozostałej części tego artykułu opisano najlepsze rozwiązania w zakresie zabezpieczeń dotyczące właściwości rejestracji aplikacji Entra.

Poświadczenia (w tym certyfikaty i wpisy tajne)

Poświadczenia są istotną częścią aplikacji, gdy jest używana jako poufny klient. Na stronie Certyfikaty i wpisy tajne dla aplikacji w witrynie Azure Portal można dodać lub usunąć poświadczenia.

Rozważ następujące wskazówki dotyczące certyfikatów i sekretów:

• Zawsze, gdy jest to możliwe, użyj tożsamości zarządzanej jako poświadczenia. Jest to zdecydowanie zalecane, ponieważ tożsamości zarządzane są zarówno najbezpieczniejszą opcją, jak i nie wymagają ciągłego zarządzania poświadczeniami. Postępuj zgodnie z poniższymi wskazówkami , aby skonfigurować tożsamość zarządzaną jako poświadczenia. Jednak ta opcja może być możliwa tylko wtedy, gdy usługa, w której aplikacja jest używana, działa na platformie Azure.
• Jeśli usługa używana w aplikacji nie działa na platformie Azure, ale działa na innej platformie, która oferuje automatyczne zarządzanie poświadczeniami, rozważ użycie tożsamości z tej platformy jako poświadczenia. Na przykład przepływ pracy GitHub Actions można skonfigurować jako poświadczenia, aby uniknąć zarządzania i zabezpieczania poświadczeń w workflow GitHub Actions. Należy zachować ostrożność w przypadku tego podejścia i skonfigurować tylko poświadczenia federacyjne z zaufanych platform. Aplikacja jest tak bezpieczna, jak platforma tożsamości, która została skonfigurowana jako poświadczenie.
• Jeśli nie można użyć tożsamości zarządzanej lub innego bezpiecznego zewnętrznego dostawcy tożsamości, użyj poświadczeń certyfikatowych. Nie używaj poświadczeń haseł, zwanych także tajemnicami. Chociaż wygodne jest używanie tajnych haseł jako poświadczeń, poświadczenia haseł są często źle zarządzane i łatwo mogą zostać skompromitowane.
• Jeśli certyfikat musi być używany zamiast tożsamości zarządzanej, zapisz ten certyfikat w bezpiecznym magazynie kluczy, takim jak usługa Azure Key Vault.
• Jeśli certyfikat musi być używany zamiast tożsamości zarządzanej, użyj certyfikatu z zaufanego urzędu certyfikacji zamiast certyfikatu z podpisem własnym. Skonfiguruj zasady, aby wymusić , że certyfikaty pochodzą z zaufanych wystawców. Jeśli jednak korzystanie z zaufanego urzędu certyfikacji nie jest możliwe, certyfikaty z podpisem własnym są nadal preferowane zamiast haseł.
• Skonfiguruj zasady zarządzania aplikacjami, aby kontrolować użycie sekretów przez ograniczenie ich okresów żywotności lub całkowite zablokowanie ich użycia.
• Jeśli aplikacja jest używana tylko jako klient publiczny lub zainstalowany (na przykład aplikacje mobilne lub klasyczne zainstalowane na komputerze użytkownika końcowego), upewnij się, że nie określono poświadczeń w obiekcie aplikacji.
• Przejrzyj poświadczenia używane w aplikacjach pod kątem aktualności użycia i daty wygaśnięcia. Nieużywane poświadczenie przypisane do aplikacji może spowodować naruszenie zabezpieczeń. Często zmieniaj poświadczenia i nie udostępniaj poświadczeń między aplikacjami. Nie umieszczaj wielu poświadczeń logowania w jednej aplikacji.
• Monitoruj potoki produkcyjne, aby zapobiec dodawaniu poświadczeń dowolnego rodzaju do repozytoriów kodu. Credential Scanner to narzędzie do analizy statycznej, które może służyć do wykrywania poświadczeń (i innej poufnej zawartości) w kodzie źródłowym i danych wyjściowych kompilacji.

Identyfikatory URI przekierowania

Ważne jest, aby zapewnić aktualność URI przekierowań aplikacji. W obszarze Uwierzytelnianie dla aplikacji w witrynie Azure Portal należy wybrać platformę dla aplikacji, a następnie można zdefiniować właściwość URI przekierowania.

Rozważ następujące wskazówki dotyczące identyfikatorów URI przekierowania:

• Zachowaj własność wszystkich identyfikatorów URI. Utrata kontroli nad jednym z identyfikatorów URI przekierowania może prowadzić do naruszenia zabezpieczeń aplikacji.
• Upewnij się, że wszystkie rekordy DNS są okresowo aktualizowane i monitorowane pod kątem zmian.
• Nie używaj adresów URL odpowiedzi z symbolami wieloznacznymi ani niezabezpieczonych schematów URI, takich jak http, ani identyfikatorów URN.
• Niech lista będzie krótka Przytnij wszystkie zbędne identyfikatory URI. Jeśli to możliwe, zaktualizuj adresy URL z protokołu Http do https.

Konfiguracja niejawnego przepływu

Scenariusze, które wymagały przepływu niejawnego, mogą teraz używać przepływu kodu autoryzacyjnego, aby zmniejszyć ryzyko naruszenia bezpieczeństwa związanego z nieprawidłowym użyciem przepływu niejawnego. W obszarze Uwierzytelnianie dla aplikacji w witrynie Azure Portal należy wybrać platformę dla aplikacji, a następnie można ustawić właściwość Tokeny dostępu (używane dla niejawnych przepływów).

Identyfikator URI aplikacji (znany również jako identyfikator URI)

Właściwość Application ID URI aplikacji określa globalnie unikatowy identyfikator URI używany do identyfikowania internetowego interfejsu API. Jest to prefiks wartości zakresu w żądaniach do firmy Microsoft Entra. Jest to również wartość deklaracji odbiorców (aud) w tokenach dostępu w wersji 1.0. W przypadku aplikacji wielodostępnych wartość musi być również globalnie unikatowa. Jest on również określany jako URI identyfikatora . W obszarze Udostępnij interfejs API dla aplikacji w witrynie Azure Portal można zdefiniować właściwość Identyfikator URI aplikacji.

Najlepsze praktyki dotyczące określania URI identyfikatora aplikacji zmieniają się w zależności od tego, czy aplikacja korzysta z wystawianych tokenów dostępu w wersji 1.0 czy 2.0. Jeśli nie masz pewności, czy aplikacja otrzymuje tokeny dostępu w wersji 1.0, sprawdź requestedAccessTokenVersion w manifeście aplikacji . Wartość null lub 1 wskazuje, że aplikacja odbiera tokeny dostępu w wersji 1.0. Wartość 2 wskazuje, że aplikacja odbiera tokeny dostępu w wersji 2.0.

W przypadku aplikacji, dla których wystawiane są tokeny dostępu w wersji 1.0, należy używać tylko domyślnych identyfikatorów URI. Domyślne identyfikatory URI to api://<appId> i api://<tenantId>/<appId>. — Skonfiguruj nonDefaultUriAddition ograniczenie zasad zarządzania aplikacjami , aby wymusić to najlepsze rozwiązanie dla przyszłych aktualizacji aplikacji w organizacji.

W przypadku aplikacji, którym wystawiono tokeny dostępu w wersji 2.0, należy użyć następujących wskazówek podczas definiowania Identyfikatora URI aplikacji:

• Zalecane są schematy identyfikatorów URI api lub https. Ustaw właściwość w obsługiwanych formatach, aby uniknąć kolizji identyfikatorów URI w organizacji. Nie używaj symboli wieloznacznych.
• Użyj zweryfikowanej domeny organizacji.
• Prowadź spis identyfikatorów URI w organizacji, aby zapewnić bezpieczeństwo.

Obsługiwane są następujące formaty identyfikatora URI aplikacji dla interfejsu API i aplikacji opartych na schemacie HTTP. Zastąp wartości symboli zastępczych zgodnie z opisem na liście po tabeli.

• <appId> — właściwość identyfikatora aplikacji (appId) obiektu aplikacji.
• <string> — wartość ciągu dla host lub segmentu ścieżki interfejsu API.
• <tenantId> — identyfikator GUID wygenerowany przez platformę Azure do reprezentowania dzierżawcy na platformie Azure.
• <tenantInitialDomain> - <tenantInitialDomain.onmicrosoft.com, gdzie tenantInitialDomain jest początkową nazwą domeny określoną przez twórcę dzierżawy podczas tworzenia dzierżawy.
• <verifiedCustomDomain> — zweryfikowana domena niestandardowa skonfigurowana dla dzierżawy firmy Microsoft Entra.

Wersja tokenu dostępu

Ta sekcja ma zastosowanie tylko do aplikacji zasobów — czyli aplikacji, które działają jako odbiorcy w tokenach dostępu. Aplikacje zasobów to zazwyczaj internetowe interfejsy API. Jeśli aplikacja działa tylko jako klient (co oznacza, że uzyskuje tokeny do wysyłania do zasobów, takich jak Microsoft Graph), ta sekcja nie ma zastosowania.

Aplikacje zasobów, które skonfigurowały niestandardowe identyfikatory URI, powinny używać formatu tokenu dostępu w wersji 2.0. Aby sprawdzić, czy aplikacja powinna używać tokenów dostępu w wersji 2.0, zapoznaj się z właściwością identifierUris na stronie manifestu Rejestracje aplikacji dla aplikacji.

Jeśli istnieją jakiekolwiek wartości ustawione nie w formacie api://{appId} lub api://{tenantId}/{appId}, aplikacja powinna używać tokenów dostępu w wersji 2.0.

Aby uaktualnić tokeny dostępu do wersji 2.0, najpierw upewnij się, że aplikacja może obsługiwać oświadczenia tokenów w wersji 2.0. Następnie zaktualizuj wersję tokenu dostępu wystawioną przez aplikację przy użyciu edytora manifestu.

Po zaktualizowaniu konfiguracji aplikacji do używania tokenów w wersji 2.0, upewnij się, że logika weryfikacji odbiorców aplikacji została zmodyfikowana tak, aby akceptowała tylko jego appId.

Zablokowanie właściwości instancji aplikacji

Gdy aplikacja ma jednostkę usługi aprowizowaną w dzierżawie, jednostka usługi może być dostosowywana przez administratora dzierżawy. Jest to prawdą niezależnie od tego, czy dzierżawa ta jest dzierżawą główną aplikacji, czy dzierżawą zagraniczną. Te możliwości dostosowywania mogą zezwalać na modyfikacje, których właściciel aplikacji nie oczekiwał, co prowadzi do zagrożeń bezpieczeństwa. Na przykład poświadczenia można dodać do jednostki usługi, mimo że poświadczenia powinny być zwykle własnością i kontrolowane przez dewelopera i właściciela aplikacji.

Aby zmniejszyć to ryzyko, aplikacje powinny skonfigurować blokadę wystąpienia aplikacji. Podczas konfigurowania blokady wystąpienia aplikacji zawsze zablokuj każdą dostępną właściwość wrażliwą. Jest to szczególnie ważne w przypadku aplikacji wielodzierżawnych, ale aplikacje jednodzierżawne również powinny używać app instance lock w celu ochrony ich poufnych właściwości.

Uprawnienia

Aplikacja może wymagać udzielenia uprawnień dostępu do chronionych zasobów lub interfejsów API. Podczas żądania uprawnień zawsze upewnij się, że są spełnione następujące warunki:

• Przestrzegaj zasad najniższych uprawnień. Zażądaj tylko uprawnienia, które przyznaje najmniej uciążliwy dostęp wymagany do wykonania akcji, którą musi wykonać aplikacja. W przypadku wywoływania Microsoft Graph, użyj dokumentacji interfejsu API, aby zidentyfikować najmniej restrykcyjne uprawnienia dla danego wywołania interfejsu API. Okresowo sprawdzaj uprawnienia aplikacji, aby sprawdzić, czy jest dostępna opcja mniej uprzywilejowana. Jeśli aplikacja nie potrzebuje już uprawnień, usuń ją.
• Jeśli to możliwe, użyj dostępu delegowanego zamiast dostępu tylko do aplikacji.
• Przejrzyj dokumentację uprawnień i zgody , aby upewnić się, że rozumiesz podstawy uprawnień.

Konfiguracja właściciela aplikacji

Właściciele mogą zarządzać wszystkimi aspektami zarejestrowanej aplikacji. Ważne jest, aby regularnie weryfikować, kto jest właścicielem wszystkich aplikacji w organizacji. Aby uzyskać więcej informacji, zobacz Przeglądy dostępu Microsoft Entra. W obszarze Właściciele aplikacji w portalu Azure można zarządzać właścicielami tej aplikacji.

Rozważ następujące wskazówki dotyczące określania właścicieli aplikacji:

• Odpowiedzialność za aplikację powinna być ograniczona do minimalnej liczby osób w organizacji.
• Administrator powinien przeglądać listę właścicieli co kilka miesięcy, aby upewnić się, że właściciele są nadal częścią organizacji i nadal powinni być właścicielami aplikacji.

Zapoznaj się z zaleceniami entra

Funkcja rekomendacji firmy Microsoft Entra pomaga monitorować stan dzierżawy, aby nie trzeba było tego robić. Te zalecenia pomagają zapewnić, że tenant jest w bezpiecznym i stanie zdrowym, a jednocześnie pomagają zmaksymalizować wartość funkcji dostępnych w Microsoft Entra ID. Okresowo przejrzyj wszystkie aktywne rekomendacje firmy Microsoft Entra dotyczące właściwości aplikacji lub konfiguracji aplikacji, aby zachować ekosystem aplikacji w dobrej kondycji.