الإدارة السرية

الإدارة السرية

1) لماذا وما الذي نعتبره بالضبط «سرًا»

سري - أي مادة يؤدي الكشف عنها إلى حل وسط للنظام أو البيانات: كلمات المرور، ورموز واجهة برمجة التطبيقات، ومفاتيح OAuth/JWT الخاصة، ومفاتيح SSH، والشهادات، ومفاتيح التشفير (KEK/DEK)، ومفاتيح توقيع الويب، وقواعد بيانات/مخابئ DS، مفاتيح البائع (المدفوعات، مزودي البريد/الرسائل القصيرة)، أملاح ملفات تعريف الارتباط/الفلفل، رموز الروبوت/الدردشة، التراخيص.
توجد الأسرار في الرمز، والتكوين، والبيئة، وصور الحاويات، CI/CD، Terraform/Ansible، والسجلات/المقالب - مهمة إدارة الأسرار: الحساب التخزين التسليم استخدام التناوب الاستجابة مراجعة الحسابات والاستخدام.

2) مبادئ العمارة

المركزية. طبقة واحدة موثوقة (Vault/Cloud Secret Manager/KMS) للتخزين والإصدار والتدقيق.
أقل الامتيازات (PoLP). الوصول إلى الخدمات/الأدوار اللازمة فقط، لفترة دنيا.
حياة قصيرة. يفضل الأسرار الديناميكية/الزمنية مع TTL/عقد الإيجار.
خفة الحركة المشفرة. القدرة على تغيير الخوارزميات/أطوال المفاتيح دون توقف.
فصل الأسرار عن الشفرة/الصور. لا توجد كلمات مرور في المستودعات ولا صور Docker.
إمكانية الملاحظة ومراجعة الحسابات. يتم تسجيل كل عملية لإصدار/قراءة الأسرار وحذفها.
الدوران التلقائي. التناوب هو عملية قيد الإعداد وليست إجراءً يدويًا.

3) الحلول النموذجية والأدوار المكونة

KMS/HSM. Root trust, encryption/key wrapping operations (envelope).
مدير سري/قبو. متجر الإصدارات السرية، ACL، التدقيق، الأسرار الديناميكية (DB، cloud-IAM، PKI)، نماذج التناوب.
PKI/CA. إصدار توقيعات قصيرة الأجل لـ mTLS/SSH/JWT.
العميل/العربة الجانبية. تسليم الأسرار إلى وقت التشغيل (tmpfs، in-memory k/v، hot-reload files).
سائقي/مشغلي CSI. التكامل مع Kubernetes (Secret Store CSI Driver، cert-manager).
طبقة التشفير في Git. SOPS/age، git-crypt (لرمز البنية التحتية).

4) التصنيف والسياسة

• TTL/الإيجار وتواتر التناوب ؛
• طريقة الإخراج (الديناميكيات مقابل الثابتة)، الشكل، الوسائط ؛
• سياسة الوصول (من/أين/متى/لماذا)، ومتطلبات التوثيق المتبادل ؛
• مراجعة الحسابات (أن نسجل كم نخزن، ومن يستعرض) ؛
• إجراءات وسحب الزجاج.

5) دورة الحياة السرية

1. الإنشاء: من خلال واجهة برمجة التطبيقات للمدير السري مع البيانات الوصفية (المالك، العلامات، النطاق).
2. التخزين: مشفر (مغلف: DEK ملفوف بـ KEK من KMS/HSM).
3. التسليم: بناء على طلب كيان معتمد (OIDC/JWT، SPIFFE/SVID، mTLS).
4. الاستخدام: حصرا في الذاكرة/في tmpfs ؛ حظر قطع الأشجار/مقالب النفايات.

5. التناوب: بواسطة TTL أو حدث (حل وسط) ؛ دعم النسخ المتوازية (N-1)

6. الاستدعاء/الحظر: الانتهاء الفوري لعقد الإيجار، وإعاقة الحساب/المفتاح في النظام المستهدف.
7. التخلص: تدمير النسخ/المواد، سلسلة مراجعة واضحة.

6) الأسرار الديناميكية (موصى بها افتراضيًا)

• بيانات اعتماد قاعدة البيانات (Postgres/MySQL) مع TTL 15-60 دقيقة.
• مفاتيح سحابية مؤقتة (AWS/GCP/Azure) حسب دور الخدمة.
• شهادات SSH (5-30 دقيقة)، X.509 شهادات (ساعة/يوم).
• فريق العمل المشترك المؤقت لطلبات التوقيع، وسماسرة تذاكر الجلسات.
• الإيجابيات: الحد الأدنى من نصف قطر الانفجار، الاستدعاء المبسط (لن «يبقى» شيء في العالم).

7) تسليم الأسرار في وقت التشغيل

• Secret Store CSI Driver → أسرار متراكمة من مدير خارجي إلى ملفات (tmpfs).
• تجنب Kubernetes Secret كمصدر وحيد (base64 ≠ التشفير) ؛ إذا لزم الأمر، تمكين مزود KMS لـ ettcd.
• وكيل Sidecar (وكيل Vault/Secrets Store) مع عقد إيجار تلقائي وإعادة تحميل ساخن.
• VM/Bare-metal: عامل النظام + mTLS إلى Vault/Secret Manager، مخبأ في الذاكرة، الحد الأدنى من TCB.
• بدون خادم: التكامل السحابي مع استبدال شفاف للأسرار كمتغيرات/ملفات بيئية، ولكن تجنب المحاذير طويلة العمر - ويفضل الملفات/في الذاكرة.

مثال (Kubernetes + CSI، من الناحية المفاهيمية)

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8) CI/CD و IaC التكامل

CI: يحصل العمال على رموز قصيرة العمر وفقًا لـ OIDC (هوية عبء العمل). حظر الأسرار «المقنعة» التي تدخل في السجلات ؛ خطوة «مسح التسرب» (trufflehog/gitleaks).
CD: يأخذ النشر الأسرار في وقت العرض، ولا يكتبها في القطع الأثرية.
IaC: Terraform تخزن المتغيرات في Secret Manager ؛ الدولة مشفرة والوصول مقيد.
SOPS/age: لإعادة الشراء - قوائم التخزين المشفرة والمفاتيح - تحت سيطرة KMS.

مثال (جزء SOPS)

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9) سياسات الوصول وتوثيق عبء العمل

هوية عبء العمل: SPIFFE/SPIRE، Kubernetes SA→OIDC→IAM - роль، mTLS.
الرموز المؤقتة: TTL قصيرة، نطاق ضيق.
ABAC/RBAC في Secret Manager: «من يمكنه قراءة سر X في بيئة Y» منفصل عن «من يمكنه إنشاء/تدوير».
الاستئجار المتعدد: مساحات/حلقات مفاتيح منفصلة لكل مستأجر ؛ السياسات الفردية والإبلاغ.

10) التناوب والنسخ والتوافق

فصل المعرف السري وإصداره («secret/app/db # v17»).
دعم نسختين عاملتين (N و N-1) للتناوب بدون توقف.
يعتمد التناوب على الأحداث: عند الفصل، والتسوية، وتغيير المزود، وترحيل الخوارزميات.
التشغيل الآلي: cron/التناوب الخلفي في محفزات Vault/Secret Manager + webhook لإعادة تشغيل التطبيق/إعادة التشغيل.

وصفة مصغرة «مفتاحين» دوران الخطاف

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11) التخزين خارج وقت التشغيل: نسخ احتياطية وقطع أثرية

لا تدخل أبدًا في القطع الأثرية (الصور، أرشيف السجلات، المقالب).
نسخ احتياطية من المدير السري - تشفير، مفاتيح تخزين خارج نفس الحلقة (فصل الواجبات).
العلامات ومسح DLP: الكشف عن الأسرار في S3/Blob/GCS، Git، CI القطع الأثرية.

12) قابلية الملاحظة ومراجعة الحسابات و SLO

المقاييس: عدد القضايا/السرية/الخدمة، حصة عقد الإيجار المنتهي الصلاحية، متوسط TTL، وقت التناوب، وقت التقارب (ثوانٍ/دقائق قبل «قبول» الإصدار الجديد).
سجلات مراجعة الحسابات: من/ماذا/متى/أين/لماذا ؛ التخزين بشكل منفصل، مشفر أيضًا.
SLO: 99٪ إنتاج <200 مللي ثانية ؛ وتسرب 0 في جذوع الأشجار ؛ 100٪ من الأسرار لها مالك/TTL/علامات ؛ 100٪ أسرار مهمة - ديناميكية أو دوران ≤ 30 يومًا.
التنبيهات: تنتهي صلاحية السر <7 أيام (ثابتة)، ارتفاع في حالات فشل المصادقة في التخزين، لا يوجد سر يقرأ> N days (ميت)، مصادر geo/ASN غير متوقعة.

13) الأخطاء المتكررة وكيفية تجنبها

أسرار في Git/imagery. استخدام SOPS/العمر والماسحات الضوئية ؛ لحظر الخطوط «العارية».
المبعوثون كوسيط طويل الأجل. إعطاء الأفضلية لملفات tmpfs/in-memory ؛ تنظيف البيئة في الشوكات/المقالب.
نفس الأسرار للتطوير/المرحلة/الدفع. تقسيم البيئة.
كلمات مرور ثابتة طويلة العمر. التحول إلى ديناميكي/قصير العمر.
مفتاح رئيسي واحد "لكل شيء. "تقسيم المستأجر/المشروع/الخدمة.
لا إعادة تحميل ساخنة. يتطلب التطبيق إعادة تشغيل → نافذة الضعف أثناء الدوران.

14) أمثلة على عمليات التكامل (تخطيطية)

الوصول الديناميكي إلى Postgres

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

توقيع JWT على الطلبات (قصيرة الأجل)

يتم تخزين المفتاح الخاص في Secret Manager ؛ تطلب الخدمة رمز توقيع قصير الأجل ويوقع الوكيل المحلي الحمولة (لا يتم تمرير المفتاح إلى التطبيق كسلسلة).

شهادات SSH للمسؤولين

إصدار شهادة SSH لمدة 10 دقائق عبر SSO (OIDC)، دون توزيع مفاتيح دائمة.

15) السلامة حول الحواف

السجلات/المسارات/المقاييس: معقمات، مرشحات للمفاتيح/الأنماط المعروفة ؛ حقول «سرية» - إخفاء في APM.
تقارير المقالب/التصادم: قطع افتراضياً ؛ إذا لزم الأمر - تشفيرها وتنظيفها.
تطبيقات العميل/الهاتف المحمول: تقليل الأسرار غير المتصلة بالإنترنت، استخدام تخزين النظام الأساسي (Keychain/Keystore)، ربط الجهاز، تثبيت TLS مع لف الطوارئ.

16) الامتثال

PCI DSS: حظر تخزين PAN/الأسرار دون تشفير ؛ مراقبة صارمة للدخول والتناوب.

ISO 27001/SOC 2 - إدارة الأصول، وقطع الأشجار، ومراقبة الوصول، ومتطلبات إعادة التشكيل

اللائحة العامة لحماية البيانات/المنظمون المحليون: التقليل، الوصول حسب الحاجة، التدقيق.

17) العمليات وكتيب التشغيل

التكليف

1. جرد الأسرار (المستودعات، السجلات المدنية، الصور، وقت التشغيل، النسخ الاحتياطية).
2. التصنيف والعلامات (المالك، البيئة، المستأجر، سياسة التناوب).
3. تكامل Vault/Cloud SM + KMS/HSM.
4. تحديد الناتج حسب هوية عبء العمل (OIDC/SPIRE).
5. تمكين الأسرار الديناميكية لـ DB/Cloud/PKI.
6. التدوير التلقائي وإعادة التحميل الساخن ؛ عند انتهاء الصلاحية.
7. إعداد ماسحات تسرب وكتالوج البيانات/ET.

سيناريوهات الطوارئ

التسريب المشتبه به: قائمة إيقاف الوصول، التناوب الفوري، إلغاء الشهادات/المفاتيح، إعادة إصدار الرموز، تمكين زيادة التدقيق، RCA.
المدير السري غير متوفر: ذاكرة مخبأة محلية ذات ذاكرة منخفضة TTL، وتدهور الوظيفة، وتقييد الاتصالات الجديدة، وخطوات زجاج الكسر اليدوي.
حل وسط لمفتاح الجذر: تجديد التسلسل الهرمي للمفتاح، وإعادة غلاف جميع DEKs، والتحقق من جميع التعرضات لنافذة المخاطر.

18) القوائم المرجعية

قبل البيع

• الأسرار المحذوفة من الرمز/الصور ؛ بما في ذلك ماسحات التسرب.
• يتم تمكين الآليات الديناميكية للأسرار الحرجة.
• التسليم عبر عربة جانبية/CSI/tmpfs مع إعادة تحميل ساخنة، ولا يوجد محاسد دائم.
• تم تشكيل سياسات IAM/ABAC، مرتبطة بعبء العمل.
• التدوير التلقائي والنسخ المزدوجة (N، N-1) من أجل التوافق.
• تمكين المقاييس/التنبيهات/عمليات مراجعة الحسابات ؛ اجتازت اختبارات التدهور.

عملية

• التقرير الشهري: المالكون، TTL، الأسرار منتهية الصلاحية، غير المستخدمة.
• دورات دورية واختبارات اختراق مسارات التسرب (جذوع الأشجار والمقالب والتحف).
• خطة الرشاقة المشفرة واستبدال CA/الجذور في حالات الطوارئ.

19) الأسئلة الشائعة

س: هل المدير السري بدون KMS كافٍ ؟

ج: بالنسبة للمستوى الأساسي - نعم، ولكن من الأفضل استخدام تشفير المغلف: KEK في KMS/HSM، الأسرار - ملفوفة. وهذا يبسط التغذية المرتدة والامتثال.

س: ماذا تختار - ثابت أم ديناميكي ؟

ج: الافتراضي هو الديناميكيات. اترك ثابتًا فقط في حالة عدم وجود مزودين مدعومين، واحرق TTL حتى أيام/ساعات + دوران تلقائي.

س: كيف ترمي الأسرار بأمان في الخدمة الدقيقة ؟

: هوية عبء العمل mTLS Secret Manager sidecar/CSI tmpfs + hot-reload. لا سجلات، لا مبعوثين «إلى الأبد».

س: هل يمكنني الاحتفاظ بأسرار في Kubernetes Secret ؟

ج: فقط مع تمكين التشفير etcd مع مزود KMS والسياسات الصارمة. تفضل التخزين الخارجي و CSI.

س: كيف «تمحو» وصول المستأجر ؟

ج: إلغاء/تجميد سياساتها في Secret Manager، وإبطال جميع عقود الإيجار، وتناوب/تجديد المفاتيح ؛ عند استخدام KMS - فك غلاف KEK المقابل.

• «في الراحة التشفير»
• «In Transit Encryption»
• «الإدارة والتناوب الرئيسيان»
• «التوثيق S2S»
• «توقيع الطلبات والتحقق منها»