こんにちは。AWS CLIが好きな福島です。
はじめに
今回は、SSMを利用したOSアクセスの統制について検討する機会があったため、ブログにまとめたいと思います。
構成
初期セットアップ
- ①IAM Userを1つのAWSアカウントに集約し、スイッチロール形式で各AWSアカウントにアクセスする
- ②SSMを利用したOSアクセス用のIAMロール(OSAccess)を作成する
- ③IAMロール(OSAccess)には、OSアクセスするために必要な権限だけ付与する
- ④SCPにより、StartSession操作を禁止する(上記IAMロール以外)
運用イメージ
- 通常時は、OSAccessへのスイッチロール権限を付与しない
- OSアクセスが必要な場合、利用者から管理者へ申請する
- 管理者は、利用者にOSAccessへのスイッチロール権限を付与する(時間指定)
補足
運用には最近リリースされたJITNAを活用する方法も考えられます。 その場合は以下のような構成および運用になるかと存じます。 机上なので今度検証したらまた別のブログにまとめたいと思います。
- JITNAには、SSM-JustInTimeAccessTokenRoleが利用されるため、OSAccessのIAMロールは不要
- SCPを更新し、OSAccessではなく、SSM-JustInTimeAccessTokenRoleを操作禁止の対象から除外する
- OSアクセスが必要な場合は、普段利用するIAMロールを活用し、管理者へJITNA経由で申請する
JITNAの詳細は以下をご確認ください。
【AWS Systems Manager の新しいエクスペリエンス】(2) ジャストインタイムノードアクセス (JITNA) を試す (1) - サーバーワークスエンジニアブログ
試してみる
①SCPの設定
SCPを作成します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Deny", "Action": "ssm:StartSession", "Resource": "*", "Condition": { "ArnNotLike": { "aws:PrincipalARN": "arn:aws:iam::*:role/OSAccess" } } } ] }
特定のアカウントまたはOUにアタッチします。 (今回は検証のため、アカウントに直接アタッチしました。)
②SCPの動作確認
SCPにより想定通り、OSアクセスが禁止されていることを確認します。 利用するIAMロールには、管理者権限(AdministratorAccess)を付与しています。
ターミナルセッション接続
ターミナルセッション接続の開始
無事にSCPにより接続が拒否されました
リモートデスクトップ接続
リモートデスクトップ接続の開始1
リモートデスクトップ接続の開始2
無事にSCPにより接続が拒否されました
③OSAccessのIAMロールの作成
OSAccess用のIAMロールには、以下のポリシーを付与します。
- ReadOnlyAccess:読み取り専用の権限(マネージドポリシー)
- OSAccessPolicy:OSアクセスに必要な権限(カスタムポリシー)
OSAccessPolicyにはドキュメントを参考に以下の権限を付与します。
参考:
- Sid: SsmStartSessionの参考
- 上記以外の参考
{ "Version": "2012-10-17", "Statement": [ { "Sid": "SsmStartSession", "Effect": "Allow", "Action": [ "ssm:StartSession" ], "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ssm:*:*:managed-instance/*", "arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell" ] }, { "Sid": "TerminateAndResumeSession", "Effect": "Allow", "Action": [ "ssm:TerminateSession", "ssm:ResumeSession" ], "Resource": "*", "Condition": { "StringLike": { "ssm:resourceTag/aws:ssmmessages:session-id": [ "${aws:userid}" ] } }, { "Sid": "EC2", "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:GetPasswordData" ], "Resource": "*" }, { "Sid": "SSM", "Effect": "Allow", "Action": [ "ssm:DescribeInstanceProperties", "ssm:GetCommandInvocation", "ssm:GetInventorySchema" ], "Resource": "*" }, { "Sid": "SSMStartSession", "Effect": "Allow", "Action": [ "ssm:StartSession" ], "Resource": [ "arn:aws:ec2:*:account-id:instance/*", "arn:aws:ssm:*:account-id:managed-instance/*", "arn:aws:ssm:*::document/AWS-StartPortForwardingSession" ], "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": "ssm-guiconnect.amazonaws.com" } } }, { "Sid": "GuiConnect", "Effect": "Allow", "Action": [ "ssm-guiconnect:CancelConnection", "ssm-guiconnect:GetConnection", "ssm-guiconnect:StartConnection", "ssm-guiconnect:ListConnections" ], "Resource": "*" } ] }
④OSAccessの動作確認
OSAccessにスイッチロールした状態で先ほどのSCPの動作確認と同様にOSアクセスをします。
ターミナルセッション接続
ターミナルセッション接続の開始
無事にアクセスできました!
リモートデスクトップ接続
リモートデスクトップ接続の開始1
リモートデスクトップ接続の開始2
無事にアクセスできました!
⑤OSAccessへのスイッチロールの制御
OSAccessへのスイッチロールの制御は、以下で実現することができます。 時間指定で権限付与するため、権限剥奪するのを忘れるといった心配が不要となります。 ただし、UTCで記載する必要があるため、その点は注意が必要となります。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/OSAccess", "Condition": { "DateGreaterThan": {"aws:CurrentTime": "2020-04-01T00:00:00Z"}, "DateLessThan": {"aws:CurrentTime": "2020-06-30T23:59:59Z"} } } ] }
終わりに
今回は、マルチアカウント環境において、 SSMを利用したOSアクセスの統制方法をまとめてみました。
どなたかのお役に立てれば幸いです。