الأسئلة الشائعة عن Identity and Access Management

موضوعات الأسئلة الشائعة

عام

ما المقصود بـ Oracle Cloud Infrastructure Identity and Access Management ‏(OCI IAM)؟

OCI IAM هي خدمة أصلية لـ OCI توفر ميزات إدارة الهوية والوصول على مستوى المؤسسة مثل المصادقة القوية والتكييفية وإدارة دورة حياة المستخدم (LCM) وتسجيل الدخول الموحد (SSO) إلى تطبيقات المؤسسة. تم توزيع OCI IAM كمجالات هوية في OCI. تتيح المجالات المضمّنة للمؤسسات إدارة الوصول إلى تطبيقات Oracle Cloud الخاصة بها (الشبكة والحوسبة والتخزين، وما إلى ذلك) وOracle SaaS. يمكن للعملاء اختيار ترقية أو إنشاء مجالات هوية إضافية لاستيعاب حالات الاستخدام الأخرى مثل إدارة وصول القوى العاملة إلى التطبيقات غير التابعة لشركة Oracle، أو تمكين وصول المستهلك إلى التطبيقات التي تواجه العملاء، أو تضمين IAM في التطبيقات المخصّصة.

ما المقصود بمجالات الهوية؟

كل مجال هوية OCI IAM يُعدّ أحد حلول إدارة الهوية والوصول القائمة بذاتها ويمكن استخدامه لمعالجة مجموعة متنوعة من حالات استخدام IAM. على سبيل المثال، يمكنك استخدام مجال هوية OCI IAM لإدارة الوصول للموظفين عبر العديد من التطبيقات السحابية والمحلية، ما يتيح المصادقة الآمنة والإدارة السهلة للاستحقاقات وتسجيل الدخول الأحادي السلس للمستخدمين النهائيين. قد تريد أيضًا وضع مجال هوية لتمكين الوصول إلى سلسلة التوريد أو أنظمة الطلب لشركاء الأعمال. يمكنك أيضًا استخدام مجالات الهوية لتمكين IAM للتطبيقات التي تواجه المستهلكين والسماح للمستخدمين المستهلكين بإجراء تسجيل ذاتي وتسجيل دخول اجتماعي و/أو الموافقة على شروط الاستخدام. تمثِّل مجالات الهوية حلًا شاملًا للهوية كخدمة (IDaaS) يستوعب العديد من حالات استخدام IAM والسيناريوهات.

ما نوع مجال الهوية الذي يجب أن أختاره؟

  • مجالات الهوية المجانية: يتضمن كل عقد إيجار OCI مجال هوية OCI IAM افتراضيًا من الطبقة المجانية لإدارة الوصول إلى موارد OCI (الشبكة والحوسبة والتخزين، وغير ذلك). إذا كنت تبحث عن إدارة الوصول إلى موارد OCI فقط، يمكنك استخدام المجال الافتراضي المضمّن. وهي توفِّر مجموعة قوية من وظائف IAM لإدارة الوصول إلى موارد Oracle Cloud. وفقًا لنموذج التأمين والفريق، قد يختار العملاء حجز هذا المجال لمسؤولي OCI.
  • مجالات هوية تطبيقات Oracle‏: قد تتضمّن العديد من تطبيقات Oracle Cloud (HCM، وCRM، وERP، وتطبيقات المجال، وما إلى ذلك) استخدام OCI IAM عبر مجال تطبيقات Oracle. يتم تضمين هذه المجالات لاستخدامها مع تطبيقات Oracle المشتركة وتوفِّر وظائف IAM قوية لإدارة الوصول إلى خدمات Oracle Cloud وSaaS. قد يختار العملاء إضافة جميع الموظفين إلى هذا المجال لتمكين تسجيل الدخول الموحّد إلى خدمة تطبيق Oracle Cloud، وقد يستخدموا هذا المجال لإدارة الوصول إلى بعض موارد OCI الخاصة بهم أو جميعها.
  • مجالات هوية Oracle Apps Premium‏: إذا كنت تريد توسيع مجال Oracle Apps بميزات مؤسسة كاملة لإدارة الوصول لتطبيقات Oracle التي قد لا تكون مقدمة بواسطة SaaS (على سبيل المثال، Oracle E-Business Suite أو Oracle Databases، سواء أكانت محلية أم مستضافة في OCI)، توفِّر مجالات Oracle Apps Premium مجموعة كاملة من ميزات وإمكانات OCI IAM للاستخدام مع أهداف Oracle التي يمكن نشرها عبر بيئات السحابة الهجينة. هذه خدمة منخفضة التكلفة كاملة المزايا ولكنها محدودة الاستخدام مع أهداف Oracle.
  • مجالات الهوية الخارجية: توفِّر مجالات الهوية الخارجية مجموعة كاملة من ميزات وإمكانات OCI IAM لغير الموظفين مثل المستهلكين الذين يصلون إلى موقع التجزئة أو الحكومات التي تتيح الوصول للمواطنين أو الشركات ما يتيح الوصول إلى شركاء الأعمال. لا توجد قيود يمكن استهداف التطبيقات عليها. ومع ذلك، لا يتم تضمين بعض ميزات المؤسسة التي لا تكون مفيدة بشكل عام في سيناريوهات غير الموظفين، مثل عبّارة التطبيق وجسر الإمداد. تشمل المجالات الخارجية دعم تسجيل الدخول الاجتماعي والتسجيل الذاتي والموافقة على شروط الاستخدام وإدارة ملف التعريف/كلمة المرور.
  • مجالات الهوية المميزة: توفِّر مجالات الهوية المميزة مجموعة كاملة من ميزات وإمكانات OCI IAM دون قيود يمكن استهداف التطبيقات عليها. يمكن استخدام المجالات المميزة كخدمة IAM للمؤسسات التي تدير وصول الموظفين أو القوى العاملة عبر التطبيقات السحابية والمحلية ما يتيح مصادقة آمنة وإدارة الاستحقاقات بسهولة وتسجيل الدخول الأحادي السلس للمستخدمين النهائيين.

هل يمكنني مزج الموظفين وغير الموظفين في مجال هوية واحد؟

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

من لديه حق الوصول إلى مجال الهوية؟

يتضمن كل عقد إيجار OCI مجموعة مسؤولين توفِّر الوصول الكامل إلى جميع موارد OCI. من المهم فهم أن كل أعضاء مجموعة مسؤولي OCI لديهم حق الوصول الكامل لإدارة مجالات هوية OCI IAM. تنصح Oracle باستخدام هذه المجموعة بعناية. يمكن منح الامتيازات الإدارية داخل كل مجال من خلال أدوار المسؤولين التي تسمح بفصل المهام بين مجموعات الأشخاص. راجع معرفة أدوار المسؤولين للمزيد من التفاصيل.

هل توفِّر OCI IAM توافرًا عاليًا و/أو استعادة القدرة على العمل بعد الكوارث؟

داخل كل منطقة OCI، توجد إما مجالات إتاحة (ADs) متعددة أو مجالات خطأ (FD) (في مناطق AD واحدة). تخدم ADs وFDs وظائف مماثلة، ولكن FDs أقرب ماديًا من ADs. يتم نشر مجالات الهوية مع التركيبات الزائدة في كل منطقة (اثنان عبر AD/FDs) ويُعدّ ذلك توافرًا عاليًا. توفِّر مجالات هوية OCI IAM أيضًا استعادة البيانات بعد الكوارث عبر المناطق من خلال نهج سلبي نشط يستفيد من استنساخ البيانات عالي الأداء. يوفِّر ذلك استعادة بيانات موثوقة لمجالات الهوية في حال عدم توفر منطقة OCI بأكملها. يتم تسليم DR من خلال عنوان URL واحد ما يجعله شفافًا للتطبيقات.

ما المفاهيم والمصطلحات الرئيسية لخدمة Oracle Identity and Access Management؟

المفاهيم الرئيسية لخدمة IAM هي:

  • الحساب أو الإيجار: عند التسجيل في OCI، تنشئ Oracle عقد إيجار لشركتك، وهو قسم معزول داخل OCI حيث يمكنك تكوين مواردك السحابية وتنظيمها وإدارتها. ويسمى هذا أحيانًا حساب OCI.
  • حاوية الموارد السحابية: حاوية منطقية داخل حساب OCI لموارد Oracle Cloud. يمكن للمسؤولين إنشاء مقطع واحد أو أكثر ضمن حساب OCI لتنظيم الموارد وإدارتها. على سبيل المثال، يمكن استخدام الحاويات لفرض فصل المهام بين أنواع مختلفة من المسؤولين (الشبكة، الحوسبة، التخزين، وغير ذلك).
  • الحاوية الجذر: حاوية المستوى الأعلى داخل حساب OCI. يتم إنشاء الحاوية الجذر لك تلقائيًا عند توفير حسابك.
  • مجالات الهوية - يمثِّل مجال الهوية مجتمع المستخدمين في OCI والتكوينات المرتبطة وإعدادات التأمين. يتضمّن كل حساب مجال هوية افتراضيًا يتيح للعملاء إدارة الوصول إلى موارد OCI. يمكن للعملاء اختيار إنشاء مجالات هوية إضافية بناءً على احتياجاتهم الخاصة. يتم تكوين مجالات الهوية داخل إحدى الحاويات، ويتم ربط الوصول إلى إدارة المجالات بأذونات الحاوية. يمكن كتابة سياسات الوصول إلى OCI للسماح للمستخدمين في حاوية محددة/مجال محدد بالوصول إلى الموارد في الحاويات الأخرى.
  • المستخدم: كيان يمكن التصديق عليه. يمكن أن يكون المستخدم إما حساب شخص أو حساب آلة. لكل مستخدم اسم فريد في حسابك ومعرّف فريد عام. يمكن منح المستخدمين كلمات مرور للوصول إلى وحدة تحكم الويب والمفاتيح للوصول إلى الخدمات من خلال واجهات برمجة التطبيقات.
  • 0المجموعة: مجموعة من المستخدمين. وتُستخدم المجموعات لتبسيط إدارة الوصول. على سبيل المثال، يمكن تجميع مطوري البرامج معًا كأعضاء في مجموعة "المطورين"، ما يتيح لهم قراءة و/أو تعديل التعليمات البرمجية. يمكن أن يكون مستخدم واحد عضوًا في مجموعات متعددة.
  • النظام: مستند يحدِّد من يمكنه الوصول إلى موارد OCI والامتيازات التي يمتلكها. يتألف النظام من عبارات نظام تستفيد من صياغة اللغة الطبيعية.

ما الذي يميز نهج Oracle Cloud Infrastructure فيما يتعلق بخدمة Identity and Access Management؟

باستخدام OCI IAM، يمكنك الاستفادة من نموذج واحد للمصادقة والترخيص عبر جميع خدمات Oracle Cloud وCloud Application. تسهّل OCI IAM إدارة الوصول للمؤسسات على اختلاف أحجامها، بدءًا من شخص واحد يعمل في مشروع واحد ووصولًا إلى الشركات الكبيرة التي يعمل بها العديد من المجموعات في العديد من المشروعات في الوقت نفسه، وكل ذلك ضمن حساب واحد. يمكن أن تتم إدارة الموارد والتصريح بها على مستوى الحساب أو على مستوى الحاويات، مع السماح بالتدقيق والفوترة المركزيين. تم إنشاء OCI IAM من البداية للسماح لك بفرض مبدأ التأمين الأقل امتيازًا؛ وبشكل افتراضي، لا يُسمح للمستخدمين الجدد بتنفيذ أيّ إجراءات على أيّ موارد. ويمكن للمسؤولين بعد ذلك منح كل مستخدم حق الوصول الملائم لذلك المستخدم المحدّد فقط.

بالإضافة إلى إدارة موارد OCI، تضع OCI IAM حل IDaaS من فئة المؤسسات في متناول يديك. بمجرد ضغطة زر، يمكنك نشر حل IAM قوي يمكن استخدامه لتلبية العديد من متطلبات IAM عبر حالات استخدام الموظف/القوى العاملة أو الشريك أو المستهلك.

كيف تدعم Oracle Cloud Infrastructure المصادقة متعددة العوامل؟

توفِّر OCI IAM دعمًا واسعًا للمصادقة متعددة العوامل (MFA) التي تتضمّن تطبيق MFA للأجهزة المتنقلة الذي يعرض خيارات للدفع أو رمز المرور لمرّة واحدة ودعم مصدقي FIDO2 ودعم الرسائل القصيرة والبريد الإلكتروني والمكالمات الهاتفية وغيرها. تتضمّن OCI IAM أيضًا الأمان التكيفي القائم على السياق الذي يقلِّل من المخاطر من دون إحداث عقبات لتجربة المستخدم النهائي. يقوم الأمان التكيفي بتقييم جهاز المستخدم وشبكته وموقعه وسلوكه السابق لإنشاء درجة مخاطر لجلسة عمل المستخدم. يمكن للمسؤولين تكوين أنظمة MFA التي قد تختلف في تطبيقات معينة أو لمجموعات معينة من المستخدمين.

هل تم تسجيل تغييرات للمستخدمين والمجموعات والحاويات والسياسات لأغراض تصحيح الأخطاء والمراجعة؟

نعم. لدعم متطلبات المؤسسة للمراجعة والتوافق، يتم تسجيل جميع التغييرات ويمكن توفير هذه السجلات لك دون أيّ تكلفة إضافية.

كيف يمكنني بدء استخدام OCI IAM؟

يتم تمكين OCI IAM افتراضيًا من دون رسوم إضافية. المستخدم الأول في حسابك هو المسؤول الافتراضي. يتم تكوين كل المستخدمين اللاحقين من خلال خدمة IAM، حيث يمكنك منحهم صراحةً الامتيازات للتفاعل مع موارد السحابة المحددة.

يمكنك الوصول إلى Oracle IAM باستخدام وحدة التحكم أو واجهة برمجة التطبيقات Rest‏ أو حزم تطوير البرامج (SDKs).

كمستخدم لخدمة Oracle Cloud Infrastructure، كيف يمكنني إعادة تعيين كلمة المرور؟

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

حاويات موارد سحابية

ما المشكلات التي تم تصميم الحاويات لحلها؟

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

فيما يلي بعض الطرق الشائعة لاستخدام الحاويات من أجلها:

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

هل يمكن أن تحتوي الحاويات على موارد في مجالات توافر متعددة؟

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

كيف يتم استخدام الحاويات للتحكم في الوصول؟

كل السياسات مرفقة إمّا بالحاوية الجذرية أو بحاوية فرعية. يتكوّن كل نظام من عبارة نظام واحدة أو أكثر تتبع هذه الصياغة الأساسية:

السماح بالمجموعة في الحاوية

تتيح لك عبارات النظام استخدام الحاويات لتبسيط إدارة الأذونات؛ على سبيل المثال، يمكنك كتابة نظام يتيح للمجموعة HRAdministrators بإدارة كل الموارد في الحاوية HRCompartment.

هل يمكنني حذف الحاويات؟

نعم، يمكنك حذف الحاويات.

هل يمكنني نقل أشجار حاوية كاملة ومواردها المضمّنة؟

نعم، يمكنك نقل أشجار حاوية كاملة ومواردها المضمّنة إلى حاويات رئيسية أخرى.

هل يمكنني نقل الموارد، مثل مثيل الحوسبة أو وحدة تخزين الكتل، من حاوية إلى أخرى؟

نعم، يمكنك نقل الموارد من إحدى الحاويات إلى أخرى.

هل يمكنني إنشاء تدرج الحاويات؟

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

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

الحدّ الأقصى لعمق حاوية متداخلة هو ستة.

هل الأنظمة المطبقة على حاوية رفيعة المستوى تنطبق أيضًا على حاوية فرعية؟

نعم، يتم اكتساب الأنظمة الموجودة على الحاويات رفيعة المستوى بواسطة حاويات فرعية.

هل يمكنني تتبع التكاليف والاستخدام حسب الحاويات؟

نعم، يمكنك تتبع التكاليف والاستخدام حسب الحاويات في قسم "خدماتي".

ما المقصود بالحاوية الجذر؟

تقوم Oracle Cloud Infrastructure تلقائيًا بإنشاء حاوية على مستوى عالٍ تُعرف باسم الحاوية الجذر لكل حساب. وهي تشبه إلى حدّ كبير المجلد الجذر في نظام الملفات، تتصرّف الحاوية الجذر تمامًا مثل حاوياتها الفرعية، باستثناء بعض الخصائص الخاصة:

  • نظرًا لأنّ الأذونات متدرجة، سيتم تطبيق أذونات المجموعة في الحاوية الأولي على كل الحاويات الفرعية. على سبيل المثال، إذا تم منح المجموعة NetworkAdmins إذنًا لإدارة شبكات السحابة الظاهرية (VCN) في الحاوية الجذر، فستتمكن هذه المجموعة من إدارة شبكات VCN في جميع الحاويات.
  • في الوقت الحالي، يتم تكوين كل المستخدمين والمجموعات داخل الحاوية الجذر. يمكن استخدام الأنظمة لمنحهم حق الوصول إلى حاويات فرعية محددة فقط.

ملاحظة: يمكنك حاليًا إنشاء حاويات إضافية داخل الحاوية الأولي فقط وليس داخل الحاويات الأخرى.

متى يجب إنشاء الموارد في الحاوية الجذر ومتى يجب إنشائها في حاوية فرعية؟

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

المستخدمين

ما الذي يمكن أن يفعله مستخدم وحدة تحكم Oracle Cloud Infrastructure؟

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

من يستطيع إنشاء المستخدمين وإدارتهم؟

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

ما هي صلاحية الوصول للمستخدم الجديد عند الإنشاء؟

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

هل يمكنني تمكين وصول المستخدم وتعطيله؟

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

هل يمكننا تعيين كلمات سر لانتهاء صلاحيتها؟ كيف يمكنني تدوير الصلاحيات؟

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

السياسات

ما المقصود بالنظام؟

النظام هو مستند يتكون من بيانات نظام وصفية تمنح أذونات محددة لمجموعات من المستخدمين. وتتم كتابتها بصياغة سهلة الفهم تشبه SQL. مثال على الأنظمة التي قد تُفرض:

  • يمكن لمسؤولي النظام "إنهاء" مثيلات الحوسبة بدون أنظمة تشغيل أو "إعادة تشغيلها".
  • يمكن لمسؤولي الشبكة إدارة كل موارد البنية التحتية المرتبطة بالشبكة بشكل كامل.
  • يمكن لمسؤولي تكنولوجيا المعلومات تكوين مستخدمين وتعديل عضويات المجموعة.

يتيح النظام للمجموعة العمل بطرق معينة مع أنواع محددة من الموارد في حاوية معينة. اختياريًا، يمكن أن تحتوي الأنظمة على عبارة شرطية ("‎wher‎e ...‎") تقيّد بيان النظام بشكل أكبر. تلتزم الأنظمة بالصياغة التالية:

السماح بالمجموعة في الحاوية [where]

على سبيل المثال، إليك جملة نظام تمنح أذونات لاستخدام مثيلات الحوسبة:

السماح لمطوري المجموعة باستخدام المثيلات في الحاوية ProjectA

  • "group_name" هو اسم المجموعة التي يتم منحها الأذونات.
  • "verbs" هي إجراءات يمكنك اتخاذها على الموارد، على سبيل المثال: فحص أو قراءة أو استخدام أو إدارة.
  • "resource-type" هو مورد السحابة الذي يتم منح الأذونات له. مثال على أنواع الموارد: المثيلات ووحدات التخزين وجداول المسارات.
  • "compartment_name" هو اسم الحاوية الذي يتم فيه تنظيم الموارد.
  • "conditions" هي مواصفات أخرى تضييق نطاق بيان النظام. تتضمّن الأمثلة: "where request.user.id=target.user.id" أو "where target.group_name != المسؤولين".

للمزيد من التفاصيل، اطّلع على قسم ‏OCI IAM‏ لوثائق Oracle Cloud Infrastructure.

هل يتم اكتساب أنظمة الحاوية الجذر بواسطة الحاويات الفرعية؟

نعم. يمنح النظام الذي يمنح الأذونات في الحاوية الجذر الأذونات نفسها تلقائيًا لجميع الحاويات الفرعية. على سبيل المثال، يمنح النظام التالي الإذن لجميع المستخدمين في المجموعة "InstanceAdmins" لإدارة المثيلات في الحاوية الجذر وكذلك جميع الحاويات الفرعية:

السماح للمجموعة InstanceAdmins بإدارة المثيلات في الإيجار

هل يمكن قصر الأنظمة على حاويات محددة؟

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

أين يمكنني معرفة المزيد عن كتابة بيانات الأنظمة؟

لمزيد من المعلومات عن بيانات الأنظمة والأنظمة، يُرجى الاطّلاع على "بدء استخدام الأنظمة" و"الأنظمة العامة" في وثائق Oracle Cloud Infrastructure.

سياسة رفض IAM

الأسئلة الشائعة حول سياسة رفض إدارة الهوية والوصول في OCI

توجِّه هذه الأسئلة الشائعة المستخدمين من خلال سياسات رفض إدارة الهوية والوصول في البنية التحتية من Oracle Cloud (OCI)، والتي تسمح للمستخدمين الذين يمكنهم إدارة السياسات بحظر الإجراءات بشكل صريح، وتعزيز الأمان وتبسيط التحكم في الوصول في مستأجرات OCI. لمزيد من التفاصيل، راجع وثائق إدارة الهوية والوصول في OCI .

بدء استخدام رفض IAM

كيف يمكنني تمكين ميزة رفض IAM في OCI؟

يُعد رفض IAM ميزة اشتراك يجب تمكينها صراحةً بواسطة مسئول مثيل قاعدة البيانات مؤجر من خلال الانتقال إلى وحدة تحكم OCI، ثم السياسات، ثم الإجراءات، ثم إعدادات السياسة. لا يمكن تمكينها بواسطة المستخدمين العاديين أو مؤلفي السياسات. بمجرد التمكين، تصبح الميزة جزءًا دائمًا من إطار عمل IAM المسأجرة ولا يمكن تعطيلها عبر واجهة المستخدم. مع ذلك، يمكن لمسئول المستأجرة ممن لديه القدرة على كتابة سياسات الرفض التحكم بفعالية في استخدام سياسات الرفض عن طريق كتابة سياسة رفض على مستوى الجذر تمنع جميع المستخدمين من إنشاء سياسات الرفض أو تعديلها، باستثناء مجموعة المسئولين الافتراضية. مثال على ذلك هو رفض أي مستخدم لإدارة السياسات في مستأجرة يكون بها target.policy.type='DENY'

عند تمكين رفض IAM

  • تضع OCI تلقائيًا سياسة رفض افتراضية في الحاوية الجذر للاستخدام الآمن.
  • لا تحتفظ سوى مجموعة المسئولين الافتراضية ومسئول المستأجرة الذي مكَّن رفض IAM بالأذونات لإنشاء سياسات الرفض وإدارتها.
  • يمكن لمسئول المستأجرة بعد ذلك تحديث سياسة الرفض الافتراضية للسماح للمستخدمين المعتمدين—مثل مجموعات المسئولين في حاويات الخدمات المصرفية والاستثمارات والامتثال—بكتابة سياسات الرفض في وحدة تحكم OCI.

ما بيانات رفض إدارة الهوية والوصول في OCI؟

باستخدام بيانات رفض إدارة الهوية والوصول في OCI، يمكنك كتابة سياسات رفض صريحة لحظر إجراءات مُحددة في مستأجرات OCI، مما يكمل إدارة الهوية والوصول في OCI والسمح ببيانات للتحكم الدقيق في الوصول. على سبيل المثال، يمكنك استخدام رفض أي مستخدم أن يفحص كل الموارد في المستأجرة التي يكون بها request.service='streaming' لتعيين أساس حماية يمنع كل الوصول إلى خدمة تدفق OCI عبر مستأجرتك، مع السماح بالأذونات الأخرى عبر بيانات السماح.

ما هي حدود سياسات رفض IAM؟

تشارك سياسات رفض IAM في نفس حدود سياسات السماح. يمكن أن تحتوي مستأجرة على ما يصل إلى 100 كائن سياسة IAM، يحتوي كل منها على ما يصل إلى 50 بيان سياسة (رفض أو السماح)، لكن العدد الإجمالي لبيانات السياسة عبر جميع الكائنات في المستأجرة محدود بـ 100.

ما هي أفعال البيانات الوصفية التي تدعمها سياسات رفض IAM، وهل هي جديدة أم موجودة؟

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

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

إنشاء السياسات وإدارتها

أين يمكنني كتابة سياسات الرفض في وحدة تحكم OCI؟

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

هل يوجد كائن سياسة مُنفصل لسياسات الرفض؟

لا، تستخدم سياسات الرفض نفس كائن السياسة مثل سياسات السماح. تتم إدارة كليهما في نفس كائن السياسة، مما يُبسِّط الإدارة.

هل يمكنني تضمين رفض البيانات والسماح بها في كائن سياسة IAM واحد؟

نعم، يمكنك دمج عبارات الرفض والسماح في كائن سياسة واحد للتحكم المرن في الوصول.

على سبيل المثال، يمكن أن تتضمن سياسة واحدة عبارات السماح والرفض كما هو موضح أدناه:

رفض مجموعة المتدربين استخدام المستأجرة في الإدارة المالية للحاوية
السماح لمسؤولي المجموعة بإدارة جميع الموارد في الإدارة المالية للحاوية

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

كيف يمكنني منع المستخدمين الذين يمكنهم إدارة السياسات من كتابة سياسات الرفض؟

لمنع مستخدمي السياسة الذين يمكنهم إدارة السياسات من كتابة سياسات الرفض، أنشئ سياسة رفض على مستوى الجذر لمنع إنشاء سياسة الرفض.

مثال: رفض مجموعة PolicyAdmins لإدارة السياسات في مستأجرة يكون بها target.policy.type='DENY'

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

كيف يمكنني حظر خدمة OCI بأكملها باستخدام سياسة رفض IAM؟

لحظر خدمة OCI بأكملها، أنشئ سياسة رفض في الحاوية الجذر تستهدف موارد الخدمة أو إجراءاتها باستخدام شرط مثل request.service.name.

على سبيل المثال، لحظر مستأجرة خدمة تدفق OCI على مستوى العالم

رفض أي مستخدم أن يفحص جميع الموارد في مثيل قاعدة البيانات المؤجر يكون بها request.service.name='streaming'

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

كيف يمكنني رفض مجموعة من إدارة الموارد في منطقة مُحددة؟

لمنع مجموعة من إدارة الموارد في منطقة مُحددة، استخدم سياسة رفض مع request.region condition.

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

رفض مجموعة RegionalAdmins أن تستخدم جميع الموارد في مستأجرة يكون بها request.region='sa-saopaulo-1'

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

كيف يمكنني رفض وصول مجموعة إلى مثيلات الحوسبة في حاوية مُحددة؟

لرفض وصول مجموعة إلى مثيلات الحوسبة في حاوية مُحددة، استخدم

رفض مجموعة DevTeam أن تفحص المثيل في حاوية ProjectX

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

كيف يمكنني رفض مجموعة من إدارة تخزين الكائنات في حاوية مُحددة؟

لرفض مجموعة من إدارة تخزين الكائنات في حاوية مُحددة، استخدم

رفض مجموعة StorageUsers أن تفحص مجموعة كائنات في حاوية DataLake

تمنع هذه السياسة كل الأذونات (الفحص والقراءة والاستخدام والإدارة) في موارد تخزين الكائنات في حاوية DataLake. على سبيل المثال، يمكن لمؤسسة الرعاية الصحية تطبيق ذلك لمنع StorageUsers من الوصول إلى بيانات المرضى الحساسة، مما يدعم الامتثال إلى لوائح الخصوصية.

كيف يمكنني تفويض المهام إلى المستخدمين الذين يمكنهم إدارة السياسة في حاوية فرعية دون السماح لهم بتعديل موارد معينة أو كتابة سياسات رفض؟

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

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

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

رفض مجموعة ProjectAdmins أن تدير مجموعة الشبكة في حاوية ProjectX رفض مجموعة ProjectAdmins أن تدير السياسات في حاوية ProjectXيكون بها target.policy.type='DENY'

السماح لمجموعة ProjectAdmins بإدارة مجموعة المثيلات في حاوية ProjectX

تمكِّن هذه السياسات ProjectAdmins من إدارة المثيلات في ProjectX، وحظرها من تعديل الشبكات، ومنعها من كتابة سياسات الرفض، ودعم التفويض الآمن. قد تستخدم المؤسسة المالية هذا النهج للسماح للمسؤولين الفرعيين بإدارة موارد الحوسبة مع الحفاظ على تحكم صارم في تكوينات الشبكة وإدارة السياسات.

آليات السلامة والاستعادة

هل يتم تقييم سياسات الرفض قبل السماح بالسياسات؟

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

على سبيل المثال، قد توجد السياسات التالية في حاوية "المنتج":

رفض مجموعة Devs أن تدير مجموعة المثيلات في حاوية المنتج
والسماح لمجموعة Devs أن تدير جميع الموارد في حاوية المنتج

تمنع سياسة الرفض التطويرات من إدارة المثيلات، بينما لا يزال بإمكان المسئولين الافتراضيين إدارة المثيلات.

ماذا يحدث إذا قام مُستخدم يمكنه إدارة السياسات بكتابة سياسة رفض تؤمن كل المستخدمين في مستأجرة؟

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

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

كيف يمكنني استعادة سياسة رفض على مستوى المستأجرة التي تؤمن جميع المستخدمين؟

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

1. سجِّل الدخول باعتبارك عضو في مجموعة المسئولين الافتراضية (معفى من سياسة الرفض).
2. في وحدة تحكم OCI، انتقل إلى الهوية والأمان، ثم السياسات.
3. حدد موقع السياسة التي بها مشكلة في الحاوية الجذر.
4. قم بتحرير السياسة أو حذفها (على سبيل المثال، قم بتغيير رفض أي مستخدم أن يفحص كل الموارد في مستأجرة إلى رفض مجموعة المتدربين من أن يفحصوا كل الموارد في المستأجرة).
5. أو بدلاً من ذلك، استخدم واجهة سطر أوامر OCI التالية: تحديث سياسة OCI iam --policy-id --عبارات '["رفض مجموعة المتدربين من أن يفحصوا كل الموارد في المستأجرة"]

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

تأثيرات الإذن

ماذا يحدث إذا رفضت إذن "إدارة"؟

يحظر رفض الإدارة إذن الإدارة فحسب، مع ترك الاستخدام والقراءة والفحص دون تغيير.

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

ماذا يحدث إذا رفضت إذن "استخدام"؟

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

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

ماذا يحدث إذا رفضت إذن "قراءة"؟

يحظر رفض القراءة أذونات القراءة والاستخدام والإدارة، لكن لا يزال يكون مسموحًا بالفحص.

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

ماذا يحدث إذا رفضت إذن "الفحص"؟

يمنع رفض الفحص كل الأذونات (فحص، قراءة، استخدام، إدارة) لأن الفحص هو إذن المستوى الأساس.

مثال: يمنع رفض عارضي المجموعة فحص المثيل في الحاوية العامة العارضين تمامًا من الوصول إلى المثيلات.

حالات الاستخدام المُتقدمة واستكشاف الأخطاء وإصلاحها

كيف يمكنني مراقبة سياسات الرفض لضمان عملها على النحو المقصود؟

مراجعة سجلات تدقيق OCI لتتبع الإجراءات التي تم حظرها من سياسات الرفض. إذا أدت سياسة مثل رفض أي مستخدم أن يفحص cloud-shell في مستأجرة إلى حدوث مشكلات، فقم بتحسينها إلى رفض مجموعة المتدربين من فحص cloud-shell في المستأجرة. أعد تنبيهات حول تغييرات السياسة للبقاء في الصدارة.

مثال: مراقبة السجلات لضبط رفض برامج تشغيل مجموعة إدارة مجموعة المثيلات في سطول الحاوية إذا كانت تحظر المهام المشروعة.

ما هي الأخطاء الشائعة التي يجب تجنبها مع سياسات الرفض؟

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

على سبيل المثال، يمكن أن تمنع سياسة مثل رفض أي مستخدم أن يفحص كل الموارد في المستأجرة كل الوصول، مما يتسبب في تأمين على مستوى المستأجرة. بدلاً من ذلك، استخدم السياسات المُستهدفة، مثل ما يلي:

Deny group Interns to inspect all-resources in compartment Public

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

هل عبارات الرفض مدعومة لحالات الاستخدام عبر المستأجرة؟

نعم، تدعم عبارات الرفض سيناريوهات عبر المستأجرة. يمكن أن تمنع عبارة قبول رفض أو تأييد رفض واحدة طلبات عبر المستأجرة، على عكس أزواج التأييد/القبول التي تتطلب استيفاء كليهما.

تُعد مستأجرة المصدر التالية مثال على ذلك:

تأييد مجموعة Devs لاستخدام مجموعة الكائنات في مستأجرة PartnerTenancy رفض مجموعة التأييد Devs إدارة مجموعة الكائنات في مستأجرة PartnerTenancy

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

كيف يتفاعل رفض السياسات مع توجيه حزم الثقة الصفرية في OCI؟

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

مثال:

  • سياسة توجيه حزم الثقة الصفرية في OCI: السماح لـ dynamic-group FrontEnd في VCN web:vcn بالاتصال بـ backend:server-instance في VCN vcn:server، يسمح بحركة مرور الشبكة.
  • سياسة IAM: رفض المجموعة الديناميكية FrontEnd إدارة مجموعة المثيل في الحاوية ProjectA تمنع إدارة المثيلات على الرغم من السماح بتوجيه حزم الثقة الصفرية في OCI.

يتم تقييم توجيه حزم الثقة الصفرية في OCI وسياسات IAM بالتسلسل، مع اعتبار IAM مسئول البوابة النهائي.

كيف تتفاعل السياسات المُحددة بواسطة النظام مع سياسات الرفض؟

تتجاوز سياسات النظام القياسية دائمًا سياسات الرفض المُحددة بواسطة المستخدم لضمان عمل الخدمات الأساسية (على سبيل المثال، السماح لأي مستخدم بقراءة النطاقات في مستأجرة يكون بها target.domain.id='request.domain.id').

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

هل يتم تقييم سياسات الرفض بشكل مُختلف عن سياسات السماح؟

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

مثال: إذا كان رفض مستخدمي المجموعة إدارة مجموعة المثيل في حاوية الإنتاج موجودًا بجانب السماح لمستخدمي المجموعة بإدارة جميع الموارد في حاوية الإنتاج، فتمنع سياسة الرفض إدارة المثيل.

هل يتخطى رفض IAM أدوار إدارة مجال هوية Oracle (على سبيل المثال، مسئول نطاق الهوية ومسئول الأمان ومدير المستخدم)؟

في الإصدار الحالي، لا تتجاوز سياسات رفض IAM أدوار إدارة خدمة Oracle Identity Cloud (على سبيل المثال، مسئول نطاق الهوية ومسئول الأمان ومدير المستخدم). هذا تقييد. في الإصدار التالي، يأخذ رفض IAM الأسبقية على أدوار إدارة خدمة Oracle Identity Cloud لإجراء التحكم المُتسق في الوصول.

كيف يمكنني استخدام رفض IAM حتى لا يحدث الوصول إلى الخدمة إلا من خلال الوصول الجديد إلى خدمة OCI الخاصة؟

يسمح الوصول إلى خدمة OCI الخاصة بالوصول إلى خدمات Oracle عبر مسار شبكة خاصة بدلاً من عبر الإنترنت العام. تم تصميم الوصول إلى خدمة OCI الخاصة للعملاء الذين يرغبون في الاتصال الخاص بين أحمال العمل وخدمات Oracle—لأسباب تتعلق بالامتثال أو الأداء أو الأمان.

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

على سبيل المثال، السماح بالوصول إلى تخزين كائنات OCI فحسب من خلال الوصول إلى خدمة OCI الخاصة، استخدم

رفض أي مستخدم للوصول إلى مجموعة الكائنات في مستأجرة يكون بها أي {not request.gateway.id, request.gateway.type !='privateserviceaccess'}

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

ما الفَرق بين سياسات رفض إدارة الهوية والوصول في OCI وOracle Security Zones، ومتى يجب علي استخدامها؟

توفر OCI سياسات رفض IAM وOracle Security Zones لتأمين مستأجرتك من خلال منع الإجراءات غير الآمنة. على الرغم من أن كلاهما يعزز أمانك، إلا أنهما يختلفان في طريقة عملهما ومرونتهما.

  • أوجه التشابه: تحظر كل من سياسات رفض IAM وOracle Security Zones إجراءات مُحددة لحماية مواردك وفرض أفضل ممارسات الأمان في مستأجرة OCI لديك.
  • الفروق الرئيسة
    • سياسات رفض IAM: يمكنك إنشاء سياسات مُخصصة لحظر الإجراءات بناءً على شروط مثل هوية المستخدم أو نوع المورد أو عنوان IP أو العلامات. تعمل هذه السياسات بمثابة حواجز، وبدءًا من الإصدار التالي، يصبح لها الأسبقية على جميع سياسات IAM. على سبيل المثال، يمكنك حظر مجموعة مستخدمين مُحددة من حذف الموارد المهمة إذا كان المورد يحتوي على علامة محددة، مثل environment:production.
    • Oracle Security Zones: تُطبق قواعد الأمان المُحددة مُسبقًا على الحاويات أو المستأجرة بأكملها. عند التمكين، تفرض Oracle Security Zones تلقائيًا قيودًا على بعض مجموعات خدمات OCI، مثل منع الشبكات الفرعية العامة أو تعطيل التشفير. لست بحاجة إلى كتابة السياسات—تكون القواعد مُدمجة وتتحقق تلقائيًا من إعدادات الموارد.
  • وقت الاستخدام
    • استخدم سياسات رفض IAM للوصول إلى قيود مُخصصة ومُستهدفة، مثل حظر مستخدمين أو إجراءات مُحددة بناءً على شروطك المحددة.
    • استخدم Oracle Security Zones للوصول إلى قواعد الأمان التلقائية الجاهزة لفرض أفضل الممارسات بأقل قدر من الإعداد.
    • دمج كلاهما من أجل توفير حماية أقوى. تمكين Oracle Security Zones للوصول إلى حواجز أساسية عريضة وإضافة سياسات رفض IAM لعناصر تحكم محددة ومُخصصة.

الحصول على المساعدة في سياسات رفض إدارة الهوية والوصول في OCI

لمزيد من المساعدة، تفضل بزيارة وثائق إدارة الهوية والوصول في OCI أو اتصل بفريق حساب OCI لديك.

المجموعات

ما المقصود بالمجموعة؟

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

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

هل يمكنني تعيين مسؤولين متعددين؟

نعم. تم تزويد حسابك بمسؤول افتراضي واحد ينتمي إلى مجموعة مسؤولين داخل الحاوية الجذر. تتمتع هذه المجموعة بامتيازات كاملة لإنشاء جميع موارد Oracle Cloud Infrastructure وإدارتها في حسابك، بما في ذلك المستخدمين والمجموعات والسياسات والحاويات، بالإضافة إلى جميع موارد البنية التحتية السحابية الأخرى في أيّ حاويات. يمكنك إضافة مستخدمين إضافيين إلى مجموعة المسؤولين هذه.

الميزات

كيف تلبي OCI IAM متطلبات انتهاء صلاحية كلمة المرور؟

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

كيف يمكنني تشغيل المهام على مثيل الحوسبة دون تضمين صلاحيات المستخدم فيها؟

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

الاتحاد

ما المقصود باتحاد الهوية في Oracle Cloud Infrastructure؟

اتحاد الهوية هو آلية لتفويض إدارة المستخدمين لإيجار Oracle Cloud Infrastructure لكيان آخر يسمى موفِّر الهوية أو IdP. وهذا مفيد للشركات التي لديها نظام هوية موجود تريد استخدامه، بدلًا من إنشاء وصيانة مجموعة جديدة من المستخدمين. يتطلب الاتحاد تكوينًا لمرّة واحدة بين Oracle Cloud Infrastructure وIdP المعروف باسم Federation Trust.

ما المقصود بالمستخدمين الخارجيين؟

المستخدمون الخارجيون (الهويات الخارجية) هم مستخدمون تديرهم خارج Oracle Cloud Infrastructure (على سبيل المثال، في دليل شركتك)، ولكنك تمنحهم حق الوصول إلى حساب Oracle Cloud Infrastructure. وهم يختلفون عن مستخدمي Oracle Cloud Infrastructure، الذين تم إنشاؤهم وصيانتهم في حساب Oracle Cloud Infrastructure الخاص بك.

هل يمكن للمستخدمين الخارجيين الوصول إلى وحدة تحكم Oracle Cloud Infrastructure؟

نعم. يمكن للمستخدمين الخارجيين الوصول إلى وحدة تحكم Oracle Cloud Infrastructure.

هل يمكن للمستخدمين الخارجيين الوصول إلى Oracle Cloud Infrastructure SDK وCLI؟

نعم. يمكن للمستخدمين الخارجيين الوصول إلى Oracle Cloud Infrastructure SDK وCLI.

ما الإجراءات التي يمكن لمستخدمي Oracle Cloud Infrastructure تنفيذها في وحدة التحكم التي لا يمكن للمستخدمين الخارجيين تنفيذها؟

لا يمكن للمستخدمين الخارجيين تغيير كلمات السر الخاصة بهم أو إعادة تعيينها في وحدة تحكم Oracle Cloud Infrastructure.

كيف يمكنني التحكم في ما هو مسموح للمستخدم الخارجي القيام به عند تسجيل الدخول إلى وحدة التحكم؟

يمكنك استخدام أنظمة Oracle Cloud Infrastructure نفسها التي تستخدمها في إدارة المستخدمين المحليين لإدارة المستخدمين الخارجيين. يمكنك تخطيط الأدوار والمجموعات في موفِّر الهوية إلى مجموعات في Oracle Cloud Infrastructure. عندما يقوم مستخدم خارجي بتسجيل الدخول، تقوم وحدة تحكم Oracle Cloud Infrastructure بتطبيق الأنظمة بناءً على عضوية مجموعة Oracle Cloud Infrastructure، تمامًا كما هو الحال مع المستخدمين الأصليين. راجع الوثائق للحصول على أمثلة.

يمكن ربط دور واحد أو مجموعة واحدة في "موفِّر الهوية" إلى مجموعات متعددة في Oracle Cloud Infrastructure. كما يمكن ربط عدة أدوار أو مجموعات في "موفِّر الهوية" إلى مجموعة واحدة في Oracle Cloud Infrastructure.

كم عدد المستخدمين الخارجيين الذين يمكنني منحهم حق الوصول إلى وحدة تحكم Oracle Cloud Infrastructure؟

لا يوجد حدّ لعدد المستخدمين الخارجيين الذين يمكن منحهم حق الوصول إلى وحدة التحكم.

من هم موفِّرو الهوية الذين تدعمونهم؟

تدعم OCI IAM أيّ مزود هوية متوافق مع SAML 2.0 أو Open ID Connect أو OAuth بما في ذلك الحلول الشائعة مثل Oracle Access Manager وMicrosoft Active Directory Federation Services (AD FS) وOkta.

التصديق متعدد العوامل

ما هو التصديق متعدد العوامل (MFA)، ولماذا يُعد ذلك مُهمًا؟

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

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

من يجب أن يستخدم MFA؟

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

ما تجربة المستخدم النهائي عندما يمكِّن المسؤولون MFA؟

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

لمزيد من المعلومات، يمكن للمستخدمين الرجوع إلى الإرشادات التالية:

هل MFA إلزامية في جميع الظروف؟

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

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

ما هي عوامل MFA المتاحة بالنسبة لي؟ هل توجد تكلفة؟

لفهم العوامل والتكلفة المتوفرة تمامًا، من المهم أولاً فهم نوع إيجار OCI الذي لديك. لتحديد إذا كان إيجارك يحتوي على OCI Identity and Access Management (IAM) مع نطاقات الهوية أو إذا كان لديه OCI IAM بدون نطاقات هوية، فراجع هذه الوثائق.

  • إذا كان الإيجار الخاص بك يحتوي على OCI IAM مع نطاقات الهوية، فإن جميع أنواع نطاقات الهوية تدعم MFA دون أي تكلفة إضافية. لا يمكن لنطاقات الهوية من النوع "المجاني" استخدام الرسائل النصية القصيرة كعامل مصادقة، لكن تتوفر عوامل أخرى. للحصول على التفاصيل الكاملة، يرجى مراجعة وثائق OCI IAM مع نطاقات الهوية MFA.
  • إذا كان الإيجار الخاص بك يحتوي على OCI IAM بدون نطاقات هوية، فيتوفر لديك خياران لـ MFA:
    • تمكين MFA لتسجيل دخول المستخدم المُباشر عبر خدمة OCI IAM. يوفر هذا الخيار مجموعة مُحدودة من عوامل المصادقة بدون تكلفة إضافية. للحصول على التفاصيل الكاملة، يرجى مراجعة OCI IAM دون وثائق MFA مع نطاقات الهوية.
    • الاستفادة من Oracle Identity Cloud Service (IDCS) لتصديق المستخدمين في OCI. يوفر هذا الخيار المزيد من ميزات المصادقة مُتعددة العوامل وخيارات المصادقة.
  • إذا كنت تستخدم IDCS للمصادقة، فيوجد نوعان من التراخيص:
    • تدعم مؤسسة IDCS (الطبقة المجانية) MFA فحسب للوصول إلى وحدة تحكم OCI، بدون تكلفة، بمجموعة محدودة من عوامل التصديق مثل موثقة هنا. لحماية التطبيقات الأخرى، تحتاج إلى الترقية إلى IDCS Standard.
    • يدعم IDCS Standard مجموعة واسعة من خيارات المصادقة متعددة العوامل لأي خدمة محمية أو تطبيق دون أي تكلفة إضافية. للحصول على التفاصيل الكاملة، يرجى مراجعة وثائق Identity Cloud Service (IDCS) MFA.

أين يمكنني معرفة المزيد حول طريقة تنفيذ MFA؟

تختلف التعليمات المُحددة لتنفيذ MFA تبعًا لنوع إيجار OCI الذي تمتلكه. لتحديد إذا كان إيجارك يحتوي على OCI IAM مع نطاقات الهوية أو إذا كان لديه OCI IAM بدون نطاقات هوية، فراجع هذه الوثائق.

  • إذا كان إيجارك يحتوي على OCI IAM بنطاقات هوية، فيرجى الرجوع إلى تأمين أفضل ممارسات OCI IAM.
  • إذا كان الإيجار الخاص بك يحتوي على OCI IAM بدون نطاقات هوية، فيتوفر لديك خياران لـ MFA:
  • إذا كنت تستخدم IDCS لتصديق التطبيقات بدون إيجار في OCI، فيرجى الرجوع إلى تكوين لخدمة IDCS.

ماذا يحدث إذا لم يتم تنفيذ MFA؟

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