Google Cloud アーキテクチャ フレームワークのセキュリティの柱にあるこの原則では、クラウド アプリケーション、サービス、プラットフォームの設計に堅牢なセキュリティ機能、制御、プラクティスを組み込むための推奨事項について説明します。アイデア出しから運用まで、セキュリティを設計プロセスのすべての段階に組み込むと、より効果的です。
原則の概要
安全性を重視した設計に対する Google の取り組みの概要で説明されているように、デフォルトでセキュリティを確保すると安全性を重視した設計は、しばしば同じ意味で使用されますが、安全なシステムを構築するための異なるアプローチを表しています。どちらのアプローチも、脆弱性を最小限に抑えてセキュリティを強化することを目的としていますが、スコープと実装が異なります。
- デフォルトで安全: システムのデフォルト設定がセキュア モードに設定されていることを確認することで、ユーザーや管理者がシステムを保護するためのアクションを必要最小限に抑えます。このアプローチは、すべてのユーザーにベースライン レベルのセキュリティを提供することを目的としています。
- 設計によるセキュリティ: システムの開発ライフサイクル全体にわたってセキュリティ上の考慮事項を事前に組み込むことを重視します。このアプローチでは、潜在的な脅威や脆弱性を早期に予測し、リスクを軽減する設計を選択します。このアプローチでは、安全なコーディング手法の使用、セキュリティ レビューの実施、設計プロセス全体にセキュリティを組み込むことが含まれます。セキュア・バイ・デザイン アプローチは、開発プロセスをガイドする包括的な哲学であり、セキュリティが後付けではなく、システム設計の不可欠な部分であることを保証するのに役立ちます。
推奨事項
クラウド ワークロードに安全設計の原則を実装するには、次のセクションの推奨事項を検討してください。
ワークロードの保護に役立つシステム コンポーネントを選択する
この推奨事項は、すべての重点分野に関連しています。
効果的なセキュリティを実現するための基本的な決定は、プラットフォーム、ソリューション、サービスを構成する堅牢なシステム コンポーネント（ハードウェア コンポーネントとソフトウェア コンポーネントの両方を含む）を選択することです。セキュリティ攻撃対象領域を減らし、潜在的な損害を制限するには、これらのコンポーネントのデプロイ パターンとその構成も慎重に検討する必要があります。
アプリケーション コードでは、脆弱性のクラスを排除するために、単純で安全で信頼性の高いライブラリ、抽象化、アプリケーション フレームワークを使用することをおすすめします。ソフトウェア ライブラリの脆弱性をスキャンするには、サードパーティ製ツールを使用できます。Assured Open Source Software を使用する方法もあります。これにより、Google が使用して保護しているオープンソース ソフトウェア（OSS）パッケージを使用して、ソフトウェア サプライ チェーンに対するリスクを軽減できます。
インフラストラクチャでは、安全な運用をサポートし、セキュリティ要件とリスク許容レベルに準拠するネットワーキング、ストレージ、コンピューティング オプションを使用する必要があります。インフラストラクチャのセキュリティは、インターネットに接続するワークロードと内部ワークロードの両方にとって重要です。
この推奨事項をサポートするその他の Google ソリューションについては、シフトレフト セキュリティを実装するをご覧ください。
階層化されたセキュリティ アプローチを構築する
この推奨事項は、次の重点分野に関連しています。
- AI と ML のセキュリティ
- インフラストラクチャのセキュリティ
- ID とアクセスの管理
- データ セキュリティ
多層防御アプローチを適用して、アプリケーションとインフラストラクチャ スタックの各レイヤにセキュリティを実装することをおすすめします。
プラットフォームの各コンポーネントのセキュリティ機能を使用する。セキュリティ インシデントが発生した場合にアクセスを制限し、影響を受ける可能性のある範囲（影響範囲）を特定するには、次の操作を行います。
- 可能であれば、柔軟性に対応するためにシステム設計を簡素化します。
- 各コンポーネントのセキュリティ要件を文書化します。
- 復元性と復元の要件に対処するために、堅牢なセキュリティ メカニズムを組み込みます。
セキュリティ レイヤを設計するときは、リスク評価を実施して、内部セキュリティ要件と外部規制要件を満たすために必要なセキュリティ機能を決定します。クラウド環境に適用され、規制要件に関連する業界標準のリスク評価フレームワークを使用することをおすすめします。たとえば、Cloud Security Alliance（CSA）は Cloud Controls Matrix（CCM）を提供します。リスク評価では、リスクのカタログと、それらを軽減するための対応するセキュリティ管理が提供されます。
リスク評価を行う際は、クラウド プロバイダと責任を共有していることを念頭に置いてください。したがって、クラウド環境におけるリスクは、オンプレミス環境におけるリスクとは異なります。たとえば、オンプレミス環境では、ハードウェア スタックの脆弱性を軽減する必要があります。一方、クラウド環境では、こうしたリスクはクラウド プロバイダが負担します。また、共有責任の境界は、クラウド プロバイダの IaaS、PaaS、SaaS サービスによって異なります。
潜在的なリスクを特定したら、技術的、管理的、運用上のコントロール、契約上の保護、サードパーティの証明書を使用する緩和計画を設計して作成する必要があります。また、OWASP アプリケーション脅威モデリング方法などの脅威モデリング方法は、潜在的なギャップを特定し、ギャップに対処するためのアクションを提案するのに役立ちます。
強化された構成証明付きのインフラストラクチャとサービスを使用
この推奨事項は、すべての重点分野に関連しています。
成熟したセキュリティ プログラムでは、セキュリティに関する公開情報で説明されている新しい脆弱性を軽減します。セキュリティ プログラムでは、既存のデプロイの脆弱性を修正し、VM とコンテナ イメージを保護するための修正も提供する必要があります。イメージの OS とアプリケーションに固有のハードニング ガイドや、Center of Internet Security（CIS）が提供するベンチマークを使用できます。
Compute Engine VM にカスタム イメージを使用する場合は、イメージに自分でパッチを適用する必要があります。また、Google 提供の厳選された OS イメージを使用することもできます。このイメージは定期的にパッチが適用されます。Compute Engine VM でコンテナを実行するには、Google がキュレートした Container-Optimized OS イメージを使用します。Google はこれらのイメージのパッチと更新を定期的に行っています。
GKE を使用している場合は、クラスタノードに常に最新のパッチが適用されているように、ノードの自動アップグレードを有効にすることをおすすめします。Google では、GKE コントロール プレーンを管理し、自動更新を行ってパッチを適用しています。コンテナの攻撃対象領域をさらに減らすには、distroless イメージを使用します。Distroless イメージは、セキュリティに敏感なアプリケーション、マイクロサービス、イメージサイズと攻撃対象領域を最小限に抑えることが不可欠な状況に最適です。
機密性の高いワークロードの場合は、Shielded VM を使用します。これにより、VM の起動サイクル中に悪意のあるコードが読み込まれるのを防ぐことができます。Shielded VM インスタンスは、ブート セキュリティを提供し、整合性をモニタリングし、Virtual Trusted Platform Module（vTPM）を使用します。
SSH アクセスを保護するために、OS Login を使用すると、従業員は SSH 認証鍵に依存することなく、Identity and Access Management（IAM）権限を信頼できる情報源として使用して VM に接続できます。したがって、組織全体で SSH 認証鍵を管理する必要はありません。OS Login では、管理者による従業員のライフサイクルへのアクセスが関連付けられます。つまり、従業員がロールを変更したり、退職した場合、そのユーザーのアクセス権はそのユーザーのアカウントで取り消されます。OS Login は Google の 2 要素認証もサポートしています。これにより、アカウントの乗っ取り攻撃に対するセキュリティを強化できます。
GKE では、アプリケーション インスタンスは Docker コンテナ内で実行されます。定義済みのリスク プロファイルを有効にして、ユーザーがコンテナを変更できないようにするには、コンテナをステートレスにし、変更されないようにします。不変性の原則は、従業員がコンテナを変更したり、コンテナにインタラクティブにアクセスしないことを意味します。コンテナを変更する必要がある場合は、新しいイメージをビルドしてそのイメージを再デプロイします。特定のデバッグ シナリオでのみ、基盤となるコンテナへの SSH アクセスを有効にします。
環境全体で構成をグローバルに保護するには、組織のポリシーを使用して、クラウド アセットの動作に影響するリソースに制約またはガードレールを設定します。たとえば、次の組織のポリシーを定義し、組織全体にグローバルに適用するか、フォルダまたはプロジェクトのレベルで選択的に適用できます。 Google Cloud
- VM への外部 IP アドレスの割り当てを無効にします。
- リソースの作成を特定の地理的ロケーションに制限します。
- サービス アカウントまたはそのキーの作成を無効にします。
保存中と転送中のデータの暗号化
この推奨事項は、次の重点分野に関連しています。
- インフラストラクチャのセキュリティ
- データ セキュリティ
データ暗号化は、機密情報を保護するための基本的な制御であり、データ ガバナンスの重要な部分です。効果的なデータ保護戦略には、要件の慎重な評価に基づくアクセス制御、データ分割とデータ所在地、監査、および暗号化の実装が含まれます。
デフォルトでは、 Google Cloudは保存されているお客様のデータを暗号化します。お客様が特別な操作を行う必要はありません。Google Cloud では、デフォルトの暗号化に加えて、エンベロープ暗号化と暗号鍵の管理を行うことができます。ストレージ、コンピューティング、ビッグデータ ワークロード用の鍵の選択に関しては、鍵の生成、保管、ローテーションの要件にどのソリューションが最適かを判断する必要があります。たとえば、顧客管理の暗号鍵（CMEK）は Cloud Key Management Service（Cloud KMS）で作成できます。CMEK は、暗号鍵の定期的なローテーションの必要性など、規制要件またはコンプライアンス要件を満たすために、ソフトウェアベースまたは HSM で保護できます。Cloud KMS Autokey を使用すると、CMEK のプロビジョニングと割り当てを自動化できます。また、Cloud External Key Manager（Cloud EKM）を使用して、サードパーティの鍵管理システムから独自の鍵を取得することもできます。
転送中のデータを暗号化することを強くおすすめします。すべての転送中のデータは、Google が管理しているまたは Google が管理を委託している物理的境界の外へ出るときに、1 つ以上のネットワーク レイヤで暗号化され認証されます。VPC ネットワーク内とピアリングされた VPC ネットワーク間の VM 間トラフィックはすべて暗号化されます。Cloud Interconnect 接続を介したトラフィックの暗号化には、MACsec を使用できます。IPsec は、Cloud VPN 接続を介したトラフィックの暗号化を提供します。クラウド内のアプリケーション間トラフィックを保護するには、Apigee の TLS と mTLS の構成や、コンテナ化されたアプリケーションの Cloud Service Mesh などのセキュリティ機能を使用します。
デフォルトでは、 Google Cloud は保存データとネットワークを介した転送中のデータの暗号化を行います。ただし、デフォルトでは、メモリ内で使用中のデータは暗号化されません。組織で機密データを扱う場合は、アプリケーション メモリまたはシステムメモリ内のデータの機密性と整合性を損なう脅威に対処する必要があります。こうした脅威を軽減するには、コンピューティング ワークロードに信頼できる実行環境を提供する Confidential Computing を使用します。詳細については、Confidential VMs の概要をご覧ください。