Skip to content

# 26 — Security Audit Checklist (MicroDAO)

Безпека інфраструктури, сервісів, вебклієнта, агентів, Embassy, access keys, токенів та даних

Це документ для регулярного безпекового аудитування платформи DAARION.city / microDAO / Embassy / Agent Mesh / Wallet / RWA.

Він структурований так, щоб аудитори, інженери, DevOps та SecOps могли пройтися checklist-пунктами і чітко виявити проблеми в:

- Auth / Identity;
- Access Keys & Capability System;
- RBAC/Entitlements;
- Е2Е шифруванні повідомлень;
- Низькорівневій безпеці API, web, deployment;
- Embassy / Webhooks / Oracle-потоках;
- Wallet / Chain / Payouts;
- RWA flows;
- DB Security;
- Secrets Management;
- Logging/Audit/Compliance.

Документ повністю відповідає архітектурі, яку ми вже побудували.

## 1. Identity & Authentication

### 1.1 Users

- [ ] Email-based auth, OTP / Magic Link використовують одноразові токени.
- [ ] Термін дії OTP ≤ 10 хв.
- [ ] Повторне використання OTP заблоковано.
- [ ] Blocklist для підозрілих IP/UA-фінгерпринтів.
- [ ] MFA можлива (на roadmap).
- [ ] Session cookies:
- [ ] `HttpOnly`
- [ ] `Secure`
- [ ] `SameSite=Strict` для prod
- [ ] Session TTL визначений (24–72 год), auto-refresh без надмірного продовження.

### 1.2 Agents

- [ ] Приватні агенти НЕ використовують user-сесію.
- [ ] Кожен агент має свій Agent Access Key (`ak_*` з `subject_kind='agent'`).
- [ ] Немає можливості «перевтілюватися» в користувача.
- [ ] Rate limit для agent keys встановлений.

### 1.3 Integrations / Webhooks

- [ ] Інтеграції без JWT. Тільки API Key + HMAC.
- [ ] Embassy Webhooks:
- [ ] Secret зберігається в KMS.
- [ ] Підпис запиту перевіряється (`X-Signature`).
- [ ] Replay protection: timestamp + max time drift < 5 хв.

## 2. Authorization Layer (RBAC + Entitlements + Capabilities)

### 2.1 RBAC

- [ ] Ролі існують: `Owner`, `Guardian`, `Member`, `Visitor`.
- [ ] Роль користувача залежить від `team_members.role`.
- [ ] Немає прямого доступу до таблиць без RBAC-check.

### 2.2 Entitlements

- [ ] `plan.Freemium`, `plan.Casual`, `plan.Premium`, `plan.Platformium`.
- [ ] Плани визначають квоти на:
- agent runs;
- router.invoke;
- message sends;
- wallet.payout.claim;
- [ ] Стейк RINGK коректно впливає на квоти (множники).

### 2.3 Capability System

- [ ] Access Key має capabilities через:
- [ ] bundle.role.*
- [ ] bundle.plan.*
- [ ] bundle.agent.*
- [ ] власні capabilities (`access_key_caps`)
- [ ] Формула:

`text allow = RBAC ∧ Entitlement ∧ Capability ∧ ACL ∧ Mode`

- [ ] PDP працює централізовано.
- [ ] PEP на всіх API endpoints.

## 3. Access Keys (User, Agent, Integration, Embassy)

### 3.1 Зберігання

- [ ] Secrets у KMS (не в базі).
- [ ] У таблиці `access_keys` зберігаються тільки metadata.
- [ ] Секрет видається один раз → не зберігається у plaintext.

### 3.2 Політики

- [ ] TTL для ключів (default 30–90 днів).
- [ ] Mandatory rotation.
- [ ] Revoke → негайна інвалідація.
- [ ] `status` ∈ (`active`, `revoked`, `expired`).

### 3.3 Rate limiting

- [ ] Okta-like limit per key.
- [ ] DDOS запобігання (global rate limit + per-key).

## 4. Confidential Mode (E2EE-Like Messaging)

### 4.1 На рівні каналів/команд

- [ ] Якщо `teams.mode='confidential'`:
- [ ] сервер не бачить plaintext у `messages.body` (тільки ciphertext).
- [ ] агенти не отримують plaintext — тільки:
  - embeddings;
  - summary;
  - обмежені метадані.

### 4.2 Ключі шифрування

- [ ] Зберігаються виключно на клієнті.
- [ ] Rotate при:
- зміні складу команди;
- зміні owner/guardian;
- виході учасника.

### 4.3 E2EE Threat Model

- [ ] Сервер не може дешифрувати повідомлення.
- [ ] Агенти працюють на «вивітрених» даних (privacy-preserving).

## 5. API Security

### 5.1 Input validation

- [ ] Валідація payload (Zod/JSON schema).
- [ ] Неможливо запостити чужий team_id/channel_id/task_id.

### 5.2 Rate limiting

- [ ] per-IP
- [ ] per-user
- [ ] per-access-key
- [ ] per-endpoint (наприклад `/agent/run` має сильний ліміт)

### 5.3 Common

- [ ] CORS: origin whitelist
- [ ] TLS enforced
- [ ] Referrer policy: `strict-origin`
- [ ] Headers:
- [ ] `X-Frame-Options: DENY`

- [ ] `Content-Security-Policy` мінімум:

  `text default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src 'self' https:; img-src 'self' data: https:; frame-ancestors 'none';`

- [ ] Вимкнуто directory listing у CDN.

## 6. Web Client Security

### 6.1 Token handling

- [ ] Немає зберігання секретів у localStorage.
- [ ] Capability-token не містить чутливих даних.
- [ ] Cookies: secure, httponly, samesite.

### 6.2 UI-level attack surface

- [ ] XSS захищено (React escaping).
- [ ] Посилання user-generated content: `rel="noopener noreferrer"`.

### 6.3 Cache

- [ ] Disable caching of sensitive pages.

## 7. Database Security

### 7.1 Структура

- [ ] Всі таблиці пройдені аудитом (див. `27_database_schema_migrations.md`).
- [ ] Поля з критичними даними не мають plaintext секретів.

### 7.2 Обмеження

- [ ] CHECK / ENUM на:
- roles
- viewer_types
- message types
- task statuses
- wallet statuses
- access key statuses
- embassy platforms
- [ ] Foreign keys у всіх критичних зв'язках.

### 7.3 Політика доступу

- [ ] Web/API використовує RLS або server-side filters.
- [ ] Відсутня можливість запитів напряму «в сусідню команду».

### 7.4 Backup & Restore

- [ ] PITR 7–30 днів для prod.
- [ ] Snapshot перед кожним релізом.
- [ ] Процедура restore протестована.

## 8. Secrets Management

### 8.1 Джерело

- [ ] Prod/Staging secrets в KMS або Vault.
- [ ] Немає `.env` у repo.
- [ ] Локальні `.env` окремо від production.

### 8.2 Sensitive secrets

- Embassy secrets
- Wallet signer private key
- JWT secret
- Session secret
- RWA oracle secrets

### 8.3 Rotation

- [ ] Rotation policy існує.
- [ ] Auto-rotate для Embassy secrets мінімум раз на 30–60 днів.

## 9. Embassy Module & Webhooks Security

### 9.1 Inbound Webhooks

- [ ] Підпис перевіряється (`X-Signature`).
- [ ] Timestamp у тілі підпису.
- [ ] Maximum allowed skew < 5 хв.
- [ ] Body hashing (HMAC_SHA256).

### 9.2 Outbound Webhooks

- [ ] Retry з експоненційною затримкою.
- [ ] Dead-letter queue для NATS споживачів.

### 9.3 Oracle Input

- [ ] Oracle events проходять PDP capability-check:
- `embassy.energy.update`
- `embassy.rwa.claim`
- `embassy.intent.read`
- [ ] Oracle payload має структуру з валідацією (не приймати довільний json).

## 10. Wallet & Chain Security

### 10.1 Signer

- [ ] Wallet private key у KMS.
- [ ] Операції підпису — через офіційну KMS-операцію (не на сервері).
- [ ] Multi-sig або 4-eyes approval для критичних транзакцій.

### 10.2 Payouts

- [ ] `payout.generated` приходить лише з wallet service.
- [ ] claim → tx → підтвердження → оновлення БД.
- [ ] Rate limit на claim.

### 10.3 Chain RPC

- [ ] Використовувати приватні RPC endpoint-и.
- [ ] Логи RPC запитів не містять приватних ключів.

## 11. RWA Security

### 11.1 Data-level

- [ ] RWA inventory має типи:
- `energy`, `food`, `water`, `essence`, `generic`.
- [ ] Кожен update — подія `rwa.inventory.updated`.

### 11.2 Embassy-guarded actions

- [ ] тільки Embassy Keys з capability:
- `rwa.inventory.update`
- `embassy.rwa.claim`
- `embassy.energy.update`

## 12. Logging & Audit Trail

### 12.1 Audit Log

- [ ] Всі критичні дії пишуть у `audit_log`:
- access key created/revoked,
- agent run invoked,
- payout claimed,
- governance actions,
- embassy updates.

### 12.2 Log integrity

- [ ] Логи доступні тільки admin/ops.
- [ ] Немає plaintext секретів.

### 12.3 SIEM інтеграція

- [ ] Підтримується forwarding у ELK / Loki / Cloud Logging.

## 13. Monitoring & Alerting

### 13.1 Метрики

- API latency, error rate
- DB connections, slow queries
- NATS lag
- Agent run failures
- Embassy webhook failures
- Wallet TX errors

### 13.2 Алерти

- [ ] high latency
- [ ] high error rate (>2%)
- [ ] failed db migration
- [ ] stuck outbox events
- [ ] agent-run failure rate > заданого порогу
- [ ] "Embassy webhook signature mismatch"

## 14. Incident Response

### 14.1 Playbooks

- [ ] DB corruption
- [ ] Chain stuck / RPC unreachable
- [ ] Embassy compromised key
- [ ] Access key leak
- [ ] Agent runaway (infinite loop / high cost)
- [ ] DDOS attack
- [ ] RWA incorrect oracle input

### 14.2 Communication

- [ ] Responsible security officer визначено.
- [ ] Питання ескалації прописані.

## 15. Compliance

### 15.1 Privacy

- [ ] PII зберігається encrypted-at-rest.
- [ ] Резидентські дані обмежені на команди.
- [ ] E2EE для confidential-каналів гарантує приватність.

### 15.2 Data retention

- [ ] Логи зберігаються до 30–90 днів.
- [ ] Outbox events → 7 днів.

### 15.3 Legal

- [ ] Webhooks & Embassy: мінімізація PII.
- [ ] Wallet: відповідність нормам локальних регуляцій.

## 16. Summary: Security Audit Status Table

Категорія | Статус | Проблеми | Пріоритет
--- | --- | --- | ---
Identity/Auth | PASS / WARN / FAIL | … | High
Access Keys | PASS / WARN / FAIL | … | High
RBAC | PASS | … | Medium
Capabilities | PASS | … | High
E2EE | … | … | High
Embassy | … | … | High
Wallet | … | … | Critical
RWA | … | … | High
DB | … | … | High
Secrets | … | … | Critical
Logs | … | … | Medium

## 17. Завдання для Cursor

    You are a senior security engineer. Implement security measures based on:
    - 26_security_audit.md
    - 24_access_keys_capabilities_system.md
    - 25_deployment_infrastructure.md
    - 12_agent_runtime_core.md

    Tasks:
    1) Implement rate limiting middleware for API endpoints.
    2) Add input validation (Zod schemas) for all API endpoints.
    3) Implement security headers middleware (CSP, X-Frame-Options, etc.).
    4) Add audit logging for critical actions (access keys, payouts, governance).
    5) Implement secrets rotation policy.
    6) Add security monitoring alerts.

    Output:
    - list of modified files
    - diff
    - summary

## 18. Результат

Після проходження цього чеклисту:

- виявлені всі критичні вразливості безпеки;
- впроваджені best practices для всіх компонентів системи;
- готовність до production deployment з точки зору безпеки;
- чітка політика incident response та compliance.

Версія: 1.0 (для MVP → RC → PROD)
Останнє оновлення: 2024-11-14