BSI Technische Richtlinie 03125 Vertrauenswürdige elektronische Langzeitspeicherung

Bezeichnung

VELS – Vertrauenswürdige elektronische Langzeitspeicherung

Kürzel

BSI TR - 03125

Version

1.0

Datum

31.07.09

Das Dokument ist in Teilen nicht barrierefrei.

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 228 99 9582-0 E-Mail: [email protected] Internet: https://www.bsi.bund.de © Bundesamt für Sicherheit in der Informationstechnik 2009

2

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Vorwort des Präsidenten

Papier ist geduldig, heißt es. Und darüber hinaus hat es viele weitere, ganz handfeste, positive Eigenschaften. Doch Papier ist nicht mehr en vogue: Unternehmen, die öffentliche Verwaltung und die Justiz sind schon seit längerem bestrebt, ihre Geschäftsprozesse möglichst weitgehend in elektronischer Form durchzuführen und die zugehörigen Unterlagen auch in digitaler Form aufzubewahren. Das Substituieren der bisher üblichen, gar sprichwörtlichen Papierberge durch elektronische Dokumente beeinflusst dabei nicht nur die Kommunikation und die unmittelbare Vorgangsbearbeitung oder Geschäftsabwicklung, sondern hat ohne Zweifel für die Archivierung elektronischer Dokumente weitreichende Folgen. Papierdokumente verfügen aufgrund ihrer Körperlichkeit über Eigenschaften, die elektronische Dokumente per se nicht aufweisen. Aus sich heraus können elektronische Dokumente weder wahrgenommen oder gelesen werden, noch Anhaltspunkte für Integrität und Authentizität aufweisen. Diese Eigenschaften aber sind entscheidend. Sie müssen bei der Migration von papiergetragenen zu elektronischen Datenformaten zwingend bedacht werden. Insbesondere für die längerfristige Speicherung elektronischer Dokumente ist die Erhaltung der Lesbarkeit und Vollständigkeit sowie der Integrität und Authentizität unabdingbar und muss durch technische und organisatorische Maßnahmen hergestellt und dauerhaft erhalten werden – mindestens für die Dauer gesetzlich vorgeschriebener Aufbewahrungsfristen. Nationale und internationale Normen und Regelungen stecken hier den Rahmen für Unternehmen wie auch für die öffentliche Verwaltung ab. Tatsächlich existiert bereits eine Reihe von nationalen und internationalen Anforderungskatalogen oder Standards für elektronische Vorgangs- oder Aufbewahrungssysteme. So haben etwa die amerikanische Luft- und Raumfahrtbehörde NASA, das europäische DLM-Forum oder die IETF-LTANS-Arbeitsgruppe Anstrengungen in dieser Sache unternommen. In Deutschland sind aus dem durch das BMWi geförderten Verbundprojekt „ArchiSig“ umfangreiche Ausführungen zu den rechtlichen Anforderungen an die Aufbewahrung elektronisch signierter Dokumente hervorgegangen. Diese Regelungen gelten jedoch in den meisten Fällen nur für bestimmte Branchen oder beziehen sich auf einzelne konkrete Fragestellungen und spezifizieren in der Regel wenig detaillierte Anforderungen an den Entwurf und die Implementierung vertrauenswürdiger elektronischer Archivsysteme insgesamt. Die mit diesem Dokument vorgelegte „Technische Richtlinie zur vertrauenswürdigen elektronischen Langzeitspeicherung (TR-VELS)“ unternimmt deshalb den Versuch, auf der Grundlage bestehender

Bundesamt für Sicherheit in der Informationstechnik

3

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

rechtlicher Normen und technischer Standards sowie nationaler und internationaler Erfahrungen in einem modular aufgebauten Gesamtkonzept anwendungsübergreifende Anforderungen und Kriterien für die langfristige, rechts- und revisionssichere Aufbewahrung elektronischer Dokumente zu spezifizieren und fortzuschreiben. Ziel der TR-VELS ist es, die Auswahl und den adäquaten Einsatz geeigneter Sicherungsmittel für die langfristige und rechtssichere Aufbewahrung elektronischer Dokumente nachhaltig zu unterstützen. Auf der Basis einer hersteller- und produktunabhängigen Referenzarchitektur werden sicherheitstechnische Mindestanforderungen an Systeme, Komponenten und Schnittstellen sowie ihr Zusammenspiel definiert, auf deren Grundlage vertrauenswürdige und funktional konforme elektronische Langzeitaufbewahrungssysteme aufgebaut, überprüft und in Betrieb genommen werden können.

Denn Papier ist nicht nur geduldig, sondern vor allem auch verlässlich. Wir können heute noch problemlos Jahrhunderte alte Papierschriften entziffern. Eine solche Dauerhaftigkeit ist bekanntermaßen mit elektronisch lesbaren Datenträgern nicht zu erreichen. Sechs Jahrhunderte lang war Papier der wichtigste Datenträger, besser: Wissensträger. Jenseits aller gesetzlichen Vorgaben ist es daher auch unser Auftrag, das digitale Wissen unserer Zeit für künftige Generationen nutzbar zu machen.

Bonn, im Juli 2009

Dr. Udo Helmbrecht, Präsident des BSI

4

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Inhaltsverzeichnis 1. Vorbemerkungen..............................................................................................................................10 1.1 Titel................................................................................................................................................10 1.2 Kennzeichnung...............................................................................................................................10 1.3 Fachlich zuständige Stelle..............................................................................................................10 1.4 Versionsverwaltung........................................................................................................................10 1.5 Änderungsdienst / Fortschreibung..................................................................................................11 1.6 Veröffentlichung.............................................................................................................................11 1.7 Konventionen.................................................................................................................................12 2. Anwendungsbereich.........................................................................................................................13 3. Allgemeines und Übersicht...............................................................................................................14 3.1 Aufbau und Inhalte der Technischen Richtlinie..............................................................................14 3.2 Untersuchungsgegenstand und Begriffsdefinitionen.......................................................................14 3.3 Übersicht........................................................................................................................................15 4. Allgemeine Anforderungen an ein vertrauenswürdiges elektronisches Archivsystem......................18 4.1 Rechtliche Rahmenbedingungen....................................................................................................19 4.1.1 Übergreifende rechtliche Rahmenbedingungen...........................................................................20 4.1.2 Sachbezogene rechtliche Rahmenbedingungen...........................................................................25 4.1.3 EU-Recht.....................................................................................................................................37 4.2 Übergreifende funktionale Anforderungen an eine vertrauenswürdige elektronischer Aufbewahrung............................................................................................................................38 4.2.1 Verfügbarkeit und Lesbarkeit......................................................................................................39 4.2.2 Integrität und Authentizität..........................................................................................................40 4.2.3 Datenschutz, Datensicherheit und Vertraulichkeit.......................................................................42 5. Funktionen des Archivsystems.........................................................................................................44 5.1 Funktionale Anforderungen............................................................................................................45 5.1.1 Archivierung signierter und unsignierter Daten...........................................................................45 5.1.2 Abruf (Rückgabe) archivierter Daten...........................................................................................47 5.1.3 Abruf von Beweisdaten...............................................................................................................47 5.1.4 Löschen archivierter Daten..........................................................................................................47 5.2 Organisatorische Anforderungen....................................................................................................48 5.2.1 Die Einrichtung vertrauenswürdiger Archivsysteme...................................................................49 5.2.2 Anforderungen an die Einsatzumgebung.....................................................................................49 6. Abgeleitete technische Anforderungen.............................................................................................51 6.1 Systemtechnische Anforderungen...................................................................................................51 6.2 Empfohlene Dokumentformate.......................................................................................................51 6.3 Empfohlene Speicherformate.........................................................................................................52 6.4 IT-Infrastruktur...............................................................................................................................54

Bundesamt für Sicherheit in der Informationstechnik

5

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

6.5 IT-Anwendungen beim Einsatz von Archivierungsverfahren.........................................................54 7. IT-Architektur..................................................................................................................................56 7.1 Empfohlene IT-Referenzarchitektur...............................................................................................56 7.2 Alternative Architekturen...............................................................................................................57 7.3 Komponenten und Module.............................................................................................................57 7.3.1 Vorgelagerte Anwendungssysteme..............................................................................................58 7.3.2 XML-Adapter zur Anbindung von Geschäftsanwendungen an das Archiv (TR-VELS-M.5).........................................................................................................................58 7.3.3 ArchiSafe-Modul (TR-VELS-M.1).............................................................................................59 7.3.4 Krypto-Modul (TR-VELS-M.2)..................................................................................................60 7.3.5 ArchiSig-Modul (TR-VELS-M.3)...............................................................................................61 7.3.6 Der Langzeitspeicher (TR-VELS-M.4).......................................................................................61 7.3.7 Die Kommunikationskanäle und Schnittstellen...........................................................................61 7.4 Zusammenspiel der Komponenten..................................................................................................62 7.4.1 Archivierung elektronischer Unterlagen......................................................................................62 7.4.2 Abfrage archivierter Daten..........................................................................................................65 7.4.3 Rückgabe technischer Beweisdaten.............................................................................................66 7.4.4 Löschen von Archivdaten............................................................................................................68 7.4.5 Änderung von Metadaten (z. B. Aufbewahrungsfristen)..............................................................70 8. IT-Sicherheitskonzept.......................................................................................................................72 8.1 Sicherheitsziele...............................................................................................................................72 8.2 Maßnahmen....................................................................................................................................73 8.2.1 Übergreifende Maßnahmen.........................................................................................................73 8.2.2 Maßnahmen zum Schutz der Vertraulichkeit...............................................................................73 8.2.3 Maßnahmen zum Schutz der Authentizität, Integrität und Verbindlichkeit (Zurechenbarkeit)....75 8.2.4 Maßnahmen zum Schutz der Verfügbarkeit.................................................................................78 8.2.5 Maßnahmen zur Autorisierung (Vertraulichkeit, Integrität)........................................................78 9. Konformität und Interoperabilität.....................................................................................................79 9.1 Konformität und Konformitätsprüfung...........................................................................................79 9.2 Beteiligte Instanzen bei der Konformitätsprüfung..........................................................................80 9.2.1 Antragsteller................................................................................................................................80 9.2.2 Prüfgegenstand............................................................................................................................80 9.2.3 Prüfstelle......................................................................................................................................80 9.2.4 Bestätigungsstelle........................................................................................................................81 9.3 Abwicklung der Konformitätsprüfung............................................................................................82 9.3.1 Vorphase......................................................................................................................................82 9.3.2 Durchführung der Konformitätsprüfung......................................................................................82 9.3.3 Konformitätsbestätigung..............................................................................................................83 9.4 Interoperabilität..............................................................................................................................83 10. Anlagen..........................................................................................................................................84 10.1 TR-VELS-M.1 ArchiSafe-Modul.................................................................................................84 10.2 TR-VELS-M.2 Krypto-Modul......................................................................................................85 6

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

10.3 TR-VELS-M.3 ArchiSig-Modul...................................................................................................86 10.4 TR-VELS-M.4 Langzeitspeicher..................................................................................................87 10.5 TR-VELS-M.5 XML-Adapter zur Anbindung von Geschäfts-Anwendungen an das Archiv.......88 10.6 TR-VELS-S.1 Schnittstelle zwischen Krypto-Modul und ArchiSafe...........................................89 10.7 TR-VELS-S.2 Schnittstelle zwischen ArchiSig und Langzeitspeicher.........................................90 10.8 TR-VELS-S.3 Schnittstelle zwischen Krypto-Modul und ArchiSig.............................................91 10.9 TR-VELS-S.4 Schnittstelle zwischen dem XML-Adapter und ArchiSafe....................................92 10.10 TR-VELS-S.5 Schnittstelle zwischen ArchiSafe und dem Langzeitspeicher..............................93 10.11 TR-VELS-S.6 Schnittstelle zwischen ArchiSafe und ArchiSig..................................................94 10.12 TR-VELS-F Formate und Protokolle für die Langzeitspeicherung.............................................95 10.13 TR-VELS-E Konkretisierung der Schnittstellen auf Basis des eCard-API-Frameworks............96 11. Zuordnung der Anforderungen.......................................................................................................97 12. Abkürzungsverzeichnis.................................................................................................................102 13. Glossar..........................................................................................................................................106 14. Quellenverzeichnis.......................................................................................................................123

Bundesamt für Sicherheit in der Informationstechnik

7

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Verzeichnis der Abbildungen Abbildung 1: Typische Archiv-Infrastruktur......................................................................................17 Abbildung 2: Anwendungsfälle für die elektronische Archivierung..................................................45 Abbildung 3: Typischer Archivierungsablauf....................................................................................47 Abbildung 4: Referenzarchitektur Übersicht......................................................................................57 Abbildung 5: Schematischer Ablauf der Archivierung......................................................................65 Abbildung 6: Schematischer Ablauf des Abrufs archivierter Daten...................................................67 Abbildung 7: Schematischer Ablauf des Abrufs technischer Beweisdaten........................................69 Abbildung 8: Schematischer Ablauf der Löschung von Archivdatenobjekten...................................70 Abbildung 9: Krypto-Modul..............................................................................................................86

8

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Verzeichnis der Tabellen Tabelle 1: Rechtliche Themen und gesetzliche Regelungen..............................................................19 Tabelle 2: Aufbewahrungspflichtige Unterlagen nach HGB, Quelle [SBR 04], S. 16........................28 Tabelle 3: Aufbewahrungspflichtige Unterlagen nach § 25a Abs. 1 KWG, Quelle: [SBR 04], S. 19.32 Tabelle 4: Aufbewahrungspflichtige Unterlagen nach WpHG, Quelle: [SBR 04], S. 19,20..............33 Tabelle 5: Zuordnung der Anforderungen........................................................................................102

Bundesamt für Sicherheit in der Informationstechnik

9

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

1. Vorbemerkungen Kapitel 1 enthält Angaben zur Bezeichnung dieser Technischen Richtlinie (TR), zur fachlich zuständigen Stelle, zur Versionsverwaltung, zum Änderungsdienst und der Fortschreibung der TR.

1.1

Titel

Diese TR trägt den Titel "Technische Richtlinie zur vertrauenswürdigen elektronischen Langzeitspeicherung (VELS)“.

1.2

Kennzeichnung

Diese TR wird gekennzeichnet mit „BSI TR-03125“.

1.3

Fachlich zuständige Stelle

Fachlich zuständig für die Formulierung und Betreuung dieser TR ist das Bundesamt für Sicherheit in der Informationstechnik (BSI). Anschrift:

1.4

Bundesamt für Sicherheit in der Informationstechnik (BSI) Postfach 20 03 63 53133 Bonn Tel.: +49 228 99 9582-0 E-Mail: [email protected] Internet: https://www.bsi.bund.de

Versionsverwaltung

Diese TR besteht aus diesem Dokument und weiteren separaten normativen Anhängen (siehe hierzu Kapitel 10). Darüber hinaus wird es weitere Anhänge mit den entsprechenden Prüfspezifikationen für die notwendigen Konformitätsprüfungen geben. Die zur Zeit gültigen Teile dieser TR sind: Teil der TR Hauptdokument (dieses Dokument) Anlage TR-VELS-M.1 ArchiSafe-Modul Anlage TR-VELS-M.2 Krypto-Modul Anlage TR-VELS-M.3 ArchiSig-Modul Anlage TR-VELS-M.4 Langzeitspeicher Anlage TR-VELS-M.5 XML-Adapter zur Anbindung von Geschäfts-Anwendungen an das Archiv

10

1.0 1.0

Datum (JJJJ-MM-TT) 2009-07-31 2009-07-31

1.0

2009-07-31

1.0

2009-07-31

Version

Bemerkung

In Vorbereitung In Vorbereitung

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Teil der TR Anlage TR-VELS-S.1 Schnittstelle zwischen Krypto-Modul und ArchiSafe Anlage TR-VELS-S.2 Schnittstelle zwischen ArchiSig und Langzeitspeicher Anlage TR-VELS-S.3 Schnittstelle zwischen Krypto-Modul und ArchiSig Anlage TR-VELS-S.4 Schnittstelle zwischen dem XML-Adapter und ArchiSafe Anlage TR-VELS-S.5 Schnittstelle zwischen ArchiSafe und dem Langzeitspeicher Anlage TR-VELS-S.6 Schnittstelle zwischen ArchiSafe und ArchiSig Anlage TR-VELS-E Konkretisierung der Schnittstellen auf Basis des eCard-API-Frameworks Anlage TR-VELS-F Formate und Protokolle

1.5

1.0

Datum (JJJJ-MM-TT) 2009-07-31

1.0

2009-07-31

1.0

2009-07-31

1.0

2009-07-31

Version

Bemerkung

In Vorbereitung

1.0

2009-07-31

1.0

2009-07-31

1.0

2009-07-31

Änderungsdienst / Fortschreibung

Die TR und ihre normativen Anhänge unterliegen fortwährender weiterer Verbesserung und Anpassung an neue Anforderungen. Die Fortführung muss geordnet verlaufen, d. h. dass abgestimmte Versionen der TR in einem formalen Akt freigegeben werden. Formal freigegebene Versionen oder Patches werden auf der Webseite des BSI veröffentlicht. Die Veröffentlichung erfolgt geregelt.

1.6

Veröffentlichung

Die aktuell gültigen Versionen werden auf den TR-VELS Webseiten des BSI zum Download angeboten. In einem auf den TR-VELS Webseiten des BSI verfügbaren Änderungsverzeichnis werden die Versionen mit Beschreibung der Erweiterung oder Änderung und des Datums geführt.

1.7

Konventionen

Die in dieser Technischen Richtlinie spezifizierten Anforderungen und Empfehlungen an rechts- und revisionssichere Archivsysteme im Sinne einer vertrauenswürdigen elektronischen Langzeitspeicherung werden eindeutig gekennzeichnet. Hierbei gilt:

Bundesamt für Sicherheit in der Informationstechnik

11

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

•

BSI TR 03125

Der Anforderung wird ihre eindeutige Kennung der Form (Ax.y-z) vorangestellt, wobei x das jeweilige Hauptkapitel y das jeweilige Unterkapitel und z eine fortlaufende Nummer innerhalb des Unterkapitels ist.

Jede Anforderung wird in Anlehnung an [RFC2119] explizit als verpflichtend, empfohlen oder als optional spezifiziert. Verpflichtende Anforderungen (MUSS-Anforderungen), sind Anforderungen deren Umsetzung zwingend gefordert wird. Sie sind im Text mit den Worten muss (müssen) / ist (sind), ausgezeichnet. Empfohlene Anforderungen (SOLL-Anforderungen) sollten umgesetzt werden. Sie sind im Text mit den Worten soll (sollen) / empfohlen ausgezeichnet. Optionale Anforderungen (KANN-Anforderungen) können umgesetzt werden. Sie sind im Text mit den Worten kann (können) ausgezeichnet. Weitere Erläuterungen zu diesen kennzeichnenden Begriffen sind in Kapitel 9.3 zu finden.

12

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

2. Anwendungsbereich Vertrauenswürdige elektronische Langzeitspeicherung im Sinne dieser technischen Richtlinie bezeichnet die langfristige, rechts- und revisionssichere elektronische (digitale) Speicherung von aufbewahrungspflichtigen elektronischen (digitalen) Dokumenten und Daten nebst den zugehörigen elektronischen (digitalen) Verwaltungsdaten (Metadaten) auf maschinenlesbaren Datenträgern zur Erfüllung gesetzlicher Aufbewahrungspflichten. Vornehmlicher Anwendungsbereich der vorliegenden Technischen Richtlinie sind die Bundesbehörden im Rahmen der gesetzlichen Aufbewahrungspflichten. Darüber hinaus besitzt die Technische Richtlinie empfehlenden Charakter.

Bundesamt für Sicherheit in der Informationstechnik

13

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

3. Allgemeines und Übersicht In diesem Kapitel werden der Aufbau und die Inhalte der Technischen Richtlinie sowie die grundsätzlichen Ziele und Herausforderungen an eine vertrauenswürdige und langfristige Aufbewahrung elektronischer Dokumente erläutert.

3.1

Aufbau und Inhalte der Technischen Richtlinie

Die Technische Richtlinie besteht aus diesem Hauptdokument sowie einer Reihe ergänzender Anlagen, in denen einzelne Aspekte der Anforderungen an ein vertrauenswürdiges elektronisches Archivsystem näher spezifiziert und erläutert werden. In diesem Hauptdokument werden zunächst die rechtlichen Rahmenbedingungen und Normen, die grundsätzlichen Ziele und Anforderungen an eine vertrauenswürdige elektronische Aufbewahrung, die abzubildenden Prozesse und Funktionen, die Anforderungen an die Einrichtung sowie systemtechnische Anforderungen und eine empfohlene Systemarchitektur (Referenzarchitektur) vertrauenswürdiger elektronischer Archivsysteme, die Sicherheitsziele und Sicherheitsmaßnahmen sowie der Umfang und die Inhalte einer Konformitätsprüfung technischer Produktlösungen mit den in dieser Richtlinie definierten Anforderungen beschrieben. Darüber hinaus enthält dieses Hauptdokument in Kapitel 10 eine Übersicht über die mit diesem Dokument veröffentlichten und geplanten Anlagen. In diesen ergänzenden Anlagen werden die in diesem Hauptdokument definierten Anforderungen auf der Grundlage einer in Kapitel 7 beschriebenen plattform- und produktneutralen Referenzarchitektur für vertrauenswürdige elektronische Archivsysteme näher spezifiziert und erläutert. Die Beschreibung der Ziele und Anforderungen ist strikt produkt- und herstellerneutral und orientiert sich allein an den entsprechenden rechtlichen Anforderungen und technischen Umsetzung der gesetzlich vorgeschriebenen Aufbewahrungspflichten elektronischer Unterlagen.

3.2

Untersuchungsgegenstand und Begriffsdefinitionen

Dieses Kapitel enthält die für diese Technische Richtlinie wesentlichen Begriffsdefinitionen. Weitere Begriffsdefinitionen finden sich im Glossar in Kapitel 13. Die dauerhafte und unveränderbare Aufbewahrung (Speicherung) von elektronischen Dokumenten und anderen Daten wird im informationstechnischen Sprachgebrauch allgemein als elektronische Archivierung bezeichnet. Der mit dem Begriff „dauerhaft“ umschriebene Zeithorizont überschreitet dabei aus informationstechnischer Sicht in der Regel kaum mehr als 10 bis 30 Jahre. Hierfür hat sich im deutschen Sprachgebrauch auch der Begriff der elektronischen Langzeitarchivierung eingebürgert, um den Unterschied zur kurzzeitigen (operativen) Speicherung bzw. zum Backup hervorzuheben. Aus rechtlicher Sicht ist der Begriff der Archivierung durch die Archivgesetze des Bundes und der Länder konkretisiert und belegt und daher von der zeitlich beschränkten Aufbewahrung zu unterscheiden. Archivierung im juristischen Kontext betrifft allein Unterlagen der öffentlichen Verwaltung und bezieht sich darauf, dass Schriftgut einer Behörde, sobald es für die Zwecke der Behörde nicht mehr benötigt wird, ausgesondert und durch eine zuständige staatliche Einrichtung (Archiv) auf unbegrenzte Zeit verwahrt werden soll (vgl. §§1 und 2 BArchG). Dieser in den Archivgesetzen des Bundes und der Länder regulierte „Archivzwang“ nach Aussonderung und Abgabe des Schriftguts und das ihm vorausgehende obligatorische Anbietungsgebot bleiben daher von den in dieser Technischen Richtlinie beschriebenen Anforderungen unberührt. Die vorliegende Technische Richtlinie bezieht sich ausschließlich auf die Nutzung des Langzeitspeichersystems in Behörden und Unternehmen während der Aufbewahrungsfrist des Schriftgutes unter Wahrung der Rechtssicherheit und der Revisionssicherheit. Insbesondere beschränkt sich die TR auf stabile Speicherformate, die für die angedachten Aufbewahrungszeiträume angemessen sind. Die Transformation von (signierten) Dokumenten wird deshalb hier nicht betrachtet.

14

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Rechtssichere Langzeitspeicherung im Sinne dieser technischen Richtlinie bedeutet, dass ein zu dieser Richtlinie konformes elektronisches Archivsystem imstande ist, den beweisrechtlichen Wert der in ihm aufbewahrten elektronischen Informationen über die Dauer des Aufbewahrungszeitraumes zu erhalten und so die mit der Aufbewahrung bezweckten Rechtsfolgen elektronischer Unterlagen mindestens für die Dauer der gesetzlich vorgeschriebenen Aufbewahrungszeiträume zu gewährleisten. Mit revisionssicherer elektronischer Langzeitspeicherung bezeichnet diese technische Richtlinie elektronische Archivsysteme, die nach den Vorgaben des Handelsgesetzbuches (§§ 239, 257 HGB), der Abgabenordnung (§§ 146, 147 AO) und der Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) elektronische Daten und Dokumente sicher, unverändert, vollständig, ordnungsgemäß, verlustfrei reproduzierbar und datenbankgestützt recherchierbar zu verwalten imstande sind.1 Vertrauenswürdige elektronische Langzeitspeicherung im Sinne dieser technischen Richtlinie bezeichnet die langfristige, rechts- und revisionssichere elektronische Speicherung von aufbewahrungspflichtigen Dokumenten und Daten nebst den zugehörigen Verwaltungsdaten (Metadaten) auf maschinenlesbaren Datenträgern zur Erfüllung gesetzlicher Aufbewahrungspflichten (siehe auch Kapitel 4). Wenn an den jeweiligen Textstellen nicht explizit etwas anderes vermerkt ist, ist in dieser Technischen Richtlinie der Begriff „Archivierung“ an den jeweiligen Stellen im Sinne einer vertrauenswürdigen elektronischen Langzeitspeicherung zu verstehen. Darüber hinaus unterliegen behördliche elektronische Unterlagen selbstverständlich weiterhin und unabhängig von der informationstechnischen Langzeitspeicherung den rechtlich geregelten Archivregelungen gemäß BArchG. Das heißt für Bundesbehörden, dass nach Ablauf der Aufbewahrungsfristen eine gesetzlich festgelegte Anbietungspflicht an das BArch besteht. Weitere wichtige Begriffsdefinitionen wie z.B. Daten, Dokument, Metadaten etc. sind dem Kapitel 13 zu entnehmen.

3.3

Übersicht

Das Ziel einer auch auf lange Zeiträume angelegten vertrauenswürdigen Ablage elektronischer Unterlagen ist die dauerhafte, rechts- und revisionssichere Speicherung (Konservierung) digitaler Dokumente und Daten (Inhaltsdaten)2 sowie zugehöriger Metainformationen zu einem nachweisbaren Zeitpunkt T1, an dem die Dokumente und Daten in einem elektronischen Archivsystem abgelegt wurden. Für rechtlich bedeutsame Dokumente und Daten sind dabei zusätzlich nachprüfbare Belege über den Aussteller (Authentizität) sowie die Unversehrtheit (Integrität) der aufbewahrten Dokumente und Daten dauerhaft und entsprechend der rechtlichen Anforderungen vorzuhalten. Der Inhalt elektronischer Unterlagen ist auf der Anwendungsebene von IT-Systemen in der Regel als ein Strom (Folge) von Zeichen eines endlichen Zeichensatzes Z 1 codiert. Die zugehörigen Metadaten lassen sich in zwei Kategorien unterscheiden: 1

2

Der Begriff der Revisionssicherheit orientiert sich am Verständnis der Revision aus wirtschaftlicher Sicht und betrifft vor allem aufbewahrungspflichtige oder aufbewahrungswürdige Informationen und Dokumente aus handelsrechtlicher und steuerrechtlicher Sicht. Der § 238 HGB verpflichtet Kaufleute zur Buchführung und zur Aufbewahrung von Handelsbriefen. Als Handelsbrief gilt, was einen, wenn auch nur entfernten oder lockeren, Zusammenhang mit betrieblichen Interessen hat. Das bedeutet, aufbewahrungspflichtige oder aufbewahrungswürdige Informationen und Dokumente sind sämtliche elektronischen Daten und Dokumente, die einen sachlogischen Zusammenhang mit einem Geschäfts- oder Verwaltungsvorgang begründen oder ergeben. Der Begriff revisionssichere Archivierung wurde 1992 von Ulrich Kampffmeyer geprägt und vom deutschen Fachverband der Dokumentenmanagementbranche, VOI Verband Organisations- und Informationssysteme e.V. in einem Code of Practice [KAMPFF97] im Jahr 1996 allgemeingültig veröffentlicht. Revisionssicherheit im Zusammenhang mit der elektronischen Archivierung bezieht sich dabei nicht nur auf technische Komponenten sondern auf die gesamte Lösung. Revisionssicherheit schließt sichere Abläufe, die Organisation des Anwenderunternehmens, die ordnungsgemäße Nutzung, den sicheren Betrieb und den Nachweis in einer Verfahrensdokumentation ein. Kriterien für die „Revisionssicherheit“ sind vor allem Nachvollziehbarkeit, Schutz der Daten vor Veränderung und Verlust sowie die Wiederauffindbarkeit der Daten in einem angemessenen Zeitraum. Ziel der revisionssicheren Aufbewahrung elektronischer Unterlagen ist es, die internen und gesetzlichen Anforderungen zu erfüllen, die als Voraussetzung für die Durchführung einer Revision festgelegt worden sind. Der Begriff Revisionssicherheit oder revisionssichere Archivierung wird inzwischen auch auf die Archivierung von Informationen außerhalb des handels- und steuerrechtlichen Bereichs angewendet und häufig synonym mit der verfälschungssicheren, langfristigen Archivierung elektronischer Informationen benutzt. Es kann sich dabei durchaus um verschiedenste Datenarten handeln – Texte, Bilder, Signale, Töne, Filme, etc. Zur Vereinfachung wird in dieser Technischen Richtlinie jedoch immer nur von Dokumente und Daten gesprochen.

Bundesamt für Sicherheit in der Informationstechnik

15

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

•

Ein Metadatensatz M1 enthält Informationen über den zur Codierung der Unterlagen verwendeten Zeichensatz Z1 und umfasst somit Informationen zur Darstellung und Formatierung der eigentlichen Inhaltsdaten.

•

Ein Metadatensatz M2 enthält zusätzliche beschreibende Metainformationen zu den digitalen Unterlagen (z. B. Ersteller, Datum, Aktenzeichen, usw.) und stellt somit beispielsweise sicher, dass die Dokumente oder Daten wieder gefunden und einem Vorgang zugeordnet werden können.

Auch die Metadaten sind als Folge eines Zeichensatzes Z 2 codiert. Die Zeichensätze Z1 und Z2 können, müssen aber nicht übereinstimmen. Darüber hinaus genügen die Metadaten bestimmten syntaktischen und semantischen Regeln, die in der Spezifikation der Metadatensätze begründet sind. Das Ziel und die Herausforderung der rechts- und revisionssicheren Ablage elektronischer Unterlagen ist es daher, für die digitalen Inhalte sowie deren Metadatensätze M1 und M2 die Verfügbarkeit und Lesbarkeit, • die Integrität (Unversehrtheit), • die Authentizität (daraus folgt auch die Nichtabstreitbarkeit) und • Datenschutz, Datensicherheit und Vertraulichkeit für lange Zeiträume (mehrere Jahrzehnte) zu gewährleisten. Gegenstand von vertrauenswürdigen IT-gestützten Archivierungsprozessen ist daher der Dokumentenund Datenfluss von aufbewahrungspflichtigen oder aufbewahrungswürdigen Dokumenten und Daten von dem Zeitpunkt des Beginns ihrer Aufbewahrungspflicht, respektive ihrer Aufbewahrungswürdigkeit, über ihre langfristige und unveränderliche Aufbewahrung bis zu ihrer abschließenden Vernichtung. Zur Sicherung der Verfügbarkeit elektronischer Unterlagen gehört dabei auch die Gewährleistung der Lesbarkeit und Darstellbarkeit der Inhaltsdaten und Metainformationen über lange Zeiträume auf den zum Zeitpunkt der Verfügbarmachung üblichen IT-Systemen. Ein für diese Zwecke eingerichtetes elektronisches Archivierungssystem umfasst deshalb alle diejenigen Elemente und Prozesse eines IT-Systems, die zur Erzeugung, Speicherung, Indexierung 3, Suche, Verwaltung, Lesbarmachung und langfristigen und unveränderlichen Aufbewahrung von zu speichernden Daten eingesetzt werden. Dazu gehören i. d. R. •

3

16

•

die zur Archivierung eingesetzte IT-Infrastruktur und

•

die zur Archivierung und zur Sicherung der Authentizität und Integrität der archivierten Dokumente und Daten eingesetzten IT-Anwendungen.

Indexierung im Sinne dieser Richtlinie bezeichnet die Verknüpfung von Daten und Dokumenten mit einem oder mehreren eindeutigen Ordnungskriterien und ist von der Verschlagwortung von aufbewahrungspflichtigen Unterlagen zu unterscheiden.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Abbildung 1: Typische Archiv-Infrastruktur

Die zur Archivierung eingesetzte IT-Infrastruktur besteht typischerweise, wie auch in Abbildung 1 dargestellt, aus •

einem Speichersystem, das die unterschiedlichen zur Archivierung eingesetzten Speichermedien umfasst und verwaltet, und den zuverlässigen und sicheren Zugriff auf die Speichermedien für die Ablage, den Abruf oder die Löschung archivierter Dokumente und Daten gewährleistet,

•

(kryptographischen) Komponenten und Schnittstellen, die den Erhalt des beweisrechtlichen Wertes der archivierten Unterlagen (Dokumente und Daten) unterstützen sowie

•

Archivschnittstellen, die der Integration der Archivlösung in eine bestehende, unternehmensoder organisationsweite IT-Infrastruktur dienen und die archivierten Daten und Dokumente vor dem unberechtigten Zugriff Dritter schützen.

Die zur Archivierung eingesetzten IT-Anwendungen umfassen typischerweise Programme oder Schnittstellen (Datenarchivierungsfunktionen) zur Erzeugung, Indexierung und Verwaltung der zu archivierenden Unterlagen, zur Recherche sowie zur Wiedergabe oder auch Löschung von Daten und Dokumenten aus dem Archivierungssystem. Der Aufruf der Datenarchivierungsfunktionen erfolgt typischerweise aus organisationsspezifischen IT-Anwendungen oder IT-Services. Unabhängig von der eingesetzten Technologie, den eingesetzten Verfahren und Anwendungen sind die gesetzlichen Vertreter verantwortlich für die Einhaltung der gesetzlichen Sicherheits- und Ordnungsmäßigkeitsanforderungen, die beim Einsatz von elektronischen Archivierungssystemen erforderlich sind. Im Einzelnen sind diese in den nachfolgenden Abschnitten beschrieben.

Bundesamt für Sicherheit in der Informationstechnik

17

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

4. Allgemeine Anforderungen an ein vertrauenswürdiges elektronisches Archivsystem Die elektronische Ablage und Aufbewahrung elektronischer signierter und unsignierter Dokumente und Daten in einem elektronischen Archivsystem ist grundsätzlich so auszugestalten, dass die aus rechtlicher Sicht bestehenden Aufbewahrungspflichten und –ziele für lange Zeit, mindestens aber für die Dauer der gesetzlich festgelegten Aufbewahrungsfristen, erfüllt werden können. Vornehmliches Ziel dabei ist es, den beweisrechtlichen Wert elektronisch aufbewahrter Informationen zum Nachweis eines Rechts oder einer Pflicht, eines bestimmten Handelns, des Unterlassens oder eines Handlungsverlaufs sowie der Einhaltung gesetzlicher Vorschriften und Regelungen für die Dauer ihrer Aufbewahrungszeit durch den Einsatz eines vertrauenswürdigen Archivsystems zu schützen und zu erhalten. Die deutsche Rechtsordnung kennt zum Zeitpunkt der Veröffentlichung dieser Richtlinie kein „Aufbewahrungsgesetz“, welches die Aufbewahrungsfristen übergreifend regelt, weder für papierbasierte noch für elektronische Dokumente (vgl. [ARO 07], S. 55). Es ist daher notwendig, die im Einzelfall geltenden Anforderungen an die Dokumentation und Aufbewahrung aus den für den jeweiligen Sachbereich relevanten Normen und Vorschriften abzuleiten. Gleiches gilt für den europäischen Kontext. Auch hier existiert derzeit keine einheitliche EU-Norm, die spezielle Anforderungen für die langfristige Aufbewahrung elektronischer Daten und Dokumente formuliert. Allgemeine rechtliche Anforderungen an die Aufbewahrung elektronischer Unterlagen lassen sich dabei aus den vorhandenen anwendungsübergreifenden Normen (z. B. dem Datenschutzrecht und dem Signaturrecht) oder auch aus sachbezogenen rechtlichen Regelungen wie dem Handels- und Steuerecht oder verwaltungsrechtlichen und haushaltsrechtlichen Normen der öffentlichen Verwaltung ableiten (siehe [SFD 06], S. 33 ff., [ARO 07], S. 79 ff.). Die nachfolgende Tabelle 1 gibt einen Überblick über bestehende rechtliche Normen sowie ihren rechtsthematischen Bezügen zur Langzeitspeicherung elektronischer Informationen. Von zentraler Bedeutung und Wirkung ist hier insbesondere das Signaturrecht, das im Zusammenhang mit dem Gesetz zur Anpassung der Formvorschriften des Privatrechts und anderer Vorschriften an den modernen Rechtsgeschäftsverkehr [FormAnpG] und dem Verwaltungsverfahrensgesetz [VwVfG] die Voraussetzungen und Anforderungen an die beweisrechtliche Anerkennung und den Erhalt des beweisrechtlichen Wertes elektronischer Unterlagen normiert. HINWEIS: An dieser Stelle sei darauf hingewiesen, dass die in den folgenden Abschnitten aufgeführten normativen Regelungen keinen vollständigen Überblick über einzelne rechtliche Anforderungen aus unterschiedlichen Rechtsgebieten geben können. Um den Rahmen des Dokuments nicht zu sprengen, beschränkt sich der Überblick zudem auf bundesrechtliche Regelungen. Es obliegt dem Anwender eines Archivsystems, sich vor dessen Einsatz eingehend über die für ihn geltenden rechtlichen Bestimmungen im Hinblick auf den Einsatz eines solchen Archivsystems zu informieren.

18

Bundesamt für Sicherheit in der Informationstechnik

Schutz vor Verlust

X

X

ZPO

SigG, SigV

X X

Schutz vor unberechtigtem Zugriff

X

Einhaltung von Aufbewahrungsfristen

X

X

Sicherstellung des gesetzlichen Zugriffs

X

X

Sicherstellung der Beweiskraft vor Gericht Beteiligungsrechte der Mitarbeiter

GoB

X

GoBS

X

GDPdU

X

HGB

Ordnungsmäßigkeit, Integrität, Authentizität

BDSG

Rechtliche Themen

AO

Rechtliche Grundlagen

BGB

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BetrVG

BSI TR 03125

X X

X

X

Legende: AO Abgabenordnung, BDSG Bundesdatenschutzgesetz, BetrVG Betriebsverfassungsgesetz,4 BGB Bürgerliches Gesetzbuch, GDPdU Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen, GoB Grundsätze ordnungsgemäßer Buchführung, GoBS Grundsätze ordnungsgemäßer DV-gestützter Buchführung, HGB Handelsgesetzbuch, SigG Signaturgesetz, SigV Signaturverordnung, ZPO Zivilprozessordnung

Tabelle 1: Rechtliche Themen und gesetzliche Regelungen

4.1

Rechtliche Rahmenbedingungen

Die Aufbewahrungspflicht und Aufbewahrungswürdigkeit elektronischer Dokumente und Unterlagen ist i. d. R. in dem jeweiligen Fachrecht begründet und dient vor allem der Gedächtnisstütze, dem Schutz und der Wahrung von Rechtsansprüchen des Ausstellers oder Dritter und dem Nachweis der Ordnungsmäßigkeit im elektronischen Rechts- und Geschäftsverkehr. Eine vertrauenswürdige langfristige Aufbewahrung elektronischer Unterlagen verpflichtet daher zur Vollständigkeit und Sicherheit der aufbewahrten Daten und Dokumente, zur Einhaltung von Aufbewahrungsfristen, zur Dokumentation und regelmäßigen Kontrolle der richtigen Anwendung des Verfahrens. Sicherheit bedeutet in diesem Zusammenhang vor allem den Schutz der Informationen und Daten vor Veränderung und Verfälschung (Gewährleistung der Integrität), vor unberechtigtem Zugriff (Kenntnisnahme) sowie die Sicherung der Daten und Informationen vor Verlust. Für die rechtmäßige elektronische Aufbewahrung zusätzlich von Bedeutung ist dabei die Tatsache, dass elektronische Dokumente keine Urkundsqualität im Sinne des Gesetzes besitzen. Damit bestünde ein rechtliches Hemmnis für die Distribution rechtsverbindlicher Leistungen über das Medium Internet oder anderen elektronischen Datenträgern. Der deutsche Gesetzgeber hat darauf durch Gesetzesänderungen reagiert, mit denen er vor allem die rechtlichen Rahmenbedingungen beschreibt, unter welchen Umständen elektronische Dokumente Rechtswirkung entfalten können und welche Anforderungen in diesem Zusammenhang an die Gewährleistung der Integrität und Authentizität elektronischer Dokumente zu stellen sind (Beweiskraft elektronischer Dokumente). Kernstücke der rechtlichen Regelungen sind neben dem Signaturgesetz (SigG) vom 22. Mai 2001 sowie der sich hieran anschließenden Signaturverordnung (SigV) vom 24. Oktober 2001, die Änderungen

4

Daneben gibt es noch das Bundespersonalvertretungsgesetz (BPersVG). Da die TR jedoch keinen Anspruch auf Vollständigkeit der juristischen Grundlagen erhebt, werden hier nur einige Beispiele angeführt.

Bundesamt für Sicherheit in der Informationstechnik

19

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

(Ergänzungen) der Formvorschriften des BGB, die Erleichterungen der Beweisführung im Rahmen der ZPO und die Anpassung des Verwaltungsverfahrensrechtes des Bundes (VwVfG). Für die Einrichtung und den Betrieb vertrauenswürdiger, rechts- und revisionssicherer elektronischer Archivsysteme sind die Einhaltung sämtlicher für den jeweiligen Sachbereich geltenden Anforderungen und normativen Regelungen für die Aufbewahrung von Unterlagen auch für elektronisch erzeugte und verarbeitete Daten und Dokumente zu bestimmen und nachvollziehbar zu gewährleisten.

4.1.1

Übergreifende rechtliche Rahmenbedingungen

Der folgende Abschnitt erläutert allgemeine normative Anforderungen an die Aufbewahrung elektronischer Dokumente, die sich vornehmlich aus nationalen, anwendungsübergreifenden rechtlichen Bestimmungen ergeben. 4.1.1.1

Datenschutzrechtliche Regelungen (BDSG)

Unterlagen, aufbewahrt in jeglicher Form und Art, unterliegen, sofern personenbezogene Informationen in die Unterlagen einbezogen werden, dem Datengeheimnis und weiteren datenschutzrechtlichen Anforderungen (vgl. [ARO 07, S. 56]). In § 3a Bundesdatenschutzgesetz [BDSG] werden datenschutzrechtliche Grundanforderungen an Datenverarbeitungssysteme normiert: „Gestaltung und Auswahl von Datenverarbeitungssystemen haben sich an dem Ziel auszurichten, keine oder so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu nutzen. Insbesondere ist von den Möglichkeiten der Anonymisierung und Pseudonymisierung Gebrauch zu machen, soweit dies möglich ist und der Aufwand in einem angemessenen Verhältnis zu dem angestrebten Schutzzweck steht.“ Personenbezogene Daten sind vor allem in den aufzubewahrenden Dokumenten sowie den dazu gehörenden Metadaten vorhanden. Für die Gestaltung der Aufbewahrungssysteme folgt daraus zum Einen, dass für die Verwaltung und Sicherung der Dokumente ein Zugriff auf die Dokumente möglichst gering gehalten werden soll. Zum Anderen soll die Gestaltung der Metadaten so vorgenommen werden, dass dabei möglichst wenig personenbezogene Daten verwendet werden. Datenerhebende und –verarbeitende Stellen sind gesetzlich dazu verpflichtet, technisch-organisatorische Schutzvorkehrungen zu treffen, um die Rechte der Betroffenen zu wahren. Dazu gehört insbesondere gemäß Anlage zu § 9 Satz 1 BDSG das Treffen von Maßnahmen, die geeignet sind, zu gewährleisten, • „dass die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können, und dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können“, • „dass personenbezogene Daten bei der elektronischen Übertragung oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können…“, • „dass nachträglich überprüft und festgestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind…“ Für die langfristige vertrauenswürdige Aufbewahrung personenbezogener Daten bedeutet das, dass durch organisatorische und technische Maßnahmen sicher zu stellen ist, dass nicht autorisierte Zugänge zu und Zugriffe auf schützenswerte Daten zuverlässig verhindert werden, Informationen und Daten weder vorsätzlich noch fahrlässig unbemerkt und in unzulässiger Weise manipuliert werden können, Veränderungen daran protokolliert werden und ein unwiederbringlicher Verlust schützenswerter Informationen und Daten ausgeschlossen werden kann. Der Einsatz von kryptographischen Verschlüsselungstechniken sowie die strikte logische oder auch physikalische Trennung schützenswerter Daten und Informationen sind hierfür geeignete Instrumente. (A4.1-1) Hieraus folgt, dass ein zu dieser Richtlinie konformes Archivsystem imstande sein muss, dem Trennungsgebot nach § 9 BDSG sowohl mit der Aufbewahrung verschlüsselter Informationen und Daten, wie mit der Möglichkeit „mandantenfähiger“ Systemlösungen mit einer strikten logischen

20

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

und/oder physikalischen Trennung der gespeicherten Daten und einer kontrollierten Zugriffsberechtigung unter Einbeziehung der erforderlichen Protokollierung auf die gespeicherten Daten und Informationen auf der Ebene der externen, d. h. dem Archivsystem vorgelagerten IT-Fachanwendungen, Rechnung zu tragen. 4.1.1.2

Signaturrechtliche Regelungen (SigG, SigV)

Die Aufbewahrung elektronischer Dokumente und Daten dient neben der Sicherstellung der Verfügbarkeit der elektronischen Informationen als Grundlage für eine sachgerechte Weiterverwendung insbesondere auch dem Nachweis ordnungsgemäßen Handelns und der Beweiserhaltung der in den Dokumenten niedergelegten Rechtsansprüche und Pflichten. Wesentliche Anforderungen an die Aufbewahrung elektronischer Unterlagen für beweisrechtliche Zwecke sind vor allem die Nachweisbarkeit der Echtheit (Authentizität) und der Vollständigkeit der aufbewahrten Dokumente und Daten für die Zeit der gesetzlich vorgeschriebenen Aufbewahrungsdauer (siehe auch [SFD 06, S. 54]). Ein Dokument wird als authentisch angesehen, „wenn es das ist, was es vorgibt zu sein, und wenn es frei von Verfälschung oder unerlaubter Veränderung ist“ [SFD 06, S. 59]. Die Prüfung der Authentizität eines Dokuments umfasst dabei nicht nur die zweifelsfreie Feststellung des Ausstellers eines Dokuments, sondern darüber hinaus auch die Beantwortung der Frage, ob das vorliegende Dokument seit seiner Erstellung nicht verändert wurde, also integer ist. Können die Integrität und Authentizität eines elektronischen Dokuments nicht zweifelsfrei festgestellt werden, bestehen berechtigte Unsicherheiten über die Glaubwürdigkeit der in dem Dokument niedergelegten Inhalte. Die beabsichtigten Rechtsfolgen oder Pflichten lassen sich damit nicht mehr sicher begründen. Die Gewährleistung der Authentizität und Integrität von elektronischen Daten und Dokumenten und die zuverlässige Identifizierung von deren Urheber bilden somit das grundlegende Fundament des elektronischen Rechts- und Geschäftsverkehrs. Elektronische Daten und Dokumente sind an sich flüchtig und können spurenlos verändert werden. Aus einem elektronischen Dokument kann daher auch nicht ohne weiteres auf seinen tatsächlichen Aussteller geschlossen werden. Um die Integrität und Authentizität elektronischer Dokumente und Daten zweifelsfrei feststellen zu können, bedarf es deshalb zusätzlicher technischer Sicherungsmittel. Elektronische Signaturen sind nach heutigem Kenntnisstand das am besten geeignete Sicherungsmittel, um die Integrität und Authentizität von elektronischen Daten zu gewährleisten.5 Das Signaturgesetz [SigG] und die Signaturverordnung [SigV] regeln die grundsätzlichen technischen Rahmenbedingungen für diese elektronischen Sicherungsmittel. Dem trägt auch die Neufassung des § 371a Abs. 1 Satz 1 und Abs. 2 Satz 1 der Zivilprozessordnung [ZPO] über die Beweiskraft privater und öffentlicher Urkunden Rechnung. Nach § 371a Abs. 1 Satz 1 ZPO wird von der Vorlage einer qualifizierten elektronischen Signatur auf den Anschein der Echtheit des Dokuments geschlossen, sofern die Signatur dem Dokument zweifelsfrei zugerechnet werden kann.6 Für qualifiziert signierte öffentliche elektronische Dokumente gilt nach § 371a Abs. 2 Satz 2 ZPO darüber hinaus die Vermutung der Echtheit nach § 437 Abs. 1 ZPO, sofern das Dokument nach Form und Inhalt sich als öffentliches Dokument darstellt. Der Anschein bzw. die Vermutung der Echtheit signierter elektronischer Dokumente bezieht sich dabei sowohl auf die Zurechnung des Dokuments zu dem Signaturschlüssel-Inhaber als auch auf die in dem Dokument niedergelegten Tatsachen oder Informationen. Tatbestandsvoraussetzung des § 371 Abs. 1 S. 2 ZPO ist, dass es sich um eine qualifizierte elektronische Signatur handelt. Dadurch wird klargestellt, dass die Beweiserleichterung bei einfachen oder fortgeschrittenen Signaturen nicht in Betracht kommt. Wesentliche Voraussetzung für die Bestimmung des Beweiswertes eines elektronisch signierten Dokuments ist die Durchführung einer Signaturprüfung. Für die langfristige Sicherstellung der Beweiskraft elektronischer Signaturen sind daher Sicherungsmaßnahmen notwendig, die geeignet sind, die Authentizität und Integrität der elektronisch si5

6

Signaturen sind natürlich nur dazu geeignet, die Integrität und Authentizität nachzuweisen, jedoch nicht, sie zu erhalten. Veränderungen können mit Signaturen nicht verhindert sondern nur erkannt werden. Die Nutzung von speziellen Speichermedien bringt jedoch keinen nennenswerten Vorteil, da die Administratoren immer in der Lage sind, auch solche Speicher zu manipulieren. § 371a Abs. 1 Satz 2: Der Anschein der Echtheit einer in elektronischer Form vorliegenden Erklärung, der sich auf Grund der Prüfung nach dem Signaturgesetz ergibt, kann nur durch Tatsachen erschüttert werden, die ernstliche Zweifel daran begründen, dass die Erklärung vom Signaturschlüssel-Inhaber abgegeben worden ist.

Bundesamt für Sicherheit in der Informationstechnik

21

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

gnierten Daten dauerhaft, mindestens aber für die Zeit der gesetzlich vorgeschriebenen Aufbewahrungsfristen, zu gewährleisten. Dies gilt insbesondere auch dann, wenn festgestellt wird, dass die den elektronischen Signaturen zugrunde liegenden Algorithmen und Parameter keine ausreichende Sicherheit mehr für den vorgeschriebenen oder gewünschten Aufbewahrungszeitraum bieten und damit einen neuen Integritätsschutz i. S. von § 17 SigV erforderlich machen. Hinsichtlich der Sicherung der Authentizität der signierten Daten muss vor allem langfristig nachweisbar sein und bleiben, wem die Signatur zugerechnet werden kann, d. h., der Urheber der signierten Daten muss eindeutig erkennbar sein. Die für eine langfristige Aufbewahrung elektronischer Daten erforderlichen Vorkehrungen zur Sicherung der Authentizität sind im Signaturgesetz nur zum Teil enthalten. Fehlende Vorkehrungen müssen daher aus einer sicherheitstechnischen Betrachtung und den beweisrechtlichen Anforderungen an eine Prüfung von Zertifikaten gemäß Signaturgesetz entwickelt werden. Die Zurechnung der Signatur erfolgt über Nutzerzertifikate mit dem in § 7 SigG bestimmten Inhalt. Ein solches Zertifikat ist die Bestätigung der Zuordnung eines zuverlässig identifizierten Signaturschlüssel-Inhabers zum Signaturprüfschlüssel, mit dessen korrespondierenden Signaturschlüssel die Signatur erstellt wurde. Handelt es sich – wie im § 7 SigG beschrieben – um ein qualifiziertes Zertifikat, und war es darüber hinaus zum Signaturerstellungszeitpunkt gültig, kann der Nachweis der Authentizität grundsätzlich erbracht werden, sofern eine Prüfung des Zertifikats gemäß Signaturgesetz erfolgreich verlaufen ist. Für den langfristigen Nachweis der Authentizität signierter Daten ist daher wesentlich, dass die Existenz des Nutzerzertifikats sowie seine Gültigkeit zum Signaturerstellungszeitpunkt nachweisbar bleiben. Eine notwendige Voraussetzung für eine Prüfung eines qualifizierten Zertifikats gemäß Signaturgesetz ist es, dass das Zertifikat überhaupt vorliegt. Ein Zertifizierungsdiensteanbieter hat die von ihm ausgestellten Zertifikate gemäß § 5 Abs. 1 Satz 2 SigG über öffentlich erreichbare Kommunikationsverbindungen jederzeit nachprüfbar und mit Zustimmung des Signaturschlüssel-Inhabers auch abrufbar zu halten. Die Nachprüfbarkeit setzt voraus, dass das Zertifikat in dem vom Zertifizierungsdiensteanbieter gemäß § 4 Abs. 1 SigV zu führenden Zertifikatsverzeichnis vorhanden ist. Eine Signaturprüfung nach Signaturgesetz erfordert daher, zusätzlich zur Überprüfung der technischen Gültigkeit der Signatur, also der Überprüfung, ob die Signatur im kryptographischen Sinne korrekt verifiziert werden kann und die Signatur und die signierten Daten technisch zueinander gehören, stets auch eine Abfrage beim Zertifizierungsdiensteanbieter, ob das der Signatur zugrunde liegende Zertifikat zum angegebenen Zeitpunkt vorhanden, gültig und nicht gesperrt war. Der Zertifizierungsdiensteanbieter hat diese Auskunft gemäß § 5 Abs. 1 Satz 2 SigG über öffentlich erreichbare Kommunikationsverbindungen zu erteilen. Da die Authentizität der Auskunft nachweisbar sein muss, werden Auskünfte der Zertifizierungsdiensteanbieter üblicherweise mit einer qualifizierten elektronischen Signatur versehen. Allerdings sind diese Pflichten des Zertifizierungsdiensteanbieters zweifach beschränkt. Zunächst kann der Signaturschlüssel-Inhaber gemäß § 5 Abs. 1 Satz 3 SigG bestimmen, dass sein Zertifikat nicht abrufbar sein soll. Dem Zertifizierungsdiensteanbieter ist in diesem Fall nicht gestattet, das Zertifikat zum Abruf bereitzustellen. Der Signaturschlüssel-Inhaber selbst muss das Zertifikat dem bestimmungsgemäßen Empfänger der von ihm signierten Daten auf andere Weise zur Verfügung stellen, beispielsweise dadurch, dass das Zertifikat der Signatur beigefügt wird. Die Verpflichtung des Zertifizierungsdiensteanbieters ist aber auch zeitlich begrenzt. Nach § 4 Abs. 1 SigV besteht die gesetzliche Verpflichtung nur für einen Zeitraum von bis zu fünf Jahren nach dem Schluss des Jahres, in dem die Gültigkeit des Zertifikats abläuft. Dieser Zeitraum verlängert sich um weitere 25 Jahre, falls der Zertifizierungsdiensteanbieter akkreditiert ist (vgl. § 4 Abs. 2 SigV). Sofern ein Zertifizierungsdiensteanbieter mit Anbieterakkreditierung seinen Betrieb einstellt, ist die Bundesnetzagentur (BNetzA) verpflichtet, die Dokumentation zu den ausgegebenen Zertifikaten zu übernehmen – nicht jedoch, den technischen Betrieb fortzuführen (vgl. § 15 Abs. 6 SigG). Eine automatisierte Prüfung wird somit bspw. nicht mehr ohne weiteres möglich sein. Bei qualifizierten Signaturverfahren im Zusammenhang mit Zertifizierungsdiensteanbieter mit Anbieterakkreditierung sind Zertifikate und Dokumentation nach §§ 4 Abs. 2 und 8 Abs. 3 SigV 30 Jahre nach Ablauf des Jahres

22

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

der Gültigkeit des Zertifikats aufzubewahren.7 Im Falle der vorherigen Einstellung des Betriebs übernimmt dies ein anderer Zertifizierungsdiensteanbieter oder die BNetzA. Aus der gesetzlichen Beschränkung der Aufbewahrungspflicht des Zertifizierungsdiensteanbieters ergibt sich somit die Obliegenheit bzw. Verpflichtung des Empfängers signierter Daten, selbst dafür zu sorgen, dass er das Zertifikat und die zugehörigen Prüfinformationen8 vorlegen kann, wenn sie für ein Beweisbegehren benötigt werden. In der Regel wird der Empfänger daher die Vorkehrung treffen, nicht nur die signierten Daten und die Signatur, sondern auch die erforderlichen Zertifikate und Prüfinformationen, wenn schon nicht beim Eingang oder der Ausstellung signierter Daten, so doch dann spätestens bei der Ablage im elektronischen Archiv, einzuholen und gemeinsam mit den signierten Daten zu speichern.9 Für elektronische Signaturen basierend auf einem qualifizierten Zertifikat sind für den schlüssigen und nachvollziehbaren Nachweis der Existenz und der Gültigkeit des Zertifikats zum Signaturerstellungszeitpunkt die Vorlage und technische Verifikation folgender Daten erforderlich (s. [ARO 07], S. 73): •

das Nutzerzertifikat und ggf. Attributzertifikat mit Zertifikatskette bis zum Wurzelzertifikat,

•

eine OCSP-Auskunft10 des Zertifizierungsdiensteanbieters (gegebenenfalls in Kombination mit einer Sperrliste) über die Existenz und die Gültigkeit des Zertifikats, ebenfalls mit Zertifikatskette bis zum Wurzelzertifikat,

•

ein qualifizierter Zeitstempel bezogen auf die Signatur ebenfalls mit Zertifikatskette bis zum Wurzelzertifikat.

Dabei ist es dem Anwender überlassen, wo er die Daten aufbewahrt. Er kann diese unmittelbar der Signatur oder den signierten Daten beifügen oder aber in einer gesonderten Objektdatenbank vorhalten und über eine eindeutige Referenzierung einen Zugriff auf diese zur Sicherstellung der Verfügbarkeit gewährleisten. Zu den für die langfristige Prüfbarkeit erforderlichen Sicherheitsmaßnahmen gehört auch die Signaturerneuerung nach § 17 SigV, die zur Gewährleistung der Integrität erforderlich ist. Gemäß § 17 SigV sind Daten mit einer qualifizierten elektronischen Signatur neu zu signieren, wenn sie für längere Zeit benötigt werden, als der Signaturalgorithmus als geeignet (technisch sicher) beurteilt werden kann. Da auch Verifikationsdaten elektronische Signaturen enthalten, unterliegen sie ebenso dem Erfordernis der Neusignierung nach § 17 SigV. Erst durch ihre Einbeziehung in die Neusignierung kann die Unversehrtheit und damit Echtheit eines Zertifikats, einer Gültigkeitsabfrage oder eines Zeitstempels langfristig überprüft werden. § 17 SigV begründet allerdings keine Rechtspflichten. Der Zweck dieser technischen Vorschrift ist darauf beschränkt, ein geeignetes Verfahren für eine langfristige Datensicherung zu beschreiben. Der Zertifizierungsdiensteanbieter hat jedoch den Signaturschlüssel-Inhaber gemäß § 6 Abs. 1 Satz 2 SigG in Verbindung mit § 6 Nr. 5 SigV darauf hinzuweisen, dass Daten mit einer qualifizierten elektronischen Signatur bei Bedarf gemäß § 17 SigV neu zu signieren sind. Die Anwendung des Verfahrens ist damit grundsätzlich als eine Obliegenheit im Umgang mit signierten Daten anzusehen. Die Obliegenheit besteht allerdings unabhängig vom Hinweis des Zertifizierungsdiensteanbieters. Auch wenn § 17 SigV somit grundsätzlich lediglich eine Obliegenheit begründet, kann eine Rechtspflicht zur Anwendung des § 17 SigV bestehen. Diese muss sich dann jedoch aus anderen Gesetzen, Normen oder aus vertraglichen Regelungen ergeben. Eine Rechtspflicht zur Anwendung des § 17 7 8

9

10

Für fortgeschrittene Signaturverfahren sind keine Vorhaltefristen vorgesehen. „Prüfinformationen“ sind die Ergebnisse einer Gültigkeitsprüfung einer Signatur und aller damit in Zusammenhang stehenden Zertifikate, die die Gültigkeit der Signatur und der Zertifikate zu einem gewissen Zeitpunkt (normalerweise dem Zeitpunkt der Signaturerstellung) angeben. Die Auskunft des Zertifizierungsdiensteanbieters enthält neben den Angaben darüber, ob das Zertifikat im Verzeichnis vorhanden ist, auch eine Information über den Status des Zertifikats. Sperrungen hat der Zertifizierungsdiensteanbieter gemäß § 7 Abs. 2 SigV im Zertifikatsverzeichnis mit Angabe von Datum und Uhrzeit kenntlich zu machen. Da der Sperrstatus für eine Prüfung eines Zertifikats nach Signaturgesetz benötigt wird, sollten die Auskünfte auch aus diesem Grund unverzüglich einholt, geprüft und gespeichert werden. Online Certificate Status Protocol (OCSP), Client-Server Protokoll für die Online Statusabfrage eines Zertifikats bei einem Zertifizierungsdiensteanbieter, http://www.ietf.org/rfc/rfc2560.txt

Bundesamt für Sicherheit in der Informationstechnik

23

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

SigV besteht immer dann, wenn der Empfänger auf Grund von Gesetzen oder Verträgen verpflichtet ist, den besonderen Beweiswert qualifizierter elektronischer Dokumente zu erhalten. Die Signaturverordnung sieht in § 17 SigV ein Verfahren vor, wie und wann die erforderliche Neusignierung zu erfolgen hat: „Daten mit einer qualifizierten elektronischen Signatur sind nach § 6 Abs. 1 Satz 2 des Signaturgeset­ zes neu zu signieren, wenn diese für längere Zeit in signierter Form benötigt werden, als die für ihre Erzeugung und Prüfung eingesetzten Algorithmen und zugehörigen Parameter als geeignet beurteilt sind. In diesem Falle sind die Daten vor dem Zeitpunkt des Ablaufs der Eignung der Algorithmen oder der zugehörigen Parameter mit einer neuen qualifizierten elektronischen Signatur zu versehen. Diese muss mit geeigneten neuen Algorithmen oder zugehörigen Parametern erfolgen, frühere Signaturen einschließen und einen qualifizierten Zeitstempel tragen.“ Droht der Verlust der Sicherheitseignung der verwendeten Algorithmen und der zugehörigen Parameter, so sind die Daten und alle bestehenden Signaturen also gemäß § 17 SigV erneut zu signieren. Dies ist die Grundlage der Beweiswerterhaltung elektronischer Dokumente. Mit § 17 SigV wurde eine Norm geschaffen, die den Rahmen für eine technische Lösung umreißt, die den Anforderungen an die Beweiswerterhaltung genügt. Intention des vom Gesetzgeber normierten Verfahrens ist die fortdauernde Sicherstellung der Integrität und Authentizität des ursprünglich signierten Dokuments. Nach vorherrschender Rechtsmeinung (siehe hierzu [ARO 07], Kap. 4.2.1.1) ist die durch § 17 SigV geforderte erneute qualifizierte elektronische Signatur keine (erneute) Willenserklärung, sondern ein Sicherungsmittel für vorhandene Willenserklärungen. Das Ziel des Verfahrens ist es, die Integrität einer qualifizierten elektronischen Signatur auch dann noch feststellen so können, wenn die mathematische Signaturprüfung aufgrund mangelnder Sicherheitseignung der verwendeten Algorithmen nicht mehr geeignet ist, die Integrität der Signatur zu belegen. Um sicherzustellen, dass die Echtheit qualifizierter elektronischer Signaturen − trotz später möglicherweise bekannt werdender Sicherheitsmängel − auf Dauer nachweisbar ist, wird eine Integritätssicherung benötigt, die die Signaturen zu einem Zeitpunkt „konserviert“, zu dem diese Mängel im Nachhinein als noch nicht relevant anzusehen sind. Diese Integritätssicherung muss den Nachweis darüber erbringen können, dass die Signatur und die signierten elektronischen Daten bereits zu diesem Zeitpunkt vorlagen. Die Integritätssicherung muss daher die Daten und die Signatur umfassen, und die Dokumentation des Zeitpunktes muss durch einen vertrauenswürdigen Dritten erfolgen, z. B. durch einen Zertifizierungsdiensteanbieter. Qualifizierte Zeitstempel gemäß Signaturgesetz können genau diesem Zweck dienen. Ein qualifizierter Zeitstempel ist gemäß § 2 Nr. 14 SigG die elektronische Bescheinigung eines Zertifizierungsdiensteanbieters darüber, dass ihm bestimmte elektronische Daten zu einem bestimmten Zeitpunkt vorgelegen haben. Die aktuelle Fassung des Signaturgesetzes schreibt nicht mehr vor, dass ein qualifizierter Zeitstempel eine qualifizierte elektronische Signatur enthalten muss. Damit ist ein qualifizierter Zeitstempel alleine nicht ausreichend, eine Neusignierung durchzuführen. Ein qualifizierter Zeitstempel kann jedoch eine qualifizierte elektronische Signatur enthalten. Wird ein solcher signierter Zeitstempel für die Neusignatur verwendet, ist nach gängiger Rechtsauffassung eine weitere Signatur für die Beweiswerterhaltung weder notwendig noch sinnvoll (siehe dazu [SFD 06], S. 178 ff.). Die erneute Signatur muss rechtzeitig, d. h. vor Ablauf der Sicherheitseignung der verwendeten Algorithmen und zugehörigen Parameter mit neuen sicherheitsgeeigneten Algorithmen erfolgen. Entsprechende Übersichten geeigneter Algorithmen werden von der BNetzA nach Eignungsfeststellung durch das BSI veröffentlicht. Die Neusignierung muss alle vorhandenen Signaturen umschließen. Nur so lässt sich die Gesamtstruktur des Dokuments und der dazugehörigen Signaturen und Informationen erhalten. Da die Neusignierung lediglich als Sicherungsmittel dient, kann die (Neu-)Signatur beliebig viele Daten umschließen. Es muss sich jedoch beweisen lassen, dass ein bestimmtes Dokument in der Umschließung enthalten ist, das heißt (gemeinsam mit anderen) erneut signiert wurde. Zeitstempel sind technisch gesehen in der Regel ebenfalls elektronische Signaturen, deren sicherheitstechnische Eignung im Laufe der Zeit verloren gehen kann. Bevor dies geschieht, müssen diese Zeitstempel daher ebenfalls konserviert werden, indem ein erneuter Zeitstempel eingeholt wird.

24

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

§ 17 SigV unterscheidet nicht danach, ob der Hash-Algorithmus, der Signatur-Algorithmus oder beide ihre Eignung verlieren. Der qualifizierte Zeitstempel muss sich aber nur dann sowohl auf die signierten Daten als auch auf die Signatur beziehen, wenn das verwendete Hash-Verfahren unsicher zu werden droht. Falls der Hash-Algorithmus noch geeignet ist, muss sich der zu bildende Zeitstempel nur auf die Signatur beziehen. Dies reicht aus, da die Daten weiterhin zuverlässig mit der alten Signatur verknüpft sind. Sicherheitstechnisch gesehen ist es nicht erforderlich, für die Daten einen neuen Hashwert zu bilden, um diesen dann neu zu signieren. Um eine wirtschaftliche Signaturerneuerung zu ermöglichen, ist es zudem nach § 17 SigV nicht erforderlich, für jedes elektronische Datum, das erneut signiert werden muss, einen eigenen Zeitstempel einzuholen. Ein Zeitstempel darf sich vielmehr auf beliebig viele signierte Daten beziehen. Sicherheitstechnisch gesehen ist dies ohne weiteres möglich. Die Wirkung eines Zeitstempels als Mittel zur Integritätssicherung ist nicht davon abhängig, wie viele Signaturen gleichzeitig konserviert werden. Auch wurde bereits in der amtlichen Begründung zu § 18 SigV 1997 ausgeführt, dass „für eine beliebige Anzahl signierter Daten eine (übergreifende) neue digitale Signatur …“ angebracht werden kann. Die Neusignierung von Teilen eines elektronischen Archivs ist damit auch automatisiert möglich. Als automatisierte elektronische Signatur wird eine Signatur verstanden, die von einem automatischen Prozess ohne Mitwirkung eines Menschen erzeugt wird. Dabei wird davon ausgegangen, dass ein Mensch diesen Prozess zwar bewusst einleitet, er aber weder die zu signierenden Daten im Einzelfall vor der Signatur überprüft, noch den Signaturschlüssel im Einzelfall freischaltet. Die Erstellung qualifizierter elektronischer Signaturen oder qualifizierter Zeitstempel im Massenverfahren ist ebenfalls zulässig.11 4.1.1.3

Bundesarchivgesetz und Landesarchivgesetze

Alle öffentlichen Stellen des Bundes und der Länder sind gesetzlich verpflichtet, Unterlagen, die für die Aufgabenwahrnehmung nicht mehr benötigt werden, vor ihrer Vernichtung dem Bundes- bzw. Landesarchiv zur Übernahme als Archivgut des Bundes / des Landes anzubieten (vgl. §2 Abs. 1 BArchG und entsprechende Landesarchivgesetze). Diese Anbietungspflicht gilt selbstverständlich auch für elektronische Unterlagen. Da die Archivierung jedoch nicht Gegenstand dieser TR ist, wird auf die entsprechenden rechtlichen Anforderungen nicht näher eingegangen.12 Hinweis: Nach § 2 BArchG sind zunächst grundsätzlich alle Unterlagen von Bundesbehörden aufzubewahren; die bereichsspezifischen Regelungen nach BGB, HGB etc. stellen keine Löschungsermächtigung dar, sondern bezeichnen gesetzliche Mindestfristen für die Aufbewahrung. Die Entscheidung über die Aufbewahrungswürdigkeit (»Archivwürdigkeit«) steht nach § 3 BArchG allein dem Bundesarchiv im Benehmen mit den anbietenden Stellen des Bundes zu. Die Kriterien einer Entscheidung über den „bleibenden Wert“ ergeben sich nicht zwingend aus den fachrechtlichen Gründen für die Entstehung der Unterlagen

4.1.2

Sachbezogene rechtliche Rahmenbedingungen

Die Aufbewahrung elektronischer Daten und Dokumente erfolgt grundsätzlich nicht zum Selbstzweck. Vielmehr werden damit, unabhängig davon, ob die Aufbewahrung einer Pflicht genügt oder im eigenen Interesse vorgenommen wird, bestimmte Zwecke verfolgt. Diese Zwecke können einzeln oder kumulativ vorliegen und in den Sachzusammenhängen selbst, in denen die Daten und Dokumente erzeugt und verwendet werden, oder den geltenden rechtlichen Regelungen begründet sein. Für eine Vielzahl von Unterlagen hat der Gesetzgeber spezifische Regelungen hinsichtlich der Aufbewahrung getroffen. Nachfolgend (Kap. 4.1.2.1 bis 4.1.2.7) werden anhand von Auszügen aus [ARO 07, ebenda Kap. 4.3] für ausgewählte Dokumentarten, zu deren Erstellung und Aufbewahrung Personen, Unternehmen oder öffentliche Verwaltungen verpflichtet sind, die gesetzlich bestehenden Anforderungen beispielhaft beschrieben. 11 12

Siehe hierzu eingehend [ARO 07], Kap. 4.2.1.2 Siehe hierzu Kapitel 3.2.

Bundesamt für Sicherheit in der Informationstechnik

25

Vertrauenswürdige elektronische Langzeitspeicherung (VELS) 4.1.2.1

BSI TR 03125

Aufbewahrung elektronischer Rechnungen13

Sofern bei elektronischen Rechnungen die Umsatzsteuer gegenüber dem Finanzamt geltend gemacht werden soll, sind sie gemäß § 14 Abs. 3 [UStG] vom Rechnungsaussteller qualifiziert zu signieren. Die Signatur soll Fälschungen elektronischer Rechnungen und damit eine missbräuchliche Geltendmachung der Umsatzsteuer ausschließen und dient somit allein der Sicherung von Integrität und Authentizität der Daten. Zur Aufbewahrung elektronisch signierter Rechnungen, die nach § 14b UStG zehn Jahre aufzuheben sind, hat das BMF durch Schreiben vom 29.1.200414 die Anforderungen an die Aufbewahrung nach § 14b UStG konkretisiert. Danach hat der Aufbewahrungspflichtige bei elektronisch übermittelten signierten Rechnungen auch die Signatur als Nachweis über die Echtheit und Unversehrtheit der Daten aufzubewahren (TZ 70 des Schreibens).15 Nach TZ 76 sind für die Archivierung und Prüfbarkeit der signierten Rechnungen darüber hinaus die „Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen“ [GDPdU] zu berücksichtigen.16 Abschnitt II der GDPdU legt fest, wie qualifiziert signierte Unterlagen (z. B. elektronische Rechnungen nach § 14 Abs. 4 UStG) zu prüfen und in elektronische (technische) Archivsysteme einzubinden sind. Danach setzt eine jederzeitige Überprüfbarkeit des Originalzustands einer qualifiziert signierten Abrechnung unter anderem voraus, dass vor einer weiteren Verarbeitung der elektronischen Abrechnung die qualifizierte elektronische Signatur im Hinblick auf die Integrität der Daten und die Signaturberechtigung zu prüfen und das Ergebnis zu dokumentieren ist. Daneben sind der Signaturprüfschlüssel sowie das qualifizierte Zertifikat des Absenders der signierten Rechnung aufzubewahren. Darüber hinaus muss die Speicherung der elektronischen Abrechnung auf einem Datenträger erfolgen, der Änderungen nicht mehr zulässt. Bei einer Zwischenspeicherung auf einem änderbaren Datenträger muss das DV-System den Schutz vor Veränderungen sicherstellen. Zwar ist auch eine Transformation zulässig, doch sind in einem solchen Fall sowohl das ursprüngliche wie auch das neue Dokument aufzubewahren. Ebenfalls sind umfassende Protokollierungen der einzelnen Vorgänge vorzunehmen. 4.1.2.2

Aufbewahrung buchführungsrelevanter Unterlagen 17

Das Handels- und Steuerrecht sieht gemäß §§ 238 ff. HGB und §§ 140 ff. AO für Kaufleute umfassende Buchführungspflichten vor.18 Aus den Büchern müssen sich die Geschäftsvorfälle in ihrer Entstehung und Abwicklung verfolgen lassen und die Vermögenslage des Unternehmens ersichtlich sein. Damit soll der Kaufmann einen transparenten Überblick über seine wirtschaftliche Lage erhalten, die ihm zur Selbstkontrolle dient sowie eine Rechenschaft gegenüber Gläubigern und der Steuerbehörde ermöglicht. Die Buchführung ist damit die wesentliche Grundlage für die Nachvollziehbarkeit der steuerrechtlich relevanten Vorgänge und ihrer Kontrolle durch das zuständige Finanzamt. Aus diesen Zielsetzungen heraus ergeben sich auch die wesentlichen Anforderungen an Inhalt und Form der Buchführung und ihrer Aufbewahrung. Nach den Grundsätzen ordnungsgemäßer Buchführung (GoB) hat die Buchführung gemäß § 239 Abs. 2 HGB richtig und vollständig zu sein sowie auch zeitgerecht und geordnet zu erfolgen.19 Unter Zugrundelegung der GoB wird für die Langzeitspeiche13 14

15 16

17 18

19

26

S. [ARO 07], Kap. 4.3.1 Schreiben des BMF vom 29.1.2004 zur Umsetzung der Richtlinie 2001/115/EG (Rechnungsrichtlinie) und der Rechtsprechung des EuGH und des BFH zum unrichtigen und unberechtigten Steuerausweis durch das Zweite Gesetz zur Änderung steuerlicher Vorschriften (Steueränderungsgesetz 2003 –StÄndG 2003). Dies gilt auch dann, „wenn nach anderen Vorschriften die Gültigkeit dieser Nachweise bereits abgelaufen ist“. BMF-Schreiben vom 16.7.2001. Die Schreiben des Bundesministeriums für Finanzen sind Verwaltungsanweisungen ohne Rechtsnormcharakter. Sie binden zwar die Verwaltung, aber nicht die Gerichte, haben aber als Willensbekundung des BMF hohe Bedeutung. Sie bieten auch Leitlinien für die Hersteller und Betreiber von Buchführungs- und technischen Archivsystemen, da die Finanzbehörden sich bei der Prüfung grundsätzlich an diesen orientieren. S. [ARO 07], Kap. 4.3.2 Die handelsrechtliche Buchführungspflicht folgt aus dem allgemeinen Handelsrecht und den handelsrechtlichen Nebengesetzen. §§ 238 ff. HGB werden insbesondere durch §§ 150 AktG, §§ 41 ff. GmbHG, § 33 GenG und durch das Gesetz über die Rechnungslegung von bestimmten Unternehmen und Konzernen (PublG) ergänzt. Eine Buchführungspflicht kann sich darüber hinaus auch allgemein aus Gesetz oder Vertrag ergeben, insbesondere aus der Pflicht zur Verwaltung fremden Vermögens und Rechnungslegung hierüber. Die Grundsätze ordnungsgemäßer Buchführung sind ein unbestimmter Rechtsbegriff und ihre Rechtsnatur ist umstritten. Ihr Inhalt ist teilweise gesetzlich normiert, teilweise sind es ungeschriebene und sich aus dem Gewohnheitsrecht oder aus

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

rung von Dokumenten insbesondere verlangt, dass die Ordnungsmäßigkeit, Vollständigkeit und Sicherheit des Gesamtverfahrens gewährleistet ist. Die Buchführung muss vor Verlust von Daten gesichert sowie vor Veränderung, Verfälschung und vor Zugriffen Unberechtigter geschützt sein. Eine Dokumentation des Verfahrens und damit die Nachvollziehbarkeit und Prüfbarkeit der Buchführung müssen ebenso sichergestellt werden wie die Möglichkeit, einem sachverständigen Dritten anhand der Bücher innerhalb angemessener Zeit einen Überblick über die Geschäftsvorfälle und die Lage des Unternehmens zu vermitteln. Änderungen sind nach § 239 Abs. 3 HGB nur zulässig, wenn sie den ursprünglichen Inhalt und die Tatsachen späterer Änderung erkennen lassen. Die Form der Buchführung wird mit einigen Ausnahmen gemäß § 257 Abs. 3 HGB, § 147 Abs. 5 AO dem Buchführungspflichtigen überlassen. Die handels- und steuerrechtlichen Aufbewahrungsfristen sind in § 257 Abs. 4 HGB und § 147 Abs. 3 AO normiert. Sie sehen eine 10-jährige Aufbewahrungsfrist für Handelsbücher, Inventare, Eröffnungsbilanzen, Jahresabschlüsse, Lageberichte, Konzernabschlüsse, Konzernlageberichte, Arbeitsanweisungen und sonstige Organisationsunterlagen sowie Buchungsbelege vor (siehe Tabelle 2). Eine sechsjährige Aufbewahrungspflicht besteht hingegen für empfangene Handels- und aufbewahrungsbedürftige Geschäftsbriefe, Wiedergaben der abgesandten Handels- und Geschäftsbriefe und sonstige Unterlagen, soweit sie für die Besteuerung von Bedeutung sind. Die Aufbewahrungsfrist beginnt entsprechend § 257 Abs. 5 HGB und § 147 Abs. 4 AO mit dem Ablauf des Kalenderjahres, in dem die Unterlagen und Aufzeichnungen entstanden oder zugegangen sind oder die letzte Eintragung in das Handelsbuch erfolgt ist. Aufbewahrungspflichtige Unterlagen Handelsbücher, Inventare, Eröffnungsbilanzen, Jahresabschlüsse, Lageberichte, Konzernabschlüsse, Konzernlageberichte sowie die zu ihrem Verständnis erforderlichen Arbeitsanweisungen und sonstigen Originalunterlagen

Aufbewahrungsfrist 10 Jahre

Empfangene Handelsbriefe

6 Jahre

Wiedergaben der abgesandten Handelsbriefe

6 Jahre

Buchungsbelege

10 Jahre

Tabelle 2: Aufbewahrungspflichtige Unterlagen nach HGB, Quelle [SBR 04], S. 16

Um den Kaufmann sowie den Steuerpflichtigen nicht zu einer kostenintensiven Aufbewahrung sämtlicher Unterlagen zu zwingen, lassen sowohl das Handels- als auch das Steuerrecht eine Erstellung der Buchführung sowie ihrer Aufbewahrung nach §§ 239 Abs. 4, 257 Abs. 3 HGB sowie §§ 146 Abs. 5, 147 Abs. 2 AO „auch als Wiedergabe auf einem Bildträger oder auf einem anderen Datenträger" zu20, wobei die Buchführung den Grundsätzen ordnungsgemäßer Buchführung (GoB) entsprechen muss.21 Ergänzt und konkretisiert wurden diese Anforderungen erstmals durch die Grundsätze der Speicherbuchführung (GoS)22, die durch die Grundsätze ordnungsgemäßer datenverarbeitungsgestützter Buchführungssysteme (GoBS) ersetzt wurden und Anforderungen insbesondere an die Datensicherheit stellen.23 Konkret zu ergreifende Maßnahmen zur Umsetzung der Anforderungen zur Erfüllung der Buchführungspflichten beinhalten die Regelungen nicht. In 5.6 der Anlage zu den GoBS heißt es lediglich:

20

21

22

dem Handelsbrauch ergebende Grundsätze. Sie stellen somit Regeln dar, die einzuhalten sind, um einen gesetzlichen Zweck (bspw. eine ordnungsgemäße Buchführung) zu erreichen. Die Zulässigkeit der alleinigen bildlichen Wiedergabe besteht mit der Einschränkung, dass Eröffnungsbilanzen, Jahresabschlüsse und Konzernabschlüsse im Original aufzubewahren sind. Die Zulassung der Wiedergabe auf Bild- oder andere Datenträger wurde auf Grund des Wandels der wirtschaftlichen Verhältnisse wie auch der fortschreitenden technologischen Entwicklung 1977 eingeführt. BStBl. I 1978, 250.

Bundesamt für Sicherheit in der Informationstechnik

27

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

„Da das ,Wie' der Datensicherheit von dem jeweils gegebenen Stand der EDV­Technik abhängt, er­ gibt sich aus der technischen Entwicklung für das Unternehmen die Notwendigkeit, ihr Datensicher­ heitskonzept den jeweils aktuellen Anforderungen und Möglichkeiten anzupassen.“ Es obliegt daher dem Buchführungspflichtigen, aus diesen allgemeingültigen Anforderungen die für ihn erforderlichen Maßnahmen zur Erfüllung einer ordnungsgemäßen Buchführung abzuleiten. Der Einsatz elektronischer Signaturen zur Sicherung seiner Unterlagen liegt somit im Ermessen des Buchführungspflichtigen. Eine weitere Konkretisierung erfolgte diesbezüglich auch nicht durch II 2 der „Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen“ (GDPdU). Die dort festgelegten Anforderungen an die Prüfbarkeit aufbewahrungspflichtiger, digitaler Unterlagen bestätigen nur nochmals die Notwendigkeit der unveränderbaren Speicherung durch den Einsatz geeigneter Datenträger und Datenverarbeitungssysteme. Parallele Vorschriften zu den handels- und steuerrechtlichen Regelungen zur Aufbewahrung von buchführungsrelevanten Unterlagen im Privatrecht, finden sich für den öffentlichen Bereich in den Haushaltsordnungen. Dabei ist zwischen der Bundes- und der Landesebene zu unterscheiden. Übergreifende haushaltsrechtliche Regelungen für Bund und Länder sind im Gesetz über die Grundsätze des Haushaltsrechts des Bundes und der Länder (HGrG) normiert. Sowohl beim Erlass der Bundeshaushaltsordnung als auch den jeweiligen Landeshaushaltsordnungen müssen diese Grundsätze berücksichtigt werden. Während § 33 HGrG die grundsätzliche Pflicht zur Buchführung regelt, verweist § 33a HGrG zur näheren Ausgestaltung auf die Grundsätze der ordnungsgemäßen Buchführung und Bilanzierung nach den Vorschriften des Handelsgesetzbuchs. Es findet sich zwar zum Beispiel in der Bundeshaushaltsordnung kein expliziter Verweis auf die Vorschriften des Handelsgesetzbuchs, dennoch ist davon auszugehen, dass sowohl in der Bundeshaushaltsordnung als auch in den Landeshaushaltsordnungen und den jeweils konkretisierenden Verwaltungsvorschriften keine Regelungen enthalten sind, die denen des Handelsgesetzbuchs widersprechen. Daher kann auf die allgemeinen Ausführungen zur Aufbewahrung buchführungsrelevanter Unterlagen im Privatrecht verwiesen werden. Unterschiede ergeben sich allerdings zum Beispiel hinsichtlich der konkreten Aufbewahrungsfristen, die betreffend der haushaltsrelevanten Unterlagen in den jeweiligen Verwaltungsvorschriften normiert sind. 4.1.2.3

Aufbewahrung von Personalunterlagen24

Besonders im Personalbereich führen Aufzeichnungs-, Melde- und Aufbewahrungspflichten zu einer Fülle von Dokumenten. Den Unternehmen werden zahlreiche unmittelbar sowie mittelbar normierte Aufzeichnungspflichten25 und hinzutretende Aufbewahrungspflichten26 auferlegt. Die Aufbewahrungspflicht kann einerseits ausdrücklich normiert sein, andererseits ergibt sich dies aber auch mittelbar aus der Aufzeichnungspflicht.27 Denn diese kann durch die jeweilige Aufsicht führende Stelle28 nur kontrolliert werden, wenn die Aufzeichnungen aufbewahrt werden, bis eine Kontrolle stattgefunden hat. Die Aufbewahrung erfolgt zu verschiedenen Zwecken, die einzeln oder kumulativ auftreten können. Eine große Zahl der Aufbewahrungspflichten dient der Durchführung von Kontrollen. Erforderlich ist jeweils, dass hierfür eine Rechtsgrundlage in Form eines Gesetzes oder einer hierauf beruhenden Rechtsverordnung besteht, die Zweck, Umfang und Verwendung der Aufzeichnungen regelt. Eine wichtiges Beispiel für eine kontrollorientierte Aufzeichnungspflicht ist gemäß § 6 Arbeitsschutzgesetz [ArbSchG] die Dokumentation der Tätigkeiten nach dem Arbeitsschutzgesetz, insbesondere die Erfassung bestimmter Betriebsunfälle gemäß § 6 Abs. 2 ArbSchG. Die Aufbewahrung dient hier der Kontrolle durch die zuständige Behörde.29 23

24 25 26 27 28

29

28

Als Verwaltungsanweisungen sind sie zwar lediglich für die Verwaltung bindend, stellen indirekt jedoch Leitlinien für den Aufbewahrungspflichtigen dar, da die Verwaltung sich bei der Prüfung an diesen Anweisungen grundsätzlich orientiert. S. [ARO 07], Kap. 4.3.3 So z. B. in § 16 Abs. 2 ArbZG, § 2 Abs. 1 Satz 1 NachwG. § 7 Abs. 2 Satz 4 AÜG; § 39b Abs. 1 Satz 2 EStG. § 6 ArbSchG Wie z. B. die Bundesagentur für Arbeit (§ 16 Abs. 3 i.V.m. § 16 Abs. 1 Nr. 6 AÜG) oder die Ämter für Arbeitsschutz, die Gewerbeaufsichtsämter oder Berufsgenossenschaften. Ämter für Arbeitsschutz, Gewerbeaufsichtsämter oder Berufsgenossenschaften

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

In Bezug auf die arbeitsvertraglichen Unterlagen trifft den Arbeitgeber über die steuerlichen und sozialversicherungsrechtlichen Vorschriften hinaus keine Pflicht zur Aufbewahrung. Die Art und Weise der Aufbewahrung überlässt der Normgeber in vielen Fällen der jeweiligen aufbewahrungspflichtigen Stelle. So verlangt § 7 Abs. 2 Satz 4 AÜG die Aufbewahrung von Geschäftsunterlagen und verlangt in § 7 Abs. 2 Satz 3 AÜG eine Glaubhaftmachung in sonstiger Weise. Sofern eine besondere Form nicht vorgeschrieben ist, gilt die Regel, dass aus den aufbewahrten Dokumenten hervorgehen muss, dass der Verpflichtete die jeweiligen rechtlichen Pflichten erfüllt hat. Für die Kündigung und den Auflösungsvertrag ist gemäß § 623 BGB die elektronische Form ausdrücklich ausgeschlossen. Dies führt dazu, dass auch die spätere Aufbewahrung in elektronischer Form zumindest zeitweise nur kumulativ zum gedruckten Original erfolgen darf, damit die Einhaltung der Form nachgewiesen werden kann. Nach § 14 Abs. 4 TzBfG i.V.m. § 126 Abs. 3 BGB genügt für die Befristung eines Arbeitsvertrages die elektronische Form.110 § 2 Abs. 1 Satz 3 NachwG schließt allerdings die elektronische Form für den Nachweis der wesentlichen Vertragsbedingungen nach dem Nachweisgesetz aus. Zu den wesentlichen Vertragsbedingungen nach dieser Vorschrift gehören auch die Vereinbarungen zur Befristung. Demnach ist ein Abschluss der Befristung in elektronischer Form zwar möglich, durch die Anforderungen des Nachweisgesetzes wird aber die Aufbewahrung in schriftlicher Papierform notwendig. Die Fristen für die Aufbewahrung sind teilweise nach Jahren bemessen 30, teilweise richten sie sich nach der Betriebszugehörigkeit des Mitarbeiters31, dessen Lebensalter nach der Pensionsgrenze32, der Nutzungsdauer von Anlagen und Geräten33 sowie der Zugehörigkeit in Gremien.34 4.1.2.4

Aufbewahrung medizinischer Dokumentation35

Diente die ärztliche Dokumentation einer Behandlung ursprünglich allein zur Gedächtnisstütze des Arztes, so ist heute anerkannt, dass sie auch im Interesse des Patienten erfolgt. Erst sie ermöglicht dem Patienten, Kenntnis über den Behandlungsverlauf zu erlangen, und ist damit wesentlich für die Ausübung seines Rechts, anderweitig sachkundige Auskünfte über seinen Gesundheitszustand sowie über einen weiteren erforderlichen Behandlungsbedarf einzuholen. Zwar ist strittig, ob bereits die Dokumentationserstellung auch zum Zweck der Beweissicherung erfolgt und daher dieser Zweck den Umfang der zu erstellenden Dokumentation bestimmt; unstrittig ist allerdings, dass der Dokumentation in dem Umfang, in dem sie vorliegt und aufbewahrt wird, eine beweissichernde Funktion zukommt. Über die Grundlage der ärztlichen Dokumentations- und Aufbewahrungspflicht bestehen ebenfalls unterschiedliche Ansichten. Teils wird sie als vertragliche Nebenpflicht aus dem Arztvertrag oder dem Krankenhausaufnahmevertrag verstanden, teils gilt sie als unverzichtbare Grundlage für die Sicherheit des Patienten in der Behandlung und somit als Teil der ärztlichen Behandlungspflicht; auch aus dem Persönlichkeitsrecht des Patienten wird sie hergeleitet.36 Normiert sind Dokumentations- und Aufbewahrungspflichten außer in vereinzelten Vorschriften im Gesundheitsverwaltungsrecht37 nur in den Kammergesetzen der Länder und den darauf basierenden Berufsordnungen für Ärzte. [...] Beispielsweise sieht § 28 Abs. 4 [RöntgVO] eine zehn- bzw. 30-jährige Aufbewahrungsfrist für Aufzeichnungen über Röntgenbehandlungen vor. Längere Fristen können sich aber auch daraus ergeben, dass die Informationen für eine spätere Behandlung des Patienten noch benötigt werden. Unter Umständen kann es sein, dass medizinische Daten eines Kindes bis in dessen hohes Alter aufbewahrt werden müssen, weil ihre Kenntnis auch dann noch relevant sein kann.

30 31 32 33 34 35 36

37

§ 16 Abs. 2 Satz 2 ArbZG; § 165 Abs. 4 Satz 2 SGB VII; § 22 Abs. 3 LadenSchlußG; § 50 Abs. 2 JArbSchG § 41 Abs. 1 JArbSchG; § 80 SGB IX. § 13 Abs. 4 Satz 1 und Satz 2 BiostoffVO. § 7 3. BImSchVO; § 27 StrlSchVO. § 19 WO (1. VO zur Durchführung des BetrVG). S. [ARO 07], Kap. 4.3.4 Die Rechtsprechung spricht in diesem Zusammenhang von einer „selbstverständlichen therapeutischen Pflicht“; s. erstmals BGH, NJW 1978, 2339; Siehe z. B. § 43 StrlSchVO, § 29 Abs. 2 RöntgVO, § 19 ArbStoffVO, § 37 JArbSchG

Bundesamt für Sicherheit in der Informationstechnik

29

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Aus den Dokumentationszwecken werden Art, Inhalt und Umfang der Dokumentationspflicht abgeleitet. Sie umfasst den gesamten Behandlungsverlauf, wobei ihr Umfang sich auf das medizinisch Übliche und das zur Erreichung der Dokumentationszwecke Erforderliche reduziert: Sie muss alle wesentlichen diagnostischen und therapeutischen Bewandtnisse, Gegebenheiten und Maßnahmen in einer für den Fachmann hinreichend klaren Form beinhalten und in unmittelbarem Zusammenhang mit der Behandlung erfolgen. Hinsichtlich der Form sieht § 10 Abs. 5 MBO-Ärzte explizit vor, dass die Dokumentation in elektronischer Form erfolgen und aufbewahrt werden kann.38 Allerdings bedürfen Aufzeichnungen auf elektronischen Datenträgern oder anderen Speichermedien gemäß § 10 Abs. 5 Satz 1 MBO-Ärzte besonderer Sicherungs- und Schutzmaßnahmen, um deren Veränderungen, Vernichtung oder unrechtmäßige Verwendung zu verhindern. Die entsprechend Satz 2 zu beachtenden Empfehlungen der Ärztekammer präzisieren insbesondere die Anforderungen und zu treffenden Maßnahmen zur Wahrung des Datenschutzes und der Datensicherheit zur Gewährleistung des informationellen Selbstbestimmungsrechts des Patienten und der Schweigepflicht des Arztes. Der Einsatz elektronischer Signaturen wird zur Datensicherung und damit zur Erhöhung des Beweiswerts der Dokumentation angesprochen, allerdings ihre Eignung zur Erreichung des Ziels offen gelassen. Diese Unsicherheit dürfte heute, knapp zehn Jahre später, nicht mehr bestehen. So muss auch der Heilberufsausweis für Ärzte, der gemäß § 291a Abs. 5 Satz 3 SGB V als Zugriffsinstrument auf die Daten der elektronischen Gesundheitskarte erforderlich ist, in der Lage sein, qualifizierte elektronische Signaturen zu erstellen.39 Auch wenn sich daraus nicht zwingend ergibt, dass die gesamte ärztliche Dokumentation elektronisch signiert und mit Zeitstempeln versehen werden muss, so ist diese Form der Dokumentation und Aufbewahrung empfehlenswert, da der elektronischen Dokumentation dadurch bei etwaigen gerichtlichen Auseinandersetzungen40 ein großes Maß an Beweiskraft verliehen wird. 4.1.2.5

Die Aufbewahrung von Bankunterlagen41

Ebenso wie das Rechtsgebiet des Bankrechts eine Bündelung von mehreren Gesetzen umfasst, so finden sich auch die Vorschriften über die Erstellung und Aufbewahrung von Bankunterlagen in unterschiedlichen Vorschriften wieder. Die wichtigsten Normen zur Aufbewahrung von Bankunterlagen stellen § 25a Abs. 5 KWG, § 9 GWG und § 34 WpHG dar. Die einzelnen Aufbewahrungsbestimmungen müssen wiederum zweckorientiert ausgelegt werden. Die genannten Gesetze unterscheiden sich durch ihre jeweilige Zielbestimmung, ihnen ist aber eine Überschneidung des Adressatenkreises gemeinsam. So richten sich alle insbesondere an Kredit- und Finanzdienstleistungsinstitute.42 [...] Das Kreditwesengesetz verfolgt den Zweck, die Funktionsfähigkeit, Stabilität und Integrität des Kredit- und Finanzdienstleistungswesens sicherzustellen.43 Gemäß § 6 Abs. 1 KWG übt die Kontrolle über die Institute die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) aus. Der Durchführung der Überwachung dient ausdrücklich die in § 25a Abs. 1 Nr. 5 KWG für die Institute normierte Aufzeichnungs- und Aufbewahrungspflicht. Danach müssen die Institute dafür Sorge tragen, dass eine vollständige Dokumentation der ausgeführten Geschäfte eine lückenlose Überwachung durch die BaFin gewährleistet. Aus dieser Vorschrift ergibt sich in Ergänzung der Grundanforderungen die weitere Anforderung der Vollständigkeit hinsichtlich aller Geschäftsvorgänge. Des Weiteren wird hinsichtlich 38 39

40

41 42

43

30

Bereits [KIL 1987], NJW 1987, 696 ff.; [SBJ 1991], NJW 1991, 2335; [INHE 1995], NJW 1995, 689 Hierzu und zur Signaturfunktionalität auf dem Heilberufsausweis und der Gesundheitskarte [HORN 04], 229 f.; [HORN 05], 63 f. Laut Medical Tribune (MTD, Ausgabe 49 / 2001 S.34) gibt es jährlich etwa 400.000 Kunstfehler, 80.000 Haftpflichtansprüche gegen Ärzte und 5.000 Arzthaftungsprozesse. Siehe [ARO 07], Kap. 4.3.5 Siehe § 1 Abs. 1 Satz 1 KWG, § 1 Abs. 4 Satz 1 GwG und § 2 Abs. 4 WpHG. Kreditinstitut ist, wer eines der in § 1 Abs. 1 Satz 1 KWG genannten Bankgeschäfte gewerbsmäßig oder in einem Umfang betreibt, der einen in kaufmännischer Weise eingerichteten Gewerbebetrieb erfordert. Die Qualifizierung als Kreditinstitut setzt damit das Betreiben eines der im Katalog des § 1 Abs. 1 Satz 2 KWG genannten Bankgeschäfte voraus. Eine Legaldefinition des Begriffs des Finanzdienstleistungsinstituts findet sich in § 1 Abs. 1a KWG. http://www.bafin.de/bafin/aufgabenundziele.htm.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

der Aufbewahrungspflicht eine dokumentenspezifische Differenzierung getroffen, indem Buchungsbelege zehn Jahre und sonstige erforderliche Aufzeichnungen sechs Jahre aufzubewahren sind. Aufbewahrungspflichtige Unterlagen

Aufbewahrungsfrist

Aufzeichnungen, die eine lückenlose Überwachung der ausgeführten Geschäfte durch die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) für ihren Zuständigkeitsbereich gewährleisten Soweit dies Buchungsbelege darstellen

6 Jahre 10 Jahre

Tabelle 3: Aufbewahrungspflichtige Unterlagen nach § 25a Abs. 1 KWG, Quelle: [SBR 04], S. 19

Während diese Regelungen zunächst offen lassen, ob die Dokumentation in Papierform erstellt werden muss oder auch elektronisch erfolgen kann, schafft der zweite Halbsatz des § 25a Abs. 1 Nr. 5 KWG insofern Klarheit, als er auf § 257 Abs. 3 und Abs. 5 HGB verweist. Wie bereits ausgeführt, ist gemäß dieser Vorschrift die Aufbewahrung der Dokumentation als Wiedergabe auf einem Bildträger oder auf anderen Datenträgern zulässig, wenn dies den Grundsätzen der ordnungsgemäßen Buchführung entspricht und die weiteren Voraussetzungen gemäß § 257 Abs. 3 Nr. 1 und Nr. 2 HGB erfüllt sind. Zusammenfassend muss die Aufbewahrung der Dokumentation auf Datenträgern nach dem KWG den Anforderungen der GoB entsprechen, mit den Originalen übereinstimmen und jederzeit verfügbar sein.44 Mit dem Geldwäschegesetz verfolgt der Gesetzgeber den Zweck, in Ergänzung zu der Normierung des Geldwäschestraftatbestands des § 261 StGB die Nutzung des Finanzsystems zur Geldwäsche zu verhindern. Ziel ist es daher, präventiv die Einschleusung illegaler Gelder in den Finanzmarkt zu erschweren und zu verhindern. Ein wirksames Instrument der Kredit- und Finanzdienstleistungsunternehmen, sich vor dem Missbrauch ihrer „Organisationen" zur Geldwäsche zu schützen, ist die in § 2 Abs. 1 und 2 GwG normierte Identifizierungspflicht hinsichtlich des Vertragspartners bei Abschluss eines Vertrags zur Begründung einer auf Dauer angelegten Geschäftsbeziehung und jeweils bei Annahme von Bargeld, Wertpapieren oder Edelmetallen im Wert ab 15.000 Euro. Die Identifizierung erfolgt in der Regel durch die Vorlage eines Ausweises. Die getroffenen Feststellungen über die Person müssen gemäß § 9 GwG aufgezeichnet und für die Dauer von sechs Jahren aufbewahrt werden. Die Aufzeichnungen können gemäß § 9 Abs. 2 GwG auch auf elektronischen Datenträgern erfolgen. Die weiteren Anforderungen, die diese Vorschrift an die elektronische Aufbewahrung stellt, entsprechen den Ausführungen zum Kreditwesengesetz.

44

Ausdrücklich genannt wird in § 257 Abs. 3 Nr. 2 auch die Lesbarkeit, die hier nicht noch einmal explizit genannt wird, da sie bereits zu den Grundanforderungen zählt.

Bundesamt für Sicherheit in der Informationstechnik

31

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Aufbewahrungspflichtige Unterlagen Aufzeichnungen über die Erbringung von Wertpapierleistungen, dazu gehören: • Der Auftrag und die hierzu erteilten Anweisungen des Kunden sowie die Ausführung des Auftrags • Der Name des Angestellten, der den Auftrag des Kunden angenommen hat • Datum und Uhrzeit der Erteilung und der Ausführung des Auftrags • Die dem Kunden für den Auftrag in Rechnung gestellten Provisionen und Spesen • Die Anweisungen des Kunden sowie die Erteilung des Auftrags an Dritte, soweit es sich um die Verwaltung von Vermögen handelt • Die Erteilung eines Auftrags für eigene Rechnung an ein anderes Wertpapierunternehmen sofern das Geschäft nicht der Meldepflicht nach § 9 WpHG unterliegt; Aufträge für eigene Rechnung sind besonders zu kennzeichnen. Soweit dies Buchungsbelege darstellen (nach HGB/AO)

BSI TR 03125

Aufbewahrungsfrist 6 Jahre

10 Jahre

Tabelle 4: Aufbewahrungspflichtige Unterlagen nach WpHG, Quelle: [SBR 04], S. 19,20

Ziel des Wertpapierhandelsgesetzes ist der Schutz und die Stärkung des Vertrauens der Anleger in die Ordnungsmäßigkeit, Fairness und Integrität der Kapitalmärkte [...]. Das Wertpapierhandelsgesetz will durch die Einführung bestimmter Verhaltens- und Informationspflichten vertrauensbildende Maßnahmen schaffen. So gewährleistet die in § 34 Abs. 1 WpHG normierte Aufzeichnungspflicht des Instituts für den Kunden eine hohe Transparenz hinsichtlich aller für ihn durchgeführten Wertpapierdienstleistungen. Die Aufbewahrungsdauer der aufgezeichneten Informationen richtet sich nach § 34 Abs. 3 WpHG, der eine Aufbewahrungsfrist von sechs Jahren festlegt und im Übrigen auf den § 257 Abs. 3 und Abs. 5 HGB verweist. Die Zulässigkeit und die weiteren Anforderungen für die Aufbewahrung der aufzuzeichnenden Informationen in elektronischer Form entsprechen wiederum den zuvor genannten Ausführungen. [...] 4.1.2.6

Die Aufbewahrung von Akten der Verwaltung 45

Die grundsätzliche Pflicht zur Aktenförmigkeit und Dokumentation trifft [...] die gesamte Verwaltung unabhängig von gesetzlichen Anordnungen oder Organisationsstatuten als Ausfluss aus dem Rechtsstaatsprinzip und je nach Art des Verfahrens aus dem Grundsatz des fairen, objektiven und wahrheitsgetreuen Verwaltungsverfahrens. Als unausgesprochene Voraussetzung findet sie auch Niederschlag in § 29 VwVfG, dem Recht auf Akteneinsicht der Beteiligten. Diese allgemeine Dokumentationspflicht umfasst die Pflicht der Behörden und Verwaltungseinheiten, ordnungsgemäße Akten zu führen und alle wesentlichen Vorgänge, die für das Verwaltungsverfahren während seiner Durchführung und später für seine Nachvollziehbarkeit relevant sind, in Niederschriften oder Aktenvermerken festzuhalten, Schriftwechsel aufzubewahren und den gesamten Vorgang „aktenkundig“ zu machen.46 Differenziert werden drei Gebote: Das Gebot der Aktenmäßigkeit, der Vollständigkeit und der wahrheitsgetreuen Aktenführung. […] Darüber hinaus sind alle Stellen des Bundes verpflichtet, Unterlagen, die für die Aufgabenwahrnehmung nicht mehr benötigt werden, vor ihrer Vernichtung dem Bundesarchiv zur Übernahme als Archivgut des Bundes anzubieten (vgl. § 1 Abs. 1 Bundesarchivgesetz). Diese Anbietungsverpflichtung gilt selbstverständlich auch für elektronisch erstellte oder elektronisch erfasste Unterlagen. 45 46

32

Siehe [ARO 07], Kap. 4.3.6 So auch § 2 RegR der Bundesministerien: „Die Geschäftstätigkeit der Verwaltung folgt dem Grundsatz der Schriftlichkeit. […] Die Aktenführung sichert ein nachvollziehbares transparentes Verwaltungshandeln….“; Siehe dazu auch KBSt, DOMEA Erweiterungsmodul Aussonderung und Archivierung elektronischer Akten, S. 11 ff, abrufbar unter http://www.kbst.bund.de.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Neben der Pflicht zur Aktenförmigkeit und Dokumentation wirkt außerdem das in § 30 VwVfG und in einigen besonderen Verwaltungsverfahrensgesetzen (§ 30 AO, § 35 SGB I, § 5 BDSG) normierte Verwaltungsgeheimnis auf die Anforderungen an die Aufbewahrung ein. Die Dokumentationspflicht selbst folgt [...] verschiedenen Zwecken, die Einfluss auf die Anforderungen an die Aufbewahrung haben. Ein Zweck ist das Schaffen einer Möglichkeit für aufsichts- oder weisungsberechtigte übergeordnete Behörden oder auch Untersuchungsgremien, Kontrollen zur Rechtmäßigkeit im Nachhinein durchführen zu können. [...] Ein weiterer Zweck liegt in der Möglichkeit der Verfahrensbeteiligten über die Akteneinsicht das rechtmäßige Vorgehen der Verwaltungsbehörden und -einheiten zu überprüfen und gegebenenfalls mittels der Akten die Unrechtmäßigkeit zu beweisen. Hier spielt [...] bereits der Beweiszweck eine Rolle. Ein gewisser Vertrauensvorschuss der öffentlichen Verwaltung ist bei den Anforderungen hieraus an die Aufbewahrung zwar in Rechnung zu stellen und beispielsweise mit Blick auf öffentliche Urkunden auch rechtlich manifestiert, 47 doch andererseits ist die Verwaltung gerade im möglichen Streitfall Partei. [...] Daher liegt die Anknüpfung an die Beweiseignungskriterien der Prozessordnungen nahe, also die Verwendung von qualifizierten elektronischen Signaturen zumindest bei bedeutsamen Aktenbestandteilen. Zudem sind für alle hier genannten Zwecke die Vollständigkeit und die Erhaltung der Aktenstruktur von Bedeutung. Nicht zu vernachlässigen als Zweck der Dokumentationspflicht ist außerdem die Absicht, die Kenntnis von den Vorgängen innerhalb der Organisation unabhängig von der Kenntnis des verantwortlichen Bearbeiters zu gestalten. Die Notwendigkeit lässt sich aus den allgemeinen Verfahrensgarantien, auch aus dem Beschleunigungsgrundsatz ableiten. Sicherungsanforderungen folgen aus diesem Zweck jedoch kaum, denn im Vordergrund steht der Wissenstransfer, nicht die Manipulationssicherheit. Angesichts der verschiedenen Zwecke und der im Allgemeinen zunächst einmal nicht normierten Anforderungen an die Aufbewahrung lassen sich für die einzelne Akte keine durchgängigen, die allgemeinen Grundanforderungen und die Forderung nach Vollständigkeit übersteigenden Anforderungen aufstellen, sieht man von Schutzmaßnahmen gegen den Datenverlust oder versehentliche Löschung ab. Besonders beweisrelevante Teile einer Akte werden einer qualifizierten elektronischen Signatur bedürfen. Das ist jedoch teilweise bereits gesetzlich im Bereich der Verwendung der elektronischen Form geregelt, so etwa in § 37 Abs. 3 VwVfG für den ansonsten schriftlich zu erlassenden Verwaltungsakt oder in § 57 VwVfG und § 56 SGB X i.V.m. § 3a Abs. 2 VwVfG für Verwaltungsverträge. Auch wenn die Signaturverwendung hier zunächst an die Ersetzung der Schriftform geknüpft ist und somit auf die Formwahrung zielt, so ist doch auch einer der Formzwecke der Beweiszweck, der für die Aufbewahrung fortdauert. Dokumente der Akte, die in ihrer Beweisbedeutung Verwaltungsakten oder Verwaltungsverträgen nicht nachstehen, werden dieser Wertung folgend ebenfalls zu signieren sein. Dies würde etwa Dokumente umfassen, in denen die die Entscheidung tragenden Informationen erfasst werden. Andererseits werden die wenigsten Vermerke ihrer Bedeutung nach einer qualifizierten elektronischen Signatur bedürfen. Für die Aufbewahrung hat dies die Konsequenz, dass nur für einen Teil der einzelnen Akte die Sicherung mittels Signatureinsatz zwingend geboten ist und der Erhalt der Signaturen gewährleistet werden muss. Um die Vollständigkeit der Akte zu sichern, werden aber grundsätzlich Sicherungsmittel notwendig sein. [...] Neben der allgemeinen Dokumentationspflicht bestehen für die Verwaltung zahlreiche besondere Regelungen spezifisch für bestimmte Handlungsbereiche der Verwaltung. Zudem existieren die Aktenordnungen und Verwaltungsrichtlinien der einzelnen Behörden, die jedoch erst vereinzelt auf die Probleme der elektronischen Aufbewahrung und Prozessabwicklung eingehen. Das wichtigste Beispiel solcher Richtlinien mit Orientierungsfunktion stellt die Gemeinsame Geschäftsordnung der Bundesministerien (GGO)48 dar, die durch die Registraturrichtlinie für das Bearbeiten und Verwalten von Schriftgut in den Bundesministerien (RegR)49 ergänzt wird. In beiden Regelungen wird nach der Überarbeitung im Rahmen des Programms „Moderner Staat – moderne Verwal47

48 49

§ 371a Abs. 2 ZPO i. V. m. § 437 Abs. 1 ZPO führt bei öffentlichen elektronischen Dokumenten zu einer Vermutung der Echtheit, § 371a Abs. 1 ZPO für private Dokumente nur zu einem Anschein, der durch Tatsachen, die ernstlichen Zweifel begründen, erschüttert werden kann. Beschluss des Bundeskabinetts v. 26.7.2000, verfügbar unter http://www.staat-modern.de. Beschluss des Bundeskabinetts v. 11.7.2001, verfügbar unter http://www.staat-modern.de.

Bundesamt für Sicherheit in der Informationstechnik

33

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

tung“50 elektronische Kommunikation und der Einsatz elektronischer Medien umfassend berücksichtigt.51 Dies umfasst die Regelung des elektronischen Eingangs in § 13 Abs. 2 GGO und der zugehörigen Anlage, aber auch den Einsatz von elektronischen Signaturen gemäß Signaturgesetz bei unmittelbarer Rechtswirkung des Dokuments oder bei besonderer politischer Bedeutung (§ 18 Abs. 2 GGO). Ausführlichere Regelungen, auch zur Aufbewahrung, finden sich in der Registraturrichtlinie. § 4 RegR stellt die Grundsätze der Vollständigkeit, Einheitlichkeit und Nachvollziehbarkeit des Sach- und Bearbeitungszusammenhangs in den Vordergrund. § 4 Abs. 3 RegR regelt, dass elektronische Dokumente nur nach Beteiligung ihres Verfassers verändert werden sollen. § 6 Abs. 4 RegR sieht vor, dass der Laufweg und sämtliche Bearbeitungsschritte dem elektronischen Dokument beigefügt werden. § 8 Abs. 3 RegR ermöglicht den Verzicht auf eine Farbregelung bei der elektronischen Vorgangsbearbeitung. § 18 RegR schließlich behandelt die Aufbewahrung. Durch geeignete Maßnahmen, die nicht näher vorgegeben werden, sind Vollständigkeit, Integrität, Authentizität und Lesbarkeit zu gewährleisten (§ 18 Abs. 1 Satz 2 RegR). In § 18 Abs. 3 RegR wird darüber hinaus klargestellt, dass elektronisches Schriftgut der laufenden Pflege bedarf. Es soll rechtzeitig und ohne inhaltliche Veränderungen auf Formate und Datenträger übertragen werden, die dem Stand der Technik entsprechen.[...] Die wohl umfassendsten Regelungen neben denen der allgemeinen Verwaltungsverfahrensgesetze des Bundes und der Länder enthält das Sozialgesetzbuch. Aber auch dieses enthält letztlich nur eine Ermächtigung der Spitzenverbände und subsidiär der beteiligten Bundesministerien, Grundsätze für die ordnungsgemäße Aufbewahrung zu vereinbaren oder als Verordnung zu erlassen. Die normierten Anforderungen in § 110a Abs. 2 SGB IV beschränken sich darauf, dass die bildliche Wiedergabe mit dem ehemals in Papierform vorliegenden Dokumenten vollständig übereinstimmt und hierüber ein entsprechender Nachweises geführt wird. Bei bereits elektronisch angefertigten Dokumenten wird deren jederzeitige Lesbarkeit und Wiedergabemöglichkeit gefordert. Aus der bildgerechten Wiedergabe folgt als weitergehende Anforderung noch die Forderung nach einer farbechten Wiedergabe. Nach § 110c Abs. 1 SGB IV sollen die Spitzenverbände beim Vereinbaren von Grundsätzen die Maßgaben des Signaturgesetzes beachten. Nach § 110d SGB IV können außerdem Unterlagen, die auf anderen dauerhaft maschinell verwertbaren Datenträgern als Bildträgern aufbewahrt werden und mit einer dauerhaft überprüfbaren Signatur versehenen sind, der öffentlich-rechtlichen Verwaltungstätigkeit zugrunde gelegt werden. Aus beiden Anknüpfungspunkten lässt sich ableiten, dass entweder bei der Aufbewahrung Signaturen allgemein verwendet werden, oder aber, dass die Beweisrelevanz nach einzelnen Dokumentarten zu prüfen ist und nur für diejenigen, die noch für die Verwaltungstätigkeit benötigt werden, Signaturen verwendet werden. Ein Dokument, das im weiteren Verlauf des Vorgangs nicht mehr entscheidungserheblich ist, braucht nicht signiert zu werden. Für personenbezogene Stammdaten bestehen weitergehende Anforderungen. So fordert § 149 Abs. 2 SGB VI eine Speicherung, die erlaubt, Daten jederzeit abzurufen und auf einem Datenträger oder durch Datenübermittlung zu übertragen. § 148 Abs. 2 SGB VI enthält eine Begrenzung, welche Daten unter welchen organisatorischen Voraussetzungen gemeinsam in einer Datei gespeichert werden dürfen. § 150 Abs. 2 Nr. 5 SGB VI macht zudem eine Verschlüsselung der Adressdaten notwendig. Systematisch stehen diese Anforderungen zwar unter der Rubrik Datenschutz und Datensicherheit und betreffen die Stammdatensätze, nicht die Aktenführung, doch da die Datensätze auch Teil der Akte sind, müssen sie als weitere spezielle Anforderungen herangezogen werden. Von den datenschutzbezogenen Regelungen der §§ 67 ff SGB X ist außerdem noch besonders § 78a SGB X samt dem zugehörigen Anhang zu beachten, der konkrete technische und organisatorische Anforderungen stellt, die auch die Aufbewahrung betreffen. So werden im Anhang die Gewährleistung von Zugangs-, Zutritts-, Weitergabe-, Eingabe- und Verfügbarkeitskontrollen gefordert sowie die Möglichkeit der getrennten Verarbeitung der Daten nach Zweckbindungsgrundsätzen. Aus der grundsätzlichen Verpflichtung der Behörde im anhängigen Rechtsstreit dem Gericht die Akte zugänglich zu machen, resultieren zudem weitere Anforderungen an die inhaltliche, chronologische Aufbereitung und Schlüssigkeit der Akte. [...] Einen weiteren weitgehend durch die Sonderregelungen der Abgabenordnung bestimmten Bereich stellt die Finanzverwaltung dar. Die Abgabenordnung enthält jedoch keine direkten Regelungen zur Aufbewahrung. Auswirkungen auf die Durchführung der Aufbewahrung haben nur wenige Bestimmungen. An erster Stelle ist § 30 Abs. 6 AO zu nennen, der den automatisierten Abruf von elektro50 51

34

S. hierzu http://www.staat-modern.de Elektronische Verfahren erhalten sogar eine Vorrangstellung, denn nach § 12 Abs. 1 GGO sind in den Arbeitsabläufen elektronische Verfahren soweit wie möglich zu nutzen.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

nisch gespeicherten Daten unter bestimmten Voraussetzungen zulässt, aber das Bundesfinanzministerium ermächtigt, durch Verordnung Anforderungen an die technischen und organisatorischen Maßnahmen zur Wahrung des Steuergeheimnisses zu stellen. Das Bundesfinanzministerium ist dem nachgekommen und hat in der Verordnung über den automatisierten Abruf von Steuerdaten (StDAV) die Verfahrensdokumentation, die Prüfung der Zulässigkeit der Abrufe und die automatisierte Befugnisprüfung, die Beschränkung der Befugnis auf aufgabenbezogene Daten, die Aufzeichnung der Abrufe und die Abrufmöglichkeit durch Steuerpflichtige geregelt.52 Die Vorgaben für die Gestaltung der Abrufmöglichkeit wirken hinsichtlich der Vorgaben für den Zugriff auch auf die Gestaltung der Aufbewahrung ein. § 87a AO regelt die Grundlagen elektronischer Kommunikation und enthält die Parallelregelung zu § 3a VwVfG, so dass auch in der AO zum Ersatz der Schriftform die elektronische Signatur verlangt wird. Die Aufbewahrung signierter Dokumente wird also auch hier erheblich werden. 4.1.2.7

Die Aufbewahrung von Gerichtsakten53

Als Ausfluss des Rechtsstaatsprinzips und aus der Garantie des umfassenden und effektiven Rechtsschutzes durch unabhängige Gerichte ergeben sich ebenfalls bei der Justiz die umfassende Aktenführungspflicht und Pflicht zur Aufbewahrung dieser Akten. Hinsichtlich der Aufbewahrungsfristen bestehen keine einheitlichen Vorgaben. Entsprechend § 1 Schriftgutaufbewahrungsgesetz dürfen beispielsweise Gerichtsakten der Gerichte des Bundes und des Generalbundesanwalts nur so lange aufbewahrt werden, wie schutzwürdige Interessen der Verfahrensbeteiligten oder sonstiger Personen oder öffentliche Interessen dies erfordern. Seit Inkrafttreten des Justizkommunikationsgesetzes ist auch die elektronische Aktenführung in der Justiz möglich.54 Nach § 130b ZPO kann die Erfordernis der handschriftlichen Unterzeichnung einer Urkunde, sofern das Gesetz eine solche von einem Justizmitarbeiter verlangt, auch durch ein elektronisches Dokument abgebildet werden, wenn die verantwortenden Personen unter dieses ihren Namen setzen und mit einer qualifizierten elektronischen Signatur versehen.55 Nachdem bereits der Zugang elektronischer Dokumente zur Justiz durch das Formanpassungsgesetz von 2001 mit § 130a ZPO eröffnet worden war, steht seit 2005 einer elektronischen Aktenführung grundsätzlich nichts mehr im Weg. Allerdings sieht § 298a Abs. 1 Satz 2 ZPO vor, dass die Bundes- und Landesregierungen für ihren Bereich durch Rechtsverordnung die geltenden organisatorisch-technischen Rahmenbedingungen hinsichtlich der Bildung, Führung und Aufbewahrung elektronischer Akten bestimmen sollen. Als Grundlage für diese Rechtsverordnungen sollen die von den Ländern gemeinsam entwickelten organisatorisch-technischen Leitlinien für den elektronischen Rechtsverkehr mit den Gerichten und Staatsanwaltschaften (OT-Leit-ERV)56 dienen. Gemäß 9.3 OT-Leit-ERV ist vorgesehen, nach erfolgter Signaturprüfung und Dokumentation des Ergebnisses an einer festzulegenden Stelle (beispielsweise beim Übergang in ein sicheres Landesnetz oder Eingang bei Gericht) auf die Speicherung der Signatur zu verzichten, wenn die Integrität der Daten auf andere Weise sichergestellt ist und die Gültigkeit der Signatur und des Zertifikats zum Zeitpunkt der Übermittlung nachweisbar bleibt. Die Zertifikatsdaten sollen gespeichert werden, wohingegen eine generelle Online-Prüfung als nicht erforderlich angesehen wird, sondern nur auf Einzelfälle beschränkt sein soll. Auf diese Weise sollen Probleme mit der wiederholten Prüfung und der längerfristigen Ablage und späteren Prüfung einer elektronischen Signatur umgangen werden.57 Soweit ersichtlich, sind auf dieser Grundlage allerdings hinsichtlich der Aufbewahrung elektronischer Dokumente noch keine Rechtsverordnungen erlassen worden.

52 53 54

55 56

57

BGBl. I, 3021, vom 13.10.2005. Siehe [ARO 07], Kap. 4.3.7 Zur Zulässigkeit der elektronischen Aktenführung in der Verwaltungsgerichtsbarkeit vor dem Justizkommunikationsgesetz [KUSSEL 03], 132 ff.; zur Aufbewahrungsdauer von Akten in der Justiz nach Beendigung des Verfahrens gilt seit Inkrafttreten des Justizkommunikationsgesetzes [JKomG] das Justizaufbewahrungsgesetz [JustAG]. Entsprechende Regelungen enthalten § 46c ArbGG, § 55a III VwGO, § 52a III FGO, § 65a III SGG. Diese Leitlinien wurden von der Bund-Länder-Kommission erstellt und durch Beschluss der Justizministerkonferenz auf der 73. Konferenz der Justizministerinnen und –minister vom 10. bis 12.6.2002 in Weimar den Ländern und dem Bund zur Einführung des elektronischen Rechtsverkehrs empfohlen Siehe hierzu Anlage 1 der OT-Leit-ERV, wobei jedenfalls in der Pilotphase zur Beweissicherung ergänzend die Speicherung des noch signierten Originaleingangs empfohlen wird.

Bundesamt für Sicherheit in der Informationstechnik

35

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

§ 299a ZPO sieht eine Speicherung und Aufbewahrung von ursprünglich in Papierform vorliegenden Akten auf elektronischen Datenträgern vor. Danach müssen die Prozessakten nach ordnungsgemäßen Grundsätzen übertragen worden sein und es muss ein schriftlicher Nachweis darüber vorliegen, dass die Wiedergabe mit der Urschrift übereinstimmt. Eine Konkretisierung der „ordnungsgemäßen Grundsätzen“ liegt soweit ersichtlich nur für die Mikroverfilmung, nicht jedoch für die digitale Übertragung und insbesondere für die Ausgestaltung der in diese Form gebrachten Dokumente vor.58 4.1.2.8

Revisionssichere und ordnungsgemäße Aufbewahrung59

Im Kontext der Aufbewahrung von elektronischen Dokumenten werden darüber hinaus auch regelmäßig die Begriffe der revisionssicheren und ordnungsgemäßen Aufbewahrung oder Archivierung verwendet. Der Begriff der revisionssicheren „Archivierung“ hat, wie schon Kapitel 3.2 erläutert (siehe Fußnote 1) keinen juristischen Ursprung. Er wurde 1992 von Ulrich Kampffmeyer geprägt und im Jahre 1996 vom Fachverband der Dokumentationsmanagementbranche, Verband Organisations- und Informationssysteme e.V. (VOI) in einem Code of Practice veröffentlicht [KAMPFF 97]. Danach bezieht sich der Begriff „revisionssichere Archivierung“ auf elektronische Archivsysteme, die den Anforderungen der Grundsätzen ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS)60 genügen,61 ordnungsgemäß betrieben werden und Dokumente datenbankgestützt wiederauffindbar, unveränderbar und verfälschungssicher aufbewahren. Für die Bewertung der Revsionssicherheit macht der Code of Practice des VOI e. V. die folgenden Kriterien geltend: • Ordnungsmäßigkeit • Vollständigkeit • Sicherheit des Gesamtverfahrens • Schutz vor Veränderung und Verfälschung • Sicherung vor Verlust • Nutzung nur durch Berechtigte • Einhaltung der Aufbewahrungsfristen • Dokumentation des Verfahrens • Nachvollziehbarkeit • Prüfbarkeit Die Einhaltung der Revisionssicherheit kann auf Grundlage einer Verfahrensdokumentation auch durch den TÜV-IT zertifiziert werden. Basis hierfür sind die Prüfkriterien für Dokumentenmanagementlösungen [PK-DML] des VOI e.V. Die GoBS ersetzen freilich nicht die Grundsätze ordnungsgemäßer Buchführung (GoB); sie stellen lediglich eine Präzisierung der GoB im Hinblick auf eine IT-gestützte Buchführung dar und beschreiben die Maßnahmen, die der Buchführungspflichtige ergreifen muss, will er sicherstellen, dass die Buchungen und sonst erforderlichen Aufzeichnungen vollständig, richtig, zeitgerecht und geordnet vorgenommen werden. Zu beachten sind dabei neben den handelsrechtlichen GoB auch die §§ 145 bis 147 der Abgabenordnung (vgl. hierzu auch [ARO 07], S. 39 ff.). Revisionssicherheit zielt hauptsächlich auf die wirtschaftliche Revision, d. h. die Prüfung des Geschäftsgebarens (des Rechnungswesens, der Buchführung) eines Unternehmens durch Sachverständige 58 59 60

61

36

„Richtlinien für die Mikroverfilmung von Schriftgut in der Bundesverwaltung“ vom 9.3.1978, GMBl. 1978, 188 Siehe auch [ARO 07], Kapitel 3.1.5 BStBl. I 1995, 738; die GoBS wurden vom AWV-Arbeitskreis erarbeitet, dann allerdings durch Schreiben des Bundesministeriums der Finanzen (BMF) an die obersten Finanzbehörden der Länder vom 7.11.1995 intern für verbindlich erklärt. (siehe näher das Vorwort der Anlage zu den GoBS). Die Schreiben des Bundesministeriums für Finanzen sind Verwaltungsanweisungen ohne Rechtsnormcharakter. Sie binden zwar die Verwaltung aber nicht die Gerichte, haben aber als Willensbekundung des BMF hohe Bedeutung. Sie bieten auch Leitlinien für die Hersteller und Betreiber von Buchführungs- und technischen Archivsystemen, da die Finanzbehörden sich bei der Prüfung grundsätzlich an diesen orientieren. So wird auch bei „DOMEA – Modul Technische Aspekte der Archivierung“ Seite 20 unter „revisionssicherer elektronischer Archivierung“ ein Archivsystem verstanden, das nach den Vorgaben der §§ 239, 257 HGB, §§ 146, 147 AO und GoBS beliebige Informationen sicher, unverändert, ordnungsgemäß, verlustfrei reproduzierbar und datenbankgestützt recherchierbar verwalten.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

des Unternehmens (Innenrevision), durch Wirtschaftsprüfer oder durch Behörden, hier insbesondere des Finanzamts. Die Revision dient hauptsächlich der Kontrolle und dem Nachweis der Einhaltung der handels- und steuerrechtlichen Normen und Vorschriften. Ziel einer revisionssicheren elektronischen Aufbewahrung ist es daher, elektronische Archive so zu gestalten, dass sie die internen und gesetzlichen Anforderungen erfüllen, die als Voraussetzung für die Durchführung der Revision festgelegt worden sind (vgl. [ARO 07], S. 40). Revisionssicherheit und Beweissicherheit im Sinne dieser Richtlinie (siehe hierzu Kapitel 3.2) stehen natürlich nicht völlig beziehungslos nebeneinander. Eine beweisrechtliche Würdigung elektronischer Dokumente stützt sich immer auch auf bestimmte, nachvollziehbare Tatsachen, die auf einen beweiswürdigen Sachverhalt schließen lassen. Für elektronische Dokumente sind die Integrität und auch die Authentizität ein taugliches Indiz für die inhaltliche Richtigkeit. Da diese Anforderungen bei einer revisionssicheren Archivierung gemäß den Prüfkriterien des VOI grundsätzlich erfüllt werden, gilt diese als Indiz und erhöht die Beweissicherheit elektronisch aufbewahrter Dokumente. Der Begriff der ordnungsgemäßen Aufbewahrung kann nach [ARO 07, ebenda S. 41] als Obergriff verstanden werden. Er lässt sich keiner bestimmten Fachsprache zuzuordnen und orientiert sich ausschließlich an der Zweckrichtung der Aufbewahrung, hier vor allem der Nachvollziehbarkeit, Vollständigkeit und Sicherheit der Aufbewahrung (vgl. auch [VOI 05], S. 158). Somit kann für eine revisionssichere Aufbewahrung grundsätzlich immer auch eine ordnungsgemäße Aufbewahrung geltend gemacht werden, wobei ordnungsgemäß in diesem Zusammenhang bedeutet, dass die Art und Weise der Aufbewahrung den GoB entspricht, die lediglich für die DV-gestützte Buchführung durch die GoBS konkretisiert werden (vgl. hierzu auch [ARO 07], Seite 41). Die Ordnungsmäßigkeit ist ebenso wie die Revisionssicherheit der Aufbewahrung ein Indiz und führt zur Steigerung der Beweissicherheit, da eine ordnungsgemäße elektronische Aufbewahrung auch auf eine höhere Beweisqualität elektronisch archivierter Dokumente schließen lässt. Dies ergibt sich aus den Anforderungen an eine ordnungsgemäße, revisionssichere Aufbewahrung, die auch den Anforderungen an einen hohen Beweiswert entsprechen. Die Grundsätze der ordnungsmäßigen Aufbewahrung dienen somit der Erhöhung der Beweissicherheit. Hierfür ist vor allem die entsprechend den Grundsätzen der Ordnungsmäßigkeit erreichte Unveränderbarkeit des elektronisch aufbewahrten Dokuments entscheidend.

4.1.3

EU-Recht

Es existieren gegenwärtig keine unmittelbar wirkenden EG-Richtlinien und dementsprechend – wie bereits aus Kapitel 4.1.1 hervorgeht – nationale Umsetzungsakte, die man im europäischen Kontext als rechtlichen Rahmen für ein elektronisches Langzeitspeicherungssystem heranziehen könnte. Es gibt allerdings Bestrebungen in der EU, die mittelbare Anforderungen an ein solches System zur Folge haben könnten. In den USA existiert seit 2002 der sogenannte „Sarbanes-Oxley-Act“ (SOX). Das Gesetz findet Anwendung für alle Unternehmen, die an der New York Stock Exchange notiert sind. SOX hat die Aufgabe, die Transparenz und Nachvollziehbarkeit in den Unternehmen bei Prüfungen durch die SEC (Securities und Exchange Commission) zu verbessern. Unternehmen werden verpflichtet, u. a. ein internes Kontrollsystem für die Rechnungslegung zu unterhalten, die Wirksamkeit der Systeme zu beurteilen und die Richtigkeit der Jahres- und Quartalsberichte beglaubigen zu lassen. Die Erfüllung dieser Verpflichtungen wird unter dem Stichwort „Compliance“ (Übereinstimmung, Erfüllung) zusammengefasst. Direkte Auswirkungen auf die Anforderungen zur Langzeitspeicherung elektronischer Dokumente hat vor allem der Abschnitt 802 von SOX, wonach Sanktionen im Falle der Zerstörung, der Veränderung oder Manipulation aufbewahrungspflichtiger elektronischer Unterlagen angedroht werden. Die Unternehmen werden dabei durch SOX nicht nur verpflichtet aufbewahrungspflichtige elektronische Dokumente gegen vorsätzliche Löschung, Veränderung oder Zerstörung zu schützen, sondern müssen darüber hinaus auch den Nachweis erbringen können, dass Veränderungen oder Manipulationen an diesen Dokumenten nicht stattgefunden haben. In der EU gibt es analoge Bestrebungen, nachprüfbare Regeln für die Einrichtung eines institutionalisierten und transparenten Risikomanagements in Unternehmen zu formulieren. Folgende Richtlinien enthalten hierzu Bestimmungen:

Bundesamt für Sicherheit in der Informationstechnik

37

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

•

Vierte Richtlinie 78/660/EWG des Europäischen Rates vom 25. Juli 1973: „Externe Prüfung des Jahresabschlusses“

•

Siebente Richtlinie 83/349/EWG des Europäischen Rates vom 13. Juni 1983: „Konsolidierter Abschluss“

•

Richtlinie 2006/43/EG (8. EU Richtlinie) des Europäischen Parlaments und des Rates vom 17. Mai 2006 über Abschlussprüfungen von Jahresabschlüssen und konsolidierten Abschlüssen, zur Änderung der Richtlinien 78/660/EWG und 83/349/EWG des Rates und zur Aufhebung der Richtlinie 84/253/EWG des Rates

Die umgangssprachliche Bezeichnung Euro-SOX für die 8. EU Richtlinie ist insofern irreführend, als sich die 8. EU-Richtlinie im Gegensatz zu ihrem US-amerikanischen Pendant nicht mit exakten Fragestellungen der Bewältigung von Risiken im Unternehmen befasst. Sie legt vielmehr fest, nach welchen Kriterien Unternehmen eine Institutionalisierung des Risikomanagements (mindestens) vornehmen müssen und welche Voraussetzungen Wirtschaftsprüfer zu erfüllen haben, um das Risikomanagement effizient kontrollieren zu können. Anders als SOX enthält die 8. EU-Richtlinie damit zwar keine ausformulierten Forderungen, wie interne Kontrollsysteme und Risikomanagementsysteme von Unternehmen auf ihre Wirksamkeit zu überprüfen sind. Allerdings wird in Artikel 13 klar dargelegt, dass Abschlussprüfer »internationale Standards« als Maßstab anzuwenden haben. Aufgrund der zunehmenden Abhängigkeit der Unternehmen von einer funktionierenden Informationstechnik (IT) lassen sich daher zumindest die folgenden wichtigen Anforderungen an eine organisationsweite IT aus dieser Richtlinie ableiten: Die IT muss dafür sorgen, dass alle relevanten Daten jederzeit verfügbar sind. Dazu gehören: • die Steuerung der Infrastruktur, der Organisation, der Applikationsentwicklung und Pflege, • die Kontrolle und Steuerung der logischen Sicherheit (Berechtigungswesen), der physikalischen Verbindungen und der umfeldbedingten Sicherheit, • die Planung für den langfristigen Erhalt des Betriebs und Erstellung eines Notfallkonzepts, • die Überwachung der Systempflege und Weiterentwicklung, der Verarbeitungsdaten, des täglichen Geschäfts sowie der Projekte bis hin zur • rechts- und revisionssicheren Archivierung aller relevanten Daten, Dokumente und Unterlagen.

4.2

Übergreifende funktionale Anforderungen an eine vertrauenswürdige elektronischer Aufbewahrung

Unabhängig von der konkreten Zweckbestimmung einer elektronischen Aufbewahrung elektronischer Daten und Dokumente muss ein zu dieser Richtlinie konformes vertrauenswürdiges elektronisches Archivsystem mindestens die folgenden, sowohl rechtlich als auch funktional bestimmten, grundsätzlichen Anforderungen erfüllen. Diese sind nach Maßgabe der in Kap. 4.1 dargelegten normativen Regelungen: die Verfügbarkeit und Lesbarkeit, die Integrität und Authentizität sowie der Datenschutz und die Datensicherheit der gespeicherten elektronischen Informationen.

4.2.1

Verfügbarkeit und Lesbarkeit

(A4.2-1) Vertrauenswürdige elektronische Archivsysteme müssen die zur Aufbewahrung bestimmten Daten und Dokumente mindestens für die Dauer gesetzlicher Aufbewahrungsfristen in Form und Inhalt authentisch und vollständig verkehrsfähig aufbewahren. „verkehrsfähig“ heißt hier technisch verfügbar, wiedergabefähig und lesbar auf zum Zeitpunkt der Wiedergabe dem Stand der Technik entsprechenden elektronischen Geräten.

38

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Die Sicherstellung der Verfügbarkeit und Lesbarkeit ergibt sich unmittelbar aus der Zielsetzung jeglicher Aufbewahrung. Erst wenn die Aufbewahrung den jederzeitigen und vollständigen Zugriff auf die aufbewahrten Informationen sowie ihre Lesbarkeit sicherstellt, kann sie ihre Wirkung entfalten. Der Zugriff und die Lesbarmachung erfolgen im Regelfall über die Anzeige der Dokumente und Daten auf einer Datenverarbeitungsanlage, über die Erstellung eines Ausdrucks oder durch die Bereitstellung der Dokumente und Daten in einem maschinell auswertbaren Format über eine Export-Schnittstelle des Archivierungssystems. Daraus folgt: (A4.2-2) Für die rechtssichere und dauerhafte Ablage elektronischer Informationen müssen langfristig stabile und eindeutig interpretierbare Nutzdatenformate verwendet werden, für die eine nachhaltige Verkehrsfähigkeit über die Dauer der gesetzlichen Aufbewahrungsfristen nach heutigem Wissensstand mindestens angenommen werden kann und deren Spezifikation standardisiert und öffentlich zugänglich ist ( mehr dazu in Kapitel 6.1 dieses Dokuments). Zur Vollständigkeit des Zugriffs auf elektronisch archivierte Informationen gehört, dass der Zusammenhang der archivierten Daten und Dokumente mit der Begründung und Zweckbestimmung der Archivierung jederzeit und zweifelsfrei hergestellt werden kann. Das bedeutet: (A4.2-3) Die rechts- und revisionssichere dauerhafte Aufbewahrung elektronischer Dokumente und Daten erfordert zwingend, in Verbindung mit den eigentlichen Inhaltsdaten, Zusatzinformationen (Metadaten) mit abzulegen, die Auskunft über die Struktur, den Zustand (Authentizität und Integrität), den Fundort und die Zuordnung (fachlicher Kontext; Geschäftsvorfall) der archivierten Unterlagen geben können. Umfang, Inhalt und technisches Format der Metadaten sind dabei so zu gestalten, dass Kontext und Semantik der archivierten Unterlagen sowie der Zusammenhang der Inhaltsdaten mit den beschreibenden Metainformationen mindestens für die Dauer der gesetzlich vorgeschriebenen Aufbewahrungszeiträume grundsätzlich und jederzeit auch durch Dritte wieder herstellbar ist. (A4.2-4) Datenträger können physikalisch wie technologisch veralten. Dies kann dazu führen, dass archivierte Daten nicht mehr lesbar sind. Daher müssen archivierte Daten und Dokumente noch vor Ablauf der vom Hersteller von Speichermedien zugesagten Haltbarkeitsfristen auf ihre Lesbarkeit untersucht werden und ggf. auf neue Datenträger kopiert bzw. in neue, aktuellere Datenformate übertragen werden. Bei der Übertragung muss der Beweiswert der Dokumente und Daten erhalten bleiben. (A4.2-5) Verfügbarkeitsrisiken des Archivierungssystems sollen durch regelmäßige Datensicherungen und Datenmigration vermindert werden. Bei der Übertragung zum Backup-System muss der beweisrechtliche Wert aufbewahrter Daten und Dokumente erhalten bleiben. Aus Sicherheitsgründen (bspw. Brandschutz) sollen die Datensicherungen räumlich getrennt vom ITgestützten Archivsystem aufbewahrt werden. Hinweis: Wenn Anforderungen auf nicht-wiederherstellbares Löschen von einzelnen Daten/Dokumenten bestehen, müssen solche Anforderungen auch auf das Backup-System ausgedehnt werden können oder es darf kein Backup angefertigt werden.

4.2.2

Integrität und Authentizität

Voraussetzung für eine mögliche oder auch beabsichtigte Rechtswirkung elektronisch aufbewahrter Informationen ist, die aufbewahrten Daten und Dokumente so zu erhalten, wie sie ursprünglich abgefasst worden sind, d. h. ohne nachträgliche Änderungen und der Möglichkeit, auch nach langer Zeit den Aussteller des Dokuments zweifelsfrei bestimmen zu können. Das bedeutet: (A4.2-6) Die vertrauenswürdige Ablage elektronischer Dokumente und Daten muss so ausgestaltet werden, dass die aus rechtlicher Sicht geforderten und vom Betreiber eines elektronischen LangzeitSpeichersystems zu erbringenden Nachweise über die Integrität und Authentizität der Dokumente und Daten noch nach langer Zeit geführt werden können. Da zu den Wesensmerkmalen elektronischer Daten und Dokumente die Flüchtigkeit und ihre fehlende Verkörperung gehören, bezeichnet Integrität im Sinne dieser Richtlinie die (technische) Fähigkeit, die Unverändertheit elektronischer Informationen nachzuweisen.

Bundesamt für Sicherheit in der Informationstechnik

39

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Die Feststellung der Authentizität elektronisch aufbewahrter Daten und Dokumente im Sinne dieser Richtlinie bezeichnet die (technische) Fähigkeit, auch nach langer Zeit den Aussteller eines elektronischen Dokumentes erkennen und zuordnen zu können. Ein rechtswirksamer Nachweis der Authentizität und Integrität elektronischer Unterlagen verlangt darüber hinaus, dass sowohl der Aussteller wie auch die Echtheit der Unterlagen durch den Nachweis der Unverfälschtheit bewiesen werden können. Beide Nachweise basieren auf elektronischen Signaturen und elektronischen Zeitstempeln ausreichender Qualität. (A4.2-7) Für elektronische Daten und Dokumente, die vor Gericht ähnlich wie private oder öffentliche Urkunden nutzbar sein sollen, ergibt sich aus § 371a Abs. 1 oder Abs. 2 ZPO die Anforderung, dass sie mit einer gültigen qualifizierten elektronischen Signatur versehen sein müssen. Hieraus folgt, ein vertrauenswürdiges Archivsystem im Sinne dieser Richtlinie muss imstande sein, (qualifizierte) elektronische Signaturen und Zeitstempel in der durch Rechtsvorschriften geforderten Qualität sicher und zuverlässig zu erzeugen, zu prüfen, zu erneuern und aufzubewahren. Die Beweiseignung kann durch den Einsatz qualifizierter elektronischer Signaturen mit Anbieterakkreditierung noch gesteigert werden, da in diesem Fall auf die für die Nachweisführung erforderliche Dokumentation bei den akkreditierten Zertifizierungsdiensteanbietern über lange Zeiträume zugegriffen und zudem die Vermutung ihrer technisch-organisatorischen Sicherheit geltend gemacht werden kann (§ 15 Abs. 1 Satz 4 SigG). Um die beweisrechtliche Eignung elektronisch signierter Daten und Dokumente für die Dauer der Aufbewahrung zu erhalten, ist zusätzlich erforderlich: (A4.2-8) Elektronisch signierte und dauerhaft aufbewahrte Dokumente und Daten müssen über den gesamten Aufbewahrungszeitraum mit einem vertretbaren zeitlichen und technischen Aufwand zugänglich, darstellbar und vollständig überprüfbar sein. Das bedeutet, sie müssen zusammen mit allen notwendigen Verifikationsdaten und erneuten elektronischen Signaturen nach § 17 SigV in einer beweiskräftigen Form mindestens für die Dauer der gesetzlich vorgeschriebenen Aufbewahrungsfristen verkehrsfähig gehalten werden. (A4.2-9) Die Forderung der langfristigen Verkehrsfähigkeit und Prüfbarkeit elektronischer Signaturen ist Voraussetzung dafür, dass sie für die Feststellung der Echtheit elektronisch aufbewahrter Daten und Dokumente herangezogen werden können. Dabei muss sichergestellt sein, dass die zur Prüfung erforderlichen Verifikationsdaten für den maßgeblichen Aufbewahrungszeitraum verfügbar sind und auf sie zugegriffen werden kann. (A4.2-10) Die für eine spätere Signaturverifikation erforderlichen Verifikationsdaten sollen daher unmittelbar nach der Signaturerstellung und/oder -prüfung beschafft und gemeinsam mit den zu archivierenden Dokumenten und Daten in langfristig verkehrsfähiger Form abgelegt werden. (A4.2-11) Die Gültigkeitsprüfung muss in jedem Falle umfassend, vollständig und so ausgestaltet sein, dass aus dem Prüfergebnis die Erfüllung der in der europäischen Richtlinie für elektronische Signaturen wie auch im Signaturgesetz festgelegten Anforderungen an fortgeschrittene und qualifizierte elektronische Signaturen festgestellt werden können. Sie muss sich darüber hinaus auf die gesamten Zertifikatsketten (Signaturzertifikate des Ausstellers, der Zertifizierungsstelle und der Wurzelzertifizierungsinstanz) sowie alle Verifikationsdaten und Zeitstempel beziehen und nachweislich erkennbar machen, dass die einer elektronischen Signatur zugrunde liegenden bzw. beigefügten Zertifikate zum Signaturzeitpunkt gültig und nicht gesperrt und die eingesetzten kryptographischen Algorithmen und Parameter zum Signaturzeitpunkt sicherheitsgeeignet waren. Sämtliche Prüfschritte und Prüfergebnisse müssen in übersichtlicher Weise nachvollziehbar protokolliert und angezeigt werden können.62 (A4.2-12) Bei der Verifikation (qualifizierter) elektronischer Signaturen soll der Signaturzeitpunkt grundsätzlich aus einem vertrauenswürdigen Zeitstempel der Signatur entnommen werden können (vgl. [HK 06], S. 85). Sofern ein solcher Zeitstempel nicht vorhanden ist und die Existenz und Authen62

40

Da die Signatur selbst lediglich durch eine digitale Zeichenfolge repräsentiert wird, sind nachprüfbare und damit beweisstützende Aussagen über die Authentizität und Integrität und damit letztlich über die Echtheit der elektronischen Daten erst über eine umfassende Signaturprüfung unter Hinzuziehung der signierten Daten, geeigneter Hard- und Software zur Anzeige der Daten, der Signaturzertifikate und der Gültigkeitsabfragen und durch eine schlüssige Interpretation der Signaturprüfergebnisse möglich. Das eCard-API-Framework [eCard-2] unterstützt die Protokollierung und Interpretation der Signaturprüfergebnisse durch die Erzeugung eines Signaturprüfberichtes in einem standardisierten Format.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

tizität der Signatur zu einem früheren Zeitpunkt nicht anderweitig belegt werden kann, muss die Verifikation bezüglich des aktuellen Zeitpunkts erfolgen. (A4.2-13) Um die Prüfbarkeit elektronisch signierter Dokumente über die gesetzlich vorgeschriebenen Aufbewahrungsfristen hin zu gewährleisten, müssen bei der Signaturerstellung standardisierte Signaturdatenformate verwendet werden. Dies betrifft neben den eigentlichen Signaturdatenformaten auch die Formate von Zertifikaten, Sperrlisten und Zertifikatsstatusabfragen sowie Zeitstempeln. Dabei muss die Kompatibilität mit den Normen und Empfehlungen der Bundesnetzagentur und des Bundesamtes für Sicherheit in der Informationstechnik sichergestellt sein (siehe hierzu [eCard-2]). Elektronische Signaturen ermöglichen es aber nur dann, die Integrität und Authentizität elektronischer Daten nachweisbar zu machen, wenn die den Signaturen zugrunde liegenden Algorithmen mathematisch und technisch sicherheitsgeeignet sind. Fortschritte in der Entwicklung von Computern und neue Methoden der Kryptographie können jedoch dazu führen, dass die Algorithmen oder ihre Parameter im Laufe der Zeit ihre Sicherheitseignung einbüßen. Ein dauerhafter und nachweisbarer Erhalt der Authentizität und Integrität elektronischer Daten erfordert deshalb den Einsatz zusätzlicher Sicherungsmittel, die den Nachweis ermöglichen, dass insbesondere elektronisch signierte Daten über die Dauer der Aufbewahrungsfristen unverfälscht aufbewahrt wurden. (A4.2-14) Elektronische Signaturen müssen rechtzeitig vor Ablauf der Sicherheitseignung der verwendeten kryptographischen Algorithmen und zugehörigen Parameter gemäß den Vorgaben des Signaturgesetzes erneuert werden. Die Signaturerneuerung muss entsprechend der rechtlichen Anforderungen sowie weitgehend automatisch und wirtschaftlich erfolgen können. Vornehmliche Intention der Erneuerung von Signaturen ist die Sicherstellung der Integrität und Authentizität der bereits signierten Dokumente. Nach geltender Rechtsauffassung ist es daher für eine erneute Signatur nach § 17 Satz 3 SigV ausreichend, wenn elektronisch signierte Daten mit einem qualifizierten Zeitstempel versehen werden, der mindestens eine qualifizierte elektronische Signatur enthält (vgl. [SFD 06, S. 178 ff., ARO 07, S. 61 ff.]). Da zudem die signierten Daten durch einen Hashwert repräsentiert werden, reicht es – sofern die Sicherheitseignung des Hashalgorithmus weiterhin gegeben ist – aus, allein die Signaturen des elektronischen Dokuments erneut mit einem Zeitstempel zu versehen und so neu zu signieren. Bei der Langzeitspeicherung elektronisch signierter Dokumente kann nur der Beweiswert erhalten werden, der von Anfang an besteht und sich letztlich natürlich daraus bestimmt, welche Anforderungen der Aufbewahrende an die Zweckerfüllung der Beweisführung stellt bzw. zu stellen verpflichtet ist. Maßgeblich für den beweisrechtlichen Wert elektronisch signierter Dokumente ist die Qualität der eingesetzten Signaturen, Signaturerstellungseinheiten, Signaturanwendungs- und Signaturprüfkomponenten. Daraus folgt: (A4.2-15) Für die Erstellung elektronischer Signaturen und Zeitstempel sind ausschließlich von der Bundesnetzagentur veröffentlichte und als sicherheitstechnisch unbedenklich eingestufte Schlüssellängen und Algorithmen zu verwenden. (A4.2-16) Qualifizierte elektronische Signaturen müssen die Anforderungen an fortgeschrittene elektronische Signaturen erfüllen und gemäß § 2 Nr. 3a SigG auf einem zum Zeitpunkt ihrer Erzeugung gültigen qualifizierten Zertifikat beruhen sowie nach § 2 Nr. 3b SigG mit einer sicheren Signaturerstellungseinheit erzeugt worden sein. (A4.2-17) Qualifizierte Zeitstempel müssen die Anforderungen von § 2 Nr. 14 SigG erfüllen. Die Vergabe qualifizierter Zertifikate ist nach § 2 Nr. 7 SigG Zertifizierungsdiensteanbietern vorbehalten, die mindestens die Sicherheitsanforderungen des Signaturgesetzes und der Signaturverordnung erfüllen. Die technische Sicherheit qualifizierter elektronischer Signaturen wird durch den Einsatz geeigneter Komponenten zur Schlüssel- und Signaturerzeugung, der Signaturanwendung und Signaturprüfung erreicht. Nach § 17 Abs. 1 SigG sind die Komponenten so zu gestalten, dass sie gegen unberechtigte Nutzung geschützt sind und sich Fälschungen von Signaturen und Manipulationen signierter Daten zuverlässig erkennen lassen. Signaturprüfkomponenten müssen nach § 17 Abs. 2 Satz 2 feststellen können, auf welche Daten sich die Signatur bezieht (Nr. 1), ob die signierten Daten unverändert sind (Nr. 2), welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist (Nr. 3), welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur beruht, und ggf. zugehörige Attributzertifikate aufweisen (Nr. 4)

Bundesamt für Sicherheit in der Informationstechnik

41

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

und zu welchem Ergebnis die Nachprüfung von Zertifikaten nach § 5 Abs. 1 Satz 2 SigG geführt hat (Nr. 5). Darüber hinaus müssen Signaturprüfkomponenten nach § 15 Abs. 2 Nr. 2 SigV die Korrektheit der Signatur zuverlässig prüfen und anzeigen sowie eindeutig erkennbar machen, ob die nachgeprüften Zertifikate zum Prüfzeitpunkt im jeweiligen Zertifikatsverzeichnis vorhanden und nicht gesperrt waren. Für die langfristige Sicherung und Überprüfbarkeit der Authentizität und Integrität elektronisch signierter Daten und Dokumente in einem vertrauenswürdigen elektronischen Archiv im Sinne dieser Richtlinie folgt daraus: (A4.2-18) Die Erstellung und Prüfung qualifizierter elektronischer Signaturen für dauerhaft und vertrauenswürdig im Sinne dieser Richtlinie aufbewahrte signierte elektronische Daten und Dokumente sollen durch nach SigG und SigV geprüfte und bestätigte Signaturanwendungskomponenten erfolgen. Für eine Visualisierung der signierten Daten, der Zertifikate und Prüfergebnisse sollen ebenfalls nach SigG und SigV geprüfte und bestätigte Anzeigekomponenten zur Verfügung stehen. (A4.2-19) Die Integrität unsignierter Daten und Dokumente soll durch Hashwerte, elektronische Signaturen und Zeitstempel bei der Aufnahme in das Archivsystem gesichert werden. (A4.2-20) Vertrauenswürdige Archivsysteme sollen deshalb imstande sein, die Integrität nicht signierter Daten ab dem Zeitpunkt der Überführung in einen elektronischen Langzeitspeicher automatisch durch elektronische Archiv(eingangs)hashwerte oder -signaturen und (qualifizierte) Archiv(eingangs)zeitstempel zu sichern (siehe dazu auch Anlage TR-VELS-M.1 und Anlage TR-VELS-M.3).

4.2.3

Datenschutz, Datensicherheit und Vertraulichkeit

Jegliche Art der Aufbewahrung elektronischer Informationen unterliegt zwangsläufig allgemeinen und gegebenenfalls auch bereichsspezifischen datenschutzrechtlichen Regelungen und Anforderungen. Für die Einrichtung und den Betrieb vertrauenswürdiger elektronischer Archivsysteme folgt daraus: (A4.2-21) Die langfristige Aufbewahrung von Daten und Dokumenten muss den gesetzlichen und bereichsspezifischen Anforderungen an den Daten- und Geheimnisschutz genügen. Insbesondere die Verarbeitung und Speicherung personenbezogener Daten im Zusammenhang mit Signaturen und den zugehörigen Verifikationsdaten muss auf ein Minimum begrenzt werden. Dabei muss zugleich sichergestellt sein, dass Unbefugte unter keinen Umständen Zugang zu personenbezogenen oder anderweitig dem Geheimnisschutz unterliegenden Daten erhalten. Datenerhebende und datenverarbeitende Stellen sind gesetzlich dazu verpflichtet, technisch-organisatorische Schutzvorkehrungen zu treffen, um die Rechte Betroffener zu schützen. Dazu gehört nicht nur der Schutz von Persönlichkeitsrechten, sondern auch der Schutz von Amts-, Berufs- und Geschäftsgeheimnissen sowie sonstigen aus rechtlichen oder auch wirtschaftlichen Beweggründen zu schützenden Geheimnissen. Das bedeutet: (A4.2-22) Spezielle, den Daten- und Geheimnisschutz betreffende Anforderungen an elektronische Langzeitspeicher müssen mit einem wirtschaftlich vertretbaren Aufwand erfüllbar sein. Das Archiv muss daher auch in der Lage sein, verschlüsselte Dokumente und Daten aufzubewahren. Das Archiv muss die Ver- und Entschlüsselung jedoch nicht zwangsläufig selbst durchführen. Soweit für bestimmte Zwecke, wie z. B. die Einstellung in einen elektronischen Langzeitspeicher oder die Transformation von Daten, Signaturen des (technischen) Archivars benötigt werden, sollten diese ggf. auch unter einem Pseudonym möglich sein. (A4.2-23) Bei der Signaturerneuerung müssen Verfahren gewählt werden, welche das Löschen von Dokumenten wie auch Zertifikaten inklusive der Verifikationsdaten nicht behindern. Die Beweiseignung der im elektronischen Langzeitspeicher verbleibenden Unterlagen darf nicht verloren gehen.

42

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

5. Funktionen des Archivsystems Aufgrund der kurzen Innovationszyklen in der Informationstechnologie sind vertrauenswürdige Archivierungsverfahren und Archivsysteme so einzurichten und umzusetzen, dass ungeachtet der fortschreitenden technologischen Entwicklung die Authentizität, Integrität und Verfügbarkeit der elektronisch gespeicherten Unterlagen gewährleistet werden kann. Dazu gehört, dass die im Langzeitspeicher abgelegten Dokumente und Daten • in Form und Inhalt authentisch und vollständig sowie technisch verfügbar aufbewahrt werden, und zwar so, dass sie auf zum Zeitpunkt der Wiedergabe dem Stand der Technik entsprechenden elektronischen Geräten wiedergegeben werden können, • nicht unberechtigt eingesehen, weitergegeben oder veröffentlicht werden können, • vor Manipulation und ungewollten oder fehlerhaften Änderungen geschützt sind sowie • Rechtsansprüche und Nachweispflichten zu gewährleisten imstande sind. Der erste Abschnitt dieses Kapitels beschreibt die Funktionen des Archivsystems, die aus Anwendersicht vorhanden und nutzbar sein müssen. Nachfolgend werden die wichtigsten organisatorischen Aspekte angesprochen, die eine Behörde oder ein Unternehmen bei der Einführung und während des Betriebs eines vertrauenswürdigen Archivsystems im Sinne dieser Richtlinie zu beachten hat. Hierbei ist zu bedenken, dass diese Hinweise nur eine grobe Orientierung liefern können und kein umfassendes Sicherheitskonzept aller organisatorischer Belange darstellen. Hierzu sei auf Kapitel 8 verwiesen.

Abbildung 2: Anwendungsfälle für die elektronische Archivierung *) siehe dazu auch den Hinweis in Kapitel 5.1.4

Bundesamt für Sicherheit in der Informationstechnik

43

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

5.1

BSI TR 03125

Funktionale Anforderungen

Die funktionalen Anforderungen legen fest, welche Funktionen ein zu dieser Richtlinie konformes Archivsystem aus Sicht eines Benutzers zur Verfügung stellen muss. Dabei werden, wie in Abbildung 2 dargestellt, die folgenden grundsätzlichen Anwendungsfälle unterschieden:63 •

die Ablage (Archivierung) unsignierter und signierter Daten,

•

der Abruf archivierter Daten,

•

der Abruf beweisgeeigneter Nachweise über die Authentizität und Integrität der aufbewahrten Daten und

•

das Löschen von Daten64 .

Grundsätzlich gilt: (A5.1-1) Der Zugriff auf das elektronische Archivsystem zu Zwecken der Ablage, der Recherche, des Abrufs oder des Löschens abgelegter Dokumente und Daten muss in jedem Falle nachweisbar (z.B. protokolliert) über definierte Schnittstellen aus den vorgelagerten IT-Anwendungen erfolgen. Unberechtigte Zugriffe sind durch das System zuverlässig zu verhindern.

5.1.1

Archivierung signierter und unsignierter Daten

(A5.1-2) Eine rechtssichere Ablage elektronischer Dokumente und Daten muss zu jedem Zeitpunkt aus externen IT-Anwendungen und/oder vorgelagerten Prozessen heraus über einen sicheren Kommunikationskanal und in einem zu dieser Richtlinie konformen Datenformat möglich sein. Um die Ablage von Daten und Dokumenten zu verhindern, deren Format nicht für eine dauerhafte und plattformübergreifende Aufbewahrung geeignet ist, wird zusätzlich gefordert: (A5.1-3) Das Archivsystem muss vor der Ablage im Langzeitspeicher die Syntax der zur Aufbewahrung übergebenen Archivdatenobjekte auf Konformität mit dem für die Archivierung durch die Nutzer und Betreiber eines Archivsystems definierten und spezifizierten Datenformate prüfen. Bei Nichtübereinstimmung muss die Ablage im Langzeitspeicher abgelehnt werden (siehe auch Abbildung 3). (A5.1-4) Zur Vollständigkeit der Archivierung muss gewährleistet sein, dass alle zur langfristigen Aufbewahrung vorgesehenen Dokumente und Daten zuverlässig und nachweislich im Langzeitspeicher des Archivierungssystems abgelegt werden. Das Archivsystem quittiert den vorgelagerten IT-Anwendungen die ordnungsgemäße Speicherung der zur Aufbewahrung übergebenen Dokumente und Daten durch die Rückgabe eines eindeutigen Dokument-Identifikators. (A5.1-5) Bei der Ablage im Archivsystem muss jedem archivierten Dokument oder Datensatz ein eindeutiger Archivdatenobjekt-Identifikator (AOID für Archiv Objekt ID) zugewiesen werden. Über diesen Archivdatenobjekt - Identifikator erfolgt in den vorgelagerten IT-Anwendungen die Verknüpfung zu mindestens einem Ordnungskriterium des zugehörigen Geschäftsvorfalls (z. B. Belegnummer, Vorgangs- oder Aktenzeichen). Die Archivdatenobjekt ID dient der zuverlässigen Wiederauffindbarkeit der gespeicherten Dokumente und Daten sowie als Schlüssel für die autorisierte Rückgabe oder Löschung von Daten. (A5.1-6) Archivseitig ist die eindeutige Verknüpfung und deren Nachweisbarkeit zu gewährleisten und sicherzustellen, dass zwei Dokumenten nicht die gleiche Archivdatenobjekt-ID zugewiesen wird. (A5.1-7) Die Ablage der Archivdatenobjekt-Identifikation erfolgt im Regelfall in einer Datenbank auf einem Archivserver. Um bei Integritäts- oder Verfügbarkeitsverlust dieser Datenbank einen Neu63

64

44

Weitere Funktionen wie z. B. „Suchen“ (auch geschäftsanwendungsübergreifend), „Prüfen der Beweisdaten“ sind sicherlich wünschenswert, für den Beweiswerterhalt jedoch nicht notwendig. Diese Technische Richtlinie beschränkt sich daher auf die oben aufgeführten vier Basisfunktionen. In der vorliegenden Technischen Richtlinie wird die Langzeitspeicherung in Behörden bzw. Unternehmen betrachtet. Aussonderungen gemäß den Archivgesetzen (BArchG) führen in diesem Kontext zum Löschen der Daten in dem behördeneigenen Langzeitspeichersystem. (siehe auch A5.1-25).

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

aufbau der Indexinformationen zu ermöglichen, soll die Archivdatenobjekt-ID (zusätzlich) gemeinsam mit den archivierten Objekten abgelegt werden. (A5.1-8) Zu welchem Zeitpunkt Daten und Dokumente in einem elektronischen Archiv abgelegt werden, ist abhängig von der in der Unternehmensorganisation festgelegten Entscheidung der gesetzlichen Vertreter. Soweit die Ablage der zu archivierenden Daten und Dokumente im Archivsystem in den vorgelagerten Anwendungssystemen manuell ausgelöst wird, ist sicherzustellen, dass dieser Vorgang nur durch die dazu autorisierten Personen vorgenommen wird.

Abbildung 3: Typischer Archivierungsablauf

(A5.1-9) Für die Aufbewahrung signierter Daten muss das Archivsystem die Möglichkeit vorsehen, die Signaturen vor der Übergabe an den Langzeitspeicher umfassend zu prüfen und die Prüfergebnisse gemeinsam mit den signierten Daten abzulegen. (A5.1-10) Für die Beweiswerterhaltung elektronischer Signaturen müssen bei einem drohenden Verlust der Sicherheitseignung der für die Signatur verwendeten Algorithmen und zugehörigen Parameter nach § 17 SigV die signierten Daten unter Einbeziehung aller bereits bestehenden Signaturen mit erneut signiert werden. Daraus folgt: (A5.1-11) Ein vertrauenswürdiges und rechtssicheres Archivsystem im Sinne dieser Richtlinie muss imstande sein, eine gesetzeskonforme Signaturerneuerung über sämtliche im Langzeitspeicher aufbewahrten, elektronisch signierten Daten und Dokumente durchzuführen. Die Lösung muss effizient, wirtschaftlich und kompatibel zum „Evidence Record Syntax“- Standard der IETF [RFC4998]65 sein (siehe dazu auch Anlage TR-VELS-M.3 „ArchiSig-Modul“ dieser Richtlinie).

65

Alternativ zur ASN.1 Spezifikation des [RFC4998] kann nach der Standardisierung durch die IETF auch die XMLSpezifikation der Evidence Record Syntax [ERSXML] zugrunde gelegt werden.

Bundesamt für Sicherheit in der Informationstechnik

45

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

(A5.1-12) Der dauerhafte Nachweis der Integrität unsignierter Daten und Dokumente, zumindest ab dem Zeitpunkt des Übergangs in das Archivsystem, soll durch einen elektronischen Archiv-EingangsHashwert, eine elektronische Archiv-Eingangs-Signatur bzw. einen elektronischen Archiv-EingangsZeitstempel zusätzlich sichergestellt werden. Die benötigte Qualität des Archiv-Eingangs-Hashwerts, der Archiv-Eingangs-Signatur bzw. des Archiv-Eingangs-Zeitstempels bestimmt sich aus dem erforderlichen oder auch beabsichtigten Beweiszwecken.

5.1.2

Abruf (Rückgabe) archivierter Daten

Beim Abruf von archivierten Daten kann es sich sowohl um komplette Aktenstrukturen, einzelne Dokumente oder nur Elemente von Dokumenten handeln. Diese Unterscheidungen werden hier nicht getroffen sondern werden erst bei der technischen Definition in Kapitel 7 wieder aufgegriffen. (A5.1-13) Der Abruf (die Rückgabe) archivierter Daten muss aus den vorgelagerten IT-Anwendungen über einen sicheren Kommunikationskanal erfolgen. (A5.1-14) Für den Abruf (die Rückgabe) archivierter Daten muss eine gültige Archiv-Objekt Identifikation (AOID) an das Archivsystem übergeben werden. Das Archivsystem quittiert im Erfolgsfall die Anfrage mit der Rückgabe des zur Archivdatenobjekt ID gehörigen Archivdatenobjektes. (A5.1-15) Der Abruf archivierter Daten kann durch geeignete Suchfunktionen unterstützt werden (siehe dazu auch TR-VELS-M.1, Kap. 4.6). Durch das Archivsystem ist dabei sicher zu stellen, dass mit diesen Suchfunktionen nur solche Archivdatenobjekte und deren Metainformationen zurückgeliefert werden, für die die aufrufende Anwendung auch die Zugriffsberechtigung besitzt.

5.1.3

Abruf von Beweisdaten

(A5.1-16) Ein vertrauenswürdiges und rechtssicheres Archivsystem im Sinne dieser Richtlinie muss imstande sein, auf Anforderung beweisrechtliche Belege für die Echtheit und Unverfälschtheit von Archivdatenobjekten zu erbringen. Die Archivdatenobjekte werden dabei anhand ihrer AOID identifiziert. (A5.1-17) Beim Abruf des Nachweises der Echtheit und Unverfälschtheit von Archivdatenobjekten muss das Archivsystem sämtliche elektronische Beweisdaten erstellen und zurück geben. Die elektronischen Beweisdaten müssen sämtliche Informationen enthalten, die zur Verifikation der Authentizität und Integrität der gespeicherten Daten, deren Signaturen, Zertifikaten und der Signaturerneuerungen benötigt werden.

5.1.4

Löschen archivierter Daten

Am Ende des ‚Lebenszyklus‘ eines Archivdatenobjektes, d. h. in der Regel nach dem Ablauf gesetzlich vorgeschriebener Aufbewahrungsfristen, kann das Objekt aus dem Archiv gelöscht werden. Da dieser Vorgang für ein vertrauenswürdiges Archiv im Sinne dieser Richtlinie ein äußerst kritischer Vorgang ist, muss durch geeignete technische und organisatorische Maßnahmen eine besonders zuverlässige und nachvollziehbare Durchführung gewährleistet werden. HINWEIS: Nach Ablauf der vorgeschriebenen Mindestaufbewahrungsfristen können Archivdatenobjekte in der öffentlichen Verwaltung dann aus dem Langzeitspeicher gelöscht werden, wenn diese zuvor dem zuständigen Archiv angeboten und von diesem übernommen wurden bzw. wenn das Archiv die Ermächtigung zum Löschen erteilt hat. (A5.1-18) Archivierte Dokumente und Daten dürfen in der Regel nur unter den folgenden Voraussetzungen vernichtet (gelöscht) werden: 46

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

•

Der Aufbewahrungszeitraum bei elektronisch archivierten Dokumenten bzw. Daten ist abgelaufen.

•

Es bestehen keine weiteren gesetzlichen Vorschriften, die die Existenz der archivierten Dokumente und Daten verlangen.

•

Es bestehen keine innerbetrieblichen Regelungen oder sonstigen organisatorischen Anforderungen, die einem Löschen im Wege stehen.

•

Es besteht kein Herausgabeanspruch Dritter auf die archivierten Dokumente und Daten.

•

Es besteht ein Rechtsanspruch auf das Löschen archivierter Dokument und Daten.

(A5.1-19) Das Löschen von Daten und Dokumenten nach Ablauf des gesetzlich vorgeschriebenen Aufbewahrungszeitraums kann durch technisch und organisatorisch berechtigte Nutzer derjenigen vorgelagerten IT-Anwendung angestoßen werden, die auch die Archivierung der zu löschenden Daten veranlasst hat oder durch einen zentralen Prozess, der diese Funktion für das gesamte Archiv ausführt und entsprechend berechtigt ist. (A5.1-20) Das Löschen von Daten und Dokumenten vor Ablauf des gesetzlich vorgeschriebenen Aufbewahrungszeitraums muss durch technisch und organisatorisch berechtigte Nutzer derjenigen vorgelagerten IT-Anwendung angestoßen werden, die auch die Archivierung der zu löschenden Daten veranlasst hat. Der Löschauftrag muss eine gültige Archivdatenobjekt-ID und eine Begründung für das Löschen enthalten.66 (A5.1-21) Mit Blick auf zu erfüllende datenschutzrechtliche Bestimmungen oder Aufbewahrungsfristen muss das Löschen einzelner elektronisch signierter Dokumente und / oder Daten einschließlich zugehöriger Signaturen mit einem wirtschaftlich vertretbaren Aufwand möglich sein. (A5.1-22) Die Beweiskraft der im Langzeitspeicher verbleibenden Dokumente muss bei Löschen anderer Archivdatenobjekte erhalten bleiben. (A5.1-23) Um die Nachvollziehbarkeit des Handelns zu gewährleisten, muss der Löschvorgang protokolliert werden. Die Protokolle sind gemäß der jeweils relevanten rechtlichen und/oder betrieblichen Vorschriften aufzubewahren. (A5.1-24) Die im Archiv verbleibenden Daten dürfen nicht dafür geeignet sein, die gelöschten Informationen wiederherzustellen.67 Hinweis: Wenn explizite Anforderungen auf nicht-wiederherstellbares Löschen von einzelnen Daten/ Dokumenten bestehen, müssen solche Anforderungen auch auf das Backup-System ausgedehnt werden können oder es darf kein Backup angefertigt werden. (A5.1-25) Die gesetzlichen Vorgaben gemäß dem Archivgesetz BArchG für Behörden hinsichtlich eines geordneten Aussonderungsprozesses unter Einbindung der Archivbehörde sind im Rahmen des Löschens archivierter Daten einzuhalten.

5.2

Organisatorische Anforderungen

Die organisatorischen Anforderungen legen die nicht-technischen Bedingungen fest, die vorzugsweise bereits vor oder bei der Einführung eines elektronischen Archivierungssystems geschaffen werden müssen.

66

67

Es ist hier anzumerken dass die entsprechenden Geschäftsanwendungen eine Funktion für vorzeitiges Löschen nur dann implementieren sollen, wenn es aus fachlicher Sicht auch die Notwendigkeit für eine solche Funktion gibt. Auch wenn ein Backup der Daten erstellt wurde, muss gemäß der gesetzlichen Regelungen gelöscht werden.

Bundesamt für Sicherheit in der Informationstechnik

47

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Die Einrichtung vertrauenswürdiger Archivsysteme68

5.2.1

(A5.2-1) Die gesetzlichen Vertreter eines Unternehmens oder einer Behörde tragen die Verantwortung dafür, dass im Rahmen der IT-Strategie ein langfristiges Konzept zum Einsatz von Archivierungsverfahren aufgestellt und mit dem IT-Sicherheitskonzept abgestimmt wird. Im Rahmen dieses Konzepts sind Festlegungen zu treffen, die eine langfristige gesetzeskonforme Aufbewahrung, Verwaltung und Nutzung der archivierten Daten und Dokumente sicherstellen und die Verfügbarkeit des Archivsystems unter Berücksichtigung des erwarteten Datenvolumens unter Einhaltung der gesetzlichen Aufbewahrungspflichten gewährleistet. (A5.2-2) Zur Erfüllung der gesetzlichen Aufbewahrungspflichten muss beim Einsatz von Archivierungsverfahren über den gesamten Prozess der Archivierung gewährleistet sein, dass alle Dokumente und Daten gemäß dem Archivierungskonzept erfasst werden, für welche die elektronische Archivierung zulässig bzw. notwendig ist oder festgelegt wurde. Ferner muss sichergestellt werden, dass die Daten und Dokumente für die Dauer der Aufbewahrungspflicht innerhalb angemessener Zeit wiedergegeben werden können und keine Daten und Dokumente verloren gehen. (A5.2-3) Um auch bei notwendig werdenden Systemwechseln eine langfristige und den gesetzlichen Aufbewahrungszeiträumen entsprechende Aufbewahrung zu gewährleisten, sind neben den Konzepten zur regelmäßigen Erfassung, Speicherung, Archivierung und Lesbarmachung von elektronisch gespeicherten Daten und Dokumenten auch geeignete Migrationskonzepte für den Einsatz neuer Systeme zu entwickeln. (A5.2-4) Ferner sind Festlegungen zur Integration des Archivierungssystems in die IT-Infrastruktur, zur Identifikation, Auswahl und Verwaltung der zu archivierenden Daten und Dokumente sowie zur periodischen Überprüfung der Angemessenheit des langfristigen Archivierungskonzepts zu treffen.

5.2.2

Anforderungen an die Einsatzumgebung

(A5.2-5) Eine wesentliche Voraussetzung für die Sicherheit und Ordnungsmäßigkeit der elektronischen Archivierung ist ein angemessenes Problembewusstsein der gesetzlichen Vertreter und der Mitarbeiter für mögliche Risiken beim Einsatz von Archivierungsverfahren (geeignetes IT-Umfeld). Dafür sind vor allem bei der Einführung oder Änderung von Archivierungsprozessen die beteiligten Mitarbeiter auf der Grundlage einer aussagekräftigen und vollständigen Verfahrensdokumentation ausreichend zu schulen und einzuweisen. (A5.2-6) Die Beschreibung der Archivierungsprozesse ist schriftlich festzulegen. Die VerfahrensDokumentation dient zum Verständnis der Archivierungsprozesse und ist damit ebenfalls aufbewahrungspflichtig. (A5.2-7)

Der Archivierungsprozess besteht im Regelfall aus den Teilaktivitäten

•

Erzeugung der Archivdatenobjekte aus den zur Archivierung vorgesehenen Dokumenten, Daten und Metainformationen,

•

Indexierung und ggf. Verschlagwortung der Archivdatenobjekte,

•

Speicherung und Verwaltung der Archivdatenobjekte im Archivierungssystem,

•

Suche/Abfrage von Archivdatenobjekten ,

•

Vernichtung der archivierten Dokumente und Daten einschließlich der Metadaten und Prüfinformationen nach Ende der Aufbewahrungsfrist, sofern dem nicht gesetzliche oder verwaltungsrechtliche Regelungen69 entgegenstehen,

und ist in den vorgelagerten IT-Anwendungen in geeigneter Weise zu unterstützen. 68

69

48

Für die Konzeption elektronischer Archivsysteme siehe auch Baustein B1.12 Archivierung – IT-Grundschutzkataloge – 10. EL Stand 2008 des BSI unter https://www.bsi.bund.de/cln_174/ContentBSI/grundschutz/kataloge/baust/b01/b01.html Zum Beispiel die Anbietepflicht an das Bundesarchiv.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

(A5.2-8) Insbesondere sind die folgenden Bereiche für alle archivierungspflichtigen und archivierten Daten und Dokumente im Rahmen der Ablauforganisation zu regeln: •

Identifikation der aufbewahrungspflichtigen Dokumente und Daten.

•

Festlegung des Archivierungszeitpunktes (Belegstatus), der Archivierungsfrequenz und der Archivierungsprozesse.

•

Festlegung der Aufbewahrungsfristen für die elektronisch zu archivierenden Daten und Dokumente.

•

Festlegung der Archivierungsprozesse und Archivformate sowie der technischen und organisatorischen Maßnahmen zur Sicherstellung der Vollständigkeit und Richtigkeit der Archivierung sowie der Wiedergabequalität.

•

Beschreibung eines eindeutigen und nachvollziehbaren Verfahrens zur Erzeugung und Verwaltung eindeutiger Archivdatenobjektschlüssel (Archiv Objekt ID) und der eindeutigen Zuordnungsfähigkeit der archivierten Dokumente und Daten zu den zugrunde liegenden Geschäftsprozessen.

•

Löschung und Lesbarmachung archivierter Dokumente und Daten.

•

Sicherung von archivierten Datenbeständen.

•

Verfahren zum Zugriff auf Dokumente und Daten – auch in ausgelagerten Archivdatenbeständen.

•

Verfahren zum nachprüfbaren und vollständigen Wiederanlauf von gesicherten Archivdatenbeständen (Restart, Recovery)

•

Festlegung von Aufgaben und Verantwortlichkeiten sowie der Einführung und Kontrolle der Archivierungsprozesse.

(A5.2-9) In Organisationsanweisungen ist der Regelbetrieb des Archivierungssystems festzulegen, etwa die Aufgaben und Befugnisse von Administratoren, Regelungen zum Change-Management und zur Verwaltung von Speichermedien.

Bundesamt für Sicherheit in der Informationstechnik

49

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

6. Abgeleitete technische Anforderungen Der folgende Abschnitt beschreibt abgeleitete und vornehmlich technische Anforderungen, die bei der Einrichtung und dem Betrieb eines zu dieser Richtlinie konformen elektronischen Archivsystems zu erfüllen sind.

6.1

Systemtechnische Anforderungen

(A6.1-1) Um proprietäre, d. h. produkt- oder herstellerabhängige Lösungen zu vermeiden, muss die Integrierbarkeit elektronischer Archivlösungen in bestehende Informationssysteme sowie die Interoperabilität, Verfügbarkeit und Verkehrsfähigkeit der verwendeten Formate für die Nutzdaten, die Metainformationen, Signaturen, Zeitstempel und Signaturprüfinformationen (Verifikationsdaten) mindestens für die Dauer der gesetzlich vorgeschriebenen Aufbewahrungsfristen gewährleistet werden können. (A6.1-2) Die für die Langzeitspeicherung signierter elektronischer Dokumente eingesetzten Verfahren und technischen Lösungen dürfen die weitere Verwendbarkeit der elektronischen Dokumente für unterschiedliche Anwendungszwecke und in unterschiedlichen Anwendungssystemen (Fachverfahren) nicht beeinträchtigen. Durch Verfahren und technische Lösungen der Langzeitspeicherung und der Erneuerung von Signaturen dürfen insbesondere keine Behinderungen entstehen für: •

den Austausch von Dokumenten zwischen Anwendungssystemen,

•

den Wechsel von Datenformaten in Anwendungssystemen,

•

den Austausch von Anwendungssystemen oder -komponenten.

(A6.1-3) Im Interesse der dauerhaften Verfügbarkeit und Verkehrsfähigkeit der zu archivierenden Dokumente und Daten sollen ausschließlich Archivformate eingesetzt werden, die eine plattform- und herstellerunabhängige Archivierung in langfristig verkehrsfähiger Form ermöglichen. (A6.1-4) Technische Lösungen zur vertrauenswürdigen Langzeitspeicherung müssen eine sichere, externe Administration und Konfiguration unterstützen.

6.2

Empfohlene Dokumentformate

Dieser Abschnitt beschäftigt sich mit den Formaten, die für die eigentlichen Nutzdaten – die Primärinformationen – verwendet werden können bzw. sollen. Der nächste Abschnitt hingegen beschreibt Daten und Datenstrukturen, die für die tatsächliche Speicherung im Archivsystem empfohlen werden. (A6.2-1) Das DOMEA-Organisationskonzept 2.170 und die Standards und Architekturen für E-Government-Anwendungen (SAGA)71 empfehlen, ebenso wie die von der Europäischen Kommission geförderte Anforderungsspezifikation für die elektronische Schriftgutverwaltung („Model Requirements for the Management of Electronic Records - Moreq272), für die langfristige Ablage von elektronischem Schriftgut nur wenige und einheitliche Datenformate zu benutzen. Kapitel 4 von [TR-VELS-F] führt im Detail die empfohlenen Formate auf.

70 71 72

50

Siehe http://www.kbst.bund.de/domea Siehe http://www.kbst.bund.de/saga Siehe http://ec.europa.eu/transparency/archival_policy

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

6.3

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Empfohlene Speicherformate

Um die Vollständigkeit des Zugriffs auf elektronisch archivierte Informationen einschließlich der Begründung und Zweckbestimmung der Archivierung jederzeit und zweifelsfrei herstellen zu können und dem Programm von Bund, Ländern und Kommunen für die Standardisierung des Datenaustausches in und mit der öffentlichen Verwaltung73 folgend, wird deshalb für ein zu dieser Richtlinie konformes elektronisches Archivsystem gefordert: (A6.3-1) Inhaltsdaten, Metadaten und Verifikationsdaten74 langfristig aufzubewahrender Daten und Dokumente müssen in einem abgeschlossenen und selbst-erklärenden Archivdatenobjekt (Archival Information Package, AIP75) auf der Basis von XML (kurz XAIP für: XML formatted Archival Information Package) und einer formalisierten Dokumenttypbeschreibung in XML-Syntax (XML-Schema) in einem elektronischen Langzeitspeicher abgelegt und verwaltet werden können.76 Die Aufbewahrung von Daten und Dokumenten in einem selbst-erklärenden Archivdatenobjekt auf Basis von XML unterstützt nicht nur die Plattform- und Produktneutralität von Archivsystemen und damit auch die Verkehrsfähigkeit und beweiserhaltende Migration archivierter Daten, sondern erleichtert darüber hinaus auch die Prozess- und Verarbeitungsfähigkeit bei der Ablage und Prüfung aufzubewahrender Daten und Dokumente.77 Eine ausführliche Darstellung der Syntax und Semantik eines geeigneten XAIP-Dokuments findet sich in Kapitel 3 von Anlage [TR-VELS-F] „Protokolle und Formate“ dieser Richtlinie. Ein zu dieser Technischen Richtlinie konformes Archivdatenobjekt ist ein wohlgeformtes XML Dokument mit folgenden Merkmalen78: ● XML Standard Ein zu dieser Richtlinie konformes Archivdatenobjekt erfüllt die XML 1.1 Spezifikation [XML]. ●

73

74

75

76

77

78

XML Schema

Die gemeinsam von Bund, Ländern und Kommunen verabredete Standardisierung des Datenaustausches soll die automatisierte und medienbruchfreie Datenverbindung zwischen Kommunen, Landes- und Bundesbehörden und ihren Kunden ermöglichen. Ziel dieses Vorhabens im Rahmen des Aktionsplans Deutschland Online ist die Schaffung eines gemeinsamen, durch Bund, Länder und Kommunen getragenen Gesamtkonzepts für die Entwicklung und den bundesweiten Einsatz von einheitlichen fachlichen Datenformaten und Datenstrukturen (fachliche Standards) und technischer Schnittstellen zum elektronischen Austausch von Geschäfts- und Verwaltungsnachrichten innerhalb und mit der öffentlichen Verwaltung auf der Grundlage von XML. Mehr dazu unter http://www.deutschland-online.de Es handelt sich dabei um Signaturen und die zugehörigen Zertifikate sowie um die Prüfinformationen zu diesen Signaturen und Zertifikaten. Im Fall einer Migration in ein neues Archivsystem können hier auch die ERS-Beweisdaten aus dem alten Archivsystem enthalten sein. Die Bezeichnung folgt der Notation des Referenzmodells für Offene Archivinformationssysteme (OAIS) der Nationalen Luft- und Raumfahrtbehörde der USA. Mehr dazu unter http://public.ccsds.org/publications/archive/650x0b1.pdf Es ist anzumerken, dass sich das Volumen von binären Inhaltsdaten um ca. 36% vergrößert, wenn sie für das Einbetten in ein XML-Objekt BASE64-codiert werden. Damit erhöht sich auch die Wahrscheinlichkeit, dass die Objekte eine Größe erreichen bzw. überschreiten, die eine automatische Verarbeitung verhindern. Auf syntaktischer Ebene unterstützt XML als textbasierte Meta-Auszeichnungssprache nicht nur die Beschreibung, sondern vor allem die automatisierte Darstellung, Manipulation und Verarbeitung logisch strukturierter Daten und zeichnet sich darüber hinaus durch eine gute Erweiterbarkeit und eine große Flexibilität aus. Auf semantischer Ebene unterstützen Regeln und Strukturdefinitionen in XML-Syntax (XML-Schema) die Abbildung strukturierter Inhaltsmodelle. XML-Schemata erlauben nicht nur die formale und maschinenlesbare Beschreibung eines für den Datenaustausch erlaubten XML-Vokabulars, sondern darüber hinaus den Aufbau komplexer Datenstrukturen und die Formulierung von Verarbeitungsanweisungen. Ein Archivdatenobjekt (XAIP) im Sinne dieser Technischen Richtlinie ist ein vor allem fachlich spezifiziertes und abgestimmtes Datenaustauschformat (Datenschnittstelle), d. h. eine einheitliche und verbindliche semantische Definition und Beschreibung einer Datenstruktur in XML-Syntax mit einem für die langfristige und vertrauenswürdige elektronische Speicherung aufbewahrungspflichtiger Daten relevanten Kontext (Vokabular).

Bundesamt für Sicherheit in der Informationstechnik

51

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Sämtliche gültige Archivdatenobjekte können gegen eine autorisierte und maschinenlesbare Dokumenttypbeschreibung in XML Syntax, d. h. eine gültige XML Schemadatei [XSD] validiert werden. ●

XML Namensraumstandard Alle zu dieser Richtlinie konformen Archivdatenobjekte auf XML Basis erfüllen die XML Namensraumkonventionen [XML Name].

●

Einbettung binärer Objekte Binäre Daten werden gemäß der MIME Base64 Spezifikation kodiert und eingebettet [BASE64].79

(A6.3-2) Um zu gewährleisten, dass die im Langzeitspeicher abgelegten Dokumente auch ohne Zuhilfenahme der vorgelagerten IT-Anwendungen durch Dritte interpretiert und verifiziert werden können, müssen aus den vorgelagerten IT-Anwendungen heraus auch zusätzliche Metainformationen generiert und gemeinsam mit den Dokumenten und Daten in langfristig verkehrsfähiger Form im Langzeitspeicher abgelegt werden können. Der Umfang dieser „beschreibenden“ Metadaten ergibt sich aus den Anforderungen der IT-Anwendungen, sollte aber, nicht zuletzt im Sinne geltender Datenschutzund Geheimnisschutzbestimmungen, so restriktiv wie möglich gehandhabt werden. (A6.3-3) Den Empfehlungen nationaler (SAGA80, XÖV81, ArchiSafe82) und internationaler (Moreq283, OASIS84) Standardisierungsinitiativen folgend, soll die Darstellung und Umsetzung der Archivdatenobjekte und von Schnittstellen für den Datenaustausch zwischen den Komponenten und Bestandteilen eines zu dieser Richtlinie konformen Archivsystems grundsätzlich über XML und entsprechende Schemadefinitionen oder vergleichbare offene, standardisierte Datenformate beschrieben und realisiert werden. In der Anlage TR-VELS-F dieser Technischen Richtlinie ist ein Datenformat beschrieben, das diesen Anforderungen Rechnung trägt.85 (A6.3-4) Grundsätzlich sind die technischen Lösungen hinsichtlich des angestrebten Sicherheitsniveaus elektronischer Signaturen und der in diesem Zusammenhang jeweils notwendigen Verifikationsdaten skalierbar zu gestalten. Hierzu gehört insbesondere, dass die technischen Konzepte und Lösungen den Betrieb mandantenfähiger Lösungen unterstützen. Das bedeutet:

79

80 81 82 83 84 85

52

•

in Abhängigkeit vom Dokumenttyp und dem jeweiligen Aufbewahrungszweck müssen spezifische Parametrierungen (Aufbewahrungsdauer, Hinzufügen von Verifikations- und/oder Metadaten etc.) möglich sein,

•

spezielle Anforderungen, wie etwa die Integritätssicherung logisch zusammengehöriger Dokumente (z. B. Vollständigkeit von Akten), müssen auf Anforderung berücksichtigt werden können.

Es ist zu beachten, dass sich die Datenmenge von binären Objekten beim Einsatz von BASE64 um ca. 36% erhöht. Es steigt damit auch die Wahrscheinlichkeit, dass die Datenobjekte eine Größe erreichen, die eine automatische Weiterverarbeitung verhindert. siehe http://www.kbst.bund.de/saga siehe http://www.deutschland-online.de/Standardisierung siehe http://www.archisafe.de siehe http://ec.europa.eu/transparency/archival_policy siehe http://docs.oasis-open.org/ Anlage TR-VELS-F dieser Technischen Richtlinie beschreibt grundsätzliche syntaktische und semantische Strukturen für ein zu dieser Richtlinie konformes Archivdatenobjekt, elektronische Datenformate für die langfristige Aufbewahrung von Nutzdaten und Metadaten sowie Strukturen, Formate und Algorithmen für die Erzeugung und Interpretation kryptographischer Daten, die für die langfristige Sicherung der Integrität, Authentizität und Beweiskraft elektronischer Dokumente (Objekte) geeignet sind.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

6.4

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

IT-Infrastruktur

Die technischen Sicherungsmaßnahmen eines vertrauenswürdigen Archivierungssystems im Sinne dieser Richtlinie umfassen physische Sicherungsmaßnahmen, logische Zugriffskontrollen sowie Datensicherungs- und Auslagerungsverfahren für den Regel- und den Notbetrieb. (A6.4-1) Durch physische Sicherungsmaßnahmen ist die IT-Infrastruktur beim Einsatz von Archivierungsverfahren und die Speichermedien vor Verlust, Zerstörung sowie unberechtigter Veränderung zu schützen. (A6.4-2) Neben den Zugriffsschutzmechanismen der vorgelagerten IT-Anwendungen muss zum Schutz der archivierten Daten und Dokumente auch im Archivsystem ein geeignetes Berechtigungskonzept implementiert werden. (A6.4-3) Das Archivsystem muss geeignete Maßnahmen vorsehen und implementieren, die eine unzulässige Manipulation oder den Austausch von Komponenten oder Modulen des Systems zuverlässig verhindern. (A6.4-4) Von den Speichermedien können Sicherungs-Kopien angefertigt und an einem räumlich vom Archivierungssystem getrennten Standort ausgelagert werden. (A6.4-5) Zur Sicherung der Lesbarkeit der Speichermedien über die gesamte Aufbewahrungsfrist sind vom Medientyp abhängige Kontrollen und Maßnahmen vorzusehen, wie etwa der regelmäßige Test auf Lesbarkeit der Speichermedien. (A6.4-6) Bei redundant ausgelegten Archivierungssystemen ist zu testen, ob die Funktionsübergabe bei Ausfall eines Teilsystems ordnungsgemäß erfolgt und ob bei Wiederanlauf des ausgefallenen Systems ein ordnungsgemäßer Abgleich der Daten zwischen den Systemen erfolgt. (A6.4-7) Zur Sicherstellung des Betriebs des Archivierungssystems müssen Maßnahmen, die beim Ausfall eines Archivierungssystems ergriffen werden müssen, in einem Notfallkonzept festgehalten werden. Im Fall einer ungeplanten Unterbrechung während eines Archivierungslaufes ist nach Wiederanlauf sicherzustellen, dass die Konsistenz der Daten gewährleistet ist.

6.5

IT-Anwendungen beim Einsatz von Archivierungsverfahren

(A6.5-1) Bei den zur Archivierung eingesetzten IT-Anwendungen handelt es sich im Regelfall um Softwaresysteme, die an die organisationsspezifischen Besonderheiten und Archivierungsanforderungen anzupassen sind. Die zur Archivierung eingesetzten IT-Anwendungen oder IT-Services sollen folgende Mindestanforderungen erfüllen: •

die Erzeugung der zu archivierenden Daten in definierten langfristig verkehrsfähigen und standardisierten Datenformaten (z. B. PDF oder XML, vgl. Kapitel 6.2),

•

das Erzeugen bzw. Prüfen von elektronischen Signaturen hinreichender Qualität,

•

Schnittstellenfunktionalitäten zur Ablage, zum Abruf und Löschen archivierter Dokumente und Daten auf der Basis der vom Archivsystem zurückgegebenen Archivdatenobjekt-IDs (AOID),

•

die Protokollierung durchgeführter Archivoperationen,

•

die zuverlässige Verwaltung und Zuordnung der Archivdatenobjekt-IDs (AOID’s) zu den zugehörigen Geschäftsprozessen und der Ablageorte der archivierten Daten86.

(A6.5-2) Folgende Zugriffsmethoden müssen dabei durch Schnittstellenfunktionalitäten des Archivsystems grundsätzlich unterstützt werden:

86

Bei der Migration von Fachanwendungen ist selbstverständlich auch die Migration der AOIDs zu berücksichtigen. Nur so kann die neue Fachanwendung später auf die archivierten Daten der Altanwendung zugreifen.

Bundesamt für Sicherheit in der Informationstechnik

53

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

•

das Ablegen von signierten und unsignierten Archivdatenobjekten im Archiv mit der Archivdatenobjekt-ID (AOID) als Rückgabewert,

•

die Übergabe einer gültigen Archivdatenobjekt-ID (AOID) für den Abruf archivierter Archivdatenobjekte,

•

der Abruf von technischer Belegdaten zum Nachweis der Authentizität und Integrität der archivierten Informationen,

•

das Löschen87 von Archivdatenobjekten aus dem Archiv nach der Übergabe einer gültigen Archivdatenobjekt-ID (AOID). Der Löschvorgang wird dabei nicht vom Archivsystem initiiert sondern nur protokolliert. Ein vollständiges und explizites Löschen (im Sinne einer unwiederbringlichen Vernichtung) von archivierten Objekten muss auch vor Ablauf der bei der Archivierung übergebenen Aufbewahrungsfrist möglich sein.

(A6.5-3) Der Zugriff externer, vorgelagerter IT-Anwendungen oder IT-Services auf das Archivsystem darf nur über definierte Schnittstellen und sichere Kommunikationskanäle erfolgen. (A6.5-4) Die externen IT-Anwendungen müssen über sichere Zugriffsschutzmechanismen auf der Grundlage eines zuverlässigen und konfigurierbaren Berechtigungssystems verfügen.

87

54

Im Falle einer (Bundes-)Behörde stößt die IT-Anwendung nach Abgabe des Schriftguts an die Archivbehörde das Löschen des Schriftgutes im Langzeitspeichersystem an.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

7. IT-Architektur Die IT-Architektur eines zu dieser Richtlinie konformen elektronischen Archivsystems muss die in dieser technischen Richtlinie aufgeführten Anforderungen (insbesondere die geforderte Funktionalität aus den Kapiteln 5 und 6 und die Anforderungen aus Kapitel 4) zuverlässig umsetzen. In diesem Abschnitt wird eine hersteller- und produktunabhängige IT-Referenzarchitektur empfohlen, die alle aufgeführten Anforderungen erfüllt und daher die Basis für eine entsprechende Umsetzung sein kann. Auf der Grundlage dieser IT-Referenzarchitektur werden systemlogische Komponenten und Schnittstellen grob identifiziert und beschrieben. Die weitere, ausführliche Spezifikation der identifizierten logischen Komponenten und Schnittstellen erfolgt in den Anlagen zu dieser Technischen Richtlinie. HINWEIS: Es sei darauf hingewiesen, dass die hier beschriebene Aufteilung der Funktionen auf die Module der IT-Referenzarchitektur nicht verpflichtend ist. Ein zu dieser Technischen Richtlinie konformes System muss jedoch alle Funktionen in der erforderlichen Qualität und auf dem notwendigen Sicherheitsniveau anbieten.

7.1

Empfohlene IT-Referenzarchitektur

Abbildung 4: Referenzarchitektur Übersicht

Die empfohlene IT-Referenzarchitektur ist in Abbildung 4 dargestellt und besteht im Wesentlichen aus den folgenden logischen Komponenten und Schnittstellen:

Bundesamt für Sicherheit in der Informationstechnik

55

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

•

vorgelagerten Anwendungen (hier als Beispiel ein ERP-System, ein DMS-System, ein e-Mail-System und weitere), die das Archivsystem für die langfristige, rechts- und revisionssichere Ablage elektronischer Daten und Dokumente nutzen,

•

einem Archiv Gateway (TR-VELS-M.1: ArchiSafe Modul), dass für eine Entkopplung von Anwendungssystemen und Archivsystem sowie für eine effektive und zuverlässige Zugriffskontrolle auf das Archiv sorgen soll,

•

einem Krypto-Modul (TR-VELS-M.2), das alle erforderlichen Funktionen zur Erstellung (optional) und Prüfung elektronischer Signaturen, zur Nachprüfung elektronischer Zertifikate und zum Einholen qualifizierter Zeitstempel für das Archivsystem sowie Schnittstellen zu Zertifizierungs- und Zeitstempeldiensteanbietern und ggf. auch Funktionen zur Verschlüsselung von Daten und Dokumenten zur Verfügung stellt,

•

einem ArchiSig-Modul (TR-VELS-M.3), das die erforderlichen Funktionen für die Beweiswerterhaltung der archivierten Datenobjekte bereithält,

•

einem Langzeitspeicher zur eigentlichen Datenspeicherung (TR-VELS-M.4). Dies umfasst sowohl die Speicherung der eigentlichen Archivdatenobjekte als auch aller vom Archiv-system zusätzlich erzeugten und verwalteten Daten (z. B. zur Beweiswertsicherung oder allgemeiner Archiv-Verwaltungsinformationen). Die Ablage der durch das ArchiSig-Modul erzeugten kryptographischen Beweisdaten soll dabei zumindest logisch getrennt in einem eigenen Speicherbereich oder besser physikalisch getrennt in einer eigenen Speichereinheit erfolgen.

•

verschiedenen Kommunikationskanälen und Schnittstellen, u. a.

-

die Anwendungsschnittstelle (TR-VELS-M.5: XML­Adapter) zwischen den vorgelagerten Anwendungen und dem Archiv Gateway. Dieses anwendungsspezifische Modul bildet die Archivschnittstelle in eine anwendungsspezifische Schnittstelle ab.

-

Die Schnittstellen zwischen den internen Komponenten des elektronischen Archivsystems (benannt nach dem Schema TR-VELS-S.x).

Der gebrochen gezeichnete Rahmen in Abbildung 4 zeigt den inhaltlichen Umfang dieser Technischen Richtlinie auf. Weder die Fachanwendungen noch der Zertifizierungsdiensteanbieter sind Gegenstand dieser Technischen Richtlinie. Alle Komponenten innerhalb der Umrahmung müssen jedoch Konformität zu den in dieser Technischen Richtlinien getroffenen Definitionen nachweisen.

7.2

Alternative Architekturen

Insofern alle in den Kapiteln 4 bis 6 beschriebenen Anforderungen an das elektronische Archivsystem auch mit einer anderen IT-Architektur bzw. einer angepassten IT-Referenzarchitektur erfüllt werden, ist eine derartige IT-Architektur prinzipiell auch zulässig. Die weitere Beschreibung der Technischen Richtlinie, insbesondere die detaillierteren Beschreibungen in den Anhängen, bezieht sich jedoch immer auf die oben aufgeführte und empfohlene Referenzarchitektur.

7.3

Komponenten und Module

Es folgt eine kurze Beschreibung der verschiedenen Komponenten und Module der IT-Referenzarchitektur, weitergehende Beschreibungen und Detaillierungen erfolgen in den Anlagen (siehe dazu auch Kapitel 10 „Anlagen“).

7.3.1

Vorgelagerte Anwendungssysteme

In den vorgelagerten Anwendungssystemen (IT-Fachanwendungen, Dokumentenmanagement- oder Vorgangsbearbeitungssystemen, etc.) werden die später zu archivierenden Dokumente und Daten er-

56

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

zeugt und bearbeitet. Bis zum Zeitpunkt der Archivierung werden sie dabei auf den zu diesen Anwendungssystemen gehörenden Datenspeichern vorgehalten. (A7.3-1) Sämtliche in Kapitel 5.1 „Funktionale Anforderungen“ beschriebenen Archivoperationen müssen durch das betreffende Anwendungssystem angestoßen (initiiert) werden können.88 (A7.3-2) Eine Anwendung im Sinn dieser Richtlinie kann aus mehreren Einzelkomponenten oder Programmen bestehen. Es ist nicht notwendigerweise ein monolithisches Programm oder ein einzelnes System. (A7.3-3) Die Anwendung oder die Anwendungsumgebung muss über ein eigenes zuverlässiges und sicheres Identifikations- und Authentisierungssystem verfügen. (A7.3-4) Es ist organisatorisch sicher zu stellen, das nur die autorisierten Benutzer auch tatsächlich die notwendigen Berechtigungen innerhalb der Anwendung erhalten bzw. besitzen. (A7.3-5) Falls aus fachlicher Sicht, d. h. durch Rechtsvorschriften oder sonstige Regelungen, geboten, muss die Anwendung bzw. der Anwender imstande sein, die zu archivierenden Nutzdaten vor der Ablage im Archivsystem mit einer elektronischen Signatur in einer durch die Rechtsvorschriften oder sonstigen Regelungen geforderten Qualität zu versehen. Für die Ausführung der Signatur gelten die Regelungen des Signaturgesetzes (SigG) und der Signaturverordnung (SigV) in der zum Zeitpunkt der Signatur jeweils gültigen Fassung. (A7.3-6) Für die Anzeige von qualifiziert signierten elektronischen Daten und Dokumenten soll die Anwendung oder die Anwendungsumgebung eine bestätigte vertrauenswürdige Anzeigekomponente (Trusted Viewer) zur Verfügung stellen. Die Bestätigung muss durch eine anerkannte Bestätigungsstelle gemäß §18 SigG erfolgen. (A7.3-7) Um die Gültigkeit der Signatur über die Dauer der gesetzlich vorgeschriebenen Aufbewahrungsfristen nachweisen zu können, wird empfohlen, mit der Ausführung der Signatur zugleich sämtliche für den Gültigkeitsnachweis der Signatur erforderlichen Verifikationsdaten zu beschaffen und gemeinsam mit den Signaturdaten innerhalb des Datenspeichers der Geschäftsanwendung abzulegen. Der Umfang der erforderlichen Verifikationsdaten bestimmt sich vornehmlich aus dem Ziel der erforderlichen Nachweissicherung (siehe dazu auch Kapitel 4.1 „Rechtliche Rahmenbedingungen“).89, 90

7.3.2

XML-Adapter zur Anbindung von Geschäftsanwendungen an das Archiv (TR-VELS-M.5)

Die XML-Adapter sind anwendungsspezifische oder anwendungstypspezifische Datenkonverter, die aus den Daten und Dokumenten der vorgelagerten Anwendungen das einheitliche, XML basierte Datenformat des elektronischen Archivs erzeugen. Dies kann auch die Konvertierung von proprietären Datenformaten in offene Datenformate (z.B. PDF/A) beinhalten. Über die XML-Adapter wird auch die standardisierte Kommunikation mit dem zentralen Archiv­Gateway, dem ArchiSafe-Modul, geführt. Der XML-Adapter übernimmt dabei die Rolle eines standardisierten Konnektors. (A7.3-8) Grundsätzlich kann ein solcher Adapter in verschiedenen Ausprägungen implementiert werden: •

88

89

90

als (fester) Bestandteil der Anwendung, d. h. als anwendungsintegrierte Archivierungsschnittstelle

Auch an dieser Stelle sei noch einmal darauf hingewiesen, dass die Funktion für vorzeitiges Löschen eine fachliche Berechtigung benötigt und für die rechtssichere Aufbewahrung nicht zwingend notwendig ist. Verifikationsdaten müssen nach [SFD 06] nicht notwendigerweise beschafft und aufbewahrt werden, wenn sie vom Zertifizierungsdiensteanbieter mindestens solange vorgehalten werden, wie das signierte Dokument aufbewahrt werden muss. Hintergrund dieser Forderung ist, dass zwischen dem Zeitpunkt der Signaturerstellung und der eigentlichen Archivierung eine beträchtliche Zeitspanne liegen kann. Das Archivsystem prüft zwar laut Empfehlung die enthaltenen Signaturen bei Archiveingang, kann die Gültigkeit der dafür genutzten Zertifikate zum Signaturerstellungszeitpunkt jedoch nur dann prüfen, wenn die Zertifizierungsdiensteanbieter entsprechende Informationen noch vorhalten. Ist dies nicht (mehr) der Fall, kann die enthaltene Signatur nicht geprüft werden und die Beweiskraft der Daten ist quasi verloren.

Bundesamt für Sicherheit in der Informationstechnik

57

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

•

als eigenständiger Dienst, der Datenstrukturen und Kommunikationsprotokoll in die standardisierten Formate des elektronischen Archivs überführt

•

als (fester) (mandantenfähiger) Bestandteil des Archiv-Gateway

Insbesondere bei der letztgenannten Variante ist jedoch sicherzustellen, dass z. B. Blockaden des XML-Adapters durch fehlerhafte Anwendungen oder sicherheitstechnische Fehlfunktionen eines einzelnen XML-Adapters nicht zu einer generellen Fehlfunktion des gesamten Archiv­Gateways führt. Daher ist diese Variante (XML-Adapter ist architektonischer Bestandteil des Archiv­Gateways) in der Regel nicht zu empfehlen. Bei der zweiten Möglichkeit (eigenständiger Dienst) kann man die Möglichkeit in Betracht ziehen, mehrere gleichartige Anwendungen (z. B. mehrere Module eines SAP-Systems oder mehrere SAPSysteme unterschiedlicher Mandanten eines Archivierungsdienstleisters) über genau einen XML-Adapter in das Archiv zu führen. Hierbei ist jedoch insbesondere aus Sicherheitssicht sicherzustellen, dass weder eine anwendungsübergreifende Kommunikation über den XML-Adapter möglich ist, noch dass eine Anwendung auf die archivierten Unterlagen einer anderen Anwendung zugreifen kann. Die erste Möglichkeit (Bestandteil der Anwendung) kann sich wiederum in zwei Alternativen aufspalten: •

Inhärenter Teil der Anwendung. Dies bedeutet, die Geschäftsanwendung implementiert die Archivschnittstellen direkt.

•

Modul für die Geschäftsanwendung. Dies bedeutet, die Archivschnittstellen sind in einem eigenständigen Modul (im Sinn einer Bibliothek) implementiert, das von der Geschäftsanwendung direkt genutzt wird. Die Geschäftsanwendung braucht also, um das Archiv nutzen zu können, selbst nicht angepasst zu werden. Diese Option ist die empfohlene Methode im Sinne dieser Technischen Richtlinie.

Der XML-Adapter soll, je nach Gesamtarchitektur des Archivs und Bedarf, mandantenfähig sein. (A7.3-9) Der XML-Adapter muss in der Lage sein, alle Funktionen des ArchiSafe-Moduls, an das er angeschlossen ist, korrekt zu nutzen und eine sichere und zuverlässige Kommunikation in beide Richtungen (Anwendung und Archiv) korrekt abzubilden.

7.3.3

ArchiSafe-Modul91 (TR-VELS-M.1)

Das ArchiSafe-Modul ist ein einheitliches und sicheres Archiv-Gateway, welches den Zugriff von Geschäftsanwendungen auf den Langzeitspeicher kontrolliert. Ziel ist die Realisierung einer einheitlichen Archivschnittstelle, die eine strikte logische Trennung der vorgelagerten Anwendungssysteme (den IT-Fachanwendungen) von den eigentlichen Langzeitspeichersystemen und den weiteren Archivdiensten (Services) gewährleistet und so imstande ist, unberechtigte Zugriffe zuverlässig zu verhindern. Die sicherheitstechnischen Anforderungen an ein solches ArchiSafe-Modul wurden produktunabhängig in einem Schutzprofil (Protection Profile) nach Common Criteria [CC] spezifiziert [ACMPP]. (A7.3-10) Jeder Zugriff auf das Archivsystem von Seiten der Anwender bzw. der Anwendungssysteme muss über das ArchiSafe-Modul erfolgen, eine andere Zugriffsmöglichkeit muss durch geeignete technische Maßnahmen ausgeschlossen werden.

91

58

Der Name „ArchiSafe“ bezieht sich auf das E-Government Projekt „ArchiSafe – rechts- und revisionssichere Langzeitspeicherung elektronischer Dokumente“ der Physikalisch-Technischen Bundesanstalt im Jahre 2005, das im Rahmen der E-Government Programms „BundOnline 2005“ gefördert wurde. Ziel des Projektes war die Spezifikation und Umsetzung einer service-orientierten informationstechnischen Lösung für die rechts- und revisionssichere Langzeitspeicherung elektronischer Dokumente (mehr dazu unter: http://www.archisafe.de).

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

(A7.3-11) Das ArchiSafe-Modul muss den Anforderungen des zum Zeitpunkt der Archivierung gültigen und durch das Bundesamt für Sicherheit in der Informationstechnik (BSI) veröffentlichten Schutzprofils genügen und erfolgreich gemäß dieses Schutzprofils durch das BSI zertifiziert worden sein.

7.3.4

Krypto-Modul (TR-VELS-M.2)

Das Krypto-Modul stellt verschiedene kryptographische Funktionen, die für die vertrauenswürdige elektronische Langzeitspeicherung benötigt werden, bereit. Dies umfasst im Wesentlichen kryptographische Verfahren, die für die Erzeugung und Verifikation von elektronischen Signaturen benötigt werden, Mechanismen zur Einholung und Verifikation von qualifizierten Zeitstempeln sowie ggf. Funktionen zur Verschlüsselung von Daten und Dokumenten.. (A7.3-12) Das Krypto-Modul kann in verschiedenen Ausprägungen implementiert sein: •

als eigenständiges Hardware-Modul, das über spezielle Hardwareschnittstellen vom Archivsystem angesprochen wird,

•

als Mischung aus Hardware und Software; das Archivsystem greift auf die Funktionen dieses Moduls ausschließlich über die angebotenen Softwareschnittstellen zu, oder

•

sämtliche kryptographischen Funktionen sind komplett in Software implementiert. Das Krypto-Modul wird als Bibliothek eingebunden und von anderen Software-Paketen des Archivsystems genutzt.

(A7.3-13) Das Krypto-Modul muss mindestens die Anforderungen an eine Signaturanwendungskomponente nach § 2 Nr. 11 SigG erfüllen, da qualifizierte elektronische Signaturen mittels dieses Moduls auf ihre Gültigkeit hin überprüft werden müssen. Das Erzeugen von qualifizierten elektronischen Signaturen ist optional. (A7.3-14) Ist das Modul imstande und vorgesehen qualifizierte elektronische Signaturen selbst zu erstellen, z. B. im Rahmen der Erzeugung von Zeitstempeln, müssen die dafür mit dem Modul eingesetzten Soft- oder Hardwareeinheiten die Anforderungen an eine sichere Signaturerstellungseinheit nach § 2 Nr. 10 SigG erfüllen. (A7.3-15) Da sich die für gesetzeskonforme elektronische Signaturen zulässigen Algorithmen und Parameter ändern können, muss ein schneller und unkomplizierter Austausch nicht mehr sicherheitsgeeigneter oder sicherheitsgefährdeter Algorithmen und Parameter des Krypto-Moduls durch sicherheitsgeeignete Algorithmen und Parameter jederzeit möglich sein. (A7.3-16) Falls die Schnittstellen des Krypto-Moduls oder das gesamte Krypto-Modul in Software implementiert sind, sollen sie die Anforderungen der Technischen Richtlinie TR-03112 (eCard-API Framework) des BSI in der aktuell gültigen Fassung erfüllen.

7.3.5

ArchiSig-Modul92 (TR-VELS-M.3)

Das ArchiSig-Modul stellt vornehmlich Funktionen für den Erhalt und die Erneuerung der Beweiskraft elektronischer Signaturen sowie für die Integrität der archivierten Datenobjekte (XAIP) bereit (ausführlicher in der Anlage TR-VELS-M.3 dieser Richtlinie). Für alle kryptographischen Funktionen greift das ArchiSig-Modul auf das bereits vorgestellte KryptoModul zurück. Das ArchiSig-Modul muss also selbst keine kryptographischen Funktionen implementieren. 92

Der Name „ArchiSig“ bezieht sich auf das Verbundprojekt „ArchiSig – Beweiskräftige und sichere Langzeitarchivierung digital signierter Dokumente“, das in den Jahren 2001 bis 2003 vom Bundesministerium für Wirtschaft und Arbeit im Rahmen des Programms „VERNET - Sichere und verlässliche Transaktionen in offenen Kommunikationsnetzen“ gefördert wurde. Ziel des Projektes war die Entwicklung einer gesetzeskonformen, wirtschaftlichen und leistungsfähigen informationstechnischen Lösung für eine beweiskräftige und sichere Langzeitarchivierung digital signierter Dokumente (mehr dazu unter: http://www.archisig.de)

Bundesamt für Sicherheit in der Informationstechnik

59

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

(A7.3-17) Das ArchiSig-Modul kann Modul-Charakter besitzen und damit leicht austauschbar sein. (A7.3-18) Das ArchiSig-Modul soll in der Lage sein, in mehreren Instanzen parallel zu arbeiten, insbesondere was den Fall der Neusignatur des kompletten Archives angeht. In diesem Fall bedarf es jedoch noch eines steuernden Objektes, das die Arbeiten der einzelnen ArchiSig-Instanzen steuert. (A7.3-19) Die einzelnen Instanzen sollen auf einer als auch auf unterschiedlichen Maschinen laufen können, um sowohl die Bandbreite als auch die Rechenleistung voll auszunutzen. (A7.3-20) Das ArchiSig-Modul muss auch während der kompletten Neusignierung des Archivs die laufenden Anfragen aus dem regulären Betrieb in akzeptabler Zeit bedienen können.

7.3.6

Der Langzeitspeicher (TR-VELS-M.4)

Der Langzeitspeicher stellt die Datensenke des elektronischen Archivs dar. Die archivierten Daten und Dokumente sind hier sicher gespeichert, inklusive aller für die langfristige Aufbewahrung und Verfügbarkeit nötigen Verkehrs- und Verwaltungsinformationen. (A7.3-21) Es kann sich um einen Speicher handeln, der sowohl die Archivdatenobjekte als auch die Verwaltungsinformationen und die Daten zur Integritäts- und Authentizitätssicherung enthält (u.a. die Hashbäume). Die beiden Datenarten können auch in unterschiedlichen Speichern abgelegt werden. (A7.3-22) Es kann sich um eine beliebige Art von Speichersystem (SAN, NAS, Festplattensystem mit beliebigem Dateisystem, relationale Datenbank, objektorientierte Datenbank, XML-fähige Datenbank, Archivsystem, etc.) handeln, solange dieses System alle anderen Anforderungen erfüllt. (A7.3-23) Das Speichersystem kann physisch in mehrere Speicher aufgeteilt sein; auch in Speicher mit unterschiedlichen Schnittstellen, Kapazitäten, physischen Merkmalen wie z. B. Medien, Anbindungsart (Latenzzeit, Bandbreite), Standorten, etc.

7.3.7

Die Kommunikationskanäle und Schnittstellen

Die IT-Referenzarchitektur beinhaltet verschiedene Kommunikationskanäle und Schnittstellen innerhalb des Archivs (ausführlicher in den Anlagen TR-VELS-S.1 bis TR-VELS-S.6). Im Wesentlichen sind dabei zu unterscheiden die •

Archiv-externen Schnittstellen: zu den Anwendungen oder zu den Zertifizierungsdiensteanbietern

•

Archiv-internen Schnittstellen: z. B. zwischen dem ArchiSafe-Modul und dem Krypto-Modul

Nicht enthalten in Abbildung 4 sind notwendige administrative Schnittstellen zu den einzelnen Komponenten. Diese sind in der Regel produktspezifisch ausgeprägt (z. B. als textbasiertes interaktives Interface, als Konfigurationsdatei, als web-basierte Administrationsschnittstelle, etc.) und spielen für diese Technische Richtlinie nur eine untergeordnete Rolle.93 (A7.3-24) Schnittstellen zur Administration des Gesamtsystems oder einzelner Komponenten dürfen nur ausdrücklich berechtigten Personen zugänglich sein.

93

60

Neben den in den Anlagen zu diesem Dokument beschriebenen funktionalen und technischen Aspekten der Schnittstellen (Daten-, Aufrufformate, etc.) sind bei der Einrichtung eines elektronischen Archivsystems an dieser Stelle insbesondere auch Aspekte der Verfügbarkeit und Performance zu beachten. Daraus ergeben sich weitere projekt- und produktspezifische Detailarchitekturfragestellungen, wie beispielsweise nach der geeigneten Kommunikationsinfrastruktur (z. B. synchrone oder asynchrone Kommunikationsbeziehungen, Implementierung von Datenpuffern und Warteschlangen, usw. ). Diese lassen sich nicht pauschal beantworten, sondern nur unter Berücksichtigung des Volumens der zu erwartenden Archivanfragen und der Größe der zu speichernden Archivdatenobjekte sowie der Anzahl und der Standorte der anzuschließenden Anwendungen.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

(A7.3-25) Schnittstellen zur Administration des Gesamtsystems oder einzelner Komponenten dürfen unter keinen Umständen die Sicherheitseigenschaften des Systems oder einzelner Komponenten sowie Integrität und Authentizität der gespeicherten Daten und Dokumente kompromittieren.

7.4

Zusammenspiel der Komponenten

Der folgende Abschnitt veranschaulicht das Zusammenspiel der Komponenten in der dargestellten ITReferenzarchitektur an den wesentlichen Anwendungsfällen (siehe Abbildung 2 auf Seite 43), der Archivierung elektronischer (signierter) Daten, dem Abruf archivierter Daten und technischer Beweisdaten und dem Löschen archivierter Daten.

7.4.1

Archivierung elektronischer Unterlagen

Für die Archivierung elektronischer Unterlagen ist auf der Grundlage der IT-Referenzarchitektur folgender grundsätzlicher Ablauf vorgesehen (siehe Abbildung 5). Dabei wird aus Gründen der Übersichtlichkeit hier nur der positive Fall angegeben. Zudem wird vorausgesetzt, dass jedem Funktionsaufruf und Transport von Daten über eine der in Abbildung 4 der IT-Referenzarchitektur benannten Schnittstellen eine erfolgreiche technische Authentisierung auf der Vermittlungs-, Transport- oder Anwendungsschicht zwischen den beteiligten Modulen vorausgegangen ist (vgl. A8.2-11 und A8.2-12). Darüber hinaus sind an allen Entscheidungsknoten entsprechende Fehlerabfragen und Verzweigungen im Prozess vorzusehen. Schritt 1:

OPTIONAL - Die zu archivierenden Inhaltsdaten werden innerhalb der Geschäftsanwendung mit einer elektronischen Signatur versehen. Je nach Datenformat kann die Signatur dabei direkt in die Nutzdaten eingebettet sein oder als eigenständiges Objekt (z. B. als Datei) existieren.

Schritt 2:

Die (signierten) Inhaltsdaten und Metainformationen94 werden dem XML-Adapter von der Geschäftsanwendung übergeben. Das hier verwendete Format hängt im Wesentlichen von der Geschäftsanwendung ab und kann daher nicht näher spezifiziert werden.95

Schritt 3:

Der XML-Adapter erzeugt aus den (signierten) Inhaltsdaten und den Metainformationen ein Archivdatenobjekt in XML-Syntax (XAIP-Dokument) gemäß eines definierten XMLSchemas (siehe auch Kapitel 6.3.1 und Anlage TR-VELS-F). In die Metadaten ist mindestens das Ende des Aufbewahrungszeitraums, das Format der Nutzdaten und ein eindeutiges Authentisierungsmerkmal der zuständigen Fachanwendung einzutragen.

Schritt 4:

94

95

Der XML-Adapter übergibt das Archivdatenobjekt an das ArchiSafe-Modul zur Archivierung über die Schnittstelle TR-VELS-S.4 (siehe Abbildung 4). Der Aufruf enthält das Archivdatenobjekt (XAIP-Dokument) und das Authentisierungsmerkmal der Fachanwendung, falls nicht bereits eine authentisierte Verbindung aufgebaut wurde.

Signaturen der Nutzdaten, die nicht direkt in die Nutzdaten eingebettet sind, werden hier unter dem Begriff Metadaten subsumiert. Der XML-Adapter behandelt die Signaturen jedoch etwas anders und speichert sie vor allen an einer anderen Stelle im XAIP – in der DataCredentialSection. Gemäß [ACMPP] bekommt das ArchiSafe-Modul neben den zu archivierenden Daten auch eine geschäftsanwendungsspezifische ID der Daten mit übergeben. Diese ID übergibt das ArchiSafe-Modul nach der erfolgreichen Archivierung zusammen mit der neu generierten AOID zurück an die Geschäftsanwendung, damit diese sicher einen Bezug zwischen AOID und archivierten Daten herstellen kann (hier Schritt 20). In dieser Technischen Richtlinie wird dies lediglich als Option spezifiziert und in der Prozessbeschreibung oben nicht aufgeführt, da dieses Vorgehen nur bei manchen technischen Implementierungen tatsächlich notwendig ist. Allerdings wird das in [ACMPP] beschriebene Verfahren durchaus empfohlen.

Bundesamt für Sicherheit in der Informationstechnik

61

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Schritt 5:

Das ArchiSafe-Modul überprüft die Zugriffsberechtigung der Geschäftsanwendung auf der Grundlage des im Aufrufs übergebenen Authentisierungsmerkmals und die Syntax des übergebenen XML-Dokuments auf Basis eines im ArchiSafe-Moduls hinterlegten und autorisierten XML-Schemas. Das XML-Schema ist kunden- und einsatzspezifisch.

Schritt 6:

Falls das ArchiSafe-Modul so konfiguriert ist, dass Signaturen geprüft werden müssen, übergibt das ArchiSafe-Modul das komplette Archivdatenobjekt zur Signaturprüfung an das Krypto-Modul über die Schnittstelle TR-VELS-S.1 (siehe Abbildung 4).96

Schritt 7:

Das Krypto-Modul verifiziert die mathematische Richtigkeit der in den Nutzdaten oder in der DataCredentialSection des XML-Dokuments (siehe Kap. 6.3.1 und Anlage TRVELS-F) enthaltenen Signaturen.

Schritt 8:

Das Krypto-Modul validiert die Gültigkeit der zugeordneten Zertifikate über eine Abfrage beim Zertifikatsaussteller (i.d.R. ein Zertifizierungsdiensteanbieter). Dazu muss ein Zertifizierungspfad bis hin zu einer, aus Sicht des Prüfenden, vertrauenswürdigen Zertifizierungsinstanz gebildet und geprüft werden.

Schritt 9:

Der Zertifizierungsdiensteanbieter liefert eine Bestätigung der Gültigkeit der angefragten Zertifikate als OCSP- oder SCVP-Antwort zurück (siehe Anlage TR-VELS-M.2).

Schritt 10: Die Prüfergebnisse (OCSP/SCVP-Antworten) werden vom Krypto-Modul unverändert in das Archivdatenobjekt in die DataCredentialSection des XAIP-Dokuments eingetragen. Schritt 11: Das Krypto-Modul liefert das so angereicherte Archivdatenobjekt dem ArchiSafe-Modul über die Schnittstelle TR-VELS-S.1 zurück. Schritt 12: Das angereicherte Archivdatenobjekt wird über die Schnittstelle TR-VELS-S.6 (siehe Abbildung 4) dem ArchiSig-Modul zum Aufbau des Archiv-Zeitstempels übergeben (siehe auch Anlage TR-VELS-M.3) Schritt 13: Das ArchiSig-Modul erzeugt eine neue AOID für dieses Archivdatenobjekt oder lässt vom Langzeitspeicher eine AOID erzeugen und trägt diese AOID als Attribut in das XAIP-Dokument ein (siehe Kapitel 6.3.1 und Anlage TR-VELS-F). Schritt 14: Das ArchiSig-Modul übergibt über die Schnittstelle TR-VELS-S.3 (siehe Abbildung 4) das komplette Archivdatenobjekt an das Krypto-Modul, um über dieses Archivdatenobjekt einen Hashwert zu erzeugen.

96

62

Falls im XAIP bereits Prüfinformationen zu den enthaltenen Signaturen und Zertifikaten enthalten sind (vgl. A7.3-7), braucht das ArchiSafe-Modul dieses XAIP nicht mehr zur Signaturprüfung an das Krypto-Modul zu übergeben. Die Schritte 7 bis 11 können dann übersprungen werden. Allerdings ist empfehlenswert, dass das Verhalten von ArchiSafe für diese Situation konfigurierbar ist.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Abbildung 5: Schematischer Ablauf der Archivierung

Schritt 15: Das Krypto-Modul liefert den Hashwert im MessageImprint-Format [RFC3161] über die Schnittstelle TR-VELS-S.3 (siehe Abbildung 4) an das ArchiSig-Modul zurück. Schritt 16: Das ArchiSig-Modul speichert diesen Hashwert zusammen mit der AOID im Hashbaum ab (siehe Anlage TR-VELS-M.3). Schritt 17: Das ArchiSig-Modul übergibt das Archivdatenobjekt über die Schnittstelle TR-VELS-S.2 (siehe Abbildung 4) an den Langzeitspeicher zur Persistierung. Schritt 18: Der Langzeitspeicher quittiert die erfolgreiche Speicherung, z. B. durch Rückgabe der AOID.

Bundesamt für Sicherheit in der Informationstechnik

63

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Schritt 19: Das ArchiSig-Modul gibt an das ArchiSafe-Modul über die Schnittstelle TR-VELS-S.6 (siehe Abbildung 4) die AOID als positive Rückmeldung zurück. Schritt 20: Das ArchiSafe-Modul gibt die AOID über die Schnittstelle TR-VELS-S.4 (siehe Abbildung 4) als Bestätigung für die erfolgreiche Archivierung an den aufrufenden XML-Adapter zurück. Dieser liefert die AOID an die Geschäftsanwendung. Zu einem späteren Zeitpunkt erstellt das ArchiSig-Modul über die in letzter Zeit erzeugten Hashwerte einen initialen Archivzeitstempel und baut damit den ArchiSig-Hashbaum auf. Dieser Prozess erfolgt nicht unmittelbar bei der Archivierung, sondern in der Regel periodisch und automatisiert angestoßen. Details finden sich im Anhang TR-VELS-M.3.

7.4.2

Abfrage archivierter Daten

Für den Abruf archivierter elektronischer Unterlagen ist auf der Grundlage der IT-Referenzarchitektur folgender grundsätzlicher Ablauf vorgesehen (siehe auch Abbildung 6). Auch hier wird vom positiven Fall ausgegangen, die notwendigen Fehlerprüfungen und Verzweigungen sind aus Gründen der Übersichtlichkeit im Ablauf nicht berücksichtigt. Zudem wird vorausgesetzt, dass jedem Funktionsaufruf und Transport von Daten über eine der in Abbildung 4 der IT-Referenzarchitektur benannten Schnittstellen eine erfolgreiche technische Authentisierung auf der Vermittlungs-, Transport- oder Anwendungsschicht des TCP/IP-Schichtenmodells97 zwischen den beteiligten Modulen vorausgegangen ist. Schritt 1:

Die Geschäftsanwendung stellt eine Anfrage zum Abruf archivierter Daten über den XML-Adapter an das Archivsystem. Das Format der Anfrage richtet sich nach der Geschäftsanwendung. Es muss allerdings die AOID des abzufragenden Archivdatenobjektes enthalten sein. Die Geschäftsanwendung legt bei diesem Aufruf per Parameter fest, ob der gesamte XML-Container, nur die Nutzdaten, nur die Metadaten oder eine Kombination davon zurückgeliefert werden sollen.

Schritt 2:

Der XML-Adapter richtet die Anfrage zum Abruf archivierter Daten an das ArchiSafeModul über die Schnittstelle TR-VELS-S.4 (siehe Abbildung 4). Die Anfrage muss die zu den archivierten Daten gehörige Archivdatenobjekt-ID (AOID) und ein eindeutiges Authentisierungsmerkmal der Fachanwendung enthalten.

Schritt 3:

Das ArchiSafe-Modul überprüft die Zugriffsberechtigung der Geschäftsanwendung auf der Grundlage des im Aufrufs übergebenen Authentisierungsmerkmals.

Schritt 4:

Das ArchiSafe-Modul fragt das mittels AOID identifizierte Archivdatenobjekt vom Langzeitspeicher über die Schnittstelle TR-VELS-S.5 (siehe Abbildung 4) ab.

Schritt 5:

Der Langzeitspeicher gibt das zu der AOID gehörige Archivdatenobjekt über die Schnittstelle TR-VELS-S.5 (siehe Abbildung 4) an das ArchiSafe-Modul zurück. Das Archivdatenobjekt wird dabei bitgenau vom Langzeitspeicher reproduziert. ArchiSafe erhält das Archivdatenobjekt also exakt so, wie es ursprünglich archiviert wurde (siehe Kapitel 7.4.1 Schritt 17).

Schritt 6:

Das ArchiSafe-Modul gibt das Archivdatenobjekt über die Schnittstelle TR-VELS-S.4 (siehe Abbildung 4) an den XML-Adapter zurück.

Schritt 7:

Der XML-Adapter gibt das komplette Archivdatenobjekt (XAIP) oder die extrahierten Inhalts- und Metadaten an die Geschäftsanwendung zurück.98

97

64

Siehe dazu bspw. [BLESS 05], Seite 22

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Abbildung 6: Schematischer Ablauf des Abrufs archivierter Daten

7.4.3

Rückgabe technischer Beweisdaten

Zur Verifikation der Integrität und Authentizität der archivierten Daten können die zugehörigen Beweisdaten (Evidence Record, siehe auch Kapitel 6.3.2 und Anlage TR-VELS-M.3) aus dem Archiv abgefragt werden. Der nachfolgend beschriebene Ablauf geht von der vorgestellten IT-Referenzarchitektur aus und beschreibt ausschließlich den positiven Fall (siehe auch Abbildung 7). Die notwendigen Fehlerprüfungen und Verzweigungen sind aus Gründen der Übersichtlichkeit im Ablauf nicht berücksichtigt. Zudem wird vorausgesetzt, dass jedem Funktionsaufruf und Transport von Daten über eine der in Abbildung 4 der IT-Referenzarchitektur benannten Schnittstellen eine erfolgreiche technische Authentisierung auf der Vermittlungs-, Transport- oder Anwendungsschicht des TCP/IP-Schichtenmodells99 zwischen den beteiligten Modulen vorausgegangen ist. Schritt 1:

Die Geschäftsanwendung stellt eine Anfrage bezüglich der Beweisdaten archivierter Daten an den XML-Adapter. Das Format der Anfrage richtet sich nach der Geschäftsanwendung. Es muss allerdings die AOID des nachzuprüfenden Archivdatenobjektes enthalten sein.

Schritt 2:

Der XML-Adapter ruft das per AOID spezifizierte XAIP-Dokument aus dem Langzeitspeicher über das ArchiSafe-Modul ab. Dies erfolgt gemäß der Prozessbeschreibung in Kapitel 7.4.2.

Schritt 3:

Das ArchiSafe-Modul ruft das per AOID spezifizierte XAIP-Dokument aus dem Langzeitspeicher ab. Dies erfolgt gemäß der Prozessbeschreibung in Kap. 7.4.2

98

99

Falls es sich bei diesem abgefragten Archivdatenobjekt um ein versioniertes Archivdatenobjekt handelt (vgl. Kapitel 7.4.5) und der XML-Adapter nur die eigentlichen Nutzdaten zurück liefern soll, muss der XML-Adapter nun den inneren XML-Container extrahieren und prüfen, ob dies nun das ursprünglich archivierte Archivdatenobjekt ist. Dieser Prozess muss vom XML-Adapter solange ausgeführt werden, bis er tatsächlich die ursprünglichen Primärinformationen erhalten hat. Siehe dazu bspw. [BLESS 05], Seite 22

Bundesamt für Sicherheit in der Informationstechnik

65

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Schritt 4:

Der Langzeitspeicher gibt das XAIP-Dokument über das ArchiSafe-Modul an den XMLAdapter zurück Der XML-Adapter speichert das XAIP temporär zur weiteren Verwendung.

Schritt 5:

Der XML-Adapter richtet nun eine Anfrage zum Abruf der Beweisdaten über die Schnittstelle TR-VELS-S.4 (siehe Abbildung 4) an das ArchiSafe-Modul.

Schritt 6:

Das ArchiSafe-Modul überprüft die Zugriffsberechtigung der Geschäftsanwendung auf der Grundlage des im Aufrufs übergebenen Authentisierungsmerkmals.100

Schritt 7:

Das ArchiSafe-Modul fragt die Beweisdaten des per AOID identifizierten Archivdatenobjektes über die Schnittstelle TR-VELS-S.6 vom ArchiSig-Modul an.

Schritt 8:

Das ArchiSig-Modul ermittelt aus seinem Datenspeicher101 den reduzierten Archivzeitstempel zu dem per AOID identifizierten Archivdatenobjekt. Der reduzierte Archivzeitstempel wird im ERS Standardformat [RFC4998] erstellt. Verwaltet das ArchiSig-Modul mehrere redundante Hashbäume, wird aus jedem Hashbaum der entsprechende reduzierte Archivzeitstempel berechnet und im Rückgabewert eingebettet. Das genaue Format der ERS ist ansatzweise in Kapitel 6.3.2 und ausführlich in [RFC4998] beschrieben.

Schritt 9:

Das ArchiSig-Modul gibt den berechneten Evidence Record über die Schnittstelle TRVELS-S.6 (siehe Abbildung 4) an das ArchiSafe-Modul zurück.

Schritt 10: Das ArchiSafe-Modul übergibt die empfangenen Beweisdaten über die Schnittstelle TRVELS-S.4 (siehe Abbildung 4) an den XML-Adapter. Schritt 11: Der XML-Adapter prüft, ob das vorher abgefragte XAIP ein versioniertes Archivdatenobjekt ist (vgl. Kapitel 7.4.5). Sollte dies der Fall sein, ermittelt der XML-Adapter die AOID des inneren (versionierten) Archivdatenobjektes und fragt, wie oben beschrieben, auch zu diesem die Beweisdaten ab. Dies wird solange wiederholt, bis der XML-Adapter auch die Beweisdaten für das ursprüngliche Archivdatenobjekt ermittelt hat. Schritt 12: Der XML-Adapter gibt den in den Schritten 2-4 abgefragten XAIP Container und alle ermittelten Beweisdaten an die Geschäftsanwendung zurück. Falls die Beweisdaten von mehreren Versionen des Archivdatenobjektes abgefragt wurden, werden diese jeweils getrennt im ERS Format zurück geliefert. Der XML-Adapter und das ArchiSafe-Modul bieten auch eine Abfrage der Beweisdaten ohne eine Berücksichtigung der Versionierung an (per Parameter beim Funktionsaufruf). Wird dieser Parameter gesetzt, entfallen aus der vorherigen Beschreibung die Schritte 2, 3, 4 und 11 und es werden im Schritt 12 ausschließlich die Beweisdaten, nicht aber das XAIP, zurückgeliefert.

100

101

66

Da bereits im Schritt 2 eine Prüfung der Zugriffsberechtigung erfolgte, kann – je nach technischer Implementierung – an dieser Stelle eine nochmalige Prüfung auch entfallen. Gemäß der empfohlenen IT-Referenzarchitektur in Kapitel 7.1 verwaltet ArchiSig seine Daten in einem mindestens logisch von den eigentlichen Archivdaten separierten Speicher. Die Schnittstelle TR-VELS-S.2 deckt den Zugriff auf diesen separierten Speicher nicht ab, weshalb hier nicht Bezug auf diese Schnittstelle und auch nicht auf das Modul TRVELS-M.4 „Langzeitspeicher“ genommen wird.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Abbildung 7: Schematischer Ablauf des Abrufs technischer Beweisdaten

7.4.4

Löschen von Archivdaten

Selbstverständlich müssen auch in einem Archiv Daten grundsätzlich gelöscht werden können. Dabei ist jedoch zu unterscheiden, ob die Daten vor oder nach ihrer durch gesetzliche Bestimmungen oder anderweitigen Regelungen festgelegten Mindestaufbewahrungsfrist gelöscht werden sollen. Ein vorzeitiges Löschen kann z. B. dann notwendig werden, wenn personenbezogene Daten gespeichert sind und die betreffende Person der Speicherung nicht mehr zustimmt bzw. widerspricht. In jedem Falle muss das Löschen archivierter Daten aus den vorgelagerten IT-Anwendungen heraus nur ausdrücklich autorisierten Personen erlaubt sein. Die entsprechenden Sicherheitsmerkmale müssen durch die vorgelagerten IT-Anwendungen durchgesetzt werden. Der nachfolgend beschriebene Ablauf (siehe auch Abbildung 8) geht von der in Kapitel 7.1 vorgestellten IT-Referenzarchitektur aus und beschreibt ausschließlich den positiven Fall. Die notwendigen Fehlerprüfungen und Verzweigungen sind aus Gründen der Übersichtlichkeit im Ablauf nicht berücksichtigt. Zudem wird vorausgesetzt, dass jedem Funktionsaufruf und Transport von Daten über eine der in Abbildung 4 der IT-Referenzarchitektur benannten Schnittstellen eine erfolgreiche technische Authentisierung auf der Vermittlungs-, Transport- oder Anwendungsschicht des TCP/IP-Schichtenmodells102 zwischen den beteiligten Modulen vorausgegangen ist.103 102 103

Siehe dazu bspw. [BLESS 05], Seite 22 Zudem gelten die Anforderungen aus A5.1-25.

Bundesamt für Sicherheit in der Informationstechnik

67

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Abbildung 8: Schematischer Ablauf der Löschung von Archivdatenobjekten

Schritt 1:

Die Geschäftsanwendung stellt eine Anfrage zum Löschen archivierter Daten an den XML-Adapter. Das Format der Anfrage richtet sich nach der Geschäftsanwendung. Es muss allerdings die AOID des zu löschenden Archivdatenobjektes enthalten sein. Handelt es sich um ein Löschen vor Ablauf der Mindestaufbewahrungsfrist, muss der Aufruf zusätzlich eine protokollierbare Begründung für das vorzeitige Löschen beinhalten.

Schritt 2:

Der XML-Adapter richtet eine Anfrage zum Löschen archivierter Daten an das ArchiSafe-Modul (über Schnittstelle TR-VELS-S.4). Die Anfrage muss die AOID des zu löschenden Archivdatenobjektes und ein eindeutiges Authentisierungsmerkmal der Fachanwendung enthalten. Handelt es sich um ein Löschen vor Ablauf der Mindestaufbewahrungsfrist, muss der Aufruf zusätzlich die protokollierbare Begründung für das vorzeitige Löschen beinhalten.

Schritt 3:

Das ArchiSafe-Modul überprüft die Zugriffsberechtigung der Geschäftsanwendung auf der Grundlage des im Aufrufs übergebenen Authentisierungsmerkmals.

Schritt 4:

Das ArchiSafe-Modul prüft, ob die Mindestaufbewahrungsfrist bereits erreicht wurde. Hierzu fragt das ArchiSafe-Modul die entsprechenden Metadaten aus dem XAIP aus dem Langzeitspeicher über die Schnittstelle TR-VELS-S.5 ab. Falls die Mindestaufbewahrungsfrist noch nicht abgelaufen ist, prüft das ArchiSafe-Modul, ob die Löschanfrage eine Begründung für die vorzeitige Löschung enthält.

Schritt 5:

Im Fall einer vorzeitigen Löschung protokolliert das ArchiSafe-Modul den übergebenen Begründungstext gemeinsam mit der AOID.104

104

68

Dieser Schritt sollte immer vor dem eigentlichen Löschen erfolgen, so dass sichergestellt ist, dass der Begründungstext immer vorhanden ist, auch wenn das Archivsystem beim eigentlichen Löschen ausfällt.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Schritt 6:

Das ArchiSafe-Modul fordert den Langzeitspeicher über die Schnittstelle TR-VELS-S.5 (siehe Abbildung 4) auf, das per AOID identifizierte Archivdatenobjekt zu löschen.

Schritt 7:

Der Langzeitspeicher löscht das Archivdatenobjekt.

Schritt 8:

Der Langzeitspeicher quittiert über die Schnittstelle TR-VELS-S.5 (siehe Abbildung 4) den Erfolg der Lösch-Aktion an das ArchiSafe-Modul.

Schritt 9:

Das ArchiSafe-Modul quittiert das erfolgte Löschen über den XML-Adapter an die Fachanwendung, die die Löschaktion ausgelöst hat.

7.4.5

Änderung von Metadaten (z. B. Aufbewahrungsfristen)

Aus fachlicher Sicht kann es notwendig werden, Metadaten von bereits archivierten Dokumenten nachträglich zu ändern. Ein anschauliches Beispiel hierfür ist die Aufbewahrungsfrist, die bspw. auf Grund einer Änderung der gesetzlichen Regelungen verändert werden muss. Da das Ziel der vertrauenswürdigen elektronischen Langzeitspeicherung gerade die nachweisliche Unveränderbarkeit der archivierten Unterlagen ist, bedarf es hier eines besonderen Ansatzes, der nachfolgend erläutert wird. Um die Unveränderbarkeit der Archivdatenobjekte nicht grundsätzlich zu kompromittieren, wird empfohlen, eine „Versionierung“ von Archivdatenobjekten zu implementieren, die nur die notwendigen Änderungen an den Metadaten zulässt und gleichzeitig alle Änderungen nachvollziehbar macht. Ein solcher Prozess lässt sich aus den bereits erläuterten Archivfunktionen 1. Abfrage archivierter Daten 2. Löschen von Archivdaten 3. Archivierung elektronischer Unterlagen zusammensetzen. Die nachfolgende Beschreibung beschränkt sich auf diesen Versionierungsvorgang mitsamt der Änderung der XAIP Datenstruktur und referenziert die oben aufgeführten Archivfunktionen nur. Schritt 1:

Die Geschäftsanwendung stößt die Veränderung von Metadaten eines Archivdatenobjekts (identifiziert mittels AOID) an. Je nach Ausprägung kann die Geschäftsanwendung die Logik der Versionierung implementieren oder der XML-Adapter. Im weiteren wird davon ausgegangen, dass der XML-Adapter diese Logik implementiert.

Schritt 2:

Der XML-Adapter fragt das per AOID identifizierte Archivdatenobjekt aus dem Archiv ab und erhält den gesamten XAIP Container vom ArchiSafe-Modul übergeben (vgl. Kapitel 7.4.2).

Schritt 3:

Der XML-Adapter erzeugt eine neue XAIP Datenstruktur und fügt das „alte“ Archivdatenobjekt komplett und unverändert in das Datenelement xaip:dataObjectsSection für die Nutzdaten ein. Der XML-Adapter kopiert die nicht zu verändernden Metadaten des „alten“ Archivdatenobjektes unverändert in die Datenelemente für die Metadaten des neuen Archivdatenobjektes (xaip:packageAttributes, xaip:packageHeader, xaip:metaDataSection). Die bislang verwendete AOID darf bei diesem Schritt nicht mit kopiert werden, da die neue Version des XAIP eine neue AOID erhalten wird.

Schritt 4:

Der XML-Adapter fügt die veränderten Metadaten in das Datenelement für die Metadaten des neuen Archivdatenobjektes ein. Dieser Schritt darf die bisher verwendete AOID

Bundesamt für Sicherheit in der Informationstechnik

69

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

ebenfalls nicht umfassen! Es muss nun in den Metadaten des neuen Archivdatenobjektes das Datenformat „XAIP“ eingetragen werden (vgl. Kapitel 6.3.1). Schritt 5:

Der XML-Adapter übergibt das neue Archivdatenobjekt dem ArchiSafe-Modul zur Ablage im Archiv und erhält die neue AOID als Bestätigung zurück. (vgl. Kapitel 7.4.1)

Schritt 6:

Der XML-Adapter fordert das Löschen des „alten“ Archivdatenobjektes aus dem Archiv mit der Begründung „Vorzeitig gelöscht wg. Erstellung neuer Version ()“ (oder eines vergleichbaren Begründungstextes) (vgl. Kapitel 7.4.4).105

Es sei hier angemerkt, dass dieses Verfahren die Signaturen der ursprünglich archivierten Nutzdaten weder negativ beeinflusst noch deren Beweiskraft schmälert. Ebenfalls bleibt der Beweiswert der bisher generierten Sicherungsdaten (der ArchiSig Hashbaum) erhalten. Eine Neusignatur des versionierten Objektes oder eine erneute Prüfung der Signatur und der Zertifikate ist nicht notwendig.

105

70

Auch hier ist die Reihenfolge von Schritt 5 und 6 zu beachten. Nur so ist sicher gestellt, dass die Daten auch bei einem Ausfall einer Komponenten während dieses Prozesses nicht gänzlich verloren sind.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

8. IT-Sicherheitskonzept In diesem Abschnitt wird auf der Grundlage der in Kapitel 4 beschriebenen allgemeinen Anforderungen sowie der in Kapitel 7 empfohlenen Referenzarchitektur ein generisches Sicherheitskonzept für ein vertrauenswürdiges, rechts- und revisionssicheres elektronisches Langzeitarchiv im Sinne dieser Technischen Richtlinie entwickelt.

8.1

Sicherheitsziele

Voraussetzung für eine langfristige, vertrauenswürdige und rechtssichere elektronische Ablage aufbewahrungspflichtiger elektronischer Unterlagen sind hinreichend sichere Archivierungsverfahren. Die hierfür erforderlichen organisatorischen und technischen Maßnahmen und Vorkehrungen sind Bestandteil eines organisationsspezifischen Sicherheitskonzepts, das zur Gewährleistung des erforderlichen Grades an Informationssicherheit entwickelt und umgesetzt werden muss. Bestandteil eines solchen Sicherheitskonzeptes sind insbesondere Maßnahmen und Vorkehrungen zur Gewährleistung der folgenden Sicherheitsziele: • Vertraulichkeit Das Kriterium Vertraulichkeit verlangt, dass Daten nicht unberechtigt eingesehen, weitergegeben oder veröffentlicht werden können. Dieser Anforderung ist auch beim Einsatz von Archivierungssystemen Rechnung zu tragen, indem das eigentliche Archivsystem, die Speichermedien, etwaige Sicherheitskopien und die Kommunikationsverbindungen mittels physischer und/oder logischer Zugangs- und Zugriffskontrollen vor unberechtigter Kenntnisnahme geschützt werden. • Integrität Die Integrität eines elektronischen Archivierungssystems ist gegeben, wenn die zu archivierenden Dokumente und Daten nachweislich vollständig und unverfälscht aufbewahrt werden. Um die Integrität sicherzustellen, sind das Archivsystem insgesamt und die gespeicherten Dokumente und Daten vor Manipulation und ungewollten oder fehlerhaften Änderungen zu schützen. Manipulationen und ungewollte oder fehlerhafte Änderungen müssen immer entdeckt werden können. • Verfügbarkeit Das Sicherheitsziel der Verfügbarkeit gibt an, dass die zur Aufbewahrung bestimmten Daten und Dokumente bei Bedarf (jederzeit) in einer angemessenen Zeitspanne vollständig und unverfälscht aus dem Archiv ausgelesen werden können müssen. Das betrifft auch die zum Nachweis der Authentizität und Integrität erzeugten und gespeicherten Verifikationsdaten. Aus diesen grundsätzlichen Sicherheitszielen der IT-Sicherheit können für ein vertrauenswürdiges rechtssicheres elektronisches Langzeitarchiv noch weitere Sicherheitsziele abgeleitet werden: • Authentizität Für den Erhalt der Rechtsverbindlichkeit archivierter Dokumente oder Daten ist neben der Unverfälschtheit die nachprüfbare Authentizität der Dokumente und Daten von entscheidender Bedeutung. Es muss zweifelsfrei nachweisbar sein und bleiben, dass eine bestimmte (natürliche) Person ein bestimmtes Datum zu einer bestimmten Zeit mit dem vorliegenden Inhalt und in der vorliegenden Form erzeugt oder zur Kenntnis genommen hat. Dieser Nachweis muss im Fall des Langzeitarchivs auch nach mehreren Jahrzehnten noch möglich sein. Zur Authentizität archivierter Dokumente und Daten gehört auch, dass die im elektronischen Archiv aufbewahrten Informationen vollständig sind (vgl. Integrität) und zweifelsfrei einem bestimmten Geschäftsvorfall zugeordnet werden können. Dieses Sicherheitsziel stützt sich auf das Sicherheitsziel der Integrität ab, stellt jedoch noch deutlich höhere Anforderungen an ein Archivsystem.

Bundesamt für Sicherheit in der Informationstechnik

71

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

•

8.2

BSI TR 03125

Verbindlichkeit Unter Verbindlichkeit wird die Eigenschaft von elektronischen Archivierungsverfahren verstanden, gewollte Rechtsfolgen dauerhaft, mindestens aber für die Dauer der gesetzlich vorgeschriebenen Aufbewahrungsfristen, zu gewährleisten. Elektronische Daten sind grundsätzlich geeignet, im elektronischen Geschäftsverkehr Beweiskraft für gewollte Rechtsfolgen zu erbringen. Die beweisrechtliche Wert elektronischer Daten hängt dabei maßgeblich davon ab, wie es gelingt, nachzuweisen, dass die Dokumente seit ihrer Erstellung oder Aufbewahrung nicht mehr verändert worden sind (Integrität) und in Form und Inhalt vom bezeichneten Aussteller herrühren (Authentizität). Im Sinne der Revisionssicherheit bedeutet Verbindlichkeit zudem, dass jegliche Operation auf den Archivdatenobjekten während der Aufbewahrung nachvollziehbar dokumentiert ist. Dies bezieht sich insbesondere auf die Überarbeitung von Metainformation und das vorzeitige Löschen von Archivdatenobjekten.

Maßnahmen

Um die oben angegebenen Sicherheitsziele für das Archivsystem in der Ausprägung der empfohlenen Referenzarchitektur zu erfüllen, sind die folgenden Maßnahmen erforderlich. HINWEIS: Es ist zu beachten, dass dieser generische Maßnahmenkatalog auf keinen Fall ein konkretes Sicherheitskonzept gemäß bspw. den IT-Grundschutz-Katalogen des BSI ersetzen kann, das den lokalen und organisationsspezifischen Bedürfnissen und Gegebenheiten angepasst ist.

8.2.1

Übergreifende Maßnahmen

(A8.2-1) Vor der Einrichtung eines elektronischen Archivsystems muss ein dieses System und sämtliche relevanten Prozesse abdeckendes IT-Sicherheitskonzept basierend auf einer standardisierten Methodik (z. B. BSI-100 Standard) erstellt und mit der Inbetriebnahme umgesetzt werden. (A8.2-2) Das IT-Sicherheitskonzept für das Archivierungssystem muss regelmäßig (z. B. einmal pro Jahr) auf den aktuellen Stand gebracht werden. (A8.2-3) Die Maßnahmen, die sich aus dem IT-Sicherheitskonzept und dessen Überarbeitung ergeben, müssen - soweit wirtschaftlich vertretbar - zeitnah umgesetzt werden. Dies gilt insbesondere für die Definition und Umsetzung der Verantwortlichkeiten und Kompetenzen, der sicheren Archivierungsprozesse auf organisatorischer Ebene sowie sicherer Administrations- und Kontrollprozesse für das Archivsystem. (A8.2-4) Insbesondere für Einrichtungen, Organisationen und Unternehmen der öffentlichen Verwaltung soll die Einrichtung und der Betrieb eines vertrauenswürdigen Archivsystems i. S. dieser Technischen Richtlinie einem IT-Grundschutz-Audit mit dem Ziel der Zertifizierung unterzogen werden, um auch die jeweiligen Prozesse und Organisationen in der Einsatzumgebung des Archivsystems nachweislich zielgerichtet definiert zu haben.

8.2.2

Maßnahmen zum Schutz der Vertraulichkeit

(A8.2-5) Das Langzeitspeichersystem und dessen Medien muss in Räumen betrieben werden, die zutrittsgesichert sind. Zutritt zu diesen Räumen ist nur sehr restriktiv zu gewähren. Dies gilt auch für eventuell vorhandene redundante Systeme und Backup-Systeme und dessen Medien.

72

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

(A8.2-6) Die Handhabung und Verwaltung (Transport, Lagerung, Entsorgung) von Wechseldatenträgern (hier insbesondere Backup-Medien) muss exakt definiert und sehr restriktiv gehandhabt werden. Über die Backup-Medien darf der Zugriff nicht vereinfacht und der Kreis der Zugriffsfähigen (nicht deckungsgleich mit den Berechtigten) und soweit als wie unbedingt notwendig ausgeweitet werden. (A8.2-7) Der Zutritt von Personen zu diesen Räumen soll protokolliert und stichprobenartig überprüft werden. Optional kann eine unabhängige Überwachung der Räume, z. B. per Videoanlage, erfolgen. (A8.2-8) Jegliche Aktionen im Zusammenhang mit Backupmedien (Auslagerung, Einlagerung, Umschichtung, Prüfung der Lesbarkeit, Entsorgung, etc.) soll protokolliert werden. Die Protokolle sollen mindestens aufzeigen, welche Person wann aus welchem Grund welche Aktion mit welchen Medien durchgeführt hat. (A8.2-9) Das Archivsystem kann optional sämtliche Archivdaten im Langzeitspeicher verschlüsseln. In einem solchen Fall ist jedoch besonderes Augenmerk auf das sichere Schlüsselmanagement und die Wiederherstellbarkeit sämtlicher Daten im Fehlerfall zu legen. Aus Gründen der Wirtschaftlichkeit wird daher empfohlen, bei Bedarf die erforderlichen Ver- und Entschlüsselungsprozesse und die damit verbundene Administrationsinfrastruktur auf externe, vorgelagerte IT-Anwendungen zu verlagern. Eine Verschlüsselung ersetzt jedoch nicht die generell notwendigen Zugriffskontrollmechanismen. (A8.2-10) Das Archivsystem kann für die Wiederherstellung verloren gegangener oder beschädigter DatenBackupsysteme nutzen, die die Daten während der Aufbewahrung auf den Backupmedien verschlüsseln. Auch hier ist in diesem Fall besonderes Augenmerk auf die Wiederherstellbarkeit der Daten im Fehlerfall zu legen. (A8.2-11) Sofern Kommunikationsverbindungen zwischen einzelnen Komponenten des Archivsystems nicht durch anderweitige Maßnahmen geschützt sind (vgl. Kapitel 7.3.7), müssen die physischen Kommunikationsverbindungen in gesicherten Räumen und/oder in gesicherten Leitungsführungen untergebracht sein. Ein unerlaubter Zugriff auf die Leitungen muss sehr zeitnah erkannt werden können. (A8.2-12) Jegliche Kommunikation zwischen den Archivkomponenten und mit Archiv-externen Komponenten106 darf erst nach einer erfolgreichen Authentisierung dieser Komponenten aufgenommen werden. Hierbei müssen unterschiedliche Authentisierungsstufen berücksichtigt werden:

106 107

•

Die Authentisierungsverfahren müssen so ausgelegt sein, dass keine Komponente des Archivsystems unbemerkt ausgetauscht oder umgangen werden kann.

•

Die Authentisierungsverfahren müssen hinreichend stark sein. Dabei ist insbesondere zu beachten, ob die Kommunikationsbeziehungen und Komponenten physisch geschützt sind oder nicht.

•

Die Authentisierung von vom Archivsystem genutzten externen Dienstleistern (z. B. den Zertifizierungsdiensteanbietern) kann nur in dem Maße genutzt werden, wie die Dienstleister dies anbieten. Die angebotenen Möglichkeiten müssen genutzt werden.

•

Die Authentisierung von externen Dienstleistern, die auf das Archivsystem und dessen Komponenten zugreifen möchten (z.B. zur Fernwartung), muss eine hinreichende Stärke aufweisen, damit kein unerlaubter Zugang und Zugriff von diesen Systemen zum Archiv und dessen Daten möglich ist.

•

Die Authentisierung Archiv-externer Systeme (hier insbesondere die Geschäftsanwendungen) muss ebenfalls eine hinreichende Stärke aufweisen, damit kein unerlaubter Zugang und Zugriff von diesen Systemen zum Archiv und dessen Daten möglich ist.107

z. B. die Fachanwendung oder ein Zertifizierungsdiensteanbieter Der XML-Adapter wird in diesem Zusammenhang, obwohl durch diese Technische Richtlinie definiert, als eine Archivexterne Komponente betrachtet. Es bedarf also einer Authentisierung zwischen XML-Adapter und Archiv. Weiterhin muss sichergestellt sein, dass der XML-Adapter nicht von unautorisierten Geschäftsanwendungen genutzt werden kann.

Bundesamt für Sicherheit in der Informationstechnik

73

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

•

BSI TR 03125

Die an das Archivsystem angebundenen Geschäftsanwendungen müssen eine personenbezogene Authentisierung und Autorisierung durchsetzen. Ausschließlich den fachlich autorisierten Personen soll so der Zugriff auf das Archiv möglich sein.

(A8.2-13) Fehlgeschlagene Authentifizierungsversuche sind zu protokollieren. Es ist aus fachlicher Sicht abzuwägen, ob Zugänge nach mehrfachen fehlerhaften Authentifizierungsversuchen gesperrt werden, da dies auch relativ leicht für Denial-of-Service Attacken genutzt werden kann. (A8.2-14) Erfolgreiche Authentifizierungen können protokolliert werden. (A8.2-15) Jegliche Kommunikation zwischen den Archivkomponenten und mit externen Anwendungen oder Dienstleistern (bspw. Zertifizierungsdiensteanbietern) soll verschlüsselt werden. Sollte eine physische Absicherung einer Kommunikationsbeziehung nicht möglich sein, muss die Kommunikation verschlüsselt werden. Sollte ein externer Dienstleister keine Verschlüsselungsoption für die Kommunikation anbieten, muss geprüft werden, ob ein anderer Dienstleister, der eine Verschlüsselungsoption anbietet, diese Dienstleistungen gleichwertig erbringen kann. (A8.2-16) Für die Kommunikationsverschlüsselung sind hinreichend starke Verschlüsselungsverfahren und Schlüssellängen einzusetzen. Eine Aushandlung einer unzureichenden oder nicht vorhandenen Verschlüsselungsstärke bei Sitzungsaufbau muss verhindert werden. Es darf keine Kommunikation mit zu schwacher Verschlüsselung stattfinden. Das Ereignis ist zu protokollieren. (A8.2-17) Jede Kommunikation wird nur bei Bedarf und nur von der dafür eingerichteten Komponente oder den dazu autorisierten Personen initiiert. Unbegründete bzw. unerwartete Kommunikationsverbindungsanfragen sind von allen Komponenten abzulehnen. (A8.2-18) Der Zugriff auf Protokolldaten des Archivs ist ebenso möglichst restriktiv zu halten.

8.2.3

Maßnahmen zum Schutz der Authentizität, Integrität und Verbindlichkeit (Zurechenbarkeit)

(A8.2-19) Sofern die Sicherung der Authentizität und Integrität elektronischer Daten mit Hilfe elektronischer Signaturen durch gesetzliche Regelungen oder andere Vorschriften normiert ist, müssen elektronische Signaturen von Daten und Dokumenten in der durch die Normen und Regelungen geforderten Qualität grundsätzlich durch die Anwendungen und vor der Ablage im Archivsystem realisiert werden. (A8.2-20) Um sicherzustellen, dass es bei der Signatur von Inhaltsdaten in XML-Notation zu keinen Mehrdeutigkeiten kommt, ist vor der Signatur eine Kanonisierung der Inhaltsdaten erforderlich (ausführlicher dazu in Anlage TR-VELS-M.2 Krypto-Modul und TR-VELS-M.5 XML-Adapter). (A8.2-21) Die Signaturen sind so mit den signierten Daten zu verbinden, dass der Zusammenhang zwischen den Signaturen und den signierten Daten jederzeit und zweifelsfrei auch durch Dritte reproduziert werden kann. (A8.2-22) Für ein zu dieser Technischen Richtlinie konformes elektronisches Archivsystem wird deshalb gefordert, dass die Signaturdaten gemeinsam mit den Inhaltsdaten in einem XML-basierten Archivdatenobjekt (siehe auch Kapitel 4.2.1 und Anlage TR-VELS-F) eingebettet werden. (A8.2-23) Darüber hinaus sollen die für eine vollständige Prüfung der Gültigkeit der Signaturen erforderlichen Prüfdaten (siehe auch Kapitel 4.2.2) bei oder unmittelbar nach der Erstellung der Signatur beschafft und ebenfalls vor der Ablage im Archiv so mit den Signaturen und signierten Daten verbunden werden, dass der Zusammenhang jederzeit und auch durch Dritte reproduziert werden kann. Anderenfalls müssen diese Verifikationsdaten bei der Ablage im Archivsystem durch das ArchiSafeModul beschafft und in die Archivdatenobjekte (XAIP) eingebettet werden.

74

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

(A8.2-24) Für ein zu dieser Technischen Richtlinie konformes elektronisches Archivsystem wird deshalb gefordert, dass die Signaturverifikationsdaten gemeinsam mit den Inhaltsdaten und den Signaturdaten in einem XML-basierten Archivdatenobjekt (siehe auch Kapitel 4.2.1 und Anlage TR-VELS-F) eingebettet werden. (A8.2-25) Um die langfristige Nachprüfbarkeit der Signaturen zu gewährleisten, müssen die Signaturen und Signaturprüfdaten (Zertifikate und Statusabfragen) in standardisierten Datenformaten abgelegt werden. Zum Zeitpunkt der Veröffentlichung der technischen Richtlinie sind dies [RFC3852] und [XMLDSIG]108 für die elektronischen Signaturen und [X.509] sowie [RFC2560] und [RFC5055] für die Verifikationsdaten (Zertifikate und Statusabfragen). (A8.2-26) Zur Ablage im Archivsystem bestimmte elektronische Daten und Dokumente, für die eine elektronische Signatur durch gesetzliche oder andere Regelungen nicht vorgeschrieben ist, können vor der Ablage im Archivsystem zur Sicherung der Authentizität und Integrität durch die vorgelagerten Anwendungen zusätzlich mit einer fortgeschrittenen elektronischen Signatur oder einem elektronischen Zeitstempel versehen werden. Auch in diesem Fall müssen die Signaturdaten und Signaturprüfdaten so mit den signierten Daten verbunden werden, dass der Zusammenhang zwischen den Signaturen und den signierten Daten jederzeit und zweifelsfrei auch durch Dritte reproduziert werden kann. (A8.2-27) Bei der Archivierung muss jedes Archivdatenobjekt (XAIP-Dokument) durch das ArchiSafe-Modul gegen eine in dieser Komponente hinterlegte und durch die Fachanwendung autorisierte XML Schemadatei auf syntaktische Richtigkeit geprüft werden. Schlägt die Überprüfung fehl, darf das Objekt nicht archiviert werden. (A8.2-28) Enthält das Archivdatenobjekt elektronische Signaturen, muss das ArchiSafe-Modul die Gültigkeit der Signaturen prüfen und die Prüfergebnisse in standardisierter Form (siehe dazu 8.2.3) in das Archivdatenobjekt (XAIP-Dokument) eintragen. Schlägt die Prüfung fehl, darf das Objekt nicht archiviert werden. (A8.2-29) Ist die Prüfung erfolgreich, kann das ArchiSafe-Modul das gesamte Archivdatenobjekt zusätzlich mit einer fortgeschrittenen elektronischen Signatur oder einem elektronischen Zeitstempel versehen. (A8.2-30) Um neben den eigentlichen Inhaltsdaten auch die zu dem Archivdatenobjekt gehörenden Metainformationen vor Manipulationen zu schützen, muss, nach der erfolgreichen Prüfung der Syntax des Archivdatenobjektes sowie ggf. vorhandener Signaturen durch das ArchiSafe-Modul, durch das ArchiSig-Modul über das gesamte XML-Archivdatenobjekt (XAIP-Dokument) ein Hashwert auf der Basis sicherheitsgeeigneter Algorithmen und Parameter berechnet und gemeinsam mit einer eindeutigen Archivdatenobjekt ID (AOID) 109 in der ArchiSig-Datenbasis abgelegt werden. (A8.2-31) Alle noch nicht integritätsgeschützten Hashwerte in der ArchiSig-Datenbasis müssen regelmäßig durch einen qualifizierten „Archivzeitstempel“, der eine qualifizierte elektronische Signatur enthält, nach dem in der Anlage TR-VELS-M.3 „ArchiSig-Modul“ näher beschriebenen ERS-Standard der IETF gesichert werden.110 Empfehlung: mindestens einmal pro Tag.

108

109

110

Eastlake, D., Reagle, J., Solo, D.: RFC 3275 – (Extensible Markup Language) XML-Signature Syntax and Processing, März 2002, unter: http://www.ietf.org/rfc/rfc3275 Die AOID wird entweder direkt vom ArchiSig-Modul selbst erzeugt oder die AOID wurde vom Langzeitspeicher zurückgeliefert. Ein „Archivzeitstempel“ kann auf ein einzelnes Datenobjekt oder eine Gruppe von Datenobjekten angewendet werden. Im Falle einer Gruppe von Datenobjekten werden die kryptographischen Repräsentanten (Hashwerte) der Datenobjekte zunächst in einem so genannten Merkle-Hashbaum [MER 1980] zusammengefasst und der letzte Hashwert des Baums dann mit einem Zeitstempel versehen. Auf diese Weise sind alle unter einem Hashbaum subsumierten Hashwerte mit nur einem Zeitstempel kryptographisch geschützt (siehe auch TR-VELS-M.3 und unter http://www.ietf.org/rfc/rfc4998.txt).

Bundesamt für Sicherheit in der Informationstechnik

75

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

(A8.2-32) Rechtzeitig vor dem Auslaufen der Sicherheitseignung oder dem Bekanntwerden111 einer (theoretischen) Angreifbarkeit der für den Archivzeitstempel verwendeten Algorithmen und Parameter112 muss über alle in der ArchiSig-Datenbasis vorhandenen Archivzeitstempel ein neuer Hashwert gebildet werden. Aus diesen Hashwerten wird nach dem ERS-Standard der IETF ein neuer Hashbaum gebildet, der wiederum mit einem neuen Archivzeitstempel geschützt wird. Dieser neue Zeitstempel basiert auf sicherheitsgeeigneten Algorithmen und ist ebenfalls der ArchiSig-Datenbasis hinzuzufügen. (A8.2-33) Rechtzeitig vor dem Auslaufen der Sicherheitseignung oder dem Bekanntwerden einer (theoretischen) Angreifbarkeit der für die Berechnung der Hashwerte der Archivdatenobjekte verwendeten Algorithmen und Parameter müssen für alle im Langzeitspeicher abgelegten XAIP-Dokumente neue Hashwerte auf Basis sicherheitsgeeigneter Algorithmen und Parameter berechnet und mit neuen Archivzeitstempeln nach dem ERS-Standard der IETF gesichert werden. Das Archivsystem muss für diese Operation dem ArchiSig-Modul einen performanten, sicheren und zuverlässigen Zugriff auf den elektronischen Langzeitspeicher zur Verfügung stellen. (A8.2-34) Da diese Operation abhängig vom Volumen der gespeicherten Daten möglicherweise einen nicht unerheblichen Zeitraum beanspruchen wird, soll das Archivsystem als Fallback-Lösung zusätzlich eine sekundäre ArchiSig-Datenbasis parallel zur primären Datenbasis pflegen. Diese sekundäre Datenbasis muss auf anderen kryptographischen Algorithmen und Parametern als die primäre Datenbasis aufsetzen. Die sekundäre Datenbasis muss genau die gleichen Datenobjekte wie die primäre Datenbasis absichern und jederzeit parallel zur primären Datenbasis in Betrieb genommen werden können. (A8.2-35) ArchiSig-Datenbestände dürfen nicht gelöscht werden oder durch sonstige Umstände verloren gehen. Dies gilt auch dann, wenn einzelne Archivdatenobjekte schon gelöscht oder wenn die verwendeten Algorithmen ausgelaufen sind oder gebrochen wurden. (A8.2-36) Die ArchiSig-Datenbestände müssen auf bzw. in Speichern113 gehalten werden, die grundlegende integritätssichernde Mechanismen zur Verfügung stellen. Dies bezieht sich nicht nur auf die Zeitstempel und Hashwerte sowie die Archivdatenobjekt ID’s selbst sondern auch auf die Verknüpfungen zwischen diesen Datenelementen. (A8.2-37) Der Langzeitspeicher muss derart gewählt werden, dass eine bitgenaue Reproduktion der gespeicherten Archivdatenobjekte (XAIP) und der ArchiSig-Datenbestände garantiert werden kann. (A8.2-38) Alle im Langzeitspeicher gehaltenen Medien (auch Backup-Medien) sowie die darauf gespeicherten Daten müssen regelmäßig auf ihre Lesbarkeit hin überprüft werden. Selbst bei Identifikation nur geringfügiger Fehler (z. B. Bit-Fehler auf Medium) muss das entsprechende Medium ersetzt bzw. die betroffenen Datenbestände von integren Backup-Medien zurückgesichert werden. (A8.2-39) Alle Komponenten des Archivsystems müssen derart ausgelegt sein, dass der parallele Zugriff einer oder mehrerer unterschiedlicher Geschäftsanwendungen, auch mit unterschiedlicher Rechenkapazitäts- und Bandbreitenausnutzung, nicht zu unerwünschten Verfälschungen an den übertragenen oder gespeicherten Daten führt.

111 112 113

76

Der Zeitpunkt des Bekanntwerdens ist dann, wenn die mögliche Angreifbarkeit in Fachforen diskutiert wird. Dies schließt sowohl das Hash-Verfahren als auch das Signaturverfahren ein. Es wird nicht gefordert, dass das Langzeitspeichersystem diese Mechanismen zur Verfügung stellt. Das ArchiSig-Modul könnte diese auch selbst realisieren.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

8.2.4

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Maßnahmen zum Schutz der Verfügbarkeit

(A8.2-40) Archivdatenobjekte dürfen nur gelöscht werden, wenn die vorgeschriebene Mindestaufbewahrungsdauer abgelaufen ist und ein Löschauftrag im Falle einer vorzeitigen Löschung eine Begründung für ein vorzeitiges Löschen enthält. Die Begründung ist im Falle einer vorzeitigen Löschung nachweislich durch den Langzeitspeicher zu protokollieren und für die Dauer der gesetzlich vorgeschriebenen Aufbewahrungsfristen unverfälscht vorzuhalten. Es ist zu empfehlen, dass für das (vorzeitige) Löschen innerhalb der Geschäftsanwendung ein 4-Augen-Prinzip oder ein anderes Berechtigungs- und Kontrollmodell durchgesetzt wird. (A8.2-41) Das Archiv soll sämtliche Daten redundant speichern. In welchem Grad dies notwendig ist, muss das konkrete IT-Sicherheitskonzept aufzeigen. Dies gilt für die eigentlichen Archivdatenobjekte als auch für die ArchiSig-Datenbasis. (A8.2-42) Die Infrastruktur und die technischen Komponenten des gesamten Archivsystems sowie die Anbindungen an Archiv-externe Komponenten müssen hinreichend verfügbar und ggf. redundant ausgelegt werden. In welchem Grad dies notwendig ist, muss das konkrete IT-Sicherheitskonzept aufzeigen. (A8.2-43) Alle Komponenten des Archivsystems müssen derart ausgelegt sein, dass keine der angeschlossenen Geschäftsanwendungen den Zugriff auf das Archiv blockieren kann. (A8.2-44) Alle Komponenten des Archivsystems müssen derart ausgelegt sein, dass keine archivinternen Aktionen den zeitnahen Zugriff für die Geschäftsanwendungen blockieren können.

8.2.5

Maßnahmen zur Autorisierung (Vertraulichkeit, Integrität)

(A8.2-45) Die am Archivsystem angeschlossenen Geschäftsanwendungen müssen ein zuverlässiges Authentisierungs- und Autorisierungssystem implementieren, das den Zugriff auf das Archiv nur berechtigten Personen ermöglicht. (A8.2-46) Das ArchiSafe-Modul muss bei jeder Archivanfrage überprüfen können, ob die anfragende Geschäftsanwendung für einen Zugriff (Ablage, Abruf oder Löschung) auf das Archiv autorisiert ist. (A8.2-47) Das ArchiSafe-Modul muss überprüfen können, ob die anfragende Geschäftsanwendung für den einen Zugriff (Rückgabe oder Löschung) auf das durch eine AOID identifiziertes Archivdatenobjekt autorisiert ist. (A8.2-48) Das ArchiSafe-Modul muss überprüfen können, ob eine Archivanfrage (z. B. archiviere, suche, lösche, etc.) ein zulässiger Befehl ist.

Bundesamt für Sicherheit in der Informationstechnik

77

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

9. Konformität und Interoperabilität Die Technische Richtlinie definiert Anforderungen an IT-Systeme und Komponenten, die für eine vertrauenswürdige, rechts- und revisionssichere Langzeitspeicherung elektronischer Daten und Dokumente eingesetzt werden.

9.1

Konformität und Konformitätsprüfung

Es sind zwei aufeinander aufbauende Stufen für die Konformitätsprüfung von einzelnen Modulen oder ganzen Archivsystemen vorgesehen: Funktionale Konformität Ein System oder eine Komponente ist funktional konform zu dieser Technischen Richtlinie, wenn das System oder die Komponente funktional auf die in dieser Richtlinie beschriebene Systemkomposition oder auf einzelne (auch mehrere) Module dieser Systemkomposition abgebildet werden kann und die Übereinstimmung zu den Anforderungen (Ax.y-z) an das Gesamtsystem oder an einzelne Module festgestellt wird. Funktional konform im Sinne dieser TR bedeutet, dass die Komponenten eines elektronischen Archivsystems die in dieser TR definierten funktionalen und sicherheitstechnischen Anforderungen erfüllen, die logische Abbildung der funktionalen Anforderungen nachvollziehbar dargestellt wird und die Komponenten des Archivsystems zweckmäßig auf der Basis der in dieser TR aufgeführten Ziele und Standards miteinander arbeiten können. Funktional konform im Sinne dieser TR bedeutet nicht, dass die Schnittstellen der Komponente bzw. des Systems den ASN.1 Spezifikationen exakt entsprechen müssen. Wesentliches Ziel dieser Konformitätsprüfung ist der Nachweis, dass das Modul bzw. das Gesamtsystem die Rechtssicherheit, die für ein vertrauenswürdiges elektronisches Langzeitarchiv notwendig ist, funktional umsetzt. Technische Konformität Ein Archivsystem oder eine Archivkomponente ist technisch konform, wenn zusätzlich zum Nachweis der funktionalen Konformität auch alle bzw. die betreffenden Schnittstellen auf Basis der eCard-API, wie in [TR-VELS-E] beschrieben, umgesetzt sind. Wesentliches Ziel dieser zusätzlichen Prüfung ist der Nachweis, dass eine technische Interoperabilität auf Basis eines wohldefinierten Standards erreicht werden kann. Dies ist insbesondere dann relevant, wenn nur einzelne Module geprüft werden, die als eigenständige Produkte vertrieben werden und damit mit anderen Modulen/Systemen zusammen arbeiten müssen. Eine Komponente oder ein System ist konform gemäß der TR, wenn die Komponente bzw. das System die Konformitätsprüfung ohne Abweichung von der für die Konformitätsstufe geltenden Spezifikationen durchlaufen hat. Eine bestandene Konformitätsprüfung ist der Nachweis, dass die Komponente oder das System die technischen Anforderungen der TR erfüllt. Ein zu prüfendes System kann komplett konform sein oder nur die Anforderungen einzelner Module implementieren.

78

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

9.2

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Beteiligte Instanzen bei der Konformitätsprüfung

Die folgenden Instanzen sind an einer Konformitätsprüfung beteiligt: Antragsteller

Hersteller, Vertreiber oder Betreiber einer Komponente/eines Systems im Sinne dieser TR.

Prüfgegenstand

Komponente/System nach dieser TR, die/das zur Konformitätsprüfung bereitgestellt wird.

Prüfstelle

Vom BSI akkreditierte Stelle oder Einrichtung, welche die Konformitätsprüfung durchführt.

Bestätigungsstelle

Konformitätsbestätigungsstelle des BSI.

9.2.1

Antragsteller

Der Antragsteller möchte die Konformität seines Systems oder seiner Komponente(n) gemäß einer der beiden oben angegebenen Stufen der TR prüfen und bestätigen lassen. Dazu stellt er beim BSI einen Antrag auf Bestätigung der Konformität seines Systems oder seiner Komponente(n). Das offizielle Antragsdatum ist für die Reihenfolge der Bearbeitung der verschiedenen Bestätigungsverfahren beim BSI maßgebend. Es wird dem Antragsteller vom BSI mitgeteilt, wenn der Antrag vollständig eingegangen ist und die Verfahrensnummer vergeben wurde. Der Antragsteller schließt mit der Prüfstelle einen Vertrag zur Durchführung der Konformitätsprüfung. Der Antragsteller verpflichtet sich, alle für die Durchführung der Konformitätsprüfung nötigen Informationen, den Prüfgegenstand selbst und ggf. erforderliche Testwerkzeuge und Schulungen zur Verfügung zu stellen. Er ist für die Richtigkeit seiner Angaben zu seinem System oder seiner Komponente verantwortlich.

9.2.2

Prüfgegenstand

Das System oder die Komponente, deren Konformität bestätigt werden soll, wird als Prüfgegenstand bezeichnet. Dabei kann es sich um Software handeln, die auf einer bestimmten Plattform zur Ausführung kommt und in einer bestimmten Einsatzumgebung zu verwenden ist. Ebenso kann es sich um Hardwareprodukte handeln oder eine Kombinationen aus Software und Hardware. Zum Zeitpunkt der Durchführung der Konformitätsprüfung muss der Prüfgegenstand vollständig vorliegen und die Entwicklung für den zur Prüfung eingereichten Versionsstand abgeschlossen sein. Der Versionsstand des Prüfgegenstandes wird bei Antragstellung festgehalten. Nachbesserungen am Prüfgegenstand während der Konformitätsprüfung sind nur in Absprache mit dem BSI möglich.

9.2.3

Prüfstelle

Konformitätsprüfungen mit dem Ziel der Bestätigung durch das BSI werden von den durch das BSI akkreditierten Prüfstellen durchgeführt. Eine Voraussetzung für die Akkreditierung ist die Einhaltung der DIN EN ISO/IEC 17025. Die Prüfstelle ist für die Richtigkeit ihrer Prüfergebnisse verantwortlich und dokumentiert diese Ergebnisse in einem Prüfbericht. Die Durchführung der Konformitätsprüfung erfolgt erst, nachdem ein

Bundesamt für Sicherheit in der Informationstechnik

79

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

Antrag auf Konformität offiziell vom BSI angenommen wurde. Dazu stimmt die Prüfstelle die Planung und Durchführung der Konformitätsprüfung mit der Bestätigungsstelle des BSI aktiv ab. Diese Abstimmung beinhaltet die zeitliche Planung, die Planung der technischen Durchführung und Angaben zu den im Verfahren eingesetzten Prüfern. Der Prüfbericht dokumentiert den Prüfablauf und die Ergebnisse. Er wird der Bestätigungsstelle zur Prüfung und Abnahme zur Verfügung gestellt. Den abschließenden Prüfbericht erhält der Antragsteller nach Abnahme durch die Bestätigungsstelle von der Prüfstelle. Die durch das BSI akkreditierten Prüfstellen und das BSI haben einen Vertrag geschlossen, der ihre gegenseitigen Rechte und Pflichten regelt. Die akkreditierte Prüfstelle ist verpflichtet, Herstellerinformationen und Prüfgegenstände sowie die Ergebnisse der Prüfungen vertraulich zu handhaben und sie vor unbefugter Kenntnisnahme zu schützen. Das need-to-know Prinzip ist anzuwenden. In der Kommunikation mit der Bestätigungsstelle ist die Vertraulichkeit zu wahren. Alle Prüfunterlagen sind als firmenvertraulich zu kennzeichnen. Herstellerinformationen und Prüfberichte müssen in der Prüfstelle einem Konfigurationsmanagment unterliegen. Die Dienstleistung der Prüfstelle muss in ein Qualitätsmanagementsystem der Prüfstelle eingegliedert sein. Akkreditierte Prüfstellen werden vom BSI in regelmäßig aktualisierten Publikationen veröffentlicht und können auf der BSI Webseite eingesehen werden.

9.2.4

Bestätigungsstelle

Aufgabe der Bestätigungsstelle ist es, den Ablauf der Konformitätsprüfung zu überwachen (Prüfbegleitung) und nach erfolgreich durchgeführter Prüfung den Konformitätsreport und den Konformitätsbescheid zu erstellen. Die Bestätigungsstelle prüft den Antrag auf Bestätigung der Konformität. Bei der Abstimmung der Durchführung der Prüfung durch die im Antrag angegebene Prüfstelle werden die Angaben der Prüfstelle zur zeitlichen Planung, zur Planung der technischen Durchführung der Prüfung und ggf. die Angaben zur Kompetenz der genannten Prüfer geprüft. Lizenz- und Kompetenzfragen werden ggf. mit der Akkreditierungsstelle des BSI abgestimmt. Nachdem die Antragsprüfung abgeschlossen ist, wird dem Antragsteller und der Prüfstelle das offizielle Antragsdatum und eine Verfahrensnummer mitgeteilt. Die Verfahrensnummer ist die Vorgangskennung beim BSI. Sie wird bei jedem Schriftwechsel zur Kennzeichnung der Dokumente und der Bestätigungsurkunde verwendet. Die Bestätigungsstelle des BSI oder ein von ihr beauftragter BSI Mitarbeiter nimmt ggf. an Teilen der Durchführung der technischen Konformitätsprüfung teil. Der von der Prüfstelle vorgelegte Prüfbericht wird geprüft, ggf. kommentiert und abgenommen. Zum Abschluss des Prüfverfahrens erstellt die Bestätigungsstelle ein Zertifikat sowie den zugehörigen Konformitätsbescheid. Bestätigte Produkte und Systeme werden vom BSI – sofern der Antragsteller dem zustimmt – durch die Bestätigungsstelle veröffentlicht.

80

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

9.3

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Abwicklung der Konformitätsprüfung

Konformitätsprüfungen werden von einer Prüfstelle durchgeführt. Die Prüfgegenstände durchlaufen bei der Konformitätsprüfung nacheinander die folgende drei Phasen: 1. Vorphase 2. Durchführung der Konformitätsprüfung 3. Konformitätsbestätigung

9.3.1

Vorphase

Die erste Phase besteht aus den Schritten: •

Beantragung durch den Antragsteller

•

Antragsprüfung durch Bestätigungsstelle

•

offizielle Annahme des Antrags durch das BSI

•

Abstimmung der Durchführung der Prüfung zwischen den Parteien

•

Bereitstellung des Prüfgegenstands und der nach der TR notwendigen Unterlagen durch den Hersteller/Betreiber

9.3.2

Durchführung der Konformitätsprüfung

In der zweiten Phase wird die ausgewählte und parametrisierte Prüffolge durch die Prüfstelle abgearbeitet. Je nach Prüfmethode werden verschiedene Prüfverfahren oder Prüfwerkzeuge eingesetzt. Die während der Prüfung anfallenden Prüfresultate werden gesammelt und geeignet archiviert. Außerdem werden die während der Durchführung der Prüfung erzielten und beobachteten Prüfresultate analysiert und dokumentiert und es wird ein Prüfbericht erstellt. • Durchführung der technischen Prüfung durch die Prüfstelle entsprechend den Spezifikationen der TR und entsprechend der mit der Bestätigungsstelle abgestimmten Planung und Durchführung; ggf. beobachtende Begleitung der Prüfung vor Ort durch das BSI, um eine einheitliche Vorgehensweise und Methodik und ggf. vergleichbare Bewertungen sicherzustellen. • Dokumentation der Teilschritte der Durchführung und der Ergebnisse der Prüfung in einem Prüfbericht durch die Prüfstelle. • Prüfung, ggf. Kommentierung und Abnahme des Prüfberichtes durch das BSI. Bei der Prüfung werden alle muss114-Anforderungen auf ihre uneingeschränkte Umsetzung hin überprüft. Eine Abweichung von den muss-Anforderungen ist nicht zulässig. Ebenso werden alle soll-Anforderungen geprüft. Ihre Nichteinhaltung muss durch den Antragsteller, schlüssig und nachvollziehbar, schriftlich begründet werden. kann-Anforderungen sind nicht Gegenstand der Prüfung.

114

Diese Prüfungen beziehen sich natürlich auch auf alle Forderungen mit dem Wortlauf „ist“, „darf nicht“, etc.

Bundesamt für Sicherheit in der Informationstechnik

81

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

9.3.3

BSI TR 03125

Konformitätsbestätigung

Diese Phase umfasst: • Erstellung des Konformitätsreportes, des Zertifikates und Erteilung des Konformitätsbescheides durch das BSI. • Veröffentlichung des Ergebnisses, sofern dem der Antragsteller zugestimmt hat.

9.4

Interoperabilität

Während durch die funktionale Konformitätsprüfung die Übereinstimmung von implementierten Komponenten zu den eher funktionalen Anforderungen der TR festgestellt wird, bedeutet Interoperabilität zwischen konformen Komponenten, dass diese Komponenten auf einer technischen Ebene zusammenwirken können. Die funktionale Konformität ist daher Voraussetzung für die Interoperabilität, aber nicht immer hinreichend. Wenn funktional konforme Komponenten jeweils verschiedene Anforderungen einer Spezifikation erfüllen, welche keine gemeinsame Schnittmenge haben, dann sind die Komponenten jeweils einzeln funktional konform zur Spezifikation, aber nicht miteinander interoperabel. Im Rahmen dieser TR werden für die funktionale Konformitätsprüfung keine eigenen Interoperabilitätsprüfungen durchgeführt, sondern es wird durch geeignete Festlegungen der Konformitätskriterien erreicht, dass die Komponenten logisch und funktionell interoperabel gestaltet sind. Für die technische Interoperabilitätsprüfung muss ein nachvollziehbarer technischer Nachweis erbracht werden, dass die geprüften Komponenten oder Module die mit Hilfe der eCard-API spezifizierten Schnittstellen korrekt implementiert haben.

82

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

10. Anlagen Diese Technische Richtlinie umfasst dieses Hauptdokument und gemäß der empfohlenen Referenzarchitektur aus Kapitel 7 die folgenden Anlagen zu den in der Referenzarchitektur definierten Module (Komponenten) und Schnittstellen.

10.1 TR-VELS-M.1 ArchiSafe-Modul Die Anlage mit der Bezeichnung „TR-VELS-M.1 ArchiSafe Modul“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an eine einheitliche Archiv-Middleware, die als sicheres Archiv-Gateway den Zugriff auf den Langzeitspeicher für folgende Operationen regelt: ● die Ablage von Datenobjekten, ● den Abruf von Archivdatenobjekten, ● die Abfrage von Beweisdaten, ● das Löschen von Archivdatenobjekten. Ziel des ArchiSafe-Moduls ist die Realisierung einer einheitlichen, funktionalen Archivschnittstelle, die eine strikte logische Trennung der vorgelagerten IT-Fachanwendungen von den eigentlichen Langzeitspeichersystemen gewährleistet und so imstande ist, unberechtigte Zugriffe auf das Langzeitspeichersystem zuverlässig zu verhindern. Das ArchiSafe-Modul entkoppelt zudem logisch und funktional den Datenfluss zwischen den ITFachanwendungen und dem elektronischen Langzeitspeicher zur Ablage oder zum Aufruf archivierter Daten und Dokumente. Darüber hinaus bietet dieses Modul einheitliche Schnittstellen zur Kommunikation mit den kryptographischen Komponenten (TR-VELS-M.2 und TR-VELS-M.3), die den Erhalt der Authentizität und Integrität der gespeicherten elektronischen Unterlagen unterstützen. Jeder Archivaufruf von einer vorgelagerten, externen IT-Anwendung, bspw. einem Dokumenten-Management-System, zur Ablage oder zum Abruf archivierter Daten und Dokumente in bzw. aus dem Langzeitspeicher muss über das ArchiSafe-Modul erfolgen. Die externe IT-Anwendung eröffnet zu diesem Zweck einen sicheren Kommunikationskanal mit dem ArchiSafe-Modul und versendet eine Archivanfrage. Das ArchiSafe-Modul identifiziert und authentifiziert die aufrufende Anwendung und überprüft die syntaktische Gültigkeit der von der aufrufenden Anwendung übermittelten Archivanfrage anhand der im ArchiSafe-Modul abgelegten Konfigurationsdaten (XML-Schemata, Kommunikations- und Verarbeitungsregeln). Bei der Ablage elektronisch signierter Daten und Dokumente sichert das ArchiSafe-Modul die beweisrechtliche Qualität der zu archivierenden Informationen, indem 1) elektronische Signaturen auf Gültigkeit geprüft und die Prüfergebnisse in standardisierter Form in die XML-Dokumente eingebettet werden. Die Signaturprüfung wird durch kryptographische Module realisiert, die den in der Anlage TR-VELS-M.2 beschriebenen Anforderungen genügen müssen. Die Schnittstelle zwischen dem ArchiSafe-Modul und den kryptographischen Einheiten ist in Anlage TR-VELS-S.1 spezifiziert. 2) das für die Signaturerneuerung verantwortliche ArchiSig-Modul (siehe Anlage TR-VELS-M.3) die Archivdatenobjekt ID (AOID) nach der dort durchgeführten Hashwertberechnung zurück gibt. Nur mittels dieser AOID wird ein späterer Zugriff auf das Archivdatenobjekt möglich.

Bundesamt für Sicherheit in der Informationstechnik

83

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

10.2 TR-VELS-M.2 Krypto-Modul Die Anlage mit der Bezeichnung „TR-VELS-M.2 Krypto-Modul“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an kryptographische Module zur Erstellung und Prüfung elektronischer Signaturen und zur Einholung von qualifizierten Zeitstempeln. Das Krypto-Modul stellt benötigte kryptographische Funktionen zentral bereit, die für die vertrauenswürdige elektronische Langzeitspeicherung benötigt werden. Im Wesentlichen umfasst dies kryptographische Verfahren, die für die Erzeugung und Verifikation von elektronischen Signaturen benötigt werden.

Abbildung 9: Krypto-Modul

Das Krypto-Modul besitzt folgende kryptographischen Funktionen, es implementiert keine fachlichen Prozesse: • Kryptographische Funktionen: o Erzeugung einer digitalen Signatur (optional) o Verifikation einer digitalen Signatur o Validierung von Zertifikaten o Erzeugung eines Hash-Wertes o Anforderung eines qualifizierten Zeitstempels o Verifikation eines qualifizierten Zeitstempels Das Krypto-Modul bietet einige dieser Funktionen über die Schnittstellen TR-VELS-S.1 und TRVELS-S.3 den Modulen ArchiSafe und ArchiSig an (vgl. TR-VELS-S.1 und TR-VELS-S.3). Die anderen Funktionen werden nur innerhalb des Krypto-Moduls benötigt. Des Weiteren beschreibt diese Anlage grundlegende Anforderungen an eingesetzte Algorithmen sowie an erforderliche Sicherheitsfunktionalitäten und die Konfiguration des Krypto-Moduls.

84

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

10.3 TR-VELS-M.3 ArchiSig-Modul Die Anlage mit der Bezeichnung „TR-VELS-M.3 ArchiSig-Modul“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an ein kryptographisches Modul zum Erhalt und der Erneuerung der Beweiskraft elektronischer Signaturen nach dem ERS-Standard der IETF [RFC4998]. Kryptographische Operationen wie elektronische Signaturen ermöglichen es nur dann, die Integrität und Authentizität elektronischer Daten nachweisbar zu machen, wenn die den Signaturen zugrunde liegenden Algorithmen mathematisch und technisch sicherheitsgeeignet sind. Ein dauerhafter und nachweisbarer Erhalt der Authentizität und Integrität elektronischer Daten erfordert deshalb den Einsatz zusätzlicher Sicherungsmittel, die den Nachweis ermöglichen, dass insbesondere elektronisch signierte Daten über die Dauer der Aufbewahrungsfristen unverfälscht aufbewahrt wurden. Aufgabe des ArchiSig-Moduls ist der Erhalt der Authentizität, Integrität gemäß der rechtlichen Anforderungen und damit der Erhalt des beweisrechtlichen Werts vor allem elektronisch signierter, aufbewahrungspflichtiger und aufbewahrungswürdiger Daten und Dokumente (Archivdatenobjekte) durch zusätzliche kryptographische Sicherungsmittel. Das ArchiSig-Modul implementiert für diesen Zweck eine kryptographische Lösung, die insbesondere sicherstellt, dass das durch § 17 Signaturverordnung (SigV) normierte Verfahren zur Aufrechterhaltung der Sicherheit und Vertrauenswürdigkeit elektronischer Signaturen durch eine erneute Signatur zuverlässig und wirtschaftlich, d. h. auch für große Datenmengen, erfüllt werden kann. Die erneute elektronische Signatur muss die Daten und frühere Signaturen einschließen und mit sicherheitsgeeigneten kryptographischen Algorithmen und Parametern erzeugt werden. Für die erneute elektronische Signatur ist zumindest ein qualifizierter Zeitstempel notwendig, der eine qualifizierte elektronische Signatur trägt. Das Erneuerungsverfahren kann automatisiert und so eingerichtet werden, dass viele Dokumente gemeinsam elektronisch neu signiert werden. Bei elektronischen Signaturen auf Basis von qualifizierten Zertifikaten, herausgegeben von Zertifizierungsdiensteanbietern mit Anbieterakkreditierung, müssen qualifizierte Zeitstempel akkreditierter Zertifizierungsdiensteanbieter verwendet werden. Grundlage des ArchiSig-Moduls für ein zu dieser Richtlinie konformes Archivsystem ist die informationstechnische Umsetzung des Evidence Record Syntax (kurz: ERS) Standards der IETF115. ERS definiert im Detail, wie Signaturerneuerungen für große Dokumentenmengen automatisch durchgeführt werden können. Darüber hinaus legt der Standard die Datenformate fest, in denen die Beweisdaten über einen unbegrenzten Zeitraum bereitgestellt und rechtssicher ausgetauscht werden. Datenschutztechnische Aspekte werden ebenso berücksichtigt, da mit dem ERS-Standard auch Teile aus dem Dokumentenbestand gelöscht werden können, ohne die Beweiskraft der übrigen Teile zu beeinträchtigen. Technisch basiert der ERS-Standard auf dem Ansatz, dass kryptographische Prüfsummen (Hashwerte) der Archivdatenobjekte als kryptographisch eindeutige Repräsentanten der aufzubewahrenden Daten bei der Ablage im Archivsystem zusätzlich mit einem qualifizierten Archivzeitstempel gesichert werden.

115

Siehe unter http://www.ietf.org/rfc/rfc4998.txt

Bundesamt für Sicherheit in der Informationstechnik

85

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

10.4 TR-VELS-M.4 Langzeitspeicher Die Anlage mit der Bezeichnung „TR-VELS-M.4 Langzeitspeicher“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an einen vertrauenswürdigen elektronischen Langzeitspeicher. Die Erstellung dieses Anhangs ist derzeit noch in der Planung.

86

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

10.5 TR-VELS-M.5 XML-Adapter zur Anbindung von GeschäftsAnwendungen an das Archiv Die Anlage mit der Bezeichnung „TR-VELS-M.5 XML-Adapter“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an einen XML-Adapter zur Anbindung von Geschäftsanwendungen an das Archiv und zur Erzeugung der XML-basierten Archivdatenobjekte. Die Erstellung dieses Anhangs ist derzeit noch in der Planung.

Bundesamt für Sicherheit in der Informationstechnik

87

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

10.6 TR-VELS-S.1 Schnittstelle zwischen Krypto-Modul und ArchiSafe Die Anlage mit der Bezeichnung „TR-VELS-S.1“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an die Schnittstelle zwischen der Archiv-Middleware (ArchiSafeModul) und dem Krypto-Modul. Über diese Schnittstelle, zu der eine beispielhafte Ausprägung auf Basis der eCard-API im Anhang TR-VELS-E zu dieser Richtlinie aufgezeigt ist, nutzt die ArchiSafe-Middleware die durch das KryptoModul angebotenen kryptographischen Funktionen. Im Einzelnen sind dies: ● Das Verifizieren von (qualifizierten) elektronischen Signaturen samt der relevanten Zertifikate bis hin zum Wurzelzertifikat und das Ablegen der gewonnenen Prüfinformationen im XAIP Container. ● Optional das Erzeugen einer elektronischen Signatur über einen Teil oder den gesamten XAIP Container. Die in dieser Schnittstellenspezifikation aufgeführten Funktionen stellen jedoch nur die Funktionen dar, die das ArchiSafe-Modul für seine Aufgaben benötigt. Neben den aufgeführten kryptographischen Funktionen spezifiziert das Dokument TR-VELS-S.1 noch die Mindestanforderungen an die Sicherheit der Schnittstelle. Dies beinhaltet insbesondere die obligatorische gegenseitige Authentisierung vor jeglicher Aktion.

88

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

10.7 TR-VELS-S.2 Schnittstelle zwischen ArchiSig und Langzeitspeicher Die Anlage mit der Bezeichnung „TR-VELS-S.2“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an die Schnittstelle zwischen dem ArchiSig-Modul und dem Langzeitspeicher. Das Dokument unterscheidet zunächst zwischen dem Langzeitspeicher, in welchem die eigentlich zu archivierenden Daten abgespeichert werden und einem Speicher, der für die Persistierung der ArchiSig-Hashbäume notwendig ist. Es kann sich hierbei um den physikalisch gleichen Speicher handeln. Zumindest eine logische Trennung in unterschiedliche Speicherbereiche ist jedoch aus Gründen der Sicherheit notwendig. Die Funktionen des ArchiSig-Modul zum Zugriff auf den eigentlichen Archiv-Speicher beschränken sich auf das Speichern von neu zu archivierenden XAIP Objekten und das Auslesen von XAIP-Objekten aus dem Speicher. Letzteres ist nur für den Neuaufbau der Hashbäume notwendig. Ersteres wird über das ArchiSig-Modul geleitet, damit dieses zwangsmäßig in den Archivierungsprozess eingebunden ist und damit unmittelbar bei der Archivierung eines Objektes ein sichernder Hashwert über dieses Objekt erzeugt wird. Die Funktionen zum Zugriff auf den ArchiSig-eigenen Speicher wurden nicht näher ausgeführt. Zum einen ist klar, das ArchiSig auf seinen eigenen Speicher uneingeschränkten Zugriff benötigt und es ist zu erwarten, dass die unterschiedlichen Hersteller auch ebenso unterschiedliche Möglichkeiten der Speicherung der ArchiSig-Hashbäume nutzen werden.

Bundesamt für Sicherheit in der Informationstechnik

89

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

10.8 TR-VELS-S.3 Schnittstelle zwischen Krypto-Modul und ArchiSig Die Anlage mit der Bezeichnung „TR-VELS-S.3“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an die Schnittstelle zwischen dem ArchiSig-Modul und dem Krypto-Modul. Über diese Schnittstelle, zu der eine beispielhafte Ausprägung auf Basis der eCard-API im Anhang TR-VELS-E aufgezeigt ist, nutzt das ArchiSig-Modul die durch das Krypto-Modul angebotenen kryptographischen Funktionen. Im Einzelnen sind dies: ● Das Erzeugen von qualifizierten Zeitstempeln mit qualifizierter elektronischer Signatur. Im Regelfall wird hier das Krypto-Modul die Dienste eine Zertifizierungsdiensteanbieters in Anspruch nehmen. ● Das Verifizieren von (qualifizierten) elektronischen Signaturen samt der relevanten Zertifikate bis hin zum Wurzelzertifikat. Im Fall dieser Schnittstelle werden ausschließlich die Signaturen der Zeitstempel geprüft. ● Das Erzeugen eines Hashwertes über ein übergebenes Datum. Die in dieser Schnittstellenspezifikation aufgeführten Funktionen stellen jedoch nur die Funktionen dar, die das ArchiSig-Modul für seine Aufgaben benötigt. Neben den aufgeführten kryptographischen Funktionen spezifiziert das Dokument TR-VELS-S.3 noch die Mindestanforderungen an die Sicherheit der Schnittstelle. Dies beinhaltet insbesondere die obligatorische gegenseitige Authentisierung vor jeglicher Aktion.

90

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

10.9 TR-VELS-S.4 Schnittstelle zwischen dem XML-Adapter und ArchiSafe Die Anlage mit der Bezeichnung „TR-VELS-S.4“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an die Schnittstelle zwischen dem XML-Adapter zur Anbindung der Geschäftsanwendungen und der Archiv-Middleware (ArchiSafe-Modul).

Bundesamt für Sicherheit in der Informationstechnik

91

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

10.10 TR-VELS-S.5 Schnittstelle zwischen ArchiSafe und dem Langzeitspeicher Die Anlage mit der Bezeichnung „TR-VELS-S.5“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an die Schnittstelle zwischen der Archiv-Middleware (ArchiSafeModul) und dem Langzeitspeicher. Die Erstellung dieses Anhangs ist derzeit noch in der Planung.

92

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

10.11 TR-VELS-S.6 Schnittstelle zwischen ArchiSafe und ArchiSig Die Anlage mit der Bezeichnung „TR-VELS-S.6“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an die Schnittstelle zwischen der Archiv-Middleware (ArchiSafeModul) und dem ArchiSig-Modul. Das wesentliche Motiv zur Existenz dieser Schnittstelle ist, eine Hashwertbildung durch das ArchiSigModul unmittelbar bei der Archivierung eines neuen XAIP-Objektes durchzusetzen. Ein neu zu archivierendes Objekt wird über diese Schnittstelle nach der erfolgreichen Prüfung durch das ArchiSafeModul an das ArchiSig-Modul übergeben. Dieses ist nun dafür verantwortlich, dass das XAIP-Objekt in den Langzeitspeicher gelangt. Vorab kann nun bereits ein Hashwert über das XAIP-Objekt gebildet und in den ArchiSig-Hashbäumen gespeichert werden. In alternativen IT-Architekturen kann es durchaus sein, dass diese Schnittstelle nicht vorhanden ist und das ArchiSig-Modul auf anderem Wege erfahren muss, dass es ein neues XAIP Objekt im System gibt. Allerdings existiert dann eine Zeitspanne zwischen Archivierung und Hashwertbildung über dieses XAIP-Objekt, was die Vertrauenswürdigkeit des Gesamtsystems senkt. Des weiteren ist das ArchiSafe-Modul über diese Schnittstelle in der Lage, vom ArchiSig-Modul die Beweisdaten für ein im Archiv befindliches XAIP Objekt abzurufen. Sollte diese Schnittstelle nicht existent sein, muss ArchiSafe auf anderem Weg an diese Daten gelangen (was das ArchiSafe Protection Profile [ACMPP] jedoch nicht vorsieht) oder die Beweisdaten müssen über eine zusätzliche Schnittstelle direkt vom Benutzer vom ArchiSig-Modul abgefragt werden (was relativ unkomfortabel sein dürfte). Die hier beschriebene Schnittstelle besitzt daher die Funktionen, die ArchiSafe aufruft und die das ArchiSig-Modul zur Verfügung stellt: ● Übergabe eines neuen und geprüften XAIP Objektes zum Zwecke der Speicherung im Langzeitspeicher ● Abfrage der Beweisdaten gemäß [RFC4998] zu einem oder mehreren XAIP Objekten

Bundesamt für Sicherheit in der Informationstechnik

93

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

10.12 TR-VELS-F Formate und Protokolle für die Langzeitspeicherung Die Anlage mit der Bezeichnung „TR-VELS-F Formate und Protokolle“ spezifiziert und erläutert die funktionalen und sicherheitstechnischen Anforderungen an Datenprotokolle und Datenformate für die Ablage der Nutzdaten, Metainformationen und Signaturdaten (Archivdatenobjekte). Weiterhin werden in diesem Dokument die empfohlenen Formate und Protokolle für die Kommunikation mit Archiv-externen Systemen und Partnern, wie bspw. den Zertifizierungsdiensteanbietern, erläutert.

94

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

10.13 TR-VELS-E Konkretisierung der Schnittstellen auf Basis des eCardAPI-Frameworks Die genannte Anlage profiliert die von der eCard-API spezifizierten Funktionen derart, dass damit so weit als möglich die in den Schnittstellenspezifikationen aufgeführten ASN.1 Definitionen umgesetzt werden. Dieser Anhang stellt die Basis für die Stufe „Interoperabilität“ der Konformitätsprüfungen dar. Für die Stufe „Funktionale Konformität“ ist dieser Dokument nicht von Belang.

Bundesamt für Sicherheit in der Informationstechnik

95

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

11. Zuordnung der Anforderungen Die in diesem Abschnitt aufgeführte Tabelle listet die in diesem Dokument aufgeführten Einzelanforderungen zusammenfassend auf und ordnet sie auch den betreffenden Detail-Dokumenten (hier nur kurz mit M.x, S.x und F angegeben) zu, in welchen diese Anforderung ggf. nochmals aufgeführt und bei Bedarf weiter verfeinert werden.

96

Bundesamt für Sicherheit in der Informationstechnik

F.1

S.6

S.5

S.4

S.3

S.2

S.1

M.6

M.5

M.4

X

M.3

X

M.2

M.1

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Hauptdokument

BSI TR 03125

A4.1-1

Trennung der Daten; Mandantenfähigkeit

X

A4.2-1

Verkehrsfähigkeit

A4.2-2

Nutzdatenformate

X

A4.2-3

Metadaten

X

A4.2-4

Datenträgererneuerung

X

X

A4.2-5

Backup

X

X

A4.2-6

Rechtssicherheit

X

X

X

X

A4.2-7

Qualifizierte elektronische Signaturen

X

X

X

X

A4.2-8

Ablage Verifikationsdaten

X

A4.2-9

Zugriff Verifikationsdaten

X

X

A4.2-10

Prüfung Verifikationsdaten (1)

X

X

A4.2-11

Prüfung Verifikationsdaten (2)

X

X

X

A4.2-12

Prüfung Verifikationsdaten (3)

X

X

X

A4.2-13

Formate der Verifikationsdaten

X

A4.2-14

Signaturerneuerung

X

X

A4.2-15

Algorithmen

X

X

A4.2-16

Qualität der Signaturen

X

X

A4.2-17

Qualität der Zeitstempel

X

X

A4.2-18

Signaturanwendungskomponenten

X

A4.2-19

Eingangssignatur (1)

X

X

X

X

A4.2-20

Eingangssignatur (2)

X

X

X

X

A4.2-21

Bereichsspezifische Anforderungen

X

A4.2-22

Wirtschaftlichkeit

X

A4.2-23

Beweiseignung

X

A5.1-1

Zugriffsbeschränkung

X

X

A5.1-2

Ablagefähigkeit

X

X

A5.1-3

Prüfung Syntax

X

X

A5.1-4

Rückgabe AOID

X

X

A5.1-5

Erzeugung AOID

X

X

A5.1-6

Verknüpfung AOID

X

X

A5.1-7

Ablage AOID bei Objekten

X

A5.1-8

Zeitpunkt Archivierung

X

X

A5.1-9

Prüfung Signatur

X

X

A5.1-10

Neusignatur (1)

X

X

X

X

A5.1-11

Neusignatur (2)

X

X

X

X

A5.1-12

Eingangssignatur

X

X

A5.1-13

Sicherer Kanal

X

X

X

A5.1-14

Übergabe AOID

X

X

X

A5.1-15

Optionale Such-Funktion

X

A5.1-16

Erzeugung Beweisdaten

X

X

X

X

X

X

X

A5.1-17

Rückgabe Beweisdaten

X

X

X

X

X

X

X

X

X X

X

X

X X

X

X X X

X X

X

X

X X

X X

X

X

X

X X

X

X

X

X

Bundesamt für Sicherheit in der Informationstechnik

X

X

X

X

97

Vorzeitiges Löschen

X

X

X

X

A5.1-21

Wirtschaftliches Löschen

X

A5.1-22

Bestand Beweiskraft anderer ADO's

X

A5.1-23

Protokollierbarkeit Löschfunktion

X

A5.1-24

Nichtwiederherstellbarkeit

X

A5.2-1

Archiv-Strategie

X

A5.2-2

Archivierungs-Prozesse

X

A5.2-3

Migrationsstrategie

X

A5.2-4

Integration in IT-Landschaft

X

A5.2-5

Mitarbeiterschulung

X

A5.2-6

Dokumentation

X

A5.2-7

Der Archivierungsprozess

X

A5.2-8

Archivierungskonzept

X

A5.2-9

Betriebsvorgaben

X

A6.1-1

Integrierbarkeit

X

X

A6.1-2

Austauschbarkeit der Datenformate

X

X

A6.1-3

Offene Standards

X

X

A6.1-4

Sichere Administration

X

A6.2-1

Dokumentenformate

X

X

A6.3-1

Selbsttragendes Archivdatenformat

X

X

A6.3-2

Metadaten

X

X

A6.3-3

XML-Schema

X

X

A6.3-4

Mandantenfähigkeit

X

A6.4-1

Zugangsschutz

X

A6.4-2

Zugriffsschutz

X

X

A6.4-3

Selbstschutz

X

X

A6.4-4

getrenntes Backup

X

X

A6.4-5

Test Speichermedien

X

X

A6.4-6

Test Fail-over

X

A6.4-7

Notfallhandbuch

X

A6.5-1

Anforderungen an Geschäftsanwendung

X

A6.5-2

Anforderungen Archivschnittstellen

X

X

X

X

A6.5-3

Sicherer Kanal zur Geschäftsanwendung

X

X

X

X

A6.5-4

Berechtigungssystem in Geschäftsanwendung

X

A7.3-1

Geschäftsanwendung muss initiieren

X

X

X

A7.3-2

Geschäftsanwendung kann geteilt sein

X

A7.3-3

Berechtigungssystem in Geschäftsanwendung

X

98

X

F.1

A5.1-20

S.6

X

S.5

X

S.4

X

S.3

X

S.2

Löschen

S.1

A5.1-19

M.6

X

M.5

X

M.4

Voraussetzungen zum Löschen

M.3

A5.1-18

M.2

M.1

BSI TR 03125

Hauptdokument

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

X

X X

X

X

X

X

X

X

X

X

X

X

X

X

X

Bundesamt für Sicherheit in der Informationstechnik

Anwendung muss Viewer haben

X

A7.3-7

Beschaffung Prüfinformationen

X

X

A7.3-8

Ausprägung XML-Adapter

X

X

A7.3-9

Sicherer XML-Adapter

X

A7.3-10

Zugriff nur über ArchiSafe

X

X

A7.3-11

ArchiSafe PP konform zertifiziert

X

X

A7.3-12

Ausprägung Krypto-Modul

X

X

A7.3-13

Qualität Krypto-Modul

X

X

A7.3-14

ggf. Signaturerstellungseinheit

X

X

A7.3-15

Modul-Charakter

X

X

A7.3-16

eCard-API konform

X

X

A7.3-17

Modul-Charakter

X

X

A7.3-18

Mehrere Instanzen

X

X

A7.3-19

Skalierbarkeit

X

X

A7.3-20

Normale Funktion trotz Neusignatur

X

X

A7.3-21

Ein oder zwei Speicher

X

X

A7.3-22

Art des Speichers

X

X

A7.3-23

Typen von Speichern

X

X

A7.3-24

Admin-Schnittstellen 1

X

A7.3-25

Admin-Schnittstellen 2

X

A8.2-1

IT-Sicherheitskonzept

X

A8.2-2

Aktualisierung

X

A8.2-3

Umsetzung Maßnahmen

X

A8.2-4

ITGS-Audit

X

A8.2-5

Zutrittssicherung

X

A8.2-6

Handhabung Backup-Medien

X

A8.2-7

Zutrittsprotokoll

X

A8.2-8

Protokollierung Backup-Medien

X

A8.2-9

Verschlüsselung

X

A8.2-10

Verschlüsselung Backup

X

A8.2-11

Physischer Schutz Leitungen

X

A8.2-12

Authentisierung

X

A8.2-13

Protokoll fehlerhafter Authentisierungen

X

A8.2-14

Protokoll erfolgreicher Authentisierungen

X

A8.2-15

Verschlüsselung Kommunikation (1)

X

A8.2-16

Verschlüsselung Kommunikation (2)

X

A8.2-17

Initiierung Kommunikation

X

A8.2-18

Zugriffsschutz Protokolldateien

X

X

X

F.1

S.4

S.3

S.2

S.1

X

S.6

A7.3-6

X

M.6

M.5

M.4

M.3

M.2

X

A7.3-5

Nur autorisierte Benutzer in Geschäftsanwendung Anwendung muss signieren können

S.5

A7.3-4

M.1

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Hauptdokument

BSI TR 03125

X

X

X

Bundesamt für Sicherheit in der Informationstechnik

X

X

X

X

X

X

X

X

X

X

X

99

X

X

X

Relation Signatur-Daten (2)

X

X

X

A8.2-23

Verifikationsdaten (1)

X

X

X

X

A8.2-24

Verifikationsdaten (2)

X

X

X

X

A8.2-25

Empfohlene Formate

X

X

X

A8.2-26

Fortgeschrittene Signatur

X

X

A8.2-27

XML-Schema konform

X

X

A8.2-28

Signaturprüfung

X

X

A8.2-29

Archiveingangszeitstempel

X

X

A8.2-30

Hashwert über gesamtes XAIP

X

A8.2-31

regelmäßige Bildung Archivzeitstempel

X

X

A8.2-32

Neuer Archivzeitstempel

X

X

A8.2-33

Neuer Hashbaum

X

X

A8.2-34

Sekundäre ArchiSig-Datenbasis

X

X

X

A8.2-35

ArchiSig-Daten nicht löschen

X

X

X

A8.2-36

Verlässliche Speicher

X

X

A8.2-37

Bitgenaue Reproduktion

X

X

A8.2-38

Regelmäßige Prüfung Lesbarkeit

X

X

A8.2-39

Parallele Zugriffe möglich

X

X

A8.2-40

Nur begrenztes Löschen

X

X

A8.2-41

Redundanter Speicher

X

A8.2-42

Verfügbarkeit der IT-Umgebung

X

A8.2-43

Nicht-Blockierbarkeit (1)

X

X

X

A8.2-44

Nicht-Blockierbarkeit (2)

X

X

X

A8.2-45

Authentisierung in Geschäftsanwendung

X

A8.2-46

Autorisierung Geschäftsanwendung (1)

X

X

A8.2-47

Autorisierung Geschäftsanwendung (2)

X

X

A8.2-48

Zulässiges Kommando

X

X

F.1

Relation Signatur-Daten (1)

A8.2-22

S.6

A8.2-21

S.5

X

S.4

X

S.3

X

S.2

Kanonisierung

S.1

A8.2-20

M.6

X

M.5

X

M.4

Signaturerstellung

M.3

A8.2-19

M.2

M.1

BSI TR 03125

Hauptdokument

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

X

X X X X

X X

X X

X

X X X

Tabelle 5: Zuordnung der Anforderungen

100

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

12. Abkürzungsverzeichnis ADO AIP AktG AO AOID API ArbGG ArbSchG ArbStoffVO ArbZG ARS ASCII ASN.1 ATS AÜG BaFin BArchG BDSG BetrVG BFH BGB BGBl BGH BImSchVO BiostoffVO BMF BMI BMWi BNetzA BSI BStBl CA CC CCITT CMS CRL DES DIN DOMEA DSS DSSC DTD ERS

Archivdatenobjekt (engl.: Archival Information Package, AIP) Archival Information Package Aktiengesetz Abgabenordnung Archive Object ID (Identifier) Application Programming Interface Arbeitsgerichtsgesetz Arbeitsschutzgesetz Verordnung über gefährliche Arbeitsstoffe (Arbeitsstoffverordnung - ArbstoffVO) Arbeitszeitgesetz ArchiSafe Recordkeeping Strategy American Standard Code for Information Interchange Abstract Syntax Notation One Archive Timestamp Arbeitnehmerüberlassungsgesetz Bundesanstalt für Finanzdienstleistungsaufsicht Bundesarchivgesetz Bundesdatenschutzgesetz Betriebsverfassungsgesetz Bundesfinanzhof Bürgerliches Gesetzbuch Bundesgesetzblatt Bundegerichtshof Bundesimmisionsschutzverordnung Biostoffverordnung Bundesministerium für Finanzen Bundesministerium des Innern Bundesministerium für Wirtschaft und Technologie Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post u. Eisenbahnen Bundesamt für Sicherheit in der Informationstechnik Bundesteuerblatt Certification Authority Common Criteria for Information Technology Security Evaluation Comité Consultatif International Téléphonique et Télégraphique Cryptographic Message Syntax Certificate Revocation List Data Encryption Standard Deutsches Institut für Normung Dokumentenmanagement und elektronische Archivierung im IT-gestützten Geschäftsgang Digital Signature Standard Data Structure for Security Suitability’s of Cryptographic Algorithms Document Type Definition Evidence Record Syntax

Bundesamt für Sicherheit in der Informationstechnik

101

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

ETSI EuGH FGO GDPdU GenG GGO GmbHG GMBl GoB GoBS GWG HGB HGrG HSM HTTP IETF IPSec ISIS-MTT ISO IT ITSEC IuKDG JArbSchG JKomG JPEG JustAG KontraG

European Telecommunications Standards Institute Europäischer Gerichtshof Finanzgerichtsordnung Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen Genossenschaftsgesetz Gemeinsame Geschäftsordnung der Bundesministerien GmbH Gesetz Gemeinsames Ministerialblatt Grundsätze ordnungsgemäßer Buchführung Grundsätze ordnungsgemäßer DV gestützter Buchführungssysteme Geldwäschegesetz Handelsgesetzbuch Grundsätze des Haushaltsrechtes des Bundes und der Länder Hardware Security Module Hypertext Transfer Protocol Internet Engineering Task Force Internet Protocol Security Industrial Signature Interoperability Specification-Mailshot International Organization for Standardization Informationstechnologie Information Technology Security Evaluation Criteria Informations- und Kommunikationsdienste-Gesetz Jugendarbeitsschutzgesetz Justizkommunikationsgesetz Joint Photographic Experts Group Justizaufbewahrungsgesetz Gesetz zur Kontrolle und Transparenz im Unternehmensbereich

KoopA-ADV

Kooperationsausschuss Automatisierte Datenverarbeitung Bund, Länder, Kommunaler Bereich

KWG LadenSchlußG LDAP MBO-Ärzte MIME NachwG NIST NJW OAIS OCSP ODF OSCI PDF PK-DML PKCS PKI

102

Kreditwesengesetz Ladenschlussgesetz Lightweight Directory Access Protocol Musterberufsordnung für die deutschen Ärztinnen und Ärzte Multipurpose Internet Mail Extension Gesetz über den Nachweis der für ein Arbeitsverhältnis geltenden wesentlichen Bedingungen National Institute of Standards and Technology (USA) Neue Juristische Wochenschrift Open Archival Information System Online Certificate Status Protocol Open Document Format Online Service Computer Interface Portable Document Format Prüfkriterien für Dokumentenmanagement-Lösungen Public Key Cryptography Standard Public Key Infrastructure

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

PKIX PNG PP PublG RegR RFC RöntgVO RSA S/MIME SAGA SASL SCVP SGB SGG SigG SigV SMTP SNIA SOA SSL ST StÄndG StDAV StGB StrlSchVO TAP TC TCP/IP TDDSG TDG TIFF TLS TS TSP TZ TzBfG UML UrhG USB UStG VELS VwGO VwVfG WpHG WWW XAIP

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

PKI-Arbeitsgruppe der IETF Portabe Network Graphics Format Protection Profile Publizitätsgesetz Registraturrichtlinie des Bundes Request for Comments Röntgenverordnung Rivest Shamir Adleman (kryptographischer Algorithmus und Firmenname) Secure Multipurpose Internet Mail Extension Standards und Architekturen für E-Government-Anwendungen Simple Authentication and Security Layer Server-Based Certificate Validation Protocol Sozialgesetzbuch Sozialgerichtsgesetz Gesetz über Rahmenbedingungen für elektronische Signaturen-(deutsches) Signaturgesetz Verordnung zur elektronischen Signatur-(deutsche) Signaturverordnung Simple Mail Transfer Protocol Storage Network Industry Association Service Oriented Architecture Secure Sockets Layer (Protocol) Security Target Steueränderungsgesetz Steuerdaten-Abrufverordnung Strafgesetzbuch Strahlenschutzverordnung Trustworthy Archival Protocol Trust Center Transmission Control Protocol / Internet Protocol Teledienstdatenschutzgesetz Teledienstegesetz Tagged Image File Format Transport Layer Security Time Stamping Time Stamp Protocol Teilziffer Teilzeit- und Befristungsgesetz Unified Modelling Language Urheberrechtsgesetz Universal Serial Bus Umsatzsteuergesetz Vertrauenswürdige elektronische Langzeitspeicherung Verwaltungsgerichtsordnung Verwaltungsverfahrensgesetz Wertpapierhandelsgesetz Word Wide Web XML formatted Archival Information Package

Bundesamt für Sicherheit in der Informationstechnik

103

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

XML XSD ZDA ZPO

104

BSI TR 03125

eXtensible Markup Language XML Schema Definition Zertifizierungsdiensteanbieter Zivilprozessordnung

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

13. Glossar Absender

Abstract Syntax Notation One (ASN.1)

Akkreditierung

Anscheinsbeweis

ArchiSafe

Eine externe (vorgelagerte) IT-Anwendung (Client Software), die Daten zur Archivierung an das Archivsystem übergibt. Die Abstract Syntax Notation One (ASN.1) ermöglicht es, die Syntax von Daten präzise und unabhängig von der tatsächlichen Codierung zu beschreiben. Sie wurde im Rahmen des [X.408]-Standards entwickelt und dann in [X.680] standardisiert. Die Akkreditierung ist gemäß § 2 Nr. 15 SigG ein freiwilliges „Verfahren zur Erteilung einer Erlaubnis für den Betrieb eines Zertifizierungsdienstes, mit der besondere Rechte und Pflichten verbunden sind“. Zu den Pflichten des akkreditierten Zertifizierungsdiensteanbieters gehört bspw., dass er geprüfte und bestätigte Produkte einsetzen muss (§ 15 Abs. 7 SigG), dass er, sofern er Zertifikate ausstellt, diese mindestens 30 Jahre nach Ablauf der Gültigkeit des Zertifikates nachprüfbar halten muss, und dass er sein Sicherheitskonzept von einer von der Bundesnetzagentur anerkannten Stelle auf seine Eignung und praktische Umsetzung hin prüfen und bestätigen lassen muss. Ein Anscheinsbeweis liegt vor, wenn ein erwiesener Sachverhalt der Lebenserfahrung nach auf einen bestimmten (typischen) Ablauf eines damit zusammenhängenden Sachverhalts hinweist, dieser also indirekt dem Anschein nach bewiesen wird. Anscheinsbeweis (prima-facieBeweis) ist möglich bei typischen Geschehensabläufen. Steht ein Sachverhalt fest, der nach aller Lebenserfahrung auf einen bestimmten Geschehensablauf hinweist, kann dieser Ablauf als bewiesen angesehen werden. Der Anscheinsbeweis ist gesetzlich nicht geregelt. Das Gesetz nimmt aber vereinzelt auf den Anscheinsbeweis Bezug (so etwa § 371a der deutschen Zivilprozessordnung für qualifizierte elektronische Signaturen). Im Rahmen des E-Government Projektes des Bundes "ArchiSafe (Langzeitarchivierung)" wurden die Grundlagen für eine kostengünstige und skalierbare elektronische Archivlösung definiert und in Form eines Pilotsystems realisiert. Die während des Projektes erarbeiteten informationstechnischen Konzepte ermöglichen die dauerhafte rechts- und revisionssichere elektronische Ablage elektronischer Unterlagen. Das Projekt knüpft bewusst an die Ergebnisse des Projektes "ArchiSig" an, in dem wesentliche Grundlagen der rechtssicheren elektronischen Archivierung erarbeitet wurden. Mehr dazu unter http://www.archisafe.de Im Rahmen der Technischen Richtlinie bezeichnet der Begriff „ArchiSafeModul“ eine einheitliche, funktionale Archivschnittstellenkomponente, die ein strikte logische Trennung vorgelagerter IT-Fachanwendungen von den eigentlichen Langzeitspeichersystemen gewährleistet und so imstande ist, unberechtigte Zugriffe auf das Langzeitspeichersystem zuverlässig zu verhindern.

Bundesamt für Sicherheit in der Informationstechnik

105

Vertrauenswürdige elektronische Langzeitspeicherung (VELS) ArchiSig

BSI TR 03125

ArchiSig ist ein vom Bundesministerium für Wirtschaft und Technologie (BMWi) im Rahmen des Programms „VERNET – Sichere und verlässliche Transaktionen in offenen Kommunikationsnetzen“ gefördertes Verbundprojekt zur beweiskräftigen und sicheren Langzeitspeicherung digital signierter Dokumente. Im Rahmen des Projektes ArchiSig wurden aus den allgemeinen gesetzlichen Regelungen konkrete rechtliche Anforderungen an Systeme zur langfristigen Aufbewahrung elektronisch signierter Dokumente abgleitet und prototypisch implementiert. Es konnte erstmalig gezeigt werden, dass die Langzeitaufbewahrung elektronisch signierter Dokumente gesetzeskonform, performant und akzeptabel umgesetzt werden kann. Mehr dazu unter: http://www.archisig.de Im Rahmen der Technischen Richtlinie bezeichnet der Begriff „ArchiSigModul“ eine kryptographische Lösung, die den Erhalt der Authentizität, Integrität und damit des beweisrechtlichen Werts vor allem elektronisch signierter Dokumente durch zusätzliche kryptographische Sicherungsmittel entsprechend der gesetzlichen Anforderungen gewährleistet. Das ArchiSig-Modul implementiert für diesen Zweck eine kryptographische Lösung, die insbesondere sicherstellt, dass das durch § 17 SigV normierte Verfahren zur Aufrechterhaltung der Sicherheit und Vertrauenswürdigkeit elektronischer Signaturen durch eine erneute Signatur zuverlässig und wirtschaftlich, d. h. auch für große Datenmengen, erfüllt werden kann.

Archivanfrage (Archive Request)

Archivdatenobjekt, ADO (Archival Information Packages, AIP)

Archivierung, elektronische A.

Eine XML-basierte Nachricht, die von einer autorisierten externen Anwendung (Client Software) zum ArchiSafe-Modul übertragen wird und eine Archivoperation auslöst. Ein Archivdatenobjekt im Sinne dieser Richtlinie ist ein selbstbeschreibendes und wohlgeformtes XML-Dokument, das gegen ein gültiges und autorisiertes XML-Schema geprüft werden kann. Die dauerhafte und unveränderbare Aufbewahrung (Speicherung) von elektronischen Dokumenten und anderen Daten wird im informationstechnischen Sprachgebrauch allgemein als elektronische Archivierung bezeichnet. Der mit dem Begriff „dauerhaft“ umschriebene Zeithorizont überschreitet dabei aus informationstechnischer Sicht in der Regel kaum mehr als 10 bis 20 Jahre. Aus rechtlicher Sicht ist der Begriff der Archivierung durch die Archivgesetze des Bundes und der Länder konkretisiert und belegt und daher von der zeitlich beschränkten Aufbewahrung zu unterscheiden. Archivierung im juristischen Kontext betrifft allein Unterlagen der öffentlichen Verwaltung und bezieht sich darauf, dass Schriftgut einer zuständigen Behörde ausgesondert und „ewig“ verwahrt werden soll. In deutschen Sprachgebrauch hat sich darüber hinaus für die langfristige elektronische Archivierung zudem der Begriff der elektronischen Langzeitarchivierung eingebürgert. Man spricht von Langzeitarchivierung, wenn die Informationen mindestens 10 Jahre aufbewahrt und zugreifbar gehalten werden. Der Begriff Langzeitarchivierung ist im Prinzip ein Pleonasmus, da Archivierung den Langzeitaspekt bereits impliziert, er hilft aber den Unterschied zur kurzzeitigen Speicherung bzw. zum Backup hervorzuheben. Die Archivierung ist als Teil eines Informationsmanagement-Prozesses zu sehen. Neben der Erzeugung, Bearbeitung und Verwaltung elektronischer Daten und Dokumente spielt die dauerhafte Speicherung eine besondere

106

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Rolle, denn es wird üblicherweise erwartet, dass einerseits die Daten und Dokumente bis zum Ablauf einer vorgegebenen Aufbewahrungsfrist verfügbar sind und andererseits deren Vertraulichkeit und Integrität gewahrt bleibt. Unter Umständen sollen elektronische Daten und Dokumente zeitlich unbegrenzt verfügbar sein. Archivierung, rechtssichere A.

Archivierung, revisionssichere A.

Archivierung, vertrauenswürdige A.

Archivoperation

Archivzeitstempel

Rechtssichere Archivierung im Sinne dieser technischen Richtlinie bedeutet, dass ein zu dieser Richtlinie konformes elektronisches Archivsystem imstande ist, den beweisrechtlichen Wert der in ihm aufbewahrten elektronischen Informationen über die Dauer des Aufbewahrungszeitraumes zu erhalten und so die mit der Aufbewahrung bezweckten Rechtsfolgen elektronischer Unterlagen mindestens für die Dauer der gesetzlich vorgeschriebenen Aufbewahrungszeiträume zu gewährleisten. Mit revisionssicherer elektronischer Archivierung bezeichnet diese technische Richtlinie elektronische Archivsysteme, die nach den Vorgaben des Handelsgesetzbuches (§§ 239, 257 HGB), der Abgabenordnung (§§ 146, 147 AO) und der Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) elektronische Daten und Dokumente sicher, unverändert, vollständig, ordnungsgemäß, verlustfrei reproduzierbar und datenbankgestützt recherchierbar zu verwalten imstande sind. Vertrauenswürdige elektronische Archivierung im Sinne dieser technischen Richtlinie bezeichnet die langfristige, rechts- und revisionssichere elektronische (digitale) Speicherung von aufbewahrungspflichtigen elektronischen (digitalen) Dokumenten und Daten nebst den zugehörigen elektronischen (digitalen) Verwaltungsdaten (Metadaten) auf maschinenlesbaren Datenträgern zur Erfüllung gesetzlicher Aufbewahrungspflichten. Eine Archivoperation ist eine (Operationen) im Archivsystem.

Ausführung definierter Funktionen

Ein Archivzeitstempel ist ein Zeitstempel, der in Verbindung mit einer elektronischen Signatur bestätigt, dass bestimmte zur Ablage im Archiv vorgesehene Daten zu einem bestimmten Zeitpunkt vorgelegen haben. Nach dem ArchiSig-Konzept muss nicht jedes Dokument zeitgestempelt werden. Vielmehr genügt es, Hashbäume, die viele Dokumente repräsentieren, mit einer Signatur oder mit einem Zeitstempel, der eine Signatur enthält, zu versehen.

Asymmetrische Kryptoalgorithmen

Für asymmetrische kryptographische Algorithmen existiert ein komplementäres Schlüsselpaar (privater und öffentlicher Schlüssel), das zur Realisierung digitaler Signaturen, zur Vereinbarung geheimer Schlüssel oder zur Verschlüsselung verwendet werden kann. Das Konzept asymmetrischer Kryptoalgorithmen geht zurück auf W. Diffie und M. Hellman [DiHe 76]. Der heute gebräuchlichste asymmetrische Algorithmus ist der RSA-Algorithmus.

Bundesamt für Sicherheit in der Informationstechnik

107

Vertrauenswürdige elektronische Langzeitspeicherung (VELS) Authentifikation

Authentizität

BArchG

BSI TR 03125

Dient dem Nachweis der Identität eines Benutzers oder eines Kommunikationspartners bzw. der Quelle und Unversehrtheit einer Nachricht. Bei der Authentifikation werden zur Feststellung der Identität Zertifikate einer vertrauenswürdigen Instanz verwendet. Zur Überprüfung der Unversehrtheit (und der Quelle) einer Nachricht dienen Funktionen, die einen kryptographisch gesicherten (signierten) „Fingerabdruck“ der unkodierten Originalnachricht erstellen und mit versenden. Elektronische Daten sind authentisch, wenn sie mit den Ursprungsdaten übereinstimmen und ihnen zweifelsfrei die Identität eines Ausstellers (Verfassers, Erstellers und/oder Absenders) zugeordnet werden kann. Das Bundesarchivgesetz oder Gesetz über die Sicherung und Nutzung von Archivgut des Bundes in Deutschland bestimmt, wie das Archivgut des Bundes durch das Bundesarchiv auf Dauer zu sichern, nutzbar zu machen und wissenschaftlich zu verwerten ist. Archive in diesem Zusammenhang sind (staatliche) Einrichtungen, die die Unterlagen aller Behörden ihres Zuständigkeitsbereichs - im Falle des Bundesarchivs (= Staatsarchiv der Bundesregierung und Bundesverwaltung) also aller Bundesbehörden - übernehmen, bewerten und für die spätere Nutzung im Archiv erschließen und bereitstellen, sobald diese für die Zwecke der Behörde, bei der sie entstanden sind, nicht mehr benötigt werden (§§1 und 2 BArchG). Die Archivierung erfolgt hier nicht auf lange, sondern auf unbegrenzte Zeit (dauerhaft „für die Ewigkeit“. Vgl. Bundesarchivgesetz, Handkommentar, Baden-Baden 2006, § 1 Rz 18).

BASE64

Base64 ist ein Begriff zur Kodierung von Binärdaten in eine Zeichenfolge, die nur aus wenigen, Codepage-unabhängigen ASCII-Zeichen besteht. Das Verfahrene findet vor allem im Internet-Standard MIME (Multipurpose Internet Mail Extensions) Anwendung und wird damit z. B. beim Versenden von E-Mail-Anhängen verwendet. Nötig ist dies, um den problemlosen Transport von beliebigen Binärdaten zu gewährleisten, da SMTP in seiner ursprünglichen Fassung nur für den Versand von 7-Bit ASCII-Zeichen ausgelegt war. Zur Kodierung werden jeweils drei Byte des Bytestroms (=24 bit) in vier 6-bit-Blöcke aufgeteilt. Jeder dieser 6-bit-Blöcke bildet eine Zahl zwischen 0 und 63, woraus sich auch der Name des Algorithmus erklärt. Diese Zahlen werden anhand einer Umsetzungstabelle in „druckbare ASCIIZeichen“ umgewandelt und ausgegeben. Durch diese Kodierung steigt der Platzbedarf um ca. 36% an (33% durch die Kodierung an sich, weitere 3% durch Zeilenumbrüche).

Beweisdaten, technische

108

Technische Beweisdaten dienen dem Nachweis der Unversehrtheit der Integrität und Authentizität der archivierten Datenobjekte. In Übereinstimmung mit den Spezifikationen des ERS-Standards der IETF enthält ein technischer Beweisdatensatz Archivzeitstempel ausreichender Qualität über die gespeicherten (signierten) Archivdatenobjekte, die die Unversehrtheit der Daten nachweisen, und zusätzlich Informationen, welche die Richtigkeit und die Gültigkeit elektronischer Signaturen zum Signaturzeitpunkt sowie die rechtzeitige Signaturerneuerung entsprechend der rechtlichen Anforderungen belegen.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125 Beweisrelevante Daten

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Beweisrelevante Daten sind Signaturen bzw. Zeitstempel zu genau einem Datenobjekt bzw. Dokument und enthalten auch die für die Prüfung der Signatur bzw. Zeitstempelsignatur notwendigen Prüfdaten wie z. B. Zertifikate sowie CRL-Listen und OCSP-Responses zu diesen Zertifikaten. Die Beweisdaten belegen, dass das Dokument ab dem Zeitpunkt der Archivierung nicht mehr verändert wurde. Die beweisrelevanten Daten belegen, dass die ggf. außerhalb des Archives erzeugten Signaturen und Zeitstempel gültig sind bzw. zum Erstellungszeitpunkt gültig waren.

Client

Client Software

Common Criteria (CC)

Cryptographic Message Syntax (CMS) RFC 3852

Eine Behörde, Verwaltungseinheit oder ein Unternehmen die wenigstens eine Client Software (IT-Fachanwendung) betreibt, mit der elektronische Daten und Dokumente rechts- und revisionssicher in einem Langzeitspeicher abgelegt werden sollen. Eine externe (vorgelagerte) IT-Anwendung, die imstande und autorisiert ist, über das ArchiSafe-Modul Daten im Langzeitspeicher zu archivieren, archivierte Daten zu suchen, abzurufen oder zu löschen. Mit den Common Criteria for Information Technology Security Evaluation (kurz. Common Criteria [CC]) wurde ein internationaler Standard (ISO 15408) für die Bewertung und Zertifizierung der Sicherheit von Computersystemen geschaffen. Die CC sehen verschiedene Vertrauenswürdigkeitsstufen (Evaluation Assurance Level) vor, von den Stufen „EAL 1“ (funktionell getestet) bis „EAL 7“ (formal verifizierter Entwurf und getestet). Die Cryptographic Message Syntax (CMS) ist eine durch die Internet Engineering Task Force (IETF) veröffentlichte Spezifikation, die in ASN.1 Syntax beschreibt, wie Daten durch kryptographische Maßnahmen wie digitale Signaturen oder Verschlüsselung geschützt, respektive Signaturdaten über das Internet ausgetauscht werden können. Sie basiert auf dem ursprünglich durch die RSA Laboratories veröffentlichten PKCS#7 (Public Key Cryptography Standard) Dokument in der Version 1.5, das eine allgemeine Syntax für Daten darstellt, auf die kryptographische Operationen wie digitale Signaturen oder digitale Umschläge angewendet wurden. Der PKCS#7v1.5 Standard ist Grundlage des S/MIME Protokolls und der in PDF-Dokumenten eingebetteten elektronischen Signaturen sowie der Authentizitätssicherung von ausführbaren Software-Dateien. Die Syntax ist rekursiv, so dass Daten und Umschläge verschachtelt oder bereits chiffrierte Daten unterschrieben werden können. Die Syntax ermöglicht zudem, dass weitere Attribute, wie z. B. Zeitstempel, mit den Daten oder dem Nachrichteninhalt authentifiziert werden können und unterstützt eine Vielzahl von Architekturen für die Schlüsselverwaltung auf der Basis von elektronischen Zertifikaten.

Bundesamt für Sicherheit in der Informationstechnik

109

Vertrauenswürdige elektronische Langzeitspeicherung (VELS) Daten

BSI TR 03125

Oberbegriff für alle Informationen, die von elektronischen Medien gelesen, elektronisch verarbeitet oder auf elektronischen Medien gespeichert werden. In der Informationstechnik werden häufig Daten von Dokumenten unterschieden. Ein Datenmodell beschreibt innere Strukturen und Beziehungen von Daten untereinander. Die Beschreibung des Modells erfolgt in der Regel durch eine formale Darstellung, bspw. durch ein UML-Klassendiagramm und zusätzliche textuelle Beschreibung.

Deterministischer Algorithmus

Dokument

Dokument Type Definition (DTD)

DOMEA

Eigentümer

Evidence Record Evidence Record Syntax

110

Ein deterministischer Algorithmus ist ein Algorithmus, der zu einer bestimmten Eingabe immer die gleiche Folge von Operationen ausführt, d. h. zu jedem Zeitpunkt ist die folgende Operation des Algorithmus eindeutig festgelegt. Alle Arten von Informationen, die zur Wahrnehmung durch den Menschen bestimmt sind und als Einheit zwischen Systemen oder Benutzern ausgetauscht werden können. Bei elektronischen Dokumenten sind die Informationen maschinell lesbar und verarbeitbar und werden ganz allgemein als Daten bezeichnet. Eine Definition, die die syntaktischen Regeln angibt, nach denen ein Dokument erzeugt werden kann. Eine DTD definiert, wie Elemente und Attribute einer Markup-Sprache wie SGML, HTML oder XML zusammengestellt werden können. Mit Hilfe einer DTD und eines Parsers kann geprüft werden, ob ein bestimmtes Dokument entsprechend einer zugrunde liegenden DTD aufgebaut, d. h. syntaktisch gültig ist. DOMEA steht für „Dokumentenmanagement und elektronische Archivierung im IT-gestützten Geschäftsgang“ und ist ein Konzept für Dokumentenmanagement und elektronische Archivierung in der öffentlichen Verwaltung. Wesentliches Ziel des DOMEA-Konzeptes ist die Einführung der elektronischen Akte als Weiterentwicklung des Konzeptes Papierarmes Büro aus dem Jahr 1996. Da für die elektronische Akte die gleichen Gesetze, Geschäftsordnungen, Richtlinien und Vorschriften wie für Papierakten gelten, müssen behördliche Geschäftsprozesse, Vorgangsbearbeitung und Archivierung vollständig in konforme IT-Prozesse überführt werden. Das DOMEA-Konzept liefert dafür Richtlinien, ist aber trotz seiner weiten Verbreitung und der Möglichkeit der Zertifizierung kein genormter Standard. Das Konzept liegt seit November 2005 in der Version 2.1 vor. Der Eigner (Eigentümer) eines Archivdatenobjektes ist die Client Software, die das Archivdatenobjekt zur Ablage im Langzeitspeicher über das ArchiSafe-Modul übergeben hat. Siehe „Beweisdaten, technische“ und auch [RFC4998]

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125 Hashfunktion

Hashwert

IETF

Information

Integrität

Interoperabilität

ISO 15498

Konfigurationsdaten

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Eine Hashfunktion ist ein kryptographischer Algorithmus, bei dem (elektronische) Nachrichten beliebiger Länge auf einen Hashwert fester Länge (z. B. 160 Bit) abgebildet werden. Bei kryptographisch geeigneten Hashfunktionen ist es praktisch unmöglich zwei Nachrichten mit dem gleichen Hashwert zu finden (Kollisionsresistenz) und für einen gegebenen Hashwert eine Nachricht zu finden, die durch die Hashfunktion auf den Hashwert abgebildet werden kann (Einwegeigenschaft). Ein Hashwert ist eine eindeutige Prüfsumme elektronischer Daten und wird auch als Message Digest oder digitaler „Fingerabdruck“ der Daten bezeichnet. Eine Hashfunktion zur Berechnung des Hashwertes ist eine mathematisch oder anderweitig definierte Funktion, die ein Eingabedatum variabler Länge aus einem Urbildbereich (auch als „Universum“ bezeichnet) auf ein (in der Regel kürzeres) Ausgabedatum fester Länge (den Hashwert) in einem Bildbereich abbildet. Das Ziel ist, einen „Fingerabdruck“ der Eingabe zu erzeugen, die eine Aussage darüber erlaubt, ob eine bestimmte Eingabe aller Wahrscheinlichkeit nach mit dem Original übereinstimmt. Internet Engineering Task Force, eine offene, technisch orientierte internationale Gemeinschaft von Netzwerkdesignern, professionellen Anwendern und Herstellern, die sich mit den technischen Grundlagen des Internets sowie mit Netzwerkmanagement befasst. Für die Aneignung, Übermittlung und Verarbeitung „in Form“ gebrachte Kenntnisse oder Tatsachen, wie Mitteilungen, Nachrichten, Daten oder Messwerte. In der Informatik werden Informationen betrachtet, die Gegenstand von maschineller Speicherung, Verarbeitung und Übertragung sind, überwiegend als Folge von Zeichen aus einem bestimmten Zeichenvorrat (bspw. einem Alphabet). Elektronische Daten sind integer, wenn sie vollständig sind und nachweislich keine Veränderungen oder Manipulationen an den Daten festgestellt werden können. Interoperabilität bezeichnet im weiteren Sinne die Fähigkeit verschiedener Geräte- oder Softwarekomponenten, direkt miteinander kommunizieren, d. h. insbesondere Daten austauschen zu können. Im engeren Sinne ist I. die Fähigkeit von IT-Systemen, direkt mit anderen Systemen zu kommunizieren, wenn sie über ein Netz verbunden sind. ISO 15489 ist ein internationaler Standard, der in Deutschland unverändert als DIN-Norm übernommen wurde. Er bietet Leitlinien zur Verwaltung von Schriftgut von öffentlichen und privaten Organisationen. Schlüsselbegriffe sind 'Aktenführung', 'Schriftgutverwaltung' oder Records Management. Die Zielsetzung der Norm besteht darin, für die Verwaltung und Aufbewahrung von Unterlagen - unabhängig von ihrer physischen Beschaffenheit und der logischen Struktur - einen Rahmen zu schaffen. Dazu zählen alle modulinternen Daten, die für eine korrekte Ausführung der sicherheitsrelevanten Funktionen, insbesondere die korrekte und zuverlässige Identifizierung und Authentifzierung der externen Anwendungen, sowie der internen Module des Archivsystems sowie die Überprüfung und Ausführung der Archivanfrage benötigt werden.

Bundesamt für Sicherheit in der Informationstechnik

111

Vertrauenswürdige elektronische Langzeitspeicherung (VELS) Konformität

Mandantenfähig

Metadaten

BSI TR 03125

Konformität bedeutet die Übereinstimmung eines Systems oder Komponente mit den für diese Art von Systemen oder Komponenten (System- bzw. Komponentenklasse) definierten Anforderungen. Als mandantenfähig (auch mandantentauglich) wird Informationstechnik bezeichnet, die auf demselben Server oder demselben Software-System mehrere Mandanten, also Kunden oder Auftraggeber, bedienen kann, ohne dass diese gegenseitigen Einblick in ihre Daten, Benutzerverwaltung und ähnliches haben. Ein IT-System, das dieser Eigenschaft genügt, bietet die Möglichkeit der disjunkten, mandantenorientierten Datenhaltung, Präsentation (GUI) und Konfiguration (Customizing). Jeder Kunde kann nur seine Daten sehen und ändern. (Quelle: Wikipedia) Metadaten sind im weitesten Sinne Daten, die andere Daten beschreiben. Metadaten sind i. d. R. Daten, die die Strukturen und den Zusammenhang von Daten bei der Verarbeitung der Daten durch die IT-Systeme beschreiben, die die Daten erzeugen, bearbeiten, verwalten und speichern. Metadata are the data that describe the structure and the workings of an organization's use of information, and which describe the systems it uses to manage the information. Metadaten eines Archivdatenobjektes sind i. d. R. textbasierte XMLMetadaten zur Identifikation und Rekonstruktion des Verwaltungs- oder Geschäftkontextes der Nutzdaten.

Middleware

Migration

112

Software für den direkten Datenaustausch zwischen Anwendungsprogrammen, IT-Systemen oder IT-Komponenten, die unter verschiedenen Betriebssystemen oder in heterogenen IT-Umgebungen (Netzen) arbeiten. Der Begriff Migration bezeichnet in der Informationstechnik die Transformation von Daten auf ein anderes Betriebs- oder Speichersystem oder in ein anderes Datenformat. Für die vertrauenswürdige Langzeitaufbewahrung elektronischer Daten von besonderer Bedeutung ist dabei die Tatsache, dass bei einem solchen Vorgang die Authentizität und Integrität der Daten nicht beeinträchtigt werden darf. Wie das zu bewerkstelligen ist, ist Gegenstand des Projektes TransiDoc.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125 MoReq2

Nachsignatur

Nichtabstreitbarkeit

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

MoReq (Model Requirements for the Management of Electronic Documents and Records) ist der europäische Standard für das elektronische Records Management. Er wurde im Rahmen des IDAProgrammes der Europäischen Kommission entwickelt und vom DLMForum veröffentlicht. Ursprünglich sollte MoReq zur Vereinheitlichung des Dokumentenaustauschs zwischen der europäischen Kommission und den Regierungen der Mitgliedsstaaten beitragen. Inzwischen hat sich MoReq als Grundlage für verschiedene Standards für das elektronische Dokumenten-, Archiv- und Records-Management etabliert. An MoReq orientieren sich z. B. die Standards für das Records Management in der öffentlichen Verwaltung in England (TNA), in den Niederlanden (ReMano), in Norwegen (NOARK) und Luxemburg (SEL ECM). MoReq liefert im Gegensatz zu anderen Standards (wie z. B. ISO 15489) eine sehr detaillierte Anforderungsliste sowohl für funktionale Anforderungen an ein elektronisches und papierbasiertes Records Management System, als auch für die dazugehörigen elektronischen Vorgangsbearbeitungs- und Dokumenten-Management-Systeme. MoReq schließt auch Richtlinien zur Betrachtung von operationalen Systemen und Managementsystemen ein und erstellt nicht nur Anforderungen für eine Aufbewahrung von elektronischen Aufzeichnungen, sondern auch für die Anforderungen anderer elektronischer dokumentenbezogener Funktionen wie Workflow, E-Mail und Elektronische Signaturen. MoReq2 ist die aktuelle und umfassendste Spezifikation für Records Management. Die für die elektronische Signatur eingesetzten Algorithmen und Parameter können mit wachsender Rechenleistung oder der Verfügbarkeit verbesserter Algorithmen ihre Sicherheitseignung verlieren, so dass die Beweiskraft elektronisch signierter Daten abnehmen würde. Deshalb sieht § 17 [SigV] vor, dass Daten mit einer qualifizierten elektronischen Signatur neu zu signieren sind, „wenn diese für längere Zeit in signierter Form benötigt werden, als die für ihre Erzeugung und Prüfung einge­ setzten Algorithmen und zugehörigen Parameter als geeignet beurteilt sind. In diesem Falle sind die Daten vor dem Zeitpunkt des Ablaufs der Eignung der Algorithmen oder der zugehörigen Parameter mit einer neuen qualifizierten elektronischen Signatur zu versehen. Diese muss mit geeigneten neuen Algorithmen oder zugehörigen Parametern erfolgen, frühere Signaturen einschließen und einen qualifizierten Zeitstempel tragen.“ Unter Nichtabstreitbarkeit (eng. non-repudiation) versteht man, dass die Urheberschaft, der Versand oder der Empfang von Daten und Informationen nicht in Abrede gestellt werden können.

Bundesamt für Sicherheit in der Informationstechnik

113

Vertrauenswürdige elektronische Langzeitspeicherung (VELS) OAIS

BSI TR 03125

OAIS steht für Open Archival Information System bzw. Offenes ArchivInformations-System (ISO-Standard 14721:2003). Der Grund für die Entwicklung dieses Modells bestand in der Einsicht, dass elektronisch archivierte Dokumente nach längerer Zeit aus vielfältigen Gründen nicht mehr lesbar sein könnten. Das Referenzmodell beschreibt ein Archiv als Organisation, in dem Menschen und Systeme zusammenwirken, um einer definierten Nutzergemeinde Archivgut verfügbar zu machen. Die Implementierung eines OAIS-konformen Archivs ist dabei jedoch nicht festgelegt. Die Entwicklung des Standards wurde von der NASA initiiert und gemeinsam mit der Raumfahrtorganisation ESA und Weltraumforschungszentren in Großbritannien, Kanada, Frankreich, Deutschland, Brasilien, Japan und Russland vorangetrieben. Im Mai 1999 legte das Beratungskomitee für Weltraumdatensysteme (CCSDS) den Entwurf "Referenzmodell für ein offenes Archiv-Informationssystem (OAIS)" vor.

OCSP (RFC 2560)

Öffentlicher Schlüssel

Personal Security Environment (PSE)

Privater Schlüssel

Protokolldaten

114

Das Online Certificate Status Protocol [RFC 2560] ist ein Protokoll für die Online-Statusabfrage eines elektronischen Zertifikats bei einem Zertifizierungsdiensteanbieter. Ein öffentlicher Schlüssel ist jener Teil eines kryptographischen Schlüsselpaares, der öffentlich bekannt und frei zugänglich ist. Er kann in einem Zertifikat enthalten sein und wird neben der Prüfung digitaler Signaturen auch verwendet, um Daten zu verschlüsseln. Eine PSE ist ein Aufbewahrungsmedium für private Schlüssel und vertrauenswürdige Zertifikate. Eine PSE kann entweder als SoftwareLösung, z. B. als eine mittels Passwort geschützte Datei im PKCS#12 Format oder als Hardware-Lösung, beispielsweise in Form einer Smart Card (Chipkarte) realisiert sein. Der private Schlüssel ist jener Teil eines kryptographischen Schlüsselpaares, auf das nur der Inhaber des Schlüsselpaares zugreifen kann. Er wird verwendet, um Daten zu signieren und um verschlüsselte Daten zu entschlüsseln. Protokolldaten sind Log-Informationen, die durch ein Modul erzeugt und für einen konfigurierbaren Zeitraum aufbewahrt oder dem Archivdatenobjekt hinzugefügt werden.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125 Public Key Cryptography Standards (PKCS)

Public Key Infrastructure (PKI)

Qualifizierte elektronische Signatur

Qualifizierter Zeitstempel

Qualifiziertes Zertifikat

Regeln

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

PKCS ist eine von der US amerikanischen Firma RSA Security Inc. entwickelte Reihe von Standards für Technologien auf Basis von asymmetrischen Kryptoalgorithmen. Zu den wichtigsten Standards in dieser Reihe gehören: •

PKCS#1: RSA Cryptography Standard, ein sehr häufig eingesetztes Low-Level-Signaturformat auf der Basis des RSAAlgorithmus. Die aktuelle Version ist PKCS#1, V. 2.1 [RFC3447]

•

PKCS#7: Cryptographic Message Syntax Standard, ein sehr weit verbreitetes High-Level-Signaturformat, das von vielen Standard-Softwarekomponenten unterstützt wird. Die CMSSpezifikation der IETF [RFC2630, RFC3369, RFC3852] basiert auf diesem Standard.

•

PKCS#11: Cryptographic Token Interface Standard, eine Programmierschnittstelle für den standardisierten Zugriff auf Chipkartenfunktionen.

•

PKCS#12: Personal Information Exchange Syntax Standard, ein Datenformat für den Austausch von mittels Passwort verschlüsselten privaten Schlüsseln.

Eine PKI ist eine technische und organisatorische Infrastruktur, die es ermöglicht, auf asymmetrischen Kryptoverfahren basierende digitale Zertifikate auszustellen, zu verteilen, zu verwalten und zu prüfen. Eine qualifizierte elektronische Signatur ist gemäß § 2 Nr.3 SigG eine fortgeschrittene elektronische Signatur, die unter Verwendung einer sicheren Signaturerstellungseinheit erzeugt wurde und zum Zeitpunkt der Signaturerstellung auf einem gültigen qualifizierten Zertifikat beruht. Ein qualifizierter Zeitstempel ist gemäß § 2 Nr.14 SigG ein Zeitstempel, der von einem Zertifizierungsdiensteanbieter gemäß Signaturgesetz ausgestellt wird. Ein qualifiziertes Zertifikat ist gemäß § 2 Nr.7 SigG ein Zertifikat, das von einem Zertifizierungsdiensteanbieter für natürliche Personen ausgestellt wird. Die detaillierten Inhalte eines qualifizierten Zertifikats ergeben sich aus § 7 SigG. Regeln spezifizieren Operationen, die durch das die Module bei der Ablage, dem Abruf oder der Löschung von Archivdatenobjekten auszuführen sind. Sie werden durch die Organisation spezifiziert, die ein zu dieser Richtlinie konformes Archivsystem nutzt. . Solche Regeln können bspw. sein, dass das ArchiSafe-Modul jedes Archivdatenobjekt vor der Ablage im Langzeitspeicher mit einem initialen elektronischen Zeitstempel versehen und dafür die Dienste eines externen Zeitstempeldienstes in Anspruch nehmen soll.

Bundesamt für Sicherheit in der Informationstechnik

115

Vertrauenswürdige elektronische Langzeitspeicherung (VELS) Relax NG

BSI TR 03125

Regular Language Description for XML New Generation (RELAX NG) ist eine einfache Schemasprache für XML. Ein RELAX-NG-Schema spezifiziert Muster für die Struktur und den Inhalt eines XML-Dokuments. Dabei ist ein RELAX-NG-Schema selbst ein XML-Dokument, jedoch bietet es auch eine kompakte Nicht-XML-Syntax an. RELAX NG ist beschrieben in einem Dokument der OASIS RELAX NG Technical Committee und darüber hinaus als internationaler Standard ISO/ IEC 19757-2 innerhalb der Document Schema Definition Languages (DSDL).In der Komplexität steht Relax NG etwa zwischen DTD und XML-Schema. Gegenüber der einfachen DTD hat Relax NG vor allem den Vorteil, (wahlweise) XML-Syntax zu verwenden und auch ungeordnete Inhalte zu unterstützen. Darüber hinaus kennt es Datentypen und Namespaces. Siehe auch unter http://relaxng.org/

RSA

SAGA Standards und Architekturen für E-GovernmentAnwendungen

SASL

Schema

Schnittstelle (Interface)

116

Der nach seinen Erfindern (Rivest, Shamir und Adleman) benannte RSAAlgorithmus ist ein asymmetrischer Kryptoalgorithmus, der zur Verschlüsselung und zur Erzeugung digitaler Signaturen verwendet werden kann. Die Sicherheit des Verfahrens beruht auf der Annahme, dass das dem Algorithmus zugrunde liegende Faktorisierungsproblem für große Zahlen nicht effizient gelöst werden kann. Die Richtlinie „Standards und Architekturen für E-Government-Anwendungen (SAGA)“ definiert Empfehlungen zum Einsatz von IT-Standards und IT-Architekturen in E-Government-Projekten der Bundesverwaltung. Ziel ist, die Interoperabilität, die Offenheit und Skalierbarkeit, Wiederverwendbarkeit und die Investitionssicherheit von E-Government Anwendungen zu fördern. Simple Authentication and Security Layer (SASL) ist ein Framework, das von verschiedenen Protokollen zur Authentifizierung verwendet wird. Es wurde im Oktober 1997 als RFC 2222 definiert und im Juni 2006 durch [RFC4422] ersetzt. SASL bietet dem Applikationsprotokoll eine standardisierte Möglichkeit der Aushandlung von Kommunikationsparametern. Im Regelfall wird nur eine Authentifizierungsmethode ausgehandelt, es kann aber auch vereinbart werden, dass zuerst auf ein verschlüsseltes Transportprotokoll, wie beispielsweise TLS, gewechselt wird. Die SASL-Implementierungen auf beiden Seiten der Kommunikationspartner einigen sich auf ein Verfahren und dieses kann dann von der Applikation transparent benutzt werden. Ein Schema beschreibt die syntaktische Struktur einer XML-Datei und definiert damit einen Dokumententyp von XML-Dokumenten. Verbreitete Sprachen für die Erstellung von Schemata sind XML-Schema (XSD) und Relax NG. Verbindungs- oder Berührungspunkte von Systemen oder Komponenten, die miteinander kommunizieren oder zusammenarbeiten. Die Informationstechnik unterscheidet Hardware, Software- und Benutzerschnittstellen. Software-Schnittstellen dienen dem Datenaustausch von Anwendungen oder Komponenten untereinander bzw. mit dem Betriebssystem.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125 SCVP

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Server-Based Certificate Validation Protocol (SCVP) ist ein InternetProtokoll, das es Clients ermöglicht, den Aufbau einer X.509Zertifikatskette und deren Validierung auszulagern. Dies wird vor allem bei Clients, die mit dem Kettenaufbau und der Validierung aufgrund fehlender Ressourcen oder Protokolle überlastet sind, benötigt. SCVP kann dem Client alle Aufgaben (Aufbau der Kette, Überprüfung auf Widerruf, Validierung) einer vollständigen Zertifikatsprüfung abnehmen. Im Gegensatz zu OCSP besteht SCVP aus zwei Nachrichten: Zunächst fragt der Client den Server nach unterstützten Validation Policies, die bestimmen für welche Anwendungen der Server konfiguriert wurde. Danach schickt der Client dem Server die Zertifikats-IDs und gibt an, welche Aktionen durchzuführen sind, die der Server signiert beantwortet. SCVP ist noch sehr neu und wird bisher nur von wenigen Anwendungen unterstützt.

Semantik

SHA-1

Sichere Signaturerstellungseinheit (SSEE)

Sicherungsmittel

Die Semantik definiert – im Gegensatz zur Syntax – die Bedeutung der gültigen Zeichen, Wörter und Sätze einer Sprache. Der Secure-Hash-Algorithm (SHA-1) [FIPS180-2] ist ein von der USamerikanischen Sicherheitsbehörde NSA entwickelter Hashalgorithmus, der Hashwerte von der Länge 160 Bit erzeugt. Eine sichere Signaturerstellungseinheit ist gemäß § 2 Nr.10 SigG eine Signaturerstellungseinheit, die den Anforderungen des SigG, insbesondere § 17 Abs. 1 SigG und § 15 Abs. 1 SigV genügt. Dazu gehört bspw., dass selbst der Signaturschlüssel-Inhaber seinen privaten Schlüssel nicht aus der Signaturerstellungseinheit auslesen und veröffentlichen kann. I. d. R. wird dies in Form einer Chipkarte realisiert. Die Erfüllung der Anforderungen muss durch anspruchsvolle Prüfungen nach international anerkannten Sicherheitskriterien und eine Bestätigung gemäß Signaturgesetz nachgewiesen werden. Sicherungsmittel sind technische und organisatorische Maßnahmen (Vorkehrungen) mit dem Ziel, eine langfristige und unveränderbare Aufbewahrung elektronischer Dokumente in einem Archivsystem sicherzustellen. Systembezogene Sicherungsmittel beschränken durch eine individuelle Konfiguration des Archivsystems oder der auf dieses zugreifenden Komponenten den Zugriff auf die Daten, z. B. durch Berechtigungssysteme. Datenträgerbezogene Sicherungsmittel sind Speichermedien, die ein Überschreiben oder Verändern der auf ihnen abgelegten Informationen ausschließen. Dokumentbezogene Sicherungsmittel sind solche, die die elektronischen Dokumente selbst gegen unbemerkte Veränderungen und unberechtigte Kenntnisnahme zu schützen imstande sind, z. B. Verschlüsselungstechnologien.

Bundesamt für Sicherheit in der Informationstechnik

117

Vertrauenswürdige elektronische Langzeitspeicherung (VELS) Signatur, elektronische S.

BSI TR 03125

Elektronische Signaturen sind gemäß Signaturgesetz „Daten in elektronischer Form, die anderen elektronischen Daten beigefügt oder logisch mit ihnen verknüpft sind und die zur Authentifizierung“ im elektronischen Rechts- und Geschäftsverkehr dienen. Ihre Aufgabe ist die Identifizierung des Urhebers der Daten, d. h. der Nachweis, dass die Daten tatsächlich vom Urheber herrühren (Echtheitsfunktion) und dies vom Empfänger der Daten auch geprüft werden kann (Verifikationsfunktion). Beides lässt sich nach dem heutigen Stand der Technik zuverlässig am ehesten auf der Grundlage kryptographischer Authentifizierungssysteme, bestehend aus sicheren Signaturalgorithmen sowie dazu passenden und personifizierten Signaturschlüsseln realisieren. Technisch bezeichnet eine elektronische (digitale) Signatur den mit einem privaten Signaturschlüssel „verschlüsselten“ Hashwert einer Information (Dokumentes oder Nachricht). Da der Hashwert in diesem Fall als eindeutiger elektronischer Repräsentant der Information angesehen werden kann, bezeugt der „verschlüsselte“ Hashwert die Authentizität der Information. Die Überprüfung der elektronischen Signatur erfolgt mit Hilfe des öffentlichen Schlüssels des Ausstellers der Information, der entweder in der Signatur selbst enthalten ist oder über die in der Signatur enthaltenen Zertifikatsinformationen beschafft werden kann.

Signaturanwendungskomponente

Signaturprüfung

SOA Service Oriented Architecture

118

Signaturanwendungskomponenten sind gemäß § 2 Nr.11 SigG Softwareoder Hardwareprodukte, die dazu bestimmt sind, Daten dem Prozess der Erzeugung oder Prüfung qualifizierter elektronischer Signaturen zuzuführen oder qualifizierte elektronische Signaturen zu prüfen oder qualifizierte Zertifikate nachzuprüfen und die Ergebnisse anzuzeigen. Die Signaturprüfung umfasst zwei Prüfungsschritte. Beim ersten Schritt wird die mathematische Gültigkeit der Signatur zum Nachweis der Integrität geprüft. Im zweiten Schritt wird für den Nachweis der Authentizität die Gültigkeit der gesamten Signatur im Hinblick auf das zugrunde liegende Gültigkeitsmodell geprüft. Dies umfasst die Prüfung, ob das zur Signaturerstellung verwendete Zertifikat zum Referenzzeitpunkt, d. h. bei einer qualifizierten elektronischen Signatur der Zeitpunkt der Signaturerstellung und bei einer zur Authentifizierung verwendeten Signatur der aktuelle Zeitpunkt, gültig ist. Für die Gültigkeit eines Zertifikats wird geprüft, ob die durch den Aussteller der Zertifikats gesetzte Signatur gültig ist, ob Zertifikatserweiterungen richtig gesetzt wurden und ob ein Zertifikatspfad zu einem vertrauenswürdigen Wurzelzertifikat gebildet werden kann und ob das Zertifikat nicht gesperrt wurde. Der Begriff service oriented architecture (SOA) oder deutsch „diensteorientierte Architektur“ ist ein Managementkonzept und setzt ein Systemarchitektur-Konzept voraus: Das Managementkonzept strebt eine an den gewünschten Geschäftsprozessen ausgerichtete IT-Infrastruktur an, die schnell auf veränderte Anforderungen im Geschäftsumfeld reagieren kann. Das Systemarchitektur-Konzept sieht daher die „Abbildung“ und das Zusammenwirken einzelner Geschäftsprozesse (oder Teilen davon) über die Bereitstellung fachlicher Dienste und Funktionalitäten in Form von autonomen, lose gekoppelten IT-Services vor.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125 Standard

Syntax

Time-Stamp Protocol (TSP)

TransiDoc

UML Unified Modeling Language

Verbindlichkeit

Verfügbarkeit

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Ein Standard bezweckt die Vereinheitlichung von Gütern, Leistungen oder Prozessen nach bestimmten Mustern. In der Informationstechnik dienen Standards bspw. dem Ziel, für eine Gruppe von Anwendern und für einen gewissen Zeitraum allgemein akzeptierte und öffentlich zugängliche Regeln aufzustellen, die es ermöglichen, verschiedenartige IT-Systeme im Verbund einzusetzen. Absicht einer derartigen Standardisierung ist ein technisches oder logisches Muster für die Harmonisierung des Datenaustausches zwischen den IT-Systemen mit dem Ziel, die Transaktionskosten der Datenaustauschprozesse zu senken und die Qualität zu erhöhen. Die Syntax definiert, wie gültige Sätze einer Sprache aufgebaut werden. So besteht eine Sprache aus einer Menge gültiger Symbole (Zeichen, Wörter) und einem Regelwerk (Grammatik), das besagt, wie die einzelne Zeichen oder Wörter miteinander kombiniert werden, um gültige Sätze zu formen. Die Syntax trifft aber keine Aussage über die Bedeutung (Semantik) der gebildeten Sätze. TSP ist ein in [RFC3161] von der IETF standardisiertes Client-ServerProtokoll zur Ausstellung von Zeitstempeln. TransiDoc (Transformation signierter Dokumente) ist ein vom BMWi gefördertes Forschungsprojekt mit dem Ziel, Anforderungen und Regeln (Normen) für die rechtssichere Transformation elektronisch signierter Dokumente zu spezifizieren. Die Unified Modelling Language (UML) ist eine seit Ende der 1990er Jahre entwickelte grafische Modellierungssprache für die einheitliche Beschreibung und Darstellung von Geschäftsprozessen sowie der Funktionalität und Kommunikation komponentenbasierter IT-Systeme. Sie hat sich nach der Standardisierung durch die Object Management Group (OMG) weltweit zum Standard für Analyse und Designnotationen entwickelt. UML liegt seit August 2003 in der Version UML 2 vor und wird im Software Engineering besonders in der Frühphase der Anforderungsdefinition und der Systemkonzeption eingesetzt und stellt Diagramme und Notationselemente zur Verfügung, mit deren Hilfe statische und dynamische Aspekte beliebiger Anwendungsgebiete modelliert werden können. Unter Verbindlichkeit versteht man, dass ein Rechtsgeschäft seine beabsichtigte rechtliche Wirkung entfaltet. Voraussetzung ist teilweise die Einhaltung von Formerfordernissen (bspw. Schriftform) und das Vorhandensein von Beweismitteln. Elektronische Informationen sind verfügbar, wenn auf sie in einer angemessenen Zeit zugegriffen werden kann, und wenn sie auf den zum Zeitpunkt des Zugriffs eingesetzten IT-Systemen für menschliche Benutzer lesbar dargestellt werden können

Bundesamt für Sicherheit in der Informationstechnik

119

Vertrauenswürdige elektronische Langzeitspeicherung (VELS) Verifikationsdaten

Verkehrsfähigkeit

Vertraulichkeit

BSI TR 03125

Verifikationsdaten sind Daten, die dem Nachweis des Übereinstimmens von Ist-Eigenschaften mit den durch ein Ziel, einen Zweck oder eine Spezifikation definierten Soll-Eigenschaften eines Systems, einer Komponente oder von Daten oder Datengruppen dienen. Die Art und der Umfang der für einen solchen Nachweis erforderlichen Verfikationsdaten bestimmt sich daher immer auch aus den ziel- oder zweckbestimmmten Soll-Eigenschaften. Verkehrsfähigkeit bezeichnet die Möglichkeit, dass elektronische Daten und Dokumente technisch unverändert auf den zum Zeitpunkt ihrer in Verkehrsbringung üblichen DV-Systemen angeeignet, d. h. lesbar angezeigt, bzw. übertragen oder gespeichert werden zu können. Schutz vor unbefugter Kenntnisnahme zur Sicherung personenbezogener Daten und betriebs- oder berufsbezogener Geheimnisse. Die Vertraulichkeit ist die einzige bei der Aufbewahrung elektronischer Dokumente zu berücksichtigende Anforderung, die sich nicht aus den Aufbewahrungszwecken, sondern aus anderen zu schützenden Rechtsgütern ergibt.

W3C World Wide Web Consortium

X.509

XML Extensible Markup Language

XML Schema Definition

120

Das W3C ist ein Zusammenschluss von Wirtschaft und Wissenschaft mit dem Ziel, interoperable Technologien zu entwickeln, um das gesamte Potenzial des World Wide Web ausschöpfen zu können. Es erstellt seine Standards als Empfehlungen und hat sich verpflichtet, ausschließlich Technologien zu verwenden, die frei von Patent-Gebühren sind. [X.509] ist ein internationales Standardformat für Ausstellung digitaler PKI Zertifikate über die Identität des Zertifikatinhabers. Die Extensible Markup Language (XML) ist eine vor allem für das Internet entwickelte Formatbeschreibungssprache für den Austausch strukturierter Daten und wurde 1997 vom Word Wide Web Consortium (W3C) standardisiert (mehr unter: http://www.w3c.org/XML/). XML-Schema Definition (XSD) ist eine Empfehlung des W3C zur Spezifikation syntaktischer Regeln für den Aufbau von XML-Dokumentstrukturen. Anders als bei einer klassischen XML-DTD wird die Struktur in Form eines XML-Dokuments, d. h. in XML-Syntax, beschrieben. Neben der Definition von Elementen, Attributen und Verarbeitungsanweisungen erlauben XML-Schemata die Formulierung von Bedingungen und Beschränkungen für den Zugriff auf diese.

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125 XML-DSig

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

Die XML Signatur Spezifikation (auch XML-DSig, RFC3275) definiert eine XML Syntax für digitale Signaturen. In ihrer Funktion ähnelt sie dem PKCS#7 Standard, ist aber leichter zu erweitern und auf das Signieren von XML Dokumenten spezialisiert. Sie findet Einsatz in vielen weiterführenden Web-Standards wie etwa SOAP, SAML oder dem deutschen OSCI. Mit XML Signaturen können Daten jeden Typs signiert werden. Dabei kann die XML-Signatur Bestandteil des XML Datenpakets sein (enveloped signature), die Daten können aber auch in die XML-Signatur selbst eingebettet sein (enveloping signature) oder mit einer URL adressiert werden (detached signature). Eine XML Signatur ist immer mindestens einer Ressource zugeordnet, dass heißt ein XML Baum oder beliebige Binärdaten auf die ein XMLLink verweist. Beim XML Baum muss sichergestellt sein, dass es zu keinen Mehrdeutigkeiten kommt. Um dies erreichen zu können, ist eine so genannte Kanonisierung des Inhalts erforderlich. Dabei werden nach Maßgabe des Standards alle Elemente in der Reihenfolge ihres Auftretens aneinander gereiht und alle Attribute alphabetisch geordnet, so dass sich ein längerer UTF-8 String ergibt. Aus diesem wird dann der eigentliche Hashwert für die Signatur gebildet. Da die Signatur eine binäre Zeichenfolge ist, lässt sie sich nicht direkt in ein XML Dokument einbetten. Man codiert die binären Werte im Base64Format [RFC 1521], um so aus ihnen ASCII lesbare Zeichen zu gewinnen. Im Rahmen der Struktur eines XML Dokuments lassen sich Subelemente explizit vom Signieren ausschließen, so auch die Signatur selbst. Umgekehrt lassen sich beliebig viele Referenzen auflisten, die als Gesamtheit zu signieren sind.

Zeitstempel, elektronischer

Zertifikat

Ein Zeitstempel ist eine von einem vertrauenswürdigen Dritten zuverlässig bescheinigte elektronische Angabe von Zeit und Datum. Ein Zeitstempel dient dazu, verlässlich und nachweislich zu belegen, dass digitale Daten eines bestimmten Inhalts zu einem bestimmten Zeitpunkt bei dem Aussteller des Zeitstempels (i. d. R. ein Zertifizierungsdiensteanbieter) vorgelegen haben. Nach § 2 Nr. 6 SigG sind Zertifikate elektronische Bescheinigungen, mit denen Signaturschlüssel einer Person zugeordnet werden und die Identität einer Person bescheinigt wird. Für die Anwendung von Signaturverfahren von besonderer Bedeutung ist die Feststellung, dass „qualifizierte Zertifikate“ nur auf natürliche Personen ausgestellt werden dürfen. Das Zertifikat enthält neben dem öffentlichen Signaturschlüssel insbesondere Angaben zur Person, die von der ausstellenden Instanz zum Zeitpunkt der Zertifikatserstellung geprüft wurden, sowie zum Gültigkeitszeitraum.

Zertifizierungsdiensteanbieter

Ein Zertifizierungsdiensteanbieter ist gemäß § 2 Nr. 8 SigG eine natürliche oder juristische Person, die qualifizierte Zertifikate oder qualifizierte Zeitstempel ausstellt.

Bundesamt für Sicherheit in der Informationstechnik

121

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

14. Quellenverzeichnis

122

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

[ACMPP]

Common Criteria Protection Profile for an ArchiSafe Compliant Middleware for Enabling the Legally compliant Long-Term Preservation of Electronic Documents (ACM_PP), Physikalisch-Technische Bundesanstalt (PTB), jeweils aktuell gültige Fassung

[AIS 20]

BSI, Anwendungshinweise und Interpretationen zum Schema (AIS), Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren, Version 1 siehe unter https://www.bsi.bund.de/cln_174/ContentBSI/Themen/ZertifizierungundAkkreditierun g/ZertifierungnachCCundITSEC/AnwendungshinweiseundInterpretationen/AISCC/ais _cc.html

[AIS 31]

BSI, Anwendungshinweise und Interpretationen zum Schema (AIS), Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren,Version 1 siehe unter https://www.bsi.bund.de/cln_174/ContentBSI/Themen/ZertifizierungundAkkreditierun g/ZertifierungnachCCundITSEC/AnwendungshinweiseundInterpretationen/AISCC/ais _cc.html

[AktG]

Aktiengesetz vom 6. September 1965 (BGBl. I S. 1089), zuletzt geändert durch Artikel 11 des Gesetzes vom 16. Juli 2007 (BGBl. I S. 1330) siehe unter www.gesetze-im-internet.de/bundesrecht/aktg/gesamt.pdf

[ALGCAT]

Geeignete Kryptoalgorithmen zur Erfüllung der Anforderungen nach §17 Abs. 1 bis 3 SigG vom 22. Mai 2001 in Verbindung mit Anlage 1 Abschnitt I Nr. 2 SigV vom 22. November 2001, jeweils aktuell gültige Fassung, siehe http://www.bundesnetzagentur.de/

[ANSIX3.4]

ANSI X3.4 Information Systems – Coded Character Sets – 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII)

[AO]

Abgabenordnung in der Fassung der Bekanntmachung vom 1. Oktober 2002 (BGBl. I S. 3866; 2003 I S. 61), zuletzt geändert durch Artikel 3 des Gesetzes vom 21. Dezember 2007 (BGBl. I S. 3198) siehe unter www.gesetze-im-internet.de/bundesrecht/ao_1977/gesamt.pdf

[ArbGG]

Arbeitsgerichtsgesetz in der Fassung der Bekanntmachung vom 2. Juli 1979 (BGBl. I S. 853, 1036), zuletzt geändert durch Artikel 2 Abs. 2 des Gesetzes vom 16. Mai 2008 (BGBl. I S. 842) siehe unter www.gesetze-im-internet.de/bundesrecht/arbgg/gesamt.pdf

[ArbSchG]

Gesetz über die Durchführung von Maßnahmen des Arbeitsschutzes zur Verbesserung der Sicherheit und des Gesundheitsschutzes der Beschäftigten bei der Arbeit (Arbeitsschutzgesetz – ArbSchG), siehe unter www.gesetze-im-internet.de/bundesrecht/arbschg/gesamt.pdf

[ArbZG]

Arbeitszeitgesetz vom 6. Juni 1994 (BGBl. I S. 1170, 1171), zuletzt geändert durch Artikel 229 der Verordnung vom 31. Oktober 2006 (BGBl. I S. 2407), siehe unter www.gesetze-im-internet.de/bundesrecht/arbzg/gesamt.pdf

[ArchiSig]

A. Rossnagel, P. Schmücker (Hrsg.): Beweiskräftige elektronische Archivierung. Ergebnisse des Forschungsprojektes „ArchiSig – Beweiskräftige und sichere Langzeitarchivierung digital signierter Dokumente“, Economica Verlag, 2006

[ARO 07]

A. Rossnagel, S. Fischer-Dieskau, S. Jandt, M. Knopp: „Langfristige Aufbewahrung elektronischer Dokumente“, Band 17 der Reihe „Der elektronische Rechtsverkehr“, 1. Auflage, Nomos-Verlag, 2007.

Bundesamt für Sicherheit in der Informationstechnik

123

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

[ASN.1]

O. Dubuisson, ASN.1 – Communication between heterogeneous systems, Academic Press, 2001

[AÜG]

Arbeitnehmerüberlassungsgesetz in der Fassung der Bekanntmachung vom 3. Februar 1995 (BGBl. I S. 158), zuletzt geändert durch Artikel 233 der Verordnung vom 31. Oktober 2006 (BGBl. I S. 2407) siehe unter www.gesetze-im-internet.de/bundesrecht/a_g/gesamt.pdf

[BArchG]

Gesetz über die Sicherung und Nutzung von Archivgut des Bundes (Bundesarchivgesetz – BArchG) vom 06.01.1988, zuletzt geändert durch § 13 Abs. 2 G vom 05.09.2005 I 2722, siehe unter http://www.gesetze-iminternet.de/bundesrecht/barchg/gesamt.pdf

[BASE64]

Freed, N, Borenstein, N.: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, section 6.8, Base64 Content-Transfer-Encoding, IETF RFC 2045, November 1996.

[BDSG]

Bundesdatenschutzgesetz, vom 20. Dezember 1990, BGBl I 1990, 2954, 2955; zuletzt geändert durch G. Vom 5.9. 2005, BGBl I 2722; siehe unter http://bundesrecht.juris.de/bundesrecht/bdsg_1990/, 1990

[BetrVG]

Betriebsverfassungsgesetz in der Fassung der Bekanntmachung vom 25. September 2001 (BGBl. I S. 2518), zuletzt geändert durch Artikel 221 der Verordnung vom 31. Oktober 2006 (BGBl. I S. 2407) siehe unter http://bundesrecht.juris.de/bundesrecht/betrvg/gesamt.pdf

[BGB]

Bürgerliches Gesetzbuch in der Fassung der Bekanntmachung vom 2. Januar 2002 (BGBl. I S. 42, 2909; 2003 I S. 738), zuletzt geändert durch Artikel 1 des Gesetzes vom 4. Juli 2008 (BGBl. I S. 1188) siehe unter www.gesetze-im-internet.de/bundesrecht/bgb/gesamt.pdf

[BiostoffVO]

Biostoffverordnung vom 27. Januar 1999 (BGBl. I S. 50), zuletzt geändert durch Artikel 2 der Verordnung vom 6. März 2007 (BGBl. I S. 261) siehe unter http://bundesrecht.juris.de/bundesrecht/biostoffv/gesamt.pdf

[BLESS 05]

Bless, R., et al.: Sichere Netzwerkkommunikation. Grundlagen, Protokolle und Architekturen, Springer Verlag, Berlin Heidelberg, 2005

[BORG 03]

Borghoff, C., et al.: Long-Term Preservation of Digital Documents, Principles and Practices, Springer, 2003

[BSG09]

A. J. Blazic, S. Saljic, T. Gondrom: Extensible Markup Language Evidence Record Syntax, Internet Draft, http://www.ietf.org/internet-drafts/draft-ietf-ltans-xmlers-03.txt

[BT 01]

Bröhl, G. M., Tettenborn, A., Das neue Recht der elektronischen Signaturen, Bundesanzeigerverlag, 2001

[C14N]

Canonical XML, Version 1.0, W3C Recommendation, Mai 2001, siehe unter http://www.w3.org/TR/xml-c14n

[CC]

Common Criteria for Information Technology Security Evaluation (CC), Version 3.1, siehe unter http://www.commoncriteriaportal.org

[Common-PKI]

T7 e.V. und TeleTrusT e.V.: Common PKI Specification, Version 2.0, http://www.common-pki.org/uploads/media/Common-PKI_v2.0.pdf, Januar 2009

[DOL02]

Dollar, C. M., Authentic Electronic Records: Strategies for Long-Term Access, Cohasset Associates , Inc., 2002

[DSSC]

Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC), IETF, Draft-Status, siehe unter http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-02.txt

124

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

[EC14N]

Exclusive XML Canonicalization, Version 1.0, W3C Recommendation, Juli 2002, siehe unter http://www.w3.org/TR/xml-exc-c14n

[eCard-1]

BSI: eCard-API-Framework – Teil 1 – Überblick und übergreifende Definitionen, BSI TR-03112-1, Version 1.0 vom 03.03.2008, siehe https://www.bsi.bund.de/cln_174/ContentBSI/Publikationen/TechnischeRichtlinien /tr03112/index_htm.html BSI, eCard-API-Framework – Teil 2 – eCard-Interface, BSI TR-03112-2 , Version 1.0 vom 03.03.2008; siehe unter

[eCard-2]

https://www.bsi.bund.de/cln_174/ContentBSI/Publikationen/TechnischeRichtlinien/tr0 3112/index_htm.html [eCard-3]

BSI, eCard-API-Framework – Teil 3 – Management-Interface, BSI TR-03112-3 , Version 1.0 vom 03.03.2008, siehe unter https://www.bsi.bund.de/cln_174/ContentBSI/Publikationen/TechnischeRichtlinien/tr0 3112/index_htm.html

[eCard-4]

BSI, eCard-API-Framework – Teil 4 – ISO24727-3-Interface, BSI TR-03112-4 , Version 1.0 vom 03.03.2008, siehe unter https://www.bsi.bund.de/cln_174/ContentBSI/Publikationen/TechnischeRichtlinien/tr0 3112/index_htm.html

[eCard-7]

BSI, eCard-API-Framework – Teil 7 – Protokolle, BSI TR-03112-7 , Version 1.0 vom 03.03.2008, siehe unter https://www.bsi.bund.de/cln_174/ContentBSI/Publikationen/TechnischeRichtlinien/tr0 3112/index_htm.html

[ERSXML]

A. Jerman Blazic, S. Saljic, T. Gondrom, Extensible Markup Language Evidence Record Syntax, draft-ietf-ltans-xmlers-03.txt, http://tools.ietf.org/html/draft-ietf-ltans-xmlers-03, 26.01.2009

[ETSI 101733]

ETSI: CMS Advanced Electronic Signatures (CAdES). ETSI Technical Specification TS 101 733, Version 1.7.4. http://www.etsi.org/ , Juli 2008.

[ETSI 101903]

ETSI: XML Advanced Electronic Signatures (XAdES), ETSI Technical Specification TS 101 903, Version 1.3.2, http://webapp.etsi.org/action/PU/20060307/ts_101903v010302p.pdf , März 2006.

[ETSI-TSP]

TS 101 861 V 1.3.1 Time stamping profile, European Telecommunications Standards Institute (ETSI), Januar 2006, siehe unter http://www.etsi.org

[FC 07]

F. Cohen: FastSOA, Elsevier Inc., 2007

[FGO]

Finanzgerichtsordnung (FGO) in der Fassung der Bekanntmachung vom 28. März 2001 (BGBl. I S. 442, 2262 (2002 I S. 679)), zuletzt geändert durch Artikel 14 des Gesetzes vom 12.Dezember 2007 (BGBl. I S. 2840) siehe unter www.gesetze-im-internet.de/fgo/

[FIPS180-2]

United States of America National Institute for Standards and Technology (NIST), Secure Hash Standard (SHS), Federal Information Processing Standard (FIPS), Publication 180-2, 01.08.2002, siehe unter http://csrc.nist.gov/fips/

[FormAnpG]

Gesetz zur Anpassung der Formvorschriften des Privatrechts und anderer Vorschriften an den modernen Rechtsgeschäftsverkehr, vom 13. Juli 2001, BGBl I, Nr. 35, S. 15421549; siehe unter http://www.dud.de/documents/formvorschriften-10713.pdf

Bundesamt für Sicherheit in der Informationstechnik

125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

[GDPdU]

Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU) (BMF-Schreiben vom 16. Juli 2001 - IV D 2 - S 0316 - 136/01 -) siehe unter www.zdh.de/fileadmin/user_upload/themen/Steuerinfo/BMFSchreiben_16-07-01_GdPDU.pdf

[GenG]

Gesetz betreffend die Erwerbs- und Wirtschaftsgenossenschaften (Genossenschaftsgesetz – GenG) in der Fassung der Bekanntmachung vom 16. Oktober 2006 (BGBl. I S. 2230), zuletzt geändert durch Artikel 2 des Gesetzes vom 3. September 2007 (BGBl. IS. 2178) siehe unter http://bundesrecht.juris.de/bundesrecht/geng/gesamt.pdf

[GGO]

Gemeinsame Geschäftsordnung der Bundesministerien siehe unter http://www.bmi.bund.de/Internet/Content/Common/Anlagen/Broschueren/2007/GGO

[GLAD 07]

Gladney, H. M., Preserving Digital Information, Springer Publ., 2007

[GmbHG]

Gesetz betreffend die Gesellschaften mit beschränkter Haftung in der im Bundesgesetzblatt Teil III, Gliederungsnummer 4123-1, veröffentlichten bereinigten Fassung, zuletzt geändert durch Artikel 4 des Gesetzes vom 19. April 2007 (BGBl. I S.542) siehe unter www.gesetze-im-internet.de/bundesrecht/gmbhg/gesamt.pdf

[GoBS]

Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) Schreiben des Bundesministeriums der Finanzen an die obersten Finanzbehörden der Länder vom November 1995 - IV A 8 - S 0316 - 52/95- BStBl 1995 I S. 738 siehe unter www.bundesfinanzministerium.de/

[GON 07]

Gondrom, T., Evidence Record Syntax in: N. Pohlmann et al.: ISSE/SECURE 2007 Securing Electronic Business Processes: Highlights of the Information Security Solutions Europe/SECURE 2007 Conference, Vieweg + Teubner, 2007, 367 ff.

[GWG]

Gesetz über das Aufspüren von Gewinnen aus schweren Straftaten (Geldwäschegesetz -GwG) vom 25. Oktober 1993 (BGBl. I S. 1770), zuletzt geändert durch Artikel 5 des Gesetzes vom 21. Dezember 2007 (BGBl. I S. 3089) siehe unter www.gesetze-im-internet.de/gwg/

[HGB]

Handelsgesetzbuch, vom 10. Mai 1897, RGBl 1987, 219, zuletzt geändert druch Art. 1 G. v. 3.8.2005 I 2267, siehe unter http://bundesrecht.juris.de/bundesrecht/hgb

[HGrG]

Gesetz über die Grundsätze des Haushaltsrechts des Bundes und der Länder (Haushaltsgrundsätzegesetz - HGrG) vom 19. August 1969 (BGBl. I S. 1273), zuletzt geändert durch Artikel 123 der Verordnung vom 31. Oktober 2006 (BGBl. I S. 2407) siehe unter www.gesetze-im-internet.de/hgrg/

[HK 06]

Hühnlein, D, Korte, U., Grundlagen der elektronischen Signatur, Bundesamt für Sicherheit in der Informationstechnik und Secu Media Verlag, Bonn / Ingelheim, 2006

[HK 06b]

D. Hühnlein und U. Korte: Signaturformate für elektronische Rechnungen, in Horster P. (Hrsg.): Tagungsband „D•A•CH Security“, 2006, IT-Verlag, ISBN 3-00-018166-0, 2006 Seiten 1-14, http://www.ecsec.de/pub/2006_DACH_Signaturformate.pdf

[HORN 04]

Hornung, G., Der zukünftige Einsatz von Chipkarten im deutschen Gesundheitswesen, in: Horster p. (Hrsg.), D·A·CH Security 2004, 226

[HORN 05]

Hornung, G., Di digitale Identität. Rechtsprobleme von Chipkartenausweisen: digitaler Personalausweis, elektronische Gesundheitskarte, Job-Card-Verfahren, Baden-Baden, 2005

126

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

[HUE 04]

Hühnlein, D., Intervall-Qualifizierte Zeitstempel, in: P. Horster (Hrsg), Elektronische Geschäftsprozesse, S. 341, IT-Verlag, 2005, siehe auch.: http://www.secunet.com/download/fachartikel/iq-zeitstempel.pdf

[INHE 1995]

Inhester, M., Rechtliche Konsequenzen des Einsatzes von Bildarchivierungs- und Kommunikationssystemen (PACS), NJW 1995, 685

[ISO-Latin-1]

ISO/IEC 8859-1:1998 Information technology -8-bit single-byte coded graphic character sets, Part 1: Latin alphabet No. 1, siehe unter: http://www.iso.org/

[JArbSchG]

Gesetz zum Schutz der arbeitenden Jugend (Jugendarbeitsschutzgesetz – JarbSchG) vom 12. April 1976 (BGBl. I S. 965), zuletzt geändert durch Artikel 230 der Verordnung vom 31. Oktober 2006 (BGBl. I S. 2407) siehe unter www.gesetze-im-internet.de/bundesrecht/jarbschg/gesamt.pdf

[JKomG]

Gesetz über die Verwendung elektronischer Kommunikationsformen in der Justiz (Justizkommunikationsgesetz – JkomG) vom 22. März 2005 siehe unter www.bmj.gekko.de/files/-/1281/JKomG.pdf

[KAMPFF 97]

Kampffmeyer, U., Rogalla, J, Grundsätze der elektronischen Archivierung. VOI Kompendium Band 3. VOI Verband Organisations- und Informationssysteme e. V., Darmstadt 1997, ISBN 3-932898-03-6.

[KIL 1987]

Kilian, W., Rechtliche Aspekte der digitalen medizinischen Archivierung von Röntgenunterlagen, NJW 1987, 695

[KUSSEL 03]

Kussel, S., Die Digitalisierung der Verwaltungsgerichtsbarkeit, Berlin, 2003

[KWG]

Gesetz über das Kreditwesen (Kreditwesengesetz – KWG) in der Fassung der Bekanntmachung vom 9. September 1998 (BGBl. I S. 2776), zuletzt geändert durch Artikel 2 des Gesetzes vom 21. Dezember 2007 (BGBl. I S. 3089), siehe unter www.gesetze-im-internet.de/kredwg/

[LAZ 01]

Lazinger, S. S., Digital Preservation and Metadata, Greenwood Publishing, 2001

[LTAP]

A. Jerman Blazic, SETCCE, P. Sylvester, EdelWeb, C. Wallace, Cygnacom Solutions: Long-term Archive Protocol (LTAP) – draft-ietf-ltans-ltap-07, siehe unter http://tools.ietf.org/html/draft-ietf-ltans-ltap-07

[MER 1980]

Merkle, R.: Protocols for Public Key Cryptosystems, Proceedings of the 1980 IEEE Symposium on Security and Privacy (Oakland, CA, USA), pages 122-134, April 1980.

[METS]

Metadata Encoding and Transmission Standards, siehe unter http://www.loc.gov/standards/mets/

[Moreq2]

Model Requirements fort he Management of Electronic Records, Update and Extension (Moreq2) CECA-CEE-CEEA, Bruxelles- Luxembourg, 2008 siehe unter http://ec.europa.eu/transparency/archival_policy/moreq

[NachwG]

Gesetz über den Nachweis der für ein Arbeitsverhältnis geltenden wesentlichen Bedingungen (Nachweisgesetz – NachwG) vom 20. Juli 1995 (BGBl. I S. 946), zuletzt geändert durch Artikel 32 des Gesetzes vom 13. Juli 2001 (BGBl. I S. 1542), siehe unter http://bundesrecht.juris.de/nachwg/

[OAIS]

CCSDS 650.0-B-1: Reference Model for an Open Archival Information System (OAIS). Blue Book (Standard). Issue 1. January 2002. siehe unter http://public.ccsds.org/publications/archive/650x0b1.pdf

[OASIS-DSS]

OASIS: Digital Signature Service Core Protocols, Elements, and Bindings, Version 1.0, OASIS Standard, via http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0os.pdf

Bundesamt für Sicherheit in der Informationstechnik

127

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

[OASIS WD2]

Henkel, I., Hühnlein, D.: Profile for comprehensive multi-signature verification reports for OASIS Digital Signature Services Version 1.0, Working Draft (WD2, http://docs.oasis-open.org/dss/v1.0/oasis-dss-profile-for-comprehensive-signatureverification-report-v1.0-os.html,February 2009

[PDF 1.4]

Adobe Systems Inc., PDF – Reference – Third Edition – Adobe Portable Document Format Version 1.4, Addison Wesley, ISBN 0-201-75839-3, siehe unter http://partners.adobe.com/public/developer/en/pdf/PDFReference.pdf, November 2001

[PK-DML]

Prüfkriterien für Dokumentenmanagement-Lösungen, VOI Verband Organisationsund Informationssysteme e.V., Bonn, 2. Auflage 2004

[PKCS#12]

RSA Laboratories. PKCS#12: Personal Information Exchange Syntax Standard, Version 1.0, Juni 1999, siehe unter http://www.rsa.com/

[PKCS#7]

RSA Laboratories. PKCS#7: Cryptographic Message Syntax Standard, Version 1.5, November 1993, siehe unter http://www.rsa.com/

[PTB 05]

Physikalisch-Technische Bundesanstalt, ArchiSafe-Webseite, siehe unter http://www.archisafe.de

[PublG]

Gesetz über die Rechnungslegung von bestimmten Unternehmen und Konzernen (Publizitätsgesetz - PublG) vom 15. August 1969 (BGBl. I S. 1189), zuletzt geändert durch Artikel 7 des Gesetzes vom 10. November 2006 (BGBl. I S. 2553), siehe unter www.gesetze-im-internet.de/publg/

[RegR]

Richtlinie für das Bearbeiten und Verwalten von Schriftgut (Akten und Dokumenten) in Bundesministerien (RegR), siehe unter www.bmi.bund.de

[RFC1521]

Borenstein, N., Freed, N.: IETF RFC 1521 – MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, siehe unter http://www.ietf.org/rfc/rfc1521.txt

[RFC1945]

Berners-Lee, T., Fielding, R., Frystyk, H.: IETF RFC 1945 – Hypertext Transfer Protocol -- HTTP/1.0, siehe unter http://www.ietf.org/rfc/rfc1945.txt

[RFC2119]

S. Bradner: IETF RFC 2119 – Key words for use in RFCs to Indicate Requirement Levels, siehe unter http://www.ietf.org/rfc/rfc2119.txt

[RFC2401]

Kent, S., Atkinson, R.: IETF RFC 2401 – Security Architecture for the Internet Protocol (IPSec), siehe unter http://www.ietf.org/rfc/rfc2401.txt

[RFC2459]

Housley, R., Ford, W.: IETF RFC 2459 – Internet X.509 Public Key Infrastructure Certificate and CRL Profile, siehe unter http://www.ietf.org/rfc/rfc2459.txt

[RFC2560]

Myers, M., Ankney, A., Malpani, A, Galperin, S., Adams, C.: IETF RFC 2560 – X.509 Internet Public Key Infrastructure - Online Certificate Status Protocol – OCSP), siehe unter http://www.ietf.org/rfc/rfc2560.txt

[RFC2616]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, P., Leach, P., Berneres-Lee, T.: IETF RFC 2616 – Hypertext Transfer Protocol -- HTTP/1.1, siehe unter http://www.ietf.org/rfc/rfc2616.txt

[RFC3161]

Adams, C., Cain, P., Pinkas, D., Zuccherrato, R.: IETF RFC 3161 – Internet X.509 Public-Key Infrastructure – Time Stamp Protocol (TSP), siehe unter http://www.ietf.org/rfc/rfc3161.txt

[RFC3275]

Eastlake, D., Reagle, J., Solo, D.: IETF RFC 3275 – (Extensible Markup Language) XML –Signature Syntax and Processing, siehe unter http://www.ietf.org/rfc/rfc3275.txt

128

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

[RFC3280]

Housley, R., Polk, W., Ford, W., Solo, D.: IETF RFC 3280 – Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, siehe unter http://www.ietf.org/rfc/rfc3280.txt

[RFC3281]

S, Farrell, R. Housley: An Internet Attribute Certificate Profile for Authorization, RFC 3281, http://www.ietf.org/rfc/rfc3281.txt April 2002

[RFC3447]

Jonsson, J., Kaliski, B.: IETF RFC 3447 – Public-Key Cryptography Standards (PKCS)#1: RSA Cryptography Specifications Version 2.1, siehe unter http://www.ietf.org/rfc/rfc3447.txt

[RFC3852]

Housley, R.: IETF RFC 3852 – Cryptographic Message Syntax (CMS), siehe unter http://www.ietf.org/rfc/rfc3852.txt

[RFC4346]

T. Dierks, E. Rescorla: IETF RFC 4346 - The Transport Layer Security (TLS) Protocol, Version 1.1, siehe unter http://www.ietf.org/rfc/rfc4346.txt

[RFC4422]

A. Melnikov, K. Zeilenga: IETF RFC 4422 – Simple Authentication and Security Layer (SASL), siehe unter http://www.ietf.org/rfc/rfc4422.txt

[RFC4510]

Zeilenga, K., Ed.: IETF RFC 4510 – Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map, siehe unter http://www.ietf.org/rfc/rfc4510.txt

[RFC4648]

S. Josefsson, SJD: IETF RFC 4510 – The Base16, Base32, and Base64 Data Encodings, siehe unter http://www.ietf.org/rfc/rfc4648.txt

[RFC4810]

Wallace, C., Pordesch, U., Brandner, R.: IETF RFC 4810 – Long-Term Archive Service Requirements, siehe unter http://www.ietf.org/rfc/rfc4810.txt

[RFC4998]

Gondrom, T., Brandner, R., Pordesch, u.: IETF RFC 4998 – Evidence Record Syntax (ERS), siehe unter http://www.ietf.org/rfc/rfc4998.txt

[RFC5019]

A. Deacon, R. Hurst: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High­Volume Environments, RFC 5019, http://www.ietf.org/rfc/rfc5019.txt , September 2007

[RFC5055]

Freeman, T., Housley, R., Malpani, A., Cooper, D., Polk, W.: IETF RFC 5055 – Server-Based Certification Validation Protocol, siehe unter http://www.ietf.org/rfc/rfc5055.txt

[RFC5126]

D. Pinkas, J. Ross, und N. Pope. CMS Advanced Electronic Signatures (CAdES), Request For Comments, RFC 5126, http://www.ietf.org/rfc/rfc5126.txt , Februar 2008.

[RFC5276]

C. Wallace: Using the Server­Based Certificate Validation Protocol (SCVP) to Convey Long­Term Evidence Records, RFC 5276, http://www.ietf.org/rfc/rfc5276.txt, August 2008

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., Polk, W.: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, siehe unter http://www.ietf.org/rfc/rfc5258.txt

[SBJ 1991]

Schmidt-Beck, J. R., Rechtliche Aspekte der EDV-gestützten ärztlichen Dokumentation, NJW 1991, 2335

[SBR 04]

Brumme, S, Gustmann, U, Krebs, F., Erfolgreiche Einführung elektronischer Archive, Deutscher Sparkassen Verlag, Stuttgart, 2004

[SFD 06]

Fischer-Dieskau, S., Das elektronisch signierte Dokument als Mittel zur Beweissicherung, Band 12 der Reihe Der elektronische Rechtsverkehr, 1. Auflage 2006, Nomos-Verlag.

Bundesamt für Sicherheit in der Informationstechnik

129

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

[SGB]

Sozialgesetzbuch (I-X) siehe unter http://www.sozialgesetzbuch-bundessozialhilfegesetz.de/

[SGG]

Sozialgerichtsgesetz (SGG) in der Fassung der Bekanntmachung vom 23. September 1975 (BGBl. I S. 2535), zuletzt geändert durch Artikel 1 des Gesetzes vom 26. März 2008 (BGBl. I S.444) siehe unter www.gesetze-im-internet.de/bundesrecht/sgg/gesamt.pdf

[SigG]

Gesetz über die Rahmenbedingungen für elektronische Signaturen und zur Änderung weiterer Vorschriften (SigG) vom 16.5.2001, BGBl. 2001, Teil I Nr. 22, S. 876 ff., geändert durch Art 1 G v. 4.1.2005 I 2 siehe unter http://www.bundesnetzagentur.de/media/archive/2247.pdf

[SigV]

Verordnung zur elektronischen Signatur (Signaturverordnung – SigV) vom 16.11.2001, BGBl. 2001, Teil I Nr. 59, S. 3075 ff., geändert durch Art 2 G v. 4.1.2005 I 2 siehe unter http://www.bundesnetzagentur.de/media/archive/5264.pdf

[SNIA 08]

SNIA - Information Management – Extensible Access Method (XAM) – Part 1: Architecture, Version 1.0 , Working Draft, April, 2008, siehe unter http://www.snia.org

[sRGB]

Bilingual Multimedia systems and equipment - Colour measurement and management Part 2-1: Colour management - Default RGB colour space - sRGB, siehe unter: http://www.srgb.com/srgb.html bzw. als IEC-Standard: IEC 61966-2-1 – Ed. 1.0 – http://webstore.iec.ch/webstore/webstore.nsf/

[StDAV]

Verordnung über den automatisierten Abruf von Steuerdaten (SteuerdatenAbrufverordnung – StDAV) vom 13. Oktober 2005 (BGBl. I S. 3021) siehe unter www.gesetze-im-internet.de/bundesrecht/stdav/gesamt.pdf

[StGB]

Strafgesetzbuch (StGB) in der Fassung der Bekanntmachung vom 13. November 1998 (BGBl. I S. 3322), zuletzt geändert durch Artikel 3 des Gesetzes vom 11. März 2008 (BGBl. I S. 306) siehe unter http://bundesrecht.juris.de/stgb/index.html

[TAP 03]

Wallace, C., Chokani, S., Trusted Archive Protocol (TAP), Internet Draft , draft-ietfpkix-tap-00.txt, February 2003, siehe unter http://tools.ietf.org/id/draft-ietf-pkix-tap00.txt

[TIFF6]

Adobe Systems Inc., TIFF – Revision 6.0 vom 3. Juni 1992, siehe unter http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

[TR 02102]

BSI TR-02102: Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Version 1.0, 20.06.2008

[TR-VELS-E]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-E Konkretisierung der Schnittstellen auf Basis des eCard-API-Frameworks

[TR-VELS-F]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-F Formate und Protokolle

[TR-VELS-M.1]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-M.1 ArchiSafe Modul

[TR-VELS-M.2]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-M.2 Krypto-Modul

[TR-VELS-M.3]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-M.3 ArchiSig-Modul

[TR-VELS-M.4]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-M.4 Langzeitspeicher

130

Bundesamt für Sicherheit in der Informationstechnik

BSI TR 03125

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

[TR-VELS-S.1]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-S.1 Schnittstelle ArchiSafe-Modul / Krypto-Modul

[TR-VELS-S.2]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-S.2 Schnittstelle ArchiSig-Modul / Langzeitspeicher

[TR-VELS-S.3]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-S.3 Schnittstelle Krypto-Modul / ArchiSig-Modul

[TR-VELS-S.4]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-S.4 Schnittstelle XML-Adapter / ArchiSafe-Modul

[TR-VELS-S.5]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-S.5 Schnittstelle ArchiSafe-Modul / Langzeitspeicher

[TR-VELS-S.6]

TR Vertrauenswürdige elektronische Langzeitspeicherung: Anlage TR-VELS-S.6 Schnittstelle ArchiSafe-Modul / ArchiSig-Modul

[TR-VELS]

TR Vertrauenswürdige elektronische Langzeitspeicherung, Hauptdokument

[TzBfG]

Gesetz über Teilzeitarbeit und befristete Arbeitsverträge (Teilzeit- und Befristungsgesetz – TzBfG) vom 21. Dezember 2000 (BGBl. I S. 1966), zuletzt geändert durch Artikel 1 des Gesetzes vom 19. April 2007 (BGBl. I S. 538) siehe unter http://bundesrecht.juris.de/bundesrecht/tzbfg/gesamt.pdf

[UNICODE]

Unicode Standard, Unicode Consortium (ISBN 0-201-61633-5), siehe unter http://unicode.org/versions/Unicode4.1.0/ This is functionally equivalent to ISO/IEC 10646:2003 – Information technology – Universal Multiple-Octet Coded Character Set (UCS). siehe unter http://www.iso.org/

[UStG]

Umsatzsteuergesetz (UStG) in der Fassung der Bekanntmachung vom 21. Februar 2005 (BGBl. I S. 386), zuletzt geändert durch Artikel 8 des Gesetzes vom 20. Dezember 2007 (BGBl. I S. 3150) siehe unter www.gesetze-im-internet.de/bundesrecht/ustg_1980/gesamt.pdf

[VERS]

Victorian Electronic Records Strategy, siehe unter http://www.prov.vic.gov.au/vers

[VOI 05]

Dokumenten-Management. Vom Archiv zum Enterprise-Content-Management, VOI – Verband Organisation und Informationssysteme e.V., Bonn, 2005

[VwGO]

Verwaltungsgerichtsordnung (VwGO) in der Fassung der Bekanntmachung vom 19. März 1991 (BGBl. I S. 686), zuletzt geändert durch § 62 Abs. 11 des Gesetzes vom 17. Juni 2008 (BGBl. I S. 1010) siehe unter www.gesetze-im-internet.de/bundesrecht/vwgo/gesamt.pdf

[VwVfG]

Verwaltungsverfahrensgesetz (VwVfG) in der Fassung der Bekanntmachung vom 23. Januar 2003 (BGBl. I S. 102), geändert durch Artikel 4 Abs. 8 des Gesetzes vom 5. Mai 2004 (BGBl. IS. 718), siehe unter www.gesetze-im-internet.de/bundesrecht/vwvfg/gesamt.pdf

[WpHG]

Gesetz über den Wertpapierhandel(Wertpapierhandelsgesetz - WpHG) in der Fassung der Bekanntmachung vom 9. September 1998 (BGBl. I S. 2708), zuletzt geändert durch Artikel 11 des Gesetzes vom 21. Dezember 2007 (BGBl. I S. 3198) siehe unter www.gesetze-im-internet.de/bundesrecht/wphg/gesamt.pdf

[X.408]

ITU-T, ITU-T Recommendation X.408, Message Handling Systems : Encoded Information Type Conversion Rules, 1988

Bundesamt für Sicherheit in der Informationstechnik

131

Vertrauenswürdige elektronische Langzeitspeicherung (VELS)

BSI TR 03125

[X.509]

ITU-T, ITU-T Recommendation X.509 (2005) - ISO/IEC 9594-8:2005, Information Technology – Open Systems Interconnection – The Directory: Public-key and attribute certicate frameworks http://www.itu.int/rec/T-REC-X.509-200508-I/en , August 2005.

[X.680]

ITU-T, ITU-T Recommendation X.680(2002) – ISO/IEC 8824-1:2002. Information Technology – Abstract Syntax One (ASN.1): Specification of Basic Notation, 2002

[XAdES]

J. C. Cruellas, G. Karlinger, D. Pinkas, J. Ross, XML Advanced Eelectronic Signatures (XAdES), http://www.w3.org/TR/2003/NOTE-XAdES-20030220/, Februar 2003

[XFDU]

Nikhinson, S., Reich, L.: XML formatted Data Unit (XFDU), Structure and construction rules, CCSDS 661.0-R-1, January 2007, siehe unter http://sindbad.gsfc.nasa.gov/xfdu

[XML Name]

W3c, Namespaces in XML 1.0 (Second Edition), W3C Recommendation 16 August 2006 siehe unter http://www.w3.org/TR/REC-xml-names/

[XML]

Bray, T., et al.: Extensible Markup Language (XML) 1.1, second edition, W3C Recommendation, 16.August 2006, siehe unter http://www.w3.org/TR/xml

[XMLDSIG]

Bartel, M., et al.: XML Signature Syntax and Processing (Second Edition), W3C Recommendation 10 June 2008 siehe unter http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/

[XMLENC]

Imamura, T. et al.: XML Encryption Syntax and Processing W3C Recommendation 10 December 2002 siehe unter http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

[XSD]

Fallside, D. C., et al.: (Ed.) XML Schema, W3C Recommendation, 28. October 2004 siehe unter http://www.w3.org/TR/xmlschema-0/ (Primer) siehe unter http://www.w3.org/TR/xmlschema-1/ (Structures) siehe unter http://www.w3.org/TR/xmlschema-2/ (Datatypes)

[WSDL]

W3C Recommendation: Web Services Description Language (WSDL) Version 1.1, via http://www.w3.org/TR/wsdl Zivilprozessordnung siehe unter www.gesetze-im-internet.de/zpo

[ZPO]

132

Bundesamt für Sicherheit in der Informationstechnik