La sécurité repose sur des limites claires

Un équipement dédié est le point de départ : la sécurité dépend de chaque limite.

MiniRent fournit des nœuds Mac physiques dédiés dans le cloud, sans partager les ressources de machines virtuelles avec d’autres locataires. Cette page précise qui gère les contrôles de la plateforme, les comptes de l’appareil, les connexions SSH, les artefacts de build et les outils de développement tiers, ainsi que la conduite à tenir en cas d’anomalie.

Mac physique dédié Pas de machine virtuelle Cinq nœuds disponibles

Louer un Mac dédié Consulter le guide de connexion et de dépannage

Scénario de sécurité cloud composé d’un Mac mini, de nœuds réseau et de l’état des connexions

Clé SSH acceptée Connexion avec privilèges minimaux

Session de l’appareil isolée physical-node / dedicated

99,9 % Objectif de service

Répartition des responsabilités

Commencez par définir l’exclusivité de l’appareil, puis qui contrôle quoi

L’exclusivité d’un équipement physique élimine la concurrence pour les ressources entre locataires d’une machine virtuelle partagée, mais elle ne remplace ni les permissions de compte, ni la rotation des clés, ni le nettoyage des artefacts de build. Le modèle de sécurité repose simultanément sur trois niveaux : la plateforme, l’équipe locataire et les outils utilisés.

Contrôles de la plateforme

La plateforme gère l’attribution des nœuds physiques, l’accès à la console, la remise des informations de connexion, l’enregistrement des commandes et de l’état des équipements, ainsi que le traitement des incidents de service confirmés.

Chaque location correspond à un équipement physique dédié
Les opérations d’administration et les sessions de build sur l’appareil sont consignées séparément
Les informations de connexion sont accessibles uniquement depuis la console après autorisation

Contrôles de l’utilisateur

L’utilisateur gère les comptes sur l’appareil, les clés publiques SSH, les jetons de dépôts de code, les éléments de signature, les variables d’environnement, les permissions des membres et le nettoyage des données avant la fin de la location.

Séparer les identités par membre et par tâche automatisée
Accorder uniquement les permissions nécessaires à la tâche en cours
Révoquer immédiatement les anciens accès lors d’un changement de membre

Contrôles des outils de développement

Xcode, fastlane, les gestionnaires de dépendances et les Runners de pipeline stockent chacun leur configuration, leurs caches et leurs journaux. L’équipe doit définir les versions, les permissions et la stratégie de nettoyage selon les capacités de chaque outil.

Verrouiller les versions reproductibles des outils et des dépendances
Ne jamais enregistrer les variables sensibles dans le dépôt ou les journaux ordinaires
Supprimer les fichiers temporaires et les caches à la fin de la tâche

À retenir :Si votre tâche exige des ressources dédiées, l’accès à l’interface graphique complète et à la ligne de commande macOS, ainsi que le contrôle de vos comptes de build et de vos workflows automatisés, un nœud physique dédié répond mieux à ces exigences qu’une machine virtuelle partagée.

Contrôle d’accès à l’appareil

Considérez chaque connexion comme une autorisation à vérifier

La première connexion ne consiste pas à saisir une adresse puis à continuer. Récupérez d’abord les informations de connexion dans la console, vérifiez l’empreinte de l’hôte, puis établissez la session avec une clé publique SSH enregistrée. Ne transmettez jamais une clé privée via des conversations, des documents publics ou des fichiers de dépôt.

01 Enregistrer la clé publique

Générez des clés distinctes pour chaque personne ou tâche automatisée ; ne partagez pas une même clé privée entre plusieurs membres.

02 Vérifier l’empreinte

Lors de la première connexion ou d’un changement de point d’accès, comparez l’empreinte de l’hôte affichée localement avec celle enregistrée dans la console.

03 Limiter les permissions

Utilisez un compte standard pour les builds quotidiens et n’élevez temporairement les privilèges que pour installer des composants ou modifier les réglages système.

Gestion du cycle de vie des membres

Arrivée d’un membre: Créez une identité distincte, enregistrez une clé publique dédiée et n’ouvrez l’accès qu’aux dépôts, Runners et répertoires de projet nécessaires.
Changement de rôle: Réexaminez la portée d’accès aux comptes de l’appareil, aux répertoires, aux clés d’automatisation et aux éléments de signature.
Rotation des identifiants: Définissez des règles de rotation pour les clés des personnes, les jetons de dépôt et les clés de pipeline ; en cas de suspicion de fuite, n’attendez pas l’échéance prévue.
Départ d’un membre: Révoquez sa clé publique et son compte sur l’appareil, supprimez ses autorisations de pipeline, faites tourner les identifiants partagés auxquels il a eu accès et vérifiez les journaux récents.

À ne jamais envoyer :Les demandes d’assistance ne doivent contenir ni clé privée, ni jeton d’accès complet, ni mot de passe, ni élément de signature non masqué.

Protection des artefacts de build

Les jetons, éléments de signature et variables d’environnement ne doivent exister que lorsque la tâche l’exige

Dans les builds automatisés, le risque le plus courant ne vient pas du partage des ressources de l’appareil, mais de jetons persistants présents dans les scripts, les journaux ou les caches. Concevez ensemble les permissions, la durée de validité, le mode d’injection et le nettoyage des éléments sensibles.

Recommandations d’autorisation, d’injection et de nettoyage des artefacts de build
Artefact	Périmètre d’autorisation	Mode d’injection recommandé	Action en fin de tâche
Jeton de dépôt de code	Limiter au dépôt et aux opérations nécessaires, en privilégiant la lecture seule	Injecter via des variables d’environnement contrôlées ou des secrets de pipeline	Révoquer les jetons à courte durée et vérifier l’espace de travail ainsi que les URL distantes
Certificat de signature et clé privée	Autoriser la lecture uniquement au compte chargé de signer	Importer dans un trousseau contrôlé au début du build	Supprimer le trousseau temporaire et les fichiers importés
Profil de provisioning	Limiter à l’application cible et à l’usage de build	Copier dans un répertoire temporaire depuis une tâche contrôlée	Supprimer la copie temporaire et vérifier le contenu de l’archive
Variables d’environnement	Séparer par projet et environnement, sans réutilisation entre tâches	Écrire dans l’environnement du processus lors de l’exécution du pipeline	Arrêter le processus et supprimer la configuration temporaire ainsi que les traces de l’historique shell
Artefacts de build et journaux	Lisibles uniquement par les membres du projet et le processus de livraison	Sortir vers un répertoire de tâche distinct	Transférer les artefacts nécessaires et supprimer le reste selon la règle de conservation

MOINDRE PRIVILÈGE

Moindre privilège

Si le build ne fait que récupérer le code, n’accordez ni droit d’écriture au dépôt ni droit de gestion des membres ; ne partagez pas les éléments de signature d’un projet avec les tâches d’autres projets.

À COURTE DURÉE

Autorisation temporaire

Les identifiants pouvant être émis pour une tâche ne doivent pas être conservés durablement. Les identifiants fixes doivent être stockés dans un gestionnaire contrôlé de secrets, avec des conditions de rotation clairement définies.

SORTIE PROPRE

Nettoyage après la tâche

Vérifiez simultanément les répertoires temporaires, les trousseaux, les fichiers d’environnement, l’historique shell, la configuration des dépendances, les journaux de build et les répertoires d’artefacts ; ne supprimez pas uniquement le code source.

Gestion du réseau et des nœuds

Cinq nœuds, un même périmètre de connexion

Les deux modèles disponibles de MiniRent peuvent être déployés à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul), à Hong Kong et dans l’est des États-Unis. Choisissez un nœud proche de votre équipe de développement principale ou de votre dépôt de code ; la disponibilité réelle est indiquée en temps réel dans la console.

Singapour

Convient aux équipes d’Asie du Sud-Est et aux points d’entrée de pipelines régionaux.

Japon (Tokyo)

Convient aux tâches de développement et de build au Japon et en Asie de l’Est.

Corée du Sud (Séoul)

Convient aux équipes coréennes et aux environnements de collaboration régionaux.

Hong Kong

Convient à la collaboration transrégionale entre la Chine méridionale et l’Asie du Sud-Est.

US-E

Est des États-Unis

Convient aux workflows de l’est de l’Amérique du Nord et transatlantiques.

Plan de gestion

Utilisé pour les commandes, l’état des équipements, les informations de connexion et les tickets d’assistance. Les opérations d’administration ne doivent pas servir de canal de transfert de données pour les scripts de build.

Session sur l’appareil

Les sessions SSH et VNC servent directement à utiliser l’appareil. Limitez les réseaux sources, vérifiez les informations de connexion et fermez la session lorsque vous quittez l’appareil.

Changement de nœud

Pour changer de nœud, envoyez un ticket depuis la console. Avant la migration, sauvegardez les artefacts nécessaires, révoquez les identifiants temporaires et vérifiez l’empreinte de l’hôte du nouveau point d’accès.

En cas de connexion anormale, effectuez d’abord ces quatre vérifications

01
Vérifiez l’identifiant de l’appareil, le nœud, le fuseau horaire et la période concernée.
02
Recherchez les nouvelles clés publiques, les comptes sur l’appareil, les enregistrements de Runner et les changements de permissions récents.
03
Révoquez les clés et jetons suspects, suspendez les tâches automatisées concernées et conservez des journaux masqués.
04
Envoyez les informations reproductibles via un ticket de console ou à support@minirents.com.

Objectif de disponibilité du service

99,9 %

Fonctionnement continu 365 jours par an

Tous les nœuds sont fournis en fonctionnement continu, sans période d’arrêt planifiée. Les incidents de service sont évalués à partir des enregistrements de la console, de l’état du nœud et de la confirmation de l’assistance.

Couverture de l’objectif de service 90 JOURS

Barre d’état des 90 derniers jours OBJECTIF 99,9

Il y a 90 jours Actuellement

La compensation est calculée selon les conditions de service applicables et les interruptions confirmées.

Consulter les conditions de service

Traitement des incidents de sécurité

De la détection au rétablissement : préserver les preuves sans diffuser les identifiants

Lors du signalement d’un problème de sécurité, les informations les plus utiles sont l’identifiant de l’appareil, le nœud, la période concernée, les étapes de reproduction, l’impact et des journaux masqués. Les clés complètes, mots de passe et jetons d’accès ne facilitent pas l’analyse et augmentent au contraire le risque.

01

Détecter

Notez les symptômes, l’identifiant de l’appareil, le nœud, le fuseau horaire, la première apparition et la dernière opération normale. Distinguez l’échec de connexion, le changement de permissions, les processus anormaux et l’exposition d’artefacts de build.
02

Limiter l’impact

Révoquez les clés publiques SSH, jetons de dépôt et clés de pipeline concernés, puis arrêtez les Runners ou tâches suspects. Ne remplacez pas massivement les journaux avant d’avoir consigné les informations essentielles.
03

Conserver des journaux masqués

Conservez l’heure des commandes, les codes d’erreur, les informations de processus et le contexte nécessaire ; masquez les mots de passe, clés privées, jetons complets, éléments de signature et lignes de commande contenant des paramètres sensibles.
04

Envoyer le rapport

Connectez-vous à la console pour envoyer un ticket ou écrivez à support@minirents.com. Indiquez « Rapport de sécurité » dans l’objet et précisez l’impact, les étapes de reproduction et les mesures de limitation déjà prises.
05

Vérifier le rétablissement

Faites tourner les identifiants concernés, vérifiez les permissions des membres et la configuration de l’automatisation, puis utilisez une tâche de test minimale pour vérifier la connexion, les dépendances, la signature et la production des artefacts. Ne rétablissez la concurrence complète qu’après confirmation de l’absence d’anomalie.

Envoyer un ticket de sécurité depuis la console Envoyer un e-mail à support@minirents.com

Checklist de sécurité utilisateur

Effectuez une vérification avant la mise en production, lors d’un changement de membre et avant la fin de la location

Cette checklist convient au développement individuel, aux fermes de build d’équipe et aux Runners autohébergés. Nous recommandons d’attribuer chaque point à un responsable et à un script automatisé, plutôt que de le laisser uniquement dans la documentation interne.

Minimum à appliquer :Clé publique distincte, vérification de l’empreinte, moindre privilège, aucune variable sensible dans le dépôt, journaux masqués, révocation des accès dès le départ d’un membre et nettoyage avant la fin de la location.

Vérifier la première connexion
Récupérez les informations de connexion dans la console et vérifiez le nœud, l’identifiant de l’appareil et l’empreinte de l’hôte.
Activer une authentification forte
Activez une authentification forte pour l’adresse e-mail professionnelle, le dépôt de code et le système de pipeline, et protégez les identifiants de récupération.
Interdire le partage des identifiants
Chaque membre et chaque tâche automatisée doivent utiliser une identité distincte afin d’éviter les clés partagées impossibles à tracer.
Mettre régulièrement les dépendances à jour
Verrouillez les versions et évaluez les mises à jour, en traitant en priorité les correctifs de sécurité des outils de build, des gestionnaires de dépendances et des Runners.
Surveiller le disque et les journaux
Évitez que les caches de build saturent le disque et vérifiez que les journaux ne contiennent pas accidentellement de variables d’environnement ou de jetons d’accès.
Nettoyer avant la fin de la location
Supprimez le code, les clés, les jetons, les éléments de signature, les trousseaux temporaires, les artefacts de build et les caches inutiles.

Étape suivante

Choisissez un Mac dédié dans le cloud et connectez-le selon votre processus de sécurité.

Les deux modèles physiques prennent en charge les cinq nœuds disponibles. Après la commande, récupérez l’état de l’appareil et les informations de connexion dans la console ; pour tout problème concernant un appareil existant, envoyez directement un ticket.

Louer un Mac dédié Se connecter à la console