Cassandra tra VPN: aparta aliro por klientoj kaj nodoj

Cassandra-instalaĵo ne havas unu universalan datumbazan reton. Aplikaĵoj parolas kun la klientservo, grupanoj parolas unu kun la alia, kaj operatoroj uzas administrajn interfacojn, kaj tiuj tri publikaĵoj ne devus heredi la atingeblon de unu la alia. Privata vojo kiel VPN estas bona komenca punkto, sed ĝi ne estas la uzantidenteco de la datumbazo kaj ĝi ne estas ĝia ĉifrada politiko. Traktu la decidon pri konekteco kaj la decidon pri rajtigo kiel du apartajn reviziojn.

Ĉiu el la tri publikaĵoj ricevas sian propran respondon, kaj la sekcioj sube traktas ilin laŭ ordo de elmetiĝo.

Tri publikaĵoj, tri decidoj

Identigu, kion ĉiu grupo efektive bezonas, antaŭ ol tuŝi regulon. Klientoj bezonas la klientan aŭskultilon kaj sufiĉe da informoj por atingi ĉiun nodon, kiun oni povas doni al ili, samrangaj nodoj bezonas unu la alian sur la internoda pordo, kaj operatoroj bezonas la administran interfacon por tio, kion la runbook efektive postulas. Tri listoj, tri publikaĵoj, tri niveloj da fido.

La ordinara eraro estas konstrui unu ebenan privatan segmenton kaj supozi, ke la VPN-limo faros la reston. Ene de ĝi, aplikaĵo, kiu atingas la klientan pordon, kutime atingas ankaŭ la internodan pordon, kaj la administraj iloj de operatoro ofte sidas sur la sama saltgastigaĵo kiel la aplikaĵo. Ebena kunmetado de ili signifas, ke kompromitita aplikaĵidenteco jam havas pli grandan atingon ol siaj propraj demandoj. Desegnu la tri publikaĵojn kiel tri vicojn en la projekt-dokumento, ĉiun kun la regulo, kiu permesas ĝin, kaj la mankoj fariĝos videblaj antaŭ ol iu ajn konstruos ilin.

Kion klientoj bezonas, kaj nenion pli

Permesu al la celataj aplikaĵfontoj atingi la klientajn finpunktojn por la instalita versio, kaj tenu nerilatajn gruppajn kaj administrajn servojn ekster tiu atingo. Poste kontrolu, kiel la stirilo malkovras nodojn. Atingebla komenca kontakta punkto ne pruvas, ke ĉiu noda adreso, kiun la stirilo poste elektas, estas atingebla el tiu klienta kunteksto, ĉar la stirilo demandas la grupon pri samranguloj kaj poste konektiĝas al ajnaj adresoj, kiujn la grupo anoncas.

Tial unu miskongruo de privata adreso produktas la konatan ŝablonon: sukcesa unua konekto sekvata de tempolimoj. Konfiguru anoncatajn adresojn kaj klientan vojigon konscie; publikigi la tutan grupon en la interreto por ripari unu miskongruon interŝanĝas vojigan cimon kontraŭ elmetiĝo, kiun vi ne povas repreni.

Tenu ankaŭ la datumbazan aŭtentikigon de la aplikaĵo kaj la rolajn permesojn en loko. Komuna tradukita VPN-adreso povas reprezenti multajn uzantojn aŭ servojn, do ĝi neniam anstataŭas apartajn datumbazajn identecojn.

Ĉifru aparte klient-al-nodo kaj internode

La sekureca dokumentaro de Apache traktas klient-al-nodan kaj internodan ĉifradon kiel apartajn agordojn, kaj ŝalti unu ne ŝaltas la alian. Tiu distingo ankoraŭ validas ene de VPN, ĉar la tunelo protektas sian propran segmenton kaj ne etendiĝas aŭtomate de la aplikaĵa procezo al la datumbaza procezo aŭ inter ĉiu paro de grupanaj membroj.

Agordo, kiu ŝaltas ambaŭ eksplicite, anstataŭ heredi ŝablonan defaŭlton, aspektas proksimume jene:

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

Ĉe servilaj agordoj, kiuj permesas laŭvolan klientan ĉifradon, akcepto de TLS povas kunekzisti kun akcepto de neĉifritaj konektoj, do legu la efektivan politikon, ne la intencon. Planu atestilajn nomojn, fidodistribuadon kaj renovigon por la finpunktoj, kiujn ĉiu kliento efektive kontaktas; anstataŭigi gastigantnomon per IP-adreso ŝanĝas la identeckontrolon de la kliento, ne nur ĝian vojon.

Tenu administradon sur sia propra vojo

Internoda trafiko bezonas la permesitan samrangulan aron kaj sian propran protektan politikon. Administra aliro, inkluzive de JMX kie ĝi estas uzata, bezonas apartan publikaĵon kaj sian propran aŭtentikigon. Aplikaĵo rajtigita eldoni ordinarajn demandojn tial ne bezonas ĉiun administran kapablon, kaj la malo estas pli malbona: administra vojo elmetita al la aplikaĵa segmento estas la plej mallonga vojo de cimo al rekonstruo. Skribu tiujn du publikaĵojn aparte, kaj nomu iliajn posedantojn, ĉar ili kutime estas malsamaj teamoj, kies reguloj estis hazarde kunfanditaj.

Tenu efektivajn nubajn regulojn, gastigantajn regulojn kaj aŭskultilan agordon kongruaj. Privata aŭskultilo povas ankoraŭ esti elmetita per neatendita traduko aŭ prokurilo, kaj larĝa publika regulo povas silente sidi apud mallarĝa VPN-regulo, ĝis iu revizios ambaŭ samtempe.

Kie operatoroj vere bezonas administran vojon, donu al ĝi nomitan posedanton kaj pli mallongan vivdaŭron de akreditaĵoj ol tiu de la aplikaĵo. Tio tenas la delegadon videbla, kiam la sekva persono heredas la grupon.

Kion la projekto promesas

Validigu ĉiujn tri promesojn per realaj roloj, ne nur per konektecaj testoj. Aprobita aplikaĵo devus finplenumi sian permesitan laboron kaj nenion pli, ekskludita fonto devus malsukcesi ĉe la klienta enirejo, kaj aplikaĵidenteco devus esti rifuzita sur la rezervitaj administraj vojoj. Aldonu klientan rekonekton kaj nodan elekton al la sama enkonduka testo, ĉar tie la malkovraj eraroj aperas.

Finu per tri frazoj en la projekt-dokumento: kiuj klientoj povas demandi, kiuj nodoj povas komuniki, kaj kiuj operatoroj povas administri. Esti malantaŭ VPN estas utila topologia informo, sed ĝi ne estas respondo al iu ajn el tiuj tri demandoj.