حسابرسی و سیاهههای مربوط تغییر ناپذیر

حسابرسی و سیاهههای مربوط تغییر ناپذیر

1) چرا شما به آن نیاز دارید

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

2) مدل تهدید و اهداف کنترل

• ویرایش/حذف عمدی رویدادها توسط یک خودی.
• جایگزینی زمان/منبع (replay/backdating).
• خاموش کردن ورود به سیستم «آرام» در گره.
• از دست دادن بخشی از ورود به سیستم در حوادث/مهاجرت.
• جمع آوری PII بیش از حد و اختلاف با حریم خصوصی.

1. یکپارچگی: اثبات شده توسط حفاظت در برابر تغییرات/حذف.

2. کامل بودن: بسته شدن جریان های کلیدی (صفحه کنترل، صفحه داده، دسترسی، پول).

3. دقت زمان: قابل تکرار، زمان هماهنگ.

4. قابلیت دسترسی: خواندن و جستجو در SLO.

5. حریم خصوصی: حداقل PII، نشانه گذاری/رمزگذاری، قانونی بودن استفاده.

3) اولویت های طبقه بندی و رویداد

• کنترل هواپیما: احراز هویت/مجوز، تغییرات پیکربندی، عملیات کلیدی (KMS)، مدیریت مخفی، تغییرات سیاست.
• هواپیما داده: دسترسی به اشیاء/سوابق/چک/پرداخت ؛ خواندن/ایجاد/حذف
• مدیر و DevOps: SSH/کنسول، CI/CD، تغییرات زیرساخت/IaC، تشدید حقوق.
• محصول: معاملات، صورتحساب، عملیات مشتری.
• سیستم/شبکه: هسته/عوامل/پروکسی/متعادل کننده ها، کارگزاران، پایگاه داده ها.
• امنیت: IDS/IPS/EDR، WAF، ضد DDoS، ضد انفجار، DLP.

برای هر کلاس، ما رفع: بحرانی، طرح، زمینه های اجباری، عمر مفید، الزامات برای تغییر ناپذیری.

4) زمینه ها و فرمت های مورد نیاز

شناسه های همبستگی عبارتند از «trace _ id»، «span _ id»، «request _ id»، «actor _ id» (کاربر/سرویس)، «tenant _ id»، «resource _ id».
زمینه A&A: روش احراز هویت، نقش/سیاست در زمان عمل.
زمان: RFC3339/UTC، میلی ثانیه/نانو ثانیه ؛ منبع هماهنگ سازی.
عمل و نتیجه: نوع عملیات، هدف، وضعیت، تعداد اشیاء آسیب دیده.
یکپارچگی: سوابق HMAC محلی، شماره توالی، hash-prev.
طرح: JSON با یک مدل پایدار (به عنوان مثال، سازگار با لغت نامه های رویداد مشترک).

ممنوع: اسرار، کلید، نشانه، PAN کامل، کلمه عبور، کلید خصوصی. PII - فقط در صورت لزوم، با ماسک کردن/نشانه گذاری.

5) زمان و هماهنگ سازی

منبع زمان: حداقل دو منبع مستقل (NTP/PTP) + نظارت بر تعصب.
امضای زمان بحرانی: از خدمات معتبر زمان (TSA) یا یک سرویس زمان بندی داخلی برای دسته بندی رویدادها استفاده کنید.
قوانین: هیچ منطقه زمانی محلی، فقط UTC ؛ ورود و جبران/کیفیت زمان.

6) معماری جریان ورودی

Agents → Buffer → Transport → Landing → Hash Chain/Signature → Cold/Archive → فهرست برای جستجو

مجموعه روی گره: عوامل نور (daemonset/sidecar) با یک بافر روی دیسک (فشار برگشتی).
حمل و نقل: کانال حفاظت شده (TLS/mTLS)، تحویل تضمین شده (حداقل یک بار)، idempotent-ingest.
منطقه فرود: ذخیره سازی شی در یک فرم «خام» (دسته های تاریخ/مستاجر/نوع).
فهرست: موتور جستجو/تجزیه و تحلیل برای نمایش داده های آنلاین (لایه داغ).
بایگانی (WORM): سطل های غیر قابل تغییر/نوار با سیاست های نگهداری و نگهداری قانونی.
لنگر/مهر و موم: دوره ای «آب بندی» بسته های زنجیره ای هش (پایین را ببینید).

7) تغییر ناپذیری رمزنگاری

7. 1 زنجیرهای هش (فقط پیوست)

هر ورودی شامل: 'hash _ curr = H (رکورد)'، 'hash _ prev' از ورودی قبلی، 'seq' است. هر ویرایشی زنجیره را میشکند.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 امضای بسته ها و تمبر زمان

هر N ثانیه/MB ما یک بلوک را تشکیل می دهیم: ریشه Merkle از همه «hash _ curr».
ما بلوک را با کلید حسابرسی امضا می کنیم (به طور پایدار در KMS/HSM ذخیره می شود).
یک برچسب زمانی TSA اضافه کنید و «Transparency Log» را منتشر کنید.
اختیاری: هش ریشه به صورت دوره ای به یک فضای قابل اثبات خارجی (به عنوان مثال، یک مجله مستقل یا ذخیره سازی غیر قابل تغییر عمومی) متصل می شود.

7. 3 مدیریت کلید حسابرسی

کلید های امضا - در KMS/HSM، چرخش در برنامه، دسترسی چند منظوره، کنترل دوگانه برای صادرات.
ابطال کلید → شعبه اعتماد جدید ؛ امضاهای قدیمی قابل بررسی هستند.

8) حفظ و سیاست های WORM

WORM/غیر قابل تغییر: شامل ظروف غیر قابل تغییر/سطل با سیاست حفظ و نگهداری قانونی برای کلاس های P0/P1.
نسخه بندی: فعال ؛ حذف - فقط برای روش با تاخیر (ممنوعیت پاکسازی فوری).
نگهداری: گرم (7-30 روز)، گرم (3-6 ماه)، سرد/بایگانی (1-7 سال یا بیشتر - بسته به تنظیم کننده/قرارداد).

چند اجاره: فضای نام/حساب/کلید رمزگذاری جداگانه برای هر مستاجر ؛ گزارش دسترسی ورود به سیستم

9) حفظ حریم خصوصی و به حداقل رساندن

جمع آوری با توجه به اصل ضرورت: ما ورود غیر ضروری نیست.
نشانه گذاری/pseudonymization از زمینه های حساس، هش نمک برای شناسه.
رمزگذاری فیلد سمت تولید کننده (AEAD) هنگامی که در ذخیره سازی شیء مشترک ذخیره می شود.
حق حذف (در صورت لزوم): از طریق رمزنگاری پاک کردن کلید های زمینه/بخش، بدون نقض تغییر ناپذیری ظرف (برنامه ریزی شده در طول طراحی) اجرا می شود.

10) دسترسی، نقش ها و حسابرسی خود حسابرسی

تقسیم: تولید کنندگان ≠ خوانندگان ≠ مدیران.
فقط خواندنی از WORM ؛ تغییر سیاست های حفظ - از طریق نقش های جداگانه و روش با تصویب.
تمام عملیات خواندن/صادرات به یک گزارش ثانویه (meta audit) وارد می شوند.
صادرات برای تحقیق/انطباق - به صورت رمزگذاری شده با یک دایرکتوری بلوک هش و یک زنجیره اعتماد.

11) قابلیت مشاهده و SLO

معیارها: میزان تزریق، تاخیر به شاخص،٪ از دست رفته/تکرار، کسری از زمان غیر همگام، خطاهای امضا/لنگر، پر کردن بافر.
SLO: ≥99. 9٪ از رویدادها ≤ X ثانیه به شاخص داغ تحویل داده می شود ؛ 0 «سوراخ» غیر قابل توضیح در توالی ؛ 100٪ از بلوک ها امضا شده و زمان مهر و موم شده است.
هشدارها: مکث تزریق> N دقیقه، رشد هش نامعتبر، واگرایی زنجیره ای، خرابی امضا/برچسب زمان، زمان جبران فراتر از آستانه.

12) تست و تایید

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

13) عملیات و روش ها

Runbook «بررسی یکپارچگی» (بر اساس تقاضا و برنامه ریزی).
روش برای برگزاری قانونی و موقت «انجماد» احزاب.
روش کشف و صادرات در حالی که حفظ زنجیره اعتماد.
برنامه ریزی برای چرخش کلیدهای حسابرسی و پاسخ به مصالحه (شعبه اعتماد جدید، امضای مجدد بلوک ها، اطلاعیه ها).

14) دستور العمل های کوچک

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• کنترل/داده هواپیما P0: روز گرم 30 → ماه گرم 6 → بایگانی 7 سال (WORM).
• DevOps: گرم 14 روز → گرم 3 ماه → بایگانی 1 سال.
• سیگنال های Securiti: 90 روز گرم (برای تحقیقات)، سپس 1-3 سال.

15) خطاهای مکرر

"سیاههها متن بدون طرح هستند. بدون یک طرح، هیچ یکپارچگی و جستجوی قطعی وجود ندارد ؛ JSON متعارف و فیلدهای ثابت مورد نیاز است.
هيچ ارتباطي وجود نداره فقدان «ردیابی _ id» تحقیقات را تجزیه می کند.
به وقت محلي. فقط UTC و کنترل افست.
به جلدهای قابل تغییر می نویسد. بدون WORM، هرگونه تغییرناپذیری یک افسانه است.
خواندن را فراموش نکنید. خواندن اطلاعات حساس برای رفع حداقل از نوشتن مهم است.
رازهایی در لاگها قبل از ارسال، «لیست قرمز» الگوها را روشن کنید.
یک کلید برای همه چیز کلید های امضا و رمزگذاری - به طور جداگانه، با یک نقش و چرخش.

16) انطباق و مقررات

مورد نیاز برای عمر مفید/غیر قابل تغییر بستگی به دامنه (امور مالی، پرداخت، مخابرات، و غیره).
قابلیت اثبات: در دسترس بودن پروتکل های WORM/retention، گزارش های اعتبار سنجی مدار، ورود به سیستم های دسترسی، نگهداری قانونی و روش های صادرات.

17) چک لیست

قبل از فروش

• طبقه بندی رویداد و طرح تایید شده (زمینه های مورد نیاز).
• عوامل، بافر، حمل و نقل محافظت شده، فشار برگشتی پیکربندی شده است.
• شامل: زنجیره های هش، امضای بلوک، برچسب زمان، ورود به سیستم شفافیت.
• ذخیره سازی WORM/ارائه فعال است ؛ تست برای عدم توانایی بازنویسی/حذف.
• پوشش/نشانه گذاری زمینه های حساس.
• هماهنگ سازی زمان و نظارت افست.
• برنامه چرخش و ذخیره سازی کلید های حسابرسی در KMS/HSM.

عملیات اجرایی

• اعتبار سنجی هفتگی زنجیره ها و بلوک ها (+ گزارش).
• شکست مدار/خطا امضا/زمان هشدار افست.
• دوره آزمون جایگزینی/حذف تیم قرمز.
• بررسی منظم نظرات و هزینه ها.

18) سوالات متداول

س: آیا فقط «اضافه کردن» در سطح پایگاه داده کافی است ؟

اوه نه. ما به تضمین های رمزنگاری (زنجیره ای از هش ها، امضای بلوک، تمبر زمان) و سیاست های WORM نیاز داریم.

س: در مورد حق حذف داده ها چیست ؟

A: طراحی رمزنگاری پاک کردن (حذف کلید) برای زمینه ها/احزاب، نگه داشتن رسانه ها غیر قابل تغییر و سیاهههای مربوط قابل اثبات است.

س: آیا من نیاز به یک کلید جداگانه برای امضای بلوک ؟

اوه، آره. کلیدهای امضای بلوک را از کلیدهای رمزگذاری ذخیره سازی جدا کنید. فروشگاه در KMS/HSM، با چرخش و حسابرسی.

س: آیا ممکن است به «لنگر» به یک فضای عمومی ؟

A: اختیاری این قابلیت اطمینان را افزایش می دهد و «بازنویسی تاریخ» را در مدار قطع می کند.

• «رمزگذاری در حالت استراحت»
• «در رمزگذاری حمل و نقل»
• «مدیریت مخفی»
• «مدیریت کلید و چرخش»
• «ثبت و بررسی درخواستها»