Metodtips för säkerhet för programegenskaper i Microsoft Entra-ID

Säkerhet är ett viktigt begrepp när du registrerar ett program i Microsoft Entra-ID och är en viktig del av dess affärsanvändning i organisationen. Eventuella felkonfigurationer av ett program kan leda till stilleståndstid eller kompromisser. Beroende på vilka behörigheter som läggs till i ett program kan det finnas organisationsomfattande effekter.

Eftersom säkra program är viktiga för organisationen kan eventuella driftstopp på grund av säkerhetsproblem påverka verksamheten eller någon kritisk tjänst som verksamheten är beroende av. Därför är det viktigt att allokera tid och resurser för att säkerställa att programmen alltid är i ett felfritt och säkert tillstånd. Utför en regelbunden säkerhets- och hälsobedömning av program, ungefär som en utvärdering av säkerhetshotmodellen för kod. Ett bredare perspektiv på säkerhet för organisationer finns i SDL (Security Development Lifecycle).

I den här artikeln beskrivs metodtips för säkerhet för följande programegenskaper och scenarier:

• Identitetstyp
• Behörigheter
• Omdirigerings-URI:er
• Konfiguration av implicit flöde
• Program-ID-URI (kallas även identifierar-URI)
• Åtkomsttokenversion
• Lås för programinstans
• Programägarskap

Identitetstyp

Du är förmodligen här för att lära dig mer om metodtips för säkerhet för Microsoft Entra-program – även kallade appregistreringar eller appobjekt. Det finns dock en annan identitetstyp som kan användas för att komma åt Entra-skyddade resurser, som kallas hanterade identiteter för Azure-resurser.

Azure-hanterade identiteter är säkra som standard och kräver lite eller inga löpande underhåll eller omkostnader. Överväg att använda en hanterad identitet i stället för ett Microsoft Entra-program för din appidentitet om allt följande är sant:

• Tjänsten körs i Azure-molnet
• Appen behöver inte logga in användare
• Appen behöver inte fungera som resurs i ett tokenflöde (är inte ett webb-API)
• Appen behöver inte fungera i flera olika klientorganisationer

Resten av den här artikeln beskriver metodtips för säkerhet för egenskaper för Entra-appregistreringar.

Autentiseringsuppgifter (inklusive certifikat och hemligheter)

Autentiseringsuppgifter är en viktig del av ett program när det används som en konfidentiell klient. På sidan Certifikat och hemligheter för programmet i Azure-portalen kan autentiseringsuppgifter läggas till eller tas bort.

Överväg följande vägledning som rör certifikat och hemligheter:

• Använd en hanterad identitet som autentiseringsuppgifter när det är möjligt. Detta rekommenderas starkt eftersom hanterade identiteter både är det säkraste alternativet och inte kräver någon pågående hantering av autentiseringsuppgifter. Följ den här vägledningen för att konfigurera en hanterad identitet som en autentiseringsuppgift. Det här alternativet kan dock bara vara möjligt om tjänsten som appen används i körs i Azure.
• Om tjänsten som appen används i inte körs i Azure, men körs på en annan plattform som erbjuder automatiserad hantering av autentiseringsuppgifter, bör du överväga att använda en identitet från den plattformen som en autentiseringsuppgift. Ett GitHub-åtgärdsarbetsflöde kan till exempel konfigureras som en autentiseringsuppgift, vilket eliminerar behovet av att hantera och skydda autentiseringsuppgifter för GitHub Actions-pipelinen. Var försiktig med den här metoden och konfigurera endast federerade autentiseringsuppgifter från plattformar som du litar på. En app är bara lika säker som identitetsplattformen som den har konfigurerat som en autentiseringsuppgift.
• Om det inte går att använda en hanterad identitet eller någon annan säker extern identitetsprovider använder du certifikatautentiseringsuppgifter. Använd inte autentiseringsuppgifter för lösenord, även kallat hemligheter. Det är praktiskt att använda lösenordshemligheter som autentiseringsuppgifter, men lösenordsuppgifter hanteras ofta felaktigt och kan lätt komprometteras.
• Om ett certifikat måste användas i stället för en hanterad identitet lagrar du certifikatet i ett säkert nyckelvalv, till exempel Azure Key Vault.
• Om ett certifikat måste användas i stället för en hanterad identitet använder du ett certifikat från en betrodd certifikatutfärdare (CA) i stället för ett självsignerat certifikat. Konfigurera en princip för att framtvinga att certifikat kommer från betrodda utfärdare. Men om det inte går att använda en betrodd certifikatutfärdare föredras självsignerade certifikat framför lösenord.
• Konfigurera principer för programhantering för att styra användningen av hemligheter genom att begränsa deras livslängd eller blockera användningen helt och hållet.
• Om ett program endast används som en offentlig eller installerad klient (till exempel mobilappar eller skrivbordsappar som är installerade på slutanvändarens dator) kontrollerar du att inga autentiseringsuppgifter har angetts för programobjektet.
• Granska de autentiseringsuppgifter som används i program för färsk användning och förfallotid för dem. En oanvänd autentiseringsuppgift i ett program kan leda till en säkerhetsöverträdelse. Rollover-autentiseringsuppgifter ofta och dela inte autentiseringsuppgifter mellan program. Har inte många autentiseringsuppgifter för ett program.
• Övervaka dina produktionspipelines för att förhindra att autentiseringsuppgifter av något slag checkas in i kodlagringsplatser. Skanner för autentiseringsuppgifter är ett statiskt analysverktyg som kan användas för att identifiera autentiseringsuppgifter (och annat känsligt innehåll) i källkod och kompileringsutdata.

Omdirigerings-URI:er

Det är viktigt att hålla omdirigerings-URI:er för ditt program uppdaterade. Under Autentisering för programmet i Azure Portal måste en plattform väljas för programmet och sedan kan egenskapen Omdirigerings-URI definieras.

Överväg följande vägledning för omdirigerings-URI:er:

• Behåll ägarskapet för alla URI:er. Ett fel i ägarskapet för en av omdirigerings-URI:erna kan leda till att programmet komprometteras.
• Kontrollera att alla DNS-poster uppdateras och övervakas regelbundet för ändringar.
• Använd inte svars-URL:er för jokertecken eller osäkra URI-scheman som http eller URN.
• Håll listan liten. Trimma eventuella onödiga URI:er. Om möjligt uppdaterar du URL:er från Http till Https.

Konfiguration av implicit flöde

Scenarier som kräver implicit flöde kan nu använda autentiseringskodflöde för att minska risken för kompromisser som är associerade med implicit flödesmissbruk. Under Autentisering för programmet i Azure Portal måste en plattform väljas för programmet och sedan kan egenskapen Åtkomsttoken (används för implicita flöden) anges.

Överväg följande vägledning som rör implicit flöde:

• Förstå om implicit flöde krävs. Använd inte implicit flöde om det inte uttryckligen krävs.
• Om programmet har konfigurerats för att ta emot åtkomsttoken med implicit flöde, men inte aktivt använder dem, inaktiverar du inställningen för att skydda mot missbruk.
• Använd separata program för giltiga implicita flödesscenarier.

Program-ID-URI (kallas även identifierar-URI)

Programmets URI-egenskap för program-ID anger den globalt unika URI som används för att identifiera webb-API:et. Det är prefixet för omfångsvärdet i begäranden till Microsoft Entra. Det är också värdet för målgruppsanspråket (aud) i v1.0-åtkomsttoken. För program med flera klienter måste värdet också vara globalt unikt. Det kallas även för en identifierar-URI. Under Exponera ett API för programmet i Azure Portal kan egenskapen Program-ID URI definieras.

Metodtips för att definiera program-ID-URI-ändringen beroende på om appen utfärdas v1.0 eller v2.0-åtkomsttoken. Om du är osäker på om en app har fått v1.0-åtkomsttokens utfärdade, kontrollerar du requestedAccessTokenVersion för appmanifestet. Värdet null eller 1 anger att appen tar emot v1.0-åtkomsttoken. Värdet 2 anger att appen tar emot v2.0-åtkomsttoken.

För program som utfärdas v1.0-åtkomsttoken ska endast standard-URI:er användas. Standard-URI:er är api://<appId> och api://<tenantId>/<appId>. – Konfigurera begränsningen nonDefaultUriAddition i principer för programhantering för att framtvinga den här bästa metoden för framtida uppdateringar av program i din organisation.

För program som utfärdas v2.0-åtkomsttoken använder du följande riktlinjer när du definierar app-ID-URI:n:

• URI-scheman för api eller https rekommenderas. Ange egenskapen i de format som stöds för att undvika URI-kollisioner i din organisation. Använd inte jokertecken.
• Använd en verifierad domän i din organisation.
• Håll en inventering av URI:erna i din organisation för att upprätthålla säkerheten.

Följande API- och HTTP-schemabaserade program-ID URI-format stöds. Ersätt platshållarvärdena enligt beskrivningen i listan som följer tabellen.

• <appId> – programidentifieraregenskapen (appId) för programobjektet.
• <string> – strängvärdet för värden eller api-sökvägssegmentet.
• <tenantId> – ett GUID som genereras av Azure för att representera klientorganisationen i Azure.
• < > , där - < är det första domännamnet som klientskapare angav när klientorganisationen skapades.
• <verifiedCustomDomain> – en verifierad anpassad domän som konfigurerats för din Microsoft Entra-klientorganisation.

Åtkomsttokenversion

Det här avsnittet gäller endast för resursapplikationer, vilket innebär applikationer som agerar som mottagare i åtkomsttokens. Resursprogram är vanligtvis webb-API:er. Om ett program bara fungerar som en klient (vilket innebär att det hämtar token för att skicka till resurser som Microsoft Graph) gäller inte det här avsnittet.

Resursprogram som har konfigurerat anpassade identifierar-URI:er bör använda formatet för v2.0-åtkomsttoken. Om du vill kontrollera om en app ska använda v2.0-åtkomsttoken, titta på identifierUris-egenskapen på appregistreringarnas manifestsida för appen.

Om det finns några värden som har konfigurerats där inte i formatet api://{appId} eller api://{tenantId}/{appId}, bör appen använda v2.0-åtkomsttoken.

Om du vill uppgradera till v2.0-åtkomsttoken kontrollerar du först att appen kan hantera v2.0-tokenanspråk. Uppdatera sedan versionen av åtkomsttokenet som utfärdas till applikationen med hjälp av manifestredigeringsverktyget.

När programkonfigurationen har uppdaterats för att använda v2.0-token kontrollerar du att programmets logik för målgruppsverifiering ändras så att den endast accepterar dess appId.

Lås för applikationsinstansegenskap

När ett program har ett huvudnamn för tjänsten etablerat i en klientorganisation kan tjänstens huvudnamn anpassas av en klientadministratör. Detta gäller oavsett om den klientorganisationen är programmets hemklientorganisation eller en sekundär klientorganisation. Dessa anpassningsfunktioner kan möjliggöra ändringar som appägaren inte förväntade sig, vilket leder till säkerhetsrisker. Autentiseringsuppgifter kan till exempel läggas till i tjänstens huvudnamn, även om autentiseringsuppgifter vanligtvis ska ägas och kontrolleras av apputvecklaren och ägaren.

För att minska den här risken bör program konfigurera appinstanslås. När du konfigurerar appinstanslås låser du alltid alla tillgängliga känsliga egenskaper. Att konfigurera den här egenskapen är särskilt kritiskt för multitenant-applikationer, vilket innebär applikationer som används av flera hyresgäster eller organisationer, men den kan och bör konfigureras av alla applikationer.

Behörigheter

Ditt program kan behöva beviljas behörighet för att få åtkomst till skyddade resurser eller API:er. När du begär behörigheter kontrollerar du alltid följande:

• Följ principerna för lägsta behörighet . Begär endast den behörighet som ger minst tillåtande åtkomst som krävs för att utföra den åtgärd som appen behöver vidta. Om du anropar Microsoft Graph använder du API-dokumentationen för att identifiera den minst tillåtande behörigheten för ett visst API-anrop. Granska regelbundet appens behörigheter för att kontrollera om ett mindre privilegierat alternativ är tillgängligt. Om en app inte längre behöver en behörighet tar du bort den.
• Använd delegerad åtkomst i stället för endast appåtkomst när det är möjligt.
• Granska dokumentationen om behörigheter och medgivande för att se till att du förstår grunderna i behörigheter.

Konfiguration av appägarskap

Ägare kan hantera alla aspekter av ett registrerat program. Det är viktigt att regelbundet granska ägarskapet för alla program i organisationen. Mer information finns i Microsoft Entra-åtkomstgranskningar. Under Ägare för programmet i Azure Portal kan programmets ägare hanteras.

Överväg följande vägledning om att ange programägare:

• Programägarskapet bör hållas till en minimal uppsättning personer i organisationen.
• En administratör bör granska ägarlistan en gång med några månaders mellanrum för att se till att ägarna fortfarande är en del av organisationen och fortfarande bör äga ett program.

Kontrollera Entra-rekommendationer

Funktionen Microsoft Entra-rekommendationer hjälper dig att övervaka statusen för din klientorganisation så att du inte behöver göra det. De här rekommendationerna hjälper till att säkerställa att din klientorganisation är i ett säkert och felfritt tillstånd samtidigt som du kan maximera värdet för de funktioner som är tillgängliga i Microsoft Entra-ID. Granska regelbundet alla aktiva Microsoft Entra-rekommendationer som gäller appegenskaper eller appkonfiguration för att hålla appens ekosystem i ett felfritt tillstånd.