Les systèmes de gestion de la sécurité (SGS) font le lien entre les exigences de sécurité et le domaine d'application technique. D'un côté, le SGS doit permettre à l'administrateur sécurité de traduire les exigences de sécurité en configurations de sécurité (appelé ici le processus de déploiement). De l'autre, il doit lui fournir des mécanismes de supervision (tels que des SIEM, IDS, fichiers de logs, etc.) afin de vérifier que l'état courant du système est toujours conforme aux exigences de sécurité (appelé ici processus de supervision). Aujourd'hui, garantir que les exigences de sécurité sont respectées nécessite une intervention humaine. En effet, les processus de déploiement et de supervision ne sont pas reliés entre eux. Ainsi, les SGS ne peuvent garantir que les exigences de sécurité sont toujours respectées lorsque le comportement du système change. Dans le cadre du projet européen PREDYKOT, nous avons tenté de boucler la boucle de gestion en intégrant les informations sur le changement de comportement du système et en les injectant dans le processus de déploiement. Cela permet de faire appliquer des mesures de sécurité dynamiques en fonction des changements de comportement du système. Toutefois, il existe diverses approches pour exprimer et mettre en œuvre des politiques de sécurité. Chaque solution de gestion est dédiée à des problématiques de gestion des autorisations ou à celles des configurations de sécurité. Chaque solution fournit son propre langage de politique, son propre modèle architectural et son propre protocole de gestion. Or, il est nécessaire de gérer à la fois les autorisations et les configurations de sécurité de manière unifiée. Notre contribution porte principalement sur trois points : Le retour d'information de supervision : Le processus de supervision capture le comportement dynamique du système au travers d'évènements. Chaque évènement transporte peu de sens. Nous proposons de considérer non pas les évènements individuellement mais de les agréger pour former des situations afin d'amener plus de sémantique sur l'état du système. Nous utilisons ce concept pour relier les exigences de sécurité, les changements dans le système et les politiques de sécurité à appliquer. Un nouvel agent, appelé gestionnaire de situations, est responsable de la gestion du cycle de vie des situations (début et fin de situation, etc.) Nous avons implanté cet agent grâce à la technologie de traitement des évènements complexes. Expression de la politique : Nous proposons d'utiliser le concept de situation comme élément central pour exprimer des politiques de sécurité dynamiques. Les décisions de sécurité peuvent être alors automatiquement dirigées par les situations sans avoir besoin de changer la règle courante. Nous appliquons l'approche de contrôle d'accès à base d'attributs pour spécifier nos politiques. Cette approche orientée par les situations facilite l'écriture des règles de sécurité mais aussi leur compréhension. De plus, ces politiques étant moins techniques, elles sont plus proches des besoins métiers. L'architecture de gestion : Nous présentons une architecture de gestion orientée événement qui supporte la mise en œuvre de politiques de sécurité dirigées par les situations. Considérer les messages de gestion en terme d'évènements, nous permet d'être indépendant de tout protocole de gestion. En conséquence, notre architecture couvre de manière unifiée les approches de gestion des autorisations comme des configurations (obligations) selon les modèles de contrôle de politiques en externalisation comme en approvisionnement. De plus, les agents de gestion sont adaptables et peuvent être dynamiquement améliorés avec de nouvelles fonctionnalités de gestion si besoin. Notre cadriciel a été complètement implanté et est conforme au standard XACMLv3 d'OASIS. Enfin, nous avons évalué la généricité de notre approche à travers quatre scénarii. / A Security Management System (SMS) connects security requirements to the technical application domain. On the one hand, an SMS must allow the security administrator/officer to translate the security requirements into security configurations that is known as the enforcement process. On the other hand, it must supply the administrator/officer with monitoring features (SIEM, IDS, log files, etc.) to verify that the environments' changes do not affect the compliance to the predefined security requirements known as the monitoring process. Nowadays, guarantying security objectives requires a human intervention. Therefore, the SMS enforcement process is disconnected from the monitoring process. Thus, an SMS cannot dynamically guarantee that security requirements are still satisfied when environment behavior changings are observed. As part of the European project PREDYKOT, we have worked on closing the management loop by establishing a feedback on the dynamic behavior, captured from the environment, to impact the enforcement process. As a result, expressing and applying a dynamic security policy will be possible. However, many policy expression and enforcement approaches exist currently. Each security management solution is dedicated to some specific issues related to authorization or to system/network management. Each solution provides a specific policy language, an architectural model and a management protocol. Nevertheless, closing the management loop implies managing both authorizations and system/network configurations in a unified framework. Our contribution tackles the following three main issues: Feedback: The monitoring process captures the highly dynamics of the behavior through events. However, each event is not semantically associated with other events. We propose to get more semantics about behavior's changings thus introducing the concept of "situation" to be dealt with in security management applications. This concept aggregates events and links relevant security requirements, relevant behavior changes, and relevant policy rules. A new management agent, called the situation manager, has been added. The latter is responsible for the management process of the situations lifecycle (situation beginning and ending, etc.). We implement this software module using the complex event processing technology. Policy Expression: We propose to specify dynamic security policies oriented by situations. By doing so, the expression of the security policy rules becomes simpler to understand, easier to write and closer to the business and security needs. Hence, each relevant situation orients automatically the policy evaluation process towards a new dynamic decision that doesn't require updating the policy rules. We apply the attribute-based expression approach because of its ability to represent everything through attribute terms, which is a flexible way to express our dynamic policy rules. Enforcement Architecture: we propose a unified and adaptive architecture that supports situations-oriented policies enforcement. We choose to build an event-driven architecture. Exchanging management messages in terms of events allows our architecture to be independent from the management protocols. Thus, it covers in a unified way authorizations as well as configurations management approaches considering both provisioning and outsourcing policy control models. In addition, management agents are adaptable and can be upgraded dynamically with new management functionalities. Our framework has been implemented and is compliant with the OASIS XACMLv3 standard. Finally, we evaluated our contributed according to four different scenarios to prove its generic nature.