Des limites de sécurité vérifiables

Contrôles de sécurité des nœuds dédiés, des limites physiques à la réponse aux incidents

Chaque commande correspond à un nœud physique Mac mini indépendant, et non à une machine virtuelle. HexVM assure la livraison du nœud, le réseau de base et le contrôle d’exploitation côté plateforme ; le client gère les autorisations des comptes, les clés de build, l’accès aux dépôts de code et les données présentes sur le nœud.

Louer un Mac dédié maintenant Contacter l’équipe sécurité

Les rapports de sécurité sont traités uniquement via les tickets de la console ou à l’adresse support@hexvm.com. N’envoyez jamais de clé privée réelle, de jeton d’accès complet ni d’identifiant non anonymisé.

Nœud Mac mini dédié HexVM et interface de contrôle de l’état de sécurité
Vérification des limites du nœud Normal
Attribution des ressources
Dédié à une seule commande
Type de calcul
Nœud physique
Accès de gestion
Identifiants et tickets contrôlés
Isolation du nœud 1 par commande
Couverture d’exploitation 365 jours
Objectif de service 99,9 %
Canaux de signalement 2
Répartition des responsabilités

Commencez par définir qui contrôle quoi

Un nœud physique dédié limite le partage des ressources de calcul, mais la sécurité repose toujours sur des actions conjointes de la plateforme et du client. Les points suivants détaillent les ressources, les autorisations, l’exploitation de la plateforme et les opérations côté client.

Limites des ressources physiques

Chaque commande correspond à un Mac mini indépendant ; le CPU, la mémoire et le stockage local ne sont pas partagés avec les instances d’autres clients. Les deux configurations disponibles sont la configuration M4 de base (16 Go, 256 Go) et la configuration M4 Pro (64 Go, 2 To).

  • Le nœud est dédié à une seule commande ; la facturation ne repose ni sur des vCPU ni sur de la mémoire partagée.
  • La région et le modèle du nœud sont définis lors de la commande ; la disponibilité affichée en temps réel dans la console fait foi.
  • Avant la fin de la période de location, terminez la migration des données, la révocation des clés et les sauvegardes locales.

Autorisations gérées par le client

Le client contrôle l’environnement de développement du nœud, les autorisations des membres, les clés SSH, les identifiants des dépôts, les caches de build et les tâches automatisées. Toute modification des autorisations doit être consignée et vérifiée par le responsable de la commande.

  • Après la première connexion, remplacez les identifiants temporaires et privilégiez l’authentification par clé.
  • Définissez des périmètres d’autorisation distincts pour les CI runners, l’administration manuelle et les tâches de déploiement.
  • N’utilisez pas durablement un même jeu d’identifiants administrateur à plusieurs.

Limites de l’exploitation de la plateforme

HexVM assure la livraison des commandes, les contrôles de santé des nœuds, la connectivité réseau de base, le suivi de l’état du service et le traitement des tickets. Toute opération sur un nœud nécessite de vérifier au préalable la propriété de la commande et la portée de la demande.

  • Nous ne demanderons jamais au client d’envoyer une clé privée réelle ou un jeton complet par e-mail.
  • Toute demande d’intervention sur un nœud doit préciser son ID, sa région, l’heure de l’incident et son périmètre d’impact.
  • Les actions côté plateforme visent à rétablir un état sécurisé et à confirmer l’impact sur le service.
Base de responsabilité partagée

HexVM fournit un nœud physique dédié et le contrôle d’exploitation côté plateforme ; le client gère les comptes, le code, les certificats, les clés, les autorisations des dépôts tiers et la stratégie de sauvegarde sur le nœud. En cas d’anomalie, les deux parties doivent partager une chronologie anonymisée et des éléments reproductibles.

Contrôle des accès

Réduisez les risques persistants en cinq actions récurrentes

La sécurité des accès ne repose pas sur une configuration unique. Intégrez la mise à jour des identifiants, le principe du moindre privilège, la révocation des membres et l’isolation des environnements aux processus d’arrivée, de déploiement et de départ.

01

Mettez immédiatement à jour les identifiants temporaires

Après réception des informations de connexion, vérifiez l’ID du nœud, la région et l’empreinte de l’hôte, puis remplacez le mot de passe temporaire. Ne copiez jamais les identifiants initiaux dans les discussions d’équipe, les documents publics ou les journaux de pipeline.

02

Privilégiez les clés SSH

Attribuez une clé distincte à chaque membre ou tâche automatisée, en conservant son empreinte et son usage. En cas de changement d’appareil, de fonction ou de suspicion de compromission, supprimez immédiatement la clé publique concernée et émettez-en une nouvelle.

03

Limitez les autorisations à chaque tâche

Les tâches de build ne doivent disposer que des droits nécessaires pour lire le code, écrire dans le répertoire de build et téléverser les artefacts. Réservez l’installation d’outils, la modification des paramètres système et la gestion des membres à un nombre restreint de responsables.

04

Révoquez les accès dès le départ d’un membre

Révoquez les clés publiques personnelles, les clés de déploiement des dépôts, les jetons d’enregistrement des CI runners et les droits sur les répertoires partagés, puis vérifiez les connexions récentes. Ne désactivez pas seulement un outil collaboratif en laissant l’accès au nœud ouvert.

05

Isolez développement, test et déploiement

Utilisez des comptes, des ensembles de clés et des autorisations de dépôt distincts pour chaque environnement. Les identifiants de déploiement ne doivent pas figurer dans les scripts de développement courants, et les tâches de test ne doivent pas accéder aux identifiants d’écriture du stockage des artefacts de production.

Protection des données

Définissez le chemin de sortie des données avant même leur arrivée sur le nœud

Le code, les artefacts de build et les éléments de signature n’ont pas le même niveau de sensibilité. Définissez pour chacun le mode de transfert, l’emplacement de stockage, les personnes autorisées et le moment de suppression.

01

Transfert

Utilisez une connexion SSH ou VNC sécurisée pour transférer les données et vérifiez l’empreinte de l’hôte lors de la première connexion. Vérifiez l’intégrité des fichiers volumineux et évitez les liens publics pour échanger des éléments de build.

02

Traitement

Placez le code, les caches, les artefacts et les éléments sensibles dans des répertoires dédiés. Les scripts temporaires ne doivent pas écrire de clés dans l’historique des commandes, la sortie du terminal ou les rapports de test.

03

Conservation

Les clés de build et les certificats doivent être accessibles uniquement aux tâches qui en ont besoin pour signer ou déployer. Limitez les droits d’exportation et consignez les responsables de l’importation, de la rotation et de la révocation.

04

Libération

Avant la fin de la location du nœud, exportez les artefacts et journaux d’audit nécessaires, révoquez les identifiants des dépôts et de la CI, puis supprimez les répertoires de travail, caches, fichiers temporaires et copies locales des clés.

Méthodes de contrôle recommandées pour les types de données courants
Type de données Emplacement de conservation recommandé Périmètre des autorisations Actions avant libération
Code source et dépendances Répertoire de travail contrôlé et répertoire de cache de build Membres de l’équipe de développement et runners désignés Vérifier l’état des commits et supprimer les fichiers sensibles non suivis
Clés de build et jetons d’accès Stockage d’identifiants restreint ou injection à l’exécution Uniquement les tâches de pipeline concernées et leurs responsables Révoquer, renouveler et supprimer les copies locales
Certificats et profils de provisionnement Environnement de signature à accès contrôlé Tâches de signature et responsables des déploiements Exporter les sauvegardes nécessaires et supprimer les copies du nœud
Artefacts de build Répertoire d’artefacts ou emplacement de stockage approuvé par l’équipe Rôles de test, de déploiement et d’audit Vérifier les sommes de contrôle et supprimer les versions temporaires après migration
Journaux et bundles de diagnostic Répertoire de journaux avec durée de conservation limitée Équipes d’exploitation et de sécurité, et propriétaires des tâches Anonymiser puis archiver ; supprimer les copies originales contenant des identifiants
Réseau et journaux

Donnez à chaque anomalie une chronologie, un périmètre et des preuves

Les journaux de connexion et de build doivent faciliter l’analyse, pas être conservés indéfiniment. Harmonisez les horaires, les champs et les règles de conservation afin de recouper les événements du nœud avec les systèmes de dépôt, de CI et d’artefacts.

Audit des connexions et détection des anomalies

Consignez l’heure de connexion, la source, le mode d’accès, le compte et le résultat. Vérifiez notamment les échecs répétés sur une courte période, les connexions à des heures inhabituelles, l’ajout de clés publiques inconnues, les élévations soudaines de privilèges et les runners qui passent régulièrement hors ligne.

  • Utilisez les mêmes champs pour les événements de connexion réussis et échoués.
  • Utilisez des comptes distincts pour les opérations administrateur et les tâches automatisées.
  • En cas d’anomalie de provenance, réduisez d’abord les accès, puis préservez les preuves.

Synchronisation de l’heure et format des journaux

Le nœud, la plateforme de dépôt, l’orchestrateur CI et le système d’artefacts doivent utiliser le même fuseau horaire ou indiquer clairement le décalage. Dans un ticket, indiquez l’heure de l’incident à la minute près au minimum, ainsi que la première détection et la dernière reproduction.

  • Conservez l’ID du nœud, l’ID de la tâche, l’identifiant du commit et le code de sortie.
  • Supprimez les mots de passe, jetons, clés privées et données personnelles avant d’envoyer les journaux.
  • Conservez séparément les journaux bruts et les conclusions de l’analyse manuelle.

Recommandations de conservation des journaux

Définissez la durée de conservation selon la sensibilité du code, la fréquence des déploiements et le cycle d’audit interne. Ne conservez dans les sorties de build que les champs nécessaires à l’analyse ; réduisez la durée de conservation des bundles de diagnostic sensibles et limitez leur téléchargement.

  • Définissez des règles de conservation distinctes pour les environnements de développement, de test et de déploiement.
  • Vérifiez régulièrement que les journaux peuvent être reliés au responsable de chaque tâche.
  • Lors de la suppression des journaux expirés, supprimez également les copies de diagnostic exportées.

Intégration de la supervision côté client

Vous pouvez intégrer sur le nœud les outils existants de supervision des processus, de l’espace disque, des files de build et de la santé des runners. Les alertes doivent préciser l’ID du nœud, la région, le seuil, la durée et l’état de rétablissement, plutôt que d’envoyer uniquement une capture impossible à analyser.

  • Surveillez l’espace disque disponible, les processus essentiels et le temps d’attente dans les files.
  • Déclenchez des alertes distinctes pour les pannes de service et les échecs isolés de build.
  • Après le rétablissement d’une alerte, conservez le même identifiant d’incident pour l’analyse rétrospective.
Stabilité d’exploitation

Objectif de disponibilité de 99,9 % et vue des 90 derniers jours

Tous les nœuds fonctionnent normalement 365 jours par an. La vue d’état affiche la disponibilité jour par jour ; en cas d’impact, un marqueur d’incident relie le périmètre, la durée et l’historique du traitement.

Objectif de service 99,9 %

Selon les conditions de service applicables, évaluez l’impact du service côté plateforme. Les problèmes liés à la configuration ou aux identifiants du client, aux systèmes tiers ou à un cas de force majeure ne sont pas pris en compte dans la disponibilité de la plateforme.

Période observée
90 jours
Granularité de l’état
Par jour
Incident en cours
Aucun
État du service jour par jour
Normal Incident de service
Il y a 90 jours Il y a 60 jours Il y a 30 jours Aujourd’hui

Résumé de la demande de crédit de service

Si vous estimez qu’un impact côté plateforme atteint le seuil prévu par les conditions, ouvrez un ticket dans la console en indiquant l’ID du nœud, la région, les heures de début et de fin, les résultats de connexion ou de tâche et les journaux anonymisés. HexVM vérifiera la chronologie, l’attribution de la commande et les conditions applicables, puis accordera le crédit de service prévu pour les commandes admissibles.

Soumettre un ticket dans la console
Réponse aux incidents

Un parcours de traitement en six étapes, de la détection à l’analyse rétrospective

Le traitement d’un incident de sécurité donne la priorité à la protection des limites d’accès et à l’intégrité des preuves. Des informations précises sur le nœud et des journaux anonymisés fournis par le client réduisent les vérifications répétées et accélèrent l’analyse.

  1. 01

    Détection

    Confirmez les symptômes, l’heure de première détection, les nœuds touchés et le périmètre métier. Conservez les erreurs brutes, les journaux de connexion et les identifiants de tâches ; évitez toute action répétée susceptible d’écraser les preuves.

    Coopération du client : fournissez l’ID du nœud, la région, la chronologie et la source de la détection.
  2. 02

    Isolement

    Selon le risque, réduisez les points d’entrée, supprimez les clés publiques suspectes, suspendez les tâches automatisées concernées et protégez les chaînes de build et de déploiement non touchées.

    Coopération du client : confirmez les comptes, dépôts et tâches pouvant être suspendus.
  3. 03

    Enquête

    Mettez en relation les connexions au nœud, les changements d’autorisations, les tâches de build, les opérations sur les dépôts et les enregistrements d’artefacts afin d’identifier le point d’entrée, la durée, les éléments touchés et l’étendue des données.

    Coopération du client : fournissez des journaux anonymisés, les étapes de reproduction et l’historique des changements récents.
  4. 04

    Remédiation

    Révoquez les identifiants touchés, corrigez les autorisations et la configuration, supprimez les tâches anormales, puis vérifiez le rétablissement des connexions, des builds, de la signature et du téléversement des artefacts.

    Coopération du client : effectuez la rotation nécessaire des jetons de dépôt, des clés et des certificats.
  5. 05

    Notification

    Utilisez le canal de contact vérifié associé à la commande pour communiquer le périmètre d’impact, l’état actuel, les actions effectuées et la date de la prochaine mise à jour. N’échangez pas d’informations sensibles via un canal non vérifié.

    Coopération du client : désignez un responsable capable de confirmer les impacts techniques et métier.
  6. 06

    Analyse rétrospective

    Documentez la cause racine, les lacunes de détection, les étapes de rétablissement et les responsables à venir, puis intégrez les améliorations durables aux revues d’accès, à la supervision et aux contrôles de déploiement.

    Coopération du client : vérifiez que les améliorations sont effectivement appliquées dans les processus de l’équipe.
Canal de signalement de sécurité

Signaler une vulnérabilité, une connexion inhabituelle ou un risque lié aux identifiants

Les problèmes de sécurité sont traités uniquement via les tickets de la console ou à l’adresse support@hexvm.com. Pour les anomalies liées à une commande ou à un nœud existant, privilégiez le ticket afin de vérifier la propriété de la commande et d’assurer le suivi.

Ticket de sécurité dans la console

Ce canal convient aux connexions anormales, changements d’autorisations sur un nœud, impacts de service et événements nécessitant une vérification côté plateforme pour des commandes existantes. Indiquez dans le ticket l’ID du nœud, la région, l’heure, le périmètre d’impact et les preuves anonymisées.

Ouvrir un ticket depuis la console

Adresse e-mail pour les rapports de sécurité

Ce canal convient aux vulnérabilités non associées à une commande, aux problèmes de sécurité reproductibles ou aux questions sur les risques liés aux identifiants. L’objet doit résumer le type de problème et le composant touché ; les pièces jointes doivent être anonymisées au préalable.

Envoyer à support@hexvm.com

Un rapport exploitable doit contenir

  • Le type de problème, l’heure de découverte et la possibilité actuelle de le reproduire.
  • L’ID et la région du nœud touché, ainsi que la page ou le parcours fonctionnel concernés.
  • Les étapes minimales de reproduction, le résultat attendu et le résultat observé.
  • Les requêtes, messages d’erreur, extraits de journaux ou captures d’écran anonymisés.
  • Les mesures d’isolement déjà prises et les changements susceptibles d’influencer l’enquête.
Ne joignez jamais au rapport

De clé privée réelle, de jeton d’accès complet, de mot de passe complet, de fichier de certificat non anonymisé ni d’identifiant permettant d’accéder directement à un dépôt ou à des artefacts. Pour vérifier un champ sensible, indiquez d’abord son type dans le ticket ; l’équipe d’assistance vous proposera une procédure sécurisée.

Apple Silicon dédié

Déployez votre Mac dans le cloud avec des limites clairement définies

Comparez les configurations et les durées de location des deux nœuds physiques dédiés, puis choisissez l’offre adaptée à vos builds Xcode, à votre CI/CD ou à votre développement continu. Tous les montants sont facturés en dollars américains (USD).

Louer un Mac dédié maintenant Voir les offres de location