Modifier et réviser une passerelle d'intégration multiprotocole sans casser les contrôles d'accès

## Trouver les consignes les plus proches et, en cas de conflit, suivre le code en service Commencez par les consignes générales du dépôt, puis trouvez les instructions propres au domaine les plus proches des fichiers à modifier. Les tests, les extensions, les descriptifs de déploiement, la documentation, les serveurs de protocole et les environnements d'exécution sensibles aux performances peuvent suivre des processus distincts. N'appliquez pas les règles d'un domaine à un autre sans éléments probants. Distinguez les consignes destinées aux personnes qui contribuent au code des instructions d'exécution pour les utilisateurs finaux. Un document écrit pour un modèle ou un client utilisant le système déployé ne régit pas automatiquement les agents qui modifient le code source. Cartographiez le système avant toute modification : - Points d'entrée de l'application et configuration de l'environnement. - Schémas de validation, modèles de persistance et migrations. - Services métier, routes, intergiciels et transports de protocole. - Authentification, autorisation, extensions et limites de fédération. - Tests, documentation, ressources de déploiement et interfaces d'administration. Lorsque les sources divergent, privilégiez d'abord le code réellement exécuté et la configuration de référence, puis les cibles de construction et dépendances prises en charge, ensuite les exemples d'environnement et enfin la documentation ou les commentaires. Vérifiez l'implémentation actuelle avant de reprendre des décomptes ou des limites d'exploitation susceptibles de devenir obsolètes. Inspectez d'abord les chemins de code source actifs. Ignorez les espaces de travail temporaires, journaux, résultats de couverture, artefacts générés et dossiers de tâches reportées, sauf si la demande les inclut explicitement. ## Lancer les contrôles du projet et la détection de secrets après chaque modification Utilisez l'outil d'exécution des tâches pris en charge par le dépôt et la chaîne d'outils aux versions verrouillées, au lieu d'appeler les outils sous-jacents avec des options improvisées. Validez l'environnement de développement par rapport à l'exemple de référence, exécutez les étapes requises de préparation ou de génération d'interface, puis choisissez le serveur local ou le mode de test adapté à la tâche. Après avoir modifié le code : 1. Exécutez les contrôles de formatage, lint, types, sécurité et documentation qui couvrent directement le langage et les fichiers modifiés. 2. Utilisez des contrôles ciblés pendant l'itération, puis exécutez la porte de qualité globale exigée par le dépôt avant de proposer la fin du travail. 3. Pour un langage système secondaire ou un environnement à hautes performances, exécutez son contrôle de formatage, son analyse statique en traitant les avertissements comme des erreurs, ainsi que les tests du crate ou du paquet. 4. Reconstruisez les ressources d'administration ou de client générées lorsque leurs sources changent. 5. Ajoutez des tests de comportement pour chaque modification visible de l'extérieur. Utilisez la détection des secrets comme porte de contrôle. Pour un faux positif confirmé, n'employez la suppression en ligne autorisée par le projet que là où elle ne peut pas modifier le comportement d'un test ou d'un exemple. Dans les autres cas, régénérez et auditez la base de référence approuvée. Ne masquez jamais un véritable identifiant et ne placez jamais de secrets dans une configuration enregistrée dans le dépôt. Préférez étendre les langages et mécanismes existants de construction et d'automatisation. N'ajoutez une dépendance ou une nouvelle chaîne d'outils que si une exigence concrète ne peut pas être satisfaite en toute sécurité avec les moyens déjà pris en charge. ## Vérifier séparément ce que chaque identité peut voir et faire, et refuser les routes sans règle Maintenez deux couches de sécurité indépendantes sur chaque chemin protégé : - Le filtrage par périmètre détermine les ressources qu'une identité peut voir. - L'autorisation fondée sur les rôles détermine les actions que cette identité peut exécuter. Le franchissement d'une couche ne remplace jamais l'autre. Considérez le périmètre public de la plateforme comme une visibilité au sein de celle-ci, et non comme une autorisation d'accès anonyme depuis Internet. Normalisez chaque classe de jeton au moyen d'une seule fonction de politique de référence. Pour les jetons d'API autonomes ou anciens, un périmètre d'équipe absent ou vide doit échouer en mode fermé en limitant la visibilité aux ressources publiques ; le contournement administratif exige à la fois un état de contournement explicite et un statut d'administrateur vérifié. Pour les identités liées à une session, l'appartenance et le statut d'administrateur conservés côté serveur font autorité, tandis que les déclarations du jeton peuvent seulement réduire l'accès. Une intersection vide doit échouer en mode fermé. Les identités provisionnées par une connexion externe de confiance doivent elles aussi utiliser l'état d'autorisation local conservé, au lieu de faire confiance aux déclarations externes de privilèges. Appliquez ces invariants : - Authentifiez avant d'établir une session de transport ou de transmettre un message, puis imposez l'autorisation de l'action avant de la traiter. - Refusez par défaut les routes protégées qui n'ont pas de correspondance d'autorisation explicite. - Déduisez le propriétaire, l'équipe et l'identité de session de l'état authentifié côté serveur ; ne faites jamais confiance aux champs de propriété fournis par le client. - N'acceptez jamais les identifiants entrants du client par l'intermédiaire des paramètres de requête d'une URL. - Maintenez désactivés par défaut les transports à haut risque et le routage interdomaines sans restriction. - Exigez une liste explicite de domaines autorisés pour le trafic entre passerelles ; une liste vide bloque toutes les destinations. - Exigez que les passerelles qui communiquent fassent confiance au même émetteur et ne transmettez que les identifiants nécessaires à l'autorisation distante. Lors d'un échange délégué de jetons, ne transmettez jamais au service en aval le jeton entrant de l'utilisateur. Échangez-le auprès d'un serveur d'autorisation de confiance et ne transmettez que le jeton obtenu. Traitez la destination configurée pour l'échange comme une frontière SSRF et de sortie réseau : validez-la lors de l'enregistrement de la configuration, réservez les modifications aux identités privilégiées, consignez un identifiant de corrélation et ne journalisez jamais les jetons entrants bruts ni les jetons échangés. Les modifications sensibles pour la sécurité doivent inclure des tests de régression pour les accès non authentifiés, les périmètres incorrects, les autorisations insuffisantes, les fonctions désactivées, les destinations interdites et les autres chemins de refus. ## Garder les écritures de traces et d'audit hors de la transaction principale Comprenez la frontière transactionnelle prévue avant de modifier le code de persistance. Les données de la requête, les enregistrements d'observabilité et les journaux d'audit peuvent délibérément utiliser des sessions et des garanties d'atomicité différentes. Les écritures d'observabilité sans garantie peuvent utiliser des sessions indépendantes de courte durée qui valident immédiatement leur transaction. Cela conserve les traces et les événements lorsque la requête principale échoue, mais signifie aussi que la télémétrie n'est pas atomique avec la requête et peut présenter des états partiels ou en cours. Les opérations de consultation doivent continuer à employer des sessions limitées à la requête afin d'appliquer les filtres de visibilité et d'autorisation. La journalisation d'audit peut également posséder sa session et isoler ses défaillances. Ne transmettez pas la session déjà validée de la requête à un rédacteur d'audit indépendant par simple commodité ; une seconde validation ou annulation peut rendre inactive la transaction partagée et exposer une erreur après la persistance de la ressource principale. Si un enregistrement d'audit doit être atomique avec l'écriture principale, traitez cela comme une modification de conception explicite nécessitant une révision, une nouvelle sémantique d'échec et des tests. Le traçage indépendant peut créer plusieurs sessions de base de données par requête. Mesurez la concurrence, surveillez les signes d'épuisement du pool et dimensionnez-le pour la base de données et la charge réelles, plutôt que de reprendre des capacités fixes. Ne qualifiez pas de défaut isolé, sans preuve, une stratégie délibérée de persistance synchrone dans des gestionnaires asynchrones. La conversion de points d'appel individuels peut produire des sémantiques mélangées ; proposez plutôt une migration coordonnée du pilote et des transactions. ## Interroger le head actuel avant d'ajouter une migration de base de données Avant de créer une migration, interrogez le head de migration actuel. Le parent de la nouvelle révision doit référencer ce head vérifié ; ne le devinez jamais et ne copiez pas un identifiant parent depuis un ancien fichier. Après la création, vérifiez que l'historique possède toujours exactement un seul head prévu. Écrivez des étapes de migration idempotentes lorsque les installations peuvent différer. Inspectez le schéma actuel avant de le modifier, ignorez une opération en toute sécurité lorsqu'une table facultative est absente et évitez d'ajouter une colonne ou un objet qui existe déjà. Maintenez la cohérence entre les chemins de création d'une base neuve et d'upgrade. Si un downgrade dépend de la configuration d'exécution, rendez-le hermétique : 1. Pendant l'upgrade, stockez chaque valeur de configuration requise dans des métadonnées appartenant à la migration et indexées par révision. 2. Pendant le downgrade, lisez l'instantané stocké plutôt que l'environnement actuel. 3. N'utilisez la configuration active que comme solution de compatibilité documentée pour les bases mises à niveau avant l'existence des instantanés. 4. Retirez l'instantané à la fin du downgrade. Une migration qui lit la configuration uniquement pour initialiser des données pendant l'upgrade n'a pas besoin d'un instantané de downgrade, sauf si ce dernier dépend lui aussi de cette valeur. Vérifiez de nouveau le head après la modification et exécutez les tests pertinents de migration et d'application. Si la base cible est en retard, amenez la base contrôlée de développement ou de test jusqu'au head attendu avant de générer une nouvelle révision. N'effectuez jamais cet upgrade correctif en production sans autorisation explicite et sans plan révisé. ## Vérifier les vrais résultats et obtenir l'accord avant un push Comparez le diff final à la demande initiale, aux consignes de domaine les plus proches et aux invariants de sécurité précédents. Confirmez les résultats réels du lint, des types, des analyses de sécurité, des tests, des migrations, des ressources générées et de la documentation, selon le cas. N'affirmez pas qu'une opération a réussi sur la seule base d'une inspection. Utilisez la convention de commits, la politique de signature, les liens vers les issues et le modèle de pull request exigés par le dépôt. N'effectuez ni push ni force-push, ne modifiez pas la branche d'une personne contributrice et ne changez pas l'état externe du projet avant d'avoir reçu une autorisation explicite. Dans les revues publiques et les commentaires d'issues : - Commencez par ce qui fonctionne avant de soulever des préoccupations. - Séparez les constats bloquants, les suggestions et les remarques mineures. - Expliquez le risque et proposez des questions ou des choix au lieu de donner des ordres inutiles. - Soyez direct sans être dur ni robotique. N'ajoutez pas d'attribution interne à l'assistant, de commentaire opérationnel caché, d'identifiant ni d'estimation spéculative de l'effort dans les diffs du produit ou les messages publics. Ne créez de nouveaux fichiers ou documents que si la modification les exige réellement. Lors du tri du travail, distinguez une demande en attente d'informations de la personne qui l'a signalée, un blocage dû à une dépendance et un élément accepté mais reporté. Ne marquez une issue comme résolue qu'après l'intégration de la modification corrective, et non après sa seule mise en œuvre locale. Avant de terminer, vérifiez que les valeurs sensibles restent hors du contrôle de version, que les chemins de refus de sécurité disposent de tests, que l'ordre de priorité des sources de référence a été respecté et qu'aucun contenu temporaire sans rapport n'est entré dans le diff.