مشاركة عبر

للهوية وخارجها - وجهة نظر مهندس معماري واحد

في هذه المقالة، يناقش Alex Shteynberg، المهندس التقني الرئيسي في Microsoft، أهم استراتيجيات التصميم للمؤسسات التي تعتمد Microsoft 365 وخدمات Microsoft السحابية الأخرى.

نبذة عن الكاتب

أليكس شتينبيرغ الصورة.

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

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

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

أعيش في مدينة نيويورك (الأفضل!) وأتمتع حقا بتنوع ثقافتها وطعامها وشعبها (وليس حركة المرور). أحب السفر عندما أستطيع وأرجو أن أرى معظم العالم في حياتي. أنا حاليا أبحث في رحلة إلى أفريقيا للتعرف على الحياة البرية.

المبادئ التوجيهية

  • البساطة غالبا ما تكون أفضل: يمكنك القيام (تقريبا) بأي شيء باستخدام التكنولوجيا، ولكن هذا لا يعني أنه يجب عليك القيام بذلك. خاصة في مساحة الأمان، يقوم العديد من العملاء بتجاوز الحلول. أحب هذا الفيديو من مؤتمر Google's Stripe لتأكيد هذه النقطة.
  • الأشخاص، وعملية، وتكنولوجيا: تصميم للأشخاص لتحسين العملية، وليس التكنولوجيا أولا. لا توجد حلول "مثالية". نحن بحاجة إلى الموازنة بين عوامل الخطر المختلفة والقرارات التي قد تكون مختلفة لكل شركة. يصمم عدد كبير جدا من العملاء نهجا يتجنبه مستخدموهم لاحقا.
  • التركيز على 'لماذا' أولا و'كيف' في وقت لاحق: أن يكون طفل مزعج 7-yr القديمة مع مليون سؤال. لا يمكننا الوصول إلى الإجابة الصحيحة إذا لم نكن نعرف الأسئلة الصحيحة التي يجب طرحها. يقوم الكثير من العملاء بافتراضات حول كيفية عمل الأشياء بدلا من تحديد مشكلة الأعمال. هناك دائما مسارات متعددة يمكن اتخاذها.
  • ذيل طويل من أفضل الممارسات السابقة: أدرك أن أفضل الممارسات تتغير بسرعة فاتحة. إذا نظرت إلى Microsoft Entra قبل أكثر من ثلاثة أشهر، فأنت على الأرجح غير محدثة. كل شيء هنا قابل للتغيير بعد النشر. الخيار "الأفضل" اليوم قد لا يكون هو نفسه ستة أشهر من الآن.

مفاهيم الأساس

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

رسم توضيحي للمستأجر والاشتراك والخدمة والبيانات.

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

في الرسم التخطيطي:

  • المستأجر = مثيل Microsoft Entra ID. إنه في "أعلى" التسلسل الهرمي، أو المستوى 1 في الرسم التخطيطي. يمكننا اعتبار هذا المستوى هو "الحد" حيث يحدث كل شيء آخر (Microsoft Entra B2B جانبا). تعد جميع خدمات Microsoft enterprise السحابية جزءا من أحد هؤلاء المستأجرين. خدمات المستهلك منفصلة. يظهر "المستأجر" في الوثائق كمستأجر Microsoft 365 ومستأجر Azure ومستأجر WVD وما إلى ذلك. غالبا ما أجد هذه الاختلافات تسبب الارتباك للعملاء.
  • الخدمات/الاشتراكات، المستوى 2 في الرسم التخطيطي، تنتمي إلى مستأجر واحد فقط. معظم خدمات SaaS هي 1:1 ولا يمكن نقلها دون ترحيل. يختلف Azure، يمكنك نقل الفوترة و/أو الاشتراك إلى مستأجر آخر. هناك العديد من العملاء الذين يحتاجون إلى نقل اشتراكات Azure. هذا السيناريو له آثار مختلفة. لا يتم نقل العناصر الموجودة خارج الاشتراك. على سبيل المثال، التحكم في الوصول استنادا إلى الدور (Azure RBAC)، Microsoft Entra العناصر (المجموعات والتطبيقات والنهج وما إلى ذلك)، وبعض الخدمات (Azure Key Vault، وData Bricks، وما إلى ذلك). لا تقم بترحيل الخدمات دون حاجة تجارية جيدة. تتم مشاركة بعض البرامج النصية التي يمكن أن تكون مفيدة للترحيل على GitHub.
  • عادة ما تحتوي الخدمة المحددة على نوع من حدود "المستوى الفرعي"، أو المستوى 3 (L3). هذه الحدود مفيدة لفهم الفصل بين الأمان والسياسات والحوكمة وما إلى ذلك. لسوء الحظ، لا يوجد اسم موحد أعرفه. بعض الأمثلة على أسماء L3 هي: اشتراك Azure = المورد؛ Dynamics 365 CE = مثيل؛ Power BI = مساحة العمل؛ Power Apps = البيئة؛ وهكذا.
  • المستوى 4 هو المكان الذي تعيش فيه البيانات الفعلية. هذه "وحدة البيانات" هي مقالة معقدة. تستخدم بعض الخدمات Microsoft Entra ID ل RBAC، والبعض الآخر ليس كذلك. سأناقش الأمر قليلا عندما نصل إلى مقالات التفويض.

بعض المفاهيم الأخرى التي أجد العديد من العملاء (وموظفي Microsoft) مربكة حول أو تحتوي على أسئلة حول تتضمن المشكلات التالية:

  • يمكن لأي شخص إنشاء العديد من المستأجرين دون أي تكلفة. لا تحتاج إلى خدمة تم توفيرها داخلها. لدي العشرات. كل اسم مستأجر فريد في خدمة السحابة العالمية من Microsoft (بمعنى آخر، لا يمكن أن يكون لكل مستأجرين نفس الاسم). كلها بتنسيق TenantName.onmicrosoft.com. هناك أيضا عمليات تنشئ المستأجرين تلقائيا (مستأجرون غير مدارين). على سبيل المثال، يمكن أن تحدث هذه النتيجة عندما يقوم مستخدم بالتسجيل في خدمة مؤسسة مع مجال بريد إلكتروني غير موجود في أي مستأجر آخر.
  • في المستأجر المدار، يمكن تسجيل العديد من مجالات DNS فيه. لا تغير هذه النتيجة اسم المستأجر الأصلي. لا توجد حاليا طريقة سهلة لإعادة تسمية مستأجر (بخلاف الترحيل). على الرغم من أن اسم المستأجر ليس مهما من الناحية الفنية هذه الأيام، إلا أن بعض الأشخاص قد يشعرون بأنهم مقيدون بهذا الواقع.
  • يجب عليك حجز اسم مستأجر لمؤسستك حتى إذا لم تكن تخطط بعد لنشر أي خدمات. وإلا يمكن لشخص ما أخذه منك ولا توجد عملية بسيطة لإعادته (نفس المشكلة مثل أسماء DNS). أسمع بهذه الطريقة في كثير من الأحيان من العملاء. ما يجب أن يكون عليه اسم المستأجر الخاص بك هو مقالة مناقشة أيضا.
  • إذا كنت تملك مساحة اسم DNS، فيجب عليك إضافة جميع مساحات الأسماء هذه إلى المستأجرين. وإلا يمكن للمرء إنشاء مستأجر غير مدار بهذا الاسم، مما يؤدي بعد ذلك إلى تعطيل جعله مدارا.
  • يمكن أن تنتمي مساحة اسم DNS (على سبيل المثال، contoso.com) إلى مستأجر واحد فقط. هذا المطلب له آثار على سيناريوهات مختلفة (على سبيل المثال، مشاركة مجال بريد إلكتروني أثناء الدمج أو الاستحواذ، وما إلى ذلك). هناك طريقة لتسجيل فرعي DNS (مثل div.contoso.com) في مستأجر مختلف، ولكن يجب تجنب ذلك. من خلال تسجيل اسم مجال من المستوى الأعلى، يفترض أن تنتمي جميع المجالات الفرعية إلى نفس المستأجر. في السيناريوهات متعددة المستأجرين (كما هو موضح بعد ذلك) أوصي عادة باستخدام اسم مجال آخر من المستوى الأعلى (مثل contoso.ch أو ch-contoso.com).
  • من الذي يجب أن "يمتلك" مستأجرا؟ غالبا ما أرى عملاء لا يعرفون من يملك مستأجرهم حاليا. هذا النقص في المعرفة هو علامة حمراء كبيرة. اتصل بدعم Microsoft في ASAP. تماما كما هو الحال مع المشكلة عندما يتم تعيين مالك خدمة (غالبا مسؤول Exchange) لإدارة المستأجر. يحتوي المستأجر على جميع الخدمات التي قد تحتاجها في المستقبل. يجب أن يكون مالك المستأجر مجموعة يمكنها اتخاذ قرار لتمكين جميع الخدمات السحابية في المؤسسة. مشكلة أخرى هي عندما يطلب من مجموعة مالك المستأجر إدارة جميع الخدمات. لا يتوسع هذا الأسلوب للمؤسسات الكبيرة.
  • لا يوجد مفهوم للمستأجر الفرعي/الفائق. لسبب ما، تستمر هذه الأسطورة في تكرار نفسها. ينطبق هذا المفهوم على مستأجري Azure Active Directory B2C أيضا. أسمع عدة مرات، "بيئة B2C الخاصة بي موجودة في مستأجر XYZ الخاص بي"، أو "كيف أعمل نقل مستأجر Azure الخاص بي إلى مستأجر Microsoft 365 الخاص بي؟"
  • يركز هذا المستند في الغالب على السحابة التجارية في جميع أنحاء العالم، لأن هذا ما يستخدمه معظم العملاء. من المفيد أحيانا معرفة السحب ذات السيادة. السحب السيادية لها آثار أخرى لمناقشتها خارج نطاق هذه المناقشة.

مقالات هوية الأساس

هناك الكثير من الوثائق حول النظام الأساسي للهويات في Microsoft - Microsoft Entra ID. بالنسبة للأشخاص الذين بدأوا للتو، غالبا ما تشعر بالرضا. حتى بعد أن تتعرف على ذلك، يمكن أن يكون مواكبة الابتكار والتغيير المستمرين أمرا صعبا. في تفاعلات العملاء، غالبا ما أجد أعمل ك "مترجم" بين أهداف الأعمال ونهج "جيد، أفضل، أفضل" لمعالجة هذه المخاوف (و"ملاحظات المنحدر" البشرية لهذه المقالات). نادرا ما تكون هناك إجابة مثالية والقرار "الصحيح" هو توازن بين عوامل الخطر المختلفة. التالي بعض الأسئلة الشائعة ومناطق الارتباك التي أميل إلى مناقشتها مع العملاء.

توفير

Microsoft Entra ID لا يحل نقص الحوكمة في عالم هويتك! يجب أن تكون إدارة الهوية عنصرا مهما مستقلا عن أي قرارات سحابية. تتغير متطلبات الحوكمة بمرور الوقت، وهذا هو السبب في أنه برنامج وليس أداة.

Microsoft Entra الاتصال مقابل Microsoft Identity Manager (MIM) مقابل شيء آخر (جهة خارجية أو مخصص)؟ احفظ مشاكلك الآن وفي المستقبل وانتقل إلى Microsoft Entra Connect. هناك جميع أنواع الذكاء في هذه الأداة لمعالجة تكوينات العملاء الغريبة والابتكارات المستمرة.

بعض حالات الحافة التي قد تدفع نحو بنية أكثر تعقيدا:

  • لدي غابات AD متعددة دون اتصال بالشبكة بينها. هناك خيار جديد يسمى Cloud Provisioning.
  • ليس لدي Active Directory، ولا أريد تثبيته. يمكن تكوين Microsoft Entra Connect للمزامنة من LDAP (قد يكون الشريك مطلوبا).
  • أحتاج إلى توفير نفس العناصر لعدة مستأجرين. هذا السيناريو غير مدعوم تقنيا ولكنه يعتمد على تعريف "نفسه".

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

يدعم XYZ SaaS توفير Just-in-Time (JIT)، لماذا تطلب مني المزامنة؟ راجع الفقرة السابقة. تحتاج العديد من التطبيقات إلى معلومات "ملف التعريف" للوظائف. لا يمكنك الحصول على GAL إذا لم تكن جميع الكائنات الممكنة للبريد متوفرة. وينطبق الشيء نفسه على توفير المستخدم في التطبيقات المتكاملة مع Microsoft Entra ID.

المصادقة

مزامنة تجزئة كلمة المرور (PHS) مقابل مصادقة المرور (PTA) مقابل الاتحاد.

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

يمكن بعض العملاء الاتحاد + PHS بشكل أساسي من أجل:

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

مثال على محادثة لوح المعلومات.

يوضح هذا النوع من رسم لوح المعلومات مكان تطبيق نهج الأمان ضمن تدفق طلب المصادقة. في هذا المثال، يتم تطبيق النهج التي يتم فرضها من خلال خدمة اتحاد Active Directory (AD FS) على طلب الخدمة الأول، ولكن ليس طلبات الخدمة اللاحقة. هذا السلوك هو سبب واحد على الأقل لنقل عناصر التحكم في الأمان إلى السحابة قدر الإمكان.

لقد كنا نطارد حلم تسجيل الدخول الأحادي (SSO) طالما أستطيع أن أتذكر. يعتقد بعض العملاء أنه يمكنهم تحقيق تسجيل الدخول الأحادي عن طريق اختيار موفر الاتحاد "الصحيح" (STS). يمكن أن تساعد Microsoft Entra ID بشكل كبير في تمكين قدرات تسجيل الدخول الأحادي، ولكن لا يوجد STS سحري. هناك عدد كبير جدا من أساليب المصادقة "القديمة" التي لا تزال تستخدم للتطبيقات الهامة. يمكن أن يعالج توسيع Microsoft Entra ID مع حلول الشركاء العديد من هذه السيناريوهات. تسجيل الدخول الأحادي هو استراتيجية ورحلة. لا يمكنك الوصول إلى هناك دون الانتقال نحو معايير التطبيقات. فيما يتعلق بهذه المقالة هي رحلة إلى المصادقة بدون كلمة مرور ، والتي لا تحتوي أيضا على إجابة سحرية.

المصادقة متعددة العوامل (MFA) ضرورية اليوم (هنا لمزيد من المعلومات). أضف إليها تحليلات سلوك المستخدم ولديك حل يمنع الهجمات الإلكترونية الأكثر شيوعا. حتى خدمات المستهلكين تتحرك لطلب المصادقة متعددة العوامل. ومع ذلك، ما زلت ألتقي بالعديد من العملاء الذين لا يرغبون في الانتقال إلى نهج المصادقة الحديثة . أكبر وسيطة أسمعها هي أنها تؤثر على المستخدمين والتطبيقات القديمة. في بعض الأحيان قد تساعد الركلة الجيدة العملاء على التحرك - Exchange Online التغييرات المعلن عنها. تتوفر الآن الكثير من التقارير Microsoft Entra لمساعدة العملاء في هذا الانتقال.

إذن

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

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

محرك النهج في Microsoft Entra ID.

يسمح الجمع بين كل هذه الإشارات معا بنهج ديناميكية مثل هذه:

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

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

بالإضافة إلى Microsoft Entra ID، فإن الخدمات والتطبيقات المختلفة لها نماذج تخويل خاصة بها. وتتم مناقشة بعض هذه النماذج لاحقا في قسم التفويض.

تدقيق

Microsoft Entra ID قدرات مفصلة للتدقيق وإعداد التقارير. ومع ذلك، فإن هذه التقارير ليست عادة المصدر الوحيد للمعلومات اللازمة لاتخاذ قرارات أمنية. اطلع على مزيد من المناقشة حول هذا الموضوع في قسم التفويض.

لا يوجد Exchange

لا تذعر! لا يتم إهمال Exchange (أو SharePoint، وما إلى ذلك). لا تزال خدمة أساسية. ما أعنيه هو أنه لبعض الوقت الآن، يقوم موفرو التكنولوجيا بنقل تجارب المستخدمين (UX) لتشمل مكونات خدمات متعددة. في Microsoft 365، مثال بسيط هو "المرفقات الحديثة" حيث يتم تخزين مرفقات البريد الإلكتروني في SharePoint Online أو OneDrive.

إرفاق ملف بالبريد الإلكتروني.

بالنظر إلى عميل Outlook، يمكنك رؤية العديد من الخدمات "المتصلة" كجزء من هذه التجربة، وليس فقط Exchange. تتضمن الأمثلة مجموعات Microsoft Entra ID وMicrosoft Search والتطبيقات وملف التعريف والتوافق وMicrosoft 365.

واجهة Outlook مع وسائل شرح.

اقرأ عن إطار عمل Microsoft Fluid لمعاينة الإمكانات القادمة. في المعاينة الآن، يمكنني قراءة محادثات Teams والرد عليها مباشرة في Outlook. في الواقع، عميل Teams هو أحد الأمثلة الأكثر بروزا على هذه الاستراتيجية.

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

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

لجميع المعجبين والمطورين في SharePoint، يرجى التوقف عن سؤال "كيف يمكنني القيام ب XYZ في SharePoint Online؟" استخدم Power Automate (أو Flow) لسير العمل، إنه نظام أساسي أكثر قوة بكثير. استخدم Azure Bot Framework لإنشاء تجربة مستخدم أفضل لقائمة عناصر 500-K. ابدأ باستخدام Microsoft Graph بدلا من CSOM. يتضمن Microsoft Teams SharePoint ولكن أيضا عالما أكثر. هناك العديد من الأمثلة الأخرى التي يمكنني سردها. هناك عالم واسع ورائع هناك. افتح الباب وابدأ الاستكشاف.

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

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

خيارات بنية المستأجر

مستأجر واحد مقابل مستأجر متعدد

بشكل عام، يجب أن يكون لدى معظم العملاء مستأجر إنتاج واحد فقط. هناك العديد من الأسباب التي تجعل العديد من المستأجرين صعبين (امنحه بحث Bing) أو اقرأ هذا المستند التقني. في الوقت نفسه، لدى العديد من عملاء المؤسسات الذين أعمل معهم مستأجر آخر (صغير) لتعلم تكنولوجيا المعلومات واختبارها وتجريبها. أصبح الوصول إلى Azure عبر المستأجرين أسهل مع Azure Lighthouse. لدى Microsoft 365 والعديد من خدمات SaaS الأخرى حدود للسيناريوهات عبر المستأجرين. هناك الكثير الذي يجب مراعاته في Microsoft Entra سيناريوهات B2B.

ينتهي العديد من العملاء بمستأجري إنتاج متعددين بعد الدمج والاستحواذ (M&A) ويريدون الدمج. هذا ليس بسيطا اليوم ويتطلب Microsoft Consulting Services (MCS) أو شريكا بالإضافة إلى برنامج تابع لجهة خارجية. هناك عمل هندسي مستمر لمعالجة سيناريوهات مختلفة مع عملاء متعددي المستأجرين في المستقبل.

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

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

في هذه السيناريوهات متعددة المستأجرين، غالبا ما يرغب العملاء في الاحتفاظ ببعض التكوين كما هو عبر المستأجرين، أو الإبلاغ عن تغييرات التكوين والانحرافات. غالبا ما يعني هذا الانتقال من التغييرات اليدوية إلى التكوين كتعلم برمجي. يقدم دعم Microsoft Premiere ورشة عمل لهذه الأنواع من المتطلبات استنادا إلى عنوان IP العام هذا: https://Microsoft365dsc.com.

متعدد المواقع الجغرافية

إلى متعدد المواقع الجغرافية أم لا إلى متعدد المواقع الجغرافية. هذا هو السؤال. باستخدام Microsoft 365 Multi-Geo، يمكنك توفير البيانات وتخزينها الثابتة في المواقع الجغرافية التي تختارها لتلبية متطلبات موقع البيانات . هناك العديد من المفاهيم الخاطئة حول هذه الإمكانية. ضع النقاط التالية في الاعتبار:

  • لا يوفر مزايا الأداء. قد يزيد الأداء سوءا إذا لم يكن تصميم الشبكة صحيحا. احصل على الأجهزة "قريبة" من شبكة Microsoft، وليس بالضرورة إلى بياناتك.
  • إنه ليس حلا لتوافق القانون العام لحماية البيانات (GDPR). لا يركز القانون العام لحماية البيانات (GDPR) على سيادة البيانات أو مواقع التخزين. هناك أطر امتثال أخرى لسيادة البيانات أو مواقع التخزين.
  • لا يحل تفويض الإدارة (انظر أدناه) أو حواجز المعلومات.
  • إنها ليست هي نفسها متعددة المستأجرين وتتطلب المزيد من مهام سير عمل تزويد المستخدمين .
  • لا ينقل المستأجر (Microsoft Entra ID) إلى جغرافية أخرى.

تفويض الإدارة

في معظم المؤسسات الكبيرة، يعد الفصل بين الواجبات والتحكم في الوصول استنادا إلى الدور (RBAC) حقيقة ضرورية. سأعتذر قبل الموعد المحدد هذا النشاط ليس بسيطا كما يريده بعض العملاء. تختلف متطلبات العملاء والقانونية والتوافق والمتطلبات الأخرى، وأحيانا تتعارض في جميع أنحاء العالم. غالبا ما تكون البساطة والمرونة على جانبين متقابلين من بعضهما البعض. لا تخطئوا في فهمي، يمكننا القيام بعمل أفضل في هذا الهدف. كانت هناك (وسوف تكون) تحسينات كبيرة مع مرور الوقت. تفضل بزيارة مركز تكنولوجيا Microsoft المحلي الخاص بك للعمل على النموذج الذي يناسب متطلبات عملك دون قراءة 379230 مستندات! هنا، أركز على ما يجب أن تفكر به وليس لماذا الأمر بهذه الطريقة. الخروج هي خمسة مجالات مختلفة للتخطيط لبعض الأسئلة الشائعة التي أواجهها.

مراكز إدارة Microsoft Entra ID وMicrosoft 365

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

  • مسؤول عمومي: يجب حماية هذا الدور "القوي بالكامل" حماية عالية تماما كما تفعل في الأنظمة الأخرى. تتضمن التوصيات النموذجية: لا يوجد تعيين دائم واستخدام Microsoft Entra إدارة الهويات المتميزة (PIM)؛ ومصادقة قوية؛ وما إلى ذلك. ومن المثير للاهتمام أن هذا الدور لا يمنحك حق الوصول إلى كل شيء بشكل افتراضي. عادة ما أرى ارتباكا حول الوصول إلى التوافق والوصول إلى Azure، تمت مناقشته لاحقا. ومع ذلك، يمكن لهذا الدور دائما تعيين الوصول إلى خدمات أخرى في المستأجر.
  • مسؤولو خدمة محددون: تستهلك بعض الخدمات (Exchange وSharePoint وPower BI وما إلى ذلك) أدوارا إدارية عالية المستوى من Microsoft Entra ID. هذا السلوك غير متسق عبر جميع الخدمات وهناك المزيد من الأدوار الخاصة بالخدمة التي تمت مناقشتها لاحقا.
  • دالة وظيفية: هناك قائمة طويلة (ومتزايدة) من الأدوار التي تركز على عمليات محددة (المدعو الضيف، وما إلى ذلك). بشكل دوري، تتم إضافة المزيد من هذه الأدوار بناء على احتياجات العملاء.

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

ملاحظة: يحتوي مركز مسؤولي Microsoft 365 على واجهة أكثر سهولة في الاستخدام ولكنه يحتوي على مجموعة فرعية من الإمكانات مقارنة بتجربة المسؤول Microsoft Entra. يستخدم كلا المدخلين نفس الأدوار Microsoft Entra، لذلك تحدث التغييرات في نفس المكان. تلميح: إذا كنت تريد واجهة مستخدم مسؤول مركزة على إدارة الهوية دون كل فوضى Azure، فاستخدم https://aad.portal.azure.com.

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

القدرة على إنشاء أدوار مخصصة هو سؤال شائع. هذه الإمكانية محدودة في Microsoft Entra اليوم (كما هو موضح لاحقا)، ولكنها ستنمو في القدرات بمرور الوقت. أعتقد أن هذه الأدوار المخصصة قابلة للتطبيق على الوظائف في Microsoft Entra ID وقد لا تمتد "لأسفل" نموذج التسلسل الهرمي (كما تمت مناقشته سابقا). كلما تعاملت مع "مخصص"، أميل إلى العودة إلى مبدأ "بسيط هو أفضل".

سؤال شائع آخر هو القدرة على تحديد نطاق الأدوار لمجموعة فرعية من الدليل. أحد الأمثلة على ذلك هو شيء مثل "مسؤول مكتب المساعدة للمستخدمين في الاتحاد الأوروبي فقط". تهدف الوحدات الإدارية إلى معالجة هذا السيناريو. كما هو موضح سابقا، أعتقد أن هذه النطاقات قابلة للتطبيق على الوظائف في Microsoft Entra ID وقد لا تمتد "لأسفل". لا معنى لبعض الأدوار للنطاق (المسؤولون العموميون ومسؤولو الخدمة وما إلى ذلك).

اليوم، تتطلب جميع هذه الأدوار عضوية مباشرة (أو تعيين ديناميكي إذا كنت تستخدم Microsoft Entra PIM). وهذا يعني أنه يجب على العملاء إدارة هذا الدور مباشرة في Microsoft Entra ID، ولا يمكن أن تستند هذه الأدوار إلى عضوية مجموعة أمان. لست من محبي إنشاء البرامج النصية لإدارة هذه الأدوار لأنها ستحتاج إلى التشغيل بحقوق مرتفعة. أوصي عموما بتكامل واجهة برمجة التطبيقات مع أنظمة العمليات مثل ServiceNow أو استخدام أدوات حوكمة الشركاء مثل Saviynt. هناك عمل هندسي مستمر لمعالجة هذه المشكلة بمرور الوقت.

ذكرت Microsoft Entra PIM عدة مرات. هناك حل لإدارة الوصول المتميز (PAM) ل Microsoft Identity Manager (MIM) المقابل لعناصر التحكم المحلية. قد تحتاج أيضا إلى إلقاء نظرة على محطات عمل الوصول المتميز (PAWs) Microsoft Entra ID Governance. هناك العديد من أدوات الجهات الخارجية أيضا، والتي يمكن أن تمكن رفع الدور في الوقت المناسب، بما يكفي، والديناميكية. عادة ما تكون هذه الإمكانية جزءا من مناقشة أكبر لتأمين بيئة.

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

مداخل Microsoft Defender XDR وMicrosoft Purview

البريد الإلكتروني & أدوار التعاون في مدخل Microsoft Defenderو*مجموعات الأدوار لحلول Microsoft Purview في مدخل Microsoft Purview هي مجموعة من "مجموعات الأدوار"، والتي تكون منفصلة ومتميزة عن الأدوار Microsoft Entra. قد يكون هذا مربكا لأن بعض مجموعات الأدوار هذه لها نفس اسم أدوار Microsoft Entra (على سبيل المثال، قارئ الأمان)، ولكن يمكن أن يكون لها عضوية مختلفة. أفضل استخدام أدوار Microsoft Entra. تتكون كل مجموعة أدوار من "دور" واحد أو أكثر (راجع ما أعنيه حول إعادة استخدام نفس الكلمة؟) ولديك أعضاء من Microsoft Entra ID، وهي كائنات ممكنة للبريد الإلكتروني. يمكنك أيضا إنشاء مجموعة أدوار بنفس اسم الدور، والتي قد تحتوي على هذا الدور أو لا تحتوي عليه (تجنب هذا الارتباك).

بمعنى ما، هذه الأذونات هي تطور لنموذج مجموعات دور Exchange. ومع ذلك، Exchange Online لها واجهة إدارة مجموعة الأدوار الخاصة بها. يتم تأمين بعض مجموعات الأدوار في Exchange Online وإدارتها من Microsoft Entra ID أو مداخل Microsoft Defender XDR وMicrosoft Purview، ولكن قد يكون للبعض الآخر نفس الأسماء أو أسماء مشابهة وتتم إدارتها في Exchange Online (إضافة إلى الارتباك). أوصيك بتجنب استخدام واجهة المستخدم Exchange Online ما لم تكن بحاجة إلى نطاقات لإدارة Exchange.

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

تتطلب مجموعات الأدوار هذه أيضا عضوية مباشرة ولا يمكن أن تحتوي على مجموعات Microsoft Entra. لسوء الحظ، اليوم لا يتم دعم مجموعات الأدوار هذه من قبل Microsoft Entra PIM. مثل الأدوار Microsoft Entra، أميل إلى التوصية بإدارة مجموعات الأدوار هذه من خلال واجهات برمجة التطبيقات أو منتج حوكمة الشريك مثل Saviynt أو غيرها.

تمتد أدوار مدخل Microsoft Defender ومدخل Microsoft Purview إلى Microsoft 365 ولا يمكنك تحديد نطاق مجموعات الأدوار هذه إلى مجموعة فرعية من البيئة (كما تفعل مع الوحدات الإدارية في Microsoft Entra ID). يسأل العديد من العملاء كيف يمكنهم الحذف الفرعي. على سبيل المثال، "إنشاء نهج DLP لمستخدمي الاتحاد الأوروبي فقط." اليوم، إذا كانت لديك حقوق لدالة معينة في مداخل Microsoft Defender XDR وMicrosoft Purview، فلديك حقوق لكل ما تغطيه هذه الدالة في المستأجر. ومع ذلك، العديد من النهج لديها قدرات لاستهداف مجموعة فرعية من البيئة (على سبيل المثال، "جعل هذه التسميات متاحة لهؤلاء المستخدمين فقط"). الحوكمة السليمة والاتصالات عنصران رئيسيان لتجنب الصراعات. يختار بعض العملاء تنفيذ نهج "التكوين كتعليق برمجي" لمعالجة التفويض الفرعي في مداخل Microsoft Defender XDR وMicrosoft Purview. تدعم بعض الخدمات المحددة التفويض الفرعي (راجع القسم التالي).

خاص بالخدمة

كما ذكرنا سابقا، يتطلع العديد من العملاء إلى تحقيق نموذج تفويض أكثر دقة. مثال شائع: "إدارة خدمة XYZ فقط لمستخدمي ومواقع القسمة X" (أو بعد آخر). تعتمد القدرة على القيام بذلك على كل خدمة وهي غير متسقة عبر الخدمات والقدرات. بالإضافة إلى ذلك، قد يكون لكل خدمة نموذج RBAC منفصل وفريد. بدلا من مناقشة كل هذه النماذج (التي ستستغرق إلى الأبد)، أقوم بإضافة روابط ذات صلة لكل خدمة. هذه القائمة غير مكتملة، ولكن يمكن أن تساعدك على البدء.

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • eDiscovery - (.. /compliance/index.yml)
    • تصفية الأذونات - (.. /compliance/index.yml)
    • حدود التوافق - (.. /compliance/set-up-compliance-boundaries.md)
    • eDiscovery (Premium) - (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • متعدد المواقع الجغرافية - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

ملاحظة

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

  • Power Platform - (/power-platform/admin/admin-documentation)

    • Power Apps - (/power-platform/admin/wp-security)

      ملاحظة

      هناك أنواع متعددة مع اختلافات في نماذج المسؤول/التفويض.

    • Power Automate - (/power-automate/environments-overview-admin)

    • Power BI - (/power-bi/service-admin-governance)

      ملاحظة: أمان النظام الأساسي للبيانات وتفويضها (الذي يعد Power BI مكونا) منطقة معقدة.

  • Intune - (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender لنقطة النهاية - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps - (/cloud-app-security/manage-admins)

  • Stream - (/stream/assign-administrator-user-role)

  • حواجز المعلومات - (.. /compliance/information-barriers.md)

سجلات النشاط

يحتوي Microsoft 365 على سجل تدقيق موحد. إنه سجل مفصل للغاية، ولكن لا تقرأ الكثير في الاسم. قد لا يحتوي على كل ما تريده أو تحتاجه لاحتياجات الأمان والتوافق. أيضا، بعض العملاء مهتمون جدا في التدقيق (Premium).

تتضمن أمثلة سجلات Microsoft 365 التي يتم الوصول إليها من خلال واجهات برمجة التطبيقات الأخرى الميزات التالية:

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

من منظور تفويض المسؤول، لا تحتوي معظم سجلات نشاط Microsoft 365 على نموذج RBAC مضمن. إذا كان لديك إذن لرؤية سجل، فيمكنك رؤية كل شيء فيه. ومن الأمثلة الشائعة على متطلبات العميل: "أريد أن أكون قادرا على الاستعلام عن النشاط لمستخدمي الاتحاد الأوروبي فقط" (أو بعد آخر). لتحقيق هذا المطلب، نحتاج إلى نقل السجلات إلى خدمة أخرى. في سحابة Microsoft، نوصي بنقلها إما إلى Microsoft Sentinel أو Log Analytics.

رسم تخطيطي عالي المستوى:

رسم تخطيطي لمصادر السجل لبرنامج الأمان والتوافق.

يمثل الرسم التخطيطي القدرات المضمنة لإرسال السجلات إلى مراكز الأحداث و/أو Azure Storage و/أو Azure Log Analytics. لا تتضمن جميع الأنظمة هذا خارج الصندوق حتى الآن. ولكن هناك نهج أخرى لإرسال هذه السجلات إلى نفس المستودع. على سبيل المثال، راجع حماية Teams باستخدام Microsoft Sentinel.

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

لا يجب توجيه السجلات إلى مكان واحد فقط. قد يكون من المفيد أيضا دمج سجلات Microsoft 365 مع Microsoft Defender for Cloud Apps أو نموذج RBAC مخصص في Power BI. المستودعات المختلفة لها فوائد وجماهير مختلفة.

تجدر الإشارة إلى أن هناك نظام تحليلات مدمجا غنيا للأمان والتهديدات والثغرات الأمنية وما إلى ذلك في خدمة تسمى Microsoft Defender XDR.

يرغب العديد من العملاء الكبار في نقل بيانات السجل هذه إلى نظام جهة خارجية (على سبيل المثال، SIEM). هناك نهج مختلفة لهذه النتيجة، ولكن بشكل عام مراكز أحداث AzureوGraph هي نقاط بداية جيدة.

Azure

غالبا ما يطلب مني ما إذا كانت هناك طريقة لفصل الأدوار عالية الامتيازات بين Microsoft Entra ID وAzure وSaaS (على سبيل المثال: المسؤول العام ل Microsoft 365 ولكن ليس Azure). ليس حقًا. هناك حاجة إلى بنية متعددة المستأجرين إذا كان الفصل الإداري الكامل مطلوبا، ولكن هذا يضيف تعقيدا كبيرا (كما تمت مناقشته سابقا). جميع هذه الخدمات هي جزء من نفس حد الأمان/الهوية (كما هو موضح في نموذج التسلسل الهرمي).

من المهم فهم العلاقات بين الخدمات المختلفة في نفس المستأجر. أعمل مع العديد من العملاء الذين يبنون حلول أعمال تمتد عبر Azure وMicrosoft 365 وPower Platform (وغالبا أيضا الخدمات السحابية المحلية والجهات الخارجية). مثال شائع واحد:

  1. أريد التعاون في العمل على مجموعة من المستندات/الصور/إلخ (Microsoft 365)
  2. إرسال كل واحد منهم من خلال عملية الموافقة (Power Platform)
  3. بعد الموافقة على جميع المكونات، قم بتجميع هذه العناصر في تسليم (تسليمات) موحد (Azure) Microsoft Graph API هو أفضل صديق لديك هنا. ليس مستحيلا، ولكن أكثر تعقيدا بكثير لتصميم حل يمتد عبر مستأجرين متعددين.

يتيح Azure Role-Based Access Control (RBAC) إدارة الوصول الدقيقة ل Azure. باستخدام التحكم في الوصول استنادا إلى الدور، يمكنك إدارة الوصول إلى الموارد عن طريق منح المستخدمين أقل الأذونات اللازمة لأداء وظائفهم. التفاصيل خارج نطاق هذا المستند، ولكن لمزيد من المعلومات حول التحكم في الوصول استنادا إلى الدور، راجع ما هو التحكم في الوصول استنادا إلى الدور (RBAC) في Azure؟ التحكم في الوصول استنادا إلى الدور مهم ولكنه جزء فقط من اعتبارات الحوكمة ل Azure. يعد Cloud Adoption Framework نقطة بداية رائعة لمعرفة المزيد. أحب كيف يرشد صديقي ، أندريس رافينت، العملاء خطوة بخطوة من خلال مختلف المكونات لاتخاذ قرار بشأن النهج. عرض عالي المستوى لعناصر مختلفة (ليس جيدا مثل عملية الوصول إلى نموذج العميل الفعلي) هو شيء من هذا القبيل:

عرض عالي المستوى لمكونات Azure للإدارة المفوضة.

كما ترى من الصورة أعلاه، يجب اعتبار العديد من الخدمات الأخرى جزءا من التصميم (على سبيل المثال: نهج Azureومخططات Azureومجموعات الإدارة وما إلى ذلك).

استنتاج

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