تخفيض أدوار المستخدمين في Amazon Quick

تُعد إدارة أذونات الوصول بفعالية جانبًا مهمًا للحفاظ على بيئة آمنة وتعاونية في Amazon Quick. يدعم Quick خيارات متنوعة لإدارة المستخدمين مصممة لاستيعاب أنواع مختلفة من الهويات واحتياجات المؤسسات. يمكنك توفير المستخدمين محليًا من خلال Quick Identity أو إدارتهم عبر مزودي هويات المؤسسة مثل AWS IAM Identity Center أو Active Directory. تتيح هذه الأنظمة تعيين أدوار المستخدمين بما في ذلك Admin وAuthor وReader وتجميعها وفقًا للوظائف ومتطلبات الأمان. ومع انضمام أعضاء الفريق أو تغيير أدوارهم أو مغادرتهم للمؤسسة، يجب على المسؤولين ضمان سلاسة هذه التحولات دون تعطيل سير العمل أو خلق ثغرات أمنية.

تُهم مراجعات الوصول المنتظمة للحفاظ على الأمان في بيئة Quick الخاصة بك. خطّط لتدقيقات شهرية أو ربع سنوية لأدوار المستخدمين للتأكد من أن الجميع يملكون الأذونات المناسبة. عندما تتغير مسؤوليات أعضاء الفريق، انقل ملكية لوحات المعلومات والتحليلات الخاصة بهم بشكل استباقي لمنع وجود موارد يتيمة. هذه الممارسة، الموصى بها في AWS Well-Architected Framework، تساعد في الحفاظ على استمرارية التصورات الحرجة للأعمال.

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

لماذا التخفيض؟

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

تعتمد أسعار Quick أيضًا على الدور: يدفع المؤلفون (Authors) والمسؤولون (Admins) رسمًا شهريًا ثابتًا لكل مستخدم، بينما يستخدم القراء (Readers) تسعيرًا قائمًا على الجلسات. يمكن للمؤسسات التي لديها مستخدمون مُوفَّرون كمؤلفين ولا يستهلكون سوى لوحات المعلومات تقليل التكاليف بشكل كبير عبر ضبط أدوارهم لتصبح Reader. للحصول على تفاصيل التسعير الحالية، راجع صفحة تسعير Amazon Quick.

لمزيد من التحكم الأكثر دقة إلى جانب الأدوار المدمجة في Amazon Quick، فكّر في استكمال تعيينات الأدوار بـ الأذونات المخصصة (Custom Permissions)، التي تقيّد قدرات محددة ضمن مستوى الدور. يوفر تكامل Amazon Quick مع AWS Identity and Access Management (IAM) حدود أذونات إضافية تكمل نظام الأدوار الأساسي.

نطاق هذه المقالة

على الرغم من أن الخطوات الدقيقة تعتمد على نوع هوية المستخدم، تركز هذه المقالة بشكل أساسي على مستخدمي Amazon Quick Identity (يُطلق عليهم أيضًا اسم المستخدمين المُدارين بواسطة Quick). عادةً ما تتم إدارة تغييرات الأدوار للمستخدمين الذين يتم التحقق منهم عبر IAM Identity Center أو Active Directory من خلال تعيينات المجموعات في مزود الهوية الخارجي الخاص بهم. إذا كانت بيئتك تستخدم IAM Identity Center، يُنفَّذ تخفيض الدور بنقل المستخدم من مجموعة IdC إلى أخرى (على سبيل المثال، من مجموعة Quick-Admins إلى مجموعة Quick-Readers). ولا يلزم أي تسلسل تخفيض تدريجي.

على الرغم من أن وحدة تحكم Amazon Quick لا توفر مسار تخفيض مباشرًا لجميع تحولات الأدوار (تحديدًا، لا يمكنك التخفيض من Admin إلى Reader أو من Author إلى Reader مباشرةً عبر واجهة وحدة التحكم)، توجد حلان موثوقان: طريقة يدوية للحذف وإعادة الإنشاء، ونهج يستخدم واجهة سطر أوامر AWS (AWS CLI). نستعرض معك كلتا التقنيتين لمساعدتك في الحفاظ على إدارة وصول سليمة مع تطور فريقك.

المتطلبات الأساسية

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

فهم أدوار Amazon Quick

يوفر Amazon Quick مستويي اشتراك بمجموعات أدوار مختلفة:

لا توفر وحدة التحكم طريقة مباشرة للتنزيل من أي مستوى مؤلف إلى أي مستوى قارئ. إن update-user API تفرض القيد نفسه، وترفض التنزيل المباشر برسالة خطأ "You cannot downgrade a user role".

تُظهر لقطة الشاشة التالية صفحة إدارة مستخدمي Amazon Quick Suite، حيث لا توفر وحدة التحكم أي تحكم مباشر لنقل مستخدم من مستوى مؤلف إلى مستوى قارئ. ويوضح هذا سبب ضرورة الطرق الواردة في هذه المقالة.

الشكل 1: صفحة إدارة مستخدمي Amazon Quick Suite

تعمل طريقة التنزيل خطوة بخطوة في CLI بشكل موثوق للأدوار القديمة الخاصة بذكاء الأعمال فقط (مسؤول، مؤلف، قارئ)، وفق هذا التسلسل:

Admin > Author > Restricted Reader > Reader

يعمل هذا التسلسل نفسه أيضاً مع مستخدمي Pro، طالما أن الخطوات الوسيطة تستخدم الأدوار القديمة. على سبيل المثال، يكتمل التحويل Author Pro > Author > Restricted Reader > Reader Pro بنجاح.

اعتبارات مهمة قبل إجراء التغييرات

عند تنفيذ تغييرات الأدوار من خلال أي من الطريقتين، هناك عدة عوامل مهمة يجب وضعها في الاعتبار. أولاً، تحقق من أن جميع المستخدمين في قائمتك من مستخدمي Admin أو Author حاليًا قبل إجراء التغييرات. قد تؤدي محاولة تخفيض مستوى المستخدمين الذين يمتلكون بالفعل أذونات أقل إلى حدوث أخطاء. تنطبق أسئلة ملكية الموارد حتى عند استخدام طريقة CLI. لن يتمكن المستخدمون الذين يتم تخفيض مستواهم بعد الآن من تعديل الموارد التي كانوا يملكونها سابقًا. بالنسبة للمؤسسات الأكبر التي تستخدم طريقة CLI، فكّر في تحميل عناوين البريد الإلكتروني للمستخدمين من ملف CSV بدلاً من تضمينها يدويًا في الكود. إذا كنت تستخدم AWS CloudShell بدلاً من تثبيت CLI محلي، يمكنك الاستغناء عن تحديد AWS Region لأن AWS CloudShell يستخدم تلقائيًا سياق Region الخاص بوحدة التحكم الحالية لديك.

نقل ملكية الأصول (قم بذلك أولاً)

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

الخيار 1: نقل الملكية استباقيًا إلى مسؤول آخر

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

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

الشكل 2: نقل ملكية الأصل إلى مستخدم آخر

الخيار 2: استخدام نقل الأصول المجمّع في Amazon Quick من صفحة Admin

إذا كان المستخدم يملك أصولًا كثيرة، فقد تصبح الطريقة اليدوية غير فعالة. في هذه الحالة، يمكنك استخدام ميزة Manage assets المتاحة في قسم Admin من Quick. بهذه الأداة، يمكن للمسؤولين إجراء عمليات نقل ملكية مجمّعة أو تحديث أذونات المشاركة لعدة أصول في وقت واحد. تعمل هذه الميزة على تبسيط عملية إعادة التعيين بشكل كبير، خاصة عند إخراج المستخدمين من الخدمة أو إدارة التغييرات التنظيمية. لمزيد من التفاصيل حول كيفية استخدام هذه الميزة، راجع الوثائق الرسمية Managing assets in Amazon Quick .

الخيار 3: مشاركة الأصول مع مجموعة مستخدمي Quick

استراتيجية فعالة أخرى هي مشاركة الأصول مع مجموعة مستخدمين. بالنسبة لمستخدمي Quick Identity، يمكنك إنشاء مجموعة Quick، وإضافة أعضاء الفريق المعنيين، ومشاركة لوحات المعلومات أو مجموعات البيانات مع المجموعة بدلاً من المستخدمين الفرديين. إذا كان حسابك متكاملاً مع IAM Identity Center أو Active Directory، يتم إنشاء مجموعات مكافئة وإدارتها في تلك الأنظمة، ويستخدم Quick تلك المجموعات الخارجية للتحكم في الوصول بدلاً من المجموعات المُدارة بواسطة Quick. بهذه الطريقة، يظل الوصول إلى الموارد المشتركة سليمًا حتى إذا تم حذف مستخدم معين. إنه نهج مرن يقلل من الحاجة إلى إعادة تعيين الملكية في المستقبل ويساعد في الحفاظ على وصول متسق عبر الفرق المتغيرة.

الطريقة اليدوية: حذف المستخدم وإعادة إنشائه

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

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

الخطوة 1: حذف مستخدم Admin

بعد نقل ملكية جميع الموارد، سجّل الدخول إلى AWS Management Console وانتقل إلى خدمة Amazon Quick. من هناك، اختر أيقونة ملفك الشخصي، ثم اختر Manage Quick، ثم Manage users. عند تحديد موقع مستخدم Admin الذي تريد تخفيض مستواه، اختر أيقونة الحذف بجانب اسمه وأكّد الحذف عند مطالبتك بذلك. يؤدي هذا إلى إزالة وصوله الحالي إلى النظام بالكامل.

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

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

الشكل 3: النقل المدمج للموارد أثناء حذف المستخدم

الخطوة 2: إعادة إنشاء المستخدم بدور Reader

بعد حذف المستخدم بنجاح، ابقَ في صفحة Users واختر Invite users. أدخل عنوان البريد الإلكتروني للمستخدم واختر دور Reader من الخيارات المتاحة. أرسل الدعوة للسماح للمستخدم بالعودة إلى Quick بصلاحياته الجديدة الأكثر تقييدًا.

الخطوة 3: التحقق من تغيير الدور

بعد قبول المستخدم للدعوة:

• تأكد من تحديث صلاحياته إلى Reader.
• تحقق من أنه يمكنه فقط عرض لوحات المعلومات والتقارير.
• تأكد من أنه لا يمكنه تعديل أو إنشاء محتوى.

طريقة CLI: انتقال الدور عبر التنحي التدريجي (موصى به)

إذا كنت تفضل استخدام AWS CLI أو AWS CloudShell، يمكنك تغيير دور المستخدم برمجيًا. نظرًا لأن Quick يتطلب إجراء تغييرات الأدوار بتسلسل محدد، لا يمكنك الانتقال مباشرة من أي Admin إلى أي Reader. بدلًا من ذلك، يجب عليك المرور عبر الأدوار الوسيطة.

ملاحظات مهمة

• استبدل <your-account-id> بمعرّف حساب AWS الخاص بك.
• استبدل <user-name> باسم المستخدم الخاص بالمستخدم.
• استبدل <user-email> بعنوان البريد الإلكتروني للمستخدم.
• إذا كنت تستخدم AWS CLI خارج CloudShell، حدد المعامل --region .
• يجب أن تتطابق قيمة --role مع اسم دور API تمامًا (انظر الجدول السابق).

مثال: المسار القديم (من Admin إلى Reader)

الخطوة 1: تغيير الدور من Admin إلى Author:

aws quicksight update-user \
  --aws-account-id <your-account-id> \
  --user-name <user-name> \
  --namespace default \
  --email <user-email> \
  --role AUTHOR

الخطوة 2: تحديث الدور من Author إلى Restricted Reader:

aws quicksight update-user \
  --aws-account-id <your-account-id> \
  --user-name <user-name> \
  --namespace default \
  --email <user-email> \
  --role RESTRICTED_READER

الخطوة 3: تغيير الدور من Restricted Reader إلى Reader:

aws quicksight update-user \
  --aws-account-id <your-account-id> \
  --user-name <user-name> \
  --namespace default \
  --email <user-email> \
  --role READER

بعد التخفيض: راجع ملفات تعريف الحدود والأذونات المخصصة

تغييرات الأدوار لا تُعدّل تلقائيًا ملفات الحدود (Limit Profiles) أو ملفات الأذونات المخصصة (Custom Permissions). كلاهما يبقى مستقلًا عن دور المستخدم، ويجب مراجعتهما بعد أي تخفيض للمستخدم.

• ملفات الحدود (Limit Profiles) تتحكم في الحدود القصوى لكل مستخدم على الموارد مثل مساحة تخزين الفهارس وساعات الوكيل. إذا كان المستخدم المخفَّض مُعيَّنًا له ملف مناسب لدوره السابق كمسؤول (Admin) أو كاتب (Author)، فأعد تعيين ملف حدود مناسب للقارئ (Reader) لتجنب التخصيص المفرط للموارد. راجع وثائق ملفات الحدود (Limit Profiles) للتفاصيل.
• الأذونات المخصصة (Custom Permissions) تقيّد قدرات محددة ضمن مستوى دور معين. قد لا يعمل ملف مُعيَّن لكاتب (Author) بالشكل المتوقع على قارئ (Reader). إما أن تلغِ تطبيقه في خطوة واجهة السطر الأخيرة (باستخدام --unapply-custom-permissions) أو تعيّن ملفًا مصممًا لمستوى القارئ (Reader).

سكربت لتحديث عدة مستخدمين

استخدم السكربت التالي لتحديث عدة مستخدمين.

#!/bin/bash

# Define AWS account details
AWS_ACCOUNT_ID="<your-account-id>"
REGION="<your-region>"

# Load users from file (format: username,email per line)
# Lines starting with # are treated as comments
INPUT_FILE="users_to_downgrade.txt"

while IFS=',' read -r username email; do
  # Skip comments and empty lines
  [[ "$username" =~ ^#.*$ || -z "$username" ]] && continue

  echo "Processing user: $username"

  # Role transition stages
  for ROLE in AUTHOR RESTRICTED_READER READER; do
    RESULT=$(aws quicksight update-user \
      --aws-account-id "$AWS_ACCOUNT_ID" \
      --user-name "$username" \
      --namespace default \
      --email "$email" \
      --role "$ROLE" \
      --region "$REGION" 2>&1)

    if [ $? -ne 0 ]; then
      echo " ERROR at $ROLE: $RESULT"
      break
    fi

    echo " Transitioned to $ROLE"
    sleep 3
  done

  echo "Role update completed for $username."
done < "$INPUT_FILE"

echo "All user role updates processed!"

وظائف السكربت

ينفّذ هذا السكربت ما يلي:

• يقرأ أسماء المستخدمين وعناوين البريد الإلكتروني من ملف خارجي (يدعم التعليقات باستخدام #).
• يحدّث الدور على ثلاث مراحل: مسؤول > كاتب > قارئ مقيّد > قارئ.
• معالجة الأخطاء توقف انتقال المستخدم إذا فشلت أي خطوة.
• أوامر السكون (Sleep) تتيح وقتًا لتصبح التغييرات سارية المفعول.

بعض الأمور التي يجب مراعاتها عند تشغيل السكربت:

• تأكد من أن المستخدمين حاليًا من مستوى مسؤول أو كاتب قبل التشغيل.
• استخدم اسم مستخدم Quick الفعلي، والذي قد يختلف عن بادئة البريد الإلكتروني في البيئات الموحدة (federated).
• لا حاجة لتحديد المنطقة (Region) في AWS CloudShell.
• يمكنك تعديل السكربت لتحميل المستخدمين من تصدير CSV لـ list-users.

أفضل الممارسات لإدارة وصول المستخدمين

للحفاظ على بيئة Quick الخاصة بك آمنة ومنظمة جيدًا، اتبع أفضل الممارسات التالية:

• راجع أدوار المستخدمين بانتظام (تدقيق شهري أو ربع سنوي).
• انقل ملكية الموارد قبل تغيير الأدوار.
• اتبع مبدأ الامتيازات الأقل.
• استخدم ملفات تعريف Custom Permissions للتحكم الدقيق داخل مستوى الدور.
• شارك الموارد مع المجموعات بدلًا من الأفراد لضمان المرونة.
• استخدم AWS Identity and Access Management لوضع حدود إضافية للأذونات.

التنظيف

بعد إكمال تغييرات أدوار المستخدمين:

• أزل أي مستخدمين تجريبيين.
• تحقق من عدم بقاء أي موارد غير مقصودة.
• احذف سكربتات CLI المؤقتة أو ملفات قوائم المستخدمين.
• تحقق مرة أخرى من أذونات المستخدمين النهائية.

الخلاصة

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

بالنسبة للبيئات التي تستخدم IAM Identity Center، تتم إدارة تغييرات الأدوار من خلال إعادة تعيين مجموعات IdC، وهو ما لا يتطلب تسلسل الخطوات التنازلي الموصوف هنا. للتحكم الإضافي في الحوكمة، استكشف Custom Permissions لقيود على مستوى الميزات، و Restricted Folders لعزل المحتوى على مستوى الملفات.

الموارد

• إدارة وصول المستخدمين في Amazon Quick
• إدارة الأصول في Amazon Quick
• ملفات تعريف Custom Permissions
• أفضل ممارسات AWS IAM
• مدونة AWS Business Intelligence

يسعدنا سماع تجاربك في إدارة المستخدمين. كيف تتعامل مؤسستك مع انتقالات الأدوار في Quick Suite؟ هل طوّرت سكربتات أو عمليات مخصصة لتبسيط هذه التغييرات؟ شارك أفكارك وتحدياتك في التعليقات.

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