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
Rollen | Hauptrollen:
| Zusätzliche Rollen:
| Unterstützende Rollen:
|
Eingaben | Verbindlich:
| Optional:
| Extern:
|
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).
-
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.
-
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.
-
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.
-
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).
-
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.
-
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
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|