オペレーションのベスト プラクティス

このセクションでは、追加のワークロードを Google Cloud 環境にデプロイして運用する際に考慮すべきオペレーションについて説明します。このセクションは、クラウド環境におけるすべてのオペレーションを網羅するものではありませんが、アーキテクチャの推奨事項、およびブループリントによってデプロイするリソースに関連する決定事項を紹介します。

基盤のリソースを更新する

ブループリントは基盤環境の独自の開始点として使用できますが、基盤の要件は、時間の経過とともに増大する可能性があります。最初のデプロイ以降に、構成設定を調整したり、すべてのワークロードで使用される新しい共有サービスを構築したりする場合も考えられます。

基盤リソースを変更する場合は、基盤パイプラインを使用してすべての変更を行うことをおすすめします。コードの記述と統合の流れや、デプロイ パイプラインのトリガーの流れの概要については、ブランチ戦略をご覧ください。

新しいワークロード プロジェクトの属性を決定する

自動化パイプラインのプロジェクト ファクトリ モジュールを使用して新しいプロジェクトを作成する場合は、さまざまな属性を構成する必要があります。新しいワークロードのプロジェクトを設計して作成するプロセスでは、次のことを決定する必要があります。

• 有効にする Google Cloud APIs
• 使用する共有 VPC、または新しい VPC ネットワークを作成するかどうか
• パイプラインによって作成される最初の project-service-account に対して作成する IAM ロール
• 適用するプロジェクト ラベル
• プロジェクトのデプロイ先となるフォルダ
• 使用する請求先アカウント
• プロジェクトを VPC Service Controls の境界に追加するかどうか
• プロジェクトの予算と請求アラートしきい値を構成するかどうか

各プロジェクトの構成可能な属性の詳細については、自動化パイプラインのプロジェクト ファクトリの入力変数をご覧ください。

権限を大規模に管理する

基盤上にワークロード プロジェクトをデプロイする場合は、対象となるデベロッパー、およびプロジェクトのユーザーに対し、アクセス権をどのように付与するかを検討する必要があります。既存の ID プロバイダが管理するグループにユーザーを追加し、グループを Cloud Identity と同期してから、グループに IAM ロールを適用することをおすすめします。また、最小権限の原則を常に念頭に置いてください。

また、IAM Recommender を使用して、権限が過剰なロールを付与する許可ポリシーを特定することをおすすめします。推奨事項を定期的に確認するプロセス、または推奨事項をデプロイ パイプラインに自動的に適用するプロセスを設計します。

ネットワーキング チームとアプリケーション チームの間で変更を調整する

ブループリントによってデプロイされるネットワーク トポロジでは、ネットワーク リソースの管理を担当するチームと、ワークロード インフラストラクチャ リソースのデプロイを担当するチームが別々に存在していることを前提としています。ワークロード チームはインフラストラクチャをデプロイするため、ワークロードのコンポーネント間で目的のアクセスパスを許可するファイアウォール ルールを作成する必要があります。しかし、このチームには、ネットワーク ファイアウォール ポリシーを自分たちで変更する権限はありません。

アプリケーションのデプロイに必要となる、一元化されたネットワーキング リソースに対する変更を調整するために、各チームがどのように連携するかを計画しましょう。たとえば、ワークロード チームがアプリケーション用のタグをリクエストするプロセスを設計します。これに対し、ネットワーキング チームはタグを作成してネットワーク ファイアウォール ポリシーにルールを追加し、タグを持つリソース間でのトラフィックのフローを許可し、タグを使用するための IAM ロールをワークロード チームに委任します。

Active Assist ポートフォリオで環境を最適化する

Google Cloud には、IAM Recommender のほか、環境の最適化方法に関する推奨事項を作成する Active Assist サービス ポートフォリオが用意されています。たとえば、ファイアウォール インサイトや放置されたプロジェクトの Recommender は、セキュリティ ポスチャーの強化に役立つ実用的な推奨事項を提供します。

推奨事項を定期的に確認するプロセス、または推奨事項をデプロイ パイプラインに自動的に適用するプロセスを設計します。中央チームが管理する推奨事項とワークロード オーナーが責任を持つ推奨事項を決定し、それぞれの推奨事項にアクセスできるよう、必要な IAM ロールを適用します。

組織のポリシーに例外を付与する

このブループリントで適用される組織のポリシーの制約セットは、大半のシナリオにおいて、ほとんどのユーザーに推奨されます。しかし、広範囲に適用する組織のポリシーに対して、限定的な例外を必要とする正当なユースケースが生じる場合もあります。

たとえば、このブループリントは iam.disableServiceAccountKeyCreation の制約を適用します。サービス アカウント キーの漏洩は重大な悪影響を及ぼす可能性があるため、この制約は重要なセキュリティ管理策です。したがって、ほとんどのシナリオでは、サービス アカウント キーよりも安全な代替手段を使用して認証を行う必要があります。しかし、認証にサービス アカウント キーしか使用できないユースケースもあります。Google Cloud サービスへのアクセスを必要とし、Workload Identity 連携を使用できないオンプレミス サーバーなどです。このようなシナリオでは、サービス アカウント キーを管理するためのベスト プラクティスなどの補完的な対策が追加されている限り、ポリシーの例外を許可するような判断が必要となります。

したがって、ワークロードのポリシーの例外をリクエストするプロセスを設計する必要があります。また、例外の付与を担当する意思決定者は、ユースケースを検証し、補完的なセキュリティ対策を追加するべきかどうかを相談できる十分な知識を有している必要があります。ワークロードに例外を付与する場合は、組織のポリシーの制約をできるだけ絞り込んで変更します。また、ポリシーの例外または適用を許可するタグを定義し、そのタグをプロジェクトとフォルダに適用することで、組織のポリシーに条件付きで制約を追加することもできます。

VPC Service Controls でリソースを保護する

このブループリントを使用することで、ベース ネットワークと制限付きネットワークを分離し、VPC Service Controls 用の環境を準備できます。ただし、デフォルトでは、Terraform コードは VPC Service Controls を有効化しません。有効化することで、中断を生じさせるプロセスになる可能性があるためです。

境界では、境界外からのトラフィック（コンソール、デベロッパー ワークステーション、リソースのデプロイに使用される基盤パイプラインなど）に対し、制限付きの Google Cloud サービスへのアクセスが拒否されます。VPC Service Controls を使用する場合は、目的のアクセスパスを許可する例外を境界に対して設計する必要があります。

VPC Service Controls の境界は、Google Cloud 組織と外部ソースとの間で、データの引き出しが生じるのを制御することを意図しています。個々のプロジェクトやリソースに対するきめ細かなアクセス制御のために、許可ポリシーの置き換えや複製を行うものではありません。境界を設計して構築する場合は、管理オーバーヘッドを低減するため、統一された共通の境界を使用することをおすすめします。

Google Cloud 組織内のサービス トラフィックをきめ細かく制御するために、複数の境界を設計する必要がある場合は、より複雑な境界構造で対処すべき脅威と、目的のオペレーションに必要となる境界間のアクセスパスを明確に定義することをおすすめします。

VPC Service Controls を導入する場合は、次の点を評価します。

• VPC Service Controls を必要とするユースケース。

• 必要な Google Cloud サービスが VPC Service Controls をサポートしているかどうか。

• 自動化パイプラインが中断された場合に、境界を修正するためのブレークグラス アクセスを構成する方法。

• VPC Service Controls を有効にするためのベスト プラクティスを使用して境界を設計し、実装する方法。

境界を有効にしたら、新しいプロジェクトを適切な境界に一貫して追加するプロセスと、現在の境界の設定では拒否される新しいユースケースが生じた場合の例外を設計するプロセスを設計しておくことをおすすめします。

組織ごとに組織全体の変更をテストする

変更を本番環境にデプロイする際は、必ず事前にテストすることをおすすめします。ワークロード リソースの場合、開発環境、非本番環境、本番環境を個別に用意して使用することで、このアプローチを実践しやすくなります。ただし、組織には、テストを円滑に行うための個別の環境を用意できないリソースもあります。

組織レベルでの変更や、本番環境に影響を与える可能性があるその他の変更（ID プロバイダと Cloud Identity 間の設定など）については、テスト用に個別の組織を作成することを検討してください。

仮想マシンへのリモート アクセスを制御する

基盤パイプライン、インフラストラクチャ パイプライン、アプリケーション パイプラインを使用して、不変のインフラストラクチャをデプロイすることが推奨されます。したがって、制限付きまたは例外的なユースケースでは、SSH または RDP 経由での仮想マシンへの直接アクセス権のみをデベロッパーに付与することをおすすめします。

リモート アクセスが必要なシナリオでは、可能であれば OS Login を使用してユーザー アクセスを管理することをおすすめします。このアプローチでは、マネージド Google Cloud サービスを使用して、アクセス制御、アカウント ライフサイクル管理、2 段階認証プロセス、監査ログを適用します。ただし、メタデータの SSH 認証鍵または RDP 認証情報を介したアクセスを許可する必要がある場合、認証情報のライフサイクルを管理し、その認証情報を Google Cloud の外部に安全に保管することは、お客様の責任となります。

いずれのシナリオでも、VM への SSH または RDP アクセス権を持つユーザーは権限昇格のリスクを伴うため、この点を念頭に置いてアクセスモデルを設計する必要があります。ユーザーは、関連するサービス アカウントの権限を使用して、その VM 上でコードを実行することも、メタデータ サーバーに対してクエリを実行して、API リクエストの認証に使用されるアクセス トークンを表示することもできます。このような場合、ユーザーにサービス アカウントの権限を使用させるつもりがなくても、このアクセス権が権限昇格となる可能性があります。

予算アラートを計画して過剰な支出を抑制する

このブループリントでは、Google Cloud Architecture Framework: 費用の最適化で紹介した、次のような費用管理のベスト プラクティスが実装されます。

• エンタープライズ基盤のすべてのプロジェクトで単一の請求先アカウントを使用します。

• 各プロジェクトに billingcode メタデータ ラベルを割り当てます。これは、コストセンター間でコストを割り当てるために使用されます。

• 予算とアラートのしきい値を設定します。

予算を計画して請求アラートを設定することは、お客様の責任となります。このブループリントは、予測支出額が予算の 120% に達すると予想される場合、ワークロード プロジェクトの予算アラートを作成します。このアプローチにより、中央チームは多大な費用超過のインシデントを特定して軽減できます。明確な原因なしに支出が大幅に増加した場合は、セキュリティ インシデントの兆候である可能性があります。このような場合は、コスト管理とセキュリティの両方の観点から調査する必要があります。

ユースケースに応じて、プロジェクトごとにきめ細かく予算を設定するのではなく、環境フォルダ全体の費用、または特定のコストセンターに関連するすべてのプロジェクトの費用に基づいて予算を設定できます。また、日常的なモニタリングのために、より詳細なアラートしきい値を設定すると考えられるワークロード オーナーに対し、予算とアラート設定を委任することもおすすめします。

ワークロードの予算の予測など、FinOps 機能の構築に関するガイダンスについては、Google Cloud で FinOps を使ってみるをご覧ください。

内部コストセンター間で費用を割り当てる

コンソールを使用すると、請求レポートを表示して、複数の項目で費用を表示して予測できます。事前構築済みのレポートに加えて、請求データを prj-c-billing-export プロジェクトの BigQuery データセットにエクスポートすることをおすすめします。エクスポートされた請求レコードを使用すると、billingcode などのプロジェクト ラベルのメタデータに基づいて、内部コストセンターなどのカスタム ディメンションに費用を割り当てることができます。

次の SQL クエリは、billingcode プロジェクト ラベルでグループ化されたすべてのプロジェクトの費用を把握するためのサンプルクエリです。

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

このエクスポートを設定する方法については、Cloud Billing データを BigQuery にエクスポートするをご覧ください。

コストセンター間で内部の会計処理またはチャージバックが必要となる場合、このクエリから取得したデータを内部プロセスに組み込むのはお客様の責任となります。

検知制御による検出結果を既存の SIEM に取り込む

基盤リソースは、監査ログとセキュリティ検出結果の集約先を設定するのに役立ちますが、これらのシグナルの消費方法と使用方法を決定するのはお客様の責任となります。

すべてのクラウド環境とオンプレミス環境のログを既存の SIEM に集約する必要がある場合は、prj-c-logging プロジェクトからのログ、および Security Command Center からの検出結果を、既存のツールやプロセスにどのように取り込むかを決定します。1 つのチームが環境全体のセキュリティをモニタリングする場合であれば、すべてのログと検出結果に対する単一のエクスポートを作成できます。職責の異なる複数のチームが必要とするログと検出結果に応じてフィルタリングする必要がある場合は、複数のエクスポートを作成できます。

また、ログの量が膨大で費用がかかりすぎる場合は、Google Cloud のログと検出結果を Google Cloud 内のみで保持するようにし、重複を避ける必要があります。このシナリオでは、既存のチームが、Google Cloud 内のログと検出結果を直接処理できるための適切なアクセス権を持ち、そのトレーニングを受けていることを確認してください。

• 監査ログについては、一元化されたログバケット内のログのサブセットに対するアクセス権を各チームに付与するようにログビューを設計します。複数のバケットにログを複製する方法では、ログストレージの費用が増大してしまいます。
• セキュリティ検出結果の場合は、Security Command Center にフォルダレベルとプロジェクト レベルのロールを付与し、どのチームも、自身が担当するプロジェクトのセキュリティ検出結果だけをコンソールで直接表示および管理できるようにします。

制御ライブラリの継続的な開発

このブループリントは、脅威を検出して防止する基本的な制御が出発点となります。これらの制御を確認し、要件に応じて必要な制御を追加することをおすすめします。次の表は、ガバナンス ポリシーを適用するメカニズムと、追加要件に合わせてポリシーを拡張する方法をまとめたものです。

これらの制御は、お客様の要件と Google Cloud での成熟度が変化するにつれて進化する可能性があります。

Cloud Key Management Service で暗号鍵を管理する

Google Cloud では、お客様のすべてのコンテンツに対して保存データの暗号化がデフォルトで提供されますが、保存データの暗号鍵をさらに制御できるように、Cloud Key Management Service（Cloud KMS）が用意されています。デフォルトの暗号化で十分なのか、それとも Cloud KMS を使用して独自に鍵を管理しなければならないコンプライアンス要件があるのかどうかを評価することをおすすめします。詳細については、保存データの暗号化に関するコンプライアンス要件を満たす方法を決定するをご覧ください。

このブループリントでは、暗号鍵を一元管理するために、共通フォルダ内に prj-c-kms プロジェクトを用意し、各環境フォルダ内に prj-{env}-kms プロジェクトを用意しています。このアプローチにより、中央チームは規制要件とコンプライアンス要件を満たすために、ワークロード プロジェクトのリソースに使用される暗号鍵を監査、管理できます。

運用モデルによっては、一元化された単一の Cloud KMS プロジェクト インスタンスを単一チームの管理下に置くことが望ましい場合もあれば、各環境で暗号鍵を個別に管理することが望ましい場合もあり、暗号鍵の説明責任を適切なチームに委任できるように、複数の分散インスタンスを設置することが望ましい場合もあります。運用モデルに合わせて、必要に応じて Terraform コードサンプルを変更してください。

必要に応じて、特定のリソースタイプでは常に CMEK 鍵を要求し、信頼できるプロジェクトの許可リストにある CMEK 鍵のみを使用できるように、顧客管理の暗号鍵（CMEK）の組織のポリシーを適用できます。

Secret Manager でアプリケーションの認証情報を保存、監査する

API キー、パスワード、プライベート証明書など、機密性の高いシークレットはソースコード リポジトリに commit しないことをおすすめします。代わりに、シークレットを Secret Manager に commit し、シークレットへのアクセスを必要とするユーザーまたはサービス アカウントに Secret Manager のシークレット アクセサーの IAM ロールを付与します。IAM ロールは、プロジェクト内のすべてのシークレットではなく、個々のシークレットに付与することをおすすめします。

可能であれば、CI / CD パイプライン内で本番環境のシークレットを自動生成し、ブレークグラスの状況以外で人間のユーザーがアクセスできないように管理します。このシナリオでは、どのユーザーやグループに対しても、これらのシークレットを表示する IAM ロールを付与しないように注意してください。

このブループリントでは、共通フォルダ内に 1 つの prj-c-secrets プロジェクトを用意し、各環境フォルダ内に prj-{env}-secrets プロジェクトを用意して、シークレットを一元管理しています。このアプローチでは、各アプリケーションで使用されるシークレットを中央チームが監査、管理し、規制とコンプライアンスの要件を満たすことができます。

運用モデルによっては、1 つの Secret Manager インスタンスを 1 つのチームに集中管理させる方法、各環境で個別にシークレットを管理する方法、あるいは複数の Secret Manager インスタンスを分散して設置し、各ワークロード チームがそれぞれのシークレットを管理できるようにする方法が適している場合もあります。運用モデルに合わせて、必要に応じて Terraform コードサンプルを変更してください。

高い権限を持つアカウントへのブレークグラス アクセスを計画する

基盤リソースへの変更は、基盤パイプラインによってデプロイされる、バージョン管理された IaC を通じて管理されることが推奨されますが、例外的または緊急のシナリオでは、特権アクセスによって環境を直接変更する必要が生じることもあります。緊急時や、自動化プロセスが中断した場合に備えて、環境に対する高度な特権アクセスを持つブレークグラス アカウント（ファイアコール アカウントや緊急アカウントとも呼ばれます）を計画しておくことをおすすめします。

次の表に、ブレークグラス アカウントの用途例を示します。

ブレークグラス アクセスを許可するメカニズムは、既存のツールと手順によって異なりますが、たとえば次のようなメカニズムが考えられます。

• 高い権限を持つ IAM ロールを事前定義しておいたグループに、既存の特権アクセス管理ツールを使用してユーザーを一時的に追加するか、高い権限を持つアカウントの認証情報を使用します。
• 管理者専用のアカウントを事前にプロビジョニングしておきます。たとえば、Dana というデベロッパーがいたとします。日常的に使用する dana@example.com という ID とは別に、ブレークグラス アクセス用の admin-dana@example.com という ID を用意しておくことができます。
• デベロッパーが上位の特権ロールに自己昇格できるようにする、ジャストインタイム特権アクセスなどのアプリケーションを使用します。

どのようなメカニズムを使用する場合であっても、以下の質問に運用上どのように対処するかを検討してください。

• ブレークグラス アクセスのスコープと粒度をどのように設計するか。たとえば、それぞれのブレークグラス メカニズムが干渉し合わないように、ビジネス ユニットごとに異なるメカニズムを設計します。
• 不正行為をどのように防止するメカニズムか。承認は必要か。たとえば、オペレーションを分割して、1 人のユーザーが認証情報を保持し、もう 1 人のユーザーが MFA トークンを保持するようにします。
• ブレークグラス アクセスの監査とアラートをどのように実施するか。たとえば、事前定義したブレークグラス アカウントの使用中に、セキュリティの検出結果が生成されるように、Event Threat Detection のカスタム モジュールを設定できます。
• インシデント解決後に、ブレークグラス アクセスを削除して通常のオペレーションを再開するにはどうすればよいか。

一般的な権限昇格タスクと変更のロールバックについては、ユーザーが自身の ID を権限昇格することなくオペレーションを実行できる、自動ワークフローを設計することをおすすめします。このアプローチは、人為的ミスを減らし、セキュリティを強化するのに役立ちます。

定期的な介入が必要なシステムでは、修正を自動化することが最適なソリューションとなる場合があります。ゼロタッチの本番環境アプローチを採用し、自動化、安全なプロキシ、または監査されたブレークグラスを使用して、すべての本番環境の変更を自動実行することをおすすめします。Google では、Google の SRE アプローチの導入を検討しているお客様向けに SRE 関連の書籍を提供しています。

次のステップ

• ブループリントをデプロイする（このシリーズの次のドキュメント）を読む。