IT-Grundschutz auf AWS: Vom Konzept zur praktischen Umsetzung

Viele IT-Abteilungen der öffentlichen Verwaltung kennen den IT-Grundschutz des BSI als Regelwerk und täglichen Begleiter: Schutzbedarfsfeststellung, Baustein-Mapping, Maßnahmenumsetzung – und die Frage: „Wie belegen wir das im Audit?“

Dieser Beitrag beschreibt praxisnah, wie ausgewählte IT-Grundschutz-Anforderungen in AWS umgesetzt und technisch nachweisbar gemacht werden – mit Fokus auf wiederholbare Baselines, automatisierbare Kontrollen und auditfähige Evidence, gemappt auf Cloud-Services, so dass Organisationen IT-Grundschutz in der Cloud umsetzen können. Mit dem AWS Enterprise Support-Kunden erhalten direkten Zugang zu Technical Account Managern (TAMs), die bei der Umsetzung IT-Grundschutz-konformer Architekturen unterstützen, z. B. durch Threat-Model-Workshops. Durch kollaborative Planungsworkshops, Best Practices und maßgeschneiderte Supportpläne identifizieren TAMs Risiken frühzeitig, unterstützen die Operationalisierung von BSI-Standards und entwickeln resiliente Architekturen

Die Herausforderung: IT-Grundschutz trifft Cloud-Realität

Der IT-Grundschutz des BSI entstand für on-premises-Systeme. Die Cloud-Transformation bringt drei Herausforderungen:

Shared Responsibility: Wer verantwortet welche Sicherheitskontrollen?
Technische Umsetzung: Wie übersetzen wir Grundschutz-Maßnahmen in Cloud-Services?
Nachweisführung: Wie belegen wir die Compliance im Audit?

Praxisbeispiel: IT-Grundschutz im Projekt eCORDA (BMFTR)

Das Bundesministerium für Bildung und Forschung (BMF) implementierte mit Unterstützung von M2 technology & project consulting GmbH und AWS eine sichere, IT-Grundschutz-konforme AWS-Plattform im Projekt eCORDA. Die Freigabe erfolgte im Rahmen der Projektabnahme durch das BMF und die beteiligten Sicherheitsarchitekten (u. a. Dr. Wolfgang Schult, David Surey oder Michael Wahlers).

Umgesetzt wurden:

Eine sichere, nachvollziehbare Cloud-Basis (Landing Zone) etabliert
Klare Mandantentrennung und Zuständigkeiten definiert
Zentrale, manipulationsgeschützte Protokollierung eingerichtet
Standardisierte Sicherheitsbaselines erstellt
Kontinuierliche statt punktuelle Compliance-Prüfungen umgesetzt
Betriebsfähigkeit für die Verwaltung sichergestellt (Governance, Nachweise, Change-Prozesse)

Typische Herausforderungen:

„Wer darf was?“ → Strikte Rollenmodelle mit technischer Durchsetzung.
„Wie verhindern wir Drift?“ → Automatisierte Kontrollen gegen manuelle Änderungen.
„Wie liefern wir Evidence?“ → Automatisch erzeugte, auditfähige Nachweise.
„Wie skalieren wir Governance?“ → Multi-Account-Strategie mit zentralisierten Richtlinien.
„Wie bleiben wir handlungsfähig?“ → Security by Design.
Sicherheit wurde von Anfang an integriert, nicht nachträglich aufgesetzt.

Multi-Account als Sicherheitsfundament

Wesentlicher Baustein: Strukturierte Account-Architektur mit:

Separate Accounts für verschiedene Schutzzonen und Verantwortlichkeiten eingerichtet
Produktiv- und Nicht-Produktivumgebungen strikt getrennt
Dedizierte Security/Logging-Komponenten als unabhängige Kontrollinstanzen implementiert
Den Blast-Radius bei Incidents durch Account-Isolation begrenzt

Von der Anforderung zur technischen Kontrolle

Operationalisierung nach Prinzip:

Was? Die normative Anforderung aus dem IT-Grundschutz
Wie? Die technische Umsetzung durch AWS-Services und -Konfigurationen
Nachweis? Die automatisch erzeugte Evidence für Audits

So haben wir einen transparenten Pfad von der Anforderung bis zum Nachweis geschaffen.

Technische Bausteine in der Praxis

Quellcode und Referenzbeispiele stammen von M2 technology & project consulting GmbH. Sie wurden im eCORDA-Projekt eingesetzt und bei der Projektabnahme durch BMF freigegeben.

1. ORP.4: Identitäts- und Berechtigungsmanagement (IAM)

Die Basis für sichere Zugriffskontrolle sind Permission Boundaries, die präventiv unzulässige Aktionen verhindern:

data "aws_iam_policy_document" "permission_boundary" {
  statement {
    sid    = "CreateOrChangeRoleOnlyWithRoleBoundary"
    effect = "Allow"
    actions = [
      "iam:AttachRolePolicy",
      "iam:CreateRole",
      # weitere IAM-Aktionen
    ]
    resources = ["*"]
    condition {
      test     = "StringEquals"
      values   = ["arn:aws:iam::${var._account_info.account_id}:policy/${local.permission_boundary_name}"]
      variable = "iam:PermissionsBoundary"
    }
  }
  
  statement {
    sid    = "DenyChangesToPermissionBoundary"
    effect = "Deny"
    actions = [
      "iam:CreatePolicyVersion",
      "iam:DeletePolicy",
      # weitere Schutzaktionen
    ]
    resources = ["arn:aws:iam::${var.account_info.account_id}:policy/${local.permission_boundary_name}"]
  }
}

Auf diesen Boundaries bauen funktionsspezifische Rollen auf:

module "developer" {
  source = "./trusted_role"
  customer_short = var.config.customer_short
  role_name = "${local.name_prefix}Developer"
  # weitere Parameter
}

module "operator" {
  source = "./trusted_role"
  role_name = "${local.name_prefix}Operator"
  # weitere Parameter
}

IT-Grundschutz-Mapping: Dies erfüllt ORP.4.A1 (IAM-Richtlinien), A2 (Berechtigungskonzept) und A5 (Privilege Escalation Prevention).

2. CON.1: Kryptographisches Konzept

Für Transportverschlüsselung setzen wir auf aktuelle TLS-Standards gemäß BSI-Anforderungen:

resource "aws_alb_listener" "https" {
  load_balancer_arn = aws_alb.lb.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS-1-3-2021-06"
  certificate_arn   = aws_acm_certificate_validation.cert_validation.certificate_arn

  # weitere Konfigurationen
}

Datenverschlüsselung erfolgt über AWS KMS mit automatischer Schlüsselrotation:

resource "aws_kms_key" "general" {
  description = "IT-Grundschutz General Purpose Key"
  enable_key_rotation = true  # CON.1.A4
  deletion_window_in_days = 10
}

resource "aws_ebs_encryption_by_default" "encrypt_ebs" {
  enabled = true
}

IT-Grundschutz-Mapping: Dies erfüllt CON.1.A1 (kryptographische Verfahren), A2 (Schlüssellängen) und A3 (Transportverschlüsselung).

3. OPS.1.1.5: Zentrale Protokollierung

Manipulationsgeschützte, zentrale Logs sind entscheidend für Audit-Trails:

resource "aws_cloudtrail" "cloudtrail" {
  name = "cloudtrail"
  s3_bucket_name = aws_s3_bucket.global_log.bucket
  s3_key_prefix = local.cloudtrail_prefix
  kms_key_id = module.kms_log.kms_master_arn
  include_global_service_events = true
}

resource "aws_s3_bucket" "global_log" {
  bucket = "global.logs.${module.config.domain_name}"
}

resource "aws_s3_bucket_public_access_block" "bucket" {
  bucket = aws_s3_bucket.global_log.id
  block_public_acls = true
  block_public_policy = true
  restrict_public_buckets = true
  ignore_public_acls = true
}

Für Compliance-gerechte Log-Aufbewahrung:

resource "aws_s3_bucket_lifecycle_configuration" "lifecycle" {
  bucket = aws_s3_bucket.global_log.id
  rule {
    id = "compliance-retention"
    transition {
      days = 365
      storage_class = "GLACIER"
    }
    expiration {
      days = 365*7  # 7 Jahre Aufbewahrung
    }
    status = "Enabled"
  }
}

IT-Grundschutz-Mapping: Dies erfüllt OPS.1.1.5.A3 (zentrale Protokollierung), A4 (Schutz der Logs) und A12 (Verschlüsselung).

4. CON.3: Backup & Recovery

Automatisierte Datensicherung mit definierten RPO/RTO-Zielen:

resource "aws_rds_cluster" "db" {
  engine = var.engine
  engine_version = var.engine_version
  backup_retention_period = 30  # 30 Tage Aufbewahrung
  preferred_backup_window = "03:00-04:00"
  # weitere Parameter
}

IT-Grundschutz-Mapping: Dies erfüllt CON.3.A1 (Backup-Strategie) und A3 (regelmäßige Sicherungen).

Audit-fähige Nachweise

Die Plattform erzeugt automatisch Nachweise für Audits:

Organizations-Struktur: Account-Hierarchie und Zuweisungen
Policy-Versionierung: Nachvollziehbare Änderungshistorie von SCPs und IAM-Policies
CloudTrail-Status: Nachweis der Protokollierung mit Log-Validierung
AWS Config: Compliance-Reports und Konfigurationsprüfungen
Security Hub: Konsolidierte Sicherheitsberichte

Die Methodik: Vom „Was“ zum „Wie“

Der systematische Ansatz für IT-Grundschutz auf AWS umfasst:

Strukturanalyse: Identifikation von Prozessen, Anwendungen, Systemen
Schutzbedarfsfeststellung: Bewertung von Vertraulichkeit, Integrität, Verfügbarkeit
Baustein-Mapping: Zuordnung der IT-Systeme zu IT-Grundschutz-Bausteinen
Gap-Analyse: Abgleich zwischen Ist-Zustand und BSI-Anforderungen
Technische Umsetzung: Implementierung der AWS-Controls
Kontinuierliche Überwachung: Automatisierte Compliance-Prüfung

Grundlagen: Der IT-Grundschutz im Cloud-Kontext

Der IT-Grundschutz des BSI ist modular aufgebaut und definiert drei Anforderungsstufen:

B (Basis): Grundlegende Sicherheit für alle Organisationen (MUSS)
S (Standard): Normaler Schutzbedarf, aktueller Stand der Technik (SOLL)
H (Erhöht): Zusätzliche Maßnahmen für kritische Daten/Systeme (SOLLTE)

Für AWS-Umgebungen sind besonders relevant:

Baustein	Fokus	AWS-Umsetzung
ORP.4	IAM	AWS IAM, Organizations, SCP
CON.1	Kryptographie	KMS, ACM, TLS-Policies
OPS.1.1.5	Logging	CloudTrail, CloudWatch, S3
CON.3	Backup	AWS Backup, Snapshots
OPS.2.2	Cloud-Nutzung	Landing Zone, Control Tower

Konkrete Umsetzungsbeispiele

AWS Multi-Account-Struktur

Eine grundschutzkonforme AWS-Umgebung ist typischerweise so strukturiert:

├── Management Account (Root)
│   ├── AWS Organizations (zentrale Verwaltung)
│   ├── Service Control Policies (präventive Kontrollen)
│
├── Security Account
│   ├── CloudTrail Destination Bucket (zentrale Logs)
│   ├── AWS Security Hub (Compliance Dashboard)
│   ├── KMS Keys (zentrale Verschlüsselungsschlüssel)
│
├── Audit Account
│   ├── Read-Only Cross-Account Access
│   ├── Compliance Officer Role
│   ├── IAM Access Analyzer
│
├── Shared Services
│   ├── Transit Gateway (zentrale Netzwerkkontrolle)
│   ├── Network Firewall
│   ├── DNS-Management
│
└── Workload Accounts (Produktiv/Test/Entwicklung)
    ├── App Account 1 (isolierte Ressourcen)
    └── App Account 2 (isolierte Ressourcen)

Baseline mit Infrastructure as Code

Wir nutzen Terraform, um Compliance-Einstellungen konsistent und versioniert zu verwalten:

locals {
  compliance = {
    iam_mfa_required = true,
    encryption_required = "kms",
    logging_enabled = true,
    backup_retention_days = 35,
    tls_min_version = "TLSv1.2"
  }
}

# Zentrale KMS-Schlüssel mit automatischer Rotation
resource "aws_kms_key" "general" {
  description = "IT-Grundschutz General Purpose Key"
  enable_key_rotation = true  # CON.1.A4
  tags = { Compliance = "IT-Grundschutz" }
}

# Automatisierte Compliance-Überprüfung
resource "aws_securityhub_account" "main" {}
resource "aws_securityhub_standards_subscription" "cis" {
  standards_arn = "arn:aws:securityhub::standards/aws-foundational-security-best-practices/v/1.0.0"
}

Fazit: Grundschutz ist Cloud-kompatibel

eCORDA zeigt: IT-Grundschutz ist mit AWS kompatibel für alle Kunden mit vergleichbaren Anforderungen. Systematisches Mapping, Automatisierung und „Grundschutz as Code“ ermöglichen Konsistenz, Auditierbarkeit und Skalierbarkeit. Folgendes ist dabei zu betragen:

IT-Grundschutz systematisch auf AWS-Services mappen
Sicherheitskontrollen automatisieren und codifizieren
Audit-taugliche Nachweise kontinuierlich generieren
Security by Design statt nachträglicher Absicherung umsetzen

Der Schlüssel liegt in der Transformation vom statischen Dokument zum dynamischen Code – „Grundschutz as Code“. Dies ermöglicht:

Konsistenz: Einheitliche Sicherheitsstandards über alle Umgebungen
Automatisierung: Kontinuierliche statt punktuelle Compliance-Prüfung
Nachvollziehbarkeit: Versionierte Sicherheitsrichtlinien mit klarem Audit-Trail

Die Zukunft des IT-Grundschutzes in der Cloud liegt nicht in dicken Dokumenten, sondern in automatisierten, sich selbst überprüfenden Infrastrukturen. Starten Sie Ihren Weg zum „Grundschutz as Code“ mit AWS.gibt

Über die Autoren

	Dr. Wolfgang Schult ist ein erfahrener Berater in den Bereichen Anforderungs- und Systemanalyse sowie Softwareentwicklung. Er verfügt über langjährige Projekterfahrung als Systemarchitekt, insbesondere mit Technologien von Amazon, Microsoft und Oracle. Neben der Beratung des Managements bei Produkt- und Architekturentscheidungen umfassten seine Aufgaben auch die Konzeption und Umsetzung von IT-Sicherheitslösungen, das fachliche und technische Design sowie die Führung und Koordination von Projektteams.
	Dietrich Bartsch arbeitet bei der M2. technology & project consulting GmbH und ist ein erfahrener Data-Analytics-Experte mit Schwerpunkt auf Datenintegration, -analyse und -visualisierung. Als Team Lead des BI-Consulting-Teams verantwortet er Projekte in den Bereichen Business Intelligence, Data Engineering und Technologieberatung. Er entwickelt interaktive BI-Lösungen mit Power BI und Tableau und ist AWS-zertifiziert (Data Analytics Specialty). Darüber hinaus ist Dietrich Bartsch als Keynote Speaker zu den Themen Data Analytics, IT-Security und sichere Cloud-Infrastrukturen tätig, mit einem besonderen Fokus auf den Einsatz von KI in der modernen Datenanalyse.
	Michael Wahlers, Principal Solutions Architect und Public Sector Specialist, ist in Deutschland, Österreich und der Schweiz tätig. Mit leidenschaftlichem Enthusiasmus unterstützt er öffentliche Einrichtungen mit innovativen digitalen Lösungen. Seine Expertise gewährleistet eine nahtlose Servicebereitstellung und macht ihn zu einem wertvollen Aktivposten für die Gestaltung der digitalen Zukunft des öffentlichen Sektors in der Region. Neben seinen beruflichen Verpflichtungen erforscht er gerne komplexe verteilte Systeme und bezieht lokale Kontexte in seine Arbeit mit ein.
	Christian Schäfer beschäftigt sich seit über 25 Jahren mit der Transformation von Geschäftsprozessen mit Hilfe von Technologie in dynamischen und datengetriebenen Organisationen. Berufliche Stationen führten den ehemaligen Offizier der Bundeswehr zu Accenture Digital, wo er als Principal Director Data Science tätig war. Von 2018 bis 2020 war er Leiter des Deloitte Analytics Institutes in Berlin, einem Expertenzentrum an der Schnittstelle von Business, Technologie und Wissenschaft. In Zeitraum 2020 bis 2022 verantwortete er das Marksegment AI-Insights bei Deloitte in Deutschland. Christian Schäfer leitet seit 2023 den Bereich Business Development für den öffentlichen Sektor bei Amazon Web Services in Deutschland.
	David Surey ist Senior Technical Account Manager bei AWS Enterprise Support mit Fokus auf den deutschen, öffentlichen Sektor. Mit 25 Jahren Erfahrung in verschiedenen IT-Rollen und Branchen unterstützt er Behörden und öffentliche Einrichtungen bei der sicheren Cloud- Transformation. Er führt Architektur-Reviews durch, begleitet kritische Migrationen und treibt Innovationen in hochregulierten Umgebungen voran. Seine Expertise umfasst Sovereign Cloud-Lösungen, Compliance-Anforderungen und die Modernisierung komplexer Legacy-Infrastrukturen.

AWS Germany – Amazon Web Services in Deutschland