Podkast 23T7 ZTNA – 3 Korzyści Single Sign-On

WERSJA TEKSTOWA

Cześć. Witam Cię w dzisiejszym podkaście. Temat to Zero Trust Network Access a konkretniej element Single Sign On czyli system uwierzytelniania dla różnych aplikacji. Dziś postanowiłem omówić trzy najważniejsze zalety.

Pierwsza to bezpieczeństwo. Dlaczego SSO je zwiększa? Przede wszystkim wiadomo, problem jest z zapamiętywaniem haseł. Jeżeli mamy różne hasła do różnych systemów – a generalnie tak powinno być – jeśli mamy niezależne logowania – to musimy pamiętać dużą ilość haseł. W praktyce do wyboru mamy dwie opcje. Używamy tego samego hasła lub kilku do wszystkich systemów co jest najczęstszą praktyką i oczywiście jest to niebezpieczne bo w przypadku kompromitacji dowolnego z tych systemów to hasło jest automatycznie znane atakującemu i próbuje on się nim logować do innych systemów. Tak nie należy robić.

Opcja druga – zarządzanie tymi hasłami, czyli jakiś password manager i jest to dobry wybór, zwłaszcza w użytkowaniu indywidualnym. W przypadku, gdy nie masz dużego IT, czy nie jesteś częścią tego dużego IT, to zarządzanie hasłami w postaci managera haseł jest całkiem niezłym rozwiązaniem. Rozwiązanie to ma jednak minus – jeśli jest to zastosowanie firmowe, to nie mamy centralnego punktu uwierzytelniania, kontroli nad tym czy aktywujemy czy dezaktywujemy użytkownika, do czego on się loguje – tego też centralnie nie widzimy. Mając możliwość zastosowania jednego systemu SSO, jednego centralnego systemu do którego odsyłamy wszystkie zapytania dotyczące uwierzytelnienia, mamy to bezpieczeństwo wyższe. My jako IT kontrolujemy ten jeden centralny punkt uwierzytelnienia i możemy dodatkowe funkcjonalności bezpieczeństwa dodawać.

Tu przechodzimy do drugiego punktu – bardzo istotnego z punktu widzenia stosowania SSO i zalety jakie SSO daje – czyli łatwość uwierzytelniania. W przypadku bezpieczeństwa już omówiliśmy, że z powodu tego jednego hasła to już jest wyższe bezpieczeństwo ale oprócz tego liczy się tu również taka użyteczność. User experience. Jeżeli używamy SSO i logujemy się do niego najczęściej raz na jakiś czas to potem uruchamiając daną inną aplikację – najczęściej webową – to mamy automatycznie zalogowanego użytkownika i w tej aplikacji widzimy co to jest za użytkownik, możemy mu przypisać uprawnienia, robić audyt jego interakcji z tym systemem. Wiemy dużo więcej na temat tego, kto się łączy i co robi w poszczególnych systemach.

Mamy możliwość wymiany tej informacji dzięki takim zestandaryzowanym protokołom jak np. SumUp i wysyłaniem informacji do danego systemu w postaci tokena. Najczęściej spotykam Office 365, jako ten system SSO ale nie jest to jedyna opcja, są też inni operatorzy. Logujemy się tam swoim kontem domenowym i standardowo mamy dostęp do Outlooka, poczty i innych rzeczy, które nam pozwalają korzystać z Office. Jednocześnie jeśli otworzymy inny system np supportowy – w przypadku inżyniera supportu lub system sprzedażowy, jakiś salesforce – w przypadku handlowca. Będzie on automatycznie zalogowany do tego systemu i to jest super z punktu widzenia tego użytkownika – nie musi on nic robić, klika i automatycznie się loguje i mu działa. Mimo tego, że musi on chwilę poczekać bo jest tam trochę informacji transakcyjnych wysyłanych pomiędzy poszczególnymi systemami a systemem SSO, to jest to użyteczność bez wątpienia atrakcyjna. Nie tylko mamy wyższy poziom bezpieczeństwa ale mamy również wyższą użyteczność.

Trzeci punkt jest taki, że jeżeli mamy ten centralny system uwierzytelniania SSO to możemy do niego dokładać kolejne klocki bezpieczeństwa. Np. uzależniać uwierzytelnienie użytkownika od tzw. scoringu, czyli Risk-Based Authentication. Mierzymy różne zachowania danego użytkownika i to też jest zdecydowanie polecana taktyka na podwyższenie bezpieczeństwa. User behaviur analytics w kontekście naszych firmowych użytkowników. Mierzymy sobie, zbierając informacje, jakie jest to zachowanie i tworzymy pewne schematy zachowań (jest to automatycznie stworzone – machine lerning a pod nim schemat zachowania użytkownika tworzony). Jeśli mamy anomalie to możemy tą informację wykorzystać i zablokować np. możliwość dostępu takiego użytkownika. Możemy to również zrobić w kontekście konkretnych jakiś krytycznych systemów, nie wszystkiego.

Mamy tu możliwość elastycznego kreowania sobie tego w jaki sposób będziemy udostępniać te nasze zasoby do naszych systemów podwyższając poziom bezpieczeństwa, jednocześnie zapewniając wyższy poziom użyteczności dla tego użytkownika.

Na koniec podsumowując te trzy punkty możesz zapytać jak to się ma do Zero Trust Network Access. Ma się to bardzo prosto. Zero Trust Network Access zakłada, że my, tak jak mówiłem w poprzednim odcinku, mamy pełną informację o użytkowniku. Wiemy kto to jest, do jakiej grupy przynależy, wiemy jakie poziomy uprawnień chcemy mu przyznać czyli np. do jakich aplikacji ma mieć dostęp. W różny sposób możemy to implementować ale ten pierwszy podstawowy element czyli informacja o użytkowniku jest dla nas najbardziej kluczowa, żeby móc w ogóle pójść dalej w koncepcji Zero Trust Network Access. Bez tego zbiorczego punktu nic się nie da zrobić, jeżeli chodzi o dalsze zabezpieczenia systemów. Informacja o tym kto jest, jest bardzo kluczowa.

Podsumowując, bez wątpienia jeśli ktoś chce iść do Zero Trust Network Access system centralnego uwierzytelnienia ewentualnie połączony z IAM’em, czyli Identity Managerem jest elementem bardzo istotnym i najczęściej wymaganym, żeby pójść dalej. Po prostu bez tego się nie da. Taki jeden przykład – jeżeli chciałbyś zrobić Network Access Control, czyli dostęp do sieci po uwierzytelnieniu to musisz gdzieś tego użytkownika uwierzytelnić. Musisz zebrać skądś informację o tym, w jakiej jest np grupie domenowej. Oczywiście domena i SSO to nie jest jednocześnie to samo bo gdy mówimy o domenie, to jest jeden punkt uwierzytelniania ale dla systemów Windowsowych. W przypadku komputera, który ma zainstalowany system Windows to tak, jest to jedno miejsce uwierzytelnienia. Jeśli jednak chcesz zalogować się do systemu webowego to bez powiązanego z tą domeną systemu SSO nie ma jak tego zrobić.

W związku z tym trzeba ten element SSO rozpatrzyć i zachęcam absolutnie wszystkich do tego, żeby pomyśleli nad tym tematem. Również małe firmy z małym działem IT mogą to rozważyć bo to licencjonowanie większości systemów SSO jest w oparciu o ilość użytkowników. Nawet dla małych firm są to typowo systemy chmurowe. Mamy możliwość wykupienia odpowiedniej ilości subskrypcji tak, żeby zapewnić tą funkcjonalność SSO dla naszego zespołu czy środowiska, które ma się logować w ramach naszej firmy. Możemy to wiązać zarówno z AD on prem’owym, czyli takim klasycznym, możemy to wiązać z AAD czyli w Azure, możemy to wiązać z innymi systemami jeżeli mamy taką sytuację i taką potrzebę.

Na dziś to tyle, dziękuję Ci za uwagę. Jeśli masz jakieś pytania bądź tematy – pisz w komentarzu. Do usłyszenia już za tydzień.