L1 BIO 17.01.03 ISO A.17.1.2 CIS Intune-BitLocker-2

BitLocker Recovery Keys Backed-up Naar Azure AD

📅 2025-10-30
•
⏱️ 6 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

BitLocker-herstelcodes moeten zonder uitzondering automatisch worden veiliggesteld in Azure AD, zodat elke organisatie direct kan reageren wanneer een medewerker zijn wachtwoord verliest, een apparaat defect raakt of de Trusted Platform Module zich onverwacht reset.

Aanbeveling
IMPLEMENT
Risico zonder
High
Risk Score
8/10
Implementatie
3u (tech: 1u)
Van toepassing op:
✓ Windows 10
✓ Windows 11
✓ Intune
✓ Azure AD

Wanneer een BitLocker-beveiligd apparaat geen herstelcode beschikbaar heeft, verandert een tijdelijk incident onmiddellijk in een crisis: het productiesysteem is ontoegankelijk, lokale gegevens zijn onbruikbaar en er rest niets anders dan herinstallatie met volledig gegevensverlies. Afdelingen verliezen kostbare tijd, crisiscommunicatie slokt het securityteam op, auditors stellen kritische vragen over sleutelbeheer en bestuurders moeten uitleggen waarom een simpele sleutel niet beschikbaar was. Door herstelcodes centraal in Azure AD op te slaan, ontstaat een gecontroleerd proces met meervoudige authenticatie, auditing van iedere sleutelopvraging en de mogelijkheid om selfserviceportalen in te richten voor scenario’s waarin gebruikers zelf verantwoordelijkheid kunnen nemen. De combinatie van versleutelde opslag, role-based access control en uitgebreide logging voorkomt dat herstelcodes alsnog een zwakke plek worden.

PowerShell Modules Vereist
Primary API: Microsoft Graph API
Connection: Connect-MgGraph
Required Modules: Microsoft.Graph.DeviceManagement, Microsoft.Graph.Identity.DirectoryManagement

Implementatie

Deze control schrijft een Intune-beleid voor dat de volledige levenscyclus van BitLocker-herstelcodes regisseert: tijdens de initiële encryptie wordt de configuratie ‘Save BitLocker recovery information to Azure Active Directory’ afgedwongen, de opslag moet plaatsvinden vóórdat de schijf daadwerkelijk wordt versleuteld en alleen 48-cijferige herstelsleutels zijn toegestaan. Het beleid verbergt lokale herstelopties zodat gebruikers de verplichting niet kunnen omzeilen, blokkeert het oudere recovery password-mechanisme en activeert sleutelrotatie zodra een sleutel is gebruikt. Daardoor is iedere sleutel die in Azure AD verschijnt aantoonbaar gekoppeld aan een apparaat, gecontroleerd toegankelijk voor bevoegde beheerders en direct beschikbaar voor hulpdiensten wanneer productie-apparatuur dreigt uit te vallen.

Vereisten

Een doordachte uitrol van BitLocker-herstelcodes richting Azure AD begint met het scherp definiëren van de randvoorwaarden. Zonder stabiele identiteitsverankering, betrouwbare licentiestructuur en toegangsbeheer dat precies aansluit bij het sleutelproces, ontstaat er een lappendeken van uitzonderingen die pas zichtbaar worden wanneer een incident zich aandient. Deze sectie beschrijft daarom hoe de technische fundamenten, organisatorische afspraken en ondersteunende infrastructuur elkaar moeten versterken voordat het beleid wordt geactiveerd.

Alle apparaten die onder dit beleid vallen moeten aantoonbaar Azure AD-joined of Hybrid Azure AD-joined zijn, omdat alleen die registratiemodellen de sleutel direct in de directory kunnen plaatsen. Het is expliciet niet toegestaan om stand-alone Active Directory domeinapparaten zonder cloudidentiteit in productie te houden, aangezien beheerders anders moeten terugvallen op manuele export en de keten van vertrouwen wordt doorbroken. De tweede pijler is volledige BitLocker-configuratie via Intune Endpoint Security-profielen: de TPM-status moet gezond zijn, de hardware moet Modern Standby ondersteunen en er moet een vooraf gevalideerd encryptieprofiel klaarstaan dat automatisch inschakelt zodra het apparaat aan de beleidsgroep wordt toegevoegd. Iedere workstation of laptop moet bovendien al in Intune zijn ingeschreven voordat de beleidsinstellingen van kracht worden. Zonder MDM-configuratie kan de opdracht om de sleutel op te slaan simpelweg niet worden afgedwongen.

Licentietechnisch zijn minimaal Azure AD Premium P1-rechten vereist (bij voorkeur P2 voor uitgebreidere auditing) in combinatie met Microsoft 365 E3 of E5, zodat zowel de identiteitsbescherming als de beheerportalen beschikbaar zijn. Voor het afdwingen van de BitLocker-profielen is de Intune Endpoint Security-add-on noodzakelijk; deze licentie geeft ook toegang tot geavanceerde rapportages waarmee naleving kan worden aangetoond tijdens audits. Tijdens de initiële encryptie en bij elke sleutelrotatie moet het apparaat de Azure AD-API's kunnen bereiken. Dat betekent dat firewallregels en webproxyconfiguraties verkeer naar login.microsoftonline.com, device.login.microsoftonline.com en graph.microsoft.com niet mogen blokkeren, zelfs niet wanneer het apparaat tijdelijk buiten het bedrijfsnetwerk opereert. Organisaties die gebruikmaken van Always On VPN of ZTNA moeten de benodigde endpoints expliciet in hun cliëntprofielen opnemen, zodat mobiele medewerkers niet onbedoeld de sleutelupload blokkeren.

De toegang tot herstelcodes is strikt geregeld via Azure AD-rollen. De Cloud Device Administrator-rol is het minimum om sleutels in te zien, maar organisaties doen er verstandig aan een aangepaste rol te creëren waarin alleen de microsoft.directory/bitlockerKeys/key/read-machtiging is opgenomen en waarbij Just-In-Time-toegang via Privileged Identity Management wordt afgedwongen. Voor kritieke incidenten moet een Global Administrator beschikbaar blijven, maar die rol mag enkel worden gebruikt als escalatiepad onder vier-ogen-principe. Tot slot hoort elke organisatie een selfserviceportaal of minimaal een helder serviceproces te publiceren zodat gebruikers weten hoe zij een sleutel aanvragen, welke verificatiestappen worden uitgevoerd en op welke manier de sleutel wordt teruggekoppeld. Het communiceren van deze procedure verlaagt de druk op de servicedesk en verkleint het risico dat collega’s informele kanalen gebruiken om herstelcodes te delen.

Naast de technische randvoorwaarden moeten procesmatige vereisten worden vastgelegd in het beveiligingsbeleid. Er moet een registratie bestaan van welke apparaten onder de regeling vallen, welke sleutelbewaartermijn geldt en welke audittrails verplicht zijn voor zowel sleutelopslag als sleutelopvraging. Verder is het zinvol om testscenario’s te plannen waarin minimaal per kwartaal een willekeurig apparaat gecontroleerd wordt op aanwezigheid van een actuele sleutel in Azure AD. Deze proef zorgt ervoor dat afwijkingen, zoals apparaten die tijdelijk offline waren tijdens de initiële versleuteling, tijdig aan het licht komen. Door deze mix van identiteitsborging, licenties, connectiviteit, rollen en procesafspraken ontstaat een fundament dat bestand is tegen zowel technische storingen als menselijke fouten.

Implementatie

De implementatie van deze maatregel draait om het feilloos laten samenwerken van Intune-profielen, Azure AD-roles en operationele draaiboeken. Voordat de eerste instelling wordt gewijzigd, inventariseren beheerders welke apparaatgroepen als eerste in aanmerking komen, welke communicatie naar gebruikers nodig is en hoe lang het maintenance-venster duurt. De focus ligt op automatisering: wanneer de policy eenmaal is gepubliceerd mag geen enkel apparaat nog afhankelijk zijn van handmatige acties om de sleutel te uploaden.

Gebruik PowerShell-script bitlocker-recovery-keys-azure.ps1 (functie Invoke-Monitoring) – PowerShell-script dat lokaal controleert of BitLocker actief is, of de sleutel naar Azure AD is geschreven en welke foutmeldingen tijdens de upload zijn geregistreerd.

Configuratie via Intune (onderdeel van BitLocker policy):

Via het Intune admin center wordt onder Endpoint security → Schijfversleuteling een nieuw BitLocker-profiel gecreëerd dat uitsluitend is gericht op sleutelbeheer. Binnen de recovery-instellingen wordt de optie ‘Save BitLocker recovery information to Azure Active Directory’ verplicht gesteld; apparaten kunnen de versleuteling niet voltooien zolang de upload mislukt. Ook de instelling ‘Store recovery information in Azure AD before enabling BitLocker’ wordt op Require gezet zodat geen enkel apparaat een tussenvariant hanteert waarbij de sleutel lokaal blijft hangen. Alleen de 48-cijferige recovery key is toegestaan; het legacy recovery password wordt geblokkeerd zodat gebruikers niet terugvallen op minder veilige mechanismen. Tijdens de gebruikerservaring worden herstelopties verborgen zodat het proces consistent verloopt ongeacht de technische vaardigheid van de eindgebruiker. Na publicatie wordt de policy gekoppeld aan dynamische Azure AD-groepen, bijvoorbeeld op basis van device trust type, waardoor nieuwe apparaten automatisch onder de regeling vallen. Vervolgens controleren beheerders in het Azure Portal per pilotapparaat of de recovery key zichtbaar is binnen de device properties. Pas wanneer de eerste tien apparaten aantoonbaar een sleutel hebben geüpload, wordt het beleid opgeschaald naar de gehele vloot. Deze aanpak voorkomt dat latente configuratiefouten zich vermenigvuldigen. Tot slot wordt client-driven key rotation geactiveerd zodat elke sleutel automatisch wordt ververst nadat een helpdeskmedewerker de code heeft ingezien.

Recovery key ophalen via Azure AD (helpdesk procedure):

De servicedesk gebruikt een gestandaardiseerd draaiboek dat is gekoppeld aan het incident- of requestmanagementsysteem. Nadat de identiteit van de aanvrager is gevalideerd (tweefactorauthenticatie plus bevestiging via leidinggevende), navigeert de medewerker in het Azure Portal naar Azure Active Directory → Devices, zoekt het betreffende apparaat op naam of serienummer en opent het tabblad Recovery keys. De sleutel wordt tijdelijk weergegeven; de medewerker kopieert de sleutel naar een vooraf goedgekeurd communicatiekanaal, bijvoorbeeld een beveiligd ticketbericht of een telefonisch doorgegeven code met meervoudige verificatie. E-mail en onverduisterde chatkanalen zijn standaard verboden. Zodra de sleutel is verstrekt, registreert de medewerker de reden, het ticketnummer en het gebruikte verificatiemechanisme zodat auditors achteraf precies kunnen herleiden waarom toegang is verleend. Dezelfde procedure schrijft voor dat de gebruiker direct na ontsluiting de BitLocker-wizard afrondt, waarna Intune de sleutelrotatie triggert en de oude sleutel ongeldig maakt. Door deze keten strak te volgen, ontstaat een reproduceerbaar proces dat bestand is tegen interne en externe controles.

monitoring

Gebruik PowerShell-script bitlocker-recovery-keys-azure.ps1 (functie Invoke-Monitoring) – PowerShell-script dat BitLocker-statussen inventariseert, locale eventlogs uitleest en de aan- of afwezigheid van Azure AD opgeslagen herstelcodes rapporteert.

Monitoring gaat verder dan een enkele controlerapportage; het vereist een continue keten van signalen die laten zien dat elk apparaat daadwerkelijk een actuele sleutel bezit en dat sleutelopvragingen op een integere manier verlopen. In deze fase worden technische telemetrie, processtatistieken en auditlogboeken samengebracht tot één verhaal dat eenvoudig kan worden gedeeld met CISO’s, auditors en dienstverleners.

Het monitoringprogramma combineert drie lagen. Op het technische vlak verzamelt Intune Compliance de status ‘Recovery key in Azure AD’ en stuurt deze naar Endpoint analytics, zodat dashboards in een oogopslag laten zien of apparaten afwijken. Daarnaast wordt een Azure Monitor Workbook gebouwd dat de Graph API raadpleegt om dagelijks een overzicht te maken van alle BitLockerKeys-objecten; apparaten die ouder zijn dan zeven dagen en nog geen sleutel tonen, worden rood gemarkeerd. Deze signalen worden gekoppeld aan een Logic Apps-workflow die automatisch een ticket opent of een Teams-melding stuurt naar het security operations center.

De tweede laag richt zich op auditlogs. Azure AD logt elke sleutelupload én elke sleutelopvraging. Door deze logs realtime naar de SIEM-oplossing te sturen, kunnen ongebruikelijke patronen – bijvoorbeeld een reeks sleutelopvragingen buiten kantooruren of door een medewerker die normaliter geen devices beheert – onmiddellijk worden onderzocht. Tevens worden maandelijks rapportages gedeeld met de privacy officer zodat zij kan toetsen of het vier-ogen-principe en de legitimeerbare grondslag per opvraging aanwezig waren. Tegelijkertijd houdt het servicedeskmanagement bij hoe vaak een sleutel is opgevraagd, hoe lang het duurde om de gebruiker te helpen en of de sleutelrotatie foutloos verliep. Deze gegevens leveren verbetervoorstellen op voor training, beschikbaarheid van uitwijkapparatuur en communicatie richting gebruikers.

De derde laag bestaat uit steekproefcontroles en kwartaalreviews. Minimaal eenmaal per maand selecteert het beheerteam willekeurig tien apparaten uit verschillende organisatieonderdelen om te testen of de sleutel correct kan worden opgehaald en of de gebruiker de sleutelrotatie terugziet. Eventuele afwijkingen worden direct gedocumenteerd en leiden tot een correctieve actie. Elk kwartaal wordt het totale percentage apparaten met een geldige sleutel afgezet tegen het aantal versleutelde apparaten; de norm ligt op honderd procent en afwijkingen worden door het lijnmanagement verklaard. Door deze drie lagen te combineren ontstaat een gesloten feedbacklus die zowel technische degradatie als procedurele overtredingen vroegtijdig detecteert.

Als extra borging wordt een Key Health Index opgesteld waarin indicatoren als ‘percentage apparaten met recente sleutel’, ‘tijd tot sleutelrotatie’ en ‘aantal sleutelopvragingen per 1.000 apparaten’ worden meegenomen. Deze index verschijnt in het maandelijkse securitydashboard en fungeert als leading indicator voor mogelijke continuïteitsproblemen. Wanneer de index onder de afgesproken drempel zakt, start automatisch een problemmanagement-proces waarin root cause-analyses, verbeteracties en bestuurlijke opvolging worden vastgelegd.

Remediatie

Gebruik PowerShell-script bitlocker-recovery-keys-azure.ps1 (functie Invoke-Remediation) – Remediatiemodule die apparaten zonder geregistreerde sleutel identificeert, BitLocker tijdelijk opschort en de upload naar Azure AD opnieuw triggert.

Remediatie start zodra monitoring aantoont dat een apparaat wel versleuteld is maar geen sleutel in Azure AD heeft. Dat scenario vereist directe actie omdat iedere reboot of hardwarewijziging het risico op onomkeerbaar verlies vergroot. Het herstelproces bestaat uit een combinatie van geautomatiseerde scripts, gebruikerscommunicatie en bestuurde escalatie voor uitzonderingen.

Het proces begint met een Graph API-query die dagelijks draait en apparaten zonder BitLockerKeys-object identificeert. Het PowerShell-script kan direct BitLocker Suspend uitvoeren, de beveiligingsconfiguratie opnieuw toepassen en een forced key backup naar Azure AD starten. Tegelijkertijd wordt in het ticketsysteem automatisch een melding aangemaakt zodat de verantwoordelijke servicelijn zichtbaar eigenaarschap heeft. Tijdens de root-causeanalyse controleert de beheerder of het apparaat daadwerkelijk Azure AD-joined is, of het tijdens de eerste encryptie internetconnectiviteit had, of de betreffende gebruiker wellicht meerdere apparaten onder dezelfde naam heeft of dat permissies zijn ingetrokken. Elk scenario krijgt een standaardoplossing: ontbrekende netwerktoegang wordt opgelost via VPN-profielen, verkeerde join-status leidt tot re-enrollment en onvoldoende rechten resulteert in een PIM-activatie voor de juiste rol.

Wanneer de automatische upload mislukt, wordt stap twee gestart: via manage-bde -protectors -adbackup C: kan de sleutel alsnog rechtstreeks naar Azure AD worden gekopieerd zonder het apparaat volledig opnieuw te versleutelen. Alleen als ook dat faalt, volgt een gecontroleerde herencryptie. Hierbij wordt BitLocker tijdelijk gepauzeerd, de configuratie opnieuw ingestuurd en geverifieerd of de sleutel ditmaal verschijnt. Mocht zelfs dat niet lukken, dan wordt het apparaat opnieuw in Intune geregistreerd en wordt de hardware gecontroleerd op TPM-fouten of BIOS-firmware die key protectors blokkeert. Elke stap wordt vastgelegd in het ticket, inclusief gebruikte commando’s, logbestanden en de naam van de uitvoerende engineer. Pas wanneer het Azure Portal de sleutel toont, mag het ticket worden afgesloten.

Ter voorkoming van herhaling analyseert het beheerteam wekelijks alle remediatickets. Ze categoriseren de oorzaken (connectiviteit, rechten, gebruiker heeft encryptie uitgesteld, defecte TPM, foutieve image) en koppelen verbeteracties terug naar het change- of releaseboard. Voorbeelden zijn het toevoegen van sleutelvalidatie aan het gouden image, het uitbreiden van onboardingchecklists met een expliciete sleutelcontrole en het inrichten van alerting op devices die langer dan twee dagen in een ‘encrypting’ status blijven hangen. Door remediatie als een volledig proces met rapportages en lessons learned te behandelen, wordt voorkomen dat dezelfde fout zich eindeloos blijft herhalen.

Ook de communicatie naar eindgebruikers maakt deel uit van de herstelstrategie. Wanneer een apparaat in remediatie staat, ontvangt de eigenaar een korte uitleg over de risico’s, de verwachte doorlooptijd en de acties die van hem of haar worden gevraagd (zoals het apparaat aan het stroomnet laten en verbonden houden met het netwerk). Hiermee wordt voorkomen dat gebruikers de herstelactie onderbreken door het device voortijdig af te sluiten of los te koppelen van de VPN. Zodra de sleutel succesvol is opgeslagen, ontvangt dezelfde gebruiker een bevestiging met het verzoek om de volgende werkdag een korte zelftest uit te voeren. Deze menselijke feedbacklus versterkt het vertrouwen in het proces en levert waardevolle signalen op over gebruikerservaringen die in toekomstige verbeteringen kunnen worden verwerkt.

Compliance en Auditing

Deze maatregel is een hoeksteen binnen vrijwel alle relevante raamwerken voor informatiebeveiliging en continuïteit. De CIS Benchmark voor Intune eist expliciet dat BitLocker-herstelcodes centraal worden opgeslagen en periodiek worden getoetst; zonder deze voorziening is het onmogelijk om aantoonbaar te maken dat dataherstel na incidenten gegarandeerd is. Binnen de Nederlandse BIO valt dit onderwerp onder Thema 17 (Continuïteit). Paragraaf 17.01 schrijft voor dat overheidsorganisaties niet alleen back-ups van data, maar ook van cryptografische sleutels moeten beheren. Zonder gedocumenteerde sleutelprocessen kan een toezichthouder concluderen dat de beschikbaarheid van vitale informatie onvoldoende geborgd is, met alle bestuurlijke gevolgen van dien. ISO 27001:2022 koppelt twee controls aan dit onderwerp. Control A.17.1.2 vereist dat procedures voor informatieback-up bestaan en in werking zijn, inclusief alternatieve locaties voor het veiligstellen van essentiële sleutels. Control A.8.24 (Use of cryptography) zoomt in op sleutelbeheer en stelt dat organisaties veilige opslag, distributie, vervanging en vernietiging van cryptografisch materiaal moeten aantonen. Door BitLocker-herstelcodes automatisch in Azure AD op te slaan, met strikte RBAC en logging, kan bij audits een sluitende keten van bewijs worden overlegd: configuraties in Intune laten zien dat opslag verplicht is, Azure AD toont de feitelijke sleutels, auditlogs bewijzen wie wanneer iets heeft ingezien en de change- en remediatieverslagen beschrijven hoe het proces beheerst blijft. In het kader van NIS2 Artikel 21 is dit control-object een belangrijk onderdeel van het vereiste risicobeheer voor essentiële en belangrijke entiteiten. De richtlijn benadrukt dat organisaties hun redundantie en disaster recovery-capaciteiten moeten aantonen. Een herstelketen zonder sleutelback-up is in strijd met deze eis, omdat een enkele TPM-fout dan kan leiden tot langdurige uitval van kritieke diensten. Door te laten zien dat herstelcodes redundant zijn opgeslagen, dat sleutelrotatie automatisch verloopt en dat incidenten worden gelogd, voldoet de organisatie aan de verwachtingen van de toezichthouder. Ook de AVG speelt een rol. Artikel 32 verlangt dat passende technische en organisatorische maatregelen worden genomen om de beschikbaarheid en veerkracht van verwerkingssystemen te verzekeren. Wanneer persoonsgegevens uitsluitend op versleutelde endpoints staan, maakt de herstelcode deel uit van de passende maatregelen. Bij het ontbreken van een sleutel kan de Autoriteit Persoonsgegevens concluderen dat er onvoldoende maatregelen zijn getroffen om persoonsgegevens tijdig te herstellen na een incident. Door herstelcodes centraal te borgen, kunnen organisaties bovendien aantonen dat gebruikersrechten zoals dataportabiliteit en inzage praktisch uitvoerbaar blijven, zelfs wanneer een apparaat niet meer opstart. Tot slot zijn er sectorspecifieke kaders. Binnen de rijksoverheid sluit deze control aan bij het Voorschrift Informatiebeveiliging Rijk (VIR) en de Richtlijnen Informatiebeveiliging Gemeenten (BIG), die beide eisen dat cryptografische sleutels aantoonbaar beheerbaar zijn. Financiële instellingen kunnen de maatregel mappen tegen DNB Good Practice Informatiebeveiliging Clouddiensten, waarin nadrukkelijk staat dat herstelprocedures inclusief sleutelbeheer getest moeten worden. Door deze maatregel te implementeren, ontstaat een consistent verhaal richting auditors: beleid, configuraties, logging, rapportage en remediatie vormen samen een toetsbaar bewijs dat sleutelbeheer volwassen is ingericht. Voor een volledige audittrail wordt aanbevolen om een compliance-pakket samen te stellen met screenshots van Intune-profielen, exports van Azure AD BitLockerKeys, kopieën van SIEM-rapportages over sleutelopvragingen en de notulen van kwartaalreviews. Dit pakket kan direct worden gedeeld met interne audit, de functionaris gegevensbescherming en externe toezichthouders, waardoor toetsingen aanzienlijk worden versneld.

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# .SYNOPSIS Intune BitLocker: Recovery Keys to Azure AD .DESCRIPTION CIS - BitLocker recovery keys moeten opgeslagen worden in Azure AD/Entra ID. .NOTES Filename: bitlocker-recovery-keys-azure.ps1|Author: Nederlandse Baseline voor Veilige Cloud|Feature: BitLocker Recovery Keys|Expected: Stored in Azure AD #> #Requires -Version 5.1 #Requires -RunAsAdministrator [CmdletBinding()]param([switch]$WhatIf, [switch]$Monitoring, [switch]$Remediation, [switch]$Revert) $ErrorActionPreference = 'Stop' function Connect-RequiredServices { $p = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent()); return $p.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) } function Test-Compliance { $r = [PSCustomObject]@{ScriptName = "bitlocker-recovery-keys-azure.ps1"; PolicyName = "BitLocker Recovery Keys"; IsCompliant = $false; CurrentValue = $null; ExpectedValue = "Stored in Azure AD"; Details = @() }; function Invoke-Revert { Write-Host "Revert via Intune" } try { $osVol = Get-BitLockerVolume -MountPoint "C:" -ErrorAction SilentlyContinue; if ($osVol -and $osVol.ProtectionStatus -eq 'On') { if ($osVol.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }) { $r.CurrentValue = "Recovery key present"; $r.Details += "Recovery key configured (Azure AD check via Intune/Entra)"; $r.IsCompliant = $true }else { $r.Details += "Geen recovery key" } }else { $r.Details += "BitLocker niet actief" } }catch { $r.Details += "Error: $($_.Exception.Message)" }; return $r } function Invoke-Remediation { Write-Host "BitLocker Recovery Keys configureren via Intune:" -ForegroundColor Yellow; Write-Host "Endpoint Security > Disk Encryption > BitLocker" -ForegroundColor Gray; Write-Host "Enable BitLocker recovery information to Azure AD" -ForegroundColor Gray; Write-Host "Store recovery passwords and keys: Enabled" -ForegroundColor Gray } function Invoke-Monitoring { $r = Test-Compliance; Write-Host "`n$($r.PolicyName): $(if($r.IsCompliant){'COMPLIANT'}else{'NON-COMPLIANT'})" -ForegroundColor $(if ($r.IsCompliant) { 'Green' }else { 'Red' }); return $r } function Invoke-Revert { Write-Host "Revert via Intune" } try { if (-not(Connect-RequiredServices)) { exit 1 }; if ($Monitoring) { $r = Invoke-Monitoring; exit $(if ($r.IsCompliant) { 0 }else { 1 }) }elseif ($Remediation) { if (-not $WhatIf) { Invoke-Remediation } }elseif ($Revert) { Invoke-Revert }else { $r = Test-Compliance; exit $(if ($r.IsCompliant) { 0 }else { 1 }) } }catch { Write-Error $_; exit 1 }

Risico zonder implementatie

Risico zonder implementatie
High: Hoog risico op permanent gegevensverlies scenario's: gebruiker vergeet wachtwoord is versleuteld device ontoegankelijk is alle data verloren. TPM chip failure is recovery key vereist is zonder backup complete gegevensverlies. Device beschadigd is data onherstelbaar zonder recovery key. Dit leidt tot productiviteitsverlies (dagen/weken werk verloren), bedrijfscontinuïteit issues (kritieke informatie onbereikbaar), gebruikersfrustatie en helpdesk overload, en potentiële compliance schendingen bij verlies van business-critical data.

Management Samenvatting

Configureer automatische backup van BitLocker recovery keys naar Azure AD als onderdeel van BitLocker policy. Recovery keys zijn essentieel voor data recovery bij wachtwoord vergeten of hardware failure. Helpdesk kan keys ophalen via Azure Portal. Voldoet aan BIO 17.01, ISO 27001 A.17.1.2. Implementatietijd: 1 uur technisch (onderdeel BitLocker policy) + 2 uur organisatorisch (helpdesk training, procedures).