مقارنة مديري الأسرار المستضافين ذاتياً لخادم واحد

ما الذي يفعله مدير الأسرار المستضاف ذاتياً ولا يفعله مدير كلمات المرور

يسلّم مدير الأسرار المستضاف ذاتياً بيانات الاعتماد إلى العمليات. أما مدير كلمات المرور فيسلّم بيانات الاعتماد إلى الأشخاص. وكل شيء آخر ينتج عن هذا الفرق الواحد. يفتح الإنسان الحاضر والمنتبه مدير كلمات المرور. أما مدير الأسرار فعليه أن يسلّم تطبيقك كلمة مرور قاعدة البيانات عند الساعة 03:00 عندما لا يكون أحد مستيقظاً.

تختلف حالات الفشل بطريقة مهمة. إذا كان مدير كلمات المرور مقفلاً، فهذه مشكلة بسيطة: تكتب كلمة المرور الرئيسية مرة أخرى. أما إذا كان مدير الأسرار مختوماً، فهذا انقطاع للخدمة: كل خدمة تعيد التشغيل أثناء بقائه مختوماً تبدأ من دون بيانات اعتماد وتظل متوقفة. يحل تشغيل Vaultwarden كمدير كلمات مرور خاص بك مشكلة الاستخدام البشري جيداً. لكنه لا يحل مشكلة الآلات، ولم يُبنَ لهذا الغرض أصلاً.

تنقسم الخيارات الواقعية لخادم واحد إلى مجموعتين. OpenBao وInfisical خدمتان: API، وقاعدة بيانات، وTLS (أمان طبقة النقل)، وخطوة تسجيل دخول، وعملية يجب عليك الآن إبقاؤها قيد التشغيل. أما SOPS مع age، وsystemd credentials، وDocker secrets فهي ملفات: تكون مشفّرة أثناء التخزين، ويفك تشفيرها شيء يعمل بالفعل، ولا تحتاج إلى أي مكوّن إضافي لمراقبته.

إليك الإجابة الصريحة أولاً. بالنسبة إلى خادم واحد يستخدمه شخص أو شخصان، تكون الخيارات المعتمدة على الملفات صحيحة عادةً. فـOpenBao لا يقوم أحد بإلغاء ختمه بطريقة صحيحة ولا يجري أحد تدوير أسراره أسوأ من ملف env بصلاحية mode 600، لأنه يضيف مكوّناً متغيراً ونسخة احتياطية ستُعدّها بطريقة خاطئة، ولا يوفّر لك أي تدوير لم تكن تنفّذه يدوياً من قبل.

هل يكفي ملف بيئة بوضع 600؟

غالباً، نعم. التهديد الذي يتصدى له هو قراءة مستخدم آخر على الخادم لكلمة مرور قاعدة البيانات. تتولى أذونات ملفات Unix ذلك، وتفعل ذلك قبل أن تصبح الشبكة متاحة.

sudo install -d -m 750 -o root -g myapp /etc/myapp
sudo install -m 640 -o root -g myapp /dev/null /etc/myapp/env
sudoedit /etc/myapp/env

تحقق من ذلك من الجانبين:

sudo -u myapp cat /etc/myapp/env
sudo -u nobody cat /etc/myapp/env

يطبع الأمر الأول محتوى الملف. ويطبع الأمر الثاني cat: /etc/myapp/env: Permission denied، لأن nobody ليس ضمن المجموعة myapp، ولأن الملف لا يحتوي على أذونات للمستخدمين الآخرين. هذا هو نموذج الأمان بأكمله، وهو نموذج فعلي.

يحدث التسريب في الخطوة التالية. تنسخ وحدة systemd التي تحتوي على EnvironmentFile= هذه القيم إلى بيئة العملية، وبيئة العملية قابلة للقراءة.

[Service]
User=myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/usr/local/bin/myapp

sudo cat /proc/$(pgrep -n myapp)/environ | tr '\0' '\n'

يطبع ذلك أسرارك بنص واضح، لأن /proc/<pid>/environ قابل للقراءة من root ومن المستخدم الذي تعمل العملية باسمه. ويرى أداة الإبلاغ عن الأعطال التي ترفق البيئة بالتقرير الشيء نفسه. وينطبق ذلك أيضاً على أي أداة تعمل تحت الحساب نفسه، ولذلك يبدأ إبعاد الأسرار عن وكلاء AI بإخراجها من البيئة. اربط الملف بـمستخدم خدمة مخصص منخفض الصلاحيات حتى لا يكون «المستخدم الذي تعمل العملية باسمه» هو root.

SOPS مع age: أسرار مشفّرة يمكنك إيداعها في git

يشفّر SOPS (عمليات الأسرار) القيم الموجودة في ملف YAML أو JSON، ويترك المفاتيح بنص واضح. أما age فهي أداة تشفير صغيرة تمنحك زوج مفاتيح واحداً، من دون خادم مفاتيح. يتيح لك استخدامهما معاً إيداع secrets.enc.yaml بجانب الشيفرة، بينما يظل git diff يوضح لك الإعداد الذي تغيّر، من دون كشف القيمة الجديدة للقارئ.

تأتي age ضمن حزم Ubuntu 24.04. أما SOPS فلا تأتي ضمنها، لذلك نزّل .deb من صفحة الإصدارات. كان الإصدار 3.13.3 هو الأحدث في August 2026.

sudo apt update && sudo apt install -y age
curl -LO https://github.com/getsops/sops/releases/download/v3.13.3/sops_3.13.3_amd64.deb
sudo apt install -y ./sops_3.13.3_amd64.deb
sops --version

أنشئ زوج مفاتيح. يكتب age-keygen المفتاح الخاص في الملف ويطبع المفتاح العام، لذلك سترى سطراً يبدأ بـPublic key: age1....

mkdir -p ~/.config/sops/age
age-keygen -o ~/.config/sops/age/keys.txt
chmod 600 ~/.config/sops/age/keys.txt
age-keygen -y ~/.config/sops/age/keys.txt

ضع المفتاح العام في .sops.yaml عند جذر المستودع، حتى لا تضطر إلى تذكّر المستلِم في سطر الأوامر.

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c

sops encrypt secrets.yaml > secrets.enc.yaml
sops decrypt secrets.enc.yaml

تطابق القاعدة التي لا تحتوي على path_regex كل شيء، وهذا ما تريده في البداية. إذا أضفت واحداً لاحقاً، فاكتبه بحيث يطابق الملف الذي تمرّره إلى sops، لأن القواعد تُفحص مقابل مسار الإدخال، لا مقابل الملف الذي تعيد توجيه المخرجات إليه.

أثناء التشغيل، مرّر القيم إلى عملية واحدة فقط:

sops exec-env secrets.enc.yaml './myapp'

يفك sops exec-env التشفير في الذاكرة، ويضبط القيم في بيئة العملية الابنة، لذلك لا يُكتب النص الواضح على القرص. يظل التحذير المتعلق بالبيئة من القسم السابق سارياً على تلك العملية الابنة.

هناك أمران يسببان المشكلات هنا. الخطأ Failed to get the data key required to decrypt the SOPS file ضمن systemd يعني في الغالب أن SOPS بحث في الدليل المنزلي الخطأ، لأن الوحدة لا ترث HOME الخاص بك. اضبط المسار صراحةً باستخدام Environment=SOPS_AGE_KEY_FILE=/etc/sops/age.txt في الوحدة. وبشكل منفصل، لا تؤدي إعادة تحرير .sops.yaml إلى إعادة تشفير أي شيء موجود مسبقاً: إضافة المفتاح العام لزميل تؤثر في الملفات الجديدة فقط، لذلك شغّل sops updatekeys secrets.enc.yaml على كل ملف موجود. إذا كان إعدادك يعمل أصلاً عبر Ansible، فإن تشفير القيم نفسها باستخدام Ansible Vault يحقق النتيجة نفسها من دون أداة ثانية.

بيانات اعتماد systemd: أسرار لا تصل إلى البيئة

يتضمن Ubuntu 24.04 الإصدار systemd 255، لذلك لا تحتاج إلى تثبيته. يعمل systemd-creds على تشفير سر على المضيف، ويفك systemd تشفيره داخل دليل خاص لا يمكن للخدمة المعنية وحدها قراءته.

sudo systemd-creds setup
sudo install -d -m 700 /etc/myapp
echo -n 'hunter2' | sudo systemd-creds encrypt --name=db_password - /etc/myapp/db_password.cred

[Service]
User=myapp
LoadCredentialEncrypted=db_password:/etc/myapp/db_password.cred
ExecStart=/usr/local/bin/myapp

تقرأ الخدمة القيمة من ملف اسمه db_password داخل الدليل الذي يحدده $CREDENTIALS_DIRECTORY. لا توجد القيمة في البيئة، لذلك لا يعرض /proc/<pid>/environ أي معلومات مفيدة، ولا تصل القيمة النصية الصريحة إلى نظام الملفات الجذر.

تحقق من إمكانية فك تشفير الملف قبل ربط وحدة به:

sudo systemd-creds decrypt /etc/myapp/db_password.cred -

اعرف المفتاح الذي شُفِّر به الملف، لأن ذلك يحدد ما إذا كانت نسختك الاحتياطية مفيدة. يستخدم --with-key=auto الافتراضي شريحة TPM2 (وحدة النظام الأساسي الموثوق، الإصدار 2) عند توفرها وإمكانية استخدامها، ويستخدم مفتاح المضيف خلاف ذلك. لا تحتوي معظم مثيلات VPS على TPM2.

systemd-analyze has-tpm2

يعني no استخدام مفتاح المضيف، ويوجد هذا المفتاح في /var/lib/systemd/credential.secret، ولا يمكن قراءته إلا بواسطة root. إذا استعدت db_password.cred إلى VPS جديد من دون ذلك الملف، فلن يتمكن أي شيء من فك تشفيره أبداً. انسخ credential.secret إلى النسخة الاحتياطية نفسها، أو احتفظ بالقيمة النصية الصريحة في مكان لا يزال بإمكانك الوصول إليه.

أسرار Docker: ملفات ضمن /run/secrets

يقرأ Compose ملفاً من المضيف ويحمّله داخل الحاوية في /run/secrets/<name>.

services:
  app:
    image: myapp:latest
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
secrets:
  db_password:
    file: ./db_password.txt

docker compose exec app cat /run/secrets/db_password
docker compose exec app env | grep -i password

يطبع الأمر الأول السر. أما الثاني فيطبع DB_PASSWORD_FILE=/run/secrets/db_password فقط، وهذه هي النقطة الأساسية: لا تظهر القيمة مطلقاً ضمن بيئة الحاوية، لذلك لا تظهر في مخرجات docker inspect. تتوقع كثير من الصور الرسمية هذا الشكل مسبقاً، وتقرأ صورة Postgres POSTGRES_PASSWORD_FILE بهذه الطريقة تحديداً.

وضّح طبيعة هذه الآلية. خارج وضع Swarm، لا يوجد تشفير في أي طبقة: ./db_password.txt ملف نص عادي على المضيف، وحمايته الوحيدة هي وضعه ومالكه. اضبط كليهما بنفسك، لأن Compose سيحمّل ملفاً قابلاً للقراءة من الجميع من دون إصدار تحذير. يوضّح الدليل الخاص بملفات env والأسرار في Compose مجموعة المفاضلات الأوسع مقارنة بالاختصار العادي env_file.

ما التكلفة الفعلية لتشغيل OpenBao وVault

OpenBao هو fork من HashiCorp Vault تحت إشراف Linux Foundation، وقد بدأ بعد أن أعادت HashiCorp ترخيص Vault بموجب Business Source License في 2023. ما يزال OpenBao خاضعاً لترخيص MPL 2.0 (Mozilla Public License). كان الإصدار 2.6.2 هو الإصدار الحالي في أغسطس 2026. ينطبق كل ما يلي تقريباً على Vault أيضاً، لأن fork حافظ على واجهة الأوامر نفسها.

docker pull docker.io/openbao/openbao

تتوفّر حزم Debian وUbuntu في صفحة تنزيلات OpenBao إذا كنت تفضّل أن يتولى apt إدارة التحديثات. يحتاج الخادم إلى ملف إعداد يحتوي على listener وstorage backend:

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/path/to/full-chain.pem"
  tls_key_file  = "/path/to/private-key.pem"
}

storage "raft" {
  path = "/path/to/raft/data"
  node_id = "raft_node_1"
}

ثم شغّله مرة واحدة:

bao operator init

يقسم هذا الإجراء root key افتراضياً إلى 5 حصص، ويتطلب 3 منها لإلغاء القفل، وهما الخياران -key-shares و-key-threshold. يطبع الحصص وinitial root token مرة واحدة فقط، ولا يطبعهما مجدداً.

إليك الجزء الذي تتجاهله معظم المقارنات. الخادم الذي أُعيد تشغيله هو خادم مقفول. يحتفظ OpenBao بـroot key في الذاكرة فقط، لذلك لا يستطيع بعد إعادة التشغيل فك تشفير storage الخاص به إلى أن يزوّده شخص ما بالعدد المطلوب من الحصص. لذلك ينتهي تحديث kernel أو إنهاء العملية بسبب نفاد الذاكرة بخادم مقفول وتطبيقات لا تستطيع تسجيل الدخول.

على VPS يديره شخص واحد، لا يحمي تقسيم Shamir أي شيء، لأن الحصص الخمس تنتهي في password manager نفسه الذي يملكه الشخص نفسه. ينقل Auto unseal المفتاح إلى جهاز أو خدمة موثوقة. في cloud كبير يعني ذلك عادةً خدمة مفاتيح مُدارة، أما على VPS الخاص بك فيعني غالباً ملف مفتاح موجوداً على القرص نفسه الذي يحتوي على البيانات التي يحميها. هذا خفض أمني حقيقي، مقابل خادم يعود إلى العمل تلقائياً بعد إعادة التشغيل. اتخذ هذا القرار عن علم، وسجّل الخيار الذي اتبعته.

Infisical: واجهة، وقاعدة بيانات، ومفتاح رئيسي لا يزال بحوزتك

Infisical منصة لإدارة الأسرار، وتوفّر واجهة ويب ومشروعات وبيئات وعناصر تحكم في الوصول لكل مستخدم. ويكون تشغيلها ذاتياً باستخدام Compose مختصراً:

curl -o docker-compose.prod.yml https://raw.githubusercontent.com/Infisical/infisical/main/docker-compose.prod.yml
curl -o .env https://raw.githubusercontent.com/Infisical/infisical/main/.env.example
docker compose -f docker-compose.prod.yml up -d

عدّل .env قبل تنفيذ الأمر الأخير. يجب أن تكون قيمتان من اختيارك، ويجب ألا تتغير إحداهما بعد ذلك مطلقاً:

openssl rand -hex 16
openssl rand -base64 32

القيمة الأولى هي ENCRYPTION_KEY، وهي سلسلة سداسية عشرية بطول 16 بايت. هذا هو المفتاح الذي تُشفَّر به أسرارك داخل PostgreSQL. لذلك فإن فقدانه يحوّل نسخة احتياطية سليمة تماماً من قاعدة البيانات إلى مجموعة من النصوص المشفّرة، كما أن تغييره على نسخة قيد التشغيل يمنع فك تشفير الأسرار الموجودة. والقيمة الثانية هي AUTH_SECRET، وهي سلسلة base64 بطول 32 بايت تُستخدم للجلسات. يجب أن تكون SITE_URL هي URL المطلق الذي ستصل إليه فعلياً، مع تضمين البروتوكول، وإلا يفشل توجيه تسجيل الدخول.

يناسبك Infisical أكثر من OpenBao عندما تكون حاجتك الفعلية هي إدارة المستخدمين: واجهة ويب لفريق صغير وفصل بين البيئات، بدلاً من بيانات اعتماد قواعد البيانات التي تنتهي صلاحيتها تلقائياً. لكنه يتطلب منك PostgreSQL وRedis وشهادة TLS، وعليك تحديثها جميعاً وإنشاء نسخ احتياطية منها.

ما الذي يحدث عندما تتوقف خدمة الأسرار وتُعاد تشغيل تطبيقك

يحدد هذا السؤال ما إذا كانت خدمة الأسرار مناسبة للتشغيل على خادم واحد. يمكن قراءة الملفات قبل بدء الشبكة. أما الخدمة فلا يمكن ذلك.

أعد تشغيل الخادم، وسيبدأ تطبيقك وOpenBao في اللحظة نفسها. يطلب التطبيق كلمة مرور قاعدة البيانات، بينما لا يزال OpenBao مختوماً، ويفشل الطلب، ثم يعيد systemd تشغيل التطبيق في حلقة متكررة إلى أن يُدخل أحد المسؤولين أجزاء فك الختم يدوياً. لا يوجد عطل فعلي. لكن لا شيء يعمل أيضاً.

هناك طريقتان واضحتان للتعامل مع ذلك. رتّب الوحدات ودَع التطبيق يعيد المحاولة: After= خدمة الأسرار، إضافة إلى Restart=on-failure وRestartSec= بمدة كافية حتى لا ترسل طلبات متكررة إلى API. أو اجلب السر وقت النشر بدلاً من وقت الإقلاع: أنشئ الملف بالسر بصلاحيات mode 600 أو استخدم systemd credential، بحيث يعتمد النظام قيد التشغيل على ملف بدلاً من API.

انتهاء صلاحية الرمز هو المشكلة نفسها، لكن على مقياس زمني أبطأ. تحتوي رموز OpenBao وعقوده على مدة صلاحية، ولذلك يفقد process طويل التشغيل لا يجدّد الرمز وصوله في وقت لا يرتبط بأي عملية نشر. ويصعب تشخيص هذا الفشل تحديداً لأن شيئاً لم يتغير في ذلك اليوم.

نسخ المتجر نفسه احتياطياً

لكل خيار هنا مفتاح، والنسخة الاحتياطية التي لا تتضمن ذلك المفتاح لا قيمة لها. دوّن مكان وجود مفتاحك.

في حالة ملف env، يكون الملف هو السر، لذلك يجب تشفير النسخة الاحتياطية. في SOPS، يمكن وضع الملف المشفّر في أي مكان عام، أما مفتاح age الخاص الموجود في ~/.config/sops/age/keys.txt فهو الشيء الذي يجب ألا تفقده. بالنسبة إلى بيانات اعتماد systemd، انسخ /var/lib/systemd/credential.secret احتياطياً إلى جانب ملفات .cred. في Infisical، أنشئ تفريغاً لقاعدة PostgreSQL وخزّن ENCRYPTION_KEY في مكان منفصل عنه.

يأخذ OpenBao الذي يستخدم تخزين raft لقطة خاصة به:

bao operator raft snapshot save backup.snap
bao operator raft snapshot restore backup.snap

تحتوي اللقطة على التخزين المشفّر، لذلك يتطلب استعادتها إلى خادم جديد أيضاً حصص unseal الموجودة في bao operator init. إن تشغيل مهمة ليلية تنسخ اللقطات إلى تخزين الكائنات، بينما لا تُخزَّن الحصص في أي مكان، لا ينشئ نسخة احتياطية لأي شيء. اختبر الاستعادة على VPS مؤقت قبل الاعتماد عليها.

تدقيق السجلات: من قرأ أي سر

لا تمنحك الملفات مسار تدقيق. يخبرك النمط والمالك بمن يمكنه قراءة السر. لكنهما لا يخبرانك بمن قرأه فعلاً. يُعدّ auditd مع مراقبة المسار أقرب بديل، وهو يبيّن أن ملفاً فُتح، لا القيمة التي استُخدمت.

يسجّل OpenBao كل طلب في جهاز تدقيق تفعّله صراحةً:

bao audit enable file file_path=/var/log/openbao_audit.log

تغيّر حقيقتان في هذا السجل طريقة تشغيل الخادم. تُجزّأ معظم السلاسل النصية في الطلبات والاستجابات باستخدام HMAC-SHA256 وsalt، لذلك يمكنك مطابقة قيمة تعرفها مسبقاً مع السجل من دون أن يحتوي السجل نفسه على نص واضح. أما الأعداد الصحيحة والقيم المنطقية فتُكتب كما هي وبنص واضح، لذلك لا تحصل الأسرار الرقمية على حماية التجزئة هذه.

أما المشكلة التشغيلية، فهي أن OpenBao لن يستجيب للطلبات عندما لا يستطيع أي جهاز تدقيق مفعّل تسجيلها. كما أن تعطل الجهاز بطريقة تمنع المتابعة يجعل الطلبات معلّقة إلى أن يصلح أحدهم المشكلة. امتلاء القرص على /var/log يوقف واجهة API الخاصة بالأسرار عمداً وفق التصميم. خصص مساحة مستقلة لسجل التدقيق وأضف قاعدة logrotate في اليوم الأول، لا بعد أول انقطاع.

ما مدير الأسرار المستضاف ذاتياً الذي ينبغي أن تشغّله؟

أحصِ الأجهزة والأشخاص، ثم اختر.

1. جهاز واحد وشخص واحد: استخدم ملف بيئة بصلاحيات 600 مملوكاً لـroot ويقرأه مستخدم الخدمة. أضف بيانات اعتماد systemd عندما تريد إخراج القيمة من بيئة العملية.
2. جهاز واحد وشخصان إلى خمسة أشخاص، مع وجود الإعدادات مسبقاً في git: استخدم SOPS مع age. يحصل كل شخص على زوج مفاتيح، ويسرد .sops.yaml كل مفتاح عام مسموح له بفك التشفير.
3. عدة أجهزة ومستودع إعدادات واحد، من دون حاجة إلى بيانات اعتماد تنتهي صلاحيتها: استخدم SOPS مع age أيضاً، مع مفتاح مستلم واحد لكل مضيف، بحيث لا يؤدي سرقة مفتاح مضيف إلى فك تشفير إلا ملفات ذلك المضيف.
4. عدة أجهزة وعدة فرق تحتاج فعلياً إلى بيانات اعتماد قاعدة بيانات ذات مدة صلاحية، مع سجل تدقيق يراجعه أحد: استخدم OpenBao، وخصّص في الميزانية ساعة واحدة شهرياً من وقت المشغّل لإجراءات فك الإغلاق وتمارين الاستعادة.

القاعدة الكامنة وراء الخيارات الأربعة واحدة. شغّل أصغر حل يلبّي متطلباً يمكنك وصفه بوضوح، لأن مدير الأسرار المتوقف لا يختلف عن مدير أسرار فارغ.

FAQ

هل يستحق تشغيل مدير أسرار مستضاف ذاتياً على VPS واحد؟

عادةً لا، إذا كنت تقصد خدمة مثل OpenBao أو Infisical. على خادم واحد مع شخص أو شخصين، يوفّر ملف بيئة بصلاحيات mode 600 أو بيانات اعتماد مشفّرة في systemd الحماية نفسها من مستخدم محلي آخر، من دون خطوة unseal أو خدمة إضافية تحتاج إلى تصحيحها. تبدأ خدمة الأسرار في تبرير تكلفتها عندما يكون لديك عدة أجهزة وعدة أشخاص، أو حاجة فعلية إلى بيانات اعتماد تنتهي صلاحيتها من دون أن يدوّرها أحد يدوياً.

ما الفرق بين مدير كلمات المرور ومدير الأسرار؟

يخزّن مدير كلمات المرور بيانات الاعتماد التي يكتبها شخص، ويفتحه مستخدم أثناء وجوده. أما مدير الأسرار فيسلّم بيانات الاعتماد إلى العمليات، لذلك يجب أن يعمل عند الساعة 03:00 من دون أن يراقبه أحد. وهذا هو الفرق العملي بينهما: عندما يكون مدير كلمات المرور مقفلاً، عليك إعادة كتابة كلمة المرور الرئيسية، بينما يوقف مدير الأسرار المختوم كل خدمة تعيد التشغيل أثناء بقائه مختوماً.

ماذا يحدث لتطبيقاتي إذا أصبح OpenBao مختوماً بعد إعادة التشغيل؟

لا يمكنها جلب أسرارها، لذلك تفشل في البدء، ويعيد systemd تشغيلها في حلقة إلى أن يوفّر أحدهم حدّ فك الختم، وهو 3 من أصل 5 حصص افتراضياً. يحتفظ OpenBao بالمفتاح الجذر في الذاكرة فقط، لذلك يعيد كل تشغيل ختمه. يمكنك إما تفعيل auto unseal، مع قبول أن مفتاح فك الختم على VPS واحد سينتهي به المطاف على القرص نفسه الذي توجد عليه البيانات، أو كتابة الأسرار إلى ملف وقت النشر حتى لا يعتمد الإقلاع على API مطلقاً.

هل يمكنني إيداع ملفات SOPS المشفّرة في مستودع عام؟

القيم مشفّرة، لذلك تكون آمنة من أي شخص لا يملك المفتاح الخاص لـ age. أما المفاتيح نفسها فليست مشفّرة: يستطيع القارئ معرفة أنك تملك STRIPE_SECRET_KEY وSMTP_PASSWORD، ومعرفة معدل تغيّر كل منهما. هذه البيانات الوصفية مقبولة في معظم المشاريع وغير مقبولة في مشاريع قليلة. أبقِ المفتاح الخاص لـ age خارج المستودع، وشغّل sops updatekeys على كل ملف موجود كلما أضفت مستلماً أو أزلته.