Do napisania tego artykułu (oprócz osoby redaktora portalu WSS.pl) zainspirowało mnie zdanie, jakie przeczytałem w książce „Poradnik Administratora Windows Server 2008” (wydanej w ubiegłym roku nakładem Microsoft TechNet przy udziale trenerów z kilku ośrodków edukacyjnych). Zdanie to (strona 132.) brzmi: „Obecnie interfejs graficzny BitLockera nie daje możliwości szyfrowania dysków innych niż systemowe (zamiast szyfrowania zostało użyte słowo „szyfracja”, które niestety nie jest poprawne językowo — będę się więc posługiwał właściwym terminem).

Pomyślałem sobie, że wtedy serwer tego nie obsługiwał, ale przecież od kilku tygodni używam jako podstawy swojego środowiska Windows Server 2008 R2 w wersji Enterprise — więc tu chyba powinien zadziałać interfejs graficzny. Muszę też w tym miejscu zaznaczyć, że oczywiście BitLocker obsługiwany poprzez linię komend pozwala na szyfrowanie innych partycji. W tym artykule jednak nie zamierzam w ogóle poruszać kwestii użycia BitLockera z linii poleceń, (jeśli czytelnicy wyrażą chęć, mogę przygotować artykuł o tej funkcjonalności, bazując na Hyper-V Server 2008 - który z założenia jest jedną wielką linią komend).

Czym jest BitLocker — omówienie wymagań

Właściwa nazwa to BitLocker Driver Encryption, czyli BDE. Jest to funkcjonalność zaimplementowana w systemach Windows Server 2008, Windows Vista (w wersji Ultimate i Enterprise) oraz jak już wiemy, w nowej wersji systemu Microsoft Windows 7. Głównym jej zadaniem jest ochrona danych przechowywanych na dysku. Należy tu zauważyć, że chodzi o ochronę danych przed niepowołanym dostępem, która nie ma nic wspólnego z ochroną przed utratą danych. Tę drugą funkcjonalność zapewnia… oczywiście backup, którym dziś się nie będziemy zajmować.

Nie będę się rozpisywał marketingowo o zaletach ochrony danych i wadach ich utraty. Skupmy się tylko na owej funkcjonalności. Środowisko, które posłużyło mi do przygotowania tego artykułu, to laptop Lenovo T61 (CPU Intel Centrino Duo T8300 vPro 2,4 GHz + 4GB RAM + 160 GB HDD). Warunki, jakie musiałem spełnić, aby zainstalować system operacyjny hosta, czyli Windows Server 2008 R2 z funkcją Hyper-V, to oczywiście:

• procesor obsługujący technologię wirtualizacji (hardware’owo),
• procesor obsługujący architekturę x64 (tylko taka wersja serwera jest i będzie),
• włączony mikrochip TPM w wersji co najmniej 1.2.

Na serwerze obecnie pracuje kilka maszyn wirtualnych (oczywiście, w miarę dostępności pamięci), głównym systemem gościa jest Windows Vista 32bit Ultimate (stanowi dla mnie odpowiednik fizycznej stacji roboczej: Microsoft Office, IE8RC1, GG, Skype, Windows Live i inne standardowe aplikacje codziennego użytku). System hosta nie świadczy żadnej funkcjonalności poza dostarczaniem miejsca dla maszyn wirtualnych, udostępniania swoich zasobów, udostępniania sieci LAN i Wireless. Ten artykuł również jest pisany na maszynie wirtualnej.

Czym jest BitLocker — omówienie funkcjonalności

BDE podnosi bezpieczeństwo ochrony danych poprzez zastosowanie dwóch funkcji składowych:

• szyfrowanie partycji systemowej,
• sprawdzanie integralności przez komponenty uruchamiania systemu.

I tutaj wystąpił podstawowy (i chyba jedyny) problem, jaki dotyczy tej funkcjonalności. Cały wolumen systemowy jest szyfrowany, łącznie z plikiem wymiany i hibernacji, spełnia międzynarodowe wymagania dla organizacji rządowych zgodnych z ustawami Sarbanes-Oxley Act i HIPAA, ale…

Potrzebne są co najmniej dwie partycje. Jedna systemowa w pełni szyfrowana i zabezpieczona i druga o zalecanej wielkości 1,5 GB (!) NIEZASZYFROWANA, będąca partycją rozruchową i przechowującą klucz symetryczny VEK (Volume Encryption Key) służący do szyfrowania i deszyfrowania danych na partycji systemowej. Wprawdzie BitLocker daje nam możliwość szyfrowania partycji systemowej protokołem AES z kluczem 128 lub 256 bit, ale co z tego, skoro możemy się dostać do partycji rozruchowej. Rafał Łukawiecki, (którego osobiście uważam za jedną z ważniejszych osób w zakresie bezpieczeństwa) na jednej z konferencji skutecznie przekonał mnie do podejścia: „szyfrujemy wszystko!”.

Jak wobec tego zabezpieczyć klucz szyfrujący, który mamy na niezaszyfrowanej partycji, aby nasze dane były bezpieczne? Są dwie metody:

Pierwsza:

Wykorzystujemy moduł TPM (Trusted Platform Module) w wersji 1.2. Opracowany przez organizację Trusted Computing Group jest powszechnie implementowany przez producentów sprzętu. Założenie jego opiera się na instalacji sprzętowego modułu kryptograficznego na płycie głównej, który przy wykorzystaniu powszechnie używanych algorytmów (RSA, SHA1, HMAC, AES) będzie dokonywał operacji kryptograficznych. TPM posiada umiejętność wyliczania sumy kontrolnej z aktualnie wykonywanego przez procesor kodu w postaci tzw. ciągów SRK (Storage Root Key). Jest on używany przez BitLockera podczas uruchamiania systemu, poprzez żądanie od TPM sumy kontrolnej policzonej z kodu sekwencji startowej. To z kolei pozwala na wygenerowanie klucza VMK (Volume Master Key), który posłuży do deszyfrowania klucza VEK. Ponieważ TPM wylicza ciąg SRK każdorazowo przy starcie komputera, zmiana tego kodu (przeniesienie dysku, wymiana modułu TMP, zmiana w MBR — Master Boot Records) spowoduje, że wyliczony ciąg SRK będzie różny od wymaganego do deszyfrowania klucza VEK, co z kolei uniemożliwi uruchomienie systemu. Oczywiście, te operacje są transparentne dla użytkownika, a dodatkowo możemy użyć PIN kodu (o długości od 2 do 20 cyfr, — co nie jest szczególnie skomplikowane) do wyliczenia SRK (opcja TPM with PIN) lub klucza startowego na nośniku zewnętrznym (opcja TPM with USB).

Druga:

Używamy BDE bez modułu TPM, ale musimy pamiętać o tym, aby ów klucz przechowywać na zewnętrznym nośniku USB i każdorazowo podawać podczas uruchamiania systemu — wymaga to laptopa (serwera) umożliwiającego odczyt tych danych jeszcze na etapie rozruchowym.

Trzecia:

Trzecia metoda, niezaanonsowana wcześniej, to moja praktyka, która kłócąc się z możliwością pozostawienia partycji rozruchowej niezaszyfrowanej oraz stratą (zupełnie niepotrzebną 1,5 GB przestrzeni — nawet przy obecnych wielkościach dysków), spowodowała użycie oprogramowania firmy trzeciej (bezpłatnego, opartego w tym wypadku o protokół AES), którym zaszyfrowałem całą partycję systemową, wymagając podania silnego hasła (23 do 36 znaków alfanumerycznych i specjalnych, wprowadzanych podczas uruchamiana systemu). Oczywiście, mając w pamięci prelekcję Rafała Łukawieckiego, od jakiegoś czasu nie korzystam z hibernacji, co powoduje każdorazowo kompletne zaszyfrowanie systemu.

Szyfrowanie dysku

Starczy nudnej teorii, przejdźmy do prezentacji graficznej o tym, jak można w prosty sposób zaszyfrować partycje inne niż systemowa.

ETAP PIERWSZY:

Na początku musimy oczywiście zainstalować „ficzer” BitLocker Drive Encryption, co robimy z poziomu MMC (Microsoft Management Console) — w wersji W2K8R2 skrót do niej jest na pasku zadań (jak dla mnie doskonałość).

Rys.1. Konsola MMC z zainstalowanymi „ficzerami” i funkcją BitLocker Drive Encryption.

Kiedy wybierzemy instalację, system zrobi, co do niego należy, a następnie poprosi o restart. Po ponownym zalogowaniu się do systemu będziemy mieli już zainstalowaną funkcję.

Rys.2. Instalacja dodatku BitLocker Drive Encryption.

ETAP DRUGI:

Po zainstalowaniu funkcji możemy przystąpić do szyfrowania partycji. Z panelu kontrolnego uruchamiamy funkcję BitLocker Drive Encryption.

Rys.3. Uruchomienie funkcji BitLocker Drive Encryption z Panelu Kontrolnego.

Przy każdym dysku, który nie jest zaszyfrowany, pojawia nam się opis jego statusu. W tym wypadku dla dysku CTHOLMURGOS funkcja szyfrowania jest wyłączona. Śmiało więc klikamy na link Turn On BitLocker:

Rys.4. Niezaszyfrowany dysk twardy.

System zapyta, czy chcemy przeprowadzić ową operację. Oczywiście potwierdzamy.

Rys.5. Pytanie systemu.

Po potwierdzeniu mamy możliwość wybrania sposobu odblokowywania zaszyfrowanego dysku — możemy to zrobić albo za pomocą hasła, albo za pomocą karty inteligentnej z podaniem PIN kodu. Z uwagi na brak takowej karty (najczęściej) wybieramy hasło.

Rys.6. Wybór sposobu odblokowywania dysku.

System nie pozwoli nam ani na niepodanie hasła (podanie hasła pustego), ani nie zezwoli na hasło proste (niespełniające ogólnie przyjętych założeń haseł skomplikowanych — długość/typ znaków).

Rys.7. Ostrzeżenie o nieprawidłowości hasła.

Po podaniu właściwego hasła możemy kliknąć NEXT i system przepuści nas dalej

Rys.8. Po podaniu hasła możemy iść dalej.

Następnym i BARDZO WAŻNYM pytaniem jest to, co chcemy zrobić z kluczem do odzyskiwania. Klucz jest bardzo ważny, ponieważ bez niego w przypadku zapomnienia hasła nie jesteśmy w stanie dostać się do dysku. Mamy do wyboru zapisanie go do pliku albo wydrukowanie. Większość z nas zapewne wybierze pierwszą opcję, ale może warto się zastanowić nad wybraniem obu (nawet jeśli wydruk będzie miał miejsce po rozpoczęciu szyfrowania).

Rys.9. Wybór miejsca przechowywani klucza awaryjnego (plik lub wydruk).

Kiedy wybierzemy opcję zapisu do pliku, ważne jest, by nazwa pliku była taka sama, jak podaje system — czyli domyślna. Będzie to użyteczne podczas procesu odzyskiwania danych.

Rys.10. Wybór miejsca przechowywania pliku z kluczem awaryjnym.

Oczywiście system będąc przewidującym zapyta się nas czy aby na pewno chcemy zapisać plik (w tym wypadku na desktopie), sugerując bezpieczniejszą lokalizację – chociażby zasób sieciowy.

Rys.11. Potwierdzenie miejsca zapisania pliku awaryjnego.

Kiedy już potwierdzimy, przechodzimy do ostatniego okna, w którym możemy się jeszcze wycofać bez wpływu na środowisko. System podaje nam wszystkie ustalone wcześniej parametry, a nam nie pozostaje nic innego, jak wybrać opcję START ENCRYPTING.

Rys.12. Definitywne rozpoczęcie operacji szyfrowania wolumenu.

Ostatnie okienko to standardowy pasek postępu, z jednym małym ale: proszę nie odłączać dysku podczas szyfrowania.

Rys.1. Okienko postępu.

Gdy wrócimy do panelu sterowania, a stamtąd do funkcji BitLocker, zobaczymy, że dysk F CTHOLMURGOS jest w fazie szyfrowania.

Rys.14. Widok na BitLocker Drive Encryption.

Po zakończeniu operacji otrzymujemy okienko Encryption of F: is complete.

Rys.15. Koniec operacji szyfrowania.

I oczywiście zmienia nam się charakterystyka dysku w porównaniu z początkiem operacji (Rys. 4.).

Rys.16. Dysk jest już zaszyfrowany.

Podsumowanie

Niniejszy artykuł oczywiście nie wyczerpuje nawet w części zagadnień związanych z funkcją BitLocker w Windows Server 2008 (i Windows Vista), dlatego też w przygotowaniu jest kilka innych artykułów o tej tematyce.

BitLocker Drive Encryption powróci w części drugiej: „Typowe problemy, przerwy w szyfrowaniu, password recovery i hyper-v”.

Autor:

Tobiasz Koprowski (Anorak)
(MLS, SBS, MCP, MCSA, MCITP: Server Administrator)