‏حاکمیت زیرساخت با OPA و الگوهای Policy as Code

Policy as Code یعنی تبدیل قوانین امنیتی و انطباق به کد قابل اجرا که به‌جای بررسی دستی، به‌طور خودکار در pipeline توسعه اعمال می‌شه. ابزار Open Policy Agent (OPA) این کار رو با ارزیابی خروجی JSON پلن ترافرم انجام می‌ده — یعنی قبل از اینکه هر تغییری روی زیرساخت اعمال بشه، سیاست‌ها چک می‌شن.

یک رویکرد الگو-محور، قوانین رو به‌جای دسته‌بندی سرویس‌به‌سرویس، حول نیت کنترلی تکرارشونده سازمان می‌ده. پنج الگوی اصلی اینا هستن: متادیتای اجباری (تگ‌ها)، پیکربندی مجاز (ریجن‌های تأییدشده)، محدودیت در معرض قرار گرفتن عمومی، اعمال حفاظت‌های پایه (رمزنگاری، لاگینگ)، و محدودیت امتیاز در IAM. این ساختار باعث می‌شه هم مهندس ابر و هم کارشناس انطباق درباره‌ی یک چیز حرف بزنن.

مثال اول، الگوی protection enforcement رو برای S3 پیاده می‌کنه. این policy چک می‌کنه که bucket policy یه دستور Deny برای درخواست‌های بدون SSL داشته باشه:

deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket_policy"
    is_create_or_update(resource.change.actions)
    policy_value := resource.change.after.policy
    policy := json.unmarshal(policy_value)
    not has_secure_transport_deny(policy)
    msg := sprintf(
        "[S3-OPA-1] Resource '%s' does not enforce SSL/TLS.",
        [resource.address]
    )
}

مثال دوم، الگوی exposure restriction رو برای security group‌های VPC اجرا می‌کنه. پورت‌های حساسی مثل ۲۲ (SSH)، ۳۳۸۹ (RDP) و ۵۴۳۲ (PostgreSQL) رو چک می‌کنه که از 0.0.0.0/0 قابل دسترس نباشن. مثال سوم هم الگوی privilege constraint رو در trust policy نقش‌های IAM پیاده می‌کنه و به دنبال principal‌های wildcard می‌گرده که دسترسی بیش از حد گسترده‌ای ایجاد می‌کنن.

برای ادغام OPA در pipeline، توالی کار ثابته: validate → plan → تبدیل به JSON → ارزیابی با OPA → ذخیره‌ی artifact. این جریان هم در GitHub Actions و هم GitLab CI با همین ترتیب پیاده می‌شه. نتیجه‌ی ارزیابی به‌عنوان artifact نگه داشته می‌شه تا هم در تصمیم‌گیری تأیید تغییر و هم در ممیزی‌های بعدی قابل استناد باشه.

برای rollout توصیه می‌شه با حالت advisory شروع کنید — نتایج نمایش داده بشن ولی کسی بلاک نشه — تا تیم‌ها با خروجی‌ها آشنا بشن. بعد الگوهای پرمطمئن‌تر رو enforce کنید و در مرحله‌ی آخر، پوشش رو گسترش بدید و با سرویس‌های نظارتی AWS مثل Config و Security Hub ترکیب کنید. OPA جایگزین سرویس‌های بومی AWS نمی‌شه، بلکه یه لایه‌ی پیشگیرانه پیش از دیپلوی اضافه می‌کنه.

نکات کلیدی:

• OPA پلن ترافرم رو قبل از دیپلوی در برابر سیاست‌های تعریف‌شده ارزیابی می‌کنه
• الگوهای پنج‌گانه (متادیتا، پیکربندی مجاز، محدودیت exposure، حفاظت، IAM) ساختار قابل‌فهمی برای هر دو تیم فنی و انطباق ایجاد می‌کنن
• نتایج ارزیابی باید به‌عنوان artifact نگه داشته بشن تا در تأیید تغییر و ممیزی مفید باشن
• با حالت advisory شروع کنید، نه enforcement فوری
• OPA مکمل سرویس‌های AWS (Config، Security Hub، Organizations) است، نه جایگزین آن‌ها