S3-Bucket-Konfiguration und -Zugriff mit Snyk & Solvo absichern

Solvo befähigt Entwickler und DevOps-Ingenieure, ihre Cloud-Infrastruktur mit minimalen Berechtigungen schnell und skalierbar zu betreiben. In diesem Artikel zeigen wir einen Workflow, der Solvos automatisierte Plattform mit Snyk Infrastructure as Code (Snyk IaC) kombiniert, um den Zugriff einer Lambda-Funktion auf einen AWS-S3-Bucket individuell und sicher einzurichten. Dieser Blogbeitrag wurde ursprünglich auf der Solvo-Website veröffentlicht.

Immer mehr Unternehmen setzen bei der Verwaltung ihrer Cloud-Ressourcenkonfigurationen auf das Infrastructure-as-Code-Modell.

Wenn Sie Ihre Infrastruktur als Code konfigurieren, profitieren Sie von einer besseren Versions- und Quellcodeverwaltung. So lassen sich Konfigurationen leichter nachverfolgen und von einer Umgebung in eine andere übertragen. Besonders praktisch ist dieser Ansatz, wenn Sie AWS-S3-Buckets bereitstellen, etwa zum Speichern Ihres Codes oder anderer nützlicher Daten. Als Cloud-Ressourcen lassen sich diese S3-Buckets problemlos mit dem restlichen Team teilen.

Doch manchmal werden diese S3-Buckets ein bisschen _zu_ leicht geteilt. Wenn es schnell gehen muss, denken Entwickler zuletzt daran, eine sichere IAM-Richtlinie für eine Cloud-Ressource (S3, Lambda, EC2 oder eine andere) zu verfassen. Im Interesse von Tempo und Komfort kommt es daher häufig vor, dass ein Entwickler den Bucket mit übermäßig großzügigen Sicherheitsrichtlinien konfiguriert und so dessen Inhalte dem Risiko einer Offenlegung aussetzt.

Sehen wir uns einige richtlinienbezogene Sicherheitsrisiken an und wie wir sie vermeiden können.

Beispiel für eine fehlerhaft konfigurierte Lambda-Funktion

Unten sehen Sie eine Terraform-Konfiguration, die eine AWS-Lambda-Funktion einrichtet, welche ein Bild in einen S3-Bucket hochlädt. Außerdem sehen Sie hier den Code für die IAM-Rolle und die Sicherheitsrichtlinie.

Welche Details können wir aus dieser Konfiguration ableiten, die uns etwas über ihren Inhalt und ihr Sicherheitsniveau verraten?

1```
2# create function 
3resource "aws_lambda_function" "Lambda_function" { 
4    s3_bucket = "my-bucket" 
5    s3_key = "my-key.zip" 
6    function_name = "my-test-function" 
7    role = aws_iam_role.lambda_iam_role.arn 
8    handler = "index.handler" 
9    runtime = "nodejs12.x" 
10    memory_size = 1024 
11    timeout = 900
12}
13
14# create role 
15resource "aws_iam_role" "Lambda_iam_role" {
16    name = "my-lambda-role" 
17    assume_role_policy = <<EOF
18{
19    "Version": "2012-10-17", 
20    "Statement": [
21        {
22            "Action": "sts:AssumeRole", 
23            "Principal": {
24                "Service": "lambda.amazonaws.com" 
25            }, 
26            "Effect": "Allow", 
27            "Sid": ""
28        }
29    ]
30}
31EOF
32}
33
34# create policy 
35resource "aws_iam_role_policy" "Lambda_iam_policy" { 
36    name = "my-lambda-policy" 
37    role = aws_iam_role.Lambda_iam_role.id
38    policy = <<EOF
39{
40    "Version": "2012-10-17", 
41    "Statement": [
42        {
43            "Effect": "Allow", 
44            "Action": [
45                "logs:CreateLogGroup",
46                "logs:CreateLogStream", 
47                "logs:PutLogEvents"
48            ],
49            "Resource": "*"
50        },
51        {
52            "Effect": "Allow", 
53            "Action": "*",
54            "Resource": "*"
55        }
56    ]
57}
58EOF

In unserer Anwendung ist die Lambda-Funktion so geschrieben, dass sie Hundebilder in einen S3-Bucket hochlädt. Sie hat dafür Berechtigungen sowie für weitere Aktionen wie Put, Get, Delete, Create und List. Und noch für viele weitere Aktionen, wenn wir alle anderen Services neben S3 berücksichtigen.

Der Grund dafür steht in den Zeilen 52–54. Damit erlauben wir effektiv alle Aktionen für alle Ressourcen. Das entspricht Admin-Berechtigungen.

Das ist viel zu großzügig. Hier sollte nur die Aktion „put“ erlaubt sein, denn alle anderen Berechtigungen sind überflüssig und könnten zu Datenlecks oder Datenbeschädigung führen oder zur Aufklärung unserer Ressourcen missbraucht werden.

Wenn Sie sich mit Terraform und AWS IAM gut auskennen und nur diese eine Konfiguration prüfen müssten, wäre das Problem vielleicht leicht zu erkennen. In der Regel gibt es jedoch deutlich mehr Terraform-Konfigurationen, und es ist schwierig, mit allen Konfigurationsdetails Schritt zu halten. Daher ist es unwahrscheinlich, dass ein Entwickler oder Mitglied des Security-Teams diese riskante Richtlinie entdeckt, die tief in einer Reihe von Terraform-Modulen verborgen ist.

Zum Glück gibt es neue Tools, die das Auffinden und Beheben solcher Probleme erheblich erleichtern und es ermöglichen, Sicherheitsaufgaben auf alle Engineering-Teams auszuweiten, die IaC einsetzen.

Unsichere Konfigurationen aufspüren

Snyk Infrastructure as Code (IaC) ist ein IaC-Testtool, das Terraform-, Kubernetes- und AWS-CloudFormation-Konfigurationen scannt und riskante Richtlinien für Services in AWS, Azure und GCP erkennt. Das kann etwas so Einfaches sein wie ein Sternchen, das eine Richtlinie – wie in unserem Beispiel oben – viel zu großzügig macht. Oder eine „write“-Berechtigung, obwohl nur „read“ erforderlich ist.

Durch kontinuierliche, automatisierte statische Tests kann Snyk IaC Terraform in einem Umfang scannen, der Unternehmen bei der Verwaltung ihrer Infrastruktur als Code unterstützt. Findet der Scan eine riskante Konfiguration, hilft Snyk dem Entwickler, sie zu beheben. Noch besser: Solvo lässt sich mit Snyk IaC einsetzen, um automatisch eine sichere Richtlinie zu erstellen, die das potenzielle Risiko mindert.

Sehen wir uns an, wie das in der Praxis funktioniert.

Für den Scan können wir die Snyk CLI verwenden und für unsere Konfiguration snyk iac test ausführen:

Der Scan hat eine Fehlkonfiguration in der Richtlinie gefunden: Sie verwendet ein „*“ und ist dadurch viel zu großzügig, da sie alles erlaubt.

Snyk IaC informiert Sie über die potenziellen Risiken dieser Konfiguration und gibt allgemeine Hinweise zur Behebung des Problems. Solvo geht noch einen Schritt weiter und erstellt automatisch eine IAM-Konfiguration mit den minimal erforderlichen Berechtigungen, die auf Ihre Umgebung zugeschnitten ist. Gemeinsam helfen Ihnen die Tools, Probleme bereits beim Schreiben des Codes zu finden und zu beheben, die erforderlichen Korrekturen schnell vorzunehmen und die Sicherheit vor dem Deployment sicherzustellen.

Jetzt sehen wir, dass unsere Richtlinie nur „PutObject“ erlaubt. Unsere Hundefotos sind also sicher.

Nachdem Solvo die Richtlinie durchgesetzt hat, scannen wir die Terraform-Datei erneut. Snyk IaC zeigt, dass alle administrativen Berechtigungen entfernt wurden:

Integrationen kombinieren und mehr Bereiche abdecken

Mithilfe von Snyk-IaC-Scans können Unternehmen riskante Richtlinien in ihrer Infrastruktur als Code proaktiv erkennen und beheben – ob in Terraform, Kubernetes oder CloudFormation. In Kombination mit Solvo lassen sich sichere Richtlinien anstelle der riskanten erstellen. So können Unternehmen Fehlkonfigurationen schnell beheben und die Sicherheit verbessern, ohne zusätzliche Ressourcen oder Fachkenntnisse einsetzen zu müssen.

Weitere Informationen dazu, wie Solvo dazu beitragen kann, Risiken für Ihre Cloud-Infrastruktur automatisch zu verringern, finden Sie auf der Solvo-Website. Starten Sie dort oder fordern Sie eine kostenlose Demo an. Wenn Sie Snyk IaC noch nicht ausprobiert haben, können Sie es kostenlos nutzen.

David Hendri ist Mitgründer und CTO von Solvo.

Lauren Place ist Product Marketing Manager bei Snyk.