IAM権限の棚卸し手順｜未使用ID・最小権限・ロールの信頼条件

IAM権限の棚卸しは、IDごとに最終利用日、許す操作と資源、ロールの引き受け元を並べ、所有者と照合して不要な権限を削る作業だ。

AWSを例にすると、確かめる順番は次の4つになる。

IAM権限の棚卸しで調べる未使用ID・アクセスキー

未使用のIDとアクセスキーは、IDと長期の認証情報（アクセスキー・パスワード）の最終利用日で洗い出す。AWSは「IAMのセキュリティのベストプラクティス」で、使っていないユーザー・ロール・権限・ポリシー・認証情報を定期的に削除するよう勧めている。この段階で出すのは削除の候補で、確定は所有者の確認の後にする。

IAMの未使用ID・アクセスキー

最終利用日を確かめる情報はIDの種類で違い、どれにも限界がある。

候補が出たら、名前やタグから所有者と使うシステムを割り出す。NSAとCISAは「クラウドのIDとアクセス管理を安全に運用する」で、未使用に見える権限を外すときは、ときどき使う処理や緊急用のアクセスを考慮するよう求めている。月次・年次の処理や障害対応用のIDは、集計期間に利用がなくても、残す理由を記録して残す。

利用実態と付与権限の差

IDが使われていても、付けた権限の一部は使われずに残りうる。AWSの「最終アクセス情報」は、IDのポリシーが許すサービスごとに最後に使われた日時を示し、サービスの単位では少なくとも400日分を保持する。操作の単位の記録はサービスにより2020〜2023年に始まった。この情報には次の限界がある。

• 操作の単位で分かるのは、作成・削除・変更などの管理操作だけ。S3のオブジェクトの読み書きのようなデータ操作は入らない
• ロールをサービスに渡すiam:PassRoleは記録されない
• 拒否された試行も含む。成功したかはCloudTrailのログで確かめる
• IDに付けたポリシーが許すサービスだけを集計し、資源側のポリシーやSCPで許した分は入らない

データ操作はCloudTrailのデータイベントの記録で確かめる。PassRoleはCloudTrailにも記録されないので、設計書で確かめる。

IAM権限の棚卸しで見直すポリシーと最小権限

ポリシーは、IDごとに使う操作と対象の資源を書き出し、そこまで絞る。AWSは最小権限を、特定の資源への特定の操作だけを特定の条件で許すことと説明する。

編集上の想定として、数年前に作った外部連携用のIDに広い権限が残っているとする。連携は毎日動くので、前章の確認では候補に上がらない。連携元の侵害やキーの漏えいがあれば、そのIDが許す資源はすべて操作されうる。

IAMポリシーの操作・資源の限定

ポリシーで先に見るのは、操作が*やs3:*のようにサービス全体を許すもの、資源が*のもの、AWS管理ポリシーをそのまま付けたものだ。AWS管理ポリシーは全顧客向けで、個々の用途の最小権限にならないことがあると前述の資料にある。既存のポリシーは、100を超える検査があるポリシーの検証にもかける。グループから受け継ぐポリシーと、IDに埋め込んだインラインポリシーも見る。

絞り込みには「ポリシー生成」が使える。CloudTrailの最大90日分の記録から、そのIDが使ったサービスと操作のひな形を作り、資源名（ARN）は人が入れる。ひな形には期間内に一度も使われなかった操作が入らないので、年次の処理などは人が足す。データイベントの操作とPassRoleも入らない。

最小権限への変更と動作確認

権限を絞るときは、業務を止めない順に進める。

AWSは「アクセスキーを更新する」で、未使用と表示されたキーも先に無効化してアプリが動くか確かめ、一定期間待ってから削除するよう勧めている。ロールも、削除の前に全操作を拒否するポリシーを付け、あわせて既存のセッションを取り消して無効化できる。無効化の期間に業務が止まらなかったことを、削除の判断の根拠として記録する。

開発用の部品からクラウドの認証情報が盗まれ、持ち出された前提で対応が要った例は、LiteLLMに認証情報を盗むコードが混入した件の記事で整理している。

IAM権限の棚卸しで確認するロールの信頼ポリシーと外部連携

ロールの信頼ポリシーでは、誰がどの条件でロールを引き受けられるかを、権限とは別に棚卸しする。何ができるかは権限ポリシーが決める。権限を絞っても、信頼ポリシーが広ければ想定外の相手がその権限を使える。

IAMロールの引き受け元

信頼ポリシーの引き受け元（Principal）を、ロールごとに次の種類で一覧にする。

• 同じアカウントのユーザーやロール
• 別のAWSアカウント（委託先・SaaSの事業者など）
• AWSのサービス
• 外部のIDプロバイダー（SAML、OpenID Connect）

別のアカウントの番号は、契約中の委託先・連携先の台帳と照合する。IAM Access Analyzerの外部アクセスの分析（無料）は、組織またはアカウントの外の相手にアクセスを許す設定を検出する。ロールを引き受けられる外部の相手も対象になる。台帳にない番号と、契約を終えた相手の番号は、ロールの用途を確かめてから外す。

信頼ポリシーの条件と外部連携

引き受け元をアカウント番号で限っても、AWSが「混乱した代理問題」と呼ぶ状況は防げない。多くの顧客のロールを引き受ける事業者に、別の顧客が自社のロール名（ARN）を知って伝えると、事業者がそれで自社の資源にアクセスしてしまう。

外部の事業者に渡すロールは、事業者が顧客ごとに発行する外部ID（sts:ExternalId）を条件に入れる。外部IDは秘密の値ではなく、顧客側で決めずに事業者から受け取る。

CI/CDなどOpenID Connectのトークンで引き受けるロールは、トークンのsubを条件にする。GitHubは「Amazon Web ServicesでのOpenID Connectの構成」で、信頼していないリポジトリが使えないよう条件を1つ以上定めるよう求めている。repo:組織名/リポジトリ名:*は、そのリポジトリの全ブランチ・プルリクエスト・環境に引き受けを許す。

連携を終えたら信頼ポリシーから相手を外す。発行済みの一時的な認証情報は期限まで使えるので、AWSの「アクティブなセッションの取り消し」で、それ以前に発行された分の操作を拒否する。

IAM権限の定期的な棚卸しと更新記録

棚卸しは組織が決めた頻度で行い、退職・異動・委託や連携の終了のときにも同じ確認をする。NISTの「SP 800-53 Rev. 5」も、組織が決めた頻度での権限の見直しと、決めた期間使われていないアカウントの無効化を管理策に挙げる。

ID・キー・ポリシー・信頼先ごとに、次を記録する。

• IDの種類・所有者・使うシステムか連携先
• 最終利用日と、確かめた日・情報源
• 判断（維持・縮小・無効化・削除）と理由
• 変更前後のポリシーと引き受け元の条件
• 動作確認で許可・拒否された操作と戻す手順

未使用アクセスの分析は、タグでユーザーやロールを対象外にできる。対象外にしたIDも、理由と所有者を記録し、棚卸しのたびに確かめる。

我々は、社外から使われる経路になりうる外部連携のIDと、長期のアクセスキーを持つIDから始めるのがよいと考えている。人が使うIAMユーザーが多ければ、AWSの勧めに従いIAM Identity Centerなどの一時的な認証情報に移す。検証環境で試せない場合や、信頼条件の妥当性を自社で判断できない場合は、確かめた範囲を記録してから進め方を決める。