IAM の安全な使用

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

はじめに

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

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

最小限の権限

基本ロールには、すべての Google Cloud サービスにかかわる多くの権限が含まれます。本番環境では、他に選択肢がない限り、基本ロールを付与しないでください。代わりに、ニーズに合わせて最も制限された事前定義ロールまたはカスタムロールを付与します。

基本ロールを置き換える必要がある場合は、ロールの推奨事項を使用して、代わりに付与するロールを決定できます。また、Policy Simulator を使用すると、ロールを変更してもプリンシパルのアクセス権に影響しないようにすることもできます。

次のような場合には、基本ロールの付与をおすすめします。

  • Google Cloud サービスで事前定義ロールを利用できない場合。使用可能なすべての事前定義済み役割のリストについては、事前定義済みの役割の表をご覧ください。
  • プロジェクトに関する幅広い権限を付与する必要がある場合。この状況は、開発環境またはテスト環境で権限を付与する場合によく生じます。
  • メンバーがきめ細かい権限を必要としない小規模なチームで働いている場合。
アプリケーションの個々のコンポーネントは個別の信頼境界として扱ってください。異なる権限を必要とする複数のサービスがある場合は、サービスごとに個別のサービス アカウントを作成した後で、各サービス アカウントに必要な権限のみを付与します。
❑  
子リソースの許可ポリシーは、親リソースの許可ポリシーを継承します。たとえば、プロジェクトの許可ポリシーでユーザーに Compute Engine 仮想マシン(VM)インスタンスを管理する権限が付与されている場合、ユーザーは各 VM で設定した許可ポリシーに関係なく、そのプロジェクトのすべての Compute Engine VM を管理できます。
❑  
必要最小限の範囲のロールを付与します。たとえば、Pub/Sub トピックをパブリッシュするアクセス権だけを必要とするユーザーには、そのトピックのパブリッシャーのロールを付与します。
サービス アカウントとして活動できるプリンシパルを指定します。サービス アカウントに対するサービス アカウント ユーザーのロールを付与されたユーザーは、そのサービス アカウントがアクセス権を持つすべてのリソースにアクセスできます。そのため、サービス アカウント ユーザーのロールをユーザーに付与する際は十分な注意が必要です。
プロジェクトのサービス アカウントの作成と管理ができる権限を持つユーザーを指定します。
❑  
プロジェクト IAM 管理者およびフォルダ IAM 管理者の事前定義ロールを付与すると、すべてのリソースに対する直接読み取り権限、書き込み権限、管理者権限を付与することなく、許可ポリシーを変更するためのアクセス権を付与できます。

プリンシパルにオーナーroles/owner)のロールを付与すると、ほぼすべてのリソースにアクセスして変更する権限(許可ポリシーの変更を含む)を付与することになります。この権限の範囲の広さには、潜在的な危険も潜んでいます。オーナーのロールは、ユニバーサルなアクセス権が必要な場合にのみ付与してくだい。
❑  
条件付きロール バインディングを使用してアクセスを自動的に期限切れにし、ジャストインタイムでのみ特権アクセスを付与することを検討します。

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

IAM Service Account API を使用して、サービス アカウント キーをローテーションします。キーをローテーションするには、新しいキーを作成し、新しいキーを使用するようにアプリケーションを切り替えます。その後、古いキーを無効にして、不要になった古いキーを削除します。
ユーザーが管理するサービス アカウント キーを管理するためのプロセスを実装します
暗号化キーとサービス アカウントキーを混同しないように注意してください。一般的に、暗号鍵はデータの暗号化に使用され、サービス アカウント キーは Google Cloud APIs への安全なアクセスのために使用されます。
インスタンスを実行するために使用中のサービス アカウントを削除しないでください。これを削除すると、先に別のサービス アカウントを使用するよう移行していなかった場合に、アプリケーションの全体または一部が失敗することがあります。
サービス アカウントの表示名を使用して、そのアカウントの用途やアカウントに必要な権限を管理できるようにします。
サービス アカウント キーをソースコードに組み込んだり、ダウンロード ディレクトリに置いたままにしたりしないでください。

監査

❑  
Cloud Audit Logs のログを使用して、許可ポリシーの変更を定期的に監査します。
❑  
Cloud Storage に監査ログをエクスポートして、ログを長期間保存します。
❑  
プロジェクトの許可ポリシーを変更できるユーザーの管理状況を監査します。
❑  
Logging のロールを使用して、ログへのアクセスを制限します。
❑  
ログ エクスプローラに適用されるのと同じアクセス ポリシーを、ログの転送に使用する Google Cloud リソースに適用します。
❑  
Cloud Audit Logs のログを使用して、サービス アカウント キーへのアクセスを定期的に監査します。

ポリシーの管理

❑  
組織内のすべてのプロジェクトにアクセスする必要があるプリンシパルには、組織レベルでロールを付与します。
❑  
可能であれば、個々のユーザーではなく Google グループにロールを付与します。許可ポリシーのプリンシパルを更新するよりも、Google グループのメンバーを更新するほうが簡単です。