Versleuteld transport geeft geen toegang tot de provider

Twee goedgekeurde gateways dragen het verkeer van een netwerk met minder vertrouwen over een beperkt transportnetwerk. De payload versleutelen houdt die onleesbaar voor gewone transportwaarnemers, en dat is het deel dat mensen eerst ontwerpen en daarna niet meer over nadenken. Wat versleuteling niet doet, is bepalen welke resources de zijde met minder vertrouwen mag bereiken. Het ontwerp heeft twee grenzen nodig: een rond het vervoerde gesprek en een rond de toegang tot de provider zelf.

Voer de onderstaande stappen in volgorde uit en behandel een fout bij elke stap als een ontwerpwijziging, niet als een configuratieaanpassing.

Bepaal beide grenzen voordat u een configuratie aanraakt

De eerste grens is het gesprek: welke gatewayparen een tunnel mogen opzetten en welk innerlijk verkeer erdoor mag. De tweede is de provider: welke adressen en diensten de hosts met minder vertrouwen buiten de tunnel mogen bereiken. Teams bouwen meestal de eerste en erven de tweede van welke routing dan ook die al bestond, en zo wordt een beperkt ontwerp stil een breed ontwerp. Die erfenis is de gebruikelijke grondoorzaak wanneer een beoordeling een host met minder vertrouwen vindt die praat met iets dat niemand heeft goedgekeurd.

Schrijf beide op als lijsten van adressen, poorten en richtingen. Als een lijst niet kan worden geschreven, is de grens nog niet bepaald.

Stap 1: beperk de buitenste tunnel

Op de interface richting de provider staat u alleen toe wat de tunnel nodig heeft: IKE op UDP 500 en 4500 tussen de twee gateway-adressen, en ESP waar geen NAT-traversal wordt gebruikt. Weiger al het andere dat op die interface aankomt, inclusief beheerprotocollen. De ESP-specificatie dekt de beveiligingsdiensten; hij zegt niets over welke eigen diensten van de provider de gateways mogen gebruiken. Druk dat uit als een expliciete toelatingslijst, zodat een nieuw gepubliceerde providerdienst niet standaard bereikbaar wordt.

Dat is de regelset die het ontwerp een transportontwerp maakt en geen peeringafspraak.

Controleer het vanaf de zijde met minder vertrouwen, niet vanaf de gateway-console. Een host daar zou een DNS-server van de provider niet moeten kunnen bereiken, nog voordat de tunnel staat.

Stap 2: beslis wat de verre gateway levert

Aan de verre kant moet hersteld verkeer naar een specifieke plek. Bepaal welke innerlijke diensten zijn toegestaan, vanuit welke bronbereiken, en of antwoorden symmetrisch worden verwacht. Bekijk beheerstoegang apart, omdat dezelfde gateway vaak een administratieve interface blootlegt die nooit deel uitmaakte van het transportplan.

Een diagram dat stopt bij succesvolle ontsleuteling heeft de beslissing overgeslagen die het meest telt.

Stap 3: behoud eigenaarschap per laag

Transportapparatuur ontvangt en doorstuurt nog steeds buitenste pakketten, dus die heeft patches en capaciteitsplanning nodig. Tunnel-eindpunten verwerken het beschermde protocol en stellen innerlijk verkeer beschikbaar aan hun doorstuurpad, dus die hebben eigen regels en eigen monitoring nodig. Eindtoepassingen verwerken de payload, en een ondoorzichtige payload is geen bewijs dat een ontsleutelde download onschadelijk is.

Wijs elke laag een eigenaar toe. De lagen zonder eigenaar zijn degene die afdrijven.

Stap 4: verifieer en draag het daarna over aan de autoriteit

Verifieer het buitenste pad met de tunnel actief en de providerregels op hun plaats. Probeer vervolgens elke resource die de zijde met minder vertrouwen niet zou moeten bereiken en bevestig dat het falen een weigering is en geen time-out die een route verbergt. Controleer ook beschikbaarheid en resourcelimieten, want een versleutelde verbinding kan nog steeds verzadigd raken.

Voor gereguleerde of gerubriceerde omgevingen brengt u het ontwerp naar de verantwoordelijke beveiligingsautoriteit en gebruikt u de goedgekeurde scheidingsarchitectuur daarvan. Een VPN-configuratie en een conceptuele uitleg vestigen geen accreditatie. Die stap is geen papierwerk; hij bepaalt of het ontwerp überhaupt mag bestaan.