AAAAA

Christoph Iserlohn: Hallo und herzlich Willkommen zu der sechsten Ausgabe des INNOQ Security Podcasts. Heute ist das Thema Authentisierung, Authentifizierung, Autorisierung, Access Control und Audit und dazu habe ich mir den Stefan eingeladen. Hallo Stefan!

Stefan Bodewig: Hallo Christoph!

Christoph Iserlohn: Ja, heute sind viele As dabei, es geht alles irgendwie um Zugriffskontrolle und so etwas. Und wir wollen heute mal versuchen diese ganzen Begriffe, die sich ja auch zum Teil sehr ähneln, ein bisschen auseinander zu dröseln und sehen: Wofür stehen die überhaupt? Und da fangen wir einfach mal an mit der einfachen Frage, es ja auch noch zwei so Akronyme, das ist AuthN und AuthZ. Wofür stehen die denn?

Stefan Bodewig: Ja, im Endeffekt sind es die englischen Begriffe: Authentication/Authorization, die ganz vorne halt so ganz gleich sind und dann ist es einfach irgendwie den letzten Buchstaben, also nicht wirklich bei Authorization… Also das Z ist Authorization und das auf N ist Authentication. Von den Begrifflichkeiten her. Jetzt müssen wir wahrscheinlich voneinander abgrenzen: Was ist das eine? Was tut das andere?

Christoph Iserlohn: Ja, die sind sehr ähnlich und ich habe das auch schon sehr oft erlebt, dass man die einfach wild durcheinanderwirft. Aber eigentlich haben die ja eine ganz unterschiedliche Bedeutung. Und vielleicht klären wir die mal und gehen vielleicht auch gleichzeitig darauf ein, dass es im deutschen da irgendwie noch einen dritten Begriff gibt, nämlich die Authentisierung und die Authentifizierung, die es im Englisch scheinbar nicht so gibt. Was ist denn…? Fangen wir erstmal mit der Authentisierung, was ist denn das eigentlich?

Stefan Bodewig: Na gut, wenn wir bei den deutschen Begriffen bleiben, dann ist Authentisierung: Ich sage dir, wer ich bin und versuche das nachzuweisen. Und ich, also als Benutzer, authentisiere mich indem ich, weiß ich nicht… Im Alltag meinen Personalausweis dir zeige oder sowas in der Art tue. Und die Authentifizierung ist die andere Seite, die prüft, ob das was ich behaupte auch wirklich stimmt. Also jemand der auf meinen Personalausweis guckt und das Foto mit mir vergleicht. Und das hoffentlich noch ähnlich genug findet, um mir zu glauben, dass ich ich bin.

Christoph Iserlohn: Gut. Das heißt, wenn wir das dann auf die IT Security übertragen, würde das dann heißen: Der Akt das ich hier dann mein Passwort zum Beispiel eingebe, wäre so dass ich mich dabei authentisiere und wenn das Passwort von dem Server geprüft wird, das ist dann die Authentifizierung.

Stefan Bodewig: Ja.

Christoph Iserlohn: Ja und im englischen gibt es aber diese Unterscheidung nicht. Da wird im Allgemeinen typischerweise nur von Authentication gesprochen.

Stefan Bodewig: Ja, ich habe irgendwo zwischendrin noch einmal gesehen, dass man Identification vielleicht für den ersten Teil, der im deutschen Authentisierung wäre, nutzt. Aber eigentlich im Großen und Ganzen sehe ich das auch in der Literatur zusammen immer als Authentication.

Christoph Iserlohn: Gut, gut. Das ist im deutschen zwar jetzt verschieden, aber in der Praxis habe ich gemerkt, dass man meistens von Authentifizierung spricht und nicht von Authentisierung, egal welche Seite ich jetzt gerade einnehme. Also das ist auch bei, wenn ich zum Beispiel mein Passwort eingebe, auch als ich authentifiziere mich. Also ist dir das auch schon so begegnet?

Stefan Bodewig: Gelegentlich trenne ich die Dinge und werde dann eher wegen Pedanterie verhöhnt oder ich verwirre Menschen einfach nur. Denn tatsächlich glaube ich, dass im Alltag das Wort Authentisierung überhaupt nie auftaucht. Ich kenne niemanden mit dem ich mich außerhalb von IT Security unterhalten würde, der den Begriff Authentisierung überhaupt nutzen würde. Gehört einfach nicht zum…, mindestens mal nicht zum aktiven Wortschatz und bei vielen nicht mal zum passiven, würde ich sagen.

Christoph Iserlohn: Also wenn du sagst: Außerhalb der IT Security. Dann ist das so ein Beispiel für eine Bruchstelle, die es oft gibt im Sprachgebrauch zwischen den wirklichen IT Security Fachleuten und dem normalen Entwickler, oder?

Stefan Bodewig: Auch da, ja richtig. Aber das war jetzt eher noch weiter über IT-Grenzen hinausgedacht, aber grundsätzlich stimmt das schon. Auch viele Entwickler unterscheiden da nicht, sondern sehen das als den Bereich, den einen und dem gibt man im englischen den Namen Authentication und das deutsche ist dann eindeutig als Authentifizierung übersetzt.

Christoph Iserlohn: Ja, das ist ja da die Sprache der IT ja auch Englisch ist, ist das vielleicht auch so, dass man das einfach direkt sozusagen übersetzt und sich da diesen Unterschied nicht bewusst ist. Es gibt ja auch in anderen Bereichen, also umgekehrt, im Deutschen wird ja immer über Sicherheit gesprochen. Im Englischen unterscheidet man ja auch zwischen Security und Safety, diese Art von Unterscheidung gibt es jetzt bei dem Wort auch nicht. Bei uns ist es beides Mal die Sicherheit. Gut, jetzt haben wir schon Beispiele gehört, du hast eins genannt mit dem Personalausweis, ich habe das erwähnt, dass man ein Passwort haben kann, um sich zu Authentisieren und authentifiziert zu werden. Aber welche Möglichkeiten bestehen denn da generell, womit kann ich mich denn alles authentisieren?

Stefan Bodewig: Ja, das was du klassisch findest, ist halt, ich muss entweder etwas vorweisen, was ich weiß oder ich muss nachweisen, dass ich irgendetwas besitze und dann gibt es die dritte Kategorie von Dingen, die sicherstellen, dass ich ich bin mit der Regel irgend so ein biometrisches Verfahren oder Dinge, die mein Verhalten analysiert haben und nachweisen können, dass ich ich bin an Hand meiner Tippgewohnheiten, wenn ich irgendeinen Text tippe. Das das aufgezeichnet worden ist und dann rausgefunden wird, dass ich das tatsächlich selber sein könnte. Das sind so die groben drei Kategorien von denen. Wissen, Passwort, das hattest du schon genannt, über diese Kategorie. Der Personalausweis würde eher so in die Kategorie des Besitzes dann gehören. Also etwas was ich habe. Wissen, kennen wir PIN, die ich eingebe, wenn ich auf mein Konto zugreife noch oder diese etwas abstrusen Sicherheitsabfragen: Wie ist der Mädchenname ihrer Mutter? Und: Wie hieß ihre erste Lehrerin in der Schule? Oder so etwas in der Form, das sind eben diese klassischen Wissensbestandteile.

Christoph Iserlohn: Gut, nutzt ich denn sowas immer einzeln oder in Kombination? Oder wie läuft das ab?

Stefan Bodewig: Naja, das heißt… Je nachdem wie sicher ich mir sein möchte, dass derjenige der sagt, der nachweist, dass er er selber ist oder dass sie sie selber ist, das auch wirklich ist. Also in ganz vielen Fällen reicht ja offensichtlich momentan vielen das Passwort aus. Also an ganz vielen Stellen melde ich mich ja lediglich mit dem Passwort an. Wenn ich es etwas sicherer haben möchte, dann sage ich eben: Ich möchte aus diesen verschiedenen Kategorien von Dingen mal zwei kombinieren, das ist dann die klassische zwei-Faktor Authentisierung. Das heißt ich muss einerseits Wissen nachweisen und auf der anderen Seite Besitz. Das sind dann irgendwelche Hardware Token, die Ziffern ausgeben, die ich in der Hand haben muss zusätzlich zu meinem Passwort oder eine App, die ich auf meinem Telefon installiert haben muss, die dann irgendetwas generiert, dass ich also den Nachweis habe, dass ich das Telefon mit der App drauf in der Hand habe, zusätzlich zum Wissen von meinem Passwort. Oder der Fingerabdruck, der dann mit den anderen biometrischen Verfahren dann irgendwo in die dritte Kategorie reingehört. Also ich würde im Normalfall schon sagen, man nimmt zwei, aber ganz häufig ist das im Moment offenbar nicht der Fall. Ganz häufig reicht ja an vielen Stellen ein Faktor.

Christoph Iserlohn: Gut, das heißt also man kann verallgemeinern: Also ein Faktor reicht erstmal, um sich zu authentisieren, aber desto mehr Faktoren dazu nötig sind authentifiziert zu werden, desto sicherer ist das Ganze.

Stefan Bodewig: Ja.

Christoph Iserlohn: Ja und was sind so die Vor- und Nachteile dieser einzelnen Varianten? Also ich kann mir vorstellen bei Fingerabdruck ist es ja so, davon habe ich halt nur zehn, die ich einsetzten kann. Passwörter kann ich immer beliebig ändern, wenn das mal irgendwie verloren geht, … also mein Fingerabdruck geht jetzt nicht unbedingt verloren, den behalte ich, aber vielleicht kriegt den ja jemand anderes in die Hände und kann den dann fälschen, das soll ja auch schon vorgekommen sein.

Stefan Bodewig: Also das hast du ja schon gesagt, ändern ist mit den zehn Fingern vielleicht problematisch. Ich könnte den Finger, den ich bisher benutzt habe, aber auch durch einen Unfall verloren haben. Und verliere dann möglicherweise dieses Verfahren Zugriff zu erhalten, weil mein Finger einfach nicht mehr da ist. Ähnliches gilt für die anderen biometrischen Verfahren. Wenn ich einen Iris Scan habe, dann gibt es auch nur die eine Iris oder die zwei, die ich habe, mit Austauschen ist das auch ein bisschen schwierig. Beim Wissen, das Passwort kann ich so oft ändern, wie ich möchte, aber das kann natürlich auch zu Problemen führen. Dann habe ich vielleicht irgendwann vergessen zu was ich das denn das letzte Mal geändert habe, das kann jemand abgreifen, ich habe das Passwort vielleicht auf einen Zettel geschrieben und der Zettel kommt mir abhanden. Die Nachweise, die sagen: Ich habe etwas was ich besitze, das kann mir gestohlen werden, das kann ich weitergeben an jemanden, der es eigentlich nicht haben sollte. Das Passwort könnte ich jemanden verraten, der es nicht wissen sollte. Während ich bei den biometrischen Verfahren… Ich kann meinen Finger auch zu mindestens nicht einfach weitergeben. Tatsächlich hinterlasse ich den Fingerabdruck aber an unglaublich vielen Stellen den ganzen Tag über, so dass es einen interessierten Angreifer eigentlich nicht schwerfallen sollte so einen Faktor zu gewinnen. Das hängt dann so ein bisschen davon ab, wie gut die Fingerabdrucks Scanner sind, mit denen man dann prüft, ob das tatsächlich der richtige Fingerabdruck ist und ob der von einem lebendigen Menschen kommt.

Christoph Iserlohn: Also daraus könnte man vielleicht den Entschluss ziehen, dass man für… wenn man sich an einem System authentisieren will, vielleicht andere Sachen benutzt, zum Beispiel andere Passwörter oder die Fingerabdrücke, als bei einen anderen System, wo ich jetzt versuche diese Verfahren zu ändern. Also ich denke mal an Passwort recovery oder sonstiges, sozusagen, dass ich da zwei verschiedene Dinge habe. Ja, also die, was du gerade genannt hast: Wie alt ist… Wie war der Mädchenname ihrer Großmutter? Oder ähnliches, also, dass ich an den verschiedenen Stellen vielleicht auch verschiedene Verfahren benutze.

Stefan Bodewig: Ja, wobei die in diesem Beispiel halt nicht unbedingt aus verschiedenen Bereichen kommen, das ist in beiden Fällen Wissen. Also wenn ich mein Passwort vergessen habe, muss ich mich trotzdem daran erinnern, was ich denn damals behauptet habe, was meine Lieblingsfarbe war. Insofern bleiben wir zumindest in einer Kategorie von Faktoren sehr häufig.

Christoph Iserlohn: Ja, ich hatte dabei mehr so an Sachen gedacht, wo es um den Besitz geht. Also so ein Hardware Token, das du erwähnt hast, könnte ich ja auch mal verlieren. Man kann auch den Finger verlieren oder das Auge. Das wollen wir nicht hoffen, dass das passiert, aber das kann ja auch sein. Und das ist dann vielleicht unwiederbringlich verloren, um das dann wieder herzustellen muss ich dann etwas anderes haben. Da wäre es gut, wenn ich dann ein anderes Verfahren benutze oder wenigstens auf jeden Fall was anderes habe. Also ich könnte ja Besitz…, ich könnte ja auch mehrere Fingerabdrücke haben, so bei der Herstellung könnte ja auch einen anderen Fingerabdruck benutzen zum Beispiel. So, wenn man sich dann jetzt authentisiert hat und authentifiziert wurden ist, dann gibt es ja noch den Begriff der Autorisierung. Wie unterscheidet der sich denn jetzt von der Bedeutung?

Stefan Bodewig: Ja, die beiden decken einfach unterschiedliche Themengebiete ab. Authentisierung/Authentifizierung auf der einen Seite entscheidet darüber: Wer ist das, mit dem ich aus Sicht von so einem System dann gerade spreche? Autorisierung ist der Themenkomplex: Was darf diese Person, dieses etwas mit dem ich auf der anderen Seite spreche eigentlich?

Christoph Iserlohn: Gut, setzt denn dann eine Autorisierung, also was darf ich machen, immer eine Authentifizierung voraus?

Stefan Bodewig: Nein, wir haben also ganz klassisch den Bereich, wenn wir im Softwarebereich bleiben, Webseiten, Webseiten darf jeder sich angucken, zumindest ganz große Teile von Webseiten, ohne dass dazu die Webseite wissen muss: Wer ist denn da? Also es gibt den anonymen Benutzer, der nie sich irgendwo authentisiert hat, der aber dennoch offensichtliche Rechte hat. Und es gibt durchaus Konstellationen in denen jemand, ein Teilnehmer an einer Kommunikation nachweist, dass er etwas darf, ohne dass ich weiß wer denn das ist. Also ich habe die Berechtigung bekommen im Namen von jemand anderen was zu tun und ich zeige dir, dass ich diese Berechtigung habe, ohne dass du dazu wissen musst, wer ich eigentlich bin. Solche Konstrukte gibt es ja durchaus auch.

Christoph Iserlohn: Gut, das heißt da spielen dann ganz verschiedene Sachen eine Rolle. Also, jetzt hast du gerade auch schon davon geredet, wer denn…, dass da Dinge oder Personen sind, die etwas tun und Dinge, an denen man etwas tut. Und manchmal geht es auch um die Identität, die dabei eine Rolle spielt, manchmal muss man das auch gar nicht wissen und in der Literatur wird da auch oft von Subject, Object und Principle gesprochen. Kannst du diese Begriffe mal kurz erklären und auseinanderhalten?

Stefan Bodewig: Ja, gerne. Also ich habe eben schon so ein bisschen rumlaviert über etwas und jemanden, die irgendetwas tun wollen, gesprochen, um auch vielleicht …, weil es nicht immer klar ist, ob da überhaupt ein Mensch dahintersteckt. Also es gibt irgendjemanden, irgendetwas, die möchten etwas machen, das wäre dann eben Subject, sowie im englischen Satz. Das Subject ist das, was auch immer in dem Satz etwas tun möchte, das Object ist das, dem etwas angetan wird. Also in so einem Beispiel wie der Webseite wäre die Seite, die ich da angucke, das Object und ich, der ich das angucke, vor meinem Browser sitze, bin das Subject in dieser Interaktion. Und Principle war noch der Begriff, den du erwähnt hattest, der Principle ist eigentlich etwas, was man nicht in allen Zusammenhängen wirklich als Begriff sieht. Principle ist im Wesentlichen ein identifizierter Teilnehmer an so einer Kommunikation, ein identifizierbarer und eindeutig identifizierter Teilnehmer. Ein Subject kann jemand sein von dem ich genau weiß wer es ist, also ein angemeldeter Benutzer oder… dann wäre es auch ein Principle gleichzeitig oder ein Principle ist vielleicht auch manchmal Object, das weiß ich gar nicht so genau. Gibt es sicherlich Konstrukte, in denen das auch mal so sein kann.

Christoph Iserlohn: Gut, das heißt also das Subject ist zum Beispiel auch eine Untermenge vom Principle. Also das Subject tut immer was und das kann identifiziert sein, muss es aber nicht, kann da einfach nur Rechte haben. Aber Principle ist immer identifiziert.

Stefan Bodewig: Ja.

Christoph Iserlohn: Müssen das denn… Was sind denn so Subjects oder Principles zum Beispiel? Sind das immer Menschen?

Stefan Bodewig: Nö, also das habe ich glaube ich auch irgendwo gerade schon so ein bisschen versucht zu sagen, anzudeuten zumindest, dass es natürlich auch andere Systeme sein können. Also wenn zwei Stücke Software miteinander sprechen, dann muss da nicht zwingend ein Mensch dran beteiligt sein. Den Roboter der Suchmaschine der Websites heimsucht, der ist auch ein Subject. Der möchte auch die Website durchlaufen, injizieren, ohne dass da ein Mensch dahinter sitzt und trotzdem ist dieser Robot ein Subject.

Christoph Iserlohn: Okay, das heißt wir haben es nicht nur mit Menschen zu tun, sondern generell mit einem Etwas, was irgendeine Handlung vollführen kann. Das können Menschen sein, das können Prozesse sein, das können ganze Server sein im verteilten System. Das ist sozusagen irgendetwas beliebiges, aber das hat die Absicht irgendetwas zu tun an dem Object. Und Object muss dann auch… kann dann auch etwas Beliebiges sein. Das kann vielleicht sein ein File oder das kann auf der Datenbank sein oder auf dem Netzwerk etwas, das ist erstmal prinzipiell egal.

Stefan Bodewig: Ja, das kann irgendetwas völlig abstraktes auch sein.

Christoph Iserlohn: Gut. Also jetzt wo ich gerade das Beispiel genannt habe vom Filesystem, da habe ich auch schon den Begriff Access Control gehört. Was ist denn das? Ist das dasselbe wie Autorisierung? Gehört das zusammen? Oder gibt es da auch wieder einen feinen Unterschied, sowie Authentisierung und… Autorisierung und Authentisierung auch feine Unterschiede haben? Oder ist das im Prinzip erstmal das Gleiche?

Stefan Bodewig: Tatsächlich muss ich zugeben, dass ich die Begriffe vermutlich nicht sauber voneinander trenne. Das ich da im Zweifel auch, wenn ich drüber spreche, fast immer wahrscheinlich Autorisierung verwende, selbst wenn Access Control richtig wäre an der Stelle. Access Control ist dann das Überprüfen dessen, dass ich das tatsächlich darf und die Autorisierung ist die Menge an Policies die festlegen, was ich darf… Ich weiß es gar nicht so genau, wie würdest du das trennen?

Christoph Iserlohn: Ja, da hast du gerade nochmal einen schönen Begriff reingebracht: Policy, das sollten wir vielleicht gleich nochmal besprechen. Aber soweit ich das gelernt habe, ist die Autorisierung erstmal sozusagen das Verteilen der Rechte. Also nehmen wir mal an, ich habe mich authentisiert, dann gibt mir irgendjemand die Autorisierung irgendetwas zu tun, das heißt aber noch nicht, dass ich das tue. Aber wenn ich das dann tue, dann setzt der Access Control Mechanismus ein und der überprüft das, ob ich diese Rechte habe. Also das ist dann sozusagen wieder die andere Seite. Also ich bin autorisiert das zu tun, ich habe eine Autorisierung bekommen und wenn es dann getan wird, muss dann ja auch irgendjemand überprüfen und das macht das Access Control System. Soweit. Aber da muss ich auch zugeben, in der Praxis sind das auch so etwas schwammige Begriffe, die werden dann öfter mal zusammengesetzt oder beziehungsweise nicht zusammengesetzt, sondern gegeneinander ausgetauscht oder für dasselbe gebraucht. Welche verschiedene Access Control Systeme es so gibt, können wir mal gleich besprechen. Ich würde gerne nochmal bei dem Filesystem Beispiel bleiben, da gibt auch immer jedenfalls unter Unix System so eine Access Control List. Kannst du mal das erklären, was das ist? Du bist ja auch ein alter Unix Hase.

Stefan Bodewig: Oh Gott, ja. Access Control List ist wahrscheinlich schon fortgeschrittener, als der alte Unix Hase tun würde, …im klassischem Unix Dateisystem habe ich halt die drei Kategorien von Besitzer von irgendeiner Datei, der Gruppe, die diese Datei besitzt und allen anderen. Und denen kann ich getrennte Berechtigungen vergeben, dass ich da sage: Diese Datei darf gelesen werden, geschrieben werden und was ausführbar ist, auch ausführt werden. Access Control List gehen dann glaube ich noch ein bisschen weiter über diese Granularität von… Also Access Control List zumindest in der Form wie man sie dann spezifisch für bestimmte Dateisysteme unter Linux macht über diese jeweiligen Dreiklänge, es gibt drei Arten von Zugriffswegen: Lesen, Schreiben, Ausführen. Und die drei Kategorien: Owner, Group und Other. Bei Access Control List kann ich das dann eben ein bisschen Feingranularer steuern, dass ich eben nicht für eine komplette vielleicht den Zugriff erlaube, sondern für eine einzelne Person, die sich nicht in meiner Gruppe befindet. Kann ich solche Dinge… Also die Control List legt fest für ein bestimmtes Objekt im Dateisystem: Wer darf darauf zugreifen und wenn? Womit? Was darf dieses Subject machen mit der Datei?

Christoph Iserlohn: Gut und wenn wir das sozusagen mal verallgemeinern heißt das, an irgendeinen Object hängt dann eine Liste, die Access Control List und die bestimmt… oder da ist hinterlegt, welches Subject welche Operation auf diesem Object ausführen kann.

Stefan Bodewig: Ja.

Christoph Iserlohn: Gut. In dem Zusammenhang gibt es dann auch immer mal den Begriff: Access Control Matrix. Weißt du denn was das ist? Beziehungsweise, du weißt das bestimmt. Kannst du uns das mal erklären was das ist?

Stefan Bodewig: Ja, im Wesentlichen nehme ich diese Liste für alle Objekte und packe die nebeneinander. Und bekomme dann eine Matrix, würde ich vereinfacht sagen. Also ich habe meine Objects als Spalten und meine Subjects als Zeilen und da, wo die sich treffen steht drin, was darf denn das Subject für dieses Object?

Christoph Iserlohn: Okay, das heißt ich hätte dann, wenn ich das für alle meine Subjects und Objects aufzeichne, … erstmal brauche ich da eine große Wand, aber zweitens hätte ich dann eine Übersicht über mein gesamtes Berechtigungskonzept sozusagen. Oder beziehungsweise über die realen Berechtigungen, vielleicht stimmen die ja nicht überein mit meinem Berechtigungskonzept, das könnte ich zum Beispiel damit ablesen.

Stefan Bodewig: Ja.

Christoph Iserlohn: Okay. So, eine Access Control List ist jetzt halt eine Form von Access Control, da gibt es aber ganz viele. Und ganz viele enden mit den… Also wenn man die abkürzt, die Abkürzungen enden mit dem Buchstaben BAC, da gibt es irgendwie RBAC, ABAC, CBAC, da gibt es noch ganz viele. Willst du das mal erklären? Also wofür stehen überhaupt diese Buchstaben und was… Wir können da mal beispielhaft das RBAC nehmen oder das ABAC und dann mal zeigen, was das überhaupt bedeutet und wie das funktioniert.

Stefan Bodewig: Ja, das RBAC ist ‚Role Based Access Control‘, also die Berechtigungsprüfung basiert ausschließlich auf einer Rolle, die das Subject besitzt oder nicht besitzt. Das heißt Subjects sind Rollen zugeordnet und den Rollen sind Berechtigungen zugeordnet. Und zwar nicht immer eins zu eins, sondern es können viele Subjects können in einer Rolle sein, ein Subject kann mehrere Rollen innehaben, Berechtigungen können eben vielen Rollen gleichzeitig zugewiesen sein und auch eine Rolle kann mehrere Berechtigungen bedeuten. Auf diese Art und Weise bekomme ich die Rolle als eine Indirektion, die es mir erstmal einfacher macht meine Matrix von der wir eben gesprochen haben ein bisschen übersichtlicher zu gestalten, indem ich dann in den Zeilen nicht mehr jedes einzelne Subject stehen haben muss, sondern da nur noch hoffentlich weniger Rollen drinstehen habe als ich Subjects besitze. Und die Berechtigungen sind möglicherweise dann auch solche, die ich über ganze Gruppen von Objects hinweg anwende, sodass ich auch da meine Matrix ein bisschen schmaler bekomme und auf die Berechtigung als spalten gehen kann. Und dann so ein bisschen weiter fortgeschrittene Aspekte können dann noch Rollen wiederum noch Rollen haben, das ich so eine Hierarchie von Rollen vielleicht bekomme. Das also bestimmte Rechte für die Benutzergruppe von grundsätzlichen Anwendern gelten und dann gibt es Manager, die dürfen ein bisschen mehr. Aber diese Manager sind gleichzeitig auch normale Anwender, sodass sich alle die Berechtigungen, die normale Anwender hätten nicht nochmal neu für Manager definieren müsste. Das ich also solche Hierarchien von Rollen vielleicht aufbauen kann. Das ist so die klassische RBAC Sicht der Welt, die wir aber… die sich relativ gut abbilden lässt auf das, was ich eben über Unix Dateisysteme beschrieben habe. Da ist also eine Rolle die des Besitzers einer Datei, dann kann ich die Rolle haben, dass ich der Gruppe angehöre oder ich bin in der Rolle, ich gehöre zu einen anderen. Als Besitzer bin ich vielleicht auch noch in der richtigen Gruppe, also hier hätte ich schon zwei Rollen, die mir zugewiesen werden. Darauf passt es jetzt ganz gut, wenn wir aber über komplexere Berechtigungsdinge nachdenken, dann reicht die Rolle oft alleine nicht aus. Also da brauche ich vielleicht noch zusätzliche Informationen über den Benutzer, Beispiele sind: Ich darf nur… Ein Beispiel, das mir gerade einfällt, ist aus dem Krankenhausbereich, dass das Krankenpflegepersonal nur auf die Krankenakten der Patienten zugreifen darf, die in der richtigen Station sind, nämlich der wo das Pflegepersonal gerade tätig ist. Dann geht es also nicht nur darum, dass ich zum Krankenpflegepersonal gehöre in der Frage, ob ich auf eine bestimmte Akte zugreifen darf, sondern dann brauche ich schon Eigenschaften für die Akte. Die gehört zu einem bestimmten Patienten, auf der Station ist der und auch Eigenschaften des Subjects, wo ist denn die Person in der Rolle Krankenpflegepersonal gerade eingesetzt. Dann sind wir so ein Stück weg von reinen Lehre von RBAC und dann sind wir in der verallgemeinerten Variante, dass wir eben Attribute brauchen, sowohl vom Subject, als auch vom Object, um am Ende die Entscheidung treffen zu können ob Zugriff erlaubt ist. Diese Verallgemeinerung ist Attribute Based Access Control und da sind wir bei ABAC. Genau.

Christoph Iserlohn: Gut.

Stefan Bodewig: Sehr häufig finden wir, wenn wir irgendwelche Managementsysteme für irgendetwas bauen dann eher den Fall, dass wir eigentlich im Großen und Ganzen RBAC machen, aber mit so einen kleinen Winkel dran. Also ich darf Dinge ändern, aber nur meine eigenen, sowas in dieser Form. Also grundsätzlich: Ich bin in einem Shop, als Benutzer angemeldeter darf ich im Produktkatalog suchen und ich darf Dinge in einen Warenkorb tun. Aber nicht einen beliebigen Warenkorb, sondern nur in meinen eigenen. Ich habe also das Recht Dinge einen Warenkorb hinzuzufügen, aber nicht jedem Warenkorb. Da gehört dann zumindest noch das Attribut dazu, dass es auch mein eigener Warenkorb ist.

Christoph Iserlohn: Gut. Also du hast schonmal schön dieses BAC am Ende ist immer Based Access Control und davor kommt dann immer noch ein Wort, in dem Fall, wo du das jetzt erklärt hast war das Role Based. Was wir wohl… Was uns allen wahrscheinlich schon sehr häufig begegnet ist, was wie du uns schön erklärt hast auch in der Wirklichkeit gar nicht so ist, dass wir eigentlich so einen ABAC machen. Also eine Attribute Based oder eine Mischform davon. Was ich auch dabei kenne, ist auch noch CBAC, das ist Context Based Access Control, wo dann auch sozusagen der, statt einem Attribut, der Kontext mit in die Entscheidung reingezogen wird, ob der Zugriff gewährt wird oder nicht. Das ist zum Beispiel bei so einer stateful firewall der Fall, die jetzt sozusagen nicht nur sagt: Mein Programm kann eine Netzwerkverbindung zu folgendem Server aufmachen, sondern auch auf der Verbindung guckt, was denn da ausgetauscht wird, also sozusagen den Kontext des Datenaustausches mit in Betracht zieht, um da vielleicht zu erlauben welches Protokoll gesprochen wird. Das wird wahrscheinlich auch noch ohne Kontext gehen, weil man die ja auch gut unterscheiden kann von welchen Ports und so. Aber wenn wir dann sowas haben wie so eine Web Application Firewall, der sich halt auch den Inhalt ansehen muss und zum ein Beispiel unterscheiden muss: Ist das jetzt ein gefährlicher Pilot, der in diesem http request drinnen ist? Das kann das ja nur aus dem Kontext erkennen. Also klar, es gibt da Attribute, da kann man relativ ein klares Muster erkennen, aber bei ausgefeilteren Angriffen müsste das dann auch den gesamten Kontext miteinziehen.

Stefan Bodewig: Und das ist im Prinzip das hinzunehmen von Dingen, die weder am Subject noch am Object hängen, sondern eben noch ein Stück drüber hinausgehen. Ich kenne sowas auch beispielsweise, dass man die Uhrzeit oder das Datum mitberücksichtigen muss, dass man eben bestimmte Zugriffe nur in bestimmten Zeitfenstern erlauben möchte und in anderen eben so ein Zugriff nicht möglich ist. Und auch das hängt ja nicht direkt weder am Subject noch am Object, sondern das ist auch Kontext dann in dem Fall. Oder Environment, weiß aber dann nicht, wie man das BAC nennt, wie man das benutzen würde, ob das alles noch unters CBAC fallen würde.

Christoph Iserlohn: Ja, also diese Begriffe werden ja auch oft nicht auch so trennscharf benutzt und sind sie ja auch nicht. Also in der Theorie schon, in der Praxis natürlich nicht unbedingt. Da wir jetzt bei den ganzen Akronymen sind, da gibt es noch zwei weitere, die wir da haben, die mich interessieren, das ist einmal das MAC und das DAC. Also ich weiß wofür die stehen, das MAC ist das Mandatory Access Control und vielleicht willst du uns das auch nochmal erklären, was das bedeutet?

Stefan Bodewig: Das D ist dann Discretionary, also das in DAC. In dem einen Fall, Mandatory Access Control heißt das, es gibt Regeln die sind für das komplette System festgelegt wurden und die gelten immer. Und niemand hat die Möglichkeit diese Regeln zu überschreiben. Die sind klassisch tatsächlich in solchen Bereichen bei denen wir über Beeinhaltung verschiedener Zugriffsberechtigungslevel sprechen in militärischen oder administrativen Bereichen, da kommen die ursprünglich her. Das also nur jemand, der die entsprechenden Freigaben hat überhaupt in der Lage sein darf Dokumente, die das Label Secret haben lesen zu dürfen beispielsweise. Davon abgegrenzt, Discretionary Access Control heißt, ich als Eigentümer eines Objects, das Konzept von Eigentümer ist vielleicht manchmal auch gar nicht gegeben in so einen Mandatory Access Control Zusammenhang. Ich als Eigentümer eines Objekts entscheide selber darüber, welche Zugriffe ich denn erlaube auf das Objekt. Das ist auch wieder im klassischen Unix Dateisystem, kann ich als Eigentümer einer Datei festlegen wer diese Datei lesen darf und könnte mich damit, wenn ich es unbedingt will, vielleicht sogar dafür sorgen, dass Subjects ein Objekt, dass ich angelegt habe lesen dürfen, die eigentlich nach den Regeln, die gelten sollen für das System, gar nicht erlaubt sein würden. Mandatory Access Control könnte man noch zusätzlich einfügen und sagen, das schieben wir dann noch als Layer drüber, der dann verhindert, dass solche versehentlichen oder böswilligen Zugriffsberechtigungsverletzungen möglich gemacht werden.

Christoph Iserlohn: Also der Unterscheidungspunkt ist dann sozusagen, wer die Regeln festlegt. Einmal kann das der Besitzer machen, beim DAC sozusagen, kann selber festlegen welcher Access möglich ist und bei MAC macht das irgendeine dritte Partei. Sozusagen die… Da kann das Subject oder der Owner von einem Object das nicht selber machen. Ist das so die Unterscheidung?

Stefan Bodewig: Das ist die, die ich zumindest mache, ja.

Christoph Iserlohn: Okay und du sagst man kann diese Systeme auch mischen. Hast du dafür ein Beispiel, wo das gemischt wird?

Stefan Bodewig: Ich glaube, dass das in Linux in einigen Bereichen der Fall ist, je nachdem welche Kernel Module ich zumindest eingeschaltet habe, dass dort bestimmte Regeln an Mandatory Access Control eingeschaltet werden in SELinux oder AppArmor, je nachdem welche Linux Distribution ich habe, die beispielsweise dafür sorgen würden, dass mein Webserverprozess nicht einfach an beliebige Stellen auf der Festplatte schreiben dürfte. Selbst wenn die Dateisystemberechtigungen, die eher aus dem DAC Bereich kommen es den Prozess erlauben würden, verhindert der Mandatory Access Control Bereich, der eben in diesen Kernel Modul steht, dass der wildgewordene Webserver irgendwo hinschreibt, wo er das nicht darf.

Christoph Iserlohn: Gut, also das bedeutet, dass diese beiden Verfahren also sich nicht gegenseitig ausschließen, sondern eher orthogonal arbeiten oder sind die in einer Hierarchie?

Stefan Bodewig: In dem Fall, wie ich es beschrieben habe, wären die sie ja in einer Hierarchie. Dann hätte irgendjemand vielleicht entschieden, dass der Webserver dahinschreiben darf, aber das Mandatory Access Control unterbindet das Ganze dann wieder. Also gewinnt am Ende gegen DAC.

Christoph Iserlohn: Gut. Jetzt haben wir schon öfter von so Regelwerken gesprochen. Wer definiert die denn? Und was ich schon öfter dabei gehört habe, in diesem Kontext wird immer von Policies gesprochen. Davon hast du eben auch kurz… Das hast du eben kurz mal angerissen, dass es da Policies gibt. Was heißt das denn? Also wer macht diese Regeln? Ist Regel gleich Policy? Oder was heißt Policy?

Stefan Bodewig: Wer macht diese Regeln, ist glaube ich vor allen Dingen eine organisatorische Frage und nicht unbedingt eine technische. Und Policy ist für mich, aber vielleicht nutze ich da auch die Terminologie wieder falsch, eher so eine Sammlung von Regeln, die zusammengenommen eine Policy ergeben.

Christoph Iserlohn: Gut, also Policy ist sozusagen ein Regelwerk?

Stefan Bodewig: Ja.

Christoph Iserlohn: Und du sagst das ist eine organisatorische Sache, gehen wir da mal wieder auf die Technik. Aber irgendwo müssen diese Policies doch auch da sein? Also die müssen sich ja irgendwo technisch manifestieren und irgendwie verwaltet werden und angewendet werden. Wo passiert das denn?

Stefan Bodewig: Wenn wir weiterhin in dem Bereich von Einzelplatz Unix Rechnern bleiben, dann gibt es da irgendwelche Policy Dateien, Policy Datenbanken, Regeldatenbanken, die durch Systemadministratorinnen gepflegt werden. Ansonsten, wenn wir in eine übergeordneteren Kontext gehen, wo wir Anwendungslandschaften haben, gibt es in der Regel Systeme, in denen ich eine solche Policy definieren und hinterlegen kann. Und wann immer eine Access Control Entscheidung getroffen werden muss, na gut, dann haben wir immer noch zwei verschiedene Möglichkeiten, wenn man darüber nachdenkt… Ich frage dieses System, ob ich den zugriff erteilen darf oder diese für mich wichtigen Teile der Regel werden mir vorher zugewiesen, ich muss nicht jedes Mal aktiv nachfragen. Ich verlasse mich darauf, dass ich das aktuelle Regelwerk kenne. Auf so einer Art und Weise, wenn wir so eine zentrale Stelle haben, die das definieren. Es ist aber auch denkbar, dass wir das Regelwerk komplett dezentral haben. Das es also gar nicht die zentrale Stelle gibt von der wir solche Policy definieren, sondern dass jede Anwendung für sich selber eine zentrale Stelle hat. Aber eben jede für sich und nicht die eine globale Stelle, die weiß welche Regeln denn gelten.

Christoph Iserlohn: Also was du gerade beschrieben hast, da würde ich immer direkt denken: Ist das ein aktive Directory zum Beispiel? Also der füllt so ungefähr…, also wenn zentral verwaltet wird, die Funktion, die du gerade beschrieben hast.

Stefan Bodewig: Das ist sicher nicht das einzige, dass das könnte, aber kann eben eine solche Rolle übernehmen oder eine solche Aufgabe übernehmen.

Christoph Iserlohn: Ja, das wären dann wahrscheinlich diese sogenannten Gruppenrichtlinien dort, die man wenn man Windows Rechner zum Beispiel verwaltet, die auch mit so einem active Directory gepflegt werden können, die wären dann Policies.

Stefan Bodewig: Ich muss zugeben, dass Gruppenrichtlinien nicht unbedingt meine Expertise sind.

Christoph Iserlohn: Gut. Jetzt haben wir eine ganze Menge Systeme besprochen und Verfahrensweisen. Wann sollte man denn vielleicht welches einsetzen? Beziehungsweise, anders formuliert: Welche Probleme haben denn die einzelnen Systeme? Also wann sollte ich sie vielleicht nicht einsetzen, wann wird es schwierig, wo gibt es Verbesserungsbedarf, was kann man vielleicht nicht abbilden?

Stefan Bodewig: Ja, du hast selber, als wir über die Access Control Matrix gesprochen haben, selber schon gesagt, dann brauche ich möglicherweise die riesengroße Wand, um zu sehen: Was darf denn wer? Auf der anderen Seite kann ich sehr genau sehen, was darf denn wer? Wenn ich diese Matrix habe. Bei den anderen Systemen ist das entweder so, dass die Matrix kleiner wird und damit übersichtlicher, es damit aber schwierige wird rauszufinden: Was darf denn der einzelne? Weil dann sich diese Indirektionen alle wieder rückwärts auflösen. Oder es wird unübersichtlicher, weil ich nicht mehr nur die eine Matrix habe, beispielsweise, wenn ich… Also in dem Fall, wo ich eben gesagt habe, wir haben vielleicht gar nicht die zentrale Stelle über die alle Policies definiert werden, sondern wir verteilen das, sodass jede Anwendung das für sich entscheiden kann. Dann habe ich auch nicht mehr den zentralen Überblick darüber was ein Benutzer in meiner Organisation mit irgendeiner der Anwendungen tun könnte, sondern ich muss dann rumlaufen und in der Anwendung nachschauen. Also das ist in vielen Fragefällen… Also in diesem Fall heißt es, es wird für mich, wenn ich es alles an einer zentralen Stelle habe, leichter nachzuvollziehen was jemand darf und dafür habe ich sehr große Datenvolumina, über die ich gucken muss. Und auf der anderen Seite, wenn ich es verteilt habe, wird es schwieriger. Wenn ich aber dann schaue, wie leicht finde ich für mich selber meine Entscheidung, wie gut funktioniere ich autonom, dann schlägt das Pendel so ein bisschen zurück. Dann kann ich als einzelne Anwendung für mich entscheiden, ohne dass ich abhängig davon bin, dass das andere System läuft und ich gerade fragen kann nach irgendwelchen Entscheidungen in irgendwelchen verteilten Systemen.

Christoph Iserlohn: Also dabei ist es dann genauso wie bei… Die grundsätzliche Abwägung, ob ich jetzt ein zentrales monolithisches System baue oder ein sehr verteiltes, das geht dann wahrscheinlich nicht nur für die Policies, sondern auch für viele andere Aspekte. Also einmal wichtig: Die kleine Einheit unter Kontrolle, habe aber keinen Überblick über das große Ganze dabei und schaffe vielleicht auch Abhängigkeiten zu anderen Systemen. Während bei den anderen ich halt, beim großen zentralen System, das Problem habe, dass das dann halt sehr komplex wird. Also, dass ich zum Beispiel bei so einer Access Control Matrix halt auch kognitiv völlig überfordert bin, wenn ich dafür irgendwie ein Hochhaus brauche, um die aufzukleben und dann zwar schön zentral sehen kann, wer was darf, aber ich da trotzdem nicht mehr durchblicke.

Stefan Bodewig: Ja.

Christoph Iserlohn: Gut. Gibt es denn eine Empfehlung von dir, was man wann einsetzen sollte? Oder was du am liebsten einsetzt aus deiner Erfahrung?

Stefan Bodewig: Also da muss ich natürlich erstmal das typische Berater-It depends loswerden oder so, das hängt immer davon ab, was denn jetzt gerade besonders wichtig ist. Wenn es besonders wichtig ist, dass ich zu jedem Zeitpunkt immer ganz genau prüfen kann, welcher Benutzer, welche Benutzerin, was in meinem System tun kann, dann brauche ich sowas wie das zentrale Management von Policies. Das ist in der Mehrzahl der Systeme, an denen ich bisher mitgearbeitet habe, nicht unbedingt notwendig gewesen. Und in solchen Fällen würde ich dann eher vorziehen Authorisierungsentscheidungen, also die Policies dezentral zu behalten und nur so ein paar globale Dinge vielleicht sogar außerhalb der Systeme schon stattfinden zu lassen und Zugriff auf Systeme gar nicht zu erlauben, beispielsweise in dieser Form, das zentraler zu haben. Aber das was in dem System passieren darf, dann eher dezentral abzubilden.

Christoph Iserlohn: Ja, also dieses It depends ist ja fast immer der Fall, Aussagen zu treffen, die immer stimmen, ist immer schwierig und will man wahrscheinlich auch gar nicht machen. So jetzt haben wir ganz viele As besprochen, die Authentisierung, die Authentifizierung, die Autorisierung und Access Control, aber ein letztes A bleibt noch übrig, das ist Audit. Was versteht man denn darunter? Wozu brauchen wir das denn?

Stefan Bodewig: Audit ist auf den ersten Blick sowas ähnliches wie Login. Also wann immer irgendetwas passiert im System, was etwas zu tun hat mit den anderen Dingen Authentisierung, Autorisierung, schreiben wir das irgendwo hin. Benutzer X hat sich angemeldet, jemand hat versucht sich mit dem folgenden Benutzernamen anzumelden, das hat aber nicht geklappt, weil das Passwort falsch war. Oder sowas in dieser Form, das schreiben wir erstmal irgendwo hin. Genauso wie: Ich habe Subject X den Zugriff auf irgendein Object Y erteilt, das schreibe ich irgendwo hin. Das ist eigentlich ganz ähnlich zu dem was Login ist. Der wesentliche Unterschied ist, wenn wir es richtig machen, dass im Gegensatz zu einem gewöhnlichen Log File, wir es nicht einfach irgendwo hinschrieben, wo vielleicht nochmal irgendwie geändert werden könnte, sondern idealerweise ist das, was wir da geschrieben haben, im Nachhinein nicht mehr änderbar. Sodass man dann, wenn dann irgendwas passiert sein sollte, auch nachvollziehen kann, wie welche Zugriffe erfolgt sind. Also im Wesentlichen ist das für… ist der eine Teil des Audit Trails so eine Art Post-mortem Analyse fahren zu können, wenn das Kind schon im Brunnen ist. In einem gewissen Umfang kann man es auch vielleicht im Vorfeld schon sehen bei den Beispielen. Jemand hat versucht von System A sich als Subject X Zugriff auf Object Y zu verschaffen, der das aber nicht dürfte, dann vielleicht schonmal präventiv Maßnahmen einzuleiten, weil man auf der Basis vielleicht einen stattfindenden oder einen vorbereiteten Angriff detektieren könnte, wenn man auf das Audit Log, Log in Anführungsstrichen, guckt.

Christoph Iserlohn: Gut, das heißt dann, dass aber dann auch in diesen Audit Log, soweit ich weiß nennt man das auch Audit Trail, weil man das nachverfolgen kann, relativ sensible Daten stehen, oder? Also das ist ja so, wenn das der Normalbetrieb ist, wird der ja sozusagen mit geloggt, was eigentlich der Benutzer so den ganzen lieben, langen Tag tut. Oder versucht zu tun.

Stefan Bodewig: Absolut, ja. Das ist der Fall. Also das heißt, dass wir eben nicht nur dafür sorgen müssen, dass niemand das, was wir da protokolliert haben ändern kann, sondern im Zweifel muss das auch so aufbewahrt werden, dass das niemand sehen darf und kann, der das nicht sehen sollte. Und eben auch nicht einfach mal für solche Auswertungen genutzt werden kann, sondern dass der Zugriff eben auch nur in den Fällen erfolgt, in denen es tatsächlich Grund gibt, darauf zuzugreifen. Also Dinge wie möglich Angriffe detektieren, das kann man voll automatisiert tun, das kann man auch auf Daten tun, die dann eben nicht persönlich identifizierbar sind. Ich stelle einfach fest, von einem bestimmten System wird versucht Zugriffe zu starten die nicht erlaubt sind. Vielleicht sehe ich dann noch wessen Subject, wessen Account verwendet wird, um das zu tun, aber das ist dann im Normalfall dann auch gar nicht derjenige selber, sondern auf irgendeine Art und Weise ist der Benutzername in die Hände eines Angreifers geraten. Das passiert eben automatisiert und die anderen Zugriffe passieren ja nur in einem sehr engen Kontext und nur durch dafür besonders ausgewählte Personen.

Christoph Iserlohn: Also bedeutet dann, dass wir möglichst ein gutes Bug System da draufhaben, der wenige Zugriffe erlaubt und das nicht einfach ein Logstash oder ein System reinschmeißen, das jeder durchsuchen kann.

Stefan Bodewig: Ja, natürlich.

Christoph Iserlohn: Neben dem Sicherheitsproblem oder beziehungsweise dem Erkennen von Sicherheitsproblemen, gibt es aber glaube ich noch eine Funktion und das ist halt, wenn in bestimmten Bereichen mit sensiblen Daten gearbeitet wird. Und da gibt es Datenmissbrauch, dass man dann im Nachhinein feststellen kann, wer das war. Also ich denke jetzt akut zum Beispiel das Beispiel mit den Personendaten abfragen im Bereich dieser Drohbriefe von NSU 2.0, das waren ja Dienstcomputer und da ist halt ein Zugriff erlaubt. Und man kann jetzt halt nicht so leicht feststellen, ob der jetzt berechtigt ist oder nicht. Das man dann aber, wenn das sozusagen jetzt im Nachhinein rauskommt, dass das nicht berechtigt ist, dass man dann auch sozusagen die entsprechenden Verantwortlichen finden kann. Dann kann ich das ja nicht mehr so anonym machen, sondern dann muss ich ja auch irgendwie rausfinden, wer das war.

Stefan Bodewig: Ja, aber dann glaube ich tritt dieser Aspekt ein, dass eben nur speziell dazu berechtigte Personen in einem ganz ausgewählten Prozess das dann auch nur tun dürfen im Zweifel. Auch in einem vier Augen System oder sowas in der Art, dann wiederum denjenigen, der den Audit Trail nutzt, dann nochmal zu überprüfen, dass da nicht die falschen Abfragen mitgefahren werden.

Christoph Iserlohn: Gut, das ist dann wahrscheinlich kein Access Control Problem, sondern eher ein organisatorisches Problem.

Stefan Bodewig: Definitiv.

Christoph Iserlohn: So, jetzt haben wir ganz viele As durchgesprochen. Einen Buchstaben überspringen wir jetzt, das B, sondern wir kommen nochmal zum C. Da gibt es nämlich auch noch etwas was in diesem ganzen Bereich eine Rolle spielt, das sind Capabilities, die…, das habe ich mal gelernt, dass das was ganz Tolles sein soll und eigentlich viel besser als die meisten Access Control Systeme. Was ist denn das, Capabilities?

Stefan Bodewig: Gehört habe ich das auch, dass das allen anderen überlegen ist, tatsächlich im Einsatz gehabt selber habe ich das bisher noch nicht. Mein Verständnis dessen ist, dass ich nicht nur die abstrakte Information liefere, dass ich auf irgendetwas zugreifen könnte, sondern eigentlich schon den Zugriff selber als solchen weitergebe. Also ein Beispiel, das ich irgendwo gelesen habe war das, dass ich eben nicht sage: Ich möchte auf diese Datei zugreifen und da habe ich übrigens Lesezugriff drauf, sondern ich gleich den offenen Datei Deskriptor in Unix spreche, durchreiche und damit nachgewiesen habe, dass ich offensichtlich das Recht hatte die Datei zu lesen. Und ich gebe dann die geöffnete Datei weiter an jemand anderen, damit der in meinem Auftrag damit etwas tun kann. Das ist das, was ich über Capabilities an der Stelle theoretisch weiß, dass das so funktionieren soll.

Christoph Iserlohn: Ja, das Beispiel, das ich immer mitbekommen habe, schon an verschieden Stellen, ist halt gar nicht aus der IT-Sicherheit, sondern aus der realen Welt, ist halt der Türschlüssel. Mit dem Türschlüssel habe ich halt die Capability irgendeine Tür aufzuschließen und den Türschlüssel könnte ich halt auch an irgendjemanden weitergeben, dann hat der das halt. Das ist so wie du das gerade genannt hattest, den File Deskriptor, den könnte ich ja auch weitergeben und erstmal durch diesen Besitz kann ich das haben. Aber Capabilities sind dann halt diese Berechtigungen, die ich sozusagen an jemand anderes weitergeben kann. In der Praxis ist mir das aber auch noch nicht begegnet. Kennst du denn irgendein System, auch wenn du nicht selber damit gearbeitet hast, dass das irgendwie implementiert?

Stefan Bodewig: Also ich weiß, dass es das als Aufsatz für andere Systeme gibt. Es gibt glaube ich irgendwelche universitären Projekte das auch in Betriebssysteme direkt einzubuggen, ich glaube im FreeBSD Kontext gibt es ein Projekt, dessen Namen mir schon wieder entfallen ist, das irgendwo auch CAP mit im Namen hat, aber ich komme nicht bis zum Ende dessen. Ich weiß es nicht, kennst du das?

Christoph Iserlohn: Ich weiß es auch nicht genau, Capsicum oder so ähnlich heißt das meine ich. Ich bin mir da aber auch bei dem Namen nicht ganz sicher. Schreiben wir vielleicht mal in die Shownotes rein, einen Link dazu. Dann können wir aber vielleicht zusammenfassen, dass das zwar immer wieder Thema in der Theorie ist, aber in der Praxis eigentlich keine Rolle spielt. Also den klassischen Gegensatz zwischen was in der akademischen Welt passiert und in der realen Softwareentwicklung dann halt doch nicht so ist, beziehungsweise vielleicht noch nicht so weit ist. Und das vielleicht schon in der Theorie überlegen ist, kann ja sein, dass es nochmal doch irgendwann kommt, eine Implementierung, die sich dann durchsetzt.

Stefan Bodewig: Ja, oder irgendjemand wird uns in den Kommentaren belehren, dass wir keine Ahnung haben und dass das selbstverständlich schon ganz viel Praxisrelevanz hat.

Christoph Iserlohn: Ja, das kann natürlich auch sein. So, wir haben jetzt eine ganze Menge heute besprochen. Damit würde ich die Folge gerne schließen. Es sei denn du hast jetzt… Dir ist noch eine ganz wichtige Ergänzung zu irgendeinem Thema eingefallen?

Stefan Bodewig: Nein.

Christoph Iserlohn: Wenn das nicht so ist, dann können wir… Oder doch so sein sollte noch im Nachhinein, schreiben wir das natürlich in die Shownotes. Ansonsten gebe ich mal einen kleinen Ausblick auf die nächsten Folgen, da werden wir uns nämlich weiter mit diesen Themen beschäftigen, dann aber nicht nur mit den Begrifflichkeiten und mit Beispielen aus der realen Welt, wie Schlüsseln und Haustüren und ähnlichen, sondern da werden wir dann eher auf die technischen Systeme eingehen. Auf jeden Fall wird OAuth, OAuth2 ein Thema sein, open ID connect wird ein Thema sein, wir werden noch über Multifaktor Authentisierung sprechen und ich hoffe bis dahin geht es euch allen ganz gut. Ich bedanke mich, ich bedanke mich bei dir Stefan, ich bedanke mich bei unseren Hörern und Hörerinnen und sage dann bis zum nächsten Mal! Und wenn es euch gefallen hat, gibt uns eine gute Bewertung und wenn ihr Kommentare habt oder Ergänzungen könnt ihr uns gerne an [email protected] schreiben, die E-Mail Adresse ist auch nochmal auf der Homepage des Podcasts zu finden. Und damit sage ich bis zum nächsten Mal! Ciao Stefan!

Stefan Bodewig: Tschüss!