6.11 Le protocole SEP
6.11.6 Le gestionnaire de politique d’accès
6.11.6.1 Principe de fonctionnement
La politique de sécurité d’un système informatique permet de spécifier les actions autorisées dans ce système. Pour contrôler l’accès aux informations sensibles d’un système, une politique de sécurité doit identifier les ressources du système contenant les informations sensibles et les opérations permettant d’accéder à ces informations.
Une politique de sécurité repose sur :
– La définition des ensembles de ses ressources et des opérations permettant d’accéder aux ressources.
– La définition de l’ensemble des règles pour le contrôle d’accès aux ressources. Nous pouvons distinguer entre deux types de sécurité : la sécurité centralisée et la sécurité distribuée. Dans le système centralisé, il existe une unique politique de sécurité prenant en compte l’ensemble des entités du système. La sécurité distribuée se caractérise par la coexistence de nombreuses politiques de sécurité [GGKL89]. L’un des problèmes de ce type de sécurité concerne l’interaction des différents systèmes. Chaque système pouvant avoir ses propres contraintes de sécurité.
SEP propose un mécanisme de fédération des politiques de sécurité au niveau de l’autorité intermédiaire SEP. La fédération des politiques de sécurité permet de :
Garantir que la politique résultante préserve les conditions de sécurité associées à chaque politique initiale.
Dans SEP, chaque serveur application doit définir sa politique de sécurité. Cependant, une IA SEP qui protège plusieurs serveurs doit assurer que la politique d’une application ne réduit pas celle de l’autre. Ainsi, des systèmes distribués ayant une sécurité centralisée interagissent dans un environnement distribué sans réduire le niveau de sécurité de chacun des systèmes.
La politique résultante permet une cohabition avec des politiques plus globales (liées au réseau, à l’entreprise, etc.).
Un modèle de fédération permet une cohabitation de la politique de chaque application et une politique de sécurité plus générale correspondant à la sécurité de l’environnement à protéger.
Dans le cas d’un système SEP distribué (plusieurs serveurs origines), une IA SEP doit assurer la centralisation de la base des politiques de sécurité.
6.11.6.2 Plan et procédure de contrôle
La vérification de l’application de la politique de sécurité consiste à définir un contrôle de sécurité sur la base des politiques de sécurité (DBP) définies par les serveurs origine. Si les serveurs origines sont des entités internes reliées par une IA SEP, un deuxième contrôle de sécurité au niveau du réseau serait nécessaire.
Administrateur réseau
Administrateur du serveur origine et de l’application configuration
Rapport de Sécurité (Vérification de l’accès au réseau)
Politique du réseau
Politique de l’application
Rapport de Sécurité (Vérification de l’accès à l’application)
configuration
Donnée sortante Donnée entrante
Filtrage au niveau des données (certificat d’attribut,
mot-de-passe, etc.) Filtrage par adresse
IP, portes, etc.
Figure 6-27. Procédure de vérification des configurations des machines SEP
Un ensemble d’étapes doit être réalisé afin d’obtenir le résultat escompté, comme illustré à la figure 6-27.
La première étape pour la mise en œuvre du plan de contrôle de sécurité, consiste à centraliser à l’IA SEP la configuration des serveurs origines. Nous nous intéressons aussi aux besoins des administrateurs qui souhaitent contrôler l’ensemble des flux entrants et sortants sur le réseau. Par rapport au serveur d’application demandé par les clients, l’administrateur réseau effectue son premier filtrage en se basant sur les adresses IP source et destination ainsi que le nom de l’application. Une fois ce contrôle effectué, les acteurs SEP commencent à négocier les paramètres de sécurité de chaque application (algorithme de chiffrement, méthode d’authentification, etc.). Ceci constitue un deuxième contrôle effectué au niveau applicatif et dépend des mécanismes d’autorisation de chaque service.
La figure suivante (figure 6-28) montre le modèle relationnel de la base de données DBP. Certaines parties concernant les détails de cette base de données (type et taille des champs, valeurs, etc.) sont reprotées à la partie 5 de l’annexe C.
Dans la figure 6-28 les syntaxes suivantes sont utilisées :
Table 1 → Table 2 : Signifie que Table 2 possède une ou plusieurs instances de la table 1.
CP : Identifie uniquement une table.
In et CEn : Valeur indexée.
Un administrateur doit commencer la configuration de sa base de données DBP à travers les deux tables Mediator et Server. La table Mediator définit la IA installée avec son adresse IP (ip_address), son DNS (ia_name) et son certificat de délégation (delegation_certificate). Pour chaque IA, l’administrateur doit définir un ou plusieurs serveurs d’application SEP. Chaque serveur possède une adresse IP (ip_address) et un nom (server_name). Un serveur SEP peut héberger un ou plusieurs services définis dans la table service. La table service est le centre des relations dans notre base de données. Elle possède un nom (service_name) et un flag (internal). Flag est égal à true si le service est interne à l’entreprise qui doit être protégée par un ensemble de paramètres de sécurité (méthodes d’authentification, messages alarmes, etc.). Si le flag est égal à false, le service est alors un service défini en dehors des frontières réseau
mais qui demande un contrôle de sécurité explicite au niveau des connexions demandées par les clients internes.
Service CP id_service service_name used_port CE1,I2,I1 id_Server internal Service_Alarm CP,I4 id_service_alram CE1,I2,I1 id_alarm CE2,I5,I3 id_service Service_Authentication CP,I4 id_Service_Authentication CE2,I5,I3 id_service CE1,I2,I1 id_authentication max_list Mediator CP,I1 id_ia ia_name ip_address delegated_certificate Service_Parameters CP,I3 id_Service_Parameters CE1,I2,I1 id_service CE2,I5,I4 id_Security_Parameter max_list Network_Filter CP,I3 id_network_politic ip_source ip_destination por_source port_destination CE1,I2,I1 id_application Alarm CP,I1 id_alarm alarm desciption Security_Parameters CP,I1 id_security_parameter cipher_list value exportable Authentication CP,I2 id_authentication Authentication_name Authentication_type value I1 id_application Server CP,I3 id_server Server_name ip_address CE1,I2,I1 id_ia Connection_Trace CP,I4 id_temp I8 session_id ip_s_add ip_d_add ip_ps_add ip_pd_add CE2,I2,I6 id_Service_Authentication CE3,I1,I7 id_Service_Parameters CE1,I3,I5 id_service_alarm data_in data_out
Figure 6-28. Modèle relationnel de la base de données DBP
Un service SEP est relié au trois tables service_alarm, security_parameters et authentication methods. Elles sont initialisées avec leur contenu avant la table service. Dans les implémentations, ces trois tables peuvent être figées durant l’installation de SEP. La table service communique avec ces trois tables à travers des tables intermédiaires qui définissent les paramètres de sécurité pour chaque service. Les trois tables intermédiaires sont :
• service_authenication : définit les méthodes d’authentification qui peuvent être utilisées pour chaque service.
• service_alarm : définit les alarmes nécessaires au bon fonctionnement de chaque service.
• service_parameters : choisit les paramètres de sécurité pour chaque service.
Finalement, une politique au niveau réseau est définie dans la table Network_Filter. A travers la liste des relations déjà établies, cette table peut être utilisée par le Proxy ou le serveur origine (Server).
DBP permet de stocker aussi les différentes connexions effectuées pour chaque service. En effet, la table Connection_trace permet d’identifier les sessions établies vers chaque service, les paramètres de sécurité de chaque service ainsi que l’archivage des données entrante et sortante du système si le service de non répudiation est activé.
6.11.6.3 Délégation à travers les certificats d’attribut
Les certificats d'attributs ont été créés pour résoudre les problématiques des certificats d'identité. En particulier, la notion "de lier une clé à une identité par un certificat" est abandonnée avec les certificats d'attribut. Le rôle d'un certificat est plus général grâce à l'attribution de permissions au possesseur d'une clé. Un certificat d'attribut contient donc un ensemble d’attributs qui donnent des informations sur les privilèges du possesseur du certificat.
Ainsi avec SEP, le serveur origine SEP fournit un certificat d'attribut à la IA SEP pour qu’elle puisse effectuer en son nom des opérations pendant une durée déterminée. Cette opération est plus précisément l’authentification des utilisateurs.
Le format de certificat d’attribut que nous utilisons avec SEP est celui développé dans le projet ICARE [ICARE]. Les certificats ICARE utilisent le format XML-DSIG qui permet d'ajouter une ou plusieurs signatures au même certificat d’attribut [Bern02] [Deme04]. Pour cela, les IAs SEP possèdent un seul certificat d’attribut qui contient la signature de plusieurs serveurs origines avec les rôles délégués par chaque serveur.
En général, le certificat d'attribut est composé de l'identificateur de l'émetteur (serveur origine), de l'identificateur du propriétaire (la IA SEP), des droits à donner (attributs), du temps de validité du certificat et de la capacité de déléguer à un tiers. L’émetteur et le propriétaire sont identifiés par leurs adresses IP, leurs noms de domaine et leurs clés publiques.