للاعتمادات الثابتة — كلمة مرور قاعدة بيانات أو مفتاح AWS يعيش في ملف إعداد أو متغير بيئة — عيبٌ جوهري: لا تنتهي صلاحيتها. إذا سرب اعتمادٌ عبر سطر سجل أو إيداع في git أو منفّذ CI مخترق، يبقى صالحًا إلى أجل غير مسمى ما لم يدوّره أحدٌ يدويًا. على نطاق واسع مع مئات الخدمات، "الدوران اليدوي" يعني فعليًا "لا دوران أبدًا". تحلّ الأسرار الديناميكية هذه المشكلة على المستوى المعماري: يولّد Vault اعتمادًا جديدًا محدود الصلاحية عند الطلب ويدمّره تلقائيًا عند انتهاء الإيجار. لا شيء يمكن تسريبه تبقى له قيمة دائمة.
المفهوم الأساسي: السر الديناميكي لا يُسترجع من التخزين — بل يُنشأ عند الطلب. يستدعي Vault واجهة برمجة النظام الهدف (قاعدة بيانات أو AWS STS أو Azure AD أو غيرها)، ويوفّر مبدأً جديدًا بالأذونات المطلوبة، ويُعيد الاعتماد، ويضبط مدة بقاء (TTL). عند انتهاء المدة، يُلغي Vault الاعتماد. تحصل التطبيقات على اعتمادات لم تُوجد من قبل ولن تُوجد مجددًا بعد انتهاء الإيجار.
نموذج مخاطر الاعتمادات الثابتة مقابل الديناميكية
تخيّل نشرًا نموذجيًا للخدمات المصغّرة: عشر خدمات تتشارك كلمة مرور Postgres واحدة مخزّنة في Kubernetes Secret. نطاق الضرر عند اختراق اعتماد واحد يشمل جميع الخدمات العشر وكل جدول في قاعدة البيانات، والمهاجم أمامه أيام أو أسابيع قبل أن يلاحظ أحد. مع الأسرار الديناميكية، تحصل كل خدمة على اعتمادها الخاص المرتبط بإيجارها الخاص. وإذا اختُرقت الخدمة A، فاعتمادها الوحيد هو ما هو موجود — وهو ينتهي خلال ساعة. ينهار نافذة المهاجم من أسابيع إلى دقائق.
الاعتمادات الثابتة تُنشئ نطاقات ضرر مشتركة وطويلة الأمد. الأسرار الديناميكية تعزل كل خدمة باعتمادات قصيرة الأجل تُلغى تلقائيًا.
تفعيل محرك أسرار قاعدة البيانات
يأتي Vault مع محرك أسرار لقواعد البيانات يدعم PostgreSQL وMySQL وMSSQL وMongoDB وCassandra وElasticsearch وغيرها. النمط متطابق في جميعها: اضبط الاتصال، عرّف أدوارًا بقوالب SQL، واسمح للخدمات بطلب اعتمادات عند الحاجة. فيما يلي الإعداد الكامل لـPostgreSQL — الأكثر شيوعًا في الإنتاج:
# 1. تفعيل محرك أسرار قاعدة البيانات عند مسار معين
vault secrets enable -path=database database
# 2. إعداد الاتصال بكلستر PostgreSQL
# يستخدم Vault هذا الاتصال المتميز لإنشاء الأدوار وحذفها
vault write database/config/prod-postgres \
plugin_name=postgresql-database-plugin \
connection_url="postgresql://{{username}}:{{password}}@postgres.internal:5432/appdb?sslmode=require" \
allowed_roles="app-readonly,app-readwrite,app-migration" \
username="vault_admin" \
password="$VAULT_ADMIN_PW" \
rotation_statements="ALTER USER {{username}} WITH PASSWORD '{{password}}';"
# 3. تدوير كلمة المرور الأولية فورًا حتى يكون Vault وحده من يعلمها
vault write -force database/config/prod-postgres/rotate-root
# 4. تعريف دور بقالب SQL للإنشاء ومدة بقاء
vault write database/roles/app-readonly \
db_name=prod-postgres \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
revocation_statements="REVOKE ALL ON ALL TABLES IN SCHEMA public FROM \"{{name}}\";
DROP ROLE IF EXISTS \"{{name}}\";" \
default_ttl=1h \
max_ttl=24h
# 5. طلب اعتماد (ما تفعله التطبيقات أو مهام CI عند الإقلاع)
vault read database/creds/app-readonly
# Key Value
# --- -----
# lease_id database/creds/app-readonly/8a2f3c1d...
# lease_duration 1h
# lease_renewable true
# password A1a-xyz987pqr
# username v-token-app-rea-abc123-1748000000
ممارسة إنتاجية: استدعِ دائمًا rotate-root فور إعداد اتصال قاعدة البيانات. هذا يضمن أن كلمة مرور الحساب المتميّز غير معروفة لأحد — بمن فيهم المهندس الذي أعدّها — وتديرها Vault حصريًا. بدون هذه الخطوة، تبقى كلمة مرور الإقلاع في سجل الشل وسجلات تدقيق Vault بنص صريح.
الاعتمادات الديناميكية لـAWS (IAM)
يتبع محرك AWS نفس النمط لكنه يستدعي واجهة STS أو IAM من AWS بدلًا من قاعدة البيانات. يمكنه توليد اعتمادات الدور المفترض (رموز STS مؤقتة عبر sts:AssumeRole)، أو رموز المستخدم المفوّض، أو مستخدمي IAM كاملين بمفاتيح وصول برمجية. في الإنتاج، تُفضَّل اعتمادات الدور المفترض بقوة لأنها محلية لـAWS IAM، تنتهي صلاحيتها بشكل مدمج عبر STS، ولا تحتاج Vault لاستدعاء iam:DeleteAccessKey للتنظيف.
# تفعيل محرك AWS
vault secrets enable -path=aws aws
# الإعداد بمستخدم Vault IAM يملك صلاحية sts:AssumeRole
vault write aws/config/root \
access_key="$AWS_ACCESS_KEY_ID" \
secret_key="$AWS_SECRET_ACCESS_KEY" \
region=us-east-1
# إنشاء دور يفترض دور IAM موجود عبر STS
vault write aws/roles/deploy-role \
credential_type=assumed_role \
role_arns=arn:aws:iam::123456789012:role/DeployerRole \
default_ttl=15m \
max_ttl=1h
# التطبيق يطلب اعتمادات في وقت التشغيل:
vault read aws/creds/deploy-role
# Key Value
# --- -----
# lease_id aws/creds/deploy-role/9c4d...
# access_key ASIAXXX...
# secret_key wJalrXUt...
# security_token FQoGZXIvYXdzE... <-- مطلوب لاعتمادات الدور المفترض
# lease_duration 15m
# lease_renewable true
# في سكريبت نشر: حقن مباشر في البيئة
eval $(vault read -format=json aws/creds/deploy-role | \
jq -r '"export AWS_ACCESS_KEY_ID=\(.data.access_key)
export AWS_SECRET_ACCESS_KEY=\(.data.secret_key)
export AWS_SESSION_TOKEN=\(.data.security_token)"')
خطأ إنتاجي شائع: تتضمن اعتمادات الدور المفترض في AWS رمز security_token (رمز الجلسة) الذي يجب تعيينه كـAWS_SESSION_TOKEN. التطبيقات التي تستهلك اعتمادات مستخدم IAM بدون رمز جلسة ستفشل بصمت مع اعتمادات الدور المفترض — تحصل على أخطاء 403 تبدو كمشكلات أذونات لا كأخطاء تنسيق اعتمادات. اختبر تطبيقك باعتمادات STS مبكرًا، لا فقط بمفاتيح مستخدم IAM طويلة الأمد.
دورة حياة الإيجار: التجديد والإلغاء
كل سر ديناميكي يأتي مع إيجار: معرّف إيجار، ومدة بقاء، وعلامة قابلية التجديد. يتتبع Vault جميع الإيجارات النشطة. يجب على التطبيق تجديد إيجاره قبل انتهائه لتجنب الانقطاع خلال جلسة نشطة. وإذا كان التطبيق قيد الإيقاف، ينبغي إلغاء الإيجار فورًا بدلًا من انتظار الانتهاء الطبيعي — وهذا هو مبدأ الإغلاق عند الفشل.
# تجديد إيجار قبل انتهائه (مثلًا من حاوية مساعدة أو خيط خلفي)
vault lease renew database/creds/app-readonly/8a2f3c1d...
# إلغاء إيجار محدد فورًا (عند إيقاف التطبيق أو الحادث)
vault lease revoke database/creds/app-readonly/8a2f3c1d...
# إلغاء جميع الإيجارات تحت بادئة (خيار طارئ لخدمة مخترقة)
vault lease revoke -prefix database/creds/app-readonly/
# قائمة الإيجارات النشطة لنقطة تحميل (مفيد أثناء الاستجابة للحوادث)
vault list sys/leases/lookup/database/creds/app-readonly/
# فحص إيجار محدد
vault write sys/leases/lookup lease_id=database/creds/app-readonly/8a2f3c1d...
تتولى عميل Vault Agent دورة حياة الإيجار تلقائيًا في معظم نشرات الإنتاج. يُصادق على Vault نيابةً عن التطبيق، يكتب الاعتماد إلى وحدة تخزين tmpfs مشتركة أو بيئة العملية، يجدد الإيجارات استباقيًا عند ثلثي مدة البقاء، ويُعيد جلب الاعتمادات عند تعذّر التجديد. تستهلك التطبيقات الاعتمادات من مسار معروف ولا تتحدث إلى Vault مباشرة.
يتولى Vault Agent المصادقة وتجديد الإيجار كحاوية مساعدة؛ تقرأ حاوية التطبيق الاعتمادات من وحدة tmpfs مشتركة دون أي تبعية مباشرة على واجهة Vault.
تحديد نطاق السياسات لأدوار الأسرار الديناميكية
يجب أن تمتلك كل خدمة سياسة Vault تمنح الوصول فقط للأدوار المحددة التي تحتاجها. اكتب السياسة بـHCL واربطها بأسلوب مصادقة الخدمة (Kubernetes ServiceAccount أو دور AWS IAM أو AppRole أو غيرها):
# السياسة: svc-payments-policy.hcl
# تمنح خدمة المدفوعات اعتمادات قاعدة بيانات للقراءة فحسب
path "database/creds/app-readonly" {
capabilities = ["read"]
}
path "database/creds/payments-readwrite" {
capabilities = ["read"]
}
# تسمح للخدمة بتجديد إيجاراتها وإلغائها
path "sys/leases/renew" {
capabilities = ["update"]
}
path "sys/leases/revoke" {
capabilities = ["update"]
}
# كتابة السياسة وربطها
vault policy write svc-payments svc-payments-policy.hcl
# الربط بمصادقة Kubernetes: ServiceAccount الخاصة بالمدفوعات في فضاء أسماء payments
vault write auth/kubernetes/role/payments \
bound_service_account_names=payments-svc \
bound_service_account_namespaces=payments \
policies=svc-payments \
ttl=1h
مبدأ الحد الأدنى من الامتيازات: يجب ألا تمنح سياسة Vault الواحدة أبدًا الوصول للمسار البديل database/creds/*. يجب أن تُدرج سياسة كل خدمة فقط مسارات الأدوار المحددة التي تستخدمها تلك الخدمة فعلًا. عند اختراق خدمة ما، تحدّ السياسة الضيقة المهاجمَ بأدوار قاعدة البيانات التي كانت تلك الخدمة مخوّلة بها فحسب — لا كل الأدوار في المحرك.
لماذا تتفوق الأسرار الديناميكية على الثابتة: دليل إنتاجي
في شركات مثل Lyft وNetflix وShopify، أسفر الانتقال من الأسرار الثابتة إلى الديناميكية عن نتائج قابلة للقياس: انخفض متوسط وقت اكتشاف كشف الاعتمادات من أيام إلى دقائق (لأن الاعتمادات المسرَّبة تنتهي قبل اكتمال التحقيق الجنائي)، وأصبح دوران الأسرار عملية مستمرة وتلقائية بدلًا من عملية يدوية ربع سنوية، وأصبحت مسارات التدقيق لكل طلب بدلًا من لكل خدمة. مدة البقاء هي المحرّك القسري — عندما تنتهي كل اعتماداتك خلال ساعة، يكون وضع إدارة أسرارك في دوران دائم دون أي تكلفة تشغيلية.
ابدأ بأسرار قاعدة البيانات. يغطي محرك قاعدة البيانات أعلى نوع من الاعتمادات خطورةً في معظم المنظمات. فعّله، اضبط اتصال PostgreSQL أو MySQL واحدًا، انقل خدمة واحدة إلى الاعتمادات الديناميكية، وقِس الأثر. بمجرد إثبات النمط، طبّقه على بقية الأسطول. لا تحاول نقل جميع أنواع الأسرار في آنٍ واحد — الزحف أولًا، ثم المشي، ثم الجري.
نستخدم ملفات تعريف الارتباط لتشغيل هذا الموقع وتحليل الزيارات وعرض إعلانات مخصّصة. يمكنك قبول كل ملفات تعريف الارتباط أو رفض غير الأساسية منها.
سياسة الخصوصية