Aufgabe: Sicherheitsmuster identifizieren
Bei der Erstellung der ersten Architektur für ein System ist der Sicherheitsarchitekt für die Identifikation und Auswahl der wichtigsten Sicherheitsmuster verantwortlich, die das für das System erforderliche Sicherheitsniveau gewährleisten.
Zweck

Bereitstellung von Schlüsselmechanismen für die Entwicklung sicherer Lösungen durch Auswahl vordefinierter Muster

Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Hauptbeschreibung

Ziel dieser Aufgabe ist es, Architekten die Möglichkeit zu geben, grobe Sicherheitsmuster zu identifizieren, die den Sicherheitsanforderungen und -richtlinien der Architekturelemente genügen und diesen somit zugeordnet werden können. Diese Muster werden dann mit detaillierten Mustern verfeinert, die für die von nachgeordneten Design- und Implementierungsaufgaben ausgewählten Technologien und Plattformen geeignet sind.

Weitere Informationen zu Sicherheitsmustern enthält das Konzept Sicherheitsmuster.

Schritte
Sicherheitsanforderungen identifizieren

Bei diesem Schritt ist der Sicherheitsarchitekt dafür verantwortlich, dass die wesentlichen Sicherheitsanforderungen für ein Projekt und die wichtigsten Architekturelemente für das Projekt erfasst werden. Diese Anforderungen werden im Dokument zur Softwarearchitektur und in den ergänzenden Spezifikationen erfasst. Falls diese Anforderungen signifikante Einschränkungen für die Architektur der Lösung bedeuten, sollten sie außerdem in die Referenzarchitektur aufgenommen werden. Der Sicherheitsarchitekt hat die Aufgabe, diese komplexen Anforderungen bei den Stakeholdern des Projekts in Erfahrung zu bringen und leicht verständlich (als Absichten) zu formulieren.

In diesem Stadium wird bewusst das Wort Absicht betont, denn die meisten Stakeholder werden in einer Befragung zu den Anforderungen (siehe Richtlinie Anforderungsworkshop) antworten, dass "selbstverständlich alles sicher sein muss". Wird nachgefragt, ob damit gemeint ist, dass alles verschlüsselt und überwacht werden soll etc., lautet die Antwort meistens "oh ja, bitte". Der Sicherheitsarchitekt erklärt an dieser Stelle die Auswirkungen einer solchen Entscheidung, die damit verbundenen Kosten und die Komplexität, so dass die Gruppe eine sinnvolle Diskussion darüber beginnen kann, welche Muster für welche Elemente der Architektur relevant sind. Es sind diese Muster, die die Absicht des Systems in Sachen Sicherheit ausdrücken. Die Muster auf Designebene drücken dagegen die Mechanismen für die Umsetzung der Absicht aus, und Implementierungsmuster drücken schließlich die für die Umsetzung der Absicht verwendete Technologie aus.

Vertrauensgrenzen identifizieren

Vertrauen ist ein Schlüsselaspekt jeder Sicherheitslösung. Die Notwendigkeit einer Absicherung basiert auf der Prämisse, dass zwei Vertragspartner ein gewisses Maß an Vertrauen haben. Dies kann bis hin zu vollständigem Vertrauen (und dem Wegfall der Notwendigkeit zur Absicherung) reichen oder aber bis zu totalem Misstrauen (und den damit verbundenen Unterstellungen).

  1. Keine Sicherung ... gleichbedeutend mit blindem Vertrauen: Der Provider könnte einen öffentlichen Service bereitstellen, ohne dass eine Notwendigkeit besteht, dem aufrufenden System zu vertrauen. Das aufrufende System könnte eine ID ohne Nachweis senden und erwarten, dass der Provider die ID beim Verarbeiten der Anforderung als gegeben annimmt. Möglicherweise sind keine Maßnahmen in Kraft, die Attacken mit einer vorgetäuschten Identität verhindern.
  2. Sicherung durch die Netzkonfiguration: Es gibt keine Softwarekonfiguration, die Sicherheit vermittelt. Das Netz ist (möglicherweise durch die Gliederung in Teilnetze mit Firewalls) so konfiguriert, dass nur eine begrenzte Anzahl von Maschinen eine Nachricht an den Provider senden kann. Im krassesten Fall würde das Teilnetz nur das vorgesehene aufrufende System und das Providersystem enthalten. Manchmal wird die Anzahl der potenziellen aufrufenden Systeme durch virtuelle private Netze beschränkt.
  3. Sicherung durch die Infrastruktur: Die Infrastruktur (z. B. das Transportprotokoll, möglicherweise MA SSL oder SSL + BA) ist so konfiguriert, dass das aufrufende System identifiziert wird, um festzustellen, ob es sich um ein anerkanntes System handelt. Die Web-Services-Nachricht (SOAP-Nachricht) enthält ausschließlich die ID des Aufrufenden, die der Provider bei der Verarbeitung der Anforderung als gegeben annehmen soll.
  4. Sicherung durch Token: Bei der Punkt-zu-Punkt-Sicherung auf Tokenbasis enthält die Nachricht ein Token, das eine Aufrufer-ID zusichert und nachweislich von einem anerkannten aufrufenden System erstellt wurde (z. B. SAML, LTPA). Bei der Sicherung durch Token eines Dritten enthält die Nachricht ein Token, das eine Aufrufer-ID zusichert und nachweislich vom KDC/STS des Systems eines vertrauenswürdigen Dritten erstellt wurde (z. B. SAML, Kerberos).
  5. Sicherung durch Tokenkontext: Der Tokenkontext kann eine Signatur sein, die für das Token und die Nachricht gilt. Die von einem anerkannten aufrufenden System erstellte Nachricht enthält eine Signatur, die für die Nachricht gilt und für das Token, das die Aufrufer-ID zusichert und das aufrufende System authentifiziert. Ein weiterer Tokenkontext sind zwei Token in der Nachricht. Ein in der Nachricht enthaltenes Token authentifiziert das aufrufende System als anerkanntes System und das andere Token identifiziert den Aufrufenden. Es ist ein Mechanismus erforderlich, der die beiden Token verbindet und an die Nachricht bindet, z. B. eine Signatur.
  6. Die extreme Form der Sicherung ist die Authentifizierung. Jedes Token, das als sicherer Nachweis dienen kann, macht gesonderte Mechanismen zum Aufbau von Vertrauen überflüssig.

Vertrauenszonen

Bei großen Organisationen ist es oft effizient, das Unternehmen in Verwaltungsregionen zu unterteilen und verschiedene Vertrauenszonen einzurichten. Zwischen den verschiedenen Zonen können mehrere Unterarten von Vertrauensbeziehungen hergestellt werden. Nachfolgend finden Sie Beispiele für einige Möglichkeiten zur Herstellung einer Vertrauensbeziehung zwischen zwei Parteien, von denen nur eine eine Beziehung zum Endbenutzer hat.

  • Direkte Sicherung - Tokenaustausch: Trust Domain 1 authentifiziert den Endbenutzer und Trust Domain 2 erfordert eine Identität oder Kennung (Identitätsweitergabe). In einigen Fällen (in denen nur eine Personalisierung erforderlich ist) wird möglicherweise keine Authentifizierung benötigt.
  • Direkte Sicherung - Tokenvalidierung: Trust Domain 1 könnte eine neue Zusicherung (einer Identität) erstellen und den eigenen Beweis dafür anbieten, dass sie den identifizierten Benutzer authentifiziert hat. Trust Domain 2 überprüft, ob diese Zusicherung von einer anerkannten Quelle (Trust Domain 1) stammt und verwendet sie dann, anstatt den Benutzer selbst zu identifizieren.
  • Tokenservices und Identitätsserviceprovider: Manchmal werden Vertrauensbeziehungen zwischen mehreren Parteien hergestellt, und die Authentifizierung des Benutzers wird gesondert von einem unabhängigen Service (Identitätsserviceprovider) durchgeführt. Solche Identitätsserviceprovider bieten verschiedene Funktionsebenen an. Einige können ausgehend vom Bestimmungsort der Anfrage feststellen, ob der Benutzer authentifiziert ist. Sie wissen, ob das aktuelle Token durch ein zweites Token ersetzt werden muss, und können diese Anforderung an die entsprechenden Parteien weiterleiten.
  • Indirekte Sicherung: Manchmal gibt es keine direkte Vertrauensbeziehung zwischen Parteien. Die Parteien nutzen jedoch einen von beiden anerkannten Dritten als Broker für den Nachrichtenaustausch.
  • Delegierung: Es können Kombinationen aus direkten und indirekten Vertrauensbeziehungen hergestellt werden.
Problemorientierte Sicherheitsmuster identifizieren

Nachfolgend sind die während dieser Aufgabe identifizierten problemorientierten Sicherheitsmuster aufgeführt. Elemente der Systemarchitektur, die von Sicherheitsanforderungen betroffen sind (dies können Software- und Hardwareelemente sein), können jetzt einem oder mehreren dieser Muster zugeordnet werden (die nach Möglichkeit im Dokument zur Softwarearchitektur beschrieben sein sollten), damit sie während der Designaktivitäten weiterentwickelt werden können.

Identität und Authentifizierung

Ein Endbenutzer hat eine Kennung (einen Benutzernamen) und/oder eine Reihe von Kennungen (Titel, Rollen, Aliasnamen) sowie Nachweise (Kennwörter). Diese bewahrt er auf, z. B. auf einem Clientsystem wie einem Laptop oder PDA. Wenn der Benutzer von einer Anwendung aufgefordert wird, sich zu identifizieren, präsentiert er der Anwendung zur Authentifizierung die Kennung und den Nachweis. Wenn die Anwendung die Kennung und den Nachweis validiert, hat sich der Benutzer erfolgreich "authentifiziert", und die Identität ist jetzt eine "authentifizierte Identität". Wenn eine Anwendung Geschäftslogik implementiert und eigene Sicherheitsrichtlinien umsetzt, muss sie ihre Daten/Metadaten in einem Repository für Daten/Metadaten (Dateisystem, Datenbank usw.) aufbewahren. Seit der Einführung des Web hat der Endbenutzer nicht mehr nur Anwendungsclientcode auf seinem eigenen System, sondern greift häufig über einen Browser auf Anwendungen zu, die im Netz mit Hilfe eines vom Endbenutzer bereitgestellten URI (Universal Resource Identifier) gefunden werden.

Single Sign-On

Wenn ein Benutzer mit mehreren Anwendungen arbeitet und verschiedene Kennungen und Nachweise verwendet, wird es manchmal schwierig, die Identitätsdaten und -metadaten so zu verwalten, dass angemessene Entscheidungen getroffen werden können. Der Begriff Single Sign-On (SSO) wird auf verschiedene Verfahren (menschliche und automatisierte) angewendet, um diese Komplexität zu reduzieren.

Lösungen für SSO können client- oder server-/servicebasiert und eng oder flexibel mit den Anwendungen verbunden sein. Webbasiertes SSO bezieht sich auf browserbasierte Lösungen und verwendet in der Regel Cookies. Beim clientbasierten SSO mit enger Verbindung ist der Benutzer für die Registrierung und Synchronisierung mehrerer IDs/Kennwörter, die in mehreren Anwendungs-Repositorys verwaltet werden, verantwortlich. Manche Formen des SSO setzen auf den "Identitätsabgleich", andere bieten die Möglichkeit der "Identitätsweitergabe" oder der "Identitätsprüfung". Neue Initiativen für dezentrales SSO erlauben dem Benutzer, sich bei einem anderen Anbieter (Identitätsserviceprovider) zu registrieren, der dann die Benutzerinformationen verwaltet. Dies wäre eine Alternative mit flexibler Verbindung. Bei einem Back-End-SSO in Unternehmen kann das Unternehmen selbst als Identitätsserviceprovider agieren. Für das Back-End-SSO ist unter anderem ein gemeinsames Repository für alle Anwendungen erforderlich. Außerdem werden alle Anwendungen/Server so rekonfiguriert, dass sie kein lokales Repository verwenden. Es können auch mehrere Repositorys mit Benutzerinformationen für das Back-End-SSO verwaltet werden. In diesem Fall ist ein Managementprozess für die Synchronisation der Identitätsdaten in den verschiedenen Repositorys erforderlich. Sind mehrere Identitäten vorhanden, gibt es oft Anforderungen, Anwendungen in Realms zu isolieren, die häufig mit Verwaltungsdomänen korrelieren.

Digitale Identitäten

Menschen und Unternehmen sind in immer stärkerem Maße auf Computertechnologien angewiesen, so dass eine starke Zunahme bei der Erstellung identitätsbezogener Informationen zu verzeichnen ist. Um einem Diebstahl von Identitätsdaten zu verhindern, haben Regierungen Gesetze erlassen, die Unternehmen zum Schutz der von ihnen verwalteten Identitätsdaten verpflichten.

Lösungen mit digitalen Identitäten: Für die Verwaltung digitaler Identitäten gibt es zwei Hauptstrategien. Die eine ist "benutzerzentriert" und darauf angewiesen, dass der Benutzer aktiv zum Schutz seiner Identität beiträgt, indem er sich bei anderen Providern "registriert" und den Providern seines Vertrauens gestattet, auf seine Identitätsdaten und -metadaten zuzugreifen. Diese Strategie wurde maßgeblich von der Liberty Alliance, einem Konsortium, entwickelt. Mit der Higgins-Initiative in Zusammenarbeit mit der Apache Foundation wurde jedoch auch ein Open-Source-Ansatz auf den Weg gebracht.

Die zweite Strategie ist ein geschäftszentriertes Modell, bei dem ein Unternehmen Identitätsmanagementservices für seine Kunden, Partner und Angestellten bereitstellt. Die zugrunde liegende Technologie ist bei allen Herangehensweisen dieselbe. Unterschiede finden sich jedoch bei der Steuerung und Zuständigkeit für die Bereitstellung des Identitätsmanagements für digitale Identitäten. Unternehmen haben es mit anderen Datenmengen zu tun als Einzelpersonen und sind daher mit anderen Skalierungsanforderungen konfrontiert. Darüber hinaus benötigen Unternehmen ihre eigenen Systeme für die Verwaltung des Benutzerzugriffs in Abhängigkeit von Aufgabenbereichen und wechselnden Geschäftsbedingungen. (Das heißt, Sie sind stets "Sie selbst", arbeiten aber möglicherweise nicht immer für Firma XYZ.)

Berechtigung

Je stärker Menschen und Unternehmen auf Computertechnologien angewiesen sind, desto wichtiger werden Regeln, die festschreiben, wer auf welche Ressourcen zugreifen darf. Beim Entwerfen von Anwendungen kann die Entscheidung darüber, wer Zugriff auf welche Informationen hat, von Informationen aus dem Geschäftskontext abhängig sein. Sie kann aber auch externalisiert (in die Anwendung verlagert) werden und von separaten Middlewarekomponenten verarbeitet werden. Die meisten Produkte und Computersysteme enthalten eine Reihe von Mechanismen für die "Zugriffssteuerung". In der Regel verwendet jedoch jeder dieser Mechanismen eine eigene Zuordnung von autorisierten Benutzernamen zu Ressourcennamen, die als "Zugriffssteuerungsliste" bezeichnet wird.

Nachrichtenschutz

Es gibt zwei Basisarten des Schutzes, den Integritätsschutz (Nachweis, dass die Nachricht auf dem Transportweg nicht geändert wurde) und Vertraulichkeit (Einsatz der Verschlüsselung, um sicherzustellen, dass die Nachricht nur von berechtigten Empfängern gesehen werden kann). Beim Senden von Nachrichten über Protokolle kann jede Nachricht digital signiert oder verschlüsselt werden, oder das Netzprotokoll kann den gesamten Datenverkehr zwischen zwei Eingangspunkten signieren/verschlüsseln. Wird der Schutz vom Protokoll gewährleistet, sprechen wir oft vom "Punkt-zu-Punkt-Schutz" (d. h. der Schutz von Netzendpunkt zu Netzendpunkt).

Eigenschaften
Vorgänger
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Wichtige Hinweise
Die während dieser Aufgabe identifizierten Sicherheitsmuster sind problemorientiert und nicht von bestimmten Technologien oder Plattformen abhängig. Jedes dieser Muster wird jedoch von einer Reihe technologie- und plattformspezifischer Muster unterstützt. Die Definition dieser detaillierten Muster muss dem Implementierer der für ein Projekt ausgewählten Technologie und Plattform zur Verfügung stehen.
Weitere Informationen