1.1 Mitgeltende Dokumente

–

Internetbasierte Fahrzeugzulassung (i-Kfz) – Anlage Penetrationstest

–

Internetbasierte Fahrzeugzulassung (i-Kfz) – Grobkonzept – Version 2.0.2

Hinweis:

Es wird ausschließlich auf die Teile des zitierten Dokumentes verwiesen, welche die Umsetzung der 1. Stufe des i-Kfz-Projektes betreffen.

–

Informationen zur netztechnischen Anbindung an das Kraftfahrt-Bundesamt

1.2 Abkürzungsverzeichnis

Tabelle 2: Abkürzungsverzeichnis

1.3 Abbildungsverzeichnis

Abbildung  1:

Kommunikationswege zur internetbasierten Außerbetriebsetzung („Hamburger Kompromiss“; Stand 30. Juli 2014)

Abbildung  2:

Primäre Akteure und Anwendungen sowie Kommunikationsflüsse im i-Kfz-System

Abbildung  3:

Technische Architektur des i-Kfz-Systems – das Gesamtbild

Abbildung  4:

Netzwerkbereiche der definierten Architektur innerhalb i-Kfz

Abbildung  5:

Interner Aufbau der Komponente „KBA-Internet-Kom-Modul“ (schematische Darstellung)

Abbildung  6:

Interner Aufbau der Komponente „KBA-DOI-Kom-Modul“

Abbildung  7:

Verwendung der Schnittstelle A durch das zentrale Portal

Abbildung  8:

Verwendung der Schnittstelle A durch ein dezentrales Portal

Abbildung  9:

Verwendung der Schnittstelle B

Abbildung 10:

Verwendung der Schnittstelle C

Abbildung 11:

Zusätzliche Kommunikationsflüsse

Abbildung 12:

Erweiterte technische Architektur des i-Kfz-Systems

Abbildung 13:

Erweiterte Zusammenstellung der Netzwerkbereiche

Abbildung 14:

Schematische Darstellung des internen Aufbaus der Komponente „Internet-Cnn“

Abbildung 15:

Der Lebenszyklus einer Zulassung

1.4 Tabellenverzeichnis

Tabelle  1:

Änderungsverzeichnis

Tabelle  2:

Abkürzungsverzeichnis

Tabelle  3:

Aufbau einer Sicherheitsanforderung

Tabelle  4:

Zulassungsverfahren – Übergänge des Zustands „initial beantragt“

Tabelle  5:

Zulassungsverfahren – Übergänge des Zustands „gültig“

Tabelle  6:

Zulassungsverfahren – Übergänge des Zustands „eingeschränkt gültig“

Tabelle  7:

Zulassungsverfahren – Übergänge des Zustands „suspendiert“

Tabelle  8:

Zulassungsverfahren – Übergänge des Zustands „ungültig“

Tabelle  9:

Grobe Schritte des Beantragungsprozesses einer Zulassung

Tabelle 10:

Kontaktdaten des technischen Supports

Tabelle 11:

Kontaktdaten der Kundenbetreuung

Im Verfahren internetbasierte Fahrzeugzulassung (i-Kfz) werden schutzbedürftige Daten verarbeitet, insbesondere bei der Kommunikation mit den zentralen Registern des Kraftfahrt-Bundesamtes (KBA). Mit diesem Dokument werden Mindestanforderungen an die Informationssicherheit bei der Anbindung dezentraler Portale definiert, die zwingend zu erfüllen sind.

Im Zuge der Umsetzung der ersten Stufe i-Kfz zum 1. Januar 2015 kann die Antragstellung auf Außerbetriebsetzung eines Fahrzeugs – neben dem zentralen Zugang über das beim KBA betriebene i-Kfz-Portal – auch über dezentrale kommunale Portale erfolgen. In Diskussionen zwischen BMVI, KBA, BSI, Vertretern von kommunalen Spitzenverbänden, kommunalen IT-Dienstleistern und Zulassungsbehörden wurde eine grundlegende Architektur für die Kommunikationswege bei der Anbindung dezentraler Portale festgelegt („Hamburger Kompromiss“).

Die dezentralen Portale greifen über das Internet (unsicheres Netz) auf die KBA-Infrastruktur zu. Die Anforderung zur Öffnung der KBA-Netze für diese Kommunikation stellt eine neue Art des Zugriffs auf das Zentrale Fahrzeugregister (ZFZR) dar und bringt damit Gefahren in Bezug auf Sicherheit und Datenschutz mit sich.

Abbildung 1: Kommunikationswege zur internetbasierten Außerbetriebsetzung („Hamburger Kompromiss“; Stand: 30. Juli 2014)

Vor diesem Hintergrund ist die Datensicherheit der zentralen Register beim KBA sicherzustellen. Um dies zu gewährleisten, hat das KBA Mindestanforderungen an die Informationssicherheit für die Anbindung dezentraler Portale in Stufe 1 i-Kfz festgelegt.

Die Mindestanforderungen orientieren sich zunächst grundsätzlich am Schutzbedarf „normal“ jeweils für die Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit, z. T. gehen sie aufgrund spezifischer i-Kfz-Funktionalitäten darüber hinaus. Der Schutzbedarf für das i-Kfz-Verfahren wurde noch nicht abschließend bestimmt und die Vollständigkeit der Mindestanforderungen zur Erfüllung des Schutzbedarfes noch nicht geprüft. Ein entsprechendes Sicherheitskonzept mit ggf. integrierter Risikoanalyse existiert nicht. Somit ist eine ganzheitliche Betrachtung der Verfahrenssicherheit zum jetzigen Zeitpunkt noch nicht möglich. 

Aus Sicht des Bundesamtes für Sicherheit in der Informationstechnik (BSI) sind die vorliegenden Mindestanforderungen sinnvoll und angemessen und decken die wichtigsten Aspekte zur Informationssicherheit des i-Kfz-Verfahrens ab. Die Mindestanforderungen werden im weiteren Projektverlauf, abhängig von den Ergebnissen der UAG Datensicherheit, gegebenenfalls ergänzt und fortgeschrieben.

In diesem Kapitel wird der für das Projekt i-Kfz gegebene rechtliche Rahmen skizziert. Insbesondere wird auf die Rolle des KBA in Bezug auf die Ausgestaltung der Kommunikation zwischen KBA und Dritten eingegangen.

Es wurden folgende für das Projekt relevanten rechtlichen Grundlagen identifiziert:

–

Gesetz über die Errichtung eines Kraftfahrt-Bundesamts (KBAG)

–

Fahrzeug-Zulassungsverordnung (FZV)

–

Viertes Gesetz zur Änderung des Straßenverkehrsgesetzes und anderer Gesetze (4. StVGuaÄndG)

–

Bundesdatenschutzgesetz (BDSG)

Weiterführende geltende Regelungen:

–

Information zur netztechnischen Anbindung an das Kraftfahrt-Bundesamt für Behörden (vergleiche [IznAaKBAfB]).

Das KBA nimmt gemäß [KBAG], [FZV] und [StVGuaÄndG] eine zentrale Rolle in der Gestaltung der Schnittstellen für die Kommunikation zwischen KBA und Dritten ein. Die Vorgaben für die betroffenen Schnittstellen sowie alle damit verbundenen Modalitäten werden vom KBA festgelegt.

„Das Kraftfahrt-Bundesamt übernimmt […] für Zwecke der Zulassung von Fahrzeugen und der Zuteilung von Kennzeichen die Errichtung und den Betrieb informationstechnischer Systeme für eine zentrale elektronische, auch internetbasierte Verarbeitung von für diesen Zweck erforderlichen Daten und deren Weiterleitung an die für den Vollzug zulassungsrechtlicher Vorschriften zuständigen Behörden und Stellen“, gemäß § 2 Absatz 1 Nummer 2a KBAG.

Weiterhin gilt es gemäß Artikel 2 Nummer 6 Buchstabe b [FZVuGebOStÄndV]:

„(2) Erfüllen die abgestempelten Kennzeichenschilder die Anforderungen des § 10 Absatz 3 Satz 2 bis 4 und die Zulassungsbescheinigung Teil I eines Fahrzeugs die Anforderungen des § 11 Absatz 1 Satz 1 und 2, so kann das Fahrzeug auch dadurch außer Betrieb gesetzt werden, dass der Halter oder der Verfügungsberechtigte dies bei der Zulassungsbehörde elektronisch über ein vom Kraftfahrt-Bundesamt betriebenes informationstechnisches System beantragt, das sicherstellt, dass

1.

eine sichere Identifizierung des Antragstellers erfolgt und

2.

die vom Halter oder Verfügungsberechtigten an das Kraftfahrt-Bundesamt übermittelten Daten vom Kraftfahrt-Bundesamt vollständig und plausibel an die Zulassungsbehörde übermittelt werden (internetbasierte Außerbetriebsetzung).“

Für die Gestaltung der Schnittstelle zwischen KBA und Dritten wurde dem Bundesrat ein Vorschlag zur entsprechenden Ergänzung der FZV im Herbst 2014 zugeleitet:

„Soweit für die internetbasierte Außerbetriebsetzung auf Systembestandteile zurückgegriffen wird, die einen Zugang zu den Daten des Kraftfahrt-Bundesamtes ermöglichen, hat die Übermittlung der Daten nach Maßgabe eines vom Kraftfahrt-Bundesamt im Bundesanzeiger und nachrichtlich im Verkehrsblatt veröffentlichten Standards zu erfolgen.“

Das vorliegende Dokument definiert die Mindestsicherheitsanforderungen, die zwingend bei der Umsetzung der 1. Stufe des i-Kfz-Projektes (Beginn zum 1. Januar 2015) zu berücksichtigen sind.

Dieses Dokument beinhaltet darüber hinaus Anforderungen, bzw. Teile von Anforderungen, die für die 1. Stufe nicht verpflichtend sind. Sie sind gesondert durch eine entsprechende Fußnote gekennzeichnet. Ab der 2. Stufe des i-Kfz-Projektes (Beginn zum 1. Januar 2016) sind die gekennzeichneten Anforderungen (bzw. deren Teile) als muss-Kriterien anzusehen und somit auch zwingend zu erfüllen.

Zur Beschreibung der Kommunikation innerhalb des i-Kfz-Systems wird in den folgenden Kapiteln eine Architektur definiert. Ausgehend von einer funktional gehaltenen Beschreibung der Informationsflüsse zwischen beteiligten Akteuren und Anwendungen (vergleiche Kapitel 5.1) wird eine technische Sicht auf das Gesamtsystem dargestellt (vergleiche Kapitel 5.2), in der die relevanten Netzwerkbereiche (vergleiche Kapitel 5.3), die darin enthaltenen Komponenten (vergleiche Kapitel 5.4), sowie die Schnittstellen (vergleiche Kapitel 5.5) untereinander benannt und beschrieben werden.

Hinweis:

Die in diesem Kapitel vorgestellte Architekturbetrachtung bezieht sich ausschließlich auf das i-Kfz-System. Im Kapitel 6 sind zusätzliche Einflussfaktoren (z. B. bereits existierende Kommunikationsverbindungen) auf die i-Kfz-Architektur dargestellt und beschrieben.

5.1 Kommunikationsarchitektur innerhalb des i-Kfz-Systems

Die Abbildung 2 stellt die Anwendungen, die primären Akteure und die zulässigen Kommunikationsflüsse aus funktionaler Sicht dar¹. Es sind drei primäre Akteure beteiligt:

–

Antragsteller Bürger,

–

Antragsteller Großkunde,

–

Sachbearbeiter in der Zulassungsbehörde.

Weiterhin werden (gemäß Stufe 1 des i-Kfz-Projektes) folgende Anwendungen genutzt:

–

dezentrales Portal,

–

zentrales Portal,

–

Fachverfahren der Zulassungsbehörde,

–

KBA-Dienste.

Abbildung 2: Primäre Akteure und Anwendungen sowie Kommunikationsflüsse im i-Kfz-System

Antragsteller Bürger

Die Rolle „Antragsteller Bürger“ bildet alle Personen ab, die die Dienste des zentralen oder eines dezentralen Portals über die graphische Benutzeroberfläche (GUI) in Anspruch nehmen.

Es ist zu beachten, dass darüber hinaus die Möglichkeit besteht, dass die antragstellende Person über bereits heute schon existierende Schnittstellen mit dem Fachverfahren der Zulassungsbehörde kommuniziert, z. B. um einen Termin mit der Zulassungsbehörde zu vereinbaren, ein Wunschkennzeichnen zu reservieren oder auch die benötigten Eingaben vorerfassen. Diese Anwendungen gehören nicht zum Funktionsumfang des i-Kfz-Projektes und sind nicht Betrachtungsgegenstand dieses Kapitels, sondern werden gesondert bei den externen Einflussfaktoren auf die i-Kfz-Architektur (Kapitel 6) berücksichtigt.

Antragsteller Großkunde

Die Rolle „Antragsteller Großkunde“ bezeichnet alle Antragsteller, die anstatt der graphischen Benutzerschnittstelle eine maschinen-verarbeitbare Schnittstelle zur Übermittlung der Antragsdaten nutzen. In der Regel handelt sich hier um Antragsteller, die eine relativ große Anzahl an Zulassungsvorgängen auf einmal erledigen müssen, z. B. Autohändler, Autovermietungen oder Flottenbetreiber.

Diese Schnittstelle dient dabei ausschließlich der Nutzung durch einen spezifischen Antragsteller in einem nicht-öffentlichen Bereich. Die Sicherheit kann bei einem Zugang über kaskadierende Portale nicht kontrolliert werden, diese sind daher im Verfahren nicht zuzulassen.

Da eine Großkundenschnittstelle im zentralen Portal nicht vorgesehen ist, erfolgt die Kommunikation ausschließlich über die dezentralen Portale. Eine alternative Kommunikationsbeziehung (z. B. zum Fachverfahren der Zulassungsbehörde) ist im Rahmen des Projektes i-Kfz nicht zulässig.

Sachbearbeiter in der Zulassungsbehörde

Innerhalb der Zulassungsbehörden bearbeiten die Sachbearbeiter die seitens der Antragsteller (Bürger und Großkunden) beantragten Leistungen.

Zentrales Portal

Das KBA stellt Bürgerinnen und Bürgern, deren zuständige Zulassungsbehörde kein dezentrales Portal anbietet, die internetbasierte Außerbetriebsetzung über ein zentrales Portal zur Verfügung. Diese Komponente ist nur für die erste Stufe des i-Kfz-Projektes vorgesehen und wird mit der Realisierung der vollständigen Abdeckung durch die dezentralen Portale ab Stufe 2 des i-Kfz-Verfahrens entfallen.

Das „zentrale Portal“ nimmt die Anfragen des Akteurs „Antragsteller Bürger“ entgegen und kommuniziert mit der Anwendung „KBA-Dienste“.

Dezentrales Portal

Im Auftrag der Zulassungsbehörden werden dezentrale Portale betrieben, welche analog zum zentralen Portal für die Bürgerinnen und Bürger eine internetbasierte Außerbetriebsetzung anbieten. Darüber hinaus bietet ein dezentrales Portal ggf. eine Webservice-Schnittstelle für die Benutzung durch die Großkunden an.

Ein dezentrales Portal kommuniziert im Rahmen des i-Kfz-Projektes ausschließlich mit den vom KBA hierzu bereitgestellten Diensten, sofern die KBA-Infrastruktur berührt wird. Von einem „dezentralen Portal“ können weitere lokale Funktionalitäten genutzt werden, die aber keine primäre i-Kfz-Funktionalität darstellen (z. B. ePayment, elektronischer Identitätsnachweis oder lokale Kfz-Funktionalitäten) und mit Hilfe von Schnittstellen in Anspruch genommen werden. Auf die Betrachtung dieser Wege wird im Dokument verzichtet.

Hinweis:

Nicht alle ca. 420 momentan existierenden Zulassungsbehörden werden ein eigenes dezentrales Portal betreiben. Es können sich Cluster bilden, in denen mehrere Zulassungsbehörden ein dezentrales Portal, angeboten durch einen Dienstanbieter (z. B. ein Landesrechenzentrum), gemeinsam nutzen. In solchen Fällen ist idealerweise auf eine Mandantentrennung in Verbindung mit einer sicheren Virtualisierung bezogen auf die einzelnen Zulassungsbehörden innerhalb des Clusters zu achten. Insbesondere sind eindeutige Zuständigkeiten im Bereich des Service Managements und der Administration sicherzustellen und zu dokumentieren.

Fachverfahren Zulassungsbehörde

Ein Fachverfahren in einer Zulassungsbehörde stellt eine Anwendung dar, in der die Anträge auf Außerbetriebsetzung eines Fahrzeugs durch einen Mitarbeiter der Zulassungsbehörde bearbeitet werden. Das Fachverfahren kommuniziert auf zweierlei Weise mit den KBA-Diensten:

–

die im Rahmen des i-Kfz-Projektes gestellten Anträge werden seitens KBA dem Fachverfahren in der Zulassungsbehörde zur Verfügung gestellt und von der Zulassungsbehörde abgeholt (Kommunikationsverbindung: KBA-Dienste → Fachverfahren),

–

das Fachverfahren liefert die Ergebnisse der Vorgangsverarbeitung an das KBA (Kommunikationsverbindung: Fachverfahren → KBA-Dienste).

Diese Kommunikationsverbindungen sind bereits heute technisch realisiert und werden durch die Zulassungsbehörden (außerhalb des i-Kfz-Projektes) benutzt, um die vor Ort durchgeführten Zulassungsvorgänge an das KBA zu übermitteln.

Hinweis:

Innerhalb der Zulassungsbehörden werden Fachverfahren unterschiedlicher Hersteller eingesetzt.

KBA-Dienste

Diese Anwendung symbolisiert die vom KBA angebotenen Dienste, unter anderem die Registerführung des ZFZR.

Ein Teil der KBA-Dienste wird bereits von den Zulassungsbehörden benutzt.

Hinweis:

Es ist zu beachten, dass im Rahmen der 1. Stufe des i-Kfz-Projektes jegliche Kommunikation zwischen dem Antragsteller und den Zulassungsbehörden über die Portale (hier sowohl zentral als auch dezentral) und das KBA (hier die KBA-Dienste) erfolgen muss. Es ist nicht zulässig, dass Antragsteller oder die Portale direkt über die Fachverfahren der Zulassungsbehörden mit dem KBA kommunizieren.

5.2 Technische Architektur des i-Kfz-Systems

Auf Basis der in Kapitel 5.1 beschriebenen Kommunikationsarchitektur wurde folgende technische Architektur für das i-Kfz-System definiert (vergleiche Abbildung 3), an der sich die Anbieter dezentraler Portale bei der Umsetzung der dezentralen Portale halten müssen.

Abbildung 3: Technische Architektur des i-Kfz-Systems – das Gesamtbild

Im Folgenden werden die in der Architektur definierten Netzwerk-Bereiche und Komponenten sowie deren Schnittstellen beschrieben.

5.3 Netzwerkbereiche innerhalb des i-Kfz-Systems

Die im i-Kfz-System agierenden Kommunikationspartner sind unterschiedlichen Netzwerken (oder auch Netzwerksegmenten) zugeordnet. Eine Zuordnung der einzelnen Komponenten und Schnittstellen zu den Netzwerkbereichen ist der Abbildung 3 zu entnehmen.

In den folgenden Abschnitten werden die einzelnen Netzwerkbereiche, sowie deren Rolle im Gesamtverbund definiert. Die daraus abgeleiteten Sicherheitsanforderungen sind im Kapitel 7 beschrieben.

In der Abbildung 4 werden die identifizierten Netzwerkbereiche bzw. Netzwerke dargestellt und bezogen auf die untereinander auftretenden Kommunikationsflüsse in Relation gestellt.

Abbildung 4: Netzwerkbereiche der definierten Architektur innerhalb i-Kfz

Hinweis:

Gemäß [BSI-ISI-LANA] wird eine Demilitarisierte Zone (DMZ) wie folgt definiert:

„Eine DMZ ist ein Zwischennetz, das an Netzübergängen gebildet wird, aber weder zu dem einen, noch zu dem anderen Netz gehört. Sie stellt ein Netz dar, das weniger stark gesichert, aber vom äußeren Netz aus besser erreichbar ist als das eigentlich zu schützende interne Netz. Die DMZ dient der Schaffung eines zusätzlichen Sicherheitsbereichs für Dienste (z. B. E-Mail, Web) oder Proxys, die von externen Netzen aus nutzbar sein sollen, aber aus Sicherheitsgründen nicht im internen Netz platziert werden dürfen.“

Mindestanforderungen an eine DMZ mit normalem Schutzbedarf sind die Verwendung von einem Paketfilter, von einem Application-Level-Gateway und von einem weiteren Paketfilter (die PAP-Struktur) für den Aufbau eines sogenannten Sicherheits-Gateways (vergleiche [BSI-ISI-LANA] und [BSI-ISI-WEB-SVR]).

5.3.1 KBA-Internet-DMZ

Die „KBA-Internet-DMZ“ stellt ein separates Netzwerksegment innerhalb der KBA-Infrastruktur dar. Innerhalb dieses Netzwerksegmentes werden die Komponenten vom KBA zur Verfügung gestellt, die eine Abwicklung der i-Kfz-Szenarien über das Internet erlauben:

–

„KBA-Internet-Kom-Modul“ (vergleiche Kapitel 5.4.2),

–

Das „zentrale Portal“ (vergleiche Kapitel 5.4.1).

5.3.2 KBA-Kern-Netz

Die Kerndienste des KBA (hier KBA-Registerführung genannt, vergleiche Kapitel 5.4.3) werden innerhalb des Netzwerkbereiches „KBA-Kern-Netz“ angeboten. Es handelt sich hierbei insbesondere um das ZFZR. Das „KBA-Kern-Netz“ stellt einen geschützten Bereich dar, der von externen Netzwerken durch die Verwendung einer sogenannten DMZ separiert ist.

Es besteht keine Möglichkeit aus einer Internet-DMZ in das „KBA-Kern-Netz“ eine Verbindung aufzubauen.

Es besteht auch keine Möglichkeit aus dem „KBA-Kern-Netz“ eine Verbindung in ein externes Netzwerk (z. B. Internet oder auch DOI) zu eröffnen, ohne dass diese Verbindung über die korrespondierende DMZ (entsprechend „KBA-Internet-DMZ“ oder „KBA-DOI-DMZ“) verläuft.

Die innerhalb dieses Segmentes untergebrachten Dienste können mit Hilfe eines Puffer-Mechanismus (z. B. einer Nachrichtenschlange) mit den DMZ-Netzwerksegmenten kommunizieren.

5.3.3 KBA-DOI-DMZ

Die Zulassungsbehörden kommunizieren bereits heute aus der Komponente „Systeme der Fachverfahren“² heraus mit dem KBA über das Behördennetzwerk DOI. Diese Kommunikation ist entsprechend der Anforderungen des KBA formuliert innerhalb des Dokumentes „Information zur netztechnischen Anbindung an das Kraftfahrt-Bundesamt für Behörden“ abzusichern.

Die im Rahmen des i-Kfz-Projektes zusätzlich geplante Kommunikation zwischen KBA und Zulassungsbehörden unter Verwendung eines Postfachs wird auf die bereits implementierten Transport-Mechanismen zurückgreifen.

5.3.4 Dezentrales-Portal-DMZ

Der Bereich „Dezentrales-Portal-DMZ“ beinhaltet die über das unsichere Medium Internet zugängliche Komponente „dezentrales Portal“ (vergleiche Kapitel 5.4.7) und die für die Kommunikation des dezentralen Portals mit dem KBA benutzte Komponente „KBA-Cnn“ (vergleiche Kapitel 5.4.8).

Es sind eingehende Kommunikationsverbindungen der Antragsteller (Großkunde und Bürger) erlaubt. Eine ausgehende Kommunikation ist nur in den Bereich „KBA-Internet-DMZ“ zulässig.

5.3.5 Zulassungsbehörde-Kern-Netz

Dieser Bereich beinhaltet die Komponente „Systeme der Fachverfahren“ der Zulassungsbehörde. Es ist keine direkt eingehende Kommunikation in diesen Bereich hinein zulässig. Es dürfen aus diesem Bereich ausgehende Verbindungen in den Bereich „Zulassungsbehörde-DOI-Netz“ hergestellt werden.

5.3.6 Zulassungsbehörde-DOI-DMZ

Die Komponenten, die die Kommunikation der Zulassungsbehörde mit dem KBA realisieren, werden im Bereich „Zulassungsbehörde-DOI-DMZ“ untergebracht. In diesem Bereich ist die eingehende Kommunikation aus dem Bereich „Zulassungsbehörde-Kern-Netz“ erlaubt. Weiterhin darf der Bereich ausgehend mit dem Bereich „KBA-DOI-DMZ“ über das DOI-Netz kommunizieren.

5.3.7 Internet

Dieser Bereich umfasst die Komponenten der Antragsteller:

–

Bürger (vergleiche Kapitel 5.4.10)

–

Großkunden (vergleiche Kapitel 5.4.9)

Außer der Abwicklung von Einzelanträgen über das zentrale bzw. über die dezentralen Portale kann es eine Möglichkeit für die sogenannten Großkunden (hier z. B. große Autohäuser, Flottenbetreiber oder Autovermietungsfirmen etc.) geben, über dezentrale Portale die Anträge nicht direkt über die graphische Benutzerschnittstelle des Portals einzugeben, sondern über eine maschinenlesbare Schnittstelle (vergleiche Kapitel 5.5.7) zu übermitteln.

5.4 Komponenten der Architektur innerhalb des i-Kfz-Systems

Die vorgestellten Netzwerkbereiche beinhalten System-Komponenten, die über definierte Schnittstellen miteinander kommunizieren.

5.4.1 Zentrales Portal

Das zentrale Portal wird durch das KBA bereitgestellt und ermöglicht die internetbasierte Antragstellung für die Außerbetriebsetzung eines Fahrzeugs (Stufe 1 i-Kfz). Das Portal ist dem Netzwerkbereich „KBA-Internet-DMZ“ zugeordnet. Die Kommunikation mit der übrigen KBA-Infrastruktur wird analog zu den dezentralen Portalen über das „KBA-Internet-Kom-Modul“ abgewickelt (vergleiche Kapitel 5.4.2).

5.4.2 KBA-Internet-Kom-Modul

Eine zentrale Rolle bei der Kommunikation aus dem Internet in das KBA-Netz übernimmt die Komponente „KBA-Internet-Kom-Modul“. Dieses Modul bietet zwei Schnittstellen an:

–

Schnittstelle A – erreichbar aus dem Internet durch die dezentralen Portale, sowie aus dem der KBA-Internet-DMZ durch das zentrale Portal (vergleiche Kapitel 5.5.1),

–

Schnittstelle B – erreichbar nur aus dem Intranet des KBA („KBA-Kern-Netz“), (vergleiche Kapitel 5.5.2).

Der interne Aufbau der Komponente „KBA-Internet-Kom-Modul“ ist der Abbildung 5 zu entnehmen. Das Modul nimmt die über die Schnittstelle A eingehenden Nachrichten entgegen und speichert diese über eine interne Schnittstelle k in einer Nachrichtenschlange, bis die Nachrichten über die Schnittstelle B abgeholt werden.

Die über die Schnittstelle B zurückgeschriebenen Antworten werden über die interne Schnittstelle k abgeholt und dann über die Schnittstelle A an die aufrufende Instanz als Antwort auf die Anfrage zurückgeschickt.

Eine logische synchrone Kommunikation über die Kommunikationsverbindung „dezentrales/zentrales Portal“ → „KBA-Internet-Kom-Modul“ → „KBA-Registerführung“ wird physikalisch durch den asynchronen Ansatz (die Verwendung der Nachrichtenschlange) auf der Kommunikationsverbindung „KBA-Internet-Kom-Modul“ → „KBA-Registerführung“ transparent für die aufrufende Instanz umgesetzt.

Abbildung 5: interner Aufbau der Komponente „KBA-Internet-Kom-Modul“ (schematische Darstellung)

5.4.3 KBA-Registerführung

Unter der „KBA-Registerführung“ werden Software-Komponenten (z. B. Verarbeitungsmodule, Datenbanken, ZFZR etc.) zusammengefasst, die innerhalb des Netzwerkbereiches „KBA-Kern-Netz“ in einer abgesicherten Umgebung ablaufen.

5.4.4 KBA-DOI-Kom-Modul

Die bereits zur Verfügung stehende Kommunikationsmöglichkeit zwischen einer Zulassungsbehörde und dem KBA über sichere Netze der öffentlichen Verwaltung (insbesondere DOI) wird in der Architektur durch die Komponente „KBA-DOI-Kom-Modul“ dargestellt.

Die eingehende Kommunikation von den Zulassungsbehörden wird mit Hilfe der Schnittstelle D (vergleiche Kapitel 5.5.4) und von der KBA-Registerführung mit Hilfe der Schnittstelle E (vergleiche Kapitel 5.5.5) entgegengenommen.

Die Kommunikation vom KBA an die Zulassungsbehörden wird analog umgesetzt. Die an eine Zulassungsbehörde adressierten Nachrichten werden mithilfe der Schnittstelle E von der KBA-Registerführung abgelegt und über die Schnittstelle D den Zulassungsbehörden zur Verfügung gestellt.

Das „KBA-DOI-Kom-Modul“ wickelt die Kommunikation dabei für zwei Anwendungsfälle ab, die bereits heute technisch implementiert sind und außerhalb der Funktionalität des i-Kfz-Projektes genutzt werden (vergleiche Abbildung 6)³:

–

Die Zugriffe seitens der Zulassungsbehörde auf das Zentrale Fahrzeugregister (ZFZR-Webservice) – hier fragen die Behörden synchron einen Web-Service ab,

–

die Zugriffe der Zulassungsbehörden auf das für die Zulassungsbehörden seitens KBA zur Verfügung gestellte Postfach – in dem Falle werden die Nachrichten asynchron (durch die Zulassungsbehörden) abgeholt und die Antwortnachrichten abgelegt.

Abbildung 6: Interner Aufbau der Komponente „KBA-DOI-Kom-Modul“

5.4.5 KBA-DOI-Cnn

Dieses Modul stellt eine sichere Kommunikationsschnittstelle zwischen dem „Fachverfahren“ und dem „KBA-DOI-Kom-Modul“ über sichere Netze (insbesondere DOI) her. Die Komponente bietet die Aushandlung und Abwicklung einer abgesicherten Datenübertragung auf dem Transport-Level.

Das Modul bietet die Schnittstelle C (vergleiche Kapitel 5.5.3) an, die durch das Fachverfahren der Zulassungsbehörden bedient wird. Weiterhin spricht die Komponente die vom KBA betriebene Kommunikationsgegenstelle („KBA-DOI-Kom-Modul“) mit Hilfe der Schnittstelle D (vergleiche Kapitel 5.5.4) an.

Das Modul „KBA-DOI-Cnn“ bedient dabei zwei Anwendungsfälle:

–

Bereits heute implementierter Zugriff seitens der Zulassungsbehörden auf den ZFZR-Webservice,

–

der im Rahmen des i-Kfz-Projektes verwendete Zugriff auf das Postfach.

5.4.6 Systeme der Fachverfahren (Zulassungsbehörde)

Die Komponente „Systeme der Fachverfahren“⁴ in der Zulassungsbehörde wird in dem sicheren Bereich „Zulassungsbehörde-Kern-Netz“ betrieben. Die Komponente „Systeme der Fachverfahren“ bietet keine Schnittstellen an, sondern bedient die von der Komponente „KBA-DOI-Cnn“ angebotene Schnittstelle C (vergleiche Kapitel 5.5.3).

Die Komponente „Systeme der Fachverfahren“ ist immer eine Kommunikation initiierende Instanz und darf keine Kommunikationsanfragen entgegennehmen.

5.4.7 Dezentrales Portal

Die Komponente „dezentrales Portal“ bietet dem „Antragsteller Bürger“ die Schnittstelle H (vergleiche Kapitel 5.5.8) an und bedient die von der Komponente „KBA-Cnn“ (vergleiche Kapitel 5.4.8) angebotene Schnittstelle F (vergleiche Kapitel 5.5.6), über die die an das KBA adressierten Nachrichten weitergeleitet werden.

Eine Erweiterung gegenüber dem „zentralen Portal“ stellt die mit Hilfe der Schnittstelle G (vergleiche Kapitel 5.5.7) implementierte Möglichkeit der Abwicklung von Massenanfragen, die seitens sogenannter Großkunden abgesetzt ­werden können.

5.4.8 KBA-Cnn

Die Komponente „KBA-Cnn“ realisiert die Kommunikation zwischen einem „dezentralen Portal“ und dem KBA über die Komponente „KBA-Internet-Kom-Modul“ durch Aufbau einer gesicherten VPN-Verbindung. Der Informationsfluss verläuft stets vom „KBA-Cnn“ (Initiator) zum „KBA-Internet-Modul“ (Empfänger).

Der „KBA-Cnn“ bietet die Schnittstelle F (vergleiche Kapitel 5.5.6) gegenüber dem „dezentralen Portal“ an, welches die Nachrichten entgegennimmt. Die Nachrichten werden im nächsten Schritt an das „KBA-Internet-Kom-Modul“ über die Schnittstelle A (vergleiche Kapitel 5.5.1) weitergeleitet.

5.4.9 Antragsteller Großkunde

Eine Besonderheit des Systems stellen die sogenannten Großkunden dar, die beispielweise durch Autovermietungen, Flotten-Betreiber oder durch große Autohäuser vertreten sind. Die Fachverfahren der Großkunden kommunizieren über die Schnittstelle G (vergleiche Kapitel 5.5.7) mit einem dezentralen Portal.

Die Benutzung der Schnittstelle G ermöglicht eine performante Übertragung mehrerer Nachrichten (Massendaten). Eine Nutzung der graphischen Benutzerschnittstelle (GUI) des dezentralen Portals ist nicht notwendig.

5.4.10 Antragsteller Bürger

Die Antragstellergruppe „Bürger“ fasst die Bürgerinnen und Bürger zusammen, die mit Hilfe des zentralen Portals bzw. der dezentralen Portale eine Kfz-Angelegenheit abwickeln möchten. Es handelt sich hier um eine graphische Schnittstelle (GUI), die für Einzelangelegenheiten über einen Standardbrowser bedient werden kann. Die Kommunikation wird durch die Schnittstelle H (vergleiche Kapitel 5.5.8) charakterisiert.

5.5 Schnittstellen der Architektur innerhalb des i-Kfz-Systems

Die im Kapitel 5.4 vorgestellten Komponenten der Architektur werden über definierte Schnittstellen angesprochen. Es wurden insgesamt neun Schnittstellen definiert, die in den darauffolgenden Kapiteln detaillierter vorgestellt werden.

5.5.1 Schnittstelle A

Die Schnittstelle A wird vom „KBA-Internet-Kom-Modul“ angeboten und von den Komponenten „zentrales Portal“ (vergleiche Abbildung 7) und „dezentrales Portal“ (über das Modul „KBA-Cnn“, vergleiche Abbildung 8) genutzt.

Hinweis:

Die detaillierte technische Spezifikation der Schnittstelle ist in der seitens KBA zu Verfügung gestellten Information für Softwarehersteller und Verfahrensanbieter zu finden.

Abbildung 7: Verwendung der Schnittstelle A durch das zentrale Portal

Abbildung 8: Verwendung der Schnittstelle A durch ein dezentrales Portal

Die Schnittstelle nimmt die für die weitere Verarbeitung durch die „KBA-Registerführung“ gedachten Nachrichten entgegen und puffert diese (z. B. in einer Nachrichten-Schlange) für die Abholung seitens der „KBA-Registerführung“. Auf dem gleichen Weg werden die Antworten der KBA-Registerführung in einen Puffer geschrieben, im nächsten Schritt aus dem Puffer ausgelesen und entsprechend über die Schnittstelle A an die aufrufende Instanz zurückgeliefert.

Es darf über die Schnittstelle A nur die eingehende Kommunikation behandelt werden. Es darf keine ausgehende Kommunikation über die Schnittstelle A realisiert werden. Die Antwortnachrichten werden synchron als Rückgabewerte zurückgeschrieben.

Die Schnittstelle ist mit Hilfe der Webservice-Technologie (WS-Technologie) realisiert und bietet die im Rahmen des i-Kfz-Projektes entwickelten i-Kfz-Webservices an.

Die Schnittstelle realisiert eine synchrone Kommunikation, die intern asynchron abgewickelt wird.

Die Nachrichten werden in einem vom KBA definierten XML-Format realisiert. Entsprechende Schemadateien und WS-Beschreibungen sind im geschützten Bereich der KBA-Internetseite⁵ veröffentlicht.

5.5.2 Schnittstelle B

Bei der Schnittstelle B handelt es sich um eine weitere Schnittstelle, die vom „KBA-Internet-Modul“ angeboten wird. Es ist eine interne KBA-Schnittstelle, die von außerhalb des Bereichs „KBA-Internet-DMZ“ mit Ausnahme des „KBA-Kern-Netz“ nicht sichtbar ist. Die „KBA-Registerführung“ aus dem „KBA-Kern-Netz“ greift auf diese Schnittstelle zu, um die für diese Komponenten bestimmten Nachrichten abzuholen.

Abbildung 9: Verwendung der Schnittstelle B

Die Schnittstelle an sich wird im synchronen Modus betrieben, realisiert aber einen asynchronen Zugriff zwischen den Komponenten „KBA-Internet-Modul“ und „KBA-Registerführung“.

Die Nachrichten werden in einem vom KBA definierten XML-Format implementiert.

5.5.3 Schnittstelle C

Schnittstelle C definiert den Informationsfluss zwischen den Komponenten „Systeme der Fachverfahren“ und „KBA-DOI-Cnn“ und wird von der Komponente „KBA-DOI-Cnn“ angeboten. Die aus der Komponente „Systeme der Fachverfahren“ herausgehenden Nachrichten an die KBA-Infrastruktur, sowie das Abholen von aus der KBA-Infrastruktur herausgehenden Nachrichten an die Zulassungsbehörde (Postfach) werden über diese Schnittstelle realisiert.

Es werden zwei unterschiedliche Kommunikationsmodi unterschieden, die sich auf dem logischen Level unterscheiden, auf dem physikalischen Level jedoch gleich behandelt werden:

–

Abschicken einer Nachricht aus der Komponente „Systeme der Fachverfahren“ an das KBA und Empfang einer Antwort – die Nachricht ist innerhalb der Komponente „Systeme der Fachverfahren“ erstellt worden und wird dann synchron an das KBA verschickt; die zeitnah generierte Antwort seitens KBA wird an die Komponente „Systeme der Fachverfahren“ als Rückgabewert zurückgeliefert (vergleiche Abbildung 10 – Variante 1),

–

Abholen einer Nachricht des KBA an die Zulassungsbehörde und Ablegen einer Antwort durch die Zulassungsbehörde – in diesem Fall wird die Kommunikation seitens der Komponente „Systeme der Fachverfahren“ initiiert. Die Komponente „Systeme der Fachverfahren“ holt im ersten Schritt (erster Aufruf, vergleiche Abbildung 10 – Variante 2) die für sie bestimmte Nachricht ab, verarbeitet diese und legt ggf. die erzeugte Antwort an das KBA (zweiter Aufruf, vergleiche Abbildung 10 – Variante 3) ab.

Abbildung 10: Verwendung der Schnittstelle C

Die Schnittstelle C leitet die Kommunikation transparent in den Bereich „KBA-DOI-DMZ“ weiter. Die Realisierung des zweiten Kommunikationsmodus (Zwischenspeicherung der Nachrichten) erfolgt im Bereich „KBA-DOI-DMZ“.

Hinweis:

Im Dokument „Informationen zur netztechnischen Anbindung an das Kraftfahrt-Bundesamt für Behörden“ (Kapitel 3) wird der Betrieb einer Kopfstelle innerhalb der Zulassungsbehörden beschrieben. Diese Kopfstelle bietet gegenüber der Komponente „Systeme der Fachverfahren“ die Schnittstelle C technisch an.

Die im Rahmen des i-Kfz-Projektes ausgetauschten Nachrichten sind in einem vom KBA festgelegten XML-Format implementiert.

5.5.4 Schnittstelle D

Die Kommunikation zwischen den Komponenten „KBA-DOI-Cnn“ und „KBA-DOI-Kom-Modul“ wird mit Hilfe der Schnittstelle D realisiert. Das funktionale Verhalten der Schnittstelle D entspricht dem Verhalten an der Schnittstelle C (vergleiche Kapitel 5.5.3). Die möglichen Nachrichten der Schnittstelle C sind genauso an der Schnittstelle D zu finden.

Es werden beide zur Schnittstelle C beschrieben Kommunikationsmodi unterstützt.

5.5.5 Schnittstelle E

Der Kommunikationsfluss zwischen den Modulen „KBA-Registerführung“ und „KBA-DOI-Kom-Modul“ wird durch die Schnittstelle E beschrieben. Die Komponente „KBA-Registerführung“ stellt dabei die aktive Instanz der Kommunikation dar und holt die eingehenden Nachrichten ab, bzw. legt die ausgehenden Nachrichten für die Weiterleitung an die Zulassungsbehörde ab.

Analog der Schnittstelle B ist diese Schnittstelle synchron implementiert, realisiert aber eine asynchrone Kommunikation zwischen den Komponenten „KBA-Registerführung“ und „KBA-DOI-Kom-Modul“.

5.5.6 Schnittstelle F

Die Schnittstelle F definiert die Gegebenheiten der Kommunikation zwischen einem „dezentralen Portal“ und dem „KBA-Cnn“. Der „KBA-Cnn“ nimmt die ausgehenden Nachrichten vom „dezentralen Portal“ entgegen und leitet diese an die KBA-Infrastruktur weiter, empfängt die eingehende Antwort und liefert diese an die aufrufende Instanz zurück.

Es ist eine synchrone Schnittstelle, die Nachrichten in einem vom KBA definierten XML-Format unterstützt.

Hinweis:

Es ist auch zulässig, dass die Schnittstelle F eine interne Schnittstelle innerhalb der Komponente „dezentrales Portal“ darstellt. In dem Fall ist die Komponente „KBA-Cnn“ in die Komponente „dezentrales Portal“ integriert.

5.5.7 Schnittstelle G

Mit Hilfe der Schnittstelle G wird die Kommunikation zwischen der Komponente „Antragsteller Großkunde“ und der Komponente „dezentrales Portal“ beschrieben. Es handelt sich um eine vollständig automatisierte Maschine-zu-Maschine-Schnittstelle (API), die ohne Mitwirkung von Menschen betrieben wird.

Die Komponente „Antragsteller Großkunde“ nimmt stets die Rolle des Initiators der Kommunikation an.

Im Rahmen des i-Kfz-Projektes findet keine Standardisierung der Schnittstelle G statt. Dieses Dokument legt allerdings allgemeine Sicherheitsmindestanforderungen fest (vergleiche Kapitel 7.2.7), die bei der Realisierung der Schnittstelle G beachtet werden müssen.

5.5.8 Schnittstelle H

Der Zugriff durch die antragstellende Person auf die dezentralen Portale und/oder auf das zentrale Portal wird durch die Schnittstelle H beschrieben. Die Schnittstelle H ist mit Hilfe der Web-Technologie realisiert und wird über einen Standardbrowser durch die Bürger bedient.

Form und Inhalt der auszutauschenden Informationen, sowie der Ablauf der einzelnen Schritte an der Schnittstelle sind im Rahmen des i-Kfz-Projektes spezifiziert worden. Eine genaue technologische Umsetzung ist nicht vorgeschrieben.

Zusätzlich zu der im Kapitel 4 beschriebenen Architektur des i-Kfz-Systems können unterschiedliche außerhalb des i-Kfz-Projektes liegende Aspekte weitere Sicherheitsanforderungen notwendig machen. In diesem Kapitel werden zusätzliche Kommunikationsflüsse sowie deren Einfluss auf die Architektur dargestellt. Die identifizierten Sicherheitsanforderungen werden im Kapitel 7 beschrieben.

6.1 Zusätzliche Kommunikationsflüsse

Im Zuge der in den letzten Jahren innerhalb der Zulassungsfachverfahren durchgeführten Implementierungen sind insbesondere web-basierte Erweiterungen (z. B. Terminvereinbarung oder Reservierung eines Wunschkennzeichens, Vorerfassung von Zulassungsdaten) umgesetzt worden. Es ist daher davon auszugehen, dass die Zulassungsfachverfahren bereits einen direkten Zugang aus einem unsicheren Netzwerk in die lokalen Systeme der Zulassungsbehörden umgesetzt haben.

In Abbildung 11 ist dieser zusätzlich zu betrachtende Kommunikationsfluss zwischen einem dezentralen Portal und dem Fachverfahren in der Zulassungsbehörde mit einem rot gekennzeichneten Pfeil dargestellt.

Abbildung 11: Zusätzliche Kommunikationsflüsse

6.2 Einfluss auf die technische Architektur des i-Kfz-Systems

Die im Kapitel 6.1 beschriebene zusätzliche Kommunikationsbeziehung zwischen den dezentralen Portalen und den Zulassungsbehörden bedingen eine Erweiterung der im Kapitel 5.2 definierten technischen Architektur. Insbesondere kommen folgende Elemente hinzu:

–

zusätzlicher Netzwerkbereich – „Zulassungsbehörde-Internet-DMZ“

–

zusätzliche Komponente – „Internet-Cnn“, die für die Abwicklung der aus dem Internet kommenden Kommunikation verantwortlich ist und

–

zwei zusätzliche Schnittstellen – Schnittstelle X (zwischen Internet und dem Bereich „Zulassungsbehörde-Internet-DMZ“) und Schnittstelle Y (zwischen den Bereichen „Zulassungsbehörde-Internet-DMZ“ und „Zulassungsbehörde-Kern-Netz“).

Die zusätzlichen Elemente wurden in der Abbildung 12 rot umrahmt dargestellt und werden im weiteren Verlauf dieses Kapitels beschrieben.

Abbildung 12: Erweiterte technische Architektur des i-Kfz-Systems

6.3 Zusätzliche Netzwerkbereiche

Mit der Öffnung des Zulassungsverfahrens für die Zugriffe aus einem unsicheren Netzwerkbereich (z. B. Internet) steigt die Gefahr des Kompromittierens eines Fachverfahrens. Da die Zulassungssoftware (die Komponente „Systeme der Fachverfahren“) über einen (insbesondere auch schreibenden) Zugriff auf das KBA-Register verfügt (Kommunikationsverbindung Systeme der Fachverfahren→KBA-DOI-Cnn→KBA-DOI-Kom-Modul→KBA-Registerführung), steigt somit auch die Gefahr eines unzulässigen Zugriffs auf die Kommunikationsverbindung Zulassungsbehörde-KBA (vergleiche Schnittstelle C, Kapitel 5.5.4).

Um dieser Gefahr entgegenzuwirken, wurde ein zusätzlicher Netzwerkbereich zwischen den unsicheren Netzen und dem abzusichernden Netzwerkbereich der Zulassungsbehörde geschaffen – „Zulassungsbehörde-Internet-DMZ“ (vergleiche dazu Kapitel 6.3.1).

In der Abbildung 13 wurde der zusätzliche Bereich rot umrahmt markiert.

Abbildung 13: Erweiterte Zusammenstellung der Netzwerkbereiche

6.3.1 Zulassungsbehörde-Internet-DMZ

Die aus dem unsicheren Netzwerk (Internet) in den Bereich der Zulassungsbehörde eingehende Kommunikation wird in dem ersten Schritt im Netzwerkbereich „Zulassungsbehörde-Internet-DMZ“ empfangen.

Es handelt sich hier um die von den dezentralen Portalen ausgehende Kommunikation zur Zulassungsbehörde, die für die i-Kfz-Abwicklung benötigt wird (dezentrale i-Kfz-Funktionalität wie z. B. Gebührenrückstandsprüfung) oder um weitere Funktionen/Verfahren, die nicht innerhalb des i-Kfz-Verfahrens benötigt werden.

Eine weitere Kommunikationsmöglichkeit in dem Netzwerksegment „Zulassungsbehörde-Internet-DMZ“ besteht aus dem abgesicherten Netzwerkbereich der Zulassungsbehörde „Zulassungsbehörde-Kern-Netz“.

Hinweis:

Es ist zulässig, dass die beiden Bereiche „Dezentrales-Portal-DMZ“ (vergleiche dazu Kapitel 5.3.4) und „Zulassungsbehörde-Internet-DMZ“ zusammengelegt werden, wenn dies organisatorisch möglich ist (z. B. bei gleichem Betreiber). In einem solchen Fall wird die Komponente „dezentrales Portal“ innerhalb des Netzwerkbereiches „Zulassungsbehörde-Internet-DMZ“ betrieben.

Hinweis:

Es darf keine direkte, sowohl physikalische als auch logische, Verbindung zwischen den Komponenten aus dem Netzwerkbereich „Zulassungsbehörde-Internet-DMZ“ und den Komponenten aus dem Netzwerksegment „Zulassungsbehörde-DOI-DMZ“ existieren.

6.4 Zusätzliche Komponenten

Die beiden Kommunikationsflüsse im Netzwerkbereich „Zulassungsbehörde-Internet-DMZ“ werden durch die Komponente „Internet-Cnn“ abgewickelt (vergleiche Kapitel 6.4.1).

6.4.1 Internet-Cnn

Die Komponente „Internet-Cnn“ ist für den Empfang der aus dem Internet kommenden und an die Zulassungsbehörde adressierten Nachrichten sowie deren Angebot für die weitergehende Bearbeitung zuständig. Die Komponente bietet zwei Schnittstellen an:

–

Schnittstelle X – über diese Schnittstelle wird die aus dem Internet kommende Kommunikation entgegengenommen (vergleiche Kapitel 6.5.1),

–

Schnittstelle Y – mit Hilfe dieser Schnittstelle können die Komponenten aus dem Bereich „Zulassungsbehörde-Kern-Netz“ die an sie adressierten Nachrichten abholen und die generierten Antworten zur Verfügung stellen (vergleiche Kapitel 6.5.2).

Die beispielhafte schematische Darstellung der Komponente „Internet-Cnn“ ist in der Abbildung 14 dargestellt. Die logische synchrone Kommunikation zwischen den Komponenten „dezentrales Portal“ und „Systeme der Fachverfahren“ wird über folgende asynchrone Teilschritte abgebildet:

–

Die interne Komponente „Internet-Server“ nimmt die Nachrichten (Anfragen) über die äußere Schnittstelle X entgegen (z. B. von der Komponente „dezentrales Portal“) und speichert diese über die interne Schnittstelle j in einem Nachrichtenpuffer (z. B. einer Nachrichtenschlange [Queue]).

–

Die Komponente „Systeme der Fachverfahren“ greift über die Schnittstelle Y auf den Nachrichtenpuffer zu, liest die strukturierten Inhalte aus und prüft ihre Semantik. Anschließend holt sie die wartenden Nachrichten ab.

–

Die abgeholten Nachrichten werden durch die Komponente „Systeme der Fachverfahren“ verarbeitet und die generierten Antwortnachrichten werden über die Schnittstelle Y in den Nachrichtenpuffer geschrieben.

–

Die Komponente „Internet-Server“ holt die wartenden Antwortnachrichten über die interne Schnittstelle j ab und liefert diese als Antwort auf die korrespondierenden Anfragen, die zuvor über die Schnittstelle Y ankamen.

Abbildung 14: Schematische Darstellung des internen Aufbaus der Komponente „Internet-Cnn“

6.5 Zusätzliche Schnittstellen

6.5.1 Schnittstelle X

Die Kommunikation zwischen den Komponenten „dezentrales Portal“ und „Internet-Cnn“ (innerhalb der Zulassungsbehörde) wird über die Schnittstelle X realisiert. Der Initiator der Kommunikation ist dabei stets die Komponente „dezentrales Portal“. Die eingehenden Nachrichten werden von der Komponente „Internet-Cnn“ entgegengenommen und die Antworten an die aufrufende Instanz in einem synchronen Modus zurückgeliefert.

6.5.2 Schnittstelle Y

Die über das unsichere Netz (Internet) an die Zulassungsbehörden herangetragenen Nachrichten müssen in einem ersten Schritt von einem direkten Durchgriff auf das geschützte Kern-Netzwerk der Zulassungsbehörde separiert werden. Für diesen Zweck wurde der Netzwerk-Bereich „Zulassungsbehörde-Internet-DMZ“ geschaffen.

Die Komponente, die die eingehenden Nachrichten zwischenspeichert und die Schnittstelle Y anbietet, heißt „Internet-Cnn“. Die Schnittstelle wird von der Komponente „Systeme der Fachverfahren“ benutzt.

Die Kommunikation muss dabei stets von einer Komponente aus dem Bereich „Zulassungsbehörde-Kern-Netz“ initiiert werden.

Es darf keine Möglichkeit geben, dass die Kommunikation aus dem Bereich „Zulassungsbehörde-Internet-DMZ“ über die Schnittstelle Y im Bereich „Zulassungsbehörde-Kern-Netz“ initiiert werden kann.

In diesem Kapitel werden die allgemeinen und speziellen Sicherheitsanforderungen an die beschriebenen Schnittstellen der Architektur dargestellt.

Jede Anforderung besteht aus vier Teilen, die in Form einer Tabelle zusammengestellt sind (vergleiche Tabelle 3):

–

ID – die im Rahmen dieses Dokumentes eindeutige Kennung der Anforderung: Die ID beginnt immer mit dem Großbuchstaben A, gefolgt von der Nummer des Kapitels, in dem die Anforderung beschrieben ist, gefolgt von der Nummer der Anforderung bezogen auf das jeweilige Kapitel (z. B. erhält die zweite Anforderung, die im Kapitel 6.2.6 beschrieben ist, die folgende ID: A-6.2.6-2),

–

Anforderungstitel,

–

Verpflichtungsgrad (VG),

–

Anforderungsbeschreibung.

Tabelle 3: Aufbau einer Sicherheitsanforderung

Der Verpflichtungsgrad einer Anforderung kann einen der folgenden Werte annehmen:

–

„muss“ – eine „muss“-Anforderung ist unbedingt zu erfüllen,

–

„soll“ – eine „soll“-Anforderung muss nicht unbedingt erfüllt werden, jedoch sind die Gründe im Falle einer Nichterfüllung zu dokumentierten,

–

„kann“ – ist eine optionale Anforderung.

Hinweis:

Die Gruppe der „muss“-Anforderungen bildet die Mindestanforderungen, die erfüllt werden müssen.

7.1 Allgemeine Sicherheitsanforderungen

Hinweis:

Im Rahmen dieses Dokumentes gilt folgende Definition des Begriffes „Sicherheitsvorfall“.

Als Sicherheitsvorfall wird im Rahmen dieses Dokumentes ein Ereignis verstanden, das die Vertraulichkeit, Verfügbarkeit und Integrität der Informationen, Geschäftsprozesse, IT-Dienste, IT-Systeme bzw. IT-Anwendungen, die innerhalb des i-Kfz-Projektes zum Einsatz kommen, derart beeinträchtigt, dass ein großer Schaden für die beteiligten Akteure entstehen kann.

7.2 Sicherheitsanforderungen an die Schnittstellen der Architektur

Basierend auf der Beschreibung des Verhaltens an den Schnittstellen werden in diesem Kapitel Sicherheitsanforderungen an die einzelnen Schnittstellen der Architektur definiert.

Die Anforderungen werden sowohl an die im Kapitel 4 aufgeführten Schnittstellen der Architektur des i-Kfz-Systems als auch an die im Kapitel 6 dargestellten Schnittstellen der erweiterten Architektur gerichtet.

7.2.1 Anforderungen an die Schnittstelle A

Das Verhalten der Schnittstelle A wurde im Kapitel 5.5.1 erläutert.

Es wurden folgende Anforderungen an die Schnittstelle A abgeleitet.

7.2.2 Anforderungen an die Schnittstelle B

Interne Schnittstelle des KBA.

7.2.3 Anforderungen an die Schnittstelle C

Die Schnittstelle C ist im Kapitel 5.5.3 vorgestellt worden. Es wurden folgende Anforderungen an die Schnittstelle C abgeleitet.

7.2.4 Anforderungen an die Schnittstelle D

Die Anforderungen an die Schnittstelle D sind in [IznAaKBAfB] beschrieben. Die Eigenschaften der Schnittstelle D sind im Kapitel 5.5.4 zu finden.

Bezogen auf die im Rahmen von i-Kfz definierte zusätzliche Kommunikation über das Postfach ergeben sich weitere Anforderungen an die Schnittstelle D.

7.2.5 Anforderungen an die Schnittstelle E

Interne Schnittstelle des KBA.

7.2.6 Anforderungen an die Schnittstelle F

Die Schnittstelle F wurde im Kapitel 5.5.6 beschrieben.

7.2.7 Anforderungen an die Schnittstelle G

Die Schnittstelle G ist im Kapitel 5.5.7 vorgestellt.

7.2.8 Anforderungen an die Schnittstelle H

Die Ausgestaltung der Schnittstelle H ist dem Kapitel 5.5.8 zu entnehmen.

7.2.9 Anforderungen an die Schnittstelle X

Die Ausgestaltung der Schnittstelle X ist nicht im Fokus dieses Dokumentes, da diese Schnittstelle im Rahmen des i-Kfz-Projektes nicht direkt benutzt wird (vergleiche Grobkonzept2).

Hinweis:

Es wird empfohlen die Schnittstelle gemäß den geltenden Sicherheitsanforderungen für einen Zugriff aus dem Internet abzusichern (vergleiche [BSI-ISI]).

7.2.10 Anforderungen an die Schnittstelle Y

Im Zuge der Umsetzung der ersten Stufe des i-Kfz-Projektes ist keine Kommunikation an der Schnittstelle Y vorgesehen. Aus diesem Grund ergibt sich keine Notwendigkeit den Schutzbedarf der Schnittstelle zu ermitteln. Basierend auf der Gesamtarchitektur des Systems ergeben sich aber weitere Anforderungen, die im Folgenden beschrieben werden.

Die Kommunikation mit der KBA-Infrastruktur ist nur den zugelassenen Kommunikationspartnern gestattet. Über die Zulassung eines Kommunikationspartners entscheidet ausschließlich das KBA, die entsprechenden Zulassungsformalitäten als Kommunikationspartner werden in diesem Kapitel beschrieben. Die Prüfung einer Zulassung muss stets von einem Kommunikationspartner (hier die Zulassungsbehörde) beantragt werden. Bereits erteilte Kommunikationszulassungen sind in regelmäßigen Abständen zu erneuern.

Im Folgenden wird zunächst ein Überblick über den Lebenszyklus einer Zulassung gegeben, gefolgt von der Beschreibung der einzelnen Zustände und der möglichen Übergänge zwischen den Zuständen. Nachfolgend werden die Eigenschaften der durchzuführenden Audits und Penetrationstests, die Besonderheiten der Beantragung/Kündigung einer Zulassung sowie des angewandten Mahnverfahrens skizziert.

8.1 Lebenszyklus einer Zulassung

Ein Lebenszyklus einer Zulassung zur Kommunikation mit der KBA-Infrastruktur im Rahmen des i-Kfz-Projektes (im weiteren Verlauf auch nur Zulassung genannt) wird in der Abbildung 15 dargestellt.

Abbildung 15: Der Lebenszyklus einer Zulassung

Außer den Pseudozuständen „START“ und „ENDE“ sind fünf weitere Zustände einer Zulassung möglich:

–

„initial beantragt“ – die Zulassung wurde beantragt, befindet sich in der Prüfung, ist noch nicht gültig,

–

„gültig“ – die Zulassung ist gültig, die Kommunikation mit der KBA-Infrastruktur kann erfolgen,

–

„eingeschränkt gültig“ – die Zulassung wurde mit Auflagen versehen, die fristgerecht erfüllt werden müssen, die Kommunikation mit der KBA-Infrastruktur kann (befristet) erfolgen,

–

„suspendiert“ – die Zulassung ist suspendiert worden, die Auflagen müssen fristgerecht erfüllt werden, die Kommunikation mit der KBA-Infrastruktur wurde unterbrochen,

–

„ungültig“ – die Zulassung wurde terminiert, die Kommunikation mit der KBA-Infrastruktur findet nicht statt, die Zugangsdaten der Behörde wurden endgültig gesperrt, um die Kommunikation wiederaufnehmen zu können muss erneut eine Zulassung beantragt werden.

Nachstehend werden die einzelnen Zustände einer Zulassung mit den dazugehörigen Übergängen beschrieben. Jeder Übergang ist durch folgenden fünf Attribute charakterisiert:

–

„Art“ – es werden drei unterschiedliche Arten der Zustandsübergänge (Aktivitäten) definiert. Ein Übergang bezieht sich stets auf einen Zustand und kann gegenüber diesem Zustand eine der genannten Arten zugewiesen bekommen:

–

„in“ – ein eingehender Übergang, bedeutet mit Hilfe von diesem Übergang wird der betrachtende Zustand erreicht (z. B. „gültig“ – [kleine Mängel] → „gültig“),

–

„out“ – ein ausgehender Übergang, bedeutet mit Hilfe von diesem Übergang kann der betrachtende Zustand verlassen werden (z. B. „eingeschränkt gültig“ – [vollständig positiv geprüft] → „gültig“),

–

„in/out“ – ein ein- und ausgehender Übergang, bedeutet mit Hilfe von diesem Übergang kann der betrachtende Zustand verlassen aber gleichzeitig auch wieder betreten werden (z. B. „eingeschränkt gültig“ – [1. Ermahnung] → „eingeschränkt gültig“).

–

„Name“ – der Name eines Übergangs (z. B. „1. Ermahnung“),

–

„Start“ – Anfangszustand einer Übergangs,

–

„Ziel“ – Zielzustand eines Übergangs,

–

„Beschreibung“ – eine textuelle Beschreibung des Übergangs.

8.1.1 Eine „initial beantragte“ Zulassung

In dem Zustand „initial beantragt“ befindet sich eine Zulassung wenn sie neu beantragt wurde. Dieses trifft auf folgende Fälle zu:

–

Die Zulassung wird erstmalig beantragt,

–

oder die Zulassung wurde bereits beantragt und erteilt, hat aber ihre Gültigkeit im Rahmen des Zulassungsprozesses verloren und muss daher erneut beantragt werden.

Um eine Zulassung zu beantragen müssen generell die Bedingungen einer „gültigen“ Zulassung erfüllt werden (vergleiche Kapitel 8.1.2).

Eine Zulassung befindet sich in dem Zustand „initial beantragt“, wenn der Beantragungsprozess erfolgreich abgeschlossen wurde (vergleiche Kapitel 8.5).

Eine „initial beantragte“ Zulassung ermächtigt noch nicht zur Kommunikation mit der KBA-Infrastruktur.

Die Aktivitäten (Übergänge) die eine Zulassung in den Zustand „initial beantragt“ überführen, oder auf eine Zulassung im Zustand „initial beantragt“ anwendbar sind, werden in der Tabelle 4 aufgelistet:

Tabelle 4: Zulassungsverfahren – Übergänge des Zustands „initial beantragt“

8.1.2 Eine „gültige“ Zulassung

Eine Zulassung ist uneingeschränkt „gültig“ (auch nur „gültig“ genannt), wenn folgende Eigenschaften gelten:

1.

Der Beantragungsprozess wurde erfolgreich abgeschlossen (vergleiche Kapitel 8.5).

2.

Die in diesem Dokument definierten Mindestanforderungen (vergleiche Kapitel 7) sind vollständig erfüllt (die Einhaltung/Erfüllung konnte vollständig positiv geprüft werden).

3.

Die Erfüllung der Mindestanforderungen wurde im Rahmen eines Audits (vergleiche Kapitel 8.2) durch einen unabhängigen Dritten (im weiteren Verlauf Auditor genannt) überprüft und bestätigt.

4.

Es sind mehr als zwei Monate bis zur Fälligkeit eines Re-Audits (Hinweis: Sobald es weniger als zwei Monate bis zur Vorlage der Ergebnisse des Re-Audits sind, ist die Zulassung automatisch „eingeschränkt gültig“).

Eine gültige Zulassung ermächtigt zur Kommunikation mit der KBA-Infrastruktur.

In der Tabelle 5 werden die möglichen Aktivitäten (Übergänge) und der damit verbundenen Änderungen des Status einer Zulassung, bezogen auf eine „gültige“ Zulassung, dargestellt:

Tabelle 5: Zulassungsverfahren – Übergänge des Zustands „gültig“

8.1.3 Eine „eingeschränkt gültige“ Zulassung

Eine „gültige“ Zulassung, die kleine Mängel aufweist gilt als „eingeschränkt gültig“.

Folgende Eigenschaften definieren einen kleinen Mangel:

–

Ein Nachweis der Wiederholung der Penetrationstests steht aus (überfällig),

–

Ein Nachweis der Wiederholung des Audits steht aus (überfällig),

–

Ein Nachweis der Wiederholung des Audits muss spätestens in zwei Monaten vorgelegt werden (die Zulassung steht kurz vor dem Ablauf).

Eine eingeschränkte Zulassung wird normalerweise durch eine oder mehrere Auflagen begleitet, die innerhalb einer vorgegebenen Frist erfüllt werden müssen und deren Erfüllung nachgewiesen werden muss.

Ein wiederholtes Nichtbeachten der angesetzten Erfüllungs- und Nachweisfristen kann zur Ungültigkeit der Zulassung führen (vergleiche Kapitel 8.7).

Eine eingeschränkte Zulassung ermächtigt zur Kommunikation mit der KBA-Infrastruktur.

In der Tabelle 6 werden, bezogen auf eine „eingeschränkt gültige“ Zulassung, die Aktivitäten (Übergänge) und der damit verbundenen Änderungen des Status einer Zulassung gezeigt:

Tabelle 6: Zulassungsverfahren – Übergänge des Zustands „eingeschränkt gültig“

8.1.4 Eine „suspendierte“ Zulassung

Eine Zulassung kann aufgrund der festgestellten großen Mängel suspendiert werden. Zu der Gruppe der großen Mängel gehören u. a.:

–

Ein schwerwiegender Informationssicherheitsvorfall wurde beim Kommunikationspartner festgestellt (z. B. Teile des Portals wurden kompromittiert).

–

Festgestellter Verstoß gegen die in diesem Dokument definierten Mindestsicherheitsanforderungen.

Eine suspendierte Zulassung wird normallerweise von zeitlich befristeten Auflagen begleitet, die vom Kommunikationspartner erfüllt werden müssen und deren Erfüllung dem KBA rechtzeitig (vor dem Ablauf der Auflagefrist) angezeigt werden müssen.

Eine wiederholte Nichtbeachtung der angesetzten Erfüllung- und Nachweisfristen kann zur Ungültigkeit der Zulassung führen (vergleiche Kapitel 8.7).

Eine suspendierte Zulassung ermächtigt nicht zur Kommunikation mit der KBA-Infrastruktur (die Zugangsdaten werden seitens KBA gesperrt).

In der Tabelle 7 werden die Aktivitäten (Übergänge) und daraus resultierende neue Zustände der Zulassung, bezogen auf eine „suspendierte“ Zulassung, dargestellt:

Tabelle 7: Zulassungsverfahren – Übergänge des Zustands „suspendiert“

8.1.5 Eine „ungültige“ Zulassung

Eine ungültige Zulassung kann nicht in einen anderen Statuswert geändert werden. Um zur Kommunikation mit der KBA-Infrastruktur erneut zugelassen zu werden, muss der Kommunikationspartner die entsprechende Zulassung erneut beantragen.

Eine ungültige Zulassung ermächtigt nicht zur Kommunikation mit der KBA-Infrastruktur.

Tabelle 8: Zulassungsverfahren – Übergänge des Zustands „ungültig“

8.2 Audit

Die Erfüllung der in diesem Dokument definierten Mindestsicherheitsanforderungen muss im Rahmen eines Audits durch einen unabhängigen Dritten überprüft und bestätigt werden (vergleiche hierzu [BSI-ITG-ZERT]).

Die Überprüfung (Audit) ist alle drei Jahre zu wiederholen. Die Ergebnisse sind dem KBA vorzulegen.

Der Umfang des durchzuführenden Audits besteht aus einer Überprüfung der Anforderungen, die im Kapitel 7 definiert sind.

Im Falle einer bestehenden IT-Grundschutz-Zertifizierung sind im Audit nur die i-Kfz-spezifischen Anforderungen zu prüfen, welche über die IT-Grundschutzprüfung hinausgehen.

8.3 Prüfung der zusätzlichen Anforderungen¹²

Dieses Dokument spezifiziert einige Anforderungen, die über den Rahmen der IT-Grundschutz-Stufe hinausreichen. Insbesondere diese Anforderungen müssen im Zuge des Audits überprüft werden. Zu diesen Anforderungen gehören:

–

Die erfolgreiche Durchführung der vorgeschriebenen Härtungsmaßnahmen der ausgewählten Komponenten (vergleiche Anforderung A-6.1-2) ist zu überprüfen. Der erfolgreiche Abschluss der im Kapitel 8.4 beschriebenen Penetrationstests muss geprüft und dokumentiert werden.

–

Die Erfüllung der Anforderung A-6.1-2 muss überprüft und das Ergebnis dokumentiert werden.

–

Die netztechnische Abschottung der Portal-Anwendung (vergleiche Anforderung A-6.1-6) muss überprüft und das Ergebnis dokumentiert werden.

–

Die Anforderung A-6.1-9, insbesondere die 1-zu-1-Kommunikation (direkte Weiterleitung der Nachrichten), muss überprüft und das Ergebnis dokumentiert werden.

8.4 Penetrationstests¹²

Im Zuge der Maßnahmen zur Härtung der kritischen Anwendungen müssen an den Komponenten (vergleiche hierzu die Anforderung A-6.1-2 in Kapitel 7.1)

–

„dezentrales Portal“

–

und „Systeme der Fachverfahren“

sogenannte Penetrationstests durchgeführt werden. Der positive Ausgang der Penetrationstests muss dem KBA mitgeteilt werden. Im Falle des negativen Ausgangs der Penetrationstests müssen die aufgezeigten Mängel unverzüglich beseitigt werden sowie deren Beseitigung muss durch eine erfolgreiche Nachprüfung gegenüber dem KBA nachgewiesen werden.

Die Penetrationstests sind jährlich erfolgreich zu wiederholen und das Ergebnis ist im Rahmen des Zulassungsverfahrens dem KBA mitzuteilen.

In bestimmten Fällen kann eine außerordentliche Durchführung von Penetrationstests notwendig sein. Zu diesen Fällen gehören:

–

Feststellung eines scherwiegenden Informationssicherheitsvorfalls und Beseitigung dessen Ursachen – abhängig von den Gegebenheiten, sind im Nachgang die Penetrationstests vollständig, oder punktuell abgestimmt auf die relevanten Bereiche durchzuführen und der positive Ausgang ist dem KBA mitzuteilen.

–

Einsatz einer neuen Hauptversion der Anwendung – es handelt sich hier generell nicht um einen Minor-Update bzw. Sicherheitspatch, sondern um ein Major-Release der Software (z. B. von der Version 2.0 auf die Version 3.0).

–

Durchführung der Änderungen an den kritischen Schnittstellen, insbesondere an den Außenschnittstellen (hier auch im Falle von kleinen Updates und Sicherheitspatches). Begründet können die Penetrationstests partiell innerhalb des betroffenen Bereiches durchgeführt werden.

–

Durchführung von Änderungen an anderen involvierten und sicherheitskritischen Infrastrukturkomponenten – z. B. ein Switch oder ein Paketfilter werden ausgetauscht oder einem Update/Sicherheitspatch unterzogen.

Sollte eine partielle Durchführung des Penetrationstests stattgefunden haben, dann gilt für die nächste vollständige Durchführung die Periode gemessen vom Datum der Durchführung des letzten vollständigen Penetrationstests.

8.5 Beantragung einer Zulassung

Nur zugelassene Kommunikationspartner dürfen im Rahmen des i-Kfz-Projektes mit der KBA-Infrastruktur kommunizieren. Die für die Kommunikation notwendige Zulassung muss von jedem Kommunikationspartner beantragt werden. Der Antragsteller ist dabei stets die korrespondierende Zulassungsbehörde¹³.

Für das Jahr 2015 und im Rahmen der Stufe 1 (Außerbetriebsetzung) des i-Kfz-Projektes gelten folgende Sonderregelungen:

–

Zur initialen Beantragung einer Zulassung muss das Ergebnis des Audits bereits vorliegen. Alternativ muss seitens des Antragstellers erklärt werden, dass die Sicherheitsanforderungen umgesetzt sind und die Penetrationstests sowie das Audit bereits beauftragt wurden (unter Angabe des beauftragten Unternehmens). Die Ergebnisse sind dem KBA dann bis spätestens Ende 2015 vorzulegen.

–

Im Falle bereits bestehender BSI-Grundschutz-Zertifizierung, welche durch ein jährliches Wiederholungsaudit aufgefrischt wird, kann das vom KBA geforderte Audit mit dem Wiederholungsaudit bis Ende 2015 erfolgen.

Der Prozess der Beantragung wird gestartet indem der Antragsteller die Beantragungsdokumente bei der KBA-Kundenbetreuung bestellt. Im Folgenden wird der Beantragungsprozess grob skizziert.

Tabelle 9: Grobe Schritte des Beantragungsprozesses einer Zulassung

8.6 Kündigung einer laufenden Zulassung

Eine laufende Zulassung kann jederzeit seitens des Kommunikationspartners beim KBA schriftlich gekündigt werden. Eine eingegangene Kündigung wird durch das KBA schriftlich bestätigt und beinhaltet das Datum der Deaktivierung des Zugangs.

Die für die Kündigung benötigten Unterlagen können bei der KBA-Anwenderbetreuung erfragt werden (vergleiche Kapitel 8.8).

Eine gekündigte Zulassung, deren Kündigung bestätigt wurde, kann nicht reaktiviert werden. Zur Reaktivierung ist eine erneute initiale Beantragung notwendig.

8.7 Ermahnungsverfahren, Sperrung einer Zulassung

Um ein reibungsloses Zulassungsverfahren anzubieten zu können, müssen auch die Aspekte des Umgangs mit den ggf. auftretenden Versäumnissen geregelt werden. Insbesondere im Falle einer „eingeschränkt gültigen“ bzw. „suspendierten“ Zulassung muss ein Mechanismus definiert werden, welcher die Beseitigung der auferlegten Auflagen steuert und somit eine vollständige Erfüllung der Mindestanforderungen sichert.

Jede formulierte Auflage ist mit einer Erledigungsfrist versehen. Der Kommunikationspartner ist somit verpflichtet unter der Einhaltung dieser Frist die Auflage zu erfüllen.

Sollte keine fristgerechte Erfüllung der Auflage feststellbar sein, dann ist seitens des KBA eine schriftliche Mahnung an den Kommunikationspartner zu richten und eine Ersatzfrist zu nennen. Kommt es im weiteren Verlauf zum wiederholten Verstreichen der Frist, so ist seitens des KBA eine erneute (zweite) Mahnung zu versenden inklusive einer zweiten (finalen) Ersatzfrist. Sollte auch die finale Frist nicht eingehalten werden und die Erfüllung der auferlegten Auflage nicht feststellbar ist, so wird seitens des KBA eine dritte (und letzte) Mahnung an den Kommunikationspartner versendet.

Die betroffene Zulassung wird nach Ablauf der dritten Mahnfrist in den Zustand „ungültig“ überführt. Das KBA sperrt die während des Beantragungsprozesses dem Kommunikationspartner ausgehändigten Zugangsdaten, wodurch mit sofortiger Wirkung keine Möglichkeit des Zugriffs auf die i-Kfz-Webservices besteht.

8.8 Ansprechpartner beim KBA

Technische Informationen bezüglich der Netzanbindung und der Sicherheitsmaßnahmen erhalten Sie durch den technischen Support unter:

Tabelle 10: Kontaktdaten des technischen Supports

Die weiterführenden Informationen zum Beantragungsprozess, sowie die Beantragungsunterlagen erhalten Sie über unserer Anwenderbetreuung:

Tabelle 11: Kontaktdaten der Kundenbetreuung

1.1 Mitgeltende Dokumente

–

Internetbasierte Fahrzeugzulassung (i-Kfz) – Mindest-Sicherheitsanforderungen an dezentrale Portale, Version 1.0

1.2 Abkürzungsverzeichnis

Tabelle 2: Abkürzungsverzeichnis

1.3 Abbildungsverzeichnis

Abbildung 1:

Klassifikation von Penetrationstests (Quelle: [BSI-PENTESTS])

Abbildung 2:

Fünfphasige Vorgehensweise für Penetrationstests (Quelle: [BSI-PENTESTS])

Abbildung 3:

Ausschluss der Module durch die Klassifikationskriterien (Quelle: [BSI-PENTESTS])

Abbildung 4:

Beschreibung eines I-Moduls – Beispiel

Abbildung 5:

Beschreibung eines E-Moduls – Beispiel

1.4 Tabellenverzeichnis

Tabelle  1:

Änderungsverzeichnis

Tabelle  2:

Abkürzungsverzeichnis

Tabelle  3:

Erklärung der Werte der einzelnen Kriterien

Tabelle  4:

Klassifikation der durchzuführenden Penetrationstests

Tabelle  5:

Ausgeschlossene I- und E-Module für spezifizierte Klassifikation

Tabelle  6:

Ausgeschlossene I- und E-Module

Tabelle  7:

Durchzuführende I-Module

Tabelle  8:

Durchzuführende E-Module

Tabelle  9:

Liste der Module zur Informationsbeschaffung (I-Module)

Tabelle 10:

Liste der Module für aktive Eindringungsversuche (E-Module)

Dieses Dokument gilt als eine Anlage zu dem Dokument mit dem Titel „Mindest-Sicherheitsanforderungen an dezentrale Portale“ (vergleiche [KBA-MSADP]). Die in diesem Dokument zitierten Anforderungen kommen aus [KBA-MSADP].

Gemäß der Anforderung A-6.1-2 müssen die Komponenten „dezentrales Portal“ (vergleiche [KBA-MSADP], Kapitel 5.4.7) und „Systeme der Fachverfahren“¹ (vergleiche [KBA-MSADP], Kapitel 5.4.6) besonderen Härtungsmaßnahmen unterzogen werden, um die geforderte Resistenz gegenüber potentiellen Angriffen aufweisen zu können. Zu den Maßnahmen gehört insbesondere eine erfolgreiche Durchführung der in diesem Dokument definierten Penetrationstests.

Ein Penetrationstest besteht dabei stets aus folgenden vier Bestandteilen:

–

Durchführung einer IS-Kurzrevision²,

–

Durchführung eines IS-Webchecks³,

–

Durchführung von Blackbox-Penetrationstests,

–

Durchführung von Whitebox-Penetrationstests.

Es wird empfohlen die Kurzrevision grundsätzlich vorzuziehen, die Reihenfolge der anderen Bestandteile kann variieren.

Die genaue Beschreibung der Modalitäten der Durchführung ist dem Kapitel 8.4 in [KBA-MSADP] zu entnehmen. Im Rahmen dieses Dokumentes wird lediglich die Art sowie Umfang der durchzuführenden Prüfungen dargestellt.

Im Kapitel 3 wird zunächst auf die der Definition zugrunde liegenden Methodik verwiesen sowie diese kurz skizziert. Das darauf folgende Kapitel 4 definiert die mit Hilfe der vorgestellten Methodik beschriebenen Penetrationstests, die zwingend durchgeführt werden müssen.

Hinweis:

Das vorliegende, nicht vollständige Dokument beschreibt die verbindlich zu erfüllenden Anforderungen an die Penetrationstests gem. [KBA-MSADP].

Es handelt sich um eine erste Version, welche nach Vorliegen der Erkenntnisse aus einem noch durchzuführenden Pilot-Penetrationstest unter Leitung des BSI bei Dataport AöR, Hamburg fortgeschrieben wird.

Der Inhalt dieses Kapitels basiert auf den Ausführungen zu Penetrationstests in [BSI-PENTESTS].

Von Grundsatz her kann die Vorgehensweise bei der Durchführung der Penetrationstests in folgende Teilschritte unterteilt werden (vergleiche [BSI-PENTESTS], Kapitel 2.4):

–

Recherche nach Informationen über das Zielsystem,

–

Scan der Zielsysteme auf angebotene Dienste,

–

System und Anwendungserkennung,

–

Recherche nach Schwachstellen,

–

Ausnutzen der Schwachstellen.

3.1 Einordnung und Zielsetzung

Ein wichtiger Aspekt, der für eine erfolgreiche Durchführung aus der Sicht des Auftraggebers unabdingbar ist, ist eine klare Zielvereinbarung für die Tests. In [BSI-PENTESTS], Kapitel 3.2, werden vier gängige Gruppen der Ziele vorgestellt.

Um eine Möglichkeit einer allgemeinverständlichen Beschreibung der Penetrationstests zu schaffen, definiert [BSI-PENTESTS] im Kapitel 3.4 eine Klassifikation, die unter Verwendung von sechs Kriterien (Informationsbasis, Aggressivität, Umfang, Vorgehensweise, Technik und Ausgangspunkt) die Penetrationstests geeignet charakterisieren kann (vergleiche Abbildung 1).

Abbildung 1: Klassifikation von Penetrationstests (Quelle: [BSI-PENTESTS])

In Tabelle 3 werden die Werte der einzelnen Kriterien kurz beschrieben.

Tabelle 3: Erklärung der Werte der einzelnen Kriterien

3.2 Rechtliche Aspekte

Die Durchführung der Penetrationstests simuliert einen Angriff auf die Ressourcen des Auftraggebers. Dieses Vorgehen zieht normalerweise juristische Konsequenzen, bezogen auf den Angreifer, nach sich. Aus diesem Grund ist es wichtig das geplante Vorhaben sehr genau in Form eines Vertrags zwischen dem Tester und Auftraggeber festzulegen (vergleiche [BSI-PENTESTS], Kapitel 4.3).

Weiterhin sind sehr oft im Zuge der Durchführung von Penetrationstests Daten, die unter besonderen Schutz (z. B. personenbezogene Daten) offengelegt wurden. Der Umgang mit solchen Daten ist sehr präzise geregelt und muss unbedingt befolgt werden (z. B. durch Einbeziehung des Datenschutzbeauftragten, eines Vertreters der HR-Abteilung etc.).

Eine tiefergreifende Betrachtung der rechtlichen Aspekte ist dem Kapitel 4 in [BSI-PENTESTS] zu entnehmen.

3.3 Weitere Rahmenbedingungen

Abgesehen vom rechtlichen Rahmen (vergleiche Kapitel 3.2) müssen bei der Durchführung von Penetrationstests auch die organisatorischen (vergleiche [BSI-PENTESTS], Kapitel 5.1), personellen (vergleiche [BSI-PENTESTS], Kapitel 5.2) und technischen (vergleiche [BSI-PENTESTS], Kapitel 5.3) Bedingungen erörtert werden.

3.4 Durchführung

Die Durchführung der Penetrationstests wird gemäß [BSI-PENTESTS] in fünf Phasen unterteilt:

–

Vorbereitung,

–

Informationsbeschaffung,

–

Bewertung der Information/Risikoanalyse,

–

Eindringversuche und

–

Abschlussanalyse.

Diese Phasen werden dabei stets parallel von einer zusätzlichen Phase – Dokumentation – begleitet (vergleiche Abbildung 2).

Abbildung 2: Fünfphasige Vorgehensweise für Penetrationstests (Quelle: [BSI-PENTESTS])

Detailliertere Beschreibung des Vorgehens ist dem Kapitel 6.3 in [BSI-PENTESTS] zu entnehmen.

Insbesondere werden in den Phasen 2 und 4 mit Hilfe der sogenannten I- und E-Module (vergleiche Kapitel 6) die tatsächlichen Tests durchgeführt. Die Auswahl der Module erfolgt nach einem negativen Ausschlussprinzip anhand der gewählten Klassifikation (vergleiche [BSI-PENTESTS], Kapitel 6.4.4 und Abbildung 3). Wird ein Modul nicht ausgeschlossen, so muss es durchgeführt werden. Falls ein Modul aus anderen Gründen ausgeschlossen werden soll, so müssen die dafür vorliegenden Gründe erläutert und dokumentiert werden.

Abbildung 3: Ausschluss der Module durch die Klassifikationskriterien (Quelle: [BSI-PENTESTS])

Abbildung 3 zeigt die Zuordnung der auszuschließenden I- und E-Module pro Klassifikationskriterium.

In diesem Kapitel werden die Prüfungen beschrieben, deren erfolgreiche Durchführung im Rahmen des Zulassungsverfahrens für die Anbindung an die KBA-Infrastruktur (vergleiche [KBA-MSADP], Abschnitt 8) gegenüber dem KBA nachgewiesen werden müssen.

Die Durchführung der im Rahmen dieses Dokumentes vorgeschriebenen Prüfungen soll die Bestätigung der Infomationssicherheit durch einen externen Dritten als Ziel verfolgen.

4.1 IS-Kurzrevision

Die IS-Kurzrevision dient der Unterstützung bei der Umsetzung und Optimierung der Informationssicherheit. Gegenstand ist die Basisabsicherung nach IT-Grundschutz. Dabei werden auch Aspekte, wie die Einbettung in die Infrastruktur oder organisatorische Fragen untersucht.

Die Durchführung einer IS-Kurzrevision erfolgt nach der vom BSI herausgegebenen Methodik⁴.

4.2 IS-Webcheck

Der IS-Webcheck dient der Prüfung des Sicherheitsstandards einer Internetpräsenz durch den Einsatz automatisierter Methoden.

Die Durchführung eines IS-Webchecks erfolgt nach der vom BSI herausgegebenen Methodik⁵.

4.3 IS-Penetrationstest

Der IS-Pentest untersucht vorrangig die Schnittstellen einer Institution nach außen über die potentielle Angreifer die IT-Systeme kompromittieren könnten.

4.3.1 Klassifikation

Es werden IS-Penetrationstests mit folgenden Klassifikationen (vergleiche Tabelle 4) gefordert:

Tabelle 4: Klassifikation der durchzuführenden Penetrationstests

Für die Auswahl der beiden Klassifikationen war das Kriterium Technik von entscheidender Bedeutung. Einerseits werden die Netzwerkinfrastruktur und andererseits die physikalische Absicherung der Umgebung betrachtet.

4.3.2 Ausgeschlossene I-/E-Module

Basierend auf der in Tabelle 4 dargelegten Klassifikation ergibt sich folgende Tabelle der ausgeschlossenen I- und E-Module.

Tabelle 5: Ausgeschlossene I- und E-Module für spezifizierte Klassifikation

Somit ergibt sich, dass die folgenden Module ausgeschlossen sind:

Tabelle 6: Ausgeschlossene I- und E-Module

Die durchzuführenden Module sind der Tabelle 7 und der Tabelle 8 zu entnehmen.

Tabelle 7: Durchzuführende I-Module

Tabelle 8: Durchzuführende E-Module

Die konkreten, durchzuführenden Prüfungsschritte sind in der Beschreibung der jeweiligen Module enthalten (vergleiche [BSI-PENTESTS], Kapitel 6.5).

4.3.3 Dokumentation

Die erfolgreiche Absolvierung der Penetrationstests muss dokumentiert werden. Diese Dokumentation muss dem KBA entsprechend vorgelegt werden (vergleiche hierzu [KBA-MSADP], Kapitel 8.4).

Die Dokumentation soll zumindest folgende Bestandteile aufweisen:

1.

Die Dokumentation der durchgeführten Prüfungsschritte zur Informationsbeschaffung einschließlich einer Liste der geprüften Schwachstellen,

2.

die Dokumentation der durchgeführten Prüfungsschritte bei den Eindringversuchen einschließlich einer Liste der geprüften Schwachstellen,

3.

Abschlussbericht.

4.3.4 Übersicht über relevante Angriffstechniken

In diesem Kapitel wird eine kurze Übersicht über die üblichen Angriffstechniken vermittelt, deren Verwendung empfohlen wird. Weiterhin wird zu jeder vorgestellten Angriffstechnik ein Mapping auf die relevante Module eingegeben.

Netzwerk- und Portscanning

Es können offensichtliche und/oder auch verdeckte Scan-Aktivitäten durchgeführt werden. Die Durchführung zielt auf die Auffindung der im untersuchten Netz aktiven IT-Systeme und somit Identifizierung der dahinter stehenden Dienste (hier gegeben durch bestimmte Ports) ab. Die gewonnenen Erkenntnisse dienen als Informationsbasis für die weiterführenden Aktivitäten.

Involvierte I- und E-Module: I3, I4, I5, I7, I8, I9, I10, I11, I12, I13.

Ausnutzung mangelhafter Eingabeüberprüfung

Die vom Benutzer getätigten Eingaben sollten auf deren Korrektheit und Plausibilität geprüft und ggf. zurückgewiesen werden. Findet diese Filterung nicht bzw. im unzureichenden Umfang statt, besteht unter Umständen eine Möglichkeit in das System einen fremden Code einzuschleusen und die Anwendung in der Funktionalität zu beeinträchtigen oder geschützte Information zu gewinnen (z. B. Cross-Site-Scripting⁶ [XSS], LDAP-/SQL-Injection⁷, etc.).

Involvierte I- und E-Module: E1, E2, E3, E6, E7, E8, E9, I10, E11.

Denial-of-Service-Angriffe (DOS) – optional

DOS und insbesondere die verteilte Variante hiervon – D-DOS gehören zu sehr aggressiven Angriffstechniken. Das Ziel des Angriffs ist die Blockierung des untersuchten Netzes oder IT-Systems, normalerweise mit Hilfe eines massiv erhöhten Datenaufkommens oder der Ausnutzung möglicher Software-Schwachstellen (z. B. Ping of Death⁸). Aus diesem Grund ist es einzeln abzuwägen, im welchem Umfang diese Techniken während der Penetrationstests zum Einsatz kommen sollen.

Involvierte I- und E-Module: E13 – kein ausgewähltes Modul.

Information Gathering

Durchführung von Aktivitäten, die die Vorbereitung einer Informationsbasis für die Durchführung der tatsächlichen Attacken ermöglichen sollen (z. B. ein Versuch, die benutzten Schemata für die Benennung der Systeme und Verzeichnisse zu identifizieren).

Involvierte I- und E-Module: I1, I2, I3, I6, I12.

Passwort-Attacken

Der Versuch die benutzten Kennwörter mit Hilfe unterschiedlicher Techniken zu kompromittieren. Die Angriffspalette reicht hier vom einfachen Ausprobieren der Standard-Passwörter, über die sogenannten Wörterbuchattacken⁹ bis hin zu Brute-Force-Attacken¹⁰.

Involvierte I- und E-Module: E4, E5, E11, E12.

Ausnutzen von Software-Schwachstellen

Zum Umfang dieser Technik gehört das Ausprobieren bekannter Schwachstellen einer Software, indem Exploits¹¹ eingesetzt werden.

Involvierte I- und E-Module: E1, E2, E3, I10.

Kryptographische Angriffe

Die Angriffe dieser Kategorie versuchen Schwachstellen eingesetzter Verschlüsselungsalgorithmen und Schlüsselverwaltungen in Implementierungen zu überprüfen.

Involvierte I- und E-Module: E5.

Infrastruktur-Untersuchungen

Unter diese Kategorie fällt die Untersuchung von baulichen Maßnahmen, wie z. B. die Zutritts- bzw. Schließungseinrichtungen. Darüber hinaus sind weiterreichende Aspekte, wie z. B. ordnungsgemäße Entsorgung von Materialien (z. B. Dumpster Diving) inbegriffen.

Involvierte I- und E-Module: I21, E22.

6.1 Vollständige Auflistung der I-/E-Module

Tabelle 9: Liste der Module zur Informationsbeschaffung (I-Module)

Tabelle 10: Liste der Module für aktive Eindringungsversuche (E-Module)

6.2 Beispiele einer Beschreibung der I-/E-Module

Abbildung 4: Beschreibung eines I-Moduls – Beispiel

Abbildung 5: Beschreibung eines E-Moduls – Beispiel