Tarvitsetko vielä sivuston VPN:n, kun sovellus käyttää mTLS:ää ja SSO:ta?
Käy läpi kanavat, joita sovelluksesi kirjautuminen ei koskaan kata, ja päätä sitten, onko yksityisverkon käyttö tarpeetonta vai yhä ainoa reitti isäntään.
Kirjaudut sisään mTLS:llä, hallintapaneeli latautuu, ja väite siitä, että sivuston VPN on nyt tarpeeton, kuulostaa järkevältä suunnilleen niin kauan, kunnes kahdelta yöllä tarvitset tietokannan palautusta. Sovelluksen TLS-raja kuvaa yhtä kanavaa. Isäntä, tietokanta, varmuuskopion kohde ja pilvitili kantavat kukin oman sisääntuloreittinsä, oman identiteettinsä ja oman hyväksyjänsä, eikä yhtäkään niistä harjoiteta onnistuneella kirjautumisella.
Kävele ulospäin kirjautumisnäkymästä
Kirjaudu sisään kuten tavallinen käyttäjä ja kirjoita ylös jokainen hyppy, jota pyyntö koskettaa: selain, reuna, sovelluksen kuuntelija, istuntovarasto, backend-rajapinta. Jokaisella hypyllä on omistaja ja todennusratkaisu. Toista nyt kävely henkilölle, joka paikkaa isäntää, ja työlle, joka kirjoittaa öisen varmuuskopion. Nämä kävelyt eroavat yleensä jo ensimmäisellä hypyllä.
Juuri tämä ero on kysymys, johon kannattaa vastata. Sivuston VPN on tarpeeton vain silloin, kun jokaisella tuon toisen kävelyn kanavalla on omaan varaansa seisova sisääntulo- ja valtuutuspolitiikka.
Viisi kanavaa, joita sovelluksen kirjautuminen ei koskaan kata
Alla oleva taulukko on inventaariomalli, ei käyttöönoton tarkistuslista. Täytä toinen sarake sillä, mitä oma ympäristösi todella valvoo tänään.
| 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 |
Identiteetintarjoajan jakaminen ei yhdistä näitä valtuutuksia. Käyttäjä, joka saa lähettää rajapintapyynnön, ei saa sen perusteella vaihtaa virtuaalikoneen levyä tai palauttaa tietokantaa sovelluksen tunnuksilla. NIST pitää nollaluottamuksen arkkitehtuurin tiivistelmässä resurssien todennuksen ja valtuutuksen verkkosijainnista erillään juuri tästä syystä.
Tukipalveluinsinööri, joka osaa lukea tiketin, ei saa sen perusteella avata konsolia sen takana olevalla isännällä.
Reitti on todellinen vain, jos vaihtoehto pysyy suljettuna
Saavutettavuuden rajaaminen yksityisiin hallinnollisiin kuuntelijoihin on laillinen korvike sivuston VPN:lle, edellyttäen että rajoitus pannaan täytäntöön eikä vain piirretä. Tavallinen epäonnistuminen on vaihtoehtoinen kuuntelija, jota kukaan ei muistanut: palvelu, joka on yhä sidottu kaikkiin rajapintoihin, urakoitsijalle avattu tietoturvaryhmän sääntö, internetistä saavutettava hallintaportti.
Tarkista kuuntelijat, älä kaaviot. Listaa isännällä ss -ltnp:llä, mikä on todella sidottu, ja varmista, että hallintaportit ovat yksityisessä osoitteessa. Lue pilvikonsolissa työkuorman aliverkon saapuvat säännöt ja etsi 0.0.0.0/0 mistä tahansa hallinnollisesta. Kokeile sitten yhteyttä yksityisen reitin ulkopuolelta, koska juuri se koe vastaa kysymykseen.
Yksi koko maailmalle avoin sääntö SSH:ssa kumoaa jokaisen argumentin, jonka tunnelin suunnittelu esitti.
Kirjoita kartta ennen kuin vertailet suunnitelmia
Kirjaa inventaarion jokaiselle riville, kuka hyväksyy identiteetit, kuka päivittää käyttösäännöt, kuka poistaa tunnukset jonkun lähtiessä ja kuka hoitaa palautuksen, kun reitti itse katkeaa. Neljä nimeä riviä kohden riittää paljastamaan rivit, joilla vastaus on jaettu tili ja kolme vuotta vanha wikisivu.
Validoi sitten yksi sallinta ja yksi kielto kanavaa kohden. Sallinta todistaa, että aiottu identiteetti pääsee resurssiin aiotun reitin kautta. Kielto todistaa, että samankaltainen identiteetti ei pääse, ja juuri tämän kokeen ihmiset ohittavat, minkä vuoksi vaihtoehtoiset kuuntelijat selviävät auditoinneista. Vertaa ehdotettua suunnittelua näihin tuloksiin, älä sovelluksen TLS-määritykseen, joka ei koskaan harjoittanut yhtäkään niistä.
Missä sivuston VPN vielä ansaitsee paikkansa
Tunneli tai kapea yhdyskäytävä on oikea vastaus, kun resurssilla ei ole omaa todennusta pyyntöä kohden: tietokantojen ylläpitoportit, varmuuskopioiden kohteet, hypervisor-konsolit, kaistan ulkopuolinen hallinta. Ne kuuntelijat luottavat verkkoon, joten verkon on oltava se, joka todentaa kutsujan.
Se ei ole ainoa vastaus. Yhdyskäytävä, joka päättää valtuutuksen resurssia kohden, voi olla kapeampi kuin koko aliverkon tunneli, ja se jättää paremman auditointijäljen kuin jaettu hyppypalvelin.
Työn järjestys: täydennä inventaario, sulje vaihtoehdot, validoi yksi kielto riviä kohden ja vasta sitten luovu tunnelista. Jos rivi ei pysty tuottamaan kieltoa, pidä yksityinen reitti, kunnes se pystyy.