Comment un fournisseur d’identité IL4 réussit à desservir les environnements IL5

En adoptant le cloud et les nouveaux standards, le ministère de la Défense (DoD) des États-Unis peut faire progresser ses systèmes d’information et orienter la modernisation de la cybersécurité, comme l’exige le pilier 1 de la National Cybersecurity Strategy, section 3 du décret présidentiel (Executive Order) 14028, Improving the Nation’s Cybersecurity, et la section 1 du Memorandum on Improving the Cybersecurity of National Security, Department of Defense, and Intelligence Community Systems (NSM8). 

Toutefois, l’objectif du ministère, à savoir une infrastructure moderne, riche en informations sur les menaces pour le combattant, ne peut être atteint seul. La campagne visant à sécuriser les services cloud est une responsabilité partagée entre les responsables de mission du DoD et les fournisseurs de services cloud. Le document Cloud Computing Security Requirements Guide de la DISA (Defense Information Systems Agency) décrit ces directives et fournit un framework pour l’implémentation de solutions cloud commerciales.

Les niveaux d’impact (IL) constituent la base de ce framework. Chaque IL correspond à un niveau spécifique de sensibilité et de risque des informations, ainsi qu’à un sous-ensemble des contrôles de sécurité de l’instruction n° 1253 du Committee on National Security Systems (CNSSI). Ces niveaux d’impact dictent également les exigences de connectivité, dont certaines incluent des points d’accès au cloud (CAP). Les CAP offrent une connexion pour les offres cloud afin de se connecter au NIPRNet via une pile de sécurité de la DISA ou d’un service. La DISA a créé un processus de framework de gestion des risques (RMF) pour l’évaluation et l’autorisation des offres de services cloud (RSI), spécialement conçu pour le DoD, et qui existe en parallèle au programme FedRAMP (Federal Risk and Authorization Management Program).

Comprendre à quel niveau un RSI doit opérer est simple. Il suffit de comprendre la mission et les données qu’elle traite. Voici quelques exemples :
 

Le parcours d’Okta avec le DoD

Au cours de l’année écoulée, Okta a travaillé avec diligence avec la DISA pour étendre notre offre Identity-as-a-Service (IDaaS) au DoD et à ses partenaires de mission dans un environnement exclusif, sans restrictions d’approbation du programme pilote. Nous avons mené à bien cet effort, qui a abouti à une nouvelle autorisation provisoire conditionnelle (PA) pour Okta for US Military. Une partie de cette étape importante est une reconnaissance par le responsable de l’autorisation (AO) de la DISA de l’IDaaS Okta en tant que service de gestion des identités et des accès pour les environnements IL5.

Comment un IDaaS de niveau IL4 peut-il être utilisé pour la gestion des accès à un système IL5 ? Pour répondre à cette question, nous devons revenir sur la question des contrôles et des données.

Commençons par les données. L’IDaaS est une plateforme de gestion des identités et des accès (IAM) basée sur le cloud qui fournit un point de gestion centralisé pour accéder à d’autres systèmes et applications, mais elle ne « traite » pas les données au sens traditionnel du terme. Dans un tel contexte, quel type de données serait-il opportun de stocker dans un annuaire d’utilisateurs ? Il n’est pas envisageable d’y conserver des données de sécurité nationale, des informations personnelles sensibles identifiables ou des informations médicales protégées comme attribut de compte. L’un des principes du modèle Zero Trust est de supposer que l’adversaire a déjà accédé à votre environnement. Placer des informations protégées dans un compte faciliterait la tâche des acteurs malveillants. Si nous considérons l’IDaaS comme une fonction de facilitation pour un système global (ou une famille de systèmes), il devient logique d’en conclure qu’il faut éviter de stocker des données protégées dans un annuaire. Par exemple, si vous avez besoin d’un identifiant unique pour le personnel, envisagez d’utiliser les identifiants EDIPI (Electronic Data Interchange Personnel Identifier) et non les numéros de sécurité sociale (SSN).

Le deuxième facteur est le modèle d’héritage des contrôles. L’IDaaS fournit des contrôles héritables basés sur sa fonctionnalité dans le cadre d’une architecture système globale. Okta System Security Plan (SSP) et les contrôles héritables deviennent une référence précieuse pour toute personne concevant un modèle d’héritage. Étant donné que l’IDaaS ne stocke aucune donnée CUI, la majeure partie des contrôles supplémentaires relevant de l’IL5 doivent être appliqués aux systèmes qui stockent les données CUI. Okta peut vous aider à répondre à ces exigences supplémentaires dans le cadre d’une approche hybride. Dans cette optique, seuls les contrôles sur lesquels Okta a un impact direct sont marqués comme héritables. Par exemple, Okta fournit un chiffrement FIPS 140-2 aux données stockées en son sein, mais pas aux données de votre système de maintenance des opérations de combat.

Le dernier facteur est l’investissement supplémentaire d’Okta dans l’hébergement de l’environnement sur un domaine .mil et la limitation de son utilisation aux seules entités approuvées par le DoD, une étape importante dans notre engagement continu envers le DoD. Ces composants architecturaux (données, contrôles et exclusivité) sont les facteurs logiques qui ont permis à la DISA d’accorder à Okta for US Military une autorisation provisoire conditionnelle au niveau IL4 et d’autoriser l’utilisation d’IDaaS pour soutenir les environnements IL5. Cette situation unique est gage de l’avenir d’Okta en tant que leader de la migration vers le cloud du DoD et des initiatives Zero Trust.

Pour en savoir plus sur cet effort et sur les applications IL5 avec lesquelles nous nous intégrons, téléchargez notre livre blanc intitulé Deploying Modern Identity for National Security ou contactez-nous à l’adresse federal@okta.com.