Con NinjaOne, creare politiche coerenti è un gioco da ragazzi, consentendoti di gestire gli endpoint in modo semplice ed efficiente. In questa guida tratteremo i concetti chiave delle politiche con esempi reali di come funzionano all'interno della console NinjaOne.
Indice:
- Informazioni sulla funzionalità delle politiche di NinjaOne
- Eredità delle politiche
- Gerarchie delle politiche
- Override dei dispositivi
- Strategie di gestione delle politiche
- 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 gestirà i dispositivi.
Cosa contiene una politica?
Con le politiche, si comunica a NinjaOne come si desidera che i propri endpoint vengano gestiti quotidianamente. NinjaOne esegue automaticamente e in modo continuativo le azioni previste dalle politiche su tutti i dispositivi correlati.
Le politiche includono regole di monitoraggio degli endpoint, regole di automazione, opzioni di gestione granulare 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", che offre maggiore visibilità e comprensione di come viene gestito ogni dispositivo. Con altre soluzioni, è possibile che a un singolo endpoint vengano applicate più politiche, rendendo la gestione più difficile e confusa. Utilizzando questo metodo a politica unica, si ottiene un'esperienza più intuitiva ed efficiente.
Eredità delle politiche:
NinjaOne include un concetto chiamato eredità delle politiche che consente una gestione più standardizzata ed efficiente dei dispositivi. Al momento della creazione, una nuova politica (figlia) può essere assegnata per ereditare un'altra politica (genitore) che collega le due politiche in modo tale che qualsiasi modifica apportata alla politica genitore si rifletta nella politica figlia. Questa relazione è continua e unidirezionale, consentendo di bilanciare le esigenze di personalizzazione con la standardizzazione e una gestione efficiente.
Sebbene i seguenti non siano stati definiti come stati delle policy in NinjaOne, le policy possono essere classificate come:
- Politiche autonome, che sono politiche che non hanno né una politica padre né una politica figlia.
- Le politiche radice sono le politiche di livello superiore senza politiche padre. Queste politiche definiscono le regole generali per tutte le politiche subordinate. La maggior parte del lavoro verrà svolto a livello di radice. Una volta impostati i nuovi tratti, è necessario disattivarli tutti e quindi attivare o sovrascrivere tali regole a livello padre o figlio. Le politiche radice includeranno tutte le condizioni, gli script pianificati, le politiche di gestione delle patch, i piani di backup, ecc. Tutto ciò che si applica a più di un gruppo di dispositivi o che è complesso da configurare risiederà generalmente nel livello della politica 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 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, risiede generalmente nel livello delle politiche figlio.
Come interagiscono le politiche
Di seguito è riportato un esempio di come può apparire un insieme di politiche all'interno di NinjaOne. Si noti che ogni dispositivo risiede sotto una singola politica piuttosto che sotto più politiche, il che semplifica le operazioni.
Per quanto riguarda le interazioni tra le politiche, si applica quanto segue:
- Qualsiasi modifica a una politica padre o radice verrà trasferita alle restanti politiche figlio elencate al di sotto.
- Le politiche secondarie possono sovrascrivere le decisioni prese nella politica principale o aggiungere ulteriori caratteristiche.
- Quando si apportano modifiche alle politiche figlie, le politiche padre non cambiano.
- L'ereditarietà può essere accumulata su più livelli, dalla radice alla figlia.
Come le gerarchie influenzano la creazione delle politiche
Quando si creano le policy, è importante notare che le policy padre devono essere create prima di creare una policy figlia al loro interno. Ogni volta che si crea una nuova policy, è possibile assegnarla a qualsiasi altra policy, che diventerà quindi la policy padre.
Non è possibile creare una politica e poi assegnarla come politica ereditata in un secondo momento. Se si desidera assegnarla a una politica padre, è necessario farlo 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 che non erediterà alcuna caratteristica modificata dalla politica originale che è stata copiata.
Gerarchie delle policy:
Ora che abbiamo stabilito un livello base su cosa ci si può aspettare dalla gestione delle policy, diamo un'occhiata a tre diverse strutture di policy per confrontare casi d'uso e vantaggi.
Politiche a silos
Le politiche a silos sono la versione più semplice di politiche che richiedono il minimo sforzo di pianificazione. Le politiche a silos raramente sono la scelta migliore per la gestione dei dispositivi in NinjaOne, poiché ogni politica è indipendente dalle altre, senza consolidamento o efficienza tra le politiche. Quasi sempre è possibile ottenere una maggiore efficienza avendo una politica madre 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, invece di sfruttare una politica madre generale. Questo tipo di struttura può funzionare per ambienti molto semplici, ma manca dell'efficienza di scala quando si iniziano ad aggiungere altri 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/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 politica principale.
Politicheglobali di livello superiore
Le strutture globali di livello superiore rappresentano un livello superiore rispetto alle politiche isolate, con il lavoro sulle politiche consolidato a livello globale piuttosto che gestire ogni set di dispositivi attraverso politiche isolate di livello inferiore. Si tratta comunque di una gerarchia piuttosto piatta, ma offre un po' più di profondità e gestibilità. Questa struttura è ideale per 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. È consigliabile svolgere il maggior lavoro possibile nella politica padre globale, quindi apportare personalizzazioni e modifiche 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 nei programmi di patch.
Questa è la struttura di policy più comune che riscontriamo presso i clienti maturi ed è adatta alla maggior parte delle situazioni.
Criterimultilivello
Le configurazioni multilivello sono la struttura più complessa delle tre, poiché aggiungono ulteriore complessità con criteri a livello di root, padre e figlio. 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.
La presenza di più livelli di ereditarietà consente di definire 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 è utilizzata più comunemente per la gestione dei server in cui si gestiscono molti server con scopi diversi o per gli MSP che desiderano standardizzare i client.
Esempio reale
Una volta che inizi ad aggiungere altri dispositivi alla piattaforma NinjaOne, la struttura della tua organizzazione potrebbe apparire come quella riportata di seguito, sfruttando ogni tipo di struttura in un'unica piattaforma coesa:
Sostituzioni dei dispositivi:
Avrete sempre la possibilità di sovrascrivere le politiche a livello di dispositivo. Ad esempio, se avete un laptop particolare che deve essere esentato dalla pianificazione delle patch esistente, potete sovrascrivere quel dispositivo specifico e inserirlo in una pianificazione delle patch separata. 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 alcuni aspetti 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 multilivello?
- Se si utilizza una struttura multilivello, a cosa corrispondono le politiche di livello intermedio?
- Il consolidamento è fondamentale. È il momento di investire in politiche di base. Più lavoro fate nella fase di pianificazione, meno lavoro avrete da fare in seguito. Ricordate che potete sempre disabilitare le caratteristiche nel genitore globale per impostazione predefinita se non sono ampiamente applicabili. Utilizzate politiche di livello intermedio o relative ai dispositivi per abilitare le funzionalità e abilitate solo ciò che è necessario attraverso i livelli genitore e figlio.
- Standardizzate ovunque. Se avete già delle politiche, valutate se è davvero necessario differenziare i gruppi di politiche esistenti. Iniziate a consolidare le politiche in politiche uniche piuttosto che gestirele singolarmente. Se alcuni dispositivi richiedono delle eccezioni, inserite tali eccezioni nelle politiche piuttosto che sovrascriverle. Riducete al minimo il numero di sovrascritture e di politiche autonome nella vostra struttura, poiché tali eccezioni spesso causano ulteriori problemi in futuro.
- Avere una politica genitore aggiuntiva non guasta mai. Poiché NinjaOne non consente di assegnare retroattivamente una politica genitore, non guasta mai avere un genitore globale per tutte le politiche in un ruolo dispositivo. Impostare un genitore globale, anche se vuoto, e assegnare tutte le nuove politiche a tale politica genitore man mano che vengono create. La probabilità di non poter applicare alcune condizioni, script pianificati o best practice di patching a una politica genitore per una maggiore efficienza è molto bassa.