Overprivilegeerde machtigingen en apps verminderen

Als ontwikkelaar die zich richt op het ontwerpen en implementeren van toepassingen die voldoen aan de richtlijnen van Zero Trust, wilt u de beveiliging van toepassingen verbeteren met minimale bevoegdheden. Het is belangrijk dat u de kwetsbaarheid voor aanvallen van uw toepassing en het effect van een beveiligingsschending vermindert.

In dit artikel leert u waarom toepassingen niet meer machtigingen moeten aanvragen dan ze nodig hebben. U begrijpt de term overprivilegeerd en ontdekt aanbevelingen en aanbevolen procedures voor het beperken van bevoegdheden in uw toepassingen om de toegang te beheren en de beveiliging te verbeteren.

Wat is te duur?

Overprivileged treedt op wanneer een toepassing meer machtigingen aanvraagt of ontvangt dan nodig is om deze goed te laten functioneren. Verbeter uw begrip van te veel bevoegdheden met voorbeelden van ongebruikte en verleidbare machtigingen in de rest van dit artikel.

Ongebruikte machtigingen

Stel voor dit voorbeeld van ongebruikte sleutel dat er drie vergrendelde deuren (blauw, geel en groen) zijn, zoals wordt weergegeven in het volgende diagram.

Uw assets liggen achter de deuren. U hebt drie toetsen (blauw, geel en groen) waarmee u de bijbehorende deur kunt openen. De blauwe sleutel kan bijvoorbeeld de blauwe deur openen. Wanneer u alleen toegang nodig hebt tot de gele deur, draagt u alleen de gele sleutel.

Om uw assets het beste te beveiligen, draagt u alleen de sleutels die u nodig hebt wanneer u ze nodig hebt en bewaart u ongebruikte sleutels op een veilige locatie.

Reduceerbare machtigingen

Het voorbeeld van verleidbare sleutels is ingewikkelder dan het voorbeeld van de ongebruikte sleutel waaraan we nu twee speciale sleutels toevoegen, zoals wordt weergegeven in het volgende diagram.

De eerste zwarte sleutel is een wachtwoordsleutel die alle deuren kan openen. De tweede zwarte toets kan de gele en de groene deuren openen. Als je alleen toegang nodig hebt tot de gele en groene deuren, draag je alleen de tweede zwarte sleutel. U behoudt uw wachtwoordsleutel op een veilige locatie met de redundante groene sleutel.

In de microsoft-identiteitswereld zijn de sleutels toegangsmachtigingen. Uw resources en u, de sleutelhouder, zijn toepassingen. Als u het risico van het dragen van onnodige sleutels begrijpt, bent u zich bewust van het risico dat uw toepassingen onnodige machtigingen hebben.

Machtigingsverschil en risico

Hoe kunnen deuren en sleutels helpen om te begrijpen hoe overprivileged zich voordoet? Waarom kan uw toepassing over de juiste machtigingen beschikken om een taak uit te voeren, maar nog steeds te veel worden gemachtigd? Laten we eens kijken naar de machtigingsruimte die de discrepantie in het volgende diagram kan veroorzaken.

De X-as vertegenwoordigt Tijd en de Y-as vertegenwoordigt Machtigingen. Aan het begin van de gemeten tijd vraagt en ontvangt u toestemming voor uw toepassing. Naarmate het bedrijf groeit en verandert in de loop van de tijd, voegt u nieuwe machtigingen toe om uw behoeften te ondersteunen en neemt de helling van verleende machtigingen toe. De gebruikte machtigingen zijn mogelijk lager dan Verleende machtigingen wanneer u vergeet onnodige machtigingen te verwijderen (bijvoorbeeld als de toepassing niet wordt onderbroken), wat resulteert in een machtigingsverschil.

Hier volgen interessante opmerkingen in het Microsoft Identity Platform.

• We hebben meer dan 4000 API's in Microsoft Graph.
• Er zijn meer dan 200 Microsoft Graph-machtigingen beschikbaar op het Microsoft Identity Platform.
• Ontwikkelaars hebben toegang tot een breed scala aan gegevens en de mogelijkheid om granulariteit toe te passen op de machtigingen die hun apps aanvragen.
• In ons onderzoek hebben we vastgesteld dat apps slechts 10% volledig gebruiksmachtigingen hebben voor hun scenario's.

Denk goed na over welke machtigingen uw app daadwerkelijk vereist. Pas op voor het machtigingsverschil en controleer regelmatig uw toepassingsmachtigingen.

Beveiliging gecompromitteerd voor overprivileged

Laten we dieper ingaan op de risico's die het gevolg zijn van hiaten in machtigingen met een voorbeeld. Dit scenario bestaat uit twee rollen: IT-beheerder en ontwikkelaar.

• IT-beheerder: Jeff is een tenantbeheerder die ervoor zorgt dat toepassingen in Microsoft Entra ID betrouwbaar en veilig zijn. Een deel van de taak van Jeff is om toestemming te verlenen aan machtigingen die app-ontwikkelaars nodig hebben.
• Ontwikkelaar: Kelly is een app-ontwikkelaar die gebruikmaakt van het Microsoft Identity Platform en eigenaar is van apps. Kelly's taak is ervoor te zorgen dat toepassingen over de juiste machtigingen beschikken om vereiste taken uit te voeren.

Het volgende veelvoorkomende scenario voor beveiligingsrisico's voor overprivileged heeft doorgaans vier fasen.

1. Eerst begint de ontwikkelaar de toepassing te configureren en vereiste machtigingen toe te voegen.
2. Ten tweede controleert de IT-beheerder de vereiste machtigingen en verleent hij toestemming.
3. Ten derde begint de slechte actor gebruikersreferenties te kraken en wordt de gebruikersidentiteit gehackt.
4. Als de gebruiker eigenaar is van meerdere toepassingen, zijn ze ook te veel gemachtigd. De slechte actor kan snel het token van de verleende machtiging gebruiken om gevoelige gegevens op te halen.

Toepassingen met teveel bevoegdheden

Een entiteit is te veel gemachtigd wanneer deze om meer machtigingen vraagt of ontvangt dan nodig is. De definitie van overprivilegeerde toepassing in het Microsoft Identity Platform is: 'elke toepassing met ongebruikte of verleidbare machtigingen'.

We gaan Microsoft Graph gebruiken als onderdeel van het Microsoft Identity Platform in een praktijkvoorbeeld om meer inzicht te krijgen in ongebruikte machtigingen en terug te leiden machtigingen.

Ongebruikte machtiging treedt op wanneer uw toepassing machtigingen ontvangt die niet nodig zijn voor de gewenste taken. U bouwt bijvoorbeeld een agenda-app. Uw agenda-app vraagt om toestemming en ontvangt machtigingen Files.ReadWrite.All . Uw app kan niet worden geïntegreerd met api's van bestanden. Daarom heeft uw toepassing een ongebruikte Files.ReadWrite.All machtiging.

De leesbare machtiging is moeilijker te detecteren. Dit gebeurt wanneer uw toepassing weinig machtigingen ontvangt, maar een alternatief met lagere bevoegdheden heeft dat voldoende toegang biedt voor vereiste taken. In het voorbeeld van de agenda-app vraagt uw app toestemming aan en ontvangt deze Files.ReadWrite.All machtigingen. Het hoeft echter alleen bestanden te lezen uit de OneDrive van de aangemelde gebruiker en hoeft nooit nieuwe bestanden te maken of bestaande bestanden te wijzigen. In dit geval wordt uw toepassing slechts gedeeltelijk gebruikt Files.ReadWrite.All , dus u moet downgraden naar Files.Read.All.

Aanbevelingen voor het verminderen van overprivilegeerde scenario's

Beveiliging is een reis, geen bestemming. Er zijn drie verschillende fasen in de beveiligingslevenscyclus:

• Preventie
• Controle
• Herstel

In het volgende diagram ziet u aanbevelingen voor het verminderen van overprivilegeerde scenario's.

• Voorkomen: wanneer u een toepassing bouwt, moet u volledig inzicht hebben in de vereiste machtigingen voor de API-aanroepen die uw toepassing moet maken en moet u alleen aanvragen wat nodig is om uw scenario in te schakelen. Microsoft Graph-documentatie bevat duidelijke verwijzingen voor machtigingen met minimale bevoegdheden voor de meeste bevoegde machtigingen voor alle eindpunten. Houd rekening met overprivilegeerde scenario's wanneer u bepaalt welke machtigingen u nodig hebt.
• Controle: U en IT-beheerders moeten regelmatig de eerder verleende bevoegdheden van bestaande toepassingen controleren.
• Herstel: Als u of IT-beheerders een te veelgestelde toepassing in het ecosysteem opmerken, moet u stoppen met het aanvragen van tokens voor de overprivilegeerde machtiging. IT-beheerders moeten de verleende toestemming intrekken. Voor deze stap is meestal een codewijziging vereist.

Aanbevolen procedures voor het onderhouden van machtiging voor minimale bevoegdheden

Twee belangrijke stimulansen voor het onderhouden van machtigingen voor minimale bevoegdheden met uw toepassingen zorgen voor de acceptatie van toepassingen en het stoppen van de verspreiding.

• Stimuleren van acceptatie door een betrouwbare app te bouwen voor klanten die overmatige machtigingsaanvragen voorkomen. Beperk uw toepassingsmachtigingen tot alleen wat deze nodig heeft om de taak te voltooien. Deze praktijk vermindert de potentiële straal van aanvallen en verhoogt de acceptatie van uw apps door de klant. Pas meer controle toe bij het controleren van machtigingen die toepassingen aanvragen en bepalen of app-machtigingen moeten worden verleend.
• Stop de verspreiding door ervoor te zorgen dat aanvallers geen overmatige bevoegdheden kunnen gebruiken om verdere toegang te krijgen. Wanneer u een app maakt waarin om onnodige machtigingen wordt gevraagd, is het minst waarschijnlijk dat deze goedkeuring ontvangt of helemaal wordt geweigerd. De beste manier om schade te beheersen, is om te voorkomen dat aanvallers verhoogde bevoegdheden krijgen die het bereik van het compromis vergroten. Als uw toepassing bijvoorbeeld alleen basisgegevens van gebruikers hoeft User.ReadBasic.All te lezen, zijn uw OneDrive, Outlook, Teams en eventuele vertrouwelijke gegevens veilig als een app is gecompromitteerd.

Volgende stappen

• U kunt autorisatie verkrijgen voor toegang tot resources om te begrijpen hoe u Zero Trust het beste kunt garanderen bij het verkrijgen van machtigingen voor toegang tot resources voor uw toepassing.
• Het bouwen van apps met een Zero Trust-benadering voor identiteit biedt een overzicht van machtigingen en aanbevolen procedures voor toegang.
• Tokens aanpassen beschrijft de informatie die u kunt ontvangen in Microsoft Entra-tokens. In dit artikel wordt uitgelegd hoe u tokens aanpast om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van nul vertrouwensrelaties met minimale bevoegdheden te verhogen.
• Als u groepsclaims en app-rollen in tokens configureert, ziet u hoe u uw apps configureert met app-roldefinities en beveiligingsgroepen toewijst aan app-rollen. Deze methoden helpen om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van de toepassing nul vertrouwen te verhogen met minimale bevoegdheden.
• Zero Trust-gereedheid in uw apps bereiken: Met ontwerpen voor minimale bevoegdheden kunt u apps ontwerpen met behulp van het principe van minimale toegang met het Microsoft Identity Platform.
• Verhoog de toepassingsbeveiliging met het principe van minimale bevoegdheden om de kwetsbaarheid voor aanvallen van een toepassing te verminderen en het effect van een beveiligingsschending (de straal van de straal) moet zich voordoen in een geïntegreerde Microsoft Identity Platform-toepassing.
• Naslaginformatie over Graph Explorer- en Microsoft Graph-machtigingen helpt u bij het selecteren van Microsoft Graph API-aanroepen om uw app-scenario in te schakelen en bijbehorende machtigingen te vinden van minimaal tot meest bevoegd.