Sélection de la langue

Recherche

Audit des contrôles généraux de la technologie de l’information

Audit des contrôles généraux de la technologie de l’information
(PDF, 441 KB)

Rapport d'audit interne
Projet 6B315
Date : Avril 2022

Sur cette page


Introduction

Contexte

Pêches et Océans Canada (MPO) est responsable de la protection des eaux et de la gestion des ressources halieutiques et océaniques du Canada. Sa mission est d’offrir aux Canadiens des secteurs maritimes et des pêches économiquement prospères, des écosystèmes aquatiques plus durables et des eaux sûres, sécuritaires et navigables. La Garde côtière canadienne (GCC) offre toute une gamme de services aux Canadiens, notamment la recherche et le sauvetage, les opérations de déglaçage, la sûreté maritime et les interventions environnementales.

Pour remplir son mandat, le Ministère s’appuie sur un vaste réseau de technologies de l’information (TI) qui, ensemble, soutiennent la prestation de programmes et de services nationaux et régionaux. En tant que ministère du gouvernement fédéral, le MPO doit adhérer et se conformer aux exigences et aux attentes en matière de TI énoncées dans les lois, les politiques et les directives à l’échelle du gouvernement – en particulier, la Politique sur les services et le numérique et la Directive sur les services et le numérique du Conseil du Trésor, la Politique sur la sécurité du gouvernement, et la Directive sur la gestion de la sécurité. Ces instruments régissent la manière dont les ministères et les organismes fédéraux gèrent les renseignements et les données, les technologies de l’information, la prestation de services et la cybersécurité. Au sein du MPO, le dirigeant principal de l’information (DPI), qui relevait du sous-ministre adjoint des Ressources humaines et des Services intégrés (RHSI) au cours de l’audit, est responsable de la fonction TI du Ministère et doit rendre compte de tous les projets ministériels de TI, y compris ceux de la Garde côtière canadienne.Note de bas de page 1 Note de bas de page 2 Au moment de la rédaction de ce rapport, un nouveau DPI venait d’être nommé à un poste de sous-ministre adjoint nouvellement créé. Les changements organisationnels résultant de cette nomination, y compris ceux touchant les fonctions informatiques, n’avaient pas encore été annoncés.

Le portefeuille informatique du Ministère se compose d’un peu plus de 400 applications, dont 39 sont définies comme critiques ou essentielles à la mission visant la continuité des opérations et des services du Ministère. La majorité des applications sont gérées et soutenues par la direction de la Gestion de l’information et des services de technologie de l’information (GI-ST).Note de bas de page 3 L’un des rôles clés de la GI-ST est de veiller à ce que des contrôles adéquats des TI soient en place et fonctionnent efficacement au sein du Ministère. Les contrôles généraux liés à la TI sont essentiels pour protéger et préserver l’intégrité des renseignements et des données, et pour garantir le respect des politiques et des normes applicables.

Les contrôles généraux des TI sont définis comme étant distincts des contrôles d’application. Ils concernent l’environnement dans lequel les systèmes d’applications informatiques sont développés, entretenus et exploités, et sont donc valables pour toutes les applications.Note de bas de page 4 Les contrôles généraux liés à la TI comprennent des politiques, des procédures et des pratiques conçues pour fournir une assurance sur le développement et le fonctionnement de l’informatique et sont applicables à tous les systèmes, applications et processus, à la gestion de l’accès et de la sécurité, au développement d’applications, ainsi qu’à la sauvegarde et à la récupération des données. En revanche, les contrôles propres à une application ou à un processus individuel, appelés contrôles d’application, ne sont pas considérés comme faisant partie des contrôles généraux liés à la TI.

Les dépenses en TI au sein du MPO ont augmenté globalement de 59 % au cours des trois dernières années. De l’exercice financier 2018-2019 à 2019-2020, les dépenses en TI ont augmenté de 31 %, passant de 104,3 millions de dollars à 137,1 millions de dollars, et de 21 % de l’exercice financier 2019-2020 à 2020-2021.Note de bas de page 5 L’augmentation du financement sur la période de trois ans a été utilisée pour investir dans la mise à niveau des réseaux, les capacités Wi-Fi, les ressources humaines, un nouveau système de rapports financiers ministériels et un nouveau système de gestion des documents.

Le MPO a également effectué récemment d’autres audits internes portant sur la gouvernance et la planification des TI, la gestion des actifs et la sécurité :

Audit de la gouvernance de la gestion de l’information et de la technologie et de la planification intégrée (2020)

L’audit visait à déterminer si le Ministère avait mis en place des structures et des processus de gouvernance pour gérer les projets de GI-TI et intégrer la GI-TI aux décisions de planification. Elle a conclu que le Ministère avait mis en œuvre certains éléments et certains processus de gouvernance pour gérer les projets de GI-TI et intégrer la GI-TI aux décisions de planification. Toutefois, l’audit a permis de cerner des points à améliorer concernant les pratiques de surveillance des comités et la mise en application du cadre de gestion de projet du Ministère afin de mieux appuyer la surveillance, la production de rapports et la prise de décision éclairée.

Audit de la gestion des biens de technologie de l’information (2019)

L’audit a permis de déterminer si le Ministère avait mis en place un système efficace de gestion des biens de TI pour les matériaux informatiques qui protège ces biens ainsi que les renseignements de TI, qui respecte les règlements et appuie la prestation des programmes. L’audit a conclu qu’un système efficace de gestion des biens de TI n’avait pas été mis en place pour les matériaux informatiques. Il a également cerné des possibilités de renforcer l’inventaire et la protection des actifs informatiques ainsi que le ressourcement, la coordination et la disposition de ces actifs.

Audit de la sécurité de la technologie de l’information (2016)

L’audit visait à déterminer si le Ministère avait mis en place un cadre de contrôle adéquat et efficace pour soutenir la sécurité de la TI. L’audit a constaté que, bien que les structures de gouvernance existaient, les rôles et les responsabilités de la sécurité des TI devraient être mieux définis pour veiller à ce que le programme de sécurité des technologies de l’information soit géré de façon adéquate et efficace. Il a également conclu qu’il était possible de renforcer le programme de sécurité de la TI du Ministère en améliorant les processus de gestion des comptes et de gestion des correctifs, et en veillant à ce que les menaces et les risques pour la sécurité informatique soient régulièrement évalués et surveillés.

L’audit a été sélectionné conformément au Plan d’audit axé sur les risques 2020-2022 du Ministère, qui a déterminé la nécessité d’évaluer l’efficacité des contrôles généraux de la TI.

À la suite d’une évaluation des risques au cours de la phase de planification de l’audit, cette dernière a permis de cerner cinq domaines présentant un risque plus élevé et nécessitant un examen plus approfondi, à savoir :

Pourquoi cet audit est-il important?

La TI joue un rôle essentiel dans la capacité du MPO à offrir ses programmes et services aux Canadiens et à aboutir à des efficacités opérationnelles. Pour cela, il est essentiel de disposer d’un environnement de contrôle informatique qui fonctionne bien, afin de fournir les conditions nécessaires pour que les TI fonctionnent comme prévu et en conformité avec les politiques applicables.

Objectif de l’audit

L’objectif de cet audit était de déterminer si les contrôles généraux clés du Ministère en matière de technologie de l’information étaient en place et s’ils fonctionnaient efficacement.

Portée de l’audit et approche utilisée

La portée de l’audit a été établie sur la base des résultats d’une évaluation détaillée des risques réalisée au cours de la phase de planification de l’audit et a permis de vérifier si des contrôles clés étaient en place et fonctionnaient efficacement dans les domaines jugés à haut risque. Il s’agit notamment de la prestation de services informatiques, du développement d’applications, de la continuité de la TI, de la sécurité informatique et de l’adoption de l’informatique en nuage. L’audit n’a pas examiné d’autres contrôles généraux liés à la TI, principalement sur la base de l’évaluation des risques et de la couverture récente des audits précédents. Il convient de noter que la portée ne couvrait pas les services informatiques gérés par la GCC. En outre, la portée de l’audit excluait l’infrastructure et les services de TI relevant de Services Partagés Canada.

L’audit a porté sur la période du 1er avril 2019 au 31 août 2021, mais a également pris en compte des renseignements en dehors de cette période pour des contrôles précis.

Les travaux d’audit ont été exécutés au moyen des activités suivantes :

Conclusion

Dans l’ensemble, l’audit a permis de conclure que le Ministère avait mis en œuvre des contrôles généraux en matière de TI dans les domaines examinés, et que ceux-ci fonctionnaient généralement comme prévu.

Toutefois, des lacunes ont été cernées dans un certain nombre de domaines :

Énoncé de conformité

Cet audit a été réalisé conformément aux Normes internationales pour la pratique professionnelle de l’audit interne, comme en témoignent les résultats du programme d’assurance et d’amélioration de la qualité de la Direction générale de l’audit interne de Pêches et Océans Canada.

Constatations et recommandations de l’audit

Ce rapport présente des résultats organisés autour de cinq éléments d’enquête : le Centre de services informatique, le développement d’applications, la continuité informatique, la sécurité informatique et l’adoption de l’informatique en nuage.

L’annexe A présente les critères d’audit à l’appui, par secteur d’intérêt, utilisés pour conclure sur l’objectif d’audit.

Centre de services TI

Le Centre de services TI du MPO joue un rôle essentiel, car il est le premier point de contact pour de nombreux employés du Ministère qui souhaitent obtenir un soutien et des services informatiques. La mise en place de normes de processus et de procédures est importante pour aider le personnel du Centre de services à fournir des services cohérents et efficaces à ses clients. En outre, les normes de service permettent à la fois au client et au personnel du Centre de services de comprendre clairement le niveau de service fourni afin de répondre aux attentes. Elles permettent également de hiérarchiser les demandes de service et de résoudre les incidents.

En ce qui concerne le soutien et la prestation des services de TI du Centre de services, nous nous attendions à ce que le Ministère ait mis en place les éléments suivants :

Dans l’ensemble, nous avons conclu que la GI-ST avait bien progressé dans la mise en œuvre de processus et de procédures standardisé pour le Centre de services et dans l’établissement de normes de service. D’autres travaux étaient toujours en cours, mais aucun processus officiel n’a été mis en place pour définir les priorités ou les échéanciers de la réalisation des éléments en suspens.

Des progrès ont été réalisés dans la mise en œuvre des améliorations apportées au bureau de service de la technologie de l’information (TI), mais les délais pour l’achèvement des travaux restants n’ont pas été définis.

En 2017, la Gestion de l’information et services de la technologie (GI-ST) a engagé une société d’experts-conseils externe pour examiner sa fonction de bureau de service à la clientèle et sa prestation de services de TI. Elle a formulé sept recommandations principales visant à améliorer les processus et les technologies du bureau de service ainsi que la prestation des services de TI. Un deuxième examen a eu lieu en octobre 2019, dirigé par la même société d’experts-conseils, afin d’examiner les progrès réalisés dans la mise en œuvre des recommandations antérieures. Ce travail a abouti à l’élaboration de la stratégie de soutien aux services de TI de la GI-ST.

Sur la base de cette stratégie et d’autres travaux effectués en interne, portant sur l’amélioration d’autres domaines, la GI-ST a déterminé un certain nombre de mesures de suivi qui, une fois mises en œuvre, permettraient d’atteindre les améliorations souhaitées du bureau de service. Parmi celles-ci, nous en avons cerné 29 qui étaient liées à la standardisation des processus et procédures du bureau de service et à l’établissement de normes du service à la clientèle. Nous avons ensuite examiné les progrès de la GI-ST dans la mise en œuvre de chaque mesure. Toutefois, notre évaluation des mesures de suivi ne portait pas sur leur efficacité à atteindre les résultats escomptés en matière d’amélioration du bureau de service, ni sur les contrôles internes associés visant à renforcer les processus du bureau de service ou les normes de service. Dans l’ensemble, nous avons constaté que la GI-ST avait progressé dans la standardisation des processus et des procédures opérationnelles pour la prestation des services et la résolution des incidents, et dans l’établissement de normes de service.

Constatations et analyse

Processus et procédures standardisés et normes de service

Plus de la moitié des 29 mesures de suivi que nous avons examinées (15 sur 29) avaient été mises en place, huit étaient en cours de réalisation et six n’avaient pas encore commencé. Neuf mesures dont la mise en place était prévue pour avril 2021 n’étaient pas encore achevées. Par exemple, un processus clé visant à effectuer une analyse de l’arriéré et à réduire régulièrement les files d’attente du bureau de service de la TI n’avait pas été élaboré.

Une nouvelle équipe dédiée à l’innovation et au soutien a été créée en janvier 2021 au sein de la GI-ST pour diriger la mise en œuvre des mesures de suivi restantes. Toutefois, l’équipe a fait état de la lenteur des progrès dans la mise en œuvre des modifications, les membres ayant été chargés de ce nouveau rôle en plus de leurs rôles et responsabilités précédents.

En outre, nous avons constaté qu’il n’existait aucune hiérarchisation officielle des priorités ni aucun calendrier d’échéanciers défini pour les mesures de suivi en cours ou à être initiées. Selon la direction du bureau de service de la TI, les tâches sont exécutées dans la mesure du possible, celles que la direction considère comme les plus faciles étant mises en œuvre en premier tandis que les tâches plus complexes sont réalisées une fois que les ressources ont été libérées de l’exécution des tâches plus faciles. Les progrès dans la mise en œuvre des mesures de suivi font l’objet d’un suivi et de rapports à la haute direction lors de réunions mensuelles.

En ce qui concerne les normes de service, nous avons constaté que la GI-ST avait également fait quelques progrès dans ce domaine, notamment grâce à l’élaboration d’indicateurs de rendement et d’objectifs de travail destinés au personnel du bureau de service de la TI. Elle a également mis en œuvre une initiative visant à analyser, suivre et rendre compte de la capacité des ressources du bureau de service de la TI au fil du temps.

Pourquoi est-ce important?

Ces constatations sont importantes parce que les processus et procédures standardisés ainsi que les normes de service permettent au bureau de service de la TI de soutenir les clients, de résoudre les incidents et de fournir d’autres services de TI de manière cohérente et en temps voulu. Une délimitation plus claire des rôles et des responsabilités du personnel dans la mise en œuvre des mesures de suivi restantes, ainsi que des priorités et des échéanciers de conclusion pour les mesures à être mises en place par la suite, faciliteront la planification et le déploiement des ressources.

Développement d’applications – conception de la sécurité

La sécurité fait partie intégrante de la conception et du développement des systèmes d’information et des applications. Elle désigne l’ensemble des mesures prises pour préserver la confidentialité, l’intégrité, la disponibilité et l’utilisation prévue des renseignements stockés, traités ou transmis par voie électronique.

Selon la Directive sur la gestion de la sécurité du Conseil du Trésor (CT) et à la Publication 33 des Conseils en matière de sécurité des technologies de l’information du Centre canadien de cybersécurité (CCC) intitulée La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie (ITSG-33), nous nous attendions à ce que le Ministère ait mis en place les éléments suivants :

Dans l’ensemble, nous sommes arrivés à la conclusion que les processus de conception de la sécurité avaient été intégrés au cours du développement des applications. Cependant, certaines applications ont été mises en production avant que les contrôles de sécurité requis aient pu être entièrement mis en œuvre et avant de recevoir les autorisations de sécurité des autorités compétentes.Note de bas de page 6  Par ailleurs, nous avons conclu que les exigences officielles en matière de formation à la TI pour les développeurs d’applications n’avaient pas été mises en place.

Les processus de conception de la sécurité ont été intégrés au développement des applications, mais ils n’étaient pas toujours achevés avant la mise en production des applications.

Nous avons examiné si les processus de conception de la sécurité étaient intégrés au développement des applications. Avant qu’une application puisse être mise en production, elle doit passer par le processus d’évaluation de la sécurité et d’autorisation (ÉSA) du Ministère, afin de déterminer si les contrôles de sécurité et les autres exigences en matière de sécurité ont été respectés. Elle doit recevoir une autorisation de sécurité officielle émanant des autorités compétentes pour fonctionner dans un environnement de production, y compris l’autorisation du dirigeant principal de l’information (DPI) et du propriétaire de l’application.

Le processus d’ÉSA repose sur les exigences de la Directive sur la gestion de la sécurité du CT et sur les conseils en matière de contrôles de la Publication ITSG-33 du CCC. L’objectif du processus d’ÉSA est de déterminer et d’évaluer les principaux risques de sécurité encourus par les biens de TI, et de s’assurer que des contrôles de sécurité sont mis en œuvre pour atténuer les risques jugés inacceptables. Dans l’ensemble, nous avons constaté que les processus de conception de la sécurité étaient réalisés au cours du développement des applications. Cependant, certaines applications que nous avons examinées n’avaient pas reçu l’autorisation de sécurité requise avant d’être mises en production.

Constatations et analyse

La Directive sur la gestion de la sécurité du CT stipule que des mesures devraient être mises en place pour garantir que seules les applications autorisées sont mises en production. Au sein du Ministère, l’autorisation de mise en production d’une application doit être reçue officiellement du DPI et du propriétaire de l’application. Sur la base d’un échantillon de huit applications (sur les dix) qui ont été développées en interne et mises en production depuis le 1er avril 2019, nous avons constaté que :

La direction de la GI-ST nous a informé que la responsabilité de la mise en production des applications avait été confiée à un groupe unique au sein de la GI-ST. Toutefois, la direction a reconnu que cette pratique n’était pas toujours respectée et que d’autres groupes au sein de la Direction conservaient leur accès à l’environnement de production. Autrement dit, des applications étaient susceptibles d’être mises en production sans avoir reçu l’autorisation appropriée.

Pourquoi est-ce important?       

Cette constatation est importante car, sans un contrôle approprié des accès, les applications risquent d’être mises en production sans l’autorisation adéquate, ce qui expose le Ministère à des risques de sécurité dépassant un niveau acceptable.

Recommandation           

Recommandation 1 : Le directeur des Services numériques devrait veiller à ce que seules les applications qui ont été approuvées par les autorités désignées soient mises en production.

Les exigences officielles de formation à la sécurité des TI pour les développeurs d’applications n’avaient pas été mises en œuvre.

En vertu de la Directive sur la gestion de la sécurité du CT et des conseils en matière de sécurité de l’ITSG 33, une formation à la sécurité est requise pour les personnes assumant des responsabilités spécifiques en matière de sécurité ou qui pourraient avoir une influence sur la réalisation des objectifs de sécurité dans le cadre de leurs fonctions. En outre, cette formation devrait être documentée et suivi de façon à garantir qu’elle continue à répondre aux besoins du Ministère.

Nous avons examiné si les exigences en matière de formation à la sécurité des TI pour les développeurs d’applications avaient été établies et mises en œuvre, et si les progrès de la formation faisaient l’objet d’un suivi. Dans l’ensemble, nous avons constaté que la direction n’avait pas établi officiellement les exigences en matière de formation à la sécurité des TI et n’avait pas identifié les lacunes en matière de compétences et de connaissances liées à la sécurité des TI chez les développeurs d’applications par rapport aux besoins du Ministère.

Constatations et analyse

Bien qu’un projet de programme de formation à la sécurité des TI destiné aux développeurs d’applications ait été initialement élaboré en 2016, les exigences officielles en matière de formation à la sécurité des TI n’avaient pas encore été établies pour les développeurs d’applications. En outre, aucune analyse n’avait été effectuée pour identifier l’existence de lacunes dans les compétences et les connaissances des développeurs d’applications en matière de sécurité des TI par rapport aux besoins particuliers du Ministère en matière de sécurité.

Les gestionnaires ont confirmé que la formation à la sécurité des TI suivie par les développeurs d’applications était établie au cas par cas entre le développeur et son superviseur. Ils ont également fait remarquer que les offres de formation applicables en matière de sécurité des TI étaient difficiles à trouver et que l’identification de telles formations n’était pas une priorité.

Les gestionnaires des équipes de développement d’applications ont mentionné qu’une formation à la sécurité des TI serait utile pour les développeurs d’applications, les chefs d’équipe, les conseillers techniques et les gestionnaires et, plus précisément, une formation qui permettrait de mieux comprendre les attentes en matière de conformité de la sécurité vis-à-vis du processus d’ÉSA. Ils ont également relevé des cas où le manque de clarté quant aux attentes précises en matière de contrôle de la sécurité avait contribué aux retards constatés dans les délais de production des applications.

Pourquoi est-ce important?

Ces constatations sont importantes car la conception de la sécurité fait partie intégrante du processus de développement des applications, lequel repose sur l’existence de personnel ayant reçu une formation adéquate. La formation à la sécurité des TI destinée aux développeurs d’applications permet d’atténuer les risques de sécurité. Elle permet notamment d’empêcher l’accès non autorisé à une application ou de compromettre les renseignements ou les données stockés dans l’application. Par ailleurs, la formation peut aider à éclaircir les attentes en matière de conformité de la sécurité dans le cadre du processus d’ÉSA, et donc à mieux respecter les délais de production des applications.

Recommandation

Recommandation 2 : Le directeur des Services numériques devrait s’assurer que les développeurs d’applications possèdent les compétences et les connaissances nécessaires en matière de sécurité des TI pour répondre aux exigences de sécurité des applications.

Constatations et analyse

Bien qu’un projet de programme de formation à la sécurité des TI destiné aux développeurs d’applications ait été initialement élaboré en 2016, les exigences officielles en matière de formation à la sécurité des TI n’avaient pas encore été établies pour les développeurs d’applications. En outre, aucune analyse n’avait été effectuée pour identifier l’existence de lacunes dans les compétences et les connaissances des développeurs d’applications en matière de sécurité des TI par rapport aux besoins particuliers du Ministère en matière de sécurité.

Les gestionnaires ont confirmé que la formation à la sécurité des TI suivie par les développeurs d’applications était établie au cas par cas entre le développeur et son superviseur. Ils ont également fait remarquer que les offres de formation applicables en matière de sécurité des TI étaient difficiles à trouver et que l’identification de telles formations n’était pas une priorité.

Les gestionnaires des équipes de développement d’applications ont mentionné qu’une formation à la sécurité des TI serait utile pour les développeurs d’applications, les chefs d’équipe, les conseillers techniques et les gestionnaires et, plus précisément, une formation qui permettrait de mieux comprendre les attentes en matière de conformité de la sécurité vis-à-vis du processus d’ÉSA. Ils ont également relevé des cas où le manque de clarté quant aux attentes précises en matière de contrôle de la sécurité avait contribué aux retards constatés dans les délais de production des applications.

Pourquoi est-ce important?

Ces constatations sont importantes car la conception de la sécurité fait partie intégrante du processus de développement des applications, lequel repose sur l’existence de personnel ayant reçu une formation adéquate. La formation à la sécurité des TI destinée aux développeurs d’applications permet d’atténuer les risques de sécurité. Elle permet notamment d’empêcher l’accès non autorisé à une application ou de compromettre les renseignements ou les données stockés dans l’application. Par ailleurs, la formation peut aider à éclaircir les attentes en matière de conformité de la sécurité dans le cadre du processus d’ÉSA, et donc à mieux respecter les délais de production des applications.

Recommandation

Recommandation 2 : Le directeur des Services numériques devrait s’assurer que les développeurs d’applications possèdent les compétences et les connaissances nécessaires en matière de sécurité des TI pour répondre aux exigences de sécurité des applications.

Continuité de la TI

La TI joue un rôle clé dans la capacité du ministère des Pêches et Océans (MPO) à réaliser son mandat. Il est donc important que des plans, des processus et des procédures soient en place pour permettre la continuité et la récupération des applications essentielles à la mission, ou des applications qui soutiennent les programmes et les services essentiels à la mission, en cas de perturbation ou de catastrophe. La Directive sur la gestion de la sécurité du CT exige des ministères qu’ils mettent en place des stratégies de gestion de la continuité de la TI, y compris pour la reprise après sinistre, afin de permettre aux systèmes d’information de conserver ou de retrouver rapidement leur niveau de service normal en cas d’événements de ce genre. Conformément aux exigences du CT, nous nous attendions à ce que le Ministère ait mis en place :

Dans l’ensemble, nous avons constaté que le Ministère avait élaboré un processus de gestion des incidents critiques pour gérer les incidents critiques n’entrainant pas de dommages importants ou de défaillance complète de l’infrastructure de la TI, et lorsque la récupération des applications et des données pouvait être réalisée sur place. Cependant, ce processus n’avait pas encore été officiellement approuvé ni communiqué à tous les intervenants qui jouent un rôle dans la gestion des incidents critiques. En outre, le processus ne comprenait pas de stratégie officielle de reprise après sinistre apte à faire face à des catastrophes majeures telles que des inondations, des incendies ou des attaques de rançongiciels, ni de tests pour valider l’efficacité du processus de gestion de la continuité de la TI.

Certains éléments de la gestion de la continuité de la TI étaient en place, mais ils ne comprenaient pas de stratégie officielle de reprise après sinistre.

Nous avons examiné si les stratégies et les plans de gestion de la continuité de la TI pour la récupération des applications et des données essentielles à la mission avaient été documentés, approuvés, testés et communiqués aux personnes jouant un rôle dans la récupération. Dans l’ensemble, nous avons constaté que le Ministère avait mis en place certains éléments de gestion de la continuité de la TI sous la forme d’un processus de gestion des incidents critiques, mais qu’il ne comprenait aucune stratégie pour faire face à d’éventuelles catastrophes ou perturbations majeures concernant des biens de TI.

Constatations et analyse

Gestion de la continuité de la TI

La gestion de la continuité de la TI consiste à définir les applications qui soutiennent les programmes et les services essentiels à la mission, à élaborer des stratégies de continuité et des mesures d’atténuation, et à s’assurer que ces applications peuvent continuer à fonctionner en cas de perturbation ou de catastrophe. Les principaux résultats d’un processus de gestion de la continuité de la TI sont notamment les suivants :

La gestion de la continuité de la TI est une responsabilité partagée entre les ministères et Services partagés Canada (SPC). SPC gère et assure l’entretien de la majorité des infrastructures essentielles à la gestion de la continuité de la TI, notamment les serveurs, les réseaux et les centres de données. Le Ministère des Pêches et Océans (MPO) est responsable de l’établissement et de la mise à l’essai des plans de continuité de la TI ainsi que de la communication des exigences de continuité à SPC.

Nous avons constaté que le Ministère avait développé certains éléments de gestion de la continuité de la TI dans le cadre de sa responsabilité de permettre la continuité des applications essentielles à la mission. Il s’agit notamment d’un processus de gestion des incidents critiques, qui a été lancé en décembre 2018, ainsi que de procédures opérationnelles standards pour exécuter le processus de gestion des incidents critiques. Le processus de gestion des incidents critiques a été conçu pour faire face aux incidents qui ne provoquent pas de dommages physiques importants ou de défaillance de l’infrastructure de la TI, et lorsque la récupération des applications et des données critiques peut être effectuée sur place, comme les incidents impliquant des pannes d’applications.

Cependant, nous avons constaté que le processus de gestion des incidents critiques présentait certaines limites importantes. Nous avons constaté, notamment, que les stratégies visant à assurer la continuité des applications essentielles à la mission du Ministère, après une perturbation ou une catastrophe majeure sur un site touché, n’ont été ni élaborées ni documentées. Cet aspect est important car, en cas d’événement majeur rendant un site primaire inaccessible et inapte à fonctionner, les opérations et les services de TI devraient être facilement transférés sur un site secondaire afin d’assurer la continuité des applications essentielles à la mission.

Bien que SPC soit responsable des défaillances ou des dommages à l’infrastructure de la TI ayant une incidence sur le Ministère, aucun accord officiel entre les deux organisations n’était en place pour garantir la disponibilité et la continuité des applications et des données essentielles à la mission pendant de tels événements. La récupération est au contraire censée être effectuée autant que possible, ce qui signifie que le Ministère et SPC tenteraient de récupérer et de restaurer les applications dans la mesure où leurs ressources le leur permettraient à ce moment-là. De plus, les dispositifs de dépannage qui permettraient aux applications critiques de continuer à fonctionner sur des sites secondaires n’avaient pas été établis. Le Ministère a conclu une entente de service avec SPC en avril 2020, qui prévoit que SPC fournisse un soutien de secours 24 heures sur 24 et 7 jours sur 7 pour les serveurs hébergeant la majorité des applications essentielles à la mission du Ministère. Auparavant, SPC ne fournissait ce soutien que pendant les heures normales de fonctionnement.

Un autre risque important pour la gestion de la continuité de la TI a été souligné lors d’entretiens avec la direction de la Gestion de l’information et des services de la technologie (GI-ST). Cette dernière a en effet expliqué qu’un grand nombre d’applications essentielles à la mission du Ministère sont considérées comme anciennes. La direction de la GI-ST n’était pas certaine non plus sur jusqu’à quel point les anciennes applications pouvaient être récupérées ou restaurées en cas de catastrophe majeure ou de défaillance complète. Elle a ajouté que ces applications ne pouvaient pas être facilement remises en service et intégrées à l’infrastructure de la TI et aux technologies modernes.

Essais de continuité de la TI

La Directive sur la gestion de la sécurité du CT exige des ministères qu’ils testent les processus de gestion de la continuité de la TI de manière à assurer un état de préparation acceptable. Ces tests font partie intégrante de la gestion globale de la continuité des activités ministérielles. Nous avons constaté que les processus de gestion des incidents critiques du Ministère ne prévoyaient pas de tests et qu’aucun test des applications essentielles à la mission dans le cadre de scénarios d’incidents critiques potentiels n’avait été réalisé. Les tests périodiques permettent d’assurer que les processus de continuité de la TI fonctionneront en cas d’incident critique réel. Ils permettent également de cerner des défis imprévus, d’en retenir les leçons, puis de les intégrer aux processus et procédures de gestion des incidents critiques.

Pourquoi est-ce important?       

Ces constatations sont importantes parce qu’il est indispensable de disposer de processus efficaces de gestion de la continuité de la TI pour garantir que les programmes et les services du Ministère pourront continuer à fonctionner aussi normalement que possible, en cas d’incident critique ou de catastrophe majeure. La TI est la colonne vertébrale de nombreux programmes et services que le Ministère offre dans le cadre de son mandat.

Recommandation           

Recommandation 3 : Le directeur des Services numériques devrait s’assurer que des stratégies d’atténuation sont élaborées pour les applications essentielles à la mission, afin de pouvoir faire face à d’éventuelles catastrophes majeures, et que ces applications sont régulièrement testées dans le contexte de scénarios d’incidents critiques et de catastrophes.

Sécurité informatique – Autorisation d’exploitation

Le processus d’évaluation de la sécurité et d’autorisation (ÉSA) de la sécurité des TI du Ministère est un contrôle de gestion des risques fondé sur la Directive sur la gestion de la sécurité du Conseil du Trésor (CT) et sur les conseils de la Publication ITSG-33 du Centre canadien de cybersécurité (CCC). Le processus d’ÉSA vise à établir et maintenir la confiance dans la sécurité des systèmes d’information utilisés par le MPO.

Selon la Directive sur la gestion de la sécurité du CT et aux conseils de la Publication ITSG-33 du CCC, nous nous attendions à ce que le Ministère ait mis en place des processus visant à assurer que :

Dans l’ensemble, nous avons constaté que, pour les applications que nous avons examinées, les évaluations de sécurité et les décisions d’autorisation, y compris l’acceptation officielle du risque résiduel, étaient documentées. Cependant, les autorisations ne faisaient généralement l’objet d’aucun maintien. En conséquence, les autorisations de sécurité d’un grand nombre d’applications avaient expiré.

L’autorisation d’exploitation des applications dans un environnement de production ne faisait pas l’objet d’une évaluation périodique tout au long de leur cycle de vie opérationnel.

Nous avons examiné si les évaluations de sécurité et les décisions d’autorisation, y compris l’acceptation officielle du risque résiduel, étaient documentées. Nous avons également examiné si l’autorisation de sécurité qui permet aux applications de fonctionner dans un environnement de production faisait l’objet d’une évaluation et d’un entretien périodiques tout au long de leur cycle de vie opérationnel. Dans l’ensemble, nous avons constaté que, bien que les évaluations de sécurité soient documentées et que l’équipe de sécurité des TI ait établi des exigences pour évaluer périodiquement les autorisations de sécurité des applications, ces autorisations ne faisaient en général l’objet d’aucun maintien, et que les autorisations d’un grand nombre d’applications étaient arrivées à expiration.

Constatations et analyse

Évaluations de la sécurité et autorisations (ÉSA)

Sur la base de l’échantillon des huit applications examinées précédemment, nous avons constaté que les évaluations de sécurité, les décisions d’autorisation et l’acceptation du risque résiduel étaient documentées pour les huit applications.

Évaluation et maintien des autorisations de sécurité

La Directive sur la gestion de la sécurité du CT exige que l’autorisation de sécurité soit maintenue tout au long du cycle de vie opérationnel d’un système ou d’une application. Nous avons constaté que la sécurité des TI avait mis en place des outils et des pratiques pour suivre l’expiration des autorisations de sécurité des applications ministérielles. Basés sur une évaluation des risques liés aux contrôles de sécurité existants pour une application donnée, la sécurité des TI recommandera l’un des trois niveaux d’autorisation suivants : 1) l’autorisation d’exploitation complète, 2) l’autorisation provisoire d’exploitation ou 3) le refus d’autorisation. Ces niveaux d’autorisation sont décrits plus en détail à l’annexe C.

En 2019, la sécurité des TI a établi une nouvelle pratique selon laquelle les propriétaires d’applications doivent être informés six mois avant l’expiration afin d’entamer le processus de renouvellement de l’autorisation de sécurité. En outre, la sécurité des TI doit assurer un suivi pendant et après l’expiration des autorisations de sécurité, si les propriétaires des applications ne répondent pas.

Nous avons examiné si les autorisations de sécurité des applications ministérielles étaient en cours de validité ou avaient expiré. Basés sur une analyse du journal de suivi de la sécurité des TI au 27 juillet 2021, nous avons constaté que les autorisations de sécurité n’étaient généralement pas maintenues tout au long du cycle de vie opérationnel des applications. Sur les 133 applications qui avaient reçu une autorisation d’exploitation, 77 % (103) avaient des autorisations expirées. En décomposant par niveau d’autorisation, nous avons constaté ce qui suit :Note de bas de page 8  

Pour comprendre pourquoi les autorisations de certaines applications étaient arrivées à expiration depuis plusieurs années, nous avons effectué le suivi d’un petit échantillon d’applications. Nous avons constaté que, dans certains cas, le processus d’autorisation de sécurité était bloqué en attente d’une réponse du propriétaire de l’application et, dans d’autres cas, la sécurité des TI n’avait pas assuré de suivi. Lors des entretiens, les problèmes de capacité en matière de ressources – plus précisément, les budgets de ressources et la rotation du personnel au sein de la GI-ST, ainsi que dans les programmes et services du MPO – ont souvent été cités comme les principales raisons expliquant l’expiration prolongée des autorisations de sécurité. Nous avons également été informés que des applications restaient en production alors que leurs autorisations avaient expiré et qu’aucun plan officiel n’avait été mis en place pour résorber l’arriéré.

Pourquoi est-ce important?       

Ces constatations sont importantes parce que les autorisations de sécurité garantissent que les applications ministérielles ont toujours les contrôles de sécurité requis lors de leur utilisation dans un environnement de production. Un grand nombre d’autorisations de sécurité expirées exposerait le Ministère à des risques de sécurité supérieurs aux niveaux jugés acceptables.

Recommandation           

Recommandation 4 : Le directeur des Services numériques devrait s’assurer que le processus pour évaluer et maintenir les autorisations de sécurité des applications ministérielles est revu dans le but d’améliorer son efficacité, tout en tenant compte des besoins en matière de sécurité.

Adoption de l’informatique en nuage

Le MPO a récemment entamé la transition vers l’informatique en nuage afin de moderniser la prestation de ses services pour les Canadiens. Ce changement est en accord avec la stratégie d’adoption de l’informatique en nuage d’abord, du gouvernement du Canada, publiée en 2016, qui obligeait tous les ministères et organismes à accorder la priorité aux applications, aux plateformes et aux infrastructures en nuage avant de recourir à des applications sur place ou hébergées par Services partagés Canada. L’informatique en nuage représente un nouveau modèle d’acquisition de logiciels de stockage et de ressources informatiques. Conformément à la stratégie de l’informatique en nuage d’abord et à la Directive sur les services et le numérique du Conseil du Trésor, il était attendu que le Ministère ait :

Dans l’ensemble, nous avons conclu que le Ministère avait mis en place une structure de gouvernance officielle pour superviser l’adoption de l’informatique en nuage, et que le suivi des progrès et la production de rapports se faisaient régulièrement. Toutefois, même si une stratégie est en place, il y a eu des retards dans la mise en œuvre de l’adoption, y compris pour deux éléments clés considérés comme essentiels pour assurer une adoption plus large de l’informatique en nuage au sein du Ministère, sans qu’aucun échéancier précis n’ait été établi pour leur achèvement.

Une structure de gouvernance pour l’adoption de l’informatique en nuage a été mise en place. Toutefois, les rôles et les responsabilités n’avaient pas été suffisamment définis ou communiqués aux intervenants.

Nous avons examiné si une structure de gouvernance était en place pour superviser l’adoption de l’informatique en nuage au sein du Ministère, et si les rôles, les responsabilités et les obligations de rendre compte pour l’informatique en nuage avaient été bien définis, communiqués et compris. Dans l’ensemble, nous avons constaté qu’une structure de gouvernance avait été mise en place pour superviser l’adoption de l’informatique en nuage au sein du Ministère. Toutefois, les rôles et les responsabilités pour l’adoption de l’informatique en nuage, particulièrement pour ceux au niveau opérationnel, n’avaient pas encore été suffisamment définis ou communiqués.

Constatations et analyse

Gouvernance

Nous avons constaté qu’une structure de gouvernance avait été mise en place pour superviser l’adoption de l’informatique en nuage au sein du Ministère, et qu’elle était dirigée par le Comité directeur du programme de l’informatique en nuage du MPO. Ce Comité directeur relevait du Comité consultatif national sur le numérique du Ministère, et son rôle était de fournir à la haute direction du MPO des conseils et des directives concernant les initiatives et les projets liés à l’informatique en nuage.

Rôles et responsabilités

Nous avons constaté que même si une matrice qui expliquait et présentait les rôles et responsabilités pour l’adoption de l’informatique en nuage avait été préparée, il n’y avait pas d’échéance clairement définie pour l’approbation et la communication aux intervenants au sein du Ministère. Dans plusieurs entrevues, les intervenants ont indiqué que les rôles et les responsabilités – principalement pour ceux au niveau opérationnel – pour l’adoption de l’informatique en nuage n’étaient pas toujours bien compris. De plus, des fonctions clés pour la gestion des actifs en nuage, ainsi que pour la gestion des incidents et des changements pour les applications et les systèmes liés au nuage, n’avaient pas encore été définies.

Pourquoi est-ce important?

Ces constatations sont importantes car des structures de gouvernance solides ayant des rôles, des responsabilités et des obligations de rendre compte clairement définis et communiqués sont essentielles à une adoption réussie de l’informatique en nuage au sein du Ministère. Elles permettent de prendre des décisions efficaces, d’allouer et d’aligner les ressources en nuage, et d’atténuer les retards ou la duplication des efforts lors de l’adoption.

Deux des initiatives de la stratégie d’adoption de l’informatique en nuage du Ministère n’avaient pas d’échéance définie.

Nous avons cherché à déterminer si le Ministère avait élaboré un plan pour la mise en œuvre de l’adoption de l’informatique en nuage, et s’il assurait un suivi de sa mise en œuvre. Dans l’ensemble, nous avons constaté que le Ministère avait élaboré une stratégie d’adoption de l’informatique en nuage, et que des plans de mise en œuvre étaient en place et faisaient l’objet de suivis pour deux des quatre initiatives de la stratégie. Bien qu’on ait commencé à travailler sur les deux autres initiatives, des plans de mise en œuvre n’avaient pas encore été élaborés pour guider ce travail. De plus, on nous a dit que deux des éléments clés considérés comme essentiels pour assurer une mise en œuvre complète de la stratégie avaient pris du retard, et qu’aucun échéancier précis n’avait été établi pour leur achèvement.

Constatations et analyse

Nous avons constaté que le Ministère avait établi une stratégie d’adoption de l’informatique en nuage, et qu’elle avait été officiellement approuvée par la haute direction du MPO en juin 2020. La stratégie se composait de quatre initiatives principales :

  1. Environnement de l’informatique en nuage et services standard
  2. Migration de la charge de travail vers le nuage
  3. Expertise en matière d’informatique en nuage et changement de culture
  4. Stratégie financière pour l’informatique en nuage

De plus, des plans de mise en œuvre avaient été élaborés pour les deux premières initiatives dans le cadre de la stratégie d’adoption de l’informatique en nuage, dont la mise en œuvre était prévue le 31 mars 2022. La direction a suivi les progrès des deux initiatives et a produit des rapports sur ces progrès de façon régulière par des tableaux de bord mensuels ainsi que par des mises à jour fournies aux comités d’examen des projets et au Comité consultatif national sur le numérique du Ministère.

Toutefois, deux éléments clés considérés comme essentiels par la direction de la Gestion de l’information et des services de la technologie (GI-ST) pour mettre en œuvre les deux initiatives, et pour assurer une adoption plus large de l’informatique en nuage au sein du Ministère, étaient en retard et risquaient de ne pas être terminés à l’échéance prévue du 31 mars 2022. Le premier élément nécessitait la mise en œuvre de contrôles de sécurité appropriés sur la plateforme de l’informatique en nuage qui hébergera les applications stockant des renseignements protégés. Le deuxième élément nécessitait la mise en œuvre de la technologie d’activation et de défense du nuage sécurisé (ADNS), qui permet une connexion sécurisée entre les systèmes d’information du MPO et le nuage. SPC est responsable du déploiement de cette technologie.

Bien qu’on ait commencé à travailler sur les deux autres initiatives, des plans de mise en œuvre n’avaient pas encore été élaborés pour guider ce travail.

Pourquoi est-ce important?       

Ces constatations sont importantes car la transition à l’informatique en nuage pour la prestation des services de TI a été désignée comme une priorité à l’échelle du gouvernement et du Ministère. Des retards dans la mise en œuvre de la stratégie, particulièrement les retards liés aux éléments permettant d’assurer des environnements d’informatique en nuage sécurisés pour les applications stockant des renseignements protégés, pourraient entraîner des retards dans l’intégration des applications prêtes pour le nuage.

Annexe A : Secteurs d’intérêt et critères d’audit

Les critères d’audit ont été établis au moyen des sources suivantes :

Secteurs d’intérêt et critères d’audit
Critères d'audit Conclusion
Secteur d’intérêt 1 – Centre de services TI
Critère 1.1 : Le Centre de services TI a des processus et des procédures standardisés en place pour fournir des services informatiques et résoudre les incidents, des normes de service sont établies et le rendement par rapport à ces normes est mesuré et fait l’objet de rapports. Partiellement respecté
Secteur d’intérêt 2 – Développement d’applications
Critère 2.1 : Les processus de conception de la sécurité des systèmes sont intégrés au développement des applications. Partiellement respecté
Critère 2.2 : Les exigences en matière de formation à la sécurité des TI pour les développeurs d’applications sont identifiées et les progrès de la formation font l’objet d’un suivi. Partiellement respecté
Secteur d’intérêt 3 – Continuité de la TI
Critère 3.1 : Les stratégies et les plans de gestion de la continuité de la TI pour la récupération des systèmes et des données sont documentés, approuvés, testés et communiqués à ceux jouant un rôle dans la reprise après sinistre. Partiellement respecté
Secteur d’intérêt 4 – Sécurité des TI
Critère 4.1 : Les autorisations de sécurité permettant l’exploitation des systèmes d’information dans un environnement de production sont évaluées et maintenues tout au long du cycle de vie opérationnel des systèmes. Partiellement respecté
Critère 4.2 : Les évaluations de sécurité et les décisions d’autorisation sont consignées, y compris l’acceptation officielle du risque résiduel par une personne ayant l’autorité requise. Partiellement respecté
Secteur d’intérêt 5 – Adoption du nuage
Critère 5.1 : Les rôles, les responsabilités et les obligations de rendre compte en matière de gouvernance et de structures fonctionnelles pour l’informatique en nuage sont définis, communiqués et compris. Partiellement respecté
Critère 5.2 : Un plan de mise en œuvre de la stratégie d’adoption de l’informatique en nuage du Ministère est en place et fait l’objet de suivis. Partiellement respecté

Annexe B : Réponse et plan d’action de la direction

Réponse et plan d’action de la direction
Recommandation Plan d’action Gestionnaires responsables Produits livrables Date d’achèvement prévue
Recommandation 1 :
Le directeur des Services numériques devrait veiller à ce que seules les applications qui ont été approuvées par les autorités désignées soient mises en production.

La direction est d'accord avec la recommandation.
a. Précisez tous les éléments de l'autorisation d'exploitation (AE) y compris l'approbation de la sécurité informatique dans la charte du projet ou du produit. Directeur, Gouvernance de projets et de produits a. Charte de projet révisée.
La charte de projet/produit comprend tous les éléments AE.
31 décembre 2022
b. Inclure les exigences d'évaluation et d'autorisation de sécurité (EAS) dans les processus de contrôle du cadre de gestion de projet (CGP) et vérifier à chaque point d'accès respectif lors de la réunion du comité d'examen des points d'accès. Directeur, Gouvernance de projets et de produits b. Liste de vérification de la gestion de projet.
c. Examiner et mettre à jour le processus de gestion des versions pour inclure la vérification de l'autorisation provisoire d'exploitation (AEP) ou de l'autorisation d'exploitation (AE) avant toute version de production. Prévoyez également de doter l'équipe de sécurité informatique en personnel en conséquence pour respecter le plan de publication révisé. Directeur général, Innovation numérique & Directeur, cybersécurité c. Le document de gestion des versions est examiné, mis à jour et approuvé par le directeur général de l'innovation numérique.

Le plan des RH doit inclure les mesures de dotation requises.

Les mesures de dotation sont lancées et/ou finalisées.
Recommandation 2 :
Le directeur des Services numériques devrait s’assurer que les développeurs d’applications possèdent les compétences et les connaissances nécessaires en matière de sécurité des TI pour répondre aux exigences de sécurité des applications.

La direction est d'accord avec la recommandation.
a. Développer un programme de formations et/ou de certifications en matière de sécurité des technologies de l'information (TI) pour les développeurs. Directeur général, Innovation numérique a. La formation est identifiée et/ou développée. 31 décembre 2022
b. Élaborer un plan qui créerait et maintiendrait une bibliothèque de solutions pour les contrôles de sécurité informatique. Tout projet s'abonnerait alors à cette bibliothèque pour répondre de manière commune à ses exigences en matière de sécurité informatique. Directeur, Cybersécurité b. Élaboration d'un programme d'études et d'un ensemble de connaissances sur le développement, la sécurité et les opérations.
c. Créer une équipe affectée aux projets pour analyser le code à la recherche de vulnérabilités à l'aide d'outils désignés, et fournissez des rapports et des recommandations à l'équipe de projet. Directeur général, Innovation numérique c. Dans le cadre du nouvel organigramme, une nouvelle équipe de sécurité du développement d'applications est créée avec un mandat clair pour soutenir l'activité de développement d'applications.
Recommandation 3 :
Le directeur des Services numériques devrait s’assurer que des stratégies d’atténuation sont élaborées pour les applications essentielles à la mission afin de pouvoir faire face à d’éventuelles catastrophes majeures, et que ces applications sont régulièrement testées dans le contexte de scénarios d’incidents critiques et de catastrophes.

La direction est d'accord avec la recommandation.
a. Pour les nouveaux projets, s’assurez qu'ils spécifient et mettent en œuvre tous les éléments de l'autorité d'exploitation (AE), y compris l'accord sur les niveaux de service (ANS) requis et les plans de continuité dans la charte du projet/produit. Directeur principal, Planification stratégique a. Confirmer les dépendances informatiques des services essentiels du MPO.
b. Documenter le plan récapitulatif global de reprise après sinistre et la gouvernance.
c. Documenter le plan de reprise après sinistre pour chaque application critique.
d. Effectuer une évaluation des écarts de reprise après sinistre.
e. Définir et mettre en œuvre le calendrier annuel des tests.
f. Recommandations pour résoudre l'évaluation des lacunes consultée auprès du Comité consultatif national sur le numérique.
31 décembre 2023
Recommandation 4 :
Le directeur des Services numériques devrait s’assurer que le processus pour évaluer et maintenir les autorisations de sécurité des applications ministérielles est revu dans le but d’améliorer son efficacité, tout en tenant compte des besoins en matière de sécurité.

La direction est d'accord avec la recommandation.
a. Examiner le processus d'évaluation et d'autorisation de sécurité (EAS) pour :
  • s'aligner sur le modèle DevOps d'intégration continue et de déploiement continu; et
  • permettre une analyse/conception delta d'une phase de projet/produit à l'autre.
Directeur, Cybersécurité a. Processus d'évaluation et d'autorisation de sécurité (EAS) amélioré avec :
  • différents processus par profil de risque ; et
  • lignes directrices pour l'analyse delta.
31 mars 2023
b. Établir un processus pour examiner régulièrement les AE sur le point d'expirer et engager les équipes de développement d'applications dès le début des activités de renouvellement. Directeur, Cybersécurité b. Inventaire des systèmes avec profil Confidentialité, Intégrité, Disponibilité (CID) et statut d’AE avec dates d'expiration.

Processus d'examen continu des AE qui arrivent bientôt à expiration.

Annexe C : Niveaux des autorisations de sécurité des applications ministérielles

La dernière étape du processus d’évaluation de la sécurité et de l’autorisation est l’émission de l’Énoncé d’autorisation. L’Énoncé d’autorisation comprend une évaluation de tous les risques résiduels à la sécurité associés à l’exploitation de l’application dans un environnement de production. En s’appuyant sur cette évaluation des risques, la Sécurité des TI peut recommander un des trois niveaux d’autorisation de sécurité au DPI et au propriétaire de l’application :

Autorisation d’exploitation complète – Peut être accordée pendant un maximum de trois ans à partir de la date à laquelle l’autorisation a été approuvée. Les applications auxquelles on accorde une autorisation d’exploitation complète sont conformes aux exigences de contrôles de sécurité pertinentes.

Autorisation provisoire d’exploitation – Dans le but d’équilibrer les besoins opérationnels des programmes et des services du MPO, on peut accorder une autorisation provisoire d’exploitation pendant un an aux applications qui ne répondent pas à toutes les exigences de sécurité, mais dont les contrôles de sécurité qui restent à régler sont considérés comme ne dépassant pas un niveau acceptable de risque.

Pour qu’on accorde une autorisation provisoire d’exploitation à une application, il faut qu’il y ait un plan pour mettre en place les contrôles de sécurité qui restent à régler, démontrant comment les contrôles seront mis en œuvre pendant la période provisoire d’exploitation. Si ces contrôles ne sont pas mis en œuvre dans le délai d’un an, la Sécurité des TI peut prolonger la période d’autorisation provisoire ou peut recommander de retirer l’application de la production.

Refus d’autorisation – S’il est déterminé que le risque de sécurité associé à une application dépasse un niveau de risque acceptable, un refus d’autorisation peut être émis. Dans ce cas, il sera interdit d’utiliser l’application dans un environnement de production tant que des mesures de contrôle appropriées ne sont pas mises en œuvre pour atténuer les risques à un niveau acceptable.

 

Date de modification :