IPsec kahden isännän välillä: mihin suojaus alkaa ja mihin se päättyy

Suojaus isäntäparissa alkaa siitä, mihin tietoturvayhteys päättyy, ja juuri tämän tosiseikan yhdyskäytävämuotoinen intuitio useimmiten ohittaa. Sovelluspalvelin ja sen tietokantapalvelin voivat suojata oman keskustelunsa suoraan, ilman että polulla on yhtään etäkäyttökeskittäjää, ja suojausraja sijaitsee silloin kunkin isännän sisällä eikä palomuurissa. Se, mitä tämä tuo, on päästä päähän -kattavuus valituille virroille. Se, mitä tämä ei tuo, on päätös siitä, kuka saa lukea mitäkin riviä.

Raja on siinä, mihin SA päättyy

RFC 4301 kuvaa siirtotilan tietoturvayhteydet järjestelyksi, jota tavallisesti käytetään isäntäparin välillä päästä päähän -suojaukseen. Nämä kaksi isäntää pitävät avaimet, ja kumpikin päättää, mitkä sen omista paketeista tulevat yhteyteen. Yhdyskäytävätunneli päättyy aivan muualla ja saavuttaa isännän ylimääräisen sisäisen segmentin kautta, mikä on eri luottamusraja, vaikka paketti olisi salattu suurimman osan matkaansa.

Isäntä-isäntä ja siirtotila eivät kuitenkaan ole synonyymejä. Kaksi isäntää voi aivan yhtä oikein rakentaa välilleen tunnelitilan yhteyden, joten valitse ensin tila ja kuvaile sitten päätepisteet. Kirjoita molemmat suunnittelumuistioon vertaisosoitteiden viereen, koska vain tilan tunteva arvioija olettaa toisen.

SPD päättää suojauksesta, reitti päättää suunnasta

Reititystaulu vastaa siihen, minne paketti menee. Tietoturvakäytännön tietokanta vastaa siihen, miten valittu liikenne ylittää suojausrajan, ja se tekee sen suunnittain omilla valitsimillaan. Tämä ero on syy siihen, miksi toimiva reitti tietokantaan ei todista mitään siitä, oliko pyyntö suojattu, ja miksi vakiintunut neuvottelu ei todista mitään siitä, vastasiko juuri tämä sovellus sitä. Vertaa valitsimia ennen kuin vertaat laskureita, koska laskurit kuvaavat vain ne virrat, jotka pääsivät niin pitkälle.

Linuxissa ip xfrm policy tulostaa ne merkinnät suuntineen, prioriteetteineen, valitsimineen ja toimintoineen salli, estä tai ansa, kun taas ip xfrm state näyttää syntyvät yhteydet ja niiden laskurit. Molempien lukeminen yhdessä on tapa löytää se virta, joka hiljaa ohitti tunnelin, koska laajempi salliva merkintä osui ensin.

Prioriteettijärjestys on osa käytäntöä, ei toteutuksen yksityiskohta. Kapea merkintä, jonka pitäisi suojata tietokannan portti, häviää korkeamman prioriteetin laajemmalle merkinnälle, ja vika näyttää siltä, ettei käytäntöä olisi koskaan kysytty.

Siirtotila kattaa seuraavan kerroksen, ei IP-otsaketta

Siirtotilassa ESP-otsake on IP-otsakkeen ja hyötykuorman välissä, ja tuon otsakkeen osoitekentät pysyvät näkyvinä jokaiselle polulla olevalle laitteelle. Se on hyvä silloin, kun osoitteet eivät ole salaisuus ja hyötykuorma on. Se on väärä valinta, jos sinun on myös piilotettava sisäinen topologia, koska vain tunnelitila kääri alkuperäisen otsakkeen uuden sisään.

Molemmat tilat voivat kuljettaa useita seuraavan kerroksen protokollia, ja ESP suojaa sen, mihin valitsin osuu, eikä kaikkea, mitä isäntä lähettää.

Valinta on kapeampi kuin yhteys

Yksi yhteys voi kuljettaa useita virtoja, mutta vain ne, jotka käytäntö valitsee. Kirjaa vertaisidentiteetit, lähde- ja kohdeosoitteet, protokolla ja aiotun suhteen palvelun laajuus, ja päätä sitten erikseen, saako yhteensopimaton liikenne kulkea avoimesti, täytyykö se suojata vai täytyykö se pudottaa, kun yhteys ei ole käytettävissä. Juuri viimeinen päätös tuottaa yllätyksiä, koska väärälle lähteelle suojausta vaativa sääntö voi estää oman hallintayhteytesi yhtä tehokkaasti kuin se estää tunkeilijan.

Pidä hyväksytty kanavan ulkopuolinen reitti, kun muutat valvontaa, ja testaa se ennen kuin tarvitset sitä, etkä vasta sen jälkeen, kun molemmat isännät ovat käymättömissä.

Koneen identiteetti ei ole sovelluksen käyttöoikeus

IPsec todentaa määritetyn vertaisen ja suojaa valitut paketit. Se ei päätä, mitä tietokantatietuetta henkilö saa muokata, eikä se muuta luotettua palvelinidentiteettiä kaikkien sovellusetuoikeuksien myöntämiseksi. Sovellustilit, roolit ja valtuutus pysyvät täsmälleen siellä, missä ne olivat, ja sovellustason TLS-vaatimus säilyttää oman tarkoituksensa, vaikka verkkopolku olisi jo suojattu.

Hyväksy suunnittelu yhdellä toimenpiteellä aiotusta lähteestä ja yhdellä, joka on hylättävä, ja sisällytä mukaan, mitä tapahtuu, kun vaadittua yhteyttä ei voi muodostaa. Tavallinen tavoitettavuustesti kertoo, että paketit liikkuvat; se ei kerro, että ne liikkuivat kirjoittamasi käytännön alaisina.