Sekret aplikacji ważny przez dwa lata nie musi być akceptowany w Twojej organizacji. Microsoft Entra ID pozwala ograniczyć okres ważności nowych sekretów, a nawet zablokować ich dodawanie. Służą do tego zasady zarządzania aplikacjami pomagające egzekwować wymagania bezpieczeństwa już podczas konfiguracji. Limit wynika z ustawień organizacji – nie jest automatycznym powszechnym zakazem wprowadzonym przez Microsoft.

Czym są zasady zarządzania aplikacjami w Entra ID

Uprawnienie do zarządzania rejestracją aplikacji nie powinno oznaczać dowolności jej konfiguracji. Właściciel może potrzebować możliwości zmiany ustawień, ale organizacja nadal powinna określać, jakie metody uwierzytelniania i okresy ważności są dopuszczalne. Zasady zarządzania aplikacjami, opisane w dokumentacji jako Application Management Policies, pozwalają blokować wybrane operacje tworzenia i modyfikowania aplikacji. Obejmują obiekty aplikacji oraz jednostki usługi, czyli obiekty reprezentujące aplikacje w danym katalogu organizacji. Zakres poszczególnych ograniczeń zależy od rodzaju obiektu i ustawień zasady.

Jak ograniczyć ważność sekretów i certyfikatów

Sekret klienta to poufna wartość, której aplikacja może używać do uwierzytelniania. Organizacja może zabronić dodawania nowych sekretów albo ustalić ich maksymalny okres ważności. Podobne ograniczenie okresu ważności można zastosować do certyfikatów używanych do uwierzytelniania aplikacji. Przykładowo, jeżeli organizacja wybierze limit 90 dni, dodanie nowego sekretu ważnego przez dwa lata do aplikacji objętej tym ograniczeniem zostanie odrzucone. To przykład decyzji organizacji, a nie zalecenie Microsoftu dotyczące uniwersalnego okresu ważności. W portalu ustawienie blokujące dodawanie haseł obejmuje zarówno sekrety, jak i klucze symetryczne. Przy konfiguracji przez Microsoft Graph odpowiadają im osobne ograniczenia. Trzeba uwzględnić oba, aby uzyskać taki sam zakres ochrony.

Jakie ustawienia aplikacji można kontrolować

Mechanizm obejmuje więcej niż sekrety i certyfikaty. Pozwala również ograniczać obsługiwane konta oraz identyfikatory URI aplikacji. Poniższe zestawienie zachowuje nazwy techniczne parametrów, aby ułatwić ich odnalezienie w dokumentacji.

OgraniczenieCo może wymusić
passwordAdditionBlokowanie dodawania nowych sekretów i kluczy symetrycznych
passwordLifetimeOgraniczenie maksymalnego okresu ważności nowych sekretów i kluczy symetrycznych
asymmetricKeyLifetimeOgraniczenie okresu ważności certyfikatów używanych do uwierzytelniania
audiencesOgraniczenie tworzenia aplikacji lub zmiany ich konfiguracji na obsługującą wiele katalogów organizacji albo osobiste konta Microsoft
nonDefaultUriAdditionDopuszczenie nowych identyfikatorów URI tylko w domyślnych formatach api://{appId} lub api://{tenantId}/{appId}
uriAdditionWithoutUniqueTenantIdentifierDopuszczenie nowych identyfikatorów URI tylko w obsługiwanych bezpiecznych formatach
customPasswordAdditionBlokowanie sekretów o wartości dostarczonej przez wywołującego; nie oznacza blokady wszystkich sekretów generowanych przez Entra ID
trustedCertificateAuthorityOgraniczenie dodawania certyfikatów według listy zaufanych urzędów certyfikacji. Konfiguracja przez interfejs programistyczny

Ograniczenie obsługiwanych kont pomaga zapobiegać nieuzasadnionemu rozszerzaniu przeznaczenia aplikacji. Nie należy jednak utożsamiać go z pełną kontrolą dostępu użytkowników do aplikacji – opisany mechanizm kontroluje jej konfigurację.

Zasada dla całej organizacji i wyjątki dla aplikacji

Microsoft Entra ID rozróżnia zasadę domyślną dla katalogu organizacji oraz zasady przypisywane do konkretnych aplikacji lub jednostek usługi. Pozwala to określić wspólny standard, a następnie zastosować uzasadnione odstępstwa lub dodatkowe ograniczenia. Do jednego obiektu można przypisać jedną zasadę niestandardową. Ma ona pierwszeństwo dla ograniczeń, które jawnie definiuje. Jeżeli nie określa danego ograniczenia, obowiązuje ustawienie z zasady domyślnej. Samo przypisanie wyjątku nie wyłącza więc wszystkich pozostałych zabezpieczeń. Portal pozwala stosować ograniczenia do wszystkich aplikacji, wszystkich z wyłączeniami albo do wybranych aplikacji. Potrzebne zasady niestandardowe tworzy i przypisuje w tle. Ich pełną listę można odczytać przez Microsoft Graph.

Co stanie się z istniejącymi sekretami

Włączenie ograniczenia nie usuwa sekretów dodanych wcześniej ani nie skraca automatycznie ich ważności. Microsoft wskazuje również, że niespełnienie nowych wymagań samo w sobie nie blokuje wydawania tokenów istniejącej aplikacji. Odrzucana jest operacja tworzenia lub aktualizacji, która narusza obowiązujące ograniczenie. W konfiguracji ograniczeń poświadczeń można dodatkowo uwzględnić datę utworzenia aplikacji. W związku z tym przed wdrożeniem trzeba sprawdzić nie tylko limit ważności, ale też zakres obiektów, do których będzie stosowany. Przegląd istniejących poświadczeń pozostaje osobnym zadaniem. Warto ustalić, kto odpowiada za każdą aplikację, gdzie jest używany jej sekret i kiedy można go bezpiecznie wymienić. Samo włączenie nowych zasad nie zastąpi porządkowania.

Wyjątki dla użytkowników i automatyzacji

Wyjątek może dotyczyć aplikacji albo użytkownika bądź jednostki usługi wykonującej zmianę. Ten drugi wariant wykorzystuje niestandardowe atrybuty zabezpieczeń. Przydaje się na przykład, gdy proces automatycznie tworzy aplikacje i wymaga czasu na dostosowanie do nowych wymagań. Zakres takiego odstępstwa trzeba ocenić szczególnie uważnie – dotyczy ono operacji wykonywanych przez wskazaną tożsamość, a nie wyłącznie jednej aplikacji. Zalecamy wskazać właściciela wyjątku, uzasadnienie i termin jego ponownej oceny.

Od czego zacząć wdrożenie

Najpierw sporządź wykaz aplikacji, poświadczeń i procesów, które je tworzą. Następnie określ dopuszczalne okresy ważności oraz potrzebne wyjątki. Przetestuj ograniczenia na wybranych aplikacjach, uwzględniając dodawanie sekretów, certyfikatów i działanie automatyzacji. Dopiero po sprawdzeniu skutków rozszerz zakres na pozostałe aplikacje. Ustawienia są dostępne w centrum administracyjnym Microsoft Entra, w obszarze aplikacji dla przedsiębiorstw i zasad aplikacji.

Dobrze ustawione zasady zarządzania aplikacjami pomagają egzekwować standard bezpieczeństwa w chwili wprowadzania zmian. Ich wdrożenie warto połączyć z przeglądem dotychczasowych sekretów i certyfikatów oraz uporządkowaniem odpowiedzialności za aplikacje.