この記事の要点
- 最小の権限とは、仕事に要る権限だけを、要る範囲で渡すことです。広い権限を広い範囲に渡すと、乗っ取られたときの被害が大きくなります。
- 人は会社の認証の仕組みと一時的な資格情報でログインし、権限は個人ではなくグループに付けます。システムには、長く使える鍵を渡さず、役割（ロール）を使います。
- 権限は一度決めて終わりではありません。使われていない権限を定期的に見つけて外し、組織全体で越えてはいけない線を別に引いておきます。
クラウドの権限管理の基本は、仕事に要る権限だけを、要る範囲で、要る期間だけ渡すことです。これを最小の権限（最小権限の原則）といいます。クラウドの管理画面や API は、インターネットのどこからでも操作できるため、権限の広いアカウントが乗っ取られると、データの持ち出しや資源の削除が一度に起こり得ます。権限を絞ることは、被害の範囲を小さくする備えです。
IAM とは
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）、Best practices for Azure RBAC（Microsoft Learn）、Use IAM securely（Google Cloud）
Google Cloud の説明では、基本ロールは、テストや開発の環境のように、広い権限を認めてよい場合には使ってもよいとされています。本番と開発で決まりを分けるためにも、環境ごとにアカウントやプロジェクトを分けておくと管理しやすくなります。分け方はアカウントの分け方。本番・検証・開発を分ける設計で説明しています。
人の権限と、システムの権限を分ける
人の権限とシステムの権限は、渡し方を分けます。
人の権限：社員は会社の認証の仕組み（ID の管理の仕組み）でログインし、クラウドには一時的な資格情報で入る形にします。権限は役割ごとのグループに付け、人はグループに入れるだけにすると、入社・異動・退職のときの作業が、グループの出し入れで済みます。管理者の権限は、普段の作業用のアカウントとは分けます。管理者のアカウントの守り方は管理者アカウントの守り方。多要素認証と緊急用のアカウントで説明しています。
システムの権限：アプリやサーバーがクラウドの資源を使うときは、AWS の IAM ロールや Google Cloud のサービスアカウントのように、システム用の仕組みを使います。AWS は、AWS の上で動く処理に、長く使える資格情報を配る必要はない、としています。プログラムの中や設定ファイルに長く使えるアクセスキーを書くと、漏れたときに悪用されるおそれがあります。キーを使わない設計はアクセスキーの漏えいを防ぐ。キーを使わない設計で説明しています。
出典：Security best practices in IAM（AWS）
使っていない権限を、外し続ける
権限は、一度決めて終わりではありません。仕事が変わっても権限が残り、時間とともに広がっていきがちです。定期的に、使われていない権限を見つけて外します。
クラウドには、そのための機能があります。AWS は、利用者・ロール・権限が最後に使われた日時の情報を提供し、不要になったものを見つけて外す助けにできるとしています。また、IAM Access Analyzer で、実際の操作の記録から最小の権限の方針を作り、試してから本番で使う方法も示しています。Google Cloud は、基本ロールを置き換えるときに、役割の推奨（ロールの推奨事項）を使って、代わりに渡す役割を決められるとしています。
出典：Security best practices in IAM（AWS）、Use IAM securely（Google Cloud）
見直しの手順と、監査で見られる点は、アクセス権の棚卸しと特権IDの管理の進め方で説明しています。
組織全体で、越えてはいけない線を引く
一人ひとりの権限とは別に、組織全体で越えてはいけない線を引いておくと、誤った権限の付け方があっても被害を抑えられます。
AWS では、組織の複数のアカウントにまたがる歯止めとして、サービスコントロールポリシー（SCP）とリソースコントロールポリシー（RCP）があります。これらは権限を与えるものではなく、与えられる権限の上限を決めるものです。また、1つのアカウントの中で権限の管理を任せるときに使う「アクセス許可の境界」も、それ自体では権限を与えないと説明されています。
出典：Security best practices in IAM（AWS）
権限を与えるものと、上限を決めるもの（AWS の例）
- 組織全体の歯止め（SCP・RCP）複数のアカウントにまたがり、与えられる権限の上限を決める。権限は与えない
- アクセス許可の境界1つのアカウントの中で権限の管理を任せるときに使う。それ自体では権限を与えない
- 一人ひとり・システムの権限実際に権限を与える。上の線の内側で、仕事に要る分だけ
歯止めは、権限の付け方を誤ったときの最後の守りです。どこに線を引くかは、業務で使うサービスとリージョンを確かめてから決め、検証の環境で試してから組織全体に広げます。
当社のご支援
アメリア・テクノロジーのクラウドの構築と運用管理では、いまの権限の洗い出し、役割とグループの設計、システム用の権限への置き換え、使われていない権限の定期的な見直しをご支援しています。権限の設定の誤りを含めたクラウドの点検は、クラウドのセキュリティ診断としてもお受けしています。当社が構築・運用している環境の診断は、自己点検として報告します。
- クラウド
- IAM
- 最小権限
- セキュリティ
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。