Podział obowiązków, a kontrola dostępu centralne zarządzanie użytkownikami i ich uprawnieniami.

Transkrypt

1 Podział obowiązków, a kontrola dostępu centralne zarządzanie użytkownikami i ich uprawnieniami. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 1

2 Fakty Rosnące wymagania biznesu na IT: Rozrastające się środowiska Linux/Unix Coraz większa liczba systemów, usług i danych Wysoki poziom skomplikowania i zależności Ciągła rekrutacja nowych pracowników Regulacje prawne Polityka bezpieczeństwa dedykowana dla całej organizacji Domena Active Directory w środowisku Windows: Hermetyczne i kompletne podejście Standard korporacyjny 2

3 Problemy środowisk Linux/Unix Do jakich systemów Leszek.Miś miał dostęp? Kto zna hasło roota do systemów krytycznych? Czy przestrzegana jest polityka bezpieczeństwa haseł? Z jakich adresów IP można logować się do systemów krytycznych? Kto dodał tego użytkownika? Kto uruchomił usługę telnet? 3

4 Problemy środowisk Linux/Unix Kto i kiedy próbował uzyskać uprawnienia roota? W jaki sposób nadać dostęp użytkownikowi Leszek.Mis do farmy 500 serwerów z uwzględnieniem: Przeznaczenia systemów Różnych uprawnień i przypisanych ról Kontroli dostępu Rozliczalności i audytowania działań 4

5 IdM - potrzeby organizacji Nieskomplikowana integracja z Active Directory/SSO Rozliczalność czyli kto, co, gdzie i kiedy? Centralne uwierzytelnienie Spójne zarządzanie tożsamością i dostępami Jednolitość UID/GID Polityka bezpieczeństwa kont i haseł użytkowników Najwyższy poziom bezpieczeństwa przy zachowaniu funkcjonalności Domena administratorów Separacja funkcji administracyjnych 5

6 Separacja funkcji Administracja vs. projektowanie zabezpieczeń Administracja vs. monitorowanie Administracja vs audyt Nadzór nad działaniami użytkowników Separacja uprawnień SELinux/RBAC/MCS: www_admin: www_r -> httpd_*_t (uid=0) dns_admin: dns_r -> named_*_t (uid=0) app_admin: tomcat_r -> tomcat_*_t (uid=0) Podział uprawnień roota pomiędzy kilkoma użytkownikami, tzw. security officers 6

7 Klasyfikacja danych Różne typy danych o różnej klasyfikacji (o różnych poziomach bezpieczeństwa) MultiLevel Security/MultiCategory Security: Możliwość klasyfikacji danych z uwzględnieniem czułości (sensitivity) Nadawanie plikom kategorii przez zwykłych użytkowników Dostęp do danych dla użytkowników z różnymi poziomami dostępu do danych Niskie i wysokie komponenty wysoki zawsze dominuje nad niskim Przykład: kategoria Company_Confidential 7

8 Klasyfikacja danych No read up, no write down 8

9 Ochrona systemów krytycznych Obowiązkowa kontrola dostępu ubezpieczenie Piaskownice czyli tzw. Sandboxing Ograniczenie możliwości wykorzystania podatności Utwardzanie: standardy STIG, CIS, PCI DSS 9

10 Red Hat IdM Mix ustawień operujących na: Użytkownikach i grupach Hasłach i politykach Hostach i grupach hostów Usługach Sudo, HBAC, SELinux, AD Cross Realm Trust Synchronizacja 10

11 Red Hat IdM Integracja Linux-Active Directory: 11

12 Rekomendacja D 5.2: Bank powinien precyzyjnie zdefiniować obowiązki i uprawnienia poszczególnych pracowników w zakresie technologii informacyjnej i bezpieczeństwa informacji. 11.2: Parametry haseł dostępu (w tym długość i złożoność hasła, częstotliwość zmiany, możliwość powtórnego użycia historycznego hasła) oraz zasady blokowania kont użytkowników powinny zostać ustalone w regulacjach wewnętrznych, z uwzględnieniem klasyfikacji systemu 11.5: Opracowania standardowych profili dostępu dla określonych grup pracowników lub stanowisk pracy 11.6: Bank w miarę możliwości powinien ograniczać użytkownikom dostęp do funkcji pozwalających na samodzielne zwiększenie własnych uprawnień. 11.9,

13 13 Pokaz integracji systemu RHEL z Active Directory za pomocą Cross Realm Trust: - Utworzenie nowego - Dodanie do grupy - Zablokowanie konta - Wymuszenie zmiany hasła

14 Pokaz ograniczenia dostępu do użytkownika root dla wybranych użytkowników, w obrębie wybranych hostów. admin1->wszystkie hosty, wallf1->sudo httpd webapp1->liferay (HBAC) leszek->wszystkie hosty 14

15 Po godzinach Sercem integracji jest mechanizm SSSD: Demon dostarczający dostęp do zdalnych zasobów typu identity and auth. Komunikuje się z systemem poprzez moduł NSS i PAM: Backendy: LDAP,Kerb,IPA,AD,proxy Offline cache + Redukuje load Server failover Jedno połączenie do serwera katalogowego Bez potrzeby wsparcia dla atrybutów POSIX po stronie AD Bezpośrednie mapowanie SID->ID = konwersja Windows Security Identifiers do UNIX IDs Automatyczne przyznawanie wartości: ldap_id_mapping = true Traktuje AD jako typowy LDAP server 15

16 Dziękujemy za uwagę. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 16