📊 Übersicht
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 | Unnamed: 6 | Unnamed: 7 | Unnamed: 8 | Unnamed: 9 | Unnamed: 10 |
|---|---|---|---|---|---|---|---|---|---|---|
| ANLAGE 3 – ANFORDERUNGSKATALOG SICHERHEIT – TELEFONANLAGE, ACD und UC | ||||||||||
| Anbieter: | ||||||||||
| WERTUNG SOLL-ANFORDERUNGEN | ||||||||||
| Gesamt Anforderungen | Anzahl MUSS-Kriterien | MUSS - Anforderung nicht, nur teilweise erfüllt oder nicht beantwortet | Anzahl SOLL-Kriterien | SOLL: Anzahl der Punkte | Gewichtung dieses Katalogs in der Gesamtwertung | 0.25 | ||||
| Maximal erreichbare SOLL-Punkte (Gewichtung × 10) | 3610 | |||||||||
| Mindestquote | 0.5 | |||||||||
| 136 | 15 | 15 | 121 | 0 | Mindestpunktzahl | 1805 | ||||
| Erreichte SOLL-Punkte | 0 | |||||||||
| Mindestpunktzahl erreicht? | nein – Ausschluss | |||||||||
| Hinweis: Die leere Vorlage zählt alle nicht ausgefüllten MUSS-Zeilen als nicht erfüllt (Ausschluss). Aussagekräftig sind die Werte erst nach vollständiger Beantwortung. | Hinweis: Gesamtwertung Preis 50 %, Anforderungskatalog TK/ACD 25 %, Anforderungskatalog Sicherheit 25 %. Ein Angebot, das in diesem Katalog weniger als 50 % der erreichbaren SOLL-Punkte (Mindestpunktzahl) erreicht, wird ausgeschlossen. Die SOLL-Punkte vergibt die ALDB in der Wertung; in der Bieterdatei bleibt die erreichte Punktzahl daher 0. Gelb: Vorgaben der ALDB. | |||||||||
| KATEGORIEN IM ÜBERBLICK | ||||||||||
| Kategorie | Key | Anforderungen | Beschreibung | |||||||
| Sicherheit & Compliance | S-001 | 136 | Schutz der Kommunikation und Einhaltung BSI Vorgaben |
Anforderungen
| ANFORDERUNGSKATALOG SICHERHEIT – TELEFONANLAGE / ACD | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 | Unnamed: 6 | Unnamed: 7 | Unnamed: 8 | Unnamed: 9 | Unnamed: 10 | Unnamed: 11 | Unnamed: 12 | Unnamed: 13 | Unnamed: 14 | Unnamed: 15 | Unnamed: 16 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Bewertung ALDB | Anbieter | |||||||||||||||
| MUSS - zwingend erforderlich, K.O.-Kriterium SOLL - wird bewertet, einzeln kein K.O.-Kriterium | SOLL Wichtigkeit: 1 - niedrig 2 - mittel 3 - hoch | SOLL Erfüllungsgrad: 0 - nicht erfüllt 5 - teilweise erfüllt 10 - voll erfüllt Ausschluss bei < 50 % der SOLL-Punkte | SOLL Gewichtung x Punkte | erfüllt - Anforderung wird vollständig erfüllt teilweise - Anforderung wird mit Einschränkungen erfüllt (K.O.-Kriterium bei MUSS) nicht erfüllt - Anforderung wird nicht erfüllt (K.O.-Kriterium bei MUSS) | ||||||||||||
| ID | Kapitel LB | Kategorie | Erfüllungs-kriterium | Gewichtung (1-3) | Anforderung / Beschreibung | Punkte (0/5/10) | Gesamt-punkte | Antwort | kurze Erläuterung/Beschreibung/Alternative Lösung/Verweis auf Herstellerunterlagen(Dokument, Seite), wenn verlangt, ZWINGEND ERFORDERLICH bei SOLL-Anforderungen, wenn sie NICHT ERFÜLLT oder TEILWEISE erfüllt werden | muss | nicht erfüllt | teilweise | muss und nicht erfüllt | muss und teilweise | muss ohne Antwort | |
| S-001 | – | Sicherheit & Compliance | MUSS | n.a. | Der Anbieter erklärt sich bereit, sein Personal im 2nd-Level-Support sowie Personal, das vor Ort Zugang zu den IT-Systemen benötigt, einer erweiterten Sicherheitsüberprüfung (SÜ2) gemäß § 9 SÜG zu unterziehen, sofern keine gültige Verschlusssachenermächtigung vorliegt. Die SÜ2 ist aufgrund vertraglicher Vorgaben der Auftraggeberin der ALDB erforderlich. Für den 1st-Level-Support ist keine SÜ2 erforderlich. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-002 | – | Sicherheit & Compliance | MUSS | n.a. | Bei Bearbeitung von VS-NfD eingestuften Daten ist eine VS-NfD-Verpflichtung durch Unterzeichnung des VS-NfD-Merkblatts erforderlich. Dies gilt auch für Personal von Nachunternehmern einschließlich des Herstellers. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-003 | 1.1 | Sicherheit & Compliance | MUSS | n.a. | Personal, das vor Ort Zugang zu den IT-Systemen benötigt oder im 2nd-Level-Support tätig ist, hat das VS-NfD-Merkblatt unterzeichnet und unterzieht sich einer Sicherheitsüberprüfung SÜ2, die unmittelbar nach Zuschlag eingeleitet wird. Bis zu deren Abschluss arbeitet das Personal nur in Begleitung von ALDB-Mitarbeitenden und nicht selbständig im geschlossenen System der ALDB. Für den 1st-Level-Support ist keine SÜ2 erforderlich. Für die Projektphase sind die Mitarbeitenden nach Zuschlag vor Leistungsbeginn zu benennen, für die Betriebsphase 2 bis 4 Mitarbeitende inkl. Profil. Die Anforderungen gelten auch für Personal von Nachunternehmern. Personal des Herstellers, das ausschließlich vorgeprüfte, bereinigte Protokolldaten erhält, benötigt keine SÜ2. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-004 | 2.4 | Sicherheit & Compliance | MUSS | n.a. | Die Qualifikationsnachweise der eingesetzten Personen werden spätestens zwei Wochen vor Beginn der Leistungserbringung vorgelegt. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-005 | 2.6 | Sicherheit & Compliance | MUSS | n.a. | Support und Fehlerbehebung inkl. Hotline erfolgen aus Deutschland und in deutscher Sprache. Es werden keine Nutzdaten an Anbieter oder Hersteller übermittelt, lediglich vorgeprüfte, bereinigte Protokolldaten. Zur Fehleranalyse bereitgestellte Daten werden nur in Deutschland bzw. innerhalb der EU verarbeitet. Eskalation an den Hersteller zulässig, wenn ausschließlich vorgeprüfte, bereinigte Protokolldaten übermittelt werden und die Verarbeitung innerhalb der EU erfolgt. Eine Eskalation an Support-Organisationen außerhalb der EU ist auch für bereinigte Daten ausgeschlossen | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-006 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Die Lösung soll für den Einsatz in VS-NfD-Umgebungen geeignet sein (Schutz von Sprach-, Video-, Chat- und Metadaten) durch Verschlüsselung nach BSI TR-02102 (Stand der Technik) für Signalisierung, Medien und gespeicherte Daten; der Anbieter beschreibt in der Projektphase, wie die Lösung die Vorgaben der VSA im geschützten Netz der ALDB unterstützt. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-007 | 4.3.3 | Sicherheit & Compliance | SOLL | 3 | Verschlüsselung von Signalisierung und Medien: - Verwendung von SIPS anstatt SIP - Verwendung von TURNS anstatt TURN - Verwendung von STARTTLS oder SMTPS anstatt SMTP - Verwendung von SRTP anstatt RTP - Übertragung von SOAP über https - Tunnelung von CSTA & MGCP (https/TLS/IPsec) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-008 | 4.3 | Sicherheit & Compliance | MUSS | n.a. | Der Anbieter hält die für die Leistungserbringung relevanten Vorgaben des nach ISO/IEC 27001 und ISO/IEC 27019 zertifizierten ISMS der ALDB ein, wirkt an Sicherheits- und Compliance-Maßnahmen mit und weist die Einhaltung auf Anforderung nach. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-009 | 4.3.1.1 | Sicherheit & Compliance | MUSS | n.a. | Vor der Übergabe der Software-Pakete sind die relevanten BSI-Grundschutz-Bausteine anzuwenden bzw. ist daran mitzuwirken, insbesondere OPS.1.1.3, OPS.1.1.4, OPS.1.1.5, OPS.1.1.6 und APP.4.3. Die Lösung unterstützt Auditing, Verschlüsselung (Transport/ruhende Daten) und Härtungsmaßnahmen. Für OPS.1.1.5 (Protokollierung) gilt S-016. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-010 | 4.3.1.2 | Sicherheit & Compliance | MUSS | n.a. | Vor der Bereitstellung werden sämtliche Software-Komponenten einer Schwachstellenanalyse unterzogen (Identifizierung, Bewertung/Klassifizierung, Maßnahmenplanung). | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-011 | 4.3.1.3 | Sicherheit & Compliance | MUSS | n.a. | Vor der Bereitstellung neuer Software sind Regressionstests durchzuführen, zu dokumentieren und der ALDB zu übergeben. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-012 | 4.3.1.4 | Sicherheit & Compliance | MUSS | n.a. | Bereitstellung der Software über die Download-Plattform des Anbieters (z. B. SharePoint) mit Zugriff der ALDB über eine sichere Verbindung nach BSI-Empfehlungen, Authentifizierung nach BSI-Richtlinien mit 2FA sowie Integritätsnachweisen (Signaturen/Checksummen) für alle Software-Pakete. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-013 | 4.3.2 | Sicherheit & Compliance | MUSS | n.a. | Webanwendungen sind nach dem Stand der Technik unter Berücksichtigung der aktuellen OWASP Top 10 zu entwickeln, zu testen und zu betreiben. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-014 | 4.3.3 | Sicherheit & Compliance | SOLL | 3 | Kommunikation soll gegen Mitlesen und Manipulation abgesichert werden. Für TLS soll BSI TR-02102-2 in der gültigen Fassung eingehalten werden. Signalisierung und Medien werden verschlüsselt übertragen (SIP über TLS, SRTP), ebenso Service- und Administrationszugänge; TLS 1.3 wird unterstützt; Zertifikatsmanagement mit der internen CA der ALDB. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-015 | 4.3.4 | Sicherheit & Compliance | SOLL | 3 | Der Anbieter legt eine Selbstverpflichtung zur Umsetzung von OWASP ASVS Level 2 vor und belegt die Umsetzung erstmals spätestens 4 Wochen nach Zuschlag, während der Vertragslaufzeit auf Verlangen (ASVS-Checkliste, Sicherheitsprüfungen, Dokumentation der TLS-Konfiguration). Kritische Sicherheitslücken werden vor der produktiven Inbetriebnahme behoben. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-016 | 4.3.7.1 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsrelevante Logfiles werden an das zentrale Sicherheits-Log-Management der ALDB gesendet. Die Lösung protokolliert administrative und sicherheitsrelevante Aktivitäten lückenlos. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-017 | 4.3.7.2 | Sicherheit & Compliance | SOLL | 3 | Die Software soll eine Integration mit HCL BigFix zur Integritätsüberwachung unterstützen, sowohl für direkt installierte als auch für containerisierte Software. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-018 | 4.3.8 | Sicherheit & Compliance | SOLL | 3 | Passwortvorgaben werden im Regelbetrieb über die Passwort-Policy des Active Directory umgesetzt. Ist das AD nicht verfügbar, soll eine lokale Benutzerverwaltung mit denselben Vorgaben verfügbar sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-019 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Die Applikation wird an das MS Active Directory angebunden; die Authentifizierung erfolgt ausschließlich über das AD. Ist das AD nicht verfügbar, soll eine lokale Verwaltung von Benutzern und Rollen verfügbar sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-020 | 4.3.10 | Sicherheit & Compliance | SOLL | 3 | Die Software soll eine vollständige Backup-/Recovery-Funktion besitzen, getrennt nach Software- und Daten-Backup. Bei Ausfall eines Servers oder Systems soll eine Wiederherstellung ohne Datenverlust sichergestellt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-021 | 4.3.10 | Sicherheit & Compliance | SOLL | 3 | Der Anbieter soll in der Projektphase darstellen, wie die Applikation unabhängig von bzw. parallel zur Datenbank gesichert werden kann, und die Prozedur für den Ausfall der Applikation, der Datenbank sowie beider beschreiben. Die Sicherung soll bevorzugt über die Mechanismen der Virtualisierung erfolgen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-022 | 4.3.10.3 | Sicherheit & Compliance | SOLL | 3 | Ein Backup soll alle Informationen umfassen, insbesondere sämtliche Software-Konfigurationen und Regeln. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-023 | 4.3.10.4 | Sicherheit & Compliance | SOLL | 3 | Automatisches Backup nach Zeitplan auf ein externes Medium sowie manuelles Backup sollen möglich sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-024 | 4.3.10.4 | Sicherheit & Compliance | MUSS | n.a. | Der Anbieter muss in der Projektphase ein Sicherungskonzept mit Prozeduren und den erforderlichen Beistellungen der ALDB vorlegen. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-025 | 4.3.10.5 | Sicherheit & Compliance | SOLL | 3 | Backups sollen je Software-Modul und inkrementell möglich sein; mindestens wöchentlich ein Vollbackup. Die letzten fünf bzw. individuell erstellte Backups sollen wiederherstellbar sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-026 | 4.3.10.6 | Sicherheit & Compliance | SOLL | 1 | Die Software überwacht den Backup-Prozess, erzeugt bei fehlerhaften oder unvollständigen Backups einen Alarm (idealerweise mit Ursache) und protokolliert jedes Backup. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-027 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Die Lösung soll auf nach CIS-Benchmarks gehärteten Systemen betreibbar sein und deren Einsatz unterstützen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-028 | 4.3 | Sicherheit & Compliance | MUSS | n.a. | Der Anbieter erfüllt die Anforderungen der DSGVO: Verarbeitung personenbezogener Daten ausschließlich auf dokumentierte Weisung der ALDB, Abschluss eines Auftragsverarbeitungsvertrags nach Art. 28 DSGVO, Nachweis geeigneter technischer und organisatorischer Maßnahmen. Die Lösung muss DSGVO-konform betrieben werden können. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-029 | 3.1 | Sicherheit & Compliance | MUSS | n.a. | Die Lösung muss die Anforderungen des deutschen Telekommunikationsrechts erfüllen (u. a. TKG, gesetzliche Notrufanforderungen, Rufnummernübermittlung). | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-030 | 4.3 | Sicherheit & Compliance | MUSS | n.a. | Die ALDB erhält Audit- und Auskunftsrechte beim Anbieter (Audits nach Ankündigung). Der Anbieter unterstützt interne und externe Audits und stellt aktuelle Zertifikate und Prüfberichte bereit. | ./. | 1 | 0 | 0 | 0 | 0 | 1 | ||||
| S-031 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.2 (NET.4.1.A5): VoIP-Systeme und TK-Anlagen sollen alle Systemeingriffe, Konfigurationsänderungen, Datenübermittlungen und Zugriffe protokollieren. Folgende Protokolle sollen bei TK-Anlagen und VoIP-Systemen erhoben werden: - alle systemtechnischen Eingriffe, die Programmveränderungen beinhalten - Auswertungsläufe, - Datenübermittlungen, - Datenzugriffe - Anmeldungen an und Zugriffe auf die TK-Anlagen über Administrationsschnittstellen und zugehörige Konten, - sämtliche Administrationsarbeiten, - wer mit wem telefoniert hat, - wie lange telefoniert wurde, - ob der Empfänger das Gespräch angenommen hat, - von welchem Netz und welcher IP-Adresse aus das Gespräch initiiert wurde und - welche Medientransportprotokolle und welcher Codec ausgehandelt wurden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-032 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.3 (NET.4.1.A5, NET.4.1.A16), Richtlinie VoIP und TK-Anlagen: Nur die wirklich notwendigen Leistungsmerkmale, Schnittstellen, Ports und Dienste sollen aktiviert werden. Alle anderen Konfigurationen sollen deaktiviert sein, sowohl an den Endgeräten, als auch an der zentralen Anlage / System. Die Konfigurationseinstellungen sollen nicht unkontrolliert verändert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-033 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.4 (NET.4.1.A6), Richtlinie VoIP und TK-Anlagen: Die Konfiguration der Anlage soll nach erfolgreicher Konfiguration, vor der Änderung von Konfigurationen und in regelmäßigen Abständen gesichert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-034 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.5 (NET.4.1.A15), Richtlinie VoIP und TK-Anlagen: Es soll sichergestellt werden, dass Notrufe auch bei einem Ausfall der TK-Anlage möglich sind. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-035 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.6 (NET.4.1.A17), Richtlinie VoIP und TK-Anlagen: Die Geräte sollen mit PINs / Passwörtern gesichert sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-036 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.7 (NET.4.1.A19), Richtlinie VoIP und TK-Anlagen: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: TK-Anlagen sind redundant an das Netz und die TK-Netze angeschlossen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-037 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.9 (NET.4.2.A4), Richtlinie VoIP und TK-Anlagen: Die Datenübertragung soll nur über die festgelegten und definierten beteiligten VoIP-Systeme stattfinden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-038 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.10 (NET.4.2.A8), Richtlinie VoIP und TK-Anlagen: Eine Verschlüsselung der VoIP-Kommunikation soll den Vorgaben des BSI Grundschutzes folgen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-039 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.13 (ALDB), Richtlinie VoIP und TK-Anlagen: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: Die Endgeräte der TK-Anlage werden über ein separates Netz angebunden; VoIP- und Datennetz sind mindestens durch VLANs voneinander getrennt. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-040 | 4.3.5 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 1.14 (NET.4.1.A16), Richtlinie VoIP und TK-Anlagen: Telefonanschlüsse in frei zugänglichen Räumen sollen nur mit den wenigsten Privilegien ausgestattet werden. Von diesen Anschlüssen sollen nur interne Anrufe (und externe Notrufe) durchgeführt werden können. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-041 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.2 (APP.3.2.A1), Regelungen für Webserver: Der Webserver soll von einem dedizierten Service Konto mit minimalen Rechten ausgeführt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-042 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.3 (APP.3.2.A1), Regelungen für Webserver: Sofern dies vom Betriebssystem unterstützt wird, soll der Webserver in einer gekapselten Umgebung ausgeführt werden (z.B. LXC, Docker). Wenn es nicht möglich ist, sollen Webserver durch selbständige virtuelle Server getrennt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-043 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.4 (APP.3.2.A1), Regelungen für Webserver: Der Webserver-Dienst soll nur über die absolut nötigen Schreibberechtigungen verfügen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-044 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.1.5 (APP.3.2.A1), Regelungen für Webserver: Werden Module oder Funktionen des Webservers nicht benötigt, sollen diese deaktiviert werden. Alle Beispieldokumente und –skripte sollen entfernt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-045 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.6 (APP.3.2.A2), Regelungen für Webserver: Sämtliche auf dem Webserver vorhandenen Dateien, insbesondere Skripte und Konfigurationsdateien, sollen vor unbefugtem Zugriff und unbefugter Veränderung geschützt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-046 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.7 (APP.3.2.A2), Regelungen für Webserver: Die Webserver-Anwendung soll nur auf Daten zugreifen, die sich innerhalb eines fest definierten Verzeichnisbaums (z.B. /var/www/) befinden. Ressourcen außerhalb dieses Verzeichnisbaums sollen nicht von innerhalb verlinkt oder verknüpft werden. Es soll sichergestellt sein, dass vertrauliche Dateien nicht in öffentlichen Verzeichnissen gespeichert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-047 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.8 (APP.3.2.A2), Regelungen für Webserver: Funktionen, die Verzeichnisse auflisten oder Code-Ausführung zulassen (z.B.‘exec cmd=“ls .“ ‘ ) sollen deaktiviert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-048 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.9 (APP.3.2.A3), Regelungen für Webserver: Für Datei-Uploads soll: - eine maximale Größe spezifiziert, - genügend Speicherplatz reserviert, - ein oder mehrere zulässige Dateitypen definiert, - der Dateiname von Zeichen spezifischer Bedeutung für Interpreter ($,;,>,<,…) und Steuerzeichen ( , \0, EOF,..) bereinigt, - der Dateiname von nicht-sichtbaren Zeichen (z.B. Steuerzeichen) bereinigt sowie der Ablageort zufällig erzeugt werden (z.B. durch das Hashen des Dateinamens mit geeigneter Entropie). | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-049 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.10 (APP.3.2.A5), Regelungen für Webserver: Passwortdateien auf dem Webserver sollen verschlüsselt gesichert und vor unbefugtem Zugriff geschützt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-050 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.11 (APP.3.2.A11), Regelungen für Webserver: Alle Webserver sollen verschlüsselte Protokolle gemäß BSI Grundschutz für alle Verbindungen nutzen. Bei Verwendung von HTTPS sollen sämtliche Inhalte über HTTPS verfügbar sein. Es soll kein Mixed Content genutzt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-051 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.12 (APP.3.2.A12), Regelungen für Webserver: Aus den http-Informationen und angezeigten Fehlermeldungen soll es nicht möglich sein, Informationen über das genutzte Produkt, Version des Webservers, Systeminformationen oder Konfiguration möglich sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-052 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.13 (APP.3.2.A12), Regelungen für Webserver: Es soll über den Betrieb sichergestellt sein, dass alternative Fehlermeldungen mit einer ID versehen ausgegeben werden, die über die serverseitige Protokollierung Rückschlüsse auf die Fehler geben können. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-053 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.14 (APP.3.2.A12), Regelungen für Webserver: Der Webserver sollte bei unerwarteten Fehlern in einen sicheren Zustand gehen und ggf. die auslösende Verbindung zurückweisen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-054 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 2.20 (APP.3.2.A15), Regelungen für Webserver: Webserver sollten redundant ausgelegt werden. Hierbei sollten auch andere wesentliche Komponenten (z.B. Netzwerkanbindung, Hardware) redundant ausgelegt sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-055 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.1 (APP.3.1.A1, APP.3.1.A7), Regelungen für Webanwendungen und Webservices: Webanwendungen und Webservices sollen eine geeignete Authentifizierung für den Zugriff erzwingen, insbesondere für den Zugriff auf geschützte Ressourcen und für den Schutz vor unerlaubter automatisierter Nutzung. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-056 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.2 (APP.3.1.A1, APP.3.1.A14), Regelungen für Webanwendungen und Webservices: Wenn eine Authentifizierung nicht über das ALDB AD realisiert werden kann, sollen über die Webanwendung oder Webservice die Grenzwerte für Anmeldeversuche angewendet werden. Weiterhin soll sichergestellt werden, dass die gespeicherten Zugangsdaten sicher vor unbefugtem Zugriff geschützt werden. Dafür sollen Salted Hash Verfahren genutzt werden. Die Authentisierung bei Webanwendung erfolgt mit Kennung und Passwort. Weitere Details sind im Kapitel „Anforderungen an die Passwortverwaltung“ gelistet. Werden vertrauliche Daten (Zugangsdaten (z. B. Benutzer, Passwort), Authentisierungsdaten (z. B. Session-ID) durch die Webanwendung verarbeitet, übertragen oder gespeichert (server- wie auch clientseitig), sollen sie durch kryptographische Verfahren geschützt werden. Es soll ausschließlich die Webanwendung mit Schreibrechten auf die Zugangsdaten zugreifen können. Bevor kritische Aktionen ausgeführt werden (z. B. zustandsändernde Anfragen wie eine Änderung des Passworts), soll der Benutzer erneut von der Webanwendung authentisiert werden. Zugangsdaten der Webanwendung sollen in der Webanwendung nicht im Klartext gespeichert werden. Stattdessen sollen sie mithilfe von zeitgemäßen kryptographischen Algorithmen als salted Hashes hinterlegt werden, bei denen eine zufällige Zeichenfolge an den Klartext angehängt wird. Hierbei soll für jedes Passwort ein unterschiedlicher, zufälliger Salt verwendet werden. Zugangsdaten der Webanwendung sollen serverseitig nur auf einem vertrauenswürdigen IT-System (z. B. auf dem der Webanwendung) und in einem geschützten Bereich (z. B. außerhalb des Web-Root-Verzeichnisses oder in separaten Datenbanktabellen) hinterlegt sein. Zugangsdaten der Webanwendung sollen nur durch den Benutzer und über die vorgesehenen Schnittstellen und Funktionen der Webanwendung geändert werden können, sodass es Benutzern nicht möglich ist, Zugangsdaten unbefugt über z. B. den direkten Zugriff auf das Dateisystem zu lesen, zu ändern oder zu löschen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-057 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.3 (APP.3.1.A4), Regelungen für Webanwendungen und Webservices: Wenn eine Webanwendung eine Upload-Funktion bereitstellt, soll dies möglichst restriktiv konfiguriert werden. Die Dateigröße, Dateitypen und Speicherorte sollen definiert und restriktiv konfiguriert sein. Um File Inclusion oder Directory Traversal Schwachstellen zu verhindern, sollen die Ausführungs- und Zugriffsrechte für die Webanwendung restriktiv gewählt werden. Insbesondere der Speicherort für Uploads soll restriktiv konfiguriert und sichergestellt werden, dass nur an diesem Speicherort Uploads abgelegt werden können. Erfordert die Webanwendung Benutzer-Eingaben als Quelle zur Einbindung von Dateien, sollen die vorgesehenen Pfadangaben zu den Quell-Dateien nicht frei wählbar sein. Benutzereingaben in eine Website sollen zudem auf unerwünschte Zeichen zur Manipulation des Pfades (z. B. "/.." und "..") gefiltert werden. Kann auf die Einbindung externer Inhalte in eine Website nicht verzichtet werden, soll die vertrauenswürdige Herkunft dieser Dateien sichergestellt werden (z. B. auf Basis einer Whitelist mit der Limitierung auf einen Server oder eine Auflistung von absoluten URLs). Hochgeladene Daten von einer Webanwendung sollen auf die benötigten Dateiformate beschränkt werden. Hierbei soll neben der Prüfung der Dateiendung ebenfalls der Inhalt der Datei, z. B. durch eine Auswertung des Dateiheaders, geprüft werden. Hochgeladene Dateien einer Webanwendung sollen in einem Verzeichnis gespeichert werden, das nicht über die Web-Schnittstelle erreichbar ist (z. B. außerhalb des Wurzelverzeichnisses des Webservers). Werden hochgeladenen Dateien einer Webanwendung zunächst in einem temporären Verzeichnis gespeichert, so soll sichergestellt werden, dass andere Benutzer nicht unerlaubt auf die Datei zugreifen können. Die Upload-Funktionalität einer Webanwendung soll nur angemeldeten Benutzern zur Verfügung stehen. Die Dateigröße von Uploads in Webanwendungen soll begrenzt werden. Das Limit soll für jede Anwendung zwischen Anwendungsverantwortlichem und IT-Sicherheitsbeauftragten abgestimmt werden. Ein Virenschutzprogramm soll in Webanwendungen hochgeladene Dateien auf Schadsoftware untersuchen. Alle nicht sichtbaren Zeichen (z. B. Steuerzeichen) und alle kodierten Varianten dieser Zeichen sollen vom Dateinamen von hochgeladenen Dateien in einer Webanwendung entfernt werden (z. B. Unicode). Alle Zeichen mit einer spezifischen Bedeutung für Interpreter sollen aus dem Dateinamen von hochgeladenen Dateien in einer Webanwendung entfernt werden (z. B.: „ ; : > < / \ . * % $“). | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-058 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.4 (APP.3.1.A14), Regelungen für Webanwendungen und Webservices: Die Zugriffsberechtigungen auf Dateien mit dem Quelltext der Webanwendung und der Zugangsdaten sollen restriktiv gesetzt werden, so dass diese auch nicht über die Webanwendung abgerufen werden können. Die Webanwendung soll durch Zugriffsbeschränkungen auf Webanwendungsebene und durch restriktive Dateisystemberechtigungen geschützt werden. Bei der Vergabe von Zugriffsrechten sollen alle von der Webanwendung verwalteten Ressourcen berücksichtigt werden. Bei fehlerhafter Zugriffskontrolle sollen Verbindungen abgewiesen werden. Der Zugriff auf (temporäre) Dateien, Objekt-Referenzen und URL-Aufrufe soll ebenfalls restriktiv geregelt werden. Der Zugriff auf Dateien durch die Benutzer der Webanwendung soll durch restriktive Dateisystemberechtigungen beschränkt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-059 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.5 (APP.3.1.A11), Regelungen für Webanwendungen und Webservices: Der Zugriff auf Backend-Systeme, wie Datenbanken oder Fileserver, soll ausschließlich über definierte Schnittstellen und Systeme möglich sein. Die Zugriffe sollen verschlüsselt stattfinden. Die zur Absicherung des Kommunikationsaufbaus verwendeten Server-Zertifikate sollten durch die interne Zertifizierungsstelle der ALDB ausgestellt werden. Die Session Renegotiation soll für TLS-Verbindungen unterbunden werden. TLS-Kompression soll deaktiviert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-060 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.6 (APP.3.1.A12), Regelungen für Webanwendungen und Webservices: Webanwendungen und Webservices sollen so konfiguriert werden, dass auf die Ressourcen und Funktionen ausschließlich über vorgesehene Kommunikationspfade zugegriffen werden kann. Der Zugriff auf nicht benötigte Ressourcen und Funktionen soll deaktiviert oder eingeschränkt werden, falls eine Deaktivierung nicht möglich ist. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-061 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.7 (APP.3.1.A12), Regelungen für Webanwendungen und Webservices: Alle nicht benötigten HTTP-Methoden einer Webanwendung (z. B. GET, POST, PUT, DELETE oder TRACE) sollen deaktiviert werden und sollen von der Webanwendung nicht bearbeitet werden. Schützenswerte Daten (Kundendaten, VS, firmenvertraulich) sollen innerhalb einer Webanwendung ausschließlich über die POST-Methode übertragen werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-062 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.8 (APP.3.1.A12), Regelungen für Webanwendungen und Webservices: Die genutzte Zeichenkodierung soll entsprechend der tatsächlichen Notwendigkeit konfiguriert sein, andere sollen nicht zugelassen werden. Damit Clients Daten an die Webanwendung in der gewünschten Kodierung senden, soll die Webanwendung bei der Auslieferung von Webseiten in den Header-Feldern der HTTP-Response das Zeichenkodierungsschema (z. B. UTF-8) mit angeben. Falls die Webanwendung international verwendet wird, soll darauf geachtet werden, dass alle internationalen Zeichensätze auf allen logischen Ebenen der Webanwendung und von den angebundenen Hintergrundsystemen unterstützt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-063 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.9 (APP.3.1.A12), Regelungen für Webanwendungen und Webservices: Fehlermeldungen sollen keine Informationen zur Webanwendung, Webservice, genutzten Versionen oder Konfiguration ausgeben. Um potentiellen Angreifern keine Hinweise zu geben, sollen Ausgaben, insbesondere Fehlermeldungen, so gestaltet werden, dass keine Rückschlüsse auf das verwendete System (z.B. Produkt- bzw. Versionsangaben) oder die Struktur der dahinterliegenden Datenbank verraten werden. Um automatisierte Angriffe zu verhindern, sollen bei zurückgewiesenen Eingaben durch die Webanwendung keine Informationen über die Ursache (wie z.B. unbekannter Account, falsches Passwort) enthalten sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-064 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.10 (APP.3.1.A12), Regelungen für Webanwendungen und Webservices: Konfigurationsdateien sollen zugriffsgesichert ausschließlich außerhalb des Webserver-Root-Verzeichnisses gespeichert werden. Grundsätzlich sollen Konfigurationsdaten der Webanwendung außerhalb des Quelltextes in separaten Konfigurationsdateien gespeichert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-065 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.11 (APP.3.1.A21), Regelungen für Webanwendungen und Webservices: Die Konfiguration der Webanwendung soll zum Schutz vor Clickjacking, Cross-Site-Scripting und anderen Angriffen entsprechend sicher entwickelt und konfiguriert worden sein. Dafür soll die Konfiguration für folgende Punkte für die Webanwendung evaluiert und sicher konfiguriert werden: - Content-Security-Policy - Strict-Transport-Security - Content-Type / X-Content-Type - Cache-Control - Restriktive http-Header Das clientseitige Zwischenspeichern (Cachen) von vertraulichen Daten der Webanwendung soll durch folgende Direktiven in den HTTP -Headern der Webanwendung unterbunden werden: - Cache-Control: no-cache, no-store - Pragma: no-cache - Expires: -1 - Um CSRF-Angriff (Cross-Site Request Forgery) zu erschweren, soll die Webanwendung Sicherheitsmechanismen unterstützen, die es ermöglichen, beabsichtigte Seitenaufrufe des Benutzers von unbeabsichtigt weitergeleiteten Befehlen Dritter zu unterscheiden. Zum Schutz vor Clickjacking-Angriffen sollte in den http-Response-Headern die Direktive X-FRAME-OPTIONS verwendet werden. (“Header always append X-Frame-Options <DENY;SAMEORIGIN;ALLOW-FROM [URL]>”) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-066 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.12 (APP.3.1.A21), Regelungen für Webanwendungen und Webservices: Cookies sollten mit den Attributen secure, samesite und httponly ausgegeben werden. Das Direktive secure soll gesetzt sein, damit Cookies ausschließlich über verschlüsselte Kommunikationskanäle übertragen, wie z. B. über TLS. Der Zugriff auf Cookies mit vertraulichen Daten soll so weit wie möglich eingegrenzt werden. Das Cookie-Flag für die Domain Einschränkung soll nicht gesetzt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-067 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.14 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Zur Vermeidung von SQL-Injection-Angriffen sollen Eingaben auf Korrektheit überprüft bzw. gegen Sonderzeichen gefiltert werden. Zur Vermeidung von SQL-Injection-Angriffen sollen Stored Procedures bzw. Prepared SQL-Statements verwendet werden. Dadurch werden Sonderzeichen durch das Datenbankmanagementsystem automatisch maskiert. Sollten beide Methoden nicht möglich sein, sollen SQL-Queries separat abgesichert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-068 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.15 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Es sollte auf lokale Pfadangaben verzichtet werden. Nicht benötigte Daten sollten regelmäßig gelöscht werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-069 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.16 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Aus der Dokumentation der Webanwendung bzw. des Web-Services soll hervorgehen, welche Komponenten Sicherheitsmechanismen (Benutzermanagement, Rollen- und Berechtigungskonzept, Authentisierung, Autorisierung, Session-Management, Protokollierung, Transportsicherheit) umsetzen. Ebenso soll sichtbar sein, wie die Webanwendung in die bestehende Infrastruktur integriert wird, sowie welche kryptografischen Funktionen und Verfahren eingesetzt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-070 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.17 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Die Sicherheitsmaßnahmen für den Webservice sollen definiert werden, z.B. Absicherung der Kommunikation, verwendeter Protokolle, Authentisierung, Einbindung von Application Layer Gateways, etc. Hierbei sollten möglichst zukünftige Standards und Angriffstechniken berücksichtigt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-071 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.23 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Die Serverdienste der Webanwendung (z. B. Webserver, Applikationsserver, Datenbankserver) sollen jeweils auf separaten IT-Systemen betrieben werden. Eine Trennung der Server-Rollen kann auch durch eine Servervirtualisierung umgesetzt werden. Die Rechte der einzelnen Rollen sollen soweit eingeschränkt werden, dass nur auf erforderliche Ressourcen und Dateien zugegriffen werden kann. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-072 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.24 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Bei der Änderung wichtiger Einträge sollte die Eingabe durch ein Passwort erneut verifiziert werden. Der Benutzer sollte über Änderungen per E-Mail informiert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-073 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.25 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Alle Eingabedaten von Benutzern an die Webanwendung als auch die Ausgabedaten der Webanwendung an die Clients sollen gefiltert und transformiert (Output Encoding) werden. Zugelassen werden sollen nur zu erwartende Daten. Die Validierung der Ein- und Ausgabedaten soll serverseitig erfolgen. Vor der Validierung sollte eine Kanonisierung der Daten durchgeführt werden. Fehleingaben sollten nicht automatisch behandelt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-074 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.26 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Daten, die von einer Webanwendung bzw. einem Webservice verarbeitet werden sollen, sollen kontextsensitiv mit Bezug zur weiteren Verarbeitung maskiert werden, so dass sie bei der weiteren Verarbeitung nicht als ausführbarer Code interpretiert werden können. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-075 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.27 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Grundsätzlich soll bei einer Ablehnung der Daten die angeforderte Aktion ebenfalls abgebrochen und eine neutrale Fehlermeldung ausgegeben werden. Bei Webanwendungen mit hohem Schutzbedarf soll zudem zusätzlich die Sitzung invalidiert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-076 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.28 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Es soll ein Session-Management für die Webanwendung integriert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-077 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.29 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Die Session-ID soll eine maximale Gültigkeitsdauer besitzen. Nach 600 Minuten soll eine Abfrage zur Re-Authentisierung erfolgen. Sitzungen sollen zudem nach einer Inaktivität von 30 Minuten eine Abfrage zur Authentisierung durchführen. Wird die Anfrage innerhalb von 30 Minuten nicht beantwortet, soll ein Session Timeout erfolgen. Ausgenommen sind die Wallboard-Rolle (reine Anzeige auf einem festen Gerät) und laufende Agenten-Telefonie Sitzungen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-078 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.30 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Es sollen keine extern bekannten oder erratbaren Daten (z.B. Uhrzeit) in die Berechnung der Session-ID einfließen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-079 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.31 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Unterstützt das der Webanwendung zugrunde liegende Framework die Generierung von Session-IDs, soll vorzugsweise die Funktion des Frameworks verwendet werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-080 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.32 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Die Session-ID einer Webanwendung soll nicht über die GET-Methode (also in der URL) übertragen werden. Stattdessen soll die Session-ID in Cookies übertragen werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-081 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.33 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Es soll auf allen Webseiten, für deren Abruf eine Authentisierung des Benutzers notwendig ist, eine deutlich sichtbare Abmeldemöglichkeit bestehen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-082 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.34 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Treten bei der Nutzung der Webanwendung schwerwiegende Fehler auf, sollten angeforderte Aktionen abgebrochen und zusätzlich die Sitzung beendet werden. Schwerwiegende Fehler sind z. B. auftretende Ausnahmefehler (Exceptions). Treten Fehler im Zusammenhang mit Sicherheitskomponenten der Webanwendung oder des Web-Service auf (zum Beispiel während der Autorisierung oder Authentisierung), soll die veranlasste Aktion abgebrochen und der Zugriff auf die angeforderte Ressource oder Funktion abgewiesen werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-083 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.35 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Bei der Invalidierung sollen die Sitzungsdaten server- und clientseitig vollständig gelöscht werden, sodass die Sitzung serverseitig nicht weiter akzeptiert wird und clientseitig keine Informationen über zuvor aufgebaute Sitzungen verbleiben. Dies kann z. B. durch Löschen des Cookies mit der Session-ID erfolgen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-084 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.36 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Nach bereits erfolgter Anmeldung an einer Webanwendung soll eine gegebenenfalls bestehende Session-ID durch eine neue ersetzt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-085 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.37 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Angriffsversuche sind häufig gekennzeichnet durch vielfache Fehlversuche bei der Durchführung einer Aktion. Daher sollte eine vorhandene Sitzung beendet werden, wenn eine ungewöhnlich hohe Anzahl von Fehlversuchen identifiziert wird, und anschließend eine Neuanmeldung erforderlich sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-086 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.38 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Fehler in der Webanwendung sollen von der Webanwendung selbst behandelt werden. Die Weiterleitung eines unbehandelten Fehlers an andere Komponenten (z. B. Applikationsserver) kann zu einem Verlust von Informationen führen, die zur Behandlung des Fehlers notwendig sind (z. B. zur Freigabe von gebundenen Ressourcen). Daher sollen unbehandelte Fehler nicht weitergeleitet werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-087 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.39 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Die Administration über eine Web-Oberfläche auf demselben Server soll gemieden und stattdessen die Administration über ein separates System durchgeführt werden. Falls die Administration auf demselben Server unumgänglich ist, soll die Administrationsoberfläche ausschließlich aus dem Administrationsnetz heraus erreichbar und der Zugriff durch gewöhnliche Benutzer der Webanwendung nicht möglich sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-088 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.40 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Möglichkeiten zur Administration der Webanwendung, die nicht genutzt werden (z. B. Konsole), sollen deaktiviert sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-089 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.41 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Angaben zu verwendeten Produkten und Versionen sollen vermieden werden (z. B. Applikationsframework, Webserver). | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-090 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.42 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Bei der Verwendung von XML-Strukturen für Web-Services soll deren Konformität zum XML-Schema überprüft werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-091 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.44 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Zusätzlich zur Session ID soll ein Security Token zum Schutz gegen CSRF-Angriffe erzeugt werden. Für das Security Token sollen dabei ähnliche Anforderungen gelten, die auch an die Session ID gestellt werden. Zusätzlich sollte das Referrer-Feld im http-Request als Merkmal geprüft werden, um einen beabsichtigten Aufruf von einem unbeabsichtigten zu unterscheiden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-092 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.45 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Zugriffsgeschützte Ressourcen sollen einem unbefugten Benutzer nicht als Suchergebnis präsentiert werden. Vor der Ausgabe der Suchergebnisse soll geprüft werden, ob der Benutzer über ausreichende Rechte verfügt, um diese zu betrachten. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-093 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.46 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Wenn Ressourcen der Webanwendung geschützt werden sollen, ist es nicht ausreichend, den Link auf die Ressource aus den angezeigten Webseiten zu entfernen (z. B. ein Link auf die Administrationsseite), sondern es soll ebenfalls der direkte Aufruf der Ressource über die URL geschützt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-094 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.47 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Bei indirekten Referenzen (Verweise auf Objekte) in den Seiten von Webanwendungen soll eine Zugriffskontrolle anhand von Referenzwerten (z. B. IDs) erfolgen. Des Weiteren sollte nach Möglichkeit eine zusätzliche Zugriffs-kontrolle für die angeforderten Objekte in den Hintergrund-systemen durchgeführt werden. Dies kann beispielsweise durch das Durchreichen der Benutzer-Authentisierung an die Hintergrundsysteme realisiert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-095 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.48 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Passworteingaben sollen nicht im Klartext wiedergegeben werden, sondern sollen durch sogenannte Wildcards ersetzt werden (z. B. Sterne oder Punkte). Hierfür soll in der Formulardefinition der Passwort-Feld-Typ ausgewählt werden (type="password"). | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-096 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.50 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Grundsätzlich soll vermieden werden, vertrauliche Daten an den Client zu übertragen oder auf dem Client zu speichern, da die Webanwendung keinen Einfluss auf den Schutz von clientseitig hinterlegten Daten hat. Falls nicht vermieden werden kann, dass Sitzungsdaten clientseitig gespeichert werden, sollen diese Daten verschlüsselt und vor der Verarbeitung durch die Webanwendung auf Integrität geprüft werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-097 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.51 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Dateien, die nicht für die Interpretation und den direkten Abruf durch den Benutzer vorgesehen sind, sollen von der Webanwendung nicht ausgeliefert werden. Zusätzlich sollen die Dateisystemberechtigungen auf diese Dateien restriktiv gesetzt sein. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-098 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.52 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Jeder Zugriff auf geschützte Inhalte und Funktionen soll kontrolliert werden, bevor er ausgeführt wird. Dies gilt auch dann, wenn beispielsweise der gleiche Benutzer auf eine geschützte Ressource wiederholt zugreift. Auch automatisierte Client-Requests durch Web-Technologien (z. B. Ajax) sollten als unabhängige Requests behandelt und entsprechend kontrolliert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-099 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.53 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Kommt es zu Fehlern während der Zugriffskontrolle sollen Zugriffe abgelehnt werden. Im Fehlerfall sollen keine angeforderten Ressourcen übermittelt oder Funktionen unkontrolliert ausgeführt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-100 | 4.3.6 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 3.54 (ALDB-Vorgabe), Regelungen für Webanwendungen und Webservices: Es soll einem Benutzer nicht möglich sein, eine Aktion auf eine Ressource durchzuführen, für die er keine ausreichenden Rechte hat. Falls z. B. ein authentisierter Benutzer einen URL-Parameter für die Zuordnung zu einem Bankkonto ändert, soll dieser dadurch keinen Zugriff auf ein fremdes Bankkonto erlangen. Werden die Rechte zur Durchführung einer Aktion geprüft, sollten daher ebenso alle an der Aktion beteiligten Ressourcen bei der Prüfung mit eingeschlossen werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-101 | 4.3.8 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 4.2 (ALDB-Vorgabe), Anforderungen an die Passwortverwaltung: Das System soll Passwörter unterstützen, die aus den folgenden unterschiedlichen Zeichenarten bestehen: Großbuchstaben (z. B. „A“, „Y“) Kleinbuchstaben (z. B. „h“, „z“) Ziffern (z. B. „5“, „3“) Sonderzeichen (z. B. „!“, „&“) Mindestens fünf unterschiedliche Zeichen | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-102 | 4.3.8 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 4.3 (ALDB-Vorgabe), Anforderungen an die Passwortverwaltung: Es sollen Passwörter mit mindestens 24 Zeichen länge unterstützt werden | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-103 | 4.3.8 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 4.4 (ALDB-Vorgabe), Anforderungen an die Passwortverwaltung: - Bei der Erstanmeldung soll das Initialpasswort umgehend geändert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-104 | 4.3.8 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 4.5 (ALDB-Vorgabe), Anforderungen an die Passwortverwaltung: - Passwörter sollen mindestens einmal jährlich gewechselt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-105 | 4.3.8 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 4.7 (ALDB-Vorgabe), Anforderungen an die Passwortverwaltung: - Eine Sperrung der Konten aufgrund von fehlerhaften Anmeldeversuchen soll automatisch erfolgen. - Dauer und Anzahl der zulässigen Fehlversuche ist abhängig von den Berechtigungen und der Art des Kontos. - Der Zähler für fehlerhafte Anmeldeversuche soll erst zurückgesetzt werden, sobald eine korrekte Anmeldung erfolgte bzw. nachdem das Konto wieder freigeschaltet worden ist. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-106 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.1 (SYS.1.6.A1, SYS.1.6.A4, SYS.1.6.A6, SYS.1.6.A12, SYS.1.6.A20, SYS.1.6.A22), Richtlinie für Container: Alle ALDB Anwendungscontainer sollen aus eigenem Source Code auf der Basis von minimalen Basis-Images erstellt werden. Andere Container sollen aus sicherer Quelle bezogen werden. Die Quelle soll dabei eindeutig identifizierbar sein. Die bezogenen Images sollen mit Hashes und Versionsnummern versehen sein. Diese Hashes sollen beim Import in die ALDB Registry überprüft werden. Die von extern bezogenen Container-Images sollen nicht deprecated sein und sollen stets gegen Schwachstellen und Sicherheitsprobleme überprüft werden. Die gewählten Quellen sollen dokumentiert werden. Die Container und die zu ihrer Ausführung notwendigen Konfigurationen sollen durch eine interne Registry und eine interne Versionsverwaltung verwaltet werden. Es sollen nur minimale Container-Betriebssysteme installiert werden, insbesondere unnötige Netzwerkzeuge wie curl oder wget eignen sich zum Angriff auf das Netzwerk. Container sollen gehärtet eingesetzt werden, als Basis empfehlen sich leere Images oder distroless Container. Um Container im Bedarfsfall für eine spätere Untersuchung verfügbar zu haben, sollen die Container Images in der ALDB Registry über die ID verfügbar gehalten werden. Die Beschreibung der Container-Konfigurationsdaten soll versioniert erfolgen. Änderungen sollen nachvollziehbar dokumentiert werden. Die Bereitstellung und das Ausrollen von Containern soll automatisiert erfolgen. Die Steuerung des Rollouts soll durch ein GitOps Tool wie z.B. ArgoCD gesteuert werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-107 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.2 (SYS.1.6.A2), Richtlinie für Container: Die Verwaltung der Container im laufenden Betrieb soll über eine zentral vom Betrieb gesteuerte Verwaltungssoftware betrieben werden. Der Zugriff auf die Software soll den Vorgaben des Minimalprinzips und dem Rollen- & Berechtigungskonzept folgen. Um den unkontrollierten Betrieb von Containern und ein fehlendes Patch- und Update-Management vorzubeugen, sollen Container nicht stand alone betrieben werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-108 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.6 (SYS.1.6.A3, SYS.1.6.A9), Richtlinie für Container: Alle Container sollen durch Health und Readiness Checks überwacht werden und alle Applikationen sollen dafür geeignete Endpunkte zur Überwachung zur Verfügung zu stellen. Die Performance der Verwaltungssoftware und Container-Hosts soll überwacht werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-109 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.7 (SYS.1.6.A7), Richtlinie für Container: Die Speicherung der Protokollierungsdaten der Container soll außerhalb des Containers, mindestens auf dem Container-Host, erfolgen. Die Persistenz soll vollständig auf das externe Speichersystem ausgelagert werden, das für die Datenspeicherung und Replikation ausgelegt sein soll. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-110 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.8 (SYS.1.6.A8), Richtlinie für Container: Zugangsdaten sollen weder in der Versionsverwaltung und den Konfigurationsdateien, noch im Container selbst, verwaltet werden, es soll ein Secret Management System eingesetzt werden. Der Zugriff auf Zugangsdaten im Secret Management System soll den Vorgaben des Minimalprinzips und dem Rollen- und Berechtigungskonzept folgen. Die Zugangsdaten werden in den laufenden Container als Dateien oder Environment Variables injiziert. Jeder, der Zugang zu diesen Containern hat, kann diese Daten lesen. Aus diesem Grund sind die Zugriffe auf die Container in der laufenden Umgebung auf das absolute nötigste einzuschränken. Secrets in etcd sollen verschlüsselt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-111 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.9 (SYS.1.6.A11), Richtlinie für Container: Jeder Container soll jeweils nur einen Dienst bereitstellen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-112 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.10 (SYS.1.6.A13), Richtlinie für Container: Alle Images für den produktiven Betrieb sollen wie Softwareprodukte einen Test- und Freigabeprozess gemäß des Bausteins OPS.1.1.6 Software-Test und Freigaben durchlaufen. Die Freigabe von Images soll nur erfolgen, wenn: - die Herkunft eindeutig nachgewiesen ist, idealerweise durch Signaturen, - die Security Scans den Vorgaben entsprechen, idealerweise keine oder keine schweren und kritischen Lücken existieren - die Images in einer Testinstallation die vorgegebenen Integrations- und ggf. auch Lasttests bestanden haben und - sichergestellt ist, dass ein rolling Update durchgeführt werden kann. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-113 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.11 (SYS.1.6.A14), Richtlinie für Container: Für jedes Container-Image soll dokumentiert sein, wie der Update Prozess abläuft. Container werden durch die Verwaltungssoftware aktualisiert. Dazu soll ein GitOps Tool eingesetzt werden. Der Update Prozess selbst soll in einem Test überprüft werden. Aus dem Image heraus sollen keine Änderungen an externen Systemen getriggert werden, wie z.B. Datenbank-Updates. Diese sollen in einem separaten Schritt erfolgen. Für ein Rolling Update soll sichergestellt werden, dass alte und neue Container über Versionsgrenzen zusammenarbeiten können. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-114 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.13 (SYS.1.6.A16, SYS.1.6.A21), Richtlinie für Container: Aus einem Container soll kein administrativer Zugriff auf den Container-Host erfolgen. Alle Änderungen und Zugriffe auf die laufenden Container sollen durch die Verwaltungssoftware ausgelöst werden und in den Audit-Logs sichtbar sein. Audit-Logs sollen grundsätzlich außerhalb der Verwaltungssoftware aufbewahrt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-115 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.14 (SYS.1.6.A17, SYS.1.6.A18, SYS.1.6.A21), Richtlinie für Container: Die Container-Runtime und alle instanziierten Container sollen nur von einem nicht-privilegierten System-Account ausgeführt werden, der keine erweiterten Rechte für den Container-Dienst bzw. das Betriebssystem des Host-Systems verfügt oder diese Rechte erlangen kann. Die Container-Runtime soll durch zusätzliche Maßnahmen gekapselt werden, etwa durch Verwendung der Virtualisierungs-Erweiterungen von CPUs. Es soll sichergestellt werden, dass Container, die Privilegien benötigen, vom Netzwerk getrennt werden. Es sollen, wenn nötig, Anwendungen in privilegierte und unprivilegierte Teile aufgeteilt werden, wenn z.B. nur bei der Initialisierung Systemeinstellungen verändert werden. Sofern Container ausnahmsweise Aufgaben des Host-Systems übernehmen sollen, sollen die Privilegien auf dem Host-System auf das erforderliche Minimum begrenzt werden. Ausnahmen sollen angemessen dokumentiert werden. Für Container soll immer ein angemessener, in der Regel restriktiver SecurityContext eingesetzt werden. Applikationen von Dienstleistern, die sich nicht auf einfache Weise ohne Privilegien betreiben lassen, sollen isoliert werden. Die SecurityContexte sollen überwacht werden. Die System-Accounts innerhalb eines Containers sollen keine Berechtigungen auf dem Host-System haben. Applikationen sollen nicht mit UID und GID root ausgeführt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-116 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.15 (SYS.1.6.A19), Richtlinie für Container: Die Container sollen nur auf die für den Betrieb notwendigen Massenspeicher und Verzeichnisse zugreifen können. Nur wenn Schreibrechte wirklich benötigt werden, sollen diese explizit vergeben werden. Sofern die Container-Runtime für einen Container lokalen Speicher einbindet, sollen die Zugriffsrechte im Dateisystem auf den Service-Account des Containers eingeschränkt sein. Werden Netzspeicher verwendet, so sollen die Berechtigungen auf dem Netzspeicher selbst gesetzt werden. Der Zugriff auf das Hostfilesystem soll nur in Ausnahmefällen, wenn eine Applikation schnellen, lokalen Storage benötigt, erlaubt werden. Er soll auf eine eigene Partition beschränkt und gesondert überwacht werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-117 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 5.16 (SYS.1.6.A23), Richtlinie für Container: Nicht-persistente Container sollen ihr Dateisystem während der Laufzeit nicht verändern können. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-118 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 6.2 (SYS.1.5.A2, SYS.1.5.A4, SYS.1.5.A6, SYS.1.5.A15), Richtlinie Virtualisierung: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: Virtuelle Netze werden analog zu physikalischen Netzen geplant und folgen den Vorgaben des Netzkonzepts. Innerhalb der Virtualisierung werden keine Netze konfiguriert, die dem Netzkonzept widersprechen, Sicherheitsfunktionen (wie ALGs oder Firewalls) umgehen oder Netze überbrücken. Alle vorgesehenen Netzverbindungen stehen innerhalb der Virtualisierungsumgebung zur Verfügung; ihre Zuordnung wird überwacht. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-119 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 6.3 (SYS.1.5.A2, SYS.1.5.A15), Richtlinie Virtualisierung: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: Die Isolation und Kapselung der Systeme in der Virtualisierungsumgebung wird auf Ebene der Hypervisor sichergestellt. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-120 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 6.4 (SYS.1.5.A2, SYS.1.5.A6, SYS.1.5.A17), Richtlinie Virtualisierung: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: Host- und Gastsysteme der Virtualisierungsumgebung werden überwacht, um die Verfügbarkeitsanforderungen einzuhalten. Stößt ein Host an die Grenzen seiner Kapazität, werden virtuelle Systeme automatisch verschoben; erreicht die Umgebung ihre Kapazitätsgrenzen, beschafft die ALDB frühzeitig neue Hardware. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-121 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 6.5 (SYS.1.5.A3, SYS.1.5.A23), Richtlinie Virtualisierung: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: Gastbetriebssysteme greifen nicht unkontrolliert auf Funktionen, Geräte und Schnittstellen des Hosts zu. Ist dies aufgrund der Anforderungen der Lösung zwingend notwendig, wird es explizit für das zugehörige System freigegeben und dokumentiert. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-122 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 6.11 (SYS.1.5.A16), Richtlinie Virtualisierung: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: Copy/Paste zwischen virtuellen Maschinen über die Zwischenablage ist deaktiviert. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-123 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 6.15 (SYS.1.5.A25), Richtlinie Virtualisierung: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: Ein Zugriff auf die Gastbetriebssysteme über die Konsole der Virtualisierungsumgebung erfolgt nur im Notfall; die Gastbetriebssysteme werden über das Netz verwaltet, z. B. über SSH oder RDP. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-124 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 6.20 (ALDB-Vorgabe), Richtlinie Virtualisierung: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: Für alle Benutzer der Verwaltungsschnittstellen wird eine Authentisierung erzwungen; anonyme Zugriffe sind nicht erlaubt. Die Authentisierungsdaten werden verschlüsselt übertragen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-125 | 4.3 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 6.22 (ALDB-Vorgabe), Richtlinie Virtualisierung: Die Lösung ist betreibbar unter folgender Vorgabe der ALDB-Plattform: Werden in der virtualisierten Infrastruktur Funktionen wie die Migration zur Laufzeit genutzt, wird die Laufzeitumgebung der virtuellen IT-Systeme mit allen darin verarbeiteten, möglicherweise hoch schutzbedürftigen Daten über das Netz übertragen. Das hierfür verwendete Netz ist separiert, sofern ein ungesichertes Netz verwendet wird. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-126 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.1 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Die Webapplikation soll die Authentifizierung von Benutzern gegen das angebundene Active Directory durchführen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-127 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.2 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Benutzer sollen ausschließlich nach erfolgreicher Authentifizierung im Active Directory auf die Webapplikation zugreifen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-128 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.3 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Die Webapplikation soll die im Active Directory hinterlegten Benutzerinformationen zur Anmeldung verwenden (Single Sign-on, sofern verfügbar). | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-129 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.4 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Die Zuordnung eines Benutzers zu Anwendungsprofilen und Berechtigungsrollen soll auf Basis von im Active Directory hinterlegten Gruppen oder Attributen erfolgen. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-130 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.5 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Änderungen an Gruppenmitgliedschaften oder relevanten Benutzerattributen im Active Directory sollen von der Webapplikation automatisch übernommen werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-131 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.6 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Die Webapplikation soll Benutzerprofile und Berechtigungszuordnungen nicht eigenständig pflegen, sofern diese Informationen im Active Directory vorhanden sind. Klarstellung: Das Active Directory ist führend. Lokale Notfallkonten bei AD-Ausfall (vgl. LB 4.3.8/4.3.9) sowie ACD-spezifische Profile (Skills, Routing- und Agentenprofile) in der Applikation sind zulässig. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-132 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.7 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Es soll kein Read-Only Modus existieren; ausgenommen ist die Wallboard-Rolle (reine Anzeige auf einem festen Gerät). Nicht authentifizierte Benutzer oder Benutzer ohne gültige Profilzuordnung sollen keinen Zugriff auf die Applikation erhalten. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-133 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.8 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Fehler bei der Kommunikation mit dem Active Directory sollen protokolliert und dem Benutzer in geeigneter Form angezeigt werden. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-134 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.9 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Die Kommunikation zwischen Applikation und AD soll über verschlüsselte und sichere Protokolle erfolgen | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-135 | 4.3.9 | Sicherheit & Compliance | SOLL | 3 | Sicherheitsanforderung Nr. 7.10 (ALDB Vorgabe), Rollen- und Berechtigungskonzept: Die Applikation soll das Erstellen von mehreren Profilen erlauben. Diesen Profilen sollen Berechtigungen zugeordnet werden können. Eine Berechtigung soll mehreren Profilen zugeordnet werden können. Ein Profil soll mehreren Benutzern zugewiesen werden können. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| S-136 | 2.5 | Sicherheit & Compliance | SOLL | 3 | Der Anbieter sagt zu, die Zutrittsregelungen der ALDB einzuhalten: Zutritt zu den Standorten nur nach vorheriger Anmeldung, im Regelfall vier Arbeitstage im Voraus; bei Störungen hoher Priorität verkürzt. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| 0 | 0 | 0 | 0 | 0 | 0 | |||||||||||
| 0 | 15 | 0 | 0 | 15 |