Opracowywanie strategii uprawnień delegowanych
Ten artykuł ułatwia deweloperom zaimplementowanie najlepszego podejścia do zarządzania uprawnieniami w aplikacji i opracowywania przy użyciu zasad zero trust. Zgodnie z opisem w sekcji 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, 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, obowiązujące uprawnienia są powiązane.
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 piszesz kodu w celu zaktualizowania profilu użytkownika, nie żądasz go dla aplikacji. Jeśli uzyskujesz dostęp tylko do użytkowników i grup, nie żądasz dostępu do innych informacji w katalogu. Nie żądasz uprawnień do zarządzania pocztą e-mail użytkownika, jeśli nie piszesz kodu, który uzyskuje dostęp do poczty 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óre 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 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, administrator dzierżawy może unieważnić sugestie dotyczące zgody użytkownika projektanta interfejsu API. 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 zezwalać 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 wiesz, 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) 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, należy utworzyć 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. This overrides 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 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, zwraca AcquireTokenSilent token, 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 udziela zgody). AcquireTokenSilent W związku z tym wysyła błąd z powrotem do aplikacji, która wymaga interakcji użytkownika. Gdy twoja aplikacja otrzymuje błąd, wróć do wywołania metody AcquireTokenPopup.
W tym momencie identyfikator Entra firmy Microsoft prowadzi 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 pobiera token, który musi przejść 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. Powyższy przykładowy kod 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
- Uzyskiwanie 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. Wyjaśniono w nim, jak dostosować tokeny w celu zwiększenia elastyczności i kontroli przy jednoczesnym zwiększeniu poziomu zabezpieczeń zerowego zaufania aplikacji z najmniejszymi 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. Te metody pomagają zwiększyć elastyczność i kontrolę 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łanie 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.