はじめに
Google Cloudに限らず、システムにおいてリソースへのアクセス権限というのは必ず管理が必要なものです。
クラウド環境では、多くのユーザーがさまざまなリソースにアクセスし、異なる操作を行います。
このため、適切な権限管理がなされていないと、意図しないデータのアクセスや変更、システムの停止など、多くのリスクが生じる可能性があります。
今回のトピック
Google CloudにおいてIAMの権限は「最小権限の原則」を提唱しており、必要以上の権限を付けないようにすることが推奨されています。
この最小権限については、いくつかの切り口がありますので、それらを紹介していきます。
Google Cloudにより事前定義されているロール(編集者、ストレージ管理者など)ではなく、自身で細かくカスタマイズして作成するロールです。
例えば、CloudStorageに対して、一覧の取得は出来るが作成や変更などの操作は加えられないようにするためのカスタムロールを定義するなどです。
これにより、操作権限それ自体をより小さくすることが可能です。
どのようなカスタムロールに作り変えれば良いか分からない場合でも、IAM Recommenderがその選定をサポートします。
②リソース単位の権限
IAM権限の付与対象は、組織、フォルダ、プロジェクトといった広い範囲に限らず、「特定サービスにおける特定のリソース」に対して付与することが出来るものもあります。
例としては、CloudStorageのバケット、Artifact Registryのリポジトリ、BigQueryのデータセットやテーブルといった単位での付与です。
同一プロジェクトに構築した異なるリソースを、別の権限を持つ利用者同士で使うようにもできることになります。
これにより、権限が適用される対象リソースの範囲を小さくすることが可能です。
③IAM Conditions
IAMをさらに高度にコントロールするための機能です。
「許可ポリシー」として条件を設定し、特定の条件が満たされた場合にのみロールが有効になります。
設定できる項目としては「時間」「リソース」があります。
- 時間: 有効期限や曜日、時間帯を指定する。それに合致する間だけロールが有効になる
- リソース: リソースのタイプや名前を指定する。それに合致するリソースに対してだけロールが有効になる。
- タグ: リソースにタグを付与したうえで、そのタグを指定する。そのタグを持つリソースに対してロールが有効になる。
これにより、権限が適用される対象リソースの範囲を小さくするとともに、権限を付与しておく時間も小さくすることが出来ます。
④PAM
Priviledged Access Managerの略で、特権アクセス管理と呼ばれます。
「特権アクセス」という名前ではありますが、対象とする権限に決まりはなく、一時的に権限を付与することを目的とした機能です。
権限利用者が一時的に権限を付与してもらう申請を行い、それに対して承認者が承認を行い一時的な許可をする、という機構です。
付与できる最大の時間は24時間であるため、一時的な付与を前提としています。
これにより、権限を付与しておく時間を小さくすることが出来ます。
機能上はIAM Conditionsの時間条件による許可ポリシーと近いですが、
申請を行うという手順により運用フローを厳格化できることや、PAMでの申請はあらかじめ定義しておくものであり使いまわしができるなどで、若干の使い方の違いがあります。
機能の活用例
上記を踏まえ、きめ細かい権限付与を目指してみます。
より最小となる権限運用を考えてみると「より小さい権限を(①)、より小さい範囲に(②③)、より小さい期間で(③④)付与する」という切り口で最小にすることが出来ます。
実例としては以下のようなものが考えられるかもしれません。
ケース1: ファイアウォールルールの変更が必要になった。システムの担当者に、最小限の権限で操作をさせたい
1. 「ファイアウォールの編集」だけが出来るカスタムロールを作成。
2. PAMを作成
- PAMにて設定するIAMで「IAM Conditions」を利用し、FW名が合致することを条件とする
- 設定に必要な時間をもとに期間を指定
3. 作業者にPAMの申請操作を行わせる。承認者がPAMの申請を承認する
ケース2: 調査のため、特定のGCSバケットに対して一時的に操作を行いたい
1. 対象のGCSバケットに対するIAM権限の付与を行う
- 権限付与時に、「IAM Conditions」を利用し、必要な時間帯を設定する
期間設定においてPAMを使うかIAM Conditionsを使うかは、技術的観点よりも運用的観点での検討が良いでしょう。
以下のようなものがあるかなと思います
- 権限を必要とするのは誰か?IAM操作権限を持っているか?操作していいか?
- 「申請」というフローを回すことが出来る体制があるか?
まとめ
システムの初期構築時などには必要な権限の判別が難しく、やや大きめの権限が付与されるというのはよく聞かれるケースです。
ただし、いつまでもそのままにしておくことは大きなリスクです。
今回の4つはそれぞれの機能としては独立していますので、部分的な導入も可能です。実現できるところから徐々に入れていくのが良いでしょう。
特に、時間による制限を設ける機能は運用保守のフローを変えることにもなるでしょう。
クラウド上の権限とともに、システムにおける各人自身のロールも整理することが肝要です。
少しずつ正しい形や理想形に近づけていくのを目指していきましょう！
参考
- https://cloud.google.com/policy-intelligence/docs/role-recommendations-overview?hl=ja
- https://cloud.google.com/iam/docs/conditions-attribute-reference?hl=ja
- https://cloud.google.com/resource-manager/docs/tags/tags-supported-services?hl=ja
Google Cloud、Google Workspace に関するご相談はXIMIXへ！
Google Cloud、Google Workspaceに関する お問い合わせはこちら