Architektur und Datenfluss
Diese Seite gibt es, damit eine Sicherheitsprüfung das gesamte System auf einen Blick sieht. Das Interessante ist nicht, was das Diagramm enthält - sondern was nicht.
Das gesamte System in einem Diagramm
Der Scanner wird als einzelner Container ausgeliefert. Die Angular-Oberfläche ist in das Anwendungs-JAR eingebaut und wird vom selben Spring-Boot-Prozess ausgeliefert, der auch die API bereitstellt. Es gibt also keinen separaten Webserver, den Sie betreiben und absichern müssten.
Was jeder Pfeil bedeutet
| Pfeil | Protokoll | Wozu er dient |
|---|---|---|
| Browser zu Reverse Proxy | HTTPS | Ihr Proxy terminiert TLS. Der Container selbst liefert reines HTTP - siehe Produktivbetrieb. |
| Reverse Proxy zu Anwendung | HTTP, Port 8080 | Der einzige Port, den der Container exponiert. |
| Browser zu Identity Provider | OIDC Authorization Code + PKCE | Benutzer authentifizieren sich direkt gegen Ihren Provider. Siehe Identity Provider. |
| Anwendung zu PostgreSQL | JDBC | Der einzige Ort, an dem der Scanner überhaupt etwas persistiert. |
| Anwendung zu Jira | Jira REST API, rein lesend | Der Scan selbst. Keinerlei Schreibvorgänge. Siehe Sicherheit und Datenverarbeitung. |
| Anwendung zu Identity Provider | OIDC-Discovery und JWKS | Das Backend validiert JWTs als OAuth2 Resource Server. Es holt die Signaturschlüssel des Providers und übermittelt nie Benutzerinhalte. |
| Anwendung zu SMTP | SMTP | Nur bei eingerichtetem Reporting. Report-E-Mails enthalten Zahlen und Links, nie Trefferwerte. |
Es gibt keine weiteren ausgehenden Verbindungen
Genau diese Abwesenheit ist der Sinn des Diagramms:
- Kein Phone-Home. Die Lizenzierung ist offline. Die Signaturprüfung erfolgt lokal gegen einen in die Anwendung kompilierten öffentlichen Schlüssel.
- Keine Cloud-KI und keine externe Analyse. Die Mustererkennung läuft lokal.
- Keine Telemetrie und keine Nutzungsanalyse.
- Keine Verbindung zu arcsoft. Zu keinem Zeitpunkt gelangen Jira-Inhalte, Funde oder Metadaten zum Hersteller.
Jeder Endpunkt im Diagramm ist einer, den Sie konfigurieren. Der Scanner hat keinen fest eingebauten externen Host. Wenn Sie ihn auf einen Cloud Identity Provider oder ein gehostetes SMTP-Relay richten, ist das Ihre Konfigurationsentscheidung und nichts, was das Produkt von sich aus tut - und wenn Sie ihn auf nichts weiter richten, läuft er in einem Netz ganz ohne Route ins Internet.
Wo welche Daten liegen
| Daten | Wo sie liegen | Wie sie geschützt sind | Wie lange sie bleiben |
|---|---|---|---|
| Trefferwert selbst (das Geheimnis) | Nirgends | Wird nie in die Datenbank, ein Log, einen Export oder die Oberfläche geschrieben | Wird nie gespeichert |
| Getroffener Text und sein umgebender Kontext | Nirgends | Es wird kein Ausschnitt irgendeiner Form gespeichert; ein Fund hält nur einen geschlüsselten Fingerabdruck und eine Fundstelle | Wird nie gespeichert |
| Fingerabdruck des Funds | PostgreSQL | HMAC-SHA256, geschlüsselt mit FINDING_FINGERPRINT_HMAC_SECRET, sodass eine entwendete Datenbank keinen Wörterbuchangriff erlaubt | Aufbewahrungsfrist, standardmässig zehn Jahre |
| Fundstelle (Projekt, Issue-Schlüssel, Feld, Offsets) | PostgreSQL | Gewöhnliche Anwendungsdaten; verweist auf Jira, statt daraus zu kopieren | Aufbewahrungsfrist, standardmässig zehn Jahre |
| Extrahierter Anhangstext | Nur im Arbeitsspeicher | Nur so lange gehalten, wie dieser eine Anhang gescannt wird, danach verworfen | Wird nie persistiert |
| Bild-Bytes während der OCR | Privates temporäres Verzeichnis | Berechtigungen nur für den Eigentümer; gelesen von einem separaten, ressourcenbegrenzten OCR-Prozess ohne Geheimnisse; nach jedem Bild gelöscht | Wird nie gespeichert |
| Manuelle Prüfungen | PostgreSQL | Dateiname des Anhangs, Issue-Schlüssel, Grund und Entscheidung; nie Bild-Bytes oder OCR-Text | Aufbewahrungsfrist, standardmässig zehn Jahre |
| Zugangsdaten des Jira-Service-Accounts | PostgreSQL | AES-256-GCM mit JIRA_CREDENTIAL_ENCRYPTION_KEY; wird nie von der API zurückgegeben oder nach dem Speichern angezeigt | Bis Sie sie ersetzen - unterliegt nicht der Aufbewahrungsfrist |
| SMTP-Passwort | PostgreSQL | Dieselbe Verschlüsselung, derselbe Schlüssel | Bis Sie es ersetzen - unterliegt nicht der Aufbewahrungsfrist |
| OIDC-Zugangsdaten | Nirgends | Das Backend validiert lediglich JWTs; es speichert kein Benutzer-Zugangsdatum | Wird nie gespeichert |
| Audit-Ereignisse | PostgreSQL | Bereinigte Metadaten, nie Rohwerte; über die Oberfläche nicht bearbeitbar | Werden standardmässig nicht gelöscht |
Die Einzelheiten hinter jeder Zeile stehen in Sicherheit und Datenverarbeitung, Anhänge scannen und Datenaufbewahrung.
Was der Betrieb Ihnen nicht abnimmt
Der Scanner ist self-hosted. Damit liegen mehrere Kontrollen, nach denen eine Prüfung fragt, bei Ihnen und nicht beim Produkt:
- TLS-Terminierung erfolgt an Ihrem Reverse Proxy. Der Container liefert reines HTTP auf Port 8080 und terminiert selbst kein TLS.
- Verschlüsselung der Datenbank im Ruhezustand ist eine Eigenschaft Ihrer PostgreSQL-Installation. Der Scanner verschlüsselt die gespeicherten Jira- und SMTP-Zugangsdaten ohnehin auf Anwendungsebene, doch das übrige Schema ist nur so geschützt, wie Ihre Datenbank und Ihr Speicher es leisten.
- Sicherungen und Wiederherstellung liegen bei Ihnen. Der Scanner hat weder eine eigene Backup-Funktion noch einen eigenen Wiederherstellungsweg.
- Patching bedeutet, ein neues Container-Image zu ziehen; der Scanner aktualisiert sich nicht selbst und hat keinen Auto-Update-Kanal.
- Die Verwaltung der Geheimnisse
JIRA_CREDENTIAL_ENCRYPTION_KEYundFINDING_FINGERPRINT_HMAC_SECRETliegt bei Ihnen. Beide sind für die Lebensdauer der Installation unveränderlich - siehe Produktivbetrieb.
Das steht hier ausdrücklich, weil ein self-hosted Produkt, das diese Punkte verschweigt, eine Prüfung zu der Annahme einlädt, der Hersteller kümmere sich darum.