Como um provedor de identidade IL4 consegue atender ambientes IL5

Graças à adoção da nuvem e dos novos padrões, o Departamento de Defesa (DoD) dos Estados Unidos pode aprimorar seus sistemas de informação e orientar a modernização da segurança cibernética, conforme exigido no Pilar 1 da National Cybersecurity Strategy (Estratégia Nacional de Segurança Cibernética), Seção 3 da Ordem Executiva (EO) 14028, Improving the Nation’s Cybersecurity (Melhorando a segurança cibernética da nação), e Seção 1 do Memorando de Segurança Nacional sobre Improving the Cybersecurity of National Security, Department of Defense, and Intelligence Community Systems (NSM8) (Aumentando a segurança cibernética da segurança nacional, do Departamento de Defesa e dos sistemas da comunidade de inteligência (NSM8)). 

No entanto, o Departamento não é capaz de alcançar sozinho seu objetivo de ter uma infraestrutura moderna e informada sobre ameaças para o combatente. A campanha para proteger os serviços na nuvem é uma responsabilidade compartilhada entre os proprietários de missão do Departamento de Defesa e os provedores de serviços na nuvem (CSPs). O Guia de Requisitos para a Segurança da Computação em Nuvem (CC SRG) da Agência de Sistemas de Informação de Defesa (DISA) documenta essas diretrizes e fornece uma estrutura para implementar a computação em nuvem disponível comercialmente.

Os níveis de impacto formam a base dessa estrutura. Cada nível de impacto se alinha a um nível específico de sensibilidade e risco da informação e a um subconjunto dos Controles de Segurança nº 1253 do Comitê de Instruções para Sistemas de Segurança Nacional (CNSSI). Esses níveis de impacto também ditam os requisitos de conectividade, alguns dos quais incluem Pontos de Acesso a Nuvens (CAPs). Os CAPs fornecem uma conexão para ofertas de nuvem se conectarem à NIPRNet por meio de uma pilha de segurança de serviço ou da DISA. A DISA criou um processo de Estrutura de Gerenciamento de Riscos (RMF) para a avaliação e a autorização de Ofertas de Serviço na Nuvem (CSOs), adaptado especificamente para o Departamento de Defesa dos EUA, e que existe em paralelo com o Programa Federal de Gerenciamento de Riscos e Autorização (FedRAMP).

Entender em que nível um determinado CSO precisa operar é simples. Basta entender a missão e os dados que ele está processando. Aqui estão alguns exemplos:
 

A jornada do Departamento de Defesa na Okta

Durante o ano passado, a Okta trabalhou diligentemente com a DISA para levar nossa oferta de identidade como serviço (IDaaS) ao Departamento de Defesa dos Estados Unidos e seus parceiros de missão em um ambiente exclusivo, sem restrições de aprovação de programas piloto. Concluímos esse esforço, que culminou em uma nova Autorização Provisória (PA) condicional para o Okta for US Military. Parte desse marco é o reconhecimento do Agente de Autorização (AO) da DISA no IDaaS da Okta como um serviço de gerenciamento de identidade e acesso para ambientes IL5.

Como um IDaaS IL4 pode ser utilizado para o gerenciamento de acesso em um sistema IL5? Para responder a essa pergunta, precisamos voltar aos controles e dados.

Vamos começar com os dados. O IDaaS é uma plataforma de gerenciamento de identidade e acesso (IAM) baseada em nuvem que fornece um ponto de gerenciamento central para acessar outros sistemas e aplicativos, mas não “processa” dados no sentido tradicional. Que tipo de dados você gostaria de armazenar em um diretório de usuários? Seria difícil encontrar a necessidade de armazenar dados de segurança nacional, informações pessoais identificáveis sensíveis (SPII) ou informações de saúde protegidas (PHI) como um atributo de conta. Um dos princípios do modelo Zero Trust é presumir que o adversário já teve acesso ao seu ambiente. A presença de informações protegidas em uma conta facilitaria o trabalho do agente! Se observarmos o IDaaS como uma função capacitadora para um sistema geral (ou família de sistemas), é fácil ver que devemos evitar o armazenamento de dados protegidos em um diretório. Por exemplo, se você precisar de um identificador exclusivo para o pessoal, considere usar o Identificador de Pessoal de Intercâmbio Eletrônico de Dados (EDIPI) e não o Número de Seguro Social (SSN).

O segundo fator é o modelo de herança de controles. O IDaaS fornece controles herdáveis com base em sua funcionalidade como parte de uma arquitetura geral do sistema. O System Security Plan (SSP) da Okta e os controles herdáveis se tornam uma referência inestimável para qualquer pessoa que esteja projetando um modelo de herança. Como o IDaaS não armazena informações não classificadas controladas, a maior parte dos controles adicionais no IL5 deve ser utilizada contra os sistemas que armazenam tais informações. A Okta pode ajudar a cumprir esses requisitos adicionais como parte de uma abordagem híbrida. Com isso em mente, apenas os controles que a Okta impacta diretamente são marcados como herdáveis. Por exemplo, a Okta fornece criptografia FIPS 140-2 para os dados armazenados nela mesma, mas não os dados em seu sistema de manutenção de combate.

O fator final são os investimentos adicionais da Okta na hospedagem do ambiente em um domínio .mil e na restrição do uso apenas a entidades aprovadas pelo Departamento de Defesa — um passo importante em nosso compromisso contínuo com ele. Esses componentes arquitetônicos (dados, controles e exclusividade) são os fatores lógicos que permitiram que a DISA concedesse uma PA condicional no IL4 ao Okta for US Military e permitisse o uso de IDaaS para suporte a ambientes IL5. Essa situação única exemplifica o futuro da Okta como líder na migração do Departamento de Defesa para a nuvem e nos esforços de Zero Trust.

Para saber mais sobre esse esforço e os aplicativos IL5 com os quais nos integramos, baixe nosso whitepaper sobre Implantação de identidade moderna para segurança nacional ou entre em contato conosco pelo e-mail federal@okta.com.