Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則では、クラウド アプリケーション、サービス、プラットフォームの設計に堅牢なセキュリティ機能、制御、プラクティスを組み込むための推奨事項が示されています。アイディエーションから運用まで、設計プロセスのすべての段階に不可欠な要素としてセキュリティを組み込むことで、セキュリティの効果が高まります。
原則の概要
Google のセキュア バイ デザインへの取り組みの概要で説明されているように、セキュア バイ デフォルトとセキュア バイ デザインは、多くの場合、同じ意味で使用されますが、安全なシステムを構築するための異なるアプローチを表しています。どちらのアプローチも、脆弱性を最小限に抑え、セキュリティを強化することを目的としていますが、スコープと実装が異なります。
- デフォルトで保護: システムのデフォルト設定がセキュアモードに設定されていることを確認することに重点を置いています。これにより、ユーザーや管理者がシステムを保護するためのアクションを実行する必要性が最小限に抑えられます。このアプローチは、すべてのユーザーにベースライン レベルのセキュリティを提供することを目的としています。
- セキュア バイ デザイン: システムの開発ライフサイクル全体にわたって、セキュリティに関する考慮事項をプロアクティブに組み込むことを重視します。このアプローチは、潜在的な脅威と脆弱性を早期に予測し、リスクを軽減する設計を選択することです。このアプローチでは、安全なコーディング手法を使用し、セキュリティ レビューを実施して、設計プロセス全体にセキュリティを組み込みます。安全性を重視した設計アプローチは、開発プロセスを導く包括的な理念であり、セキュリティが後回しにされることなく、システム設計の不可欠な要素となるようにします。
推奨事項
クラウド ワークロードにセキュア バイ デザインの原則を実装するには、次のセクションの推奨事項を検討してください。
- ワークロードの保護に役立つシステム コンポーネントを選択する
- 階層化されたセキュリティ アプローチを構築する
- 強化された証明済みのインフラストラクチャとサービスを使用する
- 保存データと転送中データを暗号化する
ワークロードの保護に役立つシステム コンポーネントを選択する
この推奨事項は、すべての重点分野に関連しています。
効果的なセキュリティを実現するための基本的な決定は、プラットフォーム、ソリューション、サービスを構成する堅牢なシステム コンポーネント（ハードウェア コンポーネントとソフトウェア コンポーネントの両方）を選択することです。セキュリティ攻撃対象領域を減らし、潜在的な被害を制限するには、これらのコンポーネントのデプロイ パターンとその構成を慎重に検討する必要があります。
アプリケーション コードでは、脆弱性のクラスを排除するために、シンプルで安全、信頼性の高いライブラリ、抽象化、アプリケーション フレームワークを使用することをおすすめします。ソフトウェア ライブラリの脆弱性をスキャンするには、サードパーティ ツールを使用します。Assured Open Source Software を使用することもできます。これは、Google が使用して保護しているオープンソース ソフトウェア（OSS）パッケージを使用することで、ソフトウェア サプライ チェーンに対するリスクを軽減するのに役立ちます。
インフラストラクチャでは、安全な運用をサポートし、セキュリティ要件とリスク許容レベルに沿ったネットワーキング、ストレージ、コンピューティングのオプションを使用する必要があります。インフラストラクチャのセキュリティは、インターネットに接続するワークロードと内部ワークロードの両方にとって重要です。
この推奨事項をサポートする他の Google ソリューションについては、シフトレフト セキュリティを実装するをご覧ください。
階層化されたセキュリティ アプローチを構築する
この推奨事項は、次の重点分野に関連しています。
- AI と ML のセキュリティ
- インフラストラクチャのセキュリティ
- Identity and Access Management
- データ セキュリティ
多層防御アプローチを適用して、アプリケーションとインフラストラクチャ スタックの各レイヤにセキュリティを実装することをおすすめします。
プラットフォームの各コンポーネントのセキュリティ機能を使用します。セキュリティ インシデントが発生した場合にアクセスを制限し、潜在的な影響の範囲（影響範囲）を特定するには、次の操作を行います。
- 可能な限り柔軟に対応できるように、システムの設計を簡素化します。
- 各コンポーネントのセキュリティ要件を文書化します。
- 復元性と復旧の要件に対応する堅牢なセキュリティ メカニズムを組み込む。
セキュリティ レイヤを設計する際は、リスク評価を実施して、内部セキュリティ要件と外部規制要件を満たすために必要なセキュリティ機能を特定します。クラウド環境に適用され、規制要件に関連する、業界標準のリスク評価フレームワークを使用することをおすすめします。たとえば、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 はこれらのイメージのパッチと更新を定期的に行っています。
Google Kubernetes Engine（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 間トラフィックは暗号化されます。MACsec を使用すると、Cloud Interconnect 接続を介したトラフィックを暗号化できます。IPsec は、Cloud VPN 接続を介したトラフィックの暗号化を提供します。Apigee の TLS と mTLS 構成や、コンテナ化されたアプリケーション用の Cloud Service Mesh などのセキュリティ機能を使用して、クラウド内のアプリケーション間のトラフィックを保護できます。
デフォルトでは、 Google Cloud は保存データとネットワーク経由で転送中のデータを暗号化します。ただし、メモリ内で使用中のデータはデフォルトでは暗号化されません。組織が機密データを扱う場合は、システムメモリ内のアプリケーションまたはデータの機密性と整合性を損なう脅威を軽減する必要があります。これらの脅威を軽減するには、コンピューティング ワークロードに高信頼実行環境を提供する Confidential Computing を使用します。詳細については、Confidential VMs の概要をご覧ください。