für das E-Government
|
Open Source für das E-Government |
|
Die E-Government Box ist ein System, das nur mehr für die spezielle Organisation (z.B. Gemeinde) parametrisiert werden muss und dann einfache Bescheide/Erledigungen und Anbringen, die Verpflichtung zur Veröffentlichung im Internet, die Rekonstruktionsinformation (Rekonstruktion), sichere ausgehende Mail (signiert) und Eingangskommunikation (Formulare, die gesichert in der Mail landen) umsetzt.
Die E-Government Starterbox soll aus handelsüblichen Komponenten und Teilen bestehen, die für die Verwaltung frei verfügbar sind bzw. Open Source Produkte darstellen. Komponenten umfassen etwa Drucker, DVD-Schreiber zru Sicherung oder Smartcard-Leser (SC-Reader) zum Zugriff auf Bürgerkarten (siehe nachfolgende Abbildung).
Abbildung: E-Government Box System bestehend aus handelsüblichen Komponenten
Das System wird auf Basis zweier unterschiedlicher Betriebssysteme (im Weiteren mit Funktionsdomänen bezeichnet) realisiert, da betriebssystemübergreifende Attacken bis dato noch nicht bekannt sind. Um eine hohe Sicherheit zu gewährleisten, werden beide Funktionsdomänen innerhalb einer DMZ betrieben, d.h. beide Funktionsdomänen werden von einer Firewall vor Attacken geschützt. Im Weiteren werden die beiden Funktionsdomänen einerseits als "Äußere Funktionsdomäne" bzw. "Äußere Domäne", andererseits als "Geschützte Funktionsdomäne" bzw. "Geschützte Domäne" bezeichnet.
Um sensible Daten bei Verlust oder Diebstahl zu schützen, werden die Systemteile der Geschützten Domäne stark verschlüsselt abgelegt. Die Applikationen der Geschützten Funktionsdomäne sind dabei nur über TCP/IP und nur von der Äußeren Domäne bzw. vom LAN der Organisation zugänglich. Die kritischen Dienste der Geschützten Funktionsdomäne sind ausschiesslich innerhalb dieser Domäne zugänglich und es darf keine eingehende Verbindung von ausserhalb auf diese Module zugelassen werden.
Das Grundkonzept umfasst die Segmentierung des Systems in Domänen über virtuelle Machinen, wobei die Äussere Domäne (das "Wirt-System") nur sicherheitstechnisch unkritische Funktionen oder Daten zur Verfügung stellt. In dieser Domäne ist ein weiteres System (das "Arbeits-System") eingebettet, das verschlüsselt abgelegt ist und nur nach starker Authentifizierung über die Bürgerkarte aktiviert werden kann. Diese Domänentrennung entspricht einem Schalenmodell, wobei die inneren Schalen die sicherheitskritischen Elemente enthalten. Die folgende Abbildung stellt dieses Szenaro dar, wobei in der linken Darstellung das Arbeitssystem betriebsbereit ist (die über Verschlüsselung mit Bürgerkarte gegebene Sicherung geöffnet), in der rechten Abbildung ist die Geschützte Funktionsdomäne nicht betriebsbereit (geschlossen) und damit selbst bei Diebstahl des Gesamtsystems nicht kompromittierbar.
Abbildung: Segmentierung des Systems
Die Spezifikation ist modular aufgebaut, sodass je nach Anforderung einzelne Module nicht explizit in das System integriert werden müssen.
Die Spezifikation teilt das Gesamtsystem in
Jeder Layer enthält einzelne Komponenten, die getrennt spezifiziert werden. Die Kommunikation zwischen Komponenten und über Schichten hinweg wird ebenfalls spezifiziert.
Die aktuelle Grund-Ausbaustufe umfasst eine Äußere Funktionsdomäne (das "Wirt-System") und eine geschütze Funktionsdomäne (das "Arbeits-System"). Grundsätzlich erlaubt die modulare Spezifikation erweiterte und verschachtelte Konfigurationen, etwa über mehrere "Arbeits-Systeme", die unterschiedliche Funktionen umfasssen. Eine derartige Variante ist in Folge dargestellt, wobei die Bereiche . "ELAK" und "Intranet" gesondert und allenfalls über verschiedene Bürgerkarten oder Kombinationen von Bürgerkarten sicherbar sind.
Abbildung: Äußere Funktionsdomäne
Um für besondere Einsatzgebiete einen hohen Grad an Sicherheit oder für besondere Performanceanforderungen eine Trennung auf verschiedene Systeme zu gewährleisten, erlaubt die modulare Spezifikation, die beiden Funktionsdomänen physikalisch voneinander zu trennen. Sowohl die Äußere Domäne, als auch die Geschützte Domäne laufen auf unterschiedlichen Rechnern und unterschiedlichen Betriebssystemen, wie in der Abbildung dargestellt.
Abbildung: E-Government Box mit hoher Sicherheit
Um besonderen Sicherheitsanforderungen zu begegnen, werden die beiden Systeme über eine Hardware-Firewall sowohl vom LAN als auch voneinander entkoppelt, und laufen somit jeweils in einer eigenen DMZ.
Die Firewall muss dabei so konfiguriert sein, dass die Ports für die öffentlichen Dienste des Rechners (HTTP und HTTPS) der äußeren Domäne nach „aussen“ (Internet) freigeschaltet werden. Die sicherheitskritischen Applikationen der inneren Domäne dürfen dabei über die Firewall von der Äußeren Domäne bzw. vom LAN der Organsiation aus sichtbar sein.
Die Abhängigkeiten der Komponenten werden mit Hilfe von vier Layern dargestellt:
Die Komponenten eines Layers sind von allen Komponenten der übergeordnetetn Layer abhängig. Abhängigkeiten von Komponenten im gleichen Layer werden durch Pfeile repräsentiert.
Abbildung: Schichtenmodell des Konzepts "E-Government Box"
Die nachfolgende Abbildung zeigt das Kommunikationsmodell des Konzepts "E-Government Box". Die Kommunikationspfade werden mit Pfeilen dargestellt. Die Richtung des Pfeils entspricht der Richtung vom Initiator der Kommunikationsbeziehung.
Abbildung: Kommunikationsmodell des Konzepts "E-Government Box"
Die Äußere Funktionsdomäne stellt nicht sicherheitskritische Applikationen und Dienste zur Verfügung. Dazu zählen in erster Linie jene Applikationen und Dienste, die der BürgerIn zur Verfügung gestellt werden. Dies sind beispielsweise ein einfaches Anbringen oder Ankündigungen laut E-Government Gesetz. Als Schnittstelle zur BürgerIn fungiert ein Microsoft IIS Webserver. Um jedoch auch Applikationen anbieten zu können, die eine starke Authentifizierung und Identifikation durch die Bürgerkarte erfordern, agiert in der Äußeren Funktionsdomäne ein Tomcat Application Server mit den Module MOA-ID und MOA-SP. Dieser wird aus Gründen der Flexibilität durch den IIS maskiert.
Im Grundkonzept, in dem das System über eine virtuelle Maschine segmentiert wird, werden die Partitionsdaten der Geschützten Funktionsdomäne über eine Bürgerkarte stark verschlüsselt abgelegt, um die Daten im Falle von Verlust oder Diebstahl vor dem Zugriff durch Dritte zu schützen.
Aus Sicherheitsgründen befindet sich die Äußere Funktionsdomäne innerhalb einer DMZ, die durch eine Firewall vom Internet und dem LAN der Organisation entkoppelt ist. Die Firewall lässt nur die notwendigen Verbindungen nach außen/innen zu. Weiters ist es notwendig den Verkehr der Geschützten Funktionsdomäne mit Hilfe von NAT (Network Address Translation) zu maskieren.
Die Plattform besteht aus dem Betriebssystem Windows XP, der Firewall und dem Virenscanner. Die Firewall und der Virenscanner werden zur Plattform gezählt, da sie auf einer Ebene agieren, auf der die Basisdienste aufbauen. Alle Netzwerkverbindungen ins Internet, in das LAN und die Geschützte Domäne werden von der Firewall überwacht. Speicherzugriffe und Zugriffe auf das Dateisystem werden vom Virenscanner überwacht. Die drei Komponenten Windows XP, Firewall und Virenscanner stellen so die Sicherheitsbasis der E-Government Box in Bezug auf Attacken aus dem Internet dar.
Als Betriebssystem der Äußeren Funktionsdomäne wird Windows XP verwendet, da die E-Government Box weder als Domänencontroller fungieren soll, noch irgendwelche serverspezifischen Dienste zur Verfügung stellt. Dies ist notwendig, um nicht die Sicherheit beider Funktionsdomänen zu gefährden. Folgende Maßnahmen werden getroffen, um die Sicherheit des Systems so weit wie möglich zu erhöhen:
Detailierte Spezifikation: Windows XP
Die Firewall regelt den netzwerkbasierten Zugriff auf Dienste sowohl vom Internet als auch vom LAN der Organisation. Die Firewall darf nur notwendigen Verbindungen zulassen und schützt beide Domänen. Sowohl die Äußere als auch die Geschützte Funktionsdomäne befinden sich innerhalb einer DMZ. Die Firewall der Äußeren Funktionsdomäne soll so weit wie möglich ohne Benutzerinteraktion agieren. Die Verwendung einer Personal Firewall, die in der Lage ist, Verbindungen auf Applikationsebene zu verwalten, ergibt in der Äußeren Domäne keinen Sinn, da die Applikationen in der Geschützten Domäne installiert sind. Die Firewall kann also Verbindungen der Applikationen der Geschützten Domäne nur auf Netzwerkebene inspizieren.
Detailierte Spezifikation: Firewall
Der Virenscanner stellt den Grundschutz vor Viren, Würmer und Trojaner her. Buffer-Overflows oder schädliche Software, die entweder durch Sicherheitslücken des Betriebssystems oder durch den Benutzer in das System eingeschleust werden, sollen so schnell erkannt und wenn möglich automatisch entfernt werden. Der Virenscanner muss in regelmässigen Zuständen seine interne Virendatenbank automatisch aktualisieren können.
Detailierte Spezifikation: Virenscanner
In der Äußeren Funktionsdomäne ist eine Java VM installiert, die von folgenden Basisdiensten verwendet wird:
Detailierte Spezifikation: Java VM
SecureEFS bietet für die E-Government Box einen Diebstahlschutz sensibler Daten unter dem Einsatz starker Verschlüsselung. SecureEFS basiert auf dem mit Microsoft® Windows 2000/XP/Windows Server 2003 integriertem Dateiverschlüsselungssystem Encrypting File System (EFS). Daten werden seit Windows XP Service Pack 2 mit dem starken Verschlüsselungsalgorithmus AES-256 verschlüsselt. SecureEFS verstärkt dieses Dateiverschlüsselungssystem mit der Verschlüsselung des privaten EFS Schlüssels über die österreichische Bürgerkarte. Mit SecureEFS verschlüsselte Daten können daher nur über die Bürgerkarte freigeschalten werden. Dies garantiert einen hochgradigen Schutz sensibler Daten vor Diebstahl.
Um Applikationen im Falle von Verlust oder Diebstahl vor Zugriff Dritter zu schützen, werden die Geschützte Domäne, der S/MIME Mapper, der Tomcat Application Server und der Proxytunnel durch das bürgerkartenbasierte Verschlüsselungstool SecureEFS geschützt. SecureEFS wird mit dem Computerkonto installiert, mit dem die E-Government Box initialisiert wird. Die Daten können nur von diesem Computerkonto aus mit der Bürgerkarte freigeschalten werden. Erst nach dem Freischalten von SecureEFS, das nach jedem Neustart des Rechners durchgeführt werden muss, kann das Betriebssystem der Geschützten Funktionsdomäne gestartet werden
Dieses Dokument beschreibt die Anforderungen, Installation und Referenzkonfiguration von SecureEFS für die E-Government Box.
Detailierte Spezifikation: SecureEFS
Für die Verwendung von SecureEFS muss eine Bürgerkartenumgebung installiert sein. Diese muss in der Äußeren Funktionsdomäne installiert sein, um eine Kompatibiltät mit diversen Kartenlesern zu gewährleisten. Anwendungen und Dienste der Geschützten Funktionsdomäne, die ebenfalls eine BKU benötigen, können über eine Proxytunnelverbindung mit der BKU der Äußeren Funktionsdomäne kommunizieren. Die BKU MUSS die SecurityLayer Schnittstelle mit einer Mindestversion von 1.2 unterstützen, um die XML Verschlüsselungsoptionen nutzen zu können.
Detailierte Spezifikation: BKU
Abhängig von: SecureEFS
Die virtuelle Maschine emuliert einen kompletten PC für die Geschützte Domäne. Dadurch ist es möglich, Linux als Betriebssystem für die Geschützte Domäne zu verwenden, was auch eine erhöhte Sicherheit mit sich bringt, da es bis zum jetzigen Zeitpunkt noch keine betriebsystemübergreifende Attacken bekannt sind.
Die Partitionsdateien der Geschützten Domäne werden mit SecureEFS verschlüsselt, um die Daten bei Verlust oder Diebstahl sicher vor dem Zugriff durch Dritte zu schützen.
Detailierte Spezifikation: Virtuelle Maschine
Abhängig von: Java VM
In der äußeren Funktionsdomäne wird die serverseitige Komponente des IAIK Proxytunnels installiert, um authentifizierte und gesicherte Verbindungen in diesen Domänenbereich zu ermöglichen. In erster Linie wird diese Komponente benötigt, um Verbindungen zur BKU zu ermöglichen, die nicht vom lokalen Rechner kommen. Dienste der Geschützten Domäne, die auf die BKU der Äußeren Funktionsdomäne zugreifen, verwenden diese Proxytunnelkomponente.
Detailierte Spezifikation: Proxytunnel
Ein Webserver in der Äußeren Funktionsdomäne ermöglicht das Veröffentlichen von Informationen der Organisation laut E-Government Gesetz, ein Allgemeines Anbringen oder andere Dienste für den BürgerIn. Als Webserver fungiert ein IIS 6.0 mit reduzierter Funktionalität, um der Ausnutzung unbekannter Sicherheitslücken (Exploits) vorzubeugen und damit die Sicherheit zu erhöhen. Serverseitige Applikationen und Skriptsprachen werden standardmässig nicht zur Verfügung gestellt, können aber manuell aktiviert werden. Der IIS ist dem Tomcat Application Server "vorgeschaltet", auf dem serverseitige Java Applikationen installiert werden können.
Detailierte Spezifikation: Webserver
Abhängig von: Java VM
Um Webservices und Webapplikationen auf Basis der Programmiersprache Java anbieten zu können (JSP, Servlets), ist in der Äußeren Funktionsdomäne ein Tomcat Application Server installiert. Bestimmte Applikationen und Dienste, welche direkte oder weitergeleitete Verbindungen aus dem Internet oder einem anderen ungeschützten Netzwerk benötigen, werden aus Sicherheitsgründen nicht in den Tomcat Application Server der geschützten Funktionsdomäne integriert, um direkte Verbindungen aus dem unsicheren Netzwerk zu Applikationen in die Geschützte Domäne zu vermeiden. Der Tomat Server ist vom Internet aus nicht direkt erreichbar, sondern wird vom IIS über ein Weiterleitungs-Plugin maskiert. Dies ermöglicht sowohl die Nutzung von JSP Seiten und Java Serverapplikationen, als auch die schnelle Verarbeitung von statischem Inhalt durch den IIS. MOA-ID und MOA-SP sind die Kerndienste, die auf diesem Server betrieben werden, um BürgerInnen die Möglichkeit geben, sich bei Diensten und Applikationen der Organisation zu authentifizieren bzw. digitale Signaturen behördlicher Dokumente verifizieren zu können.
Detailierte Spezifikation: Tomcat Application Server
Abhängig von: Tomcat Application Server
Siehe Tomcat Authentication Plugin Geschützte Domäne
Abhängig von: Tomcat Application Server
Im Konzept "E-Government-Box" ist vorgesehen, dass Applikationen auf der Box dieses Modul für die Überprüfung von XML Signaturen verwenden. Dies inkludiert sowohl Applikationen aus der Geschützten Domäne, als auch Applikationen aus der äußeren Funktionsdomäne.
MOA-SP wird in der äußeren Funktionsdomäne überlicherweise von Applikationen verwendet, die einen Input für eine Signaturprüfung vom Internet oder vom behördeninternen Netz erhalten. In den meisten Fällen wird kein Zugriff aus der geschützten Funktionsdomäne stattfinden. Die Referenzkonfiguration der E-Government Box enthält keine Komponente in der geschützten Domäne, die einen Zugriff auf das Signaturprüfungsmodul benötigen würde.
Das Modul MOA-SP DARF jedoch NICHT direkt vom Internet aus zugänglich sein. Daher MUSS eine Signaturprüfung in jedem Fall über eine intermediäre Applikation erfolgen. Über eine entsprechende Firewall Regel wird der Zugriff auf das MOA-SP Modul vom Internet aus gesperrt, jedoch kann ein Zugriff aus der geschützten Domäne sowie dem Organisationsnetz problemlos erfolgen.
Detailierte Spezifikation: MOA-SP
Abhängig von: Tomcat Application Server
Im Konzept "E-Government Box" ist vorgesehen, dass Applikationen auf der Box dieses Modul für die Authentifikation und Identifikation der Benutzer verwenden können. Dies inkludiert sowohl Applikationen in der geschützten Domäne, als auch Applikationen in der äußeren Funktionsdomäne.
Applikationen in der äußeren Funktionsdomäne benötigten hauptsächlich die Identifikation und Authentifikation von Benutzern, die vom Internet aus in einer identifizierten und authentifizierten Umgebung arbeiten. Dies sind in der Regel Applikationen für Bürger, die sich vom Internet aus an einer speziellen Online-Applikation identifizieren und authentifizieren müssen.
Nur organisationsinterne Benutzer dürfen auf Applikationen der geschützten Domäne zugreifen. Um einen hohen Grad an Sicherheit zu gewährleisten, wird der Zugriff einerseits über eine Firewall nur vom behördeninternen Netz erlaubt, und zudem wird ein stark authentifizierter und identifizierter Zugang über das Servermodul MOA-ID verwendet.
Online Applikationen, die bereits über einen authentifizierten Zugang - z.B. Benutzername und Passwort - verfügen, können über das MOA-ID Proxy Modul an die bürgerkartenbasierte Authentifikation angepasst werden. Für Online-Applikationen, die noch nicht über einen authentifizierten und identifizierten Zugang über MOA-ID verfügen, und zudem auf einem Tomcat Application Server betrieben werden, wird empfohlen das Tomcat Authentication Plugin zu verwenden, da dessen Integration und Administration mit relativ geringem Aufwand verbunden ist.
Detailierte Spezifikation: MOA-ID
Abhängig von: Tomcat Application Server
Im Rahmen der Eingangskommunikation stellt das Konzept "E-Government Box" in der ersten Phase ein sogenanntes "Einfaches Anbringen" zur Verfügung.
Über ein einfaches und vordefiniertes Webformular kann der Antragsteller einen Antrag an die Organisation übermitteln. Dieser wird mit optionalen Anlagen mit der Bürgerkarte digital signiert und über die sichere ausgehende Mail an den zuständigen Sachbearbeiter/-in bzw. für die Rückantwort an den Antragsteller weitergeleitet.
Detaillierte Spezifikation: Einfaches Anbringen
Abhängig von: Virtuelle Maschine
Die Geschütze Domäne nutzt die von der Äußeren Domäne zur Verfügung gestellten Netzwerkverbindungen, um mit den benötigten Diensten und dem Internet kommunizieren zu können. Das Betriebssystem der Äußeren Domäne ist das Default Gateway für das Betriebssystem der Geschützten Domäne.
In der Geschützten Domäne läuft aus Sicherheitsgründen ein von der Äußeren Domäne unterschiedliches Betriebssystem. Für die E-Government Referenzinstallation wird eine Debian Linux Distribution verwendet. Die Architektur der Komponenten ist jedoch so ausgelegt, dass allenfalls auch andere Linux Distributionen eingesetzt werden können.
Da die Daten der Geschützten Domäne stark verschlüsselt abgelegt werden, kann auf die Dienste der Geschützten Domäne nur über das Netzwerkinterface von der Äußeren Domäne, dem LAN oder dem Internet zugegriffen werden. Die Firewall ist daher eine der kritischsten Komponenten der Geschützten Domäne.
Die Geschützte Funktionsdomäne stellt alle sicherheitskritischen Dienste zur Verfügung. Dazu zählen in erster Linie die Applikationen für das Ausstellen von Bescheiden und die MOA-Dienste die dafür benötigt werden. Dies sind in erster Linie MOA-SS (Serversignatur) zum Signieren behördlicher Dokumente und MOA-ZS (Elektronische Zustellung) zum Zustellen behördlicher Dokumente.
Um den Zugriff auf die Partitionsdaten von der Äußeren Funktionsdomäne während des laufenden Betriebes zu verhindern, werden die Daten in der Geschützten Domäne über die Bürgerkarte stark verschlüsselt abgelegt (SecureLinux).
Die Plattform besteht aus dem Betriebssystem Linux und der Firewall. Die Firewall wird zur Plattform gezählt, da sie auf einer Ebene operiert, auf der die Basisdienste und Applikationen der Geschützten Domäne aufbauen. Alle Netzwerkverbindungen ins Internet, in das LAN und die Äußere Domäne werden von der Firewall überwacht.
Linux wird als Betriebssystem für die Geschützte Funktionsdomäne verwendet. Für die Referenzinstallation wird eine Debian Linux Distribution verwendet. Die Installation des Betriebssystem ist so ausgelegt, dass bei Bedarf allenfalls eine andere Distribution verwendet werden kann. Um eine hohe Sicherheit der Geschützten Domäne garantieren zu können, werden folgende Maßnahmen getroffen:
Detailierte Spezifikation: Linux
[ TBD ]
Als Basisdienste werden jene essentiellen Dienste bezeichnet, die für den Betrieb der Applikationen der Geschützten Domäne benötigt werden. Dies sind in erster Linie eine Java VM, eine SQL-fähige Datenbank, der IAIK Proxytunnel sowie ein Tomcat Application Server.
In der Geschützten Domäne ist eine Java VM installiert, die von folgenden Basisdiensten benötigt wird:
Die Daten der VM werden ebenfalls mit SecureLinux verschlüsselt, um das Einspielen modifizierter Krypto-Bibliothken zu verhindern.
Detailierte Spezifikation: Java VM
[ TBD ]
Detailierte Spezifikation: SecureLinux
Abhängig von: Java VM
In der Geschützten Funktionsdomäne wird die server- und clientseitige Komponente des IAIK Proxytunnels installiert, um authentifizierte und gesicherte Verbindungen in/aus diesen/m sicherheitskritischen Domänenbereich zu ermöglichen. In erster Linie wird diese Komponente benötigt, um Verbindungen zur BKU der Äußeren Funktionsdomäne zu ermöglichen. Dienste der Geschützten Domäne, die auf die BKU der Äußeren Funktionsdomäne zugreifen, verwenden diese Proxytunnelkomponente.
Detailierte Spezifikation: Proxytunnel [SPEK Tunnel Geschützt fehlt noch]
Abhängig von: Java VM
Ausgehender Mail Verkehr der Organisation wird in der Angabe des Mailservers über die E-Government Box geführt und damit seitens der Organisation signiert. Dafür wird eine modifizierte Version des frei verfügbaren S/MIME Mappers verwendet. Die "From" Kopfzeile der ausgehenden Mail wird mit der vordefinierten Adresse des Organisationspostfachs befüllt, die "Reply-To" Kopfzeile mit der Adresse des Sachbearbeiters ("From" Kopfzeile der ursprünglich ausgehenden Mail).
Dieses Dokument beschreibt die Anforderungen, die Installation sowie eine Referenzkonfiguration des S/MIME Mappers für den Einsatz in der E-Government Box.
Detailierte Spezifikation: S/MIME Mapper
Abhängig von: Java VM
Um sicherheitskritische MOA Dienste und Applikationen zu betreiben, ist in der Geschützten Funktionsdomäne ein Tomcat Application Server installiert. Diese Applikationen sind ausschliesslich von der Äußeren Funktionsdomäne bzw. dem Organisationsnetz stark authentifiziert und identifiziert zugänglich. Speziell die MOA Dienste, die von den Applikationen der Geschützten Domäne verwendet werden, sind nur von innerhalb der Geschützten Domäne aus zugänglich.
Zu den kritischen Diensten, welche in dieser Serverumgebung laufen, zählen in erster Linie MOA-SS, MOA-ZS und das Tomcat Authentication Plugin. Diese Dienste dürfen ausschliesslich von der Geschützten Funktionsdomäne aus zugänglich sein.
Das E-Government Box Administrationstool und die Bescheiderstellung aus Word gehören zu den Applikationen, die in dieser Serverumgebung laufen und von der Äußerern Funktionsdomäne bzw. dem Organsationsnetz aus zugänglich sind.
Dataillierte Spezifikation: Tomcat Application Server
Abhängig von: Tomcat Application Server
Das Modul MOA-SS dient zum Erstellen von XML-Signaturen in Anlehnung an die Schnittstellenspezifikation des Security-Layers (V 1.1). Eine Signatur kann entweder rein in Software erstellt werden, oder aber unter Zuhilfenahme eines Hardware Security Modules (HSM), das den privaten Schlüssel geschützt enthält und die Signatur berechnet.
Der Zugriff auf einzelne Signaturschlüssel in MOA SS kann basierend auf dem für TLS-Client-Authentisierung verwendeten Zertifikat eingeschränkt werden.
Anwendungen können das Modul entweder als Web-Service oder über ein Java-API ansprechen.
Im Konzept "E-Government-Box" ist vorgesehen, dass Applikationen dieses Modul für die Erzeugung von XML Signaturen verwenden. Z.B. können elektronische Bescheide mit der Amtssignatur versehen werden. Das Modul kann ausschliesslich von Applikationen der Geschützten Domäne verwendet werden.
MOA-SS wird in der Geschützten Funktionsdomäne hauptsächlich von Bescheiderstellungsapplikationen und dem Zustellmodul MOA-ZS verwendet.
Das Modul MOA-SS DARF NICHT direkt über TCP/IP (HTTP/SOAP) von ausserhalb der Geschützten Funktionsdomäne zugänglich sein. Daher MUSS eine Signaturerstellung von ausserhalb in jedem Fall authentifiziert über eine intermediäre Applikation erfolgen. Über eine entsprechende Firewall Regel wird der Zugriff auf das MOA-SS Modul ausserhalb der Geschützten Funktionsdomäne gesperrt.
Detaillierte Spezifikation: MOA-SS
Abhängig von: Tomcat Application Server
MOA-ZS ist eine Middleware deren Aufgabe darin besteht, Fachapplikationen den Zugang zur elektronischen Zustellung zu erleichtern, indem sie die Zahl der Interaktionen mit externen Modulen (Adressierbarkeitsabfrage, bPK Umrechnung, Signatur, Zustellung) von 4 auf 1 reduziert. Das Hauptaugenmerk liegt auf der einfachen Handhabung der Kommunikation mit MOA-ZS.
MOA-ZS verarbeitet Zustellstücke in einem 2 Phasen System. Zunächst werden die Zustellstücke in einer synchronen Phase übernommen und überprüft. In der zweiten, asynchronen Phase, die ohne Verbindung mit der Absenderapplikation arbeitet, werden die Zustellstücke aufbereitet und an den jeweiligen Zustellserver übergeben.
Im Konzept "E-Government-Box" ist vorgesehen, dass Applikationen dieses Modul für die Zustellung von behördlichen elektronischen Dokumenten verwenden. Dies gilt in erster Linie für Applikationen der Geschützten Funktionsdomäne.
Es DARF NICHT direkt aus der Äußeren Funktionsdomäne auf die Zustellkomponente zugegriffen werden. Die Referenzkonfiguration der E-Government Box enthält keine Komponente in der Äußeren Domäne, die einen Zugriff auf das Zustellmodul benötigen würde.
Falls jedoch eine Zustellung aus der Äußeren Funktionsdomäne notwendig ist, MUSS dies stark authentifiziert über eine intermediäre Applikation erfolgen. Über eine entsprechende Firewall Regel wird der Zugriff auf das MOA-ZS Modul von aussen gesperrt, jedoch kann ein Zugriff aus der Geschützten Domäne problemlos erfolgen.
Detaillierte Spezifikation: MOA-ZS
Abhängig von: Tomcat Application Server
Das Modul MOA-Proxy & Notifier erweitert MOA-ZS um eine semi-synchrone Zustellfunktion. MOA-ZS bietet keine synchrone Zustellung, sondern informiert die Clientapplikation im Falle einer erfolgreichen oder fehlgeschlagenen Zustellung lediglich über einen asynchronen Kommunikationsmechanismus.
Der MOA-ZS Proxy & Notifier implementiert das Interface von MOA-ZS und kann daher an Stelle dessen verwendet werden. Jedoch werden asynchrone Benachrichtigungen hinter dem MOA-ZS Interface maskiert als Serverantwort an den Client retourniert. Erhält der Proxy & Notifier während einer Sitzung eine asynchrone Benachrichtigung, kann man von einer synchronen Zustellung sprechen. In jedem anderen Fall ist sie asynchron bzw. in einem Wartestatus, und die Zustellung unterscheidet sich nicht von einer Zustellung mit MOA-ZS. Die asynchrone Statusbenachrichtigung wird jedoch in einer Datenbank gespeichert und kann zu einem späteren Zeitpunkt abgerufen werden. Die elektronische Zustellung über das MOA Proxy & Notifier Modul kann daher als semi-synchron bezeichnet werden.
Detaillierte Spezifikation: MOA-ZS Proxy & Notifier
Abhängig von: Tomcat Application Server
Authentifizierungssmechanismen bestehender Applikationen können mit dem Servermodul MOA-ID integriert werden, indem entweder das MOA-ID Proxy Modul verwendet wird, oder die Applikation die SAML Authentifizierungsdaten vom MOA-ID Server holt und selbst die Adaption des Authentifizierungsmechnismus vornimmt. Für die erste Variante wird der gesamte Verkehr der Kommunikation permanent über den Proxy weitergeleitet und es werden nur bestehende Authentifizierungssmechanismen der MOA-ID Anmeldedaten angepasst (z.B. BASIC Authentication). Für die Variante des manuellen Abfragens der Anmeldedaten ist es relativ einfach Applikationen (z.B. Servlets) zu schützen, jedoch bleiben andere Resourcen innerhalb einer Webapplikation (HTML, JSP Dateien etc.) ungeschützt.
Das im Folgenden beschriebene Plugin für den Tomcat Application Server beschreibt einen rollenbasierten Zugriffschutz basierend auf einer Authentifizierung und Identifikation über das Servermodul MOA-ID. Mittels einer Single-Sign-On Lösung können beliebige Resourcen eines oder mehrerer Webcontainer über diesen Authentifizierungs- und Identifikationsmechanismus abgesichert werden. Es ist sogar möglich einzelne virtuelle Hosts oder im Kontext eines Webportals sogar den sämtlichen Application Server zu schützen.
Ziel dieses Plugins ist es einen über die Bürgerkarte stark authentifizierten und identifizierten Zugang zu Webapplikationen zu ermöglichen.
Detaillierte Spezifikation: MOA Tomcat Authentication Plugin
Alle sicherheitskritischen Applikationen und Dienste der Organisation werden in der Geschützten Domäne betrieben. Folgende Applikationen werden standardmässig auf der E-Government Box zu Verfügung gestellt.
Abhängig von: Tomcat Application Server
Zur Erstellung von Dokumenten sind Office-Anwendungen wie MS-Word am weitesten verbreitet. So auch im Bereich der öffentlichen Verwaltung.
So ermöglicht dies Applikation Word2Bescheid grundsätzlich die Erstellung von XML-Dokumenten einer vorgegebenen Struktur (Schema) mit MS-Word. Konkret können damit elektronische Bescheide direkt aus MS-Word als XML-Dokument exportiert, ggf. signiert und sogar elektronisch zugestellt werden.
Die Applikation "Word2Bescheid" ist im Konzept "E-Government Box" in der geschützten Funktionsdomäne angesiedelt und ist im öffentlichen Bereich des Tomcat Application Servers integriert. Dieser Bereich ist ausschliesslich vom Behördennetz aus zugänglich und kann zudem noch über einen stark authentifizierten und identifizierten Zugang abgesichert werden.
Detailierte Spezifikation: Word2Bescheid
Hier die Liste der detaillierten specs...
BRAUCHEN WIR GLOSSAR? - ggf. datei löschen.