Política de Segurança da Informação da Ackaia Corporation#

Ackaia Corporation v1.00.00 24 de julho de 2026 1233 York Avenue, Apt. 301 New York, NY 10065 Estados Unidos da América www.ackaia.com

Data de Vigência: 24 de julho de 2026

Publicadora: Ackaia Corporation, 1233 York Avenue, Apt. 301, New York, NY 10065, Estados Unidos

(“Ackaia”, “Ackaia Corp.”, “nós”, “nosso”, “nossa”)

Aplicável a: produtos, sites, APIs, ambientes em nuvem, sistemas corporativos, ambientes de desenvolvimento, ativos de informação e pessoal e fornecedores de apoio da Ackaia, salvo quando houver política de segurança mais específica.

Responsável pelo Documento: Segurança da Ackaia Corp.

Contato Principal de Segurança: security@ackaia.com

Versão de Origem: tradução baseada na versão inglesa v1.00.00.

---

Histórico de Revisões#

---

1. Finalidade#

Esta Política estabelece os princípios públicos e corporativos da Ackaia para proteger informações, sistemas, produtos, usuários e operações.

Seus objetivos são proteger confidencialidade, integridade, disponibilidade, autenticidade e resiliência; gerenciar riscos continuamente; incorporar segurança e privacidade ao desenvolvimento; limitar acesso à necessidade e autorização verificadas; detectar, responder e aprender com eventos; comunicar limites relevantes com transparência; e apoiar obrigações legais, contratuais e regulatórias.

Este é um documento público. Ele não divulga configurações sensíveis, lógica de detecção, arquitetura de rede, credenciais, playbooks, valores de recuperação ou outras informações capazes de enfraquecer a segurança.

2. Escopo#

Esta Política aplica-se a:

• Serviços voltados a clientes;

• Ackaia ID e sistemas compartilhados de identidade;

• CipherDrive™ e outras aplicações;

• APIs, integrações entre serviços, autorização e mensageria;

• produção, homologação, desenvolvimento, teste e recuperação;

• código-fonte, repositórios, builds e pipelines;

• dispositivos, contas, comunicações e sistemas administrativos;

• informações criadas, recebidas, armazenadas, transmitidas ou controladas pela Ackaia;

• empregados, administradores, contratados e pessoal autorizado;

• Prestadores que tratem informações ou apoiem sistemas relevantes.

Whitepapers e políticas específicas complementam este documento e prevalecem para controles mais fortes ou precisos do produto.

3. Natureza desta Política#

Esta Política descreve o programa em alto nível. Ela não é garantia de inexistência de incidentes; declaração de que todos os controles se aplicam igualmente; certificação ISO, SOC, PCI DSS, HIPAA, FedRAMP ou equivalente; divulgação de procedimentos confidenciais; substituta da avaliação do cliente; nem compromisso contratual de nível de serviço, salvo incorporação expressa.

A referência a framework significa utilização como orientação quando apropriado, não certificação ou adoção completa.

4. Princípios de Segurança#

O programa é orientado por:

• Segurança desde a concepção: considerada na arquitetura, desenvolvimento, revisão, implantação e operação.

• Privacidade desde a concepção: minimização de coleta, acesso, exposição e retenção.

• Zero trust: nenhum acesso é confiado apenas por rede, acesso anterior ou função.

• Privilégio mínimo: pessoas e sistemas recebem somente o necessário.

• Defesa em profundidade: controles preventivos, detectivos e responsivos reduzem dependência de uma única proteção.

• Padrões seguros: configurações protetivas por padrão quando viável.

• Segregação de funções: operações sensíveis evitam concentração desnecessária de autoridade.

• Proporcionalidade: controles refletem sensibilidade, ameaça, exposição, impacto e viabilidade.

• Resiliência: sistemas preparados para conter falhas e recuperar com segurança.

• Transparência: capacidades e limites relevantes são descritos sem expor defesas sensíveis.

5. Governança e Responsabilidade#

A Ackaia atribui responsáveis por riscos, políticas, sistemas, ativos e incidentes.

A governança poderá incluir supervisão executiva; proprietários designados; políticas, padrões e procedimentos; análise de exceções e riscos residuais; requisitos em planejamento; métricas e correções; e coordenação entre engenharia, segurança, privacidade, jurídico, trust and safety e operações.

Responsáveis devem atuar dentro da autoridade definida e escalar riscos materiais.

6. Gestão de Riscos#

Avaliamos riscos considerando sensibilidade, criticidade e exposição; probabilidade e impacto; ameaças e vulnerabilidades; requisitos legais e contratuais; cadeia de suprimentos; impacto a usuários e negócio; e capacidade de recuperação e detecção.

O tratamento poderá envolver mitigação, prevenção, transferência, aceitação, monitoramento ou descontinuação. Risco residual material deve ser documentado e aceito por responsável autorizado.

Avaliações poderão ocorrer no projeto, antes de mudanças, após incidentes, na análise de fornecedores e periodicamente.

7. Gestão de Ativos#

Buscamos identificar e administrar ativos de informação, sistemas, repositórios, serviços, credenciais, dispositivos e dependências.

Controles poderão incluir propriedade, inventários, software e dependências aprovados, classificação, ciclo de vida, desativação e identificação de sistemas críticos ou expostos.

Ativos não gerenciados ou obsoletos devem ser removidos, isolados, corrigidos ou aceitos formalmente como risco.

8. Classificação e Manuseio#

As informações são classificadas por sensibilidade, obrigações, impacto e público. Padrões internos poderão usar categorias como Pública, Interna, Confidencial e Restrita.

Requisitos poderão tratar acesso autorizado, criptografia, transmissão, armazenamento, logs, retenção, dispositivos aprovados e escalonamento de incidentes.

Classificação pública não renuncia a propriedade intelectual nem autoriza alteração, personificação ou uso indevido.

9. Identidade, Autenticação e Acesso#

Usamos controles destinados a tornar o acesso atribuível, autorizado, limitado e auditável.

Eles poderão incluir identidades únicas; autenticação multifator para acesso sensível; autorização baseada em função, atributo, política ou contexto; privilégio mínimo; separação de acesso administrativo; controles de sessão e rotação; aprovação, revisão e revogação; revogação rápida após desligamento ou comprometimento; controles para acesso privilegiado, emergencial e de máquinas; e logs de eventos relevantes.

Estar em rede confiável não é autorização suficiente.

10. Arquitetura Zero Trust#

A direção zero trust presume que usuário, dispositivo, workload, segmento ou requisição não recebem confiança implícita.

Os controles poderão avaliar identidade autenticada; recurso e ação solicitados; contexto de dispositivo, sessão, rede e risco; funções, políticas e direitos; identidade do serviço e autorização do workload; e estado atual da conta.

A autorização deve ser explícita, delimitada, adequada ao momento e aplicada próxima ao recurso. Decisões e alterações administrativas devem gerar registros auditáveis quando apropriado.

11. Credenciais, Segredos e Material Criptográfico#

Senhas, chaves privadas, tokens, credenciais de API, chaves de criptografia e recuperação devem ser protegidos conforme a sensibilidade.

Controles poderão incluir gestores de segredos; proibição de segredos em repositórios públicos; acesso restrito e auditável; rotação, expiração e revogação; separação por ambiente e finalidade; geração aleatória segura; resposta a exposição; e redução de credenciais duradouras.

O pessoal não deve compartilhar credenciais nem usar segredos de produção em ambientes não aprovados.

12. Criptografia e Gestão de Chaves#

Usamos criptografia quando apropriado para dados em trânsito e em repouso. Os controles dependem da sensibilidade, arquitetura, modelo de ameaças e requisitos do Serviço.

A gestão poderá abranger geração, aleatoriedade, armazenamento, acesso, separação, rotação, revogação, backup ou recuperação, destruição e resposta a comprometimento.

Alguns produtos usam material controlado pelo usuário ou gerado no cliente. Em arquitetura de conhecimento zero documentada, a Ackaia poderá intencionalmente não possuir as chaves necessárias para descriptografar conteúdo. A documentação específica rege algoritmos, custódia, limitações e recuperação.

Não descrevemos um Serviço como E2EE ou conhecimento zero sem documentar escopo e limites.

13. Infraestrutura e Rede#

Usamos controles em camadas para ambientes de nuvem, rede, hosts, contêineres, aplicações e armazenamento.

Eles poderão incluir separação de ambientes e contas; segmentação; caminhos administrativos restritos; firewalls, filtros e limites; hardening e redução de serviços expostos; administração remota segura; criptografia; monitoramento; proteção contra ataques comuns; capacidade e disponibilidade; e remoção de sistemas e acessos sem uso.

Mudanças de infraestrutura devem seguir processos autorizados.

14. Ciclo de Desenvolvimento Seguro#

A segurança é integrada ao ciclo conforme o risco, podendo incluir requisitos e modelagem de ameaças; revisão de arquitetura; peer review e branches protegidas; testes e análise estática; varredura de dependências e segredos; validação de entrada; testes de autenticação e autorização; separação de ambientes; implantação e rollback controlados; revisão de mudanças; monitoramento; e lições aprendidas.

Ambientes de desenvolvimento e teste devem evitar dados pessoais reais quando possível. Dados de produção não devem ser copiados sem autorização e salvaguardas.

15. Segurança de Aplicações e APIs#

Aplicações e APIs devem aplicar controles adequados, incluindo autenticação e autorização; permissões no servidor; validação de entradas; proteção contra injeção, XSS, CSRF, IDOR e riscos relacionados; rate limiting; sessões, cookies e tokens seguros; proteção contra replay quando necessária; credenciais entre serviços delimitadas; versionamento; logs sem exposição desnecessária; e erros seguros.

Controles apresentados na interface também devem ser aplicados pelo backend autoritativo.

16. Logs, Monitoramento e Detecção#

Coletamos eventos necessários para detectar ameaças, investigar incidentes, aplicar políticas e manter confiabilidade.

Logs poderão abranger autenticação, recuperação, autorização, alterações administrativas, ciclo de credenciais, configuração, deploy, alertas, atividade suspeita, erros, cotas e ações relevantes de acesso ou compartilhamento.

Devem ser protegidos contra acesso e alteração, retidos conforme risco e lei e evitar segredos ou conteúdo desnecessários. Métodos e limites de detecção são confidenciais e podem mudar.

17. Gestão de Vulnerabilidades#

Mantemos processos para identificar, avaliar, priorizar, corrigir, mitigar e verificar vulnerabilidades.

Fontes poderão incluir alertas de dependências, varreduras, revisão de código e arquitetura, testes focados, avisos de fornecedores, relatos responsáveis, incidentes e inteligência de ameaças.

A prioridade considera explorabilidade, exposição, sensibilidade, impacto, privilégio necessário, exploração ativa, mitigação e risco operacional. Quando correção imediata não for viável, poderemos aplicar controles compensatórios, restringir exposição, monitorar ou desabilitar o recurso.

18. Patches e Configuração#

Sistemas e dependências devem receber atualizações conforme risco, compatibilidade e operação.

Buscamos acompanhar vulnerabilidades; priorizar exploração ativa e alto impacto; testar proporcionalmente; usar versões mantidas; documentar adiamentos; remover ou isolar componentes sem suporte; e manter baselines seguros.

19. Testes e Divulgação Responsável#

Poderemos realizar testes automatizados e manuais, revisão arquitetural, modelagem de ameaças, revisão de código, testes de invasão e exercícios de recuperação.

Pesquisadores externos devem seguir a Política de Divulgação Responsável. A pesquisa não poderá acessar dados de terceiros, interromper Serviços, usar material ilegal ou malware ativo, realizar engenharia social, divulgar vulnerabilidade não corrigida de modo arriscado nem contornar sistemas de proteção para abuso.

20. Terceiros e Cadeia de Suprimentos#

Avaliamos Prestadores e dependências relevantes conforme acesso, dados e risco operacional.

Controles poderão incluir due diligence; obrigações contratuais; integração com privilégio mínimo; análise de localização e suboperadores; integridade e atualizações; separação e rotação de credenciais; contingência; reavaliação; e devolução ou exclusão no encerramento.

O uso de fornecedor não transfere nossa responsabilidade pelos riscos sob nosso controle.

21. Segurança de Pessoal#

Pessoas com acesso estão sujeitas a confidencialidade e uso aceitável; verificações legais e apropriadas; conscientização; treinamento por função; aprovação e privilégio mínimo; mudanças rápidas de acesso; consequências por uso indevido; e offboarding.

Devem comunicar incidentes, exposição de credenciais, violações e fragilidades materiais prontamente.

22. Endpoints e Trabalho Remoto#

Dispositivos usados para sistemas sensíveis devem ter sistemas suportados e atualizados, criptografia, bloqueio e autenticação fortes, proteção contra malware, privilégios restritos, acesso remoto seguro, separação de informações quando apropriado, capacidade de revogação ou limpeza e restrições a software e mídia não confiáveis.

O pessoal deve proteger fisicamente dispositivos e denunciar perda, roubo ou comprometimento.

23. Segurança Física e Ambiental#

Usamos infraestrutura em nuvem, Prestadores e ambientes corporativos. Controles poderão incluir restrição de acesso, procedimentos para visitantes e equipamentos, descarte seguro, garantia contratual de datacenters e proteção contra furto, dano e observação.

Não alegamos controle direto sobre instalações de fornecedores além dos direitos e garantias disponíveis.

24. Minimização, Retenção e Descarte#

Buscamos coletar e reter apenas o necessário para finalidades definidas.

Controles poderão incluir critérios de retenção; exclusão ou anonimização; ciclos de logs, backups, temporários e objetos abandonados; preservação legal e de segurança; exclusão segura ou apagamento criptográfico; requisitos a Prestadores; e desativação de mídias, sistemas e Contas.

Backups ou registros imutáveis poderão seguir ciclo posterior quando a exclusão imediata não for viável.

25. Backup, Continuidade e Recuperação#

Mantemos medidas proporcionais à criticidade, como backups ou replicação, separação geográfica ou de domínio de falha, procedimentos de restauração, mapeamento de dependências, processos alternativos, planejamento de capacidade, testes e prioridades de recuperação.

Nenhuma arquitetura garante recuperação total. Termos do Produto poderão exigir cópias independentes, especialmente quando chaves controladas pelo usuário forem necessárias.

26. Resposta a Incidentes#

Mantemos processo destinado a receber e validar relatos; classificar eventos; conter sistemas ou acessos; preservar provas; investigar escopo e causa; erradicar ameaças; corrigir fragilidades; recuperar com segurança; notificar quando necessário; e registrar lições e ações.

A resposta poderá envolver segurança, engenharia, privacidade, jurídico, trust and safety, comunicações, liderança, Prestadores e autoridades. Detalhes poderão permanecer confidenciais durante investigação ou quando a divulgação aumentar riscos.

27. Notificação de Incidentes#

Avaliamos obrigações conforme dados, jurisdição, risco, contratos e lei. Quando exigido, notificaremos usuários, clientes, reguladores, autoridades ou outras partes no prazo aplicável.

Avisos poderão descrever natureza, dados ou sistemas afetados, ações adotadas, medidas recomendadas e suporte. A notificação poderá ser adiada quando autorizada, necessária à investigação ou determinada por autoridade.

28. Gestão de Mudanças#

Mudanças materiais em produção, controles, infraestrutura e configurações sensíveis devem ser autorizadas, testadas proporcionalmente, rastreáveis e reversíveis.

Controles poderão incluir revisão por pares, testes, aprovações, separação de ambientes, validação, rollback, monitoramento e revisão posterior de mudanças emergenciais.

29. Exceções de Segurança#

Uma exceção interna deve ter necessidade documentada, avaliação de risco, aprovação autorizada, prazo quando possível, controles compensatórios e revisão ou encerramento.

Exceções não afastam obrigações legais ou contratuais sem autorização de quem possa exigi-las.

30. Responsabilidades de Clientes e Usuários#

Segurança é compartilhada. Usuários devem proteger credenciais, recuperação, chaves, sessões e dispositivos; habilitar e configurar recursos; conceder acesso apenas a autorizados; revogar acessos; manter dispositivos e integrações; proteger downloads; revisar links e permissões; manter backups; relatar comprometimento; e cumprir Termos e lei.

A Ackaia não pode proteger informações depois que destinatário autorizado as baixa, copia ou redistribui fora de seu controle.

31. Limites Específicos de Produtos#

Capacidades variam entre Serviços. Documentamos limites relevantes separadamente.

Para o CipherDrive™, o Whitepaper de Segurança e Criptografia descreve criptografia no cliente, conhecimento zero, metadados, riscos locais, compartilhamento, custódia e limites de proteção.

Declarações sobre um produto não se aplicam automaticamente a outro.

32. Solicitações Legais, Acesso Governamental e Backdoors#

Solicitações legais são tratadas conforme a Política de Resposta a Solicitações Legais.

A Ackaia não cria nem mantém backdoor de uso geral para o CipherDrive™ e não pode divulgar texto simples, chaves controladas pelo usuário ou material que não possui.

Esta Política não impede cumprimento de obrigações válidas relativas a dados sob nosso controle, contestação de solicitações impróprias ou ações urgentes de proteção.

33. Frameworks de Referência#

O programa poderá se orientar por:

• NIST Cybersecurity Framework 2.0;

• Recomendações de Resposta a Incidentes do NIST;

• CISA Secure by Design;

• práticas de desenvolvimento seguro, nuvem, privacidade e criptografia adequadas à arquitetura.

Essas referências são orientação, não certificação, atestado ou adoção integral.

34. Conformidade, Revisão e Melhoria#

Poderemos avaliar conformidade mediante monitoramento, revisão de acesso e configuração, vulnerabilidades, exercícios, avaliações, reconhecimento de políticas, treinamento e acompanhamento de correções.

Esta Política é revista periodicamente e diante de mudanças materiais em leis, ameaças, produtos, arquitetura ou operações.

35. Aplicação#

Violações poderão resultar em remoção ou restrição de acesso, revogação de credenciais, ação corretiva ou disciplinar, medidas contratuais, encerramento de vínculo ou acesso e ação legal ou comunicação a autoridades.

A resposta considera gravidade, intenção, impacto, repetição e obrigações.

36. Alterações desta Política#

Poderemos atualizar esta Política por mudanças em ameaças, tecnologia, lei, Serviços, arquitetura, responsabilidades ou práticas.

O histórico e a data identificam a versão atual. Alterações materiais poderão ser anunciadas pelo Repositório Jurídico, sites, avisos de produto, comunicações de segurança ou canal apropriado.

37. Contato#

Vulnerabilidades devem ser comunicadas segundo a Política de Divulgação Responsável.

Segurança: security@ackaia.com

Privacidade: privacy@ackaia.com

Jurídico: legal@ackaia.com

Abuso: abuse@ackaia.com

Site: www.ackaia.com

Endereço: 1233 York Avenue, Apt. 301, New York, NY 10065, Estados Unidos da América

Não envie senhas, tokens, chaves privadas, frases de recuperação, malware ativo, material de abuso sexual infantil ou dados pessoais não relacionados por e-mail comum.

---

Fim da Política de Segurança da Informação