Hantera BitLocker enkelt

Skaffa en agent på varje maskin först

Konsolen kan bara hantera vad den kan se. Varje PC behöver först Endpoint Central-agenten installerad och rapporterad i — utan en agent är en maskin osynlig för policyn, för nyckelvalvet och för varje rapport i den här guiden.

Jämför konsolens maskinlista med vad kontoret faktiskt äger - inköpsposter, Active Directory-datorlistan, en nätverksskanning. Alla datorer som saknas är inte "förmodligen krypterade"; det är okänt och okänt är risken. Krypteringsprojekt för flottan misslyckas vanligtvis vid det här synlighetssteget, inte vid krypteringssteget – täpp till luckan först.

Skriv en policy innan du rör vid valfri dator

Skapa BitLocker-policyn centralt istället för att konfigurera datorer en efter en. En policy är en definition av "krypterat korrekt", och videons genomgång anger vilka beslut som är viktiga:

Protector: TPM låser bara upp enheten automatiskt vid start – en stulen bärbar dator når fortfarande Windows-inloggningsskärmen. TPM + PIN ber om en PIN-kod innan Windows ens startar, vilket är inställningen som verkligen stoppar en tjuv; för bärbara datorer som reser är det värt den lilla dagliga friktionen. Maskiner utan TPM kan använda ett lösenordsskydd – ett medvetet val, aldrig en olycka.

Algorithm och omfattning: XTS-AES 128 eller 256 (256 är vad de flesta revisorer gillar att se nedskrivna; ingen av dem tvingas fram i praktiken), och kryptering med endast begagnat utrymme för helt nya maskiner jämfört med full disk för alla maskiner som redan är i drift, eftersom "tomma" filer fortfarande innehåller.

Ställ in Key Escrow - och verifiera det innan du upprätthåller något

Varje BitLocker-enhet har en 48-siffrig återställningsnyckel, och samma dag som en dator visar den blå återställningsskärmen är den nyckeln det enda mellan användaren och en raderad enhet. Escrow innebär att nyckeln samlas in automatiskt och lagras där organisationen kontrollerar den: på Endpoint Central-servern, med möjlighet att även säkerhetskopiera nycklar till Active Directory eller Azure AD.

Endpoint Centrals regel är strikt, och striktheten är funktionen: kryptering startar inte förrän återställningsnyckeln har lagrats säkert på servern. En enhet kan aldrig hamna krypterad med dess enda nyckel strandsatt på själva maskinen.

Skicka policyn till en pilotgrupp först

Distribuera den färdiga policyn till en liten pilotgrupp före hela kontoret – några maskiner du kan gå över till. Se dem röra sig genom konsoltillstånden, bekräfta att var och ens återställningsnyckel landar i valvet och först därefter bredda utrullningen till grupper av maskiner (ManageEngine-dokument pushar upp till 250 enheter åt gången). Nya maskiner kan hämta policyn automatiskt när de ansluter sig, så flottan förblir täckt efter projektets slut.

Läs statustavlan — krypterad, väntande, icke-kompatibel

Härifrån är jobbet att läsa, inte att resa. Konsolens BitLocker Managed Computers-vy innehåller alla hanterade datorer i ett av tre tillstånd: Krypterad, Väntar på kryptering eller Icke-kompatibel. Den tavlan - inte en promenad runt kontoret - är hur du svarar "vilka av våra datorer är fortfarande inte krypterade?"

Arbeta gaplistan i riskordning

"Väntande" och "Icke-kompatibel" är symtom, inte diagnoser. De vanliga orsakerna: maskinen har inte checkat in (av, ledig, agenten slutade rapportera); en förutsättning misslyckades — konsolens förinstallation kontrollerar flaggklassiker som BIOS-lägesinkompatibilitet och TPM-ägarskapsfel; maskinen har ingen TPM och ingen reserv fras planerades; eller så kan Windows-utgåvan inte göra BitLocker alls - en Windows Home-maskin kommer att sitta i luckan för alltid tills den uppgraderas eller ersätts.

Rensa listan i riskordning: bärbara datorer som lämnar byggnaden först, sedan maskiner som innehåller känsliga data (konton, HR, kundregister), sedan stationära datorer i delade områden, sedan fasta stationära datorer i kontrollerade rum. Och verifiera avslutningen korrekt på varje maskin: status visar Krypterad och och du kan hämta dess återställningsnyckel från valvet. Båda - inte en.

Bevisa det – rapporter, återställningsövningen och en lokal kontroll

När kortet är rent, dra krypteringsrapporten: vilka maskiner är krypterade, med vilken policy och om varje enhets nyckel är lagrad. Den rapporten är revisionsbeviset — skillnaden mellan "vi tror att vi är krypterade" och ett dokument du kan lämna över.

Repetera sedan den värsta dagen en gång: välj en maskin, öppna konsolens återställningsnyckelsökning och hämta nyckeln som du skulle göra under en riktig lockout. Escrow du aldrig har testat är ett hopp, inte ett system. Gör samma sak när människor byter: när en anställd lämnar, rotera nycklar och få åtkomst ordentligt istället för att lämna sin gamla åtkomst och gamla nycklar levande.

När du själv sitter vid en dator kan du kontrollera maskinens egen status från en admin-kommandotolk:

manage-bde -status C:

Det talar om för dig den här enhetens tillstånd - det säger ingenting om var dess återställningsnyckel bor. Valvet är svaret på den andra frågan, och det är hela poängen med att hantera BitLocker från en konsol.