Avec NinjaOne, créer des politiques cohérentes est un jeu d'enfant, ce qui vous permet de gérer facilement et efficacement les terminaux. Dans ce guide, nous aborderons les concepts clés des politiques à l'aide d'exemples concrets illustrant leur fonctionnement dans la console NinjaOne.
Table des matières :
- À propos de la fonctionnalité de politique de NinjaOne
- Héritage des politiques
- Hiérarchies des politiques
- Dérogations au niveau des appareils
- Stratégies de gestion des politiques
- Documentation connexe
À propos de la fonctionnalité de politique de NinjaOne :
Que sont les politiques dans NinjaOne ?
Les politiques sont 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 ?
Les politiques permettent d'indiquer à NinjaOne comment vous souhaitez que vos terminaux soient gérés au quotidien. NinjaOne exécute automatiquement et en continu les actions prévues 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 utilisons une règle simple « une politique par appareil », 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 seul 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 assigné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 est répercutée dans la politique enfant. Cette relation est permanente et unidirectionnelle, ce qui vous permet d'équilibrer les besoins de personnalisation avec la standardisation et une gestion efficace.
Bien que les éléments suivants ne soient pas des statuts de politique définis dans NinjaOne, les politiques peuvent être classées comme suit :
- Politiques autonomes, qui sont des politiques qui n'ont ni politique parent ni politique enfant.
- Les politiques racines sont les politiques de niveau supérieur qui n'ont pas de politiques parentes. Ces politiques définissent les règles générales pour toutes les politiques qui leur sont subordonnées. La plupart de votre travail se fera au niveau racine. Une fois que vous aurez configuré vos nouveaux traits, vous les désactiverez tous, puis vous activerez ces règles ou les remplacerez au niveau parent ou enfant. Les politiques racines incluent toutes les conditions, les scripts planifiés, les politiques de gestion des correctifs, les plans de sauvegarde, etc. Tout ce qui s'applique à plusieurs groupes d'appareils ou qui est complexe à configurer se trouve généralement au niveau de la politique racine.
- Les politiques parentales sont des 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 gestion intermédiaire, ces politiques ont pour seul but d'améliorer l'efficacité au niveau enfant.
- Les politiques enfants activent les caractéristiques spécifiques à un appareil. Tout ce qui est propre à un client ou à un groupe d'appareils individuel, qui nécessite des informations d'identification spécifiques ou qui comprend des éléments applicables uniquement à un petit groupe de routines se trouve généralement au niveau de la politique enfant.
Interaction entre les politiques
Vous trouverez ci-dessous un exemple de ce à quoi peut ressembler un ensemble de politiques dans NinjaOne. Notez que chaque appareil est soumis à une seule politique plutôt qu'à 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 parent ou racine sera répercutée sur toutes les politiques enfants répertoriées en dessous.
- Les politiques enfants peuvent remplacer les décisions prises dans la politique parent ou ajouter des caractéristiques supplémentaires.
- Lorsque vous modifiez les politiques enfants, les politiques parentales ne changent pas.
- L'héritage peut s'empiler sur plusieurs niveaux, de la racine à la fille.
Comment les hiérarchies affectent la création de politiques
Lorsque vous créez vos politiques, il est important de noter que vos politiques parentes doivent être créées avant de créer une politique enfant sous celles-ci. Chaque fois que vous créez une nouvelle politique, vous avez la possibilité de l'attribuer à une autre politique, qui deviendra alors la politique parente.
Vous ne pouvez pas créer une politique puis l'attribuer comme politique héritée par la suite. Si vous souhaitez l'attribuer à une politique parente, vous devez le faire avant la publication. Après la publication, 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 caractéristique modifiée par la politique d'origine qui a été copiée.
Hiérarchies de politiques :
Maintenant que nous avons établi un niveau de base sur ce que vous pouvez attendre de la 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 sont la version la plus simple des politiques et celle qui nécessite le moins de réflexion préalable. Elles sont rarement le meilleur choix pour la gestion des appareils dans NinjaOne, car chaque politique est indépendante, sans consolidation ni efficacité entre les politiques. Il y a presque toujours des gains d'efficacité à réaliser en ayant une politique parent pour chaque rôle d'appareil.
Cela signifie également que toute mise à jour du flux de travail, telle que la modification des calendriers de correctifs ou des règles de sauvegarde, devra être reproduite manuellement dans toutes les politiques concernées, plutôt que de tirer parti d'une politique parent globale. Ce type de structure peut fonctionner dans des environnements très simples, mais manque d'efficacité à mesure que vous ajoutez des 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/groupes d'appareils.
- Chaque groupe de périphériques 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 parent.
Politiquesglobales parentes
Les structures parentales globales constituent un niveau supérieur aux politiques cloisonnées, le travail lié aux 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 bénéficient 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 est automatiquement dupliqué dans les politiques enfant. Vous devez effectuer autant de travail que possible dans la politique parent globale, puis procéder aux personnalisations et ajustements au niveau de la politique enfant. La gestion des postes de travail, par exemple, est souvent facile à standardiser du point de vue de la surveillance, de l'automatisation des tâches, de l'antivirus et de la sauvegarde, les variations dans les calendriers de correctifs étant les plus courantes.
Il s'agit de la structure de stratégie la plus courante chez nos clients expérimentés. Elle convient à la plupart des situations.
Politiquesmulticouches
Les configurations multicouches sont les plus complexes des trois, car elles ajoutent une couche supplémentaire avec les stratégies racine, parent et enfant. Cette structure peut être extrêmement efficace dans des environnements complexes mais très structurés, mais elle 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 préférable de placer les configurations le plus haut possible dans l'arborescence des politiques et de les regrouper en un minimum de politiques afin d'atteindre vos objectifs.
Cette structure de politique est le plus souvent utilisée pour la gestion de serveurs, où vous gérez de nombreux serveurs ayant des objectifs différents, ou pour les MSP qui souhaitent standardiser leurs processus entre leurs clients.
Exemple concret
Une fois que vous commencez à ajouter des appareils à la plateforme NinjaOne, voici à quoi pourrait ressembler la structure de votre organisation, en tirant parti de chaque type de structure dans une plateforme cohérente :
Remplacement des appareils :
Vous aurez toujours la possibilité de remplacer les politiques au niveau des appareils. Par exemple, si vous avez un ordinateur portable particulier qui doit être exempté du calendrier de correctifs existant, vous pouvez remplacer cet appareil spécifique et le placer sur un calendrier de correctifs distinct. Toute caractéristique de politique, telle que les conditions et les scripts, peut être ajoutée ou remplacée au niveau de l'appareil.
Les dérogations prévaudront sur les normes de stratégie. Si vous effectuez une dérogation au niveau de l'appareil et que la stratégie parentale est modifiée, la dérogation prévaudra et ignorera la modification apportée à la stratégie parentale.
Stratégies de gestion des politiques :
Au fur et à mesure que vous avancez dans la gestion des politiques et la création ou la mise à jour de votre structure de politiques, voici quelques éléments à prendre en compte :
- Planifiez, puis construisez. Avant de créer ou de mettre à jour vos politiques, déterminez la fonction des hiérarchies. N'oubliez pas que vous pouvez toujours planifier la croissance, mais n'utilisez que les couches nécessaires pour le moment. Questions à se poser
- Les politiques relatives aux appareils sont-elles spécifiques à chaque client ? À chaque filiale ? À chaque 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 des politiques fondamentales. 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 caractéristiques dans le parent global si elles ne sont pas largement applicables. Utilisez des politiques de niveau intermédiaire ou applicables à tous les appareils pour activer les fonctionnalités et n'activez que ce qui est nécessaire via les niveaux parent et enfant.
- Standardisez partout. Si vous disposez déjà de politiques, demandez-vous si vous avez vraiment besoin de différencier les groupes de politiques existants. Commencez à regrouper vos politiques en politiques uniques plutôt que de les gérer individuellement. Si certains appareils nécessitent des exceptions, ajoutez ces exceptions aux politiques plutôt que de les remplacer. Réduisez au minimum le nombre de remplacements et de politiques autonomes dans votre structure, car ces exceptions entraîneront souvent des complications par la suite.
- Il n'y a jamais de mal à avoir une politique parent supplémentaire. Comme NinjaOne ne vous permet pas d'attribuer rétroactivement une politique parent, il n'y a aucun inconvénient à avoir une politique parent globale pour toutes les politiques d'un rôle de périphérique. Configurez une politique parent globale, même si elle est vide, et attribuez-lui 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 correction à une politique parent pour plus d'efficacité.