ملاحظات امنیتی مدیریت پیکربندی

ما اغلب بدیهی می دانیم که پیامدهای امنیتی استفاده از ابزارهای مدیریت پیکربندی مانند Puppet، Chef یا Ansible واضح است، اما این دور از واقعیت است. دروغ می گویم اگر بگویم که هرگز کد مدیریت پیکربندی خطرناکی را در استفاده از تولید به کار نبرده ام که در نگاه به گذشته باید از همان ابتدا آشکار می شد. در اینجا یک مثال عالی است. توانایی از بین بردن اعتبارسنجی کد آنلاین عروسکی بیش از یک سال زنده بود!

پس با در نظر گرفتن این موضوع، بیایید در اکوسیستم Puppet پرسه بزنیم و در مورد مواردی صحبت کنیم که ممکن است پیامدهای امنیتی داشته باشند و ممکن است نیاز به بررسی دقیق تر در مورد کنترل دسترسی داشته باشند. و بیایید لید را اینجا دفن نکنیم. مهم نیست چه چارچوبی را اجرا می کنید، مدیریت پیکربندی است طبق تعریف دسترسی در سطح ریشه / مدیر به کل زیرساخت شما و دسترسی به تنظیمات و پایگاه کد آن باید به این صورت در نظر گرفته شود. مثال‌هایی که در این راهنما به آن‌ها اشاره می‌شود، مختص Puppet هستند، اما مفاهیم سطح بالاتر اینطور نیستند. اگر از یک پلت فرم مدیریت پیکربندی رقیب استفاده می کنید، باید استفاده خود را برای الگوهای مشابه ارزیابی کنید.

در نظر گرفتن یک طرز فکر امنیتی در اینجا به این معنی است که این راهنما به “بردارهای حمله” اشاره خواهد کرد. این بدان معنا نیست که آسیب پذیری وجود دارد. این به سادگی به این معنی است که ممکن است یک مهاجم بالقوه از یک پیکربندی نادرست سوء استفاده کند. و برای روشن بودن، این یک چک لیست جامع از چیزهایی نیست که باید از آنها اجتناب کنید. در عوض، این راهنمای نحوه تفکر در مورد کدهای مستقر در زیرساخت مدیریت پیکربندی است.

در گذشته، این به نوعی بدیهی است – مدیریت پیکربندی با توزیع انواع خاصی از کدها و داده ها در زیرساخت شما و اجرای آن با امتیازات مدیریت کار می کند تا اطمینان حاصل شود که سیستم های شما در حالتی که می خواهید پیکربندی شده اند.

اما چند جا وجود دارد که این کد اجرایی واضح نیست. بررسی دقیق کمتر به این معنی است که این مناطق می توانند به عنوان بردارهای حمله استفاده شوند. به عنوان مثال، در طول تدوین کاتالوگ، توابع بر روی سرور اجرا می شوند. این به معنای هر توابع سفارشی موجود در ماژول ها است، اما همچنین به معنای کامپایل کد Ruby در قالب های ERB و کد پوسته اجرا شده توسط generate() تابع و غیره را config_version اسکریپت قبل از جمع آوری کاتالوگ اجرا می شود. مردم معمولاً از آن برای افشای نسخه‌های git یا موارد مشابه استفاده می‌کنند، اما این فقط یک اسکریپت پوسته است. می تواند هر چیزی را که شما بخواهید اجرا کند و درست در مخزن کنترل قرار دارد. و حقایق سفارشی همگام‌سازی می‌شوند و به محض نصب ماژول‌های آن‌ها، با امتیازات روت در کل زیرساخت شما اجرا می‌شوند.

توصیه های امنیتی:

• هنگام نصب ماژول های جدید باید ممیزی کنید:
  • حقایق و توابع سفارشی را بررسی کنید و ببینید چه کاری انجام می دهند.
  • الگوهای ERB را بررسی کنید و مطمئن شوید که آنها فقط حاوی کد ارائه یا طرح بندی هستند، مانند تکرار روی یک آرایه برای ساخت بند در یک فایل پیکربندی. هر منطق روبی دیگری مشکوک است. برای استفاده از مانیفست ها را بررسی کنید inline_template() عملکرد و اعتبار آنها را به همان شیوه انجام دهید.
  • برای استفاده از مانیفست ها را از بین ببرید generate() تابع. موارد استفاده معتبر بسیار کمی برای این عملکرد وجود دارد، بنابراین هر مشاهده ای از آن باید یک پرچم قرمز باشد.
• هنگام بررسی درخواست‌های کشش/ادغام به مخزن کنترل:
  • به هر گونه تغییر در آن بسیار دقت کنید config_version اسکریپت
  • اگر ماژول های جدید به Puppetfile، سپس بررسی کنید که آنها حسابرسی شده اند.

را Puppetfile یک شگفتی دیگر است به نظر می رسد یک فایل داده است و بسیاری از افرادی که کد را بررسی می کنند مانند داده رفتار می کنند. اما در واقع یک DSL سفارشی است که به عنوان Ruby پیاده سازی شده است، به این معنی که امکان پذیر است (اگرچه بسیار دلسرد شده است) شامل کد دلخواه است که در طول استقرار پایگاه کد اجرا می شود. این یک بردار حمله یواشکی است زیرا اگر کسی بتواند یک شاخه در مخزن کنترل شما ایجاد کند، ممکن است قبل از اینکه دیگران بتوانند آن را بررسی کنند، مستقر و اجرا شود.

توصیه های امنیتی:

• به کاربران نامعتبر اجازه ندهید که در مخزن کنترل شما شعبه ایجاد کنند.
• استفاده از چک های VCS را برای رد کردن تعهدات حاوی کد غیرمنتظره در خود در نظر بگیرید Puppetfile. یک نمونه پشتیبانی نشده و کمی تست شده در اینجا موجود است.
• هنگام بررسی درخواست‌های کشش/ادغام به مخزن کنترلی خود، به هر تغییری در مخزن کنترلی خود بسیار توجه کنید Puppetfile و آن را مانند کد بررسی کنید تا اینکه مانند داده های ساده با آن رفتار کنید.

و البته، هر ماژول‌هایی که به مخزن کنترل خود اضافه می‌کنید، می‌توانند هر افزونه سفارشی را اجرا کنند، یا exec عبارات، یا هر چیزی که در هر جایی که در یک گره طبقه بندی شده باشد. ماژول های مخرب از نظر تئوری می توانند تأثیر بیشتری داشته باشند، زیرا آنها به عنوان کاربر اصلی یا مدیر فراخوانی می شوند.

توصیه های امنیتی:

• هنگام نصب ماژول های جدید باید ممیزی کنید:
  • مانیفست ها را مرور کنید تا یک ایده کلی از نحوه کار ماژول و مدیریت آن به دست آورید. به هر چیزی که نامناسب به نظر می رسد توجه بیشتری داشته باشید.
  • به دنبال منابعی باشید که کد پوسته را اجرا می کنند، مانند execیا cron jobs, the validate پارامتر از file نوع، یا پارامترهای مختلف فرمان service نوع علاوه بر جستجوی کدهای مخرب، درون یابی ناامن را نیز بررسی کنید که می تواند برای حملات تزریق پوسته استفاده شود.
  • انواع سفارشی و ارائه دهندگان را بررسی کنید. خواندن اینها به این سادگی نیست، اما باید به دنبال هر چیزی باشید که نامناسب یا نامرتبط به چیزی که ادعا می کند مدیریت می کند.

اگر نگرانی‌هایی را شناسایی کردید، آن‌ها را به‌عنوان مسائلی در مخزن ماژول مطرح کنید یا از همتایان جامعه در مورد آن در فضای کاری Slack ما بپرسید.

بیشتر اینها نباید خیلی نگران کننده باشند. باز هم، خودکار کردن اجرای کد در زیرساخت شما همان کاری است که اتوماسیون زیرساخت انجام می دهد. اما مهم است که این را به خاطر بسپارید و مخزن کنترل خود و هر چیزی که ممکن است حاوی آن باشد را به عنوان کد ممتاز در نظر بگیرید. قبل از استفاده از ماژول‌های حسابرسی، یا فقط از ماژول‌های نویسندگان مورد اعتماد استفاده کنید. مراقب باشید چه کسی به مخزن کنترل یا ورودی های شما دسترسی دارد Puppetfile. و عوامل غیرمنتظره مختلف اجرای کد را فراموش نکنید. طبقه بندی ماژول ها بر روی گره ها تنها راه برای اجرای کد آنها نیست.

به یاد داشته باشید، این فهرست جامعی از همه چیزهایی نیست که باید به دنبال آن باشید. اما من امیدوارم که به شما ایده ای در مورد انواع بردارهایی که ممکن است توسط بازیگران بدخواه مورد سوء استفاده قرار گیرند و برخی عادات خوب به شما بدهد. چه تدابیر امنیتی دیگری برای محافظت از پایگاه کد خود دارید؟ آنها را در نظرات بگذارید!