Documentation
Security
Ensuring the security of your project and data is one of our top concerns, so we follow a set of internal guidelines based on ISO27001 to help ensure we're on the right side of secure. The following is a high level overview of our security principles and some technical info on how it's implemented.
Physical Security #
Servd is a software platform which utilises physical servers provided by both Digital Ocean, Civo, Wasabi and Backblaze. These companies and the data centres within which they operate are responsible for the physical security of the servers under their management. All companies use fully SOC-2 compliant physical access procedures including biometric and segmented access restrictions.
You can read more this on their respective sites:
Project Data at Rest #
All project database data and backups are stored encrypted by default, ensuring that direct access to data at rest is protected from 3rd parties. Encryption is provided by the underlying storage service providers, Digital Ocean, Civo, Wasabi and Backblaze, and make use of industry standard encryption algorithms to ensure transparent storage and retrieval of encrypted data.
Accounts and Access #
Servd's internal accounts are provisioned on a per user basis following a minimum-viable-permissions philosophy. This also applies to any inter-service communication in which access scopes are tailored to the application using them.
Credentials require a minimum level of entropy and are signed by administrators private keys where applicable. Access to individual platform components is limited on a per user basis to only the functions each user is authorised to perform. Credential revocation can be performed by internal administrators in the event of a suspected leak.
Access to critical system components is monitored by intrusion detection mechanisms which are able to alert administrators of suspicious activity in real-time, ensuring unauthorised access can be dealt with quickly.
Updates and Security Patches #
We try to keep our platform software as up-to-date as possible, however there are occasions where breaking changes prevent us from applying new software releases quickly. In these circumstances we ensure that critical security patches are applied within at least 1 month of their release and within a designated platform maintenance window if we believe they might incur any end-user downtime.
Security patches for individual PHP / Craft projects hosted on the platform are made available for inclusion in your bundles as soon as possible, however we do not automatically apply updates to PHP and Craft - instead they are automatically included in your new bundles. This ensures you always have easy access to the latest vulnerability patches (just build a new bundle), but we don't risk breaking your project by auto-applying breaking changes. It's important that you check regularly for available updates for your projects - we'll also send out global emails for critical security issues to keep you informed.
Firewalls and Traffic #
New Projects using Servd's Ingress Platform
All new projects on Servd use our New Ingress Platform by default. This utilises Cloudflare as a CDN which sits in front of Servd's servers. Within the Cloudflare network we employ Enterprise level automated DDoS protection, a custom configured WAF and dynamic traffic routing features to keep projects secure and performant.
Servd's origin servers do not accept any HTTP/S traffic directly for these projects, ensuring any attacks can be mitigated easily before they are forwarded to Servd's own infrastructure.
Traffic moving between Cloudflare and Servd is transported via post-quantum encrypted, reverse tunnels - ensuring that MITM attacks are not possible and traffic security is maintained throughout its journey.
Older projects using our legacy setup
The legacy Servd platform receives HTTP traffic directly on two specific ports:
- HTTP: Port 80
- HTTPS: Port 443
Traffic arriving on these ports is handled by two layers of load balancing services which apply any required access controls or WAF rules before being forwarded to individual projects.
Other Functionality
In addition to HTTP/S traffic, the following two ports are used as part of day-to-day interaction with your projects:
- Database: Port 6033
- SSH: Port 2200
Both database and SSH traffic pass through at least one proxy service before arriving at your project's running instances. This allows us to manage the updates and security of these entrypoints as a whole for the platform, rather than individually per-project. It also ensures that access via these entrypoints can be centrally managed and deactivated on a per-project basis.
We encourage you to only activate database and SSH access as required and disable it after each use. To deactivate database access, disable the "Allow external database connections" option in the project's Access Control page. To deactivate SSH access to an environment, click the "End Active Sessions" button in the environment's Commands page (e.g https://app.servd.host/env/production/commands for production)
Database Access #
Database access is restricted to traffic originating from inside the platform VPC (your project's PHP instances and optionally the database connection proxy). Databases cannot be accessed directly from the internet.
All databases are provisioned with a single user per-database which has access to that database only. Every database user is protected by a unique auto-generated password which is only shared with your project's PHP instances.
Ephemeral Filesystems #
All Servd projects run on an ephemeral filesystem, ensuring any unexpected changes can be undone by simply redeploying your application. This has some significant security benefits as it prevents any attackers from being able to persist any changes they make - even if they leave behind scripts intended to re-install exploits if they are ever removed.
A redeploy on Servd resets your entire project filesystem to a known-safe state. You can read more about that here.
Network Segregation #
Servd runs as a multi-tenant platform, meaning we use some shared infrastructure components for multiple projects. In order to ensure that projects within the platform are not able to communicate directly with each other, we implement strict network segregation between project components. This ensures that even though two projects might be running side-by-side within the Servd platform, any traffic they send to one another has to exit the platform and re-enter via the internet-facing load balancers - applying all of the same rules and restrictions that that entails. Traffic sent directly from one project to another via the use of the VPC's internal address space is simply dropped.
Staff Access #
Servd's staff have access to client projects to help with debugging and problem remediation. However we will always ask permission before accessing any database data. Project data will not be copied to any other location during these activities.
Servd's staff employ secure access to both internal and any third party services that we use. This includes the use of strong passwords, password management and MFA as a blanket policy. Access to our own infrastructure is managed via public/private key pair signed certificates whose access credentials are confirmed and maintained by system administrators. All certificates are revokable and have a limited lifespan.