Checkov و خطای امنیتی پیش از استقرار
Checkov ابزار تحلیل تنظیمات زیرساخت به صورت کد است. وقتی منابع ابری، شبکه یا بارکاری با فایل تعریف می‌شوند، خطای امنیتی می‌تواند پیش از ایجاد منبع در همان فایل دیده شود. برای مثال یک تنظیم دسترسی گسترده یا نبود یک کنترل مورد انتظار ممکن است در بازبینی کد نادیده بماند، اما قاعده خودکار آن را مشخص کند. ارزش این رویکرد در انتقال بخشی از بازخورد به زمان توسعه است؛ زمانی که اصلاح معمولاً ساده‌تر و کم‌هزینه‌تر است. با این حال بررسی تعریف زیرساخت به معنای مشاهده کامل وضعیت واقعی محیط اجرا نیست.
مخزن رسمی Checkov قابلیت‌های ابزار و چارچوب‌های پشتیبانی‌شده را توضیح می‌دهد. پروژه از چند نوع ورودی زیرساخت و سیاست‌های مبتنی بر ویژگی یا رابطه پشتیبانی می‌کند. موضوع این راهنما استفاده از آن برای بررسی زیرساخت و طراحی کنترل در جریان تغییر است. برخی قابلیت‌های محصول، اطلاعات تکمیلی یا یکپارچگی‌های سازمانی ممکن است به اتصال خدمات دیگر وابسته باشند؛ بنابراین پیش از طراحی فرایند، امکانات قابل استفاده در حالت انتخاب‌شده را بررسی کنید. یک اجرای محلی ساده و یک اتصال سازمانی کامل لزوماً دامنه و رفتار یکسانی ندارند.
تعریف منبع با وضعیت واقعی فرق دارد
فایل زیرساخت می‌گوید تیم قصد دارد چه چیزی بسازد. محیط واقعی ممکن است به علت تغییر دستی، شکست استقرار، تفاوت متغیرها یا رفتار ارائه‌دهنده از آن فاصله گرفته باشد. Checkov در نقش تحلیل ایستا به ورودی خود وابسته است. اگر یک تنظیم خارج از مخزن تغییر کند، اسکن همان مخزن به تنهایی آن را نمی‌بیند. پیشنهاد می‌شود کنترل کد با کنترل تغییر و پایش انحراف محیط همراه باشد. این تفکیک از این برداشت اشتباه جلوگیری می‌کند که عبور از بررسی کد، وضعیت امن همه منابع فعال را ثابت کرده است.
همچنین زمینه محیط اهمیت دارد. یک پورت باز در آزمایشگاه جداشده و همان پورت روی سرویس عمومی پیامد یکسانی ندارند. قاعده عمومی می‌تواند محل نیاز به بررسی را نشان دهد، ولی تصمیم نهایی ممکن است به معماری، داده و دسترسی واقعی وابسته باشد. برای هر یافته مهم، تیم باید توضیح دهد منبع در کدام محیط قرار می‌گیرد و چه مسیرهایی به آن وجود دارد. این اطلاعات بهتر است در تعریف و مستندات پروژه قابل دسترس باشند تا بازبین برای هر هشدار مجبور به کشف دوباره معماری نشود.
بررسی فایل و بررسی طرح Terraform
در Terraform می‌توان فایل‌های تعریف را بررسی کرد و همچنین طرح تولیدشده را در قالب مناسب به ابزار داد. راهنمای رسمی بررسی طرح توضیح می‌دهد که طرح می‌تواند زمینه و وابستگی بیشتری فراهم کند. فایل منبع برای بازخورد سریع هنگام نوشتن مناسب است؛ طرح به مقدارهایی نزدیک‌تر است که برای اجرای مشخص محاسبه شده‌اند. این دو مرحله رقیب نیستند. ترکیب آنها می‌تواند خطاهای زودهنگام و مسائل وابسته به متغیرهای واقعی را در نقاط مناسب جریان تغییر آشکار کند.
اما فایل طرح ممکن است داده حساس داشته باشد. مقدارهایی که در زمان اجرا تزریق می‌شوند، از جمله بعضی اسرار، می‌توانند در خروجی طرح حضور داشته باشند. بنابراین نباید آن را مانند یک فایل عمومی گزارش در اختیار همه کاربران خط ساخت قرار داد. محل ذخیره، مدت نگهداری و دسترسی به خروجی را محدود کنید. اگر برای عیب‌یابی نیاز به اشتراک بخشی از طرح است، ابتدا داده حساس را حذف کنید و مطمئن شوید حذف واقعاً در فایل انجام شده است. پوشاندن مقدار در رابط کاربری همیشه به معنی نبود آن در فایل قابل دانلود نیست.
انتخاب قواعد و شروع قابل مدیریت
فعال کردن تمام قواعد بدون شناخت محصول ممکن است حجم زیادی هشدار ایجاد کند. برای شروع، چند خانواده کنترل با اثر روشن انتخاب کنید: دسترسی عمومی ناخواسته، مجوزهای بیش از نیاز و تنظیمات حفاظتی مورد انتظار برای داده حساس. سپس یک مجموعه نمونه از پروژه‌های واقعی را بررسی کنید و سهم یافته‌های قابل اقدام را بسنجید. هدف کاهش دلخواه تعداد هشدار نیست؛ هدف فهم این است که کدام قاعده با معماری و مسئولیت تیم سازگار است و کدام مورد به زمینه بیشتری نیاز دارد. دامنه انتخاب‌شده باید صریح و قابل بازبینی باشد.
در مخزن قدیمی، نتایج اولیه را به عنوان بدهی قابل مدیریت ثبت کنید. مالک هر گروه منابع و موعد رسیدگی باید مشخص شود. کنترل تغییرهای تازه می‌تواند سخت‌گیرانه‌تر باشد، در حالی که اصلاح سابقه طبق برنامه پیش می‌رود. این روش از توقف دائمی همه کارها جلوگیری می‌کند و هم‌زمان اجازه نمی‌دهد وضعیت بدتر شود. برای یافته‌های بسیار پرخطر، جدا کردن مسیر اضطراری لازم است؛ قرار گرفتن مورد در دسته بدهی قدیمی نباید بهانه تعویق نامحدود باشد. تصمیم‌ها باید بر اثر واقعی و امکان مهار استوار باشند.
سیاست ویژگی و سیاست رابطه
بعضی کنترل‌ها فقط ویژگی یک منبع را بررسی می‌کنند؛ برای نمونه وجود یک گزینه حفاظتی مشخص. بعضی دیگر به رابطه منابع وابسته‌اند، مانند اینکه یک سرویس به چه شبکه یا نقش دسترسی متصل است. Checkov برای سیاست‌های رابطه‌ای نیز امکاناتی دارد. هنگام نوشتن قاعده اختصاصی، ابتدا سؤال امنیتی را به زبان روشن تعریف کنید و سپس ببینید آیا پاسخ در یک ویژگی دیده می‌شود یا به ارتباط چند منبع نیاز دارد. انتخاب مدل اشتباه می‌تواند قاعده‌ای بسازد که در مثال ساده درست عمل کند اما در پروژه واقعی موارد مهم را نبیند.
برای آزمون سیاست، فقط یک نمونه نامعتبر کافی نیست. نمونه مجاز، نمونه نامجاز و حالتی با مقدار نامعلوم یا ساختار متفاوت بسازید. همچنین یک منبع مشابه اما خارج از دامنه قاعده را امتحان کنید. نتیجه باید نشان دهد قاعده دقیقاً چه چیزی را بررسی می‌کند و در نبود اطلاعات چه رفتاری دارد. نگهداری این نمونه‌ها کنار سیاست باعث می‌شود تغییر آینده قابل اعتمادتر باشد. اگر سیاست از نام‌گذاری منابع برای نتیجه‌گیری امنیتی استفاده می‌کند، بررسی کنید آیا تغییر نام ساده می‌تواند آن را دور بزند یا نتیجه کاذب بسازد.
استثناهای مستند و محدود
راهنمای رسمی استثناها میان کنار گذاشتن یک بررسی در سطح منبع و انتخاب یا حذف قواعد برای کل اجرا تفاوت می‌گذارد. این تفاوت عملی مهم است. استثنای محدود به یک منبع با خاموش کردن قاعده در تمام مخزن پیامد یکسانی ندارد. پیشنهاد می‌شود هر استثنا دلیل روشن، مالک و موعد بازبینی داشته باشد. اگر کنترل معادل در جای دیگری اجرا می‌شود، آن کنترل باید مشخص و قابل اثبات باشد؛ عبارت کلی «در محیط کنترل شده است» برای بازبین بعدی کافی نیست.
استثنا باید در بازبینی تغییر دیده شود. اگر افزودن یک توضیح در کد می‌تواند هشدار را حذف کند، تیم باید همان توضیح را مانند تغییر سیاست امنیتی بررسی کند. همچنین گزارش موارد کنارگذاشته‌شده را جدا از موارد قبول‌شده نگه دارید. در غیر این صورت صفحه سبز ممکن است ترکیبی از منابع سالم و منابع دارای استثنا باشد، بدون اینکه تفاوت دیده شود. بازبینی دوره‌ای استثناها به‌ویژه پس از تغییر معماری مهم است؛ کنترلی که قبلاً در یک لایه شبکه وجود داشته ممکن است با مهاجرت سرویس دیگر برقرار نباشد.
اتصال به درخواست ادغام
بهترین زمان بازخورد، زمانی است که نویسنده هنوز زمینه تغییر را به خاطر دارد. اجرای بررسی روی درخواست ادغام می‌تواند مسیر فایل و شناسه قاعده را به همان تغییر وصل کند. پیام باید توضیح دهد چه شرطی نقض شده و از کجا می‌توان راهنمای اصلاح را دید. صرف نمایش یک کد بدون زمینه، توسعه‌دهنده را به جست‌وجوی جداگانه مجبور می‌کند. همچنین نتایج قبلی نباید هر بار به صورت هشدار تازه روی تغییر نامرتبط ظاهر شوند. طراحی گزارش باید میان بدهی موجود و مسئله ایجادشده در تغییر جدید تفاوت بگذارد.
خط ساخت باید حالت خطای ابزار را از عبور قواعد جدا کند. نبود وابستگی لازم، خطای خواندن ورودی یا مشکل پردازش فایل نمی‌تواند نتیجه امن محسوب شود. در محیط آزمایشی، یک فایل نامعتبر و یک تخلف شناخته‌شده قرار دهید و رفتار مرحله را ببینید. سپس یک نمونه اصلاح‌شده اجرا کنید تا مسیر موفقیت نیز مشخص شود. سیاست توقف باید روشن باشد: کدام یافته مانع ادغام می‌شود، چه کسی می‌تواند استثنا بدهد و چگونه تصمیم ثبت می‌شود. کنترل بدون این مسیرها معمولاً به دور زدن غیررسمی یا خاموش کردن کامل منتهی می‌شود.
نصب، وابستگی و نسخه ابزار
نسخه Checkov را از انتشارهای رسمی یا روش نصب مستند پروژه انتخاب کنید. ثابت نگه داشتن نسخه و وابستگی‌ها در محیط ساخت به تکرارپذیری کمک می‌کند. ارتقای ابزار ممکن است قواعد جدید یا رفتار متفاوتی به همراه آورد؛ ابتدا آن را روی چند مخزن نماینده اجرا کنید و اختلاف‌ها را بخوانید. یک افزایش ناگهانی هشدار لزوماً به معنی بدتر شدن زیرساخت نیست. اگر تغییر ناشی از قاعده تازه باشد، تیم نیاز به زمان و راهنمای اصلاح دارد تا کنترل جدید با اعتماد و فهم کافی پذیرفته شود.
در بعضی پروژه‌ها بررسی ماژول‌ها یا محتوای وابسته می‌تواند به دریافت داده بیرونی نیاز داشته باشد. مسیر دریافت و نسخه وابستگی‌ها باید کنترل شود تا اسکن امروز و فردا روی محتوای متفاوت انجام نشود. حساب خط ساخت نیز فقط دسترسی لازم برای خواندن و بررسی داشته باشد. صرف اینکه ابزار امنیتی است دلیل کافی برای دادن مجوز مدیریت محیط تولید به آن نیست. اگر بررسی طرح به اعتبارنامه ارائه‌دهنده نیاز دارد، این مرحله را از مرحله تحلیل فایل جدا طراحی کنید و نقش‌ها را متناسب با کار واقعی محدود کنید.
سناریوی اصلاح یک یافته
فرض کنید بررسی یک منبع ذخیره‌سازی، دسترسی گسترده‌تر از سیاست سازمان را نشان می‌دهد. نخست ببینید منبع متعلق به کدام محیط است و چه مصرف‌کننده‌ای واقعاً به آن نیاز دارد. سپس تعریف دسترسی را به نقش یا مسیر لازم محدود کنید و طرح جدید را بررسی کنید. پس از استقرار، باید تأیید شود مصرف‌کننده مجاز همچنان کار می‌کند و مسیر ناخواسته بسته شده است. عبور دوباره Checkov نشان می‌دهد تعریف با قاعده سازگار شده، اما آزمون عملی دسترسی به محیط، بخش دیگری از تأیید اصلاح است که نباید حذف شود.
اگر مالک سرویس می‌گوید دسترسی گسترده ضروری است، از او بخواهید نیاز دقیق را توضیح دهد. گاهی مسئله با تفکیک منبع عمومی و خصوصی یا محدود کردن یک عملیات حل می‌شود. گاهی نیز استثنای موقت با کنترل جبرانی لازم است. ثبت دلیل و موعد بازنگری باعث می‌شود تصمیم معماری از یک خاموش کردن مبهم قاعده متمایز باشد. این گفت‌وگو ارزش اصلی سیاست به صورت کد را نشان می‌دهد: قاعده یک پرسش امنیتی را در زمان تغییر مطرح می‌کند و تیم را به تصمیم قابل مشاهده و قابل تکرار می‌رساند.
ارزیابی ارزش برای تیم
برای سنجش موفقیت، زمان رسیدن بازخورد به نویسنده، سهم یافته‌های اصلاح‌شده پیش از استقرار و سن استثناهای باز را اندازه بگیرید. تعداد قواعد فعال به تنهایی شاخص خوبی نیست. مجموعه کوچک قواعد قابل اعتماد و دارای مالک می‌تواند از مجموعه بزرگی که همیشه نادیده گرفته می‌شود مؤثرتر باشد. همچنین مواردی را که پس از استقرار کشف می‌شوند بررسی کنید تا معلوم شود ورودی ناقص بوده، قاعده وجود نداشته یا زمینه اجرا در تحلیل ایستا قابل مشاهده نبوده است. این بازخورد مسیر توسعه سیاست‌ها را مشخص می‌کند.
Checkov برای تیمی مناسب است که زیرساخت را در فرایند تغییر قابل بازبینی نگه می‌دارد و می‌خواهد بخشی از خطاهای تنظیمات را زودتر ببیند. این ابزار جای کنترل دسترسی واقعی، پایش محیط و طراحی امن معماری را نمی‌گیرد. با انتخاب ورودی درست، مدیریت دقیق طرح‌های حساس، سیاست‌های آزموده و استثناهای محدود، می‌توان آن را به بخشی قابل اعتماد از توسعه زیرساخت تبدیل کرد. نتیجه مطلوب، تغییرهایی است که دلیل امنیتی آنها روشن است و پیش از رسیدن به محیط تولید اصلاح می‌شوند، همراه شواهدی که بازبین بعدی بتواند آن را بفهمد.
