Der Vier-Augen-Workflow stellt einen Kontrollmechanismus dar, der Fehler oder Manipulationen innerhalb bestimmter Arbeitsprozesse verhindern soll. Hierbei sind (mindestens) zwei Personen aufgefordert, z.B. einen Arbeitsvorgang oder eine Entscheidung zu bestätigen.
Mit dem SecPKI Server können Workflows wie z.B. eine 4-Augen-Freigabe auf unterschiedliche Art und Weise realisiert werden, wie z.B. in in §7 SVRV „Siebte Verordnung zur Änderung der Sozialversicherungs-Rechnungsverordnung“ gefordert.
4-Augen-Freigabe im Workflow
Am komfortabelsten ist die Anlage und Verwaltung der Workflows über einen Webservice, der dem Kunden vom durch den Kunden selbst betriebenen oder in der Cloud betriebenen SecPKI Server bereitgestellt wird. Über einen (z.B. durch den SecPKI Server bereitgestellten Webservice) kann der Kunde ein Workflow Template anlegen, in dem er bestimmt, welcher Nutzer / welche Nutzergruppe in welchem Schritt eine definierte Aktion ausführen muss. Anstelle der Nutzung des Webservices über den SecPKI Server kann der Kunde das Ganze auch unter Verwendung einer REST API in seinen eigenen Service integrieren. Beispiele für mögliche Aktionen: Option A: Freigabe durch Authentifizierung (entweder einfache Authentifizierung mit einem Passwort oder starke Authentifizierung mit einer Zwei-/Multi-Faktor-Authentifizierung) Option B: Freigabe durch eine fortgeschrittene Signatur (für interne Dokumente). Dabei kann der SecPKI Server die Zertifikate für die Benutzer selber erstellen und verwalten. Option C: Freigabe durch eine qualifizierte elektronische Signatur (z.B. auch durch die Fernsignatur) So kann beispielsweise einfach gesteuert werden, dass Person A eine Rechnung vor Person B freigeben muss. Daraufhin wird das Dokument automatisch durch den SecPKI Server an den weiterverarbeitenden Prozess übergeben. Eine Datei (z.B. ein PDF) wird von einem Benutzer in das Web UI geladen oder per API (z.B. REST, SOAP, etc.) dem Server übergeben. Benutzer Nr. 1 erhält Die Freigabe kann beispielsweise eine Signatur sein. Nach der Freigabe durch Nutzer 1 wird diese vom Server protokolliert. Der Server weiß, dass eine weitere Freigabe erforderlich ist und schickt nun Nutzer Nr. 2 ebenfalls (wie bei Nutzer Nr. 1) entweder eine E-Mail, die einen Link beinhaltet oder eine kurze Information, dass Nutzer Nr. 2 sich im Portal anmelden soll, um ein Dokument freizugeben. Nachdem das Dokument den Freigabeprozess nun vollständig durchlaufen hat, gibt es mehrere Möglichkeiten, wie weiter verfahren werden kann:
Der Webservice kann entweder in der Standardkonfiguration genutzt werden oder aber von uns zu einem Custom Webservice in dem Design des Kunden gestaltet werden.
Der Kunde kann zudem die Funktionalität über die durch den SecPKI Server zur Verfügung gestellte REST API in bestehende Portale integrieren.
Anwendungsbeispiel Custom Webservice
Key Facts zur 4-Augen Freigabe im Überblick
Der Workflow
Beispiel für einen möglichen Workflow-Verlauf:
eine E-Mail mit einem Link auf eine Webseite, auf der er das Dokument freigeben kann
oder
b) erhält eine einfache Benachrichtigung, die ihm mitteilt, dass im Portal etwas liegt, das auf seine Freigabe wartet
Revisionssichere Protokollierung
Alle Schritte, die ein Benutzer durchführt, werden durch den SecPKI Server protokolliert. Somit ist genau ersichtlich, wann welcher Benutzer was freigeben hat. Welche Aktionen protokolliert werden, kann auf feingranularer Ebene konfiguriert werden, damit die Kunden ihren Datenschutzanforderungen gerecht werden. Auf Wunsch können die protokollierten Daten noch mit Zeitstempeln versehen oder z.B. mithilfe eines qualifizierten Siegels signiert werden.
Zusätzliche Features
- Freie Positionierung von sichtbaren Signaturstempeln in einer PDF-Datei oder automatisierte Zuordnung der Signaturstempel zu bestimmten Formfeldern
- Prüfung durch den SecPKI Server, ob PDF-Dokumente den Anforderungen des Unternehmens gerecht werden (z.B. ob sie PDF/A-konform sind)
- Erstellung eines PDFs durch den SecPKI Server, in dem genau dokumentiert ist, wer wann von wo signiert hat (inkl. Zeitstempel, etc.).
- Automatische Erkennung von Formfeldern im PDF
- Embedded PAdES-Signatur oder externe Signaturdateien
- Übergabe per API, z.B. SOAP oder REST
- Automatischer Versand bzw. Übergabe des abgeschlossenen Workflows
- Signaturprüfung