Eigen TLS, SSH-doorsturing of VPN voor één clouddienst

De vraag is zelden of er iets tussen twee cloudmachines versleuteld moet worden; ze is welk interface je versleutelt en wie wiens identiteit controleert. Ik begin deze gesprekken bij de dienst in plaats van bij het netwerkdiagram, omdat de dienst al weet wat hij nodig heeft. Drie grenzen dekken de meeste gevallen: de eigen TLS van de toepassing, één doorgestuurde TCP-poort via SSH en een gerouteerde overlay die elke deelnemer een adres geeft. Ze zijn niet gerangschikt naar sterkte, maar naar hoeveel van het probleem ze dekken.

Begin bij de dienst, niet bij het netwerk

Ga van het proces naar buiten. Welk protocol spreekt het, welke naam gaat de client controleren en wie mag überhaupt een verbinding openen? Die drie antwoorden sluiten opties sneller uit dan welke vergelijkingstabel dan ook, en de eigen configuratie van de dienst beantwoordt ze meestal binnen een paar minuten.

Neem een kleine interne API die al HTTPS levert op poort 8443 met een certificaat voor api.internal.example. ss -ltnp op de host laat zien waaraan hij bindt, en openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example laat zien of het certificaat geldig is voor de naam die de client echt gebruikt. Als beide gezond zijn, kan de dienst zijn eigen stream beschermen en blijft alleen bereikbaarheid over. Dat is een veel kleiner probleem dan een netwerk bouwen.

Stap 1: beschermt de dienst zichzelf?

Dit is de optie om te kiezen als hij past, en hij past vaker dan teams aannemen. De versleuteling van de dienst dekt het hele pad tussen client en server, inclusief elke sprong ertussen, wat geen tunnel rond het midden verbetert. Stel de verwachte naam en het vertrouwen expliciet in in plaats van te vertrouwen op wat de standaardopslag van de client toevallig bevat.

Versleuteling en bereikbaarheid blijven aparte controles, en het samenvoegen ervan is waar deze optie misgaat. Een TLS-dienst op een onbeperkte openbare listener accepteert nog steeds verbindingspogingen van iedereen, dus de listener en de netwerkregels moeten onafhankelijk van het feit dat de payload beschermd is worden afgebakend. Controleer dan de afhankelijkheden, want een API over TLS zegt niets over het ontdekkingspunt, de beheerpoort of het bulktransportkanaal ernaast. Elk daarvan heeft zijn eigen antwoord nodig, en één onbeschermde broer is genoeg om de hele grens tot fictie te maken.

Stap 2: is één TCP-poort de hele eis?

Als de eis echt één TCP-poort is, is een doorsturing het kleinste dat werkt. Een lokale SSH-doorsturing draagt die poort door een al bestaande geauthenticeerde verbinding.

De vorm is ssh -N -L 8443:127.0.0.1:8443 [email protected], en het detail dat telt is het doeladres: 127.0.0.1 wordt aan de externe kant opgelost, dus de verbinding naar de dienst wordt vanaf de bastion geopend en niet vanaf je laptop. Bind de lokale listener nauw als -L 127.0.0.1:8443:... zodat je de dienst niet per ongeluk op je eigen lokale netwerk publiceert. Beperk aan de serverkant wat het account mag doorsturen in plaats van te vertrouwen op goed gedrag van de client. PermitOpen, AllowTcpForwarding local en een standaard-GatewayPorts no zijn de drie instellingen die een algemene relay in een specifiek kanaal veranderen.

Het contract is smal in beide richtingen. SSH beschermt zijn eigen kanaal, en een verdere sprong van de bastion naar een andere toepassing heeft zijn eigen bescherming nodig. Een dienst die alleen op de loopback van de bastion luistert, heeft een heel andere blootstelling dan een die via een ander netwerk bereikbaar is, en de doorsturing verandert dat niet. Houd de authenticatie en TLS-controles van de toepassing in stand in plaats van de tunnel als hun vervanging te behandelen.

Dit werkt goed voor één verbinding met één eigenaar. Op schaal wordt het een systeem: lokale poortconflicten, toezicht, sleutelrotatie en de vraag wie de doorsturing na een herstart opnieuw start.

Stap 3: is routing de echte eis?

Die lijst is de eerlijke prijs van de kleinste optie, en daarom vervangen teams uiteindelijk een handvol vergeten achtergrondcommando's door iets beheerd. De vervanging is niet automatisch een VPN. Als de eis nog steeds één TCP-poort is, is een bewaakte doorsturing met een gedocumenteerde eigenaar goedkoper te draaien dan een overlay en faalt hij op manieren die je kunt zien. Meet operationeel eigenaarschap voordat je elegantie meet.

Routing wordt het juiste antwoord als routing de eis is. Meerdere toepassingen die gewone IP-connectiviteit nodig hebben, protocollen die een TCP-doorsturing niet kan dragen of diensten die tussen hosts bewegen wijzen allemaal dezelfde kant op.

Een overlay geeft deelnemers een adres en een route, en dan begint het echte werk: niet-overlappende bereiken, route-eigenaarschap, DNS, inschrijving, intrekking en wat er gebeurt als een peer verdwijnt. Niets daarvan komt met het adres mee. Een tot de overlay toegelaten peer is ook niet automatisch geautoriseerd voor elke bewerking op de bestemming, dus authenticatie op dienstniveau blijft.

Wat je daarna bezit

Twee dingen horen in het verslag dat je achterlaat. Het eerste is de identiteit die de client wordt geacht te controleren, want elk van deze grenzen verslechtert stil zodra een naamcontrole wordt versoepeld om iets werkend te krijgen. Het tweede is de verwijderingsstap: welke sleutel, welke regel of welke route verdwijnt als de toegang eindigt, en wie dat uitvoert.

De rondleiding eindigt waar hij begon, bij de dienst. Kies de grens die het werkelijke verkeer dekt en de peers controleert die je wilde controleren, en schrijf dan op hoe toegang wordt bijgewerkt, gemonitord en verwijderd. De OpenSSH-referentie is de plek om de doorsturingsopties te bevestigen voordat je een smal contract belooft. Als je de verwijderingsstap niet in één zin kunt beschrijven, is de grens groter dan het probleem.