Arbeiten mit AWS-Berechtigungsrichtlinien

Richtlinien und Berechtigungskontrollen

Die Zugriffsverwaltung ist ein wichtiger Bestandteil der Verwaltung Ihrer Arbeitslasten. Sie ist auch einer der Hauptbereiche, in denen die Fehlersuche problematisch sein kann. In AWS gibt es mehrere Möglichkeiten, den Zugriff auf die Plattform auf verschiedenen Ebenen zu kontrollieren. Diese Berechtigungsrichtlinien ermöglichen es, die Kontrolle über Anwendungen, Programme und Ressourcen zu optimieren, damit der tägliche Betrieb so reibungslos wie möglich verläuft. AWS bietet viele Optionen zur Erstellung sicherer Richtlinien auf seiner Plattform.

Die Entscheidung, welche Richtlinien und Berechtigungskontrollen für verschiedene Organisationen verwendet werden sollen, kann entmutigend erscheinen. Unternehmen verlassen sich bei der Zugriffsverwaltung auf AWS Identity and Access Management (IAM). Aber es gibt noch mehr Optionen, insbesondere für größere, komplexere Organisationen mit vielen Konten. Hier befassen wir uns mit den besten Anwendungsszenarien für die AWS-Zugriffsverwaltung, je nach den Bedürfnissen der verschiedenen Benutzer und Organisationen, ob klein oder groß. Außerdem gehen wir auf neue Entwicklungen und Anleitungen zur Beseitigung von Berechtigungsfehlern ein.

Identitäts- und Zugriffsmanagement (IAM)

AWS Identity Access Management ist ein Webservice, der den sicheren Zugriff von Benutzern oder Anwendungen auf AWS-Ressourcen und -Services ermöglicht. Er ermöglicht es Benutzern, zu kontrollieren und zu definieren, was Benutzer oder Anwendungen innerhalb eines Kontos tun dürfen, indem sie den Benutzer authentifizieren und autorisieren. Es schränkt auch ein, was Benutzer tun können. Innerhalb von IAM gibt es Benutzer und Rollen. Im Gegensatz zu einer Rolle kann ein Benutzer in Gruppen organisiert werden. Innerhalb von IAM werden diese Entitäten als Principals bezeichnet. Prinzipale können nur dann Aktionen durchführen, wenn sie dazu berechtigt sind.

IAM-Rollen sind nicht auf eine einzelne Person beschränkt, sie sind wie ein Hut, den jeder Benutzer oder jede Ressource tragen kann, wenn er/sie die Erlaubnis dazu hat, und sie können Ihnen eine vorübergehende "Superkraft" verleihen. Rollen erlauben Aktionen, die von AWS-Services ausgeführt werden, und Benutzer können eine Rolle übernehmen. Zum Beispiel kann ein AWS-Service vorübergehenden Zugriff anfordern, indem er eine Rolle annimmt. Die am häufigsten verwendeten Services sind Amazon Simple Storage Service (Amazon S3) Buckets, Amazon Elastic Compute Cloud (Amazon EC2), AWS Lambda und Amazon DynamoDB. Rollen werden entweder innerhalb der Webkonsole oder über ein Programm wie AWS CLI verwendet.

IAM-Richtlinien sind mit Benutzern, Gruppen, Rollen und Ressourcen verknüpft. Dadurch wird die Verwaltung von Berechtigungen in Ihrem Workload überschaubarer, insbesondere für kleinere Organisationen mit einer geringen Anzahl von Konten. Im Fall von umfassenderen Berechtigungen mit mehreren Konten. In diesen Fällen haben Sie in der Regel ein Plattformteam, das den Prozess der Kontovergabe verwaltet. Und Sie haben wahrscheinlich einige standardisierte Ressourcen, die Sie bereitstellen. Die Workload-Teams sollten diese Ressourcen nicht verändern, da sie vom Workload-Team erstellt wurden. Sie können diese Ressourcen auf Organisationsebene mit Service Control Policies (SCPs) schützen.

AWS-Berechtigungen

Richtlinien werden auf der Grundlage der Anfrage und Autorisierung eines Benutzers erstellt. Sie sollten dem Prinzip der geringsten Privilegien folgen. Eine Richtlinie definiert Berechtigungen und bestimmt den Zugriff oder die Verweigerung, wenn ein IAM-Prinzipal (Benutzer oder Rolle) sie anfordert. Eine Richtlinie ist nichts anderes als eine JSON-Definition. Sie können sie von Grund auf neu schreiben, von bestehenden kopieren oder den visuellen Editor verwenden. Sie definieren die Richtlinie, aber AWS übernimmt die Durchsetzung. AWS bietet auch verwaltete Richtlinien an, die vom AWS-Team verwaltet und gepflegt werden. Sie können sie direkt verwenden und von AWS verwalten lassen oder sie kopieren und nach Ihren Bedürfnissen ändern. Jedem Benutzer und jeder Rolle können Richtlinien zugewiesen werden. Benutzer können Richtlinien erben, die auf den Gruppen basieren, denen sie angehören. Zum Zeitpunkt der Erstellung dieses Dokuments können Sie einem Benutzer oder einer Rolle maximal 10 Richtlinien zuordnen. Dies ist eine weiche Grenze und Sie können eine Erhöhung auf maximal 20 beantragen.

Es gibt sechs Arten von Richtlinien, die AWS unterstützt und die hauptsächlich im JSON-Richtliniendokumentformat verfasst sind:

• Organisation SCP: Die Service Control Policy wird verwendet, um die maximalen Berechtigungen in einer Organisation zu definieren. SCPs werden auf Organisationseinheiten angewandt, und die Richtlinien werden von der übergeordneten OU geerbt. SCPs dienen nicht dazu, Aktionen zu erlauben, sondern nur dazu, Aktionen zu verweigern. Sie können SCPs beispielsweise verwenden, um zu verhindern, dass das Entwicklungsteam teure Ressourcen wie EC2 "u-12tb1.112xlarge" einsetzt, die $3.648 pro Tag kosten. Oder Sie können SCPs verwenden, um einzuschränken, welche Regionen in Ihrem Unternehmen genutzt werden können, indem Sie den Rest der Regionen verweigern.
• Identitätsbasierte Richtlinien: Berechtigungen, die von IAM-Identitäten (Benutzer, Gruppen oder Rollen) erteilt werden. Damit wird gesteuert, welche Aktionen eine Identität durchführen kann. In der Richtlinie können Sie Aktionen für jeden Dienst, die alle oder bestimmte Ressourcen betreffen, unter bestimmten Bedingungen verweigern oder zulassen. So können Sie beispielsweise eine Richtlinie erstellen, die das Auflisten von Objekten von S3-Buckets, deren Name mit app1-acc-* beginnt, unter der Bedingung erlaubt, dass der Benutzer bei der Authentifizierung MFA verwendet hat.
• Ressourcenbasierte Richtlinien: Sie können Benutzern oder Gruppen bestimmte Aktionen verweigern oder erlauben, indem Sie Inline-Richtlinien an Ressourcen anhängen. Ressourcenbasierte Richtlinien sind für verschiedene Dienste verfügbar; die Liste finden Sie hier.
• Berechtigungsgrenzen: Die maximalen Berechtigungen, die eine identitätsbasierte Richtlinie einer Entität gewähren kann. Berechtigungsgrenzen sind die perfekte Lösung, um mehr Aufgaben an Entwickler zu delegieren und so das Plattformteam zu entlasten, ohne die Sicherheit zu beeinträchtigen.
• Sitzungsrichtlinien: Schränkt die Berechtigung ein, die der Benutzer oder die Rolle einer Sitzung gewähren kann, wenn Sie eine Rolle programmatisch übernehmen. Indem Sie eine Sitzungsrichtlinie übergeben, können Sie sicherstellen, dass diese spezielle Sitzung nur die geringsten benötigten Privilegien hat und nicht die gesamte Rollenberechtigung.

AWS-Organisationen

Wenn Ihr Unternehmen wächst, stehen Sie vor zahlreichen Herausforderungen. Eine davon ist, dass Sie mehr Personen in Ihr Unternehmen aufnehmen. Sie können Ihre bestehende SSO-Lösung (Single Sign On) verwenden oder AWS Single Sign On zur Authentifizierung dieser Benutzer einsetzen. Damit können sie eine Rolle in einem der AWS-Konten übernehmen. Eine weitere Herausforderung besteht darin, dass Sie Ihre Arbeitslasten auf mehrere AWS-Konten verteilen. Dies würde zu immer mehr AWS-Konten führen, während Sie wachsen. Eine gängige Praxis ist auch die Aufteilung von Umgebungen auf mehrere Konten. So könnten Sie für eine einzelne Arbeitslast leicht Entwicklungs-, Test-, Abnahme- und Produktionskonten haben.

Diese Herausforderungen lassen sich mit AWS Organizations bewältigen. Damit können Sie die Konten selbst und den Zugriff auf sie zentral verwalten. Außerdem können Sie damit SCP (Service Control Policies) verwalten.

Verwaltung von Berechtigungen in AWS-Organisationen: Richtlinien für die Servicekontrolle

Service Control Policies sind ein Richtlinientyp, der in AWS zu finden ist. SCPs eignen sich gut für große Organisationen, da sie es der Organisation ermöglichen, die Verantwortlichkeiten aufzuteilen. Mit einer organisatorischen SCP können Sie komplette Services oder nur eine Handvoll von Aktionen verweigern. Diese SCPs haben die gleiche Richtlinienstruktur wie die IAM-Richtlinien, mit einem Unterschied. Sie gelten für das gesamte AWS-Konto. Zum Beispiel, wenn Sie einen bestimmten Plan haben, wie ein AWS-Konto aussehen soll, wenn Sie es an ein Workload-Team übergeben. Sie können diese Ressourcen davor schützen, dass sie von den Benutzern und Rollen, die das Workload-Team verwendet, geändert oder gelöscht werden.

Ein SCP wird auf eine Organisationseinheit (OU) angewendet und gilt für alle Konten in der OU, einschließlich aller verschachtelten OUs. Eine seiner Hauptfunktionen besteht darin, sicherzustellen, dass alle Konten innerhalb der Zugriffskontrollrichtlinien einer Organisation bleiben. Das bedeutet, dass SCPs zwar keine Berechtigungen erteilen, jedoch die Grenzen und Aktionen von IAM-Benutzern und -Rollen festlegen. SCPs fungieren quasi als Leitplanke für alle Konten, die ein Administrator kontrolliert.

Ein SCP kann eine IAM-Richtlinie außer Kraft setzen. In der Tat hilft ein SCP Unternehmen bei der Lösung von Problemen, die in einer sich entwickelnden Cloud-Infrastruktur auftreten können. Da Unternehmen in der Regel viele bewegliche Teile haben, mit verschiedenen Teams, Abteilungen, Hierarchien usw., helfen SCPs dabei, die Grenzen dessen zu definieren, was innerhalb des Kontos erlaubt ist. Im Konto selbst müssen Sie noch die Zugriffsrechte für jeden Principal festlegen. Wenn dem Prinzipal ein Zugriff gewährt wird, der durch den SCP verweigert wird. Der Prinzipal darf diese Aktion nicht durchführen.

Arbeiten mit einem SCP Beispiel

Nehmen wir an, es gibt ein Plattform-Team und ein Workload-Team. Das Workload-Team ist das einzige Team, das S3-Buckets erstellen darf, die mit xebia-workload beginnen. Das Plattformteam ist das einzige Team, das Buckets erstellen darf, die mit xebia-platform beginnen. Sie können dies mit dem folgenden SCP erreichen:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPlatformPrefixBuckets",
      "Effect": "Deny",
      "Action": [
        "s3:CreateBucket"
      ],
      "Resource": [
        "arn:aws:s3:::xebia-platform-*"
      ],
      "Condition": {
        "ForAnyValue:StringNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/Administrator*"
          ]
        }
      }
    },
    {
      "Sid": "AllowWorkloadPrefixBuckets",
      "Effect": "Deny",
      "Action": [
        "s3:CreateBucket"
      ],
      "Resource": [
        "arn:aws:s3:::xebia-workload-*"
      ],
      "Condition": {
        "ForAnyValue:StringNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/Developer*"
          ]
        }
      }
    }
  ]
}

Wenn Sie versuchen, einen xebia-platform-myworkload S3-Bucket mit der Rolle "Entwickler" zu erstellen. Sie erhalten eine Fehlermeldung wie diese:

Wenn Sie einen xebia-workload-myworkload S3-Bucket mit der Rolle "Entwickler" erstellen. Sie können den Bucket erstellen.

Wenn Sie sich die Richtlinie genauer ansehen, werden Sie feststellen, dass wir für die Aktion s3:CreateBucket ein Deny gesetzt haben. Für Buckets, die auf den Namen passen, wenn der ARN des Auftraggebers nicht mit der Rolle Entwickler übereinstimmt. Sie können dies dahingehend übersetzen, dass nur der Rolle Entwickler die Erstellung eines Buckets mit dem Präfix xebia-workload- nicht verweigert wird.

Dies ist ein einfaches Beispiel, aber es veranschaulicht die Leistungsfähigkeit eines SCP. Aus organisatorischer Sicht können Sie Entwickler daran hindern, Plattform-Buckets zu erstellen. Und Sie können Administratoren daran hindern, Workload-Buckets zu erstellen.

Dadurch entsteht auch ein Problem für die Entwicklerrolle. Eine Aktion wird verweigert, aber aus Sicht des Kontos sollte die Entwicklerrolle in der Lage sein, einen xebia-platform-workload Bucket zu erstellen. Die Lösung für dieses Problem ist die Verwendung des IAM Policy Simulators. Sie können eine Rolle, eine Aktion und die Ressource auswählen und simulieren, was passieren würde.

Wie Sie sehen können, wurde die Aktion verweigert. Aber es wird auch angegeben, dass sie von AWS Organizations verweigert wird. Jetzt weiß der Entwickler, dass die Aktion aufgrund eines SCP blockiert ist.

Grenzen der Erlaubnis: Warum sollten Sie sie nutzen?

Stellen Sie sich folgendes Szenario vor: Sie sind der Plattformadministrator und müssen eine Richtlinie für einen Entwickler erstellen, der an serverlosen Anwendungen arbeitet. Der Entwickler benötigt für jede erstellte Anwendung eine Rolle, was bedeutet, dass Sie jedes Mal neue Rollen erstellen müssen, wenn eine neue Anwendung erstellt wird. Um den Overhead zu reduzieren, möchten Sie dem Entwickler erlauben, die Rollen selbständig zu erstellen, aber Sie sind besorgt, wenn der Entwickler beschließt, eine Rolle zu erstellen, die mehr kann als nötig!

Sie können eine Richtlinie erstellen, die es den Entwicklern nur dann erlaubt, Rollen zu erstellen, wenn sie der Rolle Berechtigungsgrenzen zuweisen. Dann können Sie die maximale Berechtigung in den Berechtigungsgrenzen festlegen. In unserem obigen Szenario können die Berechtigungsgrenzen nur Aktionen für AWS S3 und AWS Lambda-Funktionen zulassen. Wenn der Entwickler beschließt, eine Rolle mit Administratorenzugriff zu erstellen, wird dies durch die Berechtigungsgrenzen auf das beschränkt, was innerhalb der Grenze erlaubt ist.

Das ist es, was AWS die "effektiven Berechtigungen" nennt. Vom organisatorischen Standpunkt aus gesehen verwalten Sie die Berechtigungsgrenzen. Die Entwickler können ihre eigenen Rollen erstellen, aber nur, wenn sie eine der von Ihnen zur Verfügung gestellten Grenzen anhängen.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRolesWithBoundary",
      "Action": [
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy",
        "iam:PutRolePermissionsBoundary"
      ],
      "Effect": "Deny",
      "Condition": {
        "StringNotEquals": {
          "iam:PermissionsBoundary": [
            "arn:aws:iam::111122223333:policy/xebia-default-boundary"
          ]
        }
      },
      "Resource": "*"
    }
  ]
}

Wie Sie in dieser Beispielrichtlinie sehen können, verweigern wir die Aktionen, wenn es keine Berechtigungsgrenze namens xebia-default-boundary gibt.

Debuggen von Berechtigungsfehlern

Als Entwickler stoßen Sie möglicherweise auf Berechtigungsfehler. Diese Fehler machen vielleicht keinen Sinn, weil aus der Sicht des Entwicklers alle Richtlinien korrekt eingestellt sind. In diesen Fällen stoßen Sie möglicherweise auf einen SCP, der Sie an der Ausführung der Aktion hindert.

Aus diesem Grund ist es nützlich, den Richtliniensimulator zu verwenden. Im Simulator können Sie eine Rolle auswählen, die Sie erstellt haben. Gefolgt von dem Dienst und der Aktion, die Sie simulieren möchten. So erfahren Sie, ob die Aktion erlaubt ist oder nicht. Aber noch wichtiger ist, dass er Ihnen mitteilt, warum sie verweigert wird.

Fazit

Wenn Sie in größeren Organisationen arbeiten, ist es wichtig, dass Sie eine gute Vorstellung davon haben, wie Sie Ihr Berechtigungsmanagement handhaben. Wie Sie in diesem Beitrag lesen konnten, gibt es verschiedene Stellen, an denen Sie Ihre Richtlinien anwenden können. Schreiben Sie auf, wie Sie Ihre Rechteverwaltung handhaben, und sehen Sie es sich an, bevor Sie zukünftige Änderungen an Ihren Richtlinien vornehmen.

Am besten dokumentieren Sie Funktionen für jede Rolle, definieren die Berechtigung für eine Funktion mit den geringsten Privilegien mit der Aktion "Zulassen" und vermeiden die Aktion "Verweigern".