クライアント 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> フラグに置き換えられます。これにより、リクエストは疑わしいが、データセキュリティの懸念からリクエストデータを収集されなかったことがわかります。
ユーザーのデータを保護するために、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 データセキュリティを参照してください。
カスタムブロッキングページまたはペイロードの構成
The blocked requests feature JSON or HTML content. If the Accept HTTP header is pointing to HTML, like text/html, the HTML content is used. Otherwise, the JSON one is used.
Both sets of content are embedded in the Datadog Tracer library package and loaded locally. See examples of the templates for HTML and JSON in the Datadog Java tracer source code on GitHub.
The HTML and JSON content can both be changed using the DD_APPSEC_HTTP_BLOCKED_TEMPLATE_HTML and DD_APPSEC_HTTP_BLOCKED_TEMPLATE_JSON environment variables within your application deployment file.
Example:
DD_APPSEC_HTTP_BLOCKED_TEMPLATE_HTML=<path_to_file.html>
Alternatively, you can use the configuration entry.
For Java, add the following:
dd.appsec.http.blocked.template.html = '<path_to_file.html>'
dd.appsec.http.blocked.template.json = '<path_to_file.json>'
For Ruby, add the following:
# config/initializers/datadog.rb
Datadog.configure do |c|
# To configure the text/html blocking page
c.appsec.block.templates.html = '<path_to_file.html>'
# To configure the application/json blocking page
c.appsec.block.templates.json = '<path_to_file.json>'
end
For PHP, add the following:
; 98-ddtrace.ini
; Customises the HTML output provided on a blocked request
datadog.appsec.http_blocked_template_html = <path_to_file.html>
; Customises the JSON output provided on a blocked request
datadog.appsec.http_blocked_template_json = <path_to_file.json>
For Node.js, add the following:
require('dd-trace').init({
appsec: {
blockedTemplateHtml: '<path_to_file.html>',
blockedTemplateJson: '<path_to_file.json>'
}
})
By default, the page shown in response to a blocked action looks like this:
その他の参考資料
