1ProNAS1ProNAS Trust Centre
SecurityContact
SECURITY

1ProNAS Security Architecture

Security is designed around private NAS connectivity, passwordless human access, tenant separation, signed connector commands and recoverable file operations.

Controlled-production policy draft dated 3 August 2026. Final legal review and jurisdiction-specific amendments are required before unrestricted paid commercial launch.

Identity and sessions

  • Six-digit email OTP codes are hashed, short-lived, single-use and attempt-limited.
  • Private arithmetic human verification and honeypot checks reduce automated abuse without Google CAPTCHA.
  • Browser sessions use random secrets stored only as hashes and delivered through Secure, HttpOnly, SameSite cookies.
  • Machine API keys are separate from human accounts and must never be used as portal passwords.
  • Axon, client and integrator roles are separated and enforced server-side as functionality is activated.

Infrastructure

  • PostgreSQL and Valkey are private container services without public host bindings.
  • Public traffic terminates through Apache and TLS; APIs are bound to localhost on the application host.
  • Application containers use read-only filesystems, dropped Linux capabilities and no-new-privileges controls.
  • Production readiness checks cover database, cache, signing key, TLS, storage, memory, backup and isolated restore.
  • Germany is planned as recovery infrastructure while Tokyo becomes the primary APAC production environment.

Connector safety

Connectors initiate outbound encrypted connections. NAS SMB, NFS, SSH and administration interfaces remain private. Each connector is bound to one tenant and device. Planned executable commands include tenant, connector, job, expiry, nonce, expected totals, policy version, dry-run requirement and Ed25519 signature.

File-lifecycle safety

The control plane does not blindly delete NAS files. The intended sequence is analyse, recommend, approve, archive, verify, grace period, dry run and reclaim. Protected paths, legal holds, changed source totals, invalid signatures, expired commands and replayed nonces must stop execution.

Billing security

Stripe Checkout is created server-side. Browser-submitted prices do not grant entitlements. Subscription changes are accepted only through signature-verified, idempotently recorded Stripe webhooks. Payment-card data is handled by Stripe and is not displayed to integrator staff.

Reporting a concern

Use the secure contact form and select Technical support. Do not include live secrets or sensitive file contents. Include the time, affected tenant, request ID and a non-sensitive description. Critical production procedures will be added to the incident-response runbook before unrestricted launch.