Server architecture
The services are designed in such a way that everything is segmented. That means: One service, one VPS and possibly your own physical machine.
A VPS always has lower privileges than a hypervisor. This means that when one VPS is compromised, it is not trivially possible to escalate rights to the guest and take control of other services.
All operating systems (OS) are kept up-to-date. No part goes as unsupported (EoL) distribution. The system team monitors the EoL of the system and reports it to the application team in time (typically 3/4 years in advance so preparations can take place).
Security updates are automatically applied to each OS. This applies to all VPS and hypervisors. Kernel updates and system boot tests are also performed regularly.
Each service is deployed according to the "least-privilege access" principle and standard "hardening" is applied to them. (For example, no application runs with higher rights than necessary, services have their own system users, and rights are limited only to activities that are needed for a given function.)
Configuration distribution is automated.
Network
Each element in the network has a restrictive firewall set up (packet filtering and traffic flow control):
- There is no DMZ (demilitarized zone) anywhere in the network. Everything is set up so that the internal network is treated as untrusted (zero-trust architecture).
- The same applies to VPS on only the hypervisor. If it is not needed, the VPS does not look at itself.
- An outbound firewall is deployed where it makes sense (eg DBs don't need to access the internet).
- All local services that are accessed locally are explicitly bound to localhost. So even if the firewall fails, the services will not be available outside anyway.
In general, only necessary access between individual elements is allowed in the LAN (i.e. only the part of the application that needs it can access the DB. Different DBs cannot see each other.)
(The internal network is physically segmented by the switch. That is, it is not possible to perform "VLAN hopping" attacks.)
Each hypervisor enforces source IP address filtering. I.e. anti-spoofing according to BCP 38 (RFC 2827) is implemented.
All servers are behind a large firewall that filters the flow from the Internet and possibly to the Internet if it makes sense for the service.
Only the ports required for communication with clients and for development are allowed out to the Internet. Everything else is closed.
Communication with clients is always handled via an encrypted channel (SSL/TLS, SSH/SFTP).
Backups
Backups are made of entire VPS, individual OS, application data and DB dumps. It lasts for 30 days.
They are encrypted "at rest" with a strong algorithm and data integrity is guaranteed. (In addition, a good cryptographic hash is used.)
File checksums are regularly checked and possibly file corruption is fixed.
Backups are resistant to deletion to some extent.
It always backs up via an encrypted tunnel, even locally on the LAN.
Monitoring
Each server has basic system monitoring deployed:
- CPU, RAM, NET, disk I/O, system load, ...
- Checking whether critical services are running and working (app, DB, fw, ...).
Deployed basic logging of anomalies in the system. This is not SIEM (Security information and event management), local logging and alerting are deployed!
Physical access to the DC is monitored.
Audit
Once a year, the system team audits the status of all servers and their security. He fixes any problems right away.
Systems team
The system team (hereinafter referred to as the team) manages all systems, keeps them up-to-date, helps debug and solve application problems, and monitors current threats. The team has long-term experience in OS security, defense against common attacks and incident resolution.
The team has excellent knowledge of the infrastructure and architecture of the DISIVO server.
The team is constantly being educated not only from the point of view of security and vulnerability of systems, but also of the general functioning of modern computer architecture.