Risposta rapida. Per proteggere PLC S7-1500 serve più di una password, e ognuna protegge un bersaglio diverso. Il controllo accessi della CPU decide chi scarica, chi legge e chi arriva solo dall’HMI. La password dei dati di configurazione riservati protegge chiavi private e altri dati riservati. La know-how protection nasconde il codice di un blocco, ma non ne impedisce il caricamento. Da TIA Portal V19 con firmware V3.1 il controllo accessi passa per utenti e ruoli (UMAC), e il PUT/GET parte disattivato.

In TIA Portal le password sono almeno tre, ognuna chiude una porta diversa, e confonderle di solito finisce allo stesso modo: il codice nascosto con cura e il download aperto a chiunque sia sulla rete. Qui trovi cosa protegge ogni meccanismo, cosa no, dove si imposta secondo i manuali Siemens di novembre 2025 e come si prova che funziona. Il quadro generale sta nella guida pratica alla cybersecurity dei PLC per chi programma macchine.

Proteggere PLC S7-1500: quattro meccanismi, quattro bersagli

La tabella è il riassunto da tenere aperto mentre si configura. I percorsi di menu vengono dai manuali Siemens 11/2025 (TIA Portal fino a V21) e, per il controllo accessi legacy, dall’application example UMAC per V19 (07/2024), tranne dove è indicato il manuale di sistema del 2014: quelle voci vanno ricontrollate sulla tua versione.

Controllo accessi: utenti, ruoli e tre diritti

Da TIA Portal V19 e firmware V3.1 l’S7-1500 usa la User Management & Access Control (UMAC). Prima c’erano solo livelli protetti da password: la CPU sapeva che qualcuno aveva digitato la password, non chi. Con UMAC si creano utenti con nome e ruoli che portano diritti sulla CPU.

I diritti di accesso sono tre, e conviene leggerli con attenzione:

• HMI access: solo accesso HMI e dati di diagnostica; da un dispositivo HMI le variabili si leggono e si scrivono.
• Read access: lettura della configurazione hardware e dei blocchi. Permette anche di cambiare lo stato operativo (RUN/STOP) e di impostare l’ora.
• Full access: tutto, compresi download di blocchi e configurazione hardware, funzioni di test, RUN/STOP e aggiornamento firmware.

Il dettaglio del Read access sorprende. Un utente «solo lettura» può fermare la macchina: dare Read access al manutentore vuol dire dargli anche lo STOP della CPU.

Con firmware V3.1 cambiano i default di un progetto nuovo. Secondo l’application example sulla UMAC partono attivi la password dei dati di configurazione riservati e la sola comunicazione PG/PC e HMI sicura; il permesso PUT/GET è disattivato e non modificabile; il controllo accessi legacy di V17 e V18 è disattivato.

Dove si imposta

1. Nell’albero di progetto apri «Security Settings > Users and roles» e crea gli utenti. Per ogni utente c’è il campo «Runtime timeout», il tempo di inattività dopo il quale l’utente viene disconnesso. Sulla CPU l’unico metodo di autenticazione è la password.
2. Nelle proprietà della CPU, «Protection & Security > Access control», l’opzione «Enable access control» deve essere spuntata. È il default.
3. L’opzione «Use legacy access control via access levels» resta spenta, salvo il caso del pannello descritto qui sotto. In V19 il livello legacy si sceglie attraverso i diritti dell’utente «Anonymous»; con Anonymous disabilitato il risultato è «No access (complete protection)».

Il caso del pannello: l’application example dice che TIA Portal V19 «does not support user-based access control for PLC-HMI communication, only passwords», e consiglia di evitare il controllo accessi legacy se nessun pannello si collega. Se in V20 e V21 questo limite ci sia ancora, nelle fonti che abbiamo letto non c’è scritto: controllalo sulla tua versione prima di progettare gli accessi del pannello. Per chi lavora in V21 c’è anche la guida pratica per configurare TIA Portal V21.

Sotto il firmware V3.1 valgono i quattro livelli, che il manuale 2014 mette sotto la voce «Protection» (oggi «Protection & Security»). Lo stesso manuale dice che la CPU scrive nel buffer diagnostico ogni password giusta o sbagliata.

Read access non è sola lettura: chi lo ha può portare la CPU in STOP.

Cosa fa davvero il permesso PUT/GET

L’opzione si chiama «Permit access with PUT/GET communication from remote partner (PLC, HMI, OPC, …)» e sta in «Protection & Security > Connection mechanisms». Il punto da capire lo scrive il manuale del 2014: la comunicazione fra CPU fatta con i blocchi di comunicazione «is not restricted by the protection level of the CPU, unless PUT/GET communication is deactivated». La frase riguarda i livelli di protezione legacy. La nostra lettura: con il PUT/GET permesso, il livello di protezione non ferma un partner remoto che comunica con quei blocchi.

Con firmware V3.1 la casella parte spenta e grigia. Se un pannello o un altro PLC non comunica, la tentazione è spuntarla e andare avanti. Prima di farlo, scrivi quale partner la usa e perché; se nessuno sa rispondere, resta spenta. Per i problemi di comunicazione quando il PUT/GET serve davvero c’è l’articolo GET/PUT S7-1200 non comunica: controlli e soluzioni.

Comunicazione PG/HMI sicura

Da TIA Portal V17 e firmware S7-1500 V2.9 la comunicazione fra CPU, programmatore e pannello può viaggiare in TLS. Si imposta in «Protection & Security > Connection mechanisms», casella «Only allow secure PG/PC and HMI communication». Tre cose da sapere prima di spuntarla:

• una CPU impostata così «can no longer be reached online» da chi usa la comunicazione legacy. Verifica prima che il pannello del tuo impianto la supporti, poi spunta;
• un progetto creato con TIA precedente a V17 e caricato su una CPU V2.9 si comporta come una CPU V2.8: il TLS non arriva da solo cambiando la CPU;
• quando il certificato scade, la connessione sicura da pannello o PG non si stabilisce più.

La password dei dati di configurazione riservati

Esiste da STEP 7 V17 e protegge le chiavi private e gli altri dati riservati della configurazione. Se la perdi e la azzeri, i certificati di web server, OPC UA e comunicazione PG/HMI possono dover essere ricreati. Si imposta in «Protection & Security > Protection of the PLC configuration data»; le regole sulle password stanno in «<nome progetto> > Security settings > Settings», area «Password policies». Da V21 con firmware V4.1 puoi estenderla all’intera configurazione: in quel caso serve la password anche per caricare in STEP 7 da una memory card.

Qui il problema non è la forza della password, è chi la conserva. Quattro fatti dal manuale di comunicazione:

• la stessa password su un gruppo di CPU è ammessa, ma se ne viene compromessa una sono esposte tutte;
• con firmware V4.1 un backup fatto con «Online > Load backup from online device» si ripristina solo con la stessa password usata quando è stato creato;
• il job «SET_PWD» scrive la password in chiaro in un file sulla memory card; il manuale chiede di custodire la card in un posto sicuro;
• una CPU di ricambio non dovrebbe arrivare con una configurazione o una password già impostate.

La nostra lettura: questa password fa parte del backup di progetto. Va nel gestore password condiviso dell’impianto, accanto al progetto TIA, e la conoscono almeno due persone con nome e cognome. Una password lunga nella testa di una persona sola vale meno di una password decente scritta nel posto giusto, perché il giorno del ripristino quella persona può non esserci. Il tema del ripristino è trattato nell’articolo su backup di PLC e HMI per ripartire dopo un ransomware.

Know-how protection e copy protection: il codice, non l’accesso

Secondo il manuale di sistema del 2014, senza password restano leggibili titolo, commenti, proprietà e interfaccia del blocco, e si possono ancora copiare, cancellare, richiamare, confrontare online/offline e caricare. Lo stesso manuale lo dice al contrario: impostare un livello di accesso non sostituisce la know-how protection. Le due cose si sommano, non si scambiano.

La copy protection lega i blocchi al numero di serie della memory card, e il blocco gira solo con quella card inserita. Il manuale del 2014 indica l’ordine: prima la copy protection, poi la know-how protection sullo stesso blocco, altrimenti la copy protection si può azzerare. Il percorso di menu non è nelle fonti usate: cercalo nella documentazione della tua versione.

E la password del programma safety?

È un’altra cosa. I manuali Siemens usati per questo articolo non la trattano, quindi non ne descriviamo il funzionamento. Chi cerca quella password trova due pagine dedicate: la guida sulla password del DB safety su S7-1500 e quella sulla password del DB safety su S7-1200. Per il recupero delle password su S7-1200 c’è anche l’articolo su come eliminare la password di un S7-1200. Qui si parla di come non doverle recuperare.

Scenario d’esempio: la Linea P1

La Linea P1 è un impianto di fantasia: una linea di pallettizzazione con una CPU S7-1500 a 192.168.10.10, un pannello HMI Comfort a 192.168.10.20, due periferie ET 200SP a 192.168.10.31 e 192.168.10.32, due switch, un laptop di servizio a 192.168.10.100 e un gateway di accesso remoto a 192.168.10.2. Nello scenario il progetto è in TIA Portal V19 e la CPU ha firmware V3.1.

Il resto della configurazione P1: PUT/GET disattivato, perché nello scenario nessun partner lo usa; password dei dati di configurazione riservati propria di questa CPU e non condivisa con altre linee, custodita nel gestore password dell’impianto con il responsabile di linea e il suo sostituto. Gli utenti del pannello, quelli che l’operatore usa sul Comfort, sono un’altra lista con altre regole: se ne parla in come creare gruppi utenti sugli HMI Siemens con WinCC.

Come lo controlliamo noi

Queste prove non vengono dal manuale: sono il nostro modo di verificare. Si fanno in banco o in messa in servizio, mai su un impianto in produzione.

• Dal laptop 192.168.10.100 senza login, un download sulla CPU deve essere rifiutato. Con l’utente manut.p1 pure. Con prog.p1 deve passare.
• Controlla se i tentativi di accesso compaiono nel buffer diagnostico: il manuale del 2014 lo documenta per le password dei livelli, non per il login UMAC.
• Con PUT/GET disattivato, un client che legge variabili via comunicazione S7 PUT/GET deve ricevere un errore.
• Il ripristino di un backup, su una CPU di prova, con la password dei dati riservati presa dal gestore password e non dalla memoria di qualcuno.

Cosa NON fare

• Lasciare Anonymous con Full access «solo per l’avviamento». Le linee guida operative Siemens chiedono di cambiare le password predefinite in messa in servizio; lo stesso vale per gli accessi aperti per comodità.
• Usare la stessa password dei dati riservati su tutte le CPU dello stabilimento. Il manuale lo permette e dice anche cosa succede se ne esce una.
• Contare sulla know-how protection per impedire il download. Non lo fa.
• Spuntare PUT/GET per far comunicare qualcosa senza sapere chi lo usa.
• Lasciare nel quadro la memory card con il job SET_PWD: contiene la password in chiaro.

Limiti di questo articolo

• Le voci segnate «manuale 2014» vengono dal manuale di sistema S7-1500 di quell’anno: la sostanza regge, i nomi dei menu possono essere cambiati. Gli altri percorsi sono dei manuali 11/2025: su V20 o su una V21 aggiornata diversamente, controllali sulla tua installazione.
• Non sappiamo se in V20 e V21 il collegamento pannello-CPU supporti gli utenti nominali. In V19 no.
• Password del programma safety, aggiornamento firmware e secure boot restano fuori.

Fonti

• Siemens, User Management & Access Control with TIA Portal V19, application example 109973173, V1.0, 07/2024.
• Siemens, S7-1500, ET 200MP, ET 200SP Communication Function Manual, A5E03735815-AN, 11/2025.
• Siemens, S7-1500 Web server Function Manual, A5E53797648-AB, 11/2025.
• Siemens, S7-1500/ET 200MP System Manual, A5E03461182-AC, edizione 12/2014 (datata).
• Siemens, CPU 1518-3 PN Equipment Manual, A5E53640193-AA, 11/2024.
• Siemens, Cybersecurity for Industry – Operational Guidelines, versione 2.2.1, aprile 2024.

Ultimo controllo: 29 settembre 2026

Dott. Strongoli Alessandro

“Semplifica, automatizza, sorridi: il mantra del programmatore zen.”

Dott. Strongoli Alessandro

Programmatore
CEO IO PROGRAMMO srl