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



23.01.2018

Infrastruktura konwergentna

NFLEX firm Fujitsu i NetApp
19.01.2018

Wysoka gęstość

D-Link DGS-3630
16.01.2018

Odporne na korozję

Kamery Panasonic WV-X6531NS i WV-S1531LNS
12.01.2018

Bezpieczny AP

Ubiquiti UAP-AC-SHD
09.01.2018

Zarządzanie i dostępność

Veeam Availability Suite 9.5 U3
04.01.2018

Usługi w chmurze

Citrix XenApp i XenDesktop
27.12.2017

Nowe macierze All-Flash

Dell EMC SC All-Flash SC5020F/SC7020F
21.12.2017

Jak cyberzagrożenia zmieniły...

Na pytanie odpowiada Mukul Chopra, Director, Digital Transformation Centre, COMPAREX
21.12.2017

Rekord świata w SPEC CPU

HPE ProLiant DL385

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"