Bij het ontwikkelen van moderne cloudapplicaties is het van cruciaal belang om gevoelige gegevens veilig te beheren en de toegang tot databases te controleren. Azure maakt dit eenvoudiger met Managed Identities.
In deze blog leid ik je door het proces van het beveiligen van applicaties zonder dat je gevoelige inloggegevens hoeft te beheren, met een focus op System Assigned Managed Identity en het gebruik van DefaultAzureCredential. Dit om authenticatie zowel in ontwikkel- als productieomgevingen te vereenvoudigen.
Of je nu net begint of je kennis wilt uitbreiden, ik hoop dat deze handleiding je net zo helpt als het mij heeft geholpen.
Managed Identity
Managed Identity is een Azure-functie waarmee de applicatie kan authenticeren bij andere Azure-diensten zonder hardcoded inloggegevens. Wanneer je een System Assigned Managed Identity inschakelt voor je dienst, zoals Azure App Service, beheert Azure de identiteit automatisch voor je. Deze System Assigned Identity wordt gebruikt om toegangstokens aan te vragen bij Microsoft Entra ID, waarmee je app veilig toegang krijgt tot Azure-resources.
Om te bepalen welke Azure-resources de Managed Identity kan benaderen, wordt RBAC (Role-Based Access Control) toegepast via Microsoft Entra ID (voorheen Azure AD). Je kunt rollen toewijzen, zoals Key Vault Secrets User of SQL DB Contributor, aan de Managed Identity via het gedeelte Access Control (IAM) in de Azure Portal. Dit zorgt ervoor dat je app alleen de nodige rechten heeft om met deze resources te communiceren, volgens het principe van “least privilege”. RBAC zorgt ervoor dat alleen geautoriseerde services toegang hebben tot kritieke resources, wat de beveiliging verder versterkt.
Hoe schakel je Managed Identity in via de Azure portal?
De System Assigned Managed Identity voor je app is te vinden onder Identity in de sectie Settings.
Inzicht in Microsoft Entra ID (voorheen Azure AD)
Microsoft Entra ID beheert de authenticatie voor Managed Identities. Wanneer een applicatie met een Managed Identity toegang nodig heeft tot een resource, zoals Azure SQL Database of Key Vault, stuurt het een verzoek naar Microsoft Entra ID voor een toegangstoken. Dit token wordt gebruikt om te authenticeren bij de doelresource.
Hoe het werkt:
- De applicatie vraagt een token aan bij Microsoft Entra ID.
- Entra ID verifieert de identiteit van de app en geeft, indien geautoriseerd, een OAuth 2.0-token terug.
- De app gebruikt dit token om veilig toegang te krijgen tot Azure-resources.
DefaultAzureCredential: authenticatie vereenvoudigen
De DefaultAzureCredential-klasse vereenvoudigt authenticatie over verschillende omgevingen heen. Het kiest automatisch de juiste authenticatiemethode op basis van de omgeving.
Hoe het werkt:
- In ontwikkelomgevingen gebruikt DefaultAzureCredential inloggegevens van tools zoals Azure CLI, Visual Studio of Visual Studio Code.
- In productieomgevingen gebruikt het automatisch de Managed Identity die is gekoppeld aan je Azure-dienst (zoals App Service).
Dit zorgt ervoor dat je geen authenticatiecode hoeft te wijzigen tussen verschillende omgevingen.
Belangrijke overwegingen voor ontwikkeling
Als je de applicatie lokaal draait in een ontwikkelomgeving, zorg ervoor dat:
- Je bent ingelogd bij Azure op je lokale machine, bijvoorbeeld via de Azure CLI (az login) of Visual Studio/Visual Studio Code.
- Je gebruiker is toegevoegd aan de database met de nodige toegang, zoals db_datareader, db_datawriter of db_owner, voor de Azure SQL Database die je wilt benaderen.
- Zorg ervoor dat je de juiste rol (zoals Key Vault Secrets User) hebt gekregen voor de Azure Key Vault.
In ontwikkelmodus zal DefaultAzureCredential je lokale inloggegevens gebruiken voor authenticatie, maar je moet ervoor zorgen dat de juiste rechten zijn toegekend op de Azure-resources.
Geheime sleutels beveiligen in gescheiden Azure Key Vaults voor ontwikkeling en productie
Het is een best practice om gescheiden Azure Key Vaults te onderhouden voor ontwikkel- en productieomgevingen om veiligheid en scheiding van gevoelige gegevens te waarborgen.
Met Granular Access Control kun je via Azure IAM (RBAC) striktere toegangsregels toepassen voor productiegeheimen en flexibelere toegang in de ontwikkelomgeving, zodat het principe van "least privilege" in alle omgevingen wordt gehandhaafd.
Omdat je gescheiden Key Vaults hebt voor verschillende omgevingen, moet je applicatie verwijzen naar de juiste Key Vault URI op basis van de omgeving. Je kunt bijvoorbeeld een omgevingsvariabele of configuratie-instelling gebruiken om te schakelen tussen de Key Vault URI's, afhankelijk van de omgeving waarin je app draait.
Verbinden met Azure SQL Database met Managed Identity
Nadat je de verbindingsreeks veilig hebt opgehaald uit Azure Key Vault, kan je applicatie Managed Identity gebruiken om te authenticeren en verbinding te maken met Azure SQL Database.
Voor System Assigned Managed Identity gebruikt Azure SQL Database de naam van de App Service wanneer de gebruiker in de database wordt aangemaakt. Haal eerst de App Service-naam op door de naam van de App Service te kopiëren (in het voorbeeld in Figuur 2: "AppWeb23").
Hoe configureer je je Key Vault in 3 stappen?
Ga in de Azure Key Vault-instellingen naar IAM en wijs de Key Vault Secrets User-rol toe aan de Managed Identity van je App Service.
- Wijs rollen toe
- Selecteer de Key Vault Secrets User Rol en klik ‘volgende’
- Selecteer ‘Managed Identity’, kies ‘app service’, zoek je app op en selecteer deze.
Hoe configureer je je Azure SQL Database?
Met de App Service-naam kun je een gebruiker aanmaken in de Azure SQL Database en de benodigde rollen toewijzen aan de Managed Identity.
- Maak de gebruiker aan met behulp van de App Service-naam.
- Verleen de nodige rechten aan de Managed Identity, zoals db_datareader, db_datawriter of db_owner.
Wanneer je Managed Identity gebruikt, bevat de verbindingsreeks die is opgeslagen in Azure Key Vault geen inloggegevens zoals een gebruikersnaam of wachtwoord. In plaats daarvan is het een eenvoudige verbindingsreeks die er als volgt uitziet:
De verbindingsreeks specificeert de server en database, terwijl authenticatie wordt afgehandeld via Managed Identity met het toegangstoken.
Verbinden en Data Opvragen met C#
Hier is een voorbeeld dat de verbindingsreeks uit Key Vault ophaalt, verbinding maakt met de Azure SQL Database zonder handmatig tokens op te halen, en een SELECT-query uitvoert op de database.
- De SecretClient haalt de verbindingsreeks op uit Azure Key Vault.
- De Managed Identity wordt gebruikt om te authenticeren en verbinding te maken met Azure SQL Database zonder expliciete inloggegevens.
- De databasequery wordt uitgevoerd met de verbindingsreeks die is opgehaald uit Key Vault.
Conclusie
Door gebruik te maken van Managed Identities en Azure Key Vault, kun je veilig toegang krijgen tot Azure SQL Database zonder gevoelige verbindingsreeksen of inloggegevens in je applicatie hard te coderen. Deze aanpak werkt naadloos in zowel ontwikkel- als productieomgevingen:
- In de ontwikkelomgeving: Azure AD-authenticatie gebruikt Azure CLI- of Visual Studio-inloggegevens om toegang te krijgen tot Azure SQL Database.
- In de productieomgeving: de Managed Identity van je Azure-service authenticeert direct bij Azure SQL Database.
Deze aanpak garandeert:
- Geen beheer van inloggegevens: managed Identities elimineren de noodzaak om gevoelige inloggegevens op te slaan en te beheren.
- Veilig geheimenbeheer: de verbindingsreeks wordt veilig opgeslagen in Azure Key Vault en op runtime opgehaald.
- Naadloze authenticatie: automatische, veilige authenticatie in beide omgevingen, zowel via ontwikkeltools als door de productie Managed Identity.
Het implementeren van dit patroon in je applicatie verbetert de beveiliging, vermindert het risico op datalekken en vereenvoudigt het beheer van geheimen.
Kan ik of één van mijn collega’s je helpen met het inrichten van dit proces? Neem vrijblijvend contact met ons op om de mogelijkheden te bespreken!
Heb je vragen over dit onderwerp of zou je Hugh willen inhuren voor een vergelijkbare opdracht?
Lees meer over Development
Wil je onze collega worden?
