Autentisering för analys i molnskala i Azure
Autentisering är processen för att verifiera användarens eller programmets identitet. En enda källidentitetsprovider föredras, som hanterar identitetshantering och autentisering. Den här providern kallas för en katalogtjänst. Den innehåller metoder för att lagra katalogdata och göra dessa data tillgängliga för nätverksanvändare och administratörer.
Alla datasjölösningar bör använda och integreras med katalogtjänsten som redan används. För de flesta organisationer är Active Directory katalogtjänsten för alla identitetsrelaterade tjänster. Det är den primära och centraliserade databasen för alla tjänst- och användarkonton.
I molnet är Microsoft Entra ID en centraliserad identitetsprovider och önskad källa för identitetshantering. Om du delegerar autentisering och auktorisering till Microsoft Entra-ID kan du använda scenarier som principer för villkorlig åtkomst som kräver att en användare befinner sig på en viss plats. Den stöder multifaktorautentisering för att öka åtkomstsäkerheten. Konfigurera data lake-datalagertjänster med Microsoft Entra-integrering när det är möjligt.
För datatjänster som inte stöder Microsoft Entra-ID använder du åtkomstnyckel eller token för autentisering. Klienten bör lagra åtkomstnyckeln i ett nyckelhanteringsarkiv, till exempel Azure Key Vault.
Autentiseringsscenarier för analys i molnskala är:
- Användarautentisering
- Program- och tjänst-till-tjänst-autentisering
Användarautentisering
Användare som ansluter till en datatjänst eller resurs måste presentera en autentiseringsuppgift. Den här autentiseringsuppgiften bevisar att användarna är de som de hävdar. Sedan kan de komma åt tjänsten eller resursen. Autentisering gör det också möjligt för tjänsten att känna till användarnas identitet. Tjänsten bestämmer vad en användare kan se och göra när identiteten har verifierats.
Azure Data Lake Storage Gen2, Azure SQL Database och Azure Synapse stöder Microsoft Entra-integrering. Det interaktiva användarautentiseringsläget kräver att användarna anger autentiseringsuppgifter i en dialogruta.
Viktigt!
Hårdkoda inte användarautentiseringsuppgifter i ett program i autentiseringssyfte.
Program- och tjänst-till-tjänst-autentisering
Dessa begäranden är inte associerade med en specifik användare eller så finns det ingen tillgänglig användare för att ange autentiseringsuppgifter.
Tjänst-till-tjänst-autentisering
Även om en tjänst får åtkomst till en annan tjänst utan mänsklig interaktion måste tjänsten presentera en giltig identitet. Den här identiteten bevisar att tjänsten är verklig. Den använda tjänsten kan använda identiteten för att avgöra vad tjänsten kan göra.
För tjänst-till-tjänst-autentisering är den bästa metoden för att autentisera Azure-tjänster hanterade identiteter. Hanterade identiteter för Azure-resurser tillåter autentisering till alla tjänster som stöder Microsoft Entra-autentisering utan några explicita autentiseringsuppgifter. Mer information finns i Vad är hanterade identiteter för Azure-resurser.
Hanterade identiteter är tjänstens huvudnamn, som bara kan användas med Azure-resurser. Till exempel kan en hanterad identitet skapas direkt för en Azure Data Factory-instans. Den här hanterade identiteten är ett objekt som är registrerat i Microsoft Entra-ID. Den representerar den här Data Factory-instansen. Den här identiteten kan sedan användas för att autentisera till alla tjänster, till exempel Data Lake Storage, utan några autentiseringsuppgifter i koden. Azure tar hand om de autentiseringsuppgifter som används av tjänstinstansen. Identiteten kan bevilja auktorisering till Azure-tjänstresurser, till exempel en mapp i Azure Data Lake Storage. När du tar bort den här Data Factory-instansen rensar Azure identiteten i Microsoft Entra-ID:t.
Fördelar med att använda hanterade identiteter
Hanterade identiteter ska användas för att autentisera en Azure-tjänst till en annan Azure-tjänst eller resurs. De ger följande fördelar:
- En hanterad identitet representerar den tjänst som den skapas för. Den representerar inte en interaktiv användare.
- Autentiseringsuppgifter för hanterade identiteter underhålls, hanteras och lagras i Microsoft Entra-ID. Det finns inget lösenord för en användare att behålla.
- Med hanterade identiteter använder klienttjänsterna inte lösenord.
- Den systemtilldelade hanterade identiteten tas bort när tjänstinstansen tas bort.
Dessa fördelar innebär att autentiseringsuppgifterna skyddas bättre och att säkerhetskompromisser är mindre sannolika.
Program-till-tjänst-autentisering
Ett annat åtkomstscenario är ett program, till exempel ett mobilt webbprogram, som har åtkomst till en Azure-tjänst. Den som har åtkomst till en Azure-tjänst måste ange sin identitet och den identiteten måste verifieras.
Ett huvudnamn för Azure-tjänsten är alternativet för program och tjänster som inte stöder hanterade identiteter för att autentisera till Azure-resurser. Ett huvudnamn för tjänsten i Azure är en identitet som skapas för användning med program, värdbaserade tjänster och automatiserade verktyg för att tillgång till Azure-resurser. Den här åtkomsten begränsas av de roller som tilldelats tjänstens huvudnamn. Av säkerhetsskäl rekommenderar vi att du använder tjänstens huvudnamn med automatiserade verktyg eller program i stället för att tillåta dem att logga in med en användaridentitet. Mer information finns i Program- och tjänsthuvudnamnsobjekt i Microsoft Entra-ID.
Kommentar
Både hanterade identiteter och tjänstens huvudnamn skapas och underhålls endast i Microsoft Entra-ID.
Skillnad mellan hanterad identitet och tjänstens huvudnamn
| Tjänstens huvudnamn | Hanterade identiteter |
|---|---|
| En säkerhetsidentitet som skapats manuellt i Microsoft Entra-ID för användning av program, tjänster och verktyg för att få åtkomst till specifika Azure-resurser. | En särskild typ av tjänstens huvudnamn. Det är en automatisk identitet som skapas när en Azure-tjänst skapas. |
| Kan användas av alla program eller tjänster. Det är inte kopplat till en specifik Azure-tjänst. | Representerar en azure-tjänstinstans. Det kan inte användas för att representera andra Azure-tjänster. |
| Har en oberoende livscykel. Du måste ta bort den explicit. | Tas bort automatiskt när Azure-tjänstinstansen tas bort. |
| Lösenordsbaserad eller certifikatbaserad autentisering. | Inget uttryckligt lösenord ska anges för autentisering. |
Databasautentisering och behörigheter
Analys i molnskala innehåller förmodligen flerspråkig lagring. Exempel är PostgreSQL, MySQL, Azure SQL Database, SQL Managed Instance och Azure Synapse Analytics.
- Använda Microsoft Entra-ID för autentisering med PostgreSQL
- Använda Microsoft Entra-autentisering med Azure SQL Database, SQL Managed Instance och Azure Synapse Analytics
- Använda Microsoft Entra-ID för autentisering med MySQL
Vi rekommenderar att du använder Microsoft Entra-grupper för att skydda databasobjekt i stället för enskilda Microsoft Entra-användarkonton. Använd dessa Microsoft Entra-grupper för att autentisera användare och skydda databasobjekt. På samma sätt som data lake-mönstret kan du använda registrering av dataprogram för att skapa dessa grupper.
Kommentar
Dataprogram kan lagra känsliga dataprodukter i Azure SQL Database, SQL Managed Instance eller Azure Synapse Analytics-pooler. Mer information finns i Datasekretess för analys i molnskala i Azure.
Azure Data Lake-säkerhet i analys i molnskala
För att styra åtkomsten till data i datasjön rekommenderar vi att du använder åtkomstkontrollistan (ACL) på nivån för filer och mappar. Azure Data Lake använder också en POSIX-liknande modell för åtkomstkontrollistor. POSIX (portabelt operativsystemgränssnitt) är en serie standarder för operativsystem. En standard definierar en enkel men kraftfull behörighetsstruktur för åtkomst till filer och mappar. POSIX har antagits i stor utsträckning för nätverksfilresurser och Unix-datorer.
På samma sätt som allmänna metoder i Azure RBAC bör följande regler gälla för ACL:
Hantera åtkomst med hjälp av grupper. Tilldela åtkomst till Microsoft Entra-grupper och hantera medlemskap i grupper för kontinuerlig åtkomsthantering. Se Åtkomstkontroll och datasjökonfigurationer i Azure Data Lake Storage.
Lägsta behörighet. I de flesta fall bör användarna bara ha läsbehörighet till de mappar och filer som de behöver i datasjön. En hanterad identitet eller tjänstens huvudnamn, till exempel den som används av Azure Data Factory, har läs-, skriv- och körningsbehörigheter. Dataanvändare bör inte ha åtkomst till lagringskontocontainern.
Justera med datapartitioneringsschemat. Designen för ACL och datapartition måste justeras för att säkerställa effektiv dataåtkomstkontroll. Mer information finns i Partitionering av Data lake.
Nästa steg
Datahantering och rollbaserad åtkomstkontroll för analys i molnskala i Azure