Medidas técnicas e organizacionais

1. Escopo e estrutura

• Empresa: CreatorFlow Labs S.L., Madri, Espanha. Uma equipe pequena e totalmente remota. Não operamos servidores próprios, salas de servidores nem uma rede corporativa de escritório, e nenhum dado pessoal é armazenado nas instalações da empresa.
• Hospedagem: Todo o serviço é executado na Amazon Web Services (AWS), na União Europeia, região eu-west-1 (Irlanda). A aplicação, os bancos de dados, os caches, o armazenamento de objetos e os backups ficam todos nessa região.
• Dados tratados: Nomes de usuário do Instagram e identificadores públicos de perfil, o texto dos comentários e das mensagens diretas que acionam automações ou que resultam delas, endereços de e-mail coletados por meio de automações, eventos de clique em links e dados de conta e de cobrança dos clientes. Não está previsto o tratamento de categorias especiais de dados pessoais nos termos do Artigo 9 do GDPR.
• Responsabilidade compartilhada: A segurança física e ambiental dos centros de dados é fornecida pela AWS. Tudo o que está do sistema operacional para cima é operado pela CreatorFlow. Cada seção abaixo indica de que lado fica cada controle.

2. Controle de acesso físico (Zutrittskontrolle)

• Instalações da empresa: Não se aplica. Nenhum servidor, equipamento de rede ou mídia de armazenamento com dados pessoais fica nas instalações da CreatorFlow. Por isso, salas de servidores com tranca, racks de servidores, gestão de chaves, registros de visitantes, sistemas de alarme e regras para a equipe de limpeza ou de manutenção não se aplicam a nós.
• Centros de dados (AWS): Controle herdado da AWS. Os centros de dados da AWS implementam segurança de perímetro, controle de acesso por crachá e por biometria, acompanhamento de visitantes, CFTV e registro de acessos. Esses controles são auditados com base na ISO 27001 e no SOC 2, e os relatórios ficam disponíveis para os clientes mediante solicitação, por nosso intermédio ou diretamente pelo AWS Artifact.
• Energia de emergência e proteção contra incêndio: Controle herdado da AWS. Os centros de dados contam com alimentação elétrica redundante, fontes de alimentação ininterrupta (nobreaks) e geradores, além de detecção e supressão automáticas de incêndio. Esses controles estão cobertos pelos mesmos relatórios de auditoria.

3. Controle de acesso aos sistemas (Zugangskontrolle)

• Autenticação dos clientes: Os clientes entram com endereço de e-mail e senha ou pelo login com o Google. O formulário de cadastro exige senhas com pelo menos 8 caracteres. Atualmente, esse mínimo é aplicado apenas no navegador, e não no servidor. As senhas são armazenadas como hashes com salt, nunca em texto puro. A migração para um algoritmo moderno de hash de senhas (bcrypt ou argon2) está registrada como item em aberto. As novas contas são criadas após uma verificação com reCAPTCHA. Atualmente, a confirmação do e-mail antes do primeiro uso não é exigida.
• Sessões: As sessões são armazenadas no servidor e referenciadas por um cookie assinado com o atributo HttpOnly, restrito ao nosso domínio, que expira após 7 dias. O atributo Secure ainda não está definido nesse cookie. A inclusão desse atributo está prevista no nosso plano de melhorias de segurança. A troca de senha encerra a sessão atual e revoga os tokens da opção "lembrar de mim", mas atualmente não encerra outras sessões ativas em outros dispositivos. Uma alteração do e-mail da conta iniciada por um administrador invalida todas as sessões desse usuário.
• Bloqueio de conta: Ainda não existe bloqueio automático da conta após repetidas tentativas de login malsucedidas. Proteções adicionais contra abuso de login estão previstas no nosso plano de melhorias de segurança. Os links de redefinição de senha são enviados somente para o endereço de e-mail cadastrado na conta.
• Acesso ao Instagram: Nunca pedimos nem armazenamos senhas do Instagram. As contas do Instagram são conectadas pelo fluxo oficial OAuth 2.0 da Meta, e os tokens de acesso gerados são criptografados no nível da aplicação (AES-256) antes de serem armazenados.
• Acesso da equipe e à infraestrutura: O acesso ao console da AWS, aos servidores e às funções administrativas é limitado a membros da equipe identificados nominalmente, com credenciais individuais. O acesso aos servidores usa SSH com chaves individuais. Dentro da aplicação, as funções administrativas são restritas a uma única conta de administrador incluída em uma lista de permissões e estão sujeitas a limites de taxa.

4. Controle de acesso aos dados (Zugriffskontrolle)

• Delimitação por cliente (tenant): Cada registro de cliente (automações, contatos, atividade, análises) é armazenado com o identificador do workspace ao qual pertence, e a aplicação só mostra a cada usuário os workspaces dos quais ele é membro. As verificações no servidor de que o usuário é membro do workspace já existem em parte da API e estão sendo estendidas a todos os endpoints vinculados a um workspace. Até que isso esteja concluído, não descrevemos a separação entre clientes (tenants) como totalmente aplicada na camada da API.
• Necessidade de conhecer: Somente os membros da equipe identificados nominalmente que operam o serviço podem acessar os dados de produção, e apenas para suporte, tratamento de incidentes e manutenção.
• Proteção de credenciais: Os tokens de acesso do Instagram são criptografados em repouso e excluídos das leituras padrão do banco de dados. Por isso, eles não são retornados em consultas ou exportações comuns.
• Dados de pagamento: Os dados de cartão são tratados inteiramente pela Stripe. A CreatorFlow nunca recebe nem armazena números completos de cartão.

5. Controle de transferência (Weitergabekontrolle)

• Criptografia em trânsito: As conexões entre os usuários e o serviço, e entre o serviço e a Meta, a Stripe e os nossos provedores de e-mail e de logs, são criptografadas com TLS.
• Suboperadores: Os dados pessoais são compartilhados somente com os suboperadores listados na Seção 5 do DPA, mediante termos de tratamento de dados. Os dados são hospedados e registrados em logs na União Europeia. As transferências para suboperadores fora da UE se baseiam nas Cláusulas Contratuais Padrão ou no Marco de Privacidade de Dados UE-EUA, conforme previsto no DPA.
• Exportações: Os clientes podem exportar os contatos coletados em um arquivo CSV. Depois de exportados, esses dados ficam sob o controle e a responsabilidade do cliente.
• Mídias removíveis: Não se aplica. Nenhuma mídia removível de armazenamento (pen drives, discos externos, fitas de backup) é usada para dados pessoais. Por isso, não é necessário um inventário de mídias de armazenamento.

6. Logs e controle de entrada de dados (Eingabekontrolle)

• Logs da aplicação: A aplicação grava logs estruturados de cada webhook processado, execução de automação, envio de mensagem e requisição à API. Cada entrada de log contém um identificador de correlação, para que um único evento possa ser rastreado de ponta a ponta.
• Logs de acesso: A camada HTTP registra uma linha de log de acesso por requisição.
• Armazenamento central e retenção: Todos os logs são enviados para uma plataforma de logs hospedada na UE (New Relic, região de dados da UE) e mantidos por 30 dias. Os usuários da aplicação não podem editar os logs.
• Log de auditoria administrativa: As ações que a equipe da CreatorFlow realiza nas contas dos clientes pela interface de administração, incluindo exclusões de conta e alterações do e-mail da conta, são gravadas em um log de auditoria, com o administrador que executou a ação, a data e a hora e o resultado.
• Falhas de login: Atualmente, as tentativas de login malsucedidas dos clientes não são gravadas em um log de segurança específico. Isso está previsto no nosso plano de melhorias de segurança.

7. Controle de separação (Trennungskontrolle)

• Separação entre clientes: Os dados dos clientes são separados de forma lógica pelo identificador do workspace, na camada de dados (multi-tenancy). Pela aplicação, os clientes não podem ver dados que pertencem a outros workspaces.
• Separação funcional: Os dados de conta e de autenticação ficam em um banco de dados separado dos dados da aplicação (automações, contatos, análises).
• Ambientes: Os testes automatizados são executados em um banco de dados isolado em memória e nunca acessam dados de produção. O desenvolvimento do dia a dia usa bancos de dados locais. Membros da equipe identificados nominalmente também consultam os dados de produção diretamente para suporte, depuração e investigação de incidentes. Há um único ambiente de produção e nenhum ambiente de homologação separado. As mudanças são verificadas localmente e pelo conjunto de testes automatizados antes de cada nova versão, e podem ser revertidas.
• Separação física: Não se aplica além do limite da conta da AWS. Todas as cargas de trabalho são executadas em uma conta dedicada da AWS que pertence à CreatorFlow.

8. Disponibilidade e resiliência (Verfügbarkeitskontrolle)

• Infraestrutura: O serviço é executado em uma única região da AWS (eu-west-1), dentro de um grupo de escalonamento automático que substitui automaticamente um host de computação com falha. Os dados ficam em volumes de armazenamento persistentes, que se mantêm quando o host é substituído.
• Snapshots: Os snapshots dos volumes são feitos antes de mudanças na infraestrutura e mantidos na mesma região da AWS. Os snapshots que podem conter dados pessoais são excluídos no ciclo de rotação.
• Resiliência dos webhooks: A Meta reenvia os webhooks do Instagram por um período após uma indisponibilidade temporária, e a Stripe tenta reenviar os webhooks de cobrança por vários dias. Assim, interrupções curtas não causam perda de eventos.
• Monitoramento: A saúde da aplicação, a vazão e as taxas de erro são monitoradas pela nossa plataforma de logs. As implantações são acompanhadas e comparadas com uma linha de base medida antes da implantação.
• Limites: Não há failover entre várias regiões nem um objetivo de tempo de recuperação ou de ponto de recuperação formalmente assumido. O serviço não se destina a casos de uso que exijam disponibilidade contínua garantida.
• Resiliência dos centros de dados: Controle herdado da AWS (energia, refrigeração e rede redundantes, supressão de incêndio). Veja a Seção 2.

9. Gestão de patches e de mudanças

• Processo de mudança: Mudanças não triviais começam com uma especificação escrita e um plano de implementação. O código é coberto por um conjunto de testes automatizados executado em bancos de dados de teste isolados, e cada versão é compilada e passa por verificação de tipos antes da implantação.
• Versões: A aplicação é implantada como imagens de contêiner versionadas. Uma imagem anterior pode ser implantada novamente para reverter uma versão. Os comportamentos de maior risco são lançados com feature flags, que podem ser desativadas sem uma nova implantação e ativadas primeiro para uma parte dos workspaces.
• Verificação: As principais métricas são registradas antes de uma implantação e comparadas depois, para detectar regressões cedo.
• Dependências e sistema operacional: As dependências de terceiros e as imagens base dos contêineres são atualizadas pelo processo normal de publicação de versões, e o sistema operacional do host é renovado quando o host de computação é substituído. Não há um calendário fixo para a aplicação de patches. As atualizações relevantes para a segurança são priorizadas conforme a gravidade.
• Registro de segurança: Os achados das nossas próprias auditorias de segurança são acompanhados em um registro interno, com uma pontuação de gravidade, e são corrigidos por ordem de risco.

10. Tratamento de incidentes e de violações de dados

• Contato: Questões de segurança podem ser relatadas pelo e-mail security@creatorflow.so. Confirmamos o recebimento dos relatos e os investigamos. Não mantemos um programa pago de recompensa por falhas (bug bounty).
• Tratamento: Os incidentes são investigados com base nos logs centrais, contidos, documentados com uma linha do tempo e a causa raiz, e corrigidos. As lições aprendidas alimentam o registro de segurança.
• Notificação ao cliente: Se uma violação de dados pessoais afetar os dados de um cliente, notificamos esse cliente sem demora injustificada após tomarmos conhecimento dela, com as informações descritas na Seção 8 do DPA, para que o cliente possa cumprir as próprias obrigações previstas nos Artigos 33 e 34 do GDPR.

11. Medidas organizacionais

• Confidencialidade: As pessoas da equipe com acesso a dados pessoais estão sujeitas a obrigações de confidencialidade contratuais ou legais.
• Ciclo de vida dos acessos: O acesso à infraestrutura e às funções administrativas é concedido individualmente e removido quando a pessoa deixa a empresa ou muda de função.
• Dispositivos e trabalho remoto: A equipe trabalha de forma remota. Os dados de produção só são acessados com credenciais individuais, por conexões criptografadas (TLS, SSH), e, como prática, não são armazenados em dispositivos locais. Não há rede corporativa de escritório, por isso não se usa VPN. Cada conexão administrativa é autenticada e criptografada individualmente.
• Mesa limpa e registros em papel: Não se aplica no sentido clássico: os dados pessoais tratados pelo serviço existem apenas em formato eletrônico, dentro da AWS, e não são mantidos registros em papel com dados de clientes.
• Terceiros e manutenção: Nenhuma equipe externa de manutenção, limpeza ou suporte tem acesso aos sistemas de produção. Não é usada manutenção remota por terceiros. A infraestrutura é operada somente pela equipe da CreatorFlow.
• Proteção de endpoints nos servidores: As cargas de trabalho de produção são executadas como contêineres Linux, com usuários sem privilégios de root, em um host que expõe publicamente apenas HTTPS. As estações de trabalho dos funcionários não fazem parte da rede de produção.

12. Exclusão e retenção

• Exclusão de conta: Mediante solicitação, a conta é excluída junto com todos os seus workspaces, automações, contatos, registros de atividade, estados pendentes de automação e conexões com o Instagram, e o contato correspondente para e-mails de marketing é removido. Cada exclusão é registrada em um log de auditoria.
• Exclusão de contatos: O cliente pode excluir contatos individuais (endereços de e-mail coletados), o que ajuda a atender às solicitações de exclusão dos titulares dos dados.
• Expiração automática: Os registros temporários usados enquanto uma automação espera uma ação do usuário (por exemplo, responder com o e-mail ou seguir a conta) deixam de poder ser usados em 24 a 48 horas, conforme o tipo de automação, e são excluídos fisicamente do banco de dados em até 48 horas.
• Logs: Os logs da aplicação e os logs de acesso são mantidos por 30 dias.
• Snapshots: Veja a Seção 8. Os snapshots só são restaurados para recuperar o serviço após uma falha do sistema. Os dados pessoais que tenham sido excluídos antes dessa restauração teriam de ser excluídos novamente depois dela. Não há reconciliação automática para isso. Por isso, refazemos as exclusões manualmente, mediante solicitação.

13. Revisão destas medidas