Delen via

Toepassingsbeveiliging verhogen met behulp van Zero Trust-principes

  • Artikel

Een beveiligde netwerkperimeter rond de toepassingen die zijn ontwikkeld, kan niet worden aangenomen. Bijna elke ontwikkelde toepassing wordt standaard geopend vanaf buiten de netwerkperimeter. Toepassingen kunnen niet worden gegarandeerd veilig wanneer ze zijn ontwikkeld of blijven zo nadat ze zijn geïmplementeerd. Het is de verantwoordelijkheid van de ontwikkelaar van de toepassing om niet alleen de beveiliging van de toepassing te maximaliseren, maar ook om de schade die de toepassing kan veroorzaken te minimaliseren als deze is aangetast.

Daarnaast omvat de verantwoordelijkheid de ondersteuning van de veranderende behoeften van de klanten en gebruikers, die verwachten dat de toepassing voldoet aan de beveiligingsvereisten van Zero Trust. Leer de principes van het Zero Trust-model en gebruik de procedures. Door de principes te leren en te gebruiken, kunnen toepassingen worden ontwikkeld die veiliger zijn en die de schade die ze kunnen veroorzaken, minimaliseren als er sprake is van een onderbreking in de beveiliging.

Het Zero Trust-model schrijft een cultuur voor van expliciete verificatie in plaats van impliciet vertrouwen. Het model is verankerd op drie belangrijke uitgangspunten:

  • Expliciet verifiëren
  • Toegang met minimale bevoegdheden gebruiken
  • Stel dat er sprake is van een schending

Best practices voor Zero Trust

Volg deze aanbevolen procedures om Zero Trust-toepassingen te bouwen met het Microsoft Identity Platform en de bijbehorende hulpprogramma's.

Expliciet verifiëren

Het Microsoft Identity Platform biedt verificatiemechanismen voor het verifiëren van de identiteit van de persoon of service die toegang heeft tot een resource. Pas de aanbevolen procedures toe die hieronder worden beschreven om expliciet te verifiëren welke entiteiten toegang nodig hebben tot gegevens of resources.

Best practice Voordelen van toepassingsbeveiliging
Gebruik de Microsoft Authentication Libraries (MSAL). MSAL is een set Microsoft-verificatiebibliotheken voor ontwikkelaars. Met MSAL kunnen gebruikers en toepassingen worden geverifieerd en kunnen tokens worden verkregen voor toegang tot bedrijfsresources met slechts een paar regels code. MSAL maakt gebruik van moderne protocollen (OpenID Connect en OAuth 2.0) die ervoor zorgen dat toepassingen de referenties van een gebruiker nooit rechtstreeks kunnen verwerken. Deze verwerking van referenties verbetert de beveiliging voor zowel gebruikers als toepassingen aanzienlijk, omdat de id-provider de beveiligingsperimeter wordt. Deze protocollen ontwikkelen zich voortdurend om nieuwe paradigma's, kansen en uitdagingen in identiteitsbeveiliging aan te pakken.
Gebruik zo nodig verbeterde beveiligingsuitbreidingen, zoals CAE (Continuous Access Evaluation) en voorwaardelijke toegangsverificatiecontext. In Microsoft Entra ID zijn enkele van de meest gebruikte extensies voorwaardelijke toegang, verificatiecontext voor voorwaardelijke toegang en CAE. Toepassingen die gebruikmaken van verbeterde beveiligingsfuncties, zoals CAE en de context voor verificatie voor voorwaardelijke toegang, moeten worden gecodeerd om problemen met claims af te handelen. Met open protocollen kunnen de claimsuitdagingen en claimsaanvragen worden gebruikt om extra clientmogelijkheden aan te roepen. De mogelijkheden zijn mogelijk om de interactie met Microsoft Entra-id voort te zetten, zoals wanneer er een anomalie was of als de voorwaarden voor gebruikersverificatie veranderen. Deze extensies kunnen in een toepassing worden gecodeerd zonder de primaire codestromen voor verificatie te storen.
Gebruik de juiste verificatiestroom per toepassingstype. Probeer voor webtoepassingen altijd vertrouwelijke clientstromen te gebruiken. Probeer voor mobiele toepassingen brokers of de systeembrowser te gebruiken voor verificatie. De stromen voor webtoepassingen die een geheim (vertrouwelijke clients) kunnen bevatten, worden beschouwd als veiliger dan openbare clients (bijvoorbeeld: Desktop- en Console-toepassingen). Wanneer de webbrowser van het systeem wordt gebruikt om een mobiele toepassing te verifiëren, maakt een veilige SSO-ervaring (eenmalige aanmelding) het gebruik van toepassingsbeveiligingsbeleid mogelijk.

Toegang met minimale bevoegdheden gebruiken

Een ontwikkelaar gebruikt het Microsoft Identity Platform om machtigingen (bereiken) te verlenen en te controleren of aan een beller de juiste machtiging is verleend voordat toegang wordt verleend. Dwing toegang met minimale bevoegdheden in toepassingen af door fijnmazige machtigingen in te schakelen waarmee de kleinste hoeveelheid toegang kan worden verleend. Houd rekening met de volgende procedures om ervoor te zorgen dat u zich houdt aan het principe van minimale bevoegdheden:

  • Evalueer de machtigingen die worden aangevraagd om ervoor te zorgen dat de absolute minimale bevoegdheden zijn ingesteld om de taak uit te voeren. Maak geen 'catch-all'-machtigingen met toegang tot het volledige API-oppervlak.
  • Bij het ontwerpen van API's geeft u gedetailleerde machtigingen op om toegang met minimale bevoegdheden toe te staan. Begin met het verdelen van de functionaliteit en gegevenstoegang in secties die kunnen worden beheerd met behulp van bereiken en app-rollen. Voeg geen API's toe aan bestaande machtigingen op een manier die de semantiek van de machtiging wijzigt.
  • Alleen-lezenmachtigingen bieden. Write toegang, bevat bevoegdheden voor bewerkingen voor maken, bijwerken en verwijderen. Een client mag nooit schrijftoegang vereisen voor alleen leesgegevens.
  • Bied zowel gedelegeerde machtigingen als toepassingsmachtigingen aan. Het overslaan van toepassingsmachtigingen kan een harde vereiste maken voor clients om algemene scenario's te bereiken, zoals automatisering, microservices en meer.
  • Overweeg 'standaard' en 'volledige' toegangsmachtigingen als u met gevoelige gegevens werkt. Beperk de gevoelige eigenschappen zodat ze niet kunnen worden geopend met een standaardtoegangsmachtiging, bijvoorbeeld Resource.Read. En implementeer vervolgens een machtiging voor volledige toegang, bijvoorbeeld Resource.ReadFull die alle beschikbare eigenschappen, inclusief gevoelige informatie, retourneert.

Stel dat er sprake is van een schending

De registratieportal van de Microsoft Identity Platform-toepassing is het primaire toegangspunt voor toepassingen die het platform willen gebruiken voor hun verificatie en bijbehorende behoeften. Wanneer u toepassingen registreert en configureert, volgt u de procedures die hieronder worden beschreven om de schade die ze kunnen veroorzaken, te minimaliseren als er sprake is van een beveiligingsschending. Zie de best practices voor beveiliging van microsoft Entra-toepassingsregistratie voor meer informatie.

Houd rekening met de volgende acties om schendingen in de beveiliging te voorkomen:

  • Definieer de omleidings-URI's voor de toepassing op de juiste manier. Gebruik niet dezelfde toepassingsregistratie voor meerdere toepassingen.
  • Controleer omleidings-URI's die worden gebruikt in de registratie van de toepassing voor eigendom en om overname van domeinen te voorkomen. Maak de toepassing niet als een multitenant, tenzij deze bedoeld is. |
  • Zorg ervoor dat eigenaren van toepassingen en service-principals altijd zijn gedefinieerd en onderhouden voor de toepassingen die zijn geregistreerd in de tenant.

Zie ook