次の方法で共有

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

  • [アーティクル]

ログと脅威検出では、クラウドでの脅威の検出やクラウド サービスの監査ログの有効化、収集、格納を行うコントロールを対象とします。たとえば、クラウド サービスのネイティブ脅威検出を使って高品質アラートを生成するコントロールによる検出、調査、修復のプロセスの有効化のほか、クラウド監視サービスによるログの収集、SIEM によるセキュリティ分析の一元化、時間の同期、ログの保持などがあります。

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

CIS Controls v8 ID NNIST 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からアラートとログ データを取り込み、他のリソースのデータ Microsoft 365 Defenderを Azure Monitor または Microsoft Sentinel インスタンスに取り込み、脅威を検出し、環境全体の特定の条件に一致するアラートを作成する分析ルールを構築します。

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

ネイティブの脅威検出機能がないサービスの場合は、データ プレーン ログを収集し、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 を使用して、AWS の特定のサービス (EC2 インスタンスなど) を監視することもできます。

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

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

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

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

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

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

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

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

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

CIS Controls v8 ID NNIST 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 の脅威保護モジュールでは、基本的なセキュリティ検疫監視に加えて、個々の Azure コンピューティング リソース (仮想マシン、コンテナー、アプリ サービスなど)、データ リソース (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
  • 次の場合に使用される API:
    • リソースが異常な方法で呼び出されたことを検出する
    • AWS 環境からデータを収集することは異常な方法で呼び出されました。
    • AWS 環境のデータまたはプロセスの改ざんが異常な方法で呼び出されました。
    • AWS 環境への不正アクセスが異常な方法で呼び出されました。
    • AWS 環境への未承認のアクセスを維持することは、異常な方法で呼び出されました。
    • AWS 環境に対する高レベルのアクセス許可の取得は、異常な方法で呼び出されました。
    • は、既知の悪意のある IP アドレスから呼び出されます。
    • ルート資格情報を使用して呼び出すことができます。
  • AWS CloudTrail のログ記録が無効になりました。
  • アカウント のパスワード ポリシーが弱まっていました。
  • 世界中で成功した複数のコンソール ログインが観察されました。
  • インスタンス起動ロールを介して EC2 インスタンス専用に作成された資格情報は、AWS 内の別のアカウントから使用されています。
  • インスタンス起動ロールを介して EC2 インスタンス専用に作成された資格情報は、外部 IP アドレスから使用されます。
  • 既知の悪意のある IP アドレスから API が呼び出されました。
  • カスタム脅威リストの IP アドレスから API が呼び出されました。
  • Tor 出口ノードの IP アドレスから API が呼び出されました。

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

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

Google Id ログと Google Cloud IAM ログはどちらも管理者アクティビティ ログを生成しますが、スコープは異なります。 Google ID ログは ID プラットフォームに対応する操作に対してのみ使用され、IAM ログは Google Cloud の IAM に対応する操作用です。 IAM ログには、API 呼び出しのログ エントリ、またはリソースの構成またはメタデータを変更するその他のアクションが含まれます。 たとえば、ユーザーが VM インスタンスを作成したり、ID とアクセス管理のアクセス許可を変更したりすると、これらのログが記録されます。

Cloud Identity レポートと IAM レポートを使用して、特定の疑わしいアクティビティ パターンに関するアラートを生成します。 また、ポリシー インテリジェンスを使用してサービス アカウント アクティビティを分析し、プロジェクト内のサービス アカウントなどのアクティビティが過去 90 日間使用されていないことを特定することもできます。

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

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

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

CIS Controls v8 ID NNIST 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 ガイダンス: VM 内の Azure リソース、オペレーティング システム、アプリケーションのログ、その他のログの種類など、さまざまなレベルのリソースのログ機能を有効にします。

管理/コントロール プレーン層とデータ プレーン層で、セキュリティ、監査、およびその他の運用ログのさまざまな種類のログに注意してください。 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 ガイダンス: VM 内の Azure リソース、オペレーティング システム、アプリケーションのログ、その他のログの種類など、さまざまなレベルのリソースのログ機能を有効にします。

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

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

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

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

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

CIS Controls v8 ID NNIST 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 Application Firewall (WAF) ログ、およびログを、セキュリティ分析のためにネットワーク トラフィック データ収集エージェントを介して仮想マシンから有効にして収集し、インシデント調査とセキュリティ アラート生成をサポートします。 Azure Monitor Log Analytics ワークスペースにフロー ログを送信し、Traffic Analytics を使用して分析情報を提供できます。

他のネットワーク データの関連付けを支援するために、DNS クエリ ログを収集するようにしてください。

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

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

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

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

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

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

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

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

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

CIS Controls v8 ID NNIST 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 ストレージ バケット内のログを集計し、ログ データを Microsoft Sentinel にオンボードできます。これにより、セキュリティ情報イベント管理 (SIEM) とセキュリティ オーケストレーション自動応答 (SOAR) 機能が提供されます。

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

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

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

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

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

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

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

CIS Controls v8 ID NNIST 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、データ エクスプローラー、またはデータ レイクを使用して、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 の実装と追加のコンテキスト:

GCP ガイダンス: 既定では、クラウド ログ バケットのカスタムリテンション期間を構成しない限り、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 NNIST 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 をセキュリティで保護してください。

注: コンピューティング エンジン仮想マシンでは外部 NTP ソースを使用せず、Google が提供する内部 NTP サーバーを使用することをお勧めします。

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

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