TLS, નેટવર્ક પ્રવેશ અને SQL વિશેષાધિકારો જુદા જુદા પ્રશ્નોના જવાબ આપે છે
કનેક્શન એન્ક્રિપ્ટ કરવું, સ્રોતને મંજૂરી આપવી અને ટેબલ આપવું એ ત્રણ નિર્ણય છે. TLS VPN ને બદલી શકે છે કે નહીં તે પૂછતાં પહેલાં તેમને ક્રમમાં જુઓ.
કોઈ વ્યક્તિ ગ્રાહકને PostgreSQL લૉગિન આપવાનું સૂચન કરે છે જેથી ખર્ચનો દાવો શરૂઆતથી અંત સુધી એન્ક્રિપ્ટ થઈને જાય. ડેટાબેઝ સંચાલકને સાચું SQL સત્ર જોઈએ છે, અને બીજું કોઈ તેના બદલે વેબ ફોર્મ સૂચવે છે. બંને સૂચનો ખોટી સમસ્યા ઉકેલે છે, કારણ કે બંનેમાંથી કોઈ ગ્રાહક ખરેખર જે ક્રિયા કરે છે તેનાથી શરૂ થયું નથી. ત્રણ નિર્ણયો ક્રમમાં જુઓ અને TLS VPN ને બદલી શકે છે કે નહીં તે પ્રશ્ન પોતે જ જવાબ આપી દેશે.
ગ્રાહકને જે ક્રિયા જોઈએ છે તેનાથી શરૂ કરો
ગ્રાહકે શું હાંસલ કરવું છે તે લખો. દાવો સબમિટ કરવો, રિપોર્ટની એક પંક્તિ વાંચવી અને તાત્કાલિક ક્વેરી ચલાવવી એ ત્રણ જુદી ક્રિયાઓ છે જેમના ત્રણ જુદા જોખમ પ્રોફાઇલ છે.
પછી લખો કે વિનંતી કોણ કરે છે. ગ્રાહક, સહાય એજન્ટ અને સંચાલક એક જ ટેબલને સ્પર્શે તોપણ એકબીજાના બદલે ન વપરાય. આ તફાવત નક્કી કરે છે કે ગ્રાહકને ક્વેરી ભાષાનો કેટલો ભાગ જોવો જોઈએ.
જવાબોની જોડી ઇન્ટરફેસ નક્કી કરે છે. ત્યાર પછીનું બધું અમલીકરણ છે, અને એન્ક્રિપ્શન વિશેની મોટાભાગની ચર્ચા વાસ્તવમાં કયો ઇન્ટરફેસ પસંદ થયો તેની ચર્ચા છે.
ત્રણ નિયંત્રણો, ત્રણ નિર્ણયો
પ્રમાણિત TLS કનેક્શનનું રક્ષણ કરે છે અને કઈ TLS ઓળખ સ્વીકારવામાં આવે તે નક્કી કરે છે. નેટવર્ક પ્રવેશ નક્કી કરે છે કે કયા સ્રોત શ્રોતા સુધી પહોંચી શકે. ડેટાબેઝ અધિકૃતિ નક્કી કરે છે કે ભૂમિકા કઈ વસ્તુઓ અને ક્રિયાઓ વાપરી શકે.
ત્રણમાંથી એક પણ બીજાનું સ્થાન લેતું નથી, જે ટેબલ સ્પષ્ટ કરે છે.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
બીજી પંક્તિ દૂર કરતાં પહેલાં જે પંક્તિ પર તમે આધાર રાખો છો તે વાંચો. આમાંના મોટાભાગના ડિઝાઇન નિષ્ફળ જાય છે કારણ કે નિયંત્રણ ગોઠવવાને બદલે ધારી લેવાયું હતું.
સીધું SQL ડેટાબેઝ નીતિને જવાબદાર રાખે છે
મંજૂર સીધા કનેક્શન સાથે સેવા ઓળખની ચકાસણી અને ઇચ્છિત પ્રવેશ નીતિ બંને રાખો. TLS ચાલુ કરવાથી એન્ક્રિપ્ટેડ કનેક્શન ઉપલબ્ધ થાય છે; પ્રવેશ રૂપરેખાંકન hostssl એન્ટ્રી દ્વારા ન કહે તો તે એન્ક્રિપ્ટ ન કરેલા કનેક્શનને નકારતું નથી.
આ તફાવત ટેમ્પલેટમાં નહીં, ચાલુ રૂપરેખાંકનમાં ચકાસવા યોગ્ય છે. TLS આપતું અને સાદો ટેક્સ્ટ સ્વીકારતું સર્વર એ ડિઝાઇન નથી જે મોટાભાગના લોકો ધારે છે કે તેમણે તૈનાત કરી છે. પ્રવેશ નિયમો વાંચો અને જુઓ કઈ એન્ટ્રી ખરેખર તેની માંગ કરે છે. એ જ એક ચકાસણી એન્ક્રિપ્શન-સક્ષમ સર્વરને ફક્ત એન્ક્રિપ્ટેડ સર્વરથી અલગ પાડે છે.
ફક્ત કામને જરૂરી વિશેષાધિકારો ધરાવતી ભૂમિકાઓ વાપરો, અને માલિકી, વારસાગત સભ્યપદ અને વ્યાપકપણે આપેલી પરવાનગીઓની સમીક્ષા કરો. PostgreSQL વિશેષાધિકાર મોડેલ ડેટાબેઝ વસ્તુઓ માટે સત્તાની સીમા છે.
VPN ડેટાબેઝ પ્રમાણીકરણ પહેલાં કયા ઉપકરણો સેવા સુધી પહોંચે તે મર્યાદિત કરી શકે છે, અને પ્રવેશ ગેટવે પણ એવું જ કંઈક કરી શકે છે. બંનેથી પણ ખુલ્લા ઘટકની જાળવણી, ઓળખપત્રોનું સંચાલન અને સંસાધન વપરાશ મર્યાદિત કરવાની જરૂર દૂર થતી નથી.
ક્લાયન્ટ સર્ટિફિકેટ ઓળખપત્ર છે, ACL નથી
ક્લાયન્ટ સર્ટિફિકેટ કનેક્શન સમયે એક શરત ઉમેરી શકે છે. clientcert સેટિંગ વિશ્વસનીય સર્ટિફિકેટ અને વધુ કડક મોડમાં સર્ટિફિકેટના નામ અને ડેટાબેઝ વપરાશકર્તા વચ્ચેનો સંબંધ માંગી શકે છે.
તે વધુ મજબૂત ઓળખપત્ર છે. તે અધિકૃતિ યાદી નથી, અને તે સર્વરને અદૃશ્ય કરતું નથી, કારણ કે કનેક્શન સ્વીકારતું ઘટક હજી નેટવર્ક ટ્રાફિક અને હેન્ડશેક પ્રક્રિયા કરે છે. સર્ટિફિકેટને પ્રવેશ યાદી તરીકે ગણવાથી વાસ્તવિક પરવાનગીઓ અસ્પૃષ્ટ રહે છે. તે સર્ટિફિકેટ વિતરણને પણ પહોળું કરવાની વૃત્તિ ધરાવે છે, જે આગલી સમસ્યા ઊભી કરે છે.
વધુ પડતા વિશેષાધિકારોવાળી ભૂમિકા સાથે જોડાયેલું મજબૂત સર્ટિફિકેટ સારી રીતે પ્રમાણિત સંચાલક બનાવે છે. સર્ટિફિકેટની ઉજવણી કરતાં પહેલાં ભૂમિકા તપાસો.
યોગ્ય હોય ત્યારે સાંકડો ઇન્ટરફેસ પસંદ કરો
ખર્ચના દાવા માટે, દાવો સ્વીકારતું, વ્યવસાય નિયમો લાગુ કરતું અને તે વપરાશકર્તાનું મંજૂર પરિણામ પાછું આપતું એપ્લિકેશન એન્ડપોઇન્ટ સામાન્ય SQL ખાતા કરતાં ક્રિયાને વધુ સારી રીતે રજૂ કરે છે.
પછી એપ્લિકેશન પોતાની મર્યાદિત ડેટાબેઝ ઓળખ વાપરે છે, અને ગ્રાહકને ક્યારેય સુવિધા તરીકે ક્વેરી ભાષા મળતી નથી. તે નાની સપાટી છે જેમાં ખોટું થવાના ઓછા રસ્તા છે.
આ ડિઝાઇન વિકલ્પ છે, એવો દાવો નહીં કે એપ્લિકેશન કોડ આપમેળે વધુ સુરક્ષિત છે. તે કોડે તેના કૉલરોને પ્રમાણિત કરવા, દરેક ક્રિયાને અધિકૃત કરવી અને તેનું ઇનપુટ ચકાસવું પડે છે, અને તેની પોતાની ડેટાબેઝ પરવાનગીઓ હજી પણ મહત્વપૂર્ણ છે.
સીધું SQL જેમનું મંજૂર કામ તેની માંગ કરે છે તેવા લોકો અને સાધનો માટે સાચું રહે છે. તે ડિઝાઇનને ભૂમિકાઓ, નેટવર્ક વ્યાપ અને કાર્યસંચાલન મર્યાદાઓથી બાંધો, અને બાકીના ક્લાયન્ટને સાંકડો ઇન્ટરફેસ રાખવા દો. બે વસ્તીને એક ભૂમિકામાં ભેળવવી એ જ જગ્યા છે જ્યાંથી ચર્ચા શરૂ થાય છે.