Résumé VII








télécharger 1.18 Mb.
titreRésumé VII
page14/33
date de publication02.07.2017
taille1.18 Mb.
typeRésumé
ar.21-bal.com > loi > Résumé
1   ...   10   11   12   13   14   15   16   17   ...   33

6.4 Applications de gestion de réseau


Compte tenu de l'architecture de sécurité examinée au § 2.4, il est impératif de sécuriser le trafic dans le plan de gestion. Ce trafic est utilisé pour surveiller et contrôler le réseau de télécommunication. Le trafic de gestion est généralement classé dans différentes catégories en fonction des informations requises pour exécuter les fonctions de gestion des défauts, de la configuration, de la qualité de fonctionnement, de la comptabilité et de la sécurité. La gestion de la sécurité concerne à la fois l'établissement d'un réseau de gestion sécurisé et la gestion de la sécurité des informations liées aux trois plans de sécurité et aux trois couches de sécurité de l'architecture de sécurité. Le deuxième point est décrit dans le présent paragraphe.

Traditionnellement, dans le réseau de télécommunication, le trafic de gestion est souvent transmis dans un réseau distinct qui achemine uniquement le trafic de gestion de réseau et non le trafic des utilisateurs. Ce réseau, souvent appelé réseau de gestion des télécommunications (RGT), est décrit dans la Rec. UIT T M.3010. Le RGT est séparé et isolé de l'infrastructure du réseau public de sorte que les perturbations dues à des menaces de sécurité dans le plan d'utilisateur final du réseau public ne s'étendent pas au RGT. Compte tenu de cette séparation, il est relativement facile de sécuriser le trafic du réseau de gestion car l'accès au plan de gestion est restreint aux administrateurs de réseau autorisés et le trafic est restreint aux activités de gestion valables. Avec la mise en place des réseaux de prochaine génération, le trafic des applications d'utilisateur final risque parfois d'être combiné au trafic de gestion. Cette approche, fondée sur une seule infrastructure de réseau intégrée, permet de minimaliser les coûts mais pose bon nombre de nouveaux problèmes de sécurité. Les menaces dans le plan d'utilisateur final constituent alors des menaces pour les plans de gestion et de commande. Le plan de gestion devient alors accessible à une multitude d'utilisateurs finaux et de nombreux types d'activités malveillantes deviennent possibles.

Pour pouvoir offrir une solution complète de bout en bout, toutes les mesures de sécurité (par exemple contrôle d'accès, authentification) doivent être appliquées à chaque type d'activité de réseau (c'est-à-dire activité du plan de gestion, activité du plan de commande et activité du plan d'utilisateur final) concernant l'infrastructure du réseau, les services de réseau et les applications de réseau. Il existe un certain nombre de Recommandations de l'UIT T qui portent tout particulièrement sur l'aspect de sécurité du plan de gestion en ce qui concerne les éléments de réseau (NE, network element) et les systèmes de gestion (MS, management system) qui font partie de l'infrastructure du réseau.

Comme décrit ci-dessus, de nombreuses normes visent à sécuriser les informations de gestion nécessaires au maintien de l'infrastructure des télécommunications, mais un autre domaine qui relève de la gestion concerne les environnements dans lesquels différents fournisseurs de services doivent interagir pour offrir des services de bout en bout, par exemple une ligne louée entre des abonnés se trouvant de part et d'autre d'une frontière géographique ou pour des organismes de réglementation ou des organismes publics en vue d'assurer le retour à la normale après une catastrophe.

6.4.1 Architecture de gestion de réseau


L'architecture permettant de définir la gestion d'un réseau de télécommunication est définie dans la Rec. UIT T M.3010 et l'architecture physique est représentée sur la Figure 6 11. Le réseau de gestion définit des interfaces qui déterminent les échanges requis pour assurer les fonctions OAM&P à différents niveaux.



Figure 6 11 – Exemple d'architecture physique (M.3010)
Les exigences de sécurité varient d'une interface à l'autre. L'interface Q se trouve dans un seul domaine administratif tandis que l'interface X se trouve entre différents domaines administratifs qui peuvent appartenir à différents fournisseurs. Des services de sécurité sont nécessaires pour les deux interfaces, mais les contre-mesures requises pour l'interface X sont plus robustes. La Rec. UIT T M.3016.0 fournit un aperçu général et un cadre qui identifient les menaces de sécurité concernant un  RGT. Dans la série M.3016, la Rec. UIT T M.3016.1 donne des détails sur les exigences de sécurité, la Rec. UIT T M.3016.2 décrit les services de sécurité et la Rec. UIT T M.3016.3 définit des mécanismes de sécurité permettant de faire face aux menaces dans le contexte de l'architecture fonctionnelle du RGT, décrite dans la Rec. UIT T M.3010. Comme les exigences n'ont pas besoin d'être toutes prises en charge par les diverses organisations de normalisation, la Rec. M.3016.4 contient un formulaire permettant de créer des profils des exigences, des services et des mécanismes de sécurité, ces profils pouvant être utilisés pour assurer la conformité à la politique de sécurité propre à une organisation. La Rec. UIT T M.3320 traite des aspects propres à l'interface X. Les aspects de protocole relatifs aux différentes couches de communication sont spécifiés dans les Rec. UIT T Q.811 et Q.812.

Lorsqu'on examine la sécurité dans le contexte de la gestion, deux facettes sont à prendre en considération. La première concerne le plan de gestion pour une activité de bout en bout (par exemple services de téléphonie IP). L'activité de gestion consistant à administrer les utilisateurs doit être réalisée de manière sécurisée. On parle de sécurité des informations de gestion échangées sur le réseau pour le déploiement d'une application de bout en bout. La deuxième facette est la gestion des informations de sécurité. Quelle que soit l'application (par exemple téléphonie IP ou activité de signalisation de dérangement entre deux fournisseurs de services), des mesures de sécurité telles que l'utilisation de clés de chiffrement doivent aussi être gérées. On parle souvent de gestion des informations de sécurité. L'infrastructure PKI définie au paragraphe précédent est un exemple de cette facette. La Rec. UIT T M.3400 définit un certain nombre de fonctions liées à ces deux facettes.

Sur la base du cadre défini dans la Rec. UIT-T X.805, plusieurs Recommandations portant sur des fonctions de gestion sont disponibles pour les trois cellules du plan de gestion (voir la Figure 2 1). Les paragraphes qui suivent illustrent certaines de ces Recommandations et montrent comment les besoins de sécurité sont pris en considération. En plus des Recommandations relatives aux trois cellules du plan de gestion, il en existe d'autres qui définissent des services génériques ou communs, par exemple l'envoi d'alarme en cas de violation de sécurité physique, des fonctions d'audit et des modèles d'infor­mation définissant des niveaux de protection pour différentes cibles (c'est-à-dire les entités de gestion).

6.4.2 Intersection du plan de gestion et de la couche infrastructure


Cette cellule concerne la sécurisation de l'activité de gestion des éléments d'infrastructure du réseau, à savoir les éléments de commutation et de transmission et les liaisons entre ces éléments ainsi que les systèmes d'extrémité tels que les serveurs. Les activités telles que la configuration d'un élément de réseau doivent par exemple être réalisées par un utilisateur autorisé. Une connectivité de bout en bout peut être envisagée en termes de réseaux d'accès et de réseaux centraux. Différentes technologies peuvent être employées dans ces réseaux. Des Recommandations ont été élaborées pour les deux types de réseau (réseau d'accès et réseau central). On prend ici l'exemple du réseau optique passif à large bande (BPON, broadband passive optical network) utilisé comme réseau d'accès. L'administration des privilèges des utilisateurs pour un tel réseau d'accès est définie au moyen de la méthodologie de modélisation unifiée dans la Rec. UIT T Q.834.3 et l'échange de gestion utilisant l'architecture de courtier de requêtes pour objets communs (CORBA, common object request broker architecture) est spécifié dans la Rec. UIT-T Q.834.4. L'interface décrite dans ces Recommandations est l'interface Q illustrée sur la Figure 6 11. Elle est appliquée entre le système de gestion des éléments et le système de gestion du réseau. Le système de gestion des éléments sert à gérer les différents éléments de réseau et a donc connaissance des détails internes des architectures matérielle et logicielle des éléments d'un ou de plusieurs fournisseurs et le système de gestion du réseau réalise les activités au niveau du réseau de bout en bout et couvre les systèmes de gestion de plusieurs fournisseurs. La Figure 6 12 montre les divers objets utilisés pour créer, supprimer, attribuer et utiliser des informations de contrôle d'accès pour les utilisateurs du système de gestion des éléments. La liste de permissions des utilisateurs contient, pour chaque utilisateur autorisé, la liste des activités de gestion qui sont permises. Le gestionnaire de contrôle d'accès vérifie l'identité et le mot de passe de l'utilisateur de l'activité de gestion et autorise l'accès à la fonctionnalité figurant dans la liste de permissions.



Figure 6 12 – Administration des privilèges des utilisateurs (Q.834.3)


6.4.3 Intersection du plan de gestion et de la couche services


L'intersection entre le plan de gestion et la couche services concerne la sécurisation des activités de surveillance et de contrôle des ressources de réseau configurées pour l'offre de services par le fournisseur de services. Les Recommandations de l'UIT T portent sur deux aspects de cette intersection. Le premier aspect consiste à veiller à ce que des mesures de sécurité appropriées soient disponibles pour les services qui sont disponibles dans le réseau (par exemple veiller à ce que seuls des utilisateurs valables soient autorisés à exécuter les opérations associées à la fourniture d'un service). Le second aspect consiste à définir les échanges administratifs et de gestion qui sont valables. Cette définition facilitera la détection des violations de sécurité. En cas de violations de sécurité, celles-ci sont souvent gérées au moyen de systèmes de gestion spécifiques.

Un exemple de Recommandation portant sur le premier aspect, l'activité de gestion d'un service, est la Rec. UIT T M.3208.2 sur la gestion de connexion. Un client du service de gestion de connexion qui possède des liaisons préconfigurées utilise ce service pour former une connexion par circuits loués de bout en bout. Ce service de gestion de connexion permet à un abonné de créer/activer, modifier et supprimer des circuits loués dans les limites des ressources préconfigurées. Comme l'utilisateur fournit

la connectivité de bout en bout, il est nécessaire de garantir que seuls les utilisateurs autorisés peuvent exécuter ces opérations. Les dimensions de sécurité définies pour l'activité de gestion associée à ce service font partie des huit dimensions examinées au § 2.4. Ce sont: authentification d'entité homologue, contrôle d'intégrité des données (afin d'empêcher toute modification non autorisée des données en transit) et contrôle d'accès (pour garantir qu'un abonné n'accède pas de façon malveillante ou accidentelle aux données d'un autre abonné).

La Rec. UIT T M.3210.1 est un exemple de Recommandation qui définit les activités administratives associées au plan de gestion pour les services hertziens. Elle correspond au second aspect examiné ci dessus.

Dans un réseau hertzien, lorsque les utilisateurs se déplacent entre leur réseau de rattachement et un réseau visité, ils peuvent traverser différents domaines administratifs. Les services définis dans la Rec. UIT T M.3210.1 décrivent comment le domaine de gestion des fraudes du réseau de rattachement collecte les informations appropriées concernant un abonné une fois que celui-ci est enregistré dans un réseau visité. Les scénarios a) et b) de la Figure 6 13 illustrent le déclenchement de l'activité de gestion de surveillance respectivement par le réseau de rattachement et par le réseau visité. Le système de détection des fraudes du réseau de rattachement demande des informations sur les activités d'un abonné qui s'enregistre dans un réseau visité jusqu'à ce que cet abonné quitte le réseau ou annule son enregistrement dans ce réseau. Des profils d'utilisation peuvent alors être élaborés sur la base des relevés d'appel et de l'analyse au niveau du service ou pour un abonné. Le système de détection des fraudes peut ensuite procéder à une analyse et produire des alarmes appropriées pour les compor­tements frauduleux.


Figure 6 13 – Gestion des fraudes pour les services hertziens
(Rec. UIT T M.3210.1)


6.4.4 Intersection du plan de gestion et de la couche application


La troisième cellule, correspondant à l'intersection du plan de gestion et de la couche application, concerne la sécurisation des applications d'utilisateur final fondées sur le réseau. Les applications telles que la messagerie et les services d'annuaire sont définies dans les Recommandations des séries X.400 et X.500.

Une autre catégorie d'applications pour lesquelles les activités de gestion doivent être sécurisées correspond aux applications de gestion proprement dites. Cette déclaration, d'apparence obscure, sera mieux comprise à l'aide d'exemples. Pour ces applications, le personnel de gestion (d'exploitation) faisant partie de l'administration du fournisseur de service représente les utilisateurs finaux. Prenons le cas où un fournisseur de service utilise les services de connexion d'un autre fournisseur pour offrir un service de connectivité de bout en bout. Suivant l'environnement réglementaire ou le marché considéré, certains fournisseurs de services peuvent offrir des services d'accès et d'autres, appelés opérateurs intercentraux, peuvent offrir une connectivité longue distance. Les opérateurs intercentraux louent des services d'accès auprès du fournisseur local pour assurer la connectivité de bout en bout entre des endroits géographiques différents. En cas de perte de service, il est fait appel à une application de gestion appelée administration des dossiers de dérangement afin de signaler les dérangements entre systèmes de gestion. L'utilisateur de ces systèmes et de l'application proprement dite a besoin d'une autorisation pour pouvoir signaler des dérangements concernant les services. Les systèmes et utilisateurs autorisés doivent prendre les mesures qui s'imposent pour extraire l'état des dérangements signalés. La Figure 6 14 illustre les interactions qui doivent être réalisées de manière sécurisée. De manière analogue à l'administration des boîtes vocales pour l'application de messagerie électronique, les privilèges d'accès sont administrés afin d'éviter tout accès non autorisé aux dossiers de dérangement. Un fournisseur de services est autorisé à signaler uniquement des dérangements concernant les services qu'il loue et non des dérangements concernant les services loués par un fournisseur différent.



Figure 6 14 – Création d'un dossier de gestion de dérangement
(Rec. UIT T X.790)


La Rec. UIT T X.790 définit cette application de gestion et utilise des mécanismes tels que la liste de contrôle d'accès et l'authentification bidirectionnelle pour sécuriser les activités. Cette application a été implémentée et déployée sur la base de cette Recommandation conjointement avec les mécanismes de sécurité applicables à l'authentification.

6.4.5 Services communs de gestion de la sécurité


Les Rec. UIT T X.736, X.740 et X.741 définissent des services communs qui s'appliquent aux trois  cellules du plan de gestion lorsque le protocole commun d'informations de gestion (CMIP, common management information protocol ) est utilisé à l'interface. Les services définis dans ces Recommandations sont brièvement décrits ci-après. Il est à noter que toutes ces fonctions sont bien évidemment considérées comme correspondant à des activités dans le plan de gestion.

6.4.5.1 Fonction de signalisation des alarmes de sécurité:  d'une manière générale, la signalisation des alarmes est une fonction essentielle dans les interfaces de gestion. Lorsqu'une défaillance est détectée, résultant d'un problème opérationnel (défaillance de l'ensemble de circuits) ou d'une violation de la politique de sécurité, une alarme est communiquée au système de gestion. Les rapports d'alarme incluent un certain nombre de paramètres, de sorte que le système de gestion puisse déterminer le motif de la défaillance et prendre une mesure corrective. Les paramètres relatifs à un événement donné incluent un champ obligatoire appelé type d'événement et un ensemble d'autres champs appelés informations d'événement. Ces derniers champs contiennent des informations telles que la gravité de l'alarme, les motifs probables de déclenchement de l'alarme, le détecteur de la violation de sécurité, etc. Les motifs de déclenchement des alarmes sont associés aux types d'événement comme indiqué dans le Tableau 6-2.

Tableau 6 2 – Motifs de déclenchement des alarmes de sécurité


Type d'événement

Motifs de déclenchement
de l'alarme de sécurité


Violation de l'intégrité


Information dupliquée
Information manquante
Détection de modification d'information
Information hors séquence
Information inattendue

Violation opérationnelle


Refus de service
Hors service
Erreur de procédure
Raison non spécifiée

Violation physique


Altération frauduleuse du câble
Détection d'intrusion
Raison non spécifiée

Violation de service ou de mécanisme de sécurité


Echec d'authentification
Atteinte à la confidentialité
Echec de non-répudiation
Tentative d'accès non autorisée
Raison non spécifiée

Violation du domaine temporel


Information tardive
Mot de passe périmé
Activité en dehors de l'horaire





On trouvera davantage d'explications sur ces motifs de déclenchement des alarmes dans la Rec. UIT T X.736. Plusieurs de ces motifs ont trait aux menaces examinées dans des paragraphes précédents.

6.4.5.2 Fonction de journal d'audit de sécurité:  pour qu'un gestionnaire de la sécurité puisse enregistrer les violations de sécurité et les conserver dans un journal d'audit, la Rec. UIT T X.740 identifie un certain nombre d'événements à consigner dans un journal d'audit. Il s'agit des connexions, des déconnexions, des utilisations de mécanismes de sécurité, des opérations de gestion et de la comptabilisation de l'utilisation. Le modèle considéré utilise le mécanisme de journalisation défini dans la Rec. UIT T X.735, un journal général pour enregistrer tous les événements produits au niveau du système géré. Dans le cadre de la fonction de journal d'audit, on définit deux événements se rapportant à des violations de sécurité: le rapport de service et le rapport d'utilisation. Le rapport de service concerne la fourniture, le refus ou la reprise d'un service. Le rapport d'utilisation sert à indiquer qu'un enregistrement contenant des données statistiques relatives à la sécurité a été créé. Comme pour chaque événement, un certain nombre de valeurs de motif ont été définies pour le rapport de service (par exemple demande de service, refus de service, échec de service, reprise de service, etc.). De nouveaux types d'événement pourront être définis si nécessaire car les deux types indiqués dans la Recommandation ne seront peut-être pas suffisants dans l'avenir.

6.4.5.3 La Rec. UIT T X.741 définit de façon très détaillée le modèle associé à l'attribution d'un certain contrôle d'accès aux diverses entités gérées. Les définitions relatives au contrôle d'accès données dans cette Recommandation permettent notamment de satisfaire aux exigences suivantes: les informations de gestion sont protégées contre toute création, suppression et modification non autorisées, les opérations autorisées relatives aux entités sont compatibles avec les droits d'accès de ceux qui sont à l'origine des opérations et la transmission d'informations de gestion à des destinataires non autorisés est interdite. Divers niveaux de contrôle d'accès sont définis pour respecter les exigences susmentionnées. Pour les opérations de gestion, les dispositions énoncées dans la Recommandation facilitent la mise en place de restrictions d'accès à plusieurs niveaux: l'entité gérée dans son ensemble, les attributs de l'entité, les valeurs des attributs, le contexte de l'accès et les actions au niveau de l'entité. Un certain nombre de mécanismes tels qu'une liste de contrôle d'accès, fondée sur des capacités, fondée sur des étiquettes et fondée sur des contextes ont été définis et une politique de contrôle d'accès peut appliquer un ou plusieurs de ces mécanismes. Dans ce modèle fondé sur une politique et des informations de contrôle d'accès (ACI, access control information), une décision est prise concernant l'autorisation ou non de l'opération demandée. Les informations ACI sont par exemple constituées de règles, de l'identité du demandeur, des identités des cibles auxquelles l'accès est demandé, d'informations relatives à l'authentification du demandeur, etc. Le modèle est très riche en fonctionnalités et, dans une application donnée, les capacités peuvent ne pas être toutes requises.

6.4.5.4 Services de sécurité fondés sur l'architecture CORBA:  tandis que les Recommandations UIT T de la série X.700 reposent sur l'utilisation du protocole CMIP comme protocole aux interfaces de gestion, il existe d'autres tendances dans le secteur, visant à introduire l'utilisation d'un protocole, de services et de modèles d'objet fondés sur le courtier de requête pour objets communs pour les interfaces de gestion. La Rec. UIT T Q.816 définit un cadre pour l'utilisation de ces services dans le contexte des interfaces de gestion. En ce qui concerne la prise en charge des exigences de sécurité pour ces interfaces, cette Recommandation renvoie à la spécification de l'OMG relative aux services de sécurité communs.
1   ...   10   11   12   13   14   15   16   17   ...   33

similaire:

Résumé VII iconRésumé VII

Résumé VII iconRegards VII environnement

Résumé VII iconУрок – экскурсия по теме: «Paris et ses curiosités» в VII классе
Развитие монологической речи учащихся (Учебная ситуация: «Paris et ses curiosités»)

Résumé VII iconRésumé

Résumé VII iconRésumé 1

Résumé VII iconRésumé : 3

Résumé VII iconRésumé

Résumé VII icon[Tapez le résumé du document ici. IL s'agit généralement d'une courte...
...

Résumé VII iconRésumé en Français

Résumé VII iconRésumé Théorique








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com