Ausgesperrt! – Vorsicht bei S3 Berechtigung per Bucket policy

AWS S3 bietet viele Möglichkeiten, den Zugriff zu regeln

S3 Buckets bieten flexible Möglichkeiten, Daten abzulegen und den Zugriff auf diese Daten zu beschränken. Dies für den öffentlichen (Internet) und internen Gebrauch.

Über die normalen Berechtigungen (Permissions) lassen sich Berechtigungen ganz grob für „list“ (Anzeigen), „upload/delete“ (Schreiben), „view permissions“ (Berechtigungen sehen) sowie „edit permission“ (Berechtigungen schreiben) einstellen. Das reicht für viele Fälle, manchmal braucht man aber eine feinere Berechtigungsverwaltung, der bucket policy. Die ist aber nicht ohne Fallstricke…

Eine Bucket Policy ist nicht ohne Fallstricke

Nimmt man das harmlos klingende Beispiel „Zugriff auf einen VPC Endpunkt beschränken„, so bekommt man folgende Beispiel Policy:

{
   "Version": "2012-10-17",
   "Id": "Policy1415115909152",
   "Statement": [
     {
       "Sid": "Access-to-specific-VPCE-only",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::examplebucket",
                    "arn:aws:s3:::examplebucket/*"],
       "Condition": {
         "StringNotEquals": {
           "aws:sourceVpce": "vpce-1a2b3c4d"
         }
       },
       "Principal": "*"
     }
   ]
}

Die Werte sind in der Dokomentation gut beschrieben, hier will ich nur auf das gefährliche Element hinweisen:

Mit dem „Effect“ : „Deny“ wird der Zugriff explizit verboten. Zusammen mit der Bedingung (Condition) Zeichenkette ungleich (StringNotEquals) schließt diese Policy alle Zugriffe aus, die diese Bedingung nicht erfüllen. Und das schließt den AWS Root Account mit ein!

Macht man also bei der Erstellung so einer Policy den kleinsten Fehler, so kann man über die AWS Console nicht mehr auf den S3 Bucket zugreifen.

Zugriff wiederherstellen

Wie man dennoch wieder an die Daten herankommt, verraten wir hier:

  1. Kommandozeilenzugriff über die AWS CLI einrichten.
  2. Einen Access Key für root einrichten.
  3. Eine Policy, die den Zugriff erlaubt, wie im „Allow“ Beispiel als Datei „policy.json“ speichern
  4. Diese Policy einspielen
    1. aws s3api put-bucket-policy –bucket MeinBucketName –policy file://policy.json
  5. Jetzt sollte man über die Console wieder zugreifen können

„Allow“ ist sicherer

Sicherer ist es, hier mit „Allow“ zu arbeiten:

{
 "Version": "2012-10-17",
 "Id": "S3PolicyId1",
 "Statement": [
 {
 "Sid": "IPAllow",
 "Effect": "Allow",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::gg-blogartikel",
 "Condition": {
     "IpAddress": {
       "aws:SourceIp": "42.55.47.11/32"
     }
  }
 }
 ]
}

Mit dieser Policy wäre der Inhalt des Buckets auf die fiktive IP Adresse 42.55.47.11/32 beschränkt. Alle anderen Zugriff bekommen eine „Verboten“ Meldung beim Zugriff:

accessdenied

Dieses Allow verbietet aber eben nicht den Zugriff über die AWS Console.

Eine Besonderheit ist noch bei dem Feld „Ressource“ zu beachten:

"arn:aws:s3:::gg-blogartikel"

Bezieht sich auf den gesamten Bucket. Will man sich auf alle Objekte im Bucket beziehen nimmt man:

"arn:aws:s3:::gg-blogartikel/*"

Zugriff auf den Bucket und alle Unterobjekte gibt man mit:

"Resource": ["arn:aws:s3:::gg-blogartikel", "arn:aws:s3:::gg-blogartikel/*"],

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.