Perguntas sobre segurança, respondidas

Sim. A Scratcher ApS está certificada pela ISO/IEC 27001:2022, a norma internacional para sistemas de gestão de segurança da informação (SGSI). A certificação é emitida pela Bureau Veritas Certification sob acreditação (FINAS), certificado n.º FIHSK27150F, válido até 7 de novembro de 2028. Estamos certificados desde novembro de 2022.

Descarregue o certificado (PDF)

O âmbito certificado é o desenvolvimento, a venda e o apoio de software para campanhas interativas, marketing e atividades relacionadas, incluindo a recolha de dados e permissões. Na prática, abrange a plataforma Scratcher, as campanhas que nela correm, os nossos processos e a infraestrutura cloud por trás deles.

A Bureau Veritas realiza todos os anos uma auditoria externa de acompanhamento e, de três em três anos, uma auditoria de recertificação. Antes de cada auditoria externa, fazemos uma auditoria interna a todos os processos do SGSI e uma revisão pela gestão.

Sim. A nossa Declaração de Aplicabilidade está mapeada com os controlos do Anexo A da ISO/IEC 27001:2022 (ISO/IEC 27002:2022) e mostra que controlos se aplicam e como são implementados. Os clientes Enterprise podem solicitá-la.

Sim. Tratamos dados pessoais de acordo com o Regulamento Geral sobre a Proteção de Dados (RGPD) da UE. Para os dados das campanhas, o cliente é o responsável pelo tratamento e o Scratcher é o subcontratante (artigo 28.º), ao abrigo de um acordo de tratamento de dados (DPA).

Não. Em vez disso, a nossa segurança da informação está certificada pela ISO/IEC 27001:2022, e disponibilizamos o certificado e a Declaração de Aplicabilidade como documentação de garantia.

O nosso certificado ISO 27001 e a Declaração de Aplicabilidade cobrem a maioria das necessidades de auditoria e de avaliação de fornecedores. Se precisar de uma auditoria adicional, acordamos consigo antecipadamente o âmbito, o calendário e eventuais custos.

A si. Mantém todos os direitos sobre os seus dados (dados do cliente), e nós só os tratamos para prestar o serviço, conforme descrito nos nossos termos e no acordo de tratamento de dados.

Sim. Todos os clientes estão abrangidos pelo nosso acordo de tratamento de dados nos termos do artigo 28.º do RGPD. Os clientes Enterprise podem também usar um DPA baseado no modelo contratual padrão da autoridade dinamarquesa de proteção de dados (Datatilsynet).

Utilizamos um pequeno número de subcontratantes ulteriores cuidadosamente selecionados, por exemplo a Amazon Web Services (AWS) para o alojamento e um fornecedor para o envio de e-mails transacionais. Cada subcontratante está vinculado por um acordo de tratamento de dados. A lista atual está no Anexo B do nosso acordo de tratamento de dados.

Sim. Avisamo-lo com pelo menos 14 dias de antecedência antes de acrescentarmos ou substituirmos um subcontratante que trate os seus dados pessoais. Se não aceitar a alteração, pode rescindir o contrato.

Todos os dados dos clientes são armazenados na UE. Se um subcontratante tratar dados pessoais fora da UE/EEE, por exemplo para funcionalidades de IA ou proteção contra bots, a transferência é protegida pelas Cláusulas Contratuais-Tipo (CCT) da Comissão Europeia ou pelo Quadro de Privacidade de Dados UE-EUA (DPF).

Não. Só tratamos os seus dados segundo as suas instruções, para prestar o serviço (limitação das finalidades). Nunca vendemos os seus dados nem os usamos para o nosso próprio marketing.

Sim. Decide que campos de formulário tem cada campanha e quais são obrigatórios, para recolher apenas os dados de que realmente precisa (minimização dos dados).

É o cliente que decide o prazo de conservação. Pode apagar os dados dos participantes a qualquer momento ou definir a eliminação automática, por exemplo um determinado número de dias após o fim de uma campanha. O prazo máximo de conservação está definido no seu acordo de tratamento de dados.

Sim. Pode exportar participantes e leads em CSV a qualquer momento, enviá-los automaticamente para os seus próprios sistemas através das nossas integrações ou obtê-los através da nossa API REST (portabilidade dos dados).

Os seus dados são apagados após o fim da subscrição, de acordo com os nossos termos e o acordo de tratamento de dados. As cópias nas cópias de segurança são substituídas à medida que estas vão sendo renovadas. Exporte tudo o que quiser guardar antes de a subscrição terminar.

Enquanto responsável pelo tratamento, é o cliente que trata os pedidos dos participantes, como acesso, retificação ou apagamento (artigos 15.º a 17.º do RGPD). Pode encontrar, exportar e apagar os dados dos participantes na plataforma, e a nossa equipa ajuda-o se necessário.

Todos os dados dos clientes são armazenados em centros de dados da Amazon Web Services (AWS) na UE. Não temos servidores próprios, por isso a segurança física e ambiental é assegurada pela AWS, que está certificada pela ISO 27001, SOC 2 e outras normas reconhecidas.

• Isolamento de rede: todos os servidores e bases de dados correm numa rede privada (Amazon VPC) que não é acessível a partir da internet.
• Proteção na periferia: apenas os balanceadores de carga (ALB) e a rede de distribuição de conteúdos (Amazon CloudFront) são públicos, e estão protegidos por uma firewall de aplicações web (AWS WAF).
• Infraestrutura imutável: os servidores correm como contentores que nunca são alterados manualmente. Substituímo-los por versões novas e testadas, e não há acesso SSH.
• Bases de dados geridas: as bases de dados correm no Amazon RDS, um serviço de bases de dados gerido pela AWS.

Sim. Todo o tráfego passa pelo Amazon CloudFront e pela AWS WAF, que filtram pedidos maliciosos e absorvem grandes picos de tráfego (proteção DDoS) antes de chegarem aos nossos servidores.

O Scratcher é uma plataforma multi-tenant. Os dados de cada cliente estão separados logicamente por conta (isolamento de tenants), e cada pedido é autorizado, para que os utilizadores só vejam dados das contas a que têm acesso.

Sim. As chamadas à API e as alterações ao nosso ambiente AWS são registadas num registo de auditoria encriptado e à prova de adulteração (AWS CloudTrail com validação dos ficheiros de registo), e os registos da aplicação são recolhidos centralmente (Amazon CloudWatch). Na sua conta, pode ver o que os seus utilizadores fizeram no registo de atividade.

Gerimos a infraestrutura em conjunto com um parceiro especializado em DevOps, que também tem certificação ISO 27001. Os parceiros só obtêm o acesso de que o seu trabalho necessita (privilégio mínimo).

A plataforma é verificada automaticamente a cada 30 segundos a partir de várias regiões AWS (monitorização da disponibilidade). A nossa equipa de operações é alertada automaticamente se algo correr mal, e a maioria dos problemas é detetada em minutos. Os erros da aplicação são acompanhados com monitorização de erros.

Sim. A deteção automática de abusos funciona em segundo plano, e as campanhas podem usar proteção contra bots (Cloudflare Turnstile), limites de participação, códigos de verificação e listas de bloqueio para endereços de e-mail e números de telefone.

Sim. Todo o tráfego para a plataforma, as campanhas e a API é encriptado com TLS (HTTPS).

Sim. As bases de dados, os ficheiros e as cópias de segurança são encriptados em repouso com AES-256 através da AWS.

As chaves de encriptação são geridas pela AWS (chaves geridas pela AWS) e só estão disponíveis para os serviços que delas precisam.

As credenciais das suas integrações, como as chaves de API da sua ferramenta de e-mail ou CRM, são adicionalmente encriptadas na aplicação com AES-256 antes de serem armazenadas (encriptação ao nível da aplicação).

As palavras-passe nunca são armazenadas em texto simples. São submetidas a hash e salt com bcrypt, um algoritmo concebido para palavras-passe.

Sim. A sua equipa pode iniciar sessão com a conta Google (Google SSO).

Sim. Cada utilizador pode ativar a autenticação de dois fatores (2FA) com uma app de autenticação como o Google Authenticator ou o Microsoft Authenticator (palavras-passe de utilização única baseadas no tempo, TOTP), e são fornecidos códigos de recuperação. As tentativas de autenticação de dois fatores têm limite de frequência.

As sessões usam cookies seguros e HTTP-only e terminam automaticamente após um período de inatividade (tempo limite de sessão). Cada utilizador pode também terminar todas as suas outras sessões no browser.

Sim. As tentativas de início de sessão e de autenticação de dois fatores têm limite de frequência, para proteger contra ataques de força bruta e adivinhação de palavras-passe.

Sim. O acesso é controlado com funções e permissões (controlo de acessos baseado em funções, RBAC) em dois níveis:

• Funções da conta: Owner, Admin, Manager, Analyst e Support, cada uma com direitos diferentes sobre utilizadores, faturação, campanhas e dados.
• Permissões por campanha: pode dar a cada pessoa acesso a campanhas específicas e decidir o que pode fazer nelas, por exemplo design, escrever textos, gerir prémios e vencedores, ou apenas rever.

Pode ver o que os seus utilizadores fizeram no registo de atividade.

Sim. A nossa API REST só funciona através de HTTPS, usa tokens de acesso pessoais e tem limite de frequência. Os webhooks do Scratcher são assinados com um segredo partilhado (assinatura HMAC), para que possa verificar que vêm de nós.

Apenas os colaboradores que precisam de acesso para o seu trabalho, e apenas quando precisam (necessidade de conhecer). Nas definições da sua conta, decide se a nossa equipa de apoio pode aceder à sua conta para o ajudar.

O acesso segue o princípio do privilégio mínimo, usa contas de utilizador únicas e é revisto pelo menos uma vez por ano. Os colaboradores usam um gestor de palavras-passe, autenticação multifator sempre que possível e portáteis encriptados, e o acesso é revogado assim que alguém sai da empresa (offboarding).

As bases de dados e os servidores têm cópias de segurança automáticas todos os dias, e são guardados pelo menos sete dias de cópias. As cópias de segurança são encriptadas, armazenadas separadamente dos sistemas de produção num armazenamento AWS de elevada durabilidade (Amazon S3) e só podem ser lidas por administradores. Antes de qualquer trabalho de recuperação após um incidente, é feita primeiro uma cópia de segurança adicional. Os restauros são testados pelo menos uma vez por ano.

Temos planos de continuidade do negócio e de recuperação de desastres (BC/DR) para falhas na AWS, falhas da plataforma e ataques a campanhas. Os planos são revistos e testados todos os anos. Se uma falha durar mais de uma hora, todos os clientes são informados por e-mail. A nossa equipa de operações responde a indisponibilidades em 1 hora durante o horário de expediente e em 3 horas fora dele, com piquete 24 horas por dia.

O apoio está incluído em todas as subscrições. Os clientes Enterprise podem acordar connosco níveis de serviço específicos.

Seguimos um processo documentado de gestão de incidentes: os incidentes são comunicados ao nosso responsável pela segurança da informação, avaliados, contidos, analisados para encontrar a causa raiz (análise da causa raiz) e acompanhados com ações corretivas. Cada incidente é registado e revisto.

Sim. Se uma violação afetar os seus dados pessoais, notificamo-lo sem demora injustificada e no prazo de 24 horas, e ajudamo-lo com a sua própria notificação à autoridade de controlo no prazo de 72 horas (artigos 33.º e 34.º do RGPD).

Na nossa última revisão anual do sistema de gestão de segurança da informação não foi registada nenhuma violação da confidencialidade ou da integridade dos dados dos clientes.

Escreva para contact@scratcher.io com o máximo de detalhe possível. Seguimos uma política de divulgação de vulnerabilidades (divulgação responsável), investigamos cada comunicação e damos-lhe resposta.

Seguimos um ciclo de vida de desenvolvimento de software seguro (SDLC) documentado, baseado na ISO/IEC 27001:2022 (controlos 8.25–8.33). Cada funcionalidade tem um responsável pela segurança desde a ideia até à desativação, e os requisitos de segurança são definidos logo na fase de especificação e design.

• Segurança desde a conceção e por predefinição: a segurança é integrada desde o início, e as definições mais seguras são as predefinidas.
• Privilégio mínimo: pessoas, serviços e parceiros só obtêm o acesso de que precisam, e nada mais.
• Defesa em profundidade: várias camadas de proteção independentes, para que uma falha não exponha dados.
• Negação por predefinição: o acesso é bloqueado a menos que tenha sido explicitamente permitido.
• Zero trust: nunca confiar, verificar sempre. Cada pedido é autenticado e autorizado, quer venha de dentro ou de fora da rede.
• Falhar de forma segura e assumir a violação: os sistemas são concebidos para se manterem seguros se algo correr mal.
• Funcionalidade mínima: só são ativadas as funcionalidades e os serviços necessários.
• Desconfiar de dados externos: todos os dados de entrada são validados.

Todo o código é mantido em controlo de versões (Git), e cada alteração passa por um pull request com revisão de código por pares antes de ser integrada. Os testes automatizados unitários, de funcionalidades e de arquitetura correm em cada pull request, e os testes de arquitetura impedem que padrões de código inseguros sejam integrados. O linting e a refatoração automatizada correm em cada commit, e as alterações de design e técnicas são aprovadas pelo nosso CTO.

A plataforma assenta em frameworks consolidadas e com manutenção ativa (Laravel e Vue), com proteção integrada contra vulnerabilidades comuns do OWASP Top 10, como injeção de SQL, cross-site scripting (XSS) e cross-site request forgery (CSRF). Todos os dados de entrada são validados no servidor, e os endpoints sensíveis têm limite de frequência. Os pedidos suspeitos são registados e revistos.

Sim. Desenvolvimento, testes (staging) e produção são ambientes separados, com acessos separados. As alterações são testadas em staging antes de chegarem à produção, e a nossa política é não copiar dados de produção para ambientes de desenvolvimento ou de testes.

As alterações são implementadas através de um pipeline CI/CD automatizado que cria uma nova imagem de contentor com versão para cada lançamento. As alterações à base de dados correm como um passo controlado da implementação e, como cada lançamento é uma imagem separada, podemos reverter rapidamente para a versão anterior se necessário. Nenhuma pessoa sozinha pode alterar a produção sem revisão e aprovação (segregação de funções).

O nosso código-fonte é mantido em repositórios privados, com controlo de acessos e histórico de versões completo. Os segredos, como palavras-passe e chaves de API, nunca são guardados no código; ficam no AWS Secrets Manager e são injetados em tempo de execução.

Só usamos bibliotecas open source conhecidas e com manutenção ativa, de fontes reputadas. As novas bibliotecas têm de ser aprovadas antes de serem usadas, as versões são fixadas (lock files) e as dependências são atualizadas continuamente (segurança da cadeia de fornecimento de software).

Os nossos programadores fazem uma revisão de segurança todas as semanas (gestão de vulnerabilidades). As vulnerabilidades encontradas pela nossa equipa, pelas nossas ferramentas ou que nos são comunicadas são avaliadas, priorizadas e corrigidas, e tratadas através do nosso processo de incidentes se necessário.

Sim. Os nossos programadores seguem diretrizes de programação segura e recebem formação de sensibilização para a segurança quando começam e de forma contínua.

Fazemos uma avaliação de riscos com base na probabilidade e no impacto. Os riscos são revistos todos os meses, e cada risco é reavaliado pelo menos uma vez por ano (gestão de riscos).

O nosso CTO é o responsável pela segurança da informação (ISM), e a gestão aprova as nossas políticas de segurança da informação. As políticas são revistas todos os anos.

O nosso sistema de gestão de segurança da informação (SGSI) inclui políticas aprovadas para, entre outros:

• Segurança da informação e utilização aceitável
• Classificação e transferência de informação
• Controlo de acessos e criptografia (incluindo gestão de chaves)
• Relações com fornecedores e serviços cloud
• Proteção de dados pessoais (PII) e registos
• Teletrabalho, secretária limpa e ecrã limpo, dispositivos terminais e suportes amovíveis
• Registo e monitorização, cópias de segurança e conservação de dados
• Gestão de vulnerabilidades e divulgação de vulnerabilidades
• Utilização de IA

As políticas são aprovadas pela gestão, comunicadas a todos os colaboradores e revistas todos os anos.

Sim. Os novos colaboradores passam por uma verificação de antecedentes antes de começarem, assinam acordos de confidencialidade (NDA) e recebem formação de sensibilização para a segurança quando começam e de forma contínua.

O Scratcher é uma empresa remote-first. A nossa política de teletrabalho exige escritórios em casa seguros, bloqueio de ecrã, dispositivos encriptados, Wi-Fi protegido (WPA2/WPA3) e VPN em redes públicas.

Sim. A informação é classificada por confidencialidade, integridade e disponibilidade (CIA) e tratada de acordo com o seu nível.

Os fornecedores são avaliados quanto à confidencialidade, integridade e disponibilidade antes de os utilizarmos (gestão de riscos de fornecedores). Os requisitos de segurança fazem parte dos nossos contratos, e os fornecedores são revistos regularmente.

As nossas funcionalidades de IA, incluindo o Rex, o assistente de IA, usam modelos de linguagem de grande dimensão (LLM) do Google Gemini e modelos de imagem da fal.ai. Os fornecedores são avaliados no nosso processo de fornecedores, e a nossa política de utilização de IA define como a IA é usada.

Sim. A nossa política de IA exige supervisão humana (human in the loop) nas decisões importantes. As alterações feitas com IA acontecem no editor, e é a sua equipa que decide quando uma campanha é publicada. O Rex e as outras funcionalidades de IA só fazem alterações quando alguém da sua equipa lhes pede.

Por defeito, as campanhas só usam cookies e armazenamento funcionais: cookies que equilibram o tráfego entre os nossos servidores (cookies do balanceador de carga), armazenamento local no browser, por exemplo para lembrar que alguém já jogou, e, nos pop-ups incorporados no seu website, cookies que controlam a frequência com que o pop-up é apresentado. Se adicionar o seu próprio rastreamento, por exemplo o Google Tag Manager ou o Meta Pixel, este só é carregado depois de o participante dar o seu consentimento no banner de cookies da campanha. Se a proteção contra bots (Cloudflare Turnstile) estiver ativa, a Cloudflare também trata dados técnicos, como o endereço IP e sinais do browser.

Sim. Escreve os seus próprios textos de consentimento e termos, escolhe que campos são obrigatórios e pode usar o duplo opt-in para os registos na newsletter.

Os e-mails transacionais, como os e-mails de prémios, são enviados através do nosso fornecedor de envio de e-mails. Pode enviá-los a partir do seu próprio domínio, para que os participantes reconheçam o remetente.

Sim. Nos planos Professional e Enterprise, as campanhas podem correr no seu próprio endereço web (domínio personalizado), e os e-mails aos participantes podem ser enviados a partir do seu próprio domínio.

• Certificado ISO/IEC 27001:2022: descarregue-o aqui
• Declaração de Aplicabilidade (SoA), mediante pedido
• Acordo de tratamento de dados (DPA), incluindo a lista de subcontratantes ulteriores
• Respostas ao seu questionário de segurança ou avaliação de fornecedores

Sim. Envie-nos o seu questionário de segurança ou avaliação de fornecedores e nós preenchemo-lo. Muitas perguntas já estão respondidas nesta página.

Escreva para contact@scratcher.io ou marque uma reunião. Scratcher ApS, CVR 38552864.