Gondolkodott már azon, hogyan válasszon hitelesítési szolgáltatót?
Egyre növekvő tendenciát tapasztalunk abban, hogy egyesített azonosítókat használunk a mindennap használt webhelyek hitelesítéséhez.
Számtalan alkalmazásba bejelentkezhetünk a közösségi média fiókjaink segítségével, a munkahelyi fiókok mindegyike rendelkezik egyszeri bejelentkezési képességekkel, sőt online banki hitelesítő adatainkkal bejelentkezhetünk kormányzati webhelyekre is.
Fogalmilag a hitelesítés (és az egyszeri bejelentkezés) egyszerű, de a megvalósítása nehéz és költséges. Bár a vállalkozások hagyományosan az építési funkciókra összpontosítottak, a valóságban most a felhasználói regisztrációs verseny csökkentésére kell összpontosítaniuk, anélkül, hogy az alkalmazást sebezhetőségnek tennék ki. Ahogyan a felhőalapú infrastruktúra-platformok (például az AWS) lehetővé teszik a vállalkozások számára, hogy az alkalmazások építésére összpontosítsanak, ugyanezt látjuk a hitelesítésnek is.
A hitelesítés szolgáltatásként (vagy hitelesítési szolgáltató) hitelesítési és felhasználókezelési szolgáltatásokat nyújt az alkalmazások számára.
Nem csak identitásszolgáltató, hanem konfigurálható felhasználói bejelentkezési oldalakat (vagy widgeteket), kijelentkezési funkciókat, egyesített identitásokat biztosítanak a közösségi média fiókokkal, felhasználói adatbázisokkal és bizonyos fokú felhasználói kezeléssel. A dobozon kívül képesek támogatni a közös hitelesítési protokollokat, mint például a SAML és az OpenID Connect.
Az egyszeri bejelentkezésre vágyó vállalati ügyfelek a SAML2 használatával gyakran kihasználhatják az egyszerű, egy kattintásos beállításokat olyan harmadik féltől származó alkalmazásokkal, mint a JIRA, az Office 365 és a Salesforce.
Mik a céljaid?
Időnként egy alkalmazás hitelesítési rendszereinek megvalósítása úgy érezheti magát, mintha újratalálná a kereket. A hitelesítés mint szolgáltatás (AaaS) koncepciója megkísérli megoldani ezt a problémát, de a szolgáltató kiválasztása (vagy egy egyedi megoldás bevezetése mellett dönt) előtt érdemes megfontolni néhány dolgot.
Kritériumok
Miután elkészítette a szervezete számára fontos szempontok listáját, itt az ideje elkezdeni értékelni a hitelesítést szolgáltatóként (AaaSp-ként) a piacon. Az elmúlt években számos AssSp-t láttunk belépni és eltűnni. Ez sokkal kritikusabbá teszi a megfelelő AaaSp kiválasztását. Mindenféle formában és méretben kaphatók - a kis ügyfelekkel rendelkező kisvállalkozásoktól a nagyvállalati eladókig.
Bizalom és hírnév
Olyan fontos dolog megbízása, mint a hitelesítés, jelentős önbizalmat igényel, ezért fontos, hogy a választott eladó jó hírű legyen és megbízható hatóság legyen a hitelesítésben. Fontolja meg, hogy architektúrájukat más biztonsági szakértők felülvizsgálták-e, és tekintse át a szolgáltatóval kapcsolatos esetleges online kommentárokat.
Amint láttuk Stormpath (vásárolt Okta 2017, akkor esett a Stormpath API), átmosás egy harmadik féltől megnyitja a kockázata árus megszüntetése. A legrosszabb esetben, ahogy a fent említett felvásárlásnál történt, sokaknak nem volt migrációs útjuk a Strompath-ról Okta-ra, és saját hitelesítési rendszereiket kellett bevezetniük.
Az eladó mérete, ügyféllista és vállalati profil általános irányelvek, amelyeket figyelembe lehet venni, de Ön mégis kockáztat. A kisebb induló szolgáltatók jelentős ösztönzőket kínálhatnak, de az a képességük, hogy megfelelő értesítés nélkül gyorsan eltűnjenek, kockázatos döntést hozhatnak. Alternatív megoldásként a nagyobb szolgáltatók továbbra is leállíthatják szolgáltatásaikat, ha ez az üzletág már nem válik nyereségessé.
Szánt felhasználók
Néhány AaaS-szolgáltató, például a One Login, kizárólag a B2E-re koncentrál - SSO-élményt nyújt a vállalat belső alkalmazottai számára webalapú szolgáltatásaikkal. Gondoljon a HR-forrásokra mutató linkeket tartalmazó vállalati portálokra, a Wiki, a Sharepoint és a Salesforce cégekre. Az Auth0 és az AWS Cognito a B2E-t és a B2C-t egyaránt kiszolgáló szolgáltatók, és kifejezetten támogatják az ügyfelek százezreit.
Vender Lock
Az AaaSp-vel való integráció jelentősebb mértékű kölcsönös függőséget eredményez, majd csak integrál egy alkalmazásverem egy felhőalapú megoldásba, mert az integráció befejezéséhez szolgáltató-specifikus kódot kell írni.
Ezt nemcsak vissza kell vonni, hanem további integrációs kódot kell írni az új szolgáltató számára. Az AaaS-ről az egyéni megoldás bevezetésére még költségesebb, mivel mindent a nulláról kell írni.
Az infrastruktúra-változásokkal ellentétben, ahol enyhítő csillagok léteznek a felhasználói megszakítások csökkentése érdekében, az AaaS-szolgáltatók cseréje szinte mindig hatással lesz a felhasználókra. Ne feledje, hogy olyan komponenseket cserélünk, amelyek közvetlenül érintkeznek a végfelhasználókkal.
Adatok importálása
A legtöbb AaaS-szolgáltató meghatározza a felhasználók rendszerbe történő importálásának mechanizmusát tömeges importálás (ahol a felhasználóknak jelszó-visszaállítási folyamaton kell keresztülmennie) vagy fokozatos migrációs folyamat révén. A fokozatos áttéréssel a felhasználói hitelesítő adatokat először a régi adatbázishoz igazolják, majd titkosítják és tárolják az új adatbázisban. Ebben a felhasználási esetben a költöztetés nem érinti a felhasználókat.
Adatok exportálása
Ez a szolgáltatás különösen fontos abban az esetben, ha az alkalmazások az AaaS adattárát használják. Biztonsági okokból az AaaS-szolgáltatók nem teszik közzé jelszó-kivonatoló algoritmusukat. Ezért, ha exportra van szükség, minden felhasználónak kezdeményeznie kell a jelszó visszaállítását.
Ha ez nem hangzik elég rosszul, sok AaaS-szolgáltató NEM biztosít tömeges adatexportálási funkciót, ezáltal extra bonyolultságot és manuális lépéseket adva a felhasználói adatoknak az AaaS-ből történő migrálásához.
Alvállalkozók
Az AaaS szolgáltatók által kínált egyes szolgáltatásokat még egy harmadik fél szolgáltatása teljesíti. A 2fa / mfa és az e-mail néha olyan funkciók, amelyekhez külön regisztráció (és további fizetés) szükséges a harmadik félnél.
Példaként a 2FA-t véve néhány AaaS-szolgáltatás nem teszi lehetővé, hogy kiválassza az alapul szolgáló 2FA-szolgáltatót, és arra kényszeríti, hogy használja a preferált szolgáltatót. Nemcsak arra kényszerül, hogy partnerségbe lépjen az adott eladóval, hanem arra is kényszerül, hogy fizesse az árakat (ahol olcsóbb alternatívák is elérhetők).
Technológiai támogatás
Protokollok
A legtöbb AaaS szolgáltató támogatja a főbb összevont protokollokat (OpenID Connect és SAML). Mások további csatlakozókkal rendelkeznek, amelyek lehetővé teszik a testreszabott adatforrások (Microsoft AD vagy LDAP) használatát, valamint a SMAL használatán keresztül egyszerűen beállíthatják harmadik féltől származó alkalmazásokat, mint például a JIRA, az Office 365 és a Salesforce.
Integráció
Az AaaS szolgáltatás integrálása az alkalmazásba továbbra is jelentős feladat lehet (különösen, ha egy régi alkalmazást futtat). Ezért egy szempont az, hogy az AaaS kínál-e könyvtárakat a technológiai veremhez.
Például: A legtöbb fő AaaS szolgáltató a közösségi média webhelyekkel együtt kliens könyvtárakat biztosít különféle hitelesítési tokenek és dokumentumok kérésére, fogyasztására és érvényesítésére. Ha Java-veremet futtat, sok szolgáltatás Java-könyvtárakat kínál a projektbe való beépítéshez bármilyen háttér-feldolgozáshoz. Ha a verem támogatott, akkor az integrációs folyamat olyan egyszerű lehet, mint egy JS fájlba dobni, beleértve a JAR-t, és néhány értéket kitölteni egy tulajdonságértékben.
Dokumentáció
A bőséges, jól megírt dokumentáció és a közösségi támogatás nagyban hozzájárul az integráció megkönnyítéséhez. Néhány szolgáltató kezdő és mintaprojekteket kínál a kezdéshez.
Más funkciók
Számos szolgáltatás kínál olyan szolgáltatásokat, mint a felhasználói profilozás, az e-mail és a 2fa / mfa.
Testreszabható felhasználói interfészek és folyamatok
Az AaaS-szolgáltatók különböző szintű testreszabást tesznek lehetővé a felhasználói felület oldalai, moduljai és felhasználói attribútumai számára. Ezenkívül néhány rendszer rendelkezik olyan „horgokkal”, ahol a folyamatok testreszabása megtörténhet (a Auth0 és az AWS Cognito pénztár részletekért).
A saját szervezetétől függően nehéz lehet megtalálni az egyensúlyt az UX igényeinek teljesítése és a szolgáltató által testreszabható (ésszerű keretek között) között. Bizonyos esetekben a kiválasztott AaaS nem támogatja az üzleti igényelt folyamatokat.
Megjegyzés a testreszabásról:
A dobozon kívüli kész hitelesítési képességek az AaaSp használatának egyik nagy előnye. Az előre gyártott alkatrészek használatakor az integráció hihetetlenül egyszerű.
Másrészt a felhasználói felület és az áramlások nehéz testreszabása növeli az időt és a bonyolultságot. Olyan erősen és nagymértékben testre szabhatja a felhasználói felületet és a hitelesítési folyamatokat, hogy fel kell tennie a kérdést, hogy olcsóbb- e egy egyedi házon belüli megoldást bevezetni (figyelembe véve az éves költségeket is). A válasz IGEN lehet .
Az a javaslatom, hogy tartsam vissza a lehető legtöbb testreszabást az AaaS keretein belül. Ez különösen igaz a hitelesítési és jelszó-visszaállítási folyamatokról, mivel a testreszabás hozzáadása ezekhez az összetevőkhöz növeli az integráció bonyolultságát és szállítói zárolást hoz létre.
Fejlesztési és tesztelési támogatás
Fejlesztési, minőségbiztosítási és termelési környezetek
Néhány vállalat elszigetelt fejlesztési és minőségbiztosítási környezettel rendelkezik. Ezeknek a követelményeknek a támogatása érdekében egyes AaaS-szolgáltatók lehetővé teszik egyetlen fiók számára, hogy több identitás-adatbázissal rendelkezzen. Ez sajnos nem univerzális szolgáltatás, és az AaaS-nél több fiókra lehet szükség az egyes tesztelési környezetek támogatásához.
Terhelés tesztelése
Minden AaaS rendszer tiltja az illetéktelen terhelés tesztelését. Ez akkor jelenthet problémát, ha alkalmazásához végpontok közötti terheléses tesztre van szükség a gyártás jóváhagyásához. Ebben az esetben néhány AaaS-szolgáltató engedélyezi a terhelés tesztelését, ha azt a teszt elvégzése előtt előzetesen engedélyezték. Gyakran szigorú korlátozások és időkeretek vannak, amelyek alatt a tesztet le kell futtatni.
Reálisabban valószínűleg be kell vezetnie egy bejelentkezés by-pass mechanizmust az alkalmazás számára a terhelési tesztek támogatásához.
Árazás
Az árképzési modellek jelentősen eltérnek az AaaS szolgáltatók között. Egyes szolgáltatók ösztönzik a kis induló szervezeteket, és ingyenes vagy nagyon megfizethető legalacsonyabb szinttel rendelkeznek. Általánosságban véve számíthat arra, hogy az alábbiakhoz hasonló ár / felhasználó grafikon jelenik meg:
A felhasználónkénti ár kezdetben nagyon alacsony (vagy 0 dollár), ami nagyszerű kis szervezetek vagy kis volumenű induló vállalkozások számára. A felhasználói bázis növekedésével azonban az ár / felhasználó állandó marad. Végül egy bizonyos pont után csökkenni kezd, mert vagy elérte a legmagasabb használati szintet, vagy képes tárgyalni az árakról.
A költség ésszerűnek tűnhet, amikor elindul, de ha bezárkózott, egy alkalmazás, amelynek 100 000 aktív felhasználója van egy hónap alatt, évi 150–200 ezer számlát láthat!
Ha alkalmazásának már több százezer felhasználója van, akkor olcsóbb lehet saját megoldást bevezetni! A felhasználónkénti díjak mellett gyakran felszámításra kerülnek az esetlegesen felmerülő további szolgáltatások (ismét a 2fa és az e-mail).
B2C
Tárgyaljon az árról, ha alkalmazásának nehéz használati ideje van. Egyes szolgáltatásoknál a tényleges aktív felhasználók száma alapján változó az árképzés, míg mások az év legnehezebb hónapjának becslése alapján rögzítik a havi árat (függetlenül attól, hogy hány felhasználó használja a rendszert). Az ártervek közötti különbség jelentős lehet.
B2E
Az árakat mindig alkalmazotti számlánként határozzák meg. Vigyázzon a minimális díjakkal az apró betűkkel!
Felhasználókezelés és Irányítópult
A legtöbb AaaS rendszernek valamilyen alapvető felhasználói kezelési módja van beépítve az admin irányítópultokba. Bizonyos esetekben létrehozhat nem rendszergazdai fiókokat az ügyfélszolgálati képviselőihez vagy más társaihoz a felhasználói identitás módosításához.
Kerülni kell a teljes rendszergazdai fiókok kiadását az alkalmazottaknak, hogy hozzáférhessenek a felhasználókezelési irányítópulthoz . Az adminisztrátori fióknak csak a megfelelően képzett alkalmazottak kezében kell lennie, különben fennáll annak a kockázata, hogy valaki véletlenül törli az egész felhasználói adatbázist, vagy feltárja a felhasználói azonosítókat.
Az, hogy a beépített AaaS-irányítópult támogatja-e az Ön igényeit, a szervezet felhasználói igényeinek a felhasználói attribútum mindennapi megváltoztatására vonatkozik. Győződjön meg arról, hogy az AaaS megfelelő ellenőrzési nyomon követési / naplózási nyomot biztosít a szervezete házirendje szerint.
SLA és ügyfélszolgálat
A szolgáltató fiókkezelőjével való közvetlen kapcsolatfelvétel nem minden AaaS-szolgáltatónál elérhető. Az ingyenes vagy alacsony felhasználású szintek gyakran csak a közösségi fórumokhoz férnek hozzá. Néhány szolgáltató fizetett támogatást, dedikált szervereket, naplókhoz való hozzáférést és HIPAA / PCI-megfelelőséget kínál felár ellenében.
A legtöbb AaaSp a szokásos 99,9% -tól 99,995% -ig terjedő SLA üzemidőt kínálja, de ez még mindig lehetővé teszi a leállásokat az év során. Ez akkor lehet fontos, ha kritikus időszakokban az alkalmazásnak fent kell lennie. Néhány AaaSp vállalati megoldásokat (egyéni telepítéseket) kínál a redundancia valamilyen formájának biztosítására rendszerhiba esetén.
Következtetés
A kezdő vállalkozások számára az AaaSp megfizethető megoldást kínál a hitelesítéshez, így Ön a termékére koncentrálhat. Nagyobb, régi alkalmazásokkal és már kialakított felhasználói bázissal rendelkező szervezeteknél a kritériumok sokkal szélesebb listáját kell figyelembe vennie annak biztosításához, hogy az áttelepítéshez, naplózáshoz és költségkerethez szükséges AaaS-t válassza.
Követésként bevezetőt írtam az egyesített identitásokról és a hitelesítésről.