أضف رأس HSTS إلى نقطة نهاية HTTPS التي تخدم Nextcloud

يشير تحذير "Strict-Transport-Security" من Nextcloud إلى أن فحص النظام لم يرصد وجود ترويسة HSTS بفترة صلاحية max-ageلا تقل عن 15552000180 يومًا في استجابة HTTPS العامة. أضف الترويسة إلى خادم الويب أو الخادم الوكيل العكسي الذي يُقدّم خدمة HTTPS، ثم اختبر عنوان URL العام نفسه. لا يُعدّ HSTS إعدادًا في Nextcloud config.php، ولا يمكن لاستجابة HTTP عادية إنشاء سياسة HSTS في المتصفحات.

ما يجب التحقق منه قبل تغيير الإعدادات

• تأكد من تحميل موقع Nextcloud بشكل صحيح عبر HTTPS وعرض شهادة صالحة لاسم المضيف الخاص به.
• حدد الخدمة التي تنهي بروتوكول TLS: Apache، NGINX، موازن الأحمال، مدخل الحاويات، أو وكيل خارجي.
• تحقق مما إذا كانت تلك الخدمة قد قامت بتعيينها بالفعل Strict-Transport-Security. أرسل سياسة واحدة محددة من نقطة نهاية TLS العامة؛ فالعناوين المكررة أو المتضاربة تجعل عملية التحقق مربكة.
• تأكد من جاهزية جميع النطاقات الفرعية لبروتوكول HTTPS قبل الإضافة includeSubDomains. لا تقم بتفعيلها preloadكطريقة سريعة لإزالة هذا التحذير.

يُخبر بروتوكول HSTS المتصفحات بأن الاتصالات المستقبلية باسم مضيف معين يجب أن تستخدم HTTPS. ويساعد هذا البروتوكول على منع الرجوع إلى HTTP بعد تلقي المتصفح للسياسة. ولا يحل HSTS محل TLS، ولا يُصلح شهادة غير صالحة، ولا يُعيد توجيه أول زيارة HTTP؛ لذا يُنصح بتكوين إعادة توجيه منفصلة من HTTP إلى HTTPS. يُحدد دليل إدارة Nextcloud 35 الحد الأدنى وهو 15552000 ثانية، ويوصي بتعيين رأس HTTP في خادم الويب. وتُعد نقطة التنفيذ الفعلية في نشر الوكيل هي المكون الذي يُعيد الاستجابة إلى الزائر.

تحديد سياسة أساسية

تتمثل السياسة الأولية المحافظة لاسم مضيف Nextcloud فيما يلي:

Strict-Transport-Security: max-age=15552000

يُلبي هذا الحد الأدنى لعمر مستندات Nextcloud دون تطبيق سياسة تلقائيًا على كل نطاق فرعي. بعد التأكد من دعم جميع النطاقات الفرعية ذات الصلة لبروتوكول HTTPS بشكل مستمر، يمكنك إضافة هذا ; includeSubDomainsالتوجيه. سيطلب المتصفح الذي تعرّف على هذا التوجيه استخدام HTTPS لتلك النطاقات الفرعية أيضًا. قد تصبح لوحة التحكم الداخلية أو خادم البريد أو الخدمة القديمة التي لا تزال تعتمد على HTTP غير قابلة للوصول في ذلك المتصفح حتى يتم ترحيلها أو انتهاء صلاحية السياسة.

أباتشي

بالنسبة للمضيف الظاهري لبروتوكول TLS الخاص بـ Apache، قم بتمكين mod_headersالتوجيه ووضعه داخل المضيف الظاهري لبروتوكول HTTPS، وليس فقط داخل مضيف إعادة توجيه المنفذ 80:

<VirtualHost *:443>
    ServerName cloud.example.com
    # Keep the existing TLS and Nextcloud configuration here.
    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000"
    </IfModule>
</VirtualHost>

استبدل اسم المضيف التجريبي واحتفظ بشهادتك الحالية وإعدادات الوكيل أو PHP. يستخدم مثال تقوية Apache في Nextcloud Header always setالمضيف الظاهري HTTPS. تحقق من صحة إعدادات Apache باستخدام أمر config-test المدعوم من توزيعتك، ثم أعد تحميل Apache فقط في حال نجاح الاختبار.

NGINX

في NGINX، أضف العنوان داخل serverالكتلة التي تستمع إلى HTTPS على اسم مضيف Nextcloud العام:

server {
    listen 443 ssl;
    server_name cloud.example.com;
    # Keep your existing TLS and Nextcloud locations here.
    add_header Strict-Transport-Security "max-age=15552000" always;
}

لا تقم بلصق هذا كبديل كامل لإعدادات الخادم الحالية. قد يعتمد توريث رؤوس NGINX على ما إذا كان الموقع المتداخل يُعرّف add_headerتوجيهاته الخاصة؛ لذا، افحص الإعدادات الفعلية واختبر استجابات نموذجية، بما في ذلك الأصول الثابتة ونقاط نهاية DAV. يتضمن نموذج Nextcloud NGINX الرسمي إعداد HSTS في إعدادات HTTPS الخاصة به، ويحذر المسؤولين من تفعيل التحميل المسبق.

وكيل عكسي أو مدخل

إذا كان موازن الأحمال أو بوابة الدخول أو الخادم الوكيل المستضاف يُنهي بروتوكول HTTPS قبل إعادة توجيه حركة المرور إلى Nextcloud، فقم بتعيين HSTS على طبقة TLS العامة تلك، إلا إذا كانت بنية نظامك تضيفه عمدًا على خادم موثوق به. قد يقوم الخادم الوكيل بإزالة أو استبدال رأس HTTP الذي يُضاف فقط من قِبل الخادم الخلفي. في المقابل، قد يؤدي تعيينه على كلا الطبقتين إلى قيم مكررة. تحقق من إعدادات رأس استجابة الخادم الوكيل وتأكد من أن مسار HTTPS الخاص به هو المسار الذي يتم اختباره. حافظ على اتساق إعدادات Trusted-proxy وعنوان URL الخاص بـ HTTPS في Nextcloud مع النشر الحالي، ولكن لا تعتبر هذه الإعدادات بديلاً عن إرسال رأس HTTP.

التحقق من صحة ردود الفعل العامة

1. استخدم مدقق بناء الجملة الخاص بالمنصة لتعديل إعدادات خادم الويب أو الوكيل.
2. أعد تحميل أو نشر التكوين الذي تم التحقق منه.
3. اطلب عنوان HTTPS العام وافحص رؤوس الاستجابة: curl -sSI https://cloud.example.com/ابحث عن Strict-Transport-Securityسطر واحد يحتوي على max-ageقيمة لا تقل عن 15552000.
4. في أدوات مطوري المتصفح، افحص الاستجابة من نفس اسم المضيف العام. قد يكشف هذا عن خادم وكيل يقوم بتغيير العناوين أو مسار يتجاوز المضيف الظاهري المتوقع.
5. أعد تحميل صفحة الإدارة → نظرة عامة في Nextcloud واسمح بتحديث فحص الأمان الخاص بها.

إذا curlلم يظهر رأس HSTS، فتأكد من أن نظام أسماء النطاقات (DNS) يشير إلى نقطة النهاية التي عدّلتها، وأن الطلب يستخدم HTTPS، وأن الخادم الوكيل لا يحذف الرأس. إذا ظهر الرأس في الصفحة الرئيسية فقط دون غيرها من الاستجابات، فراجع توجيهات NGINX على مستوى الموقع أو قواعد رأس استجابة الخادم الوكيل. إذا كانت الاستجابة العامة صحيحة، ولكن Nextcloud لا يزال يُصدر تحذيرًا، فتحقق من أن فحص المسؤول يستخدم نفس اسم المضيف والبروتوكول الظاهرين خارجيًا، ثم افحص أي طبقة تخزين مؤقت أو خادم وكيل بين الخادم والفحص.

استخدم التحميل المسبق فقط بعد مراجعة شاملة للنطاق

التحميل المسبق خيارٌ منفصلٌ وذو تأثيرٍ كبير. لا يُسجّل توجيه التحميل المسبق نطاقًا بحد ذاته؛ إذ أن قوائم التحميل المسبق للمتصفحات لها متطلبات تقديم خاصة بها. تتطلب إرشادات المتصفحات الحالية عملية تسجيل طويلة max-age. includeSubDomainsتُحذّر Nextcloud من أن إزالة اسم النطاق من قائمة التحميل المسبق المُرسلة قد تستغرق شهورًا حتى تصل إلى المتصفحات المُثبّتة. ابدأ بالسياسة الأساسية، وسجّل جميع أسماء المضيفين المتأثرة، وتأكد من عمل بروتوكول HTTPS عبر النطاق، وراجع متطلبات التحميل المسبق الرسمية قبل التقديم. يستطيع معظم مسؤولي Nextcloud حلّ هذا التحذير تحديدًا دون تفعيل التحميل المسبق.

المراجع: تحذيرات الأمان الخاصة بـ Nextcloud 35 ، إرشادات تقوية Nextcloud ، تكوين Nextcloud NGINX ، ومرجع رأس HSTS الخاص بـ MDN .