Fein abgestufter EC2-Zugang mit SSM, IAM Identity Center und Tags

Wenn Ihr Unternehmen das IAM Identity Center (früher AWS Single Sign-On, AWS SSO) verwendet, ist die Wahrscheinlichkeit groß, dass die meisten Benutzer beim Zugriff auf AWS-Konten dieselbe IAM-Rolle annehmen.

Aber was ist, wenn Sie den Zugriff auf EC2-Instanzen dennoch für einzelne Benutzer einschränken möchten?

Wir sind auf genau dieses Szenario gestoßen und haben eine einfache Lösung gefunden, die für andere nützlich sein könnte - auch für unser zukünftiges Ich.

Annahmen

Wir gehen von den folgenden Annahmen aus:

Wenn in Ihrer Umgebung nicht ausschließlich über SSM Session Manager auf EC2-Instanzen zugegriffen wird, ist dies eine Überlegung wert. Session Manager beseitigt die Notwendigkeit offener SSH-Ports und zentralisiert die Zugriffskontrolle in IAM, wodurch sowohl der betriebliche Aufwand als auch das Sicherheitsrisiko reduziert werden.

Lösung

Die Idee ist ganz einfach: Wir versehen jede EC2-Instanz mit einem User -Tag und stellen sicher, dass Benutzer nur auf Instanzen eine Sitzung starten können, bei denen dieses Tag mit ihrem Benutzernamen übereinstimmt.

Einem zweiten Benutzer kann der Zugriff gestattet werden, indem Sie das Tag User2 setzen. Damit diese Regel gilt, muss das Tag User jedoch noch vorhanden sein.

Um dies zu erzwingen, fügen wir eine explizite Ablehnungsanweisung zu der IAM-Richtlinie hinzu, die der gemeinsamen Rolle zugeordnet ist:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyStartSessionIfUserNotInSessionUserTags",
      "Effect": "Deny",
      "Action": "ssm:StartSession",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "Null": {
          "ssm:resourceTag/User": "false"
        },
        "StringNotLike": {
          "aws:userid": [
            "AROA*:${ssm:resourceTag/User}",
            "AROA*:${ssm:resourceTag/User2}"
          ]
        }
      }
    }
  ]
}

Wie das funktioniert

Diese Anweisung verweigert ssm:StartSession, wenn die Instanz ein User Tag hat und die Identität des Anrufers nicht mit diesem Wert übereinstimmt.

Lassen Sie uns das aufschlüsseln:

Dadurch wird sichergestellt, dass die Anweisung nur gilt, wenn das Tag User in der Zielinstanz vorhanden ist. - Wenn User vorhanden ist → wird die Bedingung als wahr ausgewertet und der Rest der Anweisung wird ausgewertet. - Wenn User nicht vorhanden ist → wird die Anweisung nicht angewendet. Mit anderen Worten: Nicht markierte Instanzen sind von dieser Ablehnungsregel nicht betroffen.

Wenn sich ein Benutzer über das IAM Identity Center anmeldet, sieht die Seite aws:userid in etwa so aus wie AROAABCDEFGHIJKL:username.

Verhinderung von Manipulationen

Dieses Modell funktioniert natürlich nur, wenn der Benutzer das Tag User nicht selbst ändern kann. Um Manipulationen zu verhindern, fügen wir eine ergänzende Deny-Anweisung hinzu:

    {
      "Sid": "PreventTamperingWithSessionUserTags",
      "Effect": "Deny",
      "Action": [
        "ec2:CreateTags",
        "ec2:DeleteTags"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "aws:TagKeys": [
            "User",
            "User2"
          ]
        }
      }
    }

Wie das funktioniert

Diese Anweisung verweigert jeden Versuch, das Benutzer-Tag auf EC2-Instanzen zu erstellen oder zu löschen.

In der Praxis bedeutet dies, dass jede Anfrage, die User oder User2 enthält, abgelehnt wird.

Dadurch wird sichergestellt, dass die Eigentümerschaft konsequent durchgesetzt wird und nicht durch Änderung des Tags umgangen werden kann. Diese Anweisungen können erweitert werden, um weitere Tags abzudecken.

Sicherer Weg

Ein robusterer und zukunftssichererer Ansatz wäre die Verwendung von Principal Tags anstelle der Analyse von Identitätsinformationen aus aws:userid.

Wenn eine Rolle übernommen wird, können Sie mit AWS Sitzungs-Tags (auch als Principal Tags bezeichnet) anhängen. Diese Tags werden Teil des Identitätskontexts und können in IAM-Richtlinien referenziert werden: ${aws:PrincipalTag/<TagKey>}

Als Teil des SSO-Prozesses könnten wir eine Markierung hinzufügen wie: User: alice

Die Politik würde viel einfacher werden:

"StringNotEquals": {
  "ssm:resourceTag/User": "${aws:PrincipalTag/User}"
}

Dies hat mehrere Vorteile:

Warum wir es nicht verwendet haben

In unserem Fall haben wir nicht die Möglichkeit, benutzerdefinierte Principal Tags an IAM Identity Center Rollensitzungen anzuhängen.

Damit dies funktioniert, benötigen Sie:

Da dies in unserer Einrichtung nicht verfügbar war, haben wir uns für einen Abgleich mit aws:userid entschieden, der für Sitzungen mit angenommener Rolle vorhanden ist. Wenn Sie die Kontrolle über die Attributzuordnungen im Identity Center haben, ist die Verwendung von Principal Tags die sauberere und sicherere Methode.

Fazit

Mit zwei kleinen politischen Erklärungen haben wir unsere Ressourcen geschützt.

Dieser Ansatz lässt sich noch weiter ausbauen - zum Beispiel, um zu verhindern, dass Benutzer Instanzen, die ihnen nicht gehören, beenden, stoppen oder ändern.

Das Ergebnis ist ein Zugriffsmodell, das sich mit Ihrem Unternehmen skalieren lässt, keine Schlüsselrotation oder Verwaltung von autorisierten Schlüsseln erfordert und alle Zugriffsentscheidungen in IAM