Bitlocker kryptering ved hjelp av AAD / MDM for Cloud Data Security

Med Windows 10s nye funksjoner har produktiviteten til brukere økt hopp og grenser. Det skyldes at Windows 10 introduserte sin tilnærming som "Mobile first, Cloud first". Det er ingenting annet enn integrasjonen av mobile enheter med skyteknologi. Windows 10 leverer moderne datahåndtering ved hjelp av skybaserte enhetsadministrasjonsløsninger som Microsoft Enterprise Mobility Suite (EMS) . Med dette kan brukerne få tilgang til data fra hvor som helst og når som helst. Denne typen data trenger imidlertid også god sikkerhet, som er mulig med Bitlocker .

Bitlocker kryptering for cloud data security

Bitlocker krypteringskonfigurasjon er allerede tilgjengelig på Windows 10 mobile enheter. Imidlertid måtte disse enhetene ha InstantGo mulighet til å automatisere konfigurasjonen. Med InstantGo kan brukeren automatisere konfigurasjonen på enheten, samt sikkerhetskopiere gjenopprettingsnøkkelen til brukerens Azure AD-konto.

Men nå trenger ikke enhetene InstantGo-funksjonen lenger. Med Windows 10 Creators Update, vil alle Windows 10-enheter ha en veiviser der brukere blir bedt om å starte Bitlocker-kryptering, uavhengig av hvilken maskinvare som brukes. Dette var hovedsakelig resultatet av brukerens tilbakemelding om konfigurasjonen, der de ønsket å få denne krypteringen automatisert uten at brukerne gjorde noe. Således er Bitlocker-kryptering nå automatisk og maskinvare uavhengig.

Hvordan fungerer Bitlocker-kryptering

Når sluttbrukeren registrerer enheten og er en lokal administrasjon, TriggerBitlocker MSI gjør følgende:

• Bruker tre filer til C: Program Files (x86) BitLockerTrigger
• Importerer en ny planlagt oppgave basert på den medfølgende Enable_Bitlocker.xml

Den planlagte oppgaven vil kjøre hver gang dag klokken 14.00 og gjør følgende:

• Kjør Enable_Bitlocker.vbs som hovedformålet er å ringe Enable_BitLocker.ps1 og sørg for å kjøre minimert.
• I sin tur vil Enable_BitLocker.ps1 kryptere den lokale stasjonen og lagre gjenopprettingsnøkkelen i Azure AD og OneDrive for Business (hvis konfigurert)
  • Gjenopprettingsnøkkelen lagres bare når den endres eller ikke er til stede

Brukere som ikke er en del av den lokale administrasjonen, må følge en annen prosedyre. Som standard er den første brukeren som slutter seg til en enhet til Azure AD, medlem av den lokale administrasjonsgruppen. Hvis en annen bruker, som er en del av samme AAD-leietaker, logger seg på enheten, vil den være en standardbruker.

Denne bifurkasjonen er nødvendig når en Enhetsregistreringskonto tar seg av Azure AD-tilmeldingen før avlevering over enheten til sluttbrukeren. For slike brukere har modifisert MSI (TriggerBitlockerUser) blitt gitt Windows-team. Det er litt annerledes enn for lokale admin-brukere:

Den planlagte oppgaven for BitlockerTrigger kjøres i systemkonteksten og vil:

• Kopier gjenopprettingsnøkkelen til Azure AD-kontoen til brukeren som sluttet seg til enheten til AAD.
• Et nytt skript MoveKeyToOD4B.ps1 er introdusert

og kjører daglig via en planlagt oppgave kalt MoveKeyToOD4B . Denne planlagte oppgaven kjører i brukernes sammenheng. Gjenopprettingsnøkkelen flyttes fra systemdrive temp til OneDrive for Business -gjenopprettingsmappen. For de ikke-lokale administrasjonsscenariene må brukerne distribuere TriggerBitlockerUser-filen via

Intune til gruppen av slutt -brukere. Dette blir ikke distribuert til Enhetsoppføringsbehandling-gruppen / -kontoen som brukes til å bli med i Azure-AD. For å få tilgang til gjenopprettingsnøkkelen, må brukerne gå til en av følgende steder:

Azure AD-konto

• En gjenopprettingsmappe i OneDrive for Business (hvis konfigurert).
• Brukere foreslås å hente gjenopprettingsnøkkelen via

//myapps.microsoft.com og naviger til profilen, eller i deres OneDrive for Business -gjenopprettingsmappe. For mer informasjon om hvordan du aktiverer Bitlocker-kryptering, les hele bloggen på Microsoft TechNet.