Identifiants uniques
Chaque commande utilise des informations de connexion distinctes. Ne réutilisez pas les mêmes éléments d’accès entre équipes, projets ou nœuds.
AC-01 · UNIQUE
Nœuds dédiés et responsabilités
Un Mac physique dédié par commande
Les locataires ne partagent ni instance du système, ni mémoire, ni disque local. ArmCLI assure la mise à disposition du nœud physique, la connexion de base et le suivi d’état côté plateforme ; l’utilisateur gère son code, ses clés, ses accès, ses données et le nettoyage avant restitution.
- 1:1
- Commande associée à un nœud physique
- 99,9 %
- Objectif de disponibilité
- 365 jours
- Nœuds opérationnels toute l’année
Registre de sécurité
AC-NODE-01
Isolation vérifiée
Nœud physique dédié, sans partage d’instance système
- Attribution du nœud
- Une seule commande active
- Authentification
- Identifiants uniques et clés privilégiés
- Suivi d’état
- Mise à disposition, sessions et événements de ressources
- Fin de location
- Accès désactivé, puis passage au processus de récupération
- Nouvelle mise à disposition
- Traitement des données et vérification de l’état terminés
L’état réel du nœud, son attribution et sa disponibilité sont ceux renvoyés en temps réel par la console.
Contrôle des accès
Ramenez chaque connexion à un accès identifiable et révocable
La sécurité ne repose pas sur un simple bouton. Identifiants, clés, autorisations, sessions et traitement des anomalies doivent former une boucle complète pour limiter les risques liés aux mots de passe partagés, aux autorisations persistantes et aux sessions oubliées.
Priorité aux clés
Pour les tâches automatisées SSH, privilégiez des clés révocables individuellement. Conservez la clé privée sur un appareil contrôlé, jamais dans un dépôt, des journaux de build ou un document partagé.
AC-02 · KEY FIRSTMoindre privilège
N’accordez que les accès aux répertoires, commandes et services nécessaires à la tâche. Utilisez des identités et répertoires de travail distincts pour le runner CI, le développement interactif et les scripts d’exploitation.
AC-03 · LEASTFermeture de session
Après une tâche graphique ou en ligne de commande, fermez activement la session, supprimez les redirections temporaires et effacez les traces de connexion locales sur les appareils partagés.
AC-04 · SIGN OUTRotation des identifiants
Après le départ d’un membre, la perte d’un appareil, une évolution de l’automatisation ou un accès suspect, révoquez immédiatement les anciennes clés et émettez de nouveaux éléments de connexion.
AC-05 · ROTATETraitement des accès suspects
En cas de source inconnue, de commande inhabituelle ou de session inattendue, déconnectez-vous, révoquez les identifiants, conservez une chronologie anonymisée, puis ouvrez un ticket dans la console.
AC-06 · CONTAIN
Cycle de vie du nœud
De la préparation à la récupération, chaque étape a un état précis
Un nœud physique n’est jamais partagé entre deux commandes actives. Les changements d’état reposent sur la commande, l’identifiant du nœud et les traces de traitement ; les accès et les données sont revérifiés avant toute nouvelle mise à disposition.
-
01
Préparation
Vérification du modèle, de la mémoire, du stockage, du centre de données cible et de la connexion de base, puis validation de l’entrée du nœud dans le processus automatisé de préparation.
-
02
Mise à disposition
Établissement de l’attribution individuelle entre la commande et le nœud physique, émission des informations de connexion et validation par l’utilisateur de l’empreinte hôte, des versions d’outils et de la capacité disque.
-
03
Suivi pendant la location
Suivi de l’état en ligne du nœud, de la connexion de base et des événements de ressources, sans lecture du contenu du code utilisateur. L’utilisateur gère ses autorisations de projet, ses clés et ses données métier.
-
04
Récupération à l’échéance
À la fin de la location, l’accès à la commande est désactivé et le processus de récupération commence. Effectuez vos sauvegardes, votre migration et le nettoyage des fichiers sensibles avant l’échéance.
-
05
Traitement avant nouvelle mise à disposition
Traitement des données, invalidation des identifiants et vérification de l’état du nœud ; celui-ci ne peut être attribué à nouveau qu’après la fin des contrôles.
Définition de la disponibilité
99,9 % Objectif vérifié par les relevés de service
La disponibilité est calculée à partir de l’état du nœud, des relevés de connexion de base et des incidents confirmés. Le réseau local, les actions et la configuration logicielle de l’utilisateur, les dépendances tierces et la force majeure ne sont pas comptabilisés dans le temps de disponibilité de la plateforme.
Tous les nœuds fonctionnent 365 jours par an. En cas d’incident imprévu, les relevés d’état sont mis à jour dans l’ordre suivant : détection, confirmation, atténuation, rétablissement et analyse.
Voir la définition des conditions de service
Relevés des 90 derniers jours
99,9 %
Objectif
Période normale
Marqueurs d’incidents confirmés
Marqueurs sur la période : 0
- Unité statistique
- Nœud associé à la commande
- Source des éléments probants
- Relevés d’état et de connexion
- Indemnisation
- Selon les conditions de service et le résultat de l’examen
Latence mesurée dans cinq régions
Examinez le trajet réseau avant de choisir le centre de données
Le tableau présente la médiane du temps aller-retour ICMP entre les points de test et les nœuds de Singapour, du Japon (Tokyo), de Corée du Sud (Séoul), de Hong Kong et de la côte Est des États-Unis. Ces valeurs servent à comparer les trajets ; elles ne représentent ni la vitesse de build ni la fréquence d’affichage d’un bureau distant.
Date du test20 septembre 2026
Fournisseur réseauInternet public, deux sorties locales haut débit fixe
Nombre d’échantillons20 mesures par trajet
Méthode statistiqueMédiane du RTT ICMP, en ms
| Origine du test | Singapour | Japon (Tokyo) | Corée du Sud (Séoul) | Hong Kong | Côte Est des États-Unis |
|---|---|---|---|---|---|
| Shanghai | 73 ms | 49 ms | 45 ms | 36 ms | 188 ms |
| Taipei | 61 ms | 38 ms | 52 ms | 24 ms | 176 ms |
| Bangkok | 31 ms | 96 ms | 101 ms | 54 ms | 229 ms |
| Sydney | 92 ms | 118 ms | 132 ms | 126 ms | 241 ms |
| Francfort | 162 ms | 231 ms | 224 ms | 198 ms | 94 ms |
Les résultats peuvent varier selon l’opérateur, les routes internationales, le réseau sans fil, la congestion et l’appareil local. Avant de commander, testez le centre de données cible depuis les principaux lieux d’accès de l’équipe ; la disponibilité réelle est celle renvoyée en temps réel par la console.
Périmètre de l’infrastructure
Cinq centres de données couvrent les principaux trajets asiatiques et la côte Est des États-Unis
Les trois modèles disponibles peuvent être déployés dans les cinq centres suivants. Tenez compte de l’emplacement de l’équipe, du trajet vers le dépôt de code, de la source des dépendances et de la région de livraison finale.
SG
Catalogue disponible
Singapour
Convient aux équipes d’Asie du Sud-Est et aux tâches de build, de test et d’automatisation nécessitant une connexion aux services régionaux.
- À vérifier
- Route internationale et durée de récupération du dépôt
- Modèles au catalogue
- 3 configurations
JP
Catalogue disponible
Japon (Tokyo)
Convient aux accès depuis le Japon et l’Asie du Nord-Est, notamment pour le développement interactif, les builds Xcode et les runners auto-hébergés.
- À vérifier
- Stabilité de la latence de l’équipe vers Tokyo
- Modèles au catalogue
- 3 configurations
KR
Catalogue disponible
Corée du Sud (Séoul)
Convient aux réseaux coréens et voisins, avec une option régionale pour les sessions en ligne de commande et l’intégration continue.
- À vérifier
- Routage international de l’opérateur local
- Modèles au catalogue
- 3 configurations
HK
Catalogue disponible
Hong Kong
Convient aux équipes recherchant un trajet réseau asiatique court, pour le développement distant, la signature et l’exécution de pipelines.
- À vérifier
- Variations du trajet aux heures de pointe
- Modèles au catalogue
- 3 configurations
US-E
Catalogue disponible
Côte Est des États-Unis
Convient aux équipes de la côte Est nord-américaine ou aux charges dont les dépôts de code, artefacts et services d’automatisation se trouvent principalement en Amérique du Nord.
- À vérifier
- Dépendances intercontinentales et transfert d’artefacts
- Modèles au catalogue
- 3 configurations
La latence ne dépend pas d’un seul centre de données
L’expérience réelle dépend aussi du réseau local, du routage de l’opérateur, du VPN, de l’environnement sans fil et du protocole utilisé. Pour les interfaces graphiques, privilégiez un trajet stable et peu latent ; pour les builds en volume, comparez aussi l’emplacement du dépôt et du stockage d’artefacts.
Communication en cas d’incident
Cinq étapes pour rendre compte d’un incident, sans statut vague
ArmCLI ne prévoit pas d’interruption récurrente. Le processus suivant s’applique aux anomalies imprévues de connexion, de nœud ou de plateforme ; chaque mise à jour précise le périmètre connu, l’action suivante et les points à confirmer.
-
01
Détection
Consignez l’heure de la première anomalie, le nœud touché et le phénomène reproductible, en distinguant les signaux du réseau local de l’utilisateur de ceux du nœud.
-
02
Confirmation
Vérifiez les relevés d’état, la connexion de base et le comportement des nœuds voisins. Indiquez le périmètre confirmé sans présenter une hypothèse comme une conclusion.
-
03
Atténuation
Rétablissez en priorité une connexion utilisable ou limitez la propagation de l’impact, en notant les mesures temporaires, leur périmètre et les risques restants.
-
04
Rétablissement
Vérifiez la connexion du nœud, l’attribution de la commande et les chemins critiques. Continuez à surveiller après le rétablissement ; un seul test réussi ne suffit pas à clore l’incident.
-
05
Analyse
Rassemblez la chronologie, le périmètre, les conditions de déclenchement et les améliorations à apporter. En cas de disponibilité ou d’indemnisation, appliquez les conditions de service et le résultat de l’examen.
Signalement de sécurité
Envoyez des éléments reproductibles et anonymisés
Si vous découvrez un problème de sécurité potentiel, arrêtez d’abord les tests susceptibles d’en aggraver l’impact. Ne publiez jamais d’identifiants valides, de clés privées, de jetons d’accès, d’informations complètes sur l’hôte ni de journaux non anonymisés.
Le rapport doit au moins contenir
- 01
Conditions de reproductionIndiquez le point d’entrée, l’état préalable, les étapes à suivre et le résultat attendu.
- 02
Périmètre de l’impactPrécisez s’il concerne un seul nœud, le processus de commande, la couche de connexion ou une page publique.
- 03
Temps et environnementIndiquez le fuseau horaire, l’heure de survenue, l’environnement réseau et la version du client.
- 04
Éléments anonymisésJoignez un résumé de l’erreur, les captures ou extraits de journaux nécessaires, en masquant tous les identifiants valides.
Les demandes générales sont traitées dans l’ordre de réception. En cas de risque persistant, indiquez « problème de sécurité » dans l’objet et conservez une copie contrôlée des éléments originaux.
Après vérification des limites de sécurité, choisissez le nœud physique adapté
Les trois formules de Mac physiques dédiés couvrent Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong et la côte Est des États-Unis. La configuration, le nœud et la disponibilité réelle sont ceux renvoyés en temps réel par la console.