This page is written for IT teams and anyone who has to evaluate the system before approving budget — we name the actual mechanisms in use, not marketing claims.
Every core data table is bound to a company, preventing data crossing between organizations — not just filtering in application code.
Naya PMS and KuiKeng add database Row-Level Security as a safety net — one property's or shop's data cannot be reached from another's context, even at the level of a database query.
If a property or shop is deactivated, every request is rejected immediately — there is no fallback.
Stored encrypted, and the UI never displays the real values back.
| Area | What is actually in place |
|---|---|
| Sign-in | JWT signed with an asymmetric key pair (RSA private/public key) plus a refresh token · Naya PMS uses a 1-day access token + a 7-day refresh token, with token rotation and revocation on sign-out. |
| Passwords | Hashed with the bcrypt standard; no password is ever stored in readable form · a password change is forced on first sign-in · forgot-password/reset runs over email with token verification. |
| Access permissions | Action-level RBAC with CASL — permissions are defined as {subject, action} pairs, e.g. employees = read/create/update/delete. |
| Roles | One user can hold several roles, and system-level roles are separate from company-specific roles · three user types: system admin / company admin / employee. |
| Permission enforcement | Enforced on both the front end and the API — hiding a menu is not enough; the server re-checks every time. |
| Permission changes | Take effect immediately, backed by a token revocation mechanism. |
An audit log of system usage with a screen for reviewing history.
Trace every request across the system, so you can pinpoint problems after the fact even when they pass through several microservices.
Cancelling a service ticket is a soft delete — nothing is lost and it stays auditable.
Every movement (top-up / deduct / refund / reset) with the balance after the entry, the reason, and the related ticket number.
Every event — created, checked out, returned, status changed, repair started/finished, damaged, lost, retired, disposed.
Every action with its comment, and a reason is required to reject.
HMAC-SHA256 is verified every time — forged messages that did not come from LINE are rejected.
And security headers are configured on the web server.
Restricts which domains can call the API · limits request rates to protect against flooding and abuse.
Switched off automatically in production environments, so the API structure cannot be explored from outside.
Files are stored on Cloudflare R2 / S3-compatible storage — scales without limit and does not consume application server disk.
We use the authentication the cloud provider manages for us, which reduces the risk of leaked keys.
When you stop using the service, the process always exports your data to you first.
Across the database, the search index and file storage — no copy is left behind in any one system.
Book a call directly with our technical team — we can answer on architecture, deployment and data isolation at a detailed level.