Segurança e conformidade: os controles da Clikma

Identidade e controle de acesso

Cada empresa decide como as suas pessoas entram, de onde e com quais permissões.

• Login único (SSO) com SAML 2.0 e LDAP

  É configurado com o provedor de identidade da empresa, para que as pessoas entrem com as credenciais que já usam.

• Autenticação de dois fatores (MFA)

  Segundo fator com aplicativo autenticador, ativado por empresa e por usuário.

• Políticas de senha por empresa

  Complexidade, histórico, expiração e bloqueio por tentativas.

• Lista de IPs permitidos por empresa

  Cada empresa define os endereços a partir dos quais é possível entrar ou usar a API.

• Controle de sessões ativas

  Mostra onde há sessões abertas e permite forçar o seu encerramento.

• Perfis de acesso e permissões personalizados

  Perfis de acesso criados a partir dos perfis base, com o princípio de dar a cada um apenas o que precisa.

• Segurança e integrações

Rastreabilidade e auditoria

O que acontece na plataforma fica registrado: quem alterou o quê, quando e, se estava vendo a plataforma como outra pessoa, por quê.

• Auditoria de alterações campo a campo

  Registra quem alterou cada dado e, se havia um acesso como outro usuário em andamento, quem o estava fazendo.

• Acesso como outro usuário em modo somente leitura

  Para diagnosticar um problema sem modificar nada, com motivo, início, fim e um aviso visível.

• Histórico de alterações por conteúdo

  Quem alterou o quê em cada conteúdo, com o valor anterior e o novo.

• Histórico de cargas em massa

  Status, erros e arquivo original de cada carga em massa.

• Auditoria exportável da conformidade

  Histórico de cada requisito e documento, exportável para auditorias e fiscalizações.

Proteção dos dados

Os dados de cada empresa trafegam criptografados, são armazenados criptografados e ficam separados dos dados das demais empresas.

• Criptografia em trânsito

  Todo o tráfego passa por HTTPS com TLS, e os certificados são renovados automaticamente.

• Criptografia em repouso

  O banco de dados, os backups e os arquivos são armazenados com a criptografia em repouso aplicada pelo provedor de nuvem.

• Dados hospedados no Chile

  A plataforma e o seu banco de dados de produção operam na região de Santiago.

• Separação lógica por empresa

  Cada usuário acessa apenas os dados da sua empresa, de acordo com os seus privilégios.

• O conteúdo não treina a IA

  O assistente de IA indexa o conteúdo da empresa para responder, sem usá-lo para treinar o modelo.

• Direitos do titular de dados pessoais (Ley 21.719)

  As solicitações de acesso, retificação, exclusão e consentimento são atendidas por meio de um procedimento.

• Proteção de dados pessoais

Desenvolvimento seguro e gestão de mudanças

Cada mudança percorre o mesmo caminho antes de chegar à produção.

• Ambientes separados

  Desenvolvimento, demo, testes de aceitação e produção, cada um com os seus próprios dados.

• Revisão de cada mudança

  Cada mudança entra por uma solicitação de integração, que é revisada e aprovada antes de chegar ao branch de produção.

• Análise estática de código

  Cada serviço é analisado para detectar erros e vulnerabilidades antes de ser integrado.

• Verificação de acessibilidade a cada atualização

  Regras automáticas revisam a acessibilidade de cada mudança; a que não cumpre os requisitos não é integrada.

• Infraestrutura versionada

  A configuração da infraestrutura está declarada em repositórios versionados.

• Arquitetura da plataforma

Continuidade e recuperação

A plataforma está preparada para que a falha de um componente não interrompa o serviço e para recuperar os dados, se necessário.

• Redundância de serviços

  Cada serviço de produção roda com mais de uma réplica sobre Kubernetes.

• Banco de dados com réplica em espera

  Uma réplica em outra zona da região assume se o banco principal falhar.

• Backup diário e recuperação para um ponto no tempo

  O banco de dados pode ser recuperado para qualquer momento dos últimos 14 dias.

• Reconstrução documentada

  Um procedimento com scripts permite subir a plataforma completa em um cluster novo, e a configuração do cluster tem backup diário.

Resposta a incidentes

A Clikma tem uma equipe de resposta a incidentes (IRT) formada pelo PMO, pela diretoria geral, pela diretoria de tecnologia e pela equipe de desenvolvimento, que trabalha com o método do NIST SP 800-61: preparação, detecção e análise, contenção, erradicação e recuperação, e atividades posteriores.

• Severidades e tempos de resposta

  Primeira resposta em 30 minutos ou menos para um incidente crítico, 1 hora para um alto, 4 horas para um médio e 1 dia útil para um baixo.

• Comunicação com a empresa cliente

  O caso é registrado na central de ajuda da Clikma, que notifica a empresa a cada mudança de status e a cada comentário.

• Análise posterior

  Cada incidente é encerrado com uma análise de causas e ações para que não se repita.

• Suporte, SLA e incidentes

Mapa de controles: NIST CSF 2.0 e ISO/IEC 27001:2022

A tabela relaciona os controles descritos nesta página com as funções do NIST Cybersecurity Framework 2.0 e com os temas de controles do Anexo A da ISO/IEC 27001:2022. É um guia de leitura para a sua avaliação, não uma declaração de certificação de conformidade.

Frameworks de referência

• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-61, recomendações para a resposta a incidentes
• ISO: ISO/IEC 27001:2022, sistemas de gestão da segurança da informação