IAM の安全な使用

はじめに

このページでは、IAM を使用する際に留意いただく必要があるセキュリティに関するベスト プラクティスをご紹介します。

このページは IAM に精通しているユーザーを対象としています。IAM を使い始めたばかりの方は、こちらの説明をお読みいただいても IAM の使い方は書かれていないため、IAM クイックスタートをまずお読みください。

最小限の権限

❑ 基本ロールには、すべての Google Cloud サービスにかかわる多くの権限が含まれます。本番環境では、他に選択肢がない限り、基本ロールを付与しないでください。代わりに、ニーズに合わせて最も制限された事前定義ロールまたはカスタムロールを付与します。 基本の役割を置き換える必要がある場合は、IAM Recommender を使用して、付与する役割を決定できます。また、ポリシー シミュレータを使用して、役割を変更してもメンバーのアクセス権に影響が生じないようにすることもできます。 次のような場合には、基本ロールの付与をおすすめします。 Google Cloud サービスで事前定義ロールを利用できない場合。使用可能なすべての事前定義済み役割のリストについては、事前定義済みの役割の表をご覧ください。 プロジェクトに関する幅広い権限を付与する必要がある場合。この状況は、開発環境またはテスト環境で権限を付与する場合によく生じます。 メンバーがきめ細かい権限を必要としない小規模なチームで働いている場合。

❑ アプリケーションの個々のコンポーネントは個別の信頼境界として扱ってください。異なる権限を必要とする複数のサービスがある場合は、サービスごとに個別のサービス アカウントを作成した後で、各サービス アカウントに必要な権限のみを付与します。

❑ 子リソースのポリシーは親リソースから継承されることにご注意ください。たとえば、プロジェクトのポリシーでユーザーに Compute Engine 仮想マシン（VM）インスタンスを管理する権限が付与されている場合、ユーザーは各 VM で設定したポリシーに関係なく、そのプロジェクトのすべての Compute Engine VM を管理できます。

❑ 必要最小限の範囲のロールを付与します。たとえば、Pub/Sub トピックをパブリッシュするアクセス権だけを必要とするユーザーには、そのトピックのパブリッシャーのロールを付与します。

❑ サービス アカウントとして活動できるメンバーを指定します。サービス アカウントに対するサービス アカウント ユーザーのロールを付与されたユーザーは、そのサービス アカウントがアクセス権を持つすべてのリソースにアクセスできます。そのため、サービス アカウント ユーザーのロールをユーザーに付与する際は十分な注意が必要です。

❑ プロジェクトのサービス アカウントの作成と管理ができる権限を持つユーザーを指定します。

❑ プロジェクト IAM 管理者およびフォルダ IAM 管理者の事前定義ロールを付与すると、すべてのリソースを直接読み取り、書き込み、管理するアクセス権を許可することなく、IAM ポリシーを変更するためのアクセス権を付与できます。 メンバーにオーナー（roles/owner）のロールを付与すると、ほぼすべてのリソースにアクセスして変更する権限（IAM ポリシーの変更を含む）を付与することになります。この権限の範囲の広さには、潜在的な危険も潜んでいます。オーナー（roles/owner）の役割は、（ほとんど）ユニバーサルなアクセス権が必要な場合にのみ付与してくだい。

サービス アカウントとサービス アカウント キー

❑ IAM Service Account API を使用して、サービス アカウント キーをローテーションします。キーをローテーションするには、新しいキーを作成し、新しいキーを使用するようにアプリケーションを切り替えてから、古いキーを削除します。serviceAccount.keys.create() メソッドと serviceAccount.keys.delete() メソッドを一緒に使用して、ローテーションを自動化します。

❑ プロセスの実装では、ユーザーが管理するサービス アカウント キーを管理します。

❑ 暗号化キーとサービス アカウントキーを混同しないように注意してください。一般的に、暗号鍵はデータの暗号化に使用され、サービス アカウント キーは Google Cloud APIs への安全なアクセスのために使用されます。

❑ インスタンスを実行するために使用中のサービス アカウントを削除しないでください。これを削除すると、先に別のサービス アカウントを使用するよう移行していなかった場合に、アプリケーションの全体または一部が失敗することがあります。

❑ サービス アカウントの表示名を使用して、そのアカウントの用途やアカウントに必要な権限を管理できるようにします。

❑ サービス アカウント キーをソースコードに組み込んだり、ダウンロード ディレクトリに置いたままにしたりしないでください。

監査

❑ Cloud Audit Logs のログを使用して、IAM ポリシーの変更を定期的に監査します。

❑ Cloud Storage に監査ログをエクスポートして、ログを長期間保存します。

❑ プロジェクトの IAM ポリシーを変更できるユーザーの管理状況を監査します。

❑ Logging のロールを使用して、ログへのアクセスを制限します。

❑ ログ閲覧者に適用されるのと同じアクセス ポリシーを、ログのエクスポートに使用する Google Cloud リソースに適用します。

❑ Cloud Audit Logs のログを使用して、サービス アカウント キーへのアクセスを定期的に監査します。

ポリシーの管理

❑ 組織内のすべてのプロジェクトにアクセス権を付与するために、組織レベルの IAM ポリシーを設定します。

❑ 可能であれば、個々のユーザーではなく Google グループにロールを付与します。ユーザーを追加または削除する場合、IAM ポリシーを更新するより Google グループのユーザーを追加または削除するほうが簡単です。

❑ 特定のタスクの実行を許可するために複数の役割を付与する必要がある場合は、Google グループを作成してそのグループに役割を付与し、そのグループにユーザーを追加します。