Minska överprivilegierade behörigheter och appar

Som utvecklare som vill utforma och implementera program som följer de vägledande principerna för Nolltillit vill du öka programsäkerheten med minsta möjliga behörighet. Det är absolut nödvändigt att du minskar angreppsytan för ditt program och effekten av ett säkerhetsintrång.

I den här artikeln får du lära dig varför program inte ska begära fler behörigheter än de behöver. Du förstår termen överprivilegierad och identifierar rekommendationer och metodtips för att begränsa behörigheten i dina program för att hantera åtkomst och förbättra säkerheten.

Vad är överprivilegierat?

Överprivilegierad inträffar när ett program begär eller tar emot fler behörigheter än det behöver för att det ska fungera korrekt. Förbättra din förståelse av överprivilegierade med exempel på oanvända och reproducerbara behörigheter i resten av den här artikeln.

Oanvända behörigheter

För det här oanvända nyckelexemplet kan du tänka dig att det finns tre låsta dörrar (blå, gul och grön) enligt följande diagram.

Dina tillgångar är bakom dörrarna. Du har tre nycklar (blå, gul och grön) som gör att du kan öppna motsvarande dörr. Den blå nyckeln kan till exempel öppna den blå dörren. När du bara behöver åtkomst till den gula dörren bär du bara den gula nyckeln.

För att skydda dina tillgångar bäst kan du bara bära de nycklar du behöver när du behöver dem och behålla oanvända nycklar på en säker plats.

Reproducerbara behörigheter

Exemplet med reproducerbara nycklar är mer komplicerat än det oanvända nyckelexemplet där vi nu lägger till två specialnycklar som visas i följande diagram.

Den första svarta nyckeln är en passnyckel som kan öppna alla dörrar. Den andra svarta nyckeln kan öppna de gula och gröna dörrarna. När du bara behöver åtkomst till de gula och gröna dörrarna bär du bara den andra svarta nyckeln. Du håller din passeringsnyckel på en säker plats med den redundanta gröna nyckeln.

I Microsofts identitetsvärld är nycklarna åtkomstbehörigheter. Dina resurser och du, nyckelhållaren, är program. Om du förstår risken med att bära onödiga nycklar är du medveten om risken för att dina program har onödiga behörigheter.

Behörighetsgap och risk

Hur kan dörrar och nycklar hjälpa till att förstå hur överprivilegierad inträffar? Varför kan ditt program ha rätt behörighet att utföra en uppgift, men ändå vara överprivilegierad? Nu ska vi titta på det behörighetsgap som kan orsaka avvikelsen i följande diagram.

X-axeln representerar Tid och Y-axeln representerar Behörigheter. I början av den uppmätta tiden begär och får du behörighet för ditt program. När verksamheten växer och ändras över tid lägger du till nya behörigheter för att stödja dina behov och lutningen för Beviljade behörigheter ökar. De behörigheter som används kan vara lägre än beviljade behörigheter när du glömmer att ta bort onödiga behörigheter (till exempel om programmet inte bryts) vilket resulterar i ett behörighetsgap.

Här är intressanta observationer i Microsofts identitetsplattform.

• Vi har fler än 4 000 API:er i Microsoft Graph.
• Mer än 200 Microsoft Graph-behörigheter är tillgängliga på Microsofts identitetsplattform.
• Utvecklare har åtkomst till en mängd olika data och möjlighet att tillämpa kornighet på de behörigheter som deras appar begär.
• I våra undersökningar upptäckte vi att appar bara har 10 % fullständigt använda behörigheter för sina scenarier.

Tänk noga på vilka behörigheter din app faktiskt kräver. Se upp för behörighetsgapet och kontrollera regelbundet dina programbehörigheter.

Säkerhet komprometterad för överprivilegierad

Nu ska vi gå djupare in på de risker som följer av behörighetsluckor med ett exempel. Det här komprometterande scenariot består av två roller: IT-administratör och utvecklare.

• IT-administratör: Jeff är en klientorganisationsadministratör som ser till att program i Microsoft Entra-ID:t är tillförlitliga och säkra. En del av Jeffs jobb är att ge medgivande till behörigheter som apputvecklare behöver.
• Utvecklare: Kelly är en apputvecklare som använder Microsofts identitetsplattform och äger appar. Kellys jobb är att se till att program har rätt behörighet att utföra nödvändiga uppgifter.

Följande vanliga säkerhetskompromissscenario för överprivilegierad har vanligtvis fyra steg.

1. Först börjar utvecklaren konfigurera programmet och lägga till nödvändiga behörigheter.
2. För det andra granskar IT-administratören nödvändiga behörigheter och beviljar medgivande.
3. För det tredje börjar den dåliga aktören knäcka användarautentiseringsuppgifter och hackar användaridentiteten.
4. Om användaren äger flera program är de också överprivilegierade. Den felaktiga aktören kan snabbt använda token för den beviljade behörigheten för att hämta känsliga data.

Överprivilegierade program

En entitet överprivilegieras när den ber om eller tar emot fler behörigheter än den behöver. Definitionen av överprivilegierat program i Microsofts identitetsplattform är "alla program med oanvända eller reproducerbara behörigheter".

Vi använder Microsoft Graph som en del av Microsofts identitetsplattform i ett verkligt exempel för att bättre förstå oanvänd behörighet och reproducerbar behörighet.

Oanvänd behörighet inträffar när programmet får behörigheter som inte behövs för de önskade uppgifterna. Du skapar till exempel en kalenderapp. Din kalenderapp begär och får Files.ReadWrite.All behörighet. Appen integreras inte med några filers API:er. Därför har programmet en oanvänd Files.ReadWrite.All behörighet.

Det är svårare att identifiera reproducerbar behörighet. Det inträffar när programmet får få behörigheter men har ett lägre privilegierat alternativ som ger tillräcklig åtkomst för nödvändiga uppgifter. I exemplet med kalenderappen begär och tar din app emot Files.ReadWrite.All behörighet. Den behöver dock bara läsa filer från den inloggade användarens OneDrive och behöver aldrig skapa nya filer eller ändra befintliga filer. I det här fallet använder Files.ReadWrite.All ditt program bara delvis, så du måste nedgradera till Files.Read.All.

Rekommendationer för att minska överprivilegierade scenarier

Säkerhet är en resa, inte ett mål. Det finns tre olika faser i säkerhetslivscykeln:

• Prevention (Skydd)
• Granskning
• Åtgärder

Följande diagram illustrerar rekommendationer för att minska överprivilegierade scenarier.

• Förhindra: När du skapar ett program bör du fullt ut förstå den behörighet som krävs för de API-anrop som ditt program behöver göra och endast begära det som krävs för att aktivera ditt scenario. Microsoft Graph-dokumentationen innehåller tydliga referenser för behörigheter med minst behörighet till de flesta privilegierade behörigheterna för alla slutpunkter. Tänk på överprivilegierade scenarier när du avgör vilka behörigheter du behöver.
• Granskning: Du och IT-administratörer bör regelbundet granska befintliga program tidigare beviljade privilegier.
• Åtgärda: Om du eller IT-administratörer märker ett program med överprivilegierad behörighet i ekosystemet bör du sluta begära token för överprivilegierad behörighet. IT-administratörer bör återkalla beviljade medgivanden. Det här steget kräver vanligtvis en kodändring.

Metodtips för att upprätthålla behörigheter med minst behörighet

Två viktiga incitament för att upprätthålla behörighet med minst behörighet med dina program driver programimplementeringen och stoppar spridningen.

• Driva på implementeringen genom att skapa en tillförlitlig app för kunder som undviker orimliga behörighetsbegäranden. Begränsa programbehörigheterna till endast det som krävs för att slutföra uppgiften. Den här metoden minskar risken för explosionsradie av attacker och ökar kundernas implementering av dina appar. Tillämpa mer granskning när du granskar behörigheter som program begär och bestämmer om appbehörigheter ska beviljas.
• Stoppa spridningen genom att se till att angripare inte kan använda överdrivna privilegier för att få ytterligare åtkomst. När du skapar en app som ber om onödiga behörigheter är det minst troligt att den får godkännande eller nekas helt och hållet. Det bästa sättet att kontrollera skador är att förhindra att angripare får utökade privilegier som ökar kompromissens omfattning. Om ditt program till exempel bara behöver User.ReadBasic.All läsa grundläggande användarinformation är dina OneDrive, Outlook, Teams och eventuella konfidentiella data säkra om en app komprometteras.

Nästa steg

• Med auktorisering för åtkomst till resurser kan du förstå hur du bäst kan se till att Nolltillit när du hämtar behörigheter för resursåtkomst för ditt program.
• Att skapa appar med en Nolltillit metod för identitet ger en översikt över behörigheter och metodtips för åtkomst.
• Anpassa token beskriver den information som du kan ta emot i Microsoft Entra-token. Den förklarar hur du anpassar token för att förbättra flexibiliteten och kontrollen samtidigt som du ökar säkerheten för program utan förtroende med minsta möjliga behörighet.
• Konfigurera gruppanspråk och approller i token visar hur du konfigurerar dina appar med approlldefinitioner och tilldelar säkerhetsgrupper till approller. De här metoderna bidrar till att förbättra flexibiliteten och kontrollen samtidigt som säkerheten för program utan förtroende ökar med minsta möjliga behörighet.
• Att uppnå Nolltillit beredskap i dina appar: Design för lägsta behörighet hjälper dig att utforma appar med principen om minst privilegierad åtkomst med Microsofts identitetsplattform.
• Öka programsäkerheten med principen om minsta behörighet hjälper dig att minska angreppsytan för ett program och effekten av en säkerhetsöverträdelse (explosionsradien) om en inträffar i ett Microsofts identitetsplattform integrerat program.
• Graph Explorer - och Microsoft Graph-behörighetsreferensen hjälper dig att välja Microsoft Graph API-anrop för att aktivera ditt appscenario och hitta motsvarande behörigheter från minst till mest privilegierade.