Estratégia de Confiança Zero do DoD na Prática

Google Imagens

HashiCorp responde à Estratégia de Confiança Zero: Comece!

Notas do Blog

Público-alvo: profissionais, profissionais de segurança, equipes de operações e consultores técnicos

Os ataques cibernéticos aumentaram 28% globalmente no terceiro trimestre em comparação com o ano passado. Esses ataques se espalharam por muitos setores, como educação, saúde, energia e até mesmo o Departamento de Defesa. O governo dos Estados Unidos está tornando a defesa cibernética uma prioridade máxima e há grandes iniciativas para proteger e defender nossos dados críticos.

Há cerca de um ano e meio, o governo Biden produziu uma Ordem Executiva para incentivar organizações governamentais, fornecedores de tecnologia e desenvolvedores a repensar como protegem aplicativos e infraestrutura técnica. O Departamento de Defesa anunciou sua própria direção de segurança cibernética modernizada em 22 de novembro de 2022: Estratégia e Roteiro de Confiança Zero do DoD. Se você ainda não leu, Chris Huges faz um ótimo trabalho ao resumi-lo em seu Resilient Cyber Blog.

A estratégia do DoD fornece orientação de alto nível sobre como alcançar capacidades de confiança zero ao longo de vários anos. Nosso objetivo na HashiCorp é acelerar a adoção de confiança zero para o DoD, fazendo parcerias para impulsionar processos de automação de infraestrutura que se expandem em toda a organização.

Segurança orientada por identidade: o primeiro passo para a confiança zero

O NIST define identidade como “o conjunto de características físicas e comportamentais pelas quais um indivíduo é exclusivamente reconhecível”. Hoje vivemos em um mundo híbrido/multiplataforma. Os benefícios e vantagens desse ambiente dinâmico são enormes, mas a complexidade e os desafios de segurança podem ser impressionantes. O princípio da identidade é fundamental para a adoção bem-sucedida da confiança zero.

Segurança orientada por identidade significa que as entidades globais (um dispositivo/máquina, máquina virtual, contêiner, aplicativo, usuário, etc.), independentemente da plataforma (agnóstica), são estabelecidas e reconhecidas exclusivamente, além das dependências operacionais tradicionais (como localização da máquina, segmentos de rede, etc.).

A identidade é o princípio crítico da confiança zero e a chave para habilitar a autenticação e a autorização de entidades não pessoais (NPE), acesso à máquina ou acesso máquina a máquina. Ao acessar um sistema de máquina, devemos vincular a identidade às credenciais ou segredos globalmente. Definimos um segredo/credencial como qualquer coisa que nos dê acesso a um sistema ou nos permita autenticar ou autorizar. A Estratégia DoD Zero Trust faz um ótimo trabalho ao destacar esses pontos.

A HashiCorp pode ajudar o DoD com algumas das “Metas e Objetivos Defendidos pelos Sistemas de Informação do DoD”. As Metas e Objetivos Específicos mapeados são:

  • Usuário — Proteger, limitar e impor autenticação forte de acesso de pessoa e entidade não pessoal
  • Dispositivo — Identifique, inventarie, autorize, autentique e corrija todos os dispositivos continuamente e em tempo real
  • Aplicativos e cargas de trabalho — proteja todos os aplicativos e cargas de trabalho, para incluir a proteção de contêineres e máquinas virtuais
  • Dados — habilite e proteja a transparência e a visibilidade dos dados com infraestrutura corporativa, aplicativos, padrões, criptografia de ponta a ponta e marcação de dados
  • Ambiente de & de rede — Segmente (lógica e fisicamente), isole e controle a rede/ambiente (local e externo) com restrições granulares de acesso e política
  • Automação e orquestração — automatize a segurança manual e outros processos aplicáveis para executar ações baseadas em políticas em toda a empresa com velocidade e em escala
  • Visibilidade e análise — analise eventos, atividades e comportamentos para derivar contexto e aplique IA/ML para obter modelos que melhorem a detecção e o tempo de reação na tomada de decisões de acesso em tempo real

Segurança independente de plataforma: à prova de futuro

Após décadas de abordagens tradicionais de TI empresarial para redes e métodos de acesso, o desafio está mudando de apenas a nuvem híbrida/múltipla para práticas recomendadas emergentes, como manter o acesso à rede de confiança zero (ZTNA). Com base na ordem executiva, esses esforços de confiança zero podem ser muito complexos e devem ser arquitetados e planejados usando as melhores práticas emergentes, que continuam a se desenvolver. Isso torna fundamental estabelecer uma abordagem independente de plataforma.

Por exemplo, uma malha de serviço que é compatível apenas com um tempo de execução, fornecedor ou plataforma específica é uma aposta arriscada, oferecendo um menor grau de preparação para o futuro. A realidade (especialmente no governo federal) é que a maioria dos sistemas não está em um único tempo de execução/plataforma. Essa lacuna de requisitos foi identificada e é crítica para resolver a segurança de confiança zero (ZTS) para ambientes de várias nuvens.

Autenticação mútua para aplicativos e cargas de trabalho

A Estratégia de Confiança Zero do DoD visa “proteger todos os aplicativos e cargas de trabalho, para incluir a proteção de contêineres e máquinas virtuais”. O NIST define autenticação mútua como “o processo de ambas as entidades envolvidas em uma transação verificando uma à outra”. Essa autenticação bidirecional é comum e essencial em redes de serviço seguras e realizada por meio de segurança de camada de transporte mútuo ou mTLS. Por exemplo, o SP 800–204C afirma: “o software de malha de serviço consiste em dois componentes principais: o plano de controle e o plano de dados”. O plano de dados é onde o mTLS ou autenticação mútua ocorre usando proxies, também conhecidos como sidecars.

Atualmente, não há menção a uma malha de serviço para suporte multiplataforma no documento. O HashiCorp Vault e o Consul Enterprise são soluções práticas e eficazes que abordam e permitem que identidades de serviço se conectem com base em autenticação e autorização que foram projetadas de acordo com o NIST SP 800–27, conforme ilustrado abaixo, do serviço A ao serviço B no plano de dados e no plano de controle. O uso de listas e intenções de controle de acesso se integram aos seguintes fluxos de trabalho sem a necessidade de alterar sua arquitetura existente:

  • Sistemas MDL
  • Conformidade do setor
  • Inteligência de ameaças
  • Registros de atividades
  • Política de Acesso a Dados
  • PKI (o Vault pode automatizar e orquestrar)
  • Gerenciamento de ID
  • Sistema SIEM (NIST 800–27)

Foto tirada por NIST SP 800–207 Figura 2 & HashiCorp

Agente de Identidade Global

O NIST define autorização como “o direito ou uma permissão concedida a uma entidade do sistema para acessar um recurso do sistema”. Essa definição é ótima, mas problemática, pois o acesso aos recursos do sistema raramente é singular. Por exemplo, a seguir estão algumas maneiras comuns de obter autorização por meio do controle de acesso em um mundo de várias nuvens:

Nem sequer discutimos a complexidade acrescida do híbrido/multiplataforma. Com uma lista desse tamanho, a necessidade de uma força de trabalho especialmente qualificada aumenta em todas essas plataformas díspares, assim como a complexidade operacional. Como o controle de acesso está vinculado à autorização e autenticação, é fundamental enfatizar a importância da adoção de um agente de identidade global para permitir a adoção de confiança zero e reduzir significativamente a carga sobre as operações e a força de trabalho.

Credenciais de curta duração

A Publicação Especial NIST 800–63B aprofunda as diretrizes de identidade digital, autenticação e gerenciamento do ciclo de vida. O NIST deixa bem claro que uma identidade global é necessária para que máquinas e humanos realizem o gerenciamento do ciclo de vida da identidade digital adequadamente. Um dos principais fatores a serem abordados para o ZTS em um ambiente híbrido/multinuvem/multiplataforma é o fator tempo de vida (TTL) para segredos/credenciais em toda a extensão dos limites de autorização.

Sem controle centralizado, isso é impossível. Por exemplo, a conexão mTLS do serviço A para o serviço B no exemplo acima, dentro da malha de serviço, deve ser automatizada e limitada por tempo para permitir a rotação automática de chaves. A malha de serviço seguindo nossos princípios globais deve ser agnóstica. Dessa forma, o ciclo de vida das identidades digitais é automatizado e possível para os humanos auditarem e registrarem.

Rotação da chave de criptografia

Um dos pontos essenciais a considerar ao usar a criptografia é a rotação de chaves. Esse processo necessário pode ser desafiador com vários limites de autorização em um cenário híbrido de várias nuvens. Baseado explicitamente na publicação 800–38D do NIST. Por exemplo,

“Recomenda-se a rotação periódica das chaves de criptografia, mesmo na ausência de comprometimento. Para chaves AES-GCM, a rotação deve ocorrer antes que aproximadamente 232 criptografias tenham sido executadas por uma versão de chave, seguindo as diretrizes da publicação 800–38D do NIST. Recomenda-se que os operadores estimem a taxa de criptografia e a usem para determinar uma frequência de rotação que impeça que os limites de orientação sejam atingidos. Por exemplo, se determinarmos que a taxa estimada é de 40 milhões de operações por dia, então girar uma chave a cada três meses é suficiente.”

Há uma lacuna em muitos sistemas em fornecer uma abordagem padrão (ou criptografia como serviço) para criptografia em trânsito. Caso contrário, quem cumpre esses cálculos matemáticos e tarefas criptográficas em sua organização? Tokenização do cofre? Mecanismo de PKI do Vault? Vamos torcer para que não transborde pilha!

Visibilidade e análise

Um desafio significativo que enfrentamos em arquiteturas de confiança zero é o registro em log, a auditoria e o monitoramento em muitos ambientes. A complexidade adicional de vários limites de autorização, identidades, tempos de execução e plataformas diferentes só agrava o problema. É vital aproveitar uma plataforma centralizada de registro e análise que possa ingerir dados em qualquer formato, qualquer volume, qualquer fonte, em escala. Uma estratégia de registro em log centralizada correlaciona dados de muitas fontes diferentes e fornece um único painel de exibição de vidro em vários ambientes. Exemplos dessas plataformas são o Datadog, que está incluído no programa Continuous Diagnostics and Mitigation (CDM). O Datadog pode indexar dados em qualquer formato legível por humanos (sem binário), independentemente da fonte ou do volume. Além disso, os eventos podem ser correlacionados por meio de sua linguagem de pesquisa e nos permitem imprimir a atividade em arquiteturas de confiança zero.

Por exemplo, um profissional de DevOps precisa implantar um aplicativo de várias nuvens na AWS, Google, Oracle e Azure. Eles precisarão solicitar credenciais para cada provedor de serviços de nuvem do HashiCorp Vault, mas antes que isso possa acontecer, o Vault verificará sua identidade. Uma vez verificado, o Vault — como agente de identidade — pode gerar credenciais just-in-time (dinâmicas), limitadas ao tempo, para cada CSP com princípios de menor privilégio para permitir que o profissional execute o trabalho dentro do escopo e nada mais. Depois que as credenciais expirarem, elas não poderão mais ser usadas. Neste exemplo, os logs de eventos do provedor de identidade, os logs de auditoria do Vault, os eventos do AWS CloudWatch/CloudTrail e os logs do Azure Monitor podem contar histórias diferentes individualmente. Mas, ao agregar esses logs díspares em uma plataforma centralizada, comandos de pesquisa simples, aprendizado de máquina e correspondência de padrões nos ajudam a vincular a identidade do praticante com as credenciais CSP geradas no Vault e pintar uma imagem completa das atividades em todos os ambientes.

Inscreva-se e siga no Medium para saber mais. Saiba mais sobre os produtos e a educação da HashiCorp na HashiCorp Developer. Todos nós precisamos fazer nossa parte para ajudar a impulsionar a segurança de confiança zero para a comunidade do Departamento de Defesa e Segurança Nacional.


Artigo Original