Repense sua estratégia de acesso, pense além da Corp

Anos atrás , Forrester declarou morto o antigo mantra de segurança, “confie, mas verifique”, e cunhou o termo confiança zero. O argumento era que confiamos em tudo com base em uma autenticação inicial bem-sucedida, mas nunca realmente verificamos depois. Como de costume, palavras da moda como essa passam por um ciclo de entusiasmo, começando com muita excitação e muitas vezes não resultando em muita ação no curto prazo. A confiança zero e seus desdobramentos (o aplicativo é o novo perímetro, etc.) agora estão ganhando força em arquiteturas e implementações do mundo real. Um grande defensor dessa estratégia de segurança, o Google, fez grandes avanços na implementação dela e até foi gentil ao publicar seu processo para fazê-lo. Eles o apelidaram de BeyondCorp.

O Google publicou recentemente uma postagem de blog para divulgar seu 4º artigo de pesquisa sobre o assunto, que descreveu como eles mantiveram a produtividade durante o longo processo de migração. Para resumir a arquitetura BeyondCorp, não há mais diferenciação entre acesso local e acesso remoto... é apenas acesso. Todas as solicitações de autenticação e acesso seguem o mesmo caminho por meio de um gateway de acesso centralizado, independentemente da localização ou do dispositivo do usuário. No entanto, os desafios de autenticação e as decisões de acesso podem diferir com base em uma série de fatores de risco. O gateway fornece prompts de autenticação, mas também permite um controle de acesso detalhado e baseado em atributos, com base em um perfil de risco. Isso proporciona consistência e simplicidade para os usuários, o que é extremamente valioso para diminuir a probabilidade de ataques bem-sucedidos (como descrevi em artigos anteriores).

Para ilustrar, se um usuário estiver tentando se conectar ao aplicativo da web de sua empresa, que só tem anúncios da empresa que também podem ser públicos (baixo risco), e tentando se conectar de sua mesa de escritório ou de seu laptop fornecido pela empresa (baixo risco), então talvez, como administrador de segurança, eu opte por exigir apenas nome de usuário e senha para acesso. Mas suponha que o usuário esteja tentando se conectar a um aplicativo relacionado a finanças (alto risco), de algum lugar na Rússia (alto risco) e de um dispositivo desconhecido (alto risco). Eu, como administrador de segurança, posso ter uma política no meu gateway de acesso que considere isso muito arriscado e negue o acesso ou, no mínimo, solicite ao usuário um segundo ou até terceiro fator para verificar a identidade. Além disso, com um controle de acesso refinado e baseado em atributos, posso decidir dar às solicitações de acesso que correspondem a esse nível de risco uma forma reduzida de acesso... talvez somente leitura em vez de leitura/gravação.

Alguma coisa disso lhe parece familiar? Se você usa um serviço IDaaS, como os dos parceiros da F5, Microsoft Azure AD, Ping ou Okta , você já está fazendo isso até certo ponto. Existem outros componentes que compõem o modelo BeyondCorp, porém o gateway de acesso é certamente o ponto crucial de toda a arquitetura. O Google agora está oferecendo seu “proxy com reconhecimento de identidade” (IAP) para outras empresas usarem, mas não sem limitações. Além de poder usar isso apenas com aplicativos na Google Compute Platform (GCP), alguns clientes notaram desafios com granularidade e flexibilidade no controle de acesso, desejando duração de sessão configurável, por políticas de aplicativo em vez de por GCP, e capacidade de fazer autenticação de segundo fator flexível e gradual.

Não por coincidência, a F5 oferece uma solução de acesso que oferece esses recursos e muito mais. E funciona para TODOS os seus ambientes, e não apenas para aplicativos que residem no GCP. Seja completamente na nuvem ou de forma híbrida, a F5 oferece uma solução de acesso segura, centralizada e escalável para se adaptar a qualquer arquitetura. Para saber mais, visite f5.com/apm .