Medidas de Segurança
Medidas de Segurança da ProcessMind
Data de vigência: 14 de setembro de 2026
Este documento descreve as medidas técnicas e organizacionais («TOMs») mantidas pela ProcessMind B.V. para proteger a confidencialidade, a integridade e a disponibilidade dos Dados do Cliente. A ProcessMind adota uma abordagem de defesa em profundidade, na qual várias camadas de segurança independentes protegem os Dados do Cliente em todos os níveis — da rede e infraestrutura à identidade, autorização, isolamento de dados, criptografia, monitoramento e desenvolvimento de software. Essas medidas complementam o Aditivo de Tratamento de Dados, a Política de Privacidade e a Política de Hospedagem SaaS. A ProcessMind revisa e atualiza essas medidas pelo menos uma vez por ano.
Os Dados do Cliente nunca são vendidos, compartilhados com terceiros nem utilizados por terceiros para fins próprios.
1. Segurança da Infraestrutura
1.1 Plataforma de nuvem. A ProcessMind é hospedada exclusivamente na Amazon Web Services (AWS), na UE (Frankfurt, Alemanha, eu-central-1). A AWS mantém certificações ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3 e PCI DSS. Consulte Programas de Conformidade da AWS para ver a lista completa.
1.2 Arquitetura sem Servidor. A lógica da aplicação da ProcessMind é executada no AWS Lambda e em serviços gerenciados pela AWS. A ProcessMind não opera servidores de aplicação de longa duração gerenciados pelo cliente, o que elimina uma grande categoria de tarefas de aplicação de patches no sistema operacional e de reforço da segurança dos servidores.
1.3 Limites de Rede. A ProcessMind mantém uma VPC da AWS para controles de banco de dados e de rede. O Aurora PostgreSQL é executado em sub-redes privadas sem saída para a internet, não é acessível publicamente e os logs de fluxo da VPC estão habilitados. Por padrão, a ProcessMind não coloca funções Lambda da aplicação dentro da VPC. As funções Lambda acessam o Aurora por meio da AWS RDS Data API sobre TLS, usando autenticação do IAM e do Secrets Manager.
1.4 Entrega de Conteúdo e Controles de Borda. O site voltado aos clientes, o SPA do frontend e o tráfego de recursos públicos são servidos pelo Amazon CloudFront. Todas as distribuições do CloudFront impõem uma política TLS mínima de TLS 1.2 (2021). As distribuições do site e do SPA do frontend também adicionam cabeçalhos de resposta de segurança, incluindo HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), frame-ancestors 'none', X-Frame-Options: DENY, X-Content-Type-Options, política de referenciador e política de permissões. A distribuição de recursos públicos usa o CloudFront Origin Access Control para manter privado o bucket de origem. O tráfego da API voltado aos clientes é tratado separadamente pelo Amazon API Gateway: o tráfego de solicitação/resposta HTTPS é servido por uma HTTP API em um subdomínio de API dedicado, e as conexões de clientes em tempo real são servidas por uma API WebSocket separada do API Gateway, em um subdomínio WebSocket dedicado.
1.5 Segregação de Ambientes. Os ambientes de produção e desenvolvimento usam contas AWS, bancos de dados e pilhas de infraestrutura separados. As credenciais dos desenvolvedores não dão acesso aos Dados do Cliente em produção.
2. Criptografia de Dados
2.1 Criptografia em Trânsito. Todos os dados transmitidos entre os clientes e os serviços da ProcessMind são criptografados usando TLS 1.2 ou superior. Os endpoints voltados aos clientes são disponibilizados por HTTPS. Os buckets do S3, tópicos do SNS e filas do SQS criados diretamente pela ProcessMind impõem acesso somente por SSL. O acesso ao banco de dados por meio da RDS Data API e as demais chamadas a serviços da AWS usam HTTPS/TLS.
2.2 Criptografia em Repouso. O Aurora PostgreSQL é criptografado em repouso usando chaves AWS KMS gerenciadas pelo cliente, com rotação automática de chaves. Os buckets do S3 de dados do cliente e operacionais criados diretamente pela ProcessMind, incluindo buckets de uploads, recursos e logs de acesso, usam chaves KMS gerenciadas pelo cliente. Os grupos de logs do CloudWatch, tópicos do SNS e filas do SQS criados diretamente pela ProcessMind também usam chaves KMS gerenciadas pelo cliente. Os buckets de origem do site e do frontend gerenciados pelo SST usam criptografia do lado do servidor do S3 gerenciada pela AWS (SSE-S3 / AES-256), em vez de chaves KMS gerenciadas pelo cliente.
2.3 Gerenciamento de Chaves e Segredos. As chaves de criptografia do banco de dados são gerenciadas centralmente por meio do AWS KMS, e o acesso às chaves é regido por políticas do IAM que seguem o princípio do menor privilégio. As credenciais do banco de dados são armazenadas no AWS Secrets Manager. O segredo mestre do Aurora e o segredo restrito do usuário da aplicação são rotacionados automaticamente a cada trinta (30) dias. Chaves e segredos de produção nunca são armazenados no código-fonte; as credenciais exclusivas de desenvolvimento são isoladas da produção. Alguns recursos de suporte gerenciados pela AWS/CDK/SST continuam usando criptografia gerenciada pela AWS quando o serviço ou a estrutura não oferece configuração de chaves gerenciadas pelo cliente.
3. Isolamento e Residência dos Dados
3.1 Isolamento de Locatários. Cada locatário cliente recebe uma instância de banco de dados dedicada e isolada. Os Dados do Cliente nunca são misturados aos dados de outros clientes no nível do banco de dados. Metadados compartilhados (por exemplo, registros de contas, faturamento e mapeamentos de usuários para locatários) são armazenados em um banco de dados separado para vários locatários, com controles de acesso rigorosos. As tabelas compartilhadas com escopo de locatário e de organização também são protegidas por políticas de segurança em nível de linha (RLS) do PostgreSQL, aplicadas por meio de contexto de banco de dados com escopo por solicitação.
3.2 Residência dos Dados. Todos os Dados do Cliente, incluindo bancos de dados, uploads de arquivos, backups e resultados de consultas, são armazenados exclusivamente na UE (Frankfurt, Alemanha). Quando um subprocessador localizado fora do EEE é contratado para uma atividade específica de tratamento (por exemplo, tratamento por modelo de IA ou processamento de pagamentos), a transferência é coberta por um mecanismo de transferência adequado, conforme descrito no Adendo de Tratamento de Dados, e o subprocessador e o local do tratamento constam da Lista de Subprocessadores.
3.3 Retenção e exclusão de dados. Os prazos de retenção e exclusão estão estabelecidos na Seção 6 do Aditivo de Tratamento de Dados. Os clientes podem excluir seus dados a qualquer momento por meio do aplicativo ou entrando em contato com a ProcessMind. As cópias de backup são removidas quando os respectivos períodos de retenção de backup expiram (Seção 7.1).
4. Gerenciamento de Identidade e Acesso
4.1 Autenticação. A ProcessMind oferece suporte a Single Sign-On (SSO) por meio do Microsoft Entra ID (Azure AD), Google OAuth 2.0/OIDC e LinkedIn OAuth 2.0/OIDC. A ProcessMind atua como parte confiável e não armazena senhas de usuários. A autenticação multifator é imposta pelo provedor de identidade — por exemplo, quando uma organização conecta o Microsoft Entra ID (Azure AD), aplicam-se as próprias políticas de MFA e de acesso dessa organização.
4.2 Gerenciamento de Sessões. As sessões do navegador usam JSON Web Tokens (JWT) assinados, transmitidos por cookies seguros e HttpOnly com os sinalizadores SameSite e Secure. As assinaturas dos tokens são validadas em cada solicitação autenticada.
4.3 Modelo de Autorização. A ProcessMind não depende de autorizadores nativos do API Gateway para suas APIs principais da aplicação. A autorização é aplicada em wrappers compartilhados de manipuladores Lambda, que validam o estado da sessão e o escopo do locatário antes da execução da lógica de negócios. As rotas públicas são explicitamente incluídas em uma lista de permissões para fluxos não autenticados, webhooks, ingestão de eventos e preflight de CORS. Os endpoints de API externos usam manipuladores de autenticação dedicados. O acesso aos Dados do Cliente é limitado ao contexto do locatário ou da organização autenticados.
4.4 Menor Privilégio. Os sistemas internos seguem o princípio do menor privilégio. As funções do IAM são limitadas aos recursos mínimos necessários quando a estrutura permite um escopo preciso. Algumas funções geradas pelo SST/CDK usam políticas gerenciadas ou em linha mais amplas para vinculações e operação em tempo de execução; esses casos são revisados, limitados ao escopo dos recursos quando possível e registrados como exceções explícitas.
4.5 Controles de Acesso dos Funcionários. O acesso dos funcionários aos sistemas internos é gerenciado por meio do Active Directory com SSO e MFA obrigatória. O controle de acesso baseado em funções (RBAC) garante que o acesso aos Dados do Cliente seja limitado ao pessoal autorizado que tenha necessidade de conhecê-los. Os direitos de acesso são revisados periodicamente.
5. Registro de Logs, Monitoramento e Auditoria
5.1 Registro centralizado. O registro de acesso à API HTTP e o registro de acesso ao WebSocket estão habilitados com campos JSON estruturados e são gravados no Amazon CloudWatch Logs, com retenção de um (1) ano. Esses grupos de logs de acesso são criptografados com uma chave AWS KMS gerenciada pelo cliente. Os logs da aplicação são centralizados em grupos de logs do Amazon CloudWatch criptografados com uma chave AWS KMS gerenciada pelo cliente e retidos por dez (10) anos. Grupos separados de logs de auditoria e telemetria também são criptografados com uma chave AWS KMS gerenciada pelo cliente e retidos por dez (10) anos. O grupo de exportação de logs do mecanismo Aurora PostgreSQL é retido por uma (1) semana.
5.2 O que é registrado e o que não é. A ProcessMind registra eventos de acesso à API HTTP e ao WebSocket — horário da solicitação, identificadores da solicitação, rota ou caminho, status da resposta e latência. Os logs de acesso não incluem o endereço IP de origem nem o agente do usuário de quem faz a chamada. A ProcessMind também registra eventos de autenticação, caminhos de falha assíncronos e atividades de suporte da aplicação Lambda em grupos de logs centralizados do CloudWatch. Os logs de fluxo da VPC estão habilitados. Atualmente, a ProcessMind não habilita o registro de acesso padrão do CloudFront nos recursos de distribuição do site, do SPA frontend ou dos recursos públicos.
5.3 Monitoramento e alertas. Os alarmes e painéis do CloudWatch monitoram a integridade do sistema, as filas de mensagens não entregues e as falhas relevantes para a segurança. As falhas de processamento assíncrono são encaminhadas para filas criptografadas de mensagens não entregues (retenção de quatorze (14) dias; dois (2) dias para as filas de miniaturas e de índices de pesquisa), e os alarmes de DLQ acionam notificações do SNS para investigação. Além disso, a ProcessMind usa o Sentry para rastreamento de erros de frontend em tempo real, monitoramento de desempenho e reprodução de sessões. As reproduções de sessões são gravadas somente para sessões em que ocorre um erro, e textos, campos de formulário e mídias são mascarados ou bloqueados nas reproduções. Os dados do Sentry são ingeridos na UE (Frankfurt) e limitam-se aos Dados de Uso da ProcessMind (erros do navegador, rastreamentos de desempenho, metadados do dispositivo e gravações mascaradas de reproduções). O Sentry consta na lista de subprocessadores.
5.4 Proteção dos Logs. Os logs são armazenados em grupos dedicados do CloudWatch com acesso controlado e criptografia em repouso. Os logs de produção e desenvolvimento são separados por limites de ambiente e de conta.
6. Validação Automatizada de Controles e Gerenciamento de Vulnerabilidades
6.1 O que a ProcessMind faz. A ProcessMind executa cdk-nag como parte da síntese da infraestrutura e do fluxo de trabalho de implantação, usando vários conjuntos de regras do setor (incluindo AWS Solutions, NIST 800-53 e PCI DSS). Relatórios por pilha são gerados e revisados como parte do gerenciamento de alterações da infraestrutura. As constatações são classificadas como corrigidas, risco aceito ou melhoria planejada.
6.2 Como as Exceções são Gerenciadas. As supressões são registradas em um repositório central quando a estrutura permite, limitadas às pilhas afetadas e exigem justificativa por escrito; quando uma pilha contém uma supressão em linha, ela é documentada junto com essa pilha. Quando uma constatação é corrigida, a supressão correspondente é atualizada ou removida. A ProcessMind não trata a supressão como uma dispensa geral de revisão.
6.3 O que a ProcessMind não faz atualmente. A ProcessMind acompanha e revisa exceções substanciais aos controles de infraestrutura. As principais são:
- as Lambdas do aplicativo não são colocadas dentro da VPC por padrão; elas acessam o Aurora por meio da RDS Data API usando TLS, com autenticação por IAM e Secrets Manager
- nenhuma parte do serviço é protegida pelo AWS WAF: o AWS WAF não oferece suporte a APIs HTTP do API Gateway, e os demais pontos de entrada também não são protegidos pelo WAF (as conexões WebSocket usam tokens HMAC de curta duração; as restrições geográficas relacionadas a pagamentos são aplicadas no sistema de pagamentos); as distribuições estáticas também não têm registro de acesso padrão do CloudFront
- a recuperação do banco de dados depende dos backups automatizados do Aurora e da recuperação para um ponto no tempo, em vez de um plano separado do AWS Backup ou do Aurora Enhanced Monitoring
- não há replicação do S3 entre regiões nem S3 Object Lock para buckets mutáveis
- alguns recursos de suporte gerenciados por AWS/CDK/SST usam criptografia gerenciada pela AWS ou políticas IAM geradas mais abrangentes quando o serviço não oferece uma alternativa controlada pelo cliente
O registro completo de supressões é mantido junto com o código da infraestrutura e está disponível mediante solicitação. O uso de cdk-nag conjuntos de regras é uma validação de controles de engenharia, não uma certificação externa, opinião de auditoria ou atestado jurídico de conformidade com HIPAA, NIST ou PCI DSS.
6.4 Gerenciamento de dependências. As dependências de software são monitoradas continuamente quanto a vulnerabilidades conhecidas. As vulnerabilidades críticas e de alta gravidade são corrigidas com uma meta de sete (7) dias. As dependências são atualizadas em ciclos regulares.
6.5 Ciclo de vida de desenvolvimento seguro de software (SDLC). A ProcessMind adota uma abordagem de defesa em profundidade para o desenvolvimento de software. Toda alteração na produção deve passar por várias camadas independentes de validação automatizada antes da implantação:
- Análise estática e segurança de tipos: O modo estrito do TypeScript e o ESLint impõem a correção de tipos, a segurança contra valores nulos e padrões de codificação relevantes para a segurança no momento da compilação.
- Revisão de código assistida por IA: A análise assistida por IA oferece uma perspectiva adicional de revisão das solicitações de pull para identificar riscos de segurança, erros lógicos e desvios de convenções, complementando os testes automatizados.
- Testes unitários e de integração: um conjunto abrangente de testes Vitest valida a lógica de negócios, os padrões de acesso a dados, o comportamento da API e o tratamento de erros em relação a recursos AWS ativos no ambiente de desenvolvimento.
- Testes de ponta a ponta: testes de navegador baseados em Playwright verificam fluxos de trabalho críticos do usuário, incluindo autenticação, carregamento de dados, modelagem de processos, simulação e isolamento entre locatários.
- Verificação de conformidade da infraestrutura:
cdk-nagvalida código de infraestrutura como código em relação a várias estruturas de conformidade a cada alteração. - Verificação de vulnerabilidades de dependências: auditorias automatizadas de dependências impedem que vulnerabilidades conhecidas críticas e de alta gravidade cheguem à produção.
A revisão humana concentra-se na arquitetura, nos limites de segurança e nas decisões de projeto, em vez da inspeção do código linha por linha. Quando houver alterações estruturais, sensíveis à segurança ou de infraestrutura, será necessária aprovação humana expressa, além da validação automatizada.
Todas as camadas de validação são aplicadas por meio de CI como verificações obrigatórias para mesclagem de alterações no aplicativo e na infraestrutura para a ramificação principal. O conteúdo do site e as versões de ativos estáticos seguem um processo de lançamento separado e documentado, com verificações no momento da implantação — incluindo uma verificação automatizada de que os documentos legais estão atualizados — em vez da verificação de CI do aplicativo. Correções emergenciais em produção podem ignorar a verificação de CI, mas devem ser seguidas por uma execução completa do pipeline e uma análise pós-incidente no prazo de vinte e quatro (24) horas.
7. Backup e recuperação de desastres
7.1 Backups automatizados. O Amazon Aurora realiza backups contínuos e automatizados com um período de retenção de sete (7) dias. Os backups são criptografados usando as mesmas chaves KMS gerenciadas pelo cliente que os bancos de dados de origem.
7.2 Recuperação pontual. O Aurora oferece suporte à recuperação pontual para qualquer segundo dentro do período de retenção dos backups, permitindo a restauração rápida em caso de corrupção de dados ou exclusão acidental.
7.3 Durabilidade e controle de versões do S3. Os carregamentos de arquivos e os artefatos operacionais são armazenados no Amazon S3, que oferece durabilidade de 99,999999999% (11 noves). O controle de versões está habilitado no bucket de carregamentos e nos buckets de recursos para permitir recuperação e reversões. Os buckets de implantação do site e do frontend contêm artefatos de compilação reproduzíveis e não são tratados como um sistema de backup. Atualmente, a ProcessMind não habilita a replicação do S3 entre regiões.
7.4 Continuidade de negócios. Os procedimentos de recuperação de desastres estão documentados e são testados periodicamente. Um resumo está disponível no documento Recuperação de Desastres, Continuidade de Negócios e Resposta a Incidentes. A arquitetura utiliza serviços gerenciados da AWS na região eu-central-1, operados pela AWS em várias zonas de disponibilidade; atualmente, o cluster Aurora executa uma única instância de gravação, portanto, a recuperação do banco de dados depende de backups automatizados e da recuperação para um ponto no tempo, em vez de uma instância em espera na mesma região. Os backups do Aurora, a durabilidade do S3, as filas de mensagens não entregues e os ativos estáticos recriados a partir do código-fonte fazem parte da estratégia de recuperação.
8. Resposta a incidentes
8.1 Notificação de incidentes. Em caso de Incidente de Segurança (conforme definido no DPA), a ProcessMind notificará os clientes afetados sem demora injustificada e, quando viável, em até setenta e duas (72) horas após tomar conhecimento do incidente.
8.2 Tratamento de incidentes. A ProcessMind mantém procedimentos documentados de resposta a incidentes que abrangem identificação, contenção, erradicação, recuperação e análise pós-incidente. Um resumo está disponível no documento Recuperação de Desastres, Continuidade de Negócios e Resposta a Incidentes. As lições aprendidas com os incidentes são incorporadas aos controles e processos de segurança.
8.3 Comunicação. As notificações de incidentes incluem a natureza e o escopo do incidente, as categorias de dados afetadas, as medidas tomadas para conter o incidente e as ações recomendadas ao cliente.
9. Medidas organizacionais
9.1. Gerenciamento da segurança da informação. A ProcessMind mantém um sistema de gerenciamento da segurança da informação alinhado aos princípios da ISO 27001. A ProcessMind selecionou seu caminho de certificação para a certificação ISO 27001 e o atestado SOC 2 Tipo II; o processo formal de certificação ainda não foi iniciado.
9.2 Conscientização sobre segurança. Todo o pessoal com acesso aos Dados do Cliente recebe treinamento de conscientização sobre segurança. As melhores práticas de segurança estão incorporadas à integração de novos funcionários, aos fluxos de trabalho de desenvolvimento e aos procedimentos operacionais.
9.3 Gestão de fornecedores e subprocessadores. Os subprocessadores são contratualmente obrigados a cumprir padrões de proteção de dados equivalentes aos descritos neste documento. A ProcessMind mantém uma lista pública de subprocessadores e fornece aviso com pelo menos trinta (30) dias de antecedência antes de contratar um novo subprocessador. Os subprocessadores são avaliados anualmente quanto à conformidade.
9.4 Confidencialidade. Todo o pessoal autorizado a tratar Dados do Cliente está sujeito a obrigações de confidencialidade por escrito.
10. Conformidade e certificações
| Estrutura / Norma | Status |
|---|---|
| GDPR (Regulamento Geral sobre a Proteção de Dados da UE) | Em conformidade |
| Residência de dados na UE (Frankfurt, Alemanha) | Aplicada |
| Certificações de infraestrutura da AWS (ISO 27001, SOC 2, PCI DSS) | Herdadas por meio da AWS |
| ISO 27001 (ProcessMind) | Planejada — caminho de certificação selecionado; processo formal ainda não iniciado |
| SOC 2 Tipo II (ProcessMind) | Planejada — caminho de certificação selecionado; processo formal ainda não iniciado |
Validação automatizada de controles de infraestrutura (cdk-nag em AWS Solutions, HIPAA Security, NIST 800-53 R4/R5, PCI DSS 3.2.1, Serverless) | Implementada como validação de controles de engenharia, não como certificação |
| Cláusulas Contratuais Padrão (SCCs) para transferências internacionais | Implementadas (consulte o DPA) |
| Aditivo de Tratamento de Dados (DPA) | Disponível publicamente |
O uso de cdk-nag conjuntos de regras não significa que a ProcessMind seja formalmente certificada ou auditada de forma independente em relação à HIPAA, ao NIST ou à PCI DSS. Esses conjuntos de regras são usados como salvaguardas de engenharia para validar o projeto da infraestrutura e acompanhar explicitamente as lacunas.
Para dúvidas sobre segurança ou conformidade, ou para solicitar documentação, como relatórios de auditoria ou questionários de segurança preenchidos, entre em contato com support@processmind.com.