Cassandra over VPN: giv klienter og noder hver sin adgang

En Cassandra-udrulning har ikke ét universelt databasenetværk. Applikationer taler med klienttjenesten, klyngemedlemmer taler sammen, og operatører bruger administrative grænseflader, og de tre målgrupper bør ikke arve hinandens rækkevidde. En privat sti som en VPN er et godt udgangspunkt, men den er ikke databasens brugeridentitet, og den er ikke dens krypteringspolitik. Behandl beslutningen om forbindelse og beslutningen om autorisation som to separate gennemgange.

Hver af de tre målgrupper får sit eget svar, og afsnittene nedenfor tager dem i rækkefølge efter eksponering.

Tre målgrupper, tre beslutninger

Find ud af, hvad hver gruppe faktisk har brug for, før du rører en regel. Klienter har brug for klientlytteren og nok information til at nå hver node, de kan få udleveret, peernoder har brug for hinanden på internode-porten, og operatører har brug for administrationsgrænsefladen til det, runbooken faktisk kræver. Tre lister, tre målgrupper, tre tillidsniveauer.

Den almindelige fejl er at bygge ét fladt privat segment og antage, at VPN-grænsen klarer resten. Indeni kan en applikation, der kan nå klientporten, som regel også nå internode-porten, og en operatørs administrative værktøjer sidder ofte på samme jump host som applikationen. At lægge dem sammen betyder, at en kompromitteret applikationsidentitet allerede har større rækkevidde end sine egne forespørgsler. Tegn de tre målgrupper som tre rækker i designdokumentet, hver med den regel, der tillader den, og hullerne bliver synlige, før nogen bygger dem.

Hvad klienter har brug for, og intet mere

Tillad de tilsigtede applikationskilder adgang til klientendepunkterne for den udrullede version, og hold urelaterede klynge- og administrationstjenester uden for den rækkevidde. Kontroller derefter, hvordan driveren opdager noder. Et tilgængeligt indledende kontaktpunkt beviser ikke, at hver nodeadresse, driveren derefter vælger, er tilgængelig fra den klientkontekst, fordi driveren spørger klyngen om peers og derefter forbinder til de adresser, klyngen annoncerer.

Derfor giver én uoverensstemmelse i en privat adresse det velkendte mønster: en vellykket første forbindelse efterfulgt af timeouts. Konfigurer annoncerede adresser og klientrutning bevidst; at offentliggøre hele klyngen på internettet for at rette én uoverensstemmelse bytter en rutningsfejl for en eksponering, du ikke kan tage tilbage.

Behold også applikationens databasegodkendelse og rolle-tilladelser. En delt oversat VPN-adresse kan repræsentere mange brugere eller tjenester, så den er aldrig en erstatning for adskilte databaseidentiteter.

Kryptér klient-til-node og internode hver for sig

Apaches sikkerhedsdokumentation behandler klient-til-node- og internode-kryptering som separate konfigurationer, og at slå den ene til slår ikke den anden til. Den forskel gælder stadig inde i en VPN, fordi tunnelen beskytter sit eget segment og ikke automatisk strækker sig fra applikationsprocessen til databaseprocessen eller mellem hvert par af klyngemedlemmer.

En konfiguration, der slår begge eksplicit til i stedet for at arve en skabelonstandard, ser nogenlunde sådan ud:

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

På serverkonfigurationer, der tillader valgfri klientkryptering, kan accept af TLS sameksistere med accept af ukrypterede forbindelser, så læs den effektive politik frem for hensigten. Planlæg certifikatnavne, tillidsdistribution og fornyelse for de endepunkter, hver klient faktisk kontakter; at erstatte et værtsnavn med en IP-adresse ændrer klientens identitetskontrol, ikke bare dens rute.

Hold administration på sin egen sti

Internode-trafik har brug for det tilladte peer-sæt og sin egen beskyttelsespolitik. Administrativ adgang, inklusive JMX hvor det bruges, har brug for en separat målgruppe og sin egen godkendelse. En applikation, der må udstede almindelige forespørgsler, har ikke dermed brug for enhver administrationsmulighed, og det omvendte er værre: en administrativ sti, der er eksponeret mod applikationssegmentet, er den korteste vej fra en fejl til en genopbygning. Skriv de to målgrupper ned hver for sig, og navngiv deres ejere, fordi det som regel er forskellige teams, hvis regler er blevet sammenlagt ved et uheld.

Hold effektive cloudregler, værtsregler og lytterkonfiguration på linje. En privat lytter kan stadig være eksponeret gennem en utilsigtet oversættelse eller proxy, og en bred offentlig regel kan ligge stille ved siden af en snæver VPN-regel, indtil nogen reviderer begge på én gang.

Hvor operatører virkelig har brug for en administrationssti, giv den en navngivet ejer og en kortere levetid for legitimationsoplysninger end applikationens. Det holder delegationen synlig, når den næste person overtager klyngen.

Hvad designet lover

Validér alle tre løfter med rigtige roller i stedet for kun med forbindelsestests. En godkendt applikation bør fuldføre sit tilladte arbejde og intet mere, en udelukket kilde bør fejle mod klientindgangen, og en applikationsidentitet bør afvises på de reserverede administrationsstier. Tilføj klientgenopkobling og nodevalg til den samme udrulningstest, fordi det er der, opdagelsesfejl kommer frem.

Afslut med tre sætninger i designdokumentet: hvilke klienter kan forespørge, hvilke noder kan kommunikere, og hvilke operatører kan administrere. At være bag en VPN er nyttig topologiinformation, men det er ikke et svar på noget af de tre spørgsmål.