يصل كل فريق في النهاية إلى مرحلة تتوزع فيها بيانات الدخول على أماكن كثيرة جدًا: ملف .env على كل حاسوب محمول، ورسالة مثبتة في Slack، وجدول بيانات اسمه «logins»، ومتغير في CI ضبطه أحدهم قبل عامين. وُجد مدير الأسرار السحابي ليجمع ذلك كله في مكان واحد مشفر، محكوم الصلاحيات، وخاضع للتدقيق.
يشرح هذا الدليل ما يفعله مدير الأسرار السحابي، وكيف تختار بين الخيارات الرئيسية، وكيف تعتمده دون عملية ترحيل طويلة، والمهمة الوحيدة التي لا يؤديها: إيصال سر إلى شخص من خارج حسابك السحابي.
ما يفعله مدير الأسرار السحابي
يخزن مدير الأسرار القيم الحساسة ويسلّمها إلى الهويات المصرح لها عند الطلب. والميزات الأساسية واحدة لدى جميع المزودين:
- تخزين مشفر للبيانات المخزنة، بمفاتيح محفوظة في خدمة إدارة المفاتيح لدى المزود، و TLS أثناء النقل.
- وصول قائم على الهوية: لكل سر سياسة تحدد المستخدمين أو الأدوار أو أعباء العمل التي يحق لها قراءته أو كتابته أو تدويره. ويصادق التطبيق بهويته الخاصة، لا بكلمة مرور رئيسية.
- سجل تدقيق لكل قراءة وكتابة وتدوير، يحدد من وماذا ومتى.
- الإصدارات والتدوير: يمكن تجهيز قيمة جديدة، ونقل التطبيقات إليها، ثم إخراج الإصدار القديم من الخدمة. وكثير من مديري الأسرار يغيّرون بيانات دخول قواعد البيانات تلقائيًا.
- الجلب وقت التشغيل: يجلب التطبيق السر عند بدء تشغيله أو حين يحتاج إليه، فلا تُكتب القيمة أبدًا في الشيفرة أو صور الحاويات أو ملفات الإعداد.
السر هو كل ما يمنح صلاحية وصول. أما الإعدادات التي تصف السلوك فحسب، مثل رقم المنفذ أو خيار تفعيل ميزة، فمكانها ملفات الإعداد العادية. والخلط بين الاثنين يملأ مخزن الأسرار بالضجيج ويجعل مخزن الإعدادات خطرًا.
كيف تختاره
يتوقف القرار عادة على المكان الذي تعمل فيه أعباء العمل لديك، وعدد السحابات التي تستخدمها.
| الخيار | الأنسب له | انتبه إلى |
|---|---|---|
| AWS Secrets Manager / Parameter Store | أعباء العمل الموجودة أصلًا على AWS، مع هويات IAM في كل مكان | التسعير لكل سر في Secrets Manager، و Parameter Store أرخص للقيم العادية |
| Google Secret Manager | مشاريع GCP وأعباء العمل على Cloud Run و GKE | خيارات النسخ المتماثل بين المناطق |
| Azure Key Vault | أعباء العمل على Azure، واحتياجات إدارة دورة حياة الشهادات | خزنات منفصلة لكل بيئة لتبقى السياسات بسيطة |
| HashiCorp Vault | بيئات متعددة السحابات أو محلية، وبيانات دخول ديناميكية قصيرة الأمد | تشغيله بنفسك ما لم تستخدم النسخة المستضافة |
| Doppler و Infisical و 1Password Secrets Automation | الفرق الصغيرة التي تريد مزامنة مريحة للمطورين مع منصات كثيرة | مزود إضافي في سلسلة الثقة |
أربعة أسئلة تحسم معظم الخيارات. هل يتكامل مع أدوات النشر وبيئة التشغيل لديك دون شيفرة ربط مخصصة؟ هل تستطيع أعباء العمل المصادقة عليه بالهوية التي تملكها أصلًا؟ هل يدوّر أنواع بيانات الدخول التي تحتفظ بها فعلًا؟ وهل تصل سجلات التدقيق فيه إلى حيث ينظر فريق الأمن لديك أصلًا؟ ويأتي التسعير والمناطق وشهادات الامتثال بعد هذه الأسئلة الأربعة.
اعتماده دون مشروع يستغرق ستة أشهر
- الجرد وتعيين المسؤولين. أدرج كل سر، ومكانه، وما يستخدمه، ومن المسؤول عنه. والمسؤول هو من يقرر سياسة التدوير وقائمة الوصول.
- أنشئ الهويات أولًا. أنشئ الأدوار أو حسابات الخدمة لكل عبء عمل وكل بيئة قبل أن تنقل قيمة واحدة. فسياسات الوصول التي تقول «هذه الخدمة، في هذه البيئة، للقراءة فقط» هي جوهر الأمر.
- رحّل حسب الخطورة. كلمات مرور قواعد بيانات الإنتاج ومفاتيح الدفع أولًا، ثم مفاتيح API من الجهات الخارجية، ثم كل ما عدا ذلك. احذف كل قيمة من الشيفرة ومتغيرات CI وملفات الإعداد عند نقلها، ودوّرها أثناء إدخالها، لأن القيمة القديمة نُسخت وتنقلت بالفعل.
- غيّر طريقة قراءة التطبيقات للأسرار. استبدل بالقيم المكتوبة في الشيفرة وملفات البيئة استدعاءً إلى SDK مدير الأسرار عند بدء التشغيل، أو احقنها عبر التكامل الأصلي للمنصة.
- فعّل التدوير لكل ما يستطيع المدير تدويره بنفسه، واكتب دالة تدوير أو دليل تشغيل للباقي.
- أطلق تنبيهًا عند غير المعتاد. قراءة سر من هوية جديدة، أو قفزة في عدد القراءات، أو قراءة من منطقة لا تنشر فيها، كلها تستحق تنبيه المناوب.
والأخطاء الشائعة متوقعة: ترك النسخ القديمة في مكانها بعد الترحيل، ومنح عبء عمل صلاحية قراءة المخزن كله بدل أسراره هو، وتسجيل القيمة المسترجعة في سجلات التطبيق.
الفجوة التي لا يسدها مدير الأسرار
مدير الأسرار مبني للأجهزة وللأشخاص الموجودين داخل نظام الهويات لديك. وليس مبنيًا للحظة التي يجب أن تصل فيها بيانات الدخول إلى شخص من خارجه: متعاقد يحتاج إلى كلمة مرور مؤقتة لقاعدة البيانات، أو عميل يتسلم أول بيانات دخول له بصلاحيات المسؤول، أو مهندس لدى مزود يحتاج إلى رمز لبضع ساعات، أو موظف جديد في يومه الأول قبل أن يُنشأ حسابه في SSO.
هذه التسليمات تحدث في كل الأحوال، وإن لم يكن لها طريق معتمد فإنها تحدث في البريد الإلكتروني والمحادثات، وهي بالضبط الأماكن التي كان يُفترض أن يُخرج مديرو الأسرار بيانات الدخول منها. والطريق المعتمد هو الرابط السري لمرة واحدة. تُشفَّر القيمة في متصفحك قبل تخزينها، ولا تحمل الرسالة إلا رابطًا، وتُتلف النسخة المخزنة في أول مرة يُفتح فيها الرابط، وتنتهي صلاحية الرابط بعد مدة محددة إن لم يفتحه أحد.
والنمط الناجح: مدير الأسرار هو المرجع الرسمي، والرابط لمرة واحدة هو وسيلة التسليم حين يحتاج شخص من خارج النظام إلى قيمة مرة واحدة. أنشئ بيانات الدخول، وخزّنها في مدير الأسرار، وأرسلها إلى الشخص عبر رابط لمرة واحدة، ودوّرها حين تنتهي صلاحية وصوله. ويطبق مقال الروابط السرية مقابل مديري كلمات المرور المنطق نفسه على مدير كلمات المرور الخاص بالفريق، ويتناول دليل تسليم بيانات الدخول بين الفرق الإجراء المعتاد.
قائمة تحقق قصيرة
- لكل سر مسؤول وسياسة وصول وقاعدة تدوير.
- تصادق أعباء العمل بهويتها الخاصة، لا بمفتاح مشترك أبدًا.
- لا يبقى أي سر في الشيفرة أو صور الحاويات أو متغيرات CI أو المحادثات بعد الترحيل.
- تُسجَّل القراءات في مكان ينظر فيه شخص فعلًا.
- يتسلم الأشخاص من خارج نظام الهويات الأسرار عبر رابط لمرة واحدة، لا في رسالة.
نفّذ هذه الأمور الخمسة، فيتوقف مدير الأسرار عن كونه منتجًا اشتريته، ويصبح السبب في توقف تسرّب بيانات الدخول.