Richtlinie zur sedex-nutzung

Eidgenössisches Departement des Innern EDI Bundesamt für Statistik BFS Abteilung Register Bundesamt für Statistik (BFS), Dienstleitungserbringer von sedex 23.08.2016 Richtlinie zur sedex-nutzung 1 Ausgangslage 2 1.1 Zweck dieses Dokuments... 2 1.2 Zielpublikum... 2 1.3 Domänenvertreter... 2 2 Gesetzliche Grundlagen 3 3 Verantwortungen: allgemeine Grundsätze 4 4 Relevante sedex-teilnehmertopologien 5 4.1 Fall A: Physischer sedex-anschluss - Basisanschluss... 5 4.1.1 Mindestanforderungen... 6 4.1.2 Konsequenzen... 6 4.2 Fall B: Physischer sedex-anschluss - domänenübergreifend... 7 4.2.1 Ergänzende Anforderungen... 7 4.2.2 Konsequenzen... 7 4.3 Fall C: Logischer sedex-anschluss - domänenübergreifend... 8 4.3.1 Ergänzende Anforderungen... 8 4.3.2 Konsequenzen... 9 4.4 Fall D: Logischer sedex-anschluss - Generischer Router... 9 4.4.1 Ergänzende Anforderungen... 10 4.4.2 Konsequenzen... 10 4.5 Perpektive Interconnexion Anschluss Bus Bridge... 11

1 Ausgangslage Die Datenaustauschplattform sedex (secure data exchange) wurde Anfang 2008 im Rahmen der Harmonisierung der amtlichen Personenregister für die Durchführung der neuen Volkszählung aufgebaut. Seit der Inbetriebnahme hat sich die Nutzung der Plattform über viele weitere Domänen ausserhalb der Registerharmonisierung ausgedehnt. Neben der ursprünglichen und ordentlichen Implementierung (eine Organisation, ein sedex-teilnehmer, eine sedex-domäne) gibt es heute zunehmend komplexere, technisch sehr unterschiedliche Installationen und Konfigurationen, z.b. IT-Infrastrukturen, die einen Anschluss an sedex für mehrere Organisationen und Domänen über einen einzigen physischen sedex-client anbieten. Datenschutztechnisch kann dies problematisch sein. Aktuell entstehen bei der Neubestellung eines sedex-clients regelmässig Unsicherheiten bezüglich der Anschlussmöglichkeiten, z.b. logisch oder physisch oder ob ein sedex-client mit einer anderen Domäne geteilt werden darf. Eine einheitliche Regelung der Implementierungen ist notwendig geworden. 1.1 Zweck dieses Dokuments Die vorliegende Richtlinie trägt dieser Entwicklungen Rechnung. Die Implementierung von sedex in der IT-Infrastruktur der Betreiber wird kategorisiert und die damit verbundenen Zuständigkeiten und Verantwortungen beschrieben. Weiterhin werden die Mindestanforderungen, die für den sicheren Datenaustausch über die sedex-plattform gewährleistet sein müssen festgehalten. Die verschiedenen Anschlussmöglichkeiten (Topologien) werden nachfolgend dokumentiert. Anschliessend werden zu jeder Variante Zulassungskriterien, Massnahmen und Konsequenzen aufgezeigt. 1.2 Zielpublikum Dieses Dokument richtet sich sowohl an die Leistungsbezüger (LB) als auch an die verantwortlichen Personen der sedex-domänen (Domänenvertreter). Weiter angesprochen sind verantwortliche Personen von IT-Infrastrukturen und Betreiber von nachgelagerten Lösungen, wie Dispatcher, Busse oder meldungsverarbeitende Systeme. 1.3 Domänenvertreter Der Domänenvertreter stellt die Einhaltung der vorliegenden Richtlinie seines sedex-teilnehmerkreises sicher. Zu beachten ist dabei, dass die sedex-teilnehmer nicht unbedingt selber den Betrieb ihres sedex-anschlusses verwalteten. Sie können diesen allenfalls an Dritte weitergeben. 2/11

2 Gesetzliche Grundlagen Das Registerharmonisierungsgesetz (RHG, SR 431.02) bildet die gesetzliche Grundlage für die IKT- Plattform sedex des Bundes. So sind in den Artikeln 10 und 14 RHG die allgemeinen Vorschriften von sedex geregelt. Die Details für die Verwendung, Umsetzung, Kosten und Zuständigkeiten von sedex sind in der Registerharmonisierungsverordnung (RHV, RS 431.021) geregelt. Das BFS wird namentlich als verantwortliche Stelle beim Bund für sedex genannt. Die Nutzung von sedex zu weiteren behördlichen Zwecken ist in Art. 15 RHV geregelt. In solchen Fällen erfolgt der Datenaustausch über sedex nach den Richtlinien des BFS. Allfällige Nutzungsgebühren richten sich nach der Verordnung vom 25. Juni 2003 (SR 431.09) über die Gebühren und Entschädigungen für statistische Dienstleistungen von Verwaltungseinheiten des Bundes. Die Höhe der Gebühren und Entschädigungen ist unter www.sedex.ch > Governance publiziert. 3/11

3 Verantwortungen: allgemeine Grundsätze - Die Verantwortlichkeit des BFS als Leistungserbringer von sedex (BFS) endet in der Dateischnittstelle bzw. bei der Übergabe der Meldungen in die Verzeichnisse (In- und Outbox) im sedex-client, innerhalb der Infrastruktur des Leistungsbezügers (Abbildung 1). - Die korrekte Konfiguration der IT-Infrastruktur und des sedex-clients sowie die Einhaltung der Datenschutzbestimmungen obliegen der jeweiligen verantwortlichen Betriebsorganisation vor Ort. - Für die Inhalte der Meldungen sind die Absender bzw. die verantwortliche Domäne zuständig. - Für die Erneuerung der Zertifikate, welche ausserhalb des automatischen Erneuerungsprozesses eingesetzt werden, trägt der Leistungsbezüger resp. der Domänenverantwortliche die Verantwortung. - Die Details zum sedex-dienst sind in den Rahmen- bzw. Zusatzvereinbarungen mit den Domänen geregelt. - Der Leistungserbringer fakturiert allfällige Kosten der verantwortlichen Domäne. Eine allfällige Weiterverrechnung an die effektiven Teilnehmer ist Sache der sedex-domänen. Abbildung 1: Detailgrafik zum physischen sedex-anschluss. 4/11

4 Relevante sedex-teilnehmertopologien Der Begriff Topologie wird in diesem Kontext verwendet, um die effektiven sedex-installationen zu kategorisieren. Der nachfolgend beschriebene Basisanschluss gilt als einfachste anzunehmende Installation. Alle weiteren bauen auf diesem Basisanschluss mit steigenden Anforderungen auf. Abbildung 2: Legende zu den Grafiken. 4.1 Fall A: Physischer sedex-anschluss - Basisanschluss Eine Organisationseinheit (OE) resp. eine Fachstelle (FS) nutzt eine Fachanwendung für die Bearbeitung ihrer Geschäftsfälle. Merkmale: - Ein sedex-client ist physisch installiert. - Der sedex-teilnehmer ist einer sedex-domäne zugewiesen (Domäne 1). - Die Installation hat keine abhängigen logischen sedex-teilnehmer. - Es erfolgt keine weitergehende nachgelagerte Feinverteilung der Meldungen. Die Fachanwendung benutzt die sedex-client Verzeichnisse direkt. Abbildung 3: Die Fachstelle ist physisch angeschlossen. Einsatzbeispiel: Gemeinde, Krankenkasse. 5/11

4.1.1 Mindestanforderungen Im Folgenden erfolgt eine Auflistung der minimalen Anforderungen an die Infrastruktur mit einem sedex-client: - Die Rechtsgrundlagen und Vorgaben der verantwortlichen Domäne müssen eingehalten werden. - Die Installation muss gemäss sedex-handbuch erfolgen. - Die Infrastruktur, auf welcher der sedex-client installiert ist, muss den relevanten Datenschutzund Informatiksicherheitsvorgaben entsprechen. Die Betreiber sind aufgefordert sicherzustellen, dass es nicht zu doppelten Instanzen kommen kann. Doppelte Instanzen sind mehrere sedex-client Installationen, die sich mit derselben Identität melden, daher dasselbe sedex-zertifikat und dieselbe sedex-id verwenden. Dies kommt zum Beispiel dann vor, wenn der sedex-client auf einen neuen Server installiert wird, und der sedex-client auf dem alten Server nicht ordnungsgemäss zurückgebaut wird. Solche doppelte Instanzen verursachen regelmässig Probleme. Auf alle Fälle führt dies zu manuellen Eingriffen und Mehraufwänden aller Beteiligten. Um die negativen Auswirkungen einzuschränken, deaktiviert der sedex-support beide sedex-client, bis die Situation bereinigt ist. - Betreiber mit hochverfügbaren Umgebungen können unter www.sedex.ch > Download das Dokument sedex-client: Varianten für den Betrieb in einer hoch verfügbaren Umgebung als Hilfestellung beiziehen. - Die sedex-verzeichnisse dürfen ausschliesslich von der Fachanwendung der Organisationseinheit einsehbar sein. - Die Fachanwendung muss alle Meldungen inklusive deren Quittungen fehlerfrei verarbeiten. - Abhängig von der Konfiguration des sedex-clients können die Verzeichnisse des sedex-clients (z.b. processed oder sent) bereits verarbeitete Meldungen enthalten. Diese Verzeichnisse sind aktiv zu bewirtschaften. Werden die Meldungen nicht aus Archivgründen benötigt, sind diese definitiv zu löschen. Sie dürfen nicht in den Papierkorb verschoben werden. - Sicherheitselemente (Zertifikat der Klasse C, Passwörter) dürfen ausschliesslich im Rahmen der sedex-implementation verwendet werden. Die Nutzung hat gemäss den Vorgaben des aktuellsten sedex-handbuches zu erfolgen. Eine anderweitige Verwendung ist ausdrücklich nur mit der Einwilligung des Leistungserbringers (BFS) erlaubt. - Es soll jeweils zeitnah der neuste sedex-client installiert werden ( Life Cycle Management ) 4.1.2 Konsequenzen Die Topologie der Basisversion hat folgende Konsequenzen: - Die Meldungen sind innerhalb des sedex Perimeters End-to-End verschlüsselt. - Alle im sedex-client vorhandenen Meldungen sind der gleichen Fachstelle zugeteilt. - Die Nachvollziehbarkeit ist über den gesamten Transportweg gegeben. Entsprechende Reports sind verfügbar. - Das BFS stellt den Support sicher und ist für die korrekte Datenzustellung sowie sämtliche sicherheitsrelevanten Komponenten von sedex verantwortlich. 6/11

4.2 Fall B: Physischer sedex-anschluss - domänenübergreifend Eine Organisationseinheit (OE) bzw. eine Fachstelle (FS) nutzt mehrere dedizierte Fachanwendungen für die Bearbeitung ihrer Geschäftsfälle. Die Geschäftsfälle betreffen unterschiedliche sedex-domänen. Merkmale: - Ein sedex-client ist physisch installiert. - Der sedex-teilnehmer ist einer sedex-domäne zugewiesen (Domäne 1). - Die Installation hat keine abhängigen logischen sedex-teilnehmer. - Dem sedex-client nachgelagert erfolgt eine Feinverteilung mittels Meldungstyp der Meldungen durch Dritte. Abbildung 4: Die Organisationseinheit bzw. Fachstelle ist physisch angeschlossen. Einsatzbeispiel: Rechenzentrum von kleineren Gemeinden. 4.2.1 Ergänzende Anforderungen - Die Mindestanforderungen sind eingehalten (siehe Kapitel 4.1.1). - Diese Topologie ist nur für eine kleine Organisation zulässig (z.b. kleine Gemeinde, kleine AHV-Kasse usw.). - Die Freischaltung von Meldungstypen weiterer sedex-domänen, muss vom jeweiligen Domänenverantwortlichen des physischen sedex-teilnehmers genehmigt sein. - Ergänzend zu den Mindestanforderungen, dürfen die sedex-verzeichnisse nur von der nachgelagerten Lösung für die Feinverteilung einsehbar sein. - Wenn möglich, sind fachliche Quittungen in den Geschäftsfälle zu implementieren. 4.2.2 Konsequenzen Ein domänenübergreifender Anschluss hat folgende Konsequenzen: - Die Meldungen sind innerhalb des sedex Perimeters End-to-End verschlüsselt. Abhängig von einer nachgelagerten Feinverteilung sind die Meldungen allenfalls nicht End-to-End verschlüsselt. - Alle im sedex-client vorhandenen Meldungen sind der gleichen Fachstelle zugeteilt. Die jeweiligen Meldungen müssen durch die Fachanwendungen über die Meldungstypen richtig verarbeitet werden. - Die Nachvollziehbarkeit ist über den gesamten Transportweg gegeben. Entsprechende Reports sind verfügbar. Jede Domäne sieht nur ihre Meldungstypen. 7/11

- Das BFS stellt den Support sicher und ist für die korrekte Datenzustellung sowie sämtliche sicherheitsrelevanten Komponenten von sedex verantwortlich. 4.3 Fall C: Logischer sedex-anschluss - domänenübergreifend Eine Organisationseinheit (OE) bzw. Fachstelle (FS) nutzt mehrere dedizierte Fachanwendungen für die Bearbeitung ihrer Geschäftsfälle. Die Geschäftsfälle betreffen unterschiedliche sedex-domänen, z.b. das Bundesamt für Sozialversicherung, welches Daten in diversen Domänen austauscht. Merkmale: - Ein sedex-client ist physisch installiert, jede Organisationseinheit benutzt aber einen untergeordneten logischen sedex-teilnehmer. - Der physische sedex-teilnehmer ist einer sedex-domäne zugewiesen (Domäne 1). - Dem sedex-client nachgelagert erfolgt eine Feinverteilung der Meldungen durch Dritte via die sedex-id. - Der physische sedex-teilnehmer hat selber keine Berechtigungen. Abbildung 5: Die Teilnehmer (FS) sind logisch angeschlossen. Einsatzbeispiel: Rechenzentrum von einer Organisationsein heit. 4.3.1 Ergänzende Anforderungen - Die Mindestanforderungen sind eingehalten (siehe Kapitel 4.1.1). - Die Freischaltung von Meldungen weiterer sedex-domänen muss vom jeweiligen verantwortlichen Domänenverantwortlichen des physischen sedex-teilnehmers (Domäne 1) genehmigt sein. - Werden Meldungen physisch weitertransportiert, hat dies ausschliesslich innerhalb der Infrastruktur des Betreibers zu erfolgen. - Beim Anschluss eines neuen sedex-teilnehmers kann der Domänenverantwortliche des physischen sedex-teilnehmers eine Architekturbeschreibung (z.b. Architekturskizze oder Konzept) des effektiven sedex-anschlusses sowie ein Sicherheitskonzept einfordern. Die anderen Domänenvertreter müssen mit der Anschlusstopologie einverstanden sein. 8/11

4.3.2 Konsequenzen Die beschriebene Topologie hat folgende Konsequenzen: - Die Meldungen sind nicht End-to-End verschlüsselt, da nachgelagert eine Feinverteilung bis zum end Empfänger durch Drittlösungen erfolgt. - Die Nachvollziehbarkeit von sedex ist ausschliesslich bis zum physischen sedex-client sichergestellt. - Die im sedex-client vorhandenen Meldungen müssen den jeweiligen Fachstellen mit Hilfe der sedex-id zugeteilt werden. Die Meldungen müssen danach durch die Fachanwendungen über die Meldungstypen richtig verarbeitet werden. - Auswertungen für nachgelagerte Lösungen sind nicht beim Leistungserbringer erhältlich. - Der Leistungserbringer übernimmt keine Verantwortung für die korrekte Verarbeitung der Meldungen durch Drittlösungen. - Der Leistungserbringer bietet keinen Support für Drittlösungen. - Allfällige Nachforschungen werden vom Leistungserbringer nach dem Prinzip best effort erbracht. 4.4 Fall D: Logischer sedex-anschluss - generischer Router Mehrere Organisationseinheiten (OE) bzw. Verwaltungsstellen nutzen mehrere dedizierte Fachanwendungen für die Bearbeitung ihrer Geschäftsfälle. Die Geschäftsfälle können unterschiedliche sedex-domänen betreffen. Der Sedex-Client funktioniert in dieser Konstellation als Router. Abbildung 6: Alle Organisationseinheiten (OE) sind logisch angeschlossen. Einsatzbeispiel: Kantonale Organisationen oder Hosting-Anbieter von Fachanwendungen. Merkmale: - Ein sedex-client ist physisch installiert. Jede Fachanwendung bzw. Organisationseinheit verwendet einen separaten untergeordneten logischen sedex-teilnehmer mit einer sedex-identifikation. - Dem sedex-client nachgelagert erfolgt eine Feinverteilung der Meldungen durch Dritte (mittels einem Dispatcher oder einer ähnlichen Komponente). - Der physische sedex-teilnehmer hat selber keine Berechtigungen. 9/11

- Der physische Teilnehmer ist einer Domäne zugeordnet (Domäne 1), die logischen Teilnehmer können weiteren Domänen zugeordnet sein. 4.4.1 Ergänzende Anforderungen - Die Mindestanforderungen sind eingehalten (siehe Kapitel 4.1.1). - Diese Topologie ist nur für grössere Organisationen zulässig (z.b. Rechenzentrum für Gemeindelösungen, kantonales Rechenzentrum). - Die Freischaltung von Meldungen weiterer sedex-domänen muss vom jeweiligen Domänenverantwortlichen des physischen sedex-teilnehmers genehmigt sein. - Alle beteiligten Domänenvertreter müssen über diese Topologie in Kenntnis gesetzt werden und sich damit einverstanden erklären. Die Koordination erfolgt direkt durch die Domänenvertreter. - Beim Anschluss eines neuen sedex-teilnehmers kann der Domänenverantwortliche des physischen sedex-teilnehmers eine Architekturbeschreibung (z.b. Architekturskizze oder Konzept) des effektiven sedex-anschlusses sowie ein Sicherheitskonzept einfordern. Die anderen Domänenvertreter müssen mit der Anschlusstopologie einverstanden sein. - Die Domänenvertreter können bei Bedarf die korrekte Umsetzung der Anschlusstopologie (gemäss Architekturbeschreibung) und des Sicherheitskonzeptes beim Hostingpartner vor Ort überprüfen. 4.4.2 Konsequenzen Die beschriebene Topologie hat folgende Konsequenzen: - Die Meldungen sind nicht End-to-End verschlüsselt, da nachgelagert eine Feinverteilung bis zum end Empfänger durch Drittlösungen erfolgt. - Die Nachvollziehbarkeit von sedex ist ausschliesslich bis zum physischen sedex-client sichergestellt. - Die im sedex-client vorhandenen Meldungen müssen den jeweiligen Organisationseinheiten mit Hilfe der sedex-id zugeteilt werden. Die Meldungen müssen anschliessend durch die Fachanwendungen über die Meldungstypen richtig verarbeitet werden. - Auswertungen für nachgelagerte Lösungen sind nicht beim Leistungserbringer erhältlich. - Der Leistungserbringer übernimmt keine Verantwortung für die korrekte Verarbeitung durch Drittlösungen. - Der Leistungserbringer bietet keinen Support für Drittlösungen. - Allfällige Nachforschungen werden vom Leistungserbringer nach dem Prinzip best effort erbracht. 10/11

4.5 Perpektive Interconnexion Anschluss Bus Bridge Diese Konstellation wird als ein möglicher Ausblick beschrieben. Eine solche Konstellation gibt es heute noch nicht. Zwei Busbetreiber ermöglichen ihren Busteilnehmern, die Daten transparent auszutauschen. In diesem Fall gibt es keine sedex-id für jede Fachapplikation resp. Organisationseinheit. Die Busteilnehmer haben eigene Busidentifikationen. Die Teilnehmer sind also physische Teilnehmer eines Partnerbusses. Der Übergang von sedex zum Partnerbus erfolgt über eine sogenannte Bridge. Wenn der Partnerbus die gleichen Anforderungen wie der sedex-bus erfüllt, dann entspricht diese Konstellation wiederum einer Standardinstallation von sedex mit einem physischen Client pro Teilnehmer. Daher ist eine End-to-End Verschlüsselung der Busteilnehmer vorhanden. Abbildung 7: Mögliche Topologie eines Anschlusses über Interconnexion. Glossar AdminPKI Infrastruktur BUS LB LE LT PT Public-Key-Infrastruktur des BIT (Swiss Government PKI) Sie dient der Erstellung der sedex-zertifikate. Transportinfrastruktur für einen asynchronen Meldungsaustausch Leistungsbezüger des sedex-angebots (eine Domäne) Leistungserbringer Im vorliegenden Dokument ist immer das BFS als Dienstleistungsanbieter von sedex gemeint. Logischer sedex-teilnehmer Physischer sedex-teilnehmer Änderungsverzeichnis Version Datum Autor Änderung 1.5 23.08.2016 Antonio Stoppelli Ergänzung doppelte Instanzen 1.4 20.02.2016 Patrick Kummer Überarbeitung 11/11