06-1_Anlage 1A _ RL_techn_Rahmenbedingungen_V1.4_Anlage.pdf

[Seite 1]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

Anlage Technische Rahmenbedingungen

Nachfolgende betriebliche und technische Rahmenbedingungen sind für alle IT-gestützten Verfahren des LfULG bindend, um die Integrationsfähigkeit in die vorhandene IT-Infrastruktur zu gewährleisten. Sie gelten für fertige Softwareprodukte, für das LfULG fremdentwickelte und im LfULG entwickelte Software.

IT Gesamtstruktur

Die Mitarbeiter des LfULG arbeiten an über 30 Standorten. Diese Standorte sind über ein pri- vates Datennetz (Sächsisches Verwaltungsnetz) verbunden. Dieses Netz benutzt private IP Adressen und ist nur an einem zentralen Punkt im Freistaat über Gateways mit dem Internet verbunden (kein NAT möglich). In der Regel sollte die gesamte Kommunikation über https- Verbindungen oder E-Mail (mit Authentifizierung am Mailserver) mit dem Internet erfolgen. Das Sächsische Verwaltungsnetz ist in einzelne IP-Netze segmentiert, an den Netzübergän- gen kommen Firewalls zum Einsatz. Außerdem sind die lokalen Firewalls auf Servern und Clients aktiviert. Zukünftig müssen alle IT-Services auch in einer Zero-Trust-Security-Infra- struktur nutzbar sein. Die IT-Verfahren werden grundsätzlich zentral bereitgestellt. Dafür sind zwei Rechenzentren im LfULG vorhanden. Nicht alle vom LfULG unterstützten Basistechnologien werden an beiden RZ gleichzeitig betrieben. Kern der Infrastruktur bilden Windows-Server sowie MS-SQL, Post- greSQL und Oracle Datenbanken. Die Infrastruktur ist weitgehend virtualisiert. Verfahren, die auf den zentralen e-Government Komponenten des Freistaates aufbauen, wer- den zentral im RZ des SVN (Dienstleister) betrieben. Der Betrieb von Verfahren als lokale bzw. dezentrale Lösung kommt nur in Einzelfällen in Be- tracht. Diese müssen dann aber in einer Virtual Desktop Infrastructure (VDI) lauffähig sein oder eine Anwendungsvirtualisierung unterstützen. Im Freistaat kommt ein zentrales Active Directory von Microsoft mit einer Vielzahl von Sub- Domänen zum Einsatz, d.h. Nutzer und/oder Ressourcen können in verschiedenen Domänen sein. Schemaerweiterungen sind nur landesweit möglich und deshalb nur in Ausnahmefällen umsetzbar. Für die Clientkomponenten steht in der Regel ein Fat-Client zur Verfügung. Dieser wird ent- weder lokal (Arbeitsplatzcomputer) oder remote (VDI, Citrix Virtual Apps and Desktops) zur Verfügung gestellt. Das Management der Clients erfolgt automatisiert, d.h. die Installation und Konfiguration muss skriptbasiert möglich sein. Strategisch sollte auf dem Client nur die Dar- stellungs- und Eingabeschicht unabhängig von einem speziellen Betriebssystem und der Ge- räteklasse laufen. Die Nutzung der Cloud, insbesondere eine Datenspeicherung außerhalb der EU, ist für hoheit- liche Aufgaben grundsätzlich nicht zulässig. Ausnahmen sind mit der betrieblichen Daten- schutzbeauftragten des LfULG abzustimmen.

Detaillierte Anforderungen sind in den nachfolgenden Teilen aufgeführt. Teil A definiert allgemeine Anforderungen für alle IT-Leistungen. Teil B findet immer dann Anwendung, wenn für das LfULG eine Software erstellt wird. Teil C legt die konkreten Versionen von Betriebssystemen bzw. Datenbanken fest.

Version 1.4 Anhang Seite 1 von 13

[Seite 2]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

Teil A Allgemeine Anforderungen

SERVER

 Als Serversysteme kommen grundsätzlich Microsoft-Server zum Einsatz. Die aktuellen Versionen finden sich in Teil C  Die Standardsysteme haben einen aktuellen Patch-Stand.  Alte Systeme und Betriebssysteme ohne Support werden nicht unterstützt.  Alternativ kann in Abstimmung mit Abteilung 11 Ubunto-Linux eingesetzt werden.  In der Regel werden Serversysteme über eine Virtualisierung Plattform bereitgestellt

CLIENTS

 Als Clients kommen Microsoft Windows Systeme zum Einsatz.  Clientanwendungen müssen sowohl auf klassischen Client-Systemen laufen, als auch auf MS-Terminalservern mit Citrix Virtual Apps -Aufsatz (Multiuser-Umgebung).  Als Anzeigegeräte sind aktuell folgende Systeme im Einsatz: o 24“-Monitoren 1920 x 1200 Bildpunkte (WUXGA) o 27“-Monitoren 2560 * 1440 Bildpunkte (QHD,) o 34“-Monitoren 3440 x 1440 Bildpunkte (WQHD i) o außerdem noch Systeme mit der Auflösung 1920*1080 (FHD)

5.1.1 Vorgaben für Softwareprodukte

 Für Anwendungen ist grundlegend eine AD-Kopplung für die Benutzersteuerung umzu- setzen. Dabei muss das Multidomänenmodell (mehrere AD-Domänen in einem AD-For- rest) unterstützt werden. Für Anwendungen ist grundlegend eine AD-Kopplung für die Benutzersteuerung umzusetzen. Die Authentifizierung muss mindestens der Vorgabe zum Authentifizierungsprotokoll in Teil C genügen. Alle Fachverfahren und Systeme, die eine Authentifizierung via Domänencontroller durchführen, müssen so ausgelegt sein, dass sie redundant mindestens gegen zwei DCs einer Domäne authentifizieren können. Dies bedeutet im Konkreten zwei Einträge (primär/sekundär) von DC IP-Adressen in den entsprechenden Konfigurationen. Hinweis: Für Anwendungen, die zum Großteil von Externen genutzt werden (z.B. DIANA-Web, Online-GIS), kann von dieser Vorgabe abgewichen werden.

 Um eine einfache Integration der Software sicherzustellen sind im LfULG vorhandene Bibliotheken, Frameworks und Softwareprodukte zu verwenden, siehe Teil C.  Bei Serveranwendungen ist i.d.R. zu jeder Produktivumgebung auch eine Testumgebung vorzusehen.  Erfolgt die Anbindung einer Anwendung an Dienste im Internet (z.B. Clouddienste), dann müssen die definierten Zugangswege über das SVN (i.d.R. https über Proxy/ Reverse Proxy) genutzt und eingehalten werden.  Bei Nutzung einer Mailschnittstelle müssen die Anwendungen „authentifizierten Mailver- sand“ unterstützen.  Lieferung einer schriftlich dokumentierten Installations- und Deinstallationsroutine.  Grundsätzlich müssen alle einsetzten Softwareprodukte virtualisiert betrieben werden können. Dabei sollten reine Fachapplikationen als freigegebene Citrix-Applikationen lauf- fähig sein.

Version 1.4 Anhang Seite 2 von 13

[Seite 3]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

Für Anwendungen auf Client-Systemen gelten folgende Standardanforderungen:

 Reine Clientapplikationen müssen in einer VDI-Umgebung betreibbar sein. Bei grafikin- tensiven Anwendungen muss ggf. eine Virtualisierung der Grafikkarte unterstützt werden.  Die Software ist in einem standardisierten Installer-Format zu liefern. Es sollte die Mög- lichkeit einer komplett automatisierten unbeaufsichtigten Installation bestehen.  Bevorzugt wird die Bereitstellung im Microsoft-Installer (.msi)-Format, Installationsan- passungen sind über Transforms-Files (.mst) zu ermöglichen.  Die Installation der Anwendungen muss in ein frei wählbares Verzeichnis erfolgen, in dem die lokale Gruppe der Benutzer die NTFS-Berechtigung Lesen besitzt.  Werden Anwendungen deinstalliert, müssen alle angelegten und nicht mehr benötigten Dateien entfernt werden. Alle Einträge in Systemdateien, die für das Produkt vorgenom- men wurden und nicht mehr benötigt werden, müssen Rückgängig gemacht werden. (APP.6.A13)  Die Anwendungen müssen ohne administrative Rechte des Anwenders voll lauffähig sein.  Lizenzen sollten automatisch einspielbar sein. Dies kann entweder über eine Einstellung im Rahmen einer unbeaufsichtigten Installation oder die Verwendung eines Lizenzser- vers geschehen. (externe Lizenzserver müssen über die Proxykette des SVN erreichbar sein)  Die Benutzeroberfläche der Anwendung muss den Normen der Arbeitsplatzgestaltung DIN EN ISO 9241 entsprechen. Dabei sind die Grundsätze der DIN EN ISO 9241 Teil 210 explizit zu beachten. Die Gestaltung basiert somit auf einem umfassenden Verständ- nis der Benutzer, Aufgaben und Arbeitsumgebungen. Der Auftragnehmer bzw. die Nut- zer sind während der Gestaltung und Entwicklung als iterativer Prozess einzubeziehen. Bei der Systementwicklung wird die gesamte User Experience berücksichtigt.  Unterstützung einer dem Stand der Technik entsprechenden Bildschirmauflösung.

WEBANWENDUNGEN  müssen „Proxy“-tauglich und „Reverse-Proxy“-tauglich sein  Webanwendungen müssen auf allen aktuell gängigen Webbrowsern lauffähig sein 7.  sollten gemäß responsivem Web-Design erstellt werden, d.h. dass das Layout der Seite für das jeweilige Ausgabemedium angepasst wird.  interne Webanwendungen sollten / im Internet bzw. für Dritte angebotene Webanwen- dungen müssen sich an den Styleguide-Vorgaben des Freistaat Sachsen orientieren https://www.styleguide.sachsen.de/

Mobilgeräte (Tablet, Smartphone)

 Als mobile Clients werden im LfULG Android-Geräte eingesetzt. Anwendungen für Mo- bilegeräte müssen auf der jeweils aktuellen Version lauffähig sein.  Anwendungen sollten primär als Webanwendungen mit responsivem Design entwickelt werden, um eine Unabhängigkeit von Geräten und Herstellern zu gewährleisten. Dies erlaubt weiterhin den schnellen Wechsel auf andere Plattformen.  Entwickelte Anwendungen für mobile Clients sind als APK-Datei zur Verfügung zu stellen.

7 Aktuell Edge, Chrome, Firefox, Safari, Opera

Version 1.4 Anhang Seite 3 von 13

[Seite 4]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

DATENBANKEN

 Als Datenbankmanagementsysteme müssen die bestehenden zentralen Datenbankma- nagementsysteme genutzt werden. Aktuell werden sind folgende im Einsatz: o Microsoft SQL-Server o Oracle Datenbankserver, o Open-Source-Datenbank PostgreSQL jeweils in den Versionen gemäß Teil C.  Eine lokale Datenbankinstallation ist nicht zulässig.  Bei Standardsoftware und bei der Neuentwicklung von IT-Verfahren ist auf die Verwen- dung des Microsoft SQL-Server oder PostgreSQL zu orientieren. Hinweis: Der Einsatz von Oracle in Neuverfahren bedarf einer gesonderten Abstimmung.

GEODATENSPEICHER  Das LfULG setzt für Geodateninformationssysteme eine ArcGIS-Umgebung mit Enter- prise Geodatabase basierend auf ESRI ArcGIS Server Basic (SDE) ein (Geofachdaten- banken).  Die Bereitstellung von Geodateninformationen für Drittanwendungen erfolgt auf der Ba- sis von OGC- bzw. ESRI-REST-Diensten über den ArcGIS Server Standard Enterprise.  Zudem setzt das LfULG die Cadenza Plattform der Firma disy Informationsgesellschaft GmbH8 ein. Das Informationssystem iDA (interdisziplinäre Daten und Auswertungen) ba- siert auf Cadenza und bietet dabei umfassende Funktionen zur Datenanalyse, Reporting und GIS. iDA integriert die ESRI-Umgebung über ESRI-REST-Dienste und setzt für Fachanwendungen auf einem Datawarehouse auf der Basis von Oracle auf. Sowohl in- tern als auch von extern bereitgestellte OGC-Dienste sind ebenfalls integriert.  Zur Editierung der Metadaten von Geodaten und Geodatendiensten wird der Metada- tenkatalog der sächsischen E-Government Plattform GeoMIS.Sachsen9 eingesetzt.

Vorgaben für Schnittstellen  Exportfunktionen in Textverarbeitungs- und Tabellenkalkulationssoftware müssen unab- hängig von der eingesetzten Office-Suite sein und eine Bearbeitung / Öffnung der expor- tierten Datei(en) mit anderen Office-Suite ermöglichen. Deshalb sind Software-unabhän- gige Dateiex-/-importformate zu nutzen (xml, csv, json…).  Von Extern hochladbare Dateien müssen auf Schadsoftware geprüft werden. Es ist die ICAP-Schnittstelle zu beschreiben, sofern ein IT-Verfahren Dateien von „außen“ hoch lädt.  Hochladbare Formate sind auf ein absolutes Minimum zu beschränken (Sicherheitssicht). Es sind in jedem Verfahren die konkreten Formate vorhabensspezifisch festzulegen. Die einzelnen Formate sind sicherheitstechnisch zu betrachten.  Keine Nutzung von lizenzpflichtigen Java-Modulen (z.B. OracleJava).

8 https://www.disy.net/de/ 9 https://geomis.sachsen.de/

Version 1.4 Anhang Seite 4 von 13

[Seite 5]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

Weitere Vorgaben zur Integration  Bei Serveranwendungen ist i.d.R. zu jeder Produktivumgebung auch eine Testumgebung vorzusehen.  Erfolgt die Anbindung eines Fachverfahrens an Dienste im Internet (z.B. Clouddienste), dann müssen die definierten Zugangswege über das SVN genutzt und eingehalten werden.

KONFIGURATION

 Die Grundkonfiguration sollte im Rahmen einer unbeaufsichtigten Installation erfolgen, entsprechende Einstellungen müssen der Installation als Parameter oder Konfigurations- datei mitgegeben werden.  Fach- und nutzerspezifische Einstellungen sollten innerhalb der Anwendung selbst erfol- gen.  Kennwortdaten sind nicht in der Anwendung zu speichern, sondern die Authentifizierung durch die geforderte AD-Kopplung zu realisieren.  Sollten im Ausnahmefall doch Kennwortdaten gespeichert werden, sind diese grundsätz- lich als Hashwert bzw. verschlüsselt abzulegen, wenn sie für definierte Automatismen benötigt werden.  Entwickelte Fachanwendungen müssen mit Hilfe von menschenlesbaren Konfigurations- daten, die in Abstimmung mit dem AG zu definieren sind, anpassbar sein. Dazu zählen beispielsweise Dateizugriffsverfahren und -parameter für die Ein- und Aus- gabe (lokaler Pfad, WebDAV, FTPS) und Datenbankzugriffsmechanismen (ODBC, JDBC, Oracle Service).  Die fachlichen Konfigurationsdaten, die für die Konfiguration durch den Fachadministra- tor vorgesehen sind, sollten nicht die Windows-Registrierdatenbank verwenden. SOFTWARE UND LIZENZEN VON DRITTANBIETERN Müssen  frei verfügbar sein oder  mit vorhandenen Lizenzen in Abstimmung mit dem AG abgedeckt werden oder  die Lizenz durch den AN beschafft und bezahlt werden. Detaillierte Festlegungen zu Lizenz- und Nutzungsrechten sind in den jeweiligen EVB-IT-Ver- trägen zu vereinbaren.

ANFORDERUNGEN AN DIE DOKUMENTATION

 Vom AN wird eine vollständige und nachvollziehbare Dokumentation bezüglich techni- scher Verfahrensbeschreibung, Installation, Administration und Anwendung der zu reali- sierenden Lösung erwartet, die einen reibungslosen Betrieb und ggfs. eine Weiterent- wicklung durch das LfULG ermöglicht.  Die Dokumentationen sind in menschenlesbarer Form auf geeigneten Medien bereitzu- stellen.  Eine in das IT-Verfahren integrierte Nutzerhilfe wird erwartet.

LOGGING

 Die Software sollte Möglichkeiten zum Logging bieten, um im Fehlerfall selbstständig Probleme beheben zu können bzw. aussagekräftige Logdaten an den AN senden zu können.

Version 1.4 Anhang Seite 5 von 13

[Seite 6]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

 In datenschutzrelevanten Anwendungen ist jede Aktivität (z.B. Lesen, Ändern, Kopieren, Löschen) mit Personenbezug und Zeitstempel zu protokollieren. In der Protokolldatei muss ersichtlich sein, wer wann welche personenbezogenen Daten in welcher Weise verarbeitet hat. In der Anwendung muss gewährleistet werden, dass die Protokolldateien nach einer konfigurierbaren Zeit automatisch gelöscht werden.

SICHERHEITSANFORDERUNGEN Das LfULG ist der Informationssicherheit verpflichtet. Zur Erreichung und Aufrechterhaltung eines angemessenen Schutzes ist der BSI-Standards zum IT-Grundschutz zu beachten.  Die eingesetzte Software muss aktuellen Sicherheitsstandards genügen.  Für Nicht-Standard-Software muss ein Sicherheitskonzept vorliegen.  Prinzipiell müssen sich die verwendeten IT-Systeme und Software an den aktuellen Stand der Technik halten. Sollten hier Vorgaben fehlen bzw. diese, z.B. bei Verschlüs- selungsalgorithmen, überholt sein, dann ist der jeweils aktuelle Stand der Technik zu nutzen.  Sofern personenbezogene/personenbeziehbare Daten verarbeitet werden, sind die Vor- gaben der DSGVO einzuhalten. Insbesondere müssen beachtet werden: o die Möglichkeit der Auskunftspflicht aller gespeicherten Daten und o das Recht auf Löschung  Müssen IT-Verfahren im Betrieb durch externe Partner unterstützt werden, z.B. mittels Fernwartung, dann sind die organisatorischen und technischen Zugangsmodalitäten frühzeitig unter Einbindung der A11 zu regeln.  Verschlüsselung der Kommunikationswege (mind. TLS 1.3 oder höher)  für standortübergreifenden Datenaustausch sind standardisierte Kommunikationsverfah- ren über HTTPS: SOAP, WebDAV, XML-RPC zu nutzen  NTLMv2, Kerberos, LDAPS

Version 1.4 Anhang Seite 6 von 13

[Seite 7]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

Teil B Zusatzanforderungen für die Softwareentwicklung

1. Anwendungen haben sich in die klassische 3-Schicht-Architektur (Client, Anwendung, Da- tenbank) zu integrieren.

 Client und Datenbank wurden bereits beschrieben. Für Datenbanken gibt es weitere Entwicklungsvorgaben in Teil C  Alle IT-Fachverfahren dürfen nur auf IT-Systemen (Betriebssysteme, Middleware, Standardsoftware) betrieben werden, die unter Herstellerwartung stehen und einen ak- tuellen Patch-Stand aufweisen.  Standardmäßig werden Verfahren auf Anwendungsservern betrieben. Als Webserver kommen dabei IIS- und Apache-Tomcat-Server zum Einsatz.

2. Die Nutzerverwaltung eines entwickelten IT-Fachverfahrens hat ausschließlich durch den Fachadministrator der Applikation zu erfolgen.

 Gemäß den Vorgaben zur AD-Integration ist für Anwendungen grundlegend eine AD- Kopplung für die Benutzersteuerung umzusetzen. Hier müssen lediglich die AD-Konten auf ihre Rollen in der Fachanwendung umgesetzt werden. Dabei müssen sie so aus- gelegt sein, dass sie redundant mindestens gegen zwei DCs einer Domäne authentifi- zieren können. Dies bedeutet im Konkreten zwei Einträge (primär/sekundär) von DC- IP-Adressen in den entsprechenden Konfigurationen.  Sollten die AD-Kopplung begründet nicht möglich sein, kann die Nutzerverwaltung im IT-Fachverfahren stattfinden. Die Nutzer sind dabei in der Datenbank des IT-Fachver- fahrens zu speichern und deren Passwörter sind sicher zu verschlüsseln, z.B. über eine dem aktuellen Stand der Technik entsprechende Hashfunktion.  Für Verfahren im Bereich Agrarförderung ist eine Ankopplung an das bestehende Sys- tem AdminX/CockPitX vorzusehen.

3. Wesentliche Kernpunkte einer Dokumentation entwickelter Software sind:

 Datenmodell inkl. graphischer Darstellung  Beschreibung der Datenbankfunktionalität (Rollenkonzept, SQL Skripte, Prozeduren, Funktionen),  Schnittstellenbeschreibungen,  Kommunikationswege und -beziehungen,  Programmablaufplänen,  Verzeichnis der Programme und Skripte etc.  Installationsroutine bzw. Skripte, Datenbankerstellungsskripte  Deinstallationsroutine bzw. Skripte zur vollständigen Entfernung  Kommentierte Konfigurationsdateien  Beschreibung der softwaretechnischen Maßnahmen zum Schutz personenbezogener Daten

4. Zusätzliche Dokumentation für interne Projekte (Quellcode ist Vertragsbestandteil)

 Dokumentierter Quellcode, inkl. Projektdatei der Entwicklungsumgebung  Quellcodes sind in menschenlesbarer Form (keine „Minifizierung“, nachvollziehbare Benennung von Klassen, Variablen, Funktionen usw.) bereitzustellen

Version 1.4 Anhang Seite 7 von 13

[Seite 8]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

5. Logging

 der AN ist verpflichtet, die Anwendung so zu konzipieren, dass diese zur Laufzeit ein aussagekräftiges Logfile mitschreiben kann. Der Umfang der Logdateien kann in ver- schiedenen Logstufen erfolgen. Die Festlegung erfolgt in Absprache mit dem AG.  Das Benutzen von Bibliotheken/Frameworks zum Loggen von Anwendungsmeldungen ist zu bevorzugen. Wenn durch den AN nur Programmteile oder Module entwickelt werden, die nicht als eigenständiges Programm laufen, kann in Absprache mit dem AG auf das Logging verzichtet werden.  Für personenbezogene/personenbeziehbare Daten müssen und für weitere Daten soll- ten Mechanismen implementiert sein, die das Verwerfen von Logdaten bei Anfrage oder nach einem festgelegten Zeitraum / einer maximalen Dateigröße erlauben.  (Optional) Erstellte Logdaten sollen bevorzugt über den systemeigenen Log-Dienst (Syslog, Event-log) gespeichert oder in einer vom AG vordefinierten Logdatenbank ab- gelegt werden

VORGABEN FÜR DIE DATENBANKPROGRAMMIERUNG Eingabedaten sind vor ihrer Weiterverarbeitung grundsätzlich zu prüfen und zu validieren. Für Tabellen, Spalten und Views sind sprechende Namen zu verwenden sowie eine ausführ- liche Dokumentation (einschließlich graphischem Datenbankmodell) zu erstellen. Oracle Datenbanken (es gelten zusätzlich die Vorgaben der Tabelle 1 – Anlage C)

 Die Namen von Datenbanksegmenten und -objekten sind in Großbuchstaben anzulegen. Quotierte Objektnamen sind nicht zulässig.  Periodische Aktivitäten haben nicht im Kontext vordefinierter Nutzer zu erfolgen.  Als Architektur kommt im Oracle Bereich die Single-tenant configuration zum Einsatz. Hierbei sind auf die PDB´s über entsprechende Oracle Services zuzugreifen. Dabei soll jede Anwendungskomponente über einen separaten Service auf die PDB zugreifen, um anwendungsspezifisches Tracing zu ermöglichen.

MS-SQL Datenbanken (es gelten zusätzlich die Vorgaben der Tabelle 1- Anlage C)

 Datenbankmodelle werden mit Hilfe eines Modellierungswerkzeugs erstellt. Alle Daten- bankobjekte außer Prozeduren und Funktionen sind im Werkzeug zu modellieren und zu dokumentieren.  (Optional) Für die Modelle sollte der SAP PowerDesigner verwendet werden.  (Optional) In einem IT-Verfahren implementierte Datenbankzugriffe sind in gespeicherten Prozeduren zu kapseln. Direkte Insert-, Update- und Delete-Operationen auf den Daten- banktabellen sind nicht zulässig.  Für jede nicht in einem IT-Verfahren implementierte Änderung in der Datenbank muss ein SQL-Skript vorhanden sein, dessen Ausführung beliebig fehlerfrei wiederholbar ist (z.B. Test auf Existenz der Spalte, bevor eine neue Spalte an eine Tabelle angefügt wird).  SQL-Skripte werden über ein existierendes Ticketsystem an die Datenbankadministrato- ren geliefert und nur von diesen ausgeführt.  SQL-Skripte sind mit Encoding „Western European (Windows) – Codepage 1252“ oder „Unicode (UTF-8 with Signature) – Codepage 65001“ zu speichern.  In SQL-Skripten und Köpfen von Prozeduren und Funktionen sind bei Erstellung und jeder Änderung das Datum, der Name des Ändernden und eine Kurzbeschreibung der Änderung zu vermerken. Parameter und Rückgabewerte (ResultSets und oder Return- Codes) von SQL-Prozeduren und -Funktionen sind im Quelltext zu kommentieren. Zur einheitlichen Formatierung dieser Kommentare stehen Templates bereit.

Version 1.4 Anhang Seite 8 von 13

[Seite 9]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

INFORMATIONSSICHERHEIT UND DATENSCHUTZ

Beachtung des BSI-IT-Grundschutzes Das LfULG ist der Informationssicherheit verpflichtet. Zur Erreichung und Aufrechterhaltung eines angemessenen Schutzes der gespeicherten und verarbeiteten Informationen folgt das LfULG den BSI-Standards zum IT-Grundschutz. Von den Auftragnehmern

• für die Erstellung der Software-Spezifikation und
• für die Software-Erstellung ist darzulegen, wie der IT-Grundschutz des BSI berücksichtigt wird und wie die zu entwi- ckelnde Lösung den Auftraggeber bei der Umsetzung seiner Informationssicherheitsziele un- terstützt. In der Darstellung ist im gebotenen Umfang auf die Anforderungen der einschlägigen Bau- steine des IT-Grundschutz-Kompendiums (i. d. Fassung von 2023) 10 einzugehen, insbeson- dere:  CON.8 - Software-Entwicklung  APP.3.1 - Webanwendungen und Webservices  CON.10 - Entwicklung von Webanwendungen  CON.1 - Kryptokonzept Es wird erwartet, dass die Anforderungen dieser Bausteine bei der Entwicklung schon von der Konzeptionsphase an kontinuierlich berücksichtigt werden. Die Anforderungen sind vom Auf- tragnehmer jeweils durch geeignete Maßnahmen zu untersetzen und mit dem Auftraggeber abzustimmen.

Vorgehensmodell bei der Software-Entwicklung Vom Auftragnehmer ist darzulegen, dass bei der Entwicklung Verfahren und Werkzeuge ein- gesetzt werden, die dem Paradigma einer sicheren Software-Entwicklung verpflichtet sind. Die eingesetzten Entwicklungswerkzeuge sollten auch Methoden wie  SAST (Static Application Security Testing),  DAST (Dynamic Application Security Testing) und  SCA (Software Composition Analysis) unterstützen. Im Fall der Entwicklung einer Webanwendung erwartet der Auftraggeber, dass der OWASP Application Security Verification Standard (ASVS, Version 4.0.3) durch den Auftragnehmer berücksichtigt wird. Die Einhaltung der ASVS-Anforderungen ist zu dokumentieren. Abwei- chungen von den Anforderungen sind ebenfalls zu dokumentieren sowie zu begründen.

10 https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grund- schutz/IT-Grundschutz-Kompendium/IT-Grundschutz-Bausteine/Bausteine_Download_Edition_node.html

Version 1.4 Anhang Seite 9 von 13

[Seite 10]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

Rollen- und Rechteverwaltung, Protokollierung Die zu entwickelnde Anwendung muss über eine angemessene, abgestufte Rollen- und Rechteverwaltung verfügen. Es sind mindestens folgende Rollen zu konzipieren und zu implementieren:  Fachadministrator,  Anwender lesend  Ggf. Anwender lesend und schreibend  Rechteverwalter  Auditor / Revisor. Die Rollen- und Rechteverwaltung soll sich an zentraler Stelle transparent und anwender- freundlich konfigurieren und überprüfen lassen. Alle Aktivitäten, die den entsprechenden Rollen zugeordnet sind, sind dem Stand der Technik entsprechend zu protokollieren. Die erzeugten Protokolldaten müssen sich später auch im Rohformat an einen SYSLOG-Ser- ver bzw. eine SIEM-Lösung (Security Information and Event Management) übertragen lassen. Aktuell existiert beim Auftraggeber noch kein SIEM-System; die Anschaffung ist aber in Pla- nung, so dass entsprechende Schnittstellen im Laufe der Projektbearbeitung mit dem Auftrag- geber abzustimmen sind.

Unterstützung der Datensicherung Schon bei der Konzeption der Lösung ist darauf zu achten, die Datensicherung angemessen zu unterstützen. Dabei sollten sich sowohl Konfigurationsdaten (einschließlich der Konfiguration der Rollen- und Rechteverwaltung) als auch Nutzdaten auf branchenübliche Weise sichern und wieder- herstellen lassen. Der Baustein CON.3 Datensicherungskonzept aus dem IT-Grundschutz-Kompendium des BSI sowie die zugehörigen Umsetzungshinweise zum Baustein sollten bei der Entscheidungsfin- dung für die Lösungsansätze angemessen berücksichtigt werden. Es sind die Anforderungen zu beschreiben um die Datenkonsistenz beim Backup zu gewähr- leisten.

Version 1.4 Anhang Seite 10 von 13

[Seite 11]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

Verwendung kryptografischer Methoden Grundsätzlich muss der Einsatz kryptografischer Methoden bei der Übertragung und Speiche- rung von schützenswerten Informationen zur Sicherung von deren Vertraulichkeit und Integri- tät dem Stand der Technik entsprechen. Die im FIS Geologie gehaltenen Daten sind nicht vertraulich; jedoch ist deren Integrität zu sichern. In der zu erarbeitenden Software-Spezifikation ist darzustellen, mit welchen Mitteln und Me- thoden die Integrität der Daten des FIS gesichert werden soll. Bei einer Verwendung kryptografischer Methoden sind grundsätzlich die einschlägigen BSI-Vorgaben aus den folgenden Richtlinien einzuhalten:  BSI TR-02102-1: Kryptographische Verfahren: Empfehlungen und Schlüssellänge (Ver- sion 2024-01, oder neuer)  BSI TR-02102-2: Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Teil 2 – Verwendung von Transport Layer Security (TLS) (Version 2024-01, oder neuer)  BSI TR-02102-3: Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Teil 3 – Verwendung von Internet Protocol Security (IPsec) und Internet Key Exchange (IKEv2) (Version 2024-01, oder neuer)  BSI TR-02102-4: Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Teil 4 – Verwendung von Secure Shell (SSH) (Version 2024-01, oder neuer) Dem Auftraggeber ist die Einhaltung der BSI-Vorgaben geeignet (z. B. durch Handbücher, oder Kryptokonzept) nachzuweisen.

Software Bill of Materials (SBOM) Sollte der Auftragnehmer im Rahmen der Entwicklung Programmbestandteile (Programm- code, Programmbibliotheken o. Ä.) verwenden, die nicht selbst entwickelt worden sind, ist das in Form einer Software Bill of Materials (SBOM) vollständig zu dokumentieren. Dabei sollte sich der Auftragnehmer grundsätzlich an den Vorgaben der BSI TR-03183: Cyber- Resilienz-Anforderungen an Hersteller und Produkte, Teil 2: Software Bill of Materials (SBOM) (Version 1.0, oder neuer) orientieren.

Version 1.4 Anhang Seite 11 von 13

[Seite 12]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

Teil C Systemumgebungen und Datenbanken

Tabelle 1 definiert die aktuellen Systemumgebungen, die als Mindeststandard eingehalten werden müssen. Kommen neuere Versionen der Software zu Einsatz, ist dies mit der Abteilung 11 abzustimmen. Nach der Tabelle werden für die Datenbankprogrammierung wesentliche Vorgaben definiert, die bei Entwicklungen für das LfULG eingehalten werden müssen.

Tabelle 1: Systemumgebungen

System Aktuelle Umgebung(en)

Windows 10 (64 Bit), Microsoft Office 2016 Professional Edition (32 Bit) Clients Windows 11 (SAC / LTSC 2024) (64 Bit), Microsoft Office 2024 Profes- sional Edition LTSC (32-Bit / 64-Bit) Domain Functional Level: Windows Server 2016 Active Directory Forest Functional Level: Windows Server 2012 R2 Mind. Authentifizierungsprotokoll: NTLMv2, Kerberos, LDAPS Standardserver Microsoft Server 2019 (64 Bit) oder höher Microsoft Web-/Applikations- IIS Version 10 oder höher Server Apache Tomcat Version 9 oder höher Oracle Database 19c Standard Edition 2, 64 Bit Oracle Datenbank- Unicodezeichensatzparameter UTF-8: server NLS_CHARACTERSET AL32UTF8 NLS_NCHAR_CHARACTERSET AL16UTF16

Oracle Client Oracle Database Client 12.2 (64bit Standard Edition) oder höher

Microsoft SQL Server 2019 Standard Edition 64Bit oder höher Microsoft Sortierreihenfolge: Latin1_General_CS_AS. Datenbankserver Installationssprache und Spracheinstellung DBs: Englisch OpenSource- PostgreSQL Version 15 oder höher auf Basis von Microsoft Server Datenbanken 2019 (64 Bit) oder höher

Microsoft Server 2019 (64 Bit) oder höher Terminalserver Citrix Virtual Apps

• VMware (vSphere) Virtualisierungs- - Omnissa (Horizon) plattform - Citrix XENServer
• Citrix Virtual Apps and Desktops

Open JDK / Java SDK 17 LTS Java (Bei Verwendung von Java-Umgebungen ist darauf zu achten, das dem LfULG beim Einsatz dadurch keine Lizenzkosten entstehen)

Vorhanden: .NET Runtime Versionen 2.0, 3.x und 4.x .NET Runtime Für Neu- und Anpassungsentwicklungen: mind. .NET Framework 4.7.1 bzw. .NET 8.0

Version 1.4 Anhang Seite 12 von 13

[Seite 13]

Technische Rahmenbedingungen für den Betrieb von Verfahren des LfULG

Client:

• ESRI ArcGIS Pro 3.x inkl. Erweiterungen
• ESRI ArcGIS Desktop (ArcMap/ArcCatalog) Version 10.8.1 inkl. Erweiterungen wird nur noch bis Februar 2024 betrieben. Es sind keine neuen Anwendungen darauf aufzusetzen. Server/Datenspeicher:
• ESRI ArcGIS Server Standard Enterprise 10.9.1 (OGC- und REST-Dienste) für die ArcGIS Enterprise und Web-Bereitstel- lung. o Spatial Datatype SDO_Geometry
• ESRI ArcGIS Server Basic 10.8.1 (mit Oracle Database Client) o Spatial Datatype SDO_Geometry
• Cadenza Web Classic Version 8.3, Update auf Version 9.1 im

3. Quartal 2023, basierend auf XML-Repositories. Geographische Informations- - sowie Cadenza Server/Client 8.3 (Update auf Version 9.1 im 3. systeme (GIS) Quartal 2023).

• Versionsverwaltung Cadenza Repositories: TortoiseSVN für die Versionsverwaltung der XML-Repositorys von Entwick- lungs- auf Produktivumgebung.
• Cadenza Workbooks befindet sich aktuell im Aufbau und wird ab 2024 sukzessive ausgebaut (datenbankbasierten Reposito- ries auf Oracle Basis).

Metadatenserver: Erfassung und Veröffentlichung der Metadaten über E-Government Komponente https://geomis.sachsen.de

ETL-Tools zur Geodatenbearbeitung und –bereitstellung

• Bereich ESRI: FME Desktop und Server ESRI Edition (Version

Bereich disy Cadenza (iDA) mit Oracle: Talend 8

Version 1.4 Anhang Seite 13 von 13