50 lines
1.7 KiB
Markdown
50 lines
1.7 KiB
Markdown
# OpusR-Client — Security Model
|
|
|
|
## Übersicht
|
|
|
|
Der OpusR-Client ist für den Einsatz in hochsicheren z/OS-Umgebungen
|
|
(Banken, Versicherungen, Behörden) konzipiert. Sicherheit hat absolute
|
|
Priorität über Komfort.
|
|
|
|
## Authentifizierung
|
|
|
|
### Phase 1: Basic Auth über HTTPS
|
|
- User gibt RACF User/Password ein
|
|
- Credentials werden per TLS verschlüsselt an DDF geschickt
|
|
- Password wird nur im Speicher gehalten (SecretString mit Zeroize)
|
|
- Bei Programmende wird der Speicher überschrieben
|
|
|
|
### Phase 2: RACF PassTickets
|
|
1. Einmal-Login: User/Password → Login-Service auf z/OS
|
|
2. Login-Service prüft gegen RACF (ICHRIX02 / RACROUTE VERIFY)
|
|
3. Bei Erfolg: PassTicket generieren (IRRSGS00)
|
|
4. PassTicket zurück an Client (8 Byte, 10 min TTL)
|
|
5. Alle weiteren REST-Calls nutzen PassTicket statt Password
|
|
6. Refresh vor Ablauf (9 min Intervall)
|
|
|
|
### PassTicket Eigenschaften
|
|
- 8 Byte, kryptographisch generiert
|
|
- Gebunden an Applikationsname (PTKTDATA-Profil in RACF)
|
|
- Einmalig verwendbar (Replay-Schutz)
|
|
- 10 Minuten gültig
|
|
- Kein echtes Passwort verlässt nach dem Login den Client
|
|
|
|
## Transport
|
|
- TLS 1.2+ mandatory (DDF SECPORT)
|
|
- Zertifikatvalidierung standardmäßig aktiv
|
|
- `--danger-accept-invalid-certs` nur für Entwicklung
|
|
- Kundeninstallation: echtes Zertifikat im RACF Keyring
|
|
|
|
## Credential-Handling im Code
|
|
- `secrecy::SecretString` für Passwords und PassTickets
|
|
- Automatisches Zeroize bei Drop
|
|
- Debug-Output zeigt "[REDACTED]"
|
|
- Kein Logging von Credentials (auch nicht bei Fehlern)
|
|
- Kein Speichern auf Disk (kein Config-File mit Passwords)
|
|
|
|
## RACF-Voraussetzungen beim Kunden
|
|
1. DDF aktiv mit SECPORT (SSL)
|
|
2. RACF PTKTDATA-Profil für opusR-Applikation
|
|
3. User braucht EXECUTE auf das REST-Service-Package
|
|
4. Optional: Client-Zertifikat im RACF Keyring
|