Votre code, vos accès

Vos certificats de signature
restent sur votre machine

Chaque Mac mini est attribué à un seul utilisateur : ce n’est pas une machine virtuelle. Nous définissons clairement les limites des ressources physiques ; à vous de gérer les accès à votre poste cloud avec des clés, le principe du moindre privilège et des sauvegardes distinctes.

Cette page présente les limites de l’isolation et des interventions. Une machine dédiée ne constitue pas une sauvegarde automatique, et le chiffrement du disque ne remplace pas le contrôle des accès.

Machine physique dédiéeMémoire et disque non partagés
Identifiants sous votre contrôleClés privées et mots de passe de certificats hors des tickets
Sauvegarde avant échéanceLe disque de travail ne remplace pas une copie séparée
Isolation physique

Toute la machine, rien qu’à vous

Desk M4 est un Mac mini physique dédié : M4, 16 Go de mémoire et SSD de 256 Go. Pendant votre location, sa mémoire et son disque ne sont attribués à aucun autre utilisateur. Vous disposez de macOS avec son interface graphique et sa ligne de commande ; vous gérez vos projets, caches de compilation et environnement de signature.

Vos tâches restent séparées

Les ressources d’une même machine ne sont pas réparties entre plusieurs utilisateurs et les compilations de différents utilisateurs ne sont pas exécutées à tour de rôle. Vos tâches restent en concurrence avec les simulateurs, l’indexation et les processus en arrière-plan que vous lancez. Pour diagnostiquer un ralentissement, commencez par vérifier la charge de la machine.

Une machine dédiée n’implique pas des ressources illimitées.

Vous gérez votre environnement

La version de Xcode, les dépendances, les certificats et les profils de provisionnement font partie de votre environnement de travail. Notez les versions avant toute mise à niveau et ajoutez les configurations importantes à votre propre procédure de restauration. Ne conservez pas votre unique copie de matériel de signature sur le disque de travail cloud.

L’environnement se reconstruit ; les éléments essentiels doivent être sauvegardés.

La sécurité réseau reste à configurer

L’isolation physique ne définit pas les règles d’accès réseau. Après avoir activé SSH, le partage d’écran ou un service de développement, vérifiez les adresses d’écoute, l’authentification et les sources autorisées. N’exposez que les services nécessaires.

Machine dédiée, mais pas tous les ports ouverts.

Contrôle des accès

Vérifiez les clés avant de désactiver les mots de passe

Le compte du portail, l’utilisateur macOS et la clé privée SSH sont trois identifiants distincts. N’utilisez pas le même mot de passe pour le portail et le système. Chaque collaborateur doit avoir sa propre clé ; pour révoquer un accès, supprimez la clé publique correspondante. Ne partagez pas une clé privée entre tous les membres de l’équipe.

  1. Générez une clé en local

    Générez une clé sur votre ordinateur et protégez-la par une phrase secrète. Transférez uniquement le fichier de clé publique. N’envoyez pas la clé privée sans extension et ne la stockez ni dans un dépôt de code, ni dans des conversations, ni dans les artefacts de compilation.

    ssh-keygen -t ed25519
  2. Gardez une session ouverte, testez-en une autre

    Vérifiez les informations de connexion dans le portail, puis ajoutez la clé publique à la liste des clés autorisées de l’utilisateur cible. Lors de la première connexion, vérifiez l’empreinte de l’hôte. Gardez la session actuelle ouverte, testez l’authentification par clé dans un deuxième terminal, puis modifiez la configuration d’authentification.

    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys
  3. Désactivez les mots de passe après vérification

    Vérifiez où se trouve la configuration SSH de macOS et quels fichiers elle inclut, puis définissez les options ci-dessous. Après avoir vérifié la syntaxe, appliquez la configuration selon le mode de gestion des services du système. Testez une nouvelle session et ne fermez l’ancienne qu’une fois la connexion confirmée.

    PubkeyAuthentication yes
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    sudo /usr/sbin/sshd -t
Sécurité réseau

Utilisez un tunnel pour l’interface graphique et ouvrez les ports au cas par cas

À la prise en main de votre instance, vérifiez les ports de connexion indiqués dans le portail et les ports réellement en écoute sur macOS. Cette page ne présente pas comme des valeurs par défaut des règles de livraison qui n’ont pas été vérifiées. Votre configuration de base doit conserver les accès d’administration nécessaires et désactiver les services inutilisés. Si des restrictions par origine sont possibles, limitez l’accès aux réseaux de confiance.

Après la livraison, vérifiez chaque point au lieu de juger la sécurité d’un service à son numéro de port
Accès Recommandation Points à vérifier
SSH Ne gardez que les accès distants nécessaires et privilégiez l’authentification par clé. Port de connexion, utilisateurs autorisés, empreinte de l’hôte et connectivité depuis votre réseau local.
VNC / partage d’écran Privilégiez l’accès par tunnel SSH ; ne l’exposez pas directement sur Internet. État du service, port d’écoute distant et restrictions appliquées à l’accès direct selon vos besoins.
Aperçu et outils de débogage Privilégiez une écoute sur l’adresse de bouclage locale ; fermez rapidement tout accès temporaire. Présence d’une authentification ou d’interfaces de débogage, et éventuelle exposition de variables d’environnement ou de journaux sensibles.
Autres connexions entrantes N’activez rien sans besoin précis et n’ouvrez pas tous les ports pour résoudre un problème. Règles réellement appliquées par le pare-feu de l’hôte et par le réseau en amont ; vérifiez les deux niveaux.

Exemple de tunnel : gardez le partage d’écran distant derrière SSH

L’exemple ci-dessous ne fonctionne que si le service distant écoute sur le port 5900. Remplacez le nom d’utilisateur et l’adresse IP par les valeurs indiquées dans le portail. Si le service utilise un autre port, adaptez la commande. Connectez ensuite votre client local à 127.0.0.1:15900.

ssh -N -L 127.0.0.1:15900:127.0.0.1:5900 USER@HOST

Le tunnel chiffre les communications, mais ne ferme pas automatiquement les accès publics existants. Vérifiez aussi séparément les règles d’accès distant et fermez la session du tunnel une fois votre utilisation du bureau à distance terminée.

Effacement en fin de location

Récupérez votre dernière copie avant la fin de la location

À la fin de la location, le traitement concerne le disque système et le SSD supplémentaire qui vous a été attribué. L’effacement ne constitue pas une sauvegarde et ne remplace pas une prolongation de location. Avant l’échéance, exportez vos projets, certificats, artefacts de compilation et copies de configuration vers un emplacement que vous contrôlez, puis vérifiez que ces copies s’ouvrent correctement.

Avant l’échéance : exportez vos données

Fiez-vous à la date d’échéance affichée dans le portail et prévoyez la migration à l’avance. Arrêtez les Runner et les tâches qui continuent d’écrire sur le disque, puis exportez une dernière copie cohérente. Pour continuer à utiliser le service, vérifiez le renouvellement dans le portail.

Ne comptez pas sur le maintien de la connexion après l’échéance.

Après la fin : le nettoyage est lancé

À la fin du service, l’environnement de l’utilisateur précédent est traité selon la procédure prévue : les disques sont effacés et réinitialisés, SSD supplémentaire compris. Supprimer uniquement les dossiers de projet ne suffit pas à nettoyer la machine.

Pour vérifier le périmètre de l’intervention, contactez-nous via un ticket de commande.

Avant la remise en service : vérifiez le nettoyage

Avant toute nouvelle mise à disposition, le nettoyage et l’initialisation de l’environnement doivent être vérifiés. Si vos exigences de conformité imposent un délai ou un compte rendu d’effacement précis, transmettez d’abord les informations de commande afin de vérifier si cette demande peut être satisfaite, avant d’y migrer des données sensibles.

Les délais applicables sont ceux confirmés dans les conditions de service et le ticket de commande.

Cette page ne prévoit ni période de conservation après l’échéance ni possibilité de récupération après effacement. Destruction, restauration et migration répondent à des besoins différents : déterminez celui dont vous avez réellement besoin avant d’agir.

Accès pour les interventions

Définissez l’intervention avant d’en autoriser l’exécution

Les interventions courantes n’ont pas pour but de consulter le code de vos projets, vos certificats de signature ni vos fichiers professionnels. En cas de panne matérielle, de problème de connexion, d’opération système que vous avez demandée ou d’incident de sécurité, le périmètre du diagnostic et ses conséquences possibles doivent être précisés. Si l’accès à votre environnement utilisateur est nécessaire, confirmez les autorisations accordées via un ticket de commande.

Dans votre demande, distinguez ce qui peut être consulté de ce qui peut être modifié
Situation À confirmer d’abord Ce que vous pouvez fournir
Connexion impossible État de l’instance, connectivité réseau et état des services nécessaires ; ne partez pas du principe qu’une réinstallation est requise. Numéro de commande, extrait du message d’erreur et étapes de reproduction. Précisez si un redémarrage est autorisé.
Diagnostic dans le système Journaux, dossiers et autorisations de compte à examiner, ainsi que le risque d’interruption des tâches. Masquez les données sensibles dans les journaux. Si un accès temporaire est nécessaire, limitez les droits et révoquez-les une fois l’intervention terminée.
Réinstallation ou intervention sur disque Machine concernée, conséquences sur les données, état des sauvegardes et périmètre de l’intervention. Confirmez clairement toute opération destructive ; une demande vague comme « réparez-moi ça » ne vaut pas autorisation.
Anomalie ou incident de sécurité Accès concernés, restrictions à appliquer et besoins de conservation des preuves. Révoquez d’abord les identifiants compromis, conservez les journaux nécessaires, puis convenez des étapes de rétablissement.

N’envoyez pas de clé privée SSH, de clé privée de certificat, de mot de passe de trousseau ni de clé de récupération dans un ticket ou un e-mail. Pour nous aider à diagnostiquer un problème, commencez par fournir des informations expurgées. Les seuls moyens de contact sont les tickets du portail et support@macminivps.com.

À faire de votre côté

Un poste restaurable, des accès révocables

La sécurité ne se règle pas une fois pour toutes. À la première activation, à l’arrivée d’un collaborateur, lors d’une mise à niveau de la chaîne d’outils et avant la fin de la location, reprenez les points ci-dessous. Vérifiez d’abord la procédure de récupération, puis renforcez les accès pour éviter de vous bloquer hors de votre machine.

  • Avant d’activer FileVault, testez la procédure de récupération à distance

    Le chiffrement protège les données au repos, mais après un redémarrage, le disque peut devoir être déverrouillé avant que les services distants soient de nouveau disponibles. Vérifiez comment la machine démarre et se déverrouille dans votre environnement, conservez la clé de récupération dans un autre emplacement sécurisé, puis décidez si vous souhaitez activer FileVault.

  • Sauvegardez le trousseau séparément des informations de déverrouillage

    Ne sauvegardez que les éléments nécessaires et limitez l’accès aux copies. Ne stockez pas une copie du trousseau et son mot de passe dans le même dossier de projet ou parmi les artefacts de compilation. Vérifiez que la sauvegarde est utilisable.

  • Exportez régulièrement vos certificats de signature et les clés privées nécessaires

    Utilisez un fichier d’export protégé par mot de passe et vérifiez sa période de validité, son usage et les éléments requis pour la restauration. La présence d’un fichier de certificat ne garantit pas qu’il contienne une clé privée utilisable. Vérifiez l’importation et le processus de signature dans un environnement contrôlé.

  • Limitez les droits des identifiants CI au strict nécessaire

    Utilisez une identité distincte pour le Runner et limitez les jetons aux projets et opérations nécessaires. Évitez d’afficher des variables d’environnement dans les journaux. Au départ d’un collaborateur ou à la fin d’une tâche, révoquez les clés publiques et jetons devenus inutiles.

  • Conservez une copie restaurable des projets hors du disque de travail

    Stockez votre code dans un dépôt que vous contrôlez et sauvegardez séparément les ressources volumineuses et les artefacts de compilation. Notez la version de Xcode, les dépendances et les commandes de compilation. Les caches se reconstruisent ; les éléments de signature et le code non soumis ne se récupèrent pas à partir d’un cache.

  • Avant la fin de la location, faites l’inventaire des autorisations externes

    Après la migration des données, déconnectez les Runner CI, révoquez les jetons temporaires et supprimez les autorisations côté serveur devenues inutiles. Ne vous contentez pas de vider le dossier de projet local en laissant les systèmes externes continuer à faire confiance à ce poste.

Définissez vos règles d’accès,
puis migrez vos compilations

Besoin d’un Mac physique dédié ? Choisissez votre poste. Pour des éléments de signature sensibles ou des exigences de sécurité d’équipe, confirmez d’abord le périmètre des accès, de la récupération et de l’effacement via un ticket.