chrisbst48/itgrundschutzcompendium_2023 huggingface dataset:
APP.3.6.A10 Auswahl eines geeigneten DNS-Server-Produktes
Das DNS-Server-Produkt SOLLTE die aktuellen RFC-Standards unterstützen. Wird ein DNS-Server-Produkt beschafft, dann SOLLTE darauf geachtet werden, dass es sich in der Praxis ausreichend bewährt hat. Das DNS-Server-Produkt SOLLTE die Zuständigen dabei unterstützen, syntaktisch korrekte Master Files zu erstellen.
APP.3.6.A11 Ausreichende Dimensionierung der DNS-Server
Die Hardware des DNS-Servers SOLLTE ausschließlich für den Betrieb dieses DNS-Servers benutzt werden. Die Netzanbindungen sämtlicher DNS-Server im Informationsverbund SOLLTEN ausreichend bemessen sein. Die Hardware des DNS-Servers SOLLTE ausreichend dimensioniert sein.
APP.3.6.A12 ENTFALLEN
Diese Anforderung ist entfallen.
APP.3.6.A13 Einschränkung der Sichtbarkeit von Domain-Informationen
Der Namensraum eines Informationsverbunds SOLLTE in einen öffentlichen und einen institutionsinternen Bereich aufgeteilt werden. IT-Systeme im internen Netz SOLLTEN selbst dann keinen von außen auflösbaren DNS-Namen erhalten, wenn sie eine öffentliche IP-Adresse besitzen. Im öffentlichen Teil SOLLTEN nur solche Domain-Informationen enthalten sein, die von Diensten benötigt werden, die von extern erreichbar sein sollen.
APP.3.6.A14 Platzierung der Nameserver
Primary und Secondary Advertising DNS-Server SOLLTEN in verschiedenen Netzsegmenten platziert werden.
APP.3.6.A15 Auswertung der Logdaten
• Anzahl der Fehler bei DNS-Anfragen, • Veränderungen im Verhältnis von Fehlern zu DNS-Anfragen. • fehlgeschlagene Zonentransfers sowie • auslaufende Zonen, Mindestens die folgenden sicherheitsrelevanten Ereignisse SOLLTEN ausgewertet werden: • Anzahl der DNS-Anfragen, • EDNS-Fehler, Die Logdateien des DNS-Servers SOLLTEN regelmäßig überprüft werden. Die Logdateien des DNS-Servers SOLLTEN regelmäßig ausgewertet werden.
APP.3.6.A16 Integration eines DNS-Servers in eine P-A-P-Struktur
Die DNS-Server SOLLTEN in eine „Paketfilter - Application-Level-Gateway - Paketfilter“-(P-A-P)-Struktur integriert werden (siehe auch NET.1.1 Netzarchitektur und -design). Der Advertising DNS-Server SOLLTE in diesem Fall in einer demilitarisierten Zone (DMZ) des äußeren Paketfilters angesiedelt sein. Der Resolving DNS-Server SOLLTE in einer DMZ des inneren Paketfilters aufgestellt sein.
APP.3.6.A17 Einsatz von DNSSEC
Die dabei verwendeten Schlüssel Key-Signing-Keys (KSK) und Zone-Signing-Keys (ZSK) SOLLTEN regelmäßig gewechselt werden. Die DNS-Protokollerweiterung DNSSEC SOLLTE sowohl auf Resolving DNS-Servern als auch auf Advertising DNS-Servern aktiviert werden.
APP.3.6.A18 Erweiterte Absicherung von Zonentransfers
Um Zonentransfers stärker abzusichern, SOLLTEN zusätzlich Transaction Signatures (TSIG) eingesetzt werden.
APP.3.6.A19 Aussonderung von DNS-Servern
Der DNS-Server SOLLTE sowohl aus dem Domain-Namensraum als auch aus dem Netzverbund gelöscht werden.
APP.3.6.A2 Einsatz redundanter DNS-Server
Für jeden Advertising DNS-Server MUSS es mindestens einen zusätzlichen Secondary DNS-Server geben. Advertising DNS-Server MÜSSEN redundant ausgelegt werden.
APP.3.6.A20 Prüfung des Notfallplans auf Durchführbarkeit
Es SOLLTE regelmäßig überprüft werden, ob der Notfallplan für DNS-Server durchführbar ist.
APP.3.6.A21 Hidden Master
Um Angriffe auf den primären Advertising DNS-Server zu erschweren, SOLLTE eine sogenannte Hidden-Master-Anordnung vorgenommen werden.
APP.3.6.A22 Anbindung der DNS-Server über unterschiedliche Provider
Extern erreichbare DNS-Server SOLLTEN über unterschiedliche Provider angebunden werden.
APP.3.6.A3 Verwendung von separaten DNS-Servern für interne und externe Anfragen
Die Resolver der internen IT-Systeme DÜRFEN NUR die internen Resolving DNS-Server verwenden. Advertising DNS-Server und Resolving DNS-Server MÜSSEN serverseitig getrennt sein.
APP.3.6.A4 Sichere Grundkonfiguration eines DNS-Servers
Es MUSS sichergestellt werden, dass DNS-Zonentransfers zwischen Primary und Secondary DNS-Servern funktionieren. Ein Resolving DNS-Server MUSS so konfiguriert werden, dass er ausschließlich Anfragen aus dem internen Netz akzeptiert. Wenn ein Resolving DNS-Server Anfragen versendet, MUSS er zufällige Source Ports benutzen. Sind DNS-Server bekannt, die falsche Domain-Informationen liefern, MUSS der Resolving DNS-Server daran gehindert werden, Anfragen dorthin zu senden. Ein Advertising DNS-Server MUSS so konfiguriert werden, dass er Anfragen aus dem Internet immer iterativ behandelt. Zonentransfers MÜSSEN so konfiguriert werden, dass diese nur zwischen Primary und Secondary DNS-Servern möglich sind. Zonentransfers MÜSSEN auf bestimmte IP-Adressen beschränkt werden. Die Version des verwendeten DNS-Server-Produktes MUSS verborgen werden.
APP.3.6.A5 ENTFALLEN
Diese Anforderung ist entfallen.
APP.3.6.A6 Absicherung von dynamischen DNS-Updates
Es MUSS festgelegt werden, welche Domain-Informationen die IT-Systeme ändern dürfen. Es MUSS sichergestellt werden, dass nur legitimierte IT-Systeme Domain-Informationen ändern dürfen.
APP.3.6.A7 Überwachung von DNS-Servern
• EDNS-Fehler (EDNS - Extension Mechanisms for DNS), • Anzahl der DNS-Anfragen, • fehlgeschlagene Zonentransfers. • auslaufende Zonen sowie Es MUSS überwacht werden, wie ausgelastet die DNS-Server sind, um rechtzeitig die Leistungskapazität der Hardware anpassen zu können. DNS-Server MÜSSEN so konfiguriert werden, dass mindestens die folgenden sicherheitsrelevanten Ereignisse protokolliert werden: • Anzahl der Fehler bei DNS-Anfragen, DNS-Server MÜSSEN laufend überwacht werden.
APP.3.6.A8 Verwaltung von Domainnamen
Es MUSS sichergestellt sein, dass die Registrierungen für alle Domains, die von einer Institution benutzt werden, regelmäßig und rechtzeitig verlängert werden. Eine Person MUSS bestimmt werden, die dafür zuständig ist, die Internet-Domainnamen zu verwalten. Falls Dienstleistende mit der Domainverwaltung beauftragt werden, MUSS darauf geachtet werden, dass die Institution die Kontrolle über die Domains behält.
APP.3.6.A9 Erstellen eines Notfallplans für DNS-Server
Der Notfallplan für DNS-Server MUSS einen Wiederanlaufplan für alle DNS-Server im Informationsverbund enthalten. Ein Notfallplan für DNS-Server MUSS erstellt werden. Der Notfallplan für DNS-Server MUSS in die bereits vorhandenen Notfallpläne der Institution integriert werden. Im Notfallplan für DNS-Server MUSS ein Datensicherungskonzept für die Zonen- und Konfigurationsdateien beschrieben sein. Das Datensicherungskonzept für die Zonen- und Konfigurationsdateien MUSS in das existierende Datensicherungskonzept der Institution integriert werden.
APP.4.2 SAP-ERP-System
Anwendung R2
APP.4.2.A1 Sichere Konfiguration des SAP-ABAP-Stacks
Dazu MÜSSEN die jeweiligen Profilparameter gesetzt werden, z. B. für die Passwortsicherheit, Authentisierung und Verschlüsselung. Der SAP-ABAP-Stack MUSS sicher konfiguriert werden. Auch MÜSSEN die Systemänderbarkeit und die Mandanten konfiguriert, das IMG-Customizing durchgeführt und die Betriebssystemkommandos abgesichert werden.
APP.4.2.A10 ENTFALLEN
Diese Anforderung ist entfallen.
APP.4.2.A11 Sichere Installation eines SAP-ERP-Systems
Außerdem SOLLTEN die Sicherheitsrichtlinien der Institution eingehalten werden. Bei der Installation eines SAP-ERP-Systems SOLLTEN aktuelle SAP-Sicherheitsleitfäden und - Dokumentationen berücksichtigt werden. Ebenso SOLLTE gewährleistet sein, dass das SAP-ERP-System auf einem abgesicherten Betriebssystem installiert wird.
APP.4.2.A12 SAP-Berechtigungsentwicklung
Des Weiteren SOLLTEN SAP-Berechtigungen auf dem Entwicklungssystem der SAP-Landschaft angepasst oder neu erstellt werden. Die technischen Berechtigungen SOLLTEN aufgrund fachlicher Vorgaben entwickelt werden. Das Qualitätssicherungssystem SOLLTE bei der Berechtigungsvergabe und ergänzenden Einstellungen analog zum Produktivsystem betrieben werden. Das SOLLTE auch bei S/4HANA die Berechtigungsentwicklung auf HANA-Datenbanken mit einschließen. Hier SOLLTEN Repository-Rollen aufgebaut und transportiert werden. Datenbankprivilegien SOLLTEN NICHT direkt an Konten vergeben werden. Bei Eigenentwicklungen für z. B. Transaktionen oder Berechtigungsobjekte SOLLTE die Transaktion SU24 gepflegt werden (Zuordnungen von Berechtigungsobjekten zu Transaktionen). Die Gesamtberechtigung * oder Intervalle in Objektausprägungen SOLLTEN vermieden werden. Die Berechtigungsentwicklung SOLLTE im Rahmen eines Änderungsmanagements durchgeführt werden. Es SOLLTE sichergestellt sein, dass das Produktivsystem ausreichend vor Berechtigungsänderungen geschützt ist und keine Entwicklerschlüssel vergeben werden.
APP.4.2.A13 SAP-Passwortsicherheit
Zugriffe auf Tabellen mit Hashwerten SOLLTEN eingeschränkt werden. Die eingesetzten Hash-Algorithmen für die gespeicherten Hashwerte der Passwörter in einem SAP-ERP-System SOLLTEN den aktuellen Sicherheitsstandards entsprechen. Um eine sichere Anmeldung am SAP-ERP-System zu gewährleisten, SOLLTEN Profilparameter, Customizing-Schalter oder Sicherheitsrichtlinien geeignet eingestellt werden.
APP.4.2.A14 Identifizierung kritischer SAP-Berechtigungen
Die SAP-Profile SAP_ALL und SAP_NEW* sowie das SAP-Berechtigungsobjekt S_DEVELOP (mit Änderungsberechtigungen ACTVT 01 und 02) SOLLTEN im Produktivsystem nicht vergeben werden. Der Umgang mit kritischen Berechtigungen SOLLTE streng kontrolliert werden. Notfall-Konten SOLLTEN von dieser Vorgabe ausgeschlossen sein. Dies SOLLTE auch für kritische Rollenkombinationen und additive Effekte wie z. B. Kreuzberechtigungen sichergestellt sein. Kritische Berechtigungen SOLLTEN regelmäßig identifiziert, überprüft und bewertet werden. Es SOLLTE darauf geachtet werden, dass diese Berechtigungen, Rollen und Profile nur restriktiv vergeben werden.
APP.4.2.A15 Sichere Konfiguration des SAP-Routers
Der SAP-Router SOLLTE den Zugang zum Netz regeln und die bestehende Firewall-Architektur zweckmäßig ergänzen. Auch SOLLTE er den Zugang zum SAP-ERP-System kontrollieren.
APP.4.2.A16 Umsetzung von Sicherheitsanforderungen für das Betriebssystem Windows
Nach der Installation SOLLTE das Konto  gesperrt werden. Das SAP-ERP-System SOLLTE NICHT auf einem Windows-Domaincontroller installiert werden. Die SAP-spezifischen Konten wie adm oder SAPService  SOLLTEN abgesichert werden. Das Konto SAPService  SOLLTE KEINE Rechte zur interaktiven Anmeldung besitzen. In Bezug auf diese Berechtigungen SOLLTEN die zum SAP-ERP-System dazugehörigen Systemressourcen wie Dateien, Prozesse und gemeinsam genutzte Speicher geschützt werden. Die spezifischen Berechtigungen der vom SAP-ERP-System angelegten Konten Guest, System, SAP system users = adm, SAPService und Database users =  und Benutzendengruppen SOLLTEN mithilfe geeigneter Einstellungen abgesichert werden.
APP.4.2.A17 Umsetzung von Sicherheitsanforderungen für das Betriebssystem Unix
Auch SOLLTEN die Passwörter der systemspezifischen Konten adm und  geändert werden. Nach der Installation SOLLTE das Konto  gesperrt werden. Für die SAP-ERP-Systemverzeichnisse unter Unix SOLLTEN Zugriffsberechtigungen festgelegt werden.
APP.4.2.A18 Abschaltung von unsicherer Kommunikation
Die internen Dienste des SAP-Applikationsservers SOLLTEN NUR mittels TLS miteinander kommunizieren. Sofern Datenbank und SAP-Applikationsserver auf verschiedenen Systemen betrieben werden, SOLLTE die Datenbankverbindung in geeigneter Weise verschlüsselt werden. Die Kommunikation mit und zwischen SAP-ERP-Systemen SOLLTE mit SNC abgesichert werden.
APP.4.2.A19 Definition der Sicherheitsrichtlinien für Konten(umbenannt von Definition der Sicherheitsrichtlinien für Benutzer in Vorjahres-Edition)
So SOLLTEN beispielsweise Konten mit kritischen Berechtigungen durch starke Passwortregeln abgesichert sein (Transaktion SECPOL). Für die jeweiligen Konten und Kontengruppen SOLLTEN spezifische Sicherheitsrichtlinien für Passwörter und Anmelderestriktionen erstellt werden. Die Sicherheitsrichtlinien SOLLTEN den Konten korrekt zugeordnet und regelmäßig überprüft werden.
APP.4.2.A2 Sichere Konfiguration des SAP-JAVA-Stacks
Der SAP-JAVA-Stack MUSS sicher konfiguriert werden, falls dieser eingesetzt wird. Deshalb MÜSSEN Administrierende die Architektur des JAVA-Stacks kennen und wissen, wie er administriert wird. Zudem MÜSSEN nicht benötigte Dienste abgeschaltet, Standardinhalte entfernt, HTTP-Dienste geschützt und Zugriffe auf Administrationsschnittstellen eingeschränkt werden. Dafür MÜSSEN andere Sicherheitsmechanismen und -konzepte erstellt werden als für den SAP-ABAP-Stack.
APP.4.2.A20 Sichere SAP-GUI-Einstellungen
Auch SOLLTEN SAP GUI ACLs aktiviert sowie angemessene Administrationsregeln verteilt und aktiviert werden. Die SAP GUI SOLLTE auf allen Clients installiert und regelmäßig aktualisiert werden.
APP.4.2.A21 ENTFALLEN
Diese Anforderung ist entfallen.
APP.4.2.A22 Schutz des Spools im SAP-ERP-System
Es SOLLTE sichergestellt sein, dass auf Daten der sequenziellen Datenverarbeitung wie Spool oder Druck nur eingeschränkt zugegriffen werden kann. Die hierfür vergebenen Berechtigungen SOLLTEN regelmäßig überprüft werden. Auch SOLLTE verhindert werden, dass unberechtigte Konten auf die vom SAP-Spoolsystem benutzte Datenablage TemSe zugreifen können.
APP.4.2.A23 Schutz der SAP-Hintergrundverarbeitung
Die SAP-Hintergrundverarbeitung SOLLTE vor unberechtigten Zugriffen geschützt werden. Der so genannte Benutzertyp Dialog SOLLTE dafür grundsätzlich NICHT zugelassen werden. Dafür SOLLTEN für Batch-Jobs verschiedene System-Konten nach ihren Funktionsbereichen definiert und angelegt werden.
APP.4.2.A24 Aktivierung und Absicherung des Internet Communication Frameworks
ICF-Berechtigungen SOLLTEN restriktiv vergeben werden. Die Kommunikation SOLLTE verschlüsselt erfolgen. Es SOLLTE darauf geachtet werden, dass nur notwendige ICF-Dienste aktiviert werden. Alle ICF-Dienste, die unter einem ICF-Objekt sind, SOLLTEN nur einzeln aktiviert werden.
APP.4.2.A25 Sichere Konfiguration des SAP Web Dispatchers
Der SAP Web Dispatcher SOLLTE nicht der erste Einstiegspunkt aus dem Internet zum SAP-ERP-System sein. Der SAP Web Dispatcher SOLLTE auf dem aktuellen Stand sein. Er SOLLTE sicher konfiguriert sein.
APP.4.2.A26 Schutz von selbstentwickeltem Code im SAP-ERP-System(umbenannt von Schutz des kundeneigenen Codes im SAP-ERP-System in Vorjahres-Edition)
Es SOLLTE ein Custom-Code-Managementprozess definiert werden, damit selbstentwickelter Code ausgetauscht oder entfernt wird, falls er durch SAP-Standard-Code ersetzt werden kann oder er nicht mehr benutzt wird. Ferner SOLLTEN die Anforderungen aus der Richtlinie für die Entwicklung von ABAP-Programmen berücksichtigt werden.
APP.4.2.A27 Audit des SAP-ERP-Systems
Dafür SOLLTE der Security Optimization Service im SAP Solution Manager benutzt werden. Die Ergebnisse des Audits SOLLTEN ausgewertet und dokumentiert werden. Damit sichergestellt ist, dass alle internen und externen Richtlinien sowie Vorgaben eingehalten werden, SOLLTEN alle SAP-ERP-Systeme regelmäßig auditiert werden.
APP.4.2.A28 Erstellung eines Notfallkonzeptes
Das Notfallkonzept SOLLTE regelmäßig aktualisiert werden. Im Notfallkonzept SOLLTEN folgende Punkte beschrieben und definiert werden: Es SOLLTE die Geschäftsaktivitäten absichern und mit den Vorgaben aus dem Krisenmanagement oder dem Business-Continuity-Management übereinstimmen. Für SAP-ERP-Systeme SOLLTE ein Notfallkonzept erstellt und betrieben werden. • Detektion von und Reaktion auf Zwischenfälle, • Datensicherungs- und Wiederherstellungskonzept sowie • Notfalladministration.
APP.4.2.A29 Einrichten von Notfall-Konten(umbenannt von Einrichten eines Notfallbenutzers in Vorjahres-Edition)
Die eingerichteten Konten und Berechtigungen SOLLTEN stark kontrolliert und genau dokumentiert werden. Es SOLLTEN Notfall-Konten angelegt werden. Außerdem SOLLTEN alle von Notfall-Konten durchgeführten Aktivitäten protokolliert werden.
APP.4.2.A3 Netzsicherheit
Um die Netzsicherheit zu gewährleisten, MÜSSEN entsprechende Konzepte unter Berücksichtigung des SAP-ERP-Systems erstellt und Einstellungen am System durchgeführt werden. Um Sicherheitslücken aufgrund von Fehlinterpretationen oder Missverständnissen zu vermeiden, MÜSSEN sich die Bereiche IT-Betrieb, Firewall-Betrieb, Portalbetrieb und SAP-Betrieb miteinander abstimmen. Weiterhin SOLLTEN der SAP-Router und SAP Web Dispatcher eingesetzt werden, um ein sicheres SAP-Netz zu implementieren und aufrechtzuerhalten.
APP.4.2.A30 Implementierung eines kontinuierlichen Monitorings der Sicherheitseinstellungen
Das SAP-Monitoring SOLLTE in die allgemeine Systemüberwachung der Institution integriert werden. Es SOLLTE ständig überwacht werden, ob alle Sicherheitseinstellungen des SAP-ERP-Systems korrekt sind. Außerdem SOLLTE überwacht werden, ob alle Patches und Updates ordnungsgemäß eingespielt wurden.
APP.4.2.A31 Konfiguration von SAP Single-Sign-On
Sind mehrere SAP-ERP-Systeme vorhanden, SOLLTEN die Benutzenden auf die Systeme mit SAP Single-Sign-On (SAP SSO) zugreifen. Es SOLLTE in der Planungsphase entschieden werden, zwischen welchen SAP-ERP-Systemen der SSO-Mechanismus benutzt wird. Das SSO SOLLTE sicher konfiguriert und betrieben werden.
APP.4.2.A32 Echtzeiterfassung und Alarmierung von irregulären Vorgängen
Bei verdächtigen Vorgängen SOLLTEN automatisch die zuständigen Mitarbeitenden alarmiert werden. Um SAP-spezifische Sicherheitsvorfälle analysieren und Falschmeldungen von echten Sicherheitsvorfällen abgrenzen zu können, SOLLTEN entweder Mitarbeitende geschult oder entsprechende Serviceleistungen von Drittanbietenden genutzt werden. Die wichtigsten Sicherheitsaufzeichnungsfunktionen der SAP-ERP-Systeme wie Security Audit Log oder System Log SOLLTEN kontinuierlich überwacht werden.
APP.4.2.A4 Absicherung der ausgelieferten SAP-Standard-Konten(umbenannt von Absicherung der ausgelieferten SAP-Standardbenutzer-Kennungen in Vorjahres-Edition)
Auch MÜSSEN die eingerichteten SAP-Standard-Konten mithilfe geeigneter Maßnahmen abgesichert werden. Bestimmte SAP-Standard-Konten DÜRFEN NICHT benutzt werden, z. B. für RFC-Verbindungen und Background-Jobs. Direkt nach der Installation eines SAP-ERP-Systems MÜSSEN die voreingestellten Passwörter der SAP-Standard-Konten geändert werden.
APP.4.2.A5 Konfiguration und Absicherung der SAP-Konten-Verwaltung(umbenannt von Konfiguration und Absicherung der SAP-Benutzerverwaltung in Vorjahres-Edition)
Aktivitäten, wie Konten anlegen, ändern und löschen, Passwörter zurücksetzen und entsperren sowie Rollen und Profile zuordnen, MÜSSEN zu den Aufgaben der Konto-Administration gehören. Die SAP-Konten-Verwaltung für ABAP-Systeme MUSS sorgfältig und sicher administriert werden.
APP.4.2.A6 Erstellung und Umsetzung eines Konten- und Berechtigungskonzeptes(umbenannt von Erstellung und Umsetzung eines Benutzer- und Berechtigungskonzeptes in Vorjahres-Edition)
Werden neben dem ABAP-Backend weitere Komponenten wie SAP HANA und SAP NetWeaver Gateway (für Fiori-Anwendungen) verwendet, MUSS das Design der Berechtigungen zwischen den Komponenten abgestimmt und synchronisiert werden. Für SAP-ERP-Systeme MUSS ein Konten- und Berechtigungskonzept ausgearbeitet und umgesetzt werden. • Vorgehensweisen im Rahmen der Berechtigungsvergabe für Konten und Berechtigungen beantragen, genehmigen, ändern und löschen MÜSSEN definiert werden. • Namenskonventionen für Konten-Kennungen und technische Rollennamen MÜSSEN definiert werden. • Vorschlagswerte und Prüfkennzeichen SOLLTEN in der Transaktion SU24 gepflegt werden. Die Vorgehensweise dazu SOLLTE im Konten- und Berechtigungskonzept beschrieben sein. • Gesetzliche und interne Rahmenbedingungen wie die Grundsätze ordnungsgemäßer Buchführung (GoB), das Handelsgesetzbuch (HGB) oder interne Vorgaben der Institution MÜSSEN berücksichtigt werden. Das Konten- und Berechtigungskonzept SOLLTE auch den Betrieb technischer Konten abdecken, also auch die Berechtigung von Hintergrund- und Schnittstellenkonten. Es SOLLTEN geeignete Kontrollmechanismen angewandt werden, um SoD-Konfliktfreiheit von Rollen und die Vergabe von kritischen Berechtigungen an Konten zu überwachen. Dabei MÜSSEN folgende Punkte berücksichtigt werden: • Identitätsprinzip, Minimalprinzip, Stellenprinzip, Belegprinzip der Buchhaltung, Belegprinzip der Berechtigungsverwaltung, Funktionstrennungsprinzip (Segregation of Duties, SoD), Genehmigungsprinzip, Standardprinzip, Schriftformprinzip und Kontrollprinzip MÜSSEN berücksichtigt werden. • Konto-, Berechtigungs- und gegebenenfalls Profiladministrierender MÜSSEN getrennte Verantwortlichkeiten und damit Berechtigungen haben. • Vorgehensweisen im Rahmen der Berechtigungsadministration für Rollen anlegen, ändern, löschen, transportieren und SU24 Vorschlagswerte transportieren MÜSSEN definiert werden. Dabei SOLLTEN Berechtigungsrollen nur im Entwicklungssystem angelegt und gepflegt werden. Sie SOLLTEN mit Hilfe des Transport-Management-Systems (TMS) transportiert werden. Berechtigungen SOLLTEN in Berechtigungsrollen (PFCG-Rollen) angelegt, gespeichert und den Konten zugeordnet werden (rollenbasiertes Berechtigungskonzept). Da sich einzelne kritische Aktionen in den Rollen nicht immer vermeiden lassen, SOLLTEN sie von kompensierenden Kontrollen (mitigation controls) abgedeckt werden.
APP.4.2.A7 Absicherung der SAP-Datenbanken
Wird dazu Software von fremden Institutionen benutzt, MÜSSEN zusätzliche Sicherheitsmaßnahmen umgesetzt werden. Es DARF dann kein Schema-Konto des SAP Systems für die Verbindung zur Datenbank genutzt werden. Außerdem MÜSSEN Standardpasswörter geändert und bestimmte Datenbanktabellen (z. B. USR* Tabellen) besonders geschützt werden. Der Zugriff auf SAP-Datenbanken MUSS abgesichert werden. Administrierende SOLLTEN möglichst nur mit SAP-Tools auf die Datenbanken zugreifen können.
APP.4.2.A8 Absicherung der SAP-RFC-Schnittstelle
Nicht mehr benutzte RFC-Verbindungen MÜSSEN gelöscht werden. Verbindungen mit hinterlegtem Passwort SOLLTEN nicht von niedriger privilegierten auf höher privilegierte Systeme (z. B. von Dev nach Prod) konfiguriert sein. Dazu SOLLTEN die benötigten RFC-Verbindungen definiert und dokumentiert werden. Zum Schutz der Remote-Function-Call (RFC)-Schnittstelle MÜSSEN RFC-Verbindungen, RFC-Berechtigungen und die RFC-Gateways sicher konfiguriert werden. Es MÜSSEN für alle RFC-Verbindungen einheitliche Verwaltungsrichtlinien erstellt und umgesetzt werden. Es MÜSSEN Zugriffssteuerungslisten (ACLs) definiert werden. Außerdem MUSS die Protokollierung aktiv sein. Alle Verbindungen über ein Gateway MÜSSEN unter dem Sicherheitsaspekt analysiert und bewertet werden. Dazu MÜSSEN geeignete Profilparameter gesetzt werden, z. B. gw/monitor, gw/reg_no_conn_info und snc/permit_insecure_start. Alle RFC-Gateways MÜSSEN sicher administriert werden.
APP.4.2.A9 Absicherung und Überwachung des Message-Servers
Der Message-Server MUSS mithilfe von geeigneten Mechanismen überwacht werden, damit z. B. Systemausfälle des Message-Servers schnell erkannt werden. Der Message-Server MUSS durch geeignete Einstellungen in den Profilparametern abgesichert werden. Es MUSS unter anderem entschieden werden, ob für den internen Message-Server noch ACLs aufgebaut werden.
APP.4.3 Relationale Datenbanken
Anwendung R2
APP.4.3.A1 Erstellung einer Sicherheitsrichtlinie für Datenbanksysteme
Die Ergebnisse MÜSSEN sinnvoll dokumentiert werden. Wird die Richtlinie verändert oder wird von den Anforderungen abgewichen, MUSS dies mit dem oder der ISB abgestimmt und dokumentiert werden. Es MUSS regelmäßig überprüft werden, ob die Richtlinie noch korrekt umgesetzt ist. Die Richtlinie MUSS allen im Bereich Datenbanksysteme zuständigen Mitarbeitenden bekannt sein. Darin MÜSSEN nachvollziehbar Anforderungen und Vorgaben beschrieben sein, wie Datenbanksysteme sicher betrieben werden sollen. Ausgehend von der allgemeinen Sicherheitsrichtlinie der Institution MUSS eine spezifische Sicherheitsrichtlinie für Datenbanksysteme erstellt werden. Sie MUSS grundlegend für ihre Arbeit sein.
APP.4.3.A10 ENTFALLEN
Diese Anforderung ist entfallen.
APP.4.3.A11 Ausreichende Dimensionierung der Hardware
Datenbankmanagementsysteme SOLLTEN auf ausreichend dimensionierter Hardware installiert werden. Wenn die Hardware dimensioniert wird, SOLLTE das erwartete Wachstum für den geplanten Einsatzzeitraum berücksichtigt werden. Zeichnen sich trotzdem während des Betriebs Ressourcenengpässe ab, SOLLTEN diese frühzeitig behoben werden. Die Hardware SOLLTE über genügend Reserven verfügen, um auch eventuell steigenden Anforderungen gerecht zu werden.