Sichere mobile Lösungen, Donnerstag, 18. Oktober 2012, 09:45 Uhr. Moderner Staat 6. 7. November 2012, Berlin

2012 # 5 20. Jahrgang BSI Forum Forum Organ des Bundesamtes für Sicherheit in der Informationstechnik Inhalt Das BSI auf den Herbstmessen 35 Cloud-Computing-SLAs 36 Amtliche Mitteilungen 43 Messepräsenz Das BSI auf den Herbstmessen 2012 Die Themen IT-Sicherheit und E-Government stehen im Mittelpunkt der Sicherheitsfachmesse it-sa in Nürnberg sowie der Kongressmesse Moderner Staat in Berlin, bei denen das BSI auch in diesem Jahr wieder vertreten ist. it-sa 16. 18. Oktober 2012, Nürnberg Die it-sa ist eine Fachmesse, die sich exklusiv auf das Thema Informationssicherheit konzentriert. Die Messe war von 1999 bis 2008 als Sicherheitshalle in die ehemalige Systems integriert. Seit 2009 findet die it-sa (www.it-sa.de) als eigenständige Messe im Messezentrum Nürnberg statt Veranstalter ist die NürnbergMesse GmbH. In diesem Jahr informiert das BSI auf seinem Stand in der Halle 12, Stand-Nr. 632 über die Themen Cyber-Sicherheit, IT-Grundschutz, IT-Sicherheitsberatung, De-Mail, IT-Sicherheitszertifizierung sowie sichere mobile Lösungen. Neben der Keynote zur it-sa- Eröffnung am Dienstag, den 16. Oktober 2012 um 09:45 Uhr, durch die Amtsleitung beteiligt sich das BSI mit jeweils einem Vortrag je Messetag: Cyber-Sicherheit, Dienstag, 16. Oktober 2012, 10:45 Uhr De-Mail, Mittwoch, 17. Oktober 2012, 09:45 Uhr Sichere mobile Lösungen, Donnerstag, 18. Oktober 2012, 09:45 Uhr Moderner Staat 6. 7. November 2012, Berlin Bereits zum 16. Mal öffnet die Fachmesse Moderner Staat ihre Pforten. Die Veranstaltung in den Hallen 2 und 4 des Messegeländes Berlin widmet sich vom 6. bis 7. November 2012 unter anderem den Themen IT/E-Government, Weiterbildung/E-Learning Telekommunikation/Mobile Computing sowie IT-Sicherheit und richtet sich an Entscheidungsträger aus Bundes-, Landes- und Kommunalverwaltungen. Das BSI ist in der Halle 2, Stand-Nr. 510 mit den Themen Cyber-Sicherheit, IT-Sicherheitsberatung und De-Mail vertreten. Darüber hinaus gestaltet das BSI am 6. November 2012 ein 90-minütiges Kongressforum zum Thema IT-Security ; weitere Informationen stehen unter www.moderner-staat. com zur Verfügung. Impressum Redaktion: Matthias Gärtner (verantwortlich) E-Mail: matthias.gaertner@bsi.bund.de Sebastian Bebel E-Mail: sebastian.bebel@bsi.bund.de Bundesamt für Sicherheit in der Informationstechnik (BSI) Referat Öffentlichkeitsarbeit und Presse Postfach 20 03 63 53133 Bonn Hausanschrift: Godesberger Allee 185 189 53175 Bonn Telefon: +49 228 999582-0 Telefax: +49 228 999582-5455 Web: www.bsi.bund.de www.bsi-fuer-buerger.de Das BSI-Forum, Organ des Bundesamtes für Sicherheit in der Informationstechnik in Bonn, ist Bestandteil der <kes> Die Zeitschrift für Informations-Sicherheit 20. Jahrgang 2012 BSI 53133 Bonn <kes> 2012 # 5 35

SLAs für Cloud-Computing Damit die Sicherheit nicht zu kurz kommt: Cloud-Computing-SLAs Immer mehr Endkunden, aber auch Unternehmen und Behörden nutzen zunehmend Cloud- Computing-Angebote. Dabei werden Verträge mit Cloud-Computing-Anbietern geschlossen, die denen von Outsourcing-Verträgen ähnlich sind. Für viele Institutionen, die Cloud-Services nutzen, sind die entsprechenden Service-Level-Agreements (SLAs) der erste Outsourcing- Vertrag. Da Cloud-Services anders als die meisten Outsourcing-Dienstleistungen hochgradig standardisiert sind, können für diese SLAs spezifischere Empfehlungen gegeben werden. Von Clemens Doubrava und Isabel Münch, BSI Es vergeht kein Monat und keine Woche, in denen nicht neue Cloud-Services von frisch gegründeten ebenso wie von etablierten Unternehmen angeboten werden. Cloud-Dienstleistungen werden sowohl von Institutionen als auch von Endkunden immer stärker genutzt. Gleichzeitig nehmen aber auch Meldungen über Sicherheitsprobleme bei Cloud-Services zu, beispielsweise Berichte über gestohlene (Zugangs-)Daten zu Diensteanbietern oder über Ausfälle von Cloud-Infrastruktur. Die Ursachen mögen immer sehr unterschiedlich sein, aber immer sind Daten, die einem Dritten anvertraut wurden, davon betroffen. Inzwischen gibt es auch von verschiedenen Institutionen und Gremien eine Reihe von Sicherheitsempfehlungen für das Cloud-Computing, unter anderem auch vom Bundesamt für Sicherheit in der Informationstechnik (BSI, [1,2,3,4,5,6]). Bevor Cloud-Dienstleistungen genutzt werden, sollten diese Sicherheitsempfehlungen gesichtet werden und hierauf aufbauend für die eigene Institution passende Richtlinien erstellt werden. Bei der Nutzung einer Private Cloud sind diese leichter umzusetzen als bei der Nutzung externer Dienstleister, da Betrieb und Verwaltung der Cloud-Dienste unter Kontrolle der eigenen Institution sind. Wird jedoch über die Nutzung von Public-Cloud-Services nachgedacht, stellen sich die Sicherheitsfragen mit neuer Schärfe: Hierbei ist oft unklar, was der Kunde vom Anbieter an Sicherheit verlangen muss, was Anbieter bereit sind, an Sicherheit anzubieten, und zu welchen Konditionen und wie der Kunde dies im laufenden Betrieb überprüfen kann. Wird in einer Institution über die Nutzung von Cloud-Services nachgedacht, muss zunächst analysiert werden, ob der betrachtete Geschäftsprozess hierfür überhaupt geeignet ist. Dabei spielen nicht nur Kostenbetrachtungen eine Rolle, sondern auch der Schutzbedarf der Daten beziehungsweise der Anwendungen, die künftig vom Anbieter der Cloud-Dienstleistungen (Cloud-Service- Provider CSP) gehostet beziehungsweise verarbeitet werden sollen. Wenn der Schutzbedarf nicht direkt aus dem Sicherheitskonzept abgelesen werden kann, muss er bewertet werden. Darauf aufbauend muss von der Institution eine Risikoanalyse durchgeführt werden, deren Ergebnisse dann in Sicherheitsanforderungen für diesen konkreten Cloud-Service münden. Im Rückschluss muss nach Analyse der erreichbaren Sicherheit entschieden werden, ob der Cloud-Service für das Unternehmen oder die Behörde nutzbar ist. Für die Nutzung von Cloud-Services müssen Verträge mit dem Diensteanbieter geschlossen werden, in denen die vereinbarte Leistung sowie einige Sicherheitsthemen festgeschrieben sind. Dies ist nicht nur bei Public- Cloud-Angeboten, sondern auch bei Cloud-Services, die innerhalb einer Institution erbracht werden, sinnvoll. Das BSI hat Dienstgütevereinbarungen (Service- Level-Agreements oder kurz SLAs) von verschiedenen Public-Cloud-Anbietern untersuchen lassen. Inhalt und Qualität der betrachteten SLAs differierten deutlich: In manchen wurde fast nichts festgelegt, in anderen wiederum wurden der Service ausführlich beschrieben, die Dienstgüte quantifiziert und weitere Regelungen etabliert. Auch die Auskunftsbereitschaft der Unternehmen zu ihrer Informationssicherheit war sehr unterschiedlich: Während manche CSPs auch auf Nachfrage nicht bereit waren, ihre Informationssicherheit weiter zu erläutern, zeigten sich andere nach Abschluss einer Vertraulichkeitsvereinbarung sehr kooperativ. Auf Basis dieser Untersuchung und den im Literaturverzeichnis erwähnten Quellen[7,8] gibt das BSI Empfehlungen für die Vertragsgestaltung beim Cloud-Computing. Public Clouds Public-Cloud-Computing ist Outsourcing Über Cloud-Computing wird im Moment sehr viel geschrieben, sodass hier auf eine lange Einführung 36 BSI 53133 Bonn <kes> 2012 # 5

verzichtet wird. Ganz allgemein sind die im Folgenden beschriebenen Kriterien für IT-Dienstleistungen anwendbar, die über definierte Schnittstellen, zum Beispiel über das Internet oder auch interne Netze, angeboten werden. Im Fokus stehen Public-Cloud-Angebote, von denen sich viele an Privatkunden richten, aber auch Angebote wie Virtual Managed Private Clouds, die sich vor allem an Geschäftskunden wenden. Manche der folgenden Hinweise lassen sich auch auf Hybrid und Private Clouds übertragen. Die Nutzung von Public-Cloud-Diensten ist immer eine Form von Outsourcing wie Outsourcing sicher betrieben werden kann, ist in den IT-Grundschutz-Katalogen [9] im Baustein B 1.11 Outsourcing beschrieben, der die wesentlichen Aspekte bei Auswahl und Nutzung von Outsourcing-Angeboten aus Sicht der Informationssicherheit behandelt. Zu jeder Lebenszyklusphase eines Outsourcing-Projektes werden hier Maßnahmen aufgeführt, mit deren Umsetzung ein angemessenes Sicherheitsniveau erreicht werden kann. Da die Maßnahmen und Empfehlungen auf unterschiedlichste Outsourcing- Projekte anwendbar sind, sind sie zum Teil generisch gehalten. Unterschiede zu klassischem Outsourcing Cloud-Dienste weisen einige Besonderheiten auf, die sie vom klassischen Outsourcing unterscheiden und die im Folgenden kurz dargestellt werden. Während Outsourcing-Vorhaben meist einen kompletten Geschäftsprozess oder zumindest wesentliche Elemente eines Geschäftsprozesses umfassen, können Cloud-Services auch für kleinere Teile eines Geschäftsprozesses genutzt werden. Geht es um einen Cloud-Service, der nur einen Teil eines Geschäftsprozesse abbildet, so werden die erforderlichen Sicherheitsaspekte schnell nicht ernst genug genommen und daher vernachlässigt. In einer Public Cloud wird ein Service vielen Kunden zur Verfügung gestellt, die die zugrunde liegende Infrastruktur gemeinsam nutzen. Deshalb sind die angebotenen Services hoch standardisiert und in der Regel nur sehr begrenzt an individuelle Anforderungen anpassbar. Dem gegenüber steht die hohe Flexibilität der Cloud-Services, die sich rasch an den Bedarf anpassen lassen. Sollen nur Teile eines Geschäftsprozesses in die Cloud verlagert werden, wird dies in Institutionen häufig nur als kleines Projekt betrachtet. Daher stehen oft zu wenig Ressourcen im Vorfeld bereit, um zu einer fundierten Entscheidung über den Einsatz zu kommen, obwohl der Ausfall von kleinen Teilen eines Geschäftsprozesses auch drastische Auswirkungen haben kann. Da der Markt rund um Cloud-Computing im Moment noch sehr dynamisch ist und immer neue Anbieter und Angebote hinzukommen, möchten sich viele Kunden nicht auf langfristige Verträge einlassen, sondern beim Erscheinen besserer oder günstigerer Angebote den Anbieter wechseln können. Wenn Kunden hoch komplexe Cloud-Services nutzen, ist diese Möglichkeit natürlich eingeschränkt, aber bei Cloud-Angeboten wie Speicherdiensten ist ein Wechsel des Anbieters meistens relativ einfach. Dies wird auch dadurch erleichtert, dass solche Cloud-Services häufig einfach über ein sogenanntes Self-Service-Portal gebucht werden können. Was bleibt gleich? Informationssicherheit! Risikoanalyse! Unabhängig von der Art eines Outsourcing-Vorhabens gilt, dass nur eine Institution, die den Wert ihrer Daten kennt, entscheiden kann, ob für diese die Nutzung eines Cloud-Services vertretbar ist. Wird eine Institution, die nur über ein sehr rudimentäres Informationssicherheitsmanagement verfügt, mit der Frage konfrontiert, ob ein Cloud-Service für ihre Daten ausreichend sicher ist, kann sie hierüber keine fundierte Aussage treffen. Dies führt dann häufig zu Aussagen wie Der Cloud-Anbieter hat bestimmt eine bessere Informationssicherheit wie wir! und Ich will 100%-ige Sicherheit für meine Daten! das ist entweder blauäugig oder unrealistisch. Ohne den Wert der Informationen zu kennen, die in die Cloud ausgelagert werden sollen, gehen Institutionen ein unkalkulierbares Risiko ein. Daher müssen vor jeder Cloud-Nutzung zunächst deren potenzielle Auswirkungen auf die betroffenen Informationen, Geschäftsprozesse sowie den internen Informationsverbund untersucht werden. Dadurch können die Überlegungen zur Cloud-Nutzung auch den Synergieeffekt haben, dass sich Institutionen ernsthaft mit der eigenen Informationssicherheit beschäftigen. Als nächster Schritt folgt dann eine Analyse der Risiken der Cloud- Nutzung. Hier ist nun der CSP gefragt, der sein System kennen und bereit sein muss, die umgesetzten Sicherheitsmaßnahmen zu kommunizieren. Nur so können seine Kunden eine aussagekräftige Risikoanalyse durchführen. Verträge mit Cloud-Anbietern Im Vertrag mit dem jeweiligen CSP wird alles geregelt, was mit der Erbringung der Leistung und deren Bezahlung zusammenhängt. Meistens sind nicht alle Regelungen im SLA enthalten, sondern sie können auch in den allgemeinen Geschäftsbedingungen (AGB) oder einer Produktbeschreibung festgehalten sein. Im Folgenden werden verschiedene Punkte aufgezählt, die eine Relevanz für die Sicherheit haben, unabhängig davon, ob sie direkt im SLA adressiert werden oder in einem anderen Teil des Vertrags. BSI 53133 Bonn <kes> 2012 # 5 37

SLAs für Cloud-Computing Beschreibung der angebotenen Dienste im SLA Das Service-Level-Agreement (SLA) soll die angebotenen Services und deren Leistungseigenschaften genau und soweit möglich quantifiziert beschreiben. Idealerweise nimmt es dabei stark auf die Kundenbedürfnisse Rücksicht. Dies kann zum Beispiel durch folgende Punkte erreicht werden: Im SLA sollten grundlegende Begriffe geklärt sein. So kann beispielsweise die Definition von Verfügbarkeit sehr unterschiedlich sein und gravierende Auswirkungen auf die Nutzung des Service haben. Komplexitäten sollten aufgelöst und so beschrieben sein, dass der Kunde den Inhalt verstehen und richtig interpretieren kann. Produktbezeichnungen des CSP, die nicht klar erklärt sind, sollten im SLA nicht vorkommen. Übertriebene Erwartungen des Kunden sollten weder gefördert noch stillschweigend hingenommen werden, da daraus nur Konflikte und Unzufriedenheit auf Kundenseite entstehen. In einem klar geschriebenen SLA wird deutlich, welchen Umfang die angebotene Dienstleistung hat. So kann bei einer Analyse des SLA festgestellt werden, ob es offene Punkte gibt, die nicht geregelt sind. Diese können dann entweder noch adressiert werden oder aber das SLA zeigt Wege und Möglichkeiten auf, wie Konflikte zwischen den Vertragsparteien gelöst werden können. SLA-Typen Cloud-Services sind in der Regel hochstandardisiert, da sie intern oder extern mehreren Abnehmern angeboten werden. Dies spiegelt sich auch in den SLAs wider. Bei der Nutzung von kostenfreien Public-Cloud- Services liegt oft überhaupt kein SLA zugrunde, da sich der CSP zu nichts verpflichtet, sondern sich im Gegenteil zum Teil Rechte an den gespeicherten und verarbeiteten Daten der Kunden zusichern lässt. Was im privaten Umfeld akzeptabel erscheinen mag, ist allerdings im Geschäftsumfeld nicht tragbar. Daher müssen die Geschäftsbedingungen unbedingt darauf gesichtet werden, welche Rechte bei der Nutzung der Cloud-Dienste dem Anbieter übertragen werden. Cloud-Services für Geschäftskunden basieren auf konkreten Service-Levels, die der Anbieter garantiert. Im Wesentlichen können drei Modelle unterschieden werden: Nicht-verhandelbare SLAs: Der CSP gibt einen bestimmten Service-Level vor, also eine Güteklasse, in der der Service angeboten wird. Sicherheitsmaßnahmen sind nur soweit erwähnt, wie der CSP dies für notwendig hält. Nicht-verhandelbare SLAs mit verschiedenen Qualitätsstufen: Um den Kunden einen möglichst optimalen Service anbieten zu können, stellen CSPs oft einen Service in unterschiedlichen Güteklassen zu unterschiedlichen Preisen zur Verfügung. Die Stufen unterscheiden sich in der Regel nicht in der Funktionalität, sondern in Performance, Verfügbarkeit und auch bei den Sicherheitsmaßnahmen. Verhandelbare SLAs: Da auf einzelne Kunden angepasste Dienstleistungen für den Anbieter einen höheren Aufwand bedeuten, sind die SLAs nur bei größeren Cloud-Projekten verhandelbar. Hier sind in einem weit höheren Umfang Sicherheitsziele vereinbar. Rechtliches Da viele CSPs in anderen Ländern und damit anderen Rechtsräumen ihren Sitz haben, ist es wichtig, die rechtlichen Rahmenbedingungen in den Verträgen genau zu definieren. Hierzu gehört unter anderem zu klären, welches Recht anwendbar ist und wo in einem Streitfall der Gerichtsstand ist. Für den Cloud-Nutzer ist es meist sehr schwierig, hier seine eigene Position gegenüber dem CSP durchzusetzen, da dieser nicht für alle Länder, in denen die angebotenen Services genutzt werden, individuell an den Rechtsraum angepasste Verträge vorhalten will. Es ist hilfreich, wenn das SLA in der Landessprache des Kunden (z. B. Deutsch) abgefasst ist und der Gerichtsstandort im Heimatland des Kunden (z. B. Deutschland) liegt, da der Cloud-Kunde dann in der Regel auf seine eigenen Rechtsberater zurückgreifen kann. Im Vertrag sollten zudem der Geltungsbereich und die Geltungsdauer vereinbart werden. Wichtig ist auch, dass der Cloud-Anbieter sich verpflichtet, jeweils relevante vertragliche Bestimmungen an seine Subunternehmer weiterzugeben. Es sollte auch klar geregelt werden, welche Rechte und Pflichten sowohl aufseiten des CSP als auch aufseiten des Kunden liegen, wobei die Pflichten des Service Providers in der Regel schon durch die Beschreibung des angebotenen Services und dessen Leistungseigenschaften definiert sind. Informationssicherheit Beim Abschluss eines SLA mit einem Cloud- Service-Provider sind neben der Beschreibung der Services, des Leistungsumfangs und den rechtlichen Verhältnissen auch Punkte der Informationssicherheit zu berücksichtigen, die hier ausgeführt werden. 38 BSI 53133 Bonn <kes> 2012 # 5

CSPs handeln, was Informationen und Zusagen zur Informationssicherheit betrifft, sehr unterschiedlich. Erhält ein Cloud-Kunde für seine Risikoanalyse keine ausreichenden Informationen vom CSP, so muss er einem konservativen Ansatz folgend davon ausgehen, dass der CSP keine Sicherheitsmechanismen umgesetzt hat oder diese so schwach sind, dass er sie nicht beschreiben will. Festzustellen ist demgegenüber auch, dass CSPs, deren Informationssicherheitsniveau hoch ist, in der Regel darüber auch konkrete Informationen herausgeben, zumindest nach Unterzeichnung einer Vertraulichkeitsvereinbarung, um sich so einen Wettbewerbsvorteil zu verschaffen. Empfehlungen für SLAs Die folgende Zusammenstellung nennt die aus der Sicht der Informationssicherheit wichtigsten Themen und gibt Empfehlungen für die Vertragsgestaltung. Sicherheitsmanagement beim Cloud-Service- Provider Die IT beim CSP sollte prozessorientiert aufgebaut und betrieben sein (z. B. nach ITIL/ISO 20000 oder Co- BIT), was sich an einzelnen Prozessen nachweisen lassen sollte. Beispielsweise könnte hinterfragt werden, ob es die Prozesse Change-Management oder User-Help-Desk gibt. Dies gilt wie auch die folgenden Punkte ebenfalls für Subunternehmer, die der CSP wesentlich zur Erbringung der Leistung nutzt. Der Cloud-Service-Provider sollte zusichern, dass er ein Informationssicherheits-Management-System (z. B. nach IT-Grundschutz oder ISO/IEC 27001) betreibt, das den angebotenen Cloud-Service vollständig umfassst. Der CSP sollte einen Ansprechpartner für Sicherheitsfragen und dessen Erreichbarkeit benennen. Es sollte vereinbart werden, dass der Kunde benachrichtigt wird, wenn sich beim Anbieter Änderungen im Sicherheitsmanagement ergeben. Sicherheitsüberprüfung und -nachweis Der Cloud-Anbieter sollte sich verpflichten, regelmäßig die Umsetzung seiner Sicherheitsmaßnahmen durch interne oder externe Audits zu überprüfen. Dazu können zum Beispiel regelmäßige Penetrationstests und auch unabhängige Sicherheitsrevisionen durchgeführt werden. Im SLA sollte festgelegt werden, inwieweit der Kunde die Ergebnisse dieser Audits und Penetrationstests einsehen kann, wobei hier nicht nur der Kundenwunsch nach umfassender Information, sondern auch die Sicherheit des Anbieters selbst zu beachten ist. Bei einem erhöhten Schutzbedarf der Daten und Anwendungen sollten sich die Kunden das erreichte Sicherheitsniveau beim Anbieter über eine Zertifizierung nachweisen lassen. Hierbei muss genau darauf geachtet werden, ob die Zertifizierung auch den für den Kunden interessanten Teil des Leistungsangebotes abdeckt, von einer anerkannten Zertifizierungsstelle durchgeführt wurde und die Ergebnisse nachvollziehbar sind. Je nach Art der Geschäftsprozesse oder Daten, die in die Cloud ausgelagert wurden, kann es erforderlich sein, dass der Cloud-Anbieter dem Kunden ein Prüfrecht gewährt oder diesem das Testat eines unabhängigen Prüfers vorlegen kann. Dies ist beispielsweise bei der Verarbeitung von personenbezogenen Daten nach 11 BDSG gefordert. In der Regel sollten potenzielle Kunden davon ausgehen, dass ein Anbieter, der ein funktionierendes Sicherheitsmanagement hat, darüber qualifiziert Auskunft geben kann und auch gibt. Verweigert ein Anbieter hier belastbare Aussagen, sollten Kunden ihm ihre Daten nicht anvertrauen, zumindest wenn diese auch nur im Ansatz sensitiv oder geschäftsrelevant sind. Transparenz und Kommunikation Eine transparente Kommunikation zwischen einem Cloud-Anbieter und seinen Kunden stärkt das gegenseitige Vertrauen. Hierzu zählt beispielsweise die regelmäßige Unterrichtung über Änderungen (organisatorisch, fachlich, technisch und finanziell) bei der Erbringung des Service. Der Cloudanbieter sollte auch die Standorte seiner Rechenzentren und seiner Subunternehmer offenlegen. Auch die Rechts- und Besitzverhältnisse des Cloud-Anbieters können für den Kunden wichtig sein, auch wenn diese Fakten nicht Gegenstand der Verträge sind. Zudem sollte klargestellt sein, welchen staatlichen Eingriffen sich der CSP unterwerfen muss, welche die Informationen des Kunden betreffen. Im Vertrag sollte des Weiteren vereinbart werden, wie Veränderungen des Vertragsgegenstands kommuniziert und abgestimmt werden (Change-Request-Verfahren). Dies beinhaltet auch Änderungen, die die Sicherheit des Cloud-Service betreffen. Personal Das Personal des Cloud-Anbieters sollte auf Einhaltung des Datenschutzes, der Sicherheitsmaßnahmen und der Wahrung der Vertraulichkeit der Kundendaten verpflichtet werden. Außerdem muss das Personal nicht nur für den IT-Betrieb geschult, sondern auch für Datenschutz und Informationssicherheit sensibilisiert werden. Der Kunde sollte sich die hierzu ergriffenen Maßnahmen bezüglich personeller Sicherheit der CSP-Mitarbeiter beschreiben lassen. BSI 53133 Bonn <kes> 2012 # 5 39

SLAs für Cloud-Computing Rechenzentrumssicherheit Die Erbringung der Cloud-Dienste findet letztendlich immer in einem oder mehreren Rechenzentren (RZ) statt. Deshalb muss auf die Sicherheit dieser Rechenzentren ein besonderes Augenmerk gelegt werden. Explizit sollte zugesichert werden, dass die wichtigsten Infrastruktur-Komponenten der genutzten Rechenzentren (wie Strom, Kühlung, Netz, Internetanbindung etc.) redundant ausgelegt sind, mit möglichst konkreten Aussagen zu den ergriffenen Maßnahmen. Es muss sichergestellt sein, dass nur befugte Personen die Rechenzentren betreten können und dass ausreichende Brandschutzmaßnahmen und andere Sicherheitsmaßnahmen gegen Elementarmächte umgesetzt sind. Bei sehr hohen Kundenanforderungen an die Verfügbarkeit sollte der CSP redundante Rechenzentren anbieten können. Die meisten RZ-Betreiber lassen ihre Rechenzentren zertifizieren, sodass die obigen Forderungen einfach zu erfüllen sein sollten. Vor allem in diesem Bereich sollten Kunden darauf achten, dass seriöse Zertifizierungen vorliegen, also nur solche, die von anerkannten Zertifizierungsstellen auf der Basis von nachvollziehbaren Kriterien durchgeführt wurden. Auch wenn ein CSP kein eigenes Rechenzentrum betreibt (z. B. als SaaS-Anbieter), muss er auf jeden Fall Auskunft über die Sicherheit der genutzten Rechenzentren geben. In diesem Fall ist es wichtig zu erfahren, ob der SaaS- oder PaaS-Anbieter auf Rechenzentren verschiedener Anbieter zurückgreift beziehungsweise häufiger die Rechenzentrenanbieter wechselt (z. B. über einen Cloud- Broker, der die aktuell günstigsten Angebote ermittelt). In letztem Fall scheint es sehr unwahrscheinlich, dass der CSP belastbare Aussagen über die RZ-Sicherheit machen kann. Netzsicherheit Im Vertrag sollten angemessene Maßnahmen benannt werden, um eine ausreichende Netzsicherheit zu erreichen. Vor allem bei sehr hohen Zusagen zur Verfügbarkeit sind Sicherheitsmaßnahmen wie Intrusion- Detection- oder Intrusion-Prevention-System und andere Maßnahmen zur Abwehr von Denial-of-Service-Angriffen auf Netzebene im Vertrag zu erwähnen. Systemsicherheit und sicherer Systembetrieb Auch der Cloud-Service selbst muss angemessen abgesichert sein, also so, dass das Sicherheitsniveau dem Schutzbedarf der damit verarbeiteten Informationen entspricht. Im Fokus steht hier oft die Verfügbarkeit des Service, da diese einfach quantifizierbar und daher meist ein entsprechender Wert im SLA vereinbart wird. Der Cloud-Anbieter sollte im Vertrag benennen, welche Maßnahmen er zur Erreichung der gewährleisteten Verfügbarkeit umgesetzt hat. Der Cloud-Anbieter sollte im Vertrag außerdem beschreiben, wie die Systemsicherheit aufrecht erhalten wird. Für Leistungen oberhalb der Betriebssystemebene muss dies mindestens die Themen Patchmanagement und Virenschutz umfassen, wobei beim Patchmanagement vor allem wichtig ist, ob und wie die Patches vor dem Einspielen in den Wirkbetrieb getestet werden. Es muss ein dem Kunden rechtzeitig bekannt gegebener Zeitplan für das Einspielen der Patches und Updates existieren. Inzwischen spielen einige SaaS-Anbieter zum Teil mehrmals täglich neue Patches ein, was in der Regel keine Auswirkung auf die Dienste hat. In diesem Fall, da schwerlich ein Zeitplan vorgelegt werden kann, sollte der CSP die gewählte Vorgehensweise und vor allem die Sicherheitsaspekte dieses Verfahrens erläutern. Im Vertrag sollte außerdem beschrieben werden, wie die verschiedenen Mandanten auf den IT-Systemen des CSP voneinander getrennt werden. Die Nennung weiterer Schutzmaßnahmen wie Systemhärtung und Minimalprinzip können das Vertrauen in den Anbieter steigern. Mandantentrennung Die saubere Trennung von Mandanten ist bei Cloud-Diensten ein zentraler Sicherheitsaspekt, da in der Regel die Ressourcen der IT-Systeme des Anbieters von verschiedenen Kunden gemeinsam genutzt werden. Diese Ressourcen wie CPU, Arbeitsspeicher, Datenspeicher und Netze werden den Cloud-Services meist in virtualisierter Form bereitgestellt, wodurch die Trennung der Mandanten gewährleistet wird. Hier sollte der CSP Auskunft über die verwendeten Mechanismen geben, vor allem bei der Server- und Speichervirtualisierung. Lebenszyklus der Daten Es sollten Vereinbarungen bezüglich der Informationssicherheit im Lebenszyklus der Daten (z. B. Verschlüsselung sensitiver Daten unter vollständiger Schlüsselkontrolle des Kunden) und der sicheren Isolierung von Daten sowie der Datensicherung und Datenrücksicherung getroffen werden. Ein weiteres wichtiges Thema ist, wie die Kundendaten beim Anbieter wieder zuverlässig gelöscht werden. Da bei Cloud-Diensten die Daten typischerweise vielfach redundant gespeichert werden, ist es häufig schwierig, einen Datensatz zu einem Zeitpunkt vollständig und unumkehrbar zu löschen. Der Cloud-Anbieter sollte daher 40 BSI 53133 Bonn <kes> 2012 # 5

beschreiben, welche Maßnahmen er ergreift, um Daten und Datenträger zuverlässig zu löschen beziehungsweise deren weitere Verwendung zu verhindern. Diese Regelungen müssen auch Datensicherungen und Archivdaten einbeziehen. Absicherung der Kommunikation Die Datenübertragung vom Kunden zum Cloud- Anbieter sollte unbedingt verschlüsselt erfolgen, wenn sensitive Informationen enthalten sein könnten. Im SLA sollten daher Vereinbarungen darüber getroffen werden, wie Datenübertragung verschlüsselt wird und wie die Schlüsselverwaltung beim CSP geregelt ist. Der Cloud-Anbieter sollte die eingesetzten Maßnahmen und Verfahren zur Absicherung der Kommunikation nennen, inklusive der eingesetzten kryptografischen Verfahren und Schlüssellängen. Eine Vereinbarung, dass nach Absprache zwischen CSP und Kunde die verwendeten kryptografischen Verfahren und Schlüssellängen bei Bedarf an den Stand der Technik angepasst werden, sollte nicht fehlen. Identitäts- und Berechtigungsmanagement Damit keine Unbefugten auf die Kundendaten zugreifen können, müssen verschiedene Maßnahmen zum Zugriffsschutz getroffen werden. So sollten nur die Mitarbeiter des Auftraggebers auf die Dienstleistungen des CSP zugreifen können, zu deren Aufgabengebiet dies gehört. Daher muss die Vergabe von Berechtigungen klar zwischen Cloud-Anbieter und Kunde geregelt sein. Auf beiden Seiten sind hierfür Ansprechpartner zu benennen, die Berechtigungen vergeben und ändern können. Aber auch Sperrmöglichkeiten von Benutzeraccounts müssen beschrieben sein. Ebenso ist zu klären, welche Mitarbeiter des CSP unter welchen Rahmenbedingungen auf die Mandantensysteme beim CSP zugreifen können. Auf das Cloud- Angebot sollte kein Nutzer ohne erfolgreiche Authentifizierung zugreifen können der Cloud-Anbieter sollte hierfür angemessene Mechanismen zur Verfügung stellen. Je nach Schutzbedarf der Kunden bieten viele CSPs auch unterschiedlich starke Authentisierungsmechanismen an. Die Art und Stärke der Mechanismen zur Authentifizierung der Cloud-Nutzer, aber auch der Administratoren beim CSP, sollten im SLA beschrieben sein. Im Vertrag sollte zudem vereinbart werden, wer sowohl aufseiten des Anbieters als auch aufseiten des Kunden für die Vergabe von Nutzer-Rechten und die Erstellung, Verwaltung und Löschung von Benutzerkonten verantwortlich ist. Sofern für den betreffenden Dienst relevant, sollte der Cloud-Anbieter außerdem beschreiben, welche Mechanismen zur sicheren Identifizierung der Cloud-Nutzer eingesetzt werden. Monitoring und Incident-Management Die Überwachung und Entstörung der Cloud- Umgebung sollte im SLA geregelt werden. Dies umfasst die Detektion von Störungen und Angriffen auf die Cloud-Umgebung und die Durchführung entsprechender Gegenmaßnahmen (inklusive Eskalationsregelungen) sowie die Vereinbarungen über regelmäßige Auswertungen (z. B. Verfügbarkeit, fehlgeschlagene Authentifizierungsversuche). Im Vertrag sollte vereinbart werden, wie der CSP den Cloud-Nutzer über Sicherheitsvorfälle informiert (Fristen, Kommunikationswege, Ansprechpartner). Andererseits sollte auch festgeschrieben sein, wie der Cloud-Nutzer Störungen beim Cloud-Anbieter melden und eskalieren kann (Fristen, Kommunikationswege, Ansprechpartner). Nicht nur die Erreichbarkeit, sondern auch die Antwortzeiten auf Anfragen und Störungsmeldungen sollten zumindest als Richtwert festgeschrieben sein. Dies sollte auch für die Reaktions- und Behebungszeiten von Störungen getan werden. Notfallmanagement Der Cloud-Anbieter sollte ein Notfallmanagement (möglichst nach einem etablierten Standard wie BSI 100-4 oder BS 25999) beschreiben und nachweisen, dass regelmäßig angemessene Notfalltests durchgeführt werden. Service-Kennzahlen Ein Schwerpunkt jedes SLA ist, neben der Beschreibung des Service, die Festlegung der vereinbarten Kennzahlen, anhand derer ein Cloud-Kunde die Qualität des Cloud-Service messen kann. Deshalb ist im Vertrag grundsätzlich zu vereinbaren, wie die Qualitätsmerkmale des Cloud-Service überwacht, gemessen und an den Cloud-Kunden berichtet werden. Da die Bezahlung des Service häufig auch von der Erreichung der Servicequalität abhängt, ist dies ein sehr wichtiger Punkt. Qualitätsmerkmale, die je nach Service häufig vereinbart werden, sind: Die Verfügbarkeit des Dienstes ist in vielen Fällen der einzige Messwert, der in SLAs angegeben wird. Hier ist es notwendig, dass die Angaben auf einen Zeitraum (z. B. pro Monat) bezogen sind. Ein Hinweis, ob geplante Servicezeiten inkludiert sind oder nicht, sollte ebenfalls vorhanden sein. Außerdem ist festzuhalten, wo gemessen wird: Zu bevorzugen sind hier Messungen, die möglichst nah beim Cloud-Nutzer liegen, mindestens jedoch am Netzzugangspunkt des Rechenzentrums. BSI 53133 Bonn <kes> 2012 # 5 41

SLAs für Cloud-Computing Der CSP sollte die Service-Zeiten beziehungsweise Zeiten, an denen der Service wegen geplanter Wartungsarbeiten nicht zur Verfügung steht, angeben einerseits ist das die Dauer pro Zeitraum (z. B. Stunden pro Quartal) und zum anderen das genaue Datum und Uhrzeit. Für weiter in der Zukunft liegende Wartungszeiten sollte im SLA niedergelegt sein, wie lange vorab und auf welchem Kommunikationsweg der Kunde darüber informiert wird. Diese Zeiten gehen meist in die Berechnung der Verfügbarkeit nicht ein. Das Antwortzeitverhalten des Dienstes sollte mit möglichst genauen Angaben zur Art der Messung (siehe Verfügbarkeit) vereinbart werden besonders bei Services, bei denen es auf eine schnelle Antwort ankommt. Wird eine hohe Elastizität gefordert, ist festzulegen, wie viele Benutzer beim Cloud-Kunden gleichzeitigen Zugriff auf den Service haben können und wie und in welchem Zeitraum diese Grenze nach oben und unten verschoben werden kann. Vorlaufzeiten für die Bereitstellung neuer oder erweiterter Dienste sind festzulegen (z. B. um neue Benutzer hinzufügen). Leider lässt sich auch beobachten, dass manche CSPs höhere Verfügbarkeiten angeben, als sie erreichen können. Dies kann sich für den CSP rechnen, da in der Regel keine Strafzahlungen oder Haftungsverpflichtungen seitens des CSP festgelegt sind, wenn die vereinbarten Qualitätsmerkmale nicht erreicht werden. Stattdessen werden nicht erreichte Ziele leider meist nur mit einer Kompensation in Form von unentgeltlicher Nutzung des Service für eine bestimmte Zeit ausgeglichen. Fazit Von Cloud-Service-Providern, die sich um Kunden im unternehmerischen und behördlichen Umfeld bemühen, können die Kunden einiges fordern, was die Vertragsgestaltung angeht. Die Überprüfung einiger SLAs hat gezeigt, dass die oben genannten Forderungen keineswegs unrealistisch sind, sondern dass Anbieter diese Informationen und Zusagen auch gewähren dies hängt natürlich von der Art des angebotenen Cloud-Service ab und ob der CSP ein verhandelbares SLA oder zumindest verschiedene Leistungsstufen anbietet. Insbesondere Provider, die auf institutionelle Kunden setzen, werden das Sicherheitsbewusstsein der Kunden ernst nehmen und qualifizierte sowie nachprüfbare Sicherheitsmaßnahmen ergreifen und diese Informationen dem Kunden auch zugänglich machen. Dabei geht es nicht darum, dass der Cloud-Anbieter alle Sicherheitsmaßnahmen offenlegen muss. Aber die Sicherheitsmaßnahmen müssen zumindest soweit beschrieben sein, dass der Kunde auf dieser Basis eine Risikoanalyse erstellen kann, um das Angebot angemessen prüfen zu können. Literatur [1] BSI, Sicherheitsempfehlungen für Cloud-Computing Anbieter, 2011, www.bsi.bund.de/de/themen/cloud- Computing/Eckpunktepapier/Eckpunktepapier_node. html [2] NIST Special Publication 800-144, Guidelines on Security and Privacy in Public Cloud Computing, 2011, http:// csrc.nist.gov/publications/nistpubs/800-144/sp800-144. pdf [3] Cloud Security Alliance CSA, Security Guidance For Critical Areas Of Focus In Cloud-Computing V3.0, 2011, www.cloudsecurityalliance.org/guidance/csaguide. v3.0.pdf [4] BITKOM, Cloud-Computing Evolution in der Technik, Revolution im Business, Leitfaden, www.bitkom.org/ files/documents/bitkom-leitfaden-cloudcomputing_ Web.pdf [5] Cloud-Computing Use Cases A white paper produced by the Cloud-Computing Use Case Discussion Group, Version 4.0, 2010, http://opencloudmanifesto. org/cloud_computing_use_cases_whitepaper-4_0.pdf [6] EuroCloud, Leitfaden Recht, Datenschutz & Compliance, www.eurocloud.de/2010/12/02/eurocloud-leitfaden-recht-datenschutz-compliance/ [7] BSI, Protection Level Agreements, 2010, www.bsi. bund.de/shareddocs/downloads/de/bsi/soa/pla_studie.pdf? blob=publicationfile [8] ENISA, Survey and analysis of security parameters in cloud SLAs across the European public sector, 2011, www.enisa.europa.eu/activities/application-security/ cloud-computing/survey-and-analysis-of-security-parameters-in-cloud-slas-across-the-european-public-sector/ at_download/fullreport [9] BSI, IT-Grundschutz-Kataloge, 2012, www.bsi.bund. de/grundschutz 42 BSI 53133 Bonn <kes> 2012 # 5

Amtliche Mitteilungen BSI Forum Amtliche Mitteilungen 1. Im Vergleich zur letzten Ausgabe dieser amtlichen Mitteilungen sind inzwischen folgende Zertifizierungen des BSI gemäß Common Criteria und ITSEC abgeschlossen worden: Hersteller/Vertreiber Produkt Produkt-Typ Ergebnis ID Zertifizierungsdatum NXP Semiconductors NXP Smart Card Controller Smartcard Controller BSI-DSZ-CC-0466-2008- Germany GmbH P5CC037V0A with specific IC MA-02 Dedicated Software 2012-07-31 NXP Semiconductors NXP Smart Card Controller Smartcard Controller BSI-DSZ-CC-0465-2008- Germany GmbH P5CC037V0A with specific IC MA-02 Dedicated Software 2012-07-31 NXP Semiconductors NXP Smart Card Controller Smartcard Controller BSI-DSZ-CC-0464-2008- Germany GmbH P5CC024V0A, P5CC020V0A, MA-02 P5SC020V0A and P5CC012V0A each 2012-07-31 with specific IC Dedicated Software Infineon Infineon Security Controller M7892 B11 Smartcard Controller BSI-DSZ-CC-0758-2012- Technologies AG with optional RSA2048/4096 v1.02.013, MA-01 EC v1.02.013, SHA-2 v1.01 and Toolbox 2012-07-27 v1.02.013 libraries and with specific IC dedicated software (firmware) Frequentis Secure Audio Switch (ISAS), Netzwerk- und EAL 4+ Nachrichtentechnik Version 1.0 Kommunikations- BSI-DSZ-CC-0619-2012 GmbH produkt 2012-07-27 Infineon Infineon smartcard IC Smartcard Controller EAL 4+ Technologies AG (Security Controller) M7794 A12 with BSI-DSZ-CC-0814-2012 optional RSA2048/4096 v1.02.013, 2012-07-26 EC v1.02.013 and Toolbox v1.02.013 IBM Corporation IBM DB2 Version 9.1 for z/os Datenbankserver EAL 4+ Version 1 Release 10 BSI-DSZ-CC-0622-2012 2012-07-20 Continental Digital Tachograph DTCO 1381, Fahrtenschreiber E3 /hoch Automotive GmbH Release 1.3v BSI-DSZ-ITSEC- 0834-2012 2012-06-04 Bundesdruckerei Bundesdruckerei Document Anwendungssoftware BSI-DSZ-CC-0794- GmbH Application Version 1.1.1104 zum Auslesen von 2011-MA-01 elektronischen 2012-07-09 Ausweisdokumenten IBM Corporation IBM Tivoli Access Manager for Serveranwendungen EAL 4+ e-business version 6.1.1 FP4 with BSI-DSZ-CC-0636-2012 IBM Tivoli Federated Identity Manager 2012-06-22 version 6.2.1 FP2 BSI 53133 Bonn <kes> 2012 # 5 43

Amtliche Mitteilungen Hersteller/Vertreiber Produkt Produkt-Typ Ergebnis ID Zertifizierungsdatum Utimaco Safeware AG SafeGuard Enterprise Device PC-Sicherheit EAL 4 Encryption, Version 5.60 for Microsoft BSI-DSZ-CC-0553-2012 Windows XP Professional and 2012-06-18 Microsoft Windows 7 NXP Semiconductors NXP Secure Smart Card Controllers Smartcard Controller BSI-DSZ-CC-0555-2009- Germany GmbH P5CD016/021/041/051V1A and MA-02 P5Cx081V1A 2012-06-04 Anmerkung: Die zugehörigen Zertifizierungsreporte mit Zertifikaten sind auf der Web-Seite www.bsi.bund.de/zertifizierungsreporte einzusehen. 2. Im Vergleich zur letzten Ausgabe dieser amtlichen Mitteilungen ist inzwischen für folgende Produkte eine Zertifizierung beantragt worden: Antragsteller Produktname Produkttyp Zertifizierungs-ID F5 Networks, Inc. F5 Networks BIG-IP Local Traffic Netzwerk- und BSI-DSZ-CC-0856 Manager Release 11.3.0 plus the Kommunikationsprodukt APM, ASM, and Data Center Firewall Modules; and BIG-IP Edge Gateway Release 11.3.0. SUSE Linux SUSE Linux Enterprise Server 11 Betriebssystem BSI-DSZ-CC-0852 Products GmbH Service Pack 2 for IBM System z (s390x) Red Hat, Inc. Red Hat Enterprise Linux, Betriebssystem BSI-DSZ-CC-0848 Version 6.2, Operating System for IBM System z and IBM System p Dell Inc, USA Dell Compellent Storage Center, Enterprise Manager BSI-DSZ-CC-0847 Version 6.0.3, and Enterprise Manager Version 5.5.4 Navayo Technologies AG MVCN Core, Version 2.0 Netzwerk- und BSI-DSZ-CC-0843 Kommunikationsprodukt IBM Corporation Tivoli Security Policy Manager 7.1 Security BSI-DSZ-CC-0839 Policy Management Anmerkungen: Eine Veröffentlichung dieser Angaben erfolgt hier nur, sofern der Antragsteller damit einverstanden ist und die Evaluierung begonnen wurde. In der Liste vorhandene Nummerierungslücken betreffen beantragte Zertifizierungen, für die die genannten Voraussetzungen fehlen. Bei einigen Produkten handelt es sich um eine Re-Zertifizierung eines bereits zertifizierten Produktes wegen Änderungen am Produkt oder Wechsel der Prüfkriterien. 44 BSI 53133 Bonn <kes> 2012 # 5

3. Vom BSI erteilte Standortzertifikate Antragsteller Entwicklungs-/Produktionsstandorte ID gültig bis Ausstellungsdatum Trueb AG, Switzerland Trueb AG, Locations Aarau and Unterentfelden BSI-DSZ-CC-S-0011-2012 2014-06-04 2012-06-05 4. Vom BSI erteilte ISO-27001-Zertifikate auf der Basis von IT-Grundschutz Zertifikatsnummer Institution Untersuchungsgegenstand gültig bis BSI-IGZ-0118-2012 ekom21-kgrz Der Untersuchungsgegenstand umfasst die informationstech- 2015-07-12 Hessen nischen Anlagen und Lösungen der ekom21 KGRZ Hessen an den Standorten Darmstadt, Gießen und Kassel, die zur Erbringung der ASP-Dienstleistungen erforderlich sind. Betrachtet wird die IT-Infrastruktur an den drei Standorten, die zur Erfüllung der Aufgaben dient. Nicht Gegenstand der Untersuchung sind ASP-Dienste, die auslaufenden Charakter haben und deshalb für die Restlaufzeit outgesourct wurden. Als kommunales IT-Dienstleistungsunternehmen in Hessen hat sich die ekom21 KGRZ Hessen auf Komplettlösungen für den öffentlichen Dienst spezialisiert und ist Full-Service-Partner für die öffentliche Verwaltung. BSI-IGZ-0109-2012 Kommunale Beim Untersuchungsgegenstand handelt es sich um Server 2015-06-20 Informations- Hosting, -Housing, Remote Access, sowie Internet und E-Mail verarbeitung Anbindung, die von der Kommunalen Informationsverarbei- Baden-Franken tung Baden-Franken mit Hauptsitz in Karlsruhe für Kommunen, Stadt und Landkreise und sonstige Körperschaften des öffentlichen Rechts in Baden-Württemberg angeboten wird. Die dafür erforderlichen IT-Systeme werden durch infrastrukturelle, organisatorische, personelle und technische Geschäftsprozesse unterstützt. BSI-IGZ-0113-2012 Interoute Der Geltungsbereich des Informationsverbunds umfasst den 2015-05-20 Germany Service Colocation und das Management Netzwerk welches GmbH zur Erbringung der Services Hosting im Rahmen der Interoute Services bei unternehmenskritischen Anwendungen im Kundenauftrag eingesetzt wird. Das Management Netzwerk wird von der Interoute Germany GmbH an den Standorten Berlin und Kleinmachnow erbracht. Die Gebäudemanagementsysteme werden für den Standort Kleinmachnow von der Interoute Germany GmbH erbracht und am Standort Berlin durch den Outsourcing Partner e-shelter erbracht. Zur Aufgabenerfüllung werden zusätzlich Services im Rahmen eines Outsourcing in Anspruch genommen. Backup, Monitoring von Critical Alerts im Kundenauftrag sowie Installation und Wartung der lokalen Systeme für den Bereich der Administratoren erfolgt durch Interoute Czech s.r.o. Für den Standort Berlin wird das Rechenzentrum eines Housing Dienstleisters genutzt. Nicht zum Informationsverbund gehören die Komponenten, die über das Management Netzwerk hinaus für den Service Hosting genutzt werden sowie die von Kundenseite installierten Systeme im Rahmen eines Housing. Externe Netzwerkverbindungen, Kundenanbindungen, die Bereitstellung von Einwahlzugängen ins Internet sowie der Betrieb der internen Telefonanlagen sind ebenfalls nicht Bestandteil des Informationsverbundes BSI 53133 Bonn <kes> 2012 # 5 45

Amtliche Mitteilungen Zertifikatsnummer Institution Untersuchungsgegenstand gültig bis BSI-IGZ-0106-2012 Bundes- Ein wesentlicher Geschäftsprozess des BMI ist die Gewinnung 2015-05-16 ministerium und Verarbeitung von Informationen. Daher wird innerhalb des Innern der komplexen IuK-Landschaft der Prozess Standard-Bürokommunikation betrachtet, d.h. sämtliche hierfür notwendige Basisinfrastruktur des BMI am Standort Alt Moabit. Die Komponenten zur Standard-Bürokommunikation sind darüber hinaus Voraussetzung für zahlreiche Fachverfahren und haben damit insgesamt eine hohe strategische und operative Bedeutung für das BMI. Von der Standard-Bürokommunikation umfasst sind der Standard-Büroclient ebenso wie der Telearbeitsplatz, die Dateiablage, die Benutzerverwaltung, die Groupware-Umgebung sowie die Netzwerkinfrastruktur einschließlich Perimeternetzwerk zum Übergang in das Behördennetzwerk. 5. Vom BSI zertifizierte oder anerkannte Stellen: Firma/Anschrift Bereich Gültig TÜV TRUST IT GmbH, IT-Sicherheitsdienstleister im Geltungsbereich 2012-09-01/2015-08-31 Unternehmensgruppe IS-Revision und IS-Beratung TÜV Austria, Waltherstraße 49-51, 51069 Köln 46 BSI 53133 Bonn <kes> 2012 # 5