Version
      
2.5.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
02.03.2020
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_KSR
     
    

TIP1-A_3312 - Nur zugelassene Update-Pakete im Downloadbereich der PU

Der Konfigurationsdienst MUSS sicherstellen, dass nur Update-Pakete in den Downloadbereich der Produktivumgebung der TI (PU) gelangen

• deren Bereitstellung im Downloadbereich der PU durch den GTI beauftragt wurde und
  
• die eine Zulassung durch die gematik besitzen.
  

[<=]

TIP1-A_5157 - Nur freigegebene Konfigurationsdatenfiles im Downloadbereich der PU

Der Konfigurationsdienst MUSS sicherstellen, dass nur Konfigurationsdatenfiles in den Downloadbereich der Produktivumgebung der TI (PU) gelangen

• deren Bereitstellung im Downloadbereich der PU durch den GTI beauftragt wurde.
  

[<=]

TIP1-A_3313 - Anzahl Update-Pakete pro dezentralem Produkt

Der Konfigurationsdienst MUSS für alle dezentralen Produkte mindestens die Update-Pakete speichern können, die der Hersteller in der aktuellen Firmware-Gruppen-Informationen referenziert. Der Speicherplatz für die Update-Pakete muss skalierbar sein.

[<=]

TIP1-A_6129 - Bereitzustellende Dateien pro Update-Paket

Der Konfigurationsdienst MUSS für jedes freigegebene Update-Paket die folgenden Dateien im KSR Downloadbereich zur Übertragung mit Operation I_KSRS_Download::getUpdates für den KSR Client bereitstellen:

• Die in UpdateInfo.xml referenzierten Dateien

• Die optionale detached Signatur „UpdateInfo.sig

[<=]

TIP1-A_3314 - Inhalt Update-Paket – Hersteller-Update-Informationen

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN in jedem Firmware-Update-Paket ein File mit Namen UpdateInfo.xml mit Hersteller-Update-Informationen gemäß Element UpdateInformation aus Konfigurationsdienst.xsd (siehe auch Abbildung Abb_KSR_005 und Tabellen Tab_KSR_004-009, Tab_KSR_012-020) liefern.

[<=]

TIP1-A_3895 - Inhalt Update-Paket – Konnektor FirmwareFiles

Hersteller von Konnektoren MÜSSEN in jedem Firmware-Update-Paket 0 bis maximal 999 Firmwarefile(s) liefern.

[<=]

TIP1-A_5158 - Inhalt Update-Paket – Kartenterminal FirmwareFiles

 Hersteller von Kartenterminals MÜSSEN in jedem Firmware-Update-Paket genau ein Firmware File liefern.
[<=]

TIP1-A_3315 - Inhalt Update-Paket – DokumentationFiles

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN in jedem Firmware-Update-Paket bis zu maximal 999 Files mit Dokumentationen für das Update liefern.

[<=]

TIP1-A_5159 - Inhalt Update-Paket – Firmware-Gruppen-Information

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN in jedem Firmware-Update-Paket ein File mit der aktuell gültigen Firmware-Gruppen-Information gemäß „Abb_KSR_007 Firmware-Gruppen-Informationen“ liefern. Diese Firmware-Gruppen-Information muss der im Firmwarefile enthaltenen Information entsprechen.

[<=]

TIP1-A_3347 - Integrität und Authentizität

Der Konfigurationsdienst MUSS die Integrität und Authentizität der durch den Hersteller von Komponenten, die den KSR nutzen, übermittelten Update-Pakete (Gesamtpaket) bis zur Übertragung an den KSR-Client durch die Prüfung der Update-Paket – Signatur (TIP1-A_6123) gewährleisten.

[<=]

TIP1-A_6777 - KSR, Hersteller von Konnektoren, Deadline und alternative URL

Hersteller von Konnektoren MÜSSEN im Update-Paket in der Datei UpdateInfo.xml im Element KSR:FirmwareReleaseNotes eine URL für einen separaten Downloadpunkt des Update-Pakets im Internet angeben und, wenn das Element KSR:Priority den Wert „Kritisch“ hat, im Element UpdateInformation das Element KSR:Deadline mit einem gültigen Wert befüllen.

[<=]

TIP1-A_6778 - KSR, GTI, Deadline und alternative URL

Der GTI MUSS im Rahmen der Freigabe eines Konnektor-Update-Pakets für die PU prüfen, dass das Update-Paket in der Datei UpdateInfo.xml im Element KSR:FirmwareReleaseNotes eine URL für einen separaten Downloadpunkt des Update-Pakets im Internet enthalten ist und, wenn das Element KSR:Priority den Wert „Kritisch“ hat, im Element UpdateInformation das Element KSR:Deadline mit einem gültigen Wert enthalten ist.
Wenn die Deadline (bei KSR:Priority = „Kritisch“) oder die URL nicht enthalten sind, muss die Freigabe abgelehnt werden.
[<=]

TIP1-A_3896 - Signatur der Update-Informationen durch Konnektorhersteller

Konnektorhersteller MÜSSEN die Update-Informationen (UpdateInfo.xml) signieren. Dazu kann er das Element UpdateInformationSignature in den Update-Informationen oder eine detached Signatur nutzen.

[<=]

A_14538 - KSR – Richtlinien zum Erhalt der Update-Informationen Signatur

Der Konfigurationsdienst MUSS gewährleisten, dass die UpdateInformation-Elemente in der I_KSRS_Download::listUpdates Response an den Konnektor bis auf kanonische Transformationen gleich denen der zugehörigen Dateien in den Firmware-Update-Paketen sind.
Die Prüfung der Gleichheit MUSS durch folgende Schritte möglich sein:

1. XML-Element UpdateInformation aus der I_KSRS_Download::listUpdates Response ausschneiden und als root-Element in extra Datei ablegen, die eine XML-Deklaration zum Encoding wie die I_KSRS_Download::listUpdates Response erhält.
2. Die so erzeugte Datei und ursprüngliche Paketdatei wie folgt kanonisieren:
• Inhalt des Elements KSR:UpdateInformationSignature wird entfernt.
• Default-Namespace Deklaration wird im root-Element gesetzt.
• XML Kanonisierung  wird gemäß https://www.w3.org/TR/xml-c14n11/durchgeführt.
3. Wenn die so erhaltenen Dateien bitweise identisch sind, besteht Gleichheit, andernfalls keine Gleichheit.

[<=]

TIP1-A_3897 - Keine Signatur der Update-Informationen durch Kartenterminalhersteller

Kartenterminalhersteller SOLLEN die Update-Informationen (UpdateInfo.xml) NICHT signieren.

[<=]

TIP1-A_3316 - Firmware-Gruppenkonzept Informationen für den Konfigurationsdienst

Der Hersteller einer dezentralen Komponente, welche das Firmware-Gruppenkonzept unterstützt und Firmware an den Konfigurationsdienst liefert, MUSS dem Konfigurationsdienst Informationen über die aktuelle Firmware-Gruppe bereitstellen.
Der Hersteller MUSS für die aktuelle Firmware-Gruppe folgende Informationen bereitstellen:

Abbildung 10: Abb_KSR_007 Firmware-Gruppen-Informationen

Tabelle 21: Tab_KSR_021 Firmware-Gruppen-Information – Element FirmwareGroupID

Bezeichnung	FirmwareGroupID
Beschreibung	Identifiziert die Firmware-Gruppe eindeutig.
Befüllung	Hersteller von Komponenten, die den KSR nutzen
Optional	Nein
Wertebereich	Entspricht dem Wertebereich vom XML-Datentyp „string“ mit dem Pattern „[a-zA-Z0-9_]*“. Maximale Länge: 32 Zeichen

Tabelle 22: Tab_KSR_022 Firmware-Gruppen-Information – Element FirmwareGroupVersion

Bezeichnung	FirmwareGroupVersion
Beschreibung	Die Versionsnummer der aktuellen Firmware-Gruppe. Laut GS-A_4868 [gemSpec_OM] muss die Firmware-Gruppe mit aufsteigenden ganzzahligen Nummern versioniert werden. Der Inhalt wird als nummerisches Feld interpretiert.
Optional	nein
Wertebereich	Entspricht dem Wertebereich vom XML-Datentyp „string“ mit dem Pattern „[0-9]*“ (ganzzahlige Zahlen). Maximale Länge 5 Zeichen.

Tabelle 23: Tab_KSR_023 Firmware-Gruppen-Information – Element FirmwareGroupReleaseNotes

Bezeichnung	FirmwareGroupReleaseNotes
Beschreibung	Durch den Hersteller von Komponenten, die den KSR nutzen, erstellte Beschreibung der Firmware-Gruppe. Falls es Abhängigkeiten zwischen den referenzierten Produktversionen (Update-Paketen) gibt, MUSS der Hersteller sie hier beschreiben.
Optional	nein
Wertebereich	Entspricht dem Wertebereich vom XML-Datentyp „string“. Maximale Länge 2048 Zeichen.

Tabelle 24: Tab_KSR_024 Firmware-Gruppen-Information – Element FirmwareGroupSignature

Bezeichnung	FirmwareGroupSignature
Beschreibung	Dieses Element kann der Hersteller von Komponenten, die den KSR nutzen, zur Signatur der Firmware-Gruppen-Information nutzen. Die Signatur wird in TIP1-A_6133 definiert. Der Hersteller kann die Signatur auch als „Detached“-Signature nach dem in 5.3.1 definierten Verfahren im Update-Paket speichern. Sofern dieses Feld durch den Hersteller verwendet wird, entspricht der Inhalt des Feldes einer Detached-Signature in einem Base64-Codierten String.
Befüllung	Hersteller von Komponenten, die den KSR nutzen
Optional	Ja.
Wertebereich	Any (vom Hersteller festzulegen)

Die Parameter ProductVendorID, ProductCode, HWVersion, CreationDate und FWVersion entsprechen den Definitionen in Tabellen Tab_KSR_005, Tab_KSR_006, Tab_KSR_007, Tab_KSR_009 und Tab_KSR_014.
Die Parameter ProductVendorID, ProductCode, HWVersion identifizieren zusammen die Hardware, für welche die Firmware-Gruppen-Information gilt.
Das Element FWVersion enthält die Liste der aktuell durch den Hersteller von Komponenten, die den KSR nutzen, unterstützten und zugelassenen Firmwareversionen. Es können bis zu 999 FWVersionen in der Liste enthalten sein.
[<=]

TIP1-A_6131 - FirmwareGroupInfo.xml und UpdateInfo.xml - Format

Der Konfigurationsdienst und Hersteller von Komponenten, die den KSR nutzen, MÜSSEN die Datei FirmwareGroupInfo.xml und UpdateInfo.xml nach folgenden Vorgaben prüfen bzw. bereitstellen:

• Die Datei verwendet das charset-encoding „UTF-8“

• Die Datei definiert den Namespace http://ws.gematik.de/ksr/v1.1 als Default-Namespace.

• Es ist keine „schemaLocation“ enthalten. Die Validierung erfolgt ausschließlich mit lokalen Schemadateien im jeweiligen System.

• Die Datei kann erfolgreich gegen das XSD-Schema „Konfigurationsdienst.xsd“ validiert werden.

[<=]

TIP1-A_3317 - Firmware-Gruppenkonzept – Lieferung mit Firmware

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN die Firmware-Gruppen-Information zusammen mit dem Firmware-Update, welches die neue Firmware-Gruppe enthält an den Konfigurationsdienst übergeben.

[<=]

TIP1-A_3908 - Firmware-Gruppenkonzept – Streichung Firmware

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN eine aktualisierte Firmware-Gruppen-Information an den Konfigurationsdienst übergeben, wenn eine bisher enthaltene Firmwareversion ungültig (z.B. Sicherheitsproblem, fehlerhafte Firmware, nicht mehr unterstützte Firmware,…) wird.

[<=]

TIP1-A_3318 - Firmware-Gruppenkonzept – Lieferung ohne Firmware

Hersteller von Komponenten, die den KSR nutzen, KÖNNEN die Firmware-Gruppen-Information ohne Zusammenhang zu einem Firmware-Update an den Konfigurationsdienst übergeben, falls zu dieser Firmware-Gruppen-Information kein Firmware-Update gehört.

[<=]

TIP1-A_3319 - Firmware-Gruppenkonzept – Aktive Firmware-Gruppen-Information

Der Konfigurationsdienst MUSS für jedes Produkt vom Produkttyp Konnektor und eHealth-Kartenterminal genau eine „aktive“ Firmware-Gruppen-Information verwalten.

Ein Produkt ist eindeutig identifiziert über die Attribute

• Hersteller-/Anbieter-ID

• Produktkürzel

• Hardwareversion.

[<=]

TIP1-A_3320 - Firmware-Gruppenkonzept - Übernahme Firmware-Gruppe

Der Konfigurationsdienst MUSS die in einem Update enthaltene bzw. einzeln gelieferte Firmware-Gruppen-Information übernehmen, wenn

• eine Freigabe für das Update-Paket, welches die Firmware-Gruppen-Information enthält, bzw. die einzeln gelieferte Firmware-Gruppen-Information vorliegt und

• die Firmware-Gruppen-Information eine höhere Versionsnummer hat als die der aktuell vorliegenden Firmware-Gruppen-Information und

• Integrität und Authentizität der Firmware-Gruppen-Information erfolgreich geprüft wurde.

[<=]

TIP1-A_3321 - Firmware-Gruppenkonzept – Unterstützte Firmware Versionen

Der Konfigurationsdienst MUSS für jedes Produkt ausschließlich die Firmware-Versionen der „aktiven“ Firmware-Gruppen-Information zum Download anbieten.

[<=]

TIP1-A_3322 - Firmware-Gruppenkonzept – Integritäts- und Authentizitätsschutz

Der Konfigurationsdienst MUSS – zusammen mit dem Hersteller von Komponenten, die den KSR nutzen, – die Integrität und Authentizität der Firmware-Gruppen-Information für die gesamte Lebenszeit dieser Informationen gewährleisten.

[<=]

TIP1-A_6108 - FirmwareGroupInfo.xml Signatur

Der Konfigurationsdienst und Hersteller von Komponenten, die den KSR nutzen, MÜSSEN die Detached-Signature der FirmwareGroupInfo.xml und das in TIP1-A_6133 definierte FirmwareGroupInfo.xml - Element „FirmwareGroupSignature“ unterstützen bzw. prüfen.  
[<=]

TIP1-A_6132 - Detached-Signature der FirmwareGroupInfo.xml

Bei Verwendung einer Detached-Signatur MÜSSEN Hersteller von Komponenten, die den KSR nutzen, und der Konfigurationsdienst eine Detached-Signature (UTF-8-kodierte XML-Datei) zur Datei „FirmwareGroupInfo.xml“ mit folgenden Eigenschaften bereitstellen bzw. prüfen:

• Die Signatur hat die XAdES-Form. Optionale XAdES-Attribute sind erlaubt, werden aber bei der Signaturprüfung ignoriert.
  
• Die Signatur erfolgt über das gesamte XML-Dokument nach Kanonisierung. Ein etwaig angegebenes URI-Attribut des zugehörigen Reference-Elements wird bei der Signaturprüfung akzeptiert, aber nicht geprüft.
  
• Es werden alle Kanonisierungsverfahren gemäß [XML-DSIG] unterstützt.
  
• Eine Transformationsvorschrift im Reference-Element über das Dokument

• Die Signatur enthält das Signer-Zertifikat im XML-Block des XML-Elementes KeyInfo.
  
• Die Signatur ist konform mit der Anforderung [gemSpec_Krypt# GS-A_4370] und [gemSpec_Krypt#A_17360].
  
• Für die Signatur ist das gleiche Zertifikat zu verwenden mit dem auch das Update-Paket signiert ist.

[<=]

TIP1-A_6133 - FirmwareGroupInfo.xml - Element „FirmwareGroupSignature“

Bei Verwendung des Elements „FirmwareGroupSignature“ in der Datei „FirmwareGroupInfo.xml“ MÜSSEN Hersteller von Komponenten, die den KSR nutzen, und der Konfigurationsdienst den Inhalt nach folgender Vorgabe bereitstellen bzw. prüfen:

• Die Signatur wurde als Detached-Signature [TIP1-A_6132] erstellt.
  
• Die erstellte Signatur wurde in einer UTF-8 kodierte XML-Datei gespeichert und diese als Base64-Codierter String in das Feld „FirmwareGroupSignature“ geschrieben.

[<=]

TIP1-A_5154 - Konfigurationsdatenfiles zur Anbindung von Bestandsnetzen

Der Anbieter des Konfigurationsdienstes MUSS für die über Aufträge bereitgestellten Konfigurationsdaten zur Anbindung von Bestandsnetzen Konfigurationsdatenfiles erstellen. Die Konfigurationsdatenfiles MÜSSEN auf dem XML-Schema [InfrastrukturKonfig.xsd] entsprechend Abb_KSR_014 basieren und den Vorgaben aus Tabelle Tab_KSR_045 genügen.

[<=]

TIP1-A_6134 - Konfigurationsdatenfile - Format

Der Konfigurationsdienst DARF NICHT von folgenden Vorgaben abweichende Formate akzeptieren:

• Die Datei verwendet das charset-encoding „UTF-8“
  
• Es ist keine „schemaLocation“ enthalten. Die Validierung erfolgt ausschließlich mit lokalen Schemadateien im jeweiligen System.
  
• Die Datei kann erfolgreich gegen das XSD-Schema „InfrastrukturKonfig.xsd“ validiert werden.
  

[<=]

TIP1-A_3323 - Konfigurationsdienst TLS-Authentisierung

Der Konfigurationsdienst MUSS bei der Absicherung der Verbindung zum Konnektor durch TLS die einseitige Serverauthentisierung unter Nutzung des X.509-Komponentenzertifikats mit der TLS-Server-Identität ID.ZD.TLS_S zur Serverauthentisierung umsetzen.

[<=]

TIP1-A_3324 - Konfigurationsdienst TLS-Zertifikatserstellung

Der Anbieter des Konfigurationsdienstes MUSS beim zuständigen PKI-Registrierungsdienst über die Schnittstelle I_Cert_Provisioning [gemKPT_Arch_TIP] das X.509-Komponentenzertifikat mit der TLS-Server-Identität ID.ZD.TLS_S zur TLS Serverauthentisierung beantragen.
​​

[<=]

TIP1-A_3325 - Konfigurationsdienst Keine Verbindungen ohne TLS

Der Konfigurationsdienst MUSS an der Schnittstelle zum Konnektor ausschließlich Verbindungen mit TLS akzeptieren.

[<=]

TIP1-A_3326 - IPv4 und Ipv6 Unterstützung

Der Konfigurationsdienst MUSS IPv4 und IPv6 parallel unterstützen (Dual-Stack-Modus).

[<=]

TIP1-A_6130 - Bereitstellung DNS Resource Records

Der Anbieter des KSR MUSS SRV und optional TXT Resource Records im DNS bereitstellen. Wenn die TXT Resource Records nicht existieren MÜSSEN die <PFAD1> und <PFAD2> Anteile der URL leere Strings sein.
Im DNS sind dazu folgende Einträge durch den KSR Anbieter einzutragen:

Owner                                  TTL Class Type Data
_ksrfirmware._tcp.ksr.<TOP_LEVEL_DOMAIN_TI> <TTL1> <IN> <SRV> <Priorität1>  <Gewicht1>  <Port1>  <FQDN1>
_ksrfirmware._tcp.ksr.<TOP_LEVEL_DOMAIN_TI> <TTL2> <IN> <TXT> "txtvers=<VERSION1>" "path=<PFAD1>"
_ksrkonfig._tcp.ksr.<TOP_LEVEL_DOMAIN_TI> <TTL3> <IN> <SRV> <Priorität2>  <Gewicht2>  <Port2>  <FQDN2>
_ksrkonfig._tcp.ksr.<TOP_LEVEL_DOMAIN_TI> <TTL4> <IN> <TXT> "txtvers=<VERSION2>" "path=<PFAD2>"

TOP_LEVEL_DOMAIN_TI: in der PU = telematik.; in der RU/TU = telematik-test.
[<=]

TIP1-A_3328 - Logging Datenänderungen im Konfigurationsdienst

Der Konfigurationsdienst MUSS für alle Aktionen (sowohl intern wie auch an den Außenschnittstellen) mit Update-Paketen und Firmware-Gruppen-Informationen und Konfigurationsdatenfiles Log-Informationen erfassen. Dabei MUSS mindestens folgende Information gespeichert/bereitgestellt werden:

• Wer hat etwas getan

• Was hat er getan

• Mit welchem Informationsobjekt

• Zeitpunkt der Aktion  

[<=]

TIP1-A_6135 - Löschen der Logging-Daten

Der Konfigurationsdienst MUSS die gesammelten Logging-Daten nach einer konfigurierten Zeitspanne, spätestens aber nach 90 Tagen aus dem Konfigurationsdienst entfernen.
​​

[<=]

TIP1-A_6136 - Umfang der gespeicherten Logdaten

Der Konfigurationsdienst MUSS die in Tabelle 26 „Logdatenformat“ enthaltenen Felder entsprechend ihrer Definition füllen und persistent speichern.

Tabelle 25: Tab_KSR_048 Logdatenformat

Position	Feld	Beschreibung	Typ
1	Timestamp	Zeitpunkt, zu dem die Aktion gestartet wurde.	String, Timestamp-Format „YYYY-MM-DD HH:mm:SS,SSS”, Beispiel: „2014-01-08 09:46:18,780“. Die Zeitzone ist UTC
2	UserID	Eindeutiger Identifikator des eingeloggten Users, bzw. des ausführenden Herstellers (z.B. beim Upload oder Download einer Datei). Sofern das System selbst die Aktion gestartet hat (z.B. durch einen Timer), wird das Feld mit der ID „SYSTEM_KSR“ belegt.	String, max. 32 Zeichen
3	InfoID	Identifiziert das Informationsobjekt, mit dem die Aktion ausgeführt wurde. Z.B. UpdateID, FirmwareGroupId	String, max. 255 Zeichen
4	Action	Bezeichner der durchgeführten Aktion, z.B. „FREIGABE“, „UPLOAD“,	String, max. 32 Zeichen
5	State	Status-Ergebnis der durchgeführten Aktion.	String, entweder „ERFOLG“, „FEHLER“ oder „REMOTE-FEHLER“
6	Description	Textuelle Beschreibung des Ergebnisses der ausgeführten Aktion. Kann leer sein, wenn die Aktion korrekt ausgeführt wurde, enthält in einem Fehlerfall, die Fehlerbeschreibung.	String, max. 2048 Zeichen

Der Inhalt im Feld InfoID ist abhängig von dem Wert im Feld Action nach den Angaben der folgenden Tabelle. Das Operator-Zeichen „|“ im Feld InfoID steht für ENTWEDER ODER der Parameter des Feldes. Ein Feld hat den Wert des linken Operands, wenn dieser nicht leer ist und damit gültig ist und hat andernfalls den Wert des rechten Operands.

Tabelle 26: Tab_KSR_049 Werte im Feld InfoID zu Action

Action	InfoID
FILE_UPLOAD	FILE-IDENTIFIER
INSERT_CONFIG	FILE-IDENTIFIER
PROZESS_FREIGABE_UPDATE_PAKET_AKZEPTIERT	UPDATE-ID | FIRMWAREGROUP-ID
PROZESS_FREIGABE_UPDATE_PAKET_FREIGEGEBEN	UPDATE-ID | FIRMWAREGROUP-ID
PROZESS_FREIGABE_UPDATE_PAKET_AKTIVIERT	UPDATE-ID | FIRMWAREGROUPID
PROZESS_FREIGABE_UPDATE_PAKET_ABGELEHNT	FILE-IDENTIFIER
PROZESS_FREIGABE_UPDATE_PAKET_DEAKTIVIERT	UPDATE-ID | FIRMWAREGROUP-ID
get_Updates	UPDATE-ID | Bestandsnetze.xml
list_Updates	FIRMWAREGROUP-ID
BESTANDSNETZE_UPLOAD	Bestandsnetze.xml
BESTANDSNETZE_CONFIRM	Bestandsnetze.xml
BESTANDSNETZE_REJECT	Bestandsnetze.xml

[<=]

A_17455 - KSR Logging-Daten – Bereitstellung

Der Konfigurationsdienst MUSS täglich zu einem konfigurierbaren Zeitpunkt - die im Konfigurationsdienst angefallenen - Logging-Daten entsprechend Tab_KSR_048 an die Schnittstelle I_OpsData_Update [gemSpec_SST_LD_BD] liefern. Dazu MUSS die Schnittstelle I_OpsData_Update::fileUpload benutzt werden.
Die Logging-Daten MÜSSEN für jeden vollständigen Berichtszeitraum in einer Datei mit folgenden Namenskonventionen gesendet werden:

KSR_Logging_<Start>_<Ende>.csv

<Start> und <Ende> entspricht den Festlegungen in A_17453.
Der Konfigurationsdienst MUSS in jedem Sendevorgang alle seit dem letzten Senden angefallenen Dateien senden.
[<=]

TIP1-A_6102 - Datei-Format Logging- und Statistik-Daten

Der Konfigurationsdienst MUSS die Logging- und Statistik-Daten im CSV-Format bereitstellen.

• Die Datei verwendet UTF-8 Codierung
  
• Die Zeilenenden schließen mit dem LF-Zeichen (0x10) ab.
  
• Das Trennzeichen zwischen den Werten ist „;“
  

[<=]

TIP1-A_5038 - FehlerLog

Der Konfigurationsdienst MUSS lokal erkannte Fehler und Remote-Fehler im lokalen Protokollspeicher (FehlerLog) protokollieren.

[<=]

TIP1-A_5039 - Remote-Fehlerbehandlung

Der Konfigurationsdienst MUSS für empfangene Fehlermeldungen von anderen Komponenten folgende allgemeine Vorgaben berücksichtigen:

• Empfangene Fehlermeldungen sind als Remote-Fehler zu protokollieren.

• Durch empfangene Fehlermeldungen resultierende Folgefehler KÖNNEN an die Fehlermeldung angefügt werden.

[<=]

TIP1-A_3353-01 - Inhalt der statistischen Daten

Der Anbieter des Konfigurationsdienstes MUSS in den statistischen Daten des Konfigurationsdienstes, die pro Produkt im Downloadbereich angefragten Updates (Operation I_KSRS_Download::listUpdates inklusive aller Parameter des Requests) und bereitgestellten Updates (Operation I_KSRS_Download::getUpdates inklusive UpdateID und Filename) inklusive aller Anfragen bei KSR Download Cache Servern, aufgeschlüsselt nach Produkt und Update-Paket (Element „UpdateID“) im zeitlichen Verlauf entsprechend Tab_KSR_046-01 auflisten.

Tabelle 27: Tab_KSR_046-01 Statistikdatenformat

Position	Feld	Beschreibung	Typ
1	Timestamp	Zeitpunkt, zu dem der Download gestartet wurde.	String, Timestamp-Format „YYYY-MM-DD HH:mm:SS,SSS”, Beispiel: „2014-01-08 09:46:18,780“. Die Zeitzone ist UTC
2	ProductVendorID	Identifiziert den Hersteller des Produkts. [gemSpec_OM] beschreibt dieses Element unter der Bezeichnung „Hersteller-/Anbieter-ID“ ausführlich.	String, max. 5 Zeichen Wenn „listUpdates“ aufgerufen wurde, enthält dieses Feld den entsprechenden Parameter des Requests, beim Aufruf von „getUpdates“ die ProductVendorID der gesendeten Datei.
3	ProductCode	Identifiziert das Produkt zusammen mit der ProductVendorID. [gemSpec_OM] beschreibt dieses Element unter der Bezeichnung „Produktkürzel“ ausführlich.	String, max. 8 Zeichen Wenn „listUpdates“ aufgerufen wurde, enthält dieses Feld den entsprechenden Parameter des Requests, beim Aufruf von „getUpdates“ den ProductCode der gesendeten Datei.
4	HWVersion	Identifiziert zusammen mit ProductCode und ProductVendorID die Hardware. [gemSpec_OM] beschreibt dieses Element ausführlich.	String „[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}“) Wenn „listUpdates“ aufgerufen wurde, enthält dieses Feld den entsprechenden Parameter des Requests, beim Aufruf von „getUpdates“ die Hardware-Version der gesendeten Datei.
5	FWVersion	Firmware Version des heruntergeladenen Updates. [gemSpec_OM] beschreibt dieses Element ausführlich.	String „[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}“) Wenn „listUpdates“ aufgerufen wurde, enthält dieses Feld den entsprechenden Parameter des Requests, beim Aufruf von „getUpdates“ die Firmware-Version der gesendeten Datei.
6	Action	Ausgeführte Aktion	String, “listUpdates” für einen Aufruf der Operation “listUpdates”. “getUpdates“, wenn die Operation „getUpdates“ aufgerufen wurde.
7	UpdateID	Eindeutige Bezeichnung des Updates.	String, wenn „listUpdates“ aufgerufen wurde, ist dieses Feld leer, ansonsten enthält es die UpdateID des Paketes.
8	Filename	Dateiname des heruntergeladenen Paketes.	String, wenn „listUpdates“ aufgerufen wurde, ist dieses Feld leer, ansonsten enthält es den Filename der aufgerufenen Datei ohne den Pfad.
9	SZZP-ID	SZZP-ID über den die Anfrage kam. Dient der Ermittlung des betroffenen VPN-Anbieters.	String, max. 5 Zeichen

[<=]

TIP1-A_3354 - KSR-Statistiken – Format

Der Anbieter des Konfigurationsdienstes MUSS alle Download-Berichte und Berichte über die listUpdates Abfragen im CSV-Format bereitstellen. Die CSV-Datei MUSS im durch TIP1-A_3353 definierten Format vorliegen.

[<=]

A_17453 - KSR-Statistiken – Bereitstellung

Der Konfigurationsdienst MUSS täglich zu einem konfigurierbaren Zeitpunkt KSR-Statistiken im CSV-Format an die Schnittstelle I_OpsData_Update [gemSpec_SST_LD_BD] liefern. Dazu MUSS die Schnittstelle I_OpsData_Update::fileUpload benutzt werden.
Die Statistik-Daten MÜSSEN für jeden vollständigen Berichtszeitraum in einer Datei mit folgenden Namenskonventionen gesendet werden:

KSR_Statistik_<Start>_<Ende>.csv

• <Start> = Startzeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (immer volle Minuten, erster Zeitraum des Tages beginnt um 00:00 Uhr UTC)
  
• <Ende> = Endezeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (offenes Intervallende, d.h. erster Zeitpunkt, der gerade nicht mehr zum Intervall gehört, immer volle Minuten)
  

Der Konfigurationsdienst MUSS in jedem Sendevorgang alle seit dem letzten Senden angefallenen Dateien senden.

[<=]

A_18383 - KSR, Lokalisierung von Firmware

Der Konfigurationsdienst MUSS eine tagesaktuelle Log-Datei bereitstellen, die für alle Aufrufe der Operation-I_KSRS_Download::listUpdates die Parameter entsprechend Tab_KSR_051 enthält.

Tabelle 28: Tab_KSR_051 Lokalisierungsdaten

Position	Feld	Beschreibung	Typ
1	Timestamp	Zeitpunkt, zu dem die Operation aufgerufen wurde.	String, Timestamp-Format „YYYY-MM-DD HH:mm:SS,SSS”, Beispiel: „2014-01-08 09:46:18,780“. Die Zeitzone ist UTC
2	ProductVendorID	Identifiziert den Hersteller des Produkts. [gemSpec_OM] beschreibt dieses Element unter der Bezeichnung „Hersteller-/Anbieter-ID“ ausführlich.	String, max. 5 Zeichen Wenn „listUpdates“ aufgerufen wurde, enthält dieses Feld den entsprechenden Parameter des Requests, beim Aufruf von „getUpdates“ die ProductVendorID der gesendeten Datei.
3	ProductCode	Identifiziert das Produkt zusammen mit der ProductVendorID. [gemSpec_OM] beschreibt dieses Element unter der Bezeichnung „Produktkürzel“ ausführlich.	String, max. 8 Zeichen Wenn „listUpdates“ aufgerufen wurde, enthält dieses Feld den entsprechenden Parameter des Requests, beim Aufruf von „getUpdates“ den ProductCode der gesendeten Datei.
4	HWVersion	Identifiziert zusammen mit ProductCode und ProductVendorID die Hardware. [gemSpec_OM] beschreibt dieses Element ausführlich.	String „[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}“) Wenn „listUpdates“ aufgerufen wurde, enthält dieses Feld den entsprechenden Parameter des Requests, beim Aufruf von „getUpdates“ die Hardware-Version der gesendeten Datei.
5	FWVersion	Firmware-Version des heruntergeladenen Updates. [gemSpec_OM] beschreibt dieses Element ausführlich.	String „[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}“) Wenn „listUpdates“ aufgerufen wurde, enthält dieses Feld den entsprechenden Parameter des Requests, beim Aufruf von „getUpdates“ die Firmware-Version der gesendeten Datei.
6	Client Adresse	IP Adresse des Clients.	String. Darstellung entsprechend RFC791.

[<=]

A_18384 - KSR, Lokalisierungsdaten – Format

Der Konfigurationsdienst MUSS die Lokalisierungsdaten im CSV-Format bereitstellen. Die CSV-Datei MUSS im durch TIP1-A_6102 definierten Format und entsprechend A_18383 vorliegen.
[<=]

A_18385-01 - KSR, Lokalisierungsdaten – Bereitstellung

Der Konfigurationsdienst MUSS die tagesaktuellen KSR-Lokalisierungsdaten im CSV-Formatt über eine organisatorische Schnittstelle bereitstellen.
[<=]

A_18386 - KSR, Lokalisierungsdaten – Löschen

Der Konfigurationsdienst MUSS KSR-Lokalisierungsdaten automatisch nach einer konfigurierbaren Anzahl von Tagen löschen.
[<=]

A_18495 - KSR, Lokalisierungsdaten – Abruf nur durch dedizierten VPN-Zugangsdienst

Der Anbieter des Konfigurationsdienstes MUSS sicherstellen, dass die tagesaktuellen KSR-Lokalisierungsdaten nur dem jeweiligen netzsegment-entsprechenden VPN-Zugangsdienst über einen Service-Abruf, der vorher von der gematik zu genehmigen ist, bereitgestellt werden.
[<=]

TIP1-A_5040 - Schlüssel sicher speichern

Der Konfigurationsdienst MUSS Schlüssel sicher speichern und ihr Auslesen verhindern.

[<=]

TIP1-A_3909 - Bereitstellung I_KSRS_Download

Der Konfigurationsdienst MUSS für Clients den Dienst I_KSRS_Download entsprechend der Tabelle Tab_KSR_025 bereitstellen.

Tabelle 29: Tab_KSR_025 Konfigurationsdienst

Name	I_KSRS_Download
Version (KDV)	gemäß Produkttypversion
Namensraum	http://ws.gematik.de/ksr/v1.1
Namensraum-Kürzel	KSR
Operationen	Name	Kurzbeschreibung
	listUpdates	Auflisten verfügbarer Updates
WSDL	Konfigurationsdienst.wsdl
Schema	Konfigurationsdienst.xsd

[<=]

TIP1-A_6103 - SOAP-Version

Der Konfigurationsdienst und der Konnektor (KSR-Client) MÜSSEN ausschließlich „SOAP über http“, Version 1.1 für ihre Kommunikation verwenden.
[<=]

TIP1-A_3330 - I_KSRS_Download::listUpdates

Der Konfigurationsdienst MUSS die logische Operation listUpdates entsprechend der Tabelle Tab_KSR_026 implementieren.

Tabelle 30: Tab_KSR_026 Operation I_KSRS_Download::listUpdates

Element	Beschreibung
Name	I_KSRS_Download::listUpdates
Beschreibung	Die Operation listet die auf dem Konfigurationsdienst verfügbaren Update-Pakete für eine dezentrale Komponente der TI-Plattform auf.
Initiierender Akteur	Konnektor
Weitere Akteure	Keine
Auslöser	Konnektor
Berechtigungen	Konnektor
Vorbedingungen	Aufgebaute TLS-Verbindung vom Konnektor zum Konfigurationsdienst entsprechend Kapitel 5.5.1.
Nachbedingungen	Konfigurationsdienst hat Log-Daten der Abfrage gespeichert und KSR-Client hat UpdateInfos vorliegen sowie gespeichert.
Aufruf	Der Aufrufer (Konnektor) ruft über die hier definierte Schnittstelle den Konfigurationsdienst mit den in Kapitel 6.1.1.1.1 definierten Parametern auf. Aufruf der Operation listUpdates mit der URL https://<host>:<port><path> (<host>:<port> wird durch Abfrage des DNS SRV Resource Record „_ksrfirmware._tcp.ksr.telematik“ ermittelt. <path> wird durch Abfrage des DNS TXT Resource Record „_ksrfirmware._tcp.ksr.telematik“ ermittelt.)
Antwort	Die Liste der auf dem Konfigurationsdienst verfügbaren Update-Pakete für die dezentrale Komponente entsprechend Beschreibung in Kapitel 6.1.1.1.2.
Standardablauf	Der Konfigurationsdienst MUSS die Liste der verfügbaren Updates für die dezentrale Komponente der TI-Plattform zusammenstellen. Diese Liste entspricht dem Element Firmware-Version der „aktiven“ Firmware-Gruppe (siehe Kapitel 5.3) für die Komponente. Der Konfigurationsdienst MUSS im Response die Liste der verfügbaren Updates (Parameter UpdateInformation) sowie die FirmwareGroupReleaseNotes (entspricht Element FirmwareGroupReleaseNotes der „aktiven“ Firmware-Gruppe) an den Client senden. Der Konfigurationsdienst MUSS – entsprechend Festlegungen in Kapitel 5.6 – Log-Daten von dieser Operation speichern.
Fehlerfälle	Tritt während der Verarbeitung ein Fehler auf, so MUSS der Konfigurationsdienst die Webservice-Anfrage mit einem SOAP-Fault entsprechend [gemSpec_OM] beantworteten. Die Fehlercodes sind entsprechend Tabelle Tab_Gen_Fehler aus [gemSpec_OM] zu nutzen.

[<=]

TIP1-A_3331 - I_KSRS_Download::listUpdates Request

Für den Konfigurationsdienst MUSS die Operation I_KSRS_Download::listUpdates Request mit folgenden Parametern bereitstellen:

Abbildung 12: Abb_KSR_008 Operation I_KSRS_Download::listUpdates Request

Tabelle 31: Tab_KSR_027 I_KSRS_Download::listUpdates Request

Bezeichnung	I_KSRS_Download::listUpdates Request
Beschreibung	Operations-Element des Request der Operation I_KSRS_Download::listUpdates

Tabelle 32: Tab_KSR_028 Hersteller-Update-Informationen – Element ProductVendorID

Bezeichnung	ProductVendorID
Beschreibung	Identifiziert den Hersteller des Produkts, für welches auf Updates geprüft werden soll.
Optional	Nein
Wertebereich	Entspricht dem Wertebereich vom XML-Datentyp „string““ mit Pattern „[a-zA-Z0-9_]*“. Maximale Länge 5 Zeichen.

Tabelle 33: Tab_KSR_029 Hersteller-Update-Informationen – Element ProductCode

Bezeichnung	ProductCode
Beschreibung	Identifiziert das Produkt zusammen mit dem ProductVendorID, für welches auf Updates geprüft werden soll.
Optional	Nein
Wertebereich	Entspricht dem Wertebereich vom XML-Datentyp „string““ mit Pattern „[a-zA-Z0-9_]*“. Maximale Länge 8 Zeichen.

Tabelle 34: Tab_KSR_030 Hersteller-Update-Informationen – Element HWVersion

Bezeichnung	HWVersion
Beschreibung	Identifiziert die Hardware zusammen mit ProductCode und ProductVendorID, für welches auf Updates geprüft werden soll. [gemSpec_OM] beschreibt dieses Element ausführlich.
Optional	Nein
Wertebereich	Entspricht dem Wertebereich vom XML Datentyp „string“ mit Pattern „[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}“.

Tabelle 35: Tab_KSR_031 Hersteller-Update-Informationen – Element FWVersion

Bezeichnung	FWVersion
Beschreibung	Die FirmwareVersion des Produkts, für welches auf Updates geprüft werden soll.
Optional	Nein
Wertebereich	Entspricht dem Wertebereich vom XML-Datentyp „string“ mit Pattern „[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}“.

[<=]

TIP1-A_3332 - I_KSRS_Download::listUpdates Response

Der Konfigurationsdienst MUSS die Operation I_KSRS_Download::listUpdates Response mit folgenden Parametern (siehe Abb_KSR_009, Tab_KSR_032, Tab_KSR_033, Tab_KSR_034) bereitstellen:

Abbildung 13: Abb_KSR_009 Operation I_KSRS_Download::listUpdates Response

Tabelle 36: Tab_KSR_032 I_KSRS_Download::listUpdates – Response

Bezeichnung	I_KSRS_Download::listUpdates Response
Beschreibung	Operations-Element des Response der Operation I_KSRS_Download::listUpdates

Tabelle 37: Tab_KSR_033 I_KSRS_Download::listUpdates – Element FirmwareGroupReleaseNotes

Bezeichnung	FirmwareGroupReleaseNotes
Beschreibung	Dieses Element enthält die Release Notes der Firmware-Gruppen-Information. Es beschreibt die Update-Pakete bzw. Firmware der Firmware-Gruppe.
Optional	Ja (falls keine Update-Pakete auf dem Konfigurationsdienst vorhanden sind)

Tabelle 38: Tab_KSR_034 I_KSRS_Download::listUpdates – Element UpdateInformation

Bezeichnung	UpdateInformation
Beschreibung	Dieses Element liefert eine Liste mit bis zu 999 verfügbaren Updates für den im Request spezifizierten Client. Jedes Element der Liste beschreibt ein Update mit allen Elementen der Hersteller-Update-Informationen (siehe Kapitel 5.2).
Optional	Ja (falls keine Update-Pakete auf dem Konfigurationsdienst vorhanden sind)

[<=]

TIP1-A_3333 - Konfigurationsdienst SOAP-Fehlercodes

Der Konfigurationsdienst MUSS für seine SOAP-Schnittstelle die generischen Fehlercodes

• Code 2: Verbindung zurückgewiesen

• Code 3: Nachrichtenschema fehlerhaft

• Code 4: Version Nachrichtenschema fehlerhaft

• Code 6: Protokollfehler

aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM] im SOAP-Fault verwenden. Erkannte Fehler auf Transportprotokollebene müssen auf gematik SOAP Faults (Code 6 aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM]) abgebildet werden.

[<=]

TIP1-A_3334 - I_KSRS_Download::getUpdates

Der Konfigurationsdienst MUSS die Operation I_KSRS_Download::getUpdates für die Übertragung von Aktualisierungspaketen an dezentrale Komponente der TI-Plattform durch den Konfigurationsdienst entsprechend Tabelle Tab_KSR_035 bereitstellen.

Tabelle 40: Tab_KSR_035 Operation I_KSRS_Download::getUpdates

Element	Beschreibung
Name	I_KSRS_Download::getUpdates
Beschreibung	Mit dieser Operation ruft der Konnektor verfügbare Updates für eine dezentrale Komponente der TI-Plattform vom Konfigurationsdienst ab. Die Auswahl der Files zum Download erfolgt auf Grundlage der zurückgegebenen Werte in Operation listUpdates Response. Die optionale detached Signatur „UpdateInfo.sig“ kann ebenfalls mit dieser Operation übertragen werden. Mit jedem Aufruf dieser Operation wird ein File übertragen.
Initiierender Akteur	Konnektor
Weitere Akteure	keine
Auslöser	Konnektor
Vorbedingungen	Aufgebaute TLS-Verbindung vom Konnektor zum Konfigurationsdienst entsprechend Kapitel 5.5.1.
Nachbedingungen	Konfigurationsdienst hat Log-Daten gespeichert und der Konnektor hat die Update-Datei vorliegen und gespeichert.
Aufruf	Aufruf von TUC_KSR_001 „Get File“ mit der URL    https://<host>:<port><path>/<filename> (<host>:<port> wird durch Abfrage des DNS SRV Resource Record „_ksrfirmware._tcp.ksr.telematik“ ermittelt. <path> wird durch Abfrage des DNS TXT Resource Record „_ksrfirmware._tcp.ksr.telematik“ ermittelt. <filename> entspricht dem Filename der Firmwaredatei inklusive absoluten Pfad (siehe z.B. Tab_KSR_015).)
Standardablauf	Der KSR sendet die angeforderte Datei an den aufrufenden Konnektor.
Fehlerfälle	Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten.

[<=]

TIP1-A_5160 - I_KSRS_Download::get_Ext_Net_Config

Der Konfigurationsdienst MUSS die Operation I_KSRS_Download::get_Ext_Net_Config für die Übertragung von Konfigurationsdatenfiles an dezentrale Komponenten der TI-Plattform durch den Konfigurationsdienst entsprechend Tabelle Tab_KSR_044 bereitstellen.

Tabelle 41: Tab_KSR_044 Operation I_KSRS_Download::get_Ext_Net_Config

Element	Beschreibung
Name	I_KSRS_Download::get_Ext_Net_Config
Beschreibung	Mit dieser Operation ruft der Konnektor verfügbare Konfigurationsdatenfiles vom Konfigurationsdienst ab. Die Auswahl der Konfigurationsdatenfiles zum Download erfolgt auf Grundlage ihrer fest vorgegebenen Filenamen. Mit jedem Aufruf dieser Operation wird ein File übertragen.
Initiierender Akteur	Konnektor
Weitere Akteure	keine
Auslöser	Konnektor
Vorbedingungen	Aufgebaute TLS-Verbindung vom Konnektor zum Konfigurationsdienst entsprechend Kapitel 5.5.1.
Nachbedingungen	Konfigurationsdienst hat Log-Daten gespeichert und der Konnektor hat das Konfigurationsdatenfile vorliegen und gespeichert.
Aufruf	Aufruf von TUC_KSR_001 „Get File“ mit der URL    https://<host>:<port><path>/<filename> (<host> und <port> werden durch Abfrage des DNS SRV Resource Record „_ksrkonfig._tcp.ksr.telematik“ ermittelt. <path> wird durch Abfrage des DNS TXT Resource Record „_ksrkonfig._tcp.ksr.telematik“ ermittelt und enthält den Pfad des Konfigurationsdatenfiles.)
Standardablauf	Der KSR sendet das angeforderte Konfigurationsdatenfile an den aufrufenden Konnektor.
Fehlerfälle	Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten.

[<=]

TIP1-A_5375 - Filename des Konfigurationsdatenfiles zur Anbindung von Bestandsnetzen

Der Konfigurationsdienst MUSS das Konfigurationsdatenfile zur Anbindung von Bestandsnetzen unter dem Filenamen „Bestandsnetze.xml“ zum Download bereitstellen.

[<=]

TIP1-A_5161 - TUC_KSR_001 „Get File“

Der Konfigurationsdienst MUSS den technischen Use Case für die Übertragung von Files an dezentrale Komponente der TI-Plattform durch den Konfigurationsdienst entsprechend Tabelle Tab_KSR_043 TUC_KSR_001 „Get File“ bereitstellen.

Tabelle 42: Tab_KSR_043 TUC_KSR_001 „Get File“

Element	Beschreibung
Name	TUC_KSR_001 „Get File“
Beschreibung	Dieser technische Use Case wird von den Operationen zum Abruf von Files durch den Konnektor vom Konfigurationsdienst genutzt. Mit jedem Aufruf dieser Operation wird ein File übertragen.
Initiierender Akteur	Konnektor (bzw. I_KSRS_Download::getUpdates, I_KSRS_Download::get_Ext_Net_Config)
Weitere Akteure	keine
Auslöser	Konnektor (bzw. I_KSRS_Download::getUpdates, I_KSRS_Download::get_Ext_Net_Config)
Vorbedingungen	Aufgebaute TLS-Verbindung vom Konnektor zum Konfigurationsdienst entsprechend Kapitel 5.5.1.
Eingangsdaten	filename (Filename welches vom KSR geladen werden soll)
Nachbedingungen	Konfigurationsdienst hat Log-Daten gespeichert und der Konnektor hat die Update-Datei vorliegen und gespeichert.
Aufruf	http GET entsprechend TIP1-A_3335.
Standardablauf	Der Konfigurationsdienst MUSS dem Client das angegebene File mit dem Bezeichner filename entsprechend http 1.1 [RFC2616] übertragen. Der Konfigurationsdienst MUSS Log-Daten von dieser Operation speichern (siehe Kapitel 5.6).
Fehlerfälle	Tritt während der Verarbeitung ein Fehler auf, so MUSS der Konfigurationsdienst im http-Response einen entsprechenden http Status Code senden (siehe TIP1-A_4120).

[<=]

TIP1-A_3335 - Konfigurationsdienst File Transfer HTTP Request

Der Konfigurationsdienst MUSS den Download eines Files mit einem http GET unterstützen. Dafür MUSS ein http URL-Schema entsprechend [RFC1738] sowie Tabellen Tab_KSR_036 und Tab_KSR_037 unterstützt werden:

https://<host>/<path>

Tabelle 43: Tab_KSR_036 File Transfer HTTP Request – Element host

Bezeichnung	host
Beschreibung	Der FQDN (fully qualified domain name) des Konfigurationsdienstes und optional eine Portnummer.
Optional	nein
Wertebereich	Entspricht dem Wertebereich vom Datentyp „string“.

Tabelle 44: Tab_KSR_037 File Transfer HTTP Request – Element path

Bezeichnung	path
Beschreibung	Absoluter Pfad (siehe z.B. Tab_KSR_015, Tab_KSR_017.
Optional	nein
Wertebereich	Entspricht dem Wertebereich vom Datentyp „string“.

[<=]

TIP1-A_3336 - File Transfer HTTP Response

Der Konfigurationsdienst MUSS in das http-Response die notwendigen http-Header-Datenfelder gemäß [RFC2616] aufnehmen. Im http-Body MUSS der Konfigurationsdienst das angeforderte File zurückgeben.

[<=]

TIP1-A_4120 - File Transfer HTTP Status Codes

Der Konfigurationsdienst MUSS die http Status Codes entsprechend [RFC2616] unterstützen.

[<=]

TIP1-A_5162 - http Status Code „Retry After“

Wenn der Konfigurationsdienst den getUpdates Request wegen temporärer Überlast oder Maintenance nicht verarbeiten kann, MUSS er den http Status Code 503 Server Unavailable an den Client zurückgeben. Falls dem Konfigurationsdienst der Zeitraum der Nichtverfügbarkeit bekannt ist, SOLL er den Retry-After Header zur Information des Clients nutzen. Der Retry-After Header MUSS ebenfalls bei Überlast zur zeitlichen Lastverteilung genutzt werden. [<=]

TIP1-A_3910 - Konfigurationsdienst File Transfer http Komprimierung

Der Konfigurationsdienst MUSS die Komprimierung des File Transfers über http unterstützen. Dazu muss er das „Content Coding“ [RFC2616] „gzip“ implementieren.

[<=]

TIP1-A_7221 - Konfigurationsdienst File Transfer Range Requests

Der Konfigurationsdienst MUSS für den File Transfers über http die Option Range Requests [RFC7233#3.1] zur Fortsetzung von unterbrochenen Transfers unterstützen. [<=]

TIP1-A_6104 - KSR Download Cache Server

Der Konfigurationsdienst MUSS für jeden SZZP der VPN-Zugangsdienste einen KSR Download Cache Server vorsehen. Jeder einzelne dieser KSR Download Cache Server MUSS dabei autark laufen und sich eigenständig synchronisieren. Für die zentralen Komponenten des Konfigurationsdienstes MUSS das Vorhandensein und die Anzahl von KSR Download Cache Servern transparent sein.

Die KSR Download Cache Server MÜSSEN folgende Eigenschaften haben:

• Jede Instanz MUSS separat in den Umgebungen deploybar sein.

• Jede Instanz MUSS eine eigene lokale Datenhaltung besitzen.

• Jede Instanz MUSS die Anfragen dezentraler Komponenten ohne die Kommunikation mit anderen Instanzen beantworten können.

[<=]

TIP1-A_6105 - KSR Download Cache Server Transparenz

Der Konfigurationsdienst MUSS für die dezentralen Komponenten die Transparenz der KSR Cache Server sicherstellen. Mit den KSR Download Cache Servern MUSS die gleiche Schnittstelle I_KSRS_Download bereitgestellt werden wie sie der KSR selbst unterstützt. Der Konfigurationsdienst MUSS sicherstellen, dass Hinzufügen, Entfernen und Ausfall (Redundanzfall) eines KSR Download Cache Servers keinerlei Anpassungen in dezentralen Komponenten erfordert.

[<=]

TIP1-A_6106 - KSR Download Cache Server Redundanz

Der Konfigurationsdienst MUSS für die KSR Download Cache Server eine redundante Lösung vorsehen. Der Konfigurationsdienst MUSS sicherstellen, dass Aktivieren und Deaktivieren der Redundanzlösung keinerlei Anpassungen in dezentralen Komponenten erfordert.

[<=]

TIP1-A_6125 - KSR Störungsampel Monitoringdaten

Der Konfigurationsdienst MUSS für alle seine Komponenten inklusive der KSR Download Cache Server Monitoringdaten an die Störungsampel senden [gemSpec_St_Ampel] (Schnittstelle I_Monitoring_Update).

[<=]

TIP1-A_6109 - KSR Nutzung des zentralen Netzes während Redundanz

Der Konfigurationsdienst KANN während des Ausfalls eines KSR Download Cache Servers für die Übertragung der Update-Pakete zu den dezentralen Komponenten das zentrale Netz verwenden.

[<=]

TIP1-A_6107 - Bereitstellung Registrierungsinterface

Der Anbieter des Konfigurationsdienstes MUSS berechtigten Akteuren die Registrierung für die Nutzung der organisatorischen KSR-Schnittstellen ermöglichen und ihnen die nötigen Zugangsdaten bereitstellen.
[<=]

TIP1-A_6110 - Authentisierung und Autorisierung

Der Konfigurationsdienst MUSS Akteure der organisatorischen KSR-Schnittstellen authentisieren und autorisieren.

[<=]

TIP1-A_6111 - Gruppen und Berechtigungen

Der Konfigurationsdienst MUSS den Akteuren der organisatorischen KSR-Schnittstellen jeweils Rollen gemäß ihrer Gruppenzugehörigkeit und Umgebung entsprechend Tab_KSR_011 zuweisen.

Tabelle 45: Tab_KSR_011 Gruppen und Berechtigungen

Rolle/Gruppe	Berechtigung
Hersteller_RU	Die Rolle kann sich an der Web-Applikation des Upload-Bereichs in RU anmelden, Pakete hochladen, den Status einsehen und Statistikdaten herunterladen.
Hersteller_RU_RO	Die Rolle kann sich an der Web-Applikation des Upload-Bereichs in RU anmelden, den Status einsehen und Statistikdaten herunterladen. Es sind keine Änderungen von Daten im Konfigurationsdienst erlaubt.
Hersteller_TU	Die Rolle kann sich an der Web-Applikation des Upload-Bereichs in TU anmelden, Pakete hochladen, den Status einsehen und Statistikdaten herunterladen.
Hersteller_TU_RO	Die Rolle kann sich an der Web-Applikation des Upload-Bereichs in TU anmelden, den Status einsehen und Statistikdaten herunterladen. Es sind keine Änderungen von Daten im Konfigurationsdienst erlaubt.
Hersteller_RU_Konfig	Die Rolle kann sich an der Web-Applikation des Konfigurationsbereichs in RU anmelden, die Auftragsliste einsehen, Pakete ablehnen, freigeben oder deaktivieren, Statistikdaten herunterladen. Akteure mit dieser Rolle dürfen nur auf eigene Pakete (Pakete mit dem ProductVendorID des Akteurs) und Daten über eigene Pakete zugreifen.
Hersteller_TU_Konfig	Die Rolle kann sich an der Web-Applikation des Konfigurationsbereichs in TU anmelden, die Auftragsliste einsehen, Pakete ablehnen, freigeben oder deaktivieren, Statistikdaten herunterladen. Akteure mit dieser Rolle dürfen nur auf eigene Pakete (Pakete mit dem ProductVendorID des Akteurs) und Daten über eigene Pakete zugreifen.
Hersteller_PU	Die Rolle kann sich an der Web-Applikation des Upload-Bereichs in PU anmelden, Pakete hochladen, den Status einsehen und Statistikdaten herunterladen. Diese Rolle erlaubt in der PU nicht die Funktionalitäten Pakete ablehnen, freigeben oder deaktivieren.
Hersteller_PU_RO	Die Rolle kann sich an der Web-Applikation des Upload-Bereichs in PU anmelden, den Status einsehen und Statistikdaten herunterladen. Es sind keine Änderungen von Daten im Konfigurationsdienst erlaubt.
TBI_RU	Die Rolle kann sich an der Web-Applikation des Konfigurationsbereichs in RU anmelden, die Auftragsliste einsehen, Pakete ablehnen, freigeben oder deaktivieren, Statistik- und Logdaten herunterladen sowie Konfigurationsdatenfiles für RU hochladen, freigeben oder ablehnen.
TBI_TU	Die Rolle kann sich an der Web-Applikation des Konfigurationsbereichs in TU anmelden, die Auftragsliste einsehen, Pakete ablehnen, freigeben oder deaktivieren, Statistik- und Logdaten herunterladen sowie Konfigurationsdatenfiles für TU hochladen, freigeben oder ablehnen.
GTI_PU	Die Rolle kann sich an der Web-Applikation des Konfigurationsbereichs in PU anmelden, die Auftragsliste einsehen, Pakete ablehnen, freigeben oder deaktivieren, Statistik- und Logdaten herunterladen sowie Konfigurationsdatenfiles für PU hochladen, freigeben oder ablehnen.

[<=]

TIP1-A_3342 - Bereitstellung P_KSRS_Upload

Der Anbieter des Konfigurationsdienstes MUSS berechtigten Herstellern dezentraler Komponenten der TI, dem Gesamtverantwortlichen TI  (PU) und der Testbetriebsinstanz TU/RU eine Möglichkeit zum Übermitteln von Update-Paketen und zugehörigen Firmware-Gruppen-Informationen entsprechend Tabelle Tab_KSR_039 zur Verfügung stellen (P_KSRS_Upload).

Tabelle 47: Tab_KSR_039 P_KSRS_Upload Schema

Name	P_KSRS_Upload
Version (KDV)	gemäß Produkttypversion
Namensraum	http://ws.gematik.de/ksr/v1.1
Namensraum-Kürzel	KSR
Informationsobjekte	Name	Kurzbeschreibung
	UpdateInformation	Metainformationen zum Update-Paket
	FirmwareGroupInformation	Liste der aktuell freigegebenen Firmware-Versionen eines Produkts.
Schema	Konfigurationsdienst.xsd

[<=]

TIP1-A_3343 - Berechtigung P_KSRS_Upload

Der Anbieter des Konfigurationsdienstes MUSS sicherstellen, dass nur berechtigte Akteure (berechtigte Hersteller von Komponenten, die den KSR nutzen, Gesamtverantwortlicher TI (PU), Testbetriebsinstanz TU und Testbetriebsinstanz  (RU) auf P_KSRS_Upload der jeweiligen Umgebung zugreifen können.
[<=]

TIP1-A_3348 - Form und Inhalt Upload-Interface

Der Anbieter des Konfigurationsdienstes MUSS die Form  des Upload-Interfaces  definieren und mit den berechtigten Akteuren abstimmen.

[<=]

TIP1-A_5042 - P_KSRS_Upload parallel nutzbar

Der Konfigurationsdienst SOLL die Kommunikationsschnittstelle von KSR-Upload so implementieren, dass sie parallel durch mehrere Aufrufer nutzbar ist.

[<=]

TIP1-A_3345 - KSR Logging – Upload-Interface

Der Konfigurationsdienst MUSS mindestens für folgende Vorgänge Logging-Daten erfassen:

• Upload von Update-Paketen und Firmware-Gruppen-Informationen

• Ergebnis der Eingangsprüfung

Ein Log-Eintrag MUSS mindestens folgende Informationen erfassen:

• Wer hat etwas getan

• Was wurde getan

• Zeitpunkt

• Updatepaket.UpdateInformation.UpdateID bzw. FirmwareGroupInformation.FirmwareGroupID

[<=]

TIP1-A_6065 - KSR Fortschrittsinformation im Interface P_KSRS_Upload

Der Konfigurationsdienst MUSS während des Übermittelns von Update-Paketen den Nutzer über den Fortschritt des Filetransfers informieren.

[<=]

A_14540 - P_KSRS_Upload & P_KSRS_Operations, Optionen zur Anzeige von Listen

Der Anbieter des Konfigurationsdienstes MUSS in den Schnittstellen P_KSRS_Upload und P_KSRS_Operations Nutzern folgende Optionen bei der Anzeige von Update-Paketen – zur Erleichterung der Arbeit mit langen Listen – bereitstellen:

• Die Listen müssen – entsprechend der vom Nutzer gewählten Spalte – auf und absteigend sortierbar sein.
• Die Listen müssen – entsprechend der vom Nutzer gewählten Spalte – nach einem Zeitpunkt (mindestens Tag bzw. Monat in Spalte Timestamp) und Strings in den restlichen Anzeigespalten - filterbar  sein.
• Die Listen müssen maximierbar (Ausnutzung eines großen Bereichs des Fensters für die Liste der Update-Pakete) sein.

[<=]

A_15171 - P_KSRS_Upload & P_KSRS_Operations, Gesicherter Zugang

Der Anbieter des Konfigurationsdienstes MUSS in den Schnittstellen P_KSRS_Upload und P_KSRS_Operations den Zugriff der Anwender auf diese Schnittstellen ausschließlich über eine  TLS-Verbindung mit serverseitiger Authentifizierung ermöglichen. [<=]

TIP1-A_3346 - Eingangsprüfung

Der Konfigurationsdienst MUSS die übermittelten Update-Pakete und Firmware-Gruppen-Informationen einer Eingangsprüfung unterziehen.
Die Eingangsprüfung MUSS folgende Prüfungen enthalten:

• Prüfung der Integrität und Authentizität
  
• Die Signatur des Update-Paketes muss beim Übergang zwischen Upload-Bereich und Konfigurationsbereich geprüft werden. Die Prüfung muss mindestens die folgende Schritte umfassen:
  
• Prüfung der Gültigkeit des Zertifikats über den zuständigen OCSP-Responder,
  
• Prüfung der Zertifikatstyp-OID auf Zulässigkeit,
  
• Prüfung der mathematischen Korrektheit des Zertifikats.
  
• Die Integrität des ZIP-Containers
  
• Der Konfigurationsdienst MUSS – im Sinne Integrität und Authentizität - fehlerhafte Update-Pakete ohne weitere Prüfung ihrer Inhalte  ablehnen.
  
• Prüfung auf syntaktische Korrektheit (Update-Informationen und Firmware-Gruppen-Informationen)
  
• Sofern die Datei UpdateInfo.xml im Container enthalten ist, wird die XML-Struktur validiert. Die in dem Element „Files“ angegebenen Dateien müssen im Container enthalten sein, die Pfadangaben müssen dem in Anforderung „TIP1-A_6122 Pfadreferenz“ definiertem Format entsprechen. Alle Pflichtfelder müssen mit korrekten Werten belegt sein, die angegebene ProductVendorID muss mit der ID des übertragenden Herstellers identisch sein, außer es handelt sich um ein Update-Paket, das durch den TBI/GTI eingestellt wurde.
  
• Die Datei „FirmwareGroupInfo.xml“ wird mit dem XSD-Schema validiert und sichergestellt, dass die Version aktueller ist, als die bereits vorhandene.
  
• Prüfung auf Vollständigkeit (Vorhandensein aller aus den Update-Informationen referenzierten Files)
  
• Das Update-Paket wird geöffnet und festgestellt, dass alle notwendigen Dateien im ZIP-Container enthalten sind. (FirmwareGroupInfo.xml, optional UpdateInfo.xml)
  
• Es dürfen nicht mehr Dateien im Container enthalten sein, als die in 6.2.3.1 definierten Elemente. Die Firmware- und Dokumentationsdateien müssen alle durch UpdateInfo.xml referenziert werden. Update-Pakete mit Dateien ohne Referenz werden abgelehnt. Die optionalen detached Signaturen „UpdateInfo.sig“ und „FirmwareGroupInfo.sig“ können – ohne Referenz - im Update-Paket enthalten sein.
  
• Prüfung ob der eingeloggte Nutzer die Berechtigung hat das Update-Paket zu übermitteln. Der Nutzer muss zu der Organisation gehören welche das Update-Paket signiert hat oder die TBI bzw. GTI Rolle für die jeweilige Umgebung besitzen.
  

[<=]

TIP1-A_6112 - Name des Update-Paketes

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN den Dateinamen so wählen, das er dem Pattern „[A-Za-z0-9_-.]*“ entspricht und nicht länger als 32 Zeichen ist und der Konfigurationsdienst MUSS die Einhaltung dieser Definition prüfen.

[<=]

TIP1-A_6113 - Definition Update-Paket-Struktur

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN Update-Pakete mit den in Tab_KSR_010 (Struktur Update-Paket) definierten Elementen in Form eines ZIP-Containers nach dem Standard [ZIP-APP] erzeugen und der Konfigurationsdienst MUSS die Einhaltung dieser Definition prüfen.

[<=]

TIP1-A_6114 - Passwort des Update-Paketes

Hersteller von Komponenten, die den KSR nutzen, DÜRFEN NICHT den ZIP-Container mit einem Passwort schützen und der Konfigurationsdienst DARF NICHT passwortgeschützte ZIP-Container akzeptieren.

[<=]

TIP1-A_6115 - Größe des Update-Paketes

Hersteller von Komponenten, die den KSR nutzen, DÜRFEN NICHT Update-Pakete hochladen, deren entkomprimierte Paketgröße den abgestimmten Maximalwert übersteigt und der Konfigurationsdienst DARF NICHT Update-Pakete akzeptieren welche diesen Maximalwert übersteigen.
[<=]

TIP1-A_7253 - KSR – Konfigurierbare Maximalgröße von Update-Paketen

Der Konfigurationsdienst MUSS die Konfiguration der maximalen Größe von Update-Paketen erlauben. Der initiale Wert für diesen Konfigurationsparameter MUSS 1500 Mbyte betragen. Die Änderung des Wertes dieses Konfigurationsparameters durch die gematik MUSS ermöglicht werden. [<=]

TIP1-A_7346 - KSR – Löschen von deaktivierten Update-Paketen

Der Konfigurationsdienst SOLL bei Deaktivierung von Update-Paketen die – vom Hersteller gelieferten – Daten des Update-Paketes im Konfigurationsdienst löschen und die im Konfigurationsdienst vorhandenen Metadaten (Daten über das Update-Paket, welche im GUI angezeigt oder in Logfiles und Reports enthalten sind) entsprechend der vorgegebenen Speicherdauer für diese Daten weiterhin zur Verfügung stellen. [<=]

TIP1-A_7347 - KSR – Anzahl Update-Pakete

Der Konfigurationsdienst MUSS pro Hersteller von dezentralen Produkttypen mindestens 10 Update-Pakete speichern und zum Download anbieten können.
Diese Anzahl muss erweiterbar sein. [<=]

TIP1-A_6116 - Update-Paket - Dateinamen und Unterverzeichnisse

Der Konfigurationsdienst und Hersteller von Komponenten, die den KSR nutzen, MÜSSEN folgende Vorgaben im ZIP-Container gewährleisten und fehlerhafte Update-Pakete MÜSSEN abgelehnt werden:

• Die Dateinamen innerhalb des Paketes sind eindeutig.
  
• Es existieren keine Unterverzeichnisse innerhalb des ZIP-Containers.
  

[<=]

TIP1-A_6117 - Referenzierungen des Update-Paketes

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN Update-Pakete erstellen, in denen alle Firmware- und Dokumentationsdateien in der Datei UpdateInfo.xml referenziert werden.
Der Konfigurationsdienst MUSS die Update-Pakete auf die Referenzierung aller Firmware- und Dokumentationsdateien in der Datei UpdateInfo.xml prüfen und fehlerhafte Update-Pakete ablehnen.
[<=]

TIP1-A_6118 - Zusätzliche Dateien im Update-Paket

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN das Update-Paket so erstellen, das nur die in Tab_KSR_010 definierten Elemente in ihr enthalten sind.
Der Konfigurationsdienst MUSS prüfen, dass Update-Pakete nur die in Tab_KSR_010 definierten Elemente enthalten und fehlerhafte Update-Pakete ablehnen.
[<=]

TIP1-A_6119 - Update-Paket – Übertragung „Firmware-Gruppen-Information“

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN, sofern es sich um ein Update einer Firmware-Gruppen-Information ohne neue Firmware handelt, das Update-Paket ausschließlich mit dem Element „Firmware-Gruppen-Information“ und dem optionalen Element „FirmwareGroupInfo-Signature“ füllen.
Der Konfigurationsdienst MUSS die Einhaltung dieser Definition prüfen und fehlerhafte Update-Pakete ablehnen.
[<=]

TIP1-A_6120 - Update-Paket – Dateinamen der UpdateInformation Detached-Signatur

Hersteller von Komponenten, die den KSR nutzen, und der Konfigurationsdienst MÜSSEN, sofern das Update-Paket eine Detached-Signatur der Datei UpdateInfo.xml enthält, die Signatur in der Datei mit dem Namen „UpdateInfo.sig“ erstellen bzw. prüfen und fehlerhafte Update-Pakete ablehnen.
[<=]

TIP1-A_6121 - Update-Paket – Dateinamen der FirmwareGroupInfo Detached-Signatur

Hersteller von Komponenten, die den KSR nutzen, und der Konfigurationsdienst MÜSSEN, sofern das Update-Paket eine Detached-Signatur der Datei FirmwareGroupInfo.xml enthält, die Signatur in der Datei mit dem Namen „FirmwareGroupInfo.sig“ erstellen bzw. prüfen und fehlerhafte Update-Pakete ablehnen.
[<=]

TIP1-A_6128 - Vollständige Update-Pakete

Der Konfigurationsdienst DARF unvollständige Update-Pakete NICHT verarbeiten.
[<=]

TIP1-A_6122 - Pfadreferenz

• Schema: /<ProductVendorId>/<ProductCode>/<UpdateID>/<Filename>
  
• Als Trennzeichen muss das Zeichen „/“ verwendet werden.
  
• <Filename> entspricht dem Pattern „[A-Za-z0-9_-.]*“  und ist nicht länger als 32 Zeichen.
  

[<=]

TIP1-A_6123 - Update-Paket – Signatur

Der Konfigurationsdienst und Hersteller von Komponenten, die den KSR nutzen, MÜSSEN die detached PKCS#7-Signatur zum Update-Paket mit Signatur-Vorgaben entsprechend [gemSpec_Krypt#A_17359]  unterstützen. Das Feld certificates des Feldes signedData der Signatur MUSS das Zertifikat des Signers enthalten (Validation Policy zu [ETSI-CAdES#5.4]). Das Feld signedAttrs der Signatur MUSS die Attribute content-type (OID 1.2.840.113549.1.9.3), message-digest (OID 1.2.840.113549.1.9.4) und ESS signing-certificate-v2 (OID 1.2.840.113549.1.9.16.2.47) enthalten laut [ETSI-CAdES#5.7]. [<=]

TIP1-A_6124 - Bereitstellung KSR Update-Paket Zertifikat

Der KSR-Anbieter MUSS für die Hersteller dezentraler Komponenten X.509-Zertifikate und zugehörige private Schlüssel zum Signieren der Update-Pakete bereitstellen und ihnen Vorgaben machen wie diese Zertifikate beantragt werden können. Hersteller von Komponenten, die den KSR nutzen, MÜSSEN den privaten Schlüssel des bereitgestellten X.509-Zertifikats zum Signieren ihrer Update-Pakete verwenden.
[<=]

TIP1-A_6127 - Fehlerhafte Signaturen

Der Konfigurationsdienst DARF Pakete mit einer fehlerhaften oder nicht verifizierten Signatur NICHT weiter verarbeiten.
[<=]

A_17344 - KSR Bereitstellung "Signier-Tool" für neue kryptographische Algorithmen (ECC-Migration)

Der Anbieter des Konfigurationsdienstes MUSS berechtigten Herstellern dezentraler Komponenten der TI, dem Gesamtverantwortlichen TI (PU) und der Testbetriebsinstanz TU/RU das Tool zur ECC-Signatur von Update-Paketen rechtzeitig vor Auslauf der bisherigen kryptographische Algorithmen bereitstellen.
[<=]

A_17759 - KSR Informationspflicht über neue kryptographische Algorithmen (ECC-Migration)

Der Anbieter des Konfigurationsdienstes MUSS die registrierten Nutzer von dem Upload-Interface – spätestens ab Bereitstellung des Tools – auf das geänderte Tool und den Zeitplan für den Wechsel der kryptographischen Algorithmen hinweisen.   [<=]

A_17374 - KSR Gültigkeit der Update-Pakete bei Migration zu neuen kryptographischen Algorithmen (ECC-Migration)

Der Konfigurationsdienst MUSS Update-Pakete, welche erfolgreich die Eingangsprüfung bestanden haben, aber mit abgelösten kryptographischen Algorithmen signiert wurden, weiterhin für die dezentralen Produkte bereitstellen. 
[<=]

TIP1-A_6066 - KSR Bereitstellung "Signier-Tool"

Der Anbieter des Konfigurationsdienstes MUSS berechtigten Herstellern dezentraler Komponenten der TI, dem Gesamtverantwortlichen TI (PU) und der Testbetriebsinstanz  TU/RU ein plattformunabhängiges Tool (z.B. auf Java Basis) zur Signatur von Update-Paketen - mit dem vom Anbieter des Konfigurationsdienstes gelieferten X.509-Zertifikat (TIP1-A_6124) - bereitstellen, welches alle durch den KSR geprüften Signaturen eines Update-Paketes erstellen kann. Das sind

• die Signatur der Datei FirmwareGroupInfo.xml (siehe Kap. 5.3.1) und
• die Signatur des Update-Pakets (siehe Kap. 6.2.3.4).

[<=]

TIP1-A_3349 - Organisatorische Schnittstelle zur Erteilung von Aufträgen

Der Anbieter des Konfigurationsdienstes MUSS ein Web-Interface für jede Umgebung (RU, TU, PU) im Internet bereitstellen, über die berechtigte Akteure Aufträge zur Aufnahme und Löschung von Update-Paketen und Konfigurationsdatenfiles in die Download-Bereiche der von ihnen verantworteten Umgebungen erteilen können.
[<=]

TIP1-A_3350 - Organisatorische Schnittstelle Form und Inhalt von Aufnahme-Aufträgen

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt eines Auftrags zur Aufnahme eines Update-Pakets/Firmware-Gruppen-Informationen und Konfigurationsdatenfiles in den Download-Bereich definieren und mit den berechtigten Akteuren abstimmen. [<=]

TIP1-A_6126 - Organisatorische Schnittstelle Form und Inhalt Ergebnisse von Aufnahme-Aufträgen

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt des Ergebnisses eines Auftrags definieren und mit den berechtigten Akteuren abstimmen. Die Ergebnisse MÜSSEN permanent gespeichert und durch berechtigte Nutzer im Web-Interface abrufbar sein. Folgende Informationen MÜSSEN mindestens enthalten sein:

• Auftraggeber
• Eindeutige Referenz des verarbeiteten Update-Pakets „UpdateID“, Firmware-Gruppen-Information „FirmwareGroupID“ bzw. Konfigurationsdaten.
  
• Status des verarbeiteten Update-Pakets „UpdateID“, Firmware-Gruppen-Information „FirmwareGroupID“ bzw. Konfigurationsdaten nach Auftragsabarbeitung entsprechend Tab_KSR_050.
  
• Datum und Uhrzeit der Auftragsabarbeitung.
  
• Ergebnis der Auftragsabarbeitung.

[<=]

TIP1-A_5163 - Organisatorische Schnittstelle zur Übergabe von Konfigurationsdaten

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt eines Auftrags zur Übergabe von Konfigurationsdaten definieren und mit den berechtigten Akteuren abstimmen. Folgende Informationen MÜSSEN zwingend enthalten sein:

• Auftraggeber

• Umgebung, in der der Auftrag ausgeführt werden soll

• Name des Konfigurationsdatenfiles

• Format für die Übergabe der zugehörigen Konfigurationsdaten

Die übergebenen Konfigurationsdaten ersetzen (nach Freigabe durch die verantwortliche Instanz) die aktuellen Konfigurationsdaten.

[<=]

TIP1-A_3913 - Organisatorische Schnittstelle Form und Inhalt von Lösch-Aufträgen

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt eines Auftrags zur Löschung eines Update-Pakets/Firmware-Gruppen-Informationen aus dem Download-Bereich definieren und mit den berechtigten Akteuren abstimmen. Folgende Informationen MÜSSEN zwingend enthalten sein:

• Auftraggeber

• Umgebung, in der der Auftrag ausgeführt werden soll

• Eindeutige Referenz auf das bereitzustellende Update-Paket „UpdateID“ bzw. Firmware-Gruppen-Informationen „FirmwareGroupID“

[<=]

TIP1-A_3355 - Schutz Managementschnittstelle

Der Anbieter des Konfigurationsdienstes MUSS die Kommunikationsschnittstelle P_KSRS_Operations gegen unberechtigte Nutzung schützen. Dazu muss der Anbieter des Konfigurationsdienstes den Auftraggeber identifizieren und authentisieren. Der Anbieter des Konfigurationsdienstes kann weitere Schutzmaßnahmen definieren.

[<=]

A_14541 - Status Update-Pakete P_KSRS_Operations

Der Anbieter des Konfigurationsdienstes MUSS sicherstellen, dass berechtigte Akteure (berechtigte Hersteller von Komponenten, die den KSR nutzen, GTI (PU), TBI (TU) und TBI (RU)) in Schnittstelle P_KSRS_Operations der jeweiligen Umgebung den Status der Update-Pakete einsehen können.
[<=]

TIP1-A_3917 - Keine Aufnahme von invaliden Update-Paket bzw. Firmware-Gruppen-Informationen

Ist ein zur Aufnahme beauftragtes Update-Paket bzw. Firmware-Gruppen-Informationen technisch nicht valide (siehe Eingangsprüfung), so DARF der Anbieter des Konfigurationsdienstes es NICHT in den entsprechenden Download-Bereich einstellen.

[<=]

TIP1-A_3918 - Aufnahme von validen Update-Paket bzw. Firmware-Gruppen-Informationen

Ist ein zur Aufnahme beauftragtes Update-Paket bzw. eine Firmware-Gruppen-Information technisch valide, so MUSS der Anbieter des Konfigurationsdienstes es nach erfolgreicher Prüfung des Auftrags in den entsprechenden Download-Bereich einstellen.

[<=]

TIP1-A_3919 - Durchführungsbestätigung eines Auftrags

Nach Ausführung eines Auftrags MUSS der Anbieter des Konfigurationsdienstes den Auftraggeber die erfolgreiche Durchführung des Auftrages bestätigen bzw. über aufgetretene Fehler informieren.

[<=]

TIP1-A_3920 - Form und Inhalt der Durchführungsbestätigung eines Auftrags

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt der Durchführungsbestätigung eines Auftrags definieren und mit den berechtigten Akteuren abstimmen.

[<=]

TIP1-A_3921 - Logging der Auftragsbearbeitung

Der Anbieter des Konfigurationsdienstes MUSS die Durchführung des Prozesses einschließlich der Beauftragung und Bestätigung in Log-Dateien dokumentieren.

[<=]

TIP1-A_3351 - Organisatorische Schnittstelle zur Bereitstellung von PU-Log-Daten

Der Anbieter des Konfigurationsdienstes MUSS dem Gesamtverantwortlichen TI auf Anforderung die Log-Dateien des Upload- und Download-Bereiches der Produktivumgebung (PU) übermitteln.
[<=]

TIP1-A_3922 - Organisatorische Schnittstelle zur Bereitstellung von RU-Log-Daten

Der Anbieter des Konfigurationsdienstes MUSS der Testbetriebsinstanz RU auf Anforderung die Log-Dateien des Upload- und Download-Bereiches der Referenzumgebung (RU) übermitteln.
[<=]

TIP1-A_3923 - Organisatorische Schnittstelle zur Bereitstellung von TU-Log-Daten

Der Anbieter des Konfigurationsdienstes MUSS der Testbetriebsinstanz TU auf Anforderung die Log-Dateien des Upload- und Download-Bereiches der Testumgebung (TU) übermitteln.
[<=]

TIP1-A_3352 - Organisatorische Schnittstelle zur Bereitstellung von statistischen Daten der PU

Der Anbieter des Konfigurationsdienstes MUSS dem Gesamtverantwortlicher TI zyklisch jeden Monat und zusätzlich auf Anfrage adhoc einen Bericht mit den statistischen Daten der Produktivumgebung (PU) übermitteln.
[<=]

TIP1-A_3924 - Organisatorische Schnittstelle zur Bereitstellung von statistischen Daten der RU

Der Anbieter des Konfigurationsdienstes MUSS der Testbetriebsinstanz RU zyklisch jeden Monat und zusätzlich auf Anfrage adhoc einen Bericht mit den statistischen Daten der Referenzumgebung (RU) übermitteln.
[<=]

A_14542 - Berechtigung P_KSRS_Operations

Der Anbieter des Konfigurationsdienstes MUSS sicherstellen, dass

• nur berechtigte Akteure (berechtigte Hersteller von Komponenten, die den KSR nutzen, GTI (PU), TBI (TU) und TBI (RU)) auf P_KSRS_Operations der jeweiligen Umgebung zugreifen können.
• die Rollen Hersteller_RU und Hersteller_RU_Konfig sowie Hersteller_TU und Hersteller_TU_Konfig nicht dem gleichen Akteur zugeordnet werden.
• Akteure mit den Rollen Hersteller_* nur auf eigene Pakete (Pakete mit dem ProductVendorID des Akteurs) und Daten über eigene Pakete zugreifen können.

[<=]

A_14543 - P_KSRS_Operations parallel nutzbar

Der Konfigurationsdienst SOLL die Kommunikationsschnittstelle von P_KSRS_Operations so implementieren, dass sie parallel durch mehrere Aufrufer nutzbar ist.
[<=]

A_14544 - KSR Logging – P_KSRS_Operations

Der Konfigurationsdienst MUSS mindestens für alle Vorgänge welche Daten im Konfigurationsdienst ändern (z.B. Aufnahme-Aufträge und Lösch-Aufträge) Logging-Daten erfassen.
Ein Log-Eintrag MUSS mindestens folgende Informationen erfassen:

• Wer hat etwas getan
• Was wurde getan
• Zeitpunkt
• Updatepaket.UpdateInformation.UpdateID bzw. FirmwareGroupInformation.FirmwareGroupID

[<=]

TIP1-A_3925 - Organisatorische Schnittstelle zur Bereitstellung von statistischen Daten der TU

Der Anbieter des Konfigurationsdienstes MUSS der Testbetriebsinstanz TU zyklisch jeden Monat und zusätzlich auf Anfrage adhoc einen Bericht mit den statistischen Daten der Testumgebung (TU) übermitteln.
[<=]

TIP1-A_5043 - Organisatorische Schnittstellen parallel nutzbar

Der Konfigurationsdienst SOLL die organisatorischen Schnittstellen so realisieren, dass sie parallel durch mehrere Aufrufer nutzbar sind.

[<=]

TIP1-A_6067 - Organisatorische Schnittstelle zur Bereitstellung von KSR Statusberichten der PU

Der Anbieter des Konfigurationsdienstes MUSS dem Gesamtverantwortlichen TI einen Statusbericht im XML-Format mit den Informationen aller auf dem KSR vorliegenden Firmware-Pakete der Produktivumgebung (PU) übermitteln. Dieser Statusbericht MUSS bei jeder Änderung der enthaltenen Daten übermittelt werden.
[<=]

TIP1-A_6074 - Organisatorische Schnittstelle zur Bereitstellung von KSR Statusberichten der PU – Inhalt

Der Anbieter des Konfigurationsdienstes MUSS in dem Statusbericht zu jedem Firmware-Paket mindestens folgende Informationen liefern:

• Timestamp (Zeitstempel des Hochladens auf den KSR)
  
• Kurzbeschreibung (beim Hochladen auf den KSR eingegebene Kurzbeschreibung)
  
• FirmwareGroupInformation
  
• FirmwareGroupID
  
• ProductVendorID
  
• ProductCode
  
• HWVersion
  
• FirmwareGroupVersion
  
• CreationDate
  
• FirmwareGroupReleaseNotes
  
• Liste von Firmwareversionen (FWVersion)
  
• Aktive FG (Kennzeichen ob diese Firmwaregruppe aktiv ist)
  
• UpdateInformation
  
• UpdateID
  
• ProductVendorID
  
• ProductCode
  
• HWVersion
  
• ProductName
  
• CreationDate
  
• DeploymentInformation
  
• StartDate
  
• Deadline
  
• Firmware
  
• FWVersion
  
• FWPriority
  
• FirmwareReleaseNotes
  
• Status
  
• Status-Beschreibung
  

[<=]

TIP1-A_6075 - Organisatorische Schnittstelle zur Bereitstellung von KSR- Statusberichten der PU – Anhänge

Der Anbieter des Konfigurationsdienstes MUSS mit dem Statusbericht als Anlage alle weiteren aktuell gültigen Konfigurationsdateien hinzufügen, welche die Auswahl von Update-Paketen beeinflussen.

[<=]

TIP1-A_6076 - Organisatorische Schnittstelle zur Bereitstellung von KSR- Statusberichten der PU – Excel-Import

Der Anbieter des Konfigurationsdienstes MUSS den Statusbericht in einem XML-Format liefern, welches den Excel-Import und die weitere Analyse des Reports in Excel ermöglicht.

[<=]