Sécurité : une approche dans la durée avant tout

On peut partir d’un faible niveau de sécurité globale, arriver à un niveau acceptable, voire même à un bon niveau, pratiquement sans avoir fait progresser son approche du sujet. L’opération coup de poing, dans un mode de correction uniquement, si elle est indispensable, n’est pas une approche globale. Méfiance même, elle peut donner « l’impression de », créer du relâchement, ce qui n’est jamais la bonne solution.

Alors comment, en permanence, traiter cette sécurité. Voilà une approche orientée Microsoft Azure, qui donne de très bons résultats, qui demande du temps, mais qui traite le sujet en profondeur.

L’objectif est d’identifier ce qui ne va pas, de le traiter (parfois en mode coup de poing), mais surtout, de l’auditer au fil du temps, et plus encore, d’en interdire la reproduction.

Ce qui a déjà été mal fait, qui a été corrigé, NE DOIT PLUS ETRE POSSIBLE !

Une évidence sans doute, mais un travail de fond indispensable.

Liste non exhaustive 

Les points importants sont les suivants, même si la liste n’est pas exhaustive.

– L’indentification ou audit

– La correction

– La mise sous surveillance

– L’alignement des automatismes de déploiement

– L’interdiction (il faut savoir le dire)

– La gestion des exceptions

Audit & Connaissance du parc

L’audit est nativement disponible, dans une forme simple. Il ne nécessite pas forcément la présence d’un outil de SIEM (Gestion des informations et des événements de sécurité), même si c’est un plus. Directement depuis le portail, l’utilisation d’Azure Advisor donne déjà une très bonne vue de la sécurité, de ce qui est déployé sur les environnements. On y trouve les recommandations, classées par risques, pour l’intégralité des ressources déployées. Ainsi, on peut se concentrer sur les risques les plus élevés, puis poursuivre sur ceux qui présentent un peu moins de criticité.

Mieux même, il est parfois possible de corriger directement depuis le menu du portail pour régler massivement les points de sécurité. Attention toutefois de bien mesurer l’impact des actions.

Un rappel, Advisor est une fonctionnalité gratuite.

En complément, une initiative Azure va apporter quelques informations complémentaires, particulièrement si l’entreprise doit respecter un benchmark de sécurité. Comme le CIS, le NIST ou même une norme ISO. L’initiative se trouve dans le portail des Policy Azure. L’activation se fait en quelques clics, en mode audit, et les résultats sont connus sous 12 à 24 h, dépendant du nombre de ressources déployées. Voilà pour la phase d’audit, la connaissance du parc.

Correction

Seconde étape dont il a été question plus haut, la correction. Pour cela, il faut utiliser son expérience, suivre les recommandations d’Advisor et s’appuyer sur les documentations éditeurs pour corriger les points de sécurité.

Puis revenir à l’étape précédente d’audit pour mesurer l’impact des corrections. La réévaluation se fait en continu, au fil de l’eau, le niveau de conformité va progresser durant toute la phase de correction.

Alignement du code et des automatismes de déploiement

Etape suivante, la plus consommatrice de temps, l’alignement du code et des automatismes de déploiement. Il y a, de moins en moins d’environnement gérés uniquement depuis le portail, et c’est une bonne chose. Cela garantit en plus de la rapidité des déploiements une bonne homogénéité des ressources, des déploiements reproductibles. Un bémol ? Oui, la correction des configurations et des paramètres doit être intégrée dans le code.

Sans cela, il va y avoir un « glissement » des configurations, le code n’est plus aligné avec la réalité. Cette étape n’est pas facultative. Elle est en lien avec le point suivant, l’INTERDICTION. Car le code est aligné, là, aujourd’hui, mais il doit le rester :

– Pour les prochains déploiements.

– Pour garantir que l’arrivée d’un nouveau service ne va pas créer de nouvelles alertes de sécurité.

Là, pré déploiement, Advisor n’est plus le bon outil. Il ne travaille que post déploiement, il constate.

Initiative & Documentation

L’initiative Azure Policy, le complément dont il est question plus haut, peut couvrir une partie de ces contraintes à venir, mais de façon un peu détournée. Pré déploiement, un service non déployé est … compliant. C’est un peu dommage d’ailleurs. C’est le propre des Policy. Un service inexistant n’apparait pas comme tel dans un résultat d’audit de Policy. Son état est vert, compliant. Un état intermédiaire entre la compliance et la non compliance serait intéressant. Mais ce n’est pas proposé dans le portail. Un jour peut-être.

C’est pour cette raison qu’utiliser les points de la compliance actuelle n’est pas la meilleure solution pour préparer la suite.

Une bonne solution est plutôt de se tourner vers la documentation et de définir dans le LLD (Low Level Design) du nouveau service à déployer les contraintes de sécurité à respecter.

Avant le déploiement ! C’est assez facile puisque très bien documenté. Il faut exploiter la documentation Base de référence de sécurité Azure pour xxx, ou chaque service Azure est détaillé et abordé sous l’angle de la sécurité.

On y trouve le paramétrage à mettre en œuvre, les recommandations et si possible, les Azure Policy qui doivent accompagner le déploiement. Dans l’exemple ci-dessous (vue très partielle des nombreux points obligatoires), qui concerne le déploiement du service Azure Cosmos DB, une Policy « Les comptes Azure Cosmos DB doivent avoir des règles de pare-feu » et une recommandation liée à l’identité « Authentification Azure AD requise pour l’accès au plan de contrôle ».

Vue partielle des nombreux points obligatoires

Des contraintes sont positionnées tôt pour maintenir son niveau de sécurité

Plus les contraintes sont positionnées tôt, plus elles sont efficaces. Et surtout, il est plus facile d’expliquer un blocage de déploiement lorsqu’un nouveau service arrive plutôt que de laisser le premier déploiement se faire avant d’expliquer que finalement, non, ce ne sera pas possible par la suite. Et qu’en plus, il faut corriger ce qui vient d’être déployer sans blocage.

Donc, plus les contraintes sont positionnées tôt, et plus il sera facile de maintenir son niveau de sécurité.

L’interdiction

Il est donc important d’interdire, mais plus facile de parler de ce qui est bloqué pour garantir à une application, à une architecture logicielle qu’elles respectent les bonnes pratiques de sécurisation de ses ressources Azure. Si le design de départ n’est pas aligné sur les contraintes de Policy, alors, il n’est pas bon. Il doit être discuté, expliqué. On n’intègre pas les équipes de sécurisation Azure post architecture, mais bien au début du projet. C’est une habitude à prendre. Ce n’est pas une contrainte forte. Et cela permet aussi de discuter du dernier des 6 points listés en début de sujet. Le traitement des exceptions.

Traitement des exceptions

Il n’y a pas de solution même bien pensée qui va permettre de répondre à 100 % des contraintes d’architecture. Sans chercher trop loin, une localisation autorisée en France centrale / France sud, c’est dans un contexte de développement d’une solution IA une limitation trop importante. Elle ne peut être respectée parce que certains modèles ne sont pas disponibles dans la région France Centrale (voir ci-dessous).

Voilà un cas typique pour lequel il va falloir faire des ajustements sous la forme d’exception. Cela ne concerna pas directement la sécurité, mais c’est un bon exemple de ce que doit être une exception.

Une bonne gestion documentée

Pour assurer une bonne gestion, elle doit être documentée

• Pourquoi ?
• Pour quelle ressource ?
• Pour quelle durée ? Ce point est crucial, les exceptions doivent être réévaluées régulièrement. Parce qu’un service évolue, parce qu’un besoin 2025 n’est peut-être plus un besoin 2026 …etc.

Et, le plus IMPORTANT, en plus de cette documentation statique, la ressource doit être étiquetée (un TAG Azure). Par exemple, avec son numéro d’exception et sa date de validité. C’est indispensable pour conserver un bon niveau d’exploitabilité et garantir que les automatisations existantes / futures sauront identifier dynamiquement ce type de ressources.

Exemple avec la gestion de la sécurité au travers des Policy, en 2 étapes

Une policy, c’est une règle, un filtre d’évaluation. Toutes les ressources doivent être en France centrale / France Sud. Pour une gestion transparente et efficace, une condition basée sur les TAG est ajoutée. Tout sauf ce qui est tagué ExceptionSecu. Bien, c’est donc une gestion automatique de l’exception.

Et pour que la gestion soit assurée de bout en bout, on peut ajouter un service Azure, une Logic App (Application logique) qui va lire une fois par semaine le contenu du TAG et traiter de la fin de validité.

Si la date de fin est atteinte, l’Application Logique envoie sur une canal teams dédié sécurité ou sur une adresse mail d’équipe l’information de la suppression du TAG lors de sa prochaine évaluation. Si l’exception doit être prolongée, le TAG est modifié et prolongé. Si l’exception n’est plus utile, la TAG est supprimée et la ressource sera évaluée lors du prochain contrôle Azure Policy comme une ressource normale. Son état ne sera plus Compliant.

Voilà quelques pistes pour aller au-delà de la simple opération coup de poing dès que sont levées les alertes de sécurité. C’est un investissement de départ non négligeable, mais qui se révèle bien moins consommateur à la cible que la course infinie vers la correction sans autre action.