Zertifizierungen und Compliance Statements¶
Compliance und Sicherheit sind nicht exklusiv und müssen gemeinsam angesprochen werden. OpenStack-Implementierungen sind unwahrscheinlich, dass sie Compliance-Anforderungen ohne Security Hardening erfüllen. Die untenstehende Auflistung bietet dem OpenStack Architekten fundamentale Kenntnisse und Anleitungen, um die Einhaltung von Handels- und Regierungszertifikaten und -normen zu erreichen.
Gewerbliche Standards¶
Für kommerzielle Einsätze von OpenStack empfehlen wir SOC 1/2 mit ISO 2700 1/2 kombiniert als Ausgangspunkt für OpenStack-Zertifizierungsaktivitäten. Die erforderlichen Sicherheitsaktivitäten, die von diesen Zertifizierungen beauftragt werden, erleichtern die Festlegung von bewährten Best Practices und gemeinsamen Kontrollkriterien, die bei der Erreichung strengerer Compliance-Aktivitäten, einschließlich staatlicher Bescheinigungen und Zertifizierungen, helfen können.
Nach Abschluss dieser Erstzertifizierungen sind die verbleibenden Zertifizierungen mehr implementierungsspezifisch. Zum Beispiel benötigen Clouds, die Kreditkarten-Transaktionen verarbeiten, PCI-DSS, Clouds, die Gesundheitspflegeinformationen speichern, benötigen HIPAA, und Clouds innerhalb der Bundesregierung können FedRAMP/FISMA und ITAR, Zertifizierungen erfordern.
SOC 1 (SSAE 16) / ISAE 3402¶
Service-Organization Controls (SOC) Kriterien sind definiert durch die American Institute of Certified Public Accountants <http://www.aicpa.org/> ``(AICPA). SOC-Kontrollen beurteilen relevante finanzielle Statements und Erklärungen eines :term:`service provider, wie z.B. die Einhaltung des Sarbanes-Oxley Act. SOC 1 ist ein Ersatz für Statement on Auditing Standards Nr. 70 (SAS 70) Typ II report. Diese Kontrollen beinhalten häufig physische Rechenzentren im Geltungsbereich.
Es gibt zwei Arten von SOC 1 reports:
Typ 1 - Report über die Fairness der Darstellung der Beschreibung des Systems der Dienstleistungsorganisation und die Eignung der Gestaltung der Kontrollen zur Erreichung der damit verbundenen Kontrollziele in der Beschreibung zu einem bestimmten Datum.
Typ 2 - Report über die Fairness der Darstellung der Beschreibung des Systems der Dienstleistungsorganisation und die Eignung des Entwurfs und der betrieblichen Wirksamkeit der Kontrollen, um die damit verbundenen Kontrollziele in der Beschreibung während eines bestimmten Zeitraums zu erreichen
Für weitere Details siehe den AICPA-Report über Kontrollen bei einer Serviceorganisation, die für die interne Kontrolle der Benutzerorganisationen für die Finanzberichterstattung relevant ist.
SOC 2¶
Service Organization Controls (SOC) 2 ist eine Selbstbescheinigung von Kontrollen, die die Sicherheit, Verfügbarkeit und Verarbeitung der Integrität der Systeme beeinflussen, die eine Dienstleistungsorganisation verwendet, um die Daten der Benutzer zu verarbeiten und die Vertraulichkeit und die Privatsphäre der von diesem System verarbeiteten Informationen zu schützen. Beispiele für Benutzer sind Verantwortliche für die Governance der Serviceorganisation, Kunden der Serviceorganisation, Regulierungsbehörden, Geschäftspartner, Lieferanten und andere, die ein Verständnis der Serviceorganisation und ihrer Kontrollen haben.
Es gibt zwei Arten von SOC 2 Reports:
Typ 1 - Report über die Fairness der Darstellung der Beschreibung des Systems der Dienstleistungsorganisation und die Eignung der Gestaltung der Kontrollen zur Erreichung der damit verbundenen Kontrollziele in der Beschreibung zu einem bestimmten Datum.
Typ 2 - Report über die Fairness der Darstellung der Beschreibung des Systems der Dienstleistungsorganisation und die Eignung des Entwurfs und der betrieblichen Wirksamkeit der Kontrollen, um die damit verbundenen Kontrollziele in der Beschreibung während eines bestimmten Zeitraums zu erreichen.
Für weitere Details siehe AICPA Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy.
SOC 3¶
Service Organisation Controls (SOC) 3 ist ein Trust Services Report für Service-Organisationen. Diese Berichte sind so konzipiert, dass sie den Bedürfnissen der Nutzer gerecht werden, die die Kontrolle über die Kontrollen bei einer Serviceorganisation im Zusammenhang mit Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit oder Privatsphäre wünschen, aber nicht die Notwendigkeit oder das notwendige Wissen benötigen, um eine effektive Nutzung zu ziehen aus dem SOC 2 Report. Diese Reports werden mit dem AICPA/Canadian Institute of Chartered Accountants (CICA) Trust Services Principles, Criteria, and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy erstellt. Weil die Reports Allgemeingut sind, können SOC 3 Reports frei verteilt oder auf einer Website als Siegel gepostet werden.
Weitere Informationen finden Sie im `AICPA Trust Services Report for Service-Organizationen <http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC3Report.aspx> `_.
ISO 27001/2¶
Die ISO/IEC 27001/2-Normen ersetzen BS7799-2 und sind Spezifikationen für ein Information Security Management System (ISMS). Ein ISMS ist eine umfassende Reihe von Richtlinien und Prozessen, die eine Organisation erstellt und verwaltet, um das Risiko für Informationsvermögen zu verwalten. Diese Risiken basieren auf der Vertraulichkeit, Integrität und Verfügbarkeit (CIA) von Benutzerinformationen. Die CIA-Sicherheitstriade wurde als Grundlage für einen Großteil der Kapitel in diesem Buch verwendet.
Für weitere Details siehe `ISO 27001 <http://www.27000.org/iso-27001.htm> `_.
HIPAA / HITECH¶
Der Health Insurance Portability and Accountability Act (HIPAA) ist ein Kongressgesetz der Vereinigten Staaten, das die Erhebung, Speicherung, Nutzung und Zerstörung von Patientengesundheitsakten regelt. Das Gesetz besagt, dass geschützte Gesundheitsinformationen (PHI) für unberechtigte Personen unbrauchbar, unlesbar oder unentzifferbar gemacht werden müssen und dass die Verschlüsselung für Daten „atrest“ und „inflight“ angegangen werden sollte.
HIPAA ist keine Zertifizierung, sondern ein Leitfaden zum Schutz der Gesundheitsdaten. Ähnlich wie bei der PCI-DSS sind die wichtigsten Probleme bei PCI und HIPPA, dass ein Verstoß gegen Kreditkarteninformationen und Gesundheitsdaten nicht auftritt. Im Falle eines Einbruchs wird der Cloud-Provider für die Einhaltung von PCI- und HIPPA-Kontrollen geprüft. Wenn er nachweislich konform ist, kann davon ausgegangen werden, dass der Anbieter sofort Abhilfemaßnahmen umsetzt, Notifizierungspflichten verletzt und erhebliche Ausgaben für zusätzliche Compliance-Aktivitäten ausführt. Wenn nicht kompatibel, hat der Cloud-Provider vor Ort Audit-Teams, Geldstrafen, potenziellen Verlust der Händler-ID (PCI) und massive Reputation Auswirkungen zu erwarten.
Benutzer oder Organisationen, die PHI besitzen, müssen die HIPAA-Anforderungen unterstützen und sind HIPAA-abgedeckte Einheiten. Wenn ein Unternehmen beabsichtigt, einen Dienst zu verwenden, oder in diesem Fall eine OpenStack-Cloud, der den PHI verwendet, speichert oder Zugriff hat, dann muss eine Business Associate Agreement (BAA) unterschrieben werden. Das BAA ist ein Vertrag zwischen der HIPAA-abgedeckten Einheit und dem OpenStack-Dienstanbieter, der den Anbieter verpflichtet, diese PHI gemäß den HIPAA-Anforderungen zu bearbeiten. Wenn der Dienstanbieter das PHI nicht behandelt, wie z.B. mit Sicherheitskontrollen und Hardening, so unterliegt er HIPAA-Geldstrafen und Strafen.
OpenStack-Architekten interpretieren und reagieren auf HIPAA-Anweisungen, wobei die Datenverschlüsselung eine Kernpraxis bleibt. Derzeit würde dies erforderlich, dass alle geschützten Gesundheitsinformationen, die in einer OpenStack-Bereitstellung enthalten sind, mit Industriestandard-Verschlüsselungsalgorithmen verschlüsselt werden. Mögliche zukünftige OpenStack-Projekte wie die Objektverschlüsselung erleichtern die HIPAA-Richtlinien für die Einhaltung der Handlung.
Für weitere Details siehe Health Insurance Portability And Accountability Act.
PCI-DSS¶
Der Payment Card Industry Data Security Standard (PCI DSS) wird durch den Payment Card Industry Standards Council definiert und erstellt, um die Kontrollen um Karteninhaberdaten zu erhöhen und um Kreditkartenbetrug zu reduzieren. Die jährliche Compliance-Validierung wird von einem externen Qualified Security Assessor (QSA) beurteilt, der einen Bericht über Compliance (ROC) oder einen Self-Assessment Questionnaire (SAQ) erstellt, der vom Volumen der Karteninhaber-Transaktionen abhängig ist.
OpenStack-Bereitstellungen, die die Kartenkarten speichern, verarbeiten oder übertragen, sind für den PCI-DSS im Geltungsbereich. Alle OpenStack-Komponenten, die nicht ordnungsgemäß von Systemen oder Netzwerken, die Zahlungsdaten behandeln, segmentiert sind, fallen unter die Richtlinien des PCI-DSS. Die Segmentierung im Rahmen von PCI-DSS unterstützt keine Multitenants sondern eine physikalische Trennung (Host/Netzwerk).
Weitere Details finden Sie unter PCI security standards.
Government standards¶
FedRAMP¶
„Das Federal Risk and Authorization Management Program (FedRAMP) ist ein staatliches Programm, das einen standardisierten Ansatz für die Sicherheitsbewertung, die Genehmigung und die kontinuierliche Überwachung von Cloud-Produkten und -Dienstleistungen bietet.“ NIST 800-53 ist die Basis für FISMA und FedRAMP, um Schutz in Cloud-Umgebungen zu bieten. FedRAMP kann von der Spezifität um Sicherheitskontrollen extrem intensiv sein und das Dokumentationsvolumen, das erforderlich ist, um Regierungsstandards zu erfüllen.
Für weitere Details siehe FedRAMP.
ITAR¶
Die International Traffic in Arms Regulations (ITAR) ist eine Reihe von Regulierungen der Vereinigten Staaten, die den Export und Import von verteidigungsrelevanten Artikeln und Dienstleistungen auf der United States Munition List (USML) und zugehörigen technischen Daten kontrollieren. ITAR wird oft von Cloud-Anbietern als „operative Ausrichtung“ anstatt einer formalen Zertifizierung angesprochen. Dies beinhaltet in der Regel die Implementierung einer segregierten Cloud-Umgebung nach Praktiken auf der Grundlage des NIST 800-53 Framework, wie pro FISMA Anforderungen, ergänzt mit zusätzlichen Kontrollen, Beschränkung des Zugang nur durch „US-Personen“ und Background-Screening.
Für weitere Details siehe The International Traffic in Arms Regulations (ITAR).
FISMA¶
Das Bundesgesetz für Informationssicherheitsgesetz verlangt, dass die Regierungsbehörden einen umfassenden Plan zur Umsetzung zahlreicher Sicherheitsstandards der Regierung schaffen und im Rahmen des E-Government-Gesetzes von 2002 verabschiedet wurden. Die FISMA beschreibt einen Prozess, der mehrere NIST-Veröffentlichungen verwendet, bereitet ein Informationssystem vor und verarbeiten Regierungsdaten.
Dieser Vorgang wird in drei Hauptkategorien zerlegt:
- Systemkategorisierung:
Das Informationssystem erhält eine Sicherheitskategorie, wie sie in der Federal Information Processing Standards Publikation 199 (FIPS 199) definiert ist. Diese Kategorien spiegeln die potenziellen Auswirkungen des Systemkompromisses wider.
- Kontrollauswahl:
Basierend auf der System-Security-Kategorie, wie in FIPS 199 definiert, nutzt eine Organisation FIPS 200, um spezifische Sicherheitssteuerungsanforderungen für das Informationssystem zu identifizieren. Zum Beispiel, wenn ein System als „moderate“ kategorisiert wird, kann eine Anforderung eingeführt werden, um „sichere Passwörter“ zu beauftragen.
- Control tailoring:
Sobald System-Sicherheitskontrollen identifiziert sind, wird ein OpenStack-Architekt NIST 800-53 nutzen, um eine maßgeschneiderte Kontrollauswahl zu extrahieren. Zum Beispiel, Spezifikation, was ein „sicheres Passwort“ darstellt.
