أمن الخدمات المصغرة كيف تؤمن البنية التحتية للخدمات المصغرة الخاصة بك؟



ستناقش هذه المقالة حول أمان الخدمات المصغرة بعضًا من أفضل الممارسات لتأمين الخدمات المصغرة بطريقة مفصلة.

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

ما هي الخدمات المصغرة؟

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





ما هي الخدمات المصغرة - أمن الخدمات المصغرة - Edureka

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



لذا ، بعد ذلك في هذه المقالة حول أمان الخدمات المصغرة ، دعونا نفهم المشكلات التي تواجهها بنية الخدمات المصغرة.

المشاكل التي تواجهها الخدمات المصغرة

المشاكل التي تواجهها الخدمات المصغرة هي كما يلي:

المشكلة 1:

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



المشكلة 2:

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

مشكلة 3:

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

كيفية عمل قاموس في جافا

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

أفضل الممارسات لأمان الخدمات المصغرة

فيما يلي أفضل الممارسات لتحسين الأمان في الخدمات المصغرة:

آلية الدفاع في العمق

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

pivot and unpivot في خادم SQL

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

الرموز وبوابة API

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

الرموز

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

الآن ، المشكلة الرئيسية هي الرموز حيث يتم تخزين معلومات المستخدم. لذلك ، يجب تشفير بيانات الرموز لتجنب أي استغلال من 3بحث وتطويرموارد الحزب. يُعد تنسيق الويب Jason أو المعروف باسم JWT معيارًا مفتوحًا يحدد تنسيق الرمز المميز ويوفر مكتبات للغات مختلفة ويقوم أيضًا بتشفير هذه الرموز المميزة.

بوابات API

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

التتبع الموزع وإدارة الجلسة

التتبع الموزع

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

إدارة الجلسة

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

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

الجلسة الأولى و Mutual SSL

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

كيف تكتب طريقة الخيط

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

3بحث وتطويرالوصول إلى تطبيق الحزب

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

استخدام بروتوكول OAuth

الحل هو استخدام OAuth. عند استخدام OAuth ، يطالب التطبيق المستخدم بتفويض 3بحث وتطويرتطبيقات الحزب ، لاستخدام المعلومات المطلوبة وإنشاء رمز مميز لها. بشكل عام ، يتم استخدام رمز التفويض لطلب الرمز المميز للتأكد من عدم سرقة عنوان URL لرد الاتصال الخاص بالمستخدم.

لذلك ، أثناء ذكر رمز الوصول ، يتواصل العميل مع خادم التفويض ، ويفوض هذا الخادم العميل بمنع الآخرين من تزوير هوية العميل. لذلك ، عند استخدام Microservices مع OAuth ، تعمل الخدمات كعميل في بنية OAuth لتبسيط مشكلات الأمان.

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

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

لديك سؤال لنا؟ يرجى ذكر ذلك في قسم التعليقات في ' أمن الخدمات المصغرة 'وسأعود إليك.