Cassandra per VPN: atskira prieiga klientams ir mazgams

Cassandra diegimas neturi vieno universalaus duomenų bazės tinklo. Programos kalba su kliento paslauga, klasterio nariai kalba tarpusavyje, o operatoriai naudoja administravimo sąsajas, ir šios trys auditorijos neturėtų paveldėti viena kitos pasiekiamumo. Privatus kelias, pavyzdžiui, VPN, yra gera pradžia, bet jis nėra duomenų bazės naudotojo tapatybė ir nėra jos šifravimo politika. Traktuokite ryšio sprendimą ir autorizacijos sprendimą kaip dvi atskiras peržiūras.

Kiekviena iš trijų auditorijų gauna savo atsakymą, o toliau esantys skyriai nagrinėja jas pagal poveikio tvarką.

Trys auditorijos, trys sprendimai

Prieš liedami bet kurią taisyklę, nustatykite, ko kiekvienai grupei iš tikrųjų reikia. Klientams reikia kliento klausytuvo ir pakankamai informacijos pasiekti kiekvieną mazgą, kuris jiems gali būti duotas, partneriniams mazgams reikia vienas kito tarp mazgų skirtame prievade, o operatoriams reikia valdymo sąsajos tam, ko iš tikrųjų reikalauja runbook. Trys sąrašai, trys auditorijos, trys pasitikėjimo lygiai.

Dažna klaida – pastatyti vieną plokščią privatų segmentą ir manyti, kad VPN riba padarys likusią dalį. Jo viduje programa, kuri pasiekia kliento prievadą, paprastai pasiekia ir tarp mazgų skirtą prievadą, o operatoriaus administravimo įrankiai dažnai stovi tame pačiame šuolio hoste kaip ir programa. Suplojus tai kartu, pažeista programos tapatybė jau turi didesnį pasiekiamumą nei jos pačios užklausos. Nubrėžkite tris auditorijas kaip tris eilutes projektiniame dokumente, kiekvieną su taisykle, kuri ją leidžia, ir spragos taps matomos anksčiau, nei kas nors jas pastatys.

Ko reikia klientams, ir nieko daugiau

Leiskite numatytiems programos šaltiniams pasiekti kliento galinius taškus įdiegtai versijai ir laikykite nesusijusias klasterio ir valdymo paslaugas už to pasiekiamumo. Tada patikrinkite, kaip tvarkyklė aptinka mazgus. Pasiekiamas pradinis kontaktinis taškas neįrodo, kad kiekvienas mazgo adresas, kurį tvarkyklė vėliau pasirenka, yra pasiekiamas iš to kliento konteksto, nes tvarkyklė klausia klasterio apie partnerius ir tada jungiasi prie adresų, kuriuos klasteris skelbia.

Štai kodėl vienas privataus adreso neatitikimas sukuria pažįstamą modelį: sėkmingas pirmasis ryšys, po kurio seka laiko limitai. Sąmoningai konfigūruokite skelbiamus adresus ir kliento maršrutizavimą; paskelbti visą klasterį internete, kad pataisytumėte vieną neatitikimą, iškeičia maršrutizavimo klaidą į atskleidimą, kurio negalite atšaukti.

Taip pat palikite programos duomenų bazės autentifikaciją ir vaidmenų leidimus. Bendras išverstas VPN adresas gali atstovauti daugeliui naudotojų ar paslaugų, todėl jis niekada nepakeičia atskirų duomenų bazės tapatybių.

Šifruokite atskirai kliento–mazgo ir tarp mazgų ryšį

Apache saugumo dokumentacija kliento–mazgo ir tarp mazgų šifravimą traktuoja kaip atskiras konfigūracijas, ir vienos įjungimas neįjungia kitos. Šis skirtumas galioja ir VPN viduje, nes tunelis saugo savo segmentą ir automatiškai nesiplečia nuo programos proceso iki duomenų bazės proceso ar tarp kiekvienos klasterio narių poros.

Konfigūracija, kuri aiškiai įjungia abi, o ne paveldi šablono numatytąją reikšmę, atrodo maždaug taip:

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

Serverio konfigūracijose, kurios leidžia pasirenkamą kliento šifravimą, TLS priėmimas gali egzistuoti kartu su nešifruotų ryšių priėmimu, todėl skaitykite veiksmingą politiką, o ne ketinimą. Planuokite sertifikatų pavadinimus, pasitikėjimo paskirstymą ir atnaujinimą tiems galiniams taškams, su kuriais kiekvienas klientas iš tikrųjų susisiekia; pakeitus pagrindinio kompiuterio vardą IP adresu, pasikeičia kliento tapatybės patikra, o ne tik jo maršrutas.

Laikykite administravimą atskirame kelyje

Tarp mazgų vykstančiam eismui reikia leidžiamo partnerių rinkinio ir savo apsaugos politikos. Administracinei prieigai, įskaitant JMX ten, kur jis naudojamas, reikia atskiros auditorijos ir savo autentifikacijos. Programa, kuriai leidžiama teikti įprastas užklausas, dėl to neįgyja visų valdymo galimybių, o atvirkščiai yra blogiau: programų segmentui atviras administracinis kelias yra trumpiausias kelias nuo klaidos iki perstatymo. Užrašykite šias dvi auditorijas atskirai ir įvardykite jų savininkus, nes paprastai tai skirtingos komandos, kurių taisyklės buvo netyčia sujungtos.

Laikykite suderintus veiksmingas debesijos taisykles, hosto taisykles ir klausytuvo konfigūraciją. Privatus klausytuvas vis tiek gali būti atviras per netyčinį vertimą ar tarpinį serverį, o plati vieša taisyklė gali tyliai stovėti šalia siauros VPN taisyklės, kol kas nors audituos abi iš karto.

Kai operatoriams tikrai reikia valdymo kelio, duokite jam įvardytą savininką ir trumpesnį kredencialų galiojimo laiką nei programos. Tai išlaiko delegavimą matomą, kai kitas žmogus paveldi klasterį.

Ką žada dizainas

Patikrinkite visus tris pažadus su tikrais vaidmenimis, o ne vien ryšio testais. Patvirtinta programa turėtų atlikti leistą darbą ir nieko daugiau, pašalintas šaltinis turėtų nepraeiti kliento įėjime, o programos tapatybė turėtų būti atmetama rezervuotuose administravimo keliuose. Įtraukite kliento pakartotinį prisijungimą ir mazgo pasirinkimą į tą patį diegimo testą, nes būtent ten išryškėja aptikimo klaidos.

Užbaikite trimis sakiniais projektiniame dokumente: kurie klientai gali užklausti, kurie mazgai gali bendrauti ir kurie operatoriai gali administruoti. Buvimas už VPN yra naudinga topologijos informacija, bet tai nėra atsakymas į nė vieną iš šių trijų klausimų.