「Patch Managerのために必要な最低限の権限ってどれなんだろう」〜 IAM Access Analyzer で本当に必要な最小権限を実現する〜

はじめに

西藤です。

情報システム上のアクセス権限の運用において度々目にする言葉として「最小権限の原則」というものがあります。

「権限の付与は最小限のものから付与していき、必要に応じて追加していく。そして不要な時には権限を破棄する」ということが言われており、情報セキュリティにおいては重要な原則です。

ただし、この原則にしたがっていきますとシステムの立ち上げ段階においては

はじめにAが動作できなかったから権限を足して、

次にBも必要だから権限を足して、

そしたら、Cもうまくいかなかったから権限を足して・・・・

という具合に、希望の動作ができる権限構成になるまでに時間を要してしまうことが多々あり得ます。

もちろん、順次足していくことがもっとも推奨されるやり方ではありますが、開発進行における障壁となる場合があります。

そこで参考にしたいのがAWSの公式ドキュメントにおけるIAMのベストプラクティスでの記載で

• 「アクセスアクティビティに基づくポリシーの生成」¹

があります。

利用履歴に基づいてポリシーを生成し、それを適用していくことでより小さな権限構成を実現しよう。というアプローチです。

たとえば、「直近30日間運用してみて、実際に利用履歴のあった権限だけに絞る」と言うことが考えられます。

これは、運用のはじめに比較的緩めの権限を付与することにはなります。しかし「Aができなかった次は、Bもできなくて・・・」という具合に、都度都度、権限を足していくことを求められる状況と比べると、かなり現実的なアプローチです。

今回は、「アクセスアクティビティに基づくポリシーの生成」におけるツールとしてAWSのベストプラクティス資料上でも言及されている"IAM Access Analyzer"を使って、

Systems Manager Patch Managerをログ書き込みも含めて運用するために必要な権限だけを付与する

と言うシナリオの実践例を記載したいと思います。

本記事が「アクセスアクティビティに基づくポリシーの生成」のアプローチで最小権限を実現していくための方法の参考にになれば幸いです。

※なお、「Systems Manager Patch Managerを使ったパッチ適用のやり方」自体は割愛いたします。

マネージドポリシー"AmazonSSMManagedInstanceCore"について

まず始めに、適切な権限の付与をしていく上で検討したいのが、マネージドポリシーです。

Systems Managerを使うためのマネージドポリシーとしてAmazonSSMManagedInstanceCoreが提供されています。

これはAWSのドキュメントでの解説にて

この AWS マネージドポリシーにより、インスタンスは Systems Manager サービスコア機能を使用できます。²

とあるように、Systems Managerを使う上での最低限の権限セットが提供されているので、1からポリシー設計をする手間を省くことができます。

これを活用することで、このような権限になります。

これだけでもSystems Managerの動作はできるようになり、パッチ適用は行えるようになります。

動作確認してみましょう。

"AmazonSSMManagedInstanceCore"だけの状態の動作確認

パッチ適用のやり方自体は割愛しますが、

• Amazon Linux 2の古いマシンイメージを使ってEC2インスタンスを立ち上げる（つまりパッチ適用対象のパッケージが多くある）
• そのインスタンスに対してPatch Managerでの実施結果の確認（配信されているすべてのパッチを適用する）

を行なった結果が以下の通りです。

Systems Managerでの表示：

→コマンド実行が成功している

インスタンス内：

→"No packages marked for update"の表示となっており、すべてのパッチが適用されている状態。

以上の通り、パッチ適用の実施だけであればマネージドポリシー AmazonSSMManagedInstanceCoreを使うだけで実現できると言うことがわかります。

しかし、この権限構成だけですと権限の不足によりSystems Managerによるコマンド実行のログをCloudWatch Logsに書き出せず履歴を見ることができません。

「ログをここから見る」旨が表示されているが・・・

→「該当のロググループが存在しない」とのエラーになる。

この状態からCloudWatch Logsにログ書き込みをできるように権限設定を進めていきます。

マネージドポリシー"CloudWatchLogsFullAccess"を付与

まずは正常に動作するために制約のゆるい形で権限を付与します。

具体的にはマネージドポリシーのCloudWatchLogsFullAccessを追加します。

では、このように権限を付与した上でSystems ManagerのPatch Managerを使うとどうなるか。結果は以下の通りです。（上記とまったく同じ構成のEC2インスタンスを新設して、実行しました。）

Systems Managerでの表示：

→コマンド実行が成功している

インスタンス内：

→"No packages marked for update"の表示となっており、すべてのパッチが適用されている状態。

CloudWatch Logs：

→該当のロググループ上にログが書き込まれている。

以上の通り、マネージドポリシー"CloudWatchLogsFullAccess"を付与することでログ書き込みが実現できました。

しかし、このマネージドポリシーは、"FullAccess"の名の通り、"CloudWatch Logs"のサービスに絞り込まれてはいますが、その中での全アクションが許可されている構成です。

そのため、作成済みのログやロググループを削除できる権限も含まれているので、「ログ書き込みできるようにしたい」と言う目的からすると過剰に権限を与えてしまっており、「最小権限の原則」からは逸脱しています。

この状態から「利用実態のあるアクションだけ」を許可するようにするため、IAM Access Analyzerを使ってポリシー生成をします。

IAM Access Analyzerでポリシー生成

IAM Access Analyzerでのポリシー生成を行うためには、該当のIAMロールの画面で「CloudTrailイベントに基づいてポリシーを生成」の欄にあるボタンから開始できます。

利用実態を分析するためのCloudTrailのtrailと、その分析期間を指定します。

「ポリシーを作成」を押して、リクエストを行うと分析が開始された旨の表示になります。

生成が完了すると「成功」の表示となるので、「生成されたポリシーを表示」を開く

するとポリシー生成をするウィザードに入ります。

指定期間中に検出されたアクションの内訳が表示されるほか、それ以外にもアクションを追加できます。

たとえば、「アクションが検出されなかったけど、権限が必要になることがわかっている」と言うようなアクションを追加できます。

今回は「CloudWatch Logsにログ書き込みをすること」が目的なのに、検出されていなかった"PutLogEvents"を追加します。

次にjson形式のポリシーの編集画面に入ります。

直前の画面で表示されていた各サービスごとのアクションが含まれていることがわかります。

また、Resourceの部分は ${Region},${Account}などのような形でプレースホルダーになっており、そのままでは使うことができません。

今回は「CloudWatch Logsにログを書き込めるようにしたい」と言うのが目的でしたので、次の編集をします

• CloudWatch Logsの以外のサービス用のブロックは削除
• プレースホルダーでの記述が入っていたResourceの部分でリージョンを東京リージョンに指定
• プレースホルダーでの記述になっていたAWSアカウントID部分を自分のAWSアカウントIDに指定

「次へ」を押下して画面をすすめるとIAMポリシーの作成確定画面になります。作成と同時に該当のIAMロールに付与するオプションもあるのでそのまま確定します。

このように該当のロールには生成されたポリシーがアタッチされています。

これにより、"CloudWatch Logs"に関する「必要最低限」の権限を適用することができたので、元々つけていたCloudWatchLogsFullAccessのポリシーは外すことができます。

最終版

以上の設定を踏まえて、最終的に該当のロールについている権限は次のようになります。

元々、FullAccessでつけていたCloudWatch Logs用の権限が利用実績に合わせて必要最低限の権限に絞ることができました。

詳細は割愛しますが、この新たな権限構成でも同じようにパッチ適用とCloudWatch Logsのログ書き込みが行われることが確認できました。

まとめ

以上、 IAM Access Analyzerを使って、「アクセスアクティビティに基づくポリシーの生成」のアプローチで最小権限を実現する方法を紹介しました。

本来あるべき姿としては、FullAcceessで権限を付与してしまうのは好ましくなく、小さな権限から付与していくのが理想です。

しかし、稼働を始めてしまっているシステムにて、意図せず大きな権限を付与していたことに気づき、権限を絞り込んでいきたい時など、AWSが提供しているこういったツールは積極的に活用していきたいところです。

残念ながら、100%ツールに任せっきりとはいかず、IAMポリシーの構成を理解しながら自分でも補完する必要はありましたが、付与済みの権限を絞り込んでいく際に使うものとしては非常に便利なツールだと感じました。

権限管理のベストプラクティスに準じて、適切なIAMポリシーの構成管理をしていく上で、本記事が参考になれば幸いです。

参考資料

1. https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html#grant-least-privilege↩
2. https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/setup-instance-profile.html#instance-profile-policies-overview↩

sho