Model driven security from UML models to access control architectures [Elektronische Ressource] / vorgelegt von Torsten Lodderstedt

Model Driven Securityfrom UML Models to Access Control ArchitecturesDissertation zur Erlangung des Doktorgrades der Fakultat fur Angewandte¨ ¨Wissenschaften der Albert-Ludwigs-Universita¨t Freiburg im Breisgauvorgelegt von Torsten Lodderstedt2003• Dekan: Prof. Dr. Thomas Ottmann• Pru¨fungskommision:– Prof. Dr. Stefan Leue– Prof. Dr. Christoph Scholl– Prof. Dr. David Basin– Prof. Dr. Gunter Muller¨ ¨• Termin der Disputation: 15.03.20042ZusammenfassungSicherheit ist ein integraler Bestandteil moderner IT-Systeme und die Ent-wicklung solcher Systeme erfordert es, die notwendigen Sicherheitstechnolo-gien zu identifizieren und sie zu integrieren. Beispiele fur solche Technologien¨sindZugriffskontrollezumSchutzvonSystemressourcenvorunerlaubtemZu-¨griff,Verschlusselung,umdieVertraulichkeitvonDatenwahrendihrerUber-¨ ¨tragung u¨ber ein Netzwerk zu schu¨tzen, und die Verwendung von digitalenSignaturen zum elektronischen Unterzeichnen von Vertragen. Obwohl eine¨große Anzahl von Sicherheitsarchitekturen und -technologien verfu¨gbar ist,gibt es beinahe taglich Berichte von Fehlern in den Sicherheitsmechanismen¨von IT-Systemen.Warum ist es so schwierig, robuste, sichere Systeme zu entwickeln? EineAnalyse der Softwareentwicklungsprozesse wie sie heute typischerweise ange-wendet werden zeigt, daß Sicherheit nicht systematisch sondern zumeist adhoc behandelt wird.
Publié le : jeudi 1 janvier 2004
Lecture(s) : 18
Tags :
Source : FREIDOK.UB.UNI-FREIBURG.DE/FREIDOK/VOLLTEXTE/2004/1253/PDF/THESIS_T_LODDERSTEDT.PDF
Nombre de pages : 156
Voir plus Voir moins

Model Driven Security
from UML Models to Access Control Architectures
Dissertation zur Erlangung des Doktorgrades der Fakultat fur Angewandte¨ ¨
Wissenschaften der Albert-Ludwigs-Universita¨t Freiburg im Breisgau
vorgelegt von Torsten Lodderstedt
2003• Dekan: Prof. Dr. Thomas Ottmann
• Pru¨fungskommision:
– Prof. Dr. Stefan Leue
– Prof. Dr. Christoph Scholl
– Prof. Dr. David Basin
– Prof. Dr. Gunter Muller¨ ¨
• Termin der Disputation: 15.03.2004
2Zusammenfassung
Sicherheit ist ein integraler Bestandteil moderner IT-Systeme und die Ent-
wicklung solcher Systeme erfordert es, die notwendigen Sicherheitstechnolo-
gien zu identifizieren und sie zu integrieren. Beispiele fur solche Technologien¨
sindZugriffskontrollezumSchutzvonSystemressourcenvorunerlaubtemZu-
¨griff,Verschlusselung,umdieVertraulichkeitvonDatenwahrendihrerUber-¨ ¨
tragung u¨ber ein Netzwerk zu schu¨tzen, und die Verwendung von digitalen
Signaturen zum elektronischen Unterzeichnen von Vertragen. Obwohl eine¨
große Anzahl von Sicherheitsarchitekturen und -technologien verfu¨gbar ist,
gibt es beinahe taglich Berichte von Fehlern in den Sicherheitsmechanismen¨
von IT-Systemen.
Warum ist es so schwierig, robuste, sichere Systeme zu entwickeln? Eine
Analyse der Softwareentwicklungsprozesse wie sie heute typischerweise ange-
wendet werden zeigt, daß Sicherheit nicht systematisch sondern zumeist ad
hoc behandelt wird. In vielen F¨allen werden Sicherheitsanforderungen erst
kurz vor oder wahrend der Inbetriebnahme eines Systems analysiert und im-¨
plementiert. Hinzu kommt, daß die Systementwicklung und die Realisierung
vonSicherheitmechanismenzumeistgetrenntvonverschiedenePersonengrup-
pen durchgefu¨hrt werden, den Software-Entwicklern auf der einen Seite und
den Sicherheitsexperten auf der anderen Seite. Dafur gibt es technologische¨
und kulturelle Gru¨nde.
Insbesondere muß man ein Defizit an Methoden und Werkzeugen kon-
statieren, die eine enge Integration der Sicherheit in den allgemeinen Soft-
wareentwicklungsprozeß unterstutzen. Selbst Standardprozesse, wie der Ra-¨
tional Unified Process [26] oder das deutsche V-Modell [15] geben nur ober-
flachliche Hinweise, wie Sicherheit berucksichtigt werden sollte. Des weite-¨ ¨
ren spielt die Sicherheit im typischen Projektplan keine prominente Rolle
und sie wird auch durch die Struktur der meisten Entwicklungsorganisatio-
nen nicht unterstu¨tzt. Auch dort kann man eine starke Trennung zwischen
Software-Entwicklern undSicherheitsexperten beobachten. Das Resultat die-
ser Vorgehensweise sind IT-Systeme in denen die Sicherheit als nachrangiges
Problem behandelt wird und wo Sicherheitsmechanismen nur schlecht in das
Gesamtsystem integriert sind.
DieNotwendigkeitdieseMangelzubehebenwurdeninderLiteraturschon¨
festgestellt (z.B. in [14]) und die zunehmende Nachfrage am Markt nach Sy-
stemen mit zertifizierten Sicherheitseigenschaften verstarkt den Druck. Denn¨
Zertifizierungsstandards wie die “Information Technology Security Evalua-
tionCriteria”[35]oderdie“CommonCriteria”[11]erfordernvorallenDingen
eines: einen ausgereiften Softwareentwicklungsprozeß, in welchem Sicherheit
ein integraler Bestandteil ist.
3Wir schlagen Model Driven Security als eine Methode vor, um diese De-
fizite zu beheben. Die Kernidee von Model Driven Security ist, daß Softwa-
redesigner IT-Systeme in Modellen spezifizieren, welche auch die gewunsch-¨
ten Sicherheitseigenschaften des Systems beschreiben. Basierend auf diesen
Modellen werden dann mit Hilfe von Werkzeugen Systemarchitekturen mit
komplettenundvollstandigkonfiguriertenSicherheitsmechanismengeneriert.¨
Auf diese Weise ermo¨glicht Model Driven Security die enge Integrati-
on von Sicherheit in den Entwicklungsprozess. Unsere Methode kann daher
verwendet werden, um die Produktivit¨at bei der Entwicklung von sicheren
Softwaresystemen zu erhohen und die Qualitat der resultierenden Systeme¨ ¨
zu verbessern.
Anstatt eine einzige Modellierungssprache fur diesen Prozeß vorzugeben,¨
schlagen wir ein Schema fu¨r die Definition solcher Sprachen vor, in welchem
Sprachen fur die Systemmodellierung mit solchen fur die Modellierung von¨ ¨
Sicherheitseigenschaften kombiniert werden.
Wir pra¨sentieren verschiedene Beispiele fu¨r die Anwendung dieses Sche-
mas, in welchen UML-basierte Modellierungssprachen mit einer Sprache fur¨
dieSpezifikationvonZugriffskontrollmodellenkombiniertwerden.Wirzeigen
außerdem, wie auf der Basis von Modellen in diesen Sprachen Zugriffskon-
trollarchitekturen fu¨r verteilte Systeme generiert werden ko¨nnen. Die Model-
lierungssprachen und der Generierungsprozess sind semantisch wohl fundiert
und basieren auf einer Erweiterung von rollenbasierter Zugriffskontrolle. Wir
haben unsere Methode in einem Werkzeug implementiert, welches wir im
Rahmen einer Fallstudie angewendet haben, und wir berichten von unseren
Erfahrungen.
4Preface
We present a new approach to building secure systems. In our approach,
which we call Model Driven Security, designers specify system models along
with their security requirements and use tools to automatically generate sys-
tem architectures from the models including complete, configured security
infrastructures. Inthatway, ModelDrivenSecurityhelpstotightlyintegrate
securityintothesoftwaredevelopmentprocess. Asaresult,ourapproachcan
beusedtoimproveboththeproductivityofthedevelopersofsecuresoftware
systems and the quality of the resulting systems.
Rather than fixing one particular modeling language for this process, we
propose a schema for constructing such languages that combines languages
for modeling systems with languages for modeling security. Thus the schema
allows language designers to leverage expert know-how that is required to
define a modeling language for a particular area as well as accompanying
methods and tools.
We present different instances of this schema, which combine different
UML modeling languages with a security modeling language for formalizing
access control requirements. From models in these languages, we automati-
cally generate access control architectures for distributed applications. The
modelinglanguagesandgenerationprocessaresemanticallywell-foundedand
arebasedonanextensionofrole-basedaccesscontrol. Wehaveimplemented
this approach in a prototypical tool that we used to conduct a case study
and report on experiences.
56Contents
1 Introduction 11
1.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Background 19
2.1 A Design Problem . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Model Driven Architecture . . . . . . . . . . . . . . . . . . . . 20
2.2.1 The Unified Modeling Language . . . . . . . . . . . . . 21
2.2.2 The Meta Object Facility . . . . . . . . . . . . . . . . 25
2.2.3 Defining Modeling Languages . . . . . . . . . . . . . . 28
2.2.4 Model Transformations . . . . . . . . . . . . . . . . . . 30
2.3 Role-Based Access Control . . . . . . . . . . . . . . . . . . . . 30
2.4 Security Architectures . . . . . . . . . . . . . . . . . . . . . . 32
2.4.1 Enterprise JavaBeans . . . . . . . . . . . . . . . . . . . 32
2.4.2 Enterprise Services for .NET . . . . . . . . . . . . . . . 35
2.4.3 Java Servlets . . . . . . . . . . . . . . . . . . . . . . . 35
3 Model Driven Security: an Overview 37
3.1 Language Definition Techniques . . . . . . . . . . . . . . . . . 39
3.1.1 MOF-Mapping to Relational Models . . . . . . . . . . 39
3.1.2 The Role of Semantics in Model Driven Security . . . . 41
3.2 Combining Modeling Languages . . . . . . . . . . . . . . . . . 41
3.3 Model Transformation . . . . . . . . . . . . . . . . . . . . . . 44
3.4 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 SecureUML 47
4.1 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Concrete Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Building SecureUML Dialects . . . . . . . . . . . . . . . . . . 53
4.3.1 Integrating the Abstract Syntax . . . . . . . . . . . . . 54
4.3.2 Integrating the Concrete Syntax . . . . . . . . . . . . . 55
74.3.3 The Structure of Security Design Models . . . . . . . . 56
4.4 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.1 Static Part . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.2 Dynamic Part . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.3 Default Behavior . . . . . . . . . . . . . . . . . . . . . 62
5 Example Modeling Language: ComponentUML 63
5.1 Language Definition . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 SecureUML Dialect for ComponentUML . . . . . . . . . . . . 65
5.2.1 Extending the Abstract Syntax . . . . . . . . . . . . . 65
5.2.2 Formal Definition of ComponentUML Models . . . . . 68
5.2.3 Extending the Concrete Syntax . . . . . . . . . . . . . 70
5.3 Example Authorization Policy . . . . . . . . . . . . . . . . . . 72
5.3.1 Policy Semantics . . . . . . . . . . . . . . . . . . . . . 73
6 Generating Systems from ComponentUML Models 75
6.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2 Enterprise JavaBeans . . . . . . . . . . . . . . . . . . . . . . . 77
6.2.1 Basic Generation Rules for EJB . . . . . . . . . . . . . 77
6.2.2 Generating Access Control Infrastructures . . . . . . . 81
6.3 Correctness of Generation . . . . . . . . . . . . . . . . . . . . 91
6.3.1 Informal Semantics of EJB Access Control . . . . . . . 91
6.3.2 Proof Strategy and Discussion . . . . . . . . . . . . . . 92
6.4 Verification of the Sub-function for Declarative Access Control 95
6.4.1 EJB Declarative Access Control . . . . . . . . . . . . . 96
6.4.2 Model Transformation Function . . . . . . . . . . . . . 97
6.4.3 Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.5 Transformation Function for .NET Systems . . . . . . . . . . 103
6.5.1 Basic Generation Rules for .NET . . . . . . . . . . . . 103
6.5.2 Generating Access Control Infrastructures . . . . . . . 104
7 ControllerUML 107
7.1 Language Definition . . . . . . . . . . . . . . . . . . . . . . . 107
7.2 SecureUML Dialect for ControllerUML . . . . . . . . . . . . . 109
7.2.1 Extending the Abstract Syntax . . . . . . . . . . . . . 110
7.2.2 Extending the Concrete Syntax . . . . . . . . . . . . . 111
7.3 Example Authorization Policy . . . . . . . . . . . . . . . . . . 112
7.4 Transformation to Web Applications . . . . . . . . . . . . . . 113
7.4.1 Basic Transformation Function . . . . . . . . . . . . . 113
7.4.2 Generating Access Control Infrastructures . . . . . . . 115
88 Tool Support and Development Process 119
8.1 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.1.1 Tool Foundation . . . . . . . . . . . . . . . . . . . . . 119
8.1.2 Prototype Architecture . . . . . . . . . . . . . . . . . . 120
8.1.3 OCL Support . . . . . . . . . . . . . . . . . . . . . . . 121
8.1.4 Security Designer . . . . . . . . . . . . . . . . . . . . . 122
8.2 Development Guidelines . . . . . . . . . . . . . . . . . . . . . 124
8.2.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.2.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.2.3 Implementation . . . . . . . . . . . . . . . . . . . . . . 128
8.2.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . 129
9 Case Study 131
9.1 Use Case Model . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.2 Design Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.3 Use Case Model Annotations. . . . . . . . . . . . . . . . . . . 135
9.4 Access Control Policy . . . . . . . . . . . . . . . . . . . . . . . 136
9.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
10 Conclusions 141
10.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
10.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
A Appendix 147
A.1 OCL Translation to First-order Logic . . . . . . . . . . . . . . 147
A.2 TranslationofComponentUMLAtomicActionstoEJBmethod-
elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
A.3 OCL Translation to Java . . . . . . . . . . . . . . . . . . . . . 150
Bibliography 153
910

Soyez le premier à déposer un commentaire !

17/1000 caractères maximum.