Jak efektywnie i bezpiecznie zarządzać toŝsamością uŝytkowników przy jednoczesnym ułatwieniu korzystania z systemów i aplikacji IBM Corporation

Transkrypt

1 Jak efektywnie i bezpiecznie zarządzać toŝsamością uŝytkowników przy jednoczesnym ułatwieniu korzystania z systemów i aplikacji 2010 IBM Corporation

2 IBM Security Framework 1

3 KTO ma dostęp do CZEGO i DLACZEGO?? ToŜsamości Polityki Zasoby 2

4 ToŜsamości UŜytkownicy którzy potrzebują mieć dostęp do zasobów. Jane Doe s HR information HR System Name: Jane Doe Dept: Accounting Manager: John Smith Address: 10 Main St. Tel. No: Bus Role: Benefits Administrator KaŜdy uŝytkownik jest toŝsamością którą opisują atrybuty. Atrybuty mogą stanowić informacje która moŝe być wykorzystana w podjęciu decyzji do jakich zasobów dany uŝytkownik powinien mieć dostęp aby móc wykonywać swoje codzienne obowiązki. Przykładem takiego atrybutu moŝe być np. stanowisko. Proces zarządzania toŝsamością odpowiedzialny jest za przyznawanie uprawnień uŝytkownikowi do konkretnego zasobu, ich modyfikację oraz usuwanie uprawnień. 3

5 Zasoby Konta na systemach są wykorzystywane przez toŝsamości do wykonywania swoich codziennych obowiązków. Przykłady: Systemy Operacyjne Bazy Danych Aplikacje Meta Katalogi Unix, Windows DB2, Oracle SAP, Lotus Notes Active Directory UŜytkownik jkowalski posiada konto w Active Directory i jest członkiem grupy Domain Users oraz grupy Faktury która daje mu uprawnienia do Aplikacji Finansowej. UŜytkownik jkow posiada konto na systemie AIX wraz z katalogiem domowym /home/jkow oraz powłoką /bin/sh a takŝe naleŝy do grupy dbadmin. Grupa ta pozwala uŝytkownikowi na wykonywanie czynności administracyjnych na bazie danych. RACF: jk Unix: jkow AD: jkowalski 4

6 Polityka czyli DLACZEGO uprawnienia zostały nadane? ToŜsamości Polityka Zasoby Polityka definiuje kto moŝe mieć dostęp do zasobów. Politykę określa zestaw uprawnień oraz wykaz osób mogących wnioskować o uprawnienia Z polityką związane są procesy które mają na celu zebrać wymagane zgody na przydzielenie uprawnień do osoby wnioskującej oraz ciągłą kontrolę czy osoby te mają właściwe uprawnienia. 5

7 Identity change (add/del/mod) Access policy evaluated Approvals gathered Accounts updated Detect and correct local privilege settings Accounts on 70 different types of Accounts on 70 different types of systems managed. Plus, In-House systems managed. Plus, In-House Systems & portals Systems & portals Tivoli Identity Manager Applications Databases Operating Systems HR Systems/ Identity Stores Networks & Physical Access 6

8 Cykl Ŝycia konta System A Pracownik Kontraktor Serwisant Klient Audyt System B 7

9 Raportowanie 29 gotowych raportów między innymi lista uŝytkowników, lista systemów, lista uprawnień uŝytkowników i pełnionych przez uŝytkownika ról w przedsiębiorstwie, lista zdarzeń dotyczących procesów (np. kto wystąpił z wnioskiem o konto, kto zatwierdził itp.), historia zmian na kontach, lista nieuŝywanych tzn. martwych kont, lista nieuŝywanych kont od określonego czasu, niezgodności z określonymi zasadami polityki bezpieczeństwa, MoŜliwość wykorzystania ITIM Report Designer do modyfikacji raportów Format PDF lub CSV 8

10 SSO: Standardowe logowanie Data Access User Account Password Account n Password n Account 2 Password 2 Aplikacja n AuthN AuthZ Account 3 Password 3 Aplikacja 2 Aplikacja 3 AuthN AuthZ Klient Aplikacji Authenticated Authorized Aplikacja 1 AuthN AuthZ AuthN AuthZ AuthN AuthZ OK 9

11 SSO Standardowe logowanie Wiele kont, wiele haseł UŜytkownicy zapisują hasła UŜytkownicy zapominają hasła -> HelpDesk UŜytkownicy przeznaczają duŝo czasu na obsługę kont, haseł UŜytkownicy posiadający duŝo haseł są niezadowoleni UŜytkownicy starają sięłamać polityki poprzez trywializację haseł, powtarzanie ich Wymuszenie budowy niezaleŝnych polityk kontroli siły haseł DuŜe koszty zarządzania Brak audytu zmian haseł KaŜdy uŝytkownik będzie zapisywał hasła jeśli jest ich więcej niŝ 4 i są okresowo zmieniane!!! Większość uŝytkowników przechowuje zapisane hasła w pobliŝu stacji roboczej Najłatwiejszym sposobem otrzymania nieautoryzowanego dostępu do danych jest kradzieŝ zapisywanych przez uŝytkowników haseł 10

12 Rozwiązanie w szczegółach 11

13 Rozwiązanie w szczegółach 12

14 Silne uwierzytelnienie ACTIVE RFID Wsparcie dla: Passive RFID (Mifare, HID iclass) Active RFID (Xyloc) Tokeny (Vasco, Authenex) USB Key (DigiSafe, Charismathics) MobileAccessCode SMS Sonar Biometryka (UPEK, DigitalPersona) Wsparcie dla: Logowania do systemu Logowanie do aplikacji 2FA Wylogowanie przy nieobecności SMS USB Key SONAR TOKENY BIOMETRIC 13

15 Rozwiązanie w szczegółach 14

16 Enterprise SSO Wsparcie logowania do większości aplikacji: Windows Web Java Terminal, Mainframe Automatyczne budowanie dostępów dla aplikacji webowych, windows, java Wsparcie dla usług terminalowych Windows Terminal Services Citrix MetaFrame Presentation Server Wsparcie dla cienkiego klienta Terminale Wyse, NeoWare Windows CE, XP embedded RDP dla Windows 2003, Citrix EnGINA Łańcuch GINA zamiast podmiany MSGINA 15

17 Rozwiązanie w szczegółach 16

18 Integracja z Tivoli Identity Management Generowane po stronie IM uprawnienia zasilają portfele uŝytkowników Hasła zmieniane przez uŝytkowników automatycznie zasilają portfel System IM zarządza dostępem do TAMESSO Blokowanie portfela uŝytkownika z IM Wsparcie dla TIM 4.6, 5.0 i

19 Pytania 18

20 Dziękuje za uwagę 19