Come costruire e mantenere una libreria di script condivisa tra più tecnici MSP

I provider di servizi gestiti (MSP) hanno bisogno di script per l’automazione, la risoluzione dei problemi e la coerenza. Per evitare duplicazioni, incoerenze e rischi per la sicurezza, devono mantenere una libreria di script centralizzata e standardizzata. Leggi questo articolo per imparare a creare e mantenere un repository di script sicuro, scalabile e basato sui ruoli, utilizzando strumenti come PowerShell, CMD, Git, GPO e NinjaOne.

Passi per la creazione e la manutenzione di una libreria di script condivisa

Quando costruisci una libreria di script, devi concentrarti sulla struttura, sulla sicurezza e sulla manutenzione del repository. Questo garantisce l’accesso agli strumenti giusti al momento giusto senza compromettere la sicurezza o la coerenza. Di seguito sono riportati alcuni passaggi che i team IT degli MSP possono utilizzare per progettare una libreria di script efficiente.

📌 Prerequisiti:

• una posizione di archiviazione centrale (file server interno, repository Git o libreria di script RMM)
• Definizione chiara dei ruoli e dei livelli tecnici (ad esempio, livello 1, 2, 3)
• Accesso amministrativo per assegnare autorizzazioni e distribuire chiavi di registro, GPO o policy RMM
• Piattaforme di scripting comuni: PowerShell, CMD, Batch, Python (opzionale)
• Standard concordati di denominazione e documentazione
• Un processo di approvazione predefinito

💡 Suggerimento: Controlla Cose da tenere d’occhio prima di procedere.

📌 Strategie di implementazione consigliate:

Fase 1: Progettare una struttura di cartelle e di tag per la biblioteca

Questa fase organizza i copioni in modo chiaro e logico, in modo che i tecnici possano individuare rapidamente i copioni approvati senza doverli spulciare. Migliora la ricercabilità e riduce le perdite di tempo per trovare gli script giusti. Di seguito è riportato uno standard organizzativo e di documentazione che consigliamo di utilizzare.

📌 Casi d’uso:

• MSP multi-client con ambienti Windows misti
• Organizzazioni con esigenze di onboarding per nuovi tecnici

📌 Prerequisiti: una gerarchia di cartelle ben definita con convenzioni di denominazione e modelli di metadati

1. Crea una cartella principale denominata \ScriptLibrary.
2. Aggiungi sottocartelle:
   • \Approved (per script completamente testati e sicuri da usare)
     • \Tier1 (per script di base a livello di helpdesk, come il riavvio di un servizio)
     • \Tier2 (script intermedi per la risoluzione dei problemi)
     • \Tier3 (script avanzati o complessi per ingegneri senior)
   • \In Review (per gli script in attesa di approvazione)
   • \Deprecated (per gli script obsoleti)
   • \Documentation (per guide all’uso e riferimenti)
3. Definisci una convenzione di denominazione.

Formato: Action_Target_Tier_Version.ps1
Esempio: Restart_PrintSpooler_T1_v1.1.ps1

• • Action (cosa fa lo script) (ad esempio, Riavvio)
  • Target (l’effetto dello script) (ad esempio, PrintSpooler)
  • Tier (quale tier tecnico è autorizzato ad usarlo) (T1, T2, T3)
  • Version (versione dello script) (ad esempio, v1.1)

4. All’inizio di ogni script, aggiungi metadati, come ad esempio:

<#

Author: mbrown

Date: 2025-07-01

Tier: Tier 1

Tested On: Windows 10, Server 2022

Description Restarts the Print Spooler service

#>

Fase 2: Controllare l’accesso agli script utilizzando ruoli NTFS, di registro o NinjaOne

I tecnici devono poter accedere solo agli script adatti al loro ruolo. Questa fase limita l’esposizione degli strumenti sensibili per evitare abusi e ridurre la superficie di attacco.

📌 Casi d’uso:

• ambienti con ingegneri sia entry-level che senior
• MSP che servono settori ad alto rischio come quello sanitario o finanziario

📌 Prerequisiti:

• autorizzazioni NTFS (New Technology File System) su cartelle condivise / Controllo degli accessi basato sui ruoli in NinjaOne
• Opzionale: Autorizzazioni per la modifica del registro

Utilizzo delle ACL NTFS sulle unità condivise

1. Clic destro del mouse sulla cartella di destinazione, seleziona Proprietà > Protezione.
2. Assegnare:
   • Tier 1: Accesso in sola lettura a \Tier1
   • Tier 2: Lettura-scrittura di \Tier1 e \Tier2
   • Amministratori: Controllo completo su tutti i livelli

Utilizzo del tagging del registro per l’uso della libreria di script locale

1. Sulle workstation del tecnico o sui server di gestione, crea un percorso del Registro di sistema utilizzando questo comando PowerShell:

New-Item -Path "HKLM:\SOFTWARE\Org\ScriptLibrary" -Force

2. Assegna il livello del tecnico:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptLibrary" -Name "Role" -Value "Tier1"

3. Utilizza questo valore per controllare la visibilità degli script nella logica di automazione o nei trigger RMM.

Ad esempio, supponi di avere uno script chiamato Restart_PrintSpooler_T1_v1.1.ps1. Non vuoi che le postazioni di livello 2 o 3 aggirino i controlli di versione o li utilizzino in modo non previsto.

1. Esegui questo script manualmente sulle singole workstation o tramite GPO per impostare il livello:

New-Item -Path "HKLM:\SOFTWARE\Org\ScriptLibrary" -Force

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptLibrary" -Name "Role" -Value "Tier1"

2. All’inizio di Restart_PrintSpooler_T1_v1.1.ps1, aggiungi questo frammento di esecuzione dello script:

$role = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptLibrary").Role

if ($role -ne "Tier1") {

Write-Error "This script is restricted to Tier 1 technicians. Current role: $role"

exit 1

}

3. Risultato: Verrà eseguito normalmente se una workstation di livello 1 esegue lo script, ma l’esecuzione si interrompe e viene registrato un errore se una workstation di livello 2 o 3 tenta di eseguirlo.

Utilizzo dei ruoli di NinjaOne

Configura i ruoli dei tecnici in NinjaOne e assegna gli script solo ai livelli di ruolo corrispondenti.

Fase 3: Gestire le versioni e approvare gli script utilizzando Git o i tag di versione locali

Questa fase può aiutare i tecnici a mantenere una chiara cronologia delle versioni, a garantire che vengano utilizzati solo script approvati e a tenere traccia di chi ha apportato le modifiche. Inoltre, impedisce le sovrascritture accidentali creando una traccia di audit per la conformità e la risoluzione dei problemi.

📌 Casi d’uso:

• ambienti in cui sono necessari cambiamenti frequenti
• I settori che richiedono registri di modifica per la conformità sono molto esigenti

📌 Prerequisiti:

• repository Git (GitHub, GitLab, Azure DevOps) / Una cartella condivisa con tracciamento manuale della versione
• Flusso di lavoro per la revisione e l’approvazione tra pari

Utilizzo di Git

1. Crea un repository dedicato agli script.
2. Usa i rami di funzionalità per le modifiche agli script.
3. Inviare richieste di pull per la revisione tra pari.
4. Unire solo dopo l’approvazione e la verifica.
5. Etichettare i rilasci con i numeri di versione.

Utilizzo di cartelle condivise

1. Aggiungi i numeri di versione ai nomi dei file (ad esempio, “_v1.1”).
2. Utilizza changelog.md o CSV:

Formato: Nome dello script, Versione, Data, Autore, Note

Esempio: Restart_PrintSpooler_T1, v1.1, 2025-07-01, mbrown, Added error handling

Fase 4: Automatizzare la distribuzione degli script con RMM o con attività pianificate

Questa fase distribuisce automaticamente gli script approvati agli endpoint giusti e ne garantisce l’aggiornamento. In questo modo i tecnici hanno sempre a disposizione le ultime versioni approvate.

📌 Casi d’uso:

• librerie di script regolarmente aggiornate
• Ambienti MSP altamente standardizzati

📌 Prerequisiti:

• strumento RMM (ad esempio, NinjaOne) / Utilità di pianificazione di Windows
• Script di sincronizzazione dei file per la replica

Utilizzo di NinjaOne

1. Assegnare gli script ai ruoli dei tecnici o ai tag dei dispositivi.
2. Imposta lo stato dell’approvazione (ad esempio, Approvato, Limitato, Legato).
3. Configura i trigger in base ai tag dei dispositivi, ai criteri o alle azioni manuali dei tecnici.

Utilizzo dell’utilità di pianificazione di Windows per le librerie manuali

1. Crea un’attività pianificata:

schtasks /create /tn "WeeklyScriptSync" /tr "powershell.exe -File \\share\sync-library.ps1" /sc weekly /ru SYSTEM

💡 Nota: il file sync-library.ps1 è uno script PowerShell personalizzato che definisce come copiare gli script dal repository centrale alla workstation locale di ciascun tecnico. Non si tratta di uno script integrato, quindi il team IT deve scriverlo.

2. Scrivi uno script di sincronizzazione che copi solo gli script approvati nelle cartelle locali.

Fase 5: Convalidare la cronologia di esecuzione e l’utilizzo degli script tramite i tag di audit

Questa fase tiene traccia di quali script vengono utilizzati, di chi vi accede e di quando, per supportare la responsabilità e la conformità. Fornisce inoltre la documentazione per i QBR o la conformità.

📌 Casi d’uso:

• operazioni conformi a HIPAA, PCI-DSS o ISO
• MSP che effettuano revisioni regolari a contatto con i clienti

📌 Prerequisiti:

• comandi di registrazione del Registro
• Campi personalizzati o strumenti di reporting di NinjaOne

1. Apri PowerShell come amministratore.
2. Registra l’ultimo script eseguito, chi lo ha eseguito e quando, utilizzando questo script:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptAudit" -Name "LastUsedScript" -Value "Restart_PrintSpooler_T1_v1.1"

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\ScriptAudit" -Name "LastRunBy" -Value "$env:USERNAME - $(Get-Date -Format u)"

💡 Nota: questa operazione creerà la chiave di registro sulla workstation su cui viene eseguito lo script. Se un tecnico lo esegue su più computer, ogni sistema avrà il proprio record locale. Per la prima riga, il valore “Restart_PrintSpooler_T1_v1.1” è solo un segnaposto. Sostituiscilo con il nome effettivo dello script che stai eseguendo.

3. Recupera i log utilizzando i report di NinjaOne o esportandoli in CSV.

Passo 6: Utilizzare le GPO per imporre l’esecuzione locale e la conformità ai criteri

L’uso di GPO offre migliori controlli sugli script e applica le impostazioni di sicurezza per i criteri di esecuzione. Impedisce l’esecuzione di script al di fuori delle directory approvate e garantisce criteri di esecuzione coerenti tra gli endpoint.

📌 Casi d’uso:

• ambienti altamente regolamentati.
• Reti in cui gli utenti degli endpoint possono tentare di eseguire script non autorizzati

📌 Prerequisiti:

• accesso alla Console di gestione dei criteri di gruppo (GPMC)
• Criteri di esecuzione definita
• I computer gestiti devono essere collegati al dominio

1. Apri la Console di gestione dei Criteri di gruppo (GPMC).
2. Nel riquadro di sinistra, vai su:

Configurazione del computer > Modelli amministrativi > Componenti di Windows > Windows PowerShell

3. Impost Attiva esecuzione script su Consenti solo script firmati o Consenti script locali e script firmati remoti.

💡 Nota: L’opzione Consenti solo script firmati richiede la firma di tutti gli script che intendi utilizzare.

4. Reindirizza i percorsi delle cartelle degli script:

Configurazione utente > Preferenze > Impostazioni di Windows > Mappe delle unità

Map \\mspshare\ScriptLibrary\Tier1 as S:

💡 Nota: si trova in Preferenze, non in Criteri. Le mappe delle unità sono disponibili solo se sono installate le Preferenze criteri di gruppo, che sono supportate in Windows Server 2008 o successivo.

⚠️ Cose da tenere d’occhio

Perché la standardizzazione delle librerie di script è importante

La creazione di una libreria di script condivisi non è solo conveniente, ma anche efficiente e sicura. I team IT negli ambienti MSP possono sprecare tempo e sforzi per duplicare il lavoro e adottare pratiche incoerenti se non utilizzano le librerie di script. L’applicazione della standardizzazione può offrire diversi vantaggi, quali:

• Evitare che i tecnici ricreino script già esistenti, risparmiando tempo e fatica
• Consentire a tutti i tecnici di utilizzare gli stessi metodi di automazione testati e approvati per ridurre errori e variabilità
• Limitare l’accesso agli script sensibili in base al ruolo del tecnico e ridurre il rischio di uso improprio o di danni accidentali
• Garantire che i tecnici di tier inferiore dispongano solo degli strumenti necessari, mentre il personale di livello superiore può accedere in modo sicuro agli script avanzati
• Facilitare l’identificazione, la revisione e la correzione dei problemi in un’unica posizione centralizzata, invece di inseguire più versioni
• Consentendo ai nuovi tecnici di utilizzare rapidamente strumenti collaudati e documentati senza bisogno di troppe regolazioni
• Mantenere una chiara documentazione degli script approvati, delle loro versioni e del loro utilizzo per gli audit o le revisioni normative
• Promuovere la condivisione delle conoscenze tra i tecnici mantenendo i contenuti allineati agli standard organizzativi
• Consentire il rollout controllato delle modifiche per garantire che tutti lavorino con le ultime versioni approvate degli script

Ulteriori considerazioni sulla gestione di una libreria di script condivisa

Oltre alle strutture di cartelle, ai controlli di accesso e ai flussi di lavoro di automazione, gli MSP devono prestare attenzione ad altri fattori che possono influenzare l’utilità di questa libreria di script. Ecco alcuni elementi da considerare:

• Deprecazione degli script: Vuoi evitare che i tecnici eseguano accidentalmente script obsoleti o non sicuri. A tale scopo, sposta i vecchi script in una cartella \Deprecati o aggiungi un avviso esplicito all’inizio degli script legacy.
• Documentazione: l’aggiunta di un file di testo alle librerie, che include informazioni quali lo scopo, i parametri richiesti, le piattaforme testate, le limitazioni note e le istruzioni di rollback, rende più veloce l’inserimento di nuovi tecnici e migliora la risoluzione dei problemi
• Controllo delle modifiche: imposta i criteri interni per chi può pubblicare o approvare gli script. È meglio richiedere la revisione tra pari per tutti i nuovi script o gli aggiornamenti principali e tenere traccia di tutte le modifiche in Git o in un file di changelog.
• Compatibilità cross-client: per garantire che uno script funzioni in modo affidabile in diversi ambienti dei clienti, testa gli script in ambienti sandbox per ogni sistema operativo e configurazione supportata. È inoltre opportuno aggiungere etichette o metadati che indichino i requisiti specifici dell’ambiente, come quelli per Intune o Defender.

Risoluzione dei problemi più comuni

Errori di autorizzazione

Innanzitutto, verificare le autorizzazioni NTFS confermando che il tier 1 è di sola lettura, il tier 2 è di lettura/scrittura e gli amministratori hanno il controllo completo. In NinjaOne, rivedi le impostazioni dei ruoli dei tecnici e i criteri di assegnazione degli script. Se utilizzi l’etichettatura del registro, verifica che sul computer del tecnico sia impostato il valore di livello corretto.

Tecnici che utilizzano versioni obsolete

Imponi sincronizzazioni settimanali o giornaliere utilizzando l’Utilità di pianificazione o l’automazione RMM. È anche utile mantenere i tag di versione nei metadati degli script e nei nomi dei file.

Errori di esecuzione degli script

Per evitare che gli script terminino inaspettatamente, aggiungi sempre blocchi try/catch e un logging dettagliato per catturare i dettagli del fallimento. Da qui, puoi eseguire manualmente lo script in modalità di debug per isolare gli errori prima di eseguire nuovamente la distribuzione.

Le restrizioni GPO bloccano l’esecuzione

I Criteri di gruppo potrebbero essere configurati per bloccare l’esecuzione di script, oppure gli strumenti di sicurezza degli endpoint potrebbero applicare criteri di esecuzione restrittivi. In Gestione Criteri di gruppo, imposta l’esecuzione di script in modo da consentire solo script firmati o locali. Assicurati quindi che gli script siano firmati se vengono eseguiti in ambienti che utilizzano solo script firmati.

Servizi NinjaOne per aiutare le librerie di script dei tecnici MSP

I metodi tradizionali come le autorizzazioni NTFS, Git e GPO possono costituire una solida base per la tua libreria di script. Ma se hai bisogno di migliorare la gestione della libreria di script del tuo team, NinjaOne offre diversi servizi che possono aiutarti a standardizzare, automatizzare e verificare il tuo sistema.

Costruire saggiamente un framework di script scalabile

Quando crei una libreria di script condivisa, cerca sempre di migliorare l’efficienza dei tecnici, la sicurezza e la coerenza tra gli ambienti gestiti. È necessario standardizzare le strutture delle cartelle, controllare l’accesso per ruolo, gestire le versioni e automatizzare passaggi specifici per ridurre in modo significativo gli errori e i rischi per la sicurezza durante la crescita dell’organizzazione.

Argomenti correlati:

• Libreria di script NinjaOne
• Script di automazione IT: definizione e panoramica
• Che cos’è una knowledge base?