クラウド デプロイのセキュリティを保護するための基本的なベスト プラクティス
Google Cloud Japan Team
※この投稿は米国時間 2021 年 8 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。
最近のブログ投稿で触れたように、セキュリティ基盤のブループリントは、安全な Google Cloud デプロイを作成するためのベスト プラクティスを選び、ご使用の環境でそれらのベスト プラクティスを適応、採用、デプロイするための Terraform 自動化リポジトリを提供するものです。今日のブログ投稿では、セキュリティ基盤ガイドについてもう少し掘り下げ、セキュリティの実践担当者とプラットフォーム チームが自社組織でセキュリティ中心のインフラストラクチャをセットアップ、構成、デプロイ、運用するため使用できる、いくつかのベスト プラクティスに注目します。
ブループリントに記載されているベスト プラクティスは予防制御と検出制御の両方を組み合わせたもので、手順ガイドのような形式に編成されています。最初のトピックのセクションでは、予防制御について触れています。これらはアーキテクチャとポリシーの決定により実装されます。次のトピックのセクションでは、検出制御について触れています。これらはモニタリング機能を使用して変動、異常値、悪意のある行動が発生しているかどうかを監視するものです。
この投稿を完全なセキュリティ基盤ガイドと照らし合わせながら読み進める場合、手順ガイドのセクション 4～11（第 2 章）をご覧ください。
予防制御
最初のいくつかのトピックでは、プログラマティックな制限（ポリシー）とアーキテクチャ設計の両方を使用して組織を保護し、違反の可能性を防止する方法について触れています。
組織構造
Google Cloud への移行による利点の一つは、リソースおよびその編成と階層を 1 つの場所で管理できることです。このセクションのベスト プラクティスは、そのためのリソース階層戦略を示すものです。これらを実装すると、隔離が行われ、ポリシー、権限、アクセスの分離が可能になり、悪意のある行動やエラーによるリスクが減少します。これらは作業が増えるように思えるかもしれませんが、GCP の能力により管理のオーバーヘッドを減らしながら実現可能です。
次のようなベスト プラクティスがあります。
リソースのトップレベルの所有権には単一の組織を使用します。
フォルダ階層を実装し、プロジェクトを関連するグループ（本番、本番以外、開発、共通、ブートストラップ）に分け、セグメンテーションと分離を作成して、セキュリティ ポリシーの適用やアクセス許可の付与を行えるようにします。
フォルダやプロジェクト間でのリソース構成の制約を定義する組織のポリシーを規定します。
リソースのデプロイ
基礎リソースやインフラストラクチャ リソースを展開する、またはアプリケーションをデプロイするとき、デプロイのパイプラインを管理する方法によってセキュリティが強固になることも、リスクが増えることもあります。このセクションのベスト プラクティスは、自動化され標準化されたレビュー、承認、ロールバックの処理を設定する方法を示しています。これらにより、手動での構成の量が制限され、結果として人為的エラーの可能性が減少し、整合性が促進され、リビジョン管理を行え、スケーリングが可能になります。これによってガバナンスとポリシー管理を行い、組織がセキュリティやコンプライアンスのリスクにさらされることを回避できます。
次のようなベスト プラクティスがあります。
Google Cloud インフラストラクチャを Terraform モジュールとしてコード化し、リソースを自動的にデプロイ可能にします。
Terraform モジュールにプライベート Git リポジトリを使用します。
デプロイ パイプライン アクションを、パイプラインに組み込まれたポリシー検証および承認ステージとともに開始します。
基盤、インフラストラクチャ、ワークロードを別のパイプラインとアクセス パターンでデプロイします。
認証と認可
多くのデータ侵害は、権限のスコープが正しくない、または過剰に与えられていることから発生します。アクセスを正確にコントロールし、特定のユーザーのみが保護されたリソースにアクセス可能とすることで、デプロイメントの安全を保つことができます。このセクションは、クラウドのデプロイメントにおける認証（ユーザーの身元を検証する）と認可（そのユーザーが何を行えるのか決定する）についてのベスト プラクティスを示しています。推奨事項として、ユーザーの認証情報を 1 か所で管理する（たとえば、Google Cloud Identity や Active Directory）、同期を有効にし、停止または削除されたユーザー アカウントのアクセスや権限の削除が正しく伝搬されるようにする、などがあります。
このセクションでは、多要素認証（MFA）とフィッシング耐性のあるセキュリティ鍵の重要性（組織構造の章でさらに詳しく触れます）も強調されています。特権のある ID では特に多要素認証を使用し、マルチパーティ認可の追加も検討する必要があります。これらの ID はそのアクセス権のためターゲットとなる可能性が高く、リスクが大きくなるためです。
このセクションのベスト プラクティスすべてに共通するのは、最小権限の原則、つまり必要な権限のみを与えるという原則です。必要より多くの権限も、少ない権限も望ましくありません。
それ以外に、いくつかのベスト プラクティスがあります。
ユーザーの ID を、オンプレミスの Active Directory（該当する場合）と連携した Cloud Identity で自動的に維持し、すべての ID 情報をここで参照可能にします。
認証にシングル サインオン（SSO）を使用します。
緊急事態にアクセスの昇格を行うため、特権 ID を規定します。
個別の ID よりも、命名規則が定義されたグループを使用して、IAM によりアクセス許可を割り当てます。
ネットワーキング
ネットワークはリソース間とインターネットへのコミュニケーション レイヤなので、外部（North-South とも呼ばれます）および内部（East-West）からの攻撃を阻止するため、セキュリティ保護の保証が不可欠です。手順ガイドのこのセクションでは、ネットワークのセキュリティを保護し、分割して、機密性の高いデータを保存するサービスを保護する方法について解説しています。また、デプロイのパターンに応じた各種の代替アーキテクチャも記載されています。
ガイドでは、オンプレミス環境と公開インターネットの両方でリソースが互いに通信を行えるようにするには、クラウドのデプロイのネットワーキングをどのように構成するのが最良かについても詳しく解説しています。これらはすべて、セキュリティと信頼性を保持したうえで行われます。ネットワークのポリシーとコントロールの集中化を保つことで、これらのベスト プラクティスの実装を管理しやすくなります。
このセクションでは詳細で明確なガイドを示すことを焦点としているため、このトピックについてさらに詳しく調べるには完全な手順ガイドのセクション 7 をご覧ください。このセクションにおける高レベルのベスト プラクティスのいくつかを次に示します。
共有 VPC、または使用事例に適合している場合はハブ アンド スポークのアーキテクチャを使用して、ネットワークのポリシーと管理を集中化します。
機密データを含むサービスを別の共有 VPC ネットワーク（基本と制限付き）に分離し、別のプロジェクト、IAM、VPC Service Controls 境界を使用して、制限付きネットワークとの間でのデータ転送を制限します。
Dedicated Interconnect（または代替品）を使用してオンプレミスと Google Cloud とを接続し、Cloud DNS を使用してオンプレミスの DNS サーバーと通信を行います。
クラウドやオンプレミスから Google Cloud API へのアクセスには、プライベート IP アドレスを使用します。
タグベースのファイアウォール ルールを規定して、ネットワーク トラフィックのフローをコントロールします。
鍵とシークレットの管理
鍵と認証情報を保存する場所を特定しようとするとき、多くの場合はセキュリティ レベルと利便性のトレードオフとなります。このセクションでは、クラウド アプリケーションに必要な鍵、パスワード、証明書、他の機密データを、Cloud Key Management Services と Secret Manager を使用して保存する、安全で便利な方法について概説します。これらのベスト プラクティスに従うことで、コードにシークレットを保存することが避けられ、鍵とシークレットのライフサイクルが正しく管理され、最小権限の原則と職掌分散が遵守されます。
次のようなベスト プラクティスがあります。
暗号鍵は Cloud Key Management Services で作成、管理、使用します。
他のすべての汎用シークレットは、Secret Manager で保存および取得します。
規定された階層を使用して、組織とフォルダのレベル間で鍵とシークレットを分離します。
ロギング
ログは、組織全体でさまざまなチームにより使用されます。デベロッパーはコードを作成するとき何が起きているかを把握するため、セキュリティ チームは調査と根本原因の分析のため、管理者は本番運用での問題をデバッグするため、コンプライアンス チームは規制の要件をサポートするため、ログを使用します。このセクションのベスト プラクティスでは、これらの使用事例すべてを念頭に置いて、多様な一連のユーザーが必要なログでサポートされることを保証します。
ガイドでは、ログに関して次のようないくつかのベスト プラクティスが推奨されています。
組織レベルのログシンク プロジェクトで、ログの収集を集中化します。
フォルダレベルでデータのモニタリングを統合します。
Cloud Logging API と Cloud Log Router でログの取り込み、集約、処理を行います。
シンクから、監査のため Cloud Storage に、分析のため BigQuery に、Cloud Pub/Sub 経由で SIEM に、それぞれログをエクスポートします。
手順ガイドに記載されているロギングの構造
検出制御
「検出制御」という用語は、変動や悪意のある行動が発生したとき、またはその直後に捕捉するという意味に解釈されることがあります。しかし実際には、手順ガイドの以後のセクションでは、攻撃を抑止する方法や、モニタリング機能を使用し、脆弱性や構成ミスを悪用される機会が発生する前に検出する方法について触れています。
検出制御
このセクションでは、探偵が犯罪を解決するため手がかり、容疑者、それらのつながりのマッピングをホワイトボードに書き込むのと同様に、インフラストラクチャの構成ミスや脆弱性の可能性と、アクティブな脅威となる行動を検出してまとめ、一元管理する方法について触れています。このためにはいくつかの方法があります。Google Cloud の Security Command Center Premium を使用する、BQ と Chronicle を活用してセキュリティ アナリティクスのネイティブの機能を使用する、およびデプロイで適用可能ならサードパーティの SIEM ツールと統合する方法です。
ガイドには、次のようないくつかのベスト プラクティスが記載されています。
Security Command Center Premium を使用してセキュリティの検出事項を集約および管理し、インフラストラクチャの構成ミス、脆弱性、およびアクティブな脅威となる行動を検出してアラートを発行します。
BigQuery のログを使用して、Security Command Center Premium による異常動作の検出を強化します。
エンタープライズの SIEM プロダクトを Google Cloud Logging と統合します。
請求の設定
組織でのクラウドの使用は請求を伴うため、請求のアラートをセットアップし、請求記録をモニタリングすることで、予測しない消費を検出し、ガバナンスとセキュリティを拡張するための機構を追加できます。
これをサポートするためのベスト プラクティスとして、次のものが記載されています。
プロジェクトごとに、主要なしきい値（50%、75%、90%、95%）で警告を発するよう請求アラートを設定します。
請求固有のプロジェクトでは、BigQuery データセットに請求記録をエクスポートします。
請求アラートの設定、BigQuery への請求記録のエクスポートなどの方法について詳しくは、Beyond Your Bill 動画シリーズもご覧ください。
まとめと次のステップ
この投稿では、クラウドのデプロイの基盤となるインフラストラクチャを構築するためのブループリントに記載されているベスト プラクティスについて、予防と検出の制御も含めて解説しました。
ベスト プラクティスは数多く存在しますが、Terraform 自動化リポジトリで提供されているテンプレートを使用すると効率的に採用、適応、デプロイが可能です。これらのベスト プラクティスを実装するための詳細な解説は、セキュリティ基盤ガイドに記載されています。一歩前に進んでデプロイし、セキュリティを維持しましょう。
-デベロッパー アドボケイト Alicia Williams
