Skip to main content

Sécurité du réseau

Exécutez le CODESYS 4 serveur uniquement derrière un proxy inverse TLS

Groupe cible: Administrateurs système

Description: Le CODESYS 4 Le serveur lui-même ne fournit pas de chiffrement TLS et, en dehors de localhost, il n'est accessible que via HTTP non chiffré. Par conséquent, un proxy inverse TLS externe en amont (par exemple nginx) ou un proxy de portail est nécessaire pour son fonctionnement sur le réseau. Ce proxy inverse TLS externe (par exemple nginx) ou ce proxy de portail termine les connexions TLS et redirige les connexions HTTP et WebSocket vers le serveur. CODESYS 4 serveur. Sans contexte sécurisé (HTTPS), l'application web refusera de s'exécuter.

Action Dans chaque opération réseau ou opération de production, il est absolument nécessaire de configurer un proxy inverse TLS en amont ou un proxy de portail devant le serveur. CODESYS 4 serveur. Pour ce faire, utilisez la configuration nginx d'exemple fournie ou adaptez-la à votre environnement. Un guide d'installation se trouve dans le répertoire. guide de démarrage rapide.

Raisonnement En l'absence de chiffrement TLS, les identifiants, les informations de session et les données du projet seraient transmis en clair sur le réseau et pourraient être lus ou manipulés par un attaquant ayant accès au réseau. Par conséquent, l'application web requiert impérativement un contexte sécurisé (MSDN). De ce fait, le fonctionnement du réseau sans chiffrement TLS en amont est techniquement impossible.

Mettez en place une protection supplémentaire contre les attaques par force brute et les attaques par déni de service (DDoS).

Groupe cible: Administrateurs système

Description: CODESYS 4 Le système limite les tentatives de connexion en interne grâce à plusieurs mesures : un délai aléatoire lors de la connexion, un maximum de 10 connexions simultanées par utilisateur et de 500 au total, ainsi qu’un cache pour les noms d’utilisateur invalides. Cependant, ces mesures n’offrent pas une protection complète contre les attaques par force brute et les attaques par déni de service distribué (DDoS).

Action Mettez également en place une protection en amont contre les attaques par force brute et les attaques par déni de service (DDoS) au niveau de l'infrastructure : par exemple, en limitant le débit et les connexions au niveau du proxy inverse ou d'un pare-feu applicatif web (WAF) en amont. Cette protection en amont relève de votre responsabilité en tant qu'opérateur.

Raisonnement: Les restrictions internes de CODESYS 4 Ces mesures rendent les attaques plus difficiles, mais ne peuvent empêcher totalement les attaques par force brute ciblées ni les attaques par déni de service distribué (DDoS). Sans protection en amont, un attaquant peut compromettre la disponibilité du système pour les utilisateurs autorisés.

Isolez et protégez vos propres solutions de proxy de portail.

Groupe cible: Administrateurs système

Description: Au lieu du proxy fourni de CODESYS 4 Sur le serveur, vous pouvez utiliser votre propre proxy de portail ou votre propre isolation de session – par exemple, un conteneur Docker distinct par session avec le CODESYS 4 Le système dorsal. La sécurité d'une telle configuration est entièrement de votre responsabilité et ne peut être évaluée par CODESYS Dans cette variante, la connexion entre le proxy et le serveur dorsal n'est actuellement ni authentifiée ni chiffrée.

Action Isolez et sécurisez la connexion entre votre proxy et le CODESYS 4 Le serveur d'arrière-plan doit être hébergé sur des serveurs, conteneurs ou réseaux distincts afin d'être inaccessible aux autres utilisateurs, qu'ils soient locaux ou distants. Jusqu'à nouvel ordre, exécutez cette variante exclusivement dans des environnements sécurisés. Veillez à ce qu'aucune donnée sensible (mots de passe, jetons) ne soit enregistrée.

Raisonnement La connexion entre le proxy et le serveur dorsal n'est actuellement ni authentifiée ni chiffrée. Par conséquent, un attaquant ayant accès à cette connexion pourrait détourner des sessions, usurper l'identité d'un autre utilisateur, lire ou manipuler des données transmises, ou bloquer l'accès aux sessions.

N'utilisez les connexions en ligne aux contrôleurs que dans des réseaux sécurisés.

Groupe cible: Administrateurs système

Description: CODESYS 4 Actuellement, la connexion en ligne avec la passerelle et le contrôleur (système d'exécution) n'est pas chiffrée. Seul le mot de passe du contrôleur est protégé par chiffrement lors de sa transmission. L'application de démarrage – et donc la propriété intellectuelle de votre projet – ainsi que les données de surveillance et de contrôle en temps réel sont actuellement transmises en clair sur le réseau.

Action: Exploiter les connexions en ligne aux passerelles et aux contrôleurs exclusivement dans un réseau sécurisé ou segmenté inaccessible aux utilisateurs non autorisés.

Raisonnement Un attaquant ayant accès au réseau pourrait intercepter le trafic en ligne non chiffré – et exposer par exemple le savoir-faire de votre projet – ou manipuler les données et les commandes transmises.

Maintenez une configuration TLS sécurisée sur le proxy inverse.

Groupe cible: Administrateurs système

Description Le chiffrement TLS est effectué pendant le fonctionnement du CODESYS 4 serveur via le proxy inverse en amont (voir aussi : Exécutez le CODESYS 4 serveur uniquement derrière un proxy inverse TLSCela signifie qu'en tant qu'opérateur de ce proxy, vous êtes également responsable de la sélection et de la maintenance du logiciel de proxy inverse, des versions TLS autorisées et des suites de chiffrement.

Action Configurez les versions TLS et les suites de chiffrement autorisées sur votre proxy inverse en fonction des dernières recommandations et veillez à maintenir cette configuration à jour. Assurez-vous également de maintenir votre logiciel de proxy inverse à jour afin de corriger rapidement toute faille de sécurité.

Raisonnement Des versions TLS obsolètes ou des suites de chiffrement faibles peuvent permettre à un attaquant de casser le chiffrement et de lire ou de manipuler les données transmises.