Zum Inhalt springen

APP.3.2 Webserver: Unterschied zwischen den Versionen

Aus Foxwiki
K Textersetzung - „z. B. “ durch „beispielsweise “
 
(56 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Baustein''' - Beschreibung
'''APP.3.2 Webserver''' - Kernkomponente jedes Webangebot
 
== Beschreibung ==
== Beschreibung ==
=== Einleitung ===
Webserver
* Anfragen von Clients annehmen
* Inhalte zurückliefern
; Hypertext Transfer Protocol (HTTP)
Verschlüsselt über [[HTTPS]]
* [[Hypertext Transfer Protocol Secure]]
* [[Transport Layer Security]] ([[TLS]])
Da Webserver eine einfache Schnittstelle zwischen Serveranwendungen und Clients bieten, werden sie auch häufig für interne Informationen und Anwendungen in Institutionsnetzen, wie dem Intranet, eingesetzt
Webserver sind in der Regel direkt im Internet verfügbar und bieten somit eine exponierte Angriffsfläche
* Deswegen müssen sie durch geeignete Schutzmaßnahmen abgesichert werden
=== Zielsetzung ===
Schutz eines Webservers und der Informationen, die durch den Webserver bereitgestellt oder verarbeitet werden
=== Modellierung ===
Der Baustein muss auf alle Webserver des Informationsverbunds angewendet werden
=== Abgrenzung ===
Die Bezeichnung Webserver wird sowohl für die Software verwendet, welche die HTTP-Anfragen beantwortet, als auch für die IT-Systeme, auf denen diese Software ausgeführt wird
* In diesem Baustein wird vorrangig die Webserver-Software betrachtet
* Sicherheitsaspekte des IT-Systems, auf dem die Webserver-Software installiert ist, werden im Baustein SYS.1.1 Allgemeiner Server sowie den jeweiligen betriebssystemspezifischen Bausteinen betrachtet
Empfehlungen, wie Webserver in die Netzarchitektur zu integrieren und mit Firewalls abzusichern sind, finden sich in den Bausteinen NET.1.1 Netzarchitektur und -design bzw. NET.3.2 Firewall
Der Baustein behandelt grundsätzliche Aspekte, die für die Bereitstellung von Webinhalten wichtig sind
* Dynamische Inhalte, die durch Webanwendungen bereitgestellt werden, sind nicht Gegenstand des vorliegenden Bausteins
* Diese werden im Baustein APP.3.1 Webanwendungen und Webservices behandelt
* Ebenso werden hier keine Webservices betrachtet
Webbrowser werden in diesem Baustein nicht betrachtet
* Anforderungen dazu sind im Baustein APP.1.2 Webbrowser zu finden
In der Regel werden die Verbindungen zu Webservern verschlüsselt
* Der Baustein CON.1 Kryptokonzept beschreibt, wie die dazu notwendigen kryptografischen Schlüssel sicher verwaltet werden können
Werden Webserver nicht selbst betrieben, sondern über einen Hosting-Anbieter bereitgestellt, ist der Baustein OPS.2.3 Nutzung von Outsourcing zu beachten
Oft werden Authentisierungsmechanismen für Webserver verwendet
* Ergänzende Anforderungen dazu finden sich im Baustein ORP.4 Identitäts- und Berechtigungsmanagement
== Abgrenzung und Modellierung ==
== Abgrenzung und Modellierung ==
== Gefährdungslage ==
== Gefährdungslage ==
; Typische Szenarien
; Typische Szenarien
Zeile 8: Zeile 54:
! Gefährdung !! Beschreibung
! Gefährdung !! Beschreibung
|-
|-
| [[#Gefährdung1|Gefährdung1]] || Beschreibung  
| [[#Gefährdung1|Gefährdung1]] || Beschreibung
|-
|-
| [[#Gefährdung2|Gefährdung2]] || Beschreibung  
| [[#Gefährdung2|Gefährdung2]] || Beschreibung
|-
|-
| [[#Gefährdung3|Gefährdung3]] || Beschreibung  
| [[#Gefährdung3|Gefährdung3]] || Beschreibung
|}
|}
== Zuständigkeiten ==
== Anforderungen ==
=== Basis ===
Die folgenden Anforderungen MÜSSEN für diesen Baustein vorrangig erfüllt werden.


==== APP.3.2.A1 Sichere Konfiguration eines Webservers ====
Nachdem der IT-Betrieb einen Webserver installiert hat, MUSS er eine sichere Grundkonfiguration vornehmen.
* Dazu MUSS er insbesondere den Webserver-Prozess einem Konto mit minimalen Rechten zuweisen.
* Der Webserver MUSS in einer gekapselten Umgebung ausgeführt werden, sofern dies vom Betriebssystem unterstützt wird.
* Ist dies nicht möglich, SOLLTE jeder Webserver auf einem eigenen physischen oder virtuellen Server ausgeführt werden.


Dem Webserver-Dienst MÜSSEN alle nicht notwendige Schreibberechtigungen entzogen werden.
; Gefährdungslage
* Nicht benötigte Module und Funktionen des Webservers MÜSSEN deaktiviert werden.
Da IT-Grundschutz-Bausteine nicht auf individuelle Informationsverbünde eingehen können, werden zur Darstellung der Gefährdungslage typische Szenarien zugrunde gelegt
* Die folgenden spezifischen Bedrohungen und Schwachstellen sind für den Baustein APP.3.2 Webserver von besonderer Bedeutung


==== APP.3.2.A2 Schutz der Webserver-Dateien ====
=== Reputationsverlust ===
Der IT-Betrieb MUSS alle Dateien auf dem Webserver, insbesondere Skripte und Konfigurationsdateien, so schützen, dass sie nicht unbefugt gelesen und geändert werden können.
Gelingt es bei einem Angriff mit administrativen Rechten auf einen Webserver zuzugreifen, kann darüber eine manipulierte Webseite ausgeliefert werden (Defacement)
* So kann die Reputation der Institution geschädigt werden
* Ebenso kann die Veröffentlichung falscher Informationen, wie zum Beispiel fehlerhafter Produktbeschreibungen, dazu führen, dass die Reputation der Institution in der Öffentlichkeit leidet
* Auch kann die Institution abgemahnt werden, wenn auf ihrer Webseite Inhalte veröffentlicht werden, die gegen gesetzliche Vorschriften verstoßen
* Ein Schaden kann auch entstehen, wenn die Webseite nicht verfügbar ist und potenzielle Kunden und Kundinnen deshalb zu Mitbewerbern wechseln


Es MUSS sichergestellt werden, dass Webanwendungen nur auf einen definierten Verzeichnisbaum zugreifen können (WWW-Wurzelverzeichnis).
=== Manipulation des Webservers ===
* Der Webserver MUSS so konfiguriert sein, dass er nur Dateien ausliefert, die sich innerhalb des WWW-Wurzelverzeichnisses befinden.
Bei einem Angriff könnten sich unberechtigte Personen Zugriff auf einen Webserver verschaffen und dessen Dateien manipulieren
* Es könnte beispielsweise die Konfiguration der Webserver-Software geändert werden, Schadsoftware verbreitet oder Webinhalte modifiziert werden


Der IT-Betrieb MUSS alle nicht benötigten Funktionen, die Verzeichnisse auflisten, deaktivieren.
=== Denial of Service (DoS) ===
* Vertrauliche Daten MÜSSEN vor unberechtigtem Zugriff geschützt werden.
Durch DoS-Angriffe lässt sich die Verfügbarkeit eines Webangebotes gezielt beeinträchtigen, indem beispielsweise einzelne Accounts durch fehlerhafte Anmeldungen gesperrt werden
* Insbesondere MUSS der IT-Betrieb sicherstellen, dass vertrauliche Dateien nicht in öffentlichen Verzeichnissen des Webservers liegen.
* Der IT-Betrieb MUSS regelmäßig überprüfen, ob vertrauliche Dateien in öffentlichen Verzeichnissen gespeichert wurden.


==== APP.3.2.A3 Absicherung von Datei-Uploads und -Downloads ====
Durch DDoS (Distributed Denial of Service)-Angriffe kann ein Webserver teilweise oder auch ganz ausfallen
Alle mithilfe des Webservers veröffentlichten Dateien MÜSSEN vorher auf Schadprogramme geprüft werden.
* Für Clients ist das Webangebot dann nur noch sehr langsam oder gar nicht mehr verfügbar
* Es MUSS eine Maximalgröße für Datei-Uploads spezifiziert sein.
* Für viele Institutionen kann ein solcher Ausfall schnell geschäftskritisch werden, z. B.  für Online-Shops
* Für Uploads MUSS genügend Speicherplatz reserviert werden.


==== APP.3.2.A4 Protokollierung von Ereignissen ====
=== Verlust vertraulicher Daten ===
Der Webserver MUSS mindestens folgende Ereignisse protokollieren:
Viele Webserver verwenden noch veraltete kryptografische Verfahren wie RC4 oder SSL
* erfolgreiche Zugriffe auf Ressourcen,
* Eine unzureichende Authentisierung bzw. eine ungeeignete Verschlüsselung kann dazu führen, dass die Kommunikation zwischen den Clients und den Webservern mitgelesen oder manipuliert werden kann
* fehlgeschlagene Zugriffe auf Ressourcen aufgrund von mangelnder Berechtigung, nicht vorhandenen Ressourcen und Server-Fehlern sowie
* Das gleiche gilt für die Kommunikation zwischen dem Webserver und anderen Servern, wie beispielsweise Load Balancern
* allgemeine Fehlermeldungen.


Die Protokollierungsdaten SOLLTEN regelmäßig ausgewertet werden.
=== Verstoß gegen Gesetze oder Regelungen ===
Für die Veröffentlichung von Webinhalten gibt es verschiedene regulatorische Anforderungen
* Neben den Regelungen der Telemedien- und Datenschutzgesetze, sind auch die Regeln des Urheberrechts zu beachten
* Verstöße gegen diese Gesetze können rechtliche Konsequenzen nach sich ziehen


==== APP.3.2.A5 Authentisierung ====
=== Fehlende oder mangelhafte Fehlerbehebung ===
Wenn sich Clients mit Hilfe von Passwörtern am Webserver authentisieren, MÜSSEN diese kryptografisch gesichert und vor unbefugtem Zugriff geschützt gespeichert werden.
Treten während des Betriebs eines Webservers Fehler auf, kann sich das beispielsweise auf dessen Verfügbarkeit auswirken
* Auch werden eventuell Inhalte unvollständig dargestellt oder Sicherheitsmechanismen fallen aus
* Werden Fehler nicht korrekt behandelt, sind sowohl der Betrieb als auch der Schutz der Funktionen und Daten eines Webservers nicht mehr gewährleistet


==== APP.3.2.A6 ENTFALLEN ====
== Zuständigkeiten ==
Diese Anforderung ist entfallen.
Der oder die Informationssicherheitsbeauftragte (ISB) ist dafür zuständig, dass alle Anforderungen gemäß dem festgelegten Sicherheitskonzept erfüllt und überprüft werden
* Bei strategischen Entscheidungen ist der oder die ISB stets einzubeziehen


==== APP.3.2.A7 Rechtliche Rahmenbedingungen für Webangebote [Fachverantwortliche, Zentrale Verwaltung, Compliance-Beauftragte] ====
Im IT-Grundschutz/Kompendium sind darüber hinaus weitere Rollen definiert
Werden über den Webserver Inhalte für Dritte publiziert oder Dienste angeboten, MÜSSEN dabei die relevanten rechtlichen Rahmenbedingungen beachtet werden.
* Sie sollten besetzt werden, insofern dies sinnvoll und angemessen ist
* Die Institution MUSS die jeweiligen Telemedien- und Datenschutzgesetze sowie das Urheberrecht einhalten.


==== APP.3.2.A11 Verschlüsselung über TLS ====
{| style="border-spacing:0;width:17cm;"
Der Webserver MUSS für alle Verbindungen durch nicht vertrauenswürdige Netze eine sichere Verschlüsselung über TLS anbieten (HTTPS).
|- style="background-color:#f0f0f0;border:0.5pt solid #000000;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"
* Falls es aus Kompatibilitätsgründen erforderlich ist, veraltete Verfahren zu verwenden, SOLLTEN diese auf so wenige Fälle wie möglich beschränkt werden.
!| Zuständigkeiten
!| Rollen
|- style="background-color:transparent;border:0.5pt solid #000000;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"
|| Grundsätzlich zuständig
|| IT-Betrieb
|- style="background-color:transparent;border:0.5pt solid #000000;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"
|| Weitere Zuständigkeiten
|| Fachverantwortliche, Compliance-Beauftragte, Zentrale Verwaltung
|-
|}


Wenn eine HTTPS-Verbindung genutzt wird, MÜSSEN alle Inhalte über HTTPS ausgeliefert werden.
; Genau eine Rolle sollte Grundsätzlich zuständig sein
* Sogenannter Mixed Content DARF NICHT verwendet werden.
* Darüber hinaus kann es noch Weitere Zuständigkeiten geben
* Falls eine dieser weiteren Rollen für die Erfüllung einer Anforderung vorrangig zuständig ist, dann wird diese Rolle hinter der Überschrift der Anforderung in eckigen Klammern aufgeführt
* Die Verwendung des Singulars oder Plurals sagt nichts darüber aus, wie viele Personen diese Rollen ausfüllen sollen


=== Standard ===
== Basis-Anforderungen ==
Gemeinsam mit den Basis-Anforderungen entsprechen die folgenden Anforderungen dem Stand der Technik für diesen Baustein.
Die folgenden Anforderungen [[MÜSSEN]] für diesen Baustein vorrangig erfüllt werden
* Sie SOLLTEN grundsätzlich erfüllt werden.


==== APP.3.2.A8 Planung des Einsatzes eines Webservers ====
{| class="wikitable options col1center"
Es SOLLTE geplant und dokumentiert werden, für welchen Zweck der Webserver eingesetzt und welche Inhalte er bereitstellen soll.
! Anforderung || Beschreibung
* In der Dokumentation SOLLTEN auch die Informationen oder Dienstleistungen des Webangebots und die jeweiligen Zielgruppen beschrieben werden.
|-
* Für den technischen Betrieb und die Webinhalte SOLLTEN geeignete Zuständige festgelegt werden.
| A1 || Sichere Konfiguration eines Webservers
|-
| A2 || Schutz der Webserver-Dateien
|-
| A3 || Absicherung von Datei-Uploads und -Downloads
|-
|A4 || Protokollierung von Ereignissen
|-
|A5 || Authentisierung
|-
|| A6 || ENTFALLEN
|-
| A7 || Rechtliche Rahmenbedingungen für Webangebote [Fachverantwortliche, Zentrale Verwaltung, Compliance-Beauftragte]
|-
| A11 || Verschlüsselung über TLS
|}


==== APP.3.2.A9 Festlegung einer Sicherheitsrichtlinie für den Webserver ====
==== A1 Sichere Konfiguration eines Webservers ====
Es SOLLTE eine Sicherheitsrichtlinie erstellt werden, in der die erforderlichen Maßnahmen und Zuständigkeiten benannt sind.
Nachdem der IT-Betrieb einen Webserver installiert hat, MUSS er eine sichere Grundkonfiguration vornehmen
* Weiterhin SOLLTE geregelt werden, wie Informationen zu aktuellen Sicherheitslücken besorgt werden.
* Dazu MUSS er insbesondere den Webserver-Prozess einem Konto mit minimalen Rechten zuweisen
* Auch SOLLTE geregelt werden, wie Sicherheitsmaßnahmen umgesetzt werden und wie vorgegangen werden soll, wenn Sicherheitsvorfälle eintreten.
* Der Webserver MUSS in einer gekapselten Umgebung ausgeführt werden, sofern dies vom Betriebssystem unterstützt wird
* Ist dies nicht möglich, SOLLTE jeder Webserver auf einem eigenen physischen oder virtuellen Server ausgeführt werden


==== APP.3.2.A10 Auswahl eines geeigneten Webhosters ====
Dem Webserver-Dienst MÜSSEN alle nicht notwendige Schreibberechtigungen entzogen werden
Betreibt die Institution den Webserver nicht selbst, sondern nutzt Angebote externer Unternehmen im Rahmen von Webhosting, SOLLTE die Institution bei der Auswahl eines geeigneten Webhosters auf folgende Punkte achten:
* Nicht benötigte Module und Funktionen des Webservers MÜSSEN deaktiviert werden
* Es SOLLTE vertraglich geregelt werden, wie die Dienste zu erbringen sind.
* Dabei SOLLTEN Sicherheitsaspekte innerhalb des Vertrags schriftlich in einem Service Level Agreement (SLA) festgehalten werden.
* Die eingesetzten IT-Systeme SOLLTEN vom Webhoster regelmäßig kontrolliert und gewartet werden.
* Der Webhoster SOLLTE dazu verpflichtet werden, bei technischen Problemen oder einer Kompromittierung von Kundschaftssystemen zeitnah zu reagieren.
* Der Webhoster SOLLTE grundlegende technische und organisatorische Maßnahmen umsetzen, um seinen Informationsverbund zu schützen.


==== APP.3.2.A12 Geeigneter Umgang mit Fehlern und Fehlermeldungen ====
==== A2 Schutz der Webserver-Dateien ====
Aus den HTTP-Informationen und den angezeigten Fehlermeldungen SOLLTEN weder der Produktname noch die verwendete Version des Webservers ersichtlich sein.
Der IT-Betrieb MUSS alle Dateien auf dem Webserver, insbesondere Skripte und Konfigurationsdateien, so schützen, dass sie nicht unbefugt gelesen und geändert werden können
* Fehlermeldungen SOLLTEN keine Details zu Systeminformationen oder Konfigurationen ausgeben.
* Der IT-Betrieb SOLLTE sicherstellen, dass der Webserver ausschließlich allgemeine Fehlermeldungen ausgibt, die Clients darauf hinweisen, dass ein Fehler aufgetreten ist.
* Die Fehlermeldung SOLLTE ein eindeutiges Merkmal enthalten, das es dem IT-Betrieb ermöglicht, den Fehler nachzuvollziehen.
* Bei unerwarteten Fehlern SOLLTE sichergestellt sein, dass der Webserver nicht in einem Zustand verbleibt, in dem er anfällig für Angriffe ist.


==== APP.3.2.A13 Zugriffskontrolle für Webcrawler ====
Es MUSS sichergestellt werden, dass Webanwendungen nur auf einen definierten Verzeichnisbaum zugreifen können (WWW-Wurzelverzeichnis)
Der Zugriff von Webcrawlern SOLLTE nach dem Robots-Exclusion-Standard geregelt werden.
* Der Webserver MUSS so konfiguriert sein, dass er nur Dateien ausliefert, die sich innerhalb des WWW-Wurzelverzeichnisses befinden
* Inhalte SOLLTEN mit einem Zugriffsschutz versehen werden, um sie vor Webcrawlern zu schützen, die sich nicht an diesen Standard halten.


==== APP.3.2.A14 Integritätsprüfungen und Schutz vor Schadsoftware ====
Der IT-Betrieb MUSS alle nicht benötigten Funktionen, die Verzeichnisse auflisten, deaktivieren
Der IT-Betrieb SOLLTE regelmäßig prüfen, ob die Konfigurationen des Webservers und die von ihm bereitgestellten Dateien noch integer sind und nicht durch Angriffe verändert wurden.
* Vertrauliche Daten MÜSSEN vor unberechtigtem Zugriff geschützt werden
* Die zur Veröffentlichung vorgesehenen Dateien SOLLTEN regelmäßig auf Schadsoftware geprüft werden.
* Insbesondere MUSS der IT-Betrieb sicherstellen, dass vertrauliche Dateien nicht in öffentlichen Verzeichnissen des Webservers liegen
* Der IT-Betrieb MUSS regelmäßig überprüfen, ob vertrauliche Dateien in öffentlichen Verzeichnissen gespeichert wurden


==== APP.3.2.A16 Penetrationstest und Revision ====
==== A3 Absicherung von Datei-Uploads und -Downloads ====
Webserver SOLLTEN regelmäßig auf Sicherheitsprobleme hin überprüft werden.
Alle mithilfe des Webservers veröffentlichten Dateien MÜSSEN vorher auf Schadprogramme geprüft werden
* Auch SOLLTEN regelmäßig Revisionen durchgeführt werden.
* Es MUSS eine Maximalgröße für Datei-Uploads spezifiziert sein
* Die Ergebnisse SOLLTEN nachvollziehbar dokumentiert, ausreichend geschützt und vertraulich behandelt werden.
* Für Uploads MUSS genügend Speicherplatz reserviert werden
* Abweichungen SOLLTE nachgegangen werden.
* Die Ergebnisse SOLLTEN dem ISB vorgelegt werden.


==== APP.3.2.A20 Benennung von Anzusprechenden [Zentrale Verwaltung] ====
==== A4 Protokollierung von Ereignissen ====
Bei umfangreichen Webangeboten SOLLTE die Institution zentrale Anzusprechende für die Webangebote bestimmen.
Der Webserver MUSS mindestens folgende Ereignisse protokollieren:
* Es SOLLTEN Prozesse, Vorgehensweisen und Zuständige für Probleme oder Sicherheitsvorfälle benannt werden.
* erfolgreiche Zugriffe auf Ressourcen,
 
* fehlgeschlagene Zugriffe auf Ressourcen aufgrund von mangelnder Berechtigung, nicht vorhandenen Ressourcen und Server-Fehlern sowie
Die Institution SOLLTE eine Kontaktmöglichkeit auf ihrer Webseite veröffentlichen, über die Sicherheitsprobleme an die Institution gemeldet werden können.
* allgemeine Fehlermeldungen
* Für die Behandlung von externen Sicherheitsmeldungen SOLLTE die Institution Prozesse definieren.


=== Erhöht ===
Die Protokollierungsdaten SOLLTEN regelmäßig ausgewertet werden
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Links ====
===== Weblinks =====


=== Wissenswertes ===
==== A5 Authentisierung ====
Das Bundesamt für Sicherheit in der Informationstechnik hat folgende weiterführende Dokumente veröffentlicht, die für den Betrieb von Webservern relevant sein können:
Wenn sich Clients mit Hilfe von Passwörtern am Webserver authentisieren, MÜSSEN diese kryptografisch gesichert und vor unbefugtem Zugriff geschützt gespeichert werden
* Migration auf TLS 1.2 - Handlungsleitfaden
* Sicheres Webhosting: Handlungsempfehlung für Webhoster
* Sicheres Bereitstellen von Webangeboten (ISi-Webserver)


Das National Institute of Standards and Technology (NIST) stellt in seinem Dokument „Guideline on Securing Public Web Servers“ Hinweise zur Absicherung von Webservern zur Verfügung.
==== A6 ENTFALLEN ====
Diese Anforderung ist entfallen


= TMP =
==== A7 Rechtliche Rahmenbedingungen für Webangebote [Fachverantwortliche, Zentrale Verwaltung, Compliance-Beauftragte] ====
== Beschreibung ==
Werden über den Webserver Inhalte für Dritte publiziert oder Dienste angeboten, MÜSSEN dabei die relevanten rechtlichen Rahmenbedingungen beachtet werden
=== Einleitung ===
* Die Institution MUSS die jeweiligen Telemedien- und Datenschutzgesetze sowie das Urheberrecht einhalten
Ein Webserver ist die Kernkomponente jedes Webangebotes, er nimmt Anfragen der Clients entgegen und liefert die entsprechenden Inhalte zurück.
* Die Daten werden in der Regel über das Hypertext Transfer Protocol (HTTP) oder dessen mit Transport Layer Security (TLS) verschlüsselte Variante HTTP Secure (HTTPS) transportiert.
* Da Webserver eine einfache Schnittstelle zwischen Serveranwendungen und Clients bieten, werden sie auch häufig für interne Informationen und Anwendungen in Institutionsnetzen, wie dem Intranet, eingesetzt.


Webserver sind in der Regel direkt im Internet verfügbar und bieten somit eine exponierte Angriffsfläche.
==== A11 Verschlüsselung über TLS ====
* Deswegen müssen sie durch geeignete Schutzmaßnahmen abgesichert werden.
Der Webserver MUSS für alle Verbindungen durch nicht vertrauenswürdige Netze eine sichere Verschlüsselung über TLS anbieten (HTTPS)
* Falls es aus Kompatibilitätsgründen erforderlich ist, veraltete Verfahren zu verwenden, SOLLTEN diese auf so wenige Fälle wie möglich beschränkt werden


=== Zielsetzung ===
Wenn eine HTTPS-Verbindung genutzt wird, MÜSSEN alle Inhalte über HTTPS ausgeliefert werden
Ziel dieses Bausteins ist der Schutz des Webservers und der Informationen, die durch den Webserver bereitgestellt oder damit verarbeitet werden.
* Sogenannter Mixed Content DARF NICHT verwendet werden


=== Abgrenzung und Modellierung ===
== Standard-Anforderungen ==
Der Baustein muss auf alle Webserver des Informationsverbunds angewendet werden.
Gemeinsam mit den Basis-Anforderungen entsprechen die folgenden Anforderungen dem Stand der Technik für diesen Baustein
* Sie SOLLTEN grundsätzlich erfüllt werden


Die Bezeichnung Webserver wird sowohl für die Software verwendet, welche die HTTP-Anfragen beantwortet, als auch für die IT-Systeme, auf denen diese Software ausgeführt wird.
{| class="wikitable options col1center"
* In diesem Baustein wird vorrangig die Webserver-Software betrachtet.
! Anforderung || Beschreibung
* Sicherheitsaspekte des IT-Systems, auf dem die Webserver-Software installiert ist, werden im Baustein SYS.1.1 Allgemeiner Server sowie den jeweiligen betriebssystemspezifischen Bausteinen betrachtet.
|-
| A8 || Planung des Einsatzes eines Webservers
|-
| A9 || Festlegung einer Sicherheitsrichtlinie für den Webserver
|-
| A10 || Auswahl eines geeigneten Webhosters
|-
| A12 || Geeigneter Umgang mit Fehlern und Fehlermeldungen
|-
| A13 || Zugriffskontrolle für Webcrawler
|-
| A14 || Integritätsprüfungen und Schutz vor Schadsoftware
|-
| A16 || Penetrationstest und Revision
|-
| A20 || Benennung von Anzusprechenden [Zentrale Verwaltung]
|}


Empfehlungen, wie Webserver in die Netzarchitektur zu integrieren und mit Firewalls abzusichern sind, finden sich in den Bausteinen NET.1.1 Netzarchitektur und -design bzw.&nbsp;NET.3.2 Firewall.


Der Baustein behandelt grundsätzliche Aspekte, die für die Bereitstellung von Webinhalten wichtig sind.
==== A8 Planung des Einsatzes eines Webservers ====
* Dynamische Inhalte, die durch Webanwendungen bereitgestellt werden, sind nicht Gegenstand des vorliegenden Bausteins.
Es SOLLTE geplant und dokumentiert werden, für welchen Zweck der Webserver eingesetzt und welche Inhalte er bereitstellen soll
* Diese werden im Baustein APP.3.1 Webanwendungen und Webservices behandelt.
* In der Dokumentation SOLLTEN auch die Informationen oder Dienstleistungen des Webangebots und die jeweiligen Zielgruppen beschrieben werden
* Ebenso werden hier keine Webservices betrachtet.
* Für den technischen Betrieb und die Webinhalte SOLLTEN geeignete Zuständige festgelegt werden


Webbrowser werden in diesem Baustein nicht betrachtet.
==== A9 Festlegung einer Sicherheitsrichtlinie für den Webserver ====
* Anforderungen dazu sind im Baustein APP.1.2 Webbrowser zu finden.
Es SOLLTE eine Sicherheitsrichtlinie erstellt werden, in der die erforderlichen Maßnahmen und Zuständigkeiten benannt sind
* Weiterhin SOLLTE geregelt werden, wie Informationen zu aktuellen Sicherheitslücken besorgt werden
* Auch SOLLTE geregelt werden, wie Sicherheitsmaßnahmen umgesetzt werden und wie vorgegangen werden soll, wenn Sicherheitsvorfälle eintreten


In der Regel werden die Verbindungen zu Webservern verschlüsselt.
==== A10 Auswahl eines geeigneten Webhosters ====
* Der Baustein CON.1 Kryptokonzept beschreibt, wie die dazu notwendigen kryptografischen Schlüssel sicher verwaltet werden können.
Betreibt die Institution den Webserver nicht selbst, sondern nutzt Angebote externer Unternehmen im Rahmen von Webhosting, SOLLTE die Institution bei der Auswahl eines geeigneten Webhosters auf folgende Punkte achten:
* Es SOLLTE vertraglich geregelt werden, wie die Dienste zu erbringen sind
* Dabei SOLLTEN Sicherheitsaspekte innerhalb des Vertrags schriftlich in einem Service Level Agreement (SLA) festgehalten werden
* Die eingesetzten IT-Systeme SOLLTEN vom Webhoster regelmäßig kontrolliert und gewartet werden
* Der Webhoster SOLLTE dazu verpflichtet werden, bei technischen Problemen oder einer Kompromittierung von Kundschaftssystemen zeitnah zu reagieren
* Der Webhoster SOLLTE grundlegende technische und organisatorische Maßnahmen umsetzen, um seinen Informationsverbund zu schützen


Werden Webserver nicht selbst betrieben, sondern über einen Hosting-Anbieter bereitgestellt, ist der Baustein OPS.2.3 Nutzung von Outsourcing zu beachten.
==== A12 Geeigneter Umgang mit Fehlern und Fehlermeldungen ====
Aus den HTTP-Informationen und den angezeigten Fehlermeldungen SOLLTEN weder der Produktname noch die verwendete Version des Webservers ersichtlich sein
* Fehlermeldungen SOLLTEN keine Details zu Systeminformationen oder Konfigurationen ausgeben
* Der IT-Betrieb SOLLTE sicherstellen, dass der Webserver ausschließlich allgemeine Fehlermeldungen ausgibt, die Clients darauf hinweisen, dass ein Fehler aufgetreten ist
* Die Fehlermeldung SOLLTE ein eindeutiges Merkmal enthalten, das es dem IT-Betrieb ermöglicht, den Fehler nachzuvollziehen
* Bei unerwarteten Fehlern SOLLTE sichergestellt sein, dass der Webserver nicht in einem Zustand verbleibt, in dem er anfällig für Angriffe ist


Oft werden Authentisierungsmechanismen für Webserver verwendet.
==== A13 Zugriffskontrolle für Webcrawler ====
* Ergänzende Anforderungen dazu finden sich im Baustein ORP.4 Identitäts- und Berechtigungsmanagement.
Der Zugriff von Webcrawlern SOLLTE nach dem Robots-Exclusion-Standard geregelt werden
* Inhalte SOLLTEN mit einem Zugriffsschutz versehen werden, um sie vor Webcrawlern zu schützen, die sich nicht an diesen Standard halten


== Gefährdungslage ==
==== A14 Integritätsprüfungen und Schutz vor Schadsoftware ====
Da IT-Grundschutz-Bausteine nicht auf individuelle Informationsverbünde eingehen können, werden zur Darstellung der Gefährdungslage typische Szenarien zugrunde gelegt.
Der IT-Betrieb SOLLTE regelmäßig prüfen, ob die Konfigurationen des Webservers und die von ihm bereitgestellten Dateien noch integer sind und nicht durch Angriffe verändert wurden
* Die folgenden spezifischen Bedrohungen und Schwachstellen sind für den Baustein APP.3.2 Webserver von besonderer Bedeutung.
* Die zur Veröffentlichung vorgesehenen Dateien SOLLTEN regelmäßig auf Schadsoftware geprüft werden


=== Reputationsverlust ===
==== A16 Penetrationstest und Revision ====
Gelingt es bei einem Angriff mit administrativen Rechten auf einen Webserver zuzugreifen, kann darüber eine manipulierte Webseite ausgeliefert werden (Defacement).
Webserver SOLLTEN regelmäßig auf Sicherheitsprobleme hin überprüft werden
* So kann die Reputation der Institution geschädigt werden.
* Auch SOLLTEN regelmäßig Revisionen durchgeführt werden
* Ebenso kann die Veröffentlichung falscher Informationen, wie zum Beispiel fehlerhafter Produktbeschreibungen, dazu führen, dass die Reputation der Institution in der Öffentlichkeit leidet.
* Die Ergebnisse SOLLTEN nachvollziehbar dokumentiert, ausreichend geschützt und vertraulich behandelt werden
* Auch kann die Institution abgemahnt werden, wenn auf ihrer Webseite Inhalte veröffentlicht werden, die gegen gesetzliche Vorschriften verstoßen.
* Abweichungen SOLLTE nachgegangen werden
* Ein Schaden kann auch entstehen, wenn die Webseite nicht verfügbar ist und potenzielle Kunden und Kundinnen deshalb zu Mitbewerbern wechseln.
* Die Ergebnisse SOLLTEN dem ISB vorgelegt werden


=== Manipulation des Webservers ===
==== A20 Benennung von Anzusprechenden [Zentrale Verwaltung] ====
Bei einem Angriff könnten sich unberechtigte Personen Zugriff auf einen Webserver verschaffen und dessen Dateien manipulieren.
Bei umfangreichen Webangeboten SOLLTE die Institution zentrale Anzusprechende für die Webangebote bestimmen
* Es könnte beispielsweise die Konfiguration der Webserver-Software geändert werden, Schadsoftware verbreitet oder Webinhalte modifiziert werden.
* Es SOLLTEN Prozesse, Vorgehensweisen und Zuständige für Probleme oder Sicherheitsvorfälle benannt werden


=== Denial of Service (DoS) ===
Die Institution SOLLTE eine Kontaktmöglichkeit auf ihrer Webseite veröffentlichen, über die Sicherheitsprobleme an die Institution gemeldet werden können
Durch DoS-Angriffe lässt sich die Verfügbarkeit eines Webangebotes gezielt beeinträchtigen, indem beispielsweise einzelne Accounts durch fehlerhafte Anmeldungen gesperrt werden.
* Für die Behandlung von externen Sicherheitsmeldungen SOLLTE die Institution Prozesse definieren


Durch DDoS (Distributed Denial of Service)-Angriffe kann ein Webserver teilweise oder auch ganz ausfallen.
== Erhöhter Schutzbedarf ==
* Für Clients ist das Webangebot dann nur noch sehr langsam oder gar nicht mehr verfügbar.
* Für viele Institutionen kann ein solcher Ausfall schnell geschäftskritisch werden, z.&nbsp;B. &nbsp;für Online-Shops.


=== Verlust vertraulicher Daten ===
{| class="wikitable options col1center"
Viele Webserver verwenden noch veraltete kryptografische Verfahren wie RC4 oder SSL.
! Anforderung || Beschreibung
* Eine unzureichende Authentisierung bzw.&nbsp;eine ungeeignete Verschlüsselung kann dazu führen, dass die Kommunikation zwischen den Clients und den Webservern mitgelesen oder manipuliert werden kann.
|-
* Das gleiche gilt für die Kommunikation zwischen dem Webserver und anderen Servern, wie z.&nbsp;B.&nbsp;Load Balancern.
| A15 || Redundanz
|-
| A17 || ENTFALLEN
|-
| A18 || Schutz vor Denial-of-Service-Angriffen
|-
| A19 || ENTFALLEN
|}


=== Verstoß gegen Gesetze oder Regelungen ===
Für die Veröffentlichung von Webinhalten gibt es verschiedene regulatorische Anforderungen.
* Neben den Regelungen der Telemedien- und Datenschutzgesetze, sind auch die Regeln des Urheberrechts zu beachten.
* Verstöße gegen diese Gesetze können rechtliche Konsequenzen nach sich ziehen.


=== Fehlende oder mangelhafte Fehlerbehebung ===
; Anforderungen bei erhöhtem Schutzbedarf
Treten während des Betriebs eines Webservers Fehler auf, kann sich das z.&nbsp;B.&nbsp;auf dessen Verfügbarkeit auswirken.
Im Folgenden sind für diesen Baustein exemplarische Vorschläge für Anforderungen aufgeführt, die über dasjenige Schutzniveau hinausgehen, das dem Stand der Technik entspricht
* Auch werden eventuell Inhalte unvollständig dargestellt oder Sicherheitsmechanismen fallen aus.
* Die Vorschläge SOLLTEN bei erhöhtem Schutzbedarf in Betracht gezogen werden
* Werden Fehler nicht korrekt behandelt, sind sowohl der Betrieb als auch der Schutz der Funktionen und Daten eines Webservers nicht mehr gewährleistet.
* Die konkrete Festlegung erfolgt im Rahmen einer individuellen Risikoanalyse


== Anforderungen ==
==== A15 Redundanz ====
Im Folgenden sind die spezifischen Anforderungen des Bausteins APP.3.2 Webserver aufgeführt.
Webserver SOLLTEN redundant ausgelegt werden
* Der oder die Informationssicherheitsbeauftragte (ISB) ist dafür zuständig, dass alle Anforderungen gemäß dem festgelegten Sicherheitskonzept erfüllt und überprüft werden.
* Auch die Internetanbindung des Webservers und weiterer IT-Systeme, wie etwa der Webanwendungsserver, SOLLTEN redundant ausgelegt sein
* Bei strategischen Entscheidungen ist der oder die ISB stets einzubeziehen.


Im IT-Grundschutz-Kompendium sind darüber hinaus weitere Rollen definiert.
==== A18 Schutz vor Denial-of-Service-Angriffen ====
* Sie sollten besetzt werden, insofern dies sinnvoll und angemessen ist.
Der Webserver SOLLTE ständig überwacht werden
* Des Weiteren SOLLTEN Maßnahmen definiert und umgesetzt werden, die DDoS-Angriffe verhindern oder zumindest abschwächen


{| style="border-spacing:0;width:17cm;"
|- style="background-color:#f0f0f0;border:0.5pt solid #000000;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"
!| Zuständigkeiten
!| Rollen
|- style="background-color:transparent;border:0.5pt solid #000000;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"
|| Grundsätzlich zuständig
|| IT-Betrieb
|- style="background-color:transparent;border:0.5pt solid #000000;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"
|| Weitere Zuständigkeiten
|| Fachverantwortliche, Compliance-Beauftragte, Zentrale Verwaltung
|-
|}


Genau eine Rolle sollte Grundsätzlich zuständig sein.
<noinclude>
* Darüber hinaus kann es noch Weitere Zuständigkeiten geben.
* Falls eine dieser weiteren Rollen für die Erfüllung einer Anforderung vorrangig zuständig ist, dann wird diese Rolle hinter der Überschrift der Anforderung in eckigen Klammern aufgeführt.
* Die Verwendung des Singulars oder Plurals sagt nichts darüber aus, wie viele Personen diese Rollen ausfüllen sollen.


=== Anforderungen bei erhöhtem Schutzbedarf ===
== Anhang ==
Im Folgenden sind für diesen Baustein exemplarische Vorschläge für Anforderungen aufgeführt, die über dasjenige Schutzniveau hinausgehen, das dem Stand der Technik entspricht.
=== Siehe auch ===
* Die Vorschläge SOLLTEN bei erhöhtem Schutzbedarf in Betracht gezogen werden.
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
* Die konkrete Festlegung erfolgt im Rahmen einer individuellen Risikoanalyse.
=== Links ===
==== Weblinks ====
# [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/06_APP_Anwendungen/APP_3_2_Webserver_Edition_2023.pdf?__blob=publicationFile&v=3#download=1 Webserver]


==== APP.3.2.A15 Redundanz ====
=== Wissenswertes ===
Webserver SOLLTEN redundant ausgelegt werden.
==== BSI ====
* Auch die Internetanbindung des Webservers und weiterer IT-Systeme, wie etwa der Webanwendungsserver, SOLLTEN redundant ausgelegt sein.
Das Bundesamt für Sicherheit in der Informationstechnik hat folgende weiterführende Dokumente veröffentlicht, die für den Betrieb von Webservern relevant sein können
 
* Migration auf TLS 1.2 - Handlungsleitfaden
==== APP.3.2.A17 ENTFALLEN ====
* Sicheres Webhosting: Handlungsempfehlung für Webhoster
Diese Anforderung ist entfallen.
* Sicheres Bereitstellen von Webangeboten (ISi-Webserver)
 
==== APP.3.2.A18 Schutz vor Denial-of-Service-Angriffen ====
Der Webserver SOLLTE ständig überwacht werden.
* Des Weiteren SOLLTEN Maßnahmen definiert und umgesetzt werden, die DDoS-Angriffe verhindern oder zumindest abschwächen.
 
==== APP.3.2.A19 ENTFALLEN ====
Diese Anforderung ist entfallen.


==== NIST ====
Das National Institute of Standards and Technology (NIST) stellt in seinem Dokument "Guideline on Securing Public Web Servers" Hinweise zur Absicherung von Webservern zur Verfügung


[[Kategorie:APP]]
</noinclude>
</noinclude>

Aktuelle Version vom 28. April 2025, 10:33 Uhr

APP.3.2 Webserver - Kernkomponente jedes Webangebot

Beschreibung

Einleitung

Webserver

  • Anfragen von Clients annehmen
  • Inhalte zurückliefern
Hypertext Transfer Protocol (HTTP)

Verschlüsselt über HTTPS

Da Webserver eine einfache Schnittstelle zwischen Serveranwendungen und Clients bieten, werden sie auch häufig für interne Informationen und Anwendungen in Institutionsnetzen, wie dem Intranet, eingesetzt

Webserver sind in der Regel direkt im Internet verfügbar und bieten somit eine exponierte Angriffsfläche

  • Deswegen müssen sie durch geeignete Schutzmaßnahmen abgesichert werden

Zielsetzung

Schutz eines Webservers und der Informationen, die durch den Webserver bereitgestellt oder verarbeitet werden

Modellierung

Der Baustein muss auf alle Webserver des Informationsverbunds angewendet werden

Abgrenzung

Die Bezeichnung Webserver wird sowohl für die Software verwendet, welche die HTTP-Anfragen beantwortet, als auch für die IT-Systeme, auf denen diese Software ausgeführt wird

  • In diesem Baustein wird vorrangig die Webserver-Software betrachtet
  • Sicherheitsaspekte des IT-Systems, auf dem die Webserver-Software installiert ist, werden im Baustein SYS.1.1 Allgemeiner Server sowie den jeweiligen betriebssystemspezifischen Bausteinen betrachtet

Empfehlungen, wie Webserver in die Netzarchitektur zu integrieren und mit Firewalls abzusichern sind, finden sich in den Bausteinen NET.1.1 Netzarchitektur und -design bzw. NET.3.2 Firewall

Der Baustein behandelt grundsätzliche Aspekte, die für die Bereitstellung von Webinhalten wichtig sind

  • Dynamische Inhalte, die durch Webanwendungen bereitgestellt werden, sind nicht Gegenstand des vorliegenden Bausteins
  • Diese werden im Baustein APP.3.1 Webanwendungen und Webservices behandelt
  • Ebenso werden hier keine Webservices betrachtet

Webbrowser werden in diesem Baustein nicht betrachtet

  • Anforderungen dazu sind im Baustein APP.1.2 Webbrowser zu finden

In der Regel werden die Verbindungen zu Webservern verschlüsselt

  • Der Baustein CON.1 Kryptokonzept beschreibt, wie die dazu notwendigen kryptografischen Schlüssel sicher verwaltet werden können

Werden Webserver nicht selbst betrieben, sondern über einen Hosting-Anbieter bereitgestellt, ist der Baustein OPS.2.3 Nutzung von Outsourcing zu beachten

Oft werden Authentisierungsmechanismen für Webserver verwendet

  • Ergänzende Anforderungen dazu finden sich im Baustein ORP.4 Identitäts- und Berechtigungsmanagement

Abgrenzung und Modellierung

Gefährdungslage

Typische Szenarien
Gefährdung Beschreibung
Gefährdung1 Beschreibung
Gefährdung2 Beschreibung
Gefährdung3 Beschreibung


Gefährdungslage

Da IT-Grundschutz-Bausteine nicht auf individuelle Informationsverbünde eingehen können, werden zur Darstellung der Gefährdungslage typische Szenarien zugrunde gelegt

  • Die folgenden spezifischen Bedrohungen und Schwachstellen sind für den Baustein APP.3.2 Webserver von besonderer Bedeutung

Reputationsverlust

Gelingt es bei einem Angriff mit administrativen Rechten auf einen Webserver zuzugreifen, kann darüber eine manipulierte Webseite ausgeliefert werden (Defacement)

  • So kann die Reputation der Institution geschädigt werden
  • Ebenso kann die Veröffentlichung falscher Informationen, wie zum Beispiel fehlerhafter Produktbeschreibungen, dazu führen, dass die Reputation der Institution in der Öffentlichkeit leidet
  • Auch kann die Institution abgemahnt werden, wenn auf ihrer Webseite Inhalte veröffentlicht werden, die gegen gesetzliche Vorschriften verstoßen
  • Ein Schaden kann auch entstehen, wenn die Webseite nicht verfügbar ist und potenzielle Kunden und Kundinnen deshalb zu Mitbewerbern wechseln

Manipulation des Webservers

Bei einem Angriff könnten sich unberechtigte Personen Zugriff auf einen Webserver verschaffen und dessen Dateien manipulieren

  • Es könnte beispielsweise die Konfiguration der Webserver-Software geändert werden, Schadsoftware verbreitet oder Webinhalte modifiziert werden

Denial of Service (DoS)

Durch DoS-Angriffe lässt sich die Verfügbarkeit eines Webangebotes gezielt beeinträchtigen, indem beispielsweise einzelne Accounts durch fehlerhafte Anmeldungen gesperrt werden

Durch DDoS (Distributed Denial of Service)-Angriffe kann ein Webserver teilweise oder auch ganz ausfallen

  • Für Clients ist das Webangebot dann nur noch sehr langsam oder gar nicht mehr verfügbar
  • Für viele Institutionen kann ein solcher Ausfall schnell geschäftskritisch werden, z. B.  für Online-Shops

Verlust vertraulicher Daten

Viele Webserver verwenden noch veraltete kryptografische Verfahren wie RC4 oder SSL

  • Eine unzureichende Authentisierung bzw. eine ungeeignete Verschlüsselung kann dazu führen, dass die Kommunikation zwischen den Clients und den Webservern mitgelesen oder manipuliert werden kann
  • Das gleiche gilt für die Kommunikation zwischen dem Webserver und anderen Servern, wie beispielsweise Load Balancern

Verstoß gegen Gesetze oder Regelungen

Für die Veröffentlichung von Webinhalten gibt es verschiedene regulatorische Anforderungen

  • Neben den Regelungen der Telemedien- und Datenschutzgesetze, sind auch die Regeln des Urheberrechts zu beachten
  • Verstöße gegen diese Gesetze können rechtliche Konsequenzen nach sich ziehen

Fehlende oder mangelhafte Fehlerbehebung

Treten während des Betriebs eines Webservers Fehler auf, kann sich das beispielsweise auf dessen Verfügbarkeit auswirken

  • Auch werden eventuell Inhalte unvollständig dargestellt oder Sicherheitsmechanismen fallen aus
  • Werden Fehler nicht korrekt behandelt, sind sowohl der Betrieb als auch der Schutz der Funktionen und Daten eines Webservers nicht mehr gewährleistet

Zuständigkeiten

Der oder die Informationssicherheitsbeauftragte (ISB) ist dafür zuständig, dass alle Anforderungen gemäß dem festgelegten Sicherheitskonzept erfüllt und überprüft werden

  • Bei strategischen Entscheidungen ist der oder die ISB stets einzubeziehen

Im IT-Grundschutz/Kompendium sind darüber hinaus weitere Rollen definiert

  • Sie sollten besetzt werden, insofern dies sinnvoll und angemessen ist
Zuständigkeiten Rollen
Grundsätzlich zuständig IT-Betrieb
Weitere Zuständigkeiten Fachverantwortliche, Compliance-Beauftragte, Zentrale Verwaltung
Genau eine Rolle sollte Grundsätzlich zuständig sein
  • Darüber hinaus kann es noch Weitere Zuständigkeiten geben
  • Falls eine dieser weiteren Rollen für die Erfüllung einer Anforderung vorrangig zuständig ist, dann wird diese Rolle hinter der Überschrift der Anforderung in eckigen Klammern aufgeführt
  • Die Verwendung des Singulars oder Plurals sagt nichts darüber aus, wie viele Personen diese Rollen ausfüllen sollen

Basis-Anforderungen

Die folgenden Anforderungen MÜSSEN für diesen Baustein vorrangig erfüllt werden

Anforderung Beschreibung
A1 Sichere Konfiguration eines Webservers
A2 Schutz der Webserver-Dateien
A3 Absicherung von Datei-Uploads und -Downloads
A4 Protokollierung von Ereignissen
A5 Authentisierung
A6 ENTFALLEN
A7 Rechtliche Rahmenbedingungen für Webangebote [Fachverantwortliche, Zentrale Verwaltung, Compliance-Beauftragte]
A11 Verschlüsselung über TLS

A1 Sichere Konfiguration eines Webservers

Nachdem der IT-Betrieb einen Webserver installiert hat, MUSS er eine sichere Grundkonfiguration vornehmen

  • Dazu MUSS er insbesondere den Webserver-Prozess einem Konto mit minimalen Rechten zuweisen
  • Der Webserver MUSS in einer gekapselten Umgebung ausgeführt werden, sofern dies vom Betriebssystem unterstützt wird
  • Ist dies nicht möglich, SOLLTE jeder Webserver auf einem eigenen physischen oder virtuellen Server ausgeführt werden

Dem Webserver-Dienst MÜSSEN alle nicht notwendige Schreibberechtigungen entzogen werden

  • Nicht benötigte Module und Funktionen des Webservers MÜSSEN deaktiviert werden

A2 Schutz der Webserver-Dateien

Der IT-Betrieb MUSS alle Dateien auf dem Webserver, insbesondere Skripte und Konfigurationsdateien, so schützen, dass sie nicht unbefugt gelesen und geändert werden können

Es MUSS sichergestellt werden, dass Webanwendungen nur auf einen definierten Verzeichnisbaum zugreifen können (WWW-Wurzelverzeichnis)

  • Der Webserver MUSS so konfiguriert sein, dass er nur Dateien ausliefert, die sich innerhalb des WWW-Wurzelverzeichnisses befinden

Der IT-Betrieb MUSS alle nicht benötigten Funktionen, die Verzeichnisse auflisten, deaktivieren

  • Vertrauliche Daten MÜSSEN vor unberechtigtem Zugriff geschützt werden
  • Insbesondere MUSS der IT-Betrieb sicherstellen, dass vertrauliche Dateien nicht in öffentlichen Verzeichnissen des Webservers liegen
  • Der IT-Betrieb MUSS regelmäßig überprüfen, ob vertrauliche Dateien in öffentlichen Verzeichnissen gespeichert wurden

A3 Absicherung von Datei-Uploads und -Downloads

Alle mithilfe des Webservers veröffentlichten Dateien MÜSSEN vorher auf Schadprogramme geprüft werden

  • Es MUSS eine Maximalgröße für Datei-Uploads spezifiziert sein
  • Für Uploads MUSS genügend Speicherplatz reserviert werden

A4 Protokollierung von Ereignissen

Der Webserver MUSS mindestens folgende Ereignisse protokollieren:

  • erfolgreiche Zugriffe auf Ressourcen,
  • fehlgeschlagene Zugriffe auf Ressourcen aufgrund von mangelnder Berechtigung, nicht vorhandenen Ressourcen und Server-Fehlern sowie
  • allgemeine Fehlermeldungen

Die Protokollierungsdaten SOLLTEN regelmäßig ausgewertet werden

A5 Authentisierung

Wenn sich Clients mit Hilfe von Passwörtern am Webserver authentisieren, MÜSSEN diese kryptografisch gesichert und vor unbefugtem Zugriff geschützt gespeichert werden

A6 ENTFALLEN

Diese Anforderung ist entfallen

A7 Rechtliche Rahmenbedingungen für Webangebote [Fachverantwortliche, Zentrale Verwaltung, Compliance-Beauftragte]

Werden über den Webserver Inhalte für Dritte publiziert oder Dienste angeboten, MÜSSEN dabei die relevanten rechtlichen Rahmenbedingungen beachtet werden

  • Die Institution MUSS die jeweiligen Telemedien- und Datenschutzgesetze sowie das Urheberrecht einhalten

A11 Verschlüsselung über TLS

Der Webserver MUSS für alle Verbindungen durch nicht vertrauenswürdige Netze eine sichere Verschlüsselung über TLS anbieten (HTTPS)

  • Falls es aus Kompatibilitätsgründen erforderlich ist, veraltete Verfahren zu verwenden, SOLLTEN diese auf so wenige Fälle wie möglich beschränkt werden

Wenn eine HTTPS-Verbindung genutzt wird, MÜSSEN alle Inhalte über HTTPS ausgeliefert werden

  • Sogenannter Mixed Content DARF NICHT verwendet werden

Standard-Anforderungen

Gemeinsam mit den Basis-Anforderungen entsprechen die folgenden Anforderungen dem Stand der Technik für diesen Baustein

  • Sie SOLLTEN grundsätzlich erfüllt werden
Anforderung Beschreibung
A8 Planung des Einsatzes eines Webservers
A9 Festlegung einer Sicherheitsrichtlinie für den Webserver
A10 Auswahl eines geeigneten Webhosters
A12 Geeigneter Umgang mit Fehlern und Fehlermeldungen
A13 Zugriffskontrolle für Webcrawler
A14 Integritätsprüfungen und Schutz vor Schadsoftware
A16 Penetrationstest und Revision
A20 Benennung von Anzusprechenden [Zentrale Verwaltung]


A8 Planung des Einsatzes eines Webservers

Es SOLLTE geplant und dokumentiert werden, für welchen Zweck der Webserver eingesetzt und welche Inhalte er bereitstellen soll

  • In der Dokumentation SOLLTEN auch die Informationen oder Dienstleistungen des Webangebots und die jeweiligen Zielgruppen beschrieben werden
  • Für den technischen Betrieb und die Webinhalte SOLLTEN geeignete Zuständige festgelegt werden

A9 Festlegung einer Sicherheitsrichtlinie für den Webserver

Es SOLLTE eine Sicherheitsrichtlinie erstellt werden, in der die erforderlichen Maßnahmen und Zuständigkeiten benannt sind

  • Weiterhin SOLLTE geregelt werden, wie Informationen zu aktuellen Sicherheitslücken besorgt werden
  • Auch SOLLTE geregelt werden, wie Sicherheitsmaßnahmen umgesetzt werden und wie vorgegangen werden soll, wenn Sicherheitsvorfälle eintreten

A10 Auswahl eines geeigneten Webhosters

Betreibt die Institution den Webserver nicht selbst, sondern nutzt Angebote externer Unternehmen im Rahmen von Webhosting, SOLLTE die Institution bei der Auswahl eines geeigneten Webhosters auf folgende Punkte achten:

  • Es SOLLTE vertraglich geregelt werden, wie die Dienste zu erbringen sind
  • Dabei SOLLTEN Sicherheitsaspekte innerhalb des Vertrags schriftlich in einem Service Level Agreement (SLA) festgehalten werden
  • Die eingesetzten IT-Systeme SOLLTEN vom Webhoster regelmäßig kontrolliert und gewartet werden
  • Der Webhoster SOLLTE dazu verpflichtet werden, bei technischen Problemen oder einer Kompromittierung von Kundschaftssystemen zeitnah zu reagieren
  • Der Webhoster SOLLTE grundlegende technische und organisatorische Maßnahmen umsetzen, um seinen Informationsverbund zu schützen

A12 Geeigneter Umgang mit Fehlern und Fehlermeldungen

Aus den HTTP-Informationen und den angezeigten Fehlermeldungen SOLLTEN weder der Produktname noch die verwendete Version des Webservers ersichtlich sein

  • Fehlermeldungen SOLLTEN keine Details zu Systeminformationen oder Konfigurationen ausgeben
  • Der IT-Betrieb SOLLTE sicherstellen, dass der Webserver ausschließlich allgemeine Fehlermeldungen ausgibt, die Clients darauf hinweisen, dass ein Fehler aufgetreten ist
  • Die Fehlermeldung SOLLTE ein eindeutiges Merkmal enthalten, das es dem IT-Betrieb ermöglicht, den Fehler nachzuvollziehen
  • Bei unerwarteten Fehlern SOLLTE sichergestellt sein, dass der Webserver nicht in einem Zustand verbleibt, in dem er anfällig für Angriffe ist

A13 Zugriffskontrolle für Webcrawler

Der Zugriff von Webcrawlern SOLLTE nach dem Robots-Exclusion-Standard geregelt werden

  • Inhalte SOLLTEN mit einem Zugriffsschutz versehen werden, um sie vor Webcrawlern zu schützen, die sich nicht an diesen Standard halten

A14 Integritätsprüfungen und Schutz vor Schadsoftware

Der IT-Betrieb SOLLTE regelmäßig prüfen, ob die Konfigurationen des Webservers und die von ihm bereitgestellten Dateien noch integer sind und nicht durch Angriffe verändert wurden

  • Die zur Veröffentlichung vorgesehenen Dateien SOLLTEN regelmäßig auf Schadsoftware geprüft werden

A16 Penetrationstest und Revision

Webserver SOLLTEN regelmäßig auf Sicherheitsprobleme hin überprüft werden

  • Auch SOLLTEN regelmäßig Revisionen durchgeführt werden
  • Die Ergebnisse SOLLTEN nachvollziehbar dokumentiert, ausreichend geschützt und vertraulich behandelt werden
  • Abweichungen SOLLTE nachgegangen werden
  • Die Ergebnisse SOLLTEN dem ISB vorgelegt werden

A20 Benennung von Anzusprechenden [Zentrale Verwaltung]

Bei umfangreichen Webangeboten SOLLTE die Institution zentrale Anzusprechende für die Webangebote bestimmen

  • Es SOLLTEN Prozesse, Vorgehensweisen und Zuständige für Probleme oder Sicherheitsvorfälle benannt werden

Die Institution SOLLTE eine Kontaktmöglichkeit auf ihrer Webseite veröffentlichen, über die Sicherheitsprobleme an die Institution gemeldet werden können

  • Für die Behandlung von externen Sicherheitsmeldungen SOLLTE die Institution Prozesse definieren

Erhöhter Schutzbedarf

Anforderung Beschreibung
A15 Redundanz
A17 ENTFALLEN
A18 Schutz vor Denial-of-Service-Angriffen
A19 ENTFALLEN


Anforderungen bei erhöhtem Schutzbedarf

Im Folgenden sind für diesen Baustein exemplarische Vorschläge für Anforderungen aufgeführt, die über dasjenige Schutzniveau hinausgehen, das dem Stand der Technik entspricht

  • Die Vorschläge SOLLTEN bei erhöhtem Schutzbedarf in Betracht gezogen werden
  • Die konkrete Festlegung erfolgt im Rahmen einer individuellen Risikoanalyse

A15 Redundanz

Webserver SOLLTEN redundant ausgelegt werden

  • Auch die Internetanbindung des Webservers und weiterer IT-Systeme, wie etwa der Webanwendungsserver, SOLLTEN redundant ausgelegt sein

A18 Schutz vor Denial-of-Service-Angriffen

Der Webserver SOLLTE ständig überwacht werden

  • Des Weiteren SOLLTEN Maßnahmen definiert und umgesetzt werden, die DDoS-Angriffe verhindern oder zumindest abschwächen



Anhang

Siehe auch

Links

Weblinks

  1. Webserver

Wissenswertes

BSI

Das Bundesamt für Sicherheit in der Informationstechnik hat folgende weiterführende Dokumente veröffentlicht, die für den Betrieb von Webservern relevant sein können

  • Migration auf TLS 1.2 - Handlungsleitfaden
  • Sicheres Webhosting: Handlungsempfehlung für Webhoster
  • Sicheres Bereitstellen von Webangeboten (ISi-Webserver)

NIST

Das National Institute of Standards and Technology (NIST) stellt in seinem Dokument "Guideline on Securing Public Web Servers" Hinweise zur Absicherung von Webservern zur Verfügung