Payment Orchestrator

Тема

11.04 Audit, Security And Privacy Data Requirements ​

Статус: черновик для обсуждения

1. Назначение документа ​

Этот документ описывает product-level data requirements для audit, security and privacy events.

Это не database schema.

Development team должна определить:

  • physical storage;
  • indexes;
  • event schema;
  • auth/security log separation;
  • retention implementation;
  • search/export implementation;
  • access control.

Product requirement: system must provide immutable, searchable, permission-safe audit/security history.

2. Audit/security events to store ​

Система должна хранить audit/security events для всех важных user/system actions.

Минимально нужно хранить:

  • login success;
  • failed login attempts;
  • logout;
  • session created;
  • session terminated by owner;
  • session terminated by platform admin;
  • sessions terminated automatically after user disabled/deleted;
  • password reset requested;
  • password reset completed;
  • 2FA setup completed;
  • 2FA reset requested;
  • 2FA reset completed;
  • 2FA failed attempts;
  • invite created;
  • invite resent;
  • invite accepted;
  • invite expired;
  • invite rejected because email already exists;
  • user merchant access added;
  • user merchant access removed;
  • user merchant role changed;
  • user merchant group access added;
  • user merchant group access removed;
  • user merchant group role changed;
  • role assigned;
  • role removed;
  • role permission changed;
  • provider access granted to merchant;
  • provider access revoked from merchant;
  • API key created;
  • API key rotated;
  • API key revoked;
  • transaction correction;
  • manual webhook resend;
  • configuration changes;
  • routing changes;
  • velocity changes;
  • FX/fee changes.

3. Actor data ​

Audit/security event должен хранить actor information.

Минимально:

  • actor user ID;
  • actor email;
  • actor user type;
  • actor role/context, if available;
  • source;
  • action;
  • timestamp.

Для Back Office user actions нужно хранить:

  • actor IP;
  • actor user agent.

Для login/security events нужно хранить:

  • actor IP;
  • actor user agent;
  • device/browser metadata, if available;
  • success/failure result;
  • failure reason, if safe to store.

4. Entity/context data ​

Audit event должен хранить target entity/context.

Минимально:

  • entity type;
  • entity ID;
  • entity display name, if available;
  • action type;
  • changed fields;
  • reason/comment, if provided.

merchantId, brandId, merchantGroupId are not mandatory base fields for every audit event.

Context can be derived from:

  • entity type;
  • entity ID;
  • entity relations.

Reason: not every entity belongs to merchant/brand/merchant group.

5. Old/new values ​

Audit log должен хранить old/new values for non-secret field changes.

Examples:

  • status changed from ACTIVE to INACTIVE;
  • role name changed;
  • permission added/removed;
  • routing rule condition changed;
  • velocity limit changed;
  • fee value changed;
  • webhook URL changed;
  • user access context changed.

Old/new values are required for:

  • investigation;
  • accountability;
  • support;
  • rollback planning;
  • understanding configuration changes.

6. Secret values ​

Secret values must not be stored in audit/security logs.

Confirmed rule:

text
For secrets, store only the fact that the field changed.
Do not store old value.
Do not store new value.
Do not store masked value.
Do not store encrypted value in audit log.

Examples of secret values:

  • API key secret;
  • provider credentials;
  • provider secret keys;
  • passwords;
  • password reset codes;
  • 2FA secrets;
  • invite tokens;
  • session tokens;
  • webhook signing secrets;
  • private keys.

Audit event can show:

text
field: providerSecretKey
change: updated

7. Visibility ​

Merchant user should see audit events only in accessible merchant contexts.

Merchant visibility depends on:

  • permissions;
  • merchant access;
  • merchant group access;
  • entity visibility;
  • provider access;
  • secret data rules.

Merchant user must not see:

  • platform-hidden provider internals;
  • secret values;
  • hidden SUB MID / SUB MID AGGREGATOR internals;
  • raw provider credentials/config;
  • audit events outside accessible merchant context.

Platform user with permission should see global audit/security logs.

Platform user still must not see actual secret values.

8. Export ​

Audit log export is required in MVP.

Export must respect:

  • permissions;
  • visibility rules;
  • merchant/merchant group access;
  • secret data rules.

Secret values must never be exported.

Merchant user can export only audit events available to that user.

Platform user with permission can export global audit/security logs according to access scope.

9. Retention ​

Audit/security logs must be retained indefinitely.

Product requirement:

text
Audit/security events are retained indefinitely / always.

Reason:

  • financial system investigation;
  • access/accountability;
  • operational disputes;
  • historical configuration analysis;
  • security incident investigation.

If future legal/security/compliance constraints require different retention, security/legal team must propose it.

10. Immutability ​

Audit/security events must be immutable.

Users cannot:

  • edit audit event;
  • delete audit event;
  • rewrite audit event;
  • change old/new values.

If a previous action was wrong, system creates a new correction/action event.

11. Audit log vs security log ​

Product does not require audit log and security log to be the same physical storage.

Development team can choose:

  • one shared audit/security event store;
  • separate audit log and security log;
  • hybrid model.

Product requirement:

  • platform users with permission can investigate security/auth events;
  • merchant users with permission can see relevant merchant-context audit events;
  • search/export/visibility rules work.

12. Privacy constraints ​

Audit/security logs can contain sensitive personal/technical data:

  • actor IP;
  • user agent;
  • email;
  • access context;
  • failed login metadata.

Visibility must be permission-based.

Sensitive non-secret data can be stored if needed for investigation.

Secrets must not be stored.

13. Acceptance Criteria ​

Audit / Security / Privacy Data Requirements считаются согласованными для MVP, если:

  • Login success events are stored.
  • Failed login attempts are stored.
  • Logout events are stored.
  • Session created/terminated events are stored.
  • Password reset requested/completed events are stored.
  • 2FA setup/reset/failed attempts are stored.
  • Invite created/resent/accepted/expired events are stored.
  • User role/access changes are stored.
  • Provider access grant/revoke events are stored.
  • API key created/rotated/revoked events are stored.
  • Actor IP/user agent are stored for Back Office user actions.
  • Actor IP/user agent are stored for login/security events.
  • Old/new values are stored for non-secret field changes.
  • Secret old/new values are not stored.
  • Only fact of secret field change is stored.
  • Audit/security logs are retained indefinitely.
  • Merchant user sees audit events only by accessible merchant contexts.
  • Platform user with permission sees global audit/security logs.
  • Audit log export is included in MVP.

14. Open Questions ​

Product open questions отсутствуют.

Technical/security/legal follow-up:

  1. Development team должна определить physical model: audit log, security log or shared event store.
  2. Development team должна определить search/indexing strategy.
  3. Development team должна определить export format.
  4. Security/legal team должна validate indefinite retention.
  5. Development team должна определить exact actor/device metadata fields.