--- title: "クラウドの権限管理（IAM）の基本。最小の権限とは｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/cloud-iam-least-privilege/ description: "クラウドの権限管理（IAM）は、誰が、どの資源に、何をしてよいかを決める仕組みです。最小の権限の考え方、AWS・Azure・Google Cloud の公式の推奨、人とシステムの権限の分け方、使っていない権限を外し続ける方法、組織全体の歯止めを説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # クラウドの権限管理（IAM）の基本。最小の権限とは クラウドの権限管理（IAM）は、誰が、どの資源に、何をしてよいかを決める仕組みです。最小の権限の考え方、AWS・Azure・Google Cloud の公式の推奨、人とシステムの権限の分け方、使っていない権限を外し続ける方法、組織全体の歯止めを説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - 最小の権限とは、仕事に要る権限だけを、要る範囲で渡すことです。広い権限を広い範囲に渡すと、乗っ取られたときの被害が大きくなります。 - 人は会社の認証の仕組みと一時的な資格情報でログインし、権限は個人ではなくグループに付けます。システムには、長く使える鍵を渡さず、役割（ロール）を使います。 - 権限は一度決めて終わりではありません。使われていない権限を定期的に見つけて外し、組織全体で越えてはいけない線を別に引いておきます。 クラウドの権限管理の基本は、仕事に要る権限だけを、要る範囲で、要る期間だけ渡すことです。これを最小の権限（[最小権限の原則](https://www.ameliatechnology.co.jp/glossary/least-privilege/)）といいます。クラウドの管理画面や API は、インターネットのどこからでも操作できるため、権限の広いアカウントが乗っ取られると、データの持ち出しや資源の削除が一度に起こり得ます。権限を絞ることは、被害の範囲を小さくする備えです。 ## IAM とは [IAM](https://www.ameliatechnology.co.jp/glossary/iam/)（Identity and Access Management）とは、誰が（人やシステム）、どの資源に対して、どの操作をしてよいかを決めて管理する仕組みです。AWS・Microsoft Azure・Google Cloud のいずれにも IAM の仕組みがあり、名前や細かい作りは違いますが、考え方は共通しています。 権限を決めるときは、次の3つを組み合わせて考えます。 - **誰に**：人のアカウント、グループ、システム（アプリやサーバー） - **何を**：読むだけか、変更や削除もできるか - **どこで**：組織全体か、1つのアカウント・サブスクリプション・プロジェクトか、1つの資源か ## 3つのクラウドの公式の推奨 3つのクラウドの公式の推奨には、共通する点が多くあります。 | クラウド | 公式の推奨の要点 | |---|---| | AWS | 作業に要る権限だけを渡す。人は外部の認証の仕組みと一時的な資格情報でログインする。システムは IAM ロールの一時的な資格情報を使い、長く使える資格情報を配らない。多要素認証を求める。使われていない利用者・ロール・権限・資格情報を定期的に見直して外す | | Microsoft Azure | 最小の権限を渡し、便利に見えても広い役割を広い範囲に割り当てない。サブスクリプションの所有者は最大3人まで。役割は個人ではなくグループに割り当てる。特権は Privileged Identity Management で必要なときだけ渡す。独自の役割では、操作をワイルドカード（*）でまとめずに明示する | | Google Cloud | 本番の環境では、ほかに方法がない場合を除き、基本ロール（オーナー・編集者・閲覧者）を渡さない。役割は必要な最小の範囲で渡す。役割は個人ではなくグループに渡す。アプリの部品ごとに別のサービスアカウントを使う | 出典：[Security best practices in IAM（AWS）](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)、[Best practices for Azure RBAC（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices)、[Use IAM securely（Google Cloud）](https://docs.cloud.google.com/iam/docs/using-iam-securely) Google Cloud の説明では、基本ロールは、テストや開発の環境のように、広い権限を認めてよい場合には使ってもよいとされています。本番と開発で決まりを分けるためにも、環境ごとにアカウントやプロジェクトを分けておくと管理しやすくなります。分け方は[アカウントの分け方。本番・検証・開発を分ける設計](https://www.ameliatechnology.co.jp/blog/cloud-account-structure/)で説明しています。 ## 人の権限と、システムの権限を分ける 人の権限とシステムの権限は、渡し方を分けます。 **人の権限**：社員は会社の認証の仕組み（ID の管理の仕組み）でログインし、クラウドには一時的な資格情報で入る形にします。権限は役割ごとのグループに付け、人はグループに入れるだけにすると、入社・異動・退職のときの作業が、グループの出し入れで済みます。管理者の権限は、普段の作業用のアカウントとは分けます。管理者のアカウントの守り方は[管理者アカウントの守り方。多要素認証と緊急用のアカウント](https://www.ameliatechnology.co.jp/blog/protecting-admin-accounts/)で説明しています。 **システムの権限**：アプリやサーバーがクラウドの資源を使うときは、AWS の IAM ロールや Google Cloud のサービスアカウントのように、システム用の仕組みを使います。AWS は、AWS の上で動く処理に、長く使える資格情報を配る必要はない、としています。プログラムの中や設定ファイルに長く使える[アクセスキー](https://www.ameliatechnology.co.jp/glossary/access-key/)を書くと、漏れたときに悪用されるおそれがあります。キーを使わない設計は[アクセスキーの漏えいを防ぐ。キーを使わない設計](https://www.ameliatechnology.co.jp/blog/access-key-leak-prevention/)で説明しています。 出典：[Security best practices in IAM（AWS）](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) ## 使っていない権限を、外し続ける 権限は、一度決めて終わりではありません。仕事が変わっても権限が残り、時間とともに広がっていきがちです。定期的に、使われていない権限を見つけて外します。 クラウドには、そのための機能があります。AWS は、利用者・ロール・権限が最後に使われた日時の情報を提供し、不要になったものを見つけて外す助けにできるとしています。また、IAM Access Analyzer で、実際の操作の記録から最小の権限の方針を作り、試してから本番で使う方法も示しています。Google Cloud は、基本ロールを置き換えるときに、役割の推奨（ロールの推奨事項）を使って、代わりに渡す役割を決められるとしています。 出典：[Security best practices in IAM（AWS）](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)、[Use IAM securely（Google Cloud）](https://docs.cloud.google.com/iam/docs/using-iam-securely) 見直しの手順と、監査で見られる点は、[アクセス権の棚卸しと特権IDの管理の進め方](https://www.ameliatechnology.co.jp/blog/access-review-privileged-id/)で説明しています。 ## 組織全体で、越えてはいけない線を引く 一人ひとりの権限とは別に、組織全体で越えてはいけない線を引いておくと、誤った権限の付け方があっても被害を抑えられます。 AWS では、組織の複数のアカウントにまたがる歯止めとして、サービスコントロールポリシー（SCP）とリソースコントロールポリシー（RCP）があります。これらは権限を与えるものではなく、与えられる権限の上限を決めるものです。また、1つのアカウントの中で権限の管理を任せるときに使う「アクセス許可の境界」も、それ自体では権限を与えないと説明されています。 出典：[Security best practices in IAM（AWS）](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 権限を与えるものと、上限を決めるもの（AWS の例） - **組織全体の歯止め（SCP・RCP）**：複数のアカウントにまたがり、与えられる権限の**上限**を決める。権限は与えない - **アクセス許可の境界**：1つのアカウントの中で権限の管理を任せるときに使う。それ自体では権限を与えない - **一人ひとり・システムの権限**：実際に権限を与える。上の線の内側で、仕事に要る分だけ 歯止めは、権限の付け方を誤ったときの最後の守りです。どこに線を引くかは、業務で使うサービスとリージョンを確かめてから決め、検証の環境で試してから組織全体に広げます。 ## 当社のご支援 アメリア・テクノロジーの[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)では、いまの権限の洗い出し、役割とグループの設計、システム用の権限への置き換え、使われていない権限の定期的な見直しをご支援しています。権限の設定の誤りを含めたクラウドの点検は、[クラウドのセキュリティ診断](https://www.ameliatechnology.co.jp/service/cloud/)としてもお受けしています。当社が構築・運用している環境の診断は、自己点検として報告します。 - クラウド - IAM - 最小権限 - セキュリティ ## この記事に出てくる用語 - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [最小権限の原則](https://www.ameliatechnology.co.jp/glossary/least-privilege/) - [API](https://www.ameliatechnology.co.jp/glossary/api/) - [インターネット](https://www.ameliatechnology.co.jp/glossary/internet/) - [IAM（IDとアクセスの管理）](https://www.ameliatechnology.co.jp/glossary/iam/) - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [Microsoft Azure](https://www.ameliatechnology.co.jp/glossary/azure/) - [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/) この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/) - [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/) - [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/) [クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### クラウドの構築と運用を任せる AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。 [クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/) ### クラウドの状態を、無料で確かめる 15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。 [クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「クラウドの権限管理（IAM）の基本。最小の権限とは｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/cloud-iam-least-privilege/