اقرأ المنشورات السابقة في هذه السلسلة في الجزء الأول: المكاسب السهلة والجزء الثاني: تقليل الامتيازات.
عندما يحتاج أحد موارد الحوسبة في موفر سحابي آخر (مثل GCP أو Azure) إلى التفاعل مع موارد AWS الخاصة بك، فقد يتم استخدام OpenID Connect (OIDC). باستخدام هذا الحل، يمكنك تكوين دور IAM في بيئتك لتثق بموفر السحابة الآخر، الذي يعرف موارد الحوسبة في بيئته الخاصة ويمكنه بعد ذلك منحها الوصول اللازم. تدعم العديد من الحلول الأخرى أيضًا حالات استخدام OIDC مثل هذه، مثل Github Actions. يمكن العثور على تعليمات حول إعداد هذا التكامل في أوس و جيثب الوثائق. تبدو سياسة الثقة في دور IAM الناتجة كما يلي:
عند إعداد عمليات التكامل هذه، من المهم التأكد من عدم تمكن المستخدمين الآخرين لخدمات الطرف الثالث من تولي دورك أيضًا. على سبيل المثال، إذا تركت عن طريق الخطأ “sub“الشرط الذي يحدد”GitHubOrg/GitHubRepo“، ثم أي شخص باستخدام حساب Github، يمكنك إنشاء سير عمل Github Action الذي يتولى دورك! قد تسمح التعديلات المختلفة لهذا الشرط لأي فرع في المستودع أو أي مستودع في مؤسستك بتولي هذا الدور، مما قد يمثل خطرًا أمنيًا.
أخيرًا، يمكننا مناقشة المواقف التي لا يمكن فيها الحصول على الثقة عبر سحابة AWS أو سحابة أخرى. في حالة رغبتك في منح خادم في مركز بيانات أو كمبيوتر محمول أو أي جهاز فعلي آخر إمكانية الوصول إلى بيئة AWS الخاصة بك، فإن الحلين الأساسيين اللذين توفرهما AWS هما أدوار IAM في أي مكان و التنشيط الهجين لمدير الأنظمة.
أدوار IAM في أي مكان
في العديد من النواحي، تقوم IAMRoles Anywhere ببساطة باستبدال مفتاح الوصول والمفتاح السري بشهادة. تعتمد AWS على العملاء للتأكد من أنهم يديرون البنية التحتية للمفتاح العام (PKI) التي يمكنها التعامل مع الشهادات بشكل أفضل من مفاتيح الوصول.
هذه الخدمة هي في الغالب إعادة تصور iot:AssumeRoleWithCertificate. نظرًا لأنه يعتمد على الشهادات، فمن الممكن نظريًا تخزين الشهادات داخل شيء مثل TPM لإجراء عمليات التوقيع دون التمكن من استخراجها. قام باحث يدعى Aidan Steele بإنشاء أداة مفتوحة المصدر تسمى com.cloudkey الذي ينجز هذا مع yubikey وما سبق ذكره iot:AssumeRoleWithCertificate اتصل دون الحاجة إلى الضغط على زر yubikey. يمكن اعتماد هذا المفهوم لـ IAM roles Anywhere والأجهزة الآمنة الأخرى، مثل TPM. حتى أن هناك فتح العلاقات العامة لدعم PKCS11 لإنجاز هذا الأمر الذي يجب على AWS مراجعته. لقد مر عام تقريبًا منذ إطلاق هذه الخدمة والأدوات، وهذا النقص في الدعم وقد لوحظ.
التنشيط الهجين لمدير الأنظمة
على الرغم من أن التنشيط المختلط لـ Systems Manager لم يحظ بقدر كبير من الضجة مثل IAM Roules Anywhere، إلا أنها تقنية تستحق الاهتمام ويتم استخدامها خلف الكواليس من أجل ECS في أي مكان وهو جزء من إنترنت الأشياء جرين جراس. المكونات الرئيسية لهذه الآلية هي رمز التفعيل واستخدام بصمة الجهاز. يتم توفير رمز التنشيط للنظام البعيد وتنتهي صلاحيته افتراضيًا بعد يوم واحد ولا يمكن استخدامه إلا مرة واحدة فقط. وهذا يخفف من المخاطر التي تواجهها الحلول الأخرى حيث يمكن للمهاجم استخدام الشيء المنقول إلى العميل (والذي قد يظهر عن طريق الخطأ في السجلات أو مصادر البيانات الأخرى التي قد يصادفها المهاجم لاحقًا) مباشرةً للمصادقة.
يقوم النظام البعيد بإنشاء زوج المفاتيح الخاص به وبصمة الإصبع الخاصة به بناءً على معلومات حول BIOS والمعالج والذاكرة ومعلومات القرص وعنوان IP والمزيد. تتم تجزئة بصمة الإصبع هذه وتمريرها إلى AWS، جنبًا إلى جنب مع رمز التنشيط والمفتاح العام، لتسجيل نفسها عبر واجهة برمجة التطبيقات غير الموثقة ssm:RegisterManagedInstance. ومن أجل الحصول على بيانات الاعتماد، يتم بعد ذلك استخدام بصمة الإصبع مع واجهة برمجة التطبيقات غير الموثقة ssm:RequestManagedInstanceRoleToken. من الأفضل توثيق واجهات برمجة التطبيقات هذه بواسطة Aidan Steele في مستودع مختلف له، com.awsaccountcreds، لحالة استخدام مختلفة تمامًا لـ SSM (التكوين الافتراضي لإدارة المضيف).
قد يبدو هذا بمثابة تحسن كبير لأن النظام البعيد يقوم بإنشاء بصمة لنفسه. ومع ذلك، يتم تخزين بيانات بصمة الإصبع هذه مؤقتًا على القرص، وعند دمجها مع المفتاح الخاص، تعمل مثل زوج مفاتيح وصول مستخدم IAM. ولجعل الأمور أكثر إحباطًا، هناك الكثير من المنطق المتضمن في تحديد المدى الذي يمكن أن تتغير به بصمة الإصبع قبل اعتبار النظام البعيد مختلفًا، ولكن هذا المنطق يتم تنفيذه بالكامل من جانب العميل، حيث لا يبدو أن حالة الاستخدام لهذا الفحص تهدف إلى التخفيف من سرقة المهاجم.
مصدر قلق آخر بشأن هذه الميزة هو أنه بمجرد الحصول على بيانات اعتماد الجلسة لـ AWS، يتم تخزينها في ملف على القرص في /root/.aws/credentials. ومع ذلك، هذه هي بيانات اعتماد الجلسة التي تنتهي صلاحيتها.
هناك أمر جدير بالإشارة إليه، والذي قد يمثل فائدة أساسية أو اهتمامًا أمنيًا بالنسبة لك، وهو أن Systems Manager يمكّنك أيضًا من إدارة النظام البعيد إذا تم إعطاؤه المجموعة الصحيحة من الامتيازات. وهذا يعني أنه يمكنك نشر التطبيقات والحصول على جلسة طرفية على النظام البعيد.
ما الذي يجب عليك استخدامه؟
ما لم يكن لديك بنية عامة للمفاتيح العمومية (PKI) تتضمن نقلًا آمنًا للشهادات وطرق إنشاء الثقة مع الأنظمة البعيدة، فإن التنشيط المختلط لـ Systems Manager يوفر فوائد مقنعة، خاصة لعمليات التكامل لمرة واحدة مع عدد قليل من الأنظمة. تعد فترة الصلاحية المحدودة والاستخدام لمرة واحدة لرمز التنشيط المختلط بمثابة تخفيف كبير للمخاطر. علاوة على ذلك، فإن بصمة النظام، على الرغم من فحصها بشكل أساسي من جانب العميل، إلا أنها تخفف من السهولة التي قد يقوم بها المهندسون بنسخ بيانات الاعتماد بحرية من نظام إلى آخر.
بالنسبة لعمليات النشر الأكبر، توفر IAMRoles Anywhere المرونة لشروط سياسة IAM بشأن تفاصيل الشهادات، مما يسمح بمزيد من المصادقة الدقيقة لكل جهاز عندما لا ترغب في نشر أدوار فردية لحالات استخدام مختلفة.
سيتم تحسين كلا الخيارين بشكل كبير من خلال تطبيق AWS لـ PKCS11 حتى تتمكن من الاستفادة من TPMs للاستفادة من مفاتيح هوية التصديق لتنفيذ عمليات التوقيع. بمجرد الانتهاء من ذلك، يمكن بعد ذلك تحسين التنشيط المختلط من خلال عدم تخزين بيانات اعتماد الجلسة على القرص. يمكن الوصول إليها بدلاً من ذلك من خلال حل بيع عملية الاعتماد، حيث أنه من الشائع أكثر وجود ثغرات أمنية تسمح بقراءة الملفات بشكل عشوائي مقابل تلك التي تسمح بقراءة الملفات العشوائية (يرجع ذلك جزئيًا إلى خطورة القراءات التعسفية التي تعتبر بشكل عام أقل، وبالتالي تقوم الفرق بإلغاء تحديد أولويات إصلاحها وتصحيحها). وبالمثل، ستستفيد بصمة النظام من عدم تخزينها مؤقتًا على القرص.
يوجد الآن عدد من الخيارات لمساعدة العملاء على تجنب الاضطرار إلى الاعتماد على مفاتيح وصول مستخدم IAM طويلة الأمد. لقد كانت مفاتيح الوصول طويلة العمر هذه سببًا منتظمًا للحوادث الأمنية، والتي كان من الممكن تجنبها إذا تم استخدام بيانات الاعتماد قصيرة العمر بدلاً من ذلك، وإذا كانت بيانات الاعتماد هذه مرتبطة بقوة أكبر بالأنظمة التي تستخدمها. ناقشت هذه السلسلة عددًا من الأساليب للتخلص من مفاتيح وصول مستخدم IAM، والتخفيف من المخاطر من خلالها الامتيازات الأقل والوسائل الأخرى وآليات المصادقة البديلة لاستخدامها بدلاً من ذلك. نأمل أن نرى عددًا أقل منها في المستقبل، ونتيجة لذلك، عدد أقل من الحوادث الأمنية السحابية!
انظر بنفسك…
تعرف على ما يجعل Wiz النظام الأساسي لتمكين عملية الأمان السحابية لديك
اقرأ المقال الأول (الانتصارات السهلة) والمقال الثاني (تقليص الامتيازات) من هذه السلسلة!
