Все още ли ви е нужен VPN за сайта, когато приложението използва mTLS и SSO?
Минете през каналите, които входът в приложението така и не покрива, и решете дали достъпът до частна мрежа е излишен, или все още е единственият път до хоста.
Влизате през mTLS, таблото се зарежда и твърдението, че VPN за сайта вече е излишен, звучи разумно горе-долу толкова дълго, колкото е нужно, за да ви потрябва възстановяване на база данни в два часа през нощта. TLS границата на приложението описва един канал. Хостът, базата данни, целта за резервни копия и облачният акаунт носят всеки свой път за вход, своя идентичност и свой одобряващ, и нито един от тях не се упражнява от успешен вход.
Вървете навън от екрана за вход
Влезте както обикновен потребител и запишете всяка стъпка, която заявката докосва: браузър, ръб, слушател на приложението, хранилище на сесии, backend API. Всяка стъпка има собственик и решение за автентикация. Сега повторeте пътя за човека, който поставя кръпки на хоста, и за задачата, която пише нощното резервно копие. Тези пътища обикновено се разделят още на първата стъпка.
Това разделяне е въпросът, който си струва да бъде отговорен. Тунелът за сайта е излишен само когато всеки канал в това второ пътуване има политика за вход и оторизация, която стои сама.
Пет канала, които входът в приложението така и не покрива
Таблицата по-долу е шаблон за инвентаризация, а не контролен списък за внедряване. Попълнете втората колона с това, което вашата среда действително налага днес.
| 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 конфигурацията на приложението, която никога не е упражнявала нито един от тях.
Къде тунелът за сайта все още заслужава мястото си
Тунел или тесен шлюз е правилният отговор, когато ресурсът няма собствена автентикация за всяка заявка: портове за поддръжка на база данни, цели за резервни копия, конзоли на хипервайзора, извънлентово управление. Тези слушатели се доверяват на мрежата, така че мрежата трябва да е това, което автентикира извикващия.
Това не е единственият отговор. Шлюз, който терминира оторизацията за всеки ресурс, може да е по-тесен от тунел за цялата подмрежа и оставя по-добра одитна следа от споделен междинен хост.
Ред на работа: завършете инвентаризацията, затворете алтернативите, проверете едно отказване на ред и едва след това се откажете от тунела. Ако даден ред не може да даде отказване, пазете частния път, докато може.