Download - Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

Transcript
Page 1: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust PKI

Certificate Practice Statement

RootCA

PolicyCA

IssuingCA Wien/NÖ/Bgld/Stmk

Page 2: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite ii

Dokumentenverwaltung Dokument-Historie Version Status Datum Verantwortlicher Änderungen

1.0 Gültig 12.09.2012 6340 Web Services Erstellung vom Dokument

1.1 Gültig 10.03.2017 7530 Security Applications Anpassung der Zuständigkeiten

1.2 Gültig 14.12.2017 7110 Security Applications Anpassung der Zuständigkeiten, Typos

Page 3: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite iii

Inhaltsverzeichnis 1 Einleitung ............................................................................................................................. 7

1.1 Überblick ................................................................................................................... 7

1.1.1 Verwendete Abkürzungen ............................................................................. 7

1.2 Identifikation des Dokuments .................................................................................. 7

Object Identifier .......................................................................................................... 7

1.3 Infrastruktur und Anwendungsbereich ................................................................... 8

1.3.1 CA ................................................................................................................ 8 1.3.2 RA ................................................................................................................ 8 1.3.3 Zertifikatsinhaber und End-Entität ................................................................. 8 1.3.4 Anwendungsbereich ..................................................................................... 8

1.4 Kontakt ...................................................................................................................... 9

2 Rahmenvorschriften .......................................................................................................... 10

2.1 Verpflichtungen ...................................................................................................... 10

2.1.1 Verpflichtung der CA ................................................................................... 10 2.1.2 Verpflichtung der RA ................................................................................... 10 2.1.3 Verpflichtung des Zertifikatsinhabers .......................................................... 10 2.1.4 Verpflichtungen der Zertifikatsnutzer ........................................................... 11 2.1.5 Verpflichtungen der Verzeichnisdienste ...................................................... 11

2.2 Haftung .................................................................................................................... 11

2.3 Finanzielle Verantwortung ..................................................................................... 11

2.3.1 Schadenersatz ............................................................................................ 11 2.3.2 Treuhänderische Beziehungen ................................................................... 11 2.3.3 Administrative Prozesse ............................................................................. 11

2.4 Rechtliche Auslegung ............................................................................................ 11

2.4.1 Zugrunde liegende gesetzliche Bestimmungen ........................................... 11 2.4.2 Trennbarkeit der Bestimmungen, Fortbestehen von Ansprüchen, Fusion,

Kündigung .................................................................................................. 12

2.5 Veröffentlichungen und Verzeichnisdienste ........................................................ 12

2.5.1 Veröffentlichungen von Informationen der CA ............................................. 12 2.5.2 Aktualisierungen ......................................................................................... 12 2.5.3 Zugriff ......................................................................................................... 12 2.5.4 Verzeichnisdienst ........................................................................................ 12

2.6 Überprüfung – Audit ............................................................................................... 13

2.6.1 Frequenz des Audits ................................................................................... 13 2.6.2 Identität/Qualifikation des Auditors .............................................................. 13 2.6.3 Beziehung des Auditors zum Unternehmen ................................................ 13 2.6.4 Umfang des Audits ..................................................................................... 13 2.6.5 Maßnahmen nach Feststellung von Mängeln .............................................. 13 2.6.6 Veröffentlichung der Ergebnisse des Audits ................................................ 13

2.7 Datenschutz ............................................................................................................ 13

2.8 Geistiges Eigentumsrecht ..................................................................................... 13

3 Identifizierung und Authentifizierung ............................................................................... 14

Page 4: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite iv

3.1 Erstregistrierung .................................................................................................... 14

3.1.1 Namenstypen.............................................................................................. 14 3.1.2 Aussagekraft von Namen ............................................................................ 14 3.1.3 Interpretationsregeln für Namensformen ..................................................... 14 3.1.4 Eindeutigkeit von Namen ............................................................................ 14 3.1.5 Verfahren bei Streitigkeiten über einen Namen ........................................... 14 3.1.6 Erkennung, Authentifizierung und Funktion von Warenzeichen .................. 14 3.1.7 Überprüfungsverfahren des Besitzes eines privaten Schlüssels ................. 15 3.1.8 Authentifizierung von natürlichen Personen ................................................ 15

3.2 Routinemässige Erneuerung / Rezertifizierung.................................................... 15

3.3 Erneuerung nach Widerruf .................................................................................... 15

3.4 Widerrufsantrag (revocation request) ................................................................... 15

4 Ablauforganisation ............................................................................................................ 16

4.1 Zertifikatsantrag ..................................................................................................... 16

4.2 Zertifikatsausstellung ............................................................................................ 16

4.3 Zertifikatsakzeptanz ............................................................................................... 16

4.4 Zertifikatsrevokation und –suspendierung ........................................................... 16

4.4.1 Gründe für einen Widerruf ........................................................................... 16 4.4.2 Berechtigte Stellen, die einen Widerruf veranlassen können ....................... 16 4.4.3 Ablauf eines Widerrufs ................................................................................ 16 4.4.4 Veröffentlichungsfrequenz der CRL ............................................................ 17 4.4.5 Anforderungen an Kontrolle der CRL .......................................................... 17 4.4.6 Verfügbarkeit von Online-Widerrufs/Status-Überprüfungsverfahren ............ 17 4.4.7 Anforderungen an Online-Widerrufs/Status-Überprüfungsverfahren ........... 17 4.4.8 Andere verfügbare Formen der Revokationsbekanntmachung ................... 17 4.4.9 Anforderungen an Kontrolle der anderen Formen der

Revokationsbekanntmachung ..................................................................... 17 4.4.10 Kompromittierung von privaten Schlüsseln ................................................. 17

4.5 Sicherheitsüberwachung & Protokollierung ........................................................ 17

4.5.1 Protokollierte Ereignisse ............................................................................. 17 4.5.2 Frequenz der Protokollanalyse ................................................................... 18 4.5.3 Aufbewahrungszeitraum für Protokolldaten ................................................. 18 4.5.4 Schutz der Protokolldaten ........................................................................... 18 4.5.5 Backup der Protokolldaten .......................................................................... 18 4.5.6 Protokollierungssystem (intern/extern) ........................................................ 18 4.5.7 Anforderungen für die Zeitstempelung von protokollierten Daten ................ 18 4.5.8 Benachrichtigung bei sicherheitsrelevanten Ereignissen ............................. 18 4.5.9 Schwachstellenbewertung .......................................................................... 18 4.5.10 Abrufprozeduren für archivierte Daten ........................................................ 18

4.6 Schlüsselwechsel ................................................................................................... 18

4.7 Kompromittierung und Wiederherstellung ........................................................... 19

4.7.1 Beschädigungen von Hard-, Software und/oder Daten ............................... 19 4.7.2 Widerruf des CA-Zertifikats ......................................................................... 19 4.7.3 Kompromittierung des privaten Schlüssels der CA ..................................... 19 4.7.4 Betrieb nach einer Katastrophe ................................................................... 19

4.8 Einstellung des Betriebs der CA ........................................................................... 19

5 Infrastrukturelle, organisatorische und personelle Sicherheitsmaßnahmen ................ 20

5.1 Physische Sicherheitsmaßnahmen ....................................................................... 20

5.1.1 Lage und Räumlichkeiten ........................................................................... 20

Page 5: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite v

5.1.2 Zutrittskontrollen ......................................................................................... 20 5.1.3 Stromversorgung und Klimatisierung .......................................................... 20 5.1.4 Schutz von Wasserschäden ........................................................................ 20 5.1.5 Abwehr von Feuerschäden ......................................................................... 20 5.1.6 Aufbewahrung von Medien ......................................................................... 20 5.1.7 Abfallentsorgung ......................................................................................... 20 5.1.8 Externes Backup ......................................................................................... 20

5.2 Organisatorische Sicherheitsmaßnahmen ........................................................... 21

5.2.1 Rollen ......................................................................................................... 21 5.2.2 Anzahl notwendiger Personen bei Tätigkeiten an der CA ........................... 22 5.2.3 Identifizierung und Authentifizierung der Rollen .......................................... 22

5.3 Personelle Maßnahmen.......................................................................................... 23

5.3.1 Anforderungen an Vergangenheit, Qualifikation, Erfahrung und Integrität ... 23 5.3.2 Anforderungen an den Arbeitsvertrag ......................................................... 23

6 Technische Sicherheitsmaßnahmen ................................................................................ 24

6.1 Schlüsselerzeugung und Installation .................................................................... 24

6.1.1 Schlüsselerzeugung.................................................................................... 24 6.1.2 Auslieferung des privaten Schlüssels an den Zertifikatsinhaber .................. 24 6.1.3 Auslieferung der öffentlichen Schlüssels ..................................................... 24 6.1.4 Auslieferung des öffentlichen Schlüssels der CA an die Nutzer .................. 24 6.1.5 Schlüssellänge ............................................................................................ 24 6.1.6 Parameter der öffentlichen Schlüssel .......................................................... 24 6.1.7 Qualität der Parameter ................................................................................ 24 6.1.8 Schlüsselerzeugung in Software oder in Hardware ..................................... 24 6.1.9 Verwendungszweck der Schlüssel und Beschränkungen ........................... 24

6.2 Schutz der privaten Schlüssel ............................................................................... 25

6.2.1 Standards des Schlüssel erzeugenden kryptographischen Moduls ............. 25 6.2.2 Schlüsselteilung (key-sharing Algorithmus) ................................................. 25 6.2.3 Schlüsselhinterlegung ................................................................................. 25 6.2.4 Backup von privaten Schlüsseln ................................................................. 25 6.2.5 Archivierung privater Schlüssel ................................................................... 25 6.2.6 Speicherung privater Schlüssel in ein Kryptomodul..................................... 25 6.2.7 De-/Aktivierung privater Schlüssel .............................................................. 25 6.2.8 Vernichtung privater Schlüssel .................................................................... 26

6.3 Weitere Aspekte des Schlüsselmanagements ..................................................... 26

6.3.1 Archivierung öffentlicher Schlüssel ............................................................. 26 6.3.2 Gültigkeit der Schlüsselpaare ..................................................................... 26

6.4 Technische Maßnahmen während Dauerbetrieb der CA ..................................... 26

6.5 Sicherheitsmaßnahmen für Netzwerk ................................................................... 26

6.6 Technische Maßnahmen für kryptographische Module ...................................... 26

7 Profile für Zertifikate und Revokationslisten (CRLs) ....................................................... 27

7.1 Profil der Zertifikate ................................................................................................ 27

7.1.1 Version ....................................................................................................... 27 7.1.2 Zertifikatserweiterungen .............................................................................. 27 7.1.3 OID der Algorithmen ................................................................................... 27 7.1.4 Format der Namen ...................................................................................... 27 7.1.5 Wird in den jeweiligen Certificate Policies beschrieben.Auflagen an die

Namen ........................................................................................................ 27 7.1.6 OID der Certificate Policy ............................................................................ 27 7.1.7 Verwendung von Policy Constraints Erweiterungen .................................... 27

Page 6: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite vi

7.1.8 Syntax und Semantik des Policy Qualifiers ................................................. 27 7.1.9 Verarbeitungssemanik für kritische Certificate Policy Erweiterungen .......... 27

7.2 Profil der CRL ......................................................................................................... 27

7.2.1 Version ....................................................................................................... 27 7.2.2 CRL- und CRL-Eintrags-Erweiterungen ...................................................... 28

8 Verwaltung der Richtlinien ................................................................................................ 29

8.1 Ablauf von Änderungen ......................................................................................... 29

8.2 Veröffentlichungs- und Benachrichtungsrichtlinien ............................................ 29

8.3 Genehmigungsverfahren der CPS ........................................................................ 29

Page 7: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 7

1 Einleitung

1.1 Überblick

Das vorliegende Certificate Practice Statement enthält die Zertifizierungsrichtlinien der Zertifizierungsinstanz für die Vergabe und Verwaltung von Maschinenzertifikaten der Raiffeisen Informatik GmbH. Die CA ist Teil der betriebenen Public-Key-Infrastruktur, deren Aufgabe die Bereitstellung von Zertifikaten und Schlüsselpaaren ist. Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die von der CA ausgestellt werden, und geben damit das Sicherheitsniveau der PKI wieder.

1.1.1 Verwendete Abkürzungen

CPS Certificate Practice Statement CP Certificate Policy CA Certification Authority – Zertifizierungsinstanz – Zertifizierungsstelle RA Registration Authority – Registrierungsinstanz – Registrierungsstelle PKI Public Key Infrastruktur

1.2 Identifikation des Dokuments

Titel, Version, History und Status dieser Richtlinie finden sich am Beginn dieses Dokuments. Object Identifier Raiffeisen Informatik verfügt über den OID-Raum: 1.3.6.1.4.1.8697. Darin wird das vorliegende Dokument wie folgt festgelegt: 1.3.6.1.4.1.8697.4.4.1.1.1.1 Schema für OID-Vergabe: 1.3.6.1.4.1.8697.4.(PKI-Nr).(CA-Level).(CA-Nr).(Policy-Type).(Version)

(PKI-Nr) Nummer der CA-Hierarchie (CA-Level) Nummer der Hierarchie-Ebene (CA-Nr) Nummer der CA in dieser Ebene (Typ) Art des PKI-Elements:

Practice Statement: 1

Application Policy: 2 (Version) Laufende Nummer oder Versionsnummer

CP/CPS: Versionnummer

Application Policy: Nummer oder Version der jeweiligen Policy.

Page 8: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 8

1.3 Infrastruktur und Anwendungsbereich

1.3.1 CA

Raiffeisen Informatik betreibt die CAs der RTrust PKI: Root-CA, Policy-CA, Issuing-CA. Diese Reihenfolge stellt auch die Zertifkatskette dar.

1.3.2 RA

1.3.2.1 Manuell ausgestellte Maschinenzertifikate

Als Registrierungsstelle der Issuing-CAs für Maschinenzertifikate fungiert jene Organisationseinheit, die einerseits die betroffene Hardware nach technischer Überprüfung dem Betrieb zuführt und sich andererseits von der Rechtmäßigkeit des Antrags für die Maschine vergewissert. Für Clients (Notebooks) ist das die RI-S, die ein Gerät nur nach erfolgtem Anforderungsworkflow – durch einen Antragsteller und einen Genehmiger – mit der Software betankt, die letztlich eine Auslieferung eines Zertifikats auf die betroffene Maschine bewirkt. Die Anforderungen für konkrete Anwendungen für Maschinenzertifikate werden in den einzelnen Certificate Policies beschrieben.

1.3.2.2 Automatisch ausgestellte Maschinenzertifikate

Die Zertifikate werden von den Issuing-CAs ausgestellt und die Genehmigung erfolgt aufgrund der entsprechenden Zuordnung im Active Directory.

1.3.2.3 Smartcard Zertifikate

Als Registrierungsstelle der Issuing-CAs für Smartcard-Zertifikate fungiert das Cardmanagementservice. Die genaue Beschreibung findet sich in der Certificate Policy „CP für R-Trust Benutzerzertifikate v1.0.doc“

1.3.3 Zertifikatsinhaber und End-Entität

Die Zertifikatsinhaber sind firmeninterne Organisationseinheiten, repräsentiert durch die organisatorische Rolle des Verantwortlichen und der zugehörigen natürlichen Person, welche die Bereitstellung und den Betrieb von betroffenen Maschinen rechtmäßig angefordert haben. Antragsteller eines Maschinen-Zertifikates im technischen Sinn ist die Maschine selbst (Account der Maschine). Diese Maschinen können als die End-Entitäten bezeichnet werden (subject of the certificate). Der Zertifikatsinhaber für Smartcard-Zertifikate ist der Smartcard-Benutzer.

1.3.4 Anwendungsbereich

Dieses CPS gilt für nachfolgende Klassen von Zertifikaten, die von der Raiffeisen Informatik GmbH PKI verwaltet werden:

Clientzertifikate (Notebooks und andere mobile Geräte)

Serverzertifikate

Domain-Controller-Zertifikate

Zertifikate für Smartcards

Zertifikate für WLAN/Teleworker Zugang

Zertifikate für Telefonie-Geräte

Zertifikate für Remote System Access (RSA)

Page 9: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 9

1.4 Kontakt

Betreiber der PKI ist Raiffeisen Informatik GmbH A-1020 Wien Lilienbrunngasse 7-9 Tel. +43 1 99 3 99 – 0

Page 10: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 10

2 Rahmenvorschriften

2.1 Verpflichtungen

2.1.1 Verpflichtung der CA

Die RTrust-CAs verpflichten sich, nach den Richtlinien dieses CPS sowie der jeweiligen CP zu arbeiten. Insbesondere wird dem Schutz der privaten Schlüssel der RTrust-CAs absolute Priorität gegeben. Die Issuing-CAs stellen Zertifikate für Maschinen, Services und Benutzer aus. Dafür vertraut sie der RA und lehnt unautorisierte Anträge ab. Die RTrust-CAs verpflichten sich, Widerrufsanträge schnellstmöglich zu bearbeiten und entsprechende CRLs auszustellen. Der Betreiber der RTrust-CAs verpflichtet sich, qualifiziertes Personal zu beschäftigen, dessen Zuverlässigkeit geprüft wurde. Die Sicherheitsrichtlinien der Raiffeisen Informatik werden eingehalten. Im Speziellen verpflichtet sich die CA zu folgenden Aufgaben:

Annahme von Zertifikatsanträgen (certification requests) von befugter Stelle

Ausstellung von Zertifikaten anhand autorisierter Anträge

Annahmen von Widerrufsanträgen (revocation requests) entsprechend der in diesem Dokument beschriebenen Vorgaben entgegen

Ausstellung von Widerrufslisten (Certificate Revocation List – CRL) gemäß authentischer Widerrufsanträge und veröffentlicht diese CRLs

Erstellung von revisionssicherer Aufzeichnung über die beschriebenen Schritte sowie Tätigkeiten zur Administration und Betrieb der CA

Vorgehensweise anhand einer gültigen CPS

Aktualisierung des CPS bei Änderung der Einflussfaktoren (z.B. technisches Umfeld, Zertifikatstypen/-Politiken, etc.)

Nennung eines Verantwortlichen für die CA und Veröffentlichung des Kontakts innerhalb des Wirkungsbereichs der CA

Der private Schlüssel der CA wird ausschließlich zum Signieren der Zertifikate der Zertifikatsinhaber und zum Signieren der zugehörigen Widerrufslisten verwendet.

Betrieb eines OCSP-Responders für die Issuing-CAs

2.1.2 Verpflichtung der RA

Die RA verpflichtet sich, nach den Richtlinien dieses CPS sowie der jeweiligen CP zu arbeiten, die Identifizierung der End-Entitäten zuverlässig durchzuführen und sämtliche Schritte durchzuführen, damit ein Zertifikatsantrag einen nachvollziehbaren Authentifizierungsprozedere durchläuft. Die RA verpflichtet sich für Ausstellung der Benutzerzertifikate die CP der R-Trust Benutzerzertifikate zu berücksichtigen. Die RA verpflichtet sich weiters, qualifiziertes Personal zu beschäftigen, dessen Zuverlässigkeit geprüft wurde. Die Sicherheitsrichtlinien der Raiffeisen Informatik werden eingehalten. Externe RAs werden auf die Einhaltung der vorliegenden Richtlinien verpflichtet.

2.1.3 Verpflichtung des Zertifikatsinhabers

Die Zertifikatsinhaber verpflichten sich mit einer unterfertigten Übernahmebestätigung den sorgsamen Umgang mit den Zertifikaten, sowie die Belehrung bzgl. Wiederruf verstanden zu haben und die Zertifikate nur für die produktiven und genehmigten Zwecke der dafür vorgesehenen Maschine zu verwenden.

Page 11: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 11

Sollte der private Schlüssel abhanden kommt, gestohlen oder möglicherweise kompromittiert werden, oder sollten sich die Angaben des Zertifikates ändern so ist unverzüglich ein Zertifikatswiderruf zu beantragen (revocation requests).

2.1.4 Verpflichtungen der Zertifikatsnutzer

Die Zertifikatsnutzer, bzw. jene, die jenes technische Umfeld implementieren und betreiben, das sich die Zertifikate zunutze macht (Server, Applikationen, Authentisierungsmechanismen, etc.), verpflichten sich, vor der Akzeptanz eines Zertifikats zu prüfen, ob

das Zertifikat gültig ist (dabei ist die entsprechende CRL zu prüfen) und ob

das zweckgemäß eingesetzt ist (für erlaubte Applikationen und dgl.)

2.1.5 Verpflichtungen der Verzeichnisdienste

Der Verzeichnisdienst veröffentlicht in regelmäßigen Abständen Listen mit

ausgestellten Zertifikaten und

widerrufenen Zertifikaten.

2.2 Haftung

Raiffeisen Informatik GmbH haftet gemäß seiner Allgemeinen Geschäftsbedingungen. Für die Ausstellung eines Zertifikates, die auf falschen Daten einer externen RA beruht, haftet die externe RA gemäß ihren Allgemeinen Geschäftsbedingungen und nicht Raiffeisen Informatik GmbH.

2.3 Finanzielle Verantwortung

2.3.1 Schadenersatz

Keine Bestimmungen, soweit es den internen Gebrauch der PKI betrifft. Treten im Zusammenhang mit der internen PKI Schäden mit Außenwirkung auf, gelten die Bestimmungen der Allgemeinen Geschäftsbedingungen der Raiffeisen Informatik GmbH, sofern keine spezifischen Vereinbarungen bestehen.

2.3.2 Treuhänderische Beziehungen

Durch die Benutzung eines ausgestellten Zertifikates entsteht keine treuhänderische Beziehung zwischen Raiffeisen Informatik GmbH und einem Zertifikatsinhaber. Der Zertifikatsinhaber ist für die Benutzung seines Zertifikates allein verantwortlich, die Raiffeisen Informatik GmbH übernimmt keinerlei Verantwortung für Rechtsgeschäfte, die mit Einsatz eines Zertifikates getätigt werden.

2.3.3 Administrative Prozesse

Keine Bestimmungen

2.4 Rechtliche Auslegung

2.4.1 Zugrunde liegende gesetzliche Bestimmungen

Der Betrieb der PKI, dieses CPS und die CPs unterliegen dem Recht der Republik Österreich. Raiffeisen Informatik GmbH stellt keine qualifizierten Zertifikate im Sinne des österreichischen Signaturgesetzes aus.

Page 12: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 12

2.4.2 Trennbarkeit der Bestimmungen, Fortbestehen von Ansprüchen, Fusion, Kündigung

Keine Bestimmungen

2.5 Veröffentlichungen und Verzeichnisdienste

2.5.1 Veröffentlichungen von Informationen der CA

Raiffeisen Informatik GmbH publiziert die folgenden Informationen mittels geeigneter Mittel online:

CDP: http://cert.r-itservices.at/RTrust

AIA: http://cert.r-itservices.at/RTrust

OCSP: http://ocsp.r-itservices.at/ocsp/

LDAP: ldap:///CN=RTrustIssuingCA02,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=rbgat,DC=net?cACertificate?base?objectClass=certificationAuthority

Zertifikate der CAs

Fingerabdrücke der Zertifikate der CAs

Certificate Practice Statement

Certificate Policies

2.5.2 Aktualisierungen

Aktualisierte Informationen werden umgehend publiziert. Dies gilt insbesondere für die CRLs: Gültigkeitsdauer des Zertifikats der Root-CA: siehe 6.3.2 Gültigkeitsdauer der Basis-CRL (Root-CA): 1 Jahr Gültigkeitsdauer des Zertifikats der Policy-CA: siehe 6.3.2 Gültigkeitsdauer der Basis-CRL (Policy-CA): 1 Jahr Gültigkeitsdauer des Zertifikats der Issuing-CA: siehe 6.3.2 Gültigkeitsdauer der Basis-CRL (Issuing-CA): 3 Tage Gültigkeitsdauer der Delta-CRL (Issuing-CA): 30 Minuten

2.5.3 Zugriff

Alle Anwender der PKI haben lesenden Zugriff auf obengenannte Informationen. Autorisierte Mitarbeiter der Raiffeisen Informatik GmbH haben die Möglichkeit, Änderungen an den Dokumenten und die Administration der Verzeichnisse für Zertifikate sowie der Widerrufslisten vorzunehmen.

2.5.4 Verzeichnisdienst

Der Verzeichnisdienst der PKI der Raiffeisen Informatik GmbH, der die herausgegebenen Zertifikate und die CRL zur Verfügung stellt, ist unter oben angegebener Adresse erreichbar.

Page 13: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 13

2.6 Überprüfung – Audit

2.6.1 Frequenz des Audits

Interne und externe Audits des gesamten Unternehmens finden regelmäßig statt. Ihre Zyklen hängen von der auditierenden Instanz und der Detailtiefe des Audits ab.

2.6.2 Identität/Qualifikation des Auditors

Die Audits werden im Rahmen einer internen Revision durch den Revisor des Trustcenters durchgeführt.

2.6.3 Beziehung des Auditors zum Unternehmen

Interne Auditoren führen ihre Aufgaben im Rahmen der Unternehmensrevision durch und bekleiden keine weiteren Funktionen im Unternehmen. Externe Auditoren sind einerseits von Raiffeisen Informatik GmbH beauftragt, um Sicherheits- und Qualitätsprüfungen vorzunehmen, andererseits unterzieht sich das Unternehmen verpflichtenden Audits von Wirtschaftsprüfern und akkreditierten Zertifizierungsinstanzen (für Sicherheit und Qualität). Für den Betrieb der PKI sind zudem eigene Rollen für Monitoring und Auditierung geschaffen.

2.6.4 Umfang des Audits

Es werden alle Instanzen, Rollen, Prozesse, Personen, Protokolle und Log-Dateien der PKI stichprobenartig überprüft. Soweit wie möglich, werden Log-Auswertungen und Soll-/Ist-Vergleiche automatisiert durchgeführt.

2.6.5 Maßnahmen nach Feststellung von Mängeln

Werden Mängel festgestellt, werden umgehend geeignete Maßnahmen zu deren Beseitigung eingeleitet.

2.6.6 Veröffentlichung der Ergebnisse des Audits

Die Ergebnisse des Audits werden nicht veröffentlicht.

2.7 Datenschutz

Das Unternehmen verpflichtet sich generell zur Einhaltung des Österreichischen Datenschutzgesetzes (siehe Sicherheitspolitik und -Handbuch der Raiffeisen Informatik GmbH). Im vorliegenden Fall ist dies insofern von geringer Relevanz, als die PKI Maschinenzertifikate verwaltet und dementsprechend keine personenbezogenen Daten verarbeitet.

2.8 Geistiges Eigentumsrecht

Urheber- und Eigentumsrechte an CPS und CP, sowie an Zertifikaten und Schlüsseln – insbesondere der Root-CA, liegen bei Raiffeisen Informatik. Eine Ausnahme bilden nur jene Zertifikate, deren Inhaber außerhalb des Unternehmens ist.

Page 14: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 14

3 Identifizierung und Authentifizierung

3.1 Erstregistrierung

3.1.1 Namenstypen

Die Anforderungen für konkrete Anwendungen für Maschinenzertifikate werden in den einzelnen Certificate Policies beschrieben. Name der Issuing-CA

Distinguished Name Suffix Common Name (CN) der CA

RTrustRootCA01 O=Raiffeisen Informatik RTrustRootCA01

RTrustPolicyCA01 O=Raiffeisen Informatik RTrustPolicyCA01

RTrustIssuingCA01 O=Raiffeisen Informatik RTrustIssuingCA01

RTrustIssuingCA02 O=Raiffeisen Informatik RTrustIssuingCA02

RTrustIssuingCA03 O=Raiffeisen Informatik RTrustIssuingCA03

RTustIssuingCASTMK01 O=RRZ Steiermark RTrustIssuingCASTMK01

RTustIssuingCASTMK01 O=RRZ Steiermark RTrustIssuingCASTMK01

„xx“ im Namen der Issuing-CA ist eine fortlaufende Nummer, somit ist die Eindeutigkeit

gewährt.

3.1.2 Aussagekraft von Namen

Die Anforderungen für konkrete Anwendungen für Maschinenzertifikate werden in den einzelnen Certificate Policies beschrieben.

3.1.3 Interpretationsregeln für Namensformen

Die Anforderungen für konkrete Anwendungen für Maschinenzertifikate werden in den einzelnen Certificate Policies beschrieben.

3.1.4 Eindeutigkeit von Namen

Die Anforderungen für konkrete Anwendungen für Maschinenzertifikate werden in den einzelnen Certificate Policies beschrieben.

3.1.5 Verfahren bei Streitigkeiten über einen Namen

Da es sich um Maschinenzertifikate handelt, kann eine Nameskollision leicht umgangen werden. Sollten dennoch für zwei Geräte die gleichen Namenswünsche eingebracht werden, entscheidet die CA über das Vorrecht. In der Regel wird dem zuerst eingebrachten Antrag der Distinguished Name zugesprochen.

3.1.6 Erkennung, Authentifizierung und Funktion von Warenzeichen

Eine Überprüfung durch die CA findet nicht statt. Der Antragsteller hat dafür Sorge zu tragen, dass durch seinen Antrag keine Markenrechte, Warenzeichen usw. verletzt werden. Pseudonyme oder Namen, die geltendes Recht verletzen, sind nicht zulässig. Ein auf einen unzulässigen Namen ausgestelltes Zertifikat wird sofort nach bekannt werden gesperrt. Spezielles wird in der jeweiligen Certificate Policy geregelt.

Page 15: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 15

3.1.7 Überprüfungsverfahren des Besitzes eines privaten Schlüssels

Die CA empfängt den Request für ein Zertifikat signiert mit dem privaten Schlüssel der antragstellenden Entität. Mit dem mitgeschickten public key wird der Request entschlüsselt und dadurch authentifiziert.

3.1.8 Authentifizierung von natürlichen Personen

Da die PKI Maschinenzertifikate verwaltet ist eine Authentifizierung von natürlichen Personen nur in dem eingeschränkten Rahmen vonnöten, als sie als Antragsteller für Geräte in ihrem Verantwortungsbereich in einem Anforderungsworkflow die Rechtmäßigkeit ihrer Anforderung genehmigen lassen müssen.

3.2 Routinemässige Erneuerung / Rezertifizierung

Nach Ablauf von 50% der Gültigkeitsdauer des CA-Zertifikats ist eine Erneuerung des CA-Zertifikats geplant. Es sei denn technische Anforderungen machen dies zu einem früheren Zeitpunkt notwendig.

3.3 Erneuerung nach Widerruf

Nachdem ein Zertifikat widerrufen wurde, ist es nicht möglich ein neues Zertifikat mit dem gleichen Schlüsselpaar auszustellen. In diesem Fall muss ein neues Zertifikat mit einem neuen Schlüsselpaar beantragt werden.

3.4 Widerrufsantrag (revocation request)

Diese Reglung ist in der jeweiligen Certificate Policy festgelegt.

Page 16: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 16

4 Ablauforganisation

4.1 Zertifikatsantrag

Die Anforderungen werden in den einzelnen Certificate Policies beschrieben

4.2 Zertifikatsausstellung

Diese Reglung ist in der jeweiligen Certificate Policy festgelegt.

4.3 Zertifikatsakzeptanz

Diese Reglung ist in der jeweiligen Certificate Policy festgelegt.

4.4 Zertifikatsrevokation und –suspendierung

4.4.1 Gründe für einen Widerruf

Zertifikate können aus folgenden Gründen widerrufen werden:

Zertifikat enthält Angaben, die nicht oder nicht mehr korrekt sind

privater Schlüssel wurde verloren, ist kompromittiert (hierfür reicht ein begründeter Verdacht, bspw. der Zugriff eines Unbefugten) oder ist aus anderen Gründen nicht mehr verwendbar (Defekt des Schlüsselmediums, etc.)

Zertifikatnehmer verliert Berechtigungsgrundlage (siehe 1.3.3)

Zertifikatnehmer hält dessen Certificate Policy nicht ein

Raiffeisen Informatik hält das Certificate Practice Statement oder die Certificate Policies nicht ein

Das Zertifikat wird nicht mehr benötigt

Ermessen des Betreibers der PKI bzw. des PKI-Boards

Wunsch des Zertifikatsinhabers

4.4.2 Berechtigte Stellen, die einen Widerruf veranlassen können

Diese Reglung ist in der jeweiligen Certificate Policy festgelegt. Ein Widerruf eines Zertifikats kann veranlasst werden durch:

Zertifikatsinhaber

RA

Betreiber der PKI

Der Widerrufsantrag wird geprüft und (technisch) durchgeführt vom:

PKI-Operator der CA

4.4.3 Ablauf eines Widerrufs

Diese Reglung ist in der jeweiligen Certificate Policy festgelegt. Der Antrag auf Widerruf wird vom Zertifikatsinhaber unter Angaben von Gründen bei der CA eingebracht. Dies kann telefonisch erfolgen, muss jedoch in jedem Fall schriftlich, bzw. in den Systemen dokumentiert werden.

Page 17: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 17

Der PKI Operator prüft die Authentizität des Antrags und führt im positivem Falle den Widerruf durch. Die CRL wird aktualisiert.

4.4.4 Veröffentlichungsfrequenz der CRL

Die CRL wird aktualisiert, wenn ein Zertifikat widerrufen wird, spätestens jedoch gemäß der Gültigkeitsdauer laut 2.6.2

4.4.5 Anforderungen an Kontrolle der CRL

Es liegt in der Verantwortung der Entität, die ein von der Raiffeisen Informatik ausgestelltes Zertifikat benutzen will, dieses Zertifikat gegen die aktuelle CRL zu verifizieren. Kann eine Überprüfung des Zertifikats gegen eine aktuelle CRL nicht durchgeführt werden, ist eine Verwendung des Zertifikats nicht gestattet.

4.4.6 Verfügbarkeit von Online-Widerrufs/Status-Überprüfungsverfahren

Ein OCSP-Responder wird für die Issuing-CAs bereitgestellt, welcher seine Informationen aus den CRLs bezieht.

4.4.7 Anforderungen an Online-Widerrufs/Status-Überprüfungsverfahren

Es wird ein OCSP-Responder konform RFC 2560 zur Verfügung gestellt.

4.4.8 Andere verfügbare Formen der Revokationsbekanntmachung

Keine Bestimmungen.

4.4.9 Anforderungen an Kontrolle der anderen Formen der Revokationsbekanntmachung

Keine Bestimmungen.

4.4.10 Kompromittierung von privaten Schlüsseln

Bei einer möglichen Kompromittierung des privaten Schlüssels, ist das entsprechende Zertifikat unverzüglich zu widerrufen.

4.5 Sicherheitsüberwachung & Protokollierung

4.5.1 Protokollierte Ereignisse

Sicherheitsrelevante Ereignisse werden protokolliert. Dazu zählen systemrelevante Ereignisse:

Wartungen an Systemkomponenten (Hard- und Software der Issuing-CA) samt Änderungen der Konfiguration.

In- und Außerbetriebnahme der CA (Re-/Bootvorgänge der Hardware)

Fehlgeschlagene Login-Versuche

Aktivitäten der Benutzerverwaltung (Anlegen von Benutzern, Rechtevergabe, etc.)

PKI relevante Ereignisse

Zertifikatsanträge

Zertifikatsauslieferung

Zertifikatswiderrufe

Zertifikatsverlängerungen

Schlüsselwechsel und –erneuerungen

Page 18: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 18

4.5.2 Frequenz der Protokollanalyse

Reguläre Überprüfungen der Protokolldaten finden regelmäßig statt. Bei Verdacht auf außergewöhnliche Vorkommnisse werden außertourliche Überprüfungen vorgenommen.

4.5.3 Aufbewahrungszeitraum für Protokolldaten

Die Aufbewahrungsdauer für PKI-relevante Ereignisse beträgt 7 Jahre, oder mindestens solange, wie der korrespondierende Gültigkeitszeitrahmen des den Protokolleintrag betreffenden Objektes ist (z.B. Zertifikatsantrag, -auslieferung, etc.). Die Aufbewahrungsdauer für systemrelevante Ereignisse richtet sich nach der betrieblichen Notwendigkeit.

4.5.4 Schutz der Protokolldaten

Nur berechtigte Benutzer haben Zugriff auf die Protokolldaten, siehe Rollendefinitionen. Die Aufbewahrung der Backups in räumlicher Trennung ist von essentieller Bedeutung!

4.5.5 Backup der Protokolldaten

Die Protokolldaten werden zusammen mit den anderen relevanten Daten der CA regelmäßig einem Backup unterzogen.

4.5.6 Protokollierungssystem (intern/extern)

Die Protokollierung wird mittels interner Systeme an den Standorten durchgeführt.

4.5.7 Anforderungen für die Zeitstempelung von protokollierten Daten

Erfasste Protokolldaten und Ereignisse werden mit Zeitangaben versehen, welche in erster Linie auf der Systemzeit beruhen. Alle Systeme im Rechenzentrum synchronisieren ihre Systemzeit gemäß eines zentralen Zeitservers.

4.5.8 Benachrichtigung bei sicherheitsrelevanten Ereignissen

Werden sicherheitsrelevante Ereignisse erkannt, werden diese den Security Auditoren (siehe Rollendefinitionen) umgehend gemeldet.

4.5.9 Schwachstellenbewertung

Eine Schwachstellenbewertung wird vom Betreiber der CA selbst und von den internen Revisoren im Zuge von Audits durchgeführt.

4.5.10 Abrufprozeduren für archivierte Daten

Archivierte Daten können von berechtigten Benutzern beim Betreiber der CA (PKI Administrator) beauskunftet werden.

4.6 Schlüsselwechsel

Die Gültigkeit der CA-Zertifikate sind in 6.3.2 festgelegt. Das CA-Zertifikat wird jeweils zur halben Gültigkeitsdauer mit dem gleichen Schlüssel erneuert, um eine Ausnutzung der vollen erlaubten Gültigkeitsdauer für End-Entitäten zu ermöglichen.

Page 19: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 19

4.7 Kompromittierung und Wiederherstellung

4.7.1 Beschädigungen von Hard-, Software und/oder Daten

Für den Fall einer Beschädigung von Hard-, Software und/oder Daten stehen sowohl Ersatzhardware zu Verfügung als auch System- und Datenbackup (Full Backup). Die mögliche Ausfallzeit der CAs wird durch Maßnahmen in der VMWare Infrastruktur minimiert. Es erfolgt eine Wiederherstellung der Software und der Daten aus dem Backup laut Betriebshandbuch. Der Vorfall wird analysiert um Verbesserungspotential zu erkennen und entsprechende Maßnahmen einzuleiten. Werden sicherheitsrelevante Ursachen aufgedeckt (Mutwilligkeit) erfolgt eine Ahndung gemäß der Sicherheitspolitik der Raiffeisen Informatik. Abschließend wird eine erneute Schwachstellenbewertung durchgeführt.

4.7.2 Widerruf des CA-Zertifikats

Muss das CA-Zertifikat widerrufen werden, werden in Folge alle von der CA ausgestellten Zertifikate widerrufen. Mit einem neuen Zertifikat für die CA werden auch neue Schlüssel generiert.

4.7.3 Kompromittierung des privaten Schlüssels der CA

Bei einer Kompromittierung des privaten Schlüssels der CA, bzw. bei einem dementsprechenden begründeten Verdacht, wird deren Zertifikat und alle an End-Entitäten ausgegebenen Zertifikate umgehend widerrufen (siehe 4.8.2).

4.7.4 Betrieb nach einer Katastrophe

Nach einer Katastrophe wird versucht, den Betrieb ehestmöglich wieder aufzunehmen (siehe 4.8.1). Die Endnutzer werden geeignet informiert.

4.8 Einstellung des Betriebs der CA

Die Einstellung des Betriebs der CA kann nur vom PKI-Board oder vom Betreiber der CA im Falle der Issuing CAs beschlossen werden. Wird eine solche Entscheidung getroffen, sind alle Maßnahmen im Vorfeld zu planen, umzusetzen und zu kommunizieren, dass ein Betrieb ohne Zertifikate technisch möglich wird. Alle ausgestellten Zertifikate werden widerrufen und alle relevanten Daten (CRL, Zertifikate, etc.) werden gesichert und archiviert. Die CRL muss über einen angemessenen Zeitrahmen auch weiterhin zu Verfügung stehen. Der CRL-Service wird außer Betrieb genommen, wenn das letzte von dieser CA ausgegebene Zertifikat abgelaufen ist.

Page 20: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 20

5 Infrastrukturelle, organisatorische und personelle Sicherheitsmaßnahmen

5.1 Physische Sicherheitsmaßnahmen

5.1.1 Lage und Räumlichkeiten

Die PKI wird ist an den Standorten der Raiffeisen Informatik untergebracht. Kritische Komponenten werden über diese Standorte verteilt; diese räumliche Trennung sorgt zusätzlich für Schutz gegen Ausfälle. Die Räumlichkeiten des Rechenzentrums können nur von berechtigten Administratoren betreten werden. Ein Sicherheitszonenkonzept sorgt für eine Abgrenzung von anderen Bereichen innerhalb des Standorts.

5.1.2 Zutrittskontrollen

Für den Zutritt sind Berechtigungen erforderlich, die in Form kodierter Schlüssel (Token bzw. Dienstausweis-Card) an jeden Mitarbeiter ausgegeben werden. Dieses elektronische Schlüsselsystem wird von der zentralen Stelle aus gemanagt, die auf schriftliche Anforderung berechtigte Schlüssel vergibt und ebenso wieder sperren kann. Sicherheitszonen mit hohem Schutzbedarf sind auch von Firmenangehörigen nur mit besonderen Berechtigungen zu erreichen, die nur nach Bedarf an ausgewählte Mitarbeiter vergeben werden.

5.1.3 Stromversorgung und Klimatisierung

Es existiert eine doppelte Anbindung der Stromversorgung an die Energielieferanten sowie eine redundante USV-Anlage für eine Batterieversorgung. Weiters starten wenige Sekunden nach Ausfall der Netzenergie automatisch der ebenfalls redundant ausgelegte Dieselgenerator und übernimmt die komplette Versorgung der Geräte und das Laden der Batterien. Die Klimatisierung ist über Kühltürme und Kühlgeräte realisiert, ist redundant aufgebaut und verfügt über eine Ausfallsinfrastruktur mit Eisspeicher.

5.1.4 Schutz von Wasserschäden

Die Räumlichkeiten haben einen doppelten Boden und sind zudem – je nach Standort – oberhalb des Erdgeschosses angelegt.

5.1.5 Abwehr von Feuerschäden

Es sind Anlagen zur Brandfrühesterkennung (erkennt Rauchentwicklung vor Feuerausbruch) im Einsatz. Die Brandmeldeanlage meldet direkt an Feuerwehr über TUS Leitung, zusätzlich an Portier und Technik. Eine Trigon-Gaslöschanlage für bekämpft Brände der Brandklasse A bis C. Eine Wassermeldeanlage ist an die Zentrale Leitstelle (ZLT) angebunden.

5.1.6 Aufbewahrung von Medien

Ist durch die örtlich getrennten Standorte der Rechenzentren gegeben.

5.1.7 Abfallentsorgung

Sicherheitskritischen Unterlagen und Datenträger werden sicher physisch vernichtet, bevor sie entsorgt werden.

5.1.8 Externes Backup

Eine externe Sicherung ist durch die örtlich getrennten Standorte der Rechenzentren gegeben.

Page 21: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 21

5.2 Organisatorische Sicherheitsmaßnahmen

5.2.1 Rollen

Zu Ausübung der PKI-bezogenen Aufgaben sind Rollen formuliert, die den Betrieb der PKI aus operativer als auch aus sicherheitstechnischer Sicht gewähren.

5.2.1.1 Security Analyst

Ein Security Analyst führt die Überprüfung der IT-Infrastruktur in Bezug auf Sicherheit und Compliance durch.

5.2.1.2 Chief Security Officer

Der CSO/SO, mit anderen Worten: die Stabsstelle ISM, ist Mitglied im PKI Board (siehe unten). Am HSM besitzt der CSO/SO die Rolle HSM Administrator. Fallweise kann der CSO/SO auch in der „operativen“ Rolle des Security Auditor auftreten, wenn er dies als erforderlich erachtet.

5.2.1.3 PKI Trustee – HSM & Template Manager

Die Gruppe hat die Berechtigung die laufende Administration und Überwachung des HSM durchzuführen. Der PKI Trustee HSM & Template Manager hat zudem die Oberaufsicht auf das HSM. Am HSM besitzt diese Gruppe die Rollen Appliance Administrator, Partition Owner, Token Administrator. Weiters haben sie ein Subset der Aufgaben von PKI Services AD Publishers: sie sind verantwortlich für die Erstellung und Modifikation von Zertifikatsvorlagen. Templates legen Eigenschaften von Zertifikaten fest, die zukünftig von Issuing-CAs ausgegeben werden können (z.B.: Gültigkeitsdauer)

Implementierung: Universelle Gruppe mit delegierten Berechtigungen auf Certificate Templates im AD. Personen/Gruppe: Security Applications

5.2.1.4 PKI Trustee – Auto-Enrollment Manager

Auto-Enrollment-Manager können über Gruppenrichtlinien (in den Windows-Domänen, in denen sich die Maschinen-Accounts befinden) steuern, für welche Maschinen Auto-Enrollment möglicht ist. Implementierung: Change-Rechte auf Group-Policy-Objekten Personen/Gruppe: Server Windows

5.2.1.5 CA-Bereitstellung

Personen aus der CA-Bereitstellung haben die Aufgabe, die Infrastruktur und benötigten Systeme zu installieren, zu konfigurieren und in Betrieb zu nehmen. Die CA-Bereitstellung verfügt über lokale Admin-Rechte auf der CA-Maschine und Schreibrechte auf den PKI Services Containern im AD. Die Rechte können temporär eingeschränkt werden, um nach erfolgter Übergabe der laufenden Systeme an die Betriebsmannschaft die Zugriffsberechtigungen auf die CA zu minimieren. Für Issuing-CAs außerhalb der Raiffeisen Informatik (aber innerhalb des Raiffeisensektors) werden die Berechtigungen über Verschachtelung realisiert: Die Gruppe CA-Bereitstellung hat Rechte im AD, Bundesländergruppen sind Mitglieder dieser Gruppe. Personen/Gruppe: Security Applications

Page 22: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 22

5.2.1.6 PKI-Administrator

Jede CA-Maschine verfügt über einen lokalen Administrator des Betriebssystems (CA Manager). Er ist ein Systemadministrator und für das tägliche Management des Systems aus betrieblicher Sicht verantwortlich. Dies umfasst die Überwachung, Backups und andere Arbeiten der Systempflege welche keinen direkten Zusammenhang zu PKI Funktionalitäten haben, bzw. hat privilegierten Zugriff zu den administrativen Funktionen welche keine Freigabe durch einen Trustee erfordern. Auf der Maschine der Root-CA hat der PKI-Administrator alle Rechte über das Betriebssystem. Alle kritischen Tätigkeiten des PKI-Administrators – insbesondere Aktionen der Benutzer-/Gruppenverwaltung und der Vergabe von Berechtigungen – werden zentral protokolliert und bleiben nachvollziehbar. Personen/Gruppe: Security Applications

5.2.1.7 PKI-Operator

Er ist der Zertifikats-Manager innerhalb der CA-Applikation. Die Aufgabe des PKI-Operators ist das Ausstellen, Erneuern und der Widerruf von Zertifikaten. Personen/Gruppe Issuing-CA für Zertifikate: Security Applications

5.2.1.8 Registration Authority (RA)

siehe 1.3.2

5.2.1.9 End-Entity und Requester

siehe 1.3.3

5.2.1.10 PKI Board

Das PKI-Board ist oberstes Entscheidungsgremium und Träger der PKI. Es entscheidet in letzter Instanz über alle geschäftsrelevanten Vorgänge in Bezug auf die PKI. Gegeben durch die zentrale und strategische Funktion einer PKI werden die Aufgaben des PKI-Boards je nach Belang in einem der Raiffeisen-übergreifenden Gremien wahrgenommen. Schnittstelle zur Raiffeisen Informatik bildet die Stabsstelle ISM.

5.2.2 Anzahl notwendiger Personen bei Tätigkeiten an der CA

Für Issuing-CAs ist kein strenges Vieraugen-Prinzip implementiert, für administrative Tätigkeiten auf der CA ist nur eine Person nötig.

5.2.3 Identifizierung und Authentifizierung der Rollen

Rollen werden über Windows-Benutzergruppen realisiert. Die oben definierten Rollen werden, sofern technisch möglich, über (zentral verwaltete) Gruppen im Active Directory realisiert. Die Vergabe von Rechten im Active Directory erfolgt über Berechtigung dieser Gruppen im Active Directory, die Vergaben von Rechten auf der CA erfolgt über die Verschachtelung dieser Gruppen in lokale Gruppen bzw. Berechtigung der zentralen Gruppen auf der lokalen CA-Konfiguration.

Page 23: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 23

5.3 Personelle Maßnahmen

5.3.1 Anforderungen an Vergangenheit, Qualifikation, Erfahrung und Integrität

Es gelten die üblichen Bestimmungen der Raiffeisen Informatik GmbH Personalentwicklung. Die bei Raiffeisen Informatik definierten Prozesse für Personalentwicklung, die entsprechende Organisationseinheit Personalentwicklung sowie die Linienorganisation stellen die Vertrauenswürdigkeit und Kompetenz der Mitarbeiter im Unternehmen sicher. Dazu zählen u.a.:

Überprüfung der Angaben über die Vergangenheit

Anforderung an die Schulung

Frequenz und Ablauf von Weiterbildung

Frequenz und Ablauf von Arbeitsplatzrotation

Sanktionen bei unerlaubten Handlungen

5.3.2 Anforderungen an den Arbeitsvertrag

Es gelten die normalen Dienstverträge und alle darüberhinausgehenden Betriebsvereinbarungen der Raiffeisen Informatik.

Page 24: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 24

6 Technische Sicherheitsmaßnahmen

6.1 Schlüsselerzeugung und Installation

6.1.1 Schlüsselerzeugung

Die Issuing-CA erzeugt das Schlüsselpaar und stellt den Request an die Root-CA. Diese empfängt den Request für ein Zertifikat signiert mit dem privaten Schlüssel der antragstellenden Issuing.CA. Mit dem mitgeschickten public key wird der Request entschlüsselt und dadurch authentifiziert.

6.1.2 Auslieferung des privaten Schlüssels an den Zertifikatsinhaber

Dies ist in der jeweiligen Certificate Policy (unter 4.2) festgelegt.

6.1.3 Auslieferung der öffentlichen Schlüssels

Das Schlüsselpaar wird lokal auf der Clientmaschine (Maschinenzertifikat) bzw. im Crypto-Chip der Smartcard erzeugt. Nur der öffentliche Schlüssel wird zur Zertifizierung an die CA gesendet. Zusätzlich wird der öffentliche Schlüssel als Bestandteil des Teilnehmerzertifikats im Zertifikatsverzeichnis veröffentlicht.

6.1.4 Auslieferung des öffentlichen Schlüssels der CA an die Nutzer

Die öffentlichen Schlüssel der CAs werden über die oben genannten Publikationsadressen im Internet zum Abruf bereitgestellt und intern über einen LDAP-URL (Issuing CA) zur Verfügung gestellt.

6.1.5 Schlüssellänge

Die Schlüssellänge wird mit 4096bit festgelegt, um Komptabilität mit möglichst vielen Anwendungen zu gewährleisten (speziell: Router-Zertifikate, VPN u.ä.)

6.1.6 Parameter der öffentlichen Schlüssel

Hash-Algorithmus: SHA-256 Cryptographic Service Provider: Microsoft Strong Cryptographic Provider Schlüssel-Speicher: im Profil der Maschine (auf der Festplatte), entsprechend dem CryptoAPI-Modell und zusätzlich im HSM

6.1.7 Qualität der Parameter

Die Sicherheit der bei der Schlüsselerzeugung verwendeten Parameter wird laufend mit State-of-the-Art-Empfehlungen verglichen.

6.1.8 Schlüsselerzeugung in Software oder in Hardware

CA-Schlüssel werden vom HSM erzeugt und in der entsprechenden Partition am HSM gespeichert. Entsprechend dem Sicherheitsmodell des HSM hat der jeweilige CA-Rechner die Berechtigung kryptographische Operationen des HSM anzustoßen.

6.1.9 Verwendungszweck der Schlüssel und Beschränkungen

Der Verwendungszweck von CA-Schlüsseln (Key Usage) ist beschränkt auf: Digitale Signatur, Zertifikatssignatur, Offline Signieren der Zertifikatssperrliste, Signieren der Zertifikatssperrliste.

Page 25: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 25

6.2 Schutz der privaten Schlüssel

6.2.1 Standards des Schlüssel erzeugenden kryptographischen Moduls

Private Schlüssel werden vom HSM (HSM-spezifischer Cryptographic Service) nach RSA erzeugt.

Für End-Entitäten-Schlüssel gilt der in der Zertifikatsvorlage festgelegte CSP (Hardware oder Software), siehe das entsprechende CP

6.2.2 Schlüsselteilung (key-sharing Algorithmus)

Die Schlüssel der Issuing-CA und der End-Entitäten werden nicht geteilt.

6.2.3 Schlüsselhinterlegung

Der private Schlüssel der CA ist nicht Teil des Backups des HSMs. Für End-Entitäten-Schlüssel gelten die Einstellungen in der Zertifikatsvorlage (Exportierbar / nicht exportierbar).

6.2.4 Backup von privaten Schlüsseln

Private Schlüssel von Client-Maschinen werden als Teil eines System-State- oder Full-Backups gesichert.1 Ein separates Backup des CA-Schlüssel ist technisch möglich, aber nicht vorgesehen.

6.2.5 Archivierung privater Schlüssel

Private Schlüssel von CAs werden nicht in der CA-Datenbank archiviert (siehe unten – Clients), allerdings bleiben frühere Schlüssel im Profil der Maschine erhalten und werden im persönlichen Speicher als "archiviert" gekennzeichnet. Im Gegensatz zur Archivierung von End-Entitäten-Zertifikaten sind die Schlüssel aber nicht durch Recovery-Agent-Zertifikate verschlüsselt.

End-Entitäten-Schlüssel können je nach Einstellungen im Template in der CA-Datenbank archiviert werden, wenn zuvor Key Recovery Agents definiert wurden. KRAs stellen eine eigene Rolle dar: Sie erhalten ein KRA-Zertifikat, mit dessen Public Key End-Entitäten-Zertifikate verschlüsselt und dann in der CA-Datenbank abgelegt werden. KRAs haben ansonsten keine speziellen Berechtigung auf CAs oder anderen Servern.

6.2.6 Speicherung privater Schlüssel in ein Kryptomodul

Private Schlüssel von CAs werden Hardware-mäßig gespeichert.

6.2.7 De-/Aktivierung privater Schlüssel

Private Schlüssels einer Windows-Maschine (inkl. CA) brauchen bzw. können nicht "aktiviert" / "deaktiviert" werden. Ob eine kryptographische Operation ausgeführt werden kann, hängt davon ab, ob die betreffende Applikation den Widerrufsstatus des (eigenen) Zertifikates prüft. Der CA-Service lässt sich nicht starten und somit der eigene Schlüssel nicht verwenden, wenn ein CA-Zertifikat widerrufen wurde.

1 Abhängig von der Version des Betriebssystems; siehe KB2603469

Page 26: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 26

6.2.8 Vernichtung privater Schlüssel

Private Schlüssel von CAs können aus dem Speicher des HSM dauerhaft gelöscht werden. Eine Vernichtung in diesem Sinne ist aber im Routine-Betrieb nicht vorgesehen.

6.3 Weitere Aspekte des Schlüsselmanagements

6.3.1 Archivierung öffentlicher Schlüssel

Öffentliche Schlüssel von CAs werden (als Teil des Zertifikates) gemeinsam mit dem privaten Schlüssel im HSM archiviert und zusätzlich im lokalen Speicher der Maschine.

6.3.2 Gültigkeit der Schlüsselpaare

Gültigkeitsdauer des Zertifikats der Root-CA: 40 Jahre Gültigkeitsdauer des Zertifikats der Policy-CA: 20 Jahre Gültigkeitsdauer des Zertifikats der Issuing-CAs: 10 Jahre

6.4 Technische Maßnahmen während Dauerbetrieb der CA

Alle Angaben zum Betrieb der PKI sind im Hera-Betriebshandbuch zu finden, das bei der Gruppe Security Applications aufliegt.

6.5 Sicherheitsmaßnahmen für Netzwerk

Es gelten die Bestimmungen der Raiffeisen Informatik GmbH Netzwerksicherheitspolitik und der daraus abgeleiteten Dokumente und Richtlinien.

6.6 Technische Maßnahmen für kryptographische Module

Die kryptographischen Module sind redundant ausgelegt.

Page 27: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 27

7 Profile für Zertifikate und Revokationslisten (CRLs)

7.1 Profil der Zertifikate

7.1.1 Version

Die Zertifikate entsprechen dem X.509v3-Standard.

7.1.2 Zertifikatserweiterungen

Wird in den jeweiligen Certificate Policies beschrieben.

7.1.3 OID der Algorithmen

Es werden folgende Algorithmen verwendet: Kryptographie-Algorithmus: rsaEncryption 1.2.840.113549.1.1.1 Hash-Algorithmus: sha256WithRSAEncryption 1.2.840.113549.1.1.11

7.1.4 Format der Namen

7.1.5 Wird in den jeweiligen Certificate Policies beschrieben.Auflagen an die Namen

Außer der in 7.1.4 erwähnten Regeln gibt es folgende: Auflagen für die Namen. Wird ein Zertifikat zur Authentifizierung einer Maschine verwendet, muss der Subject Alternative Name den DNS-Namen der Maschine enthalten.

7.1.6 OID der Certificate Policy

Für jede Zertifikatsklasse gibt es eine eigene Certificate Policy mit einem eigenen OID.

7.1.7 Verwendung von Policy Constraints Erweiterungen

Keine Bestimmungen - Derzeit keine Policy Constraints.

7.1.8 Syntax und Semantik des Policy Qualifiers

Keine Bestimmungen - Derzeit keine Policy Constraints.

7.1.9 Verarbeitungssemanik für kritische Certificate Policy Erweiterungen

Keine Bestimmungen - Derzeit keine kritischen Erweiterungen

7.2 Profil der CRL

7.2.1 Version

CRLs entsprechen dem X.509 CRLv2-Standard

Auf den Issuing-CAs werden Basis-und Delta-CRLs publiziert.

Page 28: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 28

7.2.2 CRL- und CRL-Eintrags-Erweiterungen

Basis-CRL

Authority Key Identifyer

CA Version

Next CRL Publish: Nächste automatische Publikation (früher: Next Update)

Freshest CRL: Pfad zur Location der Delta-CRLs

Published CRL Locations: Speicherort im LDAP-Verzeichnis

Delta-CRL

Authority Key Identifyer

CA Version

CRL Number: Minimal benötigte Version der Basis-CRL

Next CRL Publish: Nächste automatische Publikation (früher als Next Update)

Published CRL Locations: Speicherort im LDAP-Verzeichnis

Delta CRL Indicator: zeigt an, dass es sich um eine Delta-CRL handelt.

Page 29: Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die Certificate Policies regeln die Vergabepraxis und den Einsatz von Zertifikaten, die

RTrust PKI

Raiffeisen Informatik

RTrust CPS

©2017 Raiffeisen Informatik GmbH Seite 29

8 Verwaltung der Richtlinien

8.1 Ablauf von Änderungen

Änderungen an diesem CPS können von allen beschrieben Rollen durchgeführt werden. Die Änderungen sind im Anschluss mit dem PKI Administrator abzustimmen. Nach der Freigabe durch den PKI-Administrator kann das neue CPS mit neuer Versionsnummer veröffentlicht werden.

8.2 Veröffentlichungs- und Benachrichtungsrichtlinien

Nach der Freigabe wird das CPS unter der im Punkt 2.6.1 beschriebenen URL zur Verfügung gestellt und ist dann für alle Zertifikatsnutzer einsehbar.

8.3 Genehmigungsverfahren der CPS

Siehe Prüfung/Freigabe des Dokuments.