Notre politique de sécurité regroupe les éléments suivants :
- la protection du serveur principal
- la protection des données stockées sur le serveur
- l’infogérance
- la gestion des sauvegardes
- la gestion du plan de reprise d’activité
PROTECTION DU SERVEUR PRINCIPAL
Tous nos serveurs sont hébergés chez OVH. Le serveur principal est à Limburg (Frankfurt-Allemagne) et le serveur de secours à Gravelines (France).
Les serveurs sont protégé par un firewall et sur chaque composant de l’infrastructure, a été mis en place :
- Iptable (règles de pare-feu)
- Fail2ban (gestion des tentatives d’intrusion)
Les serveurs OVH sont protégés sous couvert de leurs propres outils, notamment le système d’anti-DDOS développé par eux-même.
De plus, les installations comprennent une série de coutumes liées à la sécurité :
- Déploiements cadrés par procédures, comprenant uniquement des services open source.
- La provenance des services est vérifié sur des repository strictement officiels et maintenu par les éditeurs (exemple : php > php.net)
- Déploiement des mises à jour (patch de sécurité) hebdomadaire + vérification de CERT-FR ainsi que Debian Security
- Manager OVH accessible par user, mot de passe fort (changé tous les deux mois) et Yubikey (clé physique nominative)
- Proxmox (gestionnaire de virtualisation) protégé par user/mot de passe fort / filtre IP sur un proxy cognix systems, non accessible par le client
- Root non accessible par le client
- Connexion root par cognix passant pas bastion, accessible par user, mot de passe fort, yubikey
- Port sftp/SSH personnalisé
- Port fermé par défaut sur l’extérieur hors http/s
- Chaque applicatif client est géré via virtual host, afin de cloisonner ces derniers à un répertoire et un user dédié et droits limités (à son propre répertoire)
- Noexec (bloque l’exécution de script/application sur une partition non concernée)
- Procédure de hardening (durcissement) permanent, nous n’installation pas de composants non utile à la gestion technique, maintien opérationnel ou à l’applicatif hébergé
- Journalisation des logs sur chaque environnement et un logrotate spécifique pour chaque.
LA PROTECTION DES DONNÉES STOCKÉES SUR LE SERVEUR
Les données enregistrés sur le serveur par les utilisateurs sont systématiquement cryptées selon la méthode de chiffrement symétrique AES256 (Advanced Encryption Standard) qui est parmi les protocoles les plus avancés à ce jour.
L’INFOGERANCE
> la notion d’infogérance regroupe les points suivants :
- la supervision hardware
- la supervision système
- la supervision applicative
- la supervision réseau
> la gestion des sauvegardes
> la gestion DRP (en français, PRA = Plan de Reprise d’Activité)
- la procédure de déclenchement du PRA
- la méthode d’activation du PRA
- la méthode de retour en production
Les tâches d’infogérance et de gestion du PRA sont confiées à COGNIX SYSTEMS à Rennes (Fr), siren 444 724 462 Rennes qui est un opérateur reconnu en la matière.
*******************
Infogérance
Dans le cadre de sa mission d’infogérance, notre partenaire Cognix surveille en permanence les éléments suivants :
- Supervision Hardware
- Etat des disques (SATA / SAS / SSD / NVMe)
- Supervision Système
- Disponibilité (ping /ssh)
- Etat des partitions (Espace libre / Quota utilisateur)
- Niveau Inode libre
- Niveau de Charges / CPU / RAM / SWAP
- Dérive horaire
- Uptime du serveur
- Etat des différents processus internes
- Supervision Applicative
- Test des URL (Disponibilité, Code d’erreur, Délai, Contenu)
- Disponibilité et statut des applications installées comme Apache, Ngnix, Tomcat, Varnish, ElasticSearch, MySQL, PostgreSQL, FTP, Postfix, Qmail, etc.
- Contrôle des systèmes de réplication distante présents sur le serveur (Heatbeat / DRBD / GlusterFS / Ceph / MySQL / PostgreSQL /etc.)
- Supervision Réseau
- Interface et routage des IPF
- Pénalité Antispam des IP
*******************
Gestion des sauvegardes
La sauvegarde de tous les environnements est réalisée journellement, en jour paire et jour impaire, sur deux serveurs différents, dont l’un des serveurs est obligatoirement positionné sur un autre datacenter que votre service.
D’autre part, la base de données des utilisateurs est réalisée toutes les 2 heures.
*******************
Gestion PRA
PRA = Plan de Reprise d’Activité ou DRP en anglais (Disaster Recovery Plan)
Le PRA consiste à mettre en place une politique à suivre en cas de défaillance sérieuse de la machine principale (dite « de production »).
Le PRA implique l’utilisation d’une ou plusieurs machines dans des datacenter différents de la production permettant de préparer les environnements et aptes à recevoir les data de production.
Si une défaillance majeure a lieu sur le serveur de production, le serveur PRA qui est synchronisé sur le serveur de production, récupère les data présentes lors de la dernière sauvegarde effective des environnements & base de données concernés.
En fonction des événements rencontrés, 1stKYC ordonne ou non l’activation du plan de PRA, ce dernier générant une perte de données dont le delta dépend de l’heure de la défaillance / heure de la dernière sauvegarde. Au maximum 2 heures dans notre organisation.
Le temps de restauration des environnements est dépendant essentiellement de la volumétrie de données à copier entre la ferme backup et le serveur de PRA.
Procédure de déclenchement du PRA :
– Situation : toute situation dégradant le service dont la durée n’est pas estimée par le fournisseur, ou, laissant supposer un blocage exprimé en nombre de jours, tels que :
- Incendie
- Dégâts des eaux
- Perte intégrale de réseau
- Défaillance majeure d’un datacenter
– Processus d’alerte : Information de la situation par ticket, pouvant donner suite à un appel
avec chef de projet, direction et décideurs afin d’appliquer les modalités de PRA.
– Activation : sur ordre de 1stKYC
Méthode d’activation :
– Copie des fichiers & configurations depuis les serveurs de sauvegardes vers le serveur PRA (estimation 2 à 3h)
– Import manuel de la base de données depuis les serveurs de sauvegardes sur le serveur PRA
– Ticket d’information pour prévenir que la PRA est finalisée
– Modification des DNS sur le domaine concerné afin de cibler l’ip du PRA
Méthode de retour en production :
– Mise en maintenance du serveur de production
– Copie des fichiers depuis PRA vers le serveur de production (estimé 2 à 3h)
– Import manuel de la base de données sur depuis PRA vers le serveur de production
– Ticket informant de la bascule des éléments sur le serveur de production
– Modification des DNS sur le domaine concerné afin de cibler l’IP du serveur de production
