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 de adreslijstservice die al wordt gebruikt. Voor de meeste organisaties is Active Directory de adreslijstservice voor alle identiteitsgerelateerde services. 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. Configureer waar mogelijk Data Lake Data Store-services met Microsoft Entra-integratie.
Gebruik toegangssleutel of token voor verificatie voor gegevensservices die geen ondersteuning bieden voor Microsoft Entra-id. De client moet de toegangssleutel opslaan in een sleutelbeheerarchief, zoals Azure Key Vault.
Verificatiescenario's voor analyses op cloudschaal zijn:
- Gebruikersverificatie
- Toepassings- en service-naar-serviceverificatie
Gebruikersverificatie
Gebruikers die verbinding maken met een gegevensservice of resource, moeten een referentie presenteren. Deze referentie bewijst dat gebruikers zijn wie ze claimen. 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 en Azure Synapse ondersteunen Microsoft Entra-integratie. Voor de interactieve gebruikersverificatiemodus moeten gebruikers referenties opgeven in een dialoogvenster.
Belangrijk
Codeer geen gebruikersreferenties in een toepassing voor verificatiedoeleinden.
Toepassings- en service-naar-serviceverificatie
Deze aanvragen zijn niet gekoppeld aan een specifieke gebruiker of er is geen gebruiker beschikbaar om referenties in te voeren.
Verificatie van service-tot-service
Zelfs als een service toegang heeft tot een andere service zonder menselijke interacties, moet de service een geldige identiteit hebben. Deze identiteit bewijst dat de service echt is. De geopende service kan de identiteit gebruiken om te bepalen wat de service kan doen.
Voor service-naar-serviceverificatie 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 is een object dat is geregistreerd bij Microsoft Entra ID. Het vertegenwoordigt dit 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 is een toepassing, zoals een mobiele webtoepassing, die toegang heeft tot een Azure-service. Wie toegang heeft tot een Azure-service, moet de toegangsfunctie de identiteit opgeven en moet die identiteit worden geverifieerd.
Een Azure-service-principal is het alternatief voor toepassingen en services die beheerde identiteiten niet ondersteunen voor verificatie bij Azure-resources. Een Azure-service-principal is een identiteit die is gemaakt om toepassingen, gehoste services en geautomatiseerde hulpprogramma's toegang te geven tot Azure-resources. Deze toegang wordt beperkt door de rollen die zijn toegewezen aan de service-principal. Om veiligheidsredenen raden we u aan 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.
Notitie
Zowel beheerde identiteiten als service-principals worden alleen gemaakt en onderhouden in Microsoft Entra-id.
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. |
| Kan worden gebruikt door elke toepassing of service. Deze 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. |
Databaseverificatie en machtigingen
Analyse op cloudschaal bevat waarschijnlijk polyglotopslag. Voorbeelden hiervan zijn PostgreSQL, MySQL, Azure SQL Database, SQL Managed Instance en Azure Synapse Analytics.
- Microsoft Entra-id gebruiken voor verificatie met PostgreSQL
- Microsoft Entra-verificatie gebruiken met Azure SQL Database, SQL Managed Instance en Azure Synapse Analytics
- Microsoft Entra-id gebruiken voor verificatie met MySQL
U wordt aangeraden Microsoft Entra-groepen te gebruiken om databaseobjecten te beveiligen in plaats van afzonderlijke Microsoft Entra-gebruikersaccounts. Gebruik deze Microsoft Entra-groepen om gebruikers te verifiëren en databaseobjecten te beveiligen. Net als bij het data lake-patroon kunt u de onboarding van uw gegevenstoepassing gebruiken om deze groepen te maken.
Notitie
Gegevenstoepassingen kunnen gevoelige gegevensproducten opslaan in Azure SQL Database-, SQL Managed Instance- of Azure Synapse Analytics-pools. Zie Gevoelige gegevens voor meer informatie.
Azure Data Lake-beveiliging in analyses op cloudschaal
Als u de toegang tot gegevens in de Data Lake wilt beheren, wordt u aangeraden toegangsbeheerlijst (ACL) te gebruiken op het niveau van bestanden en mappen. Azure Data Lake gebruikt ook een POSIX-achtig toegangsbeheerlijstmodel. POSIX (portable operating system interface) is een serie standaarden voor besturingssystemen. Eén standaard definieert een eenvoudige maar krachtige machtigingsstructuur voor het openen van bestanden en mappen. POSIX is algemeen gebruikt voor netwerkbestandsshares en Unix-computers.
Net als bij algemene procedures van Azure RBAC moeten de volgende regels van toepassing zijn op ACL:
Toegang beheren met behulp van groepen. Wijs toegang toe aan Microsoft Entra-groepen en beheer het lidmaatschap van groepen voor doorlopend toegangsbeheer. Zie Toegangsbeheer en Data Lake-configuraties in Azure Data Lake Storage.
Minimale bevoegdheden. In de meeste gevallen moeten gebruikers alleen leesmachtigingen hebben voor de mappen en bestanden die ze nodig hebben in de Data Lake. Een beheerde identiteit of service-principal, zoals de identiteit die wordt gebruikt door Azure Data Factory, heeft lees-, schrijf- en uitvoermachtigingen. Gegevensgebruikers mogen geen toegang hebben tot de container van het opslagaccount.
Uitlijnen op het schema voor gegevenspartitionering. Het ontwerp van ACL en gegevenspartitie moet worden uitgelijnd om effectief toegangsbeheer voor gegevens te garanderen. Zie [Data lake partitionering] voor meer informatie.
Volgende stappen
Gegevensbeheer en op rollen gebaseerd toegangsbeheer voor analyses op cloudschaal in Azure