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 ان لوگوں اور اوزاروں کے لیے درست رہتا ہے جن کے منظور شدہ کام کو اس کی ضرورت ہے۔ اس ڈیزائن کو کرداروں، نیٹ ورک کی وسعت اور عملی حدود سے مشروط کریں، اور باقی گاہکوں کو تنگ انٹرفیس رکھنے دیں۔ دونوں آبادیوں کو ایک کردار میں ملانا ہی وہ جگہ ہے جہاں بحثیں شروع ہوتی ہیں۔