Cassandra över VPN: separat åtkomst för klienter och noder

En Cassandra-distribution har inte ett enda universellt databasnätverk. Applikationer pratar med klienttjänsten, klustermedlemmar pratar med varandra och operatörer använder administrativa gränssnitt, och dessa tre målgrupper bör inte ärva varandras nåbarhet. En privat väg som ett VPN är en bra utgångspunkt, men den är inte databasens användaridentitet och inte heller dess krypteringspolicy. Behandla beslutet om anslutning och beslutet om auktorisering som två separata granskningar.

Var och en av de tre målgrupperna får sitt eget svar, och avsnitten nedan tar dem i ordning efter exponering.

Tre målgrupper, tre beslut

Identifiera vad varje grupp faktiskt behöver innan du rör en regel. Klienter behöver klientslyssnaren och tillräckligt med information för att nå varje nod de kan bli tilldelade, partnernoder behöver varandra på internode-porten, och operatörer behöver administrationsgränssnittet för det runbooken faktiskt kräver. Tre listor, tre målgrupper, tre förtroendenivåer.

Det vanliga misstaget är att bygga ett enda platt privat segment och anta att VPN-gränsen gör resten. Inuti det kan en applikation som når klientporten oftast också nå internode-porten, och en operatörs administrativa verktyg sitter ofta på samma hoppvärd som applikationen. Att platta till dem tillsammans innebär att en komprometterad applikationsidentitet redan har större räckvidd än sina egna frågor. Rita de tre målgrupperna som tre rader i designdokumentet, varje rad med regeln som tillåter den, och luckorna blir synliga innan någon bygger dem.

Vad klienterna behöver, och inget mer

Tillåt de avsedda applikationskällorna mot klientändpunkterna för den driftsatta versionen, och håll orelaterade kluster- och administrationstjänster utanför den räckvidden. Kontrollera sedan hur drivrutinen upptäcker noder. En nåbar första kontaktpunkt bevisar inte att varje nodadress drivrutinen väljer därefter är nåbar från den klientkontexten, eftersom drivrutinen frågar klustret efter partner och sedan ansluter till de adresser klustret annonserar.

Därför ger en enda felaktig privat adress det välbekanta mönstret: en lyckad första anslutning följd av tidsgränser. Konfigurera annonserade adresser och klientroutning medvetet; att publicera hela klustret på internet för att reparera en felaktighet byter en routningsbugg mot en exponering du inte kan ta tillbaka.

Behåll även applikationens databasautentisering och rollbehörigheter. En delad översatt VPN-adress kan stå för många användare eller tjänster, så den ersätter aldrig separata databasidentiteter.

Kryptera klient-till-nod och internode separat

Apaches säkerhetsdokumentation behandlar klient-till-nod- och internode-kryptering som separata konfigurationer, och att aktivera den ena aktiverar inte den andra. Den skillnaden gäller fortfarande inne i ett VPN, eftersom tunneln skyddar sitt eget segment och inte automatiskt sträcker sig från applikationsprocessen till databasprocessen eller mellan varje par av klustermedlemmar.

En konfiguration som slår på båda uttryckligen, i stället för att ärva en mallstandard, ser ungefär ut så här:

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

På serverkonfigurationer som tillåter valfri klientkryptering kan accepterandet av TLS samexistera med accepterandet av okrypterade anslutningar, så läs den effektiva policyn och inte avsikten. Planera certifikatnamn, förtroendedistribution och förnyelse för de ändpunkter varje klient faktiskt kontaktar; att ersätta ett värdnamn med en IP-adress ändrar klientens identitetskontroll, inte bara dess rutt.

Håll administrationen på sin egen väg

Internode-trafik behöver den tillåtna partnermängden och sin egen skyddspolicy. Administrativ åtkomst, inklusive JMX där det används, behöver en separat målgrupp och sin egen autentisering. En applikation som tillåts skicka vanliga frågor behöver inte därför varje administrationsförmåga, och det omvända är värre: en administrativ väg som exponeras mot applikationssegmentet är den kortaste vägen från en bugg till en ombyggnad. Skriv ner de två målgrupperna separat och namnge deras ägare, eftersom det oftast är olika team vars regler har slagits ihop av misstag.

Håll effektiva molnregler, värdregler och lyssnarkonfiguration i linje. En privat lyssnare kan fortfarande exponeras genom en oavsiktlig översättning eller proxy, och en bred offentlig regel kan ligga tyst bredvid en smal VPN-regel tills någon granskar båda samtidigt.

Där operatörer verkligen behöver en administrationsväg ska den ha en namngiven ägare och kortare livstid för autentiseringsuppgifter än applikationens. Det håller delegeringen synlig när nästa person ärver klustret.

Vad designen lovar

Validera alla tre löftena med riktiga roller i stället för bara med anslutningstester. En godkänd applikation ska slutföra sitt tillåtna arbete och inget mer, en utesluten källa ska misslyckas mot klientens ingång, och en applikationsidentitet ska avvisas på de reserverade administrativa vägarna. Lägg till klientens återanslutning och nodval i samma driftsättningstest, för det är där upptäcktsfel visar sig.

Avsluta med tre meningar i designdokumentet: vilka klienter som kan fråga, vilka noder som kan kommunicera och vilka operatörer som kan administrera. Att stå bakom ett VPN är användbar topologiinformation, men det är inte ett svar på någon av de tre frågorna.