フローで学ぶ Cloud IAM
Google Cloud Japan Team
複数のプロジェクトやサービスが存在し、さまざまなユーザーがアクセスするクラウド環境では、誰がどのリソースに対して何ができるのかを明確にする必要があります。Google Cloud Platform（GCP）の場合は、クラウド リソースの一元管理に必要な制御や可視性を Cloud Identity and Access Management（IAM）が提供します。
Cloud IAM の実装は複数のステップに沿って行います。最初にユーザーとグループを設定します。次に、機能的役割を定義するかどうかを決め、その役割をユーザーへとマッピングします。
また、Cloud IAM にあらかじめ用意されている役割が自社のニーズに合っているかを見定め、合っていない場合は自社に合ったものを定義します。当然のことながら IAM ポリシーはテストが必要で、時間の経過に合わせて見直しも行い、自社のニーズに合っているかを継続的に確認しなくてはなりません。
こうしたステップを実行に移す際にお役に立てるよう、各ステップを組み合わせてフローチャートにしてみました。Cloud IAM を使ったことがない方も、よく使っていてちょっと復習したいという方も、このフローチャートを見れば順にやるべきことが確認できます。
以下ではフローチャート内の各ステップを掘り下げていきましょう。
ドキュメントを読む
Cloud IAM を使ったことがないのであれば、時間を作ってドキュメントに目を通すことを強くお勧めします。Cloud IAM のドキュメントは、ベスト プラクティスのガイダンスに従ううえで有用なリソースを含む包括的なガイドです。特に「役割について」というドキュメントは、Cloud IAM を学ぶのに最適な資料です。ここには使用可能な役割が GCP プロダクトごとにすべて書かれており、プロダクト独自の IAM ドキュメントを探すことも簡単です。プロダクト独自の IAM ドキュメントには、それぞれの IAM の役割に関する詳細が書かれています。
試してみる
概要を把握できたら、IAM ポリシーをどのように適用するかを実際に試してみましょう。GCP ポリシーに関するチュートリアルには、要件を IAM にマッピングする方法のセクションに加え、GCP Console を使用したチュートリアルの実装についても記載されています。ユーザーとグループを作成する
GCP では Google アカウントを使用して認証とアクセス管理を行います。このステップでのベスト プラクティスは、要件にマッチする IAM ポリシーを Google グループによって設定することです。Google グループは、複数のまとまったユーザーにアクセス ポリシーを適用するのに便利な方法です。アクセス権限の付与や変更の際に、個人ユーザーや個別のサービス アカウントのように一度に 1 つずつ行うのではなく、一度でグループ全体に適用させることができるからです。また、Cloud IAM のポリシーを更新することなく、Google グループから簡単にメンバーを追加したり削除したりすることも可能です。
階層を理解する
Cloud IAM のキーとなるコンセプトは、組織リソースから下方向に流れる階層的アプローチを採用していることです。GCP では、すべての GCP リソースをグループ化し、組織、フォルダ、プロジェクトなどのリソース コンテナへと階層的に整理することができます。次の図は、GCP 内のさまざまなリソースや階層構造を示しています。
IAM ポリシーは、組織レベル、フォルダ レベル、プロジェクト レベル、さらに（一部のケースでは）リソース レベルで設定できます。上述した「役割について」ドキュメント内にある表は、ポリシーの一部としてプロダクトの IAM の役割を組み込むことができる階層のレベルを示しています。
リソースは親ノードのポリシーを継承します。組織レベルでポリシーを適用すると、その組織の子フォルダや子プロジェクトにも親のポリシーが適用されます。同様に、プロジェクト レベルでポリシーを適用すると、同プロジェクトの子リソースにもそのポリシーが適用されます。つまりリソースのポリシーは、リソース上で適用されたポリシーと、その祖先から継承したすべてのポリシーが結合したものとなります。
機能的役割もしくはプロダクト固有の役割を定義する
IAM の実施プランには、機能的役割を使用する方法と、データまたはプロダクトの種類に応じてアクセス権を設定する方法の 2 つがあります。通常、最初にマッピングが必要な IAM ポリシーは、機能的で役割ベースのもので、たとえば既存のネットワーキングや課金の役割です。
一方、プロダクトに応じた形でアクセスを制限する場合は、特定のリソースを調べ、そのリソースに焦点を当てたポリシーの定義に重点が置かれます。たとえば、Cloud Storage の特定のバケットや、BigQuery のデータセット、Cloud Pub/Sub のトピックやサブスクリプションへのアクセスを制限するといった具合です。
カスタム ロールを定義する
事前に定義された IAM の役割が自社のセキュリティ要件に合わないときは、1 つ以上の権限を持つ独自の役割（カスタム ロール）を作成できます。カスタム ロールを作成する場合は、空の権限リストから始めるのではなく、事前定義された既存の役割に権限を追加したり、権限を削除したりする方法をお勧めします。カスタム ロールを作成すると、管理上の作業負荷が大きくなります。役割を管理する責任が生じ、新たな IAM 権限を追加する必要があります。Cloud IAM で事前定義された役割に変更が生じても、その変更内容はカスタム ロールに反映されません。IAM 権限の変更ログを使用すれば、権限変更の履歴を追跡できます。
IAM ポリシーを定義する
Cloud IAM ポリシーを定義することでユーザーに役割を付与できます。Cloud IAM ポリシーは、どのユーザーがどのタイプのアクセス権を持つかを定義したステートメントの集合です。ポリシーは、1 つまたは複数の役割に対する（アクセス権を持つ）ユーザーの一連のバインディングで構成されています。以下は JSON でのポリシーの例です。
グループを使ってメンバーを定義することもベスト プラクティスの 1 つです。ポリシーを読みやすくし、ポリシー自体を更新することなくリソースへのアクセス権を持つユーザーを簡単に調整できます。
IAM ポリシーをテストする
定義したポリシーはすべてテストしましょう。テストを行うことで、必要以上に広範なアクセス権を付与したのではないか、逆に締め付けが強すぎたのではないかなど、新しいポリシーや更新したポリシーを本番環境に適用する前に安全に確認できます。重要となるのは、どこでテストを実施するかです。ここでは専用のフォルダを使うことをお勧めします。そのフォルダは、組織レベルで割り当てられた機能的役割が明確に定義され、変更もされないということが前提となります。
プロジェクト レベルで定義されたポリシーを認証する簡単な方法は、projects.setIamPolicy メソッドのページを使うことです。このページには “Try this API” というフォームが用意されており、リクエストとレスポンスを確認できるようになっています。
このほか、IAM ポリシーのトラブルシューティングを行い、変更をシミュレートする別の方法として、Forseti Security スイートの一部である IAM Explain を使用することもできます。
バージョン管理を使う
IaC（Infrastructure as Code）は、再現性の高い一貫した構成をデプロイしているという自信をもたらすとともに、変更の監査証跡を提供し、インフラストラクチャをコードと同様に扱うことを可能にします。そしてこのアプローチでは、バージョン管理が不可欠です。Cloud IAM ポリシーはインフラストラクチャ定義の一部を形成し、バージョン管理システムの一部として使用できます。IAM ポリシーを作成する方法は以下のように複数あります。
- 純粋な JSON として記述する
- サポートされている言語の API を利用する
- Cloud Deployment Manager を利用し、宣言テンプレートとして記述する
- Terraform などのオープンソースツールを使用する
作成したポリシーは、どのフォーマットであっても、プライベートな Git リポジトリを提供する Cloud Source Repositories などのバージョン管理システムに保存できます。その後、選択したデプロイ ワークフローの一部としてリポジトリを統合できます。
ポリシーを適用する
最後に、作成したポリシーを適用します。gcloud CLI、IAM API、GCP Console、Cloud Deployment Manager、もしくは Terraform などのオープンソース ツールを使って適用できます。Terraform には、gcloud コマンドと API を使って適用できる IAM ポリシーの例が含まれています。次のステップ
フローチャートを参照すれば IAM ポリシーの論理的な適用方法を把握できますが、そこで終わりではありません。次の大きなステップは、Cloud Audit Logging をセットアップし、ポリシーを監視することです。そうすれば、GCP リソースの一元管理に必要な制御と可視性を備えた環境を構築できるでしょう。* この投稿は米国時間 3 月 8 日、Cloud Solutions Architect の Grace Mollison によって投稿されたもの（投稿はこちら）の抄訳です。
- By Grace Mollison, Cloud Solutions Architect
