Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die...

of 29 /29
RTrust PKI Raiffeisen Informatik RTrust PKI Certificate Practice Statement RootCA PolicyCA IssuingCA Wien/NÖ/Bgld/Stmk

Embed Size (px)

Transcript of Certificate Practice Statementcert.r-itservices.at · Das Certificate Practice Statement und die...

  • RTrust PKI

    Raiffeisen Informatik

    RTrust PKI

    Certificate Practice Statement

    RootCA

    PolicyCA

    IssuingCA Wien/NÖ/Bgld/Stmk

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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.

  • 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)

  • 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

  • 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.

  • 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.

  • 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.

    http://cert.r-itservices.at/RTrusthttp://ocsp.r-itservices.at/ocsp/

  • 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.

  • 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.

  • 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.

  • 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.

  • 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

  • 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.

  • 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.

  • 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.

  • 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

  • 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.

  • 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.

  • 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.

  • 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

  • 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.

  • 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.

  • 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.

  • 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.