Cassandra over VPN: egen tilgang for klienter og noder

En Cassandra-utrulling har ikke ett universelt databasenettverk. Applikasjoner snakker med klienttjenesten, klyngemedlemmer snakker med hverandre, og operatører bruker administrative grensesnitt, og disse tre målgruppene bør ikke arve hverandres rekkevidde. En privat sti som en VPN er et godt utgangspunkt, men den er ikke databasens brukeridentitet og ikke dens krypteringspolicy. Behandle beslutningen om tilkobling og beslutningen om autorisasjon som to separate gjennomganger.

Hver av de tre målgruppene får sitt eget svar, og avsnittene nedenfor tar dem i rekkefølge etter eksponering.

Tre målgrupper, tre beslutninger

Finn ut hva hver gruppe faktisk trenger før du rører en regel. Klienter trenger klientlytteren og nok informasjon til å nå hver node de kan få tildelt, peernoder trenger hverandre på internode-porten, og operatører trenger administrasjonsgrensesnittet for det runbooken faktisk krever. Tre lister, tre målgrupper, tre tillitsnivåer.

Den vanlige feilen er å bygge ett flatt privat segment og anta at VPN-grensen gjør resten. Innenfor kan en applikasjon som når klientporten, som regel også nå internode-porten, og en operatørs administrative verktøy sitter ofte på samme jump host som applikasjonen. Å legge disse sammen betyr at en kompromittert applikasjonsidentitet allerede har større rekkevidde enn sine egne spørringer. Tegn de tre målgruppene som tre rader i designdokumentet, hver med regelen som tillater den, og hullene blir synlige før noen bygger dem.

Hva klienter trenger, og ikke noe mer

Tillat de tiltenkte applikasjonskildene å nå klientendepunktene for den utrullede versjonen, og hold urelaterte klynge- og administrasjonstjenester utenfor den rekkevidden. Kontroller deretter hvordan driveren oppdager noder. Et tilgjengelig innledende kontaktpunkt beviser ikke at hver nodeadresse driveren velger deretter, er tilgjengelig fra den klientkonteksten, fordi driveren spør klyngen om peerer og deretter kobler til adressene klyngen annonserer.

Derfor gir én avvikende privat adresse det velkjente mønsteret: en vellykket første tilkobling etterfulgt av tidsavbrudd. Konfigurer annonserte adresser og klientruting bevisst; å publisere hele klyngen på internett for å rette én avvikende adresse bytter en rutefeil mot en eksponering du ikke kan ta tilbake.

Behold også applikasjonens databaseautentisering og rolletillatelser. En delt oversatt VPN-adresse kan representere mange brukere eller tjenester, så den er aldri en erstatning for adskilte databaseidentiteter.

Krypter klient-til-node og internode hver for seg

Apaches sikkerhetsdokumentasjon behandler klient-til-node- og internode-kryptering som separate konfigurasjoner, og å slå på den ene slår ikke på den andre. Den forskjellen gjelder fortsatt inne i en VPN, fordi tunnelen beskytter sitt eget segment og strekker seg ikke automatisk fra applikasjonsprosessen til databaseprosessen eller mellom hvert par av klyngemedlemmer.

En konfigurasjon som slår på begge eksplisitt, i stedet for å arve en malstandard, ser omtrent slik ut:

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

På serverkonfigurasjoner som tillater valgfri klientkryptering, kan aksept av TLS eksistere sammen med aksept av ukrypterte tilkoblinger, så les den effektive policyen og ikke intensjonen. Planlegg sertifikatnavn, tillitsdistribusjon og fornyelse for endepunktene hver klient faktisk kontakter; å erstatte et vertsnavn med en IP-adresse endrer klientens identitetskontroll, ikke bare ruten.

Hold administrasjonen på sin egen sti

Internode-trafikk trenger det tillatte peersettet og sin egen beskyttelsespolicy. Administrativ tilgang, inkludert JMX der det brukes, trenger en separat målgruppe og sin egen autentisering. En applikasjon som har lov til å sende vanlige spørringer, trenger ikke dermed alle administrasjonsmuligheter, og det motsatte er verre: en administrativ sti som er eksponert mot applikasjonssegmentet, er den korteste veien fra en feil til en gjenoppbygging. Skriv ned de to målgruppene hver for seg, og navngi eierne deres, fordi det vanligvis er forskjellige team hvis regler ble slått sammen ved et uhell.

Hold effektive skyregler, vertsregler og lytterkonfigurasjon på linje. En privat lytter kan fortsatt være eksponert gjennom en utilsiktet oversettelse eller proxy, og en bred offentlig regel kan ligge stille ved siden av en smal VPN-regel til noen reviderer begge samtidig.

Der operatører virkelig trenger en administrasjonssti, gi den en navngitt eier og kortere levetid for legitimasjonen enn applikasjonens. Det holder delegasjonen synlig når neste person overtar klyngen.

Hva designet lover

Valider alle tre løftene med ekte roller i stedet for bare med tilkoblingstester. En godkjent applikasjon bør fullføre sitt tillatte arbeid og ikke noe mer, en utelukket kilde bør feile ved klientinngangen, og en applikasjonsidentitet bør avvises på de reserverte administrasjonsstiene. Legg klientgjenoppkobling og nodevalg til den samme utrullingstesten, fordi det er der oppdagelsesfeil kommer frem.

Avslutt med tre setninger i designdokumentet: hvilke klienter som kan spørre, hvilke noder som kan kommunisere, og hvilke operatører som kan administrere. Å være bak en VPN er nyttig topologiinformasjon, men det er ikke et svar på noen av de tre spørsmålene.