Reimaginando a confiança zero para SaaS moderno

Views: 105
0 0
Read Time:4 Minute, 33 Second

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

POSTS RELACIONADOS