التكامل مع مدير الأسرار

صُمّم DuoKey ليتصل بمدير الأسرار الذي تشغّله بالفعل، بدلًا من إجبارك على تبنّي مدير جديد. لا تُدرج الأسرار مطلقًا في الشيفرة بشكل ثابت، ولا تُودَع أبدًا في Git، ولا تُكتب أبدًا على قرص المجموعة — بل تُجلب عند الطلب وتُحفظ في الذاكرة فقط.

أحضر مدير الأسرار الخاص بك

إذا كانت مؤسستك تعتمد بالفعل معيارًا موحّدًا على HashiCorp Vault أو CyberArk أو HSM شبكي، فإن DuoKey يستهلك الأسرار منه مباشرة. تكون نسخة OpenBao المضمّنة هي الافتراضية للمواقع الجديدة ويمكن حذفها بالكامل.

مديرو الأسرار المدعومون

مدير الأسرار	مسار التكامل	الحالة
OpenBao (افتراضي)	External Secrets Operator (مصادقة Kubernetes)	الافتراضي الموصى به
HashiCorp Vault	External Secrets Operator / Vault Agent Injector	مدعوم بالكامل
CyberArk (Conjur / AAM / CCP)	External Secrets Operator (موفّر Conjur)	مدعوم بالكامل
Azure Key Vault	External Secrets Operator / CSI Secrets Store	مدعوم (المواقع المتصلة)
AWS Secrets Manager / GCP Secret Manager	External Secrets Operator	مدعوم (المواقع المتصلة)
DuoKey MPC	أصلي (حصص مفاتيح موزّعة)	جذر الثقة الأساسي — لا حاجة لـ HSM
Securosys HSM	PKCS#11، KMIP	مدعوم (جذر ثقة عتادي)
Kubernetes Secrets (etcd مشفّر)	أصلي	احتياطي / للمختبر فقط

كيف يعمل الحقن

يستخدم DuoKey External Secrets Operator (ESO) كوسيط محايد تجاه المورّدين. يظلّ مدير الأسرار لديك المصدر الوحيد للحقيقة؛ ويزامن ESO فقط القيم المحدّدة التي يحتاجها الجراب، عند الطلب.

1. يقدّم الجراب رمز حساب خدمة Kubernetes الخاص به.
2. يصادق ESO مع مدير الأسرار باستخدام تلك الهوية (دون بيانات اعتماد ثابتة).
3. يُجلب السرّ المطلوب فقط، ويُجسَّد في سرّ Kubernetes في الذاكرة (tmpfs)، ويُركَّب في الجراب.
4. عند إنهاء الجراب، يختفي السرّ — لا شيء يبقى على القرص.

مثال: SecretStore لـ HashiCorp Vault

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault
  namespace: duokey
spec:
  provider:
    vault:
      server: "https://vault.corp.example.local:8200"
      path: "duokey"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "duokey"
          serviceAccountRef:
            name: "duokey"

مثال: SecretStore لـ CyberArk Conjur

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: conjur
  namespace: duokey
spec:
  provider:
    conjur:
      url: "https://conjur.corp.example.local"
      auth:
        jwt:
          account: "myConjurAccount"
          serviceID: "openshift"
          serviceAccountRef:
            name: "duokey"

حراسة المفاتيح: MPC أولًا

إن عامل التمييز الجوهري لـ DuoKey — وجذر الثقة الأساسي لديه — هو الحساب متعدد الأطراف (MPC). تُقسَّم مادة المفتاح إلى حصص مستقلة بحيث لا تحمل أي عقدة واحدة، ولا أي مسؤول واحد، مفتاحًا كاملًا مطلقًا. يوفّر هذا حماية للمفاتيح بمستوى HSM دون الحاجة إلى أي عتاد HSM مخصّص، وهو مثالي للنشر داخل المؤسسة والبيئات المعزولة.

• يحمي مدير الأسرار أسرار الاتصال وبيانات الاعتماد.
• يحمي DuoKey MPC المفاتيح التشفيرية نفسها، مع حراسة موزّعة ودون نقطة اختراق واحدة.

اختياري: Securosys HSM

حيثما يُلزَم بجذر ثقة عتادي (على سبيل المثال بموجب سياسة أو شهادة اعتماد)، يتكامل DuoKey مع Securosys HSM:

• المورّد: Securosys (Primus HSM / Securosys Cloud HSM).
• الواجهات: PKCS#11 و KMIP.
• الاستخدام: يقوم محرّك الأسرار (OpenBao/Vault) بختم/فكّ ختم مقابل Securosys HSM، بحيث لا توجد مادة المفتاح الرئيسي أبدًا بنص واضح خارج حدود HSM. يمكن دمج MPC و HSM لتحقيق الدفاع في العمق.
• الشبكة: ضع HSM على شبكة VLAN مخصّصة ومقوّاة (انظر أمن الشبكة).

أفضل الممارسات

• فضّل بيانات الاعتماد الديناميكية قصيرة العمر على الثابتة حيثما يدعم ذلك مدير الأسرار لديك.
• حدّد نطاق كل SecretStore/دور بـأقل امتياز مطلوب.
• دوّر أدوار مصادقة مدير الأسرار ودقّق الوصول بانتظام (انظر الامتثال والتدقيق).
• بالنسبة للمواقع المعزولة، أبقِ مدير الأسرار و HSM داخل المؤسسة بالكامل؛ ولا حاجة لأي اتصال صادر.