A segurança da informação não se limita ao que está dentro do perímetro da sua organização. Com a crescente adoção de serviços em nuvem e ferramentas externas, é essencial entender como proteger dados e sistemas quando você depende de terceiros. Nesta aula, vamos explorar os conceitos fundamentais de segurança de serviços externos, incluindo Software como Serviço (SaaS), integrações de terceiros, o modelo de responsabilidade compartilhada e a necessidade de revisões periódicas de contas e permissões.

Vamos mergulhar em cada um desses tópicos, fornecendo exemplos práticos e recomendações acionáveis para que você possa fortalecer a postura de segurança da sua organização em relação a serviços externos.

SaaS

Software como Serviço (SaaS) é um modelo de distribuição de software em que um provedor terceirizado hospeda aplicações e as disponibiliza aos clientes pela internet. Exemplos comuns incluem Google Workspace, Microsoft 365, Salesforce, Slack e Zoom. Nesse modelo, o provedor é responsável por toda a infraestrutura, manutenção, atualizações e, em grande parte, pela segurança da plataforma. No entanto, o cliente ainda tem responsabilidades significativas, como gerenciar o acesso dos usuários, configurar políticas de segurança e proteger os dados que são armazenados no serviço.

Ao adotar um serviço SaaS, é crucial avaliar o nível de segurança oferecido pelo provedor. Verifique se ele possui certificações como ISO 27001, SOC 2, e se está em conformidade com regulamentações relevantes (LGPD, GDPR). Além disso, entenda onde os dados são armazenados e processados, e quais são as políticas de retenção e exclusão de dados. Uma boa prática é realizar uma due diligence de segurança antes de contratar qualquer serviço SaaS, revisando a documentação de segurança fornecida pelo provedor.

Exemplo de configuração de segurança em um serviço SaaS (simulação de política de senha em um arquivo de configuração):

# Exemplo de política de senha para um serviço SaaS
password_policy:
  minimum_length: 12
  require_uppercase: true
  require_lowercase: true
  require_numbers: true
  require_special_characters: true
  expiration_days: 90
  history_count: 5

Third-party

Integrações de terceiros (third-party) são componentes ou serviços externos que se conectam aos seus sistemas para adicionar funcionalidades ou automatizar processos. Isso pode incluir APIs, plugins, bibliotecas de código aberto, ou até mesmo serviços completos que se integram via APIs. Embora essas integrações tragam benefícios, elas também introduzem riscos de segurança, pois podem acessar seus dados e sistemas de maneiras que você nem sempre controla.

Para gerenciar esses riscos, é essencial manter um inventário atualizado de todas as integrações de terceiros utilizadas pela sua organização. Avalie cada integração quanto à sua necessidade, ao nível de acesso que ela exige e à reputação do fornecedor. Sempre que possível, aplique o princípio do menor privilégio: conceda apenas as permissões mínimas necessárias para o funcionamento da integração. Além disso, monitore as integrações quanto a atividades suspeitas e revise periodicamente se ainda são necessárias.

Um exemplo de código para verificar permissões de uma integração em uma API (simulação):

# Verificar permissões de uma integração de terceiros
integration_permissions = {
    "name": "AnalyticsTool",
    "scopes": ["read:reports", "write:events"],
    "status": "active"
}

def check_permission(integration, required_scope):
    if required_scope in integration["scopes"]:
        return True
    else:
        return False

# Exemplo de uso
if check_permission(integration_permissions, "admin:all"):
    print("Permissão de administrador concedida!")
else:
    print("Permissão limitada corretamente.")

Shared responsibility

O modelo de responsabilidade compartilhada (shared responsibility) é um conceito fundamental na segurança em nuvem. Ele define claramente quais responsabilidades de segurança são do provedor de serviços e quais são do cliente. No caso de SaaS, o provedor é responsável pela segurança da infraestrutura, plataforma e aplicação, enquanto o cliente é responsável pela segurança dos dados, gerenciamento de acesso e configuração do serviço.

Entender esse modelo é crucial para evitar lacunas de segurança. Muitas organizações assumem erroneamente que, ao usar um serviço SaaS, toda a segurança é responsabilidade do provedor. No entanto, o cliente ainda precisa garantir que as políticas de acesso, autenticação e proteção de dados estejam adequadamente configuradas. Por exemplo, se você não habilitar a autenticação multifator (MFA) para os usuários da sua conta SaaS, estará assumindo o risco de acesso não autorizado.

Um diagrama de responsabilidades compartilhadas pode ser representado assim:

Responsabilidades do Provedor:
- Segurança física dos datacenters
- Infraestrutura de rede
- Sistemas operacionais
- Aplicação SaaS

Responsabilidades do Cliente:
- Dados e conteúdo
- Gerenciamento de usuários e acessos
- Configuração de segurança
- Conformidade com regulamentações

Account reviews

As revisões de contas (account reviews) são processos periódicos de auditoria das contas de usuário e permissões em sistemas externos. O objetivo é garantir que apenas pessoas autorizadas tenham acesso aos serviços e que as permissões estejam alinhadas com as funções atuais dos usuários. Com o tempo, funcionários mudam de cargo, saem da empresa, ou acumulam permissões desnecessárias, o que aumenta a superfície de ataque.

Implementar um processo de revisão de contas envolve: identificar todos os serviços externos em uso, listar todas as contas associadas, revisar as permissões de cada conta e revogar acessos desnecessários. Isso deve ser feito em intervalos regulares (por exemplo, trimestralmente) e sempre que ocorrer uma mudança significativa, como a saída de um funcionário. Ferramentas de gerenciamento de identidade e acesso (IAM) podem automatizar parte desse processo, mas a revisão humana ainda é necessária para validar se os acessos fazem sentido.

Exemplo de script para listar usuários e permissões (simulação):

# Simulação de revisão de contas em um serviço externo
users = [
    {"name": "Alice", "role": "admin", "last_login": "2025-03-10"},
    {"name": "Bob", "role": "editor", "last_login": "2025-01-15"},
    {"name": "Carol", "role": "viewer", "last_login": "2024-12-01"}
]

for user in users:
    print(f"Usuário: {user['name']} - Papel: {user['role']} - Último login: {user['last_login']}")
    if user["role"] == "admin" and user["last_login"] < "2025-01-01":
        print("  -> Acesso administrativo inativo, considere revogar.")

Boas práticas e observações finais

Para finalizar, aqui estão algumas boas práticas essenciais ao lidar com serviços externos:

  • Centralize o gerenciamento de identidades: Use um provedor de identidade (IdP) como Okta ou Azure AD para gerenciar acessos de forma centralizada.
  • Aplique autenticação multifator (MFA): Exija MFA para todos os usuários em serviços externos, especialmente para administradores.
  • Monitore atividades: Ative logs e alertas para detectar comportamentos anômalos em serviços externos.
  • Revise contratos e SLAs: Verifique se os contratos com provedores incluem cláusulas de segurança e confidencialidade adequadas.
  • Eduque os usuários: Treine os funcionários sobre riscos de segurança e boas práticas ao usar serviços externos.

Em resumo, a segurança de serviços externos exige uma abordagem proativa e contínua. Ao entender os conceitos de SaaS, third-party, shared responsibility e account reviews, você estará melhor preparado para proteger sua organização contra ameaças relacionadas a esses serviços. Lembre-se de que a segurança é um processo contínuo, não um destino.

Referências

Exercícios

  1. Explique o modelo de responsabilidade compartilhada em um serviço SaaS e dê um exemplo de responsabilidade do cliente e do provedor.

✓ Resposta: O modelo de responsabilidade compartilhada define que o provedor é responsável pela segurança da infraestrutura, plataforma e aplicação, enquanto o cliente é responsável pela segurança dos dados, gerenciamento de acesso e configuração do serviço. Por exemplo, em um SaaS como o Google Workspace, o Google é responsável pela segurança física dos datacenters e pela infraestrutura, mas o cliente é responsável por configurar a autenticação multifator e gerenciar as permissões dos usuários.
  • Cite três riscos de segurança associados a integrações de terceiros e como mitigá-los.

    • ✓ Resposta: Riscos: 1) Excesso de permissões - mitigar aplicando o princípio do menor privilégio. 2) Vulnerabilidades no código do terceiro - mitigar realizando testes de segurança e mantendo as integrações atualizadas. 3) Roubo de dados através de APIs inseguras - mitigar usando autenticação forte e criptografia de dados em trânsito.
  • Descreva um processo de revisão de contas em um serviço externo, incluindo a frequência recomendada.

    • ✓ Resposta: O processo envolve: 1) Listar todos os serviços externos utilizados. 2) Coletar a lista de usuários e suas permissões em cada serviço. 3) Comparar com a lista de funcionários atuais e suas funções. 4) Revogar acessos de ex-funcionários ou contas inativas. 5) Ajustar permissões para que estejam alinhadas com as funções atuais. A frequência recomendada é trimestral ou semestral, e sempre após mudanças significativas, como demissões.
  • Dê um exemplo de política de senha forte para um serviço SaaS e explique por que é importante.

    • ✓ Resposta: Exemplo: mínimo de 12 caracteres, exigir letras maiúsculas, minúsculas, números e caracteres especiais, expiração a cada 90 dias e histórico de 5 senhas anteriores. Isso é importante porque senhas fortes reduzem o risco de ataques de força bruta e comprometimento de contas.
  • Qual é a importância de realizar due diligence de segurança antes de contratar um serviço SaaS? Cite dois itens que você verificaria.

    • ✓ Resposta: A due diligence ajuda a evitar contratar um provedor com práticas de segurança inadequadas. Verificaria: 1) Certificações como ISO 27001 e SOC 2. 2) Políticas de privacidade e proteção de dados, incluindo onde os dados são armazenados e como são tratados.