Hotel Data Security and Backups
Hotel data security built into the database: row-level isolation, an encrypted key vault, separate sessions per app and a backup before every change.
Your data is protected at every layer, from the database to the server it runs on.
In the database
- Every property's data is walled off by a policy applied on each query, which the app itself cannot bypass.
- Channel and payment gateway keys sit in a vault the application cannot read.
- The few functions that work across accounts are named, and refuse anyone except the platform.
When you sign in
Your PMS, POS, CRM and central reservations each live on a separate host with a separate session, so logging into one does not log you into the others. Everything uses TLS on one certificate that renews itself.
On the server
- fail2ban protects SSH, with bans that grow longer
- Deploys use a key, never a password
- The application listens only locally, behind nginx
- Nothing executable runs on the static sites
Before any change goes live
The database is dumped and the backup kept next to the change's number. Every change, with its tests, is first tried in a transaction that is then undone, and only afterwards applied for real.
What the tests prove
Close to two hundred test files run and roll back. Several sign in as the application and try to read another hotel's data, open the vault or act as the platform, and the build fails if any of that works.
