Richtlinien zur E-Mail-Authentifizierung

!! ACHTUNG !! Dieses Dokument wurde automatisch aus dem Italienischen übersetzt

Leitlinien

Einrichtung des E-Mail-Dienstes für die Authentifizierung

Die italienische Nationale Agentur für Cybersicherheit hat Leitlinien für die Konfiguration des E-Mail-Dienstes im Hinblick auf die Authentifizierung veröffentlicht, mit dem Ziel, die Zuverlässigkeit des E-Mail-Dienstes für alle betroffenen Organisationen zu stärken und dessen Sicherheitsniveau insgesamt zu erhöhen.

Versionskontrolle

INHALT

1. Einleitung

1.1. Ausgangspunkt

E-Mail ist heute einer der wichtigsten Dienste im digitalen Umfeld, da sie zu den Hauptkanälen gehört, die von Unternehmen und Nutzern für die Kommunikation und den Informationsaustausch genutzt werden¹.

Die Funktionsweise des E-Mail-Dienstes und insbesondere die Übertragung von Nachrichten basieren auf dem SMTP-Protokoll, das jedoch von Haus aus keine ausreichenden Mechanismen zur Absenderauthentifizierung und zum Schutz der Vertraulichkeit und Integrität von Nachrichten enthält. Diese Schwachstellen setzen das System der Gefahr von Angriffen wie Spoofing, Phishing, Manipulation und dem Abfangen von Nachrichten während der Übertragung aus.

Um die Schwachstellen des SMTP-Protokolls zu beheben und damit das Risiko durch die oben genannten Angriffe zu verringern, wurden im Laufe der Zeit Mechanismen zur Absenderauthentifizierung und zum Schutz der Nachrichtenintegrität entwickelt, wie beispielsweise SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) und DMARC (Domain-based Message Authentication, Reporting and Conformance).

Diese Richtlinien veranschaulichen diese Mechanismen mit dem Ziel, die Zuverlässigkeit des E-Mail-Dienstes zu stärken und dessen Sicherheitsniveau insgesamt zu erhöhen, wobei insbesondere auf die in Kapitel 4 beschriebenen Bedrohungen Bezug genommen wird.

Die zum Schutz der Vertraulichkeit von E-Mail-Nachrichten erforderlichen Maßnahmen und Protokolle (wie S/MIME und OpenPGP, die die Verschlüsselung von Nachrichten betreffen) sind nicht Gegenstand dieser Richtlinien.

1.2. Referenzvorschriften

1.3. Referenzdokumente

» Zurück zum Anfang

2. Rechtlicher Rahmen

Zum Schutz der digitalen Ressourcen des Landes, einschließlich E-Mail-Diensten und der Infrastruktur, auf der diese gehostet werden, wurde ein umfassendes Bündel an Sicherheitsmaßnahmen auf der Grundlage der geltenden Rechtsvorschriften eingeführt, das ständig aktualisiert wird.

Das höchste Schutzniveau für die wichtigsten Dienste des Landes, die mit dem Schutz der nationalen Sicherheit in Zusammenhang stehen, wird durch den Nationalen Cybersicherheitsperimeter gewährleistet, der durch das Gesetzesdekret Nr. 105 vom 21. September 2019 eingerichtet und mit Änderungen durch das Gesetz Nr. 133 vom 18. November 2019 umgesetzt wurde. Dieser sieht Sicherheitsmaßnahmen mit besonders hohem Schutzniveau vor, die in Anhang B des Dekrets des Ministerpräsidenten vom 14. April 2021, Nr. 81, die für die Netzwerke, Informationssysteme und IT-Dienste öffentlicher und privater Einrichtungen gelten, von denen die Ausübung einer wesentlichen staatlichen Funktion oder die Erbringung einer wesentlichen Dienstleistung zur Aufrechterhaltung ziviler, sozialer oder wirtschaftlicher Aktivitäten abhängt, die für die Interessen des Staates von grundlegender Bedeutung sind und deren Gefährdung zu einer Beeinträchtigung der nationalen Sicherheit führen könnte.

Darüber hinaus unterliegen E-Mail-Dienste, wie alle digitalen Dienste der öffentlichen Verwaltung, den Bestimmungen der sogenannten Cloud-Verordnung, die gemäß Artikel 33-septies des Gesetzesdekrets Nr. 179 vom 18. Oktober 2012 erlassen und von der Nationalen Agentur für Cybersicherheit (ACN) mit dem Direktorialdekret Nr. 21007 vom 27. Juni 2024 aktualisiert wurde. Gemäß der vorgenannten Verordnung sind alle öffentlichen Verwaltungen aufgefordert, ihre digitalen Daten und Dienste nach dem von der ACN erstellten Modell als gewöhnlich, kritisch oder strategisch einzustufen. Diese Maßnahme zielt darauf ab, sicherzustellen, dass digitale Daten und Dienste der öffentlichen Verwaltung über digitale Infrastrukturen und Cloud-Dienste verarbeitet und bereitgestellt werden, die den Anforderungen – einschließlich der Sicherheitsanforderungen – entsprechen, die den mit der jeweiligen Einstufungsstufe verbundenen Risiken angemessen sind, wie in der Verordnung dargelegt.

Mit dem Gesetzesdekret Nr. 138 vom 4. September 2024 (dem sogenannten NIS-Dekret) zur Umsetzung der Richtlinie (EU) 2022/2555 wurden – über die Anhänge 1 und 2 des ACN-Beschlusses 379907/2025 – die grundlegenden Sicherheitsmaßnahmen fest, die wesentliche und wichtige Stellen zur Erfüllung der Verpflichtungen gemäß den Artikeln 23 und 24 des NIS-Dekrets ergreifen müssen, und definiert damit einen Sicherheitsrahmen zur Stärkung des Schutzes von Netz- und Informationssystemen, einschließlich E-Mail-Diensten.

» Zurück zum Anfang

3. Architektur des E-Mail-Dienstes

Wie bereits eingangs erwähnt, basiert die Funktionsweise des E-Mail-Dienstes auf dem SMTP-Protokoll, das die Übertragung von E-Mail-Nachrichten vom Absender zum Empfänger regelt.

Das SMTP-Protokoll wurde ursprünglich 1982 definiert² als Store-and-Forward-Protokoll definiert, bei dem der Absender über seinen E-Mail-Client – in der Fachsprache Mail User Agent (MUA) – eine Nachricht erstellt, die an den Mailserver des Absenders gesendet wird. Dieser leitet die Nachricht über eine Komponente namens Mail Transfer Agent (MTA) weiter, möglicherweise auch über einen oder mehrere zwischengeschaltete MTAs, und liefert sie an den MTA des Ziel-Mailservers. Der Empfänger greift über seinen E-Mail-Client (MUA) auf die Nachricht zu[1].

Der MTA ist somit eine Komponente des E-Mail-Dienstes, die die Übertragung von E-Mail-Nachrichten vom Absender zum Empfänger übernimmt. MTA-Komponenten sind auf den Mail-Servern des Absenders und des Empfängers vorhanden, und es können auch Zwischen-MTAs konfiguriert werden, beispielsweise zur Verwaltung von Verteilerlisten.

Obwohl der Begriff MTA eine bestimmte Komponente von E-Mail-Servern bezeichnet³, wird in diesem Dokument auf diese hauptsächlich in ihrer Funktion als MTAs Bezug genommen; sofern keine Unklarheiten bestehen, wird der Begriff „E-Mail-Server“ der Einfachheit halber häufig anstelle des spezifischeren Begriffs „MTA“ verwendet.

In diesem Leitfaden konzentrieren wir uns auf die Konfiguration der Protokolle SPF, DKIM und DMARC, damit Mailserver die Echtheit und Integrität von E-Mail-Nachrichten überprüfen können.

» Zurück zum Anfang

4. Drohungen

Das im vorigen Kapitel vorgestellte SMTP-Protokoll war ursprünglich für den Einsatz in einem relativ kleinen akademischen Netzwerk konzipiert und berücksichtigte keine Aspekte hinsichtlich der Sicherheit der übertragenen Nachrichten oder der Absenderauthentifizierung [1].

Die zunehmende Verbreitung von E-Mails und die dem SMTP-Protokoll innewohnenden Schwachstellen haben im Laufe der Zeit die Entstehung von Angriffen begünstigt, deren Hauptarten in den folgenden Absätzen kurz erläutert werden.

4.1. Absender-Spoofing

Spoofing ist eine Technik für Cyberangriffe, bei der die Absenderadresse einer Nachricht gefälscht wird, sodass diese scheinbar von einer vertrauenswürdigen Adresse stammt (wie beispielsweise von einem Kollegen, einem Bekannten oder der eigenen Bank), um den Empfänger dazu zu verleiten, potenziell gefährliche Handlungen vorzunehmen, wie zum Beispiel das Öffnen eines E-Mail-Anhangs oder das Anklicken von Links in der Nachricht.

Diese Art von Angriff ist relativ einfach durchzuführen, da das SMTP-Protokoll keine Mechanismen zur Absenderauthentifizierung enthält und es daher über den E-Mail-Client möglich ist, beim Versenden der Nachricht eine beliebige Absenderadresse anzugeben.

E-Mail-Adresse des Absenders: envelope-from und message-from

Das E-Mail-Format sieht zwei unterschiedliche Felder vor, um die E-Mail-Adresse des Absenders anzugeben. Diese Felder heißen „envelope-from“ und „message-from“: Das erste (auch als „return-path“ bezeichnet, da es die E-Mail-Adresse angibt, an die etwaige Fehlermeldungen gesendet werden müssen, falls eine E-Mail den Empfänger nicht erreicht) ist die Adresse, die für die korrekte Weiterleitung der Nachricht verwendet wird; das zweite ist die Adresse, die dem Empfänger im Kopf der empfangenen Nachricht angezeigt wird.

Um einen Vergleich mit dem Versand eines Briefes in einem Umschlag per Post anzustellen: Der „envelope-from“ entspricht der Absenderadresse auf dem Briefumschlag, während der „message-from“ der Kopfzeile im Brief entspricht, aus der hervorgeht, wer den Brief an den Empfänger verfasst hat.

Es ist wichtig zu beachten, dass die beiden Adressen nicht unbedingt übereinstimmen müssen. Diese Unterscheidung ermöglicht die Handhabung von Situationen wie beispielsweise der Weiterleitung von Nachrichten durch Dienste von Drittanbietern, der Verteilung über Mailinglisten oder automatischen E-Mail-Antworten.

Es ist in der Tat möglich, einen beliebigen Absender sowohl auf der „Message-From“-Ebene (die E-Mail-Adresse des Absenders, die dem Empfänger im Kopf der empfangenen Nachricht angezeigt wird) als auch auf der „Envelope-From“-Ebene (die E-Mail-Adresse des Absenders, die für die Übermittlung der Nachricht verwendet wird) anzugeben.

Um diesen Bedrohungen entgegenzuwirken, ist es daher unerlässlich, Mechanismen bereitzustellen, die eine zuverlässige Authentifizierung des Absenders ermöglichen und sicherstellen, dass die Person, die die Nachricht gesendet hat, tatsächlich dazu berechtigt ist.

4.2. Phishing

Phishing ist eine Technik für Cyberangriffe, die darauf abzielt, Informationen (wie beispielsweise Anmeldedaten, Kreditkartennummern oder andere sensible Daten) auf betrügerische Weise zu erlangen, in der Regel durch das Versenden von irreführenden Nachrichten, die den Anschein erwecken, von vertrauenswürdigen Absendern zu stammen³.

Das im vorigen Absatz behandelte Spoofing gehört zu den wichtigsten Techniken, die Angreifer einsetzen, um die Identität des Absenders zu fälschen und den Anschein zu erwecken, die Nachricht stamme von einem legitimen Nutzer oder einer legitimen Domain.

Alternativ kann eine Absenderadresse bzw. -domain verwendet werden, die der vom Empfänger erkannten ähnelt, indem beispielsweise der sogenannte Anzeigename geändert wird⁴ , um die scheinbare Authentizität der Nachricht zu verstärken.

Zum Versenden von Phishing-Nachrichten können auch legitime Konten genutzt werden, die zuvor vom Angreifer kompromittiert wurden.

Eine Phishing-Nachricht ist in der Regel so verfasst, dass sie beim Empfänger ein Gefühl der Dringlichkeit, Besorgnis oder wirtschaftlichen Verlockung hervorruft. Dadurch werden Situationen geschaffen, die den Empfänger dazu veranlassen, impulsiv zu reagieren und bestimmte Handlungen auszuführen, wie beispielsweise das Öffnen bösartiger Anhänge oder das Anklicken von Links, die auf scheinbar legitime Websites weiterleiten, die jedoch in Wirklichkeit vom Angreifer erstellt wurden, um Informationen zu stehlen und/oder Malware zu installieren.

In der Regel werden Phishing-Angriffe durchgeführt, indem dieselbe E-Mail-Nachricht an eine große Anzahl von Opfern versendet wird, ohne den Text an das jeweilige Profil der Opfer anzupassen.

Eine Variante des Phishing ist das sogenannte Spear-Phishing, bei dem der Angreifer das Profil des Opfers kennt und gezielt darauf abzielt.

Im Gegensatz zu einer gewöhnlichen Phishing-E-Mail nutzt eine Spear-Phishing-Nachricht präzisere Kontextinformationen, um den Nutzer davon zu überzeugen, dass er es mit einem vertrauenswürdigen Absender zu tun hat [2].

4.3. Manipulation von Nachrichten

Der Inhalt einer E-Mail-Nachricht kann – wie jede andere Kommunikation, die über das Internet übertragen wird und keine End-to-End-Verschlüsselung (E2EE) nutzt – während der Übertragung zwischen Absender und Empfänger abgefangen und verändert werden (eine Art von Bedrohung, die gemeinhin als „Man-in-the-Middle“-Angriff bezeichnet wird).

Folglich besteht nicht nur die Gefahr eines Verlusts der Vertraulichkeit, sondern es kann auch vorkommen, dass die empfangene Nachricht nicht mit der ursprünglich vom Absender verfassten Nachricht übereinstimmt.

Ein Angreifer könnte beispielsweise den Inhalt der Nachricht so manipulieren, dass sie den Anschein erweckt, von einem vertrauenswürdigen Absender zu stammen, den Text oder darin enthaltene Links und/oder Anhänge ändern oder schädlichen Code einfügen.

Der Empfänger, der der scheinbaren Echtheit der Nachricht vertraut, kann so dazu verleitet werden, potenziell schädliche Handlungen vorzunehmen, wie beispielsweise die Weitergabe von Anmeldedaten, die Autorisierung von Zahlungen oder das Öffnen schädlicher Dateien.

Um diesen Bedrohungen entgegenzuwirken, ist es daher unerlässlich, Mechanismen einzuführen, die die Integrität und Authentizität der Nachricht gewährleisten und sicherstellen, dass der empfangene Inhalt nicht verändert wurde und der Absender tatsächlich der ist, für den er sich ausgibt.

» Zurück zum Anfang

5. Gegenmaßnahmen

In Kapitel 2 wurden die Vorschriften in Erinnerung gerufen, die Sicherheitsmaßnahmen auch zum Schutz von E-Mail-Diensten vorsehen. Dieses Dokument soll in erster Linie als Leitfaden für die Umsetzung der in diesen Vorschriften vorgesehenen und in Anhang A aufgeführten Sicherheitsmaßnahmen dienen, die auch für die Konfiguration von E-Mail-Diensten relevant sind, um die mit den in Kapitel 4 behandelten Bedrohungen verbundenen Risiken zu mindern. Es sei jedoch darauf hingewiesen, dass die in diesen Leitlinien enthaltenen Hinweise auch denjenigen empfohlen werden, die nicht den oben genannten Vorschriften unterliegen.

Die betreffenden Sicherheitsmaßnahmen beziehen sich nicht ausdrücklich auf die Konfiguration des E-Mail-Dienstes, sondern – je nach der jeweiligen Verordnung – auf die Konfiguration von IT-Systemen und industriellen Steuerungssystemen (PSNC und Cloud-Verordnung) oder von Informations- und Netzwerksystemen (NIS2). Die E-Mail-Dienste, die Gegenstand dieser Leitlinien sind, fallen unter beide Arten von Systemen.

Insbesondere werden im Folgenden die Protokolle SPF, DKIM und DMARC erläutert, die Sicherheitsmechanismen bieten, die darauf abzielen, die allgemeine Sicherheit des E-Mail-Dienstes und insbesondere die Absenderauthentifizierung sowie die Überprüfung der Nachrichtenintegrität zu verbessern.

5.1. SPF

SPF – Sender Policy Framework ist ein durch RFC 7208 formalisiertes Authentifizierungsprotokoll, das es einem Domaininhaber ermöglicht, festzulegen, welche IP-Adressen berechtigt sind, E-Mail-Nachrichten in seinem Namen zu versenden, und die Richtlinien festzulegen, die der Empfänger anwenden muss, wenn die mit der Domain verknüpfte IP-Adresse⁵ der E-Mail-Adresse des Absenders nicht zu den ausdrücklich autorisierten gehört.

Die autorisierten IP-Adressen sind in einem DNS-TXT-Eintrag aufgeführt, der sich auf die Absenderdomain bezieht und als SPF-Eintrag bezeichnet wird; dies wird im folgenden Abschnitt dieses Absatzes erläutert.

Auf diese Weise wird der E-Mail-Server des Empfängers⁶ beim Empfang einer Nachricht von einer bestimmten Domain den zugehörigen SPF-Eintrag abfragen und deren Herkunft authentifizieren, indem er überprüft, ob die IP-Adresse, von der die Nachricht empfangen wurde, zu denjenigen gehört, die zum Versenden von Nachrichten im Namen der Domain berechtigt sind.

Es ist wichtig zu beachten, dass die auf SPF-Ebene überprüfte Domain diejenige ist, die sich auf den „Envelope-From“-Eintrag bezieht; folglich reicht die Einführung des SPF-Protokolls allein nicht aus, um Spoofing zu verhindern, da diese Art von Angriff auf der „Message-From“-Ebene durchgeführt werden könnte⁷.

Falls ein Unternehmen seinen E-Mail-Dienst ganz oder teilweise an einen Dritten, wie beispielsweise einen Cloud-Anbieter, auslagert, muss es sicherstellen, dass die von diesen Anbietern versendeten Nachrichten die SPF-Prüfung bestehen. Zu diesem Zweck sollte das Unternehmen in seinen SPF-Eintrag die IP-Adressen aufnehmen, von denen aus die Anbieter E-Mails im Namen der Unternehmensdomain versenden.

Bei der automatischen E-Mail-Weiterleitung werden Nachrichten in der Regel über einen Zwischenserver umgeleitet, sodass die IP-Adresse, von der die endgültige Zustellung erfolgt, nicht mehr mit der ursprünglich von der Absenderdomain autorisierten IP-Adresse übereinstimmt. Um in diesen Fällen ein Scheitern der SPF-Überprüfung zu vermeiden, ist es erforderlich, auch alle zwischengeschalteten Weiterleitungsserver zu autorisieren oder auf Mechanismen wie SRS (Sender Rewriting Scheme) oder ARC (Authenticated Received Chain) zurückzugreifen, die insbesondere bei einer Vielzahl von zwischengeschalteten Weiterleitungsservern effektiver sein können.

Es ist zu beachten, dass SPF nur dann wirklich wirksam ist, wenn es nicht nur vom Absender, sondern auch vom Empfänger korrekt konfiguriert wird. Insbesondere:

• Der Absender muss den SPF-Eintrag auf dem entsprechenden DNS-Server veröffentlichen und darin die Adressen angeben, die berechtigt sind, E-Mails in seinem Namen zu versenden;
• Der Empfänger muss seinen eigenen Mailserver so konfigurieren, dass dieser bei empfangenen Nachrichten eine SPF-Prüfung durchführt und die daraus resultierenden Richtlinien konsequent anwendet.

5.1.1. SPF-Eintrag

Ein SPF-Eintrag ist ein DNS-Eintrag vom Typ TXT, dessen Name der Absenderdomain entspricht und dessen Inhalt aus⁸ aus dem Abschnitt, der die Version angibt⁹ sowie einer Reihe von Anweisungen, die das Verhalten des E-Mail-Servers des Empfängers festlegen, wenn eine Übereinstimmung zwischen der IP-Adresse der Absenderdomain und einer Anweisung vorliegt.

Die Anweisungen bestehen aus einem Mechanismus, dem ein Qualifizierer vorangestellt ist. Die wichtigsten Mechanismen, die in SPF-Einträgen verwendet werden, sind [2]:

• ip4, listet autorisierte IPv4-Adressen auf;
• ip6, listet autorisierte IPv6-Adressen auf;
• a) autorisiert die im A-Eintrag der Domain aufgeführten IP-Adressen;
• mx, autorisiert IP-Adressen, die mit den MX-Einträgen der Domain verknüpft sind;
• umfasst, autorisiert IP-Adressen, die im SPF-Eintrag einer anderen Domain aufgeführt sind;
• „all“ steht für alle IP-Adressen, die nicht ausdrücklich über die anderen Mechanismen autorisiert wurden.

Insbesondere die alle Dieser Mechanismus ermöglicht es, Richtlinien für Nachrichten festzulegen, die von IP-Adressen stammen, die durch frühere Mechanismen nicht erfasst wurden.

Darüber hinaus stellt SPF die folgenden Qualifizierer zur Verknüpfung mit Mechanismen bereit:

• + (pass) bedeutet, dass IP-Adressen, die dem zugehörigen Mechanismus entsprechen, zugelassen sind. Dies ist der Standardqualifizierer, sofern kein anderer angegeben ist;
• - (fail) bedeutet, dass IP-Adressen, die dem zugehörigen Mechanismus entsprechen, nicht autorisiert sind;
• ~ (softfail) weist darauf hin, dass IP-Adressen, die dem zugehörigen Mechanismus entsprechen, wahrscheinlich nicht autorisiert sind. Dies ist eine unsicherere Aussage als die vorherige. In diesen Fällen sollte die Nachricht akzeptiert, aber für eine eingehendere Analyse markiert werden; dies wird beispielsweise bei der Fehlersuche oder dann verwendet, wenn zu erwarten ist, dass die SPF-Überprüfung möglicherweise nicht erfolgreich sein wird;
• ? (neutral) bedeutet, dass für IP-Adressen, die dem zugehörigen Mechanismus entsprechen, keine Angabe gemacht wird. Standardmäßig wird die Nachricht akzeptiert.

Es ist wichtig zu betonen, dass der SPF-Eintrag in der Praxis dazu dient, autorisierte IP-Adressen anzugeben, wobei auf die Anweisung zurückgegriffen wird -alle um festzulegen, dass alle anderen Adressen nicht zugelassen sind (siehe hierzu die folgenden Beispiele). Dies ist die empfohlene Konfiguration, da sie es ermöglicht, zugelassene IP-Adressen ausdrücklich anzugeben und alle anderen auszuschließen.

Auf jeden Fall wird empfohlen, die Anweisung niemals zu verwenden +alle (oder das Äquivalent alle), da dies einer Freigabe aller IP-Adressen entsprechen würde.

Beispiele für SPF-Einträge

Eine bestimmte IP-Adresse autorisieren

v=spf1 ip4:203.0.113.0 -all

Der oben gezeigte SPF-Eintrag verwendet SPF Version 1 und autorisiert über den ip4 Mechanismus der IP-Adresse 203.0.113.0 (da für das ip4 Mechanismus, die Standardeinstellung + wird implizit verwendet). Das -alle Richtlinie, die von der alle Mechanismus und die - Der Qualifizierer „(fail)“ gibt an, dass alle anderen Adressen nicht zugelassen sind.

Einen bestimmten IP-Adressbereich autorisieren

v=spf1 ip4:203.0.113.0/24 -all

Der oben gezeigte SPF-Eintrag entspricht dem vorherigen, autorisiert jedoch alle IP-Adressen der 203.0.113.0/24 Adressraum.

Mehrere IP-Adressen autorisieren

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -all

Der oben gezeigte SPF-Eintrag autorisiert ausschließlich die IPv4-Adressen 203.0.113.22 und 203.0.113.44.

MX-Einträge und eine bestimmte Domain autorisieren

v=spf1 mx include:spf.emailprovider.it -all

Der oben angezeigte SPF-Eintrag autorisiert ausschließlich die IP-Adressen der MX-Einträge derselben Domain wie der SPF-Eintrag sowie die autorisierten IP-Adressen der Domain. spf.emailprovider.it (zum Beispiel die Domain eines E-Mail-Anbieters).

5.1.2. Authentifizierungsprozess

Ist die SPF-Überprüfung korrekt konfiguriert, ruft der Mailserver des Empfängers beim Empfang einer neuen E-Mail-Nachricht den SPF-Eintrag der Absenderdomain ab, indem er den DNS-Server abfragt, der die Einträge dieser Domain enthält, wie sie sich aus der im „Envelope-From“-Feld angegebenen Adresse ergibt. Wenn beispielsweise die im „Envelope-From“-Feld angegebene Adresse lautet alice@example.com, ruft der Mailserver des Empfängers den SPF-Eintrag der Domain ab beispiel.com.

Der Mailserver des Empfängers führt daraufhin die SPF-Überprüfung durch und analysiert den SPF-Eintrag, um festzustellen, ob die IP-Adresse, von der die Nachricht empfangen wurde, zum Versenden von E-Mails für den beispiel.com Domain. Falls die E-Mail die SPF-Überprüfung besteht, wird sie an den Empfänger zugestellt.

Wenn beispielsweise der SPF-Eintrag der beispiel.com Domain waren v=spf1 ip4:203.0.113.22 -all Die Überprüfung würde nur erfolgreich sein, wenn die IP-Adresse des Absenderservers 203.0.113.22, während dies bei jeder anderen Adresse fehlschlagen würde.

» Zurück zum Anfang

5.2. DKIM

DKIM – DomainKeys Identified Mail ist ein durch RFC 6376 standardisiertes Authentifizierungsprotokoll, das es einem Domaininhaber ermöglicht, die Echtheit versendeter E-Mail-Nachrichten zu gewährleisten, indem er eine digitale Signatur (DKIM-Signatur) anbringt, die vom Mailserver mithilfe öffentlicher kryptografischer Algorithmen generiert und in die Kopfzeilen der zu übermittelnden Nachricht eingefügt wird.

Damit der Empfänger überprüfen kann, ob die Nachricht während der Übertragung nicht verändert wurde, wird der mit der DKIM-Signatur verbundene öffentliche Schlüssel in einem TXT-Eintrag des öffentlichen DNS der Absenderdomain gespeichert – dem sogenannten DKIM-Eintrag –, der vom Mailserver des Empfängers beim Empfang der Nachricht abgefragt wird.

Die DKIM-Signatur und der DKIM-Eintrag werden in den folgenden Abschnitten dieses Absatzes erläutert.

Genau wie bei SPF muss auch DKIM vom Absender und vom Empfänger korrekt konfiguriert werden, insbesondere:

• Der Absender muss seinen Mailserver so konfigurieren, dass er DKIM-Signaturen erstellt, und den DKIM-Eintrag im entsprechenden DNS-Server veröffentlichen;
• Der Empfänger muss seinen Mailserver so konfigurieren, dass dieser bei empfangenen Nachrichten eine DKIM-Überprüfung durchführt.

5.2.1. DKIM-Signatur

Die DKIM-Signatur wird ausgehend von bestimmten Elementen des Nachrichtentextes und der Kopfzeilen generiert und besteht aus einer Reihe von Schlüssel-Wert-Paaren, die Elemente angeben, darunter:

• v: Protokollversion¹⁰;
• a: verwendeter Verschlüsselungsalgorithmus¹¹;
• d: Signieren der Domäne zur Bestätigung der Nachrichtenauthentizität¹²;
• s: Selektor, der angibt, nach welchem öffentlichen DKIM-Schlüssel im DNS-Eintrag gesucht werden soll¹³;
• h: Liste der in der Signatur enthaltenen E-Mail-Header¹⁴;
• bh: Hashwert des Nachrichtentextes, kodiert im Base64-Format¹⁵;
• b: die mit dem privaten Schlüssel erzeugte und im Base64-Format kodierte digitale Signatur¹⁶;
• x: Gültigkeitsdauer der Signatur;
• c: Art der Kanonisierung.

Kanonisierung ist der Prozess der Normalisierung von Nachrichtenelementen vor der digitalen Signatur, um die Auswirkungen kleinerer Änderungen zu minimieren, die während der Übertragung auftreten können, wie beispielsweise wiederholte Leerzeichen oder Zeilenumbrüche. Es gibt zwei Arten der Kanonisierung: die einfache Kanonisierung, bei der eine exakte Übereinstimmung zwischen der ursprünglichen und der empfangenen Nachricht erforderlich ist, und die lockere Kanonisierung, bei der Normalisierungen wie das Entfernen von Leerzeichen, die Umwandlung von Großbuchstaben in Kleinbuchstaben in den Kopfzeilen und die Reduzierung aufeinanderfolgender Leerzeilen im Nachrichtentext vorgenommen werden.

5.2.2. DKIM-Eintrag

Der DKIM-Eintrag wird in einem DNS-Eintrag vom Typ TXT gespeichert, dessen Name folgende Struktur aufweist selector._domainkey.domain, wo _domainkey ist eine Kennzeichnung, die angibt, dass es sich bei dem DNS-Eintrag tatsächlich um einen DKIM-Eintrag handelt. Der Inhalt des DKIM-Eintrags besteht aus einer Reihe von Schlüssel-Wert-Paaren, die verschiedene Elemente festlegen, darunter:

• v: Protokollversion;
• k: Schlüsseltyp, standardmäßig RSA;
• p: Öffentlicher Schlüssel im Base64-Format.

Beispiel für einen DKIM-Eintrag

Name: s1._domainkey.example.com
Wert: v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

Der Beispiel-DKIM-Eintrag ist mit dem Selektor verknüpft s1 der beispiel.com Domain, verwendet Version 1 und enthält den öffentlichen RSA-Schlüssel im Base64-Format (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).

5.2.3. Authentifizierungsprozess

Wenn das DKIM-Protokoll sowohl auf dem Mailserver des Absenders als auch auf dem des Empfängers korrekt konfiguriert ist, sieht der Ablauf des DKIM-Authentifizierungs- und -Verifizierungsprozesses vor, dass der Mailserver des Absenders die DKIM-Signatur der Nachricht gemäß Abschnitt 5.2.1 erstellt, die der Nachricht selbst hinzugefügt wird. Die DKIM-Signatur enthält insbesondere im d Feld „Signaturdomäne“¹⁷ und in der b Tragen Sie die digitale Signatur der Nachricht ein, die mit dem privaten Schlüssel der signierenden Domäne erstellt wurde.

Nach dem Empfang einer Nachricht ruft der Mailserver des Empfängers den DKIM-Eintrag der signierenden Domain ab (d Feld der DKIM-Signatur) vom DNS-Server, der die Einträge dieser Domain enthält. Anschließend verwendet es den im DKIM-Eintrag enthaltenen öffentlichen Schlüssel, um die digitale Signatur zu überprüfen (b (Feld), das in der DKIM-Signatur enthalten ist. Ist die Überprüfung erfolgreich, wird die Nachricht an den Empfänger zugestellt.

5.2.4. Kryptografische Aspekte

Im Bereich der Kryptografie wurde bei DKIM bislang der RSA-Algorithmus verwendet, insbesondere in der Variante rsa-sha256, die seit 2007 als Standard gilt. Die neue Alternative, die durch RFC 8463 eingeführt wurde, ist Ed25519-SHA256, eine moderne Form der digitalen Signatur auf Basis elliptischer Kurven, die eine höhere Effizienz und wesentlich kompaktere Schlüssel gewährleistet.

Auf technischer Ebene bleibt RSA mit einer Schlüssellänge von 2048 Bit der universelle Standard, doch die Schlüssel sind lang und die Signaturen relativ groß, während Ed25519 neunmal kürzere Schlüssel und viermal kleinere Signaturen bietet, wobei die Signaturleistung im Vergleich zu RSA 2048 bis zu dreißigmal höher ist. Trotz dieser Vorteile ist die Unterstützung in der Praxis begrenzt: Im Jahr 2026 wird Ed25519 nur von wenigen Anbietern verifiziert, während einige große Betreiber weder die Signierung noch die Verifizierung zuverlässig unterstützen, was es als alleinige Lösung im Produktivbetrieb ungeeignet macht.

Aus diesem Grund wird die Verwendung von Ed25519 – obwohl es technisch überlegen ist – zum Zeitpunkt der Erstellung dieses Dokuments nicht empfohlen, außer in Kombination mit RSA im Rahmen einer doppelten Signatur, und zwar aus experimentellen Gründen und als Maßnahme zur Gewährleistung der zukünftigen Kompatibilität. Bis große Anbieter die Überprüfung dieses Verfahrens vollständig implementiert haben, bleibt RSA unverzichtbar, um eine maximale Zuverlässigkeit bei der Nachrichtenzustellung zu gewährleisten.

Im Hinblick auf die langfristige Sicherheit ist zu beachten, dass weder RSA noch Ed25519 gegen Angriffe durch künftige Quantencomputer resistent sind [3] und dass der Übergang zu postquanten-sicheren Algorithmen neue DKIM-Standards erfordern wird, die derzeit noch nicht existieren. Daher ist es unerlässlich, die Entwicklungen im Bereich der Kryptografie der nächsten Generation sowie künftige Empfehlungen des ACN in diesem Bereich aufmerksam zu verfolgen.

Was die Verwaltung kryptografischer Schlüssel betrifft, muss der private DKIM-Schlüssel durch strenge Sicherheitsmaßnahmen geschützt werden. Dazu gehört, ihn auf isolierten Systemen zu speichern, auf die nur autorisierte Dienste Zugriff haben, sowie restriktive Zugriffsrechte, regelmäßige Rotation und ständige Überwachung, um unbefugten Zugriff oder Kompromittierungen zu verhindern.

» Zurück zum Anfang

5.3. DMARC

DMARC – Domain-based Message Authentication, Reporting and Conformance ist ein durch RFC 7489 formalisiertes Authentifizierungsprotokoll, das¹⁸ die Mechanismen SPF und DKIM integriert und es einem Domain-Inhaber ermöglicht, den Empfängern von Nachrichten, die von dieser Domain gesendet werden, Richtlinien für den Umgang mit solchen Nachrichten vorzugeben, die die SPF- und DKIM-Prüfungen nicht bestehen.

Insbesondere führt DMARC einen Authentifizierungsmechanismus ein – das sogenannte „Alignment“ –, der die Übereinstimmung zwischen den durch SPF und DKIM authentifizierten Domänen und der Domäne überprüft, auf die sich die Nachricht von Feld der empfangenen Nachricht. Beachten Sie, dass die Überprüfung der Ausrichtung zwischen dem Nachricht von Feld, und die SPF/DKIM-Domäne schlägt in jedem Fall fehl, wenn die entsprechende SPF/DKIM-Überprüfung fehlschlägt (siehe Abbildung 4).

Die Ausrichtung kann überprüft werden in streng Modus, bei dem eine exakte Übereinstimmung zwischen den durch SPF/DKIM authentifizierten Domänen und derjenigen erforderlich ist, die sich auf die Nachricht von Feld oder entspannt, wobei es ausreicht, dass die Hauptdomains übereinstimmen, auch wenn sich die Subdomains unterscheiden können.

Zum Beispiel in entspannt Modus für Domains sub1.example.com und sub2.example.com würde für die DMARC-Überprüfung eine Übereinstimmung gefunden (da die primäre Domain, beispiel.com, ist dasselbe). In streng In diesem Modus würde die DMARC-Übereinstimmungsprüfung jedoch fehlschlagen, da keine exakte Übereinstimmung zwischen den Domänen vorliegt.

Durch die Überprüfung der Übereinstimmung kann ein Angreifer, selbst wenn es ihm gelänge, die SPF- und/oder DKIM-Prüfungen mithilfe eines Nachricht von anders als der Absenderadresse Selbst wenn die E-Mail durch SPF authentifiziert wurde und/oder von der authentifizierten Signaturdomäne stammt, würde DMARC die Diskrepanz dennoch erkennen und so eine konsistente und zuverlässige Überprüfung der Identität des Absenders gewährleisten [2].

Richtlinien für den Umgang mit fehlgeschlagenen Nachrichten¹⁹ DMARC-Überprüfung sind in einem TXT-Eintrag des relativen DNS-Servers der Absenderdomain festgelegt, der als DMARC-Eintrag bezeichnet wird und im folgenden Abschnitt dieses Absatzes erläutert wird.

DMARC ermöglicht es außerdem, Empfänger dazu aufzufordern, Berichte an die Inhaber der Absenderdomain zu senden, die sich auf Nachrichten beziehen, die angeblich von dieser Domain stammen. Auf diese Weise kann der Domaininhaber überprüfen, ob und in welchem Umfang seine Domain unbefugt genutzt wird, indem er beispielsweise analysiert, wie viele der Nachrichten, die angeblich von seiner Domain stammen, tatsächlich auf ihn zurückzuführen sind.

Genau wie bei SPF und DKIM muss auch DMARC vom Absender und vom Empfänger korrekt konfiguriert werden, insbesondere:

• Der Absender muss den DMARC-Eintrag in seinem DNS veröffentlichen und dabei die Richtlinien angeben, nach denen Nachrichten zu behandeln sind, die die DMARC-Überprüfung nicht bestehen;
• Der Empfänger muss seinen Mailserver so konfigurieren, dass bei empfangenen Nachrichten eine DMARC-Überprüfung durchgeführt wird.

5.3.1. DMARC-Eintrag

Der Name des DMARC-Eintrags hat folgende Struktur _dmarc.domain, wo _dmarc ist ein Kennzeichen, das angibt, dass es sich bei dem DNS-Eintrag um einen DMARC-Eintrag handelt, und Domäne ist die Domäne, auf die sich die Richtlinie bezieht.

Der DMARC-Eintrag besteht aus einer Reihe von Schlüssel-Wert-Paaren, die verschiedene Elemente festlegen, darunter:

• v: DMARC-Protokollversion²⁰;
• p: Richtlinie für Nachrichten, die die DMARC-Überprüfung nicht bestehen; kann einen der folgenden Werte annehmen keine, Quarantäne, ablehnen;
• aspf: Ausrichtungsmodus für die SPF-Prüfung (kann entspannt, Standardwert oder streng);
• adkim: Ausrichtungsmodus für die DKIM-Prüfung (kann entspannt, Standardwert oder streng);
• rua: E-Mail-Adressen, an die aggregierte Berichte mit statistischen und zusammenfassenden Informationen zu den von der Absenderdomain empfangenen Nachrichten gesendet werden sollen;
• ruf: E-Mail-Adressen, an die detaillierte Berichte über einzelne Nachrichten gesendet werden sollen, die von der Absenderdomain empfangen wurden und die DMARC-Überprüfung nicht bestanden haben.

Beispiel für einen DMARC-Eintrag

Name:
_dmarc.example.com
Wert:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

Der Beispiel-DMARC-Eintrag ist mit dem beispiel.com Domäne, verwendet Version 1 und gibt die ablehnen Richtlinie für E-Mails, die die DMARC-Überprüfung nicht bestehen, mit der Aufforderung streng Modus (s) zur Überprüfung der Übereinstimmung von SPF- und DKIM-Domänen sowie zur Übermittlung von Sammelberichten an die E-Mail-Adresse dmarc-reports@example.com sowie Fehlermeldungen an die Adresse dmarc-fail@example.com.

5.3.2. DMARC-Richtlinien

Wie im vorigen Absatz beschrieben, gibt der DMARC-Eintrag die Richtlinie an, die der empfangende Mailserver auf Nachrichten anwenden soll, die die DMARC-Überprüfung nicht bestehen. Folgende Richtlinien sind möglich:

• keine: Die Absenderdomain gibt keine Hinweise darauf, dass Nachrichten, die die DMARC-Überprüfung nicht bestehen, nicht zugestellt werden;
• quarantine: Die Absenderdomain gibt an, dass Nachrichten, die die DMARC-Überprüfung nicht bestehen, als verdächtig eingestuft werden sollten (z. B. einer weiteren Prüfung unterzogen, als Spam behandelt oder als verdächtig gekennzeichnet werden);
• Ablehnen: Die Absenderdomäne gibt an, dass Nachrichten, die die DMARC-Überprüfung nicht bestehen, abgelehnt werden sollen.

5.3.3. Überprüfung der Richtlinien und Antragsverfahren

Wenn das DMARC-Protokoll sowohl auf dem Mailserver des Absenders als auch auf dem des Empfängers korrekt konfiguriert ist, ruft der Mailserver des Empfängers beim Empfang der Nachricht die SPF- und DKIM-Einträge ab, um die entsprechenden Überprüfungen sowie die DMARC-Überprüfung durchzuführen (wie im Einleitungsteil von Abschnitt 5.2.4 beschrieben). Falls die Nachricht die DMARC-Überprüfung nicht besteht, wird die im DMARC-Eintrag angegebene Richtlinie (keine, Quarantäne oder ablehnen) wird angewendet.

Beachten Sie, dass jeder Mailserver lokale Heuristiken und Richtlinien anwenden kann, um über die Zustellung einer Nachricht zu entscheiden, wobei auch die Ergebnisse der SPF-, DKIM- und DMARC-Prüfungen berücksichtigt werden. Daher findet im Allgemeinen nach den oben genannten Prüfungen ein zusätzlicher Entscheidungsprozess statt („Standardfilter“ in Abbildung 5), der auch weitere Überprüfungen (wie beispielsweise Anti-Spam- und Anti-Malware-Filter) umfassen kann.

Darüber hinaus kann der empfangende Mailserver Folgendes übermitteln:

• an die in der Straße Feld des DMARC-Eintrags, aggregierte Berichte mit statistischen Daten und Zusammenfassungen zu den von der Absenderdomain empfangenen Nachrichten;
• an die in der ruf Feld des DMARC-Eintrags, detaillierte Berichte zu einzelnen Nachrichten, die von der Absenderdomain empfangen wurden und die DMARC-Überprüfung nicht bestanden haben.

» Zurück zum Anfang

6. Schlussfolgerungen

Wie im vorigen Kapitel erläutert, ist es zur bestmöglichen Abwehr von Bedrohungen im Zusammenhang mit der Vortäuschung der Absenderdomain erforderlich, dass alle drei untersuchten Protokolle gemeinsam implementiert werden, und insbesondere, dass [3]:

• die Absenderdomain veröffentlicht SPF-, DKIM- und DMARC-Einträge korrekt im DNS;
• Der Mailserver des Absenders ist so konfiguriert, dass er Nachrichten mit DKIM signiert;
• Der Mailserver des Empfängers ist so konfiguriert, dass er SPF- und DKIM-Prüfungen durchführt und DMARC-Richtlinien anwendet.

Im Hinblick auf die Protokollimplementierung werden zudem folgende Empfehlungen ausgesprochen [2]:

• Konfigurieren Sie SPF so, dass festgelegt wird, welche IP-Adressen berechtigt sind, E-Mails im Namen der Domain zu versenden; für Domains, die nicht für den E-Mail-Versand genutzt werden, beispielsweise solche, die ausschließlich für Websites bestimmt sind, sollte dennoch ein SPF-Eintrag erstellt werden, um ausdrücklich anzugeben, dass es für diese Domain keine gültigen E-Mail-Absender gibt;
• Verwenden Sie modernste Verschlüsselungsprotokolle und Algorithmen, die für DKIM-Schlüssel als sicher gelten; zum Zeitpunkt der Erstellung dieses Dokuments wird 2048-Bit-RSA empfohlen;
• den auf dem Mailserver gespeicherten privaten DKIM-Schlüssel durch strenge Zugriffsberechtigungen angemessen zu schützen und sicherzustellen, dass ausschließlich die Mailserver-Software Lesezugriff auf den Schlüssel hat;
• Konfigurieren Sie jeden Mailserver mit einem eindeutigen Schlüsselpaar und einem Selektor, um die Auswirkungen einer möglichen Kompromittierung des privaten Schlüssels zu minimieren;
• den privaten Schlüssel sowohl vor versehentlicher Offenlegung als auch vor Zugriffs- oder Manipulationsversuchen durch einen Angreifer schützen;
• sicherstellen, dass die für Mailinglisten zuständige Software DKIM-Signaturen in eingehenden Nachrichten überprüft und ausgehende Nachrichten mit neuen DKIM-Signaturen versieht;
• Verwenden Sie für jeden Drittanbieter, der E-Mails im Namen der Organisation versendet, eindeutige DKIM-Schlüsselpaare;
• DKIM-Schlüsselpaare regelmäßig (mindestens alle sechs Monate) zu rotieren, um die Auswirkungen einer möglichen Kompromittierung zu mindern;
• Schlüssel bei Verdacht auf eine Kompromittierung unverzüglich widerrufen;
• Überwachen Sie die DMARC-Berichte, um Konfigurationsfehler oder Missbrauchsversuche zu erkennen.

Weitere Informationen finden Sie in den unter „Referenzdokumente“ aufgeführten Quellen.

Es ist festzustellen, dass zum angemessenen Schutz der E-Mail-Sicherheit neben den hier untersuchten Authentifizierungsprotokollen weitere Protokolle existieren – die nicht Gegenstand dieser Leitlinien sind –, wie beispielsweise TLS (Transport Layer Security), das die Verschlüsselung des Übertragungskanals gewährleistet, sowie S/MIME und OpenPGP, die sich auf die End-to-End-Verschlüsselung und die Nachrichtenauthentifizierung beziehen.

Es sei zudem darauf hingewiesen, dass – obwohl es sich dabei nicht um ein E-Mail-Sicherheitsprotokoll im engeren Sinne handelt – im Hinblick auf die Sicherheit von E-Mail-Diensten die Implementierung von DNSSEC (Domain Name System Security Extensions) empfohlen wird, einer Erweiterung des DNS-Protokolls, die DNS-Einträge mit kryptografischen Signaturen versieht, um die Integrität und Authentizität von DNS-Abfragen zu gewährleisten. Dank DNSSEC werden beispielsweise Informationen zu SPF-, DKIM- und DMARC-Einträgen während der Übertragung geschützt, wodurch das Risiko von Manipulationen verringert und somit die Sicherheit des E-Mail-Dienstes erhöht wird.

» Zurück zum Anfang

Anhang A: Sicherheitsmaßnahmen

Nationaler Cybersicherheitsperimeter (PSNC)

PR.IP-1: Für die Konfiguration von IT-Systemen und industriellen Steuerungssystemen werden Referenzverfahren (sogenannte Baselines) definiert und verwaltet, die Sicherheitsgrundsätze (z. B. das Prinzip der minimalen Funktionalität) berücksichtigen.

1. Es gibt ein detailliertes, aktualisiertes Dokument, das – auch in Bezug auf die Kategorie ID.AM – mindestens Folgendes enthält:
   • a) die Sicherheitsrichtlinien, die für die Entwicklung von Konfigurationen von IT- und industriellen Steuerungssystemen festgelegt wurden, sowie die ausschließliche Nutzung der festgelegten Konfigurationen;
   • b) die Liste der eingesetzten IT- und industriellen Steuerungssystemkonfigurationen sowie den Verweis auf die entsprechenden Referenzverfahren;
   • c) die eingesetzten Verfahren, Methoden und Technologien, die zur Einhaltung der Sicherheitsrichtlinien beitragen.

Cloud-Regulierung – Digitale Infrastrukturen und Dienste für die öffentliche Verwaltung

PR.IP-01: Für die Konfiguration von IT-Systemen und industriellen Steuerungssystemen werden Referenzverfahren (sogenannte Baselines) definiert und verwaltet, die Sicherheitsgrundsätze (z. B. das Prinzip der minimalen Funktionalität) berücksichtigen.

1. Es werden Richtlinien und Verfahren im Hinblick auf die Anwendungssicherheit festgelegt, um eine angemessene Unterstützung bei der Planung, Umsetzung und Aufrechterhaltung von Sicherheitsfunktionen für Anwendungen zu gewährleisten; diese müssen mindestens einmal jährlich überprüft und aktualisiert werden.
2. Es gibt ein detailliertes, aktualisiertes Dokument, das – auch in Bezug auf die Kategorie ID.AM – mindestens Folgendes enthält:
   • a) die Sicherheitsrichtlinien, die für die Entwicklung von Konfigurationen von IT- und industriellen Steuerungssystemen festgelegt wurden, sowie die ausschließliche Nutzung der festgelegten Konfigurationen;
   • b) die Liste der eingesetzten IT- und industriellen Steuerungssystemkonfigurationen sowie den Verweis auf die entsprechenden Referenzverfahren;
   • c) die eingesetzten Verfahren, Methoden und Technologien, die zur Einhaltung der Sicherheitsrichtlinien beitragen.
3. Die grundlegenden Anforderungen an die Sicherheit verschiedener Anwendungen werden definiert und dokumentiert.
4. Es werden technische Kennzahlen definiert und implementiert, die zur Überwachung der Einhaltung festgelegter Sicherheitsanforderungen und Compliance-Verpflichtungen dienen.
5. Es gibt einen Prozess zur Minderung von Anwendungsschwachstellen und zur Wiederherstellung der Anwendungssicherheit, der die Behebung von Problemen nach Möglichkeit automatisiert.
6. Es gibt ein Verfahren zur Überprüfung der Kompatibilität von Geräten mit Betriebssystemen und Anwendungen.
7. Es gibt ein System zur Verwaltung von Änderungen in Bezug auf das Betriebssystem, Patches und/oder Anwendungen.

Cloud-Regulierung – Cloud-Dienste für die öffentliche Verwaltung

PR.IP-01: Für die Konfiguration von IT-Systemen und industriellen Steuerungssystemen werden Referenzverfahren (sogenannte Baselines) definiert und verwaltet, die Sicherheitsgrundsätze (z. B. das Prinzip der minimalen Funktionalität) berücksichtigen.

1. Es werden Richtlinien und Verfahren im Hinblick auf die Anwendungssicherheit festgelegt, um eine angemessene Unterstützung bei der Planung, Umsetzung und Aufrechterhaltung von Sicherheitsfunktionen für Anwendungen zu gewährleisten; diese müssen mindestens einmal jährlich überprüft und aktualisiert werden [IaaS, SaaS].
2. Es gibt ein detailliertes, aktualisiertes Dokument, das – auch in Bezug auf die Kategorie ID.AM – mindestens Folgendes enthält:
   • a) die Sicherheitsrichtlinien, die für die Entwicklung von Konfigurationen von IT- und industriellen Steuerungssystemen festgelegt wurden, sowie die ausschließliche Nutzung der festgelegten Konfigurationen;
   • b) die Liste der eingesetzten IT- und industriellen Steuerungssystemkonfigurationen sowie den Verweis auf die entsprechenden Referenzverfahren;
   • c) die eingesetzten Prozesse, Methoden und Technologien, die zur Einhaltung der Sicherheitsrichtlinien beitragen [SaaS].
3. Die grundlegenden Anforderungen an die Sicherheit verschiedener Anwendungen werden definiert und dokumentiert.
4. Es werden technische Kennzahlen definiert und implementiert, die zur Überwachung der Einhaltung festgelegter Sicherheitsanforderungen und Compliance-Verpflichtungen dienen. 5. Es gibt einen Prozess zur Minderung von Anwendungsschwachstellen und zur Wiederherstellung der Anwendungssicherheit, der die Behebung von Problemen nach Möglichkeit automatisiert.
5. Es gibt ein Verfahren zur Überprüfung der Kompatibilität von Geräten mit Betriebssystemen und Anwendungen [PaaS, SaaS].
6. Es gibt ein Änderungsmanagement-System für Betriebssysteme, Patches und/oder Anwendungen [PaaS, SaaS].

NIS 2

PR.PS-01: Es werden Verfahren für das Konfigurationsmanagement festgelegt und angewendet.

1. Zumindest für relevante Informationen und Netzwerksysteme sind deren sichere Basiskonfigurationen (abgehärtet) in einer aktuellen Liste definiert und dokumentiert.
2. In Übereinstimmung mit den in der Maßnahme GV.PO-01 genannten Richtlinien werden Verfahren in Bezug auf Punkt 1 festgelegt und dokumentiert.

» Zurück zum Anfang

Literaturverzeichnis

[1] NIST, „Technical Note 1945“.
[2] NIST, „NIST Special Publication 800-177 Revision 1“
[3] Nationale Cybersicherheitsbehörde, „Post-Quanten- und Quantenkryptografie – Vorbereitung auf die Quantenbedrohung“.
[4] Nationale Cybersicherheitsbehörde, „Rahmenwerk für die E-Mail-Authentifizierung“.

» Zurück zum Anfang