Bezpieczeństwo systemów plików

Gdyby zarządzanie systemami było cyrkiem o trzech arenach — a kiedy nie jest? — numerami najbardziej przyciągającymi uwagę byłyby Bezpieczeństwo, Pewność działania i Wydajność. Byłoby idealnie, gdyby zainteresowanie publiczności podzielone było pomiędzy nie po równo, ale wobec tego, że widownia składa się głównie z poirytowanych użytkowników, udręczonych menedżerów i wymagających klientów, ich uwaga skupia się na Pewności działania i Wydajności. Biedne, stare Bezpieczeństwo pozostawiono na tylnej arenie razem z bezzębnym tygrysem i klaunem z chorym kręgosłupem. A przynajmnej do czasu, kiedy niezrównoważony pracownik skasuje pliki działu księgowości z ostatnich trzech lat i umknie do Macedonii. Wtedy to Bezpieczeństwo zostanie wprowadzone uroczyście z fanfarami na centralną arenę.

Poruszone w poprzednich rozdziałach zagadnienia związane z bezpieczeństwem opisują strategie i kolejne kroki budowania silnej obrony na granicach (rozdz. 6., „Bezpieczeństwo dostępu do sieci i Kerberos”), a następnie rozszerzenie obrony do wewnątrz, i ochrona najważniejszych informacji (patrz rozdz. 10). Ale użytkownicy po skonfigurowaniu i zalegalizowaniu mogą swobodnie wędrować poprzez pliki i foldery w każdym z zasobów współdzielonych sieci. Należy zwrócić uwagę również na inne zabezpieczenia, niż zasuwy na drzwiach, a mianowicie kłódki na szafach z dokumentami i przy biurkach. Nadszedł już czas na omówienie nadawania uprawnień w systemie plików NTFS.

Dobra strategia bezpieczeństwa nie polega wyłącznie na kontrolowaniu dostępu do plików i folderów. Jeśli szafa na dokumenty zawiera tylko rzeczy bezużyteczne, to nikt nie zawracałby sobie głowy włamywaniem do niej. W Windows 2000 istnieje zabezpieczenie oparte na systemie plików NTFS o nazwie System Szyfrowania Plików (Encrypting File System —EFS), które umożliwia użytkownikom szyfrowanie swoich plików w taki sposób, że tylko osoba, która zaszyfrowała plik, może go potem otworzyć ponownie.

Dostęp administratora do plików zaszyfrowanych

Wiem, co myślisz o plikach zaszyfrowanych. Myślisz zapewne: „Co ten Microsoft zrobił? Dali do rąk przeciętnego użytkownika narzędzie, dzięki któremu można całkowicie utracić dostęp do pliku". Na szczęście nie jest to prawda. Istnieją tylne drzwi, które umożliwiają zaufanym administratorom dostęp do plików zaszyfrowanych w razie, gdyby użytkownik, który zaszyfrował plik zwolnił się, umarł lub po prostu stracił orientację jak otworzyć taki plik.

W tym rozdziale omówiono nadawanie i zmianę uprawnień NTFS oraz system szyfrowania plików (Encrypted File System — EFS). Oto lista tematów dotyczących uprawnień NTFS:

• Przegląd uprawnień plików i katalogów NTFS, zawierający omówienie list kontroli dostępu (access control lists), uprawnień standardowych i dziedziczenia uprawnień.

• Strategie i sposoby wykorzystania uprawnień NTFS do zarządzania plikami i katalogami, stosując również wiersz poleceń.

• Konfigurowanie inspekcji plików i katalogów (file and directory auditing).

• Metody zmiany prawa własności plików.

Omówienie systemu szyfrowania plików (Encrypting File System — EFS) obejmuje:

• Opis szyfrowania plików i katalogów, zawierający szczegółowe informacje o ochronie za pomocą klucza z wykorzystaniem usług kryptograficznych z kluczem publicznym (Public Key Cryptographic Services —PKCS).

• Zarządzanie osobistymi certyfikatami PKCS.

• Odzyskiwanie plików zaszyfrowanych w przypadku, jeśli nie istnieje już użytkownik, który je zaszyfrował.

• Ochrona certyfikatów PKCS, aby zapobiec narażeniu na szwank plików zaszyfrowanych.

• Zapisywanie plików zaszyfrowanych na serwerach zaufanych do delegowania (trusted delegation server).

• Poszerzenie działalności serwerów Jednostka certyfikująca (Certification Authority — CA) o wydawanie certyfikatów PKCS.

Przegląd uprawnień NTFS dotyczących plików i katalogów

Podczas logowania się użytkownika do komputera z Windows 2000, lokalny autorytet bezpieczeństwa (Local Security Authority — LSA) tworzy żeton dostępu (access token), który zawiera identyfikator bezpieczeństwa użytkownika (Security ID — SID) oraz identyfikatory SID grup lokalnych, globalnych i grup powszechnego bezpieczeństwa, do których należy użytkownik dla każdej domeny. Żeton dostępu zawiera także dobrze znane identyfikatory SID użytkowników należących do grup Authenticated Users i Everyone.

Każdy proces przebiega w środowisku bezpieczeństwa (security context) użytkownika, który go uruchomił, co oznacza, że ten proces zawiera kopię żetonu dostępu danego użytkownika. Proces, odwołując się do obiektu zabezpieczonego (security object), takiego jak plik, folder, klucz Rejestru lub obiekt Active Directory, przedstawia żeton dostępu użytkownika. Monitor stosunków bezpieczeństwa (Security Reference Monitor —SRM) porównuje zawartość żetonu dostępu z zawartością listy kontroli dostępu (Access Control List — ACL), mieszczącej się w deskryptorze bezpieczeństwa (security descriptor) danego obiektu. Lista kontroli dostępu (ACL) składa się z jednej lub kilku pozycji kontroli dostępu (Access Control Entries — ACEs), które identyfikują obiekty typu security principal, mające zezwolenie na dostęp do danego obiektu lub takowego zezwolenia nie mające. Każda z pozycji kontroli dostępu (ACE) zawiera zestaw uprawnień, definiujących, co może, a czego nie może robić obiekt z kategorii security principal z danym obiektem.

Każdy proces przebiega w środowisku bezpieczeństwa (security context). Dla większości usług działających w tle środowiskiem bezpieczeństwa jest system lokalny (Local System). Środowisko bezpieczeństwa (security context) dla danej usługi można ustalić otwierając konsolę Services (Usługi), klikając prawym klawiszem myszy na jednej z uruchomionych usług i wybierając opcję Properties (Właściwości). Mając otwarte okno Properties (Właściwości), wybierz zakładkę Log on (Logowanie), aby zobaczyć konto używane przez daną usługę. Rys. 14.1 prezentuje właściwości logowania dla usługi Server.

Rysunek 14.1. Właściwości usługi Server pokazujące, że usługa pracuje w środowisku Komputer Lokalny

Można spotkać usługi działające w innych środowiskach bezpieczeństwa niż Local System. Przykładami mogą być programy archiwizacji danych i programy antywirusowe. Podczas instalowania takich aplikacji tworzone są specjalne konta użytkowników. Stanowią one środowisko bezpieczeństwa (security context) dla aplikacji. Sprawdzając właściwości aplikacji, zamiast nazwy system lokalny (Local System) pojawi się nazwa konta użytkownika. Jeśli to konto zostałoby skasowane lub zmieniono by hasło bez powiadomienia o tym aplikacji, wtedy dana aplikacja przestanie działać.

Budowa deskryptora bezpieczeństwa

Pliki i foldery są obiektami chronionymi i dlatego mają przyporządkowane deskryptory bezpieczeństwa. Rekord tablicy MFT, określający zawartość pliku lub folderu, zawiera wskaźnik do atrybutu $Security_Descriptor, który zawiera następujące elementy:

• Identyfikator właściciela (owner ID). Każdy obiekt chroniony ma właściciela. Jest to spełnienie wymagań stopnia ochrony C-2 Departamentu Obrony USA. Pole Identyfikator właściciela zawiera identyfikator bezpieczeństwa (SID) właściciela.

• Identyfikator grupy (group ID). Wykorzystywany tylko przez POSIX.

• Uznaniowa lista kontroli dostępu (Discretionary Access Control List — DACL lub inaczej Discretionary ACL). Zawiera pozycje kontroli dostępu (Access Control Entry) dla każdego obiektu typu security principal. W każdej pozycji ACE wpisany jest identyfikator bezpieczeństwa obiektu security principal i maska dostępu (access mask), opisująca, do czego ten obiekt security principal jest uprawniony, a do czego nie. Z obiektami NTFS związanych jest trzynaście podstawowych uprawnień. Lista ACL może zawierać do 1820 ACE.

• Systemowa lista kontroli dostępu (System Access Control List — SACL lub inaczej System ACL). Jest wykorzystywana do kontroli przeprowadzania inspekcji (auditing). Każda pozycja ACE w liście ACL otrzymuje uprawnienie SystemAudit dla wszystkich uprawnień NTFS lub dla jednego z nich.

Wspólna własność obiektów grupy Administrators

W większości przypadków identyfikator bezpieczeństwa (SID) w polu deskryptora bezpieczeństwa o nazwie identyfikator właściciela (Owner ID) określa użytkownika, który utworzył dany plik lub folder. Jedynym wyjątkiem jest prawo własności plików i folderów utworzonych przez członków lokalnej grupy Administrators.

Kiedy członek grypu lokalnej Administrators tworzy plik lub folder, prawo własności jest przypisane do identyfikatora bezpieczeństwa (SID) grupy Administrators, co pozwala każdemu administratorowi w domenie mieć dostęp do plików, folderów i obiektów Directory innych administratorów.

Maska dostępu przypisana obiektowi security principal zawiera trzy rodzaje uprawnień: standardowe (Standard), specjalne (Special) i ogólne (Generic).

• Uprawnienia standardowe. Te uprawnienia mają zastosowanie do każdego obiektu chronionego Windows 2000, nie tylko do plików i katalogów, ale na przykład do takich obiektów, jak: Delete, Read_control, Synchronize (specjalne wykorzystanie programowe), Write_DAC (modyfikacja listy DACL) czy Write_Owner. Te określenia nie pojawiają się poprzez interfejs użytkownika (UI), ale można je zobaczyć w komunikatach o błędach lub wykorzystując narzędzia wiersza poleceń.

• Uprawnienia specjalne. Te uprawnienia mają specjalne przeznaczenie i mają zastosowanie tylko do obiektów NTFS. Wykaz uprawnień i ich funkcje znajdują się w paragrafie „Standardowe uprawnienia NTFS”.

• Uprawnienia ogólne. Te uprawnienia są wzorcami przedstawiającymi zbiór uprawnień standardowych i specjalnych. Uprawnienia ogólne upraszczają programowanie.

Lista ACL może zawierać wiele pozycji ACE. Obiekt kategorii security principal może mieć kilkanaście pozycji ACE na tej samej liście ACL i może być członkiem grup reprezentowanych przez inne pozycje ACE. Maski dostępu (access mask) dla każdej pozycji ACE Zezwolenie na dostęp (Access Allowed) są łączne, to znaczy uprawnienia związane z daną pozycją ACE sumują się z uprawnieniami zapisanymi w innych pozycjach ACE.

Na przykład weźmy pod uwagę dwie grupy: Yin i Yang. Obydwie grupy znajdują się w liście ACL dla foldera. Grupa Yin ma uprawnienie Read, grupa Yang ma uprawnienie Write. Jeśli użytkownik należy do obu grup, otrzymuje uprawnienia dostępu do foldera Read i Write.

Własność odwrotną ma maska ACE Odmowa dostępu (Access Denied). Maski te są rozłączne. Przyjmijmy, że grupie Yin przypisano uprawnienie Full Control, a grupie Yang przypisano maskę ACE Odmowa dostępu (Access Denied) do uprawnienia Write. W tym przypadku użytkownik należący do obu grup miałby dostęp do foldera i mógłby przeglądać pliki i czytać z nich, ale nie mógłby tworzyć nowych plików, folderów ani modyfikować istniejących plików.

Jeśli obiekt typu security principal nie znajduje się na liście ACL danego obiektu ani nie jest członkiem żadnej grupy z listy ACL, nie ma prawa dostępu. Jest to tak zwana domniemana odmowa dostępu (Implicit Deny ACE). Domniemana odmowa dostępu jest ważnym pojęciem związanym z uprawnieniami NTFS. W przypadku usunięcia wszystkich pozycji ACE z listy ACL dla folderu, nikt nie będzie miał do niego dostępu.

„Pusta” lista ACL kontra „Zerowa” lista ACL

Jedynym niuansem dotyczącym domniemanej odmowy dostępu jest to, że stosuje się tylko do obiektów NTFS z pustą listą ACL. Możliwe jest stworzenie obiektu NTFS bez listy ACL w deskryptorze bezpieczeństwa (security descriptor). „Zerowa” lista ACL daje rezultat odwrotny do pustej listy ACL. „Zerowa” lista ACL zakłada uprawnienie Full Control dla wszystkich obiektów typu security principal. Dzięki dziedziczeniu uprawnień lista ta nie jest często spotykana w komputerach z Windows 2000.

Standardowe uprawnienia NTFS

Zawartość deskryptora bezpieczeństwa obiektu NTFS jest przedstawiona w oknie Właściwości (Properties) dla plików i folderów. Otwórz okno Właściwości (Properties), klikając prawym klawiszem myszy na ikonie pliku lub folderu i wybierając z menu opcję Właściwości (Properties). Następnie, aby zobaczyć zawartość listy ACL, wybierz zakładkę Bezpieczeństwo (Security). Rysunek 14.2 przedstawia przykład dotyczący katalogu \WINNT.

Rysunek 14.2. Okno Właściwości (Properties) folderu \WINNT przedstawiające zakładkę Bezpieczeństwo (Security) i listę kontroli dostępu (ACL) dla tego folderu.

Jeśli po otwarciu okna Właściwości (Properties) pliku lub folderu nie ma w nim zakładki Zabezpieczenia (Security), to oznacza, że wolumin został sformatowany jako FAT lub FAT32 albo użytkownik nie ma uprawnienia do oglądania deskryptora bezpieczeństwa (security descriptor). Jeśli lista ACL pokazuje identyfikatory bezpieczeństwa (SID) zamiast nazw, przeczytaj poniższe informacje.

ACL zawiera same identyfikatory bezpieczeństwa (SID)

Wykaz użytkowników w liście ACL może pokazywać jeden lub więcej identyfikatorów bezpieczeństwa (SID) zamiast nazw. Taki stan rzeczy może mieć kilka przyczyn:

• Komputer nie mógł połączyć się z kontrolerem domeny, aby przetworzyć SID na nazwę użytkownika.

• Konto jest w innej domenie, a relacja zaufania pomiędzy domenami została przerwana.

• Komputer lokalny został usunięty z domeny albo lokalna relacja zaufania pomiędzy komputerem a domeną została przerwana.

• Konto użytkownika zostało usunięte z domeny, ale nie usunięte z lokalnej listy ACL.

W każdym przypadku pojawienie się identyfikatorów bezpieczeństwa (SID) zamiast nazw użytkowników jest objawem jakiegoś problemu. Nie wolno tego lekceważyć. Jeśli administrator nie ma dostępu do pliku lub katalogu właśnie z takiego powodu, może przejąć ten plik lub katalog na własność, wpisując siebie albo grupę Administrators na listę ACL. Szczegóły podano w paragrafie „Zmiana własności pliku”.

Podczas przewijania listy nazw pozycje na liście Uprawnienia (Permissions) zmieniają się, prezentując uprawnienia przypisane do danego obiektu z kategorii security principal. W tablicy 14.1 zamieszczono wykaz standardowych uprawnień i dozwolonych działań.

Tablica 14.1. Standardowe uprawnienia NTFS i dozwolone działania

Uprawnienia	Dozwolone działania — pliki	Dozwolone działania — foldery
Full Control	Łączy wszystkie uprawnienia	Łączy wszystkie uprawnienia
Modify	Wszystkie działania z wyjątkiem Usuń, Zmiana uprawnień oraz Przejęcie własności	Wszystkie działania z wyjątkiem Usuń plik lub podfolder, Zmiana uprawnień oraz Przejęcie własności.
Write	Zmiana lub dopisywanie danych do pliku	Tworzenie plików lub folderów
Read & Execute	Otwieranie i czytanie plików, uruchamianie plików wykonywalnych lub plików wsadowych	Przeszukiwanie plików w danym katalogu, uruchamianie plików wykonywalnych lub plików wsadowych
List Folder Contents	Nie dotyczy plików	Złożenie uprawnień Read i Read & Execute

Do każdego pliku lub katalogu można przypisać maksymalnie trzynaście uprawnień. Podane powyżej standardowe uprawnienia są wzorcami przedstawiającymi podzbiór tych uprawnień. Na przykład, jeśli lista uprawnień dla danego obiektu typu security principal jest pusta, oznacza to, że do danego konta przypisano specjalne uprawnienia, które nie są pokazywane na liście standardowej. Po zaznaczeniu obiektu security principal, któremu nadano dodatkowe uprawnienia, obok przycisku Zaawansowane (Advanced) pojawi się komunikat „Nadano dodatkowe uprawnienia, ale nie są tu uwidocznione. Aby je zobaczyć naciśnij Zaawansowane” (Additional permissions are present but not viewable here. Press Advanced to see them). W razie kłopotów z wybieraniem uprawnień w głównym oknie Zabezpieczenia (Security), należy poszukać tego komunikatu. Oznacza on, że jakaś kombinacja uprawnień specjalnych nie zezwala na dokonywanie wyboru z listy ogólnej.

Podgląd uprawnień zaawansowanych NTFS

Mając otwarte okno Właściwości (Properties) z zakładką Bezpieczeństwo (Security) dla danego pliku lub folderu, naciśnij przycisk Zaawansowane (Advanced). Otworzy się okno Ustawienia kontroli dostępu (Access Control Settings). Przykład zamieszczono na rysunku 14.3.

Rysunek 14.3. Okno Ustawienia kontroli dostępu (Access Control Settings) pokazujące zakładkę Uprawnienia (Permissions).

Wykaz uprawnionych (Permission Entries list) zamieszczony w tym oknie zawiera wszystkie pozycje ACE z listy ACL. Niektóre obiekty security principal mogą mieć więcej niż jedną pozycję ACE. Przyjrzyjmy się bliżej kolumnom wykazu uprawnionych (Permission Entries list).

• Rodzaj (Type). Ta kolumna podaje rodzaj ACE, Pozwól (Allow) lub Odmów (Deny). Pozycja ACE typu Odmów (Deny) ma zawsze pierwszeństwo przed ACE typu Pozwól (Allow). Brak pozycji ACE dla danego identyfikatora bezpieczeństwa (SID) oznacza typ Odmów (Deny). Na przykład, jeśli identyfikator bezpieczeństwa (SID) użytkownika Tjones nie znajduje się na liście kontroli dostępu (ACL) i Tjones nie jest członkiem grupy będącej na tej liście, to wtedy Tjones nie ma dostępu do pliku ani do folderu.

• Nazwa. Ta kolumna pokazuje nazwę konta odpowiadającą identyfikatorowi bezpieczeństwa (SID) w pozycji ACE. Uzyskanie nazwy konta wymaga przeszukania Active Directory, jeśli komputer jest członkiem domeny, albo lokalnej bazy danych SAM, jeśli jest to komputer niezależny.

• Uprawnienie (Permission). Ta kolumna zawiera wyrażenie opisujące maskę dostępu (access mask) przyporządkowaną pozycji ACE. Wykaz pokazuje tylko wzorce uprawnień. Jeśli istnieje uprawnienie, które nie jest zgodne z wzorcem, w wykazie pojawi się napis Uprawnienia specjalne (Special Permission).

• Zastosuj do (Apply To). Ta kolumna pokazuje sposób dziedziczenia przypisany ACE. Dziedziczenie uprawnień zostanie omówione w następnym paragrafie. Mówiąc w skrócie, uprawnienia ACE przypisane do foldera są dziedziczone przez pliki i podfoldery tego folderu. Dziedziczenie upraszcza zarządzanie katalogami o wielu poziomach poprzez automatyczne przekazywanie pozycji ACE.

Przegląd uprawnień zaawansowanych NTFS

Po dwukrotnym kliknięciu na nazwie konta w wykazie uprawnionych (Permission Entries list) otworzy się okno Uprawnienia (Permission Entries) tego konta.

Jak podano wcześniej, obiekty NTFS mają trzynaście różnych uprawnień. Niektóre pochodzą od uprawnień dostępu do obiektów standardowych. Inne są charakterystyczne dla obiektów NTFS. Uprawnienia zezwalają na różne działania, zależne od tego, czy są przyporządkowane do folderu lub do pliku. W tablicy 14.2 zawarto uprawnienia NTFS i ich funkcje.

Tablica 14.2. Uprawnienia NTFS i ich funkcje

Uprawnienie	Działanie w przypadku foldera	Działanie w przypadku pliku
Traverse Folder/Ececute File	Zezwala użytkownikowi na dostęp do podfolderu w folderze, do którego użytkownik nie ma żadnych praw	Pozwala uruchomić plik wykonywalny, plik wsadowy lub skrypt
List Folder/Read Data	Pozwala na pokazywanie dostępnych plików i katalogów wykorzystując Eksploratora lub poprzez polecenie dir z wiersza poleceń	Pozwala na otwarcie i odczyt z pliku. Uprawnienie Read oznacza również Uprawnienie Copy
Read Attributes	Pozwala na odczytanie standardowych atrybutów plików i folderów, takich jak: ukryty, systemowy tylko do odczytu, archiwalny i skompresowany
Read Extended Attributes	Pozostałość po obsłudze systemu OS/2. Nie jest już obsługiwane
Create Files/ Write Data	Pozwala na tworzenie nowych plików w folderze	Pozwala na modyfikowanie pliku
Create Folders/Append Data	Pozwala na tworzenie podfolderów w danym folderze	Pozwala na dopisywanie danych do istniejącego pliku
Write Attributes	Pozwala na modyfikowanie dowolnego atrybutu standardowego
Write Extended	Pozostałość po obsłudze systemu OS/2. Nie jest już obsługiwane
Delete	Pozwala na usuwanie podfolderów lub plików, niezależnie od uprawnień odnoszących się do pliku. W Windows NT uprawnienie to nosiło nazwę File Delete Child. Istnieje, aby zapewnić zgodność ze standardem POSIX	Nie dotyczy
Delete	Uprawnienie ogólne, pozwalające na usuwanie plików, podfolderów i ich atrybutów	Uprawnienie ogólne, pozwalające na kasowanie plików i ich atrybutów
Read Permissions	Uprawnienie ogólne, pozwalające na odczyt deskryptora bezpieczeństwa pliku lub folderu
Change	Uprawnienie ogólne, pozwalające na modyfikacje deskryptora bezpieczeństwa pliku lub folderu
Take Ownership	Uprawnienie ogólne, pozwalające na przejmowanie na własność pliku lub folderu

Dziedziczenie uprawnieńW Windows NT modyfikacja listy dostępu (access list) ma wpływ tylko na dany folder i pliki bezpośrednio w nim zapisane, o ile administrator nie postanowi wprowadzić tych zmian do podkatalogów. Sposób taki jest nieporęczny i nie ma możliwości dynamicznego dziedziczenia uprawnień, co powoduje niekończące się narzekania administratorów NT. Windows 2000 łagodzi ten problem poprzez wprowadzenie usługi, która dynamicznie zmienia statyczne uprawnienia przydzielone do plików i folderów. W firmie Microsoft nie nadano tej usłudze oficjalnej nazwy. Autor książki posługuje się określeniem dziedziczenie statyczne/dynamiczne (static/dynamic inheritance), ale może nazwa Dziedzictwo 2000 (Inheritance 2000) byłaby lepsza.

Model obiektów chronionych Windows 2000 nie obsługuje dziedziczenia dynamicznego. Monitor stosunków bezpieczeństwa (Security Reference Monitor) ocenia pozycje ACE, które znajduje w pojedynczym deskryptorze bezpieczeństwa (security descriptor). Prawdziwe dziedziczenie dynamiczne wymagałoby od monitora SRM przeglądania drzewa katalogów i sprawdzania list ACL w każdym z folderów, aby znaleźć dziedziczne pozycje ACE (lub stworzenia spisu takich pozycji, który musiałby być odświeżany). Wynik wyszukiwania obowiązujących praw nie mógłby być zapisany w pamięci podręcznej, ponieważ istniałaby możliwość wystąpienia zmiany dotyczącej pojedynczego obiektu security principal.

Dziedziczenie statyczne/dynamiczne (static/dynamic inheritance) wykorzystuje nowy znacznik ACE o nazwie INHERITED_ACE i program automatycznie przesyła dziedziczne ACE do plików i podfolderów. Takie przesyłanie działa szybko, ponieważ deskryptory bezpieczeństwa (security descriptors) są zebrane w jednym katalogu, a nie rozproszone pomiędzy różnymi rekordami MFT, tak jak ma to miejsce w Windows NT.

W systemie plików NTFS jest pięć sposobów przenoszenia uprawnień dziedzicznych w dół drzewa katalogów:

• Dotyczy tylko danego folderu (This Folder Only)

• Dotyczy danego folderu i plików (This Folder and Files)

• Dotyczy danego folderu i podfolderów (This Folder and Subfolders)

• Dotyczy danego folderu, podfolderów i plików (This Folder and Subfolders and Files)

• Dotyczy wyłącznie plików (Files Only).

Przenoszenie uprawnień dziedzicznych można kontrolować poprzez okno Ustawienia kontroli dostępu (Access Control Settings) dla danego folderu. Szczegóły podano w następnym paragrafie.

Podgląd dziedziczenia uprawnień

Otwórz okno Ustawienia kontroli dostępu (Access Control Settings) dla wybranego folderu (PROPERTIES|SECURITY TAB|ADVANCED) i przesuń kursor w dół listy obiektów security principals. Zaznaczenie pozycji ACE powoduje wyświetlenie poniżej przycisków Dodaj/Usuń/Podgląd (Add/Remove/View) informacji o właściwościach dziedziczenia tej pozycji ACE.

Na przykład rysunek 14.4. przedstawia podfolder z dwiema pozycjami w wykazie uprawnionych (Permission Entries). Grupa Users posiada uprawnienie Read&Execute, przypisane bezpośrednio do danego foldera. Grupa Administrators ma uprawnienia Full Control, odziedziczone z foldera macierzystego. Kolumna Zastosuj do (Apply to) pokazuje, że te pozycje będą dziedziczone przez foldery, podfoldery i pliki.

Rysunek 14.4. Okno Ustawienia kontroli dostępu (Access Control Settings) pokazujące odziedziczone i stosowane uprawnienia.

Zaznaczenie uprawnienia odziedziczonego powoduje wyświetlenie obok przycisków Dodaj/Usuń/Podgląd (Add/Remove/View) informacji wyjaśniającej, jak zablokować, a nie usunąć, dziedziczone uprawnienia poprzez wyczyszczenie pola wyboru Zezwolenie na rozprzestrzenianie się uprawnień dziedzicznych z obiektu macierzystego na wybrany obiekt (Allow inheritable permissins from parent to propagate to this object).Odwołując się do rysunku 14.2, można zauważyć, że opcja Zezwolenie na rozprzestrzenianie się......(Allow inheritable......) nie jest zaznaczona dla foldera \WINNT. W przypadku zainstalowania Windows 2000 z ustawieniami domyślnymi grupa Everyone ma uprawnienie Full Control w głównym katalogu systemowym, a sposób dziedziczenia jest ustawiony na Dotyczy tego folderu, podfolderów i plików (This Folder, Subfolders and Files). Poprzez zablokowanie dziedziczenia tego uprawnienia pliki systemowe w folderze \WINNT są chronione przed przypadkowym skasowaniem lub zmianą dokonaną przez użytkownika.

Dla foldera \WINNT grupie Everyone i grupie Authenticated Users nadano uprawnienie Read&Execute. Dziedziczenie dla grupy Everyone zostało ustawione w tryb Dotyczy tylko danego folderu (This Folder Only). Tylko grupa Authenticated Users ma dostęp w dół drzewa katalogu.Usunięcie grupy Everyone z głównego katalogu systemowego (Root Directory)

Jeśli widok grupy Everyone z prawem dostępu Full Control potencjalnie do wszystkich folderów i katalogów w danym woluminie powoduje, a powinien, Twój niepokój, możesz usunąć tę grupę z listy ACL głównego katalogu systemowego, a dodać grupę bardziej odpowiednią do organizacji systemu. Nie zabraniaj dostępu do grupy Everyone. Natychmiast zostaniesz razem z innymi unieruchomiony bez dostępu do plików i folderów. Niejeden administrator po dokonaniu takiej pomyłki musiał odtwarzać system z taśmy.

Kasowanie uprawnień

Model dziedziczenia dynamicznego/statycznego zastosowany w Windows 2000 powoduje, że nawarstwianie się zmian uprawnień dokonywanych przez lata na dolnych poziomach drzewa katalogów może być przyczyną trudnych do śledzenia problemów z dostępem. Sposobem na usunięcie tych problemów może być wykorzystanie opcji Skasuj uprawnienia we wszystkich obiektach potomnych i ustaw zezwolenie na rozprzestrzenianie się uprawnień dziedzicznych (Reset premissions on all child objects and enable propagation of inheritable permissions). Wszystkie uprawnienia przypisane statycznie zostaną usunięte z każdego pliku i podfolderu, a następnie zastąpione dziedzicznymi uprawnieniami z folderu, do którego zastosowano powyższą opcję. Taką operację trzeba uprzednio dokładnie przemyśleć i zaplanować, ponieważ lata ciężkiej pracy można zniweczyć kilkoma kliknięciami myszą.Kiedy pozycja ACE jest dodawana do listy ACL, Monitor stosunków bezpieczeństwa (Security Reference Monitor) wpisuje na listę dziedziczone ACE niżej niż bezpośrednio stosowane ACE. Daje to pierwszeństwo bezpośrednio stosowanym ACE, ale zachowuje wyjątek w przypadku ACE Odmowa dostępu (Access Denied). Jeśli ACE Zezwolenie na dostęp (Access Allowed) jest zastosowana bezpośrednio do danego folderu, a folder dziedziczy ACE Odmowa dostępu (Access Denied), to pierwszeństwo ma Odmowa dostępu (Access Denied).Kopiowanie plików to tworzenie nowych plików w nowym miejscu, więc plik skopiowany dziedziczy listę ACL foldera macierzystego. Po przeniesieniu pliku w inne położenie na tym samym woluminie, zachowuje on deskryptor bezpieczeństwa (security descriptor), co może sprawiać kłopoty, ponieważ lista dostępu jednego katalogu może okazać się nieodpowiednia dla innego. W związku z tym po przeniesieniu pliku może być konieczna zmiana listy ACL.Do przeniesienia pliku konieczny jest taki rodzaj uprawnienia, który pozwala na kasowanie plików, ponieważ przenoszenie pociąga za sobą kasowanie. Jeśli plik jest przenoszony do innego woluminu, to w woluminie docelowym tworzony jest od podstaw nowy plik, dziedziczący listę ACL folderu macierzystego, tak jak w przypadku kopiowania plików.

Własność

Każdy z plików i katalogów ma swojego właściciela. Właściciel ma uprawnienia Full Control. Nazwę właściciela można odczytać w oknie Właściwości (Properties), naciskając przycisk Zaawansowane (Advanced) i wybierając zakładkę Właściciel (Owner). Przykład zamieszczono na rysunku 14.5.

Rysunek 14.5. Okno Ustawienia kontroli dostępu (Access Control Settings), przedstawiające zakładkę Właściciel (Owner) z podanym właścicielem katalogu \WINNT.Pole Aktualny właściciel tego obiektu (Current Owner Of This Item) podaje nazwę właściciela razem z jego identyfikatorem bezpieczeństwa (SID), znajdującym się w polu Owner_ID deskryptora bezpieczeństwa. Jeśli w polu Aktualny właściciel tego obiektu pojawi się wyłącznie identyfikator bezpieczeństwa, oznacza to, że właściciel pochodzi z domeny, która obecnie nie znajduje się już w relacji zaufania z danym komputerem.Użytkownik posiadający konto, któremu nadano uprawnienie Take Ownership odnośnie pliku lub folderu może nacisnąć przycisk „Przejmij na własność” (Take Ownership) i objąć dany obiekt w posiadanie. Na przykład, jeśli pozwolimy grupie Everyone zachować uprawnienie Full Control dotyczące plików lub folderów, to wtedy każdy użytkownik może przejąć na własność dowolny obiekt systemu plików NTFS. W stosunku do plików i folderów, znajdujących się w folderze \WINNT uprawnienie Take Ownership mają tylko członkowie grupy Administrators. Ten przywilej nie rozciąga się na grupy Account Operators ani Server Operators w domenie, ani na Power User, w przypadku komputerów z systemem Windows 2000 Professional.

Standardowe narzędzia systemu Windows 2000 pozwalają użytkownikowi przejmować na własność, ale nie przekazywać praw własności. W paragrafie „Zmiana praw własności pliku” opisane są metody przekazywania własności z wykorzystaniem narzędzi programowych, dostępnych na rynku.

W Windows NT zagadnienie prawa własności pozostawało na dalszym planie. Użytkownicy tworzą, kopiują, przenoszą, robią kopie zapasowe i odtwarzają pliki bez zwracania uwagi na rzeczywistego właściciela. To się zmieniło w systemie Windows 2000, jeśli nałożono ograniczenia na maksymalny obszar woluminu dostępny dla użytkownika (Quotas), ponieważ system zarządzania ograniczeniami wykorzystuje prawo własności do śledzenia wykorzystania dysku. Zarządzanie ograniczeniami dysku (quota management) opisano w rozdziale 13.

Przeprowadzanie inspekcji (Auditing)

Możliwość sprawdzania, jak obiekty typu security principals korzystają ze swoich uprawnień, jest częścią programu SRM. Sprawdzanie operacji wykonywanych przez proces może dostarczyć sporo informacji o pracy tego procesu. Program SRM zapisuje wynik przeprowadzonej inspekcji w dzienniku zdarzeń bezpieczeństwa (Security event log), SECURITY.EVT, umieszczonym w katalogu \WINNT\System32\Config. Dziennik zdarzeń można oglądać za pomocą konsoli Przeglądanie dziennika zdarzeń (Event Viewer), EVENTVWR.MSC. Do posługiwania się dziennikiem zdarzeń bezpieczeństwa konieczne są uprawnienia administratora. Szczegóły opisano w paragrafie „Przeprowadzanie inspekcji plików i folderów” (File and Folder Auditing).Ponieważ przeprowadzenie inspekcji dostarcza bardzo wielu informacji o działaniu systemu, usługa ta stanowi potencjalny wyłom w systemie bezpieczeństwa i wymaga szczególnej kontroli. Deskryptor bezpieczeństwa danego obiektu ma specjalną strukturę danych o nazwie Systemowa lista kontroli dostępu (System Access Control List — SACL), która określa, kto może dokonywać inspekcji danego obiektu. Użytkownik musi mieć na liście SACL wpisaną pozycję ACE „Zezwolenie na dostęp” (Access Allowed), aby mieć dostęp do informacji uzyskanych w wyniku przeprowadzonej inspekcji.

Usługa SRM może utworzyć raport z każdej dziedziny działalności obiektu, włącznie z takimi jak:

• Logowanie/Wylogowanie się użytkowników (Logon/Logoff)

• Zarządzanie Kontami (Account Management)

• Dostęp do usług katalogowych (Directory Service Access)

• Zdarzenia związane z logowaniem się użytkownika (Logon Events)

• Dostęp do obiektów (Object Access)

• Zmiana założeń systemowych (Policy Changes)

• Korzystanie z uprawnień (Privilege Use)

• Śledzenie procesów (Process Tracking)

• Zdarzenia systemowe (System Events)

Inspekcja jest przeprowadzana zgodnie z zasadami dokonywania inspekcji ustalonymi dla komputera lokalnego, bądź też zasadami inspekcji grupowej kontenerów Active Directory: Jednostka organizacyjna (OU), Domena i Miejsce (Site).

Odnośnie systemu plików NTFS najbardziej interesująca jest inspekcja dostępu do obiektów (Object Access). Aby uzyskać raport po przeprowadzonej inspekcji działalności związanej z plikami i folderami, trzeba ustawić zezwolenie na inspekcjonowanie. Następnie można wybrać inspekcjonowanie dostępu dowolnego obiektu z kategorii security principals do dowolnego obiektu NTFS z dowolnym uprawnieniem NTFS.

Wykorzystanie uprawnień NTFS do kontroli dostępu do folderów i plików

Zdarzenia zachodzą według wspólnego scenariusza. Nowy wykonawca przyjął zlecenie do wykonania w biurach firmy Company, Inc. w Phoenix. Jest to inżynier budownictwa Bob Plum. Bob jest doświadczonym pracownikiem, zarząd docenia jego zasługi dla zespołu, ale nie chce żeby on i inni kontrahenci, nie mieli dostępu do kluczowych dokumentów firmowych zawierających budżet i dane personalne. Zadaniem jest zablokowanie Bobowi dostępu do tych dokumentów.

Przykład ochrony za pomocą uprawnień do folderów udostępnianych (Share — level Security)

Jednym ze sposobów rozwiązania postawionego powyżej zadania jest zebranie poufnych danych firmowych w oddzielnym zestawie folderów, które nie są udostępnione wszystkim.

Takie rozwiązanie prowadzi do powstania płaskiej struktury katalogów z bardzo dużą liczbą udziałów. W przypadku dużej firmy mającej wiele oddziałów, liczba koniecznych udziałów może sięgać setek, co jest przyczyną problemów, gdyż za każdym razem, jeśli użytkownik jest zalogowany na komputerze-kliencie mapuje dysk sieciowy lub otwiera ikonę Moje miejsca sieciowe (My Network Places), wszystkie udziały są wysyłane do tego komputera.

Duża liczba udziałów zmusza użytkowników do mapowania wielu dysków sieciowych. Powoduje to ich zdenerwowanie i jest ciężarem dla działu pomocy technicznej. Dialogi brzmią mniej więcej tak: „Jesteś gotów? Mapuj dysk L do udziału o nazwie CAD, w którym znajdują się rysunki, mapuj dysk M do udziału Bridge, gdzie zapisane są pliki projektu. Jest jeszcze udział o nazwie COMMON, w którym jest twoja karta kontrolna, do niego mapuj dysk H, i udział APPS do uruchamiania Office, do niego mapuj dysk I. Mówisz, że pracujesz nad projektem Secret Project? Dobra, to mapuj dysk N do udziału SP, a ja sprawdzę, jakie masz uprawnienia”.

W przypadku serwerów danych z wielopoziomową strukturą katalogów, należy unikać tego sposobu ochrony i zastosować zamiast niego uprawnienia NTFS. Takie rozwiązanie pozwala na tworzenie udziałów wysoko w strukturze drzewa katalogów i ograniczenie ich liczby. Poniżej zamieszczono przykład wykorzystania uprawnień NTFS.

Przykład ochrony za pomocą uprawnień NTFS (NTFS security)

Aby kontrolować dostęp do plików projektowych firmy Company, Inc. za pomocą uprawnień NTFS, trzeba zacząć od podzielenia użytkowników na grupy. Następnie zamiast tworzenia oddzielnych udziałów dla każdego z głównych folderów, należy utworzyć jeden udział dla foldera znajdującego się najwyżej w strukturze drzewa folderów i wykorzystać podział na grupy do przypisania uprawnień NTFS do folderów znajdujących się poniżej. Na przykład utwórzmy grupę o nazwie Phx_Eng (Phoenix Engineering) i nadajmy jej uprawnienie odczytu/zapisu do folderu Engineering. Następnie utwórzmy grupę o nazwie Phx_Eng_Contr (Phoenix Engineering Contractors), dla której dostęp do folderów zawierających dane poufne będzie zabroniony. Rysunek 14.6 przedstawia taką konfigurację.

Rysunek 14.6. Konsola AD Użytkownicy i komputery (AD Users and Computers) przedstawiająca przykładowe grupy.

Można zastanawiać się, dlaczego konieczne jest utworzenie dwóch grup. Przecież pozostawienie Boba poza grupą Phx_Eng trzymałoby go z daleka od danych poufnych, ponieważ działałoby przyjęte przez domniemanie uprawnienie zakazujące dostępu Implicit Deny ACE. Korzystanie z domniemanych uprawnień zmusza administratora do zapisania objaśnień, dlaczego Boba pozostawiono poza grupą Phx_Eng, aby inny administrator nie dodał go do tej grupy, kontrolując dostęp do innego foldera. Nazwa użytkownika Bob znajdująca się wśród członków grupy, dla której odmowa dostępu do folderu jest wyrażona otwarcie, pokazuje jasno intencje administratora.

Korzystanie z grup zamiast pojedynczych użytkowników na liście ACL

Możliwe jest nadawanie uprawnień kolejnym użytkownikom oddzielnie, ale wygodniej jest wpisać na listę kontroli dostępu ACL jedną lub dwie grupy ze stu użytkownikami, niż stu użytkowników. Zbyt wiele pozycji listy ACL obniża również wydajność systemu.

Stosowanie uprawnień NTFS

Uprawnienia NTFS mogą być przypisane do foldera lub do pojedynczych plików. Na poniższym przykładzie nastąpi sprawdzenie, w jaki sposób będą dziedziczone uprawnienia przypisane do foldera.

Procedura 14.1. Przypisywanie uprawnień NTFS do foldera

1. Otwórz Eksploratora i przejdź do odpowiedniego foldera. W przykładzie pokazanym na rysunku 14.7 jest to folder \Company\Engineering\Management.

Rysunek 14.7. Przykładowy katalog z udostępnionym folderem Engineering.

2. Kliknij na nazwie foldera prawym klawiszem myszy i z menu wybierz opcję Właściwości (Properties). Otworzy się okno Właściwości (Properties) dla wybranego foldera.

3. Wybierz zakładkę Zabezpieczenia (Security). Rysunek 14.8 przedstawia przykładową listę obiektów typu security principal. Należy się spodziewać, że na liście ACL znajdzie się grupa Everyone z prawem dostępu Full Control. Jest to ustawienie domyślne dla głównego folderu systemowego (root) w każdym nowym woluminie. Uprawnienia grupy Everyone są dziedziczone przez wszystkie podfoldery i pliki.

Rysunek 14.8. Właściwości foldera Engineering pokazujące grupę Everyone, która ma uprawnienie Full Control.

1. --> Do[Author:UP] listy ACL foldera Engineering dodaj grupę Engineering. Naciśnij przycisk Dodaj (Add). Pojawi się okno Wybierz użytkowników, komputery lub grupy (Select Users, Computers or Groups), które przedstawia rysunek 14.9. Wybierać można spośród użytkowników i grup z domeny macierzystej lub z domeny zaufanej. W przykładzie wykorzystano grupę Phx_Eng_Contr z domeny macierzystej Company.com, która zawiera konto użytkownika o nazwie Bob Plum.

Rysunek 14.9. Okno Wybierz użytkowników, komputery lub grupy (Select Users, Computers or Groups), pokazujące wybór grupy Phx_Eng_Contr.

5. Dodaj grupę Phx_Eng_Contr do listy ACL klikając dwukrotnie na jej nazwie.

6. Dodaj grupę Phx_Eng do listy ACL klikając dwukrotnie na jej nazwie. Lista kontroli dostępu ACL może zawierać do 1820 pozycji ACE, ale problemy z wydajnością systemu pojawią się przed osiągnięciem tej wartości.

7. Naciśnij przycisk OK. Nastąpi powrót do okna Właściwości (Properties). Na rysunku 14.10. przedstawiono listę ACL zawierającą dodane grupy i ich domyślne uprawnienia.

8. Przed przypisaniem uprawnień tym grupom usuń z listy ACL grupę Everyone. Grupa ta jest dziedziczona i nie można wykonać tego naciskając przycisk Usuń (Remove). Próba usunięcia w taki sposób spowoduje wyświetlenie komunikatu o błędzie.

Zmiana uprawnień dla grupy Everyone w głównym katalogu systemowym (root directory) wymaga namysłu i zaplanowania, więc na razie najlepszym rozwiązaniem jest wyłączenie opcji Zezwolenie na rozprzestrzenianie się uprawnień dziedzicznych z obiektu macierzystego na wybrany obiekt (Allow inheritable permissins from parent to propagate to this object), dotyczącej tego foldera. Kiedy to zrobisz, pojawi się komunikat z zapytaniem, czy chcesz skopiować dziedziczone uprawnienia czy je usunąć. Więcej informacji w części „Ostrożnie z domniemanym zakazem dostępu”.

Rysunek 14.10. Okno właściwości folderu pokazujące nowe grupy i ich domyślne uprawnienia.

9. Naciśnij przycisk Usuń (Remove). Grupa Everyone zniknie z listy ACL.

10. Wybierz grupę Phx_Eng i zaznacz pole wyboru Full Control w kolumnie Zezwolenie (Allow), co da tej grupie uprawnienia do dodawania, usuwania i modyfikowania dowolnego pliku i podkatalogu.

11. Wybierz grupę Phx_Eng_Contr i zaznacz pole wyboru Full Control w kolumnie Zakaz dostępu (Deny), co otwarcie zakazuje dostępu członkom tej grupy. Do tej pory do listy ACL nie dopisano grupy administratorów. Po zaakceptowaniu wprowadzonych zmian straciłbyś dostęp do folderu, ponieważ zadziałałby domniemany zakaz dostępu (Implicit Deny). Przed zaakceptowaniem dokonanych zmian możesz dodać większą liczbę grup.

12. Przed naciśnięciem przycisku OK, naciśnij przycisk Zaawansowane (Advanced), otwierając w ten sposób okno Ustawienia kontroli dostępu (Access Control Settings). Kolumna Zastosuj do pokazuje ustawienia dziedziczenia. Domyślnie ustawione jest pełne dziedziczenie (aktualny folder, podfoldery i pliki). Jeśli chcesz zmienić opcje dziedziczenia, naciśnij przycisk Podgląd/Edycja (View/Edit), a następnie wybierz odpowiednią opcję z listy rozwijalnej.

13. Naciśnij przycisk Anuluj (Cancel), aby powrócić do okna Właściwości (Properties).

14. Naciśnij przycisk OK, aby zastosować wprowadzone zmiany. Pojawi się ostrzeżenie o ustawionym zakazie dostępu. Potwierdź ostrzeżenie naciskając przycisk Tak (Yes). Ustawienia zostaną zmienione i okno Właściwości (Properties) zostanie zamknięte.

Ostrożnie z domniemanym zakazem dostępu

Jeśli wybrałeś usunięcie dziedziczonych uprawnień dla danego foldera, upewnij się, czy grupa Administrators lub inna grupa mająca prawa administratorów znajduje się na liście ACL. Jeśli takiej grupy nie ma, to domniemany zakaz dostępu uniemożliwi dostęp do danego foldera.

Zależnie od sytuacji usunięcie administratorów z listy ACL danego foldera nie musi być złe, ale utrudni pracę administratora, jeśli użytkownicy będą potrzebowali jego interwencji w sprawie plików zapisanych w tym folderze. Dodanie grupy administratorów do listy ACL zwykle okazuje się dobrym pomysłem.

Nowe uprawnienia mają skutek natychmiastowy. Każdy z członków grupy Phx_Eng, który jest aktualnie zalogowany, ma dostęp do foldera. Ich znaczniki dostępu (access tokens) zawierają już identyfikatory bezpieczeństwa (SID) dla grupy Phx_Eng. Z tego samego powodu żaden z członków grupy Phx_Eng_Contr nie ma już dostępu do foldera.

A co z Bobem? Jeśli Bob zalogował się, zanim został włączony do grupy Phx_Eng_Contr, jego żeton dostępu (access token) nie zawiera identyfikatora SID dla grupy Phx_Eng_Contr. Jeśli jest już członkiem grupy Phx_Eng, zachowa dostęp do foldera Engineering, dopóki nie wyloguje się, a następnie zaloguje ponownie, otrzymując Kerberos Ticket — Granting — Ticket (TGT) z nowym zestawem identyfikatorów SID dla grup. TGT jest odświeżany okresowo, ale lepiej będzie poprosić użytkownika żeby się wylogował, aby nastąpiła aktualizacja.

Wykorzystanie uprawnień NTFS do kontroli dostępu do plików

Może wystąpić konieczność ochrony określonych plików w danym folderze. Na przykład w jednym z ogólnie dostępnych podfolderów Engineering mogą znajdować się pliki z danymi poufnymi, które nie powinny być udostępniane kontrahentom. Najlepiej byłoby przenieść je do osobnego folderu, ale czasami nie można tego zrobić. W tej sytuacji administrator może przypisać uprawnienia bezpośrednio do plików.

Przypisywanie uprawnień do plików wymaga wykonania tych samych czynności, co dla folderów. Otwórz okno Właściwości (Properties) dla danego pliku, wybierz zakładkę Bezpieczeństwo (Security), a następnie dodaj grupy do listy ACL i ustaw ich uprawnienia.

Przypisując uprawnienia do plików należy pamiętać, że użytkownik może mieć przypisane prawo dostępu na poziomie foldera, które jest nadrzędne w stosunku do uprawnienia przypisanego do pliku. Przykładem tego jest uprawnienie Delete Subfolders and Files.

Uprawnienie Delete Subfolders and Files istnieje w celu zapewnienia zgodności ze standardem POSIX. Daje użytkownikowi uprawnienie do usunięcia pliku lub podfoldera, nawet, jeśli zostało to otwarcie zakazane przez uprawnienia przypisane do pliku. W naszym przykładzie Bob ma uprawnienie Full Control w folderze Engineering. Po ustawieniu uprawnienia Deny All dla jakiegoś pliku w tym folderze, Bob nie będzie mógł otworzyć, przenieść ani skopiować tego pliku, ale będzie mógł go skasować.

Uprawnienie Delete Subfolders and Files jest aktywne tylko wtedy, kiedy wybrane jest uprawnienie Full Control. Przypisując użytkownikom uprawnienia do foldera powinno się wybierać uprawnienie Modify, zamiast Full Control, aby uniknąć przypisania uprawnienia Delete Subfolders and Files. Uprawnienie Modify pozwala również na uniknięcie przypisania uprawnień Change Permission i Take Ownership, które również nie powinny być dostępne dla przeciętnego użytkownika.

Zmiany uprawnień NTFS za pomocą polecenia Xcacls

Poprzez wiersz poleceń dostępne jest narzędzie do podglądania i zmian listy kontroli dostępu (access control list) o nazwie Cacls. W Resource Kit dla Windows 2000 znajduje się rozszerzona wersja tego programu o nazwie Xcacls. W tym paragrafie przedstawiono wykorzystanie programu Xcacls do kontrolowania uprawnień z wiersza poleceń.

Tablica 14.3 przedstawia listę parametrów Xcacls, które są użyteczne w różnych sytuacjach.

Tablica 14.3. Xcacls przełączniki polecenia

Przełącznik	Działanie
/t	Zamienia istniejące listy ACL na listy przypisane przez to polecenie
/e	Pozwala na edycję listy ACL
/c	Ignoruje błędy i przechodzi do dalszej części listy ACL
/g user:permission;special access	Dla plików polecenie ma postać /g user:perm, gdzie perm podaje uprawnienia przypisane do pliku. Dla folderów polecenie ma postać /g user:perm:spec, gdzie perm oznacza uprawnienia przypisane do foldera a spec — uprawnienia przypisane do plików. Poprzez parametry perm i spec można przypisać następujące uprawnienia: R — Read C — Change F — Full Control P — change Permissions O — take Ownership X — eXecute E — rEad W — Write D — Delete T — noT specified (tylko jako spec)
/r user	Unieważnia uprawnienia użytkownika
/p user:permission;special access	Zamienia uprawnienia użytkownika
/d user	Zakazuje użytkownikowi wszelkiego dostępu
/y	Nie weryfikuje

Przykłady zastosowania programu Xcacls

Powiedzmy, że chcemy dodać kilku użytkowników do listy ACL foldera o nazwie Campaign2000. Oto kilka sposobów wykorzystania do tego programu Xcacls:

• Usuń użytkownika BClinton z listy ACL: Xcacls campaign2000 /r

• Dodaj użytkownika AGore z uprawnieniem Full Control do wszystkich plików i folderów: xcacls campaign2000 /g agore:f;f

• Dodaj użytkownika SForbes z uprawnieniem Take Ownership do wszystkich plików i folderów: xcacls campaign2000 /gsforbes:o;o

• Dodaj użytkownika GWBush z uprawnieniem Execute dla foldera i Delete dla plików: xcacls campaign2000 /g gwbush:x;d

• Usuń wszystkie uprawnienia użytkownika RPerot: xcacls campaign2000 /d rperot

Wykorzystanie programu Xcacls do podglądu uprawnień

Program Xcacls może być także wykorzystany do oglądania istniejących uprawnień przypisanych do pliku lub foldera. Wydruki bywają tajemnicze. Oto wydruk dla foldera \WINNT przykładowego systemu uzyskany w wyniku zastosowania programu Xcacls:

C:\>xcacls winnt

C:\WINNT NT AUTHORITY\Authenticated Users:R

NT AUTHORITY\Authenticated Users:(OI) (CI) (IO) (special access)

GENERIC_READ

GENERIC_EXECUTE

BUILTIN\Server Operators:C

BUILTIN\Server Operators: (OI) (CI) (IO) C

BUILTIN\Administrators:F

BUILTIN\Administrators:(OI) (CI) (IO) F

NT AUTHORITY\SYSTEM:F

NT AUTHORITY\SYSTEM:(OI) (CI) (IO) F

BUILTIN\Administrators:F

CREATOR OWNER:(OI) (CI) (IO) F

Everyone:R

COMPANY\User001: (OI) (CI) R

COMPANY\TestGroup: (OI) (CI) F

Nazwa użytkownika zawiera nazwę serwera DNS, niższego w hierarchii domen (subauthority), która jest częścią identyfikatora SID. Źródło NT AUTHORITY wskazuje na część początkową identyfikatora SID postaci S - 1 - 5 bez serwera DNS, niższego w hierarchii domen (subauthority). Dwie końcowe linie wydruku odnoszą się do domeny COMPANY. Pozycje w nawiasach określają sposób dziedziczenia uprawnień.

• Inherit Only (IO) określa uprawnienia przypisywane każdemu nowemu plikowi utworzonemu w tym folderze.

• Container Inherit (CI) określa uprawnienia przypisywane każdemu nowemu podfolderowi utworzonemu w tym folderze.

• Object Inherit (OI) określa uprawnienia dziedziczone z folderu macierzystego.

• No Propagate (NP) (nie występuje na powyższym wydruku) określa uprawnienia mające zastosowanie tylko do folderu lokalnego.

Litera na końcu każdej pozycji oznacza uprawnienie. Special Access zawiera każde uprawnienie nie przedstawione w postaci podstawowej maski ACE.

Zmiana praw własności pliku

System Windows 2000 spełnia wymagania stopnia ochrony C2 Departamentu Obrony USA, określonym w tzw. „Orange Book”. Stopień ochrony C2 wymaga, żeby każdy obiekt miał właściciela, który ma nad nim władzę ostateczną. Ale co się stanie, jeśli właściciel utworzy plik, w dowolny sposób ograniczy dostęp do niego, a następnie opuści firmę, kraj czy galaktykę?

Na przykład co się stanie, jeśli nasz kontrahent, Bob Plum, uważa się za pisarza? Jest bardzo oddany swojej pasji i nie widzi nic złego w oddawaniu się jej w godzinach pracy (płatne 120 $ za godzinę). Stacja robocza Boba została skonfigurowana w ten sposób, że zawartość jego plików jest zapisywana we wspólnym folderze na serwerze. Bob wie, że inni użytkownicy mogą widzieć jego pliki, więc wykorzystuje fakt, że jest właścicielem plików, które utworzył. Ustawił uprawnienia dostępu w ten sposób, że tylko on jest wpisany na listę ACL, co przedstawia rysunek 14.11. Może to zrobić nawet, jeśli folder, w którym zapisane są jego pliki, ma dla uprawnienia Change Permissions ustawiony zakaz dostępu (Access Denied ACE). Właściciel pliku ma dużą zdolność przystosowywania się do zmieniających się okoliczności.

Rysunek 14.11. Okno Właściwości (Properties) pliku mającego specjalne uprawnienia.

Kiedy wydajność pracy Boba obniżyła się z powodu jego dodatkowej działalności, Bob opuszcza firmę. Wyznaczono administratora, który ma poddać jego pliki szczegółowemu badaniu. Próby otwarcia plików powodowały błąd Brak dostępu (Access Denied). Sprawdzenie właściwości pliku dotyczących bezpieczeństwa spowodowało wyświetlenie komunikatu o błędzie „Brak uprawnień do oglądania i edycji aktualnych uprawnień” (You do not have permission to view or edit the current permission setting). Po potwierdzeniu ostrzeżenia okazuje się, że lista Uprawnienia (Permissions) w karcie Bezpieczeństwo (Security) jest pusta. Naciśnięcie przycisku Zaawansowane (Advanced) i wybranie karty Właściciel (Owner) powoduje pojawienie się okna przedstawionego na rysunku 14.12. Aktualny właściciel pliku nie jest wyświetlony, ponieważ nikt oprócz Boba nie ma uprawnień do oglądania deskryptora bezpieczeństwa.

Rysunek 14.12. Okno Ustawienia kontroli dostępu (Access Control Settings) z kartą Właściciel (Owner).

Ponieważ administrator jest członkiem grupy mającej uprawnienie Take Ownership, może szybko usunąć problem. Zaznacza grupę Administrators i naciska przycisk Zastosuj (Apply), przejmując prawo własności na rzecz całej grupy, której wszyscy członkowie będą teraz mieli dostęp do plików Boba.

Następnie administrator zamyka okno Właściwości (Properties) i ponownie otwiera, odświeżając jego zawartość. Na liście ACL pojawia się nazwa użytkownika Bob. Administrator wpisuje na listę ACL siebie lub całą grupę Administrators i zagląda do pliku.

Do tego momentu administrator używał standardowych narzędzi i technik Windows 2000. Ale co zrobić w przypadku, gdy administrator oceni zawartość pliku i zdecyduje, że prawdziwym właścicielem tego pliku powinien zostać pracownik wydziału prawnego, który wniósł skargę przeciwko firmie Boba? W Windows 2000 ani w Resource Kit nie ma narzędzi do przekazywania prawa własności, można wyłącznie przejmować pliki na własność. Program do przekazywania prawa własności o nazwie chown opracowany przez firmę Mortice Kerns Systems (MKS), Inc. jest dostępny na firmowej stronie WWW www.mks.com.

Inspekcje plików i folderów

Poprzez przeprowadzanie inspekcji plików i folderów można zobaczyć, jak użytkownicy wykorzystują swoje uprawnienia. Inspekcje konfiguruje się w dwóch etapach: najpierw włącza się działanie tej usługi poprzez zmianę zasad dotyczących grup, a następnie zmienia się ustawienia inspekcji poszczególnych plików lub folderów. Sposób postępowania podano w dalszej części bieżącego paragrafu. Jeśli przed przystąpieniem do konfiguracji uprawnień NTFS dla inspekcji nie będzie włączona opcja Object Access, system odpowie ostrzeżeniem, że Aktualne zasady przeprowadzania inspekcji dla tego komputera nie mają ustawionego włączenia inspekcji. Po tym ostrzeżeniu można zapisać uprawnienia inspekcji, ale nie będą one aktywne, dopóki nie zostanie włączona opcja Object Access. Zdarzenia związane z inspekcjami zapisywane są w dzienniku zdarzeń ochrony (Security Log), SECEVENT.EVT, w katalogu \WINNT\System32\Config. Zawartość dziennika zdarzeń można oglądać za pomocą konsoli Podgląd zdarzeń (Event Viewer), EVENTVWR.MSC, pod warunkiem, że ma się uprawnienia administratora.

Konfigurowanie zasad inspekcji

W tym paragrafie opisano, jak włączyć inspekcję Object Access modyfikując założenia systemowe domeny (Default Domain Policy). Można również ustawić inspekcję Object Access, zmieniając założenia systemowe użytkownika i dołączając je do jednostki organizacyjnej (OU), domeny lub kontenerów miejsca (site containers).

Aby modyfikować lub tworzyć założenia systemowe grup, konieczne są uprawnienia administratora dla Active Directory. Jeśli istnieje wiele założeń systemowych grup, trzeba sprawdzić każde z nich i upewnić się, że w żadnym z nich nie są podane zasady inspekcji, które miałyby pierwszeństwo. Hierarchia kontenerów (Container hierarchy) dla założeń systemowych grup ustala pierwszeństwo dla założeń systemowych jednostki organizacyjnej (OU), następne są założenia systemowe domeny, dalej założenia systemowe kontenerów miejsca (Site containers), a najniższą rangę mają założenia lokalne.

Poniższy przykład pokazuje, jak włączyć inspekcję systemu.

Procedura 14.2. Włączanie inspekcji systemu

1. Zaloguj się na konto z uprawnieniami administratora.

2. Otwórz konsolę AD Użytkownicy i komputery (AD Users and Computers).

3. Prawym klawiszem myszy kliknij ikonę domeny i z menu wybierz opcję Właściwości (Properties). Otworzy się okno Właściwości (Properties).

4. Wybierz zakładkę Założenia systemowe grup (Group policy).

5. Kliknij dwukrotnie w pozycji Domyślne założenia systemowe domeny (Default Domain Policy), otwierając w ten sposób konsolę Założenia systemowe grup (Group Policy).

6. Przejdź do pozycji Konfiguracja komputera|Ustawienia Windows|Ustawienia bezpieczeństwa|Lokalne założenia systemowe|Założenia systemowe inspekcji (Computer Configuration|Windows Settings|Security Settings|Local Policies|Audit Policy). Po prawej stronie znajduje się lista założeń inspekcji. Przykład zamieszczono na rys. 14.13.

--> To nie jest ten rysunek.[Author:E]

Rysunek 14.13. Konsola Założenia systemowe grup (Group Policy) przedstawiająca listę Założenia systemowe inspekcji (Audit Policy) z wybraną opcją Inspekcja dostępu do obiektów (Audit Object Access).

7. Kliknij dwukrotnie w pozycji Inspekcja dostępu do obiektów (Audit Object Access), otwierając w ten sposób okno Ustawienia zasad bezpieczeństwa (Security Policy Setting).

8. Wybierz pozycję Zdefiniuj ustawienia zasad (Define These Policy Settings). Wybierz opcję Inspekcja prób (Audit These Attempts) i zaznacz pole wyboru Sukces (Success) i Porażka (Failure). Nie uruchamia to inspekcji wszystkich zdarzeń związanych z obiektami i należących do tych dwóch kategorii. Jest to tylko zezwolenie na wykorzystanie ich przez inspektorów poszczególnych obiektów.

9. Naciśnij przycisk OK. Zmiany zostaną zapamiętane i nastąpi powrót do konsoli Założenia systemowe grup (Group Policy), w której będą widoczne nowe ustawienia.

10. Zamknij konsolę.

11. Nowe zasady inspekcji muszą być wpisane do lokalnego Rejestru systemowego, co może zająć systemowi trochę czasu. Zawartość rejestru może być uaktualniona ręcznie za pomocą polecenia secedit /refreshpolicy machine_policy.

Po rozesłaniu zmian zasad inspekcji można skonfigurować inspekcję plików i folderów w komputerze członkowskim. Sposób postępowania opisano w następnym paragrafie.

Przykładowa konfiguracja inspekcji

W niniejszym paragrafie opisano konfigurowanie inspekcji plików w podanym folderze. Można przeprowadzać inspekcje wielu folderów albo całego drzewa katalogu.

Procedura 14.3. Konfigurowanie inspekcji plików i folderów

1. Uruchom Eksploratora.

2. Prawym klawiszem myszy kliknij na nazwie foldera i z menu wybierz opcję Właściwości (Properties). Pojawi się okno Właściwości (Properties).

3. Wybierz zakładkę Zabezpieczenia (Security).

4. Naciśnij przycisk Zaawansowane (Advanced). Pojawi się okno Ustawienia kontroli dostępu (Access Control Settings).

5. Wybierz zakładkę Inspekcje (Auditing). Na rysunku 14.14 przedstawiono wybrane atrybuty inspekcji.

Rysunek 14.14. Okno Pozycje inspekcji dla narzędzi (Auditing Entry for Tools) przedstawiające wybrane atrybuty inspekcji.

W zakładce Inspekcja (Audit) znajdują się opcje Ustawień dziedziczenia (Inheritance Settings), ponieważ lista SACL wykorzystywana do kontrolowania uprawnień inspekcji jest oddzielona od listy DACL, wykorzystywanej do kontrolowania uprawnień dostępu do plików.

6. Naciśnij przycisk Dodaj (Add). Pojawi się okno Wybierz użytkownika, Komputer lub grupę (Select User, Computer, or Group).

7. Wybierz grupę, której ma dotyczyć inspekcja w danym folderze. Na próbę kliknij dwukrotnie nazwę grupy Administrators. Pojawi się okno Opcje inspekcji (Auditing Entry). Wybierz atrybuty podlegające inspekcji. Sprawdź, czy wybranym trybem dziedziczenia jest Ten folder, podfoldery i pliki (This Folder, Subfolders, And Files).

8. Naciśnij przycisk OK, aby zapisać dokonane zmiany i powrócić do okna Ustawienia kontroli dostępu (Access Control Settings). Na liście pojawi się nowa pozycja ACE.

9. Naciśnij przycisk OK, wpisując w ten sposób zmiany do deskryptorów bezpieczeństwa (security descriptors) i powracając do okna Właściwości (Properties). Jeśli w danym folderze znajduje się znaczna liczba podfolderów i plików, to uaktualnienie może chwilę potrwać.

10. Naciśnij przycisk OK, zamykając w ten sposób okno i powracając do Eksploratora.

11. Otwórz konsolę Podgląd zdarzeń (Event Viewer) przechodząc do START|PROGRAMS|ADMINISTRATIVE TOOLS|EVENT VIEWER.

12. Przejdź do pozycji Dziennik zdarzeń bezpieczeństwa (Security Log). Do otwarcia tego dziennika zdarzeń konieczne są uprawnienia administratora. Jeśli wybrałeś do inspekcji folder, z którego ktoś korzysta, w dzienniku powinny pojawić się odpowiednie wpisy. Aby zobaczyć informacje uzyskane w wyniku inspekcji, kliknij dwukrotnie na danym wpisie. Rysunek 14.15 przedstawia przykład takich informacji.

Rysunek 14.15. Wpis do Dziennika zdarzeń bezpieczeństwa po przeprowadzonej inspekcji

Zarządzanie dziennikiem zdarzeń bezpieczeństwa

Jeśli inspekcja będzie dotyczyć bardzo dużej liczby użytkowników i zdarzeń, wydajność systemu obniży się, a dziennik inspekcji szybko zapełni się. Problem z wydajnością można usunąć obniżając liczbę obiektów podlegających inspekcji. Rozmiar dziennika zdarzeń bezpieczeństwa (Security Log) można zwiększyć otwierając okno Właściwości (Properties) i zwiększając wartość Maksymalny rozmiar dziennika (Maximum Log Size).

Domyślnym rozmiarem dziennika jest 512 kB. Wpisywanie rozmiaru większego od 300 MB nic nie da, bo system nie tworzy większych plików z powodu ograniczeń pamięci. Kiedy dziennik zdarzeń zapełni się, system wpisuje nowe pozycje na miejscu wpisów starszych niż 7 dni. Można wybrać dłuższy przedział czasu, wyłączyć zapisywanie nowych pozycji na miejscu najstarszych lub ustawić wpisywanie na miejscu najstarszych tylko w razie potrzeby.

Wykorzystanie programu Dumpel

W Windows 2000 Resource Kit znajduje się program narzędziowy do zapisywania zawartości dziennika zdarzeń w postaci oddzielnego pliku o nazwie Dumpel. Program ten nie kasuje zawartości dziennika, więc nie ma potrzeby uruchamiania go jako zadanie zaplanowane (Schedule). Składnia polecenia jest następująca: dumpel - l <log_name> - f <filename>. Domyślnym formatem pliku jest format dziennika zdarzeń (*.evt), ale można zapisać zdarzenia jako plik tekstowy ze znakiem końca wiersza w postaci znaku tabulacji jako (parametr — t) lub przecinka (parametr — c).

Wszystkie ustawienia Dziennika zdarzeń (Event Log), włącznie z ustawieniami dotyczącymi dziennika zdarzeń bezpieczeństwa (Security Log) można zmienić, wykorzystując założenia systemowe dotyczące grup. Jest to szybki sposób przygotowania serwera i stacji roboczej do przeprowadzania inspekcji. Otwórz konsolę Założenia systemowe grup (Group Policy) i przejdź do pozycji Konfiguracja komputera|Ustawienia Windows|Ustawienia bezpieczeństwa|Dziennik zdarzeń|Ustawienia dla Dziennika zdarzeń (Computer Configuration|Windows Settings|Security Settings|Event Log|Settings for Event Logs). Kliknij dwukrotnie, wybierając założenia, które chcesz zmienić, wprowadź zmiany i potwierdź je naciskając przycisk OK.

Po zapełnieniu się dziennika inspekcji, ze względu na bezpieczeństwo systemu można zabronić dostępu do niego. Jest to jedna z opcji założeń systemowych o nazwie „Natychmiast zamknij system, jeśli nie można dokonać wpisu do dziennika inspekcji” (Shut Down System Immediately If Unable To Log Security Audits), dostępna w Konfiguracja komputera|Ustawienia Windows|Ustawienia bezpieczeństwa|Lokalne założenia systemowe|Opcje bezpieczeństwa (Computer Configuration|Windows Settings|Security Settings|Local Policies|Security Options). Wybranie tej opcji spowoduje awaryjne zamknięcie systemu po zapełnieniu się pliku dziennika zdarzeń bezpieczeństwa. Odzyskanie systemu jest możliwe tylko po zalogowaniu się na konto administratora i skasowaniu zawartości pliku dziennika, więc przed uruchomieniem tej opcji niezbędna jest znajomość hasła administratora. Nie wolno zapomnieć, że opcja ta jest aktywna.

Szyfrowanie plików (File Encryption)

Jak dotąd w niniejszym rozdziale opisano kontrolowanie dostępu do plików za pomocą uprawnień NTFS. Ale co się stanie, jeśli nieupoważniony użytkownik w jakiś sposób prześlizgnie się pomimo starannie ustalonych uprawnień i uzyska dostęp do plików? W przypadku serwera jest to trudne, ale użytkownicy są skłonni do dzielenia dysków, a nie zawsze wiedzą, jak prawidłowo stosować uprawnienia NTFS. Albo jeśli użytkownik przypadkowo zostawi laptop w pokoju hotelowym lub na lotnisku, skąd komputer zostanie skradziony i sprzedany z powodu danych zapisanych na dysku?

Dodatkowym zabezpieczeniem może być szyfrowanie plików i wtedy dostęp do pliku ma wyłącznie użytkownik, który go zaszyfrował. Jeśli algorytm szyfrowania jest wystarczająco trwały, a klucze szyfrowania są odpowiednio chronione, w praktyce gwarantuje to bezpieczeństwo danych.

Szyfrowaniem i odszyfrowywaniem plików w systemie Windows 2000 zajmuje się usługa o nazwie System Szyfrowania Plików (Encrypting File System — EFS). Na pierwszy rzut oka usługa EFS jest prosta. Użytkownik wybiera opcję poprzez okno Właściwości (Properties) dla danego pliku i już plik jest zaszyfrowany. Kiedy użytkownik otwiera plik kolejny raz, odszyfrowanie pliku dokonywane jest w locie. Wygląda to zrozumiale i prosto, ale przetwarzanie danych rzadko jest zrozumiałe i proste. Skoro tylko podjęta zostanie nagła decyzja, że dany plik ma być zapisany w postaci dostępnej tylko i wyłącznie jednemu użytkownikowi, do głowy przychodzi całe mnóstwo pytań:

• Co stanie się z plikiem, jeśli użytkownik jest niedostępny?

• Kto określa, którzy z użytkowników są upoważnieni do szyfrowania plików?

• Jaki jest mechanizm szyfrowania? Czy jest naprawdę odporny na ataki?

• Co się stanie w przypadku pliku zapisanego na serwerze, a nie na dysku lokalnym? Czy może zostać zaszyfrowany?

• Czy pliki zaszyfrowane mogą być współdzielone z innymi użytkownikami?

• Czy jest różnica pomiędzy szyfrowaniem plików w komputerze nie podłączonym do sieci a szyfrowaniem plików w domenie?

• Czy istnieje możliwość zablokowania komputera przez użytkownika, który zaszyfrowałby pliki systemowe?

• Czy można robić kopie zapasowe plików zaszyfrowanych i je odtwarzać?

• Co się stanie, jeśli plik zostanie przeniesiony lub skopiowany do innego foldera? Czy pozostanie zaszyfrowany? Co się stanie w przypadku kopiowania na dyskietkę lub do urządzenia Zip?

• Czy można usunąć plik zaszyfrowany lub zmienić mu nazwę?

• Czy systemy operacyjne inne niż Windows 2000 mogą mieć dostęp do plików zaszyfrowanych?

• Czy można mieć dostęp do plików zaszyfrowanych poprzez Internet?

Pytania można mnożyć bez końca. W niniejszym paragrafie podano odpowiedzi na te i inne pytania dotyczące zasady działania systemu plików zaszyfrowanych (EFS) i obsługi tego systemu. Oto lista zagadnień opisanych w niniejszym paragrafie:

• Opis działania szyfrowania plików i katalogów. W tej części opisano sposób szyfrowania i Usługi kryptograficzne z kluczem publicznym (Public Key Cryptpgraphy Srevices — PKCS) służące do ochrony kluczy szyfru.

• Szyfrowanie plików i katalogów. W tym paragrafie opisano wykorzystanie Eksploratora i wiersza poleceń do szyfrowania i odszyfrowywania plików i folderów.

• Certyfikaty osobiste. Każdy z użytkowników szyfrujących pliki w komputerze lokalnym ma nadany certyfikat PKCS. Klucze publiczny i prywatny pochodzące z tego certyfikatu są stosowane do ochrony klucza szyfrującego plik (File Encryption Key), który jest wykorzystywany przez usługę EFS do szyfrowania. W paragrafie tym opisano podglądanie, wysyłanie i importowanie certyfikatów osobistych.

• Odzyskiwanie plików zaszyfrowanych. Usługa EFS zapewnia zaufanym administratorom, zwanym agentami odzyskiwania danych Data Recovery Agents (DRA), dostęp do pliku zaszyfrowanego bez udziału użytkownika. W tym paragrafie opisano rolę Data Recovery Agents oraz założenia i strategie umożliwiające odzyskanie danych.

• Ochrona certyfikatów odzyskiwania plików (File Recovery Certificate). Do otwierania plików agenty DRA wykorzystują tzw. certyfikaty odzyskiwania plików. Nadzór nad certyfikatami odzyskiwania plików (FR certificate) ma podstawowe znaczenie dla bezpieczeństwa usługi EFS. W tym paragrafie opisano wysyłanie, przesyłanie i importowanie certyfikatów FR.

• Dodawanie Agentów Odzyskiwania Danych (Data Recovery Agents). System automatycznie desygnuje określone konto na agenta DRA. W tej części opisano, w jaki sposób można zwiększyć liczbę agentów DRA dla zwiększenia odporności systemu na awarie.

• Szyfrowanie plików na serwerach. Pliki dostępne przez sieć mogą być szyfrowane. Wymaga to ustawienia odpowiednich opcji uprawnień protokołu autoryzacji użytkowników Kerberos, czego wynikiem może być narażenie na szwank bezpieczeństwa systemu. W tym paragrafie opisano sposób konfiguracji szyfrowania plików zapisanych na serwerze i omówiono jego wpływ na bezpieczeństwo systemu.

Opis działania szyfrowania plików i katalogów

Idea szyfrowania plików osobistych jest bardzo pociągająca dla użytkowników. Wielu użytkowników wariuje na punkcie bezpieczeństwa komputerów. Naczytali się o hackerach i crackerach skradających się poprzez Internet i porywających pliki z równą łatwością, jak dziecko potrafi zwędzić ciastka.

Nawet jeśli użytkownicy wierzą, że sieć jest odporna na ataki z zewnątrz, wiedzą o tym, że personel techniczny i administratorzy mogą mieć dostęp do plików osobistych na serwerze i w komputerach lokalnych. Idea szyfrowania swoich dokumentów bardzo im się podoba.

Powiedzmy, że użytkownik zaloguje się na komputerze i włączy szyfrowanie. Sposób dokonania tego na razie nie jest ważny. Ważne jest to, że takie działanie zwraca na dany plik uwagę sterownika EFS, EFS.SYS. Poniżej opisano, w jaki sposób EFS szyfruje pliki i zabezpiecza szyfr.

Mechanizmy szyfrowania usługi EFS

Usługa EFS ma dwa zadania. Po pierwsze musi zaszyfrować plik, to jest wystarczająco jasne. Po drugie — musi także zaszyfrować klucz wykorzystany do zaszyfrowania pliku. W tym miejscu sprawa się trochę komplikuje. Przyjrzyjmy się najpierw szyfrowaniu plików.

Usługa EFS szyfruje pliki wykorzystując algorytm DESX (extended US Data Encryption Standard). Algorytm DESX został opracowany przez Ronalda Rivesta podczas prób uodpornienia stosunkowo słabego algorytmu DES na włamania na podstawie gotowego spisu haseł (dictionary attacks), z zachowaniem prędkości działania i możliwości przenoszenia. Dokładny opis algorytmu DESX zawarto w projekcie, który jest dostępny w Internecie pod nazwą Draft — simpson — desx — 02.txt, „The ESP DES XEX3 — CBC Transform”. Z grubsza biorąc proces szyfrowania pliku za pomocą algorytmu DESX przebiega trójstopniowo:

• Najpierw algorytm dzieli plik na 64-bitowe części zwane blokami, szyfruje każdy blok przy pomocy 64-bitowego klucza, wykorzystując zwykły algorytm XOR.

• Następnie, wykorzystując oddzielny klucz 56-bitowy, szyfruje zaszyfrowany uprzednio blok, tym razem wykorzystując standardowy algorytm DES.

• Na koniec ten sam blok zostaje zaszyfrowany za pomocą algorytmu XOR, używającego innego klucza 64-bitowego.

Złożenie tych trzech kroków daje w wyniku plik zaszyfrowany, który jest równorzędny w stosunku do szyfrowania standardowym algorytmem DES, jeśli chodzi o odporność na wyrafinowane próby odszyfrowania, ale jest o wiele, wiele słabiej podatny na ataki z wyszukiwaniem klucza.

Usługa EFS szyfrując pliki generuje liczbę losową, tzw. klucz szyfrowania plików (File Encryption Key — FEK). W wersji amerykańskiej Windows 2000 klucz FEK jest 128-bitowy, w wersji międzynarodowej — 56-bitowy.

Algorytm DESX jest symetryczny, to znaczy, że ten sam klucz jest wykorzystywany zarówno do szyfrowania jak i do odszyfrowywania plików. Ta właściwość powoduje, że jest on idealnym rozwiązaniem w przypadku usługi EFS, ale również wymaga ścisłej ochrony klucza. Szyfrowanie plików, oznaczające dla komputera łamiącego szyfr miliony lat pracy poświęconych na znalezienie klucza, nie ma sensu, jeśli użytkownik pozostawi klucz w miejscu dostępnym dla każdego.

Microsoft chroni klucz FEK szyfrując go za pomocą systemu szyfrowania z kluczem publicznym (Public Key Cryptography System — PKCS). Jest to jeden z najbezpieczniejszych systemów szyfrowania dostępnych obecnie.

Należy zachować szczególną ostrożność przy pracy z usługą EFS. Możliwych jest kilka sposobów postępowania:

• Plik jest szyfrowany za pomocą algorytmu DESX z kluczem FEK wykorzystanym jako klucz szyfru.

• Klucz FEK jest szyfrowany za pomocą technologii klucza publicznego/prywatnego, przy czym klucz publiczny jest używany do szyfrowania FEK, a klucz prywatny do odszyfrowania go.

• Klucz prywatny używany do odszyfrowania FEK jest zaszyfrowany za pomocą funkcji skrótu MD4 (MD4 hash) hasła użytkownika.

• Pary kluczy publiczny/prywatny mogą być wysłane do przenośnego certyfikatu, który jest szyfrowany za pomocą specjalnego hasła podawanego przez użytkownika, kiedy para kluczy jest eksportowana.

Każda z tych strategii szyfrowania ogrywa rolę w sposobie zarządzania usługą EFS. Zanim zagłębimy się w szczegółach dotyczących PKCS, nastąpi dokończenie opisu szyfrowania pliku.

Po co dwa klucze?

Windows 2000 do szyfrowania plików nie korzysta bezpośrednio z PKCS ze względu na szybkość działania. Algorytmy szyfrowania wykorzystywane przez PKCS są niezwykle bezpieczne, ale bardzo wolne i obciążające procesor. Kombinacja umiarkowanie bezpiecznego szyfrowania plików z bardzo bezpieczną ochroną klucza pozwala na uzyskanie akceptowalnego poziomu zabezpieczenia oraz wydajności systemu.

Budowa plików zaszyfrowanych

Plik w stanie niezaszyfrowanym ma atrybut $Data, wiernie odtwarzający strumień bajtów zapisany przez aplikację, która utworzyła dany plik. Na przykład po uruchomienie programu Notepad, wpisaniu kilka razy słowa text, a następnie zapisaniu tego do pliku, atrybut $Data tego pliku będzie zawierał znaki text text text.

Zwróćmy uwagę na rysunek 14.16. Kiedy użytkownik szyfruje ten plik, sterownik Efs.sys najpierw kopiuje dane do pliku tymczasowego, EFS0.TMP. Następnie EFS szyfruje dane, a wynik zapisuje z powrotem na dysk w położenie, z którego dane pochodziły. Jak podano poprzednio, usługa EFS wykorzystuje do szyfrowania algorytm DESX ze 128-bitowym kluczem tzw. FEK.

Klucz FEK musi pozostać bezpieczny, bo inaczej bezpieczeństwo pliku zaszyfrowanego jest zagrożone. Usługa EFS szyfruje klucz FEK wykorzystując do tego celu klucz publiczny.

--> Rysunek 14.16. Budowa pliku zaszyfrowanego To nie jest rysunek zgodny z oryginałem.[Author:E]

Kiedy użytkownik szyfruje pliki, usługa EFS współpracuje z LSA, aby uzyskać kopię klucza publicznego użytkownika. Klucz publiczny użytkownika jest ogólnie dostępny. Cokolwiek zostało zaszyfrowane za pomocą klucza publicznego użytkownika, można odszyfrować tylko używając klucza prywatnego użytkownika.

Klucz publiczny użytkownika jest zawarty w certyfikacie potwierdzającym autentyczność klucza. Kopia certyfikatu jest zapamiętana razem z zaszyfrowanym kluczem FEK w specjalnym polu o nazwie Data Decryption Field (DDF).

Oprócz szyfrowania klucza FEK za pomocą klucza publicznego użytkownika, usługa EFS szyfruje również klucz FEK stosując klucz publiczny przypisany do konta wyznaczonego na agenta odzyskiwania danych (Data Recovery Agent — DRA). W domenie rolę agenta DRA spełnia konto Administrator.

Agent DRA spełnia rolę dublera, mogącego odszyfrować plik, jeśli użytkownik, który zaszyfrował plik jest nieosiągalny. Dla usługi EFS agent DRA jest tak ważny, że odmówi zaszyfrowania pliku, dopóki nie będzie certyfikatu dla przynajmniej jednego użytkownika DRA. Więcej informacji zawartych jest w paragrafie „Odzyskiwanie plików zaszyfrowanych”. Kopia certyfikatu klucza publicznego DRA jest przechowywana razem z zaszyfrowanym kluczem FEK w polu danych o nazwie Data Recovery Field (DRF).

Obydwa pola danych usługi EFS, DDF i DRF, są zapisane w specjalnym atrybucie pliku noszącym nazwę $Logged_Utility_Stream. Atrybut ten przypomina strumień danych definiowany przez użytkownika (named data stream), zapamiętywany wraz z plikiem. Kiedy usługa EFS ma dokonać deszyfracji pliku, znajduje nazwę szyfranta w polu DDF w atrybucie $Logged_Utility_Stream i wykorzystuje jako podpowiedź do poszukiwania klucza prywatnego do odszyfrowania klucza FEK. Atrybut pliku $Data może być odszyfrowany po odszyfrowaniu klucza FEK.

Fakt, że certyfikaty klucza publicznego towarzyszą plikowi zapisanemu otwartym tekstem, nie stanowi żadnego problemu dla bezpieczeństwa. Klucz publiczny mógłby być podany w postaci czerwonego neonu i nie miałby żadnego wpływu na bezpieczeństwo. Klucz FEK można odszyfrować tylko używając klucza prywatnego, który jest zapamiętany w profilu użytkownika, zaszyfrowanym za pomocą hasła użytkownika.

Kolejność zdarzeń przy kolejnym otwieraniu pliku przez użytkownika jest następująca:

• Usługa EFS odczytuje atrybut $Logged_Utility_Stream i znajduje certyfikat dla użytkownika.

• Usługa EFS kontaktuje się z LSA uzyskując klucz prywatny użytkownika.

• EFS wykorzystuje klucz prywatny do odszyfrowania klucza FEK.

• Usługa EFS wykorzystuje klucz FEK do odszyfrowania pliku w pamięci, a następnie dostarcza odszyfrowany strumień bajtów do aplikacji.

Usługa EFS jest nadrzędna w stosunku do systemu plików NTFS, więc wszystkie operacje systemowe, takie jak pliki stronicowania, dzienniki śledzenia transakcji (transaction tracking logs) i dzienniki USN mogące mieć wpływ na zawartość pliku, pozostają zaszyfrowane.

Jak ominąć tworzenie plików tymczasowych EFS

Plik tymczasowy usługi EFS jest podwójnie ukryty, tzn. że jest jednocześnie plikiem ukrytym (hidden) i systemowym (system) i można zablokować podgląd przez użytkownika poprzez odpowiednie ustawienia założeń systemowych dotyczących grup (group policy). To nie oznacza, że dane na dysku są ukryte. Zawartość pliku tymczasowego podaną otwartym tekstem można w łatwy sposób zobaczyć za pomocą edytora pozwalającego na odczytywanie danych w postaci szesnastkowej. W trakcie szyfrowania następny plik zostanie zapisany częściowo lub całkowicie na miejscu pliku tymczasowego EFS0.TMP, mogą jednak nadal pozostać ślady, które dadzą się odczytać bez zastosowania wyszukanych urządzeń do skanowania dysku. Z tego względu nie zaleca się szyfrowania pojedynczych plików.

Zawsze należy ustawić zezwolenie szyfrowania plików dla foldera, a następnie utworzyć nowe pliki w tym folderze. Pliki zapisywane na dysk są szyfrowane i nie pozostawiają w plikach tymczasowych żadnych niezabezpieczonych pozostałości.

Budowa plików usługi EFS zapisanych na dysku

W niniejszym paragrafie zawarto opis atrybutów $Data i $Logged_Utility_Stream pliku przed i po zaszyfrowaniu, pokazujący zmiany dokonane w pliku i wykorzystanie nowych elementów.

Poniższy wydruk przedstawia przykładowy atrybut $Data przed zaszyfrowaniem. Zachowano końcową część atrybutu $Filename.

<<końcowa część atrybutu $Filename pliku o nazwie file3.txt.>>

2000 0000 0000 0000 0903 6600 6900 6C00 ..........f.i.l.

6500 3300 2E00 7400 7800 7400 0000 0000 e.3...t.x.t.....

<<Atrybut $Data — kod typu. Blok danych atrybutu jest zapisany w rekordzie tablicy MFT (jest rezydentny).>>

8000 0000 6800 0000 0000 1800 0000 0100 ................

5000 0000 1800 0000 7465 7874 2074 6578 p.......text tex

7420 7465 7874 0D0A 7465 7874 2074 6578 t text..text tex

7420 7465 7874 0D0A 7465 7874 2074 6578 t text..text tex

7420 7465 7874 0D0A FFFF FFFF 8279 4711 t text........yG

Kolejny wydruk przedstawia atrybuty %Data i $Logged_Utility_Stream tego samego rekordu po zaszyfrowaniu.

<<końcowa część atrybutu $Filename pliku o nazwie file3.txt.>>

2000 0000 0000 0000 0903 6600 6900 6C00 ..........f.i.l.

6500 3300 2E00 7400 7800 7400 0000 0000 e.3...t.x.t.....

<<Atrybut %Data nie jest rezydentny. Numer LCN (wyróżniony czcionką pogrubioną) wskazuje lokalizację danych zaszyfrowanych.>>

8000 0000 4800 0000 0100 0000 0040 0500 ....H........@..

0000 0000 0000 0000 0000 0000 0000 0000 ................

4000 0000 0000 0000 0002 0000 0000 0000 @...............

7000 0000 0000 0000 7000 0000 0000 0000 p.......p.......

2101 1430 0002 0000

<<Atrybut $Logged_Utility_Stream - kod typu 100 (w notacji odwrotnej 0001). Numer LCN (wyróżniony czcionką pogrubioną) wskazuje lokalizację pola odzyskiwania danych (Data Recovery Field - DRF).>>

0001 0000 5000 0000 !..0........P...

0104 4000 0000 0400 0000 0000 0000 0000 ..@.............

0100 0000 0000 0000 4800 0000 0000 0000 ........H.......

0004 0000 0000 0000 7803 0000 0000 0000 ........x.......

7803 0000 0000 0000 2400 4500 4600 5300 x.......$.E.F.S.

2102 1230 0000 0000 FFFF FFFF 8279 4711 !..0.........yG.

Poniższy wydruk zawiera wyciąg z atrybutu $Logged_Utility_Stream przedstawiający pole DDF (Data Decryption Field) dla użytkownika i pole DRF (Data Recovery Field) dla agenta DRA.

<<Wyciąg z nierezydentnej części atrybutu $Logged_Utility_Stream przedstawia certyfikat użytkownika o nazwie bplum, który zaszyfrował plik. Liczba zapisana czcionką pogrubioną w części szesnastkowej wydruku jest odciskiem palca certyfikatu. Dane wyróżnione czcionką pogrubioną w części dziesiętnej wydruku oznaczają początek certyfikatu użytkownika.>>

7200 0000 C800 0000 C92E 531E FBBF 079F r.........S.....

50B7 4471 7A26 6C0C 4D3C 3F82 3400 3100 P.Dqz&l.M<?.4.1.

6500 3100 6300 3000 3000 3100 2D00 3700 e.1.c.0.0.1.-.7.

3100 3700 3300 2D00 3400 3200 3900 3600 1.7.3.-.4.2.9.6.

2D00 3900 3300 3100 3900 2D00 3200 6600 -.9.3.1.9.-.2.f.

6600 6600 3400 3200 6600 3600 6400 3800 f.f.4.2.f.6.d.8.

3100 3600 0000 4D00 6900 6300 7200 6F00 1.6...M.i.c.r.o.

7300 6F00 6600 7400 2000 4200 6100 7300 s.o.f.t. .B.a.s.

6500 2000 4300 7200 7900 7000 7400 6F00 e. .C.r.y.p.t.o.

6700 7200 6100 7000 6800 6900 6300 2000 g.r.a.p.h.i.c. .

5000 7200 6F00 7600 6900 6400 6500 7200 P.r.o.v.i.d.e.r.

2000 7600 3100 2E00 3000 0000 4F00 5500 .v.1...0...O.U.

3D00 4500 4600 5300 2000 4600 6900 6C00 =.E.F.S. .F.i.l.

6500 2000 4500 6e00 6300 7200 7900 7000 e. .E.n.c.r.y.p.

7400 6900 6F00 6E00 2000 4300 6500 7200 t.i.o.n. .C.e.r.

7400 6900 6600 6900 6300 6100 7400 6500 t.i.f.i.c.a.t.e.

2C00 2000 4C00 3D00 4500 4600 5300 2C00 ,. .L.=.E.F.S.,.

2000 4300 4E00 3D00 6200 7000 6C00 7500 .C.N.=.b.p.l.u.

6D00 0000 535E 9D13 3191 740F F2EA F70D m...S^..1.t.....

<<Poniższy fragment zawiera certyfikat dla agenta DRA, w tym przypadku jest to konto Administrator dla domeny. Odcisk palca certyfikatu odzyskiwania plików jest wyróżniony czcionką pogrubioną.>>

0000 0000 0000 0000 2800 0000 5672 B823 ........(...Vr.#

4097 749A 7949 3491 0531 30F9 478B 34AC @.t.yI4..10.G.4.

4F00 5500 3D00 4500 4600 5300 2000 4600 O.U.=.E.F.S. .F.

6900 6C00 6500 2000 4500 6E00 6300 7200 i.l.e. .E.n.c.r.

7900 7000 7400 6900 6F00 6E00 2000 4300 y.p.t.i.o.n. .C.

6500 7200 7400 6900 6600 6900 6300 6100 e.r.t.i.f.i.c.a.

7400 6500 2C00 2000 4C00 3D00 4500 4600 t.e.,. .L.=.E.F.

5300 2C00 2000 4300 4E00 3D00 4100 6400 S.,. .C.N.=.A.d.

6D00 6900 6E00 6900 7300 7400 7200 6100 m.i.n.i.s.t.r.a.

7400 6F00 7200 0000 6C1E 6E80 C8D0 E191 t.o.r...l.n.....

Usługi szyfrowania z wykorzystaniem klucza publicznego (Public Key Cryptography Services — PKCS) używane przez EFS

Do posługiwania się usługą EFS nie jest konieczna głęboka wiedza o kryptografii, ale zdecydowanie potrzebne jest dobre zrozumienie sposobu generowania, zapisywania i przekazywania certyfikatów. Niniejszy paragraf zawiera opis części składowych usług PKCS niezbędnych dla działania usługi EFS.

Tak samo jak DESX, szyfrowanie z wykorzystaniem klucza publicznego (PKCS) jest odwracalne, ale nie jest symetryczne, tzn. wykorzystuje dwa klucze: klucz publiczny do szyfrowania, a klucz prywatny do odszyfrowania.

Przy pierwszym szyfrowaniu pliku dla usługi EFS tworzona jest przez lokalnego dostawcę usług kryptograficznych (local crypto provider) para kluczy: publiczny i prywatny.

Klucz prywatny jest szyfrowany z wykorzystaniem tzw. funkcji skrótu MD4 (MD4 password hash). Klucz publiczny może być swobodnie rozpowszechniany. Pliki zaszyfrowane z wykorzystaniem klucza publicznego. Są doskonale bezpieczne tak długo, jak długo dostęp do klucza prywatnego ma tylko właściciel klucza.

EFS współpracuje z LSA w celu uzyskania kluczy EFS podczas szyfrowania i odszyfrowania. EFS szyfruje również klucz FEK za pomocą klucza należącego do agenta DRA. Więcej szczegółów podano w paragrafie „Rola agentów DRA”.

Klucze i certyfikaty usługi EFS

Zarządzanie kluczami jest krytyczne dla zabezpieczenia systemu PKCS. Szyfrowanie plików z wykorzystaniem klucza pochodzącego z niezaufanego źródła jest stratą czasu.

Każdy komputer z systemem Windows 2000 może wydawać klucze EFS. Klucze są wydawane przez LSA z pomocą dostawców usług kryptograficznych (cryptographic providers). Dostawcą usług kryptograficznych (Cryptographic Services Provider — CSP), wykorzystywanym do wydawania certyfikatów EFS jest Microsoft Base Cryptographic Provider v 1.0.

Kiedy użytkownik szyfruje plik po raz pierwszy, CSP generuje parę kluczy: publiczny/prywatny, o ile nie istnieje jeszcze klucz prywatny. Klucze publiczny i prywatny są zapisane jako pliki w profilu użytkownika na komputerze lokalnym. Na rysunku 14.17 pokazano lokalizację klucza i certyfikatu oraz wewnętrzną budowę pliku zaszyfrowanego. Kolejne dwa paragrafy zawierają szczegółowe informacje o kluczach publicznym i prywatnym.

--> Brak rysunku.[Author:E]

Rysunek 14.17. Lokalizacja klucza i certyfikatu EFS.

Private key used to decrypt FEK (Encrypted with users password hash) — Klucz prywatny używany do odszyfrowania klucza FEK (zaszyfrowany przy użyciu hasła użytkownika)

Public key used to encrypt user's copy of FEK — Klucz publiczny używany do zaszyfrowania kopii użytkownika klucza FEK.

Public key used to encrypt DRA copy of FEK (Administrator only) — Klucz publiczny używany do zaszyfrowania kopii agenta DRA klucza FEK (tylko dla administratora).

Wskazówki dotyczące Rejestru: dostawcy usług kryptograficznych (Cryptographic providers)

Lista dostawców usług kryptograficznych (cryptographic providers) znajduje się w kluczu HKLM|Software|Microsoft|Cryptography|Defaults|Provider.

Klucz prywatny wykorzystywany przez EFS

Klucz prywatny wykorzystywany przez EFS znajduje się w folderze \Documents and Settings\<userID>\Application Data\Microsoft\Protect\<userID>. Nazwa pliku odpowiada nagłówkowi klucza wewnątrz pliku. Klucz prywatny nie jest częścią EFS. Jest to klucz uniwersalny, mający różnorodne zastosowania. Jeśli klucz uniwersalny już istnieje, to wtedy staje się kluczem prywatnym związanym z EFS.

Klucz uniwersalny jest zaszyfrowany z wykorzystaniem hasła użytkownika. Po zmianie hasła użytkownika, LSA i CSP ponownie szyfrują klucz prywatny, używając nowego hasła.

Klucz uniwersalny ma podstawowe znaczenie dla właściwego działania EFS. Jeśli zostanie skasowany profil użytkownika, skasowany będzie również klucz uniwersalny. Bez klucza uniwersalnego użytkownik nie może odszyfrować klucza FEK. Bez klucza FEK użytkownik nie może otworzyć pliku zaszyfrowanego.

Ponieważ klucz uniwersalny jest zaszyfrowany przy użyciu hasła użytkownika, to jeśli użytkownik zostanie usunięty z domeny lub będzie utworzone nowe konto dla użytkownika, straci on dostęp do plików zaszyfrowanych. W takiej sytuacji agent DRA musi odzyskać pliki.

Jeśli użytkownik loguje się na komputerze lokalnym, szyfruje pliki, a następnie loguje się do domeny, to wtedy nie będzie mógł odczytać plików zaszyfrowanych. Konto użytkownika w domenie ma inny identyfikator SID i inny profil użytkownika. Administrator powinien nauczyć użytkowników laptopów wykorzystywania kont w domenie, nawet jeśli nie są podłączeni do sieci.

Poniżej podano najważniejsze informacje dotyczące kluczy prywatnych wykorzystywanych przez EFS:

• Klucz prywatny jest kluczem uniwersalnym, mającym różne zastosowania, nie tylko w EFS.

• Klucz uniwersalny jest konieczny do odczytania pliku zaszyfrowanego.

• Razem ze skasowaniem profilu użytkownika, kasuje się również klucz uniwersalny i użytkownik nie może odczytywać plików zaszyfrowanych.

Klucz publiczny usługi EFS

W odróżnieniu od klucza prywatnego, przechowywanego we właściwym sobie formacie, klucz publiczny jest przechowywany jako certyfikat usługi PKCS. Certyfikat jest plikiem zawierającym klucz publiczny, razem ze składnikami potwierdzającymi autentyczność klucza.

Certyfikat klucza publicznego jest przechowywany w profilu użytkownika w \Documents and Settings\<userID>\Application Data\Microsoft\SystemCertificates\My\Certificates. Nazwa pliku, w którym zapisany jest certyfikat, jest zgodna z odciskiem palca certyfikatu, 128-bitowym skrótem (message digest) umożliwiającym szybkie sprawdzenie tożsamości certyfikatu.

EFS uzyskuje certyfikat klucza publicznego użytkownika od dostawcy usług kryptograficznych (crypto provider) lokalnego autorytetu bezpieczeństwa (LSA). Wykorzystuje ten klucz do szyfrowania klucza FEK, a następnie zapisuje certyfikat w atrybucie $Logged_Utility_Stream pliku. Certyfikat klucza publicznego zawiera nazwę użytkownika osoby będącej właścicielem certyfikatu. To daje EFS wskazówkę, której potrzebuje do znalezienia klucza prywatnego użytkownika, kiedy nadejdzie czas odszyfrowania pliku.

Certyfikaty są wydawane dla specjalnych zastosowań podanych przez identyfikatory obiektów (Object Identifiers — OIDs). Więcej informacji podano w części pod tytułem „Certyfikaty identyfikatorów obiektów (OID)”. EFS stosuje dwa typy certyfikatów: Encrypting File System Certificate, OID 1.3.6.1.4.1.311.10.3.4, oraz File Recovery Certificate OID 1.3.6.1.4.1.311.10.3.4.1.

Certyfikat EFS generowany przez dostawcę usług kryptograficznych w komputerze lokalnym jest określany jako certyfikat podpisany przez samego siebie (self-signed certificate). Certyfikaty EFS mogą być także generowane przez Jednostkę certyfikującą (Certificate Authority — CA). EFS nie wymaga korzystania z jednostki certyfikującej (CA), ale jeśli jest dostępna, to lokalny dostawca usług kryptograficznych (CSP) wykorzystuje ją. Więcej informacji zawarto w części pod tytułem „Zarządzanie certyfikatami za pomocą jednostki certyfikującej (Certificate Authority)”.

Zarówno klucz uniwersalny jak i certyfikat klucza publicznego są przechowywane w części wędrującej profilu użytkownika. Oznacza to, że pliki zaszyfrowane przez użytkowników wędrujących na różnych komputerach wykorzystują tę samą parę kluczy: publiczny i prywatny. Inaczej dzieje się w przypadku użytkowników logujących się na różnych komputerach bez korzystania z profilu wędrującego, kiedy to dla każdego komputera wykorzystującego inny klucz uniwersalny generowany jest oddzielny certyfikat EFS.

W każdym przypadku efekt końcowy jest taki sam. Użytkownik ma wolny dostęp do plików zaszyfrowanych w każdym z lokalnych komputerów. Zaletą posiadania profilu wędrującego jest możliwość przesyłania plików pomiędzy komputerami używając usługi Backup nie zawracając sobie głowy eksportowaniem i importowaniem klucza uniwersalnego i certyfikatu EFS. Więcej informacji zawarto w części pod tytułem „Odzyskiwanie plików zaszyfrowanych”. Chociaż klucze i certyfikaty znajdują się w profilu wędrującym, same pliki zaszyfrowane nie mogą być umieszczone w profilu wędrującym, dopóki serwer macierzysty profilu nie jest skonfigurowany z opcją relacji zaufania Trusted for Delegation. Więcej informacji zawarto w części zatytułowanej „Zapisywanie plików zaszyfrowanych na serwerach zaufanych (trusted server)”.

Oto najważniejsze informacje dotyczące certyfikatu klucza publicznego EFS:

• Jest wydawany użytkownikowi przy pierwszym szyfrowaniu pliku.

• Klucz publiczny w certyfikacie EFS tworzy parę z uniwersalnym kluczem prywatnym stosowanym do odszyfrowania klucza FEK.

• Kopia certyfikatu klucza publicznego towarzyszy każdemu zaszyfrowanemu plikowi. EFS wykorzystuje ten certyfikat do określenia tożsamości szyfrującego, mogąc w ten sposób znaleźć położenie klucza prywatnego.

Wskazówki dotyczące Rejestru: identyfikator certyfikatu (Certificate ID)

Odcisk palca certyfikatu użytkownika EFS jest zapisany w kluczu HKCU|Software|Microsoft|Windows NT|CurrentVersion|EFS|Current Keys|Certificate Hash.

Certyfikaty

Certyfikat klucza publicznego użytkownika i plik zawierający zaszyfrowany klucz uniwersalny są zapisane w formacie nie dającym się przenosić. Jeśli zajdzie potrzeba przeniesienia ich do innego komputera, wtedy muszą być wyeksportowane w formacie, który może być kopiowany do innego komputera i importowany. Windows 2000 wykorzystuje następujące formaty certyfikatów:

• X.509 (.CER) wykorzystujące Distinguished Encoding Rules (DER)

• X.509 (.CER) wykorzystujące kodowanie Base-64

• PKCS #7 Cryptographic Message Syntax Standard (.P7B)

• PKCS #12 Personal Information Exchange (PFX)

Z powyższych czterech rodzajów certyfikatów pierwsze trzy są wykorzystywane do rozpowszechniania kluczy publicznych. Tylko ostatni rodzaj, certyfikaty PFX, mogą przechowywać pary kluczy publiczny/prywatny.

Format PFX wykorzystuje silne szyfrowanie (strong encryption) do przechowywania dwóch kluczy razem bez narażania ich na szwank. W celu zwiększenia bezpieczeństwa certyfikat agenta DRA musi być usunięty z systemu, jeśli nie jest używany, więc zdolność do bezpiecznego przechowywania i przenoszenia certyfikatów zawierających klucze prywatne ma podstawowe znaczenie dla sformułowania strategii odzyskiwania EFS.

Wydawanie certyfikatów identyfikatorów obiektów (Object Identifiers — OID)

Certyfikaty są wydawane dla różnych zastosowań podanych przez identyfikator OID przyporządkowany do certyfikatu. Umieszczenie identyfikatora OID w certyfikacie gwarantuje, że certyfikat może być użyty tylko zgodnie z przeznaczeniem.

Identyfikator OID jest unikatowym numerem zarejestrowanym przez instytucje uprawnione do tego przez International Standard Organization (ISO). W USA jest to American National Standard Institute (ANSI). Budowa i rozpowszechnianie identyfikatorów OID opisane są w normie ISO/IEC 8824:1990, Information Technology — Open Systems Interconnection — Specyfication of Abstract Syntax Notation One (ASN.1).

Inne aplikacje wykorzystujące identyfikatory OID obejmują protokół SNMP (Simple Network Management Protocol) i usługi X.500 Dierctory Services, takie jak Active Directory.

Rola agentów odzyskiwania danych (Data Recovery Agents — DRA)

Gdyby użytkownik, który zaszyfrował plik, był jedyną osobą będącą w stanie otworzyć ten plik ponownie, byłoby to przyczyną wielu kłopotów. W praktyce w EFS istnieje możliwość otwarcia pliku także przez jedno lub kilka kont ustanowionych agentami odzyskiwania danych DRA. Zależnie od konfiguracji domeny agentem DRA jest:

• Pojedynczy komputer z systemem Windows 2000 Professional. Domyślnym kontem agenta DRA jest konto Account.

• Pojedynczy komputer z systemem Windows 2000 Server. Agentem DRA jest konto Administrator przechowywane w lokalnej bazie danych SAM.

• Kontroler domeny lub komputer członkowski domeny Windows 2000. Agentem DRA jest konto Administrator przechowywane w Active Directory. Komputery członkowskie domeny nie mają lokalnych agentów DRA.

Agent DRA ma nadany certyfikat nazwany certyfikatem odzyskiwania pliku (File Recovery certificate), zawierający klucz publiczny, który tworzy parę z kluczem uniwersalnym należącym do agenta. Kiedy EFS szyfruje plik, szyfruje kopię klucza FEK kluczem publicznym z certyfikatu FR i umieszcza go razem z częścią certyfikatu FR w atrybucie pliku $Logged_Utility_Stream.

To pozwala agentowi DRA otworzyć plik w ten sam sposób, jak otwiera go użytkownik, który ten plik zaszyfrował. Nie angażuje to żadnego specjalnego mechanizmu odzyskiwania danych. Jeśli użytkownik z laptopem zalogował się do lokalnej bazy danych SAM i zaszyfrował plik, to można zalogować się jako Administrator i obejrzeć ten plik. Jedyny warunek jest taki, że plik musi znajdować się w tym samym komputerze, co klucz uniwersalny agenta DRA. Paragraf „Odzyskiwanie plików zaszyfrowanych” opisuje ochronę systemową certyfikatu FR i klucza uniwersalnego DRA.

EFS — Podsumowanie

Poniżej zamieszczono najważniejsze informacje pozwalające na najlepsze wykorzystanie EFS:

• EFS szyfruje atrybut danych pliku. Nie ma wpływu na inne atrybuty, takie jak deskryptor bezpieczeństwa (security descriptor) i nazwa pliku. Użytkownik z odpowiednimi uprawnieniami NTFS może zmienić nazwę lub skasować plik zaszyfrowany przez innego użytkownika.

• Jeśli plik jest kopiowany do woluminu FAT lub FAT32, to będzie zapisany w postaci niezaszyfrowanej.

• Jeśli aplikacja otwiera plik zaszyfrowany i tworzy pliki tymczasowe lub kopie zapasowe pliku na woluminie innym niż NTFS, to wtedy te pliki dodatkowe będą niezaszyfrowane. Należy upewnić się, czy foldery tymczasowe, wykorzystywane przez aplikację zostały przeszukane i również zaszyfrowane.

• EFS jest nadrzędny w stosunku do NTFS, więc zawartość pliku wysyłana do pliku stronicowania i dzienników śledzenia transakcji jest zaszyfrowana.

• Po ustawieniu znacznika szyfrowania dla folderu, jest on dziedziczony przez pliki tworzone w tym folderze. Kiedy plik jest szyfrowany w ten sposób, to wtedy nie tworzy się plików tymczasowych.

• Zaszyfrowanie foldera nie blokuje dostępu innym użytkownikom. Kiedy inni użytkownicy zapisują swoje pliki w folderze zaszyfrowanym, są one szyfrowane z wykorzystaniem klucza publicznego użytkownika, który utworzył plik.

• Kopiowanie lub przeniesienie pliku do foldera zaszyfrowanego powoduje zaszyfrowanie pliku.

• Pliki zaszyfrowane zachowują swój status po kopiowaniu lub przeniesieniu, o ile woluminem docelowym jest wolumin NTFS5.

• Certyfikaty użytkowników są zapisane w profilu lokalnym użytkownika. Należy pamiętać o tym przy kasowaniu profili uważanych za niepotrzebne. Po skasowaniu profilu użytkownika tylko agent DRA może przywrócić pliki. W komputerze pojedynczym, w razie skasowania profilu użytkownika i profilu agenta DRA, dostęp do plików zaszyfrowanych zostaje bezpowrotnie utracony.

• W normalnych warunkach nie można szyfrować plików poprzez sieć. Zanim na serwerze będzie można przechowywać pliki zaszyfrowane użytkowników sieciowych, serwer ten musi zostać skonfigurowany z opcją zaufania „Trusted for Delegation”. Więcej informacji w części zatytułowanej „Zapisywanie plików zaszyfrowanych na serwerach zaufanych”.

• Z tego samego powodu, jak powyżej, nie można szyfrować plików w profilu wędrującym, ponieważ profil jest kopiowany do serwera. Jeśli profil zawiera pliki zaszyfrowane, system odmówi replikacji profilu, o ile serwer nie będzie skonfigurowany z relacją zaufania „Trusted for Delegation”.

Poniżej podano listę dodatkowych ograniczeń EFS, które nie wynikają w sposób oczywisty z procesu szyfrowania i odszyfrowywania plików:

• Kopie zapasowe plików zaszyfrowanych pozostają zaszyfrowane. Wykorzystanie programu Backup do umieszczenia pliku zaszyfrowanego w kopii zapasowej jest jedyną metodą przenoszenia plików zaszyfrowanych pomiędzy komputerami, które nie znajdują się w relacji zaufania „Trusted for Delegation”.

• Pliki skompresowane nie mogą być szyfrowane. Pliki zaszyfrowane nie mogą być kompresowane.

• Pliki „rzadkie” (sparse files) mogą być szyfrowane i pozostają plikami „rzadkimi”.

• Pliki z wieloma strumieniami danych mogą być szyfrowane. Wszystkie strumienie danych są szyfrowane.

• Katalogi dołączania (mount points) i inne rekordy dynamicznych wskaźników lokalizacji danych (reparse records) nie mogą być szyfrowane. Sczegóły podano w rozdziale 13.

• Pliki systemowe nie mogą być szyfrowane. Sytem operacyjny odczytuje je w trakcie rozruchu, zanim EFS zostanie zainicjowany.

• Pliki zaszyfrowane nie mogą być dzielone z wykorzystaniem narzędzi dostarczonych z systemem Windows 2000. Istnieje wywołanie API, AddUsersToEncryptedFile(), które umożliwia dodanie certyfikatów EFS do pliku, aby wielu użytkowników mogło otwierać ten sam plik zaszyfrowany. Więcej informacji znajduje się w opisie Windows 2000 Platform SDK.

Szyfrowanie folderów i plików

W niniejszym paragrafie opisano, jak wykorzystywać Eksploratora i wiersz poleceń do szyfrowania i odszyfrowywania folderów i plików. Ustawianie atrybutu szyfrowania wymaga prawa dostępu do folderu Read/Write.

Założenia systemowe dotyczące agenta odzyskiwania danych (Encrypted Data Recovery Agents) muszą być aktywne w lokalnym komputerze, bądź też w domenie z przynajmniej jednym agentem DRA. Jeśli nie, to wystąpi błąd EFS i odmowa zaszyfrowania plików. Szczegóły zawarto w części pod tytułem „Zarządzanie założeniami systemowymi dotyczącymi odzyskiwania”.

Szyfrowanie folderu

Jedną z opcji szyfrowania folderu jest rozchodzenie się szyfrowania w głąb do podfolderów i plików. Podczas rozchodzenia się ustawień szyfrowania, EFS może napotkać plik zablokowany (locked file). W takiej sytuacji pojawi się ostrzeżenie z wyborem Ponów (Retry) lub Ignoruj (Ignore). Należy zanotować plik zablokowany (locked file) aby określić, czy powinien być zaszyfrowany.

Procedura 14.4. Szyfrowanie folderu z wykorzystaniem Eksploratora

1. Otwórz Eksploratora lub Mój komputer.

2. Przejdź do folderu, który chcesz zaszyfrować. W przykładach wykorzystano folder Moje Dokumenty. (Jeśli wykorzystujesz profil wędrujący, nie możesz szyfrować folderu Moje Dokumenty, ponieważ system nie zezwoli na zaszyfrowanie zawartości profilu wędrującego).

3. Kliknij prawym klawiszem myszy folder, który chcesz zaszyfrować i wybierz z menu opcję WŁAŚCIWOŚCI (PROPERTIES). Otworzy się okno Właściwości (Properties).

4. Naciśnij przycisk Zaawansowane (Advanced). Otworzy się okno Atrybuty zaawansowane (Advanced Atributes) (rysunek 14.18).

Rysunek 14.18. Okno Atrybuty zaawansowane (Advanced Attributes) pokazujące wybraną opcję Szyfruj zawartość (Encrypt contents).

5. Wybierz opcję Szyfruj zawartość, aby zabezpieczyć dane (Encrypt contents to secure data). Nie można wybrać jednocześnie tej opcji i opcji Kompresuj zawartość...(Compress contents). Interfejs traktuje te dwie pozycje jako pola opcji (radio button), chociaż wyglądają jak pola wyboru (checkbox).

6. Naciśnij przycisk OK, aby zapisać zmiany i powrócić do okna Właściwości (Properties). Folder nie został jeszcze zaszyfrowany.

7. Aby zaszyfrować folder, naciśnij przycisk OK. Pojawi się okno Potwierdź zmiany atrybutów (Confirm Attribute Changes).

8. Wybierz opcję Zastosuj zmiany do bieżącego folderu, podfolderów i plików (Apply Changes To This Folder, Subfolders and Files). To gwarantuje, że cała zawartość folderu i każdy podfolder utworzony przez użytkownika są zaszyfrowane od samego początku. Zapobiega to pozostawianiu niezaszyfrowanej zawartości plików tymczasowych EFS.

9. Kiedy atrybut szyfrowania jest ustawiony dla każdego pliku i podfolderu oraz odpowiednie pliki zostaną zaszyfrowane, okno Właściwości (Properties) foldera zamyka się.

Jeśli ustawiona jest opcja Enable Web content in folders dla folderu (FOLDER OPTIONS|PROPERTIES|VIEW) można zaznaczyć plik lub folder, aby pokazać status szyfrowania w liście Atrybuty (Attributes) w lewej części okna.

W innym przypadku nie ma żadnej widocznej wskazówki co do statusu szyfrowania. Nazwa użytkownika, który zaszyfrował nie jest ujawniana.

Szyfrowanie pojedynczych plików

Jeśli zostanie wybrane szyfrowanie jednego pliku zamiast całego folderu, EFS pokazuje ostrzeżenie (rysunek 14.19), mówiące o tym, że plik może zostać odszyfrowany kiedy zostanie zmodyfikowany. Jest również szansa ujawnienia niezaszyfrowanej zawartości pliku w pliku tymczasowym EFS, który jest stosowany do przechowywania pliku przed zaszyfrowaniem.

Rysunek 14.19. Ostrzeżenie o możliwości utraty ustawień odszyfrowania przy szyfrowaniu pojedynczych plików.

Wybór domyślny dokonany poprzez komunikat ostrzeżenia Szyfrowanie pliku i folderu macierzystego (Encrypt the file and the parent folder), gwarantuje, że plik pozostanie zaszyfrowany oraz że pliki, które będą umieszczone w przyszłości w tym folderze, będą szyfrowane bez wykorzystywania plików tymczasowych.

Szyfrowanie folderów i plików z wykorzystaniem wiersza poleceń

Jeśli wolisz wykorzystywać wiersz poleceń, do szyfrowania i odszyfrowania plików i folderów służy polecenie Cipher.

Procedura 14.5. Szyfrowanie folderów i plików z wykorzystaniem polecenia Cipher

1. Otwórz okno wiersza poleceń.

2. Przejdź do folderu zawierającego plik lub folder, który chcesz zaszyfrować.

3. Aby uzyskać listę bieżących ustawień dotyczących szyfrowania, wprowadź polecenie cipher. Nie ma możliwości uzyskania wykazu nazw użytkowników, którzy zaszyfrowali pliki lub foldery. Opcja ta ma znaleźć się w wersji maintenance.

4. Ustaw znacznik szyfrowania dla folderu wprowadzając polecenie cipher /e <nazwa_folderu>. Spowoduje to zaszyfrowanie każdego nowego pliku w danym folderze.

5. Zaszyfruj każdy z plików i podfolderów znajdujących się w wybranym folderze wprowadzając polecenie cipher /e /a <nazwa_folderu>\*.*.

6. Wprowadzając ponownie polecenie cipher można zobaczyć wynik szyfrowania. Oto próbka:

C:\test\subtest\>cipher \test\*.*

Listing c:\test\

Nowe pliki dodane do tego katalogu będą zaszyfrowane.

E testfile.1

E testfile.2

E subdir

Powyższy wydruk pokazuje, że folder test ma ustawiony wskaźnik szyfrowania, wszystkie pliki znajdujące się aktualnie w wybranym folderze są zaszyfrowane i podfoldery mają ustawione wskaźniki szyfrowania.

Poniżej przedstawiono dodatkowe wykorzystanie polecenia cipher:

• Aby zaszyfrować tylko folder, wprowadź polecenie cipher /e nazwa_folderu. Można również podać ścieżkę dostępu zamiast folderu, np. cipher /e \top_folder\middle_folder\bottom_folder.

• Odszyfrowanie folderu następuje po wprowadzeniu polecenia cipher /d nazwa_folderu.

• Aby zaszyfrować tylko jeden plik, wykorzystaj parametr /a: cipher /e /a nazwa_pliku.

• W celu zaszyfrowania lub odszyfrowania wszystkich podfolderów, dodaj parametr /s:<nazwa_folderu> i podaj pierwszy folder w ścieżce dostępu. Ten folder i wszystkie podfoldery będą miały ustawiony znacznik szyfrowania.

• W trakcie szyfrowania podfolderów rozchodzenie się szyfrowania jest zatrzymywane w razie wystąpienia błędu. Jeśli chcesz, by rozchodzenie się szyfrowania było kontynuowane automatycznie po wystąpieniu błędu, dodaj parametr /i : cipher /e /i /s:\<nazwa_foldera>.

• W trakcie rozchodzenia się ustawień szyfrowania EFS pomija pliki i foldery mające już ustawienia szyfrowania. Jeśli chcesz ponownie zaszyfrować pliki i foldery, które zostały poprzednio zaszyfrowane przez tego samego użytkownika, zastosuj parametr /f: cipher /e /f /s:<nazwa_foldera>.

• W trakcie szyfrowania lub rozchodzenia się ustawień szyfrowania, pliki i foldery ukryte są pomijane. Jeśli chcesz zaszyfrować pliki i foldery ukryte dodaj parametr /h: cipher /e /h /s:<nazwa_folderu>.

Certyfikaty osobiste

Kiedy użytkownik szyfruje plik pierwszy raz, system lokalny generuje parę kluczy publiczny/prywatny dla EFS, jeśli klucz uniwersalny jeszcze nie istnieje. Jeśli klucz uniwersalny już istnieje, EFS generuje klucz publiczny do pary z istniejącym kluczem uniwersalnym.

Kolejne trzy paragrafy opisują, jak wykonać następujące operacje:

• Podgląd certyfikatów osobistych.

• Eksportowanie certyfikatu osobistego do innego formatu w celu przeniesienia na inny komputer lub zapisania na dyskietce lub CD. Jest to często wymagane, kiedy przesyła się klucze EFS użytkownika do innego komputera. Wymaganie takie dotyczy również eksportowania certyfikatu odzyskiwania (File Recovery certificate) przed usunięciem go dla zachowania bezpieczeństwa.

• Importowanie certyfikatu wyeksportowanego do innego komputera. Jest to częste wymaganie w przypadku, jeśli plik zaszyfrowany musi być odzyskany z wykorzystaniem certyfikatu odzyskiwania (File Recovery certificate).

Podgląd certyfikatów osobistych

Aby obejrzeć zawartość lokalnego certyfikatu, użytkownik musi zalogować się na konsoli komputera, gdzie przechowuje się takie certyfikaty. Zawartość można oglądać za pomocą wtyczki (snap-in) konsoli MMC o nazwie Certyfikaty (Certificates). Kroki opisane w tym paragrafie tworzą konsolę MMC użytkownika do oglądania wtyczki (snap-in) o nazwie Certfikaty (Certificates).

Wtyczki (snap-in) Certyfikaty (Certificates) pokazują karty uwierzytelniające (tickets), wydane dla danego konta. Mając uprawnienia administratora można także zobaczyć certyfikaty wydane dla systemu lokalnego. Nie można zobaczyć certyfikatów wydanych dla innych użytkowników. Można także wykorzystać wtyczki (snap-in) do eksportowania i importowania certyfikatów i otrzymać nowe certyfikaty od jednostki certyfikującej (Certification Authority — CA), o ile taka istnieje. Więcej informacji podano w paragrafie „Certyfikaty odzyskiwania plików” w dalszej części rozdziału.

Procedura 14.6. Oglądanie certyfikatów osobistych

1. Otwórz pustą konsolę MMC, wykorzystując START|RUN|MMC.

2. Z menu konsoli wybierz pozycję KONSOLA (CONSOLE)|DODAJ/USUŃ PRZYSTAWKĘ (ADD/ REMOVE SNA -IN). Otworzy się okno Dodaj/Usuń przystawkę (Add/Remove Snap-in).

3. Naciśnij przycisk Dodaj (Add). Otworzy się okno Dodaj pojedynczą przystawkę (Add Standalone Snap-in).

4. Aby załadować przystawkę (snap-in), kliknij dwukrotnie na pozycji Certyfikaty (Certificates). Jeśli jesteś zalogowany na konto, które nie ma uprawnień administratora, jedyną możliwością jest załadowanie certyfikatu osobistego. Jest to wykonywane automatycznie.

5. Jeśli konto ma uprawnienia administratora, otworzy się okno Przystawka certyfikatów (Certificates Snap-in). Poniżej przedstawiono informacje dotyczące dokonywania wyboru.

Opcje wyboru certyfikatu

Wtyczki certyfikatów (snap-in) oferują następujące opcje ładowania podglądu certyfikatów:

Opcja Moje konto użytkownika (My User Account) powoduje otwarcie certyfikatów w profilu użytkownika w folderze \Documents and Settings\<logonID>\Application Data\Microsoft\SystemCertificates\My\Certificates razem z certyfikatami osobistymi zapisanymi w obiekcie Directory użytkownika.

Opcja Konto serwisowe (Service Account) otwiera okno Wybierz komputer (Select Computer), a następnie przedstawia listę usług zainstalowanych w wybranym komputerze. Po wybraniu usługi korzystającej z certyfikatu, będzie ona dodana do wykazu certyfikatów zarządzanych poprzez konsolę. Opcja ta jest przydatna w przypadku usuwania problemów związanych z podpisem cyfrowym (Digital Signing).

Opcja Konto komputera (Computer Account) otwiera okno Wybierz komputer (Select Computer). Po wybraniu konta komputera, wtyczka (snap-in) otwiera certyfikaty komputera zapisane w kluczu Rejestru HKLM|Software|Microsoft|SystemCertificates|My|Certificates. Można obejrzeć certyfikaty lokalne i certyfikaty komputerów zdalnych, o ile użytkownik ma uprawnienia administratora dla tych komputerów. W normalnych warunkach komputery z systemem Windows 2000 Professional nie mają certyfikatów osobistych. Serwer członkowski domeny Windows 2000 będzie miał certyfikat Podpis cyfrowy (Digital Signing), jeśli zainstalowano Jednostkę certyfikującą (Certificate Authority). Ten certyfikat nie jest używany przez EFS.

6. Po załadowaniu przystawki (snap-in) zapisz konsolę pod opisową nazwą, np. Cert.msc. Możesz zapamiętać konsolę w folderze \WINNT\System32 razem z pozostałymi konsolami, tak aby każdy, kto zaloguje się do komputera mógł z niej korzystać. Konsola nie wskazuje na twój certyfikat. Ładuje certyfikaty użytkownika, który utworzył tą konsolę.

Rozszerz drzewo do pozycji Certificates — Current User|Personal|Certificates. Wykaz wszystkich certyfikatów wystawionych użytkownikowi znajduje się w prawym panelu. Przykład przedstawiony jest na rysunku 14.20. Kolumna Przeznaczenie (Intended Purpose) zawiera wykaz celów, dla których certyfikat został wydany. Jest określone przez identyfikator OID związany z certyfikatem. Przykład przedstawia dwa certyfikaty: jeden dla EFS, drugi dla usługi odzyskiwania plików (File Recovery), konto Administratora domeny, który jest jednocześnie domyślnym agentem DRA domeny. Agent DRA posiada dwa certyfikaty: jeden dla EFS a drugi dla usługi odzyskiwania plików (File Recovery).

Rysunek 14.20. Konsola Certyfikaty (Certificates) przedstawiająca certyfikaty osobiste użytkownika.

8. Kliknij prawym klawiszem myszy na ikonie Certyfikaty (Certificates) i wybierz z menu pozycję Właściwości (Properties). Otworzy się okno Właściwości (Properties) (rys. 14.21).

Rysunek 14.21. Okno Właściwości certyfikatów (Certificates Properties) przedstawiające cel Odzyskiwanie plików (File Recovery) i wybraną opcję Zezwolenie dla wszystkich zadań (Enable All Purposes...). Jest to konfiguracja domyślna dla tego certyfikatu.

Każde z zadań certyfikatu jest podane razem z opcjami całkowitego zablokowania certyfikatu lub wyłączenia poszczególnych zadań. Wyłączenie Odzyskiwania plików (File Recovery) dla tego certyfikatu uniemożliwiłoby Administratorowi otwieranie, kopiowanie lub przenoszenie plików zaszyfrowanych poza plikami zaszyfrowanymi przez konto Administrator w danym komputerze.

9. Aby zamknąć okno naciśnij przycisk OK.

10. Aby otworzyć okno Certyfikaty (Certificates), kliknij dwukrotnie na ikonie Certyfikaty (Certificates). Zakładka Ogólne (General) podaje odpowiednie informacje dotyczące pochodzenia i daty ważności certyfikatu.

11. Wybierz zakładkę Szczegóły (Details). Przykład pokazano na rysunku 14.22. Zakładka przedstawia specjalne informacje z certyfikatu. Zaznaczenie pozycji powoduje wyświetlenie całej informacji w dolnej części okna.

Rysunek 14.22. Okno Certyfikat (Certificate) — zakładka Szczegóły (Details) przedstawiająca informacje o Wydającym certyfikat (Issuer).

Część certyfikatu o nazwie Temat (Subject) razem z odciskiem palca, umieszczonym w dolnej części listy Pole (Field), jest zapisana w atrybucie $Logged_Utility_Stream każdego z zaszyfrowanych plików. Ta informacja mówi EFS, którego certyfikatu użyć do odszyfrowania klucza szyfrowania plików (File Encryption Key — FEK).

Opcja Kopiuj do pliku (Copy to file) uruchamia Kreatora eksportu certyfikatów (Certificate Export Wizard), który zezwala na skopiowanie certyfikatu w formie dogodnej do zapisywania lub przesłania do innego komputera w celu importowania. Działanie tego kreatora jest opisane w następnym paragrafie.

12. Wybierz zakładkę Ścieżka zaświadczania (Certification Path), która przedstawia ścieżkę Brak zaufania (Untrusted) oznaczoną czerwonym znakiem X, jeśli certyfikat nie został wydany przez Jednostkę certyfikującą (Certification Authority).

13. Aby zamknąć okno i powrócić do konsoli Certyfikaty (Certificates), naciśnij OK.

14. Zamknij konsolę. Zapisz ustawienia konsoli.

Eksportowanie certyfikatów osobistych

Jeśli użytkownik zmienia komputery i chce przenieść pliki zaszyfrowane ze starego komputera do nowego, to dla administratora jest to kawałek roboty. Nie można po prostu skopiować plików zaszyfrowanych poprzez sieć do nowego komputera. Taka próba zakończy się komunikatem o błędzie „Brak dostępu” (access denied) i informacją o tym, że plik może być w użyciu. Dzieje się tak, ponieważ sterownik EFS pracuje w środowisku ochrony (security context) systemu lokalnego (Local System). System lokalny pracujący na jednym komputerze nie ma dostępu do klucza prywatnego zapisanego w certyfikacie użytkownika w innym komputerze.

Problem jest dwuetapowy. Trzeba w jakiś sposób przesłać pliki zaszyfrowane do nowego komputera, a także przenieść do nowego komputera certyfikat użytkownika EFS żeby można było odczytywać te pliki. Konieczne jest podjęcie następujących działań:

• Wykonanie kopii zapasowej. Nie można bezpośrednio skopiować plików, ale można wykorzystać zalety programu Windows 2000 Backup i skopiować wszystkie pliki do pliku kopii zapasowej. Do wykonania kopii zapasowej nie jest konieczny certyfikat PKCS. Instrukcja stosowania programu Backup znajduje się w rozdziale 18: „Odzyskiwanie po awariach systemu”.

• Konfiguracja profilu wędrującego. Najprostszym sposobem przesłania certyfikatu użytkownika EFS jest konfiguracja profilu wędrującego użytkownika. Certyfikaty EFS są zapisane w profilu użytkownika, więc zostaną skopiowane do drugiego komputera po zalogowaniu się użytkownika.

Jeśli administrator nie chce wykorzystywać profilu wędrującego, alternatywą jest eksport kopii certyfikatu użytkownika EFS z komputera macierzystego i import do nowego komputera. Nie można po prostu skopiować plików certyfikatów z profilu użytkownika. Musi nastąpić aktualizacja kluczy Rejestru, co jest przyczyną dokonywania importu.

Operacje eksportu/importu muszą być wykonane podczas pracy na koncie użytkownika, ponieważ wymagają otwarcia klucza prywatnego użytkownika. Można tego dokonać tylko w środowisku ochrony użytkownika, ponieważ klucz prywatny jest szyfrowany za pomocą tzw. funkcji skrótu (user's password hash). Nie można wykonać pracy z jakiegoś położenia centralnego.

Aby zobaczyć i eksportować certyfikat, konieczna będzie wtyczka (snap-in) Certyfikat konsoli MMC (MMC Certificate). Najłatwiej można tego dokonać ładując wtyczkę (snap-in) do konsoli MMC. W części zatytułowanej „Podgląd certyfikatów osobistych” (Viewing Personal Certificates) opisano kroki tworzenia konsoli Certyfikat (Certificate).

Kolejne kroki pokazują, jak jak eksportować prywatne i publiczne klucze użytkownika z jednego komputera, a następnie importować do drugiego. W przykładzie przyjęto, że pliki użytkownika zostały już przeniesione za pomocą programu Backup. Użytkownik nie może otworzyć plików, dopóki nie zostaną także przeniesione klucze EFS.

Należy postępować zgodnie z poniższym opisem:

Procedura 14.7. Eksportowanie klucza publicznego i prywatnego użytkownika EFS

1. Zaloguj się na konsoli pierwszego komputera, tego w którym obecnie znajduje się certyfikat EFS.

2. Otwórz konsolę Certyfikaty (Certificates).

3. Przejdź do gałęzi drzewa Certificates — Current User|Personal|Certificates. Jeśli nie ma żadnego certyfikatu to oznacza, że zalogowałeś się na nieprawidłowym komputerze lub wykorzystujesz złe konto. W przeciwnym razie oznacza to, że użytkownik był w błędzie i nigdy nie szyfrował plików w danym komputerze.

4. Kliknij prawym klawiszem myszy certyfikat System szyfrowania plików (Encrypting File System) i wybierz z menu pozycję WSZYSTKIE ZADANIA|EKSPORT (ALL TASKS|EXPORT). Uruchomi się Kreator eksportowania certyfikatu (Certificate Export Wizard). Jeśli na liście znajduje się kilka certyfikatów, poszukiwany certyfikat Systemu szyfrowania plików (Encrypting File System) znajdziesz na podstawie informacji w kolumnie Przeznaczenie (Intended Purpose).

5. Kliknij Dalej (Next). Otworzy się okno Eksportuj klucz prywatny (Eksport Private Key).

6. Wybierz opcję Tak, eksportuj klucz prywatny (Yes, export private key). Certyfikat musi zawierać klucz prywatny użytkownika, więc EFS może wykorzystać go do odszyfrowania klucza FEK i uzyskania szyfru. Powszechnie popełnianym błędem jest eksportowanie tylko klucza publicznego do pliku X.509 CER. Plik ten może być importowany do drugiego komputera, ale nie może być wykorzystany do otwierania plików zaszyfrowanych.

7. Naciśnij Dalej (Next). Otworzy się okno Format pliku eksportowanego (Export File Format), rysunek 14.23. Plik eksportowany musi być zapisany w formacie PFX, ponieważ zawiera obydwa klucze i wymaga dodatkowej ochrony. Pozostaw wybraną opcję Ustaw wysoki poziom zabezpieczeń (Enable strong protection).

Rysunek 14.23. Kreator eksportu certyfikatów (Certificate Export Wizard) — Format pliku eksportowanego (Export File Format).

8. Naciśnij Dalej (Next). Otworzy się okno Hasło (Password). Wprowadź hasło i potwierdź je. Nie ma żadnych wymagań co do złożoności hasła, ale im hasło dłuższe i zawiera mniej znaków alfanumerycznych, tym lepiej.

9. Naciśnij Dalej (Next). Otworzy się okno Plik do eksportu (File To Export). Wprowadź nazwę, którą chcesz nadać certyfikatowi eksportowanemu. Nazwa nie ma znaczenia dla szyfrowania. Powinna zawierać identyfikator logowania użytkownika (logon ID). Podaj wyjściowy folder lokalny.

10. Naciśnij Dalej (Next). Otworzy się okno zakończenia.

11. Naciśnij Zakończ (Finish). Kreator wyświetli komunikat o poprawnym zakończeniu eksportowania.

12. Zamknij konsolę Certyfikaty (Certificates).

Na tym etapie mamy plik PFX zawierający certyfikat EFS użytkownika. Należy skopiować ten plik do drugiego komputera i skasować go z komputera pierwszego, tak dla porządku. Zawartość plików jest w większej części niedostępna dla postronnych, ale nigdy nie wiadomo, kto może znać hasło użytkownika i uzyskać dostęp do certyfikatu, aby go zaimportować.

Importowanie certyfikatów usługi EFS

Teraz, mając certyfikat PFX użytkownika skopiowany już do drugiego komputera, zaloguj się tam z upoważnieniem użytkownika. Jeśli użytkownik szyfrował już pliki na tym komputerze, będzie istniał także certyfikat EFS dla tego użytkownika. Importowany certyfikat EFS będzie działał obok istniejącego już certyfikatu EFS.

Procedura 14.8. Importowanie certyfikatów EFS

1. Zaloguj się na konsoli komputera docelowego z pełnomocnictwami użytkownika.

2. Otwórz konsolę Certyfikaty (Certificates).

3. Przejdź do gałęzi drzewa Certyfikaty — Aktualny użytkownik|Osobiste|Certyfikaty ( Certificates — Current User|Personal|Certificates). Jeśli taka pozycja nie istnieje, oznacza to, że użytkownik jeszcze nie szyfrował plików na tym komputerze.

4. Kliknij prawym klawiszem myszy na ikonie Certyfikaty (Certificates) (lub na ikonie Osobiste (Personal), o ile nie ma ikony Certyfikaty (Certificates)) i z menu wybierz pozycję WSZYSTKIE ZADANIA|IMPORT (ALL TASKS|IMPORT). Uruchomiony zostanie Kreator importowania certyfikatu (Certificate Import Wizard).

5. Naciśnij Dalej (Next). Otworzy się okno Plik do importu (File To Import). Naciśnij Przeglądaj (Browse). Przejdź do miejsca, w którym znajduje się skopiowany plik PFX i wybierz go.

6. Naciśnij Dalej (Next). Otworzy się okno Hasło (Password).

7. Wprowadź hasło przypisane plikowi przed eksportem.

8. Naciśnij Dalej (Next). Otworzy się okno Zachowaj certyfikat (Certificate Store). Pozostaw wybraną opcję Umieść wszystkie certyfikaty w następującym miejscu (Place all certificates in the following store) i przypisz Magazyn certyfikatów (Certificate Store) dla folderu Osobiste (Personal).

9. Naciśnij Dalej (Next). Pojawi się okno końcowe podsumowujące twój wybór.

10. Naciśnij Zakończ (Finish). Kreator poinformuje o zakończeniu importu certyfikatu.

11. Zaznacz ikonę Osobiste|Certyfikaty (Personal|Certificates) i sprawdź, czy nowy certyfikat znajduje się na liście w prawym panelu okna i ma podane przeznaczenie System szyfrowania plików (Encrypting File System).

12. Zamknij konsolę Certyfikaty (Certificates).

13. Wykorzystując Eksploratora, spróbuj otworzyć plik zaszyfrowany z innego komputera. Plik powinien się otworzyć wskazując, że importowano właściwy certyfikat.

Odzyskiwanie plików zaszyfrowanych

Jeśli użytkownik nie jest w stanie otworzyć pliku zaszyfrowanego, plik taki może zostać otwarty przez agenta DRA. Agent DRA jest w stanie otworzyć plik, ponieważ EFS przechowuje kopię klucza FEK zaszyfrowanego przy użyciu klucza publicznego znajdującego się w certyfikacie Odzyskiwanie plików (File Recovery —FR), wystawionym agentowi DRA. Agent DRA ogląda plik zaszyfrowany używając klucza prywatnego, związanego z certyfikatem odzyskiwania plików (FR).

Nie istnieje żaden specjalny mechanizm odzyskiwania ani aplikacja odzyskująca, która byłaby konieczna do odzyskania pliku. Agent odzyskiwania (Recovery Agent) po prostu otwiera plik zaszyfrowany, dokładnie tak samo, jak zrobiłby to użytkownik.

W bieżącym paragrafie opisano:

• Sposób wybierania domyślnych agentów DRA.

• Sposób wykorzystania certyfikatu Odzyskiwanie plików (File Recovery certificate) do odzyskiwania plików na pojedynczych komputerach i komputerach w domenie.

• Konfiguracja, zarządzanie i rozpowszechnianie zasad odzyskiwania plików (recovery policies).

Domyślni agenci odzyskiwania danych (Data Recovery Agents — DRA)

EFS wybiera agenta DRA na podstawie przypisania komputera do domeny. Certyfikat odzyskiwania danych (FR certificate) jest zapisany w profilu użytkownika agenta DRA.

• Domyślnym agentem DRA dla pojedynczego komputera z systemem w wersji Professional jest konto Admin.

• Domyślnym agentem DRA dla pojedynczego serwera jest konto Administrator.

• Domyślnym agentem DRA w domenie jest konto Administrator dla tej domeny.

Certyfikat Administratora domeny jest zapisany w profilu użytkownika Administrator w pierwszym kontrolerze domeny. Kopia certyfikatu agenta DRA jest przechowywana w Rejestrze każdego z komputerów członkowskich domeny w kluczu HKLM|Software|Policies|Microsoft|SystemCertificates|EFS|Certificates|<thumbprint>.

Uwagi ogólne dotyczące odzyskiwania danych

Można odzyskać pliki zaszyfrowane na pojedynczej stacji roboczej lub serwerze poprzez zalogowanie się na konto Admin (wersja Professional) lub Administrator (wersja Server) i otwarcie pliku lub zmianę atrybutu szyfrowania. Z tego względu szyfrowanie plików na komputerach nie połączonych w sieć nie jest zbyt bezpieczne. Można pobawić się z lokalną bazą kont SAM i uzyskać dostęp do konta Admin/Administrator.

W razie zastosowania szyfrowania w komputerach nie połączonych w sieć, takich jak laptopy czy komputery domowe użytkowników, bardzo ważne jest usunięcie z takiego komputera certyfikatu odzyskiwania danych (FR certificate), aby nie narażać plików zaszyfrowanych. Nie można tego podkreślić wystarczająco mocno. Po prostu, jeśli certyfikat odzyskiwania plików (FR certificate) jest w zasięgu ręki każdego użytkownika, to szyfrowanie plików nie ma sensu. Szczegóły podano w paragrafie Ochrona certyfikatów odzyskiwania plików (Securing File Recovery Certificates).

W domenie problem odzyskiwania plików staje się trochę bardziej skomplikowany. Pojawia się dylemat. Agentem DRA jest Administrator, ale nie można po prostu pójść do komputera użytkownika, zalogować się jako Administrator i oczekiwać na otwarcie pliku zaszyfrowanego, ponieważ nie ma lokalnej kopii certyfikatu odzyskiwania danych (FR certificate) ani klucza prywatnego agenta DRA. Do otwarcia pliku zaszyfrowanego konieczne są obydwa klucze.

Odzyskanie pliku zaszyfrowanego może być wykonane według jednej z dwóch strategii:

• Można wykorzystać Ntbackup do skopiowania plików zaszyfrowanych danego użytkownika do komputera, w którym znajduje się certyfikat odzyskiwania pliku (FR certificate) i klucz uniwersalny agenta DRA (DRA master key).

• Można wyeksportować certyfikat odzyskiwania pliku (FR certificate) i klucz uniwersalny agenta DRA (DRA master key) i umieścić kopię obydwu w komputerze użytkownika.

W normalnych warunkach certyfikat odzyskiwania pliku (FR certificate) dla konta Administrator jest usunięty z sieci całkowicie, więc trzeba podjąć obydwa działania: skopiować pliki zaszyfrowane do bezpiecznego serwera, a następnie zaimportować certyfikat odzyskiwania pliku (FR cerificate) dla Administratora oraz prywatny klucz agenta DRA.

Założenia systemowe dotyczące odzyskiwania danych

Założenia systemowe dotyczące grup muszą być w miejscu, które poda każdemu komputerowi tożsamość agenta DRA, wykorzystywaną do szyfrowania plików. Są to Założenia systemowe odzyskiwania plików (File Recovery Policy). Komputery lokalne wymagają lokalnych Założeń systemowych odzyskiwania plików (File Recovery Policy).

Jeśli założenia systemowe dotyczące grup lub lokalne założenia systemowe nie działają, lub agent DRA nie jest wpisany do założeń systemowych, to wtedy EFS odmówi zaszyfrowania plików.

Pojęcie „Założenia systemowe odzyskiwania plików” wymaga oswojenia się z nim, ponieważ założenia systemowe dotyczące grup są w systemie Windows 2000 nowe. Założenia systemowe dotyczące grup nie są niczym więcej jak plikiem, który jest rozsyłany do klientów domeny podczas logowania się. Założenia systemowe odzyskiwania plików jest to pozycja Rejestru zawierająca certyfikat klucza publicznego agenta DRA. Więcej informacji zawarto w paragrafie zatytułowanym „Zarządzanie założeniami systemowymi odzyskiwania plików”.

Pozostałe tematy w tym paragrafie zawierają opis konfiguracji założeń systemowych odzyskiwania plików i wykorzystania ich do odzyskiwania plików. Poniżej podano najważniejsze informacje dotyczące odzyskiwania plików zaszyfrowanych, służące jako przewodnik dla tych działań:

• Agentem DRA jest to konto, z którego można otworzyć plik zaszyfrowany, jeśli użytkownik, który zaszyfrował dany plik jest nieosiągalny.

• Agentowi DRA wydaje się certyfikat odzyskiwania plików (FR certificate), zawierający klucz publiczny. Agent DRA może otwierać pliki zaszyfrowane, ponieważ kopia klucza FEK zaszyfrowanego za pomocą klucza publicznego odzyskiwania plików (FR public key) jest przechowywana razem z plikiem.

• Domyślny agent DRA jest wybierany na podstawie przynależności komputera do domeny.

• Tożsamość agenta DRA jest określona przez założenia systemowe grup (domeny) lub lokalne założenia systemowe (komputery niezależne). W założeniach systemowych musi być podany przynajmniej jeden agent DRA.

• Każdy plik zaszyfrowany musi mieć przynajmniej jednego agenta DRA.

Zarządzanie założeniami systemowymi odzyskiwania

Założenia systemowe odzyskiwania mają związek z założeniami systemowymi grup, zawierającymi nazwę i klucz publiczny agenta (agentów) DRA. Na niezależnych serwerach lub stacjach roboczych założenia systemowe odzyskiwania są ustawiane w założeniach systemowych komputera lokalnego za pomocą konsoli Edytora założeń systemowych grup (Group Policy Editor), GPEDIT.MSC. W domenie założenia systemowe odzyskiwania są rozdzielane pomiędzy komputery członkowskie domeny poprzez założenia systemowe grup.

Założenia systemowe grup jest to zbiór uaktualnień Rejestru, skryptów logowania/wylogowania, instrukcji przeadresowywania folderów i programów instalacyjnych oprogramowania, które są automatycznie przesyłane do komputerów członkowskich domeny i użytkowników podczas logowania. Założenia systemowe grup dotyczące Agenta odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agent) są zapisane do pliku REGISTRY.POL w związanym folderze założeń systemowych.

Założenia systemowe dla niezależnych stacji roboczych i serwerów są przechowywane w folderze \WINNT\System32\GroupPolicy\Machine\Registry.pol. Założenia systemowe grup przeznaczone do przesłania do komputerów członkowskich domeny są zapisane w folderze \WINNT\Sysvol\Sysvol\<nazwa_domeny>\Policies\<identyfikator_GUID_założen_systemowych>\Machine (\WINNT\Sysvol\Sysvol\<domain_name>Policies\<policy_ID)\Machine. Drugi folder Sysvol w tej ścieżce dostępu jest udostępniony jako SYSVOL, więc komputery klienckie przechodzą bezpośrednio do udziału SYSVOL, aby załadować założenia systemowe. Przykład zawarto na rysunku 14.24

Rysunek 14.24. Okno Eksploratora przedstawiające ścieżkę dostępu do plików założeń systemowych.

Komputery członkowskie domeny w trakcie logowania ładują swoje pliki założeń systemowych, włącznie z plikami REGISTRY.POL, z kontrolera domeny, który je aktualizuje. Pliki założeń systemowych są powielane pomiędzy kontrolerami domeny poprzez Usługę replikacji plików (File Replication Service — FRS), więc nie ma znaczenia, który kontroler domeny dokonuje autoryzacji klienta.

Uaktualnienia Rejestru w pliku REGISTRY.POL zostają niezwłocznie zastosowane do Rejestru lokalnego. W przeciwieństwie do starych założeń systemowych grup (System Policies) Windows NT 4, założenia systemowe grup są stosowane w sposób nietrwały. Jeśli założenia systemowe zostaną usunięte, przejmowane są pierwotne ustawienia Rejestru. Certyfikaty związane z założeniami systemowymi kluczy publicznych są tylko przechowywane w Rejestrze. Nie mają one formy plików certyfikatów w profilu użytkownika. Klucz publiczny w certyfikacie przechowywanym w Rejestrze może być eksportowany do standardowego formatu certyfikatu takiego jak certyfikat X.509. Klucz prywatny nie może być uzyskany z pozycji Rejestru.

Na rysunku 14.25 pokazano położenie założeń systemowych Agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents) w strukturze założeń systemowych grup. Założenia systemowe znajdują się w folderze Computer Configuration|Windows Settings|Security Settings|Public Key Policies. Kiedy założenia systemowe Agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents) są zaznaczone, wykaz agentów odzyskiwania znajduje się w prawym panelu.

Założenia systemowe agenta odzyskiwania zawierają kopię certyfikatu odzyskiwania plików (File Recovery certificate) wystawionego dla danego agenta. Ten certyfikat zawiera klucz publiczny agenta, który EFS wykorzysta do zaszyfrowania klucza FEK dla pliku.

Rysunek 14.25. Konsola Założenia systemowe grup (Group Policy) przedstawiająca konto Administrator umieszczone w folderze Encrypted Data Recovery Agents. Są to założenia systemowe odzyskiwania.

Wskazówka dotycząca Rejestru: Certyfikaty Odzyskiwania Pliku

Certyfikat odzyskiwania pliku (File Recovery) w pliku REGISTRY.POL jest zaprojektowany żeby pasował do Rejestru jako duży obiekt binarny (Binary BLOB) w kluczu HKLM|Software|Policies|Microsoft|SystemCertificates|EFS|Certificates| <certificate_thumbprint).

Rozdzielanie założeń systemowych odzyskiwania danych

EFS zawiera kopię certyfikatu odzyskiwania plików (File Recovery certificate) w polu odzyskiwania danych (Data Recovery Field) każdego pliku zaszyfrowanego. Uzyskuje go z domeny jako część założeń systemowych grup pod nazwą założenia systemowe agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents policy).

Założenia systemowe mogą być związane z domeną, miejscem lub pojedynczą jednostką organizacyjną (Organizational Unit — OU). Położenie założeń systemowych grup, zawierających założenia systemowe agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents) określa zakres wpływów agenta DRA. Na przykład domyślne założenia systemowe domeny (Default Domain Policy) zawiera certyfikat odzyskiwania pliku (FR certificate) wydany dla konta Administrator domeny, domyślnego agenta DRA dla domeny. Taki zakres wpływów dla konta Administrator obejmuje każdy komputer członkowski w domenie bez względu na jego fizyczną lokalizację i przynależność do jednostki organizacyjnej (Organizational Unit — OU).

Administrator lokalny może utworzyć nowe założenia systemowe grup, połączyć te założenia z lokalną jednostką organizacyjną (OU) i przydzielić inne założenia systemowe odzyskiwania danych (Data Recovery policy). Administrator może wybrać agenta DRA z domeny lub zablokować założenia systemowe domeny i wykorzystać po prostu założenia systemowe jednostki organizacyjnej (OU).

Zarządzanie założeniami systemowymi odzyskiwania danych

Założenia systemowe grup są skonfigurowane przy użyciu przystawki (snap-in) w Założeniach systemowych grup (Group Policy), pojawiających się w kilku konsolach MMC. Podstawowym elementem biblioteki DLL dla tej wtyczki (snap-in) jest GPEDIT.DLL, więc często jest nazywany Edytorem założeń systemowych grup (Group Policy Editor). Edytor założeń systemowych grup (Group Policy Editor) posiada wiele rozszerzeń, które mogą być wykorzystane do przystosowania jego funkcji. Założenia systemowe odzyskiwania danych są zawarte w rozszerzeniach Bezpieczeństwo (Security). Rozszerzenia te są przedstawione w Edytorze założeń systemowych grup (Group Policy Editor) jako Ustawienia bezpieczeństwa (Security Settings).

Ustawienia bezpieczeństwa (Security Settings) dla niezależnych stacji roboczych i serwerów są konfigurowane przy użyciu konsoli Założenia systemowe bezpieczeństwa (Security Policy), Secpol.msc.

Ustawienia bezpieczeństwa (Security Settings) dla założeń systemowych grup na podstawie domeny są zarządzane poprzez konsolę zarządzania Active Directory, która zarządza związanymi z nią obiektami domeny. Na przykład założenia związane z kontenerem (container) Domena (Domain) i dowolnymi kontenerami (container) jednostek organizacyjnych (OU ) są zarządzane z konsoli AD Użytkownicy i komputery (AD Users and Computers). Założenia systemowe związane z Lokacjami (Sites) są zarządzane z konsoli AD Lokacje i usługi (AD Sites and Services).

Można również zbudować własną konsolę zawierającą rozszerzenia Ustawienia bezpieczeństwa (Security Settings) wtyczki (snap-in) Założenia systemowe grup (Group Policy). Szczegóły konfigurowania własnej konsoli Założenia systemowe grup (Group Policy) podano w rozdziale 16, „Zarządzanie środowiskiem użytkownika”.

Konfigurowanie założeń systemowych agenta odzyskiwania (Recovery Agent)

Po otwarciu konsoli Założenia systemowe (Group Policy) przejdź do gałęzi Computer Configuration|Windows Settings|Security Settings|Public Key Policies|Encrypted Data Recovery Agents. W prawej części okna pokazano certyfikat agenta DRA. Musi istnieć przynajmniej jeden agent DRA, bo w przeciwnym razie EFS w komputerach lokalnych odmówi zaszyfrowania plików.

Jeśli zostaną utworzone założenia systemowe, które mają w pozycji Agenty odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents) wpisane <null> (w odróżnieniu od założeń, które mają tę pozycję pustą), to użytkownicy komputerów, których takie założenie dotyczy, nie będą mogli szyfrować plików. Na przykład administrator chce, aby działy Engineering i Księgowość szyfrowały swoje dane, aby ochronić produkt oraz informacje biznesowe, ale nie chce, by reszta pracowników szyfrowała swoje bez potrzeby. W tym celu należy utworzyć założenie systemowe grup i przypisać agenta DRA do założeń odzyskiwania danych. Domyślne założenia miałyby wpisane <null> w odpowiedniej pozycji. Procedurę przypisywania założeń systemowych grup do grup opisano w rozdziale 16.

Problem ze stosowaniem założeń systemowych odzyskiwania opierając się na grupach jest taki, że ustawienia mają wpływ na Konfigurację komputera (Computer Configuration), a nie na Konfigurację użytkownika (User Configuration). Oznacza to, że administrator musi połączyć konta danego komputera z jednostką organizacyjną (OU) lub grupą, a następnie odpowiednio przypisać założenia. Może to być trudne do zarządzania, ponieważ wymaga skojarzenia użytkowników z ich komputerami. Ostatecznie może okazać się, że łatwiej jest ustawić zezwolenie na szyfrowanie i wyszkolić użytkowników, aby prawidłowo korzystali z szyfrowania.

Zabezpieczanie certyfikatów odzyskiwania plików

Utrata kontroli nad certyfikatem odzyskiwania pliku (File Recovery) dla agenta DRA mogłaby narazić na szwank całą strategię szyfrowania plików. Jedynym pewnym sposobem na zapewnienie bezpieczeństwa EFS jest usunięcie certyfikatu odzyskiwania plików (FR certificate) ze wszystkich komputerów. Oznacza to duży nakład pracy w przypadku niezależnych stacji roboczych i serwerów.

Najlepsza strategia wykorzystania EFS składa się z następujących kroków:

• Podłączenie wszystkich komputerów niezależnych do domeny. To zapewni, że będą korzystać z agenta DRA domeny.

• Zapisanie i usunięcie certyfikatu odzyskiwania plików (FR certificate) z początkowego kontrolera domeny. To zagwarantuje, że żadna nieuprawniona osoba nie otrzyma kopii certyfikatu odzyskiwania pliku i nie wykorzysta jej do uzyskania dostępu do plików zaszyfrowanych w domenie.

• Usuń założenia systemowe Agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents) i certyfikaty odzyskiwania plików (FR certificates) ze wszystkich komputerów niezależnych, aby zablokować szyfrowanie plików.

Przed usunięciem certyfikatu odzyskiwania plików (FR certificate) z komputera niezależnego lub domeny, należy upewnić się, czy istnieje bezpieczna kopia certyfikatu, która może być użyta w razie konieczności odzyskania plików zaszyfrowanych. Ogólne działania zabezpieczające certyfikat odzyskiwania plików (File Recovery certificate) są następujące:

• Eksportuj certyfikat odzyskiwania pliku (FR certificate) i klucz uniwersalny do certyfikatu, który może być zapisany na dyskietce lub nagrany na CD.

• Usuń certyfikat odzyskiwania pliku (FR certificate) z kontrolera domeny (lub komputera niezależnego). Nie spowoduje to zakłóceń zdolności użytkownika do szyfrowania plików.

• Importuj certyfikat odzyskiwania pliku (FR certificate) tylko wtedy, kiedy to jest konieczne do odzyskania pliku, a potem znów usuń.

Eksportowanie certyfikatów odzyskiwania pliku

Certyfikatu nie można eksportować poprzez sieć. W przypadku komputerów z systemem Windows 2000 Professional konieczne jest zalogowanie się, korzystając z domyślnego konta Admin. W przypadku niezależnego serwera należy zalogować się jako lokalny Administrator. W przypadku domeny Windows 2000 wymagane jest zalogowanie się na konsoli pierwszego kontrolera domeny z wykorzystaniem konta Administrator domeny.

Aby zapisać certyfikat po wyeksportowaniu, administrator powinien mieć parę czystych dyskietek lub nagrywarkę CD do dyspozycji. Oto kolejne kroki eksportowania certyfikatu:

Procedura 14.9. Eksportowanie certyfikatu odzyskiwania pliku (File Recovery Certificate)

1. Otwórz konsolę Certyfikaty (Certificates).

2. Przejdź do gałęzi Certyfikaty — Aktualny użytkownik|Osobiste|Certyfikaty (Certificates — Current User|Personal|Certificates). Jeśli nie ma takiej ikony, to znak, że zalogowałeś się w złym kontrolerze domeny.

3. Kliknij prawym klawiszem myszy na certyfikacie Odzyskiwanie pliku (File Recovery) i z menu wybierz pozycję Wszystkie zadania|Eksport (ALL TASKS|EXPORT). To uruchomi Kreatora eksportu certyfikatów (Certificate Export Wizard). W przypadku większej liczby certyfikatów na liście, wybierz właściwy za pomocą kolumny Przeznaczenie (Intended Purpose).

4. Naciśnij Dalej (Next). Otworzy się okno Eksportuj klucz prywatny (Export Private Key).

5. Wybierz opcję Tak, eksportuj klucz prywatny (Yes, export the private key). Certyfikat musi zawierać klucz prywatny, aby umożliwić odzyskanie pliku.

6. Naciśnij Dalej (Next). Otworzy się okno Eksportuj format pliku (Export File Format), rysunek 14.26. Plik eksportowany musi być zapisany w formacie PFX, ponieważ zawiera parę kluczy i wymaga dodatkowych zabezpieczeń.

Rysunek 14.26. Kreator eksportu certyfikatu (CertificateExport Wizard) — Eksportuj format pliku (Export File Format)

Pozostaw wybraną opcję Ustaw wysoki poziom zabezpieczeń (Enable strong protection). Wykorzystuje się w tym celu bardziej zaawansowany sposób szyfrowania, który nie jest dostępny w systemie Windows NT z numerem wersji Service Pack 'a niższym niż 4.

7. Naciśnij Dalej (Next). Otworzy się okno Hasło (Password). Wprowadź hasło i potwierdź je. Nie ma żadnych wymagań co do złożoności, ale długie hasła są lepsze niż krótkie, a im mniej znaków alfanumerycznych użyjesz, tym lepiej.

8. Naciśnij Dalej (Next). Otworzy się okno Plik do eksportu (File To Export). Wprowadź nazwę, którą chcesz nadać eksportowanemu certyfikatowi. Nazwa nie ma żadnego znaczenia dla szyfrowania. Powinna zawierać identyfikator logowania użytkownika (logon ID). Podaj wyjściowy folder lokalny.

9. Naciśnij Dalej (Next). Otworzy się okno podsumowania.

10. Naciśnij Zakończ (Finish). Kreator poinformuje o bezbłędnym zakończeniu operacji eksportowania.

11. Zamknij konsolę Certyfikaty (Certificates).

12. Skopiuj certyfikat na kilka dyskietek. Możesz również skopiować go na CD. Zamknij kopie w bezpiecznym miejscu. Jedną z kopii zachowaj pod ręką, aby wykonać operację importu, aby sprawdzić, czy wszystko działa poprawnie. W kolejnych krokach kopia certyfikatu, znajdująca się na dysku, zostanie skasowana, więc upewnij się, czy posiadasz dobrą kopię.

Postępowanie w przypadku utraty certyfikatu odzyskiwania pliku (FR certificate)

Osobiście robi mi się niedobrze, kiedy czytam w podręczniku użytkownika zdanie ostrzegające mnie, by „upewnić się czy mam dobrą kopię” czegoś tam. Zwykle pytam, co będzie jeśli nie mam. Co się wtedy stanie?

W tym przypadku, jeśli zgubisz certyfikat odzyskiwania pliku dla konta Administrator, nie będziesz w stanie odzyskać żadnego pliku zaszyfrowanego przez użytkowników.

Jeśli tak się stanie, najlepszym wyjściem jest zainstalowanie Jednostki certyfikującej (Certificate Authority) (zobacz „Instalowanie usług certyfikacji”) i utworzenie nowego certyfikatu dla konta Administrator postępując według opisu „Tworzenie dodatkowych agentów odzyskiwania danych”.

Następnie poinformuj użytkowników, którzy zaszyfrowali pliki, aby zaszyfrowali pliki powtórnie. To spowoduje pojawienie się nowego agenta DRA. Jeśli użytkownicy nie zastosują się do poleceń, a później nie będą mogli otworzyć z jakiegoś powodu plików zaszyfrowanych, nie będziesz mógł im pomóc.

Usuwanie certyfikatów odzyskiwania pliku

Kiedy dokonałeś eksportu certyfikatu odzyskiwania pliku (File Recovery certificate) do dającego się przenieść formatu i zamknąłeś bezpiecznie kopie, możesz usunąć certyfikat znajdujący się na dysku wykorzystując wyczkę Certyfikaty (Certificates).

Certyfikat jest przechowywany w profilu Administrator w folderze |Dokumenty i ustawienia|Administrator|Dane aplikacji|Microsoft|Certyfikaty Systemowe|Moje|Certyfikaty (|Documents and Settings|Administrator|Application Data|Microsoft|SystemCertificates|My|Certificates) pod nazwą, która odpowiada odciskowi palca (thumbprint) w certyfikacie. Nie wolno usuwać go bezpośrednio. Przystawka Certyfikat (Certificate) dokona również koniecznych uaktualnień Rejestru.

Usunięcie certyfikatu odzyskiwania pliku (FR certificate) nie przeszkodzi użytkownikom w szyfrowaniu i deszyfrowaniu plików. Klucz publiczny agenta DRA jest wciąż dostępny jako część założeń systemowych Agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents). Jedyną rzeczą, którą się traci jest zdolność do szybkiego odzyskania plików, ponieważ najpierw konieczne jest importowanie certyfikatu.

Kiedy jesteś gotowy do eksportowania certyfikatu odzyskiwania pliku (FR certificate), postępuj tak, jak opisano poniżej:

Procedura 14.10. Eksportowanie certyfikatu odzyskiwania pliku

1. Zaloguj się jako Administrator w kontrolerze domeny przechowującym certyfikat odzyskiwania plików (FR certificate). Jest to pierwszy kontroler domeny, któremu nadano tę funkcję w domenie.

2. Otwórz konsolę Certyfikaty (Certificates).

3. Przejdź do gałęzi drzewa Certyfikaty — aktualny użytkownik|Osobiste|Certyfikaty (Certificates — Current User|Personal|Certificates). Jeśli taka ikona nie istnieje, to oznacza, że zalogowałeś się do niewłaściwego kontrolera domeny lub wykorzystujesz niewłaściwe konto Administrator.

4. Znajdź certyfikat odzyskiwania plików (File Recovery certificate). Jeśli na liście znajduje się kilka certyfikatów, do znalezienia certyfikatu odzyskiwania pliku (File Recovery certificate) wykorzystaj kolumnę Przeznaczenie (Intended Purposes).

5. Kliknij prawym klawiszem myszy na nazwie certyfikatu i wybierz z menu opcję Usuń (DELETE). Wtyczka (snap-in) wysyła ostrzeżenie, że nie będziesz w stanie odszyfrować danych zaszyfrowanych z użyciem tego certyfikatu. Potwierdź ostrzeżenie naciskając przycisk Tak (Yes) i usuń certyfikat.

6. Możesz sprawdzić, że plik został skasowany przeglądając folder |Dokumenty i ustawienia | Administrator |Dane aplikacji| CertyfikatySystemowe| Moje|Certyfikaty (|Documents and Settings|Administrator|Application Data|Microsoft|SystemCertificates|My|Certificates).

7. Zamknij konsolę.

W razie konieczności odzyskania pliku zaszyfrowanego, najpierw musi być dokonany import certyfikatu odzyskiwania pliku (File Recovery certificate). Szczegóły znajdują się w paragrafie „Importowanie certyfikatów EFS” (Importing EFS Certificates). Kolejne kroki postępowania odnoszą się do importowania certyfikatu osobistego EFS, ale również obowiązują w przypadku importu certyfikatu odzyskiwania pliku (FR certificate) po zalogowaniu się jako Administrator/Admin.

Tworzenie dodatkowych agentów odzyskiwania danych

Jak można zauważyć, konto Administrator w domenie stanowi jedyny słaby punkt EFS. Występują rzadkie przypadki utraty dostępu do konta Administrator.

W normalnych warunkach utrata konta Administrator jest irytująca, ale nie krytyczna. Powinno istnieć kilka kont z pełnymi uprawnieniami administracyjnymi. Ale jeśli w domenie zastosowano EFS, utrata konta Administrator oznacza utratę zdolności do odzyskania plików zaszyfrowanych. Dodanie jeszcze jednego agenta DRA, powinno być wysoko na liście priorytetów administratora.

Wyznaczenie kolejnego agenta DRA pociąga za sobą wydanie certyfikatu odzyskiwania plików (FR certificate) dla jeszcze jednego konta. EFS nie wyda takiego certyfikatu. Konieczne jest posiadanie Jednostki certyfikującej (Certificate Authority — CA). Instalowanie jednostki certyfikującej (CA) opisano w paragrafie „Instalowanie usług certyfikowania”.

Po zainstalowaniu jednostki certyfikującej (CA) są dwa sposoby wydania certyfikatu odzyskiwania plików (FR certificate) dla określonego konta.

• Konsola Założenia systemowe grup (Group Policy) zawiera skrót, który uzyskuje certyfikat od jednostki certyfikującej (CA) i konfiguruje dane konto jako agent DRA.

• Te same kroki, wykorzystywane przez skrót, można wykonać ręcznie. Może to być konieczne, jeśli konto ma już certyfikat odzyskiwania plików (FR certificate) i chcemy dodać ten certyfikat do założeń systemowych odzyskiwania danych (data recovery policy).

Kroki opisane w tym paragrafie dotyczą skrótu. Ręczne sposoby wydawania certyfikatów i dodawania ich do założeń systemowych odzyskiwania danych (data recovery policy) omówiono w paragrafie „Zarządzanie certyfikatami odzyskiwania plików”.

Procedura 14.11. Dodawanie kolejnego, alternatywnego agenta DRA z wykorzystaniem skrótu założeń systemowych grup (Group Policy Shortcut)

1. Zaloguj się na konsoli serwera, w którym ma być utworzony certyfikat odzyskiwania plików (File Recovery certificate). Wykorzystaj konto, które wyznaczyłeś jako kolejnego agenta DRA. Konto musi mieć uprawnienia administratora.

2. Otwórz konsolę AD Użytkownicy i komputery (AD Users and Computers).

3. Otwórz okno Właściwości (Properties) dla obiektu Domena (Domain).

4. Wybierz zakładkę Założenia systemowe grup (Group Policy).

5. Kliknij dwukrotnie na ikonie Domyślne założenia systemowe domeny (Default Domain Policy) otwierając konsolę Założenia systemowe grup (Group Policy console). Jeśli z domeną związanych jest wiele założeń systemowych, upewnij się, czy domyślne założenia systemowe domeny (Default Domain Policy) mają najwyższy priorytet. Jeśli istnieją założenia systemowe o wyższym priorytecie, upewnij się, czy nie zawierają założeń systemowych sprzecznych z tymi, które po nich następują.

6. Na konsoli Założenia systemowe grup (Group Policy) przejdź do Konfiguracja komputera|Ustawienia Windows|Ustawienia bezpieczeństwa|Założenia systemowe klucza publicznego|Agenty odzyskiwania danych zaszyfrowanych (Computer Configuration|Windows Settings|Security settings|Public Key Policies|Encrypted Data Recovery Agents).

7. Kliknij prawym klawiszem myszy pozycję Agenty odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents) i z menu wybierz opcję Utwórz (Create). Uruchomi się Kreator żądania certyfikatu (Certificate Request Wizard). Jeśli pojawi się komunikat o błędzie „System Windows nie może znaleźć Jednostki certyfikującej, która obsłuży żądanie” (Windows cannot find a certification authority that will process the request), to albo nie zainstalowałeś serwera CA albo nie wykonałeś restartu komputera, więc widzi on nowe założenia grup, które wyznaczają serwer CA. Więcej informacji zawarto w paragrafie „Zarządzanie serwerem Jednostki certyfikującej (Certificate Authority Server)”.

8. Naciśnij Dalej (Next). Otworzy się okno Szablon certyfikatu (Certificate Template). Szablony są przechowywane na serwerze CA i w Directory.

9. Naciśnij Dalej (Next). Otworzy się okno Przyjazna nazwa i opis certyfikatu (Certificate Friendly Name and Description). Wprowadź żądane informacje. Nazwa powinna być krótka, tak jak File Recovery. Nazwa nie ma znaczenia dla szyfrowania plików.

10. Naciśnij Dalej (Next). Otworzy się okno zakończenia. Lista ustawień przedstawia dostawcę usług kryptograficznych (Crypto Services Provider — CSP), wykorzystywanego do tworzenia certyfikatu i szablonu, wykorzystywanego przez tego dostawcę. Szablony nie mogą być zmieniane.

11. Naciśnij Zakończ (Finish). Kreator wyświetli komunikat o poprawnym zakończeniu operacji.

12. Aby umieścić certyfikat w profilu lokalnym użytkownika, naciśnij Instaluj certyfikat (Install Certificate). W tle kreator bierze klucz publiczny, tworzy certyfikat i dodaje go do listy Agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents).

Teraz założenia systemowe odzyskiwania są na swoim miejscu. Aby założenia systemowe zaczęły działać, muszą być wpisane do lokalnego Rejestru i załadowane do komputera członkowskiego domeny. Można czekać do następnego logowania lub na okresową (co 90 minut) aktualizację założeń systemowych, bądź też ręcznie zastosować te założenia wykorzystując narzędzie Security Editor uruchamiane z wiersza poleceń, SECEDIT.EXE. Składnia polecenia jest następująca: secedit /refreshpolicy machine_policy.

Kiedy program Secedit jest uruchamiany na kontrolerze domeny, na którym dokonywano zmian, zmiany założeń zostaną wpisane do lokalnego Rejestru. Kiedy program Secedit jest uruchamiany na komputerze członkowskim, ładowane są najbardziej aktualne założenia systemowe i wpisuje aktualizację do lokalnego Rejestru.

Bezpośrednie sprawdzenie, że nowe założenia systemowe Agenta odzyskiwania (Recovery Agent) są aktywne, jest trudne. Pośrednią weryfikację na kontrolerze domeny, na którym certyfikat został utworzony, można wykonać w następujący sposób:

Procedura 14.12. Sprawdzenie kolejnego agenta DRA

1. Zaloguj się jako użytkownik, który jeszcze nie szyfrował plików na serwerze. Użytkownik musi mieć uprawnienia administratora do zalogowania się na konsoli kontrolera domeny.

2. Zaszyfruj plik. Możesz utworzyć plik tekstowy lub wykorzystać istniejący plik. Sprawdź, czy użytkownik może otworzyć plik przed i po zaszyfrowaniu. Nie próbuj szyfrować plików systemowych lub skompresowanych. System odmówi wykonania polecenia.

3. Wyloguj się, a następnie zaloguj, wykorzystując konto agenta DRA.

4. Otwórz plik zaszyfrowany. Agent DRA uzyskał dostęp do pliku. Zamknij plik, a następnie w oknie Właściwości (Properties) danego pliku wyłącz atrybut szyfrowania i dokonaj konwersji pliku z powrotem do postaci niezaszyfrowanej. Z punktu widzenia EFS stanowi to „odzyskiwanie” pliku.

Zapisywanie plików zaszyfrowanych na serwerach zaufanych

W domyślnej konfiguracji EFS serwer nie zezwala użytkownikom sieciowym na szyfrowanie plików. Jeśli użytkownik sieciowy próbuje zaszyfrować plik, system lokalny zwraca komunikat: Wystąpił błąd użycia atrybutu. Brak zestawu kluczy. (An error occured applying the attributes. Keyset does not exist).

Zanim serwer zezwoli użytkownikom sieciowym na szyfrowanie plików, musi być skonfigurowany jako Trusted for Delegation. Powodem tego jest środowisko bezpieczeństwa (security context) usługi EFS. Kolejne trzy paragrafy opisują działanie środowiska bezpieczeństwa (security context).

Lokalna sekwencja szyfrowania pliku

Poniżej opisano działanie normalnej sekwencji szyfrowania:

• EFS jest usługą pracującą w tle. Tak jak większość usług pracujących w tle, działa w środowisku bezpieczeństwa (security context) Local System. Konto Local System ma dobrze znany identyfikator bezpieczeństwa (SID) S - 1 - 5 - 18. Usługi pracujące w tle wykorzystują ten identyfikator bezpieczeństwa (SID) w swoich znacznikach dostępu (access tokens) do otwierania i modyfikowania swoich plików pomocniczych, kluczy Rejestru i atrybutów Directory.

• Kiedy użytkownik szyfruje (lub rozszyfrowuje) plik, usługa EFS uzyskuje klucz szyfru z certyfikatu EFS tego użytkownika. Dostęp do tego certyfikatu może mieć wyłącznie proces działający w środowisku bezpieczeństwa użytkownika, ponieważ jego część jest zakodowana za pomocą identyfikatora bezpieczeństwa SID użytkownika. Procesy pracujące w tle, takie jak usługa EFS, działając w imieniu użytkownika, mają zezwolenie na przedstawianie kopii żetonu dostępu (access token) użytkownika. W takiej sytuacji mówi się, że proces uosabia użytkownika.

• Usługa EFS nie może bezpośrednio otrzymać kluczy użytkownika. Konieczna jest pomoc LSA. LSA jest właścicielem dostawców usług kryptograficznych (CSPs), którzy wiedzą, jak zlokalizować i interpretować certyfikaty użytkownika i pliki kluczowe. Dostawcą usług kryptograficznych (CSP), zastosowanym w przypadku usługi EFS, jest Microsoft Base Cryptographic Provider v 1.0.

• Dostawca usług kryptograficznych (CSP) przekazuje informacje o kluczu do lokalnego autorytetu bezpieczeństwa (LSA), który przekazuje je do usługi EFS, która wykorzystuje te informacje do szyfrowania lub odszyfrowania klucza FEK. Usługa EFS, uzbrojona w klucz FEK, szyfruje lub odzszyfrowuje pliki stosując algorytm DESX.

Szyfrowanie plików poprzez sieć i delegowanie

Kiedy użytkownik sieciowy próbuje zaszyfrować plik na serwerze poprzez sieć, proces ten przebiega trochę inaczej.

• Usługa EFS, działając na serwerze, jest odpowiedzialna za szyfrowanie pliku. Szyfrowanie nie może być wykonane bezpośrednio przez sieć, ponieważ naraziłoby to plik na działanie podglądaczy sieciowych.

• Usługa EFS na serwerze może uzyskać kopię znacznika dostępu użytkownika, ale to nie wystarczy. Usługa ta musi również uzyskać dostęp do klucza uniwersalnego użytkownika, który jest zaszyfrowany za pomocą funkcji skrótu (user's password hash).

• Usługa EFS na serwerze nie zna funkcji skrótu (user's password hash). Musi uzyskać skrót (hash) od kontrolera domeny w imieniu użytkownika.

• Usługa EFS nie może po prostu zażądać skrótu (password hash). Konieczna jest karta uwierzytelniająca protokołu Kerberos (Kerberos ticket) klienta, która jest oznaczona jako „przekaż dalej” (forwardable), więc może przekazać kartę uwierzytelniającą (ticket) do kontrolera domeny, aby uzyskać skrót (password hash).

• Taki proces przekazywania karty uwierzytelniającej protokołu Kerberos (Kerberos ticket) w imieniu klienta jest nazywany delegowaniem (delegation). Klient Kerberos tylko znakuje kartę uwierzytelniającą (ticket) jako „przekaż dalej” (forwardable), jeśli serwer zatwierdzający (validating server) został wyznaczony jako Trusted for Delegation w Active Directory.

Względy bezpieczeństwa dla delegowania (Delegation)

Domyślnie opcja Trusted for Delegation jest wybrana tylko w kontrolerach domeny. Usługa KDC na kontrolerze domeny potrzebuje delegowania, więc może przekazać kartę uwierzytelniającą użytkownika (user ticket) do usługi KDC na kontrolerze domeny w domenie zaufanej.

Opcja Trusted for Delegation jest zablokowana dla komputerów nie będących kontrolerami domeny i dla komputerów niezależnych, ponieważ pozostawiają komputery otwarte na ataki koni trojanskich. W razie takiego ataku zły człowiek uzyskuje dostęp do serwera zaufanego i instaluje złośliwą usługę działającą w środowisku bezpieczeństwa użytkownika uprzywilejowanego. Ponieważ serwer ma wybraną opcję Trusted for Delegation, wywrotowa usługa może wykorzystać upoważnienia (credentials) klientów przychodzących, by powielać się na innych komputerach, dopóki nie narazi na szwank całej sieci. Następnie robi coś podłego.

To nie znaczy, że powinno się pomijać opcję Trusted for Delegation. W praktyce jest niemożliwa żadna rozsądna implementacja usługi EFS bez jednego lub dwóch serwerów delegowania (delegation servers). Bez nich użytkownicy byliby zmuszeni do zapisywania swioch plików zaszyfrowanych na dyskach lokalnych, skąd mogłyby zostać skasowane jednum poleceniem formatowania lub opuścić komputer. Serwery delegowania (delegation servers) muszą być chronione tak ściśle, jak ochraniane są kontrolery domeny.

Kiedy użytkownik zapisuje plik zaszyfrowany na serwerze delegowania (delegation server), LSA tworzy na tym serwerze lokalny profil użytkownika. Profil ten przechowuje certyfikat EFS użytkownika i klucz uniwersalny użytkownika. Profil użytkownika pochodzi z profilu Default User, tak jakby użytkownik zalogował się na konsoli serwera.

To może stanowić problem przechowywania dla serwera. Jeśli 1000 użytkowników zapisze pliki zaszyfrowane na serwerze, wtedy będzie to 1000 profili użytkownika w folderze \Documents and Settings. Profile te zajmują około 150 kB minimum, więc należy się upewnić, czy jest zapasowa pojemność folderu systemowego do obsługi dodatkowych wymagań przechowywania danych. Konieczne także będzie wykonywanie okresowego przeglądu w celu odzyskania plików i kasowania profili użytkowników, którzy już nie pracują w firmie.

Włączanie opcji Trusted for Delegation

Po rozstrzygnięciu, który serwer lub serwery powinny mieć ustawioną opcję Trusted for Delegation, należy skonfigurować opcję w Active Directory w sposób następujący:

Procedura 14.13. Włączanie opcji Trusted for Delegation dla serwera

1. Zaloguj się na konto z uprawnieniami administratora dla obiektu Komputer serwera zaufanego.

2. Otwórz konsolę AD Użytkownicy i komputery (AD Users and Computers).

3. Przejdź do kontenera, gdzie przechowywane jest konto komputera. Domyślnym kontenerem jest cn=Computers, dc=<domain>.

4. Otwórz okno Właściwości (Properties) dla komputera; rysunek 14.27.

Rysunek 14.27. Właściwości komputera przedstawiające wybraną opcję Zaufanie do delegowania (Trust computer for delegation).

5. Wybierz opcję Zaufanie do delegowania (Trust computer for delegation). System wyświetli ostrzeżenie, że jest to „działanie mające wpływ na bezpieczeństwo” i nie powinno być nadużywane. Przeczytaj wstęp do tego paragrafu, w którym opisano szczegółowo zgadnienia bezpieczeństwa związane z delegowaniem (delegation).

6. Naciśnij OK, aby potwierdzić i powrócić do okna Właściwości (Properties).

7. Naciśnij OK, aby zastosować wprowadzone zmiany.

8. Uruchom ponownie komputer zaufany, aby wczytać nową konfigurację. Może być także konieczne ponowne uruchomienie komputerów klienckich.

9. Przetestuj konfigurację logując się na komputerze klienckim, mapując dysk sieciowy do folderu współdzielonego na serwerze, a następnie szyfrując plik w tym folderze. Jeśli opcja szyfrowania nie wyświetli się, oznacza to, że jest to wolumin FAT lub FAT32. Jeśli utrzymuje się błąd Brak zestawu kluczy (Keyset does not exist), upewnij się, czy komputer kliencki i serwer były uruchomione ponownie po zmianie konfiguracji i mają łączność z kontrolerem domeny.

Zarządzanie serwerem Jednostka certyfikująca (Certificate Authority Server)

Jednostka certyfikująca jest to serwer, który ma autoryzację do wydawania certyfikatów usługi PKCS. Certyfikaty wydane przez jednostkę certyfikującą (CA) są oparte na jednym lub więcej certyfikatów upoważniających przechowywanych w jego magazynie certyfikatów (certificate store). Microsoft dostarcza certyfikatów upoważniających dla usługi EFS i odzyskiwania plików (File Recovery).

Jednostka certyfikująca (CA) może również wydać certyfikat upoważniający podporządkowaną jednostkę certyfikującą (subordinate CA) do wydawania certyfikatów. Ta podporządkowana jednostka certyfikująca (subordinate CA) może z kolei wydać certyfikaty upoważniające swoim podporządkowanym jednostkom certyfikującym (subordinate CA). Detektywi z wydziału zabójstw lubią mówić o „łańcuchu dowodów” łączącym niezbicie śmiertelną broń ze sceną zbrodni. Usługa PKCS buduje „łańcuch certyfikatów”, który prowadzi od wydającej jednostki certyfikującej (CA) do końcowej upoważniającej jednostki certyfikującej (CA).

Zastosowanie usługi EFS nie wymaga bezwzględnie usług jednostki certyfikującej (CA). Każdy z systemów Windows 2000 Server i Professional jest w stanie wydać certyfikaty podpisane przez siebie (self-signed) EFS dla użytkowników lokalnych i certyfikat odzyskiwania plików (File Recovery certificate) dla domyślnego agenta DRA. Ale bez centralnego serwera wydającego i śledzącego certyfikaty usługa EFS może być trudna do zarządzania. W dodatku bez serwera CA nie można wydać dodatkowych certyfikatów odzyskiwania plików (File Recovery certificates), aby uzupełnić domyślnego agenta DRA.

Windows 2000 Server ma opcję Usługi certyfikatów (Certificate Services), pozwalającą na skonfigurowanie serwera CA. Zainstalowanie jednostki certyfikującej (CA) zajmuje tylko kilka minut i natychmiast zaczyna wydawanie certyfikatów dla użytkowników EFS. Można również wykorzystać go do wydawania certyfikatów dla innych funkcji korzystających z usług PKCS w firmie. Infrastruktura usług PKCS wymaga lepszego dopracowania, niż szybkie uruchomienie serwera Jednostka certyfikująca (CA server), ale bieżący paragraf zawiera informacje wystarczające do rozpoczęcia szkicowania strategii efektywnego wykorzystania, przynajmniej tam, gdzie chodzi o usługę EFS.

Przegląd funkcji usług certyfikatów Windows 2000

Jednostka certyfikująca (CA) wydaje certyfikaty w swoim imieniu lub w imieniu zaufanego „rodzica”. Serwery CA w Windows 2000 są uporządkowane hierarchicznie od Głównej jednostki certyfikującej przedsiębiorstwa (Enterprise Root CA) do Podporządkowanych CA (Subordinate CA). Każda z tych jednostek certyfikujących (CA) może wydawać certyfikaty. Certyfikat wydany przez daną jednostkę certyfikującą (CA) zawiera łańcuch jednostek certyfikujących pomiędzy nią a główną jednostką certyfikującą (root CA). Układ przypomina hierarchię domen. Administrator może chcieć zainstalować Usługi certyfikacji (Certificate Services) jako rzecz tak naturalną, jak aktualizuje się i wykorzystuje kontrolery domeny Windows 2000, aby zagwarantować odporność na błędy dla usług certyfikatów.

Po zainstalowaniu w domenie serwera CA, automatycznie zaczyna on wydawać certyfikaty w odpowiedzi na zapotrzebowania klientów. Dzieje się tak, ponieważ serwer CA uaktualnia domyślne założenia systemowe grup (group policy) związane z kontenerem Domena, aby zawierały nowy serwer CA zgodnie z założeniami systemowymi (policy) o nazwie Zaufane główne jednostki certyfikujące (Trusted Root Certificate Authorities). Po załadowaniu tych założeń systemowych przez komputery członkowskie, zaczną one przekazywać zapotrzebowanie na certyfikaty użytkowników do serwera CA, a nie wydawać własne certyfikaty (self-certification).

Użytkownicy nie są świadomi tych działań. Usługa EFS i LSA pracują w tle. Każdy z plików zaszyfrowany przed rozesłaniem nowych założeń systemowych grup (group policy) pozostaje widzialny. Pierwotny certyfikat użytkownika jest przechowywany w folderze profilu użytkownika razem z nowym certyfikatem jednostki certyfikującej (CA).

Najważniejsze informacje dotyczące wykorzystania Jednostek certyfikujących (Certificate Authority)

Poniżej przedstawiono najważniejsze informacje dotyczące wykorzystania jednostek certyfikujących (CA) do wydawania certyfikatów dla usługi EFS i certyfikatów odzyskiwania plików (FR):

• Jednostka certyfikująca (CA) wydaje certyfikaty w tle, w sposób niezauważalny dla użytkownika. Za zgłaszanie zapotrzebowania na certyfikat do jednostki certyfikującej (CA) jest odpowiedzialny lokalny dostawca usług kryptograficznych.

• Lokalny dostawca usług kryptograficznych ma informacje o jednostce certyfikującej (CA) z założeń systemowych zapisanych po zainstalowaniu serwera CA.

• Certyfikaty wydane przez jednostkę certyfikującą (CA) są przechowywane w tym samym miejscu, co certyfikaty wydane przez lokalnego dostawcę usług kryptograficznych. Jeśli użytkownik posiada już certyfikaty, działają one z istniejącymi dokumentami. Użytkownik może chcieć uruchomić program cipher do odświeżenia zaszyfrowanych dokumentów z wykorzystaniem nowego certyfikatu.

• Kopia certyfikatu jest przechowywana w obiekcie Active Directory użytkownika w atrybucie o nazwie User — Certificate. Jednostka certyfikująca (CA) wydaje oddzielny certyfikat za każdym razem, kiedy użytkownik szyfruje plik na innym komputerze. Może to spowodować, że atrybut User — Certificate rozrośnie się nadmiernie.

• Wszystkie certyfikaty, oparte na usłudze Directory, związane z użytkownikiem są ładowane i zapisywane w pamięci podręcznej lokalnie, kiedy użytkownik loguje się.

Wybór serwerów CA

Każdy serwer członkowski Windows 2000 w lesie (forest) może zostać główną jednostką certyfikującą przedsiębiorstwa (Enterprise Root CA). Przy wyborze serwera głównego (root server) lub dowolnego serwera jednostki certyfikującej (CA), niech przewodnikiem będą niezawodność i lokalne bezpieczeństwo. Ten serwer będzie przechowywał certyfikaty dla setek, tysięcy lub dziesiątków tysięcy użytkowników i usług. Jeśli ulegnie awarii i zabierze te informacje ze sobą, a nie będzie serwera zapasowego (backup server) ani plików zapasowych, to niemożliwe będzie odzyskiwanie plików. Konieczne jest upewnienie się, czy zainstalowano zapasową jednostkę certyfikującą (CA), która jest tak samo niezawodna, jak serwer Root.

Wydajność nie powinna mieć specjalnego znaczenia. Jeśli pamięć i moc obliczeniowa procesora są wystarczające dla Windows 2000, to można uruchomić jednostkę certyfikującą (CA). Serwer musi jednak uruchomić IIS, więc można powiększyć pamięć, jeśli w przyszłości ten komputer miałby być również serwerem dodatkowych usług sieciowych.

Innym ważnym czynnikiem wyboru serwera CA jest elastyczność. Certyfikat, który upoważnia serwer CA do wydawania certyfikatów jest bezpośrednio związany z nazwą serwera i przynależnością do domeny. Jeśli nazwa serwera ulega zmianie lub serwer zostanie odłączony od domeny, to wtedy nie może wydawać ani potwierdzać certyfikatów z wykorzystaniem pierwotnego certyfikatu upoważniającego. Jeśli serwer jest kontrolerem domeny, może być zdegradowany, o ile utrzymuje łączność z innym kontrolerem domeny.

Instalowanie usług certyfikacji

Aby zainstalować Usługi Certyfikacji i skonfigurować je jako główną jednostkę certyfikującą przedsiębiorstwa (Enterprise Root CA) lub podporządkowaną jednostkę certyfikującą przedsiębiorstwa (Enterprise Subordinate CA), należy zalogować się jako administrator w domenie głównej (root domain) lasu (forest). Główna jednostka certyfikująca (Root CA) i podporządkowana jednostka certyfikująca (Subordinate CA) mogą być zainstalowane w domenach zaufanych po zalogowaniu się na konto z potwierdzeniem uprawnień administratora (administrator credentials) z domeny głównej (root domain).

Jeśli istnieje mechanizm efektywnego wykorzystania certyfikatu (certificate deployment mechanism) i certyfikaty wydawane przez ten serwer mają być zgodne z istniejącą metodą efektywnego wykorzystywania (deployment method), to kreator instalacji ma opcję Zaawansowane (Advanced) w oknie Wybór pary kluczy publiczny/prywatny (Public and Private Key Pair Selection), która pozwala na wybór poszczególnych dostawców usług kryptograficznych (CSPs) i algorytmu funkcji skrótu (hash algorithm). Jeśli wykorzystywane są tylko Usługi Certyfikacji Windows 2000 (Windows 2000 Certificate Services) dla usług jednostki certyfikującej (CA), ta opcja nie jest konieczna.

Procedura 14.14. Instalacja Usług certyfikacji

1. Otwórz applet Dodaj/Usuń programy (Add/Remove Programs) w Panelu Sterowania.

2. Kliknij Dodaj/Usuń składniki systemu Windows (Add/Remove Windows Components). Uruchomiony zostanie Kreator składników systemu Windows (Windows Component Wizard).

3. Z listy Składniki (Components) wybierz Usługi certyfikacji (Certificate Services). Załadowane zostaną dwie usługi, Usługi certyfikacji CA (Certificate Services CA) oraz Certificate Services Web Enrollment Support. Dla usługi EFS nie są konieczne usługi sieciowe (Web services), ale wymaga ich jednostka certyfikująca (CA), więc jeśli usługa IIS nie jest uruchomiona, należy ją również zainstalować.

4. Naciśnij Dalej (Next). Otworzy się okno Wybór typu Jednostki certyfikującej (Certificate Authority Type Selection), rysunek 14.28. Jeśli opcje Główna jednostka certyfikująca przedsiębiorstwa (Enterprise Root CA) i Podporządkowana jednostka certyfikująca przedsiębiorstwa (Enterprise Subordinate CA) są wyświetlone na szaro, oznacza to, że nie zalogowałeś się na konto z uprawnieniami administratora w domenie głównej lasu domen (forest).

Rysunek 14.28. Kreator składników systemu Windows (Windows Component Wizard) — okno Wybór typu jednostki certyfikującej (Certificate Authority Type Selection) przedstawiające wybraną opcję Główna jednostka certyfikująca przedsiębiorstwa (Enterprise root CA) na kontrolerze domeny.

5. Wybierz opcję Główna jednostka certyfikująca przedsiębiorstwa (Enterprise root CA) i naciśnij Dalej (Next). Otworzy się okno Informacje identyfikujące jednostkę certyfikującą (CA Identifying Information), rysunek 14.29. Wprowadź informacje, o które prosi system, pamiętając, że administratorzy w innych domenach wykorzystają te dane do konfigurowania podporządkowanych serwerów CA.

Rysunek 14.29. Okno Informacje identyfikujące jednostkę certyfikującą (CA Identifying Information).

6. Naciśnij Dalej (Next). Otworzy się okno Lokalizacja przechowywania danych (Data Storage Location). Podaj lokalizację bazy danych Certyfikacja (certification).

Przechowywanie bazy danych jednostki certyfikującej (CA)

Domyślną lokalizacją bazy danych jednostki certyfikującej (CA) jest partycja systemowa i folder \WINNT\System32\Certlog. Przechowywanie bazy danych na partycji systemowej nie jest polecane, ponieważ w razie konieczności ponownej instalacji systemu Windows 2000, można utracić bazę danych.

Jeśli instalujesz Usługi certyfikacji (Certificate Services) na kontrolerze domeny, możesz umieścić pliki Certlog w tym samym woluminie, co pliki Active Directory czy Sysvol.

Pliki ASP dla części sieciowej Usług certyfikacji (Certification Services) są przechowywane w folderze \WINNT\System32\CertSrv. Nie ma możliwości wyboru innej lokalizacji.

Jeśli jest jeden serwer CA wykorzystywany przez wszystkie jednostki certyfikujące, wybierz opcję Zapisz informacje o konfiguracji w folderze udostępnionym (Store Configuration Information in a Shared Folder) i wprowadź ścieżkę UNC do tego udostępnionego folderu.

7. Naciśnij Dalej (Next). Jeśli ścieżka, którą wprowadziłeś, nie istnieje, zostaniesz poproszony o utworzenie jej. Aby potwierdzić dane naciśnij OK.

8. Jeśli usługa WWW pracuje na tym komputerze, zostaniesz poinformowany, że zostanie zatrzymana. Aby potwierdzić dane, naciśnij OK.

9. Kreator zainstaluje sterowniki usługi, uruchomi ponownie usługę WWW i zakończy, wyświetlając okno zakończenia. Naciśnij Zakończ (Finish). Nie ma potrzeby ponownego uruchomienia komputera.

Kreator skonfiguruje również nowe założenia systemowe grup (group policy) w Domyślnych założeniach systemowych domeny (Default Domain Policy). Założenia systemowe są kopią certyfikatu Główna jednostka certyfikująca (Master Certificate Authority) znajdującego się w folderze Konfiguracja komputera|Ustawienia Windows|Ustawienia bezpieczeństwa|Założenia systemowe klucza publicznego|Zaufane główne jednostki certyfikujące (Computer Cofiguration|Windows Settings|Security Settings|Public Key Policies Trusted Root Certification Authorities). Kiedy komputery członkowskie załadują te założenia systemowe, zaczynają przekazywać żądania certyfikatów użytkownika do serwera CA, zamiast wydawać autocertyfikaty (self-certifications). Użytkownicy nie są świadomi tego, co się dzieje. Każdy z plików zaszyfrowanych przed rozpowszechnieniem nowych założeń systemowych grup pozostaje widzialny. Pierwotny certyfikat użytkownika jest przechowywany w folderze profilu użytkownika razem z nowym certyfikatem jednostki certyfikującej (CA).

Podgląd kart uwierzytelniających (tickets) wydanych przez Jednostkę certyfikującą (Certificate Authority)

Po uruchomieniu serwera CA, komputery członkowskie, do których załadowano założenia systemowe grup jednostki certyfikującej (CA) uzyskają nowe certyfikaty EFS z serwera CA. Te karty uwierzytelniające można obejrzeć w następujący sposób:

Procedura 14.15. Oglądanie kart uwierzytelniających (tickets) wydanych przez Jednostkę certyfikującą (Certificate Authority)

1. Otwórz konsolę Jednostka certyfikująca (Certification Authority) wykorzystując menu START|PROGRAMY|NARZĘDZIA ADMINISTRACYJNE|JEDNOSTKA CERTYFIKUJĄCA (START|PROGRAMS|ADMINISTRATIVE TOOLS|CERTIFICATE AUTHORITY). Okno konsoli powinno wyglądać jak przykład na rysunku 14.30.

Rysunek 14.30. Konsola Jednostka certyfikująca (Certification Authority) przedstawiająca Ustawienia założeń systemowych (Policy Settings).

2. Przejdź do gałęzi drzewa <CA Name>|Wydane certyfikaty (<CA Name>|Issued Certificates). Nowo wydany certyfikat jest wyświetlany w lewej części okna.

3. Kliknij dwukrotnie na ikonie certyfikatu, aby otworzyć okno Certyfikat (Certificate).

4. Wybierz zakładkę Szczegóły (Details). Certyfikat wydany przez serwer CA zawiera więcej informacji niż zwykły podpisany przez siebie (self-assigned) certyfikat EFS wydany lokalnie. Przewiń listę do końca, aby zobaczyć informację w dolnej części okna. Rysunek 14.31 przedstawia informacje zawarte w polu certyfikatu o nazwie Authority Information Access (AIA). Jest to informacja, którą klient wykorzystuje do znalezienia jednostki certyfikującej (CA), kiedy potrzebne jest potwierdzenie ważności certyfikatu.

Rysunek 14.31. Okno Certyfikat (Cerificate) przedstawiające zakładkę Szczegóły i pole Authority Information Access (AIA).

Przycisk Kopiuj plik (Copy File) uruchamia Kreatora eksportu certyfikatu (Certificate Export Wizard). Wykorzystaj kreatora do wyeksportowania certyfikatu do pliku, który może zostać wysłany do klienta pocztą elektroniczną lub na dyskietce. Ten sposób eksportowania tworzy tylko certyfikat klucza publicznego. Nie może być wykorzystany do tworzenia certyfikatu zawierającego obydwa klucze, prywatny i publiczny. Może to zrobić tylko właściciel certyfikatu.

5. Naciśnij OK, aby zapisać zmiany i zamknąć konsolę.

Weryfikowanie działań Jednostki certyfikującej

Prawidłowo funkcjonujący serwer CA znika w tle, jak każde dobre urządzenie infrastruktury sieciowej. Użytkownicy domeny uzyskują certyfikat EFS z serwera CA automatycznie, kiedy szyfrują pliki. Nie jest konieczna żadna specjalna konfiguracja. Powinieneś zweryfikować odpowiednie działania serwera CA zaraz na początku, aby upewnić się, czy wydaje certyfikaty prawidłowo. Można tego dokonać w następujący sposób:

Procedura 14.16. Weryfikacja działania jednostki certyfikującej (CA)

1. Otwórz konsolę AD Lokacje i usługi (AD Sites and Services), wykorzystując menu START|PROGRAMY|NARZĘDZIA ADMINISTRACYJNE|AD MIEJSCA I USłUGI (PROGRAMS|ADMINISTRATIVE TOOLS|AD SITES AND SERVICES). Możesz otworzyć konsolę na serwerze CA, nawet, jeśli nie jest to kontroler domeny. Aby uzyskać niezbędne informacje konsola łączy się z kontrolerem domeny poprzez LDAP.

2. Z menu wybierz Podgląd|Pokaż węzły usług (View|Show Services node).

3. Przejdź do gałęzi drzewa Usługi klucza publicznego|Jednostki certyfikujące (Public Key Services|Certification Authorities). Certyfikat dla nowej jednostki certyfikującej jest wyświetlony w prawej części okna (rysunek 14.32).

Rysunek 14.32. Konsola AD Lokacje i usługi (AD Sites and Services) przedstawiająca zawartość kontenera Szablony Certyfikatów (Certificates Templates).

4. Zamknij konsolę AD Lokacje i usługi (AD Sites and Services).

5. Otwórz konsolę AD Użytkownicy i komputery (AD Users and Computers) wybierając z menu START|PROGRAMY|NARZĘDZIA ADMINISTRACYJNE|AD USERS AND COMPUTERS (START|PROGRAMS|ADMINISTRATIVE TOOLS|AD USERS AND COMPUTERS).

6. Otwórz okno Właściwości (Properties) obiektu Domena (Domain).

7. Wybierz zakładkę Założenia systemowe grup (Group Policy).

8. Kliknij dwukrotnie na pozycji Domyślne założenia systemowe domeny (Default Domain Policy), żeby otworzyć konsolę Założenia systemowe grup (Group Policy). Jeśli istnieje wiele założeń systemowych związanych z daną domeną, upewnij się, czy Domyślne założenia systemowe domeny (Default Domain Policy) są na pierwszym miejscu. Jeśli istnieją założenia systemowe o wyższym priorytecie, sprawdź, czy nie mają sprzecznych założeń systemowych.

9. Wykorzystując konsolę Założenia systemowe grup (Group Policy) przejdź do folderu Konfiguracja komputera|Ustawienia Windows|Ustawienia bezpieczeństwa|Założenia systemowe klucza publicznego|Zaufane główne Jednostki certyfikujące (Computer Configuration|Windows Settings|Security Settings|Public Key Policies|Trusted Root Certification Authorities). Certyfikat dla nowej Głównej jednostki certyfikującej przedsiębiorstwa (Enterprise Root CA) przedstawiono w prawej części okna. Przykład pokazano na rys. 14.33.

Rysunek 14.33. Konsola Założenia systemowe grup (Group Policy) przedstawiająca nową Główną jednostkę certyfikującą przedsiębiorstwa (Enterprise Root CA) w folderze Zaufane główne jednostki certyfikujące (Trusted Root Certification Authorities).

10. Zamknij konsolę Założenia systemowe grup (Group Policy).

11. Otwórz konsolę Jednostka certyfikująca (Certification Authority) wybierając START|PROGRAMY|NARZĘDZIA ADMINISTRACYJNE|JEDNOSTKA CERTYFIKUJĄCA (START|PROGRAMS|ADMINISTRATIVE TOOLS|CERTIFICATION AUTHORITY).

12. Rozwiń drzewo i zaznacz pozycję Wydane certyfikaty (Issued Certificates). W prawej części okna znajduje się lista wszystkich wydanych certyfikatów.

13. Przejdź do komputera członkowskiego w domenie i uruchom go ponownie, aby załadować nowe założenia systemowe grup.

14. Zaloguj się wykorzystując konto użytkownika domeny.

15. Zaszyfruj plik.

16. Na konsoli Jednostka certyfikująca (Certification Authority) sprawdź, czy wydano nowy certyfikat użytkowika.

17. Kliknij dwukrotnie na pozycji certyfikatu, aby otworzyć okno Certyfikat (Certificate) i potwierdź, że celem jest Pozwala na szyfrowanie danych na dysku (Allows data on disk to be encrypted).

18. Na komputerze klienckim otwórz profil użytkownika i przejdź do folderu |Dokumenty i ustawienia |<logonID>|Dane aplikacji|Microsoft|CertyfikatySystemowe|Moje|Certyfikaty (|Documents and Settings|<logonID>|Application Data|Microsoft|SystemCertificates|My|Certificates). Certyfikat wydany przez jednostkę certyfikującą (CA) jest w tym folderze. Potwierdź to sprawdzając na serwerze CA nazwę pliku i odcisk palca na certyfikacie.

19. Zamknij wszystkie okna i konsole.

Zarządzanie certyfikatami odzyskiwania plików

Serwer jednostki certyfikującej (CA) może wydać certyfikaty odzyskiwania plików (File Recovery) dla kolejnych agentów DRA. Wyznaczenie kolejnego agenta DRA i zamieszczenie certyfikatu w założeniach systemowych Agenta odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agent policy) najłatwiej wykonać używając skrótu w Edytorze założeń systemowych (Group Policy Editor). Ten sposób jest opisany w paragrafie „Tworzenie dodatkowych danych agentów odzyskiwania” (Creating Additional Data Recovery Agents).

Certyfikat odzyskiwania plików (FR certificate) można dla danego konta wydać ręcznie, a następnie zainstalować certyfikat w założeniach systemowych Agenta odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agent) jako oddzielny krok. Skrót jest czystszym sposobem wykonania całego procesu, ale zawsze dobrze jest mieć kopię zapasową.

Ogólne działania ręcznego przypisywania agenta DRA są następujące:

• Uzyskaj certyfikat odzyskiwania plików (FR cetificate) dla konta.

• Eksportuj certyfikat do formatu X.509.

• Dodaj certyfikat do założeń systemowych Agenta odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agent).

Szczegółowy opis tych działań znajduje się w następnych paragrafach.

Uzyskiwanie certyfikatu odzyskiwania plików (File Recovery) z serwera jednostki certyfikującej (CA server)

Poniższe kroki opisują, jak uzyskać certyfikat odzyskiwania plików (File Recovery certificate) dla kolejnego agenta DRA. Konto wyznaczone na kolejnego agenta DRA musi mieć uprawnienia administratora w domenie.

Procedura 14.17. Uzyskiwanie certyfikatu odzyskiwania plików

1. Zaloguj się na konsoli serwera, na którym ma być utworzony certyfikat odzyskiwania plików (File Recovery certificate). Wykorzystaj konto użytkownika wyznaczonego na agenta DRA.

2. Otwórz konsolę Certyfikaty (Certificates).

3. Kliknij prawym klawiszem myszy na ikonie Certyfikaty (Certificates) w folderze Osobiste (Personal) i z menu wybierz pozycję WSZYSTKIE ZADANIA|ŻĄDANIE NOWEGO CERTYFIKATU (ALL TASKS|REQUEST NEW CERTIFICATE). Uruchomi się kreator żądań certyfikatu (Certificate Request Wizard). Jeśli zostanie wyświetlony komunikat o błędzie: System Windows nie może znaleźć żadnej jednostki certyfikującej, która obsłuży żądanie (Windows can not find a certification authority that will process the request), to albo nie zainstalowałeś serwera CA, albo nie uruchomiłeś ponownie komputera, aby załadować założenia systemowe grup, zawierające nazwę nowego serwera CA.

4. Naciśnij Dalej (Next). Otworzy się okno Szablon certyfikatu (Certificate Template). Wybierz szablon Odzyskiwanie plików (File Recovery). Szablon zostanie przesłany z serwera CA.

5. Naciśnij Dalej (Next). Otworzy się okno Przyjazna nazwa i opis certyfikatu (Certificate Friendly Name and Description). Nazwa powinna być krótka i opisowa, na przykład Odzyskiwanie plików (File Recovery).

6. Naciśnij Dalej (Next). Otworzy się okno zakończenia. Lista ustawień przedstawia Dostawcę usług kryptograficznych (Crypto Services Provider — CSP), szablon użyty do utworzenia certyfikatu i nazwę użytkownika.

7. Naciśnij Zakończ (Finish). Kreator wyświetli komunikat o poprawnym zakończeniu i opcje przeglądania lub instalowania certyfikatu.

8. Naciśnij opcję Instaluj certyfikat (Install Certificate), aby go umieścić w lokalnym profilu użytkownika.

9. Kreator wyświetli jeszcze jeden komunikat o poprawnym zakończeniu. Aby potwierdzić i powrócić do konsoli Certyfikat (Certificate), naciśnij OK.

10. Na liście w prawej części konsoli znajduje się nowy certyfikat odzyskiwania plików (File Recovery certificate) razem z certyfikatem EFS, który jest również generowany. Jeśli certyfikat EFS już istnieje, na liście mogą pozostać obydwa. Skasowanie starszego zapobiegłoby oglądaniu przez administratora lub innego użytkownika z odpowiednimi uprawnieniami plików poprzednio zaszyfrowanych.

11. Pozostaw konsolę otwartą i przejdź do następnego paragrafu.

Eksportowanie certyfikatów X.509 CER

Certyfikat odzyskiwania plików (File Recovery certificate) wydany przez jednostkę certyfikującą (CA) nie jest odpowiednio sformatowany, aby mógł być importowany do listy założeń systemowych Agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents). Certyfikat musi być zapisany w formacie X.509 (CER). Eksportu certyfikatu, który został właśnie utworzony, do formatu X.509 można dokonać w następujący sposób:

Procedura 14.18. Eksportowanie certyfikatu X.509

1. Na konsoli Certyfikaty (Certificates) kliknij prawym klawiszem myszy na ikonie certyfikatu odzyskiwania plików, który właśnie utworzyłeś, i z menu wybierz opcję WSZYSTKIE ZADANIA|EXPORT (ALL TASKS|EXPORT). Uruchomi się kreator eksportu certyfikatów (Certificate export wizard).

2. Naciśnij Dalej (Next). Otworzy się okno Eksportuj klucz prywatny (Export private key). Wybierz opcję Nie eksportuj klucza prywatnego (No, do not export the private key).

3. Naciśnij Dalej (Next). Otworzy się okno Format pliku eksportowanego (Export File Format), rysunek 14.34. Wybierz jeden z formatów X.509 (CER). Wybór kodowania DER lub Base-64 w tym przypadku nie ma znaczenia. Niektóre aplikacje przyjmują tylko kodowanie Base-64, ale ten certyfikat jest związany z identyfikatorem obiektu (OID) Odzyskiwanie plików (File Recovery) i nie byłby użyteczny dla żadnej innej aplikacji. Zastosuj którąkolwiek metodę kodowania zgodną z zasadami kryptografii, przyjętymi w twojej organizacji.

Rysunek 14.34. Kreator eksportu certyfikatów — Format pliku eksportowanego.

4. Naciśnij Dalej (Next). Otworzy się okno Plik do eksportu (File To Export). Wprowadź nazwę, jaką chcesz nadać eksportowanemu certyfikatowi. Nazwa nie ma znaczenia dla szyfrowania. Powinna zawierać identyfikator logowania użytkownika (logon ID), pomocny w identyfikowaniu pliku. Zapisz plik w odpowiedniej lokalizacji.

5. Naciśnij Dalej (Next). Otworzy się okno zakończenia.

6. Naciśnij Zakończ (Finish). Kreator wyświetli komunikat o poprawnym zakończeniu exportu.

7. Zamknij konsolę Certyfikaty (Certificates) i przejdź do następnego paragrafu, w którym opisano import certyfikatu CER do listy Agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents).

Dodawanie agentów DRA do założeń systemowych odzyskiwania danych zaszyfrowanych

Poniżej opisano, w jaki sposób importować certyfikat odzyskiwania plików X.509 do założeń systemowych odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery), które są załadowywane przez klientów domeny. Poniższy opis dotyczy wyznaczania dodatkowego agenta DRA lub kolejnego agenta DRA. Certyfikat odzyskiwania plików musi być zapisany w formacie X.509 (CER). Format ten zawiera tylko klucz publiczny dla certyfikatu odzyskiwania plików (File Recovery certificate). To jest wszystko, czego wymagają założenia systemowe. W razie konieczności odzyskania plików, a nie zmian założeń systemowych odzyskiwania, zajrzyj do paragrafu „Importowanie certyfikatów EFS”. Jeśli jesteś przygotowany do importowania certyfikatu X.509 do założeń systemowych odzyskiwania danych, postępuj w sposób opisany poniżej:

Procedura 14.19. Ręczne dodawanie agentów DRA do założeń systemowych Agentów odzyskiwania danych zaszyfrowanych (Encrypted Data Reovery Agents)

1. Otwórz konsolę AD Użytkownicy i komputery (AD Users and Computers).

2. Otwórz okno Właściwości (Properties) dla obiektu Domena (Domain).

3. Wybierz zakładkę Założenia systemowe grup (Group Policy).

4. Kliknij dwukrotnie na pozycji Domyślne założenia systemowe domeny (Default Domain Policy), aby otworzyć konsolę Założenia systemowe grup (Group Policy). Jeśli istnieje więcej założeń systemowych związanych z domeną, upewnij się, czy Domyślne założenia systemowe domeny (Default Domain Policy) są na szczycie. Jeśli są założenia systemowe o wyższym priorytecie, upewnij się, czy nie mają sprzecznych założeń systemowych.

5. W konsoli Założenia systemowe grup (GroupPolicy) przejdź do pozycji Konfiguracja komputera|Ustawienia systemu Windows|Ustawienia bezpieczeństwa|Założenia systemowe klucza publicznego|Agenty odzyskiwania danych zaszyfrowanych (Computer configuration|Windows Settings|Security Settings|Public Key Policies|Encrypted Data Recovery Agents).

6. Kliknij prawym klawiszem myszy na pozycji Agenty odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents) i z menu wybierz opcję Dodaj (ADD). Otworzy się okno Dodaj agenta odzyskiwania (Add Recovery Agent). (Opcja Utwórz (Create) jest skrótem (shortcut) wspomnianym we wprowadzeniu do niniejszego paragrafu).

7. Naciśnij Dalej (Next). Otworzy się okno Wybierz agenta odzyskiwania (Select Recovery Agents). Wykorzystaj to okno do zlokalizowania wyeksportowanego certyfikatu odzyskiwania plików (File Recovery) X.509.

8. Naciśnij Przeglądaj foldery (Browse folders). Otworzy się okno Otwórz (Open).

9. Przejdź do folderu, gdzie został zapisany plik eksportowany.

10. Zaznacz certyfikat i naciśnij Otwórz (Open). Użytkownik zostanie dodany do listy Agentów odzyskiwania (Recovery Agents). Nazwa użytkownika jest wyświetlana jako UŻYTKOWNIK_NIEZNANY (USER_UNKNOWN), ale jest wciąż obowiązująca.

11. Naciśnij Dalej (Next). Otworzy się okno zakończenia.

12. Naciśnij Zakończ (Finish). Certyfikat został dodany do listy związanej z Agentami odzyskiwania danych zaszyfrowanych (Encrypted Data Recovery Agents). Komputery klienckie muszą zostać uruchomione ponownie, aby uzyskać nowe założenia systemowe.

Sprawdzenie funkcjonalności alternatywnego agenta odzyskiwania danych

Bezpośrednie potwierdzenie, że klienci włączyli nowego agenta do pola Data Recovery Field dla plików zaszyfrowanych, jest trudne. Powinna zostać wykonana pośrednia weryfikacja na tym komputerze, na którym utworzono certyfikat odzyskiwania plików (File Recovery certificate).

Procedura 14.20. Potwierdzenie, że alternatywny agent DRA potrafi odzyskać plik zaszyfrowany

1. Zaloguj się jako drugi użytkownik, taki, który nie jest agentem DRA.

2. Zaszyfruj plik.

3. Wyloguj się, a następnie zaloguj wykorzystując konto agenta DRA.

4. Otwórz plik zaszyfrowany. To stanowi „odzyskanie” pliku. Możesz także wyłączyć atrybut szyfrowania i przetworzyć plik z powrotem na postać niezaszyfrowaną (otwartym tekstem). Jeśli nie jesteś w stanie otworzyć pliku, powtórz kroki z poprzedniego paragrafu i spróbuj jeszcze raz.

W następnym rozdziale

Teraz, kiedy pliki i katalogi są zamknięte za pomocą uprawnień NTFS, a użytkownicy mogą ochronić swoje najważniejsze dokumenty szyfrując je, czas na otwarcie drzwi. W następnym rozdziale opisano, jak konfigurować zasoby współdzielone i, co równie ważne, jak upewnić się, że użytkownicy mogą łatwo znaleźć te zasoby.

17

Cyferkę 1 zamienić na 4.

Strona: 1
W oryginale jest inny rysunek, ale ten, który jest, odpowiada treści.

Strona: 1
Brak rysunku!!

Strona: 1
Brak rysunku!!

Temp files are only ............. — Pliki tymczasowe tworzone są tylko w przypadku szyfrowania pojedynczych plików. Aby ominąć powstawanie tych plików, zawierających dane podane otwartym tekstem, powinny być szyfrowane tylko foldery.

Encypted with DESX using FEK as cipher — Zaszyfrowany za pomocą algorytmu DESX z wykorzystaniem klucza FEK jako szyfru.

FEK encrypted with users public key — Klucz FEK zaszyfrowany za pomocą klucza publicznego użytkownika.

FEK encrypted with DRA public key — Klucz FEK zaszyfrowany za pomocą klucza publicznego agenta DRA.

---