Verificatie voor analyses op cloudschaal in Azure
Verificatie is het proces van het verifiëren van de identiteit van de gebruiker of toepassing. Eén bron-id-provider heeft de voorkeur, die identiteitsbeheer en verificatie afhandelt. Deze provider wordt een adreslijstservice genoemd. Het biedt methoden voor het opslaan van adreslijstgegevens en het beschikbaar maken van deze gegevens voor netwerkgebruikers en beheerders.
Elke Data Lake-oplossing moet worden gebruikt en geïntegreerd met een bestaande adreslijstservice. Voor de meeste organisaties is de adreslijstservice voor alle identiteitsgerelateerde services Active Directory. Het is de primaire en gecentraliseerde database voor alle service- en gebruikersaccounts.
In de cloud is Microsoft Entra-id een gecentraliseerde id-provider en de voorkeursbron voor identiteitsbeheer. Het delegeren van verificatie en autorisatie aan Microsoft Entra ID maakt scenario's mogelijk, zoals beleid voor voorwaardelijke toegang waarvoor een gebruiker zich op een specifieke locatie moet bevinden. Het biedt ondersteuning voor meervoudige verificatie om het niveau van toegangsbeveiliging te verhogen. Gegevensservices moeten zo mogelijk worden geconfigureerd met Microsoft Entra ID-integratie.
Voor gegevensservices die microsoft Entra-id niet ondersteunen, moet u verificatie uitvoeren met behulp van een toegangssleutel of token. U moet de toegangssleutel opslaan in een sleutelbeheerarchief, zoals Azure Key Vault.
Verificatiescenario's voor analyses op cloudschaal zijn:
- Gebruikersverificatie: Gebruikers verifiëren via Microsoft Entra ID met behulp van hun inloggegevens.
- Authenticatie van applicatie tot service: Applicaties verifiëren met behulp van service-principals.
- service-naar-service-verificatie: Azure-resources verifiëren met behulp van beheerde identiteiten, die automatisch worden beheerd door Azure.
Verificatiescenario's
Gebruikersverificatie
Gebruikers die verbinding maken met een gegevensservice of resource, moeten een referentie presenteren. Deze referentie bewijst dat gebruikers zijn wie ze beweren te zijn. Vervolgens hebben ze toegang tot de service of resource. Met verificatie kan de service ook de identiteit van de gebruikers kennen. De service bepaalt wat een gebruiker kan zien en doen nadat de identiteit is geverifieerd.
Azure Data Lake Storage Gen2, Azure SQL Database, Azure Synapse Analytics en Azure Databricks ondersteunen integratie van Microsoft Entra ID. Voor de interactieve gebruikersverificatiemodus moeten gebruikers referenties opgeven in een dialoogvenster.
Belangrijk
Codeer geen gebruikersreferenties in een toepassing voor verificatiedoeleinden.
Verificatie van service-tot-service
Zelfs wanneer een service zonder menselijke interactie toegang heeft tot een andere service, moet deze een geldige identiteit presenteren. Deze identiteit bewijst de echtheid van de service, waardoor de geopende service de toegestane acties kan bepalen.
Voor service-naar-service-verificatie is de voorkeursmethode voor het verifiëren van Azure-services beheerde identiteiten. Beheerde identiteiten voor Azure-resources maken verificatie mogelijk voor elke service die Ondersteuning biedt voor Microsoft Entra-verificatie zonder expliciete referenties. Zie Wat zijn beheerde identiteiten voor Azure-resources? voor meer informatie.
Beheerde identiteiten zijn service-principals, die alleen kunnen worden gebruikt met Azure-resources. Een beheerde identiteit kan bijvoorbeeld rechtstreeks worden gemaakt voor een Azure Data Factory-exemplaar. Deze beheerde identiteit, geregistreerd bij Microsoft Entra ID als object, vertegenwoordigt het Data Factory-exemplaar. Deze identiteit kan vervolgens worden gebruikt om te verifiëren bij elke service, zoals Data Lake Storage, zonder referenties in de code. Azure zorgt voor de referenties die worden gebruikt door het service-exemplaar. De identiteit kan autorisatie verlenen aan Azure-servicebronnen, zoals een map in Azure Data Lake Storage. Wanneer u dit Data Factory-exemplaar verwijdert, schoont Azure de identiteit op in Microsoft Entra-id.
Voordelen van het gebruik van beheerde identiteiten
Beheerde identiteiten moeten worden gebruikt om een Azure-service te verifiëren bij een andere Azure-service of -resource. Ze bieden de volgende voordelen:
- Een beheerde identiteit vertegenwoordigt de service waarvoor deze wordt gemaakt. Het vertegenwoordigt geen interactieve gebruiker.
- Referenties voor beheerde identiteit worden onderhouden, beheerd en opgeslagen in Microsoft Entra-id. Er is geen wachtwoord voor een gebruiker om te bewaren.
- Bij beheerde identiteiten gebruiken de clientservices geen wachtwoorden.
- De door het systeem toegewezen beheerde identiteit wordt verwijderd wanneer het service-exemplaar wordt verwijderd.
Deze voordelen betekenen dat de referentie beter is beveiligd en dat inbreuk op de beveiliging minder waarschijnlijk is.
Toepassings-naar-service-verificatie
Een ander toegangsscenario omvat een toepassing, zoals een mobiele of webtoepassing, die toegang heeft tot een Azure-service. De toepassing moet zijn identiteit presenteren, die vervolgens moet worden geverifieerd.
Een service-principal van Azure is het alternatief voor toepassingen en services die beheerde identiteiten niet ondersteunen voor verificatie bij Azure-resources. Het is een identiteit die specifiek is gemaakt voor toepassingen, gehoste services en geautomatiseerde hulpprogramma's voor toegang tot Azure-resources. De rollen die aan de service-principal zijn toegewezen, beheren de toegang. Om veiligheidsredenen is het raadzaam om service-principals te gebruiken met geautomatiseerde hulpprogramma's of toepassingen in plaats van ze toe te staan zich aan te melden met een gebruikersidentiteit. Zie Toepassings- en service-principalobjecten in Microsoft Entra-id voor meer informatie.
Verschil tussen beheerde identiteit en service-principal
| Service-principal | Beheerde identiteit |
|---|---|
| Een beveiligingsidentiteit die handmatig in Microsoft Entra-id is gemaakt voor gebruik door toepassingen, services en hulpprogramma's voor toegang tot specifieke Azure-resources. | Een speciaal type service-principal. Het is een automatische identiteit die wordt gemaakt wanneer een Azure-service wordt gemaakt. |
| Wordt gebruikt door een toepassing of service en is niet gekoppeld aan een specifieke Azure-service. | Vertegenwoordigt een Azure-service-exemplaar zelf. Het kan niet worden gebruikt om andere Azure-services weer te geven. |
| Heeft een onafhankelijke levenscyclus. U moet deze expliciet verwijderen. | Wordt automatisch verwijderd wanneer het Azure-service-exemplaar wordt verwijderd. |
| Verificatie op basis van een wachtwoord of certificaat. | Er moet geen expliciet wachtwoord worden opgegeven voor verificatie. |
Notitie
Zowel beheerde identiteiten als service-principals worden alleen gemaakt en onderhouden in Microsoft Entra-id.
Aanbevolen procedures voor verificatie in analyses op cloudschaal
In analyses op cloudschaal is het essentieel om robuuste en veilige verificatieprocedures te garanderen. Aanbevolen procedures voor verificatie in verschillende lagen, waaronder databases, opslag en analyseservices. Met behulp van Microsoft Entra ID kunnen organisaties de beveiliging verbeteren met functies zoals meervoudige verificatie (MFA) en beleid voor voorwaardelijke toegang.
| Laag | Dienst | Aanbevelingen |
|---|---|---|
| Databanken | Azure SQL DB, SQL MI, Synapse, MySQL, PostgreSQL, enzovoort. | Gebruik Microsoft Entra-id voor verificatie met databases zoals PostgreSQL-, Azure SQLen MySQL-. |
| Opslag | Azure Data Lake Storage (ADLS) | Gebruik Microsoft Entra-id voor verificatie voor beveiligingsprincipals (gebruiker, groep, service-principal of beheerde identiteit) met ADLS via gedeelde sleutel of SAS, omdat hiermee verbeterde beveiliging mogelijk is via de ondersteuning voor meervoudige verificatie (MFA) en beleid voor voorwaardelijke toegang. |
| Opslag | ADLS van Azure Databricks | Maak verbinding met ADLS-met behulp van Unity Catalog in plaats van directe toegang op opslagniveau door een opslagreferentie te maken met behulp van een beheerde identiteit en een externe locatie. |
| Analytics | Azure Databricks | Gebruik SCIM om gebruikers en groepen te synchroniseren vanuit Microsoft Entra ID. Als u toegang wilt krijgen tot Databricks-resources met REST API's, OAuth gebruiken met een Databricks-service-principal. |
Belangrijk
Door Azure Databricks-gebruikers directe toegang op opslagniveau te geven tot ADLS, worden de machtigingen, controles en beveiligingsfuncties van Unity Catalog overgeslagen, waaronder toegangsbeheer en bewaking. Als u gegevens volledig wilt beveiligen en beheren, moet de toegang tot gegevens die zijn opgeslagen in ADLS voor Azure Databricks-werkruimtegebruikers worden beheerd via Unity Catalog.