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 er fordi Windows 10 introduserte sin tilnærming som "Mobil først, Cloud først". Det er ingenting annet enn integrasjonen av mobile enheter med skyteknologi. Windows 10 leverer moderne administrasjon av data 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 datasikkerhet

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å vil ikke enhetene kreve 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 kryptering automatisert uten at brukerne gjorde noe. Således har Bitlocker-kryptering nå blitt Automatisk og maskinvare uavhengig.

Hvordan fungerer Bitlocker-kryptering

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

Deploys 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 løpe hver dag klokken 14.00 og vil gjøre 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 kun når den endres eller ikke er tilstede

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 på enheten, blir det en standardbruker.

Denne bifurceringen er nødvendig når en Device Enrollment Manager-konto tar seg av Azure AD-tilmeldingen før du overfører enheten til sluttbrukeren. For slike brukere har modifisert MSI (TriggerBitlockerUser) blitt gitt Windows-team. Det er litt annerledes enn for lokale adminbrukere:

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

Kopier gjenopprettingsnøkkelen til Azure AD-kontoen til brukeren som sluttet seg til enheten til AAD.
Kopier gjenopprettingsnøkkelen til Systemdrive \ temp (typisk C: \ Temp) midlertidig.

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 \ recovery-mappen.

For de ikke-lokale administrasjonsscenariene må brukerne distribuere TriggerBitlockerUser-filen via På bølgelengde til gruppen av sluttbrukere. Dette distribueres ikke til Enhetsregistreringsbehandling-gruppen / -kontoen som brukes til å bli med i enheten til 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 http://myapps.microsoft.com og naviger til profilen, eller i OneDrive for Business \ -gjenopprettingsmappen.

For mer informasjon om hvordan du aktiverer Bitlocker-kryptering, les hele bloggen på Microsoft TechNet.