Risiken und

Sicherheitsanforderungen

Die typischen Bedrohungen für verteilte IT-Systeme sind bezüglich der aufgelisteten grundsätzlichen Security-Ziele (s. Abschnitt 1.2) weiterhin von Bedeutung, auch im Rah-men von SOA-unterstützten Geschäftsprozessen. Durch das Mitschneiden der Kommunikation zwischen Services oder durch unberechtigten Zugriff auf schützenswerte Services könnten zum Beispiel Daten ausspioniert und manipuliert werden. Authentifizierungsdaten könnten ebenfalls ausspioniert werden. Weitere Risiken sind denkbar.

Eine umfangreiche Risikoanalyse ist nicht Ziel dieses Arti-kels. Um Risiken zu minimieren, gibt es, je nach Prozess-klasse, ganz bestimmte Sicherheitsanforderungen, die beachtet werden sollten. Diese sind in einer entsprechen-den prozessübergreifenentsprechen-den Security Policy zu formulieren.

Manche der Anforderungen betreffen die Architektur, insbesondere das Bereitstellen von Services im Rahmen der jeweils betrachteten Prozessklasse. Die folgende Liste der Sicherheitsanforderungen erhebt keinen Anspruch auf Vollständigkeit, vielmehr handelt es sich um eine Aus-wahl der aus unserer Sicht wichtigsten Anforderungen im Rahmen von SOA-unterstützten Geschäftsprozessen.

Anforderungen für Prozesse innerhalb einer Sicherheitsdomäne

Innerhalb einer Sicherheitsdomäne gibt es Einschränkun-gen bezüglich der erreichbaren Sicherheit. Daten, Services und Identitäten (Benutzerkonten) einer Sicherheitsdo-mäne sind vor den Administratoren der DoSicherheitsdo-mäne nicht geschützt. Darüber hinaus sind Daten und Services eines Benutzerkontos nicht vor dem Eigentümer des Kontos geschützt. Durch den Einsatz einer SOA ergeben sich trotzdem Chancen für eine angemessene Security, auch innerhalb einer Domäne.

Bereitstellung von schützenswerten Services und Daten

Um eine Beschränkung des Zugriffs und somit eine Tren-nung von Aufgabenbereichen effektiv durchzusetzen, sollte Folgendes beachtet werden:

„ Daten und Services, auf die ein Benutzer nur beschränkten Zugriff erhalten soll, müssen auf ein anderes Benutzerkonto ausgelagert werden.

„ Auf schützenswerte Daten außerhalb des eigenen Benutzerkontos darf nur über einen Service (bzw. Ser-verprogramm) zugegriffen werden. Dieser Service und die entsprechenden Daten liegen innerhalb desselben Benutzerkontos.

Authentifizierung

„ Das Anmelden (Log-in) an einem Benutzerkonto der Domäne erfordert immer eine Authentifizierung des Benutzers.

„ Das Authentifizierungsverfahren für das Log-in wird von der verantwortlichen Instanz der Sicherheitsdo-mäne definiert.

„ Die Nutzung eines Service, der sich außerhalb des eigenen Benutzerkontos befindet (z. B. auf einem Ser-ver in der Domäne), erfordert eine Authentifizierung des Benutzers im Laufe des Geschäftsprozess, sofern der Service schützenswert ist.

„ Das Authentifizierungsverfahren im laufenden Prozess wird von der verantwortlichen Instanz der Sicherheitsdomäne definiert (z. B. Kerberos).

Autorisierung

„ Der Zugriff auf Daten, Services und Identitäten einer Sicherheitsdomäne muss autorisiert werden, sofern diese schützenswert sind. Die Identität des Subjekts in der Autorisierung muss zuvor authentifiziert werden.

„ Die Autorisierung für Zugriffe auf Services und Daten, die in der Domäne eines Benutzers liegen, wird im Kontext desselben Benutzerkontos durchgesetzt.

„ Einer Identität werden nur die notwendigen Berech-tigungen erteilt, auf Services und Daten zuzugreifen, die im Rahmen einer bestimmten Tätigkeit (Rolle) erforderlich sind („least privilege“). Per Default wer-den einem Benutzer keine Berechtigungen zugeord-net (Compliance).

„ Die Zuständigkeit für das Verwalten der Zugriffs-Policy sowie der Inhalt der Zugriffs-Policy (d. h. „Wer darf was wie nutzen“) wird von der verantwortlichen Instanz der Sicherheitsdomäne definiert. Die Administration erfolgt in der Regel innerhalb der Sicherheitsdomäne.

„ Die Zugriffs-Policy muss administriert werden können und sollte nicht statisch hinterlegt sein.

Kommunikation

Auch innerhalb einer Sicherheitsdomäne kann, besonders durch den Einsatz einer SOA, IP-basierte Kommunikation stattfinden, typischerweise zwischen Benutzerkonten oder Rechnern. Diese Form der Kommunikation muss abgesichert werden, zum Beispiel mittels Mechanismen wie Kerberos (siehe Liste oben). Da die Kommunikation innerhalb einer Sicherheitsdomäne stattfindet, ist das Absichern derselben durch die vorhandene direkte Ver-trauensbeziehung der Benutzer der Domäne erleichtert.

Protokollierung

Wird ein Schritt eines Geschäftsprozesses im Namen einer Identität ausgeführt, die von der des ursprüngli-chen Benutzers abweicht, muss es möglich sein, diese ursprüngliche Identität nachzuvollziehen. Innerhalb einer Sicherheitsdomäne ist dies zum Beispiel der Fall, wenn ein Funktionsbenutzer, unter dem ein Service läuft, auf Daten zugreift. Es muss außerdem möglich sein, nachzuvollziehen, auf welche Daten und Services mit welcher Identität zugegriffen wurde.

„ Sowohl beim Log-in an einem Benutzerkonto als auch beim Zugriff auf schützenswerte Daten und Services muss ein entsprechendes Ereignis (Event) registriert werden können. Jedes Ereignis muss einer Identität/

einem Benutzer eindeutig zuzuordnen sein.

„ Die Protokollierung muss gemäß der vorhandenen Policy identitätsspezifisch ein- und abschaltbar sein (Konformität zu Datenschutzbestimmungen).

Anforderungen für Prozessschritte zwischen Domänen, die sich „direkt“ vertrauen Authentifizierung

„ Die Nutzung eines Service außerhalb seiner Sicher-heitsdomäne erfordert die Authentifizierung des

Benutzers oder der Partner-Sicherheitsdomäne, sofern der Service schützenswert ist.

„ Der Benutzer ist in der Sicherheitsdomäne des Service-Providers bekannt und kann von dieser direkt authentifiziert werden. Dafür müssen sich Benutzer beim Service-Provider registrieren oder es müssen entsprechende Konten in der Service-Provider-Domäne angelegt werden.

„ Das Authentifizierungsverfahren für den Service-Aufruf, d. h. für die direkte Authentifizierung des Benutzers, wird von der verantwortlichen Instanz der Sicherheitsdomäne des Service definiert. Dieses Verfahren könnte aber auch im Einverständnis von Benutzer bzw. Unternehmen und Service-Provider definiert werden.

„ Für die Authentifizierung zwischen Sicherheitsdomä-nen sind Standardprotokolle einzusetzen, um eine möglichst hohe Plattformunabhängigkeit zu errei-chen. Für die Bereitstellung von Authentifizierungsto-kens müssen Standardstrukturen wie z. B. WS-Security und SAML verwendet werden.

„ Authentifizierungstokens müssen genügend Merk-male aufweisen, um die entsprechenden Benutzer gegenüber der Service-Provider-Domäne zu identi-fizieren und um die direkte Vertrauensbeziehung zu beweisen.

Autorisierung

Zusätzlich zu den Forderungen für Prozessschritte inner-halb einer Sicherheitsdomäne ist Folgendes zu beachten:

„ Die Autorisierung für Zugriffe auf Services und Daten der Domäne wird im Kontext der Provider-Domäne durchgesetzt.

„ Der Inhalt der Zugriffs-Policy („Wer darf was wie nutzen“) wird in der Regel im Einverständnis von Benutzer bzw. Unternehmen und Service-Provider festgelegt.

Kommunikation

Es findet in der Regel eine IP-basierte Kommunikation zwischen Benutzer und Service in der Provider-Domäne statt, um SOAP-Nachrichten auszutauschen.

„ Falls schützenswerte Daten übertragen werden, sollte ein sicherer Transportkanal aufgebaut werden (z. B.

über SSL, IPSec usw.).

„ Schützenswerte Daten, die zwischen Sicherheitsdo-mänen ausgetauscht werden, sollten außerdem auf Nachrichtenebene (Message Security) geschützt wer-den, um den Schutz von der aufrufenden Anwendung bis zum Service – „end-to-end“ – herzustellen. Dafür sollten die entsprechenden Standards eingesetzt werden (XML-Security, WS-Security, …).

„ Die Sicherheitsstufe für Transportkanäle und Nach-richten wird von der verantwortlichen Instanz der Provider-Domäne festgelegt, kann aber auch im Einverständnis von Benutzer bzw. Unternehmen und Service-Provider definiert werden.

Protokollierung

„ Sowohl bei der Authentifizierung eines Benutzers und der Service-Provider-Domäne als auch beim Zugriff auf Funktionen eines schützenswerten Service muss ein entsprechendes Ereignis (Event) registriert werden können. Jedes Ereignis muss einer Identität/einem Benutzer eindeutig zuzuordnen sein.

„ Die Protokollierung muss gemäß der vorhandenen Policy identitätsspezifisch ein- und abschaltbar sein (Konformität zu Datenschutzbestimmungen).

Anforderungen für Prozessschritte zwischen Domänen, die sich „indirekt“ vertrauen

In diesem Szenario sind besondere Anforderungen bezüg-lich Authentifizierung sowie zur Autorisierung und Proto-kollierung von Zugriffen auf Ressourcen zu beachten. Die Anforderungen zur Sicherheit der Kommunikation sind im Wesentlichen dieselben wie in den vorherigen Szenarien.

Authentifizierung

„ Die Nutzung eines Service durch einen Client außer-halb der Sicherheitsdomäne des Service-Providers erfordert eine Authentifizierung, sofern der Service schützenswert ist.

„ Damit der Service-Provider den Aufrufer als authen-tifizierte Instanz akzeptiert, ist eine Vertrauensbe-ziehung zum Service-Provider erforderlich. In dieser

Vertrauensbeziehung werden Vertrauensintermediäre gestattet. Es ist daher nicht erforderlich, dass der Aufrufer der Sicherheitsdomäne des Service-Providers direkt bekannt bzw. als Benutzer beim Service-Pro-vider registriert ist. Dem Benutzer wird auf Basis der Vertrauensintermediäre (Federation) vertraut.

„ Der Service-Provider muss bei der Definition der Security Policy entscheiden, ob Vertrauensintermedi-äre gestattet sind. Das Authentifizierungsverfahren muss vom Service-Provider und von den betroffenen Vertrauensintermediären unterstützt werden.

„ Authentifizierungstokens müssen genügend Merk-male enthalten, um die direkte Vertrauensbeziehung zu einem Vertrauensintermediär beweisen zu können.

Außerdem sollte die Identität, Pseudonym oder Stell-vertreter des ursprünglichen Benutzers sowie aller Vertrauensintermediäre im Token enthalten sein. Wird ein Schritt im Geschäftsprozess im Namen einer ande-ren Identität ausgeführt, die von der des ursprüngli-chen Benutzers abweicht, muss es möglich sein, diese ursprüngliche Identität nachzuvollziehen.

„ Für die Authentifizierung sind Standardprotokolle und Standardstrukturen einzusetzen. Dies ist besonders wichtig, da die Authentifizierungs-Policy nicht bilate-ral zwischen Benutzer und Service-Provider definiert wird, sondern mehrere Partner betrifft.

Autorisierung

„ Die Autorisierung des Zugriffs muss anhand der Identität (oder eines Pseudonyms) des ursprünglichen Benutzers erfolgen, um die Nachvollziehbarkeit des Zugriffs während des gesamten Geschäftsprozesses herstellen zu können.

„ Der Inhalt der Zugriffs-Policy wird vom Service-Provi-der festgelegt, ggf. in Abstimmung mit Vertrauensin-termediären. Die End-Benutzer sind typischerweise nicht involviert, da keine direkte Vertrauensbeziehung zwischen Benutzer und Service-Provider besteht.

Protokollierung

„ An allen Stellen, an denen ein Identitätswechsel statt-findet, muss ein entsprechendes Ereignis registriert werden.

Allgemeine Usability-Anforderungen

Ein Single Sign-on ist für die Gesamtheit eines Geschäfts-prozesses anzustreben – ein Benutzer wird sich aber aus Sicherheitsgründen für bestimmte Services im Gesamtge-schäftsprozess trotzdem erneut authentifizieren müssen.

7.2.5 Sicherheitsanforderungen, Policy