Opracowywanie strategii uprawnień delegowanych

Ten artykuł pomoże Ci jako deweloper zaimplementować najlepsze podejście do zarządzania uprawnieniami w aplikacji i opracowywania przy użyciu zasad zero trust. Jak opisano w artykule Uzyskiwanie autoryzacji dostępu do zasobów, delegowane uprawnienia są używane z delegowanym dostępem, aby umożliwić aplikacji działanie w imieniu użytkownika, uzyskując dostęp tylko do tego, do czego użytkownik może uzyskać dostęp. Uprawnienia aplikacji są używane z bezpośrednim dostępem, aby umożliwić aplikacji dostęp do dowolnych danych, z którymi jest skojarzone uprawnienie. Tylko administratorzy i właściciele jednostek usługi mogą wyrazić zgodę na uprawnienia aplikacji.

Modele uprawnień i zgody odnoszą się głównie do aplikacji. Proces uprawnień i zgody nie ma kontroli nad tym, co użytkownik może zrobić. Steruje on akcjami, które aplikacja może wykonywać.

Odwołaj się do poniższego diagramu Venna. W przypadku uprawnień delegowanych istnieje przecięcie między tym, co użytkownik może zrobić, a tym, co może zrobić aplikacja. To skrzyżowanie jest skutecznym uprawnieniem, za pomocą którego aplikacja jest powiązana. Za każdym razem, gdy używasz delegowanego uprawnienia, jest ona powiązana z obowiązującymi uprawnieniami.

"Venn diagram description: Lewy tekst okręgu: Aplikacje otrzymują zgodę na zakres operacji aplikacji. Tekst prawego okręgu: użytkownicy mają uprawnienia do operacji zarządzanych przez organizację. Przecięcie tekstu okręgów: obowiązujące uprawnienia: skrzyżowanie uprawnień aplikacji i możliwości użytkownika.

Na przykład aplikacja, która ma użytkowników przed aplikacją, otrzymuje uprawnienia do aktualizowania profilu każdego użytkownika w dzierżawie. Nie oznacza to, że każdy, kto uruchamia aplikację, może zaktualizować profil innego użytkownika. Jeśli administrator zdecyduje się na przyznanie aplikacji User.ReadWrite.All, uważa, że aplikacja wykonuje odpowiednie czynności podczas aktualizowania dowolnego profilu użytkowników. Aplikacja może rejestrować zmiany i prawidłowo chronić informacje. Administrator ocenia wartość aplikacji, a nie o użytkowniku.

Podejście do najniższych uprawnień

Interfejsy API mogą być złożone. Proste interfejsy API mogą nie mieć wielu operacji. Złożone interfejsy API, takie jak Microsoft Graph, hermetyzują wiele żądań, których może chcieć użyć aplikacja. Tylko dlatego, że aplikacja ma prawo do odczytu, nie oznacza, że powinna mieć prawo do aktualizacji. Na przykład program Microsoft Graph ma tysiące interfejsów API. Tylko dlatego, że masz uprawnienia do odczytywania profilu użytkownika, nie ma powodu, dla którego należy również mieć uprawnienia do usuwania wszystkich swoich plików w usłudze OneDrive.

Jako deweloper należy:

• znajomość interfejsów API wywoływanych przez aplikację.
• zapoznaj się z dokumentacją interfejsu API i uprawnieniami wymaganymi przez interfejs API.
• użyj najmniejszego możliwego uprawnienia do wykonywania zadań.

Interfejsy API często zapewniają dostęp do magazynów danych organizacji i przyciągają uwagę osób atakujących, którzy chcą uzyskać dostęp do tych danych.

Oceń żądane uprawnienia, aby upewnić się, że szukasz bezwzględnie najmniej uprzywilejowanego zestawu, aby wykonać zadanie. Unikaj żądania wyższych uprawnień; zamiast tego należy uważnie pracować z dużą liczbą uprawnień, które udostępniają interfejsy API, takie jak Microsoft Graph. Znajdź i użyj minimalnych uprawnień, aby spełnić twoje potrzeby. Jeśli nie napiszesz kodu w celu zaktualizowania profilu użytkownika, nie zażądasz go dla aplikacji. Jeśli uzyskujesz dostęp tylko do użytkowników i grup, nie będziesz żądać dostępu do innych informacji w katalogu. Jeśli nie będziesz pisać kodu, który uzyskuje dostęp do poczty e-mail użytkownika, nie zażądasz uprawnień do zarządzania pocztą e-mail użytkownika.

W przypadku tworzenia aplikacji Zero Trust:

• Zdefiniuj intencję aplikacji i jej potrzeby.
• Upewnij się, że nie można naruszyć zabezpieczeń złych podmiotów i użyć aplikacji w taki sposób, że nie zamierzasz.
• Wyślij żądania zatwierdzenia, w których definiujesz wymagania (na przykład przeczytaj wiadomość e-mail użytkownika).

Role administratora użytkownika i dzierżawy w uprawnieniach i zgody

Osoby, którzy mogą zatwierdzać żądania, należą do dwóch kategorii: administratorzy, którzy zawsze mogą wyrazić zgodę na żądania uprawnień i zwykłych użytkowników, którzy nie są administratorami. Jednak administratorzy dzierżawy mają ostatnie zdanie w swojej dzierżawie dotyczące uprawnień wymagających zgody administratora i uprawnień, które użytkownik może wyrazić zgodę.

Gdy projektant interfejsu API wymaga zgody administratora na uprawnienie, to uprawnienie zawsze będzie wymagać zgody administratora; administrator dzierżawy nie może tego unieważnić i wymagać tylko zgody użytkownika.

Gdy projektant interfejsu API definiuje uprawnienia wymagające zgody użytkownika, sugestie zgody użytkownika przez projektanta interfejsu API mogą zostać unieważnione przez administratora dzierżawy. Administratorzy dzierżawy mogą to zrobić za pomocą "dużego przełącznika" w dzierżawie: wszystko wymaga zgody administratora. Mogą oni unieważnić zgodę użytkownika w bardziej szczegółowy sposób z uprawnieniami i zarządzaniem zgodą. Mogą na przykład zezwolić użytkownikom na wyrażanie zgody na żądania zgody użytkowników od zweryfikowanych wydawców , ale nie od innych wydawców. W innym przykładzie mogą zezwolić na User.Read logowanie użytkownika i odczytywanie profilu, ale wymagają zgody administratora na aplikacje z prośbą o uprawnienia do poczty lub plików.

Projektanci interfejsów API tworzą swoje sugestie, ale administratorzy dzierżawy mają ostatnie zdanie. W związku z tym jako deweloper nie zawsze będziesz wiedzieć, kiedy aplikacja wymaga zgody administratora. Miło jest zaplanować i zaprojektować wokół tego, ale pamiętaj, że podczas tworzenia żądania tokenu może on zostać odrzucony z jakiegokolwiek powodu. W kodzie musisz bezpiecznie obsługiwać nie uzyskiwanie tokenu, ponieważ administratorzy dzierżawy, w których klienci lub użytkownicy uruchamiają aplikację, decydują, kiedy uprawnienia wymagają zgody administratora.

Przykład użycia biblioteki MSAL języka JavaScript

W przypadku uwierzytelniania w tym przykładzie użyjesz naszej biblioteki Microsoft Authentication Library (MSAL) języka JavaScript, aby zalogować użytkownika w aplikacji jednostronicowej (SPA), w której jest wykonywana cała logika aplikacji z przeglądarki.

W powiązanym artykule Szybki start możesz pobrać i uruchomić przykładowy kod. Pokazuje, jak jednostronicowa aplikacja JavaScript (SPA) może logować użytkowników i wywoływać program Microsoft Graph przy użyciu przepływu kodu autoryzacji z kluczem dowodowym dla programu Code Exchange (PKCE). Przykładowy kod pokazuje, jak uzyskać token dostępu w celu wywołania interfejsu API programu Microsoft Graph lub dowolnego internetowego interfejsu API.

Jak pokazano w poniższym przykładowym kodzie, utworzysz wystąpienie klienta publicznego, ponieważ aplikacja działająca w całości w przeglądarce musi być klientem publicznym. Użytkownik może uzyskać praktyczne informacje na temat wewnętrznych aplikacji, gdy kod znajduje się w przeglądarce.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Następnie użyjesz naszej biblioteki MSAL. W języku JavaScript biblioteki MSAL istnieje określony interfejs API do logowania. Istnieją dwa interfejsy API, które korzystają z określonych funkcji w przeglądarce. Jednym z nich jest zalogowanie się za pomocą wyskakującego środowiska; drugim jest zalogowanie się przy użyciu środowiska przekierowania przeglądarki.

Jak pokazano w poniższym przykładzie kodu, okno podręczne logowania obsługuje uwierzytelnianie, które użytkownik musi wykonać, wywołując signIn funkcję.

function signIn() {

    /**
     * You can pass a custom request object below. This will override the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

Aplikacja może uzyskać informacje o użytkowniku, takie jak nazwa wyświetlana lub identyfikator użytkownika. Następnie aplikacja musi mieć autoryzację, aby odczytać pełny profil użytkownika z programu Microsoft Graph, postępując zgodnie ze wzorcem używanym w naszych bibliotekach BIBLIOTEK MSAL.

Jak pokazano w poniższym przykładowym kodzie, aplikacja próbuje uzyskać autoryzację, wywołując metodę AcquireTokenSilent. Jeśli identyfikator Entra firmy Microsoft może wystawiać token bez interakcji z użytkownikiem, zwróci token, AcquireTokenSilent który aplikacja musi uzyskać dostęp do programu Microsoft Graph w imieniu użytkownika.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

Jednak często identyfikator Entra firmy Microsoft nie może wystawiać tokenu bez interakcji z użytkownikiem (na przykład użytkownik zmienił hasło lub nie udzielił zgody). W związku z tym program wyśle błąd z powrotem do aplikacji, AcquireTokenSilent która wymaga interakcji z użytkownikiem. Gdy twoja aplikacja otrzymuje błąd, wróć do wywołania metody AcquireTokenPopup.

W tym momencie identyfikator Entra firmy Microsoft będzie miał konwersację z użytkownikiem, aby mógł uwierzytelnić użytkownika i autoryzować aplikację do działania w imieniu użytkownika (na przykład zrobić uwierzytelnianie wieloskładnikowe, podać swoje hasło, udzielić zgody). Następnie aplikacja uzyska token potrzebny do przejścia do przodu.

Podstawowym krokiem w podróży przedsiębiorstwa do rozwiązania Zero Trust jest wdrożenie silniejszych metod uwierzytelniania zamiast tylko identyfikatora użytkownika i hasła. Przykładowy kod opisany powyżej w pełni umożliwia przedsiębiorstwu przejście do silniejszej metody uwierzytelniania wybranej przez przedsiębiorstwo. Na przykład uwierzytelnianie wieloskładnikowe, w pełni bez hasła z kluczem FIDO2, Microsoft Authenticator.

Następne kroki

• Uzyskanie autoryzacji dostępu do zasobów pomaga zrozumieć, jak najlepiej zapewnić zero trust podczas uzyskiwania uprawnień dostępu do zasobów dla aplikacji.
• Opracowywanie strategii uprawnień aplikacji ułatwia podjęcie decyzji o podejściu uprawnień aplikacji do zarządzania poświadczeniami.
• Dostosowywanie tokenów opisuje informacje, które można otrzymywać w tokenach firmy Microsoft Entra oraz jak dostosować tokeny w celu zwiększenia elastyczności i kontroli przy jednoczesnym zwiększeniu zabezpieczeń zerowego zaufania aplikacji z najniższymi uprawnieniami.
• Konfigurowanie oświadczeń grup i ról aplikacji w tokenach pokazuje, jak skonfigurować aplikacje przy użyciu definicji ról aplikacji i przypisać grupy zabezpieczeń do ról aplikacji w celu zwiększenia elastyczności i kontroli przy jednoczesnym zwiększeniu zabezpieczeń zerowego zaufania aplikacji z najmniejszymi uprawnieniami.
• Usługa API Protection opisuje najlepsze rozwiązania dotyczące ochrony interfejsu API za pośrednictwem rejestracji, definiowania uprawnień i zgody oraz wymuszania dostępu w celu osiągnięcia celów zero trust.
• Wywoływanie interfejsu API z innego interfejsu API pomaga zapewnić zero trust, gdy masz jeden interfejs API, który musi wywoływać inny interfejs API i bezpiecznie opracowywać aplikację podczas pracy w imieniu użytkownika.
• Najlepsze rozwiązania dotyczące autoryzacji pomagają zaimplementować najlepsze modele autoryzacji, uprawnień i zgody dla aplikacji.
• Użyj najlepszych rozwiązań dotyczących tworzenia tożsamości zero trust i zarządzania dostępem w cyklu tworzenia aplikacji, aby utworzyć bezpieczne aplikacje.