Hei,
Palju on räägitud erinevatest identiteedi mudelitest ning eriti hästi on see ära kaetud minu hea sõbra Kaido Järvemetsa poolt (https://kaidojarvemets.ee/enterprise-mobility-security/azure-active-directory-identiteedi-kontseptsioonid). Respect sõber! 🙂
Üheks enim levinud identiteedi mudeliks on täna küll Federeeritud identiteet (mis eeldab Active Directory Federation Services aka ADFS teenust), kuid olen üpris veendunud, et väga suur osa lahenduse kasutajatest ei saa täpselt aru, miks neil selline lahendus on või siis kasutavad nad sealt ära nii marginaalse osa võimekust (näiteks ainult SSO), et lahenduse koguvajadus võiks kahtluse alla olla seatud. Paljud konsultandid käivad ja müüvad põhjendamatult maha AD FS lahendust seletamata ettevõttele miks see neile vajalik on. Mõneti võime siin süüdistada raha, kuna AD FS projektid on oma mahult kõige suuremad. Minu nägemus on alati olnud, et ettevõtte võiks teada kõiki variante ning tegema otsuse vastavalt ärivajadustele.
Tänases Eestis oleks enamustele asutustele kõige optimaalsem (Oleneb jällegi kontseptsioonist aga siinkohal kirjutan enda kogemusest) rakendada Pass-Trough identiteedi mudelit. Antud lahendus on jõukohane, arusaadav ning keerukuse astmelt kõige optimaalsem. Vaatamegi siinkohal lähemalt mida antud lahendus endast kujutab ning mida juurutamiseks tarvis on.
Täna on meil olemas neli erinevat identiteedi mudelit.
- Pilv ainult identiteet
- Sünkroniseeritud identiteet
- Federeeritud identiteet
- Pass-Through Authentication identiteet (PTA)
Pass-Through Authentication, edaspidi PTA, identiteedi mudel on hetkel Microsofti kõige uuem lahendus ning nägemus identiteedi haldusest. Antud lahendust ootasime kaua, kuna kõik varasemad lahendused olid kas liiga keerulised, kallid ning mahukad (jääksid tugevalt alakasutusse) või liiga triviaalsed, vähefunktsionaalsed või asutuse turvapoliitikaga vastuolus (Parooli räsi pilve, kuid Microsofti poolt tugevalt soovitatud). Antud lahendus on täpselt vahepealne ning mõistlik.
Miks PTA?
- Lihtsam ja odavam kui federeeritud identiteet
- Võimaldab kontrollida kasutaja parooli vastu oma maja domeenikontrollerit
- Võimaldab SSO (Seamless Single Sign-On)
- Võimalik juurutada ka tasuta Azure AD versioonide puhul
Võrdleme põgusalt Federeeritud identiteeti ning PTA lahendust:
- Mõlemal juhul toimub parooli valideerimine majasisese AD pihta. Ehk parooli pilve ei sünkroniseerita. Küll aga võib paroolid pilve sünkroniseerida ning see on ka soovituslik lahendus. Seal on mitmed põhjused miks nii teha. Näiteks pilverakenduste edasi toimimine kui sisemine võrk enam ei vasta jne. See kõik sõltub aga asutuse turvapoliitikast
- PTA puhul sisestatakse kasutajanimi/parool pilverakendusse. AD FS puhul majasisese AD FS serveri peale
- PTA puhul on võimalik ainult kasutajanimi/parool tuvastus. AD FS puhul on võimalik nii kasutajanimi/parool, sertifikaadid jne
- PTA puhul on ainult vajalik kaks serverit. Üks nendest aktiivne ja teine passiivne. Mõlema serveri seadistamine läbi Azure AD Connect kaudu AD FS infrastruktuur on märksa mahukam ning nõuab vähemalt 4 serverit ja koormusjaoturit
- Mõlemad lahendused võimaldavad kaheastmelist tuvastust, kuid AD FS lahendusega on võimalik juurutada kolmanda partei tooteid ning ka näiteks ID-kaardi tugi
- Mõlemal juhul on olemas SSO. PTA puhul tuleb see eraldi sisse lülitada
- Mõlemal juhul on kasutatav Conditional Access, kuid AD FS puhul on võimalik täiendavalt lisada näiteks IP põhine ligipääs jne
- Erinevusi on veel mitmeid, kuid peamine sai ehk kaetud
Seega lühidalt võttes kui asutuses puuduvad vajadused kolmanda osapoole tarkvara või lahenduste järgi ning lahenduse keerukust soovitakse hoida optimeeritud, siis piisab täielikult PTA lahendusest. Seda on ka ajalugu näidanud!
PTA juurutamisest
PTA lahenduse juurutamine on lihtne. Vajalik on minimaalselt üks server, mis siis serveerib Azure AD ja on-prem AD vahelist sünkroniseerimist. Olenevalt kontseptsioonist oleks mõistlik kasutada kahte serverit, millest üks on Staging-modes ehk siis failoveri jaoks valmis. Seda on peamiselt tarvis siis kui paroole pilve ei sünkroniseerita ning kõik isikutuvastuspäringud tulevad otse majasisese AD peale. See muudab Proxy/AD Connect teenuse märksa kriitilisemaks, kuna juhul kui Proxyga midagi juhtub on automaatselt maas ka kõik pilveteenused.
Proxy server vajab vaid HTTPS/TCP 443 ligipääsu välja, et suhelda Azure pilvega ning sisemiselt peab ta ligi pääsema kohalikule AD Domeeni kontrollerile. Vajalik on kaks kontot, millest üks on Azure AD Globaalne administraatori konto (Esialgseks seadistamiseks.) ning sisemine konto, kellel on õigus sünkroniseeritavate objektide atribuute lugeda ning vajadusel ka kirjutada.
Enamus asutusi kipuvad sisemise teenuskonto tegema domeeni administraatoriks, kuna nii on lihtsam. Tõsi – nii on äärmiselt lihtne, kuna õigustega ei pea eraldi mängima. Mina ise soovitan aga kõik õigused manuaalselt vastavalt sünkroniseeritavatele OU´dele/objektidele välja jagada. Sellisel juhul ei saa “kogemata” asju juhtuda, kuna konto kustutamise õigust näiteks pilvel ei ole. Kõikide tegevuste jaoks on Microsofti koduleheküljel ka välja toodud atribuudid, mida loetakse/muudetakse vastavalt teenusele. Hiljem on seda hea vaadata ka Directory Synchronizaton tööriistaga, kus näidatakse väga hästi ära, et mida püütakse teha ja mida ei saa teha.
Kokkuvõtvalt saabki öelda, et väga suurele massile sobib edukalt Pass-through Authentication lahendus, mis on arusaadav ning mõistlik. Kui te plaanite juurutada alles pilveidentiteeti ning teete esimesi samme, siis mõelge kogu kontseptsioon kindlasti põhjalikult läbi. Hiljem on selle muutmine juba märksa keerulisem ja kulukam!
Kui selles vallas on nõu või abi vaja, siis võib minu poole julgesti pöörduda. Aitan meeleldi antud lahendust projekteerida ning juurutada.
