Détection de jailbreak

Détection de jailbreak : Équivalent iOS de la détection de root, employé par les applications bancaires pour restreindre les fonctions sensibles.

Entrée de la famille « Sécurité » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.

À quoi sert Détection de jailbreak

Sur un projet d’application, Détection de jailbreak se traite pendant la conception. Ajouter la sécurité à la fin revient à réécrire des parties déjà recettées, donc à les recetter de nouveau.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

La traduction en exigences

Le cahier des charges doit prévoir qui teste « Détection de jailbreak » et à quel moment. Une revue de sécurité programmée après la mise en ligne arrive trop tard pour changer quoi que ce soit.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les modalités d’authentification, second facteur compris s’il est requis.
• Le stockage des secrets, côté application comme côté serveur.
• La gestion des accès de production, et leur revue périodique.
• Le test de restauration des sauvegardes, réellement exécuté au moins une fois.

Le niveau de détail à viser est celui qui permet à deux prestataires différents de chiffrer la même chose. En dessous, les écarts de prix ne veulent rien dire.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Comment le vérifier à la recette

Détection de jailbreak se recette avant la mise en ligne, puis se revérifie après les corrections. Un correctif non retesté n’est pas un correctif.

• Passer en revue la liste des personnes ayant accès à la production.
• S’assurer que les journaux ne contiennent aucune donnée personnelle.
• Réclamer la preuve d’un test de restauration de sauvegarde.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Les pièges à éviter

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• Faire confiance aux contrôles réalisés dans l’application sans les refaire côté serveur.
• Journaliser des données sensibles pour faciliter le débogage, puis oublier de retirer les traces.
• Protéger l’application et négliger les interfaces qu’elle appelle.
• Considérer qu’une application sans données bancaires n’intéresse aucun attaquant.
• Repousser l’arbitrage au sprint suivant, autant de fois qu’il y a de sprints.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Plan de réponse
• Confidentialité
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe

Questions fréquentes

Que signifie « Détection de jailbreak » ?

Équivalent iOS de la détection de root, employé par les applications bancaires pour restreindre les fonctions sensibles. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

À quel moment traiter le sujet ?

Dès la conception, puis en contrôle avant la mise en ligne. Une faille corrigée sur plan coûte une discussion ; la même faille corrigée après le lancement coûte un correctif, une republication et parfois une notification.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.