KAV-IT BN-003 Software Basisanforderungen 2016
Werbung
Betriebsnorm Software Basisanforderungen im KAV Änderungshistorie: Version Verantwortliche/r Änderungen Freigabe Datum Gültig Datum 4.0 4.1 Neufassung Hinzufügen Punkt Dokumentation 20160307/BJF 20160530/BJF 20160314 20160530 Barnert Barnert Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 2 von 12 DVR: 0000191 Inhalt Betriebsnorm .................................................................................................................................. 1 Software Basisanforderungen im KAV ....................................................................................... 1 1. Allgemeines ................................................................................................................................ 4 2. Server Applikationen ................................................................................................................. 4 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. 2.10. 3. Implementation ............................................................................................................................... 4 Installation....................................................................................................................................... 4 Verträglichkeit ................................................................................................................................. 5 Mandantenfähigkeit ........................................................................................................................ 5 Administration ................................................................................................................................. 5 Zugriffssicherheit ............................................................................................................................ 5 Fehlerbehandlung........................................................................................................................... 5 Logging ........................................................................................................................................... 5 Sicherheitslogging .......................................................................................................................... 5 Timeouts ..................................................................................................................................... 5 Client Applikationen .................................................................................................................. 6 3.1. 3.2. 3.3. Features der Software .................................................................................................................... 6 Installation....................................................................................................................................... 6 Zugriffssicherheit ............................................................................................................................ 6 4. Kategorisierung beim Einsatz von Client Applikationen und virtuellen Desktopumgebungen ........................................................................................................................ 7 5. Savesets (SW Packages) .......................................................................................................... 8 6. Dokumentation ........................................................................................................................... 8 7. Die einzelnen Teile im Detail .................................................................................................... 9 7.1. 7.2. 7.3. 7.4. WEB-Teil......................................................................................................................................... 9 SQL-Teil.......................................................................................................................................... 9 ORACLE-Teil ................................................................................................................................ 10 Client-Teil...................................................................................................................................... 11 ............................................................................................................................................................ 12 Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 3 von 12 DVR: 0000191 1. Allgemeines • • • • • • • • • • • • • • • Dynamische Netzwerkadressenvergabe erfolgt mittels DHCP (Client und Server) Adressierung im Netz nur mittels FQDN Verwendung von Ressourcen im Netz nur mittels UNC, nicht mit Laufwerksverbindung. Speicherung von Daten nur auf File- oder DB-Servern im Netz, nicht jedoch lokal Client-Server- oder Intranet-Technologie Kein Cloud Computing außerhalb der Netzgrenzen des KAV Lauffähigkeit auf zentralen DB- bzw. Webservern, die physisch von den Applikationsservern unterschiedlich sind. Auf sämtlichen Maschinen im KAV läuft ein standardmäßiger Virenschutz, dessen Funktionsfähigkeit nicht eingeschränkt werden darf. Sämtliche Maschinen im KAV werden mittels MS SCCM verwaltet, dessen Funktionsfähigkeit nicht eingeschränkt werden darf. Sämtliche Maschinen im KAV sind in einem Active Directory eingebunden. Die Software am Client muss frei von Kopierschutzeinrichtungen, CPU-Nummern, Datums-, Programmsperren oder ähnlichen nutzungsbeschränkenden Routinen sein. Die Software muss frei von Viren, sonstiger Malware und anderer Anomalien sein. Bei Updates müssen jene Konfigurationseinstellungen erhalten bleiben oder als Default vorgeschlagen werden, die bis vor dem Update gültig waren. Neue Versionen der in der Norm „KAV-IT BN-002 Standard Betriebsumgebung genannten“ Produkte (z.B. MS-Windows,VMS, SQLServer) sind spätestens 6 Monate nach ihrer Freigabe des Herstellers durch die jeweilige Applikation (sofern sie dieses Basisprodukt benötigt) zu unterstützen. Wesentliche Voraussetzung für die Inbetriebnahme einer Applikationsdatenbank ist eine umfassende Beschreibung der Ansprüche hinsichtlich Verfügbarkeit sowie ein Mengengerüst, aus dem Platzbedarf, Zuwachs und Zugriffe hervorgehen. 2. Server Applikationen 2.1. Implementation Applikationsservices sind Programme, die eigenständig als Windows-Services im Service Control Manager (SCM) registriert sind und auch zur Laufzeit eigenständig das Handling der SCM-Messages übernehmen. Alle permanent laufenden Programme unter Windows, die einen kontinuierlichen Dienst versehen, sind als derartige Windows-Services zu implementieren und nicht als Programme, die einen ständig interaktiv eingeloggt habenden User benötigen. Dediziert ausgenommen von dieser Richtlinie sind Programme, die nur im Kontext eines solchen Services (z.B. Scheduler) zu definierten Zeitpunkten hochgestartet werden und nach zeitlich (sehr) beschränkter Laufzeit wieder terminieren. 2.2. Installation Für die Auslieferung von Applikationsservices gelten grundsätzlich die in der Richtlinie für Savesets (siehe „Savesets“) genannten Bedingungen, wobei zusätzlich besonders darauf Rücksicht zu nehmen ist, dass: • jedes Saveset als automatisch installierbares Paket (keine ZIP-Files) ausgeliefert wird und • sämtliche, bei der Installation benötigten Parameter, im Zuge der Installation interaktiv erfragt werden (z.B. Installationsort, User, ...). Die Software darf keinerlei systemweit definierte Einstellungen auf dem Betriebssystem verändern oder Standardprogramme beeinflussen (z.B. Virenscanner). Clusterfähigkeit Zur Erhöhung der Ausfallssicherheit oder Skalierbarkeit muss jedes Applikationsservice, welches • lokal zur Laufzeit generierte Daten hält, im Cluster; Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 4 von 12 DVR: 0000191 • 2.3. über keine lokalen, zur Laufzeit generierten Daten verfügt, in einer Serverfarm lauffähig sein. Verträglichkeit Serverweite Ressourcen und Settings sind so zu verwenden, dass die Lauffähigkeit anderer, das Environment mitbenutzender Applikationen nicht nachhaltig negativ beeinflusst wird. Es kann nicht von der Verfügbarkeit einer dedizierten Maschine (Server) pro Applikation ausgegangen werden. 2.4. Mandantenfähigkeit Die Software muss, da der Betrieb mehrerer Applikationen mit gleicher Plattform (Datenbank, Betriebssystem) auf einer Serverkonfiguration möglich sein muss, mandantenfähig sein. Auch muss die Applikation für mehrere Anstalten auf einem zentralen Rechner lauffähig (mandantenfähig) sein. 2.5. Administration Zum Setzen der für die Lauffähigkeit des Services nötigen Parameter müssen durch das Setup erfolgen bzw. abgefragt werden. Alle Details über diese Parameter müssen in einem Installation Guide entsprechend ausführlich dokumentiert sein. 2.6. Zugriffssicherheit Der Gebrauch verbundweiter Applikationen ist durch Einsatz eines geeigneten Schutzmechanismus derart abzusichern, dass nur von autorisierter Stelle jene Berechtigungen vergeben werden können, die für einen erfolgreichen Daten- oder Systemzugriff im Rahmen der Applikation erforderlich sind. 2.7. Fehlerbehandlung Kritische Fehlerfälle müssen durch Ausnahmebehandlung abgefangen werden. 2.8. Logging Sämtliche Informationen über ungewöhnliche Vorkommnisse zur Laufzeit, die geeignet sind • eine Beeinträchtigung des laufenden Betriebs allgemein, • eine spezifische Disfunktion (z.B. userbezogen) oder • die Nichtverfügbarkeit benötigter Ressourcen anzuzeigen, haben via Event-Logging hinreichend detailliert, um eine gezielte Störungsbehebung zu ermöglichen, im Application-Log der lokalen Maschine festgehalten zu werden. Dabei erhalten Ereignisse, die einen Service-Restart (oder einen Boot der Maschine) nötig machen, um grundsätzliches Funktionieren des Programms weiterhin zu ermöglichen, den Status: Error; Ereignisse, welche möglicherweise nur temporäre Beeinträchtigungen anzeigen, den Status: Warning. Der Rest (Start, Stop - gewollt, ...) den Status: Information. 2.9. Sicherheitslogging Zur Nachvollziehbarkeit von Client-Server-Interaktionen ist ein bei Bedarf einzuschaltendes, serverseitiges, fallbezogenes Logging zu implementieren. Zur Auswertbarkeit muss das Logging auf Filebasis im CSV-Format erfolgen und es müssen die mitzuloggenden Informationen durch den Operator aus einer abgestimmten Menge von Parametern frei wählbar sein. 2.10. Timeouts Um eine permanente Beeinträchtigung der zum Service gehörenden Clientsoftware, über die der Dienst angesprochen wird, zu verhindern, muss die Möglichkeit der Konfiguration eines (Request-)Timeouts existieren, nach Ablauf dessen die Bearbeitung des Requests in jedem Fall terminiert. Derartige Timeouts haben im Eventlog festgehalten zu werden (als Warning). Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 5 von 12 DVR: 0000191 3. Client Applikationen 3.1. • • • • • • • 3.2. • • • • • • • • • • • • • • 3.3. • • • Features der Software Software muss mindestens 32-Bit Struktur aufweisen. Die Software muss so konfigurierbar sein, dass Ressourcen im Netz nur via FQDN angesprochen werden. Alle Daten, welche nicht mehr in kurzer Zeit wiederhergestellt werden können, müssen auf einem File-Server gespeichert werden. User-bezogene Daten sind am Home-Directory des Users abzulegen. Falls Client Software auf Windows Terminalservern laufen soll (siehe eigene Kategorisierung weiter unten), muss dies seamless unter Citrix möglich sein. Für einen fehlerfreien Betrieb der Software dürfen keine speziellen Rechte oder Modifikationen der Filesecurity erforderlich sein. Die Software muss mit normalen Userrechten betreibbar sein (kein Hauptbenutzer oder Administrator) Es dürfen keine zum Betrieb einer Applikation notwendigen Parameter in userspezifischen Teilen lokal gespeichert werden. WEB Server Dienste (IIS, Apache, etc.) dürfen nur auf Serversystemen installiert werden und keinesfalls auf Clients. Installation Die Software muss immer in Form kompletter Savesets ausgeliefert werden. Die Auslieferung einzelner Programteile (z.B. durch Patches) oder einzelner Files eines Savesets ist unzulässig. Die Installationroutine muss skriptfähig sein und dadurch silent und unattended durchgeführt werden können. Alle nötigen Installationsparameter sind während der Installation durch die Installationsroutine zu setzen. Eine Interaktion während des Installationsvorganges darf nicht erfolgen. Danach (bzw. nach einem Neustart des Rechners) muss die Applikation ohne weitere Eingriffe fehlerfrei funktionieren. Es ist darauf zu achten, daß die verschiedenen Serverfunktionalitäten auf verschiedenen Maschinen laufen können: Alle Databases auf einem Server, alle FileShares auf File-Server, etc. Für Client-Server Applikationen muss für Server-Kommunikationen ein TCP-Alias (CNAME) angefordert werden. Die Clientapplikation spricht den Server dann ausschließlich unter diesem Namen an. Clientsoftware darf nur mittels der definierten Verteillogik des MS-SCCM auf Clients aufgebracht werden. Lieferung der Software als MSI-Paket wird bevorzugt Die Lieferung hat inklusive Deinstallationsroutinen zu erfolgen Die Softwareinstallation ist in der Registry zu dokumentieren Es ist die Versions-, Release- oder Build-Bezeichnung eindeutig zu kennzeichnen. Die Software darf keinerlei systemweit definierte Einstellungen auf dem Betriebssystem verändern oder Standardprogramme beeinflussen (z.B. Virenscanner). Dies gilt auch für benutzerweite Securityeinstellungen, Policies, etc.(z.B. Internet Explorer Settings oder Einstellungen für Word Macros). Installations Source Alle zur Installation nötigen SW-Teile bzw. Konfigurationsfiles müssen am entsprechenden Softwareserver abgelegt sein. Die gesamte Konfiguration der Applikation muss im Commandfile bzw. dem entsprechenden Skriptfile im Setup enthalten sein. Zugriffssicherheit Der Zugriff ist via NT-Usergroups zu regeln. Der Zugriff auf Datenbanken - sofern nicht durch "KAV-IGV igvUser COM Object" geregelt - hat via NT-Authority zu erfolgen. Auf der Datenbank sind ebenfalls die NT-Usergroup(s) einzutragen. Somit müssen Useränderungen nur in der NT-Usergroup erfolgen (und nicht zusätzlich auf den Datenbankservern) Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 6 von 12 DVR: 0000191 • • • • • • • • • • Bei KAV-IT Applikationen erfolgt der Zugriff ausschließlich über das zentrale "KAV-IGV igvUser COM Object". Lizenzeintragungen Nur lokal zu installierende oder rechnerspezifische Licence Keys sind nicht zulässig. Dongle Dongles, die nicht nur für den Betrieb eines SW-Produktes, sondern bereits bei der Installation lokal verfügbar sein müssen, widersprechen der Forderung nach unattended installation und sind daher nicht erlaubt. Erlaubt sind sogenannte Netzwerkdongles, d.h. Dongles, die auf einem Server im Netz plaziert werden können. Elektronische Signatur ActiveX-Controls müssen vom SW-Hersteller mit einem gültigen Zertifikat signiert sein und als vor-installierbares Saveset beigestellt werden. Treiber müssen vom SW-Hersteller mit einem gültigen Zertifikat signiert sein und sollen zusätzlich eine MS-Zertifizierung aufweisen. 4. Kategorisierung beim Einsatz von Client Applikationen und virtuellen Desktopumgebungen Für den Einsatz von Client-Applikationen stehen im Wesentlichen 3 Betriebsumgebungen zur Verfügung.Die Entscheidung über den Einsatz für Applikationen zu den Varianten 2 und 3 sowie dem Einsatz von virtuellen Desktopumgebungen werden durch die KAV-IT getroffen. Grundsätzlich werden Applikationen nur auf einer der 3 folgenden Varianten betrieben: 1. Einsatz am FAT-Client (Standardvariante) Darunter fallen einerseits Bestandteile der Standard Images. (zB.: Office, Acrobat Reader...) und andererseits Applikationen, welche - wie bisher via SCCM (SMS) – zusätzlich aufgebracht werden. Damit soll zum Ausdruck gebracht werden, dass Bestandteile der Standard Images am FAT-Client nicht zusätzlich vom TS gepublished werden. 2. Einsatz am Terminal-Server Folgende Kriterien müssen diese Applikationen erfüllen: • Interprozesskommunikation mit impuls.kis • Richtlinienkonforme Verteil- und Updatelogik (zB.: kein Selfupdate im Benutzerkontext) • Eine hohe Einsatzrate (>1000 Arbeitsplätze im KAV) • Richtlinenkonforme Systemvorraussetzungen Wenn die Erstellung eines Installationspaketes erforderlich ist, dann muss bereits bei der TV die Möglichkeit der Installationspaket-Erstellung mitberücksichtigt werden. IT281 baut auch für den TS Clientpakete. Falls diese im TS-Umfeld nicht funktioniert, dann ist die enge Zusammenarbeit mit IT264 erforderlich. Für diesen Ablauf ist der HASI-Workflow anzupassen. Weiters sind TS-Pakete so zu gestalten, dass diese nicht auf einem Client installiert werden können. (z.B. Steuerung über die OU). 3. Einsatz in virtueller Umgebung (Applikationsvirtualisierung) Folgende Kriterien müssen diese Applikationen erfüllen: • Sonderapplikationen aufgrund von Inkompatibilitäten zu anderen Anwendungen • Sehr geringe Verbreitung • Mögliche Realisierung für die Bereitstellung von Destops • Published MSTSC • Desktopvirtualisierung Mögliche Einsatzvarianten für virtuelle Desktopumgebungen sind • Fernwartungszugänge • Test- und Migrationsarbeitsplätze • Telearbeitsplätze • Bereitschaftsarbeitsplätze • Entwicklerarbeitsplätze Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 7 von 12 DVR: 0000191 5. Savesets (SW Packages) Dieser Leitfaden beschreibt den prinzipiellen Aufbau eines Savesets, durch das eine Inbetriebnahme auf den Servern oder Clients des KAV ermöglicht wird. • • • • • • • • • • • • • • • • • Das Saveset ist mittels Microsoft Standard MSI bzw. KAV-Shield (für KAV-IT eigene Produkte) in der aktuellen Version zu schnüren. Jedes Saveset hat als automatisch installierbares Paket (z.B. InstallShield; nicht jedoch als ZIP-File) ausgeliefert zu werden. Beinhaltet die Installation mehrere Applikationsteile (zB. WEB, SQL, Client, usw.), so müssen diese Teile im Saveset einzeln installierbar sein. Für jeden Saveset-Teil muss dokumentiert sein, bei welchen Versionssprüngen der entsprechende Teil installiert werden muss. Die Installationsanleitung ist in der Form mitzuliefern, dass die Texte ohne Verwendung einer Textverarbeitungssoftware lesbar sind, also .rtf, .chm, o.ä., nicht jedoch .doc. Die Produktabhängigkeiten sind jeweils pro Savesetteil zu dokumentieren (ProductList.txt). Das physikalische Directory, auf dem die Applikation installiert wird, hat frei wählbar zu sein. Spezielle Settings, die zum Installationszeitpunkt zu treffen sind (wie z.B. Pfadangaben, DB-Verweise, DB-Accounts, Verweise auf externe Services wie FTP, RFC, ...), sind bei der Installation interaktiv zu erfragen und automatisch in die Konfigurationsdatenbestände einzuarbeiten. Serverseitige Implementierungen von COM-Schnittstellen haben sich bei der Installation vollständig selbst zu registrieren. Außerdem sind sämtliche derartige COM-Interfaces mitsamt ihren CLSIDs in der Installationsdoku schriftlich festzuhalten. Berechtigungen resp. Berechtigungsbeschränkungen für Applikationen müssen entweder via File-ACL oder über "KAV-IGV igvUser COM Object" steuerbar sein. Zusätzlich zur Applikation benötigte Basiskomponenten müssen vor der eigentlichen Installation der Applikation selbst automatisch zur Installation gebracht werden, wobei dies durch eine bestätigende Abfrage zu steuern ist. Jedes Saveset hat bei seiner Ausführung ein lesbares Protokoll anzulegen, in dem zumindest vermerkt sind: Zeit der Installation, installierte Files, getätigte Registry-Einträge, sowie die Versionsnummer der installierten Applikation. Jedes Saveset hat zusätzlich zur Installationsdokumentation auch ein geeignetes Betriebshandbuch zu enthalten, welches insbesondere Erklärungen zu Ursache und Maßnahmen zur Beseitigung der, bei Installation und Betrieb möglichen applikationseigenen Fehlercodes, liefert. Es dürfen keine Teile enthalten sein, die die Verwendung einer bestimmten physischen oder logischen Maschine vorherbestimmen. Jeder Teil des Savesets hat über eine entsprechende vollständig und sauber funktionierende Deinstallationsoption zu verfügen. Die Installroutine muss mindestens eine scriptfähige 32-Bit Struktur aufweisen. Es ist die Installroutine MSI Installer >= 4.0 zu verwenden – begründete Ausnahmefälle müssen gesondert abgehandelt werden. Es ist darauf zu achten, dass es bei den aktuellen Betriebssystemen (Windows 7, Windows Server 2008) erhöhte Security Settings auf File- und Registryebene gibt. Die Veränderung der Security einzelner Pfade ist nicht zulässig – begründete Ausnahmefälle sind im Vorfeld mit den Installationsteams abzustimmen. 6. Dokumentation • • Bei Inbetriebnahme ist ein entsprechendes Betriebshandbuch (Template KAV-IT) von der betreibenden OrgEinheit zu erstellen. Dieses ist mindestens einmal jährlich auf Aktualität zu prüfen. Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 8 von 12 DVR: 0000191 • Zentraler Ablageort ist das Sharepoint System der KAV-IT unter http://themen.wienkav.at/betriebshandbücher 7. Die einzelnen Teile im Detail 7.1. • • • • • • • • Der Web-Teil eines Savesets ist so zu gestalten, dass das Produkt gleichermaßen lauffähig ist, sowohl mit eigenem Virtual Server als auch im Rahmen eines Virtual Directorys. Wird ein "KAV-IGV igvUser COM Object"-Applikationseintrag benötigt, so hat als ExtraSavesetteil ein Set von Files mitgeliefert zu werden, durch dessen Import im "KAV-IGV igvUser COM Object"-Wartungsclient die entsprechenden "KAV-IGV igvUser COM Object"Datenbankeinträge automatisch angelegt werden. Von der Webapplikation selbst erzeugte oder verwaltete statische Datenbestände (Dokumente) müssen auf andere physikalische Maschinen verlagerbar sein, ohne den Betrieb der Applikation dadurch zu beeinträchtigen. Am Client laufende ActiveX-Komponenten, die im Saveset enthalten sind, haben je nach Gefährdungsgrad als safe/not safe for Initialization resp. Scripting markiert und vom Hersteller digital signiert zu sein. Zusätzlich hat die Installationsdokumentation auch einen Hinweis auf den Komponentenhersteller (Link) zu enthalten. Letzteres gilt insbesondere bei der Verwendung von clientside ActiveX-Komponenten von Fremdherstellern. Sofern möglich, hat eine Applikation zur Erbringung einer bestimmten Funktionalität das vorhandene Runtime-Environment zu verwenden, anstatt eigene, proprietäre Komponenten einzusetzen. Komponenten, die von mehreren Web-Applikationen gleichzeitig verwendet werden (BasisSW), sind als eigenständiges Saveset auszuliefern. Jede Webapplikation und deren Saveset muss sich im Zuge der Ausführung bei der Verwendung von Shared Resources fair verhalten (kein exklusives Locking, Maschinenrestart, ...). Anderenfalls ist das angesprochene Verhalten im Installationsrespektive Betriebshandbuch entsprechend zu dokumentieren. Keinesfalls dürfen Savesets codierte resp. verschlüsselte Scripts und HTMLs jedweder Art enthalten. 7.2. • • • • • • • • WEB-Teil SQL-Teil DB-Anlage: Datenbanken werden von den DBAs (Datenbankadministratoren) angelegt und frei benannt. DB-Optionen: DB-Optionen werden von den DBAs gesetzt und sind weder von der Applikation noch von Installationsscripts zu verändern. DB-Modell: Es wird grundsätzlich das Recovery Modell „Full“ verwendet. Die Datenbanken werden im Native Mode (d.h. nicht in einem Compatibility Mode betrieben. Collations: Es wird außer in begründeten Ausnahmefällen die SQL-Server Defaultcollation (Latin1_General_CI_AS) verwendet. Strukturaufbau: Der strukturelle Aufbau der DB erfolgt durch SQL-Scripts, die vom SWHersteller zu liefern sind und sowohl einen Neuaufbau als auch ein Upgrade der DB zulassen. Dies betrifft Objekte wie Tables, Views, Stored Procedures, Functions, Indizes, Constraints, Trigger usw. Skripts: Anzahl und Unterteilung der Scripts sind dabei übersichtlich und in einem sinnvollen Verhältnis zum Installationsumfang zu halten. Extreme wie z.B. 5-stellige Zeilenanzahlen in einem Script oder sehr hohe Scriptanzahlen sind zu vermeiden. Als Richtwert sollte eine einstellige Scriptanzahl gelten. Es darf jedoch kein automatisches Deployment wie Setup verwendet werden. Die Scripte werden ausschließlich durch die DBAs am SQL-Server ausgeführt. Strukturelle Veränderungen: Strukturelle Veränderungen der DB sind nicht im laufenden Betrieb vorzunehmen, sondern Gegenstand eines Upgrades im Zuge einer neuen Version. Eine DB darf ihren strukturellen Aufbau nur durch eine einzige Applikation erhalten. Befüllung: Mitgelieferte Inhalte der Datenbank werden per Script (insert statements) eingebracht. Erscheint dies aufgrund der Datenmengen nicht sinnvoll, wird durch die DBAs Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 9 von 12 DVR: 0000191 • • • • • gemeinsam mit dem Softwarehersteller eine geeignete Befüllungsmethode (DTS, XML, o.ä.) gewählt. Ausführbarer Code: Extended Stored Procedures sowie jegliche andere Art von ausführbarem Code sind keinesfalls auf einem SQL-Server einzubringen. Security: Es ist grundsätzlich über NT-Security auf die DBs zuzugreifen. Sollte aus technischen Gründen ein Zugriff per SQL-Login unumgänglich sein, so ist ausnahmslos das sogenannte „UserObject“ zu verwenden. Dies ist eine KAV-interne Applikation bzw. Schnittstelle, über die bestimmte Berechtigungen auf gesondertem Wege gehandhabt werden. Berechtigungen: Die Zugriffssteuerung ist durch Datenbankrollen abzudecken. Die Verwendung der Standardrollen datareader und datawriter ist zulässig. Falls darüber hinausgehende Rechte erforderlich sind, wie z.B. für die Verwendung von Stored Procedures, ist eine oder mehr entsprechende Datenbankrollen zu definieren. Applikationsrollen sind nur in begründeten Ausnahmefällen und nur nach Abstimmung mit den DBAs zulässig. Eine Verschachtelung der Rollen (Rolle A ist Mitglied von Rolle B) ist dabei aus Gründen der Übersichtlichkeit zu unterlassen. Die für die Applikation benötigten Berechtigungen sind in der Installationsanleitung entsprechend zu dokumentieren. SQLStandardrollen (z.B. public) dürfen nicht verändert werden. Es darf keine Berechtigung vergeben werden, die eine Strukturveränderung der DB ermöglicht (z.B. dbo). Applikationsuser, die im Betrieb verwendet werden, dürfen keine DB-, Schema- oder Objectowner sein. Dafür sind ausschließlich SQL-interne User (sa, dbo, DBAs etc.) zu verwenden. Mandantenfähigkeit: Kommt eine Applikation in mehreren logischen Einheiten (Anstalten, Abteilungen) zum Einsatz, ist eine wienweite DB zu verwenden. In berechtigten Ausnahmefällen kann der Einsatz einiger (weniger) DBs sinnvoll erscheinen, wie z.B. die Auslagerung von selten benutzten Altdaten in eine Archiv-DB. Logische Einheiten sind über ein Berechtigungskonzept gegen einen gegenseitigen Zugriff abzsichern. Linked Server: Linked Server sind nicht zu verwenden, außer es besteht technisch keine andere Möglichkeit. In diesem Fall hat die Form und Ausprägung, insbesondere Benennung und Parametrierung der Maßgabe der DBAs zu folgen und entsprechend dokumentiert zu werden. 7.3. • • • • • • • • • ORACLE-Teil Datenbanken werden durch die Datenbankadministratoren der KAV-IT erstellt. Die Applikationen müssen auf separaten Servern laufen und unabhängig vom Betriebssystem der Datenbankserver sein. Datenbanken werden im Archive Mode betrieben. Die Sicherung der Datenbanken erfolgt über Online Backups. Bei Erstinstallationen wird mit dem Hersteller festgelegt, ob eine Applikation eine eigene Datenbankinstanz oder eigene Schematas erhält. Es besteht nicht automatisch das Recht auf eine eigene Datenbankinstanz. Das Datenbankdesign ist nach Installation im Betrieb unverändert beizubehalten, d.h. Datenbankobjekte sind zu einem späteren Zeitpunkt nicht zu erstellen, zu verändern oder zu löschen. Ein derartiger Vorgang ist nur nach vorangegangener Abstimmung mit dem Datenbankverantwortlichen der KAV-IT oder bei Einsatz einer neuen Version zu tätigen. Der strukturelle Aufbau erfolgt durch die mitzuliefernden SQL-Scripts, die sowohl eine Neuinstallation als auch ein Update eines bestehenden Datenbestandes unterstützen müssen. Diese Scripts werden durch die Datenbankadministratoren der KAV-IT geprüft und durchgeführt. Mitgelieferte Inhalte der Datenbank werden per Script („insert“ Statements) eingebracht. Erscheint dies aufgrund der Datenmengen nicht sinnvoll, wird durch die DBAs der KAV-IT gemeinsam mit dem Softwarehersteller eine geeignete Befüllungsmethode (CSV, XML, o.ä.) gewählt. Der verwendete Zeichensatz muss vor Erstinstallation bekanntgegeben werden. Der Standardzeichensatz bei Applikationen in der KAV-IT ist WE8ISO8859P15 (Westeuropäisch mit Eurozeichen). Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 10 von 12 DVR: 0000191 • • • • • • • • • • • • • • Datenbankobjekte müssen in unabhängigen Applikationsschematas erstellt werden. Die Passwörter für diese User sind nur den Datenbankadministratoren der KAV-IT bekannt und können von diesen zu jedem Zeitpunkt geändert werden. Datenbankobjekte dürfen nicht im Schema des zugreifenden Users liegen. Die Applikation darf keine DBA/SYSDBA Berechtigung während der Laufzeit verwenden. Sollten Tätigkeiten vor der Installation erforderlich sein, die solche Berechtigungen nötig machen werden diese Tätigkeiten von den Datenbankadministratoren der KAV-IT ausgeführt. Die Applikation darf keine Datenbankobjekte im SYSTEM/SYSAUX Tablespace anlegen bzw. halten. Um eine gegenseitige Beeinträchtigung auszuschließen und die Integrität der Strategie von Datenbankabfragen zu gewährleisten darf der strukturelle Aufbau und die Veränderung einer Datenbank nur durch 1 Applikation erfolgen. Um ein getrenntes Restoren der Applikationen innerhalb einer Datenbank zu gewährleisten ist es erforderlich, dass die Applikationen separate, voneinander unabhängige Tablespaces verwenden. Dies schließt eine Verwendung von Sammeltablespaces wie zum Beispiel USERS aus. Das Erzeugen von Tablespaces erfolgt über Oracle Managed Files (OMF). Die Zugriffssteuerung auf Datenbankobjekte ist mittels einer entsprechenden Rolle zu definieren. Eine Verschachtelung der Rollen (Rolle A ist Mitglied von Rolle B) ist dabei aus Gründen der Übersichtlichkeit zu unterlassen. Die – für die Applikation – benötigten Berechtigungen sind im Installationguide entsprechend zu dokumentieren. Die Vergabe von ANY Berechtigungen ist zu unterlassen. Datenbankoptionen werden ausschließlich durch die Datenbankadministratoren der KAV-IT gesetzt, d.h. sie werden von Applikationsseite weder zum Installationszeitpunkt noch zur Laufzeit verändert. Bei der Namensauflösung (TNS) ist das zentrale Ldap Verzeichnis (AD) des KAV zu verwenden. Eine Verwendung des Characters „.“ ist in der TNS Bezeichnung zu unterlassen. Eine entsprechende RAC (Oracle Real Application Cluster) Tauglichkeit muss – in Abhängigkeit vom Verfügbarkeitsanspruch der Applikation - gewährleistet sein. Die Option „nologging“ für Tabellen und Indizes ist zu unterlassen. Exp bzw. expdp werden nicht als Sicherungsmethode verwendet. Daten Manipulationen welche ein Verwenden dieser Tools vorsehen sind mit den Datenbankadministratoren der KAV-IT abzusprechen. 7.4. • • • • • Client-Teil Es ist darauf zu achten, dass verbundweit nur ein Softwarepaket gleichen Namens zum Einsatz kommt. D.h. sollte das SW-Produkt in verschiedenen Anstalten installiert werden UND in den einzelnen Anstalten unterschiedliche Installationsparameter benötigen, so ist dies in geeigneter Form zu berücksichtigen Ein entsprechendes und funktionierendes InstallShieldSkriptfile (setup.iss) ist mitzuliefern. Dieses liefert dem InstallShield während einer "silent" Installation alle benötigten Installationsparameter. Analog hierzu beim Microsoft Installer: MSI-File. Die Installation des Clientteils muss ohne Interaktion eines Administrators erfolgen. Die Namensgebung der Datenbanken und Logins obliegt dem DBA. Der Betrieb des Clientteils muss unter jeder Betriebssystemversion mit den Rechten eines „Benutzers“ (User) möglich sein. Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 11 von 12 DVR: 0000191 AnsprechpartnerIn Leiter IT265 Ing. Peter Barnert Telefon: E-Mail: +43 1 40409 66771 [email protected] Oktober 2015 Besuchen Sie unsere Homepage www.wienkav.at/ikt Impressum: Wiener Krankenanstaltenverbund Informationstechnologie Stadlauer Straße 54 A-1220 Wien Dokument: KAV-IT BN-003 Software Basisanforderungen 2016.docx Vertraulichkeitsklasse: offen Dokumentengruppe: Betriebsnormen Seite 12 von 12 DVR: 0000191
