كيفية التخلص من مفاتيح الوصول إلى AWS- الجزء الأول: الانتصارات السهلة

لسوء الحظ، تعد مفاتيح الوصول المرتبطة بمستخدمي IAM في AWS شائعة جدًا. تشير بيانات Wiz إلى أن كل عميل سحابي تقريبًا لديه واحد على الأقل. تمثل هذه المفاتيح مشكلة لأنها لا تنتهي صلاحيتها مطلقًا، لذا ينتهي بها الأمر في أماكن لا توجد بها بيانات الاعتماد غير الثابتة، مثل التعليمات البرمجية المصدر، أو حيث لا يزال من الممكن العثور عليها واستخدامها من قبل مهاجم بعد سنوات، مثل سجلات التطبيق القديمة أو ملفات النسخ الاحتياطي. لقد كانت مفاتيح الوصول إلى AWS مصدرًا لعدد من حوادث أمنية كان من الممكن منع ذلك إذا كانت بيانات الاعتماد قد انتهت صلاحيتها بحلول الوقت الذي عثر عليها المهاجم. البديل هو استخدام أدوار IAM التي لها بيانات اعتماد جلسة تنتهي صلاحيتها بعد 36 ساعة على الأكثر، وغالبًا ما تكون افتراضية إلى 12 ساعة أو أقل.

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

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

أسهل مفاتيح AWS للتخلص منها هي تلك التي لا يتم استخدامها. يمكن العثور على هذه عبر تقرير أوراق الاعتماد من خلال البحث عن المفاتيح غير النشطة أو تاريخ آخر استخدام “غير متاح” لأي مفاتيح نشطة.

بعد ذلك، يجب عليك البحث عن مفاتيح الوصول التي لم يتم استخدامها خلال آخر 90 يومًا، أو أي إطار زمني آخر يبدو مناسبًا لك. على الرغم من أن معيار CIS يستخدم 90 يومًا، إلا أنه يجب عليك اختيار إطار زمني أقصر بكثير.

🔎 تُظهر بيانات Wiz أن 31% من متوسط ​​مفاتيح الوصول لعميل السحابة (المتوسط ​​والوسيط) لم تكن نشطة خلال الـ 90 يومًا الماضية.

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

هناك أسباب قليلة جدا لاستخدام حساب المستخدم الجذر في AWS، ونوصي بأفضل الممارسات تعطيل هذا المستخدم بالكامل باستخدام سياسة التحكم في الخدمة (SCP). إذا كان لديك أي مفاتيح وصول إلى الجذر، فيجب عليك تحديد الغرض منها وإيجاد بديل. يمكن اكتشاف مفاتيح الوصول إلى الجذر باستخدام أمر CLI aws iam الحصول على ملخص الحساب.

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

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

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

يجب أن تستخدم موارد الحوسبة في AWS، مثل EC2s وLambdas والحاويات، أدوار IAM لأنها تضمن أن بيانات الاعتماد مؤقتة. ستتحقق AWS SDK من عدد من الأماكن بحثًا عن بيانات الاعتماد مثل متغيرات البيئة، والملفات الموجودة على القرص، وفي النهاية خدمة بيانات تعريف المثيل لـ EC2s، للحصول على دور IAM (المعروف أيضًا باسم ملف تعريف المثيل في هذا السياق). علاوة على ذلك، سيقوم SDK تلقائيًا بتحديث أي بيانات اعتماد منتهية الصلاحية. أسهل طريقة لتحديد مفاتيح وصول AWS على القرص هي باستخدام حل مثل Wiz الذي يمكنه البحث عنها على القرص، ولكن بدلاً من ذلك يمكنك فحص سجلات CloudTrail لعناوين IP المرتبطة بمفاتيح وصول مستخدم IAM في بيئات AWS الخاصة بك.

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

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

{ 
    "Version": "2012-10-17", 
    "Statement": { 
        "Effect": "Deny", 
        "Action": ["iam:CreateAccessKey", "iam:CreateUser"], 
        "Resource": "*" 
    } 
} 

يجب نشر SCPs مثل هذه جنبًا إلى جنب مع قواعد تدقيق البنية التحتية باعتبارها تعليمات برمجية لأن تجربة المطور تكون أفضل عندما يتم حظر الأشياء في وقت مبكر من عملية التطوير قدر الإمكان.

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

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

اقرأ المقالة الثانية في هذه السلسلة في الجزء الثاني: تقليل الامتيازات.