Nœud physique et périmètre d’accès

La sécurité commence par un nœud physique dédié, pas par des promesses vagues

Chaque commande valide reçoit un nœud physique Apple Silicon dédié. VMOak sépare la gestion, la livraison et les charges de travail, tout en encadrant les actions d’administration par la délivrance des identifiants, l’approbation et la traçabilité.

La sécurité n’est pas une fonctionnalité assumée par une seule partie. Nous gérons la livraison du nœud, le compte de plateforme et les opérations nécessaires ; le client gère les accès aux dépôts, les jetons de déploiement, les fichiers de travail, le terminal de connexion et les accès de son équipe.

Louer un Mac cloud Voir le guide de connexion sécurisée
Attribution du nœud
1 commande valide correspond à 1 machine physique dédiée
Mode d’accès
Le client modifie les identifiants temporaires après leur remise
Périmètre du support
Nous ne demandons ni clé privée complète ni jeton de dépôt
REGISTRE DE SÉCURITÉ DES SESSIONS

Registre des sessions distantes

Périmètre confirmé
01
Association commande-nœud Vérification du modèle, du nœud et du titulaire de la commande ; aucune ressource physique n’est partagée avec d’autres commandes.
Terminé
02
Contrôle avant livraison Vérification du démarrage du système, de la connectivité réseau, du stockage et de l’état du compte d’accès.
Terminé
03
Délivrance des identifiants temporaires Remis par un canal contrôlé, avec obligation de les modifier dès la première connexion.
Délivré
04
Restriction des privilèges d’administration Accès limité au périmètre nécessaire lors d’un dépannage autorisé, avec motif et résultat consignés.
Limité
Principes de session Moindre privilège · Traçable · Révocable
Modèle de confiance

Les limites entre le contrôle de la plateforme et celui du client sont clairement définies

Le principe fondamental de VMOak repose sur l’attribution d’un nœud physique, et non sur une capacité logique découpée sur un hôte partagé. Pendant la validité de la commande, le Mac attribué est réservé au client ; la gestion couvre la commande, la livraison et les opérations nécessaires, tandis que les charges du client s’exécutent sur son nœud.

01

Isolation du nœud physique

Chaque commande correspond à une machine physique dédiée ; le processeur, la mémoire et le stockage local ne sont pas partagés avec d’autres clients. Le Bureau à distance, les tâches SSH et les processus de build s’exécutent sur le même appareil attribué.

  • Identité du nœud liée à la commande
  • Vérification du modèle et de la capacité de stockage avant livraison
  • Arrêt des voies d’accès existantes à la fin de la commande
02

Séparation de la gestion et des charges de travail

La console sert à gérer l’état des commandes, la remise des identifiants et les demandes de support ; elle ne sert pas de répertoire de travail pour le code, les artefacts de build ou les fichiers du projet. Les tâches du client s’exécutent sur le nœud physique attribué.

  • Les demandes de support recueillent uniquement les informations nécessaires au dépannage
  • Les opérations d’administration restent limitées au périmètre nécessaire
  • Les autorisations temporaires sont retirées une fois le dépannage terminé
03

Responsabilités du client

Le client décide qui peut se connecter au nœud, quels jetons de dépôt sont utilisables et quelles données sont envoyées sur le Mac distant. Les changements d’équipe, la révocation des clés et la sauvegarde des données métier doivent être intégrés à ses procédures internes.

  • Limiter la portée et la durée des jetons de dépôt
  • Supprimer immédiatement les accès après un départ ou un changement de poste
  • Chiffrer les fichiers sensibles et conserver une sauvegarde indépendante
Contrôle de livraison

Cinq vérifications de l’appareil avant de délivrer les informations d’accès

Le contrôle de livraison confirme que le nœud physique associé à la commande peut être mis en service. Il porte sur l’appareil, le système, le réseau, le stockage et le compte d’accès, sans remplacer la vérification de disponibilité par des benchmarks non vérifiés.

  1. 01

    État de l’appareil

    Vérification de l’identité du nœud physique, du modèle commandé et de l’état matériel de base afin d’assurer la concordance entre le dossier de livraison et l’appareil attribué.

    Délivré après validation
  2. 02

    Démarrage du système

    Vérification du démarrage normal de macOS, de l’accès à l’interface graphique et à la ligne de commande, ainsi que de l’heure système et des services de base.

    Démarrage confirmé
  3. 03

    Connectivité réseau

    Vérification des chemins entrants nécessaires, de l’accès sortant et de l’état des services requis par le Bureau à distance et SSH.

    Connectivité confirmée
  4. 04

    Capacité de stockage

    Vérification du stockage intégré commandé et des options ajoutées, de la capacité visible et de l’état du système de fichiers.

    Capacité vérifiée
  5. 05

    Compte d’accès

    Vérification de l’utilisation du compte temporaire pour la première connexion, consignation de son périmètre et modification des identifiants comme première mesure de sécurité après livraison.

    À modifier par le client
Sécurité des identifiants

Les identifiants temporaires servent uniquement à la première connexion ; le client prend ensuite en charge l’accès permanent

Les informations d’accès doivent être considérées comme une délivrance ponctuelle, et non comme un mot de passe à transférer durablement. Modifiez les identifiants dès la première connexion, puis séparez les accès par personne et par tâche automatisée afin de réduire les risques non traçables liés aux mots de passe partagés.

Cycle de vie des identifiants De la délivrance à la révocation
Délivrance

Accès avec un compte temporaire

L’adresse d’accès, le nom du compte et les identifiants temporaires sont fournis dans le dossier de livraison. Ne transférez pas ces informations dans des groupes publics, des dépôts de code ou des journaux de build.

Mise à jour

Modification après la première connexion

Utilisez des identifiants suffisamment longs et uniques. Lorsque plusieurs personnes interviennent, elles ne doivent pas partager durablement les mêmes informations de connexion interactive.

Séparation

Autorisations distinctes pour les personnes et l’automatisation

Le Bureau à distance interactif, l’administration SSH et le Runner CI/CD utilisent des voies d’accès différentes. Les jetons d’automatisation sont limités aux dépôts et opérations nécessaires à la tâche.

Révocation

Nettoyage immédiat après un changement d’équipe

Lorsqu’un membre part, change de rôle ou perd un appareil, révoquez ses clés publiques, jetons et droits de compte, puis vérifiez les connexions récentes.

Clés SSH

Téléversez uniquement la clé publique, jamais la clé privée complète

La clé privée doit rester sur le terminal contrôlé par le client ou dans un système de gestion des clés contrôlé. Utilisez des clés distinctes et identifiables pour chaque personne et chaque tâche automatisée afin de pouvoir les révoquer précisément.

  • Nommez les clés publiques selon l’utilisateur ou la tâche
  • Limitez localement les droits de lecture des fichiers de clés privées
  • Supprimez la clé publique correspondante dès qu’elle n’est plus utilisée
Exemple de contrôle des autorisations 
identity: build-runner
scope: repository-read
interactive-login: false
expires: project-policy
owner: mobile-ci-team

Cet exemple illustre le principe du moindre privilège ; il ne signifie pas que la plateforme crée une stratégie d’accès au dépôt pour le client.

Accès d’administration

Toute intervention humaine doit avoir un motif, un périmètre et une fin

Une demande de support n’accorde pas automatiquement l’accès aux charges du client. Une procédure d’analyse humaine n’est engagée qu’avec l’autorisation explicite du client, lorsque le problème distant ne peut pas être résolu à partir de l’état du système, de journaux désensibilisés ou d’actions côté client.

01

Confirmer le problème et l’autorisation

Consigner le numéro de commande, le nœud, l’heure du problème, son impact et les contrôles déjà effectués par le client. Avant d’accéder au nœud, préciser l’objectif de l’intervention.

02

Limiter le périmètre nécessaire

L’accès couvre uniquement l’état du système, la configuration des services ou les journaux nécessaires au dépannage ; il ne sert pas à consulter du code ou des fichiers métier sans rapport.

03

Consigner les opérations

Conserver les actions clés, les observations et les changements de configuration afin de distinguer les actions du client, l’état du système et les opérations du support.

04

Terminer et retirer les droits

Une fois le dépannage terminé, fermer les accès temporaires et expliquer au client le résultat, les changements et les signaux à continuer de surveiller.

Scénarios de support courants et périmètre des informations autorisées
Scénario À fournir en priorité par le client Opérations d’administration éventuellement nécessaires À ne pas fournir
Échec de connexion distante Heure, réseau du client, message d’erreur, identifiant du nœud Vérifier l’état des services, le chemin des ports et l’état du compte Clé privée complète, jeton de dépôt non désensibilisé
Interruption d’un processus de build Commande, code de sortie, journaux désensibilisés, symptômes liés aux ressources Vérifier les processus système, l’espace disque et les services de base Code source complet du projet, clés de production
Anomalie de capacité de stockage Résumé de l’occupation des répertoires, configuration de la commande, capacité attendue Vérifier le système de fichiers, les montages et les options ajoutées à la commande Contenu des fichiers métier, copie de données non chiffrées
Réseau et sessions distantes

La sécurité des connexions dépend du transport, des ports, du terminal et de la clôture de session

Le contrôle réseau d’un Mac distant ne se résume pas à la possibilité de se connecter. Les capacités du terminal, les ports exposés, l’état de l’appareil client et la fin de session déterminent ensemble le risque réel. Utilisez en priorité des connexions chiffrées et limitez les accès réseau inutiles.

Session Bureau à distance

Vérifiez que le client prend en charge le chiffrement requis et évitez d’enregistrer des identifiants permanents sur un terminal non fiable. À la fin du travail, quittez activement la session et fermez les fenêtres inutilisées.

Avant la connexion
Vérifiez l’adresse, le compte et la provenance du client ; assurez-vous que l’appareil local est à jour et verrouillable.
Pendant la connexion
Évitez de transmettre des clés permanentes via le presse-papiers et n’affichez pas de configuration sensible lors d’un partage d’écran.
Après la connexion
Quittez la session graphique, supprimez les téléchargements temporaires et vérifiez qu’aucune application sensible ne reste au premier plan.

Connexions SSH et automatisées

Utilisez des clés publiques distinctes et des jetons à privilèges minimaux pour les tâches automatisées. N’ouvrez pas de ports pour des services qui n’ont pas à être publics et fermez les accès temporaires à la fin de la tâche.

Contrôle des ports
Ne conservez que les accès réellement nécessaires à la tâche et évitez de laisser ouverts durablement des services inutiles.
Séparation des clés
Séparez les clés des personnes et celles des Runners, ainsi que les droits de lecture et de publication des dépôts.
Analyse des anomalies
Après une connexion inconnue, révoquez d’abord les clés concernées, puis conservez la chronologie, l’adresse source et les informations sur les processus.
Périmètre des données de facturation

Le statut du paiement est associé à la commande ; les données complètes de carte ne figurent pas sur les pages VMOak

Le processus de paiement ne conserve que les informations nécessaires pour finaliser la commande, vérifier son état et traiter les questions de facturation. Les deux modes de paiement suivent des contrôles différents, mais sont tous deux réglés en dollars américains (USD) ; la passerelle disponible est celle indiquée lors du paiement.

Paiement par carte

Visa / Mastercard / Amex

Les paiements par carte sont traités par Stripe. Les pages VMOak évitent de conserver le numéro complet, le code de sécurité et autres données complètes de carte ; la commande ne reçoit que les informations nécessaires au paiement et à la facturation.

  • Facturation en dollars américains (USD)
  • La commande conserve le statut du paiement et les références de transaction nécessaires
  • Les questions de facturation sont traitées par ticket depuis la console ou par e-mail d’assistance
Paiement on-chain

USDT-TRC20

Les commandes USDT-TRC20 sont vérifiées à partir de la transaction on-chain. Pour une question de facturation, fournissez le numéro de commande, l’identifiant de transaction et l’heure du paiement, sans joindre de clé privée de portefeuille ni d’autre identifiant de contrôle.

  • Prix en dollars américains (USD)
  • Vérification par commande et identifiant de transaction on-chain
  • Le client conserve toujours lui-même sa clé privée et sa phrase de récupération
VMOak a besoin de Numéro de commande, statut du paiement, référence de transaction nécessaire VMOak n’a pas besoin de Données complètes de carte, clé privée de portefeuille, identifiants sans rapport
Réponse aux incidents de sécurité

Confirmer les faits, contenir l’impact, puis restaurer et analyser

Le traitement d’un incident de sécurité ne remplace pas les preuves par des suppositions. Après réception du signalement, VMOak confirme d’abord la commande, le nœud, le compte et la période concernés, puis réduit les accès selon le risque, préserve les informations nécessaires et mène l’enquête.

  1. 01

    Confirmer

    Vérifier l’auteur du signalement, le numéro de commande, le nœud, l’heure de première détection, les faits inhabituels et l’impact toujours présent ; distinguer problème de connexion, problème de compte et incident de sécurité potentiel.

    Établir la chronologie
  2. 02

    Isoler

    Selon l’étendue de l’impact, restreindre les sessions, identifiants ou points d’entrée réseau suspects. L’isolement vise à empêcher l’aggravation du risque tout en préservant autant que possible les preuves nécessaires à l’enquête.

    Limiter l’impact
  3. 03

    Enquêter

    Examiner les journaux de connexion, les processus, les changements de configuration, les opérations du support et les preuves désensibilisées fournies par le client afin d’identifier le point d’entrée, les éléments touchés et la durée.

    Vérifier les preuves
  4. 04

    Restaurer

    Après fermeture du point d’entrée à risque, rétablir les accès nécessaires, mettre à jour les identifiants ou la configuration concernés et préciser les révocations de jetons de dépôt, rotations de clés et contrôles de fichiers à effectuer par le client.

    Rétablir le service
  5. 05

    Notifier et analyser

    Informer le client concerné des faits confirmés, des actions menées, des risques restants et des étapes recommandées. Les éléments non confirmés sont signalés comme tels ; aucune supposition n’est présentée comme une conclusion.

    Constituer le dossier de traitement
Signaler un incident

Fournissez le minimum de preuves nécessaire pour reconstituer la chronologie

Indiquez en priorité le numéro de commande, le nœud, l’heure de première détection, la dernière heure normale, l’adresse source inhabituelle, les messages d’erreur, les comptes concernés, les actions d’isolement effectuées et les journaux désensibilisés. Ne transmettez pas de clé privée complète, de jeton maître de dépôt ni de données métier non désensibilisées.

Connectez-vous à la console pour ouvrir un ticket Envoyer un e-mail de signalement
Checklist de sécurité du client

Effectuez ces actions avant de connecter le nœud à votre équipe

Cette checklist s’applique au développement distant, au CI/CD, aux Runners autogérés, aux expérimentations d’IA et aux workflows créatifs. Plus l’équipe est grande, plus chaque action doit avoir un responsable et une fréquence traçables.

01

Modifier les identifiants initiaux

Modifiez les identifiants temporaires dès la première connexion et n’utilisez pas le même mot de passe pour votre messagerie, votre hébergement de code ou d’autres serveurs.

Responsable : administrateur du nœud
02

Limiter les jetons de dépôt

Accordez uniquement les droits nécessaires au projet et à la tâche, séparez lecture, build, publication et administration, et définissez une fréquence de renouvellement interne.

Responsable : administrateur des dépôts
03

Séparer les clés des personnes et des Runners

Ne réutilisez pas les clés de connexion des personnes pour l’automatisation. Utilisez une identité distincte pour chaque Runner afin de faciliter sa désactivation, son analyse et sa rotation.

Responsable : administrateur CI/CD
04

Nettoyer régulièrement les accès

Vérifiez les comptes locaux, les clés publiques SSH, les jetons de dépôt et la configuration de l’automatisation ; supprimez les accès liés aux projets terminés ou inutilisés.

Responsable : responsable des accès de l’équipe
05

Chiffrer les fichiers sensibles

Avant d’envoyer un fichier sur le nœud, vérifiez qu’il est réellement nécessaire. Utilisez un chiffrement contrôlé par le client et conservez une sauvegarde indépendante.

Responsable : propriétaire des données
06

Retirer rapidement les accès des membres

Lorsqu’un membre part, change de rôle ou termine une mission externe, révoquez simultanément ses comptes distants, clés publiques, jetons et droits sur les répertoires partagés.

Responsable : manager de l’équipe
À chaque changement de personnel Vérifier les comptes, clés publiques et jetons de dépôt
À chaque fin de projet Nettoyer le cache, les artefacts de build et les identifiants temporaires
À chaque anomalie Préserver d’abord les preuves, puis révoquer l’accès et ouvrir un ticket
Commencer par des limites claires

Choisissez un Mac cloud réservé à une seule commande

Confirmez d’abord la configuration M4 ou M4 Pro, les six nœuds disponibles à la commande et la période de facturation, puis finalisez la commande dans la console. La disponibilité réelle du nœud est celle indiquée en temps réel par la console.

Louer un Mac cloud Voir les configurations et les prix