このページでは、サービスを有効にした後に実行する Security Command Center の有効化プロセスの概要について説明します。このチュートリアルは、以下のよくある質問に答えることを目的としています。
- 組織で Security Command Center を有効にするとどうなりますか?
- 最初のスキャンの開始までに遅延が発生する理由はなんですか?
- 初回スキャンと継続スキャンの想定される実行時間はどれくらいですか?
- リソースと設定を変更するとパフォーマンスにどのような影響がありますか?
概要
Security Command Center のほとんどのお客様では、オンボーディングや有効化において大幅な遅延は発生しません。約 99% のユーザーがサービスを有効にしてから 4 時間以内に稼働しています。これらの数字は一般的なユーザー エクスペリエンスを示していますが、有効化プロセスにかかる時間が長くなる要因もあります。通常プロジェクトが 10 万件を超える組織の場合、有効化と初期スキャンが完了するまでに 24 時間以上かかることもあります。以下の要因により、スキャンの開始、設定の変更の処理、スキャンのランタイムにレイテンシが発生する可能性があります。
トポロジ
次の図は、オンボーディングと有効化プロセスの概要を示しています。
オンボーディングでのレイテンシ
スキャンを開始する前に、Security Command Center は、Google Cloud 全体から組織に属するリソースを検出し、インデックスに登録します。インデックス登録されるサービスには、App Engine、BigQuery、Cloud SQL、Cloud Storage、Compute Engine、Identity and Access Management、Google Kubernetes Engine などがあります。このオンボーディング プロセスでは重要なステップが 2 つあります。
アセットのスキャン
Security Command Center は、アセットの初期スキャンを実行して、プロジェクト、フォルダ、ファイル、クラスタ、ID、アクセス ポリシー、登録済みユーザーなどのリソースの合計数、ロケーション、状態を特定します。通常、このプロセスは数分以内に完了します。
API の有効化
リソースが検出されると、Security Command Center は、Security Health Analytics、Event Threat Detection、Container Threat Detection、Web Security Scanner の運用に必要となる Google Cloud の一部を有効にします。一部の検出サービスでは、保護されたプロジェクトで機能するように、特定の API を有効にする必要があります。API の有効化は、スキャン対象として選択したプロジェクトを反復処理し、対象の API を自動的に有効にするプロセスです。
組織のプロジェクトの数で、オンボーディング プロセスと有効化プロセスの長さの大部分が決まります。プロジェクトに対して API を 1 つずつ有効化する必要があるため、API 有効化は、特にプロジェクト数が 10 万件を超える組織にとって、通常これは最も時間のかかる作業になります。
複数のプロジェクトのサービスを有効にするために必要な時間は、直線的にスケーリングされます。つまり通常では 30,000 件のプロジェクトがある組織のサービスとセキュリティ設定の有効化には、15,000 件のプロジェクトがある組織の 2 倍の時間がかかります。
大規模な組織以外では、オンボーディングと有効化は 4 時間以内に完了するはずです。
知見
Security Command Center を設定するときに、有効にする組み込みサービスと統合サービスを決定し、脅威と脆弱性について分析またはスキャンする Google Cloud リソースを選択します。プロジェクトに対して API が有効になると、選択したサービスはスキャンを開始します。また、これらのスキャンの所要時間は、組織内のプロジェクトの数によって異なります。
組み込みサービスからの検出結果は、初期スキャンを完了したときに利用できるようになります。以下で説明するように、サービスでレイテンシが発生します。
- Container Threat Detection には、次のレイテンシがあります。
- 新しくオンボーディングされた組織でのアクティベーション レイテンシ(最大 3.5 時間)。
- 新しく作成したクラスタのアクティベーション レイテンシ(数分)。
- アクティブ化されたクラスタで脅威を検出するためのレイテンシ(数分)。
- Event Threat Detection の有効化は数秒で実行されます。検出のレイテンシは、ログが書き込まれてから Security Command Center で検出結果が表示されるまで通常 15 分以内です。
- Security Health Analytics のスキャンは、サービスが有効になってから約 1 時間後に開始されます。Security Health Analytics での最初のスキャンは、完了するまで最大 12 時間かかることがあります。その後、ほとんどの検出はアセット構成の変更に対してリアルタイムで実行されます(例外についての詳細は、Security Health Analytics の検出のレイテンシをご覧ください)。
- サービスが有効になってから、Web Security Scanner のスキャンが開始されるまでに最大で 24 時間かかることがあり、最初のスキャン後に毎週実行されます。
予備検出
初期スキャンの実行中でありながら、オンボーディング プロセスの完了前に、Security Command Center のダッシュボードに検出結果が表示されることがあります。
予備的な検出結果は正確で実用的なものですが、包括的なものではありません。最初の 24 時間以内でコンプライアンス評価のために、これらの検出結果を使用することはおすすめできません。
後続スキャン
通常、組織内で行われた変更(新しいフォルダやプロジェクトの追加やリソースの移動など)により、リソースの検出時間やスキャンのランタイムに大きな影響が生じることはありません。ただし、一部のスキャンは設定されたスケジュールに従って続行されます。このスケジュールによって、Security Command Center で変更が検出されるまでの時間が決まります。
- Web Security Scanner: 最初のスキャンと同じ日に毎週実行されます。スキャンは毎週実行されるため、Web Security Scanner によって組織の変更がリアルタイムで検出されることはありません。リソースを移動する、またはアプリケーションを変更する場合、最大 1 週間変更が検出されないことがあります。オンデマンド スキャンを実行すると、スケジュールされたスキャン間での新規または変更されたリソースを確認できます。
- Event Threat Detection / Container Threat Detection: これらのサービスは、有効になっているときにリアルタイムで実行され、有効にしたプロジェクトで新しいリソースまたは変更されたリソース(クラスタ、バケット、ログなど)をすぐに検出します。
- Security Health Analytics: 有効な場合にリアルタイムで実行され、新しいリソースまたは変更されたリソースを数分で検出します。ただし下記の検出項目は除きます。
Security Health Analytics の検出のレイテンシ
Security Health Analytics の検出は、サービスが有効になっているときにまとめて実行されるか、関連するアセットの構成が変更されるときにリアルタイム モードで 1 つずつ実行されます。Security Health Analytics を有効にすると、関連するリソース構成の変更に従って、ほぼリアルタイムで(10 分以内、ただし多くの場合それより短時間で)構成ミスの検出が更新されます。
Security Health Analytics で一部の検出項目がリアルタイム スキャンモードに対応していない場合があります。たとえば、検出がリソース構成の外部の情報に対して実行された場合などです。以下の表にリストされた検出は定期的に実行され、12 時間以内に構成ミスを特定します。Security Health Analytics の検出項目の詳細については、脆弱性と検出をご覧ください。
リアルタイム スキャンモードをサポートしていない Security Health Analytics の検出項目 |
---|
API_KEY_EXISTS |
API_KEY_NOT_ROTATED |
API_KEY_APIS_UNRESTRICTED |
API_KEY_APPS_UNRESTRICTED |
COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED |
COMPUTE_SERIAL_PORTS_ENABLED |
DISK_CSEK_DISABLED |
FULL_API_ACCESS |
MFA_NOT_ENFORCED(以前の名称: 2SV_NOT_ENFORCED) |
OS_LOGIN_DISABLED |
PUBLIC_IP_ADDRESS |
SSH_PASSWORD_ENABLED |
SQL_NO_ROOT_PASSWORD |
SQL_WEAK_ROOT_PASSWORD |
WEAK_SSH_PASSWORD |
次のステップ
- Security Command Center のダッシュボードの使用について確認する。
- 脆弱性と脅威のセキュリティ ソースについて確認する。