ARDNTECH jest dostarczany w postaci jednolitego kodu źródłowego AGPL-3.0, wykonywalnego zarówno na infrastrukturze ARDNTECH, jak i na Twojej. Tryb self-host obejmuje cały zakres funkcji Team, Business i Enterprise bez ograniczeń : szczegółowy RBAC, SCIM 2.0, SSO SAML 2.0 i OIDC, długoterminowy log audytu. Prowadzisz swoją instancję w wybranym datacenter, w Docker Compose, w zarządzanym Kubernetes u operatora kwalifikowanego SecNumCloud lub w ścisłym wdrożeniu air-gap.
Cztery odrębne motywacje skłaniają organizację do samodzielnego prowadzenia swojego sejfu B2B zamiast subskrybowania SaaS Cloud ARDNTECH. Wszystkie pozostają kompatybilne z późniejszym przejściem w razie zmiany wewnętrznych ograniczeń.
Możliwy air-gap, ścisła izolacja sieciowa, wewnętrzna DMZ, całkowity brak wychodzącej telemetrii. Zaszyfrowane dane nigdy nie opuszczają obwodu, który definiujesz. Żadna strona trzecia nie może zażądać dostępu do Twojej instancji.
Wdrożenie u hostingodawcy już kwalifikowanego SecNumCloud, HDS lub spełniającego wymagania NIS2 i OIV. Warstwa aplikacyjna pozostaje identyczna, zgodność hostingu jest niesiona przez wybraną przez Ciebie infrastrukturę.
Publiczne repozytorium obejmuje cały kod aplikacyjny, aż do prymitywów kryptograficznych. OpenPGP.js v6, Argon2id, AES-256-GCM SEIPDv2, HMAC-SHA-256 : każdy wybór algorytmu jest czytelny i audytowalny.
Licencja AGPL-3.0 jest darmowa. Płacisz wyłącznie za infrastrukturę (compute, storage, przepustowość) i wewnętrzny czas operacji. Dla struktur, których zespół ops jest już wymiarowany, TCO staje się konkurencyjny już od kilkudziesięciu aktywnych stanowisk.
Żadna funkcja oprogramowania nie jest zarezerwowana dla trybu Cloud. To, co się różni, to kto prowadzi infrastrukturę i kto ponosi gwarancje umowne. Poniższa tabela podsumowuje piętnaście wymiarów strukturyzujących decyzję.
| Wymiar | Self-host | SaaS Cloud ARDNTECH |
|---|---|---|
| Kod źródłowy | AGPL-3.0, pełny dostęp, fork dozwolony | AGPL-3.0, pełny dostęp, fork dozwolony |
| Cennik oprogramowania | 0 € | 0 € do 7 €/stanowisko/miesiąc w zależności od planu |
| Hosting | Klient (własna infrastruktura, wybrany IaaS, dedykowane datacenter) | ARDNTECH (suwerenny europejski hostingodawca) |
| Początkowa konfiguracja | Po stronie klienta (Docker Compose lub Kubernetes) | Wliczona, zautomatyzowana (provisioning w kilka minut) |
| Utrzymanie OS i runtime | Po stronie klienta | Wliczone |
| Kopie zapasowe | Po stronie klienta (udokumentowana procedura) | Wliczone, codzienne zaszyfrowane snapshoty |
| Aktualizacje | Po stronie klienta (otagowany obraz Docker, dostarczony plan upgrade) | Wliczone, zapowiedziane okno utrzymaniowe |
| SLA dostępności | Brak (klient prowadzi swoją infrastrukturę) | Best effort (Free), 99,5 % (Business), negocjowane (Enterprise) |
| Wsparcie | Społeczności (forum, issues GitHub) | Społeczności + e-mail w ciągu 1 dnia roboczego (Business) + telefon (Enterprise) |
| Multi-organizacja | Tak (konto-oś, szczegółowy RBAC) | Tak (konto-oś, szczegółowy RBAC) |
| DPA | Nie dotyczy (klient jest administratorem danych) | Standardowa DPA (Business) lub negocjowana (Enterprise) |
| Zgodność | Po stronie klienta | Kwalifikowany hostingodawca, planowana ścieżka SecNumCloud |
| Typowy odbiorca | Firmy cyberbezpieczeństwa z dojrzałym ops, OIV, organizacje mające już wymiarowany zespół ops | Mikrofirmy, MŚP, średnie firmy, biura bez dedykowanego zespołu ops, struktury wolące płacić, aby nie prowadzić |
| Całkowity koszt posiadania | Zmienny : 0 € licencja + czas wewnętrzny + infrastruktura | Przewidywalny : abonament per stanowisko, wszystko wliczone |
| Air-gap | Wspierany (domyślnie brak wychodzącej telemetrii) | Nie dotyczy (instancja prowadzona przez ARDNTECH) |
Czytanie tabeli. Dla zespołu poniżej pięćdziesięciu aktywnych stanowisk bez dedykowanego zespołu ops, SaaS Cloud jest często racjonalnym wyborem. Powyżej, lub jeśli suwerenność infrastruktury jest wymogiem regulacyjnym lub umownym, self-host staje się zasadny. Obie migracje są przewidziane i udokumentowane.
Tylko trzy wymagania, wszystkie standardowe w nowoczesnym środowisku serwerowym. Brak obowiązkowej usługi zewnętrznej przy wykonaniu, brak niestandardowego portu wychodzącego, brak własnościowego protokołu.
Serwer Linux x86_64 lub ARM64 z Dockerem 24 lub wyższym i Docker Compose v2. Debian, Ubuntu LTS, Red Hat Enterprise Linux i ich pochodne są testowane w sposób ciągły. Runtime kontenerów działa zarówno na dedykowanej maszynie wirtualnej, jak i na zarządzanym Kubernetes.
2 vCPU i 4 GB RAM wystarczą dla pięćdziesięciu aktywnych użytkowników. Dla pięciuset użytkowników przewidź 8 vCPU i 16 GB RAM. Storage zależy od liczby sekretów : licz około 100 MB bazy na tysiąc sekretów, plus retencja logów audytu w zależności od Twojego planu.
Nazwa domeny i ważny certyfikat TLS. Let's Encrypt jest udokumentowany i działa bez specjalnej konfiguracji. Nie jest wymagany żaden niestandardowy port wychodzący. Wdrożenie air-gap jest możliwe bez modyfikacji kodu aplikacyjnego : instancja nie odpytuje żadnej usługi zewnętrznej w runtime.
Trzy wspierane warianty wdrożenia, od POC niezależnego biura po produkcję multi-AZ operatora o znaczeniu krytycznym. Ten sam kod, trzy orkiestracje.
Zalecane dla POC, małych zespołów i środowisk deweloperskich. Jedna maszyna, lokalna persystencja lub wolumen sieciowy, wdrożenie jednym poleceniem.
git clone https://github.com/aegirex/aegirex.git
cd aegirex
make install
# generuje sekrety, buduje obraz z Dockerfile repozytorium,
# stosuje migracje i uruchamia wszystkie usługi.
# Instancja jest dostępna pod http://localhost:8280
Build z kodu źródłowego domyślnie. To, co działa na produkcji, to dokładnie to, co znajduje się w git log : bez czarnej skrzynki registry, bez zależności od zewnętrznego konta Docker Hub. Pliki composer.lock i importmap.lock przypinają wersje i odciski SHA zależności ; skompromitowany Packagist lub CDN złamałby build, zamiast po cichu wprowadzić payload. Dla ops w pośpiechu wariant make install-from-registry pobiera gotowy obraz podpisany przez nasze CI.
Zalecane na produkcji, na klastrze zarządzanym lub self-managed. Dostarczone oficjalne manifesty i chart Helm. Kompatybilne z klastrami Kubernetes operatorów kwalifikowanych 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:migrateZalecane dla środowisk o radykalnej suwerenności : OIV, obronność, badania niejawne. Brak wychodzącego połączenia, ręczne kopie zapasowe, aktualizacje przez wewnętrzny mirror rejestru.
# na podłączonym stanowisku
docker pull ghcr.io/aegirex/aegirex:v1.4.2
docker save ghcr.io/aegirex/aegirex:v1.4.2 -o aegirex-v1.4.2.tar
# fizyczny transfer do sieci air-gap (zaplombowany USB, dioda sieciowa)
# na instancji 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:migrateNowoczesny stos PHP, bez SPA, bez npm, bez zależności runtime od usługi zewnętrznej. Każdy element jest udokumentowany i audytowalny niezależnie.
PHP 8.4, Symfony 7.4, Doctrine ORM 3, MariaDB 11. FPM lub FrankenPHP do wyboru. Brak własnościowego rozszerzenia PHP. Wersjonowane migracje Doctrine, przetestowany rollback.
Twig po stronie serwera + Stimulus po stronie klienta. AssetMapper do dostarczania (bez npm, bez zewnętrznego bundlera). Modułowy własny CSS. Bez SPA, bez własnościowego frameworka JavaScript.
OpenPGP.js v6 z X25519, Ed25519 i AES-256-GCM SEIPDv2. Wyprowadzanie Argon2id hasła głównego (RFC 9106, 5 przebiegów, 256 MiB, parallelism 4). Klucze prywatne nigdy nie opuszczają przeglądarki.
Łańcuch audytu zapieczętowany i łączony kryptograficznie przez HMAC-SHA-256. Niezależna weryfikacja przez publiczne polecenie CLI kontroli łańcucha. Wykrywanie każdej próby wstecznego fałszowania, wiążące wobec sędziego jak i wobec CISO.
Symfony Security + scheb/2fa-bundle : e-mail, TOTP (RFC 6238), kody zapasowe. SSO SAML 2.0 i OIDC (RFC 6749 i RFC 7519). Passkeys WebAuthn (W3C WebAuthn Level 2) opcjonalnie.
Wszystko w MariaDB 11 : schemat relacyjny, bloby ograniczone do 1 MB. Brak wymaganego zewnętrznego storage obiektowego. Kolejka przez Symfony Messenger + transport Doctrine, bez zależności Redis dla V1.
Trzy zindustrializowane i udokumentowane procedury. Tryb self-host przenosi odpowiedzialność operacyjną na klienta, nie czyniąc z niej ciężaru : polecenia są skryptowalne, idempotentne i testowane w ciągłej integracji.
Polecenie CLI kopii zapasowej tworzy eksportowalny plik zaszyfrowany w formacie OpenPGP, z automatyczną rotacją. Odbiorca kopii zapasowej jest konfigurowalny (organizacyjny klucz archiwizacji). Przywracanie jest udokumentowane i testowane przy każdym wydaniu.
Obraz Docker otagowany w semantic versioning na ghcr.io/aegirex/aegirex. Wszystkie migracje Doctrine są ustrukturyzowane w trzech etapach (ADD nullable, backfill, ALTER NOT NULL), aby umożliwić wdrożenie blue-green bez przerwy w działaniu usługi, nawet na obszernych bazach. Zmiany breaking są zapowiadane co najmniej jedną wersję minor wcześniej.
Kombinacja snapshotu bazy danych oraz poprzedniego obrazu Docker pozwala na cofnięcie w mniej niż pięć minut. Migracje Doctrine zapewniają swoją przetestowaną metodę down(). Nie jest wymagana żadna ręczna interwencja w schemacie SQL.
Wychodzące e-maile i webhooki audytu są wysyłane asynchronicznie przez Symfony Messenger. Jeśli zewnętrzny dostawca padnie (e-mail, odbiorca webhooka), żądania HTTP nigdy nie są blokowane : zadania są ponawiane z wykładniczym backoffem, a następnie przechowywane w trwałej kolejce, jeśli awaria się utrzymuje. Worker działa jako usługa systemd lub dedykowany kontener, z automatycznym restartem bez utraty.
GET /health publiczne dla sond liveness (load balancer, UptimeRobot, sondy Kubernetes). GET /health/deep chronione allowlistą adresów IP, do pogłębionych kontroli z Twojego wewnętrznego stosu monitoringu (ping bazy danych, cache, kolejka). Brak ujawnienia wrażliwych informacji.
Suwerenność nie kończy się na hostingodawcy aplikacji. ARDNTECH emituje swoje logi w ustrukturyzowanym formacie JSON i udostępnia standardowe metryki Prometheus, aby integrować się ze stosem obserwowalności w pełni europejskim lub self-hostowanym. Bez obowiązkowego własnościowego SDK, bez domyślnej wychodzącej telemetrii.
Kompatybilny z Bugsink (Holandia, MIT, self-hostowalny na Twojej instancji SecNumCloud), GlitchTip (US, MIT, self-hostowalny) lub Sentry self-host. Standardowy SDK Sentry dla Symfony jest kompatybilny z tymi trzema backendami bez modyfikacji kodu. Twoje błędy nigdy nie opuszczają Twojej infrastruktury.
Logi JSON przyswajalne przez Loki + Grafana self-hostowane, OVHcloud Logs Data Platform (zarządzany Graylog, Francja) lub Scaleway Cockpit (zarządzane Loki, Mimir, Tempo, Francja). Metryki Prometheus udostępnialne na dedykowanym endpoincie, ograniczone allowlistą adresów IP.
Publiczne polecenie CLI pozwala zweryfikować integralność łańcucha audytu HMAC-SHA-256. Planowalne w codziennym cronie, wyzwala alert (PagerDuty, wewnętrzny webhook, suwerenny Slack), jeśli łańcuch jest uszkodzony. Każda wsteczna manipulacja dziennikiem jest wykrywana w O(1), bez zależności od zewnętrznych binariów.
E-maile "Wykryto nowe logowanie" są wzbogacane o kraj i miasto dzięki bazie DB-IP Lite (belgijski wydawca, licencja CC-BY 4.0), rozwiązywanej lokalnie na Twojej instancji : adres IP użytkownika nigdy nie jest przesyłany do usługi zewnętrznej. Baza jest automatycznie odświeżana co miesiąc przez cron.
Tryb self-host pozwala przenieść zgodność na poziom wybranego przez Ciebie hostingodawcy. Cztery powszechne reżimy są udokumentowane poniżej, bez angażowania ARDNTECH poza kodem aplikacyjnym na AGPL-3.0.
Możliwy do wdrożenia w OVHcloud Hosted Private Cloud, Outscale 3DS, Cloud Temple lub NumSpot, operatorach kwalifikowanych przez ANSSI. Ścieżka SecNumCloud pozostaje celem zakładanym dla SaaS Cloud ARDNTECH ; w self-host efektywna kwalifikacja zależy od Twojego hostingodawcy.
Możliwy do wdrożenia u hostingodawcy certyfikowanego HDS dla operatorów ochrony zdrowia. Kod aplikacyjny wpisuje się w łańcuch HDS end-to-end, o ile infrastruktura bazowa jest kwalifikowana. Długoterminowy log audytu jest dostępny natywnie.
Wspierane wdrożenie air-gap. Kod AGPL-3.0 audytowalny przez Twojego CISO, aż do prymitywów kryptograficznych. Łańcuch audytu HMAC-SHA-256 tworzy identyfikowalność wiążącą wobec sektorowych organów nadzorczych.
W trybie self-host pozostajesz jedynym administratorem danych. Żaden podwykonawca ARDNTECH nie uczestniczy w ścieżce danych. ARDNTECH nigdy nie jest podmiotem przetwarzającym w rozumieniu RODO : relacja ogranicza się do udostępnienia kodu źródłowego AGPL-3.0.
Trzy profile organizacji często wybierają tryb self-host. Wspólny mianownik : już wymiarowany zespół ops Linux zdolny prowadzić usługę Symfony z bazą relacyjną na produkcji.
ESN bezpieczeństwa, firmy doradcze ds. cyberbezpieczeństwa, wewnętrzne zespoły pentest. Prowadzą już utwardzony system informatyczny, dysponują seniorskim zespołem ops i chcą stosować wewnętrznie kryteria, które audytują u swoich klientów. Self-host pozwala im udowodnić spójność między dyskursem a narzędziami.
Jednostki samorządu, agencje, operatorzy kluczowi w rozumieniu NIS2, organizacje pod nadzorem. Wewnętrzna polityka odrzucania jakiegokolwiek SaaS, nawet francuskiego kwalifikowanego. Self-host gwarantuje, że zaszyfrowane dane i ich łańcuch audytu pozostają ściśle w pożądanym obwodzie administracyjnym.
ESN, które odsprzedają swoim własnym klientom instancję ARDNTECH zarządzaną przez siebie. Tryb self-host staje się elementem ich oferty handlowej : prowadzą platformę, fakturują swoim klientom i zachowują relację. Licencja AGPL-3.0 wyraźnie dopuszcza takie użycie komercyjne.
Osiem powracających pytań zadawanych przez CISO i zespoły DevOps podczas oceny trybu self-host. Jeśli Twojego brakuje, napisz do nas.
Tak. Repozytorium aegirex/aegirex zawiera cały kod aplikacyjny na AGPL-3.0. Żadna funkcja Team, Business ani Enterprise nie jest zarezerwowana dla trybu Cloud. Jedyne różnice dotyczą konfiguracji runtime (zmienne środowiskowe, sekrety ANSSI-track, ustawienia hostingodawcy) oraz powiązania instancji Cloud z infrastrukturą nadzoru i rozliczeń prowadzoną przez ARDNTECH. Po stronie Cloud nie dodano żadnego własnościowego modułu oprogramowania.
Migracja opiera się na pełnym eksporcie sejfu przez zintegrowane narzędzia (eksport JSON odszyfrowany po stronie użytkownika, zgodnie z artykułami RODO 17 i 20) oraz na imporcie do świeżej organizacji docelowej. Migracja nie zachowuje historii audytu w stanie pierwotnym : łańcuch audytu startuje od daty importu, dziennik źródłowy jest zachowany w archiwum do pobrania. Rotacja kluczy HMAC audytu po stronie instancji docelowej rozpoczyna nowy łańcuch. Ponieważ kod jest identyczny, zgodność schematu jest gwarantowana.
Licencja oprogramowania AGPL-3.0 jest darmowa. Dla biura trzydziestu osób z trzema wewnętrznymi serwerami Linux licz zazwyczaj 50 do 150 € miesięcznie za suwerennego hostingodawcę za compute i storage, plus 500 do 2 000 € miesięcznie marginalnego kosztu operacyjnego (0,1 do 0,3 ETP na aktualizacje, kopie zapasowe i nadzór). Self-host staje się ekonomicznie atrakcyjny od liczebności, przy której marginalny koszt ops staje się pomijalny i przy której zespół ops jest już wymiarowany. Poniżej pięćdziesięciu aktywnych stanowisk Cloud jest bardzo często racjonalnym wyborem, chyba że istnieje ścisły wymóg suwerenności infrastruktury.
Bundle Symfony Security udostępnia SAML 2.0 i OpenID Connect. Konfiguracja odbywa się przez zmienne środowiskowe, bez rekompilacji. Konektor OIDC działa dla Keycloak, Authentik lub dowolnego dostawcy zgodnego z RFC 6749 i RFC 7519. Dla LDAP udokumentowane jest bezpośrednie wiązanie z mapowaniem grup na role RBAC. SCIM 2.0 (RFC 7644) jest dostępny w Business do automatycznego provisioningu.
Tak, wdrożenie Kubernetes jest udokumentowane dla standardowych dystrybucji. Manifesty obejmują niezbędne Deployment, Service, Ingress, PersistentVolumeClaim i ConfigMap. Dostarczany jest oficjalny chart Helm z wartościami domyślnymi dostosowanymi do zarządzanych klastrów. Dla suwerenności danych zalecane jest użycie zarządzanego Kubernetes u operatora kwalifikowanego SecNumCloud (OVHcloud, Outscale, Cloud Temple, NumSpot) ; pozaeuropejskie zarządzane klastry pozostają technicznie kompatybilne, ale wykraczają poza ramy suwerennych zaleceń.
Instancja udostępnia metryki kompatybilne z Prometheus na dedykowanym endpoincie i emituje ślady OpenTelemetry dla krytycznych żądań. Logi aplikacyjne są emitowane w ustrukturyzowanym formacie JSON, bezpośrednio przyswajalne przez ELK, Loki lub dowolny standardowy kolektor Syslog. Zdarzenia audytu można eksportować w formatach CEF, LEEF i OCSF dla SIEM Splunk, Elastic, QRadar i Microsoft Sentinel. Domyślnie żadna telemetria nie jest wysyłana do usługi zewnętrznej.
Wsparcie społeczności odbywa się przez publiczne forum i issues GitHub : bez zobowiązania terminowego, prowadzone przez kontrybutorów i zespół ARDNTECH. Płatne wsparcie jest dostępne dla organizacji chcących audytowanego wdrożenia, złożonej integracji SSO, wdrożenia klastra wysokiej dostępności lub przeglądu architektury przed produkcją. Z trybem self-host nie jest powiązany żaden SLA : z założenia to klient prowadzi infrastrukturę.
Air-gap polega na usunięciu wszelkiej wychodzącej łączności instancji ARDNTECH. Wymagania to : wewnętrzny mirror rejestru Docker do aktualizacji obrazów, mirror repozytorium pakietów dla zależności OS, ręczny kanał eksportu i importu zaszyfrowanych kopii zapasowych. Ponieważ domyślnie nie jest emitowana żadna telemetria, sama aplikacja nie ma żadnej zależności runtime od usługi zewnętrznej. Wychodzące webhooki można wyłączyć w konfiguracji lub przekierować do wewnętrznego przekaźnika. Pełna procedura jest udokumentowana w przewodniku air-gap repozytorium.
Tryb self-host wpisuje się w architekturę produktu spójną z pozostałymi stronami referencyjnymi witryny. Poniższe zasoby szczegółowo opisują każdy konkretny aspekt.
Szczegółowy whitepaper kryptograficzny : OpenPGP.js v6, Argon2id, AES-256-GCM SEIPDv2, HMAC-SHA-256.
Pięć priorytetowych branż B2B : ESN bezpieczeństwa, prawnicy, ochrona zdrowia, obronność, energetyka i OIV.
Status prawny ARDNTECH, jurysdykcja, łańcuch podwykonawstwa, standardowa DPA.
Porównanie Free, Team, Business, Enterprise dla SaaS Cloud ; przypomnienie o darmowym oprogramowaniu w self-host.
Szczegóły wyboru hostingu w Paryżu dla SaaS, alternatywa dla self-hostu dla zespołów bez dedykowanego ops.
Dlaczego wydawca prawa francuskiego poza jurysdykcją pozaeuropejską zmienia siatkę analizy CISO.
Przeczytaj pełną dokumentację techniczną na GitHubie lub poproś o audytowane wsparcie przy wdrożeniu produkcyjnym. Bez agresywnego nagabywania handlowego : techniczna rozmowa o zasadności rozwiązania w Twoim kontekście.