theNet by CLOUDFLARE

Roteiro da Zero Trust

Cinco projetos simples para promover a adoção do Zero Trust

A adoção do Zero Trust é complexa, mas começar não precisa ser

A adoção da segurança Zero Trust é amplamente reconhecida como uma jornada difícil. De muitas maneiras, essa reputação é bem merecida. O Zero Trust exige um trabalho sobre o qual a segurança e a TI são justificadamente cautelosas: repensar as políticas de permissão padrão e a arquitetura de rede baseada em perímetro, colaboração entre equipes funcionalmente diferentes e confiar em novos serviços de segurança. As organizações podem adiar essa transformação por vários motivos, incluindo:

  • Restrições de capacidade com projetos concorrentes

  • Variação nas ofertas do fornecedor de Zero Trust

  • Incerteza sobre onde estão vários aplicativos e recursos na rede

  • Interrupção na produtividade dos funcionários

A estrutura Zero Trust é bastante complexa em geral. O roteiro completo para a arquitetura Zero Trust consiste em 28 projetos abrangentes. No entanto, alguns projetos exigem comparativamente pouco esforço, mesmo para equipes pequenas com tempo limitado.



Adoção gradual do Zero Trust

Em um contexto de rede, a segurança Zero Trust exige que todas as solicitações que se movem para dentro, fora ou na rede corporativa sejam inspecionadas, autenticadas, criptografadas e registradas. Ela se baseia na ideia de que nenhuma solicitação deve ser implicitamente confiável, não importa de onde venha ou para onde esteja indo.

Fazer progressos iniciais em direção ao Zero Trust significa estabelecer esses recursos onde eles não estão presentes no momento. Para organizações começando do zero, isso geralmente significa estender esses recursos além de um único "perímetro de rede".

Aqui estão cinco dos projetos de adoção do Zero Trust mais simples, com foco na proteção de usuários, aplicativos, redes e tráfego da internet. Eles não vão alcançar o Zero Trust abrangente sozinhos, mas oferecem benefícios imediatos e criam um impulso inicial para uma transformação mais ampla.


PROJETO 1

Implementar a autenticação multifator para os aplicativos críticos

Em uma abordagem Zero Trust, a rede deve estar extremamente confiante de que as solicitações vêm de entidades confiáveis. As organizações precisam estabelecer proteções contra o roubo de credenciais do usuário por meio de phishing ou vazamento de dados. A autenticação multifator (MFA) é a melhor proteção contra esse roubo de credenciais. Embora uma implantação completa da MFA possa levar um tempo significativo, focar nos aplicativos mais críticos é uma vitória mais simples, mas impactante.

As organizações que já possuem um provedor de identidade podem configurar a MFA diretamente nesse provedor, por exemplo, por meio de códigos únicos ou aplicativos de notificação por push enviados aos dispositivos móveis dos funcionários. Para aplicativos não diretamente integrados ao seu provedor de identidade (IdP), considere usar um proxy reverso de aplicativo na frente do aplicativo para impor a MFA.

As organizações sem provedor de identidade podem adotar uma abordagem diferente para a MFA. O uso de plataformas sociais como Google, LinkedIn e Facebook, ou senhas de uso único (OTP), pode ajudar a verificar as identidades dos usuários. Essas são formas comuns de acesso DIY para prestadores de serviços terceirizados sem adicioná-los a um provedor de identidade corporativa, e essas estratégias também podem ser aplicadas dentro da própria empresa.


PROJETO 2

Implementação de políticas Zero Trust para aplicativos críticos

A aplicação de Zero Trust significa mais do que simplesmente verificar as identidades dos usuários. Os aplicativos também devem ser protegidos com políticas que sempre verificam as solicitações, consideram uma variedade de comportamentos e fatores contextuais antes da autenticação e monitoram continuamente a atividade. Assim como no Projeto 1, a implementação dessas políticas torna-se mais simples quando aplicada a uma lista inicial de aplicativos críticos.

Esse processo varia de acordo com o tipo de aplicativo em questão:

  • Aplicativos privados auto-hospedados (endereçáveis apenas na rede corporativa)

  • Aplicativos públicos auto-hospedados (endereçáveis pela internet)

  • Aplicativos SaaS


PROJETO 3

Monitorar os aplicativos de e-mail e filtrar as tentativas de phishing

O e-mail é a principal forma de comunicação da maioria das organizações, o aplicativo SaaS mais usado e o ponto de entrada mais comum para invasores. As organizações devem aplicar os princípios Zero Trust ao e-mail para complementar seus filtros e inspeções de ameaças padrão.

Além disso, a segurança deve considerar o uso de um navegador isolado para colocar em quarentena links que não são suspeitos o suficiente para serem bloqueados completamente.


PROJETO 4

Fechar todas as portas de entrada abertas para a internet para entrega de aplicativos

As portas de rede de entrada abertas são um vetor de ataque comum e devem receber proteção Zero Trust, aceitando apenas tráfego de fontes conhecidas, confiáveis e verificadas.

Essas portas podem ser encontradas usando tecnologia de varredura. Então, um proxy reverso Zero Trust pode expor com segurança um aplicativo web à internet pública sem abrir nenhuma porta de entrada. O único registro publicamente visível do aplicativo é seu registro de DNS, que pode ser protegido com autenticação Zero Trust e recursos de log.

Como uma camada adicional de segurança, o DNS interno/privado pode ser melhor aproveitado com o uso de uma solução de acesso à rede Zero Trust.


PROJETO 5

Bloquear solicitações de DNS para ameaças conhecidas ou destinos arriscados

A filtragem de DNS é a prática de impedir que os usuários acessem sites e outros recursos da internet que são conhecidos ou altamente suspeitos de serem maliciosos. Ela nem sempre é incluída na conversa sobre Zero Trust porque não envolve inspeção de tráfego ou log. Mas, em última análise, pode controlar onde os usuários (ou grupos de usuários) podem transferir e fazer upload de dados, o que se alinha bem com a filosofia Zero Trust mais ampla.

A filtragem de DNS pode ser aplicada por meio da configuração do roteador ou diretamente no computador do usuário.


Compreender a imagem mais ampla do Zero Trust

A implementação desses cinco projetos pode ser uma incursão relativamente direta ao Zero Trust. E qualquer organização que conclua estes projetos terá feito progressos significativos em direção a uma segurança melhor e mais moderna.

A adoção mais ampla do Zero Trust continua complicada. Para ajudar, construímos um roteiro independente de fornecedor para toda a jornada do Zero Trust, abrangendo esses cinco projetos e outros como eles. Alguns vão levar muito mais do que alguns dias, mas o roteiro pode fornecer maior clareza sobre o que significa a adoção do Zero Trust.

Todos esses serviços estão integrados à nuvem de conectividade da Cloudflare: uma plataforma unificada de serviços nativos de nuvem projetada para ajudar as organizações a recuperar o controle de seu ambiente de TI. A Cloudflare é a empresa líder em nuvem de conectividade. Ela permite que as organizações tornem seus funcionários, aplicativos e redes mais rápidos e seguros em qualquer lugar, ao mesmo tempo que reduz a complexidade e os custos. Alimentada por uma das maiores e mais interconectadas redes do mundo, a Cloudflare bloqueia bilhões de ameaças on-line para seus clientes todos os dias.

Este artigo é parte de uma série sobre as tendências e os assuntos mais recentes que influenciam os tomadores de decisões de tecnologia hoje em dia.




Principais conclusões

Após ler este artigo, você entenderá:

  • Os 28 projetos no roteiro Zero Trust

  • Cinco projetos de adoção do Zero Trust que requerem comparativamente pouco esforço

  • Os tipos de serviços que permitem a implementação

  • Como iniciar um roteiro de adoção em sua organização


Recursos relacionados


Saiba mais sobre esse assunto

Saiba mais sobre o Zero Trust e comece a planejar um roteiro para sua organização com o guia completo, A roadmap to Zero Trust architecture.

Receba um resumo mensal das informações mais populares da internet.