Sélection de la langue

Government of Canada / Gouvernement du Canada

Détermination de la robustesse des contrôles de périmètre (ITSP.80.032)

De : Centre canadien pour la cybersécurité

Format de rechange : Détermination de la robustesse des contrôles de périmètre (ITSP.80.032) (PDF, 1.13 Mo)

Avant-propos

Le document Détermination de la robustesse des contrôles de périmètre est un document NON CLASSIFIÉ publié avec l’autorisation du chef du Centre de la sécurité des télécommunications (CST). Les propositions de modifications doivent être envoyées au Centre d’appel du Centre canadien pour la cybersécurité (CCC).

Centre d’appel
contact@cyber.gc.ca
613-949-7048 ou 1-833-CYBER-88

Date d'entrée en vigueur

Le présent document entre en vigueur le 4 mars 2019.

Table des matières

Liste des figures

Liste des tableaux

Liste des annexes

Aperçu

Un des principaux défis pour les praticiens de la sécurité est de s’assurer que le niveau de robustesse est le même pour tous les mécanismes de sécurité protégeant un périmètre donné du domaine de sécurité. Le présent document d’orientation vise à remédier à la situation en fournissant les critères de sélection des exigences relatives à l’assurance et à la force des mécanismes de sécurité cryptographiques, interdomaines et d’authentification. On recommande aux organismes de mettre en pratique ces conseils au moment de considérer ou de développer des solutions pour les systèmes d’information interconnectés dans différents domaines de sécurité, particulièrement si l’un ou plusieurs de ces domaines sont classifiés.

La connexion de domaines de sécurité traitant l’information à différents niveaux de catégorisation sur le plan de la confidentialité, de l’intégrité ou de la disponibilité peut faire peser des risques importants sur la sécurité de l’information. Le principal risque est la divulgation non autorisée de renseignements classifiés d’un domaine de sécurité de niveau supérieur à un domaine de sécurité de niveau inférieur. Par contre, la protection des domaines à intégrité et disponibilité élevées repose également sur la séparation et des flux de données contrôlés. Pour atténuer ces risques, il est impératif de mettre en place les contrôles de robustesse appropriés pour gérer le flux de données entre les différents domaines de sécurité.

Tel qu’il est indiqué à l’Annexe 2 de l’ITSG-33, la robustesse permet de caractériser la force et l’assurance de la sécurité d’un contrôle, d’un service, d’un mécanisme ou d’un produitNote de bas de page 1. Ce concept est particulièrement utile pour décrire les exigences de sécurité du point de vue d’une architecture de haut niveau avant de procéder à leur mise en œuvre à un niveau inférieur. La robustesse permet de définir la force et l’assurance dans un paramètre unique. En d’autres mots, le niveau de robustesse permet à l’architecte de systèmes de formuler les exigences en matière de force et d’assurance relatives à l’architecture de haut niveau sans avoir à préciser les détails du mécanisme utilisé pour fournir une telle force ou les méthodes employées pour obtenir une telle assurance.

Le présent document traite de la protection des domaines de sécurité en fonction de la confidentialité, de l’intégrité et de la disponibilité. Il aborde également deux scénarios de confidentialité spéciaux liés à la restriction de diffusion et à la compartimentation.

Le présent document vise principalement à répondre aux besoins du gouvernement du Canada (GC) en matière de systèmes de sécurité nationale.

Les conseils prodigués dans la présente sont destinés aux praticiens de la sécurité et reposent sur l’hypothèse que ces derniers connaissent les solutions interdomaines, les mécanismes d’authentification et les systèmes cryptographiques.

 
Haut de la page

1 Introduction

Le présent document aborde précisément les besoins du GC en matière de systèmes de sécurité nationale et décrit les questions de sécurité dont il faut tenir compte pour assurer le transfert des données entre des domaines de sécurité comportant différentes exigences de sécurité, et pour accéder à ces données, en expliquant les concepts d’assurance et de robustesse.

L’interconnexion de systèmes qui traitent de l’information à différents niveaux de catégorisation pourrait faire peser des risques importants sur les réseaux et les biens d’information. Pour atténuer ces risques, il est impératif de mettre en place les contrôles de sécurité appropriés pour gérer le flux de données entre les domaines de sécurité.

Les présentes lignes directrices traitent de la robustesse des solutions interdomaines (SID), des mécanismes d’authentification et de la séparation cryptographique assurant la protection des domaines de sécurité en fonction des catégorisations de la confidentialité, de l’intégrité et de la disponibilité. Elles abordent également deux cas spéciaux liés à la confidentialité : la restriction de diffusion et la compartimentation. Le respect de ces directives permettra d’assurer une robustesse comparable parmi les mécanismes cryptographiques, interdomaines et d’authentification qui protègent un même domaine.

Le présent document comporte une annexe classifiée disponible sur demande à l’intention des ministères du GC qui échangent de l’information CONFIDENTIEL, SECRET ou TRÈS SECRET avec des systèmes alliés. Pour obtenir copie de cette annexe classifiée, prière de communiquer avec le Centre d’appel du CCC, par courriel à l’adresse contact@cyber.gc.ca, ou par téléphone au 613-949-7048 ou 1-833-CYBER-88.

1.1 Politiques déterminantes

Les exigences en matière de sécurité des TI sont l’objet de plusieurs politiques au sein du gouvernement du Canada (GC). Les ministères du GC doivent veiller à ce que toutes les politiques et procédures en matière de sécurité des TI soient conformes aux politiques du Secrétariat du Conseil du Trésor (SCT) :

  • Politique sur la gestion des technologies de l’information [2];
  • Politique sur la sécurité du gouvernement [3];
  • Norme opérationnelle de sécurité : Gestion de la sécurité des technologies de l’information [4].

En respectant les politiques de sécurité des TI du GC et du ministère, vous jouez un rôle de premier plan dans la protection de l’information et des infrastructures importantes pour le GC.

1.2 Environnements concernés

L’ITSP.80.32 contient des conseils qui touchent principalement les solutions de TI avec des catégorisations de préjudice élevé ou très élevé, ainsi que celles qui sont susceptibles d’être la cible d’auteurs de menace hautement compétentsNote de bas de page 2. Il conviendra de noter que les systèmes utilisés dans les domaines PROTÉGÉ C ou classifiés peuvent faire l’objet d’autres considérations de conception qui sortent de la portée du présent documentNote de bas de page 3, y compris des exigences liées à l’intégrité de la chaîne d’approvisionnement (ICA)Note de bas de page 4. Conformément à leurs cadres respectifs de gestion des risques, les ministères sont tenus de définir des objectifs de sécurité qui soient propices à la protection des informations et des services ministériels.

1.3 Relation avec le processus de gestion des risques liés aux TI

L’ITSG-33 – La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie [5] du CCC décrit deux niveaux suggérés d’activités de gestion des risques liés à la sécurité des TI, à savoir les activités du niveau ministériel et du niveau des systèmes d’information. Ces deux niveaux d’activités sont illustrés à la figure 1 ci-dessous.

Figure 1 : Processus de gestion des risques liés à la sécurité des TI

Figure 1 : Processus de gestion des risques liés à la sécurité des TI

Au niveau du ministère, les activités sont intégrées au programme de sécurité de l’organisation pour planifier, gérer, évaluer et améliorer la gestion des risques liés à la sécurité des TI. Ces activités sont décrites en détail à l’annexe 1 de l’ITSG-33 [4].

Quant aux activités du niveau des systèmes d’information, elles sont intégrées au cycle de vie des systèmes d’information pour s’assurer de répondre aux besoins en matière de sécurité des TI des activités opérationnelles prises en charge et pour veiller à ce que les contrôles de sécurité appropriés soient mis en œuvre et exploités comme prévu, à ce que le rendement des contrôles existants soit évalué en permanence et fasse l’objet de rapports, et à ce que des mesures appropriées soient prises pour corriger toute lacune relevée. Ces activités sont décrites en détail à l’annexe 2 de l’ITSG-33 [4].

Le présent document facilite les activités de conception qui sont menées tout au long des phases de lancement, d’élaboration et d’acquisition de l’annexe 2 et peut s’avérer utile pour ce qui est de déterminer la robustesse des contrôles au niveau d’entreprise dans le cadre des activités liées à l’annexe 1.

 
Haut de la page

2 Interconnexion de domaines

L’interconnexion de domaines qui traitent l’information à des niveaux de catégorisation différents, que ce soit en fonction de la confidentialité, de l’intégrité ou de la disponibilité, peut faire peser des risques importants sur ces domaines. Pour atténuer ces risques, il est impératif de mettre en place les contrôles de sécurité appropriés pour gérer le flux de données entre les domaines de sécurité. S’ils ne sont pas choisis judicieusement, les contrôles de sécurité qui protègent un domaine dans le cadre de l’accès à l’information ou de son transfert peuvent mener à une fuite d’information sensible du domaine de sécurité de niveau supérieur au domaine de sécurité de niveau inférieur. De même, les maliciels peuvent se propager du domaine de sécurité de niveau inférieur au domaine de sécurité de niveau supérieur, ce qui a une incidence sur la disponibilité ou l’intégrité du domaine, en plus de sa confidentialité.

L’atténuation des risques associés au transfert de données consiste à sélectionner et appliquer des contrôles de sécurité robustes pour gérer le flux de données entre les domaines de sécurité.

Tel qu’il est indiqué à l’annexe 2 de l’ITSG-33, la robustesse permet de caractériser la force et l’assurance de la sécurité d’un contrôle, d’un service, d’un mécanisme ou d’un produit. La force de la sécurité est associée à la capacité potentielle du contrôle de protéger la confidentialité, l’intégrité ou la disponibilité des biens de TI. L’assurance de la sécurité d’un contrôle est, quant à elle, liée à la confiance en la conception et la mise en œuvre adéquates du contrôle et à sa capacité de fonctionner de la manière prévue. Ensemble, ces deux caractéristiques définissent les exigences de sécurité nécessaires à la mise en œuvre d’un contrôle qui pourra respecter ses objectifs de sécurité.

Les contrôles utilisés pour protéger des biens de TI plus sensibles ou essentiels, ou qui sont exposés à des menaces plus sérieuses, exigent généralement des solutions de sécurité plus robustes et une mise en œuvre offrant une plus grande assurance, ce qui se traduit par le recours à des niveaux de robustesse plus élevés. Le modèle de robustesse établit une hiérarchie basée sur les niveaux de préjudice prévus, ainsi que sur les capacités ou l’ampleur des menaces.

L’ITSG-33 définit les cinq niveaux de robustesse (de NR1 à NR5) et leurs exigences en matière de force et d’assurance. Ces niveaux ont été adaptés de manière à contrer un ensemble défini de catégories de menaces (présentées à la section 7.4.2 de l’annexe 2 de l’ITSG-33).

Les cinq niveaux définis dans ce modèle ne s’appliquent pas nécessairement à tous les contrôles (p. ex., une robustesse de niveau 4 ou 5 pourrait être excessive pour la mise en œuvre de certains contrôles, tels ceux pour la sauvegarde ou la vérification). Les exigences relatives à la force de la sécurité sont propres à chaque contrôle. Celles de l’assurance de la sécurité sont généralement les mêmes pour tous les contrôles qui exigent un même niveau de robustesse.

Un des principaux défis pour les architectes et les ingénieurs de la sécurité est de veiller à ce que chaque mécanisme de sécurité protégeant le périmètre d’un réseau donné fasse l’objet d’un même niveau de robustesse. Il est ainsi possible d’offrir une solution de sécurité optimale du point de vue des coûts-avantages. Si la robustesse n’est pas uniforme le long d’un périmètre donné, un adversaire peut trouver le chemin d’accès le plus faible et contourner les contrôles plus robustes et généralement plus coûteux.

Le document ITSG-33 – La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie [5] fait mention d’une discussion plus générale sur la robustesse. L’autre méthode illustrée dans la présente repose sur le modèle de robustesse général de l’ITSG-33. Elle propose une approche plus directe aux interconnexions de domaines discutées, qui fait appel aux propriétés connues des domaines interconnectés, telles que les niveaux d’habilitation et la catégorisation des données, afin de déterminer directement les niveaux de robustesse recommandés. Les tableaux figurant dans la présente réduiront la subjectivité au moment de déterminer le niveau de robustesse et mèneront à des solutions plus uniformes dans l’ensemble du gouvernement.

 
Haut de la page

3 Compréhension du processus

Le choix du niveau de robustesse approprié est basé non seulement sur la valeur opérationnelle de l’information traitée dans le domaine de sécurité, mais aussi sur l’environnement de menace auquel ce domaine est exposé (voir l’annexe 2 de l’ITSG 33 pour de plus amples renseignements). Par conséquent, les niveaux de robustesse sont choisis selon les besoins variés de chaque domaine sur le plan de la confidentialité, de l’intégrité ou de la disponibilité, et de l’environnement de menace.

Le processus mené pour établir le niveau de robustesse d’un mécanisme de sécurité commence par la détermination du type de séparation requis. Les trois scénarios de séparation les plus courants sont les suivants :

  1. la séparation par domaine de sécurité en fonction d’une combinaison de caractéristiques de confidentialité, d’intégrité et de disponibilité;
  2. la séparation aux fins de restriction de diffusion à des pays étrangers;
  3. la séparation aux fins de compartimentation.

Après avoir déterminé le scénario de séparation voulu, l’ingénieur, le concepteur de système ou l’architecte suivra les procédures détaillées dans le présent document pour établir les niveaux de robustesse requis.

Une bonne communication entre les propriétaires d’entreprises et leurs équipes de la sécurité des TI est primordiale, et peut contribuer à sensibiliser le personnel aux risques actuels et aux éventuelles répercussions sur les opérations. Les praticiens des technologies de l’information (TI) ne peuvent évaluer les risques sans une bonne compréhension du point de vue du propriétaire opérationnel quant à la valeur de l’information, et du rôle que joue l’information sur le plan opérationnel ou de la mission. La catégorisation du système par le propriétaire opérationnel fournit à l’architecte de sécurité l’information requise au sujet du système.

 
Haut de la page

4 Détermination de la robustesse des mécanismes de séparation

Cette section décrit le processus visant à déterminer le niveau de robustesse d’un mécanisme.

Il existe trois scénarios de séparation courants :

  • Scénario 1 : séparation par domaine de sécurité en fonction de la catégorisation de la confidentialité, de l’intégrité et de la disponibilité;
  • Scénario 2 : séparation aux fins de restriction de diffusion à des pays étrangers;
  • Scénario 3 : séparation aux fins de compartimentation.

4.1 Aperçu du processus

Pour sélectionner les caractéristiques de robustesse appropriée pour un mécanisme de séparation, il faut procéder comme suit :

  • Étape 1 : Sélectionnez le scénario de séparation en fonction de votre domaine particulier, de la restriction de diffusion ou des questions de compartimentation.
  • Étape 2 : Suivez le processus correspondant au scénario sélectionné.
  • Étape 3 : Sélectionnez le niveau de robustesse le plus élevé dans la plage spécifiée, ou procédez à une Évaluation des menaces et des risques (EMR) propre au système pour limiter la robustesse à un niveau spécifique dans la plage.
  • Étape 4 : Déterminez la robustesse indiquée pour la solution cryptographique, la SID ou le mécanisme d’authentification.

Pour un périmètre donné du domaine de sécurité, utilisez des mécanismes offrant les mêmes niveaux de robustesse.

La sélection d’un niveau de robustesse approprié sera également basée sur la valeur opérationnelle de l’information traitée dans le domaine de sécurité et l’environnement de menace auquel ce domaine est exposé.

Cinq tableaux ont été ajoutés à l’annexe A. Il conviendra de les consulter pour sélectionner le niveau approprié :

  • Utilisez les tableaux 1 et 2 pour déterminer le niveau de robustesse (NR) du mécanisme de sécurité requis pour assurer la séparation des domaines en fonction de la confidentialité, de l’intégrité ou de la disponibilité;
  • Utilisez le tableau 3 pour déterminer le NR du mécanisme de sécurité requis pour assurer la séparation des domaines aux fins de restriction de diffusion;
  • Utilisez le tableau 4 pour déterminer le NR du mécanisme de sécurité requis pour assurer la séparation des domaines aux fins de compartimentation.

Ensemble, les tableaux 1 à 4 procurent les plages cibles des NR qu’il convient d’utiliser pour les mécanismes de sécurité dans une situation donnée. Selon le NR sélectionné, le tableau 5 fournit l’information nécessaire pour établir l’assurance de l’évaluation de produit et la force du mécanisme. Pour déterminer un NR précis, il est nécessaire de procéder à une EMR.

4.2 Scénario 1 : Interconnexion de domaines de sécurité

Ce scénario général aide à déterminer la robustesse requise pour assurer la séparation des domaines de sécurité lorsque les domaines comportent différents objectifs en matière de confidentialité, d’intégrité ou de disponibilité, et que l’interconnexion non contrôlée de deux domaines risque d’aller à l’encontre de l’un de ces objectifs de sécurité.

Utilisez le processus détaillé ci-dessous pour déterminer le niveau de robustesse des mécanismes si la principale préoccupation est la séparation des domaines de sécurité :

  • Étape 1 : Déterminez le préjudice (P) du domaine de sécurité au moyen du tableau 1 (voir l’annexe A). Le préjudice global (P) est établi en sélectionnant le plus haut niveau de préjudice des trois objectifs de sécurité suivants : Confidentialité (PC), Intégrité (PI) et Disponibilité (PD);
  • Étape 2 : Déterminez le NR recommandé au moyen du tableau 2 (voir l’annexe A). Sélectionnez la colonne appropriée selon le niveau d’habilitation le moins élevé de tous les utilisateurs du domaine externe. Déterminez le NR en fonction du niveau d’habilitation sélectionné et du préjudice global (P) établi à l’étape 1;
  • Étape 3 : Faites appel à une EMR propre au système pour sélectionner le NR exact dans la plage indiquée. Si aucune EMR n’a été menée, il conviendra de sélectionner le niveau le plus élevé dans la plage;
  • Étape 4 : À partir du tableau 5 (voir l’annexe A), déterminez les caractéristiques de l’assurance et de la force du mécanisme de séparation.

Les exemples d’architecture suivants (voir l’annexe B) visent à démontrer les concepts de confidentialité, d’intégrité et de disponibilité :

  • Un exemple d’architecture illustrant la séparation des domaines de sécurité en fonction de la confidentialité se trouve à la figure 2 de l’annexe B.1;
  • Un exemple d’architecture illustrant la séparation des domaines de sécurité en fonction de l’intégrité se trouve à la figure 3 de l’annexe B.2;
  • Un exemple d’architecture illustrant la séparation des domaines de sécurité en fonction de la disponibilité se trouve à la figure 4 de l’annexe B.3.

4.3 Scénario 2 : Séparation des domaines aux fins de restriction de diffusion

Dans ce scénario, les domaines de sécurité qui sont séparés font l’objet de politiques de sécurité comparables, mais traitent l’information avec différentes mises en garde concernant la restriction de diffusion. On entend, par restriction de diffusion, la citoyenneté des personnes ou les pays et organismes (p. ex., l’Organisation du traité de l’Atlantique Nord [OTAN] ou l’Organisation des Nations Unies [ONU]) à qui l’information pourrait être divulguée.

Utilisez le processus détaillé ci-dessous pour déterminer le niveau de robustesse des mécanismes lorsque la restriction de diffusion constitue la principale préoccupation :

  • Étape 1 : Déterminez le NR au moyen du tableau 3 (voir l’annexe A). Si le calcul sert à déterminer la robustesse d’une SID de transfert bidirectionnel, le domaine canadien doit également contenir l’information communicable au domaine connecté, sans quoi l’interconnexion de sortie est inutile;
  • Étape 2 : Procédez à une EMR propre au système pour sélectionner le NR dans la plage indiquée. Si aucune EMR n’a été menée, il conviendra de sélectionner le niveau le plus élevé dans la plage;
  • Étape 3 : Déterminez les caractéristiques relatives à l’assurance et à la force du mécanisme à partir de la colonne NR du tableau 5 (voir l’annexe A).

On retrouve un exemple d’architecture illustrant un environnement exigeant une séparation aux fins de restriction de diffusion à la figure 5 de l’annexe B.4.

4.4 Scénario 3 : Séparation aux fins de compartimentation

Dans ce scénario, les domaines de sécurité qui sont séparés font l’objet de politiques de sécurité comparables, mais traitent l’information dans différents compartiments et comptent des utilisateurs à qui différents niveaux d’habilitation ont été conférés pour ce qui est de l’accès à l’information compartimentée. Les autorités de sécurité ministérielles ou locales peuvent créer des compartiments s’il s’avère nécessaire de mettre en place de plus amples contrôles basés sur le « besoin de connaître ». Au GC, les compartiments sont généralement classifiés au niveau Très secret (TS), mais peuvent également être classifiés à des niveaux inférieurs. Certains compartiments ne sont reconnus qu’au pays, tandis que d’autres sont convenus entre les alliés. L’endoctrinement à un compartiment est généralement effectué selon une habilitation de sécurité de niveau III, ce qui a été pris en compte lors de l’élaboration du tableau 3.

Utilisez le processus détaillé ci-dessous pour déterminer les caractéristiques de robustesse des mécanismes lorsque la séparation des compartiments constitue la principale préoccupation :

  • Étape 1 : Déterminez le NR au moyen du tableau 4 (voir l’annexe A);
  • Étape 2 : Procédez à une EMR propre au système pour sélectionner le NR dans la plage indiquée. Si aucune EMR n’a été menée, il conviendra de sélectionner le niveau le plus élevé dans la plage;
  • Étape 3 : Déterminez les caractéristiques relatives aux caractéristiques d’assurance et de force du mécanisme au moyen du tableau 5 (voir l’annexe A).

On retrouve un exemple d’architecture illustrant un environnement multicompartiments accessible par des utilisateurs avec différents endoctrinements à la figure 6 de l’annexe B.5.

 
Haut de la page

5 Notes d’application

De plus amples recommandations concernant les solutions de séparation interdomaines et cryptographiques figurent dans la liste suivante.

  1. Seul un ingénieur en sécurité des systèmes (SSE pour System Security Engineer) qualifié et expérimenté devrait déterminer les fonctions nécessaires à la SID ou au mécanisme de séparation.
  2. Toute dérogation aux tableaux ne devrait être accordée que sur les conseils d’un SSE avec l’accord de l’agent d’autorisation du système et l’approbation de ce dernier (c.-à-d. le propriétaire de l’information).
  3. Grâce à ces conseils, il sera possible de s’assurer que les niveaux de robustesse sont appliqués uniformément. Il importe de souligner que le périmètre d’un domaine de sécurité devrait être protégé par des mécanismes de sécurité qui font l’objet du même niveau de robustesse.
  4. Si un domaine contient des renseignements classifiés, on recommande fortement à l’agent de sécurité du ministère (ASM) d’exiger que le ministère se conforme à ce guide lors du processus d’évaluation et d’autorisation des systèmes qui composent ce domaine.
  5. Les questions de confidentialité sont la principale raison de faire appel à une SID ou à la séparation cryptographique. On ne peut toutefois appliquer le tableau 2 qu’aux problèmes de protection de l’intégrité illustrés à l’annexe B. Les problèmes de disponibilité ne sont généralement pas réglés par le recours à une SID ou à une solution cryptographique, mais il est possible d’appliquer le tableau 3 dans plusieurs cas. Par exemple, le tableau 2 peut être utilisé pour prodiguer des conseils sur la robustesse des mécanismes de séparation de machines virtuelles (VM pour Virtual Machine), tel qu’il est illustré dans l’annexe B. Dans ce cas, la disponibilité des VM repose sur la capacité du mécanisme de séparation à éviter que la défaillance d’une VM vienne perturber les autres VM.
  6. Outre sa robustesse, un mécanisme de sécurité utilisé pour séparer des domaines de sécurité doit également être obtenu auprès d’un fournisseur et d’un développeur de confiance. Plus l’écart à la sensibilité des domaines à séparer augmente, plus grande doit être la confiance accordée au fournisseur ou développeur. Si la SID sert à protéger des renseignements classifiés, le fournisseur ou développeur devrait être homologué par le Programme de sécurité industrielle (PSI) de Services publics et Approvisionnement Canada (SPAC) ou un organisme équivalent dans un pays allié (c.-à-d. l’Australie, le Royaume-Uni, la Nouvelle-Zélande ou les États-Unis). En règle générale, les solutions dont le niveau de robustesse est plus élevé (c.-à-d. NR4 ou supérieur) devraient être élaborées par des développeurs habilités au niveau SECRET ou un niveau supérieur. Aux fins d’uniformité, on recommande également aux ministères d’établir une norme organisationnelle à cet effet.
  7. Les SID de transfertNote de bas de page 5 posent un risque élevé par essence et devraient donc faire l’objet d’une surveillance étroite. La connexion du côté non classifié d’une SID de transfert devrait être surveillée de manière à détecter les cyberattaques sophistiquées. Pour ce faire, les ministères devraient demander le soutien du CCC.
  8. L’écart entre la sensibilité ou la valeur de l’information protégée sur le domaine de haute sécurité et le niveau de confiance des utilisateurs sur le domaine de faible sécurité constitue le principal facteur utilisé pour déterminer la robustesse. La confiance accordée à une entité se mesure par le niveau d’habilitation de sécurité de son personnel ou la cote de sécurité la moins élevée des utilisateurs autorisés dans un domaine. Il importe de souligner que la catégorisation du domaine de haute sécurité comprend la confidentialité, l’intégrité et la disponibilité, et ne se limite pas à la confidentialité. Par conséquent, la robustesse nécessaire à la séparation de deux domaines donnés sera la même peu importe la direction du transfert, même si la nature fonctionnelle du mécanisme de séparation est fort différente dans chaque direction.
  9. Il faudrait, dans la mesure du possible, éviter de réduire la force du mécanisme ou d’éliminer des contrôles. Dans les situations où il s’avère impossible ou trop coûteux d’atteindre un niveau d’assurance particulier, le niveau inférieur suivant pourrait être utilisé si aucune autre politique ou norme ne l’interdit, et si le propriétaire de l’information accepte le risque additionnel dans le cadre du processus d’évaluation et d’autorisation de sécurité (EAS)Note de bas de page 6. Il importe de souligner qu’il revient au propriétaire de l’information, généralement la personne à l’origine de l’information ou le propriétaire opérationnel, d’accepter le risque, et non à l’opérateur du système.
  10. Advenant l’utilisation de produits évalués selon les Critères communs (CC), il incombe aux SSE de veiller à ce que la cible de sécurité (ST pour Security Target) et la fonctionnalité globale du produit conviennent à l’usage prévu. La ST doit comprendre la fonction permettant d’assurer la séparation. Les exigences de sécurité des SID sont décrites dans le document Committee on National Security Systems Instruction (CNSSI) 1253 Appendix F Attachment 3 [6]. Le niveau d’assurance de l’évaluation (EAL pour Evaluation Assurance Level) ne peut à lui seul assurer la sécurité du système.
  11. Pour ce qui est de la séparation par chiffrement, le SSE doit sélectionner le système cryptographique, les algorithmes et les modes de fonctionnement appropriés pour répondre aux exigences fonctionnelles du domaine tout en tenant compte des conseils et des politiques en matière de sécurité des communications (COMSEC pour Communications Security) du CCC.
 
Haut de la page

6 Résumé

Un des principaux défis des praticiens de la sécurité consiste à s’assurer que les caractéristiques des contrôles de sécurité protègent le périmètre d’un domaine à des niveaux de robustesse comparables. Ces conseils visent à relever ce défi en veillant à ce que les mécanismes sélectionnés soient appropriés, c’est-à-dire ni trop robustes (et du coup trop coûteux), ni trop faibles (ce qui pourrait affaiblir le périmètre).

On recommande aux ministères de mettre en pratique ces conseils au moment de choisir et de développer des solutions afin de connecter entre eux différents domaines de sécurité, particulièrement si un ou plusieurs de ces domaines sont classifiés.

6.1 Aide et renseignements

Si votre ministère veut obtenir de plus amples renseignements sur l’interconnexion des domaines de sécurité, veuillez communiquer avec le :

Centre d’appel
contact@cyber.gc.ca
613-949-7048 ou 1-833-CYBER-88

 
Haut de la page

7 Contenu complémentaire

7.1 Liste d’abréviations

Forme abrégée
Expression au long
ASM
Agent de sécurité du ministère
AUS
Australie
C
Confidentiel
CC
Critères communs
CCC
Centre canadien pour la cybersécurité
CEO
Réservé aux Canadiens (Canadian Eyes Only)
CNSSI
Committee on National Security Systems Instruction
COMSEC
Sécurité des communications (Communications Security)
CST
Centre de la sécurité des télécommunications
É.-U.
États-Unis d’Amérique
EAL
Niveau d’assurance de l’évaluation (Evaluation Assurance Level)
EAS
Évaluation et autorisation de sécurité
EMR
Évaluation des menaces et des risques
FIPS
Federal Information Processing Standard
GC
Gouvernement du Canada
ICA
Intégrité de la chaîne d’approvisionnement
ICP
Infrastructure à clé publique
MAC
Contrôle d’accès obligatoire (Mandatory Access Control)
NR
Niveau de robustesse
NSA
National Security Agency
NZ
Nouvelle-Zélande
ONU
Organisation des Nations Unies
OTAN
Organisation du traité de l’Atlantique Nord
PA
Protégé A
PB
Protégé B
PC
Protégé C
PP
Profil de protection
R.-U.
Royaume-Uni
S
Secret
SCRS
Service canadien du renseignement de sécurité
SID
Solution interdomaines
SPAC
Services publics et Approvisionnement Canada
SSE
Ingénieur en sécurité des systèmes (System Security Engineer)
ST
Cible de sécurité (Security Target)
STI
Sécurité des technologies de l’information
TI
Technologie de l’information
TS
Très secret
VAF
Vérification approfondie de la fiabilité
VM
Machine virtuelle (Virtual Machine)

7.2 Glossaire

Terme
Définition
Assurance de la sécurité
Activités de mise en confiance qui visent à confirmer qu’un contrôle de sécurité a été conçu et mis en œuvre correctement et qu’il fonctionne comme prévu. De plus, l’assurance de la sécurité comprend des tâches dont le but est de confirmer la capacité de tous les contrôles d’un système d’information (conception, mise en œuvre et exploitation) à répondre aux besoins opérationnels en matière de sécurité.
Cible de sécurité (ST)
Spécification selon les Critères communs (CC) qui représente un ensemble d’exigences de sécurité sur lesquelles est fondée l’évaluation d’une cible d’évaluation (TOE pour Target of Evaluation) donnée.
Compartiment
Les autorités de sécurité ministérielles ou locales peuvent créer des compartiments s’il s’avère nécessaire de mettre en place de plus amples contrôles basés sur le « besoin de connaître ». Les compartiments sont généralement classifiés au niveau TS, mais peuvent également être classifiés à des niveaux inférieurs. Certains compartiments ne sont reconnus qu’au pays, tandis que d’autres sont convenus entre les alliés. L’endoctrinement d’un compartiment est généralement effectué selon une habilitation de sécurité de niveau III.
Contrôle de sécurité
Exigence technique, opérationnelle ou de gestion de haut niveau relative à la sécurité et prescrite pour un système d’information afin de protéger la confidentialité, l’intégrité et la disponibilité de ses biens de TI. Ces contrôles sont mis en œuvre par l’application de différents types de solutions de sécurité qui incluent les produits, politiques, pratiques et procédures de sécurité.
Domaine de sécurité
Système ou ensemble de systèmes soumis à une même politique de sécurité et assujettis à des exigences ainsi qu’à des contrôles communs sur le plan de la confidentialité, de l’intégrité et de la disponibilité.
Exigence de sécurité
Tout besoin en matière de sécurité des TI, énoncé dans un langage normalisé, auquel doit répondre un système d’information pour permettre la satisfaction d’un besoin opérationnel en matière de sécurité.
Force de la sécurité
Potentiel d’une solution de sécurité à faire opposition au savoir-faire d’un auteur de menace dans la mesure où cette solution n’a fait l’objet d’aucun trafiquage et a été conçue adéquatement. Voir également Assurance de la sécurité.
Force du mécanisme
Voir Force de la sécurité.
Interface contrôlée
Mécanisme qui permet de mettre en œuvre une politique sur l’acheminement d’information opérationnelle et de sécurité entre des domaines interconnectés.
Niveau d’assurance de l’évaluation (EAL)
Ensemble constitué d’exigences en matière d’assurance qui représente un niveau de l’échelle d’assurance prédéfinie des CC.
Niveau de robustesse
Niveau qui tient compte de l’assurance et de la force de la sécurité. Ces deux composantes définissent les exigences qu’il faut respecter au moment de mettre en œuvre et d’appliquer un contrôle de sécurité pour répondre aux objectifs définis en matière de contrôles de sécurité.
Niveau de sensibilité
Les niveaux de sensibilité décrivent le préjudice qui pourrait raisonnablement survenir en cas de compromission de la confidentialité.
Objectif de sécurité
Fait d’assurer la confidentialité, l’intégrité et la disponibilité d’une activité opérationnelle ou d’un bien de TI contre un ensemble défini de menaces afin de prévenir tout préjudice aux intérêts nationaux ou non nationaux.
Préjudice
Dommage causé aux intérêts nationaux et non nationaux par les activités opérationnelles mises à leur service et qui résulte de la compromission des biens de TI. On retrouve cinq niveaux de préjudice : très faible, faible, moyen, élevé et très élevé.
Profil de sécurité
Ensemble de contrôles de sécurité qui ont été sélectionnés pour répondre aux besoins d’un environnement opérationnel et d’un contexte de sécurité en particulier. Plus précisément, les profils de sécurité répondent aux besoins en matière de confidentialité, d’intégrité et de disponibilité nécessaires à la protection de l’information sensible.
Renseignements classifiés
Renseignements d’intérêt national susceptibles d’être visés par une exclusion ou une exception en vertu de la Loi sur l’accès à l’information ou de la Loi sur la protection des renseignements personnels. La compromission de ces renseignements pourrait, selon toute vraisemblance, causer un préjudice à l’intérêt national.
Restriction de diffusion
On entend, par restriction de diffusion, la citoyenneté des personnes ou les pays ou organismes à qui l’information peut être divulguée.
Robustesse
Caractérisation de l’assurance et de la force de la sécurité d’un contrôle de sécurité.
SID de transfert
Solution interdomaines qui permet de transférer des données entre différents domaines de sécurité.
Solution de sécurité
Tout produit ou toute fonction, pratique ou procédure de sécurité que l’on peut intégrer à un système d’information pour appliquer un contrôle de sécurité.
Solution interdomaines (SID)
Interface contrôlée permettant d’accéder manuellement ou automatiquement à de l’information se trouvant dans des domaines de sécurité, ou de transférer manuellement ou automatiquement de l’information entre des domaines qui font l’objet de différentes politiques de sécurité. Parmi les exemples, on retrouve les gardiens de transfert, les systèmes d’exploitation multiniveau ou les noyaux de séparation servant à séparer les machines virtuelles dans différents domaines de sécurité. Les SID appartiennent à trois catégories selon leur architecture interdomaines : accès, transfert ou multiniveau.

7.3 Références

Numéro
Référence
1
Secrétariat du Conseil du Trésor. Ligne directrice sur la définition des exigences en matière d’authentification, novembre 2008.
2
Secrétariat du Conseil du Trésor. Politique sur la gestion des technologies de l’information, 1er juillet 2007.
3
Secrétariat du Conseil du Trésor. Politique sur la sécurité du gouvernement (PSG), 1er juillet 2009.
4
Secrétariat du Conseil du Trésor. Norme opérationnelle de sécurité : Gestion de la sécurité des technologies de l’information, non daté.
5
Centre canadien pour la cybersécurité. ITSG-33 – La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie, décembre 2014.
6
Committee on National Security Systems Instruction. 1253 Appendix F Attachment 3, non daté.
7
Centre canadien pour la cybersécurité. Algorithmes cryptographiques pour l’information protégée (ITSB-111), juillet 2015.

Annexe A : Tableaux

Utilisez le tableau 1 pour déterminer le préjudice d’une compromission au domaine que vous voulez protéger.

Tableau 1 : Préjudice à la sécurité du domaine
Préjudice (P) Intégrité (PI) Disponibilité (PD) Confidentialité (PC) Description du préjudice
P5 Très élevé Très élevé TRÈS SECRET (TS) Une infraction à la politique de protection pourrait causer un préjudice exceptionnellement grave.
P4 Élevé Élevé

SECRET (S),
Protégé C (PC)

Une infraction à la politique de protection pourrait causer un préjudice grave.
P3 Moyen Moyen

CONFIDENTIEL
Protégé B (PB)

Une infraction à la politique de protection pourrait causer un certain préjudice.
P2 Faible Faible

Protégé A (PA),
Réservé aux alliés,
Non classifié//FOUO

Une infraction à la politique de protection pourrait causer un faible préjudice.
P1 Très faible Très faible Non classifié (U) Une infraction à la politique de protection pourrait causer un préjudice négligeable.

Utilisez le tableau 2 pour déterminer le niveau de robustesse (NR) du mécanisme de séparation en fonction de la valeur du préjudice (P) obtenu au tableau 1. Il importe de souligner que le tableau 2 propose différentes valeurs NR pour l’information d’intérêt national et non national.

Tableau 2 : Séparation par niveau d’habilitationNote de bas de page 7
Utilisateurs ou domaines séparés
Préjudice Habilitation minimale des utilisateurs autorisés Utilisateurs non
habilités ou
inconnus
Niveau III Niveau II Niveau I Vérification approfondie de
la fiabilité (VAF)
Information relative à la sécurité nationale
P5 s.o. NR2 à NR3Note de bas de page 8 NR4 à NR5 NR5 NR5
P4 s.o. s.o. NR3 à NR4 NR3 à NR4 NR4
P3 s.o. s.o. s.o. NR3 à NR4 NR4
P2 s.o. s.o. s.o. NR2 NR2
P1 s.o. s.o. s.o. s.o. NR1
Utilisateurs ou domaines séparés
Préjudice Habilitation minimale des utilisateurs autorisés Utilisateurs non
habilités ou
inconnus
Niveau III Niveau II Niveau I VAF
Information non liée à la sécurité nationale
P4 NR2Note de bas de page 9 NR2Note de bas de page 8 NR2Note de bas de page 8 NR2Note de bas de page 8 NR4
P3 NR1Note de bas de page 8 NR1Note de bas de page 8 NR1Note de bas de page 8 NR1Note de bas de page 8 NR2
P2 NR1Note de bas de page 8 NR1Note de bas de page 8 NR1Note de bas de page 8 NR1Note de bas de page 8 NR1
P1 s.o. s.o. s.o. s.o. NR1

Utilisez le tableau 3 de l’annexe 1 pour déterminer le NR requis pour séparer un domaine de sécurité classifié CEO des domaines et utilisateurs étrangers.

Tableau 3 : Séparation aux fins de restriction de diffusion
Système allié
CEO Utilisateur étranger ou domaine séparé
VOIR L’ANNEXE 1

L’annexe 1 contient également un exemple d’architecture propre à ce scénario. Voir la figure 5.

Utilisez le tableau 4 pour déterminer le NR nécessaire à la séparation de l’information compartimentée dans un domaine multiniveau ou entre deux domaines exploités en mode à niveau dominant de sécurité. Pour un exemple d’architecture, voir la figure 5 à l’annexe B.

Tableau 4 : Séparation par compartiment
Utilisateurs ou domaines séparésNote de bas de page 10
Classification des
données ou du
système 		Compartiment
différent, utilisateurs
habilités TS
(niveau III) 		Compartiment
différent,
utilisateurs
habilités S
(niveau II) 		Niveau I VAF Autres
Compartiment TS NR2 NR3 à NR4 NR4 à NR5 NR5 NR5
Compartiment S NR2 NR2 NR3 à NR4 NR3 à NR4 NR4

Le tableau 5 décrit les caractéristiques des produits cryptographiques, des SID et des solutions d’authentification selon les niveaux de robustesse.

Tableau 5 : Caractéristiques des mécanismes cryptographiques et des SID
Niveau de
robustesse 		Mécanismes cryptographiques Solutions interdomaines (SID) et autres mécanismes de séparation Authentification
Exigences
d’assurance de
l’évaluation 		Exigences en matière de
force du mécanisme 		Exigences d’assurance de
l’évaluation 		Exigences en matière de force du
mécanisme 		Exigences d’assurance de
l’évaluation 		Exigences
en matière de force
du mécanisme
NR5 Produits cryptographiques d’assurance élevée (PCAE) (anciennement type 1)

Voir l’ITSD-01A

Approuvés par le CCC pour protéger les données TRÈS SECRET (TS) des entités hostiles, configurés pour protéger les données TS sur des supports de transmission non fiables. Consulter le CCCNote de bas de page 11 Consulter le CCCNote de bas de page 11 Produits cryptographiques d’assurance élevée (PCAE)
(anciennement type 1)

Voir l’ITSD-01A

Approuvés par le CCC pour l’authentification au moyen de canaux non fiables et résistants aux menaces de catégorie Md7Note de bas de page 12 ou moins.
Produit SID recommandé par le CCC avec mécanismes de séparation évalués au niveau d’assurance de l’évaluation EAL 7. Met en œuvre des contrôles de sécurité tirés de la superposition des contrôles de sécurité de la SID (CNSSI 1253, Appendix F, Attachment 3). Le CCC devrait être consulté. Interdit les transferts de données non structurées d’un domaine classifié à un domaine non classifié au moyen de la SID.
NR4 Produits cryptographiques
d’assurance élevée (PCAE)
(anciennement type 1)
ou
Produits cryptographiques
de grande valeur (PCGV)

Voir l’ITSD-01A et l’ITSD-07

Approuvés par le CCC pour protéger les données SECRET (S) sur des supports de transmission non fiables. Produit SID recommandé par le CCC avec mécanismes de séparation évalués au niveau EAL 6. Met en œuvre des contrôles de sécurité tirés de la superposition des contrôles de sécurité de la SID (CNSSI 1253, Appendix F, Attachment 3).

Le CCC devrait être consulté. Le transfert de données non structurées n’est pas recommandé.

non définie non définie
NR3 Logiciels commerciaux approuvés au niveau S. Longueur d’algorithme et de clé approuvée par le CCC pour protéger les données SECRET (S) sur des supports de transmission non fiables. Produit SID recommandé par le CCC avec mécanismes de séparation évalués au niveau EAL 5. Met en œuvre des contrôles de sécurité tirés de la superposition des contrôles de sécurité de la SID (CNSSI 1253, Appendix F, Attachment 3). Le CCC devrait être consulté. Le transfert de données non structurées n’est pas recommandé. LOA4 ITSG-31 Longueur d’algorithme et de clé approuvée au niveau PC

(voir l’ITSG-111 [Référence 3] pour plus de détails).

Pour une séparation entre des domaines classifiés (p. ex. TS de S), utilisez la FIPS 140 2Note de bas de page 13 niveau 3 ou supérieur. Longueur d’algorithme et de clé approuvée au niveau Protégé C (PC) (voir l’ITSB-111 [Référence 3] pour plus de détails).
NR2 FIPS 140-2Note de bas de page 13 niveau 2 ou supérieur. Longueur d’algorithme et de clé approuvée au niveau Protégé B (PB) (voir l’ITSB-111 [Référence 3] pour plus de détails). Produit recommandé par le CCC avec mécanismes de séparation répondant aux exigences du profil de protection (PP) homologué par le CCC (ou niveau EAL 3 ou 4 avant 2014). Met en place des contrôles de sécurité tirés d’un PP homologué par le CCC, ou d’un PP ou d’une cible de sécurité (ST pour Security Target) sélectionné par un ingénieur en sécurité des systèmes (SSE pour System Security Engineer) qualifié, s’il n’existe aucun PP homologué par le CCC. LOA3 ITSG-31 Longueur d’algorithme et de clé approuvée au niveau PB

(voir l’ITSG-111 [Référence 3] pour plus de détails).

NR1 FIPS 140-2Note de bas de page 13 niveau 1 ou supérieur. Longueur d’algorithme et de clé approuvée au niveau Protégé A (PA) (voir l’ITSB-111 [Référence 3] pour plus de détails). Produit recommandé par le CCC avec mécanismes de séparation répondant aux exigences du PP homologué par le CCC (ou niveau EAL 1 ou 2 avant 2014). Met en place des contrôles de sécurité tirés d’un PP homologué par le CCC, ou d’un PP ou d’une ST sélectionné par un SSE qualifié, s’il n’existe aucun PP homologué par le CCC. LOA2 ITSG-31 Longueur d’algorithme et de clé approuvée au niveau PA

(voir l’ITSG-111 [Référence 3] pour plus de détails).

Annexe B : Exemples d’architectures

B.1 Confidentialité et réseaux en cascade

Figure 2 : Réseaux en cascade

Figure 2 : Réseaux en cascade

Cet exemple d’architecture traite de deux concepts : la séparation en fonction de la confidentialité et les réseaux en cascade (voir la section 4.2).

On parle de réseaux en cascade lorsqu’au moins trois domaines de sécurité sont interconnectés par deux SID ou plus. Ces réseaux en cascade comportent des risques particuliers. Bien que la robustesse de chaque SID puisse convenir aux transferts qu’elle contrôle, la robustesse de l’ensemble des SID risque de ne pas correspondre au niveau de robustesse nette requis pour protéger le domaine le plus élevé du domaine le plus faible.

Calculer la robustesse requise pour la SID A

Selon le tableau 1, un préjudice de niveau 5 s’applique au domaine Très secret (TS). D’après le tableau 2, la séparation du domaine Secret (S) correspond à une robustesse de niveau 2 ou 3. Par prudence, on choisit une robustesse de niveau 3.

Calculer la robustesse requise pour la SID B

Selon le tableau 1, un préjudice de niveau 4 s’applique au domaine Secret (S). D’après le tableau 2, la séparation du domaine Non classifié (U) correspond à une robustesse de niveau 4.

Calculer la robustesse nette requise pour l’ensemble des SID

La robustesse nette se calcule en tenant compte de l’ensemble des SID entre les domaines TS et U (c’est-à-dire, le secteur à l’intérieur de la ligne pointillée). Selon le tableau 1, un préjudice de niveau 5 s’applique au Domaine S. D’après le tableau 2, le Domaine U qu’il faut séparer correspond à une robustesse de niveau 5.

Avec une robustesse de niveaux 3 et 4 respectivement, la combinaison des SID A et B est-elle égale à la robustesse globale requise de niveau 5? Au mieux, la combinaison des SID A et B serait sûrement établie au niveau 4.

Il n’est pas simple de déterminer la robustesse requise pour la combinaison de deux SID ou plus. La force globale des différents mécanismes de sécurité des diverses SID dépend de la manière dont les contrôles interagissent entre eux.

L’assurance globale doit tenir compte de l’indépendance des chaînes d’approvisionnement et de l’intégrité de la chaîne d’approvisionnement de chacune des SID. Dans certains cas, les contrôles pourraient faire augmenter la force globale alors que d’autres combinaisons pourraient la faire baisser. Ces interactions pourraient être subtiles et difficiles à reconnaître, surtout si chacune des SID est déployée indépendamment des autres par différentes équipes et à des moments différents.

La robustesse n’est pas cumulative; installer en série plus d’un dispositif peu robuste ne se traduira généralement pas par un niveau de robustesse plus élevé.

B.2 Domaine à intégrité élevée connecté à un domaine à intégrité faible

Figure 3 : Enclave à intégrité élevée vers une enclave à intégrité faible

Figure 3 : Enclave à intégrité élevée vers une enclave à intégrité faible

Cet exemple d’architecture traite de l’intégrité (voir la section 4.2).

Dans cet exemple, la SID doit éviter que le contenu du domaine à intégrité faible atteigne le domaine à intégrité élevée. Si le domaine à intégrité élevée, qui n’est pas classifié dans cet exemple pour des motifs d’intérêt national, comporte une valeur d’intégrité (II) de trois, et si le domaine à intégrité faible est un domaine public, alors la robustesse sera NR2 selon le tableau 2. D’après le tableau 5, la SID devrait être évaluée en vertu des exigences du PP homologué par le CCC (niveau EAL2 ou supérieur) par un laboratoire d’évaluation selon les CC approuvé.

B.3 Séparation aux fins de protection de la disponibilité

Figure 4 : Virtualisation et disponibilité

Figure 4 : Virtualisation et disponibilité

Cet exemple d’architecture traite de la disponibilité (voir la section 4.2).

Dans cet exemple, un domaine à disponibilité élevée avec une valeur ID de I4 se trouve sur la même machine physique qu’un domaine à disponibilité faible auquel peuvent accéder des utilisateurs et systèmes inconnus, comme l’Internet public. Le noyau de séparation, qui permet d’éviter qu’une entorse à la disponibilité dans le domaine inférieur ait une incidence sur le domaine supérieur, devrait avoir le niveau de robustesse NR4 (selon le tableau 2 pour l’information non relative à la sécurité nationale), si on part de l’hypothèse que le domaine supérieur ne contient que de l’information protégée (c.-à-d. de l’information non relative à la sécurité nationale).

Nota : On suppose également qu’il est possible d’assurer le même niveau de disponibilité pour la machine physique dans son ensemble, y compris son alimentation, son refroidissement et sa sécurité physique contre les préjudices.

B.4 Enclave SECRET//CEO connectée à une enclave SECRET//NATO

Figure 5 : Cette figure est classifiée au niveau Confidentiel//CEO et se trouve à l’annexe 1.

Pour obtenir copie de l’annexe 1, prière de communiquer avec le Centre d’appel du CCC, par courriel à l’adresse contact@cyber.gc.ca, ou par téléphone au 613-949-7048 ou 1-833-CYBER-88.

B.5 Utilisateurs multicompartiments avec accès TS//Spécial et endoctrinements divers

Figure 6 : Multicompartiments

Figure 6 : Multicompartiments

Dans cet exemple d’architecture (voir la section 4.4), l’information TS du « Compartiment A » est séparée des utilisateurs TS non endoctrinés pour le Compartiment A par un chiffrement basé sur une infrastructure à clé publique (ICP) ou par un contrôle d’accès obligatoire (MAC pour Mandatory Access Control) renforcé par le système d’exploitation ou le système de gestion des bases de données. Selon la séparation par compartiment (tableau 4), le niveau de robustesse est NR2 (compartiment TS ou utilisateurs habilités au niveau III, différents compartiments).

Les compartiments pourraient être séparés au moyen d’une des méthodes suivantes et selon les exigences en matière d’assurance du NR2, tel qu’il est indiqué dans le tableau 5 :

  • le MAC d’un SE multiniveau;
  • une base de données qui répond au profil de protection établi;
  • une séparation cryptographique avec la FIPS 140-2 de niveau 2 ou supérieur, conformément au tableau 5;
  • une combinaison des méthodes précédemment mentionnées.
Date de modification :