Creare policy coerenti è un gioco da ragazzi con NinjaOne, che consente di gestire gli endpoint in modo semplice ed efficiente. In questa guida tratteremo i concetti chiave delle policy con esempi pratici di come funzionano all'interno della console NinjaOne.
Indice:
- Informazioni sulla funzionalità delle politiche di NinjaOne
- Eredità delle politiche
- Gerarchie delle politiche
- Deroghe dei dispositivi
- Strategie di gestione delle policy
- Documentazione correlata
Informazioni sulla funzionalità delle politiche di NinjaOne:
Cosa sono le politiche in NinjaOne?
Le politiche sono il motore centralizzato di gestione e automazione dei dispositivi di NinjaOne. Le politiche impostate determineranno il modo in cui NinjaOne gestisce i dispositivi.
Cosa contiene una politica?
Con le politiche, si indica a NinjaOne come si desidera che gli endpoint vengano gestiti quotidianamente. NinjaOne esegue automaticamente e in modo continuo le azioni previste dalle politiche su tutti i dispositivi correlati.
Le policy includono regole di monitoraggio degli endpoint, regole di automazione, opzioni granulari di gestione delle patch, preferenze relative alle soluzioni di sicurezza e backup e conservazione dei dati.
In che modo NinjaOne gestisce le politiche in modo diverso?
Con NinjaOne, utilizziamo una semplice regola "una politica per dispositivo", offrendoti maggiore visibilità e comprensione su come viene gestito ogni dispositivo. Con altre soluzioni, potresti avere più politiche applicate a un singolo endpoint, rendendo la gestione più difficile e confusa. Utilizzando questo metodo a politica singola, ottieni un'esperienza più intuitiva ed efficiente.
Eredità delle politiche:
NinjaOne include un concetto chiamato ereditarietà delle policy che consente una gestione più standardizzata ed efficiente dei dispositivi. Al momento della creazione, a una nuova policy (figlia) può essere assegnata l'eredità di un'altra policy (madre), il che collega le due policy in modo tale che qualsiasi modifica apportata alla policy madre si rifletta nella policy figlia. Questa relazione è continua e unidirezionale, consentendovi di bilanciare le esigenze di personalizzazione con la standardizzazione e una gestione efficiente.
Sebbene quelli che seguono non siano stati definiti come stati delle politiche in NinjaOne, le politiche possono essere classificate come:
- Policy autonome, ovvero policy che non hanno né una policy genitrice né una policy figlia.
- Le politiche radice sono le politiche di livello superiore senza politiche madri. Queste politiche definiscono le regole generali per tutte le politiche che si trovano al di sotto di esse. La maggior parte del lavoro verrà svolta a livello di radice. Una volta configurati i nuovi tratti, li disattiverai tutti e poi attiverai o sovrascriverai quelle regole a livello di policy genitrici o figlie. Le policy di radice includeranno ogni condizione, script pianificato, policy di gestione delle patch, piano di backup, ecc. Tutto ciò che si applica a più di un gruppo di dispositivi o è complesso da configurare risiederà generalmente all’interno del livello delle policy di radice.
- Le politiche di livello superiore sono le politiche di livello intermedio che coordinano le decisioni tra i diversi livelli di politica. Utilizzando le politiche di livello superiore, è possibile abilitare o disabilitare i tratti creati al livello superiore. In quanto gestione intermedia, queste politiche servono solo a migliorare l'efficienza a livello di livello inferiore.
- Le politiche figlio abilitano i tratti specifici del dispositivo. Tutto ciò che è proprietario di un singolo cliente o gruppo di dispositivi, che richiede credenziali specifiche o include elementi applicabili solo a un piccolo gruppo di routine, si trova generalmente a livello di politica figlio.
Come interagiscono le politiche
Di seguito è riportato un esempio di come può presentarsi un insieme di politiche all'interno di NinjaOne. Si noti che ogni dispositivo rientra in un'unica politica anziché in più politiche, il che semplifica le operazioni.
Per quanto riguarda le interazioni tra le politiche, vale quanto segue:
- Qualsiasi modifica a una politica padre o radice verrà trasmessa alle restanti politiche figlie elencate sotto di essa.
- Le politiche figlie possono sovrascrivere le decisioni prese nella politica genitrice o aggiungere ulteriori caratteristiche.
- Quando si apportano modifiche alle politiche figlie, le politiche madri non cambiano.
- L'ereditarietà può estendersi su più livelli, dalla radice ai figli.
In che modo le gerarchie influenzano la creazione delle politiche
Durante la creazione delle politiche, è importante notare che le politiche principali devono essere create prima di creare una politica secondaria al di sotto di esse. Ogni volta che si crea una nuova politica, è possibile assegnarla a qualsiasi altra politica, che diventerà quindi la politica principale.
Non è possibile creare una politica e poi assegnarla come politica ereditata in un secondo momento. Se si desidera assegnarla a una politica padre, ciò dovrà essere fatto prima della pubblicazione. Dopo la pubblicazione, non sarà più possibile assegnarla a un nuovo padre.
È possibile copiare le politiche, ma si tratta di una copia a tutti gli effetti che non erediterà alcuna modifica apportata alla politica originale da cui è stata copiata.
Gerarchie delle politiche:
Ora che abbiamo stabilito un livello di base su cosa ci si può aspettare dalla gestione delle politiche, diamo un'occhiata a tre diverse strutture di politiche per confrontare i casi d'uso e i vantaggi.
Policy isolate
Le politiche isolate sono la versione più semplice di politiche che richiedono il minimo di pianificazione. Le politiche isolate sono raramente la scelta migliore per la gestione dei dispositivi in NinjaOne poiché ogni politica è slegata, senza consolidamento o efficienza tra le politiche. Quasi sempre si ottengono dei vantaggi in termini di efficienza avendo una politica principale per ogni ruolo del dispositivo.
Ciò significa anche che qualsiasi aggiornamento del flusso di lavoro che deve essere effettuato, come le modifiche alle pianificazioni delle patch o alle regole di backup, dovrà essere duplicato manualmente in tutte le politiche pertinenti, anziché sfruttare una politica principale generale. Questo tipo di struttura può funzionare per ambienti molto semplici, ma manca dell'efficienza di scala man mano che si iniziano ad aggiungere più dispositivi a NinjaOne.
Le politiche isolate possono essere efficaci se:
- Tutti i dispositivi all'interno di un ruolo sono gestiti allo stesso modo, senza variazioni tra dispositivi o gruppi di dispositivi.
- Ogni gruppo di dispositivi è gestito in modo così diverso che non vi è alcun vantaggio in termini di efficienza nel consolidare il lavoro in una policy principale.
Politicheglobali di livello superiore
Le strutture globali di livello superiore rappresentano un passo avanti rispetto alle politiche isolate, con il lavoro sulle politiche consolidato a livello globale piuttosto che gestire ogni insieme di dispositivi attraverso politiche di livello inferiore isolate. Si tratta comunque di una gerarchia piuttosto piatta, ma offre un po' più di profondità e gestibilità. Questa struttura è ideale per gli ambienti che traggono vantaggio dalla flessibilità e dalla standardizzazione.
Sfruttando la struttura padre-figlio, è possibile ottenere una maggiore efficienza. Il lavoro svolto a livello padre verrà automaticamente duplicato nelle politiche figlio. Si dovrebbe svolgere il maggior lavoro possibile nella politica padre globale, per poi effettuare personalizzazioni e adeguamenti a livello di politica figlio. La gestione delle workstation, ad esempio, è spesso facilmente standardizzabile dal punto di vista del monitoraggio, dell’automazione delle attività, dell’antivirus e del backup, con variazioni più comuni nelle pianificazioni delle patch.
Questa è la struttura di policy più comune che osserviamo presso i clienti maturi ed è adatta alla maggior parte delle situazioni.
Politichemultistrato
Le configurazioni multistrato rappresentano la struttura più complessa delle tre, aggiungendo maggiore complessità con politiche a livello di radice, principale e secondaria. Questa struttura può essere incredibilmente efficace in ambienti complessi ma altamente strutturati, ma può anche diventare complessa e difficile da gestire se non controllata adeguatamente.
Avere più livelli di ereditarietà consente uno standard di base per la gestione dei dispositivi, la personalizzazione per gruppi di dispositivi e la personalizzazione su larga scala. In generale, è sempre consigliabile spingere le configurazioni il più in alto possibile nell'albero delle politiche e consolidarle nel minor numero possibile di politiche per raggiungere i propri obiettivi.
Questa struttura di policy viene utilizzata più comunemente per la gestione dei server, in cui si gestiscono molti server con scopi diversi, o per gli MSP che desiderano standardizzare l'approccio tra i clienti.
Esempio reale
Una volta che inizi ad aggiungere più dispositivi alla piattaforma NinjaOne, ecco come potrebbe apparire la struttura della tua organizzazione, sfruttando ogni tipo di struttura in un'unica piattaforma coesa:
Deroghe ai dispositivi:
Avrete sempre la possibilità di sovrascrivere le politiche a livello di dispositivo. Ad esempio, se avete un particolare laptop che deve essere esentato dal programma di patch esistente, potete sovrascrivere quel dispositivo specifico e inserirlo in un programma di patch separato. Qualsiasi caratteristica della politica, come condizioni e script, può essere aggiunta o sovrascritta a livello di dispositivo.
Le sostituzioni avranno la precedenza sugli standard delle politiche. Se si effettua una sostituzione a livello di dispositivo e la politica principale viene modificata, la sostituzione avrà comunque la precedenza e ignorerà la modifica alla politica principale.
Strategie di gestione delle politiche:
Man mano che procedi con la gestione delle politiche e la creazione o l'aggiornamento della struttura delle politiche, ecco alcune cose da considerare:
- Pianificare, poi costruire. Prima di creare o aggiornare le politiche, decidere la funzione delle gerarchie. Ricordare che è sempre possibile pianificare la crescita, ma utilizzare solo i livelli necessari per il momento. Domande da porsi:
- Le politiche relative ai dispositivi sono per cliente? Per filiale? Per gruppo funzionale?
- È necessaria una gerarchia a più livelli?
- Se si utilizza una struttura a più livelli, a cosa si traducono le politiche di livello intermedio?
- Il consolidamento è fondamentale. È il momento di investire nelle politiche di base. Più lavoro si fa in fase di pianificazione, meno lavoro si dovrà fare in seguito. Ricordate, potete sempre disabilitare le caratteristiche nel genitore globale per impostazione predefinita se non sono ampiamente applicabili. Utilizzate politiche di livello intermedio o rivolte ai dispositivi per abilitare le funzionalità e abilitate solo ciò che è necessario attraverso i livelli genitore e figlio.
- Standardizzate ovunque. Se avete politiche esistenti, valutate se avete davvero bisogno della differenziazione tra i gruppi di politiche esistenti. Iniziate a consolidare in politiche singole piuttosto che gestire le singole. Se determinati dispositivi necessitano di eccezioni, create tali eccezioni alle politiche piuttosto che sovrascriverle. Riducete al minimo il numero di sovrascritture e politiche autonome nella vostra struttura, poiché tali eccezioni spesso causano ulteriori grattacapi in seguito.
- Avere una politica padre in più non fa mai male. Poiché NinjaOne non consente di assegnare retroattivamente una politica padre, non fa mai male avere un padre globale tra le politiche in un ruolo di dispositivo. Imposta un padre globale, anche se è vuoto, e assegna tutte le nuove politiche a quella politica padre man mano che vengono create. La probabilità che non sia possibile applicare alcune condizioni, script pianificati o best practice di patch a una politica padre per una maggiore efficienza è molto bassa.