Openbare en vertrouwelijke clienttoepassingen

Artikel
11/23/2023

De Microsoft Authentication Library (MSAL) definieert twee typen clients; openbare clients en vertrouwelijke clients. Een client is een software-entiteit met een unieke id die is toegewezen door een id-provider. De clienttypen worden onderscheiden door hun mogelijkheid om veilig te verifiëren met de autorisatieserver en om gevoelige identiteitsgegevens te bewaren, zodat deze niet kunnen worden geopend of bekend zijn bij een gebruiker binnen het bereik van de toegang.

Openbare client-apps	Vertrouwelijke client-apps
Bureaublad-app	Web-app
Browserloze API	Web-API
Mobiele app	Service/daemon

Openbare client en vertrouwelijke clientautorisatie

Bij het onderzoeken van de openbare of vertrouwelijke aard van een bepaalde client evalueren we de mogelijkheid van die client om zijn identiteit aan de autorisatieserver te bewijzen. Dit is belangrijk omdat de autorisatieserver de identiteit van de client moet kunnen vertrouwen om toegangstokens uit te geven.

Openbare clienttoepassingen worden uitgevoerd op apparaten, zoals desktop, browserloze API's, mobiele of browser-apps aan de clientzijde. Ze kunnen niet worden vertrouwd om toepassingsgeheimen veilig te bewaren, omdat ze alleen namens de gebruiker toegang hebben tot web-API's. Wanneer de bron of gecompileerde bytecode van een bepaalde app overal wordt verzonden, kan deze worden gelezen, gedemonteerd of anderszins worden geïnspecteerd door niet-vertrouwde partijen, is het een openbare client. Omdat ze ook alleen openbare clientstromen ondersteunen en geen configuratietijdgeheimen kunnen bevatten, kunnen ze geen clientgeheimen hebben.
Vertrouwelijke clienttoepassingen worden uitgevoerd op servers, zoals web-apps, web-API-apps of service-/daemon-apps. Ze worden beschouwd als moeilijk toegankelijk voor gebruikers of aanvallers en kunnen daarom voldoende configuratietijdgeheimen bevatten om het bewijs van de identiteit te bevestigen. De client-id wordt weergegeven via de webbrowser, maar het geheim wordt alleen doorgegeven in het Upstream-kanaal en wordt nooit rechtstreeks weergegeven.

Geheimen en hun belang bij het bewijzen van identiteit

Hier volgen enkele voorbeelden van hoe een client de identiteit kan bewijzen aan de autorisatieserver:

Beheerde identiteiten voor Azure-resources : voor app-only-verificatiescenario's hebben toepassings- en serviceontwikkelaars die bouwen op Azure de mogelijkheid om geheimbeheer, rotatie en beveiliging naar het platform zelf te offloaden. Met beheerde identiteiten worden identiteiten verstrekt en verwijderd met Azure-resources en heeft niemand, waaronder de Global Beheer istrator, toegang tot de onderliggende referenties. Door beheerde identiteiten te gebruiken, kunt u het risico van het lekken van geheimen voorkomen en de provider de beveiliging voor u laten afhandelen.
Client-id en geheim : in dit patroon wordt een paar waarden gegenereerd door de autorisatieserver bij het registreren van een client. De client-id is een openbare waarde die de toepassing identificeert, terwijl het clientgeheim een vertrouwelijke waarde is die wordt gebruikt om de identiteit van de toepassing te bewijzen.
Het bewijzen van het bezit van een certificaat – Public Key Infrastructure (PKI), dat standaarden zoals X.509 omvat, is de fundamentele technologie die veilige communicatie via internet mogelijk maakt en de backbone van internetprivacy vormt. PKI wordt gebruikt om digitale certificaten uit te geven die de identiteit verifiëren van partijen die betrokken zijn bij onlinecommunicatie en de onderliggende technologie is die protocollen zoals HTTPS aangeeft, die veel wordt gebruikt om webverkeer te beveiligen. Certificaten kunnen ook worden gebruikt om S2S-communicatie (service-to-service) in Azure te beveiligen door wederzijdse verificatie tussen de services mogelijk te maken. Dit omvat elke service die een certificaat aan de andere service presenteert als een middel om zijn identiteit te bewijzen.
Presentatie van een ondertekende assertie : gebruikt in de federatie van workloadidentiteit, ondertekende asserties maken het mogelijk om een token van een vertrouwde id-provider van derden uit te wisselen met het Microsoft Identity Platform om toegangstokens te verkrijgen om beveiligde Microsoft Entra-resources aan te roepen. Federatie van workloadidentiteit kan worden gebruikt om verschillende federatiescenario's mogelijk te maken, waaronder Azure Kubernetes Service, Amazon Web Services EKS, GitHub Actions en meer.

Wanneer is het bewijs van clientidentiteit belangrijk?

Het bewijzen van clientidentiteit is belangrijk wanneer er zowel de echtheid als de autorisatie van een clienttoepassing moet worden gecontroleerd voordat toegang wordt verleend tot gevoelige gegevens of resources. Enkele voorbeelden:

API-toegang beheren: als u een API hebt die wordt gemeten (bijvoorbeeld voor facturering) of gevoelige gegevens of resources beschikbaar maakt, controleert u de identiteit van de client voordat u toegang verleent. Dit is bijvoorbeeld belangrijk wanneer u ervoor zorgt dat alleen geautoriseerde toepassingen toegang hebben tot de API en dat de juiste klant wordt gefactureerd voor het gebruik van de API naar gebruik met datalimiet.
Gebruikers beschermen tegen app-imitatie : als u een door de service geïmplementeerde, gebruikersgerichte toepassing (bijvoorbeeld een back-endgestuurde web-app) hebt die toegang heeft tot gevoelige gegevens of services, gebruikt u clientgeheimen om de resources te beveiligen die door die toepassing worden gebruikt, mogelijk voorkomt u dat slechte actoren een legitieme client imiteren voor phish-gebruikers en toegang tot gegevens of misbruiken.
S2S-communicatie : als u meerdere back-endservices (bijvoorbeeld downstream-API's) hebt die met elkaar moeten communiceren, kunt u de identiteit van elke service verifiëren om ervoor te zorgen dat ze gemachtigd zijn om alleen toegang te krijgen tot de benodigde resources om hun functie uit te voeren.

Over het algemeen is het bewijzen van clientidentiteit belangrijk wanneer er een noodzaak is om een client onafhankelijk van of naast een gebruiker te verifiëren en autoriseren.

Vertrouwelijke clients: aanbevolen procedures voor het beheren van geheimen

Beheerde identiteiten gebruiken om de implementatie en beveiliging te vereenvoudigen: beheerde identiteiten bieden een automatisch beheerde identiteit in Microsoft Entra-id voor toepassingen die kunnen worden gebruikt bij het maken van verbinding met resources die ondersteuning bieden voor Microsoft Entra-verificatie. Toepassingen kunnen beheerde identiteiten gebruiken om app-tokens van Microsoft Entra ID te verkrijgen zonder referenties te hoeven beheren. Dit kan veel van de complexiteit van geheimbeheer verwijderen, terwijl uw beveiliging en tolerantie worden verhoogd. Als u beheerde identiteiten gebruikt, worden de meeste aanbevolen procedures al voor u geregeld.

Veilige opslag gebruiken: bewaar clientgeheimen op een veilige locatie, zoals Key Vault of een versleuteld configuratiebestand. Vermijd het opslaan van clientgeheimen in tekst zonder opmaak of als ingecheckte bestanden naar versiebeheersystemen.

Toegang beperken : beperk de toegang tot clientgeheimen tot alleen geautoriseerd personeel. Gebruik op rollen gebaseerd toegangsbeheer om de toegang tot clientgeheimen te beperken tot alleen degenen die deze nodig hebben om hun operationele taken uit te voeren.

Clientgeheimen draaien: het roteren van clientgeheimen op basis van behoefte of gepland, kan het risico minimaliseren dat een gecompromitteerd geheim wordt gebruikt om onbevoegde toegang te krijgen. Wanneer dit wordt toegepast, wordt de tijdsduur waarin een sleutel wordt voorgesteld om in gebruik te blijven, beïnvloed door de sterkte van het cryptografische algoritme dat wordt gebruikt en/of de naleving van standaarden of wettelijke nalevingsprocedures.

Gebruik lange geheimen en sterke versleuteling : nauw verwant aan het vorige punt, met behulp van sterke versleutelingsalgoritmen voor gegevens die zowel in transit (op de kabel) als at-rest (op schijf) worden gebruikt, zorgt ervoor dat geheimen met hoge entropie waarschijnlijk niet brute-forceren blijven. Algoritmen zoals AES-128 (of hoger) kunnen helpen bij het beveiligen van data-at-rest, terwijl RSA-2048 (of hoger) kan helpen bij het efficiënt beveiligen van gegevens tijdens overdracht. Vanwege de steeds veranderende aard van cyberbeveiliging is het altijd raadzaam om uw beveiligingsexperts te raadplegen en periodiek uw algoritmeselectie te controleren.

Vermijd het coderen van geheimen : codeer geen clientgeheimen in broncode. Het vermijden van geheimen in broncode kan de waarde minimaliseren van slechte actoren die toegang krijgen tot uw broncode. Het kan ook voorkomen dat dergelijke geheimen per ongeluk worden gepusht naar onveilige opslagplaatsen of beschikbaar worden gesteld aan projectbijdragers die brontoegang hebben, maar geen geheime toegang.

Opslagplaatsen bewaken voor gelekte geheimen : het is een jammer feit dat er slechte check-ins plaatsvinden bij het omgaan met broncode. Git-hooks vooraf doorvoeren zijn een voorgestelde manier om onbedoelde check-ins te voorkomen, maar is ook geen vervanging voor bewaking. Geautomatiseerde bewaking van opslagplaatsen kan gelekte geheimen identificeren en, met een plan om gecompromitteerde referenties te roteren, kunnen beveiligingsincidenten worden verminderd.

Controleren op verdachte activiteiten : bewaak logboeken en audittrails voor verdachte activiteiten met betrekking tot clientgeheimen. Gebruik waar mogelijk geautomatiseerde waarschuwingen en reactieprocessen om personeel op de hoogte te stellen en onvoorziene gebeurtenissen te definiëren voor ongebruikelijke activiteiten met betrekking tot clientgeheimen.

Ontwerp uw toepassingen met clientgeheim in het achterhoofd : uw beveiligingsmodel is slechts zo sterk als de zwakste koppeling in de keten. Stuur geen beveiligingsreferenties of tokens door van vertrouwelijke naar openbare clients, omdat hiermee clientgeheimgegevens naar een openbare client kunnen worden verplaatst, waardoor imitatie van de vertrouwelijke client mogelijk is.

Gebruik actuele bibliotheken en SDK's van vertrouwde bronnen . Het Microsoft Identity Platform biedt verschillende client- en server-SDK's en middleware die zijn ontworpen om uw productiviteit te verbeteren en uw toepassingen veilig te houden. Bibliotheken zoals Microsoft.Identity.Web vereenvoudigen het toevoegen van verificatie en autorisatie aan web-apps en API's op het Microsoft Identity Platform. Door afhankelijkheden bijgewerkt te houden, zorgt u ervoor dat uw toepassingen en services profiteren van de nieuwste beveiligingsinnovaties en -updates.

De clienttypen en hun mogelijkheden vergelijken

Hier volgen enkele overeenkomsten en verschillen tussen openbare en vertrouwelijke client-apps:

Beide app-typen onderhouden een gebruikerstokencache en kunnen op de achtergrond een token verkrijgen (wanneer het token aanwezig is in de cache). Vertrouwelijke client-apps hebben ook een app-tokencache voor tokens die door de app zelf zijn verkregen.
Beide app-typen kunnen gebruikersaccounts beheren en een account ophalen uit de cache van het gebruikerstoken, een account ophalen uit de id of een account verwijderen.
In MSAL hebben openbare client-apps vier manieren om een token te verkrijgen via afzonderlijke verificatiestromen. Vertrouwelijke client-apps hebben slechts drie manieren om een token te verkrijgen en één manier om de URL van de id-provider te berekenen die het eindpunt autoriseren. De client-id wordt eenmaal doorgegeven tijdens de bouw van de toepassing en hoeft niet opnieuw te worden doorgegeven wanneer de app een token verkrijgt. Zie Tokens verkrijgen voor meer informatie.

Openbare clients zijn handig voor het inschakelen van door de gebruiker gedelegeerde toegang tot beveiligde resources, maar kunnen hun eigen toepassingsidentiteit niet bewijzen. Vertrouwelijke clients kunnen daarentegen zowel gebruikers- als toepassingsverificatie en -autorisatie uitvoeren en moeten worden gebouwd met beveiliging in het achterhoofd om ervoor te zorgen dat hun geheimen niet worden gedeeld met openbare clients of andere derden.

In sommige gevallen, zoals S2S-communicatie, helpt infrastructuur zoals beheerde identiteiten aanzienlijk om de ontwikkeling en implementatie van services te vereenvoudigen en wordt veel van de complexiteit verwijderd die doorgaans samenhangt met geheimbeheer. Wanneer beheerde identiteiten niet kunnen worden gebruikt, is het belangrijk dat er beleid, preventieve maatregelen en onvoorziene gebeurtenissen zijn ingesteld voor het beveiligen van geheimen en het reageren op beveiligingsincidenten met betrekking tot deze identiteiten.

Zie ook

Zie voor meer informatie over toepassingsconfiguratie en het maken van instanties: