Seguimiento y Protección de Usuarios
Este producto no es compatible con el
sitio Datadog seleccionado. (
).
Resumen
Instrumenta tus servicios y haz seguimiento de la actividad de los usuarios para detectar y bloquear a los actores maliciosos.
Agrega información de usuario autenticado en las trazas para identificar y bloquear a los actores maliciosos que apuntan a tu superficie de ataque autenticada. Para hacer esto, establece la etiqueta de ID de usuario en la traza APM en ejecución, proporcionando la instrumentación necesaria para que AAP bloquee a los atacantes autenticados. Esto permite que AAP asocie ataques y eventos de lógica de negocio a los usuarios.
Haz seguimiento de los inicios de sesión y la actividad del usuario para detectar tomas de control de cuentas y abusos de lógica de negocio con reglas de detección listas para usar, y para finalmente bloquear a los atacantes.
La actividad de usuario personalizada para la cual hay reglas de detección listas para usar es la siguiente:
Puede agregar etiquetas personalizadas a su tramo raíz, o utilizar las funciones de instrumentación descritas a continuación.
Utilice la API del trazador de Java para agregar etiquetas personalizadas a un tramo raíz y añadir información del usuario para que pueda hacer seguimiento de las solicitudes autenticadas en la aplicación.
Las etiquetas de seguimiento de usuarios se aplican en el tramo raíz y comienzan con el prefijo usr seguido del nombre del campo. Por ejemplo, usr.name es una etiqueta de seguimiento de usuarios que rastrea el nombre del usuario.
Nota: Verifique que ha agregado las dependencias necesarias a su aplicación.
El ejemplo a continuación muestra cómo obtener el tramo raíz, agregar las etiquetas de seguimiento de usuario relevantes y habilitar la capacidad de bloqueo de usuarios:
import io.opentracing.Span;
import io.opentracing.util.GlobalTracer;
import datadog.appsec.api.blocking.Blocking;
import datadog.trace.api.interceptor.MutableSpan;
// Get the active span
final Span span = GlobalTracer.get().activeSpan();
if ((span instanceof MutableSpan)) {
MutableSpan localRootSpan = ((MutableSpan) span).getLocalRootSpan();
// Setting the mandatory user id tag
localRootSpan.setTag("usr.id", "d131dd02c56eec4");
// Setting optional user monitoring tags
localRootSpan.setTag("usr.name", "Jean Example");
localRootSpan.setTag("usr.email", "jean.example@example.com");
localRootSpan.setTag("usr.session_id", "987654321");
localRootSpan.setTag("usr.role", "admin");
localRootSpan.setTag("usr.scope", "read:message, write:files");
}
Blocking
.forUser("d131dd02c56eec4")
.blockIfMatch();
El paquete del rastreador .NET proporciona la función SetUser(), que le permite realizar el seguimiento de solicitudes autenticadas al agregar información del usuario a la traza.
El ejemplo a continuación muestra cómo agregar las etiquetas de seguimiento de usuario relevantes y habilitar la capacidad de bloqueo de usuarios:
using Datadog.Trace;
// ...
var userDetails = new UserDetails()
{
// the systems internal identifier for the users
Id = "d41452f2-483d-4082-8728-171a3570e930",
// the email address of the user
Email = "test@adventure-works.com",
// the user's name, as displayed by the system
Name = "Jane Doh",
// the user's session id
SessionId = "d0632156-132b-4baa-95b2-a492c5f9cb16",
// the role the user is making the request under
Role = "standard",
};
Tracer.Instance.ActiveScope?.Span.SetUser(userDetails);
Para información y opciones, lea la documentación del rastreador .NET.
El paquete del rastreador Go proporciona la función SetUser(), que le permite realizar el seguimiento de solicitudes autenticadas al agregar información del usuario a la traza. Para más opciones, consulte la documentación del rastreador Go (o documentación v1).
Este ejemplo muestra cómo recuperar el tramo del rastreador actual, usarlo para establecer etiquetas de seguimiento de usuario y habilitar la capacidad de bloqueo de usuarios. Note: This documentation uses v2 of the Go tracer, which Datadog recommends for all users. If you are using v1, see the migration guide to upgrade to v2.
import (
"github.com/DataDog/dd-trace-go/v2/appsec"
)
func handler(w http.ResponseWriter, r *http.Request) {
if appsec.SetUser(r.Context(), "my-uid") != nil {
// The user must be blocked by aborting the request handler asap.
// The blocking response is automatically handled and sent by the appsec middleware.
return
}
}
Utilice una de las siguientes API para agregar información del usuario a una traza para que pueda realizar el seguimiento de las solicitudes autenticadas en la aplicación:
A partir de ddtrace 1.1.0, el método Datadog::Kit::Identity.set_user está disponible. Esta es la API recomendada para agregar información del usuario a las trazas:
# Get the active trace
trace = Datadog::Tracing.active_trace
# Set mandatory user id tag
Datadog::Kit::Identity.set_user(trace, id: 'd131dd02c56eeec4')
# Or set any of these optional user monitoring tags
Datadog::Kit::Identity.set_user(
trace,
# mandatory id
id: 'd131dd02c56eeec4',
# optional tags with known semantics
name: 'Jean Example',
email:, 'jean.example@example.com',
session_id:, '987654321',
role: 'admin',
scope: 'read:message, write:files',
# optional free-form tags
another_tag: 'another_value',
)
Si Datadog::Kit::Identity.set_user no satisface tus necesidades, puedes usar set_tag en su lugar.
Las etiquetas de seguimiento de usuario se aplican en la traza y comienzan con el prefijo usr. seguido del nombre del campo. Por ejemplo, usr.name es una etiqueta de seguimiento de usuario que rastrea el nombre del usuario.
El ejemplo a continuación muestra cómo obtener la traza activa y agregar etiquetas de seguimiento de usuario relevantes:
Notas:
- Los valores de las etiquetas deben ser cadenas.
- La etiqueta
usr.id es obligatoria.
# Get the active trace
trace = Datadog::Tracing.active_trace
# Set mandatory user id tag
trace.set_tag('usr.id', 'd131dd02c56eeec4')
# Set optional user monitoring tags with known sematics
trace.set_tag('usr.name', 'Jean Example')
trace.set_tag('usr.email', 'jean.example@example.com')
trace.set_tag('usr.session_id', '987654321')
trace.set_tag('usr.role', 'admin')
trace.set_tag('usr.scope', 'read:message, write:files')
# Set free-form tags:
trace.set_tag('usr.another_tag', 'another_value')
El rastreador de PHP proporciona la función \DDTrace\set_user(), que te permite monitorear y bloquear solicitudes autenticadas.
\DDTrace\set_user() agrega las etiquetas de usuario relevantes y los metadatos a la traza y realiza automáticamente el bloqueo de usuarios.
El siguiente ejemplo muestra cómo establecer etiquetas de seguimiento de usuarios y habilitar la capacidad de bloqueo de usuarios:
<?php
// Blocking is performed internally through the set_user call.
\DDTrace\set_user(
// A unique identifier of the user is required.
'123456789',
// All other fields are optional.
[
'name' => 'Jean Example',
'email' => 'jean.example@example.com',
'session_id' => '987654321',
'role' => 'admin',
'scope' => 'read:message, write:files',
]
);
?>
El paquete de rastreo de Node proporciona la función tracer.setUser(user), que te permite realizar el seguimiento de solicitudes autenticadas al agregar información del usuario a la traza.
El ejemplo a continuación muestra cómo agregar etiquetas de seguimiento de usuario relevantes y habilitar la capacidad de bloqueo de usuarios:
const tracer = require('dd-trace').init()
function handle () {
tracer.setUser({
id: '123456789', // *REQUIRED* Unique identifier of the user.
// All other fields are optional.
email: 'jane.doe@example.com', // Email of the user.
name: 'Jane Doe', // User-friendly name of the user.
session_id: '987654321', // Session ID of the user.
role: 'admin', // Role the user is making the request under.
scope: 'read:message, write:files', // Scopes or granted authorizations the user currently possesses.
// Arbitrary fields are also accepted to attach custom data to the user (RBAC, Oauth, etc…)
custom_tag: 'custom data'
})
// Set the currently authenticated user and check whether they are blocked
if (tracer.appsec.isUserBlocked(user)) { // also set the currently authenticated user
return tracer.appsec.blockRequest(req, res) // blocking response is sent
}
}
Para información y opciones, lea la documentación del rastreador de Node.js.
A partir de dd-trace-py v3.7, puede usar el nuevo SDK del rastreador de Python para realizar el seguimiento de usuarios y eventos de usuario.
En versiones anteriores, puede realizar el seguimiento de solicitudes autenticadas al agregar información del usuario a la traza con la función set_user proporcionada por el paquete de rastreo de Python.
A partir de dd-trace-py v3.7, este ejemplo muestra cómo establecer etiquetas de seguimiento de usuarios y habilitar la capacidad de bloqueo de usuarios:
from ddtrace.appsec.track_user_sdk import track_user
# starting in dd-trace-py v3.17, you can use track_user_id
# without login information, but user_id is required
# this is the recommended API since it enables best product functionality with least room for mistakes
track_user_id(
"some_user_id",
session_id="session_id",
metadata={
"name": "John",
"email": "test@test.com",
"scope": "some_scope",
"role": "manager",
},
)
# Alternatively, you can use track_user
user_login = "some_login"
# to enable all features (user_id and/or session_id monitoring and blocking),
# make sure you provide the corresponding optional arguments
track_user(
user_login,
user_id="some_user_id",
session_id="session_id",
metadata={
"name": "John",
"email": "test@test.com",
"scope": "some_scope",
"role": "manager",
},
)
Este ejemplo muestra cómo establecer etiquetas de seguimiento de usuarios y habilitar la capacidad de bloqueo de usuarios utilizando la API heredada; sin embargo, se recomienda usar el nuevo SDK de seguimiento de usuarios, descrito anteriormente.
from ddtrace.contrib.trace_utils import set_user
from ddtrace import tracer
# Call set_user() to trace the currently authenticated user id
user_id = "some_user_id"
set_user(tracer, user_id, name="John", email="test@test.com", scope="some_scope",
role="manager", session_id="session_id", propagate=True)
Una nota sobre usr.id y usr.login: La investigación del abuso de inicio de sesión se basa en dos conceptos similares, pero diferentes. usr.id contiene el identificador único de la cuenta de usuario en la base de datos. Es único e inmutable. No está disponible cuando alguien intenta iniciar sesión en una cuenta que no existe. El bloqueo de usuario se dirige a usr.id.El usuario generalmente no es consciente de su ID de usuario. En cambio, confía en identificadores mutables (número de teléfono, nombre de usuario, dirección de correo electrónico...). La cadena utilizada por el usuario para iniciar sesión en una cuenta debe ser reportada como usr.login en los eventos de inicio de sesión.Si no se proporciona usr.login, se utilizará usr.id en su lugar.
A partir de dd-trace-java v1.8.0, puede usar la API de Java del rastreador para rastrear eventos de usuario.
Los siguientes ejemplos muestran cómo rastrear eventos de inicio de sesión o eventos personalizados (usando el registro como ejemplo).
import datadog.trace.api.EventTracker;
import datadog.trace.api.GlobalTracer;
public class LoginController {
private User doLogin(String userName, String password) {
// this is where you get User based on userName/password credentials
User user = checkLogin(userName, password);
Map<String, String> metadata = new HashMap<>();
metadata.put("email", user.getEmail());
metadata.put("usr.login", userName);
// If your system has multiple "tenants", please provide it. A tenant is an environment/group of user
metadata.put("usr.org", usr.getTenant());
// track user authentication success events
GlobalTracer
.getEventTracker()
.trackLoginSuccessEvent(user.getId(), metadata);
}
}
import datadog.trace.api.EventTracker;
import datadog.trace.api.GlobalTracer;
public class LoginController {
private User doLogin(String userName, String password) {
// this is where you get User based on userName/password credentials
User user = checkLogin(userName, password);
// if function returns null - user doesn't exist
boolean userExists = (user != null);
String userId = null;
Map<String, String> metadata = new HashMap<>();
metadata.put("usr.login", userName);
if (userExists != null) {
userId = getUserId(userName)
metadata.put("email", user.getEmail());
} else {
userId = userName;
}
// track user authentication error events
GlobalTracer
.getEventTracker()
.trackLoginFailureEvent(userId, userExists, metadata);
}
}
import datadog.trace.api.EventTracker;
import datadog.trace.api.GlobalTracer;
public class LoginController {
private User doSignup(String userId, String email) {
// this is where you create your user account
User user = createUser(userId, email);
Map<String, String> metadata = new HashMap<>();
metadata.put("usr.id", user.getId());
// track user signup events
GlobalTracer
.getEventTracker()
.trackCustomEvent("users.signup", metadata);
}
}
A partir de dd-trace-dotnet v2.23.0, puede usar la API de .NET del rastreador para rastrear eventos de usuario.
Los siguientes ejemplos muestran cómo rastrear eventos de inicio de sesión o eventos personalizados (usando el registro como ejemplo).
using Datadog.Trace.AppSec;
void OnLogonSuccess(string userId, string login...)
{
// metadata is optional
var metadata = new Dictionary<string, string>()
{
{ "usr.login", login }
};
EventTrackingSdk.TrackUserLoginSuccessEvent(userId, metadata);
// ...
}
using Datadog.Trace.AppSec;
void OnLogonFailure(string userId, string login, bool userExists, ...)
{
// If no userId can be provided, any unique user identifier (username, email...) may be used
// metadata is optional
var metadata = new Dictionary<string, string>()
{
{ "usr.login", login }
};
EventTrackingSdk.TrackUserLoginFailureEvent(userId, userExists, metadata);
// ...
}
void OnUserSignupComplete(string userId, ...)
{
// the metadata parameter is optional, but adding the "usr.id"
var metadata = new Dictionary<string, string>()
{
{ "usr.id", userId }
};
// Leveraging custom business logic tracking to track user signups
EventTrackingSdk.TrackCustomEvent("users.signup", metadata);
// ...
}
A partir de dd-trace-go v1.47.0, puede usar la API de Go del rastreador para rastrear eventos de usuario.
Los siguientes ejemplos muestran cómo rastrear eventos de inicio de sesión o eventos personalizados (usando el registro como ejemplo). Note: This documentation uses v2 of the Go tracer, which Datadog recommends for all users. If you are using v1, see the migration guide to upgrade to v2.
import (
"github.com/DataDog/dd-trace-go/v2/appsec"
)
func handler(w http.ResponseWriter, r *http.Request) {
metadata := make(map[string]string) /* optional extra event metadata */
userdata := /* optional extra user data */
metadata["usr.login"] = "user-email"
// Track login success, replace `my-uid` by a unique identifier of the user (such as numeric, username, and email)
if appsec.TrackUserLoginSuccessEvent(r.Context(), "my-uid", metadata, userdata) != nil {
// The given user id is blocked and the handler should be aborted asap.
// The blocking response will be sent by the appsec middleware.
return
}
}
import (
"github.com/DataDog/dd-trace-go/v2/appsec"
)
func handler(w http.ResponseWriter, r *http.Request) {
exists := /* whether the given user id exists or not */
metadata := make(map[string]string) /* optional extra event metadata */
metadata["usr.login"] = "user-email"
// Replace `my-uid` by a unique identifier of the user (numeric, username, email...)
appsec.TrackUserLoginFailureEvent(r.Context(), "my-uid", exists, metadata)
}
import (
"github.com/DataDog/dd-trace-go/v2/appsec"
)
func handler(w http.ResponseWriter, r *http.Request) {
metadata := map[string]string{"usr.id": "my-uid"}
// Leveraging custom business logic tracking to track user signups
appsec.TrackCustomEvent(r.Context(), "users.signup", metadata)
}
A partir de dd-trace-rb v1.9.0, puede usar la API de Ruby del rastreador para rastrear eventos de usuario. La versión v2.19.0 de dd-trace-rb introduce nuevos métodos bajo el espacio de nombres Datadog::Kit::AppSec::Events::V2. Los métodos existentes de seguimiento de eventos se mantienen para compatibilidad.
Los siguientes ejemplos muestran cómo rastrear eventos de inicio de sesión o eventos personalizados (usando el registro como ejemplo).
require 'datadog/kit/appsec/events/v2'
login = 'user@some.com'
user = 'some-user-id' # any unique string identifier (i.e. id, username or email)
user = { # or user could be a Hash with an id and other fields
id: 'some-user-id', # id is mandatory
email: 'user@some.com' # other fields are optional
}
metadata = { 'some.key': 'value' } # any arbitrary key-value pairs
Datadog::Kit::AppSec::Events::V2.track_user_login_success(login, user, metadata)
require 'datadog/kit/appsec/events/v2'
login = 'user@some.com' # the string used by the user to log in
user_exists = true # if the user login exists in database for example
metadata = { 'some.key': 'value' } # any arbitrary key-value pairs
Datadog::Kit::AppSec::Events::V2.track_user_login_failure(login, user_exists, metadata)
require 'datadog/kit/appsec/events'
span = nil
trace = Datadog::Tracing.active_trace
metadata = { 'usr.id': 'some-user-id' }
event_name = 'users.signup'
Datadog::Kit::AppSec::Events.track(event_name, trace, span, metadata)
Migrando a los nuevos métodos de éxito y fallo de inicio de sesión
Los nuevos métodos en Datadog::Kit::AppSec::Events::V2 introducen un orden de parámetros más intuitivo y una separación de preocupaciones más clara. Aquí están los cambios clave:
- El identificador de inicio de sesión (correo electrónico, nombre de usuario) es el primer parámetro y es obligatorio.
- El objeto/ID de usuario es opcional en eventos de éxito y se ha eliminado de los eventos de fracaso.
- Los metadatos se han simplificado y ya no requieren el campo
usr.login. - Los parámetros de traza y de tramo ya no son obligatorios y se infieren automáticamente.
Nota: los métodos heredados track_login_success y track_login_failure están obsoletos en favor de los nuevos métodos track_user_login_success y track_user_login_failure, respectivamente.
En el siguiente ejemplo, el código comentado ya no es necesario.
require 'datadog/kit/appsec/events/v2'
login = 'user@some.com' # new mandatory argument
user = { # same as before, but now the Hash is optional
id: 'some-user-id', # providing a user ID will nonetheless help with post-compromised activity correlation
email: 'user@some.com'
}
metadata = {
# 'usr.login': 'user@some.com', this is no longer necessary in metadata, but became the required first parameter
'some.key': 'value'
}
# deprecated
# Datadog::Kit::AppSec::Events.track_login_success(trace, span, user: user, **metadata)
Datadog::Kit::AppSec::Events::V2.track_user_login_success(login, user, metadata)
require 'datadog/kit/appsec/events/v2'
login = 'user@some.com' # new mandatory argument
user_exists = true # if the user login exists in database for example
metadata = {
# 'usr.login': 'user@some.com', this is no longer necessary in metadata, but became the required first parameter
'some.key': 'value'
}
# deprecated
# Datadog::Kit::AppSec::Events.track_login_failure(trace, span, user_exists: user_exists, user_id: login, **metadata)
Datadog::Kit::AppSec::Events::V2.track_user_login_failure(login, user_exists, metadata)
A partir de dd-trace-php v0.84.0, puedes usar la API del rastreador de PHP para rastrear eventos de usuario. La versión v1.11.0 de dd-trace-php introduce nuevos métodos bajo el espacio de nombres \datadog\appsec\v2\. Los métodos existentes de rastreo de eventos se mantienen para compatibilidad.
Los siguientes ejemplos muestran cómo rastrear eventos de inicio de sesión o eventos personalizados (usando el registro como ejemplo).
<?php
$user = [
'id' => 'user-id', // id is mandatory. If no ID is available, any unique identifier works (username, email...)
'email' => 'user@email.com' // other fields are optional
]; //User data can be provided as an array
$user = 'user-id'; //or user could be just an ID
$login = 'user@email.com';
$metadata = [ 'key' => 'value' ]; // you can add arbitrary fields to metadata
// Log a successful user authentication event
// user and metadata are optional
\datadog\appsec\v2\track_user_login_success($login, $user, $metadata);
?>
<?php
$login = 'user-id'; // the string used by the user to log in
$userExists = true; // if the user login exists in database or not
$metadata = [ 'key' => 'value' ]; // you can add arbitrary fields to metadata
// Log a failed user authentication event
// userExists is optional and it defaults to false
// metadata is optional
\datadog\appsec\v2\track_user_login_failure($login, $userExists, $metadata);
?>
<?php
$eventName = 'users.signup'; // custom event name
$metadata = ['usr.id' => $id]; // you can add arbitrary fields to metadata
\datadog\appsec\track_custom_event($eventName, $metadata);
?>
Migrando a los nuevos métodos de inicio de sesión para el éxito y el fallo
Los nuevos métodos en el espacio de nombres \datadog\appsec\v2\ introducen un orden de parámetros más intuitivo y una separación de preocupaciones más clara. Aquí están los cambios clave:
- El identificador de inicio de sesión (correo electrónico, nombre de usuario) es el primer parámetro y es obligatorio.
- El arreglo/ID de usuario es opcional en eventos de éxito y se ha eliminado de los eventos de fracaso.
- Los metadatos se han simplificado y ya no requieren el campo
usr.login.
Nota: los métodos heredados \datadog\appsec\track_user_login_success_event y \datadog\appsec\track_user_login_failure_event están obsoletos en favor de los nuevos métodos \datadog\appsec\v2\track_user_login_success y \datadog\appsec\v2\track_user_login_failure, respectivamente.
En el siguiente ejemplo, el código comentado ya no es necesario.
<?php
// in a controller:
$user = [
'id' => 'user-id', // id is mandatory. If no ID is available, any unique identifier works (username, email...)
'email' => 'user@email.com' // other fields are optional
]; // same as before, but now the array is optional. Providing a user ID nonetheless helps with post-compromised activity correlation
$login = 'user@email.com'; // new mandatory argument
$metadata = [
// 'usr.login' => 'user@email.com', this is no longer necessary in metadata. Must be the first argument
'key' => 'value'
];
// \datadog\appsec\track_user_login_success_event($user, $metadata) // deprecated
\datadog\appsec\v2\track_user_login_success($login, $user, $metadata);
?>
<?php
$userId = 'user-id'; // No longer mandatory, but helpful when available
$login = 'user@email.com'; // new mandatory argument
$userExists = true;
$metadata = [
// 'usr.login' => 'user@email.com', this is no longer necessary in metadata. Must be the first argument
'usr.id' => 'user-id', // Helps with correlating login failures with the rest of the user activity
'key' => 'value'
];
// \datadog\appsec\track_user_login_failure_event($userId, $exists, $metadata); // deprecated
\datadog\appsec\v2\track_user_login_failure($login, $userExists, $metadata);
A partir de dd-trace-js v3.13.1, puedes usar la API del rastreador de Node.js para rastrear eventos de usuario. La versión v5.48.0 de dd-trace-js introduce nuevos métodos bajo el espacio de nombres eventTrackingV2. Los métodos existentes de rastreo de eventos se mantienen para compatibilidad.
Los siguientes ejemplos muestran cómo rastrear eventos de inicio de sesión o eventos personalizados (usando el registro como ejemplo).
const tracer = require('dd-trace')
// in a controller:
const user = {
id: 'user-id', // id is mandatory. If no ID is available, any unique identifier works (username, email...)
email: 'user@email.com' // other fields are optional
}
const user = 'user-id' // user could be just the ID
const login = 'user@email.com'
const metadata = { 'key': 'value' } // you can add arbitrary fields
// Log a successful user authentication event
// user and metadata are optional
tracer.appsec.eventTrackingV2.trackUserLoginSuccess(login, user, metadata)
const tracer = require('dd-trace')
// in a controller:
const login = 'user-id' // the string used by the user to log in
const userExists = true // if the user login exists in database for example
const metadata = { 'key': 'value' } // you can add arbitrary fields
// Log a failed user authentication event
// userExists is optional and it is defaulted to false
// metadata is optional
tracer.appsec.eventTrackingV2.trackUserLoginFailure(login, userExists, metadata)
const tracer = require('dd-trace')
// in a controller:
const eventName = 'users.signup'
const metadata = { 'usr.id': 'user-id' }
tracer.appsec.trackCustomEvent(eventName, metadata)
Migrando a los nuevos métodos de inicio de sesión para el éxito y el fallo
Los nuevos métodos en eventTrackingV2 introducen un orden de parámetros más intuitivo y una separación de preocupaciones más clara. Aquí están los cambios clave:
- El identificador de inicio de sesión (correo electrónico, nombre de usuario) es el primer parámetro y es obligatorio.
- El objeto/ID de usuario es opcional en eventos de éxito y se ha eliminado de los eventos de fracaso.
- Los metadatos se han simplificado y ya no requieren el campo
usr.login.
Nota: los métodos heredados trackUserLoginSuccessEvent y trackUserLoginFailureEvent están obsoletos en favor de los nuevos métodos eventTrackingV2.trackUserLoginSuccess y eventTrackingV2.trackUserLoginFailure, respectivamente.
En el siguiente ejemplo, el código comentado ya no es necesario.
const tracer = require('dd-trace')
// in a controller:
const user = {
id: 'user-id',
email: 'user@email.com'
} // same as before, but now the object is optional. Providing a user ID will nonetheless help with post-compromised activity correlation
const login = 'user@email.com' // new mandatory argument
const metadata = {
// 'usr.login': 'user@email.com', this is no longer necessary in metadata. Must be the main argument
'key': 'value'
}
// tracer.appsec.trackUserLoginSuccessEvent(user, metadata) // deprecated
tracer.appsec.eventTrackingV2.trackUserLoginSuccess(login, user, metadata)
const tracer = require('dd-trace')
// in a controller with the deprecated method:
const userId = 'user-id' // No longer mandatory, but helpful when available
const login = 'user@email.com' // new mandatory argument
const userExists = true
const metadata = {
// 'usr.login': 'user@email.com', this is no longer necessary in metadata. Must be the first argument
'usr.id': userId, // Helps with correlating login failures with the rest of the user activity
'key': 'value'
}
// tracer.appsec.trackUserLoginFailureEvent(userId, userExists, metadata) // deprecated
tracer.appsec.eventTrackingV2.trackUserLoginFailure(login, userExists, metadata)
A partir de dd-trace-py v1.9.0, puedes usar la API del rastreador de Python para rastrear eventos de usuario.
A partir de dd-trace-py v3.7, puedes usar el nuevo SDK del rastreador de Python para rastrear usuarios y eventos de usuarios.
Los siguientes ejemplos muestran cómo rastrear eventos de inicio de sesión, eventos de registro o eventos personalizados.
Disponible desde dd-trace-py v3.7, track_user_sdk proporciona 5 funciones:
track_login_successtrack_login_failuretrack_signuptrack_custom_eventtrack_user
Disponible desde dd-trace-py v3.17, track_user_sdk proporciona esta función adicional:
from ddtrace.appsec import track_user_sdk
## This function should be called when a user successfully logs in to the
# application.
# user_id and metadata are optional
metadata = {"usr.email": "user@email.com"}
track_user_sdk.track_login_success(
"some_user_login",
user_id="some_user_id",
metadata=metadata,
)
## This function should be called when a user fails to log in to the
# application.
# user_id and metadata are optional
metadata = {"usr.error": "login failure"}
# If you want to track the login failure as a "login do not exists"
exists = False
track_user_sdk.track_login_failure(
"some_user_login",
exists,
metadata=metadata,
)
# If you want to track the login failure as a "login exists but
# authentification failed
exists = True
track_user_sdk.track_login_failure(
"some_user_login",
exists,
user_id="some_user_id",
metadata=metadata,
)
## This function should be called when a user successfully signs up for
# the application.
# user_id, success and metadata are optional, success is True by default.
metadata = {"usr.email": "user@email.com"}
track_user_sdk.track_signup(
"some_user_login",
user_id="some_user_id",
success=True,
metadata=metadata,
)
## This function should be called when a custom user event occurs in the
# application.
# metadata is required
metadata = {
"usr.address": {"line1": "221b Baker Street", "city": "London"},
"phone": "0123456789",
}
track_user_sdk.track_custom_event("my_event_name", metadata)
El siguiente ejemplo es una aplicación de juguete completamente funcional que utiliza el SDK de seguimiento de usuarios con una base de datos de usuarios basada en memoria. Este ejemplo ilustra el uso posible del SDK, pero no proporciona los requisitos necesarios de una aplicación real, como un modelo de datos persistente o un sistema de autenticación seguro.
from uuid import uuid4
import ddtrace.auto # noqa: F401
from ddtrace.appsec.track_user_sdk import (
track_custom_event,
track_login_failure,
track_login_success,
track_signup,
track_user,
)
from fastapi import FastAPI, HTTPException, Request
from fastapi.responses import JSONResponse
from pydantic import BaseModel
from starlette.middleware.sessions import SessionMiddleware
class User(BaseModel):
user_id: str
username: str
password: str
users: dict[str, User] = {}
app = FastAPI()
@app.middleware("http")
async def track_user_middleware(request: Request, call_next):
user = request.session.get("username")
session_id = request.session.get("session_id")
if user and session_id and user in users:
track_user(user, users[user].user_id, session_id=session_id)
return await call_next(request)
session_secret = "just-a-test"
app.add_middleware(SessionMiddleware, secret_key=session_secret)
@app.post("/signup")
async def signup(username: str, password: str):
if username in users:
return JSONResponse(
{"error": "User already exists"},
status_code=400,
)
user_id = str(uuid4())
users[username] = User(
user_id=user_id,
username=username,
password=password,
)
track_signup(username, user_id, success=True)
return {"message": "User created successfully"}
@app.post("/login")
async def login(username: str, password: str, request: Request):
if username not in users:
track_login_failure(username, False)
return JSONResponse(
{"error": "Invalid user password combination"},
status_code=403,
)
if users[username].password != password:
track_login_failure(username, True, users[username].user_id)
return JSONResponse(
{"error": "Invalid user password combination"},
status_code=403,
)
track_login_success(username, users[username].user_id)
request.session["username"] = username
request.session["session_id"] = str(uuid4())
return {"message": "Login successful"}
@app.get("/whoami")
async def whoami(request: Request) -> User:
if (
"username" not in request.session
or request.session["username"] not in users
):
raise HTTPException(status_code=403, detail="User not logged in")
track_custom_event(
"user_has_forgotten_who_they_are",
metadata={
"username": request.session["username"],
"session_id": request.session["session_id"],
},
)
return users[request.session["username"]]
El método preferido es utilizar el nuevo SDK de seguimiento de usuarios (disponible desde dd-trace-py v1.9) en lugar de la API heredada.
from ddtrace.appsec.trace_utils import track_user_login_success_event
from ddtrace.appsec.trace_utils import track_user_login_failure_event
from ddtrace.appsec.trace_utils import track_custom_event
from ddtrace import tracer
metadata = {"usr.login": "user@email.com"}
# name, email, scope, role, session_id and propagate are optional arguments which
# default to None except propagate that defaults to True. They'll be
# passed to the set_user() function
track_user_login_success_event(tracer, "userid", metadata)
# exists indicates if the failed login user exists in the system
exists = False
# if no numeric userId is available, any unique identifier will do (username, email...)
track_user_login_failure_event(tracer, "userid", exists, metadata)
metadata = {"usr.id": "userid"}
event_name = "users.signup"
track_custom_event(tracer, event_name, metadata)
Si su servicio tiene AAP habilitado y Configuración Remota habilitada, puede crear una regla WAF personalizada para marcar cualquier solicitud que coincida con una etiqueta de lógica de negocio personalizada. Esto no requiere ninguna modificación a su aplicación y se puede hacer completamente desde Datadog.
Para comenzar, navegue a la página de Regla WAF Personalizada y haga clic en “Crear Nueva Regla”.
Esto abrirá un menú en el que puede definir su regla WAF personalizada. Al seleccionar la categoría “Lógica de Negocio”, podrá configurar un tipo de evento (por ejemplo, users.password_reset). Luego puede seleccionar el servicio que desea rastrear y un punto de conexión específico. También puede usar la condición de la regla para apuntar a un parámetro específico para identificar el flujo de código que desea instrumentar. Cuando la condición coincide, la biblioteca etiqueta la traza y la marca para ser enviada a AAP. Si no necesitas la condición, puedes establecer una condición amplia para que coincida con todo.
Una vez guardada, la regla se despliega en las instancias del servicio que tienen habilitada la Configuración Remota.
Seguimiento automático de eventos de actividad del usuario
Cuando AAP está habilitado, las bibliotecas de instrumentación de Datadog intentan detectar automáticamente los eventos de actividad del usuario.
Los eventos que se pueden detectar automáticamente son:
users.login.successusers.login.failureusers.signup
Modos de seguimiento automático de eventos de actividad del usuario
El seguimiento automático de la actividad del usuario ofrece los siguientes modos:
identification modo (nombre corto: ident):- Este modo es el predeterminado y siempre recopila el ID del usuario o hace el mejor esfuerzo.
- El ID del usuario se recopila en el éxito y en el fallo del inicio de sesión. Con el fallo, el ID del usuario se recopila independientemente de si el usuario existe o no.
- Cuando el marco instrumentado no proporciona claramente un ID de usuario, sino más bien un objeto de usuario estructurado, el ID del usuario se determina en función del mejor esfuerzo basado en los nombres de los campos del objeto. Esta lista de nombres de campos se considera, ordenada por prioridad:
- Si no hay un ID de usuario disponible o encontrado, el evento del usuario no se emite.
anonymization modo (nombre corto: anon):- Este modo es el mismo que
identification, pero anonimiza el ID del usuario al aplicar un hash (SHA256) y recortar el hash resultante.
disabled modo:- Las bibliotecas de AAP no recogen ningún ID del usuario de sus instrumentaciones automatizadas.
- No se emiten eventos de inicio de sesión de usuario.
Todos los modos solo afectan la instrumentación automatizada. Los modos no se aplican a la recolección manual. La recolección manual se configura utilizando un SDK, y esos ajustes no son anulados por la instrumentación automatizada.
Configuración manual
Las bibliotecas de Datadog te permiten configurar la auto-instrumentación utilizando la variable de entorno DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE con el nombre corto para el modo: ident|anon|disabled.
El modo predeterminado es el modo identification (nombre corto: ident).
Por ejemplo, DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE=anon.
Modos obsoletos
Los modos anteriores están obsoletos, pero la compatibilidad se mantendrá hasta la próxima versión importante.
Los siguientes modos están obsoletos:
safe modo: La biblioteca de trazas no incluye ninguna información de PII en los metadatos de los eventos. La biblioteca de trazadores intenta recopilar el ID del usuario, y solo si el ID del usuario es un GUID válido.extended modo: La biblioteca de trazas intenta recopilar el ID del usuario y el correo electrónico del usuario. En este modo, Datadog no realiza la verificación de que el tipo del ID de usuario sea un GUID. La biblioteca de traza informa cualquier valor que se pueda extraer del evento.
Nota: Podría haber casos en los que la biblioteca de traza no pueda extraer ninguna información del evento del usuario. El evento se reportaría con metadatos vacíos. En esos casos, utiliza el SDK para instrumentar manualmente los eventos del usuario.
Deshabilitando el seguimiento de eventos de actividad del usuario
Para deshabilitar la detección automática de actividad del usuario a través de tu AAP Software Catalog, cambia la variable de entorno del modo de seguimiento automático DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE a disabled en el servicio que deseas desactivar. Todos los modos solo afectan la instrumentación automática y requieren que Remote Configuration esté habilitada.
Para la configuración manual, puedes establecer la variable de entorno DD_APPSEC_AUTOMATED_USER_EVENTS_TRACKING_ENABLED a false en tu servicio y reiniciarlo. Esto debe configurarse en la aplicación que aloja el Datadog Tracing Library, y no en el Datadog Agent.