Zehn Fallstricke, auf die Sie bei AWS IAM achten sollten

In unserem letzten Blog haben wir kurz die Sicherheitsherausforderungen angesprochen, die bei der Arbeit mit Terraform auf AWS auftreten können. In diesem Blog möchten wir etwas tiefer in das Thema IAM eintauchen und 10 Fallstricke erläutern, auf die Sie bei der Konfiguration von AWS IAM achten sollten. Beginnen wir unsere Reise und gehen sie der Reihe nach an.

1. Implizit leugnet

Für diesen ersten Fallstrick ist es wichtig, die Logik der Richtlinienbewertung zu verstehen.
Angenommen, wir möchten einer Rolle Zugriff auf alles außer IAM gewähren. Es gibt im Wesentlichen zwei Möglichkeiten, dies zu konfigurieren: implizit und explizit.

Werfen Sie einen Blick auf die folgenden beiden Policen:

{
  "Version": "2012-10-17",
  "Sid": "ImplicitDeny",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": "iam:*",
      "Resource": "*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Sid": "ExplicitDeny",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "iam:*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Beide Richtlinien gewähren Zugriff auf alles außer IAM. Der Unterschied besteht darin, wie sie es tun. Die erste Richtlinie "verweigert" IAM implizit, indem sie es nicht in die erlaubten Anweisungen aufnimmt. In der zweiten Richtlinie werden alle IAM-Aktionen explizit verweigert. Dieser Unterschied ist entscheidend.

Für sich genommen wäre das Ergebnis jeder Richtlinie dasselbe. Aber was passiert, wenn wir eine andere Richtlinie (oder Anweisung) an dieselbe Rolle anhängen, die IAM erlaubt? Sagen wir, etwa so:

{
  "Version": "2012-10-17",
  "Sid": "AllowIam",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}

Leider haben wir die erste Richtlinie umgangen: IAM ist nun auch in der Liste der erlaubten Aktionen enthalten. Die zweite Richtlinie hat immer noch den gewünschten Effekt. Das liegt daran, dass 1) ein Verweigern ein Zulassen übertrumpft und 2) IAM zuerst Verweigern auswertet.

Das bedeutet, dass es sicherer ist, ein explizites Deny zu verwenden als ein implizites, wenn Sie einen unbeabsichtigten Zugriff verhindern wollen. Wie es im Zen von Python heißt: "Explizit ist besser als implizit". Wenden Sie das auch auf Ihre AWS-Richtlinien an!

Weitere Informationen zur Richtlinienbewertung finden Sie in den AWS-Dokumenten zu diesem Thema.

2. Die additive Ressourcenpolitik

Der nächste Fallstrick hängt auch mit dem Verständnis der Logik der Politikbewertung zusammen.
Ressourcenrichtlinien können verschiedene Formen annehmen. Die S3-Bucket-Richtlinie ist das bekannteste Beispiel für eine Ressourcenrichtlinie. Andere Beispiele sind KMS-Schlüsselrichtlinien oder Lambda-Funktionsaufrufberechtigungen.

Ressourcenrichtlinien sind additiv - das heißt, sie können zusätzlich zu dem, was Sie in IAM definieren, Zugriff gewähren. Wir sehen oft Ressourcenrichtlinien, die den Zugriff zu weit gefasst gewähren.

Eine Rolle kann nicht auf eine Ressource zugreifen, wenn Sie sie in IAM nicht zulassen. Die Probleme entstehen, wenn Sie den Zugriff außerhalb des AWS-Kontos, in dem Sie arbeiten und testen, nicht berücksichtigen.

Verschlüsselung für alle

Betrachten Sie zum Beispiel die folgende Schlüsselrichtlinie:

{
  "Version": "2012-10-17",
  "Sid": "EnableKeyManagement",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal" : { "AWS" : "*" },
      "Action": "kms:*",
      "Resource": "*"
    }
  ]
}

Es gibt drei *'s in dieser Richtlinie, von denen wir zwei nicht wirklich ein unmittelbares Problem haben. Fangen wir von unten an: Da die Ressourcenrichtlinie nur an eine Ressource gebunden ist, ist * akzeptabel. Selbst wenn man sie ausblendet, gilt sie nur für die Ressource, an die sie gebunden ist.

Was die Aktion angeht, so ist kms:* hier nicht wirklich ein Problem, da diese Richtlinie die Schlüsselverwaltung erleichtern soll. Um sie ein wenig zu verbessern, könnten Sie sie so einschränken, dass die verwaltende Partei nicht in der Lage ist, mit dem Schlüssel zu verschlüsseln/entschlüsseln, ohne eine Richtlinienänderung vorzunehmen.

Die letzte * ist der Punkt, an dem das Problem liegt. Diese Richtlinie gewährt jedem und allem, der ein AWS-Konto besitzt, Zugang. Jeder, der Ihre Schlüssel-ID kennt oder voraussagen kann, kann damit tun, was er will. Im besten Fall entstehen Ihnen dadurch hohe API-Kosten, im schlimmsten Fall ein kompletter Denial-of-Service und möglicherweise ein Datenleck.

Da S3 für viele eine günstige Speicherlösung ist, sehen wir viele Verstöße, die zu offen konfigurierte S3-Buckets betreffen. Da hilft es auch nicht, dass es zusätzlich zu IAM Bucket-Richtlinien, Bucket-ACLs, öffentliche Zugriffsblöcke und S3-Zugriffspunkte gibt. Wie auch immer, das ist ein Thema für einen anderen Deep Dive.

3. Inline-Richtlinien und benannte Richtlinien

Wenn Sie eine Rolle, einen Benutzer oder eine Gruppe erstellen, haben Sie die Wahl, Inline-Richtlinien oder benannte Richtlinien anzuhängen(siehe auch). AWS empfiehlt, dass Sie nach Möglichkeit benannte Richtlinien verwenden, und wir sind derselben Meinung.

Benannte Richtlinien haben mehrere Vorteile. Sie bieten Wiederverwendbarkeit, zentrale Änderungsverwaltung, Versionierung und Rollback. Die Meinung von AWS zu diesem Thema finden Sie in den Dokumentationen.

Dennoch ist es nicht unbedingt ein Problem, Inline-Richtlinien zu verwenden - insbesondere bei den Eins-zu-Eins-Beziehungen, die Lambda-Funktionen mit Rollen haben.

Das Problem dabei ist, dass Sie diese beiden Dinge kombinieren können, um ein komplexes Durcheinander für sich selbst zu schaffen. Tun Sie sich und Ihren Teamkollegen einen Gefallen und seien Sie konsequent. Verwenden Sie benannte Richtlinien, es sei denn, sie passen nicht zu Ihrem Anwendungsfall, und kombinieren Sie die beiden nicht.

Wenn Sie sich bereits im Wald verirrt haben, ist eines der Tools, das Ihnen helfen kann zu verstehen, was passiert, der AWS-Richtliniensimulator (AWS-Konto erforderlich). Allerdings spielt er nicht mit Service Control Policies (SCPs) zusammen.

4. Umfangreiche Rollenverkettung

IAM-Rollen sind temporäre Identitäten in AWS. Sie können von denjenigen übernommen werden, die sie benötigen und die Erlaubnis haben, sie zu verwenden. Benutzer, Gruppen, Services und Anwendungen können diese Rollen auf verschiedene Weise nutzen. Konzentrieren wir uns zunächst auf Ihre Benutzer. Sie können eine Rolle übernehmen, wenn: 1) der Benutzer sts:AssumeRole mit dieser Rolle in IAM aufrufen kann und 2) die Vertrauensbeziehung der Rolle dies erlaubt.

Beginnen wir mit der Richtlinie "Rolle übernehmen". Mit dieser Richtlinie kann ein Benutzer eine vordefinierte Rolle übernehmen. Nehmen Sie das folgende Beispiel:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123412341234:role/*"
    }
  ]
}

Hinweis: 123412341234 ist Ihre normale AWS AccountID. Diese Richtlinie erlaubt es einem Benutzer, jede Rolle für das gegebene AWS-Konto mit der definierten AccountID zu übernehmen.

Als nächstes folgt die Vertrauensbeziehung, die in einer Vertrauensrichtlinie definiert ist. Eine IAM-Rolle definiert, wer diese Rolle übernehmen kann, indem sie diese Vertrauensrichtlinie enthält. Werfen Sie einen Blick auf das folgende Beispiel:

 ...Role definitions for "example-role"...
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
            {
              "Effect": "Allow",
              "Principal": {
                "AWS": "arn:aws:iam::123412341234:role/dev-engineer"
              },
              "Action": "sts:AssumeRole",
              "Condition": {}
            }
          ]
        }
  }

Hier sagen wir, dass jeder mit der Rolle dev-engineer in dem Konto mit der ID 123412341234 die example-role übernehmen darf, an die diese Vertrauensrichtlinie angehängt ist.

Sie können das obige Beispiel leicht erweitern, indem Sie eine weitere Rollenübernahme von diesem example-role erlauben. Vielleicht gibt es noch andere Rollen, die dev-engineer oder example-role übernehmen können (siehe auch: Rollenverkettung).

Durch die Verkettung dieser AssumeRole-Aufrufe ist es möglich, dass dev-engineer nun plötzlich mehr tun kann, als wir beabsichtigt haben. Wir haben verschiedene Beispiele gesehen, in denen ein Unternehmen (externen) Ingenieuren erlaubte, zunächst eine Art Nur-Ansichts-Rolle zu verwenden, um einen Blick auf einige der Konfigurationen in AWS zu werfen, und danach eine Rolle anzunehmen, die klassifizierte Geheimnisse sehen konnte. Dies geschah, weil eine andere technische Rolle diese ebenfalls einsehen musste, wobei die Nur-Ansichts-Rolle als Zwischenschritt verwendet wurde:

Umgang mit Rollenverkettungen

1. Überprüfen Sie immer die mit einer Rolle verknüpften Vertrauensrichtlinien. Stellen Sie sicher, dass Sie mächtigen Rollen - d.h. mit mächtigen Richtlinien verknüpft - keine übermäßig weit gefasste Vertrauensrichtlinie hinzufügen. Verwenden Sie die Bedingungsklausel des AssumeRole-Richtliniendokuments, wie in diesem Blogbeitrag von AWS erläutert.
2. Prüfen Sie immer, ob Sie den Principals eine korrekte Assume Role Policy zugewiesen haben, wenn die AWS IAM-Konfiguration unter Ihrer Kontrolle ist.
3. Nutzen Sie AWS SSO. AWS SSO ist in der Lage, alle Rollen bereitzustellen, die Ihre Benutzer im gesamten Unternehmen benötigen. Benutzer melden sich bei AWS SSO an und wechseln in nur einem Schritt zu ihrer Zielrolle. Damit entfällt praktisch die Notwendigkeit, Rollen zu verketten, und die Einrichtung wird erheblich vereinfacht. Zufriedene Benutzer, zufriedene Sie.

Hinweis: Die Rollenübernahme war lange Zeit schwer nachzuvollziehen. Dies ist nun viel einfacher geworden, wenn Sie sich die CloudTrail-Protokolle mit Hilfe von ansehen. Weitere Informationen finden Sie in diesem AWS-Blogbeitrag.

5. /Wurzel in Trust-Policy-Dokumenten

Erinnern Sie sich an die Aussage "AWS": "arn:aws:iam::123412341234:role/dev-engineer" in der Treuhandrichtlinie in Abschnitt 4? Wenn dort stattdessen "AWS": "arn:aws:iam::123412341234:root" stehen würde, wäre das ein Warnsignal. Wenn Sie dies angeben, verlassen Sie sich vollständig auf die IAM-Einrichtung des Kontos 123412341234 - tun Sie dies nur, wenn Sie ihr voll und ganz vertrauen. Das sollte fast nie der Fall sein.

Die obige Principal-Anweisung impliziert im Grunde, dass die Rolle, der die Vertrauensrichtlinie zugeordnet ist, von jedem authentifizierten und autorisierten Principal im 123412341234 Konto übernommen werden kann. Wenn Sie dies also tun, stellen Sie sicher, dass Sie die volle Kontrolle über dieses Konto haben und dass die Rolle nur begrenzte Rechte hat.

6. Was können Sie mit Ihrem Service tun?

Ein oft übersehener Fallstrick ist der Umfang der Richtlinien, die mit den Dienstrollen verschiedener Dienste verbunden sind. Wenn ein Benutzer nicht auf die Daten in Bereich A zugreifen kann, wohl aber auf Sagemaker, dann kann eine geschickte Nutzung von Sagemaker dazu führen, dass der Inhalt von Bereich A an den Benutzer geleitet wird.

Eine der interessanten Sagemaker-Richtlinien , auf die AWS in seinen Dokumenten verweist, ist diese:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:PassRole",
                "sagemaker:DescribeEndpointConfig",
                "sagemaker:DescribeModel",
                "sagemaker:InvokeEndpoint",
                "sagemaker:ListTags",
                "sagemaker:DescribeEndpoint",
                "sagemaker:CreateModel",
                "sagemaker:CreateEndpointConfig",
                "sagemaker:CreateEndpoint",
                "sagemaker:DeleteModel",
                "sagemaker:DeleteEndpointConfig",
                "sagemaker:DeleteEndpoint",
                "cloudwatch:PutMetricData",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:CreateLogGroup",
                "logs:DescribeLogStreams",
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket",
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage"
            ],
            "Resource": "*"
        }
    ]
}

Es gibt mehrere potenziell problematische Anweisungen, insbesondere in Verbindung mit dem Teil Resource: "*". Im Wesentlichen erlaubt diese Richtlinie die Übergabe einer beliebigen Rolle (möglicherweise einer sehr privilegierten) und erlaubt die Eingabe von Objekten und deren Abruf aus einem beliebigen S3-Bucket. Sie erlaubt es auch, Protokolle überall zu veröffentlichen, alle Sagemaker-Modelle zu löschen usw.

Dies können Sie von einer verwalteten Richtlinie erwarten, da diese eher auf Kompatibilität als auf Sicherheit ausgelegt sind. Berücksichtigen Sie dies bei der Auswahl oder dem Kopieren von leicht verfügbaren Richtlinien.

In ähnlicher Weise kann QuickSight den Lesern vertrauliche Inhalte anbieten. Daher ist es wichtig, diese Dienste so zu konfigurieren, dass nur die Informationen angezeigt werden, für die die Benutzer berechtigt sind.

Ein weiteres Beispiel ist EC2: Wenn Benutzer Aktionen auf einer EC2-Instanz ausführen können und die Instanz mit ihrer Rolle Zugriff auf privilegierte Daten auf S3 hat, dann können Benutzer diese EC2-Instanz für den Zugriff auf diese Daten verwenden.

Wenn Sie mit der Privilegienerweiterung spielen möchten, sollten Sie sich IAM-Vulnerable ansehen. Äußerst empfehlenswert!

7. Der Trugschluss "mehr Kontrolle durch feinkörnige Kontrolle".

Es gibt ein deutsches Sprichwort, das mehr oder weniger besagt: Wer die Wahl hat, hat den Schmerz ("Wer die Wahl hat, hat die Qual"). IAM ist phantastisch, weil Sie damit einen feinkörnigen Zugriff konfigurieren können. Hier wird es auch schmerzhaft, und die Komplexität in diesem Bereich ist einer der Gründe, warum mehrere AWS-Konten eine bewährte Praxis sind.

Manchmal müssen Sie sich ein wenig ins Zeug legen, um die richtige Richtlinie zu finden und gleichzeitig alle anderen Richtlinien zu berücksichtigen, die für dasselbe Unternehmen gelten. Es kann schwierig sein, sich einen Überblick zu verschaffen.
Um Ihnen dabei zu helfen, finden Sie hier einige Hinweise:

• Strukturieren Sie Ihre Richtlinien. Wenn Sie z.B. Berechtigungen für eine bestimmte Funktion erteilen müssen, geben Sie ihr einen passenden Namen und fügen Sie alles, was für diese Funktion erforderlich ist, in diese Richtlinie ein. Widerstehen Sie der Versuchung, andere Richtlinien zu bearbeiten, nur weil Sie "dort bereits einige s3-Berechtigungen drin haben". Versuchen Sie, diese Logik auch auf die Anweisungen innerhalb Ihrer Richtlinie anzuwenden.
• Manchmal ist es einfacher, ein neues AWS-Konto hinzuzufügen, als Ihre Richtlinien genau richtig zu gestalten. AWS-Konten bilden eine natürliche Grenze und setzen den Reset-Knopf für die Frage, wer auf was zugreifen darf, innerhalb Ihres Kontos. Wenn Sie entscheiden, wann Sie ein separates AWS-Konto benötigen, denken Sie an den Explosionsradius. Was könnte schief gehen, wenn etwas verletzt wird? Wie wird sich das auf andere Ressourcen in Ihrem Konto auswirken?

8. IAM Service Grenzen

Früher oder später stoßen Sie wahrscheinlich an die Grenzen der IAM-Dienste. Sie schreiben eine Richtlinie, die zu groß ist, fügen einer Rolle oder Gruppe zu viele Richtlinien zu oder fügen einer Organisationseinheit zu viele SCPs zu. Selbst wenn Ihr Terraform-Plan oder Ihr CloudFormation-Änderungssatz in Ordnung aussieht, können diese Grenzen Ihre Pipeline unterbrechen und Sie dazu veranlassen, Ihre Einrichtung zu überarbeiten.

Es ist sinnvoll, die AWS IAM- und STS-Grenzen hin und wieder zu überprüfen. Tun Sie dies insbesondere, wenn Sie mit SCPs arbeiten, da Probleme hier Ihr gesamtes Unternehmen stören könnten.

9. Attributbasierte Zugriffskontrolle (ABAC) und Tag-Richtlinien

ABAC ist ein umstrittenes Thema. AWS behauptet, dass es wichtig ist, um die Sicherheit skalierbar zu machen, aber AWS-Benutzer und Sicherheitsexperten argumentieren, dass dies große Mängel hat.

Einerseits erspart es Ihnen die ständige Aktualisierung Ihrer Richtlinien für geringste Rechte, wenn Sie neue Ressourcen und Dienste hinzufügen. Andererseits unterstützen nicht alle Ressourcen und Dienste das Tagging. Das macht sie in einigen Szenarien nutzlos.

Wir sind der Meinung, dass Sie sich nicht auf die Tag-basierte Autorisierung innerhalb eines AWS-Kontos verlassen sollten, aber es könnte für die Gewährung von Zugriff durch Rollenannahmen funktionieren.

Der Grund dafür ist, dass viele Ressourcen keinen feinkörnigen Zugriff auf der Basis von Tags unterstützen. Wenn Sie Ressourcen erstellen können, können Sie häufig auch Tags für sie festlegen. Wenn Sie Ressourcen erstellen können, können Sie wahrscheinlich auch Rollen und Richtlinien erstellen. Und seien wir mal ehrlich, das müssen Sie wahrscheinlich auch. Das Problem ist, dass dadurch die auf diesen Tags basierende Autorisierung innerhalb des Kontos, in dem Sie dazu in der Lage sind, hinfällig wird - sogar durch Erweiterung (über CI/CD).

Ähnlich verhält es sich, wenn Sie eine Rolle für die Erstellung von EC2-Instanzen mit bestimmten Tags erstellen möchten und dieselbe Anwendung nur EC2-Instanzen mit den besagten Tags beenden soll - viel Glück beim Erstellen einer Richtlinie, die dies effektiv einschränkt.

Andererseits funktioniert das Setzen von Tags für eine Gruppe und das Zulassen von Rollenübernahmen nur für Rollen, die dieselben Tags haben, ganz gut. Wenn das Ihr Anwendungsfall ist, sollten Sie das ABAC rocken.

10. Nicht zurückblicken

Okay, Sie haben einige Fehlkonfigurationen bemerkt. Oder vielleicht haben Sie das nicht und haben ein größeres Problem. Die Sache ist die: IAM ist sehr dynamisch. Daher müssen Sie eine angemessene Überwachung einrichten. Konkret wollen Sie das:

• Bewerten Sie risikoreiche Ereignisse (führen Sie eine Bedrohungsmodellierung durch, um zu wissen, um welche es sich handelt).
• Richten Sie AWS config ein, um Konfigurationen zu verfolgen. Glauben Sie uns, dass Sie in der Lage sein wollen, im Falle eines Vorfalls einen Zeitplan für mehrere Ressourcen zu erstellen. Und nein, das muss nicht unbedingt in Ihrer versionskontrollierten Infrastruktur als Code sein.
• Erstellen Sie einen unternehmensweiten AWS Access Analyzer. Auf diese Weise können Sie die externe Exposition auf S3-Buckets, Rollen, KMS-Schlüssel und Lambda-Ebenen im Auge behalten.

Was nun?

Puh, das ist eine Menge, die Sie verarbeiten müssen. Abgesehen von der Suche und Auswahl des AWS-Services, den Sie benötigen, ist IAM wahrscheinlich der komplexeste Teil von AWS. Halten Sie also die Logik für die Richtlinienbewertung griffbereit und denken Sie an die Struktur, die Sie in Ihrer IAM-Einrichtung wünschen. Erstellen Sie etwas Strukturiertes. Es ist ganz natürlich, dass Sie zu einer anderen Lösung oder Architektur wechseln, wenn sich Ihr Unternehmen oder Ihr Stack ändert, aber versuchen Sie nicht, von allem ein bisschen zu machen. Das würde nur zu einem Durcheinander führen. Legen Sie separate AWS-Konten an und lesen Sie auf jeden Fall ab und zu diesen Blog über IAM-Fallen.

Wenn Sie immer noch Probleme haben oder eine gründliche Bewertung Ihrer AWS-Einrichtung wünschen, zögern Sie nicht, uns zu kontaktieren!