Règle de sécurité numéro un : Vous le violez probablement en ce moment même
Vous avez désormais suffisamment entendu la règle de sécurité zéro pour la connaître par cœur . Vous le connaissez par cœur, n'est-ce pas ?
Juste au cas où, laissez-moi vous rafraîchir la mémoire :
TU NE FERAS PAS CONFIANCE AUX INFORMATIONS DES UTILISATEURS. JAMAIS.
Excellent. Maintenant que nous avons établi cette règle fondamentale et que nous l’avons mise en pratique, parlons de la règle de sécurité numéro un. Car comme vous l’avez peut-être deviné, il existe plus d’une règle en matière de sécurité. Bon, passons à la première règle, d’accord ?
RÈGLE DE SÉCURITÉ N°1 : TU NE CODERAS PAS EN DUR TES IDENTIFIANTS. JAMAIS.
À l’ère du contrôle d’accès via la tokenisation (populaire pour les API) et de l’identité fédérée, cette règle est rarement enfreinte pour les applications publiques. C’est à l’intérieur de l’organisation que cette règle est souvent enfreinte et ignorée. Et cela devient rapidement un problème à mesure que NetOps accélère son utilisation des scripts et de l'automatisation pour faire sa part afin d'optimiser l'informatique en soutien aux initiatives de transformation numérique de leur organisation.
Permettez-moi d’illustrer mon propos avec un exemple très concret que j’ai trouvé sur Internet. Je dis un, car je n’ai ni le temps ni la bande passante pour fournir une liste exhaustive. Cette pratique est tellement répandue.
Sur votre droite, vous verrez une erreur de sécurité extrêmement courante : des informations d'identification codées en dur et en texte clair. Il n’y a même pas un commentaire reconnaissant que cela est inacceptable dans un environnement de travail, ni un hochement de tête indiquant la nécessité d’utiliser une méthode d’authentification plus sécurisée.
Cela me trouble profondément dans le contexte du côté NetOps car le rayon d’explosion est considérablement plus grand lorsque vous jouez avec le réseau partagé de l’entreprise.
L’une des raisons pour lesquelles nous constatons ce type de problème de sécurité est que, même s’il est vrai que NetOps adopte l’automatisation, il ne l’adopte pas nécessairement de manière stratégique. Nous constatons qu’un pourcentage important de professionnels NetOps adoptent Python et le combinent avec une méthode traditionnelle de configuration et de gestion basée sur CLI.
Tout comme ils saisissent leurs informations d’identification sur la ligne de commande, ils insèrent ces mêmes informations d’identification dans un script et c’est tout.
En fin de compte, cela deviendra un problème. Nous verrons quelqu’un profiter de cette pratique et cela restera dans nos fils d’actualité pendant des jours. Parce que ce genre de chose s’est déjà produit. Vous vous souvenez de OneLogin ? Même s'ils ne stockaient pas de scripts avec des informations d'identification, ils stockaient des fichiers avec des informations d'identification. Vous pouvez imaginer le désordre que cela a créé.
Le fait est que NetOps peut se sentir assez confiant en mettant les informations d’identification de la ligne de commande dans un script, mais où finit ce script ? Est-ce que c'est géré comme ça devrait l'être ? Vous aimez l’infrastructure en tant que code ? Est-il versionné et conservé dans un référentiel ?
Vous vous souvenez peut-être d’une enquête communautaire Network to Code qui a montré un taux d’adoption élevé parmi les NetOps pour (attendez…) Github.
Alors demandons-nous : où se trouve notre référentiel ? Est-ce hors site ? Sur place ? Comment est-il protégé et quel est le rayon d'explosion si quelqu'un met la main dessus ?
Nous devons, pour maintenir et servir l'entreprise, faire évoluer nos opérations via des scripts et l'automatisation. NetOps doit évoluer dans cette direction, mais il ne devrait pas le faire sans considérer sérieusement les ramifications des informations d’identification en texte clair stockées, eh bien, n’importe où.
Au minimum, les scripts doivent nécessiter la saisie d'informations d'identification lors de leur invocation. Les informations d’identification ne doivent jamais être stockées dans un fichier ou dans un script , et certainement jamais en texte brut. Idéalement, vous utiliseriez une solution de gestion des informations d’identification plus avancée pour forcer l’authentification et utiliser la tokenisation dans les scripts internes. Mais je sais qu’à l’heure actuelle, nous en sommes seulement aux prémices de l’adoption massive de l’automatisation dans NetOps, et nous devons procéder étape par étape.
Dans cet esprit, exigez au moins des informations d’identification lors de l’invocation. Si cela s’avère trop difficile avec votre implémentation actuelle, il est peut-être temps de prendre du recul et d’examiner votre stratégie globale d’automatisation informatique. La première question étant : en avez-vous un ? Ou bien ce que vous faites est-il une réponse tactique (et primaire) aux demandes de l’entreprise ?
Parce que la solution à long terme ne devrait pas – ne peut pas – consister en des informations d’identification en texte brut dans chaque script. Outre le risque de sécurité évident, pensez à la dette technique que vous encourez. Si vous devez modifier vos identifiants, vous devez les modifier partout . Il faut du temps et des efforts pour les retrouver. Vous n'avez probablement pas le temps ni les efforts nécessaires, sinon vous ne seriez pas si désireux de gagner du temps en adoptant l'automatisation en premier lieu.
Alors s’il vous plaît, ne violez pas la règle de sécurité numéro un. Soyez plus sûr et plus intelligent que ça. L’automatisation ne doit pas être une réponse tactique aux exigences d’échelle et de vitesse. Cela devrait être – et c’est – stratégique, ce qui signifie être plus attentif aux ramifications à long terme de la manière dont vous le mettez en œuvre.