مفتاح الوصول والمفتاح السري في AWS: كيف تنشئهما وتستخدمهما وتدوّرهما وتشاركهما بأمان

مفتاح الوصول في AWS سلسلتان نصيتان تتيحان معًا لبرنامج ما أن يعمل باسم مستخدم IAM: معرّف مفتاح الوصول (access key ID) الذي يحدد المفتاح، ومفتاح الوصول السري (secret access key) الذي يثبت ملكيته. يبحث الناس عنهما بثلاثة أسماء: access key و secret key، أو secret access key، أو AWS secret key فقط، وكلها تعني الزوج نفسه. ويظهر هذا الزوج في إعدادات CLI وفي مسارات CI، وفي رسائل على Slack أكثر مما ينبغي.

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

معرّف مفتاح الوصول ومفتاح الوصول السري

تبدأ المفاتيح طويلة الأمد بالأحرف AKIA. أما بيانات الدخول المؤقتة من STS، وهي تأتي أيضًا مع رمز جلسة، فتبدأ بالأحرف ASIA وتنتهي صلاحيتها وحدها. فإذا رأيت مفتاح ASIA في ملف إعدادات، فسيتوقف عن العمل خلال ساعات، وهذا مقصود في التصميم.

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

متى تحتاج إلى مفتاح طويل الأمد أصلًا؟

الجواب الصريح: أقل مما يظن الناس.

• أحمال العمل على AWS (EC2 و Lambda و ECS و EKS) ينبغي أن تستخدم أدوار IAM. يلتقط SDK بيانات دخول قصيرة العمر تلقائيًا، فلا يبقى شيء لتدويره أو تسريبه.
• الأشخاص ينبغي أن يسجلوا الدخول عبر IAM Identity Center أو تسجيل دخول موحد (SSO) ويحصلوا على بيانات دخول مؤقتة من aws sso login.
• أنظمة CI مثل GitHub Actions تستطيع تولّي دور عبر OIDC دون أي مفتاح مخزن.
• المفاتيح طويلة الأمد تبقى للحالات التي لا يصلح فيها أي مما سبق: أداة على حاسوب محمول لا تدعم SSO، أو خدمة خارجية لا تقبل إلا المفاتيح الثابتة، أو مهمة قديمة لم تنقلها بعد.

وإن احتجت إلى مفتاح فعلًا، فأنشئه على مستخدم IAM مخصص له بأضيق سياسة تؤدي المهمة، ولا تنشئه أبدًا على حساب مسؤول يخص شخصًا.

إنشاء مفتاح وضبط إعداده

في وحدة تحكم IAM، افتح المستخدم واختر «Security credentials» ثم «Create access key». اختر حالة الاستخدام التي تسأل عنها AWS، واقرأ البديل الذي تقترحه، ثم تابع. يظهر المفتاح السري مرة واحدة فقط. احفظه مباشرة في مخزن الأسرار أو في مدير كلمات المرور، أو نزّل ملف CSV واحذفه بعد استيراده. لا يحمل كل مستخدم IAM أكثر من مفتاحين في الوقت نفسه، وهذا ما يجعل التدوير ممكنًا.

على الجهاز، اضبط ملف تعريف مسمّى بدلًا من الملف الافتراضي:

aws configure --profile deploy-tool
# AWS Access Key ID [None]: AKIA...
# AWS Secret Access Key [None]: ...
# Default region name [None]: eu-west-1

يكتب هذا الأمر الملفين ~/.aws/credentials و ~/.aws/config. اقصر الوصول إلى الملف على مستخدمك بالأمر chmod 600. وفي الحاويات وأنظمة CI، مرّر AWS_ACCESS_KEY_ID و AWS_SECRET_ACCESS_KEY كأسرار من مخزن المنصة، لا كمتغيرات عادية في ملف YAML، ولا تمررهما أبدًا في سطر الأوامر، لأنهما يُحفظان عندها في سجل أوامر الطرفية.

التدوير دون تعطيل أي شيء

التدوير خطوات أربع متتابعة، ويتيحها حد المفتاحين.

1. أنشئ المفتاح الثاني على المستخدم نفسه.
2. حدّث كل ما يستخدم المفتاح إلى المفتاح الجديد: ملفات الإعدادات وأسرار CI وإدخال مدير الأسرار. تعرض وحدة تحكم IAM آخر وقت استُخدم فيه كل مفتاح، فتعرف منه إن كنت قد نسيت شيئًا.
3. عطّل المفتاح القديم. انتظر يومًا أو دورة نشر. إن تعطل شيء، فأعد تفعيله وأصلح ما يستخدمه وحاول مجددًا.
4. احذف المفتاح القديم حين لا يعود شيء يستخدمه.

افعل هذا وفق جدول زمني للمفاتيح التي لا بد من وجودها، ولكل المفاتيح عند أحداث بعينها: مغادرة موظف، أو تغيير مزوّد، أو فقدان حاسوب محمول، أو الاشتباه في تسرب. ويستطيع AWS Config و IAM Access Analyzer تنبيهك إلى المفاتيح التي تجاوز عمرها ما تسمح به سياستك.

عندما ينكشف مفتاح

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

1. عطّل المفتاح في IAM الآن. لا تنتظر حتى تنشئ البديل أولًا، إلا إذا كان توقف الخدمة أسوأ من انكشاف المفتاح.
2. أنشئ مفتاحًا بديلًا وحدّث ما يستخدمه.
3. اقرأ CloudTrail بحثًا عن كل إجراء نُفِّذ بمعرّف مفتاح الوصول هذا منذ انكشافه. ابحث عن مستخدمي IAM أو مفاتيح جديدة، وخوادم جديدة، وسياسات حاويات تخزين معدّلة، ومناطق غير مألوفة.
4. راجع الفاتورة و Cost Explorer بحثًا عن قفزات تشبه نمط تعدين العملات المشفرة.
5. أزل السر من الشيفرة والسجلات وسجل git. قد ترفق AWS بنفسها السياسة AWSCompromisedKeyQuarantine بالمستخدم حين ترصد تسربًا علنيًا، فاتركها مكانها حتى ينتهي التنظيف.
6. احذف المفتاح القديم، ثم اعرف كيف وصل إلى هناك وأغلق ذلك المنفذ.

كيف تشارك مفتاح AWS السري مع شخص؟

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

الطريقة الآمنة تستغرق دقيقة:

1. أنشئ مفتاحًا لهذا الشخص على مستخدم IAM مخصص، بالسياسة التي تحتاجها مهمته ولا شيء أكثر. لا تشارك مفتاحًا يستخدمه أي شيء آخر.
2. الصق مفتاح الوصول السري وحده في رابط سري لمرة واحدة. يُشفَّر في متصفحك قبل تخزينه، وتُحذف النسخة المخزنة نهائيًا عند أول فتح للرابط، وتنتهي صلاحية الرابط بعد ساعة أو يوم أو أسبوع إن لم يفتحه أحد.
3. أرسل الرابط مع سطر واحد يشرح السياق. وأرسل معرّف مفتاح الوصول والمنطقة واسم ملف التعريف في رسالة منفصلة، فلا شيء منها سري وحده.
4. أضف عبارة مرور في حساب Pro لأي مفتاح يتجاوز صلاحية القراءة فقط، وأوصلها برسالة نصية أو في مكالمة.
5. تأكد أنه فتحه. إن ذكر الرابط أنه فُتح من قبل ولم يفتحه الشخص، فعطّل المفتاح وابدأ من جديد.
6. عطّل المفتاح عند انتهاء التعاقد، ثم احذفه بعد ذلك.

يطبق دليل مفاتيح API النمط نفسه على مزوّدين آخرين، ويشرح مقال مشاركة الروابط بأمان للمطورين كيف تكتب سكربتًا لعملية التسليم عند انضمام الموظفين.

قراءات ذات صلة

• كيف تشارك مفاتيح API بأمان
• مدير الأسرار السحابي: ما هو وكيف تختار واحدًا
• كيف ترسل بيانات دخول مؤقتة لقاعدة بيانات إلى متعاقد بأمان
• كيف تعمل الروابط السرية لمرة واحدة