Segurança da instalação

Esta página reúne os controles de segurança da instalação na versão 3.7 e os limites atuais, para avaliação pela equipe de segurança da informação.

Isolamento do Docker do servidor

A API nunca recebe o socket do Docker. Um serviço separado, o docker-guard, sem rede, é o único com esse acesso e permite apenas a gestão dos modelos locais:

• Somente os containers desta instalação, nunca os de outro projeto Compose.
• Containers criados apenas a partir das imagens de runtime conhecidas, com os rótulos e a rede desta instalação e volumes nomeados próprios.
• Acesso a dispositivos limitado às GPUs NVIDIA ou a /dev/dri, apenas nos containers de modelo.
• Sem modo privilegiado, sem montagens do servidor, sem rede do servidor e sem capacidades extras.
• Os containers da própria plataforma não podem ser parados nem removidos por ele.

Toda recusa fica registrada no log do docker-guard.

Segredos e credenciais

• Cada instalação gera o próprio APP_SECRET e credenciais exclusivas para PostgreSQL, Redis e MinIO. Em produção, segredos curtos (menos de 32 caracteres) ou fracos são recusados.
• Os arquivos gerados pela instalação ficam legíveis apenas pelo dono.
• Chaves de provedores e credenciais de integrações são cifradas no banco com XChaCha20-Poly1305, vinculadas ao escopo e ao nome de cada segredo.
• Senhas são armazenadas com hash Argon2.
• Segredos nunca chegam ao navegador.

Autenticação e sessões

• Login local com senha de pelo menos 12 caracteres e bloqueio temporário após falhas repetidas.
• SSO OIDC com Microsoft Entra ID, Google Workspace ou qualquer provedor OIDC; a autenticação multifator fica a cargo do provedor de identidade.
• Conta root fora do SSO, recuperável no servidor com chave de uso único verificada offline.
• Sessões em cookie HttpOnly e SameSite=Strict, com Secure atrás de HTTPS.

Veja Usuários, papéis e acesso.

Proteção de saída

URLs que um usuário pode influenciar passam por uma proteção contra SSRF: endereços privados, de loopback, link-local, CGNAT e de metadados de nuvem são bloqueados, salvo liberação explícita em APTABIT_SSRF_ALLOWED_HOSTS. As chamadas de integração não seguem redirecionamentos. Veja Integrações.

Rede e TLS

O proxy da plataforma atende HTTP em uma única porta (8080 por padrão). O TLS é terminado no balanceador ou no proxy reverso da organização. O CLI confia nas autoridades certificadoras do sistema, o que permite operar atrás de proxies corporativos que inspecionam HTTPS.

Distribuição e integridade

• O script de instalação confere o CLI com o manifesto de versão assinado pela Aptabit (Ed25519). O aptabit self-update faz a mesma verificação antes de substituir o binário.
• As imagens vêm de um registry privado, com credenciais de curta duração que o Aptabit Manager emite para uma licença ativa, mediante pedido assinado pela identidade da instalação.
• Cada imagem recebida carrega uma declaração de proveniência assinada pelo Aptabit Manager, que identifica quem a recebeu.
• Cada instalação tem um par de chaves Ed25519 gerado na própria máquina; o Aptabit Manager guarda apenas a chave pública.

Dados em repouso

Documentos, tabelas, vetores e arquivos ficam no PostgreSQL, no MinIO (ou serviço S3) e no Milvus da instalação. Os segredos são cifrados pela plataforma; a cifragem dos volumes e do armazenamento de objetos é feita pela infraestrutura da organização, no disco ou no serviço S3.

Limites atuais

• Cada instalação roda em um único servidor. Alta disponibilidade depende de PostgreSQL, Redis, S3 e Milvus gerenciados externamente.
• O isolamento entre organizações é feito pela aplicação, com uma organização por instalação; o banco não usa row-level security.
• A trilha de auditoria não é apagada por expurgos nem editável pela API, mas o banco não impõe imutabilidade técnica.
• Os backups do CLI são locais e não cifrados. Veja Operação.