Yrityksen verkkosovellus VPN:n taakse: siirron käsikirja

Kuvittele muutos käyttäjän näkökulmasta. Joku napsauttaa kirjanmerkkiä, odottaa tuttua kirjautumissivua ja saa sen sijaan yhteysvirheen, koska isäntänimi vastaa nyt vain tunnelin sisällä. Tuo yksi hetki sisältää kaiken, minkä siirtosuunnitelman on onnistuttava tekemään: nimi, polku, varmenne, tili ja sen takana oleva toiminto. Käy alla olevat vaiheet läpi tässä järjestyksessä, niin siirto lakkaa olemasta hyppy.

Vaihe 1: kirjoita ylös, mitä käyttäjät tekevät tänään

Aloita osoiterivin isäntänimestä, portista, ihmisten suorittamista toiminnoista ja käyttämistään tileistä. Jos et osaa nimetä kolmea päätoimintoa, et ole valmis sulkemaan julkista sisäänkäyntiä, koska et tunnista rikkinäistä hyväksynnän aikana.

Päätä sitten, kuka on yksityinen yleisö. Yrityksen VPN:ssä olevat työntekijät ovat alku, eivät vastaus. Urakoitsijat, tukitiimi ja talousosasto voivat kaikki tarvita sovellusta eivätkä ehkä kaikki istu saman yhdyskäytävän takana.

Vaihe 2: erota tunneli kirjautumisesta

Kun käyttäjä saavuttaa sovelluksen VPN:n kautta, selain avaa edelleen TLS-yhteyden sovelluksen omaan päätepisteeseen. Varmenteen on vastattava tuota nimeä, ja sovellus todentaa edelleen tilin. Mikään tunnelissa ei korvaa kumpaakaan.

Tässä siirrot menevät hiljaa pieleen. Joku päättää, ettei yksityinen osoite enää tarvitse kelvollista varmennetta, käyttäjät oppivat napsauttamaan varoituksen läpi, ja organisaatio on vaihtanut julkisen paljastumisen koulutusohjelmaan turvavaroitusten sivuuttamisessa. Jos sovellus todella tarvitsee sisäisen varmenteen, myönnä sellainen sisäiseltä viranomaiselta ja jaa luottamus asianmukaisesti. Se on hallittu muutos; varoitussivu ei ole.

Pidä valtuutus siellä, missä se jo on. NIST:n nollaluottamusarkkitehtuurin tiivistelmä sanoo asian suoraan: verkkosijainti ei ole syy myöntää arkaluontoista toimintoa. Tunnelin sisällä oleminen ei saisi muuttaa vain luku -tiliä järjestelmänvalvojaksi.

Vaihe 3: löydä kutsujat, jotka eivät ole työntekijöitä

Avaa sovelluksen kokoonpano ja luettele kaikki, mikä puhuu sen kanssa: identiteetintarjoajan paluu-URL, maksuntarjoajan webhook, ajastettu tuonti, valvontaluotain, kumppanin API-asiakas. Jokainen on riippuvuus, jolla on omistaja, ja jokainen rikkoutuu eri hetkellä.

Päätä tuettu polku jokaiselle, jonka on jäätävä. Webhook-tarjoaja ei voi liittyä työntekijä-VPN:hen, joten joko paljasta kapeasti rajattu integraatiopäätepiste omalla todennuksellaan tai muuta integraatiomallia. Koko sovelluksen jättäminen julkiseksi yhden paluukutsun vuoksi on valinta, ja yleensä väärä.

Kirjoita jokainen poikkeus muistiin kohteen, sallitun toiminnon, todennuksen ja omistajan kanssa. Integraatiolle annettu yleinen VPN-tili on tapa, jolla poikkeuksesta tulee pysyvä. Käy lista läpi seuraavassa käyttöoikeuskatsauksessa, koska integraatiot elävät pidempään kuin ne lisänneet projektit. Poikkeus ilman vanhenemispäivää on pysyvä suunnittelupäätös, jota kukaan ei tehnyt.

Vaihe 4: poista julkinen reitti, älä vain DNS-tietuetta

Käy julkaisuketju läpi: DNS, kuormantasaajan kuuntelijat, käänteisen välityspalvelimen säännöt, isännän palomuuri ja mikä tahansa vaihtoehtoinen nimi, joka osoittaa yhä vanhaan osoitteeseen. Tarkista molemmat osoiteperheet. Pää-A-tietueen muuttaminen ei todista juuri mitään, jos vanhempi CNAME tai IPv6-kuuntelija palvelee sovellusta edelleen.

Vahvista samanaikaisesti, että yksityinen nimi ratkeaa tunnelin sisällä ja että varmenne kattaa nimen, jonka käyttäjät kirjoittavat. Käyttäjä, jonka täytyy liittää numeerinen osoite, on löytänyt oireen, ei kiertotietä.

Rajaa VPN-yleisö sovelluksen polkuun. Laaja pääsy toimistoverkkoon vaihtaa yhden paljastumispäätöksen suurempaan, ja hallintakäyttöliittymät tarvitsevat omat sallitut lähteensä sen sijaan, että perisivät käyttäjäsäännön.

Vaihe 5: käy hyväksyntä itse läpi

Yhdistä hyväksyttynä käyttäjänä, avaa kirjanmerkki, tarkista varmenne, kirjaudu sisään ja suorita yksi todellinen toiminto. Kokeile sitten tiliä, jolla ei pitäisi olla tuota toimintoa, ja vahvista, että se hylätään. Kokeile sitten laitteesta VPN:n ulkopuolelta ja vahvista, että sovellus on tavoittamattomissa.

Toista jokaisen säilytetyn integraation kohdalla ja lue tarjoajan toimitusloki sen sijaan, että olettaisit oman testityökalusi 200:n olevan sama asia. Onnistunut VPN-kirjautuminen ei ole todiste yhdestäkään näistä tuloksista.

Vaihe 6: harjoittele huono päivä

Päätä, mitä tunnelin katkoksessa tapahtuu: työ pysähtyy tai toinen hyväksytty käyttötapa ottaa vallan. Mitä ikinä valitset, kirjoita se ylös ja testaa kerran, koska hätätilanteen julkinen uudelleenavaus dokumentoimattomana palautumismekanismina tullaan lopulta suorittamaan paineen alla.

Pidä palautumiskäyttöoikeus yhdyskäytävää ja sovellusta ylläpitäville järjestelmänvalvojille, omistajan ja poistopäivän kera. Kirjaa muutos ja sen peruutusehdot samaan paikkaan, jotta epäonnistunut siirto ei lukitse ulos niitä, jotka sen korjaisivat.

Siirron jälkeen paikkaus, tilien elinkaari, sovelluksen valtuutus ja auditointi ovat edelleen sinun. Tunneli kavensi sisäänkäyntiä; se ei ottanut mitään näistä tehtävistä.