WEB問題集
オンプレミスの VM を Google Cloud に移行する予定です。VM の移行前に、Google Cloud でランディングゾーンをセットアップする必要があります。本番環境のすべての VM がプライベート IP アドレスを介して相互に通信できるようにする必要があります。Google Cloud 組織内のすべての VM が特定の TCP ポートで接続を受け入れるようにする必要があります。Google が推奨するプラクティスに従い、運用コストを最小限に抑えたいと考えています。どうすべきですか？
正解：D
これは最もGoogle推奨の設計に沿った方法です。Shared VPCによりプライベートIPでのVM間通信が可能になり、階層型ファイアウォールポリシーにより特定のTCPポートを全組織のVMに統一的に許可することができます。スケーラビリティとコスト効率を両立する最適な解答です。
Google推奨の「ランディングゾーン」設計では、ネットワークを集中管理するためにShared VPC（共有VPC）を使用することがベストプラクティスとされています。ホストプロジェクトにVPCを作成し、各本番プロジェクトをサービスプロジェクトとして紐付けることで、すべてのVMはプライベートIPで通信可能になります。また、セキュリティと管理性を高めるためには階層型ファイアウォールポリシー（Hierarchical Firewall Policies）を組織レベルまたはフォルダレベルで適用するのが推奨されており、これにより一貫したアクセス制御を行え、個別のルール設定や重複管理を避けられます。これらを組み合わせることで、コスト効率が高く、運用負荷を最小化しつつGoogle推奨の設計を実現できます。
あなたの会社のセキュリティ脆弱性管理ポリシーでは、セキュリティチームのメンバーが特定のCompute Engineインスタンスに関する脆弱性およびその他のOSメタデータを可視化できるようにする必要があります。このCompute Engineインスタンスは、Google Cloudプロジェクト内の重要なアプリケーションをホストしています。あなたは会社のセキュリティ脆弱性管理ポリシーを実装する必要があります。どうすべきでしょうか？
正解：C
- OS Config エージェントのインストール: OS Config エージェントは、Compute Engine インスタンスのゲスト OS レベルの情報を収集し、OS ポリシーの適用、パッチ適用の管理、そして脆弱性レポートの生成を行います。問題文で求められている「脆弱性やその他の OS メタデータ」の可視性を確保するためには、このエージェントが必須です。OS Config エージェントが有効になっていれば、OS インベントリデータ（OS メタデータ）と脆弱性レポートが自動的に収集されます。
roles/osconfig.vulnerabilityReportViewer権限の付与: この IAM ロールは、OS Config サービスによって生成される脆弱性レポートを表示するための最小限の権限を提供します。これにより、セキュリティチームのメンバーは、指定された Compute Engine インスタンスの脆弱性に関する情報を確認できるようになります。このロールは、セキュリティポリシーの要件である「脆弱性への可視性」を直接満たします。
Compute Engineインスタンスの脆弱性スキャンやOSメタデータ（パッケージ情報、カーネル、構成情報など）を取得するには、OS Config エージェントをインスタンスにインストールする必要があります。OS Configはインベントリ管理と脆弱性スキャンをサポートしており、その結果はGoogle Cloud ConsoleやAPIを通じて確認可能です。さらに、セキュリティチームのメンバーが脆弱性レポートを参照できるようにするには、roles/osconfig.vulnerabilityReportViewer を付与することが推奨されています。これにより、必要な情報への最小権限アクセスが実現でき、Google推奨のセキュリティポリシーに準拠した実装となります。
あなたの会社の開発チームが、本番環境の既存の Cloud Run サービスに新しい機能をデプロイできるようにしたいと考えています。新しいリビジョンに関連するリスクを最小限に抑えるために、お客様に開発コストや運用コストを発生させることなく、障害の影響を受ける可能性のあるお客様の数を減らしたいと考えています。サービスのリビジョン管理に関する Google の推奨プラクティスに従う必要があります。どうすべきですか？
正解：B
- 段階的ロールアウト (Gradual Rollout) と トラフィック分割 (Traffic Splitting): Cloud Run は、サービスのリビジョン間でトラフィックを分割する機能をサポートしています。新しいリビジョンをデプロイする際に、最初はトラフィックのごく一部 (例: 1% や 5%) のみを新しいリビジョンにルーティングし、残りのトラフィックは安定した以前のリビジョンにルーティングできます。これにより、新しいリビジョンに問題があった場合でも、影響を受ける顧客の数を最小限に抑えることができます。これは、一般的にカナリアリリースまたはプログレッシブデプロイメントと呼ばれる手法です。
- ロールバック機能: 万が一、新しいリビジョンで問題が発覚した場合でも、トラフィックの割合を調整するだけで、迅速かつ簡単に以前の安定したリビジョンにトラフィックを戻す（ロールバックする）ことができます。これにより、ダウンタイムを最小限に抑え、顧客への影響を軽減できます。
- 運用コストの最小化: Cloud Run のトラフィック分割機能は組み込みであるため、追加のインフラストラクチャや複雑な設定は不要であり、運用コストを増やすことなくこの戦略を実行できます。
この問題は、Cloud Run での安全なデプロイ戦略、特にトラフィック分割と段階的ロールアウトの重要性に関するものです。これは、新しい機能を本番環境に導入する際のリスクを最小限に抑えるための Google Cloud の推奨プラクティスです。 各選択肢の説明の理由から、Cloud Run のトラフィック分割機能を活用した段階的ロールアウトが、リスクを最小限に抑えつつ、Google の推奨プラクティスに沿った最適なアプローチとなります。
Compute Engine インスタンスにアプリケーションをデプロイしました。外部コンサルタントが Linux ベースのインスタンスにアクセスする必要があります。コンサルタントは VPN 接続を介して企業ネットワークに接続していますが、Google アカウントを持っていません。どうすべきですか？
正解：C
- SSH キーペアの生成: SSH アクセスの標準的な方法は、ユーザーが秘密鍵と公開鍵のペアを生成することです。秘密鍵はユーザー（この場合はコンサルタント）が厳重に保管し、公開鍵はアクセスを許可したいサーバー（Compute Engine インスタンス）に配置します。
- 公開鍵の追加: コンサルタントから受け取った公開鍵を Compute Engine インスタンスのメタデータ、または特定のユーザーの
~/.ssh/authorized_keysファイルに追加することで、その公開鍵に対応する秘密鍵を持つユーザーのみがインスタンスに認証なしでアクセスできるようになります。 - 秘密鍵によるアクセス: コンサルタントは、自分が生成して保持している秘密鍵を使用して、SSH クライアントを介してインスタンスに接続します。これは、鍵交換により安全なセッションを確立し、パスワードよりもはるかにセキュアな認証方法です。
- Google アカウント不要: この方法は、外部コンサルタントが Google アカウントを持っていなくても Compute Engine インスタンスにアクセスできるようにします。
- セキュリティの原則: 秘密鍵は常にユーザー側で管理されるべきであり、決して他者に共有されるべきではありません。公開鍵のみをサーバー側に配置するこのモデルは、SSH アクセスの基本的なセキュリティ原則に合致します。
最も安全で、要件に合致し、SSH のベストプラクティスに従っているのは、コンサルタントが SSH キーペアを生成し、その公開鍵のみを Compute Engine インスタンスに追加する方法です。
最近のセキュリティインシデントの後、あなたのスタートアップ企業は Google Cloud 環境で何が起きているのかをよりよく把握したいと考えています。予期せぬファイアウォールの変更とインスタンスの作成を監視する必要があります。あなたの会社はシンプルなソリューションを好みます。どうすべきですか？
正解：B
- Cloud Audit Logs: Google Cloud は、プロジェクト内のすべての管理アクティビティ（リソースの作成、更新、削除など）を自動的にCloud Audit Logsに記録します。これには、ファイアウォールルールの変更や Compute Engine インスタンスの作成も含まれます。これらのログは、サービスアカウントやユーザーが実行した操作を追跡するための主要な情報源です。
- Cloud Logging フィルタ: Cloud Logging を使用すると、監査ログを簡単にフィルタリングして、特定のイベント（例:
compute.firewalls.insert、compute.instances.insertなど）を特定できます。 - ログベースの指標 (Log-based Metrics): フィルタリングされたログエントリに基づいてログベースの指標を作成できます。たとえば、「ファイアウォール作成イベントの数」や「インスタンス作成イベントの数」といった指標を定義できます。
- Cloud Monitoring とアラート: 作成されたログベースの指標は Cloud Monitoring に自動的に公開され、そこでアラートポリシーを設定できます。これにより、特定の期間内に予期せぬ数のイベントが発生した場合（例: 営業時間外にファイアウォールルールが変更された場合）に、セキュリティチームに即座に通知を送信できます。