A pandemia acelerou a migração para clouds públicas devido ao trabalho remoto e à digitalização rápida. Empresas adotaram soluções flexíveis e escaláveis, com 90% aumentando o uso da nuvem, mas também enfrentam novos desafios de segurança, como controle de acesso e proteção de dados. Afinal a porta de pelo menos um dos seus datacenters agora é o QRCODE abaixo. Não acredita? Escaneie-o.
O modelo multicloud oferece flexibilidade e resiliência, melhorando a disponibilidade e performance dos serviços, mas também aumenta os desafios de autenticação e gestão de acessos entre diferentes plataformas, o que eleva os riscos e a complexidade.
Como proteger a autenticação em ambientes multicloud (ou seja a porta dos seus múltiplos datacenters)
A autenticação é o processo de verificar a identidade de um usuário antes de permitir acesso a sistemas ou dados. Ela valida credenciais, como senhas ou biometria, para garantir que o acesso seja autorizado. Esse processo é essencial para proteger informações contra acessos não autorizados.
Levando em conta as 3 principais clouds públicas de mercado existem normalmente 2 formas de se autenticar:
Identidade criada no provedor de identidades interno
Identidade federada através de Single Sign On
Cada um dos provedores utiliza seu próprio serviço de autenticação para controlar as identidades e permissões:
Provedores de Identidades Internos
AWS: O AWS IAM gerencia usuários e permissões utilizando papéis e políticas personalizáveis para controle de acesso.
Azure: O Azure Active Directory (Azure AD) integra a autenticação e a gestão de identidades e dispositivos.
Google Cloud: O Google IAM permite o controle de quem pode acessar os recursos do GCP, com gerenciamento de identidades similar.
Contas root x contas operacionais
Seguindo as melhores práticas de segurança da informação, com recomendado em frameworks como o NIST, a utilização das contas root que nascem no diretório interno (global admin, administrator, a nomenclatura dependende do provedor de cloud) deve ser extremamente limitada devido aos altos privilégios que possuem. Os conceitos recomendados são:
Mínimo uso necessário: A conta root deve ser utilizada apenas para tarefas críticas como configuração inicial, federação ou tarefas extremamente críticas e em seguida desativada ou protegida por uma solução de proteção de acessos privilegiados (PAM).
Proteção Robusta: Deve se aplicar medidas rigorosas como autenticação MFA ou também rotação de senhas automatizada e armazenada em local seguro, protegendo contra comprometimentos ou vazamentos.
Monitoramento contínuo: Atividades envolvendo contas root devem ser monitoradas e auditadas do início ao fim, para identificar uso indevido e possibilitar o não-repúdio de atividades.
Apesar do uso de soluções de proteção de acessos privilegiados (PAM) ter se mostrado eficaz para gestão segura e utilização de contas locais root, o mesmo não foi observado para contas operacionais, alguns desafios observados foram:
Foco na autenticação, não no acesso: Soluções PAM legadas priorizam a autenticação com senhas e rotação de credenciais, mas não atendem totalmente às necessidades diárias dos usuários. Resultado: Alto risco residual e fricção elevada.
Privilégios desconhecidos e dinâmicos: PAMs protegem apenas os privilégios conhecidos, sem monitoramento abrangente, deixando espaços invisíveis prontos para serem explorados. Resultado: Superfície de ataque desconhecida.
Acesso permanente desnecessário: Contas administrativas com acesso contínuo tornam a rede vulnerável com uma única credencial comprometida. Resultado: Maior superfície de ataque e alto risco residual.
Implantações incompletas: Alguns modelos de PAM são baseados em agentes não escalam adequadamente, dificultando a implantação completa em ambientes elásticos. Resultado: Implantações falhas em workloads provisórias.
Experiência do usuário degradada: A utilização de um sistema de PAM para um acesso operacional, normalmente degrada a experiência do usuário por conta da separação de contas e emulação de sessão através de jump server transparente, o que dificulta a adoção do acesso.
Single Sign-On (SSO)
O Single Sign-On (SSO) melhorou a experiência dos acessos operacionais em cenários multi-cloud, permitindo acesso unificado a diversas plataformas sem a necessidade de múltiplos logins, reduzindo a complexidade de gerenciamento de credenciais. Com o SSO, os usuários podem autenticar-se uma única vez e acessar recursos distribuídos em AWS, Azure e GCP, simplificando o fluxo de trabalho.
Este fluxo é realizado através de federação, quando é delegada a autenticação da uma cloud para outro provedor de identidades via protocolos como SAML ou OIDC. Grande parte das empresas optou por utilizar o provedor de identidades de uma nuvem para federar outras como o exemplo abaixo:
A arquitetura de autenticação exibida acima é muito comum no mercado, onde utiliza-se o Azure AD como ponto central de autenticação, federando outros provedores através de protocolos como SAML ou OIDC.
Neste caso o Azure, torna-se o IDP (Identity Provider) e os provedores GCP e AWS SP (Service Provider), onde toda autenticação realizada é concentrada no IDP e devolvido o token de acesso para o provedor de serviços delegando a autenticação da identidade.
Isto torna a experiência dos usuários mais fluida e aumenta a segurança em certos aspectos, por exemplo o usuário não precisa mais possuir 3 logins de acesso, com 3 senhas diferentes aumentando a chance de salvar estes acessos (chaves do datacenter) em locais inseguros, porém...
Novos desafios? Claro!
Federar acessos de uma cloud em outra, ou seja, permitir que identidades de um provedor de cloud sejam usadas para acessar serviços em outro provedor, pode trazer uma série de desafios e problemas. A seguir estão alguns dos principais problemas dessa prática:
O ponto único de falha se torna uma das clouds
Centralizar a autenticação em uma única nuvem torna essa cloud um ponto crítico de vulnerabilidade, e uma falha ou ataque nela pode comprometer o acesso a todas as outras nuvens conectadas.
Inconsistências na política de segurança
Cada provedor de cloud tem suas próprias políticas de segurança, o que pode causar desalinhamento com a política de gestão de identidades corporativa ao tentar aplicar regras uniformes em múltiplas nuvens, criando possíveis lacunas de segurança.
Superfície de ataque ampliada
A autenticação em várias clouds aumenta os pontos de movimentação lateral para possíveis ataques, onde uma credencial comprometida na nuvem provedora de identidades IDP pode ser usada para atacar outras conectadas, expandindo os riscos.
Como otimizar o processo de autenticação multicloud
O uso de um IDP externo (Provedor de Identidade) otimiza o processo de autenticação multicloud de diversas maneiras, garantindo uma experiência de segurança consistente e simplificada. Afinal, diferentemente dos provedores de cloud, eles foram desenvolvidos apenas para esta função e trazem mais alternativas no que tange processos como autenticação, autorização e ciclo de vida de identidades em cloud.
Neste caso o provedor de identidades (IDP) externo assume a função do Azure AD mostrado na imagem anterior, tornando as 3 clouds apenas provedores de serviço (SP), centralizando todo o processo de autenticação em uma solução desenhada especificamente para esta tarefa.
Levando em conta que estamos tratando de autenticação de clouds, também é interessante que este provedor de identidades (IDP) atue no modelo SaaS, desta forma não é necessário depender de processos de disponibilidade on-premises neste tipo de autenticação, como no exemplo abaixo:
E o fator adicional de autenticação (MFA), onde entra nesta história?
A autenticação multifator (MFA) é essencial em ambientes de nuvem para fortalecer a segurança e reduzir o risco de acessos não autorizados. Em um cenário onde as contas gerenciam recursos críticos, a MFA introduz camadas adicionais de autenticação, indo além de senhas tradicionais, que são frequentemente vulneráveis a ataques. A MFA combina diferentes fatores para verificar a identidade do usuário:
O que você sabe: Credenciais como senhas ou PINs.
O que você tem: Dispositivos como tokens físicos, smartphones, ou aplicativos de autenticação.
O que você é: Métodos biométricos, como impressão digital ou reconhecimento facial.
Como medir o nível de segurança do perfil de autenticação (AAL)?
O AAL (Authenticator Assurance Level) é um conceito do NIST (National Institute of Standards and Technology) que define níveis de garantia de segurança para autenticação, indicando o quão confiável é o processo de validação da identidade de um usuário. Ele é parte das diretrizes do NIST SP 800-63 e tem como objetivo principal estabelecer padrões para minimizar o risco de acessos não autorizados em sistemas digitais.
Os níveis de AAL são classificados de acordo com a robustez dos métodos de autenticação:
AAL1: Garantia básica, exige um único fator de autenticação (como uma senha). É suficiente para sistemas de baixo risco.
AAL2: Garantia moderada, exige autenticação multifator (MFA) com dois elementos distintos (por exemplo, senha e token de autenticação).
AAL3: Garantia alta, exige autenticação robusta, como chaves de segurança baseadas em criptografia (FIDO2) ou biometria combinada com dispositivos confiáveis.
O objetivo principal do AAL é ajudar organizações a escolher o nível apropriado de autenticação com base na sensibilidade dos dados ou sistemas protegidos, balanceando segurança e usabilidade.
A adoção de passkeys baseadas em padrões como FIDO2 já alcança o nível de garantia AAL3 do NIST, o mais alto nível de segurança para autenticação. Esse método elimina a necessidade de senhas, reduzindo vulnerabilidades como phishing ou roubo de credenciais, sendo ideal para contas de alto privilégio em ambientes multicloud.
Acesso Condicional e Adaptativo
Para tornar ainda mais robusto o processo de autenticação, a introdução de acesso condicional e adaptativo em clouds ajuda a aprimorar ainda mais a segurança:
Acesso condicional: Define políticas de acesso baseadas em condições como localização, dispositivo ou comportamento do usuário. Por exemplo, o acesso pode ser bloqueado automaticamente para tentativas fora de uma região específica.
Acesso adaptativo: Avalia riscos em tempo real, ajustando os requisitos de autenticação. Usuários suspeitos podem ser obrigados a passar por verificações adicionais, enquanto acessos confiáveis seguem com menos fricção.
A utilização de machine learning e inteligência artificial por soluções de UEBA (User and Entity Behavior Analytics) permite a criação de perfis de autenticação e acesso de usuários, aprendendo como estes se autenticam utilizando fatores como: Localização, Endpoint, Browser, IP, Dia da semana, horários, aplicações utilizadas, entre outros... Desta maneira é possível detectar riscos e gerar gatilhos de adaptatividade de autenticação baseado nestes.
MFA para Contas Root e Operacionais
A indústria recomenda que a MFA seja obrigatória para contas root devido aos privilégios elevados e ao impacto que uma possível violação pode causar. Essas contas devem utilizar os métodos mais seguros, como chaves físicas ou biometria, para garantir máxima proteção. Atualmente alguns sistemas de PAM (Privileged Access Manager) já suportam a autenticação MFA com o código TOTP sendo gerado pela própria solução, pois provedores como Microsoft já tornaram o MFA obrigatório para acessos humanos aos serviços do Azure.
Para contas operacionais, a aplicação de MFA também é essencial, entretanto por se tratar de acesso de alta frequência, a adaptatividade é essencial para garantir que o usuário não tenha fricção no dia a dia e em uma situação de risco execute a comprovação da identidade usando métodos como aplicativos autenticadores ou tokens, especialmente em operações críticas.
Autentiquei de maneira segura, e agora? (Autorização)
Autorização define o que um usuário pode acessar e fazer após a autenticação. Em ambientes multicloud, cada provedor (AWS, Azure, GCP) aplica suas próprias políticas de acesso. Considerando a AWS por exemplo, onde existem mais de 1400 produtos e mais de 40.000 permissões possíveis, existem diversos métodos para conceder ou limitar autorização de acesso, dentre eles:
Políticas de autorização baseadas em identidades
Políticas de autorização baseadas em recursos
Limites de permissões (Permissions boundaries)
Políticas de controle de serviço de organizações (Organizations SCPs)
Políticas de controle de recursos de organizações (Organizations RCPs)
Listas de controle de acesso (ACLs)
Políticas de sessão (Session policies)
Este último, por exemplo, trata de autorização baseada em federação onde é possível atribuir perfis de acesso a usuários originados em outro diretório, por exemplo o Azure AD. E novamente a federação que auxilia bastante, traz um novo desafio, pois neste caso ela aumenta drasticamente as 40.000 possibilidades de permissionamento da AWS expandindo a possibilidade aos perfis do Azure também.
Como mitigar este problema?
Neste caso é interessante possuir autorização centralizada e gerida de forma federada usando IDPs externos com servidores de autorização (authorization server), garantindo que os usuários tenham o acesso correto em todas as nuvens.
Orquestrando de maneira em um servidor de autorização (authorization server), é possível criar kits de acesso multi-cloud, onde um perfil ou política de acesso é capaz de conceder os acessos corretos nas clouds públicas do ambiente de maneira ágil e eficaz.
Isto é possível através de federação utilizando protocolos como SAML ou OIDC, que fornecem informações sobre o usuário para determinar quais recursos estão e quais ações estão autorizados a realizar. Estas informações são passadas através de Assertions no caso do SAML e Claims no caso do OIDC.
Claims: São declarações feitas sobre o usuário ou entidade, como o nome, e-mail, grupo de pertencimento ou função. No OIDC, elas são carregadas em um token (geralmente um JWT) enviado pelo IdP.
Assertions: São declarações estruturadas usadas no SAML, que incluem atributos (claims) sobre o usuário e metadados de autenticação.
Ambos fornecem informações que podem ser mapeadas para permissões específicas em AWS, Azure e GCP.
Do estático ao elástico: CIEM e seu papel na governança de identidades multi-cloud
Com toda a complexidade envolvida no permissionamento de acessos multi-cloud, se torna um grande desafio para o usuário saber as permissões mínimas que ele precisa para realizar as atividades necessárias para o seu trabalho e a consequência são privilégios e provisionamentos excessivos, onde pela quantidade de possibilidades envolvidas se torna humanamente impossível de analisar.
As tecnologias tradicionais de Identity Governance and Administration (IGA) enfrentam desafios significativos ao realizar revisões de acesso em ambientes multi-cloud porque foram projetadas principalmente para gerenciar identidades em ambientes tradicionais.
Exemplo de Política de acesso da AWS
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::example-bucket", "arn:aws:s3:::example-bucket/*" ] }, { "Effect": "Deny", "Action": [ "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::example-bucket/*" ] }, { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "arn:aws:ec2:region:account-id:instance/*", "Condition": { "StringEquals": { "ec2:ResourceTag/Owner": "team-a" } } } ] } |
Explicação da Política JSON
Permissões em Bucket S3:
Permite listar, obter e adicionar objetos no bucket example-bucket, mas impede a exclusão de objetos.
Permissões em Instâncias EC2:
Permite iniciar e parar instâncias EC2, mas somente para recursos marcados com a tag Owner: team-a.
Dificuldades de Revisão com governança de identidades tradicional (IGA)
Formato Técnico e Complexo:
A política em JSON exige conhecimentos técnicos detalhados para interpretar ações, recursos e condições. Ferramentas de governança de identidades tradicionais não são projetadas para entender diretamente políticas baseadas em JSON, tornando difícil extrair e revisar permissões.
Condições Granulares:
Condições como "ec2:ResourceTag/Owner": "team-a" adicionam complexidade. Revisar manualmente cada condição para garantir alinhamento com as políticas organizacionais pode ser demorado e suscetível a erros.
Escalabilidade:
Em ambientes multi-cloud, o número de políticas JSON cresce rapidamente, e tecnologias de governança tradicionais não foram projetadas para escalabilidade de permissões com sofrendo alterações frequentemente ou que têm diferentes estruturas entre provedores de nuvem.
Falta de Contexto Dinâmico:
Solulções de governança tradicionais são projetadas para ambientes estáticos, enquanto ambientes multi clouds são voláteis. Novos recursos, alterações em tags e mudanças nas permissões ocorrem constantemente, e IGA não oferece visibilidade em tempo real para revisões eficazes.
Interpretação de Políticas Cruzadas:
Quando uma política permite ações em um serviço (S3) e restringe ações em outro (EC2), a dependência entre permissões pode não ser óbvia para uma ferramenta de governança tradicionais, dificultando a análise completa.
Para suprir este gap, tecnologias como CIEM (Cloud Infrastructure Entitlements Management) surgiram para auxiliar no mapeamento de permissões administrativas multi-cloud, lendo os permissionamentos existentes e os logs de auditoria dos provedores, para entender diversos fatores, principalmente a frequência de utilização, políticas de acesso e recursos mapeando possibilidades como escalação de privilégios, shadow admins e fatores como MFA para contas root.
Como o gráfico abaixo aponta, a pesquisa da The Business Resarch company aponta um grande crescimento de 2023 para 2024 na utilização deste tipo de tecnologia com tendencia de crescimento exponencial até 2028.
Tecnologias de CIEM (Cloud Infrastructure Entitlement Management) tem como proposta solucionar esta dor ao:
Visualizar Políticas de Forma Intuitiva: Traduz políticas JSON complexas para relatórios claros e acionáveis.
Detectar Permissões Excessivas: Analisa automaticamente permissões desnecessárias ou condições inconsistentes.
Gerenciar Escalabilidade e Dinamismo: Atualiza continuamente os dados de permissões para refletir mudanças na nuvem.
Consolidar Políticas Multi-Cloud: Oferece uma visão unificada de permissões entre diferentes plataformas.
Ou seja, este tipo de tecnologia atua de maneira proativa para identificar riscos de permissões em ambientes multi-cloud, fornecendo insights claros e acionáveis para equipes de segurança. Essa abordagem automatizada e adaptativa é essencial para acompanhar o dinamismo da nuvem, onde recursos, permissões e usuários estão em constante mudança.
A Complexidade do Permissionamento em Multi-Cloud
A AWS, por exemplo, frequentemente lança novos serviços e atualizações, o que expande continuamente o conjunto de permissões disponíveis. Atualmente, existem cerca de 40.000 permissões possíveis nos serviços AWS, e cada novo serviço introduz dezenas ou centenas de novas permissões. Isso representa um desafio significativo, pois a revisão manual de acessos é humanamente impossível. Ferramentas tradicionais de governança de identidades (IGA) não foram projetadas para lidar com esse volume e complexidade, tornando-se ineficazes nesse cenário.
Além disso, o usuário final, muitas vezes, não tem o conhecimento técnico necessário para determinar quais permissões mínimas são necessárias para realizar suas tarefas. Isso leva a solicitações excessivas de acesso, resultando em privilégios desnecessários que ampliam a superfície de ataque.
A Proposta do CIEM para Multi-Cloud
CIEM aborda essas limitações ao integrar dados de permissões e logs de auditoria dos provedores de nuvem para criar um mapeamento completo e detalhado de acessos. Entre as principais funcionalidades do CIEM, destacam-se:
Análise Baseada em Logs:
Leitura dos logs de auditoria para identificar permissões utilizadas e não utilizadas, ajudando a reduzir privilégios desnecessários.
Detecção de padrões de uso que podem indicar shadow admins (usuários com privilégios elevados escondidos) ou escalonamento de privilégios.
Contexto em Tempo Real:
Atualização constante de permissões com base no comportamento dinâmico dos recursos na nuvem.
Integração com tecnologias de MFA para reforçar a segurança de contas críticas, como contas root.
Otimização de Políticas:
Recomendações automáticas para ajustar políticas e alinhar permissões ao princípio de menor privilégio.
Redução da dependência de acessos permanentes, promovendo acessos temporários baseados em tokens.
Os colaboradores trabalham 24x7? Por que a superfície de ataque precisa ser?
Em um mundo onde as operações empresariais não param, é tentador imaginar que os acessos aos sistemas também devam estar disponíveis o tempo todo. No entanto, permitir acessos fixos 24x7 cria uma superfície de ataque constante, que pode ser explorada por atacantes em momentos de vulnerabilidade, como fora do horário comercial. Para mitigar esse risco, o modelo de zero acessos fixos surge como uma evolução segura e eficiente no gerenciamento de permissões.
O conceito de zero acessos fixos redefine a maneira como os privilégios são gerenciados. Em vez de manter permissões permanentes para usuários e sistemas, as permissões são concedidas temporariamente, com validade limitada ao período necessário para a execução de uma tarefa específica. Essa abordagem elimina a possibilidade de um atacante explorar privilégios que permanecem inativos por longos períodos e garante que o princípio do menor privilégio seja aplicado de forma dinâmica.
Zero Acessos Fixos: Uma Nova Abordagem à Segurança
Acessos Temporários e Baseados em Necessidade:
Permissões são concedidas apenas quando solicitadas e aprovadas, com tempo de expiração automático.
Reduz drasticamente os privilégios disponíveis a qualquer momento, minimizando o impacto de uma credencial comprometida.
Integração com Políticas Condicionais:
Políticas baseadas em contexto, como localização, horário e identidade, ajustam permissões de acordo com o risco do momento.
Garantem que acessos fora de um escopo esperado sejam automaticamente negados.
Monitoramento e Auditoria Contínuos:
Cada solicitação e uso de acesso é registrado, facilitando a detecção de comportamentos anômalos em tempo real.
Ajuda a alinhar a segurança à estratégia Zero Trust, onde cada acesso é verificado continuamente.
Por Que Zero Acessos Fixos é Mais Seguro?
Eliminação de Privilégios Permanentes: A ausência de permissões fixas significa que atacantes não encontram acessos ativos para explorar.
Resistência a Ataques Fora do Expediente: Com acessos temporários, credenciais não estão disponíveis 24x7, dificultando ataques em horários de baixa vigilância.
Redução da Superfície de Ataque: Apenas os acessos necessários para a tarefa em execução estão ativos, limitando os recursos disponíveis a um invasor.
Ao implementar o zero acessos fixos, empresas substituem a abordagem tradicional de permissões estáticas por uma estratégia dinâmica e adaptável, alinhada às necessidades modernas de segurança em multi-cloud. Essa evolução não apenas protege os sistemas contra ameaças emergentes, mas também simplifica o gerenciamento de acessos, garantindo que a superfície de ataque seja tão limitada quanto possível.
Os colaboradores não trabalham 24x7, e agora, com o zero acessos fixos, a superfície de ataque também não precisa ser.
Identidade validada. Acesso concedido. E agora?
Mesmo com autenticação segura e concessão de acessos apropriados, comportamentos maliciosos de insiders podem comprometer ambientes multi-cloud. Auditar ambientes multi-cloud também tem se mostrado um grande desafio para as empresas e neste ponto é essencial implementar soluções de monitoramento contínuo e proteção contra atividades inadequadas.
Proteção de Contas Root:
Gerenciamento de Acesso Privilegiado (PAM): Utilizar soluções de PAM para gerenciar contas root, incluindo rotação regular de senhas, autenticação multifator (MFA) robusta e gravação de sessões. Essas medidas dificultam o uso indevido de credenciais privilegiadas.
Monitoramento de Comportamento: Além de isolar, gravar e auditar a sessão, o sistema de PAM deve ser capaz de detectar atividades anômalas e gerem alertas para o Centro de Operações de Segurança (SOC) e respostas automatizadas, alinhando-se à estratégia de Identity Threat Detection and Response (ITDR) conforme destacado pelo Gartner Top Trends in Cybersecurity 2022.
Acesso a Contas Operacionais:
Monitoramento Contínuo de Comportamento: Adotar soluções que analisem atividades em tempo real, identificando desvios de comportamento e prevenindo ações maliciosas sem impactar a experiência do usuário.
Proteção de Sessões: Implementar ferramentas que supervisionem sessões operacionais, garantindo que ações realizadas estejam em conformidade com as políticas de segurança e gerando alertas em caso de atividades suspeitas.
A imagem abaixo é um exemplo de como podemos proteger sessões gerenciadas através de contas root ou operacionais, seguindo as melhores práticas de segurança e mantendo a experiência nativa do usuário para o dia-a-dia.
Identidades não humanas em ambientes multi-cloud
No universo multi-cloud, as identidades não humanas — como máquinas, serviços, APIs e aplicativos — desempenham um papel fundamental na comunicação e operação dos sistemas. Essas identidades são responsáveis por ações críticas, como integração de sistemas, execução de processos automatizados e troca de informações sensíveis entre serviços. No entanto, sua invisibilidade e autonomia tornam-nas alvos atraentes para atacantes e um dos principais vetores de risco em ambientes de nuvem.
Principais desafios
Volume e Complexidade: Em ambientes dinâmicos, o número de identidades não humanas pode superar o de usuários humanos, dificultando a governança.
Privilégios Excessivos: Muitas vezes, essas identidades recebem permissões amplas por conveniência, criando riscos de escalonamento de privilégios.
Autenticação Frágil: A dependência de chaves estáticas e credenciais hardcoded aumenta a exposição a vazamentos e ataques.
Melhores práticas para identidades não humanas em cloud
Autenticação Forte:
Utilize credenciais temporárias geradas dinamicamente, como tokens emitidos por provedores de identidade, eliminando chaves estáticas.
Integre métodos de autenticação baseados em certificados e protocolos seguros, como OAuth 2.0 ou OpenID Connect (OIDC).
Princípio do Menor Privilégio:
Revise regularmente as permissões atribuídas a essas identidades para garantir que apenas os acessos necessários sejam concedidos.
Utilize limites de permissões (permissions boundaries) e políticas baseadas em contexto para restringir acessos.
Proteção de segredos:
Automatize a rotação de credenciais usando ferramentas nativas dos provedores de cloud ou soluções externas especializadas.
Armazene chaves e tokens em gerenciadores de segredos, protegendo-os contra acesso não autorizado.
Monitoramento Contínuo com API Protection:
Implemente soluções de proteção de APIs para monitorar o comportamento e uso de identidades não humanas em tempo real.
Identifique padrões de tráfego incomuns, abuso de endpoints ou tentativas de uso de tokens fora do escopo previsto.
Proteja integrações contra exploits de API, como chamadas excessivas, injeção de dados ou acessos não autorizados.
Configure redes e ambientes isolados para limitar o impacto de uma eventual violação de uma identidade não humana.
Utilize políticas de acesso condicional para limitar interações entre serviços.
Níveis de proteção ainda mais elevados
A implementação deste monitoramento permite elevar o nível da autenticação ao que a indústria costuma chamar de autenticação contínua, onde em gatilhos de comportamentos inadequados ou duvidosos, é possível solicitar para que o usuário se reautentique, comprovando que a identidade está sendo utilizada por quem se diz ser, possibilitando o não-repúdio do comportamento realizado. Alguns gatilhos normalmente podem ser utilizados para solicitar reautenticação, sendo alguns exemplos:
· Tempo de sessão
· Contador de passos baseado em aplicativo de acesso
· Comportamentos inadequados
Em ambientes multi-cloud, as políticas de segurança dos browsers também são fundamentais para proteger contra ameaças como roubo de cookies, sequestro de sessões e outras vulnerabilidades que podem comprometer acessos operacionais e privilegiados.
Empresas têm adotado tecnologias de browser seguro para acesso operacional, especialmente para terceiros, garantindo que a infraestrutura da organização não dependa da segurança do equipamento externo. Estas soluções utilizam tecnologias como:
· Sandboxing
· Proteção contra roubo de credenciais
· Isolamento do sistema operacional
· Armazenamento de cookies em SaaS
Conclusão
Proteger acessos em ambientes multi-cloud exige mais do que tecnologias individuais; requer a criação de um Identity Fabric, como preconizado pelo Gartner. Esse conceito integra diversas ferramentas e práticas para formar uma malha de proteção unificada, capaz de gerenciar identidades e acessos de forma coesa em múltiplas nuvens. Tecnologias como IDP (Provedor de Identidade) e SSO (Single Sign-On) centralizam e simplificam a autenticação, enquanto a MFA (Autenticação Multifator) adiciona uma camada crítica de proteção contra acessos indevidos.
CIEM (Cloud Infrastructure Entitlement Management) contribui para esse Identity Fabric ao oferecer visibilidade contínua e controle granular sobre permissões, detectando e eliminando privilégios excessivos antes que sejam explorados. A abordagem de zero privilégios fixos, com políticas de acesso temporárias multi-cloud, complementa essa estratégia ao reduzir a janela de oportunidade para atacantes. Além disso, a gravação de sessões agrega valor ao ITDR (Identity Threat Detection and Response), permitindo auditorias detalhadas e rastreamento de ações para identificar e mitigar comportamentos inadequados.
Como destacado pelo Gartner, o ITDR é uma disciplina contínua, não uma solução isolada. Sua eficácia depende da integração dessas tecnologias para criar uma defesa em camadas, que detecta, responde e neutraliza ameaças associadas ao abuso de identidades. Quando implementado corretamente, o Identity Fabric possibilita uma governança unificada de acessos, adaptando-se ao crescimento e complexidade dos ambientes multi-cloud, enquanto oferece a resiliência necessária para enfrentar ameaças em constante evolução.
Somadas, essas tecnologias criam um ecossistema robusto de proteção, capaz de enfrentar os desafios de acessos complexos em infraestruturas multi-cloud. Ao integrar essas soluções, as organizações não apenas fortalecem sua postura de segurança, mas também se alinham às melhores práticas, garantindo que seus ambientes sejam resilientes, escaláveis e preparados para ameaças em evolução.
Comments