بررسی های امنیتی سفارشی برای ارائه دهنده کنترل ابر AWS با Checkov

Checkov یک ابزار تجزیه و تحلیل کد استاتیک منبع باز است که برای اسکن زیرساخت ها به عنوان کد (IAC) برای مشکلات امنیتی و انطباق طراحی شده است. این کشور از چارچوب های مختلفی از جمله Terraform ، CloudFormation ، Kubernetes و موارد دیگر پشتیبانی می کند. این ابزار قبل از تولید آن به شناسایی غلط ، خطرات امنیتی و نقض انطباق کمک می کند.

ارائه دهنده AWS Cloud Control (AWSCC) برای Terraform نسبتاً جدید است و فاقد پشتیبانی گسترده اکوسیستم است که ارائه دهنده سنتی AWS از آن برخوردار است. این شامل ابزارهای اسکن امنیتی مانند Checkov است که در حال حاضر پشتیبانی داخلی برای منابع AWSCC ندارد. این امر به ویژه از آنجا که سازمانها به تصویب ارائه دهنده AWSCC برای پوشش خدمات AWS خود شروع کردند ، از اهمیت ویژه ای برخوردار است.

سفر من با چکف

من با سیاستهای Checkov به عنوان یک جایگزین آسان برای هر چیزی که در آنجا از دیدگاه موتور خط مشی زیرساخت وجود دارد ، کار کرده ام. سهولت استفاده با یک باینری که برخی از چک ها را در برابر پیکربندی زیرساخت های شما اجرا می کند ، در مراحل قبلی یک پیروزی آسان بود. من شخصاً احساس می کنم که در مقایسه با سایر گزینه های دیگر پر سر و صدا شده است زیرا طبقه بندی شدت تحت مجوز است.

سیاست ها و نمونه های پایه

با دیدن شکاف در پوشش خط مشی برای منابع AWSCC ، تصمیم گرفتم برای رسیدگی به این موضوع ، سیاست های Checkov سفارشی ایجاد کنم. از آنجا که چکوف از پایتون استفاده می کند و من از آن راحت بودم ، شروع کردم به چک های ارائه دهنده ارائه دهنده AWS موجود. چالش ها:

• PRS از زمانی که من آن را باز کردم ، خیلی جابجا نشده است و من آن را با به روزرسانی های اصلی شعبه به روز کرده ام
• بین منابع AWS و AWSCC همبستگی یا نقشه دقیقی وجود ندارد که بتوانید آن را ترجمه کنید

با وجود این چالش ها ، من توانستم مجموعه ای از بررسی های امنیتی پایه را برای ارائه دهنده AWSCC تهیه کنم که می تواند با چکف ادغام شود. من قصد ندارم به جزئیات نحوه ساخت یک خط مشی چک بپردازم. در اینجا یک مثال ساده از یک چک سفارشی (احتمالاً اولین موردی که من نوشتم) آورده شده است که هیچ اعتبار AWS سخت در پیکربندی ارائه دهنده را تضمین نمی کند:

from checkov.terraform.checks.provider.base_check import BaseProviderCheck
from checkov.common.models.enums import CheckCategories, CheckResult

class AWSCCCredentials(BaseProviderCheck):
    def __init__(self) -> None:
        name = "Ensure no hard coded AWS access key and secret key exists in provider"
        id = "CKV_AWS_41"
        supported_provider = ["awscc"]
        categories = [CheckCategories.SECRETS]
        super().__init__(name=name, id=id, categories=categories, supported_provider=supported_provider)

    def scan_provider_conf(self, conf: Dict[str, List[Any]]) -> CheckResult:
        result = CheckResult.PASSED
        if self.secret_found(conf, "access_key", access_key_pattern):
            result = CheckResult.FAILED
        if self.secret_found(conf, "secret_key", secret_key_pattern):
            result = CheckResult.FAILED
        return result

اگر یک کلید دسترسی یا یک کلید مخفی در پیکربندی ارائه دهنده را پیدا کند ، چک شکست خواهد خورد. این به جلوگیری از قرار گرفتن در معرض اعتبار تصادفی در سیستم های کنترل نسخه کمک می کند.

مقیاس با Genai

پس از اولین تکرار سیاست ها ، بدیهی بود که می توانم از یک عامل برنامه نویسی Genai برای تکمیل 100 سیاست عجیب و غریب که قصد داشتم در اینجا با آن مقابله کنم استفاده کنم. رویکرد این بود:

• از توسعه دهنده A Amazon Q بخواهید تا کنترل های هاب امنیتی را برای یک سرویس یا چک چک AWS شناسایی کرده و یک خط مشی بنویسید/برای AWSCC بررسی کنید.
• از توسعه دهنده A Amazon Q بخواهید تا نمونه ای از گذر و ناکامی را برای چک که فقط در چارچوب تست جدید استفاده می کنید ، استفاده کند. من نمونه های پایه ای داشتم که برای PRS ایجاد کردم به عنوان چیزی که می تواند برای ایجاد موارد جدیدتر استفاده شود.
• اعتبار سنجی را تأیید کنید و با استفاده از چک های ناکامی دقیق هستند terraform validate
• یک گردش کار عمل GitHub را اضافه کنید که چک های گذر/شکست مورد انتظار را در برابر موارد واقعی تأیید کند تا روند تکراری صادقانه نگه دارد.

به عنوان مثال ، هنگام ایجاد بررسی Ekspublicaccess ، من آمازون Q را با “نوشتن یک خط مشی چک برای خوشه های AWSCC EKS که تضمین دسترسی به نقطه پایانی عمومی غیرفعال است” را وادار کردم.

نتیجه همان چیزی است که در اینجا در مخزن مشاهده می کنید.

کمک به بازگرداندن

من برای ادغام این چک ها درخواست های کشش را به مخزن Checkov ارسال کرده ام:

• PR #6647

• PR #7043. این زیر مجموعه از لیست اولیه من پس از انتقال آنها به عنوان چک های سفارشی است.

ویژگی

این مخزن شامل مجموعه ای جامع از بررسی های امنیتی برای منابع ارائه دهنده AWSCC ، با چندین ویژگی اصلی است:

• پوشش گسترده: بیش از 140 چک امنیتی مختلف شامل خدمات مختلف AWS و بهترین روشهای امنیتی
• نمونه های کاری: هر چک شامل نمونه های مربوط به Terraform است که هم تنظیمات سازگار و هم غیر سازگار را نشان می دهد
• اعتبار سنجی سیاست: تمام نمونه ها در برابر سیاست ها اجرا می شوند تا اطمینان حاصل کنند که آنها به درستی مسائل امنیتی را شناسایی می کنند
• خلاصه نتایج عمل: گردش کار Action GitHub خلاصه ای از نتایج را ارائه می دهد ، و این باعث می شود که آیا هرگونه چک به درستی کار نمی کند ، تشخیص آسان است
• ادغام آسان: ساده برای ادغام با خطوط لوله CI/CD موجود

دایرکتوری نمونه ها حاوی پرونده های Terraform است که با هر چک مطابقت دارند و به شما امکان می دهند رفتار چک ها را در برابر تنظیمات واقعی آزمایش و تأیید کنید. هنگامی که عمل GitHub اجرا می شود ، خلاصه ای را نشان می دهد که نشان می دهد کدام یک از چک ها را انجام داده و شکست خورده است ، و راهی سریع برای تأیید اعتبار همه چک ها همانطور که انتظار می رود ، فراهم می کند.

چه چیزی بعدی؟

هدف این است که همچنان به گسترش پوشش بررسی های امنیتی برای منابع ارائه دهنده AWSCC ادامه دهید ، با تمرکز بر روی هرگونه کنترل جدید ذکر شده است.

ادغام با اقدامات GitHub

با استفاده از اقدامات GitHub می توانید به راحتی این چک های سفارشی را در خط لوله CI/CD خود ادغام کنید. در اینجا نحوه تنظیم آن آورده شده است:

- name: Run Checkov
  id: checkov
  uses: bridgecrewio/checkov-action@v12
  with:
    directory: .
    framework: terraform
    soft_fail: true
    output_format: cli,sarif
    output_file_path: console,results.sarif
    external_checks_repos: https://github.com/quixoticmonk/checkov-awscc-custom-checks.git?ref=checks

توجه داشته باشید checks مرجع شعبه به عنوان external_checks_repo کلون می شود و من متوجه شدم که یک اجرای اولیه در لیست نمونه های خود من شکست خورده است. این پیکربندی Checkov را در برابر پرونده های Terraform شما ، از جمله چک های سفارشی AWSCC از مخزن خارجی اجرا می کند. نتایج در کنسول نمایش داده می شود و همچنین به عنوان یک فایل SARIF برای تجزیه و تحلیل بیشتر یا ادغام با سایر ابزارها ذخیره می شود.

پایان

با افزایش پذیرش کنترل ابر AWS ، داشتن چک های امنیتی قوی به طور فزاینده ای اهمیت پیدا می کند. این سیاست های Checkov سفارشی به ایجاد شکاف بین ارائه دهنده سنتی AWS و AWSCC کمک می کند و از شیوه های امنیتی مداوم در زیرساخت های شما اطمینان می دهد. من شما را تشویق می کنم که این چک ها را در محیط خود امتحان کنید و سیاست های دیگری را برای گسترش بیشتر پوشش ارائه دهید.