Construído seguro por predefinição.
Configurável ao seu nível de risco.

A indexação e pesquisa de documentos permanecem na sua VM ReefOffice: o bge-m3 cria embeddings localmente e o Qdrant armazena o texto e vetores localmente. Num piloto Private AI, a geração executa na infraestrutura GPU gerida pelo ReefOffice na Alemanha através de um túnel encriptado. O seu prompt e os excertos relevantes do documento atingem esse GPU, enquanto os seus ficheiros de origem, índice, conversas e dados de aplicação permanecem na sua VM. A retenção e garantias contratuais do fornecedor estão a ser validadas antes da disponibilidade paga. Se ligar a sua própria chave IA externa, esse fornecedor recebe o prompt e excertos selecionados sob os seus próprios termos.

As automações pré-construídas (indexação de documentos, acompanhamento de faturas, arquivo de contratos, configuração de negócios ganhos, …) executam num runtime de automação apenas para operadores que o ReefOffice gere — não no Activepieces, o construtor sem código da sua equipa. As credenciais de que precisam (as suas contas de admin do Nextcloud / Dolibarr / Paperless, o relay de email) são armazenadas encriptadas e lidas apenas pelo trabalho em execução através de credenciais de runtime limitadas ao trabalho; nunca são escritas em qualquer definição de fluxo de trabalho que um utilizador possa abrir. Quando o agente de IA privado desencadeia uma das automações aprovadas, chama um shim local autorizado que injeta as credenciais do lado do servidor, então o agente nunca recebe credenciais gerais do motor de automação. O seu sandbox Activepieces contém zero credenciais de operador, e o acesso de runtime é aplicado apenas para operadores em cada implementação, então uma conta obsoleta não pode permanecer com acesso. Isto fecha a classe de risco onde uma automação integrada se torna uma forma de ler uma palavra-passe de admin.

Correto, e isso é por conceção — LUKS é a ferramenta certa para ameaças de disco em repouso (discos físicos, desativação e snapshots que não incluem material de desbloqueio de arranque). Para um servidor em execução aplicamos uma camada separada de controlos incorporados em cada construção NixOS: ptrace é restrito (scope=3) para prevenir inspeção de processos, kexec é desativado para que o kernel não possa ser substituído em runtime, eBPF não privilegiado é bloqueado, ponteiros do kernel são ocultados (kptr_restrict=2), userfaultfd não privilegiado é desativado, criação de io_uring não privilegiado é restrita, e coredumps são suprimidos. A desativação completa do io_uring permanece disponível para implementações de hardening especiais, mas a predefinição mantém compatibilidade com infraestrutura privilegiada. A imutabilidade do NixOS significa que nenhum gestor de pacotes pode instalar silenciosamente binários inesperados. A verificação diária de CVEs (vulnix) deteta pacotes vulneráveis e reporta resultados no painel.

Sim — cada servidor executa uma verificação diária de CVEs usando vulnix, uma ferramenta nativa do NixOS. Porque o NixOS fixa versões exatas de pacotes como hashes criptográficos (construções reproduzíveis), o vulnix pode cruzar referência de cada pacote instalado contra a Base de Dados Nacional de Vulnerabilidades em segundos. Os resultados aparecem no separador Segurança do seu painel com o nome do pacote, versão e IDs de CVE. O NixOS normalmente entrega um pacote corrigido dentro de 24–48 horas de uma divulgação de CVE — a próxima verificação diária confirma a correção. Isto é algo que a maioria das stacks auto-hospedadas não consegue fazer sem ferramentas significativas; aqui executa fora da caixa.

O modo sem contacto é a resposta completa — não mantemos chave SSH, então uma compromissão completa da nossa infraestrutura não tem caminho SSH para a sua VM. No modo Gerido, o registo de auditoria com hash encadeado regista operações do plano de controlo. Além disso, pode ativar o email opcional de resumo semanal nas suas definições de conta: resume alternâncias de serviços, resultados de atualizações NixOS e contagens de CVE nos seus servidores — dando-lhe uma confirmação regular, esperada e fácil de ler de que nada inesperado aconteceu. Qualquer anomalia nesse resumo é um sinal precoce para rever o registo de auditoria completo.

LUKS protege o sistema de ficheiros raiz encriptado se alguém obtiver acesso a um disco raiz removido ou snapshot do disco raiz sem o material de desbloqueio de arranque. O ReefOffice utiliza LUKS não assistido para que os servidores possam reiniciar automaticamente, o que significa que a partição de arranque e initrd são uma parte separada do modelo de ameaças. Uma imagem completa ao nível do fornecedor de armazenamento raiz e de arranque não é a mesma coisa que um disco raiz encriptado removido. Os caminhos restantes da VM em execução, como memória ao nível do hipervisor ou acesso em runtime, são governados por controlos, contratos e auditorias do fornecedor em vez de LUKS.

Um atacante precisaria de comprometer a VM em execução, ou obter material de arranque suficiente e acesso ao disco para desbloquear o sistema de ficheiros raiz encriptado, depois ler /etc/reefoffice/secrets.env. A chave de cópia de segurança nunca está na base de dados do plano de controlo ReefOffice. Se o seu requisito de conformidade é que a chave de cópia de segurança deve ser inacessível sob qualquer compromissão ao nível da VM, o modo Conhecimento zero remove a custódia da chave de cópia de segurança do ReefOffice após a entrega.

Na primeira ligação SSH após o provisionamento, o plano de controlo regista a chave pública de anfitrião da VM (Trust On First Use — TOFU). Cada ligação subsequente verifica se a chave corresponde a esse registo. Uma incompatibilidade — indicando que a VM foi substituída ou um MITM foi inserido — causa a falha imediata da ligação e é escrita no registo de auditoria. Isto significa que uma VM fraudulenta não pode silenciosamente intercetar tráfego de gestão mesmo que DNS ou roteamento IP seja comprometido.

O seu servidor executa na Contabo GmbH, uma empresa de hosting alemã fundada em 2003 com os seus próprios centros de dados em Munique e Nuremberga — não um revendedor. A Contabo serve mais de 225.000 clientes em 190 países em mais de 450.000 servidores, e a monitorização independente da HOSTtest registou 100% de tempo de atividade no Q3 de 2025 e Q4 de 2024. A Contabo é uma empresa registada na Alemanha (Amtsgericht München, HRB 180722).