ARDNTECH | Auto-alojamento ARDNTECH · Docker, Kubernetes, air-gap

02 / Motivações

Porquê auto-alojar um gestor de palavras-passe ?

Quatro motivações distintas levam uma organização a operar ela própria o seu cofre B2B em vez de subscrever o SaaS Cloud ARDNTECH. Todas permanecem compatíveis com uma mudança posterior em caso de evolução das limitações internas.

Controlo radical dos dados

Air-gap possível, isolamento de rede estrito, DMZ interna, ausência total de telemetria de saída. Os dados cifrados nunca saem do perímetro que define. Nenhum terceiro pode requerer o acesso à sua instância.

Conformidade setorial facilitada

Deployment num alojador já qualificado SecNumCloud, HDS, ou com as exigências NIS2 e OIV. A camada aplicacional permanece idêntica, a conformidade do alojamento é suportada pela infraestrutura da sua escolha.

Código AGPL-3.0 verificável

O repositório público cobre a totalidade do código aplicacional, até às primitivas criptográficas. OpenPGP.js v6, Argon2id, AES-256-GCM SEIPDv2, HMAC-SHA-256 : cada escolha de algoritmo é legível e auditável.

Custo de software nulo

A licença AGPL-3.0 é gratuita. Paga apenas a infraestrutura (compute, armazenamento, largura de banda) e o tempo interno de operação. Para as estruturas cuja equipa ops já está dimensionada, o TCO torna-se competitivo logo a partir de algumas dezenas de lugares ativos.

03 / Comparativo

Self-host vs SaaS Cloud ARDNTECH.

Nenhuma funcionalidade de software está reservada ao modo Cloud. O que difere é quem explora a infraestrutura e quem suporta as garantias contratuais. A tabela abaixo resume as quinze dimensões que estruturam a decisão.

Dimensão	Self-host	SaaS Cloud ARDNTECH
Código-fonte	AGPL-3.0, acesso completo, fork autorizado	AGPL-3.0, acesso completo, fork autorizado
Tarifa de software	0 €	0 € a 7 €/lugar/mês consoante o plano
Alojamento	Cliente (infra própria, IaaS da sua escolha, datacenter dedicado)	ARDNTECH (alojador soberano europeu)
Setup inicial	A cargo do cliente (Docker Compose ou Kubernetes)	Incluído, automatizado (provisioning em alguns minutos)
Manutenção OS e runtime	A cargo do cliente	Incluído
Backups	A cargo do cliente (procedimento documentado)	Incluído, snapshots diários cifrados
Atualizações	A cargo do cliente (imagem Docker etiquetada, plano de upgrade fornecido)	Incluído, janela de manutenção anunciada
SLA de disponibilidade	Nenhum (o cliente opera a sua infra)	Best effort (Free), 99,5 % (Business), negociado (Enterprise)
Suporte	Comunitário (fórum, issues GitHub)	Comunitário + e-mail em D+1 útil (Business) + telefone (Enterprise)
Multi-organização	Sim (conta-pivô, RBAC granular)	Sim (conta-pivô, RBAC granular)
DPA	Não aplicável (o cliente é responsável pelo tratamento)	DPA padronizado (Business) ou negociado (Enterprise)
Conformidade	A cargo do cliente	Alojador qualificado, trajetória SecNumCloud visada
Alvo típico	Gabinetes de cibersegurança com ops maduras, OIV, organizações que já têm uma equipa ops dimensionada	Microempresas, PME, ETI, gabinetes sem equipa ops dedicada, estruturas que preferem pagar para não operar
Custo total de posse	Variável : 0 € de licença + tempo interno + infra	Previsível : subscrição por lugar, tudo incluído
Air-gap	Suportado (nenhuma telemetria de saída por defeito)	Não aplicável (instância operada por ARDNTECH)

Leitura da tabela. Para uma equipa de menos de cinquenta lugares ativos sem equipa ops dedicada, o SaaS Cloud é frequentemente a escolha racional. Para além disso, ou se a soberania da infra é uma exigência regulamentar ou contratual, o self-host torna-se pertinente. As duas migrações estão previstas e documentadas.

04 / Pré-requisitos

Pré-requisitos técnicos.

Três pré-requisitos apenas, todos padrão num ambiente de servidor moderno. Nenhum serviço terceiro obrigatório na execução, nenhuma porta de saída não padrão, nenhum protocolo proprietário.

Servidor Linux e runtime de contentor

Um servidor Linux x86_64 ou ARM64 com Docker 24 ou superior e Docker Compose v2. Debian, Ubuntu LTS, Red Hat Enterprise Linux e os seus derivados são testados continuamente. O runtime de contentor funciona tanto em máquina virtual dedicada como em Kubernetes gerido.

Dimensionamento

2 vCPU e 4 GB de RAM bastam para cinquenta utilizadores ativos. Para quinhentos utilizadores, prever 8 vCPU e 16 GB de RAM. O armazenamento depende do número de segredos : conte cerca de 100 MB de base por milhar de segredos, mais a retenção dos logs de auditoria consoante o seu plano.

Nome de domínio e certificado TLS

Um nome de domínio e um certificado TLS válido. Let's Encrypt está documentado e funciona sem configuração específica. Nenhuma porta de saída não padrão é necessária. Um deployment air-gap é possível sem modificação do código aplicacional : a instância não consulta nenhum serviço externo em runtime.

05 / Instalação

Instalação em cinco minutos.

Três variantes de deployment suportadas, do POC de gabinete independente à produção multi-AZ de um operador de importância vital. O mesmo código, três orquestrações.

Variante 1 - Docker Compose

Recomendado para os POC, as pequenas equipas e os ambientes de desenvolvimento. Uma única máquina, persistência local ou volume de rede, deployment num só comando.

git clone https://github.com/aegirex/aegirex.git
cd aegirex
make install
# gera os secrets, faz build da imagem a partir do Dockerfile do repo,
# aplica as migrações e arranca todos os serviços.
# A instância está disponível em http://localhost:8280

Build a partir da fonte por defeito. O que corre em produção é exatamente o que se encontra em git log : sem caixa negra de registry, sem dependência de uma conta Docker Hub terceira. Os ficheiros composer.lock e importmap.lock fixam as versões e impressões digitais SHA das dependências ; um Packagist ou um CDN comprometido quebraria o build em vez de introduzir silenciosamente um payload. Para os ops apressados, uma variante make install-from-registry faz pull da imagem pré-construída assinada pela nossa CI.

Variante 2 - Kubernetes

Recomendado em produção, em cluster gerido ou self-managed. Manifestos oficiais e chart Helm fornecidos. Compatível com os clusters Kubernetes dos operadores qualificados SecNumCloud (OVHcloud, Outscale, Cloud Temple, NumSpot).

helm repo add aegirex https://charts.aegirex.eu
helm repo update
helm install aegirex aegirex/aegirex \
  --namespace aegirex --create-namespace \
  --values values.production.yaml
kubectl -n aegirex rollout status deployment/aegirex-app
kubectl -n aegirex exec deploy/aegirex-app -- bin/console doctrine:migrations:migrate

Variante 3 - Air-gap

Recomendado para os ambientes de soberania radical : OIV, defesa, investigação classificada. Nenhuma ligação de saída, backups manuais, atualizações via registo espelho interno.

# em posto ligado
docker pull ghcr.io/aegirex/aegirex:v1.4.2
docker save ghcr.io/aegirex/aegirex:v1.4.2 -o aegirex-v1.4.2.tar
# transferência física para a rede air-gap (USB selado, díodo de rede)
# em instância air-gap
docker load -i aegirex-v1.4.2.tar
docker tag ghcr.io/aegirex/aegirex:v1.4.2 registry.internal/aegirex:v1.4.2
docker compose -f docker-compose.airgap.yml up -d
bin/console doctrine:migrations:migrate

06 / Arquitetura

Arquitetura técnica da stack.

Uma stack PHP moderna, sem SPA, sem npm, sem dependência runtime de um serviço terceiro. Cada bloco está documentado e é auditável independentemente.

Backend

PHP 8.4, Symfony 7.4, Doctrine ORM 3, MariaDB 11. FPM ou FrankenPHP à escolha. Nenhuma extensão PHP proprietária. Migrações Doctrine versionadas, rollback testado.

Frontend

Twig no servidor + Stimulus no cliente. AssetMapper para a entrega (sem npm, sem bundler terceiro). CSS custom modular. Sem SPA, sem framework JavaScript proprietário.

Criptografia no lado cliente

OpenPGP.js v6 com X25519, Ed25519 e AES-256-GCM SEIPDv2. Derivação Argon2id da palavra-passe mestra (RFC 9106, 5 passes, 256 MiB, paralelismo 4). As chaves privadas nunca saem do navegador.

Audit chain HMAC-SHA-256

Cadeia de auditoria selada e encadeada criptograficamente por HMAC-SHA-256. Verificação independente por um comando CLI público de controlo da cadeia. Deteção de qualquer tentativa de falsificação retroativa, oponível ao juiz como ao RSSI.

Autenticação

Symfony Security + scheb/2fa-bundle : e-mail, TOTP (RFC 6238), códigos de recuperação. SSO SAML 2.0 e OIDC (RFC 6749 e RFC 7519). Passkeys WebAuthn (W3C WebAuthn Level 2) em opção.

Armazenamento e fila de espera

Tudo em MariaDB 11 : esquema relacional, blobs limitados a 1 MB. Nenhum armazenamento de objetos externo necessário. Fila de espera via Symfony Messenger + transport Doctrine, sem dependência Redis para a V1.

07 / Operações

Backups, manutenção, atualizações.

Três procedimentos industrializados e documentados. O modo self-host transfere a responsabilidade operacional para o cliente, sem fazer dela um fardo : os comandos são scriptáveis, idempotentes e testados em integração contínua.

Backup cifrado

Um comando CLI de backup produz um ficheiro exportável cifrado no formato OpenPGP, com rotação automática. O destinatário do backup é configurável (chave de arquivo organizacional). A restauração está documentada e testada a cada release.

Atualizações blue-green sem downtime

Imagem Docker etiquetada em semantic versioning em ghcr.io/aegirex/aegirex. Todas as migrações Doctrine estão estruturadas em três etapas (ADD nullable, backfill, ALTER NOT NULL) para permitir um deployment blue-green sem interrupção de serviço mesmo em bases de dados volumosas. As alterações breaking são anunciadas com pelo menos uma versão menor de antecedência.

Rollback em menos de cinco minutos

A combinação snapshot de base de dados mais imagem Docker anterior permite um rollback em menos de cinco minutos. As migrações Doctrine fornecem o seu método down() testado. Nenhuma intervenção manual no esquema SQL é necessária.

Worker assíncrono resiliente

Os e-mails de saída e os webhooks de auditoria são despachados de forma assíncrona via Symfony Messenger. Se um prestador externo falhar (e-mail, webhook destinatário), os pedidos HTTP nunca são bloqueados : os jobs são repetidos com backoff exponencial, depois armazenados em fila persistente se a falha persistir. O worker corre em serviço systemd ou contentor dedicado, reinício automático sem perda.

Endpoints de saúde prontos para LB e Kubernetes

GET /health em público para as sondas de liveness (load balancer, UptimeRobot, sondas Kubernetes). GET /health/deep protegido por uma allowlist de endereços IP, para os controlos aprofundados a partir da sua stack de monitoring interna (ping base de dados, cache, fila de espera). Nenhuma informação sensível exposta.

07bis / Observabilidade soberana

Uma stack de monitoring 100 % europeia.

A soberania não se fica pelo alojador aplicacional. A ARDNTECH emite os seus logs no formato JSON estruturado e expõe métricas Prometheus padrão, para se integrar numa stack de observabilidade inteiramente europeia ou self-hosted. Nenhum SDK proprietário obrigatório, nenhuma telemetria de saída por defeito.

Tracking de erros soberano

Compatível com Bugsink (Países Baixos, MIT, self-hostable na sua instância SecNumCloud), GlitchTip (EUA, MIT, self-hostable) ou Sentry self-host. O SDK Sentry padrão do Symfony é compatível com estes três backends sem modificação de código. Os seus erros nunca saem da sua infraestrutura.

Logs e métricas geridos em França

Logs JSON ingeríveis por Loki + Grafana self-hosted, OVHcloud Logs Data Platform (Graylog gerido, França) ou Scaleway Cockpit (Loki, Mimir, Tempo geridos, França). Métricas Prometheus exponíveis num endpoint dedicado, restringido por allowlist de endereços IP.

Verificação de integridade diária

Um comando CLI público permite verificar a integridade da cadeia de auditoria HMAC-SHA-256. Agendável em cron diário, desencadeia um alerta (PagerDuty, webhook interno, Slack soberano) se a cadeia estiver corrompida. Qualquer alteração retroativa do registo é detetada em O(1), sem depender de um binário externo.

Geolocalização IP local (soberana UE)

Os e-mails « Nova ligação detetada » são enriquecidos com o país e a cidade graças à base DB-IP Lite (editor belga, licença CC-BY 4.0), resolvida localmente na sua instância : o endereço IP do utilizador nunca é transmitido a um serviço terceiro. A base é atualizada automaticamente todos os meses por cron.

08 / Conformidade

Conformidade setorial facilitada.

O modo self-host permite-lhe portar a conformidade ao nível do alojador que escolheu. Quatro regimes correntes estão documentados abaixo, sem comprometer ARDNTECH para além do código aplicacional sob AGPL-3.0.

SecNumCloud

Implementável em OVHcloud Hosted Private Cloud, Outscale 3DS, Cloud Temple ou NumSpot, operadores qualificados pela ANSSI. A trajetória SecNumCloud permanece um objetivo visado para o SaaS Cloud ARDNTECH ; em self-host, a qualificação efetiva depende do seu alojador.

HDS · saúde

Implementável num alojador certificado HDS para os operadores de saúde. O código aplicacional inscreve-se na cadeia HDS de ponta a ponta desde que a infraestrutura subjacente esteja qualificada. O audit log de longa duração está disponível nativamente.

OIV e NIS2

Deployment air-gap suportado. Código AGPL-3.0 auditável pelo seu RSSI, até às primitivas criptográficas. A audit chain HMAC-SHA-256 produz uma rastreabilidade oponível às autoridades de controlo setoriais.

RGPD

Em modo self-host, permanece o único responsável pelo tratamento. Nenhum subcontratante ARDNTECH intervém no caminho dos dados. ARDNTECH nunca é subcontratante no sentido do RGPD : a relação limita-se à disponibilização do código-fonte AGPL-3.0.

09 / Alvos

Casos de uso típicos.

Três perfis de organizações escolhem frequentemente o modo self-host. O ponto comum : uma equipa ops Linux já dimensionada e capaz de operar um serviço Symfony com base relacional em produção.

Perfil 1

Gabinetes de cibersegurança com operações maduras

ESN de segurança, gabinetes de consultoria em cibersegurança, equipas de pentest internalizadas. Operam já um SI reforçado, dispõem de uma equipa ops sénior e querem aplicar internamente os critérios que auditam nos seus clientes. O self-host permite-lhes provar a coerência entre discurso e ferramentas.

Perfil 2

Setor público de soberania radical

Autarquias, agências, operadores essenciais no sentido NIS2, organizações sob tutela. Política interna de recusa de qualquer SaaS, mesmo francês qualificado. O self-host garante que o dado cifrado e a sua audit chain permanecem estritamente dentro do perímetro administrativo desejado.

Perfil 3

ESN integradoras e revendedoras geridas

ESN que revendem aos seus próprios clientes uma instância ARDNTECH gerida por si. O modo self-host torna-se um bloco da sua oferta comercial : operam a plataforma, faturam aos seus clientes, e conservam a relação. A licença AGPL-3.0 autoriza expressamente este uso comercial.

10 / FAQ técnica

Perguntas frequentes das equipas ops.

Oito perguntas recorrentes colocadas pelos RSSI e pelas equipas DevOps durante a avaliação do modo self-host. Se faltar a sua, escreva-nos.

O código é mesmo idêntico entre Self-host e Cloud ?

Sim. O repositório aegirex/aegirex contém a totalidade do código aplicacional sob AGPL-3.0. Nenhuma funcionalidade Team, Business ou Enterprise está reservada ao modo Cloud. As únicas diferenças prendem-se com a configuração runtime (variáveis de ambiente, secrets ANSSI-track, parametrização do alojador) e com a ligação da instância Cloud à infraestrutura de supervisão e de faturação explorada por ARDNTECH. Nenhum módulo de software proprietário é acrescentado no lado Cloud.

Como migrar o meu self-host para o SaaS Cloud (e inversamente) ?

A migração assenta na exportação completa do cofre via as ferramentas integradas (exportação JSON decifrada no lado do utilizador, em conformidade com os artigos RGPD 17 e 20) e na importação para uma organização de destino nova. A migração não preserva o histórico de auditoria tal como está : a audit chain recomeça à data de importação, o registo de origem é conservado em arquivo descarregável. A rotação das chaves HMAC de auditoria no lado da instância de destino inicia uma nova cadeia. Sendo o código idêntico, a compatibilidade de esquema está garantida.

Qual é o custo total anual típico de um self-host (infra + ops) ?

A licença de software AGPL-3.0 é gratuita. Para um gabinete de trinta pessoas com três servidores Linux internos, conte tipicamente 50 a 150 € por mês de alojador soberano para o compute e o armazenamento, mais 500 a 2 000 € por mês de custo operacional marginal (0,1 a 0,3 ETI para atualizações, backups e supervisão). O self-host torna-se economicamente interessante a partir de efetivos em que o custo ops marginal se torna negligenciável e em que a equipa ops já está dimensionada. Abaixo de cinquenta lugares ativos, o Cloud é muitas vezes a escolha racional, salvo exigência estrita de soberania de infraestrutura.

Como integrar o SSO LDAP, Keycloak ou Authentik ?

O bundle Symfony Security expõe SAML 2.0 e OpenID Connect. A configuração faz-se via variáveis de ambiente, sem recompilação. Um conetor OIDC válido para Keycloak, Authentik ou qualquer fornecedor conforme à RFC 6749 e RFC 7519. Para LDAP, o binding direto está documentado com mapeamento dos grupos para os papéis RBAC. O SCIM 2.0 (RFC 7644) está disponível em Business para o provisioning automatizado.

A ARDNTECH corre em Kubernetes gerido (EKS, GKE, AKS, Kapsule) ?

Sim, o deployment Kubernetes está documentado para as distribuições padrão. Os manifestos incluem os Deployment, Service, Ingress, PersistentVolumeClaim e ConfigMap necessários. Um chart Helm oficial é fornecido com valores por defeito adaptados aos clusters geridos. Para a soberania dos dados, o uso de Kubernetes gerido num operador qualificado SecNumCloud (OVHcloud, Outscale, Cloud Temple, NumSpot) é recomendado ; os clusters geridos extra-europeus permanecem tecnicamente compatíveis mas saem do quadro das preconizações soberanas.

Que monitoring recomendado (Prometheus, OpenTelemetry, ELK) ?

A instância expõe métricas compatíveis Prometheus num endpoint dedicado, e emite traces OpenTelemetry nos pedidos críticos. Os logs aplicacionais são emitidos no formato JSON estruturado, ingeríveis diretamente por ELK, Loki ou qualquer coletor Syslog padrão. Os eventos de auditoria são exportáveis nos formatos CEF, LEEF e OCSF para os SIEM Splunk, Elastic, QRadar e Microsoft Sentinel. Nenhuma telemetria é enviada para um serviço terceiro por defeito.

Qual é o plano de suporte comunitário vs pago ?

O suporte comunitário passa pelo fórum público e pelas issues GitHub : sem compromisso de prazo, animado pelos contribuidores e pela equipa ARDNTECH. Um acompanhamento pago está disponível para as organizações que desejem um deployment auditado, uma integração SSO complexa, uma implementação de cluster de alta disponibilidade ou uma revisão de arquitetura antes da entrada em produção. Nenhum SLA está associado ao modo self-host : por construção, é o cliente que opera a infraestrutura.

Como mudar para air-gap após uma instalação padrão ?

O air-gap consiste em suprimir qualquer conectividade de saída da instância ARDNTECH. Os pré-requisitos são : um registo Docker espelho interno para as atualizações de imagens, um repositório de pacotes espelho para as dependências OS, um canal manual de exportação e importação dos backups cifrados. Não sendo emitida nenhuma telemetria por defeito, a própria aplicação não tem qualquer dependência runtime de um serviço externo. Os webhooks de saída podem ser desativados por configuração, ou encaminhados para um relé interno. O procedimento completo está documentado no guia air-gap do repositório.

11 / Para ir mais longe

O modo self-host inscreve-se numa arquitetura de produto coerente com as outras páginas de referência do site. Os recursos abaixo detalham cada um um aspeto particular.

Segurança e criptografia

O whitepaper criptográfico detalhado : OpenPGP.js v6, Argon2id, AES-256-GCM SEIPDv2, HMAC-SHA-256.

Setores de atividade

As cinco verticais B2B prioritárias : ESN de segurança, advogados, saúde, defesa, energia e OIV.

Confiança e transparência

Estatuto jurídico de ARDNTECH, jurisdição, cadeia de subcontratação, DPA padronizado.

Planos e tarifação SaaS

Comparativo Free, Team, Business, Enterprise para o SaaS Cloud ; lembrete da gratuitidade do software em self-host.

Cofre alojado em França

Detalhe da escolha de alojamento em Paris para o SaaS, alternativa ao self-host para as equipas sem ops dedicada.

Alternativa ao Cloud Act

Porque é que um editor de direito francês fora de jurisdição extra-europeia muda a grelha de análise RSSI.

12 / Começar

Self-host ARDNTECH,
a sua infraestrutura, o seu perímetro.

Leia a documentação técnica completa no GitHub ou peça um acompanhamento auditado para um deployment em produção. Sem contacto comercial agressivo : uma troca técnica sobre a pertinência da solução no seu contexto.

Ler a doc técnica Pedir um acompanhamento auditado

Código AGPL-3.0, acesso completo, fork autorizado

Docker Compose em menos de cinco minutos

Kubernetes gerido num operador qualificado SecNumCloud

Air-gap suportado, nenhuma telemetria de saída

Audit chain HMAC-SHA-256 verificável independentemente

Auto-alojamento ARDNTECHlivre, completo, documentado.