VPN પર Cassandra: ક્લાયન્ટ અને નોડ માટે અલગ એક્સેસ

Cassandra ડિપ્લોયમેન્ટમાં એક સર્વસામાન્ય ડેટાબેઝ નેટવર્ક હોતું નથી. એપ્લિકેશનો ક્લાયન્ટ સેવા સાથે વાત કરે છે, ક્લસ્ટરના સભ્યો એકબીજા સાથે વાત કરે છે, અને ઓપરેટરો વહીવટી ઇન્ટરફેસ વાપરે છે, અને આ ત્રણ જૂથોએ એકબીજાની પહોંચ વારસામાં ન લેવી જોઈએ. VPN જેવો ખાનગી માર્ગ સારો પ્રારંભિક બિંદુ છે, પણ તે ડેટાબેઝની વપરાશકર્તા ઓળખ નથી અને તેની એન્ક્રિપ્શન નીતિ નથી. કનેક્ટિવિટીના નિર્ણય અને અધિકૃતિના નિર્ણયને બે અલગ સમીક્ષા તરીકે ગણો.

ત્રણમાંથી દરેક જૂથને પોતાનો જવાબ મળે છે, અને નીચેના વિભાગો તેમને જોખમના ક્રમમાં લે છે.

ત્રણ જૂથ, ત્રણ નિર્ણય

કોઈ નિયમને અડકતા પહેલાં દરેક જૂથને ખરેખર શું જોઈએ છે તે ઓળખો. ક્લાયન્ટને ક્લાયન્ટ શ્રોતા અને તેમને મળી શકે તેવા દરેક નોડ સુધી પહોંચવા માટે પૂરતી માહિતી જોઈએ, પીઅર નોડને આંતર-નોડ પોર્ટ પર એકબીજાની જરૂર હોય છે, અને ઓપરેટરને રનબુક ખરેખર જે માંગે છે તેના માટે મેનેજમેન્ટ ઇન્ટરફેસ જોઈએ. ત્રણ યાદી, ત્રણ જૂથ, વિશ્વાસના ત્રણ સ્તર.

સામાન્ય ભૂલ એ છે કે એક સપાટ ખાનગી સેગમેન્ટ બનાવીને ધારી લેવું કે VPN સીમા બાકીનું કરી દેશે. તેની અંદર, ક્લાયન્ટ પોર્ટ સુધી પહોંચતી એપ્લિકેશન સામાન્ય રીતે આંતર-નોડ પોર્ટ સુધી પણ પહોંચે છે, અને ઓપરેટરનાં વહીવટી સાધનો ઘણી વખત એપ્લિકેશન જેવા જ જમ્પ હોસ્ટ પર બેસે છે. આ બધું એકસાથે સપાટ કરવાનો અર્થ છે કે ચેડાં થયેલી એપ્લિકેશન ઓળખ પાસે પહેલેથી જ તેની પોતાની ક્વેરી કરતાં વધુ પહોંચ છે. ડિઝાઇન દસ્તાવેજમાં ત્રણ જૂથોને ત્રણ હાર તરીકે દોરો, દરેક સાથે તેને મંજૂરી આપતો નિયમ, અને ખાલી જગ્યાઓ કોઈ તેમને બનાવે તે પહેલાં દેખાશે.

ક્લાયન્ટને શું જોઈએ, અને તેનાથી વધુ નહીં

તૈનાત આવૃત્તિ માટે ઇચ્છિત એપ્લિકેશન સ્રોતોને ક્લાયન્ટ એન્ડપોઇન્ટ સુધી પહોંચવા દો, અને અસંબંધિત ક્લસ્ટર અને મેનેજમેન્ટ સેવાઓને તે પહોંચની બહાર રાખો. પછી ડ્રાઇવર નોડ કેવી રીતે શોધે છે તે તપાસો. પહોંચી શકાય તેવો પ્રારંભિક સંપર્ક બિંદુ એ સાબિત કરતું નથી કે ડ્રાઇવર પછીથી પસંદ કરે તેવું દરેક નોડ સરનામું તે ક્લાયન્ટ સંદર્ભમાંથી પહોંચી શકાય તેવું છે, કારણ કે ડ્રાઇવર ક્લસ્ટરને પીઅર વિશે પૂછે છે અને પછી ક્લસ્ટર જે સરનામાં જાહેર કરે તેમાં જોડાય છે.

તેથી જ એક ખાનગી સરનામાની અસંગતિ પરિચિત પેટર્ન બનાવે છે: સફળ પ્રથમ કનેક્શન પછી સમયસમાપ્તિ. જાહેર કરેલાં સરનામાં અને ક્લાયન્ટ રૂટિંગ જાણી જોઈને ગોઠવો; એક અસંગતિ સુધારવા આખું ક્લસ્ટર ઇન્ટરનેટ પર પ્રકાશિત કરવું એ રૂટિંગ ખામીના બદલે એવો સંપર્ક આપે છે જે પાછો ખેંચી શકાતો નથી.

એપ્લિકેશનની ડેટાબેઝ પ્રમાણીકરણ અને ભૂમિકા પરવાનગીઓ પણ જ્યાં છે ત્યાં રાખો. વહેંચાયેલું અનુવાદિત VPN સરનામું ઘણા વપરાશકર્તાઓ કે સેવાઓનું પ્રતિનિધિત્વ કરી શકે છે, તેથી તે ક્યારેય અલગ ડેટાબેઝ ઓળખનો વિકલ્પ નથી.

ક્લાયન્ટ-થી-નોડ અને આંતર-નોડ અલગ રીતે એન્ક્રિપ્ટ કરો

Apache નું સુરક્ષા દસ્તાવેજીકરણ ક્લાયન્ટ-થી-નોડ અને આંતર-નોડ એન્ક્રિપ્શનને અલગ રૂપરેખાંકન તરીકે ગણે છે, અને એક સક્ષમ કરવાથી બીજું સક્ષમ થતું નથી. એ ભેદ VPNની અંદર પણ લાગુ પડે છે, કારણ કે ટનલ પોતાના સેગમેન્ટને સુરક્ષિત કરે છે અને એપ્લિકેશન પ્રક્રિયાથી ડેટાબેઝ પ્રક્રિયા સુધી કે ક્લસ્ટરના દરેક જોડી સભ્યો વચ્ચે આપોઆપ વિસ્તરતી નથી.

ટેમ્પલેટનું મૂળભૂત મૂલ્ય વારસામાં લેવાને બદલે બંનેને સ્પષ્ટ રીતે ચાલુ કરતું રૂપરેખાંકન લગભગ આવું દેખાય છે:

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

જે સર્વર રૂપરેખાંકનોમાં વૈકલ્પિક ક્લાયન્ટ એન્ક્રિપ્શનની મંજૂરી હોય છે, ત્યાં TLS સ્વીકારવું એ બિન-એન્ક્રિપ્ટેડ કનેક્શન સ્વીકારવા સાથે સહઅસ્તિત્વ ધરાવી શકે છે, તેથી ઇરાદો નહીં, અસરકારક નીતિ વાંચો. દરેક ક્લાયન્ટ ખરેખર સંપર્ક કરે તેવા એન્ડપોઇન્ટ માટે પ્રમાણપત્રના નામ, વિશ્વાસ વિતરણ અને નવીકરણનું આયોજન કરો; હોસ્ટનામની જગ્યાએ IP સરનામું મૂકવાથી ક્લાયન્ટની ઓળખ તપાસ બદલાય છે, ફક્ત તેનો રૂટ નહીં.

વહીવટને તેના પોતાના માર્ગ પર રાખો

આંતર-નોડ ટ્રાફિકને માન્ય પીઅર સમૂહ અને પોતાની સુરક્ષા નીતિની જરૂર છે. વહીવટી એક્સેસને, જ્યાં વપરાય છે ત્યાં JMX સહિત, અલગ જૂથ અને પોતાનું પ્રમાણીકરણ જોઈએ. સામાન્ય ક્વેરી આપવાની મંજૂરી ધરાવતી એપ્લિકેશનને તેથી દરેક મેનેજમેન્ટ ક્ષમતાની જરૂર હોતી નથી, અને ઊલટું વધુ ખરાબ છે: એપ્લિકેશન સેગમેન્ટ માટે ખુલ્લો વહીવટી માર્ગ ખામીથી પુનર્નિર્માણ સુધીનો સૌથી ટૂંકો રસ્તો છે. તે બે જૂથો અલગ લખો અને તેમના માલિકોને નામ આપો, કારણ કે તે સામાન્ય રીતે અલગ ટીમો હોય છે જેમના નિયમો અકસ્માતે ભેગા થઈ ગયા હોય છે.

અસરકારક ક્લાઉડ નિયમો, હોસ્ટ નિયમો અને શ્રોતા રૂપરેખાંકન સુસંગત રાખો. ખાનગી શ્રોતા હજી પણ અનિચ્છનીય અનુવાદ કે પ્રોક્સી દ્વારા ખુલ્લો રહી શકે છે, અને પહોળો જાહેર નિયમ સાંકડા VPN નિયમની બાજુમાં શાંતિથી બેસી શકે છે જ્યાં સુધી કોઈ બંનેની એકસાથે ઓડિટ ન કરે.

જ્યાં ઓપરેટરોને ખરેખર મેનેજમેન્ટ માર્ગની જરૂર હોય ત્યાં તેને નામવાળો માલિક અને એપ્લિકેશન કરતાં ટૂંકી ઓળખપત્રની આવરદા આપો. આનાથી જ્યારે આગલી વ્યક્તિ ક્લસ્ટરનો વારસો લે ત્યારે પ્રતિનિધિત્વ દૃશ્યમાન રહે છે.

ડિઝાઇન શું વચન આપે છે

ત્રણેય વચનોને ફક્ત કનેક્ટિવિટી પરીક્ષણોથી નહીં, વાસ્તવિક ભૂમિકાઓથી ચકાસો. મંજૂર થયેલી એપ્લિકેશને તેનું માન્ય કામ પૂરું કરવું જોઈએ અને તેનાથી વધુ નહીં, બાકાત કરેલા સ્રોતે ક્લાયન્ટ પ્રવેશદ્વાર પર નિષ્ફળ જવું જોઈએ, અને એપ્લિકેશન ઓળખને આરક્ષિત વહીવટી માર્ગો પર નકારવી જોઈએ. ક્લાયન્ટ પુનઃકનેક્શન અને નોડ પસંદગીને તે જ રોલઆઉટ પરીક્ષણમાં ઉમેરો, કારણ કે શોધની ભૂલો ત્યાં જ પ્રગટ થાય છે.

ડિઝાઇન દસ્તાવેજમાં ત્રણ વાક્યો સાથે પૂર્ણ કરો: કયા ક્લાયન્ટ ક્વેરી કરી શકે, કયા નોડ સંચાર કરી શકે અને કયા ઓપરેટર વહીવટ કરી શકે. VPNની પાછળ હોવું ઉપયોગી ટોપોલોજી માહિતી છે, પણ તે આ ત્રણ પ્રશ્નોમાંથી કોઈનો જવાબ નથી.