Security
An overview of niyase's security design, including encryption, access control, audit logs, and tenant isolation.
Design Philosophy
niyase provides the same level of security regardless of scale. We do not build "cheap plans with weaker security." We operate at the level of audit standards such as SOC 2 Type II, and certification is in preparation.
Data Encryption
| Location | Encryption |
|---|---|
| Desktop DB | SQLite encryption (OS keyring integration) |
| Mobile DB | SQLCipher (expo-sqlite v16+) |
| Cloud DB | Column-level encryption (PII) + at-rest encryption |
| Backup files | Same encryption applied |
| Communication | TLS 1.3 |
Sensitive information (My Number, bank account numbers, etc.) is also encrypted at the application layer when stored.
Tenant Isolation
The cloud DB is separated into a Central DB / WS DB:
- Central DB: Shared information such as users, spaces (slim), and billing
- WS DB: The business data of each space (employees, attendance, payroll, accounting, etc.)
A WS DB cannot access another space's WS DB. We physically cut off data-leak paths.
In addition, Postgres RLS (Row Level Security) is applied to every table, providing a second layer so that even an application-layer bug cannot cause cross-tenant access. We further combine this with column-level masking based on permissions, so that when a role or permission changes, the rows and fields visible at the next sync are automatically narrowed.
Access Control
Roles within a space:
| Role | Permissions |
|---|---|
| OWNER | Full control of the space, billing, deletion |
| ADMIN | Member management, settings changes |
| MEMBER | General work |
| Custom roles per feature | Definable on the plugin side |
Transferring OWNER is always done through an explicit action.
Audit Logs
Every write operation is recorded in the audit log:
- Who (user_id, device)
- When (timestamp)
- Where (space, menu)
- What (table, record ID, before/after)
- From where (IP, User-Agent)
Audit logs are stored as WORM (Write Once Read Many) and cannot be altered after the fact.
Authentication
- Password + two-factor authentication (TOTP)
- Passkeys (recommended)
- Google login
- Session list + per-session log out
- Device ID + suspicious-login detection
We do not use PPAP (sending ZIP passwords separately).
Incident Response
If you discover a security issue, please contact us at security@niyase.com.