Enamiku organisatsioonide jaoks on terviklik ühtne identiteedisüsteem positiivne. Küsisite, kas on põhjust seda mitte teha. Loetlen välja mõned, mis võivad erinevates organisatsioonides kehtida või mitte:

1. Süsteem ei toeta identiteedi pakkujat. Teil võib olla pärandterminalipõhine suurarvuti süsteem, mida AD-ga linkimine pole lihtne. Pärandtoodete ja identiteedisüsteemide linkimiseks on palju kommertstooteid, ehkki need võivad olla kulukad. Teise võimalusena võivad teil olla pilvepõhised süsteemid (nt Salesforce), millega on keeruline integreeruda.

2. Süsteem on tundlik ja te ei soovi seda paljastada. identiteedisüsteemi rikkumine. See võib kehtida vähese arvu ülitundlike süsteemide kohta, kuigi seda argumenti kasutatakse ettevõttekeskkondades üle. Kui teie identiteedi pakkuja on AD, tähendab AD rikkumine tõenäoliselt kõigi tööjaamade rikkumist, mida inimesed nende süsteemide haldamiseks kasutaksid, nii et eraldamine pole midagi muud kui turvateater.

3. Süsteemi kaudu pole identiteedipakkujale juurdepääsu. Levinud näide on Interneti-põhised süsteemid DMZ-s, mille tulemüür blokeerib juurdepääsu sisemisele AD-le. Olen näinud suuri organisatsioone, kes loovad DMZ-süsteemidele eraldi AD. Sarnane probleem võib ilmneda arendus- ja tootmissüsteemide puhul.

4. Mõned kasutajad ei kuulu identiteedi pakkujate hulka. Klassikaline näide on see, kui teil on mõned välised kasutajad, kes sisenevad sisemisele süsteemile. Sellega saate hakkama, lubades süsteemil toetada mitut autentimismeetodit või lubades välistel kasutajatel olla teie identiteedipakkujas asjakohaste piirangutega.

Kas integreerimise raskused süsteem identiteedi pakkujaga on eeliseid väärt, on tasakaalustav tegevus. Enamik IT-administraatoreid nõustub, et volikirjahordi haldamine on osa tööst.

Kõigepealt on Active Directory patenteeritud protokoll, mida ei pruugi olla kõige lihtsam kasutada väljaspool Windowsi maailma. Sel põhjusel on tavaline, et teil on vähemalt kaks autentimist, üks Windowsi maailma jaoks, teine ​​teiste süsteemide jaoks (tavaliselt Unix / Linux). Selle saab muuta kasutajate jaoks peaaegu läbipaistvaks, kui üks autentimisteenuse pakkuja on teise sünkroonitud.

See suudab tavaliselt lahendada suurema osa autentimisvajadustest. Mis veel võib jääda:

• varaline tarkvara, mis nõuab oma privaatset autentimissüsteemi. See on ikka tavalisem, kui võiksime soovida ...
• madala taseme süsteemikontod (nt: root Unixi süsteemis või dba konto andmebaasis). Ehkki tavalistele kasutajakontodele võib anda privileege või võime neid sudo kaudu hankida, on tavaline lubada madalam kohalik administraatorijuurdepääs kui asjad lähevad valesti . Kuid see ei tohiks tavakasutajatele muret valmistada.
• arenduskontod. Arendusetapis ei pruugi rakendus olla ühendatud peamiste autentimisteenuste pakkujatega. Seega peavad arendajad ja testijad kasutama spetsiaalseid kontosid.

See on vastuvõetavate kasutusjuhtumite jaoks. Kuid on veel üks kategooria: SSO-süsteemi arveldamine maksab aega ja raha. Mõni organisatsioon võib otsustada sinna mitte minna, sest arvab, et see pole seda väärt või mõnikord seetõttu, et pole võimalikust kasumist teadlik. Ainult viimasel juhul võite oma otsesele juhile soovitada, et see oleks väga huvitav, kuid peate leidma reaalse kasutamise juhtumi, kus see aitaks säästa aega või vältida vigu. Kõik teevad seda ei pruugi suure ülemuse veenmiseks olla piisav ...

Active Directory on ebaturvaline (vaikimisi)

See on koputus ADFS-i vastu, kuna see tugineb AD-le, mille nõuetekohaseks turvamiseks on vaja veidi pingutada.

Kui kasutate Active-i Kataloog üldse --- ja eriti kui see kontrollib juurdepääsu kriitilistele süsteemidele ---, peate oma keskkonna kujundama selle tõsiste turvapuuduste kõrvaldamiseks.

Vähemalt peaksite juurutama Microsofti punase metsa kujundus vastavalt nende mitmetasandilisele haldusmudelile, et leevendada räsi (PtH), piletist (PtT) ja kuldsete piletite rünnakuid.

Föderatsioon on tulevik

Väliste kasutajatega suheldes on ADFS palju parem kui teie domeenis kontode loomine või AD-usalduste loomine. Kui saate kasutada ADFS-i, siis tehke seda kindlasti.

Kuna mainite konkreetselt Google'i identiteeti, põhinevad need OAUTH-il ja OAUTH peaks ADFS-iga koostööd tegema.

Kuna ADFS on lihtsalt Microsofti SAML-i identiteedi pakkuja juurutus, peaks see aja jooksul muutuma kasulikumaks. Ettevõtte mõistes on SAML endiselt üsna uus, kuid see on aina kasvanud.

Veel on vaja mitu kontot

Administratiivsed kasutajad vajavad endiselt mitut kontot. Te ei saa seda vajadust mõistlikult kõrvaldada. Igal kontol, millel on juurdepääs Internetile, ei peaks olema privileegitud juurdepääsu teie infrastruktuuri haldamiseks ega arendus- / testimiskeskkondades muudatuste tegemiseks.

Võite siiski konsolideerida, isegi kui administraatoritel peab olema 2–3 individuaalset AD-d kontod. Näiteks toetavad nii Oracle kui ka MS SQL Windowsi mandaatidega autentimist, nii et teie DBA-d ja arendajad ei vajaks enam kordumatuid kasutaja- / pääsukontosid igas eksemplaris.

Üks probleem, mille ma välja tooksin, on identiteedihaldussüsteemi reaalajas rünnakutele juurdepääsu puudumine. Näiteks kui keegi ründab teie identiteedihaldusserverit ja pääseb edukalt sisse, võite tegutseda kohe, kui olete sellest teadlik. Kui keegi seab kolmanda osapoole identiteedipakkujat ohtu, ei pruugi te paar kuud teada, millal / kui nad otsustavad rikkumise avalikustada.

Esiteks ei pruugi mind isegi soovida, et mõnes süsteemis oleks selline ühekordse sisselogimise süsteem. Kommentaaris mainisite andmebaase ja muid süsteeme. Tehnikatöötajana eelistaksin serveritega ühenduse loomiseks eraldi SSH-võtit (parooliga kaitstud), andmebaasidele juurdepääsu paroole jne. Nii et tsentraliseeritud identiteedipakkuja lahendus ei sobi kõigile vajadustele. Eriti arvestades seda, et selline lähenemine lisab veel ühe süsteemi (teie identiteedi pakkuja), mis peab autentimiseks olema kättesaadav. Tõenäoliselt kehtib see suurema osa ajast, kuid siiski tuleb seda meeles pidada.

Lisaks peavad süsteemid olema võimelised töötama identiteedi pakkujatega. Ma kahtlen, kas andmebaasile juurdepääsuks saab üldjuhul lubada kasutajanime / parooli asemel sellist identiteedipakkujat. Kõigi süsteemide migreerimine identiteedipakkuja kasutamiseks võib (ja kindlasti tekitab) probleeme, mida te ei osanud oodata. Võib-olla ei taha keegi selle muutmiseks aega ja raha investeerida, kuna kasutajanime / parooli on kindlasti lihtsam rakendada.

Eeldades, et kasutajatunnuse kirjutamine on probleem, mida proovite lahendada, propageeriksin väga paroolihaldurite kasutamine (võib-olla edastada OS-i vaikepildiga?) Üks parool nende kõigi juhtimiseks ja kasutajad saavad siiski säilitada iga teenuse jaoks raske paroole murda. Mõned kasutajad jätkavad nende kirjutamist lindile, mis asub nende klaviatuuri all, kuid see on äri kui kasutusviis (kahjuks).

Selguse mõttes meeldib mulle idee tsentraliseeritud identiteedipakkujast. Need on kõik punktid selle vastu, ma võin praegu mõelda. Kõik täiendused on teretulnud (see on huvitav küsimus).

Enne seda on palju häid vastuseid / kommentaare, nii et proovin seda lühidalt pidada.

Minu jaoks on peamine põhjus erinevate kasutajatega erinevate kasutajakontode kasutamiseks pikaajaliste mandaatide turvalisus, olenemata sellest, kas te kasutage uuesti paroole (nt LDAP), jagatud saladusi (nt Kerberos, TOTP jne), asümmeetrilisi allkirjaskeeme (nt SSH-võtmed).

Lihtne näide paroolidest:

ei soovi e-kirjade lugemiseks aktsepteerida sama parooli, mille kasutaja on oma mobiiltelefoni salvestanud, et anda administraatorijuurdepääs lukustatud taustaprogrammi andmebaasi serverile koos kõigi teie kliendiandmetega.

Teine näide eraldi SSH-võtmed:

SSH-süsteemide alamhulga puhul võite olla sunnitud kasutama SSH-võtmeagendi edastamist või veelgi hullem, kui kopeerite oma isikliku privaatvõtme hüpikhosti. Seetõttu ei soovi te sama privaatvõtit kasutada volitatud võtmena teistes süsteemides, millel on erinevad turvanõuded.

Jah, eraldi kontode pidamine Exceli failis vms on õudusunenägu ja see näitab, et enamik IAM-i süsteemid ja protsessid ei käitu mitme kontoga inimese kohta eriti hästi. Selle probleemi saab lahendada, kui valida korralik IAM-süsteem.

(Teil võib olla vaja erinevate süsteemide jaoks erinevaid autentimisskeemide kombinatsioone, kuid see on ka omaette õudusunenägu.)

Kõigi puhul sellised ühekordsed sisselogimismehhanismid nagu CAS, SAML, OpenID (Connect) jne. :

Ma arvan, et on imetlusväärne eesmärk kasutada neid võimaluse korral, kuna pikaajalised mandaadid ei edasta potentsiaalselt potentsiaalseid ebakindlam kui teie keskne sisselogimisteenus. Täna on veebirakendusi üsna lihtne integreerida. Peate kontrollima, kas nad saavad hakkama mitme identiteediseansiga või seadistada erinevaid SSO-eksemplare.

Aga nt. SSH sisselogimiste või võrgule juurdepääsu kontrollimiseks 802.1x-ga ei näe ma praegu hõlpsasti kasutatavaid SSO ega 2FA lahendusi. Nendel kasutusjuhtumitel võib lühiajaliste sertifikaatide (OpenSSH või X.509 sertifikaadid) väljaandmine olla otstarbekas lahendus.

TLDR: ärge langege üks või teine ​​lõksu. Kasutage korralikku IAM-süsteemi ja pakkuge igale süsteemile ja rakendusele õiged autentimisliidesed.