Architektur Seitenführung

Der Zweck einer Architektur-Seite ist es, die Architektur, Zweck und Sicherheitskontrollen eines Dienstes oder Projekts zu dokumentieren. Es sollte den Best Practice-Einsatz dieses Projekts dokumentieren.

Es gibt einige wichtige Abschnitte zur Architekturseite, die im Folgenden näher erläutert werden:

• Titel, Versionsinformationen, Kontaktdaten

• Projektbeschreibung und Zweck

• Primärnutzer und Gebrauchsfälle

• Externe Abhängigkeiten und damit verbundene Sicherheitsannahmen

• Komponenten

• Architektur-Diagramm

• Datenvermögen

• Analyse der Datenanalyse

• Schnittstellen

Titel, Versionsinformationen, Kontaktdaten

Dieser Abschnitt titelt die Architektur-Seite, gibt den Status der Überprüfung (Entwurf, bereit für die Überprüfung, überprüft) und erfasst die Freigabe und Version des Projekts (wo relevant). Es zeichnet auch die PTL für das Projekt auf, der Projektarchitekt, der für die Erstellung der Architekturseite verantwortlich ist, Diagramme und die Überprüfung durch die Überprüfung (dies kann oder ist nicht die PTL) und der Sicherheitsprüfer (s).

Projektbeschreibung und Zweck

Dieser Abschnitt enthält eine kurze Beschreibung des Projekts, um Dritte an die Dienstleistung vorzustellen. Dies sollte ein Absatz oder zwei sein und kann aus Wiki oder anderen Dokumentationen geschnitten/eingefügt werden. Fügen Sie Links zu relevanten Präsentationen und weiteren Unterlagen hinzu, falls vorhanden.

Beispielsweise:

„Anchor ist ein Public Key Infrastructure (PKI) Service, der automatisierte Zertifikatsanforderungsvalidierung verwendet, um die Erteilung von Entscheidungen zu automatisieren. Zertifikate werden für kurze Zeiträume (typischerweise 12-48 Stunden) ausgegeben, um die fehlerhaften Widerrufsfragen, die mit CRLs und OCSP verbunden sind, zu vermeiden.“

Primärnutzer und Gebrauchsfälle

Eine Liste der erwarteten Primärbenutzer der implementierten Architektur und ihrer Anwendungsfälle. ‚Benutzer‘ können entweder Akteure oder andere Dienste in OpenStack sein.

Beispielsweise:

1. Die Endbenutzer verwenden das System zum Speichern von sensiblen Daten, wie z.B. Passphrasenverschlüsselungsschlüssel usw.

2. Cloud-Administratoren werden die administrativen APIs verwenden, um Ressourcenquoten zu verwalten.

Externe Abhängigkeiten und damit verbundene Sicherheitsannahmen

Externe Abhängigkeiten sind Gegenstände außerhalb der Kontrolle des Dienstes, die für seinen Betrieb erforderlich sind, und können den Dienst beeinflussen, wenn sie kompromittiert wurden oder nicht verfügbar waren. Diese Gegenstände sind in der Regel außerhalb der Kontrolle des Entwicklers, aber innerhalb der Kontrolle des Deployers, oder sie können von einem Dritten betrieben werden. Geräte sollten als externe Abhängigkeiten betrachtet werden.

Beispielsweise:

• Der Nova-Compute-Service hängt von einem externen Authentifizierungs- und Autorisierungsdienst ab. In einem typischen Einsatz wird diese Abhängigkeit durch den Keystone-Service erfüllt.

• Barbican hängt von der Verwendung von Hardware Security Module (HSM) Gerät.

Komponenten

Eine Liste der Komponenten des eingesetzten Projekts ohne externe Entitäten. Jede Komponente sollte benannt werden und eine kurze Beschreibung ihres Zweckes haben und mit der verwendeten Primärtechnologie (z.B. Python, MySQL, RabbitMQ) beschriftet werden.

Beispielsweise:

• Keystone-Listener-Prozess (Python): Python-Prozess, der Keystone-Ereignisse vereint, die vom Keystone-Service veröffentlicht werden.

• Datenbank (MySQL): MySQL-Datenbank zum Speichern von barbican-Statusdaten im Zusammenhang mit ihren verwalteten Einheiten und deren Metadaten.

Dienstarchitekturdiagramm

Das Architekturdiagramm zeigt das logische Layout des Systems, so dass die Sicherheitsbeurteiler die Architektur mit dem Projektteam durchlaufen können. Es ist ein logisches Diagramm, das zeigt, wie die Komponenten interagieren, wie sie sich mit externen Entitäten verbinden und wo die Kommunikation Vertrauensgrenzen überschreitet. Weitere Informationen zum Architekturdiagramm, einschließlich eines Schlüssels von Symbolen, werden in der anstehenden Architekturdiagrammführung gegeben. Diagramme können in jedem Werkzeug gezeichnet werden, das ein Diagramm erzeugen kann, das die Symbole im Schlüssel verwendet, aber draw.io wird dringend empfohlen

Dieses Beispiel zeigt das barbikanische Architekturdiagramm:

Datenvermögen

Datenvermögen sind Benutzerdaten, hochwertige Daten, Konfigurationselemente, Berechtigungsmarken oder andere Gegenstände, auf die ein Angreifer zielen kann. Die Menge der Datenelemente variiert zwischen den Projekten, aber im Allgemeinen sollte sie als Klassen von Daten betrachtet werden, die für den beabsichtigten Betrieb des Projekts von entscheidender Bedeutung sind. Der erforderliche Detaillierungsgrad ist etwas vom Kontext abhängig. Daten können in der Regel gruppiert werden, z. B. ‚Benutzerdaten‘, ‚geheime Daten‘ oder ‚Konfigurationsdateien‘, können aber auch singulär sein, wie ‚admin identity token‘ oder ‚user identity token‘ oder ‚database configuration file‘.

Das Datenvermögen sollte eine Erklärung enthalten, wo dieser Vermögenswert bestanden hat.

Beispielsweise:

• Geheime Daten - Passphrasen, Verschlüsselungsschlüssel, RSA Keys - Bestand in Datenbank [PKCS#11] oder HSM [KMIP] oder [KMIP, Dogtag]

• RBAC-Regeln - persistiert in policy.json

• RabbitMQ Credentials - persistiert in barbican.conf

• keystone Event Queue Credentials - persistiert in barbican.conf

• Middleware-Konfiguration - persistiert in Paste.ini

Analyse der Datenanalyse

Die Analyse der Datenvermögen berücksichtigt die Auswirkungen des Vertrauensverlustes, der Integrität oder der Verfügbarkeit für jeden Datenbestand. Projektarchitekten sollten versuchen, dies zu vervollständigen, da sie ihr Projekt im Detail verstehen, aber das OpenStack Security Project (OSSP) wird dies mit dem Projekt während der Sicherheitsüberprüfung durchgehen und wahrscheinlich die Details hinzuzufügen oder aktualisieren.

Beispielsweise:

• RabbitMQ Anmeldeinformationen:

  • Integrity Failure Impact: barbican und Worker können nicht mehr auf die Warteschlange zugreifen. Denial of Service.

  • Confidentiality Failure Impact: Ein Angreifer könnte neue Aufgaben der Warteschlange hinzufügen, die von den Workern ausgeführt werden würde. Benutzerkontingente könnten von einem Angreifer ausgeschöpft werden. DOS. Benutzer wäre nicht in der Lage, echte Geheimnisse zu schaffen.

  • Availability Failure Impact: barbican konnte nicht mehr neue Geheimnisse ohne Zugriff auf die Warteschlange schaffen.

• Keystone-Anmeldeinformationen:

  • Integrity Failure Impact: barbican wird nicht in der Lage sein, Benutzeranmeldeinformationen zu validieren und fehlschlagen. DOS.

  • Confidentially Failure Impact: Ein böswilliger Benutzer könnte andere OpenStack-Dienste missbrauchen (abhängig von Keystone-Rollenkonfigurationen), aber barbican ist unberührt. Wenn das Dienstkonto für Token-Validierung auch barbican Admin-Privilegien hat, dann könnte ein böswilliger Benutzer barbican admin-Funktionen manipulieren.

  • Availability Failure Impact: barbican wird nicht in der Lage sein, Benutzer-Anmeldeinformationen zu validieren und fehlschlagen. DOS.

Schnittstellen

Die Schnittstellenliste erfasst Schnittstellen im Rahmen der Überprüfung. Dazu gehören Verbindungen zwischen Blöcken auf dem Architekturdiagramm, die eine Vertrauensgrenze überschreiten oder kein Industriestandardverschlüsselungsprotokoll wie TLS oder SSH verwenden. Für jede Schnittstelle werden folgende Informationen erfasst:

• Das verwendete Protokoll

• Alle Datenbestände im Transit über diese Schnittstelle

• Informationen zur Authentifizierung, die für die Verbindung zu dieser Schnittstelle verwendet wird

• Eine kurze Beschreibung des Zweckes der Schnittstelle.

Dies wird im folgenden Format aufgezeichnet:

Von->An [Transport]:

• Vermögenswerte im Überblick

• Authentifizierung?

• Beschreibung

Beispielsweise:

1. Client->API-Prozess [TLS]:

   • Vermögenswerte im Überblick: User Keystone Anmeldeinformationen, Plaintext Geheimnisse, HTTP Verb, geheime ID, Pfad

   • Der Zugriff auf Keystone-Anmeldeinformationen oder Plaintext-Geheimnisse gilt als totaler Security-Ausfall des Systems - diese Schnittstelle muss über eine robuste Vertraulichkeit und Integritätskontrolle verfügen.

Ressourcen

Aufgelistete Ressourcen, die für das Projekt relevant sind, wie z.B. Wiki-Seiten, die ihre Bereitstellung und Nutzung beschreiben, sowie Links zu Code-Repositories und relevanten Präsentationen.