Créer des politiques cohérentes est un jeu d'enfant avec NinjaOne, ce qui vous permet de gérer vos terminaux facilement et efficacement. Dans ce guide, nous aborderons les concepts clés des politiques à l'aide d'exemples concrets illustrant leur fonctionnement au sein de la console NinjaOne.
Table des matières :
- À propos de la fonctionnalité de politiques de NinjaOne
- Héritage des politiques
- Hiérarchies de politiques
- Remplacements au niveau des appareils
- Stratégies de gestion des politiques
- Documentation associée
À propos de la fonctionnalité de politiques de NinjaOne :
Que sont les politiques dans NinjaOne ?
Les politiques constituent le moteur centralisé de gestion et d'automatisation des appareils de NinjaOne. Les politiques que vous définissez déterminent la manière dont NinjaOne gère vos appareils.
Que contient une politique ?
Grâce aux politiques, vous indiquez à NinjaOne comment vous souhaitez que vos terminaux soient gérés au quotidien. NinjaOne exécute automatiquement et en continu les actions définies par les politiques sur tous les appareils concernés.
Les politiques comprennent des règles de surveillance des terminaux, des règles d'automatisation, des options de gestion granulaire des correctifs, des préférences en matière de solutions de sécurité, ainsi que la sauvegarde et la conservation des données.
En quoi NinjaOne gère-t-il les politiques différemment ?
Avec NinjaOne, nous appliquons une règle simple : « une politique par appareil », ce qui vous offre une meilleure visibilité et une meilleure compréhension de la manière dont chaque appareil est géré. Avec d'autres solutions, plusieurs politiques peuvent s'appliquer à un même terminal, ce qui rend la gestion plus difficile et plus confuse. Grâce à cette méthode de politique unique, vous bénéficiez d'une expérience plus intuitive et plus efficace.
Héritage des politiques :
NinjaOne inclut un concept appelé « héritage des politiques » qui permet une gestion plus standardisée et plus efficace des appareils. Lors de sa création, une nouvelle politique (enfant) peut être configurée pour hériter d’une autre politique (parent), ce qui relie les deux politiques de telle sorte que toute modification apportée à la politique parent se répercute sur la politique enfant. Cette relation est permanente et unidirectionnelle, ce qui vous permet de trouver un équilibre entre les besoins de personnalisation, la standardisation et une gestion efficace.
Bien que les statuts suivants ne soient pas définis dans NinjaOne, les politiques peuvent être classées comme suit :
- Les politiques autonomes, qui sont des politiques n'ayant ni politique parente ni politique enfant.
- Les politiques racines sont les politiques de niveau supérieur qui n'ont pas de politique parente. Ces politiques définissent les règles générales pour toutes les politiques qui leur sont subordonnées. La majeure partie de votre travail s'effectuera au niveau racine. Une fois vos nouveaux traits configurés, vous les désactiverez tous, puis vous activerez ces règles ou les remplacerez au niveau parent ou enfant. Les politiques racines incluront toutes les conditions, les scripts planifiés, les politiques de gestion des correctifs, les plans de sauvegarde, etc. Tout ce qui s'applique à plus d'un groupe d'appareils ou qui est complexe à configurer se situera généralement au niveau de la politique racine.
- Les politiques parentales sont les politiques de niveau intermédiaire qui coordonnent les décisions entre les différents niveaux de politique. À l'aide des politiques parentales, vous pouvez activer ou désactiver les traits créés au niveau supérieur. En tant que niveau intermédiaire, ces politiques ont pour seul but d'améliorer l'efficacité au niveau enfant.
- Les politiques enfants activent des caractéristiques spécifiques aux appareils. Tout ce qui est propre à un client individuel ou à un groupe d'appareils, qui nécessite des identifiants spécifiques, ou qui inclut des éléments applicables uniquement à un petit groupe de routines se trouve généralement au niveau des politiques enfants.
Comment les politiques interagissent
Vous trouverez ci-dessous un exemple de ce à quoi peut ressembler un ensemble de politiques dans NinjaOne. Notez que chaque appareil relève d'une seule politique plutôt que de plusieurs, ce qui simplifie les opérations.
En ce qui concerne les interactions entre les politiques, les règles suivantes s'appliquent :
- Toute modification apportée à une politique parente ou racine se répercute sur les autres politiques enfants répertoriées en dessous.
- Les politiques enfants peuvent remplacer les décisions prises dans la politique parente ou ajouter des caractéristiques supplémentaires.
- Lorsque vous modifiez des politiques enfants, les politiques parents ne changent pas.
- L'héritage peut s'étendre sur plusieurs niveaux, de la racine aux enfants.
Comment les hiérarchies influencent la création de politiques
Lorsque vous créez vos politiques, il est important de noter que vos politiques parentales doivent être créées avant que vous ne puissiez créer une politique enfant en dessous. Chaque fois que vous créez une nouvelle politique, vous avez la possibilité de l'assigner à une autre politique, qui deviendra alors la politique parentale.
Vous ne pouvez pas créer une politique puis l'attribuer ultérieurement comme politique héritée. Si vous souhaitez l'attribuer à une politique parente, cela doit être fait avant la publication. Une fois la publication effectuée, vous ne pourrez plus l'attribuer à une nouvelle politique parente.
Vous avez la possibilité de copier des politiques, mais il s'agit strictement d'une copie qui n'héritera d'aucune modification apportée à la politique d'origine qui a été copiée.
Hiérarchies de politiques :
Maintenant que nous avons établi une base sur ce à quoi vous pouvez vous attendre en matière de gestion des politiques, examinons trois structures de politiques différentes afin de comparer les cas d'utilisation et les avantages.
Politiques cloisonnées
Les politiques cloisonnées constituent la version la plus simple des politiques et nécessitent le moins de préparation. Elles sont rarement le meilleur choix pour la gestion des appareils dans NinjaOne, car chaque politique est indépendante, sans consolidation ni efficacité inter-politiques. Il est presque toujours possible de gagner en efficacité en attribuant une politique parente à chaque rôle d’appareil.
Cela signifie également que toute mise à jour du workflow, comme les modifications des calendriers de correctifs ou des règles de sauvegarde, devra être reproduite manuellement dans toutes les politiques concernées, au lieu de tirer parti d’une politique parentale globale. Ce type de structure peut convenir à des environnements très simples, mais manque d’efficacité à grande échelle lorsque vous commencez à ajouter davantage d’appareils à NinjaOne.
Les politiques cloisonnées peuvent être efficaces si :
- Tous vos appareils au sein d'un rôle sont gérés de la même manière, sans variation entre les appareils ou les groupes d'appareils.
- Chaque groupe d'appareils est géré de manière si différente qu'il n'y a aucun gain d'efficacité à regrouper les tâches dans une politique parentale.
Politiquesparentales globales
Les structures parentales globales constituent un niveau supérieur par rapport aux politiques cloisonnées, le travail sur les politiques étant consolidé au niveau parental global plutôt que de gérer chaque ensemble d'appareils via des politiques enfants isolées. Il s'agit toujours d'une hiérarchie assez plate, mais qui offre un peu plus de profondeur et de facilité de gestion. Cette structure est idéale pour les environnements qui tirent parti de la flexibilité et de la standardisation.
En tirant parti de la structure parent-enfant, vous pouvez gagner en efficacité. Le travail effectué au niveau parent sera automatiquement répercuté sur les politiques enfants. Vous devriez effectuer autant de travail que possible dans la politique parent globale, puis procéder aux personnalisations et ajustements au niveau des politiques enfants. La gestion des postes de travail, par exemple, est souvent facilement standardisable du point de vue de la surveillance, de l’automatisation des tâches, de l’antivirus et de la sauvegarde, les variations les plus courantes concernant les calendriers de mise à jour.
Il s'agit de la structure de politiques la plus courante chez nos clients expérimentés et elle convient à la plupart des situations.
Politiquesmulticouches
Les configurations multicouches constituent la structure la plus complexe des trois, ajoutant une complexité accrue avec des politiques aux niveaux racine, parent et enfant. Cette structure peut s’avérer extrêmement efficace dans des environnements complexes mais hautement structurés, mais peut également devenir complexe et difficile à gérer si elle n’est pas correctement contrôlée.
Le fait de disposer de plusieurs niveaux d'héritage permet d'établir une norme de base pour la gestion des appareils, la personnalisation par groupes d'appareils et la personnalisation à grande échelle. En général, il est toujours préférable de pousser les configurations le plus haut possible dans l'arborescence des politiques et de les regrouper en un nombre de politiques aussi réduit que possible pour atteindre vos objectifs.
Cette structure de politiques est le plus souvent utilisée pour la gestion de serveurs, lorsque vous gérez de nombreux serveurs ayant des objectifs différents, ou pour les MSP qui souhaitent standardiser leurs services pour tous leurs clients.
Exemple concret
Une fois que vous commencez à ajouter davantage de périphériques à la plateforme NinjaOne, voici à quoi pourrait ressembler la structure de votre organisation, tirant parti de chaque type de structure au sein d'une plateforme cohérente :
Remplacements au niveau des appareils :
Vous aurez toujours la possibilité de remplacer les politiques au niveau de l'appareil. Par exemple, si vous disposez d'un ordinateur portable particulier qui doit être exempté du calendrier de correctifs existant, vous pouvez remplacer ce dispositif spécifique et lui attribuer un calendrier de correctifs distinct. Tout élément de politique, tel que les conditions et les scripts, peut être ajouté ou remplacé au niveau de l'appareil.
Les dérogations prévalent sur les normes de politique. Si vous effectuez une dérogation au niveau de l'appareil et que la politique parente est modifiée, la dérogation prévaudra toujours et ignorera la modification apportée à la politique parente.
Stratégies de gestion des politiques :
À mesure que vous avancez dans la gestion des politiques et que vous créez ou mettez à jour votre structure de politiques, voici quelques éléments à prendre en compte :
-
Planifiez, puis mettez en place. Avant de créer ou de mettre à jour vos politiques, déterminez la fonction des hiérarchies. N'oubliez pas que vous pouvez toujours prévoir une expansion, mais n'utilisez que les niveaux nécessaires pour le moment. Questions à se poser :
- Les politiques applicables aux appareils sont-elles définies par client ? Par filiale ? Par groupe fonctionnel ?
- Avez-vous besoin d'une hiérarchie à plusieurs niveaux ?
- Si vous utilisez une structure à plusieurs niveaux, à quoi correspondent les politiques de niveau intermédiaire ?
- La consolidation est essentielle. C'est le moment d'investir dans les politiques racines. Plus vous travaillez lors de la phase de planification, moins vous aurez de travail à faire par la suite. N'oubliez pas que vous pouvez toujours désactiver par défaut les traits dans le parent global s'ils ne sont pas largement applicables. Utilisez des politiques de niveau intermédiaire ou ciblant les appareils pour activer des fonctionnalités, et n'activez que ce qui est nécessaire via les niveaux parent et enfant.
- Standardisez partout. Si vous disposez de politiques existantes, demandez-vous si vous avez vraiment besoin de différencier les groupes de politiques existants. Commencez à regrouper les politiques en une seule plutôt que de les gérer individuellement. Si certains appareils nécessitent des exceptions, créez ces exceptions dans les politiques plutôt que des dérogations. Réduisez au minimum le nombre de dérogations et de politiques autonomes dans votre structure, car ces exceptions entraîneront souvent davantage de complications par la suite.
- Avoir une politique parentale supplémentaire ne fait jamais de mal. Étant donné que NinjaOne ne vous permet pas d'attribuer rétroactivement une politique parentale, il est toujours utile d'avoir une politique parentale globale pour toutes les politiques d'un rôle de périphérique. Configurez une politique parentale globale, même si elle est vide, et attribuez-y toutes les nouvelles politiques au fur et à mesure de leur création. Il est très peu probable que vous ne puissiez pas appliquer certaines conditions, certains scripts planifiés ou certaines bonnes pratiques de correctifs à une politique parentale pour plus d'efficacité.