Y_Yamashitaのブログ

勉強したことのアウトプット・メモが中心。記事の内容は個人の見解であり、所属組織を代表するものではありません。

(小ネタ)Session Managerのアクセス権限を真面目に絞ってみた

AWS AWS Systems Manager Amazon VPC

最近、これまでザックリと実装してきたサービスを細やかに設計する機会に恵まれ、日々勉強になっています。

今回はその一環で、Session Managerについて、アクセス権限を真面目に(？)絞って実装してみました。

これまでは、IAMロールにはマネージドポリシーの「AmazonSSMManagedInstanceCore」を割り当て、VPCエンドポイントポリシーはデフォルト、セキュリティグループもVPC内は全許可、といった具合で実装することが多かったのですが、今回は、出来るだけ各コンポーネントで必要最小限の許可設定にすることを目指します。

今回の構成

今回は、EC2をプライベートサブネットにデプロイし、VPCエンドポイント経由でSystems Managerと通信させます。セッションデータの暗号化や、セッションログのS3・CloudWatchへの送付は行わないこととします。また、Session Managerはマネジメントコンソールから利用するものとします。

EC2にアタッチするIAMロールのポリシー・VPCエンドポイントポリシーで権限制御を行い、セキュリティグループでネットワークの制御を行います。ネットワークACLは使用しません。リージョンは東京リージョンです。

今回の構成とアクセス制御ポイント

EC2にアタッチするIAMロールのポリシー

まずはEC2にアタッチするIAMロールのポリシーです。以下の公式ドキュメントの「最小限の Session Manager 許可 (コンソール) を付与した IAM ロールの作成」を参考にします。

docs.aws.amazon.com

具体的なポリシーは以下です。「AmazonSSMManagedInstanceCore」と比べると大分権限が少ないですね。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:UpdateInstanceInformation",
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        }
    ]
}

Resource は、もしかしたらもう少し絞れるかもしれませんが、今回は公式ドキュメントの「最小限」に準ずることにします。

VPCエンドポイント

上記のIAMポリシーを見て気づいたのですが、ec2messagesのアクションがありませんね。最低権限の場合は不要なのでしょうか。

答えは、下記の公式ドキュメントにありました。

docs.aws.amazon.com

SSM Agent のバージョン 3.3.40.0 以降、Systems Manager は、使用可能な場合には ec2messages: エンドポイント (Amazon Message Delivery Service) の代わりに ssmmessages: エンドポイント (Amazon Message Gateway Service) を使用するようになりました。
（中略）
2024 年より前にローンチされた AWS リージョン の場合: 現時点では、ec2messages:* アクセス許可はポリシーから安全に削除できます。

ということで、現在では、ssmmessagesエンドポイントが利用できれば、ec2messagesエンドポイントは無くても問題なさそうです。そのため今回は、「com.amazonaws.ap-northeast-1.ssm」と「com.amazonaws.ap-northeast-1.ssmmessages」のエンドポイントのみ用意します。

VPCエンドポイントポリシー

VPCエンドポイントポリシーは、上記のIAMロールのポリシーのアクションを分割し、IAMロールのプリンシパルを追加して作成してみます。

「com.amazonaws.ap-northeast-1.ssm」のエンドポイントポリシー

ssmのアクションは「ssm:UpdateInstanceInformation」だけです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::xxxxxxxxxxxx:role/ssm-minimam-role"
            },
            "Action": [
                "ssm:UpdateInstanceInformation"
            ],
            "Resource": "*"
        }
    ]
}

プリンシパルの「ssm-minimam-role」はEC2にアタッチするIAMロールです。

「com.amazonaws.ap-northeast-1.ssmmessages」のエンドポイントポリシー

ssmmessages のアクションは4つです。ssmと同様に、プリンシパルを追加します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::xxxxxxxxxxxx:role/ssm-minimam-role"
            },
            "Action": [
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        }
    ]
}

セキュリティグループ

EC2のセキュリティグループと、SSMエンドポイントのセキュリティグループ、双方で必要最小限の許可設定とします。許可が必要な通信は、以下公式ドキュメントの「着信接続」に記載の通り、EC2からエンドポイントへのHTTPS通信となります。

docs.aws.amazon.com

VPC エンドポイントにアタッチされたセキュリティグループでは、マネージドインスタンスのプライベートサブネットから、ポート 443 で着信接続を許可する必要があります。

というわけで、以下のようにセキュリティグループを作成してみます。

インバウンドルール アウトバウンドルール
EC2用セキュリティグループ なし VPCエンドポイント用セキュリティグループへのHTTPSを許可
VPCエンドポイント用セキュリティグループ EC2用セキュリティグループからのHTTPSを許可 なし

実際の設定が下図です。

EC2用セキュリティグループ（インバウンドルール）

EC2用セキュリティグループ（アウトバウンドルール）


VPCエンドポイント用セキュリティグループ（インバウンドルール）

VPCエンドポイント用セキュリティグループ（アウトバウンドルール）

接続確認

それでは対象のEC2から接続確認をしてみます。

問題なく接続できました。

まとめ

というわけで、思ったよりも少ない権限と通信許可でSession Managerに接続できました。今まで、個人検証の際には深く考えずにec2messagesのエンドポイントも作成していましたが、今後は特別な要件が無い限りは不要だということも理解できました。今後は、セッションデータを暗号化する場合・セッションログをS3やCloudWatchに送付する場合の権限についても調査していきたいと思います。

今回のブログは以上です。少しでも参考になることがあれば幸いです。