Confidentialité, autorisations et sécurité pour les compléments Outlook

Les utilisateurs finaux, les développeurs et les administrateurs peuvent appliquer les niveaux d’autorisation hiérarchisés du modèle de sécurité pour les compléments Outlook afin de contrôler les performances et la confidentialité.

Cet article décrit les autorisations que les compléments Outlook peuvent demander, et examine le modèle de sécurité selon les perspectives suivantes.

• AppSource : intégrité de complément

• Utilisateurs : problèmes de confidentialité et de performance

• Développeurs : choix d’autorisations et limites d’utilisation des ressources

• Administrateurs: privilèges pour définir des seuils de performances

Modèle d’autorisations

Comme la façon dont les clients perçoivent la sécurité des compléments peut avoir une incidence sur l’adoption de ces derniers, la sécurité des compléments Outlook repose sur un modèle d’autorisations à plusieurs niveaux. Un complément Outlook indique le niveau d’autorisations dont il a besoin, identifiant ainsi l’accès dont il peut disposer et les actions qu’il peut effectuer sur les données de la boîte aux lettres du client.

Il existe quatre niveaux d’autorisations possibles.

Les autorisations sont déclarées dans le manifeste. Le balisage varie en fonction du type de manifeste.

• Manifeste de complément uniquement : utilisez l’élément <Permissions> .
• Manifeste unifié pour Microsoft 365 : utilisez la propriété « name » d’un objet dans le tableau « authorization.permissions.resourceSpecific ».

Les quatre niveaux d’autorisations sont cumulatifs : l’autorisation boîte aux lettres en lecture/écriture inclut les autorisations de élément en lecture/écriture, lire élément et restreint, l’autorisation élément en lecture/écriture inclut lire élément et restreintet l’autorisation lire élément inclut restreint.

L’illustration suivante affiche les quatre niveaux d’autorisations et décrit les fonctionnalités proposées aux utilisateurs finaux, développeur et administrateur par chaque niveau. Pour plus d’informations sur ces autorisations, voir utilisateurs : problèmes de performances et de confidentialité, développeurs : choix d’autorisation et les limites de l’utilisation de ressources, et comprendre les autorisations de complément Outlook.

AppSource : intégrité de complément

AppSource héberge des compléments pouvant être installés par les utilisateurs finals et les administrateurs. AppSource applique les mesures suivantes pour maintenir l’intégrité de ces compléments Outlook.

• Oblige le serveur hôte d’un complément à toujours utiliser SSL (Secure Socket Layer) pour communiquer.

• Oblige un développeur à fournir une preuve d’identité, un accord contractuel et une politique de confidentialité conforme pour soumettre les compléments.

• Archive les compléments en mode lecture seule.

• Prend en charge un système d’évaluation par les utilisateurs pour les compléments disponibles afin de promouvoir une communauté exerçant une auto surveillance.

Expériences connectées facultatives

Les utilisateurs finaux et les administrateurs informatiques peuvent désactiver expériences connectées facultatives dans les clients de bureau et mobiles Office. Pour les compléments Outlook, l’impact de la désactivation du paramètre Expériences connectées facultatives dépend du client, mais cela signifie généralement que les compléments installés par l’utilisateur et l’accès à AppSource ne sont pas autorisés. Certains compléments Microsoft sont considérés comme essentiels ou stratégiques, et les compléments déployés par l’administrateur informatique d’une organisation via Déploiement centralisé restent disponibles.

Pour obtenir des informations générales sur le comportement des compléments, consultez Confidentialité et sécurité pour les compléments Office.

Utilisateurs : problèmes de confidentialité et de performance

Le modèle de sécurité résout les problèmes de sécurité, de confidentialité et de performance des utilisateurs des manières suivantes.

• Les messages de l’utilisateur final protégés par la gestion des droits relatifs à l’information (IRM) d’Outlook n’interagissent pas avec les compléments dans les instances suivantes.

  • Lorsque le message protégé par IRM est accessible à partir d’Outlook sur des appareils mobiles.

  • Lorsque le message protégé par IRM contient une étiquette de confidentialité avec l’option de stratégie personnalisée Autoriser l’accès par programmation définie sur false.

  Pour plus d’informations sur la prise en charge de la gestion des droits relatifs à l’information dans les compléments, consultez Éléments de messagerie protégés par IRM.

• Avant d’installer un complément d’AppSource, les utilisateurs finals peuvent voir l’accès dont peut disposer le complément, ainsi que les actions qu’il peut effectuer sur leurs données, et doivent explicitement confirmer qu’ils veulent poursuivre. Aucun complément Outlook n’est automatiquement transmis sur un ordinateur client sans une validation manuelle par l’utilisateur ou l’administrateur.

• L’octroi de l’autorisation Restreint permet au complément Outlook d’avoir un accès limité uniquement sur l’élément actuel. L’octroi de l’autorisation d’élément en lecture permet au complément Outlook d’accéder aux informations d’identification personnelles, telles que les noms de l’expéditeur et des destinataires et les adresses e-mail, uniquement sur l’élément actif.

• Un utilisateur final peut installer un complément Outlook uniquement pour lui-même. Les compléments de messagerie ayant une incidence sur l’organisation sont installés par un administrateur.

• Les utilisateurs peuvent installer des compléments Outlook qui activent des scénarios contextuels prisés par les utilisateurs tout en minimisant les risques de sécurité pour ces derniers.

• Les fichiers manifeste de compléments Outlook installés sont sécurisés dans le compte de messagerie de l’utilisateur.

• Les données échangées avec des serveurs hébergeant des Compléments Office sont toujours chiffrées conformément au protocole SSL (Secure Socket Layer).

• Outlook sur Windows (classique) et sur Mac surveillent les performances des compléments Outlook installés, exercent un contrôle de gouvernance et rendent les compléments indisponibles lorsqu’ils dépassent les limites dans les domaines suivants.

  • Temps de réponse d’activation

  • Nombre de défaillances d’activation ou de réactivation

  • Utilisation de la mémoire

  • Utilisation du processeur

  La gouvernance dissuade les attaques par déni de service et maintient les performances des compléments à un niveau raisonnable. Le Volet Entreprise alerte les utilisateurs finaux sur les compléments qu’Outlook sur Windows (classique) et sur Mac ont rendus indisponibles en fonction de ce contrôle de gouvernance.

• À tout moment, les utilisateurs finaux peuvent vérifier les autorisations demandées par les compléments Outlook installés et rendre tout complément disponible ou indisponible dans le Centre d’administration Exchange.

Développeurs : choix d’autorisations et limites d’utilisation des ressources.

Le modèle de sécurité fournit aux développeurs des niveaux précis d’autorisations à choisir, et de strictes directives de performance à observer.

Les autorisations à plusieurs niveaux augmentent la transparence

Les développeurs doivent suivre le modèle d’autorisations à plusieurs niveaux pour assurer la transparence et apaiser les inquiétudes des utilisateurs concernant ce que les compléments peuvent faire à leurs données et leur boîte aux lettres, en faisant la promotion indirecte de l’adoption du complément.

• Les développeurs demandent un niveau approprié d’autorisation pour un complément Outlook en fonction de la manière dont il doit être activé, et de son besoin de lire ou d’écrire certaines propriétés d’un élément, ou de créer et d’envoyer un élément.

• Comme indiqué ci-dessus, les développeurs demandent l’autorisation dans le manifeste.

  L’exemple suivant demande l’autorisation d’élément en lecture dans le manifeste du complément uniquement.

  <Permissions>ReadItem</Permissions>
  

  L’exemple suivant demande l’autorisation d’élément de lecture dans le manifeste unifié pour Microsoft 365.

  "authorization": {
    "permissions": {
      "resourceSpecific": [
        ...
        {
          "name": "MailboxItem.Read.User",
          "type": "Delegated"
        },
      ]
    }
  },
  

• Les développeurs peuvent demander l’autorisation restreinte si le complément Outlook s’active sur un type spécifique d’élément Outlook (rendez-vous ou message).

• Les développeurs doivent demander l’autorisation d’élément de lecture si le complément Outlook doit :

  • Lit les propriétés de l’élément actif.
  • Écrire des propriétés personnalisées définies par le complément sur l’élément actif, mais ne nécessite pas de lecture ou d’écriture dans d’autres éléments.
  • Créez ou envoyez un message dans la boîte aux lettres de l’utilisateur.

• Les développeurs doivent demander l’autorisation Lire/écrire dans l’élément si le complément Outlook doit écrire dans les propriétés de l’élément composé, comme les noms des destinataires, les adresses de messagerie, le corps et l’objet, ou s’il a besoin d’ajouter ou de supprimer des pièces jointes d’élément.

• Les développeurs demandent l’autorisation Lire/écrire dans la boîte aux lettres uniquement si le complément Outlook doit effectuer une ou plusieurs des actions suivantes à l’aide de la méthode mailbox.makeEWSRequestAsync.

  • Lire ou écrire des propriétés d’éléments dans la boîte aux lettres.
  • Créer, lire, écrire ou envoyer des éléments dans la boîte aux lettres.
  • Créer, lire ou écrire dans des dossiers de la boîte aux lettres.

Réglage de l’utilisation des ressources

Les développeurs doivent connaître les limites de l’utilisation des ressources pour l’activation, incorporer le réglage des performances dans leur flux de travail de développement, afin de réduire le risque d’un complément peu performant refusant le service de l’hôte. Les développeurs doivent suivre les instructions de conception de règles d’activation décrites dans Limites d’activation et API JavaScript pour les compléments Outlook. Si un complément Outlook est destiné à s’exécuter dans Outlook sur Windows (classique) ou sur Mac, les développeurs doivent vérifier que le complément fonctionne dans les limites d’utilisation des ressources.

Autres mesures visant à promouvoir la sécurité de l’utilisateur

Les développeurs doivent connaître et planifier les éléments suivants.

• Les développeurs ne peuvent pas utiliser les contrôles ActiveX dans les compléments, car ils ne sont pas pris en charge.

• Les développeurs doivent procéder comme suit lorsqu’ils envoient un complément Outlook à AppSource.

  • Produire un certificat SSL EV (Extended Validation) comme preuve d’identité.

  • Héberger le complément qu’ils soumettent sur un serveur web qui prend en charge SSL.

  • Produire une stratégie de confidentialité conforme.

  • Être prêts à signer un accord contractuel lors de la soumission du complément.

Administrateurs : privilèges

Le modèle de sécurité fournit les droits et les responsabilités suivants aux administrateurs.

• Peut empêcher les utilisateurs d’installer un complément Outlook, notamment les compléments sur AppSource.

• Peut rendre n’importe quel complément Outlook disponible ou indisponible via le Centre d’administration Exchange.

• Applicable uniquement à Outlook classique sur Windows : peut remplacer les paramètres de seuil de performances par les paramètres du Registre des objets de stratégie de groupe.

Voir aussi

• Confidentialité et sécurité pour les compléments Office
• Contrôles de confidentialité pour Microsoft 365 Apps
• API de complément Outlook
• Limites pour l’activation et l’API JavaScript pour les compléments Outlook