Beveiligingsframe: Verificatie | Oplossingen

Product/service	Artikel
Webtoepassing	Overweeg om een standaardverificatiemechanisme te gebruiken om te verifiëren bij webtoepassing Toepassingen moeten veilig omgaan met mislukte verificatiescenario's Stapsgewijze of adaptieve verificatie inschakelen Zorg ervoor dat beheerinterfaces op de juiste wijze zijn vergrendeld Wachtwoordfunctionaliteiten veilig implementeren Zorg ervoor dat wachtwoord- en accountbeleid zijn geïmplementeerd Besturingselementen implementeren om opsomming van gebruikersnaam te voorkomen
Database	Gebruik waar mogelijk Windows-verificatie om verbinding te maken met SQL Server Gebruik, indien mogelijk, Microsoft Entra-verificatie om verbinding te maken met SQL Database Wanneer de SQL-verificatiemodus wordt gebruikt, moet u ervoor zorgen dat account- en wachtwoordbeleid wordt afgedwongen op SQL Server Gebruik geen SQL-verificatie in ingesloten databases
Azure Event Hub	Referenties voor verificatie per apparaat gebruiken met behulp van SaS-tokens
Grens van Azure Trust	Meervoudige verificatie van Microsoft Entra inschakelen voor Azure-beheerders
Grens van Service Fabric-vertrouwensrelatie	Anonieme toegang tot Service Fabric-cluster beperken Zorg ervoor dat het Service Fabric-certificaat voor client-naar-knooppunt verschilt van het knooppunt-naar-knooppuntcertificaat Microsoft Entra-id gebruiken om clients te verifiëren bij service fabric-clusters Zorg ervoor dat service fabric-certificaten worden verkregen van een goedgekeurde certificeringsinstantie (CA)
Identity Server	Standaardverificatiescenario's gebruiken die worden ondersteund door Identity Server De standaard-Identity Server-tokencache overschrijven met een schaalbaar alternatief
Grens van machinevertrouwen	Zorg ervoor dat de binaire bestanden van de geïmplementeerde toepassing digitaal zijn ondertekend
WCF	Verificatie inschakelen bij het maken van verbinding met MSMQ-wachtrijen in WCF WCF-Do not set Message clientCredentialType to none WCF-Do not set Transport clientCredentialType op geen
Web-API	Zorg ervoor dat standaardverificatietechnieken worden gebruikt om web-API's te beveiligen
Microsoft Entra ID	Standaardverificatiescenario's gebruiken die worden ondersteund door Microsoft Entra ID De standaard-MSAL-tokencache overschrijven met een gedistribueerde cache Zorg ervoor dat TokenReplayCache wordt gebruikt om te voorkomen dat binnenkomende verificatietokens opnieuw worden afgespeeld MSAL-bibliotheken gebruiken om tokenaanvragen van OAuth2-clients te beheren naar Microsoft Entra-id (of on-premises AD)
IoT-veldgateway	Apparaten verifiëren die verbinding maken met de veldgateway
IoT Cloud Gateway	Controleren of apparaten die verbinding maken met cloudgateway, zijn geverifieerd Verificatiereferenties per apparaat gebruiken
Azure Storage	Zorg ervoor dat alleen de vereiste containers en blobs anonieme leestoegang krijgen Beperkte toegang verlenen tot objecten in Azure Storage met behulp van SAS of SAP

Overweeg om een standaardverificatiemechanisme te gebruiken om te verifiëren bij webtoepassing

Titel	DETAILS
Onderdeel	Webtoepassing
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	N.v.t.
Details	Verificatie is het proces waarbij een entiteit zijn identiteit bewijst, meestal via referenties, zoals een gebruikersnaam en wachtwoord. Er zijn meerdere verificatieprotocollen beschikbaar die kunnen worden overwogen. Sommige hiervan worden hieronder weergegeven: Clientcertificaten Op basis van Windows Op formulieren gebaseerd Federatie - ADFS Federatie - Microsoft Entra-id Federatie - Identiteitsserver Overweeg een standaardverificatiemechanisme te gebruiken om het bronproces te identificeren

Toepassingen moeten veilig omgaan met mislukte verificatiescenario's

Titel	DETAILS
Onderdeel	Webtoepassing
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	N.v.t.
Details	Toepassingen die gebruikers expliciet verifiëren, moeten mislukte verificatiescenario's veilig afhandelen. Het verificatiemechanisme moet: Toegang tot bevoegde resources weigeren wanneer verificatie mislukt Een algemeen foutbericht weergeven na mislukte verificatie en geweigerde toegang Testen op: Beveiliging van bevoegde resources na mislukte aanmeldingen Er wordt een algemeen foutbericht weergegeven bij mislukte verificatie en toegang geweigerde gebeurtenissen Accounts worden uitgeschakeld na een overmatig aantal mislukte pogingen

Stapsgewijze of adaptieve verificatie inschakelen

Titel	DETAILS
Onderdeel	Webtoepassing
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	N.v.t.
Details	Controleer of de toepassing aanvullende autorisatie heeft (zoals stap-omhoog of adaptieve verificatie, via meervoudige verificatie, zoals het verzenden van OTP in sms, e-mail, enzovoort) zodat de gebruiker wordt gevraagd om toegang te krijgen tot gevoelige informatie. Deze regel is ook van toepassing op het aanbrengen van kritieke wijzigingen in een account of actie Dit betekent ook dat de aanpassing van verificatie op een zodanige manier moet worden geïmplementeerd dat de toepassing contextgevoelige autorisatie correct afdwingt om niet-geautoriseerde manipulatie toe te staan door middel van bijvoorbeeld parametervervalsing

Zorg ervoor dat beheerinterfaces op de juiste wijze zijn vergrendeld

Titel	DETAILS
Onderdeel	Webtoepassing
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	N.v.t.
Details	De eerste oplossing is om alleen toegang te verlenen vanuit een bepaald bron-IP-bereik aan de beheerinterface. Als deze oplossing niet mogelijk zou zijn, wordt het altijd aanbevolen om een stapsgewijze of adaptieve verificatie af te dwingen voor het aanmelden bij de beheerinterface

Wachtwoordfunctionaliteiten veilig implementeren

Titel	DETAILS
Onderdeel	Webtoepassing
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	N.v.t.
Details	Het eerste is om te controleren of vergeten wachtwoord en andere herstelpaden een koppeling verzenden, inclusief een activeringstoken met een tijdslimiet in plaats van het wachtwoord zelf. Aanvullende verificatie op basis van soft-tokens (bijvoorbeeld sms-token, systeemeigen mobiele toepassingen, enzovoort) kan ook vereist zijn voordat de koppeling wordt verzonden. Ten tweede moet u het gebruikersaccount niet vergrendelen terwijl het proces voor het ophalen van een nieuw wachtwoord wordt uitgevoerd. Dit kan leiden tot een Denial of Service-aanval wanneer een aanvaller besluit de gebruikers opzettelijk te vergrendelen met een geautomatiseerde aanval. Ten derde, wanneer de nieuwe wachtwoordaanvraag wordt uitgevoerd, moet het bericht dat u weergeeft, worden gegeneraliseerd om opsomming van gebruikersnaam te voorkomen. Ten vierde: het gebruik van oude wachtwoorden altijd weigeren en een sterk wachtwoordbeleid implementeren.

Zorg ervoor dat wachtwoord- en accountbeleid zijn geïmplementeerd

Titel	DETAILS
Onderdeel	Webtoepassing
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	N.v.t.
Details	Wachtwoord- en accountbeleid in overeenstemming met organisatiebeleid en best practices moeten worden geïmplementeerd. Ter bescherming tegen brute-force en woordenlijstgebaseerd raden: sterk wachtwoordbeleid moet worden geïmplementeerd om ervoor te zorgen dat gebruikers een complex wachtwoord maken (bijvoorbeeld minimaal 12 tekens, alfanumerieke en speciale tekens). Accountvergrendelingsbeleid kan op de volgende manier worden geïmplementeerd: Zachte vergrendeling: dit kan een goede optie zijn om uw gebruikers te beschermen tegen beveiligingsaanvallen. Wanneer de gebruiker bijvoorbeeld drie keer een verkeerd wachtwoord invoert, kan de toepassing het account een minuut vergrendelen om het proces van brute forcering van het wachtwoord te vertragen, waardoor het minder winstgevend is voor de aanvaller om door te gaan. Als u hard lock-out tegenmaatregelen voor dit voorbeeld zou implementeren, zou u een DoS bereiken door accounts permanent te vergrendelen. De toepassing kan ook een OTP (eenmalig wachtwoord) genereren en deze out-of-band verzenden (via e-mail, sms enzovoort) naar de gebruiker. Een andere methode is het implementeren van CAPTCHA nadat een drempelwaarde voor mislukte pogingen is bereikt. Vaste vergrendeling: dit type vergrendeling moet worden toegepast wanneer u een gebruiker detecteert die uw toepassing aanvalt en deze tegenwerkt door hun account permanent te vergrendelen totdat een reactieteam tijd had om hun forensische gegevens uit te voeren. Na dit proces kunt u besluiten om de gebruiker zijn of haar account terug te geven of verdere juridische acties tegen hen uit te voeren. Met dit type aanpak voorkomt u dat de aanvaller uw toepassing en infrastructuur verder indringt. Als u zich wilt beschermen tegen aanvallen op standaard- en voorspelbare accounts, controleert u of alle sleutels en wachtwoorden kunnen worden vervangen en worden gegenereerd of vervangen na de installatietijd. Als de toepassing wachtwoorden automatisch moet genereren, moet u ervoor zorgen dat de gegenereerde wachtwoorden willekeurig zijn en hoge entropie hebben.

Besturingselementen implementeren om opsomming van gebruikersnaam te voorkomen

Titel	DETAILS
Onderdeel	Webtoepassing
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	N.v.t.
Stappen	Alle foutberichten moeten worden gegeneraliseerd om opsomming van gebruikersnaam te voorkomen. Soms kunt u ook geen informatielekken voorkomen in functies zoals een registratiepagina. Hier moet u methoden voor snelheidsbeperking gebruiken, zoals CAPTCHA, om een geautomatiseerde aanval door een aanvaller te voorkomen.

Gebruik waar mogelijk Windows-verificatie om verbinding te maken met SQL Server

Titel	DETAILS
Onderdeel	Database
SDL-fase	Build
Toepasselijke technologieën	On-premises
Kenmerken	SQL-versie - alle
Naslaginformatie	SQL Server : een verificatiemodus kiezen
Stappen	Windows-verificatie maakt gebruik van kerberos-beveiligingsprotocol, biedt afdwinging van wachtwoordbeleid met betrekking tot complexiteitsvalidatie voor sterke wachtwoorden, biedt ondersteuning voor accountvergrendeling en ondersteunt het verlopen van wachtwoorden.

Gebruik, indien mogelijk, Microsoft Entra-verificatie om verbinding te maken met SQL Database

Titel	DETAILS
Onderdeel	Database
SDL-fase	Build
Toepasselijke technologieën	SQL Azure
Kenmerken	SQL-versie - V12
Naslaginformatie	Verbinding maken met SQL Database met behulp van Microsoft Entra-verificatie
Stappen	Minimale versie: Azure SQL Database V12 vereist om Azure SQL Database toe te staan Microsoft Entra-verificatie te gebruiken voor de Microsoft Directory

Wanneer de SQL-verificatiemodus wordt gebruikt, moet u ervoor zorgen dat account- en wachtwoordbeleid wordt afgedwongen op SQL Server

Titel	DETAILS
Onderdeel	Database
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	Wachtwoordbeleid voor SQL Server
Stappen	Wanneer u SQL Server-verificatie gebruikt, worden aanmeldingen gemaakt in SQL Server die niet zijn gebaseerd op Windows-gebruikersaccounts. Zowel de gebruikersnaam als het wachtwoord worden gemaakt met behulp van SQL Server en opgeslagen in SQL Server. SQL Server kan Windows-wachtwoordbeleidsmechanismen gebruiken. Het kan dezelfde complexiteit en verloopbeleid toepassen dat in Windows wordt gebruikt op wachtwoorden die in SQL Server worden gebruikt.

SQL-verificatie in ingesloten databases niet gebruiken

Titel	DETAILS
Onderdeel	Database
SDL-fase	Build
Toepasselijke technologieën	On-premises, SQL Azure
Kenmerken	SQL-versie - MSSQL2012, SQL-versie - V12
Naslaginformatie	Aanbevolen beveiligingsprocedures met ingesloten databases
Stappen	Het ontbreken van een afgedwongen wachtwoordbeleid kan de kans vergroten dat een zwakke referentie wordt ingesteld in een ingesloten database. Maak gebruik van Windows-verificatie.

Referenties voor verificatie per apparaat gebruiken met behulp van SaS-tokens

Titel	DETAILS
Onderdeel	Azure Event Hubs
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	Overzicht van Event Hubs-verificatie en -beveiligingsmodel
Stappen	Het Event Hubs-beveiligingsmodel is gebaseerd op een combinatie van SAS-tokens (Shared Access Signature) en gebeurtenisuitgevers. De naam van de uitgever vertegenwoordigt de DeviceID die het token ontvangt. Dit helpt bij het koppelen van de tokens die zijn gegenereerd aan de respectieve apparaten. Alle berichten worden gelabeld met originator aan de servicezijde, zodat spoofingpoofingpoofingspogingen in de nettolading kunnen worden gedetecteerd. Bij het verifiëren van apparaten genereert u een SaS-token per apparaat dat is afgestemd op een unieke uitgever.

Meervoudige verificatie van Microsoft Entra inschakelen voor Azure-beheerders

Titel	DETAILS
Onderdeel	Grens van Azure Trust
SDL-fase	Implementatie
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	Wat is Meervoudige Verificatie van Microsoft Entra?
Stappen	meervoudige verificatie (MFA) is een verificatiemethode die meer dan één verificatiemethode vereist en een kritieke tweede beveiligingslaag toevoegt aan aanmeldingen en transacties van gebruikers. Het werkt door twee of meer van de volgende verificatiemethoden te vereisen: Iets wat u weet (meestal een wachtwoord) Iets dat u hebt (een vertrouwd apparaat dat niet eenvoudig kan worden gedupliceerd, zoals een telefoon) Iets wat u bent (biometrie)

Anonieme toegang tot Service Fabric-cluster beperken

Titel	DETAILS
Onderdeel	Grens van Service Fabric-vertrouwensrelatie
SDL-fase	Implementatie
Toepasselijke technologieën	Algemeen
Kenmerken	Omgeving - Azure
Naslaginformatie	Beveiligingsscenario's voor Service Fabric-clusters
Stappen	Clusters moeten altijd worden beveiligd om te voorkomen dat onbevoegde gebruikers verbinding maken met uw cluster, met name wanneer er productieworkloads op het cluster worden uitgevoerd. Zorg er tijdens het maken van een Service Fabric-cluster voor dat de beveiligingsmodus is ingesteld op 'veilig' en configureer het vereiste X.509-servercertificaat. Als u een 'onveilig' cluster maakt, kan elke anonieme gebruiker er verbinding mee maken als het beheereindpunten beschikbaar maakt op het openbare internet.

Zorg ervoor dat het Service Fabric-certificaat voor client-naar-knooppunt verschilt van het knooppunt-naar-knooppuntcertificaat

Titel	DETAILS
Onderdeel	Grens van Service Fabric-vertrouwensrelatie
SDL-fase	Implementatie
Toepasselijke technologieën	Algemeen
Kenmerken	Omgeving - Azure, Omgeving - Zelfstandig
Naslaginformatie	Service Fabric-client-naar-knooppunt-certificaatbeveiliging, verbinding maken met een beveiligd cluster met behulp van clientcertificaat
Stappen	Beveiliging van client-naar-knooppuntcertificaten wordt geconfigureerd tijdens het maken van het cluster via Azure Portal, Resource Manager-sjablonen of een zelfstandige JSON-sjabloon door een clientcertificaat en/of een gebruikersclientcertificaat op te geven. De door u opgegeven beheerdersclient- en gebruikersclientcertificaten moeten afwijken van de primaire en secundaire certificaten die u opgeeft voor beveiliging van knooppunten naar knooppunt.

Microsoft Entra-id gebruiken om clients te verifiëren bij service fabric-clusters

Titel	DETAILS
Onderdeel	Grens van Service Fabric-vertrouwensrelatie
SDL-fase	Implementatie
Toepasselijke technologieën	Algemeen
Kenmerken	Omgeving - Azure
Naslaginformatie	Clusterbeveiligingsscenario's - Beveiligingsaanbeveling
Stappen	Clusters die worden uitgevoerd in Azure, kunnen ook de toegang tot de beheereindpunten beveiligen met behulp van Microsoft Entra-id, behalve clientcertificaten. Voor Azure-clusters wordt u aangeraden Microsoft Entra-beveiliging te gebruiken om clients en certificaten te verifiëren voor knooppunt-naar-knooppuntbeveiliging.

Zorg ervoor dat service fabric-certificaten worden verkregen van een goedgekeurde certificeringsinstantie (CA)

Titel	DETAILS
Onderdeel	Grens van Service Fabric-vertrouwensrelatie
SDL-fase	Implementatie
Toepasselijke technologieën	Algemeen
Kenmerken	Omgeving - Azure
Naslaginformatie	X.509-certificaten en Service Fabric
Stappen	Service Fabric maakt gebruik van X.509-servercertificaten voor het verifiëren van knooppunten en clients. Enkele belangrijke aandachtspunten bij het gebruik van certificaten in Service Fabrics: Certificaten die worden gebruikt in clusters waarop productieworkloads worden uitgevoerd, moeten worden gemaakt met behulp van een correct geconfigureerde Windows Server-certificaatservice of verkregen van een goedgekeurde certificeringsinstantie (CA). De CA kan een goedgekeurde externe CA of een goed beheerde interne PKI (Public Key Infrastructure) zijn Gebruik nooit tijdelijke certificaten of testcertificaten in productie die zijn gemaakt met hulpprogramma's zoals MakeCert.exe U kunt een zelfondertekend certificaat gebruiken, maar dit alleen doen voor testclusters en niet in productie

Standaardverificatiescenario's gebruiken die worden ondersteund door Identity Server

Titel	DETAILS
Onderdeel	Identity Server
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	IdentityServer3 - Het grote beeld
Stappen	Hieronder ziet u de typische interacties die worden ondersteund door Identity Server: Browsers communiceren met webtoepassingen Webtoepassingen communiceren met web-API's (soms zelf, soms namens een gebruiker) Browsertoepassingen communiceren met web-API's Systeemeigen toepassingen communiceren met web-API's Servertoepassingen communiceren met web-API's Web-API's communiceren met web-API's (soms zelf, soms namens een gebruiker)

De standaard-Identity Server-tokencache overschrijven met een schaalbaar alternatief

Titel	DETAILS
Onderdeel	Identity Server
SDL-fase	Implementatie
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	Identiteitsserverimplementatie - Caching
Stappen	IdentityServer heeft een eenvoudige ingebouwde cache in het geheugen. Hoewel dit geschikt is voor kleinschalige systeemeigen apps, wordt het om de volgende redenen niet geschaald voor middelgrote en back-endtoepassingen: Deze toepassingen worden door veel gebruikers tegelijk geopend. Als u alle toegangstokens in hetzelfde archief opslaat, ontstaan isolatieproblemen en worden er uitdagingen weergegeven wanneer ze op schaal werken: veel gebruikers, elk met zoveel tokens als de resources die de app namens hen opent, kunnen enorme aantallen en zeer dure opzoekbewerkingen betekenen Deze toepassingen worden doorgaans geïmplementeerd op gedistribueerde topologieën, waarbij meerdere knooppunten toegang moeten hebben tot dezelfde cache Tokens in de cache moeten het proces recyclen en deactiveren overleven Voor alle bovenstaande redenen, bij het implementeren van web-apps, is het raadzaam om de tokencache van de standaardidentiteitsserver te overschrijven met een schaalbaar alternatief, zoals Azure Cache voor Redis

Zorg ervoor dat de binaire bestanden van de geïmplementeerde toepassing digitaal zijn ondertekend

Titel	DETAILS
Onderdeel	Grens van machinevertrouwen
SDL-fase	Implementatie
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	N.v.t.
Stappen	Zorg ervoor dat de binaire bestanden van de geïmplementeerde toepassing digitaal zijn ondertekend, zodat de integriteit van de binaire bestanden kan worden geverifieerd

Verificatie inschakelen bij het maken van verbinding met MSMQ-wachtrijen in WCF

Titel	DETAILS
Onderdeel	WCF
SDL-fase	Build
Toepasselijke technologieën	Algemeen, NET Framework 3
Kenmerken	N.v.t.
Naslaginformatie	MSDN
Stappen	Het programma kan verificatie niet inschakelen bij het maken van verbinding met MSMQ-wachtrijen. Een aanvaller kan anoniem berichten verzenden naar de wachtrij voor verwerking. Als verificatie niet wordt gebruikt om verbinding te maken met een MSMQ-wachtrij die wordt gebruikt voor het bezorgen van een bericht aan een ander programma, kan een aanvaller een anoniem bericht verzenden dat schadelijk is.

Opmerking

Het <netMsmqBinding/> element van het WCF-configuratiebestand hieronder geeft WCF de opdracht om verificatie uit te schakelen bij het maken van verbinding met een MSMQ-wachtrij voor berichtbezorging.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

Configureer MSMQ zodanig dat windows-domein- of certificaatverificatie altijd is vereist voor binnenkomende of uitgaande berichten.

Opmerking

Het <netMsmqBinding/> element van het ONDERSTAANDe WCF-configuratiebestand geeft WCF opdracht om certificaatverificatie in te schakelen bij het maken van verbinding met een MSMQ-wachtrij. De client wordt geverifieerd met X.509-certificaten. Het clientcertificaat moet aanwezig zijn in het certificaatarchief van de server.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

WCF-Do not set Message clientCredentialType to none

Titel	DETAILS
Onderdeel	WCF
SDL-fase	Build
Toepasselijke technologieën	.NET Framework 3
Kenmerken	Clientreferentietype - Geen
Naslaginformatie	MSDN, Fortify
Stappen	Het ontbreken van verificatie betekent dat iedereen toegang heeft tot deze service. Een service die de clients niet verifieert, biedt toegang tot alle gebruikers. Configureer de toepassing om te verifiëren op basis van clientreferenties. U kunt dit doen door de berichtclientCredentialType in te stellen op Windows of Certificaat.

Opmerking

<message clientCredentialType=""Certificate""/>

WCF-Do not set Transport clientCredentialType op geen

Titel	DETAILS
Onderdeel	WCF
SDL-fase	Build
Toepasselijke technologieën	Algemeen, .NET Framework 3
Kenmerken	Clientreferentietype - Geen
Naslaginformatie	MSDN, Fortify
Stappen	Het ontbreken van verificatie betekent dat iedereen toegang heeft tot deze service. Met een service die de clients niet verifieert, hebben alle gebruikers toegang tot de functionaliteit. Configureer de toepassing om te verifiëren op basis van clientreferenties. U kunt dit doen door de transportclientCredentialType in te stellen op Windows of Certificaat.

Opmerking

<transport clientCredentialType=""Certificate""/>

Zorg ervoor dat standaardverificatietechnieken worden gebruikt om web-API's te beveiligen

Titel	DETAILS
Onderdeel	Web-API
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	Verificatie en autorisatie in ASP.NET Web-API, Externe verificatieservices met ASP.NET Web-API (C#)
Stappen	Verificatie is het proces waarbij een entiteit zijn identiteit bewijst, meestal via referenties, zoals een gebruikersnaam en wachtwoord. Er zijn meerdere verificatieprotocollen beschikbaar die kunnen worden overwogen. Sommige hiervan worden hieronder weergegeven: Clientcertificaten Op basis van Windows Op formulieren gebaseerd Federatie - ADFS Federatie - Microsoft Entra-id Federatie - Identiteitsserver Koppelingen in de sectie Verwijzingen bieden gedetailleerde informatie over hoe elk van de verificatieschema's kan worden geïmplementeerd om een web-API te beveiligen.

Standaardverificatiescenario's gebruiken die worden ondersteund door Microsoft Entra ID

Titel	DETAILS
Onderdeel	Microsoft Entra ID
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	Verificatiescenario's voor Microsoft Entra-id, Microsoft Entra-codevoorbeelden, ontwikkelaarshandleiding voor Microsoft Entra
Stappen	Microsoft Entra ID vereenvoudigt verificatie voor ontwikkelaars door identiteit als een service te bieden, met ondersteuning voor industriestandaard protocollen zoals OAuth 2.0 en OpenID Connect. Hieronder ziet u de vijf primaire toepassingsscenario's die worden ondersteund door Microsoft Entra ID: Webbrowser naar webtoepassing: een gebruiker moet zich aanmelden bij een webtoepassing die is beveiligd door Microsoft Entra ID Toepassing met één pagina (BEVEILIGD-WACHTWOORDVERIFICATIE): Een gebruiker moet zich aanmelden bij een toepassing met één pagina die wordt beveiligd door Microsoft Entra-id Systeemeigen toepassing op web-API: een systeemeigen toepassing die wordt uitgevoerd op een telefoon, tablet of pc, moet een gebruiker verifiëren om resources op te halen uit een web-API die wordt beveiligd door Microsoft Entra ID Webtoepassing naar web-API: een webtoepassing moet resources ophalen uit een web-API die wordt beveiligd door Microsoft Entra-id Daemon of Servertoepassing naar web-API: Een daemon-toepassing of een servertoepassing zonder webgebruikersinterface moet resources ophalen uit een web-API die wordt beveiligd door Microsoft Entra ID Raadpleeg de koppelingen in de sectie met verwijzingen voor implementatiedetails op laag niveau

De standaard-MSAL-tokencache overschrijven met een gedistribueerde cache

Titel	DETAILS
Onderdeel	Microsoft Entra ID
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	Serialisatie van tokencache in MSAL.NET
Stappen	De standaardcache die door MSAL (Microsoft Authentication Library) wordt gebruikt, is een cache in het geheugen en is schaalbaar. Er zijn echter verschillende opties beschikbaar die u als alternatief kunt gebruiken, zoals een gedistribueerde tokencache. Deze hebben L1/L2-mechanismen, waarbij L1 zich in het geheugen bevindt en L2 de gedistribueerde cache-implementatie is. Deze kunnen dienovereenkomstig worden geconfigureerd om L1-geheugen te beperken, verwijderingsbeleid te versleutelen of in te stellen. Andere alternatieven zijn Redis-, SQL Server- of Azure Cosmos DB-caches. Een implementatie van een gedistribueerde tokencache vindt u in de volgende zelfstudie: Aan de slag met ASP.NET Core MVC.

Zorg ervoor dat TokenReplayCache wordt gebruikt om te voorkomen dat MSAL-verificatietokens opnieuw worden afgespeeld

Titel	DETAILS
Onderdeel	Microsoft Entra ID
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	Moderne verificatie met Microsoft Entra ID voor webtoepassingen
Stappen	Met de eigenschap TokenReplayCache kunnen ontwikkelaars een cache voor het opnieuw afspelen van tokens definiëren, een archief dat kan worden gebruikt voor het opslaan van tokens om te controleren of er meer dan één token kan worden gebruikt. Dit is een maatregel tegen een veelvoorkomende aanval, de tokenherhalingsaanval: een aanvaller die het token onderschept dat bij aanmelding wordt verzonden, probeert deze mogelijk opnieuw naar de app te verzenden ('opnieuw afspelen') om een nieuwe sessie tot stand te brengen. Bijvoorbeeld, in OIDC code-grant flow, na geslaagde gebruikersverificatie, wordt een aanvraag naar het eindpunt /signin-oidc van de relying party gemaakt met de parameters 'id_token', 'code' en 'state'. De relying party valideert deze aanvraag en brengt een nieuwe sessie tot stand. Als een aanvaller deze aanvraag vastlegt en opnieuw afspeelt, kan hij/zij een geslaagde sessie tot stand brengen en de gebruiker spoofen. De aanwezigheid van de nonce in OpenID Connect kan worden beperkt, maar niet volledig elimineren van de omstandigheden waarin de aanval kan worden uitgevoerd. Ontwikkelaars kunnen hun toepassingen beveiligen door een implementatie van ITokenReplayCache te bieden en een exemplaar toe te wijzen aan TokenReplayCache.

Opmerking

// ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

Opmerking

Hier volgt een voorbeeld van de ITokenReplayCache-interface. (Pas uw projectspecifieke cacheframework aan en implementeer deze)

public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

De geïmplementeerde cache moet als volgt worden verwezen in OIDC-opties via de eigenschap TokenValidationParameters.

OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

Als u de effectiviteit van deze configuratie wilt testen, meldt u zich aan bij uw lokale met OIDC beveiligde toepassing en legt u de aanvraag vast op "/signin-oidc" het eindpunt in Fiddler. Wanneer de beveiliging niet aanwezig is, wordt door het opnieuw afspelen van deze aanvraag in Fiddler een nieuwe sessiecookor ingesteld. Wanneer de aanvraag opnieuw wordt afgespeeld nadat de TokenReplayCache-beveiliging is toegevoegd, genereert de toepassing als volgt een uitzondering: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

MSAL-bibliotheken gebruiken om tokenaanvragen van OAuth2-clients te beheren naar Microsoft Entra-id (of on-premises AD)

Titel	DETAILS
Onderdeel	Microsoft Entra ID
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	MSAL
Stappen	Met de Microsoft Authentication Library (MSAL) kunnen ontwikkelaars beveiligingstokens verkrijgen van het Microsoft Identity Platform om gebruikers te verifiëren en toegang te krijgen tot beveiligde web-API's. Het kan worden gebruikt om beveiligde toegang te bieden tot Microsoft Graph, andere Microsoft-API's, web-API's van derden of uw eigen web-API. MSAL ondersteunt veel verschillende toepassingsarchitecturen en -platforms, waaronder .NET, JavaScript, Java, Python, Android en iOS.

MSAL biedt u veel manieren om tokens op te halen, met een consistente API voor veel platforms. U hoeft de OAuth-bibliotheken of -code niet rechtstreeks te gebruiken voor het protocol in uw toepassing en kan tokens verkrijgen namens een gebruiker of toepassing (indien van toepassing op het platform).

MSAL onderhoudt ook een tokencache en vernieuwt tokens voor u wanneer ze bijna verlopen. MSAL kan u ook helpen bij het opgeven van de doelgroep die u wilt dat uw toepassing zich aanmeldt en helpt u bij het instellen van uw toepassing vanuit configuratiebestanden en het oplossen van problemen met uw app.

Apparaten verifiëren die verbinding maken met de veldgateway

Titel	DETAILS
Onderdeel	IoT-veldgateway
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	N.v.t.
Stappen	Zorg ervoor dat elk apparaat wordt geverifieerd door de Veldgateway voordat u gegevens van het apparaat accepteert en voordat u upstream-communicatie met de cloudgateway faciliteert. Zorg er ook voor dat apparaten verbinding maken met een referentie per apparaat, zodat afzonderlijke apparaten uniek kunnen worden geïdentificeerd.

Controleren of apparaten die verbinding maken met cloudgateway, zijn geverifieerd

Titel	DETAILS
Onderdeel	IoT Cloud Gateway
SDL-fase	Build
Toepasselijke technologieën	Algemeen, C#, Node.js,
Kenmerken	N.b., gatewaykeuze - Azure IoT Hub
Naslaginformatie	N/B, Azure IoT-hub met .NET, Aan de slag met IoT Hub en Node JS, IoT beveiligen met SAS en certificaten, Git-opslagplaats
Stappen	Algemeen: verifieer het apparaat met behulp van Transport Layer Security (TLS) of IPSec. Infrastructuur moet ondersteuning bieden voor het gebruik van vooraf gedeelde sleutels (PSK) op die apparaten die geen volledige asymmetrische cryptografie kunnen verwerken. Maak gebruik van Microsoft Entra ID, OAuth. C#: Bij het maken van een DeviceClient-exemplaar maakt de methode Create standaard een DeviceClient-exemplaar dat gebruikmaakt van het AMQP-protocol om te communiceren met IoT Hub. Als u het HTTPS-protocol wilt gebruiken, dient u de Create-methode te overschrijven. Zo kunt u zelf het protocol bepalen. Als u het HTTPS-protocol gebruikt, moet u ook het Microsoft.AspNet.WebApi.Client NuGet-pakket aan uw project toevoegen om de System.Net.Http.Formatting naamruimte op te nemen.

Opmerking

static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

Opmerking

Node.js: verificatie

Symmetrische sleutel

• Een IoT-hub maken in Azure
• Een vermelding maken in het apparaat-id-register

  var device = new iothub.Device(null);
  device.deviceId = <DeviceId >
  registry.create(device, function(err, deviceInfo, res) {})
  

• Een gesimuleerd apparaat maken

  var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
  var Message = require('azure-iot-device').Message;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
  var client = clientFromConnectionString(connectionString);
  

  SAS-token

• Wordt intern gegenereerd bij het gebruik van een symmetrische sleutel, maar we kunnen deze ook expliciet genereren en gebruiken
• Een protocol definiëren: var Http = require('azure-iot-device-http').Http;
• Een SAS-token maken:

  resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
  var deviceName = "<deviceName >";
  var expires = (Date.now() / 1000) + expiresInMins * 60;
  var toSign = resourceUri + '\n' + expires;
  // using crypto
  var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
  const hmac = crypto.createHmac('sha256', decodedPassword);
  hmac.update(toSign);
  var base64signature = hmac.digest('base64');
  var base64UriEncoded = encodeURIComponent(base64signature);
  // construct authorization string
  var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
  + base64UriEncoded + "&se=" + expires;
  if (policyName) token += "&skn="+policyName;
  return token;
  

• Verbinding maken met behulp van sas-token:

  Client.fromSharedAccessSignature(sas, Http);
  

  Certificaten

• Genereer een zelfondertekend X509-certificaat met behulp van een hulpprogramma zoals OpenSSL om respectievelijk een .cert en .key bestanden te genereren om het certificaat en de sleutel op te slaan
• Richt een apparaat in dat beveiligde verbinding accepteert met behulp van certificaten.

  var connectionString = '<connectionString>';
  var registry = iothub.Registry.fromConnectionString(connectionString);
  var deviceJSON = {deviceId:"<deviceId>",
  authentication: {
      x509Thumbprint: {
      primaryThumbprint: "<PrimaryThumbprint>",
      secondaryThumbprint: "<SecondaryThumbprint>"
      }
  }}
  var device = deviceJSON;
  registry.create(device, function (err) {});
  

• Een apparaat verbinden met behulp van een certificaat

  var Protocol = require('azure-iot-device-http').Http;
  var Client = require('azure-iot-device').Client;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
  var client = Client.fromConnectionString(connectionString, Protocol);
  var options = {
      key: fs.readFileSync('./key.pem', 'utf8'),
      cert: fs.readFileSync('./server.crt', 'utf8')
  };
  // Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
  client.setOptions(options);
  //call fn to execute after the connection is set up
  client.open(fn);
  

Verificatiereferenties per apparaat gebruiken

Titel	DETAILS
Onderdeel	IoT Cloud Gateway
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	Gatewaykeuze - Azure IoT Hub
Naslaginformatie	Azure IoT Hub-beveiligingstokens
Stappen	Gebruik referenties voor verificatie per apparaat met behulp van SaS-tokens op basis van apparaatsleutel of clientcertificaat, in plaats van gedeeld toegangsbeleid op IoT Hub-niveau. Dit voorkomt het hergebruik van verificatietokens van één apparaat of veldgateway door een ander

Zorg ervoor dat alleen de vereiste containers en blobs anonieme leestoegang krijgen

Titel	DETAILS
Onderdeel	Azure Storage
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	StorageType - Blob
Naslaginformatie	Anonieme leestoegang tot containers en blobs, Shared Access Signatures beheren, deel 1: Inzicht krijgen in het SAS-model
Stappen	Standaard zijn een container en eventuele blobs in deze container alleen toegankelijk voor de eigenaar van het opslagaccount. Als u anonieme gebruikers leesmachtigingen wilt geven voor een container en de bijbehorende blobs, kunt u de containermachtigingen instellen om openbare toegang toe te staan. Anonieme gebruikers kunnen blobs lezen binnen een openbaar toegankelijke container zonder de aanvraag te verifiëren. Containers bieden de volgende opties voor het beheren van containertoegang: Volledige openbare leestoegang: Container- en blobgegevens kunnen worden gelezen via anonieme aanvraag. Clients kunnen blobs in de container opsommen via anonieme aanvragen, maar kunnen geen containers in het opslagaccount opsommen. Alleen openbare leestoegang voor blobs: blobgegevens in deze container kunnen worden gelezen via anonieme aanvraag, maar containergegevens zijn niet beschikbaar. Clients kunnen geen blobs in de container opsommen via anonieme aanvraag Geen openbare leestoegang: Container- en blobgegevens kunnen alleen worden gelezen door de accounteigenaar Anonieme toegang is het meest geschikt voor scenario's waarbij bepaalde blobs altijd beschikbaar moeten zijn voor anonieme leestoegang. Voor nauwkeuriger beheer kunt u een handtekening voor gedeelde toegang maken, waarmee beperkte toegang kan worden gedelegeerd met behulp van verschillende machtigingen en gedurende een opgegeven tijdsinterval. Zorg ervoor dat containers en blobs, die mogelijk gevoelige gegevens bevatten, niet per ongeluk anonieme toegang krijgen

Beperkte toegang verlenen tot objecten in Azure Storage met behulp van SAS of SAP

Titel	DETAILS
Onderdeel	Azure Storage
SDL-fase	Build
Toepasselijke technologieën	Algemeen
Kenmerken	N.v.t.
Naslaginformatie	Shared Access Signatures, deel 1: Inzicht krijgen in het SAS-model, Shared Access Signatures, Deel 2: Een SAS maken en gebruiken met Blob-opslag, toegang tot objecten in uw account delegeren met shared Access Signatures en opgeslagen toegangsbeleid
Stappen	Het gebruik van een Shared Access Signature (SAS) is een krachtige manier om beperkte toegang te verlenen tot objecten in een opslagaccount aan andere clients, zonder dat u de toegangssleutel van het account hoeft bloot te stellen. De SAS is een URI die in de queryparameters alle informatie omvat die nodig is voor geverifieerde toegang tot een opslagresource. Om toegang te krijgen tot opslagresources met de SAS, hoeft de client alleen de SAS door te geven aan de juiste constructor of methode. U kunt een SAS gebruiken als u toegang wilt verlenen tot resources in uw opslagaccount voor een client die niet kan worden vertrouwd met de accountsleutel. Uw opslagaccountsleutels bevatten zowel een primaire als een secundaire sleutel, die beide beheerderstoegang verlenen tot uw account en alle resources erin. Als u een van uw accountsleutels beschikbaar maakt, wordt uw account geopend voor de mogelijkheid van schadelijk of onachtzaam gebruik. Handtekeningen voor gedeelde toegang bieden een veilig alternatief waarmee andere clients gegevens in uw opslagaccount kunnen lezen, schrijven en verwijderen op basis van de machtigingen die u hebt verleend en zonder dat de accountsleutel nodig is. Als u een logische set parameters hebt die elke keer vergelijkbaar zijn, is het beter om een SAP (Stored Access Policy) te gebruiken. Omdat het gebruik van een SAS die is afgeleid van een opgeslagen toegangsbeleid u de mogelijkheid biedt om die SAS onmiddellijk in te trekken, is het de aanbevolen procedure om opgeslagen toegangsbeleid altijd te gebruiken wanneer dat mogelijk is.