Utveckla en strategi för programbehörigheter

När du lär dig att utveckla med hjälp av Nolltillit principer kan du läsa den här artikeln när du har granskat Hämta auktorisering för att få åtkomst till resurser och utveckla en strategi för delegerade behörigheter. Definiera din metod för programbehörigheter för hantering av autentiseringsuppgifter när du använder Microsofts identitetsplattform för att autentisera och auktorisera dina program och hantera behörigheter och medgivande.

När ingen användare är inblandad har du ingen effektiv behörighetsmodell eftersom ditt program alltid beviljas samma behörigheter som den specifika användaren av ditt program har beviljats.

• Appen bevisar att det är appen som begär behörighet. Ditt program kommer att bevisa sin egen identitet med någon av följande metoder:

  • ett certifikat, vilket är det bästa alternativet, eller
  • en hemlighet i ett avancerat system för hemlig hantering, eller
  • en hemlighet när du utvecklar dina tjänster i Azure och använder hanterade identiteter för Azure-resurser. Se följande avsnitt Om att hantera programautentiseringsuppgifter.

• Appen kräver alltid förhandsmedgivande från administratören. Programmet begär den här behörigheten med omfånget .default . Den begär de behörigheter som administratören tilldelar programmet. Oavsett namngivning för ett visst omfång gäller dessa behörigheter för alla användare som standard.

• Funktioner för transanvändare. Som standard User.ReadWrite.All gör det möjligt för ditt program att uppdatera varje användares profil, även Calendar.Read. Som programbehörighet kan programmet läsa kalendern för varje användare i klientorganisationen.

• Behörigheter som beviljats appen är alltid de behörigheter som används. Till skillnad från en delegerad behörighet begränsas inte programbehörigheter av vad en viss användare kan göra.

Begränsa programbehörigheter

Det finns tre sätt att begränsa ett program till mindre än global åtkomst.

• Microsoft Teams-appar har resursspecifikt medgivande (RSC) som gör att ett program kan komma åt ett specifikt team i stället för att komma åt alla team i företaget. RSC är en Microsoft Teams- och Microsoft Graph API-integrering som gör att din app kan använda API-slutpunkter och hantera specifika resurser. Dess behörighetsmodell gör det möjligt för Teams- och chattägare att ge ditt program tillstånd att komma åt och ändra sina Teams- och Chattdata.

• Microsoft Exchange-administratörer kan skapa Exchange-programprinciper för att begränsa appåtkomsten till specifika postlådor med ett PowerShell-skript. De kan begränsa ett visst program till specifika postlådor med Calendar.Read eller Mail.Read åtkomst. På så sätt kan du till exempel skapa en automatisering som bara kan läsa en postlåda eller bara skicka e-post från en postlåda och inte från alla i företaget.

• SharePoint har Sites.Selected som ett specifikt omfång för att tillåta detaljerade behörigheter för åtkomst till SharePoint med ett program. Om du väljer Sites.Selected för ditt program i stället för någon av de andra behörigheterna resulterar det som standard i att ditt program inte har åtkomst till några SharePoint-webbplatssamlingar. Administratören använder slutpunkten för webbplatsbehörigheter för att bevilja läs-, skriv- eller läs- och skrivbehörighet till ditt program.

Hantera autentiseringsuppgifter för program

Autentiseringshygien kan säkerställa att ditt program snabbt återställs från ett potentiellt intrång. Följande metodtips hjälper dig att utveckla program som utför identifiering och reparation samtidigt som du undviker driftstopp och påverkar legitima användare. Dessa rekommendationer stöder Nolltillit princip om att anta intrång när du förbereder dig för att svara på en säkerhetsincident.

• Ta bort alla hemligheter från kod och konfiguration. När du använder Azure-plattformen placerar du hemligheter i Key Vault och kommer åt dem via hanterade identiteter för Azure-resurser. Gör koden elastisk för att hantera hemliga rotationer om en kompromiss inträffar. IT-administratörer kan ta bort och rotera hemligheter och certifikat utan att ta bort ditt program eller påverka legitima användare.

• Använd certifikat i stället för klienthemligheter om det inte finns en säker process för att hantera hemligheter. Angripare vet att klienthemligheter tenderar att hanteras på ett mindre säkert sätt och att den läckta hemliga användningen är svår att spåra. Certifikat kan hanteras och återkallas bättre om de komprometteras. När du använder hemligheter skapar eller använder du en säker no-touch-distribution och rollover-process för dem. Använd hemligheter med en angiven giltighetstid (till exempel ett år, två år) och undvik att aldrig upphör att gälla.

• Rulla regelbundet över certifikat och hemligheter för att skapa återhämtning i ditt program och undviker avbrott på grund av en nödåterställning.

Nästa steg

• När du skaffar auktorisering för åtkomst till resurser kan du förstå hur du bäst kan säkerställa Nolltillit när du hämtar behörigheter för resursåtkomst för ditt program.
• Genom att utveckla en strategi för delegerade behörigheter kan du implementera den bästa metoden för att hantera behörigheter i ditt program och utveckla med hjälp av Nolltillit principer.
• Metodtips för auktorisering hjälper dig att implementera de bästa auktoriserings-, behörighets- och medgivandemodellerna för dina program.
• Att begära behörigheter som kräver administrativt medgivande beskriver behörigheten och medgivandeupplevelsen när programbehörigheter kräver administrativt medgivande.
• API Protection beskriver metodtips för att skydda ditt API genom registrering, definiera behörigheter och medgivande samt framtvinga åtkomst för att uppnå dina Nolltillit mål.
• Att ange autentiseringsuppgifter för programidentitet när det inte finns någon användare förklarar varför den bästa metoden för Nolltillit klientautentiseringsuppgifter för tjänster (icke-användarprogram) i Azure är hanterade identiteter för Azure-resurser.