# Security and Operations Notes

## Security boundary

Only the `public/` directory is web-accessible. The office is invitation-only, and operational routes require all three checks: authenticated session, active account, and confirmed TOTP. Permissions are checked server-side; hiding a navigation item is never treated as authorization.

## Secrets

- Keep `.env`, `APP_KEY`, database credentials, SMTP credentials, and `ZUMAX_IP_HASH_KEY` outside source control and backups encrypted.
- Never rotate `APP_KEY` casually. It encrypts TOTP secrets and recovery codes.
- Never pass passwords as Artisan options. Use the interactive Owner command.
- Do not put client messages, passwords, tokens, or recovery codes in application logs.

## Activity records

`activity_logs` is append-only through the application model. It records a short action name, actor, timestamp, severity, request ID, user-agent summary, optional subject, safe changes, and a keyed hash of the source IP. The durable activity trail therefore does not retain the raw address. Laravel's short-lived database session record and the host's standard web access log may contain a raw IP for security operations; document and enforce their separate retention periods. Database administrators can still alter records directly, so restrict database credentials and include exports in tamper-evident backup procedures.

## Sessions and transport

Production and staging must use HTTPS. The example environment encrypts database-backed sessions, marks cookies secure, uses HTTP-only cookies through Laravel defaults, and sets a one-hour session lifetime. Office responses are `no-store` and receive clickjacking, MIME-sniffing, referrer, permissions, and content-security headers.

## Account recovery

Password resets use the authenticated `no-reply@zumaxenterprises.com` SMTP identity. Business enquiries continue through `info@`; existing-client support uses `support@`. Recovery codes must be kept in a password manager or an encrypted offline record. The Owner should document a business-controlled recovery path that does not depend on one device or one person.

## Incident first response

1. Preserve logs, activity exports, timestamps, and request IDs.
2. Disable the affected account instead of deleting it.
3. Revoke sessions, reset the password, regenerate recovery codes, and re-enrol TOTP as appropriate.
4. Rotate only the credentials implicated by evidence; understand the impact before rotating `APP_KEY`.
5. Restore from a known-good backup if integrity is uncertain.
6. Record decisions and follow-up actions outside the affected system.

Report security concerns privately to `support@zumaxenterprises.com`; do not include passwords or active tokens in the report.