هل يمثل الأمان في AEM مشكلة في النظام الأساسي أو التنفيذ؟

أرسلت بواسطة: أندري بينشوك | مطور معتمد من كبار وزراء اقتصاد الآسيان

تخيل الموقف: تنام بهدوء وترى حلمك الثالث ، عندما يرن الهاتف فجأة - يشكو عميل غير راضٍ من أن النظام بأكمله غير متوفر. توافق ، مثل هذه الأحداث غير مريحة لحياة مطور AEM والفريق بأكمله ومزود الحلول. لا يوجد شيء يجب القيام به ، نهوض مبكر والبحث عن حل في المستقبل.

لمنع حدوث مثل هذه اللحظات السعيدة في حياتك المهنية ، سوف أخبرك بمشاكل الأمان النموذجية وكيفية التأمين ضدها بشكل أفضل.

سألتزم بهذه الخطة:

1. الأمن على مستوى المؤلف ؛
2. نشر مستوى الأمان ؛
3. الأمن المرسل
4. حماية إطار CSRF ؛
5. هجمات DDoS.

نصائح أساسية لإدارة تجربة إدارة Adobe

سيصبح عالم مشاريع AEM أفضل إذا كان لدى كل مطور فهم مشترك لكيفية حماية النظام الأساسي من تسرب البيانات بشكل عام. وفقًا للرسم البياني أدناه ، لدينا مؤلف والعديد من الناشرين واثنين من المرسلين أو أكثر (ما يسمى بالميزان). في الواقع ، هذه المستويات الثلاثة تستحق الاهتمام في المقام الأول من حيث حماية البيانات. هذه هي قواعد العمل الكلاسيكية المقبولة عمومًا في مجتمع وزراء اقتصاد الآسيان حول العالم.

1. استخدام HTTPS . يتطور AEM بسرعة ، مما يوفر المرونة لإنشاء مؤلف على بروتوكول آخر أكثر أمانًا. وهو ما يكفي لتوليد مفتاح "معالج SSL"، إنشاء مسار لذلك، وبالتالي، لاستخدام بروتوكول أكثر أمنا. في توصيات Adobe - هذه الخطوة هي بالضبط الأولوية الأولى في مجال الأمن.

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

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

4. رفض تعيين كلمة مرور وتسجيل الدخول على "admin-admin". لن يكون الأمر مضحكًا ، ولكن مشكلة تسجيل الدخول وكلمة المرور ذات الجودة الرديئة شائعة جدًا حتى في وزراء اقتصاد الآسيان. نتيجة لذلك ، في السعي لتحقيق السرعة أو غيرها من الاعتبارات ، نحصل على النظام الأكثر ضعفا. بمجرد العثور على تفاصيل تسجيل الدخول البدائية ، حاول إقناع الفريق / الرؤساء وتغييرها إلى بيانات موثوقة في أقرب وقت ممكن.

الأمن على مستوى المؤلف

أولا ، استخدم VPN . استخدام الشبكة الافتراضية المحمية هو عمل شبكة خاصة آمنة لتأسيس اتصال آمن بينك وبين الخادم. هذه أداة بسيطة وهامة: نظرًا لأن حركة المرور الخاصة بك سيتم تشفيرها ، فمن المستحيل معرفة من أين ترسل بياناتك منه. لذلك، مع VPN لا يمكن لأحد الوصول إلى المثيل.

هذا النهج مناسب للمطورين عن بُعد وجميع الذين يتم تنفيذ أعمالهم من مواقع مختلفة باستخدام اتصال إنترنت غير مستقر.

ثانيا، ك "الكاتب" يجب دائما أن تكون مغلقة، بما في ذلك من جوجل. حتى تتمكن من التقاط كلمة مرور واختراق النظام: من خلال الإهمال ، قد تتم فهرسة المؤلف. للتحقق من ثغراتك في محرك البحث ، اكتب في خطك المجال والمؤلف والمسار إلى crx. نعم ، يمكنك الاتصال بـ Yandex أو Google لطلب حذف مثل هذا الخط في SERP. ولكن ، بينما يتم حل المشكلة ، سيكون النظام متاحًا للجمهور بالفعل.

ثالثًا ، لا تقلل من شأن امتيازات المستخدم "المسؤول" ، الذي لديه في أغلب الأحيان القدرة على تنفيذ أي عمليات متاحة.

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

في إصدار AEM 6.1 لديه نهج جديد، حيث يمكنك تعيين حقوق محددة لخدمة حزمة أو المستخدم. لكن من الأفضل إنشاء ملف شخصي مخصص: إنه ممتع للموظف ، ومن السهل على رجال الأعمال تتبع من لديه مستويات الوصول إلى النظام. هذا النهج مناسب لمستوى المؤلف والناشر.

نشر الأمن

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

يعد مرشح Apache Sling Referrer آلية مريحة وفعالة لجعل تطبيقك آمنًا. على سبيل المثال ، أرسل مقاييس إلى AEM ، ترى معلومات حول إرسال البيانات في علبة الوارد. إذا تجاوزت القيمة الافتراضية ، فقد يرسل نظام جهة خارجية هذا الطلب. هذا يعني أن أي شخص لن يكون قادرًا على إرسال طلب. تقوم بإدخال المجال في التكوين ؛ في وقت الطلب ، يقوم بمقارنته بالبيانات التي تم إدخالها في الأصل ، وإذا كان كل شيء مطابقًا ، فسيحدث التكامل.

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

الأمن على مستوى المرسل

يواجه المطورون نزاعًا في 10٪ من الحالات. لذلك ، هذا هو ملف التكوين الرئيسي ، حيث نقوم بتعيين نوع عنوان URL (حظر / سماح).

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

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

أسهل طريقة هي تمكين التسجيل. اعتمادًا على إصدار Apache ، قد تتغير آلية العمل قليلاً. ولكن سيقوم النظام بتسليط الضوء فورًا على عنوان url الذي تحدده القاعدة المحددة وما الذي لا يزال يتعين تصحيحه.

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

طلب تزوير عبر الموقع - طلب مزيف.

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

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

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

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

ستعمل AEM كل شيء من أجلك: ستقوم بإنشاء المفاتيح والرموز ، وسوف تتحقق من تقديم النموذج

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

ما الذي يمكن القيام به لحماية النظام:

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

هجوم DDOS - الهجوم الثاني الأكثر شعبية

والهدف هو - لاستنفاد قدرات المادية للخادم. يتم تقديم ملايين الطلبات على بعض المضيف. عندما تصبح عدد لانهائي، بدء تشغيل النظام ولا تعامل جسديا. كقاعدة عامة ، يهاجمون بقوة من عدة مصادر ويستخدمون VPN. 100 ٪ من هذا غير مؤمن. ولكن دعونا لا نساعدهم.

في الحالات التي يكون فيها النظام ضعيفًا:

• تكوين النظام مع لاحقة خاطئة ؛
• العديد من طلبات الأسهم السعودية، المرسل في pablishe يمكن forvardnut عليها؛
• عندما لا يحظر انتاج المحتوى عدد غير محدود من العقد. على وجه الخصوص ، جهاز عرض JSON ، والذي يمكنه عبور هيكل الشجرة على عدة مستويات.
• المضيف المحلي: 4502 / .json يمكنه تفريغ مستودع التخزين بالكامل بتنسيق JSON.

لجعل عملك على AEM أكثر أمانًا ، ركز على إمكانيات مستخدمين محددين.

لا تنس الذهاب إلى قائمة التحقق من أمان Adobe ، وترك كل شيء مستقرًا مع مشروعك على AEM.