IPsec mellem to værter: hvor beskyttelsen begynder og slutter

Beskyttelse på et værtspar begynder, hvor sikkerhedsassociationen terminerer, og det er den kendsgerning, som intuition formet af gateways oftest overser. En applikationsserver og dens databaseserver kan beskytte deres egen samtale direkte, uden nogen fjernadgangskoncentrator på vejen, og beskyttelsesgrænsen ligger da inde i hver vært i stedet for i en firewall. Det, det køber dig, er dækning fra ende til ende for udvalgte flows. Det, det ikke køber dig, er en beslutning om, hvem der må læse hvilken række.

Grænsen er, hvor SA'en terminerer

RFC 4301 beskriver sikkerhedsassociationer i transporttilstand som den ordning, der typisk bruges mellem et par værter til beskyttelse fra ende til ende. De to værter holder nøglerne, og hver især beslutter, hvilke af dens egne pakker der går ind i associationen. En gatewaytunnel terminerer et helt andet sted og når værten gennem et ekstra internt segment, hvilket er en anden tillidsgrænse, selv når pakken er krypteret i størstedelen af sin rejse.

Vært-til-vært og transporttilstand er dog ikke synonymer. To værter kan lige så rigtigt bygge en association i tunneltilstand mellem sig, så vælg først tilstanden og beskriv derefter endepunkterne. Skriv begge dele i designnotatet ved siden af peer-adresserne, fordi en anmelder, der kun kender tilstanden, vil antage den anden.

SPD'en afgør beskyttelsen, ruten afgør retningen

En routingtabel svarer på, hvor en pakke går hen. Sikkerhedspolitikkens database svarer på, hvordan den udvalgte trafik krydser beskyttelsesgrænsen, og den gør det for hver retning med sine egne selektorer. Den opdeling er grunden til, at en fungerende rute til databasen ikke beviser noget om, hvorvidt anmodningen var beskyttet, og til at en etableret forhandling ikke beviser noget om, hvorvidt netop denne applikation matchede den. Sammenlign selektorerne, før du sammenligner tællerne, da tællerne kun beskriver de flows, der nåede så langt.

På Linux udskriver ip xfrm policy de poster med deres retning, prioritet, selektor og handlingen tillad, bloker eller trap, mens ip xfrm state viser de resulterende associationer og deres tællere. At læse de to sammen er måden, hvorpå du finder det flow, der stille og roligt gik uden om tunnelen, fordi en bredere tilladelsespost matchede først.

Prioritetsrækkefølge er en del af politikken, ikke en implementeringsdetalje. En snæver post, der burde beskytte databaseporten, taber til en bredere post med højere prioritet, og fejlen ser ud, som om politikken aldrig blev konsulteret.

Transporttilstand dækker det næste lag, ikke IP-headeren

I transporttilstand sidder ESP-headeren mellem IP-headeren og nyttelasten, og den headers adressefelter forbliver synlige for enhver enhed på vejen. Det er fint, når adresserne ikke er hemmeligheden, og nyttelasten er. Det er det forkerte valg, hvis du også skal skjule den interne topologi, fordi kun tunneltilstand pakker den oprindelige header ind i en ny.

Begge tilstande kan bære flere protokoller på det næste lag, og ESP beskytter det, selektoren matcher, i stedet for alt, hvad værten sender.

Udvalgelsen er snævrere end forbindelsen

En enkelt association kan bære flere flows, men kun dem, politikken udvælger. Registrer peer-identiteterne, kilde- og destinationsadresserne, protokollen og tjenesteomfanget for det forhold, du påtænker, og beslut derefter særskilt, om ikke-matchende trafik må gå i klartekst, skal beskyttes, eller skal droppes, når associationen ikke er tilgængelig. Den sidste beslutning er den, der giver overraskelser, fordi en regel, der kræver beskyttelse for den forkerte kilde, kan blokere din egen administrationsadgang lige så effektivt, som den blokerer en indtrængende.

Hold en godkendt out-of-band-vej, mens du ændrer håndhævelsen, og test den, før du har brug for den, i stedet for efter at begge værter er blevet uopnåelige.

Maskinidentitet er ikke applikationstilladelse

IPsec autentificerer en konfigureret peer og beskytter udvalgte pakker. Det afgør ikke, hvilken databaserække en person må redigere, og det gør ikke en betroet serveridentitet til en tildeling af enhver applikationsrettighed. Applikationskonti, roller og autorisation bliver præcis, hvor de var, og et TLS-krav på applikationsniveau bevarer sit eget formål, selv når netværksvejen allerede er beskyttet.

Accepter designet med én operation fra den tilsigtede kilde og én, der skal afvises, og medtag, hvad der sker, når den krævede association ikke kan etableres. En almindelig tilgængelighedstest fortæller dig, at pakker bevæger sig; den fortæller dig ikke, at de bevægede sig under den politik, du skrev.