Choisir les preuves HTTP : journaux de la passerelle ou journaux de l’application

La surveillance du web commence par un objectif, pas par un point de capture. Compter les clients actifs, chronométrer un appel API et lire des corps de messages exigent chacun des preuves et des décisions de confidentialité différentes. Une passerelle qui relaie HTTPS protégé voit les connexions plutôt que le contenu des pages. Choisir la mauvaise couche produit des données qui semblent riches et ne répondent à rien.

Nommez la question avant la source de données

Commencez par la décision opérationnelle que les données doivent étayer. Les questions de disponibilité ont besoin de décomptes et de durées, les questions de requêtes ont besoin de chemins et de codes de statut, et les questions de contenu ont besoin de corps de messages. Chaque pas vers l’intérieur ajoute de la sensibilité et de la complexité d’ingénierie. Faites approuver le public, l’objectif et le traitement par le responsable du service et le responsable de la sécurité avant que la collecte ne commence, car exploiter le tunnel n’est pas cette décision.

Écrivez la question en une phrase et gardez-la à côté du plan de collecte. C’est le seul contrôle fiable du périmètre.

Ce que la passerelle peut montrer et ce qu’elle ne peut pas

Une passerelle qui relaie un HTTPS correctement protégé voit normalement des adresses, des ports et des volumes, pas les lignes de requête ni les corps.

conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'

La liste conntrack montre des flux et des traductions, et la courte capture montre des paquets sans contenu applicatif lisible. Cela suffit à répondre si le trafic circule, combien et entre quelles extrémités. Ce n’est pas une liste d’URL, et un proxy CONNECT ordinaire relaie l’échange chiffré sans terminer le TLS de l’application. Quand quelqu’un promet des chemins de requête depuis cette position, demandez quel composant déchiffre et sous quelle confiance.

Les journaux de l’application répondent à la plupart des questions de requête

Pour une application que vous exploitez, sa propre journalisation prise en charge répond généralement à la question au niveau de la requête sans déchiffrer les connexions des autres.

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.log

La requête de santé mesure la disponibilité depuis la position d’un client, et le journal d’accès consigne les champs que le serveur avait déjà choisi de conserver. Sélectionnez les champs dont la tâche a besoin et laissez le reste dehors, car même une URL peut porter des paramètres sensibles. Une ligne de journal est une preuve sur ce service, pas sur tous les autres services que l’utilisateur a atteints par le tunnel. Garder la collecte étroite garde aussi la question de rétention petite, alors fixez une fenêtre plus courte que l’expérience de pensée qui a produit l’exigence.

L’interception est une conception de confiance distincte

Si l’inspection au niveau du message est réellement nécessaire, l’interception TLS crée un nouveau point de terminaison de confiance et un accord de confiance client qui doit être distribué et maintenu. Les applications qui épinglent les certificats casseront, et l’opérateur détient désormais des clés privées dont la protection compte autant que n’importe quelle clé de serveur. Faire fonctionner la collecte en affaiblissant la validation des certificats, ou en corrigeant une application qui épingle ses certificats, échange un contrôle de sécurité contre une ligne de journal. Préférez une conception d’inspection documentée dont la distribution de confiance est déjà gérée, et gardez la clé privée de l’autorité hors de tout ce qui est partagé.

À la fin de la fenêtre de collecte, retirez la configuration et son matériel de confiance par l’intermédiaire de leurs propriétaires, et éliminez les preuves conservées selon la politique convenue. Assez d’informations fiables pour l’objectif déclaré est le critère de réussite, pas la plus grande capture possible.