WebFarm. Webtechnologien effektiv einrichten und betreiben GERMAN

Sandini Bib

WebFarm

Sandini Bib

Sandini Bib

Hans-Christian Boos

WebFarm Webtechnologien effektiv einrichten und betreiben

An imprint of Pearson Education München • Boston • San Francisco • Harlow, England Don Mills, Ontario • Sydney • Mexico City Madrid • Amsterdam

Sandini Bib

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Ein Titeldatensatz für diese Publikation ist bei Der Deutschen Bibliothek erhältlich.

Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht. Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht vollständig ausgeschlossen werden. Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar. Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig. Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleichzeitig auch eingetragene Warenzeichen oder sollten als solche betrachtet werden. Umwelthinweis: Dieses Buch wurde auf chlorfrei gebleichtem Papier gedruckt. Die Einschrumpffolie – zum Schutz vor Verschmutzung – ist aus umweltfreundlichem und recyclingfähigem PE-Material.

10 9 8 7 6 5 4 3 2 1 05 04 03 02 01 ISBN 3-8273-1842-4 © 2001 by Addison-Wesley Verlag, ein Imprint der Pearson Education Deutschland GmbH, Martin-Kollar-Straße 10–12, D-81829 München/Germany Alle Rechte vorbehalten Einbandgestaltung: atelier für gestaltung n&h, Niesner & Huber, Wuppertal Lektorat: Sylvia Hasselbach, [email protected] Korrektorat: Sonja Fischer, München Herstellung: Anna Plenk, [email protected] Satz: reemers publishing services gmbh, Krefeld (www.reemers.de) Druck und Verarbeitung: Freiburger graphische Betriebe, Freiburg Printed in Germany

Sandini Bib

Inhaltsverzeichnis Vorwort Teil I:

17

Infrastruktur

1 Firewall-Architektur

19

21

1.1

Allgemeine Ansätze für Netzwerksicherheit

21

1.2

1.1.1 Schutz eines Netzknotens durch eine Firewall Schutzmechanismen für Netzwerke 1.2.1 Single Firewall-Lösungen

21 24 24

1.3

1.2.2 Network of Firewalls Zentrale Komponenten einer Firewall 1.3.1 Packetfilter

25 25 25 26 27

1.4

1.3.2 Application Level Gateway 1.3.3 Empfehlung Firewall-Aufbau im internen Netz (GAN Security) Firewall-Aufbau für eine externe Netzanbindung Sicherheitskonstruktionen als Hosting Area

30

1.5 1.6

1.6.1 1.6.2

DMZ I als Netzsegment für extern zugreifbare Dienste 31 DMZ II als Netzsegment für intern zugreifbare Dienste 31

1.6.3

Das interne Segment als Netzsegment für LAN-intern zugreifbare Dienste

32

Schaffung einer DMZ II-Klasse-Zone ohne Außenanbindung Die komplette Hosting-Infrastruktur im Überblick

32 32

1.6.4 1.6.5 1.7

1.8

28 29

Content Security

34

1.7.1 Skriptsprachen und externe Verbindungen 1.7.2 Viren- und Trojanerscanning Intrusion Detection 1.8.1 Netzwerkscanning

34 35 36 37

1.8.2

Logfristen

38

1.8.3 1.8.4

Hinweise Leitdokumentation

39 39

1.8.5

Anwenderdokumentation

40

Sandini Bib Inhaltsverzeichnis

1.8.6 1.8.7

Betriebsdokumentation Entwicklerdokumentation

2 DNS

40 42 45

2.1

Internes und externes DNS

45

2.2 2.3

Struktur des internen Namenraums Aufbau der DNS-Infrastruktur

46 48

2.4

Datenverwaltung

50

3 Proxy-Infrastruktur, Browser-Konfiguration und Zugriffsberechtigung

51

3.1 3.2

Application-Proxy vs. Web-Proxy Proxy-Konzept

51 52

3.3

Zugang zu internen Netzen

52

3.4 3.5

Proxy-Hierarchie Browser-Konfiguration

53 56

3.5.1 3.5.2

56 57

Zentrale Nicht-Zentrale

3.6

Cache 3.6.1 Was kann gecached werden?

57 57

3.7 3.8 3.9

Reverse-Proxy als Anwendungsschutz Normaler Zugriff Zugriff über einen Reverse-Proxy

58 59 59

3.9.1 3.9.2 3.9.3

59 60 61

Reverse-Proxy zur Zugriffskontrolle Reverse-Proxy zur Trennung der Zugriffssegmente HTTPS-Zugriff auf HTTP-Anwendungen

4 Authentifizierung/Autorisation 4.1 4.2 4.3

4.4

Zielsetzung für dieses Dokument Grundsätze der Berechtigungsstruktur WebFarm und Directories

63 63 63 66

4.3.1

WebFarm-Administrationsberechtigungsstruktur

67

4.3.2 4.3.3

WebFarm-Directory Webanwendungen und Berechtigungen

70 70

Authentifizierung 4.4.1 Passwörter 4.4.2 PIN-TAN (nicht empfohlen)

71 71 71

Sandini Bib Inhaltsverzeichnis

4.4.3 4.4.4

Zertifikate Smartcards, Chipkarten und Buttons

72 72

4.5 4.6

4.4.5 Biometrische Verfahren Accounting und Billing-Infrastruktur Daten

72 73 73

4.7

Standardauswertungen

74

4.8

4.7.1 Server 4.7.2 Anwendungen Billing

75 78 80

4.9 4.10 4.11

Content-Management-Übersicht Verteilung und Redaktion Style-Guides und Checking

80 81 82

5 Content-Management und Content-Pool 5.1

5.2

5.3 5.4

83

Information-Modelling 5.1.1 Was ist Information-Modelling? 5.1.2 Der Informationsbegriff

84 84 85

5.1.3 Informationstypisierung Aufbau eines Wissensnetzes 5.2.1 Informationserfassung und -verteilung

85 91 92

5.2.2

96

Sicherheitsstandard

Redaktionskonzept Grundlagen für ein Informationsmodell

97 98

5.4.1 5.4.2

Basisstruktur des Modells Verwendung von Meta-Informationen zur Klassifizierung

98

5.4.3 5.4.4

Weitere Verwendung von Meta-Informationen Mehrsprachigkeit

99 99 100

5.5

Redaktionssystem und Redaktionsverfahren

100

5.6

Informationsanlieferung 5.6.1 Parameter der Anlieferung

102

5.6.2

Methoden zur Anlieferung von Informationen

103

5.6.3 5.6.4

Packages und Packaging Sicherheitsstandard

105 106

Überprüfung von angelieferten Packages Freigabe und Verteilung

107 109

5.7 5.8

102

Sandini Bib Inhaltsverzeichnis

5.8.1 5.8.2 5.9

Rückverteilung von Packages Versionierung

Personalisierung und Profiling-Datenbanken 5.9.1 Wie wird Personalisierung eingesetzt? 5.9.2 Erzeugung von individualisierten Anwendungen nach Gruppen

112 113

5.9.3

120

Aktivierung der Empfehlungen

6 Suchmaschinen 6.1

6.2

6.3

7.2

118

123

Suchverfahren 6.1.1 Volltextsuche 6.1.2 Meta-Suche

123 124 125

6.1.3 Retrieval-Engines 6.1.4 KI-basierte Suchansätze Arbeitsweise der anwendungsübergreifenden Suchmaschine

126 127 127

6.2.1 6.2.2

127 128

Indizierung Content-Berechtigungen

Lokation einer Suchmaschine in einer WebFarm

7 Anwendungsklassifizierung 7.1

110 111

130 131

Klassifizierung 7.1.1 Software Hardware

131 131 132

7.2.1 7.2.2 7.2.3

133 134 134

Eigene Hardware oder virtueller Server Cluster Speicher und Plattenplatz

7.3

Backup, Fallback und K-Fall-Strategien

134

7.4

Datensicherung 7.4.1 Lokale Datensicherung 7.4.2 Datensicherung per Serveranwendung

135 135 135

7.4.3 7.4.4

Kombination von lokaler und zentraler Sicherung Fail-Over- und Fall-Back-Lösung

136 137

7.4.5

Datenströme

137

7.4.6

Fail-Over und Fall-Back

138

7.5

Cluster

139

Sandini Bib Inhaltsverzeichnis

7.6

K-Fall-Absicherung 7.6.1 Räumliche Trennung

140 140

7.7 7.8

7.6.2 Medienaufbewahrung Network-Connectivity GAN-Verbindungen

141 142 142

7.9

Internetanbindung

143

7.10 7.11 7.12

Archivierung Datentransfer Aktualisierungen

144 145 146

Teil II:

Anwendungsspezifische Systemarchitektur

8 Richtlinien für die Implementierung 8.1 8.2

Entwicklungsumgebung Webserver-Softwaredefinition 8.2.1 Produktklassifizierung bei HTTP-Servern 8.2.2

8.3

Spezifische Webserver im Vergleich zu allgemeinen Webservern

149 149 150 150 151

8.2.3 Plug-ins, Module und Includes 8.2.4 Installation Webserver-Hardwaredefinition

152 153 156

8.3.1 8.3.2 8.3.3

157 158 161

Hardwareplattform Hardwaredimensionierung Cluster-Lösungen

9 Application-Server 9.1 9.2

147

Funktionen eines Application-Servers Typisierung allgemeiner Application-Server 9.2.1 Vor- und Nachteile von TAG-basierten Systemen 9.2.2

Vor- und Nachteile von programmorientierten Systemen

163 164 167 167 168

9.3 9.4

9.2.3 Fazit Arbeitskräfte und Ressourcen Entwicklungsumgebungen

169 170 170

9.5 9.6

Entwicklungsstil Schulung und Time-to-Market

171 172

Sandini Bib Inhaltsverzeichnis

9.7

Einsatz eines Application-Servers 9.7.1 Einsatz von spezifischen Application-Servern

173 173

9.7.2

Standardfunktionen von Application-Servern und Webservern

174

9.7.3 9.7.4

Einsatz von allgemeinen Application-Servern Application-Server vs. CGI

174 174

9.8

Hardwarespezifikationen

175

9.9 9.10

Clustering Cookies

176 176

10 Database-Connectivity

177

10.1

Lokale und entfernte Datenbanken

177

10.2

Connectivity auf Datenbankebene 10.2.1 Datenbankzugriff vom Webserver aus

178 178

10.2.2

179

10.3 10.4 10.5

Datenbankzugriff vom Client aus

Kostenbetrachtung Layer-Zugriffe Datenbank-Zugriffsverwaltung

179 180 180

11 Search

183

11.1 11.2

183

11.3

Suche und Content-Management Volltext- und Metasuche auf lokalen Sites 11.2.1 Konfigurationsvoraussetzungen

184 185

Integration in die globale Suchumgebung

186

12 Content-Management 12.1

12.2

Lokales Content-Management 12.1.1 Statischer Content

189 190

12.1.2 Semi-dynamischer Content Content für eine Anwendung

191 198

13 Management der Navigationsstruktur 13.1

189

201

Anwendungsklassifizierung

201

13.1.1

Reine Programmanwendung

201

13.1.2 13.1.3

Allgemein verwendbare Webanwendung Webanwendung für Experten

202 203

13.1.4

Homepages

205

Sandini Bib Inhaltsverzeichnis

13.2

13.3

Navigationsdesign für allgemeine Anwendungen 13.2.1 Seitenlayout

205 206

13.2.2 Navigationselemente 13.2.3 Navigationsebenen Navigationsdesign für Expertenanwendungen

206 208 209

14 Cluster-Management 14.1

14.2

14.3

Cluster-Varianten 14.1.1 Round-Robin-Verfahren

213 213

14.1.2

214

Reverse-Proxy-Cluster

14.1.3 Director-(Hardware)-Cluster Content-Management für Cluster 14.2.1 Dynamische Informationen

216 216 217

14.2.2 Semi-dynamische Informationen 14.2.3 Statische Informationen Entwicklungsvoraussetzungen für Cluster 14.3.1 Datengenerierung

217 218 219 219

14.3.2

219

Vernetzungsvoraussetzungen

15 Secure-Content 15.1

15.2 15.3

213

221

Sicherheitsverfahren

221

15.1.1 15.1.2

221 222

Authentifizierung Übertragungssicherung

Verschlüsselung SSL

222 223

15.3.1

Andere Verfahren

224

15.3.2

Empfehlung

225

16 HTML-Style

227

16.1 16.2 16.3 16.4

Tags und Attribute Pfade und Dateinamen HTML-Generatoren Test des Codes

227 228 229 230

16.5 16.6

Style und Layout – Wo abgelegt? Extensions

231 231

Sandini Bib Inhaltsverzeichnis

17 XML 17.1

17.2

17.3

235 XML-Einführung 17.1.1 XML – Die Vision 17.1.2 XML – Die Entwicklung

235 235 236

17.1.3 XML – Die Sprache Anwendungsfelder für XML 17.2.1 XML als standardisiertes Datenaustauschformat (z.B.: XML/EDI) 17.2.2 Verlagerung der Rechenleistung (Logik) vom Server zum Client (z.B.: Electronic-Banking, Electronic-Commerce) 17.2.3 Flexible Darstellung von Informationen

237 242

243 243

XML in der Praxis 17.3.1 XML-Design 17.3.2 XML-Verwendung

244 244 244

18 CGIs

243

247

18.1

Programmierumgebung

247

18.2 18.3

Programmiersprachen CGI-Entwicklung

247 248

18.3.1 18.3.2 18.3.3

Modulköpfe Dynamische Ausgaben Verwendung von Konfigurationsfiles

248 248 249

18.3.4

Sicherheit von CGIs

249

19 Skriptsprachen 19.1 19.2

Browser-Skriptsprachen

251

19.1.1

252

Einsatz von Browser-Skriptsprachen

Skriptsprachen für den Einsatz auf Serverseite 19.2.1 Entwicklungsstil

20 Java-Style 20.1

251

253 254 255

Grundsätze 20.1.1 Lesbarkeit

255 255

20.1.2 20.1.3

256 257

Fehlerfreiheit Performante Ausführung

Sandini Bib Inhaltsverzeichnis

20.2

Entwicklungswerkzeuge 20.2.1 Reine Java-Entwicklung 20.2.2

20.3 20.4

Erweiterte Funktionen der Java-Entwicklungsumgebung

21.2

21.3

259

Laufzeitumgebung Servlets und Server-Side-Includes

260 261

20.4.1

Einsatz von Server-Side-Anwendungen

261

20.4.2

Einbindung von Includes und Servlets

262

21 Website-Werkzeuge und Serveranwendungen 21.1

258 258

263

Website-Werkzeuge 21.1.1 Charting

263 263

21.1.2 21.1.3 21.1.4

264 265 265

Community-Tools Mind-Map Shops

Serveranwendungen 21.2.1 Share/Teamworkanwendungen

266 266

21.2.2

Streaming

267

Backoffice-Anwendungen 21.3.1 Mailinglisten

267 267

21.3.2

268

Rules-Engine

Teil III: Systembetrieb

269

22 Betriebsumgebung

271

22.1

22.2

22.3 22.4

Administrationsumgebung

271

22.1.1

Administrationsserver

272

22.1.2 22.1.3

Verteilte WebFarm-Betriebspunkte Backup-Verfahren

272 273

Leistungsbeschreibung im Systembetrieb 22.2.1 Teil A: Laufender Betrieb 22.2.2 Teil B: Aufträge

275 275 282

22.2.3 Teil C: Entwicklung Verfügbarkeit Performance

282 283 283

Sandini Bib Inhaltsverzeichnis

23 Hardwaremanagement und Systemüberwachung 23.1

285

Hardwaremanagement 23.1.1 Wartungsverträge 23.1.2 Standardsysteme

285 285 285

23.2 23.3

23.1.3 Hardware-Fault-Betrachtung Überwachungsverfahren Konfigurationsmanagement

286 287 288

23.4

Logging-Verfahren

288

24 Softwaremanagement 24.1

289

Softwaredefinition 24.1.1 Betriebssystem

289 289

24.1.2 24.1.3 24.1.4

Basissoftware Zusatzsoftware Projektsoftware

290 290 291

24.2

Übergabeverfahren 24.2.1 Standardkomponenten 24.2.2 Zusatzkomponenten

291 291 291

24.3

Lizenzkontrolle

292

25 Sicherheitsabstimmung 25.1

25.2

Systemsicherheit 25.1.1 Systemsicherheit bezüglich Software

293 293

25.1.2 Benutzerprofile 25.1.3 Administrationszugriff Logbücher

294 294 295

26 Sicherheitsantragswesen und Betriebsübergabeverfahren 26.1

26.2

297

Antragsverfahren 26.1.1 WebFarm-Auftrag 26.1.2 Content-Management-Systemanträge

297 297 298

26.1.3

299

Sicherheitsrelevante Freischaltungen

Betriebsübergabe

27 Integrationstests 27.1

293

Testumgebung

300 303 303

Sandini Bib Inhaltsverzeichnis

27.1.1 27.1.2 27.2

Aufbau Betriebsunterstützung

303 304

27.1.3 Planung Testverfahren 27.2.1 Funktionstest

304 305 305

27.2.2

Lasttests

305

27.2.3

Sicherheitstests

306

28 Eskalationsverfahren

307

28.1

Definition von Klassen und Verfahren

307

28.2 28.3

WebFarm-Verfahren 28.2.1 Alarmierung Überwachungsstufen

309 310 310

28.4 28.5 28.6 28.7

Zusatzdienste und Pre-Altering Patch-Verfahren Patch-Verwendung Patch-Verteilung

312 313 313 314

28.8 Außerordentliche Patches 28.9 Servicelevel-Definitionen 28.10 Servicelevel nach Dienstverfügbarkeit

314 315 316

28.10.1 Verfügbarkeit und Konventionalstrafen 28.11 Servicelevel nach Reaktionszeit 28.11.1 Reaktionszeiten für den gesamten Betrieb 28.11.2 Kostentransparenz

316 318 318 321

Teil IV: Organisation

323

29 WebConsulting-Projekte

325

29.1

Leistungsübersicht 29.1.1 Struktur und Aufgabenverteilung 29.1.2 Information-Service

325 326 327

29.1.3 29.1.4 29.1.5

327 327 328

Network-Services Information-Management Consulting

Sandini Bib Inhaltsverzeichnis

30 Setting-up von Webprojekten 30.1 30.2 30.3

Projektantrag Gremien und Personal Phasenmodell

Stichwortverzeichnis

331 331 331 332 335

Sandini Bib

Vorwort Der WebFarm Standard ist ein Ansatz für den Aufbau einer Infrastruktur, die Darstellung eines Entwicklungsstandards und die Definition eines Betriebsverfahrens sowie die Aufstellung von Organisationsrichtlinien für die Durchführung von Projekten und Betrieb im Webumfeld. Arago Institut für komplexes Datenmanagement GmbH beschäftigt sich seit 1996 mit dem Hochverfügbarkeitsbetrieb und der Entwicklung von sicheren Webanwendungen und Anwendungen im Umfeld von Webanwendungen. Diesem Standard liegen die mit dem Großkunden gesammelten Erfahrungen im Bereich der Entwicklung und des Betriebs zu Grunde. Diese Erfahrungen sind Grundlage für diesen Standard, der auf einheitlicher Entwicklung, Wiederverwendung von Verfahren, Bausteinen und Informationen, Automatisierung, Serienfertigung und dem kundenorientierten, effizienten Hochverfügbarkeitsbetrieb von Webanwendungen beruht. Der WebFarm-Standard wurde gemeinsam mit großen Kunden entwickelt und befindet sich als Konzept bereits seit mehreren Jahren im Einsatz. Die Produktempfehlungen und Verfahrensweisen des WebFarm-Standards werden kontinuierlich an die sich schnell verändernde IT-Landschaft im Webumfeld angepasst, so dass die Infrastruktur und Wiederverwendbarkeit der implementierten Standardkomponenten erhalten werden kann. In den WebFarm-Standard gehen nur Verfahren ein, die bereits seit mindestens drei Monaten im Einsatz sind. Empfohlene Hard- und Software ist ebenfalls mindestens drei Monate bei Kunden der arago im produktiven Einsatz und wurde vorher strengen Vergleichs-, Sicherheits- und Performancetests unterzogen. In den Empfehlungen sind Produkte der arago enthalten, da diese selbstverständlich in ihrer Entwicklung sehr gut an die Vorgehensweisen des Standards angepasst werden konnten. Die arago-Produkte folgen den gleichen Maßgaben wie der WebFarm-Standard und halten im jeweiligen Anwendungsfall jeder Testumgebung für den WebFarm-Betrieb und die entsprechende Entwicklung stand.

17

Sandini Bib

Sandini Bib

I Infrastruktur

Sandini Bib

Sandini Bib

1 1.1

Firewall-Architektur Allgemeine Ansätze für Netzwerksicherheit

Im folgenden Abschnitt soll auf verschiedene Verfahren der netzwerktechnischen Systemsicherung eingegangen werden. Dabei steht die Etablierung von Firewall-Systemen, deren Vor- und Nachteile sowie deren Zielausrichtung und somit eine Empfehlung für die zu etablierende Infrastruktur innerhalb des Unternehmens im Mittelpunkt.

1.1.1

Schutz eines Netzknotens durch eine Firewall

Filtering Router

Internet

Router

LAN

Abbildung 1.1: Schema einer Firewall mit Filtering Router

Dies ist die einfachste und günstigste Art des Netzwerkschutzes. Es werden einfachste Angriffe abgefangen. Die Logmöglichkeiten sind sehr beschränkt. Es ist keinerlei Attack-Profiling oder Counter-Measures möglich. Eine solche Konstruktion sollte nur in Kleinbetrieben oder zum Schutz einzelner Netzsegmente verwendet werden, z.B. zwischen Abteilungen. Dual Homed Gate

Internet

Router

Packetfilter

Router

LAN

Abbildung 1.2: Schema einer Firewall mit Dual Homed Gate

Dies ist eine sehr oft eingesetzte Firewall-Variante. Es besteht durch die Rechner-Router-Kombination ein guter Schutz der inneren Netze. Serviceangebote nach außen verlangen Zugriffe auf eigentlich geschützte Netzsegmente. Für

21

Sandini Bib 1 Firewall-Architektur

Hochsicherheitssysteme ist ein solches Setup nicht geeignet. Die Loggingmöglichkeiten für den Servicezugriff sind beschränkt. Bei dieser Konfiguration steht normalerweise nur der eine Firewallhost zwischen dem potenziellen Angreifer und dem zu schützenden Netzwerk. Triple Homed Gate

Internet

Router

Packet Filter

Router

LAN

External Segment

Abbildung 1.3: Schema einer Firewall mit Triple Homed Gate

Grundsätzlich folgt diese Variante dem gleichen Prinzip wie den Dual Homed Gate, allerdings werden nach außen anzubietende Dienste in einem eigenen Netzwerksegment angebunden. Dieses Segment ist durch eine weitergehende Konfiguration des Gates geschützt. Guter Schutz des Netzwerkes ist gewährleistet. Die einzige wirkliche Hürde ist allerdings immer noch das eine Gateway. Die zu extrahierenden Logginginformationen sind für Hochsicherheitssysteme nicht ausreichend. Bei hoher Belastung aus internen LANs und Service-LANs wird das Gate wegen der unterschiedlichen Konfigurationen oft zum Flaschenhals. Firewalls mit DMZ

Internet

Router

Packetfilter

Application Level Gateway

Router

LAN

Abbildung 1.4: Normaler Host-Firewall

Gezeigt wird die Variante mit zwei Dual Homed Gates. In der so genannten DMZ (demilitarized Zone) werden alle nach außen anzubietenden Dienste angebunden. Ein solches Setup ermöglicht ein sehr gutes Extrahieren jeder Log- und Trafficinformationen. Der Zugriff der Services auf das innere Netzwerk ist separat gesichert und die einzelnen Zugriffsparameter werden zumeist durch Proxyservices oder Circuit-Level-Proxies realisiert. Das heißt, gewöhnlich gibt es bei einem solchen Setup keinerlei Zugriffe direkt auf interne Komponenten. Es besteht außerdem eine klare Trennung von Application-Level- und Filtering-Gate.

22

Sandini Bib Allgemeine Ansätze für Netzwerksicherheit

Application Level Gateway

Internet

Router

Packetfilter

Router

LAN

Abbildung 1.5: DMZ

Die DMZ wird nur durch den Router abgeschlossen, der 2. Rechner ist ein reines Application-Level Gate. Auch hier können Logginginformationen gut extrahiert werden. Im Vergleich zur Variante 1 fällt der Zugriffsschutz des Services auf das innere Netzwerk auf den Router zurück. Diese Variante wird oft bei hohem Traffic aus dem internen Netz verwendet, da das Application Gate sonst keinen Belastungen ausgesetzt ist.

Internet

Router

Packetfilter

Router

Application Level Gateway

Router

LAN

Abbildung 1.6: Split DMZ

Grundsätzlich bestehen hier die gleichen Möglichkeiten wie bei einer normalen DMZ- Firewall. Allerdings wird die DMZ in 2 separate Segmente geteilt. Dies ermöglicht z.B. das Aufsetzen von sicheren Datenbankspiegeln für externe Services. Es erscheint sinnvoll, eine solche Variante einzusetzen, wenn extern angebotene Services eine hohe Anzahl Zugriffe auf interne Dienste produzieren. Military Level Firewalls Encaps Filter

Screening Router

Auditing Host

Packet Filter

Splitting Router

Application Gateway Splitting Router

Circuit Gateway

Internet Connection

Screening Router

1st Screened Subnet

Fingerprint Authentication

Screening Router

2nd Screened Subnet

Log Storage

Abbildung 1.7: Military-Level-Firewall 23

Sandini Bib 1 Firewall-Architektur

Abbildung 1.7 zeigt eine Military-Level-Firewallkonstruktion. Ein solches Schema wird im kommerziellen Bereich in der Regel unnötig sein. Die Hardwarekosten einer solchen Konstruktion bewegen sich im Millionenbereich. Zusätzlich zum reinen Setup und der Installation sind bauliche Maßnahmen und die Verwendung von Spezialmaterialien (z.B. Schmelzkabel) notwendig.

1.2

Schutzmechanismen für Netzwerke

1.2.1

Single Firewall-Lösungen

LAN

Internet

Firewall

LAN

LAN

Abbildung 1.8: Single-Firewall-Lösung

Schützt man das gesamte Netzwerk nur durch eine Firewallkonstruktion, spricht man von einer Single Firewall Lösung oder auch einem Hot-Spot Security Konzept. Die Administrationsarbeiten für eine solche Lösung sind im Vergleich zu anderen Lösungen gering. Allerdings gibt es im internen Netz keinerlei Sicherheitsabstufungen und keinen weiteren Schutz vor Eindringlingen.

24

Sandini Bib Zentrale Komponenten einer Firewall

1.2.2

Network of Firewalls LAN LAN

Firewall LAN

Internet

Firewall

LAN LAN

Firewall LAN LAN LAN

Firewall LAN Abbildung 1.9: Network of Firewalls

Spricht man von einem Network of Firewalls, wird man nach der Zugriffs-Firewall zu externen Datenautobahnen im internen Netz weitere Firewall-Lösungen etablieren, mit denen verschiedene Sicherheitsstufen im Netz implementierbar sind. Ein Network of Firewalls ist komplexer zu administrieren, bietet aber einen wesentlich besseren Schutz und bessere Möglichkeiten, potenzielle Angreifer aufzuspüren und zu verfolgen.

1.3

Zentrale Komponenten einer Firewall

1.3.1

Packetfilter

Ein Packetfilter ist der Basisbestandteil jeder Firewall. Ein Packetfilter arbeitet auf IP-Ebene bzw. auf den Protokollen direkt über der IP-Ebene. Ein Packetfilter überprüft alle ein- und ausgehenden Pakete auf deren Ursprungsadresse und -port sowie Zieladresse und -port. Das Regelwerk in der Konfiguration des Packetfilters beschreibt, welche Kombinationen von Ursprungs- und Ziel-

25

Sandini Bib 1 Firewall-Architektur

daten zugelassen werden. Alle unzulässigen Daten werden unbesehen ignoriert, alle zulässigen Daten werden 1:1 durch den Packetfilter, der in diesem Falle wie ein Router funktioniert, geschleust. Ein Packetfilter ist auf jeden Fall Bestandteil einer Firewall-Konstruktion und wird als erste Barriere gegen komplett unsichere Netze sowie zur Trennung von eng verbundenen Netzen verwendet. Im Rahmen von Intrusion Detection spielen Packetfilter auch eine entscheidende Rolle, denn ein Packetfilter kann gewährleisten, dass auf einem Netzsegment nur bestimmte zugelassene Pakete existieren, was ein Scannen nach unzulässigen Paketen und Vorgehen stark erleichtert.

1.3.2

Application Level Gateway

Ein Application-Level-Gateway ist erforderlich für einen gesicherten Zugang, bei dem etwas höhere Ansprüche an die Sicherheit gestellt werden. Im Gegensatz zu »einfachen« Packetfilters arbeitet ein Application Level Gateway im TCP-Stack auf einer höheren Ebene.

Application Level GW

Packet Filter

e.g. smtp (eMail), http (WWW), ftp (Filetransfer)

Applications

connection oriented lossless protocol

TCP IP

connectionless protocol with loss

MAC Media Access (e.g. CSMA/CD Ethernet)

Abbildung 1.10: Application-Level-Gateway

Damit verfügt das Application Level Gateway über zusätzliches Wissen zur Kontrolle und Filterung von Zugriffen. Bei einer möglichen Fernwartung des Systems von außen wird der Authentifizierung Server im Application Level Gateway genutzt.

26

Sandini Bib Zentrale Komponenten einer Firewall

Das Application Level Gateway ist die zentrale separierende Instanz zwischen Intra- und Internetzen. Die Verwendung des Application Level Gateway macht durch die Trennung der Verbindungen eine Address Translation überflüssig. Innen sollten Adressen verwendet werden, die nach außen nicht geroutet werden. Dadurch werden Fehlkonfigurationen leichter erkannt und können keinen Schaden anrichten (die externe DMZ muss selbstverständlich gültige Adressen verwenden).

1.3.3

Empfehlung

In einem Netz sollten verschiedene Subnetze unterschiedlicher Unternehmensteile durch Packetfilter in einem Network of Firewalls voneinander getrennt sein. Eine direkte Kontrolle dieser Komponenten ist nicht zwingend erforderlich, solange die definierte Sicherheitspolicy überprüfbar eingehalten wird. Zum Anschluss des weltweiten Corporate Networks – Global Area Network (GAN) – an andere, unsichere Netze, wie z.B. das Internet oder Netze von Drittanbietern, wird eine mindestens zweistufige Firewall-Konstruktion mit Intrusion Detection und Content Security empfohlen. Auf diese Weise ist im konzerninternen Netz eine definierte Sicherheitspolicy etabliert und eine Netztrennung zumindest auf Dienstebene vorgenommen. Außerdem ist so, eine komplette Abschottung gegenüber externen und unsicheren Netzen vorgenommen. Diese Anbindung nach außen kann vom kompletten GAN genutzt werden. Mehrere Anbindungen nach außen empfehlen sich, wenn eine Ausfallsicherheit geschaffen werden soll, oder ein zentraler Flaschenhals für die Verbindung zu externen Netzen vermieden werden soll. Da auf jeden Fall kein 100%-Ausfall erfolgen darf, und der Ausbau von internen Knotenpunkten im GAN auf ein Niveau, das alle Verbindungen über einen Punkt abdecken würde, zu kostenintensiv ist, empfiehlt es sich, mindestens zwei Außenanbindungen zu haben. Soll Ausfallsicherheit ebenfalls gewährleistet werden, muss die Voraussetzung, im Netzwerkaufbau des GAN durch dynamisches Routing geschaffen sein. In der vorstehenden Grafik werden in einer zweistufigen Firewall-Konstruktion exemplarisch ein- und ausgehende Verbindungen dargestellt. Ein solches zweistufiges Konzept ermöglicht die vollständige Trennung von internen und externen Applikationen, da kein direkter Netzkontakt, sondern nur die Umsetzung von Applikationsanfragen auf der Applikationsebene besteht. Ein solches Konzept ermöglicht es, in einem gesicherten Bereich Dienste nach außen anzubieten, und intern einen komplett abgeschlossenen Netzbereich zu erhalten, auf den nicht direkt zugegriffen werden kann.

27

Sandini Bib

EMail Access Authenticated Access

Packet Filter

Application Level Gateway

Internal WWW Access

Internal R.

External R.

1 Firewall-Architektur

Abbildung 1.11: Zweistufige Firewall-Konstruktion

Dieses Konzept in voller Ausarbeitung entspricht den Richtlinien beispielsweise des BSI (Bundesamt für Sicherheit) und hat somit einen Sicherheitsstandard, der für Finanzapplikationen geeignet ist.

1.4

Firewall-Aufbau im internen Netz (GAN Security)

Ein lokales Netz muss sich, wie bereits oben erwähnt, gegen andere lokale Netze abschirmen, um das Risiko von Datenverlust oder Datenmanipulation möglichst gering zu halten. Als Punkt für eine solche Abschirmung bietet sich der Anschlusspunkt der LANs an das GAN an. An diesem Punkt sollten auch andere eingehende Drittnetze auflaufen, die dann in die Sicherheitskonstruktion einfließen können. An diesem Zugriffspunkt wird ein Packetfilter etabliert. Eine höhere Stufe der Netzwerktrennung, z.B. durch einen Application Level Gateway, ist nicht möglich, da die im GAN verwendeten Protokolle oft nicht einfach umgesetzt werden können und für einige Anwendungen eine direkte Punkt-zu-Punkt-Kommunikation sinnvoll ist. Dieser Packetfilter

28

Sandini Bib Firewall-Aufbau für eine externe Netzanbindung

erhält ein speziell gekennzeichnetes Interface für die Verbindung in das lokale Netz und jeweils ein Interface für jedes anzuschließende Drittnetz bzw. jede Verbindung in das GAN. Diese Packetfilter müssen nicht unbedingt unter lokaler Kontrolle stehen. Es ist aber sinnvoll, die Packetfilter auf dem lokalen Campus aufzustellen, da Außenanbindungen immer kritische Punkte sind und Angriffsmöglichkeiten bieten. Des Weiteren kann durch das lokale Aufstellen der Filter eine BackupGAN-Struktur unterstützt werden sowie die Anbindung aller anderen Netze wie z.B. Datenversorger.

LAN Segment 1

Anbindung dritter Netze

GAN Backbone

LAN Backbone

LAN Segment 2

Packetfilter

Anbindung dritter Netze LAN Segment 3

Untrusted Area

Campusgrenze

Trusted Area

Abbildung 1.12: Netzwerktrennung

In Kombination mit einer Anbindung an externe und unsichere Netze ist die Möglichkeit gegeben, eine Sicherheitskonstruktion auch als Hostingarea für Anwendungen zu nutzen, die entweder nach innen oder nach außen angeboten werden sollen.

1.5

Firewall-Aufbau für eine externe Netzanbindung

Wie bereits im theoretischen Teil empfohlen, bietet sich für die Anbindung komplett unsicherer Netze eine mindestens zweistufige Lösung an, da die Verbindungen zu solchen Netzen keine benutzerdefinierten Protokolle oder direkten Punkt-zu-Punkt-Verbindungen benötigen.

29

Sandini Bib 1 Firewall-Architektur

Insecure Network

DMZ Packetfilter

Application Level Gateway Securely controlled Area DMZ

Insecure and Untrusted Area

Trusted Area

Campusgrenze

Abbildung 1.13: Firewall für externe Netzwerkanbindung

Eine solche Konstruktion bietet einen ausreichenden Schutz gegen unsichere Netze und schafft mit der ohnehin entstehenden DMZ einerseits einen guten Messpunkt für Intrusion Detection und andererseits eine Möglichkeit, extern verfügbare Dienste in einer sicheren Umgebung unterzubringen. Dieser Aspekt wird unten weiter beschrieben. Wie bei der Abschirmung interner Netze ist es auch hier sinnvoll, die Grenze der Sicherheitskonstruktion im Campus zu belassen. Das bedeutet nicht, dass die Konstruktion nicht von anderer Stelle aus kontrolliert werden kann. Der kritische Punkt ist in beiden Fällen der Flaschenhals der nach außen weisenden Leitungen, die, wenn sie direkten Netzzugang haben, einen nahezu perfekten Angriffspunkt liefern. Application Level Gateway und Packetfilter sollten unterschiedliche Betriebssystemplattformen sein und unterschiedliche Softwareprodukte verwenden. Dies erfordert mehr Know-how im Betrieb und kann, wenn das WebFarmKonzept nicht komplett umgesetzt ist, höhere Betriebskosten durch ein heterogenes Netz verursachen, bietet aber den eindeutigen Vorteil, dass sich ein Fehler in der Hardware oder der Basissystemsoftware oder auch der Sicherheitssoftware selbst nicht durch die gesamte Konstruktion ziehen kann. Damit kann ein Sicherheitsloch, das auf einem Fehler auf dieser Ebene zurückzuführen ist, nicht den direkten Zugriff von außen bis in das LAN einer Lokation ermöglichen.

1.6

Sicherheitskonstruktionen als Hosting Area

Die meisten Anwendungen die im Web-Bereich geschaffen werden, sind heute schutzbedürftig. Dies trifft ebenso auf viele existierende Client-ServerAnwendungen zu. Diese aber zu einer Zeit implementiert wurden, als direkter Schutz der Kommunikationsstrecken noch nicht als primäres Thema behandelt wurde.

30

Sandini Bib Sicherheitskonstruktionen als Hosting Area

Aus diesem Grund bietet es sich an, solche Anwendungen in einer Sicherheitskonstruktion unterzubringen, damit die direkten Zugriffe auf diese Anwendungen auf die erlaubten Protokolle und Netzsegmente beschränkt werden können. Selbstverständlich ist dies nicht in jedem Fall erforderlich, da die Sicherheitsstufe der Anwendung vorher festgelegt werden muss. Wird eine zweistufige Anbindung nach außen geschaffen und das interne Netz zusätzlich durch einen Packetfilter geschützt, so entstehen drei verschiedene Zonen, in denen Server sinnvoll platziert werden können. Die zusätzliche vierte Zone (komplett ohne Schutz) sollte lediglich für Netzwerkprobes oder Intrusion Detection, aber nicht für das Anbieten von Diensten verwendet werden. Die drei Zonen werden im Folgenden einzeln beschrieben.

1.6.1

DMZ I als Netzsegment für extern zugreifbare Dienste

Die DMZ I ist die Zone für externe Dienste und befindet sich zwischen dem externen Packetfilter und dem Application Level Gateway. Durch den Packetfilter können Zugriffe auf bestimmte Dienste der in dieser Zone stehenden Server erlaubt werden. Alle anderen Zugriffe sind nicht gestattet. Durch das Application Level Gateway kann eine komplett von der Netzwerkschicht getrennte eventuell notwendige Datenversorgung dieser Dienste eingerichtet werden, die interne Datenquellen verwendet, ohne diese dem unsicheren Zugriff von außen auszusetzen. In der so genannten DMZ I dürfen auf keinen Fall geschäftsrelevante Daten gehalten werden. Die Haltung von lokalen Daten ist lediglich für Applikationsspezifika wie z.B. im Falle von Diskussionsforen und dergleichen erlaubt.

1.6.2

DMZ II als Netzsegment für intern zugreifbare Dienste

Die DMZ II befindet sich bereits im internen Netzsegment zwischen dem Application Level Gateway einer Anbindung und dem internen Packetfilter. In dieser Zone werden Anwendungen bzw. deren Server untergebracht, die nur intern zugreifbar sein sollen und die trotzdem einen gewissen Schutz benötigen, der über eine simple Zugriffskontrolle hinausgeht. Dies trifft auf viele Anwendungen, die Zugriff auf Datenbanken und andere primär geschäftsrelevanten Prozesse haben, zu. Auch der Zugriff zu diesen Anwendungen muss im Sinne einer einheitlichen Sicherheitspolicy geschützt werden, was sicherlich einerseits durch Zugriffskontrolle, anderseits aber durch direkte Kontrolle der Kommunikation mit den Anwendungen erreicht wird.

31

Sandini Bib 1 Firewall-Architektur

In der DMZ II können auch Datenquellen und Spiegelbestände untergebracht werden, die für den Zugriff aus dem LAN sowie anderen LANs im GAN-Verbund freigegeben sind.

1.6.3

Das interne Segment als Netzsegment für LAN-intern zugreifbare Dienste

Hinter dem internen Packetfilter in Richtung des lokalen Campus befindet sich das LAN der Lokation. Auch hier können noch Dienste untergebracht werden, die allerdings nur dem lokalen Netzwerk zur Verfügung stehen sollten oder die Datenquellen des lokalen Netzes sind. Diese Zone ist zwar ein komplett sicherer Bereich, allerdings ist, wenn der Zugriff auf einen Dienst gestattet ist und dieser kompromittiert werden kann, der Zugriff in eben diese komplett sichere Zone ohne weitere Chance auf Verhinderung oder Entdeckung möglich, was auf jeden Fall zu vermeiden ist. Gemäß des Standards dürfen in dieser Zone also lediglich komplett interne Dienste angesiedelt sein. Die Datenversorgung solcher Dienste über die DMZ I und DMZ II ist durch die Sicherheitskonstruktion kontrollierbar, und damit auch zulässig, was vor allem im Falle eines unternehmensweiten Wissensmanagement oder einer unternehmensweiten Data-Mart Struktur wichtig ist.

1.6.4

Schaffung einer DMZ II-Klasse-Zone ohne Außenanbindung

Sollen in Lokationen, die keine Anbindung an komplett unsichere Drittnetze wie z.B. das Internet haben, und dementsprechend auch nicht über ein Application Level Gateway und einen externen Packetfilter verfügen, auch interne Dienste bereitgestellt werden, die im GAN zur Verfügung stehen, so muss dies über den internen Packetfilter abgedeckt werden. Eine solche Konstruktion ist einfach zu erreichen. Es wird im internen Packetfilter ein weiteres Interface aktiviert, das zu einem im Campus befindlichen Netzsegment führt, in dem lediglich im GAN zugreifbare oder schützenswerte Dienste eingerichtet sind. Auf diese Weise wird für den Zugriff über das GAN die gleiche Zugriffs- und Netzkontrolle ermöglicht wie bei einer großen Sicherheitskonstruktion.

1.6.5

Die komplette Hosting-Infrastruktur im Überblick

Das folgende Bild soll die Hosting-Infrastruktur im Überblick für eine Lokation mit externer Anbindung zeigen. Hierbei werden Dienste für externe Kunden, Partner und Mitarbeiter bereitgestellt, Dienste für den unternehmensinternen Gebrauch sowie Dienste für den Gebrauch nur im lokalen Netz der Lokation.

32

Sandini Bib Sicherheitskonstruktionen als Hosting Area

GAN Backbone LAN Segment 1

Insecure Network

DMZ I externer Packetfilter

LAN Backbone

DMZ II Application Level Gateway

LAN Segment 2

interner Packetfilter

LAN Segment 3 Anbietung dritter Netze

nsecureand Untrusted Area

Secureand Controlled DMZ forexternal Services

Secureand Controlled DMZ forinternal Services

Trusted Area

Campusgrenze

Abbildung 1.14: Komplette Hosting-Infrastruktur

Die folgende Zeichnung zeigt das vereinfachte Schema für eine Lokation, das selbst keine Außenanbindung hat, aber dennoch Dienste im GAN anbieten soll.

LAN Segment 1

GAN Backbone

LAN Backbone

DMZ II

LAN Segment 2

interner Packetfilter Anbietung dritter Netze

Secure and Controlled DMZ for internal Services

Trusted Area

Campusgrenze

Abbildung 1.15: Lokation-Schema

33

Sandini Bib 1 Firewall-Architektur

1.7

Content Security

Die Sicherheitsrisiken, die sich in den Datenströmen einiger Dienste verbergen, werden oft stark unterschätzt und sind auch wesentlich schwieriger zu kontrollieren als die Risiken, die sich auf Netzwerkebene ergeben. Um einen möglichst hohen Standard an Content Security zu bekommen, ist es erforderlich, interne Netzwerksicherheit zu etablieren, in dem ein Netzwerk intern zu Point-to-Point-Verbindungen mittels Verschlüsselung zwischen den Kommunikationsendpunkten verändert wird. In Anbetracht der Tatsache, dass nach einschlägigen Studien mehr als 80% aller Schäden intern entstehen, ist dies sicherlich ein sinnvoller Schritt, der aber über die Etablierung eines Standards für Webanwendungen hinausgeht und darum in diesem Buch nicht ausgearbeitet werden kann. Nichtsdestotrotz sollen für die Anbindung von Webanwendungen bzw. die Anbindung von Benutzern an Webanwendungen einige Sicherheitsmaßnahmen auf Contentebene getroffen werden, die zumindest einen groben Schutz erlauben.

1.7.1

Skriptsprachen und externe Verbindungen

Viele Browser und andere Frontends unterstützen heute Skriptsprachen, die einen direkten Zugriff auf die Arbeitsstation des Benutzers ohne dessen Zutun ermöglichen. Dies geschieht vor allem ohne, dass es auch nur im entferntesten bemerkt werden kann. Solche Skriptsprachen sollten auf jeden Fall in einer Firewallkonstruktion gefiltert werden. Zumindest dann, wenn sie aus komplett ungesicherten Netzen wie dem Internet kommen. Im Bereich des GAN kann der Zugriff auf einige Skriptelemente möglich werden. Dies geschieht dann, wenn die durch das WebFarm-Konzept definierten Standards eingehalten werden, Auf jeden Fall gefiltert werden muss ActiveX, da dieses die Arbeitsstation komplett fernsteuerbar machen kann, was einen direkten Einbruch in das interne LAN einer Lokation und damit auch in das GAN bei entsprechender Berechtigung ermöglicht. Ebenso gefiltert werden muss VBScript, das die gleiche Funktionalität ermöglicht. Es ist noch erlaubt, JavaScript zu verwenden, da hiermit keine Fernsteuerung der Arbeitsstation möglich ist. Sollte dies aber in den Sprachumfang integriert werden, muss auch hier eine Filterung vorgenommen werden. Ähnliches gilt für Java, das aber aufgrund des Sicherheitmodells lediglich bei Implementationsfehlern auf Clientseite möglicherweise gefährlich werden kann – diese Fehler müssen daher bei Bekanntwerden sofort durch Einspielen von Patches behoben werden.

34

Sandini Bib Content Security

Diese Filterung wird im HTTP-Proxy oder anderen Proxy-Komponenten des Application Level Gateways eingestellt und dann dort auch vorgenommen. Die Benutzer müssen über diese Funktionalität der Anbindungsumgebung aufgeklärt werden.

1.7.2

Viren- und Trojanerscanning

Virenscanning im internen Netz und auf den Platten der Arbeitsstationen ist im internen Sicherheitsinteresse auch mit externer Virenabsicherung dringend zu empfehlen. Für die Kontrolle des in das Netz eingehenden Contents ist bei einer großen Sicherheitskostruktion innerhalb der DMZ I ein Proxy-Server vorgesehen, der im Gegensatz zu einem normalen Proxy-Server seine primäre Funktionalität auf das Scannen des übertragenen Contents nach Viren und trojanischen Pferden hat. Über einen solchen Server soll in der DMZ I aller HTTP- und FTPVerkehr geleitet werden, da dies die primären Quellen für den Import von Viren ist. In der DMZ II wird symmetrisch dazu ein Server für das Scannen des E-Mail-Verkehrs nach Viren abgestellt. HTTP (Web Access) FTP (File Transfer)

GAN Connection

SMTP (eMail)

Insecure Network

DMZ I externer Packetfilter

LAN Backbone

DMZ II Application Level Gateway

interner Packetfilter

Workstation Proxy-Ext + Scanner

Abbildung 1.16: Externe Plattform zum Scannen von Viren

Wichtig in einem globalen LAN-Verbund eines GAN ist es, dass die Patterns zur Erkennung von Viren auf diesen Rechnern immer aktuell gehalten werden und weltweit einen einheitlichen Stand haben. Über die WebFarm-Automatisierung bietet es sich an, die Verteilung dieser Patterns zu automatisieren

35

Sandini Bib 1 Firewall-Architektur

und von beliebiger Stelle deren Administration zu ermöglichen. Auf diese Weise aktualisiert immer der Erste, der ein Pattern-Update erhält, alle Scanner, und die Scanner haben immer den neuesten Stand. Da die meisten Viren Windows-basierende Rechner angreifen, empfiehlt es sich, die Plattform zum Scannen von Viren auf eine andere Betriebssystemebene zu verlagern.

1.8

Intrusion Detection

Da eine 100%ige Sicherheit selbst durch Sicherheitskonstruktionen militärischer Sicherheitsstufen nicht gewährleistet werden kann, ist die Erkennung von Eindringlingen in ein Netzwerk immer ein wichtiges Thema. Der Vorteil, den ausgereifte und mehrstufige Sicherheitskonstruktionen definitiv bieten, ist die Kontrolle über den erlaubten ein- und ausgehenden Verkehr, so dass die Erkennung von nicht zulässigen Paketen und Protokollen in Verbindungen grundsätzlich einfacher wird, je besser die Sicherheitskonstruktion ausgestattet wird. Das im WebFarm-Standard definierte dreistufige Sicherheitskonzept bei Außenanbindungen und Anbindungen an das GAN ist hierbei sehr gut für die Erkennung von Eindringlingen geeignet. Neben der Kontrolle des Verkehrs und der Verbindungen in und zwischen den Netzen ist auch die Kontrolle der zur Verfügung stehenden Dienste eine wichtige Komponente der Erkennung von Eindringlingen oder zumindest der Erkennung von Diensten, die nicht registriert sind, und ein Eindringen erleichtern könnten. Aus diesem Grunde sollten neben der Archivierung der allgemeinen Netzstruktur auch ein Scanning nach Diensten, die im Netz angeboten werden, durchgeführt werden, und in einer Berechtigungsdatenbank archiviert werden. Treten zusätzliche nicht registrierte Dienste auf, muss diesen nachgegangen werden, so dass keine Sicherheitslücken entstehen. Für das Nachvollziehen eines eventuellen Eindringens sowie den Aktionen des Eindringlings, aber auch für die Verfolgung von internen Sicherheitsproblemen und Vorfällen ist die Archivierung von gesammelten Daten unbedingt erforderlich. Diese Daten können zum Teil personenbezogen sein und fallen daher unter strenge Verchlussklauseln und Aufbewahrungsfristen, bieten aber im Falle eines Einbruchs oder eines Sicherheitsproblems die einzige Möglichkeit, den Vorgang nachzuvollziehen. Bei entsprechender Behandlung der Daten sind auch keine Konflikte mit dem Datenschutz zu befürchten.

36

Sandini Bib Intrusion Detection

1.8.1

Netzwerkscanning

Wie bereits beschrieben muss sowohl auf Netzwerkebene verfolgt werden, ob illegale Verbindungen oder Pakete auf einem Netzsegement auftauchen, aber auch nach angebotenen Diensten in den verschiedenen Netzsegmenten gesucht werden, die nicht registriert sind und daher potenzielle Sicherheitslöcher auftun können. Scannen auf Netzwerkebene Um alle Eventualitäten abzudecken, müßte an jeder Broadcast-unterdrückenden Stelle der Netzinfrastruktur ein Scanner platziert werden, der eben auch Broadcasts nach illegalen Inhalten scannt. Da dies aber die Kosten für eine Intrusion Detection im Verhältnis zum Nutzen in astronomische Höhen treiben würde, ist von einem solchen Ansatz abzusehen. Es wird an jeder Knotenstelle der Sicherheitsinfrastruktur ein Scanner etabliert, der dann für dieses Segment die Daten sammelt, die immer intern ausgewertet werden müssen. Der Zugriff auf die Scanergebnisse und die daraus resultierende Alarmierung kann automatisiert werden, allerdings ist hier ein Eingreifen im Sinne des Outsourcing nur durch Beauftragung durch internes Personal möglich, da die Intrusion Detection auf dieser Ebene gleichzeitig die interne Kontrolle des Outsourcing-Partners darstellt und auf personenbezogene Daten der Mitarbeiter zugreifen kann. An folgenden Stellen, wenn sie verfügbar sind, sollte in einer Lokation eine »Probe« installiert werden. Die Probes sind mit absteigender Priorität geordnet; soll also aus Kostengründen – oder weil angenommen wird, dass das Risiko ab einer bestimmten Ebene zu vernachlässigen ist – auf Probes verzichtet werden, dürfen diese nur von unten nach oben weggelassen werden. Auf jeden Fall ist das genaue Probing zu dokumentieren, damit im Falle der Verfolgung eines Eindringlings sofort Konzepte vorliegen. 1. DMZ I (externes Segment der Sicherheitskonstruktion) 2. DMZ II (internes Segment der Sicherheitskonstruktion) 3. LAN Backbone 4. Verbindung zum GAN Backbone 5. Verbindung zu unsicheren Netzen (meist nicht erforderlich) Die Daten werden alle nach innen geleitet und dort zu einem einheitlichen Bild zusammengefügt und verarbeitet. Die Alarmierung erfolgt nach Patterns, die als Attacken bekannt sind, oder nach Patterns, die der implementierten Sicherheitspolicy widersprechen.

37

Sandini Bib 1 Firewall-Architektur

GAN Connection

Probe 4 Insecure Network

DMZ I externer Packetfilter

Probe 5

LAN Backbone

DMZ II Application Level Gateway

Probe 1

interner Packetfilter

Probe 2

Probe 3

Collection Server

Admin Client

Abbildung 1.17: Installation von »Probes«

Scannen nach Diensten Es sollte ein Automatismus generiert werden, der regelmäßig einen verfügbaren Adressraum eines Netzsegmentes nach verfügbaren Rechnern und deren Diensten (netscan und portscan) durchsucht, diese speichert und mit registrierten Rechnern und Diensten vergleicht. Treten Differenzen auf, muss ein Administrator benachrichtigt werden, der den neuen Rechnern und Diensten nachgeht und diese entweder validiert, wenn deren Aufbau dem WebFarm-Standard entspricht, oder deren weiteren Betrieb unterbindet, wo dies möglich ist. Sollte ein Dienst trotz Nichteinhaltung von Standards noch betrieben werden müssen, so ist dieser in der Liste der Sicherheitsrisiken zu dokumentieren und die Betreiber eindeutig darauf hinzuweisen. Zusätzlich sollten die bekannten und registrierten Rechner mit ihren Diensten regelmäßig auf bekannte Verwundbarkeiten untersucht werden, was auch zu einem Reporting über den gesamten Sicherheitszustand aller WebFarm-Komponenten führt und im Rahmen der Dokumentation für Revision und Zertifizierung eine gute Basis liefert.

1.8.2

Logfristen

Alle relevanten Loginformationen aller WebFarm-Komponenten sollten für ein Accounting und spätere Auswertungen gesammelt und archiviert werden. Die Logpatterns und deren Relevanz sind im Bereich der Systemüberwachung dokumentiert.

38

Sandini Bib Intrusion Detection

Auf jeden Fall relevant sind alle Loginformationen, die in Sicherheitskomponenten generiert werden. Diese müssen sofort zentral archiviert werden, da sie bei der Verfolgung von Eindringlingen wichtige Daten enthalten. Für die Loginformationen, die erfasst werden, gelten die in folgender Tabelle beschriebenen, Aufbewahrungsfristen. Die vorliegende Aufstellung dient der übersichtlichen Darstellung der Aufbewahrungsfristen wesentlicher Dokumentationskomponenten gemäß der geltenden externen und internen Anforderungen für operative Systeme/ Anwendungen. Die Basis für dieses Verzeichnis wurde vom Arbeitskreis »EDV-Revisionen bei privaten Banken« unter Federführung des »Prüfungsverbandes deutscher Banken« erstellt. Ziel war die Erarbeitung der wesentlichen Dokumentationskomponenten im Rahmen einer ordnungsgemäßen Buchführung bei computergestützten Verfahren.

1.8.3

Hinweise

Die Aufbewahrungsfristen (siehe Tabellenüberschrift AF) sind in Jahren angegeben. Die genannten Sperrfristen beginnen am Jahresende der Außerbetriebnahme der jeweiligen Komponenten und gelten für den Regelfall. In der Spalte »Anforderungen« ist die Quelle genannt, die ausschlaggebend für die Wahl der Sperrfristen sind. Unterschieden wird in folgende Einträge: Anforderungskatalog (Katalog der Aufbewahrungsfristen – SAFRIST) GoBS (Grundsätze ordnungsgemäßer DV-gestützter Buchführungsysteme) MaH (Mindestanforderung an das Betreiben von Handelsgeschäften der Kreditinstitute) (Interne Anforderung)

1.8.4

Leitdokumentation

Dokumentationskomponenten

AF

Anforderungen

Programmier- und Systementwicklungsrichtlinien

10

GoBS

Dokumentationsrichtlinien

10

GoBS

Richtlinien für Programmtests

10

GoBS

Beschreibung Programmfreigabe und Änderungen

10

GoBS

Testrichtlinien

10

GoBS

Sachgebietsübergreifende Ablauf- und Schnittstellenbeschreibung

10

GoBS

Tab. 1.1: Übersicht Leitdokumentation

39

Sandini Bib 1 Firewall-Architektur

Dokumentationskomponenten

AF

Anforderungen

Organigramme (Bank/Teilbereiche)

2

Stellen- und Arbeitsplatzbeschreibungen

2

IDV-Richtlinien

10

GoBS

Programmkatalog/Dateikatalog/Satzartenkatalog

10

GoBS

Dokumentationskomponenten

AF

Anforderungen

Beschreibung des IKS (inkl. Formularmuster)

10

GoBS

Arbeitsablaufbeschreibung (inkl. Anweisungen zur Fehlerbereinigung und zur Vor- und Nachbehandlung von Daten

10

GoBS

Dokumentationskomponenten

AF

Anforderungen

Benutzerhandbücher/Bedienungsanleitungen

10

GoBS

Bildschirm- und Listenlayouts

10

GoBS

Schlüsselverzeichnis

10

GoBS

Tab. 1.1: Übersicht Leitdokumentation (Forts.)

1.8.5

Anwenderdokumentation

Organisationsanweisungen (bankspezifisch)

Tab. 1.2: Übersicht Organisationsanweisungen

Handbücher/Verzeichnisse (bankspezifisch)

Tab. 1.3: Übersicht Handbücher und Verzeichnisse

1.8.6

Betriebsdokumentation

Operatoranweisungen/Operatorprotokolle Dokumentationskomponenten

AF

Anforderungen

Beschreibung System-/Ablaufsteuerung (inkl. Sicherheitsregelung)

2

GoBS

Produktionspläne/Schichtpläne

2

GoBS

Sonderaufträge (Auswertungen); weitere OP-Aufträge 2 Tab. 1.4: Übersicht Operatoranweisungen und -protokolle

40

Anforderungskatalog

Sandini Bib Intrusion Detection

Dokumentationskomponenten

AF

Anforderungen

Sonderaufträge (mit Zugriff auf Praxisdaten; inkl. Protokolle über diesbezügliche Operatortätigkeiten)

6/10

GoBS; Anforderungskatalog

Protokolle Operatortätigkeiten (inkl. Protokolle über Softwarestörungen/Ablaufunterbrechung)

2

Anforderungskatalog

Protokolle über besondere Vorkommnisse/über Änderungen von Praxisdaten

6/10

GoBS

Dokumentationskomponenten

AF

Anforderungen

Beschreibung der Datensicherung

10

GoBS

Verzeichnis Programm- und Dateibibilotheken

10

GoBS

Auslagerungsprotokoll Datenträgerarchivierung

2

Anforderungskatalog/MaH

Tab. 1.4: Übersicht Operatoranweisungen und -protokolle

Datenorganisation/Datensicherung

Bestands- und Inhaltsverzeichnis; Datenträgerarchivie- Letzte rung (bei Fortschreibung) Version Tab. 1.5: Übersicht Datenorganisation und -sicherung

Zutritts-/Zugriffsregelungen Dokumentationskomponenten

AF

Anforderungen

Beschreibung des Zugriffschutzverfahrens (Anwendungen, Betriebssysteme, Datenbanken)

10

GoBS

Nachweis zu den vergebenen Berechtigungen/zugeordnete Benutzerprofile

10

GoBS

Beschreibung der Zutrittsregelung/der eingesetzten Verfahren

10

GoBS

Tab. 1.6: Übersicht Zutritts- und Zugriffsregelungen

Systemsoftware (Betriebssystem/Systemnahe Software) Dokumentationskomponenten

AF

Anforderungen

Systemhandbücher/-beschreibungen

10

GoBS

Verzeichnis eingesetzter Komponenten und Releases

10

GoBS

Parametereinstellungen

10

GoBS

Tab. 1.7: Übersicht Systemsoftware

41

Sandini Bib 1 Firewall-Architektur

Protokolling Dokumentationskomponenten

AF

Anforderungen

Beschreibung der Protokollierungsmechanismen

2

Anforderungskatalog/MaH

Protokollierung des Betriebs (Systemlogs, Joblogs)

2

Anforderungskatalog/MaH

Protokollierung der Dialogzugriffe

2

Anforderungskatalog/MaH

Weitere Protokollierungen (z.B. über sicherheitsrelevante Ereignisse)

2

Anforderungskatalog/MaH

Fehlermeldungen Anwendungssysteme

10

GoBS

Dokumentationskomponenten

AF

Anforderungen

Beschreibung Wartungs- und Fernwartungsverfahren (Zugriffsverfahren)

10

GoBS

Protokolle über Wartungstätigkeiten

2

Anforderungskatalog/MaH

Tab. 1.8: Übersicht Protokolling

Wartung

Tab. 1.9: Übersicht Wartung

Backup Dokumentationskomponenten

AF

Anforderungen

Wiederanlaufbeschreibung

10

GoBS

Protokolle der Backup-Tests

Letzte Version

GoBS

Dokumentationskomponenten

AF

Anforderungen

Verfahrensbeschreibung

10

GoBS

Testdaten und Testergebnisse

10

GoBS

Testprotokolle

10

GoBS

Tab. 1.10: Übersicht Backup

1.8.7

Entwicklerdokumentation

Testverfahren

Tab. 1.11: Übersicht Testverfahren

42

Sandini Bib Intrusion Detection

Projektsteuerung Dokumentationskomponenten

AF

Anforderungen

Vorgehensmodell

10

GoBS

Planungsunterlagen (PIT) bei Projekten

5

Sonstige Planungsunterlagen (PIT)

2

Fachkonzept

10

GoBS

DV- Fachkonzept

10

GoBS

Dokumentationskomponenten

AF

Anforderungen

Verfahrensbeschreibung

10

GoBS

Installationsprotokolle

10

GoBS

Tab. 1.12: Übersicht Projektsteuerung

Programmfreigabe/Programmänderungen

Änderungsnachweise/Versionsführung

10

GoBS

Freigabeerklärung

10

GoBS

Quellcode (inkl. Delta-Listings/Versionsfortschreibung/(Compiler oder andere zugehörige Systemsoftware)

10

GoBS

Dokumentationskomponenten

AF

Anforderungen

Datenmodelle

10

GoBS

Datenbankorganisation (Datensatzfeld/Formate)/ Verzeichnis der Dateien

10

GoBS

AF

Anforderungen

Tab. 1.13: Übersicht Programmfreigabe und -änderungen

Datenstrukturen

Tab. 1.14: Übersicht Datenstrukturen

Programmdokumentation Dokumentationskomponenten

Programmbeschreibung (Verzeichnisse/Menüs/Bild10 schirmaufbauhierarchien/Crossreferenzen/Programmablaufpläne/Entscheidungstabellen/Rechenformeln/ Dateibeschreibung/Satzbeschreibung)

GoBS

Buchungstellenanweisung

10

GoBS

Datenflusspläne

10

GoBS

Tab. 1.15: Übersicht Programmdokumentation

43

Sandini Bib 1 Firewall-Architektur

Dokumentationskomponenten

AF

Anforderungen

Verzeichnis automatisch erzeugter Buchungen

10

GoBS

Plausibilitätskontrollen

10

GoBS

Verzeichnis der Fehlermeldungen

10

GoBS

Dokumentationskomponenten

AF

Anforderungen

Linkage-Protokolle

10

GoBS

Tab. 1.15: Übersicht Programmdokumentation

Programmprotokolle

Tab. 1.16: Übersicht Programmprotokolle

Entwicklersoftware Dokumentationskomponenten

AF

Verzeichnis der betriebssystemnahen Entwicklung

2

Herstellerhandbücher (Hardware/Systemsoftware)

Letzte Version

Tab. 1.17: Übersicht Entwicklersoftware

44

Anforderungen

Sandini Bib

2

DNS

Das WebFarm-Konzept beinhaltet eine DNS-Infrastruktur, die ein internes unabhängiges Namenschema unterstützt. Interne Strukturen, sowohl organisatorischer als auch netzwerktechnischer Art, sollen nicht in die Außenwelt getragen werden, darum ist eine solche Trennung sinnvoll. Im internen Netz kann eine etwas breiter angelegte Namenstruktur zur Transparenz der Netzstrukturen und Servicestrukturen erheblich beitragen. Ein Relaying von DNS-Anfragen, die das externe Netz betreffen, kann über die Sicherheitskonstruktionen mit Außenanbindung erfolgen, so dass an jedem Punkt des internen Netzes der komplette Namenraum sowohl an internen als auch an externen Namen zur Auflösung bereitsteht, extern aber nur die Elemente bis DMZ I sichtbar sind, da diese auch offizielle Adressierungen besitzen. Dieses Dokument beschreibt den Aufbau von interner DNS-Infrastrukturanbindung an die weltweite DNS im Internet sowie die Namenvergabe im GAN, um strukturierte Schemata als Bestandteil des Standards zu präsentieren.

2.1

Internes und externes DNS

Wie bereits erwähnt, wird eine interne und eine externe DNS-Struktur aufgebaut. Die externe DNS-Struktur kann von den verschiedenen Punkten des GAN frei gewählt werden. Es ist unternehmenstechnisch sicherlich angenehmer, eine vorgegebene Namenstruktur zu haben, allerdings ist es oft marktbezogen nicht durchzusetzen. Die interne Struktur hingegen wird zentral definiert, und lokal werden die Unterbäume oder Blätter der definierten Hierarchie ausgefüllt. Der WebFarmStandard sieht vor, eine registrierte Domäne für den Aufbau der internen Namenstruktur zu verwenden, um eventuell die Möglichkeit zu haben, die Namenräume der internen und externen Welt miteinander zu kombinieren. Da es sich um die Namenstruktur für ein komplettes globales Netzwerk handelt, bietet sich als Top-Level-Domäne .net an. Die verwendete registrierte Second-Level-Domäne sollte etwas Unternehmensnahes sein, wie z.B. arago, die internen Namenserver würden in diesem Fall auf arago.net aufbauen.

45

Sandini Bib 2 DNS

.

net

arago

frankfurt

munich

www

com

de

arago

www

www

Abbildung 2.1: Infrastruktur

Um der verwendeten Domäne auch nach außen einen Sinn zu geben, können die Standardadressen wie www, ns, mail auf die externen Server des zentralen Zugangspunktes des Unternehmens umgeleitet werden; wie z.B. www.arago.net ist ein Pointer auf www.arago.de.

2.2

Struktur des internen Namenraums

Der interne Namenraum muss komplett unabhängig von anderen DNS sein, da ansonsten eine Verbindung nach außen vitaler Bestandteil der internen Netzstruktur wäre. Aus diesem Grund werden Nameserver geschaffen, die sowohl die Root-Domain ».« als auch die darunter liegenden unternehmen.netDomains verwalten. Unter dieser Third-Level-Domain, die für den gesamten Unternehmensverbund bezeichnend ist, werden nun Strukturen geschaffen, die der Unternehmensstruktur entweder organisatorisch oder nach Lokationen am Nächsten kommen. Die folgenden Diagramme zeigen eine Struktur, die geografisch ausgerichtet ist, wobei auf Basis der Städte und Länder wird. Es muss auf jeden Fall beachtet werden, dass die Strukturen nicht zu tief werden, da ansonsten die Namen nicht mehr ausschreibbar sind und somit zwar lokale Zugriffe einfach sind, da eine Domain-Zugehörigkeit feststeht, aber Zugriffe auf entfernte Dienste im GAN nur unkomfortabel zu erreichen sind.

46

Sandini Bib Struktur des internen Namenraums

.

net

arago

de

frankfurt

munich

usa

new-york

Abbildung 2.2: Struktur eines internen Namensraums

Eine Organisation nach Geschäftsfeldern oder Tochtergesellschaften könnte folgendermaßen aussehen:

.

net

arago

webfarm

intra-ffm

dmz-ffm

docme

dmz-ext-ny

intra-ny

Abbildung 2.3: Struktur eines internen Namensraums (2)

47

Sandini Bib 2 DNS

Der WebFarm-Standard lässt den Betreibern zwischen diesen Organisationsmodellen die Wahl. Unsere Erfahrung allerdings besagt, dass das zweite Modell, also das nach Organisationsstrukturen, einfacher zu handhaben ist und für die Benutzer logischer erscheint. Außerdem können so Lokationsveränderungen von Diensten, wenn sie korrekt geplant sind, für den Benutzer völlig transparent sein. Mehr als drei Unterstufen unter der Second-Level-Domain empfehlen sich nicht, bevor die tatsächlichen Blattknoten, also Rechner und Dienste angesprochen werden.

2.3

Aufbau der DNS-Infrastruktur

Es ist, wenn das DNS maximale Effizienz bringend eingesetzt werden soll, wichtig, dass das System mit einer sehr hohen Ausfallsicherheit aufgesetzt wird. Wenn man das Internet als Vorbild nimmt, in dem es nur sehr selten zu Ausfällen beim Auflösen von Namen kommt, kann man sich an der komplett verteilten Struktur der Root-Nameserver ein Beispiel nehmen. Es ist also wichtig, die Root-Nameserver des internen Netzes und die Nameserver für die Top-Level-Domains der internen Namenstruktur weltweit zu verteilen. Die Blattknoten sollten ebenfalls dupliziert werden. Das DNS schreibt einen Secondary-Nameserver vor. Für die Secondaries in der WebFarm-Infrastruktur werden allerdings die Transferzeiträume für die kompletten Datenbanken von den Primary-Nameservern von 24 Stunden auf 12 Stunden heruntergesetzt. Die Server sind weltweit verteilt, dabei werden die Regionen Europa, Amerika, Afrika und Asien (inklusive Australien) betrachtet. In jeder Region gibt es zwei Server, wobei in Afrika wegen der geringen Infrastrukturdichte auf den zweiten Server verzichtet wird. Jede Region hat einen Name-Space, der von beiden Servern im Mirroring-Verfahren gehalten wird. Jeder Server hat zwei Secondary-Server, die weltweit verteilt sind und so angelegt sind, dass keine Secondary-Primary-Beziehung doppelt auftaucht. Im folgenden Bild werden die Verbindungen zwischen den Servern verdeutlicht.

48

Sandini Bib Aufbau der DNS-Infrastruktur

Primary DNS Mirror Secondary DNS 2nd Secondary DNS

Abbildung 2.4: Verbindungen zwischen Servern

Die Server sollten auf einer modernen »bind«-Softwareversion beruhen, die das kontinuierliche Mirroring von Daten unterstützt. In jeder Region gibt es einen Server, an dem Änderungen für seine Region vorgenommen werden, die dann auf den anderen Server gespiegelt werden. Es ist möglich, die Regionen weiter zu unterteilen, so dass das lokale Management eines Namespace bei jedem Server erlaubt wird. Dieses Vorgehen ist aber nur sinnvoll, wenn an den jeweiligen Standorten genügend qualifiziertes Personal vorhanden ist, um die Server entsprechend zu pflegen. Es ist offensichtlich, dass das DNS an sich ein sehr einfaches System ist, aber in der Datenpflege eine sehr geringe Fehlertoleranz besitzt. Ein entsprechend sorgfältiger Umgang mit den Namendatenbanken und den Serverkonfigurationen ist hier ähnlich wie bei Sicherheitskonstruktionen auf jeden Fall vorauszusetzen, da viele andere Systeme auf der Verfügbarkeit des internen DNS beruhen. Genau aus diesem Grunde beinhaltet der WebFarm-Standard die Unterteilung zwischen internem und externem Namenraum, denn nur so kann die gesamte Kontrolle über die Verfügbarkeit von DNS-Servern im Unternehmen selbst gewährleistet und kontrolliert werden, was im Falle der Verwendung von Internet-Nameservern sicherlich nicht gegeben ist. Die Clients werden so konfiguriert, dass sie einen netzwerktechnisch am nächsten gelegenen Nameserver als Primary-Server verwenden, den zweiten Primary-Server der Region als Secondary eingetragen haben, den ersten Secondary-Server der Region als weiteren Secondary und den zweiten Secondary-Server der Region als zusätzlichen weiteren Secondary. Auf diese Weise ist die Verfügbarkeit des Namendienstes mit einer sehr hohen Ausfallsicherheit gegeben.

49

Sandini Bib 2 DNS

Alle Server fungieren auch als Root-Server und werden in der DNS-Konfiguration (cache.de) auch als solche angegeben. Auf diese Weise ist auch die Verfügbarkeit der Top-Level-Domain immer gewährleistet.

2.4

Datenverwaltung

Wie bereits erwähnt, können die DNS-Daten sowohl in den für DNS-üblichen Datendateien als auch in einer Datenbank abgelegt werden. Wird eine Datenbanklösung bevorzugt, was bei derart großen Netzstrukturen im WebFarmStandard empfohlen wird, sollte diese für eine Region an die Netzwerküberwachung angeschlossen sein. So können aus OpenView-Datenbanken auch Nameserver-Datenbanken erzeugt werden, und es ist gewährleistet, dass das Netzwerkmanagement eine eindeutige Sicht auf die vorhandenen Rechner und deren Namensgebung hat. Ist eine Koppelung an das Netzwerkmanagement nicht möglich, so existieren im Internet frei verfügbare Werkzeuge, um DNS-Management zu betreiben, die in diesem Falle eingesetzt werden können.

50

Sandini Bib

3

Proxy-Infrastruktur, Browser-Konfiguration und Zugriffsberechtigung

Dieses Kapitel beschäftigt sich mit dem Design einer Proxy-Infrastruktur für Webanwendungen und Anwendungen der neuen Medien. Es wird eine Infrastruktur aus Proxy-Server beschrieben, die HTTP/S und FTP mit ProxyCache-Funktionalität bedienen und direkte Verbindungen als Proxy durchschleusen können. Der Sinn einer solchen Infrastruktur ist es, die Performance von Anwendungen durch die lokale Verfügbarkeit von Seiten zu erhöhen und, noch wichtiger, Bandbreite auf teuren Verbindungen durch das Caching einzusparen.

3.1

Application-Proxy vs. Web-Proxy

Viele Anwendungen haben eigene Proxyservices, die eventuell auch eine Cache-Infrastruktur abbilden können. Es ist aber auf keinen Fall sinnvoll, pro Anwendung eine Proxy-Infrastruktur zu designen, da dies einen enormen Hard- und Software-Betriebsaufwand verursachen würde, der betriebswirtschaftlich und administrativ völlig untragbar wäre. Ähnlich wie beim Anwendungsdesign im Webbereich, das so ausgelegt ist, dass Webanwendungen direkt im Browser ablaufen können, muss bei der Infrastruktur und den Anwendungen darauf geachtet werden, dass eine Standard-Web-ProxyInfrastruktur für die Abwicklung der Anwendungszugriffe verwendet werden kann. Dabei gilt grundsätzlich, dass Caching aufgrund der Kostenersparnisse berücksichtigt werden und darum ein entsprechendes Anwendungsund Tool-Design eingehalten werden muss. Eigene Proxy-Services für Anwendungen und Werkzeuge sind nur im Komplex der Firewall vorgesehen, wo auf dem Application-Level-Gateway entsprechende applikationsspezifische Proxy-Server abgelegt werden können, wenn diese sicherheitszertifiziert sind. Im Bereich der Firewall werden ProxyServer zur Netzwerktrennung eingesetzt, wozu man auf Applikationsebene eine entsprechende Umsetzung machen muss. Fazit: Anwendungen müssen für Caching und zum Benutzerzugriff WebProxy-Server unterstützen oder zumindest so designed sein, dass cachebare Informationen in einer solchen Web-Proxy-Infrastruktur auch zwischenge-

51

Sandini Bib 3 Proxy-Infrastruktur, Browser-Konfiguration und Zugriffsberechtigung

speichert werden können. Applikationsspezifische Proxy-Server werden nur auf Application-Level-Gateway in Firewalls zur Unterstützung der 100%igen Netzwerktrennung eingesetzt.

3.2

Proxy-Konzept

Viele Informationen, die in Webanwendungen abgelegt sind, werden nicht als dynamisch angesehen, das bedeutet, sie haben eine Gültigkeitsdauer, in der sie sich nicht verändern. Da ein bestimmender Faktor in den IT-Kosten heutzutage die Bandbreite in WAN-Verbindungen ist, ist auf jeden Fall dafür zu sorgen, dass Dokumente, deren Lebensspanne noch nicht überschritten ist, möglichst selten über solche Leitungen übertragen werden. Dies bedeutet, solche Dokumente müssen in einem Cache zwischengespeichert werden. Ein solcher Cache wird verbunden mit einem Proxy-Server, der den zentralen Zugriffspunkt einer Einheit auf Internet- und GAN-Services bietet. Ein solcher Zugriffspunkt hat neben der Informationsspeicherung und damit der Bandbreitenoptimierung auch den Vorteil der Zugangskontrolle auf bestimmte Dienste anhand der Dienste selbst oder anhand eines Berechtigungskonzepts. Da solche Cache- und Proxy-Server auch kaskadiert werden können, bietet es sich an, eine entsprechende Hierarchie zu schaffen, die eine weitere Optimierung der Bandbreite zulässt. Die Konfiguration für eine solche Zugriffshierarchie auf Clientseite kann manuell umständlich werden, insbesondere wenn Ausfallssicherheitskonzepte ebenfalls implementiert werden sollen. Aus diesem Grund wird zugleich von den Servern eine automatische Browser-Konfiguration vorgenommen werden, die alle notwendigen Konfigurationen für den Benutzer vornimmt.

3.3

Zugang zu internen Netzen

Der WebFarm-Standard definiert das Layout eines Zugangspunkts zu anderen unsicheren Drittnetzen in der Sicherheitsinfrastruktur. Hier wird in der DMZ II ein Ort geschaffen, in dem interne Dienste bereitgestellt werden können, wie z.B. der Dienst eines Zugangs-Proxy-Servers. Es ist davon auszugehen, dass ein solcher Proxy-Server, da es nur eine beschränkte Anzahl an Zugangspunkten zu externen Netzen innerhalb des GAN gibt, stark belastet ist, darum sollte er sofort auf ein Clustering-System oder einen Proxy-Cluster ausgelegt werden. Von Anfang an sollten also in der DMZ II eines Zugangsknotens zwei interne Proxy-Server verfügbar sein. Diese internen Proxy-Server sind für das Routing eventuell eingehender interner Requests zu anderen internen Servern verantwortlich, für die Benutzerberechtigung und für die

52

Sandini Bib Proxy-Hierarchie

Zugriffskontrolle an sich. Ebenso stehen diese Server in Kontakt mit den so genannten PAC(Proxy Automatic Configuration)-File-Servern, um die Möglichkeiten zum Load-Sharing und zur Ausfallsicherheit mit den Proxy-Clustern und anderen Zugangspunkten zu verwalten. In der DMZ I, also in der externen DMZ der Sicherheitskonstruktion, befindet sich ein gleich konzipierter Cluster an Proxy-Servern, die den tatsächlichen Zugang in das externe Netz vornehmen. Diese Server haben die Aufgabe, Content-Security zu implementieren sowie das allgemeine Filtern von ungewollten Seiten (z.B. Pornographie oder Gewalt) vorzunehmen. Das Routing unter diesen Proxy-Servern ist so ausgelegt, dass sie auch beim Ausfall einzelner Komponenten dieser beiden kaskadierten Cluster verfügbar sind und ggf. lediglich die Performancefluktuationen aufweisen. PAC-FileServer

Internet

LAN Externer Packetfilter

Interner Paketfilter Packetfilter

Application Levelgateway Proxy-ext-1 Proxy-ext-2

ClusterManagement/Load Sharing

Proxy-in-1

BrowserConfiguration RoutingInformationExchange

Proxy-in-2

Client

Client AccesstoProxy Proxy AccesstoProxy AccesstoFinal Destination

Abbildung 3.1: Routing unter Proxy-Servern

Für den Zugriff auf interne Anwendungen bzw. Anwendungen im GAN wird eine andere Proxy-Konstruktion verwendet.

3.4

Proxy-Hierarchie

Wie bereits kurz in der generellen Idee der Proxy-Infrastruktur beschrieben, ist es sinnvoll, eine Hierarchie von Proxy-Servern aufzubauen, welche die Kommunikation innerhalb des GAN und mit den Verbindungen nach außen so bandbreitenschonend und effizient wie möglich gestalten. Studien über allgemeine Anwendungsentwicklung besagen, dass in kürzester Zeit 75% aller Anwendungen als Webanwendungen realisiert werden, was auf die offensichtlichen Vorteile dieser Plattform zurückzuführen ist. Aus

53

Sandini Bib 3 Proxy-Infrastruktur, Browser-Konfiguration und Zugriffsberechtigung

diesem Grund muss eine Proxy-Infrastruktur robust sein und auch zukünftigen Anforderungen standhalten bzw. entsprechend erweiterbar sein. Der Nutzen einer Proxy-Infrastruktur wird durch die Anwendungsentwicklung an sich festgelegt, denn die Anwendungen müssen ein Caching von nicht veränderten Daten unterstützen und können auf diese Weise die Kommunikation im GAN wesentlich verbessern sowie enorme IT-Kosten einsparen, die anfallen würden, wenn Bandbreitenerweiterungen für ganze GANs im größeren Umfang notwendig werden. Die entsprechenden Vorgaben sind im Anwendungsentwicklungsteil des WebFarm-Standards hinterlegt. Generell ist davon auszugehen, dass es unterschiedliche Größen von Arbeitsgruppen gibt, die mit unterschiedlichen Anforderungen Anwendungen innerhalb ihrer eigenen Arbeitsgruppe und innerhalb des GAN beanspruchen. Hierbei ist dann auch eine entsprechende Proxy-Infrastruktur erforderlich. Die Anbindungspunkte an externe Netze bieten gute Knotenpunkte in der Infrastruktur, da sie ohnehin technisch und GAN-verbindungstechnisch am besten ausgestattet sind. PAC-FileServer

Internet

LAN Externer Packetfilter

Interner Packetfilter

Application Levelgateway Proxy-ext-1 Proxy-ext-2

ClusterManagement/Load Sharing

Proxy-in-1

GAN Application BrowserConfiguration RoutingInformationExchange

Proxy-in-2

intraproxy-1 intraproxy-2

Client

LAN Application Client AccesstoProxy Proxy AccesstoProxy AccesstoFinal Destination

Abbildung 3.2: Proxy-Infrastruktur

Darum werden an den Anbindungspunkten so genannte Intra-Proxy-Cluster errichtet, die das interne Routing der Proxy-Infrastruktur übernehmen und den Zugriff auf interne Applikationen steuern. Die automatische Konfiguration der Clients unterscheidet anhand des eingeführten DNS, welche Zugriffe intern und welche über die Außenanbindung zu erfolgen haben, und verwendet also entsprechend die Proxy-int- oder Intra-Proxy-Server beim Zugriff.

54

Sandini Bib Proxy-Hierarchie

Für den Aufbau der eigentlichen Hierarchie sind vier verschiedene Arbeitsumgebungen, an Größe der Umgebung gemessen, vorgesehen. Es handelt sich nach kleiner werdender Größe sortiert um die Typen 왘 Zentrale 왘 Niederlassung 왘 Geschäftsstelle 왘 Außenstelle

Generell kann aber gesagt werden, dass ab einem Team von vier Benutzern, die in ihrer täglichen Arbeit mehr als 25% Webanwendungen nutzen sollen, ein Proxy auf jeden Fall sinnvoll ist. Betrachtet man den Anstieg am Nutzen von Webanwendungen muss man also von einer Proxy-Infrastruktur ab einer Außenstelle von vier Benutzern rechnen, die mit großer Wahrscheinlichkeit über eine sehr langsame Leitung angebunden sind und daher die Investition in einen Proxy-Server eher rechtfertigen, als die Leitung zu erweitern. Ohne Proxy-Server muss von einer Leitungsverfügbarkeit von 64 KBps bis 128 KBps pro Benutzer ausgegangen werden.

proxy-in

intraproxy

ne

bo

ck

AN

Ba

Client

Client

G

Intraproxy-sub-1

Client

Client

Intraproxy-sub-2

Client

Client

Intraproxy-sub-3

Client

Client

Abbildung 3.3: Konfiguration Proxy-Routing

55

Sandini Bib 3 Proxy-Infrastruktur, Browser-Konfiguration und Zugriffsberechtigung

Die Skizze zeigt die Konfiguration des Proxy-Routings sowie der Client-Konfiguration. Sowohl das Routing als auch vor allem die Client-Konfiguration wird durch PAC-Files generiert, um auf eventuelle Systemausfälle oder Netzwerkbesonderheiten dynamisch reagieren zu können. Bis auf die Zugriff-Cluster für externe Netze benötigen die Proxy-Server keine Zugriffskontrolle, da das GAN ein offener Transaktionsraum ist. Einzelne Anwendungen im GAN werden nicht durch die Proxy-Server, sondern durch deren Benutzerverifikation bzw. Freischaltungen in der Firewall an sich geschützt.

3.5

Browser-Konfiguration

Alle Browser-Konfigurationen werden automatisch generiert und vom Browser bei jedem Start vom so genannten PAC-File-Server heruntergeladen, wenn dieser verfügbar ist. Sollte der PAC-File-Server nicht verfügbar sein, wird eine Standardeinstellung verwendet, die ebenfalls durch den PAC-File-Server verteilt werden kann, wenn eine Verbindung zu diesem besteht. Eine solche automatisierte Konfiguration der Browser ist sehr sinnvoll, da auf diese Weise auch bei Netzwerk- und Infrastrukturveränderungen keine weitere Interaktion mit Clients und Client-Arbeitsplätzen erforderlich wird, was die Kosten für solche Änderungen und Erweiterungen erheblich verringert. Zusätzlich werden lokale Konfigurationsfehler als Fehlerquelle ausgeschlossen, was den Benutzersupport erheblich entlastet.

3.5.1

Zentrale

In zentralen Standorten ist die Konfiguration der Browser komplexer als in anderen Standorten. Dies liegt daran, dass hier der Browser unterscheidet, ob es sich um einen GAN-Zugriff oder um einen Zugriff auf externe Netze handelt. Im Falle eines Zugriffs auf GAN-Applikationen werden Zugriffe auf den Cluster der Intra-Proxy-Server gesendet und direkt dort verarbeitet. Da hier auch keine Benutzerkontrolle vorgenommen wird, ist es nicht erforderlich, in der Zentrale selbst eine Schicht zwischen Proxy-Proxy-Verbindungen und Client-Proxy-Verbindungen einzuziehen. Im Falle eines Zugriffs auf externe Adressen wird der Proxy-In-Cluster verwendet, der direkt über die Sicherheitskonstruktion und unter Verwendung der Proxy-Ext-Cluster eine Verbindung zum gewünschten externen Server herstellen kann, wenn der verwendete Client über die entsprechende Berechtigung verfügt und die gewünschte Zieladresse nicht generell gefiltert wird.

56

Sandini Bib Cache

3.5.2

Nicht-Zentrale

In allen anderen Standorten, sprich in allen Standorten, die nicht selbst über eine Außenanbindung verfügen, werden die Clients so konfiguriert, dass sie auf jeden Fall ihren lokalen Proxy verwenden. Die Proxy-Konfiguration wird so erweitert, dass die in der Hierarchie höher liegenden Proxy-Server als FallBacks verwendet werden, wenn der lokale Proxy-Server nicht verfügbar ist, so dass der Client in fast allen Fällen eine Verbindung zur gewünschten Anwendung erhalten wird. Aus diesem Grund muss auch der Intra-Proxy-Cluster so konfiguriert sein, dass er ggf. (im Fall-Back-Fall) Anfragen an den Proxy-In-Cluster weiterleiten kann.

3.6

Cache

Eine der wichtigsten Funktionen der Proxy-Server ist der Cache, also das Zwischenspeichern von Daten, damit diese nicht über externe Verbindungen wieder und wieder herangeholt werden müssen. Die verwendeten Protokolle unterstützen im Caching eine Nachfrage an den Originalserver, ob sich das Dokument verändert hat – wenn nicht, wird das Dokument nicht neu übertragen, sondern der Client, der den Proxy nach dem Dokument gefragt hat, bekommt das zwischengespeicherte Dokument; wenn sich das Dokument verändert hat, wird es heruntergeladen und auf dem Proxy-Cache-Server zwischengespeichert und steht somit auch anderen Clients zum Abruf zur Verfügung. Generell ist die Art des Caching und die Strategie des Caching abhängig von der Software zu sehen. Es sollte aber ein moderner Priority-Queue-CacheAnsatz gewählt werden, der auch von allen Produkten, die im WebFarmStandard eingesetzt werden, verwendet wird. Zusätzlich ist die Frage nach Garbage-Collection, also dem Sammeln alter Daten, die im Zwischenspeicher liegen und nie oder nur sehr selten abgerufen werden und wichtigeren Daten den verfügbaren Speicherplatz wegnehmen, zu stellen; eine solche Garbage-Collection oder eine Reorganisation des Cache-Space sollte auf jeden Fall definierbar sein.

3.6.1

Was kann gecached werden?

Die Grundsatzfrage nach der Effizienz von Anwendungen oder der Effizienz von Proxy-Servern an sich ist, was kann eigentlich alles gecached werden, und was muss eins zu eins durchgeschleust werden.

57

Sandini Bib 3 Proxy-Infrastruktur, Browser-Konfiguration und Zugriffsberechtigung

Die Antwort ist relativ einfach. Gecached werden können alle Informationen, die eine gleich bleibende URL, also eine gleich bleibende Lokation in einer Anwendung, haben und nicht direkten Programmcode oder Verschlüsselung beinhalten. Nicht gecached werden können alle Informationen, die dynamische URLs haben, Anwendungen, die auf dem Server ausgeführt werden müssen, um Programmresultate zu übertragen, oder Anwendungen, die dem Client übertragen werden und dort nicht abgelegt werden. Nicht gecached werden also z.B. Dokumente, die von einem Such-CGI zurückgeliefert werden oder von einem datenbankbasierten Content-Management-Werkzeug, das jeden Zugriff auf die Informationsbasis dynamisch generiert; genauso wenig gecached werden JAVA-Applets, weil diese Informationen enthalten, die sich von Release zu Release ändern können. Ebenfalls nicht zwischengespeichert werden verschlüsselte Informationen, also Informationen, die per SSL übertragen werden. Caching von Applets und SSL-Übertragungen Applets werden, weil es ja Applikationen sind, die für das einmalige Ausführen gedacht sind, genauso wenig wie verschlüsselt übertragene Daten nicht zwischengespeichert, da Applets und auch verschlüsselte Daten durchaus cachebar sein sollten, wenn dies der Sicherheitsstufe der Infrastruktur entspricht, was bei internen Netzen gegeben ist. Es ist darum möglich, Applets mit einem Zertifikat bei der Entwicklung zu versehen, das die Version des Applets und dessen Authentizität kennzeichnet. Der Proxy-Server kann angewiesen werden, dass korrekt identifizierte und versionierte Applets zwischengespeichert werden. In einigen Situationen kann der Proxy auch mit einem eigenen Verschlüsselungszertifikat ausgerüstet werden und kann dann auch gemäß des WebFarm-Standards angewiesen werden, mit SSL übertragene HTML- oder andere Dateien zwischenzuspeichern.

3.7

Reverse-Proxy als Anwendungsschutz

Um einen besonderen Schutz für den Zugriff auf bestimmte Anwendungen zu schaffen, ist es eventuell wünschenswert, den Zugriff auf Anwendungen über einen zentralen Punkt zu etablieren. Hierbei kann ein Proxy-Server verwendet werden, der in entgegengesetzter Richtung arbeitet – als ReverseProxy.

58

Sandini Bib Normaler Zugriff

3.8

Normaler Zugriff

Bei einer Webanwendung, die in einem geschützten Segment einer Firewall steht, werden die Zugriffe der externen Benutzer meist durch einen Packetfilter auf einen bestimmten Port der Webanwendung (üblicherweise 80 oder 443) beschränkt. Die Anwendung selbst muss sich um Verschlüsselung, Zugriffsberechtigungen und Content-Berechtigungen sowie potenzielle Angriffe kümmern.

Client Ethernet

WAN Packet Filter

Application

Client

Client

Abbildung 3.4: Normaler Zugriff

Diese Installation bietet üblicherweise ein ausreichendes Maß an Sicherheit, da die Berechtigungsstrukturen in Webanwendungen sehr granulär definiert werden können. Soll aber der Zugriff auf die Anwendung ohne Kontakt zur eigentlichen Anwendung eingeschränkt werden, soll bei externen Zugriffen auf eine interne Anwendung Verschlüsselung zum Einsatz kommen oder auch die Trennung von Zugriffssegmenten erzeugt werden, so ist die normale Lösung nicht ausreichend.

3.9

Zugriff über einen Reverse-Proxy

Konstruktionen mit Reverse-Proxy-Servern können diese Anforderungen erfüllen. Sie bieten einen Zugriffspunkt für zumeist externe Benutzer auf bestimmte Anwendungsgruppen, der vom Unternehmen selbst kontrolliert werden kann und noch nicht dem Sicherheitsniveau der Anwendungen selbst entsprechen muss.

3.9.1

Reverse-Proxy zur Zugriffskontrolle

In der Konfiguration des Reverse-Proxy-Servers kann eine Zugriffskontrolle auf die Anwendung selbst erfolgen. Es stehen hierbei alle Kontrollmechanismen des HTTP-Protokolls zur Verfügung. Grundsätzlich ist die beste Lösung

59

Sandini Bib 3 Proxy-Infrastruktur, Browser-Konfiguration und Zugriffsberechtigung

eine Zugangskontrolle über Zertifikate, aber auch Passwortverfahren sind möglich. Die im WebFarm-Standard eingesetzte Proxy-Software unterstützt auch Side-Includes, über die andere Methoden eingebracht werden können, die aber für spezifische Anwendungen ausgewählt werden müssen. Zusätzlich können bereits bestimmte Teile von Webanwendungen, die über URLs gekennzeichnet werden, durch die Identifikation des Benutzers am ProxyServer für bestimmte Benutzer überhaupt zugreifbar bzw. bereits am ProxyServer verweigert werden.

Client

Client LAN

Ethernet ApplicationLevelGateway

Application

WAN Packet Filter

ReverseProxy

Client

Client

Abbildung 3.5: Zugriff über Reverse-Proxy

Das Vorhandensein einer Zugriffskontrolle über den Proxy-Server sollte die Anwendung nicht davon entbinden, selbst eine Berechtigungsschematik zu implementieren. Es kann so ein durchaus sinnvoller doppelter Schutz geschaffen werden, vor allem wenn der Reverse-Proxy für differenzierte Benutzergruppen eingesetzt wird.

3.9.2

Reverse-Proxy zur Trennung der Zugriffssegmente

Ist diese Trennung sicherheitstechnisch noch nicht ausreichend, können die Segmente, in denen die Anwendung platziert ist und in denen der tatsächliche Zugriff der Benutzer erfolgt, über den Reverse-Proxy getrennt werden. Dabei steht der Reverse-Proxy in einem anderen Segment des gefilterten Netzwerks als die Anwendung. Ein Zugriff auf dieses Segment ist dann über den Packetfilter nur noch vom Reverse-Proxy aus möglich. Auf diese Weise entsteht ein zusätzlicher Schutz für den Anwendungsserver selbst, und die Benutzerkontrolle auf bestimmte Serverbereiche kann auf dem Reverse-Proxy vorgezogen werden. Wie bereits erwähnt, kann dies nicht die Anwendung von einer eigenen Benutzerkontrolle entbinden. Eine zusätzliche Möglichkeit des Reverse-Proxy-Servers ist das Ändern des Namens der Anwendung, wenn z.B. eine Anwendung in der DMZ über einen DMZ-Strukturnamen angesprochen wird, vom GAN oder Internet aus

60

Sandini Bib Zugriff über einen Reverse-Proxy

Ethernet

aber über einen anderen Namen erreichbar oder zusätzlich über einen anderen Namen erreichbar sein soll, kann ein entsprechendes Mapping auf dem Proxy-Server konfiguriert werden. Bei einer solchen Konfiguration ist darauf zu achten, dass entweder die Anwendung so designed ist, dass sie nur relative Links in der eigenen Anwendung verwendet oder dass der ReverseProxy-Server, was mit der im WebFarm-Standard vorgeschlagenen ProxyUmgebung möglich ist, ein Content-Scanning vornimmt und eventuelle Links und Verweise auf den internen Server, der ja nicht angesprochen werden soll, erkennt und in die Adresse des Reverse-Proxy-Servers einträgt.

ApplicationServer Client

Client LAN

Ethernet ApplicationLevelGateway

WAN PacketFilter Packet Filter

Client

Client ReverseProxy

Abbildung 3.6: Reverse-Proxy mit Trennung der Zugriffssegmente

3.9.3

HTTPS-Zugriff auf HTTP-Anwendungen

In vielen Fällen macht es Sinn, eine interne Anwendung, die innerhalb des GAN einen Sicherheitsstandard hat, der keine Verschlüsselung vorschreibt, für den externen Gebrauch verschlüsselt anzubieten, da hier im Gegensatz zum GAN keinerlei Kontrolle über die Netzwerkwege besteht. Anwendungen, die für den internen Gebrauch entwickelt wurden und dann doch einem sicheren Umfeld zugeführt werden sollen, bzw. Anwendungen, die nachträglich durch Verschlüsselung abgesichert werden sollen, können mit einem Reverse-Proxy-Server von HTTP- auf HTTPS-Übertragung, die SSL zur Verbindungsabwicklung verwendet, umgestellt werden. Dabei erfolgt der verschlüsselte Zugriff vom Client bis hin zum ReverseProxy, der in diesem Falle ein eigenes Zertifikat benötigt. Der Reverse-Proxy selbst setzt dann auf den eigentlichen Application-Server um. Der WebFarmStandard sieht hier zwei verschiedene Konfigurationen vor. Erstens kann ein ganz normaler Reverse-Proxy-Server verwendet werden, der den Zugriff auf einen internen Application-Server umsetzt, wie das bei

61

Sandini Bib 3 Proxy-Infrastruktur, Browser-Konfiguration und Zugriffsberechtigung

Ethernet

den vorhergehenden Modellen bereits der Fall war. Zusätzlich zu den bisher beschriebenen Aufgaben des Reverse-Proxy-Servers kommt in diesem Fall noch das Umsetzen von HTTPS nach HTTP hinzu.

Application Server

Client

Client LAN

Ethernet Application Level Gateway

WAN Packet Filter

Client

HTTP HTTPS

Client

Reverse Proxy

Abbildung 3.7: Reverse-Proxy mit Umsetzung HTTP/HTTPS

Im anderen Falle wird der Reverse-Proxy-Server in den WWW-Server des Application-Servers integriert, und er setzt den Zugriff auf die lokale Maschine des Application-Servers um, eben nur auf den anderen Port. Hierzu kann entweder eine HTTPS nach HTTP-Umsetzung verwendet werden oder eben der Zugriff auf den Webtree des Application-Servers. Letztes ist nur sinnvoll möglich, wenn keine Namenumsetzung oder zusätzliche Benutzerberechtigung erfolgen soll und wenn der Aufwand, einen zweiten, identisch konfigurierten Webserver aufzusetzen, vertretbar ist.

Client

Client LAN

Ethernet Application Level Gateway

Packet Filter

Application

62

Client

Client

HTTP HTTPS

Abbildung 3.8: Integrierter Proxy

WAN

Sandini Bib

4

Authentifizierung/ Autorisation

4.1

Zielsetzung für dieses Dokument

Zunächst einmal muss es als nicht zentrale Aufgabe einer Webumgebung gesehen werden, einen unternehmenszentralen Identifikations- und Berechtigungsservice bereitzuhalten, auch wenn PKIs meistens über Webanwendungen realisiert werden. Ziel dieses Dokuments ist es, die Anforderungen an einen Authentifizierungs-Service und dessen Protokolle abzustecken, die Webanwendungen und deren Umgebung an derartige Dienstleistungen haben. Selbstverständlich kann dieses Dokument auch als Grundlage für den Aufbau entsprechender PKI- und Directory-Lösungen verwendet werden, da die Basisideen einer modernen Identifikations- und Berechtigungsumgebung selbstverständlich abgedeckt sind.

4.2

Grundsätze der Berechtigungsstruktur

Grundsätzlich ist die Geschichte von Berechtigungen und Rechten einzelner Benutzer so alt wie die Anwendungsentwicklung auf IT-Systemen selbst. Aktuell wird eine Rechtevergabe aber nicht mehr nur an einen Benutzer selbst festgemacht, sondern an den Rollen des Benutzers innerhalb eines Unternehmens und dessen Zugehörigkeit zu verschiedenen Rollengruppen. Es wird in diesem Falle von einer so genannten rollen-orientierten Berechtigung gesprochen, die auch die Trennung von Person und Rollen, wie sie von vielen internen und externen Revisionen gefordert wird, unterstützt. Auf diese Weise können darauf folgende Berechtigungsstrukturen eben nicht an Benutzern selbst, sondern an deren Rollen innerhalb des Unternehmens festgemacht werden, was die Abhängigkeit von Unternehmen gegenüber einzelnen Personen verringert, die Verwaltung von Personalentwicklungen vereinfacht und einen generell besseren Überblick über die Berechtigungsstruktur erlaubt. In dieser Berechtigungsstruktur werden nun einzelne Rechte an bestimmte Rollengruppen vergeben.

63

Sandini Bib 4 Authentifizierung/Autorisation

User

User

CEO

User

Accountant

User

User

Manager

IT Staff

Abbildung 4.1: Benutzer und Berechtigungen

User

CEO

See Accounting

User

User

Accountant

Create Users

User

User

Manager

IT Staff

See Controlling

Computer Admin Logon

Abbildung 4.2: Benutzergruppen und Berechtigungen

Da es in größeren und globalen Organisationen eine Vielzahl von Rollen und eine noch größere Vielfalt an Rechten gibt, die zusätzlich noch von der Kombination von Rollen abhängen können, werden die Berechtigungen und Rollen sinnvollerweise in einer geordneten Struktur abgelegt und miteinander verbunden. Eine Baumstruktur bietet sich hier an, da mit dieser gleichzeitig »Ober«- und »Unter«-Rechte definiert werden können. In einer Baumstruktur an Rechten ist ein in der Hierarchie tiefer angesiedeltes Element immer eine Untermenge an Rechten, die in der höheren Ebene vorhanden sind.

64

Sandini Bib Grundsätze der Berechtigungsstruktur

GOD

Accounting See Data

Change Data

Create Reports

Controlling

IT

Abbildung 4.3: Struktur von Berechtigungen

Der Nachteil einer solchen Organisation von Rechten ist, dass es immer eine absolute Superberechtigung gibt, God oder Superuser, die alle Rechte, die definiert sind, vereinen. Andererseits ist es einfach klar definiert, dass eine solche Berechtigung nicht an einen Benutzer weitergegeben wird. GOD CEO Accounting Head of IT Departmenr

Head of Accounting

See Data

Head of Contolling

Change Data

Network Server

Create Reports Users NT

Unix

Print

Sup. Controlling

IT

Abbildung 4.4: Struktur von Berechtigungen (erweitert)

65

Sandini Bib 4 Authentifizierung/Autorisation

Ab einer bestimmten Tiefe im Berechtigungsbaum darf ein Berechtigter die Rechte für tiefer liegende Äste an andere Benutzer selbst weitervergeben, um ein dezentrales Berechtigungsmanagement, das die Administration weniger belastet und die Verantwortung erheblich verteilt und an diejenigen delegiert, die auch mit den einzelnen Rollen und deren Themen beschäftigt sind, zu schaffen. Viele Konzepte verbinden die Organisationsstruktur des Unternehmens mit der Berechtigungsstruktur und schaffen auf diese Weise einen linken und einen rechten Teilbaum, dessen Blätter und Knoten miteinander, eventuell mit bestimmten Bedingungen (wie Rechteweitervergabe gestattet oder nicht gestattet) verbunden sind. Ein solches Vorgehen kann in einem Directory-Server abgebildet werden. Nach modernen Standards wird ein solches Directory über LDAP angesprochen und ist in seinen Datenstrukturen sehr flexibel. Das bedeutet, an die einzelnen Berechtigungen und Benutzerobjekte können unterschiedlichste Daten angehängt werden, die ein einfacheres Arbeiten mit dem Directory ermöglichen und sehr viele Informationen in dem zentralen Directory einbringen.

4.3

WebFarm und Directories

Die Berechtigungsverwaltung von Webanwendungen über eine zentrale Datenbank mit Rechten erscheint sehr sinnvoll. Dabei sollte für jeden Hauptstandort eines WebFarm-Betriebszentrums eine Echtzeitkopie oder Replikation dieses Directory vorhanden sein. Wenn es ein verteiltes Konzept für die Pflege von Directories und Benutzerdatenbanken gibt, sollte in einem WebFarm-Betriebszentrum trotzdem eine Gesamtkopie (read only) vorhanden sein, um gegen eventuelle Backbone-Ausfälle im GAN eine gewisse Sicherheit zu bieten. Um die oben beschriebene Struktur von Rollen und deren resultierenden Berechtigungen abzubilden, wird eine Gruppenstruktur für die Rollen eingerichtet, in der dann die Benutzer selbst erfasst werden. Ebenfalls eine Gruppenstruktur wird für die Berechtigungen eingerichtet. Die Rollengruppen werden nun in verschiedenen Berechtigungsgruppen als Mitglieder aufgenommen, wodurch automatisch die Mitglieder der Rollengruppe die entsprechende Berechtigung erhalten. Eine Rollen-orientierte Trennung von Berechtigung und Benutzer sowie Berechtigung und Rolle ist somit gegeben, und der Verwaltungsaufwand für die Rollen- und Berechtigungsstruktur ist minimalisiert. Durch die flexible Erweiterbarkeit der Datenstrukturen in einem DirectoryServer, der mittels LDAP angesprochen wird, können von Webanwendungen eventuell zusätzlich geforderte Daten problemlos unabhängig von der Berechtigungsstruktur des Unternehmens abgelegt werden und die weitere Sign-on-Lösung in keinem Falle beeinflussen.

66

Sandini Bib WebFarm und Directories

4.3.1

WebFarm-Administrationsberechtigungsstruktur

Innerhalb der WebFarm zeichnet sich durch die klare Trennung der Infrastruktur und Serverkomponenten eine Rollenstruktur ab. Für jedes Thema der Basisinfrastruktur gibt es pro Lokation eine Rollengruppe, die genau diese Infrastrukturkomponenten verwalten darf. Bei weiteren Untergliederungen, wie z.B. Webservern, die eine Maschine, aber auch die Administration des HTTP-Servers selbst haben, wird der Baum weiter aufgeteilt. Dieser Baum lässt sich problemlos in fast jede Berechtigungsstruktur einbinden und mit Verbindungen in den Berechtigungsbaum des Unternehmens selbst bzw. arago als Outsourcing-Partner verbinden. Im Folgenden sollen die konkreten Berechtigungen in der Hard- und Software der WebFarm-Komponenten beschrieben werden. Die hier aufgeführten Berechtigungen und Rollen sind eine repräsentative Untermenge der WebFarm-Rollen. Weitere Rollen können aus den weiteren Infrastrukturkomponenten ggf. direkt abgeleitet werden (siehe Abbildung 4.5).

...

WebFarm Admin

WebFarm Location X1 Org Admin WebFarm Location X1 Admin WebFarm Proxy Admin WebFarm WebServer Admin WebFarm HTTP Server Admin WebFarm KM/ CMS Admin WebFarm DNS Admin WebFarm Security Admin WebFarm Firewall Admin WebFarm Intruder Detection Admin

Abbildung 4.5: Administrationsberechtigungsstruktur

67

Sandini Bib 4 Authentifizierung/Autorisation

WebFarm-Admin Der globale Superbenutzer in der WebFarm-Berechtigungsstruktur. Dieses Recht erhalten nur Mitglieder des zentralen Point of Administration. Generell wird dieses Recht nur auf Zeit vergeben, wenn in einem Punkt im globalen WebFarm-Verbund alle Rechte für den Betrieb der WebFarm zusammenlaufen, z.B. weil ein Nacht- oder Feiertagsdienst erbracht wird. Alle weiter unten aufgeführten Rechte sind in dieser Rolle vereint. Zusätzlich kommen noch organisatorische Rechte für die Beantragung globaler Infrastruktur hinzu, die normalerweise von den Lokation-Administratoren gemeinsam erarbeitet werden müssen. WebFarm-Lokation-Org-Admin Diese Rolle ist absichtlich getrennt von allen technischen Rollen, weil sie auf jeden Fall in den Händen des Unternehmens liegen muss. Hier werden alle organisatorischen Maßnahmen für den WebFarm-Betrieb, wie z.B. Beschaffung, Beantragung von Berechtigungen, Personalanforderungen, Zugangskontrollen, Lokationsverteilung usw., abgeklärt. Diese Berechtigung ist eher organisatorischer Natur, da sie aber Berechtigungen in organisatorischen SubSystemen voraussetzt, wird sie hier extra geführt. WebFarm-Lokation-Admin Der Superbenutzer für eine Lokation in der WebFarm-Konstruktion eines Unternehmens. Diese Rolle beinhaltet den Zugang auf alle Rechner, die zur Infrastruktur der WebFarm-gehören, inklusive aller Administrationsrechner. Zusätzlich ist auch der Zugriff auf alle in der WebFarm-betriebenen Rechner als Superbenutzer eingeschlossen. Weiterhin besteht Zugriff auf alle Administrationsserver der einzelnen Anwendungen, sofern diese technischer Natur sind und nicht fachliche Anwendungsinhalte betreffen. Zu allen fachlichen Administrationsoberflächen wird ein Testzugang in dieser Rolle eingeschlossen, damit eventuelle Fehlermeldungen und Fehlerreports nachverfolgt und gelöst werden können. WebFarm-Proxy-Admin In dieser Rolle werden alle administrativen Arbeiten um die Proxy-Infrastruktur und die Benutzerberechtigung auf den Proxys gemäß den Vorgaben der Organisationsadministration vorgenommen. Dies schließt Zugang zu allen Administrations- und Konfigurationsmechanismen der Proxy-Server sowie des PAC-File-Servers ein. Ein Superbenutzer-Zugriff ist nicht erforderlich, da die Installationen von neuer Software und dergleichen entweder unter den bestehenden Berechtigungen erfolgen (eigener Proxy-Benutzer) oder aber ohnehin von der technischen Lokationsadministration durchgeführt werden müssen.

68

Sandini Bib WebFarm und Directories

WebFarm-WebServer-Admin Diese Rolle beschreibt einen Benutzer, der die Rechte hat, einen Webserver inklusive aller statischen, automatischen und dynamischen Contents sowie aller seiner Anwendungen zu administrieren. Hierzu sind Berechtigungen auf den Benutzer, der den HTTP-Server betreibt, sowie die Benutzer, denen der Inhalt des Servers gehört, erforderlich. Zusätzlich ist ein Zugriff auf alle einen bestimmten Server betreffenden Knowledge-Management- und Content-Management-Komponenten in dieser Berechtigung eingeschlossen. Die definierten Unterberechtigung des WebFarm-HTTP-Server-Admin darf lediglich die Konfiguration des eigentlichen HTTP-Servers und seiner technischen Komponenten vornehmen. Die definierte Unterberechtigung des WebFarm-KM/CMS-Admin darf alle technischen Komponenten des KnowledgeManagement- und Content-Management-Systems für diesen einen Webserver administrieren. WebFarm-DNS-Admin Der WebFarm-DNS-Admin betreut die Datenstrukturen und die direkte Software des Nameservers einer bestimmten Lokation. Hierbei ist Zugriff auf den Datenspeicher und/oder die Datenbank notwendig, in der die Namendaten gehalten werden, sowie ein kompletter Zugriff auf die Administration der Software und deren Versionen. Eine Versionsänderung ist auf jeden Fall organisatorisch abzustellen, da sie Auswirkungen auf andere Lokationen haben wird. WebFarm-Security-Admin Der WebFarm-Security-Admin darf alle Sicherheits-komponenten, inklusive Superbenutzer-Berechtigung, auf den entsprechenden Maschinen technisch betreuen. Das bedeutet direkten Zugriff auf die Rechner, Zugriff auf alle Konfigurations- und Managementwerkzeuge sowie die eigentlichen Konfigurationen von Firewall- und Intrusion-Detection-Komponenten und anderen Elementen der Sicherheitskonstruktion und uneingeschränkten Zugriff auf entsprechende Logfiles. Die definierte Unterberechtigung des WebFarm-Firewall-Admins hat die gleichen Berechtigungen wie der Security-Admin, nur nicht auf Intrusion-Detection-Systeme und deren Logauswertungen. Zusätzlich wird eine Read-OnlyUnterberechtigung zur WebFarm-Firewall-Read-Only, damit eine Einsicht in die Konfiguration für Prüfer und dergleichen möglich wird, ohne dass die Firewall und deren Integrität gefährdet werden. Die definierte Unterberechtigung des WebFarm-Intrusion-Detection-Admins ermöglicht es dem Rolleninhaber, Zugriff auf alle Konfigurationen und Auswertungen sowie Logfiles der Intrusion-Detection-Konfiguration, nicht aber Superbenutzer-Rechte auf den entsprechenden Maschinen zu erlangen.

69

Sandini Bib 4 Authentifizierung/Autorisation

4.3.2

WebFarm-Directory

In jeder Betriebszentrale des DocMe-Systems befindet sich ein Directory-Server mit Back-up, der die im Unternehmen verwaltete Berechtigungsstruktur widerspiegelt. Es ist möglich auf andere Directory-Strukturen zuzugreifen, so lange diese über das beschriebene Gruppenkonzept in der beschriebenen Baumstruktur aufgeteilt sind und über LDAP angesprochen werden können. Ein direkter Schreibzugriff auf die Stammdaten des Directory (Benutzerstammdaten) ist von der WebFarm-Infrastruktur aus nicht notwendig. Es ist sinnvoll, das Directory so auszulegen, dass entsprechende Zusatzinformationen für z.B. bestimmte Webanwendungen oder Content-ManagementSysteme nach vorheriger Absprache mit der Administration des DirectoryService beschrieben werden können.

4.3.3

Webanwendungen und Berechtigungen

Alle Webanwendungen und Applikationen im Umfeld des Web bzw. alle Anwendungen und Services, die in der WebFarm-betrieben werden, greifen zur primären Benutzerberechtigung auf das WebFarm-Directory zu. Das bedeutet, dass die verwendete Software (HTTP-Server, Proxy-Server, …) als Berechtigungsabfrage keine lokale Datenbank, sondern auf jeden Fall LDAP zum Zugriff auf das Directory verwendet und auch für alle Teile der Anwendung die Primärberechtigung über den Zugriff auf den LDAP-Server realisiert wird. Wichtig ist, dass in den Webanwendungen nicht einzelne Benutzer, sondern Gruppen bzw. Knoten und Blätter im Gruppenast des Directory berechtigt werden, damit das Prinzip der rollen-orientierten Berechtigung gewährleistet ist. Alle Berechtigungsverfahren einzelner Services und Anwendungen (Basic, ACL, …) werden auf den LDAP-Server umgeleitet, um diesen, wie bereits betont, zur einzigen Quelle für Primärberechtigungen zu etablieren. Dieser Dienst darf gemäß des WebFarm-Standards auf keinen Fall umgangen werden. Wenn eine Anwendung eine Sekundärberechtigung z.B. durch ein Formular mit Benutzerabfrage benötigt, was in manchen Anwendungen zwingend erforderlich oder sicherheitstechnisch sinnvoll ist, sollte die Möglichkeit der Verwendung des LDAP-Servers mit Vorzug betrachtet werden. Fast alle benötigten Zusatzdaten können in den Gruppen oder Personenstrukturen des Directory zusätzlich abgelegt werden, für solche Fälle wird also keine gesonderte Lösung benötigt. Wenn eine gesonderte Lösung für eine Sekundärberechtigung verwendet wird, muss bzw. sollte diese auf der lokalen Maschine der Anwendung angesiedelt sein. Grundsätzlich ist die Bedingung für die Speicherung von Berech-

70

Sandini Bib Authentifizierung

tigungsdaten, dass die eigentlichen Sicherheitsdaten (Passwort, TAN, …) auf keinen Fall im Klartext gespeichert werden dürfen, sondern immer verschlüsselt abgelegt sein müssen. Bei der Auswahl von Anwendungen und beim Design neuer Anwendungen sollte auf jeden Fall auf die Unterstützung von LDAP als Berechtigungsprotokoll geachtet werden.

4.4

Authentifizierung

Benutzerstammdaten und deren dazugehörige Berechtigungen in einer einheitlichen Single-Sign-On-fähigen Struktur aufzubewahren, ist Grundlage für ein modernes Berechtigungssystem. Die Art und Weise, wie ein Benutzer tatsächlich identifiziert ist und damit seine Anrecht auf die seinen Stammdaten zugehörigen Berechtigungen nachweist, ist entscheidend für den Sicherheitsstandard in einem Unternehmen. Es gibt die unterschiedlichsten Verfahren, um einen solchen Identifikationsnachweis zu führen, die alle mehr oder weniger einsatzbereit und einsetzbar sind. Im Folgenden werden einige Verfahren betrachtet, die im Rahmen einer WebFarm-eingesetzt werden können bzw. weit verbreitet sind.

4.4.1

Passwörter

Die Identifikation mit Benutzernamen und Passwort ist absoluter Standard heutzutage und sicherlich auch für viele Webanwendungen absolut ausreichend. Bekannt ist die Problematik des Diebstahls oder der Weitergabe von Passwörtern mit Benutzerkennungen. Es ist aus diesem Grund unbedingt erforderlich, dass eine dem WebFarm-Dokument »Zugangsverantwortlichkeit« entsprechende Vereinbarung mit den Mitarbeitern, die eine solche Zugangskontrolllösung verwenden, getroffen wird. In diesem Dokument wird der Benutzer als Verantwortlicher für seinen Rechnerzugang festgelegt, der die Beweispflicht bei Missbrauch auf den Benutzer verlagert, da er die vollständige Verantwortung für seinen Zugang trägt. Dies setzt voraus, dass Passwörter nicht im Klartext gespeichert werden dürfen, da ansonsten die juristische Situation ungeklärt ist. Es ist auf eine verschlüsselte Übertragung der Benutzerkennung und des Passworts ab einem bestimmten Sicherheitslevel zu achten.

4.4.2

PIN-TAN (nicht empfohlen)

Weit verbreitet sind so genannte PIN-TAN-Verfahren, bei denen sich ein Benutzer über eine Benutzerkennung und eine so genannte PIN (Persönliche Identifikation) oder ein Passwort identifiziert und jede Interaktion mit dem

71

Sandini Bib 4 Authentifizierung/Autorisation

System durch eine TAN (Transaktionskennung) validiert wird. Das Problem hierbei ist, dass Passworteingaben sehr häufig notwendig sind und somit die Gefahr besteht, dass diese leicht abgeschaut werden können. Zusätzlich gestalten sich die TANs oder einmal benutzte Passwörter meist so komplex, dass sie ausgedruckt und mitgeführt werden müssen, was offensichtlich keinen Sicherheitsgewinn, sondern eher eine Verschlechterung des Sicherheitsstandards nach sich zieht. In WebFarm-konformen Anwendungen sollten also keine PIN-TAN-Verfahren eingesetzt werden.

4.4.3

Zertifikate

Die momentan modernste Art der Benutzeridentifikation. Es wird ein Schlüssel für einen Benutzer erzeugt, der mittels eines vom Benutzer selbst definierten Passworts geschützt werden kann. Dieser Schlüssel besitzt einen öffentlichen Teil, der mathematisch an den geheimen Teil des Schlüssels gekoppelt ist. Es findet die Zertifizierung des öffentlichen Schlüssels statt, d.h., die Authentizität des Schlüssels wird von einer vertrauenswürdigen Partei oder Einrichtung bestätigt und elektronisch hinterlegt. Über diesen Schlüssel kann sich nun ein Benutzer bei einem System identifizieren. Es ist gleichzeitig validiert, dass es sich um einen korrekten Schlüssel (Benutzerpasswort) handelt und dass es tatsächlich der Benutzer ist, für den er sich ausgibt (Zertifizierung). Es erscheint sinnvoll, möglichst viele Anwendungen mit dieser Zertifizierungstechnik auszustatten. Man kann hierzu in einem Unternehmen eine so genannte PKI (Public Key Infrastructure) aufbauen, die für die Vergabe von Schlüsseln, deren Verwaltung (Rechte) und deren Zertifizierung Sorge trägt.

4.4.4

Smartcards, Chipkarten und Buttons

Diese Verfahren setzten ein zusätzliches Stück Hardware beim Benutzer voraus, das die Identität des Benutzers hält und eventuell noch zusätzliche Verschlüsselungsoperationen durchführen kann. Sicherlich sind mit der Einführung eines solchen Systems erhebliche Kosten verbunden. Wünschenswert sind für das System, dass die Schlüssel des Benutzers nur im Authentifizierung-Medium vorhanden sind und lediglich ein API zu diesem Medium besteht, was z.B. im Falle der i-Buttons realisiert ist. Diese Lösungen sind sehr sinnvoll und bedeuten mit Sicherheit einen sehr guten Sicherheitslevel, es ist aber zu berücksichtigen, dass sie Eingriffe in die Benutzerumgebung erfordern und auch sehr kostenintensiv sein können.

4.4.5

Biometrische Verfahren

Hierbei handelt es sich um Verfahren, bei denen Körpermerkmale (Fingerabdruck, Stimme, Iris-Scan, …) als Identifikation einer Person verwendet werden. Hier wird eine reine Identifikation vorgenommen, im Gegensatz zu Zer72

Sandini Bib Accounting und Billing-Infrastruktur

tifikaten oder Button-Lösungen ist keine zusätzliche Verschlüsselungslogik direkt in der Identifikation eingebaut. Sicherlich handelt es sich um die eindeutigsten Identifikationsverfahren, die für die Identifikation den an sich besten Sicherheitsstandard gewährleisten. Allerdings sind die Verfahren für eine flächendeckende Einführung bei Anwendern von Webanwendungen doch wesentlich zu teuer und dem Standard nicht entsprechend. Bei Zugangskontrollen zu Rechnerräumen oder auch eventuell einzelner besonders geschützter Konsolen sind solche Verfahren sehr gut einsetzbar.

4.5

Accounting und Billing-Infrastruktur

Die statistische Auswertung von Webanwendungen und anderen Diensten, die im Zusammenhang oder Zusammenspiel mit den neuen Medien stehen, ist oft ein wichtiger Bestandteil der Marktforschung und Bewertung von entsprechenden Projekten. Neben diesen Image-Faktoren spielt die Betrachtung des Zugriffsverhaltens der Benutzer, des Lastverhaltens der Hard- und Software und des Transferverhaltens der Anwendung für die Planung der technischen Infrastruktur, aber auch für die Kostenweitergabe und korrekte Abrechnung einzelner Anwendungen und Benutzer eine wesentliche Rolle. Die Daten zur Last-, Transfer- und Benutzerauswertung fallen direkt auf den Anwendungsmaschinen an, es müssen also nicht zusätzliche Datenerfassungspunkte geschaffen werden. Das WebFarm-Konzept sieht eine Reihe von vorgefertigten Statistiken und Auswertungen sowie eine Schnittstelle zur Datenlieferung von Accountingund Billing-Daten an entsprechende andere Anwendungen vor.

4.6

Daten

Die Grundfragen sind selbstverständlich, welche Daten werden überhaupt mit dem WebFarm-Standard erfasst, und wie können diese dann ausgewertet werden? Gewöhnlich existieren in einem Unternehmen Vorschriften der Revision für die Behandlung von Journal- und Protokolldateien, wie diese ja in allen Facetten im Rahmen des Betriebs von Webanwendungen, Firewalls, Proxy-Servern usw. anfallen. Diese Vorschriften müssen ohnehin eingehalten werden, ermöglichen aber gleichzeitig eine entsprechende Auswertung dieser Dateien mit Standardwerkzeugen und individuellen Abfragen. Es werden folgende Logdaten für Auswertungen gesammelt: 왘 HTTP/HTTPS-Server-Logs (Extended Format) 왘 Proxy-Server-Logs

73

Sandini Bib 4 Authentifizierung/Autorisation

왘 Application-Level-Gateway-Logs 왘 WatchMe-Logs (DB) (siehe Systembetrieb)

Weiterhin werden Daten gesammelt, die allerdings nur zu Archivzwecken und nicht zur direkten Auswertung verwendet werden: 왘 Packetfilter-Logs 왘 Intrusion-Detection-Logs 왘 Login- und SU-Logs

Zusätzlich zu diesen über Protokolldateien anfallenden Daten werden Daten über das System vom Überwachungssystem und Monitorwerkzeugen gesammelt und zur Auswertung bereitgestellt. Diese Daten umfassen: 왘 Plattenkapazität 왘 Prozessorlast 왘 Netzwerkverkehr 왘 nach Diensten 왘 nach Quellen 왘 nach Zielen Mit dieser Sammlung an Daten werden die Standardauswertungen auf den Monitoranwendungen der WebFarm-Betriebszentren erstellt, die für die Administratoren, Benutzer und Auftraggeber interessante Einsichten in das System liefern.

Zusätzlich werden die Daten, wie bereits erwähnt, auf Wunsch an ein internes oder externes Billing-System weitergeleitet, auf dem eine dienstbezogene Rechnungsstellung ermöglicht wird. In zukünftigen WebFarm-Standarddokumenten wird ein solches Billing-System direkter Bestandteil der WebFarm-werden.

4.7

Standardauswertungen

Wie bereits erwähnt, werden im WebFarm-Standard einige Auswertungen standardisiert für alle betriebenen Komponenten erzeugt. Diese Auswertungen sind, falls nicht explizit anders gewünscht, automatisch für den Auftraggeber und den technischen Ansprechpartner der Anwendung verfügbar. Die WebFarm-Administration verwendet diese Auswertungen unter anderem, um die Entwicklung des Anwendungsverhaltens zu beobachten und rechtzeitig Auslastungen und Überlastungen vorhersagen zu können bzw. sofort die entsprechenden Maßnahmen ergreifen zu können.

74

Sandini Bib Standardauswertungen

4.7.1

Server

Standardserver Für einen Standardserver werden unterschiedliche Statistiken ermittelt. Diese beinhalten die Systemlast, die eingehenden und ausgehenden Netzwerkdaten sowie Platten und Speicherstatistiken. Die Daten werden alle zwanzig, für einen normalen Rechner maximal alle zwanzig Minuten erstellt. Es existieren Grafiken und Auswertungen über folgende Zeitspannen: 왘 Die letzten 24 Stunden 왘 24-Stunden-Durchschnitt 왘 Wochendurchschnitt 왘 Monatsdurchschnitt

Abbildung 4.6: Statistik Systemlast

Neben diesen reinen Auswertungen der Netzlast ist auch die Betrachtung des allgemeinen Maschinenstatus sehr wichtig. Hierbei ist eine kurzfristige historische Betrachtung aber vor allem des aktuellen Status interessant.

75

Sandini Bib 4 Authentifizierung/Autorisation

Weiterhin wird für jede Maschine eine Verfügbarkeitsrechnung dargestellt, die dem Auftraggeber die komplette Verfügbarkeit der Maschine sowie unterschiedliche Alarmstufen von Warnungen bis hin zum Systemausfall darstellt, damit ein allgemeiner Betriebseinblick vermittelt werden kann. Firewall-Komponenten Für eine Firewall-Komponente werden zunächst alle Auswertungen erzeugt, die auch für einen normalen Server vorhanden sind. Es werden in der Betrachtung des Netzwerkverkehrs kleinere Zeitabstände betrachtet. Es stehen auch Einzelauswertungen für die verschiedenen betrachteten Hauptprotokolle bzw. Dienste zur Verfügung. Hierbei werden die Netzwerkcharts skaliert nach verwendeter Bandbreite und relativ zur verfügbaren Bandbreite dargestellt.

Abbildung 4.7: Auswertungen für Firewall 왘 All Traffic

Hier wird einfach das Volumen des gesamten Netzverkehrs auf einem Interface der Firewall-Komponente dargestellt. 왘 Outgoing-E-Mail

Hier wird das Lastverhalten bei ausgehender E-Mail betrachtet, sprich der dazugehörende aus- und durch das Protokoll eingehende Verkehr. 76

Sandini Bib Standardauswertungen

왘 Incoming-E-Mail

Entsprechend der ausgehenden E-Mail reflektiert diese Statistik die eingehende E-Mail. 왘 Webserver

In dieser Statistik werden alle in der WebFarm über die Firewall-Komponente betriebenen Webserver dargestellt und wie viel Traffic welcher dieser Server eingehend und ausgehend erzeugt bzw. benötigt. 왘 Websurfing

Analog des von den Webservern in der WebFarm-Lokation verursachten Traffic wird hier der Traffic der Proxy-Server, sprich das eigentliche »Surfen«, aus dem internen Netz analysiert.

Abbildung 4.8: Analyse des Proxy-Traffic 왘 Combined-View

Die Combined-View zeigt relativ zum gesamten Traffic oder absolut zur verfügbaren Bandbreite die einzelnen untersuchten Werte. Zusätzlich werden alle Werte in einer Mitteldarstellung verfügbar gemacht, die nicht nur die durchschnittliche Betrachtung, wie bisher dargestellt, sondern auch die Höchst- und Tiefstwerte darstellt. Zur Darstellung dieser

77

Sandini Bib 4 Authentifizierung/Autorisation

Ansicht werden auch die Höchst- und Tiefstwerte über die Zeit gemittelt, um Ausreißer unter Kontrolle zu bringen, da ansonsten ein einmaliger 0-Wert die gesamte Darstellung ad absurdum führen würde. Diese Darstellung dient zur Gesamtlastbetrachtung, denn die Durchschnittswerte an sich geben einen guten Überblick über das Benutzerverhalten, es ist jedoch davon auszugehen, dass das Peak-Verhalten an sich als Maßstab der Kunden oder internen Benutzer für einen angebotenen Service herangezogen wird, und dieses Peak-Verhalten wird genau in einer solchen Darstellung gut veranschaulicht und kann zur Planung weiterer Netzwerkkomponenten, Strukturen, Server usw. herangezogen werden. Zusätzlich zu diesen Standardauswertungen wird bei Firewall-Komponenten auch Aktivitäten zu erhalten und eventuelle das Angriffsverhalten aus den Logfiles (Angriffszeitpunkt, Angriffsart, Angriffshäufigkeit) visualisiert, um einen Überblick über externe Gefahrenherde sofort zu identifizieren.

4.7.2

Anwendungen

Einzelne Anwendungen werden selbstverständlich auch ausgewertet. Die Daten werden für die Überwachung der Anwendung in der WebFarm-Administration ohnehin gewonnen und können sogleich zu einer Einsicht für den Auftraggeber der Verwendung des Dienstes bzw. dem Erfolg, der Auslastung und der Funktionalität darstellen. Diese Auswertungen werden oft für die Beurteilung einer Anwendung, für die Einschätzung von Weiterentwicklungen, zur Hardwareplanung und zum Marketing verwendet. Da die Daten sowieso gesammelt werden, ist eine Darstellung problemlos realisierbar und kann als Dienstleistung für Auftraggeber innerhalb der WebFarm-Konstruktion dargestellt werden. HTTP-Anwendungen Generell ist es schwierig, Webserver korrekt auszuwerten, es existieren mehrere Verfahren zur Zählung von Zugriffen. Das eindeutigste Verfahren ist immer noch das Auswerten von Loginformationen, wenn alle Informationen, die ein HTTP-Server erfassen kann, von diesem auch abgespeichert werden. Solche Auswertungen sollten auf jeden Fall über den gesamten Zeitraum der Existenz einer Anwendung oder für mindestens ein Jahr, zusätzlich monatlich und bei stark frequentierten Anwendungen sogar auf täglicher Basis erstellt werden. In einer WebFarm-Lokation gibt es hierfür einen Auswertungsrechner, der die Datenübertragungen der Logdateien erhält und die entsprechenden Auswertungen erstellt. In einer Extranet-Anwendung werden diese dann den berechtigten Benutzern zur Verfügung gestellt.

78

Sandini Bib Standardauswertungen

Abbildung 4.9: Webserver-Statistik

Je nach verwendeter Methode der Auswertung wird angezeigt, wie viele Zugriffe auf eine spezifische Seite erfolgt sind, wie viele Benutzer sich bestimmte Dateien angesehen und ausgewertet haben, und welche Resultate dies hervorgebracht hat. Wichtig bei der Auswertung von HTTP-Servern ist, neben den technischen Daten über Fehler und Bandbreite auch die Anwendungsdaten zu beachten. Für eine stetige Nutzung der Anwendung sprechen hier weniger die »Hits« auf einzelne Seiten, also die Anzahl der konkreten Einzelabrufe, sondern eher die so genannten »User Sessions« oder »Benutzer Sitzungen« – also Einheiten in der Logauswertung, in denen ein Benutzer mehrere Seiten innerhalb eines bestimmten Zeitraums aufgerufen hat, die miteinander verbunden sind. Proxy-Server Ähnliche Auswertungen werden für einen Proxy-Server erstellt, wobei hier weniger Werte betrachtet werden, weil die Datenflut, die von einem ausgelasteten Proxy erzeugt wird, ca. 500 MB pro Tag bedeutet, deren Auswertung weit über die normalerweise freie Kapazität von Auswertungsrechnern hinausgeht und keine nennenswerten zusätzlichen Informationen bietet.

79

Sandini Bib 4 Authentifizierung/Autorisation

Generell werden die folgenden Werte berechnet: 왘 Eingehender und ausgehender Verkehr für die umzusetzenden Protokolle 왘 Verhältnis von Cache- zu Non-Cache-Zugriffen und daraus resultierende

Traffic-Ersparnis 왘 Top 10 der Benutzer (Personen und Proxy getrennt) 왘 Top 10 der Zugriffsziele

4.8

Billing

Oft ist es auch interessant, die Kosten für Leitungs- und Rechenzeit direkt an Kostenstellen weiterzuberechnen. Hier bietet sich ein weites Feld an, das innerhalb eines Entwicklungs- und Betriebsstandards wie dem WebFarmStandard nicht abgedeckt werden kann. Grundsätzlich stehen alle Daten mit Quell- und Zieladresse zur Verfügung, so dass eine Auswertung der Daten auch auf Protokollebene möglich wird. Ein Anschluss an entsprechende Verrechnungswerkzeuge ist problemlos möglich. Es kann, wenn eine Quell/Benutzer-Tabelle vorliegt, eine Auswertung der Benutzer erstellt werden, die dann einer Berechnung zugrunde gelegt werden kann. Es ist für diese Auswertungen zu beachten, dass sie absolut personenbezogene Daten enthalten und dementsprechend unter das Datenschutzgesetz und das Gesetz zur betrieblichen Mitbestimmung fallen.

4.9

Content-Management-Übersicht

Content-Management entwickelt sich zu einem zentralen Thema bei allen Webanwendungen, da nicht nur die Interaktivität auf einer einheitlichen Plattform, sondern auch die Möglichkeiten der Darstellung und Verwaltung von Informationen und Anwendungen den Charme des World Wide Web ausmachen. Content-Management wird zu vielen Gelegenheiten als Schlagwort aufgeworfen und in jedem Zusammenhang anders verwendet. Der WebFarm-Standard betrachtet alle Elemente, die ein Webserver beinhalten kann, also HTML-Seiten, Dateien, CGI-Anwendungen, Application-Server-Anwendungen, JAVA-Classes usw. als Content. Nachfolgend wird ein kurzer Überblick über die Unterteilung der verschiedenen Content-Typen gegeben, die dann mit einzelnen Infrastrukturmaßnahmen über eine Lösung im WebFarm-Standard zur Anlieferung, Versionierung abgedeckt werden – eben Content-Management.

80

Sandini Bib Verteilung und Redaktion

4.10 Verteilung und Redaktion Die Verteilung von Content auf Anwendungen und die Redaktion muss gewährleistet werden, sprich die ordnungsgemäße Freigabe von Content, wenn diese erforderlich ist. Wird eine größere Anzahl von Webanwendungen betrieben, ist es nicht denkbar, jede dieser Anwendungen mit einem eigenen Verfahren zum Einspielen von Content zu versehen. Der WebFarm-Standard sieht hier über die Infrastruktur den Service der Redaktionssysteme und des Content-Pools vor. Mit diesen Werkzeugen können alle Arten von Informationen, Programmen und Dateien angeliefert und verteilt werden. Es wird zwischen statischem Content, dynamischem Content und semi-dynamischem Content unterschieden. Dabei ist unter statischem Content alles zu verstehen, was statisch für einen einzigen Server produziert wird, wie z.B. alle Programme für die Webanwendung, statisches HTML für die Navigation usw. Unter dynamischem Content ist alles zu verstehen, was die Webanwendung selbst an Content durch Programmaufrufe und Datenbankabfragen zur Anzeige beim Benutzer bringt (was über das Redaktionskonzept bereits für den statischen Content eingeschlossen ist). Semi-dynamischer Content sind alle tatsächlichen Informationen, die in eine Webanwendung einfließen, also Texte, Tabellen, Grafiken usw. Dieser semi-dynamische Content wird über einen Pool verteilt, der in sich ein objektorientiertes Modell zur Organisation der Informationen verwendet. Diese Pool-Strategie hat den Vorteil, dass einmal eingegangene Informationen auf vielen Webanwendungen gleichzeitig und nicht wie bei statischem Content nur allein auf einer Anwendung verwendet werden können, wobei die Informationen dann natürlich dem Layout und der Struktur der jeweiligen Anwendung entsprechen müssen. Durch diese Strategie, die durch den WebFarm-Standard vorgegeben wird, ist eine Informationswiederverwendung möglich, was einen enormen Effizienzund Ressourcengewinn darstellt und die Prozesse in einem Unternehmen sowie die Kundenbindung stark verbessern kann.

81

Sandini Bib 4 Authentifizierung/Autorisation

4.11 Style-Guides und Checking Datenstrom für dynamischen Content

Datenstrom für semidynamischen Content

WebFarm Admin Server

WebFarm Admin Server

Client

Client

LAN

Web Server

Web Server

LAN

Web Server

Web Server

Web Server

Web Server

Abbildung 4.10: Data-Flow

Ebenfalls durch den Mechanismus des Content-Managements wird die Umsetzung von Style-Guides eingeführt. Bei statischen Inhalten werden einfache Konventionen in der Namensgebung und im Code der übertragenen Dateien überprüft. Bei Anbindung einer Webanwendung an den ContentPool wird für diese Webanwendung die gelieferte Information im Styling und im Verhalten den Vorgaben der Anwendung angepasst.

82

Sandini Bib

5

Content-Management und Content-Pool

Im WebFarm-Standard wird eine Verfahrensweise definiert, um das im Unternehmen entstehende Wissen bzw. die im Unternehmen vorhandenen Informationen für Webanwendungen, die innerhalb einer WebFarm-Lokation betrieben werden, bereitzustellen. Es wird ein Wissensmanagement für die Informationsebene geschaffen, das aber über die reinen Funktionen des Wissens-Retrieval hinausgeht. Es wird darum von Information-Modelling gesprochen, da Informationen anhand eines Modells im Content-Pool hinterlegt werden, und in weit führenden Ebenen des Modells in einzelne Applikationen, deren Layout und deren Struktur eingebracht werden. Durch die in der WebFarm vorhandenen Infrastruktur können Anwendungen den geschaffenen Informationspool zur Erzeugung und Verwaltung ihres Content beliebig anzapfen und den Content aus dem Pool einbinden. Ein Management des Content in allen an diese Infrastruktur angeschlossenen Systemen wird durch Infrastrukturkomponenten, das Content-ManagementSystem, erreicht. Information model

Abbildung 5.1: Information-Model

83

Sandini Bib 5 Content-Management und Content-Pool

5.1

Information-Modelling

5.1.1

Was ist Information-Modelling?

Informationen werden in der heutigen von Auskünften und Nachrichten geprägten Gesellschaft immer mehr als ein wertvolles denn als ein notwendiges Gut angesehen. Das gilt nicht nur für die schon immer gut gehüteten und auch entsprechend behandelten Geschäftsgeheimnisse, sondern auch für Informationen des täglichen Bedarfs. In verschiedenen Projekten zur Workflow-Dokumentation oder des Workflow-Modelling bzw. des Business-Process-Reengineering werden Informationen auch immer nur zweitrangig behandelt, obwohl sie eigentlich zentraler Bestandteil des kompletten Arbeitsprozesses sind. Information-Modelling ist ein Ansatz zur Erfassung aller vorhandenen und benötigten Informationen sowie zur Dokumentation der benötigten ServiceLevel und Darstellungsarten für jeden vorhandenen Informationstyp. Dabei wird auf größere oder kleinere Entitäten innerhalb eines Unternehmens ein Modell erstellt, dem folgende Frage zugrunde liegt: Wer produziert welche Informationen, und wer will diese dann wann, wo und wie sehen? Zusätzlich kann selbstverständlich noch die Frage aufgeworfen werden, welche zusätzlichen Informationen noch produziert werden müssen. Gewöhnlich ist aber festzustellen, dass bereits viele Informationen, die benötigt werden, an anderen Stellen oder sogar redundant produziert werden. Dabei ist es wichtig, die Informationen von ihrer tatsächlichen Darstellung zu trennen. Ein solches Model stellt nicht nur die existierenden Informationen bzw. den Informationsbedarf dar, sondern auch die Informationsflüsse innerhalb einer Abteilung, eines Unternehmens, von und zu Partnern und von und zu Kunden dar. Auf der Basis eines solchen Modells können Geschäftsprozesse leicht abgebildet, eine redundante Produktion von Informationen vermieden und eine gute Verteilung der vorhandenen Informationen anhand des tatsächlichen Informationsverhaltens vorgenommen werden. Die daraus folgende Effizienzsteigerung sowie die verbesserte Transparenz der Unternehmensstruktur sind unübersehbar.

84

Sandini Bib Information-Modelling

5.1.2

Der Informationsbegriff

Informationen können die unterschiedlichsten Objekte darstellen und auch wieder beinhalten. Im Gegensatz zum Dokumentenmanagement können im Information-Modelling alle Facetten des Informationsbegriffs abgedeckt werden. Formate und Meta-Informationen sind von der Modellierung von Informationstypen, Informationserstellern oder Autoren sowie Informationsverbrauchern und allen dazu verwendeten technischen Hilfsmitteln wie Netzwerken und Servern völlig unabhängig. Formate werden erst thematisiert, wenn es um die Darstellungsart der Informationen geht, die nur einen geringen Teil eines ganzen Informationsmodells ausmacht.

5.1.3

Informationstypisierung

Stratege

Konzept

Agenturen

Framework

Layout, Navigation Struktur standardisiertes Layout

Pre-Production Server

verantwortlicher Redakteur

Freigabe

Production Server

Abbildung 5.2: Informationstypisierung

85

Sandini Bib 5 Content-Management und Content-Pool

Änderungsfrequenz Die Änderungsfrequenz von Informationen wirkt sich nicht unbedingt sofort auf das Informationsmodell selbst aus, hat aber gravierende Auswirkungen auf die Verwendbarkeit von Informationen und auf das technische Handling von Informationen. Deshalb wird die Änderungsfrequenz hier als ein Kriterium der Informationstypisierung vorgestellt. Statische Informationen Statische Informationen werden exakt einmal erstellt und haben dann für ihre gesamte, gewöhnlich recht lange Lebenszeit volle Gültigkeit. Statische Informationen sind daher keine aktuellen Informationen und werden im Allgemeinen auf dynamische Prozesse innerhalb eines Unternehmens wenig Einfluss haben: Sie können aber sehr wohl die Grundlage für solche Prozesse bilden, wenn es sich bei den Informationen z.B. um Verfahrensvorschriften handelt. Dynamische Informationen Dynamische Informationen sind eigentlich das exakte Gegenteil zu statischen Informationen. Dynamische Informationen haben ein sehr beschränktes Bedeutungsfeld und eine sehr kurze Lebensdauer, sie werden jedoch ständig durch aktuellere Informationen gleicher Bedeutung ersetzt: Auf diese Weise stellt eine Reihe von dynamischen Informationen wieder eine statische oder semi-dynamische Information dar (siehe Abbildung 5.3). Semi-dynamische Informationen Semi-dynamische Informationen haben eine lange Gültigkeit und werden im Gegensatz zu rein dynamischen Informationen nur selten komplett automatisch produziert. Dennoch werden von jenem semi-dynamischen Typ Informationen in gewissen Intervallen übermittelt, welche die bestehenden Informationen, ähnlich wie beim dynamischen Modell, ersetzen oder diese erweitern. Der weitaus größte Teil der in einem Unternehmen produzierten Informationen fällt in diese Kategorie, da die Informationen immer wieder den gleichen definierten Typ haben und trotzdem entweder einen Ersatz oder eine Erweiterung des bereits bestehenden Informationsbestandes darstellen.

86

Sandini Bib Information-Modelling

User/ Client AbfrageIndividual Entwicklung (App-Server)

LokalerData Storage

Zentrale (Meta) Datenbank

Abbildung 5.3: Übersicht dynamische Informationsabfrage

Klassifizierung Die eigentliche Typisierung von produzierten Informationen wird aber nicht durch die Änderungsfrequenz, sondern durch die Klassifizierung von Informationen vorgenommen. Dabei werden alle vorhandenen Informationen einem bestimmten Typ zugewiesen. Dieser Typ ist aus den Prozessen des Unternehmens gegriffen, so kann es z.B. Informationen vom Typ Pressemitteilungen oder Marktberichte geben. Da grundsätzlich eine riesige Informationsflut besteht, ist bei einem einfachen Brainstorming von Informationstypen schnell die Übersicht verloren. Es bietet sich eine hierarchische Organisation der Informationen an, bei der man Informationen mit gleichen Eigenschaften oder Grundvoraussetzungen gruppiert. Diese Hierarchisierung muss nicht auf einer Ebene stattfinden, d.h., auch die Gruppen können nochmals und nochmals gruppiert werden. Auf diese Weise entsteht ein Baum von vorhandenen Informationen mit aggregierten und abstrahierten Gruppen. Die Endpunkte des Baumes, die Blätter, sind tatsächlich produzierte Informationen.

87

Sandini Bib 5 Content-Management und Content-Pool

Da die Informationen Aufgrund gleicher Eigenschaften der Grundvoraussetzungen gruppiert wurden, bietet sich eine Objektorientierung der Informationshierarchie an. Das bedeutet, die Abstraktionsebenen erhalten alle Eigenschaften, die in der gesamten Gruppe vorhanden sind. Die einzelnen Informationen oder Subgruppen innerhalb einer solchen Ebenenklasse werden davon abgeleitet und können die mitgelieferten Attribute ohne weiteren Aufwand übernehmen (erben) oder diese wieder verändern. Dabei ist eine Kapselung von Eigenschaften vorgesehen, da jeweils nur ein Informationsobjekt seine konkreten Zusatzinformationen modifizieren oder erweitern kann. Die Idee der Polymorphie aus der Objektorientierung wird hier noch nicht benötigt, taucht aber bei den verschiedenen Darstellungen einer Information wieder auf, da es sich um unterschiedliche Repräsentationen der immer gleichen Information handelt. Es entsteht so zunächst ein Informationsbaum, der die vorhandenen Informationen gruppiert und alle innerhalb der Gruppen einheitlichen Eigenschaften in die Gruppenabstraktionsebene einmal für die gesamte Gruppe verlagert. So könnte es unter der Gruppe Pressemitteilungen verschiedene Operationsbereiche geben wie z.B. USA, Europa. Alle Informationen sind grundsätzlich Pressemitteilungen und haben die gleichen Attribute, unterscheiden sich aber von der Lokation und dementsprechend auch von der Einzelbehandlung der Information. Meta-Informationen Ein Informationsmodell hat theoretischen und praktischen Wert. Der theoretische Wert eines Informationsmodells liegt darin, dass Informationsersteller und Konsumenten eindeutig identifiziert sind, genau wie die tatsächlich produzierten Informationen. Daraus können bereits vorhandene Informationen an weitere Konsumenten abgegeben werden und die Erstellung neuer Informationen effizient geplant werden. Der praktische Wert eines Informationsmodells ergibt sich dann, wenn anhand des Modells die Informationen erfasst, weiter verteilt und umformatiert und eventuell auf andere Weise behandelt werden können. Ein solcher Automatismus bildet die Informationsflüsse innerhalb eines Unternehmens sofort praktisch aus. Damit eine korrekte Planung aber auch mit einer korrekten praktischen Behandlung von Informationen vorgenommen werden kann, muss die eigentliche Information mit Zusatzinformationen, den so genannten MetaInformationen, versehen werden. Zunächst muss auf jeden Fall der Informationstyp, sprich die Informationsklasse in den Meta-Informationen, vorhanden sein. Die Meta-Informationen können zusätzlich noch Daten über den Gültigkeitsbereich, die Informationsverteilung und Autorisation usw. enthalten.

88

Sandini Bib Information-Modelling

Der Grundvorteil bei existierenden Informationsmodellen ist, dass der eigentliche Informationsersteller, der die generierte Information am besten einschätzen und klassifizieren kann, eine gute Qualität der Informationen und der Informationsflüsse erzeugen kann. In herkömmlichen Verteilungsnetzen für Informationen werden Informationen oft erstellt und dann von Dritten eingestuft und verteilt. Da der Informationsfluss beeinträchtigt wird und die Geschwindigkeit und Aktualität der Informationen deutlich verschlechtert werden, kann dies eine zusätzliche Fehlerquelle bedeuten. Die einzige MetaInformation, die einer eigentlichen Information grundsätzlich angehängt werden muss, ist die Typisierung. Alle anderen Meta-Informationen erleichtern oder verbessern die Handhabung der Information und können von den Erstellern des Modells oder der Informationen unterschiedlich verändert und definiert werden. Als sinnvoll haben sich Meta-Informationen wie Titel, Subtitel, Author, Author Mail, Publishdate, Expiredate, Keywords usw. erwiesen. Autoren Informationen nehmen ihren Ursprung immer bei ein oder mehreren Autoren. Diese Autoren erzeugen Informationen auf explizite Anforderungen im Rahmen des Tagesgeschäfts oder zur Erleichterung ihrer eigenen Arbeit. Das größte Problem in der heutigen Informationslandschaft ist, dass nicht bekannt ist, welche Informationen überhaupt existieren. Der Informationsklassenbaum als Bestandteil eines Informationsmodells gibt darüber Auskunft. Die Tendenz geht immer mehr dorthin, dass fachlich qualifizierte und dementsprechend teure Autoren komplizierte Verfahren erlernen müssen, um ihre Informationen an die entsprechenden Konsumenten heranzutragen und diese in korrekten Formaten bereitzustellen. Information-Modelling setzt einen anderen Ansatz voraus. Der Autor produziert Informationen in einer ihm vertrauten und für ihn gut benutzbaren Umgebung. Das Informationsmodell definiert klar die Verteilung und alle damit verbunden Prozesse, die dann von entsprechend geschultem Personal oder automatisch durch ein Information-Modelling-Werkzeug durchgeführt wird. Fazit: Der Einsatz eines Informationsmodells in der Praxis hat zur Folge, dass sich ein Autor auf seine Kernkompetenz und nicht auf IT- und Informationsverteilung konzentriert und spezialisiert. Die Grundvoraussetzung dafür ist die Unterstützung der Autoren. Eine solche Unterstützung minimiert den zusätzlichen Aufwand für Autoren und verbessert somit die Produktivität. In einem effizienten Informationsmodell muss ein Autor aus seiner gewohnten Umgebung Informationen in ein System übergeben können und eine Information dabei mit einer benutzerfreund-

89

Sandini Bib 5 Content-Management und Content-Pool

lichen Oberfläche mit den erforderlichen Meta-Informationen versehen können. Das System kümmert sich um alles Weitere, der Autor konzentriert sich auf seine Kernkompetenz. Innerhalb des Informationsmodells können Autoren an den unterschiedlichsten Standorten Informationen der verschiedensten Klassen anliefern. Eine Liste der Autoren und deren logische Gruppierung wird bezüglich der Tätigkeitsgebiete oder Lokationen erstellt und dann über so genannte Erfassungssysteme mit dem Informationsbaum verbunden. So zeigt sich, welcher Autor welche Information erzeugt und erzeugen darf, und auf welchen Erfassungssystemen welche Information eingehen kann. Informationsverteilung Damit Informationen überhaupt sinnvoll eingesetzt werden können, müssen sie den Informationskonsumenten zugänglich gemacht werden. Die grundsätzliche Frage des Information-Modelling ist, wer die Informationen überhaupt sehen will, und wie für diesen einen Konsument oder die Konsumentengruppe die Informationen aufbereitet werden, wo sie vorhanden sein müssen, und wie lange und auf welche Art die Informationen dort vorliegen müssen. Dieses Verteilungsmodell stützt sich wieder auf die Erfassungssystemlogik, die bereits für die Etablierung der Autorenstruktur verwendet wurde. Es können zusätzliche Knotenpunkte in das Erfassungs- und Verteilungsnetz eingebunden werden, um eine bessere Granulierung und so eventuell eine kostengünstigere Verteilung von Informationen zu realisieren. Grundsätzlich werden zunächst die Konsumenten mit ihren besonderen Anforderungen dokumentiert und erfasst. Diese Anforderungen werden in der Publikationsschicht festgehalten, in der mehrere gleiche Anforderungen zu einem Publikationsknoten zusammengefasst werden können. Auch die unterschiedlichen Anforderungen eines Konsumenten an die gleiche Information können in mehreren Publikationsknoten dargestellt werden. Aufgrund der Informationsanforderungen der Publikationsschicht wird diese nun mit den bestehenden Erfassungssystemen und Verteilungssystemen über den Informationsbaum verbunden. Das dadurch entstandene Modell umfasst Aufgabenbereiche, die von der Informationserstellung und verteilten Bearbeitung über die hierarchische, aggregierte und abstrahierte DrillDown-Struktur der Informationen bis hin zur Verteilung und den einzelnen Darstellungen und Konsumenten reichen und eine komplette Darstellung des Informationsflusses liefern.

90

Sandini Bib Aufbau eines Wissensnetzes

Formatkonvertierungen Bei der Verteilung einzelner Informationen und dem Konzept, dass jeder Autor in einer für ihn angenehmen und gut zu bedienenden Umgebung arbeitet und jeder Konsument die Informationen in dem für ihn günstigsten Format und der besten Darstellung bereitgestellt bekommt, werden innerhalb der Informationsflüsse Formatkonvertierungen vorgenommen. In den Informationsmodellen sind solche Konvertierungen auf der Schicht der Erfassungssysteme vorgesehen und enden dort direkt oder über angeschlossene Konverter. Bei einer Verteilung von Informationen über mehrere Erfassungssysteme hinweg können so durchaus mehrere Konverterketten ausgeführt werden. Dies ermöglicht auf der einen Seite eine dezentrale Administration der Anforderungen und auf der anderen Seite dennoch eine zentrale Planung der eigentlichen Informationsflüsse. Zusatzfunktionen der Publikationsschicht Die Publikationsschicht übernimmt die unterschiedlichen Darstellungen der zu verarbeitenden Informationen. Zusätzlich können Vernetzungsfunktionen und die Vernetzung zu komplett anderen Informationssystemen wie z.B. statischen Informationen vorgesehen werden. Die Gültigkeit und die Weiterarchivierung der Versionierung von Informationen können ebenfalls in Zusatzmodulen zu den einzelnen Knotenpunkten der Publikationsschicht implementiert und dargestellt werden. In einem ersten Informationsmodell sollte zunächst nur die Darstellung der Informationen innerhalb der Publikationsschicht modelliert werden: Der Drill-Down in die weitere Behandlung der Informationen sollte bei einer weit ausgedehnten Konsumenten- und Verhaltensbasis in das Modell aufgenommen werden und kann dann den Automatisierungsgrad des Informationsmodells erheblich steigern. Zu den Zusatzmodulen, die aufgelistet und definiert werden können, zählt dann auch die weitere Verarbeitung der mitgelieferten Meta-Informationen, die Indizierung der Informationen einer oder mehrerer Klassen sowie die redaktionelle Verarbeitung innerhalb der Verteilungsorganisation des Informationsmodells.

5.2

Aufbau eines Wissensnetzes

Die beschriebene Theorie über das Modellieren von Informationen in Klassenbäumen nach Maßgaben des objektorientierten Designs ist in der Praxis relativ leicht umzusetzen. Dabei muss es Autoren ermöglicht werden, ihren erzeugten Content, also das Wissen des Unternehmens, sehr einfach an den beschriebenen Content-Pool zu übergeben und dann nicht mehr in die wei-

91

Sandini Bib 5 Content-Management und Content-Pool

tere Verarbeitung der Informationen involviert zu sein. Die verschiedenen Pools, an denen Autoren ihre Informationen einspeisen, werden miteinander verbunden und so zu einem großen Pool zusammengefasst, so dass an jeder Stelle des Netzes über eine Pool-Komponente alle Informationen in einem Modell verfügbar sein können. Einzelne Anwendungen zapfen nun dieses Wissen an und bauen eine eigene Struktur auf Basis der Informationsstruktur im Content-Pool und in den gegebenen Meta-Informationen auf, die dann im Layout der jeweiligen Anwendung mit den Informationen aus dem Pool dargestellt wird.

Abbildung 5.4: Aufbau eines Wissensnetzes

5.2.1

Informationserfassung und -verteilung

Da Autoren, die Informationen in den Content-Pool einstellen wollen, können und müssen, weltweit im Unternehmen verteilt sind, werden Richtlinien für die Erstellung des Content-Pools im WebFarm-Standard niedergelegt.

92

Sandini Bib Aufbau eines Wissensnetzes

Content-Pool-Basis In jeder WebFarm-Lokation wird ein zentraler Server angestellt, der allein für den Content-Pool dieser Lokation genutzt wird. Auf diesem Server ist zunächst das Informationsmodell der Verfasser und Autoren dieser Lokation sowie aller technisch untergeordneten Lokationen, also alle Lokationen, die ihre Internet-Connectivity über diese WebFarm-Lokation beziehen, hinterlegt. Neben den eigenen Daten werden auf diesem Server alle in dieser Lokation benötigten, nicht lokal erfassten Informationsklassen von anderen Lokationen her eingespielt. WebFarm Location DMZ II Packetfilter

Content Pool Server

GAN

DMZ II DMZ II Packetfilter Packetfilter Content Pool Server Content Pool Server

Abbildung 5.5: WebFarm mit Content-Pool-Server

Wenn eine interne oder externe Anwendung in einer zweiten Lokation also Informationen nutzt, die von einem Autor in der ersten Lokation an den Pool übergeben wurden, werden diese anhand des Informationsmodells an den Pool-Server (Gatherer) in der zweiten Lokation einmal gespiegelt und können dort von allen internen oder externen in der zweiten Lokation angesiedelten Anwendungen genutzt werden. Da die Information am dritten Standort nicht benötigt wird, ist das Informationsmodell so konfiguriert, dass die Information erst gar nicht dort gespiegelt wird. Wird zu einem späteren Zeitpunkt eine Anwendung geschaffen, die diese Informationsklasse ebenfalls benötigt, wird das Informationsmodell entsprechend verändert.

93

Sandini Bib 5 Content-Management und Content-Pool

WebFarm Location DMZ II

Client

Packetfilter

Content Pool Server Externe Web Anwendung

Interne Web Anwendung GAN

DMZ II

DMZ II Application Level Gateway

DMZ II

Packetfilter Packetfilter

Content Pool Server Content Pool Server

Abbildung 5.6: Verbindungen zwischen Content-Pool-Server und Web-Anwendungen

Weitergehende Erfassung Befinden sich im GAN oder in einem Netz von Partnern Autoren, die sehr viele Informationsklassen mit Informationen versorgen und selbst lokal auch Anwendungen betreiben – was typisch ist, denn eigene Informationen werden auch lokal verwendet –, so ist es netzwerktechnisch und sicherheitstechnisch oft effizient, wenn dort ein eigener Pool-Server quasi zur Erfassung der Daten – für die lokalen Anwendungen auch zum Empfangen von Daten aus dem Pool – eingerichtet wird. Das hat zur Folge, dass Daten nur einmal über die ohnehin stark beanspruchte Leitung zur WebFarm-Lokation gesendet werden müssen.

Externe Web-Anwendung

Interne Web-Anwendung

DMZ I

DMZ II Application Level Gateway

GAN Packetfilter

Web-Anwendung

Content Pool Server LocationLAN

Client

Content Pool Server Client

Abbildung 5.7: Weitergehende Erfassung

94

Sandini Bib Aufbau eines Wissensnetzes

Externer Content Oft wird auch ein nicht eigener Content in Anwendungen eingesetzt. Zum Beispiel Nachrichten oder Artikel werden oft von externen Lieferanten eingekauft, aber auch Partner produzieren Content, der in internen Anwendungen sinnvoll einzusetzen ist. Je mehr Content ein Pool dem Unternehmen bereitstellt, desto besser ist die Versorgung im Unternehmen mit Wissen, dessen Erstellung ja bekanntlich sehr teuer ist. An dieser Stelle ist noch einmal zu betonen, dass das bloße Einstellen von Content in willkürliche Strukturen keinen Mehrwert, sondern höchstens Chaos ergibt. Die Idee eines Informationsmodells ist es, strukturiertes Wissen – Content – zu sammeln und dieses Wissen dann in der Struktur, dem Verhalten und dem Aussehen einzelner Anwendungen anzupassen, damit es in die Anwendungen nahtlos integriert werden kann und so als Anwendungs-Content wiederverwendet werden kann. Die Kostenersparnis und die Qualitätsverbesserungen, die durch die Wiederverwendung von Wissen ermöglicht werden, sind enorm, und der WebFarm-Standard liefert eine Basis, eine solche Infrastruktur und ein derartiges System zu erstellen. Um externen Content einzubinden, kann nicht ein Zugriff auf den internen Content-Pool erlaubt werden, da dies die Sicherheitsrichtlinien der nach den im WebFarm-vorgestellten Firewall-Prinzipien verletzen würde. Aus diesem Grund wird ein externer Gatherer aufgestellt, der externe Informationen für den Content-Pool entgegennehmen kann und diese dann in den internen Content-Pool integriert, wo sie sich wieder durch das gesamte Content-Netzwerk verteilen können. Externe Web-Anwendung

Internet

Interne Web-Anwendung

DMZ I Packetfilter

DMZ II Application Level Gateway

Content Pool Server

Content Pool Server

Client Client

Abbildung 5.8: Einbindung von externem Content

95

Sandini Bib 5 Content-Management und Content-Pool

Handelt es sich bei einem externen Ersteller um einen Partner oder einen Kunden, der selbst die gleichen Anforderungen in puncto Netzwerkoptimierung und Sicherheit hat, eventuell eine eigene Informationsstruktur pflegen will usw., kann dort wiederum ein Content-Pool-Server (Gatherer) aufgestellt werden, der dann die Daten des lokalen Netzes entgegennimmt und lediglich die Informationen, die extern publiziert werden sollen, an den Content-Pool der WebFarm-Lokation weiterleitet, was wiederum über den externen Server geschieht. Client Client

LAN

Packetfilter

Externe Web-Anwendung

Interne Web-Anwendung

Content Pool Server

Internet

DMZ I Packetfilter

Content Pool Server

DMZ II Application Level Gateway

Content Pool Server

Abbildung 5.9: Weiterleitung über externen Server

5.2.2

Sicherheitsstandard

Da die Informationen, das Wissen und damit der gesamte Content über unterschiedlichste Leitungen versendet werden, die nicht immer den Sicherheitsstandards der Informationen entsprechen, und ein einheitliches Protokoll, das standardisiert und dokumentiert ist, verwendet werden muss, ist die Verschlüsselung der Informationen und Identifikation der Kommunikationspartner eine Voraussetzung für den Einsatz dieser Struktur. Es ist also gemäß des WebFarm-Standards zwingend notwendig, dass die Kommunikation zwischen Content-Pool-Servern, die Kommunikation zwischen Content-Pool-Servern und Anwendungen sowie die Kommunikation zwischen Clients und Content-Pool-Servern verschlüsselt sind. Es muss hierfür eine definierbare Verschlüsselungsstärke eingesetzt werden, damit den rechtlichen Rahmenbedingungen in unterschiedlichen Regionen des globalen Netzes entsprochen werden kann.

96

Sandini Bib Redaktionskonzept

Ebenso muss gewährleistet sein, dass der Initiator einer Kommunikation sowie der Empfänger genau wissen und protokollieren, mit welcher Endstelle eine Kommunikation stattgefunden hat. Eine entsprechende Berechtigungsvergabe, die nach dem WebFarm-Standard auf dem WebFarm-Directory beruht, kann damit definiert werden und setzt voraus, wer mit wem überhaupt welche Informationen austauschen darf.

5.3

Redaktionskonzept

Wird eine neue Information von einem internen oder externen Autoren angeliefert, kann dieses in einigen Informationsklassen nicht ohne eine vorherige Freigabe durch einen oder mehrere verantwortliche Redakteure auf eines der Produktionssysteme publiziert werden. Daher ist es notwendig, dass eine Information zuerst auf ein komplett unabhängiges System (Pre-ProductionSystem) publiziert wird. Durch E-Mail wird der verantwortliche Redakteur oder das Koordinationsteam von dem neuen Dokument in Kenntnis gesetzt. Entspricht das Dokument allen Vorgaben, kann es von einem der eingetragenen Redakteure freigegeben werden. Das Freigabe-Staging kann beliebig tief geschachtelt werden. Somit kann z.B. eine lokale Freigabe erfolgen und erst dann in einem zweiten Schritt eine Freigabe für eines der globalen Systeme. Die Festlegung der jeweiligen Redaktionsstufen für einen konkreten Anwendungsfall ist Bestandteil des Informationsmodells.

Autoren

Firewall

Firewall

WWW

Editoren

Abbildung 5.10: Redaktionskonzept

Es sollte durch das Redaktionskonzept ein Vier-Augen-Prinzip unterstützt werden.

97

Sandini Bib 5 Content-Management und Content-Pool

Ob und wann ein Freigabemechanismus benötigt wird, wird auf Verteilungsund Applikationsebene innerhalb des Informationsmodells konfiguriert und festgehalten. Auf diese Weise kann das Berechtigungsschema auf das Wissen eines Unternehmens flexibel durch das WebFarm-Directory konfiguriert werden, das selbst an interne Systeme gekoppelt sein kann.

5.4

Grundlagen für ein Informationsmodell

Nachdem die Notwendigkeit des Aufbaus eines Modells zur Entgegennahme und zur Verteilung und dem anschließenden Management von Informationen mittels eines Content-Pools festgestellt wurde, definiert der WebFarmStandard einige Ansätze zur Erstellung dieses Modells und zur Konfiguration der Erfassung mittels Meta-Informationen, zur Verteilung und zum Management von Informationen an sich.

5.4.1

Basisstruktur des Modells

Die Klassenstruktur des Modells sollte sich nicht an Lokationen orientieren, da es in einem globalen Unternehmen immer wieder Änderungen in Lokationen, Wichtigkeit von Lokationen bzw. deren Strukturierung gibt. Es bietet sich auch nicht an, das Modell auf einem Organigramm zu basieren, da es sich gewöhnlich im Verlaufe der Unternehmensentwicklung und bei Änderung der Unternehmensstruktur ändert. Der WebFarm-Standard gibt darum vor, ein solches Informationsmodell an den Kerngeschäften des Unternehmens zu orientieren. Dabei ist zu beachten, dass sich im Laufe der Zeit die Kerngeschäfte eines Unternehmens nur selten ändern. Es ist durchaus denkbar, dass ein Kerngeschäftsbereich wegfällt oder ein neuer hinzukommt, die Veränderung in der Bedeutung eines bestehenden Bereichs, also in der fachlichen Orientierung des Bereichs, ist aber fast ausgeschlossen. Darum bieten sich diese Fakten als Basis für ein Klassenmodell an, da sie für die Erweiterbarkeit des Modells als stabile Eckpfeiler fungieren. Diese relativ geringe Zahl an abstrakten Oberklassen sorgt dafür, dass eine Erweiterbarkeit immer gegeben ist und das Informationsmodell nicht einem kompletten Reeningeering unterworfen werden muss, wenn sich im Unternehmen Änderungen oder Erweiterungen der Informationsstruktur ergeben, was immer ein erheblicher Aufwand wäre. Unter diesen Basisklassen können nun die einzelnen Fachgebiete, die sich nicht an Gruppen, sondern an tatsächlichen fachlichen Problemstellungen des Bereichs orientieren.

98

Sandini Bib Grundlagen für ein Informationsmodell


 
  

    


 

    


 

   


 

  
 




Abbildung 5.11: Klassenstruktur Informationsmodell

Unter diesen Fachthemen können nun die einzelnen tatsächlich existierenden Informationen angebracht werden, die sich an Gruppierungen, Strategien usw. orientieren.

5.4.2

Verwendung von Meta-Informationen zur Klassifizierung

Es sollte nicht für jedes Element eine neue Klasse angelegt werden, vielmehr sollten sehr gleichartige Elemente in einer Klasse untergebracht und über Meta-Informationen unterschieden werden. Ist z.B. ein Versicherungsbetrag für eine Information ausschlaggebend, sollte es nicht für jede Betragsspanne eine eigene Klasse geben, sondern nur eine Klasse, in der die Betragsspanne eine Meta-Information ist. Auf diese Weise hat das Klassenmodell Bestand, denn der flexible Teil der Meta-Informationen, der sich über die Zeit hinweg ändern kann, ist nicht Bestandteil des Klassenmodells. Die Meta-Informationen können nachträglich ohne Beeinflussung der Konfiguration des Modells oder des Systems später verändert werden. Dabei ist es auch sinnvoll, den Meta-Informationen sprechende Namen und sprechende Namen für die Auswahlkriterien zu geben, in der tatsächlichen Datenrepräsentation allerdings einfache Werte zu verwenden, damit eventuell allein die Namen verändert werden können.

5.4.3

Weitere Verwendung von Meta-Informationen

Meta-Informationen sollten generell zur Beschreibung von Informationen eingesetzt werden. Eine Kurzzusammenfassung der Inhalte kann dabei z.B. hilfreich sein. Ansonsten können Meta-Informationen zur näheren Beschrei-

99

Sandini Bib 5 Content-Management und Content-Pool

bung der eigentlichen Daten verwendet werden. Zum Beispiel kann eine Information über Schlagwörter in einen größeren Kontext eingeordnet werden. Über Gültigkeitszeiträume können Lebenszeiten vergeben werden, die das Management von Informationen erheblich erleichtern. Neben der Erzeugung von Unterklassen und der näheren Beschreibung von übergebenen Informationen können über Meta-Informationen Verbindungen zu anderen Informationen im Content-Pool hergestellt werden. Dies geschieht üblicherweise über Stichworte, die sich auch in direkter Vernetzung von Dokumenten auf einzelnen Servern manifestieren können, oder auch über die Herstellung von Bezügen zu einzelnen Fachgebieten, Produkten usw., anhand derer dann Navigationsebenen eingezogen werden können.

5.4.4

Mehrsprachigkeit

Mehrsprachigkeit ist in einem Informationsmodell eines global operierenden Unternehmens immer thematisiert. Dabei ist der Ansatz des Einrichtens spezieller Klassen oft nicht sinnvoll. Informationen können wesentlich flexibler eingesetzt werden, wenn in allen Klassen die Meta-Information der Sprache erfasst wird. Auf diese Weise kann die Darstellung und Verteilung von Informationen auf Sprache basieren, in Anwendungen auf eine Klasse auch in mehreren Sprachausprägungen referenziert und somit mit einem Zugriff auf den Content-Pool aller Contents verfügbar gemacht werden.

5.5

Redaktionssystem und Redaktionsverfahren

Das in vorangegangenen Kapiteln der WebFarm-Standarddefinition beschriebene Verfahren zur Erstellung und Verwendung von Content-Pools ist auf den Bereich der semi-dynamischen Informationen anwendbar, und nur auf diesen. Im Bereich der Webanwendungen werden aber auch alle anderen Arten von Informationen eingesetzt, und sie spielen teilweise eine zentrale Rolle. Neben den eigentlichen Informationen und deren eventuell dynamischen Generierung gibt es auch ganze Anwendungen, die informatisch nach endlichen Automaten ablaufen und dementsprechend nicht als eine für sich existierende Information in einer Struktur angesehen werden können, sondern als ein Konglomerat an Informationen, die über einen Zustand zusammengehalten werden. Für alle diese anderen Arten von Informationen wie 왘 statische Navigation, 왘 statische Inhalte,

100

Sandini Bib Redaktionssystem und Redaktionsverfahren

왘 dynamisch generierte Inhalte, 왘 einfache Input-Only-Anwendungen, 왘 interaktive dynamische Informationen oder 왘 komplette Anwendungen mit Ablauflogik

kann aber nicht auf das Redaktionsverfahren, die Verteilung und die Kontrolle der Informationsflüsse verzichtet werden. Es muss darum im Konzept des Content-Managements ein Bereich den Redaktions- und Verteilungsverfahren aller anderen Informations-gattungen gewidmet werden. Werbeagentur entwirft

HTMLDesigner

Marketing neue Impulse + Konzepte

realisiert + schickt Updates

Preproduction Webserver

Unternehmen beauftragt+kontrolliert+ verantwortet, muss Update freigeben

Webserver

soll bis auf die neuen Updates identisch zu Webserver sein

SystemBetreuer

Entwicklungsserver

muss aktuell sein, aber darf nur vom Unternehmen freigegebene Inhalte präsentieren

BackupWebserver muss identisch zu Webserver sein

betreut viele Server,spielt Updates ein, spricht Serverupdates mit Verantwortlichen und Marketing ab

Revision/ Controlling verlangt Kontrollierbarkeit+ Nachvollziehbarkeit

Hoher Arbeitsaufwand für alle Beteiligten Je mehr Server und je grösser das Angebot, desto schlimmer wird die Verwirrung

Abbildung 5.12: Übersicht Redaktionssystem

101

Sandini Bib 5 Content-Management und Content-Pool

Es gilt noch einmal zu erwähnen, dass die semi-dynamischen Informationen sicherlich vom Volumen her gesehen den größten Teil aller Informationen ausmachen, die anderen Informationsgattungen und insbesondere die Anwendungen bei den Benutzern und in der Akzeptanz von geschaffenen Webanwendungen mindestens als genauso wichtig eingestuft werden müssen. Dieses Kapitel des WebFarm-Standards beschäftigt sich mit den Redaktionsund Verteilungsverfahren für statischen Inhalt und Applikationen.

5.6

Informationsanlieferung

5.6.1

Parameter der Anlieferung

Grundsätzlich ist es der Fall, dass bei allen anderen Arten von Inhalten Dateien für eine bestimmte Anwendung und damit auch für einen bestimmten Rechner oder einen bestimmten Dienst auf einem Rechner angeliefert werden. Darum ist ein entscheidendes Kriterium für die Informationsanlieferung das Zielsystem für die Informationen. Für die Identifikation des Zulieferers und die entsprechende Berechtigung ist es wichtig, den Zulieferer zu erkennen, auch dieser muss dementsprechend Teil bei einer Datenlieferung mitgegebener Meta-Informationen sein. Da im Falle von Anwendungen und statischen Informationen, die mit diesem Verfahren der Redaktion und Verteilung unterworfen werden, die Sequenz der Anlieferungen eine wichtige Rolle spielt, ist es essenziell, die Reihenfolge der Anlieferungen festzuhalten. Aus diesem Grund muss die Anlieferung in der Sequenz der Anlieferungen dieses Zulieferers für dieses Ziel gekennzeichnet werden. Zusammenfassend sind also folgende Parameter essenziell für die Anlieferung von statischem Content und Applikationen: 왘 Quelle (Agentur, Team, Benutzer, …) 왘 Ziel (Server, Service, …) 왘 Sequenzkennzeichnung für diese Quelle in Bezug auf dieses Ziel

Dies sind die Minimalanforderungen für die Anlieferung von Daten. Weitere Meta-Informationen sollten mitgegeben werden, damit ein Verteilungs- und Redaktionsverfahren auch für Inhalte, die nicht durch ein Informationsmodell abgedeckt werden, implementiert werden kann.

102

Sandini Bib Informationsanlieferung

Weitere Meta-Informationen sind für die Anlieferung von Inhalten relevant und können das Verfahren in seiner Funktionalität erheblich verbessern. Allgemein können folgende Meta-Informationen genannt werden, die aber je nach System durchaus ergänzungswürdig sind: 왘 Zeitpunkt der Einstellung

Es kommt häufig vor, oder es sollte bei einer guten Entwicklung vorkommen, dass Informationen und Anwendung vor ihrem tatsächlichen Release-Datum für die Öffentlichkeit bereits an die Produktionsumgebung übergeben, dort freigegeben und dann trotzdem erst zu einem definierten Zeitpunkt in das Produktionssystem überstellt werden. Dies kann auch vertagt werden, um bestimmte »Online-Termine« (z.B. 01.01., 0:00) zu halten. 왘 Zeitpunkt des Verfalls

Für einige Informationen ist auch im Bereich von statischen Modulen und Anwendungen eine Lebenszeit sinnvoll zu definieren. Werden z.B. steuerlich-relevante Anwendungen publiziert, so ist deren Gültigkeitsdauer oft bereits im Vorfeld bekannt, und es kann rechtliche Konsequenzen haben, wenn diese dann immer noch verfügbar sind. Ein Automatismus, um solche Informationen wieder zu entfernen, ist nicht immer sinnvoll implementierbar, da oft Auswirkungen auf den Rest der Zielanwendung bestehen würden, es muss aber durch das System nach dem WebFarm-Standard gewährleistet sein, dass das Administrationsteam der WebFarm-Lokation sowie die entsprechenden Fachverantwortlichen benachrichtigt werden. 왘 Rückverteiler

Es ist oft sinnvoll, wenn bei Freigabe einer bestimmten Anwendung oder bestimmter Informationsmodelle dritte Stellen genau diese freigegebenen Module erhalten, sei es zur Versionierung oder zur Dokumentation der Entwicklung. Sinnvoll ist dies auch, wenn ein externer Zulieferer die Anwendungen pflegt, damit dieser immer einen Überblick behalten kann, was sich bei seinem Kunden – dem WebFarm-Betreiber – in Produktion befindet.

5.6.2

Methoden zur Anlieferung von Informationen

Da es sich bei einem solchen System um ein globales Verwaltungswerkzeug handelt und der WebFarm-Standard so aufgebaut ist, dass möglichst wenig Restriktionen an Umgebungen und Entwicklungen weitergegeben werden müssen, ist es offensichtlich, dass der WebFarm-Standard vorschreibt, dass die Anlieferung über ein möglichst breites Spektrum an Wegen erfolgen kann.

103

Sandini Bib 5 Content-Management und Content-Pool

Die zu unterstützenden Methoden sind im Folgenden mit ansteigender Content- und Identifikationssicherheit aufgeführt. E-Mail Die Anlieferung per E-Mail ist absolut plattformunabhängig und kann von absolut jedem Zulieferer von Informationen unterstützt werden. Dabei versendet der Zulieferer eine E-Mail mit dem Package, das in ein WebFarm-System eingespielt werden soll, an den Redaktionsserver seiner verantwortlichen WebFarm-Lokation, wo das Package aus der E-Mail als Attachment extrahiert wird und dann dem eigentlichen Redaktionssystem eingespeist wird. internal Content Creator

external Content Creator

Web Application

Content Management

DMZ I

DMZ II

Internet Packetfilter

Application Level Gateway

eMail external

GAN Packetfilter

eMail internal

Abbildung 5.13: Anlieferung von Informationen

FTP- oder HTTP-Upload Genauso einfach ist das Einstellen von Informationen oder die Informationsübergabe per FTP. Es existiert ein »Write Only«-FTP-Service, auf dem definierte Zulieferer Packages ablegen können. Dieser Service steht im externen Segment einer Firewall für externe Zulieferer und in der DMZ II für interne Zulieferer zur Verfügung. Nach der Übergabe per FTP werden die Informationen von einem Automatismus in das eigentliche Redaktionssystem überführt. SCP-, SFTP- oder HTTPS-Upload Analog zu FTP kann auch ein verschlüsseltes Verfahren zum Transfer der Daten verwendet werden. Dies ist für alle internen Informationen sowie Informationen, die dem Datenschutz unterliegen, bei externen Anlieferungen

104

Sandini Bib Informationsanlieferung

auf jeden Fall notwendig. Existiert eine interne Netzwerk-Sicherheitsrichtlinie, müssen die Übertragungen gemäß dieser Richtlinie auch intern verschlüsselt erfolgen. Direkte Anbindung an den Pool Die direkte Kommunikation mit dem Content-Pool ergibt zusätzliche Funktionalitäten der Verwaltung von Einspielungen bzw. Packages und entspricht in jeder Hinsicht den höchsten Sicherheitsstandards, da sich der Zulieferer durch seinen Client eindeutig identifiziert und die Übertragung immer gemäß der Konfiguration der Content-Pool-Server verschlüsselt erfolgt. Der Nachteil dieses Vorgehens ist, dass die Plattformunabhängigkeit verloren geht, da der Zulieferer auf WebFarm-Standardsoftware (siehe Content-Pool) angewiesen ist und nicht nur in seiner normalen Arbeitsumgebung verbleiben kann. Diese Einschränkung ist nur für externe Zulieferer relevant. internal Content Creator

external Content Creator

Internet

Web Application

Content Management

DMZ I

DMZ II

Packetfilter

Application Level Gateway

Content Pool external

GAN Packetfilter

Content Pool internal

Abbildung 5.14: Anbindung an den Pool

5.6.3

Packages und Packaging

Auffällig an der bisherigen Beschreibung ist, dass nicht von einzelnen Informationen wie beim Content-Pool gesprochen wird, sondern immer auf Packages referenziert wird. Das Konzept des Packaging wurde aus den allgemeinen Konzepten der Softwareverteilung übernommen. In einem Package werden alle Informationen, die zu einer Lieferung gehören, zusammengefasst. Also alle Informationen, die vom Kontext her zusammengehören und auf einer Stufe stehen, sollten in einem Package zusammengefasst werden. Dabei sollte nicht eine Anwendung als ein Kontext gesehen werden, sondern einzelne definierte Module einer Anwendung oder eines Servers; dies hat den

105

Sandini Bib 5 Content-Management und Content-Pool

Vorteil, dass einzelne Funktionalitäten oder Inhalte bereits freigegeben werden können und dementsprechend auch funktional zur Verfügung stehen, während andere noch nicht freigegeben sind. Konkret sollten nicht alle Updates für einen Webserver auf einmal in ein Package gepackt werden, sondern in mehrere kleine Packages, die in einzelne Module des Servers geteilt sind. Gleiches gilt für Anwendungen, hier sollte nach Modulen oder Zustandspaketen der Anwendung vorgegangen werden. Da es sich bei einem Package um eine Zusammenstellung von Informationen handelt, sollte ein Package als Archiv angeliefert werden. Um eine Bandbreitenoptimierung bei der Anlieferung zu gewährleisten, sollte es sich um ein komprimiertes Archiv handeln. Da das Redaktions- und Verteilungsverfahren möglichst viele Quellplattformen unterstützen muss, werden verschiedenste Verfahren wie z.B. ZIP, tar, gz, tar, gz etc. unterstützt. Der Name des Package ist ausschlaggebend für dessen Verarbeitung, wenn keine direkte Verbindung zum System besteht, das bedeutet, dass im Namen des Package Quelle, Ziel und Sequenz identifiziert sein müssen.

5.6.4

Sicherheitsstandard

Sicherheit ist bei der Pflege von Webanwendungen, wie bereits mehrfach dargelegt, immer ein entscheidendes Thema. Zunächst muss die Übertragungssicherheit der Daten gewährleistet sein, wenn es sich um entsprechend schützenswerte Informationen handelt. Das bedeutet, dass, sobald schützenswerte Informationen übertragen werden, diese Übertragung bereits verschlüsselt erfolgen muss, wenn die Quelle außerhalb des GAN liegt. Liegt die Quelle innerhalb des GAN, bestimmt die interne Sicherheits-Policy, inwieweit Verschlüsselung zwingend notwendig ist. Verschlüsselung ist an sich ohnehin zu bevorzugen, da moderne Verschlüsselungsverfahren immer auch Kompression beinhalten und damit eine Bandbreitenschonung nicht bei bereits komprimierten Packages gegeben ist. Der zweite sicherheitskritische Aspekt bei der Anlieferung von Daten ist die Authentizität der Quelle. Das WebFarm-Konzept sieht zunächst die Identifikation der Quelle anhand des Package-Namens vor, was für gewöhnliche Anwendungen aufgrund des gerade durch das Redaktions- und Verteilungssystem implementierten Vier-Augen-Prinzips ausreichend ist. Wird aufgrund der Sensibilität der Anwendung eine genaue Identifikation der Quelle erforderlich, so wird diese durch eine elektronische Unterschrift um das übertragene Package oder ein Zertifikat in der Übertragung gewährleistet, das dann vom Redaktions- und Verteilungssystem mit der Quellangabe im Namen des Package verglichen wird und somit die Authentizität des Senders ohne Zweifel festhält oder das Package verwirft.

106

Sandini Bib Überprüfung von angelieferten Packages

external Content Creator

Internet Packetfilter

Web Application

Content Management

DMZ I

DMZ II

Application Level Gateway

internal Content Creator

GAN Packetfilter

Abbildung 5.15: Beispiel sichere Datenübertragung

5.7

Überprüfung von angelieferten Packages

Sind Packages einmal erstellt und an das System übertragen, muss eine Überprüfung des Package erfolgen. Hierbei werden mehrere Schritte unternommen, die seriell ablaufen: 왘 Überprüfung der Quell- und Zielberechtigung

Hier wird überprüft, ob ein Zulieferer (Quelle) die Berechtigung hat, auf das definierte Ziel bzw. die Position im Ziel zu schreiben, die das Update anspricht. Da an einer Webanwendung viele Teams arbeiten können und eventuell auch mehrere externe Zulieferer mit der Befüllung einer Anwendung mit statischen Informationen und Applikationen beauftragt sein können, wird im Zielsystem selbst noch die Lokation mit Berechtigungen versehen. Für einen Zulieferer ist genau definiert, wo in einer Anwendung Updates eingespielt werden dürfen. 왘 Überprüfung legaler Namensgebung und Zeichenverwendung

Für die Funktionalität von Webanwendungen ist die Namensgebung von Dateien entscheidend. So dürfen z.B. keine Leerzeichen und dergleichen in Dateinamen vorkommen, damit die Anwendungen nachher den Standards der Übertragungsprotokolle entsprechen. Diese Namensgebung wird überprüft. Gleichzeitig wird innerhalb des Content, wenn es sich nicht um Binärdateien handelt, was anhand der definierten MIME-Types für die Dateikennungen abgelesen werden kann, überprüft, ob die Syntax für korrektes oder annähernd korrektes HTML und XML eingehalten wurde, und ob die Konventionen für Zeichensätze (HTML ist 7 Bit) eingehalten wurden.

107

Sandini Bib 5 Content-Management und Content-Pool

왘 Überprüfung der Dateiberechtigungen

Die Berechtigungen einzelner Dateien ist für die Sicherheit der Anwendung entscheidend und muss daher überprüft werden. Das bedeutet, grundsätzlich sind in öffentlichen Bereichen keine Dateien erlaubt, die Schreibberechtigung besitzen, und nur bei Bereichen, die für Programme vorgesehen werden, werden Dateien zugelassen, die eine Ausführungsberechtigung haben, aber auch nur, wenn definierte MIME-Types dies unterstützen. Weitere Überprüfungen können in den Prozess des Redaktions- und Verteilungssystems für statische Inhalte und Anwendungen einbezogen werden.

eMail

Datenübertragung

Ablehnung / Zurück an Anlieferer und Benachrichtigung Übergabeserver

User-Check

SequenceCheck

Formatcheck / Entpacken des Archivs

PermissionChecks

DependencyCheck

Owner-Check

Einspielen der Daten auf den PreproductionServer

Release (Freigabe)

Kopie + Nachricht an Sender / Besitzer / Auftraggeber

Backup-Server

Web-Server

Abbildung 5.16: Ablaufdiagramm Überprüfung angelieferter Informationen

108

Sandini Bib Freigabe und Verteilung

Es ist anzumerken, dass eine strenge syntaktische Überprüfung von HTML und XML wünschenswert ist, da sie die korrekte Darstellung von HTML und XML auf allen verfügbaren Browsern garantieren könnte, dass eine solche Überprüfung allerdings 95% aller heute erzeugten HTML- und XML-Inhalte im Internet abweisen würde und damit als unrealistisch angesehen werden muss.

5.8

Freigabe und Verteilung

Nach der Überprüfung des angelieferten Update wird dieses auf das Pro-Production-System eingespielt, wo ein verantwortlicher Redakteur die Änderungen am statischen Inhalt oder an Applikationen innerhalb einer Webanwendung in einer realen Umgebung testen muss und dann freigeben oder verwerfen kann. Auf diese Weise ist gewährleistet, dass ein Verantwortlicher den entsprechenden Inhalt vor seiner Veröffentlichung gesehen hat und keine nicht definierten Inhalte an die Benutzerkreise einer Anwendung gelangen.

Abbildung 5.17: Bildschirmansicht Freigabe

109

Sandini Bib 5 Content-Management und Content-Pool

Ein Redakteur wird über das Eintreffen eines Update, für das er verantwortlich ist, per E-Mail benachrichtigt, kann dann die Webanwendung in ihrer Komplettfunktion auf dem Pro-Production-System einsehen oder über das Freigabe-Interface speziell die Teile der Webanwendung betrachten, die sich durch das Update verändert haben. Nach der Freigabe eines Update wird dieses Update in die Warteschlange für die Verteilung auf das entsprechende Zielsystem sowie dessen Backup-System eingereiht. Diese Warteschlange existiert, um Abhängigkeiten zwischen Updates zu ermöglichen und trotzdem eine Freigabe durch den Redakteur zuzulassen. Das bedeutet, es können mehrere Updates, die gleiche Serverteile verändern, im Freigabeprozess enthalten sein, die erst dann in Produktion gehen, wenn die sequenzielle und chronologische Reihenfolge der Updates als solche freigegeben ist. Außerdem werden Updates einer Quelle auch nur in der sequenziellen Reihenfolge der Anlieferung unabhängig von direkten Abhängigkeiten zwischen den Dateien eingestellt. Abhängigkeiten werden hier über die Veränderung gleicher Dateien und die Vernetzung über HTML- und XMLLinks definiert, solche Abhängigkeiten müssen nach dem WebFarm-Standard berücksichtigt werden.

Editor Web Application Backup

ContentManagement

DMZI

DMZII ApplicationLevelGateway

GAN Packetfilter

Abbildung 5.18: Abhängigkeiten

5.8.1

Rückverteilung von Packages

Ein wichtiger Aspekt in der Anwendungsentwicklung ist, dass die Entwicklungseinheit stets über den Zustand des Produktionssystems informiert sein muss, um auf diesem weitere Entwicklungen zu basieren, und um in der Lage zu sein, Verbesserungen und Bug-Fixes an diesem Produktionssystem vorzunehmen. Darum unterstützt das WebFarm-Redaktions- und Verteilungssystem die Rückverteilung freigegebener Packages. Dabei werden allen berechtigten Quellen die eingegangenen und freigegebenen Packages zugesendet.

110

Sandini Bib Freigabe und Verteilung

Das bedeutet, alle Zulieferer erhalten für alle Anwendungen, für die Packages angeliefert werden, die einen Bereich der Anwendung berühren, für den dieser Zulieferer Schreibberechtigung hat, Freigabe dieses Package sowohl wenn das Package vom Zulieferer selbst erstellt wurde, aber auch wenn ein anderer Zulieferer den entsprechenden Bereich verändert hat. Diese Rückverteilung wird durch die Freigabe von Packages veranlasst und gleichzeitig mit der Verteilung auf die Produktionssysteme vorgenommen. Dieses Verfahren gewährleistet, dass jedes Entwicklungsteam zu jeder Zeit das aktuelle Produktionssystem in einer Entwicklungsumgebung abbilden kann und dieses tatsächlich in Produktion befindliche System als Grundlage für weitere Entwicklungen nutzen kann. external Content Creator

Editor Web Application Backup

Internet

ContentManagement

DMZI Packetfilter

DMZII ApplicationLevelGateway

GAN Packetfilter

Abbildung 5.19: Rückverteilung von Packages

5.8.2

Versionierung

Im Gegensatz zum Content-Pool, der automatisch alle Versionen der eingegangenen Informationen in seinem Pool abgelegt hat, überschreibt das Redaktions- und Freigabeverfahren einmal vorhandene Informationen. Dies kann im Sinne eines geregelten Betriebs nicht angestrebt werden, und darum muss ein gewisser Grad an Versionierung erreicht werden. Es ist nicht notwendig, ein komplexes Versionierungsverfahren wie im Softwareentwicklungsbereich zu implementieren, da hier keine Sub-Zweige und Unterversionen von Produktionssystemen existieren. Es existiert zu einem bestimmten Zeitpunkt immer ein System, das so, wie es zu diesem Zeitpunkt existiert, online und verfügbar ist. Da dieser Zeitpunkt durch die sequenzielle Aktivierung von Updates einfach festzuhalten ist, kann über das Redaktions- und Verteilungssystem auch eine Versionierung stattfinden. Der WebFarm-Standard schreibt hierbei vor, dass von jeder Datei eine bestimmte Anzahl an Versionen rückwärts gehalten werden muss, die mindestens einen konfigurierten Zeitraum abdecken. Auf diese Weise kann sehr einfach ein Roll-Back über einzelne Packages und einzelne Updates gefahren werden, um den Serverzustand zu einem gewissen Zeitpunkt wiederherzustellen.

111

Sandini Bib 5 Content-Management und Content-Pool

Eine komplexe, am Konfigurationsmanagement orientierte Versionierung wird mit diesem Verfahren unnötig, da die Funktionalität des ProduktionsRollbacks gegeben ist.

5.9

Personalisierung und ProfilingDatenbanken

One-on-One kam mit den neuen Medien als Schlagwort für kundenorientierte und individualisierte Systeme, Anwendungen und Marketingaktionen auf und hat sich seitdem nicht nur im Inter- oder Intranet zu einem bestehenden Trend ausgebildet, der sich in der allgemeinen Strömung der Verbesserung des Customer-Relationship-Managements manifestiert. Auch bei reinen IT-Anwendungen im Webbereich sollte der Marketinggedanke eingehalten werden, denn letztendlich ist ein Benutzer einer Anwendung nichts anderes als ein Kunde genau dieser Anwendung und muss auch genauso gepflegt werden, damit er ein Interesse hat, die für ihn bereitgestellte Anwendung, oder den Dienst, den er nutzen soll, in seine Arbeit einzubinden. Damit verlässt die EDV eine lange Tradition, die sich aus der komplexen Bedienung von Großrechenanlagen entwickelt hat, nämlich die Tradition der »EDV für die EDV«; Gedanken analog zur Kunstströmung l'art pour l'art. Die heutige IT bewegt sich hin zu einem Dienstleistungsverhältnis, in dem die EDV nur eine Dienstleistung ist, um dem Benutzer seine Alltagsarbeit zu erleichtern oder überhaupt erst zu ermöglichen. Diese Dienstleistungseinstellung muss sich auf jeden Fall in Webanwendungen, aber auch modernen Netzwerkdiensten und den dazugehörenden organisatorischen Dienstleistungen wiederfinden, denn letztendlich ist die Aufgabe von EDV-Systemen, den Benutzer zu unterstützen und nicht dem Benutzer das Leben zu erschweren, was bei vielen alten Anwendungen noch akzeptiert wurde – im Zeitalter des Internets und seiner Anwendungen hat sich die Benutzereinstellung zu Anwendungen allerdings drastisch in Richtung einer dienstleistungsbezogenen Orientierung verändert. Die Personalisierung geht über die normale Benutzerfreundlichkeit hinaus, die eben beschrieben wurde. Bei der Personalisierung wird auf individuelle Anforderungen von Benutzern und Benutzergruppen eingegangen, die identifiziert und umgesetzt werden müssen und in weitergehender Entwicklung vom Benutzer auch selbst zu beeinflussen sind. Innerhalb des WebFarm-Standards werden verschiedene Stufen der Personalisierung und des Profiling, also des Sammelns von Daten über einen Benutzer und die daran orientierte Benutzerführung, vorgestellt, die wie ein Stufen-

112

Sandini Bib Personalisierung und Profiling-Datenbanken

modell aufeinander passen. Dieses Dokument beschreibt die Möglichkeiten und wann sie wie angewendet werden sollen sowie die dazu eingesetzten Werkzeuge.

5.9.1

Wie wird Personalisierung eingesetzt?

Ein sehr wichtiger Grundsatz aus dem gewöhnlichen Designbereich ist, dass Designmittel nicht zu viel eingesetzt werden dürfen. Dies gilt auch für Personalisierung, denn wenn eine Anwendung den Benutzer zu sehr in Anspruch nimmt, dann ist es sehr schwierig, den Benutzer auch für andere Dinge zu interessieren, und die Wartungsmöglichkeit bzw. der Benutzersupport für die Anwendung werden komplex, weil der Supporter nur in den seltensten Fällen die Ansicht des Benutzers nachstellen kann. Es gibt mehrere Möglichkeiten zu Personalisierungs-Anwendungen und -Informationssystemen, die alle in unterschiedlichen Zusammenhängen eingesetzt werden können und sollen. Dabei wird im Marketing unter One-onOne oft nur das Profiling betrachtet, welches das Benutzerverhalten in einer Anwendung analysiert und Empfehlungen zur weiteren Navigation gibt; aber auch die anderen Methoden zur Personalisierung sind sinnvoll und können sogar einfacher umgesetzt werden. Der WebFarm-Standard definiert aus diesem Grund klare Regeln, wann welche Personalisierungsform eingesetzt werden soll. Eigene Server für Benutzergruppen Eine einfache, aber dennoch sehr effektive Art der Individualisierung auf einer Breitenebene ist die Schaffung von eigenen Anwendungen mit dem gleichen Repertoire an Modulen und gleicher Content-Basis, aber mit unterschiedlicher Struktur und unterschiedlichem Design sowie nur dem Content, der für die jeweilige Benutzergruppe von Interesse ist. Das bedeutet, es wird ein Pool an Modulen und Content eingerichtet (siehe Content-Management), der für die Anwendung bzw. die benutzergruppenorientierten Instanzen der Anwendung als Basis dient; die Anwendung für die jeweilige Benutzergruppe bedient sich dann aus diesem Pool und stellt für diese Gruppe einen scheinbar individuell entwickelten Dienst dar. Die beschriebenen Benutzergruppen können nach Hierarchieebenen (z.B. Vorstand, Direktion, Projektteam, IT-Support) untergliedert werden, da all diese Gruppen unterschiedliche Anforderungen an Anwendungen haben, aber eventuell doch dieselben Module nur in sehr wenig unterschiedlichen Konfigurationen nutzen werden und das Content-Bedürfnis sich vor allem von der Detailebene und der Strukturierung unterscheidet. Dieser Ansatz ist auch im WebFarm-Standard zu Content- und Knowledge-Management sowie dem Redaktionsverfahren dargelegt.

113

Sandini Bib 5 Content-Management und Content-Pool

Usergroup 2 Server Usergroup 3 Server

Usergroup 1 Server

Content / Knowledge Pool

Module Pool

Usergroup 4 Server

Dev. 2

Author 1 Author 2

Dev. 1

Author 3

Abbildung 5.20: Server für Benutzergruppen

Bei Anwendungen im Business-to-Business-Bereich ist ein solches Vorgehen sehr empfehlenswert, da einem Kunden oder Partner so aus einem Pool von Informationen und Anwendungsmodulen für seinen Kunden- oder Partnertyp ein individueller Service zusammengestellt werden kann, der nur die Module und den Content enthält, den dieser Kunde oder Partner sehen darf und will. Diese Anwendung besitzt die Anwender (Kunden oder Partner) gewünschte Struktur und die für den Kunden oder Partner zutreffenden Eigenschaften und Layout-Definitionen. Auf der anderen Seite muss dieser Server, da er über den Content- und Modul-Pool gepflegt wird, nicht individuell betreut werden. Ein weiterer Vorteil, wenn Informationen und Anwendungen auf diese Weise zu Kunden und Partnern transportiert werden, neben dem durch die Individualisierung erreichten erhöhtem Service-Level ist, dass die Informationen für den Benutzer als hausinterne Informationen erscheinen, da sie ja im Layout des Kunden oder Partners auftauchen und somit automatisch ein völlig anderes Akzeptanzniveau haben.

114

Sandini Bib Personalisierung und Profiling-Datenbanken

Diese Art der Individualisierung sollte als erster Schritt immer in Betracht gezogen werden, weil sich der Pflegeaufwand im Vergleich zu komplett individuellen Anwendungen und komplett individualisierten Anwendungen nicht stark erhöht sowie eine in großen Teilen für die gesamte Anwendung durchgezogene Individualisierung bietet. Individualisierung von Seiten durch den Benutzer – My-Site Eine bekannte Art, wie ein Benutzer sich seine persönlichen Informationsseiten oder Portale zum Inhalt einer Anwendung erstellen kann, sind die so genannten »My-*« Seiten. Hierbei werden Informationsklassen und andere Module so zusammengestellt, dass sie von einem identifizierten Benutzer sehr einfach an vordefinierte Punkte einer Webseite gesetzt werden können. Die Anwendung speichert hierbei das Profil des Benutzers ab, also welches Modul wo und wie positioniert wurde, und hält diese für jeden weiteren Zugriff des Benutzers auf die Portalseite weiter verfügbar.

Abbildung 5.21: Individualisierung von Seiten

115

Sandini Bib 5 Content-Management und Content-Pool

Solche Funktionen sind technisch relativ einfach zu realisieren. Es muss darauf geachtet werden, dass die Profildaten gemäß des WebFarm-Standards im LDAP-Server der Lokation der Anwendung abgelegt werden, sofern dies realistisch umsetzbar ist. Eine solche Individualisierung kann für Navigationen, Informationen und kleine Anwendungen eingerichtet werden. Diese Seiten verweisen dann auf Inhalte, die auf dem Server standardisiert vorhanden sind oder durch die Anwendung standardisiert angeboten werden. Es werden also nicht wie im Fall der nach Gruppen individualisierten Websites komplett individualisierte Seiten und Strukturen erzeugt, sondern lediglich individualisierte Zugänge zu ohnehin vorhandenen Informationen. Mit der Erstellung einer »My-*«-Seite für die Benutzer bietet man den Benutzern eine Möglichkeit, einen individuellen Zugriff auf eine Anwendung zu gestalten. Ein Benutzer richtet sich sein eigenes Portal in die Module und Informationen einer Anwendung ein. Diese Methode wird nach dem WebFarm-Standard verwendet, wenn eine informations- und modulreiche Anwendung von Benutzergruppen mit stark differierenden Informationsbedürfnissen genutzt wird. Dabei sind die Inhalt der Anwendung für alle Benutzer grundsätzlich interessant, nur die Häufigkeit des Abrufs einzelner Module und Informationen variieren von Benutzer zu Benutzer, so dass sich eine vom Benutzer individuell erstellte Navigation und ein individuell konfiguriertes Zugangsportal für den Benutzer in zusätzlichem Komfort ausprägen. Profiling – Verhaltensanalyse und Empfehlung Die Individualisierung durch das Verhalten von Benutzern ist der Teil der Personalisierung, der den Hype für One-on-One im Internet ausgelöst hat. Hierbei wird das Verhalten eines Benutzers auf der Seite analysiert und in Vergleich zum Verhalten anderer Benutzer gesetzt. Daraus können Navigationen, Links und Inhalte generiert werden. Generell kann man diese Art der Personalisierung auch technischer beschreiben, indem man von »Empfehlungen« oder einer »Recommendation Engine« spricht. In vielen bekannten Angeboten wird dieses Werkzeug verwendet, um CrossSelling zu betreiben bzw. um Benutzer einen komplexen Site bzw. einen Site mit sehr viel Inhalt anhand von Erfahrungswerten anderer Benutzer navigieren zu lassen. Wichtig hierbei ist, dass diese Art der Individualisierung nur begrenzten Einfluss auf die Darstellung der Sites für den Benutzer hat, es wird vor allem die Navigation und Vernetzung der Seite individualisiert. Bei großen Sites oder bei Sites, die stark vom Benutzerverhalten geprägt sind, ist eine solche Empfehlungs-Policy auf jeden Fall sinnvoll.

116

Sandini Bib Personalisierung und Profiling-Datenbanken

Abbildung 5.22: Beispiel einer Website, die Profiling verwendet

Der Einsatz einer Recommendation-Engine bedeutet, dass Daten über das Verhalten von Benutzern gesammelt werden, also auf welche Seiten der Benutzer in welcher Reihenfolge zugreift. Es ist zu beachten, dass je nach Verwendung der Daten das Datenschutzgesetz und/oder die betriebliche Mitbestimmung berührt werden und darum entsprechende rechtliche Vermerke anzubringen sind. Wichtig ist, dass eine Profilpersonalisierung erst aktiviert wird, wenn bereits Profildaten gesammelt wurden, damit sinnvolle Empfehlungen gegeben werden können. Nach dem WebFarm-Standard wird diese moderne Methode zur Individualisierung bei großen Sites mit interessensorientierten Inhalten verwendet, bei denen es sinnvoll erscheint, Benutzer mit dem Verhalten anderer Benutzer zu beraten.

117

Sandini Bib 5 Content-Management und Content-Pool

Selbstverständlich kann auf die grundsätzliche Empfehlungsstruktur eingewirkt werden, damit z.B. bestimmte Marketingaktionen unterstützt werden, es muss aber sparsam mit diesen Einwirkungsmöglichkeiten (also wirklich nur für konkrete Aktionen) umgegangen werden, da sonst der Mehrwert für den Benutzer verloren geht.

5.9.2

Erzeugung von individualisierten Anwendungen nach Gruppen

Die Erzeugung von nach Gruppen individualisierten Anwendungen ist nach der Implementierung des im WebFarm-Standard vorgesehenen ContentManagements sehr einfach möglich. Mit der im WebFarm-Standard enthaltenen Software zum Management von Content-Pool und der Redaktionssoftware für statischen Content können problemlos aus einem Pool mehrere Applikationen mit unterschiedlichen Strukturen und Layouts versorgt werden. Dieses Vorgehen ist eine normale Konfiguration der Systeme und daher nicht als gesondertes Projekt zu betrachten, lediglich das Layout der Systeme und deren Struktur sind neu zu erstellen. Die anfallenden Kosten sind in der Versorgung solcher Applikationen zu betrachten und umfassen neben eventuell einzusetzender Hardware die Lizenzen des HTTP-Servers und des Content-Management-Systems. Eigene Hardware ist für eine größere Applikation unabhängig vom Standort sinnvoll und sollte auf jeden Fall eingeplant werden. Soll eine Applikation quasi als Intranet bei Partnern oder Kunden fungieren und ist damit außer Hause, ist auf jeden Fall eine eigene Hardwareanschaffung für die Anwendung erforderlich. Kleinere individualisierte Anwendungen können als virtuelle Webserver auf bereits bestehender Hardware platziert werden. Erzeugung von »My-*«-Seiten Die so genannten »My-*«-Seiten sollten, wie oben beschrieben, immer dann eingerichtet werden, wenn eine Site sehr groß und gut strukturiert ist, und zusätzlich alle Daten für einen Benutzer interessant sein können und der Benutzer selbst erkennen kann oder wissen muss, welche Daten für ihn besonders relevant sind, um deren Sofortanzeige bzw. eine einfache Navigation zu bestimmten Inhalten einer Anwendung über das »My-*«-Portal zu individualisieren. Für die Erstellung von »My-*«-Seiten stehen einige Werkzeuge zur Verfügung, die im WebFarm-Standard auch aufgenommen sind. Es ist aber oft der Fall, dass hier für eine Anwendung kleine individuelle Lösungen auf Basis des Content-Management-Systems geschaffen werden, die durchschnittlich

118

Sandini Bib Personalisierung und Profiling-Datenbanken

mit unter 500 Zeilen Programmcode abzudecken sind. Es ist also durchaus möglich, hier eine Eigenentwicklung, wenn das Anwendungsdesign dies verlangt, zu platzieren, vorausgesetzt das Content-Management-System wird als Lieferant für Informationslokationen usw. eingesetzt. Ist dies nicht der Fall, entspricht die Entwicklung nicht dem WebFarm-Standard, da zusätzlicher, unnötiger Pflegeaufwand nur für die »My-*«-Seiten entsteht, der durch Infrastrukturmaßnahmen der WebFarm-Konstruktion abgedeckt wird. Verwendung von »Recommendation Engines« Die schwierigste und letzte Stufe der Individualisierung ist der Einsatz von »Recommendation Engines«, die den One-on-One-Boom bei Webanwendungen ausgelöst haben. Der Einsatz solcher Werkzeuge ist bei Cross-Selling-Ansätzen durch Intensivierung der Produkt- oder Informationskenntnisse bei Anwendern oder zum kontaktfreien Erfahrungsaustausch zwischen globalen Nutzern und Nutzergruppen sehr gut geeignet. Damit eine Empfehlung sinnvoll ausgesprochen bzw. dargestellt werden kann, muss der Inhalt der Anwendung strukturiert organisiert sein. Das bedeutet der Baum der Anwendung muss in den Blattknoten gruppierbare oder ähnliche Informationen enthalten, denn nur dann macht eine Empfehlung auf Ebene von Informationen Sinn. Anderenfalls ist eine Empfehlung lediglich auf das Navigationsverhalten von Benutzern ausgelegt, was für die Benutzer beschränkt interessant ist, für den Anwendungsbetreiber aber alle Aspekte von Cross-Selling deaktiviert. Wird also eine Anwendung eingerichtet, die diesen Anforderungen entspricht, schlägt der WebFarm-Standard die Verwendung von Personalisierungssoftware, sprich »Recommendation Engines«, vor. Die Infrastruktur einer WebFarm-Lokation sieht einen Personalisierungsserver vor. Auf diesem Server befindet sich eine zentrale »Recommendation Engine«, die von mehreren Anwendungen verwendet werden kann. Dieses Vorgehen wird einerseits eingesetzt, um die Kosten für die Softwareanschaffung möglichst niedrig zu halten, und andererseits, weil auf diese Weise, wenn es von den Anwendungen gewünscht wird und dementsprechend in die Empfehlungsregeln eingebunden wird, eine Policy von Empfehlungen über den Horizont einer Anwendung hinaus gegeben werden kann. Auf diese Weise entsteht durch das reine Benutzerverhalten, das durch die Verwendung von Directories, wie sie im WebFarm-Standard definiert ist, über Anwendungen hinweg verfolgt werden kann, und dementsprechend zu anwendungsübergreifenden Benutzerprofilen führt, eine Vernetzung zwischen mehreren Anwendungen einer WebFarm-Lokation, die durch herkömmliches Linkage nie zu erreichen ist.

119

Sandini Bib 5 Content-Management und Content-Pool

5.9.3

Aktivierung der Empfehlungen

Die Aktivierung der Empfehlungen und die Aktivierung des Lernens der »Recommendation Engine« ist ein sehr entscheidender Prozess, bei dem häufig Fehler gemacht werden. Zur Profilfindung wird das Benutzerverhalten analysiert und in einem Profil abgelegt, dieses Profil beinhaltet selbstverständlich nicht alle vom Benutzer vorgenommenen Aktionen, sondern eine mathematische Abbildung des Benutzerverhaltens, die mit jedem neuen Besuch des Benutzers in der Anwendung aktualisiert wird. Aufgrund dieses Lernverhaltens ist die Darstellung des Profils bzw. die Kurve, auf der sich ein Profil bewegt, ein so genanntes chaotisches Attraktorensystem (Lorenzspirale), das sich auf einen bestimmten Punkt nach einer chaotisch oszillierenden Lernphase einschwingt. Soll nun ein bereits eingeschwungenes Profil, weil sich das Benutzerverhalten oder die Anwendung verändert hat, geändert werden, so ist der Vorgang des neuen Einschwingens zeitintensiver als die erste stabile Profilfindung.

120

Sandini Bib Personalisierung und Profiling-Datenbanken

Unter Umständen kann sogar ein oszillierendes System entstehen, in dem gar kein stabiles Profil für einen Benutzer mehr gefunden werden kann. Es ist zu vermerken, dass die Wahrscheinlichkeit eines solchen Problems sehr gering ist und durch die beschränkte Datendichte in einer »Recommendation Engine« auch alte Daten des Benutzerprofils aus der Betrachtung entfallen und darum neue Parameter für die Lernkurve entstehen. Die Betrachtung oszillierender Lernsysteme hat daher für den Fall der »Recommendation Engines« im Webbereich eher akademischen Charakter und muss bei der Entwicklung WebFarm-konformer Anwendungen gar nicht beachtet werden. Aufgrund dieses Verhaltens der Lernkurven ist der Zeitpunkt der Aktivierung des Profiling und danach der Aktivierung der Empfehlungen in der Anwendung wichtig. Die Empfehlungen müssen auf jeden Fall nach dem Profiling aktiviert werden, der Abstand hier sollte so groß sein, dass mindestens 15% der erwarteten Benutzerzahl mindestens zehn User-Sessions im Server hatten, damit für die 85% zu lernenden Profile eine Basis besteht.

121

Sandini Bib 5 Content-Management und Content-Pool

Das Profiling sollte nicht direkt nach dem Launch der Anwendung gestartet werden, da in einem solche Fall nicht das eigentliche Informationsverhalten der Benutzer, sondern nur das Lernen, die Anwendung selbst zu benutzen, sprich die Navigation in den Benutzerprofilen gespeichert wird. Es sollte also zunächst eine Benutzerbasis bestehen, dann das Profiling aktiviert werden und erst im dritten Schritt auch tatsächlich Empfehlungen in die Seiten integriert werden.

122

Sandini Bib

6

Suchmaschinen

Mit der Informationsfülle des Internets und mit der zunehmenden Informationsdichte der Intranet- und Extranet-Anwendungen in global operierenden Unternehmen wird die Informationsflut für Mitarbeiter und Partner immer größer, was das Lokalisieren interessanter und wichtiger Informationen exponenziell wachsend erschwert. Aus diesem Grund sind die heute im Internet am häufigsten abgerufenen Seiten Suchmaschinen wie Yahoo, Lycos, Excite usw., die dann ihrerseits wieder auf andere fachorientierte Seiten verweisen. Bei den erwähnten Dienstleistungen handelt es sich um allgemeine Suchmaschinen, die den Versuch unternehmen, das gesamte Internet zu indizieren. Zusätzlich verfügt heute jede größere Webanwendung über eine eigene Suchmaschine, die speziell auf die Bedürfnisse und Struktur der Anwendung angepasst ist und das Suchen innerhalb des vordefinierten Bereichs der Anwendung ermöglicht. Die allgemeinen Suchmaschinen hingegen ermöglichen es, Wissen grob zu lokalisieren, um dann von dieser Lokation aus die Suche in der Anwendung oder dem Informationssystem selbst zu vertiefen. Es ist sinnvoll, die Ansätze, die im allgemein zugänglichen Netz üblich sind, auch auf interne oder externe Ansammlungen von Webanwendungen in einem Unternehmen anzuwenden, wenn dort die Informationsdichte, was anzunehmen ist, ebenfalls über das normale, überschaubare Maß hinausgeht. Der WebFarm-Standard definiert aus diesem Grund zwei Elemente für die Einführung von Suchdiensten. Einerseits die Einführung eines globalen Suchdienstes für eine WebFarm-Lokation und andererseits die Einführung eines Suchdienstes für einzelne Webanwendungen ohne anwendungsübergreifende Inhalte. Dieses Dokument befasst sich mit der übergreifenden Suchfunktionalität in einer WebFarm-Lokation.

6.1

Suchverfahren

Für die Suche von Informationen werden die unterschiedlichsten Verfahren eingesetzt, die alle für bestimmte Anwendungsgebiete entwickelt wurden und entsprechende Vor- und Nachteile in einem allgemeinen System haben. Im Folgenden wird kurz auf die verschiedenen gängigen Oberverfahren eingegangen.

123

Sandini Bib 6 Suchmaschinen

6.1.1

Volltextsuche

Bei einer Volltextsuche wird ein Dokument, was in den Suchindex aufgenommen wird, Wort für Wort indiziert, und es ist später möglich, einzelne im Text vorkommende Wörter und Wortkombinationen zu suchen. Dabei ist es offensichtlich, dass die Indizes bei geringen Dokumentenmengen mindestens genauso viel Platz wie die Dokumente selbst verbrauchen. Dokument 13

Dokument 11

Dokument 12

Dokument 9

Dokument 10

Dokument 8

Dokument 6

Dokument 7

Dokument 5

Dokument 4

Dokument 2

Dokument 3

Dokument 1 Wort 1 Wort 2 Wort 3 Wort 4 Wort 5 Wort 6 Wort 7 Wort 8 Wort 9 Wort 10 Wort 11 Wort 12 Wort 13

Abbildung 6.1: Indizierung von Wörtern bei Volltextsuche

Ein einfacher Ansatz für eine Volltextsuche sind die so genannte Matrix oder das Reverse-Matrix-Verfahren, bei denen Wörter und Dokumente die Zeilen und Spalten einer Matrix beschriften, die Elemente der Matrix die Häufigkeit des Wortes darstellen und eine Suche über eben die Zeile zur Spalte führt. Moderne Volltext-Suchalgorithmen und Suchmaschinen basieren zum größten Teil auf diesen Verfahren, aber sie besitzen die Möglichkeit, über eine intelligente Vernetzung der Zeilen und Abbildung von Silben und Buchstaben auch Bruchstücke zu erkennen. Volltextsuchen setzen voraus, dass sich der Suchende sehr gut mit der Materie auskennt und nie allgemein gehaltene Anfragen stellt. Aus diesem Grund sind Volltextsuchen im Internet mit zunehmender Dokumentenzahl immer

124

Sandini Bib Suchverfahren

uneffizienter, weil hier zumeist sehr allgemein gesucht wird und dann eine nicht zu bewältigende Fülle an Treffern erscheinen, die das gesuchte Wort bzw. das gesuchte Pattern ganz widerspiegeln. Für die allgemeinen Suchservices in einer WebFarm-Lokation bietet sich eine reine Volltextsuchmaschine überhaupt nicht an. Auch für größere Anwendungen wie zentrale Intranets ist eine Volltextsuche aus den eben beschriebenen Gründen nicht geeignet.

6.1.2

Meta-Suche

Grundsätzlich wird zwischen zwei verschiedenen Typen von Meta-Suchen unterschieden. Auf der einen Seite handelt es sich um Suchmethoden, die sich auf Meta-Informationen in den Dokumenten beziehen, auf der anderen Seite handelt es sich um die Anwendung mehrerer Suchmaschinen auf eine Abfrage und dann eine Suche über deren Ergebnisse. Suche über Meta-Informationen Bei einer reinen Meta-Suche werden nur Meta-Informationen zu einem Dokument betrachtet. Diese Meta-Informationen werden in HTML und XML in speziellen Tags in den Dokumenten hinterlegt. Bei anderen Methoden werden die Meta-Informationen zu einem Dokument eventuell aus einer zusätzlichen Datei oder einer Datenbank extrahiert, was die Verarbeitung natürlich beschleunigt. Prinzipiell funktionieren die Suchverfahren dahinter genau wie Volltext-Suchalgorithmen, nur dass diese eben nicht auf allen Wörtern der Dokumente, sondern nur auf allen Meta-Informationen arbeiten. Durch diesen verringerten Suchraum können auch aufwändigere Suchen, wie z.B. phonetische Suchen eingesetzt werden. Meta-Suchmaschinen sind für den anwendungsübergreifenden Einsatz wesentlich besser geeignet, weil über diese Suchmethode Dokumente, die gefunden werden, nicht über ihre sprachlichen Eigenschaften, sondern über eine Art Stichwortkatalog gesucht werden. Schlagwörter sind oft gut vereinheitlicht und halten auch allgemeinen Anfragen ohne besondere Kenntnis der Materie stand. Suche über mehrere Suchmaschinen Ein im Internet auch häufig angewandtes Verfahren ist die Möglichkeit, eine Suchanfrage an mehrere unterschiedlich funktionierende Suchmaschinen mit unterschiedlichen Indizierungsverfahren und unterschiedlichen Suchalgorithmen zu übergeben und dann eine Suche über die Resultate selbst durchzuführen. Auf diese Resultate kann nun wieder eine Volltextsuche durchgeführt werden, was sicherlich stark verbesserte Ergebnisse liefert. Ein besseres Verfahren ist, die Ergebnisse der einzelnen Suchmaschinen miteinander zu

125

Sandini Bib 6 Suchmaschinen

vergleichen und deren Gewichtungen – Werte, welche die meisten Suchalgorithmen ausgeben, um die Qualität des Suchergebnisses anzuzeigen – in die Bewertung mit einzubeziehen. Ein Treffer, der insgesamt hoch bewertet ist, wird von der Meta-Suche auch wieder hoch bewertet und dementsprechend dem Benutzer präsentiert. Derartige Verfahren nutzen die Vor-, leider manchmal auch die Nachteile verschiedenster Suchmethoden und liefern allgemein sehr gute Ergebnisse. Für den anwendungsübergreifenden Betrieb einer Suchmaschine in einer WebFarm-Lokation bietet sich dieses Konzept an, wenn eine solche MetaSuche auf die einzelnen Suchverfahren der einzelnen Webanwendungen zugreifen kann. Generell ist die Implementierung eines solchen Verfahrens, das auf die Eigenheiten jeder Anwendung eingehen muss, leider mit erheblichem Aufwand versehen und wird darum nur selten umgesetzt.

6.1.3

Retrieval-Engines

Die aufwändigesten, heute vorhandenen Suchverfahren sind die so genannten Retrieval-Engines. Ein solches Vorgehen bedeutet, dass die eingehenden Informationen anhand von Meta-Informationen und vorhandener Klassifizierungsalgorithmen sofort mit anderen Informationen, die bereits indiziert wurden, vernetzt werden und damit über andere Informationen ebenfalls zugänglich werden. Der Vorteil dieses Vorgehens ist, dass sehr komplexe Anfragen an eine solche Suchmaschine gestellt werden können, die dann auf dem Wissensnetzwerk ihres Index arbeitet, um entsprechend miteinander vernetzte Informationen zu finden. Für die eigentliche Indizierung und das Retrieval werden unterschiedlichste Algorithmen aus allen Bereichen der klassischen und modernen Informatik verwendet. Retrieval-Engines sind vor allem sinnvoll einsetzbar, wenn sehr viele sehr ähnliche Informationen aus einem verwandten Fachgebiet miteinander vernetzt und dann über Experten abgefragt werden, die eine Suche genau genug spezifizieren können, um die Möglichkeiten des Werkzeugs auch auszunutzen. Eine solche Retrieval-Engine eignet sich sehr gut für den anwendungsübergreifenden Einsatz in einer WebFarm-Lokation eines Unternehmens. Allerdings ist zu beachten, dass Retrieval-Engines gewöhnlich bisher sehr teuer (eine Installation > 1,5 Mio. DM) sind und darum die entsprechende Software nicht als Bestandteil des Standards definiert wurde.

126

Sandini Bib Arbeitsweise der anwendungsübergreifenden Suchmaschine

6.1.4

KI-basierte Suchansätze

Eine weitere Generation von Suchmaschinen basiert aus Algorithmen, die aus dem Bereich der künstlichen Intelligenz stammen. Diese Suchmaschinen versuchen, zum einen Extrakte aus Passagen der gescannten Dokumente zu bilden und darauf eine Art Meta-Suche durchzuführen, was ein sehr interessanter Ansatz ist, der sich auch für eine anwendungsübergreifende Suche in einer WebFarm-Lokation eignet. Die andere, zweite Generation der KI-basierten Suchmaschinen versucht, eine Suchanfrage semantisch zu verstehen und ebenso die Inhalte der Dokumente, die indiziert sind, semantisch zu analysieren und gegen die Suchanfrage abzuwägen. Die Ergebnisse solcher Suchmaschinen werden immer besser. Diese Suchmaschinen haben den eindeutigen Vorteil, dass Anfragen auch in normaler Sprache unter Verwendung von Synonymen und Akronymen usw. an die Suchmaschine gerichtet werden können. Momentan kommen die ersten, für große Anwendungen konzipierten Suchmaschinen dieser Art auf den Markt. Noch eignen sie sich nicht für den Einsatz als anwendungsübergreifende Suchmaschine in einer WebFarm-Lokation, was sich aber in absehbarer Zeit ändern kann.

6.2

Arbeitsweise der anwendungsübergreifenden Suchmaschine

Eine anwendungsübergreifende Suchmaschine in einer WebFarm-Lokation muss für alle Anwendungen, die indiziert werden sollen, ein einheitliches Vorgehen haben.

6.2.1

Indizierung

Für eine anwendungsübergreifende Suchmaschine ist es wichtig, dass sie bei der Indizierung von Dokumenten wie ein Browser, also wie ein Benutzer, vorgeht und nicht direkt auf die Daten der Anwendungen zugreift, sondern über eine HTTP- oder HTTPS-Verbindung die Anwendung nach der Struktur der Anwendung durchgeht. Dabei bleiben alte Dateien und versteckte oder berechtigungstechnisch eingeschränkte Anwendungsbereiche unberücksichtigt, was eine allgemeine Einsicht in die Anwendung ermöglicht.

127

Sandini Bib 6 Suchmaschinen

Web Application

Web Application

Web Application

Web Application

Ethernet

Search Engine

Storage

Client

Abbildung 6.2: Vorgehen einer Suchmaschine bei der Indizierung

Die Konfiguration der Indizierung ist für die Netzlast in der WebFarm-Lokation und die weitergehende Performance der Anwendungen selbst sehr wichtig. Die Suchmaschine sollte so konfiguriert sein, dass sie keine spezifischen Indizierzeitrahmen hat, sondern kontinuierlich nur den definierten Namensraum durchgeht und dabei zwischen vier und acht Verbindungen gleichzeitig zu einer Anwendung offen hält. Auf diese Weise ist die Indizierung für die Performance und Netzlast nicht dramatisch, und die Suchmaschine an sich kann sehr effizient arbeiten. Sollte die Indizierung für derart viele Anwendungen laufen, dass eine Neuindizierung einer Anwendung nicht in einem akzeptablen Zeitrahmen stattfindet, kann die Verbindungszahl bis 16 erhöht werden. Neue Anwendungen sollten bei der Inbetriebnahme in der WebFarm-Lokation einmal eine Benutzerzugriffs-berechtigung erhalten, bevor sie, komplett manuell initiiert, indiziert werden.

6.2.2

Content-Berechtigungen

Die Berechtigungen von Contents sind für anwendungsübergreifende Suchen sicherlich ein Hindernis. Einerseits möchte man nicht unberechtigten Benutzern Einblick in Contents gewähren, der nicht für ihre Augen bestimmt ist, andererseits ist es wichtig, möglichst viele Contents in die Indizierung der Suchmaschine einzubinden.

128

Sandini Bib Arbeitsweise der anwendungsübergreifenden Suchmaschine

Zugriff geschützt und keine Suchmöglichkeit

Zugriff geschützt, aber Suchmöglichkeit gegeben

Öffentlich

Abbildung 6.3: Content-Berechtigungen

Der verfügbare Content wird aus diesem Grund über das Berechtigungsmodell und damit über das in der WebFarm-Lokation vorhandene Directory in drei Stufen unterteilt. Der öffentliche Content ist hierbei völlig problemlos. Der gelb markierte Content, der in die Suche mit einbezogen wird, ist auf der Anwendung selbst geschützt; alle anderen Contents werden nicht in die Suche einbezogen. Wird ein geschützter Content mit in die Suche einbezogen, ist der Content auf der Anwendung selbst geschützt, das bedeutet, wenn ein Benutzer nach einem Treffer in der WebFarm-anwendungsübergreifenden Suche auf diesen Content zugreifen will, dann wird eine Authentifizierung erforderlich. Es existieren Suchverfahren, welche die Contents aller Anwendungen indizieren und selbst die Berechtigung der Benutzer durchführen können. Diese Verfahren werden für die anwendungsübergreifende Suche in einer WebFarmStandard-Lokation nicht eingesetzt, da sie zu inperformant sind und außerdem der Idee einer anwendungsübergreifenden Suche, nämlich allgemeine Contents für spezifische Suchanfragen zu öffnen, widersprechen. Solche Ansätze werden bei Anwendungen mit großen Berechtigungsverzweigungen in der Anwendung selbst eingesetzt.

129

Sandini Bib 6 Suchmaschinen

6.3

Lokation einer Suchmaschine in einer WebFarm

Die Suchmaschine innerhalb der WebFarm-Lokation ist eindeutig als interner Service definiert, denn sonst ist auch die vorab definierte Content-SicherheitsPolicy nicht anwendbar. Die Lokation des Dienstes in der WebFarm ist nachfolgend dargestellt, sie ist in der DMZ II und hat dort auch lokalen Storage, der sich auf keinen Fall im internen LAN befinden sollte. Web Application

Web Application

Web Application

DMZ I Packetfilter

Web Application

DMZ II Packetfilter

Application Level Gateway

Search Engine

Client

Storage

Abbildung 6.4: Lokation einer Suchmaschine in einer WebFarm

130

Sandini Bib

7

Anwendungsklassifizierung

Webanwendungen wickeln einen großen Teil der tatsächlichen Anwendungsdynamik auf dem Rechner der Webanwendung ab. Auf dem Client wird lediglich Plausibilisierung, Visualisierung usw. durchgeführt. Dies erinnert stark an die Zeiten von Großrechnern, die ebenfalls diesen zentralistischen Rechen- oder Ausführungsansatz hatten. Der Vorteil dieser Vorgehensweise ist, dass die Konfiguration und hardwaretechnische Ausstattung der Clients nicht in den Vordergrund treten können, was den Aufwand für Prognosen über das Anwendungsverhalten und die Benutzerunterstützung minimiert. Die entstehenden Operationen und Zugriffe auf der eigentlichen Maschine der Anwendung sind relativ gut zu ermitteln und zu prognostizieren, so dass hier ein Standard für verschiedene Anwendungstypen geschaffen werden kann. Dieses Dokument definiert, welche Art von Anwendung in welche Kategorie fällt, und wie sich das auf die Hardwareausstattung der für die Anwendung angeschafften Rechner auswirkt. Die in diesem Dokument vorgenommenen Definitionen beschreiben die Klassifikation von Anwendungen im WebFarm-Standard.

7.1

Klassifizierung

Die eigentliche Klassifizierung einer Anwendung hat Auswirkungen auf deren Anforderungen in Hard- und Software, deren Installations- und Betriebspriceing und auf die mögliche Performance der Anwendung selbst. Neben der von der Anwendung benötigten Software und eventueller Hardware, die zwingende Voraussetzung für die Anwendung ist, sind die erwarteten Benutzer und Benutzerzugriffe für die Planung und Dimensionierung der Anwendung entscheidend. Für die Planung weiterhin wichtig sind Verteilungsgrade und Informationsgehalt von Anwendungen.

7.1.1

Software

Die Klassifikation von Anwendungen anhand der benötigten Softwarekomponenten ist sehr einfach und wirkt sich auf die Installationskosten und den Betrieb sowie die eventuell notwendigen Testverfahren aus.

131

Sandini Bib 7 Anwendungsklassifizierung

Standard-Webanwendung Bei einer Standard-Webanwendung wird ein normaler Webserver gemäß dem WebFarm-Standard installiert. Das bedeutet, es wird lediglich die HTTP- oder HTTPS-Server-Software installiert, mit der Möglichkeit, Informationen in einem Dokumentenbaum aufzunehmen und anwendungsspezifische CGIs in einem Binärbaum auszuführen. Die genauen Lokationen und Richtlinien für die Inhalte dieser Verzeichnisstrukturen sind in den WebFarm-Richtlinien zur Anwendungsentwicklung niedergelegt. Neben diesem Standard-Webserver stehen der Anwendung alle Dienste zur Verfügung, die eine WebFarm-Lokation bzw. die globalen Dienste einer WebFarm-Implementierung anbieten. Einige der Dienste, wie das Redaktionsverfahren für Content, müssen verwendet werden, andere, wie z.B. Personalisierung oder der Anschluss an den Content-Pool und somit die Einbeziehung der Anwendung in das Information-Modelling, sind bei der Anwendungsentwicklung definiert worden. Erweiterte Webanwendung Bei erweiterten Anwendungen kommen zu den unter Standard-Webanwendung beschriebenen Installationen weitere im WebFarm-Standard definierte Dienste hinzu, die sich aber nicht auf die gesamte Infrastruktur, sondern nur auf die Implementierung einzelner Anwendungen beziehen. Dies kann z.B. Installation eines Application-Servers, individueller Suchmaschinen, individueller Personalisierung, SSL-Ticketing usw. für eine Anwendung sein. Individuelle Webanwendung Eine individuelle Anwendung hat zunächst die Installation einer StandardWebanwendung. Es können, müssen aber nicht, Komponenten der erweiterten Anwendung hinzugefügt werden, also weitere Dienste, die der WebFarmStandard für die Entwicklung von Anwendungen definiert. Individuell wird die Anwendung durch die Installation eigener Serverkomponenten, sprich Programme, die auf dem Server als eigene Prozesse agieren und dort Funktionen ausüben, oder andere Programme, die von der Anwendung aus oder in Richtung der Anwendung Einfluss auf die Anwendung selbst oder andere Dienste nehmen.

7.2

Hardware

Die für eine Anwendung benötigte Hardware ist stark abhängig von der verwendeten Software und den gleichzeitig und monatlich erwarteten Benutzerzahlen in Durchschnitts- und zu Peak-Zeiten.

132

Sandini Bib Hardware

7.2.1

Eigene Hardware oder virtueller Server

Viele Ansätze gehen heute davon aus, eine möglichst große Maschine anzuschaffen und auf dieser möglichst viele Anwendungen zu vereinigen. Der WebFarm-Standard wählt einen anderen Weg, weil die Idee, eine zentrale Maschine zu betreiben, sehr gravierende Nachteile hat. Der WebFarm-Standard schreibt vor, für jede Anwendung, die über eine »Kleinapplikation« hinausgeht, bzw. für jede Anwendung, die völlig unabhängig zu anderen Anwendungen ist, eigene Hardware zu betreiben. Nach Betrachtungen, die bei der Entwicklung des WebFarm-Standards mit Kunden angestellt wurden, ist die Anschaffung und Pflege der Hardware bei Einzelkomponenten wesentlich günstiger als die Anschaffung und der Betrieb eines zentralen Servers. Vorteile der WebFarm-Architektur

Nachteile einer »Ein-Server«-Strategie

왘 Anwendungen agieren komplett un- 왘 Ausfallgründe und Störungen sind abhängig voneinander mit wesentlich besserer Effizienz nachzuvollziehen und dementspre왘 Der Ressourcenverbrauch einzelner chend zu beheben Anwendungen ist exakt zu verfolgen und dient als Betriebsplanungs- 왘 Anwendungen können miteinander grundlage kollidieren 왘 Die IO-Leistung, und hier auch die Bandbreite des Netzes, ist die entscheidende Größe, nicht die Prozessorleistung und interne Busarchitektur 왘 Beim Ausfall oder »Amoklauf« einer Anwendung werden ALLE anderen Anwendungen beeinflusst 왘 Anwendungen verschiedenster Sicherheitsstufen teilen sich Ressourcen und haben gemeinsame Zugriffe Tab. 7.1: Übersicht Vor- und Nachteile

Virtuelle Server sollten für sehr eng verwandte Anwendungen, wie z.B. Anwendungen, welche die gleichen Datenbestände mit unterschiedlichen Berechtigungen benutzen, verwendet werden. Außerdem sind virtuelle Server für »Kleinanwendungen« einzusetzen, die lediglich eine kleine Funktion haben, wie z.B. die interne Planung von Meetingräumen und dergleichen.

133

Sandini Bib 7 Anwendungsklassifizierung

7.2.2

Cluster

Cluster sollten verwendet werden, wenn es sich um eine sehr stark eingesetzte, nicht Daten generierende Anwendung handelt. Um Cluster auch für Daten generierende Anwendungen einzusetzen, müssen alle Richtlinien der massiv-parallelen Programmentwicklung beachtet werden, die nicht Bestandteil des WebFarm-Standards sein können. Cluster lohnen sich nur für Anwendungen, die konstant unter Hochlast stehen und eine enorm große Benutzerzahl abdecken müssen. Man geht hier von Anwendungen mit 2-10 Mio. Hits pro Tag und mindestens einer Mio. Benutzersitzungen pro Tag aus. Die wenigsten Unternehmen, die Internet nicht als absolutes Kerngeschäft haben, werden diese Methoden für normale Anwendungen einsetzen müssen.

7.2.3

Speicher und Plattenplatz

Eine Standard-Webanwendung kann bis zu einer Mio. Hits pro Tag mit 256 MB-Speicher abwickeln. Werden viele externe Programme aufgerufen, wird der vom WebFarm-Standard empfohlene Speicher auf 512 MB erhöht. Wird ein Application-Server verwendet, verdoppeln sich die Werte. Den benötigten Plattenplatz bestimmt allein die Anwendung. Es muss aber auf jeden Fall auch im Rahmen der K-Fall-Sicherheit darauf geachtet werden, dass das eigentliche Betriebssystem ohne alle für die Webanwendung erforderlichen Daten auf einer separaten Festplatte (nicht nur Partition) untergebracht ist. Für die Platte mit Websoftware und Webanwendungen schreibt der WebFarm-Standard eine Mindestgröße von 9 GB vor.

7.3

Backup, Fallback und K-Fall-Strategien

Durch den WebFarm-Standard wird ein Konzept entwickelt, das es ermöglicht, eine Infrastruktur für Webanwendungen aufzubauen, Entwicklungsrichtlinien für eine reibungslose Entwicklung von Webanwendungen zu geben und organisatorische Maßnahmen zu ergreifen, die eine webfreundliche Unternehmensumgebung schaffen. Dies alles hat zum Ziel, professionelle Anwendungen in den Bereichen der neuen Medien zu entwickeln. Die Entwicklung ist der erste Schritt, aber gerade mit dem wachsenden Anspruch der Benutzer und Partner ist der Betrieb von Webanwendungen und den dazugehörigen Diensten ein entscheidender Faktor. Web bedeutet in den meisten Fällen automatisch eine 24-Stunden-Verfügbarkeit, und dem muss im Betrieb Rechnung getragen werden. Der WebFarm-Standard definiert aus diesem Grund ein Betriebskonzept, das sowohl den Betriebsanforderungen (24/7 mit

134

Sandini Bib Datensicherung

geringen Reaktionszeiten), den Revisions- und Sicherheitsanforderungen des Unternehmens als auch den Anforderungen der Fachabteilungen entspricht. Eine wichtige Grundlage für einen solchen Hochverfügbarkeitsbetrieb ist eine Infrastruktur und eine allgemeine Konfiguration mit einem Backup, FallBack/Fail-Over und einer K-Fall-Konzeption, die diesen Betrieb jederzeit ermöglichen und die Verfügbarkeit der Dienste zu einem Maximum führen. Nachfolgend wird die Infrastruktur für diese Verfahren im WebFarm-Standard definiert.

7.4

Datensicherung

Die Datensicherung ist ein zentrales Thema im Betrieb von Webanwendungen, das leider viel zu oft vernachlässigt wird. Der WebFarm-Standard unterstützt zwei Möglichkeiten der Datensicherung, die auch in Kombination angewendet werden können.

7.4.1

Lokale Datensicherung

Bei der lokalen Datensicherung ist an einen Rechner eine Möglichkeit zur Datensicherung, also ein entsprechendes Peripheriegerät angeschlossen. Nach dem WebFarm-Standard muss ein Backup-Rechner nicht notwendigerweise über eigene Datensicherungskapazitäten verfügen, wenn der Hauptrechner entsprechende Kapazitäten besitzt. Eine lokale Sicherung wird aber auch bei Backup-Maschinen empfohlen. Es wird folgende Sicherungsstrategie verfolgt: 왘 Wöchentlich Full-Backup 왘 Täglich Incremental-Backup 왘 Wöchentliches Wechseln der Bänder 왘 Bandgeneration von erster Woche des Monats wird archiviert 왘 Quartalsweise wird der letzte Backup-Satz als Großvatersicherung archi-

viert

7.4.2

Datensicherung per Serveranwendung

In vielen Unternehmen existiert eine zentrale Lösung zur Datensicherung, oder die Anwendungszahl in einer WebFarm-Lösung ist so groß, dass sich eine zentrale Datensicherung allein für den Komplex einer WebFarm-Lokation wirtschaftlich rechnet.

135

Sandini Bib 7 Anwendungsklassifizierung

Bei einer zentralen Datensicherung ist zu beachten, dass hier unternehmensinterne Datensicherungsrichtlinien beachtet werden müssen. Die Sicherungsstrategie sollte aber auch keinen Fall unter die Strategie der lokalen Datensicherung fallen. Für den Betrieb einer zentralen Sicherungslösung ist zu beachten, dass keine direkten Verbindungen zwischen externen und internen Segmenten der Firewall-Konstruktion einer WebFarm-Lokation bestehen und die Daten deshalb per TCP und auf keinen Fall per UDP übertragen werden müssen. UDP-basierende Sicherungsprotokolle können innerhalb des WebFarm-Standards nicht verwendet werden, ohne sicherheitskritische Auswirkungen zu haben, und werden darum nicht in den Standard aufgenommen. Eine Abwicklung von UDP-basierten Protokollen ist über einen entsprechenden kommerziellen SOCKS-Server denkbar und dann auch gemäß dem WebFarm-Standard korrekt, und da der SOCKS-Server nicht zur normalen Infrastruktur einer WebFarm-Lokation gehört, ist diese Konstruktion nicht direkt aufgeführt. Im Rahmen einer homogenen Sicherungssoftwarelösung ist es aber sicherlich wünschenswert, diese Lösung zu betrachten, wenn im Unternehmen ein UDP-basierendes Sicherungswerkzeug eingesetzt wird. Firewall-Komponenten dürfen nicht an ein zentrales Sicherungssystem angeschlossen werden, sondern müssen lokal gesichert werden.

7.4.3

Kombination von lokaler und zentraler Sicherung

Eine Kombination aus lokaler und zentraler Datensicherung ist natürlich die wünschenswerteste Konfiguration, die allerdings auch die höchsten Kosten verursacht. Generell bleiben alle Aussagen der lokal und zentral orientierten Datensicherungskonzepte bestehen. Die Verwendung von Bändern und Medien kann allerdings näher an deren garantierte Lebenszeit geführt werden, als das bei der reinen Verwendung eines Verfahrens implementiert sein sollte. Sollen die Zyklen vor allem für das Wechseln von Bändern bei der lokalen Datensicherung verlängert werden, wird folgende alternative Strategie definiert: 왘 Alle zwei Tage Full-Backup 왘 Täglich Incremental-Backup 왘 Zweiwöchentliches Wechseln der Medien 왘 Alle sechs Wochen wird der aktuelle Mediensatz archiviert

136

Sandini Bib Datensicherung

Data via WebFarm Infrastructure Distribution to Web Application and Backup Data via Web Application Local Data Commit and Replication to Backup Server

WebFarm Infrastructure

Client Client Internet

DMZ I

DMZ II Application Level Gateway

Packetfilter

Web Server

Web Server Backup

GAN Packetfitler

Web Server

Web Server Backup

Abbildung 7.1: Kombination lokaler und zentraler Sicherung

7.4.4

Fail-Over- und Fall-Back-Lösung

Mit einer der häufigsten Gründe für einen Ausfall eines Dienstes ist der Ausfall irgendeiner Hardwarekomponente beim Rechner, auf dem der Dienst betrieben wird. Jeder Hardwarehersteller bietet aus diesem Grund so genannte High-Availability-Lösungen an, die zwei gleichartige Hardwarekonfigurationen miteinander so verbinden, dass eventuelle Ausfälle abgesichert werden. Der Nachteil solcher Lösungen ist der sehr hohe Preis, denn es müssen zwei gleiche Rechner angeschafft werden sowie die High-Availability-Lösung, die ungefähr noch einmal so viel kostet wie einer der beiden Rechner. Das bedeutet, bei der Investition in ein High-Availability-Set-up muss man mit dem Preisfaktor 3 im Vergleich zur Lösung ohne Backup-Hardware rechnen. Der WebFarm-Standard sieht ein anderes Verfahren vor, weil die Definitionen des Standards eine kosteneffizientere Lösung ermöglichen.

7.4.5

Datenströme

Entscheidend für die Funktionalität der Fail-Over und Fall-Back nach dem WebFarm-Betriebskonzept ist die Verteilung von Daten auf die entsprechenden Anwendungen. Existieren geregelte Datenströme, kann auf die HighAvailability-Lösung verzichtet werden. Voraussetzung hierbei ist, dass es für jede Maschine, die in das Fall-Back-Verfahren integriert werden soll, eine entsprechende Backup-Maschine gibt. Außerdem müssen die Datenströme, die auf die Anwendung gelangen, über die WebFarm-Infrastruktur abgewickelt werden, und die Anwendung muss, wenn sie selbst Daten generiert, gleichzeitig auf der Primär-Maschine und dem Backup-System ablegt werden.

137

Sandini Bib 7 Anwendungsklassifizierung

Data via WebFarm Infrastructure Distribution to Web Application and Backup Data via Web Application Local Data Commit and Replication to Backup Server

WebFarm Infrastructure

Client Client Internet

DMZ I

DMZ II Application Level Gateway

Packetfilter

Web Server

Web Server Backup

GAN Packetfitler

Web Server

Web Server Backup

Abbildung 7.2: Übersicht Datenströme

7.4.6

Fail-Over und Fall-Back

Für das Fail-Over-Konzept des WebFarm-Standards wird auf die Möglichkeiten der TCP/IP-Protokollfamilie zurückgegriffen. Jeder Rechner erhält auf der physikalischen Netzwerkkarte eine IP-Adresse und einen Namen, der sich aus Anwendungen (n=1 ... 2) zusammensetzt. Zusätzlich wird unter der IP-Adresse und damit auch unter dem Namen der Anwendung ein virtuelles Netzwerkinterface definiert, das auf dem Produktionssystem aktiviert und auf dem Backup-System inaktiv ist. Auf beiden Rechnern ist eine Software installiert, die, wenn das virtuelle Interface inaktiv ist, über das Löschen des ARP-Puffer und anschließendes Erzeugen eines ARP-Request für die Maschine mit dem aktiven virtuellen Interface deren Verfügbarkeit von bzw. netzwerktechnische Erreichbarkeit überprüft. Wird die Erreichbarkeit nicht nachgewiesen, so wird das virtuelle Interface aktiviert, und der bislang inaktive Rechner übernimmt die Produktionsfunktionalität Auf diese Weise können nur schwere Hardwareausfälle sowie Probleme im Netzwerk oder der LAN-Komponenten abgesichert werden, was aber für ein automatisches Hardware-Fail-Over ausreichend ist. Zusätzlich kann durch die im WebFarm-Standard definierte Überwachungssoftware der gleiche Mechanismus ausgelöst wird, wenn ein Dienst auf einer Maschine ausfällt und nicht direkt wieder aktiviert werden kann. Zusätzlich wird bei diesem Fall-Back das virtuelle Interface der Produktionsmaschine auf inaktiv geschaltet, damit keine Konflikte entstehen.

138

Sandini Bib Cluster

www-1 10.0.0.1 WWW Produktion www 10.0.0.3 Client www-2 10.0.02 WWW Backup

Abbildung 7.3: Failover und FailBack

7.5

Cluster

Mit zwei gleichen Maschinen und exakt spiegelgleichen Daten ist es selbstverständlich auch möglich, ein Clustering von Anwendungen zu schaffen. Nur sehr wenige Arten von Webanwendungen brauchen tatsächlich ein Clustering. Da die zweite oder die Backup-Maschine im WebFarm-Konzept für die Abwicklung des Pro-Production-Systems und den Redaktionsprozess verwendet wird, was bei einem Cluster nicht mehr möglich ist, muss analysiert werden, ob tatsächlich ein Cluster geschaffen werden soll. Ein einfachstes Load-Sharing kommt zustande, wenn unter einem Namen die beiden tatsächlichen IP-Adressen der Maschinen geführt werden. Fällt dann allerdings eine der Maschinen aus, gehen 50% aller Zugriffe ins Leere. Außerdem ist es keine echte Lastverteilung, weil nicht nach der Aufwendigkeit der Zugriffe unterschieden wird, sondern 50% aller Erstanfragen zur ersten Maschine und der Rest an die zweite Maschine geleitet werden. WWW C 3 WWW C 1

WWW Cluster Manager

Client

WWW C 2 WWW C 4

Abbildung 7.4: Clustering

139

Sandini Bib 7 Anwendungsklassifizierung

Ein echtes Load-Sharing wird erst durch eine Cluster-Verwaltung erreicht. In diesem Fall ist eine Hardwarekomponente als Cluster-Manager designiert, sie kennt die Last der einzelnen Cluster-Rechner und verteilt die Anfragen entsprechend. Weiterentwickelte Cluster-Manager können auch nach Anwendungsarten und Protokollen unterscheiden werden und somit mehrere SubCluster für bestimmte Anfragetypen verwalten.

7.6

K-Fall-Absicherung

Die Absicherung gegen Katastrophen, welcher Art auch immer, ist für kritische Anwendungen, die für das Primärgeschäft erforderlich sind, meistens eine Revisionsforderung. Zudem kommen in vielen Fällen für andere Anwendungsklassen auch gesetzliche Vorschriften zum Tragen, die eine Absicherung gegen Katastrophen verlangen. Als Katastrophe kann irgendein Vorfall definiert werden, der einen Rechner oder gesamte Infrastrukturkomponenten zum Ausfall bringt, so dass durch normale Maßnahmen keine Möglichkeit zur Wiederherstellung der Funktionalität des Dienstes besteht. Sei dies ein Wassereinbruch im Rechenzentrum, eine Naturkatastrophe oder ein Fehler im Stromnetz. Wie weit eine K-Fall-Absicherung gehen soll (Gebäude, Länder, ...), ist eindeutig in den Betriebsrichtlinien festzulegen oder eventuell auch durch entsprechende gesetzliche Regelungen vorgeschrieben.

7.6.1

Räumliche Trennung

Die räumliche Trennung von Produktions- und Backup-Rechner ist die erste Maßnahme zur K-Fall-Absicherung. Es muss dann allerdings gewährleistet sein, dass die Netze beider Standorte miteinander im gleichen Segment verbunden sind. Üblicherweise wird eine solche Verbindung durch eine LWLVerbindung zwischen zwei Gebäuden oder zwei Räumen im Gebäude möglich. Werden zwei komplett voneinander getrennte Lokationen geführt, ist die K-Fall-Absicherung komplexer und kann nicht im selben Netzwerksegment durchgeführt werden. In diesem Fall wird das ARP-basierte Heart-Beat-Protokoll, das im vorangegangenen Kapitel beschrieben wurde, durch ein wesentlich overhead-belastetes Protokoll auf TCP-Basis ersetzt. Dieses Vorgehen wird tatsächlich nur verwendet, wenn die räumliche Trennung der Systeme eine Verbindung der beiden Netzsegmente zu einem Netzsegment unmöglich macht.

140

Sandini Bib K-Fall-Absicherung

WWW

INTRA

WWW bak

FI

Segmen 10.0.0.X

INTRA bak

FI bak

Segment 10.0.0.X

RING Connection Fiber Connector

Fiber Connector

Abbildung 7.5: Räumliche Trennung

Der Sicherheitsstandard bzw. gesetzliche oder unternehmensinterne Vorschriften schreiben die Art der räumlichen Trennung anhand der Art der Anwendungen vor. Es ist grundsätzlich sinnvoll, zwei Räume zu verwenden, die komplett unabhängige Stromversorgung besitzen. Dies ist das Minimum für eine K-Fall-orientierte räumliche Trennung im WebFarm-Standard.

7.6.2

Medienaufbewahrung

Für kritische Systeme, für die eine zusätzliche K-Fall-Absicherung geschaffen werden soll, schreibt der WebFarm-Standard die regelmäßige Erstellung von Eins-zu-eins-Medienkopien vor. Üblicherweise werden hierzu die Systemund primären Datenplatten (auf optionale Daten wird verzichtet) mittels einer Eins-zu-eins-Übertragungssoftware in definierten Zeitintervallen gespiegelt. Für den Zeitpunkt, an dem die Spiegelung stattfindet, wird das Backup-System aktiviert, bzw. verfügt das Primärsystem über kein Backup. Das Zeitintervall sollte mindestens drei Monate betragen, kürzere Intervalle sind besser, können aber oft nicht eingehalten werden. Mit diesen Medien versehen, kann zu jeder Zeit eine gleiche Hardware sofort, also ohne das Einspielen von Backups usw., zu einem Produktivsystem umgewandelt werden. Mit den Hardwarelieferanten müssen entsprechende Verträge geschlossen werden, oder bei einer dritten Partei, die auch für die Aufbewahrung der K-Fall-Medien verantwortlich ist, wird eine kleine Anzahl an Notfallmaschinen hinterlegt.

141

Sandini Bib 7 Anwendungsklassifizierung

7.7

Network-Connectivity

Die gesamte Webinfrastruktur eines Unternehmens beruht auf der Vernetzung des Unternehmens in sich bzw. mit der Außenwelt. Aus diesen Gründen ist eine kurze Betrachtung der Netzstruktur mit entsprechenden Anforderungen Bestandteil des WebFarm-Standards. Nachfolgend wird beschrieben, wann Standorte miteinander verbunden werden, und wie eine Internetverbindung aussehen kann. Aufgrund der Erfahrungswerte, die in die Entwicklung des WebFarm-Standards eingeflossen sind, sind auch Bandbreitenvorschläge beigefügt.

7.8

GAN-Verbindungen Proxy IN

LAN

LAN

Proxy Ext

DMZ II Packetfilter

WorkstationWorkstationWorkstationWorkstationWorkstation WorkstationWorkstationWorkstationWorkstationWorkstation

DMZ I ALG

Internet Packetfilter

Intraproxy

Packet filter

Proxy

LAN

LAN

WorkstationWorkstationWorkstationWorkstationWorkstation WorkstationWorkstationWorkstationWorkstationWorkstation Packet filter

Proxy

LAN

Proxy

Proxy Packet filter

WorkstationWorkstationWorkstationWorkstationWorkstation

LAN

WorkstationWorkstationWorkstationWorkstationWorkstation

Packet filter

LAN

WorkstationWorkstationWorkstationWorkstationWorkstation

Abbildung 7.6: GAN-Infrastruktur

Die benötigten Verbindungen für eine GAN-Infrastruktur hängen selbstverständlich von allen anderen Anwendungen, die über diese Verbindungen gefahren werden, genauso ab wie von den hier beschriebenen Webanwen-

142

Sandini Bib Internetanbindung

dungen. Es gibt verschiedenste Möglichkeiten, ein GAN aufzubauen, hier wird beispielhaft eine hierarchische Organisation aufgezeigt, weil daran die Bandbreitenanforderungen am einfachsten zu demonstrieren sind. Das dargestellte Schema zeigt, analog zur vorgeschlagenen Proxy-Struktur, eine Infrastruktur mit vier Ebenen, wobei die oberste Ebene über einen Internetzugang verfügt. Aufgrund der Proxy-Infrastruktur ist mit einer 64-KBpsAnbindung das Antwortzeitverhalten der meisten Anwendungen auf jeden Fall akzeptabel. Optimal, vor allem wenn auch unbeschränkte private Nutzung der Netzzugänge gestattet ist, ist eine Vernetzung mit 64 KBps auf der untersten Ebene, 256 KBps auf der zweituntersten Ebene, 512 KBps oder bereits 2 MBps zur Zentrale. Die Internetanbindung der Zentrale sollte auf keinen Fall unter 2*2 MBps eingerichtet werden. Sind keine Proxy-Server vorhanden, muss mit einer Bandbreite von 64 KBps pro angeschlossenen Arbeitsplatz gerechnet werden. Ausfallsicherheiten durch Dial-up-Backups oder redundante Leitungen sind hier nicht angegeben, sollten aber generell in der Planung des GAN berücksichtigt werden. Wenn unternehmenskritische Echtzeit-anwendungen in einer GAN-Struktur benutzt werden, ist auf jeden Fall zumeist auch vom Gesetzgeber eine Ausfallsicherheit gefordert.

7.9

Internetanbindung

Eine normale Internetanbindung besteht aus einer Verbindung zu einem Provider. Diese Verbindung kann auf unterschiedliche Weise installiert sein. An Bandbreiten kann man von heutigen Citynetz-Providern alles ab 64 KBps in 64-KBps-Schritten mieten, es ist aber sinnvoll, in den Maßen 64 KBps, 128 KBps, 256 KBps, 512 KBps, 2 MB, 34 MB, 156 MB zu rechnen, da viele Algorithmen mit 64*2n-Bandbreite am besten arbeiten (weitere Zwischenstufen sind möglich).

Internet

Provider Net Packetfilter

Externer Router

Access Router

Backbone Router

Abbildung 7.7: Internetanbindung

143

Sandini Bib 7 Anwendungsklassifizierung

Zur Ausfallsicherheit kann auf jeden Fall eine zweite oder eine Dial-up-Leitung zum Internetprovider geschaltet werden, dies hilft aber nicht, wenn der Provider selbst der Störfaktor ist, was immer wieder vorkommen kann, da die heutigen Providernetze sehr komplex sind und auch dort Wartungsarbeiten durchgeführt werden müssen. Aus diesen Gründen kann ein so genanntes autonomes System (AS) eingerichtet werden, bei dem für die externe DMZ providerunabhängige Adressen (AS-Adressen) vergeben werden und dann der lokale Router direkt an das dynamische Routing der Internetprovider angeschlossen wird. Auf diese Weise ist die Internetverbindung ausfallsicher, und es findet ein Load-Sharing zwischen den beiden Provideranbindungen statt. Ein solcher AS-Aufbau kann mit beliebig vielen Internetprovidern zusammenarbeiten. Je mehr Provider eingebunden werden, desto höher werden die Anforderungen an den internen Router. Es ist wichtig zu beachten, dass die Konfiguration eines AS sehr komplex ist und direkt in das Routing des Internets eingreift. Aus diesem Grund muss vor der Konfiguration entsprechendes Wissen geschaffen werden oder für eine solche Installation eingekauft werden.

Internet

Provider Net Backbone Router

Access Router Packetfilter

Externer Router Provider Net Access Router

Backbone Router

Internet

Abbildung 7.8: Internetanbindung (2)

7.10 Archivierung Archivierung und klassisches Dokumentenmanagement werden im Büroalltag und in der Revisionierung und Prüfung von Unternehmen immer wichtiger. Papierprozesse werden durch diesen Trend Richtung elektronischer Prozesse migriert.

144

Sandini Bib Datentransfer

Es ist auch sehr deutlich, dass Webanwendungen aus dem Experimentierstadium entwachsen sind und heute einen großen Platz in der IT-Strategie eines Unternehmens einnehmen. Aus diesem Grund darf eine Verbindung zwischen den Produktivsystemen der Webanwendungen und den Back-OfficeSystemen der Archivierung nicht vernachlässigt werden. Der WebFarm-Standard konzentriert sich hauptsächlich auf Front-OfficeApplikationen, deren benötigte Infrastruktur, Entwicklung und Betrieb sowie die dafür notwendigen organisatorischen Maßnahmen. Mit dem Anschluss an ein Archivierungs- oder DMS-System wird also eine Verbindung in den Back-Office-Bereich eines Unternehmens geschaffen. Dieses Dokument beschreibt die möglichen Schnittstellen aus einer WebFarm-Lokation zu Archivierungs- und DMS-Systemen.

7.11 Datentransfer Der Datentransfer zu Archivsystemen gestaltet sich aufgrund der Vielfalt von Schnittstellen, die diese unterstützen müssen, sehr einfach. Es werden von der WebFarm-Infrastruktur aus alle Dateien, die in die Archivierung mit einfließen sollen, auf ein entsprechendes System kopiert und von diesem dann über die Dateischnittstelle des Archiv- oder DMS-Systems entgegengenommen. Da alle eingehenden Daten in der WebFarm- über die Administrationsrechner und Servicerechner der WebFarm-Infrastruktur kontrolliert werden, ist das Abgreifen dieser Daten völlig problemlos realisierbar. Wichtig ist, dass nicht Teile der Administrationsstruktur der WebFarmwomöglich über Sicherheitskonstruktionen hinweg »exportiert«, also komplett auf Dateisystemebene zugänglich gemacht werden, wie es von vielen Systemen anfänglich gefordert wird, sondern dass die WebFarm-Administrationsinfrastruktur für die Übertragung der benötigten Dateien an das Archivsystem sorgt. Auf diese Weise ist ein Konflikt zwischen den Abläufen im Archivsystem und den Abläufen des WebFarm-Betriebs nicht möglich, weil die Systeme sich nicht gegenseitig beeinflussen können. Der Datentransfer sollte aus der DMZ II einer WebFarm-Lokation in Richtung des internen Netzes erfolgen. Eine Verschlüsselung ist sicherlich sinnvoll und auch für die Automatisierung zweckdienlich, aber nicht zwingend erforderlich, wenn das Archivsystem entsprechend geschützt ist und nicht über weitere Außenanbindungen angebunden ist oder verfügt.

145

Sandini Bib 7 Anwendungsklassifizierung

Wird der Content-Pool als Datenquelle verwendet, können die Informationen sehr tief gehend weiter klassifiziert und mit Meta-Informationen versehen werden, was eine Weiterverarbeitung im DMS ermöglichen kann.

7.12 Aktualisierungen Aufgrund der sich ständig verändernden Technologie und der verschiedensten Entwicklungen ist der WebFarm-Standard von einigen Vorgehensweisen selbstverständlich auch permanenten Aktualisierungen unterworfen. Der WebFarm-Standard ist so zusammengestellt, dass Technologieänderungen und insbesondere Änderungen in den Entwicklungsstandards für Internet Anwendungen ohne Probleme integriert werden können. Wir sind selbstverständlich jederzeit bemüht diese Neuerungen in den WebFarm-Standard einzuarbeiten. Sie finden aktuelle Ergänzungen sowie weitere Informationen immer unter http://www.arago.de/

146

Sandini Bib

II Anwendungsspezifische Systemarchitektur

Sandini Bib

Sandini Bib

8

Richtlinien für die Implementierung

Nach dem Aufbau der bereits beschriebenen Infrastruktur können Anwendungen in einer Art Massenfertigung in die vorhandene Infrastruktur integriert werden. Hierbei ist es besonders wichtig, dass bei der Implementierung dieser Anwendungen bzw. bei der Installation der Produktionsumgebung auf den WebFarm-Standard geachtet wird, da nur dann eine optimale Zusammenarbeit mit allen Komponenten der Infrastruktur gewährleistet und der volle Nutzen aus dem Standard gezogen werden kann. Der WebFarm-Standard ist kein starres inflexibles Werk, das einem Entwickler eine exakte Vorgehensweise für eine Entwicklung oder gar die explizite Umgebung oder den Stil vorschreibt; Vielmehr gibt der WebFarm-Standard Schnittstellen zwischen Infrastruktur und Entwicklung vor, die einen Hochverfügbarkeitsbetrieb nach dem WebFarm-Modell ermöglichen und durch einen organisatorischen Kontext unterstützt wird.

8.1

Entwicklungsumgebung

Da für die verschiedensten Anwendungen in einer WebFarm-Umgebung üblicherweise unterschiedlichste Programmierer- und Entwicklungsteams sowie verschiedene Gesellschaften beteiligt sind, ist es nicht das Ziel des Standards, diesen Teilnehmern ihren Entwicklungsstil vorzuschreiben. Der WebFarm-Standard trennt die Entwicklungsumgebung der Zulieferer so weit wie möglich von den Produktionssystemen einer WebFarm-Umgebung, auf denen gar keine Entwicklung stattfinden darf. Dabei sind die Infrastrukturmaßnahmen und Standardpakete sowie die vorgeschriebene Software und die Orientierungshilfen für den Entwicklungsstil für die Zulieferer zusammengestellt, so dass diese alle Dienste der WebFarm-Infrastruktur benutzen können und eine einheitliche Systemlandschaft in der Betriebsumgebung einer WebFarm-Lokation entstehen. Für die verschiedenen grundlegenden Entwicklungsprozesse und Anwendungstypen, die entstehen können, ist der Zulieferer frei in der Wahl seiner Werkzeuge. Die Hard- und Softwareempfehlungen, die diesem Kapitel angehängt sind, sind lediglich als Anregungen zu verstehen, mit denen bereits viele erfolgreiche Entwicklungen durchgeführt wurden. Produktionsumgebung und Entwicklungsumgebung sind vollständig voneinander getrennt. Jede Produktionsanwendung hat eine Produktions- und eine Backup-Instanz. Auf der Backup-Instanz wird zusätzlich der fachliche

149

Sandini Bib 8 Richtlinien für die Implementierung

Redaktionsprozess, also die Abnahme des Auftraggebers/der Online-Redaktion für die angelieferten Anwendungsteile durchgeführt. Da die Zulieferer keinerlei Zugriff auf die Produktionsumgebung haben, ist es essentiell, dass diese die Möglichkeit haben, ein Spiegelsystem als Entwicklungssystem zu pflegen, das aber nur für diesen Zulieferer relevante Daten enthält. Um den Zulieferer diese Möglichkeit zu geben, wird das Redaktionssystem für eine Anwendung so konfiguriert, dass alle freigegebenen Pakete, die Bereiche tangieren, auf die der besagte Zulieferer Schreibberechtigung hat, an diesen Zulieferer versendet werden, nachdem sie freigegeben wurden. Der Zulieferer kann so sicherstellen, dass er ein System pflegt, das dem Produktionssystem für die von ihm beeinflussbarer Segmente gleicht. Dies ermöglicht es, bereits in einem frühen Stadium angemessene Test und Performanceuntersuchungen auf Seiten des Zulieferers durchzuführen. Die Entwicklungsplattformen für einzelne Anwendungssegmente können durchaus von der Plattform des Produktionssystems abweichen. So wird z.B. für die grafische Nachbearbeitung von Bildern oft APPLE-Hardware eingesetzt. Der Server, auf dem ein Zulieferer allerdings die Tests für eine Anwendung durchführt bzw. von dem aus Pakete für neue Anlieferungen gepackt und versendet werden, muss dem Produktionssystem zumindest von der Systemarchitektur gleichen, da ansonsten keine aussagekräftigen Tests durchgeführt werden können und diese dann von der WebFarm-Administration aufwändig nachgeholt werden müsse. Die Zulieferer müssen sich zur Durchführung entsprechender Tests verpflichten und in den Vereinbarungen zur Erstellung von Webanwendungen zugestehen, dass Änderungen an den Entwicklungen, die aufgrund der Integrationsfähigkeit in den WebFarm-Betrieb oder die WebFarmInfrastruktur anfallen, vom Zulieferer selbst getragen werden.

8.2

Webserver-Softwaredefinition

Ziel dieses Dokuments ist es, die spezifische Konfiguration, die auf einer Hardwareplattform für das Einrichten eines Webservers und der darauf existierenden Programme und Anwendungen benötigt wird, festzulegen. Dabei werden die Erfahrungen des WebFarm-Systembetriebs als Grundlage für die Definition der WebFarm-Standards verwendet.

8.2.1

Produktklassifizierung bei HTTP-Servern

Die zu treffende Grundsatzentscheidung ist prinzipiell, soll ein kommerzielles oder ein frei verfügbares Produkt als Webserver eingesetzt werden. Hierbei ergeben sich Vor- und Nachteile, die aus geschäftlicher und geschäftspolitischer Sicht abzuwägen sind und die dann für einen Softwaretypen eine klare Präferenz schaffen, der dann auch eingesetzt wird.

150

Sandini Bib Webserver-Softwaredefinition

Eine Mischung ist bei der Trennung von Anwendung in geschäftsrelevante Funktionen und Zusatzfunktionen sicherlich denkbar und kosteneffizient. Ziel muss es hierbei immer sein, für den Systembetrieb eine einheitliche Aufwandsstruktur zu schaffen. Das bedeutet, es kann innerhalb des WebFarmStandards durchaus mehrere Softwaretypen geben, die als HTTP-Server eingesetzt werden, allerdings nur unter der klaren Voraussetzung, dass der Betrieb dieser Server die gleichen Folgekosten hat.

Request

LDAP Module

Network Layer Network Permissions

HTTP Händler

MIME Händler

DB Module

Local Cache

HTML Parser SSI Connector ...

Access Module

Abbildung 8.1: Strukturdarstellung von Webserver-Modulen

8.2.2

Spezifische Webserver im Vergleich zu allgemeinen Webservern

Viele Hersteller von spezifischer Anwendungssoftware bieten heute auch eine HTTP-Integration in ihrer Anwendungssoftware an. Grundsätzlich ist der Einsatz solcher Produkte nicht Teil des WebFarm-Standards und wird darum auch nur in Sonderfällen in einer WebFarm-Lokation eingesetzt. Diese klare Richtlinie zum Einsatz von standardisierten HTTP-Servern ist folgendermaßen zu begründen: 왘 Die vom WebFarm-Standard empfohlenen Server bieten alle offene

Schnittstellen (APIs) und die Möglichkeit an, über Side-Includes oder Module andere Software in den Prozess des HTTP-Serving einzubeziehen

151

Sandini Bib 8 Richtlinien für die Implementierung

und diese zu verwenden. Es entstehen also keinerlei Restriktionen für den Anwender. 왘 Aufgrund der sehr schnellen Weiterentwicklung der Webtechnologie und

den auch ständig steigenden Anforderungen an reine Serverprodukte ist es sinnvoll, hier ein spezialisiertes Produkt einzusetzen, das eben auch allen Sicherheitsanforderungen usw. entspricht. 왘 Server, die als Zusatzfunktion einen HTTP-Server anbieten (z.B. Daten-

bank-App-Server, Corba-App-Server usw.), konzentrieren sich auf ihre eigentliche Serverfunktion und nicht auf die HTTP-Funktionalitäten und bieten daher weniger Flexibilität, Sicherheitsmechanismen, Mechanismen zur Einbindung anderer Produkte usw. 왘 Server, die als Zusatzfunktion einen HTTP-Server anbieten, sind für diese

Zusatzfunktion prioritär in der Benutzung, Entwicklung und im Betrieb und schaffen daher ein schlechteres Betriebseffizienzverhältnis.





  


 Abbildung 8.2: Integrierter und embedded Webserver

8.2.3

Plug-ins, Module und Includes

Zur Erweiterung der Funktionalität eines Webservers, so z.B., um einen Application-Server in den eigentlichen HTTP-Server einzubinden, um eine direkte Datenbankverbindung herzustellen oder um bestimmte Berechtigungsmechanismen zu erwirken, können die im WebFarm-Standard vorgeschlagenen Produkte alle über standardisierte Schnittstellen erweitert werden. Es gibt hierbei die Möglichkeit, direkt die Serversoftware um bestimmte Module zu erweitern oder in die Prozesse der Serversoftware so genannte Server-Side-Includes einzuklinken, mit denen dann an bestimmten vorgesehenen Punkten des HTTP-Serving-Prozesses die entsprechenden Zusatzfunktionen verwirklicht wird.

152

Sandini Bib Webserver-Softwaredefinition

Auf diese Weise ist es möglich, alle vorstellbaren technischen Zusätze in einen HTTP-Server zu integrieren und dabei trotzdem auf einer hochwertigen Serverbasis aufzubauen. Einige typische Beispiele für Plug-ins, Side-Includes und Module, die im WebFarm-Standard eingesetzt werden, sind hier aufgelistet: 왘 Funktionale Berechtigung 왘 Zusätzlich zum Standard-LDAP-Identifikationsmodul erscheint es oft

wünschenswert, andere Gruppen oder Felder der X500-Struktur in die Berechtigung von Benutzern mit aufzunehmen. Dies kann über ein entsprechendes Plug-in geschehen. 왘 SSL-Tickets

Zur verschlüsselten Sicherung der Seitenabruffolge können so genannte SSL-Tickets verwendet werden, die über ein entsprechendes Modul verwaltet und gesteuert werden. 왘 Web-Application-Server

Application-Server wie Cold-Fusion oder Silver-Stream werden über Includes in die Server eingebunden und stellen dann über Parsed-HTML die entsprechenden Funktionen zur Verfügung.

8.2.4

Installation

Grundsätzlich wird im System eine Trennung zwischen Anwendungen, Anwendungsdaten, und von der Anwendung erzeugten Daten gemacht. Die eigentliche Anwendung wird in einem Subtree unter dem /TOP/-Verzeichnis bei Unix-Systemen installiert. Die Anwendungsdaten werden in einem Subtree des /WWW-Verzeichnisses (bei Webservern) auch für andere Anwendungen installiert, und Loginformationen werden in einem Subtree des Verzeichnisses /LOGS unter Unix installiert. Alle diese Oberverzeichnisse werden separaten Datenspeichern oder Partitionen zugeordnet, damit der Einfluss von Anwendung auf Daten und Funktionalität minimiert werden kann und so eine maximale Betriebsbereitschaft entsteht. Basissoftware Die Basissoftware wird z.B. im Falle eines Netscape-Enterprise-Servers unter /OPT/NS-HOME installiert. Dabei wird für jede Instanz darunter ein https-xxxVerzeichnis angelegt. In den jeweiligen Anwendungsverzeichnissen werden die Logverzeichnisse nach /LOGS/XXX verlinkt, damit die angesprochene Systemtrennung gegeben ist.

153

Sandini Bib 8 Richtlinien für die Implementierung

Zusatzsoftware/Anwendungsspezifische Software Zur Template-Installation zählen die, weiter unten beschriebene Basissoftware der WebFarm-Infrastruktur die unter /OP/SWPACKAGE installiert, wobei SWPACKAGE die Bezeichnung der jeweiligen Software darstellt. Eine zusätzliche, von den Anwendungen geforderte Software wird nur dann unter /TOP/SWPACKAGE installiert, wenn es sich um Standardsoftware handelt, die eine Prüfung für die WebFarm-Infrastruktur-Tauglichkeit bestanden hat. Andernfalls wird die Software unter /WWW/XXX-ORIG-SWPACKAGE installiert, wobei xxx die Anwendung bezeichnet, für welche die Software installiert wird, ORIG den Zulieferer, der die Softwareinstallation erlangt hat, und SWPACKAGE die entsprechende Software bezeichnet. Unter Umständen kann der Lieferant auch über das Redaktionssystem bzw. das Content-Pool-System berechtigt werden, neue Versionen bereitzustellen (eine Inbetriebnahme der Applikationen erfolgt allerdings nur unter Kontrolle des Systembetriebs). Es werden zur Installation von Anwendungen folgende Grundsätze innerhalb des Bereichs der Webanwendungen festgelegt: 왘 CGIs:

werden unter /WWW/XXX/CGI-BIN/ORIG/ abgelegt, wobei xxx wieder die Anwendungsbezeichnung und ORIG der Zulieferer ist. 왘 Generierte Daten:

Werden von den Anwendungen Daten auf Platte generiert, so werden diese unter /WWW/XXX/LIB/ORIG abgelegt. 왘 Zusätzliche Daten:

Werden von den Anwendungen zusätzliche Daten benötigt, die nicht im Webtree stehen sollen, so werden diese unter /WWW/XXX/ETC/ORIG abgelegt. WebFarm-Standard-Software Im Rahmen einer WebFarm-Installation wird auf einem Webserver nicht nur die eigentliche HTTP-Serversoftware installiert. Es sind noch einige Standardkomponenten absolut erforderlich, wenn der Rechner später in den Betrieb einer WebFarm-Lokation aufgenommen werden soll. Diese Komponenten sind im Folgenden kurz aufgelistet und werden in den entsprechenden Sektionen der WebFarm-Standardbeschreibung detailliert erläutert: 왘 Überwachungssystem:

Es wird auf jedem Rechner einer WebFarm-Lokation installiert und verbindet diesen Rechner mit dem lokalen Administrationsserver. Die Administrationsserver sind untereinander verbunden und stellen so das Web-

154

Sandini Bib Webserver-Softwaredefinition

Farm-Überwachungsnetzwerk dar. Das Überwachungssystem versucht wie ein Benutzer auf die einzelnen Dienste eines Rechners zuzugreifen und ist dabei gleichzeitig mit den Logdateien des Systems und der jeweiligen Dienste verbunden. Fehler können auf diese Weise sehr schnell erkannt und in den meisten Fällen behoben werden, bevor sie den Benutzern auffallen. Jedes WebFarm-System wird mit der Systemüberwachung vorinstalliert. Für jeden Dienst und jede Zusatzsoftware ist das Überwachungssystem entsprechend zu konfigurieren. 왘 Content-Management-System:

Jeder Webserver benötigt Teile des Content-Management-Systems der WebFarm-Infrastruktur, da über dieses System alle Komponenten des Webservers geliefert werden. Hierbei wird zwischen zwei wesentlichen Teilen, dem Redaktionssystem und dem Content-Pool-System, unterschieden. Die Komponenten der WebFarm-Redaktionsinfrastruktur müssen auf jeden Fall installiert werden, ebenso die für die Softwareverteilung zuständigen Komponenten des Content-Pool-System. 왘 Redaktionssystem:

Jeder Content, der auf einer Webanwendung eingespielt wird, wird über das Redaktionssystem geleitet. Hierbei können externe und interne Zulieferer Inhalte für das Redaktionssystem bereitstellen. Die Zulieferer liefern ihren Content an die zentrale Infrastruktur des Redaktionssystems einer WebFarm-Lokation, diese verteilt den Content dann über das definierte Redaktionsverfahren auf die einzelnen Anwendungen weiter. Bei der lokalen Konfiguration des Redaktionssystems müssen alle berechtigten Benutzer bzw. Rollen in das System eingetragen und die für diese Benutzer möglichen Content-Bereiche im System definiert werden. Diese Angaben sind der Projektdokumentation der jeweiligen Anwendung zu entnehmen. 왘 Content-Pool-System:

Das Content-Pool-System wird einerseits zur Pflege von strukturiertem Content innerhalb der Anwendung verwendet, andererseits wird ein Teil des Content-Pool-System zur Verteilung von Softwarepaketen verwendet. Diese Methodik erlaubt es, die zu installierende Zusatzsoftware auf ein Minimum zu beschränken. Nicht für jedes Websystem ist die ContentPool-Software notwendig, um Inhalte in der Webanwendung zu pflegen. Nicht erforderlich ist sie z.B., wenn es sich nur um einen kleinen, völlig statischen Webauftritt handelt oder wenn es sich um eine reine C/SAnwendung handelt, die keinerlei Bezug zu semi-dynamischen Informationen hat. Der Teil des Content-Pool-Systems, der für die Verteilung von notwendigen Updates verwendet wird, ist aber auf jeden Fall in der Template-Installation eines Webservers einer WebFarm-Lokation enthalten.

155

Sandini Bib 8 Richtlinien für die Implementierung

8.3

Webserver-Hardwaredefinition

In diesem Dokument soll beschrieben werden, welche Hardwareanforderungen für welche Art von Webanwendung als Minimum vorausgesetzt, werden, wie Webanwendungen auf Hardware verteilt oder vereinigt werden und wie diese Hardware dimensioniert wird. Als Beispiel wird mit Sun-Hardware gearbeitet. Eigene vs. Virtuelle Server Eine grundsätzliche Frage für die Hardwareinfrastruktur einer WebFarmLokation ist die Art des Serverbetriebs. Hier gibt es grundsätzlich zwei extreme Ansätze, die für den WebFarm-Standard gemischt wurden. 1. Jeder Anwendung einen eigenen Server Jede Webanwendung, und sei sie auch noch so klein, bekommt ihren eigenen Server. Dabei werden die Vorteile der Hardwareskalierbarkeit nur bei großen Anwendungen genutzt; allerdings gewährleistet dieses Paradigma auch, dass auf keinen Fall das Nichtfunktionieren einer Anwendung auf Hardware- oder Serverebene eine andere Anwendung beeinflussen kann, was für die Betriebsbereitschaft und Verfügbarkeit der Anwendungen für den Benutzer erhebliche Vorteile liefert. 2. Es existieren ein oder mehrere zentrale Server, auf denen möglichst alle Anwendungen liegen. Dieser Ansatz ist der typische Zentralrechneransatz. Es wird eine Hardwareplattform geschaffen, die so leistungsfähig ist, dass alle Anwendungen gleichzeitig auf dieser betrieben werden. Es wird in diesem Falle die maximale Skalierbarkeit der Hardware ausgenutzt, und die Wartung der Systemkomponenten beschränkt sich auf eine Maschine. Dabei ist allerdings zu beachten, dass das Management einer geclusterten oder sehr großen Maschine komplexer ist als das Management einer Einzelmaschine. Der Nachteil dieser Vorgehensweise ist hierbei primär, dass eine Anwendung, die das System beeinträchtigt oder sogar dessen Betrieb stört, alle anderen Anwendungen, die ebenfalls von diesem System abhängen, auch mit beeinflusst, was für die allgemeine Verfügbarkeit von Diensten aufgrund der exponentiellen Abhängigkeitsketten nicht ohne Bedeutung ist. Der WebFarm-Standard mischt diese Paradigmen mit einem besonderen Fokus auf der Betriebssicherheit der einzelnen Anwendungen. Aus diesem Grund wird eine eigene Hardware für eine Anwendung eindeutig bevorzugt. Dies gilt natürlich nicht für kleine Anwendungen ohne Programme, sondern lediglich relativ statischem Informationsinhalt, oder für Anwendungen, die quasi keine Benutzer aufweisen. Solche Anwendungen können z.B. reine Marketingseiten, temporäre Informationen, kleine Rechner usw. sein. Für

156

Sandini Bib Webserver-Hardwaredefinition

diese Webseiten werden keine gesonderten Hardwareanforderungen getroffen, sondern lediglich ein virtueller Server auf einer bestehenden Hardware installiert.

Abbildung 8.3: Webserver-Aufbau

Ansonsten spricht außer massivem Platzmangel oder Problemen mit der Klimatisierung von Rechnerräumen nicht viel dafür, eine zentrale Host-Lösung zu etablieren, denn: 왘 Da bei der Dimensionierung von Serverhardware Peak-Zeiten nicht als

Ausreißer herausgefiltert werden dürfen, sondern durchaus eine wichtige Rolle (durch Mehrfachbewertung) spielen, sind die Leerlaufzeiten, die hier einkalkuliert werden, bei einer zentralen Serverlösung additiv. Es wird also durchschnittlich mehr Rechenleistung brachliegen. 왘 Einzelne Skalierungsschritte bei großen Hardwarekonstruktionen bieten

zumeist keinen Preisvorteil gegenüber der Anschaffung einzelner kleinerer Komponenten, sondern sind eher teurer. 왘 Der Betrieb in der WebFarm-Umgebung ist hoch automatisiert, und

darum entsteht kein Ungleichgewicht, wenn mehrere Systeme systemseitig betreut werden müssen.

8.3.1

Hardwareplattform

Die Hardwarebasis entscheidet im Allgemeinen über die Gesamtperformance der Webanwendungen in einer WebFarm-Infrastruktur. Darum ist eine allgemeine Plattformentscheidung ein Grundsatz für den stabilen Betrieb und die zukunftsweisende Entwicklung im Web-Bereich. Da das Augenmerk der gesamten WebFarm-Konstruktion auf Betriebs- und Ausfallsicherheit liegt, wird bei der Plattformentscheidung auf Erfahrungswerte in diesem Umfang Wert gelegt. Der WebFarm-Standard empfiehlt

157

Sandini Bib 8 Richtlinien für die Implementierung

daher als generelle Plattform für Web Server und Infrastrukturkomponenten eine UNIX-Plattform. Diese Entscheidung liegt in den gesammelten Erfahrungen mit Betriebssicherheit (Anzahl gefundener Sicherheitslücken und notwendiger Nachbesserungen), Stabilität und Performance begründet. Bei der Auswahl der spezifischen Plattform ist der Hausstandard zu berücksichtigen. Es ist allerdings offensichtlich, dass die Webtechnologie sehr schnelle Entwicklungszeiten hat und der Einsatz moderner Technologie durchaus maßgeblich am Erfolg einzelner Webanwendungen beteiligt ist. Es ist darum wichtig, eine Plattform für allgemeine Anwendungen zu wählen, die auch als Entwicklungsplattform für moderne Anwendungen gesehen und eingesetzt wird, und nicht nur ein Portierungsziel ist. Für spezifische Aufgaben wie z.B. Datenbanken ist auch der Einsatz einer anderen Plattform denkbar. Die Homogenität kann dann aufgelöst werden, wenn sich ein wesentlich besseres Preis-Leistungsverhältnis bietet oder andere Optionen wie Skalierbarkeit für eine Anschaffung in die Heterogenität aussprechen. Der wichtigste Grundsatz, wenn innerhalb einer WebFarmInfrastruktur ein heterogenes Netz betrieben wird, ist, dass die Betriebskosten für die einzelnen Komponenten gleicher Art, seien sie von welcher Plattform auch immer, sich nicht unterscheiden. Sobald die Betriebskosten einer Plattform andere übersteigen, ist dies in die Effizienzrechnung vor der Anschaffung einzubeziehen. Auf der anderen Seite sollten Preis- und Entwicklunsvorteile, die durch das Schaffen einer heterogenen Umgebung ausgearbeitet werden können, nicht zu Gunsten einer IT-technisch »schönen« oder »eleganten« homogenen Lösung nicht wahrgenommen werden.

8.3.2

Hardwaredimensionierung

Die eigentliche Dimensionierung der Hardware ist in den meisten Fällen nicht besonders komplex. Für normale Webanwendungen stehen folgende Systembereiche zur Dimensionierung an: 왘 Festplatten/Datenspeicher:

hierbei ist nicht nur der Gesamtplatz, sondern im Fall von stark belasteten Servern oder Clustern auch die Verteilung auf verschiedene Controller zu beachten. 왘 Arbeitsspeicher

der Arbeitsspeicher ist ein wesentlicher Faktor, da es im Webbetrieb nach dem WebFarm-Konzept, in dem On-the-Fly-Generierungen möglichst vermieden werden, um das effiziente Ausführen von Programmen und das Durchstreichen von Seiten geht.

158

Sandini Bib Webserver-Hardwaredefinition

왘 Rechenleistung/CPU

ist der an sich unkritischste Teil der Dimensionierung für Webanwendungen, da lediglich aufwändige Anwendungen sehr viel CPU verbrauchen, IO ist eher der Engpass. Festplatten/Massenspeicher Grundsätzlich ist die Basisinstallation des Systems und die Installation der Webumgebung mit allen Komponenten, die in der WebFarm-Infrastruktur benötigt werden, außer dem Betriebssystem an sich voneinander tatsächlich physikalisch zu trennen, um eine Massenproduktion von reinen Basissystemen zu ermöglichen. Das bedeutet also, ein System muss auf jeden Fall zwei Festplatten haben. Dabei muss die erste Systemplatte groß genug sein, um das System mit allen Komponenten und den temporären Speicherplatz zu halten. Gewöhnlich sind hier 4 GB ausreichend, allerdings ist heute mit mindestens 9 GB- Festplatten zu rechnen, da kleinere Platten nur noch auf Anfrage erhältlich sind. Die zweite Platte sollte dann genügend Platz für die Software und die Daten bieten, die für eine Webanwendung benötigt werden. Generell sollte diese Festplatte nicht unter 9 GB dimensioniert werden. Es muss immer damit gerechnet werden, dass an einem Tag für eine viel verwendete Webanwendung ca. 1 GB Logdateien anfallen können, da die statistischen Auswertungen die maximale Anzahl an Loginformationen benötigen. Zusätzlich benötigt die Software ca. 1 GB. Deren Daten können bis zu 500% des aktuellen Contents einer Webanwendung betragen. Die Webanwendung selbst benötigt wiederum zwischen 100 MB und 2 GB, je nach Informationsvolumen. Nur sehr wenige Anwendungen kommen über ein Informationsangebot von 2 GB hinaus. Es ist bei datengenerierenden Anwendungen oder Anwendungen, die eine große eigene Datenbasis oder entsprechend große Programme haben, davon auszugehen, dass für diese allein ca. 4 GB zu rechnen sind. Aus diesen Überlegungen kann man sagen, dass mit der vorgeschlagenen zweiten 9 GB-Platte ca. 80% aller Webanwendungen abgedeckt werden können. Bei sehr stark frequentierten Anwendungen ist die IO zwischen Web Server und Festplatte entscheidend, es sollte daher mindestens ein System von zwei Festplatten angeschafft werden, auch wenn diese nicht komplett ausgelastet werden, das auch über zwei Controller auf diese Platten zugreift, weil sich auf diese Weise zumindest eine theoretische Lesegeschwindigkeit von 88 MB/s verwirklichen lässt.

159

Sandini Bib 8 Richtlinien für die Implementierung

Arbeitsspeicher Die Dimensionierung des Arbeitsspeichers hängt sehr stark von der Anwendung ab. So ist davon auszugehen, dass das System alleine mindestens 64 MB Speicherbedarf hat. Für jeden simultanen Zugriff auf das System sollte mit einem Speicherbedarf von 2 bis 8 MB ausgegangen werden. Das bedeutet, dass bei 64 gleichzeitigen Zugriffen und einem Grundbedarf von 128 MB mindestens 256 MB Speicher nur für den HTTP Server zur Verfügung stehen muss. Üblich sind heute auch Konfigurationen von 1GB oder mehr, weil von einer großen Benutzeranzahl ausgegangen wird. Kein Server sollte mit weniger als 128 MB ausgestattet werden. Werden nicht nur HTTP Server, sondern auch CGIs, Application Server, usw. betrieben, ist die Rechnung zu erweitern. Bei CGIs ergibt sich der durchschnittliche Speicherbedarf aus durchschnittlicher Programmgröße mal Anzahl simultaner Benutzer. Bei Application Servern ist von 100 MB für die Basisinstanz und 2 MB pro Benutzer zu rechnen. Rechenleistung CPU Es sollten auf jeden Fall schnelle Prozessoren verwendet werden, weil diese die allgemeine Performance beim Starten und Ausführen von Prozessen beschleunigen. Es ist bei einer Webanwendung davon auszugehen, dass sehr viele Prozesse oder Threads bedient werden müssen, da für jeden neuen Benutzer und jede neue Seite ein Thread oder Prozess benötigt wird, der neu entsteht oder zumindest neu initialisiert werden muss. Der Grad der Parallelisierbarkeit ergibt sich aus der Anzahl gleichzeitiger Benutzer und deren gleichzeitigem Zugriff auf die gleiche Systemressource und deren Parallelisierbarkeit. Zum Beispiel ist der Zugriff auf eine Festplatte bereits mit 45 MB/s theoretischer Obergrenze beschränkt, der Zugriff auf eine Datenbank durch die Performance der Datenbankmaschine und der Netzanbindung. Steht z.B. nur eine Netzwerkkarte zur Verfügung, kann man bei einer ausgelasteten Anwendung von 75% ausgehendem Traffic und 25% eingehenden Verbindungen durch Datenbankabfragen rechnen. Für Standardanwendungen ist auf jeden Fall eine CPU ausreichend. Werden viele Programme ausgeführt, daher viele Funktionen gleichzeitig verwendet (Application Server) oder bestehen sehr viele Verbindungen nach außen, sollte auf eine Zwei-Prozessor-Maschine vergrößert werden. Mehr als 4 Prozessoren werden auch für sehr große Anwendungen nicht in einer Maschine verwendet. Es bietet sich an, wenn mehr Rechenleistung benötigt wird, eher einen Cluster einzuführen.

160

Sandini Bib Webserver-Hardwaredefinition

Andere Komponenten Auch andere Komponenten bieten eventuell Potential zur Optimierung bei wirklich ausgelasteten Systemen. Es kann vorkommen, dass ein System von der Netzwerklast her keine weiteren Zugriffe erlaubt, weil sehr viele Daten zwischen Benutzer und System und zwischen System und externen Datenquellen transportiert werden. In diesem Fall wird eine zweite Netzwerkkarte, die lediglich eine Verbindung zu den externen Datenquellen besitzt, in das System eingebaut werden. Zu beachten ist hierbei, dass das Routing deaktiviert werden muss, so dass nur das System selbst, nicht aber ein Benutzer über das System auf die Datenquellen zugreifen kann. Solche Maßnahmen werden erst erforderlich, wenn eine Anwendung mit Benutzerzahlen, die in die Millionen gehen und auf Datenbanken zugreifen, geschaffen werden soll. Es sollte auf keinen Fall eine Anwendung überdimensioniert werden.

8.3.3

Cluster-Lösungen

Cluster-Lösungen werden heute eher eingesetzt, als die Hardware maximal zu skalieren. Cluster-Lösungen bieten für große Anwendungen den entscheidenden Vorteil, dass sie sowohl Ausfallsicherheit als auch nahezu beliebige Skalierbarkeit erzeugen.

Abbildung 8.4: Cluster-Lösung

161

Sandini Bib 8 Richtlinien für die Implementierung

Das WebFarm-Konzept schreibt ohnehin die Verfügbarkeit von einem Server inklusive einer baugleichen Backup-Maschine vor. Aus diesen Systemen kann ohne Änderungen am Konzept ein zweiter Maschinen-Cluster erzeugt werden, der dann allerdings nicht spezifisch gemanagt wird. Für große Anwendungen können Cluster mit 4, 8, 16 oder 32 Maschinen erzeugt werden. Mehr als 32 Maschinen können nur noch in einer Cluster-Umgebung gemanagt und gleichzeitig betreut werden (absolut synchrone Datenbestände). Alles bis 32 Maschinen kann durch die normalen Redaktions- und Verteilungsmechanismen des WebFarm-Konzepts verwaltet werden. Es ist offensichtlich, dass Anwendungen in einem Cluster backupfähig sein müssen, das bedeutet sich nicht auf den eigenen Maschinennamen verlassen, redirected werden können usw. Diese Anforderungen bestehen seitens des WebFarm-Standards aber sowieso an Entwicklungen, da nur auf diese Weise eine Betriebssicherheit im gewünschten Umfang erreicht werden kann.

162

Sandini Bib

9

Application-Server

Application-Server und Application-Serving sind Schlagwörter der weborientierten IT geworden. An vielen Stellen wird zwischen allgemeinen WebApplication-Servern und anwendungsspezifischen Application-Servern unterschieden. Dabei bieten die allgemeinen Web-Application-Server eine Integration für die Programmierung beliebiger Webanwendungen, und die für Applikation spezifischen Server beziehen ihre Funktionalität auf eine bestimmte Anwendung oder einen bestimmten Dienst, der über das Plug-in des Application-Servers webfähig gemacht wird (z.B. Application-Server, die in Datenbanken direkt integriert sind, oder Application-Server, die in Middleware-Produkte integriert sind). Die allgemeine Webentwicklung bietet eine große Anzahl an Redundanz. Das bedeutet, es wurden oder werden immer noch und immer wieder die gleichen Programmieraufgaben gelöst, wobei die beiden häufigsten im Zusammenhang mit Webanwendungen sicherlich das Halten eines Zustands (State) sowie der Zugriff auf Datenbanken sind. Dieses Dokument beschreibt die Auswahl der Application-Server für den WebFarm-Standard, die daraus resultierenden Vor- und Nachteile sowie die Einsatzgebiete und Nicht-Einsatzgebiete und die Schulungserfordernisse der empfohlenen Application-Server. Dieses Dokument fokussiert sich auf die allgemeinen Web-Application-Server, da diese wesentlich mehr Relevanz bei der Entwicklung oder Standardisierung von Webanwendungen haben als spezifische und da diese direkt eine effizientere Entwicklung ermöglichen.

163

Sandini Bib 9 Application-Server

9.1

Funktionen eines Application-Servers

Browser Enter URL DNS Lookup

Server

Connect

Accept

Send Requested URL

Interpret URL CGI?

Interpret CHAR Stream

Read Transmission

Transmit Output

ReadFile

Execute CGI

Display PAGE Abbildung 9.1: Übersicht Application-Server

Das grundsätzliche Problem bei Webanwendungen ist das Halten des Zustands. Dies hört sich übermäßig einfach an, verursacht aber den größten Entwicklungs- und Performance-Overhead, den Webanwendungen überhaupt enthalten. Das Problem liegt darin, dass das Hypertext-Transfer-Protocol (HTTP) eine Verbindung aufbaut, einmal Daten vom Client an den Server überträgt, dem Server eine gewisse Bearbeitungszeit einräumt und, falls vorhanden, die entstandenen Ergebnisse an den Client zurückliefert. Nach einem solchen Zyklus sind Server und Client sich gänzlich unbekannt. Das bedeutet aber, dass es Sache der Applikation selbst ist, den Zustand eines bestimmten Clients zu speichern, diesen Client wieder zu erkennen und dann entsprechend im Programmablauf fortzufahren. Dabei gibt es mehrere Ansätze zur Speicherung von Zuständen. Es kann dem Client über die URL oder eine andere Methode alle notwendigen Informationen für die Wiederherstellung des Zustands, in dem sich die Anwendung für diesen Client befand, mitgegeben werden. Ist eine Client-Identifikation möglich, so kann der gesamte Zustand, der Programmkontext, auf dem Server gespeichert sein und wird für den Client, wenn dieser sich identifiziert, wieder hergestellt.

164

Sandini Bib Funktionen eines Application-Servers

Start

1

End

Abbildung 9.2: Ablaufdiagramm

Webserver hatten schon fast seit ihrer Entstehung 1992 die Möglichkeit, externe Programme auszuführen, die über das so genannte Common Gateway Interface (CGI) aufgerufen und mit Informationen versorgt wurden. Diese CGIs mussten und müssen heute auch noch den Zustand ihrer Anwendung, die sich gewöhnlich aus dem Zusammenspiel vieler CGIs zusammensetzt, übermittelt bekommen, um für den Client, der sie aufruft, die richtige Funktionalität zu erbringen. Ein einzelner Aufruf hat immer nur die, wie oben im Zyklus des HTTP-Protokolls erläutert, Reihenfolge einer Eingabe und einer darauf folgenden Ausgabe. Das führte dazu, dass sehr viele Programmierer die gleichen Funktionalitäten entwickelten, um dieses Problem zu lösen. Es wurde so genannte State-Engines als Bibliotheken angeboten, die es CGIs ermöglichen, untereinander den Zustand der Applikation auszutauschen und so überhaupt erst eine Applikation zu bilden. Viele weitere Funktionen, die immer wieder benötigt wurden, wie z.B. der Zugriff auf Daten-

165

Sandini Bib 9 Application-Server

banken, die Schleifenfunktion für Ausgaben usw., wurden immer wieder programmiert und mussten für jede Anwendung angepasst werden. Auf diese Weise wurden sehr viele Ressourcen aus der Entwicklung gebunden, die aber nichts Neues schufen, sondern nur grundlegende Probleme wieder und wieder beseitigten, um danach etwas Neues schaffen zu können. Außerdem entsteht eine klare Spaltung zwischen Entwicklung und Design, denn HTML ist leichter zu erlernen als das Programmieren, was bei vielen Webangeboten dazu führte, dass die so hoch gepriesene Interaktivität Aufgrund von Ressourcenmangel zugunsten sehr aufwändiger Designansätze verloren ging. Es ist offensichtlich, dass die Entwicklung und das Schreiben von Computerprogrammen mehr Kenntnisse der IT und der Maschine an sich erfordert, als z.B. notwendig sind, um ein maschinengerechtes Design zu entwerfen. Browser Enter URL DNS Lookup

Server

Connect

Accept

Send Requested URL

Interpret URL CGI? ReadFile

ReadSession

Interpret CHAR Stream

Read Output

Display/ Execute Page

Transmit Output

Execute CGI

ColdFusion Engin KeepSession DB Access Lib Access

Abbildung 9.3: Application-Server

166

Sandini Bib Typisierung allgemeiner Application-Server

Application-Server waren die Antwort auf dieses Dilemma für große Anwendungen. Zwischen die reine Repräsentationssicht und die Programmausführung wurde die Schicht des Application-Servers eingebunden. Hierbei interpretiert der Application-Server-Code, der von einem Client angefordert wurde, bevor er dem Client wieder zurückgegeben wird, und stellt dabei z.B. den Status der Anwendung wieder her, erfüllt Basisfunktionen wie Schleifen und Entscheidungen oder stellt sogar erweiterte Funktionen wie z.B. den transparenten Zugriff auf Datenbanken bereit. Die Befehle für diese zusätzliche Schicht werden in die eigentlich vom Client angeforderte Information, also in die Webseite hineinkodiert und erst auf dem Weg durch den Application-Server für den Client wieder zu für ihn verständlichen Seiten zusammengesetzt.

9.2

Typisierung allgemeiner Application-Server

Für die Bereitstellung der oben beschriebenen Funktionen gibt es grundsätzlich zwei Ansätze, die aus den unterschiedlichen Richtungen der Webentwicklung entstanden sind. Zum einen sind die TAG-basierte Ansätze, bei denen Programmfunktionalität in HTML-Erweiterungen, also eigenen Tags, untergebracht ist und in das ganz normale HTML-, JavaScript und dergleichen eingebunden wird. Dieser Ansatz wurde von Webdesignern entwickelt, die ihre aufwändigen Designs mit Programmfunktionalität versehen wollten. Zum anderen sind programmierorientierte Application-Server, bei denen das Design im Programmcode der einzelnen Seiten abgelegt ist, von den Programmierern entwickelt worden, die nicht auf ein gutes Design verzichten wollten. Als bekanntestes Beispiel für einen Application-Server, der programmiert wird, ist PHP zu nennen. Als bekanntestes Beispiel für einen TAG-basierenden Application-Server ist Cold-Fusion von Allaire zu nennen.

9.2.1

Vor- und Nachteile von TAG-basierten Systemen

Der eindeutige Vorteil eines TAG-basierten Systems ist die Verwendbarkeit in jeder HTML-Umgebung. Fast jeder HTML-Entwickler kann sehr schnell lernen, zumindest die einfachen Funktionen des Application-Servers zu nutzen und somit Dinge in seine Entwicklungen einfließen lassen, die ohne einen Application-Server nicht möglich gewesen wären. Die Integration der Programmierung in das Layout selbst hat zur Folge, dass die klassische Trennung zwischen Design und Algorithmik, wie sie in der Informatik schon seit längerem als Paradigma gilt, gebrochen wird. Es ist

167

Sandini Bib 9 Application-Server

allerdings zu berücksichtigen, dass TAG-basierte Systeme meistens von HTML- oder Webdesignern eingesetzt werden, die sich nicht zu reinen Programmierern entwickeln wollen, deren Ziel darin liegt, elegante algorithmische Lösungen zu gestalten, es handelt sich vielmehr um Kreative, die auch die Möglichkeiten der Programmierung nutzen wollen. Die direkte Einbindung in die Seiten, in das vertraute TAG-System und die Einfachheit der Strukturen, die durch TAGs ohnehin gegeben ist, machen die TAG-basierten Systeme einfacher zu erlernen. Dies ist aber nur der Fall, wenn bereits Kenntnisse im HTML- und Webdesign vorhanden sind. Die Zeit, die also benötigt wird, einen Webdesigner zu einem Webentwickler zu machen, ist durch diesen Ansatz stark verringert und schafft zusätzlich auch noch die Integration der rein kreativen Elemente, auf die ein solcher Personenkreis in der Arbeit sehr viel Wert legt. Der Nachteil von TAG-basierten Systemen ist eindeutig die einfache Programmstruktur, die abgebildet wird. Durch das TAG-System werden komplexe Programmieransätze, wie sie in einigen Algorithmen verwendet werden, nicht unterstützt. Außerdem ist der Code einer Anwendung über alle zur Anwendung gehörenden Seiten verteilt, da die Programmierung nicht einem programmdesignerischem Modulkonzept, sondern dem dialoggesteuerten Seitenkonzept folgen muss. TAG-basierte Systeme erfordern aus diesem Grund eine bessere Dokumentation, als diese für gewöhnliche Programme bereits erforderlich ist, um später keinen erhöhten Wartungsaufwand zu generieren. Ein weiterer, wenn auch geringerer Nachteil, der sich eventuell in den nächsten Generationen von Hybridsystemen weiter verringern wird, ist die rein interpretative Natur von TAG-basierten Systemen. Es muss bei jedem Seitenaufruf die Seite durch den Application-Server-Parser geschickt werden, der diese dann bearbeitet und wiederum reines HTML oder XML zurückliefert, was dann an den Client übermittelt wird. Durch die Aufteilung der Anwendung auf ihre Dialogseiten wird nicht nur das Debugging und bei nicht ausreichender Dokumentation die Weiterentwicklung erschwert, sondern auch die Kompilierung zu direkt ausführbarem Code nicht unterstützt. Es ist offensichtlich, dass die Vorteile dieses Ansatzes bei weitem überwiegen, weshalb Application-Server auf TAG-Basis Bestandteil des WebFarm-Standards sind.

9.2.2

Vor- und Nachteile von programmorientierten Systemen

Der Vorteil der progammorientierten Systeme ist eindeutig die Anlehnung an herkömmliche Programmiersprachen wie z.B. C oder C++. Dies ermöglicht es bei Ausnutzung der Funktionalität des Application-Servers, die hier eher wie

168

Sandini Bib Typisierung allgemeiner Application-Server

eine Bibliothek verwendet wird, auch komplexe Programmlogik in Webseiten abzulegen. Die Modularisierung der Seiten muss hierbei nicht unbedingt dem Dialogdesign der Anwendung folgen, da eine Seite durchaus mehrere unterschiedliche Dialoge erstellen kann. Bei einigen programmorientierten Systemen ist auch das Erzeugen eines Vorkompilats der erstellten Seiten zur Performancesteigerung möglich. Der Nachteil der programmierorientierten Systeme ist der hohe Kenntnisstand, den die Programmierung auf Sprachebene erfordert. Die auch informatisch elegante Realisierung von Problemen entspricht oft nicht der Denkweise von kreativen Webdesignern und hat dementsprechend einen hohen Schulungsaufwand, bzw. entsprechende Entwicklerstellen sind schwer zu besetzen.

9.2.3

Fazit

Grundsätzlich können beide Arten von Application-Servern im WebFarmStandard auch gleichzeitig eingesetzt werden. Es ist hierbei aber auf jeden Fall auf die richtige Zusammenstellung von Entwicklerteams zu achten. Im Falle eines TAG-basierten Systems benötigt man entsprechend geschulte Webdesigner, im Falle von programmierorientierten Systemen sind meistens sowohl Programmierer als auch Designer erforderlich. Es ist zu bedenken, dass die Wartung von Webanwendungen gerade aufgrund der schnellen Veränderungszyklen in diesen Anwendungen eine entscheidende Rolle für den dauerhaften Erfolg dieser Anwendungen spielt. Beim Einsatz TAG-basierter Systeme sind darum die Dokumentation und die klare Projekttierung, die in einem stringenten Anwendungsdesign abgebildet wird, wichtige Faktoren. Der WebFarm-Standard ist hierbei mit den Anforderungen an die Integration in die Infrastruktur einer WebFarm-Lokation eine Hilfe für die Entwickler. Die entsprechenden Style-Guides geben auch Auskunft darüber, wie zu wartende Seiten auch mit Application-Server-Einsatz geschaffen werden können. Es ist aber wie bei allen Entwicklungsprojekten essentiell, dass das Entwicklungsteam einer Anwendung, die in einer WebFarm-Lokation betrieben werden soll und sich in die Infrastruktur integrieren soll, ein gutes Design mit darauffolgender Umsetzung und einer entsprechenden Testphase vor der Betriebsübergabe durchgeführt hat. Es ist aber auch unbedingt erforderlich, dem Entwicklungsteam den Gesamtzusammenhang ihrer Anwendung in der WebFarm-Lokation vor der Entwicklung zu verdeutlichen, um es den Entwicklern zu ermöglichen, nicht nur den Standard der WebFarm-an sich, sondern auch den spezifischen Kontext einer WebFarm-Lokation in das Design miteinzubeziehen.

169

Sandini Bib 9 Application-Server

9.3

Arbeitskräfte und Ressourcen

Das Thema der Ressourcen, die für die Entwicklung einer Webanwendung zur Verfügung stehen und eine entsprechende Qualifikation sowohl auf fachlicher als auch auf technischer Seite besitzen, ist tatsächlich kritisch. Wenn man dem Technologieboom folgt und hierbei sieht, dass trotz eventueller Konsolidierung der Firmenstrukturen an den neuen Märkten die Investitionssummen in Zukunftstechnologien eher noch steigen werden, ist auch nicht mit einer baldigen Besserung der Ressourcenlage zu rechnen. Es ist daher entscheidend, dass die Entwickler in einer Umgebung arbeiten, die ihrem Kenntnisstand und ihren Anforderungen angemessen ist. Dieser Faktor, der bislang in DV-Entwicklungen höchstens als Einstellungskriterium, aber lange nicht als Kriterium für das Systemdesign gesehen wurde, ist heute kritisch geworden, da durch mangelnde Ressourcen durchaus wesentliche Verzögerungen oder gar Nichtrealisierungen entstehen können. Es sollte also bei der Wahl des Application-Servers für eine bestimmte Webentwicklung auf jeden Fall darauf geachtet werden, wie sich das bestimmte Projektteam zusammensetzt und ob eher eine Gewichtung der Projektmitglieder in die Programmier- oder in die Designecke der oben beschriebenen Unterteilung fallen. Dies kann ein wichtiger Hinweis für die Auswahl des Application-Servers sein.

9.4

Entwicklungsumgebungen

Die Entwicklungsumgebung entscheidet über die Teamfähigkeit einer Entwicklung. Es ist wichtig, dass die Entwickler so entwickeln können, wie sie es für sich persönlich am besten halten. Aus diesem Grund soll nicht von vornherein eine bestimmte Umgebung zur Pflicht gemacht werden. Das Backend der Umgebung für Entwicklungen ist wesentlich wichtiger, denn hier werden die einzelnen Teile zusammengefügt. Es ist wichtig, dass für die Übergabe von entwickelten Seiten und Anwendungsteilen das Content-Management-System (in diesem Fall das Redaktionssystem) verwendet wird. Es sollte auch auf eine Versionierung während der Entwicklung geachtet werden, was für ein IT-Projekt an sich selbstverständlich ist, aber in Webprojekten oft vernachlässigt wird. Die optimale Entwicklungsumgebung vereint die Teile der verwendeten Sprachen, also sowohl HTML als auch die Sprache des Application-Servers, sei diese nur TAG-basiert oder programmierorientiert. Das bedeutet, dass sowohl Konstruktion, die Syntax-Checking als auch einfache Funktionen und, besonders bei der Entwicklung von großen Anwendungen wichtig, eine ausgeklügelte Bibliotheksverwaltung bei der Umgebung berücksichtigt sind.

170

Sandini Bib Entwicklungsstil

Abbildung 9.4: Entwicklungsumgebung Allaire ColdFusion

Viele Standardumgebungen unterstützen all diese Punkte. Oft können auch Entwicklungsumgebungen, die in den Application-Server integriert sind, verwendet werden. Aber auch im letzteren Fall ist auf eine Möglichkeit des indirekten Exports von Seiten und deren Übergabe über das ContentManagement-System und die damit verbundenen essenziellen Prozesse des WebFarm-Standards zu achten.

9.5

Entwicklungsstil

Der Stil von Entwicklungen im Webbereich unterscheidet sich leider sehr oft von nach herkömmlicher Weise propagierten Programmierstilen. Und dies liegt nur zum Teil, wie oft behauptet wird, an der Menge an generiertem und nicht manuell erzeugtem Code. Es ist auf jeden Fall darauf zu achten, dass in Grenzen, die dem Entwicklungsteam zuzumuten sind, ein gängiger Entwicklungszyklus einzuhalten ist.

171

Sandini Bib 9 Application-Server

Dies bedeutet insbesondere bei der Entwicklung der Programmlogik und der Verbindungen nach außen (z.B. Datenbanken, externe Programme usw.) eine Konzeption der Entwicklung, deren anschließende Kodierung und erst darauf folgend ein Test des Geschaffenen. Dies wird hier in der Beschreibung der Implementierungsspezifika des WebFarm-Standards explizit erwähnt, da viele Webdesigner ein absolut 100%iges Trial- und Error-Verfahren anwenden, was sowohl die Entwicklungszeit mehr als verdoppelt als auch die Umgebung, wie z.B. Datenbanken, der Entwicklung über die Maßen hinaus belastet. Es ist bei der Zusammenstellung eines professionellen Teams auf jeden Fall darauf zu achten, dass diese einfachen Maßregeln der Programmierung eingehalten werden. Bei der Entwicklung des WebFarm-Standards ist oft eingeworfen worden, dass es sich bei HTML aber um ein lebendes System handele oder dass schließlich der Entwicklungszyklus so kurz sei. Es ist sicherlich festzuhalten, dass jegliche Art von Programm, das einen derart kurzen Entwicklungszyklus hat, als lebendes System bezeichnet werden kann, weil auch die normalen Zyklen für die Weiterentwicklung und damit die Veränderung im System sich an die Zyklen des Initialprojekts angeglichen haben und so stark verkürzt sind. Dies entbindet aber nicht von einem korrekten Vorgehen, in dem die zu programmierende Logik auch im Bereich der Datenbankabfragen zuerst konzipiert, danach kodiert und getestet wird. Es ist auch bei Webentwicklungen billiger, einen korrekten Stil einzuhalten, und wirkt sich hierbei nicht auf die Zeit bis zum Online-Datum aus. Diese einfachen Feststellungen, die in der herkömmlichen Programmentwicklung bereits lange bekannt sind, treffen auch nach Erfahrungen in der Erstellung des WebFarm-Standards auf die Webentwicklung im besonderen Maße zu.

9.6

Schulung und Time-to-Market

Schulungen sind ein entscheidendes Thema, was auch schon im Bereich zu Ressourcen und Arbeitskräften angesprochen wurde. Es ist hier wichtig zu sehen, was die schnellsten Resultate bei gleich bleibend guter Qualität gibt, denn die Time-to-Market ist direkt nach der danach dargestellten Funktionalität noch mehr als bei anderen IT-Projekten das A und O. Aus diesem Grund ist zu bedenken, dass TAG-basierte Systeme von Application-Servern wesentlich leichter zu erlernen sind, als programmierorientierte Systeme, wenn eine HTML-Grundlage bereits gegeben ist.

172

Sandini Bib Einsatz eines Application-Servers




 

 




   
   
 


















































 












    

9.7

 

Einsatz eines Application-Servers

Glaubt man den Marketingprospekten der meisten Produkte, kann man sie für alles einsetzen, was überhaupt vorstellbar ist. Da dies aber sicherlich nicht sinnvoll ist (z.B. Formularlogik mit einem Middleware-App-Server zu erzeugen), werden im WebFarm-Standard auch klare Vorgaben für den Einsatz solcher Werkzeuge gemacht.

9.7.1

Einsatz von spezifischen Application-Servern

Spezifische Application-Server sind mit neuem Schulungsaufwand verbunden und sollten daher nur, wenn unbedingt notwendig, eingesetzt werden. Die Bedingung für den Einsatz ist, dass die Datenübergabe gemäß dem WebFarm-Standard für Content-Management geschehen kann. Ferner empfiehlt der WebFarm-Standard, spezifische Application-Server nur für fertige Frontend-Anwendungen einzusetzen und nicht für Backend-Services. Das bedeutet zum Beispiel, dass es sicherlich sinnvoll ist, den SAPApplication-Server einzusetzen, wenn man eine webgestützte SAP-Anwendung generieren will, dass man eine Webanwendung, die lediglich auch auf Daten aus einer Datenbank zugreift, nicht mit einem Datenbank ApplicationServer erstellen muss, weil die entsprechende Funktionalität unter Berücksichtigung von Entwicklungszeit und Standard auch mit einem allgemeinen Application-Server abgedeckt werden kann.

173

Sandini Bib 9 Application-Server

9.7.2

Standardfunktionen von Application-Servern und Webservern

Gerade bei spezifischen Application-Servern werden oft Funktionalitäten, wie z.B. eine Java-Engine zur Einbindung von Servlets, als besondere Funktionen dargestellt. Da diese Application-Server meist auch gleichzeitig als Webserver fungieren, ist dies sicherlich auch notwendig. Es ist allerdings zu beachten, dass es sich hierbei zumeist um Standardfunktionen handelt, die bei normalen Webserver-Produkten (ohne ApplicationServer-Funktionen) bereits integriert sind und eventuell sogar wesentlich weiter entwickelt erscheinen. Es bietet sich also nicht an, aus solch einem Server-Backend-Grund einen spezifischen Server einzusetzen, da in diesem Falle die Kombination eines Webservers mit einem Application-Server als Zusatzprodukt die bessere technologische Grundlage für Entwicklungen bietet.

9.7.3

Einsatz von allgemeinen Application-Servern

Für alle Anwendungen können theoretisch Application-Server, wie z.B. ColdFusion von Allaire, eingesetzt werden. Allerdings ist es offensichtlich nicht sinnvoll, für sehr kleine Anwendungen diese Werkzeuge, die dem Programmierer zwar einiges an Overhead ersparen, dies aber auch von technischer Seite in die Anwendung einbringen, zu verwenden. Web-Application-Server sollten auf jeden Fall immer dann eingesetzt werden, wenn größere Webanwendungen mit HTML/XML-Basis geschaffen werden, die große zusammenhängende Benutzersitzungen erfordern. Das bedeutet z.B. Beratungswerkzeuge, Shopping-Applikationen usw. Besonders empfiehlt sich der Einsatz bei diesen Anwendungen, wenn neben der Programmlogik auch Datenbankzugriffe und Zugriffe auf andere externe Ressourcen eingebunden werden müssen. Ein zusätzlicher Vorteil der meisten im WebFarm-Standard empfohlenen Application-Server ist deren Fähigkeit, Application-Cluster zu bilden und damit eine Lastverteilung zu unterstützen.

9.7.4

Application-Server vs. CGI

Eine Frage, die sich häufig stellt, ist, ob CGIs als Programme, die über das Common-Gateway-Interface mit Informationen vom Client versorgt werden, überhaupt noch entwickelt werden sollen. Die eindeutige Antwort ist ja. Es ist nicht sinnvoll, sehr kleine Anwendungen oder Anwendungen, die keine zusammenhängenden Benutzersitzungen erfordern, weil sie aus vielen

174

Sandini Bib Hardwarespezifikationen

kleinen unabhängig voneinander funktionierenden Werkzeugen bestehen, in einen Application-Server einzubetten, dessen erzeugter Overhead dann gar nicht verwendet wird. CGIs sind in solchen Fällen sicherlich sehr sinnvoll. Bei der Entwicklung von CGIs ist auf jeden Fall auf Sicherheitskonformität mit dem WebFarm-Standard anhand der Sicherheitsrichtlinien und der CGIEntwicklungsrichtlinien zu achten, da es über die Parameterübergabe oft zu Sicherheitsproblemen kommen kann. CGIs erfordern eine sehr saubere Entwicklung, und das nicht zuletzt aufgrund der sicherheitskritischen Funktionalität im System, sondern auch aufgrund der Performance, die verbraucht wird, wenn für jedes »Anklicken« eines CGIs ein Programm gestartet werden muss. Für den Praxiseinsatz in Anwendungen mit sehr vielen Benutzern empfiehlt es sich nicht, CGIs in interpretativen Sprachen wie z.B. PERL zu entwickeln. Diese eignen sich eher für Anwendungen, die im RAD (Rapid Application Development) entwickelt werden und später für eine kleine Benutzerzahl wenige Funktionen anbieten sollen. Auf jeden Fall sinnvoll ist der Einsatz von Script-Sprachen oder interpretativen Sprachen, wenn ein Prototyping für eine Webanwendung entsteht.

9.8

Hardwarespezifikationen

Aufgrund der Funktionalität eines Application-Servers ändern sich für den Betrieb einer Webanwendung, die auf einem Application-Server aufbaut, die Spezifikationen für die Hardware der Webanwendung, wie dies auch im entsprechenden Dokument zur Webserver-Hardware des WebFarm-Standards dokumentiert ist. Generell ist davon auszugehen, dass der Application-Server pro Instanz mindestens 100 MB RAM benötigt, ohne eine Funktionalität auszuführen. Für die meisten Anwendungen, die mit einem Application-Server realisiert werden, ist also mit einer Mindestspeicheranforderung von 512 MB RAM zu rechnen. Werden über die Programmlogik komplizierte Algorithmen zur Berechnung oder zur Bedingungsauflösung und Plausibilisierung durchgeführt, so ist auch die Rechenleistung der Maschine zu erhöhen (2. Prozessor), da die Performance durch den Overhead der Applikationsabteilung und der Interpretation durch den Application-Server relativ hoch ist. Grundsätzlich ist im WebFarm-Standard zu vermerken, dass Maschinen, die Application-Server-basierte Webanwendungen beherbergen sollen, eine wesentlich höhere Hardwareausstattung benötigen, als das für einfache Webserver, die Informationssysteme beheimaten, der Fall ist.

175

Sandini Bib 9 Application-Server

9.9

Clustering

Da Application-Server oft sehr hohe Anforderungen an die Hardware haben, wie oben beschrieben wurde, empfiehlt es sich hier wesentlich eher als bei reinen Informationssystemen, ein Server-Clustering anzustreben. Der WebFarm-Standard empfiehlt dieses Clustering bei einer rein ApplicationServer-basierten Anwendung bei mehr als 200.000 Hits auf Web-Application-Server-basierten Seiten. Dieses Clustering wird zumeist von der Application-Server-Software unterstützt und ist nicht ein Load-Sharing auf IP-Basis, sondern auf Anwendungsebene.

9.10 Cookies Ein wichtiges Thema im Zusammenhang mit Web-Application-Servern sind die so genannten und allseits unbeliebten Cookies. Es handelt sich hierbei um »Nachrichten« oder Informationen, die ein Webserver an einen Client übermittelt, wo sie abgespeichert werden, und dann vom Server oder beliebigen Servern wieder heruntergeladen werden können. Unbeliebt sind diese Cookies, weil sie es einem Server ermöglichen, das Benutzerverhalten und auch das Verhalten insgesamt eines Benutzers nachzuvollziehen, und sehr effizient Informationen über den Benutzer sammeln. Ebenfalls ist es möglich, Informationen auf dem Rechner des Benutzers abzulegen, die sicherlich nicht dort zwischengespeichert werden sollten. Vor allem störend ist, dass diese Informationen immer wieder gelesen werden können. Im Bereich der Web-Application-Server wird meistens ein Cookie verwendet, um eine Session-ID für die aktuelle Anwendersitzung durch die gesamte Sitzung hindurch im Server vom Client verfügbar zu haben. Generell sollte auf den Einsatz von Cookies bei der Entwicklung eigener Anwendungen verzichtet werden. Die Art und Weise, wie aber z.B. ein WebApplication-Server, der korrekt konfiguriert ist, Cookies verwendet, nämlich lediglich zum Session-Tracking, wobei alle Cookies eine Lebenszeit unter 24 Stunden oder noch kürzer haben, eine Platzbeschränkung der gespeicherten Daten enthalten und nur von der Anwendung, die sie erzeugt hat, innerhalb der Lebenszeit gelesen werden können, ist jedoch sinnvoll.

176

Sandini Bib

10

Database-Connectivity

Datenbankverbindungen sind für jede Anwendung, die eine Interaktion mit dem Benutzer bietet und nicht nur eine reine Spielwiese darstellt, von größter Wichtigkeit, da sie nur in Datenbanken-Produktivdaten gehalten werden können bzw. verfügbar sind und diese Daten, wenn man über den Simulationslevel hinausgeht, sicherlich erforderlich sind. Nachfolgend werden die Kontextparameter für die Verbindung zu Datenbanken innerhalb der WebFarm-Infrastruktur beleuchtet und die verschiedenen Themen des Verbindungsaufbaus, der Benutzerberechtigung und des Schutzes an sich betrachtet. Der WebFarm-Standard unterstützt dabei Verbindungen zu lokalen Datenbanken der einzelnen Anwendungen, zu Datenbanken, die sich innerhalb der lokalen oder einer entfernten WebFarm-Lokation befinden, aber auch zu Datenbanken, die sich in einer anderen internen Betriebsumgebung befinden, die den Bedürfnissen der entsprechend spezifischen Datenbank und deren Betriebsanforderungen entspricht.

10.1 Lokale und entfernte Datenbanken Lokale Datenbanken, also Datenbanken, die direkt auf der gleichen Maschine laufen wie die Webanwendung, sind nur für nichtproduktive Datenbestände zu verwenden. Das bedeutet z.B. als Zwischenspeicher für Simulationen, Berechnungen oder Boards. Diese Datenbanken dürfen auf keinen Fall sicherheitsrelevante Daten enthalten und auch keine Daten, die später in ein produktives System übernommen werden, erzeugen. Lokale Datenbanken müssen so konfiguriert sein, dass entweder ein Zugriff über einen PIPE-Mechanismus erfolgt oder, wenn dies nicht möglich ist, weil nur eine TCP-Verbindung unterstützt wird,dass lediglich der lokale Rechner und, wenn der Rechner sich in einer Cluster-Umgebung befindet, alle anderen Rechner im Cluster Zugriff auf die Datenbank haben.Für alle Daten, die in irgendeiner Weise einen schützenswerten Status haben, werden entfernte Datenbankserver benutzt. Der WebFarm-Standard verlangt, dass diese jeweils eine Stufe hinter der Lokation des Webservers in der Sicherheitskonstruktion der WebFarm-Lokation stehen.

177

Sandini Bib 10 Database-Connectivity

10.2 Connectivity auf Datenbankebene Es gibt viele Arten, wie eine Verbindung so zu einer Datenbank hergestellt werden kann, dass nachher Abfragen möglich werden. Grundsätzlich gibt es die Möglichkeit, über ein der Datenbank eigenes Protokoll bzw. einen datenbankeigenen oder so genannten nativen Treiber eine Verbindung zur Datenbank aufzubauen. Alternativ existieren Protokolle wie ODBC oder JDBC, mit denen standardisierte Verbindungen aufgebaut werden können. Es ist essenziell zu beachten, dass der WebFarm-Standard Verbindungen von einer Webanwendung (serverseitig) über eine native Schnittstelle vorschreibt, es sei denn, es werden einzeln vereinbarte Sonderbedingungen definiert. Dies ist mit den Performancevorgaben durch die Mechanismen in ODBC, JDBC vorgegeben, wo z.B. Joints von Tabellen im Treiber und nicht in der Datenbank durchgeführt werden. ODBC ist lediglich für den Zugriff auf Entwicklungssysteme und in der Anwendungsentwicklung ein Thema. Es ist auf jeden Fall zu beachten, dass manche ODBC und native Treiber unterschiedliche Behandlungen des lokalen Codes haben und damit z.B. Zahlen unterschiedlich interpretieren (z.B. 3.01 wird zu 3,01). Es sollte, wie bereits erwähnt, also immer ein Native-Treiber zur Datenbankanbindung von Anwendungen aus dem Application-Server oder CGIUmfeld verwendet werden. Ein dedizierter Webserver, der bereits Datenbankoperationen eingebaut hat, bietet zwar meistens sehr gute Datenbankfunktionalitäten, ist aber im Bereich des Webservings nicht ausgereift, was sich allein durch die Entwicklungsstrategien der jeweiligen Hersteller klar belegen lässt. Durch die verschiedenen Arten, Anwendungen im Web zu entwickeln, gibt es grundsätzlich zwei Modelle für den Zugriff auf Datenbanken. Einerseits bei Anwendungen, die über einen Application-Server oder CGIs erstellt wurden, greift der Client nur auf den Webserver und die Ergebnisse einer Datenbankabfrage, die vom Webserver Richtung Datenbank erfolgt, zu. Andererseits entsteht ein direkter Zugriff vom Client auf eine Datenbank der einen Datenbankverbindung, wenn z.B. JAVA-Applets eine Datenbankabfrage starten, die nebenbei direkte Kommunikation ermöglicht.

10.2.1

Datenbankzugriff vom Webserver aus

Bei diesem Zugriffsmechanismus werden die Datenbestände durch die Sicherheitsmechanismen in der Webanwendung geschützt. Das bedeutet, dass einerseits der Server so sicher konfiguriert sein und in ein dem WebFarm-Standard entsprechendes Sicherheitskonzept eingebunden sein muss, damit sich ein Angreifer nicht der Kontrolle des Servers bemächtigen kann, um dann auf die Datenquelle mit eigenen Befehlen zuzugreifen, und anderer-

178

Sandini Bib Kostenbetrachtung

seits, dass die Webanwendung selbst dafür Sorge trägt, dass nur entsprechend berechtigte Benutzer auf die für sie zur Verfügung stehenden Daten zugreifen können. Dieser Mechanismus hat den Vorteil, dass die Datenbankabfragen absolut überschaulich und innerhalb der eigenen Sicherheitsinfrastruktur einer WebFarm-Lokation oder ggf. auch Lokationsübergreifend kontrolliert werden können. Eine Verschlüsselung, also der Einsatz eines zu verschlüsselnden Datenbanktreibers, ist nur dann erforderlich, wenn die Datenbank nicht in der gleichen WebFarm-Lokation untergebracht ist oder die Route von der Webanwendung bis zur Datenquelle Netzsegmente passiert, die mit einem weniger sicheren Status versehen sind, als die Datenbank selbst.

10.2.2

Datenbankzugriff vom Client aus

Der Datenbankzugriff vom Client aus stellt hier wesentlich größere Anforderungen an die Sicherheit. Es wird ein Weg geschaffen, mit der quasi beliebige Clients (Einschränkungen sind nur anhand der Einschränkung des Benutzerkreises der Webanwendung möglich und auf Datenbankseite sehr schwer zu implementieren und zu warten) ermöglicht werden. Für Java-Anwendungen wird in diesem Fall z.B. ein JDBC-Treiber installiert. Dieser muss auf jeden Fall, wenn es sich um geschäftskritische oder imagekritische Daten handelt, eine Verschlüsselung bis hin zum Client ermöglichen. Anderenfalls kann eine solche Datenversorgung nicht bis zum Client nach dem WebFarm-Standard erfolgen. Bei Primärdaten ist zusätzlich noch eine verschlüsselungsbasierte Identifikation des Clients bzw. seines Benutzers erforderlich, so dass auf jeden Fall nicht nur anhand der heruntergeladenen Applets nachvollzogen werden kann, wer Datenbankzugriffe getätigt hat.

10.3 Kostenbetrachtung Einige wenige Datenbanken, die für Spezialanwendungen wie z.B. das performante Management von großen Zeitreihenarchiven verwendet werden, haben auch heute noch ein benutzerbasiertes Pricing. Dies hat zur Folge, dass, wenn diese Datenbank im Rahmen einer Webanwendung eingesetzt wird, normalerweise ein Pauschalbetrag für die angenommene Anzahl von möglichen Webbenutzern fällig wird. Diese Preisstruktur kann sehr unvorteilhaft sein; es sollte darum beim Design einer Anwendung, die nach dem WebFarmStandard entwickelt wird, auf jedem Fall eine Standarddatenbank für die entsprechenden Lizenzabkommen bestehen, oder eine Datenbank, die ein ser-

179

Sandini Bib 10 Database-Connectivity

verbasiertes Pricing verfolgt, eingesetzt werden. Ist dies nicht möglich, was definitiv bei der Projektierung begründet werden muss, so ist zu betrachten, ob sich die Benutzermenge bzw. der Benutzerkreis sehr stark einschränken lässt, so dass wieder Preisvereinbarungen über eine spezifische Nutzerzahl getroffen werden können.

10.4 Layer-Zugriffe Wird ein Zugriff auf mehrere Datenbanken gleichzeitig getätigt oder wird ein Cacheing-Mechanismus wegen mangelnder Performance oder Verfügbarkeit der eigentlichen Datenquelle benötigt, kann nach dem WebFarm-Standard eine Zwischenschicht zwischen der eigentlichen Webanwendung und der eigentlichen Datenbankverbindung hergestellt werden. An sich ist diese Zwischenschicht nichts anderes, als eine starke Erweiterung der ohnehin bereits existierenden Zwischenschicht des Datenbankzugriffs über Netzwerke. Eine einfache Erweiterung wird z.B. durch verschlüsselte Zugriffe implementiert, da diese meistens in den Treibern direkt integriert sind. Diese Zugriffsschichten sind vor allem bei der Notwendigkeit von Datenproxy-Servern, wie sie z.B. oft bei HBCI-Abfragen entstehen, sinnvoll. Das Design einer solchen Zugriffsschicht sollte auf eine verlässliche Middleware aufbauen, damit eine Integration in WebFarm-Cluster und allgemein in die WebFarm-Betriebsumgebung möglich wird. Eine solche Middleware unterstützt die durch eine Warteschlange abgesicherte garantierte Zustellung von Nachrichten auch über komplexere Routen zwischen dem Sender und dem Empfänger. Solche Software wird auch oft verwendet, um Data-Warehouses oder Data-Marts aufzubauen. Der Einsatz einer Zwischenschicht sollte im Hinblick auf Performance der Anwendung, auf Kosten und auf Programmkomplexität begutachtet werden. Durch die Erfahrungen, die mit dem WebFarm-Standard gesammelt wurden, hat sich gezeigt, dass eine solche Schicht nur bei sehr zentralen Anwendungen mit Zugriffsmethoden auf Primärdatenbestände des gesamten Unternehmens wirklich notwendig sind.

10.5 Datenbank-Zugriffsverwaltung Da sich Datenquellen genauso wie Webanwendungen weiterentwickeln, aber meist nicht explizit mit den Webanwendungen verbunden sind, sondern einen eigenen Entwicklungszyklus haben, da sie auch für andere Prozesse verwendet werden, ist es ein wichtiges Thema in der Entwicklung von Web-

180

Sandini Bib Datenbank-Zugriffsverwaltung

Farm-konformen Applikationen, die Verwaltung oder eigentlichen Zugriffe innerhalb einer Anwendung so zu zentralisieren, dass sie leicht angepasst werden können. Neben der Flexibilität, die dadurch bei Änderungen der Datenbanken und Datenbankstrukturen entsteht, ist dies auch für das Performance-Tuning, was bei allen Webdatenbank-Abfragen von Bedeutung ist, ein entscheidender Vorteil, da alle Abfragen zentralisiert vorliegen und diese gemeinsam betrachtet werden können. Dies bedeutet, dass SQL-Zugriffe innerhalb einer Anwendung nicht anhand der Programmodule oder Anwendungsseiten bei Application-Servern verteilt sein dürfen, sondern dass SQL-Abfragen generell zentralisiert oder zumindest gruppiert abgelegt werden müssen. In der CGI-Entwicklung schreibt der WebFarm-Standard darum vor, alle SQL-Statements in ein Modul oder eine Modulgruppe auszulagern, abhängig davon, wie viele es sind. Es bietet sich beim Zugriff auf sehr große Data-Warehouses ebenfalls an, die Feld- und Tabellennamen durch Makrobezeichner für die Anwendung zu ersetzen, die am Anfang einer solchen Modulgruppe definiert werden, damit die Abfragen bestehen bleiben können (Mengenproblem), wenn Änderungen an Feldern vorgenommen werden, die ja dann nur noch einmal in den Makros durchgeführt werden müssen. Bei Application-Servern sollten alle SQL-Abfragen in einem gesonderten Verzeichnis in jeweils einer Datei pro Abfrage abgelegt sein. Die entsprechenden Seiten, die dann Abfragen aufrufen, werden dann mit der entsprechenden Datei über ein INCLUDE-Statement verbunden.

181

Sandini Bib

Sandini Bib

11

Search

Suchmaschinen sind bereits Teil der Infrastrukturmaßnahmen für WebFarmLokationen. Diese Suchmaschinen decken aber nur eine informations- und anwendungsübergreifende Suche auf einem bestimmten Berechtigungsniveau ab. Es ist sicherlich wünschenswert, gerade in Anwendungen oder Sites mit vielen Informationen eine Suchfunktion zu integrieren, die nicht auf die globale Infrastruktur zugreift. Ziel ist es nun, hier die Möglichkeiten zur Integration von Suchfunktionen in eine einzelne Anwendung oder einen einzelnen Site für den WebFarm-Standard festzulegen.

11.1 Suche und Content-Management Durch die im WebFarm-Standard festgelegte Philosophie des ContentManagements werden alle semi-dynamischen Informationen mit Meta-Informationen versehen. Einige dieser Meta-Informationen sind Stichwörter. Werden diese nach einem Katalog oder frei von den Autoren gepflegt, kann das Content-Management-System eine Suche über diese Stichworte zur Verfügung stellen. Eine solche Suche ist sehr effizient, da es sich um direkte aggregierte Informationen handelt, über welche die Suche durchgeführt wird. Im Gegensatz zu Volltextsuchen liefern derartige Suchmechanismen auch gute Ergebnisse, wenn die Dokumentenmenge sehr groß ist.

Abbildung 11.1: Suchabfrage und Ergebnisdarstellung

Es ist auf jeden Fall empfehlenswert, auf allen Systemen, die über den Information-Pool mit Inhalten versorgt werden – also nicht reine Applikationen oder rein statische Seiten sind – in eine solche Suchfunktion einzubinden, wenn eine Suche benötigt wird, da hier am effizientesten für das gesamte System gesucht werden kann. Alle anderen Suchen benötigen eine zusätzliche Indizierung von Dokumenten und sind somit eine Mehrbelastung für das System.

183

Sandini Bib 11 Search

11.2 Volltext- und Metasuche auf lokalen Sites Eine Volltext- oder Metasuche auf einem lokalen Site hat genau die gleichen Vor- bzw. Nachteile wie bei der Anwendung im globalen Suchbereich. Es kann also hier auf die Betrachtungen des WebFarm-Standards auf dem Infrastrukturbereich zurückgegriffen werden. Hiernach sollen möglichst nicht reine Volltextansätze für große Sites und Anwendungen verwendet werden. Der WebFarm-Standard schlägt hier vor, eine Metasuche als ersten Schritt zu etablieren. Eine Volltextsuche wird, wie bereits bei der Definition des Infrastrukturstandards erwähnt, mit zunehmender Dokumentenzahl, also mit stark steigender Informationsmenge, unzuverlässig, da sehr viele Dokumente gefunden werden, die eventuell keine echten Treffer sind.

Abbildung 11.2: Volltext- und Metasuche

184

Sandini Bib Volltext- und Metasuche auf lokalen Sites

Im Gegensatz zum Ansatz der globalen Suchmaschinen ist es mit einer gegebenen Berechtigungsstruktur eventuell sinnvoll, auf der Ebene des Dateisystems Dokumente einzulesen. Hierbei werden alle Dokumente berücksichtigt. Es ist hierbei aber auch zu beachten, dass auf jeden Fall alle Dateien eingescannt werden; das kann im Fall von statischem Content, der von den Entwicklern nur mangelhaft gepflegt wird, bedeuten, dass alte Versionen eingelesen werden, was auf jeden Fall zu verhindern ist. Wenn alle Dateien eingescannt werden, muss auf die Berechtigungsstruktur geachtet werden, die dann auf jeden Fall in der Suchmaschine nachzubilden ist. Unterstützt die Suchmaschine keine Berechtigungsabbildung, was mit einigen Suchmaschinen, die aus anderen Gründen im WebFarm-Standard empfohlen werden, der Fall ist, müssen für unterschiedliche Rollen unterschiedliche Engines verwendet werden. Auf jeden Fall ist der Einsatz einer lokalen Suchmaschine sicherlich zu empfehlen. Es kann neben der Suchmaschine über das Content-Management-System, das die Informationen aus dem Information-Pool über Stichwort und Metasuchen zugänglich macht, auch eine Volltext- oder Metasuchmaschine verwendet werden, die dann den gesamten Text untersucht. Auf jeden Fall muss eine Meta- oder Volltext-Suchmaschine verwendet werden, wenn die Autoren nicht korrekt angewiesen wurden, Schlüsselworte zu den publizierten Dokumenten zu erfassen, oder wenn Schlüsselworte nicht in den Meta-Informationen des Content-Pool konfiguriert sind, also von den Designern des Informationsmodells gar nicht vorgesehen sind.

11.2.1

Konfigurationsvoraussetzungen

Wird eine Volltext- oder Metasuchmaschine auf einem Webserver eingesetzt, der nach dem WebFarm-Standard betrieben wird, sind einige Konfigurationsvoraussetzungen zu erfüllen. Es muss auf jeden Fall dafür gesorgt werden, dass die Administration der Suchmaschine, die bei allen im WebFarm-Standard empfohlenen Suchmaschinen, die auch als lokale Suchmaschinen eingesetzt werden können, webbasiert ist, nicht automatisch aktiv ist. Diese Administrationsoberfläche darf nur eingeschaltet werden, wenn die Suchmaschine tatsächlich konfiguriert wird. Ist dies nicht möglich, ist durch eine strenge Zugangsbeschränkung (auf IP- und Benutzerebene) dafür zu sorgen, dass der Zugang autorisiertem Personal vorbehalten bleibt. Außerdem dürfen die Konfigurationsdateien sowie die Indexdateien und Suchhistorien nicht im Bereich des Document-Root der Webanwendung abgelegt werden, die durchsucht werden soll, sondern müssen entsprechend

185

Sandini Bib 11 Search

dem Schema für die Installation von Zusatzsoftware auf Webservern, das im WebFarm-Standard definiert wird, eingerichtet werden. Bei großen Anwendungen kann man für die Installation der Suchmaschine und insbesondere für deren Indexdateien eine gesonderte Partition oder Platte vorsehen, da die Indexdateien einer Suchmaschine manchmal so groß oder sogar größer werden können als die zu indizierenden Informationen.

11.3 Integration in die globale Suchumgebung Die Integration einer Anwendung und deren lokaler Suchmaschine in das globale Suchumfeld gestaltet sich immer wieder als komplex. Es ist grundsätzlich selten der Fall, dass für die Anwendung ein direkter Mehrwert geschaffen wird, vielmehr wird durch die Aufnahme einer Anwendung in die globale Suchwelt zusätzlich zur lokalen Suchmaschine den Benutzern, die diese Anwendung nicht kennen oder deren Inhalte nicht beurteilen können, ein Mehrwert gegeben, da diese sicherlich Informationen, die sie in ihren normalen Anwendungen nicht finden können, im globalen Suchmechanismus der WebFarm-zu finden versuchen. Soll eine Anwendung also auch Anwendern »schmackhaft« gemacht werden, die diese normalerweise nicht verwenden, ist eine Einbindung in das öffentliche Suchnetz der WebFarm-Lokation der Anwendung unerlässlich. Die Benutzer der Anwendung selbst können, wenn es sich um ein Angebot mit allgemein nützlichen Informationen handelt, über die Verbindung zum globalen Suchnetz und einer integrierten Suche über die anwendungseigene Suchmaschine sowie die globalen Suchmechanismen Dokumente in anderen Anwendungen lokalisieren, die zu dem von Ihnen momentan bearbeiteten Themenblock passen und damit einen Mehrwert an Information bieten, den der Benutzer, wäre er nur in der lokalen Anwendung verblieben, nicht gehabt hätte. Fazit dieser Ausführungen ist, dass ein Angebot immer in die globale Suchumgebung integriert werden sollte.

186

Sandini Bib Integration in die globale Suchumgebung

Abbildung 11.3: Integration in eine Globale Suchumgebung

187

Sandini Bib 11 Search

Abbildung 11.4: Suchumgebung von Altavista

188

Sandini Bib

12

Content-Management

Im Folgenden soll auf die spezifischen Anforderungen von Anwendungen im Hinblick auf deren Anschluss an das WebFarm-Content-Management-System eingegangen werden. Es handelt sich nicht um ein Kapitel für Agenturen und wie diese Contents in die Systeme übertragen können; eine entsprechende Beschreibung ist dem Benutzerhandbuch für Agenturen bzw. dem Autorenhandbuch für das Content-Pool-System zu entnehmen. Vielmehr geht es darum, Content in die allgemeine Struktur einzugliedern, verfügbaren Content für eine neue Anwendung nutzbar zu machen und allgemein darum Content im Unternehmen oder bei externen Quellen zu lokalisieren.

12.1 Lokales Content-Management Content-Management umfasst, wie im entsprechenden Infrastruktur-Kapitel des WebFarm-Standards beschrieben, alle Arten von Inhalten, die auf Webservern abgebildet werden können. Dabei ist es offensichtlich, dass dynamischer Content keine Frage eines zentral verfügbaren Content-Management-Systems ist, sondern von den Anwendungen selbst generiert wird und daher ohnehin eine Frage der Anwendung an sich ist. Interessant für das globale Content-Management ist die Versorgung aller Anwender mit Inhalten. Das bedeutet sowohl den Transport von statischem Content an die richtige Anwendung als auch die Versorgung aller Anwender mit semi-dynamischem Content aus einem verteilten Content-Pool.

189

Sandini Bib 12 Content-Management

12.1.1

Statischer Content

Abbildung 12.1: Statischer Content auf einer Website

Statischer Content wird von den Erzeugern und Lieferanten direkt an das Content-Management-System übergeben. Dieser Content enthält statische Serverbereiche einer Webanwendung genauso wie eigentliche Anwendungen, sprich Programme, Includes, Templates, Application-Server-Code usw. Dieser Content wird an das System nicht als allgemeiner Content für den Content-Pool übergeben, sondern mit der Kennzeichnung, dass es sich um Content für einen vorgegebenen Bestimmungsort handelt. Das ContentManagement-System wird dieses Package, wie im entsprechenden Kapitel des WebFarm-Standards beschrieben, durch die Checkalgorithmen schleusen und für eine fachliche Freigabe auf dem Pre-Production-System der Zielanwendung bereitstellen. Wurde das Package freigegeben, so wird es auf das System und das Backup-System der Anwendung als Praxis-Package eingespielt, und der Prozess ist abgeschlossen.

190

Sandini Bib Lokales Content-Management

Dieses Verfahren beeinflusst den lokalen Server. Sind hier Mehrsprachigkeit oder andere Features gewünscht, muss dies der statische Content alleine zur Verfügung stellen, da es die Idee von statischem Content ist, keine weitere Beeinflussung zu erfahren.

12.1.2

Semi-dynamischer Content

Semi-dynamischer Content wird von Autoren direkt an das Content-Management-System in den Content-Pool übergeben. Dabei ist es für die Autoren nicht relevant, für welche Zielsysteme oder Zielanwendungen dieser Content verwendet wird, denn es geht hierbei um die Speisung des Content-Pool. Die Konfiguration einer Anwendung im Content-Pool bedeutet also, dass alle diejenigen Informationsklassen und/oder durch Regeln eingeschränkten Informationsgruppen auf die Anwendung selbst übertragen werden, um dann dort in Format, Struktur, Vernetzung usw. auf die Anwendung angepasst zu werden.

Abbildung 12.2: Unterschiedliche Darstellung desselben Contents auf verschiedenen Zielsystemen

Der Content-Pool ist in diesem Fall eine Zwischenschicht zwischen Autor und Anwendung, der sich um die einfache Arbeitsumgebung für den Autor, die Verteilung der Informationen und letztendlich um das Management der Informationen auf vielen Anwendungen gleichzeitig kümmert. Mehrsprachigkeit Die Mehrsprachigkeit innerhalb eines Unternehmens oder einer Anwendung ist beim Erstellen von Webanwendungen immer wieder ein heikles Thema, was über die Funktionalität des WebFarm-Content-Management-Systems mit seinem objektorientierten Content-Pool-System mit Attributen und MetaInformationen einfach gelöst wird. 191

Sandini Bib 12 Content-Management

Selbstverständlich sollen von einer Information keine computerisierten Übersetzungen automatisch erstellt werden, da die Qualität solcher Übersetzungen immer noch stark zu wünschen übrig lässt.


 Abbildung 12.3: Eingabemaske für Metainformationen

Es werden vielmehr von Autoren bzw. Übersetzern der Autoren die entsprechenden erforderlichen Dokumente in mehreren Sprachen an den ContentPool übergeben. Dabei sind die den Dokumenten mitgegebenen Attribute und Meta-Informationen, wie z.B. Klasse, Expiry usw., identisch. Zusätzlich wird den Klassen des Content-Pool, die mehrsprachigen Content unterstützen sollen, eine Meta-Information für die Sprache des jeweiligen Dokuments mitgegeben, die der entsprechende Autor oder Übersetzer mit vordefinierten Werten ausfüllt. Dadurch wird es dem Content-Management-System auf den einzelnen Anwendungen, auf denen die Information eintrifft, ermöglicht, die Sprachen zu identifizieren und den Content, obwohl er in der gleichen Klasse und Strukturebene angekommen ist, in eine andere Struktur, eben für die andere Sprache, zu integrieren. Es ist über das Content-Pool-System auch möglich, zusammenhängende Informationen zu publizieren, also z.B. immer ein englisches und ein deutsches Dokument gemeinsam. Das hat den Nachteil, dass diese Dokumente

192

Sandini Bib Lokales Content-Management

auch immer zusammenhängend behandelt werden müssen, also nie unabhängig voneinander für eine deutsche und/oder eine englische Anwendung verwendet werden können. Es kann aber als Vorteil eine Verbindung zwischen exakt diesen Dokumenten hergestellt werden. Beide Ansätze zur Verwaltung von mehrsprachigem Content sind möglich, der WebFarm-Standard verwendet allerdings in 95% aller Fälle die Möglichkeit, Sprachen über Meta-Informationen zu identifizieren, weil dabei eindeutig die Vorteile überwiegen. Layout und Design Das Layout und Design, das bei statischen Informationen, da es ja nur für eine Anwendung erzeugt wurde, feststeht, ist bei semi-dynamischen Informationen variabel. Je nach Ziel der Information – und das sind, wenn die Information effizient eingesetzt wird, sehr viele verschiedene Ziele – kann die Information ein neues Layout und Design erhalten. Wird eine Information in einer bestimmten Klasse vom Content-Pool-Netzwerk an eine Anwendung geliefert, sind die auf der Anwendung installierten Komponenten des WebFarm-Content-Management-Systems dafür verantwortlich, dass aus dem Klassenmodell des Content-Pool und den der Information mitgegebenen Meta-Informationen eine Eingliederung der Information in die Struktur der jeweiligen Anwendung erfolgt, und ebenso sind diese Komponenten dafür verantwortlich, dass das Layout- und Designkonzept der Anwendung in den einzelnen Dokumenten umgesetzt wird.

Abbildung 12.4: Trennung von Layout und Inhalt

Eine solche Umsetzung des Designs ist, wie in Webanwendungen üblich, nur in webbasierten Dokumententypen, also HTML oder XML, sinnvoll und wird auch nur bei diesen Content-Typen vom Content-Management-System bzw. dessen Content-Pool-Komponenten vorgenommen. Auf der Anwendung

193

Sandini Bib 12 Content-Management

liegt dann also entsprechend eine Kopie der original vom Autor bereitgestellten Information, die über Links usw. in die Struktur der Anwendung eingebunden ist und dem Layout der Anwendung entspricht. Struktur Wie im vorangegangenen Absatz bereits beschrieben, ist die Einbindung einer Information in die Struktur der Anwendung ein sehr wichtiges Element, wenn Informationen wieder verwendbar gemacht werden. Da jede Anwendung eine andere Anforderung an Struktur, Vernetzung und allgemeine Darstellung bzw. Navigierbarkeit von Informationen hat, spielt die für eine Anwendung gewählte Struktur der Informationen eine große Rolle. Auf einem Site für Experten werden z.B. wesentlich mehr Informationen im direkten Zugriff stehen und völlig anders sortiert sein als auf einem Site, auf dem Benutzer an ein Thema herangeführt werden sollen, oder auf einem Site, an dem eine Art Drill-Down für Informationen präsentiert wird.

Abbildung 12.5: Integration von Informationen in die Struktur einer Anwendung

Damit eine Anwendung den Automatisierbarkeitsanforderungen des WebFarm-Standards entspricht, muss sie so strukturiert sein, dass jegliche Art von Content, der nicht unbedingt statisch oder vollkommen dynamisch erzeugt werden muss, über das Content-Pool-System der WebFarm- gefüttert wird. Die Struktur muss dabei den Anforderungen der Benutzer für diese spezielle Anwendung Rechnung tragen. Auf diese Weise können mit den gleichen Informationen viele Benutzer unterschiedlichster Benutzergruppen und Anforderungsprofile versorgt werden, die ansonsten nur schwerlich den richtigen Zugang zu diesen Informationen gefunden hätten. 194

Sandini Bib Lokales Content-Management

Der Aufbau solcher Strukturen hat Auswirkungen auf die im Content-PoolSystem verwendeten Meta-Informationen zu einem Dokument. Fällt bei einer neuen Anwendung auf, dass zusätzliche Meta-Informationen benötigt werden, so können diese immer problemlos eingeführt werden. Diese Erweiterbarkeit auf der Attributebene bewirkt, dass ein gut designtes Klassenmodell für den Content-Pool immer so erweitert werden kann, dass neue Applikationen und Informationstypen problemlos integriert werden können. Die Strukturierung muss in Betracht ziehen, auf welcher Ebene der Navigation einer Informationsanwendung welche Informationen bzw. wie viel dieser Information dargestellt werden sollen und welche Verfallszeiten Informationen an sich bzw. der Verweis auf bestimmte Informationen in Indizes haben. Sind die Indizes ermittelt, kann das System so konfiguriert werden, dass es jeden Index mit einer Menge an Bedingungen über die eingehenden Informationsklassen, deren Meta-Informationen, Sortierung, Darstellung, Verfallszeiten usw. darstellt. Sind diese Indizes geschaffen, werden sie automatisch vom Content-Pool-System auf der Anwendung generiert, und die Informationsstruktur der Anwendung ist komplett automatisiert und sehr einfach verwaltbar. Vernetzung Die Vernetzung von Informationen, die als semi-dynamische Informationen oder auch als statische Informationen auf einer Anwendung angekommen sind, wird durch das WebFarm-Content-Management weit über die generierte Struktur hinaus ermöglicht. Informationen sollen über Schlüsselwörter und Referenzen miteinander verbunden werden. Wie diese Vernetzung stattfindet, ist nicht eine Frage der globalen Konfiguration des WebFarm-ContentManagement-Systems, sondern eine Frage der lokalen Anwendung, da genau wie die Struktur die Vernetzung von Informationen auf die Benutzer der Anwendung abgestimmt sein muss. Die Vernetzung kann nur auf semi-dynamische Dokumente beschränkt werden, damit nur aktuelle Informationen miteinander verbunden werden; sie kann aber auch auf statische Dokumente ausgedehnt werden, die dann ihrerseits Verweise auf aktuelle Dokumente in der Anwendung enthalten können. Der WebFarm-Standard unterscheidet zwischen zwei grundlegenden Arten der Vernetzung: Schlüsselworte/Keywords Keywords werden einer Information vom Autor als Meta-Informationen mitgegeben. Sie dienen dazu, den Inhalt des Dokumentes zu klassifizieren. Es kann den Autoren freigestellt werden, eigene Schlagworte zu wählen, es ist aber auch möglich, das WebFarm-Content-Management-System so zu konfi-

195

Sandini Bib 12 Content-Management

gurieren, dass dem Autor eine bestimmte Auswahl an Stichworten zur Verfügung steht. Die Vernetzung anhand von Stichworten durchsucht nun den als Text (HTML, XML, Application-Server) auf einem Server, auf dem die Information ankommt, vorhandenen Inhalt nach diesen Stichworten. Wird ein Stichwort gefunden, erzeugt das Content-Management-System einen Verweis von diesem Stichwort auf das Dokument, das dieses Stichwort als Meta-Information mitführt. Wenn es mehrere Dokumente gibt, wird wie bei der Indexerstellung eine Art Zwischenseite generiert, die dann nach vorgegebenen Sortierungskriterien die Dokumente, die das Schlüsselwort als Meta-Information mitführen, darstellt, so dass der Benutzer diese anwählen kann. Zusätzlich können Attribute über die Art der Schlüsselworterkennung (z.B. mit Abständen oder unter Nichtbeachtung von HTML-Tags) definiert werden sowie Konfigurationen über die Häufigkeitsverteilung von Verweisen in einem Dokument (wie viele Wörter zwischen zwei Verweisen sein müssen, wie viele Verweise ein Dokument überhaupt enthalten darf).

Abbildung 12.6: Verweise in einem Dokument

196

Sandini Bib Lokales Content-Management

Referenzen Referenzen sind eine Art Schlagwörter, die auf Anwendungsseite konfiguriert werden. Dies bedeutet, dem Content-Management-System wird auf der Anwendung eine Liste mit Stichwörtern übergeben, die mit einem Verweis versehen sind. Semi-dynamische Informationen werden nun auf diese Schlagwörter hin untersucht, und wenn diese gefunden werden, wird ein Verweis hinter dem Schlagwort in das Dokument integriert, der auf die angegebene Stelle vernetzt. Dieses Verfahren, den Content einer Anwendung zu untersuchen, kann auch auf den statischen Content ausgedehnt werden. Auf diese Weise kann in Informationssystemen eine Art Lexikon integriert werden, das typische Begriffe erläutert. Ebenso ist dieses Verfahren geeignet, um ein durchgehendes und automatisch funktionierendes Hilfssystem in eine Webanwendung zu integrieren. Voraussetzung für die Konfiguration von Referenzen im Vergleich zu Schlüsselwörtern ist, dass ein Wort in der Referenzliste nur ein einziges Mal vorkommen darf, da es ja für die Vernetzung eindeutig identifiziert werden muss. Überlegungen zum Thema Vernetzung von Informationen nach dem WebFarm-Standard sollten in jedem Webprojekt eine wichtige Rolle spielen. Die Vernetzung über das Content-Management-System der WebFarm stellt eine sehr wichtige Administrationserleichterung sowie eine große Verbesserung der Kommunikationsstruktur von Anwendungen dar, da eine Content-orientierte Struktur, die sich nicht an der Baumstruktur eines Servers orientiert, in die Anwendung vollautomatisch eingezogen werden kann. Dokumentenzyklen Der Zyklus von Dokumenten in einer Anwendung ist ebenfalls entscheidend für die Informationsstruktur und damit für die Art der Anwendung sowie deren Benutzergruppe. Über das Content-Management-System können mehrere Zyklen für Dokumente festgelegt werden. Zunächst kann der globale Zyklus für eine Information einer Klasse bestimmt werden. Das bedeutet, dass ein Dokument nach dem dort festgelegten Zeitpunkt oder der festgelegten Dauer komplett aus der Anwendung entfernt wird. Selbstverständlich werden hierbei auch alle Verweise auf dieses Dokument entfernt. Indizes und Strukturelemente können im WebFarm-Content-ManagementSystem ebenfalls so konfiguriert werden, dass nur eine bestimmte Anzahl von Dokumenten auf einer Seite, nur eine bestimmte Anzahl von Dokumenten in einem Index dargestellt werden oder Dokumente nach einer gewissen Zeit aus einem bestimmten Index verschwinden. Diese Titel können eingesetzt werden, um verschiedene Aktualitätsstufen und Archivübersichten in eine Anwendung zu integrieren.

197

Sandini Bib 12 Content-Management

12.2 Content für eine Anwendung Die Grundsatzfrage, welcher Content überhaupt in eine Anwendung integriert wird, ist Thema vieler Abhandlungen im Bereich der Webforschung. Grundsätzlich ist wohl zu sagen, dass, wenn die Anwendung eine sehr gute Struktur hat und Drill-Down-orientiert ist, möglichst viel Content überhaupt verwendet werden sollte. Es gibt aber auch Anwendungen, wie z.B. Management-Information-Systeme, bei denen der Content auf das absolut Notwendige beschränkt ist, damit er überhaupt zu verarbeiten ist, und nicht erst eine Suche nach wesentlichen Inhalten durchgeführt werden muss. Die Anwendung an sich bietet in ihren Basisanforderungen grundsätzlich auch Anforderungen für Inhalte und damit für Content. Es ist wichtig, diese Informationen, Programme usw. auf jeden Fall in die Anwendung zu integrieren. Die eigentliche Frage stellt sich erst dann, wenn der absolute BasisContent abgedeckt ist und es um zusätzlichen Content geht. Hier gilt, aller verwandter Content, der um den Basis-Content generiert wird, oder Anwendungen, die um den Basis-Content herum entstehen, sind auf jeden Fall sinnvoll zu integrieren und stehen damit dann auch anderen Anwendungen, die eventuell einen ähnlichen Fokus haben (Brückenfunktion), zur Verfügung. Dieser Content kann, wenn er noch nicht im Informationsmodell erfasst ist, sofort in die Strukturen über den neuen Content eingegliedert werden, der die Basis für die Anwendung bildet. Zusätzlich ist es oft sinnvoll, Anwendungen mit Hintergrundinformationen zum Fachgebiet, zu Anwendungen, zum Unternehmen usw. zu versorgen, die allgemein aus dem Content-Pool angefordert werden können. Durch den bestehenden Content-Pool ist auch eine doppelte Erstellung von Informationen, was im heutigen Informationsprozess in Unternehmen sehr oft geschieht, nicht mehr möglich. Beim Design einer Anwendung muss nach dem WebFarm-Standard nämlich zuerst der Content-Pool des ContentManagement-Systems nach Informationen durchsucht werden, welche die Basisanforderungen der Anwendung widerspiegeln. Wird für eine Anwendung tatsächlich neuer Basis-Content oder auch Content aus dem Kontext der Anwendung geschaffen, muss dieser auf jeden Fall in den Informationspool einfließen, wenn es sich um semi-dynamische Informationen handelt, oder in die Bibliothek von Anwendungen und statischen Informationen, wenn es sich um statischen Content oder Anwendungen zur Benutzerführung oder zur Erzeugung von dynamischem Content handelt. Dieses Einfügen in die Strukturen erfolgt anhand des vorgegebenen Klassenmodells des Informationsmodells für die globale Content-Struktur des Unternehmens, die bei der Implementierung der WebFarm-in einem Unternehmen dynamisch festgelegt wird. Wie im entsprechenden Infrastrukturdokument des WebFarm-Standards definiert, sollten einige Oberklassen, die sich am

198

Sandini Bib Content für eine Anwendung

sinnvollsten an der fachlichen Ausrichtung von Informationen um die Geschäftsbereiche des Unternehmens organisieren, festgelegt werden. Darunter stehende Klassen werden mit den entstehenden Applikationen gebildet und daher ständig anhand der Vererbung und der Erweiterung des Modells verbessert und verfeinert. Durch den objektorientierten Ansatz des Klassenmodells des ContentManagement-Systems der WebFarm-ist die Integration von neuem Content nicht schwierig. Sie muss dennoch sehr sorgfältig erzeugt werden, damit nicht generell doppelte Strukturen innerhalb des Content-Pool bzw. dessen Klassenbaum aufgebaut werden. Auch ist zu unterscheiden, ob für neuen Content eine neue Klasse geschaffen werden muss oder ob dieser eventuell besser über die Erweiterung von Meta-Informationen eingebettet werden kann und so wesentlich einfacher und voll automatisch auch auf bestehenden Anwendungen zur Verfügung steht. Im Fall, dass nur Meta-Informationen für neuen Content erweitert bzw. Attribute hinzugefügt werden, wird der Content automatisch an alle Anwendungen verteilt, diese entsprechende Klasse angefordert haben (und keine Restriktion auf Meta-Informationen besitzen). Sind diese offen konfiguriert, wird der Content ohne weiteres Zutun integriert. Es wird auf diese Weise also eine sehr gute Automatisierung von Informationswiederverwendung erreicht.

199

Sandini Bib

Sandini Bib

13

Management der Navigationsstruktur

Die Navigation ist ein Aushängeschild für einen Webserver oder die Benutzerschnittstelle für eine Anwendung, die weborientiert arbeitet. Ohne eine sinnvolle und benutzerfreundliche Navigation ist eine Webanwendung nicht einsetzbar und wird keine Akzeptanz finden. Im Folgenden werden die Richtlinien des WebFarm-Standards beschrieben, wie eine Navigation am besten aufgebaut wird und welche unterschiedlichen Navigationstypen es gibt. Jede Anwendung hat ihre eigene Umgebung, darum können solche Richtlinien nie zu 100% eingehalten werden. Es ist aber sinnvoll, sich an diesen Vorgaben zu orientieren, da sie aus vielen großen Webprojekten resultieren, die erfolgreich sind; selbstverständlich sind auch Misserfolge beim Anwendungsdesign in den Erfahrungsschatz dieses Dokuments eingeflossen, die bei der Entwicklung neuer Anwendungen aber nicht wiederholt werden müssen.

13.1 Anwendungsklassifizierung Für die Navigationsstruktur einer Anwendung sind grundsätzlich drei Typen zu unterscheiden, die sich auf die Struktur und die Art der Navigation auswirken.

13.1.1

Reine Programmanwendung

In diesen Anwendungen, welche die Repräsentation einer normalen Applikation zur Dialogabwicklung für einen Benutzer darstellen, ist die Navigation Bestandteil der Programmierung. Es ist offensichtlich, dass dies derart abhängig von der Anwendung an sich ist, dass keine weborientierten Vorgaben gemacht werden können. Grundsätzlich gelten hier die gleichen Anforderungen an Benutzbarkeit und Ergonomie wie beim Design von Client-Serveroder anderen Anwendungen. Eine Webentwicklung bedeutet nicht, dass man sich von den Erfahrungen in der Benutzerführung und der Unterstützung des Benutzers beim Benutzen einer Anwendung, die über lange Zeit gesammelt wurden, lossagen kann. Dies ist beim Design solcher Anwendungen auf jeden Fall zu beachten.

201

Sandini Bib 13 Management der Navigationsstruktur

Abbildung 13.1: Reine Programmanwendung

13.1.2

Allgemein verwendbare Webanwendung

Allgemeine Webanwendungen sind Webanwendungen, die sich an einen Benutzerkreis richten, der durch Informationslandschaften und Interaktionsmöglichkeiten geführt werden muss und dabei neue Informationen und Anwendungen entdecken kann und soll. Es handelt sich nicht nur um Marketingangebote, sondern auch um Informationssysteme, welche die Benutzer zum weiteren Lernen veranlassen sollen. Diese Anwendungen bilden im Internet mit knapp 95% die große Mehrheit, hier ist aber ein Rückgang auf ca. 80% vorherzusagen. In den Intranet- und Extranet-Entwicklungen bilden auch diese Anwendungen mit ca. 70% den größeren Teil.

202

Sandini Bib Anwendungsklassifizierung

Diese Anwendungen besitzen eine Navigation, die sich an der Denkweise des Benutzers Schritt für Schritt orientiert und so den Benutzer unterstützt, wenn er neue Informationen entdeckt oder seinen eigenen Gedankengängen folgt.

Abbildung 13.2: Allgemein verwendbare Webanwendung

13.1.3

Webanwendung für Experten

Bei Anwendungen für Experten, also Benutzern, die exakt wissen, was sie suchen und wo sie es finden, ist eine völlig andere Navigation zu wählen. Anwendungen, die in einer solchen Art geschaffen werden, sind normalerweise sich schnell aktualisierende Informationssysteme oder Organisationssysteme, bei denen bestimmte Anwender immer wieder auf die gleichen Seiten zugreifen. Für solche Anwendungen bietet sich auch eine Individualisierung an.

203

Sandini Bib 13 Management der Navigationsstruktur

Abbildung 13.3: Webanwendung für Experten

204

Sandini Bib Navigationsdesign für allgemeine Anwendungen

13.1.4

Homepages

Abbildung 13.4: Homepages verschiedener Unternehmen mit unterschiedlichen Aussagen

Die Eingangsseite zu einer Webanwendung kann aus dem normalen Navigationsdesign der Anwendung herausstechen. Bei allgemeinen Anwendungen wird sie meistens zum Transport von aktuellen Marketingbotschaften verwendet, bei Anwendungen für Experten eher für die Darstellung von individuellen Seiten oder für die Präsentation neuester Informationen.

13.2 Navigationsdesign für allgemeine Anwendungen Das Navigationsdesign für allgemeine Anwendungen ist, wie bereits angesprochen, darauf ausgelegt, den Benutzer zu führen, ihn also von einer Ebene in die nächste zu leiten und innerhalb des Content neue Ideen oder gewollte Suggestionen zu unterstützen.

205

Sandini Bib 13 Management der Navigationsstruktur

13.2.1

Seitenlayout

Es gibt mehrere Ansätze, eine Seite zu gestalten. Viele Seiten verfolgen den Ansatz, eine Navigation oben und links oder oben und rechts oder unten und links oder auch unten und rechts zu etablieren. Nur sehr marketingorientierte Anwendungen bauen die Navigation direkt auf die Seite. Wie oben bereits erwähnt, geht es hier nicht um die Homepages, sondern um Seitenlayouts in den Anwendungen, da Homepages zur Erstellung von gewissen Effekten oft völlig anders gestaltet sind und dies auch sein dürfen.

13.2.2

Navigationselemente

Es werden verschiedene Navigationselemente unterschieden. Top Level-Navigation Über diese werden die Oberpunkte einer Anwendung angesprochen. Im Falle der allgemeinen Anwendungen stehen in diese Navigationselemente für die einzelnen Bereiche des gesamten Webservers. Diese Navigation wird oft als Top Level bezeichnet, weil sie sich für gewöhnlich auch am oberen Rande der Darstellung befindet. Hot Buttons Hot Buttons sind Navigationselemente, die, mit besonders auffälligem Design versehen, in die Top Level-Navigation integriert oder um diese gruppiert werden. Diese Elemente werden verwendet, um bestimmte spezifische Teile einer Anwendung, die von starkem allgemeinen Interesse sind, direkt anzusprechen. Meistens werden hier Hilfefunktionen oder Feedback-Funktionen in Marketinganwendungen untergebracht. In Extranet-Anwendungen werden hier z.B. Konfigurationsmöglichkeiten oder besonders hervorzuhebende Einzelanwendungen vernetzt. Die Hot Buttons sind ein wichtiges Element einer Navigation, da sie einerseits die Unterstützungsfunktionen für den Benutzer bieten, die immer benötigt werden, und andererseits verwendet werden können, um gezielt Benutzer auf bestimmte Einzelanwendungen oder Informationen zu lenken.

206

Sandini Bib Navigationsdesign für allgemeine Anwendungen



  



 

Abbildung 13.5: Elemente einer Navigationsstruktur

Side-Navigation Diese Navigationsebene, die oft an der Seite einer Website untergebracht ist, stellt die Navigation im momentan gewählten Bereich des Servers dar, der über die Top Level-Navigation ausgewählt wurde. Die Navigation kann sich auch als zweite Ebene unter der Top Level-Navigation befinden, was sich auf Seiten mit wenigen Elementen in einer Ebene sehr stark bewährt hat. Wird ein Element der Side-Navigation angewählt, was neben dem Content auch eine nächste Ebene in der Navigation der Anwendung darstellt, so wird die vorhandene Side-Navigation auf den angewählten Punkt und in einer Stufendarstellung seinen Unterpunkten umgebaut. Dies hat zur Folge, dass der Benutzer nicht durch die Möglichkeit, direkt in andere Bereiche zu springen, verwirrt wird.

207

Sandini Bib 13 Management der Navigationsstruktur

Geht man von einer erfahrenen Benutzergruppe aus, so wird nicht die Navigation der Elemente der oberen Ebene ausgeblendet, sondern lediglich die Unterpunkte des gewählten Bereichs werden eingeblendet. In einer Side-Navigation sollten nur in ganz seltenen und gut begründeten Fällen mehr als zwei Ebenen gleichzeitig voll dargestellt werden. Wird tiefer navigiert, werden die darüber stehenden Ebenen, da immer ein direkter Weg zurück geboten werden muss, mit einer Symbolik dargestellt, die es erlaubt, die Backnavigation auf die gleiche Ebene wie die übergeordneten Ebenen zu stellen, in der sich der Benutzer gerade befindet. Navigation-View Die Anzeige des Standortes des Benutzers im Server ist gerade für unerfahrene Benutzer oder Benutzerinnen, die einen Site kennen lernen, sehr wichtig. Grundsätzlich ist bei einer gut gestalteten Top Level-Navigation, die also visualisiert, welchen Bereich der Benutzer angewählt hat, und einer SideNavigation, welche die Ebenen klar erkennen lässt, keine zusätzliche Anzeige notwendig. Zur Information des Benutzers kann aber die exakte Lokation in der primären Struktur des Servers zusätzlich zwischen Top Level- und Side-Navigation dargestellt werden.

13.2.3

Navigationsebenen

Aus den vorangegangenen Ausführungen wird deutlich, dass auf jeden Fall mehr als zwei Navigationsebenen darstellbar sein müssen. Ist dies nicht der Fall, muss man von einer Bedienung der Anwendung nur von Seite zu Seite ausgehen, was eine sehr stringente Benutzerführung voraussetzt, der sich heute kaum noch ein Benutzer von Webanwendungen unterziehen will. Solche Anwendungen werden z.B. für Computer-Based-Training eingesetzt, da hier der Benutzer ohne Verwirrung nur die in der Schulung direkt im Ablauf vorgesehenen Vernetzungen verwenden soll.

208

Sandini Bib Navigationsdesign für Expertenanwendungen

Abbildung 13.6: Verschiedene Ebenen einer Navigationsstruktur

13.3 Navigationsdesign für Expertenanwendungen Expertenanwendungen müssen eine wesentlich detailliertere Navigation auf einmal anbieten als Anwendungen im allgemeinen Bereich, weil man hier davon ausgehen kann, dass der Benutzer bereits weiß, in welchem Bereich des Servers sich die Informationen befinden, die er sucht, und auch genau weiß, wie man diesen Bereich annavigieren kann. Wenn nicht ohnehin ein Bookmark für einen Anwendungsteil existiert, wie sich viele Benutzer sparen, wenn eine für sie geeignete Navigation verfügbar ist. Die Elemente sind prinzipiell gleich, nur die Anforderungen an diese Elemente haben sich im Vergleich zu allgemeinen Anwendungen stark verändert. In der Top Level-Navigation wird, wenn der Benutzer sich in einem Unterbereich befindet, nur noch die Top Level-Navigation dieses Unterbereichs dargestellt.

209

Sandini Bib 13 Management der Navigationsstruktur

Die Side-Navigation wird zu einer Komplettnavigation über die gesamte Anwendung. Dies ist das wichtigste Element für Anwendung für Experten. Der Benutzer kann mit diesem Werkzeug einfach die gesamte Site auf einmal betrachten und sich an die von ihm gewünschte Stelle mit einem Klick navigieren. Eine solche Navigation lässt sich statisch realisieren, was einen gewissen Aufwand darstellt. Sinnvoll erscheint eine an einer gewohnten Umgebung (z.B. von Windows) orientierte Navigation, wie z.B. ein Dateibaum. In einem solchen Baum können Ordner auf- und zugeklappt werden und für die Navigation angeklickt werden. Eine solche Anwendung lässt sich am einfachsten mit JavaScript navigieren.

Abbildung 13.7: JavaScript-Navigation

210

Sandini Bib Navigationsdesign für Expertenanwendungen

Wissensbasierte Navigation Eine Alternative zur allgemeinen Site-Navigation in sehr großen Informationssystemen ist eine Navigation, die sich an der Technik der so genannten Mind-Maps orientiert und somit logische Verkettungen zwischen Informationselementen darstellen kann. Eine solche Navigation wird momentan oft nur experimentell eingesetzt, wird sich aber bei wachsenden Informationssystemen immer mehr durchsetzen.

Abbildung 13.8: Wissensbasierte Navigation

211

Sandini Bib

Sandini Bib

14

Cluster-Management

Viele Websites im Internet erreichen sehr schnell eine Popularität, die über die Leistungsfähigkeit einer Maschine stark hinausgeht, oder bieten derart aufwändige Anwendungen an, dass diese nicht mehr in einem Single-Host-Environment betrieben werden können. Die erste Strategie war es, die Rechner, auf denen solche Anwendungen betrieben werden, zu maximieren. Es ergibt sich auch hier die gleiche Problematik, wie sie bereits im WebFarm-Infrastruktur-Kapitel über WebserverHardware diskutiert wird. Es hat sich darum im Internet durchgesetzt, solche Anwendungen eher auf mehrere kleine Server zu verteilen, die dann einen Cluster bilden. Solche Cluster haben Vorteile bei Anschaffungspreis, Kontrollierbarkeit und Ausfallsicherheit, sind aber auch im Management wesentlich aufwändiger als andere Umgebungen. Im Folgenden sollen die Möglichkeiten des Clustering, die Voraussetzungen und die Bedingungen in der Anwendungsentwicklung sowie die Integration von Clustern in die WebFarm-Umgebung definiert werden.

14.1 Cluster-Varianten Es gibt einige, mehr oder weniger einfache und sinnvolle Möglichkeiten, Cluster zu erstellen. Alle diese Möglichkeiten widersprechen nicht dem WebFarm-Standard.

14.1.1

Round-Robin-Verfahren

Dieses Verfahren ist wohl das älteste Verfahren, um eine Art von RechnerClustern zu erzeugen. Dieses Verfahren funktioniert über die Vergabe des gleichen Namens im DNS für mehrere Rechner bzw. mehrere IP-Adressen. Der Nameserver wird nun diesen Raum an IP-Adressen sequentiell abarbeiten und bei jeder Anfrage die nächste Adresse zurückgeben. Dieses Verfahren setzt kein besonderes Cluster-Management voraus. Es müssen lediglich alle Server, die den gleichen Namen besitzen, auch die gleichen Inhalte liefern.

213

Sandini Bib 14 Cluster-Management

Request 1 Request 2 Request 3

Client

Request 4

Client Client Client Cluster Server 1

Cluster Server 2

Network

LAN

LAN

Cluster Server 3

DNS Request 4

DNS

DNS Request 3 DNS Request 2 DNS Request 1

Cluster Server 4

Abbildung 14.1: Round-Robin-Verfahren

Das Round-Robin-Verfahren ist leider nicht kontrollierbar, da die DNS verschiedene Cash-Stufen enthält und oft keine neuen Anfragen durchgeführt werden. Auf der anderen Seite kann es sein, dass Anfragen eines Benutzers auf mehreren Rechnern eingehen, was dann wieder bedeutet, dass der Cluster Sessiondaten von Benutzern, wenn es um eine Anwendung mit Sessions geht, unter den beteiligten Maschinen in Echtzeit abgleichen muss. Generell empfiehlt der WebFarm-Standard dieses Verfahren nur dann, wenn es sich um öffentliche Informationssysteme mit sehr wenig Interaktion handelt, bei denen eine exakte Lastverteilung nicht das Ziel ist, sondern nur eine Verbesserung des Performanceverhaltens.

14.1.2

Reverse-Proxy-Cluster

Über das bereits im Infrastruktur-Kapitel des WebFarm-Standards beschriebene Reverse-Proxy-Verfahren kann ebenfalls ein Cluster eingerichtet werden. Hierfür sollte allerdings die Proxy-Software so konfiguriert werden, dass sie nur das Clustering betreibt, da ansonsten der Performanceverlust zu hoch ist. Der Reverse-Proxy kann über das Cluster-Protokoll, auf das sich verschiedene Hersteller von Proxy-Software geeinigt haben, eine bessere Verteilung der Auslastung gewährleisten. Wichtiger ist allerdings, dass der ReverseProxy auch Benutzer erkennen kann und somit einen Benutzer auf einer Maschine des Clusters belässt, so dass kein zusätzlich belastendes Sharing der Benutzerdaten vorgenommen werden muss.

214

Sandini Bib Cluster-Varianten

Eine weitere Funktion, die mit einem Reverse-Proxy abgedeckt werden kann, ist die Verteilung unterschiedlicher Anfragen. Es kann z.B. bei einem Cluster aus acht Maschinen veranlasst werden, dass alle Anfragen für den WebserverBereich/Customers auf die Maschinen 1 bis 4 verteilt werden und alle anderen Anfragen auf die Maschinen 5 bis 8. Somit kann also innerhalb einer Anwendung auch eine weitere Unterteilung der Prozesse erreicht werden, was zu einem wesentlich besseren Performanceverhalten führt. Der Nachteil einer solchen Konstruktion ist eindeutig, so dass der ReverseProxy selbst sehr schnell zum Engpass werden kann, da dieser sehr viele Requests abhandeln und je nach Konfiguration doch einiges an Operationen dabei durchführen muss. Es besteht nun die Möglichkeit, auch diese Proxies wieder zu Clustern zu machen, was aber sicherlich das Management unnötig kompliziert machen würde. Außerdem handelt es sich um ein Softwareprodukt, das, wie bei Internet-Software üblich, relativ kurzen Entwicklungszyklen unterliegt und damit eventuell instabil sein kann. Da der Reverse-Proxy aber dann ein »Single Point of Access« ist, kann das verheerende Auswirkungen auf die Verfügbarkeit der Anwendung haben.

Client Request

Client Client

Request Distriburtion

Client Cluster Server 1

Cluster Server 2

LAN

LAN

Network

Cluster Reverse Proxy

Cluster Server 3

Cluster Information Cluster Server 4

Abbildung 14.2: Reverse-Proxy-Cluster

Der WebFarm-Standard sieht Reverse-Proxy-Clusters nur bei Anwendungen vor, die keine 99% Ausfallsicherheit verlangen, und nur dann, wenn eine getestete Proxy-Software verwendet wird, die nicht immer dem aktuellen Stand angepasst wird, sondern nur, wenn wieder entsprechende Tests durchgeführt wurden, angepasst wird.

215

Sandini Bib 14 Cluster-Management

14.1.3

Director-(Hardware)-Cluster

Die wohl performanteste Methode des Handlings der Cluster-Kontrolle sind so genannte Directors, die aus dem Routing-Bereich kommen und von verschiedenen Herstellern angeboten werden. Dabei wird mit einem Regelwerk auf zunächst relativ niedriger Ebene festgelegt, wann welche Adresse mit welcher Anfrage auf welchen Cluster-Rechner weitergeleitet wird. Zusätzlich verfügen die meisten Directors heute auch über die Möglichkeit, Cluster-Protokolle zu verwenden und so auch die Cluster-Maschinen bzw. deren Belastung mit in die Routing-Entscheidung einzubeziehen. Neue Betriebssysteme auf den Directors ermöglichen es, auch die meisten Funktionen eines Reverse-Proxys abzudecken. Auf jeden Fall sind SessionHandling, URL-Redirection usw. heute bereits Standardfunktionen. Hardware-Directors sind auf jeden Fall die performanteste Methode, einen Cluster in Richtung der Außenwelt zu erzeugen. Diese Variante wird im WebFarmStandard bevorzugt.

Client Request

Client Client

Request Distriburtion

Client Cluster Server 1

Cluster Server 2

LAN

LAN

Network

Cluster Director

Cluster Server 3

Cluster Information Cluster Server 4

Abbildung 14.3: Director-Cluster

14.2 Content-Management für Cluster Das Content-Management für Cluster ist in einem System mit herkömmlichem (durch Publishing basiertes) Content-Management sehr komplett. Das WebFarm-Content-Management-Konzept unterstützt die Idee von Clustern von vornherein, so dass es, wenn die Anwendungen entsprechend entwickelt

216

Sandini Bib Content-Management für Cluster

wurden, auf Informationsseite auf keinen Fall zu Schwierigkeiten kommt, wenn nachträglich ein Cluster eingerichtet werden soll. Die verschiedenen Informationskategorien werden unterschiedlich abgedeckt.

14.2.1

Dynamische Informationen

Werden von Anwendungen selbst erzeugt oder durch Application-Server dargestellt. Für Anwendungen gelten die weiter unten aufgeführten Entwicklungsvoraussetzungen. Werden nur Informationen generiert, ist es auf jeden Fall wichtig, dass eine Belastung der Datenquelle ab einem gewissen Niveau ebenfalls zu verteilen ist. Die Notwendigkeit eines Clustering entsteht oft durch die Verwendung von vielen dynamischen Informationen, die für jeden Abruf neu in Echtzeit generiert werden. Es ist auf jeden Fall zu überlegen, ob diese Informationen derart echtzeitbehaftet sind oder ob es einen anderen Weg gibt, diese darzustellen und so eventuell das teure Erstellen eines Clusters vermeiden zu können. Da dynamische Informationen nicht direkt durch das Content-Management erstellt werden, sondern lediglich die entsprechenden Seiten und Programme als statische Informationen auf die Server einfließen, trifft für die Verteilung dieser Anwendung der Absatz dieses Kapitels über statische Informationen zu. Die Anwendungen müssen, wie bereits erwähnt, entsprechend entwickelt sein.

14.2.2

Semi-dynamische Informationen

Die Integration von Informationen, die über das Content-Pool-System des WebFarm«-Content-Management-Systems verbreitet werden, in eine ClusterUmgebung ist sehr trivial, da das Content-Pool-System der WebFarm-Standard ohnehin dafür vorgesehen ist, Informationen mehrfach zu verteilen und diese nicht nur einmal einzusetzen. Im Gegensatz zu anderen Anwendungen, die mit den gleichen Informationen aus dem Content-Pool versorgt werden, muss bei einem Cluster die Konfiguration für jedes System nicht neu erstellt werden, da sich die Systeme ja nicht an Informationen, Struktur oder Layout unterscheiden sollen. Die Konfigurationen werden also nur einmal erstellt und dann kopiert, auf diese Weise sind alle Systeme gleich konfiguriert und werden mit eingehenden Informationen gleich umgehen. Es bietet sich hier an, eine Mastermaschine im Cluster zu etablieren, von der aus automatisch in regelmäßigen Abständen die Konfigurationen an die anderen Systeme verteilt werden, wenn das eingesetzte Content-Pool-System nicht ohnehin ein Cluster-Modell unterstützt. Der Content-Pool seinerseits wird so konfiguriert, dass er an alle Systeme des Clusters exakt die gleichen Informationen verteilt.

217

Sandini Bib 14 Cluster-Management

Mit diesen einfachen Aktionen ist eine vollständige clusterfähige Informationsanwendung realisierbar. Es ist also offensichtlich, dass bei diesem Vorgehen auch nachträglich ein Cluster für eine Anwendung eingesetzt werden kann.

14.2.3

Statische Informationen

Statische Informationen werden ebenfalls durch das Content-ManagementSystem der WebFarm, in diesem Fall über das Redaktionssystem, verwaltet. Es geht hierbei sowohl um statisches HTML/XML als auch um Programme, Vorlagen usw. Diese Informationen werden vom Redaktionssystem ganz normal in den Redaktionsprozess übergeben und auf ein Pre-Production-System zur Freigabe bereitgestellt. Sind die Informationen freigegeben, wird das System für einen Cluster so konfiguriert, dass es die Informationen nicht nur an eine oder zwei Maschinen weiterkopiert, sondern an alle Maschinen des Clusters. Auch hier sind alle Systeme im Cluster von Content-Management-Seiten gleich konfiguriert, so dass keine Differenzen im lokalen Handling der eingehenden Packages auftreten können. Auch hier ist es offensichtlich, dass es sich um eine einfache Konfiguration handelt, die sehr schnell durchgeführt werden kann.

Agent Cluster Server 1 LAN Cluster Director

LAN

Cluster Server 2

Send Static Update Cluster Server 3

Cluster Server 4

Content Management Server Permit

Publish to PRE-Production Editor

Replicate to Cluster Publish to Production

Abbildung 14.4: Übergabe statischer Informationen

Das Content-Management-Konzept der WebFarm-ermöglicht es, also auch für diese Gruppe von Informationen einfach auf einen Cluster umzusteigen, wenn dies erforderlich wird, ohne dass dabei komplexe Regeln beachtet werden müssen oder bestehende Anwendungen bzw. deren Funktionalität beeinflusst würden.

218

Sandini Bib Entwicklungsvoraussetzungen für Cluster

14.3 Entwicklungsvoraussetzungen für Cluster Die grundsätzlichen Entwicklungsvoraussetzungen für Cluster sind mit dem normalen Backup-Verfahren der WebFarm bereits gegeben, da diese auch für das Backup-Verfahren benötigt werden. Es gibt zusätzliche Punkte, die im Cluster zu beachten sind, die aber keine weitere Verschärfung oder Einschränkung bei der Entwicklung bedeuten.

14.3.1

Datengenerierung

Werden Daten von der Anwendung generiert, so ist die Anwendung auf jeder Maschine des Clusters dafür verantwortlich, dass diese Daten auch den anderen Servern des Clusters zur Verfügung stehen, damit tatsächlich ein Sharing für die Benutzer in mehreren Sessions erreicht werden kann. Dies geschieht entweder, indem ein zentrales Datenbank-Backend von allen Servern des Clusters verwendet wird, oder indem lokale Applikationsdatenbanken so konfiguriert sind, dass sie sich in Echtzeit mit anderen Datenbanken des Clusters abgleichen. Dies kann z.B. über die in der Datenbank implementierten Replikationsfunktionen oder durch definierte Stored-Procedures geschehen. Handelt es sich bei den generierten Informationen nicht um Datenbankinformationen, sondern z.B. um Textdateien, oder andere Informationen, müssen sie in regelmäßigen Abständen zwischen den Servern auf Anwendungsebene synchronisiert werden und zu einem gemeinsamen Datenbestand zusammengefasst werden.

14.3.2

Vernetzungsvoraussetzungen

Es ist sinnvoll, auf absolute Vernetzungen in einer Cluster-Umgebung zu verzichten. Diese Vernetzungen und Verweise sind in HTML, XML-Applet oder Skript-Code zu finden. Viele Programme und Applets verwenden absolute Pfade, um auf jeden Fall ihre Anwendung wieder zu verwenden, was bei Clustern, da die tatsächliche Verbindung zu einem Rechner in einem bestimmten Adressbereich aufgebaut wird, sehr schnell zu Session-, aber auch zu Permission-Problemen führen kann. Der WebFarm-Standard schreibt darum vor, nur relative Links zu verwenden, die keinen Rechnernamen enthalten. Ist dies nicht zu umgehen, muss auf jeden Fall über die Cluster-Management-Maschine gegangen werden, die entsprechende Weiterleitungsmechanismen z.B. für Datenbankverbindungen bereithält und die Sessionmaschine des Benutzers identifizieren kann.

219

Sandini Bib

Sandini Bib

15

Secure-Content

Die Bereitstellung von sicherem Content ist in allen Fällen der Geschäftsabwicklung oder der direkt das Primärgeschäft unterstützenden Anwendungen ein Thema. Es sollte eher zu viel gesichert werden als zu wenig. Im Folgenden sollen die Verfahren zur Absicherung von Content nach dem WebFarm-Standard dargestellt werden, die leicht in die Applikationsentwicklung eingebracht werden können.

15.1 Sicherheitsverfahren Grundsätzlich muss zwischen zwei verschiedenen Bereichen in der Absicherung von Anwendungen unterschieden werden, die sich ergänzen, aber auch unabhängig voneinander eingesetzt werden können. Diese sind die Identifikation und die Berechtigung von Benutzern und die Sicherung der Übertragung.

15.1.1

Authentifizierung

Die Benutzer in einer Anwendung müssen einwandfrei identifiziert werden und mit Berechtigungen entsprechend ihrer Rolle versehen werden. Die Verfahren zur Authentifizierung und vor allem zum Management von Rechten usw. sind bereits in den entsprechenden Infrastrukturkapiteln des WebFarmStandards beschrieben. Hier geht es mehr um die Einbettung dieser Verfahren oder die Bestimmung spezieller Verfahren in die Entwicklung von Webanwendungen. Zertifikatsverfahren sind sehr einfach zu implementieren, da hier einfach eine Verbindung vom Webserver zum LDAP-Server hergestellt werden muss und die entsprechenden Rollenberechtigungen in den Webservern selbst konfiguriert werden müssen. Sollen weitere Verfahren, z.B. Challenge-Response-Verfahren, eingesetzt werden, so unterstützt der WebFarm-Standard keine PIN/TAN-Verfahren, da diese keinen echten Sicherheitsgewinn bringen. Es können Verfahren mit Hardwaregenerierung von Kennungen eingesetzt werden, wie z.B. SecureID. Bei diesen Verfahren übersendet der Server zusätzlich zur Zertifkat- oder Passwortidentifikation einen Challenge an den Benutzer, der diesen dann zusammen mit persönlichen Daten (Passwort oder bei Hochsicherheitsver-

221

Sandini Bib 15 Secure-Content

fahren Fingerabdruck oder Ähnliches) in ein Gerät (SecureID = ScheckkartenTaschenrechner) überträgt, eine Antwort erhält, die zurück an den Server übertragen wird und somit diese Verbindung legalisiert. Der Einsatz solcher Verfahren kann zur legalen Konfirmation von digitalen Unterschriften eingesetzt werden oder auch in echten Hochsicherheitsbereichen, die sich direkt auf das Primärgeschäft im größeren Umfang auswirken können. Für normale Sicherheitsanwendungen ist es zu überlegen, ob derart teure Lösungen zusätzlich verwendet werden sollen. Der WebFarm-Standard rät von der Verwendung von hardwarebasierten Verfahren wie ME-Chip, Fingerprint, ChipCard usw. in Massenanwendungen ab, solange diese Verfahren nicht in einem normalen Computer integriert sind. Bei internen Anwendungen und eventuell auch bei Anwendungen bei Partnern, bei denen die Ausstattung und Konfiguration von Arbeitsstationen kontrolliert werden kann, können solche Verfahren für Hochsicherheitsanwendungen eingesetzt werden.

15.1.2

Übertragungssicherung

Diese Sicherheit wird im Allgemeinen durch Verschlüsselung erreicht. Wenn eine Verbindung zu Partnern entstehen soll, ist auch an eine VPN-Lösung zu denken, wenn keine Punkt-zu-Punkt-Sicherheit vorgesehen ist, sondern lediglich die Abdeckung von Risiken, wenn Verbindungen über andere Leitungsnetze geschickt werden. Es ist keine Sicherheit, wenn es sich um dedizierte Leitungen handelt, da auch diese abgehört werden können, darum muss auch auf solchen Leitungen nach dem WebFarm-Standard Verschlüsselung betrieben werden.

15.2 Verschlüsselung Da Verschlüsselung ein wesentlicher Bestandteil der Übertragung von sicheren Daten ist und die Verbindung zum Angebot möglichst offen gehalten werden soll, ist es sinnvoll, für alle Anwendungen mit Sicherheitsrelevanz und alle Übertragungen, die kritische Daten enthalten, ein Standardverfahren zu verwenden, das modular aufgebaut ist. Hier bietet sich SSL (Secure Socket Layer), entwickelt von Netscape, an, das unterschiedliche Verschlüsselungsalgorithmen verwenden kann und entsprechend der kryptographischen Entwicklung in den Server- und Browserprodukten angepasst wird. Die Verwendung dieses Verfahrens hat den Vorteil, dass keinerlei Konfigurationen beim Client vorgenommen werden müssen. Die bekannten Exportrestriktionen der USA greifen im Falle dieser Anwendung nicht, da Unternehmen der Finanzbranche mit den letzten Gesetzesnovellen von den Exportrestrik-

222

Sandini Bib SSL

tionen befreit wurden. Es bleibt allerdings festzuhalten, dass in anderen Ländern Verschlüsselung durchaus ein juristisches Problem darstellt, was bei einer global eingesetzten Anwendung durchaus ein Problem sein kann; als Beispiel seien hier sowohl als Frankreich und Australien auch China genannt. Bei massivem Einsatz in diesen Gebieten werden Ausnahmegenehmigungen beantragt werden müssen, die üblicherweise für den Finanzsektor problemlos zu erhalten sind.

15.3 SSL Im Folgenden soll eine kurze Beschreibung der Prinzipien von SSL, Secure Socket Layer, gegeben werden, die das grundsätzliche Verständnis für die Verschlüsselungsschicht stärkt. Es ist wichtig zu beachten, dass SSL nicht abhängig von Verschlüsselungsalgorithmen ist; diese können modular eingesetzt und ausgetauscht werden, wenn zukünftige Entwicklungen bisherige Algorithmen als unsicher erscheinen lassen. SSL legt, wie der Name andeutet, eine zusätzliche Schicht zwischen die zuverlässige Transportebene TCP/IP und die Anwendungsebene (HTTP, Telnet, FTP,…). Von »oben« gesehen ist sie transparent, d.h., die Anwendungsprogramme können ohne große Modifikation auf eine sichere Übertragung zugreifen. Für die Transportschicht erscheint SSL hingegen als Anwendungsebene: HTTP

FTP

SMTP Usw.

SSL Sockets

Secure Virtual Connection Unsecure TCP/IP Connection

Hardware

Physical Connection

HTTP

FTP

SMTP Usw.

SSL Sockets Hardware

Abbildung 15.1: Verbindung über SSL

Der Verbindungsaufbau Der Verbindungsaufbau läuft in vier Schritten ab: 1. In der so genannten »Hello«-Phase baut der Client eine Verbindung zum Server auf und teilt ihm mit, welche Kryptographie-Algorithmen er unterstützt. 2. Der Server wählt daraus ein Public-Key-, ein Privat-Key- und ein HashVerfahren aus und teilt sie dem Client mit. Gleichzeitig sendet der Server ein Zertifikat, das unter anderem den öffentlichen Schlüssel des Servers enthält. Mit Hilfe des Zertifikats kann der Client überprüfen, ob die Antwort tatsächlich vom gewünschten Server stammt.

223

Sandini Bib 15 Secure-Content

3. Der Client bzw. Browser generiert automatisch einen Sitzungsschlüssel (Session-Key) für einen Datenaustausch per Private-Key-Verfahren. Aus Geschwindigkeitsgründen werden standardmäßig symmetrische Verfahren verwendet (hier: RC4). Der dazu notwendige Schlüsselaustausch wird durch Verschlüsselung mit den in den Zertifikaten enthaltenen öffentlichen Schlüsseln geschützt. Diesen chiffrierten Schlüssel schickt der Client an den Server. 4. In der abschließenden Authentifizierungsphase authentifiziert der Client den Server, indem er ihm eine Reihe von mit dem Sitzungsschlüssel chiffrierten zufälligen Testnachrichten schickt, die der Server nur dann korrekt dechiffrieren und bestätigen kann, wenn es sich um den »echten« Server handelt. In einem optionalen Schritt kann der Server auf vergleichbare Weise den Client authentifizieren. Die Client-Authentifikation funktioniert nur dann, wenn der Client über ein offiziell registriertes Zertifikat verfügt. Damit ist der Initiale Verbindungsaufbau abgeschlossen. Anschließend können die eigentlichen Daten geschützt übertragen werden. Die Verschlüsselung im Einzelnen Die zu übertragenden Daten werden in kleine Blöcke geteilt, die auch noch komprimiert werden können, was die Schnelligkeit und auch die kryptographische Sicherheit weiter erhöht. Die Blocknummer wird hinzugefügt und durch Hash-Funktion eine Prüfsumme angehängt. Abschließend wird mit dem symmetrischen Verfahren, üblicherweise dem schnellen Stromchiffrierer RC4, verschlüsselt. Sollten beim Empfang Ungereimtheiten auftreten (falsche Prüfsummen), wird dies auf eine versuchte Manipulation zurückgeführt, da dem Übertragungsprotokoll TCP/IP vertraut wird. Daraufhin wird eine verschlüsselte Fehlernachricht versandt und die Verbindung abgebrochen.

15.3.1

Andere Verfahren

Grundsätzlich existieren andere Verfahren zur Verschlüsselung, die auch standardisiert sind, z.B. HTTP. Diese Verfahren sind allerdings nicht verbreitet und scheiden daher im WebFarm-Standard für eine allgemeine Verwendung im Rahmen von Applikationsprojekten aus. Sollte die Verschlüsselung, die standardmäßig in Browsern und Servern eingebaut ist, aus wichtigen Gründen nicht ausreichen, was sicherlich nicht oft der Fall ist, sollte eine eigene Applikation mit eigenständiger Verschlüsselung z.B. in Java verwendet werden. Es ist hier unbedingt darauf zu achten, eine getestete Implementation des Verschlüsselungsverfahrens zu verwenden, sprich keine Eigenentwicklung anzustoßen, da die meisten Sicherheitslücken in Verbindungen keine Probleme der Verschlüsselungsverfahren, sondern der Implementation sind.

224

Sandini Bib SSL

Es ist auf jeden Fall zu beachten, dass der verwendete Zufallszahlenalgorithmus für die Qualität des Verfahrens ausschlaggebend ist.

15.3.2

Empfehlung

Da die Verfügbarkeit von Verfahren neben der Sicherheit ein entscheidender Erfolgsfaktor ist, schlagen wir vor, das SSL-Verfahren zur Verschlüsselung einzusetzen. Dieses Verfahren ist der allgemein anerkannte Standard im Bereich der Neuen Medien und ist flexibel und skalierbar auch für zukünftige Anwendungen im Bereich der Kryptographie. Es ist zukünftig darauf zu achten, dass aktuelle Versionen von Servern und Browsern verwendet und ggf. die Zertifikate und Schlüssel der Browser und Server ausgetauscht werden, wenn diese mit größerer Schlüssellänge verfügbar werden. Sollten zusätzliche Verfahren erforderlich werden, sollten Standardbibliotheken, wie z.B. bei RSA Inc. erhältlich, eingesetzt werden, um keine Risiken in der Implementierung einzugehen. Solche Verfahren müssen in plattformunabhängigen Applikationen eingestellt werden, da hier nicht auf die Verfügbarkeit von Standardsoftware vertraut werden kann. Momentan bedeutet das eine Entwicklung eigener Verfahren unter Java. Es ist unbedingt abzuwägen, ob eine Eigenentwicklung tatsächlich erforderlich ist, da sie große Sicherheitsrisiken birgt. Womöglich sollte, wie bereits betont, das Standardverfahren eingesetzt werden.

Abbildung 15.2: Zusammenhang zwischen Security-Level und Authentication-Method

225

Sandini Bib

Sandini Bib

16

HTML-Style

Dieses Dokument zeigt in kurzen Stichpunkten auf, wie guter HTML-Code aussehen sollte. Hierbei wird nicht auf Generatoren Rücksicht genommen. Die im WebFarm-Standard empfohlenen HTML-Generatoren entsprechen in großen Zügen diesen Vorgaben und erzeugen somit HTML, das auch bei der Nachbearbeitung von Anwendungen noch verständlich ist. Der Text ist absichtlich stichpunktartig gehalten, weil er eindeutige und einfache Regeln aufstellen will, die es einem Entwickler einfach ermöglichen, HTML zu schreiben, das durch die im WebFarm-Standard-Content-Management-System enthaltenen Prüfungen nicht zurückgewiesen wird. Diese klaren Stichpunkte sind für den Entwickler bei der Arbeit gedacht und sollen keine Philosophie des Programmierens aufstellen.

16.1 Tags und Attribute Alle Tags und Attribute sollten komplett großgeschrieben werden. Dadurch wird das Navigieren im HTML-Source-Code stark vereinfacht. <TITLE> Testtitel Testtext

Alle Attributwerte, die durch HTML fest vorgegeben sind, sollen komplett in Großbuchstaben geschrieben werden.

Alle String-Attribute sollten in doppelte Anführungszeichen eingeschlossen werden.

Alle HTML-Tags sollten, auch wenn das viele HTML-Browser nicht erfordern, soweit vorhanden, mit ihren entsprechenden Endtags versehen werden.

• Das ist der 1. Punkt
• Das ist der 2. Punkt

227

Sandini Bib 16 HTML-Style

Alle selbst definierten Attribute sollten, soweit möglich, komplett kleingeschrieben sein.

Alle Protokollnamen sollten kleingeschrieben sein.

Eine sinnvolle Einrückung des Source-Codes hilft beim Navigieren.

Überschrift	Überschrift
Daten	Daten

Sonderzeichen sollten auf jeden Fall mit den URI-Encodings dargestellt werden. Sonderzeichen, die nicht so darstellbar sind, sollten nicht verwendet werden. " Ü " Das ist ein großer Umlaut U in doppelten Anführungsstrichen.

Eingefügte Kommentare sollten vom Autor oder Generator gekennzeichnet sein

HTML-Spezifika bestimmter Browser sollten nur, wenn unbedingt notwendig, verwendet werden. Der Tag sollte gar nicht verwendet werden. Überschriften sollten auf jeden Fall mit den dafür vorgesehenen HTML-Tags dargestellt werden. Eine Verwendung von ist nicht korrekt. Die Verwendung des FACE-Attributs im -Tag ist meistens nicht sinnvoll.

16.2 Pfade und Dateinamen Alle Dateinamen sollten groß-/kleinschreibungssensitiv erstellt werden. So unterstützen z.B. die Netscape-Serverprodukte die Endung .GIF nicht, wohingegen .gif erkannt wird (siehe MIME-Types).

228

Sandini Bib HTML-Generatoren

Alle Links auf verwandte Dokumente sollten, soweit dies überhaupt möglich ist, relativ sein. Querverweis

16.3 HTML-Generatoren Soweit es unterstützt wird, sollten HTML-Generatoren keine Copyright-Verweise in den erzeugten HTML-Code einbringen. HTML-Generatoren sollten sauberen und nicht überfüllten Code erzeugen. Der MS-Internet-Assistant für Word tut dies z.B. nicht, indem er für jede Tabellenzelle in einer Tabelle den -Tag angibt. Ein guter HTML-Editor im WYSIWYG kann die Ansicht einer Seite und deren Code mit einer Codedarstellung, wie man sie aus Entwicklungsumgebungen gewohnt ist, darstellen. Dies hilft dem Autor, sofort zu erkennen, wo eventuelle Probleme auftreten können, wo Optimierungspotential vorhanden ist und wie der erzeugte Code letztendlich beim Benutzer ankommt.

Abbildung 16.1: WYSIWYG-HTML-Editor

229

Sandini Bib 16 HTML-Style

16.4 Test des Codes

Abbildung 16.2: Der Code angezeigt in Microsoft IE und Netscape

Auf jeden Fall sollte der Code vorher mit unterschiedlichen Browsern getestet werden. Die ursprüngliche Idee, völlig browserunabhängig zu sein, lässt sich bei den heutigen Designanforderungen an Webseiten leider nicht mehr umsetzen. Getestet werden muss aber auf jeden Fall mit Internet Explorer von Microsoft und mit Navigator von Netscape, denn hier können kleine Unterschiede in der Formatierung auftreten, deren man sich zumindest bewusst sein muss. Diese Vergleiche ergeben, dass selbst bei guter Darstellung auf unterschiedlichen Browsern Unterschiede vor allem im Spaceing zwischen einzelnen Elementen vorhanden sind, was für ein Layout sehr wichtig ist. Diese Eigenarten des HTML-Designs müssen bei der Ausführung von gestalterischen und grafischen Ideen immer berücksichtigt werden. Beim Design muss auch auf die Bildschirmdarstellung geachtet werden. Es erscheint wenig sinnvoll, Webanwendungen für Arbeitsplätze, wie sie üblicherweise bei Webdesignern vorhanden sind, auszulegen. Hier würde eine

230

Sandini Bib Style und Layout – Wo abgelegt?

Auflösung von mindestens 1.200 Pixeln in der Horizontalen vorausgesetzt, werden, was ein normaler Arbeitsplatz in einem Unternehmen nicht leisten kann. Generell ist es so, dass die Heimcomputer zu den meisten Zeitpunkten besser ausgestattet sind, als Computer, die in einem Unternehmen stehen. Dies liegt zum einen an der Abschreibungslogik bei angeschaffter oder geleaster Hardware, zum anderen in der Verwendung der Rechner, denn es ist generell so, dass Spiele und Unterhaltungs-anwendungen wesentlich mehr Systemressourcen erfordern als »gewöhnliche« Arbeit. Es muss darum darauf geachtet werden, dass das Zielpublikum einer Anwendung zunächst betrachtet und deren typische Hardwarekonfiguration ermittelt wird, damit entsprechende Rahmenparameter für ein Design entstehen.

16.5 Style und Layout – Wo abgelegt? Das Layout und damit der Stil, den eine Informationsanwendung im Web nach außen zeigt, muss irgendwo in der Anwendung, also in den Seiten der Anwendung abgelegt sein. Klassischerweise war dieser Style in jeder einzelnen Seite abgelegt, was das zustandslose Protokoll des HTTP unterstützte. Der Nachteil dieses Vorgehens, in jeder Seite den Style von neuem abzulegen, ist offensichtlich: Erstens wird sehr viel Overhead geschaffen, nur um immer wieder die gleichen Informationen, wie z.B. das Aussehen einer Überschrift, über das Netz zu transportieren; zweitens ist es sehr aufwändig, den style, wenn auch nur geringfügig, anzupassen. Die Webtechnologie hat hierzu das Konzept der Cascading Style Sheets hervorgebracht. Hierbei werden generelle Formatanweisungen in einer Datei zusammengefasst, die dann referenziert wird über Namen, die bestimmten Formaten gegeben wurden oder die bereits per Default vordefiniert sind. Diese Stylesheets können hintereinander geschaltet – kaskadiert – werden und ermöglichen so, auch komplexe Formatvorlagen ähnlich der Vorlagen in Textverarbeitungen oder gar Layoutsystemen zu unterstützen und für ein Medium darzustellen.

16.6 Extensions HTML-Extensions sind ein großer Streitpunkt bei den Designern von Webanwendungen. Grundsätzlich lässt sich aber sagen, je mehr Extensions verwendet werden, desto proprietärer wird der Code. Es ist nur in sehr wenigen Fällen sinnvoll, auf Plug-in-Technologie für die Darstellung von ganzen Sites oder Anwendungen zu setzen. Macromedia Flash ist ein Beispiel für eine gute Plug-in-Technologie, die, richtig angewendet, sehr gute Resultate hervor-

231

Sandini Bib 16 HTML-Style

bringt, aber sicherlich nicht geschaffen wurde, um komplette Webanwendungen zu beherbergen. Flash z.B. soll interaktive Multimedia-Shows darstellen und nicht Informationssysteme, was sich im Bereich der direkten Produktmarketing einsetzen lässt (z.B. Automobilpräsentation). Eine andere sinnvolle Möglichkeit von Extensions ist die 3D-Visualisierung, die sich derzeit im Web weiterentwickelt und die neue Möglichkeiten der kondensierten Darstellung von Daten auch auf verschiedenen Aggregationsebenen erlaubt.

Abbildung 16.3: 3D-Visualisierung

Es ist hingegen wenig sinnvoll, einfach aufwändige 3D-Anwendungen nur zur Navigation in einer simplen Anwendung zu verwenden. Es ist wichtig, solche Extensions nur einzusetzen, wenn sie auch tatsächlich sinnvoll sind. »Sinnvoll« in diesem Zusammenhang zu definieren ist nicht einfach, denn das Web eröffnet Unmengen an kreativen Möglichkeiten. Sinnvoll ist aber grundsätzlich immer das, was einem Benutzer echten Mehrwert und nicht nur Spielerei bringt, denn die Spielerei ist gerade im geschäftlichen Umfeld ein einziges Mal attraktiv, dann ist der Overhead, den sie produziert, nicht mehr wert.

232

Sandini Bib Extensions

Ein exotischeres Beispiel für Extension von Webanwendungen ist the Brain; eine Art, Sites zu navigieren und zu organisieren, die einem Mind-MappingWerkzeug nachempfunden ist und somit kreative Informationsaufnahme durch den Benutzer, psychologisch nachgewiesen, unterstützt.

Abbildung 16.4: The Brain Navigation

Grundsätzlich nicht eingesetzt werden sollten solche HTML-Extensions, die den Benutzer oder den Entwickler an eine spezifische Plattform binden. Zum Beispiel ist VBScript nur unter Microsofts Internet Plattformen verwendbar und birgt zudem sehr viele Sicherheitsrisiken. VBScript ist hier aber nur ein Beispiel, denn auch anderen Browser- und Server-Hersteller haben den Weg der proprietären Funktionalitäten gewählt, um eine Kundenbindung zu erreichen. Dieses Vorgehen kann im Rahmen des WebFarm-Standards nicht unterstützt werden, da es die Benutzer und/oder Entwickler zu sehr festlegt und oft für Entwicklungen Informationen voraussetzt, die ein Entwickler unmöglich haben kann.

233

Sandini Bib

Sandini Bib

17

XML

In diesem Kapitel werden zunächst die Funktionsweise und Anwendungsmöglichkeiten des XML-Standards beschrieben. Er ermöglicht den Austausch, die Nutzung und Wiederverwendung von Daten zwischen unterschiedlichen Softwareumgebungen und bildet, durch seine frei definierbare Struktur, eine generelle Schnittstellenmöglichkeit für zukunftssichere Webinfrastrukturen. Da XML heute noch seltener Anwendung findet, aber ein sehr großes Potenzial hat, ist der WebFarm-Standard vollständig auf die Verwendung von XML-gestützten Anwendungs- und Infrastrukturprozessen ausgerichtet, setzt aber nur dort, wo es auch heute schon sinnvoll ist, auch XML-basierende Technologie voraus. Alle für den Datenaustausch, das Content-Management und die Anwendungsabbildung verwendeten Konzepte, Verfahren und Werkzeuge, die durch den WebFarm-Standard definiert werden, sind auf die Verwendung von XML ausgerichtet, wenn sich dieser Standard als Brücke zwischen Anwendungen und Backend-Systemen oder allgemein zwischen Systemen oder auch zwischen Benutzern und Systemen anbietet.

17.1 XML-Einführung Die Extensible-Markup-Language XML ist eine textbasierte Metasprache, die es ermöglicht, Daten bzw. Dokumente zu beschreiben und zu strukturieren, so dass sie zwischen einer Vielzahl von Anwendungen ausgetauscht und weiterverarbeitet werden können. Mit XML kodierte Daten bilden eine Grundlage für verschiedenste EDI- oder E-Commerce-Anwendungen auf der Schnittstellenebene.

17.1.1

XML – Die Vision

In HTML, der für die Darstellung von Webanwendungen verwendeten Sprache, fehlte bislang eine Möglichkeit, Daten frei definierbar strukturiert zu beschreiben. XML könnte sich zu einem zukünftigen Standard zur Datenbeschreibung im Internet entwickeln. XML ist eine Metasprache, welche die Beschreibung, den Austausch, die Darstellung und die Manipulation von strukturierten Daten erlaubt, so dass diese von einer Vielzahl von Anwendungen genutzt werden können. XML ist

235

Sandini Bib 17 XML

»extensible«, da es sich im Gegensatz zu HTML nicht um ein festes Format im Sinne einer bestimmten Metasprache, sondern vielmehr um eine übergeordnete Metasprache handelt, die Vorschriften bereitstellt, um beliebige andere Metasprachen für individuelle Datenübertragungen und Anwendungen zu definieren. XML ermöglicht allgemein die flexible Weiterverwendung von Daten.

17.1.2

XML – Die Entwicklung

Probleme der HTML-Entwicklung HTML ist aufgrund seines wissenschaftlichen Ursprungs eigentlich vornehmlich eine Präsentationsbeschreibungssprache. Der Vorteil von HTML liegt in der Einfachheit. Die Sprache besteht in der Version 3.2 aus ca. 70 Tags und über 50 Attributen. Durch den kommerziellen Erfolg des WWW und durch wachsende Möglichkeiten und Anforderungen an den Datenaustausch über das Internet wurde deutlich, dass sich HTML nicht für den Einsatz als Datenschnittstelle eignet. Die ursprüngliche Aufgabe der strukturierten Darstellung von Daten trat immer mehr in den Hintergrund. HTML wird heute vor allem zur Darstellung grafisch aufwändiger und vollkommen designter Anwendungen benutzt, was dem ursprünglichen Verwendungszweck widerspricht. Auch die Weiterentwicklungen von HTML können gerade im Bereich des Datenaustauschs zwischen Applikationen (Computer-Communication) nicht verwendet werden. Durch die Verwendung von HTML zur Übertragung von Daten geht die innere Struktur der Daten verloren. Komplexere Strukturen, wie z.B. Relationen in einer Datenbank oder Objekthierarchien, sind nicht abbildbar. Weiterhin ist es mit HTML nicht möglich, Daten semantisch auszuwerten, d.h., den Dokumenten Informationen über ihren Inhalt mitzugeben. HTML

XML

<strong>Perlman, Radia Interconnections – Routers and Bridges

Perlman, Radia <TITEL> Interconnections – Routers Bridges

Tab. 17.1: Vergleich HTML und XML

236

and

Sandini Bib XML-Einführung

HTML HTML hat seine Defizite vor allem im Bereich der Datenübertragung, denn es können weder die Datenstruktur noch die Methodik zur Validierung der übertragenen Daten in den Code eingebettet werden, was aber gerade bei einer Verbindung von Systemen, eine zwingende Anforderung für eine zukunftssichere IT-Strategie wie dem WebFarm-Standard ist. SGML Mit SGML (Standard Generalized Markup Language) existiert seit über zehn Jahren, ein internationaler Standard zur Definition, Identifikation und Benutzung der Struktur und des Inhalts von Informationen. Als Übersprache definiert SGML eine Syntax, um andere Metasprachen zu definieren. SGML dient also als Basis für die verschiedensten Sprachen und ist damit eine äußerst flexible Architektur. HTML ist eine Anwendung von SGML; alle bisherigen HTML-Versionen wurden in SGML definiert. SGML ist allerdings ein rein wissenschaftliches und sehr fortschrittliches Produkt, was die Anwendung im kommerziellen Bereich sehr komplex und teuer gestaltet und daher den direkten Einsatz von SGML in großen kommerziellen und nicht auf Drucksteuerung fokussierten Umfeldern nicht gestattet. Auf der anderen Seite ist HTML aufgrund der fehlenden Erweiterbarkeit für komplexere Anwendungen ungeeignet. Hier setzt die Extensible Markup Language (XML) an. Mit dem im Februar 1998 vom World Wide Web Consortium (W3C) als Standard verabschiedeten Sprachkonzept wird versucht, eine für das Internet geeignete Metasprache zu etablieren, welche die Funktionalität von SGML für das Web bietet, ohne die Komplexität von SGML für die Entwicklung zu fordern. Wie bei SGML handelt es sich um eine Metasprache. Um die Komplexität zu reduzieren, wurden alle für das Internet als überflüssig angesehenen SGMLEigenschaften sowie eine Vielzahl als zu kompliziert erachteter und zu selten genutzter Features nicht in XML übernommen. So findet die formale Definition von XML auf 33 Druckseiten Platz; die von SGML benötigt mehr als 500 Seiten. Wie mit SGML ist es auch mit XML möglich, eigene Sprachen zu entwickeln.

17.1.3

XML – Die Sprache

Das Sprachkonzept XML ist eine textbasierte Metasprache, welche die Beschreibung, den Austausch, die Darstellung und die Manipulation von strukturierten Daten erlaubt, so dass diese von einer Vielzahl von Anwendungen genutzt werden können.

237

Sandini Bib 17 XML

XML basiert genau wie SGML auf der Idee des strukturierten Auszeichnens von Daten. Das Grundkonzept von XML ist die Trennung von Inhalt, Struktur und Layout. XML-Dokumente unterscheiden sich auf den ersten Blick nicht wesentlich von HTML-Dokumenten. In HTML ist die Anzahl und die Namensgebung der Tags vorgegeben, in XML hingegen können beliebig viele und frei benannte Tags verwendet werden. Somit besteht der wesentliche Unterschied darin, dass die Tags Informationen über den Inhalt enthalten können und die Verschachtelung der Tags ineinander die Struktur der Daten abbilden kann. Die Unterschiede zwischen HTML und XML lassen sich kurz wie folgt zusammenfassen: 왘 Tags und Attribute können individuellen Anforderungen entsprechend

definiert und benannt werden. 왘 Dokumentenstrukturen können in beliebiger Komplexität abgebildet wer-

den. 왘 XML-Dokumente können eine formale Beschreibung ihrer Grammatik

enthalten, was in Zukunft für dynamische Datenverknüpfung (z.B. über Agententechnologie) verwendet werden kann. Um ein Dokument in XML zu beschreiben, werden Tags benötigt, die sich in Processing-Instructions, Dokumententypdefinitionen sowie Style-Sheets unterscheiden lassen. Die nächsten Abschnitte enthalten eine genauere Beschreibung dieser Grundlagen von XML. XML-Dokument-Struktur Die logische Struktur wird von der Anordnung der Tags im Dokument bestimmt. Die in einem XML-Dokument verwendeten Tags werden benutzt, um den Inhalt der Elemente zu gliedern. Ein XML-Dokument kann unabhängig von der logischen Struktur in Einheiten zerlegt werden. Dabei müssen alle in einer Einheit geöffneten Tags auch in dieser wieder geschlossen werden. Diese Möglichkeit bildet die Grundlage für verteilte Datenschnittstellen und Austauscharchitekturen. Style-Sheets Die Darstellung eines XML-Dokuments erfolgt über ein Stylesheet, dieses legt das Layout des Dokuments fest. Da XML eine eigene Definition der Tag-Sprache ist, kann eine normale Applikation, also ein Webbrowser, nicht von sich aus, wie das bei HTML der Fall ist, die Darstellung des XML-Dokuments vornehmen. Oft besteht der Irrglaube, dass jeder Browser jedes XML-Dokument darstellen kann, aber hier liegt die

238

Sandini Bib XML-Einführung

Hürde für den weit greifenden kommerziellen Einsatz auf allen Websites als Frontend-Sprache, denn für jede XML-Struktur muss dann ein Parser existieren, der diese darstellen kann. Durch Style-Sheets können Autoren und Nutzer von Webdokumenten deren Präsentation beeinflussen, ohne dabei auf geräte- oder anwendungsunabhängige Weiterverarbeitbarkeit verzichten zu müssen. Auf Style-Sheets wird durch entsprechende Processing-Instructions verwiesen, z.B. : . Das W3C definiert mit der Extensible Style Sheet Language (XSL) eine StyleSheet-Sprache für XML. XSL unterstützt auch Programmelemente, durch ECMA-Script, eine standardisierte Version von JavaScript, oder durch DSSSLFlow-Object-Klassen. Document-Type-Definition (DTD) Mit XML können eigene Sprachen definiert werden. Diese Grammatik kann auf zwei Arten beschrieben werden: Zu XML-Dokumenten kann eine explizite Definition der verwendeten Tags und ihrer Struktur gehören. Dies geschieht in XML durch eine formale Grammatik, die Document-Type-Definition (DTD). Wie in HTML auch können zu den einzelnen Tags Attribute definiert werden, die einen Tag näher beschreiben. Ein Dokument, dem eine DTD zugeordnet ist, wird als gültig bezeichnet, wenn in dem Dokument gegen keine der in der DTD definierten Regeln verstoßen wird. Entspricht das XML-Dokument nicht einer DTD, ist es aber ansonsten nach der eigentlichen XML-Definition syntaktisch korrekt, so wird von einem »well-formed Document« gesprochen, was bei der allgemeinen Darstellung hilfreich sein kann. Diese in XML grundlegend einzuhaltenden syntaktischen Regeln lassen sich wie folgt zusammenfassen: 왘 Jeder geöffnete Tag muss geschlossen werden. 왘 Tags ohne Inhalt (wie in HTML) müssen in XML entweder explizit

geschlossen werden oder mit /> enden. Beispielsweise wird aus
entweder
oder

. 왘 Attributwerte müssen in doppelte Anführungszeichen gesetzt werden,

z.B.: . 왘 Das Markup muss, wie bei SGML, streng hierarchisch gegliedert sein. 왘 Weiterhin dürfen keine Markup-Zeichen (< oder &) im Text vorkommen.

239

Sandini Bib 17 XML

왘 Alle Attribute, die für alle Elemente verwendet werden, müssen vom

Default-Typ PCDATA sein. 왘 Am Anfang des Dokuments sollte der Hinweis auf die XML-Version erfol-

gen: .
BESTELLUNG AUFTRAGSKOPF NAME VORNAME E-MAIL DATUM AUFTRAGSPOSITIONEN POSITION BEZEICHNUNG ARTIKELNUMMER ANZAHL

(AUFTRAGSKOPF, AUFTRAGSPOSITIONEN)> (NAME, VORNAME, E-MAIL, DATUM)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (POSITION)+> (BEZEICHNUNG, ARTIKELNUMMER, ANZAHL)> (#PCDATA)> (#PCDATA)> (#PCDATA)>

Mustermann HEINZ <E-MAIL>[email protected] 01.03.2001 Festplatte 123456 5 Monitor 4711 1

Mustermann HEINZ <E-MAIL>[email protected] 01.03.2001 Festplatte 123456 5 Monitor 4711 1

Abbildung 17.1: XML DTD und Umsetzung

240

Sandini Bib XML-Einführung

Die DTD kann in das XML-Dokument eingefügt werden oder mit eines Links referenziert werden, z.B. mit: . In der DTD wird festgelegt, welche Tags verwendet werden können und wie diese ineinander geschachtelt werden. Mit Hilfe der DTD ist es den individuell für diese XML-Dokumente erzeugten Programmen nun möglich, ein XMLDokument auf strukturelle Fehler zu überprüfen oder eine neue Instanz dieses Dokumenttyps zu bilden. Eine DTD muss erstellt werden, wenn mehrere Instanzen angelegt werden sollen. Dabei dient die DTD als allgemeines Muster, das Angaben enthält, die durch eine Instanz benutzt werden müssen oder die beliebig häufig erscheinen dürfen. Es kann nicht tiefer auf die Syntaxregeln von XML eingegangen werden, es ist aber möglich, Inhalte der Elemente allgemein als optional (A?), als alternativ (A|B), mit mindestens einem (A+) oder beliebig vielen (A*) Instanzen vorzugeben. DOM Ein XML-Dokument ist ein Dokument, das neben dem Inhalt (den reinen Daten) auch seine Struktur enthält, die von einem auf die jeweilige verwendete DTD spezialisierten XML-Parser verschiedenen Anwendungen übergeben werden können. Das Document Object Model (DOM) wurde als ein standardisiertes Datenzugriffsmodell entwickelt und bildet damit eine Plattform, die es Programmen und Skriptsprachen erlaubt, dynamisch auf den Inhalt, die Struktur und das Layout eines XML- oder HTML-Dokumentes zuzugreifen. Das Dokument kann dann weiter verarbeitet werden, und diese Verarbeitungsergebnisse können integriert werden. Das DOM bildet die Struktur eines XML-Dokumentes in einer Baumstruktur ab. Dieses Baummodell ist die Arbeitsgrundlage für XML-Parser. Die Informationen stehen so einer maschinellen Weiterverarbeitung zur Verfügung. Dabei werden alle Tags und ihre Inhalte mit ihren Relationen untereinander als Objekte definiert und in einer Objekthierarchie abgebildet, auf die dann zugegriffen wird. Dieser Zugriff auf die Objekte eines Dokumentes erfolgt z.B. mit Java-oder JavaScript. Eine mögliche Anwendung für das DOM wäre eine automatische Erstellung eines Inhaltsverzeichnisses aus einer HTML-Seite. Durch den Zugriff über das DOM kann man alle Überschriften aus einem HTML-Dokument herausfiltern und aus den gewonnenen Objekten ein Inhaltsverzeichnis generieren.

241

Sandini Bib 17 XML

Linking in XML Mit XML kann ein im Vergleich zu HTML sehr stark erweitertes Vernetzungskonzept umgesetzt werden. Das Modell zur Vernetzung von XML-Dokumenten besteht aus XML-Linking-Language (XLink) und XML-Pointer-Language (XPointer). Das Modell enthält neben unidirektionalen Links, wie sie heute in HTML verwendet werden, auch multidirektionale Links, die auf mehrere Ressourcen gleichzeitig verweisen, und bidirektionale Links, die in beide Richtungen referenzieren. XLink spezifiziert neben den aus HTML bekannten einfachen, unidirektionalen Links auch erweiterte Links. Diese erweiterten Links eröffnen die Möglichkeit, gleichzeitig auf mehrere andere Dokumente oder Dateien zu verweisen. Daneben sind in der XLink-Spezifikation auch bidirektionale Links vorgesehen, die in beide Richtungen referenzieren können. Hinzu kommt noch die Möglichkeit, Links außerhalb des Dokuments, zu dem sie gehören, verwalten zu können. XPointer stellen daneben ein weiteres mächtiges Modell für die Vernetzung in XML-Dokumenten dar. Mit XML-Pointern ist es möglich, auf bestimmten Elemente einer Instanz eines XML-Dokuments zu verweisen und zuzugreifen. Es wird also damit möglich, direkt auf der Baumstruktur eines XML-Dokumentes zu navigieren. Ein XML-Dokument kann unabhängig von seiner logischen Struktur aus beliebig vielen physischen Einheiten bestehen. Dies ermöglicht es – im Zusammenspiel von XLink und XPointer – in einem Netzwerk verteilte Daten zu einem einzigen XML-Dokument zusammenzufügen.

17.2 Anwendungsfelder für XML Da XML noch sehr jung ist, sind die meisten Implementierungen derzeit eher prototypisch. Auch wenn alle im Rahmen der WebFarm-Standard-Betrachtung relevanten Anbieter XML-Unterstützung oder XML-Schnittstellen angekündigt oder teilweise auch bereits umgesetzt haben, ist in der eigentlichen kommerziellen Entwicklung mit XML noch kein klarer Weg definiert. Der einfachste Einsatz eines XML-gestützten Systems ist zum Datentransfer zwischen unbekannten Anwendungen mit dem Hinblick auf Zukunftssicherheit dieser ausgewählten Anwendungen.. Das bekannte Zitat des XML-Mitentwicklers Jon Bosak »XML gives Java something to do« resultiert aus der Fähigkeit von XML, nicht nur Textdaten, sondern grundsätzlich beliebige, textuell kodierbare Formen von Daten zu speichern. Praktisch bedeutet das, ein Webserver neben den XML-kodierten Daten auch gleich das passende Java-Applet übertragen muss, damit der Client überhaupt mit den Daten arbeiten kann.

242

Sandini Bib Anwendungsfelder für XML

17.2.1

XML als standardisiertes Datenaustauschformat (z.B.: XML/EDI)

XML kann als Datenaustauschformat zwischen unterschiedlichen Datenbeständen dienen. Die Gestaltung des XML-basierten Datenaustausches zwischen verschiedenen Systemen mit unterschiedlichen Datenformaten, die interessengruppenspezifisch standardisiert werden können, basiert wie z.B. im Falle von SAP darauf, dass die auszutauschenden Dokumente eine im Industriestandard spezifizierte DTD als Grundlage nutzen. Diese DTDs werden in Repositories zur Verfügung gestellt. Damit können Dokumente von jeder empfangenden Anwendung validiert und verarbeitet werden, die Zugriff auf das entsprechende Repository hat. Beispiele für die Anwendung von XML als Datenaustauschformat sind Krankenakten, kooperatives CAD/CAM oder Terminmanagement sowie allgemein jeder Datenaustausch zwischen verschiedenen Datenbanken wie auch Workflow-Systeme. Konkrete Anwendungen sind etwa der Datenaustausch mit Electronic-Data-Interchange über das WWW (XML/EDI) oder das OpenTrade-Protokoll (OTP), das ein standardisiertes Verfahren für den Handel mit Privatkunden zur Verfügung stellen soll.

17.2.2

Verlagerung der Rechenleistung (Logik) vom Server zum Client (z.B.: Electronic-Banking, Electronic-Commerce)

Durch die Möglichkeit, alle Daten, die zu einem Dokument gehören, in XML zu codieren, können alle zum Verarbeiten des Dokumentes notwendigen Informationen übertragen und beim Client durch die dort für diesen Dokumententyp spezifisch erstellten und übertragenen Parser entsprechend ausgeführt werden. Hier wird auch die Bedeutung der bereits angesprochenen Kombination von Java-Technologie und XML deutlich.

17.2.3

Flexible Darstellung von Informationen

Auf XML-Dokumente können in Abhängigkeit vom jeweiligen Anwendungszweck unterschiedliche Sichten implementiert werden. Aus einer Softwaredokumentation können z.B. nur die für das jeweilige Betriebssystem interessanten Informationen angezeigt werden. Andere Beispiele sind zur Laufzeit generierte Inhaltsverzeichnisse, mehrsprachige Informationen, die nur in der jeweils gewünschten Sprache angezeigt werden usw.

243

Sandini Bib 17 XML

17.3 XML in der Praxis Da der WebFarm-Standard sehr praxisorientiert sein muss, da es sich bei betriebenen Anwendungen immer um Praxis- und nicht um Forschungssysteme handelt, ist die tatsächlich praktische Anwendung von XML, die momentan noch nicht sehr weit verbreitet ist, das wichtigste Thema in diesem Kapitel.

17.3.1

XML-Design

Das Design einer XML-Anwendung, also vor allem der DTD für diese Anwendung, ist entscheidend für die Effizienz und die tatsächliche Verwendung von XML. Hierbei handelt es sich um ein sehr kritisches Thema, da mit dem Design oft Standards festgelegt werden, die ähnlich wie Protokolle lange überdauern müssen und dementsprechend sehr flexibel erscheinen müssen. Die einfachste Methode ist, sich beim Design von DTDs auf bereits bekannte Strukturen zu stützen. Dies ist vor allem im Bereich der Datenübertragung einfach möglich, wo z.B. EDIFACT oder SWIFT und derartige Formate und Protokolle als Grundlage herangezogen werden können. Auch HBCI kann in XML kodiert werden. Da das Design einer DTD ein sehr kritischer Schritt ist, muss dieser unbedingt professionell durchgeführt werden. Es kann nicht einfach mal schnell eine DTD geschaffen werden, die dann als zentraler Datenaustauschpunkt gilt. Für das Design einer DTD zum Datenaustausch ist von einer Aufzeit nicht unter 1,5 Monaten auszugehen. Werkzeuge für das Design von XML-DTDs und Anwendungen stehen mit allen bereits bekannten SGML-Werkzeugen wie FrameMaker, Balise usw. zur Verfügung.

17.3.2

XML-Verwendung

Content-Management Im Rahmen des Content-Management, kann XML auf sehr strukturierten Daten eingesetzt werden, um Content für mehrere Ausgabeformate gleichzeitig zu produzieren, also z.B. für HTML und WAP gleichzeitig, was aber durchaus auch auf andere Weise erreicht werden kann. Bei der Vernetzung des WebFarm-Standard-Content-Management-Systems mit anderen Content-Lieferanten, die auch andere Systeme einsetzen, können über das Filtern der Daten in einem XML-Format, das vom Content-Management-System geparsed werden kann, die Daten in die Content-Pool-Struktur eingelesen werden.

244

Sandini Bib XML in der Praxis

Datenschnittstellen Bei Anwendungen, die mit Application-Servern gemäß des WebFarm-Standards geschaffen werden, entsteht durch den Einsatz weit standardisierter XML-DTDs, z.B. auf Basis von Finanz- oder ERP-Formaten, eine universelle Schnittstelle der Systeme in Richtung Backend, was es ermöglicht, sowohl das Backend als auch das eigentliche System, also die Anwendung oder den Application-Server, auszutauschen. Der WebFarm-Standard empfiehlt darum bei Systemen, die auf juristische oder andere geschäftskritische Datenbestände zugreifen, auf jeden Fall eine XML-Schnittstelle, auch wenn diese in der Entwicklung einen nennenswerten Mehraufwand bedeutet.

245

Sandini Bib

Sandini Bib

18

CGIs

18.1 Programmierumgebung Die Umgebung für die eigentliche Entwicklung, sollte gemäß des WebFarmStandards, nicht vorgegeben werden, da Programmierer oft ihre eigene Umgebung bevorzugen. Eine Vorgabe der Entwicklungsumgebung ist dann sinnvoll, wenn sehr viele Programmierer gemeinsam an einem und demselben Code arbeiten müssen. Diese Situation tritt bei CGIs nie auf, da es sich über die Zustandslosigkeit des HTTP-Servers bedingt immer um Einzelaufrufe bestimmter Programme mit klar definierten Schnittstellen handelt. Den Entwicklern sollten aber auf jeden Fall Vorschriften im Hinblick auf Bibliotheken und im Hinblick auf Archivierung gemacht werden. Eine sinnvolle Archivierung der Entwicklungsfortschritte ist immer für eine gute Qualität zwingend notwendig, ebenso wie eine Dokumentation, die auf jeden Fall erstellt werden muss. Ansonsten gelten die Style-Richtlinien für normale Entwicklungen. Zusätze, die für CGIs notwendig sind, werden im Abschnitt »CGI-Entwicklung« beschrieben.

18.2 Programmiersprachen Grundsätzlich werden für CGIs alle Arten von Programmiersprachen verwendet. Die Webprogrammierung an sich hat sehr viele neue Sprachen und Dialekte hervorgebracht. Es handelt sich oft um Skriptansätze, die für die schnelle Programmierung und das Trial-and-Error-Verfahren optimiert sind. Im Bereich, der professionellen Webentwicklung kommen neben ApplicationServern immer noch CGIs für kleine Anwendungen, oder Anwendungen, die aufwändige Rechenoperationen durchführen müssen, zum Einsatz. Diese sollten auf keinen Fall nach dem Trial-and-Error-Verfahren entwickelt werden, was sich aber von selbst verstehen sollte. Auch Skriptsprachen sind nicht besonders effizient, da zur Ausführung immer wieder, der gesamte Interpreter geladen werden muss, bevor überhaupt eine Verarbeitung beginnen kann. Der WebFarm-Standard sieht darum vor, nur Einseitenentwicklungen oder Prototypen in Skriptsprachen zu entwickeln. Als Skriptsprachen kommen hier Perl und TCL in Frage, da diese die größte Verbreitung haben. Es sollte

247

Sandini Bib 18 CGIs

darauf geachtet werden, dass keine Entwicklungen in anderen Sprachen durchgeführt werden, weil sich dadurch das benötigte Know-how zur Pflege der Web-Application-Landschaft exponentiell steigert, was bei einem knappen Pool an Ressourcen katastrophale Auswirkungen hat. Anwendungen, die mehr als eine Seite bedienen und als CGI realisiert werden, sind nach dem WebFarm-Standard auf jeden Fall in C oder C++ zu fassen.

18.3 CGI-Entwicklung CGIs stellen sehr kritische Programmgefilde dar. Sie werden im Process-Space des jeweiligen Serverprozesses gestartet und laufen auch unter seiner UID und GID. Daher können bei schlecht administrierten Servern verheerende Schäden auftreten.

18.3.1

Modulköpfe

Das Leben eines CGIs besteht darin, den Input von STDIN oder aus einer Umgebungsvariablen zu verarbeiten. Daher ist es wichtig, diese Informationen zusätzlich in die Modulköpfe mit aufzunehmen. Als Erweiterung zum Standard-Programmierstil ergeben sich daher die zusätzlichen Felder: 왘 Input: beschreibt, ob das CGI POST oder GET oder sogar beides ver-

wendet 왘 Parameters: Beschreiben die einzelnen Übergabeparameter

18.3.2

Dynamische Ausgaben

CGIs geben in der Regel wieder HTML-Code aus. Hierfür sollte der Code aus einzelnen Dateien ausgelesen werden. Damit wird verhindert, dass Änderungen evtl. mehrmals im Source-Code gesucht und ausgebessert werden müssen. Zusätzlich entfällt auch die umständliche Neucompilierung. Diese Vorlagendateien enthalten möglicherweise Platzhalter für Werte. Diese Variablen müssen dann natürlich auch dokumentiert werden. Verwendet man hierfür die WebFarm-C-CGI-Lib, dann können in diesen Vorlagedateien Kommentare eingefügt werden, die diese Platzhalter beschreiben.

248

Sandini Bib CGI-Entwicklung

18.3.3

Verwendung von Konfigurationsfiles

Optionen und Einstellungen sollten nicht hartgecoded in den Source eingebaut werden, sondern via Konfigurationsfile eingelesen werden. Die Lokation dieser Config-Files kann dann im Programmcode angegeben werden. Der Zugriffspfad ».« sollte aber immer als letztmöglicher Defaultwert vorgesehen werden.

18.3.4

Sicherheit von CGIs

Die Sicherheit von CGIs ist eine sehr wichtige Angelegenheit und darf nicht vernachlässigt werden. Die meisten Probleme bestehen darin, dass Puffergrenzen beim Einlesen der Parameter nicht eingehalten werden und es zu Overflows kommt. Daher gilt auch hier, dass alternative Bibliotheken zum Einsatz kommen. Außerdem bietet hierfür auch die WebFarm-C-CGI-LIB hilfreiche Routinen an. Gerade auch hier machen sich alternative Libraries für das Speichermanagement nützlich (z.B. Garbage Collection, ...). system() und popen() dürfen bei CGIs, die nach dem WebFarm-Standard ent-

wickelt werden, auf keinen Fall verwendet werden. Dies kann vor allem bei frei wählbaren Parametern, die ungefiltert weitergeleitet werden, zu Katastrophen führen. Abhilfe schafft natürlich eine intelligente Filterung oder auch die beiden Calls pipe() und exec(), die keine direkte Übergabe an eine Shell hervorrufen. Um eine zusätzliche Sicherheitsüberprüfung zu ermöglichen, sollte das jeweilige CGI nicht gestartet werden, wenn die Umgebungsvariablen REMOTE_USER und AUTH_TYPE nicht gesetzt sind. Diese Variablen werden vom Server verwaltet, wenn das jeweilige Verzeichnis, auf das zugegriffen wird, geschützt werden soll. Es kann immer wieder vorkommen, dass sich ein CGI in einer Schleife oder in anderen Programmkonstrukten verhängt. Daher ist es sinnvoll, eine Art »Selbstmordfunktion« einzubauen, die das CGI nach einem bestimmten Zeitintervall des Nichtstuns beendet. Die meisten HTTP-Server tun dies von sich aus, jedoch hat man durch das manuelle Töten eine bessere Möglichkeit, noch zusätzliche Debug-Informationen mit auf den Weg zu geben. Werden sensitive Daten, wie z.B. Passwörter, übergeben, so sind diese nicht als GET, sondern immer via POST zu übermitteln, sonst tauchen diese in der URL-Zeile und vor allem auch im Serverlog wieder auf. Allgemein gilt: Traue niemals Formdaten!

249

Sandini Bib

Sandini Bib

19

Skriptsprachen

Im Folgenden wird auf die Verwendung von Skriptsprachen im Rahmen von WebFarm-Entwicklungen eingegangen. Grundsätzlich ist in den entsprechenden Kapiteln bereits beschrieben, dass CGIs und Applikationen in reiner Skriptausführung nicht WebFarm-konform sind, wenn es sich dabei um größere Anwendungen handelt. Diese Restriktion rührt vor allem daher, dass Skriptanwendungen einen enormen Pflegeaufwand haben, der sich im Vergleich zur eingesparten Zeit bei der Entwicklung sehr schnell zu großen Mehrkosten summiert. Bei Skriptanwendungen muss grundsätzlich zwischen Browserskripten unterschieden werden, die auf der Seite des Clients ablaufen und normalerweise verwendet werden, um Eingabevalidierungen und einfache Berechnungen sowie dynamische Vernetzungen oder dergleichen zu erzeugen, und auf der anderen Seite Skriptanwendungen, die als CGIs oder Side-Includes sowie Plug-ins fungieren. Diese beiden Anwendungsgebiete für Skripte sind vollkommen unterschiedlich zu behandeln und unterliegen auch unterschiedlichen Ausrichtungen.

19.1 Browser-Skriptsprachen Es gibt mehrere Methoden in den Browser-Skripten, also keine Programme, die zur Laufzeit interpretiert werden, auszuführen. Die bekanntesten davon sind sicherlich Javascript, VBScript, Flash und Dynamic HTML. Diese Beispiele bilden einige vollkommen unterschiedliche Ansätze für die interaktive Bearbeitung von Webseiten ohne direkten Serverkontakt, was ein erheblicher Fortschritt zu der rein zustandslosen Behandlung, die das ursprüngliche HTTP- und Browserkonzept des Web vorsah, bietet. Mit Hilfe dieser Skriptansätze können interaktive Kleinanwendungen geschaffen werden, die weder Netz noch Serverressourcen verbrauchen; es können Plausibilisierungen von Eingaben und Aktionen des Benutzers direkt auf Benutzerseite durchgeführt werden, ohne dass der Benutzer lange Wartezeiten in Kauf nehmen muss und ohne dass irgendeine Belastung für Netz und Server entsteht. Es können aber auch einfache Abläufe realisiert werden, die rein interaktiv auf dem Browser als Animationen oder Workflows ablaufen, weil nur Daten vom Benutzer benötigt werden und keine weitere Interaktion mit dem Server erforderlich sind.

251

Sandini Bib 19 Skriptsprachen

Abbildung 19.1: Browser-Scriptarten und ihre Anwendung

Javascript und VBScript- sind dabei eher applikationsorientiert, das bedeutet, dass hiermit direkt kleine Programme in Seiten integriert werden können und sich Flash und Dynamic HTML eher auf grafische Elemente und Animationen konzentrieren. Diese Skriptsprachen unterscheiden sich selbstverständlich von Einsatzgebieten und Entwicklungsumgebungen erheblich.

19.1.1

Einsatz von Browser-Skriptsprachen

Der Einsatz von jeglichen browserbasierten Skriptsprachen ist nach dem WebFarm-Standard gestattet, wenn die folgenden Richtlinien eingehalten werden. Insbesondere ist darauf zu achten, dass auf gar keinen Fall die »Privacy«Rechte des Browserbenutzers verletzt werden, dies bedeutet, es dürfen keine Daten von der Festplatte gelesen werden, es dürfen keine Profilingdaten dynamisch generiert werden, es dürfen keine Programme aufgeführt werden usw. Alle diese Dinge schaffen große Sicherheitslücken. Am einfachsten sind solche illegalen Aktionen in ActiveX oder VBScript zu realisieren, weswegen

252

Sandini Bib Skriptsprachen für den Einsatz auf Serverseite

in Standard-WebFarm-Security-Konstruktionen diese Arten des Content direkt herausgefiltert werden. Bei der Verwendung von Erweiterungen, die auf Plug-in-Technologie aufbauen, wie z.B. Flash, ist zu bedenken, dass diese Anwendung automatisch nur einem beschränkten Benutzerkreis zur Verfügung steht. Generell sollten nur spezifische Angebote mit genau bekanntem Benutzerkreis auf diese Weise designed sein, alle anderen Webanwendungen sollten auf Technologien beruhen, die in den am weitesten verbreiteten Browsern direkt integriert sind. Diese Funktionen können dann eingesetzt werden, um den Traffic zwischen Client und Server bzw. die Wartezeiten für den Benutzer zu reduzieren, was vor allem durch eine Vorplausibilisierung von Eingaben geschieht, oder das Abwickeln sehr einfacher algorithmischer Vorgänge wie z.B. das Summieren. Außerdem werden die Techniken oft zur Verbesserung der Layout-Eigenschaften oder der Interaktivität des grafischen Designs verwendet, was in heutigen Webanwendungen schon fast zur Pflicht geworden ist und daher auch nicht untersagt werden kann.

19.2 Skriptsprachen für den Einsatz auf Serverseite Auf Serverseite stehen wesentlich mehr Skriptsprachen zur Auswahl, die für die unterschiedlichsten Anwendungsgebiete ursprünglich entwickelt worden waren. Um nur einige zu nennen, werden heute viele Webanwendungen mit Perl-, Python-, Tcl-, … Skripten betrieben. Gemäß der CGI-Richtlinien, die im entsprechenden Kapitel der WebFarmEntwicklungsstandarddefinition aufgeführt sind, werden alle diese Sprachen von den unterschiedlichsten Agenturen und Entwicklern im Webbereich eingesetzt. Wenn man sich die Landschaft näher betrachtet, tritt eine Vielfalt von mehr als 30 Grundzügen auf. Da dies in einer kommerziellen Umgebung, sprich einem zusammenhängenden Konzern, nicht wünschenswert sein kann, weil das vorzuhaltende Know-how zur Pflege der Anwendungen oder die grundsätzliche Abhängigkeit von Entwicklern, wenn es sich um Exoten oder schlecht kommentierte Skripte handelt, einfach unberechenbar und auf jeden Fall immens ist. Aus diesem Grund schreibt der CGI-Standard vor, dass nur sehr kleine Anwendungen über eine standardisierte Skriptsprache abgewickelt werden sollen und können. Außerdem ist der Einsatz von Skriptanwendungen im Rahmen von Prototypen nach dem WebFarm-Standard gestattet, da hier die langfristige Pflegbarkeit und Sicherheitsmaßgaben keine besondere Rolle spielen, sondern eher der Beweis, dass eine Idee mit Webtechnologie schnell

253

Sandini Bib 19 Skriptsprachen

realisierbar ist, was im Rahmen eines Skriptprototypen wesentlich einfacher ist als in komplett ausformulierten und vor allem designten Programmen. Beim Einsatz von kleinen Skriptanwendungen (einseitig) in Produktionsumgebungen ist zu bedenken, dass für jeden Aufruf der Anwendung ein relativ großer Parser geladen und initialisiert werden muss, was zwar durch die im WebFarm definierten Standardplattformen für Hardware und die in den zugrunde liegenden Betriebssystemen durch die Copy-on-Write-Technologie stark verbessert, aber dennoch nicht beseitigt wird. Dieser Faktor bedeutet, dass die Auslastung bei vielen Aufrufen der Skripte sehr hoch werden kann.

19.2.1

Entwicklungsstil

Wichtig bei der Entwicklung von Skripten ist, dass die gleichen Regelungen gelten, die auch im Rahmen »normaler« Entwicklungen für Kleinanwendungen gelten. Das bedeutet im Einzelnen, dass es eine Kurzbeschreibung der Funktionalität jedes Moduls inklusive I/O-Dokumentation gibt, dass die einzelnen Module Layout und Funktionalität komplett entkoppeln, was am einfachsten über so genannte Templates oder Vorlagen realisiert wird, und dass eine komplette Kommentierung im Code vorhanden ist, weil die meisten Änderungen an Skripten direkt »on-the-fly« geschehen. Es ist auf jeden Fall sinnvoll, einen so genannten LINT, ein Werkzeug zur Kontrolle der syntaktischen und theoretischen Korrektheit von Code zu verwenden, um einwandfreie Skriptergebnisse, die eventuell auch portabel sind, zu erzielen. Für alle im WebFarm-Standard vorgeschlagenen Skriptsprachen existieren solche Check-Programme, die auf jeden Fall in die Entwicklung miteinbezogen werden sollten. Zur Betriebsübergabe von Skripten werden dann vom Systembetrieb die Ausgabe und Kommentierung der entsprechenden LINT-Reports über die Skripte gefordert.

254

Sandini Bib

20

Java-Style

Im Folgenden werden einige grundlegende Richtlinien für die Entwicklung von Java-Applets, Applications, Servlets und -Server sowie eigenen Beans gegeben, die sich am WebFarm-Standard orientieren sollen und nach Fertigstellung in der Produktionsumgebung einer WebFarm-Lokation untergebracht werden. Da Java-immer größeren Einzug in alle Arten der Softwareentwicklung hält und dementsprechend auch die Vielfalt an Java-Erweiterungen und -Zusätzen sowie die Vielzahl der zu Java-gehörenden oder verfügbaren Techniken ständig zunimmt, werden hier nur allgemeine Richtlinien für die Java-Entwicklung gegeben. Der WebFarm-Standard kann nicht vorschreiben, welche Klassenbibliotheken, Beans oder dergleichen verwendet werden sollen, da dies eine allgemeine Entwicklungsentscheidung des Unternehmens ist, die sich auch auf andere Entwicklungen außerhalb des Webbereiches sehr stark auswirken können.

20.1 Grundsätze 20.1.1

Lesbarkeit

Die Lesbarkeit von Java-Code unterscheidet sich nicht von dem anderer Programmiersprachen. Grundsätzlich sollten die gleichen Kriterien gelten wie für C++. 왘 Dateibeschreibung:

Zu Beginn jeder Datei sollte eine Beschreibung der Datei zu finden sein. Diese sollte alle für die Darstellung der Versionskontrolle notwendigen Tags ($Id$, $Log$) enthalten. Weiterhin sollten der Autor bzw. die Autoren, der Erstellungszweck, die exportierten und privaten Klassen der Datei, eine Change-History sowie eine To-do-Liste geführt werden. 왘 Klassenkopf:

Vor der Definition jeder Klasse sollte ein Kommentar untergebracht werden, der den Zweck der Klasse beschreibt, die Klasse im Klassenbaum einordnet und eventuell geplante Tochterklassen aufzeigt.

255

Sandini Bib 20 Java-Style

왘 Methodenkopf:

Für jede Methode einer Klasse sollte ein Kommentar existieren, der die eindeutige Funktionalität der Methode innerhalb der Klasse und innerhalb der Klassenstruktur definiert. 왘 Programmkommentierung:

Wie auch in jeder anderen Programmiersprache zeugt es von gutem Stil, die implementierten Algorithmen funktional zu kommentieren. 왘 Dokumentationswerkzeuge:

Java liefert Dokumentationswerkzeuge, die, wenn Kommentare jeweils korrekt um die Definition des zu beschreibenden Elements gelagert sind, eine mit Beschreibungen versehene Struktur eines Projekts darstellen kann. 왘 Modellierung:

Zusätzlich zu den im Programm abgelegten Dokumentationen sollte eine OO-Modellierung der Klassen vorgenommen werden. Aus dieser muss eine klare Trennung von Event-Handling und Computing-Classes ersichtlich werden. Es ist nicht unbedingt erforderlich, dass diese Modellierungen grafisch bzw. mit OOAD-Modelling-Tools erzeugt werden. Ein einfaches Programmieren ohne Klassenmodell ist besonders in Java tödlich!

20.1.2

Fehlerfreiheit

Die Fehlerfreiheit von Code zu garantieren, erscheint bei heutigen Codemengen unmöglich. Dennoch muss größter Wert auf eine korrekte Programmierung gelegt werden. Java unterscheidet sich auch hier kaum von C++. 왘 Kommentare:

Nicht nur zur Dokumentation sind Kommentare im Programmcode selbst unabdingbar. Sind Algorithmen nicht korrekt kommentiert, kann keinerlei Aussage über deren Programmierer- oder fachliche Richtigkeit gegeben werden. 왘 Exception-Handling:

Es ist unbedingt dafür zu sorgen, dass ein komplettes Exception-Handling in die Programme eingebunden ist. Java bietet hierfür sehr einfache »Hooks«, die unbedingt mit den entsprechenden Methoden hinterlegt werden müssen. Ansonsten sind die auf der Java-Konsole ausgegebenen Meldungen bei fatalen Exceptions absolut nicht aussagefähig.

256

Sandini Bib Grundsätze

왘 Debug-Switches

Jedes Java-Programm sollte eine Debug-Konsole besitzen. Das bedeutet, wenn man ein Java-Programm mit der entsprechenden Option aufruft oder übersetzt, sollte es bei einem Lauf auf der Konsole, sprich nicht als Applet, gestartet werden, gemäß dem angegebenen Trace-Level werden bei jeder Operation entsprechende Meldungen ausgegeben. 왘 Unter Java sollten solche Debug-Optionen, wenn sie umgesetzt sind, nicht

im Code sein, sprich als Kommentar oder DEF existieren, da sie sonst über das Netzwerk übertragen werden müssen.

20.1.3

Performante Ausführung

Da Java-Programme nicht cachebar bzw. nur, wenn der übertragene Bytecode signiert ist, cachable sind, werden sie bei einer Verwendung als Applet bei jedem Aufruf neu über das Netz geladen (es sei denn, sie sind signiert). Außerdem sind übersetzte Java-Programme keine direkten Maschinencodes und daher langsamer auszuführen als normale Programme. Auf eine performancegerechte Programmierung ist es Erachtens wert: 왘 Algorithmen:

Es ist unabdingbar, in Java noch mehr als in anderen Programmiersprachen, korrekte Algorithmik zu verwenden. Es sollte jeder verwendete Berechnungsalgorithmus einer Effizienzanalyse unterzogen werden. Werden in der Informatik nicht bekannte oder als ineffizient bekannte Algorithmen verwendet, ist dies im Kommentar zu begründen. 왘 Runtime-Module/Java-Environments:

Beim Einsatz von Java-Entwicklungsumgebungen ist darauf zu achten, dass diese keine großen Runtime-Module verwenden oder benötigen. Aufgrund des Java-Bindings ist bei solchen Modulen noch keine Übertragung nur der benötigten Funktionen möglich, es wird daher vollkommen unnötiger Netzwerkverkehr erzeugt. 왘 Strukturierung:

Bei der Strukturierung der Klassenhierarchie ist auf ein Abwägen zwischen Design und Performance zu achten. Es sollten nicht, wie das ein perfektes OO-Design vorschreibt, sehr viele kleine Klassen mit sehr tiefen Vererbungsstrukturen erzeugt werden. 왘 Signing:

Die Methode des Signing von Applets und Servlets sorgt dafür, dass diese auch gecached werden können. Dies ist sehr sinnvoll, da es sofort Netzwerk-Traffic einspart. Zusätzlich sind signierte Java-Programme auch auf lokalen Arbeitsstationen fest installierbar. Es muss bei diesem Vorgehen

257

Sandini Bib 20 Java-Style

aber darauf geachtet werden, dass die Plattformunabhängigkeit von JavaCodes gewahrt bleibt, das bedeutet, dass keine systemspezifischen Installationsalgorithmen und Methoden (wie z.B. die Windows-Cabinets (CAB)) verwendet werden dürfen. Das Signing hat neben der direkten Cachebarkeit der übertragenen Java-Klassen bzw. der Installierbarkeit auch den Vorteil, dass auch für jeden Benutzer immer sichergestellt ist, dass er ein richtiges und abgenommenes Programm erhält und nicht etwa eine Betaversion, die zufällig noch irgendwo auf dem Server lag, oder aber ein »trojanisches Pferd«, das zur Unterwanderung von Sicherheitsmethoden, die im WebFarm-Standard implementiert sind, verwendet werden könnte.

20.2 Entwicklungswerkzeuge Grundsätzlich gilt für die Java-Entwicklung im WebFarm-Standard das gleiche Prinzip wie für die anderen Entwicklungen auch. Das bedeutet also, prinzipiell kann jeder Entwickler seine Entwicklungsumgebung selbst festlegen. Bei Java-Entwicklungen ist allerdings die Interaktion innerhalb eines Programmierteams noch größer als z.B. in C++-Entwicklungen. Aus diesem Grund sollte darauf geachtet werden, dass in einem Team die gleichen Umgebungen eingesetzt werden. Da Java-Entwicklungsumgebungen, die über die standardisierte Unterstützung des Programmierers hinausgehen und Rapid-App- oder PrototypingFunktionen sowie Zusatzfunktionen für bestimmte Anwendungen (z.B. Datenbankzugriff) bereitstellen, oft eine sehr große eigene Klassenstruktur mit in die Programme importieren, ist bei solchen Umgebungen auf jeden Fall darauf zu achten, einen Standard zu finden, der für die jeweilige Anwendungsart optimal ist. Dabei spielen nicht nur die Funktionen für den Entwickler eine Rolle, sondern auch die Effizienz in Ausführung und Übertragung des entstehenden Codes.

20.2.1

Reine Java-Entwicklung

Es kann eine reine Java-Entwicklungsumgebung verwendet werden, die selbst keine zusätzlichen Klassen enthält und nur Zugriffe auf Standardfunktionen erlaubt. Mit dieser Art Umgebung werden die schnellsten Programme erzeugt, die allerdings auch am wenigsten Komfort für Benutzer und Entwickler bieten. Es muss ein Mittelweg für die Entwicklung von Java-Programmen gefunden werden. Dies gilt vor allem für den Applet-Bereich, da hier die Benutzerumgebung nicht vorhergesagt werden kann und Performance darum das alles entscheidende Thema ist.

258

Sandini Bib Entwicklungswerkzeuge

Eine solche Entwicklungsumgebung kann natürlich auch in anderen Umgebungen, die im WebFarm-Standard vorgeschlagen werden, nachgebildet werden, indem die Zusatzfunktionen dieser Umgebungen einfach nicht eingebunden werden. Dies bedeutet z.B. beim Design des Layouts eines Applets dürfen nur Komponenten verwendet werden, die im awt-Toolkit und, wenn verfügbar, in einem Toolkit, das alle Benutzer in der VM besitzen, geschaffen wurden. Generell ist zu sagen, dass diese Umgebungen kaum verwendet werden, obwohl dies wünschenswert wäre, um die Performance und damit die Akzeptanz von Java-Anwendungen zu erhöhen.

20.2.2

Erweiterte Funktionen der Java-Entwicklungsumgebung

Viele Umgebungen bieten starke Erweiterungen über den reinen Support der Entwickler bei der Gestaltung von Klassenstrukturen und Code hinaus. Sie liefern Möglichkeiten, ein Environment für Servlets und sogar Server zu schaffen, grafische Methoden und das Aussehen von Applets und Komponenten zu entwerfen, mit denen ein Datenbankzugriff z.B. über JDBC direkt eingebunden werden kann, ohne dass eine Datenbankschicht vom Programmierer selbst erstellt werden muss. Diese Umgebungen nehmen den Entwicklern sehr viel Arbeit ab, haben aber meist den eindeutigen Nachteil, dass sie sehr viel Overhead produzieren, was in einer Entwicklung, die in C++ geschrieben ist, wesentlich weniger auffällt als bei einer Java-Anwendung. Der WebFarm-Standard verbietet den Einsatz dieser Umgebungen nicht, da dies zu viel Arbeit in der Entwicklung von Anwendungen und damit ein Zurückfallen der Technologie hinter den Standard bedeuten würde, der täglich im Internet neu gesetzt wird. Die Entwickler, die mit diesen Umgebungen arbeiten, müssen aber, um dem WebFarm-Standard Genüge zu tun, auf jeden Fall mit der Klassenstruktur, die für die entworfenen Anwendungen verwendet wird, vertraut sein und eine Ausbildung genossen haben, die es ihnen ermöglicht, die Performance der Anwendungen abzuschätzen und ggf. zu verbessern. Das bedeutet in diesem Falle nicht nur im Sinne der Algorithmik des Programmierens, sondern auch eine detaillierte Kenntnis des Werkzeugs und seiner Supportklassen. In der Entwicklung von Servlets ist dies aus einem zusätzlichen Grund sehr wichtig, denn hier können durch unsachgemäßen Einsatz von Bibliotheken oder automatisch generiertem Code sehr schnell sehr große Sicherheitslücken auftreten.

259

Sandini Bib 20 Java-Style

Abbildung 20.1: Java-Entwicklungsumgebung VisualCafé

20.3 Laufzeitumgebung Da Java-Anwendungen nicht in der Laufzeitumgebung des Betriebssystems, sondern in der Umgebung der Java-Virtual-Machine ablaufen, die der konstanten Weiterentwicklung unterliegt, ist die Betrachtung des Laufzeitverhaltens von Applets und Servlets in erster Linie (Server selbst und Anwendungen setzen immer eine exakte Systemkenntnis voraus, so dass hier die Laufzeitumgebung exakt definiert werden kann) zu beeinflussen. Es ist für die Entwicklung wichtig, dass diese nicht nur in der allerneusten Version dieser Umgebungen lauffähig sind. Grundsätzlich werden alle Umgebungen von Sun zertifiziert und sind erst danach einzusetzen. Durch den offenen Entwicklungsprozess im Internet ist es auf jeden Fall so, dass oft mit Beta-Software entwickelt wird, die natürlich im kommerziellem Betriebsumfeld einer WebFarm-Lokation nicht eingesetzt werden kann. Grundsätzlich empfiehlt es sich, die Umgebungen, die Sun bzw. die Netscape Sun Alliance bereitstellt, einzusetzen, da diese sicherlich den letzten Stand der Java-Kernentwicklung repräsentieren und keinerlei proprietäres Verhalten an den Tag legen können.

260

Sandini Bib Servlets und Server-Side-Includes

20.4 Servlets und Server-Side-Includes Es gibt mehrere Arten, die Funktionalität eines Standard-HTTP-Servers stark zu erweitern und somit den Server auf bestimmte große Anwendungen anzupassen. Servlets als eigenständige Serveranwendungen und Server-SideIncludes als Module, die in den normalen Prozess des Servers eingebunden werden. Der WebFarm-Standard unterstützt diese Techniken im Rahmen von großen Anwendungen oder speziellen Sicherheits- oder Filteranforderungen. Für normale Anwendungen, die sicherlich 95% der gesamten WebFarm-Serverlandschaft ausmachen, sind aber sicherlich die über Application-Server, CGI-Programmierung und die Infrastruktur der WebFarm gegebenen Funktionalitäten völlig ausreichend. In diesen Fällen sollte auch auf jeden Fall mit den vorhanden Mitteln gearbeitet werden, da Server-Side-Entwicklungen immer die Risiken der Weiterentwicklung in den gleichen kurzen Zyklen wie die Server selbst und die massiven Sicherheitsaufwände in der Programmierung tragen. Im Folgenden werden einige Ansätze zur Entwicklung von Server-SideAnwendungen im Rahmen des WebFarm-Standards aufgeführt.

20.4.1

Einsatz von Server-Side-Anwendungen

Wie bereits erwähnt, sind im Allgemeinen alle benötigten Funktionen in den Application-Servern und Zusatzprogrammen, die der WebFarm-Standard unterstützt oder bereits über die definierte Infrastruktur bereitstellt, vorhanden. Soll dennoch eine Server-Side-Anwendung geschaffen werden, müssen folgende Grundsätze erfüllt sein. Die Anwendung sollte dabei bestimmte Sicherheitsanforderungen haben, die nur über eine eigene Logik zu erfüllen sind oder eine Verbindung oder eine Dauerverbindung zu anderen Services im GAN besitzen, die am einfachsten von einer eigenen Applikationsbasis aus gehandhabt werden. Wenn diese Voraussetzungen gegeben sind, sollte grundsätzlich die Möglichkeit eines Side-Includes zuerst betrachtet werden, da bei der Programmierung von eigenen Serverteilen (Servlets) auf das korrekte Handling eingehender Requests in allen Hinsichten geachtet werden muss. Wird hier nicht mit der entsprechenden Programmiersorgfalt vorgegangen, kann ein eigener Server nicht nur instabil und unperformant sein, sondern auch sehr große Sicherheitslücken produzieren. Im Fall von Side-Includes stehen der Anwendung alle Pre- und Post-Processing-Methoden des normalen ausgereiften Servers zur Verfügung. Der Nachteil von Side-Includes ist der vom Server vorgeschriebene Prozess, der in diesem Fall nicht verändert werden kann.

261

Sandini Bib 20 Java-Style

20.4.2

Einbindung von Includes und Servlets

Ein Servlet oder Include muss wie Programme und Zusatzanwendungen in die Struktur des Webservers installiert werden. Oft werden für die Aktivierung von Includes und Servlets noch zusätzliche Links, in die Verzeichnisse der Basissoftware des Webservers benötigt. Diese sollten nur erstellt werden, wenn eine Konfiguration des Servers in die entsprechenden Verzeichnisse nicht möglich ist.

262

Sandini Bib

21

Website-Werkzeuge und Serveranwendungen

Zeit bzw. Time-to-Market ist bei Webanwendungen gerade heute der absolut kritische Faktor. Bei der gegebenen Ressourcenknappheit und auch vor kostentechnischen Hintergründen dürfen aus diesem Grund auf gar keinen Fall Entwicklungen doppelt und dreifach forciert werden. Es existiert eine ganze Menge an Standardanwendungen oder Standardaufgaben, die auf Webanwendungen oder als Webanwendungen immer wieder benötigt werden. Hier sollten diese Anwendungen so weit vorgestellt werden, wie sie in der WebFarm-Betriebsumgebung integriert werden können. Es gibt wesentlich mehr Bausteine als die hier vorgestellten und deren Anwendungen, die aber eine wesentlich größere Detailtiefe erfordern. Bei einer größeren Webumgebung können aber durch den Einsatz der im WebFarm vorgeschlagenen Standardbausteine allein 35% Entwicklungskosten eingespart werden.

21.1 Website-Werkzeuge 21.1.1

Charting

In vielen Anwendungen tauchen zur Visualisierung von numerischen oder organisatorischen Anwendungen Charts auf, wie man sie heute aus der Office-Umgebung kennt. Diese Grafiken werden zumeist aus einer Datenbank generiert und dynamisch aktualisiert. Es muss eine Standardbibliothek sowohl vom Server aus als auch von Application-Server-Programmen und direkt programmierten CGIs angesprochen werden können, die diese Grafiken erzeugt, da ansonsten ein enormer Entwicklungsaufwand entsteht. Der WebFarm-Standard schlägt für die Generierung von Grafiken einige Werkzeuge vor, die in die unterschiedlichen Entwicklungstypen und Entwicklungstadien eingebunden werden können. Grundsätzlich ist zu sagen, dass eine gute Parametrierbarkeit der Grafiken vorausgesetzt, werden muss, da es hier nicht ausreicht, Standard-Office-Grafiken zu verwenden, weil Webanwendungen einen sehr starken Marketingtouch haben, der auch in den Grafiken zum Ausdruck kommen muss, da diese genau den Designvorgaben des Unternehmens entsprechen müssen.

263

Sandini Bib 21 Website-Werkzeuge und Serveranwendungen

21.1.2

Community-Tools

Communities oder so genannte geschlossene Benutzergruppen bilden ein neues Phänomen im Internet und werden im Rahmen von Websites der CRMLösungen zur Kundenbindung durch Mehrwertdienste angewendet. Alle Communities enthalten ein Forum, in denen die Mitglieder der Community, offensichtlich ähnliche Interessen verfolgen, miteinander kommunizieren können. Chats Chats sind Anwendungen, in denen Benutzer in verschiedenen »Räumen« miteinander über Tastatureingaben direkt kommunizieren können. Hierbei steht die direkte Kommunikation mit Echtzeitanspruch im Vordergrund. Chats werden eingesetzt, damit Benutzer untereinander einen direkten Informationsaustausch zu gewissen Themen haben können, aber auch damit klassische Events, bei denen oft andere Medien oder eine direkte Anwesenheit im »Spiel« ist, virtuell abgewickelt werden können. Hierzu gehören Pressekonferenzen, Diskussionen, Seminare usw. Der WebFarm-Standard setzt hierbei auf die Integration von Standard-Chatwerkzeugen in eine Community-Umgebung. Die Anforderungen an diese Werkzeuge sind klar die Einhaltung der Entwicklungsrichtlinien des WebFarm-Standards im Hinblick auf Übertragungen, Anpassbarkeit und Sicherheit. Wichtig bei solchen Lösungen ist auch die Fähigkeit der Produkte, mit anderen Produkten aus einer Community-Umgebung zusammenzuarbeiten und einen entsprechenden übergreifenden Mehrwert zu generieren. Boards Wird in Communities nicht von einer Echtzeitkommunikation gesprochen, so treten sofort so genannte Boards in den Mittelpunkt. Es handelt sich hier um elektronische Pinnwände, wie sie aus der alten Mailboxszene bekannt sind. Boards in der Webtechnologie ermöglichen einen multimedialen Austausch von Informationen, wie dieser heute mit E-Mails auch möglich ist, allerdings in einer Diskussionsform abgebildet. Diese Boards werden verwendet, um von den Benutzern selbst moderierte Informationsflüsse oder elektronische Zeitungen zu bilden. In einer Community werden über Boards Meinungen über eine lange Zeit diskutiert und so eine konstante Kommunikation aufgebaut. Boards, die im WebFarm-Standard eingebunden bzw. in Anwendungen eingesetzt werden, die nach dem WebFarm-Standard eingesetzt werden, müssen neben den normalen Funktionen wie Schreiben, Lesen und Suchen von Nachrichten (über eine Standard-Suchmaschine) auch in puncto Veränderbarkeit, Design und Benutzerverwaltung den Richtlinien des WebFarm-Standards entsprechen.

264

Sandini Bib Website-Werkzeuge

21.1.3

Mind-Map

Mind-Mapping ist für eine persönliche Arbeitsumgebung und für eine individuelle Navigation von Informationssystemen ein wichtiges Thema, das im WebFarm-Standard durch die Definition einiger Standardwerkzeuge abgedeckt wird. Mind-Mapping bedeutet kurz gefasst, dass die Navigation einer Informationsanwendung an den Gedankengängen und logischen Deduktionen eines einzelnen Benutzers oder einer Benutzergruppe orientiert wird. Diese Mind-Maps sorgen für eine sehr gute Identifikation der Benutzer mit großen Informationsanwendungen und für die auf Dauer einfachere Nutzbarkeit der Informationen, die sich in einer solchen Umgebung befinden.

21.1.4

Shops

Die Anwendungen, mit denen das Internet kommerziell entdeckt wurde und durch die es nicht nur als Informationsaustausch gesehen wird, sind virtuelle Läden und Filialen. Diese werden in allen Unternehmensgruppen und allen Branchen eingesetzt. Es gibt grundsätzlich zwei verschiedene Arten von Shops. Einerseits können Geschäftsereignisse zwischen Firmen auftreten, die eine ganz andere Anforderung haben als die andererseits implementierten Shop-Lösungen für Endbenutzer, bei denen es meistens um reine Katalogsysteme mit Bestellmöglichkeit geht. Da es sich hier um weitestgehend standardisierte Anwendungen handelt, kann der WebFarm-Standard auch hier Vorgaben treffen, welche die Effizienz von Entwicklungen verbessern. Business-to-Business-Shops Der Sinn von Business-to-Business-Lösungen ist es, die Abwicklung als solche zu vereinfachen, d.h., zum Beispiel elektronische Bestellungen und Berechnungen durch entsprechende Vertragswerke zu ermöglichen. Bei Business-to-Business-Shops muss die Intention nach dem WebFarm-Standard weitergehen. Es muss der Sinn sein, einen Teil des Workflows, den die beiden Geschäftspartner jeweils intern abwickeln, in den elektronischen Anwendungen abzubilden und hierbei den Prozess der gesamten Abwicklung zu optimieren. Nach den WebFarm-Standards ist es sehr schwer und bis heute auch nicht gelungen, ein absolutes Standardprodukt für die Erstellung von Business-to-Business-Anwendungen zu verwenden, da die Workflow-Komponenten und Anforderungen sehr unterschiedlich ausfallen können. Darum werden bereits existierende Komponenten vorgeschlagen, mit denen Business-to-Business-Lösungen aufgebaut werden können.

265

Sandini Bib 21 Website-Werkzeuge und Serveranwendungen

Customer-Shops Klassische Katalogbestellsysteme, bei denen aus einem gegebenen Spektrum an Produkten ein Warenkorb mit Anzahl ausgewählt und anschließend ein Bezahlungsvorgang direkt angestoßen werden kann (E-Cash, Kreditkarte, …) und ein entsprechendes, mit Optionen versehenes Logistikkontrollsystem angesteuert werden kann, ist eine der Applikationen, die im Internet den kommerziellen Nutzen eingeläutet haben. Es ist offensichtlich, dass für diesen Vorgang im WebFarm-Standard Vorgaben getroffen werden sollte. Einerseits muss es sich um ein Produkt handeln, das weltweit einsetzbar ist, damit die unterschiedlichen Zahlungssysteme und logistischen Anforderungen abgedeckt werden können, und andererseits muss das System dermaßen individualisierbar sein, dass die Kataloge und Produktsortimente eines Anbieters in exakt dessen Design und Umgebung dargestellt werden können. Für die Integration solcher Shop-Lösungen in den WebFarm-Standard muss die Einbindung der Systeme in das Content-Management-System, über das einerseits die Inhalte der Kataloge eingestellt werden müssen, aber auch eine Verknüpfung zu Hintergrundinformationen entstehen, ein entscheidendes Kriterium sein. Denn eine reine Transaktionslösung ist nur für die wenigsten Verkäufe ausreichend, vielmehr muss eine Verknüpfung von Information und Transaktion erfolgen, die im WebFarm-Standard durch das umfassende Content-Management-Konzept hergestellt wird.

21.2 Serveranwendungen 21.2.1

Share/Teamworkanwendungen

Teamwork lässt sich wie in den bereits beschriebenen Communities auch in einem Unternehmen intern durch eine webbasierte Plattform gut unterstützen. Der WebFarm-Standard schafft hier eine Kopplung von reinen Teamworkwerkzeugen und den Informationen, die über Knowledge-Pool und Content-Management allgemein bereits verfügbar sind. Werkzeuge, die nach dem WebFarm-Standard Teamwork und -Sharing unterstützen wollen, müssen eine Kopplung von allgemeinen Diskussionen, File-Sharing-Funktionen, Whiteboards und anderen Gruppenarbeitsanwendungen zur Wissensbasis, die im WebFarm-System abgelegt ist, herstellen können. Hierzu kann eine API oder ein Standard-Interface direkt in den Programmen verwendet werden. Durch den Einsatz von Teamworkanwendungen ist die Unterstützung eines weltweiten Arbeitens, wie sie mit der Webplattform oft gedacht ist, tatsächlich erst möglich. Es kann nur gemeinschaftlich gearbeitet werden, wenn für

266

Sandini Bib Backoffice-Anwendungen

die Teamumgebung ein absolut stringenter Standard ausgearbeitet wird, ab den keinerlei Modifikationen, auch nicht über WebFarm-Lokationen hinweg, zugelassen sind.

21.2.2

Streaming

Streaming oder die gebündelte Übertragung von Daten von einem Server zu bestimmten Clients gewinnt mit der multimedialen Verwendung von Informationen immer mehr an Bedeutung. Mit Streaming-Anwendungen werden einfache Übertragungen wie z.B. von Vorträgen und Pressekonferenzen in Richtung des Internets, aber auch des Intranets oder auch komplexere Anwendungen wie Business-TV über den Computer ermöglicht, was die teure Installation eines eigenen Fernsehnetzes komplett einspart. Ausschlaggebend für den Einsatz solcher Streaming-Formate und Server in einer WebFarm-Umgebung ist der Einsatz von Punkt-zu-Punkt-Verbindungen nur dort, wo diese absolut erforderlich sind, und die Verwendung von bandbreitenschonenden Multicast-Mechanismen, wo diese möglich sind. Zudem muss eine gute Client-Struktur unterstützt werden, die für die allgemeine Verwendbarkeit der entstandenen Anwendungen garantiert. Server und Clients, die diesen Anwendungen entsprechen, mit den entsprechenden Formaten, werden als Empfehlungen in die WebFarm-Standardliste aufgenommen.

21.3 Backoffice-Anwendungen 21.3.1

Mailinglisten

Mailinglisten sind eines der wichtigsten Informationsmedien für Kundenbindung. Die Verwaltung von Mailinglisten und der zeitnahe Versand von E-Mails sind entscheidend für den Erfolg solcher Ansätze. Im WebFarm-Standard wird darauf geachtet, dass sowohl Mailinglisten zur Kommunikation, ähnlich wie ein Board, nur nicht auf Basis einer Webanwendung, als auch Mailinglisten für die reine Einwegkommunikation, also die Informationsversorgung, eingesetzt werden können. Beide Anwendungsfälle treten in vielen kommerziellen Anwendungen sowohl intern als auch extern auf. Die Verwendung eines Standard-Mailsystems ist hierbei oberste Anforderung, da ansonsten keinerlei Skalierbarkeit gegeben ist. Lösungen, die nicht nur den reinen Mailversand, sondern auch die Erzeugung aller notwendigen Daten in Textversionen unterstützen, werden im WebFarm-Standard bevorzugt, da hier eine bessere Archivierung vorgenommen werden kann und bei entsprechend großen Mailinglisten ein Clustering des Mailsystems erfolgen kann.

267

Sandini Bib 21 Website-Werkzeuge und Serveranwendungen

21.3.2

Rules-Engine

Oft wird eine echte Geschäftslogik direkt in Programme von Webanwendungen integriert. Dies hat den Vorteil, dass mit den Entwicklungsmethoden des Internets eine sehr schnelle Realisierung von elektronischen Prozessen realisierbar ist. Der Nachteil in hart kodierter Business-Logik ist, dass Plausibilisierungen und kleine Änderungen an der Logik, wie sie vor allem bei der Erfassung von Anträgen, Befragungen usw. auftreten, jedes Mal die knappen Ressourcen von Programmierern erfordern und nicht direkt von den Fachleuten, welche die Änderung anfordern, umgesetzt werden können. Eine Rules-Engine schafft hier Abhilfe, indem die Regeln, die zur Programmverarbeitung verwendet werden, für bestimmte Anwendungen in eine Basis ausgelagert werden, die selbständig den Prozess zusammensetzt. In dieser Basis können Fachleute über grafische Interfaces problemlos die logischen Schritte manipulieren und die Logik an sich verändern, ohne dass eine Programmierung notwendig ist. Der Einsatz solcher Engines ist im WebFarm-Standard in größeren Anwendungen, die geschäftskritische Prozesse oder Prozesse, die gesetzlichen oder logischen Beschränkungen unterworfen sind, empfohlen.

268

Sandini Bib

III Systembetrieb

Sandini Bib

Sandini Bib

22

Betriebsumgebung

Für die Schaffung eines einheitlichen Systembetriebs für alle nach dem WebFarm-Standard entwickelten und entworfenen Systeme und Anwendungen ist eine standardisierte Betriebsumgebung Voraussetzung, welche die Vorgaben des WebFarm-Standards einhält und sich in die gegebene Infrastruktur nahtlos integriert. Im Folgenden wird der Aufbau einer Administrationsumgebung und die Verbindung einzelner Applikationen zu bestimmten in der Infrastruktur gebotenen Diensten behandelt. Außerdem werden die Dienstleistungen des Basissystembetriebs beschrieben. Darunter werden alle Tätigkeiten verstanden, die für die eigentliche Aufrechterhaltung des Betriebs und damit der Verfügbarkeit der Systeme erbracht werden. In diesem Zusammenhang sind Verfügbarkeit und Performance sowie Durchsetzung Themen, die für die Einstufung des Systembetriebs betrachtet werden müssen.

22.1 Administrationsumgebung Die heutigen Anforderungen an Betriebsgruppen in der IT-Welt gestalten sich sehr vielfältig. Es wird eine vollkommen abgeschlossene und extrem stabile Umgebung gefordert, die jeglichen Änderungen und Anforderungen standhält. Für herkömmliche Anwendungen ist dieses Problem in Rechenzentrumsumgebungen gut gelöst. Dort existieren Test- und Übergabeverfahren sowie Update- und Änderungsverfahren, die den ununterbrochenen Systembetrieb abdecken und allen Benutzeranforderungen vor allem in Richtung Sicherheit und Stabilität nachkommen. Zumeist ziehen diese Verfahren eine berechenbare Inbetriebnahmezeit und komplexe organisatorische Verfahren vor und nach sich. Im Bereich der Neuen Medien wird eine solche Umgebung erheblich gefordert, da sich die Anwendungen im Webbereich ausgesprochen rasant entwickeln und wesentlich schnelle Änderungs- und Innovationszyklen haben. Außerdem ist es vielfach schwer möglich, derartige Anwendungen komplett zentralisiert zu fahren; vielmehr ergibt sich ein komplexes und vor allem global verteiltes Netzwerk von Abhängigkeiten verschiedener Dienste und Dienstleistungen, die zusammen eine Anwendung darstellen. Neben diesen rein technischen Anforderungen für den Betrieb ist es auch auffällig, dass im Rahmen der Neuen Medien die eigentlichen Entwickler- und Fachabteilungen wesentlich näher zusammengerückt sind.

271

Sandini Bib 22 Betriebsumgebung

Durch die automatische Globalisierung von Anwendungen im Bereich der Neuen Medien ist auch ein 24-Stunden/7-Tage-Betrieb für solche Anwendungen sinnvoll. Vor dem Hintergrund des Aufbaus der WebFarm-Infrastruktur ist das beschriebene WebFarm-Betriebskonzept, das möglichst dezentral aufgesetzt ist, jedoch so, dass eine zentrale Einsicht und eventuell auch ein zentrales Eingreifen immer möglich sind, der nach dem WebFarm-Standard gewählte Lösungsansatz. Auf diese Weise können verteilte Anwendungen mit komplexen Abhängigkeitsnetzwerken verwaltet werden. Der wichtigste Aspekt im WebFarm-Betrieb ist die Automatisierung wiederkehrender Vorgänge sowie die automatische Überwachung und Alarmierung im Fehlerfalle.

22.1.1

Administrationsserver

Jede WebFarm-Lokation hat einen Administrationsserver mit, entsprechend dem WebFarm-Fail-over-Konzept, verfügbarem, gleichem Backup-System. Dieser Administrationsserver ist der zentrale Punkt für die Datenübergabe an die WebFarm-Administration für eine bestimmte Lokation. Der unten definierte hierarchische Aufbau des WebFarm-Systems bezieht sich auch auf die Hierarchien des WebFarm-Administrationsservers. Der Administrationsserver ist die Plattform für alle Automatisierungen innerhalb des WebFarm-Systembetriebs und ist daher eine zentrale Komponente des gesamten Betriebsbereiches. Weiterhin dient der Administrationsserver als Zugangsserver für den gesamten Webbetrieb. Ein Administrationsserver bietet für jeden Administrator durch eines »goto«-Kommandos den Zugang zu jedem hierarchisch tiefer liegendem System, innerhalb der WebFarm-Administrations-infrastruktur auf Basis von Agententechnologie, um das einheitliche Zugangsverfahren des WebFarm-Standard umzusetzen.

22.1.2

Verteilte WebFarm-Betriebspunkte

In das Konzept des WebFarm-Systembetriebs sind viele Konzepte verteilter Systeme eingeflossen. Ansonsten wäre kein anscheinend zentraler Betrieb so verteilt auftretender Systeme, wie dies im Webbereich der Fall ist, möglich. Zur besseren Kontrolle der Hardware bietet es sich an, die Hardware der Systeme in einer Lokation an einem Ort zu sammeln, die einzelnen Lokationen für sich sind aber untereinander vernetzt. Dies ermöglicht auch eine quasi zentrale und trotzdem dezentrale Systempflege. So können Patches vom zentralen Betrieb aus verteilt, aber auch lokal eingespielt werden und stehen danach sogar dem zentralen Betrieb zur Verfügung.

272

Sandini Bib Administrationsumgebung

Die administrative Vernetzung der einzelnen WebFarm-Lokationen muss allerdings streng hierarchisch verlaufen, damit keinerlei Kreisverteilungen auftreten. Im Allgemeinen hat eine echte WebFarm-Lokation einen Administrationsserver, der als Verteilungsknoten aktiv ist und der alle Aufgaben zur Kontrolle übernimmt. Lokale Administratoren greifen über den lokalen Administrationsserver auf die Konfiguration und das Management der lokalen Server und Applikationen zu bzw. auf eben diese Funktionen untergeordneter Farms oder Gardens. Eine zentrale Administration kann somit hierarchisch auf alle angeschlossenen Systeme zugreifen. Bei diesem Aufbau der Administration kann auch ein Outsourcing des Systemmanagements problemlos in die lokale Administration integriert werden, ohne dort alle Funktionalitäten oder Zugriffsrechte abzugeben.

22.1.3

Backup-Verfahren

Der WebFarm-Standard beschreibt in der Infrastruktur bereits die Anforderungen für ein verteiltes und lokales Backup der einzelnen Rechner und Dienste sowie die Fail-over-Strategie und Funktionalität im Bereich der WebFarm-Entwicklung. Der Systembetrieb der WebFarm-Lokationen ist für die Durchführung der Backups verantwortlich und muss in regelmäßigen Abständen, aber mindestens zweimal pro Jahr die Wiederherstellung von Systemen über die Backup- und Recovery-Verfahren des WebFarm-Standards durch einen Test prüfen. Backup-Strategie Für unterschiedliche Servertypen sollten unterschiedliche Backup-Verfahren verwendet werden. Diese werden durch die Ausfallwahrscheinlichkeit des Servers, die Änderungsfrequenz der Daten, die Benutzeranzahl und Benutzerkompetenz auf einem Server und die Datenmenge bestimmt. Grundsätzlich kann man zwischen reinen Vollsicherungsverfahren, ebensolchen mit inkrementellen Sicherungen und Verfahren sowie einem Logbuchverfahren, welches vor allem bei Sicherheitssystemen eingesetzt wird, unterscheiden. Bei einem Vollsicherungsverfahren wird zu jeder Datensicherung eine komplette Kopie der gesamten Maschine erzeugt. Bei einem Vollsicherungsverfahren mit inkrementellen Sicherungen wird am Anfang eines Intervalls immer eine Vollsicherung des gesamten Systems gezogen und dann in jedem Intervallschritt eine inkrementelle Sicherung erstellt, bis beim nächsten Intervallanfang wieder eine Vollsicherung entsteht. Bei einem rein inkrementellen Verfahren wird eine Urkopie der Maschine erstellt, und dann werden von dieser nur inkrementelle Sicherungen erzeugt. Dieses Verfahren bietet sich bei reinen Datenservern an.

273

Sandini Bib 22 Betriebsumgebung

Bei einem Logbuchverfahren wird von einer abgenommenen Installation ein Sicherungssatz erzeugt. Jede Änderung am System wird protokolliert und die entsprechende Software zum Protokoll abgelegt. Bei einer Reinstallation des Systems wird dann wieder das abgenommene Originalband eingespielt und die Änderungen bis zu einem Zeitpunkt eingespielt, zu dem man sich der Systemfunktionalität absolut sicher ist. Der WebFarm-Standard hat innerhalb seiner Infrastruktur ein definiertes Backup-Verfahren, das auf diese Strategien eingeht. Der Systembetrieb der WebFarm-Lokationen hält sich definitiv an dieses Backup-Verfahren und kann auf diese Weise gegebene Restore-Zeiten nach den WebFarm-StandardServiceleveln einhalten. Sicherheitssysteme im Backup-Verfahren Sicherheitssysteme sollten auf jeden Fall mit einem Logbuchverfahren gesichert werden. Es müssen bei der Neuinstallation eines solchen Systems auf jeden Fall alle verwendeten Softwareprodukte, Patches und andere Installationsänderungen vorliegen und manuell nachgeführt werden. Zusätzlich ist die Sicherung solcher Systeme über das Backup-System, das dem globalen Standard entspricht, wie z.B. Legato Networker oder IBM ADSM denkbar, so dass verschiedene Versionen ebenfalls geführt werden können. Nach dem WebFarm-Backup-Konzept werden alle Systeme, also auch die Sicherheitssysteme, zusätzlich zur Erhöhung der Restore-Geschwindigkeiten, soweit möglich, auf lokale Bänder gesichert. Diese werden bei einem normalen Restore bei Mediendefekten oder anderen Hardwareproblemen verwendet. Bei sicherheitskritischen Restores, z.B. nach einem Angriff, muss aber auf jeden Fall auf das Logbuchverfahren zurückgegriffen werden. Das BackupSystem kann nur bei Konfigurationsfehlern eingesetzt werden. Aufbewahrung Die für die Aufbewahrung auch an sicheren Orten außerhalb des direkten Zugriffs des Systembetriebs notwendigen Verfahren und Fristen sind im WebFarm-Standard bereits festgehalten. Sie werden im Bereich der FirewallInfrastruktur gepflegt. Diese Fristen müssen eingehalten werden, um einen WebFarm-konformen Betrieb zu gewährleisten. Der Systembetrieb einer WebFarm-Lokation bzw. der zentrale Betrieb stellen hierbei sicher, dass die entsprechenden Verfahren und Datenströme sichergestellt werden, damit Softoder Hardwarekopien der Sicherungen für diese Aufbewahrung zur Verfügung stehen.

274

Sandini Bib Leistungsbeschreibung im Systembetrieb

22.2 Leistungsbeschreibung im Systembetrieb Die vom Systembetrieb nach dem WebFarm-Standard zu erbringenden Leistungen beziehen sich auf den Betrieb der Webinfrastruktur, die nach dem WebFarm-Standard entwickelt und in einer WebFarm-Lokation betrieben werden, in Bezug auf Hardware- und Softwarebetrieb, Überwachung, Fault-, Performancemanagement, Implementierung von Verfahren, Hotline und Verwaltung von Berechtigungen und Configuration-Management. Die Aufgaben gliedern sich in drei Hauptgruppen: 왘 Teil A: Laufender Betrieb 왘 Teil B: Aufträge 왘 Teil C: Entwicklung

Die im Folgenden definierten Teile des Systembetriebs sind in verschiedenen Unterpunkten angeordnet, damit die Leistungen für bestimmte Maschinen und Dienste in späteren Kapiteln direkt referenziert werden können.

22.2.1

Teil A: Laufender Betrieb

Der laufende Systembetrieb ist das Tagesgeschäft des Systembetriebs an sich. In diesem Bereich werden alle Ziele und Aufgaben für eine Maschine oder einen Dienst definiert, der sich nach dem WebFarm-Standard im Betrieb befindet. Zielsetzung des Betriebs Die hier definierten Punkte sind die Ziele der Betriebsdienstleistung innerhalb des WebFarm-Standards. Diese Zielsetzungen müssen für die einzelnen Systeme und Dienste erbracht werden, damit von einem WebFarm-Betrieb gesprochen werden kann.

275

Sandini Bib 22 Betriebsumgebung

Zielsetzungen 1.1

Erstellung der für einen nachvollziehbaren Betrieb erforderlichen Dokumentationen

1.2

Beratung und Unterstützung zur WebFarm-Infrastruktur

1.3

Fehlerbehebung

1.4

Alarmierung bei Betriebsstörungen

1.5

Überwachung der in der WebFarm-beheimateten Websysteme 24 h/ 365 Tage

1.6

Durchführung des Systemmanagements für WebFarm-Systeme wie Ablaufüberwachung, Kapazitäts- und Performancemanagement, Informationssicherheit und Datengewinnung für das Accounting, Konfiguration, Betriebssystem, Wartung des Betriebssystems, Konfiguration und dessen Automatisierung mit Ausnahme der aktiven LAN-Komponenten

1.7

Einsatz neuer Dokumenteninhalte und Anwendungen

Tab. 22.1: Zielsetzungen des WebFarm-Betriebs

Hinweis: Nicht Gegenstand des WebFarm-Systembetriebs ist der Betrieb, das Management oder die Konzeption und Planung von Netzkopplungen, da diese eine weitergehende Infrastruktur betreffen. Aktivitäten des Betriebs Im Folgenden werden die Aktivitäten des Systembetriebs aufgeführt, die nach dem WebFarm-Standard durchgeführt werden müssen. Dabei gelten im Einzelnen die im WebFarm-Standard global bzw. in Servicelevel-Agreements für einzelne Systeme festgelegten Reaktionszeiten und Eskalationsverfahren. Voraussetzung des Systembetriebs ist selbstverständlich immer das Verfügbar sein entsprechender Lizenzen und Wartungsverträge, die nicht durch den Systembetrieb an sich sichergestellt werden müssen.

276

Sandini Bib Leistungsbeschreibung im Systembetrieb

Betriebsaktivitäten 2.1

Hardwareadministration Allgemeine Konfiguration Konfiguration des Hardwarebackup Backup-Erzeugung und -Überwachung Prozessdimensionierung (Filesysteme, …) Ressourcenüberwachung (Platten, Prozessoren, Netzkapazitäten, …) Regelmäßiges Scannen des GAN nach »inoffiziellen« Webservern nach Absprache mit dem Betrieb der GAN-Infrastruktur

2.2

Softwareadministration Allgemeine Konfiguration Software-Backup-Konfiguration Backup-Erzeugung und -Überwachung Test von gemeinsam mit dem allgemeinen Systembetrieb standardisierten Backup-Strategien Betriebssystemupdates Installation und Update erforderlicher Software Überwachung der konsistenten Konfiguration des Systems

2.3

Serveradministration Prozessdimensionierung Konfigurationsüberwachung Regelmäßige Reorganisation der Systeme Problembearbeitung Cache-Space-Verwaltung Stichwortbezogenes und statisches Linkmanagement Einbindung und ggf. Erstellung von Skripten und programmen Archivierung von Logfiles auf CD-ROM bzw. anderen angemessenen Sicherungsumgebungen Monatliche Statistikgenerierungen Soweit über Schnittstellen beeinflussbar, sollen die Meldungen in deutscher und englischer Sprache vorhanden sein. Erst- und Verlängerungsbeantragung von Zertifikaten für SSL-Webserver und eine PKI-Umgebung

Tab. 22.2: Übersicht Betriebsaktivitäten

277

Sandini Bib 22 Betriebsumgebung

Betriebsaktivitäten 2.4

Betrieb, Überwachung und Automatisierung 24 Stunden und 365 Tage Regelmäßige Prüfung der Funktionstüchtigkeit der eingesetzten Alarmsysteme Performanceüberwachung und Einstellung der Ergebnisse auf Administrationsserver Fehlerbehebung Alarmierung bei Betriebsstörungen nach Absprache mit dem globalen Systembetrieb Benutzerservice-Eskalation LAN-Support in den WebFarm-Infrastrukturen Kommunikation und Abwicklung mit anderen zuständigen Fachabteilungen Überwachung und durch Beauftragung die Behebung von Leitungsproblemen der Internet-Provider Andauerndes Überwachen der Funktionalität der Systeme, Erreichbarkeit der Internet-Systeme aus dem Internet und dem Web, der Auslastung von Ressourcen durch Erstellung und Einbindung von Automatisierungstools und Skripten Ziel ist es, eine umgehende Problem-/Fehlerbehebung an den betroffenen Komponenten zu gewährleisten. Dazu ist es notwendig, dass im Falle etwaiger Störungen das Supportteam der WebFarm-Umgebung nicht unter dessen Aktivitäten fallende Fachabteilungen bzw. von entsprechend beauftragten Firmen alarmiert. Logbucheinträge (gemäß 3.6) durchführen.

2.5

Logging für Accounting und Billing Erstellen von Logfiles nach Maßgabe des WebFarm-Standards und Überleiten auf einen zu benennenden Accounting-Server innerhalb der WebFarmInfrastruktur, der ebenfalls vom Systembetrieb der entsprechenden WebFarm-Lokation als Dienstleistung innerhalb der Infrastruktur betreut wird.

2.6

Statistik Einsatz eines mit dem WebFarm-Standard konformen Statistiktools für das Web, Generierung der aktuellen Auswertungen des abgelaufenen Monats bis zum sechsten Arbeitstag des folgenden Monats und zur Bereitstellung auf einem ausschließlich für den betreffenden internen Kunden zugänglichen Webserver-Bereich.

2.7

Serverautomatisierung Zur Überwachung der Link-Struktur und zum Einspielen, Konvertieren und Anpassen neuer Dokumente in den Webservern wird das nach dem WebFarm-Standard eingesetzte Content-Management und Information-Modelling-Werkzeug eingesetzt.

Tab. 22.2: Übersicht Betriebsaktivitäten

278

Sandini Bib Leistungsbeschreibung im Systembetrieb

Betriebsaktivitäten 2.8

Redaktionsserver (Übergabesystem) Bei Nutzung des WebFarm-Standardverfahrens zum Content-Management und Information-Modelling wird eine maschinelle Prüfung auf Einhaltung des/der Style-Guides, Link-Prüfung und Zeitsteuerung für Veröffentlichung bzw. Entfernung und Verteilung durchgeführt, sofern die Pages von des WebFarm-Software-Tools auf einem Webserver innerhalb der entsprechenden WebFarm-Lokation veröffentlicht werden. Die Übernahme von Websites erfolgt in den Praxisbetrieb mit den Produkten der WebFarm-Software-Site, die den aktuellen technischen Möglichkeiten entspricht.

2.9

Publishing-System/Content-Management-System/Information-ModellingSystem Durchführung des laufenden Betriebs, Administration und Überwachung der systemrelevanten Komponenten eines Systems.

Tab. 22.2: Übersicht Betriebsaktivitäten

Aktivitäten für Aufbau und Unterhaltung der Infrastruktur Dieser Abschnitt befasst sich mit den Basisservices des WebFarm-Standardbetriebs, die einmalig bereitgestellt und laufend gepflegt werden, sie sind bei dem Betrieb der Einzelsysteme nach dem im WebFarm-Standard vorgeschlagenen SLAs jeweils enthalten. Aktivitäten 3.1

Administrationsserver Installation und Konfiguration eines Administrationsservers und dessen Backup für alle administrativen Tätigkeiten der WebFarm-(geordnete Ansammlung von Webservern unter kontrolliertem Betrieb). Anbindung über Firewall und Internet über Secure-Shell (SSH) mit mindestens 512 BIT Verschlüsselung des Datentransfers. Erstellung einer Liste der vergebenen Berechtigungen getrennt nach Betriebssystem, Serverprodukt und Applikation.

3.2

Eingesetzte Produkte und Werkzeuge Es werden die in der WebFarm-Software-Suite beschriebenen Produkte und Werkzeuge als Standardplattform eingesetzt. Andere Produkte und Verfahren können in Abstimmung zwischen Auftraggeber und WebFarm-Systembetrieb in die WebFarm-Software-Suite eingebracht werden, wenn diese den Prüfungen im Hinblick auf Tauglichkeit für den WebFarm-Standard durch arago standgehalten haben.

Tab. 22.3: Aktivitäten für Aufbau und Unterhaltung der Infrastruktur

279

Sandini Bib 22 Betriebsumgebung

Aktivitäten 3.3.

Archivierung der Dokumentation, Vorsorgeplanung, Archivierung von Logfiles, Accounting-Daten, Statistiken und deren Auswertung Die tägliche Sicherung der Systeme und Daten für Backups wird zeitgesteuert auf Bänder als Zusatzsicherung durchgeführt. Die Datensicherung für die Katastrophenvorsorge wird mittels global standardisierter angemessener Sicherungssoftware durchgeführt. Es ist durch regelmäßige Tests sicherzustellen, dass die Backups (Sicherungskopien) les- und brauchbar sind. Softwareversionen werden nach dem WebFarm-Standard auf CD-ROM gebrannt oder in definierten Webanwendungen der WebFarm-Administrationsinfrastruktur verwahrt. Die Datenträger sind zugriffssicher mindestens 24 Monate zu verwahren bzw. entsprechend der im WebFarm-Standard definierten Fristen aufzubewahren.

3.4

Dokumentation Die implementierten Betriebsverfahren und verwendeten Tools sind innerhalb des WebFarm-Standards definiert. Alle Ansprechpartner für die Durchführung des Betriebs sind für jede WebFarm-Lokation zu dokumentieren und aktuell zu halten. Durch die Dokumentation müssen Dritte, z.B. andere Mitarbeiter oder die hausinterne Revision, in der Lage sein, sich in angemessener Zeit in die Thematik einzuarbeiten bzw. an der Durchführung der Aufgaben mitzuwirken. Alle Sicherheitsregelungen und Regeln müssen im Logbuch der Sicherheitsinfrastruktur dokumentiert und nachgeführt werden. Jederzeit können alle aktuell auf den Systemen berechtigten Mitarbeiter und deren Zugangs- und Zugriffsberechtigungen bekannt gemacht werden. Über den Rahmen des WebFarm-Standards hinaus sind globale Standards, Richtlinien und Normierungen einzuhalten.

3.5

Zugang und Zugriff auf betreute Systeme Es muss gemäß der globalen Richtlinien ein Verfahren für den Zugang und Zugriff von anderen Mitarbeitern auf die innerhalb einer WebFarm-Lokation betreuten Systeme ausgearbeitet werden. Hierbei werden den Mitarbeitern keinerlei Berechtigungen zur Systemänderung eingeräumt, solange es sich nicht um einen K-Fall oder andere Notfallmaßnahmen handelt. Der konsistente WebFarm-Betrieb ist Grundvoraussetzung für die Einhaltung der im WebFarm-Standard definierten Service-Level. Zu diesem Zweck werden an einem gesicherten Ort ein Notfallhandbuch sowie die Zugangscodes für alle verwalteten Systeme hinterlegt. Alle Zugriffe auf diese Notfallcodes müssen protokolliert werden.

Tab. 22.3: Aktivitäten für Aufbau und Unterhaltung der Infrastruktur

280

Sandini Bib Leistungsbeschreibung im Systembetrieb

Aktivitäten bezogen auf Datenbank- und Datawarehouseserver Im Folgenden werden besondere Anforderungen für den Betrieb von Datenverwaltungsdiensten, die für Webanwendungen oft zwingend erforderlich sind, im Rahmen des WebFarm-Standardbetriebs definiert: Aktivitäten 4.1

Pflege der System-, TMP- und Instanceable-Spaces in Konsistenz, Größe und Performance bei Datenbanken. Datenvolumen müssen von den Fachabteilungen spezifiziert und entsprechende Änderungen in der Planung dem WebFarm-Systembetrieb mitgeteilt werden.

4.2

Überwachung ein- und ausgehender Datenschnittstellen, d.h. das Eintreffen von Dateien oder anderen Schnittstellenmechanismen.

4.3

Performancetest von Datenschnittstellen auf das betreute System.

4.4

Voraussetzungen für den Praxisbetrieb von Datenbanksystemen bei entsprechender Abhängigkeit anderer Anwendungen von diesen Systemen ist die Verwaltung der Zugriffsrechte und der auf den Datenbanken durchgeführten Operationen der entsprechenden Anwendungen selbst bzw. auch Dritter, welche die vorhandenen Datenbestände nutzen wollen.

Tab. 22.4: Aktivitäten bezogen auf Datenbank- und Datawarehouse-Server

Aktivitäten bezogen auf Firewallsysteme Besondere Services für die Betreuung von Firewall- und Securitymaschinen innerhalb des WebFarm-Systembetriebs und der Sicherheitsinfrastruktur im WebFarm- und im globalen Kontext werden im Folgenden aufgezeigt: Aktivitäten 5.1

Anpassung der Regeln nach dem im WebFarm-Standard definierten Auftragswesen.

5.2

Regelmäßige Überprüfung der Systeme auf Sicherheit.

5.3

Einrichten von Gateways nach dem im WebFarm-Standard definierten Auftragswesen.

5.4

Ergreifung von angemessenen Gegenmaßnahmen bei Angriffen auf die Systeme und entsprechende Benachrichtigung der benannten Ansprechpartner.

Tab. 22.5: Aktivitäten bezogen auf Firewallsysteme

281

Sandini Bib 22 Betriebsumgebung

22.2.2

Teil B: Aufträge

왘 Aufträge können z.B. Installation und Konfiguration von Servern, Auf-

nahme von Webservern und anderer für die Webinfrastruktur notwendigen Server in die WebFarm-Betriebsumgebung (geordnete Ansammlung von Webservern unter kontrolliertem Betrieb) sein. Dabei werden die im WebFarm-Standard definierten Verfahren und Formalien verwendet. 왘 Diese Tätigkeiten werden nur nach gesondertem Auftrag nach den im

WebFarm-Standard festgelegten Verfahren, wie oben angesprochen, durchgeführt. Die Honorierung der Leistungen erfolgt aufgrund der Serienfertigung innerhalb der sich im WebFarm-Standard bewegenden Systeme nach dem WebFarm-Standard-Gebührenmodell. Die Betriebsaufgaben im WebFarm-Kontext werden durch die bei Auftragsvergabe genau spezifizierten Aufgaben, Konzepte und Vereinbarungen in ServicelevelAgreements für die neuen Systeme nach dem WebFarm-Standard festgelegt. 왘 Vermittler oder Überbringer von derartigen Aufträgen an den WebFarm-

Betrieb, auch im Namen und für Rechnung für andere Abteilungen oder Tochterfirmen, sind dem WebFarm-Betriebsteam der jeweiligen WebFarmLokation bekannt zu geben. Die Beauftragung hat unter Berücksichtigung der WebFarm-Auftragsabwicklung zu erfolgen.

22.2.3

Teil C: Entwicklung

Es ist klar definiert, dass innerhalb des Systembetriebs nach dem WebFarmStandard keinerlei Anwendungsentwicklungen im Rahmen der allgemeinen Entwicklung von Anwendungen vorgenommen oder betrieben werden. Im Bereich der Webanwendungen ist aber oft ein sehr kurzer Zeitzyklus für die Behebung von Fehlern oder die Umleitung bestimmter Dienste unter definierten Voraussetzungen ausschlaggebend. Aus diesem Grund wird innerhalb der WebFarm-Betriebsumgebung die Möglichkeit geschaffen, Aufträge an das Betriebsteam, das immer verfügbar ist, zu vergeben, um juristisch oder anderweitig erforderliche Korrekturen zu beauftragen, die für einen weiteren Praxiseinsatz einer Webanwendung innerhalb einer WebFarm-Lokation notwendig sind. Entwicklungsaufträge können z.B. Analyse der Systemumgebung, Erstellung von Sonderstatistiken und Auswertungen, Korrekturen auf HTML oder andere Webseiten … sein. Diese Tätigkeiten werden nur nach gesondertem Auftrag gemäß der nach dem WebFarm-Standard vereinbarten Verfahren und Formalien durchgeführt.

282

Sandini Bib Verfügbarkeit

22.3 Verfügbarkeit Über die im WebFarm-Standard definierten Verfahren für das Fail-Over von Maschinen zur Steigerung der Verfügbarkeit ist es Ziel des WebFarm-Systembetriebs, ein möglichst ausfallfreies Systembild zu erzeugen. Die Verfügbarkeit eines Dienstes wird nach dem allgemeinen WebFarm-Standard auf 98% zu den Hauptbetriebszeiten ohne Betrachtung eventuell erforderlicher und geplanter Wartungsfenster festgelegt. Dabei darf ein Ausfall, auch wenn die 98% danach immer noch eingehalten werden, nicht länger als zwei Stunden dauern. Diese Verfügbarkeit ist mit den Konstruktionen des WebFarm-Betriebes und der WebFarm-Infrastruktur sowie Anwendungen, die nach den Regelungen der WebFarm-Anwendungs-entwicklungsrichtlinien entworfen wurden, problemlos möglich.

22.4 Performance Die Abschätzung eines Mengengerüsts ist bei Webanwendungen und damit bei Systemen im Betrieb einer WebFarm-Lokation nur schwer möglich, da selbst absolute »Best-Case«-Schätzungen, die bisher Gültigkeit hatten, durchbrochen werden. Die für die Serverinfrastruktur konzipierten Server sind so ausgelegt, dass mindestens 512 Transaktionen zur exakt gleichen Zeit durchgeführt werden können. Der Commit-Time-Out einer Transaktion wird hierbei mit 10 Sekunden angenommen. Betrachtet man diese Werte theoretisch auf einen Hauptgeschäftszeitraum von 8 bis 18 Uhr, können 1.843.200 Transaktionen durch das System geschleust werden. Der WebFarm-Systembetrieb und das entsprechende Performancemanagement ist darauf ausgerichtet, diese Transaktionen zu überwachen und entsprechend der Auslastungsentwicklung der Plattformen neue Erweiterungen gemäß des WebFarm-Konzepts als Präventivmaßnahme vorzuschlagen.

283

Sandini Bib

Sandini Bib

23

Hardwaremanagement und Systemüberwachung

Im Folgenden wird festgelegt, wie Hardware gewartet werden muss und welche hardwaretechnischen und vertraglichen Anforderungen der WebFarmBetrieb stellt. Außerdem wird die Basisüberwachung der Systeme von Hardund Softwareseite festgehalten, die das Kernstück des Hochverfügbarkeitsbetriebs darstellt.

23.1 Hardwaremanagement Hardwaremanagement ist die Grundvoraussetzung eines jeden Systembetriebs, da jedes System Hardware als Basis hat. Im WebFarm-Betrieb orientiert sich das Hardwaremanagement an den verschiedenen Servicelevels der im Betrieb befindlichen Systeme.

23.1.1

Wartungsverträge

Grundsätzlich benötigt man für den Betrieb einer Softwareumgebung zu bestimmten Servicelevels einen Hardwarewartungsvertrag vom entsprechenden Hersteller, der gewährleistet, dass bei Hardwareproblemen auch die Wiederherstellungszeit oder Reaktionszeit für die Anwendung gehalten werden kann. Da im WebFarm-Standardkonzept jedes System doppelt ausgelegt ist, sollten diese Verträge eine Reaktionszeit des Herstellers von maximal vier Stunden zugrunde legen und einen Austausch von Komponenten innerhalb von maximal 24 Stunden garantieren. Nachdem Harddisks und Speicher die am häufigsten defekten Teile im Bereich der Hardware sind, hält jede WebFarm-Lokation mindestens drei Harddisks und zwei Speichersätze auf Lager.

23.1.2

Standardsysteme

Der WebFarm-Standard legt einen Hardwarestandard mit drei unterschiedlichen Basiskonfigurationen von Maschinen fest. Dabei bestimmt die Anwendung, welche Basiskonfiguration verwendet wird. Grundsätzlich werden nur UNIX-Server verwendet, die aufgrund der allgemeinen Stabilitätsbetrachtungen im WebFarm-Standard ausgesucht wurden.

285

Sandini Bib 23 Hardwaremanagement und Systemüberwachung

Die folgenden drei Systemtypen werden verwendet: System

Ausstattung

Verwendung

Standardsystem

Rechner mit 1 CPU, 512 MB RAM, 2*9 GB Platte (Rechner ausbaubar auf 2 CPU, 1 GB RAM)

Basiswebserver

Erweitertes System

Rechner mit 2 CPU, 1 GB RAM, 1*9 GB 1*18 GBPlatte (Rechner ausbaubar auf 2 CPU)

Webserver mit Applikationen, die grundsätzlich auf dem System laufen, bzw. Automatisierungsprozessen, die mehr als 10% der Systemlast eines Standardservers beanspruchen.

Applikationssystem

Rechner mit 2 CPU, 1 GB RAM, 2*18 GB-Platte (Rechner ausbaubar auf 4 CPU)

Applikationen, die einen ApplicationServer verwenden bzw. massiven Datenbankzugriff haben.

Tab. 23.1: Übersicht Standardsysteme

23.1.3

Hardware-Fault-Betrachtung

 
        

 






  

 







Abbildung 23.1: Hardwareausfälle

286
















Sandini Bib Überwachungsverfahren

Die Betrachtung von Hardwareausfällen führt zu der in der WebFarm-Infrastruktur und im WebFarm-Betriebsstandard verwendeten Konfiguration von zwei Systemen und dem Vorrat an Festplatten und Speicher, wie er im WebFarm-Standard vorgeschrieben ist.

23.2 Überwachungsverfahren Das WebFarm-Überwachungsverfahren ist das Kernstück des kontinuierlichen WebFarm-Betriebs. Neben der herkömmlichen Systemadministration, bei der die Aktualität der Systeme und Softwarepakete gewährleistet wird, stellt die Überwachung den Betrieb der Maschinen sicher. Das WebFarm-Überwachungsverfahren funktioniert über ein System von Agenten, die jeweils auf einem System tätig sind und dort die Systemfunktionalität sowie einzelne angebotene Dienste überwachen.

Abbildung 23.2: Überwachungsverfahren

Dieses Vorgehen unterscheidet sich von einem klassischen Network-Managementansatz dadurch, dass direktes Servicemanagement auf Dienstebene durchgeführt wird (Application-Monitoring). Im gewöhnlichen NetworkManagement werden die technischen Voraussetzungen für einen Dienstbetrieb bzw. für den System- oder Netzbetrieb überwacht und somit der Dienst oder das System als funktional bezeichnet. Im hier verwendeten Ansatz werden das System bzw. vom System angebotene Dienste aus Benutzersicht getestet, und erst wenn ein Fehler für den Benutzer oder eine Warnung des Systems vorliegt, werden Fehler gemeldet. Dieses Verhalten führt dazu, dass

287

Sandini Bib 23 Hardwaremanagement und Systemüberwachung

tatsächliches Fehlverhalten der Systeme sofort erkannt wird, und durch die Einarbeitung von Warnungen können Fehler zumeist korrigiert werden, bevor diese zu Tage treten. Vor diesem Hintergrund und aufgrund von bestimmten Klassen von Zuständen, sowohl bei der System-, der Log-, als auch der Dienstüberwachung, kann das Überwachungssystem dann ein Eskalationsverfahren anstoßen, das einen bestimmten Servicelevel, und damit »Quality of Service«, für jeden Rechner und Dienst je nach Definition regelt und gewährleistet. Dieser WebFarm-Ansatz zur Systemüberwachung ist auf ein globales Überwachungsnetzwerk mit der Möglichkeit des Einbeziehens externer Partner ausgerichtet, das dennoch eine zentrale und auch dezentrale Administrierbarkeit von Systemen sicherstellen kann. Bei einer derartigen Konfiguration kann von jedem Überwachungspunkt aus jedes System hinter diesem Überwachungspunkt eingesehen und administriert werden. Das WebFarm-Infrastrukturkonzept sieht vor, dass eine Hierarchie von Überwachungspunkten aufgebaut wird, dass auch Cluster geschaffen werden können, die selbst wieder zentral administrierbar sind.

23.3 Konfigurationsmanagement Das oben beschriebene Überwachungssystem muss nach dem WebFarmStandard durch ein zusätzliches Konfigurationsmanagement ergänzt werden. Dabei gilt das Konfigurationsmanagement nicht im Sinne der reinen Versionskontrolle, sondern im Sinne der Konfigurationskontrolle der einzelnen überwachten Maschinen und Dienstleistungen. Jeder Agent kann zu einem System und zu jedem auf dem System konfigurierten Dienst mehrere Konfigurationsdateien übersendet bekommen. Diese Dateien werden dann zu den Sammelstellen des Überwachungssystems übertragen und liegen dort entsprechend in einer Sicherungsversion vor. Je nach Konfigurationsänderung lassen sich verschiedene Modi im Überwachungssystem erörtern, auf die jedoch an dieser Stelle nicht näher eingegangen werden soll.

23.4 Logging-Verfahren Vor allem im Rahmen von Sicherheitskonfigurationen ist das Aufzeichnen von wichtigen Ereignissen unerlässlich. Aber auch im Zusammenhang mit Revisionstests oder anderen Überprüfungen sind Aufzeichnungen von bestimmten Ereignissen unbedingt erforderlich. Dabei sind die Grundsätze des Datenschutzes und der Sicherheit von existentiell wichtigen Daten zu beachten.

288

Sandini Bib

24

Softwaremanagement

In einer sehr schnellebigen Umgebung, wie es der Bereich der Neuen Medien und des Internets insbesondere ist, ist die Verwaltung von Software eine essenzielle Aufgabe innerhalb des Systembetriebs. Im gewöhnlichen Softwaremanagement geht es oft darum, langfristig geplante Releases einer Software an möglichst viele Clients zu verteilen und dabei zu wissen, welcher Client welche Gesamtkonfiguration hat. Im Web geht es darum, möglichst zeitnah Software an ihren Bestimmungsort zu bringen und dabei trotzdem sicherzustellen, dass keine Sicherheitsprobleme oder Lizenzfragen offen bleiben. Im Folgenden werden die Ansätze im WebFarm-Standard dokumentiert, mit denen Software im Allgemeinen verwaltet wird.

24.1 Softwaredefinition Software im herkömmlichen Sinne ist jede Art von Programm, die über das Standardbetriebssystem hinaus auf einem Rechner installiert wird. Diese Definition ist sicherlich informatisch korrekt, für den praktischen Betrieb von Websystemen allerdings nicht zu verwenden. Im WebFarm-Betrieb gibt es vier Arten der Software, die für das Management relevant sind und die einzeln betrachtet werden müssen.

24.1.1

Betriebssystem

Die Betriebssystemsoftware ist eine kritische Komponente innerhalb des Webbetriebs, da sie einerseits für die IO-Leistung des Gesamtsystems verantwortlich ist und andererseits die primäre Angriffsfläche für die weitreichendsten Angriffe auf die Sicherheitsstruktur eines Systems bietet. Das Betriebssystem und seine Basis-Patchlevel sind über die gesamte WebFarm-Infrastruktur hinweg festgelegt. Dies trifft auf die verschiedenen in einer WebFarm-Infrastruktur im Einsatz befindlichen Systeme zu. Die Erweiterung der Betriebssystemfunktionalität wird nach dem WebFarm- Standard ebenfalls als Bestandteil des WebFarm-Betriebs dokumentierten WebFarm-Patchverfahren durchgeführt.

289

Sandini Bib 24 Softwaremanagement

24.1.2

Basissoftware

Ist alle Software, die vom WebFarm-Standard explizit als Infrastrukturkomponente oder Basissoftware definiert wird. Diese Software ist für ein System zwingend notwendig, um einen Dienst auf niedrigster Ebene zu erfüllen. Zu dieser Softwaregruppe gehören unter anderem Webserver, Proxy-Server, LDAP-Server usw. Vom Standardisierungsgrad und vom Sicherheitsanspruch her stehen die Basissoftware und das Betriebssystem auf einer Ebene. Die Basissoftware wird also entsprechend den Vorgaben für das Betriebssystem nach dem WebFarm-Patchverfahren verwaltet. Zusätzlich wird eine Datenbank der Maschinen geführt, die eine Liste der verwendeten Basiskomponenten und deren Zusatzpakete dokumentiert. Ein solches Softwarelogbuch wird pro WebFarm-Lokation geführt und ermöglicht es, neben der Lizenzkontrolle auch auf eintreffende Sicherheitsmeldungen auf der Softwareebene zu reagieren. Die Software unterscheidet sich hier vom Betriebssystem, da zur Erfüllung einiger von Projekten geforderter Funktionalitäten zusätzliche Module oder Patches verwendet werden müssen.

24.1.3

Zusatzsoftware

Zusatzsoftware sind Komponenten, die als Standardprodukt verfügbar sind, die aber nicht der Standardinstallation eines Servicerechners der WebFarmInfrastruktur entsprechen. Solche Software wird notwendig, wenn bestimmte Funktionalitäten (z.B. Chat, …) zur Verfügung gestellt werden sollen. Diese Software kann mittelfristig in den Primärsoftwarekatalog des WebFarmBetriebs aufgenommen und dann auch über die Standard-Installationsaufträge beantragt werden. Alle Standardprodukte, die zusätzlich zu den ohnehin im WebFarm-Standard enthaltenen Softwarepaketen installiert werden sollen, werden als Zusatzsoftware geführt. Zur Installation einer Zusatzsoftware muss die Installationsanforderung an den Systembetrieb übergeben werden und entsprechend des WebFarm«-Packageing-Verfahrens verpackt sein. Zur Verteilung solcher Software, da sie auf einzelne Systeme fixiert ist, wird ebenfalls das Content-Pool-Verfahren verwendet und nicht der absolute Verteilungsautomatismus, der für Betriebssystem und Basissoftware eingesetzt werden kann. Alle Zusatzsoftware wird auf den Systemen unter /OPT/SOFTWARE installiert, wie dies bereits im Infrastrukturkonzept des WebFarm-Standards festgelegt ist.

290

Sandini Bib Übergabeverfahren

24.1.4

Projektsoftware

Projektsoftware sind alle Programme, die innerhalb eines Projektes für eine bestimmte Webapplikation oder andere Anwendung entstehen, die in der WebFarm-Infrastruktur betrieben werden. Das eigentliche Ziel der WebFarmInfrastruktur ist es, solche Software zu betreiben und ihr eine standardisierte und betriebssichere Umgebung zu bieten. Diese Software wird über das in der Infrastrukturkonzeption des WebFarm-Standards festgelegte PackageingVerfahren über das Content-Management-System an die entsprechenden Rechner verteilt. Eine Freigabe der Verwendung erfolgt über die im ContentManagement-System vorgeschriebenen Stufen. Auf diese Weise fällt die Projektsoftware auf jeden Fall nicht in die Patch-Verfahren zur normalen verwalteten Software des WebFarm-Betriebs.

24.2 Übergabeverfahren Die Übergabe von zu verwendender oder zu installierender Software an den Webbetrieb einer WebFarm-Lokation ist die Schnittstelle zu einzelnen Projekten und Anwendungen. Es ist klar zu unterscheiden zwischen Betriebssystem sowie Basissoftware und der Zusatz- und Projektsoftware.

24.2.1

Standardkomponenten

Die Standardkomponenten des Betriebssystems und der Basissoftware werden vom WebFarm-Betrieb selbständig verwaltet. Das bedeutet, dass hier alle Patches und sonstigen Maßnahmen vollkommen transparent für die Benutzer, Auftraggeber und Fachabteilungen durchgeführt werden. Der WebFarmBetrieb nimmt selbsttätig die Prüfung der einzelnen Komponenten vor und stimmt gegebenenfalls Freigaben mit den zentral Verantwortlichen direkt ab.

24.2.2

Zusatzkomponenten

Alle Zusatzkomponenten von Zusatz- und Projektsoftware werden dem Betrieb als fertige Pakete übergeben. Hier müssen entsprechende Unterschriften der Verantwortlichen zur Installation bereitstehen. Mit diesen Unterschriften wird die Lizenzverwaltung versorgt und eventuell eine unternehmensweite Freigabe der Software überprüft. Der WebFarm-Systembetrieb wird die Software, wenn sie fristgerecht angeliefert wird, einem zusätzlichen Sicherheitscheck unterziehen. Soll dieser umgangen werden, muss der Auftraggeber der Installation dies entsprechend

291

Sandini Bib 24 Softwaremanagement

schriftlich bestätigen und trägt damit die volle Verantwortung für das installierte Softwarepaket. Fristgerechte Anlieferung bedeutet mindestens 15 Arbeitstage vor der testweisen Inbetriebnahme. Bei der Standardsoftware wird eine angelieferte Version durch eine elektronische Unterschrift bzw. ein Zertifikat validiert und kann damit als die Version der Software, die für ein bestimmtes Projekt benötigt wird, erkannt werden.

24.3 Lizenzkontrolle Der WebFarm-Systembetrieb sorgt für eine Datenbank in jeder WebFarmLokation mit den auf jedem Server dieser Lokation installierten Softwarekomponenten. Diese Datenbank wird an zentraler Stelle der WebFarm-Infrastruktur zusammengeführt, damit eine zentrale Lizenzkontrolle und ein Lizenz-Reporting erzeugt werden können. Diese Datenbank umfasst auch, wie die Lizenzen validiert wurden; und wenn dies durch Projektteilnehmer oder andere Instanzen, die nicht zum WebFarm-Systembetrieb gehören, geschehen ist, enthält die Datenbank einen Verweis auf das entsprechende Dokument, in dem die Lizensierung vorgenommen bzw. die Lizensierung bestätigt wurde. Eine solche Bestätigung ist auch per elektronischer Unterschrift möglich.

292

Sandini Bib

25

Sicherheitsabstimmung

Allgemein ist die Systemsicherheit, wie schon oft betont, ein wichtiger Bestandteil eines geregelten Betriebs im Webumfeld. Der WebFarm-Systembetrieb regelt die Zugriffsberechtigungen und die Zugriffsmethoden auf die Systeme eindeutig und macht alle Zugriffe nachvollziehbar, damit die entsprechenden Anforderungen von Aufsichtsbehörden, Revisionen und eventueller Auftraggeber im Betriebs-Outsourcing auf jeden Fall erfüllt werden. Im Folgenden werden die Grundlagen für diese Transparenz beschrieben.

25.1 Systemsicherheit Die allgemeine Systemsicherheit ist in den Konfigurationsrichtlinien des WebFarm-Standards festgeschrieben, in denen konkrete Paketlisten mit entsprechenden Begründungen für die verschiedenen Systemtypen vorgegeben sind.

25.1.1

Systemsicherheit bezüglich Software

Grundsätzlich basiert die Konfigurationsrichtlinie aber darauf, dass lediglich die Komponenten innerhalb des Betriebssystems und von der Basissoftware installiert werden, die für einen Betrieb explizit erforderlich sind. Diese Regelung entspricht dem Konfigurationssatz für Firewalls: »Alles, was nicht explizit erlaubt ist, ist verboten« und wird umgewandelt zu »Alles, was nicht explizit benötigt wird, wird nicht installiert«. Diese Basisinstallationen von System und Software werden vom WebFarm-Betrieb bzw. vom arago WebFarm-Team getestet und ständig durchgeführt, so dass sie einen absolut aktuellen Stand haben und damit eine gute Systemsicherheitsstufe für die Basispakete des WebFarm-Standards und deren Zusammenspiel gegeben ist. Alle Änderungen in der Systemsicherheit sind einerseits über die Logfiles der Content-Managementsoftware, über die auch die Softwareverteilung vorgenommen wird, und andererseits über die Betriebslogbücher nachvollziehbar und entsprechen damit auch den Anforderungen für den Betrieb von sicheren Produktionssystemen. Da im Webbereich die Sicherheitsstandards sehr kurzen Änderungszyklen unterworfen sein müssen, werden gemäß dem WebFarm-Patchverfahren entsprechende Änderungen so schnell wie möglich implementiert, um die Systeme in einer WebFarm-Infrastruktur immer auf einem aktuellen Stand zu halten.

293

Sandini Bib 25 Sicherheitsabstimmung

25.1.2

Benutzerprofile

Grundsätzlich wird vorgegeben, dass auf den Systemen, die im Bereich einer WebFarm-Infrastruktur allesamt Serversysteme sind, keinerlei definierte Benutzer, das bedeutet personenbezogene Benutzer, agieren können. Das bedeutet, dass es auf jeden Fall die Systembenutzer für das normale Arbeiten des Betriebssystems inklusive des Super-User-Accounts, mit dem die Administration arbeitet, gibt. Zusätzlich gibt es Serveruser für definierte Dienste, wie z.B. HTTP-Server, Application-Server, Datenbankserver, die lediglich die Prozesse und Dateien des jeweiligen Dienstes verwalten, aber nicht den direkten Zugriff auf das System haben. Für alle Benutzer außer dem Super-User sind keine Passwörter oder anderen lokalen Zugangsverfahren auf das System implementiert. Wo möglich werden die Shells der Benutzer ausgeschaltet, um ein Agieren unter dieser Benutzerkennung von vornherein unmöglich zu machen. Die Zugriffsverfahren werden im Bereich Administrationszugriff dieser WebFarm- Standards niedergelegt. Mit diesen Verfahren wird sichergestellt, dass es keine Benutzer auf den Systemen gibt, die eventuell auslaufen könnten oder direkt in den Systembetrieb eingreifen können. Durch die im WebFarm-Standard verwendeten Übergabeverfahren für Content und Programme usw. werden lokale Benutzer auf den Maschinen absolut unnötig. Es ist eine absolute Betriebsanforderung für den Hochverfügbarkeitsbetrieb, dass keine weiteren lokalen Benutzer erforderlich sind.

25.1.3

Administrationszugriff

Durch das WebFarm-Konzept eines Single Point of Administration, der in lokale Unterpunkte unterteilt wird, aber immer verfügbar ist, ist die Zugriffsstruktur und damit auch das verwendete Verfahren ein wichtiger Faktor für das Funktionieren des Systembetriebs. Im Folgenden werden diese Faktoren beschrieben. Zugriffsstruktur Von den Administrationsservern aus, die im WebFarm-Standard in jeder Lokation der WebFarm zur Verfügung stehen, und die den dortigen Point of Administration markieren, werden die Administratoren direkt auf die Systeme zugreifen können. Der WebFarm-Standard lässt diesen Zugriff auch über Firewall-Komponenten hinweg zu, damit ein zentraler Zugriffskontrollpunkt entsteht. Durch diese zentralen Punkte kann der Point of Administration innerhalb einer Gesamt-WebFarm-Konstruktion zusammengeführt werden und somit, wie im Infrastrukturkonzept beschrieben, verschoben werden.

294

Sandini Bib Logbücher

Um die Verbindung zu einem bestimmten Server aufzubauen, kann ein Administrator von einem Administrationsserver mit einem im WebFarmStandard implementierten goto-Kommando alle notwendigen Verbindungskommandos ausgeben. Handelt es sich nicht um ein lokales System, muss dem goto-Kommando noch das Präfix der entsprechenden WebFarm-Lokation mitgegeben werden, also z.B. goto muc.proxy-in-1. Zugriffsverfahren Der Zugriff der Administratoren wird über ein Public-Private-Key-Verfahren durchgeführt. Alle Verbindungen zu allen Systemen werden immer verschlüsselt abgewickelt. Der Administrator muss hierzu seinen Private-Key durch das an seinem Administrationsrechner verfügbaren Verfahrens (PW, Smartcards, …..) entschlüsseln und kann somit eine Verbindung authentifizieren. Ein Agent kann diese Identifikation für weitere Verbindungssprünge (Hops) vorrätig halten, um eine Komplettverbindung über mehrere Administrationspunkte hin zu ermöglichen, ohne mehrfach eine Authentifizierung vom Administrator zu verlangen. Der Administrator wird mit der Authentifizierung immer Superuser auf den entsprechenden Systemen, da dieser der einzige Benutzer ist, der tatsächlichen Zugriff von außen auf das System hat. Das System protokolliert eine Verbindung automatisch für das Logbuch mit, so dass ein Administrator nachträglich seine Tätigkeiten auf den Systemen dokumentieren muss. Die Berechtigungen für die Public-Private-Key-Verbindungen werden zentral verteilt. Um einen Benutzer für den Zugriff auf ein System zu berechtigen, wird ein Public-Key in die Verteilung eingestellt und wird damit beim nächsten Durchlauf (täglich) auf die Systeme eingestellt. Nachdem der Zugriff auf diese Weise erlaubt ist, kann ein Administrator auf das entsprechende System zugreifen. Gegenüber den herkömmlichen Account-Methoden mit nachgeführten Super-User-Berechtigungen hat dieses Verfahren den Vorteil, dass ein Administrator, der keine Berechtigungen mehr hat, absolut zentral entfernt werden kann und damit auf jeden Fall keine Sicherheitslöcher entstehen.

25.2 Logbücher Für die Nachvollziehbarkeit des Systembetriebs, die für den Betrieb von Hochverfügbarkeitssystemen und Systemen, die sich auf geschäftskritische Prozesse des Unternehmens auswirken, zwingend gefordert wird, wird ein Logbuch über alle Zugriffe auf die Systeme geführt. Dieses Logbuch wird in einer WebFarm-Lokation geführt und in der Hierarchie der WebFarm-Loka-

295

Sandini Bib 25 Sicherheitsabstimmung

tionen repliziert, so dass ein Gesamtreporting möglich wird. Dieses Logbuch umfasst auch alle Systemmeldungen, die mit Aktionen eines Administrators zusammenhängen. Zur Sicherung dieser Einträge werden Checksummen über die entsprechenden Einträge vom Starttermin des Logbuches aus gebildet, so dass Änderungen die Checksumme ungültig machen würden und damit auf jeden Fall auffallen. Das Logbuch wird für automatische Aktionen automatisch geführt und für die manuelle Arbeit von Benutzern bzw. Administratoren von diesen mit einem Web-Frontend nachträglich gepflegt. Da alle Zugriffe auf den Systemen automatisch dokumentiert sind, kann es nicht passieren, dass unbemerkte Aktionen auf den Systemen stattfinden.

296

Sandini Bib

26

Sicherheitsantragswesen und Betriebsübergabeverfahren

Auch wenn im Webbetrieb vieles automatisch funktioniert, müssen bestimmte Vorgänge in die normalen Geschäftsprozesse des Unternehmens eingebunden werden. Dies bedeutet auf jeden Fall, dass definierte Übergaben und definierte Aufträge für bestimmte Aktionen erforderlich sind. Dies gilt vor allem für den Sicherheitsbereich und für alle sicherheitsrelevanten Tätigkeiten, aber auch für die eigentliche Beantragung neuer Systeme. Da die WebFarm-Administration eine Schnittstelle zu anderen Verfahren innerhalb des Unternehmens ist, die einer Fachabteilung oder einem Projekt einen Dienst anbietet, werden hier Informationen benötigt, die alle anderen Prozesse ermöglichen. Die zentrale Frage bei solchen Verfahrensweisen ist die Abwicklung, die Dokumentation und die Berechtigung zum Anstoß der Prozesse. Diese Fragen werden in diesem Dokument für den Bereich des WebFarm-Standards festgelegt.

26.1 Antragsverfahren Das WebFarm-Konzept sieht für alle Anträge die Möglichkeit vor, diese als Webformular abzusenden, wenn sie dann entsprechend elektronisch unterschrieben werden können. Die elektronische Unterschrift setzt eine PKI innerhalb des Unternehmens voraus. Alle Anträge können aber auf jeden Fall auch immer schriftlich ausgefüllt und übermittelt werden. Das gesamte Antragswesen der WebFarm- wird auch zum Tracking von Aufträgen und deren Status als so genannte Laufzettel verwendet. Neben der eigentlichen Beauftragung einer Aktion innerhalb des Systembetriebs einer WebFarm-Lokation oder der gesamten WebFarm-Infrastruktur werden mit den Anträgen auch Berechtigungen für die entsprechenden Systeme vergeben.

26.1.1

WebFarm-Auftrag

Grundlage eines WebFarm-Entwurfs ist immer ein bestimmter Server oder Service, für den ein WebFarm-Auftrag erstellt wird. Dieser Auftrag erhält eine eindeutige WebFarm-Auftragsnummer, so dass alle dazugehörigen Vorgänge miteinander verbunden werden können.

297

Sandini Bib 26 Sicherheitsantragswesen und Betriebsübergabeverfahren

Für den beantragten Service können gleichzeitig Installations-, Betriebs- und Beschaffungsaufträge vergeben werden sowie die Definition der Ansprechpartner für die Befüllung, den Test, die Freigabe von Inhalten und die buchhalterische Verantwortung über die Systeme. Diese Ansprechpartner müssen bis auf die für inhaltliche Fragen immer unternehmensintern oder innerhalb gegebener strategischer Partnerschaften liegen. Externe Zulieferer können als Inhaltslieferanten oder Berater eingetragen werden und können die entsprechenden Berechtigungen erhalten. Es ist auf jeden Fall wichtig, dass die Freigabe für inhaltliche Anlieferungen immer unternehmensintern abgewickelt wird. Der WebFarm-Auftrag enthält neben der Beauftragung des eigentlichen Systems auch die Konfiguration des Systems mit allen erforderlichen Komponenten und dazu vorzulegenden Dokumentationen und Lizenzen. Dieser Auftrag kann zusammen mit dem Web Consulting, das in der Organisationsstruktur des WebFarm-Standards näher beschrieben wird, ausgefüllt werden und daher auch als Beratungsgrundlage dienen. Neben der eigentlichen Beantragung und Beauftragung von WebFarmDienstleistungen werden alle Aktionen auf dem Auftrag ausgeführt, so dass ein Tracking der Arbeiten jederzeit möglich ist. Es wird auf diese Weise ein sehr transparentes Betriebsübergabe- und Auftragswesen geschaffen.

26.1.2

Content-Management-Systemanträge

Das Content-Management-System ist, da es sowohl für die Verteilung von Projektsoftware als auch für das dynamische Einstellen jeden Contents auf alle Systeme mit definiertem Redaktionsprozess verwendet wird, ein zentraler Punkt, der über die Inhalte und Funktionalitäten eines in der WebFarmbetriebenen Dienstes klar bestimmt. Content-Pool-Benutzer Jeder Autor innerhalb oder außerhalb des Unternehmens kann Inhalte in den Content-Pool beisteuern, die dann aufgrund des Informationsmodells an verschiedene Stellen von Informationssystemen verteilt werden. Die Verteilung dieser Informationen wird in der Konfiguration des Informationsmodells innerhalb der WebFarm-Infrastruktur festgelegt, während eines Projektablaufs dokumentiert und dann an die Administration bei der Servicekonfiguration (WebFarm-Auftrag) übergeben. Die Berechtigungen für Autoren, in bestimmte Teile des Informationspools Informationen tatsächlich einzustellen, werden separat davon vergeben.

298

Sandini Bib Antragsverfahren

Ein entsprechender Projekt- oder Linienverantwortlicher kann den Zugriff und die Berechtigungen eines Benutzers auf bestimmte Kategorien des Content-Pools (Einstellen, Ändern, Löschen) beantragen. Die WebFarm-Administration richtet die entsprechenden Rechte ein, wonach sich das ContentManagement-System bzw. der beim Autoren ohnehin installierte Client automatisch konfiguriert. Die Beantragung der entsprechenden Rechte für den Autor wird über ein gesondertes Formular dargestellt. Programm- und statischer Content Im Gegensatz zu Inhalten, die über den Content-Pool eingestellt werden, ist für diese Art von Content auf jeden Fall immer ein Redaktionsprozess erforderlich. Hierbei handelt es sich um die Packaging-Verfahren, die vom entsprechenden Benutzer dann eingehalten werden müssen. Der Antrag auf einen entsprechenden Zugang zum Content-Management-System kann von einem Projektverantwortlichen für externe bzw. Linienvorgesetzten für deren Mitarbeiter beantragt werden. Der WebFarm-Betrieb wird diese Berechtigungen vergeben und bei etwaigem Missbrauch den Benutzer bzw. dessen Verantwortlichen zur Rechenschaft ziehen. Redaktionsprozess Der Redaktionsprozess kann nur von internen Mitarbeitern bzw. einem begrenzten Kreis an strategischen Partnern ausgeführt werden. Darum kann hier nur ein Linienvorgesetzter entsprechende Anträge stellen, die dann vom WebFarm-Betrieb in das Informationsmodell bzw. das Content-ManagementSystem im Allgemeinen eingetragen werden. Diese Berechtigungen ermöglichen es einem Mitarbeiter, Inhalte, Programme und andere Zusammenstellungen an Dateien so weit freizugeben, dass sie einerseits öffentlich sichtbar werden, aber auch andererseits eventuell bereits verfügbaren Content ersetzen. Ein Redakteur muss über die Folgen seines Handelns entsprechend aufgeklärt sein und eine Schulung erfahren, in der er auf jeden Fall die Wichtigkeit des Redaktionsprozesses verinnerlichen kann. Weiterhin ist ein Redakteur für den freigegebenen Inhalt verantwortlich. Das bedeutet insbesondere, wenn freigegebener Content fehlerhaft, juristisch oder programmtechnisch falsch ist, also auch wenn freigegebener Content eine Applikation nachweislich beschädigt, ist der Freigeber, nicht der Betrieb für diese Schädigung verantwortlich und wird vom WebFarm-Betrieb auch entsprechend angegangen.

26.1.3

Sicherheitsrelevante Freischaltungen

Projektverantwortliche und Linienverantwortliche, die dem WebFarmBetrieb als Berechtigte mitgeteilt wurden, können auch im Sicherheitsbereich Freischaltungen und die Aktivierung von Diensten beantragen. Insbesondere

299

Sandini Bib 26 Sicherheitsantragswesen und Betriebsübergabeverfahren

gilt dies für PKI-Administration, Firewall-Freischaltungen, Zertifizierung und Aktivierung von Diensten auf einzelnen Servern. Diese Beantragung wird von den jeweils Berechtigten, andere Anträge werden vom WebFarmBetrieb nicht angenommen, an den Betrieb übergeben. Der WebFarm-Betrieb steht in engem Kontakt mit dem CSO (Chief Security Officer) der jeweiligen Lokation und des gesamten Unternehmens, um die Freischaltung auch von diesem abzeichnen zu lassen. Erst nach erfolgter Freigabe durch den Chief Security Officer, der die Gesamtsicherheitsstruktur des Unternehmens über die Grenzen der WebFarm-Infrastruktur und insbesondere über die Grenzen einer Lokation überwacht und dafür verantwortlich zeichnet, dass es ineinander greifende Verfahren und keine konkurrierenden oder gar sich aufhebenden Vorgehensweisen gibt, wird eine Durchführung des Auftrags durch den WebFarm-Betrieb der jeweiligen Lokation in Angriff genommen.

26.2 Betriebsübergabe Der wichtigste Grundsatz für einen hochverfügbaren Systembetrieb auch im Bereich unternehmenskritische Systeme ist die strikte Trennung von Entwicklung und Betrieb und die Zusammenführung von Entwicklung und Betrieb über ein dokumentiertes Verfahren. Dabei muss die Entwicklung bereits durch eine Qualitätsstufe, die so genannten Integrationstests, abgenommen sein, bevor ein Betrieb einer neu entwickelten oder konzipierten Applikation überhaupt angedacht werden kann. Diese Integrationsstufe wird im Kapitel »Integrationstests« beschrieben. Für die Übergaben von Anwendungen und Informationssystemen in den Betrieb der WebFarm-Infrastruktur bzw. einer WebFarm-Lokation wird das oben beschriebene Antragsverfahren mit dem WebFarm-Auftrag als Grundlage für eine Übergabe verwendet. Grundsätzlich gehen in der WebFarm- nur einzelne Dienstleistungen (Services) in Betrieb. Alle anderen Dinge können höchste Änderungen an bereits im Betrieb befindlichen Diensten darstellen. Nach der Qualitätssicherung auf Seiten der Entwicklung bzw. der vorgeschalteten Qualitätsstufe in den Integrationstests führt der Betrieb selbst eine Qualitätskontrolle der angelieferten Teilstücke des zu betreibenden Dienstes durch, die wiederum an die Entwicklung zurückgewiesen werden können. Es ist hierbei Aufgabe der Entwicklung, mit den entsprechenden Verwaltern von Standards und Modellen (Datenhoheit) innerhalb des Unternehmens Klärungen offener Punkte zu treffen. Der WebFarm-Betrieb seinerseits wird lediglich Verletzungen der Standards feststellen.

300

Sandini Bib Betriebsübergabe

Da der Webbetrieb eine sehr schnelle Abwicklung voraussetzt, können solche Standarddiskussionen durch die entsprechenden Bestätigungen innerhalb der hierarchischen Struktur des Unternehmens umgangen werden bzw. zeitweise außer Kraft gesetzt werden, der Betrieb wird hierbei die entsprechenden Standardverantwortlichen informieren, damit auf Dauer eine einvernehmliche Lösung zwischen Projekt- und Standardabteilungen gefunden werden kann. Nach der korrekten Beantragung einer Betriebsübernahme, der ersten Angliederung und der Annahme durch den Betrieb werden Zeitpläne für die Inbetriebnahme gemacht. Aufgrund der engen Entwicklungszyklen im Webbereich ist das Ziel solcher Pläne, innerhalb von zwei Wochen einen gesicherten Betrieb zu starten, wenn die Anlieferungen ohne weitere Beanstandungen sind. Die korrekt ausgefüllten und vor allem unterschriebenen oder zertifizierten Aufträge und Anträge liegen dabei dem Betrieb vor und werden durch alle in den Aufträgen und Anträgen referenzierten Materialien und dann durch die Packages für die Installation selbst ergänzt. Änderungen an bestehenden Betriebsprojekten bedürfen in den meisten Fällen keiner gesonderten Aufträge mehr, aber unterliegen den gleichen ReleaseZyklen und Release-Verfahren wie alle anderen Betriebsübergaben auch.

301

Sandini Bib

Sandini Bib

27

Integrationstests

Um die tatsächlich schnelle Abwicklung von Webprojekten zu gewährleisten, ist die Qualitätssicherung bereits während des Projektes und auch vor der Betriebsübergabe ein entscheidender Faktor. Welche Maßnahmen und Tests durchgeführt werden müssen, um gemäß den WebFarm-Standards eine solche Qualitätssicherung vor der Inbetriebnahme eines neuen Dienstes oder eines neuen Release eines bestehenden Dienstes durchzuführen, wird hier beschrieben.

27.1 Testumgebung Eine Testumgebung, die von der eigentlichen Projektumgebung losgelöst ist, ist der Schlüssel zu einer Qualitätsstufe vor dem eigentlichen Systembetrieb.

27.1.1

Aufbau

Der Aufbau einer Umgebung für den Integrations- oder Verifikations- und Integrationstest sollte der Betriebsumgebung sehr nahe kommen. Es ist offensichtlich aus Kostengründen nie vorstellbar, eine absolut exakte Kopie der Betriebsumgebung mit der gleichen Anzahl an Rechnern und Services herzustellen. Es sollte aber von jedem Typ Rechner mindestens eine Instanz vorhanden sein, und die gesamte Infrastruktur im Netzwerkbereich, also vor allem alle Trennungen von Netzsegmenten, muss auch in der Testumgebung der Betriebsumgebung entsprechen. Dies hat insbesondere Auswirkungen auf Firewalls und deren Nachbildung, denn in einer Testumgebung muss die prinzipielle Firewall-Konstruktion der WebFarm-Lokation sicherlich nicht redundant nachgebildet werden. Gleiches gilt für die Back-End- oder Backoffice-Dienste wie Datenbanken oder Datenfeeds, die ebenfalls mit Testdaten, aber in einer praxisnahen Umgebung versehen sein und der Testumgebung zur Verfügung stehen müssen. Der Aufbau einer Umgebung für den Integrationstest bedeutet mindestens dieses, abgesehen von drei Netzwerksegmenten, die durch Packetfilter und Aplication-Level-Gateway voneinander getrennt sind, und einem Back-EndServer, der möglichst viele Aufgaben des Produktions-Backend simuliert. Ferner müssen in jedem Segment der Testumgebung die entsprechenden Rechner vorhanden sein, um alle möglichen Dienste zu testen. Das bedeutet in einer absoluten Minimalkonfiguration vier Rechner pro Segment.

303

Sandini Bib 27 Integrationstests

Diese Rechner werden über das WebFarm-Jump-Start-Verfahren konfiguriert, und dementsprechend können verschiedenste Setups aus dem WebFarmBetrieb der jeweiligen Lokation nachgestellt werden.

27.1.2

Betriebsunterstützung

Da die Qualitätssicherung nicht durch den Betrieb durchgeführt wird und dennoch eine große Nähe zum eigentlichen Praxisbetrieb für die Früherkennung von Problemen hergestellt werden muss, wird eine gewisse Nähe der Qualitätssicherung und damit der VI-Testumgebung zum Systembetrieb vorausgesetzt. Diese wird nach dem WebFarm-Standard dadurch hergestellt, dass der Systembetrieb den Betrieb und die für die jeweiligen Tests erforderlichen Konfigurationen der Testumgebung übernimmt und auch den Betrieb, also die komplette Überwachung und Alarmierung während der Testphase simuliert, so dass sofort erkannt werden kann, wo eventuelle Konflikte auftreten. Für den Systembetrieb ist die Testumgebung also eine Art WebFarm-Lokation, die mit sehr niedrigen Serviceleveln und einer sehr hohen Konfigurationsfrequenz betrieben wird. Die für die Qualitätssicherung an sich verantwortlichen Mitarbeiter haben neben dem Betrieb die Rechte auf den entsprechenden Systemen und führen zusammen mit den Projektmitarbeitern die entsprechenden Tests durch.

27.1.3

Planung

Die aufgebaute Testumgebung und das für die Qualitätssicherung verantwortliche Personal werden von allen Projekten innerhalb der WebFarm-Infrastruktur bzw. einer WebFarm-Lokation je nach Größe der Gesamtkonstruktion angesprochen. Eine Planung der Vorgehensweisen in der Testumgebung ist daher für eine zeitnahe Realisierung mit vorgegebenen Terminen zwingend notwendig. Für die Testumgebung gelten daher die gleichen Fristen und Antragsverfahren wie für den Systembetrieb, die allerdings flexibler gehandhabt werden können, wenn entsprechend dringliche Abnahmen vorliegen. Aufgrund der Verwendung der WebFarm-Anträge und Aufträge kann aber ein exaktes Tracking der Tests bereits zu Betriebsübergabebedingungen durchgeführt werden, und damit wird die tatsächliche Betriebsübergabe und die Inbetriebnahme von Diensten wesentlich besser planbar und auch zuverlässiger.

304

Sandini Bib Testverfahren

27.2 Testverfahren Nachdem Anwendungen in der Testumgebung installiert wurden, werden diese vom Projekt, das die Anwendung erzeugt hat, und dem Qualitätssicherungsteam einem Testverfahren unterzogen. Dieses Testverfahren untergliedert sich in drei Etappen, die im Folgenden beschrieben werden.

27.2.1

Funktionstest

In allgemeinen Funktionstests werden alle Seiten und Kombinationen der Anwendung durch die Qualitätssicherung in Zusammenarbeit mit dem Projekt durchgesehen. Dabei werden datentechnisch saubere Testfälle durch die Qualitätssicherung erzeugt. Dieser Funktionstest kann auch Anforderungen für weitere Releases der Software generieren. Treten bei der Anwendung im Funktionsteil Probleme auf, werden diese dokumentiert und dem Projekt zur Verfügung gestellt. Ein erneuter Test wird in diesem Fall festgesetzt, und die Testphase wird abgebrochen. Die verwendeten Datenkonstruktionen werden in einem Testprotokoll dokumentiert, um eventuell im Praxisbetrieb auftretende Probleme durch bereits durchgeführte Tests belegen oder deuten zu können.

27.2.2

Lasttests

Der Lasttest wird unter Verwendung von Skripten durchgeführt, die bei normalen Informationsanwendungen standardisiert eine Maximalanzahl gleichzeitiger Benutzer standardisiert simulieren. Bei individuellen Anwendungen werden die Skripte so angepasst, dass sie in der Anwendung auch tatsächliche Aktionen auslösen. Diese Lasttests müssen nicht in C/C++ geschrieben sein, da die Erzeugung der Lasttests ein zeitkritischer Vorgang ist. Das Team der Qualitätssicherung wird Skelette für solche Testskripte vorab entwickeln und mit dem Projektteam gemeinsam anpassen. Die Dokumentation der Lasttests ist eine allgemeine Performance- und Abwicklungsstatistik sowie die exakte Messung der Ablauflogik in Zeiteinheiten bei definierten Benutzerzahlen auf dem System.

305

Sandini Bib 27 Integrationstests

27.2.3

Sicherheitstests

Standardisierte Scan-Mechanismen werden durch das QS-Team eingesetzt, um allgemeine Sicherheitsprobleme aufzufiltern. Auf diese Weise werden grobe Sicherheitsverstöße gefunden. Das Finden eines solchen Sicherheitsproblems hat den Abbruch aller Tests zur Folge und wird direkt an die Projektentwicklung gemeldet. Alle anderen Sicherheitskonstruktionen werden anhand der Dokumentation in Verbindung mit den entsprechenden Testfällen überprüft.

306

Sandini Bib

28

Eskalationsverfahren

28.1 Definition von Klassen und Verfahren Zur Sicherstellung eines bestimmten Servicelevels ist nicht alleine eine zuverlässige Überwachung der Systeme entscheidend, sondern auch ein Eskalationssystem, das es erlaubt, über verschiedene – teils automatische – Stufen Probleme an einen oder mehrere Personen zu delegieren und diese damit in ein »Quality of Servicemanagement« einzubeziehen. Ein typisches Eskalationsverfahren beruht auf den Alarmklassen des Überwachungssystems und definiert feste, im Rahmen von Revisionsuntersuchungen bestätigte Verfahren zur Reaktion und Reaktionsfolge. Zusätzlich werden Änderungsmöglichkeiten für bestimmte Szenerien aufgezeigt. Das folgende Schema zeigt die Klassifikation der Meldungen, die im Rahmen des WebFarm-Standardbetriebs verwendet wird.
 







    



   



   
  




   






    

  












   










Abbildung 28.1: Eskalationsskala für Webfarm-Meldungen

307

Sandini Bib 28 Eskalationsverfahren

Folgende Stufen lassen sich in einem Eskalationssystem definieren: 왘 Status-Analysis

Dies ist der Normalzustand des Eskalationssystems. Das Überwachungssystem prüft ständig den Status der angebundenen Dienste, Systeme und Prozesse und meldet keinen Eskalationsbedarf. 왘 Automatic-Restart

Meldet ein System, ein Service oder ein Prozess bzw. dessen Logüberwachung ein Problem beim Zugriff auf das entsprechende Objekt oder auf dessen Funktionalität, wird das entsprechende Objekt angehalten und neu gestartet. Bei einem Server kann dies ein Reboot sein, bei einem Dienst ein SIGHUP oder ein Stop, Start bzw. Restart. Dieser Alarmlevel kann auch verwendet werden, um auf einer anderen Maschine einen Prozess auszulösen, z.B. um ein Hot-Stand-by zu aktivieren, was vor allem bei NameServern, WWW-Servern usw. sinnvoll erscheint. 왘 E-Mail-Alert

Auch diese Eskalationsstufe hat mehrere eigentliche Level. Zunächst können einem Administrator oder mehreren Administratoren und Supportmitarbeitern bei eingehenden Alarmierungen und erfolglosem AutomaticRestart entsprechende Meldungen per E-Mail zugestellt werden. Die zweite Variante des E-Mail-Alert ist für Warnungen und zur Informationserfassung geeignet, da hier so genannte Digests, also Listen von angefallenen Warnungen und Informationen, zu einem fest definierten Zeitpunkt an Administratoren und Supportmitarbeitern übersendet werden, um eventuelle Früherkennung von Problemen zu unterstützen und den Informationsfluss zu gewährleisten. Es sollte beachtet werden, das daraus kein Echtzeitsystem mit komfortabler Handhabung (z.B. 600 E-Mails in einer Minute) zu produzieren. 왘 SMS-Alert

Diese Alarmstufe ist aufgrund der bislang existierenden Unzuverlässigkeit der SMS-Netzwerke der Mobilfunkbetreiber in Deutschland standardmäßig deaktiviert. Sie kann dazu verwendet werden, Alarme und Meldungen auf ein Mobiltelefon oder einen Pager umzuleiten, um entweder das Supportteam zu aktivieren oder einen Administrator über den Systemzustand (z.B. Plattenplatz) informiert zu halten. Das SMS-Verfahren funktioniert hierbei ebenso wie das Versenden von E-Mails, nur dass eine SMS weniger Zeichen, also auch weniger Informationen auf einmal fassen kann.

308

Sandini Bib WebFarm-Verfahren

왘 Voice-Alert

Der wohl wichtigste Eskalationsschritt ist der Voice-Alarm. Hierbei werden Administratoren und Supportmitarbeiter auf normalen oder mobilen Telefonen angerufen und über eine Sprachsynthese über anfallende Probleme informiert. Das System gibt hierbei die Domain, in der das Problem aufgetreten ist, den Server, falls vorhanden, den Service und die Art des Problems durch. Das Voice-Alerting-System unterstützt zwei Arten von Alarmen, die auch sequentiell oder auch durch einen weiteren Eskalationsschritt hin getrennt aktiviert werden können. In der ersten Stufe ruft das System exakt einen Mitarbeiter an, der sich im Dienstplan befindet oder welcher der Systemverantwortliche ist. In der zweiten Eskalationsstufe nach einem gewissen Time-out oder einem Notfallalarm werden alle verfügbaren Support-Mitarbeiter gleichzeitig aktiviert. Ein Eskalationsverfahren setzt voraus, dass für jeden Alarm der verschiedenen Alarmstufen ein bestimmtes Eskalationsverhalten definiert ist oder dass das Standardverhalten des Systems für den entsprechenden Alarm korrekt greift. Beispiele für typische Eskalationsverfahren liefert unten stehende Darstellung.

Abbildung 28.2: Eskalationsverfahren

28.2 WebFarm-Verfahren Das WebFarm-Betriebskonzept teilt alle über das WebFarm-Überwachungsmodell eingegangenen Informationen in die beschriebenen Klassen ein. Hierbei werden gemäß der WebFarm-Servicelevel Verfahrensweisen definiert.

309

Sandini Bib 28 Eskalationsverfahren

28.2.1

Alarmierung

Es wird für jedes Ereignis aus der Klasseneinteilung auf jeden Fall ein E-MailAlert generiert. Ist dieser nicht innerhalb von fünf Minuten erfolgreich beendet, so erweitert sich das Alarmverfahren auf den Anruf eines zuständigen Administrators. Hat dieser Anruf weiterhin keinen Einfluss auf den Systemstatus oder den Überwachungsstatus des alarmierten Dienstes, so wird zunächst die Gruppe 1 an Administratoren (diensthabend) und danach im weiteren 10-Minuten-Abstand die Gruppe 2 (alle Administratoren) benachrichtigt. Alle Gruppe-2-Alerts werden gesondert protokolliert und in den regelmäßigen Planungstreffen der Systemadministration besprochen.

28.3 Überwachungsstufen Die Systeme werden von den Administratoren einer WebFarm-Lokation mit bestimmten Alarmstufen versehen, die auch die Eskalationsstufe bezeichnen. Das Überwachungsintervall zur Festsetzung der jeweiligen Stufe des Systems wird im Normalfall einer WebFarm-Umgebung mit 30 Sekunden für den Statusreport des Überwachungsagenten an das Basissystem des WebFarmAdministrationsservers festgelegt. Die folgende Tabelle zeigt die einzelnen Status und deren zugehörige Beschreibung sowie die darauf erfolgenden Reaktionen. Status

Beschreibung

Off

Das System ist in die Überwachung eingetragen, wurde aber von der WebFarm-Administration als abgeschaltet gekennzeichnet. Alle Meldungen des Überwachungsagenten für dieses System werden ignoriert ebenso wie alle Zeitüberschreitungen für Funktionen des Überwachungssystems. Es erfolgt keinerlei Alarmierung. Dieser Status wird für neue Systeme eingetragen oder für Systeme, die permanent aus dem Betrieb entfernt werden.

Off ok

Dieser Status wird von der WebFarm-Administration in das Überwachungssystem eingetragen, wenn ein System beim Starten der Überwachungszentrale keine Reaktion zeigt und einen Alarmzyklus beginnt, dann aber als ausgeschaltet erkannt wird und dies ein erwarteter Zustand ist.

Tab. 28.1: Übersicht Überwachungsstufen

310

Sandini Bib Überwachungsstufen

Status

Beschreibung

Alarm ok

Bei Tests und anderen Gegebenheiten, z.B. bekannten Problemen der Netzinfrastruktur, werden mit diesem Status Systeme aus dem Eskalationsverfahren entfernt. Die Meldungen des Systems gehen weiterhin ins Reporting ein, es werden aber keine Administrationseingriffe angefordert.

Ok

Das System funktioniert gemäß der Überwachungen des Überwachungsagenten einwandfrei.

Down

Das System hat innerhalb des letzten Überwachungszyklus keinen Status geliefert und wird darum als nicht verfügbar erkannt. Bei diesem Status wird noch kein Alarm ausgelöst, da es sich um Netzprobleme handeln kann. Dieser Status ist aber für die Verfügbarkeitsbetrachtung bei tatsächlichen Ausfällen relevant und dient den Administratoren als Vorwarnung.

Alarm

Alarm 1

Das System hat mehrmals keinen Status in das Überwachungssystem oder einen Alarmstatus an das Überwachungssystem geliefert. Dieser Alarmstatus wird zur Anzeige in den Frontends der Administratoren gebracht.

Alarm 2

Als nächste Stufe wird der E-Mail-Alarm ausgelöst, der allen Administratoren, die sich mit der WebFarm-Betriebshierarchie unter diesem Überwachungsknoten beschäftigen, eine entsprechende Alarm-E-Mail schickt.

Alarm 3

Der E-Mail-Alarm zeigte keine Wirkung (Alarm ok, wenn ein Administrator am System die Arbeit begonnen hätte), und darum wird ein verantwortlicher Administrator per Telefon benachrichtigt. (SMS ist als Eskalationsstufe nicht aktiviert, weil die Zeitverzögerungen bei der SMS-Übermittlung nicht vorhersagbar sind.)

Alarm 4

Nach weiteren eingehenden Alarmmeldungen werden alle Administratoren der Gruppe 1 (diensthabend) per Telefon benachrichtigt.

Alarm 5

Nach weiteren eingehenden Alarmmeldungen werden alle Administratoren der Gruppe 2 (für diesen Bereich der WebFarm-Betriebshierarchie zuständig) benachrichtigt.

Tab. 28.1: Übersicht Überwachungsstufen

311

Sandini Bib 28 Eskalationsverfahren

28.4 Zusatzdienste und Pre-Altering Alarme werden auch ausgelöst, wenn im Überwachungssystem bestimmte Schwellwerte in der Auslastung der Systeme bzw. deren Ressourcen überschritten werden oder bestimmte Logmeldungen auftreten, die nicht auf einen Ausfall schließen lassen, aber als Vorwarnung auf zukünftige Probleme gedeutet werden können oder für das Reporting des Systemzustands interessant sind. Insbesondere werden für alle Systeme, wenn nicht anders im Service-LevelAgreement für diese Systemgruppe festgelegt, nach WebFarm-Standard folgende Faktoren als Warnungen betrachtet:

Kriterium

Schwell wert

Systemlast

2

Es wird eine Warnung an die WebFarm-Administration gesendet, damit bei häufigeren Warnungen dieser Art eine Systemplanung mit mehr Kapazität berücksichtigt werden kann.

5

Es wird eine Warnung mit dem Systemlastverlauf an die Administration gesendet, damit eine entsprechende Hardwareerweiterung der Fachabteilung vorgeschlagen werden kann.

10

Es wird ein Alarm an die Systemadministration gesendet, weil das System anzunehmenderweise keine akzeptablen Antwortzeiten liefert.

50%

Wenn das System als Datenbanksystem definiert ist, wird eine Warnung an die Administration versendet, um die Planung von neuem Plattenplatz mit der Fachabteilung zu beginnen.

85%

Es wird eine Warnung an die Systemadministration versendet, um neuen Plattenplatz zu beschaffen bzw. verfügbare Back-up-Ressourcen zu verwenden.

90%

Es wird eine Warnung an die Systemadministration versendet (im DB-Fall ein Alarm), damit sofort neuer Plattenplatz verfügbar gemacht werden kann bzw. beschafft wird.

98%

Es wird ein Alarm an die Systemadministration versendet, da ein weiterer Verbrauch zu Problemen bei allen Diensten des Systems bis hin zum Absturz mit Datenverlust führen kann.

PlattenKapazität

Beschreibung

Tab. 28.2: Übersicht Warnfaktoren

312

Sandini Bib Patch-Verfahren

28.5 Patch-Verfahren Patching von Software ist immer ein wichtiger Bestandteil eines jeden Systembetriebs. Auch wenn im Rahmen der WebFarm-Systeme der Grundsatz gelten sollte »never change a running system«, ist doch aufgrund von Sicherheitsmaßnahmen eine sofortige Systemänderung notwendig bzw. im Rahmen der kurzen Entwicklungszyklen im Bereich der Webanwendungen ein Update von Primärsoftware auf neue Versionen erforderlich. Im Folgenden wird beschrieben, wie nach dem WebFarm-Standard Patches installiert werden, bzw. wann sie überhaupt installiert werden und wie weit dieser Prozess automatisiert werden kann.

28.6 Patch-Verwendung Betriebssysteme, Primärsoftware und Anwendungen sind voneinander streng zu unterscheiden. Für alle Softwarekomponenten gilt auf jeden Fall, dass Patches, Fixes und Servicepacks nicht einfach sofort bei einfacher Verfügbarkeit eingespielt werden. Solche Softwareupdates müssen zunächst in einer vom Betrieb unabhängigen Umgebung getestet und dann klassifiziert werden. Updates, die eine Verbesserung des Sicherheitsverhaltens bewirken oder bekannte Sicherheitsprobleme lösen, werden sofort nach Freigabe des Updates nach erfolgreichem Test auf dem in Frage kommenden System installiert. Updates, die lediglich die Funktionalität von Diensten erweitern oder korrigieren, aber nicht auf deren Sicherheitsauswirkungen getestet wurden, werden nur bei definierten Benutzeranforderungen installiert, da diese dann wieder ausführliche Tests der Sicherheitsumgebung bzw. der Systemsicherheit eines so behandelten Systems nach sich ziehen. Ansonsten wird im Betriebssystemmanagement jeweils die abgenommene und getestete Version so lange erhalten, bis entsprechende Anforderungen bestehen. Sicherheitsupdates werden so schnell wie möglich eingeführt. Primärsoftware wird in der jeweils aktuellen freigegebenen Version auf den Systemen installiert und so gehalten. Bei Primärsoftware handelt es sich um Software, die von Anwendungen benötigt wird oder die für Anwendungen die Grundlage schafft, also z.B. Packetfiltering-Software, WWW-Server, Proxy-Server und dergleichen. Die Freigabekriterien der Primärsoftware orientieren sich an globalen Verfahren, um gegebene Sicherheitsbereiche und Revisionsanforderungen nicht zu verletzen. Sicherheitsupdates werden auch bei Primärsoftware sofort nach einem erfolgreichen Sicherheitstest und ohne weitere Softwarefreigabe installiert.

313

Sandini Bib 28 Eskalationsverfahren

Anwendungen werden in diesem Zusammenhang des Systembetriebs als Individualentwicklungen bezeichnet. Diese werden nach Benutzeranforderungen auf neue Versionen und Stände gebracht. Sicherheitsupdates werden auch hier sofort nach einem entsprechenden Test ohne weitere Freigabeverfahren installiert. Anwendungen setzen allerdings vor der Installation eine Change-History voraus. Sollen Anwendungen in sicheren Bereichen oder im Rahmen einer Sicherheitskonstruktion installiert oder verändert werden, muss der Source-Code bis zu einer sinnvoll verarbeitbaren Größe der Anwendung (kleine Utilities, CGIs, …) in einem bestimmten Zeitraum vor dem Installationstermin der Systemadministration zur Überprüfung bereit gestellt werden. Anwendungen, die im Rahmen von Application-Servern, also nicht als Teil einer Sicherheitskonstruktion, installiert werden, unterliegen diesen Bestimmungen nicht.

28.7 Patch-Verteilung Die Verteilung von Patches innerhalb der WebFarm-Betriebsinfrastruktur ist ein weitgehend automatisierter Prozess. Es werden immer alle verfügbaren Patches auf alle Systeme gleicher Basisfunktion verteilt, auch wenn diese später nicht verwendet werden. So kann immer sichergestellt werden, dass entsprechende Patch-Anforderungen lokal auf einem System sehr schnell erfüllt werden können. Die Patch-Verteilung funktioniert nach einem einfachen Prozess. Wird irgendwo in einer WebFarm-Infrastruktur eine Patch-CD oder ein Patch-Cluster verwendet, so wird dieser nicht an einem bestimmten System, sondern am Administrationsserver eingesetzt. Auf dem WebFarm-Administrationsserver wird mit dem entsprechenden Patch-Source als Angabe ein Patch-SystemComponent-Skript aufgerufen, das jedes WebFarm-System untersucht, auf welchen Patch-Status es ist, und alle erforderlichen Patches automatisch auf das System überträgt. Der Aufruf des Patch-Skripts erfolgt rekursiv für alle Hierarchiestufen der WebFarm-Administrationsinfrastruktur. So ist sichergestellt, dass ein einmal in der WebFarm- getesteter und eingesetzter Patch überall verfügbar ist. Die Verteilung der Patches erfolgt automatisch, die Installation nicht.

28.8 Außerordentliche Patches In einigen Fällen benötigen Entwicklungen von Fachabteilungen Patch-Level oder Patches einer Software, die für den WebFarm-Betrieb noch nicht oder absichtlich nicht (z.B. wegen bekannter Sicherheitsprobleme) zugelassen ist.

314

Sandini Bib Servicelevel-Definitionen

Da es sich um Betrieb im Webumfeld handelt, der auf die Anforderungen von Fachabteilungen wesentlich flexibler eingehen muss, als dies im normalen RZ-Betrieb der Fall ist, kann ein Patch dann individuell auf einem System oder einer Anwendung eingespielt werden, wenn die entsprechende Fachabteilung dies schriftlich beantragt und die Verantwortung für eventuelle Sicherheitsprobleme übernimmt. Ein getesteter Patch kann dann eingespielt werden, wenn die Fachabteilung die entsprechende Anforderung stellt.

28.9 Servicelevel-Definitionen Ein geregelter Systembetrieb muss gewissen Kontrollen unterliegen. Diese Kontrollen werden oft am Grad der Dienstleistung orientiert. Um den gewünschten Grad der Dienstleistung festzulegen, werden für betreute Systeme Servicelevel-Agreements zwischen den auftraggebenden Fachabteilungen und dem Systembetrieb bzw. den Betriebspartnern vereinbart. Im Folgenden wird dargestellt, wie solche Servicelevel-Agreements aufgebaut sein können. Als wichtigstes Kriterium bei der Definition der Servicelevel ist der Ausfall einer angebotenen Dienstleistung zu werten. Hierbei wird nicht der Ausfall eines einzelnen Rechners betrachtet, sondern der Ausfall einer angebotenen Dienstleistung eines Serviceclusters, wie er im WebFarmStandard mit mindestens einer Mastermaschine und einer Backup-Maschine festgelegt ist. Die Servicelevel befassen sich nicht mit den sonstigen Tätigkeiten des Betriebs, wie z.B. der Fehlerfrüherkennung, sondern nur mit den Dienstleistungen, wie sie sich in Richtung der Benutzer der Dienstleistungen darstellen. Grundsätzlich gibt es zwei Herangehensweisen an die Servicethematik. Es kann einerseits eine garantierte Verfügbarkeit der Systeme vereinbart werden, die dann für den Betrieb verbindlich zu halten ist bzw. bei Nichteinhaltung zu Konventionalstrafen führt; andererseits kann die Reaktionszeit betrachtet werden, die der Betrieb hat, um auf ein bestehendes Problem zu reagieren, wobei dies nicht bedeuten kann, dass die Reaktionszeit eingehalten ist, wenn der Systembetrieb innerhalb der vereinbarten Zeit das Problem registriert; es muss vielmehr innerhalb der vereinbarten Reaktionszeit ein Administrator mit der Behebung des Problems gemäß der Leistungsbeschreibung beginnen. Beide Arten der Servicelevel-Definition können innerhalb des Systembetriebs nach dem WebFarm-Standard angewendet werden.

315

Sandini Bib 28 Eskalationsverfahren

28.10 Servicelevel nach Dienstverfügbarkeit Die Servicelevel-Definition nach Dienstverfügbarkeit hat den eindeutigen Vorteil, dass keine weitere technische Betrachtung vorgenommen werden muss, sondern rein mit einer garantierten Verfügbarkeit von Systemen geplant werden kann. Dies ist ein sehr wirtschaftlich orientierter Ansatz für Servicelevels, und dieser geht wenig auf den technischen Hintergrund von auftretenden Problemen ein. Aufgrund definierter garantierter Verfügbarkeiten kann es durchaus notwendig sein, dass ein komplettes Ausweichrechenzentrum geschaffen werden muss oder ähnliche Maßnamen, die entsprechend finanziell aufwändige Lösungen mit sich bringen, umgesetzt werden müssen.

28.10.1 Verfügbarkeit und Konventionalstrafen Die Verfügbarkeit der in der WebFarm-Lokation betriebenen Systeme wird mindestens pro Maschinenpaar ermittelt und zur Berechnung der Konventionalstrafe herangezogen. Mindestens pro Maschinenpaar heißt, Rechner und mindestens ein Backup-Rechner bilden eine Einheit. Die Gesamtverfügbarkeit wird zum Monatsultimo errechnet. Die Ausfallzeit beginnt mit dem Störungsbeginn, das heißt dem Ausfall eines Maschinenpaars. Störungsbeginn ist der Zeitpunkt, zu welchem eine Störung automatisch oder manuell dem WebFarm-Betrieb gemeldet wird. Die Ausfallzeit endet mit der erfolgreichen Inbetriebnahme des Maschinenpaars. Hiermit ist gemeint, dass mindestens ein Rechner des Tupels den Dienst wieder darstellt. Der Zeitaufwand für Wartung zählt nicht als Ausfallzeit, sofern er in der Servicelevel-2-Zeit stattfindet. Der Zeitraum des Servicelevels 1 ist an Werktagen von 8 bis 18 Uhr Ortszeit festgelegt, alle anderen Zeiträume werden als Servicelevel 2 betrachtet. Die Verfügbarkeit jedes Dienstes auf einem Maschinenpaar muss größer als 98% pro Monat sein. Dabei darf ein Ausfall jedoch nicht länger als zwei Stunden ohne Unterbrechung pro Ausfall sein. Ist die Verfügbarkeit geringer als 98%, das heißt, die Ausfallzeit ist im Berechnungsmonat zu hoch, wird die Regelung für Konventionalstrafen angewendet. Rechenmethode Die Verfügbarkeit der Systeme wird anhand der Ausfallzeit der Maschinenpaare des WebFarm-Betriebs ermittelt. Im Falle des Ausfalls eines Maschinenpaars steht der Service dieser Maschinen nicht zur Verfügung.

316

Sandini Bib Servicelevel nach Dienstverfügbarkeit

Formel Die Berechnung erfolgt nach der hier angegebenen Methode.

Vges


AM   *100%  1   SL1* At 

Mit Vges

Gesamtverfügbarkeit

AM

Ausfallzeit in Stunden des Berechnungsmonats

SL1

Zeitfenster des Servicelevels 1 in Stunden

At

Arbeitstage des Berechnungsmonats

Rechenbeispiele Um die Berechnung praktisch darzustellen, sind hier zwei

Beispiele aufgeführt. Gemeinsam ist der Zeitraum des Servicelevels 1 von 7 bis 19 Uhr und die Zahl der Arbeitstage von 21 im Berechnungsmonat. Beispiel 1: Verfügbarkeit im Servicelevel

In dieser Berechnung wird die Gesamtausfallzeit im Berechnungsmonat auf drei Stunden angenommen. Aus der Berechnung ergibt sich dann eine Gesamtverfügbarkeit von 98,81%. Der Servicelevel ist damit erfüllt. Vges


3h    *100% 1    12h * 21

Beispiel 2: Verfügbarkeit nicht im Servicelevel

In dieser Berechnung wird die Gesamtausfallzeit im Berechnungsmonat auf sechs Stunden angenommen. Aus der Berechnung ergibt sich dann eine Gesamtverfügbarkeit von 97,62%. Der Servicelevel ist damit nicht erfüllt. Die vereinbarte Pönalregelung findet dann ihre Anwendung. Vges


6h  1   *100%    12h * 21

Konventionalstrafe Beträgt die Gesamtverfügbarkeit eines Rechnerpaars im Berechnungsmonat weniger als 98%, oder wurde die maximale Ausfallzeit pro Ausfall überschritten, wird dem WebFarm-Systembetrieb von der auftraggebenden Fachabteilung das Entgelt für den Systembetrieb nach folgender Regelung gekürzt.

317

Sandini Bib 28 Eskalationsverfahren

Für jeden angefangenen Prozentpunkt unter 98% wird der Monatsbetrag für das Rechnerpaar um 5% gekürzt. Für jeden angefangenen Prozentpunkt unter 95% wird der Monatsbetrag für das Rechnerpaar zusätzlich um 10% gekürzt. Ferner wird für jeden Ausfall, der die maximale Ausfallzeit pro Ausfall überschreitet, der Monatsbetrag um 10% gekürzt. Die Reduktion wird jedoch auf 30% des Gesamtmonatsbetrags für das Rechnerpaar begrenzt. Eskalation bei Nichteinhaltung des Servicelevels Bei Nichteinhaltung der Servicelevels hat der WebFarm-Systembetrieb das Problem gemäß folgender Tabelle bei der jeweils auftraggebenden Fachabteilung anzuzeigen. Nichteinhaltung des Servicelevels

Bericht an:

2h

Leiter der Systemtechnik

4h

zusätzlich Leiter des Systembetriebs

6h

zusätzlich IT-Leiter

Tab. 28.3: Übersicht Berichtsabgabe an Fachabteilung

28.11 Servicelevel nach Reaktionszeit Es handelt sich hierbei um das technischere Verfahren, das weniger Planungssicherheit bietet, aber sich an den tatsächlichen technischen Möglichkeiten einer vorgegebenen Umgebung orientiert und damit nicht wie das Verfahren nach Gesamtverfügbarkeit die Umgebung grundlegend durch Anforderungen beeinflusst.

28.11.1 Reaktionszeiten für den gesamten Betrieb Für alle vertraglich vereinbarten und zur WebFarm-Lokation gehörenden Komponenten wird vom WebFarm-Systembetrieb ein ausfallsicherer, 24-stündiger Dauerbetrieb der Hard- und Software an allen Tagen des Jahres gewährleistet. Auftretende Störungen werden vom WebFarm-Systembetrieb innerhalb der in den Servicelevels 1 und 2 genannten Zeiten beseitigt. Als Störung wird der Ausfall einer Komponente in einer WebFarm-Lokation bezeichnet. Für die Hauptbetriebszeit von 8 Uhr bis 18 Uhr Ortszeit sind die Leistungen gemäß Servicelevel 1 zu erbringen, in der übrigen Nebenbetriebszeit gemäß Servicelevel 2. Die genannten Zeiten werden gerechnet ab Störungsbeginn.

318

Sandini Bib Servicelevel nach Reaktionszeit

Servicelevel-Definition Vom WebFarmSystembetrieb zu erbringende Leistung

Qualität

Servicelevel 1

Servicelevel 2

Messpunkt

bei Softwareausfall

Reaktionszeit/ Behebungsbeginn

innerhalb von 10 Minuten

innerhalb von 35 Minuten

Protokolle

bei Hardwareausfall

Reaktionszeit/ Behebungsbeginn

innerhalb von 10 Minuten

innerhalb von 35 Minuten

Protokolle

Benachrichtigung

Dauer, bis zu der sie erfolgt ist. Umfang der gegebenen Fehlerbeschreibung

Die verantwortliche Stelle bei der auftraggebenden Fachabteilung, sowie die Benutzerservice-Eskalation sind sofort nach der Klassifizierung des Fehlers über Art und Dauer der Störung zu unterrichten; das Störungsende ist diesen Stellen ebenfalls mitzuteilen.

Die Benutzer- Zeitpunkt service-Eskala- des Calltions-Erreich- Eingangs barkeit ist zu informieren, wenn das vereinbarte SL nicht erreicht wird.

Tab. 28.4: Übersicht Servicelevel

319

Sandini Bib 28 Eskalationsverfahren

Vom WebFarmSystembetrieb zu erbringende Leistung

Qualität

Servicelevel 1

Servicelevel 2

Messpunkt

Störungsannahme

Erreichbarkeit

Der WebFarm-Systembetrieb teilt der auftraggebenden Fachabteilung zwei Rufnummern mit. Unter einer dieser Rufnummern ist der WebFarmSystembetrieb innerhalb des Zeitraums von 15 Minuten für die auftraggebende Fachabteilung erreichbar, um Störungsmeldungen entgegenzunehmen.

Wartung, Installation, Test

Einfluss auf Betriebszeiten

Diese Arbeiten sind, sofern Protokolle nicht im Einzelfall ausdrücklich mit der auftraggebenden Fachabteilung vereinbart, ausschließlich in der Nebenbetriebszeit zu erledigen.

Zeitpunkt der CallEingangsprotokolle, Zeitstempel des Mailsystems

Tab. 28.4: Übersicht Servicelevel

Es wird eine 24-Std./365-Tage-Erreichbarkeit vereinbart, da das Web im GAN und das Internet in allen Zeitzonen der Welt erreichbar sein muss. Reaktionszeit/Behebungsbeginn ist hierbei der Beginn der Arbeiten nach Störungsbeginn. Die auftraggebenden Fachabteilung teilt dem WebFarm-Systembetrieb detailliert in regelmäßigen Abständen, spätestens jedoch bei Veränderungen mit, unter welchen Rufnummern die jeweils bei der auftraggebenden Fachabteilung liegende verantwortliche Stelle für einen Rechner oder Dienst erreichbar ist. Konventionalstrafen Bei Nichteinhaltung der vereinbarten Servicelevel ist die auftraggebenden Fachabteilung berechtigt, das mit dem WebFarm-Systembetrieb vereinbarte Entgelt für diese Leistungen gemäß nachfolgender Tabelle zu kürzen:

320

Sandini Bib Servicelevel nach Reaktionszeit

Nichteinhaltung SLA

Abzug in Prozent

einmalig innerhalb von 30 Kalendertagen, wenn Nichteinhaltung größer 100%

0,5% auf den Monatsbetrag der Maschine

2. bis 6. Nichteinhaltungen, unabhängig von der Dauer der erstmaligen Nichteinhaltung (innerhalb von 30 Kalendertagen)

zusätzlich 0,5% auf den Monatsbetrag der Maschine

ab der insgesamt 7. Nichteinhaltung

1% gerechnet auf das Jahresvolumen der Maschine

ab der 8. Nichteinhaltung und jede weitere

weitere 1% des Jahresvolumens der Maschine

Tab. 28.5: Übersicht Konventionalstrafen

28.11.2 Kostentransparenz Ein wesentlicher Vorteil des Systembetriebs nach dem WebFarm-Standard und der eigentlichen Idee des WebFarm-Konzepts ist es, eine Art Massenfertigung von Standardumgebungen und Standarddiensten zu schaffen, die dann in individuellen Ausprägungen eingesetzt werden. Durch dieses Vorgehen ist auch eine standardisierte Preisermittlung für den kompletten Systembetrieb eines Systems bzw. mehrerer zusammengehörender Systeme möglich. Es ist also für jedes Projekt, das auf Webbasis eine Anwendung schafft, von vornherein ersichtlich, wie sich die Betriebskosten des Projekts in Zukunft verhalten werden. Dies ist vor allem für die Planung einer kompletten E-Commerce- und Webstrategie dringend erforderlich, da es aus vielen IT-Projekten und entwickelten Umgebungen bekannt ist, dass die versteckten Kosten im Systembetrieb liegen und nicht einschätzbar sind. Der WebFarm-Standard bietet über ein Gebührenmodell eben diese geforderte Planbarkeit von Betriebskosten. Im Folgenden wird beispielhaft eine solche Gebührentabelle dargestellt, die einzelne Dienstleistungen mit Preisen versieht. Die genaue Ermittlung der Preise und der erforderlichen Dienstleistungen ist selbstverständlich erst nach Ermittlung der tatsächlichen Infrastruktur der jeweiligen WebFarm-möglich. Das im Folgenden präsentierte Beispiel gibt allerdings einen guten Anhaltspunkt für die entstehenden Kosten. Da es oft schwierig ist, bei einer komplettinternen Betriebsstruktur derart definierte Preise wirtschaftlich zu behandeln, bietet sich auch ein Outsourcing an.

321

Sandini Bib

Sandini Bib

IV Organisation

Sandini Bib

Sandini Bib

29

WebConsultingProjekte

Der WebFarm-Standard greift von der reinen technischen Standardisierung der Infrastruktur, der möglichen Entwicklungen und des Systembetriebs auch in die Organisationsstruktur ein. Es ist offensichtlich, dass das gesamte Konzept des WebFarm-Standards auf einem sehr guten IT-Wissen basiert und dabei den Gedanken der effizienten Wiederverwendung bestehender Technologien verfolgt, da sich nur auf diese Weise ein profitabler Einsatz der Internet-Technologien auf Dauer umsetzen lässt. Der WebFarm-Standard befindet sich auf einem technischen Niveau, das für fachliche Anforderungen, die letztendlich umgesetzt werden müssen, den Rahmen vorgibt. Da nicht jeder Experte die gesamte Technologie der WebFarm-Umgebung verstehen und im Detail in die Projekte einbringen kann, sieht das WebFarm-Organisationskonzept die Schaffung einer internen Gruppe – das WebFarm-Consulting – vor, die als Schnittstelle zwischen den fachlichen Anforderungen einzelner Projekte und der Umsetzung, der Integration in die Infrastruktur und der Übergabe in den Systembetrieb der WebFarm-Lokationen steht. Im Folgenden werden der Aufbau der Gruppe sowie die einzelnen Dienstleistungen, die das WebFarm-WebConsulting bietet, beschrieben.

29.1 Leistungsübersicht Das WebConsulting des WebFarm-Standards ist die Schnittstelle zwischen den Fachabteilungen bzw. Töchtern und den internen Abteilungen oder strategischen Outsourcing-Partnern für den Betrieb und die Entwicklung bzw. Weiterentwicklung von Webanwendungen bzw. E-Commerce-Anwendungen, Dienstleistungen und Entwicklungen im Bereich der Neuen Medien und Technologien. Durch WebFarm-WebConsulting wird eine eigene Schnittstelle zu internen und externen Leistungen geschaffen, werden die Abhängigkeitsverhältnisse verbessert. Mit dem Wissen des WebFarm-WebConsulting wird den Fachabteilungen ein Service geboten, der durch individuelle Auftragserteilung nicht zu erreichen ist. Das WebFarm-WebConsulting ist für die konzernweite Einführung, Betreuung und Entwicklung von neuen Technologien verantwortlich. Durch das schlanke Personalkonzept wird eine profitable und flexible Einheit geschaffen, die den »Focus on Business« für das Kerngeschäft unterstützt und trotzdem das interne Handling von Technologieentscheidungen und Technologieentwicklungen bietet.

325

Sandini Bib 29 WebConsulting-Projekte

Die Idee, das Auftragswesen für Webtechnologie zu bündeln, muss mit einem gewissen Abstand zum reinen Tagesgeschäft durchgeführt werden. Zusätzlich muss ein moderner Ansatz zu allen Feldern der IT in einer solchen Schnittstelleneinheit gewählt werden. Dieser Ansatz wird momentan nur sehr selten in der komplexen internen Struktur verfolgt.

Abbildung 29.1: Leistungsübersicht

29.1.1

Struktur und Aufgabenverteilung

Abbildung 29.2: Struktur und Aufgabenverteilung

Ein schlankes Personalkonzept ist für eine Schnittstelle, die das WebFarmWebConsulting bilden soll, Voraussetzung. Trotzdem müssen entsprechend technisch versierte und mit dem eigentlichen internen Kerngeschäft vertraute Personen eingesetzt werden. Für die vier vorgeschlagenen Teams ist maximal jeweils ein Leiter mit zwei Mitarbeitern vorgesehen; in vielen Fällen kann ein Team aber auch mit einer einzigen Person besetzt sein. Die Aufgaben der einzelnen Gruppen des WebFarm-WebConsultings werden in den folgenden Abschnitten verdeutlicht.

326

Sandini Bib Leistungsübersicht

29.1.2

Information-Service

Aufgabe des Information-Service ist es, die allgemeinen Informationssysteme zu warten, die als Basis für Projekte verwendet werden können. Hierzu gehören alle nach dem WebFarm-Standard definierten organisatorischen Maßnahmen von Tracking bis hin zur Projektdokumentation. Information-Services können von den Auftrag gebenden Fachabteilungen herangezogen werden, um ein Projekt mit entsprechenden Werkzeugen zu versorgen und die Anbindung des Projektes umzusetzen. Weiterhin sind Information-Services für die fachliche Koordination der WebFarm-Infrastruktur, z.B. die Aufnahme neuer Anwendungen bzw. neuer Infrastruktur-dienstleistungen, die für Fachanforderungen benötigt werden, und deren Betriebskontrolle verantwortlich. Hierbei bilden Information-Services die Schnittstelle zwischen den Umsetzungen des WebFarm-Standards und den Auftrag gebenden Fachabteilungen, die nicht das technische Detailwissen benötigen.

29.1.3

Network-Services

Network-Services bilden das Gegenstück zu Information-Services auf der Infrastruktur- und Technikseite. Hier werden die Sicherheitskomponenten und Zugriffsstrukturen der WebFarm-Lokationen für die Fachabteilungen transparent verwaltet, die Anforderungen der Fachabteilungen koordiniert und zusammen mit den technisch zuständigen Mitarbeitern in Umsetzung gegeben. Die Aufteilung der Dienstleistung zwischen der fachlichen Ebene der Information-Services und der Network-Services liegt in den unterschiedlichen Anforderungen an die Mitarbeiter begründet. Innerhalb der Information-Services muss mehr Know-how über interne Prozesse und innerhalb der Network-Services mehr Know-how über die technischen Gegebenheiten und Voraussetzungen vorhanden sein.

29.1.4

Information-Management

Das Information-Management ist eine zentrale Kontrolleinheit bzw. Verwaltungseinheit für das Informationsmodell des Unternehmens. Das Information-Modelling beschreibt den Content-Pool des Unternehmens und stellt so die Basis für die effiziente Wiederverwendung von Wissen dar. Das Information-Management innerhalb des WebFarm-WebConsulting hat eine sehr zentrale Rolle inne, da hier Projekte vorhandene Informationen erhalten können bzw. diese in die Projekte integrieren und neue Informationsstrukturen in das Informationsmodell einfügen lassen können. Durch diese Verwaltungsfunktion des WebFarm-WebConsulting wird eine ständige Weiterentwicklung und konsequente Pflege des zu Beginn entwickelten Information-Modell möglich.

327

Sandini Bib 29 WebConsulting-Projekte

29.1.5

Consulting

Das eigentliche Consulting ist wie die Services bereits in zwei Teile gegliedert. Das System und Network-Consulting stellt die komplette Palette an Beratungsleistungen für die unterschiedlichsten Webprojekte innerhalb des Unternehmens zur Verfügung und hilft den Projekten von ihrer Entstehung an über die Entwicklung und den Betriebsübergabeprozess bis hin zur Weiterentwicklung. Das interne Consulting, das mit dem WebFarm-WebConsulting geschaffen wird, ist eine projektbegleitende Maßnahme. Es wird das Know-how über die neusten Technologien und Möglichkeiten, die Einschätzung und kompetente Kontrolle von internen und externen Entwicklungs- und Betriebspartnern und die allgemeine Unterstützung sowohl bei der fachlichen und mediengerechten Konzeption bis hin zur technischen Konzeption für den Produktionsbetrieb übernehmen. Durch eine kleine und schlagfertige Consulting-Truppe können die externen Partner, die im E-Commerce-Bereich auf jeden Fall benötigt werden, sehr effizient und Gewinn bringend für alle Projekte eingesetzt werden, ohne dass die Einhaltung von Standards in Gefahr ist. System-Consulting Das System-Consulting ist der für einzelne Projekte zuständige Teil des Consulting. Hier werden die Prozesse der Anwendungsentwicklung und des mediengerechten Designs sowie der Auswahl von geeigneten Partnern usw. unterstützt. Das WebFarm-WebConsulting-Team hält mit diesem SystemConsulting den einzelnen entstehenden Projekten eine zentrale Schnittstelle zu den Standardverfahren des WebFarm-Standards für die Entwicklung durch die Betriebsvorbereitung sowie den Zugriff auf bereits für alle global bereitstehenden Dienste innerhalb der WebFarm-Infrastruktur bereit. Das System-Consulting kann von den einzelnen Projekten angerufen werden, während eine Entwicklung stattfindet, um Empfehlungen auszusprechen und Beurteilungen und Einschätzungen vorzunehmen. Network-Consulting Analog zu den bereits definierten Rollen im Servicebereich konzentriert sich das Network-Consulting innerhalb des WebFarm-WebConsulting auf den technischen Teil der Anwendungsumsetzung und deren Integration in die vorhandene Infrastruktur. Hier werden benötigte Firewall-Freischaltungen, Netzverbindungen, Lasttests usw. bei den Projekten durchgeführt und geplant. Das Network-Consulting übernimmt auch die Begleitung bis zur Betriebsübergabe an die Systembetriebe.

328

Sandini Bib Leistungsübersicht

Das Network-Consulting muss auf jeden Fall für die Betriebsübergabe angerufen werden, damit Synergieeffekte mit anderen Projekten bzw. Infrastrukturkomponenten auf jeden Fall genutzt werden. Technology Watch Da die Consulting-Teams dafür verantwortlich sind, dass die Projekte von der neusten verfügbaren Technologie profitieren und effizienten Gebrauch von technologischen Möglichkeiten, aber auch von Werkzeugen machen, ist es essenziell für das Consulting, über die Weiterentwicklung der Internet-Technologie auf jeden Fall auf dem Laufenden zu bleiben und genügend Knowhow zu entwickeln, um Trends frühzeitig zu erkennen und diese umzusetzen bzw. Fehlentwicklungen vorherzusehen und das Unternehmen vor falschen Schritten zu schützen.

329

Sandini Bib

Sandini Bib

30

Setting-up von Webprojekten

Das Aufsetzen eines Projektes im Internet-Bereich unterscheidet sich an einigen Punkten von der Projekterzeugung für andere IT-Projekte. Diese Unterschiede, und wie sie durch den WebFarm-Standard zu einem Vorteil für Webprojekte werden können, werden im Folgenden dargestellt.

30.1 Projektantrag Der Antrag für ein Projekt ist immer die Voraussetzung für die Genehmigung von Budgets. Es wird auf jeden Fall für alle Projektarten ein Antragswesen im Unternehmen geben. Beim Verarbeiten von Projektanträgen für Webprojekte sollte auf jeden Fall auf einige Sonderfälle geachtet werden. Webprojekte hängen noch mehr als andere Anwendungen von externen Datenquellen ab. Diese Datenquellen müssen bereits zum Zeitpunkt des Projektantrages identifiziert sein oder zumindest in Aussicht stehen. Die Abhängigkeiten zur Datenversorgung sind der kritischste Pfad in einem Webprojekt, denn die eigentliche einfache Frontend-Entwicklung ist wesentlich unkomplizierter als in anderen Bereichen. Diese Abhängigkeiten müssen im Projektantrag bereits dokumentiert sein, damit entsprechende Ressourcen-Anforderungen als Teil des genehmigten internen Budgets vorhanden sind.

30.2 Gremien und Personal Jedes Projekt innerhalb des Unternehmens besitzt gewisse Gremien, die den Richtlinien des Projektmanagement-Standards des Unternehmens folgen. Normalerweise hat ein Webprojekt einen Lenkungsausschuss, in dem auf jeden Fall neben den Auftrag gebenden Fachabteilungen der IT-Umsetzung auch der Systembetrieb und die interne Revision beteiligt sein sollten. Aufgrund der Entwicklungsgeschwindigkeit der Webprojekte ist es sinnvoll, den Lenkungsausschuss größer als gewöhnlich anzusetzen und ihm auch direkt Entscheidungskompetenz zu übertragen, damit auf Projektsituationen schnell und flexibel reagiert werden kann. Bei der Personalbestückung von Webprojekten sollte das überschaubare Maß an direkten Projektbeteiligten, mit denen eine fachliche Kommunikation geführt wird, auf maximal fünfzig beschränkt werden. Alle größeren Projekte

331

Sandini Bib 30 Setting-up von Webprojekten

sollten sofort in Teilprojekte untergliedert werden, die nach Möglichkeit dann auch sequenziell abgearbeitet werden. Mit steigender Personenzahl steigen auch das Bedürfnis und der Aufwand nach Abstimmung, insbesondere wenn es sich um internationale Projekte handelt, was aufgrund der Ausbreitung des Internets gerade bei Webprojekten sehr häufig der Fall ist. Das Projektmanagement und unbedingt auch das Management von Teilprojekten innerhalb von E-Commerce-Projekten sind auf jeden Fall Vollzeitbeschäftigungen, das Management kann nicht »nebenher« erledigt werden. Aufgrund der kurzen Projektzyklen, des Einsatzes immer wieder neuer Techniken und des großen Kommunikationsbedürfnisses innerhalb von E-Commerce-Projekten ist der Aufwand innerhalb des Projektmanagements stark erhöht. Bei der Besetzung des Projektmanagements ist die gute Kommunikationsfähigkeit des Personals erachtenswert. Da die Entwicklungszyklen auf der einen Seite außergewöhnlich kurz sind, aber auf der anderen Seite sich sehr viele verschiedene Charaktere innerhalb eines Webprojektes aufhalten, ist die Kommunikation über Ergebnisse, Ziele, Tendenzen und das Projekt im Allgemeinen, die vom Projektmanagement gesteuert werden muss, absolut essenziell für das erfolgreiche Abwickeln eines Webprojektes. Wenn politische Probleme ein Webprojekt erfassen, die nicht sachlich zu begründen sind, ist dieses Projekt bereits mit 50%iger Wahrscheinlichkeit gescheitert. Aus diesem Grund sollte bei der Zusammenstellung des Teams darauf geachtet werden, dass destruktiv arbeitende, unzuverlässige Mitarbeiter bzw. »Bedenkenträger« nicht innerhalb des Projektteams aufgestellt werden. Es ist davon auszugehen, dass der Lenkungsausschuss ohnehin die Risiken des Projektes im Auge hat und daher weniger als sonst interne Kontroversen zu diesen Themen benötigt werden.

30.3 Phasenmodell Wie in anderen Projekten auch haben Projekte, die nahe dem WebFarm-Standard aufgesetzt und durchgeführt werden, ein Phasenmodell als Grundlage. Es ist aufgrund der Flexibilität von Webprojekten allerdings noch wichtiger, dass das fachliche Konzept vor der Realisierung unumstößlich steht, da die Diskussion über fachliche Fragen während der Realisierungsphase sofort zum Verlust von technologischer Flexibilität und Zukunftsorientierung führt. Das vorgestellte Phasenmodell ist sehr einfach, muss aber konsequent durchgeführt werden.

332

Sandini Bib Phasenmodell

왘 Konzeption:

Die Konzeptionsphase ist die entscheidende Phase eines Webprojektes und sollte durchaus oder mindestens ein Fünftel der gesamten Projektlaufzeit in Anspruch nehmen. Die Ergebnisse der Konzeption haben für den ersten Release des Projektes absolute Gültigkeit. Gravierende Änderungen können nur in einem nächsten Release abgedeckt werden. 왘 Fachlich:

Die fachliche Konzeption muss abgeschlossen sein, bevor die technische Betrachtung der Anforderungen beginnt. Die Destillierung der fachlichen Konzeption erfolgt selbstverständlich parallel zur technischen Konzeption, da hier Abhängigkeiten bestehen. Aber die Idee des Projekts muss dermaßen detailliert dargestellt sein, dass keinerlei Zweifel über die Realisierungsschritte aufkommen. An der fachlichen Konzeption sind neben dem Projektteam, der Auftrag gebenden Fachabteilung und den eventuellen externen Partnern mit großer Wahrscheinlichkeit auch InformationServices und System-Consulting aus dem WebFarm-WebConsulting-Team eingebunden. 왘 Technisch:

Bei der technischen Konzeption wird die tatsächliche Umsetzung der einzelnen Projektschritte definiert. Es muss eine möglichst weit gehende Definition – also in großer Detailtiefe – vorgenommen werden. Hierbei ist das Network-Consulting aus dem internen WebFarm-WebConsulting eingebunden, um die entsprechenden Fragen zu beantworten und die Abwicklung und Koordination vorzubereiten. 왘 Realisierung:

Die Umsetzungsphase ist neben der Kommunikation und einer absoluten Transparenz innerhalb des Projektes vor allem von der sequenziellen Abarbeitung definierter Technikmodule geprägt, was eine effiziente Umsetzung ohne Abhängigkeiten ermöglichen kann.

333

Sandini Bib

Sandini Bib

Stichwortverzeichnis ! »Ein-Server«-Strategie 133 »My-*«-Seiten 118 »Privacy«-Rechte 252 24-Stunden-Betrieb 272 24-Stunden-Durchschnitt 75 24-Stunden-Verfügbarkeit 134 3D-Visualisierung 232 7-Tage-Betrieb 272 A Abhängigkeiten zwischen Updates 110 Abnahme des Auftraggebers 150 Abruf in Echtzeit 217 Absicherung von Content 221 absolute Pfade 219 absolute Vernetzungen 219 abstrahierte Gruppen 87 Abstraktionsebene 88 Abwicklungsstatistik 305 Accounting 38, 73 ActiveX 34, 252 Address Translation 27 Administrationsberechtigungsstruktur 67 Administrationsinfrastruktur 145 Administrationsoberfläche 185 Administrationsserver 68, 154, 272, 294, 314 Administrationsstruktur 145 Administrationsumgebung 271 Administrationszugriff 294 aggregierte Gruppen 87 Akronyme 127 Aktivierung der Empfehlungen 120–121 Aktivierung des Lernens 120 Aktivierung des Profiling 121 Aktivitäten – bezogen auf Datenbank- und Datawarehouseserver 281 – bezogen auf Firewallsysteme 281 – des Betriebs 276 – für Aufbau und Unterhaltung der Infrastruktur 279

Aktualisierungen 146 Aktualität der Informationen 89 aktuelle Ergänzungen 146 aktuelles Produktionssystem 111 Akzeptanzniveau 114 Alarmierung 37, 304, 310 Alarmklassen des Überwachungssystems 307 Alarmstufen 76, 310 Algorithmen 257 All Traffic 76 Allgemeine Webanwendungen 202 Analyse des Proxy-Traffic 77 analysiertes Benutzerverhalten 113, 120 Änderungsfrequenz 86 – der Daten 273 Änderungsverfahren 271 Anforderungen – an den Datenaustausch 236 – für Inhalte 198 – in Hard- und Software 131 Anforderungsprofile 194 Angriffsart 78 Angriffshäufigkeit 78 Angriffszeitpunkt 78 Anlieferung per E-Mail 104 Antragsverfahren 297 Antragswesen 331 Anwenderdokumentation 40 Anwendung 78 – mehrerer Suchmaschinen auf eine Abfrage 125 Anwendungs-Content 95 Anwendungsfelder für XML 242 Anwendungsklassifizierung 131, 201 Anwendungsschutz 58 anwendungsübergreifende Benutzerprofile 119 anwendungsübergreifende Suchmaschine 127 Anwendungsverhalten 131 Anwendungsverzeichnisse 153 Anzahl gleichzeitiger Benutzer 160 Anzeige des Standortes 208 API 151, 266

335

Sandini Bib Stichwortverzeichnis

Application Gate 23 Application Level Gateway 30–31 Application Level Gateways 35 Application Server 160 – Basisinstanz 160 Application-Level Gate 23 Application-Level-Gate 22 Application-Level-Gateway 26 – applikationsspezifische Proxy-Server 51 Application-Level-Gateway-Logs 74 Application-Monitoring 287 Application-Proxy 51 Application-Server 132, 134, 152, 163, 245, 261 Application-Serving 163 Arbeitsspeicher 158, 160 Archivierung 144–145, 247 – von gesammelten Daten 36 Archivsystem 145 ARP-Puffer 138 ARP-Request 138 Art des Caching 57 AS-Adressen 144 Attacken 37 Attribute 88, 227, 236 Attributwerte 227, 239 Aufbau der DNS-Infrastruktur 48 Aufbewahrung 274 Aufbewahrungsfristen 36, 39 Aufrechterhaltung des Betriebs 271 Aufträge 275, 282 Ausfall einer angebotenen Dienstleistung 315 Ausfallsicherheit 27, 157, 161, 213 Ausfallzeit 316 Ausführungsberechtigung 108 ausgehender Verkehr 80 Auslastung 78 Ausnahmegenehmigungen 223 Außenanbindungen 29 Außerordentliche Patches 314 Auswertungen 73, 79 – für Firewall 76 Auswertungsrechner 78 Authentifizierung 63, 221 – Server 26 – vom Administrator 295 Authentifizierung-Medium 72 Authentizität der Quelle 106 Author 89 Automatic-Restart 308

336

automatische Alarmierung 272 automatische Browser-Konfiguration 52 automatische Überwachung 272 Automatisierbarkeitsanforderungen 194 Automatisierung 272 – von Informationswiederverwendung 199 autonomes System (AS) 144 Autoren 85 Autorenstruktur 90 Autorisation 63 awt-Toolkit 259 B Back-End-Server 303 Backnavigation 208 Back-Office-Systeme 145 Backup 134 Backup-Maschine 137, 315 Backup-System 110, 190 Backup-Verfahren 219, 273 Balise 244 Bandbreite 52 Basisklassen 98 Basiskonfigurationen 285 Basissoftware 153, 290 Basissystembetrieb 271 Basisüberwachung 285 bauliche Maßnahmen 24 Baum von Informationen 87 Baumstruktur 64, 241–242 Beans 255 Behebung des Problems gemäß der Leistungsbeschreibung 315 Behebungsbeginn 320 Belastung 216 Benachrichtigung per E-Mail 110 Benutzbarkeit 201 Benutzer 214 – Sitzungen 79 – und Berechtigungen 64 Benutzerdaten 214 Benutzerdatenbanken 66 Benutzerführung 112, 201, 208 Benutzergruppe 113, 194, 197 – und Berechtigungen 64 Benutzernamen 71 Benutzerpasswort 72 Benutzerprofile 294 Benutzerstammdaten 71 Benutzerunterstützung 131

Sandini Bib Stichwortverzeichnis

Benutzerzahlen 132 Beratungsleistungen 328 Berechtigung 71, 102, 133, 221 – der Benutzer 129, 221 – für Autoren 298 – für die Public-Private-Key-Verbindungen 295 Berechtigungsbaum 67 Berechtigungsdatenbank 36 Berechtigungsmechanismen 152 Berechtigungsmodell 129 Berechtigungsprotokoll 71 Berechtigungsschema 98 Berechtigungsschematik 60 Berechtigungsservice 63 Berechtigungsstruktur 63, 66, 185 Berechtigungssystem 71 Berechtigungsverfahren 70 Beschaffungsaufträge 298 beschränkter Benutzerkreis 253 Bestandteil der Programmierung 201 Bestellmöglichkeit 265 Betreuung von Firewall- und Securitymaschinen 281 Betrieb von Datenverwaltungsdiensten 281 Betriebsanforderungen 134 Betriebsaufträge 298 Betriebsbereitschaft 156 Betriebsdokumentation 40 Betriebskonzept 134, 137 Betriebskosten 158, 321 Betriebslogbücher 293 Betriebsrichtlinien 140 Betriebssicherheit 157–158, 162 – der Anwendungen 156 Betriebssystem 289 Betriebssystemplattformen 30 Betriebssystemsoftware 289 Betriebsübergabe 300, 328 Betriebsübergabebedingungen 304 Betriebsübergabeverfahren 297 Betriebsumgebung 271 Betriebsunterstützung 304 Bibliotheken 247 bidirektionale Links 242 Bildschirmdarstellung 230 Billing 73, 80 Billing-Infrastruktur 73 Billing-System 74 Binärbaum 132

Biometrische Verfahren 72 Blocknummer 224 Boards 264 Browser-Konfiguration 51, 56 Browserskripten 251 browserunabhängig 230 Brückenfunktion 198 BSI 28 Budgets 331 Bundesamt für Sicherheit 28 Business-Logik 268 Business-to-Business 114 Business-to-Business-Shops 265 Buttons 72 C C 248 C++ 248 Cache 52, 57 Caching 51 – von Applets und SSL-Übertragungen 58 – von nicht veränderten Daten 54 Cascading Style Sheets 231 CGI 154, 160, 165, 247 CGI-Entwicklung 181, 248 CGI-Programmierung 261 Challenge-Response-Verfahren 221 Change-History 314 chaotisches Attraktorensystem 120 Charting 263 Chat 264, 290 Checksummen 296 Chief Security Officer (CSO) 300 ChipCard 222 Chipkarten 72 Circuit-Level-Proxies 22 Client-Authentifikation 224 Client-Identifikation 164 Cluster 134, 139, 160, 213, 218–219 – der Intra-Proxy-Server 56 Clustering von Anwendungen 139 Cluster-Lösungen 161 Cluster-Management 213 Cluster-Manager 140 Cluster-Protokolle 216 Cluster-Varianten 213 Cluster-Verwaltung 140 Cold-Fusion 153 Combined-View 77 Common Gateway Interface (CGI) 165

337

Sandini Bib Stichwortverzeichnis

Communities 264 Community-Tools 264 Computer-Based-Training 208 Computer-Communication 236 Computing-Classes 256 Configuration-Management 275 Consulting 328 Content 155, 189 – für eine Anwendung 198 Content Security 27, 34 Content/Knowledge Pool 114 Content-Berechtigungen 59, 128 Content-Management 80, 83, 118, 183, 189, 244, 266 – für Cluster 216 Content-Management-Komponenten 69 Content-Management-Konzept 218 Content-Management-System 70, 118, 155, 185, 189, 217, 266, 291

Content-Management-Systemanträge 298 Content-Pool 81, 83, 93, 100, 118, 185, 191, 198, 299, 327

– als Datenquelle 146 Content-Pool-Benutzer 298 Content-Pool-Netzwerk 193 Content-Pool-Server 105 Content-Pool-Struktur 244 Content-Pool-System 155, 217 Content-Scanning 61 Content-Security 53 Copy-on-Write-Technologie 254 Copyright-Verweise 229 Corba-App-Server 152 CPU 159–160 CRM 264 Cross-Selling 116 Cross-Selling-Ansätze 119 CSO (Chief Security Officer) 300 Customer-Relationship-Management 112 D Darstellung 194 – und Verwaltung von Informationen und Anwendungen 80 Darstellungsart der Informationen 85 Dateibeschreibung 255 Dateinamen 228 Dateischnittstelle 145 Daten, semantisch auswerten 236 Datenbank 158 Datenbankabfragen 179

338

Datenbank-App-Server 152 Datenbankstrukturen 181 Datenbankverbindung 152 Datenbankzugriff 259 Datenbank-Zugriffsverwaltung 180 Datenbestände 133 Datenmanipulation 28 Datenschutz 288 Datenschutzgesetz 80 Datensicherung 135 – per Serveranwendung 135 Datensicherungsrichtlinien 136 Datenspeicher 158 Datenstrom 137, 274 – für dynamischen Content 82 – für semidynamischen Content 82 Datenstruktur 237 Datentransfer 242 – zu Archivsystemen 145 Datenübergabe 272 Datenübertragung 237 Datenverlust 28 Datenzugriffsmodell 241 Debug-Informationen 249 Debug-Konsole 257 Debug-Optionen 257 Debug-Switches 257 definierte Module einer Anwendung 105 definierte Preise 321 Definition der Ansprechpartner 298 Design 193, 230 detailliertere Navigation 209 dezentrales Berechtigungsmanagement 66 dienstbezogene Rechnungsstellung 74 Dienstleistungseinstellung 112 digitale Unterschriften 222 Dimensionierung von Serverhardware 157 Director-(Hardware)-Cluster 216 Directory 97–98, 119 Directory-Lösungen 63 Directory-Server 66 direkte Kommunikation mit dem Content-Pool 105 DMZ 22–23, 30 DMZ I 31–32 DMZ II 31–32, 130, 145 – ohne Außenanbindung 32 DNS 45, 213 – im Internet 45 DNS-Anfragen 45

Sandini Bib Stichwortverzeichnis

DNS-Daten 50 DNS-Infrastruktur 45 DocMe-System 70 Document Object Model (DOM) 241 Document-Type-Definition (DTD) 239 Dokumentation 247, 298 – der benötigten Service-Level und Darstellungsarten 84 Dokumentationswerkzeuge 256 Dokumentenbaum 132 Dokumentenmanagement 144 Dokumentenzahl 124 Dokumentenzyklen 197 DOM 241 doppelte Erstellung von Informationen 198 dreistufiges Sicherheitskonzept 36 Drill-Down für Informationen 194 Drill-Down-orientiert 198 Drill-Down-Struktur 90 Drittnetze 28 DSSSL-Flow-Object-Klassen 239 DTD 239, 241, 243–244 Dual Homed Gate 21–22 Dynamic HTML 251–252 dynamische Ausgaben 248 dynamische Informationen 86, 217 dynamische Informationsabfrage 87 dynamischer Content 81, 189 dynamisches Routing 27, 144 E Echtzeit, abgleichen 219 Echtzeitkommunikation 264 ECMA-Script 239 E-Commerce-Projekte 332 EDI 243 EDIFACT 244 eigene Hardware 133 eigene Server für Benutzergruppen 113 eigener Server 156 eigenständige Verschlüsselung 224 eingehender Verkehr 80 eingeschwungenes Profil 120 Eingliederung der Information in die Struktur der jeweiligen Anwendung 193 Einrückung des Source-Codes 228 Einsatz von Browser-Skriptsprachen 252 Einschätzung von Weiterentwicklungen 78 Einstellungen 249 Eins-zu-eins-Medienkopien 141

Electronic-Data-Interchange 243 elektronische Pinnwände 264 elektronische Unterschrift 292, 297 E-Mail-Alert 308, 310 Empfehlung 116 – auf Ebene von Informationen 119 – lediglich auf das Navigationsverhalten 119 Empfehlungsstruktur 118 Endtags 227 Entscheidungskompetenz 331 Entwicklerdokumentation 42 Entwicklung 275, 282 Entwicklungsaufträge 282 Entwicklungsplattform 150, 158 Entwicklungsprozesse 149 Entwicklungsstandard 146 Entwicklungsstil 254 Entwicklungsumgebung 111, 149, 247, 258 Entwicklungsvoraussetzungen für Cluster 219 Erfassung aller vorhandenen und benötigten Informationen 84 Erfassungssysteme 90 Erfassungssystemlogik 90 erfolgreiche Inbetriebnahme 316 Ergonomie 201 Erkennung von Eindringlingen 36 Erweiterbarkeit auf der Attributebene 195 erweiterte Webanwendung 132 Eskalation bei Nichteinhaltung des Servicelevels 318 Eskalationsstufe 310 Eskalationssystem 307 Eskalationsverfahren 288, 307, 309 Eskalationsverhalten 309 Event-Handling 256 Exception-Handling 256 exec() 249 Expertenanwendungen 209 Expiredate 89 Extensible Markup Language (XML) 237 Extensible Style Sheet Language (XSL) 239 External Segment 22 externe Datenquellen 161, 331 externe Dienste 31 externe DMZ 144 externe Gefahrenherde 78 externe Namen 45 externe Packetfilter 31 externer Gatherer 95 Extrakte 127

339

Sandini Bib Stichwortverzeichnis

F fachliche Freigabe 190 fachliche Konzeption 333 fachliche Koordination 327 fachlicher Redaktionsprozess 149 Fail-Over 283 Fail-Over-Konzept 138 Fail-Over-Lösung 137 Fallback 134 Fall-Back-Lösung 137 Faultmanagement 275 Fehlerfreiheit von Code 256 Fehlernachricht 224 Festplatten 158 Filtering Router 21 Filtering-Gate 22 Filtern von ungewollten Seiten 53 Filterung von Zugriffen 26 Fingerabdruck 72 Fingerprint 222 Firewall-Aufbau – für eine externe Netzanbindung 29 – im internen Netz 28 Firewall-Freischaltungen 300 Firewall-Komponenten 69, 76 Firewall-Systeme 21 Fixes 313 Flaschenhals 27, 30 Flash 251–253 Focus on Business 325 Formalien 282 Format 85, 191, 244 Forum 264 FrameMaker 244 Freigabe 97, 109, 218, 291 – durch den Chief Security Officer 300 – eines Update 110 – von Content 81 – Interface 110 Freigabekriterien 313 Freigabe-Staging 97 Fristgerechte Anlieferung 292 Früherkennung von Problemen 308 Full-Backup 135–136 Funktionale Berechtigung 153 Funktionalität 78, 254 – von Diensten erweitern 313 Funktionen eines Application-Servers 164 Funktionstest 305

340

G GAN-Infrastruktur 142 garantierte Verfügbarkeit 315–316 Garbage Collection 57, 249 Gatherer 93 Gebührenmodell 321 gebündelte Übertragung von Daten 267 geclustert 156 generelle Formatanweisungen 231 generierte Daten 154 Generierung von Grafiken 263 Gesamtlastbetrachtung 78 Gesamtverfügbarkeit 316 Geschäftslogik 268 Geschäftsprozesse 84 geschlossene Benutzergruppen 264 geschützter Content 129 Gesetz zur betrieblichen Mitbestimmung 80 gesetzliche Vorschriften 140 gesicherter Bereich 27 GET 248 Gewichtungen 126 Global Area Network 27 globale Content-Struktur 198 globaler Suchdienst 123 globaler Zyklus 197 GoBS 39 Grafiken und Auswertungen 75 Gremien 331 Grenze der Sicherheitskonstruktion 30 große Benutzerzahl 134 großschreibungssensitiv 228 Großvatersicherung 135 Grundlagen für ein Informationsmodell 98 Gruppenstruktur 66 Gültigkeitsdauer 52 Gültigkeitszeiträume 100 H Halten des Zustands 163–164 Hardware 132 Hardwareausfälle 287 Hardwarebasis 157 Hardwarebetrieb 275 Hardwaredimensionierung 158 Hardwaremanagement 285 Hardwareplanung 78 Hardwareplattform 157

Sandini Bib Stichwortverzeichnis

Hardwareskalierbarkeit 156 Hardwarestandard 285 Hash-Funktion 224 Hash-Verfahren 223 Häufigkeit des Abrufs 116 Hauptbetriebszeiten 283 Hausstandard 158 HBCI 244 Heart-Beat-Protokoll 140 Heterogenität 158 Hierarchie 64 – von Überwachungspunkten 288 Hierarchieebenen 113 hierarchische Organisation 143 – der Informationen 87 High-Availability-Lösungen 137 Hilfssystem 197 Hintergrundinformationen 198 Hits 79 Hochlast 134 Hochsicherheitsbereiche 222 Höchstwerte 77 hochverfügbarer Systembetrieb 300 Hochverfügbarkeitsbetrieb 285, 294 Homepages 205 Homogenität 158 Hooks 256 Hostingarea 29 Hosting-Infrastruktur 32 – mit externer Anbindung 32 Hot Buttons 206 Hotline 275 Hot-Spot Security Konzept 24 HTML 227, 236, 244 HTML-Code 227 HTML-Editor 229 HTML-Extensions 231 HTML-Generatoren 227, 229 HTML-Style 227 HTML-Tags 227 HTTP, Zusatzfunktion 152 HTTP Server 160 HTTP/HTTPS-Server-Logs 73 HTTP-Anwendungen 78 HTTP-Proxy 35 HTTP-Server 69, 151–152 HTTPS-Übertragung 61 HTTPS-Zugriff auf HTTP-Anwendungen 61

I IBM ADSM 274 Identifikation 71–72, 179, 221 – der Kommunikationspartner 96 – der Quelle 106 – des Zulieferers 102 Identifikationsnachweis 71 Identifikationsservice 63 identifizierter Benutzer 115 Implementierung – dieser Anwendungen 149 – von Verfahren 275 Include 152, 262 Incoming-E-Mail 77 Incremental-Backup 135–136 Indexdateien 185 individualisierte Anwendungen nach Gruppen 118 individualisierte Systeme 112 individualisierte Zugänge 116 Individualisierung 113, 116–117, 119, 203 – von Seiten durch den Benutzer 115 individuell erstellte Navigation 116 individuell konfiguriertes Zugangsportal 116 individuelle Anforderungen von Benutzern 112 individuelle Webanwendung 132 individueller Service 114 individueller Zugriff auf eine Anwendung 116 Indizes 124, 195 Indizierung 126–128, 183 Indizierungsverfahren 125 Indizierzeitrahmen 128 Industriestandard 243 Informationen 116 – für Webanwendungen 83 – gecached 58 – nicht gecached 58 – von ihrer tatsächlichen Darstellung trennen 84 Information-Management 327 Information-Modelling 83–85, 89–90, 327 Information-Modelling-Werkzeug 89 Information-Pool 185 Informationsbaum 88, 90 Informationsbedarf 84 Informationsbegriff 85 Informationsdichte 123 Informationsersteller 85, 89 Information-Service 327 Informationsfluss 84, 88–90

341

Sandini Bib Stichwortverzeichnis

Informationsgattungen 102 Informationsklasse 88, 93–94, 191 Informationsklassenbaum 89 Informationsmodel 83 Informationsmodell 85–86, 88–89, 93, 95, 97–98, 100, 198

Informationsstruktur 197, 327 Informationssysteme 202, 327 Informationstyp 84–85 Informationstypisierung 85–86 Informationsübergabe per FTP 104 Informationsverbraucher 85 Informationsverteilung 88, 90 Informationswiederverwendung 81 inkrementelle Sicherungen 273 Innovationszyklen 271 Installation 153 – der Produktionsumgebung 149 Installationsaufträge 298 Integration – in die globale Suchumgebung 186 – von Suchfunktionen in eine einzelne Anwendung 183 Integrationsfähigkeit 150 Integrationstest 300, 303 – Aufbau einer Umgebung 303 Interaktionsmöglichkeiten 202 interaktive Bearbeitung von Webseiten 251 interaktive Multimedia-Shows 232 internationale Projekte 332 interne Abteilungen 325 interne Dienste 32 interne DNS-Infrastrukturanbindung 45 interne Namen 45 interne Namenstruktur 45, 48 interne Packetfilter 31 interne Proxy-Server 52 internen Content-Pool 95 interner Packetfilter 32 internes Routing der Proxy-Infrastruktur 54 internes Segment 32 Internet Explorer 230 Internetanbindung 143 Internetverbindung 142 – ausfallsicher 144 Interpreter 247 Intra-Proxy-Cluster 54 Intrusion Detection 26–27, 30–31, 36–37 Intrusion-Detection-Komponenten 69 Intrusion-Detection-Logs 74

342

IO 159 IP-Ebene 25 Iris-Scan 72 J Java 34 Java-Anwendungen 179 Java-Applets 58, 255 Java-Entwicklung 255, 258 Java-Environments 257 Java-Erweiterungen 255 JavaScript 34, 239, 251–252 JavaScript-Navigation 210 Java-Style 255 Java-Technologie 243 Java-Virtual-Machine 260 JDBC 259 JDBC-Treiber 179 Journaldateien 73 K Kataloge 266 Katalogsysteme 265 Keywords 89, 195 K-Fall 134 K-Fall-Absicherung 140 KI-basierte Suchansätze 127 Klassenbibliotheken 255 Klassenkopf 255 Klassenmodell 99, 198, 256 Klassenstruktur – des Modells 98 – Informationsmodell 99 Klassifikation der Meldungen 307 Klassifizierung 87 – von Informationen 87 Klassifizierungsalgorithmen 126 kleinschreibungssensitiv 228 Knotenstelle der Sicherheitsinfrastruktur 37 Knowledge-Management-Komponenten 69 Knowledge-Pool 266 Kommentare 228, 256 Kommentierung im Code 254 Kommunikation 332 Kommunikationsstruktur von Anwendungen 197 Komplettnavigation 210 komplexe Anfragen 126 komplexe Formatvorlagen 231 komplexere Strukturen 236

Sandini Bib Stichwortverzeichnis

komprimiertes Archiv 106 kondensierte Darstellung von Daten 232 Konfiguration 217 – des Informationsmodells 298 – Proxy-Routing 55 Konfigurationsdateien 185 Konfigurationsfiles 249 Konfigurationskontrolle 288 Konfigurationsmanagement 288 Konfigurationsrichtlinien 293 kontaktfreier Erfahrungsaustausch 119 Konventionalstrafe 316–317 Konventionalstrafen 320 Konventionen für Zeichensätze 107 Konzeption 333 Kopie der Betriebsumgebung 303 korrekte Abrechnung 73 Kostenbetrachtung 179 Kostenersparnis 95 Kostentransparenz 321 Kostenweitergabe 73 kreative Informationsaufnahme 233 Kriterium für die Informationsanlieferung 102 Kryptographie 225 Kryptographie-Algorithmen 223 Kundenbindung 267 künstliche Intelligenz 127 L Lasttest 305 Lastverhalten 73 Laufender Betrieb 275 Laufzeitumgebung 260 Laufzettel 297 Layer-Zugriffe 180 Layout 81, 193, 230, 254 Layout-Definitionen 114 LDAP 66, 70 LDAP-Identifikationsmodul 153 LDAP-Server 70, 116, 221, 290 Lebenszeit 103 Legato Networker 274 Leistungsübersicht 326 Leitdokumentation 39 Lenkungsausschuss 331 Lernverhalten 120 Lesbarkeit von Java-Code 255 Lexikon 197 Linking in XML 242 LINT 254

Liste der Sicherheitsrisiken 38 Lizenzen 298 Lizenzkontrolle 290, 292 Lizenz-Reporting 292 Load-Sharing 53, 139–140 Logbuch 295 Logbuchverfahren 274 Logdateien 159 Logdaten für Auswertungen 73 Logfiles 78 Logfristen 38 Logging-Verfahren 288 Loginformationen 38–39, 159 – Aufbewahrungsfristen 39 Login-Logs 74 logische Schritte 268 logische Struktur 242 Logistikkontrollsystem 266 Logmeldungen 312 Logverzeichnisse 153 lokale Applikationsdatenbanken 219 lokale Benutzer 294 lokale Datensicherung 135–136 lokale Kontrolle 29 lokale Suchmaschine 185 lokaler Campus 29 lokaler Proxy 57 lokales Backup 273 Lokales Content-Management 189 Lokalisieren wichtiger Informationen 123 Lokation einer Suchmaschine 130 Lorenzspirale 120 LWL-Verbindung 140 M Macromedia Flash 231 MaH 39 Mailinglisten 267 Management 156 – der Informationen 191 – der Navigationsstruktur 201, 208 – von Informationen 98 Management-Information-Systeme 198 Mapping 61 Marketing 78 Marketingaktionen 118 Massenfertigung 321 Massenproduktion von Basissystemen 159 Mastermaschine 217, 315 Matrix, Reverse-Matrix-Verfahren 124

343

Sandini Bib Stichwortverzeichnis

ME-Chip 222 Medienaufbewahrung 141 mediengerechte Konzeption 328 mehrsprachiger Content 193 Mehrsprachigkeit 100, 191 Meta-Information 85, 88–89, 98, 103, 125–126, 146, 183, 185, 199

– zur Klassifizierung 99 Meta-Information für die Sprache 192 Metasprache 236–237 Metasuche 125–126, 184 Methode der Auswertung 79 Methoden zur Anlieferung von Informationen 103 Methodenkopf 256 Methodik zur Validierung 237 Middleware 163, 180 Military Level Firewalls 23 Mind-Map 211, 265 Mind-Mapping 265 Mind-Mapping-Werkzeug 233 Modellierung 256 Module 151–152 Module Pool 114 Modulköpfe 248 Monatsdurchschnitt 75 Multicast-Mechanismen 267 multidirektionale Links 242 My-Site 115 N Nachvollziehbarkeit des Systembetriebs 295 Namendatenbanken 49 Namenschema 45 Namenvergabe im GAN 45 Nameserver-Datenbanken 50 Navigation 116, 201, 265 – im momentan gewählten Bereich 207 Navigationsdesign – für allgemeine Anwendungen 205 – für Expertenanwendungen 209 Navigationsebenen 208 Navigationselemente 206 Navigationstypen 201 Navigation-View 208 netscan 38 Netscape Navigator 230 Netscape Sun Alliance 260 Network of Firewalls 25 Network-Consulting 328, 333

344

Network-Services 327 Netzlast 128 Netztrennung 27 Netzwerkcharts 76 Netzwerkdaten 75 Netzwerkprobes 31 Netzwerkscanning 37 Netzwerkschutz 21 nicht registrierte Dienste 36 Notfallmaschinen 141 O Oberklassen 98, 198 Objekthierarchie 241 Objektorientierung der Informationshierarchie 88 öffentlicher Content 129 öffentlicher Schlüssel 72 öffentliches Suchnetz 186 offizielle Adressierungen 45 One-on-One 112–113 OO-Modellierung 256 Open-Trade-Protokoll (OTP) 243 Optionen 249 Organisationsstruktur 325 Organisationssysteme 203 OTP 243 Outgoing-E-Mail 76 Outsourcing 321 – des Systemmanagements 273 P PAC (Proxy Automatic Configuration) 53 PAC-Files 56 PAC-File-Server 56, 68 Package 105 – als Archiv 106 Packaging 105 Packaging-Verfahren 299 Packetfilter 25, 28, 30–31 Packetfilter-Logs 74 Parser 239, 254 Passwort 71, 249 Passwortverfahren 60 Patches 272, 291, 313 Patch-Source 314 Patch-Status 314 Patch-System-Component-Skript 314 Patch-Verfahren 313 Patch-Verteilung 314

Sandini Bib Stichwortverzeichnis

Patch-Verwendung 313 Patterns zur Erkennung von Viren 35 Pattern-Update 36 Peak-Verhalten 78 Performance 158, 160, 271, 283 – der Anwendung 131 – von Anwendungen 51 Performancemanagement 275, 283 Performancestatistik 305 Performance-Tuning 181 Performanceuntersuchungen 150 Performante Ausführung 257 Perl 247 Perl-Skripte 253 Personal 331 Personalbestückung von Webprojekten 331 Personalisierung 112–113, 132 personenbezogene Benutzer 294 personenbezogene Daten 36 Pfade 228 Phasenmodell 332 phonetische Suchen 125 physikalische Netzwerkkarte 138 PIN 71 PIN-TAN 71 PIN-TAN-Verfahren 71 pipe() 249 PKI 63, 297 PKI (Public Key Infrastructure) 72 PKI-Administration 300 Planbarkeit von Betriebskosten 321 Planung 304 Plattenplatz 134 Plattform zum Scannen von Viren 36 Plattformunabhängigkeit 258 Plausibilisierung 131 – von Eingaben 251 Plug-in 152, 163, 251 Plug-in-Technologie 231, 253 Point of Administration 68 Point-to-Point-Verbindungen 34 Policy von Empfehlungen 119 Pool-Server 94 popen() 249 Portal 116 portscan 38 POST 248 Post-Processing-Methoden 261 Präsentationsbeschreibungssprache 236

Pre-Altering 312 Preisstruktur 179 Pre-Processing-Methoden 261 Pre-Production-System 97, 190, 218 Primärberechtigung 70 Primär-Maschine 137 Primary-Nameserver 48 prinzipielle Firewall-Konstruktion 303 Priority-Queue-Cache-Ansatz 57 Private-Key-Verfahren 223–224 Probe 37 Process-Space 248 Produktions-Rollbacks 112 Produktionsumgebung 149 Produktivsysteme 145 Produktklassifizierung bei HTTP-Servern 150 Produktsortimente 266 Profil 120 Profil des Benutzers 115 Profildaten 116–117 Profilfindung 120 Profiling 113 Profilingdaten 252 Profiling-Datenbanken 112 Profilpersonalisierung 117 Programmiersprachen 247 Programmierumgebung 247 Programmkommentierung 256 Projektantrag 331 projektbegleitende Maßnahme 328 Projektmanagement 332 Projektsoftware 291 Pro-Production-System 109 Protokolldateien 73 Protokolle 244 Protokollnamen 228 Provideranbindungen, Load-Sharing 144 providerunabhängige Adressen 144 Proxy-Cache-Funktionalität 51 Proxy-Cluster 52 Proxy-Ext-Cluster 56 Proxy-Hierarchie 53, 55 Proxy-In-Cluster 56 Proxy-Infrastruktur 51, 54–55, 143 Proxy-Konzept 52 Proxy-Server 52, 68, 79, 143, 290 Proxy-Server-Logs 73 Proxyservices 22 Proxy-Software 60

345

Sandini Bib Stichwortverzeichnis

Proxy-Struktur 143 Prozesse 89, 160, 268 – der Anwendungsentwicklung 328 Prozessoren 160 Prüfsumme 224 Public-Key-Verfahren 223 Public-Private-Key-Verfahren 295 Publishdate 89 Punkt-zu-Punkt-Kommunikation 28 Punkt-zu-Punkt-Sicherheit 222 Punkt-zu-Punkt-Verbindungen 29 Python-Skripte 253 Q Qualitätskontrolle 300 Qualitätssicherung 300, 303–305 Qualitätsstufe 300 Qualitätsverbesserungen 95 Quality of Service 288 Quality of Servicemanagement 307 R Rahmenparameter für ein Design 231 räumliche Trennung von Produktions- und Backup-Rechner 140 RC4 224 Reaktion 307 Reaktionsfolge 307 Reaktionszeit 276, 315, 320 – des Herstellers 285 – für den gesamten Betrieb 318 Realisierung 333 Rechenbeispiele 317 Rechenleistung 159–160 Rechenmethode 316 Rechenzentrumsumgebungen 271 Rechner-Router-Kombination 21 Recommendation Engine 116, 119–121 Recovery-Verfahren 273 Redaktion 81 Redaktionsinfrastruktur 155 Redaktionskonzept 97 Redaktionsprozess 299 Redaktionssoftware 118 Redaktionsstufen 97 Redaktionssystem 81, 100, 155, 218 Redaktionsverfahren 100 redundante Leitungen 143 Referenzen 195, 197 Referenzliste 197

346

Regeln 268 Regelwerk 25, 216 registrierte Domäne 45 Reihenfolge der Anlieferungen 102 reine Java-Entwicklung 258 reine Programmanwendung 201 relative Links 219 Release 289 Replikation 66 Replikationsfunktionen 219 Reporting des Systemzustands 312 Repositories 243 Restore-Zeiten 274 Retrieval 126 Retrieval-Engines 126 Reverse-Proxy 58, 216 – mit Trennung der Zugriffssegmente 61 – mit Umsetzung HTTP/HTTPS 62 – zur Trennung der Zugriffssegmente 60 – zur Zugriffskontrolle 59 Reverse-Proxy-Cluster 214 Reverse-Proxy-Server 61 Reverse-Proxy-Verfahren 214 Revisionsforderung 140 Revisionstest 288 Richtlinien – des Projektmanagement-Standards 331 – für die Implementierung 149 rofiling 116 Roll-Back 111 Rolle 185, 221 Rollen des Benutzers 63 Rollenberechtigungen 221 Rollengruppen 63, 66 rollen-orientierte Berechtigung 63 Rollenstruktur 67 Root-Domain 46 Root-Nameserver 48 Round-Robin-Verfahren 213 Routing unter Proxy-Servern 53 Rückverteiler 103 Rückverteilung – freigegebener Packages 110 – von Packages 110 Rules-Engine 268 Runtime-Module 257 S SAFRIST 39 Scan-Mechanismen 306

Sandini Bib Stichwortverzeichnis

Scannen – des E-Mail-Verkehrs nach Viren 35 – nach Diensten 36, 38 Scanner 37 Schlagwörter 125 Schlüssel 72 Schlüsselaustausch 224 Schlüssellänge 225 Schlüsselwörter 185, 195 Schnittstelle 145, 325, 328 – zur Datenlieferung 73 – zwischen Infrastruktur und Entwicklung 149 Schreibberechtigung 108 Schwellwerte 312 Screened Subnet 24 Screening Router 24 Search 183 Secondary-Nameserver 48 Second-Level-Domäne 45 Secure Socket Layer 223 Secure-Content 221 SecureID 221 Seitenlayout 206 Sekundärberechtigung 70 selbst definierte Attribute 228 semi-dynamische Informationen 86, 100, 217 semi-dynamischer Content 81, 189, 191 separate Segmente 23 separierende Instanz 27 Sequenz der Anlieferungen 102 sequenzielle Aktivierung von Updates 111 sequenzielle und chronologische Reihenfolge der Updates 110 Serveranwendungen 263 Serverkomponenten 132 Server-Side-Anwendungen 261 Server-Side-Includes 152, 261 Serveruser 294 Serverzustand zu einem gewissen Zeitpunkt 111 Servicelevel 307 Servicelevel 1 318 Servicelevel 2 316, 318 Servicelevel nach Reaktionszeit 318 Servicelevel-Agreement 276, 315 Servicelevel-Definition 315 – nach Dienstverfügbarkeit 316 Servicepacks 313 Servlet 255, 259, 261–262 Sessiondaten von Benutzern 214

Session-Handling 216 Session-Key 224 Setting-up von Webprojekten 331 SGML 237 Shops 265 Sicherheit 271 – von CGIs 249 Sicherheitsabstimmung 293 Sicherheitsanforderungen 261 Sicherheitsantragswesen 297 Sicherheitscheck 291 Sicherheitskomponenten 39, 327 Sicherheitskonstruktionen als Hosting Area 30 sicherheitskritische Restores 274 Sicherheitsloch 30 Sicherheitslücken 261 Sicherheitsmaßnahmen 313 – auf Contentebene 34 Sicherheitspolicy 27, 31, 37 Sicherheitsrelevante Freischaltungen 299 Sicherheitsstandard 28, 96, 106, 141 Sicherheitssysteme im Backup-Verfahren 274 Sicherheitstest 306 Sicherheitsüberprüfung 249 Sicherheitsverfahren 221 Sicherung der Übertragung 221 Sicherungsprotokolle 136 Side-Includes 60, 151, 251 Side-Navigation 207 Signing 257 Sign-on-Lösung 66 Silver-Stream 153 Single Firewall-Lösungen 24 Single Point of Administration 294 Single-Host-Environment 213 Single-Sign-On 71 Sitzungsschlüssel 224 Skalierbarkeit 161 Skalierungsschritte 157 Skriptanwendungen 251, 254 Skriptsprachen 34, 247, 251 – für den Einsatz auf Serverseite 253 Smartcards 72 SMS-Alert 308 Softwarebetrieb 275 Softwaredefinition 289 Softwarekomponenten 131 Softwarelogbuch 290 Softwaremanagement 289

347

Sandini Bib Stichwortverzeichnis

Sonderzeichen 228 Sortierung 195 Source-Code 314 Speicher 134 Speichermanagement 249 Speicherstatistiken 75 Speicherung von Zuständen 164 Spezifische Webserver 151 Sprachen, identifizieren 192 Sprachkonzept 237 SQL-Abfragen 181 SQL-Zugriffe 181 SSL (Secure Socket Layer) 222–223 SSL-Ticketing 132 SSL-Tickets 153 stabiles Profil 121 Stabilität 158, 271 Standard Generalized Markup Language (SGML) 237 Standarddienste 321 Standarddiskussionen 301 standardisierte HTTP-Server 151 standardisierte Preisermittlung 321 standardisierte Schnittstellen 152 Standardkomponenten 154, 291 Standard-Mailsystem 267 Standards der Übertragungsprotokolle 107 Standardserver 75 Standardumgebungen 321 Standardverfahren 328 Standard-Webanwendung 132 Standard-Web-Proxy-Infrastruktur 51 Standorte, miteinander verbunden 142 State 163 State-Engines 165 Statische Informationen 86, 218 statischer Content 81, 189–190 Statistik 73, 75 – Systemlast 75 statistische Auswertung 73, 159 Status der Anwendung 167 Status-Analysis 308 Stichwörter 100 – Liste 197 Stichwortkatalog 125 Stimme 72 Stored-Procedures 219 Störungsbeginn 316 Strategie des Caching 57 strategische Outsourcing-Partner 325

348

Streaming 267 Streaming-Formate 267 String-Attribute 227 Struktur 81, 114, 191, 194 – der Anwendung 123, 194 – eines internen Namensraums 47 – und Aufgabenverteilung 326 – von Berechtigungen 65 strukturierte Darstellung von Daten 236 strukturiertes Wissen 95 Strukturierung 195, 257 Style 231 – Guides 82 – Sheets 239 – Sheet-Sprache 239 Sub-Cluster 140 Subnetze 27 Subtitel 89 Suchalgorithmen 124–125 Suchanfrage, semantisch 127 Suchdienst für einzelne Webanwendungen 123 Suche 183 Suchen innerhalb des vordefinierten Bereichs 123 Suchfunktion 183 Suchindex 124 Suchmaschine 126, 128 Suchmaschinen 132, 183 Suchverfahren 123 SU-Logs 74 Sun 260 Superberechtigung 65 Superuser 295 Super-User-Accounts 294 SWIFT 244 Symbolik 208 symmetrische Verfahren 224 Synonyme 127 syntaktische Überprüfung von HTML und XML 109 System 190 system() 249 Systemänderung 313 Systembenutzer 294 Systembetrieb 151, 271, 274, 283, 304, 313 System-Consulting 328, 333 Systemlast 75 Systemmeldungen 296 Systempflege 272 Systemsicherheit 293 Systemsicherheit bezüglich Software 293

Sandini Bib Stichwortverzeichnis

Systemsicherung 21 Systemstatus 310 Systemtrennung 153 Systemüberwachung 155, 285, 288 T Tags 227, 236 – ohne Inhalt 239 TAN 72 TCL 247 Tcl-Skripte 253 Teamworkanwendungen 266 Teamworkwerkzeugen 266 technische Konzeption 328, 333 Technologieänderungen 146 Technologieentscheidungen 325 Technologieentwicklungen 325 Technology Watch 329 Teilprojekte 332 Templates 254 Test 150 – des Codes 230 Testdaten 303 Testfälle 305–306 Testphase 304 Testprotokoll 305 Testskripte, Skelette 305 Testumgebung 303–304 Testverfahren 271, 305 textbasierte Metasprache 237 The Brain Navigation 233 Third-Level-Domain 46 Threads 160 Tiefstwerte 77 Time-to-Market 263 Titel 89 Top Level-Navigation 206 Top-Level-Domains 48 Top-Level-Domäne 45 Trace-Level 257 Tracking von Aufträgen 297 Transferverhalten 73 Trends 329 Trennung von Entwicklung und Betrieb 300 Trennung von internen und externen Applikationen 27 Trennung von Person und Rollen 63 Triple Homed Gate 22 trojanische Pferde 35, 258 Typisierung 89

U Übergabe von Anwendungen 300 Übergabeparameter 248 Übergabeverfahren 271, 291 Überprüfung – der Dateiberechtigungen 108 – der Quell- und Zielberechtigung 107 – legaler Namensgebung und Zeichenverwendung 107 – von angelieferten Packages 107 Überschriften 228 Übersicht – Konventionalstrafen 321 – Redaktionssystem 101 – Servicelevel 319 – Standardsysteme 286 – Überwachungsstufen 310 – Warnfaktoren 312 Übersprache 237 Übertragungssicherheit der Daten 106 Übertragungssicherung 222 Überwachung 275, 304 Überwachungsnetzwerk 155 Überwachungssoftware 138 Überwachungsstatus 310 Überwachungsstufen 310 Überwachungssystem 154 Überwachungsverfahren 287 unidirektionale Links 242 unsichere Netze 29 Unterklassen 100 unternehmenskritische Systeme 300 unterschiedliche Konfigurationen 113 unterschiedliche Sichten 243 Unterstützungsfunktionen 206 Unterteilung der Prozesse 215 Updates 155 Updateverfahren 271 URI-Encodings 228 URL-Redirection 216 User Sessions 79 V VBScript 34, 233, 251–252 Veränderung gleicher Dateien 110 Verbesserung – des Performanceverhaltens 214 – des Sicherheitsverhaltens 313 Verbindung über SSL 223 Verbindungsaufbau 223

349

Sandini Bib Stichwortverzeichnis

Verbindungszahl 128 Verfahren 282 Verfahrensvorschriften 86 Verfügbarkeit 162, 283, 316 – der Anwendungen 156 – der Systeme 271 Verfügbarkeitsrechnung 76 Vergleich HTML und XML 236 Verhalten – der Lernkurven 121 – eines Benutzers 116 Verhaltensanalyse und Empfehlung 116 Verhältnis von Cache- zu Non-CacheZugriffen 80 Verlagerung der Rechenleistung 243 Vernetzung 191, 194, 197 – von Dokumenten 100 – von Informationen 195 – von XML-Dokumenten 242 Vernetzungsvoraussetzungen 219 Versand von E-Mails 267 verschiedene Aggregationsebenen 232 verschiedene Sicherheitsstufen 25 verschlüsselt 71 verschlüsselte Übertragung 71 verschlüsselte Zugriffe 180 verschlüsselter Zugriff 61 verschlüsseltes Verfahren zum Transfer der Daten 104 Verschlüsselung 34, 59, 106, 179, 222 – der Informationen 96 – juristisches Problem 223 Verschlüsselungsalgorithmen 223 Verschlüsselungsoperationen 72 Verschlüsselungsstärke 96 Verschlussklauseln 36 Versionierung 103, 112 Versionskontrolle 288 verteiltes Backup 273 Verteilung 89, 98, 109 – der Informationen 84, 191 – unterschiedlicher Anfragen 215 – von Content 81 Verteilungsmodell 90 Verteilungssysteme 90 Verteilungsverfahren 101 Verwaltung – von Berechtigungen 275 – von Mailinglisten 267

350

Verwaltungseinheit für das Informationsmodell 327 Verwaltungswerkzeug 103 Verweis, von Stichwort auf Dokument 196 Vier-Augen-Prinzip 97, 106 Viren 35 Virenscanning 35 virtueller Server 133, 157 virtuelles Netzwerkinterface 138 Visualisierung 263 Voice-Alert 309 Vollsicherungsverfahren 273 Volltextsuche 124–125, 184 VPN-Lösung 222 W W3C 237 WAP 244 Wartung 316 Wartungsfenster 283 Wartungsverträge 285 WatchMe-Logs 74 Web Consulting 298 Webanwendung, und Berechtigungen 70 Webanwendung für Experten 203 Web-Application-Server 163 webbasierte Dokumententypen 193 WebConsulting 325, 333 WebConsulting- Projekte 325 Webdatenbank-Abfragen 181 WebFarm mit Content-Pool-Server 93 WebFarm-Admin 68 WebFarm-Architektur 133 WebFarm-Auftrag 297 WebFarm-Auftragsabwicklung 282 WebFarm-Auftragsnummer 297 WebFarm-Betriebskonzept 272 WebFarm-C-CGI-Lib 248 WebFarm-Consulting 325 WebFarm-Content-Management-Konzept 216 WebFarm-Directory 70 WebFarm-DNS-Admin 69 WebFarm-Dokument 71 WebFarm-Infrastruktur 272 WebFarm-Lokation-Admin 68 WebFarm-Lokation-Org-Admin 68 WebFarm-Organisationskonzept 325 WebFarm-Proxy-Admin 68 WebFarm-Security-Admin 69 WebFarm-Servicelevel 309

Sandini Bib Stichwortverzeichnis

WebFarm-Standard 146, 272 WebFarm-Standard-Servicelevel 274 WebFarm-Standard-Software 154 WebFarm-Systembetrieb 272 WebFarm-Überwachungsmodell 309 WebFarm-Überwachungsverfahren 287 WebFarm-WebServer-Admin 69 Web-Proxy 51 Webserver 77, 290 Webserver-Aufbau 157 Webserver-Hardwaredefinition 156 Webserver-Statistik 79 Website-Werkzeuge 263 Websurfing 77 Weiterentwicklung der Internet-Technologie 329 Weiterleitungsmechanismen 219 Weiterverwendung von Daten 236 well-formed Document 239 Wiederherstellung des Zustands 164 Wiederverwendung von Wissen 95 Wissen 83 Wissensbasierte Navigation 211 Wissensmanagement 32, 83 Wissensnetzwerk 126 Wochendurchschnitt 75 Workflows 265 Workflow-Systeme 243 World Wide Web Consortium (W3C) 237 Wortkombinationen 124 WYSIWYG 229 X XLink 242 XML 236–237, 244 – Datenaustauschformat 243 – syntaktische Regeln 239 XML DTD und Umsetzung 240 XML in der Praxis 244 XML-Design 244 XML-Dokument 241 – Struktur 241 XML-Linking-Language (XLink) 242 XML-Pointer-Language (XPointer) 242 XML-Schnittstelle 242, 245 XML-Struktur 239 XML-Version 240 XML-Verwendung 244 XPointer 242 XSL 239

Z Zahlungssysteme 266 Zeitpunkt der Einstellung 103 Zeitpunkt des Verfalls 103 Zeitraum des Servicelevels 1 316 zentrale Administration 273 zentrale Datensicherung 136 zentrale Server 156 zentrales Datenbank-Backend 219 Zertifikat 72, 106, 223, 292 Zertifikatsverfahren 221 Zertifizierung 72 Zielpublikum 231 Zielsetzungen des WebFarm-Betriebs 276 Zielsystem 110 – für die Informationen 102 Zufallszahlenalgorithmus 225 Zugangsbeschränkung 185 Zugangskontrolle – auf bestimmte Dienste 52 – über Zertifikate 60 – zu Rechnerräumen 73 Zugangs-Proxy-Server 52 Zugangsverantwortlichkeit 71 Zugangsverfahren 272 Zugriff 79 – auf Datenbanken 163 – auf die Arbeitsstation 34 – auf mehrere Datenbanken 180 – über Reverse-Proxy 60 Zugriffsberechtigung 51, 59, 293 Zugriffskontrolle – auf die Anwendung 59 – über den Proxy-Server 60 Zugriffsmethoden 293 – auf Primärdatenbestände 180 Zugriffsschichten 180 Zugriffsstruktur 294, 327 Zugriffsverfahren 295 Zugriffsverhalten der Benutzer 73 Zusammenhang zwischen Security-Level und Authentication-Method 225 zusammenhängende Informationen 192 Zusammenspiel vieler CGIs 165 Zusatzdienste 312 Zusatzfunktionen 152 Zusatzinformationen 88 Zusatzkomponenten 291 zusätzliche Daten 154 Zusatzsoftware 154, 290

351

Sandini Bib Stichwortverzeichnis

Zustand der Applikation 165 Zustand des Produktionssystems 110 Zwei-Prozessor-Maschine 160

352

zweistufige Firewall-Konstruktion 28 zweistufiges Konzept 27 zweite Netzwerkkarte 161

Sandini Bib

Copyright Daten, Texte, Design und Grafiken dieses eBooks, sowie die eventuell angebotenen eBook-Zusatzdaten sind urheberrechtlich geschützt. Dieses eBook stellen wir lediglich als persönliche Einzelplatz-Lizenz zur Verfügung! Jede andere Verwendung dieses eBooks oder zugehöriger Materialien und Informationen, einschliesslich •

der Reproduktion,

•

der Weitergabe,

•

des Weitervertriebs,

•

der Platzierung im Internet, in Intranets, in Extranets,

•

der Veränderung,

•

des Weiterverkaufs

•

und der Veröffentlichung

bedarf der schriftlichen Genehmigung des Verlags. Insbesondere ist die Entfernung oder Änderung des vom Verlag vergebenen Passwortschutzes ausdrücklich untersagt! Bei Fragen zu diesem Thema wenden Sie sich bitte an: [email protected] Zusatzdaten Möglicherweise liegt dem gedruckten Buch eine CD-ROM mit Zusatzdaten bei. Die Zurverfügungstellung dieser Daten auf unseren Websites ist eine freiwillige Leistung des Verlags. Der Rechtsweg ist ausgeschlossen. Hinweis Dieses und viele weitere eBooks können Sie rund um die Uhr und legal auf unserer Website

http://www.informit.de herunterladen