Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Verificatie is het proces van het verifiëren van de identiteit van een gebruiker of toepassing. U wordt aangeraden een id-provider met één bron te gebruiken om identiteitsbeheer en verificatie af te handelen. Deze provider wordt een adreslijstservice genoemd. Het biedt manieren om adreslijstgegevens op te slaan en deze gegevens beschikbaar te maken 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 Microsoft Entra-id. 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. Delegeren verificatie en autorisatie aan Microsoft Entra-id voor het gebruik van mogelijkheden zoals beleid voor voorwaardelijke toegang waarvoor een gebruiker zich op een specifieke locatie moet bevinden. Microsoft Entra ID biedt ook ondersteuning voor meervoudige verificatie, waardoor het niveau van toegangsbeveiliging wordt verhoogd. U moet gegevensservices configureren door Microsoft Entra ID waar mogelijk te integreren.
Als uw gegevensservices geen ondersteuning bieden voor Microsoft Entra ID, 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. In dit scenario verifieert Microsoft Entra ID gebruikers met behulp van hun referenties.
- Service-naar-service-authenticatie. In dit scenario verifiëren Azure-resources services met behulp van beheerde identiteiten, die automatisch worden beheerd door Azure.
- Applicatie-naar-service-authenticatie. In dit scenario verifiëren toepassingen services met behulp van service-principals.
Verificatiescenario's
In de volgende secties worden alle verificatiescenario's beschreven: gebruikersverificatie, service-naar-service-verificatie en toepassings-naar-service-verificatie.
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, Azure SQL Database 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.
Authenticatie tussen services
Wanneer een service toegang heeft tot een andere service zonder menselijke interactie, moet deze een geldige identiteit presenteren. Deze identiteit bewijst de echtheid van de service en staat de service toe waartoe deze toegang heeft om te bepalen welke acties zijn toegestaan.
In service-naar-service-verificatiescenario's raden we u aan beheerde identiteiten te gebruiken voor het verifiëren van Azure-services. Beheerde identiteiten voor Azure-resources maken verificatie mogelijk voor elke service die ondersteuning biedt voor Microsoft Entra-verificatie zonder expliciete inloggegevens. Zie Wat zijn beheerde identiteiten voor Azure-resources? voor meer informatie.
Beheerde identiteiten zijn service-principals die alleen kunnen worden gebruikt met Azure-resources. U kunt bijvoorbeeld een beheerde identiteit maken voor een Azure Data Factory-exemplaar. Microsoft Entra ID registreert deze beheerde identiteit als een object dat het Data Factory-exemplaar vertegenwoordigt. U kunt deze identiteit vervolgens gebruiken om te authentiseren bij elke service, zoals Data Lake Storage, zonder inloggegevens in de code. Azure beheert de referenties die door de service-instantie worden gebruikt. De identiteit kan Azure-servicebronnen verifiëren, zoals een map in Data Lake Storage. Wanneer u het Data Factory-exemplaar verwijdert, verwijdert Azure de identiteit in Microsoft Entra-id.
Voordelen van het gebruik van beheerde identiteiten
Beheerde identiteiten gebruiken om een Azure-service te verifiëren bij een andere Azure-service of -resource. Beheerde identiteiten 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.
- Wanneer u beheerde identiteiten gebruikt, gebruiken de clientservices geen wachtwoorden.
- De door het systeem toegewezen beheerde identiteit wordt verwijderd wanneer het service-exemplaar wordt verwijderd.
Deze voordelen betekenen dat referenties beter zijn beveiligd en dat inbreuk op beveiliging minder waarschijnlijk is.
Toepassings-naar-service-verificatie
Een ander toegangsscenario is wanneer een toepassing, zoals een mobiele of webtoepassing, toegang krijgt tot een Azure-service. De toepassing moet zijn identiteit presenteren, die vervolgens moet worden geverifieerd.
Een Azure-service-principal is de alternatieve optie voor toepassingen en services die geen ondersteuning bieden voor beheerde identiteiten voor verificatie bij Azure-resources. Een service-principal 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 wordt u aangeraden service-principals te gebruiken met geautomatiseerde hulpprogramma's of toepassingen in plaats van hen toe te staan zich aan te melden met een gebruikersidentiteit. Zie Toepassings- en service-principalobjecten in Microsoft Entra-id voor meer informatie.
Verschillen tussen beheerde identiteiten en service-principals
| Service-principal | Beheerde identiteit |
|---|---|
| Een beveiligingsidentiteit die u handmatig maakt in Microsoft Entra ID voor toepassingen, services en hulpprogramma's die toegang nodig hebben tot specifieke Azure-resources. | Een speciaal type service-hoofdgebruiker. 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 implementeren van robuuste en veilige verificatieprocedures van cruciaal belang. Aanbevolen procedures voor verificatie zijn van toepassing op verschillende lagen van een oplossing, waaronder databases, opslag en analyseservices. Met behulp van Microsoft Entra ID kunnen organisaties de beveiliging verbeteren met behulp van functies zoals meervoudige verificatie en beleid voor voorwaardelijke toegang.
| Laag | Dienst | Aanbeveling |
|---|---|---|
| Databanken | - SQL Database - SQL Managed Instance - Azure Database for MySQL - Azure Database for PostgreSQL |
Gebruik Microsoft Entra ID voor verificatie met databases zoals Azure Database for PostgreSQL, Azure SQL en Azure Database for MySQL. |
| Opslag | Data-opslag in een data lake | Gebruik Microsoft Entra-id voor verificatie voor beveiligingsprinciplen, zoals gebruikers, groepen en service-principals of beheerde identiteiten, met Data Lake Storage in plaats van een gedeelde sleutel of handtekeningen voor gedeelde toegang. Deze aanpak helpt de beveiliging te verbeteren omdat het ondersteuning biedt voor meervoudige verificatie en beleid voor voorwaardelijke toegang. |
| Opslag | Data Lake Storage van Azure Databricks | Maak verbinding met Data Lake Storage met behulp van Unity Catalog in plaats van directe toegang op opslagniveau door een opslagreferentie te maken die gebruikmaakt van een beheerde identiteit en een externe locatie. |
| Gegevensanalyse | Azure Databricks | Gebruik het systeem voor identiteitsbeheer tussen domeinen om gebruikers en groepen van Microsoft Entra ID te synchroniseren. Als u toegang wilt krijgen tot Azure Databricks-resources met behulp van REST API's, gebruikt u OAuth met een Azure Databricks-service-principal. |
Belangrijk
Door Azure Databricks-gebruikers directe toegang op opslagniveau te geven tot Data Lake Storage, worden de machtigingen, controles en beveiligingsfuncties van Unity Catalog overgeslagen, waaronder toegangsbeheer en bewaking. Om gegevens beter te beveiligen en te beheren, moet Unity Catalog de toegang beheren tot gegevens die zijn opgeslagen in Data Lake Storage voor azure Databricks-werkruimtegebruikers.