Managed Cloud Signaturserver oder On-Premise (In-House) Signaturserver

Sie haben die freie Wahl! Entscheiden Sie selbst, ob Sie den Server selber in Ihrem eigenen Rechenzentrum oder einem Rechenzentrum Ihrer Wahl betreiben möchten, oder ob wir den Server für Sie betreiben sollen (hier können Sie ein Rechenzentrum auswählen oder wir schlagen Ihnen eines vor, das Ihren Anforderungen an Datenschutz, Datensicherheit, Verfügbarkeit, usw. gerecht wird. Dort betreiben wir dann exklusiv für Sie Ihren Signaturportalserver, so dass Sie sich nicht um den Betrieb, die Verfügbarkeit oder das Einspielen von Updates kümmern müssen).


headerIllu

Lizenzierungsoptionen

icon

Secure Managed Cloud

Die perfekte Lösung für Kunden, die sowohl hohe Anforderungen an den Datenschutz stellen, aber gleichzeitig eine Cloud-Strategie haben. Sie möchten den personellen Aufwand auf Ihrer Seite so gering wie möglich halten, und/oder Ihnen fehlen schlichtweg die Experten im Unternehmen, die sich um den Betrieb kümmern können? Dann ist unser Rund­um-Sorg­los-Pa­ket beim Managed Signaturportal für Sie genau das Richtige. Wir suchen gemeinsam für Sie das passende Rechenzentrum aus, wo Ihr Signaturportal dann exklusiv für Sie durch uns betrieben wird.

Das kann z.B. das Rechenzentrum der Bundesdruckerei sein oder ein anderes deutsches Rechenzentrum, aber auch ein Amazon-, Microsoft- oder Google-Rechenzentrum. Sie haben alle Konfigurations- und Customizing-Möglichkeiten für das Signatur Portal, ganz so, als wenn Sie es selber betreiben würden. Der große Unterschied ist, dass wir uns um die Installation, Konfiguration und den Betrieb kümmern. Wir spielen Updates und Patches ein und sorgen dafür, dass der Dienst performant und hochverfügbar ist u.v.m.

icon

In-House (In-House (Self-Managed))

Das Signaturportal wird dann in Ihrem eigenen Rechenzentrum oder in einem Rechenzentrum Ihrer Wahl durch Sie oder einen Partner von Ihnen betrieben. Diese Variante wird meist gewählt, wenn weitere interne Systeme an das Signaturportal angebunden werden sollen, z.B. ein SAP, DMS, usw., und wenn es erhöhte Anforderungen an den Datenschutz gibt, so dass Ihre Richtlinien erfordern, dass nur Sie Zugriff auf das Rechenzentrum haben.

Das In-House-Set-up ermöglicht es Ihnen, stets die volle Kontrolle über den Betrieb, die Update-Prozesse und die Verfügbarkeit zu behalten. Es erfordert aber natürlich auch, dass Sie Personal haben, das sich um den Betrieb kümmern kann, auch wenn unser Experten-Support-Team Sie maximal mit zugesicherten Reaktionszeiten unterstützt, so dass Sie auf Ihrer Seite keine Experten für Kryptografie oder Ähnliches benötigen.

Vorteile auf einen Blick

Sicherheit:

On Premise

Cloud Server

  • Sie legen fest, welche Anforderungen für das Rechenzentrum gelten,
check
check
  • Wie lange welche Dateien oder Daten im Server gespeichert werden und wann welche Daten gelöscht werden,
check
check
  • Welche Benutzer den Dienst nutzen können und welcher Benutzer welche Rolle hat,
check
check
  • Wie sich welcher Benutzer oder welche Benutzergruppe authentifizieren soll (z.B. Passwort oder Zwei-Faktor-Authenfizierung)
check
check
  • Dateien werden stets verschlüsselt entsprechend BSI-Richtlinien übertragen
check
check
  • Der Server ist mandantenfähig
check
check
  • Sie entscheiden, wann Updates eingespielt werden
check
check
  • Wir kümmern uns um ein TLS-Zertifikat
cross
check
  • Bei qualifizierter Signatur können Sie (oder wir) das Account beim Trustcenter beantragen¹
cross
check

¹: Anbindung des Trustcenters Komfortabel übers Webinterface

Aufwand:

On Premise

Cloud Server

  • Bereitstellung der Hardware
cross
check
  • Administration von Firewalls, Loadbalancern, usw.
cross
check
  • Sicherstellen der Verfügbarkeit des Signaturportals
cross
check
  • Einspielen von Updates und Patches für das Signaturportal
cross
check
  • Verwaltung des TLS-Zertifikats und dessen Gültigkeit für den Server
cross
check

Technische Anforderungen für den Betriebe

Die genauen Anforderungen hängen natürlich stark vom geplanten Nutzungsverhalten ab, z.B. wie viele Benutzer es in welcher Intensität nutzen sollen und wie sich die Nutzung auf einen Tag verteilt. Um eine ideale Nutzung des Signaturportals zu gewährleisten, müssen einige Anforderungen erfüllt werden.

server_anforderungen

Die Abbildung zeigt einen möglichen Infrastrukturaufbau für das Signaturportal. Hierbei muss man berücksichtigen, dass z.B. der Weg zum Remote Signature Provider (Fernsignaturdienst) natürlich nur dann nötig ist, wenn man z.B. qualifizierte Signaturen mit einem Fernsignaturdienst erstellen will. Dabei wird nur der Hashwert für die Signatur übertragen. Auch ist die Anbindung an ein Active Directory nur dann erforderlich, wenn gewünscht ist, dass ein bestehendes Active Directory für die Authentifizierung genutzt werden soll. Weitere Möglichkeiten sind die Anbindung eines Azure AD, ADFS, usw. oder die Nutzung einer internen Benutzerverwaltung des Signaturportals, so dass Sie kein Active Directoy oder Ähnliches benötigen. Ebenfalls können zahlreiche andere Datenbanken genutzt werden. So kann z.B. auch eine Default-Datenbank des Signaturportals genutzt werden. Die Mailserver-Anbindung ist dann relevant, wenn die E-Mails, die das Signaturportal verschickt (z.B. für eine Signaturanfrage), von Ihrer Firmendomain mit Ihrem Firmenabsender verschickt werden sollen. Ist dies nicht gewünscht, kann auch der interne Mailserver genutzt werden oder eben ganz auf Mails verzichtet werden.

Infrastruktur abhängig vom Signaturniveau:

Sie möchten qualifiziert mit einer Fernsignatur signieren:

Dabei müssen vom SecPKI-Server die URLs des Fernsignatuanbieters erreichen können. Das Signaturportal kann an alle europäischen Vertrauensdienste angebunden werden. Sie haben hier die freie Wahl. Die Anbindung erfolgt komfortabel über die Dashboard-Webseite.

Sie möchten fortgeschritten signieren:

Hier gibt es unterschiedliche Wege. Die beiden populärsten sind folgende: Sie lassen den Server die Zertifikate erstellen. Dieser Weg wird hauptsächlich für den internen Gebrauch genutzt. Als Alternative wird das CSM-Tool der Bundesdruckerei genutzt. Hier werden die vom Server erstellten Zertifikate mit einem Zertifikat der Bundesdruckerei bestätigt, so dass Sie z.B. auch einen grünen Haken in Adobe haben.

Sie möchten siegeln:

Hier müssen Sie unterscheiden zwischen einem Fernsiegel und dem Siegeln mit einer Siegelkarte. Für das Fernsiegeln gelten dieselben Anforderungen wie beim Einrichten des Vertrauensdienstes für die QES. Dies erfolgt ganz komfortabel über die Webseite. Bei der Siegelkarte muss gewährleistet werden, dass der Server auf die Siegelkarte oder das Siegel-HSM zugreifen kann.

Siegelkarte:

  • Das Signaturportal kann auch mit einer Siegelkarte, die an den Server angebunden wird, betrieben werden
  • Hierbei muss in der Infrastruktur berücksichtigt werden, dass der Server auf das Kartenlesegerät und damit auch die Siegelkarten zugreifen kann

Es kann eine Active-Directory-Anbindung, Azure-Anbindung oder SAML IDP geben:

  • Wenn für die Authentifizierung am Signaturportal z.B. das firmeneigene Active Directory genutzt werden soll
  • Es gibt auch hierfür einen komfortablen AD-Konnektor im Signaturportal-Dashboard
  • ADFS kann über SAML angebunden werden
  • Ein externes Active Directory muss nicht angebunden werden, es kann auch das interne Identity Management des Signaturportalservers genutzt werden
  • Azure kann z.B. über OAuth 2.0 oder auch über SAML angebunden werden

E-Mail-Server-Anbindung

  • Im Signaturportal wird - z.B. um die Teilnehmer eines Workflows per E-Mail über die neue Signaturanfrage zu informieren - eine E-Mail verschickt
  • Damit diese E-Mails von Ihrem Mail-Server verschickt werden, kann ein E-Mail-Server an den Signaturportalserver angebunden werden

Besonderheit:

  • Wenn auch Externe auf das Signaturportal zugreifen können sollen, müssen auch die Webseiten dafür erreichbar sein
  • Alternativ kann der Dienst auch komplett hinter der DMZ betrieben und feingranular über URL-Restriktionen geregelt werden, welche URLs nach außen dürfen und welche nicht

Das Signaturportal kann installiert werden auf:

  • allen Servern, auf denen Java läuft. Somit ist es plattformunabhängig.
  • auf einem Windows- Server
  • in einer VM
  • in einem Container (z.B. in einem Kubernetes-Cluster) u.v.m.

Beispiel für Ressourcen-Anforderungen:

Für ein kleines Szenario (die Dokumente in einem Workflows sollten hierbei nicht 50 MB überschreiten, und es sollten nicht mehr als 100 Workflows im Monat sein) empfehlen wir 4 vCPUs und 8 GB RAM.
Im Normalfall können 8 vCPUs und 16 GB RAM genommen werden. Für größere Set-Ups muss die Infrastruktur entsprechend angepasst werden. Eine Verbindung ins Internet zum gewählten Fernsignaturdienst auf Port 443 muss möglich sein.

Bitte kontaktieren Sie uns hier für Empfehlungen.

Kontakt

Ähnliche Themen