Ці патрэбны яшчэ VPN сайта, калі праграма выкарыстоўвае mTLS і SSO?
Прайдзіце каналы, якія ўваход у праграму ніколі не пакрывае, і вырашыце, ці доступ да прыватнай сеткі лішні, ці ўсё яшчэ адзіны шлях да хоста.
Вы ўваходзіце праз mTLS, панэль кіравання загружаецца, і сцвярджэнне, што VPN сайта цяпер лішні, гучыць разумна прыкладна столькі, колькі спатрэбіцца, каб а другой гадзіне ночы аднаўляць базу даных. Мяжа TLS праграмы апісвае адзін канал. Хост, база даных, мэта рэзервовага капіявання і хмарны ўліковы запіс маюць кожны свой шлях уваходу, сваю ідэнтычнасць і свайго асобу, якая ўхваляе, і ніводзін з іх не правяраецца паспяховым уваходам.
Ідзіце вонкі ад экрана ўваходу
Увайдзіце так, як звычайны карыстальнік, і запішыце кожны крок, якога датыкаецца запыт: браўзер, ускраіна, слухач праграмы, сховішча сеансаў, backend API. Кожны крок мае ўласніка і рашэнне аб аўтэнтыфікацыі. Цяпер паўтарыце шлях для чалавека, які ўсталёўвае латкі на хост, і для задачы, якая піша начны рэзервовы капія. Гэтыя шляхі звычайна разыходзяцца ўжо на першым кроку.
Гэтае разыходжанне і ёсць пытанне, на якое варта адказаць. Тунэль сайта лішні толькі тады, калі кожны канал у гэтым другім шляху мае ўласную палітыку ўваходу і аўтарызацыі, якая стаіць сама па сабе.
Пяць каналаў, якія ўваход у праграму ніколі не пакрывае
Табліца ніжэй — гэта шаблон інвентарызацыі, а не кантрольны спіс разгортвання. Запоўніце другі слупок тым, што ваша асяроддзе фактычна прытрымліваецца сёння.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Агульны пастаўшчык ідэнтычнасці не аб'ядноўвае гэтыя аўтарызацыі. Карыстальнік, якому дазволена адправіць запыт API, не атрымлівае тым самым права замяніць дыск ВМ або аднавіць базу даных з дапамогай уліковых даных праграмы. NIST у аглядзе архітэктуры нулявога даверу менавіта таму трымае аўтэнтыфікацыю і аўтарызацыю рэсурсаў асобна ад сеткавага размяшчэння.
Інжынер падтрымкі, які можа прачытаць тыкет, не атрымлівае тым самым права адкрыць кансоль на хосце за ім.
Шлях рэальны, толькі калі альтэрнатыва застаецца закрытай
Абмежаванне дасяжнасці прыватнымі адміністрацыйнымі слухачамі — законная замена тунэлю сайта, пры ўмове, што абмежаванне выконваецца, а не проста намалявана. Звычайная няўдача — альтэрнатыўны слухач, пра які ніхто не ўспомніў: сэрвіс, які ўсё яшчэ прывязаны да ўсіх інтэрфейсаў, правіла групы бяспекі, адкрытае для падрадчыка, порт кіравання, дасяжны з інтэрнэту.
Правярайце слухачы, а не дыяграмы. На хосце пералічыце, што фактычна прывязана, з дапамогай ss -ltnp і пацвердзіце, што адміністрацыйныя парты знаходзяцца на прыватным адрасе. У хмарнай кансолі прачытайце правілы ўваходняга трафіку для падсеткі працоўнай нагрузкі і пашукайце 0.0.0.0/0 на чым-небудзь адміністрацыйным. Затым паспрабуйце злучэнне звонку ад прыватнага шляху, бо менавіта гэты тэст адказвае на пытанне.
Адно адкрытае для ўсяго свету правіла на SSH адмяняе ўсе аргументы дызайну тунэлю.
Напішыце карту, перш чым параўноўваць дызайны
Для кожнага радка інвентарызацыі запішыце, хто ўхваляе ідэнтычнасці, хто абнаўляе правілы доступу, хто выдаляе ўліковыя даныя, калі хтосьці сыходзіць, і хто займаецца аднаўленнем, калі сам шлях ламаецца. Чатырох імёнаў на радок дастаткова, каб выкрыць радкі, дзе адказ — агульны ўліковы запіс і вікі-старонка трохгадовай даўніны.
Затым праверце адзін дазвол і адну адмову на кожны канал. Дазвол даказвае, што патрэбная ідэнтычнасць можа дасягнуць рэсурсу патрэбным шляхам. Адмова даказвае, што падобная ідэнтычнасць не можа, і менавіта гэты тэст людзі прапускаюць, таму альтэрнатыўныя слухачы і перажываюць аўдыты. Параўнайце прапанаваны дызайн з гэтымі вынікамі, а не з канфігурацыяй TLS праграмы, якая ніколі нічога з іх не правярала.
Дзе тунэль сайта ўсё яшчэ апраўданы
Тунэль або вузкі шлюз — правільны адказ, калі рэсурс не мае ўласнай аўтэнтыфікацыі на кожны запыт: парты абслугоўвання базы даных, мэты рэзервовых копій, кансолі гіпервізара, пазапалоснае кіраванне. Гэтыя слухачы давяраюць сетцы, таму менавіта сетка павінна аўтэнтыфікаваць таго, хто звяртаецца.
Гэта не адзіны адказ. Шлюз, які завяршае аўтарызацыю для кожнага рэсурсу, можа быць вужэйшы за тунэль на ўсю падсетку і пакідае лепшы след аўдыту, чым агульны прамежкавы хост.
Парадак працы: завяршыце інвентарызацыю, зачыніце альтэрнатывы, праверце адну адмову на радок і толькі пасля гэтага адмаўляйцеся ад тунэлю. Калі радок не можа даць адмову, трымайце прыватны шлях, пакуль не зможа.