Système de fichiers

Groupe cible: Administrateurs système

Description: CODESYS 4 stocke les fichiers de configuration globaux dans un dossier de configuration système. Sous Linux, ce dossier se trouve à l'emplacement suivant : /etc/CODESYS-4 Il est créé via le paquet .deb lors de l'installation et, par défaut, seuls les administrateurs peuvent y écrire. Sous Windows, CODESYS 4 stocke un sous-dossier sécurisé dans %ProgramData% et refusera de s'exécuter si ses autorisations ne sont pas correctement configurées. Aucune information d'identification n'est enregistrée dans les paramètres globaux.

Action Assurez-vous que le dossier de configuration global ne soit accessible en écriture que par les administrateurs ou le gestionnaire de paquets. c4-pkm – et les autorisations sont correctement configurées. Sinon CODESYS 4 refusera de démarrer sous Windows.

Raisonnement Si les utilisateurs ordinaires pouvaient modifier la configuration globale, alors le comportement de CODESYS 4 Cette méthode pourrait être manipulée pour tous les utilisateurs du système. En particulier, des extensions – et donc également des bibliothèques compilées – pourraient être injectées de cette manière sans que cela soit détecté ni suivi. Les extensions pourraient également exécuter du code arbitraire avec les privilèges de l'utilisateur actuel (voir aussi : Installez et utilisez uniquement des extensions de confiance).

Groupe cible: Administrateurs système

Description: Pour la vérification de la signature des paquets et des bibliothèques, CODESYS 4 utilise le magasin de certificats système ou les ancres de confiance qui y sont stockées. Windows utilise par défaut le magasin de certificats système.

Action Protégez le magasin de certificats et les ancres de confiance contre toute modification par les utilisateurs locaux en configurant les permissions du système de fichiers et en mettant régulièrement à jour les ancres de confiance – une opération comparable à la maintenance ca-certificates sous Linux.

Raisonnement Si un utilisateur local peut modifier les ancres de confiance ou en ajouter lui-même, les signatures de paquets ou de bibliothèques malveillants peuvent être acceptées comme fiables lors de la vérification. Des extensions malveillantes, auparavant bloquées par vérification de signature, peuvent désormais être installées de cette manière. Seule l'installation est consignée, et non le fait que la signature repose sur une ancre de confiance injectée ultérieurement – par exemple, une autorité de certification racine auto-signée.

Groupe cible: Administrateurs système

Description Par défaut, CODESYS 4 écrit les journaux de débogage dans le %APPDATA%\CODESYS-4\logs dossier sous Windows et vers le ~/.config/CODESYS-4/logs Sous Linux, les fichiers journaux sont stockés dans un dossier. Ils sont archivés lorsqu'ils atteignent environ 1 Mo et conservés pendant 14 jours, limitant ainsi l'espace de stockage utilisé.

Action Définissez des permissions restrictives pour le répertoire des journaux afin que seuls les utilisateurs autorisés puissent lire les fichiers journaux.

Raisonnement Les fichiers journaux peuvent contenir des informations sensibles et personnelles (voir aussi : Tenir compte des données personnelles dans les journaux de débogageUn répertoire de journaux insuffisamment protégé permet à d'autres utilisateurs de lire ces informations ou de manipuler les fichiers journaux.

Groupe cible: Administrateurs système

Description: CODESYS 4 Ce système ne possède pas de liste de contrôle d'accès (ACL) dédiée aux répertoires de projet et de travail. La protection des accès repose entièrement sur les permissions du système d'exploitation. Par défaut, aucun répertoire de travail n'est partagé.

Action Lors de la mise en place de répertoires de travail partagés pour une équipe, protégez-les avec des autorisations de groupe ou ACL appropriées afin que seul le groupe d'utilisateurs prévu puisse lire et écrire.

Raisonnement Des autorisations mal configurées permettent à des utilisateurs extérieurs à l'équipe concernée de consulter, de manipuler ou d'endommager des projets partagés – et donc la propriété intellectuelle de votre équipe – ce qui peut entraîner une perte de données.