Administrationsbereich

Der Administrationsbereich (/management) ist die eigene Oberfläche des Betreibers. Er hat eine eigene Anmeldung, getrennt von Produktkonten - ein Betreiberkonto kann keine Produktseiten öffnen und umgekehrt.

Übersicht

Die Startseite zeigt, was die Installation ist und was sie tut: Nutzer-/Workspace-/Projektzahlen, Modulstatuskarten (ArchPilot, ArchScan, Code Health) hinter einem optionalen Workspace-Filter, Verteilungsdiagramme, eine Arbeitstempo-Anzeige, die Aktivität der letzten 28 Tage und - falls konfiguriert - die Update-Prüfung.

Workspaces

Jeder Workspace der Installation, mit einer Detailseite pro Mandant:

• Mitglieder (Konten mit LDAP-Anmeldung sind markiert - ihre Passwörter leben im Verzeichnis),
• Projekte (ein Projekt ohne Zugangsdaten wird markiert: es erklärt ein Repository, das nie scannt),
• ausstehende Einladungen mit Ablaufdatum,
• ein Einladungsschalter - geschlossen verschwindet die Einladen-Aktion für die Mitglieder, und die API lehnt den Aufruf ab, egal von wem. Die eigenen Admins des Workspace können ihn nicht aufheben.
• Eine Karte Moduldaten zurücksetzen: Module auswählen (ArchScan, ArchPilot, ArchSecurity, Compliance, Git Health, Engineering-Analytik, Assistentenverlauf), und ihre Ergebnisse für diesen Workspace werden physisch gelöscht - Läufe, Scans, Befunde und Fakten. Regeln, Integrationen, Zugangsdaten und Mitglieder bleiben; der nächste Scan oder Sync beginnt von vorn. Es gibt kein Rückgängig, deshalb wird vorher gefragt.

ArchScan-Läufe und ArchPilot-Reviews auf den Modulansichten des Workspace tragen zum selben Zweck einen Löschen-Button: ein Testlauf, der nicht zählen soll, wird samt Befunden dauerhaft entfernt.

An der Workspace-Detailseite hängen zwei weitere Seiten:

• Konfiguration - die Hälfte der Einrichtung eines Mandanten, die bisher nur seine eigenen Mitglieder sahen: mit welchen Zugangsdaten er einen Git-Anbieter erreicht (eigene und von der Installation geteilte, jeweils mit den letzten vier Zeichen und der Zahl der Projekte), womit er verbunden ist (Jira, Trello, Sonar, Slack, Teams, JMeter, Argo CD, Kubernetes, Dynatrace, New Relic), seine Scan-Zeitpläne, seine eigenen Rollen mit den jeweils gewährten Rechten und seine Projektgruppen. Nur lesbar, und kein Geheimnis ist dort lesbar.
• Projektdetail - auf den Projektnamen klicken: Standardbranch, Gruppe, Zugangsdaten und deren Ablauf, die letzten vier Zeichen des Runner-Tokens und dessen Alter, ob ein Webhook-Secret gesetzt ist, Include-/Exclude-Muster des Scan-Umfangs, Architekturansätze, Regelausnahmen, Release-Verfolgung und wer das Projekt registriert hat. Token und Webhook-Secret werden gehasht gespeichert und sind nicht lesbar.

Ein gelöschter Workspace lässt sich aus der Liste wiederherstellen. Die Zeilen wurden nie entfernt, er kommt mit Projekten und Historie zurück.

Modulansichten

Jedes Modul hat eine installationsweite Ansicht, und die meisten öffnen einen Workspace genau so, wie seine Mitglieder ihn sehen - dieselben Dashboards, Befunde und Berichte, schreibgeschützt wo eine Aktion dem Mandanten gehört (Exporte, Sync-Buttons, Kommentar-Schließen).

• ArchScan - Bestandsdashboard, Drilldown pro Workspace zu Läufen und vollständigen Berichten; Code Health und Abhängigkeiten liegen auf seiner Tab-Leiste mit demselben optionalen Filter.
• ArchPilot - Adoption und Ergebnis (bestanden / Aufmerksamkeit / durchgefallen), die meistausgelösten Regeln und wie oft ihre Kommentare umgesetzt werden, pro Workspace die geprüften MRs mit Befunddetails.
• ArchSecurity - Schweregrad-Mix, Sicherheitsdashboard und Framework-Berichte pro Workspace (OWASP, PCI DSS, DISA STIG, CASA ASVS), einschließlich offener Befunde aus GitLab/SonarQube - neben den eigenen gezählt, nie zusammengeworfen.
• Compliance, Git Health, Service-Katalog - installationsweite Gegenstücke der Mandantenansichten, alle nach Workspace und Projekt eingrenzbar.

Überall gilt: nie gescannt wird als unbekannt gemeldet - nicht als gesund und nicht als null.

Auf den Seiten für Compliance und Git Health kann der Betreiber außerdem einen Scan für ein Projekt im Namen des Workspace einreihen. Der Lauf wird als von operator ausgelöst erfasst und keinem Mandantenbenutzer zugeschrieben, damit eine Support-Aktion nie wie eine Kundenaktion aussieht.

Einstellungen

Ein Reiter-Bildschirm: Lizenz (mit den gewährten Limits), E-Mail (SMTP/Postmark, mit Testversand), Bericht-E-Mails, KI-Assistent (siehe Archito, der Assistent), Registrierung & Einladungen - der Selbstregistrierungsschalter, die Positivliste einladbarer E-Mail-Domains und der installationsweite Zwei-Faktor-Schalter -, Dashboard, Module (ein abgeschaltetes Modul stoppt auch seine geplanten Jobs), LDAP, Turnstile, Sprachen und Analytics. Läuft die Lizenz ab, arbeitet die Installation 14 Tage lang weiter; danach hält die Installation an, bis eine neue Lizenz eingespielt ist - was das bedeutet und was sie sonst noch anhalten kann, steht unter Lizenziert bleiben.

Der Reiter Lizenz zeigt außerdem den Installationscode. Eine Lizenz gilt für eine Installation: Die erste Installation, die sie online abholt, bindet sie an sich, und eine andere Installation, die dieselbe Lizenz anfragt, wird abgewiesen. Eine abgeschottete Installation sendet diesen Code an AppArch und erhält eine .lic-Datei, die nur auf dieser Installation funktioniert. Mehrere Pods mit einer gemeinsamen Datenbank gelten als eine Installation. Für einen Umzug auf einen neuen Server bitten Sie AppArch, die Lizenz freizugeben, und holen Sie sie dann vom neuen Server aus erneut ab - siehe Eine Lizenz, eine Installation.

Gefahrenzone - Werksreset

Einstellungen > Gefahrenzone setzt die Installation auf den Erststart zurück: jeder Workspace, jedes Mitglied, jede Einladung, jedes Nutzerkonto, jede Git-Anmeldung (auch geteilte), jedes Projekt, jede Integration, jeder Scan, jeder Befund und jeder Bericht wird gelöscht, Identitätszähler beginnen neu. Administratorkonten, Lizenz, Installationszugang, Einstellungen, Übersetzungen und Regelkataloge bleiben, der Einrichtungsassistent läuft also nicht erneut - die App hat nur keine Nutzer und Workspaces mehr. Es gibt kein Zurück; vorher ein Datenbank-Backup ziehen (docker compose exec postgres pg_dump ...).

Der Reset ist absichtlich schwer auszulösen:

1. Passwort - nur ein Administrator mit allen Rechten kann ihn starten und muss sein Passwort erneut eingeben.
2. E-Mail-Code - ein sechsstelliger Code geht an die eigene Adresse dieses Administrators (15 Minuten gültig, fünf Versuche). Ausgehende E-Mail muss konfiguriert sein; einen anderen Bestätigungsweg gibt es nicht.
3. Getippte Bestätigung - der lizenzierte Kundenname, genau wie angezeigt.
4. Zehn-Minuten-Fenster - die Löschung wird geplant, jeder aktive Administrator erhält eine E-Mail mit Link, und jeder von ihnen kann bis zum Ende des Fensters abbrechen. Danach startet der Job innerhalb von dreißig Sekunden und ist nicht mehr zu stoppen.

Jede Anfrage wird in der Verwaltungsdatenbank protokolliert - wer sie von welcher Adresse gestartet hat und wie viele Zeilen pro Tabelle entfernt wurden. Administratoren erhalten eine abschließende E-Mail mit den Summen. Ein optionaler Schalter löscht auch die Lizenz - nur für die Übergabe der Installation an einen anderen Kunden.

Betrieb

• Updates - installierte Version gegen die Registry des Anbieters, pro Komponente, mit Sofort-Prüfen-Button. Die Prüfung läuft über das Anbieter-Gateway mit den Installationszugangsdaten; abgeschottete Installationen schalten sie mit UpdateCheck:Enabled=false ab.
• Sicherheitshinweise - die Schwachstellendaten, gegen die jede geprüfte Abhängigkeit abgeglichen wird, pro Registry, mit dem OSV-Import zur Aktualisierung. Siehe unten.
• Befunde - was die Installation über sich selbst bemerkt hat: ein Job, der geworfen hat, ein Projekt, dessen Sync immer wieder scheitert, eine Mail ohne Versuche mehr, eine von der Datenbank abgelehnte Zeile. Eine Zeile pro Problem mit Häufigkeit und letztem Fehler; sie schließt sich selbst, sobald das Subjekt wieder gelingt. Als gesehen markieren, von Hand schließen oder einen Typ nur für sich stummschalten. Offene Befunde erscheinen als Badge in der Seitenleiste und als Zeile auf der Startseite.
• Jobs - jeder geplante Job mit Sofort-Ausführen-Button.
• Kapazität (eigene Seite unter System) - gemessene Job-Last (mittlere Dauer je Job geteilt durch sein Intervall, summiert) gegen die Worker-Threads eines Api-Pods, die lebenden Pods aus der Quartz-Cluster-Tabelle mit ihrer echten CPU- und Speicherauslastung, die Last je Modulgruppe, die schwersten Jobs mit Kategoriefilter und Spaltensortierung und eine Pod-Empfehlung: ein Pod trägt die Last, zwei sind für lückenlose Neustarts ratsam, oder N Pods, wenn die verdoppelte Last einen Pod übersteigt. Erscheint nach sieben Tagen Historie.
• Systemgesundheit - Live-Proben für PostgreSQL und Redis (nie gecacht) plus Scheduler-Zustand. Für Orchestrator-Proben stattdessen die unauthentifizierten Endpunkte /health/live und /health/ready verwenden - siehe On-Prem-Installation.
• Integrationen - ein Inventar von allem, womit die Installation spricht, pro Workspace, ohne Geheimnisse.
• Nutzer, Einladungen, Administratoren - Kontenverwaltung beider Ebenen.

Sicherheitshinweise

Jeder ArchScan-Lauf meldet die Abhängigkeiten, die das Repository deklariert. Die Api gleicht diese Liste mit dem eigenen Hinweiskatalog der Installation ab und erzeugt einen Befund für jedes Paket, dessen installierte Version in ein veröffentlichtes Schwachstellenfenster fällt (CWE-1104, zugeordnet zu OWASP A06 sowie den PCI-, STIG- und CASA-Kontrollen). Der Abgleich passiert hier statt im Runner: Ein CI-Job im Kundennetz erreicht keinen CVE-Dienst, und ein vor einem Jahr festgeschriebenes Collector-Image trüge einen ein Jahr alten Datenbestand.

Das Produkt liefert einen kuratierten Grundbestand für die acht Registries, die die Collectors lesen - NuGet, npm, PyPI, Maven (Java und Kotlin), Go, RubyGems, Packagist und SwiftPM. Schwachstellendaten altern in Wochen, aktualisieren Sie sie deshalb unter Verwaltung → Sicherheitshinweise: Laden Sie auf einem Rechner mit Internet den Export der benötigten Registry von osv.dev (osv-vulnerabilities/<registry>/all.zip), fassen Sie die Datensätze zu einem JSON-Array zusammen und laden Sie die Datei hoch. Der nächste Scan gleicht damit ab - ohne Image-Neubau und ohne ausgehenden Aufruf.

Ein Import fügt hinzu und aktualisiert; er löscht nie eine Zeile und reaktiviert nie einen Hinweis, den ein Operator nach einem Fehlalarm abgeschaltet hat. Der Bildschirm zeigt außerdem, welche Registries gar keine Hinweise haben - das ist dasselbe wie eine Sprache, deren Abhängigkeiten niemand prüft.

Administrator-Anmeldung und Sperre

Jeder Anmeldeversuch im Verwaltungsbereich wird erfasst - wer, von welcher Adresse, mit welchem Browser und warum er scheiterte (falsches Passwort, unbekannte E-Mail, inaktives Konto, gesperrtes Konto). Die Spur steht unter Audit > Anmeldungen.

Nach fünf Fehlversuchen wird ein Konto fünfzehn Minuten gesperrt. Die Sperre gilt pro Konto, nicht pro Adresse: jede Anmeldung erreicht die API über den UI-Pod, eine adressbasierte Sperre würde also eine einzige Maschine zählen. Ein gesperrtes Konto ist in der Administratorenliste markiert, und jeder Administrator mit dem Recht Administratoren kann es sofort entsperren.

Jedes Betreiber-Token gehört jetzt zu einer Sitzung, und Meine Sitzungen (vom Administratoren-Bildschirm aus) listet sie auf: Gerät, Adresse, Beginn und letzte Nutzung, wobei die gerade betrachtete markiert ist. Eine Sitzung zu beenden meldet diesen Browser bei seiner nächsten Anfrage ab, und sie lässt sich danach auch nicht mehr erneuern - “diesen Laptop abmelden” meint es also wirklich, statt bis zum zufälligen Ablauf des Tokens zu gelten. Jede andere Sitzung beenden räumt den Rest in einem Schritt ab.

Ein Administrator mit dem Recht Administratoren kann außerdem eine Kollegin oder einen Kollegen überall abmelden, ohne das Konto anzutasten. Bisher ging das nur durch Deaktivieren, und das nimmt den Zugang so lange weg, bis jemand daran denkt, ihn wieder einzuschalten.

Administrator entfernen

Administrator löschen in der Liste entfernt das Konto: es verschwindet aus der Liste, kann sich nicht anmelden, seine laufenden Sitzungen enden sofort, und seine E-Mail-Adresse ist für die Nachfolge wieder frei.

Die Datenbankzeile bleibt, und das mit Absicht. Audit-Spur, Anmeldehistorie und jeder “geändert von”-Verweis benennen ihren Akteur über die Id dieses Kontos, ohne Fremdschlüssel dahinter. Die Zeile zu löschen würde all das auf “irgendjemand” reduzieren - die Spur überlebte das Konto, hätte aber vergessen, wer darin war. Also wird das Konto stattdessen geleert und überall dort verborgen, wo es noch benutzbar wäre.

Ihr eigenes Konto können Sie nicht löschen: eine Anfrage, die auf halbem Weg ihre eigenen Anmeldedaten vernichtet, ist eine verwirrende Art, “abmelden” zu sagen, und ein Fehlklick sperrt Sie aus dem Bereich aus. Für das eigene Konto muss es jemand anderes tun.

Was die einzelnen Rechte absichern

Die Rechte eines Administrators bestimmen, was er tun darf, nicht nur was er sieht - die API weist den Aufruf in jedem Fall ab:

• Lizenz - Lizenz einspielen und ersetzen.
• Benutzer - Konten sperren, reaktivieren, löschen, Passwörter zurücksetzen.
• Administratoren - Administratoren anlegen, Rechte ändern, entsperren.
• Einstellungen - alle Einstellungsreiter, Integrationseinstellungen und geteilte Zugangsdaten.
• Workspaces - Lebenszyklus: Eigentum, Mitgliedschaft, Einladungsschalter, Löschen und Wiederherstellen.
• Daten - physisches Löschen: Workspace-Bereinigung, Löschen eines Laufs oder einer Prüfung.
• Betrieb - Jobs anhalten und fortsetzen, Exporte, Mailversand.

Ein Administrator ohne ein Recht sieht die zugehörige Menügruppe nicht, und die passenden Endpunkte antworten mit 403.

Benutzer löschen

Die Benutzerseite zeigt die Workspaces der Person und, wenn sie keinen davon besitzt, die Aktion Benutzer löschen. Sie entfernt jede Mitgliedschaft, externe Anmeldung, Zwei-Faktor-Einrichtung und Wiederherstellungscodes, widerruft die Sitzungen und bereinigt die Identität - Anmeldehistorie und Audit-Spur bleiben, denn sie sind der Nachweis des Geschehenen. Wer noch einen Workspace besitzt, kann nicht gelöscht werden: übertragen Sie zuerst das Eigentum, eine einzige Aktion auf der Workspace-Seite.