Chaque fois qu’une requête est effectuée sur votre application, AppSignal collecte les paramètres envoyés avec cette requête.
Cela inclut les données de formulaire (POST), les paramètres de query et les clés dans les routes (par exemple, /user/:id/) dans certains frameworks.
Ces données peuvent contenir des informations identifiables par l’utilisateur telles que des noms, des adresses e-mail, des mots de passe, des codes d’authentification à deux facteurs, des jetons d’API, etc.
Pour protéger les données sensibles de votre application, vous devez vous assurer que ces données sont filtrées avant d’être envoyées aux serveurs AppSignal. De cette façon, votre application ne fuite aucune donnée sensible.
Votre application ne doit pas collecter d’informations identifiables sur l’utilisateur (telles que
noms personnels, adresses e-mail, mots de passe, etc.). Utilisez les outils décrits dans
ce guide pour limiter et filtrer ces données.
Filtrage des paramètres
Le filtrage de base des paramètres dans les intégrations AppSignal fonctionne avec une liste de blocage, une liste de clés à filtrer et à ne pas envoyer.
Vous pouvez définir une option « filter parameters » dans la configuration AppSignal avec une liste de clés de paramètres à filtrer.
Les valeurs des paramètres que vous avez configurés à filtrer seront remplacées par une valeur [FILTERED]. De cette façon, la liste des paramètres dans les données de l’application sur AppSignal.com
inclut toujours la clé du paramètre mais pas la valeur, vous gardez ainsi la visibilité qu’une valeur contenait des données potentiellement sensibles filtrées avant d’être envoyée à AppSignal.
Exemple
Par exemple, une application avec cette configuration AppSignal :
filter_parameters: ["password"]
Donne cette vue pour les paramètres d’une requête web sur AppSignal.com :
{
"password": "[FILTERED]"
}
Ce guide vous montrera comment configurer la liste de blocage de filtrage des paramètres de votre application en fonction du langage qu’elle utilise :
Ruby
Le gem AppSignal for Ruby dispose de deux méthodes de filtrage des paramètres :
Filtrage des paramètres AppSignal
Utilisez la liste de blocage pour le filtrage de base des paramètres. Ce filtrage des paramètres s’applique
à tous les paramètres de query d’une requête HTTP et à tout argument pour les jobs en arrière-plan.
Ce filtrage prend en charge le filtrage basé sur les clés pour les hashes, dont les valeurs seront remplacées par [FILTERED]. Il prend en charge les hashes imbriqués et les hashes imbriqués dans des arrays. Tout hash que nous rencontrons dans vos paramètres sera filtré.
Pour utiliser ce filtrage, ajoutez ce qui suit à votre fichier config/appsignal.yml dans le groupe d’environnement où vous souhaitez l’appliquer. La valeur filter_parameters est un tableau de chaînes.
Appsignal.configure do |config|
config.filter_parameters << "password"
end
Filtrage des paramètres Rails
Heureusement, Rails fournit un mécanisme de filtrage des paramètres de requête pour nettoyer les données des fichiers de log.
AppSignal s’appuie sur ce mécanisme de filtrage des paramètres de requête afin que vos logs de requêtes et les données de requête envoyées à AppSignal soient filtrés par une seule configuration. Si l’application doit filtrer les mêmes clés pour les paramètres de requête et les arguments des jobs rapportés pour différents gems Ruby, comme les arguments de jobs Sidekiq, il est nécessaire de configurer le filtrage des paramètres dans AppSignal en utilisant l’option filter_parameters pour inclure également les clés définies dans la configuration Rails, car la configuration de filtrage des paramètres Rails ne sera pas réutilisée pour ces gems.
Liste de blocage : filtrer des clés spécifiques
Il existe deux façons de déterminer quelles clés sont filtrées. La première consiste à ajouter des clés spécifiques à la liste de blocage. Dans l’exemple ci-dessous, la valeur de :secret dans tout post de l’application sera remplacée par [FILTERED].
module Blog
class Application < Rails::Application
config.filter_parameters << :secrets
end
end
L’inconvénient de cette approche est qu’elle est plus complexe pour les applications plus grandes et plus complexes, en particulier lors de l’utilisation de fonctionnalités comme accepts_nested_attributes_for. Si nous oublions d’ajouter explicitement des clés, elles ne seront pas filtrées.
Liste d’autorisation : autoriser des clés spécifiques
L’utilisation d’une lambda au lieu d’une liste de clés offre plus de flexibilité. Dans l’exemple suivant, nous utilisons une lambda pour configurer une liste d’autorisation au lieu d’une liste de blocage.
ALLOWED_KEYS_MATCHER = /((^|_)ids?|action|controller|code$)/.freeze
SANITIZED_VALUE = '[FILTERED]'.freeze
Rails.application.config.filter_parameters << lambda do |key, value|
unless key.match(ALLOWED_KEYS_MATCHER)
value.replace(SANITIZED_VALUE) if value.is_a?(String)
end
end
Vous pouvez faire en sorte que la lambda vérifie n’importe quelle clé que vous souhaitez, afin de pouvoir déterminer et utiliser une méthode de filtrage qui convient le mieux aux besoins de votre application.
Vous pouvez trouver des informations supplémentaires sur le filtrage des paramètres dans les guides Rails sur ActionController.
Elixir
Si votre application utilise Phoenix, vous pouvez utiliser le filtrage des paramètres Phoenix. Vous pouvez utiliser le filtrage intégré d’AppSignal si votre application utilise un autre framework Elixir.
Filtrage des paramètres AppSignal
Utilisez la liste de blocage pour le filtrage de base des paramètres. Ce filtrage des paramètres s’applique
à tous les paramètres de query d’une requête HTTP.
Configurez le filtrage des paramètres à l’aide de l’option de configuration filter_parameters. La valeur filter_parameters est une liste de chaînes.
config :appsignal, :config,
filter_parameters: ["password", "secret"]
Configuration filter_parameters de Phoenix
Utilisez le filtrage des paramètres de Phoenix pour centraliser votre configuration, qui est utilisée pour empêcher les informations sensibles d’apparaître dans les logs. AppSignal suivra ces règles de filtrage.
config :phoenix,
:filter_parameters, ["password", "secret"]
Si l’option de configuration filter_parameters n’est pas définie, Phoenix utilisera ["password"] comme valeur par défaut. Cela signifie qu’une application Phoenix n’enverra aucun mot de passe à AppSignal sans aucune configuration.
Node.js
Utilisez la liste de blocage filterParameters pour le filtrage de base des paramètres. Ce filtrage s’applique à tous les paramètres d’une requête HTTP.
Vous pouvez configurer le filtrage des paramètres à l’aide de l’option de configuration filterParameters. La valeur filterParameters est un tableau de chaînes.
const { Appsignal } = require("@appsignal/nodejs");
new Appsignal({
// Other config options
filterParameters: ["password", "secret"],
});
Python
Utilisez la liste de blocage filter_parameters pour le filtrage de base des paramètres. Ce filtrage s’applique à tous les paramètres d’une requête HTTP.
Vous pouvez configurer le filtrage des paramètres à l’aide de l’option de configuration filter_parameters. La valeur filter_parameters est un tableau de chaînes.
from appsignal import Appsignal
appsignal = Appsignal(
# Other config
filter_parameters: ["password", "secret"]
)
Pour Go, nous rapportons les paramètres de requête en tant que paramètres de query (?query=text) et données de charge utile (charge utile de la requête POST).
Utilisez la liste de blocage filter_request_query_parameters pour le filtrage des paramètres de query de requête. Définissez l’option send_request_query_parameters sur false pour ne pas envoyer du tout de paramètres de query de requête.
Utilisez la liste de blocage filter_request_payload pour le filtrage des données de charge utile de requête. Définissez l’option send_request_payload sur false pour ne pas envoyer du tout de données de charge utile de requête.
Consultez la page de configuration Go pour plus d’informations sur la façon de configurer OpenTelemetry pour les applications Go.
res := resource.NewWithAttributes(
attribute.StringSlice("appsignal.config.filter_request_query_parameters", []string{"password", "cvv"}),
attribute.StringSlice("appsignal.config.filter_request_payload", []string{"password", "cvv"}),
)
Java
Pour Java, nous rapportons les paramètres de requête en tant que paramètres de query (?query=text) et données de charge utile (charge utile de la requête POST).
Utilisez la liste de blocage filter_request_query_parameters pour le filtrage des paramètres de query de requête. Définissez l’option send_request_query_parameters sur false pour ne pas envoyer du tout de paramètres de query de requête.
Utilisez la liste de blocage filter_request_payload pour le filtrage des données de charge utile de requête. Définissez l’option send_request_payload sur false pour ne pas envoyer du tout de données de charge utile de requête.
Consultez la page de configuration Java pour plus d’informations sur la façon de configurer OpenTelemetry pour les applications Java.
function encode() {
echo -n "$@" | sed 's/,/%2C/g'
}
export OTEL_RESOURCE_ATTRIBUTES="\
appsignal.config.filter_request_query_parameters=$(encode "password,cvv"),\
appsignal.config.filter_request_payload=$(encode "password,cvv"),\
..."
PHP
Pour PHP, nous rapportons les paramètres de requête en tant que paramètres de query (?query=text) et données de charge utile (charge utile de la requête POST).
Utilisez la liste de blocage filter_request_query_parameters pour le filtrage des paramètres de query de requête. Définissez l’option send_request_query_parameters sur false pour ne pas envoyer du tout de paramètres de query de requête.
Utilisez la liste de blocage filter_request_payload pour le filtrage des données de charge utile de requête. Définissez l’option send_request_payload sur false pour ne pas envoyer du tout de données de charge utile de requête.
Consultez la page de configuration PHP pour plus d’informations sur la façon de configurer AppSignal pour PHP.
return [
'filter_request_query_parameters' => ['password', 'cvv'],
'filter_request_payload' => ['password', 'cvv'],
// ... other options
];