IAM: مين يقدر يسوي وش في حسابك

في الجزء الأول عرفنا إن AWS تحمي السحابة نفسها، وإنك أنت المسؤول عن اللي داخلها، وأولها: مين يقدر يوصل لحسابك، ووش يقدر يسوي فيه. هذا بالضبط شغل IAM (اختصار Identity and Access Management).

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

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

سؤالين لكل طلب #

أي طلب يوصل AWS، سواء ضغطة زر في لوحة التحكم أو أمر في الطرفية، لازم يجاوب على سؤالين:

1. مين أنت؟ هذا التحقق من الهوية (Authentication).
2. هل مسموح لك تسوي هذا الشي؟ هذا التحقق من الصلاحية (Authorization).

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

حساب الجذر (Root) #

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

بعض المهام ما يقدر عليها غيره، مثل إغلاق الحساب أو تغيير إيميله. وهذا هو تقريباً الاستخدام الوحيد له.

مكوّنات IAM الأربعة #

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

كيف تقرأ سياسة IAM #

السياسة ملف JSON. هذي سياسة تسمح بقراءة الملفات من حاوية S3 وحدة فقط:

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

• Version: إصدار لغة السياسات. اكتبها دائماً 2012-10-17، وهذا مو تاريخ سياستك.
• Statement: قائمة القواعد، وكل قاعدة تجاوب على: مسموح أو ممنوع، وش الفعل، وعلى أي مورد.
• Sid: اسم اختياري للقاعدة يوضّح الغرض منها.
• Effect: يا Allow يا Deny.
• Action: الأفعال، بصيغة الخدمة:الفعل. وتقدر تستخدم * مثل s3:Get*، بس بحذر.
• Resource: الموارد المقصودة، وتُكتب بصيغة ARN وهو المعرّف الفريد لأي مورد في AWS.
• Condition: شرط اختياري، مثل السماح فقط إذا كان المستخدم داخل بـ MFA.

لاحظ إن فيه موردين: الأول للحاوية نفسها (عشان ListBucket)، والثاني لكل الملفات داخلها (عشان GetObject). كثير من أخطاء "Access Denied" سببها نسيان واحد منهم.

أنواع السياسات #

• سياسات AWS الجاهزة (AWS managed): مثل ReadOnlyAccess وAdministratorAccess. سهلة للبداية، بس غالباً أوسع مما تحتاج.
• سياساتك أنت (Customer managed): تكتبها بنفسك وتعيد استخدامها، وهي الأفضل لتطبيق أقل صلاحية.
• السياسات المضمّنة (Inline): مربوطة بهوية وحدة وتنحذف معها. استخدمها في حالات خاصة فقط.

كيف تتقرر الصلاحية؟ #

AWS تجمع كل السياسات اللي تنطبق على الطلب، وتمشي بهذا الترتيب:

1. فيه منع صريح (Deny) في أي سياسة؟ الطلب مرفوض، حتى لو فيه سماح في مكان ثاني.
2. فيه سماح صريح (Allow)؟ الطلب مقبول.
3. ما فيه لا هذا ولا هذا؟ مرفوض، لأن كل شي ممنوع افتراضياً.

المنع دايم يفوز. وهذي نقطة تفيدك كثير لما تحاول تفهم ليش طلب مرفوض.

مبدأ أقل صلاحية #

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

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

عملي: أنشئ مستخدمك اليومي #

الحين نطبّق. بنحمي الجذر، وننشئ مستخدم إداري تستخدمه بدل الجذر.

1. فعّل MFA على الجذر. سجّل دخولك بالجذر، افتح قائمة حسابك أعلى لوحة التحكم، ثم Security credentials، ثم Assign MFA device. تطبيق مصادقة على جوالك يكفي، ومفاتيح الأمان (Passkeys) أقوى.
2. أنشئ مجموعة. افتح خدمة IAM، ثم User groups ثم Create group. سمّها Admins، واربط بها السياسة AdministratorAccess.
3. أنشئ مستخدم. من Users اضغط Create user، وفعّل Provide user access to the AWS Management Console، واختر كلمة مرور قوية، ثم أضفه لمجموعة Admins.
4. سجّل خروج من الجذر. وادخل بالمستخدم الجديد من رابط الدخول الخاص بحسابك، وتلقاه في صفحة IAM الرئيسية، وشكله https://رقم-حسابك.signin.aws.amazon.com/console.
5. فعّل MFA على المستخدم الجديد. نفس الخطوة الأولى، بس من حسابه.

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

# إنشاء المجموعة وربطها بالسياسة الجاهزة
aws iam create-group --group-name Admins
aws iam attach-group-policy --group-name Admins \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# إنشاء المستخدم وإضافته للمجموعة
aws iam create-user --user-name noura
aws iam add-user-to-group --group-name Admins --user-name noura

# التأكد من النتيجة
aws iam list-groups-for-user --user-name noura

وعشان تقوّي كلمات المرور في حسابك، حدد سياسة كلمات المرور من IAM ثم Account settings: الطول الأدنى، وأنواع الأحرف، ومدة الصلاحية، ومنع إعادة استخدام القديمة.

مفاتيح الوصول: للأوامر والكود #

لوحة التحكم تدخلها بكلمة مرور. أما سطر الأوامر والكود فيستخدمون مفاتيح وصول (Access Keys)، وهي جزئين: معرّف المفتاح (مثل اسم المستخدم)، والمفتاح السري (مثل كلمة المرور).

تنشئها من صفحة المستخدم في IAM، تبويب Security credentials. والمفتاح السري يظهر لك مرة وحدة بس. بعدها تربطها بسطر الأوامر:

$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: eu-central-1
Default output format [None]: json

(هذي قيم توضيحية من توثيق AWS، مو مفاتيح حقيقية.) وتتأكد إنها شغالة بالأمر اللي جربناه في الجزء الأول:

aws sts get-caller-identity

الأدوار: صلاحيات بدون مفاتيح #

تخيل تطبيق على سيرفر EC2 يحتاج يقرأ من S3. الحل الغلط: تحط مفاتيح وصول داخل السيرفر. لو انكشف السيرفر، انكشفت معه المفاتيح.

الحل الصحيح هو الدور (Role): تعطي السيرفر دوراً، وAWS تزوّده تلقائياً بمفاتيح مؤقتة تتجدد لحالها، بدون ما تخزّن أنت شي.

للدور جزئين: سياسة صلاحيات تحدد وش يقدر يسوي، وسياسة ثقة تحدد مين يقدر يستلم الدور. هذي سياسة ثقة تسمح لسيرفرات EC2 باستلامه:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

لاحظ الحقل الجديد Principal: هو اللي يحدد مين المقصود. ما يظهر في السياسات المربوطة بمستخدم أو مجموعة، لأن الهوية هناك معروفة. وبنستخدم الأدوار فعلياً في الجزء الجاي مع EC2. والقاعدة بسيطة: لأي خدمة أو تطبيق داخل AWS، استخدم دور، مو مفاتيح.

راجع صلاحياتك #

الصلاحيات تتراكم مع الوقت، فراجعها كل فترة. IAM يعطيك أدوات لهذا:

• تقرير بيانات الاعتماد (Credential report): ملف على مستوى الحساب، فيه كل المستخدمين وحالة كلمات مرورهم ومفاتيحهم وMFA عندهم. يكشف لك مثلاً مستخدم بدون MFA أو مفتاح قديم.
• آخر وصول (Last accessed): تبويب في صفحة المستخدم أو الدور، يوريك الخدمات اللي عنده صلاحية عليها ومتى استخدمها آخر مرة. الخدمة اللي ما استخدمها من شهور، شيل صلاحيتها.
• IAM Access Analyzer: ينبّهك على الموارد المتاحة لجهات خارج حسابك، وعلى الصلاحيات غير المستخدمة.

الخلاصة #

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

اختبر نفسك #

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

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:ListBucket"],
  "Resource": "arn:aws:s3:::reports/*"
}

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