« Service Last Accessed Dataを用いたIAMポリシーからの不必要な権限の除き方 | メイン | Amazon ECS機能追加 - 新しいデプロイ機能、CloudWatchメトリクス、SingaporeとFrankfurtリージョン »

Service Last Accessed Dataを用いてIAMポリシーから不必要な権限を除くもう一つの方法

前回の記事の中で、最小権限の原則に則ったポリシーの定義に役立つ、AWS Identity and Access Management(IAM)コンソールの新機能であるService Last Accessed Dataのご紹介を致しました。その記事の中で、私はポリシー中心の方法でどのようにService Last Accessed Dataを利用するかを見せるサンプルユースケースを取り上げました。本日のブログ記事では、プリンシパル中心の方法でアプリケーションの権限を絞り込むためにどのようにService Last Accessed Dataを用いるかお見せしようと思います。

注意:この記事ではあなたが既に前回の記事を読んでいることを想定しています。そのためService Last Accessed Dataが何かということやどこで利用できるかという概要についてはスキップして、詳細から入っていきます。

プリンシパル中心のアプローチとは何か

プリンシパル中心のアプローチはユーザーやアプリケーションのプロファイルの観点から始まります。言い換えると、IAMユーザーやグループ、ロールのためのAccess Advisorタブの見方ということになります。あなたがこのアプローチを用いてService Last Accessed Dataを元に権限の変更を加える際には、他のプリンシパルがどのように影響を受けるのか考慮することが大切になります。例えばIAMユーザーのBobが、共有されている管理ポリシーにより許可されているAmazon S3に対する権限を使用しているように見えないということは、このポリシーからS3の権限をすぐに取り除いていいということにはつながりません。なぜならばユーザーアリスがS3のアクセスを必要としているかもしれないからです。

では権限管理に対するプリンシパル中心のアプローチの例を見ていきましょう。

サンプルユースケース - 進化していくアプリケーションのための権限の再編成

この例では私はアプリケーションのオーナーがアプリケーションの権限を再設定するためにService Last Accessed Dataをどのように利用するかお見せいたします。ドナは彼女のチームのAWSのインフラを管理する権限をもつDevOps管理者です。彼女の組織のウェブアプリケーションの一つが、以前はS3を使用していたものが、レコードの保管にAmazon DynamoDBを使うように最近設計しなおされました。このウェブアプリケーションはもともとの権限に加えてDynamoDBへの権限を許可するように最近修正されたapp_fooというIAMロールに依存しています。ダナはIAMコンソールに入り、Roleを見ます。ここで彼女はapp_fooロールを選択し、以下のスクリーンショットのようにAccess Advisorタブをクリックします。


ダナはService Last Accessed Dataをレビューし、DynamoDBは最近もアクセスされているものの、S3が最後にアクセスされたのは数か月前であることを発見します。ここでダナは他のサービスやユーザーのアクセス権限に不運にも影響を与えることがないことを確実にする適切な次のステップを決めなければいけません。


ダナはapp_fooロールの権限の設定を見るためにPermissionsタブに行きます。彼女が初めにこのロールに権限を与えた時、彼女は一つの包括的なポリシーの代わりに複数のより小さい管理ポリシーをアサインするmix-and-matchのモデルを使っていました。結果としてこのロールは(以下のスクリーンショットにあるように)Amazon Elastic Load Balancing、Amazon EC2、Auto Scaling、S3そしてDynamoDBへのアクセスをそれぞれ許可する分離したポリシーをもっています。今や必要のなくなったS3の権限を無効にするために、ダナはポリシーに編集を加えるよりも、最も簡易な解決法はS3への権限を許可する管理ポリシー(app_foo_s3)をデタッチすることであると理解しています。

一般的なルールとして、ユーザーやグループ、ロールに権限を与えるポリシーを見ることにより、ユーザー、グループ、ロールを調査することは良いことです。このように、あなたは疑問のある権限が必要のないものでそれゆえ安全に取り除けるものか、単にあなたが調べた特定のプリンシパルが利用していないのか確認することができます。

次のステップ

あなたはこのアプローチを、以下のような(しかしそれらに限定しない)使用していないサービスに対する多くの次のステップに向けたスタートポイントとして利用できます。

  • 管理ポリシーのデタッチ
  • 管理ポリシーの削除
  • インラインポリシーの削除とより少ない権限の管理ポリシーの作成
  • 権限を取り除くための既存のポリシーの編集
  • 既存のポリシーへの明示的な拒否の追加
  • 特定のプリンシパルのための分離したポリシーの作成
  • 何もせず、全てのプリンシパルが彼等の全ての権限を利用しないことの受容

あなたの組織のための適切さを保ちながらアクセシビリティと最小権限の正しいバランスをもつ権限管理アプローチを選択することはIAM管理者としてのあなた次第です。

 

私達はService Last Accessed Dataをどのように使うかについての感想や将来のリリースについての提案について是非お話しを伺いたいと思っています。Service Last Accessed Dataについてのコメントや使い方に関するご質問がありましたら、下記にコメントを残して頂くか、IAM Forumでスレッドを立ててください。

- Kai(日本語訳は高田智己が担当しました)

原文:https://blogs.aws.amazon.com/security/post/Tx32VKDOM82Y1NS/Another-Way-to-Remove-Unnecessary-Permissions-in-Your-IAM-Policies-by-Using-Serv

コメント

Twitter, Facebook

このブログの最新情報はTwitterFacebookでもお知らせしています。お気軽にフォローください。

2018年4 月

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30