BerryVM fournit un nœud physique Mac mini dédié à un seul client pendant sa période de location, et non une machine virtuelle. Le modèle de sécurité repose sur l’isolation de l’appareil, le contrôle des accès, la traçabilité des opérations et un périmètre de données clairement défini.
BerryVM ne partage pas le processeur, la mémoire ou le stockage local d’un même appareil entre plusieurs clients. Une fois livré, l’appareil attribué est réservé à ce client pendant la location ; à son terme, l’accès est désactivé et le traitement de fin de service commence.
La puce, la mémoire et le stockage intégré appartiennent à l’ensemble du Mac mini attribué. Le service repose sur un appareil physique dédié, et non sur une machine virtuelle partagée ; les ressources ne sont pas décrites par un ratio de surallocation.
L’identifiant de l’appareil, le nœud et les informations d’accès sont remis avec la commande. Le client doit limiter l’accès aux personnes autorisées et renouveler immédiatement les identifiants en cas de changement de responsabilités, de départ d’un collaborateur ou de fuite suspectée.
Le personnel du support ne conserve pas un accès permanent à l’environnement client par défaut. En cas d’aide au diagnostic, le client doit préciser dans un ticket de console le périmètre, les opérations autorisées et la période concernée ; les journaux désensibilisés sont privilégiés.
Les informations d’accès servent uniquement à établir la première session sécurisée. Dès leur réception, vérifiez l’appareil et le nœud, puis mettez à jour les identifiants, limitez les sources d’accès et consignez les personnes autorisées.
Comparez l’identifiant de commande, la configuration de l’appareil, le nœud choisi et les informations d’accès reçues. En cas d’écart, interrompez la connexion et ouvrez un ticket via la console.
N’utilisez pas le mot de passe initial pour la collaboration quotidienne. Définissez des identifiants robustes selon la politique de l’équipe, privilégiez l’authentification par clé et stockez les informations de récupération en lieu sûr.
N’autorisez que les services distants et adresses sources nécessaires à la tâche, désactivez les fonctions de partage inutilisées et utilisez une autorisation distincte et révocable pour les runners d’automatisation.
Consignez les détenteurs des droits d’accès, les dates de rotation des identifiants, les pipelines utilisant l’appareil et la personne chargée de révoquer les accès lors des changements d’équipe.
Le diagnostic commence par défaut par l’état de l’appareil, le chemin réseau et les journaux désensibilisés. Une intervention n’a lieu que si le client l’autorise explicitement et qu’un diagnostic distant est nécessaire, dans le périmètre convenu du ticket.
Si des identifiants semblent compromis, arrêtez d’abord les tâches d’automatisation concernées, révoquez les accès associés et effectuez la rotation. Conservez l’identifiant de commande, le nœud, l’heure, l’adresse source et les journaux désensibilisés, puis ouvrez un ticket dans la console.
Ouvrir un ticket de sécuritéLes données des projets client se trouvent principalement sur l’appareil physique dédié attribué. Les informations de compte, commandes, paiements, échanges avec le support et journaux nécessaires sont traités selon leur finalité. La politique de confidentialité détaille les fondements de conservation et les droits des utilisateurs.
Nous traitons les coordonnées du compte, la configuration, la durée, le nœud et l’état du paiement pour confirmer la commande, attribuer l’appareil et remettre les informations d’accès. L’activation n’exige pas l’envoi du code source ni de données de production.
Pendant la location, le client gère les dépôts, caches de build, fichiers de modèles, clés et droits sur les artefacts présents sur l’appareil attribué. BerryVM ne traite que les enregistrements nécessaires au service, à la sécurité et au support.
Après confirmation du renouvellement, la période d’utilisation de l’appareil est prolongée selon la commande. L’équipe doit continuer à renouveler périodiquement les identifiants, supprimer les anciens accès et contrôler les clés utilisées par l’automatisation.
À la fin de la location, l’accès client est fermé et les données de l’appareil sont traitées selon le processus de service. Avant cette date, le client doit exporter les artefacts nécessaires, révoquer les jetons des systèmes externes et vérifier qu’aucune copie unique ne reste sur l’appareil.
La politique de confidentialité précise le traitement des données de compte, des commandes, des échanges avec le support, des journaux nécessaires et des données de l’appareil.
Les risques liés aux sessions distantes proviennent généralement des identifiants persistants, de sources trop ouvertes, de services inactifs et des accès partagés impossibles à retracer. Cette checklist constitue une bonne base d’initialisation après la remise de l’appareil.
Activez uniquement les services et ports distants nécessaires. Les fonctions de partage, de découverte et de test inutiles à l’environnement de développement doivent rester désactivées afin d’éviter de conserver une porte d’entrée durable.
Point de contrôle : services, ports, adresses d’écouteLes tâches d’automatisation et les membres de l’équipe doivent utiliser des moyens d’authentification révocables distincts. Ne partagez pas un même mot de passe permanent et n’inscrivez jamais une clé privée directement dans un dépôt, un script de build ou le corps d’un ticket.
Point de contrôle : propriétaire, stockage et révocation des clésLimitez les sources d’accès selon la sortie réseau de l’équipe, un bastion contrôlé ou le réseau de la tâche. Pour une collaboration entre régions, validez d’abord la politique de sources ; n’ouvrez pas toutes les adresses comme solution permanente.
Point de contrôle : périmètre des sources, exceptions, date d’expirationContrôlez régulièrement les membres, runners d’automatisation, services distants et jetons externes. Lorsqu’un membre quitte le projet, qu’un pipeline est désactivé ou que l’usage de l’appareil change, révoquez immédiatement les droits inutiles.
Point de contrôle : membres, tâches, jetons, anomalies| Élément contrôlé | Action recommandée | Déclencheur | Enregistrements à conserver |
|---|---|---|---|
| Accès des personnes | Vérifier les droits des membres et révoquer les accès expirés | Changement de rôle ou départ du projet | Autorisateur, heure de révocation, appareil concerné |
| Identifiants d’automatisation | Renouveler les clés et vérifier la reprise du pipeline | Rotation planifiée ou fuite suspectée | Identifiant de clé, heure de rotation, résultat de la vérification |
| Services distants | Désactiver les services inactifs et réduire le périmètre des sources | Fin de la tâche ou changement de politique réseau | Port, règle source, responsable du changement |
| Autorisation du support | Fermer l’accès temporaire et mettre à jour les identifiants concernés | Fin du diagnostic du ticket | Identifiant du ticket, périmètre autorisé, résultat de la fermeture |
Le traitement des incidents de sécurité repose sur les faits et la chronologie. Il n’est pas nécessaire d’envoyer des mots de passe d’accès ; l’identifiant de commande, le nœud, l’heure, le périmètre d’impact, les étapes de reproduction et les journaux désensibilisés permettent généralement d’accélérer l’analyse.
Fournissez l’identifiant de commande, le nœud, l’heure de première détection, les tâches affectées et les mesures déjà prises. Désensibilisez les clés, jetons, données client et informations d’identité avant de joindre les journaux.
Vérifiez si l’incident est toujours en cours, s’il touche un appareil ou une dépendance externe, et s’il faut révoquer immédiatement des identifiants, arrêter un pipeline ou limiter les sources réseau.
Selon les faits établis, fermez les points d’entrée concernés, révoquez les autorisations associées ou suspendez les tâches. Les mesures d’isolement doivent être traçables ; ne supprimez pas les journaux essentiels avant d’avoir conservé les preuves.
Après la rotation des identifiants, la correction des règles de source, la mise à jour des dépendances ou le retour à une configuration précédente, utilisez une tâche de vérification minimale pour confirmer le rétablissement de la connexion, du build et du chemin des artefacts.
Documentez la chronologie, la cause racine, l’impact et les actions de suivi, puis définissez les nouveaux contrôles de surveillance, de retrait des droits, de rotation ou les procédures d’équipe nécessaires.
Lorsque le traitement implique le service, communiquez par un canal de support traçable les résultats confirmés, l’avancement et les actions attendues du client. Ne remplacez pas les conclusions par des hypothèses non vérifiées.
BerryVM vise une disponibilité de service de 99,9 %. Tous les nœuds fonctionnent normalement 365 jours par an. Les statistiques, exclusions, délais de demande et éventuelles compensations applicables sont définis dans les conditions de service.
Pour vérifier une panne survenue pendant l’exploitation, indiquez l’identifiant de commande, le nœud, l’heure, la durée et l’impact. Les enregistrements du service et les journaux client doivent utiliser le même fuseau horaire ou préciser clairement celui utilisé.
Les signalements de vulnérabilité, questions de sécurité ou anomalies en production peuvent être envoyés via un ticket de console ou à support@berryvm.com. Indiquez l’identifiant de commande, le nœud, la chronologie, l’impact et des journaux désensibilisés ; n’envoyez ni identifiants d’accès, ni clés privées, ni données de projet non désensibilisées.