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 المباشر صحيحاً للأشخاص والأدوات الذين تتطلب وظيفتهم المعتمدة ذلك. فقيّد ذلك التصميم بالأدوار ونطاق الشبكة والحدود التشغيلية، ودع العملاء الآخرين يحتفظون بالواجهة الأضيق. وخلط الفئتين في دور واحد هو حيث تبدأ الجدالات.