KONF.2.1 — Grundkonfiguration für Systeme

SOLLTE Security level: normal-SdT Effort 3 BSI-Stand-der-Technik-Kernel
Statement (Anforderung)

Konfiguration für IT-Systeme SOLLTE eine Grundkonfiguration dokumentieren.

Guidance (Erläuterung)

Eine Grundkonfiguration (engl. baseline configuration) bezeichnet hier einen dokumentierten Ausgangszustand, der alle sicherheitsrelevanten Einstellungen, Dienste und Komponenten umfasst und als verbindlicher Referenzpunkt für den Betrieb und die Härtung dient. Sie stellt damit eine Art „Zielzustand“ dar, anhand dessen spätere Änderungen überprüft oder Abweichungen erkannt werden können. Ohne eine solche Referenz könnte es bei Installationen, Updates oder Wiederherstellungen zu unsicheren Abweichungen kommen, etwa wenn unnötige Dienste aktiv bleiben, Standardkonten nicht deaktiviert sind oder Kommunikationsschnittstellen unkontrolliert offenstehen; umgekehrt kann eine saubere Grundkonfiguration sicherstellen, dass Systeme konsistent, nachvollziehbar und auf Basis etablierter Sicherheitsanforderungen betrieben werden. Hierzu gehört z.B. die Konfiguration der Uhrensychronisation, von DNS und Verzeichnisdiensten, die Änderung von Default-Zugangsdaten oder der automatische Abruf benötigter Lizenzen. Die Umsetzung einer Grundkonfiguration kann durch verschiedene Maßnahmen unterstützt werden: (1) Es ist sinnvoll, Herstellerdokumentationen zu sichten und empfohlene Härtungseinstellungen (z. B. Deaktivierung unsicherer Protokolle) als Ausgangspunkt zu übernehmen. (2) Ergänzend können Empfehlungen des BSI oder Benchmarks wie die CIS Benchmarks herangezogen werden, um systematisch sicherheitskritische Parameter zu prüfen und einzupflegen. (3) Für komplexe Umgebungen kann ein Konfigurationsskript oder ein Automatisierungs-Tool (z. B. Ansible, Puppet, Chef) genutzt werden, um eine reproduzierbare Baseline einzuspielen und Abhängigkeiten der Komponenten konsistent zu berücksichtigen. Auf diese Weise kann die Institution sicherstellen, dass jede Installation oder Wiederherstellung eines Systems auf einer überprüfbaren und einheitlichen Basis erfolgt.

Statement properties
NameValue
target_object_categories IT-Systeme
documentation Konfigurationshistorie
result eine Grundkonfiguration
action_word dokumentieren
modal_verb SOLLTE
Control properties
NameValue
alt-identifier 8bd05aba-b395-43cf-a38e-f4e8656df7c4
sec_level normal-SdT
effort_level 3
Framework mappings this control ↔ the corresponding control in each framework (toggle per framework in Settings)

Auto-generated similarity matches — orientation only, verify before use. The score is the text-similarity confidence, not an authoritative crosswalk.

Framework Mapped control Mapped control title Match
GitHub Security Controls 🐙 GH-REP-01 Protection on critical branches
GitHub Security Controls 🐙 GH-REP-02 Pull-request-only changes
GitHub Security Controls 🐙 GH-REP-03 Two approvals plus CODEOWNERS
GitHub Security Controls 🐙 GH-REP-04 Dismiss stale approvals
GitHub Security Controls 🐙 GH-REP-05 Required status checks
GitHub Security Controls 🐙 GH-REP-06 No force push or deletion
GitHub Security Controls 🐙 GH-REP-07 Signed commits
GitHub Security Controls 🐙 GH-REP-08 CODEOWNERS maintained
GitHub Security Controls 🐙 GH-REP-09 Organization rulesets without bypass
GitHub Security Controls 🐙 GH-REP-10 Stale repository lifecycle
GitHub Security Controls 🐙 GH-ACT-01 Read-only default token
GitHub Security Controls 🐙 GH-ACT-02 Action allow-list
GitHub Security Controls 🐙 GH-ACT-03 SHA-pin third-party actions
NIS2 🇪🇺 Art. 21(2)(d); Art. 21(2)(e) SHA-pin third-party actions
ISO 27001:2013 & 27001:2022 🌐 A.8.28; A.5.21 SHA-pin third-party actions
Mindeststandard-des-BSI-zur-Nutzung-externer-Cloud-Dienste (Version 2.1) 🇩🇪 n/a (consumer-side development control) SHA-pin third-party actions
GitHub Security Controls 🐙 GH-ACT-04 Gate fork workflows
GitHub Security Controls 🐙 GH-ACT-05 Dangerous triggers reviewed
GitHub Security Controls 🐙 GH-ACT-06 Deployment environments
GitHub Security Controls 🐙 GH-ACT-07 OIDC to cloud providers
GitHub Security Controls 🐙 GH-ACT-08 Hardened self-hosted runners
GitHub Security Controls 🐙 GH-ACT-09 Runner segmentation
GitHub Security Controls 🐙 GH-ACT-10 Central reusable workflows
GitHub Security Controls 🐙 GH-ACT-11 Build provenance
GitHub Security Controls 🐙 GH-ACT-12 Workflow log governance
GitHub Security Controls 🐙 GH-SRV-01 Supported version and patching
GitHub Security Controls 🐙 GH-SRV-02 Hardened host and management console
GitHub Security Controls 🐙 GH-SRV-03 TLS configuration
GitHub Security Controls 🐙 GH-SRV-04 Network segmentation
GitHub Security Controls 🐙 GH-SRV-05 External authentication
GitHub Security Controls 🐙 GH-SRV-06 System monitoring
GitHub Security Controls 🐙 GH-SRV-07 backup-utils with restore tests
GitHub Security Controls 🐙 GH-SRV-08 Actions storage hardening
Sub-controls
Raw OSCAL JSON (complete control)
{
  "class": "BSI-Stand-der-Technik-Kernel",
  "controls": [
    {
      "class": "BSI-Stand-der-Technik-Kernel",
      "id": "KONF.2.1.1",
      "links": [
        {
          "href": "#TEST.2.1",
          "rel": "related"
        }
      ],
      "parts": [
        {
          "id": "KONF.2.1.1_stm",
          "name": "statement",
          "props": [
            {
              "name": "target_object_categories",
              "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/target_object_categories.csv",
              "value": "IT-Systeme"
            },
            {
              "name": "documentation",
              "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/documentation_guidelines.csv",
              "value": "Konfigurationshistorie"
            },
            {
              "name": "result",
              "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/result.csv",
              "value": "eine Versionierung vorheriger Konfigurationen"
            },
            {
              "name": "action_word",
              "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/action_words.csv",
              "value": "verankern"
            },
            {
              "name": "modal_verb",
              "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/modal_verbs.csv",
              "value": "SOLLTE"
            }
          ],
          "prose": "Konfiguration für IT-Systeme SOLLTE eine Versionierung vorheriger Konfigurationen verankern."
        },
        {
          "id": "KONF.2.1.1_gdn",
          "name": "guidance",
          "prose": "Die Versionierung bezeichnet hier die strukturierte Nachvollziehbarkeit von Änderungen an Konfigurationen, also das Speichern, Dokumentieren und bei Bedarf Wiederherstellen älterer Zustände eines IT-Systems. Sie unterscheidet sich von einem einfachen Backup dadurch, dass nicht nur eine Kopie vorliegt, sondern explizit eine fortlaufende Historie mit Vergleichen, Rücksetzpunkten (rollback points) und optional Kommentaren geführt wird. Der Zweck liegt darin, dass eine ungewollte oder fehlerhafte Anpassung an einer Konfiguration im Betrieb schnell erkannt und – wenn erforderlich – präzise auf einen definierten, funktionsfähigen Zustand zurückgesetzt werden kann. Ohne eine solche Versionierung könnte eine fehlerhafte Änderung unbemerkt bleiben oder nur schwer rückgängig gemacht werden. Praktisch umgesetzt kann dies z. B. durch den Einsatz von Konfigurationsmanagement-Tools erfolgen, die automatisch Änderungen versionieren und mit Prüfsummen sichern. Alternativ kann eine Institution auch Konfigurationsdateien regelmäßig in ein Versionsverwaltungssystem wie Git einspielen. Zusätzlich kann es hilfreich sein, Konfigurationsänderungen über standardisierte Änderungsprozesse einzupflegen, sodass jede Anpassung nachvollziehbar protokolliert wird. Eine weitere Möglichkeit kann die Einrichtung von Skripten sein, die Konfigurationsstände automatisch aus Geräten exportieren und revisionssicher ablegen. Zur Umsetzung können Anwendungen zur Geheimnisverwaltung, oft als Secrets-Manager oder Vault bezeichnet, eingesetzt werden. Solche Anwendungen speichern alle Geheimnisse zentral und hochverschlüsselt und stellen sie erst bei Bedarf zur Laufzeit über eine authentifizierte und gesicherte Schnittstelle (API) zur Verfügung. Eine weitere, weit verbreitete Praxis ist die Auslagerung von Secrets aus den Konfigurationsdateien in Umgebungsvariablen (Environment Variables) des ausführenden Systems, wodurch eine strikte Trennung von Code und Konfiguration erreicht wird. Alternativ kann auch die Konfigurationsdatei selbst oder zumindest die Abschnitte, die Geheimnisse enthalten, verschlüsselt werden, wobei dies erfordert, dass der zur Entschlüsselung notwendige Schlüssel seinerseits sicher an die Applikation übergeben wird."
        }
      ],
      "props": [
        {
          "name": "alt-identifier",
          "value": "3b25d629-b441-4365-96fb-d06e2e35b89d"
        },
        {
          "name": "sec_level",
          "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/security_level.csv",
          "value": "normal-SdT"
        },
        {
          "name": "effort_level",
          "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/effort_level.csv",
          "value": "3"
        }
      ],
      "title": "Versionierung der Systemkonfiguration"
    }
  ],
  "id": "KONF.2.1",
  "parts": [
    {
      "id": "KONF.2.1_stm",
      "name": "statement",
      "props": [
        {
          "name": "target_object_categories",
          "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/target_object_categories.csv",
          "value": "IT-Systeme"
        },
        {
          "name": "documentation",
          "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/documentation_guidelines.csv",
          "value": "Konfigurationshistorie"
        },
        {
          "name": "result",
          "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/result.csv",
          "value": "eine Grundkonfiguration"
        },
        {
          "name": "action_word",
          "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/action_words.csv",
          "value": "dokumentieren"
        },
        {
          "name": "modal_verb",
          "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/modal_verbs.csv",
          "value": "SOLLTE"
        }
      ],
      "prose": "Konfiguration für IT-Systeme SOLLTE eine Grundkonfiguration dokumentieren."
    },
    {
      "id": "KONF.2.1_gdn",
      "name": "guidance",
      "prose": "Eine Grundkonfiguration (engl. baseline configuration) bezeichnet hier einen dokumentierten Ausgangszustand, der alle sicherheitsrelevanten Einstellungen, Dienste und Komponenten umfasst und als verbindlicher Referenzpunkt für den Betrieb und die Härtung dient. Sie stellt damit eine Art „Zielzustand“ dar, anhand dessen spätere Änderungen überprüft oder Abweichungen erkannt werden können. Ohne eine solche Referenz könnte es bei Installationen, Updates oder Wiederherstellungen zu unsicheren Abweichungen kommen, etwa wenn unnötige Dienste aktiv bleiben, Standardkonten nicht deaktiviert sind oder Kommunikationsschnittstellen unkontrolliert offenstehen; umgekehrt kann eine saubere Grundkonfiguration sicherstellen, dass Systeme konsistent, nachvollziehbar und auf Basis etablierter Sicherheitsanforderungen betrieben werden. Hierzu gehört z.B. die Konfiguration der Uhrensychronisation, von DNS und Verzeichnisdiensten, die Änderung von Default-Zugangsdaten oder der automatische Abruf benötigter Lizenzen. Die Umsetzung einer Grundkonfiguration kann durch verschiedene Maßnahmen unterstützt werden: (1) Es ist sinnvoll, Herstellerdokumentationen zu sichten und empfohlene Härtungseinstellungen (z. B. Deaktivierung unsicherer Protokolle) als Ausgangspunkt zu übernehmen. (2) Ergänzend können Empfehlungen des BSI oder Benchmarks wie die CIS Benchmarks herangezogen werden, um systematisch sicherheitskritische Parameter zu prüfen und einzupflegen. (3) Für komplexe Umgebungen kann ein Konfigurationsskript oder ein Automatisierungs-Tool (z. B. Ansible, Puppet, Chef) genutzt werden, um eine reproduzierbare Baseline einzuspielen und Abhängigkeiten der Komponenten konsistent zu berücksichtigen. Auf diese Weise kann die Institution sicherstellen, dass jede Installation oder Wiederherstellung eines Systems auf einer überprüfbaren und einheitlichen Basis erfolgt."
    }
  ],
  "props": [
    {
      "name": "alt-identifier",
      "value": "8bd05aba-b395-43cf-a38e-f4e8656df7c4"
    },
    {
      "name": "sec_level",
      "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/security_level.csv",
      "value": "normal-SdT"
    },
    {
      "name": "effort_level",
      "ns": "https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/tree/main/Dokumentation/namespaces/effort_level.csv",
      "value": "3"
    }
  ],
  "title": "Grundkonfiguration für Systeme"
}
View JSON API Download JSON