Gouvernance
La gouvernance de la sécurité, en tant que sous-ensemble de l’approche globale, vise à soutenir les objectifs commerciaux en définissant des politiques et des objectifs de contrôle pour faciliter la gestion des risques. Pour assurer la gestion des risques, suivez une approche à plusieurs niveaux des objectifs de contrôle de sécurité. Chaque niveau s’appuie sur la précédente. La compréhension du modèle de responsabilité partagée AWS est le niveau de base. Ce niveau permet de clarifier ce dont vous êtes responsable côté client et ce dont vous héritez d’AWS. AWS Artifact
Atteignez la plupart de vos objectifs de contrôle au niveau suivant. C’est là que se trouve la capacité à l’échelle de la plateforme. Par exemple, ce niveau inclut le processus de distribution de comptes AWS, l’intégration avec un fournisseur d’identité telle que AWS IAM Identity Center et les contrôles de détection communs. Certains des résultats du processus de gouvernance de la plateforme se trouvent également ici. Lorsque vous souhaitez commencer à utiliser un nouveau service AWS, mettez à jour les stratégies de contrôle de service (SCP) dans le service AWS Organisations afin de fournir les barrières de protection pour l’utilisation initiale du service. Vous pouvez utiliser d’autres SCP pour implémenter des objectifs de contrôle de sécurité communs, souvent appelés « invariants de sécurité ». Il s’agit d’objectifs de contrôle ou de configuration que vous appliquez à plusieurs comptes, unités organisationnelles ou à l’ensemble de l’organisation AWS. Des exemples typiques limitent les régions dans lesquelles l’infrastructure s’exécute ou empêchent la désactivation des contrôles de détection. Ce niveau intermédiaire contient également des politiques codifiées telles que des règles de configuration ou des vérifications dans les pipelines.
Le niveau supérieur est celui où les équipes produit répondent aux objectifs de contrôle. Cela est dû au fait que la mise en œuvre se fait dans les applications contrôlées par les équipes produit. Il peut s’agir d’implémenter la validation des entrées dans une application ou de s’assurer que l’identité passe correctement entre les microservices. Même si l’équipe produit est responsable de la configuration, elle peut toujours hériter de certaines fonctionnalités du niveau intermédiaire.
Quel que soit l’endroit où vous mettez en œuvre le contrôle, l’objectif est le même : gérer les risques. Divers frameworks de gestion des risques s’appliquent à des secteurs, des régions ou des technologies spécifiques. Votre objectif principal : mettre en évidence le risque en fonction de la probabilité et de la conséquence. C’est le risque inhérent. Vous pouvez ensuite définir un objectif de contrôle qui réduit soit la probabilité, soit la conséquence, soit les deux. Puis, avec un contrôle en place, vous pouvez voir quel est le risque qui est le plus susceptible d’en résulter. Il s’agit du risque résiduel. Les objectifs de contrôle peuvent s’appliquer à une ou plusieurs charges de travail. Le diagramme suivant illustre une matrice de risque typique. La probabilité est basée sur la fréquence des événements précédents, et la conséquence est basée sur le coût de l’événement en matière d’argent, de réputation et de durée.
Figure 2 : matrice de probabilité du niveau de risque
