Cet article explique pourquoi le serveur auto-géré ActivityInfo ne prend pas en charge un déploiement à deux niveaux.
Nous avons conçu notre serveur auto-géré pour qu'il soit une plateforme puissante, fiable et sécurisée, simple à installer et à maintenir. Pour ce faire, nous utilisons une architecture à instance unique. Cette conception est la plus adaptée aux organisations, en particulier celles qui disposent 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 serveur unique.
Pourquoi le serveur auto-géré é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 de 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 le scanner d'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 sur le réseau depuis le serveur de base de données pour effectuer cette analyse. Ce transfert de données important crée une latence réseau, ce qui ralentit l'application et utilise beaucoup de bande passante. Les performances de ces fonctionnalités seraient bien pires, en particulier pour les clients disposant de bases de données volumineuses.
Un serveur unique est plus simple à maintenir
L'un des principaux objectifs de notre serveur auto-géré est la simplicité pour les équipes qui ne peuvent pas affecter un employé à temps plein à sa gestion. Une configuration à deux serveurs vous oblige à configurer, surveiller et maintenir deux serveurs, leurs systèmes d'exploitation, les règles de réseau entre eux et des comptes d'utilisateurs de base de données distincts. Cette complexité va à l'encontre de notre objectif d'une solution nécessitant peu de maintenance et augmente le risque de mauvaise configuration.
Conception à serveur unique
L'application auto-gérée ActivityInfo est une application Java unique et autonome. Ce processus unique comprend à 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. L'ensemble de votre base de données est stocké dans un seul fichier sur le même serveur.
Ce modèle à serveur unique offre plusieurs avantages :
- Haute performance : l'application communique directement avec son fichier de base de données sur le disque local, de sorte que l'accès aux données est rapide. Cela évite les retards de réseau et permet aux fonctionnalités complexes et gourmandes en données, comme le scanner de doublons, de fonctionner efficacement, même sur de grands ensembles de données.
- Simplicité : vous n'avez besoin d'installer, de configurer, de surveiller et de sauvegarder qu'un seul composant. Cela réduit la complexité et le risque d'erreurs de configuration.
- Fiabilité : avec moins de pièces 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 pris en charge par une équipe complète d'ingénieurs et une surveillance 24h/24 et 7j/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. Regardez notre webinaire Présentation de la version auto-gérée d'ActivityInfo pour une comparaison entre les deux produits.
Sécurisation de votre serveur auto-géré ActivityInfo
Une architecture à serveur unique peut être 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 à serveur unique est susceptible d'être plus sûr car il réduit le risque d'erreur de configuration.
Voici les étapes que vous pouvez suivre pour sécuriser votre serveur auto-géré :
- Autorisez 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 limitez 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 Container-optimized OS de Google Cloud, afin de minimiser la surface d'attaque de la machine (virtuelle).
- Activez les mises à jour automatiques du système d'exploitation.
- Envisagez de déployer un pare-feu d'application 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-géré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 fatigue liée aux mots de passe et pour vous assurer 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.