المعالجة التلقائية من خلال قواعد Config

يمثل العثور على مورد غير متوافق نصف المهمة فقط؛ إذ تعمل المعالجة التلقائية على إصلاحه تلقائيًا. يمكن لـ AWS Config إرفاق إجراء معالجة بقاعدة، بحيث عند انتقال مورد إلى حالة NON_COMPLIANT يُنفَّذ الإصلاح من دون انتظار تدخل بشري. وهذا يقلل المدة التي يظل فيها الإعداد غير الآمن مكشوفًا.

تعتمد معالجة Config على مستندات التشغيل الآلي في AWS Systems Manager (SSM)، وتُسمى أيضًا runbooks. توفر AWS العديد من المستندات المحددة مسبقًا، مثل مستند لتعطيل الوصول العام إلى حاوية S3 أو لتشفير وحدة تخزين. يحدد المستند الخطوات الدقيقة اللازمة لإعادة المورد إلى حالة التوافق.

تربطون إجراء معالجة بقاعدة Config وتربطون مخرجات القاعدة، مثل معرّف المورد، بمعلمات الإدخال الخاصة بـ runbook. عندما تُبلغ القاعدة عن عدم التوافق، تستدعي Config مستند SSM على المورد المحدد، وبذلك تكتمل الحلقة من الاكتشاف إلى التصحيح.

يمكن أن تكون المعالجة تلقائية، فتبدأ فور اكتشاف عدم التوافق، أو يدوية، بحيث يراجع المشغّل الحالة ثم يبدأ الإصلاح. تناسب التلقائية التصحيحات الواضحة والآمنة، بينما تناسب اليدوية التغييرات التي قد تعطل أعباء العمل وتحتاج إلى تقدير بشري قبل تنفيذها.

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

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

من الأنماط الشائعة ربط قاعدة s3-bucket-public-read-prohibited بـ runbook للمعالجة يطبّق ميزة Block Public Access على أي حاوية يتم وضع علامة عامة عليها. في اللحظة التي يكشف فيها شخص ما حاوية، تكتشف Config ذلك ويعيد runbook تأمينها، غالبًا خلال دقائق ومن دون تدخل أي مشغّل.

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

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

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

تكمل المعالجة التلقائية قصة Config: تسجيل الحالة، وتقييمها باستخدام القواعد، ثم إصلاحها تلقائيًا باستخدام runbooks في SSM ضمن دور ذي أقل قدر من الامتيازات. وعند استخدامها بعناية إلى جانب الضوابط الوقائية، تحافظ على امتثال بيئتكم باستمرار وتقلل بدرجة كبيرة المدة التي يمكن أن يستمر فيها أي إعداد غير آمن.

اختبروا معرفتكم بالمعالجة التلقائية.

تُرفق المعالجة التلقائية مستند تشغيل آلي في SSM بقاعدة Config، بحيث تُصلح الموارد غير المتوافقة تلقائيًا أو بعد مراجعة يدوية. يعمل runbook ضمن دور IAM ذي أقل قدر من الامتيازات، مع إمكانية ضبط إعادة المحاولات. اقرنوها بـ ضوابط وقائية، واختبروا runbooks أولًا، وانشروها على مستوى المؤسسة باستخدام حزم التوافق للحصول على بيئة ذاتية الإصلاح ومتوافقة باستمرار.