☰

Erzwingen der Überwachung von AWS-Ressourcen

tag-icon • tag-icon amazon-web-services security monitoring infrastructure
Erzwingen der Überwachung von AWS-Ressourcen

Wir haben einige große AWS-Konten und mir wurde die Aufgabe übertragen, Richtlinien für die Überwachung von Ressourcen zu implementieren und sicherzustellen, dass die Überwachung für alle vorhandenen und zukünftigen Ressourcen eingerichtet ist.

Gibt es eine Möglichkeit, die Erstellung/Änderung von Ressourcen zu verhindern, indem Regeln auf der Grundlage von Ressourcenoptionen und/oder benutzerdefinierten Bedingungen aufgerufen werden? Lassen Sie beispielsweise nicht zu, dass eine RDS-Instanz erstellt wird, wenn die erweiterte Überwachung nicht aktiviert ist, oder lassen Sie nicht zu, dass eine EC2-Instanz ohne bestimmte CloudWatch-Alarme erstellt wird.

Ich habe mir Richtlinien/Leitplanken angesehen, aber sie scheinen nicht robust genug zu sein. Was verwenden andere Leute in diesem Szenario?

BEARBEITENIch habe mir AWS Config als mögliche Lösung angesehen, aber es scheint dort viele Einschränkungen zu geben. Ich kann beispielsweise RDS-Cluster prüfen, um zu sehen, ob für bestimmte Metriken Alarme erstellt wurden, aber für RDS-Instanzen kann ich das nicht tun.

Antwort1

Verhindern Sie die Ressourcenerstellung mit SCP

In einigen Fällen können Sie für diese Art von Anforderungen Service Control Policies verwenden, jedoch nur in Bezug auf die Eigenschaften der zu erstellenden Ressource. Soweit ich weiß, funktioniert es nicht, wenn Sie sagen: „Sie können keine EC2-Instanz erstellen, wenn kein CloudWatch-Alarm erstellt wurde.“

AWS verfügt über einige Beispiele für Service Control Policies aufdiese Seite, ich kopiere unten eines. Ich habe diese Technik verwendet, um beispielsweise die Erstellung einer EC2-Instanz zu verhindern, wenn sie nicht verschlüsselt ist, wenn das EBS-Volume nicht verschlüsselt ist, und die Erstellung von RDS zu verhindern, wenn der Speicher nicht verschlüsselt ist.

Beispiel-SCP von Amazon: Mit diesem SCP werden alle Instanzstarts abgelehnt, die nicht den Instanztyp t2.micro verwenden.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireMicroInstanceType",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals":{                 
          "ec2:InstanceType":"t2.micro"
        }
      }
    }
  ]
}

Automatische Behebung

Sie könnten eine automatische Behebung in Betracht ziehen, nachdem Ressourcen erstellt wurden. So etwas wie AWS Config kann jedes Mal benachrichtigt werden, wenn eine Ressource erstellt wird, und ein Lambda-Skript ausführen, mit dem Sie dann benutzerdefinierten Code ausführen können, um den Status zu erkennen und verwandte Ressourcen einzurichten. Auch dies ist benutzerdefiniert, aber wir haben dies in der Vergangenheit getan. Wenn beispielsweise ein S3-Bucket erstellt wird, haben wir Protokollierung und Versionierung aktiviert, sofern kein bestimmtes Tag vorhanden war.

Auf die gleiche Weise können Sie nicht konforme Ressourcen löschen, anstatt sie automatisch zu beheben.

Verhindern der Ressourcenerstellung mit IAM-Berechtigungen

Anstatt nicht konforme Ressourcen zu entfernen, könnten Sie die Berechtigungen für Benutzer einschränken, damit diese keine Ressourcen direkt erstellen können, und eine Art Selbstbedienungssystem einrichten, das Ressourcen für sie einrichtet und alle erforderlichen zugehörigen Ressourcen einrichtet. Ich habe das selbst noch nicht gemacht, daher kann ich nicht genau sagen, wie es geht.

Dies kann beispielsweise so einfach sein, dass Sie die Ausführung der von Ihnen bereitgestellten CloudFormation-Vorlagen unter einer Servicerolle zulassen, den Benutzern jedoch keine Berechtigungen zum direkten Erstellen der Ressourcen erteilen.

verwandte Informationen