# مرحله ۱۲ — امنیت و انطباق مالی: خلاصه

## ۱۲.۲ Audit Trail — مستقل از Ledger
جدول جدید `audit_trail` (append-only، با همون تریگرهای محافظ مرحله ۲) — **جدا از Ledger مالی**: Ledger می‌گه «چقدر پول جابه‌جا شد»، Audit Trail می‌گه **«چه کسی چه کاری کرد»** (تایید واریز، رد برداشت، تغییر تنظیمات). الان به این عملیات‌ها وصله:
- تایید/رد واریز کیف‌پول
- تایید (هر دو مرحله‌ی Dual Approval)/رد برداشت
- پیشنهاد و تایید نهایی تغییر سقف برداشت
- **حتی خودِ مشاهده‌ی Audit Trail توسط ادمین هم به‌عنوان یه رکورد جدید ثبت می‌شه** (دقیقاً طبق تاکید صریح چک‌لیست) — صفحه‌ی جدید پنل ادمین «📜 Audit Trail».

## ۱۲.۳ ضدتقلب و سقف برداشت
- **سقف روزانه/ماهانه‌ی برداشت** (پیش‌فرض ۲۰ و ۱۰۰ میلیون تومان، قابل تغییر) — داخل همون تراکنش Atomic چک می‌شه، نه جدا.
- **پرچم‌گذاری الگوی مشکوک** (نه رد خودکار — دقیقاً طبق متن چک‌لیست «برای بررسی دستی پرچم‌گذاری بشن»): وقتی درخواست برداشت ثبت می‌شه، دو الگو چک می‌شه:
  1. ۳ درخواست برداشت یا بیشتر در ۲۴ ساعت اخیر.
  2. واریز تاییدشده‌ی کمتر از ۲ ساعت پیش + هیچ معامله‌ای ثبت نشده از اون موقع + همین الان درخواست برداشت.
  اگه هرکدوم پیش بیاد، یه پیام جدا و مشخص (🚩) فقط به ادمین‌های ارشد می‌ره، جدا از پیام عادی تایید/رد.

## ۱۲.۴ سطوح دسترسی ادمین + تایید دوگانه‌ی تنظیمات حساس
- `ADMIN_PERMISSIONS` جدید: هر ادمین می‌تونه `deposits`، `withdrawals`، `senior` (هرکدوم رو) داشته باشه یا نه. پیش‌فرض هر دو ادمین همه‌چیز دارن (رفتار قبلی حفظ شد) — اگه می‌خواید محدودشون کنید، فقط همین آرایه رو عوض کنید.
- اگه یه ادمین بدون مجوز `withdrawals` بخواد برداشتی رو تایید کنه، پیام روشن «⛔ دسترسی ندارید» می‌گیره (نه این‌که بی‌صدا کار نکنه).
- **نمونه‌ی واقعی «تغییر تنظیمات حساس نیاز به دو تایید داره»**: تغییر سقف روزانه‌ی برداشت. یه ادمین ارشد پیشنهاد می‌ده، باید یه ادمین ارشد **دیگه** (نه همون اولی) از پنل ادمین تاییدش کنه تا واقعاً اعمال بشه. این الگو رو اگه بخواید می‌تونیم برای بقیه‌ی تنظیمات حساس (مثل آستانه‌ی Dual Approval خودِ برداشت) هم تکرار کنیم — الان فقط برای سقف برداشت پیاده شد به‌عنوان نمونه‌ی کامل و واقعی.

## ۱۲.۵ محدودسازی دسترسی + بکاپ رمزنگاری‌شده
- **بکاپ رمزنگاری‌شده**: `backup-financial-db.sh` الان با AES-256 (از طریق `openssl`) بکاپ رو رمزنگاری می‌کنه؛ فایل خام رمزنگاری‌نشده با `shred` واقعاً از دیسک پاک می‌شه (نه فقط `rm`). رمز عبور رمزنگاری (`BACKUP_ENCRYPTION_PASSPHRASE`) باید کاملاً جدا از رمز دیتابیس نگه داشته بشه.
- **محدودسازی IP روی MySQL**: این یه تنظیمات سطح سرور/دیتابیسه، نه چیزی که از داخل کد PHP قابل‌اعمال باشه. دستورالعمل:
  ```sql
  -- به‌جای GRANT ... TO 'user'@'%'، فقط از IP سرور خودتون اجازه بدید:
  CREATE USER 'traderpro_fin'@'IP_سرور_شما' IDENTIFIED BY 'رمز_قوی';
  GRANT ALL PRIVILEGES ON traderpro_financial.* TO 'traderpro_fin'@'IP_سرور_شما';
  FLUSH PRIVILEGES;
  ```
  و در `/etc/mysql/mysql.conf.d/mysqld.cnf`، `bind-address` رو به `127.0.0.1` بذارید (اگه MySQL و ربات روی همون سرورن) تا از بیرون اصلاً قابل‌دسترسی نباشه.

## ⚠️ ۱۲.۱ — این یکی کاملاً روی عهده‌ی شماست
«جداسازی حساب عملیاتی کسب‌وکار از پولی که متعلق به کاربرهاست» یه **تصمیم و اقدام بانکی واقعیه**، نه چیزی که کد بتونه انجامش بده. پیشنهاد عملی: یه حساب بانکی/کیف‌پول جدا فقط برای پول کاربرها باز کنید (کارت واریز فعلی که الان توی کد هست دقیقاً همون کارتیه که برای برداشت‌ها هم پرداخت انجام می‌شه — مطمئن بشید این حساب، حساب شخصی/عملیاتی روزمره‌تون نیست).

## وضعیت چک‌لیست
- [x] Audit Trail مستقل از Ledger، شامل مشاهده‌ی خودش.
- [x] الگوهای مشکوک پرچم‌گذاری می‌شن (نه رد خودکار).
- [x] سطوح دسترسی ادمین واقعاً اعمال می‌شه (نه فقط تزئینی).
- [x] تغییر سقف برداشت نیاز به دو ادمین ارشدِ متفاوت داره.
- [x] بکاپ رمزنگاری‌شده.
- [ ] محدودسازی IP روی MySQL — دستورالعملش داده شد، اجراش روی خود سرور با شماست.
- [ ] ۱۲.۱ (جداسازی حساب) — تصمیم/اقدام بانکی، روی عهده‌ی شماست.

## فایل‌های تحویلی
- `traderpro.php` — به‌روزرسانی‌شده.
- `backup-financial-db.sh` — با رمزنگاری AES-256.
- `.env` / `.env.example` — با `BACKUP_ENCRYPTION_PASSPHRASE` جدید.