Ihre AWS-Berechtigungsrichtlinien in den Griff bekommen

In letzter Zeit bekomme ich viele Fragen von unseren Kunden über den Umgang mit den verschiedenen Ebenen im IAM-Berechtigungsmodell. Zum Beispiel: Wie findet man das richtige Gleichgewicht zwischen Dienstkontrollrichtlinien, identitätsbasierten Richtlinien und einer Berechtigungsgrenze, und wie schützt ein zentrales Cloud-Plattformteam seine Plattformressourcen angesichts der verschiedenen Richtlinienbeschränkungen?

In diesem Beitrag werde ich die Theorie kurz rekapitulieren, Sie auf einige der Vorbehalte aufmerksam machen und einige unserer Richtlinien für die Umsetzung dieser Richtlinien vorstellen. Am Ende gebe ich Ihnen eine Liste nützlicher Artikel mit auf den Weg, für den Fall, dass Sie sich eingehender mit dem Thema befassen möchten.

Auffrischung der Theorie

Bevor wir mit der Auffrischung der Theorie zu Service Control Policies (SCPs), identitätsbasierten Richtlinien (IAM-Richtlinien) und der Berechtigungsgrenze beginnen, möchte ich anmerken, dass ich die ressourcenbasierten Richtlinien und die Sitzungsrichtlinien in diesem Blogbeitrag absichtlich ausgelassen habe. Obwohl diese Richtlinien in der gesamten Berechtigungsstruktur in AWS von größter Bedeutung sind, bin ich der Meinung, dass die Abgrenzung dessen, was in diese Richtlinien einfließt, viel klarer ist als bei den Richtlinien, die wir in diesem Beitrag besprechen.

Im Mittelpunkt der Herausforderung bei der Vergabe von AWS-Genehmigungen steht die Reihenfolge, in der die Richtlinien bewertet werden. Das folgende Flussdiagramm zeigt, wie die Entscheidung getroffen wird, ob eine Aktion erlaubt ist oder nicht. In diesem Flussdiagramm sind die Auswirkungen ressourcenbasierter Richtlinien sowie implizite Verweigerungen in den anderen Richtlinientypen nicht berücksichtigt.

Das explizite 'Verweigern' ist das A und O, da es jede 'Erlauben'-Anweisung in einer der Richtlinien, die für einen Principal gelten, außer Kraft setzt. Dies ist besonders wichtig, wenn Sie damit beginnen, Aktionen in allgemeinen Richtlinien, die Sie auf mehrere Principals anwenden möchten, explizit zu verweigern, z.B. in Richtlinien zur Dienstkontrolle. Wenn Sie sich entscheiden, explizite Verweigerungsanweisungen in diese allgemeinen Richtlinien einzufügen, müssen Sie sehr sicher sein, dass Sie dies für alle diese Principals wollen. Glücklicherweise gibt es Möglichkeiten, Principals von diesen Anweisungen auszuschließen, die wir später in diesem Beitrag behandeln werden.

Wenn Sie eine Aktion nicht explizit verweigern, wird die Anfrage implizit verweigert, so dass das Prinzip der geringsten Privilegien eingehalten wird. Kein Prinzipal kann etwas in unserem AWS-Konto tun, wenn wir es nicht ausdrücklich erlauben.

Von diesem Punkt an geht es um eine Überschneidung von expliziten Erlaubniserklärungen, die die effektiven Berechtigungen eines Prinzipals bestimmen. Nur Aktionen, die von allen drei Richtlinientypen explizit erlaubt wurden (vorausgesetzt, alle 3 sind hier vorhanden, denn das sollten sie auch sein), sind erlaubt:

Eine der größten Herausforderungen

Ich denke, es versteht sich von selbst, dass eine der größten Herausforderungen, mit denen wir bei der Umsetzung von Berechtigungsrichtlinien konfrontiert sind, die Größe der Richtliniendokumente ist. Unabhängig davon, mit welcher Art von Richtlinie wir es zu tun haben, steht uns nur eine begrenzte Menge an Platz in den Dokumenten zur Verfügung, die wir zur Definition dieser Richtlinien verwenden. Das zwingt uns dazu, den Inhalt dieser Dokumente kreativ zu gestalten und gleichzeitig sicherzustellen, dass wir nicht versehentlich zu viele Rechte vergeben.

Insbesondere die Richtlinien zur Dienstkontrolle sind von der Größe her schwierig zu handhaben. Wir müssen sicherstellen, dass alles, was wir wollen, in ein 5120 Bytes großes Richtliniendokument passt, was schwierig werden kann, wenn Sie sie etwas komplexer gestalten wollen. Sie sollten bedenken, dass Leerzeichen (Leerzeichen und Zeilenumbrüche) in dieser Zeichenbegrenzung enthalten sind. Bei Xebia wandeln wir häufig ein lesbares SCP in einem Code-Repository in ein weniger lesbares SCP um, indem wir alle diese Zeichen entfernen. Sie könnten dies auf jedes Richtliniendokument anwenden, das Sie bereitstellen, aber wenn Sie natives CloudFormation verwenden, ist Ihr übertragener Code besonders schwer zu lesen.

Insbesondere mit der breiten Einführung von AWS SSO wird der Platzbedarf zu einer Herausforderung. Da wir nicht in der Lage sind, eine Berechtigungsgrenze direkt an einen Berechtigungssatz anzuhängen, müssen wir nun alle Anweisungen, die wir in unserer Berechtigungsgrenze definiert haben, in den Berechtigungssatz verschieben - was natürlich mehr Platz benötigt.

Ein Mangel an Platz in den Richtlinien deutet jedoch oft darauf hin, dass wir weniger als optimale Richtlinien implementieren. Übermäßig komplexe Richtlinien benötigen oft mehr Platz. Lassen Sie uns also einen Blick darauf werfen, wie wir die Richtlinien sauber, einfach und kurz halten können.

Unser Leitfaden

Um eine wirksame Kombination von Richtlinien zu erstellen und gleichzeitig die Vorbehalte zu berücksichtigen, mit denen wir umgehen müssen, halten wir uns bei der Gestaltung dieser Richtlinien an eine Reihe von Leitlinien. Es ist wichtig zu betonen, dass es sich dabei um Richtlinien handelt, die nicht als strenge Regeln zu verstehen sind. So können wir die Implementierung an die Anforderungen des Kunden anpassen.

Wenn Sie die API-Aktivitäten für die Mehrheit der Principals auf einer/der Plattform einschränken, verwenden Sie Richtlinien zur Dienstkontrolle und nutzen Sie die aws:PrincipalArn-Richtlinienbedingung, um Ausnahmen von dieser Richtlinie zu erstellen.

Ich sehe viele Kunden, die ihren kostbaren Zeichenraum in identitätsbasierten Richtlinien oder Berechtigungsgrenzen nutzen, um präventive Leitplanken zum Schutz ihrer Landing Zone/plattformbezogenen Ressourcen zu implementieren. Auch wenn Plattformadministratoren/-betreiber der Meinung sind, dass sie in diesem Bereich eine gewisse Freiheit haben sollten, gibt es keinen Grund, diese Entitäten nicht einzubeziehen und Änderungen an diesen Ressourcen durch Infrastructure-as-Code zu erzwingen. Außer dem IAM-Prinzipal, der von der Automatisierung verwendet wird, gibt es keine Entität, die in der Lage sein sollte, diese Ressourcen zu ändern, was diese Art von Richtlinie zu einer perfekten Ergänzung für eine Dienstkontrollrichtlinie macht.

Da wir die IAM-Rolle ausschließen möchten, die für die Bereitstellung von Plattformkomponenten verwendet wird, müssen wir die aws:PrincipalArn-Richtlinienbedingung wie folgt verwenden:

{
   "Erklärung": [
  {
           "Sid":  "BlacklistedLandingZoneAktionen",
           "Wirkung":  "Verweigern",
           "Aktion": [
               "ec2:CreateTraffic*",
               "ec2:CreateTransit*",
               "ec2:CreateVpc",
               "ec2:CreateVpcPeer*",
               "ec2:DeleteNetworkAcl*",
               "ec2:DeleteRoute*",
               "ec2:DeleteSubnet",
               "ec2:DeleteTraffic*",
               "ec2:DeleteTransit*"
               ....
  ],
           "Ressource": [
               "*"
  ],
           "Zustand": {
               "ForAnyValue:StringNotLike": {
                   "aws:PrincipalARN": [
                       "arn:aws:iam::*:role/customer-platform-provisioning"
  ]
  }
  }
  }
  ]
}

Verwenden Sie die Richtlinien zur Dienstkontrolle, um die Plattformressourcen zu schützen, andernfalls greifen Sie auf Berechtigungsgrenzen zurück.

Wie ich bereits in diesem Beitrag erwähnt habe, bin ich der Meinung, dass wir SCPs verwenden sollten, um die Ressourcen der Plattform zu schützen, aber manchmal befinden Sie sich in einer Situation, in der das aus verschiedenen Gründen nicht möglich ist (man denke nur an die Größenbeschränkung von Dokumenten :)). In diesen Fällen ist es meiner Meinung nach völlig in Ordnung, auf Berechtigungsgrenzen zurückzugreifen, solange Sie die Verwendung dieser Grenzen durchsetzen.

Verwenden Sie eine klare Namenskonvention für AWS-Ressourcen

Bitte tun Sie sich und Ihren Kollegen einen großen Gefallen und führen Sie eine klare Namenskonvention für die von Ihnen bereitgestellten AWS-Ressourcen ein. Durch die Einhaltung eines klaren Standards und die Verwendung von Präfixen, z.B. "Kunde-", können Sie Platzhalter in Richtlinien verwenden und so den benötigten Richtlinienplatz erheblich reduzieren. Damit schaffen Sie auch die Voraussetzungen für eine Aufgabentrennung zwischen den verschiedenen Einheiten, die Ihre Plattform nutzen. Wir können Präfixe verwenden, um die Zugriffskontrolle auf bestimmte Ressourcen zu erleichtern. Im Allgemeinen funktioniert eine Namenskonvention besser als die Verwendung von Tags zur Kontrolle des Zugriffs auf Ressourcen, da nicht alle Ressourcen Tagging unterstützen.

Stellen wir uns Folgendes vor: Wir haben ein paar CloudFormation-Stacks, die vom Cloud-Plattform-Team bereitgestellt werden und keine bestimmte Namenskonvention verwenden:

• route53-Auflöser
• Konfig-Bucket
• vpc
• ssm-patch-management

Um diese CloudFormation Stacks zu schützen, müssen Sie die folgende Richtlinie angeben:

{
  "Erklärung": [
  {
          "Sid":  "UnsereCloudFormationStacksnichtberühren",
          "Wirkung":  "Verweigern",
          "Aktion": [
              "cloudformation:*"
  ],
          "Ressource": [
            "arn:aws:cloudformation:region:accountid:stack/route53-resolver-rules",
            "arn:aws:cloudformation:region:accountid:stack/config-bucket",
            "arn:aws:cloudformation:region:accountid:stack/vpc",
            "arn:aws:cloudformation:region:accountid:stack/ssm-patch-management"
  ]
  }
  ]
}

Mit einer einheitlichen Namenskonvention für Ihre Stapel könnten Sie diese Richtlinie um eine erhebliche Anzahl von Zeichen verkürzen:

{
  "Erklärung": [
  {
          "Sid":  "UnsereCloudFormationStacksnichtberühren",
          "Wirkung":  "Verweigern",
          "Aktion": [
              "cloudformation:*"
  ],
          "Ressource": [
              "arn:aws:cloudformation:region:accountid:stack/customer-*"
  ]
  }
  ]
}

Auch wenn die Anzahl der gewonnenen Zeichen im Moment noch begrenzt scheint, stellen Sie sich vor, Sie müssten alle CloudFormation Stacks angeben, die die Landing Zone in einem Konto bilden.

Verwenden Sie bei der Definition von Aktionen in Richtlinien bewusst Platzhalter.

Wenn Sie in Ihrem Richtliniendokument Aktionen festlegen, schadet es nicht, Wildcards aggressiv zu verwenden, aber achten Sie darauf, dass Sie nicht aus Versehen zu freizügig sind.

Angenommen, wir möchten verhindern, dass unsere Entwicklungsteams Einladungen/Anhänge zu unserer VPC annehmen, dann könnten wir dies mit der folgenden Richtlinie erreichen:

{
   "Erklärung": [
  {
           "Sid":  "UnserVPCschützen",
           "Wirkung":  "Verweigern",
           "Aktion": [
               "ec2:AcceptReservedInstancesExchangeQuote",
               "ec2:AcceptTransitGatewayMulticastDomainAssociations",
               "ec2:AcceptTransitGatewayPeeringAttachment",
               "ec2:AcceptTransitGatewayVpcAttachment",
               "ec2:AcceptVpcEndpointConnections",
               "ec2:AcceptVpcPeeringConnection"
  ],
           "Ressource": [
               "*"
  ]
  }
  ]
}

Diese Richtlinie wird durch das oben erwähnte Wildcarding erheblich verkürzt:

{
  "Erklärung": [
  {
          "Sid":  "UnserVPCschützen",
          "Wirkung":  "Verweigern",
          "Aktion": [
               "ec2:Acc*"
  ],
          "Ressource": [
              "*"
  ]
  }
  ]
}

Nutzen Sie verschachtelte OUs, um mehr Richtlinien zur Dienstkontrolle anzuwenden

OEs können bis zu fünf Ebenen tief verschachtelt werden. Da SCPs von übergeordneten OUs vererbt werden, können wir SCPs übereinander schichten. Wenn Sie die zusätzlichen Berechtigungsebenen hinzufügen, die mit identitätsbasierten Richtlinien und Berechtigungsgrenzen eingeführt wurden, sind Sie garantiert in der Lage, den gewünschten Berechtigungssatz zu erreichen.

Fazit

In diesem Blogbeitrag habe ich die wichtigsten Herausforderungen bei der Implementierung von Richtlinien zur Dienstkontrolle, identitätsbasierten Richtlinien und einer Berechtigungsgrenze beschrieben. Ich habe Ihnen einen Einblick gegeben, wie Xebia an diese Herausforderungen herangeht und worauf Sie bei der Implementierung der verschiedenen Richtlinienschichten achten sollten.

Obwohl viele dieser Richtlinien trivial erscheinen, erleben wir regelmäßig, wie Menschen damit kämpfen, Richtlinien klar und konsequent umzusetzen. Obwohl jeder Kundenfall einzigartig ist, hoffen wir, dass die in diesem Artikel gegebenen Hinweise ausreichen, um Ihnen den Einstieg zu erleichtern. Wenn Sie jedoch das Gefühl haben, dass Sie noch etwas Hilfe brauchen - Sie wissen, wo Sie uns finden können!

Nützliche Links

• https://ben11kehoe.medium.com/aws-iam-permission-boundaries-has-a-caveat-that-may-surprise-you-d8e7dcf8b649
• https://aws.amazon.com/blogs/mt/codify-your-best-practices-using-service-control-policies-part-1/
• https://aws.amazon.com/blogs/mt/codify-your-best-practices-using-service-control-policies-part-2/
• https://aws.amazon.com/blogs/mt/implement-read-only-service-control-policy-in-aws-organizations/
• https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/