Wiele organizacji posiada własne zasoby informatyczne – w postaci stacji roboczych, serwerów i usług – utrzymywane w swojej siedzibie, które przez wiele lat wspierały jej funkcjonowanie i umożliwiały funkcjonowanie na rynku. Zapotrzebowanie na ilość i jakość usług IT cały czas jednak wzrasta i zagwarantowanie odpowiedniego ich poziomu z punku widzenia aktualizacji bazy sprzętowej, zakupu nowych licencji czy podnoszenia kwalifikacji informatyków jest coraz większym wyzwaniem.
Wykorzystanie usług w chmurze jest w takich przypadkach alternatywą godną rozważenia. Czy istnieją jednak jakieś realne przeszkody, które mogą to uniemożliwić ?
Jedną z naturalnych przeszkód jest obawa przed samą zmianą. Wiele firm bardzo często zarządza swoimi stacjami roboczymi i użytkownikami z wykorzystaniem kontrolerów domeny Active Directory. Niejednokrotnie w siedzibach firmy znajdują się również serwery poczty Microsoft Exchange, które bardzo często były aktualizowane przez wiele, wiele lat jeszcze od wersji 2000. Użytkownicy do wszystkich zasobów w organizacji uzyskują dostęp przy pomocy tej samej tożsamości. Może się wydawać, że dodatkowe wykorzystanie usług w chmurze to powielanie kont użytkowników, problemy z ustawianiem haseł, problematyczne łączenie usług i skomplikowanie dobrze funkcjonującego i znanego środowiska IT…
Ergonet wraz z Microsoft mogą przy pomocy swojego doświadczenia, odpowiedniego oprogramowania i procedur połączyć znajomość posiadanych przez firmę usług z potencjałem nowoczesnych rozwiązań Office 365 w jeden zintegrowany i dobrze funkcjonujący organizm – hybrydowe wdrożenie Office 365.
Problem tożsamości
Podstawowym zadaniem przy wdrażaniu hybrydowego rozwiązania z Office 365 jest rozwiązanie potencjalnego problemu wielu tożsamości. Wszystkie usługi Microsoft w chmurze – w tym Office 365 – przechowują dane o użytkownikach w swojej globalnej usłudze katalogowej – Azure Active Directory. Każda skrzynka pocztowa w Office 365 to jedno konto użytkownika w AAD, w którym poza odciskiem hasła (hasło nie jest przechowywane w postaci jawnej) i nazwą użytkownika są przechowywane inne atrybuty konta tj. adres, numery telefonów, tytuł, adresy email i wiele innych. Przy pomocy tego jednego konta i jednego hasła użytkownik Office 365 będzie mógł się zalogować do wszystkich pozostałych usług chmury Microsoft.
Co jednak w sytuacji, kiedy firma posiada już własne środowisko Active Directory? W takim przypadku każdy pracownik posiadałby już dwa konta z potencjalnie dwoma różnymi hasłami – jednego użytkownika w bazie użytkowników organizacji i drugiego w AAD. Aby rozwiązać ten problem, hybrydowe wdrożenie usługi Exchange oferuje kilka możliwości zarządzania tożsamością i sposobem uwierzytelniania w hybrydowej organizacji.
Zakładając, że podstawowym środowiskiem pracy użytkowników jest ich lokalne Active Directory, przy wdrożeniu hybrydowym należy w pierwszym kroku określić w jaki sposób będą sprawdzane poświadczenia użytkowników uzyskujących dostęp do usług w chmurze o365:
- Podczas dostępu do usług w chmurze za sprawdzenie poprawności nazwy użytkownika i hasła odpowiada O365 (uwierzytelnianie w chmurze)
- Podczas dostępu do usług w chmurze za sprawdzenie poprawności nazwy użytkownika i hasła jest odpowiedzialna infrastruktura AD w siedzibie organizacji (uwierzytelnianie federacyjne)
Uwierzytelnianie federacyjne
Po wybraniu tej metody uwierzytelniania usługa Azure AD przekazuje proces uwierzytelnienia do osobnego zaufanego systemu uwierzytelniania, takiego jak lokalne usługi federacyjne Active Directory (AD FS), w celu sprawdzenia poprawności hasła użytkownika. W tym modelu uwierzytelniania można wykorzystać bardziej zaawansowane (nie oparte na nazwie użytkownika i haśle) mechanizmy uwierzytelniania, np. uwierzytelnianie oparte na kartach inteligentnych.
Lokalne usługi federacyjne mogą być zlokalizowane w siedzibie organizacji lub dla zapewnienia odpowiedniego poziomu usługi w centrum danych Ergonet.
W przypadku awarii serwerów federacyjnych uwierzytelnienie w usługach Azure nie jest możliwe. Włączenie dodatkowo synchronizacji skrótów haseł umożliwia zagwarantowanie w takich przypadkach zapasowego źródła poświadczeń użytkowników, ale przełączenie z uwierzytelnienia federacyjnego na korzystające z synchronizowanych skrótów haseł nie jest procesem automatycznym i musi zostać świadomie uruchomione przez administratora.
Uwierzytelnianie w chmurze
Po wybraniu tej metody uwierzytelniania to usługa Azure AD jest odpowiedzialna za proces logowania użytkowników. W połączeniu z bezproblemowym pojedynczym logowaniem (SSO) użytkownicy mogą logować się do aplikacji w chmurze bez konieczności ponownego wprowadzania poświadczeń. W tym modelu uwierzytelniania można wybrać dwa sposoby zarządzania hasłami:
- Synchronizacja skrótu hasła Azure AD.Jest to najprostszy sposób, aby umożliwić uwierzytelnianie dla kont użytkowników Active Directory organizacji w usłudze Azure AD. W tym przypadku usługa Azure AD Connect poza synchronizacją standardowych danych użytkowników jest odpowiedzialna za synchronizowanie do chmury obliczeniowej skrótów haseł. Dzięki temu użytkownicy mogą używać tej samej nazwy użytkownika i hasła, których używają lokalnie, bez konieczności wdrażania dodatkowej infrastruktury. Hasła w usłudze Azure AD nigdy nie są przechowywane w postaci zwykłego tekstu ani szyfrowane przy użyciu odwracalnego algorytmu.
- Uwierzytelnianie tranzytowe Azure AD.Zapewnia prostą weryfikację hasła dla usług uwierzytelniania Azure AD za pomocą agenta oprogramowania, który działa na co najmniej jednym serwerze organizacji. Podczas logowania do usług w chmurze, serwery w chmurze komunikują się z agentami w organizacji klienta i sprawdzają poprawność poświadczeń użytkowników bezpośrednio w lokalnej usłudze Active Directory, co zapewnia, że sprawdzanie hasła nie odbywa się w chmurze. Firmy, które wymagają natychmiastowego egzekwowania lokalnych ustawień kont użytkowników, zasad haseł i godzin logowania, mogą skorzystać z tej metody uwierzytelniania.
W przypadku awarii agentów proces uwierzytelnienia w usługach Azure nie jest możliwy. Włączenie dodatkowo synchronizacji skrótów haseł umożliwia zagwarantowanie w takich przypadkach zapasowego źródła poświadczeń użytkowników, ale przełączenie z uwierzytelnienia tranzytowego na korzystające z synchronizowanych skrótów haseł nie jest procesem automatycznym i musi zostać świadomie uruchomione przez administratora.
Zalety i wady poszczególnych rozwiązań
Uwierzytelnianie w chmurze: synchronizacja skrótu hasła
Synchronizacja skrótów haseł wymaga najmniejszego wysiłku w zakresie wdrażania, konserwacji i zaangażowanej infrastruktury. Po włączeniu synchronizacja skrótu hasła jest częścią procesu synchronizacji Azure AD Connect i jest uruchamiana co dwie minuty. Obecnie synchronizacja skrótów haseł nie wymusza natychmiastowych zmian w stanach kont lokalnych. W tej sytuacji użytkownik ma dostęp do aplikacji w chmurze, dopóki stan konta użytkownika nie zostanie zsynchronizowany z usługą Azure AD.
Uwierzytelnianie w chmurze: uwierzytelnianie przekazywane
By uruchomić uwierzytelnienie przekazywane, potrzeba co najmniej 1 agenta. Zalecamy instalację 3 takich agentów. Instalujemy je na aktywnych serwerach organizacji. Agenty te muszą mieć dostęp do lokalnych usług domenowych w usłudze Active Directory, w tym do lokalnych kontrolerów domeny AD. Uwierzytelnianie tranzytowe wymaga nieograniczonego dostępu sieciowego do kontrolerów domeny. Cały ruch sieciowy jest szyfrowany i ograniczony do żądań uwierzytelnienia.
Uwierzytelnianie tranzytowe wymusza zastosowanie zasad konta lokalnego w momencie logowania użytkownika do usług chmurowych. Przykładowo możemy mieć do czynienia z odmową dostępu do usług chmurowych, gdy konto użytkownika w lokalnym AD jest wyłączone, zablokowane lub jego hasło wygasło lub próba logowania wykracza poza godziny, w których użytkownik może się zalogować.
Uwierzytelnianie stowarzyszone
Sfederowany system uwierzytelniania wymaga zewnętrznego zaufanego systemu do uwierzytelniania użytkowników. Jest to najbardziej skomplikowane rozwiązanie z dostępnych i zazwyczaj wymaga bardziej znaczących inwestycji w infrastrukturę lokalną. Większość organizacji wybiera tę opcję, jeśli korzysta już z tego rodzaju rozwiązań.
Sfederowane rozwiązanie uwierzytelniania jest zwykle wymagane, gdy klienci chcą wykorzystać mechanizmy uwierzytelniania, które nie są domyślnie dostarczane przez Azure AD, np.:
- uwierzytelnianie wymagające kart inteligentnych lub certyfikatów.
- lokalne serwery MFA lub zewnętrzni dostawcy wieloskładnikowi wymagający federacyjnego dostawcy tożsamości.
- uwierzytelnianie za pomocą rozwiązań uwierzytelniających innych firm
- logowanie się przy pomocy sAMAccountName, na przykład DOMAIN \ nazwa użytkownika, zamiast głównej nazwy użytkownika (UPN), na przykład użytkownik@domena.com.
W wyborze sposobu uwierzytelniania we wdrożeniu hybrydowym może pomóc poniższy diagram.
