Zum Inhalt

NPM Access-Entscheidung

Stand: 2026-05-25

Ziel

Für zentrale Verwaltungsoberflächen soll bewusst entschieden werden, ob sie öffentlich erreichbar bleiben, zusätzlich über NPM Access Lists geschützt werden oder nur intern/VPN erreichbar sind.

Diese Seite ist eine Entscheidungsvorlage. Es wurden keine NPM-Änderungen vorgenommen.

Aktueller Ist-Zustand

Read-only geprüft am 2026-05-25:

Host Access List Einschätzung
vault.lanstyle.de keine NPM Access List besonders kritisch, weil Secret-System
netbox.lanstyle.de keine NPM Access List kritisch, weil Infrastruktur-Inventar
git.lanstyle.de keine NPM Access List kritisch, weil Code, Doku und Tokens/Deploy-Flows

Andere AI-Runtime-Dienste wie litellm.lanstyle.de, mcphub.lanstyle.de, n8n.lanstyle.de, wiki.lanstyle.de und search.lanstyle.de hängen bereits an der Access List Max.

Option A: Öffentlich mit MFA/App-Härtung

Vorteile:

  • Externe Nutzung bleibt bequem.
  • Mobile und wechselnde Netze funktionieren ohne VPN.
  • Weniger Proxy-Sonderlogik.

Risiken:

  • Internet-Exposure bleibt bestehen.
  • Schutz hängt stark von App-MFA, Rate Limits, Updates und sicheren Passwörtern ab.
  • Vaultwarden und Gitea sind attraktive Ziele.

Geeignet für:

  • Dienste mit sehr guter eigener Authentifizierung, MFA und schnellem Patch-Management.

Option B: NPM Access List

Vorteile:

  • Zusätzliche Schutzschicht vor der Anwendung.
  • Gut passend für feste Admin-Quellnetze.
  • Weniger Angriffsfläche durch Bots und Internet-Scans.

Risiken:

  • Externe Nutzung kann bei wechselnden IPs nerven.
  • Falsch konfigurierte Access List kann legitimen Zugriff blockieren.
  • App-eigene MFA bleibt trotzdem nötig.

Geeignet für:

  • vault.lanstyle.de
  • netbox.lanstyle.de
  • git.lanstyle.de, wenn primär Admin-Zugriff von bekannten Netzen erfolgt.

Option C: Nur VPN/intern

Vorteile:

  • Kleinste öffentliche Angriffsfläche.
  • Besonders sinnvoll für Secret- und Infrastruktur-Systeme.

Risiken:

  • Externe Nutzung erfordert VPN.
  • Mehr Abhängigkeit von VPN-Verfügbarkeit.
  • Für OpenCode von extern muss sauber zwischen Runtime-Endpunkten und Admin-UIs getrennt werden.

Geeignet für:

  • Vaultwarden-Adminbereich
  • NetBox-Adminzugang
  • Gitea-Adminfunktionen, falls tägliche externe Nutzung nicht nötig ist.

Empfehlung

Kurzfristig Option B für vault.lanstyle.de, netbox.lanstyle.de und git.lanstyle.de vorbereiten, aber erst nach expliziter Freigabe aktivieren. Für Vaultwarden zusätzlich prüfen, ob Admin-Interface und normale Vault-Nutzung getrennt gehärtet werden können.

Wenn externe OpenCode-Nutzung stabil bleiben muss, darf litellm.lanstyle.de weiterhin über Access List Max erreichbar bleiben. Die Admin-Oberflächen sollten davon getrennt betrachtet werden.

Konkrete Empfehlung je Dienst

vault.lanstyle.de

Empfehlung: Hybrid-Variante.

  • Normale Vaultwarden-Nutzung für Browser Extension und Mobile App grundsätzlich erreichbar lassen, wenn MFA, starke Masterpasswörter und sichere Geräte vorausgesetzt sind.
  • Adminbereich besonders schützen: wenn möglich nur intern/VPN oder über NPM Access List Max.
  • Falls NPM nur den ganzen Host schützen kann und keine saubere Pfadtrennung möglich ist, vor Aktivierung testen, ob Browser Extension und Mobile App mit Access List Max zuverlässig funktionieren.
  • Nicht ohne Fallback aktivieren, weil Lockout beim Secret-System besonders unangenehm ist.

Risikobewertung:

  • Höchstes Schutzbedürfnis der drei Dienste.
  • Größtes Usability-Risiko durch Mobile-App-/Extension-Abhängigkeit.

netbox.lanstyle.de

Empfehlung: NPM Access List Max, perspektivisch nur VPN/intern.

  • NetBox ist internes Infrastruktur-Inventar und braucht keine breite öffentliche Erreichbarkeit.
  • Die Agent Runtime nutzt einen read-only Token intern; öffentliche UI-Erreichbarkeit ist dafür nicht nötig.
  • Externe Admin-Nutzung sollte über bekannte Quellnetze oder VPN erfolgen.

Risikobewertung:

  • Mittel bis hoch, weil NetBox Netzwerk-, IPAM- und Geräteinformationen enthält.
  • Geringes Usability-Risiko, weil es kein Endnutzer-Dienst ist.

git.lanstyle.de

Empfehlung: Hybrid-Variante mit NPM Access List für Web-UI, falls externe Git-Nutzung planbar bleibt.

  • Gitea ist Code-, Config-, Prompt- und Doku-Basis und damit kritisch.
  • Wenn OpenCode/CLI von extern Git über HTTPS nutzen soll, muss vorher getestet werden, ob NPM Access List Max Clone/Fetch/Push-Flows stört.
  • SSH-Git-Zugriff sollte bevorzugt über SSH-Keys und, wenn möglich, VPN oder bekannte Quellnetze laufen.
  • Web-Admin und Organisationseinstellungen sollten möglichst zusätzlich geschützt werden.

Risikobewertung:

  • Hoch, weil Repositories Automationscode, Doku und Betriebswissen enthalten.
  • Mittleres Usability-Risiko, weil externe Entwicklung und OpenCode-Workflows betroffen sein können.

Umsetzungsvorschlag ohne Aktivierung

Vor einer späteren Freigabe:

  1. Access List Max aktuelle Quellnetze prüfen.
  2. Separaten Fallback-Zugang aus internem Netz sicherstellen.
  3. Pro Dienst Wartungsfenster definieren.
  4. Nach Aktivierung testen:
  5. Web Login
  6. API Login, falls genutzt
  7. Mobile/Browser Extension bei Vaultwarden
  8. Git Clone/Fetch/Push bei Gitea
  9. NetBox Agent Runtime read-only Zugriff
  10. Bei Problemen sofort Access List wieder entfernen.

Freigabeentscheidung

Vor Umsetzung klären:

  • Welche Quellnetze gehören dauerhaft in Max?
  • Soll Git über HTTPS von extern ohne VPN nutzbar bleiben?
  • Soll Vaultwarden komplett per Access List geschützt werden oder nur der Adminbereich?
  • Gibt es einen Fallback-Zugriff, falls eine Access List versehentlich aussperrt?