SOPS
نشط ومستقريعمل محلياً ✓بدون اشتراك APIشفّر قيم ملفات الأسرار مع إبقاء بنيتها قابلة للمراجعة في Git، محليًا عبر age أو عبر KMS.
brew install sopsالاستخدام المثالي لهذه الأداة
مثالي للمطور أو فريق المنصة الصغير الذي يريد حفظ إعدادات مشفرة بجانب الشيفرة مع فرق Git واضحة. استخدمه لملفات YAML وJSON وENV وINI ولتشغيل أو CI مضبوط الصلاحيات. لا تستخدمه بدل خزنة أسرار ديناميكية أو تدوير كلمات المرور في الأنظمة المصدر.
التفاصيل والميزات المصورة
عندما تحتاج إلى حفظ مفاتيح API أو كلمات مرور قواعد البيانات مع إعدادات المشروع، يصبح الاختيار بين ملف واضح خطير وخزنة منفصلة ثقيلة على الفريق الصغير قرارًا مزعجًا. SOPS يحل جزءًا محددًا من هذه المشكلة: يشفّر قيم ملفات YAML وJSON وENV وINI مع إبقاء بنية الملف قابلة للقراءة والمراجعة في Git، ثم يفكها فقط لمن يملك هوية age أو صلاحية KMS المناسبة.
🧭 ما SOPS، وكيف ستستخدمه؟
SOPS هو محرر وCLI مفتوح المصدر لملفات الأسرار المشفرة. بدأ في Mozilla، وأصبح مشروع CNCF Sandbox تحت صيانة مجموعة getsops. لا يستضيف أسرارك في خدمة جديدة؛ بل يقرأ الملف محليًا، ينشئ مفتاح بيانات عشوائيًا، يشفّر القيم، ثم يغلّف مفتاح البيانات بهوية أو أكثر من age أو PGP أو AWS KMS أو GCP KMS أو Azure Key Vault أو HuaweiCloud KMS. توجد كذلك تكاملات موثقة مع Vault Transit.
الاستخدام المعتاد بسيط في فكرته: تحتفظ بملف مثل secrets.sops.yaml داخل المستودع، وتحتفظ بالمفتاح الخاص أو صلاحية KMS خارجه. يستطيع المطور المخوّل تحرير الملف عبر sops secrets.sops.yaml، ويمكن لخط CI أو التطبيق استهلاك القيم عبر exec-env أو exec-file دون حفظ نسخة واضحة دائمة قدر الإمكان.
هذه ليست خزنة أسرار ديناميكية، ولا مديرًا لدورة حياة كلمات المرور. SOPS لا ينشئ كلمة مرور قاعدة البيانات، ولا يبدلها في المزود، ولا يلغي الحاجة إلى IAM أو النسخ الاحتياطي للمفاتيح؛ إنه طبقة تشفير ملفات مصممة لتعمل جيدًا مع Git.

🎯 الاستخدام المثالي والقيمة المضافة
يناسب SOPS المطور الفرد أو فريق المنصة الصغير الذي يريد إبقاء إعدادات البيئات بجانب الشيفرة مع تقليل خطر ظهور القيم الحساسة في المستودع. استخدمه لملفات إعداد Kubernetes أو Terraform، إعدادات تطبيق صغير، أسرار CI، أو قيم بيئات التطوير والتجربة والإنتاج عندما تحتاج فرق Git قابلة للفهم.
قيمته المضافة هي أن المراجع يرى أن مفتاحًا مثل database_password تغير، دون أن يرى القيمة نفسها. ويمكن استخدام أكثر من هوية للوصول، أو فصل مفاتيح التطوير عن الإنتاج بقواعد .sops.yaml. كما يعمل محليًا باستخدام age بلا حساب سحابي أو API مدفوع.
لا تختَره إذا كنت تحتاج أسرارًا قصيرة العمر تُصدر لحظة الطلب، أو تدقيق وصول مركزيًا مفصلًا، أو تدويرًا آليًا لكلمات المرور في الأنظمة المصدر. في هذه الحالات تحتاج Vault أو Secret Manager أو خدمة مشابهة، وقد تستخدم SOPS فقط كجزء من المسار.
🔐 كيف يعمل التشفير المغلف؟
ينشئ SOPS مفتاح بيانات عشوائيًا بطول 256 بت لكل ملف. تُشفّر قيم شجرة البيانات باستخدام AES-256-GCM، ثم يُشفّر مفتاح البيانات نفسه بكل مفتاح رئيسي مسجل في الملف. لهذا يمكن تغيير مستلمي الوصول من دون إعادة تصميم صيغة الملف.
تبقى أسماء الحقول والبنية غير مشفرة في الملفات المنظمة، وهذا ما يجعل فرق Git مفهومة. لا تضع سرًا في اسم المفتاح أو تعليق واضح. يحمي MAC الشجرة من العبث، وتسمح الإعدادات المتقدمة بتشفير جزء فقط من الملف، لكن التشفير الجزئي يزيد مساحة الخطأ؛ ابدأ بتشفير القيم كلها ما لم تكن لديك حاجة موثقة.
افتراضيًا تكفي هوية رئيسية صالحة واحدة لفك مفتاح البيانات. إذا كان المطلوب موافقة أكثر من جهة، استخدم key groups مع Shamir Secret Sharing وحدد shamir_threshold. لا تفترض أن إضافة مفاتيح متعددة وحدها تعني أن جميعها مطلوبة.

🧩 قواعد .sops.yaml وفصل البيئات
يبحث SOPS عن ملف اسمه بالضبط .sops.yaml في المجلد الحالي ثم المجلدات الأعلى. يحتوي الملف على creation_rules تستطيع مطابقة المسار عبر path_regex واختيار هوية age أو مفتاح KMS المناسب لكل مجموعة ملفات.
مثال مبسط:
creation_rules:
- path_regex: config/dev/.*
age: age1example_dev_recipient
- path_regex: config/prod/.*
kms: arn:aws:kms:REGION:ACCOUNT:key/KEY_ID
ضع ملف القواعد في جذر المستودع وراجعه كسياسة وصول. اختبر إنشاء ملف لكل مسار، لأن قاعدة عامة موضوعة أولًا قد تلتقط ملفًا كان يجب أن يستخدم مفتاح الإنتاج. لا تنس أن معرفات المفاتيح العامة وبيانات SOPS الوصفية ستظهر في الملف؛ السر يجب أن يبقى في المفتاح الخاص أو داخل حدود مزود KMS.

🪜 مثال عملي محلي باستخدام age
ابدأ بمشروع تجريبي لا يحتوي أسرارًا حقيقية:
- ثبّت SOPS، وثبّت
ageمن مدير حزم نظامك. - أنشئ هوية:
age-keygen -o age-key.txt. - انسخ المستلم العام الذي يبدأ بـ
age1إلى.sops.yaml. - ضع المفتاح الخاص في مسار هوية SOPS الموثق لنظامك أو استخدم
SOPS_AGE_KEY_FILEفي جلسة آمنة. - أنشئ
secrets.yamlبقيم وهمية فقط. - نفّذ
sops encrypt --in-place secrets.yaml. - افتح الملف وتأكد أن القيم مشفرة وأن أسماء الحقول فقط ظاهرة.
- نفّذ
sops decrypt secrets.yamlللتحقق، ثم احذف أي مخرج واضح فورًا. - أعد تسمية الملف إلى
secrets.sops.yamlوأضفه إلى Git، مع قاعدة تمنع ملفات الأسرار الواضحة. - اختبر الاستهلاك عبر
sops exec-env secrets.sops.yaml 'your-command'.
brew install sops
sops --version
sops encrypt --in-place secrets.yaml
sops exec-env secrets.yaml 'your-command'
أمر Homebrew موثق لـ macOS وLinux، بينما توفر صفحة الإصدارات حزمًا تنفيذية لـ Windows وLinux وmacOS. لم ننفذ هذا المثال في خادم الموقع، ولا ينبغي استخدام قيم إنتاج قبل اختبار الاستعادة والنسخ الاحتياطي للمفتاح.

⚙️ تمرير الأسرار إلى التطبيق
الأمر exec-env يفك القيم إلى متغيرات بيئة لعملية فرعية. أما exec-file فينشئ FIFO افتراضيًا على Unix ويستبدل {} بمساره في الأمر. هذا يقلل بقاء ملف واضح على القرص، لكنه لا يجعل السر غير مرئي تمامًا: قد يستطيع البرنامج الفرعي طباعته، وقد تظهر متغيرات البيئة في أدوات فحص العمليات وفق النظام والصلاحيات.
على Windows أو عندما لا يناسب FIFO التطبيق، يمكن استخدام --no-fifo، وعندها يستخدم SOPS ملفًا مؤقتًا ويحذفه بعد انتهاء العملية. افحص سلوك التطبيق عند الانهيار، ولا تمرر أمرًا غير موثوق إلى shell. خيار --user يستطيع إسقاط الصلاحيات قبل تشغيل العملية على الأنظمة المدعومة.

🔄 إدارة المفاتيح والتدوير
توصي الوثائق باستخدام updatekeys لمزامنة مفاتيح الملف مع .sops.yaml. عند إزالة مفتاح مخترق، الترتيب مهم:
sops updatekeys secret.sops.yaml
sops rotate --in-place secret.sops.yaml
أولًا أزل المفتاح من القواعد وحدّث بيانات المستلمين، ثم دوّر مفتاح بيانات الملف، ثم التزم بالتغيير. بعد ذلك فقط غيّر كلمات المرور ومفاتيح API الفعلية في الأنظمة المصدر. تدوير مفتاح البيانات لا يغيّر كلمة مرور قاعدة البيانات؛ ورفع ملف جديد لا يلغي نسخة قديمة يستطيع صاحب مفتاح سابق فكها.
جرّب الاستعادة قبل إلغاء آخر مفتاح صالح، واحتفظ بنسخة احتياطية مشفرة من هوية age أو آلية كسر زجاج مناسبة. مع KMS، راجع سياسات الحذف والتعطيل والسجلات والتكلفة في المزود.

⚖️ مقارنة بالعمل اليدوي
| المهمة | ملف واضح أو تشفير يدوي | مع SOPS |
|---|---|---|
| مراجعة تغيّر الإعدادات | قد يظهر السر أو يصعب فهم كتلة مشفرة كاملة | تبقى المفاتيح والبنية قابلة للمراجعة |
| مشاركة الوصول | نسخ كلمة مرور أو مفتاح ملف يدويًا | إضافة مستلم age أو صلاحية KMS |
| فصل البيئات | تعليمات بشرية ومجلدات منفصلة | قواعد path_regex قابلة للمراجعة |
| تشغيل التطبيق | فك ملف واضح ثم حذفه يدويًا | exec-env أو exec-file |
| تدوير مفتاح التشفير | إعادة تشفير يدوية معرضة للخطأ | updatekeys ثم rotate |
| أسرار ديناميكية وتدوير المصدر | غير متوفر | غير متوفر؛ تحتاج نظام أسرار آخر |
SOPS يقلل العمل اليدوي ولا يلغي المسؤولية التشغيلية. نجاحه يعتمد على حفظ المفتاح الخاص بعيدًا عن المستودع، ومنع التسريب في السجلات، ومراجعة سياسات CI.
💻 التوافق والإصدار والتكلفة
أحدث إصدار مستقر تحققنا منه هو 3.13.3 بتاريخ 23 يوليو 2026. توفر صفحة الإصدار ملفات لـ Windows وLinux وmacOS، وصور حاويات لمعمارية amd64 وarm64، مع توقيعات وبيانات provenance موثقة. بناء فرع التطوير من المصدر يتطلب Go 1.25 فأحدث وفق صفحة التثبيت؛ تشغيل الملف التنفيذي الجاهز لا يتطلب Go.
المستودع مرخص بـ MPL-2.0. يستطيع الفرد تشغيل SOPS وage محليًا مجانًا ومن دون API مدفوع. استخدام AWS/GCP/Azure/Huawei KMS أو Vault قد يتطلب اتصالًا، حسابًا، صلاحيات، ورسوم مزود. وقت الفحص أظهر GitHub نحو 23.6 ألف نجمة و1.1 ألف تفرع، وآخر التزام ظاهر على main بتاريخ 27 أكتوبر 2026. هذه مؤشرات نشاط لحظية وليست تقييم جودة.
🛡️ الخصوصية والصلاحيات والأمان
SOPS محلي في مسار age وPGP؛ لا يرسل الملف إلى خدمة SOPS. مع KMS، تُرسل عمليات تغليف/فك مفتاح البيانات إلى المزود وفق SDK واعتماداته. امنح حساب CI أقل صلاحيات ممكنة، وافصل مفاتيح الإنتاج عن التطوير، واستخدم شروط KMS أو encryption context عندما يناسب التصميم.
احذر من:
- طباعة
sops decryptإلى الطرفية أو إعادة توجيهه إلى ملف يبقى في workspace. - تخزين مفتاح
ageالخاص أو اعتماد سحابي بجانب الملف المشفر. - اعتبار أسماء الحقول سرية؛ هي ظاهرة.
- قبول طلبات Pull Request غير موثوقة في job يملك مفاتيح فك الإنتاج.
- استخدام key service بعيد مباشرة؛ توضح الوثائق أن الاتصال لا يوفر مصادقة أو تشفيرًا بذاته، لذا مرّره عبر SSH أو قناة آمنة.
- الاعتقاد أن تشفير الملف يزيل السر من تاريخ Git إذا سبق التزام نسخة واضحة؛ عالج الحادث ودوّر السر.
- افتراض أن تعدد المفاتيح يفرض موافقة متعددة؛ استخدم key groups وعتبة Shamir صراحة.

⚠️ القيود ومتى لا تستخدمه
- لا يخزن الأسرار في خادم مركزي ولا يصدرها عند الطلب.
- لا يدوّر كلمة المرور أو مفتاح API في النظام المصدر.
- يعتمد الأمان على هوية
ageأو PGP أو IAM/KMS؛ فقدانها قد يعني فقدان الوصول. - الملفات الثنائية مدعومة، لكن فرق Git لن يكون غنيًا كما في YAML أو JSON.
- التشفير الجزئي و
mac_only_encryptedخيارات متقدمة قد تضعف توقعات الحماية إذا أسيء إعدادها. - بيئة shell والسجلات والعمليات الفرعية قد تكشف النص بعد فكّه.
- لا يوجد حاجز أمني يمنع محررًا مخولًا من نسخ السر بعد فكّه.
- لم نثبت SOPS أو ننفذ المثال أو نجري تدقيقًا أمنيًا مستقلًا.
🔎 لماذا اخترناه اليوم؟
قارنّا SOPS من مجال الأمن والخصوصية مع Lightpanda Browser من مجال أتمتة المتصفح. Lightpanda واعد وخفيف ومفتوح المصدر، لكنه يعتمد حاليًا على nightly builds ومسار منتج أحدث. SOPS يقدم قيمة مستقرة أوضح لفرد أو فريق صغير، ويمثل مجالًا مختلفًا عن بطاقة Docmost السابقة. راجعنا أيضًا claudeskills.info وdshmarket.com؛ لم نختر أداة DSH التزامًا بالأولوية الحالية خارج DSH.
📚 المصادر وتاريخ التحقق
تم التحقق في 3 نوفمبر 2026 من المصادر الأصلية:
- مستودع SOPS الرسمي — الترخيص والنشاط والنجوم والتفرعات.
- توثيق SOPS الرسمي — الصيغ ومزودو المفاتيح وخلفية المشروع.
- الإصدار 3.13.3 — النسخة والتاريخ والملفات والتوقيع.
- التثبيت وصيغة Homebrew — طرق التثبيت والأمر.
- مرجع الإعداد —
.sops.yamlوالقواعد والتشفير الجزئي. - هويات age ومجموعات المفاتيح — المستلمون وعتبة Shamir.
- إدارة المفاتيح —
updatekeysوrotateوترتيب الاستجابة للاختراق. - الاستخدام المتقدم —
exec-envوexec-fileوخدمة المفاتيح.