No panorama regulatório moderno, a Gestão de Identidades e Acessos (IAM) deixou de ser apenas uma tarefa operacional de TI; tornou-se uma exigência legal e de conformidade. Dois dos frameworks mais críticos neste domínio são o SOC 2 (System and Organization Controls 2) e o RGPD (Regulamento Geral sobre a Proteção de Dados).
Embora o SOC 2 se foque na confiança na prestação de serviços e o RGPD privilegie os direitos de privacidade dos indivíduos, ambos convergem na mesma verdade: Não se pode proteger dados se não se consegue verificar a identidade da pessoa que lhes acede.
Segue-se uma análise rigorosa das cláusulas e critérios específicos em ambos os frameworks que obrigam a uma forte autenticação de identidade, incluindo links diretos para os standards oficiais.
Parte 1: Requisitos do SOC 2 (Os critérios dos serviços de confiança)#
As auditorias SOC 2 são baseadas nos Critérios de Serviços de Confiança (TSC) da AICPA de 2017. Para a Autenticação de Identidade, a Série Common Criteria (CC) 6.0 (Controlo Lógico e Físico de Acessos) é a principal autoridade.
1. A base do acesso lógico (CC6.1)#
O Critério:
"A entidade implementa software, infraestruturas e arquiteturas de segurança de acesso lógico sobre os ativos de informação protegidos para os proteger de eventos de segurança, de forma a atingir os objetivos da entidade."
Análise:
Esta é a base obrigatória para um sistema IAM. Para cumprir a CC6.1, a organização deve provar que tem um mecanismo centralizado (como um Identity Provider - IdP) para gerir identidades. Contas partilhadas ou ad-hoc normalmente resultam numa falha, pois tornam "a segurança de acesso lógico" impossível de auditar.
2. Verificação de identidade & ciclo de vida (CC6.2)#
O Critério:
"Antes de emitir credenciais e conceder acesso ao sistema, a entidade regista e autoriza novos utilizadores internos e externos cujo acesso é administrado pela entidade."
Análise:
Isto exige um processo rigoroso de Entrada/Mudança/Saída (JML).
- Exigência de Autenticação: Deve-se verificar a identidade do utilizador antes de lhe atribuir nome de utilizador/palavra-passe.
- Revogação: Quando um colaborador sai, o acesso deve ser revogado imediatamente (normalmente em 24 horas).
- Prova Necessária: Os auditores pedem uma "lista de população" de colaboradores que saíram e cruzam-na com registos de sistema para comprovar que os tokens de autenticação foram desativados a tempo.
3. O mandato MFA (CC6.3)#
O Critério:
"A entidade autoriza, modifica ou remove o acesso a dados, software, funções e outros ativos de informação protegidos com base em papéis, responsabilidades ou desenho do sistema..."
Análise:
Embora o texto mencione explicitamente "papéis" (RBAC), os "Pontos de Foco" da AICPA para a CC6.3 destacam a necessidade de Autenticação Multi-Fator (MFA).
- Interpretação Estrita: Para relatórios SOC 2 Tipo II modernos, confiar apenas em autenticação de um único fator (palavras-passe) para acesso administrativo, repositórios de código-fonte ou dados de produção é quase sempre considerado uma "deficiência significativa" ou uma exceção.
- Exigência: O acesso a ambientes de produção ou dados de clientes deve ser protegido por MFA.
4. Revalidação (CC6.4)#
O Critério:
"A entidade restringe o acesso físico a instalações e ativos de informação protegidos apenas a pessoal autorizado para atingir os objetivos da entidade."
Análise:
Aplicado ao acesso lógico, isto obriga a Revisões de Acessos de Utilizador (UAR). Não basta autenticar um utilizador uma vez; é obrigatório revalidar periodicamente (tipicamente trimestralmente) se a identidade ainda é válida e tem os privilégios corretos.
Parte 2: Requisitos do RGPD (A abordagem baseada no risco)#
Ao contrário do SOC 2, o RGPD é legislação europeia. Não lista tecnologias específicas (como "usar apps OTP"), mas impõe resultados que tornam a autenticação forte um requisito legal.
1. Integridade e confidencialidade (Artigo 5)#
A Cláusula: Artigo 5(1)(f)
"Os dados pessoais devem ser tratados de modo a garantir a sua segurança, incluindo proteção contra tratamento não autorizado ou ilícito..."
Análise:
"Tratamento não autorizado" é a expressão-chave. Se um atacante descobre uma palavra-passe fraca e acede a dados pessoais, a organização falhou o artigo 5.
- Exigência de Autenticação: O método de autenticação tem que ser suficientemente forte para prevenir ataques comuns (como força bruta ou stuffing de credenciais). Isto implica políticas rigorosas de complexidade de palavras-passe e mecanismos de rate-limiting.
2. Segurança do tratamento (Artigo 32)#
A Cláusula: Artigo 32(1)
"Tendo em conta o estado da técnica, os custos de implementação e a natureza, âmbito, contexto e finalidades do tratamento... o responsável pelo tratamento e o subcontratante devem implementar medidas técnicas e organizativas apropriadas..."
Análise:
Esta é a cláusula do "Estado da Técnica".
- Interpretação rigorosa: Em 2024/2025, MFA é considerada "estado da técnica" para acesso a dados sensíveis. Se ocorrer uma violação e a organização apenas usar palavras-passe (uma postura obsoleta para dados de alto risco), os reguladores (como ICO ou CNIL) provavelmente vão considerar as medidas "inapropriadas" nos termos do Artigo 32.1
- Encriptação: O artigo 32 também menciona explicitamente a encriptação. Os sistemas de identidade devem encriptar credenciais em trânsito e em repouso (hashing/salting).
3. Proteção de dados desde a conceção (Artigo 25)#
A Cláusula: Artigo 25(2)
"O responsável pelo tratamento deverá implementar medidas técnicas e organizativas apropriadas para garantir que, por defeito, só sejam tratados os dados pessoais necessários para cada finalidade específica do tratamento."
Análise:
Isto obriga ao princípio do menor privilégio.
- Exigência de autenticação: Não basta autenticar que "O Utilizador A é o Utilizador A". O sistema deve garantir que o Utilizador A só vê o que é necessário.
- Implicação na identidade: Isto reforça a necessidade de Controlo de Acesso Baseado em Papéis (RBAC) granular, diretamente ligado à identidade verificada.
Parte 3: Análise comparativa & resumo#
A seguinte tabela resume como satisfazer ambos os standards em simultâneo:
O veredito#
Para cumprir a análise rigorosa de ambos os standards:
- SOC 2 trata a identidade como um processo documentado. Tens de conseguir provar que tens um processo para criar, verificar e remover identidades.
- RGPD encara a identidade como um escudo protetor. Tens de conseguir provar que as tuas medidas de identidade são suficientemente fortes para evitar uma violação segundo o standard tecnológico atual.
O cumprimento do SOC 2 e do RGPD exige ir além da simples gestão de palavras-passe. As organizações precisam de implementar um Identity Provider (IdP) centralizado que imponha Autenticação Multi-Fator (MFA), Controlo de Acesso Baseado em Papéis (RBAC) rigoroso e registos automáticos de provisionamento. O não cumprimento leva a uma reprovação na auditoria SOC 2 (Exceção nas CC6.x) e a potenciais coimas RGPD por não implementar "medidas técnicas apropriadas" no artigo 32.
