A ju duhet ende një VPN sajti kur aplikacioni përdor mTLS dhe SSO?
Kalo nëpër kanalet që identifikimi i aplikacionit tuaj nuk i mbulon kurrë, pastaj vendos nëse aksesi në rrjetin privat është i tepërt apo mbetet rruga e vetme drejt hostit.
Hyni përmes mTLS, paneli ngarkohet dhe pretendimi se VPN-i i sajtit tani është i tepërt tingëllon i arsyeshëm afërsisht aq kohë sa duhet derisa në orën dy të mëngjesit t'ju duhet të riktheni një bazë të dhënash. Kufiri TLS i aplikacionit përshkruan vetëm një kanal. Hosti, baza e të dhënave, caku i kopjeve rezervë dhe llogaria e resë mbajnë secili rrugën e vet të hyrjes, identitetin e vet dhe miratuesin e vet, dhe asnjëri prej tyre nuk ushtrohet nga një identifikim i suksesshëm.
Ecni nga ana e jashtme e ekranit të identifikimit
Hyni siç do të bënte një përdorues i zakonshëm dhe shkruani çdo kërcim që prek kërkesa: shfletuesi, skaji, dëgjuesi i aplikacionit, depoja e sesioneve, API-ja e backend-it. Çdo kërcim ka një pronar dhe një vendim vërtetimi. Tani përsëriteni ecjen për personin që instalon arnime në host dhe për punën që shkruan kopjen rezervë të natës. Ato ecje zakonisht ndahen që në kërcimin e parë.
Pikërisht kjo ndarje është pyetja që meriton përgjigje. Një VPN sajti është i tepërt vetëm kur çdo kanal në atë ecjen e dytë ka një politikë hyrjeje dhe autorizimi që qëndron më vete.
Pesë kanale që identifikimi i aplikacionit nuk i mbulon kurrë
Tabela më poshtë është një model inventari, jo një listë kontrolli për vendosje. Plotësoni kolonën e dytë me atë që mjedisi juaj zbaton vërtet sot.
| 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 |
Ndarja e një ofruesi identiteti nuk i bashkon këto autorizime. Një përdorues që mund të dërgojë një kërkesë API nuk është për këtë arsye i autorizuar të zëvendësojë një disk VM ose të rikthejë një bazë të dhënash me kredencialet e aplikacionit. NIST në përmbledhjen e arkitekturës së besimit zero mban pikërisht për këtë arsye vërtetimin dhe autorizimin e burimeve të ndara nga vendndodhja në rrjet.
Një inxhinier mbështetjeje që mund të lexojë një tiketë nuk është për këtë arsye i autorizuar të hapë një konsolë në hostin pas saj.
Një rrugë është e vërtetë vetëm nëse alternativa mbetet e mbyllur
Kufizimi i arritshmërisë në dëgjues administrativë privatë është një zëvendësim legjitim i një VPN sajti, me kusht që kufizimi të zbatohet dhe jo vetëm të vizatohet. Dështimi i zakonshëm është një dëgjues alternativ që askush nuk e kujtoi: një shërbim ende i lidhur me të gjitha ndërfaqet, një rregull grupi sigurie i hapur për një kontraktor, një port menaxhimi i arritshëm nga interneti.
Kontrolloni dëgjuesit, jo diagramet. Në host, listoni çfarë është vërtet e lidhur me ss -ltnp dhe konfirmoni që portet administrative qëndrojnë në një adresë private. Në konsolën e resë, lexoni rregullat hyrëse për nënrrjetin e ngarkesës së punës dhe kërkoni 0.0.0.0/0 në çdo gjë administrative. Pastaj provoni lidhjen nga jashtë rrugës private, sepse pikërisht ai test i përgjigjet pyetjes.
Një rregull i vetëm i hapur për botën në SSH i anulon të gjitha argumentet që dha projektimi i tunelit.
Shkruani hartën përpara se të krahasoni projektimet
Për çdo rresht të inventarit, shkruani kush miraton identitetet, kush përditëson rregullat e aksesit, kush heq kredencialet kur dikush largohet dhe kush merret me rikuperimin kur vetë rruga prishet. Katër emra për rresht mjaftojnë për të nxjerrë në dritë rreshtat ku përgjigja është një llogari e përbashkët dhe një faqe wiki tre vjeçare.
Pastaj vërtetoni një leje dhe një refuzim për çdo kanal. Leja provon që identiteti i synuar mund të arrijë burimin përmes rrugës së synuar. Refuzimi provon që një identitet i ngjashëm nuk mundet, dhe ky është testi që njerëzit e kapërcejnë, prandaj dëgjuesit alternativë i mbijetojnë auditimeve. Krahasoni projektimin e propozuar me këto rezultate, jo me konfigurimin TLS të aplikacionit, i cili nuk ushtroi kurrë asnjë prej tyre.
Ku një VPN sajti ende e fiton vendin e vet
Një tunel ose një portë e ngushtë është përgjigja e duhur kur një burim nuk ka vërtetim të vetin për çdo kërkesë: portet e mirëmbajtjes së bazave të të dhënave, caket e kopjeve rezervë, konsolat e hipervizorit, menaxhimi jashtë brezit. Ata dëgjues i besojnë rrjetit, prandaj rrjeta duhet të jetë ajo që vërteton thirrësin.
Nuk është përgjigjja e vetme. Një portë që përfundon autorizimin për çdo burim mund të jetë më e ngushtë se një tunel mbi të gjithë nënrrjetin dhe lë një gjurmë auditimi më të mirë se një host kërcimi i përbashkët.
Rendi i punës: përfundoni inventarin, mbyllni alternativat, vërtetoni një refuzim për rresht dhe vetëm atëherë tërhiqni tunelin. Nëse një rresht nuk mund të prodhojë një refuzim, mbani rrugën private derisa të mundet.