Code signing leverages public key infrastructure (PKI) to serve as your software’s digital passport. Through digital signatures, it creates cryptographic proof of authenticity and integrity. فهو يصادق عليك بصفتك الناشر ويضمن سلامة الشيفرة البرمجية من خلال إثبات عدم التلاعب بشيفرتك البرمجية منذ إصدارها.
عندما يقوم المستخدمون بتنزيل برنامجك، فإنهم يأتمنونك على أمان نظامهم. قم بكسر هذه الثقة مرة واحدة، وسينتهي أمرك.
جدول المحتويات
- حماية المفاتيح الخاصة باستخدام وحدات أمان الأجهزة
- تنفيذ ضوابط وصول صارمة لمفاتيح توقيع الأكواد البرمجية
- ختم الوقت الخاص بك أثناء عملية التوقيع
- فصل بيئات توقيع الاختبار عن بيئات توقيع الإصدار
- تنفيذ توثيق الرمز والتحقق من النزاهة قبل التوقيع
- إجراء فحص للفيروسات على التعليمات البرمجية قبل التوقيع
- تدوير المفاتيح واستخدام شهادات متعددة
- أخذ إبطال الشهادات على محمل الجد
- الاستفادة من شهادات توقيع رمز التحقق من الصحة الموسعة
- أتمتة إدارة توقيع الأكواد البرمجية ومركزيتها
- تأمين سلسلة توريد البرمجيات الخاصة بك باستخدام SSL Dragon
أصبحت المخاطر حقيقية بعد أن كشف اختراق SolarWinds عن ثغرات خطيرة في سلسلة توريد البرمجيات، مما يوضح كيف يمكن لمفاتيح التوقيع المخترقة أن تستخدم تحديثات البرامج الشرعية كسلاح وتهدد آلاف المؤسسات. الآن أكثر من أي وقت مضى، لم يعد اتباع أفضل ممارسات توقيع الأكواد البرمجية أمرًا اختياريًا، بل هو أمر أساسي لحماية المستخدمين وسمعتك.
أصبحت حماية سلسلة توريد البرمجيات أولوية قصوى للمؤسسات من جميع الأحجام. ستساعدك هذه الإرشادات على تنفيذ تدابير الأمان المهمة، سواء كنت مطورًا منفردًا أو تدير خطوط أنابيب DevOps للمؤسسة. سواء كنت تقوم بتوقيع الملفات التنفيذية لنظام التشغيل Windows أو تطبيقات macOS أو حزم Linux أو تطبيقات الأجهزة المحمولة لنظامي iOS وAndroid، فإن هذه المبادئ تنطبق على جميع الأنظمة الأساسية.
حماية المفاتيح الخاصة باستخدام وحدات أمان الأجهزة
مفتاحك المفتاح الخاص هو كل شيء في توقيع الشيفرات البرمجية. إذا تم اختراقه، يمكن للمهاجمين توقيع البرمجيات الخبيثة بهويتك. يتم إبطال شهادتك، ويفقد عملاؤك ثقتهم، وتتعرض علامتك التجارية لضربة قد لا يمكنك التعافي منها.
لماذا يعد أمان المفتاح الخاص أمرًا بالغ الأهمية
فكّر في مفتاحك الخاص على أنه المفتاح الرئيسي لمصداقية برنامجك – فهو يُنشئ التوقيعات الرقمية التي تثبت هويتك. إذا سرقه شخص ما، فيمكنه توزيع تعليمات برمجية خبيثة تبدو وكأنها صادرة منك. ستحتاج إلى إبطال شهادتك، وإعادة توقيع كل ما قمت بإصداره، وتأمل أن يلاحظ عملاؤك الفرق قبل تثبيت البرامج المصابة.
النهج التقليدي لتخزين المفاتيح على محركات الأقراص الصلبة أو خوادم الإنشاءات هو أمرٌ ينطوي على مشاكل. يتم اختراق أجهزة المطورين. يتم اختراق خوادم الإنشاء. حتى التخزين المشفر على الأجهزة العادية يترك المفاتيح عرضة للاختراق.
حلول الأجهزة المعتمدة من FIPS 140-2 المعتمدة من FIPS 140-2
تعمل وحدات أمان الأجهزة (HSMs) على حل هذه المشكلة من خلال تخزين المفاتيح الخاصة في أجهزة مقاومة للتلاعب. وباعتبارها حجر الزاوية للبنية الأساسية لمرفق المفاتيح العمومية (PKI)، توفر وحدات أمن الأجهزة (HSM) أساس الأمان الذي تتطلبه الثقة القائمة على الشهادة. تقوم هذه الأجهزة بإنشاء المفاتيح واستخدامها داخلياً دون تعريضها للنظام الخاص بك. حاول العبث فعلياً بأداة HSM، وستقوم بتدمير المفاتيح.
شهادة FIPS 140-2 مهمة هنا. يتطلب المستوى 2 دليل تلاعب مادي، في حين أن المستوى 3 يضيف استجابة نشطة للتلاعب تُلغي المفاتيح عندما يحاول شخص ما اقتحامها. بالنسبة لمعظم المؤسسات، يوفر المستوى 2 حماية قوية. تتكامل حلول الأجهزة هذه بسلاسة مع بيئات تطوير أنظمة ويندوز وماك ولينكس، مما يحمي مفاتيحك بغض النظر عن منصة الإنشاء الخاصة بك. يجب أن تأخذ التطبيقات الحكومية والتطبيقات عالية الأمان بعين الاعتبار المستوى 3.
توفر توكنات USB بديلاً محمولاً لإدارة الأمن المنزلي (HSM). وهي عبارة عن أجهزة تشفير معتمدة من FIPS يمكنك حملها معك، مما يضيف أمانًا ماديًا من خلال الحيازة. تدعم مراجع الشهادات الرئيسية كلاً من تطبيقات HSM ورموز USB الرمزية لتوقيع الشهادات المشفرة.
ومع ذلك، تختلف سياسات المرجع المصدق (CA)، وتحتاج إلى التخطيط لها. تقوم DigiCert وGoGetSSL بإصدار شهادات توقيع الرمز لمدة عام واحد فقط، ويمكنك استخدام إما HSM مقدم من المرجع المصدق (CA) أو أجهزتك الخاصة.
يقدم Sectigo (Comodo) شهادات متعددة السنوات تصل إلى 3 سنوات، ولكن بقواعد أكثر صرامة. إذا اخترت شهادة لمدة سنتين أو 3 سنوات، يجب عليك استخدام جهاز HSM الخاص بك. الأجهزة المقدمة من CA متاحة فقط للطلبات التي مدتها عام واحد.
هل تريد توقيع الرمز؟ أنت بحاجة إلى الرمز المميز. لا رمز مميز، لا توقيع – حتى لو قام شخص ما باختراق شبكتك بالكامل.
تنفيذ ضوابط وصول صارمة لمفاتيح توقيع الأكواد البرمجية
لا يحتاج كل فرد في فريقك إلى الوصول إلى مفاتيح توقيع الإنتاج. في الواقع، لا ينبغي أن يمتلكها معظم الأشخاص.
المبدأ بسيط: عدد أقل من الأشخاص الذين لديهم حق الوصول يعني عددًا أقل من ناقلات الهجوم. قم بإعداد التحكم في الوصول المستند إلى الأدوار (RBAC) الذي يحد من أذونات التوقيع لأدوار محددة. لا يحتاج فريق ضمان الجودة لديك إلى الوصول إلى توقيع الإنتاج. ربما لا يحتاج المطورون المبتدئون لديك أيضًا.
إنشاء مهام سير عمل الموافقة التي تتطلب توقيعات متعددة لإصدارات الإنتاج. يقوم شخص ما بتقديم التعليمات البرمجية للتوقيع، ثم يقوم شخص آخر بالموافقة عليها، وعندها فقط يتم التوقيع الفعلي. هذا الفصل بين الواجبات يكشف الأخطاء ويمنع التهديدات الداخلية.
احتفظ بسجلات تدقيق شاملة. سجل من قام بالتوقيع على ماذا، ومتى قام بالتوقيع، ومن أي نظام. تؤكد الورقة البيضاء لأفضل ممارسات توقيع الأكواد البرمجية الصادرة عن مجلس أمن CA على أن التسجيل المفصل ضروري للاستجابة للحوادث والتحقيق الجنائي. عندما يحدث خطأ ما – وفي النهاية يحدث شيء ما دائماً – فأنت بحاجة إلى معرفة ما حدث بالضبط.
الأمن المادي مهم أيضاً:
- لا تترك رموز USB على المكاتب.
- لا تخزن بيانات اعتماد الوصول إلى HSM في ملفات نصية عادية.
- لا تكتب رموز PIN على ملاحظات لاصقة.
تبدو هذه المشاكل واضحة، لكنها مشاكل شائعة تقوض الأمن القوي.
ختم الوقت الخاص بك أثناء عملية التوقيع
إليك المشكلة: تنتهي صلاحية شهادات توقيع الكودات، عادةً بعد سنة إلى ثلاث سنوات. بدون ختم الوقت، يصبح توقيعك غير صالح عند انتهاء صلاحية شهادتك. يبدأ المستخدمون برؤية رسائل تحذيرية حول البرامج غير الموثوق بها، على الرغم من أنه لم يتغير شيء في شفرتك البرمجية.
يعمل الختم الزمني على إصلاح هذا الأمر عن طريق إضافة طابع زمني موثوق به من خادم الطابع الزمني للمرجع المصدق أثناء عملية التوقيع. يثبت الطابع الزمني هذا أنك وقعت على الرمز بينما كانت شهادتك لا تزال صالحة. يبقى التوقيع موثوقاً به حتى بعد انتهاء صلاحية شهادتك أو إبطالها.
فكر في الأمر على أنه ختم كاتب العدل مع التاريخ. قد يتقاعد كاتب العدل أو يغلق محله، لكن ختمه على مستندك من عام 2020 لا يزال يثبت أن المستند كان موجودًا وتم التحقق منه في عام 2020.
العملية التقنية واضحة ومباشرة. أثناء التوقيع، تقوم أداتك بالاتصال بخادم الطابع الزمني الذي يديره المرجع المصدق الخاص بك. يُرجع الخادم طابعًا زمنيًا موقّعًا يتم تضمينه في توقيع الكود الخاص بك. عندما يقوم المستخدمون بالتحقق من توقيعك على أي نظام أساسي – Windows أو macOS أو Linux أو iOS أو Android – فإنهم يتحققون من شهادة التوقيع والطابع الزمني. تحافظ عملية التحقق هذه على سلامة التعليمات البرمجية مع مرور الوقت، حتى مع انتهاء صلاحية الشهادات وتطور معايير الأمان.
هذا يوفر المال أيضاً. بدون الختم الزمني، ستحتاج إلى إعادة توقيع جميع برامجك الموزعة في كل مرة تقوم فيها بتجديد شهادتك. مع ختم الوقت، تظل الإصدارات القديمة موثوقة إلى أجل غير مسمى.
وفر 10% على شهادات SSL عند الطلب من SSL Dragon اليوم!
إصدار سريع، وتشفير قوي، وثقة في المتصفح بنسبة 99.99%، ودعم مخصص، وضمان استرداد المال خلال 25 يومًا. رمز القسيمة: SAVE10
فصل بيئات توقيع الاختبار عن بيئات توقيع الإصدار
يجب ألا تستخدم بيئة الاختبار الخاصة بك نفس مفاتيح التوقيع مثل الإنتاج. على الإطلاق.
يجب أن تكون شهادات الاختبار إما موقعة ذاتياً أو صادرة عن مرجع شهادة اختبار داخلي يرتبط بجذر مختلف عن شهادات الإنتاج. يحول هذا الفصل المعماري دون الخلط بين التعليمات البرمجية الموقعة للاختبار والبرمجيات الجاهزة للإصدار.
قم بإعداد بنية تحتية منفصلة للتوقيع لكل بيئة. يمكن أن يكون توقيع الاختبار الخاص بك أكثر سهولة وأقل تقييدًا – يحتاج المطورون إلى التكرار بسرعة. ولكن يجب أن يكون توقيع الإنتاج محكم الإغلاق مع جميع التدابير الأمنية التي ناقشناها.
ضع علامة واضحة على حزم الاختبار. قم بتضمين “اختبار” أو “BETA” في أسماء الملفات. استخدم معرّفات منتجات مختلفة. اجعل من المستحيل توزيع التعليمات البرمجية الموقعة اختباريًا على العملاء عن طريق الخطأ.
يجب أن تختلف ضوابط الوصول بشكل كبير أيضًا. قد يكون للمطورين حق الوصول المباشر إلى توقيع الاختبار. يجب أن يتطلب توقيع الإنتاج تدفقات عمل الموافقة وربما بيانات اعتماد مختلفة تمامًا.
تنفيذ توثيق الرمز والتحقق من النزاهة قبل التوقيع
يوفر توقيع التعليمات البرمجية مصادقة التعليمات البرمجية – تأكيد من قام بنشر البرنامج. ولا يؤكد أن البرنامج آمن.
هذا التمييز مهم لأنك مسؤول في النهاية عن كل ما توقع عليه، حتى لو لم تقم بكتابته كله. إن التوقيع على رمز لم تتحقق من صحته يشبه التوقيع على قرض دون التحقق من الشؤون المالية للمقترض.
تنفيذ عمليات التقديم والموافقة قبل التوقيع على أي شيء. اطلب من شخص ما مراجعة ما يتم توقيعه. قارن التعليمات البرمجية على خادم الإنشاء الخاص بك مع مستودع التعليمات البرمجية المصدرية. تأكد من تطابقهما تمامًا.
علّمنا اختراق SolarWinds أن المهاجمين يمكنهم حقن تعليمات برمجية خبيثة في خطوط أنابيب الإنشاء. وقد سلط هذا الهجوم الضوء على أهمية أمن سلسلة توريد البرمجيات – فكل مكون وتبعية وخطوة بناء تمثل ناقل هجوم محتمل. إذا قمت بالتوقيع دون التحقق، فأنت تثق بكل جزء من بنيتك التحتية وكل جزء من التعليمات البرمجية من مصادر خارجية. وهذا ليس رهاناً تريد القيام به.
قم بإعداد فحوصات آلية حيثما أمكن. تحقق من التواقيع الرقمية على التعليمات البرمجية التي يسجلها المطورون في مستودعك. قم بتشغيل أدوات التحليل الثابت. إنشاء المجاميع الاختبارية للبنيات المعتمدة والتحقق منها قبل التوقيع.
سجل كل شيء. عندما يقوم شخص ما بإرسال رمز ما للتوقيع، قم بتسجيل ما تم إرساله ومن أرسله ومن وافق عليه وما تم توقيعه. تصبح مسارات التدقيق هذه حاسمة عند التحقيق في الحوادث.
إجراء فحص للفيروسات على التعليمات البرمجية قبل التوقيع
توقيع الكود يثبت أنك نشرت البرنامج. يثق المستخدمون في أنك لم تنشر برمجيات خبيثة، لكن شهادات توقيع الكود لا تثبت الأمان.
هذا الأمر مهم عندما تدمج شيفرة من مصادر خارجية – مكتبات مفتوحة المصدر، ومكونات الطرف الثالث، ومساهمات المقاول. أنت توقع كل ذلك باسمك.
افحص كل شيء قبل التوقيع. استخدم محركات متعددة لمكافحة الفيروسات إن أمكن. تحقق من توقيعات البرامج الضارة المعروفة والأنماط المشبوهة والثغرات المحتملة. ينطبق هذا سواء كنت تقوم بإعداد ملفات Windows التنفيذية، أو تطبيقات macOS، أو حزم Linux، أو تطبيقات الهاتف المحمول لنظامي iOS و Android.
إن اكتشاف الإدراج الخبيث غير المقصود قبل التوقيع يحمي المستخدمين وسمعتك. أما العثور عليه بعد أن تقوم بتوزيع البرمجيات الخبيثة الموقّعة فيعني إلغاء الشهادة وإشعار العميل والسيطرة على الضرر.
يضيف المسح الضوئي الحد الأدنى من الوقت إلى عملية الإنشاء الخاصة بك ولكنه يوفر حماية أساسية لسلامة الكود وأصالته. اجعله إلزامياً وليس اختيارياً.
تدوير المفاتيح واستخدام شهادات متعددة
لا تضع كل بيضك في سلة واحدة. استخدام شهادة توقيع رمز واحد لكل شيء يخلق نقطة فشل واحدة.
ضع في اعتبارك استخدام شهادات مختلفة لخطوط إنتاج مختلفة أو إصدارات رئيسية مختلفة. إذا اكتشفت ثغرة أمنية في كيفية إدارة إحدى الشهادات، فما عليك سوى إبطال تلك الشهادة المحددة. تبقى منتجاتك الأخرى موثوقة.
كما أن تدوير المفاتيح بانتظام يحد من التعرض للخطر أيضًا. إذا قام شخص ما باختراق مفتاحك قبل ستة أشهر ولكنك قمت بالتدوير منذ ذلك الحين إلى شهادة جديدة، فلن يتمكن من توقيع التعليمات البرمجية الحالية باسمك. يتم احتواء الضرر على الإصدارات القديمة.
تقوم بعض المؤسسات بتعيين شهادات فريدة لفرق DevOps أو فروع الإصدار المختلفة. هذا يوزع المخاطر ويجعل التحقيق في الاختراق أسهل. عندما يحدث خطأ ما، فإنك تعرف بالضبط أي شهادة كانت متورطة وأي الإصدارات تأثرت.
قم بإعداد جدول تناوب يوازن بين الأمن والنفقات التشغيلية العامة. يصلح التناوب السنوي أو نصف السنوي للعديد من المؤسسات. قد يتم التناوب في البيئات عالية الأمان كل ثلاثة أشهر.
أخذ إبطال الشهادات على محمل الجد
إلغاء الشهادة هو الخيار النووي، ولكنه ضروري في بعض الأحيان.
قم بالإبطال فوراً إذا تم اختراق مفتاحك الخاص. لا تنتظر تقييم الضرر. لا تأمل ألا يلاحظ أحد. قم بالإبطال، وأبلغ المرجع المصدق لديك، وابدأ الاحتواء.
يؤثر الإبطال على جميع التعليمات البرمجية الموقعة بتلك الشهادة. سيرى المستخدمون تحذيرات. قد تمنع الأنظمة الآلية التثبيت. هذا هو السبب في أن الختم الزمني أمر بالغ الأهمية – فهو يحد من الضرر الذي يلحق بالشيفرة الموقعة بعد الطابع الزمني ولكن قبل الإبطال.
تتبع شهاداتك بعناية داخل البنية الأساسية لمرفق المفاتيح العمومية لديك. اعرف مكان وجودها، ومن لديه حق الوصول إليها، ومتى تنتهي صلاحيتها، وما هي التعليمات البرمجية التي وقّعت عليها. تصبح إدارة دورة حياة الشهادات أمرًا بالغ الأهمية كلما قمت بتوسيع نطاق عملك.
قم بالإبلاغ عن الاختراقات إلى سلطة التصديق الخاصة بك وفقًا لإجراءاتهم. سيساعدونك في الإلغاء وقد يكون لديهم إرشادات بشأن متطلبات الإخطار.
وجود خطة إبطال قبل أن تحتاج إليها يجعل العملية أقل فوضوية. قم بتوثيق الخطوات وتعيين المسؤوليات والتدرب على الإجراء.
الاستفادة من شهادات توقيع رمز التحقق من الصحة الموسعة
شهادات توقيع الرمز الموسع للتحقق من الصحة (EV) هي شهادات رقمية من نوع X.509 توفر ضماناً أعلى من الشهادات القياسية. يقوم المرجع المصدق بإجراء تحقق أكثر صرامة من الهوية قبل إصدارها.
تتطلب شهادات EV تخزين الأجهزة التي تلبي معايير FIPS 140-2 المستوى 2 أو أعلى. لا يمكنك الحصول على شهادة EV وتخزينها على قرصك الصلب. تقلل هذه الحماية الإلزامية للأجهزة من مخاطر اختراق المفتاح.
تأتي معظم شهادات EV على رموز USB مع حماية برقم تعريف شخصي. تحتاج إلى كل من الرمز المميز الفعلي ورقم التعريف الشخصي لتوقيع الرمز. هذا النهج ذو العاملين يجعل التوقيع غير المصرح به أكثر صعوبة.
وجدت الأبحاث التي أجراها مختبر الابتكار في الطب الشرعي السيبراني التابع لجامعة جورجيا للتكنولوجيا أن الملفات التنفيذية الموقّعة بتوقيع EV قاومت 99.99% من هجمات التصيد الاحتيالي التي تم اختبارها، مقارنةً بنسبة 90% للتوقيعات القياسية. تتعرف أنظمة التشغيل، بما في ذلك ويندوز وماك أو إس ومنصات الأجهزة المحمولة مثل iOS وأندرويد، على توقيعات EV وتعرض مؤشرات ثقة محسّنة للمستخدمين. تُحدث مؤشرات الثقة المحسّنة والتدقيق الصارم فرقاً قابلاً للقياس.
اختر شهادات EV عندما تحتاج إلى أقصى قدر من الثقة – المنتجات الرائدة أو البرامج الموزعة على نطاق واسع أو التطبيقات التي تتعامل مع البيانات الحساسة. التكلفة الإضافية والنفقات الإدارية الإضافية تؤتي ثمارها في تعزيز المصداقية والأمان.
أتمتة إدارة توقيع الأكواد البرمجية ومركزيتها
لا يمكن توسيع نطاق إدارة الشهادات اليدوية في بيئات DevOps حيث تقوم فرق متعددة بشحن التعليمات البرمجية باستمرار.
تعمل حلول إدارة دورة حياة الشهادات (CLM) على مركزية التحكم أثناء التكامل مع خطوط أنابيب CI/CD. وتوفر المنصات مثل Sectigo Certificate Manager و AppViewX CERT+ إمكانات إدارة دورة حياة الشهادات (CLM) على مستوى المؤسسات المصممة خصيصاً لسير عمل توقيع التعليمات البرمجية. يحصل المطورون على وصول الخدمة الذاتية لإنشاء توقيعات رقمية دون الوصول المباشر إلى المفاتيح. تحافظ فرق الأمن على إمكانية الرؤية وفرض السياسات عبر جميع أنشطة التوقيع.
تقوم هذه المنصات بتتبع مخزون الشهادات وتواريخ انتهاء الصلاحية وأنماط الاستخدام. تصبح الإدارة المركزية ضرورية لأمن سلسلة توريد البرمجيات، خاصةً عندما تساهم عدة فرق ومقاولين في قاعدة التعليمات البرمجية الخاصة بك. كما أنها تعمل على أتمتة التجديدات وتجعل التدقيق سهلاً ومباشراً. عندما تحتاج إلى معرفة ما تم توقيعه بأي شهادة، فإن المعلومات موجودة.
يعني التكامل مع أنظمة الإنشاء أن المطورين لا يحتاجون إلى التفكير في تفاصيل الشهادة. فهم يرسلون التعليمات البرمجية، ويتعامل خط الأنابيب مع التوقيع تلقائيًا باستخدام الشهادة المناسبة، وتخرج الأداة الموقعة من الطرف الآخر.
تعمل مهام سير العمل المحددة مسبقاً على فرض سياسات الأمان الخاصة بك. لا يمكن توقيع التعليمات البرمجية بدون موافقة. لا يمكن استخدام شهادات الاختبار للإنتاج. لا يمكن للمطورين في وحدة أعمال واحدة الوصول إلى مفاتيح توقيع وحدة أخرى.
تعمل المركزية على تبسيط الأمان دون تصعيب الحياة على المطورين. هذا هو التوازن الذي تحتاجه – الأمان القوي الذي يعمل مع عملية التطوير، وليس ضدها.
تأمين سلسلة توريد البرمجيات الخاصة بك باستخدام SSL Dragon
توفر SSL Dragon شهادات توقيع الكود من جهات التصديق الرائدة بما في ذلك DigiCert وSectigo. وسواء كنت بحاجة إلى توقيع رمز قياسي للتطبيقات الداخلية أو شهادات EV للبرامج الموزعة على نطاق واسع، سنساعدك في اختيار الحل المناسب.
يتفهم فريقنا التحديات الأمنية التي يواجهها مطورو البرامج. ويمكننا إرشادك خلال اختيار الشهادات وتنفيذها وإدارتها لضمان اتباع البنية التحتية لتوقيع التعليمات البرمجية الخاصة بك لأفضل الممارسات في المجال.
استكشف شهادات توقيع التعليمات البرمجية من SSL Dragon أو اتصل بفريقنا لمناقشة الحل الأنسب لمتطلبات تطوير برامجك ومتطلبات الأمان. قم بحماية سلسلة توريد البرمجيات الخاصة بك – فمستخدموك يعتمدون على ذلك.
وفِّر 10% على شهادات SSL عند الطلب اليوم!
إصدار سريع، وتشفير قوي، وثقة في المتصفح بنسبة 99.99%، ودعم مخصص، وضمان استرداد المال خلال 25 يومًا. رمز القسيمة: SAVE10
