このページでは、IAM を使用する際に留意いただく必要があるセキュリティに関するベスト プラクティスをご紹介します。
このページは IAM に精通しているユーザーを対象としています。IAM を使い始めたばかりの方は、こちらの説明をお読みいただいても IAM の使い方は書かれていないため、IAM クイックスタートをまずお読みください。
最小限の権限
|
❑
基本ロールには、すべての Google Cloud サービスにかかわる多くの権限が含まれます。本番環境では、他に選択肢がない限り、基本ロールを付与しないでください。代わりに、ニーズに合わせて最も制限された事前定義ロールまたはカスタムロールを付与します。
基本ロールを置き換える必要がある場合は、ロールの推奨事項を使用して、代わりに付与するロールを決定できます。また、Policy Simulator を使用すると、ロールを変更してもプリンシパルのアクセス権に影響しないようにすることもできます。 次のような場合には、基本ロールの付与をおすすめします。
|
|
❑
アプリケーションの個々のコンポーネントは個別の信頼境界として扱ってください。異なる権限を必要とする複数のサービスがある場合は、サービスごとに個別のサービス アカウントを作成した後で、各サービス アカウントに必要な権限のみを付与します。
|
|
❑
子リソースの許可ポリシーは、親リソースの許可ポリシーを継承します。たとえば、プロジェクトの許可ポリシーでユーザーに 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 のログを使用して、サービス アカウント キーへのアクセスを定期的に監査します。
|
ポリシーの管理
|
❑
組織内のすべてのプロジェクトにアクセスする必要があるプリンシパルには、組織レベルでロールを付与します。
|
|
❑
可能であれば、個々のユーザーではなくグループにロールを付与します。許可ポリシーのプリンシパルを更新するよりも、グループのメンバーを更新するほうが簡単です。
|