Cassandra caur VPN: atsevišķa piekļuve klientiem un mezgliem

Cassandra izvietojumam nav viena universāla datubāzes tīkla. Lietojumprogrammas sarunājas ar klienta servisu, klastera dalībnieki sarunājas savā starpā, un operatori izmanto administratīvās saskarnes, un šīm trim auditorijām nevajadzētu mantot vienai otras sasniedzamību. Privāts ceļš, piemēram, VPN, ir labs sākumpunkts, taču tas nav datubāzes lietotāja identitāte un nav tās šifrēšanas politika. Uztveriet savienojamības lēmumu un autorizācijas lēmumu kā divas atsevišķas pārbaudes.

Katra no trim auditorijām saņem savu atbildi, un turpmākās sadaļas tās aplūko iedarbības secībā.

Trīs auditorijas, trīs lēmumi

Pirms aiztikt kādu noteikumu, nosakiet, kas katrai grupai patiešām nepieciešams. Klientiem nepieciešams klienta klausītājs un pietiekami daudz informācijas, lai sasniegtu katru mezglu, ko tiem var piešķirt, vienādranga mezgliem nepieciešams viens otrs starpmezglu portā, un operatoriem nepieciešama pārvaldības saskarne tam, ko runbook patiešām prasa. Trīs saraksti, trīs auditorijas, trīs uzticības līmeņi.

Biežā kļūda ir uzbūvēt vienu plakanu privātu segmentu un pieņemt, ka VPN robeža paveiks pārējo. Tā iekšienē lietojumprogramma, kas sasniedz klienta portu, parasti sasniedz arī starpmezglu portu, un operatora administratīvie rīki bieži atrodas tajā pašā lēciena hostā kā lietojumprogramma. To visu saplacinot kopā, nozīmē, ka apdraudētai lietojumprogrammas identitātei jau ir lielāks tvērums nekā tās pašas vaicājumiem. Uzzīmējiet trīs auditorijas kā trīs rindas projektēšanas dokumentā, katrai līdzās noteikumu, kas to atļauj, un robi kļūs redzami, pirms kāds tos uzbūvē.

Kas klientiem nepieciešams, un nekas vairāk

Atļaujiet paredzētajiem lietojumprogrammas avotiem sasniegt klienta galapunktus izvietotajai versijai, un turiet nesaistītos klastera un pārvaldības servisus ārpus šī tvēruma. Pēc tam pārbaudiet, kā draiveris atklāj mezglus. Sasniedzams sākotnējais kontakta punkts nepierāda, ka katra mezgla adrese, ko draiveris pēc tam izvēlas, ir sasniedzama no šī klienta konteksta, jo draiveris jautā klasterim par vienādranga mezgliem un pēc tam pieslēdzas adresēm, ko klasteris izziņo.

Tāpēc viena privātās adreses neatbilstība rada pazīstamo modeli: veiksmīgs pirmais savienojums, kam seko taimauti. Apzināti konfigurējiet izziņotās adreses un klienta maršrutēšanu; publicēt visu klasteri internetā, lai salabotu vienu neatbilstību, nozīmē samainīt maršrutēšanas kļūdu pret atklātību, ko nevar atsaukt.

Saglabājiet arī lietojumprogrammas datubāzes autentifikāciju un lomu atļaujas. Koplietota tulkotā VPN adrese var pārstāvēt daudzus lietotājus vai servisus, tāpēc tā nekad neaizstāj atsevišķas datubāzes identitātes.

Šifrējiet atsevišķi klienta–mezgla un starpmezglu savienojumu

Apache drošības dokumentācija klienta–mezgla un starpmezglu šifrēšanu aplūko kā atsevišķas konfigurācijas, un vienas iespējošana neiespējo otru. Šī atšķirība joprojām ir spēkā VPN iekšienē, jo tunelis aizsargā savu segmentu un automātiski neizplešas no lietojumprogrammas procesa līdz datubāzes procesam vai starp katru klastera dalībnieku pāri.

Konfigurācija, kas skaidri iespējo abas, tā vietā, lai mantotu veidnes noklusējumu, izskatās aptuveni šādi:

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

Servera konfigurācijās, kas atļauj neobligātu klienta šifrēšanu, TLS pieņemšana var pastāvēt līdzās nešifrētu savienojumu pieņemšanai, tāpēc lasiet faktisko politiku, nevis nodomu. Plānojiet sertifikātu nosaukumus, uzticības sadali un atjaunošanu tiem galapunktiem, ar kuriem katrs klients patiešām sazinās; hosta nosaukuma aizstāšana ar IP adresi maina klienta identitātes pārbaudi, ne tikai tā maršrutu.

Turiet administrēšanu uz sava ceļa

Starpmezglu trafikam nepieciešama atļautā vienādranga mezglu kopa un sava aizsardzības politika. Administratīvajai piekļuvei, tostarp JMX tur, kur to izmanto, nepieciešama atsevišķa auditorija un sava autentifikācija. Lietojumprogramma, kurai atļauts izdot parastus vaicājumus, tāpēc neiegūst visas pārvaldības iespējas, un pretējais ir sliktāk: lietojumprogrammu segmentam atvērts administratīvais ceļš ir īsākais ceļš no kļūdas līdz pārbūvei. Pierakstiet šīs divas auditorijas atsevišķi un nosauciet to īpašniekus, jo parasti tās ir dažādas komandas, kuru noteikumi nejauši tika apvienoti.

Turiet saskaņotus faktiskos mākoņa noteikumus, hosta noteikumus un klausītāja konfigurāciju. Privāts klausītājs joprojām var būt atvērts, izmantojot nejaušu tulkojumu vai starpniekserveri, un plašs publiskais noteikums var klusi stāvēt līdzās šauram VPN noteikumam, līdz kāds auditē abus vienlaikus.

Kur operatoriem patiešām nepieciešams pārvaldības ceļš, piešķiriet tam nosauktu īpašnieku un īsāku akreditācijas datu mūžu nekā lietojumprogrammai. Tas saglabā deleģējumu redzamu, kad nākamais cilvēks manto klasteri.

Ko dizains sola

Pārbaudiet visus trīs solījumus ar īstām lomām, ne tikai ar savienojamības testiem. Apstiprinātai lietojumprogrammai jāpabeidz atļautais darbs un nekas vairāk, izslēgtam avotam jācieš neveiksme klienta ieejā, un lietojumprogrammas identitātei jātiek atteiktai rezervētajos administratīvajos ceļos. Pievienojiet klienta atkārtotu savienojumu un mezgla izvēli tam pašam ieviešanas testam, jo tieši tur atklājas atklāšanas kļūdas.

Nobeigumā trīs teikumi projektēšanas dokumentā: kuri klienti var vaicāt, kuri mezgli var sazināties un kuri operatori var administrēt. Būšana aiz VPN ir noderīga topoloģijas informācija, taču tā nav atbilde uz kādu no šiem trim jautājumiem.