クラウド

IAMとは？クラウドの権限管理を認証・認可と最小権限で解説

2026/10/13 シリーズ「クラウド入門」 第3回 / 全4回

🤖 AIを使用して執筆

IAM とは：認証と認可

IAM の働きは、認証と認可の二つに分かれる。NIST（米国国立標準技術研究所）の用語では、認証は、利用者やプロセスや機器が名乗るとおりの相手かを確かめることで、多くの場合、システムのリソースに触れさせる前に行う¹。認可は、確かめた相手に、ある対象への操作を許すか断るかを決めることである²。デジタル庁の技術レポートも同じ区別を使い、アクセスの制御は、主に認証、認可、認可の結果の施行の順に行われると書いている³。

この二つを分けて考えるのは、新しい発想ではない。Saltzer と Schroeder は 1975 年の論文の用語集で、認証（authenticate）を、要求を出している人などが誰かを確かめること、認可（authorize）を、主体（principal）にある情報への操作を許すこととして定義している⁴。主体は、権限を与える相手のことで、同じ論文はこれを、システムの中で責任を問う単位でもあると書いている⁴。

クラウドの各社の説明も、この形をとる。AWS は IAM を、誰を認証し、誰にリソースの使用を認可するかを制御するサービスと説明している⁵。Google Cloud は、どのリソースで誰が何をできるかを制御するツールと説明し⁶、総務省のガイドラインは、「誰が」「どのリソースに対し」「どのような操作ができるか」を定義し、アクセスの制御を実現するサービスとしている⁷。

IAM という語は、会社の社員の ID を一元管理する仕組み（入社や異動に合わせてアカウントを作り、消す仕組み）を広く指すこともある。本稿で扱うのは、そのうち、クラウドの事業者が提供し、リソースへの操作を許すかを決める仕組みである。

主体・権限の束・範囲：三社に共通する部品

クラウドの IAM の設定は、三つの部品の組み合わせで表される。

• 主体：権限を与える相手である。人の利用者だけでなく、人の集まりであるグループや、アプリや夜間の処理のようなプログラムも主体になる。Google Cloud はプリンシパル、Azure はセキュリティ プリンシパルと呼ぶ⁶⁸。
• 権限の束：「写真を読む」「写真を置く」のような個々の操作の許可を束ねたものである。Google Cloud と Azure は、これをロールと呼ぶ（Azure の正式な名前はロール定義）⁶⁸。AWS では、ポリシーと呼ぶ文書に、どのリソースに、どの条件で、どの操作を許すかを書く⁹。
• 範囲：権限が及ぶリソースである。会社全体か、ある部門のプロジェクトか、一つのバケットかを指定する。

この三つを組み合わせて、「誰に、どの範囲で、どの権限を与えるか」を一行ずつ決めていく。Azure は、ロールの割り当てがセキュリティ プリンシパル、ロール定義、スコープ（範囲）の三つの要素からなると明記している⁸。Google Cloud も、権限を与える相手、与える権限の集まり、アクセスさせるリソースの三つで説明する⁶。

ロールという語は、AWS では別のものを指すので注意がいる。AWS のロールは権限の束ではなく、主体の一つである。人のための IAM ユーザーと同じく、ポリシーを付けて権限を持たせる ID だが、特定の一人には結びつかず、必要な人やプログラムが一時的に使う¹⁰。

範囲には階層がある。Google Cloud では、会社全体を表す組織の下にフォルダがあり、その下にプロジェクトがある。上の階層に許可を設定すると、その下のすべてのリソースにも同じ許可が及ぶ。Google はこれをポリシーの継承と呼んでいる⁶。Azure も、管理グループ、サブスクリプション、リソース グループ、リソースの四つの階層でスコープを指定でき、それぞれが親子の関係にあると説明している⁸。AWS では、アカウントそのものが一つの区切りになる。複数のアカウントをまとめる AWS Organizations では、アカウントをまたいで、実行できる操作の上限を決めるポリシー（サービスコントロールポリシー）を設定できる¹¹。このポリシーは上限を決めるだけで、それ自体は権限を与えない¹²。

階層は、管理を楽にする一方で、権限を広げすぎる原因にもなる。上の階層で一度与えた権限は、下のすべてに及ぶからである。NSA と CISA の 2024 年の文書は、最小権限の原則に従うよう求めたうえで、多くのクラウドの事業者が階層型の権限の仕組みを使っていることに注意するよう書いている¹³。

三社の製品の名前でいえば、AWS は AWS IAM、Azure はロールの割り当てを Azure RBAC で行い、人の ID は Microsoft Entra ID（2023 年に Azure AD から改名）で管理する¹⁴。Google Cloud は、そのまま IAM と呼ぶ⁶。部品の名前は違っても、主体、権限の束、範囲の三つで考えれば、どの製品の設定も同じ形で読める。

最小権限の原則：1975 年からある設計の原則

誰にどこまでの権限を与えるかについて、最も基本になる原則が、最小権限の原則である。

1971 年、Lampson は、計算機の中の保護を、ドメイン（今日の言葉でいう主体にあたる）を行に、守る対象を列にとった表として整理した¹⁵。表のマス目には、その行のドメインが、その列の対象に何ができるかを書く。この表はアクセス行列と呼ばれ、今日の IAM の設定も、この表のマス目を一つずつ埋める作業と見ることができる。

1975 年、Saltzer と Schroeder は、保護の仕組みを設計するときの原則の例を八つ挙げた⁴。その一つが最小権限で、すべてのプログラムと利用者は、仕事を終えるのに必要な最小限の権限で動くべきだとする⁴。理由として二人が挙げたのは、事故や誤りが起きたときの被害を限ることである⁴。同じ論文は、軍の「知る必要のある者だけが知る」という規則をこの原則の例として挙げ、さらに、Glaser が 1965 年に示したものとして、既定は「許さない」とし、許す条件だけを書くべきだという原則も挙げている⁴。これらは、二人が提案した設計の原則で、実験で確かめた結果ではない。

1992 年には、NIST の Ferraiolo と Kuhn が、利用者に直接権限を与える代わりに、組織の中の役割に権限をまとめ、その役割を利用者に割り当てる方法を提案した¹⁶。ロールに基づくアクセス制御（RBAC）である。二人の論文も、利用者には仕事に必要な以上の権限を与えないという最小権限の原則を、前提として書いている¹⁶。NIST の RBAC のモデルは、2004 年に米国の標準になった¹⁷。Azure の権限の仕組みの名前（Azure RBAC）は、この考え方の名前をそのまま使っている⁸。

最小権限の原則は、いまも公的な基準に入っている。NIST のセキュリティの管理策の一覧 SP 800-53 は、利用者と、利用者のために動くプロセスに、割り当てられた仕事に必要なアクセスだけを許すよう求めている¹。デジタル庁の技術レポートは、最小権限の原則を、職種や役職などに応じて、与えるアクセス権限を必要最小限にする原則と定義している³。

クラウドの事業者も、この考え方を製品に取り込んできた。AWS は、2010 年 9 月に IAM を試験提供として公開し、2011 年 5 月に一般提供を始めた¹⁸¹⁹。試験提供の告知は、IAM によってパスワードやアクセスキーを共有する必要がなくなると説明している¹⁸。全員で一つの鍵を使う状態をなくすことが、AWS の IAM の出発点だったことになる。Google Cloud の IAM は、2016 年 5 月に一般提供になった²⁰。

なぜクラウドで権限が守りの中心になるのか

自社のサーバー室では、建物と社内のネットワークの外からは機械に届かないので、その境界を固めることが防御の中心だった。Microsoft は、自社でサーバーを持つ環境では、ネットワークが主なセキュリティの境界だったと書いている²¹。

クラウドでは、この前提が変わる。NIST の定義によれば、クラウドの資源はネットワークを通じて使え、利用者は事業者の担当者とやり取りせずに、自分で設定を変えられる²²。資源の用意も設定の変更も、正しい資格情報があればネットワーク越しにできる。そのため、資格情報と、それに与えた権限が、防御の要になる。Microsoft は、PaaS ではアイデンティティを主なセキュリティの境界と考えるよう勧めている²¹。別のページでは、多くの人がアイデンティティを主な境界と考えており、従来のネットワークのセキュリティを中心とする考え方からの転換だ、と書いている²³。

この考え方は、ゼロトラストと呼ばれる設計の考え方とも重なる。NIST の 2020 年の文書は、ゼロトラストでは、ネットワーク上の位置だけを根拠に信頼を与えないとし、リソースへのアクセスは、セッション（一続きのやり取り）ごとに信頼できるかを確かめてから、作業に必要な最小限の権限で与えるべきだと書いている²⁴。

長く使える鍵と、期限の短い資格情報

権限の範囲と並んで大事なのが、資格情報の期限である。

最も強い資格情報は、契約を作ったときの最初のアカウントである。AWS では、このアカウントはルートユーザーと呼ばれ、すべてのサービスとリソースに完全にアクセスできる。AWS は、日常の作業にルートユーザーを使わないよう強く勧めている⁵。

プログラムが使う資格情報にも注意がいる。アクセスキーのように、一度作ると消すまで使える資格情報は、漏れたときの被害が長く続く。Google Cloud は、サービスアカウント（プログラムのためのアカウント）の鍵は、作ってダウンロードした既定の状態では期限がなく、消すまで有効だと説明し、できる限りこの鍵を使わずに、別の方法で認証するよう勧めている²⁵。AWS の IAM のロールには、パスワードやアクセスキーのような長期の資格情報がなく、ロールを使うときには、その使用のあいだだけ有効な一時的な認証情報が発行される¹⁰。AWS は、人の利用者にも、プログラムにも、一時的な認証情報を使うよう求めている⁹。

NSA と CISA の文書も、秘密の鍵は必要なときだけ使い、短い期間のアクセスに限り、必要最小限の権限で発行するよう勧めている¹³。人の利用者には、フィッシング（偽のログイン画面などでパスワードをだまし取る手口）に強い多要素認証を求めている¹³。多要素認証は、パスワードに加えて、手元の端末など別の手段でも本人を確かめる仕組みである。総務省のガイドラインは、特権を持つアカウントの利用者を最小限にし、その管理では多要素認証と、複数の人で確かめる体制を整えるよう書いている⁷。

社員 30 人ほどの家具の通販の会社なら、ここまでの考え方は、たとえば次のような設定になる。

• 管理者のアカウントには多要素認証をかけ、日常の作業には使わない。
• 開発の担当者、経理の担当者、制作会社の担当者には、それぞれ自分の ID を作り、仕事に合った権限だけを与える。制作会社には、写真のバケットに置くことだけを許す。
• 注文を処理するプログラムには、長く使えるアクセスキーを渡さず、期限の短い資格情報を自動で受け取る仕組み（AWS ならロール）で動かす。

一度にすべてを整える必要はない。後で見るように、AWS も、広めの権限から始めて、使い方が分かるにつれて絞っていく進め方を示している。

公的な記録に見る権限の事故

権限の与え方が被害の大きさを決めた例は、規制当局や裁判所の文書に記されている。

一つ目は Uber である。FTC の 2018 年の訴状によれば、Uber は 2014 年 9 月ごろまで、Amazon S3 のデータの保存先を使うすべてのプログラムと技術者に、すべてのデータへの完全な管理者の権限を持つ、一つのアクセスキーを共有させていた²⁶。2014 年 5 月、侵入者は、技術者の一人がコード共有サイトの GitHub に公開していたアクセスキーで保存先に入り、運転手の個人情報を含むファイルにアクセスした。公開された鍵は、保存先のすべてのデータへの完全な管理者の権限を持っていた²⁶。2016 年にも、侵入者はアクセスキーで保存先に入った。今度の鍵は、GitHub の非公開のリポジトリ（プログラムのコードを置く保管場所）のコードに、暗号化されないまま書かれていた。侵入者は、ほかの大規模な漏洩で出回ったパスワードで Uber の GitHub に入り、そこで鍵を見つけたと述べている。FTC は、Uber が技術者にパスワードの使い回しを禁じておらず、GitHub での多要素認証も求めていなかったと指摘している²⁶。2016 年の侵入でダウンロードされたファイルには、約 2560 万件の名前とメールアドレスなどの個人情報が含まれていた²⁶。

二つ目は、2019 年の Capital One である。連邦捜査局（FBI）の捜査官が起訴の前に裁判所に出した刑事告訴状によれば、ウェブアプリケーション・ファイアウォール（WAF、ウェブへの攻撃を防ぐ仕組み）の設定の誤りから、外から送った命令がサーバーで実行できる状態になっていた²⁷。攻撃者は、一つ目の命令で、「＊＊＊＊＊-WAF-Role」という名のロールの資格情報を手に入れた（名前の一部は告訴状で伏せられている）。二つ目の命令で、そのロールを使ってバケットの名前の一覧を取り、三つ目の命令で、そのロールに権限があったバケットからデータを写した。攻撃者のファイルには、700 を超えるバケットの名前の一覧も入っていた²⁷。告訴状は、Capital One の説明として、このロールは通常の業務ではバケットの一覧を取る操作をしないと書いている²⁷。司法省は 2022 年、この事件の影響が米国の 1 億人を超える顧客に及んだと発表した²⁸。

名前からするとファイアウォールのためのロールが、なぜバケットのデータを写せる権限を持っていたのかについて、公開の文書は理由を書いていない。告訴状から分かるのは、通常の業務では使わない一覧の操作が、このロールでは実行できたことである。少なくともこの操作については、仕事に要らない権限が与えられていたことになる。一方、データを写す権限のうち、どこまでが業務に必要だったのか、権限を絞っていれば被害がどれだけ減ったのかは、公開の文書からは判断できない。はっきりしているのは、漏れた資格情報で何ができるかが、そのロールに与えた権限で決まるということである。

外から見た最小権限の原則

最小権限の原則を支持する見方は、設定の誤りが避けられない以上、誤りが起きたときの被害を限ることに価値を置く。NSA と CISA の 2024 年の文書は、IAM はクラウドの資源を守るうえで欠かせないが、利用者はアクセスの制御を誤って設定し、意図せず資源を誰でも見られる状態にしやすく、そうした誤りはよくあることで、大量のデータの漏洩を起こしてきたと書いている¹³。そのうえで、最小権限と職務の分離の原則を慎重に当てはめ、権限の割り当てとアクセスの要求を監査するよう求めている¹³。総務省のガイドラインも、プログラムが使うアクセスキーの管理が不十分だと、システム全体の乗っ取りのような危険があると書き、ゲストの利用者には必要最小限の権限を与えるよう求めている⁷。

留保を付ける見方は、二つある。一つは、最小権限は一度の設定で完全にできるものではない、という見方である。AWS は、必要な権限を探るあいだは広い権限から始め、使い方が固まるにつれて権限を減らし、最小権限に近づけていく進め方を示している⁹。最小権限は、運用しながら近づけていく目標だということになる。

もう一つは、権限だけでは事故の全体を説明できないという点である。Capital One に 8000 万ドルの民事制裁金を科した米通貨監督庁（OCC）の命令は、権限の設定には触れていない。OCC が挙げたのは、クラウドへ移る前のリスクの評価、ネットワークのセキュリティの管理、データの流出を防ぐ管理、警報への対応の不備に加え、内部監査が多くの弱点を見つけられなかったことと、取締役会が経営陣の責任を十分に問わなかったことである²⁹。権限を絞ることは、単独でも被害を限る。ただ、ネットワークの守りや、異常に気づく仕組み、組織の監督と組み合わせて、効果が大きくなる。

並べると、どの見方も、権限を必要な範囲に絞ること自体には異論がない。違いは、それをどこまで最初から求め、ほかの守りとどう組み合わせるかにある。Capital One の事件の入口は、WAF の設定の誤りで、外から送った命令がサーバーに届いてしまったことだった。権限を絞っても、ネットワークの入口が開いていれば、外からの要求は届く。クラウドの上でネットワークをどう区切り、どこを外に開くのかが、次の問いである。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。