So richten Sie ein AWS Session Manager-Protokollierungskreuzkonto ein

Das Einrichten und Verwalten des Zugriffs auf Ihre EC2-Instanzen kann eine Herausforderung sein. Es gibt eine Menge Dinge, die Sie berücksichtigen müssen. Wie rotieren Sie Ihre Schlüssel? Wer hat sich mit diesem Schlüssel angemeldet? Wie begrenzen Sie das Risiko von Thread-Akteuren?

Und was haben sie getan? Was wäre, wenn Sie die komplette Sitzung in einem anderen AWS-Konto protokollieren könnten? Und sie mit einem vom Kunden verwalteten KMS-Schlüssel verschlüsseln? Das würde Ihnen vollständige Transparenz und Auditierbarkeit Ihrer Shell-Sitzungen ermöglichen.

In diesem Blogbeitrag werde ich diese Fragen anhand von AWS Session Manager beantworten.

Was ist der AWS Session Manager?

Aus der Dokumentation entnommen:

Session Manager ist eine vollständig verwaltete AWS Systems Manager-Funktion. Mit Session Manager können Sie Ihre Amazon Elastic Compute Cloud (Amazon EC2) Instanzen, Edge-Geräte, und lokalen Server und virtuellen Maschinen (VMs) verwalten.

Was bedeutet das also? Es bedeutet, dass Sie mit der AWS-Konsole in Ihrem Browser eine SSH-Shell öffnen können. Wählen Sie die EC2-Instanz. Klicken Sie auf die Schaltfläche Verbinden und eine Shell-Sitzung wird im Browser geladen. Sie können dazu auch CLI-Befehle verwenden.

Das Interessante daran ist, dass Sie den Zugang auf der Grundlage Ihrer IAM-Anmeldedaten gewähren. Sie müssen also keine privaten SSH-Schlüssel im Team freigeben. Sie müssen sie nicht rotieren. Sie müssen sie nicht wechseln, wenn ein Teammitglied ausscheidet. Denn Sie brauchen überhaupt keinen privaten Schlüssel.

Aber diese Lösung hat einen weiteren Vorteil. Sie müssen Port 22 nicht öffnen, um eine Verbindung herzustellen. Tatsächlich brauchen Sie keine eingehenden Ports zu öffnen.

Der SSM Agent wird mit dem Amazon Linux 2 AMI vorinstalliert.

Stattdessen verwendet es einen SSM-Agenten. Und dieser Agent meldet sich beim AWS Systems Manager an. Er verwendet dazu das angehängte Instanzprofil. Wenn Sie von diesem Zeitpunkt an eine Shell vom Session Manager anfordern. Der Agent wird auf diese Antwort reagieren und die Verbindung herstellen.

Was sind die weiteren Vorteile?

Ja, es gibt noch mehr! Session Manager hat einige zusätzliche Funktionen!

Sie können die Sitzungsaktivitäten mit Amazon EventBridge verfolgen. Das bedeutet, dass Sie auf diese Ereignisse reagieren können. Dies schafft die Möglichkeit, proaktiv auf diese Ereignisse zu reagieren. Sie könnten zum Beispiel: die Sitzung beenden, wenn kein Zugriff erlaubt ist.

Und das bringt mich zum Hauptthema dieses Blogbeitrags. Was, wenn Sie den Verdacht haben, dass einige Befehle auf einem Server über eine Shell-Sitzung ausgeführt wurden? Wie können Sie beweisen, dass dies geschehen ist oder nicht?

Protokollierung Ihrer Sitzungsaktivitäten

Der Session Manager bietet Ihnen die Möglichkeit, die Sitzung in S3 zu protokollieren. Wie Sie dies einrichten, ist auf den Dokumentationsseiten beschrieben. Wenn Sie jedoch ein zentrales Protokollierungskonto verwenden möchten. Und wenn Sie einen vom Kunden verwalteten KMS-Schlüssel verwenden müssen, ist die Dokumentation nicht sehr hilfreich.

Je nach Anwendungsfall möchten Sie vielleicht den Zugriff beschränken. Sie können dies pro Konto tun. Oder innerhalb einer AWS-Organisation. Für dieses Beispiel beschränke ich den Umfang innerhalb derselben Organisation.

Zunächst müssen Sie einen KMS-Schlüssel erstellen. Dieser Schlüssel wird verwendet, um die auf S3 gespeicherten Daten zu verschlüsseln. S3 muss in der Lage sein, den KMS-Schlüssel zu verwenden. Fügen Sie der Schlüsselrichtlinie folgende Anweisungen hinzu:

{
    "Effect": "Allow",
    "Principal": { "AWS": "*" },
    "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*" ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "kms:ViaService": "s3.eu-central-1.amazonaws.com",
            "aws:PrincipalOrgID": "o-xxxxxxx"
        }
    }
}

Als nächstes erlauben wir kms:Decrypt und kms:GenerateDataKey innerhalb der Organisation. Diese Aktionen sind erforderlich, damit der Session Manager die Sitzung verschlüsseln kann. Und er kann bestätigen, dass er sich bei dem angegebenen S3-Bucket anmelden kann.

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "*"
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:PrincipalOrgID": "o-xxxxxxx"
        }
    }
}

Dann müssen wir einen S3 Bucket erstellen. Sie müssen die Standardverschlüsselung mit dem von Ihnen erstellten KMS-Schlüssel aktivieren. Sie müssen anderen Konten die Berechtigung erteilen, auf diesen Bucket zu schreiben. Sie benötigen also eine Bucket-Richtlinie. Hier ist ein Beispiel für eine Bucket-Richtlinie, die Sie benötigen:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:GetEncryptionConfiguration",
            "Resource": "arn:aws:s3:::my-bucket-name",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-xxxxxxx"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::my-bucket-name/*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-xxxxxxx"
                }
            }
        }
    ]
}

Gut, das Protokollierungskonto wurde vorbereitet. Es kann nun Protokolle von allen Konten innerhalb Ihrer Organisation empfangen. Nun ist es an der Zeit, das Konto einzurichten, das den Session Manager verwenden wird.

Erstellen Sie lokal eine JSON-Datei mit dem folgenden Inhalt:

Ersetzen Sie den Namen des Buckets und den KMS-Schlüssel! Sie können die Konto-ID als Präfix verwenden.

{
    "schemaVersion": "1.0",
    "description": "Document to hold regional settings for Session Manager",
    "sessionType": "Standard_Stream",
    "inputs": {
        "s3BucketName": "[NAME OF THE BUCKET]",
        "s3KeyPrefix": "",
        "s3EncryptionEnabled": true,
        "cloudWatchLogGroupName": "",
        "cloudWatchEncryptionEnabled": false,
        "cloudWatchStreamingEnabled": false,
        "kmsKeyId": "[FULL ARN OF THE KMS KEY]",
        "runAsEnabled": true,
        "runAsDefaultUser": "",
        "idleSessionTimeout": "20",
        "maxSessionDuration": "",
        "shellProfile": {"windows": "", "linux": ""}
    }
}

Wenden Sie dieses SSM-Dokument mit Hilfe des Session Managers auf das Konto an:

aws ssm update-document 
    --name "SSM-SessionManagerRunShell" 
    --content "file://SessionManagerRunShell.json" 
    --document-version "$LATEST"

Zu diesem Zeitpunkt ist alles vorhanden, damit dies funktioniert. Bis auf die IAM-Berechtigungen für das Instanzprofil. Damit dies funktioniert, benötigen Sie die folgenden Berechtigungen:

• Hängen Sie die verwaltete Richtlinie arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore an.
• Erlauben Sie die Aktion "s3:GetEncryptionConfiguration" für die Ressource arn:aws:s3:::[NAME OF THE BUCKET].
• Erlauben Sie die Aktionen "s3:PutObject" und "s3:PutObjectAcl" für die Ressource arn:aws:s3:::[NAME OF THE BUCKET]/*.
• Erlauben Sie die Aktionen "kms:Decrypt" und "kms:GenerateDataKey" für die Ressource [FULL ARN OF THE KMS KEY].

Mit diesen Berechtigungen können Sie eine SSH-Shell starten.

Fazit

Wenn Sie Session Manager verwenden, entfällt nicht nur die Notwendigkeit, Port 22 freizugeben. Sie müssen auch nicht mehr die Schlüssel austauschen, wenn ein Teamkollege geht. Sie bekommen noch viel mehr! Ihre SSH-Sitzung wird mit einem kundenverschlüsselten KMS-Schlüssel verschlüsselt. Den Sie verwalten und pflegen!

Sobald die Sitzung geschlossen ist, wird die komplette Sitzung auf S3 gespeichert. Und wieder verschlüsselt mit einem kundenverschlüsselten KMS-Schlüssel. Den Sie verwalten und pflegen! So können Sie Shell-Sitzungen zur späteren Verwendung archivieren. Sie erhalten eine vollständige Nachvollziehbarkeit und verbessern Ihre Sicherheitslage.

Und weil Sie Ihre Teamkollegen nicht mit neuen Schlüsseln für diese Woche belästigen müssen. Auch für Ihr Team ist es einfacher, sie zu benutzen.