مردم معمولاً کشف میکنند که چیست IaC اسکن کردن وقتی چیزی خراب میشود. یک منبع ابری در معرض دید قرار میگیرد. یک سطل ذخیرهسازی عمومی است. یک نقش مجوزهایی دارد که هیچکس به خاطر نمیآورد که آنها را تأیید کرده است. وقتی تیمها مشکل را ردیابی میکنند، اغلب همان علت ریشهای را پیدا میکنند: زیرساخت ناامن به عنوان کد. زیرساخت به عنوان کد نحوه ساخت زیرساخت را تغییر داده است، اما همچنین نحوه مقیاسبندی اشتباهات را نیز تغییر داده است. یک پیکربندی اشتباه که یک بار نوشته شده و در همه جا دوباره استفاده میشود، میتواند خطر را سریعتر از هر خطای دستی دیگری منتشر کند. این [سیستم/سیستم/سیستم] دقیقاً برای پرداختن به همین مشکل وجود دارد. در اصل، این یک سوال نظری نیست. این یک سوال عملی است: چگونه تعاریف زیرساخت ناامن را قبل از استقرار تشخیص دهیم؟
تعریف سریع: چیست؟? #
IaC اسکن فرآیند تجزیه و تحلیل الگوهای زیرساخت به عنوان کد برای شناسایی پیکربندیهای نادرست امنیتی، نقض سیاستها و تنظیمات پرخطر قبل از تأمین زیرساخت است. وقتی مردم میپرسند چیست؟ IaC اسکن، سادهترین پاسخ این است: تعاریف زیرساخت نوشته شده به صورت کد را بررسی میکند، مانند Terraform، CloudFormation، ARM، یا کوبرنیتس مسائل امنیتی را در اوایل چرخه حیات توسعه آشکار و شناسایی میکند. IaC اسکن به زیرساختهای در حال اجرا نگاه نمیکند. به آنچه که اراده در صورت اعمال کد ایجاد شود. این تمایز بسیار مهم است. IaC security اسکن شیفتهای تشخیص سمت چپ، جایی که رفع مشکلات ارزانتر است و احتمال بروز حوادث کمتر است.
چرا مهم است? #
زیرساختها قبلاً به صورت دستی ایجاد میشدند. اکنون در فایلهای کنترلشده با نسخه تعریف و به صورت خودکار مستقر میشوند. این تغییر سرعت و ثبات را بهبود میبخشد، اما همچنین به این معنی است که اشتباهات امنیتی قابل تکرار میشوند.
درک آنچه هست IaC اسکن کردن مستلزم درک این خطر است. پیکربندیهای نادرست مانند نقشهای IAM بیش از حد مجاز، قرار گرفتن در معرض شبکه عمومی، ذخیرهسازی رمزگذاری نشده یا غیرفعال کردن ثبت وقایع، اغلب به معنای سنتی آسیبپذیری نیستند. آنها نقص طراحی هستند. این مطالعه بر روی این نقصها تمرکز دارد. این مطالعه ارزیابی میکند که آیا تعاریف زیرساخت از بهترین شیوههای امنیتی، سیاستهای سازمانی و توصیههای ارائهدهنده ابر پیروی میکنند یا خیر. IaC اسکن به تیمها کمک میکند تا مشکلات را قبل از وجود منابع ابری تشخیص دهند، نه پس از بهرهبرداری از آنها.
چی IaC اسکن به دنبال? #
IaC security اسکن معمولاً طیف وسیعی از خطرات پیکربندی را که شناخته شده و بارها مورد سوء استفاده قرار گرفتهاند، بررسی میکند. این خطرات شامل منابع در معرض دید عموم، فقدان رمزگذاری، مجوزهای بیش از حد، قوانین شبکه ناامن، عدم ثبت وقایع یا نظارت و پیشفرضهای ناامن است. هیچ یک از این مشکلات نیازی به سوءاستفادههای روز صفر ندارند. آنها به خطاهای پیکربندی متکی هستند. وقتی میپرسید چه چیزی IaC اسکن کردن است، مهم است بدانیم که هدف حدس زدن نیست. این کار ارزیابی زیرساختهای اعلام شده در برابر قوانین امنیتی است. IaC اسکن، آنچه را که به صورت کد نوشته شده است با آنچه که ایمن یا قابل قبول تلقی میشود، مقایسه میکند.
IaC مدیریت وضعیت اسکن در مقابل امنیت ابری #
یک سردرگمی رایج در مورد چیستی IaC اسکن کردن، تفاوت آن با ابزارهایی است که محیطهای ابری مستقر را اسکن میکنند. ابزارهای مدیریت وضعیت امنیت ابری، زیرساخت در حال اجرا را تجزیه و تحلیل میکنند. این ابزار تعاریف را قبل از استقرار تجزیه و تحلیل میکند. هر دو مفید هستند، اما اهداف متفاوتی را دنبال میکنند. IaC security اسکن کردن از همان ابتدا مانع از رسیدن مشکلات به مرحله تولید میشود. رفع یک مشکل در کد، سریعتر و ایمنتر از رفع آن در یک محیط واقعی است. IaC اسکن، امنیت زمان اجرا را تکمیل میکند، نه اینکه جایگزین آن شود.
مزایای تیمهای DevOps #
برای تیمهای DevOps، این اسکن به معنای کند کردن کارها نیست. بلکه به معنای جلوگیری از دوبارهکاری و حوادث است. یکی از مزایای اصلی، بازخورد اولیه است. توسعهدهندگان هنگام نوشتن کد زیرساخت، فوراً به مسائل امنیتی دسترسی پیدا میکنند. به جای اینکه یافتههای امنیتی هفتهها بعد ظاهر شوند،... IaC مشکلات سطحی را زمانی که رفع آنها آسانتر است، بررسی کنید. مزیت دیگر، ثبات و پایداری است. IaC security اسکن هر بار قوانین یکسانی را اعمال میکند. این امر وابستگی به دانش قبیلهای و بررسیهای دستی را کاهش میدهد. تیمها لازم نیست هر دام ارائهدهنده ابر را به خاطر بسپارند. اسکنر این کار را انجام میدهد. درک آنچه IaC اسکن همچنین به معنای تشخیص تأثیر آن بر همکاری است. تیمهای امنیتی میتوانند انتظارات را به صورت قوانین مدون کنند، در حالی که تیمهای DevOps استقلال خود را حفظ میکنند. نتیجه، غافلگیریهای کمتر و تأییدیههای دقیقه نودی کمتر است. در نهایت، به مقیاسپذیری امنیت کمک میکند. با رشد زیرساختها، بررسی دستی این کار را نمیکند. یک بررسی خودکار IaC مقیاسها را با کدبیس اسکن کنید، نه با تعداد کارکنان.
چگونه در DevSecOps جای میگیرد؟? #
DevSecOps در مورد ادغام امنیت در گردشهای کاری موجود است، نه اضافه کردن دروازهها در انتها. من به طور طبیعی با این مدل مطابقت دارم.
وقتی تیمها میفهمند که چیست IaC اسکن، آنها دیگر آن را به عنوان یک افزونه امنیتی نمیبینند و آن را به عنوان بخشی از کنترل کیفیت میبینند. همانطور که کد برای خطاهای نحوی بررسی میشود، کد زیرساخت نیز برای خطاهای امنیتی بررسی میشود. IaC security اسکن اجازه میدهد تا الزامات امنیتی به صورت کد اجرا شوند. این امر به خوبی با ... همسو است. اصل خودکارسازی DevOps، در IaC اسکن فقط یک بررسی خودکار دیگر میشود که باید با موفقیت انجام شود.
چگونه آن را در ... ادغام کنیم CI/CD Pipelines? #
ادغام این اسکن در CI/CD pipelineجایی است که بیشترین ارزش را ارائه میدهد. رایجترین رویکرد، اجرای یک IaC اسکن در حین pull requestsوقتی کد زیرساخت تغییر میکند، اسکن به طور خودکار اجرا میشود و یافتهها را قبل از ادغام تغییر گزارش میدهد. این مستقیماً به جنبه عملی آنچه که ... IaC اسکن: تشخیص مشکلات قبل از رسیدن به صفحه اصلی.
نکتهی دیگر در مورد ادغام، در طول مراحل ساخت است. IaC security اسکن میتواند به عنوان بخشی از pipeline مشاغل، در صورت شناسایی مشکلات پرخطر، ساخت را با شکست مواجه میکنند. این تضمین میکند که تعاریف زیرساخت ناامن هرگز به مراحل استقرار نمیرسند.
برخی تیمها این نوع اسکن را به صورت محلی نیز انجام میدهند. pre-commit hooksاین امر تشخیص را حتی بیشتر به سمت چپ منتقل میکند. توسعهدهندگان قبل از ارسال کد، بازخورد دریافت میکنند و بعداً اصطکاک را کاهش میدهند. اصل کلیدی، ثبات است. IaC اسکن باید خودکار و اجباری باشد. اسکنهای اختیاری تحت فشار نادیده گرفته میشوند. یک اسکن اجباری IaC اسکن به بخشی از نحوه ارائه نرمافزار تبدیل میشود.
باورهای غلط رایج #
یک تصور غلط در مورد چیستی IaC اسکن کردن این است که جایگزین ابزارهای امنیتی ابری میشود. اما اینطور نیست. از مشکلات زودتر جلوگیری میکند، اما کنترلهای زمان اجرا هنوز مورد نیاز هستند.
تصور غلط دیگر این است که فقط به نفع تیمهای امنیتی است. در واقعیت، تیمهای DevOps بیشترین سود را میبرند. عقبگردهای کمتر، حوادث کمتر و رفع مشکلات اضطراری کمتر، همگی از اقدامات مؤثر ناشی میشوند. IaC security اسکن کردن
برخی معتقدند IaC اسکن، نتایج مثبت کاذب زیادی ایجاد میکند. این معمولاً زمانی اتفاق میافتد که قوانین با مدل ریسک سازمان تنظیم نشده باشند. مانند هر کنترل امنیتی، این مورد نیز نیاز به کالیبراسیون دارد.
محدودیت ها IaC پویش #
فهمیدن چی IaC اسکن کردن همچنین به معنای فهمیدن این است که چه کارهایی را نمیتواند انجام دهد. IaC اسکن نمیتواند مشکلاتی را که پس از استقرار ایجاد میشوند، تشخیص دهد. نمیتواند رفتار زمان اجرا را ببیند. همچنین نمیتواند خطراتی را که به زمینه خارجی که در کد وجود ندارد، بستگی دارند، ارزیابی کند. با این حال، این محدودیتها از ارزش آن نمیکاهد. IaC security اسکن به یک دسته خاص و بسیار رایج از ریسک میپردازد: تعاریف زیرساخت ناامن.
چرا IaC اسکن کردن یک کنترل پایه است? #
پس چه؟ IaC واقعاً در مورد اسکن کردن؟ این در مورد اذعان به این است که زیرساخت کد است و کد باید به طور خودکار بررسی شود. این یک روش سیستماتیک برای تشخیص پیکربندیهای نادرست قبل از تبدیل شدن به حادثه فراهم میکند. این امر به تیمهای امنیتی امکان میدهد تا مقیاسپذیر شوند، تیمهای DevOps سریعتر حرکت کنند و سازمانها میتوانند بدون قربانی کردن اتوماسیون، ریسک را کاهش دهند.
An IaC اسکن چیز خوبی نیست. برای هر سازمانی که زیرساخت ابری را در مقیاس بزرگ مستقر میکند، IaC security اسکن یک کنترل پایه استاگر به درستی انجام شود، نامرئی میشود، و نکته دقیقاً همین است.
سکوهایی مانند شیگنی با تجزیه و تحلیل زیرساخت به عنوان کد در اوایل چرخه عمر توسعه و اجرای امنیت، از این رویکرد پشتیبانی کنید. guardrails قبل از اینکه پیکربندیهای نادرست به مرحله تولید برسند. با ادغام مستقیم این اسکن در گردشهای کاری توسعهدهندگان و CI/CD pipelineتیمها میتوانند ریسک زیرساخت را در جایی که رفع آن سادهترین و کمخرجترین است، برطرف کنند. امنیت زمانی بهترین عملکرد را دارد که بهصورت داخلی، خودکار و کسلکننده باشد.

