Our security policy covers the following elements

  • protection of the main server
  • protection of data stored on the server
  • outsourcing
  • backup management
  • disaster recovery plan management


All our servers are hosted by OVH. The main server is in Limburg (Frankfurt-Germany) and the backup server in Gravelines (France).

The servers are protected by a firewall, and each component of the infrastructure is equipped with :

  • Iptable (firewall rules)
  • Fail2ban (management of intrusion attempts)

OVH servers are protected by their own tools, including aOVH self-developed anti-DDOS system.

In addition, the installations include a series of security-related customs:

  • Procedural deployments, including only open source services.
  • The origin of services is verified on strictly official repositories maintained by the publishers (e.g. php >
  • Weekly security patch deployment + CERT-FR and Debian Security checks
  • OVH manager accessible by user, strong password (changed every two months) and Yubikey (nominative physical key)
  • Proxmox (virtualization manager) protected by user/strong password/IP filter on a cognix systems proxy, not accessible by customer
  • Root not accessible by client
  • Cognix root connection via bastion, accessible via user, strong password, yubikey
  • Custom sftp/SSH port
  • Default port closed to outside outside http/s
  • Each client application is managed via virtual host, in order to partition them to a dedicated directory and user with limited rights (to its own directory).
  • Noexec (blocks script/application execution on an unaffected partition)
  • Permanent hardening procedure: we do not install components that are not useful for technical management, operational maintenance or hosted applications.
  • Logging on each environment and a specific logrotate for each.


Data stored on the server by users is systematically encrypted using the AES256 (Advanced Encryption Standard) symmetrical encryption method, one of the most advanced protocols available today.


> This includes :

  • hardware supervision
  • system supervision
  • application supervision
  • network supervision

> Backup management

> Disaster Recovery Plan (DRP) management

  • the DRP activation procedure
  • the method of activation of the DRP
  • the method for returning to production

These tasks are entrusted to COGNIX SYSTEMS in Rennes (Fr), siren 444 724 462 Rennes, which is a recognized operator in this field.


Server supervision outsourcing

As part of its facilities management mission, our partner Cognix permanently monitors the following elements

– Hardware supervision

  • Disk status (SATA / SAS / SSD / NVMe)

– System monitoring

  • Availability (ping /ssh)
  • Partition status (free space / user quota)
  • Free Inode Level
  • Load / CPU / RAM / SWAP level
  • Time drift
  • Server uptime
  • Status of the different internal processes

– Application Supervision

  • URL testing (Availability, Error code, Delay, Content)
  • Availability and status of installed applications such as Apache, Ngnix, Tomcat, Varnish, ElasticSearch, MySQL, PostgreSQL, FTP, Postfix, Qmail, etc.
  • Control of remote replication systems present on the server (Heatbeat / DRBD / GlusterFS / Ceph / MySQL / PostgreSQL /etc.)

– Network supervision

  • IPF interface and routing
  • Antispam IP penalty


Backup management

The backup of all environments is performed daily, in even and odd days, on two different servers, one of which must be located in another datacenter than your service.

In addition, the user database is backed up every 2 hours.


DRP management (Data Recovery Plan)

The DRP consists in setting up a policy to be followed in case of serious failure of the main machine (called “production”).
The DRP implies the use of one or several machines in different datacenters from the production one, allowing to prepare the environments and to receive the users’ data.

If a major failure occurs on the production server, the DRP server, which is synchronized with the production server, recovers the data present at the time of the last effective backup of the environments and databases concerned.

According to the events encountered, 1stKYC orders or not the activation of the DRP plan, which generates a data loss whose delta depends on the time of the failure / time of the last backup. At most 2 hours in our organization.

The restoration time of the environments depends essentially on the volume of data to be copied between the backup farm and the DRP server.

Procedure for triggering the DRP:

– Situation: any situation degrading the service whose duration is not estimated by the supplier, or, suggesting a blocking expressed in number of days, such as

  • Fire
  • Water damage
  • Complete loss of network
  • Major failure of a datacenter

– Alert process: information of the situation by ticket, which can lead to a call with the project
with project manager, management and decision makers in order to apply the DRP modalities.

– Activation: by order of 1stKYC

Activation method:

– Copy of files & configurations from backup servers to the DRP server (estimate 2 to 3 hours)
– Manual import of the database from the backup servers to the PRA server
– Information ticket to inform that the DRP is finalized
– Modification of the DNS on the domain concerned in order to target the IP of the DRP

Method of return to production :

– Putting the production server into maintenance
– Copy of files from PRA to the production server (estimated 2 to 3 hours)
– Manual import of the database from PRA to the production server
– Ticket informing of the switchover of elements on the production server
– Modification of the DNS on the domain concerned in order to target the IP of the production server

Print Friendly, PDF & Email