Cassandra sa ibabaw ng VPN: hiwalay na access para sa mga kliyente at node

Ang isang deployment ng Cassandra ay walang isang pangkalahatang network ng database. Nakikipag-usap ang mga application sa serbisyo ng kliyente, nakikipag-usap ang mga miyembro ng kumpol sa isa't isa, at gumagamit ang mga operator ng mga administratibong interface, at ang tatlong madlang ito ay hindi dapat magmana ng abot ng isa't isa. Ang pribadong landas tulad ng VPN ay mabuting panimulang punto, ngunit hindi ito ang pagkakakilanlan ng gumagamit ng database at hindi rin ang patakaran nito sa pag-encrypt. Tratuhin ang desisyon sa pagkakakonekta at ang desisyon sa awtorisasyon bilang dalawang hiwalay na pagsusuri.

Bawat isa sa tatlong madla ay nakakakuha ng sariling sagot, at tinatalakay sila ng mga seksyon sa ibaba ayon sa pagkakasunod-sunod ng pagkahantad.

Tatlong madla, tatlong desisyon

Tukuyin kung ano talaga ang kailangan ng bawat grupo bago mo hawakan ang isang patakaran. Kailangan ng mga kliyente ang tagapakinig ng kliyente at sapat na impormasyon upang maabot ang bawat node na maaaring ibigay sa kanila, kailangan ng kapwa node ang isa't isa sa port ng internode, at kailangan ng mga operator ang interface ng pamamahala para sa aktwal na hinihingi ng runbook. Tatlong listahan, tatlong madla, tatlong antas ng pagtitiwala.

Ang karaniwang pagkakamali ay bumuo ng isang patag na pribadong segment at ipagpalagay na ang hangganan ng VPN ang gagawa ng iba. Sa loob nito, ang application na umaabot sa port ng kliyente ay karaniwang umaabot din sa port ng internode, at ang mga administratibong kasangkapan ng operator ay madalas na nakaupo sa parehong jump host ng application. Ang pagpapatag sa kanila nang sama-sama ay nangangahulugang ang komprometidong pagkakakilanlan ng application ay mayroon nang mas malaking abot kaysa sa sarili nitong mga query. Iguhit ang tatlong madla bilang tatlong hilera sa dokumento ng disenyo, bawat isa ay may patakarang nagpapahintulot dito, at ang mga puwang ay magiging nakikita bago pa man ito itayo ng sinuman.

Ano ang kailangan ng mga kliyente, at wala nang iba pa

Payagan ang nilalayong mga pinagmulan ng application sa mga endpoint ng kliyente para sa na-deploy na bersyon, at panatilihing labas ng abot na iyon ang mga walang kaugnayang serbisyo ng kumpol at pamamahala. Pagkatapos ay suriin kung paano natutuklasan ng driver ang mga node. Ang isang naaabot na paunang punto ng pakikipag-ugnayan ay hindi nagpapatunay na ang bawat address ng node na pipiliin ng driver pagkatapos ay naaabot mula sa konteksto ng kliyenteng iyon, dahil tinatanong ng driver ang kumpol tungkol sa mga kapwa node at pagkatapos ay kumokonekta sa mga address na inaanunsyo ng kumpol.

Iyon ang dahilan kung bakit ang isang hindi pagtutugma ng pribadong address ay gumagawa ng pamilyar na pattern: isang matagumpay na unang koneksyon na sinusundan ng mga timeout. Sadyang i-configure ang mga inaanunsyo na address at ang routing ng kliyente, ang paglalathala ng buong kumpol sa internet upang ayusin ang isang hindi pagtutugma ay nagpapalit ng bug sa routing para sa isang pagkahantad na hindi mo na maibabalik.

Panatilihin din ang pagpapatunay ng database at mga pahintulot sa papel ng application. Ang isang nakabahaging isinalin na address ng VPN ay maaaring kumatawan sa maraming gumagamit o serbisyo, kaya hindi ito kailanman kapalit ng magkakahiwalay na pagkakakilanlan ng database.

I-encrypt nang hiwalay ang kliyente-sa-node at internode

Ang dokumentasyon ng seguridad ng Apache ay itinuturing ang pag-encrypt ng kliyente-sa-node at internode bilang magkakahiwalay na configuration, at ang pagpapagana ng isa ay hindi nagpapagana ng isa pa. Nalalapat pa rin ang pagkakaibang iyon sa loob ng VPN, dahil pinoprotektahan ng tunnel ang sarili nitong segment at hindi ito awtomatikong umaabot mula sa proseso ng application hanggang sa proseso ng database o sa pagitan ng bawat pares ng mga miyembro ng kumpol.

Ang isang configuration na tahasang nagpapagana sa dalawa, sa halip na magmana ng default ng template, ay mukhang ganito:

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

Sa mga configuration ng server na nagpapahintulot ng opsyonal na pag-encrypt ng kliyente, ang pagtanggap ng TLS ay maaaring mabuhay kasama ng pagtanggap ng mga koneksyon na hindi naka-encrypt, kaya basahin ang epektibong patakaran at hindi ang layunin. Planuhin ang mga pangalan ng sertipiko, pamamahagi ng pagtitiwala at pag-renew para sa mga endpoint na aktwal na kinokontak ng bawat kliyente; ang pagpapalit ng hostname ng isang address ng IP ay nagbabago sa pagsusuri ng pagkakakilanlan ng kliyente, hindi lamang sa ruta nito.

Panatilihin ang administrasyon sa sarili nitong landas

Kailangan ng trapiko ng internode ang pinahihintulutang set ng kapwa node at sarili nitong patakaran sa proteksyon. Ang administratibong access, kabilang ang JMX kung saan ito ginagamit, ay nangangailangan ng hiwalay na madla at sariling pagpapatunay. Ang isang application na pinahihintulutang maglabas ng ordinaryong query ay hindi dahil dito nangangailangan ng bawat kakayahan sa pamamahala, at ang kabaligtaran ay mas masama: ang administratibong landas na inilantad sa segment ng application ay ang pinakamaikling ruta mula sa isang bug hanggang sa muling pagtatayo. Isulat nang hiwalay ang dalawang madlang iyon at pangalanan ang kanilang mga may-ari, dahil kadalasan sila ay magkaibang koponan na ang mga patakaran ay aksidenteng pinagsama.

Panatilihing pantay ang epektibong mga patakaran ng cloud, mga patakaran ng host at configuration ng tagapakinig. Ang isang pribadong tagapakinig ay maaari pa ring mailantad sa pamamagitan ng hindi sinasadyang pagsasalin o proxy, at ang isang malawak na pampublikong patakaran ay maaaring tahimik na nakaupo sa tabi ng makitid na patakaran ng VPN hanggang sa may mag-audit sa dalawa nang sabay.

Kung saan talagang kailangan ng mga operator ng landas ng pamamahala, bigyan ito ng pinangalanang may-ari at mas maikling buhay ng kredensyal kaysa sa application. Pinapanatili nitong nakikita ang delegasyon kapag namana ng susunod na tao ang kumpol.

Ano ang ipinapangako ng disenyo

Patunayan ang lahat ng tatlong pangako gamit ang tunay na mga papel at hindi lamang mga pagsubok sa pagkakakonekta. Dapat tapusin ng isang aprubadong application ang pinahihintulutang gawain nito at wala nang iba pa, dapat mabigo ang isang ibinukod na pinagmulan sa pasukan ng kliyente, at dapat tanggihan ang pagkakakilanlan ng application sa mga nakalaang administratibong landas. Idagdag ang muling pagkonekta ng kliyente at pagpili ng node sa parehong pagsubok ng rollout, dahil doon lumilitaw ang mga pagkakamali sa pagtuklas.

Tapusin sa tatlong pangungusap sa dokumento ng disenyo: aling mga kliyente ang maaaring mag-query, aling mga node ang maaaring makipag-usap, at aling mga operator ang maaaring mag-administre. Ang pagiging nasa likod ng VPN ay kapaki-pakinabang na impormasyon ng topolohiya, ngunit hindi ito sagot sa alinman sa tatlong tanong na iyon.