Dans cette partie nous allons aborder la gestion des groupes de notification. Cette notion se décline naturellement techniquement sur les groupes d'utilisateurs PRTG. Que votre configuration repose sur des groupes AD ou non, la manière de paramétrer les utilisateurs et les groupes est identique. Dans le cas de l'AD, la seule étape préalable est bien sûr la création ou l'affectation de l'utilisateur à un groupe lui même mappé dans PRTG. Il est important de noter qu'il n'est pas possible de mixer utilisateurs AD et groupes internes ou inversement.


A noter: les utilisateurs AD n’apparaîtront dans leur groupe sous PRTG que lorsqu'ils se seront connectés une première fois à la plate-forme.


Partons de l'hypothèse suivante: nous souhaitons déléguer à un groupe d'utilisateurs la capacité d’auto-gérer ses notifications sur leur domaine de compétence. On peut imaginer par exemple vouloir déléguer aux responsables d'applications la capacité de définir eux mêmes la vision qu'ils souhaitent avoir des équipements qui les intéressent ainsi que les notifications associées.

Il n'est pas envisageable de s'appuyer sur le device tree pour cela. En effet, la hiérarchie des objets n'est pas nécessairement optimisée pour leur permettre de rassembler dans un groupe tous les équipements qui les intéressent. Il y a même très peu de chance pour que ce soit le cas. De plus, certains équipements peuvent être utiles à plusieurs groupes.Il faut donc utiliser les libraries. Ils peuvent ainsi regrouper les équipements et/ou capteurs qui les concernent particulièrement et définir leurs propres notifications indépendamment de celles définies dans le device tree et de la librairie d'autres utilisateurs.


Les étapes:

  1. Créer l'utilisateur/groupe spécifique
  2. Créer la library
  3. Affecter les droits nécessaires dans le device tree
  4. Créer les notifications spécifiques


Créer l'utilisateur/groupe spécifique
Des droits minimums peuvent suffire à rendre autonome les utilisateurs dans le contexte que nous abordons.


Il est essentiel que le groupe donne aux nouveaux utilisateurs les droits de lecture/écriture sinon il ne seront pas en mesure de modifier leur librairie.



Créer la library

Cette étape est la plus simple. Il est essentiel de donner à minima le droit en écriture au groupe d'utilisateur concerné. Si on veut aller plus loin, il est possible de leur déléguer l'accès complet. Les utilisateurs deviennent alors autonome pour gérer aussi les droits d'accès à leur library et ainsi ouvrir en lecture à d'autre groupe leur supervision. Attention cependant, ils ont aussi la capacité de faire des bêtises et de se retirer à eux-mêmes les droits d'accès à leur libraries !





Affecter les droits nécessaires dans le device tree
Cette étape peut être la plus fastidieuse. En effet, il est nécessaire de donner à minima les droits en lecture sur le ou les équipements intéressants notre groupe d'utilisateur. Pour des raisons de maintenabilité, il est souhaitable de positionner ces droits suffisamment haut dans la hiérarchie afin que l'autorisation soit automatiquement héritée et que l'on ait pas à gérer les droits équipements par équipements. Ceci étant dit, il faut se poser la question de l'impact du fait qu'un utilisateur puisse lire ou non l'état de n'importe quel capteur de la plate-forme. Sauf dans certains domaines ou activités réglementés, ce choix relève de votre politique de sécurité interne.




Créer les notifications spécifiques

En restreignant les droits au strict minimum, l'utilisateur n'aura que la possibilité d'utiliser la notification par email qui est généré à la création de son groupe. Il est donc nécessaire de définir avec lui et de créer les différents types de notification qui lui seront nécessaires. Il pourra ainsi les sélectionner lorsqu'il créera ses propres notifications.


Dans l'esprit de ce que nous avons développé en Part 1, il faut être attentif à bien positionner des plages horaires dans les notifications et de sensibiliser les utilisateurs au problème de flooding.