Modèle de sécurité du nœud physique

Appliquez les limites de sécurité du Mac dans le cloud à chaque accès

RunnerVPS fournit à chaque commande un nœud physique Apple Silicon dédié. La sécurité ne dépend pas seulement de l’exclusivité de l’appareil, mais aussi de la façon dont l’équipe attribue les clés SSH, utilise VNC, injecte les secrets de build, met à jour la chaîne d’outils et effectue la sortie des données avant la fin de la période de location.

Choisir un nœud et commander Consulter la documentation de connexion et de dépannage

Limite des ressources: Une commande correspond à une machine physique
Stockage local: Non partagé avec d’autres locataires
Principe de gestion: Identifiants minimisés, opérations traçables

Accusé de réception sécurisé NODE ACCESS / READY

Nœud dédié

Association à la commande Appareil associé à l’enregistrement de commande

Remise des identifiants Rotation immédiate après le premier accès

Accès de l’équipe Une clé distincte par membre

Sortie en fin de location Exporter les artefacts et supprimer les données

Ressources de calcul: Dédiées
Accès distant: SSH / VNC
Vérification des journaux: Effectuée régulièrement par l’utilisateur
Origine des secrets: Processus géré par l’utilisateur

La remise n’est pas la fin du processus de sécurité VERIFY → LIMIT → ROTATE → REMOVE

Vue d’ensemble du modèle de sécurité

Le serveur physique dédié définit d’abord les limites des ressources

RunnerVPS fournit un nœud physique Mac dans le cloud dédié, et non une machine virtuelle partagée. Les ressources de calcul et le stockage local de l’appareil ne sont pas partagés avec d’autres locataires, mais les comptes, le code, les clés et la configuration logicielle restent sous la responsabilité de l’équipe utilisatrice.

Isolation au niveau de l’appareil

Chaque commande correspond à une machine physique dédiée. Le processeur, la mémoire et le SSD intégré ne sont pas partagés avec d’autres locataires. L’équipe peut ainsi établir un inventaire des actifs, une liste d’accès et des registres de transfert à partir d’un identifiant d’appareil clairement défini.

Commande ↔ appareil Ressources physiques dédiées

Responsabilités d’accès claires

L’utilisateur décide qui peut se connecter à l’appareil, quels comptes utiliser et quand révoquer les clés. Ne laissez pas plusieurs personnes utiliser durablement la même clé privée ou le même mot de passe, et n’inscrivez pas les identifiants de connexion dans la documentation du projet ni dans les journaux d’automatisation.

Autorisation individuelle Révocation rapide

Cycle de vie des données maîtrisé

Déterminez avant le début de la tâche quand le code, les caches de build, les éléments de signature et les artefacts arrivent sur l’appareil, combien de temps ils y restent, ainsi que leur sauvegarde et leur suppression. La fin de la location ne remplace pas une sauvegarde.

Planifier avant l’arrivée Nettoyer avant la fin

Contrôle des accès

Donnez une identité distincte à chaque connexion

Avant l’accès de l’équipe, définissez les comptes, les clés, les autorisations et la fréquence des contrôles. Ne partagez pas d’abord un identifiant administrateur unique en espérant retrouver ensuite qui a fait quoi dans les discussions.

Une personne, une clé SSH

Enregistrez une clé publique distincte pour chaque membre ayant besoin d’un accès en ligne de commande. La clé privée doit rester sur un appareil contrôlé par son propriétaire ou dans un gestionnaire de clés approuvé par l’équipe, sans passer par e-mail, ticket ou dépôt de code.

Révocation individuelle

Utiliser par défaut un compte aux privilèges minimaux

Le téléchargement quotidien du code, l’exécution des tests et le renvoi des artefacts ne nécessitent pas de conserver les privilèges maximaux. Élevez temporairement les privilèges uniquement pour des actions précises, comme l’installation de logiciels ou la modification des réglages système.

Réduire les erreurs de manipulation

Gérer séparément mots de passe et clés

Le compte de l’interface graphique doit utiliser un mot de passe fort et unique, tandis que l’accès SSH doit privilégier l’authentification par clé. N’utilisez pas le mot de passe de l’appareil pour l’hébergement de code, la messagerie ou d’autres systèmes.

Réduire les risques de réutilisation

Consulter régulièrement les journaux de connexion distante

Vérifiez les heures de connexion, les sources, les comptes et les tentatives échouées. Si une entrée ne correspond pas aux horaires de travail ou au réseau d’un membre, révoquez d’abord les identifiants concernés, conservez les journaux nécessaires et envoyez un signalement de sécurité.

Conserver les éléments d’enquête

Sécurité VNC

L’interface graphique doit elle aussi passer par un accès contrôlé

VNC convient à l’utilisation distante de l’interface graphique macOS, mais une exposition permanente et des identifiants partagés ne doivent pas être considérés comme pratiques. Privilégiez une connexion via un réseau contrôlé ou un tunnel SSH.

Avant la connexion

Vérifiez que la cible correspond au nom de l’appareil et au nœud de la commande.
Vérifiez d’abord l’empreinte de l’hôte SSH, puis établissez la redirection de port.
Limitez les appareils locaux et les membres de l’équipe autorisés à se connecter.

Pendant la session

Verrouillez la session macOS lorsque vous quittez l’écran afin que la connexion ne reste pas sur un bureau utilisable.
N’affichez pas de mots de passe, jetons ou clés privées sur un écran partagé, dans un enregistrement ou dans les journaux.
Avant de transférer un fichier sensible, vérifiez le dossier de réception et ses autorisations d’accès.

Après le départ d’un membre

Révoquez immédiatement la clé publique SSH et l’accès au compte système de ce membre.
Renouvelez le mot de passe de l’interface graphique et les jetons du projet qui ont été partagés.
Vérifiez les journaux de connexion distante récents et mettez à jour la liste des accès.

Ne partagez pas les identifiants durables

Pour travailler à plusieurs, créez pour chaque membre un accès pouvant être révoqué séparément. Les identifiants partagés compliquent la révocation après un départ, le suivi des opérations et l’analyse des incidents.

Gestion des secrets de build

Injectez les secrets pendant l’exécution, sans les faire circuler avec le code

Les certificats, fichiers de signature, jetons d’accès et variables d’environnement doivent provenir du processus de gestion des secrets de votre équipe. RunnerVPS fournit l’appareil et la connectivité de base, mais ne remplace pas la gouvernance des identifiants du projet.

Liste d’injection des tâches de build RUN SCOPE: ONE JOB

Certificat de signature Importer au début de la tâche Supprimer à la fin de la tâche

Fichier de signature Limiter les autorisations du fichier Ne pas l’ajouter au dépôt

Jeton d’accès Limiter au périmètre du projet Définir une stratégie de rotation distincte

Variable d’environnement Injectée par le runner Ne jamais l’écrire dans les journaux

Artefact de build Transférer vers un stockage contrôlé Supprimer les copies après vérification

Ne pas les placer dans le dépôt de code

Ne commitez aucune clé privée, aucun mot de passe de certificat, fichier de signature, jeton ou fichier de configuration contenant des secrets dans une branche. Même après suppression, l’historique peut en conserver le contenu.

Ne pas les placer dans les journaux de build

Désactivez l’affichage des valeurs sensibles dans l’écho des commandes et masquez les données sensibles dans les journaux, captures d’écran et rapports d’échec. Lors du dépannage, conservez le contexte de l’erreur sans recopier les identifiants complets.

Limiter la portée par tâche

N’accordez aux jetons que les autorisations nécessaires au dépôt, au pipeline et aux opérations en cours. Effectuez immédiatement une rotation à la fin de la tâche, après le départ d’un membre ou en cas de suspicion d’exposition.

Mises à jour système et logicielles

Validez d’abord la chaîne d’outils, puis planifiez les mises à jour de macOS et Xcode

Les mises à jour système peuvent modifier les SDK, les outils en ligne de commande, les simulateurs et le comportement de la signature. Pour un nœud de build continu, la vérification de compatibilité doit précéder toute modification de l’environnement de production.

01

Consigner la référence actuelle

Enregistrez les versions de macOS, Xcode, des outils en ligne de commande, du gestionnaire de paquets, des dépendances clés et du runner. Notez la tâche de test minimale actuellement réussie par le projet et la méthode de vérification des artefacts.
02

Vérifier la compatibilité du projet

Vérifiez d’abord les exigences du projet, la prise en charge des SDK, le verrouillage des dépendances et la configuration de signature. Pour les projets critiques, utilisez des tâches de test reproductibles afin de contrôler la compilation, les tests unitaires, la signature et l’export des artefacts.
03

Préparer une procédure de restauration

Avant toute modification, sauvegardez les données, listes de configuration et artefacts nécessaires au projet. Confirmez que les dépendances peuvent être réinstallées et que les secrets peuvent être injectés à nouveau via le processus de votre équipe.
04

Choisir une période à faible risque

Évitez les tâches de publication en cours et suspendez l’arrivée de nouveaux builds sur le nœud. Après la mise à jour, revérifiez l’accès distant, le pare-feu, l’état du runner et l’espace disque.
05

Valider avec une tâche minimale

Exécutez d’abord une tâche de validation de taille maîtrisée, puis rétablissez le pipeline complet. Si le résultat diffère de la référence, conservez les journaux, les informations de version et les étapes de reproduction avant de poursuivre.

Processus de sortie des données

Avant la fin de la location, emportez les données à conserver

Avant la fin de la location, l’utilisateur doit exporter les artefacts, supprimer les comptes, révoquer les clés et nettoyer les fichiers du projet. Ne considérez pas le stockage local de l’appareil comme une sauvegarde unique et ne reportez pas le nettoyage après la perte d’accès à l’appareil.

Consulter les informations d’assistance Ouvrir la console

01 Exporter

Récupérez les artefacts de build, données du projet, journaux et listes de configuration à conserver.

02 Vérifier

Dans le stockage contrôlé de l’équipe, vérifiez que les fichiers s’ouvrent, que les sommes de contrôle correspondent et que les autorisations sont correctes.

03 Révoquer

Supprimez les comptes des membres, clés publiques SSH, jetons du projet, certificats et éléments de signature.

04 Nettoyer

Supprimez les répertoires du projet, caches, fichiers temporaires, téléchargements et copies locales des artefacts.

05 Confirmer

Vérifiez l’état de la location dans la console et conservez les éléments de transfert nécessaires associés à la commande.

Limites de responsabilité

L’utilisateur doit exporter et vérifier les données nécessaires avant la fin de la location. Après cette échéance, ne supposez pas que l’appareil restera accessible pour effectuer une sauvegarde, restaurer des fichiers du projet ou récupérer des artefacts de build non exportés.

Signalement des incidents de sécurité

Fournissez assez d’informations pour que l’analyse parte des faits

Si vous détectez une connexion inhabituelle, une possible exposition d’identifiants, une portée d’accès incorrecte ou tout autre problème de sécurité, révoquez d’abord les identifiants nécessaires et limitez les accès, puis sélectionnez la catégorie de signalement de sécurité sur la page de contact.

01 Périmètre de l’impact

Indiquez les identifiants des appareils, nœuds, comptes, projets et types de données potentiellement concernés. N’envoyez pas de mots de passe, clés privées ni informations de paiement complètes.

02 Chronologie de l’incident

Indiquez l’heure de la première détection, la durée de l’anomalie, les mesures de révocation ou d’isolement déjà prises et le dernier moment où le fonctionnement normal a été confirmé.

03 Étapes de reproduction

Décrivez dans l’ordre réel le point d’entrée, les actions, le résultat attendu et le résultat obtenu. Si le problème ne peut pas être reproduit de manière stable, précisez sa fréquence et ses conditions de déclenchement.

04 Preuves anonymisées

Fournissez les extraits de journaux, messages d’erreur, heures des requêtes et captures d’écran nécessaires. Masquez les jetons, clés, mots de passe, certificats et informations personnelles sans rapport.

Commencez avec un nœud physique aux limites clairement définies

Choisissez Runner M4 ou Runner M4 Plus, la durée de location et le nœud, puis configurez l’accès après la remise en suivant les processus de gestion des clés et des secrets de votre équipe.

Choisir un nœud et commander Voir les offres et les tarifs