Cassandra oor VPN: gee kliënte en nodusse afsonderlike toegang

'n Cassandra-ontplooiing het nie een universele databasenetwerk nie. Toepassings praat met die kliëntdiens, groeplede praat met mekaar, en operateurs gebruik administratiewe koppelvlakke, en daardie drie gehore behoort nie mekaar se bereikbaarheid te erf nie. 'n Privaat pad soos 'n VPN is 'n goeie beginpunt, maar dit is nie die databasis se gebruikersidentiteit nie en dit is nie sy enkripsiebeleid nie. Behandel die verbindingsbesluit en die magtigingsbesluit as twee afsonderlike hersienings.

Elkeen van die drie gehore kry sy eie antwoord, en die afdelings hieronder hanteer hulle in volgorde van blootstelling.

Drie gehore, drie besluite

Identifiseer wat elke groep werklik nodig het voordat jy aan 'n reël raak. Kliënte het die kliënt-luisteraar nodig en genoeg inligting om elke nodus te bereik wat hulle moontlik kry, eweknie-nodusse het mekaar op die internodus-poort nodig, en operateurs het die bestuurskoppelvlak nodig vir wat die runbook werklik vereis. Drie lyste, drie gehore, drie vlakke van vertroue.

Die algemene fout is om een plat privaat segment te bou en te aanvaar die VPN-grens doen die res. Binne dit kan 'n toepassing wat die kliëntpoort kan bereik gewoonlik ook die internodus-poort bereik, en 'n operateur se administratiewe gereedskap sit dikwels op dieselfde spronggasheer as die toepassing. Om dit saam te plat maak beteken 'n gekompromitteerde toepassingsidentiteit het reeds meer bereik as sy eie navrae. Teken die drie gehore as drie rye in die ontwerpdocument, elkeen met die reël wat dit toelaat, en die gapings word sigbaar voordat iemand dit bou.

Wat kliënte nodig het, en niks meer nie

Laat die beoogde toepassingsbronne na die kliënt-eindpunte toe vir die ontplooide weergawe, en hou onverwante groepering- en bestuursdienste buite daardie bereik. Kyk dan hoe die drywer nodusse ontdek. 'n Bereikbare aanvanklike kontakpunt bewys nie dat elke nodusadres wat die drywer daarna kies, vanuit daardie kliëntkonteks bereikbaar is nie, want die drywer vra die groepering vir eweknieë en verbind dan na watter adresse die groepering ook al adverteer.

Dit is hoekom een privaatadres-wanverhouding die bekende patroon lewer: 'n suksesvolle eerste verbinding gevolg deur tydverstrykings. Stel geadverteerde adresse en kliëntroetering doelbewus op; om die hele groepering aan die internet te publiseer om een wanverhouding te herstel verruil 'n roeteringsfout vir 'n blootstelling wat jy nie kan terugneem nie.

Hou ook die toepassing se databasemagtiging en roltoestemmings in plek. 'n Gedeelde vertaalde VPN-adres kan vir baie gebruikers of dienste staan, so dit is nooit 'n plaasvervanger vir afsonderlike databasisidentiteite nie.

Enkripteer kliënt-tot-nodus en internodus afsonderlik

Apache se sekuriteitsdokumentasie behandel kliënt-tot-nodus- en internodus-enkripsie as afsonderlike konfigurasies, en om een te aktiveer aktiveer nie die ander nie. Daardie onderskeid geld steeds binne 'n VPN, want die tonnel beskerm sy eie segment en strek nie outomaties van die toepassingsproses na die databasisproses of tussen elke paar groeplede nie.

'n Konfigurasie wat albei eksplisiet aanskakel, eerder as om 'n sjabloonverstek te erf, lyk ongeveer so:

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

Op bedienerkonfigurasies wat opsionele kliënt-enkripsie toelaat, kan die aanvaarding van TLS saambestaan met die aanvaarding van onenkripteerde verbindings, so lees die effektiewe beleid eerder as die bedoeling. Beplan sertifikaatname, vertrouensverspreiding en hernuwing vir die eindpunte wat elke kliënt werklik kontak; om 'n gasheernaam met 'n IP-adres te vervang verander die kliënt se identiteitskontrole, nie net sy roete nie.

Hou administrasie op sy eie pad

Internodus-verkeer het die toegelate eweknie-versameling en sy eie beskermingsbeleid nodig. Administratiewe toegang, insluitend JMX waar dit gebruik word, het 'n afsonderlike gehoor en sy eie magtiging nodig. 'n Toepassing wat toegelaat word om gewone navrae te doen, het nie daardeur elke bestuursvermoë nodig nie, en die omgekeerde is erger: 'n administratiewe pad wat aan die toepassingsegment blootgestel is, is die kortste roete van 'n fout na 'n herbou. Skryf daardie twee gehore afsonderlik neer, en noem hulle eienaars, want dit is gewoonlik verskillende spanne wie se reëls per ongeluk saamgesmelt het.

Hou effektiewe wolkreëls, gasheerreëls en luisteraarkonfigurasie in lyn. 'n Privaat luisteraar kan steeds deur 'n onbedoelde vertaling of instaanbediener blootgestel word, en 'n breë openbare reël kan stilweg langs 'n nou VPN-reël sit tot iemand albei gelyktydig oudit.

Waar operateurs werklik 'n bestuurspad nodig het, gee dit 'n genoemde eienaar en 'n korter geloofsbriewe-leeftyd as die toepassing s'n. Dit hou die delegering sigbaar wanneer die volgende persoon die groepering erf.

Wat die ontwerp belowe

Valideer al drie beloftes met werklike rolle eerder as met verbindingstoetse alleen. 'n Goedgekeurde toepassing behoort sy toegelate werk te voltooi en niks meer nie, 'n uitgeslote bron behoort teen die kliënt-ingang te misluk, en 'n toepassingsidentiteit behoort op die gereserveerde administrasiepaaie geweier te word. Voeg kliënt-herverbinding en noduskeuse by dieselfde ontplooiingstoets, want dit is waar ontdekkingsfoute opduik.

Sluit af met drie sinne in die ontwerpdocument: watter kliënte kan navraag doen, watter nodusse kan kommunikeer, en watter operateurs kan administreer. Om agter 'n VPN te wees is nuttige topologie-inligting, maar dit is nie 'n antwoord op enige van daardie drie vrae nie.