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
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:
Die Endbenutzer verwenden das System zum Speichern von sensiblen Daten, wie z.B. Passphrasenverschlüsselungsschlüssel usw.
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:
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]:
Beispielsweise:
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.