Das Klinikum St. Marien Amberg wurde 1850 als Marienspital zu Amberg gegründet. Das zu Beginn

1. Einführung 1.1. Das Klinikum St. Marien Amberg Das Klinikum St. Marien Amberg wurde 1850 als Marienspital zu Amberg gegründet. Das zu Beginn mit 50 Betten ausgestattete Spital entwickelte sich in den vergangenen 162 Jahren zu einem modernen Klinikum und nimmt eine zentrale Stellung in der Krankenversorgung der Region ein. Das Haus der Versorgungsstufe 3 (Schwerpunktversorgung) beherbergt folgende Fachabteilungen und Institute: Klinik für Innere Medizin I und II, Allgemein, Visceral, Thorax und Gefäßchirurgie, Unfallchirurgie und Orthopädie, Neurochirurgie, Gynäkologie und Geburtshilfe, Pädiatrie, Urologie, Geriatrie und Frührehabilitation,Neurologie, Anästhesiologie und operative Intensivmedizin, Strahlentherapie sowie das Institut für diagnostische und interventionelle Radiologie. Durch verschiedene Zentren und die damit verbundene interdisziplinäre Zusammenarbeit wird eine ganzheitliche Betreuung der Patienten gewährleistet. Das Klinikum wird seit 2004 als Kommunalunternehmen (Anstalt des öffentlichen Rechts der Stadt Amberg) betrieben. 2005 wurde das Gesundheitszentrum St. Marien GmbH als 100 prozentige Tochtergesellschaft des Klinikums gegründet. Diese Einrichtung ermöglicht dem Klinikum das Angebot einer ambulanten Versorgungsform in enger Kooperation mit den bereits verfügbaren Ressourcen des Hauses, sowie mit niedergelassenen Ärzten. Um eine möglichst hohe Qualität der Pflege sicherstellen zu können, betreibt das Klinikum eine eigene Krankenpflegeschule an der sich aktuell knapp 100 junge Menschen in der Ausbildung befinden. Neben der pflegerischen Ausbildung ist das Klinikum in der Funktion als akademisches Lehrkrankenhaus der Universitäten Erlangen Nürnberg sowie der Universität Regensburg auch für die ärztliche Ausbildung mitverantwortlich. Weitere Kooperationsverträge wie z.b. mit der Hochschule Amberg Weiden sichern dem Klinikum den Zugang zu neuen Technologien und beugen dem bevorstehenden Fachkräftemangel vor. Die Einhaltung der durch den Gesetzgeber geforderten Qualitätssicherungsmaßnahmen bewies das Klinikum dieses Jahr wiederholt durch die Zertifizierung durch die KTQ (Kooperation für Transparenz und Qualität im Gesundheitswesen GmbH) mit einem überdurchschnittlich guten Ergebnis. Die Änderungen der Seite 1 von 29

vergangenen Jahr im Gesundheitssystem stellen für ein Krankenhaus auch mittlerer Größe mit 574 Betten wirtschaftliche Herausforderungen dar. Eine genaue Planung, Erfassung und Analyse medizinisch/wirtschaftlicher Kennzahlen sind für den Erhalt jeder medizinischen Einrichtung unabdingbar. So wurden im vergangenen Geschäftsjahr <INSERT> stationäre und <INSERT> ambulante Fälle behandelt. Die durchschnittliche Verweildauer sank im Vergleich zum Vorjahr um <INSERT> auf <INSERT>. Der durchschnittliche Schweregrad (CMI) der Fälle lag bei <INSERT>. Eine im Trend der vergangenen Jahre liegende Steigerung der Auslastung der Bettenkapazitäten von <INSERT> führte zu diversen zum Teil noch im Bau befindlichen Erweiterungsmaßnahmen. Trotz dieser zu einem großen Teil aus Eigenmitteln finanzierten Investition gelang es, einen Überschuss von <INPUT> am Ende des Geschäftsjahres auszuweisen. Dabei galt es auch um <INSERT> % gestiegene Personalkosten durch eine Fallzahlsteigerung von <INSERT> % auszugleichen. Mit knapp 1500 Beschäftigten stellt das Klinikum den zweitgrößten Arbeitgeber der Region dar. Vertreten wird das Klinikum durch den Vorstand Herrn Manfred Wendl, dem Herr Prof. Dr. Helmut Wollschläger als ärztlicher Direktor, Herr Hubert Graf als Verwaltungsleiter sowie Frau Wittmann als Pflegedirektorin zur Seite stehen, die zusammen das Leitungsgremium bilden. Seite 2 von 29

1.2 Die IT Abteilung des Klinikums St. Marien Die IT Abteilung als eine noch verhältnismäßig junge Abteilung des Klinikums stellt die gesamte IT Infrastruktur als interner Dienstleister für das Klinikum zur Verfügung. Dabei ist eine immer engere Verschmelzung der reinen IT Systeme mit den medizinisch technischen Geräten zu beobachten. Dies führt zu einer engen Kooperation der IT mit anderen Abteilungen, wie z.b. der Medizin oder Elektrotechnik. Als vor 25 Jahren das EDV Zeitalter im Klinikum begann, verwaltete der spätere EDV Leiter 2 Computer in der Verwaltung. Aus dieser Ein Mann Abteilung ist eine 15 Mann starke Gruppe geworden, die über 700 Client, 150 Server und 100 verschiedenste Softwaresysteme betreut. Die Aufgaben innerhalb der Abteilung teilen sich in das Tages und Projektgeschäft. Das Tagesgeschäft umfasst die Client und Anwenderbetreuung sowie die Behebung von Problemen und Wartungen an zentralen Systemen. Der Arbeitsablauf für das Tagesgeschäft wird primär über ein Helpdesk System organisiert, in dem Störmeldungen erfasst, verwaltet, abgearbeitet und ausgewertet werden. Im Projektgeschäft werden zeitlich oder durch den Umfang begrenzte Aufgaben z.b. zur Einführung neuer Softwaresysteme durchgeführt. Mitarbeiter werden für die Durchführung vom Tagesgeschäft entsprechend freigestellt. Wo aufgrund der Vielzahl verschiedener sehr spezialisierter Anwendungen kein entsprechend tiefes Verständnis der Software erreicht werden kann, wird der Second Level Support direkt an die Herstellerfirma outgesourced. Neben der engen Zusammenarbeit mit den Herstellerfirmen verschiedenster Software ist eine zunehmende Kooperation der EDV Abteilungen verschiedener medizinischer Einrichtungen zu beobachten. Wird in der Presse über eine Zusammenarbeit zwischen Krankenhäuser oder niedergelassenen Ärzten berichtet, so bildet die EDV Vernetzung in den meisten Fällen die Grundlage und Basis des Daten und Informationsaustausches. Während sich Anforderungen früher auf die Seite 3 von 29

Übertragung von Bilddaten über Dicom o.ä. beschränkten, haben sich heute bereits Einweiserportale oder Videokonferenzsysteme zur interdisziplinären Zusammenarbeit etabliert. Die im klinischen Umfeld eingesetzte Software muss hohe Anforderung an Verfügbarkeit, Sicherheit und Datenschutz erfüllen. Außerdem ist eine überdurchschnittlich hohe Flexibilität bei der Einführung neuer Software notwendig. Neue Systeme müssen kostengünstig, zeitnah, hochverfügbar bereit gestellt werden können. Um diese Anforderungen erfüllen zu können, hat man sich vor 6 Jahren zur Virtualisierung der Bereiche Server, Netzwerk und Speichersysteme entschieden. Kern der Netzwerkinfrastruktur und damit Basis des gesamten Datenverkehrs bilden 2 redundante Catalyst 6500, die in einem Virtual Switch System (VSS) 1440 Verbund der Firma Cisco arbeiten. Im Storage Bereich stehen 2 redundante Storage Server zur Verfügung. Als Hardware dahinter dienen je Storage Server 4 SX100 der Firma Fujitsu als permanente Datenablage. Die einzelnen Shelfs wurden mit verschiedenen Festplatten abhängig vom Anwendungszweck ausgestattet. Die Virtualisierungsschicht auf den 2 Storage Servern wurde mit der Software SANMelody der Firma DataCore realisiert. Diese präsentiert die logischen Volumes über eine FibreChannel SAN Infrastruktur den Servern. In dem in der Öffentlichkeit wohl bekanntesten Virtualisierungsbereich der Servervirtualiserung wird im Klinikum das Produkt der Firma VMWare eingesetzt. Die Version 5 der Software läuft sowohl auf den ESX Hosts, als auch am Virtual Center, welches für die Verwaltung der verschiedenen Komponenten verantwortlich ist. Bei dem Umstieg auf die nächste Hardwaregeneration der ESX Server sollen die bisher einzelnen Server (Fujitsu RX 600) aus Kosten und Verwaltungsgründen durch Blade Server ersetzt werden. Die Komponenten wurden in allen Bereichen redundant ausgelegt, und physikalisch in 2 verschiedenen Serverräumen in unterschiedlichen Brandabschnitten untergebracht. Um selbst im Katastrophenfall Datenverlust zu vermeiden, werden Sicherungen in einem weiteren, dritten Raum abgelegt. Vor 2 Jahren wurde im Klinikum ein flächendeckendes WLAN installiert. Neben Datendiensten wird das WLAN hauptsächlich für die Telefonie genutzt. In Zukunft soll das System außerdem zur Ortung von Patienten und Geräten dienen. Alle Bereiche des Netzwerks wurden mit Komponenten der Firma Cisco ausgestattet. Seite 4 von 29

Die im Klinikum eingesetzten Softwareprodukte lassen sich grob in Medizinische Software, Verwaltungssoftware und Infrastruktursoftware einteilen. Eines der wichtigsten Systeme stellt das Klinikum Information System (KIS), Micom Medicare der Firma Nexus da. In ihm wird der gesamte Behandlungsworkflow, von der Aufnahme, bis zur Abrechnung abgebildet. Als nummernführendes System kann es als zentrale Patientendatenbank verstanden werden. Alle medizinischen Subsysteme müssen relevante Daten über definierte Schnittstellen (HL7) erhalten. Die Kommunikation zwischen dem KIS und den verschiedensten Sub und Spezialsystemen wird von hochverfügbar ausgelegten Schnittstellenservern abgewickelt. Eines der umfangreichsten Subsysteme wird der Radiologie zur Verfügung gestellt. Sowohl als Verwaltungssoftware (RIS) als auch als Bildspeicher kommen Produkte der Firma Siemens (Syngo) zum Einsatz. Da in der Radiologie keine Bilder mehr ausgedruckt werden, muss die Organisation und Ablage der Daten hohe Anforderungen an die Datensicherheit erfüllen. Weitere spezialisierte Subsysteme finden sich in so gut wie jeder Fachabteilung. Probleme mit denen sich aktuell wohl jede Klinik IT befasst, sind einerseits die fachabteilungsübergreifende Darstellung des Datenmaterials, andererseits die sichere Archivierung der Daten. Im Verwaltungsbereich wird neben Medicare hauptsächlich SAP für die Finanzbuchhaltung und Lagerverwaltung eingesetzt. Im medizinisch administrativen Bereich hat man sich anstelle des vom Funktionsumfang sehr breit aufgestellte SAP, für das ausschließlich für den medizinischen Bereich entwickelte Nexus Medicare entschieden. Basis des Infrastrukturbereichs bildet das Microsoft Active Directory. Alle Benutzer werden in dieser zentralen Instanz gepflegt. Um Anwendern einen möglichst großen Komfort bei der Anmeldung bieten zu können, wird bei der Einführung neuer Software auf die Integrationsfähigkeit z.b. durch LDAP oder Kerberos geachtet. Sofern möglich wird dabei auf OpenSource Software zurückgegriffen. Diese bietet neben dem Kostenvorteil eine hohe Flexibilität durch eigene Anpassungen. Seite 5 von 29

2. Erweiterung OTRS Helpdesksystem 2.1. OTRS OTRS (Open Ticket Request System) ist ein webbastiertes Ticketsystem. Es basiert auf den Programmiersprachen Perl sowie JavaScript und ist als Open Source Software frei verfügbar. Die Unterstützung verschiedenster Servertechnologien macht OTRS universal in vielen Umgebungen einsetzbar. So werden neben dem freien Datenbanksystem MySQL, auch die Produkte der kommerziellen Hersteller wie Oracle oder Microsoft, als persistente Datenablage unterstützt. Ebenso spielt es für OTRS keine Rolle, ob der Webserver unter Windows, Unix, Linux oder Mac OS läuft. Das System bietet je nach Rolle verschiedene Bereiche an. Neben einem Bereich für den Ticket Bearbeiter (in OTRS als Agent bezeichnet), existiert ein Kundenbereich über den der Anwender selbst Probleme melden und gemeldete Probleme verwalten kann. Jede Problemmeldung wird von OTRS als ein Ticket mit eindeutiger Identifikationsnummer gespeichert. Die verschiedenen Arbeits und Aufgabenbereiche können in OTRS mit sogenannten Queues abgebildet bzw. gegliedert werden. Jedes Ticket muss zu jeden Zeitpunkt einer Queue zugewiesen sein. Einer Queue ist wiederum mindestens ein, in der Regel jedoch mehrere Agents zugewiesen, die die für sie jeweils relevanten Tickets durch sperren aus der öffentlichen Queue entfernen, und somit für die eigene Bearbeitung markieren. Dadurch kann verhindert werden, dass sich 2 Bearbeiter um das gleiche Problem kümmern. Weitere Funktionen wie das Verschieben zwischen Queues und Bearbeitern oder das Zusammenführen von Tickets sorgen für eine flexible aber auch saubere Ticketverwaltung. Wichtige Features zur Kommunikation mit dem Problemmelder sind Notizen und Antworten. Notizen können sowohl für die interne Dokumentation zwischen den Bearbeitern als auch für die externe Kommunikation mit dem Kunden genutzt werden. Über Antworten lässt sich ein Dialog zwischen Bearbeiter und Problemmelder realisieren. Diese können vom Kunden über die identischen Wege, wie die eigentliche Problemmeldung, an das Ticket angefügt, und so dem Bearbeiter zugestellt werden. Neben dem bereits erwähnten Customer Bereich existiert die sehr unkomplizierte und schnelle Möglichkeit, Nachrichten per Mail an das Ticketsystem zu senden. Da OTRS keine direkte Seite 6 von 29

SMTP Schnittstelle für den E Mail Empfang bereit stellt, werden eingehende Mails auf einem POP3 Server gesammelt, und von dort aus via Cron Job abgeholt. Für die abgeholten Mails wird automatisch ein Ticket in der davor statisch oder dynamisch konfigurierten Queue angelegt. Dies ermöglicht eine vollständige Aufzeichnung der gesamten Agent Kunden Kommunikation. Wichtige Informationen sind so nicht mehr in persönlichen, für andere nicht zugänglichen Outlook Postfächern, sondern zentral für alle zugreifbar einsehbar. Insbesondere im Krankheits oder Vertretungsfall können sich Kollegen so einen schnellen Überblick über den bisherigen Ticketverlauf verschaffen. Um auch den Kunden über den Stand seiner Problemmeldung auf dem Laufenden zu halten, werden z.b. beim Öffnen, Verschieben und Schließen aktionsgetriggert automatische Antworten an den Kunden per Mail versendet, die ihn über den aktuellen Bearbeitungsstand informieren. OTRS bietet eine Vielzahl vorimplementierter Möglichkeiten um das System an die jeweilige Umgebung anzupassen. Als eine der wichtigsten ist das Dynamic Field Feature zu nennen, mit dessen Hilfe sich neue Felder, und somit weiter Informationen dem Ticket hinzufügen lassen. Ebenso lassen sich Kundeninformationen erweitern, um für etwaige Rückfragen alle Daten direkt parat zu haben. Insgesamt bietet OTRS über 1400 Konfigurationsparameter die für den Regelbetrieb eine ausreichende Flexibilität zur Anpassung bereitstellen. Bei tiefergreifenden Änderungen oder Erweiterungen kann der Quellcode direkt geändert werden, oder interne Funktionen durch das Generic Interface von außen durch Eigenentwicklungen genutzt werden. Im Klinikum St. Marien wird das Ticketsystem seit 2005 in der EDV Abteilung und in Teilen der Öffentlichkeitsarbeit eingesetzt. Nach diversen Updates und Erweiterungen wird es aktuell in der Version 3.1.8 betrieben. Basis des Systems bildet eine virtuelle Maschine mit dem Betriebssystem Linux Debian 6.0.6. Der Apache Webserver zur Anzeige der Webseiten sowie der MySQL Server zur Datenspeicherung wurden in den aktuellsten, vom Betriebssystem Repository bereitgestellten, Versionen installiert. Ebenso wurde ein SSH Server für den komfortablen Zugriff auf das Betriebssystem eingerichtet. Alternativ dazu kann zur Administration die direkte Konsole über den Seite 7 von 29

VCenter Client genutzt werden. Die OTRS Installation sowie die nachfolgenden Updates wurden direkt aus den Quelldateien installiert, um ein möglichst aktuelles System mit maximalem Funktionsumfang sowie behobenen Bugs zu erhalten. Bei der Einführung des OTRS System hat man sich dazu entschlossen, eine zentrale Stelle zur Annahme aller IT Probleme zu schaffen. 2 Mitarbeiter sind seither damit betraut, Anrufe und Probleme der Anwender entgegenzunehmen, diese als Ticket im System zu erfassen, und anschließend dem richtigen Bearbeiterkreis zuzustellen. Vorteil dieser Variante ist die hohe Qualität der Problembeschreibung. Bei der Ticketannahme können Rückfragen gestellt. Durch diesen Dialog entsteht eine sehr detaillierte Fehlerbeschreibung. In vielen Fällen kann das Problem sogar direkt dadurch gelöst werden. Allerdings wurden sowohl das Kunden Interface als auch die E Mail Kommunikation mit in die Lösung eingebaut. Der Kunde wird über alle relevanten Schritte, vom Öffnen, über das Zuweisen und Bearbeiten bis hin zum Schließen per Mail auf dem Laufenden gehalten. Genauso kann er im Webinterface den aktuellen Status prüfen und eine Rückfrage zum Ticket stellen. Diese wird automatisch an das Ticket angefügt, und so dem Bearbeiter zur Verfügung gestellt. Hierdurch wird ohne zusätzlichen Aufwand ein komplettes Bearbeitungs und Kommunikationsprotokoll zur Ticket erstellt. Dies wird z.b. für spätere, ähnliche Fehler als FAQ genutzt. Die Authentifizierung am System erfolgt sowohl für die Agents als auch für die Kunden über eine LDAP Schnittstelle gegen das Active Directory des Klinikums. 2.2. Aufgabendefinition Die vorhandene OTRS Infrastruktur soll für Störungen der Betriebstechnik mitbenutzt werden. Dadurch erweitert sich nicht nur der Kreis der Bearbeiter sondern auch das Klientel der Problemmelder. Es kann nun nicht mehr davon ausgegangen werden, dass jeder Problemmelder eine E Mail Adresse und einen Active Directory Account besitzt. Dadurch stehen die Schnittstellen zur Seite 8 von 29

Problemmeldung per Mail und dem im OTRS vorhandenem Webinterface für diesen Zweck nicht zur Verfügung. Die Störannahme per Telefon wie es in der EDV Abteilung zum Großteil genutzt wird, schied aus organisatorischen Gründen ebenfalls aus. Es musste eine Möglichkeit geschaffen werden, möglichst einfach und schnell für jeden ohne Authentifizierung Meldungen aufzugeben. Die Erweiterung soll auf den vorhandenen Mitteln aufbauen, und Klinikums weit ohne Installationsaufwand auf jedem PC zur Verfügung stehen. Seite 9 von 29

2.3. Analyse der Lösungsmöglichkeiten Um eine möglichst einheitliche Struktur und bestmöglichste Integration umzusetzen, war der erste Gedankte, die vorhandenen Formulare und Dateien aus OTRS als Basis zu verwenden und entsprechend anzupassen. Leider stellte sich relativ schnell heraus, dass die im Quellcode umgesetzten konzeptionellen Vorgaben des Systems nicht zu unseren Anforderungen passten, und eine Anpassung mit einem unverhältnismäßig hohen Aufwand verbunden gewesen wäre. Zudem ließen sich die Änderungen nicht transparent für zukünftige Updates in das OTRS System integrieren. Aufgrund dieser Erkenntnisse hat man sich dazu entschlossen, ein separates Interface zur Eingabe der Störmeldungen zu entwickeln und über definierte Schnittstellen mit OTRS zu verknüpfen. Zur Implementierung bot sich die Skriptsprache PHP zum einen aufgrund der vorhandenen Infrastruktur zum anderen aufgrund der schnellen und flexiblen Verbreitungsmöglichkeit an. Als die am einfachsten anzusprechende Schnittstelle erschien mir zunächst MySQL. Die in das Formular eingegeben Daten sollen direkt in die DB gespeichert werden. Vorteil dieser Variante ist die weite Verbreitung und gute Dokumentation der Lösung. Der Ansatz ist in diversen Büchern und Fachartikeln ausführlich und gut beschrieben. Bei den ersten Implementierungsversuchen musste ich jedoch feststellen, dass die OTRS Datenbankarchitektur weitaus komplexer war als anfangs gedacht. Dazu kam dass Daten z.b. die Identifikationsnummer eines Tickets von einer OTRS Internen Funktion generiert wird, und nicht einfach nur hochgezählt wird. Aufgrund dieser Erfahrungen musste ich diesen Versuch abbrechen, und eine anderen Kommunikationsweg über OTRS suchen. Bei der Recherche im Internet bin ich auf das OTRS Generic Interface gestoßen. Es wird vom System angeboten um externe Systeme Dritter Zugriff auf OTRS Interne Funktionen zu geben. Aufgrund der offenen und standardisierten Schnittstelle entschloss man sich die PHP Anwendung kompatibel zum Generic Interface aufzubauen. 2.4. Implementierung der Lösung Seite 10 von 29

Da die Voraussetzungen an die Infrastruktur durch die vorhandene OTRS Installation bereits erfüllt waren, beschränkten sich die Vorbereitungen auf die Einrichtung einer Entwicklungsumgebung. Auf Grund der Größe des Projekts und der überschaubaren Anzahl an Dateien entschloss ich mich für den Unix Editor VI(M) und SVN zur Versionskontrolle. Vorteil dieser schlanken Entwicklungsumgebung waren die geringen Anpassungsarbeiten auf dem Server. So war weder eine Grafische Oberfläche noch ein Samba Server zur Bereitstellung als Windows Freigabe notwendig. Zur Eingabe der Daten zur Störmeldung wurde ein HTML Formular programmiert, welches die relevanten Informationen vom Anwender abfragt. Die Datenvalidierung und Eingabe von Pflichtfeldern konnten via Java Script realisiert werden. Wurden alle benötigten Felder gefüllt, und das Formular abgeschickt, werden die erfassten Daten an ein PHP Skript übergeben. Dieses Skript übernimmt die eigentliche Arbeit. Es baut via HTTP/SOAP eine Verbindung zum OTRS System auf, und legt ein neues Ticket mit den übergebenen Daten an. Die OTRS Schnittstelle bietet 2 Betriebsmodi und setzt sich aus 4 Modulen zusammen. Das OTRS Generic Interface kann als sogenannter Requester und Provider betrieben werden. Als Reqester geht die Kommunikation von OTRS aus. Beim Provider agiert OTRS als Annahmestelle für Daten. Diese letztgenannte Schnittstelle wird vom PHP Skript angesprochen um das Ticket anzulegen. Das erste Modul, Network Transport übernimmt die Kommunikation mit dem entfernten System. Im Provider Modi erfolgt dies über das Skript nph genericinterface.pl. Um dieses nutzen zu können muss ein WebService Handler in OTRS angelegt werden. In diesem werden die Einstellungen zur Kommunikation zwischen dem externen Service und OTRS festgelegt. Als Transport Methode steht im Provider Modus lediglich HTTP::SOAP zur Wahl. Die OTRS Interne Funktion wird über einen sogenannten Controller definiert. Dieser wird im eben erzeugen Webservice definiert und kann in der externen Applikation angesprochen werden. In den weiteren Modulen wie z.b. dem Data Seite 11 von 29

Mapping zur Anpassung der Datenstruktur waren keine Anpassungen notwendig, da ich die Applikation selber an die OTRS Vorgaben anpassen konnte. Damit war die Konfiguration des OTRS System abgeschlossen. Die Übergabe an das OTRS System und die Rückmeldung an den Anwender umfasst 3 Schritte, die je in einer Datei abgebildet werden. Das erste File stellt das HTML Formular zur Eingabe der Daten bereit. Der Problemmelder muss in fest definierten Feldern Angaben zu seiner Person sowie dem Problem hinterlegen. Dabei sind bestimmte Felder als Pflichtfeld auszufüllen. Da ohne diese zwingend benötigten Daten die Verarbeitung nicht fortgesetzt, und kein Ticket in OTRS angelegt werden darf, wird die Dateneingabe direkt auf der Eingabeseite durch eine JavaSkript Funktion geprüft. Hierdurch werden die fehlerhaften Daten erst gar nicht an ein verarbeitendes Skript weitergegeben, sondern schon im ersten Schritt bei der Eingabe abgefangen. Wurden alle geforderten Daten eingegeben, erfolgt die Weiterleitung zur nächsten Seite. In diesem Schritt erfolgt als erstes eine primitive Datenvalidierung, ob alle benötigten Daten erfolgreich übergeben werden konnten. Um den Zugriff auf die Daten während der gesamten Laufzeit einer Sitzung gewährleisten zu können, werden diese zunächst in entsprechenden Session Variablen abgelegt. Anschließend wird eine Instanz er SOAP Client Klasse erzeugt. Diese ermöglicht den Zugriff auf den OTRS Webservice und damit die Nutzung der internen Funktionen. Wichtigster Parameter im Konstruktor der SOAP Client Klasse ist die URL zum Webservice im OTRS Webverzeichnis. Diese setzt sich aus dem Pfad zum Generic Interface und dem Namen den Webservices zusammen ('http://<servername>/otrs/nphgenericinterface.pl/webservice/newticket'). Zurückgegeben wird das Client Objekt, über das mit der Funktion soapcall Funktionen des Webservices genutzt werden können. $soapclientobject = new SoapClient(null, array('location' => $url,... $ticketid = $soapclientobject-> soapcall(createmyticket, TICKETDATEN... Wie im Code Snipped zu sehen wird der soapcall Funktion der Name der Operation sowie die Seite 12 von 29

dazugehörigen Daten übergeben. In diesem Fall wurde im OTRS Webservice NewTicket die Operation CreateMyTicket definiert, hinter der sich der OTRS Controller Ticket::TicketCreate verbirgt. Als zweiten Parameter werden der Funktion direkt die Ticketdaten aus den Session Variablen übergeben. Bei Erfolg gibt die Funktion die ID des neu erstellten Tickets zurück. Diese wird ebenfalls in einer Session Variable abgelegt. Im Fehlerfall wird eine Exception geworfen und die Verarbeitung abgebrochen. Um dem Problemmelder die Ticketdaten sowie die ID seiner neu erstellten Meldung mitzuteilen, sollen alle erfassten Daten gesammelt ausgegeben und auf Wunsch gedruckt werden können. Um ein doppeltes Erstellen des Tickets bei bewusster oder unbewusster Aktualisierung (F5) der Seite zu vermeiden, wird man nach dem erfolgreichen Erstellen des OTRS Tickets umgehend auf eine separate Ausgabeseite weitergeleitet. Hier werden die Daten wie gefordert inkl. Ticket ID ausgegeben. Der Ausdruck der Seite wird über die JavaScript Funktion onclick="javascript:window.print()" realisiert. Der Problembearbeiter bekommt von dem Weg des Tickets nichts mit. Für ihn wird das Ticket in der entsprechenden Queue wie jedes andere Telefon oder E Mail Ticket angezeigt. Die OTRS Queue wird vom Problemmelder durch die Angabe eines Problembereichs automatisch zugeordnet. 2.5. Test und Übergabe Die Funktionalen Tests wurden parallel zur Programmierung der einzelnen Methoden durchgeführt. Abschließende Tests über den gesamten Workflow inkl. der Ticket Bearbeitung im OTRS erfolgten durch Mitarbeiter der EDV Abteilung. Das diese bereits mit dem OTRS System vertraut waren, konnten sie die korrekte Ticketerstellung innerhalb des Systeme prüfen, und den kompletten Prozess beurteilen. Die Übergabe und Übernahme in den Produktivbetrieb erfolgte nach einer Schulung des Bearbeiter Personals der Betriebstechnik. Seite 13 von 29

3. Aktualisierung des Mailhubs zur Spam und Virenabwehr Die Kommunikation via E Mail wird heutzutage als selbstverständlich aufgefasst. Selbst Computer Laien können binnen Minuten und ohne Vorkenntnisse E Mails senden und empfangen. Ermöglicht wird dies insbesondere durch sehr einfach und bequem zu bedienende Client Software (Mail User Agent MUA). Leider bringt diese Bequemlichkeit auch einen Nachteil mit sich. Den Anwendern fehlt das Hintergrundwissen zur E Mail Kommunikation und den zugrundeliegenden Protokollen. So wird das rein für Textnachrichten konzeptionierte SMTP (Simple Mail Transfer Protokoll) heute oft als Protokoll zur Übertragung großer Multimediadateien, zur Echtzeitkommunikation (Instand Messaging) oder zum Versand formatierter HTML Dokumente missverstanden. Aussagen wie der Empfang meiner E Mail muss garantiert werden, und darf unter keinen Umständen verzögert oder von Dritten gelesen werden belegen dieses mangelnde Wissen um die Funktionsweise und Hintergründe der E Mail Kommunikation. So werden z.b. insbesondere Techniken zur Verzögerung von E Mails bewusst zur SPAM Bekämpfung eingesetzt. Vielen Anwendern, die sich von ein bis zwei SPAM Mails gestört fühlen, ist nicht bekannt, dass diese Mails über 95 % des weltweiten E Mail Verkehrs verursachen. Um diese Flut vom E Mail Nutzer fern zu halten wurden diverse Techniken entwickelt, auf im weiteren Verlauf noch genauer eingegangen wird. In der Praxis hat sich eine logische, sowie in vielen Fällen auch physikalische Trennung der Aufgaben auf verschiedene Software und Hardwarekomponenten etabliert. Während die Benutzerpostfächer samt Zugriffsstruktur meist auf innerhalb des Firmen Netzwerks liegenden Groupware /Mailservern zu finden sind, übernehmen sogenannte Mailhubs oder Mailrelays die Kommunikation mit entfernten Mailservern. Da diese von Außenwelt erreichbar sein müssen, findet man sie in der Regel in speziell gesicherten, und abgeschotteten Netzwerken, den demilitarisierte Zonen (DMZ). Dort sind sie sowohl für die Annahme und Weiterleitung an den Postfachspeicher erwünschter, als auch im Besonderen für die Zurückweisung unerwünschter E Mails zuständig. Neben dem Empfang übernimmt ein Mailhub auch die Weiterleitung, der intern generierten E Mails an die Mailserver der Kommunikationspartner. Hierbei spielt das DNS (Domain Name Service) Protokoll eine Seite 14 von 29

entscheidende Rolle. Über in der DNS Zone definierte Mail Exchange Resource Records wird der Transportweg einer Mail für eine bestimmte Domain definiert. Außerdem ist eine korrekte DNS Konfiguration notwendig, um nicht selbst als SPAMer klassifiziert zu werden. Um Entscheidungen zum Mailrouting schnell und zuverlässig treffen zu können findet man in vielen Setups direkt neben dem Mailhub einen DNS Forwarder, der selbst keine Zonen verwaltet, sondern Anfragen nur zwischenspeichert oder ggf. an externe DNS Server delegiert. 3.1. Ist Analyse Im Klinikum St. Marien ist die oben beschriebene Struktur weitgehend umgesetzt. Die Daten und E Mails der Benutzer werden innerhalb des Netzwerks auf einem Microsoft Exchange Server gehalten und verwaltet. Für die Archivierung älterer, selten benötigter E Mails steht ein nachgelagertes Archiv bereit. Für den Zugriff auf die Postfächer steht den Anwendern Microsoft Outlook als vollwertiger, sowie Outlook Webaccess als eingeschränkter Client intern zur Verfügung. Ein Zugriff von Extern auf das Benutzerkonto ist aus Datenschutzgründen nicht möglich. Zur Spambekämpfung wird ein Mailrelay in der DMZ betrieben, welches im Mailfluss logisch vor dem Exchange Server angeordnet ist. Als Mailserversoftware kommt die aktuelle Sendmail Version, welche um zahlreiche Milter und Zusatzprogramme erweitert wurde, zum Einsatz. Als Basis dient ein gehärtetes Linux Grundsystem. Um einen größtmöglichen Schutz vor Viren und sonstiger Schadsoftware garantieren zu können, wurden sowohl auf dem Mailrelay, als auch auf dem Exchange Server spezielle Virenscanner unterschiedlicher Hersteller installiert und konfiguriert. Beide Dienste werden Hochverfügbar über die hausweite virtualisierte Infrastruktur bereitgestellt. 3.2. Aufgabendefinition Auch wenn Sendmail als Software für Mailsysteme immer noch sehr weit verbreitet ist, nimmt dessen Bedeutung stetig ab. Dies liegt zum einen an der äußerst komplexen Konfiguration und zum Seite 15 von 29

anderen an den regelmäßig bekannt werdenden Sicherheitslücken, die aufwendig gepached werden müssen. Funktionen, die heute Mail Transfer Agents (MTA) von Haus aus mitbringen, müssen bei Sendmail als Milter eingebunden werden. Dieses Konzept macht Sendmail auf der einen Seite sehr flexibel auf der anderen Seite auch sehr schwer zu verwalten. Besonders schwierig gestaltet sich die Absicherung des Systems durch die unzähligen Verbindungen zu den externen Modulen und Programmen. Um die erwähnten Nachteile zu beseitigen, soll das vorhandene System durch ein modernes, modulares System zur Spam und Virenabwehr abgelöst werden. Das Nachfolgesystem soll einfacher zu administrieren und konfigurieren sein. Dabei soll bei gleichbleibender SPAM und Virenerkennungsrate die Gesamtsicherheit des Systems erhöht werden. Auf Grund der hohen Qualität und Verbreitung quelloffener Software in diesem Bereich soll auf kommerzielle, kostenpflichtige Lösungen verzichtet werden. Um Ausfallzeiten zu vermeiden, soll das neue System parallel zum Bestehenden aufgebaut werden und dessen Infrastruktur nutzen. 3.3. Implementierung und Konfiguration der Lösung Durch die bereits bestehende virtualisierte Infrastruktur gestaltete sich die Einrichtung der neuen Hardware sehr einfach, schnell und kostengünstig. Logisch direkt neben dem aktiven Mailhub wurde eine neue virtuelle Maschine angelegt, und konfiguriert. Bei der Auswahl des Betriebssystems fiel die Entscheidung auf die Linux Distribution Ubuntu 12.04 LTS. Grund war zum einen das auf Linux Debian basierende Grundsystem, mit dem die Administratoren vor Ort vertraut waren, zum anderen der lange Support Zeitraum von 5 Jahren, indem Updates und neue Pakete bereit gestellt werden. Die Installation des Betriebssystems erfolgte zum Großteil nach Standardvorgaben. Dabei wurde die Partitionierung so gewählt, dass eine volle Partition nicht zum Stillstand des Gesamtsystems führen kann. Als Paketquelle erwiesen sich die Ubuntu Quellen als ausreichend. Um ein möglichst schlankes, stabiles und sicheres Grundsystem bereitzustellen, wurde als Installationstyp ein Minimalsystem ohne grafische Benutzeroberfläche gewählt. Zur Administration des Systems steht zum Zeitpunkt der Seite 16 von 29

Installation nur die VMWare Konsole und nach Abschluss dieser ein SSH Server zum Remotezugriff zur Verfügung. Da ein direkter Zugriff vom Internet aus auf diesen Server möglich ist, mussten spezielle Maßnahmen zur Absicherung des Systems ergriffen werden. So wurde das Betriebssystem mit seinem Kernel nach internen Vorgaben und Vorlagen gehärtet und unnötige Dienste deinstalliert. Des Weiteren wurde eine lokale Firewall zur Paketfilterung installiert und konfiguriert. Dabei wurde auf das im Linux Kernel enthaltene IPTables Modul mit Stateful Packet Inspection zurückgegriffen. Um Einbruchsversuche, Systemereignisse oder Logmeldungen der Mailserversoftware zeitlich richtig ein und zuordnen zu können, ist eine korrekte Systemzeit insbesondere für sicherheitskritische Komponenten zwingend erforderlich. Für die Aufgabe der Zeitsynchronisation wurde der Ubuntu NTP Client installiert und konfiguriert. Um optimal mit der zugrundeliegenden VMWare Infrastruktur zusammenarbeiten zu können, war die Installation der VMWare Tools auf dem Gast System notwendig. Da es im alltäglichen Betrieb unmöglich ist, alle Systeme, deren Auslastung und Ereignisse im Blick zu haben, wird im Klinikum die Monitoring Software Nagios eingesetzt. Diese prüft je nach Konfiguration eines Hosts oder Services die Verfügbarkeit und Auslastung in regelmäßigen Zeitabständen. Wie auch der alte Mailhub soll auch die Nachfolgeinstallation über Nagios überwacht werden. Um die relevanten Informationen vom zu überwachenden Hosts abrufen zu können, muss der Nagios Server eine Verbindung zum entfernten System aufbauen, dort je nach Check ein Programm ausführen, und dessen Rückgabewert interpretieren. Für diesen Zweck steht in den Paketquellen das Programm NRPE (Nagios Remote Plugin Executor) zur Verfügung. Es öffnet auf dem Zielsystem einen definierten Port, zum dem sich das Serversystem verbinden kann, und über das er Checks zur CPU Auslastung, RAM Belegung, Belegung der Partitionen oder Verfügbarkeitsprüfung einzelner Dienste und Anwendungen ausführen kann. Nach der Installation der Mailserverdienste sollen diese Checks noch einmal überarbeitet und angepasst werden. Dieser sehr detaillierte Systemstatus kann über ein Nagios Webinterface an zentraler Stelle eingesehen und geprüft werden. Meldungen über Warnungen oder Fehler auf den überwachten Systemen werden per Mail aktiv an den Administrator gesendet. Nach Abschluss der Grundinstallation wurden die Firewall Systeme Seite 17 von 29

sowohl zum internen Netzwerk, als auch zum Internet speziell nach den Anforderungen des E Mail Systems angepasst. Grundbedingung für die Funktionalität des späteren Systems ist die Erreichbarkeit des E Mail Dienstes in beide Richtungen. Für den Versand muss der interne Exchange Server Mails an den Mailhub in der DMZ zustellen können. Die Gegenrichtung wird primär für den Empfang von E Mails benötigt. Weitere Freigaben zur Administrator und Überwachung des Servers wurden gemäß internen Vorgaben eingerichtet. Die Regeln auf der Firewall Instanz zwischen Internet und DMZ wurden vorbereitet, jedoch während der Test und Installationsphase noch nicht aktiviert. Lediglich der Zugriff auf Updates, Paketquellen, Zeitsynchronisation und entfernte Testserver wurde ermöglicht. Um den Grundzustand des neuen Systems zu sichern, und im Fehlerfall wiederherstellen zu können, wurde ein Snapshot der virtuellen Maschine angelegt. Nach der Installation und Konfiguration dieser Basiskomponenten musste die Entscheidung für die einzusetzende Mailserversoftware getroffen werden. Nach Recherchen in einschlägiger Fachliteratur stellte sich der Mailserver Postfix als das für die Anforderungen passende Produkt heraus. Er bietet eine ähnliche, modulare Struktur wie der in die Jahre gekommen Sendmail, ermöglicht jedoch eine einfachere und komfortablere Konfiguration und Administration. Außerdem konnten von Beginn an Protokolle und Features, die in Sendmail über die Jahre aus Kompatibilitätsgründen mitgeschleift wurden, heutzutage allerdings keine Rolle mehr spielen, bei Postfix von Beginn an außen vor gelassen werden. Dies führt zu einer kompakteren, kleineren und sichereren Installation. Allerdings schränkt dies keineswegs die Flexibilität und Möglichkeiten des Postfix Systems ein. Im Grundpaket nicht enthaltene Features können über die erwähnte Modulare Struktur jederzeit eingebunden werden. Als für das neue Konzept besonders hervorzuhebende Partner Komponente ist vorab Amavis zu nennen. Sie übernimmt einerseits die Prüfung auf Viren und potentiell schädlicher Dateianhänge, sowie andererseits die contentbasierte Spamprüfung. Dabei greift Amavis auf bestehende Softwarepakete wie Spamassassin oder ClamAV zurück. Neben ClamAV, der sich als freier Virenscanner auch im professionellen Umfeld etabliert hat, bietet Amavis Schnittstellen zu Seite 18 von 29

allen gängigen Virenscannern. Auf die übrigen für die SPAM Bekämpfung relevanten Bestandteile der Lösung wird im weiteren Verlauf genauer eingegangen. Da die in den Paketquellen zur Verfügung gestellte Version alle benötigten Features enthielt, konnte auf eine manuelle Übersetzung und Installation des Quellcodes verzichtet werden. Durch die Verwendung des Paketverwaltungssystems Advanced Packaging Tool (APT) gestaltet sich die Installation sowie die Instandhaltung einfacher. Neben der automatischen Auflösung von Paketabhängigkeiten während der Installation erleichtert es insbesondere das Einspielen von Updates und neuen Versionen und somit die Wartung der Softwareinstanz. Die Installation des Basis Mailserverpakets Postfix konnte schnell abgeschlossen werden, da die im Paket hinterlegten Standardangaben wie Pfadangaben ohne Anpassung übernommen werden konnten. Die von der Distribution vorgeschlagene Konfiguration wurde hingegen komplett verworfen, um ein perfekt an die Anforderungen angepasstes System zu erhalten. Die Postfix Grundkonfiguration ist auf 2 Dateien aufgeteilt. Das Verhalten des Systems wird durch entsprechende Variablenzuweisungen in der Datei main.cf verwaltet. Zu Beginn sind hier lediglich Angaben zum Mailsystem selber, wie z.b. der Hostname, das vertrauenswürdige Netzwerk oder die eigene Domain enthalten. Im weiteren Verlauf werden insbesondere Parameter zur Spambekämpfung diese Datei erweitern. Das zweite File dient zur Konfiguration des Postfix Masterprogramms (master). Es ist für die Überwachung, Steuerung und Koordination der einzelnen Postfix Komponenten zuständig, und nimmt somit eine zentrale Stellung im Postfix System ein. Nach jedem Konfigurationsschritt wurde die korrekte Funktionalität des Systems getestet. Bereits in diesem frühen Stadium erfolgten Tests zur Erreichbarkeit des SMTP Diensten (TCP / 25) und zur Zustellung von Mails an lokale Postfächer. Besonderes Augenmerk wurde dabei auf das zuverlässige Blocken von E Mails, die nicht an eigene Domains adressiert sind, gelegt. Auch wenn Postfix selber Schutzmechanismen bereitstellt, um das Verhalten als sogenanntes Open Relay zu verhindern, müssen insbesondere Parameter zur Freigabe bestimmter Funktionen genau geprüft und anschließend getestet werden. Das Mailrouting, also die Weiterleitung und Zustellung von E Mails wird im Internet durch die Einrichtung von MX Records in den DNS Zonen definiert. Seite 19 von 29

Dieses Prinzip funktioniert bei einem Mailrelay nicht, da es nach außen hin selbst als MX für die Zone konfiguriert ist. Es müssen demnach zusätzliche Informationen auf dem Relay hinterlegt werden, anhand derer es entscheiden kann, wohin die Mail endgültig zuzustellen ist. Unter anderem um diese Entscheidungen treffen zu können kennt Postfix das Konzept der Lookup Tables. In diesen einfach aufgebauten, in Tabellenform gehaltenen Textdateien wird in der linken Spalte der Bereich definiert, für den die in der rechten Spalte definierte Aktion ausgeführt wird. Um nun Weg einer E Mail festlegen zu können, muss zunächst die Empfangsdomain als relay_domain(s) dem Postfix System bekannt gemacht werden. Andererseits würde der SMTP Daemon die Annahme der Mail verweigern. Im zweiten Schritt ist der eigentliche Transportweg via transport_maps festzulegen. Da beide Konfigurationsparameter dasselbe Textformat erwarten, können beide auf die gleiche, einzige Datei zeigen, was die Wartung und Pflege vereinfacht. transport_maps = hash:/etc/postfix/lookup/transport, hash:/etc/postfix/lookup/relay_domains relay_domains = hash:/etc/postfix/lookup/relay_domains $ cat /etc/postfix/lookup/relay_domains # Domain Eigentliches Ziel (Groupware System) mydomain.de :[192.168.0.25] mydomainxy.de :[192.168.0.25] mydomain2.de :[192.168.0.111] Die grundlegende Funktionalität des Mailhubs ist damit bereits sichergestellt. Mails werden über das SMTP Protokoll entgegengenommen, und anhand der Zieldomain an das im internen Netzwerk befindliche Groupware System weitergeleitet. Die weiteren Konfigurationsarbeiten dienen insbesondere zur SPAM und Virenabwehr sowie zur Absicherung des Systems und der E Mail Kommunikation. Auch in diesem Bereich bringt Postfix schon von Haus aus eine Fülle an nützlicher Funktionen mit. Die Reihenfolge der nachfolgenden Prüfungen entspricht der Abarbeitung dieser im Verlauf des SMTP Dialogs bei der Einlieferung einer E Mail. Dabei soll versucht werden, CPU Intensive Prüfvorgänge wie Content Filtering so spät, und damit so selten wie möglich ausführen zu Seite 20 von 29