إدارة الهوية والوصول

كلمة مرور واحدة، وحساب كامل

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

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

المستخدم الجذر، ومستخدمو IAM، والأدوار

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

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

فحصان منفصلان: التحقق من الهوية، ثم التفويض

تخيّل مطوّراً يسجّل الدخول بكلمة مرور ورمز MFA، ثم يطلب تشغيل جهاز افتراضي جديد. تُجري AWS فحصين متمايزين، بالترتيب، لا فحصاً واحداً مدمجاً.

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

الحد الأدنى من الصلاحيات: ابدأ ضيقاً لا واسعاً

لنفترض أن دور مطوّر يحتاج فقط قراءة ملفات من صندوق تقارير واحد ولا شيء غيره. تمنح سياسة الحد الأدنى من الصلاحيات هذا بالضبط: إجراء s3:GetObject، مقتصراً على ذلك الصندوق الواحد، لا أكثر. قارن هذا بسياسة فضفاضة تمنح وصولاً كاملاً لـ S3 "احتياطاً": إن أُسيء استخدام بيانات اعتماد هذا الدور، تحصر السياسة الضيقة الضرر بوصول قراءة صندوق واحد، بينما تسلّم الواسعة كل صندوق في الحساب.

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

الحد الفاصل: المجموعات مقابل الأدوار

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

الالتباس: كلمة مرور قوية كافية

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

إشارات الامتحان: مطابقة السيناريو بالأداة

إلى أين يقودك هذا

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