Développez-vous des applications ? Attention au risque de dérive de configuration

Quiconque est en charge de développer une application ou, s’il participe à ce processus, sait qu’il y a plusieurs procédures à effectuer. Une application, à quelque fin que ce soit, est censée subir des changements constants pour la faire fonctionner de mieux en mieux. Aussi, pour qu’il soit de plus en plus sécurisé et qu’il préserve la confidentialité des données des utilisateurs. Cependant, que se passe-t-il si tous ces changements entraînent des problèmes ? Aujourd’hui, dans RedesZone, nous allons parler de la question de la configuration des dérives .

Chaque fois qu’une application est développée, elle doit subir des modifications. Qui se reflètent dans les mises à jour. Ces modifications peuvent refléter des améliorations de l’interface utilisateur ou une amélioration de votre infrastructure qui permet de meilleures performances. Cependant, il existe un risque que les modifications affectent négativement l’application. Certains peuvent même le rendre inutile. Cette situation est connue sous le nom de dérive de configuration . Cela entraîne des performances globales médiocres des applications, plutôt que meilleures.

Mais cela ne veut pas dire qu’il puisse y avoir précisément certains types de mises à jour qui s’appliquent ouvertement afin de générer une telle configuration de dérive. Une série de mauvaises pratiques peut amener l’application à baisser progressivement ses performances et donc également ses niveaux de sécurité.

Dérive de configuration et élévation de privilèges

Un exemple pratique que nous pouvons citer est le développeur d’application typique qui accède fréquemment à un serveur. En fait, l’accès doit être permanent, même pour les plus petits changements et révisions en général. Si je souhaite apporter des modifications à l’application en production (c’est-à-dire à l’environnement qui fait fonctionner l’application en tant que telle pour les utilisateurs), j’ai besoin d’informations d’identification d’administrateur spéciales. Ce développeur n’aime pas l’idée d’avoir des identifiants supplémentaires car finalement, cela implique un temps supplémentaire qui peut nuire au temps dont vous disposez pour livrer vos modifications à l’application.

Cependant, ce développeur a obtenu les informations d’identification dont il a besoin pour les modifications de production qu’il doit apporter. Vous pouvez même modifier vos autorisations et ajouter celles dont vous avez besoin afin d’avoir des autorisations d’administrateur via l’interface de gestion des utilisateurs. Apparemment, il n’y a pas de problème, car ces autorisations d’administrateur ne s’appliquent qu’au serveur auquel le développeur doit accéder.

Rappelons que toute procédure appliquée en production peut très bien ou très mal se passer. Et si cela se passe très mal, les utilisateurs sont les principaux concernés. Une situation qui reflète un changement de production mal appliqué est lorsqu’une personne met à jour l’application vers sa dernière version. Mais malheureusement, cette dernière version ne permet pas à la personne de se connecter à son compte, d’afficher en permanence un message d’erreur, etc. Le développeur de cet exemple n’a pas d’intentions qui vont au-delà de la réalisation de son travail dans les délais, car le temps dont il dispose pour son projet est très serré.

Mais, que se passe-t-il si à la place de cette personne, c’est un cybercriminel ou un collaborateur malveillant ? L’ escalade de privilèges est l’une des attaques qui ont laissé des séquelles sur un réseau, un système et une infrastructure en général. Le pire, c’est que ce type d’attaque fait que plusieurs fois, elle passe inaperçue. Et c’est parce que l’utilisateur malveillant effectue toutes les activités de manière déguisée, ce qui signifie qu’ils passent par des contrôles de sécurité et qu’ils sont détectés comme bénins.

Même si l’utilisateur appliquant l’élévation de privilèges n’a pas l’intention de mener une attaque, il peut rencontrer des problèmes potentiels à d’autres égards. S’il y a un processus d’audit et que ce type d’activité est reflété, il sera très difficile de le justifier. Et s’il s’avère que cela va à l’encontre des politiques ou des réglementations en matière de conformité, l’employé et l’organisation peuvent avoir des problèmes.

Conseils de base pour éviter les « dérives de configuration »

De l’exemple que nous avons cité ci-dessus, nous pouvons extraire quelques recommandations. La première consiste à documenter tout ce qui fait référence au développement de l’application ou du service. Cependant, cela n’est pas fermé aux procédures générales ou aux manuels d’instructions. Cela doit également couvrir toutes les améliorations et modifications qui doivent être apportées à l’application. C’est comme avoir un journal de toutes les connexions à une certaine base de données ou à toute autre application.

Cette documentation doit rendre compte en détail de toutes les modifications apportées, de leurs impacts. Il doit également inclure les exigences à remplir pour bénéficier de la mise à jour, entre autres informations. Malheureusement, la pratique de la documentation  est l’une des moins ciblées. Cependant, il commence à prendre quelque chose d’important en cas d’événements tels que des audits ou des incidents de sécurité.

En mettant l’accent sur la sécurité, vous devez surveiller de près les informations d’identification de l’administrateur. On pourrait penser qu’un utilisateur avec des autorisations d’administrateur ne devrait pas utiliser ses autorisations en question pour une activité malveillante. Cependant, nous avons expliqué ci-dessus comment l’élévation des privilèges est un allié important pour la configuration de dérive.