Какво е еднократно влизане (SSO) и социално влизане: пълно ръководство

Единичният вход (SSO) се превърна в съществена част от съвременното дигитално изживяване. Той позволява на човек да влезе веднъж и след това да има достъп до множество приложения, без да въвежда повторно идентификационни данни. Удобството е огромно и когато е внедрено правилно, то също така повишава летвата за сигурност.

Не всичко обаче е гладко: ако SSO акаунт попадне в грешни ръце, нарушител може да получи достъп до голям брой услуги. Ето защо SSO изисква силни пароли, добри практики за сигурност и най-вече многофакторно удостоверяване, за да затвори допълнителни врати за нападателите.

Какво е SSO и защо е важно?

Единичното влизане (SSO) е метод за удостоверяване, който позволява на потребителя да влезе веднъж и да получи достъп до множество свързани, но независими системи. Идеята е проста: по-малко пароли за запомняне, по-малко триене и по-плавно преживяване в приложения и уебсайтове . Типичен пример е екосистемата на Google , където едно влизане може да предостави достъп до услуги като Gmail или YouTube, без да се изисква от потребителя да използва повторно идентификационни данни.

Този подход се вписва в рамките за управление на идентичността и достъпа и често е интегриран с федеративни модели за идентичност. Резултатът е унифицирано изживяване, което, ако е проектирано внимателно, подобрява производителността, без да прави компромис със сигурността.

Как работи: SP, IdP и основният поток

Единичният вход (SSO) включва два основни участника: доставчика на услуги, който е приложението или уебсайтът, до който искаме да осъществим достъп, и доставчика на идентичност, който удостоверява потребителя. Доверието между тези две страни, организирано чрез стандарти и токени, е в основата на модела.

1. Лицето осъществява достъп до приложение или сайт, който действа като доставчик на услуги.
2. Този доставчик изпраща заявка за удостоверяване или токен до доставчика на самоличност.
3. Системата за идентификация отговаря с информацията, необходима за потвърждаване на SSO удостоверяване.
4. Когато е приложимо, потребителят се помоля да се идентифицира и да попълни необходимите данни.
5. След като идентификационните данни бъдат валидирани, достъпът се предоставя и тази сесия се разширява към други свързани приложения без рестартиране.

Струва си да се отбележи, че услугите за SSO обикновено не съхраняват пълната самоличност; като цяло те проверяват идентификационните данни спрямо базова услуга за управление на самоличността и издават или проверяват токени.

Рискове за безопасност и здраве при работа и как да ги смекчим

Основният риск е ефектът на доминото: с компрометирани идентификационни данни, нападателят може да получи достъп до множество приложения едновременно. Първата линия на защита са дълги, сложни пароли, сигурно съхранявани където и да се съхраняват.

Освен това, има почти единодушна препоръка в индустрията: 2FA или MFA. Добавянето на допълнителен слой сигурност, като например код на мобилния ви телефон, USB четец на пръстови отпечатъци или лична карта, драстично намалява риска от кражба на идентификационни данни.

SSO и многофакторно удостоверяване: естествени съюзници

Единичното влизане в системата (SSO) опростява достъпа, а многофакторното удостоверяване добавя слоеве за проверка, които блокират неоторизиран достъп. Комбинирането им осигурява много по-силна защита с минимално въздействие върху потребителското изживяване.

Федерирана идентичност, SSO и едно и също влизане

Федерално управление на идентичността

Федерацията на самоличността позволява на приложения от различни доставчици да споделят и валидират самоличности чрез обща рамка. Това дава възможност на някого да влезе в едно приложение и след това да има достъп до други, без да се налага повторно влизане, когато има доверие между домейните.

SSO срещу федерация на идентичности

Федерацията е по-широк обхват за управление и удостоверяване на самоличността в различни домейни и доставчици. SSO е специфична функционалност в тази рамка, която може да бъде ограничена до услуги от един доставчик или да се използва от множество доставчици.

Същият вход или същите идентификационни данни

Концепцията за едно и също влизане се отнася до използването на едни и същи синхронизирани идентификационни данни на различни устройства, подобно на мениджър на пароли , който автоматично попълва данните за вход. Това не е същото като SSO, защото SSO изисква влизане във всяко приложение, макар и с идентични идентификационни данни.

SSO срещу едно и също влизане

Единичното влизане (SSO) изисква само едно първоначално удостоверяване за превключване между свързани услуги; с еднократно влизане (SSO) потребителят трябва да влиза отново всеки път, използвайки едни и същи идентификационни данни. На практика SSO намалява подканите и централизира проверката; еднократното влизане стандартизира идентификационните данни, но не елиминира повторното влизане.

Ключови протоколи и технологии

SAML

Този език, базиран на XML, описва как да се пакетират и транспортират твърдения за удостоверяване и оторизация между доставчик на самоличност и доставчик на услуги. SAML е популярен в корпоративни среди и е много полезен за интернет приложения, които говорят по един и същ стандарт.

SAML сам по себе си не гарантира целостта на съобщението; той разчита на допълнителни механизми, като например цифрови подписи, за да гарантира, че съдържанието не е било променено. Оттук и значението на внедряването на подписи и стриктното валидиране на твърдения.

Kerberos

Роден в MIT в рамките на Project Athena, Kerberos дефинира цялостна архитектура за удостоверяване и оторизация, базирана на симетрична криптография. Започна с DES криптиране и днес приема AES, предлагайки по-дълги ключове и рундове, които засилват сигурността.

Симетричният му характер на ключовете изисква доверена трета страна, която да управлява ключовете и билетите, което го прави идеален за корпоративни мрежи, локални мрежи и VPN . Той се използва по-рядко в отворения интернет, а в среди на Microsoft е изборът по подразбиране пред NTLM.

OAuth 2.0

Това е рамка за оторизация, а не рамка за удостоверяване, предназначена да позволи на клиентско приложение достъп до защитени ресурси от името на потребителя. Тя включва клиента, сървър за оторизация, който издава токени, и сървъра за ресурси, който валидира тези токени.

Разрешенията могат да се коригират въз основа на контекст или тип устройство, като се променя обхватът и привилегиите. Например, смарт телевизор обикновено не се нуждае от същото ниво на достъп като лаптоп.

OpenID Connect

OIDC добавя управление на идентичността към OAuth, използвайки JSON и REST услуги, за да постигне естествено интернет изживяване. Използва криптография с публичен ключ и JSON уеб токени, улеснявайки интеграцията и проверката в голям мащаб.

J.W.T.

JSON уеб токените са компактни, подписани и подходящи за изпращане на заглавки и URL адреси. Те предоставят ID токен след удостоверяване и токени за достъп до ресурси, с валидиране, базирано на X.509 сертификати.

JWT файловете не са криптирани по подразбиране, така че трябва да се предават през защитени връзки и не трябва да включват чувствителни данни. Този модел е съвместим с REST архитектури, където състоянието се предава с всяка заявка.

LDAP

Олекотеният протокол за достъп до директории е проектиран за локализиране на ресурси в локална мрежа и съхраняване на атрибути на потребители и групи. Той не е подходящ за обща употреба в интернет и неговото удостоверяване по подразбиране е слабо без TLS защита.

Това позволява разширяване на данните за служителите и собствеността, но не се справя лесно с подробни оторизации. Днес се комбинира с други слоеве, за да покрие по-детайлните нужди от контрол на достъпа.

Удостоверяване със смарт карта и пароли

Системите със смарт карти и паролите разчитат на криптография с публичен ключ, при която защитен частен ключ на устройството подписва транзакциите, а споделен публичен ключ се използва за валидиране. Съвременните устройства интегрират TPM , Secure Enclave или еквивалентни системи като Android Knox за съхранение на ключове.

Ако дадено устройство бъде изгубено и нападателят знае паролата на собственика, само криптографията няма да предотврати неоторизирано използване. Смарт картите позволяват прехвърлянето на двойка ключове за многократна употреба между устройства чрез четец или NFC. В света на паролите вече има платформи, предлагащи SDK и компоненти за интегрирането им с SSO за много кратко време.

Единично влизане в облака и локално с Microsoft Sign In ID

В Microsoft Entra ID опцията SSO варира в зависимост от начина, по който приложението се удостоверява. В идеалния случай трябва да планирате стратегията си, преди да създавате или внедрявате приложения, и да използвате портала за приложения за по-лесно управление.

Федериран

Когато SSO е конфигурирано между различни доставчици на самоличност, това се нарича федерация. Това е най-цялостният подход, базиран на протоколи като SAML 2.0, WS Federation или OpenID Connect . В тази схема Microsoft Entra удостоверява потребителя със собствения си акаунт и приложението се доверява на този резултат.

Има ситуации, в които опцията SSO не се показва в корпоративно приложение: ако приложението е регистрирано чрез секцията за регистрация на приложение, удостоверяването е конфигурирано с OpenID Connect и опцията може да не се показва в навигацията на корпоративното приложение. В този случай OIDC разчита на OAuth 2.0 за оторизация без разкриване на идентификационни данни . Освен това, тя няма да е налична, когато приложението се намира в друг клиент или когато акаунтът няма достатъчно разрешения като администратор на облачно приложение, администратор на приложение или собственик на принципал на услугата.

Базирано на парола

Локалните приложения могат да изберат SSO, базирано на парола, особено когато използват прокси сървър за приложения. След първоначалното влизане с потребителско име и парола, системата сигурно възпроизвежда идентификационните данни чрез разширение за браузър или мобилно приложение . Това е полезно, когато искате да използвате съществуващия процес за влизане в приложението и да позволите на администратор да управлява паролите, без потребителят да ги знае.

Свързан

Свързаното влизане осигурява последователно изживяване по време на миграция. То ви позволява да публикувате връзки към различни приложения в портала, въпреки че не предлага истинско еднократно влизане (SSO) чрез Microsoft Sign In . В този случай MFA и условният достъп не могат да бъдат приложени към свързаното приложение и в целевото приложение трябва да съществува акаунт, автоматично или ръчно осигурен.

инвалиди

Когато SSO е деактивирано, потребителите може да се наложи да се удостоверят два пъти: първо в Microsoft Sign In и след това в приложението. Това е валидна опция, ако приложението все още не се интегрира, все още се тества или искате да наложите удостоверяване в локално приложение, което не го изисква . Забележка: Ако приложението използва SAML, иницииран от доставчика, и SSO е деактивирано, потребителите все още може да могат да влизат извън портала на приложението; за да предотвратите това, трябва да деактивирате възможността за влизане на потребителя.

За приложения , базирани в облак , се препоръчват протоколи за федерация. В локални среди, Application Proxy улеснява отдалечения достъп и защитеното публикуване. Изборът на метод ще зависи от това къде се хоства приложението, как маршрутизира трафика и кои протоколи поддържа.

Потребителско изживяване и портал за приложения

Повечето потребители искат да влязат и да започнат работа, без да се притесняват за протоколи. Порталът за приложения, известен като „Моите приложения“, централизира достъпа и намалява необходимостта от постоянно въвеждане на пароли.

Инициирано от IdP спрямо инициирано от SP

В поток, иницииран от доставчик на идентичност, сесията започва от IdP, който издава твърдение към доставчика на услуги. Ако е инициирана от SP, потребителят първо осъществява достъп до приложението, което го пренасочва към IdP за удостоверяване и сигурно връщане.

Социално осигуряване: предимства и предпазни мерки

Платформи като Google, Facebook и LinkedIn ви позволяват да използвате вашите идентификационни данни за достъп до услуги на трети страни. Удобството е неоспоримо, но уязвимост в платформата на социалните медии може да има ефект на домино върху други свързани акаунти; например, вижте как да докладвате данните си за вход в Gmail.

SSO за компанията и SSO за уеб сървъри

В големите организации, корпоративното SSO, или eSSO, работи в рамките на корпоративната мрежа. То може да разчита на симетрично криптиране, да предпочита SAML и да комбинира многофакторно удостоверяване за по-сигурни устройства и достъп . С нарастването на SaaS приложенията, компаниите избират между приемането на по-интернет-центрирани рамки като OAuth или изискването тези приложения да бъдат интегрирани в тяхната корпоративна схема за сигурност; много от тях подкрепят и двата подхода.

За публични уеб приложения, комбинацията от OAuth и OpenID Connect обикновено е естественият избор. Те са широко приети стандарти, проектирани да се мащабират в множество домейни и съобразени със съвременните очаквания за разработка.

Нулево доверие, адаптивни политики и най-добри практики

Надеждните SSO системи включват контекстуални проверки и политики, базирани на риска: местоположение, устройство, състояние на мрежовата сигурност или навици за използване. Прилагането на MFA, базирана на риска, и вземането на адаптивни решения помагат за съгласуване на SSO с подхода Zero Trust.

Що се отнася до защитата на данните, комуникациите трябва да бъдат криптирани с надеждни алгоритми като AES 256 или RSA 2048, в допълнение към подписването на токени и твърдения. Обучението на потребителите, ясно дефинираните политики и редовните одити допълват триъгълника на оперативната сигурност.

SSO и Active Directory: Ключови разлики

SSO е функция за контрол на достъпа, която позволява на потребителя да се удостовери веднъж и да получи достъп до множество свързани системи, без да въвежда повторно идентификационни данни. Active Directory, от друга страна, е услуга за директории, която централизира информация, политики и сигурност в рамките на инфраструктурата на Windows.

Active Directory (AD) се запитва и управлява чрез LDAP и се използва за организиране на потребители, компютри, групи и разрешения в голям мащаб, от малки мрежи до големи, многодомейни внедрявания. Докато AD съхранява и управлява самоличността, Single Sign-On (SSO) организира безпроблемен достъп между приложенията, като използва тази самоличност.

Единичното влизане (SSO) предлага удобство и по-чисто управление на достъпа, но изисква защита на главния ключ с MFA и контроли, базирани на риска. Протоколи като SAML, OAuth и OpenID Connect, заедно с технологии като Kerberos, JWT, LDAP и смарт карти, позволяват изграждането на решения, които работят локално, в облака и в голям мащаб, без да се прави компромис със сигурността.