Sécurité et architecture des serveurs Seald

Architecture externe

Seald fonctionne en “Cloud” hébergée chez OVH; aucune installation de serveur n'est nécessaire chez le client pour faire fonctionner la solution.

Schéma d'architecture
Architecture simplifiée de Seald

Services utilisés par Seald

L'application client lourd Seald, ainsi que sa version allégée dans le navigateur, doivent avoir accès à divers services pour fonctionner :

API de Seald

Domaine: api.seald.io
Type de flux: HTTPS/443
Flux obligatoire: Oui

L'API de Seald est le principal maillon de communication de l'application Seald. C'est sur cette interface que seront échangées la plupart des informations telles que les clés publiques des utilisateurs ainsi que les clés de message des fichiers (voir les concepts clés et protocoles).

Service de notification

Domaine: crossbar.galactica.seald.io
Type de flux: HTTPS/443
Flux obligatoire: Non, mais hautement recommandé

Le service de notification Seald a deux principales fonctionnalités :

  • Permettre à une instance Seald de recevoir des notifications "en direct", telles que la lecture d'un fichier ou l'ajout d'un équipement à un compte. Ces notifications sont également disponibles et répliquées sur l'API de Seald, mais l'API de Seald ne permet pas une visibilité immédiate.
  • Permettre aux instances Seald (ou client léger) de communiquer directement entre elles.

Service de support et ticketing

Domaine: zammad.galactica.seald.io
Type de flux: HTTPS/443
Flux obligatoire: Non

Le service de support et ticketing permet aux utilisateurs de Seald de directement contacter le support via l'application, que ce soit pour de l'assistance ou du rapport de bogue.

Service de rapport de bogue

Domaine: sentry.galactica.seald.io
Type de flux: HTTPS/443
Flux obligatoire: Non

Le service de rapport de bogue permet en cas de crash de l'application de récupérer des informations techniques relatives au bogue. Ces informations sont anonymisées et permettent uniquement à l'équipe de développement de Seald d'avoir l'information de l'origine du bogue.

Service de mise à jour

Domaine: github.com
Type de flux: HTTPS/443
Flux obligatoire: Non, mais hautement recommandé

Le service de mise à jour permet le stockage et la récupération des binaires de l'application Seald. Il est nécessaire d'avoir accès à ce service pour avoir une version à jour de Seald.

Sécurité

Disponibilité

  • La base de données de Seald est hébergée dans les datacenters d'OVH. Elle est dimensionnée de façon hautement disponible et est répliquée trois fois.
  • Le service d'API de Seald est hébergé dans les datacenters d'OVH. L'applicatif sous-jacent est également configuré en haute disponibilité.
  • La base de données est sauvegardée quotidiennement.
  • Les systèmes de fichier des serveurs Seald sont sauvegardés de façon hebdomadaire.
  • La disponibilité des services est surveillée par l'application Cabot. Un rapport des métriques de disponibilité des services peut être mis à disposition sur demande.

Intégrité

  • L'ensemble des serveurs est mis à jour de façon mensuelle.
  • Une veille continue des vulnérabilités des composants est réalisée.
  • Des scans de sécurité sont effectués de façon hebdomadaire. Les rapports de sécurité peuvent être mis à disposition sur demande.
  • Les serveurs de productions ont tous un environnement identique de tests (appelé "Staging").

Confidentialité

  • Tous les flux entrant des serveurs sont soit sécurisés (TLS / SSH), soit redirigeant vers des flux sécurisés (HTTP + HSTS).
  • Les champs sensibles de la base de données sont chiffrés, ainsi ces données ne peuvent être extraites des sauvegardes des bases de données sans la clé de déchiffrement.
  • La sauvegarde hebdomadaire des systèmes de disque des serveurs Seald est également chiffrée avec une clé propre par serveur.
  • Les accès administratifs et de maintenances des serveurs ne sont disponibles qu'aux salariés autorisés, suivant le principe du moindre privilège.

Traçabilité

  • Les opérations système (Unix) sont journalisées via Syslogs et intégrées aux sauvegardes hebdomadaires.
  • Les opérations applicatives (Docker) sont journalisées dans des fichiers log et intégrées aux sauvegardes hebdomadaires.
  • Les événement utilisateurs (Seald) sont journalisés dans la base de données et intégrés aux sauvegardes quotidiennes.
  • Les événement d'équipes (Seald) sont journalisés dans la base de données et intégrés aux sauvegardes quotidiennes.

Dimensionnement de la sécurité

Seald suit les recommandations de l’ANSSI et du NIST en termes de dimensionnement de la sécurité :

  • Communication HTTPS : l’intégralité des communications entre les utilisateurs et les serveurs Seald est sécurisée par le protocole TLS, en utilisant exclusivement des versions de protocoles sécurisées et des suites cryptographiques sûres.
  • Chiffrement de base de données : certains champs de la base de données sont considérés comme sensibles. Uniquement ces champs là sont chiffrés (AES256_CBC + PBKDF2HMAC), avec une clé non stockée sur la base de données.