Firebird 3 નું વાયર એન્ક્રિપ્શન અને VPN બે અલગ સીમાઓ છે

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

બે સીમાઓ, અને તે એકબીજા પર ઓવરલેપ થતી નથી

VPN સીમા ક્લાયન્ટ અને ગેટવે વચ્ચેના પેકેટોને સુરક્ષિત કરે છે. Firebird નું વાયર એન્ક્રિપ્શન ક્લાયન્ટ લાઇબ્રેરી અને સર્વર પ્રોસેસ વચ્ચેના ડેટાબેઝ પ્રોટોકોલને સુરક્ષિત કરે છે. બંને હાજર હોઈ શકે છે, અને એક પણ બીજાનું સ્થાન લેતું નથી.

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

પ્રથમ સીમા: લિસનર કોણ ખોલી શકે

સાચું સર્વર સરનામું અને ગોઠવેલું પોર્ટ ઓળખો, જે બદલાયું ન હોય તો 3050 છે, પછી હોસ્ટ અને નેટવર્ક ફાયરવોલ પર ફક્ત મંજૂર VPN સ્રોતોને પરવાનગી આપો. VPN ગેટવે પરના કોઈપણ સરનામા અનુવાદને ધ્યાનમાં લો, અને ગેટવે અલગ હોય તો ડેટાબેઝ હોસ્ટને ક્લાયન્ટ પૂલ તરફ પરત માર્ગ આપો.

પછી નકારાત્મક સાબિત કરો. જે બાહ્ય માર્ગ નકારવો જોઈએ તે હજી પણ નકારાયેલો જ રહેવો જોઈએ, કારણ કે ટનલ ખોલવાથી Firebird લિસનર જાતે મર્યાદિત થતું નથી.

બીજી સીમા: Firebird શું વાટાઘાટ કરે છે

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

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

પ્રમાણીકરણ એ જ વાટાઘાટમાં ત્રીજું ચલ છે. સર્વર પ્રમાણીકરણ પ્લગઇનનો સમૂહ સ્વીકારે છે, ક્લાયન્ટ લાઇબ્રેરી તેનો ઉપસમૂહ ઓફર કરે છે, અને બંનેને ઓવરલેપ થવું પડે છે.

Legacy_Auth નો સપાટો

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

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

જે જોડાણ મહત્વનું છે તે તપાસો

જે બિલ્ડ સંદર્ભ ચલ પૂરું પાડે છે તેના પર, આ ક્વેરી વર્તમાન જોડાણની એન્ક્રિપ્શન સ્થિતિ જણાવે છે:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

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

ક્લાયન્ટ લાઇબ્રેરીની આવૃત્તિ, સર્વર બિલ્ડ અને પરિણામ એકસાથે નોંધો, કારણ કે તેમાંથી કોઈ પણ એકલું વાંચી શકાય તેવું નથી.

પરવાનગીઓ અને અપગ્રેડ માર્ગ

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

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