Cet article explique pourquoi le serveur auto-hébergé d'ActivityInfo ne prend pas en charge un déploiement à deux niveaux.
Nous avons conçu notre serveur auto-hébergé pour être une plateforme puissante, fiable et sécurisée, simple à installer et à maintenir. Pour y parvenir, nous utilisons une architecture à instance unique. Cette conception est la plus adaptée pour les organisations, en particulier celles disposant de ressources informatiques limitées.
De nombreuses normes informatiques recommandent une architecture à deux niveaux, avec l'application sur un serveur et la base de données (comme MySQL ou PostgreSQL) sur un autre. Bien que ce modèle fonctionne pour de nombreuses applications, nous avons choisi une conception différente pour ActivityInfo. Cet article explique notre conception et comment sécuriser votre déploiement sur un seul serveur.
Pourquoi le serveur auto-hébergé évite une architecture à deux niveaux
Une architecture à deux niveaux peut améliorer la sécurité en plaçant la base de données sur une machine (virtuelle) séparée derrière un pare-feu. Cependant, ce modèle rendrait ActivityInfo plus lent et plus difficile à maintenir. Nous avons décidé de ne pas utiliser un serveur de base de données séparé pour deux raisons :
Les fonctionnalités gourmandes en données sont lentes avec des serveurs séparés
De nombreuses fonctionnalités d'ActivityInfo, comme l'outil de détection des enregistrements en double, sont gourmandes en données. Elles fonctionnent en effectuant des comparaisons complexes de nombreux enregistrements.
Dans un modèle à deux niveaux, l'application devrait extraire l'ensemble des données du serveur de base de données via le réseau pour effectuer cette analyse. Ce transfert de données volumineux crée une latence réseau, ce qui ralentit l'application et consomme beaucoup de bande passante. Les performances de ces fonctionnalités seraient bien moindres, en particulier pour les clients disposant de grandes bases de données.
Un serveur unique est plus simple à maintenir
Un objectif clé de notre serveur auto-hébergé est la simplicité pour les équipes qui ne peuvent pas dédier un employé à temps plein pour le gérer. Une configuration à deux serveurs vous oblige à configurer, surveiller et maintenir deux serveurs, leurs systèmes d'exploitation, les règles réseau entre eux et des comptes d'utilisateur de base de données séparés. Cette complexité va à l'encontre de notre objectif d'une solution à faible maintenance et augmente le risque d'erreur de configuration.
Conception à serveur unique
L'application auto-hébergée d'ActivityInfo est une application Java unique et autonome. Ce processus unique contient à la fois le serveur web et un moteur de base de données SQLite intégré.
Une base de données intégrée est une bibliothèque qui fait partie de l'application ActivityInfo. Votre base de données entière est stockée dans un seul fichier sur le même serveur.
Ce modèle à serveur unique offre plusieurs avantages :
- Hautes performances : L'application communique directement avec son fichier de base de données sur le disque local, l'accès aux données est donc rapide. Cela évite les retards réseau et permet aux fonctionnalités complexes et gourmandes en données, comme l'outil de détection des doublons, de s'exécuter efficacement, même sur de grands ensembles de données.
- Simplicité : Vous n'avez besoin que d'installer, de configurer, de surveiller et de sauvegarder un seul composant. Cela réduit la complexité et le risque d'erreurs de configuration.
- Fiabilité : Avec moins de composants et aucune connexion réseau entre l'application et ses données, il y a moins de points de défaillance.
Comparaison avec notre service hébergé
Notre service hébergé sur ActivityInfo.org utilise une architecture à plusieurs niveaux. Ce service est soutenu par une équipe complète d'ingénieurs et une surveillance 24/7, et peut donc se permettre d'être plus complexe. Nous utilisons une mise en cache étendue à plusieurs niveaux pour surmonter l'impact d'une architecture à plusieurs niveaux sur les fonctionnalités gourmandes en données. Visionnez notre webinaire Présentation de la version auto-hébergée d'ActivityInfo pour une comparaison entre les deux produits.
Sécurisation de votre serveur auto-hébergé d'ActivityInfo
Une architecture à serveur unique peut être tout aussi sécurisée qu'un déploiement à deux niveaux si elle est correctement configurée. Si vous n'avez pas d'équipe à temps plein pour gérer votre service ActivityInfo, un déploiement sur un seul serveur est probablement plus sécurisé car il réduit le risque d'erreur de configuration.
Voici les étapes que vous pouvez suivre pour sécuriser votre serveur auto-hébergé :
- Autoriser l'accès uniquement aux ports 80 (http) et 443 (https). Ce sont les seuls ports que le serveur ActivityInfo écoute, et les requêtes http (non sécurisées) seront automatiquement redirigées vers https. SQLite est un système de base de données intégré et ne prend pas en charge les connexions réseau.
- Désactivez l'accès SSH ou RDP au serveur, ou restreignez l'accès SSH à un hôte « bastion » au sein de votre propre réseau.
- Choisissez un système d'exploitation minimal pour le serveur ActivityInfo, tel que Alpine Linux, Ubuntu Minimal, ou le système d'exploitation optimisé pour les conteneurs de Google Cloud, afin de minimiser la surface d'attaque de la machine (virtuelle).
- Activer les mises à jour automatiques du système d'exploitation.
- Envisagez de déployer un pare-feu d'applications Web (WAF) devant le serveur ActivityInfo. Le WAF de Cloudflare est connu pour bien fonctionner avec ActivityInfo.
Les points ci-dessus sont des étapes importantes à suivre lors du déploiement spécifique de la version auto-hébergée d'ActivityInfo. Cependant, les risques les plus importants pour toute base de données ActivityInfo proviennent des utilisateurs authentifiés :
- Configurez l'Authentification unique (SSO) pour réduire le risque de lassitude liée aux mots de passe et pour garantir que les membres du personnel perdent l'accès à la base de données lorsqu'ils quittent votre organisation.
- Configurez des rôles pour vos bases de données qui suivent le principe du moindre privilège.