Leitfaden zur Rolle Kunden-Service-Integrator für die Deutsche Verwaltungscloud (DVC)

Einleitung

Das vorliegende Dokument richtet sich an Cloud-Service-Kunden im Sinne des DVC Rahmenwerks [RAHMEN], die Cloud-Services buchen wollen oder bereits gebucht haben und Unterstützung bei der Integration des Cloud-Services benötigen. Die Integration eines Cloud-Services kann mit Hilfe eines Kunden-Service-Integrators im Sinne des DVC Rahmenwerks [RAHMEN] erfolgen. Der Leitfaden unterstützt den Cloud-Service-Kunden bei der Auswahl eines geeigneten Dienstleisters für die Serviceintegration und beschreibt die Anforderungen, die ein Kunden-Service-Integrator in den verschiedenen Phasen der Serviceintegration beachten und umsetzen sollte.

Der Leitfaden zeigt dem zu beauftragenden Kunden-Service-Integrator auf, welche Anforderungen erfüllt sein müssen und welche Möglichkeiten zur Umsetzung zur Verfügung stehen, um den über die Deutsche Verwaltungscloud bezogenen Cloud-Service in die Anwendungs- und Prozesslandschaft eines Cloud-Service-Kunden zu integrieren.

1.1 Zielstellung Leitfaden Kunden-Service-Integrator

Über das Cloud-Service-Portal der Deutschen Verwaltungscloud können Behörden in der Rolle Cloud-Service-Kunde Cloud-Services direkt oder über einen Cloud-Service-Beschaffer (i.d.R. ihr IT-Dienstleister) beschaffen. Der so beschaffte Cloud-Service kann oft nicht ohne weitere Integrationsleistungen genutzt werden. So muss beispielsweise ein Verzeichnisdienst der Behörde angebunden werden, sofern der Verzeichnisdienst nicht mit dem IAM der DVC integriert wurde. Es muss ein Rollen-Rechte-Konzept festgelegt und im Cloud-Service umgesetzt werden. Integrationen mit Fachverfahren der Behörden sind zu konzeptionieren und umzusetzen. In der Regel sind auch formale Voraussetzungen zu erfüllen, die Regularien der Behörde verlangen eine Reihe von Konzepten wie ein Infrastrukturkonzept oder ein Betriebsführungskonzept. Der Verantwortliche (Cloud-Service-Kunde) muss eine datenschutzrechtliche Bewertung anhand der notwendigen Dokumente des Cloud-Service-Anbieters vornehmen. Auf Basis von Infrastrukturkonzepten und Unterlagen für die Betriebsführung muss der Verantwortliche Anforderungen an die Informationssicherheit bewerten. Anhand der Bewertungen von Datenschutz und Informationssicherheit sind abgeleitete technisch-organisatorische Maßnahmen durch den Verantwortlichen zu planen und umzusetzen.

Phasen der Integration eines Services

Die Rolle Kunden-Service-Integrator kann durch einen behördenexternen Dienstleister oder durch interne Organisationen der Behörde selbst wahrgenommen werden. Der vorliegende Leitfaden betrachtet alle Phasen, die bei der Integration eines Cloud-Services auftreten können.

• Auswahlphase
• Planungsphase
• Umsetzungsphase
• Unterstützungsphase
• Beendigungsphase

Gemäß DVC-Rahmenwerk 3.0, Abschnitt 3.2.1 "Rollen auf der Kundenseite" ist die Rolle Kunden-Service-Integrator wie folgt beschrieben:

"Kunden-Service-Integratoren unterstützen bei der Integration von über das Cloud-Service-Portal bezogenen Cloud-Services in die IT-Umgebung des Cloud-Service-Kunden. Kunden-Service-Integratoren können sowohl Akteure der ÖV als auch verwaltungsexterne Anbieter sein."

Die folgende Tabelle beschreibt die Rolle ausführlicher:

Kunden-Service-Integrator (TK4)	Definition Der Kunden-Service-Integrator ist eine Rolle bei einem IT-Dienstleister der Öffentlichen Verwaltung (ÖV) oder bei einem privatwirtschaftlichen Anbieter, der DVC-konforme und über das Cloud-Service-Portal bezogene Services in die IT-Umgebung des Cloud-Service-Kunden integriert. Erläuterung Sofern ein Cloud-Service-Kunde einen Service in der DVC gebucht hat, wird es notwendig sein, diesen Service in die lokale IT-Landschaft der Behörde geeignet zu integrieren. Dazu muss der gebuchte Service in Leistungsbeschreibung und SLA grundsätzlich nutzbar sein, aber vor allem muss die Zielarchitektur für die Einbindung des gebuchten Cloud-Service in der IT-Umgebung des Cloud-Service-Kunden alle Beteiligten bekannt sein. Um diesen neuen Service zu nutzen wird es daher erforderlich sein, projekthaft die Inbetriebnahme und dauerhaft den Betrieb zu unterstützen. Diese Leistung wird in der Rolle "Kunden-Service-Integrator" gebündelt. Diese Rolle KANN von einem Cloud-Service-Beschaffer als IT DL der ÖV wahrgenommen werden, sie KANN aber explizit auch privatwirtschaftlich wahrgenommen werden können, um den bestehenden Supportstrukturen in der ÖV Rechnung zu tragen. Auch eine interne IT-Organisation des Cloud-Service-Kunden (z.B. die IT-Stelle der Behörde) kann diese Rolle wahrnehmen. Eine Akkreditierung des Kunden-Service-Integrators bei der DVC ist nicht notwendig. Aufgaben - Erstmalige Integration des Service in die Umgebung des Cloud-Service-Kunden. Die Beauftragung erfolgt durch den Cloud-Service-Kunden. - Fortlaufende Anpassung der Integration des Service in die Umgebung des Cloud-Service-Kunden, z.B. bei Änderung des Services. Der Cloud-Service-Kunde muss dabei mit dem Kunden-Service-Integrator vereinbaren, ob der Kunden-Service-Integrator Serviceänderungen fortlaufend proaktiv überwachen soll oder auf Anforderung tätig wird (wenn z.B. der Cloud-Service-Kunde über eine Änderung benachrichtigt wird). - Umsetzung der Anforderungen des Cloud-Service-Kunden an die Serviceintegration basierend auf dem gewünschten Reifegradprofil des Kunden und dem Reifegradprofil des Service. Die Erhebung der Anforderungen erfolgt durch die Rollen "DVZ-Berater" bzw. "Cloud-Service-Beschaffer". - Vereinbarung individueller Anforderungen an die Serviceintegration (z.B. welche internen Systeme sollen mit dem Service integriert werden). - Technische Integration des Service in die Umgebung des Cloud-Service-Kunden (z.B. Integration des Verzeichnisdienstes des Kunden mit dem Service zur Umsetzung der Authentifizierung, Anbindung des E-Akten-Systems des Kunden an den Service usw.). - Prozessuale Integration des Service in die Prozesslandschaft des Cloud-Service-Kunden (z.B. Integration in das ITSM-System des Kunden). - Abstimmung mit dem Plattformbetreiber / Softwarebetreiber des Service bei der Umsetzung des Services. Abgrenzungen bzw. Schnittstellen zu anderen Rollen Abgrenzung Plattformbetreiber / Softwarebetreiber: Plattformbetreiber und Softwarebetreiber agieren auf der Angebotsseite des Cloud-Service-Portals und stellen DVC-konforme Services bereit. Der Kunden-Service-Integrator agiert im Auftrag des Cloud-Service-Kunden auf der Kundenseite und interagiert mit Plattformbetreiber oder Softwarebetreiber sowie dem Cloud-Service-Kunden, um den DVC-konformen Service anhand der Anforderungen des Cloud-Service-Kunden in dessen Umgebung zu integrieren. Abgrenzung DVC-Berater / Cloud Service Beschaffer: DVC-Berater / Cloud-Service-Beschaffer erheben die Anforderungen des Cloud-Service-Kunden an den Service basierend auf dem gewünschten Reifegradprofil. Der Kunden-Service-Integrator nimmt die Anforderungen entgegen und setzt diese um.	Akteur der öffentlichen Verwaltung ODER verwaltungsexterner Anbieter

1.3 Nomenklatur

Für die in den folgenden Kapiteln aufgelisteten Anforderungen wurde die folgende Nomenklatur gewählt, die auch in anderen DVC-Dokumenten verwendet wird:

ID	Rolle	Modalverb	Detailanforderung
s. folgende Tabelle	Kunden-Service-Integrator	MUSS | SOLL | KANN	<Anforderungstext>

Die ID-Vergabe in der ersten Spalte wurde dabei nach folgendem Muster gewählt, sodass die Quelle der Anforderung erkennbar ist:

ID	Quelle der Anforderung	Beispiel
LF_KSI_A<lfd_nr>	Leitfaden Kunden-Service-Integrator	LF_KSI_A001 (1.Anforderung des vorliegenden Leitfadens, die nicht aus einem referenzierten Dokument stammt)

Modalverben

Die Verwendung und Bedeutung der modalen Hilfsverben (alternativ Modalverben) ist in der DIN-Norm 820-2 oder RFC2119 geregelt. Ergänzend zu diesen Regeln werden die Modalverben bzw. Schlüsselwörter „MUSS", „SOLL" und „KANN" in den Anforderungstabellen dieses Dokumentes wie folgt verwendet:

• Modalverb "MUSS" weist auf eine absolut zu erfüllende Anforderung (uneingeschränkte Anforderung) bzw. bei Negierung ein Verbot (uneingeschränktes Verbot) hin.
• Modalverb "SOLL" bedeutet, dass eine Anforderung normalerweise erfüllt werden muss, es aber Gründe geben kann, dies doch nicht zu tun. Dies muss aber sorgfältig abgewogen und stichhaltig begründet werden. Analog bei Negierung: etwas sollte normalerweise nicht getan werden, es gibt aber Gründe, dies doch zu tun. Dies muss aber sorgfältig abgewogen und stichhaltig begründet werden.
• Modalverb "KANN" zeigt eine Option an.

2 Anforderungen an Cloud-Service-Kunden der Deutschen Verwaltungscloud

Als Cloud-Service-Kunde wählen Sie je nach Ihren Anforderungen und Bedarfen einen Kunden-Service-Integrator aus, der den gewünschten Cloud-Service in ihre IT-Landschaft integriert.

2.1 Phasenmodell

Die Integration eines Cloud-Services durch den Kunden-Service-Integrator erfolgt dabei in verschiedenen Phasen:

• Phase 1: Auswahlphase: Auswahl eines geeigneten IT-Dienstleisters. Der Leitfaden unterstützt den Cloud-Service-Kunden bei der Auswahl eines geeigneten externen IT-Dienstleisters und auch bei der Beantwortung der Frage, ob eine interne Organisationseinheit der Behörde die Rolle teilweise oder ganz ausfüllen kann. Tritt eine Behörde an einen externen oder internen IT-Dienstleister mit dem Auftrag zur Integration eines oder mehrerer Cloud-Services heran, so kann der IT-Dienstleister anhand des Leitfadens entscheiden, ob er alle Voraussetzungen für die Rolle Kunden-Service-Integrator erfüllt.
• Phase 2: Planungsphase: Konzeptionierung der Integration anhand der Anforderungen des Cloud-Service-Kunden
• Phase 3: Umsetzungsphase: Durchführung der Integration. Sowohl Behörde als auch der IT-Dienstleister in der Rolle Kunden-Service-Integrator können sich anhand des Leitfadens einen Überblick über den möglichen Aufgabenumfang und die Voraussetzungen zur Erfüllung der Aufgaben verschaffen.
• Phase 4: Unterstützungsphase: Fortlaufender Support für die Integration. Sowohl Behörde als auch der IT-Dienstleister in der Rolle Kunden-Service-Integrator können sich anhand des Leitfadens einen Überblick über den möglichen Aufgabenumfang und die Voraussetzungen zur Erfüllung der Aufgaben verschaffen. Betrieb und Support der Integration - die durchgeführte Integration muss ordnungsgemäß betrieben und notwendiger Support geleistet werden. In Abgrenzung zum Cloud-Service, der durch den Cloud-Service-Anbieter betrieben wird und der für den Cloud-Service Support im Rahmen seiner Leistungsbeschreibung leistet, müssen auch die Integrationsleistungen entsprechend den vereinbarten SLA überwacht und gewartet werden. Ist eine Störung des Service gegeben, muss geprüft werden, ob diese Störung dem Cloud-Service-Anbieter zuzurechnen ist oder die Störung durch den Kunden-Service-Integrator behoben werden muss.
• Phase 5: Beendigungsphase: Wechsel bzw. Kündigung des Cloud-Services. Besteht seitens des Cloud-Service-Kunden der Wunsch, den Cloud-Service-Anbieter zu wechseln oder den Bezug von Leistungen zu beenden, unterstützt der Leitfaden sowohl Cloud-Service-Kunden als auch Kunden-Service-Integratoren mit einem Überblick über die notwendigen Maßnahmen im Rahmen der Service-Integration.

2.2 Detaillierte Übersicht der Phasen

Die nachfolgende Übersicht zeigt die einzelnen Phasen der Integration eines Cloud-Services. Die Phasen sind als Orientierung zu verstehen. Insbesondere bei weniger komplexen Einführungsprojekten oder bei der zeitlichen begrenzten Nutzung von Cloud-Services können deutliche Vereinfachungen vorgenommen werden, wenn der gewählte Cloud-Service wenige oder keine Integrationen benötigt.

3 Die Phasen der Service-Integration

Das Phasenmodell der Integration eines Cloud-Services durch den Kunden-Service-Integrator startet nach der Auswahl eines Cloud-Services. Die Auswahl des Cloud-Services selbst ist nicht Teil des Leitfadens.

3.1 Auswahlphase: Auswahl eines geeigneten IT-Dienstleisters

Den Fortschritt bei der Bearbeitung der erforderlichen Themen der Auswahlphase durch den Kunden-Service-Integrator kann der Cloud-Service-Kunde in der folgenden Checkliste protokollieren:

Phase	Anforderung?	Erfüllt (ja / nein)	Referenz
Auswahlphase	Entscheidung zu Nutzung des Cloud-Services ist getroffen?	Entfällt
Auswahlphase	Geeigneter Dienstleister als Kunden-Service-Integrator ausgewählt?		3.1.1, 3.1.2
Auswahlphase	Beauftragung des ausgewählten Kunden-Service-Integrators erfolgt?	Entfällt

3.1.1 Ausprägungen eines IT-Dienstleisters als Kunden-Service-Integrator

Für die Rolle Kunden-Service-Integrator sind verschiedene Ausprägungen bei der Auswahl eines geeigneten IT-Dienstleisters denkbar:

• Externer Dienstleister
• Interner Service-Integrator
• Hybrider Service-Integrator
• Cloud-Service-Anbieter als Service-Integrator
• Cloud-Service-Beschaffer als Service-Integrator.

3.1.1.1 Externer Dienstleister

Der Cloud-Service-Kunde beauftragt vergaberechtskonform einen externen Dienstleister als Kunden-Service-Integrator. Damit sind Personal und Fachwissen sofort verfügbar, vertragliche Leistungen können flexibel ausgeschrieben werden. Nachteilig ist das Risiko des fehlenden Know How Transfers und die notwendige zusätzliche Steuerung des externen Dienstleisters. Das Risiko, die Leistungsfähigkeit des Dienstleisters richtig einzuschätzen, verbleibt beim Cloud-Service-Kunden.

3.1.1.2 Interner Service Integrator

Der Cloud-Service-Kunde verfügt selbst über geeignete Personalressourcen und Organisationseinheiten, die die Rollen Kunden-Service-Integrator übernehmen können. Eine aufwändige Vergabe der Leistung wird vermieden.

3.1.1.3 Hybrider Service Integrator

Der Cloud-Service-Kunde verfügt selbst über geeignete Personalressourcen und Organisationseinheiten, die durch externe Kräfte unterstützt werden. Im Unterschied zum "externen Dienstleister" verbleibt die Umsetzungsverantwortung bei den internen Bereichen, die als Aufgabe die Steuerung der externen Kräfte übernehmen.

3.1.1.4 Cloud-Service-Anbieter als Service-Integrator

In diesem Modell agiert der Cloud-Service-Anbieter auch als Kunden-Service-Integrator. Hierzu muss er die entsprechende Leistung im Service anbieten. Vorteile ist der direkte Bezug der Leistungen und die Kenntnis des gelieferten Cloud-Service. Nachteile sind wie beim "externen Dienstleister" das Risiko des fehlenden Know How Transfers und die notwendige zusätzliche Steuerung.

3.1.1.5 Cloud-Service-Beschaffer als Service-Integrator

In diesem Modell agiert der Cloud-Service-Beschaffer als Kunden-Service-Integrator. Dieses Modell ist dann vorteilhaft, wenn durch entsprechende Bindungen (Pflichtabnahmen bzw. Zwangskontrahierungen) der Cloud-Service-Beschaffer tiefe Kenntnisse der Umgebung des Cloud-Service-Kunden besitzt und bereits andere Leistungen erbringt. Nachteilig kann sich die zusätzlich notwendige Abstimmung mit dem Cloud-Service-Anbieter auswirken.

3.1.2 Anforderungen an die Auswahl eines Kunden-Service-Integrators

Die formalen Voraussetzungen an den Kunden-Service-Integrator werden durch die Anforderungen des Cloud-Service-Kunden und das über den eigentlichen Cloud-Service hinausgehende zusätzliche Leistungsangebot des Cloud-Service-Anbieters sowie des Cloud-Service-Beschaffers definiert. Cloud-Services können neben dem eigentlichen Service zusätzlich angebotene Integrationsleistungen enthalten, in diesem Falle entspricht dies dem zuvor beschriebenen Modell "Cloud-Service-Anbieter als Service Integrator".

ID	Rolle	Modalverb	Detailanforderung
LF_KSI_A001	Cloud-Service-Kunde	MUSS	definieren, welche formalen Voraussetzungen ein externer Service-Integrator erfüllen muss. Dies kann z.B. eine Sicherheitsüberprüfung alle eingesetzten Mitarbeiter nach SÜG sein.
LF_KSI_A002	Cloud-Service-Kunde	MUSS	sicherstellen, dass alle Leistungen, die nicht Teil des Cloud-Service-Angebots sind, vergaberechtskonform bezogen werden.
LF_KSI_A003	Cloud-Service-Kunde	MUSS	sicherstellen, dass bei der Auswahl des Kunden-Service-Integrators die Anforderungen an die fachlichen und technischen Leistungsfähigkeit in allen Phasen berücksichtigt werden.

3.1.3 Ende der Auswahlphase

Die Auswahlphase endet mit der Beauftragung des Kunden-Service-Integrators.

3.2 Planungsphase: Konzeptionierung der Integration anhand der Anforderungen des Cloud-Service-Kunden

Den Fortschritt bei der Bearbeitung der erforderlichen Themen der Planungsphase durch den Kunden-Service-Integrator kann der Cloud-Service-Kunde in der folgenden Checkliste protokollieren:

Phase	Anforderung?	Erfüllt (ja / nein)	Referenz
Planungsphase	Art und Umfang der notwendigen Integrationen des Cloud-Services abgestimmt und durch den Cloud-Service-Kunden abgenommen?		3.2.1.1
Planungsphase	Art und Umfang der notwendigen Konzeptionierungen ist mit dem Kunden-Service-Integrator abgestimmt?		3.2.1.2
Planungsphase	Notwendige Konzepte sind erstellt und abgenommen?		3.2.1.2

3.2.1 Anforderungen in der Planungsphase

In der Planungsphase sind verschiedene Anforderungen zur Vorbereitung der Integration des ausgewählten Cloud-Services zu beachten. Dabei sollte immer der Fokus auf den gewünschten bzw. den erforderlichen Integrationsumfang gelegt werden - die Anforderungen, die zugehörige Konzeption und die Umsetzung müssen im Verhältnis zum erforderlichen Integrationsaufwand angemessen sein.

3.2.1.1 Integrationen anhand ausgewählter Beispiele

Der ausgewählte Cloud-Service kann mit anderen Cloud-Services, mit zentral bereitgestellten Basisdiensten, mit beim Cloud-Service-Kunden vorhandenen Basisdiensten und Fachverfahren integriert werden. Der Cloud-Service-Kunde gibt dabei Art und Umfang der Integrationen vor. Der Kunden-Service-Integrator konzeptioniert die Integrationen in der Planungsphase, setzt diese in der Umsetzungsphase und bietet Support für die Integration über die gesamte Nutzungszeit des Cloud-Services. Im Vordergrund steht die Integration für Authentifizierung und Autorisierung anhand der Detailstandards der DVC (DVC Detailstandards - (50) IAM (Identity- und Access-Management)-Anbindung für SSO (Single Sign On)) als technische Umsetzung des Rechte-Rollen-Konzeptes. Im Zuge dieser Integration wird ein beim Cloud-Service-Kunden vorhandenes System zur Authentisierung und Autorisierung geeignet angebunden. Dies kann ein beim Kunden bereits betriebener Verzeichnisdienst für die Client-Umgebung (z.B. Microsoft Active Directory) sein. Anhand der Anmeldedaten und im Verzeichnisdienst zugeordnete Gruppierungen kann der Zugriff auf den Cloud-Service geregelt werden. Es können weitere Systeme für die Rechteverwaltung vorhanden sein (z.B. zentrale übergreifende Systeme, die für Rechte-Rezertifizierungen eingesetzt werden), die ebenfalls berücksichtigt werden müssen.

Integrationen in Managementsysteme des Cloud-Service-Kunden sind ebenfalls zu berücksichtigen. Darunter fallen insbesondere:

• Integration in ein ITSM-System des Cloud-Service-Kunden
• Integration in Systeme für die Observability (Monitoring, Logging) des Cloud-Service-Kunden
• Integration in ein Security Operations Center (SOC) des Cloud-Service-Kunden

Die infrastrukturelle Integration ist in den jeweiligen Konzepten, insbesondere im Infrastrukturkonzept angemessen zu beschreiben. Die betriebliche Integration ist im Betriebsführungskonzept zu beschreiben.

3.2.1.2 Konzeptionierungen

Der Kunden-Service-Integrator erbringt seine Leistung auf einer vertraglichen Grundlage und der fachlichen Grundlage von Konzepten. Die Art, Anzahl und der Umfang der Konzepte richtet sich nach dem geplantem Nutzungsumfang und der Kritikalität für den Geschäftsbetrieb der nutzenden Organisation (Behörde). Während für Cloud-Services, die z.B. in mehreren Behörden übergreifend genutzt werden und die eine Grundlage für die Handlungsfähigkeit der Verwaltung darstellen, eine umfassende Konzeptionierung erforderlich ist, könnte dies für Cloud-Services, die adhoc genutzt werden und nicht zwingend für die Handlungsfähigkeit der Verwaltung erforderlich sind, auf ein Minimum beschränkt werden.

Der Cloud-Service-Kunde sollte eine weitgehende Standardisierung und Nachnutzung bestehender Konzepte und Konzeptbausteine sicherstellen, um dem Aufwand in einem angemessenen Rahmen zu halten.

Die Verantwortung für den Inhalt der Konzepte trägt der Cloud-Service-Kunde, die Erstellung der Konzepte kann durch den Kunden-Service-Integrator, den Cloud-Service-Kunden selbst oder durch Dritte erfolgen.

Notwendige Konzepte können sein:

• Fachkonzept
• Einführungskonzept
• Rolloutkonzept
• Infrastrukturkonzept
• Betriebsführungskonzept
• Sicherheitskonzept
• Datenschutzkonzept
• Datensicherungskonzept
• Betriebshandbuch
• Cryptokonzept
• Testkonzept
• Kostenmanagementkonzept
• Exit-Strategie.

Eine detaillierte Beschreibung der jeweiligen Konzepte befindet sich in der Anlage dieses Leitfadens.

ID	Rolle	Modalverb	Detailanforderung
LF_KSI_A004	Cloud-Service-Kunde	SOLLTE	eine weitgehende Standardisierung und Nachnutzung bestehender Konzepte und Konzeptbausteine sicherstellen, um dem Aufwand in einem angemessenen Rahmen zu halten.
LF_KSI_A005	Kunden-Service-Integrator	KANN	die Erstellung von Konzepten übernehmen.

3.2.1.3 Informationssicherheit

Der Kunden-Service-Integrator muss die Anforderungen des Cloud-Service-Kunden hinsichtlich Informationssicherheit prüfen und umsetzen. Die Anforderungen des Cloud-Service-Kunden sind dabei in einem IT-Sicherheitskonzept nach BSI Grundschutz zu beschreiben. Maßnahmen, die sich aus dem IT-Sicherheitskonzept entsprechend des BSI-Grundschutzvorgehens ergeben, sollten in der Umsetzungsphase berücksichtigt werden. Details zum IT-Sicherheitskonzept finden sich in der Anlage dieses Leitfadens.

3.2.1.4 Datenschutz

Der Kunden-Service-Integrator muss die Anforderungen des Cloud-Service-Kunden hinsichtlich Datenschutz prüfen und umsetzen. Die Anforderungen des Cloud-Service-Kunden sind dabei in einem Datenschutzkonzept zu beschreiben. Das Datenschutzkonzept kann zusätzliche technisch-organisatorische Maßnahmen zur Umsetzung der Datenschutzanforderungen aufführen, die in der Umsetzungsphase implementiert werden. Das Datenschutzkonzept selbst muss die Anforderungen der DS-GVO hinsichtlich Rechenschafts- und Nachweisfähigkeit sowie Evaluierbarkeit und der Dokumentation der verarbeiteten Daten erfüllen. Details zum Datenschutzkonzept finden sich in der Anlage dieses Leitfadens.

3.2.1.5 Barrierefreiheit

Der Kunden-Service-Integrator muss die Anforderungen des Cloud-Service-Kunden hinsichtlich Barrierefreiheit prüfen und umsetzen. Dies betrifft insbesondere die Integration assistiver Technologien, die im Infrastrukturkonzept konzeptioniert werden sollten.

3.2.1.6 Geschäftsprozesse

Der Cloud-Service-Kunden sollte die von der Einführung des ausgewählten Cloud-Services betroffenen Geschäftsprozesse mit Unterstützung des Kunden-Service-Integrators identifizieren, notwendige Anpassungen definieren und in der Umsetzungsphase implementieren. Die Anpassungen sind während der Supportphase fortlaufend zu überwachen, bei Bedarf sind Optimierungen vorzunehmen. Eine detaillierte Beschreibung der betroffenen Geschäftsprozesse und deren erforderlichen Anpassungen sollten im Einführungskonzept beschrieben sein. Eine detaillierte Beschreibung des Einführungskonzeptes ist in der Anlage dieses Leitfadens zu finden.

3.2.1.7 Rollout

Der Rollout des Cloud-Services ist entsprechend der Erfordernisse des Cloud-Services und der infrastrukturellen und organisatorischen Rahmenbedingungen des Cloud-Service-Kunden zu planen. Die Konzeptionierung des Rollouts sollte in einem Rolloutkonzept erfolgen, eine detaillierte Beschreibung eines Rolloutkonzeptes ist im Anhang dieses Leitfadens zu finden.

3.2.1.8 Exit-Strategie

Eine mögliche Beendigung der Nutzung des Cloud-Services ist besonders zu planen. Hierbei sind insbesondere die Vorgaben des BSI-Grundschutzes zur Cloud-Nutzung zu beachten. Vor Beginn der Nutzung des Cloud-Services ist in angemessener Weise eine Exit-Strategie zu entwickeln.

ID	Rolle	Modalverb	Detailanforderung
LF_KSI_A006	Cloud-Service-Kunde	MUSS	den Umfang der notwendigen Konzeptionierungen anhand seiner infrastrukturellen und organisatorischen Rahmenbedingungen und den Anforderungen des ausgewählten Cloud-Services bestimmen. Dabei sind insbesondere die Anforderungen, die sich aus dem Reifegrad des Cloud-Service nach Reifegradmodell ergeben zu berücksichtigen.
LF_KSI_A007	Kunden-Service-Integrator	KANN	den Cloud-Service-Kunden bei der Bestimmung des Umfangs der notwendigen Konzeptionierungen unterstützen.
LF_KSI_A008	Kunden-Service-Integrator	SOLLTE	den Cloud-Service-Kunden bei der Erstellung, Anpassung und Qualitätssicherung der notwendigen Konzepte unterstützen.
LF_KSI_A009	Cloud-Service-Kunde	MUSS	die vorgenommenen Konzeptionierungen abnehmen.
LF_KSI_A010	Cloud-Service-Kunde	MUSS	eine fortlaufende Prüfung und Überarbeitung der abgenommenen Konzepte sicherstellen.
LF_KSI_A011	Kunden-Service-Integrator	KANN	die fortlaufende Prüfung und Überarbeitung der abgenommenen Konzepte unterstützen.

Im Falle des Bezug eines Cloud-Services können die unterschiedlichen Supportlevel über mehrere Rollen verteilt werden.

ID	Rolle	Modalverb	Detailanforderung
LF_KSI_A012	Cloud-Service-Kunde	SOLLTE	die gewünschten Supportlevel definieren.
LF_KSI_A013	Cloud-Service-Anbieter	MUSS	die durch ihn angebotenen Supportlevel in der standardmäßigen Servicebeschreibung benennen und abgrenzen.
LF_KSI_A014	Kunden-Service-Integrator	SOLLTE	die fehlenden Support-Level, wenn vom Cloud-Service-Kunden beauftragt geeignet vervollständigen.
LF_KSI_A015	Cloud-Service-Anbieter	SOLLTE	den 3rd-Level-Support für dem Cloud-Service erbringen oder ggf. die Aufgabe an den Softwareanbieter delegieren bzw. mit diesem ein separates Supportmodell vereinbaren.
LF_KSI_A016	Cloud-Service-Anbieter	KANN	den 2nd-Level-Support für den Cloud-Service erbringen.
LF_KSI_A017	Kunden-Service-Integrator	SOLLTE	einen geeigneten Support anbieten bzw. für anderweitige Supportmöglichkeiten sorgen, wenn der 2nd-Level-Support nicht durch den Cloud-Service-Anbieter angeboten wird.
LF_KSI_A018	Kunden-Service-Integrator	SOLLTE	eine dauerhafte Supportmöglichkeit für die erbrachten Integrationsleistungen schaffen.
LF_KSI_A019	Kunden-Service-Integrator	SOLLTE	geeignete Support-Strukturen (Servicedesk) aufbauen bzw. vorhalten, Ticketsystem bzw. Anbindung an das Ticketsystem, Hotline, etc., wenn der 2nd-Level-Support beim Kunden-Service-Integrator liegt.
LF_KSI_A020	Cloud-Service-Kunde	SOLLTE	den 1st-Level-Support erbringen oder an den Kunden-Service-Integrator delegieren.
LF_KSI_A021	Kunden-Service-Integrator	SOLLTE	geeignete Support-Strukturen (Servicedesk) aufbauen bzw. vorhalten, Ticketsystem, Hotline, etc., wenn der Cloud-Service-Kunde den 1st-Level-Support an ihn delegiert.

3.2.2 Ende der Planungsphase

Die Planungsphase endet mit der Abnahme der Konzeptionierungen durch den Cloud-Service-Kunden.

3.3 Umsetzungsphase: Nach Beauftragung - Umsetzung der Anforderungen des Cloud-Service-Kunden

Den Fortschritt bei der Bearbeitung der erforderlichen Themen durch den Kunden-Service-Integrator kann der Cloud-Service-Kunde in der folgenden Checkliste protokollieren:

Phase	Anforderung?	Erfüllt (ja / nein)	Referenz
Umsetzungsphase	Sind die betroffenen Geschäftsprozesse angepasst und die fachlichen und organisatorischen Änderungen umgesetzt?		3.3.1.6
Umsetzungsphase	Rollout geplant und durchgeführt?		3.3.1.7
Umsetzungsphase	Erbringung 1st, 2nd und 3rd-Level-Support zwischen allen Beteiligten abgestimmt?		3.3.1.2
Umsetzungsphase	Integration konzeptioniert und implementiert?		3.3.1.1
Umsetzungsphase	Initialer Test anhand von Use Cases ist konzeptioniert, implementiert und erfolgreich durchgeführt?		3.3.2
Umsetzungsphase	Initiale Einbindung in das ITSM-Servicemanagement des Cloud-Service-Kunden ist konzeptioniert und implementiert?		3.3.1.1
Umsetzungsphase	Initiale Einbindung in Observability-Systeme des Cloud-Service-Kunden ist konzeptioniert und implementiert?		3.3.1.1
Umsetzungsphase	Integration SOC ist konzeptioniert und implementiert?		3.3.1.1
Umsetzungsphase	Einbindung in ein System für den Austausch von Sicherheitsvorfällen ist konzeptioniert und implementiert?		3.3.1.1

3.3.1 Maßnahmen in der Umsetzungsphase

In der Umsetzungsphase sind die in den abgenommenen Konzepten beschriebenen Maßnahmen durch den Kunden-Service-Integrator zu implementieren.

3.3.1.1 Infrastrukturelle Maßnahmen

Infrastrukturelle Maßnahmen für die Integration, die in den einzelnen Konzepten, insbesondere im Infrastrukturkonzept geplant wurden, werden in der Umsetzungsphase implementiert und getestet.

Für die Umsetzung der Integration sind insbesondere folgende Dienste zu beachten:

• Integration für Authentifizierung und Autorisierung anhand der Detailstandards der DVC (DVC Detailstandards - (50) IAM (Identity- und Access-Management)-Anbindung für SSO (Single Sign On))
• Für den Austausch von Informationen über Sicherheitsvorfälle ist eine Einbindung entsprechend der Detailstandards der DVC vorzunehmen (DVC Detailstandards - (19) Systematik des Austauschs von sicherheitsrelevanten Vorfällen).

Integrationen in Managementsysteme des Cloud-Service-Kunden sind ebenfalls wie in der Planungsphase konzeptioniert umzusetzen, das betrifft insbesondere folgende Integrationen:

• Integration in ein ITSM-System des Cloud-Service-Kunden
• Integration in Observability-Systeme des Cloud-Service-Kunden
• Integration in ein Security Operations Center (SOC) des Cloud-Service-Kunden.

3.3.1.2 Betriebliche Implementierungen

Die Integration des ausgewählten Cloud-Service in die Betriebsprozesse des Cloud-Service-Kunden gemäß Betriebsführungskonzept wird in der Umsetzungsphase vorgenommen.

3.3.1.3 Informationssicherheit

Die im IT-Sicherheitskonzept aufgeführten Maßnahmen sind in der Umsetzungsphase durchzuführen. Es ist sicherzustellen, dass alle aus dem IT-Sicherheitskonzept abgeleiteten technisch-organisatorischen Maßnahmen zum Produktionsbeginn umgesetzt sind bzw. umgesetzt werden.

3.3.1.4 Datenschutz

Die durch das Datenschutzkonzept vorgesehenen technisch-organisatorischen Maßnahmen werden in der Umsetzungsphase implementiert. Mit Aufnahme der Verarbeitungstätigkeit ist sicherzustellen, dass die für eine datenschutzkonforme Verarbeitung erforderlichen technisch-organisatorischen Maßnahmen umgesetzt sind bzw. umgesetzt werden.

3.3.1.5 Barrierefreiheit

Die konzeptionierten Maßnahmen für die Erfüllung der Anforderungen der Barrierefreiheit sind in der Umsetzungsphase zu implementieren. Es ist sicherzustellen, dass alle aus den Anforderungen resultierenden Maßnahmen zum Produktionsbeginn umgesetzt sind bzw. umgesetzt werden.

3.3.1.6 Geschäftsprozesse

Anhand des Einführungs- und des Rolloutkonzeptes sind in der Umsetzungsphase notwendige Anpassungen an betroffenen Geschäftsprozessen vorzunehmen. Je nach Komplexität der betroffenen Geschäftsprozesse und der vorgenommenen Anpassungen muss eine angemessene Testzeit eingeplant werden.

3.3.1.7 Rolloutmaßnahmen

Der Rollout des Cloud-Services ist entsprechend des Rolloutkonzeptes vorzunehmen. Für alle Maßnahmen ist ein angemessener zeitlicher Vorlauf einzuplanen. Dies trifft insbesondere auf erforderliche Schulungsmaßnahmen und ggf. erforderliche Maßnahmen des Akzeptanzmanagements zu.

3.3.1.8 Exit-Strategie

Vorgaben aus der Exit-Strategie sind in der Umsetzungsphase zu erfüllen. Dies betrifft z.B. den Test von Datenexport- und Import-Szenarien oder die konfigurative Einschränkung der Funktionen des Cloud-Services, wenn diese Funktionen nicht wechselfähig sind.

3.3.1.9 Sonstige Umsetzungen von Konzeptionierungen

Sind in anderen als bisher aufgeführten Konzepten Maßnahmen für die Implementierung der Integration vorgesehen, sind diese in der Umsetzungsphase vorzunehmen.

3.3.2 Test der Integration

Die vorgenommene technische Umsetzung der Integration des ausgewählten Cloud-Services ist zu testen. Dabei sind insbesondere die technische Umsetzung der Integration zu testen (z.B. die korrekte Anbindung eines IAM-Systems oder eines Fachverfahrens über eine Schnittstelle) und ein initialer fachlicher Test anhand von zuvor definierten Anwendungsfällen vorzunehmen. Der Testumfang richtet sich nach der Konzeptionierung in einem Testkonzept. Für den Umfang und die Korrektheit der fachlichen Tests ist der Cloud-Service-Kunde verantwortlich, kann sich aber durch den Kunden-Service-Integrator unterstützen lassen.

3.3.3 Anforderungen in der Umsetzungsphase

In der Umsetzungsphase müssen die folgenden Anforderungen berücksichtigt werden.

ID	Rolle	Modalverb	Detailanforderung
LF_KSI_A022	Cloud-Service-Kunde	MUSS	anhand der in der Planungsphase vorgenommenen und abgenommenen Konzeptionierung die Implementierung der Integration des Cloud-Services beauftragen.
LF_KSI_A023	Kunden-Service-Integrator	MUSS	anhand der in der Planungsphase vorgenommenen und abgenommenen Konzeptionierung die Implementierung der Integration des Cloud-Services nach Auftrag umsetzen.
LF_KSI_A024	Kunden-Service-Integrator	MUSS	die vorgenommene Implementierung in ausreichender Weise testen.
LF_KSI_A025	Cloud-Service-Kunde	MUSS	dem Kunden-Service-Integrator eine Menge an Testfällen zur Verfügung stellen, mit denen die wesentlichen Funktionen des Cloud-Services abgedeckt werden.
LF_KSI_A026	Cloud-Service-Kunde	SOLLTE	den Kunden-Service-Integrator beim Test der technischen Umsetzung der Integration im Sinne einer Mitwirkungsleistung unterstützen.
LF_KSI_A027	Cloud-Service-Kunde	MUSS	die vorgenommenen Implementierungen und deren erfolgreichen Test abnehmen.

3.3.4 Ende der Umsetzungsphase

Die Umsetzungsphase endet mit der Abnahme der implementierten und getesteten Integration des Cloud-Services durch den Cloud-Service-Kunden.

3.4 Unterstützungsphase: Nach Inbetriebnahme

Die Unterstützungsphase startet mit der Betriebsaufnahme bzw. mit der produktiven Nutzung des Cloud-Services, ggf. auch in pilothafter Art und Weise. Den Fortschritt bei der Bearbeitung der erforderlichen Themen durch den Kunden-Service-Integrator in der Unterstützungsphase kann der Cloud-Service-Kunde in der folgenden Checkliste protokollieren:

Phase	Anforderung?	Erfüllt (ja / nein)	Referenz
Unterstützungsphase	Regelmäßige Überprüfung der betroffenen Prozesse und aus den Überprüfungen erforderliche notwendige Anpassungen durchgeführt?	Entfällt
Unterstützungsphase	Überprüfung und Weiterentwicklung der ITSM-Prozesse zur Einhaltung der vereinbarten Servicequalität ist sichergestellt?	Entfällt
Unterstützungsphase	Fortlaufender Support für die Integration ist sichergestellt?	Entfällt
Unterstützungsphase	Fortlaufendes Testvorgehens für die Integration ist sichergestellt?	Entfällt
Unterstützungsphase	Fortlaufender Support für die Einbindung in Observability-Systeme ist sichergestellt?	Entfällt
Unterstützungsphase	Fortlaufender Support für die Einbindung in das SOC ist sichergestellt?	Entfällt

3.4.1 Wichtige Rollen des Kunden-Service-Integrators

Im Rahmen der Support-Phase tritt der Kunden-Service-Integrator in der im Betriebsführungskonzept festgelegten Support-Rolle auf. Je nach Vereinbarung mit dem Cloud-Service-Kunden müssen die folgenden Anforderungen erfüllt sein:

ID	Rolle	Modalverb	Detailanforderung
LF_KSI_A028	Cloud-Service-Kunde	SOLLTE	eine regelmäßige Überprüfung der betroffenen Geschäftsprozesse durchführen und erforderliche Anpassungen beauftragen.
LF_KSI_A029	Kunden-Service-Integrator	SOLLTE	die vereinbarte Servicequalität durch fortlaufende Überprüfung und Weiterentwicklung der ITSM-Prozesse sicherstellen.
LF_KSI_A030	Kunden-Service-Integrator	SOLLTE	einen fortlaufenden Supports für die Integration sicherstellen.
LF_KSI_A031	Kunden-Service-Integrator	SOLLTE	ein fortlaufenden Testvorgehens für die Integration sicherstellen.
LF_KSI_A032	Kunden-Service-Integrator	SOLLTE	Support für Einbindung in Observability
LF_KSI_A033	Kunden-Service-Integrator	SOLLTE	einen fortlaufenden Supports für die Einbindung in das SOC sicherstellen.
LF_KSI_A034	Kunden-Service-Integrator	MUSS	einen fortlaufenden Support für die Einbindung in ein System zum Austausch von Sicherheitsvorfällen entsprechend DVC Detailstandards - (19) Systematik des Austauschs von sicherheitsrelevanten Vorfällen sicherstellen

Eine besondere Bedeutung kommt der Einbindung des Cloud-Services und dessen Integration in das Servicemanagement des Cloud-Service-Kunden zu. Der Servicedesk des Cloud-Service-Kunden und die daran anknüpfenden Prozesse wie Incident-, Problem- und Changemagement muss bereits in der Planungsphase angemessen einbezogen werden. Das Betriebsführungskonzept, welches die Einbindung näher beschreibt, wird im Anhang dieses Leitfadens ausführlicher dargestellt.

3.4.2 Ende der Unterstützungsphase

Die Unterstützungsphase endet mit der Beendigung der Nutzung des Services. Ist ein Wechsel zu einem anderen Cloud-Service bzw. einem anderen Anbieter geplant, folgt eine Beendigungs- bzw. Migrationsphase.

3.5 Beendigungsphase: Ablösung des Cloud-Services bzw. Beendigung der Nutzung

Den Fortschritt bei der Bearbeitung der erforderlichen Themen durch den Kunden-Service-Integrator kann der Cloud-Service-Kunde in der folgenden Checkliste protokollieren:

Phase	Anforderung	Erfüllt (ja / nein)	Referenz
Beendigungsphase	Sind die betroffenen Prozesse angepasst und die fachlichen und organisatorischen Änderungen betrachtet, konzeptioniert und umgesetzt?	Entfällt
Beendigungsphase	Ist die geordnete Rücknahme des Roll Outs geplant und durchgeführt?	Entfällt
Beendigungsphase	Export der Kundendaten ist sichergestellt ?	Entfällt
Beendigungsphase	Export der Konfiguration ist sichergestellt ?	Entfällt

Anhand des Reifegradmodells hat der Cloud-Service-Anbieter die Eigenschaften des Service dokumentiert. Aufgabe des Kunden-Service-Integrators ist es in der Phase "Ablösung" nun, die entsprechenden Maßnahmen umzusetzen, die aus dem Reifegradmodell für die Wechselfähigkeit vorgesehen sind.

3.5.1 Anforderungen in der Beendigungsphase

In der Umsetzungsphase müssen die folgenden Anforderungen berücksichtigt werden:

ID	Rolle	Modalverb	Detailanforderung
LF_KSI_A035	Kunden-Service-Integrator	SOLLTE	den Cloud-Service-Kunden entsprechend seiner Anforderungen bei der Änderung von Geschäftsprozessen und erforderlichen fachlichen und organisatorischen Anpassungen unterstützen, wenn die Nutzung eines Cloud-Service beendet wird.
LF_KSI_A036	Kunden-Service-Integrator	SOLLTE	alle durch das Rollout des Cloud-Services bedingten Rollout-Tätigkeiten in geordneter Weise zurücknehmen (Client-Rollout, Integration in Um-Systeme, Fachverfahren sowie Monitoringsysteme).
LF_KSI_A037	Kunden-Service-Integrator	SOLLTE	den Cloud-Service-Kunden (ggf. separate Beauftragung) bei der Migration des Services geeignet unterstützen.

5 Rollenübergreifende Erläuterungen zur DVC

Der vorliegende Leitfaden beschäftigt sich mit technischen und organisatorischen Fragestellungen für die Rolle Kunden-Service-Integrator. Nicht Gegenstand dieses Dokumentes sind die juristischen Aspekte der DVC (bestehende Regelungen aus dem Vergabe-, Beihilfe- und Kartellrecht mit Auswirkungen auf die Zusammenarbeit der öffentlichen Hand untereinander sowie mit Dritten aus der freien Wirtschaft), die Einfluss auf die Rolle Kunden-Service-Integrator haben.

5.1 Motivation DVC

Die Deutsche Verwaltungscloud (DVC) verfolgt das Ziel, die Digitalisierung der öffentlichen Verwaltung voranzutreiben und dabei die Digitale Souveränität Deutschlands zu stärken. Die Rahmenbedingungen der DVC sind im Rahmenwerk Zielarchitektur niedergelegt (siehe [RAHMEN], Kapitel 1). Formaler Auftraggeber für die DVC ist der IT-Planungsrat, der im Rahmen der Strategie zur Stärkung der Digitalen Souveränität zunächst die Deutsche Verwaltungscloud-Strategie (DVS) verabschiedet und damit die konzeptionelle Grundlage für die Deutsche Verwaltungscloud (DVC) geschaffen hat. Weitere Details zur Motivation der DVC finden sich im DVC-Rahmenwerk [RAHMEN] speziell in den Kapiteln 1 und 2.

5.2 Rahmenwerk

Übergeordnetes Dokument für alle strategischen DVC-Themen ist das DVC-Rahmenwerk [RAHMEN]. Es kann daher als Einstiegslektüre für Interessenten dienen, die sich zunächst rollenübergreifend über das Thema DVC informieren wollen. Das Rahmenwerk fokussiert auf die strategischen Architekturentscheidungen („was“). Die technischen Anforderungen werden im Reifegradmodell [REIFEG], diversen Detailstandards sowie Whitepapern der IGBvC beschrieben.

5.3 Organisation der DVC

Das DVC-Rahmenwerk [RAHMEN] enthält in Kapitel 3 "Geschäftsarchitektur der DVC" einen Überblick über die Organisation der DVC. Relevant für die im vorliegenden Leitfaden beschriebene Rolle Kunden-Service-Integrator ist vor allem der Kunde selbst (Rolle Cloud-Service-Kunde).

5.4 Motivation Leitfäden

Die zu allen DVC-Rollen verfügbaren Leitfäden werden erstellt, um Interessenten ein Set von "Checklisten" zur Verfügung zu stellen, mit denen sie feststellen können, ob sie alles bearbeitet haben, was für die im Leitfaden beschriebene Rolle erschlossen werden sollte. Die in den Leitfäden beschriebenen Anforderungen wurden weitestgehend aus anderen Dokumenten gemäß der folgenden Abbildung aus Kapitel 4 des DVC Rahmenwerkes [RAHMEN] übernommen:

Anlagen

In der Anlage zu diesem Leitfaden ist eine Detaillierung möglicher Konzepte zu finden (s.u.).

Anhang

Glossar

Ein DVC-weit gültiges Glossar ist zu finden im DVC-Rahmenwerk [RAHMEN] Kap. 6.1.

Reifegradmodell und Stufenmodell

Das DVC-Rahmenwerk der Zielarchitektur [RAHMEN] Kap. 5 definiert das Reifegradmodell wie folgt: "Mit der Deutschen Verwaltungscloud (DVC) sollen verbindliche Mindestanforderungen für alle teilnehmenden Cloud-Service-Anbieter eingeführt werden, die in einem Reifegradmodell abgebildet sind. Durch die Anwendung des Reifegradmodells soll sichergestellt werden, dass die eingereichten Cloud-Service-Kandidaten den Minimalkriterien der DVC entsprechen, sodass sie über das Cloud-Service-Portal angeboten werden können."

Für das Reifegradmodell ist die jeweils gültige Fassung auf der Webseite Deutsche Verwaltungscloud veröffentlicht.

Für den laufenden Pilotbetrieb wird die Definition der Mindestanforderungen anhand eines Stufenmodells als Auszug aus dem Reifegradmodells vorgenommen.

Anlage Konzepte zum Leitfaden Kunden-Service-Integrator

Die Anlage beschreibt die Konzepte, die in der Planungsphase bei der Integration eines Cloud-Services entstehen können näher. Anzahl und Umfang der notwendigen Konzeptionierungen richten sich nach der Nutzungsdauer, der Nutzungsbreite und der Geschäftskritikalität des Cloud-Services und der Integration in die IT-Landschaft des Cloud-Service-Kunden.

1 Konzepte

Notwendige Konzepte für eine erfolgreiche Integration eines Cloud-Services in die IT-Landschaft des Cloud-Service-Kunden können sein:

• Fachkonzept
• Einführungskonzept
• Rolloutkonzept
• Infrastrukturkonzept
• Betriebsführungskonzept
• Sicherheitskonzept
• Datenschutzkonzept
• Datensicherungskonzept
• Betriebshandbuch
• Cryptokonzept
• Testkonzept
• Kostenmanagementkonzept
• Exit-Strategie.

1.1 Fachkonzept

Das Fachkonzept ist Ausgangspunkt für die Darstellung der fachlichen Anforderungen des Cloud-Service-Kunden an die Integration des Cloud-Services. Das Konzept muss neben den nachfolgend aufgelisteten Anforderungen auch spezifische Anforderungen des Cloud-Service-Kunden berücksichtigen, die in diesem Leitfaden nicht berücksichtigt werden können. Dazu zählen:

• Konzepte, die aus Vorgaben des Cloud-Service-Kunden resultieren
• Rahmenbedingungen (Arbeitsplatz-Infrastrukturen, Netze, Schutzbedarfsanforderung, Datenschutzanforderungen, ggf. Geheimschutzanforderungen etc.)
• Integrationen in kundenspezifische fachliche Systeme (E-Akte, Fachverfahren)
• Integrationen in kundenspezifische technische Systeme (Monitoring, Ticketsysteme, SOC, Lizenzverwaltung)
• Erforderliche SLA definieren
• Gewünschtes Servicemodell auswählen
• Veröffentlichung der Konfiguration (sofern sinnvoll) und andere, wiederverwendbare Artefakte auf OpenCoDE fordern.

Aufgabe des Fachkonzeptes ist auch das Aufzeigen von Differenzen zwischen dem Reifegrad des Cloud-Services und dem Anforderungen des Cloud-Service-Kunden. Das Konzept beschreibt, ob und wie diese Differenzen zu behandeln sind.

Dies betrifft insbesondere folgenden Reifegrade:

• Skalierbarkeit (Überwachung der Auslastung bzw. der Performance des Services, Erkennung und Behandlung von Engpässen und Überkapazitäten)
• AutoScaling (Überwachung der ordnungsgemäßen Funktion selbstskalierender Services und des daraus resultierenden Ressourcenverbrauchs)
• Barrierefreiheit (Integration assistiver Technologien, zusätzlich werden ggf. erforderliche technische Maßnahmen im Infrastrukturkonzept beschrieben)
• Neuer Programmstand (Einbindung des durch den Cloud-Service-Anbieter vorgegebenen Wartungsmodells in das Releasemanagement des Cloud-Service-Kunden)
• Mandantentrennung (Konzeptionierung flankierender Maßnahmen, wenn die angebotene Mandantentrennung die Anforderungen des Kunden nicht hinreichend erfüllt)
• Abrechnung (Einbindung des Ressourcenverbrauchs in ein Verbrauchsmonitoring für die fortlaufende Überwachung und in ein Verbrauchsreporting für eine periodische Übersicht. Ein Kostenmanagementkonzept kann bei der Planung unterstützen)
• Benutzerdokumentation (ausreichende Dokumentation für den täglichen Betrieb und für Schulungszwecke)
• Technische Dokumentation (ausreichende Dokumentation für die fachliche und technische Administration des Cloud-Services)
• Verfügbarkeit (Überwachung der Verfügbarkeit und Abgleich mit der zugesagten Verfügbarkeit)
• Inhalts-Verschlüsselung (Einbindung von Schlüsselmaterial in das Schlüsselmanagement des Cloud-Service-Kunden, Sicherstellung der funktionsfähigen Entschlüsselung verschlüsselter Backups)
• Sicherung und Wiederherstellung (Festlegung der zu sichernden Daten und der Sicherungsstrategie)
• Sicherung und Wiederherstellung im Self-Service (Integration einer Self-Service-Sicherung in die Backup-und Wiederherstellungsprozesse des Cloud-Service-Kunden)
• SBOM (Einbindung des gelieferten SBOMs in ein ISMS des Kunden).

1.2 Einführungskonzept

Das Einführungskonzept beinhaltet

• eine Betrachtung der von der Nutzung des Cloud-Services betroffenen Geschäftsprozesse
• die notwendigen Anpassungen an den Geschäftsprozessen
• erforderliche Schulungsmaßnahmen für die Mitarbeiter, die von der Einführung betroffen sind, erforderlichenfalls auch abgestuft nach Betroffenheitsgrad und vorgesehener Rolle in den Geschäftsprozessen
• die Einbeziehung und Beteiligung bzw. Mitwirkung von Gremien des Cloud-Service-Kunden, wie z.B. Personalvertretungen, Datenschutzbeauftragte, IT-Sicherheitsbeauftragte, Geheimschutzbeauftragte.

Anforderungen aus dem Einführungskonzept, die Auswirkungen auf die Leistungen des Kunden-Service-Integrators haben, sind bei dessen Auswahl zu berücksichtigen.

1.3 Rolloutkonzept

Das Rolloutkonzept beschreibt die Schaffung der technischen und organisatorischen Maßnahmen zum Rollout des Cloud-Services. Insbesondere die zeitlichen Abhängigkeiten der Aufgaben der beteiligten Rollen im Rahmen der Rollout-Tätigkeiten stehen im Mittelpunkt dieses Konzeptes.

1.4 Infrastrukturkonzept

Ein Infrastrukturkonzept beschreibt die notwendige Infrastruktur auf der Seite des Cloud-Service-Kunden, die zur Integration und zum Betrieb des Cloud-Services erforderlich ist. Dies umfasst i.d.R. Server- und Client-Komponenten, Netzwerkinfrastrukturen und -sicherheitselemente sowie notwendige Kommunikationsbeziehungen. Das Infrastrukturkonzept ist Grundlage für die Erstellung eines Sicherheitskonzeptes nach BSI-Grundschutz.

1.5 Betriebsführungskonzept

Das Betriebsführungskonzept beschreibt die prozessuale Integration des Cloud-Services in das IT-Servicemanagement des Cloud-Service-Kunden. Zum Betriebsführungskonzept gehört auch die Beschreibung der Einführung beim Servicedesk des Cloud-Service-Kunden, sofern dieser die Rolle des 1st-Level-Supports selbst übernimmt.

Es ist ein besonderer Fokus auf die Integration der ITSM-Prozesse in ein bestehendes Servicemanagement zu legen. Vorhandene Konzepte, Organisations- und Prozesstrukturen sowie Werkzeuge für das ITSM sollten soweit wie möglich genutzt werden. Die folgenden IT-Servicemanagementprozesse sollte ein Betriebsführungskonzept beschreiben:

• Incidentmanagement
• Problemmanagement
• Changemanagement.

1.5.1 Incidentmanagement

Das Incidentmanagement behandelt Störungen des Cloud-Services und sorgt für eine schnellstmögliche Wiederherstellung der Funktionalität des Cloud-Services ggf. auch unter Anwendung von Workarounds.

Der zu erbringende Support im Rahmen des Incidentmanagement wird i.d.R. durch mehrere Stufen erbracht. Dabei können folgende Stufen unterschieden werden:

• 1st-Level-Support: Der 1st-Level-Support ist erster Ansprechpartner für die direkten Nutzer (Anwender) des Cloud-Services. Der 1st-Level-Support nimmt den Incident in geeigneter Weise auf, bietet ggf. erste Lösungsmöglichkeiten an, leitet den Incident an den 2nd-Level-Support weiter und schließt den Incident nach erfolgter Lösung.
• 2nd-Level-Support: Der 2nd-Support hat initial keinen direkten Kontakt mit Anwender, sondern wird vom 1st-Level-Support kontaktiert, wenn der Incident dort nicht gelöst werden konnte. Je nach Ausprägung kann der 2nd-Level-Support im Rahmen der Lösungsfindung direkt mit dem Anwender kommunizieren oder diese Kommunikation über den 1st-Level-Support leiten.
• 3rd-Level-Support: Komplexere Lösungsfindungen werden in den 3rd-Level-Support ausgelagert, der hierzu vom 2nd-Level-Suppport kontaktiert wird.

Im Falle des Bezug eines Cloud-Services können die unterschiedlichen Supportlevel über mehrere Rollen verteilt werden.

ID	Rolle	Modalverb	Detailanforderung
LF_KSI_A035	Cloud-Service-Kunde	SOLLTE	die gewünschten Supportlevel definieren.
LF_KSI_A036	Cloud-Service-Anbieter	MUSS	die durch ihn angebotenen Supportlevel in der standardmäßigen Servicebeschreibung benennen und abgrenzen.
LF_KSI_A037	Kunden-Service-Integrator	SOLLTE	die fehlenden Support-Level, wenn vom Cloud-Service-Kunden beauftragt geeignet vervollständigen.
LF_KSI_A038	Cloud-Service-Anbieter	SOLLTE	den 3rd-Level-Support für dem Cloud-Service erbringen oder ggf. die Aufgabe an den Softwareanbieter delegieren bzw. mit diesem ein separates Supportmodell vereinbaren.
LF_KSI_A039	Cloud-Service-Anbieter	KANN	den 2nd-Level-Support für den Cloud-Service erbringen.
LF_KSI_A040	Kunden-Service-Integrator	SOLLTE	einen geeigneten Support anbieten bzw. für anderweitige Supportmöglichkeiten sorgen, wenn der 2nd-Level-Support nicht durch den Cloud-Service-Anbieter angeboten wird.
LF_KSI_A041	Kunden-Service-Integrator	SOLLTE	eine dauerhafte Supportmöglichkeit für die erbrachten Integrationsleistungen schaffen.
LF_KSI_A042	Kunden-Service-Integrator	SOLLTE	geeignete Support-Strukturen (Servicedesk) aufbauen bzw. vorhalten, Ticketsystem bzw. Anbindung an das Ticketsystem, Hotline, etc., wenn der 2nd-Level-Support beim Kunden-Service-Integrator liegt.
LF_KSI_A043	Cloud-Service-Kunde	SOLLTE	den 1st-Level-Support erbringen oder an den Kunden-Service-Integrator delegieren.
LF_KSI_A044	Kunden-Service-Integrator	SOLLTE	geeignete Support-Strukturen (Servicedesk) aufbauen bzw. vorhalten, Ticketsystem, Hotline, etc., wenn der Cloud-Service-Kunde den 1st-Level-Support an ihn delegiert.

Je nach Anforderungen des Cloud-Service-Kunden kann der Kunden-Service-Integrator weitere Serviceprozesse optional berücksichtigen:

• Request Fulfilment
• Access Management
• Event Management
• Service Asset and Configuration Management
• Kapazitäts- und Verfügbarkeitsmanagement
• Projektmanagement
• Release und Deployment Management.

Der Cloud-Service-Anbieter kann ein Template für ein Betriebsführungskonzept zur Verfügung stellen.

1.6 Sicherheitskonzept (Modellierung nach BSI-Grundschutz)

Ein Sicherheitskonzept dokumentiert die Definition des IT-Verbundes, in dessen Rahmen der Cloud-Service in der Kunden-Umgebung betrieben wird, die Modellierung, Risikobewertung und Maßnahmen zur Sicherstellung des definierten Schutzbedarfs nach BSI-Grundschutz. Grundlage des Sicherheitskonzeptes ist ein Infrastrukturkonzept, das eine Definition des IT-Verbundes ermöglicht.

1.7 Datenschutzkonzept

Ein Datenschutzkonzept sollte eine Schutzbedarfsfeststellung beinhalten und die Ergebnisse der Schutzbedarfsfeststellung mit den Möglichkeiten des beschafften Cloud-Services abgleichen, Lücken müssen durch geeignete technisch-organisatorische Maßnahmen geschlossen werden, die der Kunden-Service-Integrator konzeptioniert und umsetzt.

1.8 Datensicherungskonzept

Das Datensicherungskonzept beschreibt die zu sichernden Daten des Cloud-Services und die technische Art und Weise der Datensicherung.

1.9 Betriebshandbuch

Ein Betriebshandbuch beschreibt wesentliche betriebliche Aufgaben auf operativer Ebene, die für den Betrieb des Cloud-Services erforderlich sind.

1.10 Kryptokonzept

Das Kryptokonzept beschreibt im Cloud-Service und in der Integration verwendete Krypto-Algorithmen. Dies stellt sicher, dass nur zulässige Algorithmen verwendet werden und erlaubt eine fortwährende, regelmäßige Überprüfung.

1.11 Testkonzept

Das Testkonzept beschreibt das Testvorgehen bei der Einführung und im Betrieb des Cloud-Services. Das Testvorgehen setzt auf durch den Cloud-Service-Kunden vorgegebene Testfälle auf und sollte die Einhaltung testbarer funktionaler und nicht-funktionaler Anforderungen fortlaufend sicherstellen.

1.12 Kostenmanagementkonzept

Das Kostenmanagementkonzept kann den Umgang mit variablen Verbrauchskosten definieren, wenn der Cloud-Service diese Form der Abrechnung vorsieht.

1.13 Exit-Strategie

Eine Exit-Strategie definiert das Vorgehen im Falle der Beendigung bzw. des Wechsel der Nutzung eines Cloud-Services. Die Exit-Strategie ist vor Nutzungsbeginn des Cloud-Services festzulegen, um bereits bei der Implementierung notwendige Maßnahmen zu definieren, die eine Beendigung oder einen Wechsel mit geringstmöglicher Einschränkung des Geschäftsbetriebes der Cloud-Service-Kunden ermöglichen.