クライアント IP ヘッダーの構成
ASM は自動的に、X-Forwarded-For のようなよく知られたヘッダーから、http.client_ip を解決しようとします。もし、このフィールドにカスタムヘッダーを使用したり、解決アルゴリズムをバイパスしたい場合は、DD_TRACE_CLIENT_IP_HEADER 環境変数を設定します。この変数が設定されている場合、ライブラリはクライアント IP の指定されたヘッダーのみをチェックします。
認証された悪質なユーザーの追跡
多くの重大な攻撃は、最も機密性の高いエンドポイントにアクセスできる認証されたユーザーによって実行されます。疑わしいセキュリティアクティビティを生成している悪質なユーザーを特定するには、標準化されたユーザータグを使用してサービスをインスツルメンテーションすることにより、ユーザー情報をトレースに追加します。ルートスパンにカスタムタグを追加したり、インスツルメンテーション関数を使用したりすることができます。
Datadog トレーシングライブラリは、互換性のある認証フレームワークが使用されており、ASM が有効になっている場合に、ユーザーのログインとサインアップイベントの検出を試みます。
ユーザーアクティビティを手動で追跡する方法については、ユーザーアクティビティの追跡をお読みください。または、自動追跡のオプトアウト方法を参照してください。
特定のパラメーターを検出のトリガーから除外する
ASM のシグナル、あるいはセキュリティトレースが誤検出される場合があります。例えば、ASM が同じセキュリティトレースを繰り返し検出し、シグナルが発生したものの、そのシグナルが確認され、脅威ではないと判断されることがあります。
パスリストにエントリーを追加して、ルールからイベントを無視することで、ノイズの多いシグナルパターンを排除し、正当にセキュリティトレースに焦点を当てることができます。
パスリストエントリーを追加するには、次のいずれかを実行します。
- ASM シグナルのシグナルをクリックし、Add to passlist という提案アクションの横にある Add Entry というリンクをクリックします。この方法では、対象となるサービスのエントリーが自動的に追加されます。
- パスリスト構成に移動し、独自の基準に基づいて新しいパスリストエントリーを手動で構成します。
注: パスリストエントリーに一致するリクエスト (トレース) は請求されません。
データセキュリティへの配慮
Datadog で収集するデータには、除外、難読化、フィルタリング、修正したり、収集しないことを選択したりするべき機密情報が含まれることがあります。さらに、データは脅威検出が不正確になったり、サービスのセキュリティが Datadog で正確にされないという問題の原因となるシンセティックトラフィックを含む場合もあります。
デフォルトでは、ASM はセキュリティトレースから情報を収集し、そのリクエストが疑わしいと判定された理由を理解するのに役立ちます。データを送信する前に、ASM はデータが機密であることを示すパターンとキーワードをスキャンします。データが機密であると判断された場合、それは <redacted> フラグに置き換えられます。これにより、リクエストは疑わしいが、データセキュリティの懸念からリクエストデータを収集されなかったことがわかります。認証済みリクエストのユーザー ID などのユーザー関連データは、マスキングされるデータの対象ではありません。
ユーザーのデータを保護するために、ASM では機密データスキャンがデフォルトで有効になっています。以下の環境変数を使用することで、構成をカスタマイズすることができます。スキャンは RE2 構文に基づいています。スキャンをカスタマイズするには、これらの環境変数の値を有効な RE2 パターンに設定します。
DD_APPSEC_OBFUSCATION_PARAMETER_KEY_REGEXP - 値が一般的に機密データを含むキーをスキャンするためのパターン。見つかった場合、そのキーと関連する値およびすべての子ノードが編集されます。DD_APPSEC_OBFUSCATION_PARAMETER_VALUE_REGEXP - 機密データを示す可能性のある値をスキャンするためのパターン。見つかった場合、その値とすべての子ノードが編集されます。
Ruby のみ、ddtrace バージョン 1.1.0 からまた、コードでスキャンパターンを構成することも可能です。
Datadog.configure do |c|
# ...
# カスタム RE2 正規表現を設定する
c.appsec.obfuscator_key_regex = '...'
c.appsec.obfuscator_value_regex = '...'
end
以下は、デフォルトで機密と判定されるデータの例です。
pwd、password、ipassword、pass_phrasesecretkey、api_key、private_key、public_keytokenconsumer_id、consumer_key、consumer_secretsign、signed、signaturebearerauthorizationBEGIN PRIVATE KEYssh-rsa
Datadog Agent やライブラリの他のメカニズムで、機密データを削除するために使用できるものについては、APM データセキュリティを参照してください。
自動ユーザーアクティビティイベントトラッキングモードで、自動ユーザーアクティビティトラッキングモードとその構成方法に関する情報をご覧ください。Datadog ライブラリが、モードの略称 (ident|anon|disabled) を使用して DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE 環境変数を使用して自動インスツルメンテーションを構成できる方法についてもご覧ください。
カスタムブロッキングページまたはペイロードの構成
ブロックされたリクエストは JSON または HTML のコンテンツを特徴としています。HTTP ヘッダーの Accept]103 が text/html のように HTML を指している場合、HTML コンテンツが使われます。そうでない場合は JSON が使われます。
どちらのコンテンツも Datadog Tracer ライブラリパッケージに埋め込まれ、ローカルにロードされます。GitHub 上の Datadog Java トレーサーのソースコードで HTML および JSON のテンプレートの例をご覧ください。
HTML と JSON のコンテンツは、アプリケーションのデプロイメントファイル内の DD_APPSEC_HTTP_BLOCKED_TEMPLATE_HTML と DD_APPSEC_HTTP_BLOCKED_TEMPLATE_JSON 環境変数を使って変更することができます。
例:
DD_APPSEC_HTTP_BLOCKED_TEMPLATE_HTML=<path_to_file.html>
または、構成エントリを使用することもできます。
Java の場合は、以下を追加します。
dd.appsec.http.blocked.template.html = '<path_to_file.html>'
dd.appsec.http.blocked.template.json = '<path_to_file.json>'
Ruby の場合は、以下を追加します。
# config/initializers/datadog.rb
Datadog.configure do |c|
# text/html ブロックページを構成するには
c.appsec.block.templates.html = '<path_to_file.html>'
# application/json ブロックページを構成するには
c.appsec.block.templates.json = '<path_to_file.json>'
end
PHP の場合は、以下を追加します。
; 98-ddtrace.ini
; ブロックされたリクエストで提供される HTML 出力をカスタマイズします
datadog.appsec.http_blocked_template_html = <path_to_file.html>
; ブロックされたリクエストで提供される JSON 出力をカスタマイズします
datadog.appsec.http_blocked_template_json = <path_to_file.json>
Node.js の場合は、以下を追加します。
require('dd-trace').init({
appsec: {
blockedTemplateHtml: '<path_to_file.html>',
blockedTemplateJson: '<path_to_file.json>'
}
})
デフォルトでは、ブロックされたアクションに応答して表示されるページは次のようになります。
その他の参考資料
