Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



19.10.2018

4K, HDR i USB-C

Philips 328P6VUBREB
16.10.2018

Pełna optymalizacja

Quest Foglight for Virtualization Enterprise 8.8 (FVE)
12.10.2018

Linux w chmurze Azure

SUSE Linux Enterprise 15 / Microsoft Azure
09.10.2018

Nowe antywirusy

Bitdefender 2019
03.10.2018

Niezawodny tandem

Veeam Hyper-Availability Platform i Cisco HyperFlex
26.09.2018

Zarządzane z chmury

NETGEAR GC752X(P)
21.09.2018

Kolor razy 6

Kyocera ECOSYS i TASKalfa
18.09.2018

Na ataki piątej generacji

Check Point 23900
14.09.2018

UHD dla pro

Samsung UJ59

Active Directory a rozporządzenie rodo

Data publikacji: 30-10-2017 Autor: Jacek Światowiak
Rys. 1. Szerokie uprawnienia...

Niniejszy artykuł jest próbą odpowiedzi na pytanie, czy Active Directory jako system informatyczny, który może przechowywać dane osobowe (w rozumieniu rodo), spełnia ogólne wymagania dla procesów i systemów przetwarzania danych osobowych określone jako „privacy by design” (zapewnienie ochrony danych na etapie projektowania) i „privacy by default” (domyślna ochrona danych).

Może nie spełniać” – na takie hasło część administratorów może się od razu oburzyć. Dlaczego nie, skoro w tym systemie pracują od lat i nikt nie wnosił do tej pory żadnych uwag dotyczących bezpieczeństwa tego środowiska. Postaramy się wyjaśnić, gdzie leży jeden z drobnych, ale poważnych problemów w zakresie wykorzystania środowiska AD w roli repozytorium danych osobowych. A co ważniejsze, pokażemy, jak ten problem usunąć, aby przynajmniej w tym zakresie spełnić wymagania dotyczące prywatności przechowywania danych osobowych w bazach Active Directory. Zagadnienia omawiane w tym artykule charakteryzują się wysokim poziomem szczegółowości i przeznaczone są dla administratorów środowisk Active Directory. Stopień zaawansowania według skali Microsoftu to 200-300.

> BEZPIECZEŃSTWO KLASY C2

Systemy Windows już od wersji NT były przygotowywane, aby spełniać wymagania bezpieczeństwa wg standardów amerykańskiego departamentu obrony (U.S. Department of Defense). Zostały one pierwotnie opisane w tzw. Orange Book w 1983 r., po czym przekształciły się w 2005 r. w standard międzynarodowy określany jako Common Criteria. Systemy te miały docelowo spełnić wymagania klasy C2. Pojęcie to oznacza, w skrócie – ochronę z kontrolą dostępu. System musiał zatem zapewnić prowadzenie dla każdego użytkownika indywidualnie dziennika zdarzeń związanych z bezpieczeństwem (np. logowanie, uruchamianie procesów) oraz środki do określania zakresu rejestrowanych zdarzeń (audytowanie). System miał też spełniać wymagania w zakresie bezpiecznego przechowywania haseł dla użytkowników. Wymagał również odpowiedniego poziomu izolacji pomiędzy uruchamianymi procesami i zadaniami.

> GRANULARNE PODEJŚCIE DO OBIEKTÓW i ICH ATRYBUTÓW

Active Directory, analogicznie jak każda inna baza typu LDAP, zbudowane jest z obiektów (precyzyjniej klas obiektów), zaś każda klasa ma swoje atrybuty. Z tych klas (zdefiniowanych w tzw. schemacie) budowane jest odpowiednie drzewo klas obiektów. Aby zapewnić bezpieczeństwo, baza ta definiuje zasady dostępu (uprawnienia), zarówno na poziomie obiektu, jak i na poziomie atrybutu obiektu. Przykładowo do testowego użytkownika Jan Kowalski (rys. 1) wbudowana grupa zabezpieczeń o nazwie Pre-Windows 2000 Compatible Access ma uprawnienia Read All Properties, czyli może czytać prawie wszystkie atrybuty, poza atrybutami, które są tylko do zapisu albo do hasła.

> WŁAŚCIWOŚCI tzw. TOŻSAMOŚCI SPECJALNYCH – GRUPA Authenticated Users

Pod pojęciem grupy Authenticated Users kryją się użytkownicy oraz – uwaga – również komputery, które uwierzytelniły się w Active Directory dowolną metodą i protokołem (NTLM, Kerberos, basic, CHAP, certyfikat). Jednakże problem nie leży w tym, kto jest członkiem tej grupy, ale członkiem jakiej innej grupy jest grupa Authenticated Users. Tu, niestety, istotna jest konieczność utrzymywania przez Microsoft zgodności z systemami klasy NT 3.X/4X. Grupa Authenticated Users jest członkiem „nieszczęsnej grupy” Pre-Windows 2000 Compatible Access.

Zalecenie ogólne

Jeżeli w środowisku nie ma już systemów klasy NT 3.X/NT 4.X, należy grupę Authenticated Users usunąć z grupy Pre-Windows 2000 Compatible Access – gdyż ta grupa ma domyślnie zbyt wysokie uprawnienia do czytania obiektów z AD. Domyślnie są to: List contents, Read all properties oraz Read permissions.

Przykład zbyt wysokich uprawnień dla domyślnej konfiguracji grupy Authenticated Users prezentuje rysunek 2. Zalogowany użytkownik, będący zwykłym użytkownikiem domeny (należący do grupy Domain users oraz i oczywiście automatycznie do grupy Authenticated Users ma prawo czytania wszystkich atrybutów innych obiektów, w tym i innych użytkowników.

[...]

Autor jest architektem rozwiązań IT, trenerem, autorem książek i publikacji technicznych, wykładowcą Politechniki Gdańskiej. Uzyskane certyfikaty: MCSE+M, MCSE+S, 20*MCTS, 9*MCITP, MCT, MSA, MCSA 2008, 2012, 2016,Windows 7, MCSE Server Infrastructure, Communication, Messaging, Cloud Platform and Infrastructure, Productivity 2017

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2013 Presscom / Miesięcznik "IT Professional"