Sécurité des écrans
de salle sur iPad

Réponse courte : les quatre choses à vérifier avant d'approuver toute app d'écran de salle : (1) identifiants stockés dans un stockage matériel (Keychain iOS), (2) autorisations d'agenda limitées au nécessaire, (3) si les données transitent par les serveurs de l'éditeur ou vont directement de l'appareil à l'API, et (4) verrouillage physique (mode kiosque + support verrouillable). Réussissez ces quatre points et un iPad de couloir devient un appareil à faible risque.

Un iPad mural qui lit les agendas de l'entreprise est exactement le type de petit achat qui atterrit sur le bureau de la DSI pour une validation de sécurité. Voici la vraie revue, dans l'ordre qui compte.

1. Où vivent les identifiants ?

L'identifiant (jeton OAuth ou clé de compte de service) doit être stocké dans le Keychain iOS — adossé au matériel, chiffré au repos, inaccessible aux autres apps. The Room Display stocke les identifiants ainsi. Signaux d'alerte dans toute app : identifiants dans des fichiers en clair, dans les préférences de l'app, ou synchronisés vers un cloud éditeur.

2. OAuth 2.0 vs compte de service — lequel utiliser ?

OAuth 2.0 (recommandé par défaut) : l'écran s'authentifie comme un compte utilisateur dédié que vous créez (p. ex. salles@votreentreprise.com). L'accès est visible dans votre console d'administration, révocable en un clic et auditable comme tout utilisateur. Ne donnez à ce compte l'accès qu'aux ressources de salle.

Compte de service avec délégation à l'échelle du domaine (Google) / enregistrement d'application (Microsoft) : mieux pour les déploiements de flotte — pas de connexion interactive par iPad, gestion centralisée des clés. La discipline requise : restreignez étroitement la délégation. La délégation à l'échelle du domaine accorde les autorisations que vous autorisez, alors n'autorisez que les autorisations d'agenda, jamais des autorisations d'administration larges.

Dans les deux cas, le principe est identique : l'écran reçoit sa propre identité, jamais la connexion d'un véritable employé.

3. Minimisation des autorisations

Un écran de salle doit : lire les agendas de salle, y créer des événements et lister les ressources de salle. Concrètement, cela signifie des autorisations de lecture/écriture d'agenda plus la lecture de l'annuaire de ressources. Il n'a pas besoin : d'autorisations de messagerie, de Drive/SharePoint, d'écriture de l'annuaire d'utilisateurs ou d'autorisations d'administration. Si une app demande plus que les autorisations agenda + ressources, demandez pourquoi avant d'approuver.

4. Par où circulent les données ?

La question d'architecture que les éditeurs espèrent que vous ne poserez pas : les données d'agenda passent-elles par les serveurs de l'éditeur ? Beaucoup de plateformes synchronisent votre agenda dans leur cloud (c'est ainsi que fonctionnent leurs tableaux de bord). The Room Display dialogue directement depuis l'iPad avec les API Google/Microsoft — les données de réunion ne touchent jamais notre infrastructure, parce que nous n'en avons aucune dans le chemin des données. Pour une revue de confidentialité, voici la version courte : il n'y a aucun tiers à évaluer.

5. Checklist de sécurité physique

• Boîtier verrouillable — l'iPad ne doit pas repartir avec un visiteur
• Accès guidé ou Mode application unique — pas d'évasion vers Réglages ou Safari (notre guide kiosque)
• Les titres de réunion sur l'écran : définissez une politique. Afficher « Occupé jusqu'à 15h00 » plutôt que « Discussion M&A avec Acme » est un choix de confidentialité à un seul interrupteur, à faire consciemment pour les couloirs visibles par les clients
• Wi-Fi/VLAN dédié si votre politique réseau segmente les appareils de classe IoT — l'écran n'a besoin que d'une sortie HTTPS vers Google/Microsoft

FAQ

Un iPad d'écran volé peut-il fuiter des données ? Il détient un identifiant stocké dans le Keychain, limité aux agendas de salle. Révoquez le compte/la clé dans votre console d'administration et l'appareil devient inerte. Avec Localiser + Verrouillage d'activation actifs, c'est aussi un presse-papiers.

L'app a-t-elle besoin du MDM ? Non, mais le MDM rend les flottes plus agréables — voir notre guide ABM/MDM.

Prise en charge du SSO ? Le flux OAuth utilise votre connexion Google/Microsoft habituelle — les politiques SSO et d'accès conditionnel existantes s'appliquent au compte des salles comme à tout utilisateur.

Cet article est rédigé pour être transféré tel quel au responsable de la revue de sécurité — il devrait répondre à ses six premières questions avant la réunion.