Solidarita s Ukrajinou. Služba nabízena ukrajinským firmám po dobu trvání války. Požádat o bezplatný přístup
01 / Nasazení · Self-hosting

Self-hosting ARDNTECH
svobodný, kompletní, zdokumentovaný.

ARDNTECH je dodáván pod jediným zdrojovým kódem AGPL-3.0, spustitelným jak na infrastruktuře ARDNTECH, tak na vaší. Režim self-host pokrývá veškeré funkce Team, Business a Enterprise bez omezení : granulární RBAC, SCIM 2.0, SSO SAML 2.0 a OIDC, dlouhodobý auditní log. Provozujete svou instanci v datacentru dle vašeho výběru, v Docker Compose, v managed Kubernetes u provozovatele kvalifikovaného SecNumCloud nebo ve striktním air-gap nasazení.

AGPL-3.0 Docker Compose Kubernetes Air-gap podporováno Žádná odchozí telemetrie
02 / Motivace

Proč provozovat na vlastní infrastruktuře správce hesel ?

Čtyři odlišné motivace vedou organizaci k tomu, aby svůj trezor B2B provozovala sama, místo aby si předplatila SaaS Cloud ARDNTECH. Všechny zůstávají kompatibilní s pozdějším přechodem v případě vývoje interních omezení.

Radikální kontrola dat

Air-gap možný, striktní síťová izolace, interní DMZ, úplná absence odchozí telemetrie. Šifrovaná data nikdy neopustí perimetr, který definujete. Žádná třetí strana nemůže vyžádat přístup k vaší instanci.

Usnadněný odvětvový soulad

Nasazení u hostitele již kvalifikovaného SecNumCloud, HDS, nebo s požadavky NIS2 a OIV. Aplikační vrstva zůstává identická, soulad hostingu je nesen infrastrukturou dle vašeho výběru.

Ověřitelný kód AGPL-3.0

Veřejný repozitář pokrývá celý aplikační kód, až po kryptografická primitiva. OpenPGP.js v6, Argon2id, AES-256-GCM SEIPDv2, HMAC-SHA-256 : každá volba algoritmu je čitelná a auditovatelná.

Nulové softwarové náklady

Licence AGPL-3.0 je zdarma. Platíte pouze za infrastrukturu (compute, úložiště, šířka pásma) a interní provozní čas. Pro struktury s již dimenzovaným ops týmem se TCO stává konkurenceschopným již od několika desítek aktivních míst.

03 / Srovnání

Self-host vs SaaS Cloud ARDNTECH.

Žádná softwarová funkce není vyhrazena režimu Cloud. Co se liší, je kdo provozuje infrastrukturu a kdo nese smluvní záruky. Tabulka níže shrnuje patnáct dimenzí, které strukturují rozhodnutí.

Dimenze Self-host SaaS Cloud ARDNTECH
Zdrojový kód AGPL-3.0, úplný přístup, fork povolen AGPL-3.0, úplný přístup, fork povolen
Cena softwaru 0 € 0 € až 7 €/místo/měsíc podle plánu
Hosting Zákazník (vlastní infrastruktura, IaaS dle výběru, vyhrazený datacentrum) ARDNTECH (evropský suverénní hostitel)
Počáteční setup Na odpovědnost zákazníka (Docker Compose nebo Kubernetes) Zahrnuto, automatizováno (provisioning během několika minut)
Údržba OS a runtime Na odpovědnost zákazníka Zahrnuto
Zálohy Na odpovědnost zákazníka (zdokumentovaný postup) Zahrnuto, denní šifrované snapshoty
Aktualizace Na odpovědnost zákazníka (tagovaný Docker image, poskytnut plán upgradu) Zahrnuto, oznámené okno údržby
SLA dostupnosti Žádné (zákazník provozuje svou infrastrukturu) Best effort (Free), 99,5 % (Business), vyjednané (Enterprise)
Podpora Komunitní (fórum, issues GitHub) Komunitní + e-mail do následujícího pracovního dne (Business) + telefon (Enterprise)
Multi-organizace Ano (pivotní účet, granulární RBAC) Ano (pivotní účet, granulární RBAC)
DPA Nepoužije se (zákazník je správcem zpracování) Standardizované DPA (Business) nebo vyjednané (Enterprise)
Soulad Na odpovědnost zákazníka Kvalifikovaný hostitel, cílená trajektorie SecNumCloud
Typický cíl firmy kybernetické bezpečnosti s vyzrálým ops, OIV, organizace již s dimenzovaným ops týmem mikropodniky, MSP, střední podniky, firmy bez vyhrazeného ops týmu, struktury preferující platit za to, aby neprovozovaly
Celkové náklady na vlastnictví Variabilní : 0 € licence + interní čas + infrastruktura Předvídatelné : předplatné za místo, vše zahrnuto
Air-gap Podporováno (žádná odchozí telemetrie ve výchozím nastavení) Nepoužije se (instance provozovaná společností ARDNTECH)

Čtení tabulky. Pro tým s méně než padesáti aktivními místy bez vyhrazeného ops týmu je SaaS Cloud často racionální volbou. Nad tento limit, nebo pokud je infrastrukturní suverenita regulatorním nebo smluvním požadavkem, se self-host stává relevantním. Obě migrace jsou plánovány a zdokumentovány.

04 / Požadavky

Technické požadavky.

Pouze tři požadavky, všechny standardní v moderním serverovém prostředí. Žádná povinná třetí služba za běhu, žádný nestandardní odchozí port, žádný proprietární protokol.

Linux server a container runtime

Linux server x86_64 nebo ARM64 s Dockerem 24 nebo vyšším a Docker Compose v2. Debian, Ubuntu LTS, Red Hat Enterprise Linux a jejich deriváty jsou kontinuálně testovány. Container runtime funguje stejně dobře na vyhrazeném virtuálním stroji jako na managed Kubernetes.

Dimenzování

2 vCPU a 4 GB RAM stačí pro padesát aktivních uživatelů. Pro pět set uživatelů počítejte s 8 vCPU a 16 GB RAM. Úložiště závisí na počtu tajných údajů : počítejte přibližně 100 MB základu na tisíc tajných údajů, plus retence auditních logů podle vašeho plánu.

Doménové jméno a TLS certifikát

Doménové jméno a platný TLS certifikát. Let's Encrypt je zdokumentován a funguje bez specifické konfigurace. Není vyžadován žádný nestandardní odchozí port. Air-gap nasazení je možné bez úpravy aplikačního kódu : instance za běhu nekonzultuje žádnou externí službu.

05 / Instalace

Instalace za pět minut.

Tři podporované varianty nasazení, od POC nezávislé firmy po multi-AZ produkci provozovatele zásadní důležitosti. Stejný kód, tři orchestrace.

Varianta 1 - Docker Compose

Doporučeno pro POC, malé týmy a vývojová prostředí. Jediný stroj, lokální perzistence nebo síťový volume, nasazení jediným příkazem.

git clone https://github.com/aegirex/aegirex.git
cd aegirex
make install
# vygeneruje secrets, sestaví image z Dockerfile repozitáře,
# aplikuje migrace a spustí všechny služby.
# Instance je dostupná na http://localhost:8280

Build ze zdroje ve výchozím nastavení. To, co běží v produkci, je přesně to, co se nachází v git log : žádná černá skříňka registry, žádná závislost na třetím Docker Hub účtu. Soubory composer.lock a importmap.lock připínají verze a SHA otisky závislostí ; kompromitovaný Packagist nebo CDN by rozbil build místo toho, aby tiše zavedl payload. Pro spěchající ops varianta make install-from-registry stáhne předem sestavený image podepsaný naší CI.

Varianta 2 - Kubernetes

Doporučeno v produkci, na managed nebo self-managed clusteru. Poskytnuty oficiální manifesty a Helm chart. Kompatibilní s Kubernetes clustery provozovatelů kvalifikovaných 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

Varianta 3 - Air-gap

Doporučeno pro prostředí s radikální suverenitou : OIV, obrana, klasifikovaný výzkum. Žádné odchozí připojení, ruční zálohy, aktualizace přes interní zrcadlový registr.

# na připojené stanici
docker pull ghcr.io/aegirex/aegirex:v1.4.2
docker save ghcr.io/aegirex/aegirex:v1.4.2 -o aegirex-v1.4.2.tar
# fyzický přenos do air-gap sítě (zapečetěné USB, síťová dioda)
# na air-gap instanci
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 / Architektura

Technická architektura stacku.

Moderní PHP stack, bez SPA, bez npm, bez runtime závislosti na třetí službě. Každý stavební blok je zdokumentován a nezávisle auditovatelný.

Backend

PHP 8.4, Symfony 7.4, Doctrine ORM 3, MariaDB 11. FPM nebo FrankenPHP dle výběru. Žádné proprietární PHP rozšíření. Verzované migrace Doctrine, testovaný rollback.

Frontend

Twig na straně serveru + Stimulus na straně klienta. AssetMapper pro doručování (žádné npm, žádný třetí bundler). Modulární custom CSS. Žádná SPA, žádný proprietární JavaScript framework.

Kryptografie na straně klienta

OpenPGP.js v6 s X25519, Ed25519 a AES-256-GCM SEIPDv2. Odvození Argon2id z hlavního hesla (RFC 9106, 5 průchodů, 256 MiB, parallelism 4). Soukromé klíče nikdy neopustí prohlížeč.

Audit chain HMAC-SHA-256

Audit chain zapečetěný a kryptograficky zřetězený pomocí HMAC-SHA-256. Nezávislé ověření veřejným CLI příkazem pro kontrolu řetězce. Detekce jakéhokoli pokusu o zpětné padělání, vymahatelná vůči soudci i CISO.

Autentizace

Symfony Security + scheb/2fa-bundle : e-mail, TOTP (RFC 6238), záložní kódy. SSO SAML 2.0 a OIDC (RFC 6749 a RFC 7519). Passkeys WebAuthn (W3C WebAuthn Level 2) volitelně.

Úložiště a fronta

Vše v MariaDB 11 : relační schéma, bloby omezené na 1 MB. Není vyžadováno žádné externí objektové úložiště. Fronta přes Symfony Messenger + Doctrine transport, bez závislosti Redis pro V1.

07 / Operace

Zálohy, údržba, aktualizace.

Tři industrializované a zdokumentované postupy. Režim self-host přenáší provozní odpovědnost na zákazníka, aniž by z toho dělal břemeno : příkazy jsou skriptovatelné, idempotentní a testované v kontinuální integraci.

Šifrovaná záloha

Záložní CLI příkaz produkuje stažitelný soubor zašifrovaný ve formátu OpenPGP, s automatickou rotací. Příjemce zálohy je konfigurovatelný (organizační archivační klíč). Obnovení je zdokumentováno a testováno při každém release.

Blue-green aktualizace bez downtime

Docker image tagovaný semantic versioningem na ghcr.io/aegirex/aegirex. Všechny migrace Doctrine jsou strukturovány do tří kroků (ADD nullable, backfill, ALTER NOT NULL), aby umožnily blue-green nasazení bez přerušení služby i na objemných databázích. Breaking změny jsou oznámeny nejméně jednu minor verzi předem.

Rollback za méně než pět minut

Kombinace snapshotu databáze plus předchozího Docker image umožňuje návrat zpět za méně než pět minut. Migrace Doctrine poskytují svou testovanou metodu down(). Není vyžadován žádný ruční zásah do SQL schématu.

Odolný asynchronní worker

Odchozí e-maily a auditní webhooky jsou dispatchovány asynchronně přes Symfony Messenger. Pokud externí poskytovatel vypadne (e-mail, příjemce webhooku), HTTP požadavky nejsou nikdy blokovány : úlohy jsou opakovány s exponenciálním backoffem a poté uloženy do perzistentní fronty, pokud selhání přetrvává. Worker běží jako systemd služba nebo vyhrazený kontejner, automatický restart bez ztráty.

Health endpointy připravené pro LB a Kubernetes

GET /health veřejně pro liveness sondy (load balancer, UptimeRobot, Kubernetes sondy). GET /health/deep chráněný allowlistem IP adres, pro hloubkové kontroly z vašeho interního monitorovacího stacku (ping databáze, cache, fronta). Žádná citlivá informace není vystavena.

07bis / Suverénní observabilita

Monitorovací stack 100 % evropský.

Suverenita nekončí u aplikačního hostitele. ARDNTECH vysílá své logy ve strukturovaném JSON formátu a vystavuje standardní metriky Prometheus, aby se integroval do plně evropského nebo self-hostovaného observabilního stacku. Žádné povinné proprietární SDK, žádná odchozí telemetrie ve výchozím nastavení.

Suverénní tracking chyb

Kompatibilní s Bugsink (Nizozemsko, MIT, self-hostovatelný na vaší instanci SecNumCloud), GlitchTip (US, MIT, self-hostovatelný) nebo Sentry self-host. Standardní Sentry SDK Symfony je kompatibilní se všemi třemi backendy bez úpravy kódu. Vaše chyby nikdy neopustí vaši infrastrukturu.

Managed logy a metriky ve Francii

JSON logy ingestovatelné Loki + Grafana self-hostovanými, OVHcloud Logs Data Platform (managed Graylog, Francie) nebo Scaleway Cockpit (managed Loki, Mimir, Tempo, Francie). Metriky Prometheus vystavitelné na vyhrazeném endpointu, omezeném allowlistem IP adres.

Denní kontrola integrity

Veřejný CLI příkaz umožňuje ověřit integritu audit chain HMAC-SHA-256. Plánovatelný v denním cronu spustí upozornění (PagerDuty, interní webhook, suverénní Slack), pokud je řetězec poškozen. Jakékoli zpětné pozměnění záznamu je detekováno v O(1), bez závislosti na externím binárním souboru.

Lokální IP geolokalizace (suverénní EU)

E-maily „Zjištěno nové připojení“ jsou obohaceny o zemi a město díky databázi DB-IP Lite (belgický vydavatel, licence CC-BY 4.0), rozlišené lokálně na vaší instanci : IP adresa uživatele se nikdy nepřenáší ke třetí službě. Databáze je automaticky obnovována každý měsíc cronem.

08 / Soulad

Odvětvový soulad usnadněný.

Režim self-host vám umožňuje přenést soulad na úroveň hostitele, kterého jste si vybrali. Čtyři běžné režimy jsou zdokumentovány níže, aniž by zavazovaly ARDNTECH nad rámec aplikačního kódu pod AGPL-3.0.

SecNumCloud

Nasaditelné u OVHcloud Hosted Private Cloud, Outscale 3DS, Cloud Temple nebo NumSpot, provozovatelů kvalifikovaných ANSSI. Trajektorie SecNumCloud zůstává cílem pro SaaS Cloud ARDNTECH ; v self-hostu závisí efektivní kvalifikace na vašem hostiteli.

HDS · zdravotnictví

Nasaditelné u hostitele certifikovaného HDS pro provozovatele zdravotnictví. Aplikační kód zapadá do řetězce HDS od začátku do konce, jakmile je podkladová infrastruktura kvalifikovaná. Dlouhodobý auditní log je k dispozici nativně.

OIV a NIS2

Air-gap nasazení podporováno. Kód AGPL-3.0 auditovatelný vaším CISO, až po kryptografická primitiva. Audit chain HMAC-SHA-256 produkuje sledovatelnost vymahatelnou vůči odvětvovým dozorovým orgánům.

GDPR

V režimu self-host zůstáváte jediným správcem zpracování. Žádný zpracovatel ARDNTECH nezasahuje do cesty dat. ARDNTECH není nikdy zpracovatelem ve smyslu GDPR : vztah se omezuje na poskytnutí zdrojového kódu AGPL-3.0.

09 / Cíle

Typické případy užití.

Tři profily organizací často volí režim self-host. Společný bod : již dimenzovaný Linux ops tým schopný provozovat Symfony službu s relační databází v produkci.

Profil 1

Firmy kybernetické bezpečnosti s vyzrálými operacemi

ESN bezpečnost, poradenské firmy kybernetické bezpečnosti, internalizované pentest týmy. Provozují již zpřísněný IS, disponují seniorním ops týmem a chtějí interně aplikovat kritéria, která auditují u svých zákazníků. Self-host jim umožňuje prokázat soulad mezi proslovem a nástroji.

Profil 2

Veřejný sektor s radikální suverenitou

Samosprávy, agentury, základní provozovatelé ve smyslu NIS2, organizace pod dohledem. Interní politika odmítání jakéhokoli SaaS, i francouzského kvalifikovaného. Self-host zaručuje, že šifrovaná data a jejich audit chain zůstávají striktně v požadovaném administrativním perimetru.

Profil 3

ESN integrátoři a managed prodejci

ESN, které dále prodávají svým vlastním zákazníkům instanci ARDNTECH managovanou jimi samotnými. Režim self-host se stává stavebním blokem jejich obchodní nabídky : provozují platformu, fakturují svým zákazníkům a zachovávají si vztah. Licence AGPL-3.0 výslovně povoluje toto komerční použití.

10 / Technická FAQ

Časté otázky ops týmů.

Osm opakujících se otázek kladených CISO a DevOps týmy při hodnocení režimu self-host. Pokud ta vaše chybí, napište nám.

Je kód opravdu identický mezi Self-host a Cloud ?

Ano. Repozitář aegirex/aegirex obsahuje celý aplikační kód pod AGPL-3.0. Žádná funkce Team, Business nebo Enterprise není vyhrazena režimu Cloud. Jediné rozdíly spočívají v runtime konfiguraci (proměnné prostředí, secrets ANSSI-track, nastavení hostitele) a v napojení Cloud instance na infrastrukturu dohledu a fakturace provozovanou společností ARDNTECH. Žádný proprietární softwarový modul není přidán na straně Cloud.

Jak migrovat můj self-host na SaaS Cloud (a naopak) ?

Migrace spočívá na úplném exportu trezoru pomocí integrovaných nástrojů (JSON export dešifrovaný na straně uživatele, v souladu s články GDPR 17 a 20) a importu do čerstvé cílové organizace. Migrace nezachovává historii auditu v původním stavu : audit chain se restartuje k datu importu, zdrojový záznam je uchován ve stažitelném archivu. Rotace klíčů HMAC auditu na straně cílové instance zahajuje nový řetězec. Protože je kód identický, je kompatibilita schématu zaručena.

Jaké jsou typické celkové roční náklady self-hostu (infrastruktura + ops) ?

Softwarová licence AGPL-3.0 je zdarma. Pro firmu o třiceti lidech se třemi interními Linux servery počítejte typicky 50 až 150 € měsíčně za suverénního hostitele za compute a úložiště, plus 500 až 2 000 € měsíčně marginálních provozních nákladů (0,1 až 0,3 FTE na aktualizace, zálohy a dohled). Self-host se stává ekonomicky zajímavým od počtu zaměstnanců, kde se marginální ops náklady stanou zanedbatelnými a kde je ops tým již dimenzován. Pod padesáti aktivními místy je Cloud velmi často racionální volbou, kromě striktního požadavku na infrastrukturní suverenitu.

Jak integrovat SSO LDAP, Keycloak nebo Authentik ?

Bundle Symfony Security vystavuje SAML 2.0 a OpenID Connect. Konfigurace se provádí přes proměnné prostředí, bez rekompilace. Konektor OIDC platný pro Keycloak, Authentik nebo jakéhokoli poskytovatele v souladu s RFC 6749 a RFC 7519. Pro LDAP je přímý binding zdokumentován s mapováním skupin na role RBAC. SCIM 2.0 (RFC 7644) je k dispozici v Business pro automatizovaný provisioning.

Běží ARDNTECH v managed Kubernetes (EKS, GKE, AKS, Kapsule) ?

Ano, nasazení Kubernetes je zdokumentováno pro standardní distribuce. Manifesty zahrnují potřebné Deployment, Service, Ingress, PersistentVolumeClaim a ConfigMap. Oficiální Helm chart je dodáván s výchozími hodnotami přizpůsobenými managed clusterům. Pro suverenitu dat se doporučuje použití managed Kubernetes u provozovatele kvalifikovaného SecNumCloud (OVHcloud, Outscale, Cloud Temple, NumSpot) ; mimoevropské managed clustery zůstávají technicky kompatibilní, ale vypadávají z rámce suverénních doporučení.

Jaký monitoring doporučujete (Prometheus, OpenTelemetry, ELK) ?

Instance vystavuje metriky kompatibilní s Prometheus na vyhrazeném endpointu a vysílá OpenTelemetry trasy pro kritické požadavky. Aplikační logy jsou vysílány ve strukturovaném JSON formátu, přímo ingestovatelné ELK, Loki nebo jakýmkoli standardním Syslog kolektorem. Auditní události lze exportovat ve formátech CEF, LEEF a OCSF pro SIEM Splunk, Elastic, QRadar a Microsoft Sentinel. Žádná telemetrie není ve výchozím nastavení odesílána ke třetí službě.

Jaký je plán komunitní vs placené podpory ?

Komunitní podpora probíhá přes veřejné fórum a issues GitHub : bez závazku lhůty, animovaná přispěvateli a týmem ARDNTECH. Placený doprovod je k dispozici pro organizace, které chtějí auditované nasazení, komplexní integraci SSO, zavedení clusteru vysoké dostupnosti nebo revizi architektury před uvedením do produkce. K režimu self-host není připojeno žádné SLA : z principu konstrukce je to zákazník, kdo provozuje infrastrukturu.

Jak přejít na air-gap po standardní instalaci ?

Air-gap spočívá v odstranění veškeré odchozí konektivity instance ARDNTECH. Předpoklady jsou : interní zrcadlový Docker registr pro aktualizace images, zrcadlový repozitář balíčků pro OS závislosti, ruční kanál pro export a import šifrovaných záloh. Protože ve výchozím nastavení není vysílána žádná telemetrie, samotná aplikace nemá žádnou runtime závislost na externí službě. Odchozí webhooky lze deaktivovat konfigurací nebo směrovat k internímu relé. Úplný postup je zdokumentován v air-gap průvodci repozitáře.

12 / Začít

Self-host ARDNTECH,
vaše infrastruktura, váš perimetr.

Přečtěte si úplnou technickou dokumentaci na GitHubu nebo požádejte o auditovaný doprovod pro nasazení do produkce. Žádné agresivní obchodní obtěžování : technická výměna o vhodnosti řešení ve vašem kontextu.

Kód AGPL-3.0, úplný přístup, fork povolen
Docker Compose za méně než pět minut
Managed Kubernetes u provozovatele kvalifikovaného SecNumCloud
Air-gap podporováno, žádná odchozí telemetrie
Audit chain HMAC-SHA-256 nezávisle ověřitelný