Données et confidentialité · version
Données et confidentialité
En cas de divergence, la version anglaise fait foi.
Date : . Exploitant : PatchFirst (les coordonnées de l’exploitant seront publiées avant l’ouverture des paiements). Questions sur les données et demandes de suppression : [email protected].
L’inscription à PatchFirst ne nécessite ni nom, ni adresse e-mail, ni numéro de téléphone : choisissez un identifiant inventé sans données personnelles. Saisissez vos coordonnées de paiement sur la page de la plateforme choisie. Les demandes à l’exploitant peuvent révéler des informations dans la correspondance, comme expliqué ci-dessous. Ni l’anonymisation de l’inventaire technique ni le chiffrement ne promettent un anonymat absolu.
1. Avant l’envoi : sur votre serveur
L’agent collecte un inventaire technique et l’anonymise sur le serveur du propriétaire. Les noms d’hôtes deviennent des UUID ; les adresses, un indicateur d’adresse publique. Les chemins, les images privées et les autres valeurs identifiantes deviennent des étiquettes HMAC à l’aide du secret du propriétaire. Les numéros de port ne sont jamais transmis : seuls le type de service et son accessibilité publique le sont. Une recherche d’adresses, de chemins et de mots d’identification définis par le propriétaire peut bloquer l’envoi en cas de fuite détectée.
Cela réduit le risque sans garantir qu’une combinaison inhabituelle de paquets et de versions soit méconnaissable. Examinez la sortie dry-run ou le JSON avant l’envoi, configurez les mots d’identification et n’incluez aucun secret dans l’inventaire.
2. Pendant l’analyse : PatchFirst voit la pile logicielle
Le service reçoit des détails anonymisés : système et noyau, paquets et versions, produits et images reconnus, processus, types de services et indices d’exposition, UUID et étiquettes techniques. PatchFirst peut lire ces informations pendant l’analyse. Il compare l’inventaire aux CVE, aux flux d’exploitation et aux cycles de support, puis calcule les constats, la note et les priorités.
Les requêtes à OSV peuvent inclure les noms des paquets, leurs versions et l’écosystème de la distribution ; les autres sources sont principalement téléchargées sous forme de flux. Le dictionnaire des noms réels et le mot de passe des noms ne sont pas nécessaires à la recherche de correspondances et ne sont pas transmis à ces sources.
3. Dans la base de données : inventaire anonymisé et choix des noms
Les inventaires anonymisés et les rapports de surveillance sont conservés dans PostgreSQL sous forme lisible. Le service les lit et y effectue des recherches SQL pour recalculer les constats lorsque les informations de vulnérabilité changent. Ils ne sont pas chiffrés avec une clé de parc : une copie de la base expose la pile technique anonymisée, les UUID, les étiquettes et les heures de mise à jour.
Les sauvegardes sont chiffrées avec age au moyen d’une clé publique de destinataire distincte, sans clé privée sur le serveur ; celui-ci ne peut pas déchiffrer une sauvegarde. L’exploitant configure le chiffrement du disque sur l’hôte, en dehors du code PatchFirst. Cette protection ne masque pas les données au service en cours d’exécution.
Le chiffrement des noms est désactivé par défaut. L’agent ne transmet ni le nom d’hôte réel ni un dictionnaire des noms. Vous pouvez laisser les noms vides ou choisir un alias de 64 caractères maximum sans caractères de contrôle : il est conservé en clair dans PostgreSQL et accessible au service ainsi qu’à toute personne détenant une copie de la base. N’indiquez ni domaine, ni IP, ni nom d’entreprise ou de client ; utilisez un alias tel que web-1. Activez le chiffrement dans Compte avec un mot de passe des noms distinct. Votre navigateur transfère les noms existants dans un dictionnaire chiffré ; les copies en clair sont supprimées du service au cours de la même opération. Mettez ensuite à jour les configurations des agents afin qu’ils envoient les noms avec la nouvelle clé.
Lorsque le chiffrement des noms est activé, le dictionnaire « étiquette → nom réel » est chiffré séparément du côté du propriétaire à l’aide d’une clé de lecture (AES-GCM, format sealbox). PatchFirst ne détient pas cette clé ; le navigateur ou le client du propriétaire ouvre les noms. Le mot de passe des noms est distinct de celui de connexion et n’est jamais transmis au service. Le serveur ne peut pas récupérer les anciens noms s’il est perdu.
La pile anonymisée est accessible au service pendant le stockage et l’analyse. Le chiffrement des sauvegardes et du disque ne la masque pas au service en cours d’exécution. Un appareil ou navigateur du propriétaire compromis peut exposer les noms et les clés ; une combinaison inhabituelle de versions peut identifier un serveur.
4. Réseau, compte et navigateur
L’URL du destinataire des webhooks est conservée en clair par le service avec le parc et peut identifier votre entreprise. Utilisez une adresse sans domaine reconnaissable, par exemple un proxy ou un service de réception de webhooks. Le secret de signature est conservé chiffré à l’aide d’une clé dérivée du secret de service à une fin distincte. Le service le déchiffre pour signer les envois. Le destinataire reçoit les événements sélectionnés, l’UUID du serveur, son alias en clair le cas échéant et de brefs détails des constats ; l’inventaire et les noms chiffrés sont exclus. Le journal conserve la date, le type d’événement et le résultat sans le corps de réponse du destinataire.
L’IP de connexion est utilisée uniquement en mémoire pour les limites de débit et la protection contre la force brute, sans jamais être enregistrée sur disque. Caddy ne conserve pas de journal d’accès ; les journaux API et d’erreurs ne contiennent ni adresses IP ni valeurs User-Agent. Le service ne conserve ni en-têtes de requête ni URL de requête complètes. Le fournisseur réseau traite les connexions selon ses propres règles.
Pour protéger le compteur public de vérifications gratuites, la base conserve un HMAC de l’adresse avec un sel secret de service et l’heure de la dernière vérification terminée comptabilisée. Cela permet de compter au maximum une vérification par adresse en 60 secondes, y compris après un redémarrage. L’adresse elle-même n’est pas conservée ; les enregistrements HMAC expirés sont supprimés lorsqu’une autre vérification est comptée. Le total subsiste après la suppression des rapports.
Les comptes utilisent un identifiant et un mot de passe pour se connecter. La base conserve uniquement un HMAC-SHA256 de l’identifiant avec un secret conservé dans un fichier distinct, hors de la base. Aucune copie en clair ou chiffrée de l’identifiant n’est conservée. Les mots de passe de connexion sont stockés sous forme d’empreintes scrypt robustes et salées, jamais en clair. Seule une valeur de vérification du code de récupération est conservée ; le code lui-même ne l’est pas. Il rétablit l’accès au compte sans déchiffrer l’inventaire ni les noms. Le service conserve les sessions, la version des conditions acceptées, les quotas et les périodes d’accès.
Les paiements du tableau de bord ouvrent la page de Paddle, ЮKassa ou CoinsSend. PatchFirst transmet un numéro de commande opaque aléatoire et les paramètres du paiement : montant et devise. PatchFirst ne transmet au prestataire ni identifiant, nom, e-mail, téléphone, adresse, IP ni coordonnées bancaires. Les enregistrements de paiement conservent uniquement le numéro de commande, le montant, la devise, le statut, la date et des empreintes irréversibles calculées avec un secret de service à partir d’identifiants externes d’acheteur. Ces données sont pseudonymes : les empreintes servent uniquement à prévenir les abus de bonus. Une empreinte du payeur est dérivée pour les paiements par carte via Paddle et ЮKassa. CoinsSend n’en fournit pas ; aucune empreinte de ce type n’est conservée pour les paiements en cryptomonnaies. Les webhooks des prestataires peuvent contenir des informations supplémentaires sur le payeur : elles n’existent qu’en mémoire pour l’authentification et l’analyse des événements, ne sont pas stockées en base et ne sont pas journalisées. Les webhooks bruts, les réponses des API de paiement et les identifiants de paiement ne sont ni stockés ni journalisés, y compris en cas d’erreur.
Paddle et ЮKassa sont des responsables de traitement indépendants pour les données de paiement : leurs propres conditions régissent le traitement nécessaire au paiement, aux contrôles, aux reçus, aux remboursements et aux rétrofacturations. Consultez la politique de confidentialité de Paddle et politique de confidentialité de ЮMoney / ЮKassa. Paddle agit comme vendeur officiel (Merchant of Record) et gère les taxes sur les ventes applicables. Le vendeur russe recevant les paiements ЮKassa est un entrepreneur individuel ; ses coordonnées manquantes doivent figurer dans les conditions d’utilisation avant l’activation des paiements. Si la plateforme demande un e-mail ou un téléphone pour les reçus électroniques en application de la loi fédérale russe n° 54-FZ, ces coordonnées ne sont pas transmises à PatchFirst pour conservation.
CoinsSend est un service de conservation de cryptomonnaies et un responsable de traitement indépendant pour les données de paiement. PatchFirst lui transmet uniquement le numéro de commande opaque et le montant en USD, sans identifiant ni coordonnées du payeur ; les paramètres de frais et de retour au tableau de bord ne contiennent aucune information sur le payeur. Lors du paiement, CoinsSend reçoit lui-même les détails techniques du navigateur et les données de transaction en cryptomonnaie conformément à sa politique de confidentialité. CoinsSend effectue ses contrôles de lutte contre le blanchiment conformément à sa politique de lutte contre le blanchiment : il peut demander des informations supplémentaires ou retarder un paiement. Les fonds reçus sur le solde du marchand sont retenus pendant 24 heures. Les enregistrements publics de la blockchain ne sont pas supprimés avec un compte PatchFirst.
Votre navigateur peut conserver le thème choisi et les données d’accès au panneau. Un cookie de session permet la connexion ; l’ancien panneau conserve sa clé d’accès localement. Le fragment d’URL après # n’est pas envoyé au serveur dans la requête HTTP, mais toute personne disposant du lien complet peut en obtenir les secrets. Les pages publiques n’utilisent ni polices tierces, ni traceurs publicitaires, ni outils d’analyse externes.
Les relations de parrainage conservent uniquement des identifiants opaques de comptes parrain et invité, sans e-mail ni nom. Le registre enregistre les crédits de serveurs-mois, leur utilisation, leur expiration et leurs annulations ; le serveur choisi est identifié par son UUID technique.
5. Utilisation des données techniques
La pile technique anonymisée et les enregistrements opérationnels permettent les vérifications et la surveillance demandées, la gestion des comptes, la comptabilité des paiements et la prévention des abus. Le service et ses sources traitent les données techniques uniquement dans le périmètre décrit ci-dessus. La vente des inventaires ou leur utilisation publicitaire ne fait pas partie des finalités du service.
Une demande à [email protected] divulgue à l’exploitant l’adresse e-mail de l’expéditeur et toute information incluse dans le message. Nous utilisons ces informations pour répondre à votre demande. L’exploitant supprime la correspondance et les pièces jointes des copies de travail sous son contrôle dans les 30 jours suivant la résolution de la demande, sauf conservation imposée par la loi ; les sauvegardes suivent leur cycle de nettoyage. Un identifiant de compte ou de commande et une description sans secrets suffisent aux questions techniques ; n’envoyez ni données personnelles inutiles, ni mots de passe, ni coordonnées de paiement complètes.
6. Conservation et suppression
L’exploitant peut configurer la suppression des objets surveillés qui ne sont plus actualisés ; la valeur par défaut est de 180 jours. Les parcs vides sont supprimés après une semaine. Une vérification gratuite se lance avec une commande. Son rapport reste disponible par lien pendant 7 jours, chiffré avec la clé du rapport. La clé se trouve dans le fragment d’URL après # et n’est pas transmise au serveur dans la requête HTTP ; le navigateur l’envoie à l’API dans un en-tête pour ouvrir le rapport. Ce sont des délais techniques de nettoyage, pas une promesse de restauration des données supprimées.
Vous pouvez supprimer des serveurs et demander la suppression de votre compte et des données techniques associées. Désactivez l’agent pour éviter qu’il ne renvoie des données. La suppression immédiate de chaque sauvegarde n’est pas promise ; renseignez-vous auprès de l’exploitant sur leur nettoyage.
Les commandes, ces empreintes et la relation parrain–invité sont conservées après la suppression du compte, sans identifiant de connexion ni données du compte, pour la comptabilité des paiements et des remboursements.
7. Vos demandes et le périmètre de cette politique
Contactez [email protected] pour toute question sur les données techniques ou demande de suppression. Pour protéger le compte, l’exploitant peut vous demander de démontrer votre accès sans exiger votre nom ni de pièce d’identité. Les droits prévus par la législation applicable restent ouverts.
Coordonnées de l’exploitant, droit applicable et juridiction : PatchFirst (les coordonnées de l’exploitant seront publiées avant l’ouverture des paiements) ; à préciser avec les coordonnées de l’exploitant. Les révisions de cette politique portent une nouvelle date. Documents associés : conditions d’utilisation et politique d’utilisation acceptable.