Administrer BitLocker enkelt

Få en agent på hver maskin først

Konsollen kan bare administrere det den kan se. Hver PC trenger først Endpoint Central-agenten installert og rapporterer inn - uten en agent er en maskin usynlig for policyen, for nøkkelhvelvet og for hver rapport i denne veiledningen.

Sammenlign konsollens maskinliste med det kontoret faktisk eier - kjøpsposter, Active Directory-datamaskinlisten, en nettverksskanning. Enhver PC som mangler er ikke "sannsynligvis kryptert"; det er ukjent, og ukjent er risikoen. Flåtekrypteringsprosjekter mislykkes vanligvis på dette synlighetstrinnet, ikke i krypteringstrinnet – lukk gapet først.

Skriv én policy før du berører en hvilken som helst PC

Lag BitLocker-policyen sentralt i stedet for å konfigurere PC-er én etter én. En policy er én definisjon av "korrekt kryptert", og videoens gjennomgang angir avgjørelsene som betyr noe:

Beskytter: TPM låser bare opp stasjonen automatisk ved oppstart – en stjålet bærbar datamaskin når fortsatt Windows-påloggingsskjermen. TPM + PIN ber om en PIN-kode før Windows i det hele tatt starter, som er innstillingen som virkelig stopper en tyv; for bærbare datamaskiner som reiser, er det verdt den lille daglige friksjonen. Maskiner uten en TPM kan bruke en passordfrasebeskytter – et bevisst valg, aldri en ulykke.

Algorithme og omfang: XTS-AES 128 eller 256 (256 er det de fleste revisorer liker å se nedskrevet; ingen av dem blir brute-forced i praksis), og kryptering med kun brukt plass for splitter nye maskiner versus full disk for alle maskiner som allerede er i bruk, fordi "slettede" filer fortsatt holder.

Sett opp Key Escrow - og bekreft det før du håndhever noe

Hver BitLocker-stasjon har en 48-sifret gjenopprettingsnøkkel, og den dagen en PC viser den blå gjenopprettingsskjermen, er denne nøkkelen den eneste mellom brukeren og en slettet stasjon. Escrow betyr at nøkkelen samles inn automatisk og lagres der organisasjonen kontrollerer den: på Endpoint Central-serveren, med mulighet for også å sikkerhetskopiere nøkler til Active Directory eller Azure AD.

Endpoint Centrals regel er streng, og strengheten er funksjonen: kryptering starter ikke før gjenopprettingsnøkkelen er trygt lagret på serveren. En stasjon kan aldri ende opp kryptert med sin eneste nøkkel strandet på selve maskinen.

Send policyen til en pilotgruppe først

Distribuer den ferdige policyen til en liten pilotgruppe før hele kontoret – noen få maskiner du kan gå over til. Se dem bevege seg gjennom konsolltilstandene, bekrefte at hver enkelts gjenopprettingsnøkkel havnet i hvelvet, og bare deretter utvide utrullingen til grupper av maskiner (ManageEngine dokumenterer push på opptil 250 enheter om gangen). Nye maskiner kan hente policyen automatisk når de blir med, slik at flåten forblir dekket etter at prosjektet er avsluttet.

Les statustavlen – kryptert, venter, ikke-kompatibel

Herfra er jobben lesing, ikke å reise. Konsollens BitLocker Managed Computers-visning har alle administrerte maskiner i en av tre tilstander: Kryptert, Venter på kryptering eller Ikke-kompatibel. Det brettet - ikke en tur rundt på kontoret - er hvordan du svarer "hvilke av våre PC-er er fortsatt ikke kryptert?"

Arbeid gaplisten i risikorekkefølge

"Venter" og "Ikke-kompatible" er symptomer, ikke diagnoser. De vanlige årsakene: maskinen har ikke sjekket inn (av, i permisjon, agent sluttet å rapportere); en forutsetning mislyktes — konsollens forhåndsdistribusjon sjekker flaggklassikere som BIOS-modusinkompatibilitet og TPM-eierskapsfeil; maskinen har ingen TPM og det var ikke planlagt noe tilbakefall fra passordfrase; eller Windows-utgaven kan ikke gjøre BitLocker i det hele tatt - en Windows Home-maskin vil sitte i gapet for alltid til den er oppgradert eller erstattet.

Tøm listen i risikorekkefølge: bærbare datamaskiner som forlater bygningen først, deretter maskiner som har sensitive data (kontoer, HR, kunderegistre), deretter stasjonære datamaskiner i delte områder, deretter faste stasjonære datamaskiner i kontrollerte rom. Og bekreft avslutningen riktig på hver maskin: status viser Kryptert og du kan hente gjenopprettingsnøkkelen fra hvelvet. Begge - ikke en.

Bevis det – Rapporter, gjenopprettingsøvelsen og en lokal sjekk

Når brettet er rent, trekk ut krypteringsrapporten: hvilke maskiner er kryptert, med hvilken policy, og om hver stasjons nøkkel er lagret. Den rapporten er revisjonsbeviset — forskjellen mellom «vi tror vi er kryptert» og et dokument du kan overlevere.

Så repeterer du den verste dagen én gang: velg en maskin, åpne konsollens gjenopprettingsnøkkeloppslag, og hent nøkkelen slik du ville gjort under en ekte lockout. Escrow du aldri har testet er et håp, ikke et system. Gjør det samme når folk endrer seg: når en ansatt forlater, roter nøkler og få tilgang på riktig måte i stedet for å la den gamle tilgangen og de gamle nøklene være live.

Når du sitter ved én PC selv, kan du sjekke maskinens egen tilstand fra en admin-kommandoprompt:

manage-bde -status C:

Det forteller deg denne stasjonens tilstand - den sier ingenting om hvor gjenopprettingsnøkkelen bor. Hvelvet er svaret på det andre spørsmålet, og det er hele poenget med å administrere BitLocker fra én konsoll.