AWS Systems Manager セッションマネージャーのログ出力設定変更を制限する
※これ↑、Systems Manager のアイコンらしいです。
おはこんばんちは、インフラストラクチャー部の沼沢です。
みなさん、AWS Systems Manager 使ってますか?
Systems Manager を使うことで、大量のサーバーの運用保守作業を自動化したり、ソフトウェアインベントリを収集して一元的に確認したりすることができるので大変便利ですよね。
AWS Systems Manager – 運用のインサイトを入手して迅速に対応
そんな Systems Manager に先日、 セッションマネージャー という機能が登場しました。
最新 – AWS Systems Manager セッションマネージャーで EC2 インスタンスへのシェルアクセスを実現 | Amazon Web Services ブログ
SSH不要時代がくるか!?AWS Systems Manager セッションマネージャーがリリースされました! | DevelopersIO
で、これの良いところは
- コンソールからシェルアクセス可能
- EC2 インスタンスに対して SSH の穴あけ不要
- 誰がセッション開始したか、履歴が残る
- 操作ログを S3 や CloudWatch Logs に出力できる
だと思っています。
正直、IAM ユーザーをしっかりと個人ごとに発行していれば、OS アカウントを個人ごとに作成する必要が無くなって良いなーと思ったので、あとは操作ログの出力を強制できれば監査にも使えるなーと思い、調べてみました。
実現したいこと
- Systems Manager 自体は必要な人は誰でも利用できるようにしたい
- マネージドポリシー
AmazonSSMFullAccess
を付与するイメージ
- マネージドポリシー
- セッションマネージャーの設定は、特定の人以外は操作できないようにしたい
- 設定の変更 ≒ ログ出力設定の変更
これを実現する IAM ポリシーが無いか、調査・検証してみました。
調査結果
兎にも角にもまずは公式ドキュメントをチェックしました。
そしてしっかりと答えが書いてありました。ビバ公式ドキュメント。
ただし、本稿執筆時点(2018年10月)では日本語ドキュメントにはまだ無いページなので、日本語ドキュメントで探していると出てこないので注意が必要です。
Grant or Deny a User Permissions to Update Session Manager Preferences - AWS Systems Manager
User policy to prevent preferences from being updated にはこう書いてあります。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Deny",
"Resource": [
"arn:aws:ssm:us-east-2:123456789012:document/SSM-SessionManagerRunShell"
]
}
]
}
この IAM ポリシーで実現できるようです。
ただし、Resource でリージョン us-east-2
と AWS アカウント ID 123456789012
が指定されているので、ここは面倒なのでワイルドカードにしてしまいましょう。
特定のリージョンだけは許可したい、という要件が無いのであれば、ワイルドカードにしても特に問題は無いと思います。
するとこうなります。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Deny",
"Resource": [
"arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
]
}
]
}
マネージドポリシー AmazonSSMFullAccess
を付与したユーザーに、このポリシーを追加で付与し、セッションマネージャーの設定変更を試してみました。
試してみた
まとめ
ログ出力設定を変更できないようにすることができました。
冒頭でも述べたとおり、セッションマネージャーには以下の利点があると考えています。
- コンソールからシェルアクセス可能
- EC2 インスタンスに対して SSH の穴あけ不要
- 誰がセッション開始したか、履歴が残る
- 操作ログを S3 や CloudWatch Logs に出力できる
今回のログ出力設定の変更を拒否するポリシーを適用した上でセッションマネージャーを導入することで、IAM ユーザーさえしっかり管理できていれば、
- 個人 OS アカウント不要 = IAM ユーザーと OS アカウントの二重管理が無くなる
- 個人 OS アカウント不要なので、秘密鍵/公開鍵も不要
- OS 操作ログを永続化する仕組みを自前で用意、運用しなくて良い
- 運用負荷軽減!
になると考えていますので、今後活用していきたいと思います!
補足
もちろん本格的に導入の際は、S3 に吐かれたログファイルや CloudWatch Logs のストリームなどの操作を制限する IAM ポリシーも必要なのでお忘れなく!