Déploiement sécurisé d'Umami Analytics avec Docker et PostgreSQL

Un récent guide technique publié le 18 octobre 2026 décrit les étapes spécifiques requises pour héberger soi-même Umami Analytics version 3.4.0 à l'aide de Docker et PostgreSQL. L'article souligne les pratiques de configuration sécurisées, notamment en ce qui concerne la liaison réseau et l'authentification initiale, afin de prévenir tout accès non autorisé lors du processus d'installation.

Ce qui s'est passé

Le guide propose une procédure détaillée pour déployer Umami, une alternative respectueuse de la vie privée à Google Analytics, dans un environnement conteneurisé. Il spécifie l'utilisation de l'image ghcr.io/umami-software/umami:3.4.0 associée à un conteneur de base de données postgres:15.19-alpine. Un point central des instructions est la modification de la configuration Docker Compose par défaut pour renforcer la sécurité dès le déploiement.

L'auteur met en évidence un risque de sécurité critique dans la configuration par défaut en amont, qui lie le port de l'application à toutes les interfaces réseau. Étant donné que les ports publiés par Docker peuvent contourner les pare-feu au niveau de l'hôte comme ufw, laisser les paramètres par défaut intacts pourrait permettre à des acteurs externes d'accéder à l'application avant que l'administrateur n'ait eu la chance de la sécuriser. Le guide recommande de lier le port spécifiquement à 127.0.0.1, garantissant ainsi que seuls les processus locaux, tels qu'un proxy inverse, puissent communiquer avec l'instance Umami.

Une autre partie importante du guide traite des identifiants par défaut. Umami s'initialise avec une combinaison standard de nom d'utilisateur et de mot de passe : admin et umami. Les instructions soulignent que les administrateurs doivent changer ce mot de passe immédiatement après la première connexion. Si le port est exposé à Internet public avant cette modification, tout utilisateur découvrant le service pourrait se connecter en tant qu'administrateur et compromettre l'instance.

Détails clés

• La version 3.4.0 d'Umami ne prend pas en charge MySQL ; PostgreSQL est le moteur de base de données requis.
• Les identifiants de connexion administratifs par défaut sont le nom d'utilisateur admin et le mot de passe umami.
• La liaison du port Docker à 127.0.0.1:3000 empêche l'accès réseau externe au port brut de l'application.
• Les secrets tels que POSTGRES_PASSWORD, APP_SECRET et TWO_FACTOR_ENCRYPTION_KEY doivent être stockés dans un fichier .env protégé.
• Modifier le mot de passe PostgreSQL dans les variables d'environnement après la création initiale de la base de données entraînera des échecs d'authentification, sauf si le mot de passe de l'utilisateur de la base de données est également mis à jour manuellement.
• L'application inclut un filtre de détection de bots qui ignore silencieusement les requêtes provenant de navigateurs sans interface graphique (headless), ce qui peut perturber les développeurs lors des tests.

Contexte

L'hébergement autonome de logiciels d'analyse donne aux organisations le contrôle de leurs données, mais il transfère également entièrement la responsabilité de la sécurité à l'équipe informatique interne. Contrairement aux services gérés où le fournisseur assure la correction des failles et le contrôle d'accès, les instances auto-hébergées nécessitent une configuration minutieuse des limites réseau et des mécanismes d'authentification. Docker simplifie le déploiement d'applications complexes comme Umami en regroupant l'application et ses dépendances dans des conteneurs, mais il introduit des comportements réseau spécifiques que les administrateurs doivent comprendre.

Une idée reçue courante est que les pare-feu au niveau de l'hôte protègent automatiquement les conteneurs Docker. Dans de nombreuses configurations par défaut, Docker gère ses propres règles iptables, ce qui peut remplacer les paramètres de pare-feu définis par l'utilisateur comme ufw. Cela signifie que si un conteneur expose un port à l'hôte, il peut être accessible depuis le réseau plus large même si le pare-feu de l'hôte semble bloquer ce trafic. Comprendre cette interaction est crucial pour sécuriser toute application web auto-hébergée.

Pourquoi c'est important

Pour les équipes qui exécutent leur propre logiciel, la différence entre un déploiement sécurisé et un déploiement vulnérable tient souvent à de petits détails de configuration. La recommandation de lier à localhost est une stratégie fondamentale de défense en profondeur. Elle garantit que l'application n'est pas directement exposée à Internet, forçant tout le trafic à passer par un proxy inverse comme Caddy ou Nginx. Cette configuration permet au proxy de gérer la terminaison TLS et les en-têtes de sécurité supplémentaires, tandis que l'application elle-même reste isolée sur l'interface de bouclage locale.

Le problème des identifiants par défaut est un autre défi persistant dans les environnements auto-hébergés. De nombreux projets open source utilisent des mots de passe par défaut simples pour faciliter la configuration initiale et les tests. Cependant, si ces valeurs par défaut ne sont pas changées immédiatement, elles deviennent un point d'entrée bien connu pour les attaquants. Automatiser le processus de génération de secrets, comme suggéré dans le guide à l'aide d'outils comme openssl, réduit le risque d'erreur humaine et garantit que chaque déploiement commence avec des identifiants uniques et forts.

De plus, la note du guide concernant le filtrage des bots souligne l'importance de comprendre la logique de l'application lors du dépannage. Les développeurs testent souvent les nouveaux déploiements à l'aide d'outils automatisés ou de navigateurs headless, qu'Umami identifie comme des bots et ignore. Sans cette connaissance, les équipes pourraient passer beaucoup de temps à déboguer pourquoi leurs scripts de suivi semblent échouer, alors qu'en fait le système fonctionne comme prévu pour préserver la qualité des données.

Ce que vous pouvez faire

• Générez des secrets forts et aléatoires pour POSTGRES_PASSWORD, APP_SECRET et TWO_FACTOR_ENCRYPTION_KEY avant de démarrer les conteneurs.
• Modifiez le fichier Docker Compose pour lier le port Umami à 127.0.0.1 au lieu de toutes les interfaces.
• Déployez un proxy inverse tel que Caddy pour gérer les connexions HTTPS et transmettre le trafic vers l'instance Umami locale.
• Connectez-vous immédiatement après le premier démarrage et changez le mot de passe admin par défaut pour une valeur forte et unique.
• Épinglez la balise d'image Docker à une version spécifique comme 3.4.0 plutôt que d'utiliser latest pour garantir des mises à jour prévisibles.
• Testez la fonctionnalité de suivi à l'aide d'un navigateur standard avec un agent utilisateur normal pour éviter d'être filtré par la détection intégrée des bots.