كيفية حماية تطبيق ويب باستخدام Authelia دون تعديله

تتضمن العديد من التطبيقات المستضافة ذاتيًا أنظمة تسجيل دخول بدائية للغاية أو تفتقر إلى المصادقة تمامًا. يؤدي نشرها عبر نطاق وإضافة بروتوكول HTTPS إلى تحسين الاتصال، لكنه لا يمنع أي شخص من الوصول إلى الواجهة ومحاولة تسجيل الدخول.

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

يفترض هذا الدليل أن نظام Authelia والخادم الوكيل العكسي يعملان بالفعل. إذا كنت لا تزال بحاجة إلى إعداد هذه البنية التحتية، فيجب عليك أولاً... قم بتهيئة Authelia باستخدام مدير وكيل Nginx وتحقق من قدرة الحاويتين على التواصل.

ماذا يعني حماية تطبيق باستخدام Authelia؟

لا يتم تثبيت Authelia داخل التطبيق ولا تقوم بتعديل قاعدة بياناته. يتم تطبيق الحماية على مستوى الخادم الوكيل العكسي باستخدام نظام يسمى تمت إعادة توجيه عملية المصادقة أو المصادقة الأمامية.

يعمل التدفق على النحو التالي:

1. يفتح المستخدم نطاق التطبيق.
2. يقوم الخادم الوكيل بإرسال استعلام داخلي إلى Authelia.
3. تقوم Authelia بفحص سياسات الجلسة والوصول.
4. في حالة عدم وجود بيانات المصادقة، قم بإعادة توجيه المستخدم إلى بوابتك الإلكترونية.
5. بمجرد الحصول على الموافقة، يقوم الخادم الوسيط بتسليم التطبيق المطلوب.

يتيح لك هذا إضافة كلمات المرور والمصادقة الثنائية إلى اللوحات الداخلية، ومديري الملفات، وأدوات المراقبة، أو التطبيقات التي لا توفر حماية كافية.

مع ذلك، لا تتحكم Authelia إلا في الوصول المسبق. إذا كان للتطبيق أيضًا نموذج تسجيل دخول خاص به، فقد يضطر المستخدم إلى قم بالمصادقة مرتينلتسجيل الدخول تلقائيًا داخل التطبيق، يجب أن يدعم OpenID Connect أو SAML أو المصادقة باستخدام رؤوس موثوقة.

ما تحتاجه قبل حماية التطبيق

قبل أن تبدأ، تأكد من أن لديك ما يلي:

• مثال وظيفي لـ أوثيليا.
• خادم وكيل عكسي متوافق ومتكامل بشكل صحيح مع Authelia.
• نطاق أو نطاق فرعي للتطبيق.
• شهادة HTTPS صالحة.
• مستخدم أو مجموعة مُصرّح لها في نظام إدارة الهوية.
• الوصول إلى الملف configuration.yml من أوثيليا.
• التحكم في ملف Docker Compose أو جدار حماية التطبيق.

يجب أن يستخدم النطاق العام للتطبيق بروتوكول HTTPS. كما يجب أن يكون مدرجًا ضمن أحد النطاقات المُعلنة في session.cookiesعلى سبيل المثال، ملف تعريف ارتباط مُعيّن لـ example.com يمكن استخدامه مع app.example.com y auth.example.com.

لا تستخدم النطاقات العامة المشتركة بالكامل، مثل duckdns.org، باعتباره نطاق ملفات تعريف الارتباط. يجب عليك استخدام نطاقك الفرعي الخاص، مثل miservidor.duckdns.org.

كيفية إغلاق اختصار منفذ التطبيق

تفقد حماية Authelia الكثير من فائدتها إذا تمكن شخص ما من تجاوز الخادم الوكيل عن طريق الوصول إليه مباشرة من خلال عنوان مثل:

http://IP_DEL_SERVIDOR:8080

إذا كان التطبيق يعمل في Docker، فقم بإزالة القسم ports الذي ينشر منفذه على المضيف:

services:
  mi-aplicacion:
    image: imagen/de/la-aplicacion:version
    container_name: mi-aplicacion
    restart: unless-stopped
    networks:
      - proxy
    expose:
      - "8080"

networks:
  proxy:
    external: true

التوجيه expose هذا اختياري. وظيفته توثيق المنفذ الذي يستخدمه الحاوية، ولكن لا يشكل ذلك حاجزًا للسلامةيمكن للحاويات المتصلة بنفس الشبكة التواصل حتى لو لم يظهر هذا القسم.

الأمر المهم حقاً هو عدم استخدام مهمة مثل:

ports:
  - "8080:8080"

بعد إعادة إنشاء الحاوية، ستتوقف الخدمة عن الاستماع على المنفذ 8080 الخاص بالمضيف ولن يكون الوصول إليها ممكناً إلا من خلال اسمها داخل شبكة Docker.

إذا كان التطبيق يعمل على خادم آخر وتحتاج إلى إبقاء المنفذ مفتوحًا، فاستخدم جدار الحماية للسماح بالاتصالات فقط من عنوان IP الخاص بالخادم الوكيل العكسي.

كيفية ربط التطبيق بشبكة البروكسي

يجب أن يشترك التطبيق، Authelia، والخادم الوكيل في شبكة واحدة على الأقل. أولاً، تحقق مما إذا كانت هناك شبكة موجودة بالفعل:

docker network inspect proxy

إذا لم تقم بإنشائه بعد:

docker network create proxy

أضف الشبكة كشبكة خارجية في ملف Compose الخاص بالتطبيق:

networks:
  proxy:
    external: true

بعد ذلك، أعد إنشاء الخدمة:

docker compose up -d

من تلك اللحظة فصاعدًا، سيتمكن الخادم الوكيل من تحديد موقع التطبيق باستخدام اسم الخدمة أو اسم الحاوية الخاص به:

http://mi-aplicacion:8080

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

إذا كان التطبيق يستخدم قاعدة بيانات أيضًا، فلا يلزم أن يكون جزءًا من شبكة الوكيل. يمكنك إنشاء شبكة خاصة ثانية مخصصة للتطبيق للتواصل مع PostgreSQL أو MariaDB أو الخدمة المقابلة.

كيفية إنشاء سياسة الوصول للتطبيق

يتم تكوين السياسات في القسم access_control من الملف configuration.ymlلفرض المصادقة الثنائية على جميع المستخدمين المسجلين:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'app.example.com'
      policy: 'two_factor'

إذا كان ينبغي السماح لمجموعة واحدة فقط بالدخول:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'app.example.com'
      policy: 'two_factor'
      subject:
        - 'group:usuarios_app'

يمكنك أيضاً تحديد مستويات مختلفة:

• ينكر: يمنع الوصول.
• تجاوز: يسمح بالوصول بدون مصادقة.
• عامل واحد: يتطلب اسم مستخدم وكلمة مرور.
• عاملان: وهذا يضيف عاملاً ثانياً.

تقوم Authelia بتقييم القواعد بشكل تسلسلي وتطبيق أول تطابق. لذلك، يجب تضمين السياسات التي تستهدف مجالًا أو مجموعة أو مسارًا محددًا. قبل القواعد العامة.

على سبيل المثال:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'panel.example.com'
      policy: 'two_factor'
      subject:
        - 'group:admins'

    - domain: '*.example.com'
      policy: 'one_factor'

في هذه الحالة، تتطلب اللجنة المصادقة الثنائية للمسؤولين، ثم يتم تطبيق القاعدة العامة على بقية النطاقات الفرعية.

لستَ بحاجة إلى تحديد البوابة. auth.example.com مثل bypass إذا لم يستخدم مضيف الوكيل الخاص بك التحقق من Authelia، فإن تأمين البوابة من خلال التفويض الخاص بك قد يؤدي إلى إنشاء حلقة إعادة توجيه.

كيفية التحقق من إعدادات Authelia

قبل إعادة تشغيل الخدمة، تحقق من صحة الملف:

docker exec authelia authelia config validate --config /config/configuration.yml

إذا لم تظهر أي أخطاء، فأعد تشغيل Authelia:

docker restart authelia

بعد ذلك، تحقق من سجلاتك:

docker logs --tail=200 authelia

أخطاء المسافات البادئة في YAML شائعة. استخدم المسافات بدلاً من علامات الجدولة وتأكد من ذلك. domain, policy y subject يندرجون ضمن نفس القاعدة.

كيفية ربط التطبيق بالخادم الوكيل العكسي

في مدير بروكسي Nginx، قم بإنشاء مضيف بروكسي يشير إلى الاسم الداخلي للحاوية:

• أسماء النطاقات: app.example.com
• مخطط: http
• إعادة توجيه اسم المضيف/عنوان IP: mi-aplicacion
• المنفذ الأمامي: 8080
• شهادة SSL: شهادة صالحة للنطاق
• فرض استخدام SSL: تم التفعيل

في علامة التبويب "متقدم"، قم بتضمين المقتطفات الرسمية:

include /snippets/authelia-location.conf;

location / {
    include /snippets/proxy.conf;
    include /snippets/authelia-authrequest.conf;
    proxy_pass $forward_scheme://$server:$port;
}

يستعلم المقتطف الحالي عن نقطة النهاية /api/authz/auth-requestلا تعيد استخدام الأمثلة القديمة المستندة إلى /api/verify.

إذا لم تكن قد أعددت هذه الملفات بعد، فراجع الدليل الكامل لـ دمج Authelia مع مدير وكيل Nginx.

ماذا يحدث لبيانات تسجيل الدخول الخاصة بالتطبيق؟

تُحدد آلية المصادقة الأمامية ما إذا كان بإمكان الطلب الوصول إلى التطبيق، لكنها لا تُنشئ جلسة تلقائيًا داخله. لذلك، قد تحدث ثلاث حالات:

• تطبيق بدون تسجيل دخول: تُصبح أوثيليا العائق الوحيد أمام وصولهم.
• تطبيق مزود ببيانات تسجيل دخول خاصة به: يتجاوز المستخدم نظام Authelia ثم يدخل بيانات اعتماد التطبيق.
• تطبيق متوافق مع معيار OIDC أو رؤوس موثوقة: يمكن إعادة استخدام هوية أوثيليا وتجنب الشكل الثاني.

إذا كان التطبيق يدعم OpenID Connect، فسيكون من الأفضل عادةً استخدام هذا التكامل لتحقيق تسجيل دخول موحد حقيقيلا تزال خاصية المصادقة الأمامية مفيدة للتطبيقات القديمة، ولوحات المعلومات البسيطة، أو الخدمات التي لا تدعم موفري الهوية.

على سبيل المثال، يمكنك استخدام هذا النظام لـ قم بحماية واجهة المستخدم المفتوحة (Open WebUI) بكلمة مرور.ومع ذلك، فإن التكامل الأنسب سيعتمد على ميزات المصادقة المتوفرة في الإصدار المثبت.

كيفية التعامل مع واجهات برمجة التطبيقات (APIs) وتطبيقات الجوال وتقنية WebSockets

قد لا تعرض تطبيقات الجوال وبعض برامج سطح المكتب بوابة Authelia أو قد لا تتبع عمليات إعادة التوجيه بشكل صحيح. في هذه الحالات، قد يؤدي تأمين واجهة برمجة التطبيقات بالكامل باستخدام المصادقة الأمامية إلى منع العميل من الاتصال.

الخيارات الأكثر أماناً هي:

• يستخدم OpenID Connect إذا سمح التطبيق والعميل بذلك.
• الحفاظ على مصادقة واجهة برمجة التطبيقات الأصلية.
• أنشئ استثناءً يقتصر على مسار محدد يتمتع بحماية خاصة به.
• استخدم شبكة افتراضية خاصة (VPN) للوصول إلى الخدمة دون نشرها مباشرة.

لا تستبعد واجهة برمجة تطبيقات كاملة لمجرد تشغيل تطبيق جوال. إذا كنت بحاجة إلى السماح برابط ويب أو فحص حالة النظام، فقم بتقييد القاعدة باستخدام... resources:

- domain: 'app.example.com'
  policy: 'bypass'
  resources:
    - '^/api/webhook/receive$'

لا يُقبل هذا الاستثناء إلا إذا كانت نقطة النهاية تتحقق من صحة توقيع أو رمز مميز أو سر منفصل.

إذا كان التطبيق يستخدم WebSockets، فأضفه داخل الكتلة الخاصة بك location:

include /snippets/websocket.conf;

عند كتابة فقرة location قد لا يكون لتفعيل خيار دعم Websockets يدويًا في علامة التبويب "متقدم" في مدير وكيل Nginx أي تأثير.

لماذا يجب عليك الحذر من تجاوز عناوين IP؟

قد تطبق Authelia سياسات مختلفة تبعًا للشبكة التي يتصل منها المستخدم. ومع ذلك، تعتمد هذه القواعد على العنوان المُضمن في X-Forwarded-For.

يجب على الخادم الوكيل إزالة أي قيم مُرسلة مباشرةً من العميل واستبدالها بالعنوان الحقيقي. وإلا، فقد يتمكن المهاجم من ذلك. قم بانتحال عنوان IP المصدر الخاص بك للتوافق مع شبكة معتمدة.

لا تقم بتكوين الوصول غير المصادق عليه لشبكة منزلك بالكامل حتى تتأكد من التالي:

• لا يمكن تعديل الرؤوس المُعاد توجيهها إلا بواسطة الخوادم الوكيلة الموثوقة.
• يتعرف مدير بروكسي Nginx بشكل صحيح على عنوان IP الحقيقي.
• تم الإعلان عن Cloudflare أو غيرها من الوكلاء الوسيطين على أنها موثوقة.
• لا يؤدي التلاعب برأس الطلب من الإنترنت إلى تفعيل سياسة التجاوز.

كلما أمكن ذلك، من الأفضل الحفاظ على one_factor ضمن الشبكة المحلية والاحتياطي two_factor للاتصالات الخارجية.

كيفية التحقق من أن التطبيق محمي بالفعل

لا ينتهي الاختبار بمجرد ظهور بوابة Authelia. يجب عليك التأكد من عدم وجود أي مسار آخر يمكنه الوصول إلى التطبيق.

أولاً، تحقق من المنافذ المنشورة:

docker ps --format 'table {{.Names}}\t{{.Ports}}'

لا ينبغي للحاوية المحمية أن تعرض خريطة كهذه. 0.0.0.0:8080->8080/tcp.

بعد ذلك، اتبع هذه الخطوات:

1. قم بتسجيل الخروج من Authelia أو استخدم نافذة خاصة.
2. يفتح https://app.example.com.
3. تأكد من أن متصفحك يعيد توجيهك إلى البوابة.
4. تأكد من أنه يطلب مستوى المصادقة المُكوّن.
5. جرب مع مستخدم لا ينتمي إلى المجموعة المصرح لها.
6. حاول الوصول إليه مباشرة باستخدام عنوان IP والمنفذ القديم.
7. مراجعة المسارات المخصصة، وواجهات برمجة التطبيقات، وخطافات الويب، واتصالات WebSocket.

يمكنك أيضًا فحص الاستجابة دون تسجيل الدخول:

curl -I https://app.example.com

ينبغي أن تتلقى إعادة توجيه إلى بوابة Authelia، عادةً عبر رمز HTTP 302.

كرر هذه الاختبارات بعد تحديث Authelia، أو تغيير الوكيل، أو تعديل السياسات، أو إضافة موقع مخصص.

أخطاء شائعة عند حماية تطبيق باستخدام Authelia

يظل التطبيق متاحًا عبر عنوان IP.

لا يزال الحاوية تُعلن عن منفذها للمضيف، أو أن جدار الحماية يسمح بالاتصالات المباشرة. احذف القسم portsأعد إنشاء الحاوية وتحقق من قائمة المنافذ مرة أخرى.

يظهر خطأ 502 Bad Gateway

لا يستطيع الخادم الوكيل تحديد موقع التطبيق. تحقق من أن كلا الحاويتين متصلتان بنفس الشبكة وأن اسم الخدمة والمنفذ الداخلي صحيحان.

يعرض تطبيق Authelia رسالة "تم رفض الوصول" بعد تسجيل الدخول

لقد تم التحقق من هوية المستخدم بنجاح، ولكنه لا يلتزم بالسياسة. يرجى التحقق من اسم المجموعة، والنطاق المطلوب، وترتيب القواعد.

يدخل المتصفح في حلقة إعادة توجيه

تحقق من استخدام بروتوكول HTTPS، ونطاق ملفات تعريف الارتباط، authelia_url والرؤوس التي يُعيد توجيهها الخادم الوكيل. تحقق أيضًا من أن البوابة غير محمية بواسطة خادمها الخاص. auth_request.

يطلب التطبيق اسم المستخدم وكلمة المرور مرة أخرى.

هذا ليس بالضرورة خطأً برمجيًا. تحمي خاصية المصادقة الأمامية عملية تسجيل الدخول، لكنها لا تبدأ جلسة تلقائيًا داخل التطبيق. ستحتاج إلى بروتوكول OIDC أو تكامل يستخدم رؤوسًا موثوقة لتجنب تسجيل الدخول الثاني.

الموقع الإلكتروني يعمل، لكن تطبيق الهاتف المحمول لا يتصل

من المحتمل أن العميل غير قادر على متابعة عملية إعادة التوجيه إلى Authelia. تحقق مما إذا كان يدعم OIDC أو يحتفظ بمصادقة واجهة برمجة التطبيقات الأصلية دون تطبيق استثناءات واسعة النطاق.

بعض الوظائف التي تعمل في الوقت الفعلي تتوقف عن الاستجابة.

يستخدم التطبيق بروتوكول WebSockets، ولا يحتفظ الخادم الوكيل بالعناوين اللازمة. وهذا يشمل websocket.conf ضمن نفس الكتلة المحمية.

يسمح المسار المخصص بالدخول بدون مصادقة.

قد لا ترث المواقع المُنشأة من مواقع مخصصة صلاحيات الوصول. قم بتعريفها في الإعدادات المتقدمة وقم بتضمينها بشكل صريح. authelia-authrequest.conf.

لا يقتصر تأمين تطبيق ويب باستخدام Authelia على مجرد عرض نموذج تسجيل الدخول. يتطلب الأمان الحقيقي إغلاق المنفذ الأصلي، وتوجيه جميع حركة المرور عبر خادم وكيل، وإنشاء سياسة محددة، والتحقق من أن واجهات برمجة التطبيقات أو المسارات المخصصة أو التلاعب بالعناوين لا يمكنها تجاوز المصادقة.

بمجرد اكتمال هذه الفحوصات، يمكنك إضافة كلمة المرور والمصادقة الثنائية إلى الخدمات القديمة أو الأساسية للغاية دون تعديل التعليمات البرمجية الخاصة بها، مما يحافظ على نقطة وصول مركزية وخاضعة للتحكم.