Stel je dit scenario voor, je bouwt een applicatie en hebt een API-sleutel nodig om verbinding te maken met een service, een database-wachtwoord of een opslagaccount-sleutel. Dus je plaatst deze direct in je code, misschien in een configuratiebestand of een omgevingsvariabelen. Het werkt en alles draait prima totdat je die code naar GitHub, Pust of een notebook deelt met een teamgenoot. En zo is je geheim ineens niet zo geheim meer. Als die code in verkeerde handen valt, ligt je hele systeem bloot. Azure Key Vault is de tool die dat probleem oplost. Het biedt een veilige plek om geheimen op te slaan, zodat ze nooit in je code terechtkomen. Maar hier gaan de meeste mensen de mist in. Alleen een Key Vault hebben maakt je nog niet automatisch veilig. De manier waarop je het instelt, toegang beheert en rechten toewijst is net zo belangrijk. Aan het einde van deze aflevering weet je wat Key Vault precies is, wat je erin kunt opslaan, hoe toegang werkt en de grootste fout waardoor je geheimen blootgesteld kunnen worden.

Alles in begrijpelijke taal, zonder jargon, alleen de essentiële informatie die je nodig hebt. Dus, wat is Azure Key Vault precies? Wat is Azure Key Vault? Hier is de simpelste definitie. Azure Key Vault is een cloud-gebaseerde digitale kluis voor je geheimen. Het is een beheerde service van Microsoft voor API-sleutels, database-wachtwoorden, verbindingsreeksen, versleutelingssleutels en certificaten op één centrale plek. Je hoeft je geen zorgen te maken over de infrastructuur, want Azure regelt patching, uptime en beveiliging. Je gebruikt het gewoon, zie het als een kantoorpand. Je hebt werkstations, vergaderuimtes en archiefkasten, maar ergens in de kelder is een beveiligde kluisruimte waar je de belangrijke dingen bewaart. Hoofdsleutels, contant geld, juridische documenten. Niemand komt daar binnen zonder toestemming en authenticatie. En elke keer dat iemand de deur opent, wordt dat geregistreerd.

Dat is Key Vault. De beveiligde ruimte in de kelder van je Azure-architectuur. Vergelijk dat nu eens met de oude manier. Twintig jaar geleden, als je een database-wachtwoord nodig had, hardcodeerde je dat in een configuratiebestand. Misschien in een omgevingsvariabele, of erger, je liet het in platte tekst in je broncode staan. Als iemand toegang kreeg tot die server, hadden ze alles. En als je dat wachtwoord wilde wijzigen, moest je het overal bijwerken. Elk configuratiebestand, elke omgeving, elke implementatie. Het was een nachtmerrie. Key Vault verandert dat allemaal. In plaats van geheimen te verspreiden over je code- en configuratiebestanden, sla je ze op één centrale plek op. Je applicaties vragen ze tijdens runtime op, alleen wanneer ze ze nodig hebben. En omdat alles gecentraliseerd is, kun je een geheim op één plek roteren, waarna elke toepassing die het gebruikt automatisch de nieuwe waarde ophaalt zonder codewijzigingen of herimplementaties.

Maar het punt is, Key Vault is niet zomaar een wachtwoordbeheerder voor je apps. Het is een essentiële beveiligingsdienst. Elke Azure-dienst kan ermee integreren. App Service functies, AX, Data Factory, Synapse, Logic Apps en DevOps Pipelines weten allemaal hoe ze met Key Vault moeten communiceren. Het wordt de ruggegraad van je veilige cloud-architectuur. En zodra je het correct hebt ingesteld, hoef je helemaal niet meer na te denken over het beheer van inloggegevens. Wat kun je opslaan? Nu je weet wat Key Vault is, laten we het hebben over wat je er daadwerkelijk in kunt plaatsen. Er zijn drie hoofdcategorieën, geheimen, sleutels en certificaten. Elk heeft een andere functie en het begrijpen van het verschil helpt je om Key Vault op de juiste manier te gebruiken. Laten we beginnen met geheimen. Dit is het meest voorkomende wat mensen opslaan. Geheimen zijn verbindingsreeksen, API-sleutels, database-wachtwoorden, opslagaccount-sleutels, eigenlijk alle dagelijkse inloggegevens die je apps nodig hebben om met andere diensten te praten.

In plaats van ze in je code of configuratiebestand te plaatsen, zet je ze in Key Vault. Je app haalt ze op tijdens runtime en niemand ziet ze ooit in leesbare tekst. Zie het als een afgesloten laden in je digitale archiefkast. Vervolgens zijn er de sleutels. Dit zijn versleutelingssleutels voor data-adrest. Als je door de klant beheerde sleutels gebruikt voor Azure Storage, SQL-databases of het versleutelen van schijven van virtuele machines, kunnen die sleutels in Key Vault staan. Dat geeft je volledige controle over wie ze mag gebruiken en wanneer. En als je hardware-ondersteunde sleutels nodig hebt voor compliance, biedt de premium laag uitkomst met HSM-beveiliging. Dan hebben we nog certificaten. TLS en SSL-certificaten voor je webapps, APIs en interne diensten. Key Vault kan ze opslaan, hun levenscyclus beheren en ze zelfs automatisch vernieuwen wanneer ze bijna verlopen. Dat is een redding voor iedereen die wel eens een verlopen certificaat heeft gehad om drie uur op zondag.

Hier is een concreet voorbeeld. Stel je voor dat je een webapp hebt die een database-verbindingsreeks en een API-sleutel voor een externe dienst nodig heeft. Op de oude manier zou je beide in je JSON-bestand met app-instellingen zetten. Als dat bestand in je repository terechtkomt, kan iedereen met toegang tot de code waarschijnlijk je database-inloggegevens zien. Met Key Vault sla je beide waarden op als geheimen. Je app haalt ze op bij het opstarten en ze verschijnen nooit in je broncode. Moet je het database-wachtwoord roteren, update het in Key Vault. De app haalt de nieuwe waarden automatisch op bij de volgende herstart. Geen codewijzigingen, geen herimplementatie. Iets wat mensen vaak verrast is dat versiebeheer is ingebouwd. Wanneer je een geheim bijwerkt, overschrijft Key Vault de oude waarden niet. Het maakt een nieuwe versie aan. De oude versies blijven bewaard, zodat je kunt terugdraaien als er iets misgaat.

Dat is ongelooflijk handig tijdens incidenten. Je kunt snel terugkeren naar een vorig geheim zonder dat je de oude waarden hoeft te onthouden. Je kunt alle drie de type, geheimen, sleutels en certificaten in dezelfde kluis opslaan. Maar de best practice is om ze te scheiden per omgeving. Gebruik één kluis voor ontwikkeling, één voor testen en één voor productie. Dit voorkomt dat iemand per ongeluk een productiegeheim gebruikt in een ontwikkelomgeving... ...en beperkte schade als één kluis gecompromitteerd raakt. Maar geheimen opslaan is slechts de helft van het verhaal. De echte vraag is wie er toegang toe krijgt. Hoe toegangsbeheer werkt? Laten we het nu hebben over wie er toegang krijgt. Key Vault heeft twee verschillende manieren om toegang tot de inhoud te beheren... ...en de keuze die je maakt is erg belangrijk. Het eerste model is legacy toegangsbeleid. Dit is de oude manier. Je maakt beleid rechtstreeks op de kluis aan en wijst machtigingen toe...

...aan specifieke gebruikers of groepen voor specifieke datatypen, geheimen, sleutels of certificaten. Het probleem is dat dit beleid direct aan de kluis is gekoppeld. Als je meerdere kluizen hebt, moet je het beleid voor elke kluis afzonderlijk beheren. Het schaalt niet goed. Microsoft raadt het gebruik ervan nu af omdat er bekende beveiligingsproblemen zijn. Ze ondersteunen geen privileged identity management... ...en kunnen onverwachte paden voor privilege escalatie creëren. Het tweede model is Azure RBAC, op rollen gebaseerd toegangsbeheer. Dit is de moderne manier. Het gebruikt intra-ID identiteiten en is consistent met hoe je machtigingen overal elders in Azure beheert. Als je al weet hoe je iemand toegang geeft tot een opslagaccount of virtuele machine... ...dan weet je al hoe je toegang geeft tot Key Vault. Hetzelfde systeem, dezelfde patronen. Dit is de gouden regel, de minste bevoegdheid, least privilege.

Geef alleen de minimale toegang die iemand nodig heeft, niets meer. Als iemand alleen geheimen hoeft te lezen... ...geef ze dan geen toestemming om ze aan te maken of te verwijderen. Als iemand alleen certificaten hoeft te beheren, geef ze dan geen toegang tot sleutels. Ik loop de belangrijkste rollen even door. Je hebt Key Vault Reader. Hiermee kan iemand geheimen weergeven, maar de waarden niet lezen. Key Vault Secrets User. Hiermee kan iemand daadwerkelijk de waarden van geheimen lezen. En Key Vault Secrets Officer. Hiermee kan iemand geheimen aanmaken, bijwerken en verwijderen. Zie je het patroon? Elke rol is specifiek voor de gegevens in de kluis, niet voor de kluis zelf. Vergelijk dat nu eens met de brede rollen, eigenaar, medewerker en lezer. Deze zijn van toepassing op de kluis als resource, niet op de gegevens erin. Een eigenaar kan de volledige kluis verwijderen. Een medewerker kan de kluisinstellingen wijzigen.

Maar geen van deze rollen geeft op zichzelf toegang tot de geheimen binnenin. Dat is een aparte machtigingslaag en dat is het belangrijkste punt. Toegangsbeheer is als een gelaagde taart. Je hebt toegang nodig tot de kluis zelf, dat is de eerste laag. En toegang tot de gegevens in de kluis, dat is de tweede laag. Beiden moeten afzonderlijk worden verleend. De meeste beginners denken alleen aan de eerste laag en vergeten de tweede. Daar beginnen de problemen. De grootste beveiligingsfout. Dit is het punt. De meeste mensen kijken naar de rol Key Vault Contributor en denken dat deze veilig is. Ze zien het woord medewerker en gaan ervan uit dat ze de kluisinstellingen kunnen beheren, maar niet aan de geheimen erin kunnen komen. De eigen documentatie van Microsoft zei oorspronkelijk precies dat. Deze rol staat je niet toe om toegang te krijgen tot geheimen, sleutels of certificaten. Alleen is dat niet helemaal waar.

Een gebruiker met de rol Key Vault Contributor kan toegangsbeleid op de kluis wijzigen. En als die kluis nog gebruik maakt van verouderd toegangsbeleid, wat bij velen het geval is, dan kunnen ze zichzelf eenvoudig volledige leestoegang verlenen tot elk geheim, elke sleutel en elk certificaat binnenin. Geen speciale exploit nodig, geen kwetsbaarheid om te patchen. Het is simpelweg hoe de machten gingen werken. Beveiligingsonderzoekers bij Datadoc hebben dit in 2024 aangetoond. Ze lieten zien dat een medewerker volledige gegevenstoegang kon verkrijgen in elke kluis die verouderd toegangsbeleid gebruikt. De reactie van Microsoft was interessant. Ze zeiden dat dit geen kwetsbaarheid is omdat medewerkers ontworpen zijn om toegangsbeleid te beheren, maar ze hebben ook de documentatie bijgewerkt om expliciet te waarschuwen dat de rol zichzelf toegang tot de datavlak kan verlenen. Het is dus geen bak in Key Vault zelf, maar een configuratie-valstrik.

En het treft zelfs ervaren teams omdat de rolnaam onschuldig klinkt. Apostrof, medewerker, klinkt niet als iemand die je database-wachtwoorden kan lezen, maar in de praktijk kunnen ze dat wel. Denk eens na over het risico. Als een aanvaller een account met de rol, medewerker, op je Key Vault in handen krijgt, hoeven ze niet in te breken in de kluis. Ze hoeven de encryptie niet te kraken. Ze wijzigen gewoon het toegangsbeleid, geven zichzelf leestoegang en exfiltreren stilletjes elk geheim dat je hebt opgeslagen, verbindingsreeksen, API-sleutels, certificaten, alles. En omdat wijzigingen in het toegangsbeleid normale administratieve activiteiten zijn, activeert dit mogelijk geen waarschuwingen. Dus, wat is de oplossing? Gebruik eerst Azure RBAC voor toegang tot het datavlak in plaats van verouderd toegangsbeleid. RBAC scheidt het beheer van de kluis van de gegevens die erin staan. Ten tweede, geef de rol van Key Vault-bijdrager nooit aan iemand die deze niet absoluut nodig heeft.

Ten derde, als je al gebruikers met die rol hebt, controleer deze dan vandaag nog. Vervang de bijdragerrol door specifiekere rollen zoals Key Vault-geheimgebruiker of Key Vault-geheimbeheerder. Er is een tweede fout die dit verergert, al je geheimen in één kluis plaatsen. Als je één kluis hebt voor alles, def, test, staging, productie en al je applicaties, en die kluis wordt gecompromitteerd, dan ligt alles bloot. Het is een single point of failure. We praten zo direct verder over een Multivolt-strategie, maar het principe is simpel. Stop niet al je eieren in één mandje, zeker niet als dat mandje de sleutels van je hele infrastructuur bevat. Managed Identity, de gouden standaard. Dus, hoe pak je dit goed aan? Laten we praten over de beste manier om toegang te krijgen tot Key Vault. Er is een fundamenteel probleem. Om inloggegevens uit Key Vault te halen, moet je applicatie zichzelf authenticeren, maar voor authenticatie zijn inloggegevens nodig.

Waar sla je de inloggegevens op die je app gebruikt om inloggegevens te verkrijgen? Het is het kip-en-ei-probleem. Het oude antwoord was een service principle met een client-geheim, maar dat client-geheim moet ergens staan, misschien in een config-bestand, omgevingsvariabelen of een deployment-pipeline. En dan ben je weer terug bij hetzelfde probleem. Je hebt het geheim alleen maar ergens anders neergezet. Managed Identity lost dit volledig op. Dit is hoe het werkt. Wanneer je Managed Identity inschakelt op een Azure resource, zoals een webapp, functie of virtuele machine, maakt Azure automatisch een identiteit aan in Entra IDE. Die identiteit wordt volledig door Azure beheerd. Geen inloggegevens om aan te maken, geen geheimen om te roteren, niets om op te slaan. De resource heeft gewoon een identiteit waar Azure vanaf weet. Er zijn twee typen. Systeem toegewezen Managed Identity is gekoppeld aan één specifieke resource.

Als je de resource verwijdert, verdwijnt de identiteit ook. Ze delen een levenscyclus, wat het beheer eenvoudig maakt. Door gebruiker toegewezen Managed Identity is een losstaande identiteit die je aan meerdere resources kunt toewijzen. Deze deelt geen levenscyclus met hen, dus het is handig als je dezelfde identiteit voor meerdere services nodig hebt. Dit is hoe dat er in de praktijk uitziet. Je hebt een webapp die een database verbindingsreeks uit Key Vault moet lezen. Je schakelt systeem toegewezen Managed Identity in op de webapp. Vervolgens verleen je die identiteit de rol van Key Vault geheimgebruiker op je kluis. Dat is alles. Geen verbindingsreeksen in de code, geen clientgeheimen in conflictbestanden. De webapp verifieert bij Key Vault met behulp van zijn beheerde identiteit en Azure regelt al het beheer van inloggegevens op de achtergrond. Dit komt het dichtst in de buurt van verificatie zonder inloggegevens in Azure.

Het is een doorbraak voor beveiliging omdat het de meest voorkomende aanvalsfactor elimineert. Gestolen inloggegevens. Als er geen inloggegevens zijn om te stelen, is er niets voor een aanvaller om te compromitteren. Laat me je een praktijkvoorbeeld geven. Stel je een datapijplijn in Synapse voor die toegang nodig heeft tot een opslagaccount. Op de oude manier zou je de sleutel van het opslagaccount in de configuratie van de pijplijn opslaan. Als iemand toegang kreeg tot die pijplijn, hadden ze de sleutel. Met beheerde identiteit heeft de Synapse werkruimte een eigen identiteit. Die identiteit krijgt toegang tot Key Vault waar de sleutel van het opslagaccount is opgeslagen. De pijplijn haalt de sleutel tijdens runtime op, gebruikt deze en slaat hem nergens op. Geen sleutels in de code, geen geheimen in de configuratie van de pijplijn. Wanneer je beheerde identiteit combineert met RBAC en het principe van minimale rechten, krijg je een veilige basis voor elke Azure werkbelasting.

Je applicaties verifiëren zonder inloggegevens. Ze hebben alleen toegang tot wat ze nodig hebben en elke toegang wordt gelogd en is controleerbaar. Dit is het patroon dat Microsoft voor bijna elk scenario aanbeveelt. Zodra je het gebruikt, zul je je afvragen waarom je het ooit anders deed. Kosten en strategie voor meerdere kluizen. Laten we het dus over kosten hebben. Dit is waar de meeste mensen verrast worden. Hoeveel kost Azure Key Vault eigenlijk? Het prijsmodel is eenvoudig. Geen opslagkosten per geheim. Je betaalt niet voor elk wachtwoord of elke API-sleutel die je opslaat. In plaats daarvan betaal je per bewerking. Voor de standaardlaag is het ongeveer 3 cent voor elke 10.000 bewerkingen. Een GetSecret aanroep telt als één bewerking. Net als het aanmaken van een geheim of het bekijken van wat er in de kluis staat. Voor een typische kleine tot middelgrote applicatie komt dat neer op enkele centen per maand.

Echt letterlijk enkele centen. Vergelijk dat eens met AWS Secrets Manager. Zij rekenen 40 cent per geheim per maand alleen al voor de opslag, plus extra kosten voor API-aanroepen. Als je 100 geheimen hebt, is dat 40 dollar per maand voordat je er zelfs maar één hebt gelezen. Bij Azure Key Vault kosten 100 geheimen met gemiddeld gebruik je misschien 15 cent. Het verschil groeit snel naarmate je opschaalt. Nu is er ook een premium laag. Deze voegt HSM-ondersteunde sleutels toe voor werkbelastingen die het hoogste niveau van cryptografische zekerheid vereisen. Denk aan financiële transacties, zorgegevens, overheidssystemen. De kosten per bewerking zijn hoger, rond de 15 cent per 10.000 bewerkingen voor geavanceerde sleuteltypes, plus een maandelijks bedrag per HSM-sleutel. Maar voor de meeste applicaties is de standaardlaag meer dan voldoende. Hier is de kostenverrassing die mensen vaak overvalt.

Voor een typische webapp met een handvol geheimen en een paar duizend operaties per maand, kost Key Vault minder dan een dollar. Je bent meer kwijt aan de koffie die je drinkt tijdens het instellen. Maar er is een strategie die belangrijker is dan de kosten. Hoeveel kluizen je gebruikt? De slimme aanpak is een strategie met meerdere kluizen. Gebruik aparte kluizen voor ontwikkeling, testen, staging en productie. Dit voorkomt het meest voorkomende ongeluk. Iemand die een testscript draait dat per ongeluk een productiedtabase leest omdat de verbindingsreeks in dezelfde kluis stond. Wanneer omgevingen gescheiden zijn, wordt die fout onmogelijk. Je moet ook scheiden op basis van bedrijfsonderdeel of compliance domein. Als je betaalkaartgegevens verwerkt, zet die geheimen dan in een eigen kluis. Algemene bedrijfswerkbelastingen gaan in een andere, zorggegevens in een derde. Dit gaat niet om moeilijk doen, het gaat om het beperken van de explosieradius.

Als één kluis wordt gecompromitteerd, zijn alleen de geheimen in die kluis blootgesteld. De rest van je infrastructuur blijft veilig. En twee ingebouwde vangnetten die je altijd moet inschakelen. Apostrofe soft delete betekent dat als iemand een geheim verwijderd, het niet permanent weg is. Het gaat naar een herstelbaar status voor een bewaarperiode die je kiest, tot 90 dagen. Apostrofe purge protection gaat nog een stap verder. Niemand kan de kluis of de inhoud ervan permanent verwijderen totdat die bewaarperiode is verstreken. Samen voorkomen ze het soort onbedoeld gegevensverlies waar beveiligingsteams wakker van liggen. Hoe alles met elkaar verbonden is. Laten we dit alles samenvoegen en zien hoe de stukjes in elkaar passen. Key Vault is geen eiland. Het is het centrale zenuwstelsel voor geheimen in je Azure architectuur. Wanneer je begrijpt hoe het hele systeem stroomt, valt alles op zijn plek.

Dit is wat er gebeurt wanneer een applicatie een geheim nodig heeft. De applicatie doet het verzoek met haar beheerde identiteit. Die identiteit is al geregistreerd in Entra ID. Azure maakte die automatisch aan toen je beheerde identiteit op de resource inschakelde. Entra ID valideert dat de identiteit legitiem is en stuurt het verzoek door naar Key Vault. Key Vault controleert de RBAC-machtigingen die je hebt toegewezen. Als de identiteit de juiste rol heeft, zegt Key Vault Secrets User, wordt het geheim geretourneerd. Dit alles gebeurt in milliseconden. De applicatie ziet nooit een inlog gegeven. Het slaat nooit een wachtwoord op. Het krijgt gewoon de waarde die het nodig heeft. Denk nu eens aan hoeveel Azure services hierop kunnen aansluiten. App Service, Functions, Axe, Data Factory, Synapse, Logic Apps, DevOps Pipelines. Ze weten allemaal hoe ze met Key Vault moeten praten. Je kunt een webapp zo configureren dat deze direct in de applicatie instellingen naar een geheim verwijst.

Je kunt een Data Factory Pipeline instellen om tijdens runtime een opslagaccount-sleutel uit Key Vault te halen. Je kunt een Kubernetes-cluster configureren om secrets op te halen met de Key Vault CSI Driver. Elke service integreert op dezelfde manier, met hetzelfde identiteitssysteem, dezelfde RBAC-rollen en dezelfde audit-logging. Het CI-CD-patroon is bijzonder krachtig. Je pipelines halen secrets op uit Key Vault tijdens de implementatie. Ze slaan deze nooit op in pipeline-variabelen of repository-secrets. Als je een database-wachtwoord moet roteren, update je dit in Key Vault. De volgende keer dat je pipeline draait, pak deze automatisch de nieuwe waarde op. Geen pipeline-wijzigingen, geen codewijzigingen, geen herimplementaties. Dit is wat het allemaal op zijn plek laat vallen. Zodra je Key Vault instelt met Managed Identity en RBAC, hoef je niet meer na te denken over het beheer van inloggegevens.

Je applicaties werken gewoon. Secrets worden geroteerd zonder dat iemand het merkt. Certificaten worden vernieuwd zonder nachtelijke noodgevallen. Het systeem regelt alles op de achtergrond. Dit is de beveiligingshouding die ertoe doet. Identiteit is de perimeter, niet het netwerk. Het maakt niet uit of iemand zich binnen of buiten je virtuele netwerk bevindt. Wat telt is of ze een geldige identiteit hebben met de juiste rechten. Key Vault dwingt dit af door het ontwerp. Elk toegangsverzoek verloopt via Entra ID-authenticatie en RBAC-autorisatie, ongeacht waar het verzoek vandaan komt. En alles wordt gelogd. Elke secret lezing, elke sleuteloperatie, elke certificaat opvraging. Je kunt zien wie wat wanneer heeft geopend. Als iets er verdacht uitziet, heb je de gegevens om het te onderzoeken. Dit is cruciaal voor compliance, incident response en om te weten wat er in je omgeving gebeurt. Dat is de schoonheid van dit alles.

Key Vault, Entra ID, RBAC en Managed Identity werken samen als een uniform beveiligingsframework. Elk onderdeel versterkt de andere. En als alles correct is ingesteld, heb je een beheersysteem voor inloggegevens dat veiliger en eenvoudiger is dan wat je zelf zou kunnen bouwen. Concrete actiepunten. Dus wat moet je nu daadwerkelijk doen? Laten we deze kennis omzetten in actie. Dit zijn de dingen die je deze week kunt aanpakken. Begin bij je toegangsmodel. Open je Key Vault in de portal, ga naar de configuratie van toegang en kijk wat daar staat. Als je Vault Access Policy ziet, is dat de oude methode. Je wilt in plaats daarvan Azure oprollen gebaseerd toegangsbeheer, RBAC. De migratie is eenvoudig. Schakel het toegangsmodel om en wijs RBAC rollen toe aan dezelfde personen die al toegangspolicies hadden. Doe het vandaag nog. Microsoft raadt het aan en het onderzoek waar we over spraken liet precies zien waarom.

Controleer vervolgens alle accounts met de Key Vault Contributor-rol. Open het IAM-blad op je Vault en kijk wie Contributor toegang heeft. Iedereen met die rol moet een goede reden hebben. Meestal is dat niet zo. Vervang Contributor door iets specifiekers. Als iemand alleen geheimen moet lezen, geef ze dan Key Vault Secrets User. Als ze geheimen moeten beheren, gebruik dan Key Vault Secrets Officer. Het doel is om dat escalatiepad volledig te sluiten. Maak vervolgens gebruik van Managed Identity. Elke Azure service die toegang nodig heeft tot Key Vault, zou dit moeten gebruiken. Als je een webapp, functie, data factory of virtuele machine hebt die nog een service principle met Client Secret gebruikt, stap dan over op Managed Identity. Het is eenvoudiger, veiliger en lost het kip- en ei-probleem op dat we bespraken. Azure regelt het beheer van inloggegevens achter de schermen voor je. Nog één ding, schakel Soft Delete en Purge Protection in voor elke kluis.

Soft Delete staat standaard aan voor nieuwe kluizen, maar Purge Protection niet. Zet het aan. Die instelling voorkomt dat iemand tijdens de bewaarperiode een kluis of de inhoud ervan definitief verwijdert. Het heeft meer dan één team gered van een rampzalige fout. Hier is je oproep tot actie. Bekijk je huidige aanpak voor het beheer van geheimen. Zoek één geheim dat nog in een configuratie bestand, een omgevingsvariabele of hardcode in de code staat. Verplaats het deze week naar Key Vault. Slechts één. Zodra je ziet hoe eenvoudig het is, zul je de rest ook willen verplaatsen. Beveiliging is geen eenmalige configuratie. Het is een proces. Key Vault maakt dat proces makkelijker, maar alleen als je het correct gebruikt. De tools zijn aanwezig. De patronen zijn bewezen. Nu is het aan jou om ze te implementeren. Dat is het systeem. Key Vault is je digitale kluis, maar het is slechts zo veilig als de toegangscontroles die je eromheen plaatst.

Begin met de adden die ik net beschreef. Controleer je rechtenmodel. Controleer je contributortoewijzingen en verplaats deze week één geheim naar een kluis. Abonneer je voor meer cloudbeveiligingstips in begrijpelijke taal en deel dit met iemand die nog steeds geheimen opslaat in configuratiebestanden.