Die in den vorangehenden Abschnitten dargestellte Problematik ist noch nicht spezifisch für SmA. Klassische verteilte Anwendungen, sind mit den gleichen Problemen konfrontiert. Im Fall von SmA werden aber einige Probleme durch die charakteristischen Eigenschaften von SmA noch verschärft bzw. ihre Komplexität drastisch erhöht.
Generelle Ursache für die höhere Komplexität der
Sicherheitsproblematik von SmA im Vergleich zu klassischen verteilten
Anwendungen ist der unterschiedliche konzeptionelle Ansatz. Verteilte
Anwendungen werden zumeist spezifisch für konkrete Anwendungen
spezifiziert und implementiert, SmA dagegen verstehen sich als
universelle Plattform zur Implementierung konkreter Anwendungen.
Im Folgenden soll stellvertretend für klassische verteilte Anwendungen die Ausprägung als Client/Server Architektur (CSACSA!Client/Server Architektur) betrachtet werden. An einem Beispiel könnte das bedeuten, daß man für eine Banking-Anwendung unter Verwendung von CSA ein genau darauf zugeschnittenes System erstellt, während man anderenfalls spezielle Banking-Agenten auf einem generischen SmA erstellen würde.
Am Beispiel der Banking-Anwendung bedeutet dies vereinfacht, daß die Funktionalität des CSA nur Aktionen wie ``Überweisen'', ``Kontoabfrage'', ``Dauerauftrag einrichten'' umfaßt. Die Schnittstelle des Servers ist somit sehr schmal und leicht zu überwachen. Mögliche Bedrohungen eines solchen Systems wären ``Illegale Überweisung/Kontoüberziehung'', ``Kontoabfrage durch andere Personen als den Kontoinhaber'', etc.
In SmA dagegen ist nur die konkrete Funktionalität der Agentensysteme,
nicht aber die von Agenten vorherbestimmt. Vielmehr wird die Wirkung
von Agenten auf andere Entitäten bewußt offengehalten, um die
Mächtigkeit und Flexibilität des SmA nicht einzuschränken. Im Fall
von SmA für Managementanwendungen gilt dies insbesondere auch für die
Wirkung auf die Endsysteme. Die Folge davon ist allerdings, daß der
Umfang der konkreten Bedrohungen ebenso unvorhersehbar wie
unüberschaubar ist. Vielmehr muß dynamisch, und von Fall zu Fall
entschieden werden, ob eine Aktion nun legitim ist oder nicht.
Wiederum am Beispiel der Banking-Anwendung bedeutet dies, daß entschieden werden muß, ob der Agent berechtigt ist, z.B. bestimmte Einträge einer Datenbank auszulesen, diese zu verändern oder neue hinzuzufügen. Dabei bleibt dem Agentensystem die übergreifende Semantik der Einzelaktionen (``Überweisung'') jedoch verborgen. Gefahren, die dabei durch die direkte Schnittstelle zum Datenbanksystem ausgehen, sind deutlich vielfältiger als im Fall der CSA. So können neben Bedrohungen wie sie für die CSA bestehen, jetzt auch Angriffe erfolgen, die z.B. die Datenbank in einen inkonsistenten Zustand bringen.
So genügt es in einer CSA zur Kontenabfrage, daß der Server sich davon überzeugt, daß der anfragende Client von einem bestimmten Typ ist, welcher dann bereits die Überprüfung des Bankkunden vorgenommen hat, ob dieser zur Abfrage der fraglichen Konten berechtigt ist.
Fordert in einem SmA ein Agent die Ausführung einer
Aktion an, muß dagegen prinzipiell auch die ``Vorgeschichte'' des
Agenten betrachtet werden. Selbst wenn der Agent als vertrauenswürdig
eingestuft wird, könnten nämlich Daten, die für die Ausführung der
Aktion benutzt werden, vorher auf anderen Agentensystem unberechtigt
(in feindlicher Absicht) manipuliert worden sein.
Wird ein mobiler Agent zu Kontenabfrage ``ausgesandt'', muß auf jedem Agentensystem erneut übeprüft werden, ob dieser Agent zur Abfrage berechtigt ist, und ob die Identität des Bankkunden auf seiner ``Reise'' unverändert geblieben ist.
Für die Zurechenbarkeit von Aktionen bedeutet das, daß eine Aktion des Servers unmittelbar im Verantwortungsbereich des Server-Eigentümers liegt, da der Server die Aktion tatsächlich ausführt, und nur mittelbar dem Eigentümer des Clients zuzuschreiben ist, da dieser die Aktion nur ausgelöst hat.
In SmA dagegen diversifizieren sich die Eigentumsverhältnisse aus der
Sicht der Endsysteme.
Während die Agentensysteme den Eigentümern der Endsysteme gehören,
ist der Eigentümer eines Agenten sein Auftraggeber. Somit befinden
sich auf einem Endsystem aus dessen Sicht in der Regel Entitäten mit
unterschiedlichen Eigentümern. Daher ist die Organisationsstruktur
der Entitäten in einem SmA keineswegs identisch zu jener der
beiteiligten Endsysteme.
Für die Verantwortlichkeit einer Aktion heißt das, daß die Aktionen eines Agenten unmittelbar dem Eigentümer des Agenten zuzuschreiben sind und nicht der Verantwortung des Eigentümers des Agentensystems unterliegen. Daraus folgt, daß für SmA ein eigenständiges Domänenkonzept gefunden werden muß, das die Organisationsstruktur im SmA abbildet.
Dagegen sind Anwendungen auf SmA häufig so gestaltet, daß zur
Erfüllung einer Aufgabe mehrere verschieden Agenten, jeder
spezialisiert auf eine bestimmte Teilaufgabe, kooperieren und dadurch
die Gesamtaufgabe gelöst wird. Hierbei sind aber
Vertrauensbeziehungen im gesamten Netz der kooperierenden Agenten
notwendig. Häufig müssen dabei auch Berechtigungen, die ein Agent A
besitzt an einen anderen Agent B weitergegeben werden, damit B eine
Teilaufgabe für A übernehmen kann. Dieses Verfahren wird als
Delegation von Rechten bezeichnet.
So muß beispielsweise ein Kontenauszugs-Agent, der für einen bestimmten Kunden tätig ist und sich dafür der Hilfe eines Datenbankzugriffs-Agenten bedient, diesem die Berechtigungen ``mitgeben'', die für diesen Kunden relevanten Teile aus der Datenbank zu lesen.