Praxislabor — SAP-C02 AWS Certified Solutions Architect Professional

Übersicht

Voraussetzungen

Schritte

1. 1.Wählen Sie unsere Terraform-Version und AWS-Region

   Standard-Eröffnung. Organizations ist ein globaler Dienst, aber seine API-Endpunkte befinden sich in us-east-1. Führen Sie Terraform auf Organisationsebene immer von us-east-1 aus – die SAP-C02-Prüfung testet genau dieses Detail unter Network Connectivity and Content Delivery bei der Bewertung von Multi-Region-Architekturen.

   Kopieren

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.60"
       }
     }
   }
   
   provider "aws" {
     region = "us-east-1"
   
     default_tags {
       tags = {
         Project   = "certlabpro-sap-c02"
         ManagedBy = "terraform"
       }
     }
   }
   
   data "aws_caller_identity" "current" {}
   
   # Replace with the 12-digit account ID of the *shared-services* account
   # we are wiring cross-account trust to in Step 4.
   locals {
     shared_services_account_id = "111122223333"
   }

2. 2.Bootstrap von AWS Organizations mit einer OU-Struktur

   Ressourcen:

   • AWS Organizations

   Wenn das Verwaltungskonto nicht bereits ein Org-Master ist, erstellt diese Ressource die Organisation. Die Einstellung feature_set = "ALL" aktiviert SCPs (die Alternative consolidated billing only lässt SCPs komplett weg – SAP-C02 testet beide Modi). Die Liste enabled_policy_types wählt die drei Richtlinientypen aus, die dieses Lab verwendet; Sie würden BACKUP_POLICY und AISERVICES_OPT_OUT_POLICY für diese Bereiche hinzufügen.

   Die beiden OUs, die wir erstellen – Production und NonProduction – sind die SAP-C02-Referenzform für die Guardrail-Umfassungsbestimmung. SCPs werden an OUs angehängt; OUs enthalten Konten. Die Platzierung von Konten in OUs ist der größte Hebel, den ein Multi-Account-Architekt hat, da jede SCP von der OU auf jedes darunterliegende Konto kaskadiert.

   Kopieren

   resource "aws_organizations_organization" "main" {
     feature_set = "ALL"
   
     enabled_policy_types = [
       "SERVICE_CONTROL_POLICY",
       "TAG_POLICY",
     ]
   
     aws_service_access_principals = [
       "cloudtrail.amazonaws.com",
     ]
   }
   
   resource "aws_organizations_organizational_unit" "production" {
     name      = "Production"
     parent_id = aws_organizations_organization.main.roots[0].id
   }
   
   resource "aws_organizations_organizational_unit" "non_production" {
     name      = "NonProduction"
     parent_id = aws_organizations_organization.main.roots[0].id
   }

3. 3.Eine Service Control Policy anfügen, die Workloads auf zugelassene Regionen beschränkt

   Ressourcen:

   • AWS Organizations

   SCPs sind das SAP-C02-Governance-Primitiv – sie sind der einzige Mechanismus, der Administratoren eines Mitgliedskontos daran hindern kann, etwas zu tun, Punkt. Das am häufigsten getestete SCP-Muster ist die Beschränkung auf zugelassene Regionen: Selbst wenn ein IAM-Administrator eines Mitgliedskontos *:* jedem gewährt, blockiert die SCP-auferlegte Regions-Guardrail immer noch Operationen außerhalb des zugelassenen Satzes.

   Die untenstehende Richtlinie verweigert jede ec2:*-, rds:*- und lambda:*-Aktion, deren aws:RequestedRegion nicht us-east-1 oder us-west-2 ist. Globale Dienste (IAM, Organizations, CloudFront) sind davon unberührt, da sie die Bedingung RequestedRegion nicht beachten. SAP-C02 testet genau diese Ausnahme – Studenten, die *:* außerhalb zugelassener Regionen verweigern, brechen versehentlich IAM und sperren sich aus.

   Die Richtlinie wird an beide OUs aus Schritt 2 angehängt. Konten innerhalb dieser OUs werden verwaltet; das Verwaltungskonto ist davon unberührt (eine wiederkehrende SAP-C02-Fangfrage: „Warum blockiert die SCP den Org-Master nicht?“ – weil sie es konstruktionsbedingt nicht kann).

   Kopieren

   resource "aws_organizations_policy" "allowed_regions" {
     name        = "certlabpro-sap-c02-allowed-regions"
     description = "Deny ec2/rds/lambda outside the allowed regions."
     type        = "SERVICE_CONTROL_POLICY"
   
     content = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Sid    = "DenyNonAllowedRegions"
         Effect = "Deny"
         NotAction = [
           "iam:*",
           "organizations:*",
           "cloudfront:*",
           "route53:*",
           "support:*",
           "sts:*",
           "waf:*",
         ]
         Resource = "*"
         Condition = {
           StringNotEquals = {
             "aws:RequestedRegion" = ["us-east-1", "us-west-2"]
           }
         }
       }]
     })
   }
   
   resource "aws_organizations_policy_attachment" "production" {
     policy_id = aws_organizations_policy.allowed_regions.id
     target_id = aws_organizations_organizational_unit.production.id
   }
   
   resource "aws_organizations_policy_attachment" "non_production" {
     policy_id = aws_organizations_policy.allowed_regions.id
     target_id = aws_organizations_organizational_unit.non_production.id
   }

4. 4.Eine kontoübergreifende IAM-Rolle mit einer MFA-bedingten Vertrauensrichtlinie erstellen

   Ressourcen:

   • AWS IAM

   Kontoübergreifendes IAM ist das SAP-C02-Shared-Services-Primitiv. Das Muster: Ein Workload-Konto erstellt eine Rolle mit einer Vertrauensrichtlinie, die das Shared-Services-Konto als vertrauenswürdiges Principal benennt; Personen oder Dienste im Shared-Services-Konto übernehmen (sts:AssumeRole) die Rolle im Workload-Konto, um ihre Aufgaben zu erledigen. So handhabt jede SAP-C02-Referenzarchitektur zentrale Observability, Auditierung, Bereitstellung und Data-Platform-as-a-Service.

   Wir schließen eine MFA-Bedingung (aws:MultiFactorAuthPresent = true) ein – die Prüfung testet dies als Unterschied zwischen einer sicheren und einer lediglich funktionalen Vertrauensrichtlinie. Die Bedingung ExternalId ist der zweite Teil der Deputy-Problem-Verteidigung – empfohlen für den Zugriff Dritter, aber auch häufig bei internen kontoübergreifenden Zugriffen zu finden.

   Die Inline-Berechtigungsrichtlinie gewährt der angenommenen Rolle Lesezugriff auf das, was der Workload tun muss; für das Lab gewähren wir schreibgeschützten Zugriff auf den Audit-Log-Bucket, den wir in Schritt 5 erstellen werden. In der Produktion würden Sie dies weiter einschränken.

   Kopieren

   resource "aws_iam_role" "shared_services_reader" {
     name = "certlabpro-sap-c02-shared-services-reader"
   
     assume_role_policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Effect = "Allow"
         Principal = {
           AWS = "arn:aws:iam::${local.shared_services_account_id}:root"
         }
         Action = "sts:AssumeRole"
         Condition = {
           Bool = {
             "aws:MultiFactorAuthPresent" = "true"
           }
           StringEquals = {
             "sts:ExternalId" = "certlabpro-sap-c02-external-id"
           }
         }
       }]
     })
   
     max_session_duration = 3600
   }
   
   # The reader-policy is wired in Step 5 once the audit bucket exists.

5. 5.CloudTrail organisationsweit in einen zentralisierten Audit-Bucket einbinden

   Ressourcen:

   • AWS CloudTrail
   • Amazon S3

   Der Höhepunkt jeder SAP-C02-Multi-Account-Governance-Story ist der Organisations-Trail – ein CloudTrail-Trail, der im Verwaltungskonto konfiguriert ist und Management-Ereignisse über jedes Mitgliedskonto in der Organisation erfasst. SAP-C02 testet dies gegen das Anti-Pattern ein Trail pro Konto (operativ laut, audit-unvollständig, teurer).

   Der S3-Bucket benötigt eine spezifische Bucket-Richtlinie, die CloudTrail die s3:PutObject-Berechtigung mit den richtigen Pfadkonventionen gewährt – cloudtrail.amazonaws.com als Service-Principal, der aws:SourceArn passend zum Trail. SAP-C02-Fragen, warum CloudTrail nicht in einen zentralisierten Bucket schreiben kann, weisen fast immer auf diese Richtlinie hin.

   Mit dem Trail werden alle API-Aufrufe über jedes Konto in der Organisation in diesem Bucket gespeichert. Die IAM-Rolle aus Schritt 4 gewährt dem Shared-Services-Konto Lesezugriff auf den Bucket – was bedeutet, dass ein zentralisiertes Audit-Team die Aktivitäten in der gesamten Organisation überprüfen kann, ohne jemals Zugriff auf einzelne Mitgliedskonten zu benötigen. Das ist die SAP-C02-Unternehmensarchitektur in fünf Blöcken.

   Kopieren

   resource "aws_s3_bucket" "audit_logs" {
     bucket_prefix = "certlabpro-sap-c02-audit-"
   }
   
   resource "aws_s3_bucket_public_access_block" "audit_logs" {
     bucket = aws_s3_bucket.audit_logs.id
   
     block_public_acls       = true
     block_public_policy     = true
     ignore_public_acls      = true
     restrict_public_buckets = true
   }
   
   resource "aws_s3_bucket_versioning" "audit_logs" {
     bucket = aws_s3_bucket.audit_logs.id
     versioning_configuration {
       status = "Enabled"
     }
   }
   
   resource "aws_s3_bucket_policy" "audit_logs_cloudtrail" {
     bucket = aws_s3_bucket.audit_logs.id
   
     policy = jsonencode({
       Version = "2012-10-17"
       Statement = [
         {
           Sid       = "AWSCloudTrailAclCheck"
           Effect    = "Allow"
           Principal = { Service = "cloudtrail.amazonaws.com" }
           Action    = "s3:GetBucketAcl"
           Resource  = aws_s3_bucket.audit_logs.arn
         },
         {
           Sid       = "AWSCloudTrailWrite"
           Effect    = "Allow"
           Principal = { Service = "cloudtrail.amazonaws.com" }
           Action    = "s3:PutObject"
           Resource  = "${aws_s3_bucket.audit_logs.arn}/AWSLogs/*"
           Condition = {
             StringEquals = {
               "s3:x-amz-acl" = "bucket-owner-full-control"
             }
           }
         },
       ]
     })
   }
   
   resource "aws_cloudtrail" "org_trail" {
     name                          = "certlabpro-sap-c02-org-trail"
     s3_bucket_name                = aws_s3_bucket.audit_logs.bucket
     is_multi_region_trail         = true
     is_organization_trail         = true
     include_global_service_events = true
     enable_log_file_validation    = true
   
     depends_on = [
       aws_s3_bucket_policy.audit_logs_cloudtrail,
       aws_organizations_organization.main,
     ]
   }
   
   # Cross-account IAM permissions (continued from Step 4): the role we
   # created earlier now gets read access to the audit bucket so a
   # shared-services audit team can query CloudTrail across the org.
   resource "aws_iam_role_policy" "shared_services_audit_read" {
     name = "read-audit-logs"
     role = aws_iam_role.shared_services_reader.id
   
     policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Effect   = "Allow"
         Action   = ["s3:GetObject", "s3:ListBucket"]
         Resource = [aws_s3_bucket.audit_logs.arn, "${aws_s3_bucket.audit_logs.arn}/*"]
       }]
     })
   }

Bereinigung