عملیات و تنظیمات حسابرسی مدیریت

تنظیمات حسابرسی

1) هدف و ارزش

تنظیمات حسابرسی پاسخگویی قابل اثبات و تکرارپذیری تغییر را تضمین می کند: چه کسی، چه زمانی و چه چیزی تغییر کرده است. چه چیزی موجه است ؛ به عنوان تست شده ؛ چگونه به عقب برگردیم این خطر حوادث، نشت اسرار، ناسازگاری انطباق و ویرایش های «پنهان» در تولید را کاهش می دهد.

• یک منبع واحد حقیقت (SoT) برای پیکربندی.
• ردیابی تغییر کامل (پایان به پایان).
• انتشار قابل پیش بینی و بازگشت سریع.
• سیاست های انطباق و امنیت

2) محدوده

زیرساخت: Terraform/Helm/Ansible/K8s نشان می دهد، شبکه ACL/WAF/CDN.
پیکربندی برنامه: فایل های 'yaml/json/properties'، پرچم های ویژگی، محدودیت ها/سهمیه ها.
اسرار و کلید: طاق/kms، گواهینامه ها، نشانه ها، کلمه عبور.
خطوط لوله داده: طرحها، تبدیلها، برنامههای ETL/جریان.
یکپارچگی: PSP/KYC/ارائه دهندگان، webhooks، سیاست های مجدد/timeout.
قابلیت مشاهده: قوانین هشدار، داشبورد، SLO/SLA.

3) اصول

پیکربندی به عنوان داده: اعلانی، نسخه، مصنوعات قابل آزمایش.
تغییرناپذیری و بیهودگی: تکرارپذیری رسانه از کد.
طرح ها و قراردادها: اعتبار سنجی دقیق (JSON-Schema/Protobuf)، سازگاری عقب/جلو.
به حداقل رساندن ویرایش کتابچه راهنمای کاربر: تغییرات تنها از طریق MR/PR.

تفکیک وظایف (SoD) و 4 چشم: نویسنده! = deploer ؛ بررسی اجباری

Attribution and signatures: signatures of commits/releases, تصدیق مصنوعات.

4) معماری حسابرسی

1. SCM (Git) به عنوان SoT: همه در مخزن پیکربندی می شوند، شاخه «اصلی» محافظت می شود.

• پیکربندی رجیستری (دایرکتوری پیکربندی ها، اموال، SLA ها، محیط ها)،
• رجیستری طرح (نسخه های طرح پیکربندی/رویداد)،
• موتور سیاست (OPA/Conftest) - مجموعه ای از چک.
• 3. CI/CD-gates: format/scheme → static check → policy checks → secret scan → dry-run → change plan.
• 4. تحویل: GitOps (به عنوان مثال ArgoCD/Flux) با آشکارساز رانش و سیاهههای مربوط به ممیزی برنامه.
• 5. فروشگاه شواهد: یک مخزن از مصنوعات حسابرسی (طرح، سیاهههای مربوط، امضا، ساخت، SBOM).
• 6. ورود به سیستم عمل: ورود به سیستم تغییر ناپذیر (اضافه کردن فقط) از 'CREATE/تایید/اعمال/برگشت/دسترسی' حوادث.

5) مدل داده حسابرسی (حداقل)

Сущности: 'ConfigItem (id, env, service, owner, schema_version, sensitivity)'

События: 'change _ id, actor, action, ts, diff_hash, reason, approval []'

: 'plan _ url، ، ، امضا

اتصالات: RFC/ticket PR depla (sha) ضبط انتشار نظارت SLO.

6) روند تغییر (پایان به پایان)

1. RFC/بلیط → هدف، خطر، برگشت.
2. PR/MR → پیوند، اعتبار سنجی شماتیک، بررسی سیاست، اسکن مخفی.
3. طرح/پیش نمایش → خشک اجرا/طرح، تفاوت منابع، برآورد هزینه/تاثیر.
4. تایید (4-eyes/SoD، برچسب CAB در معرض خطر).
5. استقرار (توسط پنجره/تقویم) → GitOps اعمال می شود ؛ هشدار رانندگي فعال شد.
6. تأیید → دود/SLO-gardrails، تأیید نتیجه.
7. بایگانی شواهد → فروشگاه شواهد ؛ به روز رسانی فرهنگ لغت پیکربندی.

7) سیاست ها و قوانین (مثال)

SoD: نویسنده روابط عمومی در تحریک نگه ندارد.
محدودیت زمانی: بدون تولید خارج از «انجماد».
محدوده: تغییر کلید های حساس نیاز به 2 به روز رسانی از امنیت/انطباق.
رازها: نگه داشتن آنها در انبار ممنوع است ؛ مسیر طاق + فقط مراجع نقش دسترسی.
تور: ورود با '0. 0. 0. 0/0 "بدون استثناء موقت و TTL مجاز نیست.
هشدارها: کاهش بحرانی بودن P1 بدون CAB ممنوع است.

8) کنترل مخفی

ذخیره سازی Vault/KMS، TTL های کوتاه، چرخش اتوماتیک.
اسکن مخفی در CI (الگوهای کلیدی، آنتروپی بالا).

جداسازی اسرار توسط محیط/نقش ؛ حداقل امتیازات لازم

رمزگذاری «بر روی سیم» و «در حالت استراحت» ؛ گزارش های بازرسی دسترسی به اسرار بسته شده است.

9) ابزار (متغیر)

خط/طرح: 'yamllint'، 'jsonschema'، 'ajv'، 'نشانه'.
سیاست: OPA/Conftest، Checkov/tefsec/kube-policies.
GitOps: ArgoCD/Flux (تشخیص رانش، حسابرسی، RBAC).
اسرار: HashiCorp Vault، Cloud KMS، مدیران CERT.
اسکنر: trufflehog، gitleaks (اسرار) ؛ OPA/مقررات (قوانین).
گزارش: صادرات سیاهههای مربوط به DWH/BI، لینک به حادثه و تغییر سیستم.

10) نمونه هایی از قوانین و مصنوعات

JSON-Schema برای پیکربندی محدود

json
{
"$schema": "http://json-schema. org/draft-07/schema#",
"title": "limits",
"type": "object",
"required": ["service", "region", "rate_limit_qps"],
"properties": {
"service": {"type":"string", "pattern":"^[a-z0-9-]+$"},
"region": {"type":"string", "enum":["eu","us","latam","apac"]},
"rate_limit_qps": {"type":"integer","minimum":1,"maximum":5000},
"timeouts_ms": {"type":"integer","minimum":50,"maximum":10000}
},
"additionalProperties": false
}

Conftest/OPA (rego) - انکار '0. 0. 0. 0/0 'ورود به в

rego package policy. network

deny[msg] {
input. kind == "IngressRule"
input. cidr == "0. 0. 0. 0/0"
msg:= "Ingress 0. 0. 0. 0/0 is not allowed. Specify specific CIDRs or throw an exception with TTL"
}

پیکربندی/OPA - SoD

rego package policy. sod

deny[msg] {
input. env == "prod"
input. pr. author == input. pr. merger msg: = "SoD: PR author cannot hold in prod."
}

SQL (DWH) - چه کسی بحرانی بودن هشدارها را در یک ماه کاهش داد

sql
SELECT actor, COUNT() AS cnt
FROM audit_events
WHERE action = 'ALERT_SEVERITY_CHANGED'
AND old_value = 'P1' AND new_value IN ('P2','P3')
AND ts >= date_trunc('month', now())
GROUP BY 1
ORDER BY cnt DESC;

نمونه پیام Git commit (زمینه های مورد نیاز)

feat(config/payments): raise PSP_B timeout to 800ms in EU

RFC: OPS-3421
Risk: Medium (PSP_B only, EU region)
Backout: revert PR + restore timeout=500ms
Tests: schema ok, conftest ok, e2e ok

11) نظارت و هشدار

تشخیص رانش: پیکربندی در یک خوشه ≠ Git → سیگنال P1/P2 + اصلاح خودکار (آشتی).
تغییر در معرض خطر: تغییر شبکه ها/اسرار/سیاست ها - اطلاع رسانی در # عملیات امنیتی.
شواهد گمشده: استقرار بدون برنامه/امضا/گزارش - بلوک یا هشدار.

دارایی های منقضی شده: دوره اعتبار گواهی/کلید → هشدارهای فعال

12) معیارها و KPI ها

پوشش حسابرسی٪ - سهم پیکربندی ها تحت طرح ها/سیاست ها/اسکنرها.
Drift MTTR میانگین زمان پاکسازی رانش است.
پیروی از سیاست٪ - سیاست ها را به روابط عمومی منتقل کنید.
اسرار نشت MTTR - از نشت به یادآوری/چرخش.
نرخ برگشت - نسبت برگشت تغییرات پیکربندی.
Mean Change Size - تفاوت میانگین در خطوط/منابع (کمتر بهتر است).

13) گزارش و انطباق

آثار حسابرسی: ذخیره سازی ≥ 1-3 سال (با توجه به الزامات)، ذخیره سازی غیر قابل تغییر.
تنظیم کننده: ISO 27001/27701، SOX مانند SoD، GDPR (PII)، الزامات صنعت (iGaming: حسابداری برای تغییرات در محاسبات GGR/NGR، محدودیت ها، قوانین پاداش).
گزارش های ماهانه: تغییرات بالا، نقض سیاست، رانش، گواهینامه های منقضی، وضعیت چرخش.

14) کتاب های بازی

A. رانش در تحریک شناسایی شده است

1. بلوک خودکار سپرده برای خدمات آسیب دیده.
2. حذف تصویر لحظهای از وضعیت جاری.
3. مقایسه با Git، شروع «آشتی» یا عقب نشینی.
4. ایجاد P2 حادثه، مشخص کردن منبع رانش (kubectl دستی/کنسول).
5. فعال کردن حفاظت: بدون تغییر مستقیم (PSP/ABAC)، صاحبان اطلاع.

B. گواهی PSP منقضی شده است

1. سوئیچ به مسیر پشتیبان/PSP، کاهش زمان خروج/ردیابی.
2. یک گواهی جدید را از طریق فرآیند PKI صادر کنید، پیکربندی را از طریق Git به روز کنید.
3. تست دود، ترافيک برگشت، بستن حادثه، بعد از مرگ.

C. مخفی ضربه روابط عمومی

1. کلید/نشانه را لغو کنید، از چرخش استفاده کنید.
2. بازنویسی تاریخ/حذف مصنوعات از انبارها، صدور RCA.
3. اضافه کردن یک قانون به اسکنر مخفی، آموزش فرمان.

15) ضد الگوهای

ویرایش دستی «در فروش» بدون ردیابی و برگشت.
پیکربندی بدون طرح و بدون اعتبارسنجی.
اسرار در متغیرهای Git/CI بدون KMS/Vault.
Monorepos با معادل «جهانی فوق العاده راست».
GitOps «ناشنوا» بدون هشدار رانش و سیاهههای مربوط به برنامه.
PR های بزرگ «همه در یک زمان» - تخصیص نامشخص و خطر بالا.

16) چک لیست

قبل از ادغام

• نمودار و خطوط گذشت
• سیاست های OPA/Conftest سبز هستند
• راز اسکن - «تمیز»
• طرح/تفاوت متصل شده، خطر ارزیابی، عقب نشینی آماده
• 2 آوریل (prod) و SoD ملاقات کردند

قبل از استقرار

• پنجره انتشار و تقویم بررسی شده است
• نظارت بر رانش فعال است
• SLO gardrails پیکربندی شده، آزمایش دود آماده است

ماهانه

• چرخش کلیدها/گواهینامه ها در برنامه
• فهرست صاحبان و حقوق
• OPA/خروج قوانین نقد و بررسی (TTL)
• آزمون آتش سوزی

17) نکات طراحی

تغییرات را به قطعات کوچک تقسیم کنید. روابط عمومی یک هدف است.
قالب های اجباری PR/commit با RFC/risk/rollback.
برای تنظیمات پویا، از «مراکز پیکربندی» با ممیزی و بازپرداخت استفاده کنید.

مدارهای نسخه سازی ؛ ممنوعیت شکستن بدون مهاجرت

تجسم «نقشه پیکربندی»: چه، کجا، چه کسی کنترل می شود.

18) ادغام با تغییر و مدیریت حوادث

PR ↔ RFC ↔ انتشار تقویم ↔ حوادث/پس از مرگ.
معیارهای خودکار کراوات (SLO/کسب و کار) برای پیکربندی انتشار.
خودکار ایجاد وظایف برای حذف پرچم های قدیمی/استثنا (TTL).

19) خط پایین

تنظیمات حسابرسی «گزارش کاغذی» نیست، بلکه یک مکانیزم قابلیت اطمینان عملیاتی است: پیکربندی ها داده ها هستند، تغییرات کنترل و قابل تایید هستند، اسرار تحت قفل و کلید هستند، و کل داستان شفاف و قابل تایید است. این است که چگونه یک پلت فرم پایدار، سازگار و قابل پیش بینی ساخته شده است.