Visão Geral de Segurança / Whitepaper de Segurança

Última atualização: 25 de outubro de 2026 (versão 1.0).

Periodicidade de revisão: anual, e sempre que ocorra qualquer alteração material na arquitetura da plataforma

1. Introdução

A PassportScan Cloud é uma plataforma de Software-as-a-Service operada pela GlobeID Limited ("GlobeID") que permite aos prestadores de alojamento capturar documentos de identidade dos hóspedes, obter consentimentos e assinaturas, e cumprir as obrigações legais de registo de hóspedes (autoridades policiais, de estatística e de fronteiras), bem como a integração com sistemas PMS.

Este documento descreve a arquitetura de segurança e as medidas técnicas e organizativas que protegem a plataforma e os dados pessoais nela tratados. Destina-se a clientes, potenciais clientes e auditores, complementa o Acordo de Tratamento de Dados (DPA) e a Lista de Subcontratantes, e constitui a resposta de referência a questionários de segurança. Descreve a plataforma de produção tal como implementada na data de entrada em vigor deste documento.

2. Programa de segurança e conformidade

• A GlobeID opera um Sistema de Gestão de Segurança da Informação (SGSI) alinhado com a norma ISO/IEC 27001:2022, com um Chief Information Security Officer designado, um registo de riscos e uma Declaração de Aplicabilidade; o SGSI é revisto através de auditorias internas e revisões pela gestão planeadas em ciclo anual.
• RGPD: a GlobeID atua como subcontratante no tratamento dos dados dos hóspedes ao abrigo do DPA e nomeou um Encarregado de Proteção de Dados externo. São mantidos registos das atividades de tratamento, uma AIPD relativa aos dados de identidade dos hóspedes e um procedimento para o exercício dos direitos dos titulares dos dados.
• Os dados de cartões de pagamento são tratados exclusivamente pela Stripe; a PassportScan não opera um Ambiente de Dados de Titulares de Cartões e nunca recebe números de cartão, CVV ou datas de validade.
• A monitorização dos controlos é contínua, através de uma plataforma de automação de conformidade ligada aos fornecedores de serviços de cloud, de código-fonte e de identidade; são encomendados periodicamente testes de intrusão independentes e as constatações são acompanhadas até à sua resolução.

3. Alojamento e arquitetura

4. Segurança de rede

• Privado por predefinição: todos os serviços são executados em sub-redes privadas de uma VPC dedicada. Apenas os front-ends destinados aos clientes, a consola de administração do pessoal e duas APIs públicas são acessíveis a partir da Internet, através do Amazon API Gateway e de um Application Load Balancer público. A consola de administração é protegida pelo AWS WAF e pela sua própria autenticação, com contas de pessoal atribuídas individualmente e autenticação multifator obrigatória. Todos os microsserviços internos, o motor de automação e o motor de OCR são acessíveis apenas a partir do interior da VPC ou através da VPN da empresa.
• Firewall de aplicações web: o perímetro público (stages do API Gateway e o load balancer público) é protegido pelo AWS WAF. Os grupos de regras geridos pela AWS Amazon IP Reputation List e Known Bad Inputs bloqueiam origens e payloads maliciosos, o Core Rule Set da AWS (alinhado com o OWASP) é avaliado em cada pedido, e a limitação de taxa (rate limiting) bloqueia origens abusivas, com limites mais rigorosos nos endpoints de autenticação.
• Encriptação do transporte: os endpoints públicos aceitam exclusivamente TLS 1.2 e TLS 1.3 (política de segurança do API Gateway TLS_1_2; política do load balancer ELBSecurityPolicy-TLS13-1-2-2021-06 com conjuntos de cifras modernos ECDHE-GCM). O tráfego HTTP é redirecionado para HTTPS e o HTTP Strict Transport Security (HSTS) é imposto no load balancer público. Os certificados são emitidos e renovados automaticamente pelo AWS Certificate Manager.
• Acesso administrativo: os engenheiros acedem aos serviços internos exclusivamente através de uma VPN zero-trust associada à sua identidade individual; não há SSH nem RDP expostos à Internet, nem bastion host.
• Registo de rede: os VPC Flow Logs (todo o tráfego) e os registos de acesso ao servidor S3 são conservados durante 90 dias.

5. Segurança dos dados

5.1 Criptografia

5.2 Localização e residência dos dados

• Os serviços principais da plataforma e as bases de dados primárias são alojados exclusivamente na AWS eu-west-1 (Irlanda); não está configurada nenhuma replicação de bases de dados entre regiões.
• Quando um cliente ativa o armazenamento de imagens de documentos, as imagens são armazenadas na região do S3 correspondente à jurisdição do estabelecimento. Regiões provisionadas: eu-west-1 (Europa), us-east-1 (América do Norte), sa-east-1 (América do Sul), ap-southeast-1 (Ásia-Pacífico) e ap-southeast-2 (Austrália). Cada bucket regional aplica a mesma configuração de criptografia, versionamento e registo de acessos.
• As transferências para fora do EEE estão cobertas pelo Adendo de Tratamento de Dados (Data Processing Addendum) da AWS e pelas Cláusulas Contratuais-Tipo, conforme descrito no DPA.

5.3 Segredos e chaves

• Os segredos da aplicação, as chaves de API e as chaves de criptografia são armazenados no AWS Systems Manager Parameter Store (SecureString) e injetados nos contêineres no momento da inicialização; nunca são incluídos no código-fonte nem incorporados nas imagens.
• As credenciais da base de dados são geradas e rotacionadas pela AWS (segredos geridos pelo RDS no AWS Secrets Manager) ou armazenadas como SecureStrings no AWS Systems Manager Parameter Store e injetadas nos contêineres como segredos no momento da inicialização.
• As alterações de segredos em produção são realizadas através de um fluxo de trabalho operacional auditado, e não manualmente na consola. As senhas das bases de dados da aplicação são rotacionadas de forma programada pela nossa plataforma interna de operações, sem qualquer tempo de inatividade.

5.4 Cópias de segurança e retenção

• Aurora MySQL: cópias de segurança automáticas diárias com retenção de 15 dias e recuperação pontual (point-in-time recovery) contínua; proteção contra eliminação ativada; é efetuado um snapshot final antes de qualquer eliminação de cluster.
• Armazenamento de objetos: versionamento com retenção de 90 dias das versões anteriores, protegendo contra eliminação ou substituição acidental.
• No final do contrato, os dados do cliente são devolvidos ao cliente e/ou eliminados a seu pedido, no prazo de 30 dias a contar do pedido, conforme estabelecido no DPA; as cópias de segurança expiram subsequentemente através do ciclo de retenção acima descrito.

6. Gestão de identidades e acessos

• Utilizadores clientes: autenticam-se através do fornecedor de identidade da plataforma (Clerk) com verificação de e-mail, gestão de sessões e autenticação multifator opcional; o acesso dentro de uma conta de cliente é baseado em funções.
• Pessoal da GlobeID: o acesso ao código-fonte, ao CI/CD e à consola de gestão interna é efetuado através da organização GitHub, com autenticação de dois fatores obrigatória. Nenhum engenheiro detém acesso permanente à conta AWS de produção, e nenhuma credencial detida por uma pessoa pode assumir uma função nessa conta: a produção é alterada e operada exclusivamente através da nossa plataforma interna de operações e de fluxos de trabalho operacionais auditados, sem qualquer via de consola ou de linha de comandos para os engenheiros. Os programadores têm acesso de privilégio mínimo apenas às contas de desenvolvimento e de staging. A monitorização e as operações utilizam funções dedicadas de privilégio mínimo; as ações operacionais limitadas disponíveis na nossa plataforma de operações (por exemplo, reinício progressivo, modo de manutenção, rotação programada de credenciais, tarefas pontuais de dados aprovadas e snapshots de bases de dados) estão circunscritas a recursos nominalmente identificados, condicionadas por função e, no caso de operações sobre dados de produção, por um segundo administrador, e são auditadas. Um procedimento de emergência documentado (break-glass) está restrito a proprietários da organização designados, é executado exclusivamente através do nosso sistema de CI/CD e é registado e revisto sempre que é utilizado.
• Acesso à base de dados de produção: não é concedido de forma permanente aos engenheiros; é solicitado just-in-time através da nossa plataforma interna de operações com indicação do motivo, aprovado por um segundo administrador (nunca o requerente), provisionado como um utilizador de base de dados circunscrito a uma única base de dados e a um único nível de acesso, nunca com direitos de alteração de esquema, limitado no tempo (em produção, no máximo 4 horas para acesso de leitura e 1 hora para acesso de escrita) e removido automaticamente no termo do prazo; as credenciais são apresentadas apenas ao requerente. Todos os pedidos, aprovações e revogações são registados. É proibida a exportação de dados de produção para estações de trabalho.
• Os dados de produção permanecem em produção: os ambientes de desenvolvimento e de staging utilizam exclusivamente dados sintéticos ou anonimizados. Os snapshots de bases de dados são restaurados apenas numa nova base de dados no ambiente a partir do qual foram criados, pelo que os dados de produção nunca são restaurados em ambientes de desenvolvimento ou de teste; um restauro em produção exige a indicação do motivo e a aprovação de um segundo administrador. As correções aos dados de produção são efetuadas apenas através de tarefas previamente declaradas e sujeitas a revisão de código, testadas primeiro em staging e aprovadas por um segundo administrador — nunca através de SQL ad hoc.
• Trilho de auditoria da atividade dos operadores: todas as operações privilegiadas efetuadas através da plataforma de operações, incluindo o acesso ao conteúdo de registos de produção — pedidos e aprovações de acesso, promoções e reversões de versões, alterações do estado de alimentação dos ambientes, alterações de configuração, aprovações de documentos e assinaturas eletrónicas — são registadas com a identidade do operador (SSO do GitHub, 2FA obrigatória), a data e hora e o resultado, e estão disponíveis como elementos de prova para os auditores.
• CI/CD para a AWS: a autenticação é efetuada através de federação OpenID Connect do GitHub, com uma função de implementação dedicada por ambiente, restrita aos repositórios nominalmente identificados da plataforma.
• Os procedimentos de admissão/mudança de funções/saída, a triagem e os compromissos de confidencialidade fazem parte do procedimento de segurança de recursos humanos; as revisões de acessos são realizadas periodicamente.

7. Desenvolvimento seguro e gestão de alterações

• Todas as alterações chegam à produção através do Git: pull request, revisão de código independente (aprovação por pessoa diferente do autor), verificações automatizadas e um fluxo de promoção com ramo por ambiente (desenvolvimento → staging → produção). Cada promoção para staging e para produção é solicitada por um administrador e aprovada por um administrador diferente através da plataforma de operações, com reconhecimento explícito de quaisquer migrações de base de dados que inclua; a promoção para produção exige ainda a validação de QA sobre a versão em staging. Cada conjunto de alterações é rastreável desde o ticket até à versão implementada, e as implementações em produção fora da plataforma de operações são recusadas, exceto ao abrigo do procedimento de break-glass.
• As imagens de contentores são compiladas uma única vez e submetidas a análise de vulnerabilidades conhecidas no momento do push para o registo; as etiquetas do registo de produção são imutáveis (uma etiqueta publicada nunca pode ser substituída de forma silenciosa) e a produção extrai exatamente o digest da imagem validado em staging — nada é recompilado para produção.
• As alterações de infraestrutura seguem o mesmo percurso (plan do Terraform no pull request, apply na integração), proporcionando um trilho de auditoria completo e passível de revisão das alterações em produção.
• As versões podem ser revertidas por componente; a versão implementada de cada componente é registada antes de cada promoção.

8. Registos (logs), monitorização e resposta a incidentes

• Registos centralizados: os registos de aplicação e de acesso de todos os serviços são enviados para o Datadog (site da UE, datadoghq.eu) e para o Amazon CloudWatch; os registos de aplicação são conservados por um período máximo de 90 dias. Os dados pessoais e os segredos são mascarados nos serviços antes de os registos serem enviados para o Datadog, e novamente no momento da sua apresentação: através da nossa plataforma de operações, os colaboradores que não sejam administradores veem o conteúdo dos registos de produção com os valores pessoais mascarados no próprio local, e as ferramentas automatizadas e de IA não recebem quaisquer conteúdos (payloads) de pedidos ou de respostas, enquanto a informação necessária para o diagnóstico (mensagens de erro, identificadores de pedidos, códigos de estado) permanece visível. Todos os acessos ao conteúdo dos registos de produção são auditados.
• Auditoria na nuvem e deteção de ameaças: o AWS CloudTrail regista todas as chamadas à API de gestão efetuadas na conta de produção, em todas as regiões, com validação da integridade dos ficheiros de registo e armazenamento com controlo de versões; o Amazon GuardDuty analisa continuamente o CloudTrail, os VPC Flow Logs e a atividade de DNS em todas as regiões em que operamos, para detetar ameaças como a utilização indevida de credenciais, atividades de reconhecimento e comunicação com anfitriões reconhecidamente maliciosos; os resultados são analisados pela equipa de operações.
• Alertas: os alarmes do CloudWatch relativos a bases de dados, caches, balanceadores de carga, API Gateway e eventos do ciclo de vida das tarefas do ECS notificam a equipa de operações através do SNS; o desempenho das aplicações é monitorizado no Datadog; o estado da infraestrutura, as filas, os custos e os avisos de descontinuação por ambiente são consolidados na consola de monitorização da plataforma de operações.
• Página pública de estado: a disponibilidade da plataforma é monitorizada externamente e publicada em https://status.passportscan.net, com comunicação automática de incidentes e de manutenções.
• Resposta a incidentes: um Procedimento de Resposta a Incidentes e de Violação de Dados documentado define os níveis de gravidade, as funções e o escalonamento. As violações de dados pessoais são notificadas aos clientes afetados sem demora injustificada e, em qualquer caso, no prazo de 48 horas, conforme previsto no Acordo de Tratamento de Dados (DPA), e à autoridade de controlo no prazo de 72 horas, sempre que exigido (artigo 33.º do RGPD).
• Divulgação de vulnerabilidades: os investigadores de segurança podem comunicar problemas ao abrigo da Política de Divulgação de Vulnerabilidades (security@passportscan.net).

9. Continuidade de negócio e recuperação de desastres

• O ambiente de produção funciona em serviços geridos da AWS distribuídos por três zonas de disponibilidade na região eu-west-1: o armazenamento do Aurora é replicado em seis cópias pelas três zonas, os serviços essenciais executam pelo menos duas tarefas distribuídas pelas zonas, com escalonamento automático em função da carga, e o ECS substitui automaticamente uma tarefa com falha numa zona saudável, por trás dos balanceadores de carga. As implementações utilizam um mecanismo de disjuntor (circuit breaker) que reverte automaticamente quando uma nova versão falha as verificações de estado.
• As bases de dados podem ser restauradas para qualquer momento dentro da janela de retenção de 15 dias; o procedimento de restauro faz parte do exercício anual de recuperação de desastres.
• Uma Análise de Impacto no Negócio e um Plano de Continuidade de Negócio e Recuperação de Desastres definem os objetivos de recuperação da plataforma (objetivo de tempo de recuperação inferior a duas horas para o serviço principal de check-in; objetivo de ponto de recuperação na ordem de minutos, graças à recuperação pontual no tempo).
• As dependências de terceiros (fornecedor de serviços na nuvem, fornecedor de identidade, prestador de serviços de pagamento, gestão de registos, proteção contra bots e serviços de comunicação empresarial) são avaliadas no âmbito do processo de segurança de fornecedores e constam da Lista de Subcontratantes.

10. Subcontratantes

Os terceiros que tratam dados pessoais de clientes por conta da GlobeID encontram-se enumerados, com a respetiva finalidade e localização do tratamento, na Lista pública de Subcontratantes, disponível em https://www.passportscan.net/sub-processor/. Os clientes são notificados de quaisquer aditamentos em conformidade com o Acordo de Tratamento de Dados (DPA).

11. Responsabilidade partilhada

A GlobeID é responsável pela segurança da plataforma, conforme descrito acima. Os clientes continuam a ser responsáveis por: gerir os seus utilizadores e credenciais (incluindo a ativação da MFA), assegurar a segurança dos dispositivos e das redes utilizados para aceder à plataforma, configurar de forma lícita as opções de retenção e de armazenamento regional, fornecer avisos de privacidade aos hóspedes e garantir a segurança de qualquer PMS ou sistema de terceiros que liguem à plataforma.

12. Contacto

Questões e questionários de segurança: security@passportscan.net Privacidade e Encarregado de Proteção de Dados (DPO): privacy@passportscan.net GlobeID Limited, The Black Church, St. Mary's Place, Dublin 7, D07 P4AX, Irlanda (CRO 559612)