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



23.11.2017

Z IEEE 802.3bz

Przełączniki Netgear
21.11.2017

4K z USB-C

EIZO FlexScan EV2785
16.11.2017

Wielofunkcyjne MFP

Canon imageRUNNER ADVANCE C256i, C356i oraz C356P
14.11.2017

Fabryka Przyszłości w drodze...

W dniach 25 i 26 października we Wrocławiu odbyła się czwarta edycja konferencji...
14.11.2017

Pamięć definiowana programowo

Red Hat Container-Native Storage 3.6
09.11.2017

Zgodnie z rodo

Snow Software GDPR Risk Assessment
07.11.2017

Bezpieczna stacja robocza

F-Secure Protection Service for Business (PSB)
03.11.2017

III Forum Bezpieczeństwa...

21 listopada 2017 r. w PSE w Konstancinie-Jeziornie odbędzie się III Forum Bezpieczeństwa...
27.10.2017

Zasilanie gwarantowane

Schneider Electric Galaxy VX

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"