أسرارنا كانت مكشوفة للجميع: كيف أنقذتنا ‘إدارة الهوية والوصول’ (IAM) من جحيم الأذونات الفضفاضة؟

يا جماعة الخير، السلام عليكم ورحمة الله.

خليني أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه طول ما أنا عايش في هالمجال. كنا شغالين على مشروع ناشئ، فريق صغير، الحماس “للركب”، والسرعة هي كل إشي بهمنا. في بدايات أي مشروع، بتعرفوا كيف، “يلا شباب، بدنا ننجز”. وكنا كلنا “ولاد عم”، الثقة عمياء، فكان أسهل إشي نعمله هو إنه نعطي الكل مفتاح حساب AWS الرئيسي، صلاحيات مدير كاملة (Administrator Access). ليش؟ عشان ما حدا يوقف شغله عشان “permission denied”. كانت فلسفتنا بسيطة: “إنجز هلأ، ومنأمّن بعدين”.

بقيت الأمور ماشية تمام لشهور. لحد ما إجا هداك اليوم المشؤوم. حوالي الساعة 2 بعد نص الليل، تلفوني برن. على الخط زميلي، صوته برتجف، بحكيلي كلمة وحدة: “عمر، الموقع واقع!”. فتحت اللابتوب بسرعة البرق، وأنا بحاول أدخل على السيرفرات، فش إشي شغال. قاعدة البيانات الأساسية… مختفية! مش بس هيك، الـ S3 Bucket اللي عليه كل ملفات المستخدمين… فاضي!

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

هذيك الليلة، استرجعنا البيانات من نسخة احتياطية قديمة شوي، وخسرنا بيانات يوم كامل، وخسرنا ثقة، وكدنا نخسر المشروع كله. لكن ربحنا درس أهم من أي إشي ثاني: الأمان مش “إشي بنعمله بعدين”. الأمان هو الأساس اللي لازم تبني عليه كل إشي. ومن يومها، صار الـ IAM (إدارة الهوية والوصول) هو الإنجيل تبعنا.

ما هو الـ IAM (إدارة الهوية والوصول)؟ وليش هو مهم هالقد؟

ببساطة، تخيل إن حسابك السحابي (على AWS, Azure, GCP) هو بناية ضخمة فيها مكاتب وغرف حساسة ومخازن. الـ IAM هو موظف الأمن اللي واقف على الباب الرئيسي، ومعه دفتر كبير. ما حدا بفوت أو بطلع أو بستخدم أي إشي جوا البناية إلا بإذنه.

الـ IAM هو النظام اللي بسمحلك تحدد بدقة:

• من (Who): المستخدم (User)، التطبيق (Application)، أو الخدمة (Service).
• يستطيع الوصول إلى ماذا (What): أي موارد (Resources) مثل السيرفرات (EC2)، قواعد البيانات (RDS)، مساحات التخزين (S3).
• وماذا يستطيع أن يفعل (Which Actions): صلاحيات محددة مثل القراءة فقط (ReadOnly)، الكتابة (Write)، الحذف (Delete).

بدون IAM، أنت بتعطي مفتاح البناية كلها لكل موظف، حتى عامل النظافة. مع IAM، أنت بتعطي كل واحد مفتاح الغرفة اللي بحتاجها فقط لا غير. وهذا هو جوهر “مبدأ الامتياز الأقل” (Principle of Least Privilege)، القاعدة الذهبية في عالم أمن المعلومات.

المكونات الأساسية للـ IAM

عشان نفهم كيف نستخدمه صح، لازم نعرف مكوناته الرئيسية:

1. المستخدمون (Users): حسابات للأشخاص (المطورين، مدراء النظام) أو للتطبيقات. كل مستخدم له بيانات اعتماد خاصة (كلمة سر، مفاتيح وصول).
2. المجموعات (Groups): حاوية للمستخدمين. بدل ما تعطي صلاحيات لكل مستخدم لحال، بتحطهم بمجموعة (مثل “Developers”, “Testers”) وبتعطي الصلاحيات للمجموعة كلها. أسهل للإدارة وأقل عرضة للخطأ.
3. السياسات (Policies): هي روح الـ IAM. عبارة عن مستند بصيغة JSON يحدد الأذونات بالتفصيل. أنت حرفيًا تكتب قانون الصلاحيات.
4. الأدوار (Roles): من أقوى المفاهيم وأكثرها أهمية. الدور هو مجموعة من الأذونات المؤقتة اللي يمكن لأي “هوية موثوقة” (مثل سيرفر EC2، أو دالة Lambda، أو حتى مستخدم من حساب آخر) أن “تتقمصها” (Assume). هذا يسمح للخدمات بالتواصل مع بعضها بأمان بدون الحاجة لتخزين مفاتيح وصول دائمة على السيرفرات.

تشريح سياسة IAM: كيف تتكلم مع السحابة بلغة الأذونات

السياسات ممكن تبين معقدة بالبداية، لكن لما تفهم تركيبتها، بتصير سهلة. خلينا ناخذ مثال لسياسة بسيطة بتسمح بقراءة الملفات من “مخزن” (bucket) معين في خدمة التخزين S3.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowReadOnlyAccessToSpecificBucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::my-company-assets",
                "arn:aws:s3:::my-company-assets/*"
            ]
        }
    ]
}

خلونا نفصصها حبة حبة:

• Version: إصدار لغة السياسة، عادةً بكون ثابت.
• Statement: السياسة بتتكون من جملة أو أكثر من “البيانات” (Statements).

* Sid: معرف للـ Statement عشان يسهل قراءته وفهمه (اختياري لكن يفضل استخدامه).

• Effect: التأثير. إما Allow (سماح) أو Deny (منع). نصيحة من أبو عمر: الـ Deny دائمًا أقوى من الـ Allow. لو في 10 سياسات بتسمح وواحدة بتمنع، المنع هو اللي بفوز.
• Action: الفعل أو الإجراء المسموح به. كل خدمة سحابية لها قائمة أفعال خاصة فيها (مثل ec2:StartInstances أو rds:CreateDBInstance).
• Resource: المورد اللي بتنطبق عليه الصلاحية. كل مورد في السحابة له معرف فريد يسمى ARN. هنا حددنا مخزن S3 معين وكل الملفات اللي جواه (/*).

بمجرد ما تتقن قراءة وكتابة هذه السياسات، بتكون امتلكت مفتاح التحكم الحقيقي في بيئتك السحابية.

من الفوضى إلى النظام: استراتيجيات عملية لتطبيق IAM صح

بعد الكارثة اللي صارت معنا، قعدنا وأعدنا بناء كل نظام الأذونات من الصفر. وهذه هي الدروس العملية اللي طلعنا فيها، خلاصة خبرة وتعب ليالي طويلة.

1. ابدأ من الصفر: مبدأ الامتياز الأقل (The Golden Rule)

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

2. استخدم الأدوار (Roles) لكل إشي تقريبًا

انسى موضوع تخزين مفاتيح الوصول (Access Keys) على السيرفرات. هذه وصفة لكارثة أمنية. أي سيرفر EC2 أو حاوية Docker أو دالة Lambda تحتاج تتكلم مع خدمة ثانية (مثل S3 أو DynamoDB)، لازم تعملها عن طريق “دور” (IAM Role).

مثال عملي: عندك سيرفر ويب على EC2 بحتاج يعرض صور من S3.

الطريقة الغلط: توليد مفاتيح وصول لمستخدم IAM وتخزينها في ملف إعدادات على السيرفر. لو السيرفر اخترق، المخترق بسرق المفاتيح وبوصل لكل إشي.

الطريقة الصح (طريقة أبو عمر):

1. أنشئ IAM Role.
2. في “سياسة الثقة” (Trust Policy) للدور، اسمح لخدمة EC2 بتقمص هذا الدور.
3. في “سياسة الأذونات” (Permissions Policy) للدور، أعطه صلاحية s3:GetObject على الـ bucket تبع الصور فقط.
4. اربط هذا الدور بسيرفر الـ EC2 عند إطلاقه.

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

3. المجموعات (Groups) لتنظيم البشر، والأدوار (Roles) لتنظيم الآلات

لا تطبق سياسات على المستخدمين مباشرة. هذا الشيء بصير كابوس مع نمو الفريق. نظم المستخدمين في مجموعات منطقية: Developers, DevOps, Finance, ReadOnlyAdmins. وطبق السياسات على المجموعات. لما يجي موظف جديد، بس حطه في المجموعة الصح وهو بياخذ كل الصلاحيات اللازمة تلقائيًا. ولما يترك الشركة، بس شيله من المجموعة.

4. أمّن الحساب الجذري (Root User) وانساه

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

5. راقب، حلل، ثم راقب كمان مرة!

الأمان مش إشي بتعمله مرة وبتنساه. لازم تضل عينك مفتوحة. استخدم خدمات مثل AWS CloudTrail اللي بتسجل كل طلب API بصير على حسابك. مين طلب؟ متى؟ من أي IP؟ وشو عمل؟ هذا السجل هو الصندوق الأسود تبعك في حال حدوث أي مشكلة.

واستخدم أدوات أحدث مثل IAM Access Analyzer اللي بتفحص حسابك باستمرار وبتحذرك لو في أي صلاحيات فضفاضة أو خطيرة ممكن تسمح بوصول خارجي غير مرغوب فيه.

الخلاصة: من جحيم الأذونات إلى جنة الأمان 🧘‍♂️

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

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

وصدقوني، بعد ليلة حذف قاعدة البيانات هذيك، صرت أنام وأنا حاضن تلفوني اللي عليه تطبيق الـ MFA. 😉

الله يوفقكم ويبعد عنكم وعن مشاريعكم كل شر.