Cassandra over VPN: gescheiden toegang voor clients en nodes

Een Cassandra-implementatie heeft niet één universeel databasenetwerk. Applicaties praten met de clientservice, clustelleden praten met elkaar en beheerders gebruiken administratieve interfaces, en die drie doelgroepen zouden elkaars bereikbaarheid niet moeten overnemen. Een privépad zoals een VPN is een goed uitgangspunt, maar het is niet de gebruikersidentiteit van de database en ook niet het encryptiebeleid ervan. Behandel de connectiviteitsbeslissing en de autorisatiebeslissing als twee afzonderlijke beoordelingen.

Elk van de drie doelgroepen krijgt een eigen antwoord, en de onderstaande secties behandelen ze in volgorde van blootstelling.

Drie doelgroepen, drie beslissingen

Bepaal wat elke groep werkelijk nodig heeft voordat je een regel aanraakt. Clients hebben de clientlistener nodig plus genoeg informatie om elke node te bereiken die ze toegewezen kunnen krijgen, peernodes hebben elkaar nodig op de internode-poort, en beheerders hebben de beheerinterface nodig voor wat de runbook daadwerkelijk vereist. Drie lijsten, drie doelgroepen, drie vertrouwensniveaus.

De gebruikelijke fout is één vlak privésegment bouwen en aannemen dat de VPN-grens de rest doet. Binnen dat segment kan een applicatie die de clientpoort bereikt meestal ook de internode-poort bereiken, en de beheertools van een operator staan vaak op dezelfde jumphost als de applicatie. Die samen afvlakken betekent dat een gecompromitteerde applicatie-identiteit al meer bereik heeft dan haar eigen queries. Teken de drie doelgroepen als drie rijen in het ontwerpdocument, elk met de regel die ze toestaat, en de hiaten worden zichtbaar voordat iemand ze bouwt.

Wat clients nodig hebben, en niets meer

Sta de bedoelde applicatiebronnen toe naar de clienteindpunten van de geïmplementeerde versie, en houd niet-gerelateerde cluster- en beheerdiensten buiten dat bereik. Controleer daarna hoe de driver nodes ontdekt. Een bereikbaar eerste contactpunt bewijst niet dat elk nodeadres dat de driver daarna kiest bereikbaar is vanuit die clientcontext, want de driver vraagt het cluster om peers en verbindt vervolgens met de adressen die het cluster adverteert.

Daarom levert één mismatch in privéadressen het bekende patroon op: een geslaagde eerste verbinding gevolgd door time-outs. Configureer geadverteerde adressen en clientroutering bewust; het hele cluster op internet publiceren om één mismatch te repareren, ruilt een routeringsfout in voor een blootstelling die je niet kunt terugdraaien.

Houd ook de databaseauthenticatie en rolrechten van de applicatie in stand. Een gedeeld vertaald VPN-adres kan voor veel gebruikers of diensten staan, dus het is nooit een vervanging voor afzonderlijke database-identiteiten.

Versleutel client-naar-node en internode afzonderlijk

Apache's beveiligingsdocumentatie behandelt client-naar-node- en internode-versleuteling als afzonderlijke configuraties, en het inschakelen van de ene schakelt de andere niet in. Dat onderscheid geldt nog steeds binnen een VPN, want de tunnel beschermt zijn eigen segment en strekt zich niet automatisch uit van het applicatieproces naar het databaseproces of tussen elk paar clustelleden.

Een configuratie die beide expliciet aanzet, in plaats van een sjabloonstandaard te erven, ziet er ongeveer zo uit:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

Op serverconfiguraties die optionele clientversleuteling toestaan, kan het accepteren van TLS samengaan met het accepteren van onversleutelde verbindingen; lees dus het effectieve beleid en niet de bedoeling. Plan certificaatnamen, vertrouwensdistributie en vernieuwing voor de eindpunten die elke client daadwerkelijk contacteert; een hostnaam vervangen door een IP-adres verandert de identiteitscontrole van de client, niet alleen de route.

Houd beheer op een eigen pad

Internode-verkeer heeft de toegestane peerverzameling en een eigen beschermingsbeleid nodig. Beheertoegang, inclusief JMX waar dat wordt gebruikt, vraagt een aparte doelgroep en eigen authenticatie. Een applicatie die gewone queries mag uitvoeren, heeft daarmee nog niet elke beheermogelijkheid nodig, en het omgekeerde is erger: een beheerpad dat aan het applicatiesegment wordt blootgesteld is de kortste route van een bug naar een herbouw. Schrijf die twee doelgroepen afzonderlijk op en benoem hun eigenaren, want het zijn meestal verschillende teams wier regels per ongeluk zijn samengevoegd.

Houd effectieve cloudregels, hostregels en listenerconfiguratie op één lijn. Een privélistener kan alsnog worden blootgesteld via een onbedoelde vertaling of proxy, en een brede openbare regel kan rustig naast een smalle VPN-regel staan tot iemand beide tegelijk auditeert.

Waar beheerders echt een beheerpad nodig hebben, geef dat een benoemde eigenaar en een kortere levensduur van inloggegevens dan die van de applicatie. Zo blijft de delegatie zichtbaar wanneer de volgende persoon het cluster overneemt.

Wat het ontwerp belooft

Valideer alle drie de beloften met echte rollen in plaats van alleen met connectiviteitstests. Een goedgekeurde applicatie moet haar toegestane werk afronden en niets meer, een uitgesloten bron moet falen op de clienttoegang, en een applicatie-identiteit moet worden geweigerd op de gereserveerde beheerpaden. Voeg cliëntherverbinding en nodeselectie toe aan dezelfde uitroltest, want daar komen ontdekkingsfouten naar boven.

Sluit af met drie zinnen in het ontwerpdocument: welke clients mogen queryen, welke nodes mogen communiceren en welke beheerders mogen beheren. Achter een VPN staan is nuttige topologie-informatie, maar het is geen antwoord op een van die drie vragen.