Чаму адзін OTP не можа ахапіць Wi-Fi, VPN і рэестр

Адзіны ўваход абяцае адну асобу і менш запытаў, але абяцанне ламаецца на трэцім пратаколе. Пастка ў тым, каб меркаваць, што адна паспяховая аўтэнтыфікацыя стварае токен, які зможа прадставіць любы іншы пратакол. Доступ да Wi-Fi, уваход у VPN і рэестр кантэйнераў кожны праводзіць розны абмен, з рознымі аўдыторыямі і тэрмінамі. Падзел уліковага запісу — рашэнне каталога; падзел уліковых даных — рашэнне пратакола, а пратаколы рэдка згаджаюцца.

Тры абмены, тры ўладальнікі

Карпаратыўны Wi-Fi запускае метад EAP унутры 802.1X, звычайна з завяршэннем на службе RADIUS, якая мае ўласны погляд на карыстальніка або прыладу. Шлюз VPN аўтэнтыфікуецца праз уласны падтрыманы паток і потым трымае сесію з уласным таймерам паўторнай аўтэнтыфікацыі. Рэестр адказвае на неаўтэнтыфікаваны запыт выклікам, які называе службу токенаў, аўдыторыю і вобласць дзеяння, і кліент абменьвае свае ўліковыя даныя на кароткачасовы токен.

Гэта не тры погляды на адну сесію. Кожны мае ўласны правяральнік, уласны тэрмін і ўласны шлях адклікання, таму змена пароля ў каталозе можа пакінуць адзін працоўным, а другі зламаным. Разглядайце іх як тры інтэграцыі, якія проста дзеляць каталог карыстальнікаў.

Што браўзерны SSO пераносіць, а што не

Браўзерная сесія ў пастаўшчыка ідэнтычнасці сапраўды карысная: праграмы, якія перанакіроўваюць да яго, атрымліваюць ужо завершаны ўваход. Гэта працуе, бо такія праграмы гавораць на тых жа пратаколах перанакіравання і токенаў і прымаюць тую ж аўдыторыю. Запытвальнік, які гаворыць на EAP, не мае перанакіравання, а кліент Docker, што атрымаў выклік рэестра, не просіць токен ідэнтычнасці OIDC. Пастаўшчык ідэнтычнасці можа ручацца толькі за пратаколы, для якіх ён створаны.

Збой лёгка ўбачыць у журналах, калі ведаеш, куды глядзець. Пастаўшчык ідэнтычнасці паведамляе пра паспяховы ўваход, а сувязь з Wi-Fi усё яшчэ не ўсталёўваецца, або рэестр вяртае 401 пасля абмену токена, якога браўзер не бачыў. Два поспехі і адзін збой — не супярэчнасць; гэта тры асобныя аўтэнтыфікацыі.

Дзе сертыфікат замяняе паўтораны код

Для кіраваных прылад EAP на аснове сертыфікатаў прыбірае чалавечы крок, не прыбіраючы ідэнтычнасць: прылада прад'яўляе сертыфікат, служба RADIUS правярае яго ў органе выдачы, і адкліканне адбываецца ў тым органе, а не ў агульным сакрэце. Абмен — праца па жыццёвым цыкле, бо сертыфікаты сканчаюцца і іх трэба абнаўляць да гэтага.

У рэестраў ёсць адпаведнае раздзяленне. Інтэрактыўны карыстальнік можа ўвайсці адзін раз і дазволіць памочніку ўліковых даных захаваць атрыманы токен, а аўтаматызацыя павінна выкарыстоўваць вузка абмежаваныя ўліковыя даныя службы або ідэнтычнасць рабочай нагрузкі. Ні адно з гэтага не павінна быць аднаразовым кодам чалавека, скапіяваным у канвеер. Памочнік захоўвае токен для пэўнай аўдыторыі рэестра, таму яго нельга перанакіраваць на шлюз VPN праз рэдагаванне канфігурацыйнага файла.

docker login registry.example.com

Параўнайце кошт абслугоўвання, а не колькасць запытаў

Агульныя ўліковыя даныя выглядаюць танна, бо праца нябачная, пакуль не зламаецца. Замест гэтага палічыце, колькі кожны варыянт каштуе за год: рэгістрацыя, абнаўленне, адкліканне, радыус уразлівасці ўцечкі і колькасць сістэм, якіх датыкаюцца, калі нехта сыходзіць. Парк сертыфікатаў каштуе больш на пабудову і менш на эксплуатацыю ў маштабе; скапіяваны код не каштуе нічога на старт і ўсё на разблытванне.

Затым выбірайце асобна для кожнага ўчастка, а не глабальна. Wi-Fi можа перайсці на сертыфікаты, VPN можа захаваць падтрыманы SSO з MFA, а рэестр можа выкарыстоўваць токены з яўнымі абсягамі. Запішыце ўладальніка, аўдыторыю, вобласць, тэрмін і шлях адклікання для кожнага, і запыты акажуцца там, дзе трэба, а не ўсюды адразу. Гэты запіс — таксама адказ, калі аўдытар пытае, якія сістэмы ўсё яшчэ давяраюць паролю.