Cassandra over VPN: skilde tilgangar for klientar og nodar

Ei Cassandra-utrulling har ikkje eitt universelt databasenettverk. Applikasjonar snakkar med klienttenesta, klyngjemedlemmer snakkar med kvarandre, og operatørar nyttar administrative grensesnitt, og desse tre publikuma bør ikkje arve kvarandre sin nåbarheit. Ein privat veg som eit VPN er eit godt utgangspunkt, men han er ikkje brukaridentiteten til databasen og heller ikkje krypteringspolicyen hans. Handsame avgjerda om tilkopling og avgjerda om autorisasjon som to separate vurderingar.

Kvart av dei tre publikuma får sitt eige svar, og avsnitta nedanfor tek dei i rekkjefølgje etter eksponering.

Tre publikum, tre avgjerder

Identifiser kva kvar gruppe faktisk treng før du rører ei regel. Klientar treng klientlyttaren og nok informasjon til å nå kvar node dei kan bli sende til, partnarnodar treng kvarandre på internode-porten, og operatørar treng styregrensesnittet for det runbooken faktisk krev. Tre lister, tre publikum, tre tillitsnivå.

Den vanlege feilen er å byggje eitt flatt privat segment og gå ut frå at VPN-grensa gjer resten. Inne i det kan ein applikasjon som når klientporten, vanlegvis også nå internode-porten, og administratorverktøya til ein operatør sit ofte på same hoppvert som applikasjonen. Å flate desse ut saman betyr at ein kompromittert applikasjonsidentitet allereie har større rekkevidde enn sine eigne spørjingar. Teikn dei tre publikuma som tre rader i designdokumentet, kvar med regelen som tillèt henne, og hola blir synlege før nokon byggjer dei.

Kva klientane treng, og ikkje noko meir

Tillat dei tiltenkte applikasjonskjeldene mot klientendepunkta for den utrulla versjonen, og hald urelaterte klyngje- og styretenester utanfor den rekkevidda. Sjekk så korleis drivaren oppdagar nodar. Eit nåbart første kontaktpunkt viser ikkje at kvar nodeadresse drivaren vel etterpå er nåbar frå den klientkonteksten, for drivaren spør klyngja om partnarar og koplar seg så til dei adressene klyngja annonserer.

Derfor gir ein feil i private adresser det kjende mønsteret med ein vellukka første tilkopling etterfølgd av tidsavbrot. Konfigurer annonserte adresser og klientrutar med vilje; å publisere heile klyngja på internett for å reparere ein feil byter ein rutefeil mot ei eksponering du ikkje kan ta tilbake.

Hald også databaseautentiseringa og rolleløyva til applikasjonen på plass. Ei delt omsett VPN-adresse kan stå for mange brukarar eller tenester, så ho er aldri ein erstatning for særskilde databaseidentitetar.

Krypter klient-til-node og internode kvar for seg

Apache sin sikkerheitsdokumentasjon behandlar klient-til-node- og internode-kryptering som separate konfigurasjonar, og å slå på den eine slår ikkje på den andre. Denne skilnaden gjeld framleis inne i eit VPN, for tunnelen vernar sitt eige segment og strekkjer seg ikkje automatisk frå applikasjonsprosessen til databaseprosessen eller mellom kvart par av klyngjemedlemmer.

Ein konfigurasjon som slår på båe eksplisitt, i staden for å arve ein malstandard, ser omtrent slik ut:

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

På serverkonfigurasjonar som tillèt valfri klientkryptering, kan aksept av TLS leve saman med aksept av ukrypterte tilkoplingar, så les den effektive policyen og ikkje intensjonen. Planlegg sertifikatnamn, tillitsdistribusjon og fornying for endepunkta kvar klient faktisk kontaktar; å byte ut eit vertsnamn med ei IP-adresse endrar identitetssjekken til klienten, ikkje berre ruta.

Hald administrasjon på sin eigen veg

Internode-trafikk treng det tillatne partnarsettet og sin eigen vernepolicy. Administrativ tilgang, inkludert JMX der det blir brukt, treng eit eige publikum og eigen autentisering. Ein applikasjon som får lov til å sende vanlege spørjingar treng ikkje dermed kvar styreevne, og det motsette er verre: ein administrativ veg som er eksponert mot applikasjonssegmentet, er den kortaste vegen frå ein feil til ein ombygging. Skriv dei to publikuma ned kvar for seg, og namngi eigarane deira, for dei er vanlegvis ulike team der reglane har blitt slått saman ved eit uhell.

Hald effektive skyreglar, vertsreglar og lyttarkonfigurasjon på line. Ein privat lyttar kan framleis bli eksponert gjennom ei utilsikta omsetjing eller ein proxy, og ein brei offentleg regel kan sitje stille ved sida av ein trong VPN-regel til nokon reviderer båe samtidig.

Der operatørar verkeleg treng ein administrativ veg, gi han ein namngitt eigar og ei kortare levetid for innloggingsdetaljar enn applikasjonen sin. Det held delegeringa synleg når neste person overtek klyngja.

Kva designet lovar

Valider alle tre løfta med verkelege roller i staden for berre med tilkoplingsprøvar. Ein godkjend applikasjon skal fullføre det tillatne arbeidet sitt og ikkje noko meir, ei utestengd kjelde skal feile mot klientinngangen, og ein applikasjonsidentitet skal bli avvist på dei reserverte administrative vegane. Legg klientgjenoppkopling og nodeval til den same utrullingsprøven, for det er der oppdagingsfeil kjem fram.

Avslutt med tre setningar i designdokumentet: kva klientar som kan spørje, kva nodar som kan kommunisere, og kva operatørar som kan administrere. Å stå bak eit VPN er nyttig topologiinformasjon, men det er ikkje eit svar på noko av dei tre spørsmåla.