O conceito de confiança zero – como uma forma de melhorar a segurança e o acesso à rede, aos sistemas e aos dados de uma organização – ganhou força nos últimos anos. A premissa básica é que nenhum usuário ou dispositivo deve ser confiável por padrão e todo acesso a dados e recursos deve ser concedido com base na necessidade crítica do negócio – e essa necessidade deve ser continuamente verificada.
Embora a confiança zero possa ser uma abordagem eficaz para a segurança, ela também pode apresentar alguns desafios, especialmente quando se trata de implementá-la para software como serviço ( SaaS ), devido ao ritmo acelerado de sua adoção, propriedade distribuída de aplicativos SaaS nas organizações, e o modelo de responsabilidade compartilhada entre um fornecedor de SaaS e um cliente.
A abordagem tradicional para os desafios de segurança SaaS tem sido usar um agente de segurança de acesso à nuvem (CASB) e/ou provedor de identidade (IdP) para gerenciar o acesso a aplicativos SaaS. Os IdPs são usados por muitas organizações para autenticar centralmente usuários humanos em um aplicativo ou sistema, aplicando muitos métodos de autenticação fortes.
Algumas organizações também adicionam um CASB para ficar entre os usuários e os serviços que eles acessam, aplicando políticas e controles de segurança granulares para garantir que apenas usuários autorizados possam acessar recursos específicos e para proteger contra atividades maliciosas. Essas soluções combinadas ajudam a simplificar a implementação de princípios de confiança zero para aplicativos SaaS, como Microsoft 365, Salesforce, ServiceNow e Workday, e facilitam o gerenciamento de acesso e segurança nos pontos de autenticação e autorização.
CASBs e IdPs sozinhos ou em conjunto, no entanto, ainda são inadequados, pois os aplicativos SaaS se tornaram cada vez mais complexos, incluindo elementos de colaboração e automação que podem “quebrar” o modelo de confiança zero, como:
- Integrações de terceiros como OAuth, APIs e baixo/sem código – identidades não humanas que não são regidas por soluções IdP existentes e concedem acesso programático direto para fornecedores terceirizados a aplicativos SaaS principais, sem aplicar métodos fortes de autenticação humana
- Configurações externas de compartilhamento de dados que permitem o compartilhamento de arquivos com colaboradores externos no OneDrive, SharePoint, Google Drive, Box, Dropbox, etc., o encaminhamento de e-mails para usuários externos e o compartilhamento público de repositórios de dados confidenciais (ou seja, repositórios de código-fonte)
- Identidades de usuários externos que permitem a colaboração com contratados, fornecedores e outras partes externas que permitem aos usuários acessar recursos críticos para os negócios de dispositivos não gerenciados sem impor o provedor de identidade corporativa e as proteções de segurança
Além disso, os aplicativos SaaS são muito mais complexos do que os aplicativos tradicionais e permitem aos usuários de negócios autonomia para gerenciá-los sem TI em um modelo democratizado. Esses aplicativos SaaS incentivam os usuários a realizar o que no passado seriam consideradas ações administrativas, resultando em possíveis erros de configuração.
Cada aplicativo SaaS tem seu próprio modelo de permissão e conjunto de configurações complexas, a maioria delas pode afetar a postura de segurança do aplicativo SaaS. Isso quase torna mais fácil para os usuários configurar aplicativos SaaS por engano para quebrar o modelo de confiança zero. Por exemplo, em muitas organizações, os administradores do Salesforce criam usuários locais em seu locatário para habilitar scripts de automação e contas de serviço, o que lhes permite melhorar os processos de negócios. Se essas contas não estiverem configuradas corretamente, elas podem acessar o Salesforce diretamente, sem autenticação por meio do IdP, ignorando, portanto, um controle de segurança crítico.
Por fim, as equipes de segurança não têm controle sobre a infraestrutura subjacente de seu aplicativo SaaS. Ao usar sistemas locais, uma organização tem controle total sobre o hardware, software e configuração de rede, o que facilita a implementação de controles de segurança e o cumprimento de políticas. Devido ao modelo de responsabilidade compartilhada para proteger os serviços SaaS, a infraestrutura é gerenciada pelo provedor de serviços, o que pode dificultar, senão impossibilitar, a aplicação dos princípios de confiança zero a ela. Além disso, sem visibilidade de quem são esses fornecedores de segurança, as equipes de segurança nem mesmo têm a oportunidade de examinar sua postura de segurança. Isso limita as equipes de segurança ao gerenciamento de configurações habilitadas pelo fornecedor de SaaS, o que, em muitos casos, pode não ser suficiente para aplicar as políticas desejadas.
Qual é a chave para construir um modelo escalonável de confiança zero para o SaaS moderno?
Envolvimento e colaboração com os usuários de negócios que adotam, gerenciam e usam aplicativos SaaS diariamente. Ao trabalhar em estreita colaboração com eles, as equipes de segurança podem obter visibilidade de todos os aplicativos no ambiente SaaS diversificado e complexo de sua organização e garantir que as proteções de segurança de confiança zero sejam implementadas sem interromper o ritmo de adoção e configuração de aplicativos SaaS ou o ritmo do próprio negócio.
Sem esse envolvimento, as equipes de segurança carecem de um contexto crítico sobre o uso comercial diário desses aplicativos SaaS, o que é essencial para proteger os serviços SaaS de uma forma que não interrompa os negócios. Com ele, eles podem obter insights valiosos de usuários corporativos, educar toda a organização sobre as melhores práticas de segurança SaaS e estender os recursos de segurança para toda a organização, atraindo pessoas de fora da equipe de segurança para fluxos de trabalho e processos de segurança SaaS.
FONTE: HELPNET SECURITY