Comment auto-héberger CyberChef en 2026 : accès sécurisé, hébergement sans état et mises à jour

La démonstration CyberChef la plus simple prouve qu’un processus écoute sur le port 80. La production exige des preuves plus solides. Elle doit réussir ce scénario, même après le remplacement du container : créer une recipe en plusieurs étapes, l’exporter, traiter un fichier représentatif et confirmer que le hash de sortie correspond à une valeur connue.

CyberChef est déployé dans un but précis : fournir un workbench dans le navigateur pour l’encodage, le décodage, l’analyse et la cryptographie. Le piège de déploiement le plus courant est que les opérations volumineuses épuisent la mémoire du navigateur alors que le serveur reste sain. La gestion de l’URL publique et la persistance de l’état doivent donc recevoir autant d’attention que le démarrage de l’image.

Choisir la topologie CyberChef viable la plus simple

Un schéma CyberChef utile montre la route publique, le port privé 80, la frontière d’état et chaque exigence associée. Indiquez quelles flèches transportent des credentials et lesquelles correspondent au trafic utilisateur ordinaire. Le build CyberChef standard n’a besoin ni de base de données ni de service runtime persistant séparé. Gardez le web container remplaçable et placez toute future fonctionnalité d’authentification, de collaboration ou de stockage derrière une frontière documentée séparément.

Prouvez le schéma avec une action réelle : créez une recipe en plusieurs étapes, exportez-la, traitez un fichier représentatif et confirmez que le hash de sortie correspond à une valeur connue. La pression viendra probablement de la mémoire du navigateur et du CPU pour les recipes volumineuses plutôt que du calcul côté container dans le déploiement statique standard ; surveillez ce chemin au lieu de traiter toutes les requêtes HTTP de la même manière.

Exécuter la première instance proche de la production

Utilisez le container comme un runtime remplaçable, et non comme la source de vérité.

docker run -d \
  --name cyberchef \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  ghcr.io/gchq/cyberchef:latest

Vérifiez l’exigence locale avant toute exposition : le build client standard n’a pas besoin de base de données. Inspectez l’utilisateur du container, les chemins accessibles en écriture et le listener associé avant de l’exposer. Exécutez l’action complète — créer une recipe en plusieurs étapes, l’exporter, traiter un fichier représentatif et confirmer que le hash de sortie correspond à une valeur connue — puis enregistrez la référence exacte de l’image qui a produit le résultat.

Tester CyberChef depuis l’extérieur du serveur

Publiez l’interface statique sur une origine HTTPS de confiance. Dirigez le hostname choisi vers le port 80 du container, transmettez le host et le schéma HTTPS d’origine, et évitez de publier une seconde origine directe.

Testez CyberChef depuis un client externe vierge. Distinguez une défaillance d’ingress de la limite applicative connue : les opérations volumineuses épuisent la mémoire du navigateur alors que le serveur reste sain. Une erreur de certificat, de DNS ou 502 relève du routage ; une requête qui atteint CyberChef puis échoue relève de l’état applicatif, de la capacité ou d’une exigence associée. Le guide TLS pour les domaines personnalisés couvre le premier groupe.

Repérer chaque octet durable dans CyberChef

Le container CyberChef standard ne possède aucun mount de données applicatives obligatoire. Son périmètre de récupération reste toutefois explicite : aucune donnée applicative ; conservez la configuration de déploiement et la référence d’image figée. Ne créez pas de volume vide uniquement pour donner au déploiement une apparence stateful ; conservez plutôt la référence exacte de l’image et la configuration validée.

Reconstruisez CyberChef sur un hôte vierge et exécutez la transaction d’acceptation. La récupération est validée lorsque le build statique figé peut être recréé et qu’une recipe exportée produit la même sortie connue. Toute base de données ou tout service de collaboration connecté doit suivre son propre plan de sauvegarde cohérent avec l’application, tandis que le web container remplaçable est recréé depuis le code. Le guide du déploiement d’un dépôt Git en production décrit cette frontière reproductible.

Conservez un checksum ou un digest pour l’image validée et retestez après chaque mise à jour. Pour un service sans état, une reconstruction réussie constitue le test de restauration ; pour un état externe, le runbook CyberChef doit renvoyer vers le responsable et la procédure de récupération distincts.

Protéger la partie importante de CyberChef

N’ajoutez pas de faux secret d’environnement uniquement pour donner à CyberChef une apparence plus sécurisée. Le véritable enjeu est le traitement de données sensibles dans une image modifiée ou non fiable. Publiez donc uniquement une image officielle ou construite de manière reproductible lorsque les opérateurs sont susceptibles d’y coller des credentials, des captures ou des éléments encodés.

Restreignez la route publique lorsque cela est nécessaire, vérifiez le digest de l’image et exécutez le container sans les mounts hôte ni les privilèges dont il n’a pas besoin. Appliquez des limites fondées sur la mémoire du navigateur et le CPU pour les recipes volumineuses plutôt que sur le calcul côté container dans le déploiement statique standard. Les logs doivent enregistrer les échecs et les durées sans conserver les entrées sensibles traitées par CyberChef.

Diagnostiquer un CyberChef qui semble sain

Mesurez la mémoire du navigateur et le CPU pour les recipes volumineuses plutôt que le calcul côté container dans le déploiement statique standard, tout en exécutant cette transaction de régression : créer une recipe en plusieurs étapes, l’exporter, traiter un fichier représentatif et confirmer que le hash de sortie correspond à une valeur connue. Gardez la liveness probe légère ; les conversions ou le travail côté navigateur doivent relever d’un release check distinct afin qu’un échantillon lourd ne déclenche pas une restart loop.

Le risque d’une mise à niveau vient du fait que les opérations des recipes CyberChef et les bibliothèques incluses peuvent modifier la sortie ou la compatibilité. Le build figé doit donc faire l’objet d’un test de régression. Exécutez le digest candidat à côté de l’image actuelle, transmettez-leur les mêmes entrées connues et comparez les sorties, les headers et les durées. Si les opérations volumineuses épuisent la mémoire du navigateur alors que le serveur reste sain, conservez la requête en échec et la référence de l’image avant de modifier la route.

Transformer le smoke test CyberChef en release check

Le compte rendu de release CyberChef doit contenir des faits, pas un simple « ça semble fonctionner ». Enregistrez le digest de l’image sélectionnée, le checksum de la configuration, le hostname public et un résultat horodaté pour les actions suivantes : créer une recipe en plusieurs étapes, l’exporter, traiter un fichier représentatif et confirmer que le hash de sortie correspond à une valeur connue. Utilisez des données d’exemple hors production afin que le contrôle puisse être exécuté après chaque déploiement.

Prouvez séparément les deux événements du cycle de vie. Le remplacement d’un container doit préserver le fonctionnement normal ; une récupération propre doit montrer que le build statique figé peut être recréé et qu’une recipe exportée produit la même sortie connue. Pendant l’exécution des contrôles, mesurez la mémoire du navigateur et le CPU pour les recipes volumineuses plutôt que le calcul côté container dans le déploiement statique standard, et conservez le résultat comme enveloppe de référence pour cette version.

Testez également une condition refusée ou invalide : envoyez une entrée inoffensive proche de la limite de ressources ou de format associée à cette frontière — les opérations volumineuses épuisent la mémoire du navigateur alors que le serveur reste sain. CyberChef doit échouer de manière diagnostiquable et ne doit pas écraser un état sain. Rétablissez la condition valide, relancez l’échantillon et joignez les logs pertinents après suppression des données sensibles. Ces artefacts fournissent des éléments concrets pour décider d’un futur rollback.

Déplacer le travail d’infrastructure reproductible vers Dockup

Pour CyberChef sans état, le rôle de Dockup est ciblé et utile : démarrer l’image figée, garder le port 80 privé, associer la route HTTPS et remplacer le container sans inventer de stockage. Le déploiement peut cibler l’infrastructure Dockup ou un serveur fourni par le client.

Terminez la configuration applicative : publiez l’interface statique sur une origine HTTPS de confiance. Dockup doit conserver les paramètres du runtime CyberChef tandis que l’opérateur confirme l’exigence locale suivante : le build client standard n’a pas besoin de base de données. Exécutez cette action d’acceptation : créer une recipe en plusieurs étapes, l’exporter, traiter un fichier représentatif et confirmer que le hash de sortie correspond à une valeur connue. L’authentification facultative ou les services externes doivent être représentés comme une configuration et des dépendances distinctes afin que le déploiement reste fidèle.

Foire aux questions

De quoi CyberChef a-t-il besoin pour un déploiement en production ?

Acheminez le container CyberChef sur le port 80 via une seule origine HTTPS. Le build CyberChef standard n’a besoin ni de base de données ni de service runtime persistant séparé. Ne considérez pas CyberChef comme prêt tant que vous ne pouvez pas créer une recipe en plusieurs étapes, l’exporter, traiter un fichier représentatif et confirmer que le hash de sortie correspond à une valeur connue.

Quelles données CyberChef faut-il sauvegarder ?

L’image CyberChef standard ne possède aucun mount de données applicatives obligatoire. Conservez sa configuration de déploiement et sauvegardez séparément tout état connecté ; la récupération est validée lorsque le build statique figé peut être recréé et qu’une recipe exportée produit la même sortie connue.

CyberChef nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine CyberChef publique et gardez le port 80 sur la route interne. Appliquez correctement le paramètre CyberChef : publiez l’interface statique sur une origine HTTPS de confiance. Pour CyberChef, HTTPS protège les credentials ou le contenu utilisateur en transit et garantit la cohérence des comportements client sensibles à l’origine.

Comment tester une mise à niveau de CyberChef ?

Déployez l’image CyberChef candidate à côté de l’image actuelle et répétez la transaction d’acceptation avec une entrée connue. Soyez particulièrement attentif, car les opérations des recipes CyberChef et les bibliothèques incluses peuvent modifier la sortie ou la compatibilité : le build figé doit donc faire l’objet d’un test de régression. Le container standard ne comporte aucune migration de données ; conservez donc le digest précédent jusqu’à la réussite des contrôles de sortie et de compatibilité.