Beschränkung des Zugriffs auf AWS-Ressourcen anhand von SAML-Attributen mit CloudFormation

Einschränkung des Zugriffs auf IAM-Ressourcen basierend auf SAML Subject

Viele größere Unternehmen verwalten ihre eigenen Active Directory-Server. Für den AWS-Zugang erstellen sie in der Regel einen Identitätsanbieter, um eine einmalige Anmeldung (SSO) für die Anmeldung bei AWS zu ermöglichen. Dem Benutzer wird dann häufig der Zugriff auf eine bestimmte Rolle gewährt, die bestimmte Rechte gewährt. Bei diesem Ansatz fehlt es jedoch an praktischer, feinkörniger Kontrolle. Um diese Rechte effektiv zu verwalten, müssen Sie viele IAM-Rollen und AD-Gruppen erstellen und verwalten.

Ein alternativer Ansatz, der in diesem Blogbeitrag beschrieben wird, besteht darin, die SAML-Assertions in Ihren IAM-Richtlinien zu verwenden. Wenn Sie ABAC aktivieren (wofür das Privileg IAM::TagSession für die Rolle erforderlich ist), können Sie anhand von benutzerdefinierten SAML-Attributen differenzieren. Ohne ABAC können Sie immer noch einige Attribute wie das SAML-Subjekt verwenden. In diesem Beitrag werden wir uns zunächst auf Letzteres konzentrieren: Wie Sie das SAML-Subjekt verwenden, um den Zugriff auf IAM-Rollen zu beschränken.

Die CloudFormation-Vorlage unten erstellt eine IAM-Rolle. Ihre einzigen Berechtigungen sind das Auflisten von Buckets, das Auflisten eines bestimmten S3-Buckets und der volle S3-Zugriff auf einen bestimmten Unterordner. Schließlich schränken wir den Zugriff auf den Unterordner auf der Grundlage der Liste der SAML-Subjekte ein, die als Parameter für diesen Stack bereitgestellt wird.

Im AssumeRolePolicyDocument (Vertrauensrichtlinie) definieren wir den Auftraggeber als unseren SAML-Anbieter. Das bedeutet, dass jeder, der über einen föderierten Zugang zu AWS verfügt, diese Rolle übernehmen kann:

        Statement:
          - Action:
              - sts:AssumeRoleWithSAML
              - sts:TagSession
            Condition:
              StringEquals:
                SAML:aud: https://signin.aws.amazon.com/saml
            Effect: Allow
            Principal:
              Federated: !Ref 'SamlProviderArn'

Um den Zugriff auf eine durch Kommata getrennte Liste von SAML-Subjekten zu beschränken, verwenden wir die folgende Bedingung in der S3 IAM Policy:

              Condition:
                ForAllValues:StringLike:
                  saml:sub: !Split
                    - ','
                    - !Ref 'SamlSubjects'

Diese Bedingung besagt im Wesentlichen: Erlauben Sie dies nur, wenn Ihr SAML-Subjekt eines der in der Liste aufgeführten ist. Beachten Sie, dass Sie den Zugriff auf die Rolle auch einschränken können, indem Sie den Bedingungsabschnitt in die Vertrauensrichtlinie verschieben.

Die folgende Vorlage benötigt 3 Parameter: Den Bucket-Namen, den Sie sichern möchten, die ARN des SAML-Anbieters und schließlich die kommagetrennte Liste der SAML-Subjekte.

Vorlage vervollständigen:

Description: Bucket Restriction Stack
Parameters:
  BucketName:
    Description: Bucket name to grant access to
    Type: String
  SamlProviderArn:
    Description: ARN of SAML provider
    Type: String
  SamlSubjects:
    Description: List of Strings
    Type: String
Resources:
  SamlBucketRole:
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Action:
              - sts:AssumeRoleWithSAML
              - sts:TagSession
            Condition:
              StringEquals:
                SAML:aud: https://signin.aws.amazon.com/saml
            Effect: Allow
            Principal:
              Federated: !Ref 'SamlProviderArn'
        Version: '2012-10-17'
      Path: /
      Policies:
        - Statement:
            - Action:
                - s3:ListAllMyBuckets
                - s3:GetBucketLocation
              Effect: Allow
              Resource: '*'
            - Action:
                - s3:ListBucket
              Effect: Allow
              Resource:
                - !Sub 'arn:aws:s3:::${BucketName}'
            - Action:
                - s3:*
              Condition:
                ForAllValues:StringLike:
                  saml:sub: !Split
                    - ','
                    - !Ref 'SamlSubjects'
              Effect: Allow
              Resource:
                - !Sub 'arn:aws:s3:::${BucketName}'
          Version: '2012-10-17'
    Type: AWS::IAM::Role

Nun möchten Sie vielleicht keine Liste von SAML-Subjekten führen. Stellen Sie sich zum Beispiel vor, Sie haben ein S3-Bucket, das Sie sichern möchten und das eine Liste von Unterordnern für jeden Benutzer enthält, wobei der Ordnername mit dem SAML-Subjekt identisch ist. Eine Richtlinie für diese Zugriffsrichtlinie könnte etwa so aussehen:

        {
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::some-s3-bucket"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "",
                        "${saml:sub}/*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::some-s3-bucket/${saml:sub}/*"
            ]
        }

Diese parametrisierte Art der Erstellung von IAM-Richtlinien für SAML-Subjekte lässt sich sehr gut skalieren, aber Sie verlieren etwas an Flexibilität in Bezug auf das, worauf Sie Zugriff gewähren können.

Schließlich möchten Sie vielleicht den Zugriff auf der Grundlage von benutzerdefinierten SAML-Attributen einschränken können. Die standardmäßigen SAML-Attribute von AWS, die verwendet werden können, sind sehr begrenzt. Wenn Sie Session Tags aktivieren, können Sie benutzerdefinierte SAML-Attribute verwenden und diese in Ihren IAM-Richtlinien differenzieren.

Hier ist ein Beispiel:

        {
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::my-s3-bucket"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "",
                        "${aws:PrincipalTag/my-custom-attribute}/*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::my-s3-bucket/${aws:PrincipalTag/my-custom-attribute}/*"
            ]
        }

Ähnlich wie im ersten Beispiel können wir mit dem benutzerdefinierten SAML-Attribut auch eine Liste mit expliziten Bedingungen pflegen, wenn wir ABAC verwenden.

Die Verwendung von Infrastructure as Code für die Verwaltung und Bereitstellung dieser Rollen und Richtlinien reduziert den betrieblichen Aufwand und verhindert menschliche Fehler, aber: Es gibt harte Grenzen für die Größe der Richtlinien und die Anzahl der Bedingungen, die man verwenden kann. Die Skalierbarkeit ist nicht sehr gut, wenn man sie sofort einsetzt.

Fazit

Federation erfordert, dass Sie sich Gedanken über Ihre Datenzugriffsmuster machen. Die Verwendung von SAML-Attributen in Ihren IAM-Richtlinien ist eine leistungsstarke Methode zur Automatisierung des Zugriffs. Damit diese Methode für große Unternehmen skalierbar ist, müssen Sie Ihre Strategie für die Bereitstellung dieser Richtlinien sehr sorgfältig planen. Ein Ansatz könnte darin bestehen, mehrere (verschachtelte) Stapel und einzelne Rollen zu verwenden, um die Größenbeschränkungen der Richtlinien zu umgehen.

Vielleicht gefällt Ihnen auch Wie Sie mit dem SAML-Identitätsanbieter Auth0 AWS-Anmeldeinformationen und Zugriffsschlüssel erhalten und wie Sie einen SAML-Identitätsanbieter konfigurieren, um SSO in AWS CloudFormation zu aktivieren.