Celui qui est en charge du développement d'une application ou, s'il participe à ce processus, sait qu'il y a plusieurs procédures à effectuer. Une application, quel qu'en soit le but, est censée subir des changements constants pour la faire fonctionner de mieux en mieux. De même, afin qu'il soit de plus en plus sécurisé et qu'il préserve la confidentialité des données des utilisateurs. Mais que se passe-t-il si tous ces changements entraînent des problèmes? Aujourd'hui, dans cet article, nous parlerons de la question de dérive de configuration .
Chaque fois qu'une application est développée, elle doit subir des changements. Qui se reflètent dans les mises à jour. Ces changements peuvent refléter des améliorations de l'interface utilisateur ou une amélioration de son infrastructure qui permet de meilleures performances. Cependant, il existe un risque que les modifications aient un effet négatif sur l'application. Certains peuvent même le rendre inutile. Cette situation est connue sous le nom de dérive de configuration . Cela entraîne une détérioration des performances globales des applications plutôt que de l'amélioration.
Mais cela ne signifie pas qu'il peut y avoir précisément certains types de mises à jour qui sont ouvertement appliquées afin de générer une telle configuration de dérive. Une série de mauvaises pratiques peut progressivement conduire l'application à diminuer sa qualité de performance 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), il est nécessaire d'avoir des informations d'identification d'administrateur spéciales. Ce développeur n'aime pas l'idée d'avoir des informations d'identification supplémentaires, car en fin de compte, cela implique un temps supplémentaire qui peut réduire le temps nécessaire pour fournir vos modifications à l'application.
Quoi qu'il en soit, ce développeur a les informations d'identification dont il a besoin pour les changements de production qu'il doit apporter. Vous pouvez même modifier vos autorisations et ajoutez ceux dont vous avez besoin pour pouvoir disposer des autorisations d'administrateur via l'interface de gestion des utilisateurs. Apparemment pas de problème puisque ces autorisations d'administrateur ne s'appliquent qu'au serveur auquel le développeur doit accéder.
N'oubliez pas que toute procédure appliquée en production peut se dérouler très bien ou très mal. Et si cela se passe très mal, les utilisateurs sont les principaux concernés. Une situation qui reflète une modification mal appliquée en production 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 aucune intention qui va au-delà de mener à bien son travail en temps opportun, depuis car son projet est très serré.
Mais que se passe-t-il si à la place de cette personne est impliquée un cybercriminel ou un partenaire malveillant? le les déplacements verticaux et élévations de privilèges est l'une des attaques qui ont laissé des séquelles à un réseau, un système et une infrastructure en général. Le pire, c'est que ce type d'attaque est que plusieurs fois, cela passe inaperçu. Et c'est parce que l'utilisateur malveillant effectue toutes les activités de manière masquée, ce qui signifie qu'il passe par des contrôles de sécurité et qu'ils sont détectés comme bénins.
Même si l'utilisateur appliquant une élévation de privilèges n'a pas l'intention de mener une attaque, il peut avoir des problèmes potentiels à d'autres égards. S'il y avait un processus d'audit et que ce type d'activité se reflète, il sera très difficile de le justifier. Et si cela s'avère être quelque chose qui va à l'encontre des politiques ou des réglementations de conformité, le partenaire et l'organisation peuvent avoir des problèmes.
Conseils de base pour éviter toute dérive de configuration
De l'exemple que nous avons cité ci-dessus, nous pouvons extraire quelques recommandations. La première consiste à documenter tout ce qui concerne le développement de l'application ou du service. Cependant, cela n'est pas fermé aux manuels ou instructions de procédure générale. Cela devrait également couvrir toutes les améliorations et modifications qui doivent être apportées à l'application. C'est comme avoir un enregistrer de toutes les connexions à une certaine base de données ou à toute autre application.
Cette documentation doit informer en détail de toutes les modifications apportées, de leurs impacts. Il devrait également inclure les conditions à remplir pour avoir la mise à jour, entre autres données. Malheureusement, la pratique de Documentation est l'un des rares centres d'attention. Cependant, il commence à facturer quelque chose d'important face à des événements tels que des audits ou des incidents de sécurité.
En vous concentrant 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 leurs autorisations en question pour une activité malveillante. Cependant, ci-dessus, nous avons expliqué comment l'escalade de privilèges est un allié important pour la configuration de la dérive.