Modèle de sécurité et responsabilités

La sécurité commence par un Mac dédié et repose aussi sur des règles d’utilisation claires

BookaMac attribue à chaque commande un Mac mini physique dédié, et non une machine virtuelle découpée sur un hôte partagé. L’isolation physique réduit le périmètre de ressources informatiques partagé avec d’autres locataires, mais les identifiants, le code, les certificats, les dépendances et les sessions distantes doivent toujours être gérés par l’utilisateur selon les bonnes pratiques d’ingénierie.

Cette page précise ce qui relève de notre responsabilité, ce que vous devez contrôler et la manière dont nous fournissons des informations vérifiables en cas d’anomalie.

Louer un Mac mini dédié maintenant Consulter la documentation de connexion et de dépannage
1 commande correspond à 1 ordinateur physique dédié
Pas de machine virtuelle Aucune instance du système d’exploitation partagée
Responsabilités traçables Les limites entre la plateforme et l’utilisateur sont clairement définies
L’isolation ne dispense pas de la gestion

Quels problèmes le Mac physique dédié résout-il, et lesquels restent à votre charge ?

Pour évaluer les capacités de sécurité, distinguez l’isolation matérielle, le contrôle des identités, la gestion des charges de travail et la gouvernance des données. Les responsabilités de chaque niveau ne peuvent pas être remplacées par le simple mot « dédié ».

Isolation physique au niveau de la commande

Chaque commande active correspond à un Mac mini physique dédié. Votre charge de travail ne partage avec aucune autre commande la même instance du système d’exploitation, la mémoire ou le système de fichiers du disque local. Ce fonctionnement diffère des environnements informatiques partagés, où plusieurs locataires dépendent des mécanismes d’isolation de l’hôte.

  • Le processeur physique, la mémoire et le stockage local de l’appareil sont dédiés à la commande
  • Un même appareil en fonctionnement n’est jamais attribué simultanément à plusieurs commandes
  • La configuration du répertoire et les informations de livraison peuvent être vérifiées dans la commande

L’isolation ne corrige pas automatiquement les identifiants faibles

Partager une identité administrateur, réutiliser une clé privée, enregistrer des identifiants d’accès dans un dépôt ou conserver durablement une session distante neutralise les avantages de l’isolation physique. L’identité et les privilèges doivent être activement maîtrisés par l’utilisateur.

L’isolation ne constitue pas non plus une solution de sauvegarde

Un disque local dédié ne signifie pas qu’une seconde copie existe. Les dépôts, artefacts de build, fichiers de modèle et ressources multimédias doivent être enregistrés, selon leurs objectifs de restauration, dans un emplacement contrôlé par l’utilisateur, puis vérifiés avant la fin de la commande.

Méthode pour évaluer le périmètre : Si le risque provient du partage de ressources informatiques avec d’autres locataires, un ordinateur physique dédié réduit ce périmètre de risque. S’il provient de mots de passe faibles, d’une suppression accidentelle, de dépendances malveillantes, de privilèges excessifs ou de données non sauvegardées, il doit être traité séparément dans le workflow.
Contrôle des accès

Séparez d’abord les identités, puis réduisez les privilèges au strict nécessaire

Un Mac distant sécurisé ne devrait pas reposer sur un unique accès administrateur partagé durablement par plusieurs personnes. Les utilisateurs, les tâches automatisées et les opérations de diagnostic ponctuelles doivent employer des identités et des identifiants ayant des cycles de vie distincts.

01 / Identités

Chaque opérateur utilise des identifiants distincts

Créez une identité locale identifiable pour chaque personne devant se connecter, afin d’éviter le partage durable d’un compte administrateur. Lorsqu’un membre quitte le projet ou change de rôle, son accès peut être révoqué individuellement sans remplacer les identifiants de tous les autres.

  • Séparer les identités humaines et automatisées
  • Définir clairement la fin des autorisations de diagnostic temporaires
  • Ne pas transmettre d’identifiants complets dans les conversations
02 / Clés

Générez une clé SSH dédiée au nœud

Ne copiez pas la même clé privée dans plusieurs projets et appareils. Il est recommandé de répartir les clés par équipe, environnement ou nœud et de protéger les clés privées localement. En cas de suspicion de compromission, supprimez immédiatement la clé publique correspondante et réémettez-en une nouvelle.

  • Conserver les clés privées uniquement sur des terminaux contrôlés
  • Effectuer une vérification de connexion après toute modification de clé publique
  • Consigner l’opérateur et l’heure d’achèvement dans l’historique de rotation
03 / Privilèges

N’accordez pas de privilèges administrateur permanents par défaut

Extraire du code, lancer des builds et consulter les journaux au quotidien ne nécessite généralement pas de privilèges administrateur permanents. Élevez temporairement les privilèges uniquement pour installer des outils système ou modifier une configuration protégée, puis vérifiez l’étendue des changements.

  • Le service de build n’accède qu’aux répertoires nécessaires
  • Les scripts automatisés ne stockent pas d’identifiants permanents à privilèges élevés
  • Les changements d’environnement sont consignés dans l’historique d’exploitation de l’équipe
Protection des accès distants

Faites de la première connexion, des sessions quotidiennes et des vérifications anormales des étapes systématiques

Les connexions SSH et graphiques répondent à des besoins différents, mais exigent toutes deux de confirmer le nœud cible, de protéger les identifiants, de fermer activement les sessions et de conserver suffisamment d’éléments pour le diagnostic.

ROUTE SSH

Vérification de la connexion en ligne de commande

  1. Vérifier la cible de connexion

    Confirmez l’adresse, le port et le nom d’utilisateur à partir des informations de livraison de la commande ; n’utilisez pas d’adresse de transfert dont l’origine est inconnue.

  2. Vérifier l’empreinte de l’hôte

    Lors de la première connexion ou si l’empreinte change, interrompez la connexion et vérifiez à nouveau les informations de livraison. N’ignorez pas directement l’avertissement pour poursuivre.

  3. Remplacer les identifiants temporaires

    Après le premier accès, installez votre propre clé publique, vérifiez qu’une nouvelle session fonctionne, puis supprimez les accès temporaires devenus inutiles.

  4. Vérifier les événements anormaux

    Surveillez les sources inconnues, les horaires inhabituels et les tentatives d’échec répétées. En cas de comportement suspect, limitez d’abord l’accès, puis conservez des éléments de preuve désensibilisés.

SESSION GRAPHIQUE

Gestion des sessions graphiques

  1. Les identifiants ne doivent apparaître ni dans les scripts ni dans les dépôts

    Les identifiants d’accès à l’interface graphique doivent être conservés dans un gestionnaire local contrôlé, et non dans la configuration du projet, les journaux de build ou les documents partagés.

  2. Nettoyer les informations sensibles avant de partager l’écran

    Avant toute collaboration à distance, fermez les fenêtres contenant des clés, certificats, informations de paiement ou adresses internes ; n’affichez que ce qui est nécessaire au diagnostic.

  3. Quitter activement la session une fois la tâche terminée

    Fermer la fenêtre d’une application ne met pas fin à la session distante. Quittez la session après la tâche et vérifiez qu’aucun transfert temporaire ni outil en arrière-plan ne subsiste.

  4. En cas de problème de connexion, commencez par vérifier la documentation

    Suivez le guide de connexion pour contrôler le réseau local, l’adresse cible, le port, l’empreinte et l’état des identifiants, puis envoyez des journaux désensibilisés via la console.

Consulter la procédure de première connexion
Cycle de vie des données

Du classement avant import à une migration vérifiable avant la fin de la commande

La sécurité des données ne commence pas à l’expiration de la commande. Déterminez avant l’accès au nœud les catégories de données, l’emplacement de restauration et la personne responsable du nettoyage.

A

Avant l’importation

Synchronisez uniquement les dépôts, dépendances, ressources et fichiers de modèle nécessaires à la tâche. Appliquez des restrictions d’accès plus strictes aux clés, certificats et données de production ; ne copiez pas l’intégralité de votre dossier de téléchargements personnel sur le nœud.

Résultat vérifié : l’étendue des données sur le nœud correspond à la liste des tâches.
B

Pendant l’utilisation

L’utilisateur est responsable des droits sur les répertoires de travail, du contrôle de version, des sauvegardes et de la conformité. Les artefacts importants doivent être synchronisés vers un stockage contrôlé par l’utilisateur ; le disque local de l’appareil ne doit pas être l’unique copie.

Résultat vérifié : le code et les artefacts essentiels disposent d’une copie indépendante récupérable.
C

Avant l’expiration

Migrez les dépôts, artefacts de build, journaux et configurations nécessaires, puis vérifiez le nombre de fichiers, les sommes de contrôle ou l’état du dépôt. Supprimez ensuite les clés, identifiants, certificats et fichiers temporaires devenus inutiles.

Résultat vérifié : le nouvel emplacement est lisible et les éléments d’accès sensibles du nœud ont été révoqués.
D

Après la fin de la commande

Le nœud entre dans le processus de traitement du service et n’est plus accessible à la commande d’origine. La plateforme traite l’état de l’appareil selon les besoins de livraison, de sécurité et d’exploitation du service ; l’utilisateur ne doit pas considérer l’appareil après la fin de la commande comme une solution de conservation des données.

Résultat vérifié : la reprise d’activité ne dépend pas d’une commande terminée.

Principe de sortie :Migrez et vérifiez d’abord, puis supprimez la copie locale ; révoquez d’abord les éléments d’accès, puis clôturez l’historique des opérations du responsable. Ne confondez pas « déjà copié » avec « restauration déjà vérifiée ».

Réseau et journaux

Traiter séparément les journaux d’exploitation et le contenu de travail de l’utilisateur

L’assistance et le diagnostic de sécurité nécessitent certains journaux limités de connexion et de service, mais ceux-ci ne doivent pas être interprétés comme une revue habituelle du code, des documents ou du contenu de build de l’utilisateur.

Périmètre de traitement des journaux d’exploitation et du contenu de travail utilisateur
Catégorie d’information Contenu type Finalité du traitement Ce que l’utilisateur doit faire
Journaux de connexion Heure de connexion, informations de source, service cible et état du résultat Diagnostiquer les connexions d’assistance, identifier les tentatives anormales et assurer le fonctionnement du service Indiquer l’heure exacte lors du signalement et désensibiliser si nécessaire l’adresse source
État de la commande et de l’appareil Identifiant de commande, configuration, région, état de livraison et état de fonctionnement de base Vérifier la livraison et le renouvellement, localiser les pannes et délimiter les incidents de sécurité Fournir uniquement l’identifiant de commande nécessaire, sans envoyer d’identifiants d’accès complets
Communications d’assistance Description du problème, journaux désensibilisés, étapes de reproduction et historique du traitement Répondre aux questions, suivre le traitement et éviter les diagnostics répétés Supprimer les clés privées, jetons d’accès, contenus de certificats et informations personnelles sans rapport
Contenu de travail utilisateur Code, ressources, modèles, documentation de projet et artefacts de build Géré par l’utilisateur pour son propre workflow, et non traité comme un journal d’exploitation habituel Définir vous-même les droits, sauvegardes, règles de conformité et procédures de nettoyage en fin de commande
Avant d’envoyer des éléments de diagnostic : Conservez les commandes, codes d’erreur, heures et contexte nécessaire ; supprimez les clés privées, identifiants complets, texte des certificats, jetons d’accès, données métier et informations personnelles sans rapport.
Périmètre des paiements

Des moyens de paiement limités, des commandes réglées en dollars

BookaMac accepte uniquement USDT-TRC20 et Visa / Mastercard / Amex (via Stripe), avec un règlement intégral en dollars américains (USD). Les passerelles réellement disponibles sont indiquées en temps réel lors du paiement.

Le traitement des paiements collecte uniquement les informations nécessaires à la finalisation de la transaction, à la vérification du paiement, au traitement des questions de facturation et au respect des exigences de sécurité nécessaires. Les identifiants de paiement sont traités séparément du code, des fichiers et du contenu de build présents sur le nœud utilisateur.

USDT-TRC20

Paiement on-chain

Avant de payer, vérifiez le montant de la commande, le réseau et les informations de réception. L’identifiant de transaction peut servir à vérifier l’état, mais ne doit pas être envoyé avec les identifiants d’accès au nœud.

CARTE / STRIPE

Paiement par carte bancaire

Visa, Mastercard et Amex sont acceptées. Les étapes de paiement traitent les informations nécessaires selon le parcours correspondant ; l’état de la commande est celui renvoyé par la console.

Gestion des incidents de sécurité

Avancez en cinq étapes fondées sur les preuves, sans tirer de conclusion absolue trop tôt

Une connexion anormale, une fuite d’identifiants, une modification de l’état de l’appareil ou un comportement suspect doivent d’abord faire l’objet d’une évaluation de l’impact. Les informations non vérifiées ne sont pas présentées comme des conclusions absolues de sécurité.

  1. 01

    Détection

    Notez l’heure de l’anomalie, l’identifiant de commande, la région, le comportement observé et les conditions minimales de reproduction ; conservez les journaux originaux désensibilisés.

  2. 02

    Limiter l’impact

    Selon le risque, révoquez les clés, fermez les sessions anormales, restreignez l’accès réseau ou suspendez l’automatisation concernée afin d’éviter d’élargir l’exposition.

  3. 03

    Enquête

    À partir d’une chronologie, vérifiez les journaux de connexion, les changements de configuration, les opérations utilisateur et l’état du service ; distinguez les problèmes d’identifiants, de charge de travail et de plateforme.

  4. 04

    Remédiation

    Remplacez les identifiants concernés, corrigez la configuration, supprimez les éléments persistants anormaux, puis vérifiez le résultat au moyen d’une nouvelle connexion ou d’une tâche de build.

  5. 05

    Notification

    Une fois les faits confirmés, fournissez les explications nécessaires, les mesures prises et les prochaines actions de l’utilisateur selon l’impact, sans diffuser d’hypothèses non vérifiées.

Divulgation responsable

Lorsque vous signalez une vulnérabilité, fournissez des preuves vérifiables et limitez la portée des tests

La recherche de sécurité et le signalement de problèmes doivent viser à réduire l’impact. N’élargissez pas la portée des accès, n’obtenez pas de données sans rapport et ne rendez pas public un problème qui n’est pas encore corrigé.

Un rapport exploitable pour l’enquête doit contenir

Élément impacté

Les pages du site, le parcours de commande, le mode de connexion ou la fonctionnalité de l’appareil concernés, ainsi que l’étendue de l’impact que vous pouvez confirmer.

Étapes de reproduction

Le chemin le plus court entre les conditions initiales et le résultat observé, avec l’ordre des requêtes nécessaires, les paramètres d’entrée et le comportement attendu.

Preuves et horaires

Fournissez des captures désensibilisées, les messages d’erreur, les heures concernées et une description de l’environnement, sans joindre de clé privée ni de données tierces.

Coordonnées

Indiquez une adresse e-mail, un fuseau horaire et des créneaux où vous pouvez répondre aux questions, afin de faciliter la vérification complémentaire.

Comportements interdits pendant les tests

  • Accéder à des données qui ne vous appartiennent pas, les télécharger, les modifier ou les supprimer
  • Obtenir les identifiants d’autres utilisateurs ou étendre les tests à des commandes sans rapport
  • Perturber le fonctionnement normal des nœuds, du réseau, des paiements ou de l’assistance
  • Obtenir des autorisations par tromperie, usurpation d’identité ou manipulation
  • Publier des détails exploitables avant la correction et la fin des échanges
Vérification rapide du périmètre

Questions fréquentes sur la sécurité

Les réponses ci-dessous servent à déterminer rapidement l’action suivante. Pour une commande précise, joignez son identifiant, la région, l’heure concernée et des journaux désensibilisés.

Un ordinateur physique dédié signifie-t-il qu’aucun contrôle des accès n’est nécessaire ?

Non. Un ordinateur physique dédié réduit le partage de ressources informatiques avec d’autres locataires, mais n’empêche ni les mots de passe faibles, ni la fuite de clés privées, ni les privilèges excessifs, ni les dépendances malveillantes, ni les erreurs de manipulation. Chaque opérateur doit utiliser une identité distincte et bénéficier uniquement des privilèges nécessaires à sa tâche.

Que faire en premier si une clé SSH ou des identifiants de connexion à distance semblent compromis ?

Commencez par limiter l’impact : révoquez la clé publique concernée ou remplacez les identifiants, fermez les sessions suspectes et cessez d’utiliser l’automatisation associée. Notez ensuite l’heure, la source, l’identifiant de commande et les mesures prises, puis envoyez les informations désensibilisées via un ticket dans la console.

Quels éléments doivent impérativement être supprimés des journaux envoyés ?

Supprimez impérativement les clés privées, mots de passe complets, jetons d’accès, textes des certificats, données métier et informations personnelles sans rapport. Conservez les commandes, codes d’erreur, chemins nécessaires, heures exactes et le contexte minimal permettant de comprendre le problème.

Quelle est l’action la plus importante concernant les données avant la fin de la commande ?

Migrez le code, les artefacts de build, les journaux et les configurations nécessaires vers un emplacement contrôlé par l’utilisateur, puis effectuez une vérification de lecture, de contrôle ou de restauration. Révoquez ensuite les clés, identifiants et certificats présents sur le nœud avant de clôturer les opérations liées à la commande.

Étape suivante

Confirmez d’abord le périmètre de sécurité, puis choisissez le Mac physique adapté à votre workflow

Découvrez deux configurations disponibles, les tarifs pour chaque durée et quatre régions proposées. Pour toute question concernant une commande existante, connectez-vous à la console et créez un ticket.

Voir les offres de location Accéder à la console