次の方法で共有

セキュリティ制御: ログ記録と脅威の検出

ログと脅威の検出には、クラウド上の脅威を検出するための制御と、クラウド サービスの監査ログの有効化、収集、および格納が含まれます。これには、クラウド サービスでネイティブの脅威検出を使用して高品質のアラートを生成するコントロールを使用した検出、調査、修復プロセスの有効化が含まれます。また、クラウド監視サービスを使用したログの収集、SIEM を使用したセキュリティ分析の一元化、時刻同期、ログリテンション期間も含まれます。

LT-1: 脅威検出機能を有効にする

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
8.11 AU-3、AU-6、AU-12、SI-4 10.6、10.8、A3.5

セキュリティ原則: 脅威検出シナリオをサポートするには、既知の脅威と異常について、すべての既知のリソースの種類を監視します。 ログ データ、エージェント、またはその他のデータ ソースから高品質のアラートを抽出して誤検知を減らすために、アラートのフィルター処理と分析ルールを構成します。

Azure ガイダンス: それぞれの Azure サービスに対して、Microsoft Defender for Cloud の脅威検出機能を使用します。

Microsoft Defender サービスに含まれていない脅威検出については、それぞれのサービスの Microsoft Cloud セキュリティ ベンチマーク サービス ベースラインを参照して、サービス内の脅威検出またはセキュリティ アラート機能を有効にします。 Microsoft Defender for Cloud、Microsoft 365 Defender からアラートとログ データを取り込み、他のリソースのデータを Azure Monitor または Microsoft Sentinel インスタンスに取り込み、脅威を検出し、環境全体の特定の条件に一致するアラートを作成する分析ルールを構築します。

産業用制御システム (ICS) または監督制御およびデータ取得 (SCADA) リソースを制御または監視するコンピューターを含む運用テクノロジ (OT) 環境の場合は、Microsoft Defender for IoT を使用して資産のインベントリを作成し、脅威と脆弱性を検出します。

ネイティブの脅威検出機能がないサービスの場合は、データ プレーン ログを収集し、Microsoft Sentinel を使用して脅威を分析することを検討してください。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: Amazon GuardDuty を使用して、VPC フロー ログ、AWS CloudTrail 管理イベント ログ、CloudTrail S3 データ イベント ログ、EKS 監査ログ、DNS ログなどのデータ ソースを分析して処理する脅威検出を行います。 GuardDuty は、特権エスカレーション、公開された資格情報の使用、悪意のある IP アドレスやドメインとの通信などのセキュリティの問題について報告できます。

構成ドリフトなどのコンプライアンス監視のために SecurityHub のルールを確認し、必要に応じて結果を作成するように AWS Config を構成します。

GuardDuty および SecurityHub に含まれていない脅威検出の場合は、サポートされている AWS サービス内で脅威検出またはセキュリティ アラート機能を有効にします。 CloudTrail、CloudWatch、または Microsoft Sentinel にアラートを抽出して分析ルールを構築します。このルールは、環境全体で特定の条件に一致する脅威を検出します。

Microsoft Defender for Cloud を使用して、EC2 インスタンスなどの AWS の特定のサービスを監視することもできます。

産業用制御システム (ICS) または監督制御およびデータ取得 (SCADA) リソースを制御または監視するコンピューターを含む運用テクノロジ (OT) 環境の場合は、Microsoft Defender for IoT を使用して資産のインベントリを作成し、脅威と脆弱性を検出します。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: Google Cloud Security Command Center のイベント脅威検出を使用して、管理アクティビティ、GKE データアクセス、VPC フローログ、Cloud DNS、ファイアウォールログなどのログデータを使用して脅威を検出します。

さらに、Chronicle SIEM と SOAR を備えた最新の SOC 用のセキュリティ運用スイートを使用します。 Chronicle SIEM と SOAR は、脅威の検出、調査、およびハンティング機能を提供します

また、Microsoft Defender for Cloud を使用して、コンピューティング VM インスタンスなどの GCP 内の特定のサービスを監視することもできます。

産業用制御システム (ICS) または監督制御およびデータ取得 (SCADA) リソースを制御または監視するコンピューターを含む運用テクノロジ (OT) 環境の場合は、Microsoft Defender for IoT を使用して資産のインベントリを作成し、脅威と脆弱性を検出します。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

LT-2: ID およびアクセス管理の脅威検出を有効にする

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
8.11 AU-3、AU-6、AU-12、SI-4 10.6、10.8、A3.5

セキュリティ原則: ユーザーとアプリケーションのサインインとアクセスの異常を監視することで、ID とアクセス管理の脅威を検出します。 ログイン試行の失敗回数が多すぎる、サブスクリプション内の非推奨のアカウントなどの動作パターンは、アラートを生成する必要があります。

Azure ガイダンス: Azure AD には、Azure AD レポートで表示したり、Azure Monitor、Microsoft Sentinel、またはその他の SIEM/監視ツールと統合して、より高度な監視と分析のユース ケースを実現できる次のログが用意されています。

  • サインイン: サインイン レポートには、マネージド アプリケーションとユーザー サインイン アクティビティの使用状況に関する情報が表示されます。
  • 監査ログ: Azure AD 内のさまざまな機能によって行われたすべての変更について、ログを通じて追跡可能性を提供します。 監査ログの例には、ユーザー、アプリ、グループ、ロール、ポリシーの追加や削除など、Azure AD 内のリソースに加えられた変更が含まれます。
  • 危険なサインイン: 危険なサインインは、ユーザー アカウントの正当な所有者ではないユーザーによって実行された可能性のあるサインイン試行のインジケーターです。
  • リスクのフラグが設定されたユーザー: 危険なユーザーは、侵害された可能性のあるユーザー アカウントのインジケーターです。

Azure AD には、ユーザー アカウントとサインイン動作に関連するリスクを検出して修復するための Identity Protection モジュールも用意されています。 リスクの例としては、資格情報の漏洩、匿名またはマルウェアにリンクされたIPアドレスからのサインイン、パスワードスプレーなどがあります。 Azure AD Identity Protection のポリシーを使用すると、ユーザー アカウントに対する Azure 条件付きアクセスと組み合わせて、リスクベースの MFA 認証を適用できます。

さらに、Microsoft Defender for Cloud は、サブスクリプション内の非推奨のアカウントや、過剰な数の認証試行の失敗などの疑わしいアクティビティに対してアラートを生成するように構成できます。 基本的なセキュリティ検疫の監視に加えて、Microsoft Defender for Cloud の Threat Protection モジュールでは、個々の Azure コンピューティング リソース (仮想マシン、コンテナー、App Service など)、データ リソース (SQL DB やストレージなど)、Azure サービス レイヤーから、より詳細なセキュリティ アラートを収集することもできます。 この機能を使用すると、個々のリソース内のアカウントの異常を確認できます。

注: 同期のためにオンプレミスの Active Directory を接続する場合は、Microsoft Defender for Identity ソリューションを使用して、オンプレミスの Active Directory シグナルを使用して、組織に向けられた高度な脅威、侵害された ID、悪意のある内部関係者のアクションを特定、検出、調査します。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: AWS IAM は、IAM Access Advisor と IAM 認証情報レポートを通じて、コンソール ユーザー アクティビティのログとレポートを次のようにレポートします。

  • 成功したサインイン試行と失敗したログイン試行。
  • 各ユーザーの多要素認証 (MFA) の状態。
  • 休眠中のIAMユーザー

API レベルのアクセスモニタリングと脅威検出の場合は、Amazon GuadDuty を使用して IAM に関連する結果を特定します。 これらの調査結果の例は次のとおりです。

  • AWS 環境へのアクセスに使用され、異常な方法で呼び出された、または防御策を回避するために使用された API
  • API は、次の目的で使用されます。
    • Discover Resources が異常な方法で呼び出された
    • AWS 環境からのデータの収集が異常な方法で呼び出されました。
    • AWS 環境内のデータまたはプロセスの改ざんが異常な方法で呼び出されました。
    • AWS環境への不正アクセスが異常な方法で呼び出されました。
    • AWS 環境への不正アクセスを維持する が異常な方法で呼び出されました。
    • AWS 環境に対する高レベルのアクセス許可を取得することが、異常な方法で呼び出されました。
    • 既知の悪意のある IP アドレスから呼び出される。
    • ルート資格情報を使用して呼び出すことができます。
  • AWS CloudTrail のログ記録が無効になりました。
  • アカウントのパスワードポリシーが弱体化しました。
  • 世界中で複数の成功したコンソールログインが観察されました。
  • インスタンス起動ロールを通じて EC2 インスタンス専用に作成された認証情報は、AWS 内の別のアカウントから使用されています。
  • インスタンス起動ロールを通じて EC2 インスタンス専用に作成された認証情報は、外部 IP アドレスから使用されています。
  • 既知の悪意のある IP アドレスから API が呼び出されました。
  • カスタム脅威リストの IP アドレスから API が呼び出されました。
  • API が Tor 出口ノードの IP アドレスから呼び出されました。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: 休眠中のユーザー管理サービス アカウントに 1 つ以上の機密性の高い IAM ロールが付与されたイベントの検出など、特定のタイプの IAM 関連の脅威検出には、Google Cloud Security Command Center のイベント脅威検出を使用します。

Google Identity ログと Google Cloud IAM ログはどちらも管理アクティビティ ログを生成しますが、スコープは異なることに注意してください。 Google Identity ログは Identity Platform に対応する操作のみを対象とし、IAM ログは Google Cloud の IAM に対応する操作を対象としています。 IAM ログには、API コールのログエントリや、リソースの設定やメタデータを変更するその他のアクションが含まれます。 たとえば、これらのログには、ユーザーがVMインスタンスを作成したり、IDおよびアクセス管理の権限を変更したりしたときに記録されます。

Cloud Identity レポートと IAM レポートを使用して、特定の不審なアクティビティ パターンについてアラートを発します。 また、Policy Intelligence を使用して、サービスアカウントのアクティビティを分析し、プロジェクト内のサービスアカウントが過去 90 日間に使用されていないアクティビティを特定することもできます。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

LT-3: セキュリティ調査のためのログを有効にする

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
8.2, 8.5, 8.12 AU-3、AU-6、AU-12、SI-4 10.1, 10.2, 10.3

セキュリティ原則: セキュリティ インシデントの調査とセキュリティ対応およびコンプライアンスの要件を満たすために、クラウド リソースのログ記録を有効にします。

Azure ガイダンス: Azure リソース、VM 内のオペレーティング システムやアプリケーションのログ、その他のログの種類など、さまざまな階層のリソースのログ記録機能を有効にします。

管理/コントロール プレーン層とデータ プレーン層のセキュリティ、監査、およびその他の運用ログに関するさまざまな種類のログに注意してください。 Azure プラットフォームで使用できるログには、次の 3 種類があります。

  • Azure リソース ログ: Azure リソース (データ プレーン) 内で実行される操作のログ記録。 たとえば、キー コンテナーからシークレットを取得したり、データベースに対して要求を行ったりします。 リソース ログの内容は、Azure サービスとリソースの種類によって異なります。
  • Azure アクティビティ ログ: 外部 (管理プレーン) から、サブスクリプション レイヤーの各 Azure リソースに対する操作のログ記録。 アクティビティ ログを使用して、サブスクリプション内のリソースに対して実行された書き込み操作 (PUT、POST、DELETE) を決定できます。 Azure サブスクリプションごとに 1 つのアクティビティ ログがあります。
  • Azure Active Directory ログ: サインイン アクティビティの履歴と、特定のテナントに対して Azure Active Directory で行われた変更の監査証跡のログ。

Microsoft Defender for Cloud と Azure Policy を使用して、Azure リソースのリソース ログとログ データの収集を有効にすることもできます。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: 管理イベント (コントロールプレーンオペレーション) とデータイベント (データプレーンオペレーション) に AWS CloudTrail ログ記録を使用し、CloudWatch でこれらの証跡をモニタリングして自動アクションを行います。

Amazon CloudWatch Logs サービスを使用すると、リソース、アプリケーション、サービスのログをほぼリアルタイムで収集して格納できます。 ログには、主に次の 3 つのカテゴリがあります。

  • 自販ログ: ユーザーに代わって AWS サービスによってネイティブに公開されたログ。 現在、Amazon VPC フローログと Amazon Route 53 ログは、サポートされている 2 種類です。 これら 2 つのログは、既定で有効になっています。
  • AWS サービスによって発行されたログ: 30 を超える AWS サービスのログが CloudWatch に発行されます。 これには、Amazon API Gateway、AWS Lambda、AWS CloudTrail などが含まれます。 これらのログは、サービスと CloudWatch で直接有効にすることができます。
  • カスタム ログ: 独自のアプリケーションとオンプレミスのリソースからのログ。 これらのログを収集するには、オペレーティング システムに CloudWatch エージェントをインストールし、CloudWatch に転送することが必要な場合があります。

多くのサービスは CloudWatch ログにのみログを発行しますが、一部の AWS サービスでは、さまざまなログ記録ストレージと保持ポリシーを使用できる AmazonS3 または Amazon Kinesis Data Firehose にログを直接発行できます。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: Azure リソース、VM 内のオペレーティング システムやアプリケーションのログ、その他のログの種類など、さまざまな階層のリソースのログ記録機能を有効にします。

管理/コントロール プレーン層とデータ プレーン層のセキュリティ、監査、およびその他の運用ログに関するさまざまな種類のログに注意してください。 Operations Suite Cloud Logging サービスは、リソース層からあらゆる種類のログ イベントを収集して集計します。 クラウド ログでは、次の 4 つのカテゴリのログがサポートされています。

  • プラットフォーム ログ - Google Cloud サービスによって書き込まれたログ。
  • コンポーネント ログ - プラットフォーム ログと同様ですが、システム上で実行される Google が提供するソフトウェア コンポーネントによって生成されるログです。
  • セキュリティ ログ - 主に、リソース内の管理アクティビティとアクセスを記録する監査ログ。
  • ユーザー作成 - カスタム アプリケーションとサービスによって書き込まれたログ
  • マルチクラウドログとハイブリッドクラウドログ - Microsoft Azureなどの他のクラウドプロバイダーからのログとオンプレミスインフラストラクチャからのログ。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

LT-4: セキュリティ調査のためにネットワーク ログを有効にする

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
8.2, 8.5, 8.6, 8.7, 13.6 AU-3、AU-6、AU-12、SI-4 10.8

セキュリティ原則: ネットワーク関連のインシデント調査、脅威ハンティング、およびセキュリティ アラートの生成をサポートするために、ネットワーク サービスのログ記録を有効にします。 ネットワーク ログには、IP フィルタリング、ネットワークおよびアプリケーション ファイアウォール、DNS、フロー監視などのネットワーク サービスからのログが含まれる場合があります。

Azure ガイダンス: ネットワーク セキュリティ グループ (NSG) リソース ログ、NSG フロー ログ、Azure Firewall ログ、Web アプリケーション ファイアウォール (WAF) ログ、およびインシデント調査をサポートするセキュリティ分析とセキュリティ アラート生成のために、ネットワーク トラフィック データ収集エージェントを介して仮想マシンからログを有効にして収集します。 フロー ログを Azure Monitor Log Analytics ワークスペースに送信し、Traffic Analytics を使用して分析情報を提供できます。

他のネットワーク データの関連付けに役立つ DNS クエリ ログを収集します。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: VPC フローログ、WAF ログ、Route53 Resolver クエリログなどのネットワークログを有効にして収集し、インシデント調査とセキュリティアラートの生成をサポートするためのセキュリティ分析を行います。 ログは、監視のために CloudWatch にエクスポートすることも、一元化された分析のために Microsoft Sentinel ソリューションに取り込むための S3 ストレージ バケットにエクスポートすることもできます。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: ほとんどのネットワーク アクティビティ ログは、Google Compute VM や Kubernetes Engine ノードとして使用されるインスタンスなど、リソースとの間で送受信されたネットワーク フローのサンプルを記録する VPC フローログを通じて利用できます。 これらのログは、ネットワーク監視、フォレンジック、リアルタイムセキュリティ分析、経費の最適化に使用できます。

クラウド ログのフロー ログを表示し、Cloud Logging エクスポートでサポートされている宛先にログをエクスポートできます。 フロー ログは、コンピューティング エンジン VM からの接続によって集計され、リアルタイムでエクスポートされます。 Pub/Sub をサブスクライブすることで、リアルタイム ストリーミング API を使用してフロー ログを分析できます。

注: Packet Mirroring を使用して、Virtual Private Cloud (VPC) ネットワーク内の指定したインスタンスのトラフィックをクローンし、調査のために転送することもできます。 パケット ミラーリングは、ペイロードやヘッダーを含むすべてのトラフィックとパケット データをキャプチャします。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

LT-5:セキュリティ ログの管理と分析を一元化する

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
8.9, 8.11, 13.1 AU-3、AU-6、AU-12、SI-4 なし

セキュリティ原則: ログ記録のストレージと分析を一元化して、ログ データ間の関連付けを可能にします。 ログ ソースごとに、データ所有者、アクセス ガイダンス、ストレージの場所、データの処理とアクセスに使用されるツール、およびデータ保持要件が割り当てられていることを確認します。

CSP 用の既存の SIEM ソリューションがない場合は、クラウド ネイティブ SIEM を使用します。 ログ/アラートを既存の SIEM に集約します。

Azure ガイダンス: Azure アクティビティ ログを一元化された Log Analytics ワークスペースに統合していることを確認します。 Azure Monitor を使用してクエリを実行し、分析を実行し、Azure サービス、エンドポイント デバイス、ネットワーク リソース、およびその他のセキュリティ システムから集計されたログを使用してアラート ルールを作成します。

さらに、セキュリティ情報イベント管理 (SIEM) とセキュリティ オーケストレーション自動応答 (SOAR) 機能を提供する Microsoft Sentinel にデータを有効にしてオンボードします。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: AWS ログをストレージと分析のために一元化されたリソースに統合していることを確認します。 CloudWatch を使用して、クエリと分析を実行し、AWS サービス、サービス、エンドポイント デバイス、ネットワーク リソース、およびその他のセキュリティ システムから集計されたログを使用してアラート ルールを作成します。

さらに、S3 ストレージ バケットのログを集計し、セキュリティ情報イベント管理 (SIEM) とセキュリティ オーケストレーション自動応答 (SOAR) 機能を提供する Microsoft Sentinel にログ データをオンボードできます。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: GCP ログを一元化されたリソース(Operations Suite Cloud Logging バケットなど)に統合して、保存と分析を行うようにしてください。 クラウド ログでは、ほとんどの Google Cloud ネイティブ サービス ログと、サード パーティ製アプリケーションとオンプレミス アプリケーションがサポートされています。 Cloud Logging を使用してクエリを実行し、分析を実行したり、GCP サービス、サービス、エンドポイント デバイス、ネットワーク リソース、その他のセキュリティ システムから集計されたログを使用してアラート ルールを作成したりできます。

CSP 用の既存の SIEM ソリューションがない場合は、クラウド ネイティブ SIEM を使用するか、ログ/アラートを既存の SIEM に集約します。

注: Google では、ログのクエリ、表示、分析用に、Logs Explorer と Log Analytics の 2 つのログクエリ フロントエンドを提供しています。 ログ データのトラブルシューティングと調査には、ログ エクスプローラーを使用することをお勧めします。 分析情報と傾向を生成するには、Log Analytics を使用することをお勧めします。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

LT-6:ログの保持期間を構成する

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
8.3, 8.10 AU-11 10.5, 10.7

セキュリティ原則: コンプライアンス、規制、ビジネス要件に従ってログ保持戦略を計画します。 ログが適切にアーカイブされるように、個々のログ サービスでログ保持ポリシーを構成します。

Azure ガイダンス: Azure アクティビティ ログなどのログは 90 日間保持され、その後削除されます。 診断設定を作成し、ニーズに基づいてログを別の場所 (Azure Monitor Log Analytics ワークスペース、Event Hubs、Azure Storage など) にルーティングする必要があります。 この戦略は、VM 内のオペレーティング システムやアプリケーションのログなど、自分で管理される他のリソース ログやリソースにも適用されます。

ログリテンション期間オプションは次のとおりです。

  • Azure Monitor Log Analytics ワークスペースは、最大 1 年間のログ保有期間、または応答チームの要件に従って使用します。
  • Azure Storage、Data Explorer、または Data Lake を使用して、1 年以上の長期およびアーカイブ ストレージを使用し、セキュリティ コンプライアンス要件を満たします。
  • Azure Event Hubs を使用して、Azure 外部の外部リソースにログを転送します。

注: Microsoft Sentinel では、ログ ストレージのバックエンドとして Log Analytics ワークスペースが使用されます。 SIEM ログを長期間保持する予定の場合は、長期的なストレージ戦略を検討する必要があります。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: デフォルトでは、ログは無期限に保持され、CloudWatch で期限切れになることはありません。 ログ グループごとに保持ポリシーを調整したり、無期限の保持期間を保持したり、10 年から 1 日の間の保持期間を選択したりできます。

CloudWatch からのログアーカイブには Amazon S3 を使用し、オブジェクトライフサイクル管理とアーカイブポリシーをバケットに適用します。 Amazon S3 から Azure Storage にファイルを転送することで、中央ログアーカイブに Azure Storage を使用できます。

AWS の実装と追加のコンテキスト:

  • CloudWatch ログリテンション期間の変更 の
  • AzCopy を使用して Amazon S3 から Azure Storage にデータをコピーする

GCP ガイダンス: デフォルトでは、Cloud Logging バケットのカスタム保持を構成しない限り、Operations Suite Cloud Logging はログを 30 日間保持します。 既定では、管理者アクティビティ監査ログ、システム イベント監査ログ、および Access Transparency ログは 400 日間保持されます。 1 日から 3650 日の間にログを保持するようにクラウド ログを構成できます。

Cloud Storage を使用してクラウド ログからログをアーカイブし、オブジェクト ライフサイクル管理とアーカイブ ポリシーをバケットに適用します。 Google Cloud Storage から Azure Storage にファイルを転送することで、一元的なログ アーカイブに Azure Storage を使用できます。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

LT-7: 承認された時刻同期ソースを使用する

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
8.4 AU-8 10.4

セキュリティ原則: ログ記録のタイム スタンプには、日付、時刻、タイム ゾーン情報を含む承認された時刻同期ソースを使用します。

Azure ガイダンス: Microsoft は、ほとんどの Azure PaaS および SaaS サービスのタイム ソースを保持しています。 コンピューティング リソースのオペレーティング システムでは、特定の要件がない限り、時刻同期に Microsoft の既定の NTP サーバーを使用します。 独自のネットワーク タイム プロトコル (NTP) サーバーを立ち上げる必要がある場合は、UDP サービス ポート 123 をセキュリティで保護してください。

Azure 内のリソースによって生成されるすべてのログには、既定で指定されたタイム ゾーンを含むタイム スタンプが用意されています。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: AWS は、ほとんどの AWS サービスのタイムソースを保持しています。 オペレーティングシステムの時刻設定が設定されているリソースまたはサービスの場合は、特定の要件がない限り、時刻同期に AWS のデフォルトの Amazon Time Sync Service を使用します。 独自のネットワーク タイム プロトコル (NTP) サーバーを立ち上げる必要がある場合は、UDP サービス ポート 123 をセキュリティで保護してください。

AWS 内のリソースによって生成されるすべてのログは、デフォルトで指定されたタイムゾーンのタイムスタンプを提供します。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: Google Cloud は、ほとんどの Google Cloud PaaS サービスと SaaS サービスのタイムソースを保持しています。 コンピューティング リソースのオペレーティング システムでは、特定の要件がない限り、時刻の同期に Google Cloud のデフォルトの NTP サーバーを使用してください。 独自のネットワークタイムプロトコル(NTP)サーバーを立ち上げる必要がある場合は、UDPサービスポート123をセキュリティで保護してください。

注: Compute Engine 仮想マシンでは外部 NTP ソースを使用せず、Google が提供する内部 NTP サーバーを使用することをおすすめします。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):