Les utilisateurs de Railway qui y conservaient des clés AWS ou Google Cloud ont d’autres vérifications à mener que le remplacement d’une variable. Après l’alerte du 21 octobre, l’hébergeur a publié le 22 deux guides pour révoquer ces accès et rechercher leur éventuel détournement. Une clé exposée peut en effet ouvrir des services extérieurs à Railway.
Les variables d’environnement peuvent contenir des identifiants de base de données, des clés API ou des accès cloud. Railway a signalé un accès possible à certaines valeurs déchiffrées et demande par précaution de renouveler les secrets stockés. L’enquête n’attribue pas le même impact à tous les utilisateurs.
Remplacer la clé, puis déployer la nouvelle configuration
Le guide consacré à AWS recommande de désactiver la clé susceptible d’avoir été exposée, d’en créer une autre et de mettre à jour les deux variables d’accès dans le service. Il faut ensuite déployer la nouvelle configuration et vérifier que les appels fonctionnent.
La même paire de clés peut aussi être utilisée en développement local ou dans une chaîne d’intégration. Ne la remplacer qu’à un seul endroit risque alors de laisser un service en panne, ou une ancienne copie toujours utilisée ailleurs. L’inventaire des usages fait donc partie de la réponse à l’incident.
Côté Google Cloud, Railway rappelle une particularité : désactiver la clé bloque de nouvelles authentifications, mais des jetons de courte durée déjà obtenus peuvent rester valides jusqu’à une heure. Si une coupure immédiate est nécessaire, désactiver le compte de service entier a une portée plus large et interrompt aussi les applications légitimes qui en dépendent.
Les anciens accès peuvent avoir laissé des ressources derrière eux
Les recommandations invitent à examiner CloudTrail pour AWS et Cloud Audit Logs pour Google Cloud. L’objectif est de repérer des actions étrangères au fonctionnement de l’application : créations de ressources, de clés ou de comptes, changements d’autorisations et dépenses inhabituelles.
Une ressource créée pendant l’exposition ne disparaît pas parce que l’ancienne clé a été désactivée. Il faut donc distinguer la fermeture de l’accès et l’examen de ses conséquences. Une nouvelle clé évite de continuer avec le même secret ; elle ne raconte pas ce qui s’est passé auparavant.
Une adresse IP inconnue ne prouve pas toujours une intrusion
Les adresses IP demandent également du contexte. Dans son guide Google Cloud, Railway précise qu’une adresse inconnue constitue une piste, et non une preuve à elle seule, lorsque les services partagent des adresses de sortie. Une règle trop rapide peut faire confondre du trafic légitime et une activité suspecte.
Ces publications ne décrivent pas un piratage des infrastructures AWS et Google Cloud. Elles expliquent le risque de propagation lié aux droits d’une clé stockée ailleurs. Pour les équipes qui hébergent des outils IA, la question est donc celle des services reliés à l’application, et pas uniquement de son retour en ligne.
Eric Thomas suit l’actualité de Windows, des logiciels, de la cybersécurité grand public et des outils web. Il s’intéresse aux mises à jour système, aux nouveautés informatiques et aux solutions pratiques qui améliorent l’expérience numérique au quotidien.