Política de Segurança

1. Governança de segurança e riscos

• As responsabilidades de segurança são atribuídas para operação da plataforma, acesso, tratamento de incidentes, correção de vulnerabilidades e comunicação com clientes.
• Os riscos são avaliados considerando a sensibilidade de credenciais e segredos, limites de tenants e recursos, exposição à internet, dependências, modelo de implantação e impacto empresarial.
• Pessoal e prestadores recebem acesso somente quando necessário e estão sujeitos a requisitos de confidencialidade e segurança.
• Políticas, ameaças, incidentes materiais e alterações significativas da plataforma são revisados, e as melhorias são priorizadas por risco.

2. Arquitetura e proteção de dados

• O tráfego hospedado compatível é criptografado em trânsito usando configurações atuais de segurança de transporte.
• Dados armazenados de credenciais e segredos são criptografados em repouso nos componentes hospedados compatíveis.
• A autorização é aplicada por organizações, equipes, espaços de trabalho, cofres, funções, permissões e verificações no nível do recurso.
• Tenants STARTER e PRO operam em clusters Kubernetes compartilhados com isolamento lógico e políticas de rede do Kubernetes. Clientes ENTERPRISE recebem um cluster Kubernetes dedicado e segregado, salvo se um projeto de implantação privada aprovado separadamente estiver documentado no Pedido.
• Implantações hospedadas usam uma região disponível da AWS selecionada conforme os requisitos do Cliente e registrada no Pedido ou cronograma do serviço aplicável. A kubbeevault não impõe uma região padrão de dados do cliente para todas as implantações.
• O histórico de auditoria registra atividades relevantes de criação, acesso, alteração, compartilhamento e exclusão conforme o plano selecionado e a configuração de retenção.
• Implantações hospedadas usam componentes segmentados da aplicação e controles de infraestrutura gerenciada adequados à implantação; implantações privadas Enterprise têm responsabilidades definidas no Pedido.
• Para implantações hospedadas compatíveis, o perfil STARTER proposto usa uma réplica da aplicação em uma zona de disponibilidade com reagendamento automático e duas instâncias de banco de dados em duas zonas de disponibilidade; seu RTO alvo é de no máximo 30 minutos e o RPO alvo é de no máximo 5 minutos. O perfil PRO proposto usa duas réplicas da aplicação em duas zonas de disponibilidade e duas instâncias de banco de dados em duas zonas; seu RTO alvo é de no máximo 10 minutos e o RPO alvo é de no máximo 1 minuto. O perfil ENTERPRISE proposto usa três réplicas da aplicação em três zonas de disponibilidade e três instâncias de banco de dados em três zonas; seu RTO alvo é de no máximo 5 minutos e o RPO alvo é de no máximo 1 minuto.
• Esses números de recuperação são objetivos de serviço, não garantias ou compromissos de nível de serviço, salvo se incorporados ao Pedido ou cronograma de nível de serviço aplicável. Localização dos dados, opções de gestão de chaves, detalhes de isolamento de tenant, projeto de backup, procedimentos de recuperação e retenção permanecem específicos da implantação. Implantações privadas e gerenciadas pelo Cliente exigem responsabilidades e objetivos acordados separadamente.

3. Gestão de identidade e acesso

A autenticação nativa está disponível. O login único não é apresentado como disponível de forma geral, salvo se um Pedido ou a documentação atual do produto disser o contrário. O acesso administrativo e de produção segue princípios de privilégio mínimo, é limitado a pessoal autorizado e deve usar autenticação forte e caminhos de acesso auditáveis.

• Os Clientes devem usar contas individuais, funções adequadas, desligamento imediato, endpoints seguros e rotação de segredos.
• Os Clientes são responsáveis por seu provedor de identidade, fatores de recuperação, integrações, clientes de API, ambiente do navegador e qualquer implantação gerenciada pelo Cliente.
• O suporte da kubbeevault não solicitará senha, chave privada, token ou segredo completo por e-mail comum ou formulário do site.

4. Operação e desenvolvimento seguros

• As alterações são revisadas, testadas proporcionalmente ao risco e implantadas por fluxos controlados de build e release.
• Dependências, configurações, código e infraestrutura são avaliados quanto a vulnerabilidades usando técnicas automatizadas e manuais disponíveis.
• Patches de segurança e vulnerabilidades verificadas são priorizados conforme severidade, explorabilidade, exposição e impacto ao cliente.
• Logs e monitoramento apoiam disponibilidade, autenticação, autorização, auditoria, prevenção de abuso e investigação de incidentes.
• Backups e redundância são mantidos para implantações hospedadas compatíveis conforme o cronograma de serviço aplicável; a capacidade de restauração é testada em frequência adequada ao risco do serviço.
• Os procedimentos de backup, resposta a incidentes e exclusão estão documentados em runbooks internos do Confluence. Compromissos vinculantes relacionados surgem somente quando indicados no Pedido ou cronograma de nível de serviço aplicável.
• Relatórios de testes de segurança e vulnerabilidades gerados para um Cliente podem ser compartilhados com esse Cliente conforme os termos aplicáveis de confidencialidade, escopo e entrega. Um relatório não é certificação e se aplica somente aos sistemas, métodos e data de teste nele indicados.
• Os segredos usados para operar a kubbeevault são armazenados e acessados por mecanismos controlados e não são enviados a repositórios públicos de código-fonte.

5. Disponibilidade, suporte e diferenças entre planos

• STARTER: SaaS, suporte por e-mail, disponibilidade por melhor esforço, RTO alvo proposto de no máximo 30 minutos e RPO alvo proposto de no máximo 5 minutos, salvo se o Pedido indicar compromisso vinculante.
• PRO: SaaS, suporte prioritário 8×5, meta de disponibilidade indicada na descrição atual de preços ou no Pedido, RTO alvo proposto de no máximo 10 minutos e RPO alvo proposto de no máximo 1 minuto.
• ENTERPRISE: SaaS ou implantação privada aprovada, suporte 24×7, RTO alvo proposto de no máximo 5 minutos, RPO alvo proposto de no máximo 1 minuto e termos negociados no Pedido para disponibilidade, resposta inicial, manutenção, recuperação e créditos de serviço.
• As descrições públicas dos planos não substituem um cronograma de nível de serviço assinado. As exclusões normalmente incluem manutenção anunciada, sistemas controlados pelo Cliente, configurações não compatíveis, força maior e prestadores externos fora do controle razoável da kubbeevault.

6. Resposta a incidentes

A kubbeevault mantém um processo para identificar, fazer triagem, conter, investigar, erradicar, recuperar e revisar incidentes de segurança. Os Clientes devem relatar prontamente suspeitas de comprometimento e preservar informações relevantes sem inserir segredos ativos em comunicações comuns.

Para uma Violação de Dados Pessoais confirmada que afete Dados Pessoais do Cliente, aplicam-se os compromissos de notificação e cooperação do Acordo de Processamento de Dados. Outras notificações materiais de segurança do serviço seguem o Pedido e a lei aplicável. Declarações públicas são coordenadas para evitar o aumento do risco ou o comprometimento de uma investigação.

7. Garantias e declarações verdadeiras

A kubbeevault não alega certificação ISO, exame SOC, conformidade com PCI DSS, teste de invasão independente concluído, garantia pós-quântica ou outra atestação formal, salvo se o relatório ou certificado atual específico for disponibilizado e seu escopo for informado. Itens do roadmap não são controles de produção.

Clientes Enterprise podem solicitar materiais disponíveis de revisão de arquitetura, segurança e aspectos comerciais sob confidencialidade. O acesso a resultados detalhados de testes, código-fonte, infraestrutura ou informações de outro cliente não é fornecido, salvo acordo expresso e escopo seguro.

8. Comunicação de questões de segurança

Possíveis vulnerabilidades devem ser relatadas conforme a Política de Divulgação de Vulnerabilidades para [email protected]. Incidentes de Clientes devem usar os contatos de suporte e escalonamento do Pedido. Não publique uma vulnerabilidade não corrigida nem inclua segredos ativos do Cliente em um relato.