OpenNIT

OpenNIT Logo

OpenNIT

Revisionssicheres IT-Dokumentations- & Asset-Management

Self-Hosted. Audit-Ready. Open Source.

PHP 8.2+ MySQL / MariaDB License: AGPL-3.0

ISO 27001 Ready BSI Grundschutz SOC 2

Self-Hosted Hash-Chain Audit AES-256-GCM MFA: TOTP + WebAuthn

Installation · Features · Module · Screenshots · Dokumentation · Lizenz

OpenNIT Dashboard

_{Das konfigurierbare Dashboard mit Widgets für Tickets, To-Dos, Monitoring und Schnellzugriff. Weitere Ansichten unter Screenshots.}

Warum OpenNIT?

Features

Technologie-Stack

PHP MySQL MariaDB HTML5 CSS3 JavaScript

Systemvoraussetzungen

php8.x-fpm       php8.x-mysql
php8.x-json      php8.x-mbstring
php8.x-openssl   php8.x-pdo
php8.x-zip       php8.x-curl
php8.x-xml       php8.x-gd

Empfohlene Ressourcen

Installation

Ausführliche Anleitung: docs/INSTALLATION.md

# 1. Repository klonen
git clone <repository-url> /var/www/it-docs
cd /var/www/it-docs

# 2. PHP-Abhängigkeiten installieren
composer install --no-dev --optimize-autoloader

# 3. Storage-Verzeichnis anlegen (ausserhalb webroot!)
mkdir -p /var/www/it-docs-storage/{uploads,sessions,logs,cache}
chown -R www-data:www-data /var/www/it-docs-storage
chmod 750 /var/www/it-docs-storage

# 4. Webserver konfigurieren (siehe docs/INSTALLATION.md)

# 5. Installationsassistent aufrufen
#    https://your-domain.com/install.php
#    Der Assistent legt die .env samt APP_KEY selbst an - keine .env vorab
#    von Hand erstellen, sonst verweigert er den Start.

# 6. Installationsdatei entfernen (Pflicht!)
rm public/install.php

Cron-Scheduler einrichten

OpenNIT verwendet einen zentralen Scheduler — eine einzige Crontab-Zeile genügt:

* * * * * www-data /usr/bin/php /var/www/it-docs/bin/scheduler.php >> /var/www/it-docs-storage/logs/scheduler.log 2>&1

Alle Tasks (Intervall, Hintergrund, aktiv/inaktiv) werden bequem im Admin-UI unter Admin > Cron-Jobs verwaltet.

Konfiguration

# Anwendung
APP_NAME="OpenNIT"
APP_ENV=production
APP_DEBUG=false                 # NIEMALS true in Produktion!
APP_URL=https://docs.example.com
APP_KEY=<32-Zeichen-Zufallsschlüssel>

# Datenbank
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=it_docs
DB_USERNAME=it_docs_user
DB_PASSWORD=<sicheres-passwort>
DB_CHARSET=utf8mb4

# Azure AD / Entra ID (optional)
AZURE_TENANT_ID=<tenant-id>
AZURE_CLIENT_ID=<client-id>
AZURE_CLIENT_SECRET=<client-secret>
AZURE_REDIRECT_URI=https://docs.example.com/auth/callback

# Sicherheit
# Hinweis: Session-/CSRF-Lebensdauer, Rate-Limit, max. Upload-Größe und Audit-Aufbewahrung
# lassen sich auch im Backend unter Admin > Einstellungen > „Sicherheit & Sessions" pflegen
# (überschreibt diese .env-Werte via config/runtime.php). SESSION_SECURE/HSTS/CSP bleiben hier.
SESSION_LIFETIME=28800          # 8 Stunden
SESSION_SECURE=true             # Nur HTTPS!
CSRF_TOKEN_LIFETIME=28800
RATE_LIMIT_REQUESTS=100
RATE_LIMIT_WINDOW=60

# Datei-Storage
STORAGE_PATH=/var/www/it-docs-storage
STORAGE_ENCRYPTION_KEY=<32-Zeichen-Zufallsschlüssel>
MAX_UPLOAD_SIZE=52428800        # 50 MB

# Audit
AUDIT_RETENTION_YEARS=10

Sicherheit

Vollständige Analyse: docs/SECURITY.md

Checkliste Produktion

• [ ] APP_DEBUG=false
• [ ] SESSION_SECURE=true
• [ ] STORAGE_PATH ausserhalb webroot
• [ ] install.php gelöscht
• [ ] Rate Limiting aktiv
• [ ] HTTPS mit gültigem Zertifikat
• [ ] MFA für externe Benutzer erzwungen

Anleitung für externen Zugriff: docs/EXTERNAL_ACCESS.md

Audit-Funktion

Vollständige Dokumentation: docs/AUDIT.md

Aktion  -->  Audit-Eintrag  -->  Hash(Eintrag + vorheriger Hash)  -->  Kette

Jede Benutzeraktion wird erfasst:

• Wer: Benutzer, IP-Adresse, User-Agent
• Was: Aktion, betroffenes Objekt, alter/neuer Wert (JSON)
• Wann: Zeitstempel mit Mikrosekunden-Präzision
• Wie kritisch: Risikostufe (low / medium / high / critical)
• Verifizierbar: Kryptografischer Hash-Fingerprint in der Chain

Zugriff via Admin > Audit-Log — filterbar, exportierbar als CSV/PDF.

Für Audits und die jährliche Wirtschaftsprüfung erzeugt der Audit-Bericht-Generator unter Admin > Audit-Bericht ein PDF-Nachweisdokument (ISO 27001 / BSI / DSGVO / GoBD) mit Live-Kennzahlen und Control-Mapping — siehe docs/COMPLIANCE.md.

Benutzerrollen & Berechtigungen

Capability-basiertes RBAC-System:

Module

OpenNIT ist vollständig modular aufgebaut. Jedes Modul kann einzeln unter Admin > Einstellungen > Module aktiviert werden.

Kern

Betrieb

Infrastruktur

Produktivität

KI & Integrationen

Administration

Standardmässig deaktiviert (Opt-in): Hypervisor, UniFi, Backup, XDR-Warnungen, KI-Chat, Lizenzmanager, Software-Inventar, Konfigurationslog, Telefonbuch, DNS-Zonen, Informationssicherheit (ISMS), Statusseite sowie API-Auto — erfordern externe Systeme, sind öffentlich erreichbar bzw. nischig und werden bei Bedarf unter Admin > Einstellungen > Module aktiviert.

Screenshots

Ein Blick in die Oberfläche – ein Screenshot pro Modul, gruppiert wie die Modul-Liste oben. Die mit externen Systemen verbundenen Module (Monitoring, UniFi, Backup, Hypervisor, Netzwerkpläne) zeigen ihren Leer-/Verbindungszustand.

CLI-Tools

Zentraler Scheduler (empfohlen)

# Eine einzige Crontab-Zeile — alle Tasks per Admin-UI steuerbar
* * * * * www-data /usr/bin/php /var/www/it-docs/bin/scheduler.php >> /var/www/it-docs-storage/logs/scheduler.log 2>&1

Legacy-Scripts

Bleiben funktionsfähig, können aber nach Umstellung auf den Scheduler entfernt werden:

WordPress-Integration

Das Verzeichnis wordpress-plugin/opennit-connector/ enthält ein WordPress-Plugin zur Einbindung von OpenNIT-Daten in WordPress-Seiten.

• Token-basierter API-Zugriff
• Shortcodes für Dokumentation, Assets und IT-Services
• Geeignet für Intranet-Portale auf WordPress-Basis
• Leihgeräte-Self-Service: Nutzer können Geräte reservieren bzw. anfragen (mit Freigabe durch das IT-Team)
• Website-KI-Bot: öffentlicher Chat-Bot auf der WordPress-Seite über die abgesicherte Bot-API (Token mit assistant-Scope, HMAC-Signatur, Nonce-Replay-Schutz, Rate-Limit)

Lizenz: Das Plugin steht als eigenständiges Werk unter GPL-2.0-or-later (Lizenztext: wordpress-plugin/opennit-connector/LICENSE), nicht unter der AGPL-3.0 des Servers. Es kommuniziert ausschließlich über HTTP mit OpenNIT und bindet keinen Servercode ein; die abweichende Lizenz erfüllt die Vorgabe von WordPress.org („GPLv2 oder später").

Die WordPress-Endpunkte sind Teil der allgemeinen REST-API und von jedem System nutzbar, nicht nur von WordPress. Eine interaktive Swagger-UI und der OpenAPI-Export stehen im Backend unter Admin → API bereit.

Authentifizierung: Ein Bearer-Token mit passendem Scope allein genügt nicht. Jede Anfrage muss zusätzlich HMAC-signiert sein – über die Header X-OpenNIT-Timestamp, X-OpenNIT-Nonce und X-OpenNIT-Signature. Die Signatur bindet die im Aufruf angegebene Person an das Signing-Secret des Tokens; ohne sie könnte jeder Token-Inhaber im Namen beliebiger Personen lesen und handeln. Fehlen die Header, antwortet die API mit 401 – auch bei gültigem Token.

Ausgenommen sind die Endpunkte der Sync-Agenten (IPAM-Scan, DNS-Import): Sie kommen mit dem Bearer-Token aus, da die Agent-Skripte nicht signieren.

Die genaue Bildung der Signatur – kanonische Zeichenkette, Reihenfolge der Bestandteile und ein lauffähiges Beispiel – steht in der Swagger-Beschreibung unter Admin → API im Abschnitt „Signatur". Token und Signing-Secret werden beim Anlegen eines Tokens einmalig angezeigt.

Weiterführende Dokumentation

Lizenz

GNU Affero General Public License v3.0 (AGPL-3.0)

AGPL-3.0

Installation · Sicherheit · Audit · Lizenz

Made with care in Germany.