المتعاقد الذي يحتاج إلى إصلاح عملية استيراد أو تحسين استعلام أو ترحيل جدول يحتاج في العادة إلى بيانات دخول إلى قاعدة البيانات. ونادرًا ما يكون الخطر هو المتعاقد. الخطر هو بيانات الدخول نفسها: تُنشأ على عجل، وتتجاوز حدود المهمة، وتُلصق في رسالة بريد إلكتروني، وتبقى تعمل بعد ستة أشهر من دفع الفاتورة.
والحل روتين قصير. قرّر أولًا إن كان الوصول المباشر ضروريًا أصلًا، ثم أنشئ مستخدمًا بصلاحيات محدودة وله تاريخ انتهاء من البداية، وأرسل كلمة المرور عبر رابط سري لمرة واحدة لا عبر رسالة تحتفظ بنسخ، وأحكم مسار الشبكة، وأغلق الحساب حين ينتهي العمل. يشرح هذا الدليل كل خطوة، مع الأوامر الدقيقة حيث تفيد.
هل يحتاج المتعاقد إلى وصول مباشر إلى قاعدة البيانات؟
ابدأ بالمهمة لا بالطلب. «إصلاح الاستيراد» قد يعني قراءة جدول واحد، وقد يعني صلاحية كتابة على نصف المخطط. اسأل عن العملية والبيئة والجداول المعنية، ثم ابحث عن طريقة أقل كلفة لتوفيرها.
- قاعدة بيانات للاختبار (staging) فيها نسخة حديثة منقّاة من البيانات الحساسة تكفي لمعظم أعمال التشخيص والترحيل، دون كشف سجلات العملاء الحقيقية.
- واجهة API للتطبيق أو للإدارة تكفي غالبًا حين يحتاج المتعاقد إلى تغيير البيانات لا المخطط.
- نسخة متماثلة للقراءة فقط (read replica) تعطي أعمال التحليل التي تكتفي بالقراءة مكانًا تعمل فيه دون المساس بقاعدة البيانات الأساسية.
إذا لم يناسب أي من ذلك ولم يكن من الوصول إلى الإنتاج مفر، فاكتب ملاحظة من سطر واحد بالسبب. هذه الملاحظة تصبح المبرر حين يدقق أحد في هذا الوصول لاحقًا.
أنشئ مستخدمًا بصلاحيات محدودة وتاريخ انتهاء من البداية
لا تسلّم أبدًا بيانات دخول مشتركة أو بيانات دخول أحد الموظفين. المستخدم المخصص هو ما يتيح لك أن ترى ما فعله المتعاقد، وأن تقيّد ما يصل إليه، وأن تحذفه دون التأثير في أي شخص آخر. اضبط تاريخ انتهاء المستخدم عند إنشائه، فينتهي الوصول حتى لو نسيت.
في PostgreSQL يبدو المستخدم الذي لا يقرأ إلا جدولين ويتوقف عن العمل في تاريخ محدد هكذا:
CREATE ROLE contractor_jo LOGIN PASSWORD 'generated-elsewhere'
VALID UNTIL '2026-11-08 18:00+00';
GRANT CONNECT ON DATABASE app TO contractor_jo;
GRANT USAGE ON SCHEMA public TO contractor_jo;
GRANT SELECT ON orders, order_items TO contractor_jo;
وفي MySQL يوجد CREATE USER ... PASSWORD EXPIRE INTERVAL 14 DAY، والخدمات المُدارة مثل RDS و Cloud SQL و Supabase تتيح الأمر نفسه من لوحاتها أو برموز قصيرة العمر مبنية على IAM. استخدم ما تدعمه منصتك، وأنشئ كلمة المرور بمدير كلمات المرور بدل أن تكتبها بنفسك.
امنح أصغر مجموعة صلاحيات تُنجز المهمة المحددة. لمهمة تشخيص يعني ذلك SELECT على جداول بعينها. ولعملية ترحيل يعني صلاحية الكتابة على الكائنات التي ستتغير ولا شيء غيرها. ودورا owner و superuser ليسا الجواب الصحيح أبدًا لحساب مؤقت.
كيفية إرسال بيانات دخول مؤقتة لقاعدة البيانات إلى متعاقد
كلمة المرور هي الجزء الوحيد من التسليم الذي يجب أن يبقى سريًا. أما المضيف والمنفذ واسم قاعدة البيانات واسم المستخدم فمفيدة للمهاجم لكنها لا تكفيه، فيمكن أن تنتقل في رسالة عادية. افصل بين الاثنين.
- تحقق من المستلم عبر قناة تثق بها أصلًا، مثل سلسلة رسائل العقد أو مكالمة. فالعناوين المشابهة طريقة شائعة لوصول بيانات الدخول إلى صندوق بريد خاطئ.
- أنشئ رابطًا سريًا لمرة واحدة لا يحتوي إلا على كلمة المرور. في LinkPilot يُشفَّر النص في متصفحك قبل تخزينه، وتُحذف النسخة المخزنة نهائيًا عند أول فتح للرابط، ويمكنك اختيار مدة صلاحية من ساعة واحدة أو 24 ساعة أو سبعة أيام. وفي حسابات Pro يمكنك ضبط مدة صلاحية مخصصة، وإضافة عبارة مرور، ورؤية سجل التدقيق الذي يبيّن متى فُتح الرابط.
- أرسل الرابط في سلسلة الرسائل المعتادة مع ملاحظة من سطر واحد تقول الغرض منه ومتى تنتهي صلاحيته. ولا تضع اسم المستخدم في الرسالة نفسها التي فيها الرابط.
- أرسل بيانات الاتصال منفصلة: المضيف والمنفذ وقاعدة البيانات واسم المستخدم، وهل TLS مطلوب. رسالة بريد ثانية أو تعليق على تذكرة يكفي، إذ لا شيء فيها سري بمفرده.
- أرسل عبارة المرور عبر قناة مختلفة إن ضبطتها، مثل رسالة نصية أو مكالمة.
- اطلب من المتعاقد أن يؤكد أن الرابط فُتح. وإذا ظهر له أن المحتوى شوهد من قبل ولم يكن هو من فتحه، فاعتبر كلمة المرور مكشوفة وغيّرها.
ميزة المشاركة في مدير كلمات المرور بديل معقول حين يكون المتعاقد داخل خزنتك أصلًا. أما في تعاقد لمرة واحدة، فالرابط لمرة واحدة يغنيك عن إنشاء حساب لمجرد تسليم قيمة واحدة. ويشرح دليل الروابط السرية أم مديرو كلمات المرور متى يناسب كل منهما.
أحكم الاتصال
المستخدم ذو الصلاحيات المحدودة على منفذ مفتوح يبقى مشكلة. وثلاثة ضوابط تسد معظم الثغرة.
- اشترط TLS في الاتصال، واطلب من المتعاقد ضبط
sslmode=requireأو ما يعادله في برنامجه. فكثير من البرامج تعود إلى الاتصال غير المشفر بصمت إن لم تُصرّ على ذلك. - قيّد المصدر بقائمة عناوين IP مسموح بها أو بشبكة VPN أو بخادم وسيط (bastion host). وإضافة عنوان المتعاقد إلى القائمة طوال مدة العمل سريعة الإعداد وسريعة الإزالة.
- لا تشارك إلا ما تحتاجه المهمة. لا يحتاج المتعاقد إلى مخطط الشبكة الداخلية، ولا إلى قواعد البيانات الأخرى على الخادم، ولا إلى عنوان URL لوحدة الإدارة.
إذا كانت منصتك تقدم رموز IAM قصيرة العمر بدل كلمات المرور الثابتة، فهي الخيار الأفضل في العادة، وتغنيك عن تسليم كلمة المرور من الأساس.
راقب الحساب ثم أغلقه
فعّل تسجيل عمليات المصادقة والاستعلامات للمستخدم الجديد قبل بدء العمل، حتى تقارن ما حدث بما اتُّفق عليه. وعمليات الدخول في ساعات غريبة أو الاستعلامات على جداول لا علاقة لها بالمهمة تستحق سؤالًا، لا اتهامًا.
وحين تنتهي المهمة أو يتغير نطاقها، افعل أربعة أشياء في اليوم نفسه:
- احذف المستخدم أو عطّله، وتأكد أنه لم يعد قادرًا على الاتصال.
- أزل الاستثناء الشبكي الذي أضفته له.
- غيّر كل سر انتقل مع بيانات الدخول، مثل كلمة مرور تطبيق كانت في التذكرة نفسها.
- سجّل التسليم: من كان لديه وصول، وإلى ماذا، ومن متى إلى متى، ولماذا. احتفظ بالسجل لا بكلمة المرور.
بيانات الدخول المؤقتة ذات الصلاحيات المحدودة وتاريخ الانتهاء، التي تُسلَّم مرة واحدة وتُغلق في موعدها، ليست استثناءً أمنيًا. إنها ببساطة الطريقة التي يجب أن يعمل بها وصول المتعاقدين.