غالبًا ما تنخرط فرق الأمن في نوع من مشروعات الترحيل واسعة النطاق حيث لا يوجد نظام واضح لمكافحة التطرف العنيف؛ إليك بعض النصائح، نظرًا لأن هذه المشاريع قد يكون من الصعب تحديد أولوياتها والوصول إلى خط النهاية. فهي تميل إلى تضمين تغيير الطريقة التي يتم بها دائمًا القيام بشيء ما بحيث أنه على الرغم من إمكانية تقليل بعض المخاطر الكبيرة، إلا أنه يجب أن يحدث خطأ ما قبل إساءة استخدام المخاطر التي يتم تخفيفها. تتضمن أمثلة ذلك ترحيل بيئات AWS من IMDSv1 إلى IMDSv2 أو التخلص من مفاتيح وصول مستخدم IAM. هناك العديد من المشاريع المشابهة، لكني سأستخدم هذين المشروعين كأمثلة لأنني شاركت فيهما بشكل مباشر. (إذا كنت تريد الاطلاع على تفاصيل تنفيذ هذه الإستراتيجية، فقد وصف Slack مؤخرًا تفاصيلها رحلة من الهجرة إلى IMDSv2.)
الخطوة الأولى هي فهم مدى سوء هذه المشكلة، والحصول على طريقة يمكنك من خلالها إنشاء هذه المقاييس بانتظام لرؤية التقدم الذي تحرزه مع مرور الوقت. من المفيد أيضًا جمع بيانات إضافية مثل حسابات AWS التي توجد بها هذه النتائج، وعدد حسابات AWS لديك، حيث قد تجد أن أفضل مقياس لاحتياجاتك هو النسبة المئوية لحسابات AWS التي تعاني من هذه المشكلة أو بعض الحسابات الأخرى من هذه البيانات، بدلاً من مجرد عدد أولي من النتائج.
افهم حالات الاستخدام الخاصة بهذه المشكلة حتى تتمكن من وضع خطط لمهاجمتها. على سبيل المثال، مع مفاتيح وصول مستخدم IAM، قد يكون هناك بعض مستخدمي IAM الذين يتم استخدامهم من قبل البشر، وبعضهم يتم استخدامه بواسطة حلول الموردين، والبعض الآخر يتم استخدامه لحالات استخدام محددة أخرى. قد يتم حل كل حالة من حالات الاستخدام هذه بشكل مختلف. قد تتمكن من التعرف على بعض حالات الاستخدام هذه من السجلات أو واجهات برمجة التطبيقات الأخرى، ولكن يجب عليك أيضًا التحدث إلى الأشخاص. إذا كان لديك 10000 نتيجة، فسوف تحتاج إلى أخذ عينة عشوائية من هذه المجموعة لفهمها.
قد يكون لديك أيضًا فرق معينة تربطك بها علاقة أفضل ويمكنك تقسيم هذا العمل بناءً على هذا المعيار أيضًا. عادةً ما أعطي الأولوية للتركيز أولاً على الأماكن التي يمكنني فيها تحقيق التقدم بسهولة أكبر لأن هذا يساعد في بناء الزخم.
لقد كتبت سابقًا عن التخلص من مفاتيح وصول مستخدم IAM حيث ناقشت بعض الطرق لتحديد أولويات النتائج بناءً على المخاطر التي تمثلها. يتضمن ذلك العثور على المفاتيح غير المستخدمة، وتلك التي يمكنها الوصول إلى الموارد الحساسة. يمكنك قراءة الجزء الأول من هذا الدليل هنا.
قبل أن تبدأ في مطالبة الأشخاص بتغيير شيء ما، يجب عليك توثيق ما يجب عليهم تغييره وكيف. أنت لا تريد فقط أن تجعل الأمر أسهل بالنسبة لهم، بل تريد أيضًا التأكد من أن الأمور ستنتهي كما تأمل.
ومن الناحية المثالية، سيتضمن ذلك استخدام وحدات نمطية جديدة للبنية التحتية كرمز (IaC) التي تستخدم الحل المفضل. إذا تم إنشاء هذه الوحدة مع فوائد كافية مقارنة بالطريقة القديمة، فقد تكون محظوظًا لأن الأشخاص سينتقلون بشكل طبيعي إلى هذه الوحدة بمجرد وجودها. ستحتاج إلى البحث عن وثائق داخلية حول كيفية القيام بشيء ما، حيث قد تجد إرشادات قديمة تدافع عن الطريقة القديمة لفعل الأشياء.
انتبه إلى أن الحل الشائع بشكل مدهش “لإصلاح” شيء ما هو ببساطة حذفه. لقد رأيت تنبيهًا بشأن تكوين خاطئ لمورد واحد أدى إلى قرار المهندس بحذف حساب AWS بالكامل لأنه لم تعد هناك حاجة إليه.
قد تجد أن مصدر النتائج في بيئتك الخاصة بالمشكلة التي تعالجها يرجع إلى الموردين الذين لا يمكنك تغييرهم بشكل مباشر. قد يدعم بعض هذه العناصر بالفعل طريقة محسنة للقيام بالأشياء التي لم تدرك شركتك أنها يمكن أن تبدأ في استخدامها، ولكن قد تحتاج أيضًا إلى التواصل معهم لتطلب منهم تنفيذ هذا التحسين. أوصي بمعاملة هذا مثل أي طلب ميزة آخر يتم تقديمه إلى البائع، حيث يمكنك تقديم الطلب إليه بشكل خاص وتطلب تحديثات الحالة بشكل منتظم. يمكنك أيضًا الحصول على جذب أفضل من خلال التواصل مع جهة اتصال أمنية لدى البائع، حيث قد يكون الأفراد الذين يتلقون هذه الرسالة أكثر تحفيزًا ومسؤولين بشكل مباشر عن إجراء التغيير في النهاية.
قد تكون هناك تغييرات يمكنك طلبها بالإضافة إلى ذلك من موفري الخدمات السحابية أو صانعي حلول البنية التحتية كرمز (IaC). قد تكون هناك ميزات تحتاج إلى الدعم وقد تكون هناك أيضًا حالات يمكن فيها تعيين الإعدادات الافتراضية. في AWS، أصبح IMDSv2 بمرور الوقت هو الإعداد الافتراضي لجميع EC2s التي تم إنشاؤها من خلال وحدة تحكم الويب، ولجميع EC2s التي تم إنشاؤها من AMIs معينة، وأصبح أخيرًا إعدادًا إقليميًا لتمكين هذه الميزة افتراضيًا لجميع EC2s. وبالمثل، أضافت وحدة تحكم الويب AWS مزيدًا من الاحتكاك لعملية إنشاء مفاتيح وصول مستخدم IAM بمرور الوقت.
قد تكون هناك أيضًا برامج تعليمية شائعة عبر الإنترنت أو مصادر مرجعية أخرى قد يراها المهندسون في شركتك والتي تستخدم طريقة قديمة للقيام بالأشياء. في المقال قصة نجاح لمجتمع الأمان في التخفيف من التكوين الخاطئ، يمكنك معرفة أين لعب طلب تغيير برنامج تعليمي شائع عبر الإنترنت دورًا في القضاء على التكوين الخاطئ. قد يختلف عددك مع الوصول إلى مؤلفي مقالات المدونة التي قد يكون عمرها سنوات، ولكن الإستراتيجية ذات الصلة تتمثل في كتابة مقالة مدونتك الخاصة التي توضح الطريقة المفضلة لفعل شيء ما، وربما يحصل هذا على تصنيف أعلى بواسطة محركات البحث.
تريد في النهاية البدء في اكتشاف المهندسين وتنبيههم في كل مرة يتبعون فيها الطريقة القديمة للقيام بالأشياء. وهذا ضروري أيضًا لإصلاح المشكلات الحالية. أكبر مشكلتين ستواجههما هنا هما إيصال التنبيه إلى الشخص الصحيح وإيصال التنبيه إليه في أسرع وقت ممكن. ستحتاج إلى إجراء هذا الكشف في مكانين: من فحص البيئة السحابية (أو أحداث السجل) بمجرد إجراء التكوين الخاطئ ومن فحص IaC قبل نشر التكوين الخاطئ. يمكن إجراء فحص IaC أثناء إجراء طلب السحب وسيتلقى تحذيرًا أو تنبيهًا آخر مباشرةً إلى المطور أثناء عمله على التغيير. ومع ذلك، في العديد من البيئات، قد يتم إجراء بعض التغييرات عن طريق النقر في وحدة تحكم الويب أو يتم تنفيذها خارج المسارات المفضلة (والمراقبة)، لذلك يجب إجراء فحص البيئة السحابية أو أحداث سجل السحابة.
عندما تعمل على القضاء على مشكلة ما في بيئتك، يجب أن تفكر في تطبيق آليات الوقاية، أو ما يشار إليها أحيانًا باسم السقاطة لأنها تضمن انتقال الأشياء في اتجاه واحد فقط. على غرار حزام السقاطة الذي يمكن تشديده بقوة أكبر دون ارتخائه، يمكن لآليات الوقاية بالمثل أن تضمن القضاء على المشكلة في النهاية عن طريق منع حدوث التكوين الخاطئ مرة أخرى. في AWS، يأخذ هذا شكل SCPs. على سبيل المثال، باستخدام SCP، يمكنك منع إنشاء مفاتيح وصول مستخدم IAM جديدة (أو مستخدمي IAM تمامًا). ستستمر مفاتيح وصول مستخدم IAM الموجودة في العمل، ولكن لن يتم إنشاء مفاتيح جديدة بمجرد تطبيق SCP لهذه المشكلة. في النهاية، عندما يتم تحويل مفاتيح وصول مستخدم IAM الحالية إلى أدوار IAM، فسوف تتخلص منها جميعًا.
البديل لـ SCPs هو المعالجة التلقائية، حيث بالإضافة إلى اكتشاف المهندسين وتنبيههم، يتم أيضًا تنفيذ إجراء لإصلاح المورد أو حذفه تلقائيًا للمهندس.
أنت بحاجة إلى توخي الحذر عند اتخاذ إجراء وقائي مثل هذا بحيث لا تمنع أعباء العمل الحالية قبل أن تتاح للأشخاص فرصة لإصلاحها، وأن الأشخاص ما زالوا قادرين على التعامل مع حالات الطوارئ (مثل تدوير مفتاح وصول مستخدم IAM أثناء وقوع حادث، عندما قد لا يكونون جاهزين بعد للتحويل إليه إلى دور IAM)، وأنك لا تقضي الكثير من الوقت في التعامل مع الاستثناءات. لذلك يجب تطبيق هذا فقط عندما تتأكد من أن عدد التكوينات الخاطئة سوف يسير في اتجاه واحد فقط. يجب أن تفكر في تطبيق إجراءات الوقاية على بيئات محددة حيث تم القضاء على المشكلة بالفعل بدلاً من الانتظار حتى يمكن القيام بذلك على مستوى الشركة.
قد تكون هناك حالات تفشل في إحراز تقدم وستحتاج إلى التعمق فيها وتقديم مساعدة إضافية. قد يكشف هذا عن حالات استخدام غير متوقعة تحتاج إلى تطوير حلول جديدة لها، أو أخطاء أو أخطاء في كيفية إرسال التنبيهات إلى المهندسين، أو مشكلات أخرى حيث ستدرك بعد فوات الأوان أن مشاركتك كانت ضرورية حقًا.
من المرجح أن تكون هناك حاجة إلى كل هذه التقنيات لدفع مشروع أمني كبير مثل هذا إلى خط النهاية. بالحديث شخصيًا، إنه شعور رائع كمهندس أمني أن تقضي تمامًا على خطر معين من بيئتك… أي حتى تقوم شركتك بعملية استحواذ، وعليك أن تبدأ من جديد.
