Este é o primeiro artigo de uma série de três partes sobre o papel da identidade no CMMC 2.0.
Resumindo: uma questão crucial que fundamenta todas as políticas de acesso: O senhor é realmente quem diz ser?
Este artigo explora em detalhes a família de controles de Identificação e Autenticação (IA). Vamos demonstrar por que a verificação robusta de identidade é um pré-requisito obrigatório para um controle de acesso mais seguro e mostrar como a Okta ajuda o senhor a atender a esses requisitos em todos os níveis de maturidade do CMMC 2.0.
Visão geral: A autenticação é a base do controle de acesso.
A família de controles de Identificação e Autenticação (IA) é o guardião digital da sua organização. Seu objetivo é garantir que cada usuário, dispositivo ou processo seja legítimo e verificado antes mesmo de tentar acessar um recurso. Suas políticas de Controle de Acesso (CA) cuidadosamente elaboradas são inúteis se o senhor questionar a certeza da identidade que está fazendo a solicitação.
É por isso que a metodologia de pontuação do CMMC 2.0 dá tanta ênfase aos controles de IA. Um auditor precisa ter certeza e comprovação da identidade antes de poder confiar nas medidas de segurança que o senhor implementou.
Com o Okta, as organizações podem atender imediatamente a uma parcela significativa desses requisitos de alto valor. Somente dentro da família IA, a Okta ajuda o usuário a atender três controles que valem 5 pontos— os principais pilares essenciais para passar na auditoria.
Vamos explorar um controle de IA fundamental em cada nível do CMMC.
CMMC Nível 1: a camada fundamental
O nível 1 foca na "higiene cibernética básica" e é obrigatório para prestadores de serviços que lidam com Informações de Contratos Federais (FCI). Isso garante que o senhor(a) tenha o essencial em mãos.
Controle de nível 1: IA.L1-3.5.1
Requisito de CMMC | NIST SP 800-53 Controle Correlacionado |
|---|---|
IA.L1-3.5.1: Identificar e autenticar usuários, processos ou dispositivos de sistemas de informação. | IA-2: Identificação e autenticação (usuários organizacionais): o sistema de informação identifica e autentica de forma única os usuários organizacionais (ou processos que atuam em nome dos usuários organizacionais). |
Esse controle exige que o senhor ou a senhora atribua uma identidade única a cada usuário e elimine contas compartilhadas.
Como a Okta atende ao controle:
O Okta Universal Directory e o Single Sign-On (SSO) são as ferramentas perfeitas para atender a esse requisito do CMMC. Okta atua como a fonte central de verdade para todas as identidades de usuários, garantindo que cada pessoa tenha uma, e apenas uma, conta. Ao federar seus aplicativos com o Okta SSO, você ajuda a garantir que essa identidade única seja usada para cada login, tornando as contas compartilhadas coisa do passado.
- Cenário do mundo real: Um pequeno fornecedor da DIB acessa o portal de um prestador de serviços principal para obter informações da FCI, como cronogramas de entrega. Em vez de usar uma conta compartilhada shipping@supplier.com, a empresa usa o Okta para fornecer a cada funcionário uma conta do usuário exclusiva. Quando um funcionário acessa o portal, ele se autentica com a Okta usando suas credenciais pessoais, garantindo que cada ação esteja diretamente vinculada a ele e atendendo aos requisitos básicos de rastreabilidade do Nível 1.
IA.L1-3.5.1 Recomendações de design:
Para implementar esse controle, configure o Okta como seu provedor de identidade central, conectando-o a uma fonte da verdade, como seu sistema de RH, ou criando perfil do usuário diretamente no Okta Universal Directory. Para cada um de seus aplicativos, configure uma integração com SSO usando SAML ou OIDC. Fundamentalmente, certifique-se de que o aplicativo esteja configurado para permitir logins somente via Okta, desativando a possibilidade de os usuários criarem contas locais separadas com nome de usuário e senha. Isso impõe o uso de uma única identidade gerenciada para todos os acessos.
IA.L1-3.5.1 Evidências de Conformidade:
Para demonstrar a conformidade a um avaliador, o senhor deve mostrar a ele seu Okta Universal Directory para comprovar que cada funcionário possui um perfil do usuário exclusivo. Em seguida, o usuário navegaria até a página de configuração de um aplicativo importante (por exemplo, Microsoft 365) e exibiria as configurações de SSO, observando que ele está federado com a Okta. Por fim, o usuário acessaria o Registro do Sistema Okta, filtraria pelo login recente de um usuário específico e exibiria o registro de evento detalhado, comprovando que cada ação é rastreável a um actor.id exclusivo.
CMMC Nível 2: O Guardião da CUI
O nível 2 é para prestadores de serviços que lidam com informações não classificadas controladas (CUI), mais sensíveis. Este nível está alinhado com a NIST SP 800-171 e requer uma segurança muito mais robusta.
Controle de nível 2: IA.L2-3.5.3
Requisito de CMMC | NIST SP 800-53 Controle Correlacionado |
|---|---|
IA.L2-3.5.3: Utilize autenticação multifator para acesso local e em rede. | IA-2(1): Acesso à rede para contas privilegiadas e não privilegiadas: O sistema de informação implementa autenticação multifator para acesso à rede para contas privilegiadas e não privilegiadas. |
Este controle de segurança de 5 pontos, também conhecido como "big rock", exige que apenas uma senha não seja suficiente. Deve-se aplicar um segundo fator de verificação (MFA) para proteger contra o roubo de senhas.
Como a Okta atende ao controle:
O Okta Adaptive MFA é a ferramenta perfeita para atender a esse requisito do CMMC. Como provedor de identidade centralizado, o Okta pode impor uma autenticação multifator (MFA) robusta para cada tentativa de acesso a qualquer aplicativo que lide com informações confidenciais controladas (CUI). É possível configurar políticas para exigir autenticação multifator (MFA) para todos os usuários e adaptá-las com base no risco, como exigir um fator de autenticação mais forte quando um usuário se conecta a partir de uma rede não confiável.
- Cenário do mundo real: Um engenheiro aeroespacial trabalhando em casa precisa acessar um aplicativo CAD baseado em nuvem que contém informações não classificadas pelo usuário (CUI). Para fazer login, o usuário primeiro insere a senha. Em seguida, a Okta solicita que o usuário aprove uma notificação push em seu smartphone cadastrado. Somente após a aprovação desse segundo fator é que eles têm acesso aos arquivos confidenciais de design. Um atacante que obtivesse a senha por phishing seria imediatamente impedido pelo desafio de autenticação multifator (MFA).
IA.L2-3.5.3 Recomendações de design:
No console de administração do Okta, crie uma política de "Inscrição de autenticador" que exija que todos os usuários se inscrevam em pelo menos um fator de autenticação multifator (MFA). Em seguida, solicite a criação de uma "Política de Acesso" e aplique-a a todos os aplicativos que tratam de CUI (Informações Controladas Não Classificadas). Configure as regras dentro desta política para "exigir autenticação multifatorial" para cada login. Uma boa prática é definir a regra de que, se um usuário estiver em uma rede não confiável, ele sempre será solicitado a autenticar-se com autenticação multifatorial (MFA). Para uma postura ainda mais robusta, exija um fator resistente a phishing para todos os acessos a esses aplicativos críticos.
IA.L2-3.5.3 Evidências de Conformidade:
Para um avaliador, primeiramente exibe-se a política de acesso criada, mostrando a regra que impõe explicitamente a autenticação multifator (MFA) em todos os logins em um aplicativo que contém informações confidenciais do usuário (CUI). Em seguida, realizaria uma demonstração ao vivo: tentaria fazer login nesse aplicativo como um usuário de teste e mostraria ao avaliador a solicitação de autenticação multifator (MFA) exibida em um dispositivo registrado. Por fim, exiba o evento de sucesso correspondente à "Autenticação multifator" para esse usuário no Registro do Sistema Okta.
CMMC Nível 3: A Defesa Especializada
O Nível 3 destina-se a organizações que participam dos programas de maior prioridade do Departamento de Guerra. É necessário incluir todos os controles de camada 2, além dos controles aprimorados da publicação NIST SP 800-172, para proteção contra Ameaças Persistentes Avançadas (APTs).
Controle de nível chave 3: IA.L3-3.5.4e
Requisito de CMMC | NIST SP 800-53 Controle Correlacionado |
|---|---|
IA.L3-3.5.4e: Utilize autenticação multifatorial resistente a phishing para todos os acessos, sejam eles privilegiados ou não. | IA-2(8): resistente a phishing / resistente a reprodução: O sistema de informações utiliza mecanismos de autenticação que são resistentes a phishing e resistentes a reprodução. |
Este controle avançado exige o uso de MFA resistente a phishing para impedir ataques sofisticados que podem contornar tipos de MFA mais fracos.
Como a Okta atende ao controle:
Okta possui alguns dos autenticadores mais resistentes a phishing do setor, que são as ferramentas que atendem a esse requisito de nível especialista do CMMC. Isso inclui chaves de segurança de hardware compatíveis com FIDO2/WebAuthn, como YubiKeys, e soluções sem senha, como Okta FastPass, que utiliza a biometria da plataforma, como o Windows Hello ou o Face ID/Touch ID da Apple. As políticas da Okta podem ser configuradas para exigir exclusivamente esses fatores resistentes a phishing para qualquer usuário que acesse o ambiente CUI de alto valor.
- Cenário do mundo real: Um analista de cibersegurança de uma empresa de defesa de primeira linha gerencia sistemas que contêm informações confidenciais não classificadas (CUI) altamente sensíveis. Para acessar o console administrativo, eles precisam se autenticar pelo Okta. Após inserir a senha, eles são solicitados a tocar no YubiKey inserido em suas estações de trabalho. A chave realiza um processo criptográfico de desafio-resposta exclusivo para cada usuário e para o serviço Okta, comprovando sua identidade com o mais alto nível de segurança e tornando impossível para um adversário sofisticado interceptar suas credenciais.
IA.L3-3.5.4e Recomendações de design:
Na sua política de "Inscrição de Autenticadores" do Okta, certifique-se de que os autenticadores FIDO2/WebAuthn estejam habilitados. Em seguida, crie ou edite sua Política de Acesso para aplicativos CUI. Em vez de exigir MFA de forma geral, crie uma regra que exija explicitamente um autenticador com "resistência a phishing" como propriedade obrigatória. Essa regra obrigará o uso de fatores como YubiKey ou Okta FastPass, aproveitando a biometria integrada do dispositivo, e não permitirá fatores mais fracos, como SMS ou perguntas de segurança, para acessar esses aplicativos de alta sensibilidade.
IA.L3-3.5.4e Evidência de conformidade:
Para demonstrar isso a um avaliador, deverá mostrar a regra da Política de Acesso que configurou e que exige especificamente autenticadores resistentes a phishing. Em seguida, realize uma demonstração de login ao vivo. Primeiramente, deve-se tentar fazer login usando um fator que não seja resistente a phishing (como uma notificação push) e demonstrar que o acesso foi negado. Em seguida, deve-se repetir o login usando um YubiKey ou Okta FastPass com o Windows Hello e verificar se o acesso foi concedido com sucesso. Isso fornece uma prova inegável de aplicação.
Continue sua jornada CMMC com uma base sólida.
Ao combinar um forte controle de acesso com identificação e autenticação robustas, você constrói uma defesa formidável para suas informações controladas não classificadas (CUI) e uma base sólida para sua auditoria CMMC. Centralizar sua estratégia em uma plataforma de identidade moderna garante que as pessoas certas — e somente as pessoas certas — tenham acesso aos recursos certos.
Fique atento à nossa próxima publicação desta série, onde exploraremos o domínio de auditoria e responsabilização (AU) para mostrar como o senhor pode comprovar que seus controles de segurança estão funcionando conforme o esperado.
Para saber mais sobre como a Okta pode ajudar sua organização a atender aos requisitos do CMMC, baixe nosso Guia de Descoberta do CMMC em https://www.okta.com/resources/datasheet-okta-cmmc-discovery-guide/ ou entre em contato conosco em okta.com/contact-sales/.
Embora este artigo discuta certos conceitos jurídicos, ele não constitui aconselhamento jurídico e não deve ser interpretado como tal. É fornecido apenas para fins informativos. Para obter aconselhamento jurídico sobre as necessidades de conformidade da organização, recomenda-se consultar o departamento jurídico da mesma. A Okta não oferece nenhuma representação, garantia ou outra garantia em relação ao conteúdo deste artigo. Informações sobre as garantias contratuais da Okta aos seus clientes podem ser encontradas em okta.com/agreements.
