COMUNICAZIONE DEI SISTEMI DI BORDO CON LA INTRANET TRENITALIA

Transcript

1 DIREZIONE INGEGNERIA SICUREZZA E QUALITA DI SISTEMA Viale Spartaco Lavagnini, FIRENZE Identificazione n Esp. 00 Pagina 1 di 12 COMUNICAZIONE DEI SISTEMI DI BORDO CON LA INTRANET TRENITALIA Il presente documento è di proprietà di. Nessuna parte di questo documento può essere riprodotta, memorizzata, trasmessa in qualsiasi forma e/o con qualsiasi mezzo di registrazione salvo approvazione scritta di: TRENITALIA S.p.A. DIREZIONE INGEGNERIA SICUREZZA E QUALITA DI SISTEMA

2

3 INDICE 1 GENERALITA Scopo Campo di applicazione NORME DI RIFERIMENTO DEFINIZIONI E ACRONIMI PROTOCOLLI AMMESSI SERVER DI TRASFERIMENTO DATI PERIFERICI (STP) Requisiti architetturali Requisiti funzionali Requisiti funzionali generali FTP/S server Trasferimento file da bordo verso STP Trasferimento file da STP a bordo Web server Trasferimento dati da STP a server centrale Trasferimento dati da server centrale a STP SERVER DI TRASFERIMENTO DATI GPRS (STG) SERVER APPLICATIVI CENTRALI (SC) NAMING CONVENTION DEL SISTEMA DI BORDO MODALITÀ DI CONNESSIONE Generalità sulle modalità di connessione Connessioni di accesso remoto tramite GPRS-UMTS Connessioni tramite Wireless LAN Priorità delle connessioni ACCESSO AI SERVER TI (STP, STG, SC) Generalità sull accesso ai server TI Accesso ai server di trasferimento dati (STP,STG) Accesso ai server centrali (SC) ACCESSO AL WEB SERVER DI BORDO Codice identificazione: n Esp. 00 Pagina 3 di 12

4 1 GENERALITA 1.1 Scopo La presente specifica definisce le linee guida e i requisiti tecnici necessari per consentire l autenticazione, l autorizzazione e l accesso per lo scambio dati fra i dispositivi mobili installati sui rotabili e la rete informatica di, con l obbiettivo di garantire la sicurezza e l interoperabilità fra i servizi forniti. 1.2 Campo di applicazione La specifica si applica per i servizi di gestione della flotta da parte di TRENITALIA che necessitano di scambiare informazioni con la intranet aziendale. Tali sistemi di gestione sono costituiti dalla comunicazione da bordo a terra e viceversa. Fanno parte delle comunicazioni da bordo a terra le seguenti applicazioni: Scarico a terra dei dati diagnostici; Scarico a terra dei dati giuridici e di condotta; Radiolocalizzazione; Aggiornamento dei sistemi di bordo (FW, configurazione ecc.). Fanno parte delle comunicazioni da terra a bordo le seguenti applicazioni: Trasmissione a bordo di informazioni di viaggio (dati di percorso, coincidenze reali, ecc.); Aggiornamento dei sistemi di bordo (FW, configurazione ecc.); Upload a bordo di contenuti multimediali; Controllo da remoto dello stato dei sistemi di bordo. Codice identificazione: n Esp. 00 Pagina 4 di 12

5 2 NORME DI RIFERIMENTO EN ST RFC1180 Railway applications Electronic equipment used on rolling stock Specifica generale per le apparecchiature elettroniche di segnale A TCP/IP Tutorial RFC2131 The Dynamic Host Configuration Protocol (DHCP) RFC2132 DHCP Options and BOOTP Vendor Information Extensions IEEE 802.1x IEEE b/g Port Based Network Access Control Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - DSSS, HR-DSSS 2.4 GHz 3 DEFINIZIONI E ACRONIMI Acronimo APN CHAP DIS FQDN GPRS-R GSM-R PAP PPP RTID SIM SC STG STP SSID TP WLAN Descrizione Access Point Name Challenge-Handshake Authentication Protocol Driver Information System Fully Qualified Domain Name GPRS -Railway GSM-Railway Password Authentication Protocol Point to Point Protocol Running Train IDentifier Subscriber Identity Module Server applicativo Centrale Server di Trasferimento dati Gprs Server di Trasferimento dati Periferico Service Set Identifier Train Profile Wireless local area network Codice identificazione: n Esp. 00 Pagina 5 di 12

6 4 PROTOCOLLI AMMESSI Indipendentemente dal tipo di connettività utilizzata, il protocollo usato per il trasporto è il TCP/IP (rif. RFC1180); sono ammessi i soli protocolli applicativi ftp, ftps, http, https. In particolare sul sistema di bordo devono essere presenti i seguenti servizi: http/https server Sul Server Periferico devono essere presenti i seguenti servizi: http/https server ftp/ftps server Sul Server Centrale di ciascuna applicazione devono essere presenti i seguenti servizi: http/https server ftp/ftps server I servizi devono utilizzare esclusivamente le porte standard. Ove richiesto dalla particolare applicazione, il mutuo riconoscimento sicuro fra il sistema di bordo ed i server a terra deve essere effettuato mediante i servizi https o ftps. 5 SERVER DI TRASFERIMENTO DATI PERIFERICI (STP) 5.1 Requisiti architetturali Per server di trasferimento dati periferico si intende un server che permetta il collegamento con il sistema di bordo mediante uno o più Access Point WLAN ad esso collegati. Ogni STP dispone di 2 interfacce di rete, una collegata verso la intranet aziendale e l altra verso gli AP; la rete locale che collega il STP con gli AP deve essere di classe fast ethernet e separata a livello OSI 2 dalla intranet. Tutti i servizi esposti sulla rete WLAN devono essere realizzati con accorgimenti tali da ridurre al massimo la latenza verso gli apparati di comunicazione di bordo. Il canale di comunicazione da/per il server periferico garantisce un flusso dati minimo di 500Kbit/sec. 5.2 Requisiti funzionali Requisiti funzionali generali Il sistema di bordo, per accedere ai servizi sul STP (ftp/s, http/s) deve autenticarsi tramite gli stessi nome utente, nome dominio e password definiti al par 9.2. L autenticazione deve avvenire tramite meccanismi di mutuo riconoscimento sicuro e le credenziali di accesso in nessun caso devono essere trasmesse in chiaro. Sui STP non devono essere installati programmi o servizi del produttore dell'apparato di bordo che devono invece risiedere sul solo Server Centrale (SC) di ciascuna applicazione. Eventuali funzionalità richieste sul STP (dall applicazione o dalla specifica implementazione del fornitore) devono essere realizzate esclusivamente tramite il web server del STP (par.5.2.5). Codice identificazione: n Esp. 00 Pagina 6 di 12

7 5.2.2 FTP/S server Il server ftp/s presente sui STP deve supportare i comandi XCRC e XMD5 di controllo integrità del file, i servizi di crittografia SSL di comandi e dati e la funzione di resume. Per ciascuna applicazione (es DIS, PIS, diagnostiche etc..) e/o tipologia di flotta deve essere riservata una specifica cartella al disotto della root ftp/s. Eventuali cartelle necessarie all applicazione (ad es. legate al fornitore, all upload/download etc.) devono essere figlie della suddetta cartella. La definizione dell albero delle cartelle deve essere concordata con Trasferimento file da bordo verso STP Tutti i file scaricati dal sistema di bordo verso il server ftp/s del STP devono essere verificati calcolando a bordo l hash MD5 e confrontandolo con quello ottenuto dal server ftp/s (comando XMD5). Solo dopo il completamento della suddetta verifica il file può essere marcato a bordo come trasferito correttamente a terra (ed eventualmente cancellabile); in caso contrario deve essere nuovamente trasmesso e verificato. L utilizzo in alternativa dell algoritmo CRC32 e del comando XCRC deve essere proposto dal fornitore ed accettato da Trasferimento file da STP a bordo Tutti i file caricati dal sistema di bordo dal server ftp/s devono essere verificati calcolando a bordo l hash MD5 e confrontandolo con quello ottenuto dal server ftp/s (comando XMD5). Solo dopo il completamento della suddetta verifica il file può essere considerato valido; in caso contrario deve essere nuovamente caricato e verificato. L utilizzo in alternativa dell algoritmo CRC32 e del comando XCRC deve essere proposto dal fornitore ed accettato da Web server Il server http/https installato sui STP deve supportare l esecuzione di ASP, JSP e CGI. Per ciascuna applicazione (es DIS, PIS, diagnostiche etc..) deve essere riservato uno specifico percorso (URL) immediatamente al disotto della root del web server (es. Eventuali percorsi necessari all applicazione (ad es. legati al fornitore, all upload/download etc.) devono essere figli del suddetto percorso (es. La definizione dell albero dei percorsi deve essere concordato con. L utilizzo del server http/https del STP per il trasferimento di file bordo-terra e viceversa deve essere proposto dal fornitore ed accettato da Trasferimento dati da STP a server centrale Sui STP devono essere presenti uno o più servizi che trasferiscano via ftp i dati dalle cartelle specifiche di ciascuna applicazione verso i rispettivi server centrali. Tale trasferimento deve avvenire calcolando localmente l hash MD5 e confrontandolo con quello ottenuto dal server ftp del server centrale (comando XMD5). Solo dopo la suddetta verifica il file può essere spostato in altra cartella locale contenente i file correttamente trasmessi; in caso contrario deve essere nuovamente trasmesso e verificato Trasferimento dati da server centrale a STP Sul server centrale di ciascuna applicazione deve essere presente un servizio che trasferisca via ftp i dati nella cartella specifica dei STP. L elenco dei server periferici deve essere definito da una lista di distribuzione presente sul server centrale. Tale trasferimento deve avvenire calcolando sul server centrale l hash MD5 e confrontandolo con quello ottenuto dal server ftp del STP (comando XMD5). Qualora detta verifica fallisca il file deve essere nuovamente trasmesso e verificato. Codice identificazione: n Esp. 00 Pagina 7 di 12

8 6 SERVER DI TRASFERIMENTO DATI GPRS (STG) Anche se installato centralmente, il server di trasferimento dati GPRS può essere considerato un caso particolare di STP, con la differenza che l accesso al server avviene tramite il collegamento GPRS-UMTS. 7 SERVER APPLICATIVI CENTRALI (SC) I server applicativi centrali contengono tutti i programmi e servizi del fornitore necessari alla particolare applicazione. I server web e ftp presenti sui SC devono avere le stesse caratteristiche già definite per i STP. L accesso ai server centrali deve sempre avvenire tramite il nome host o alias del server e mai direttamente tramite IP. La verifica delle credenziali per l accesso ai servizi web dei SC deve essere integrata nei sistemi di autenticazione di. Ad es. sul web server del SC devono essere presenti delle pagine in cui l utente, correttamente riconosciuto, possa essere reindirizzato sul web server di bordo di ciascun rotabile con il corretto livello di accesso (es. visione, manutenzione, configurazione, amministrazione etc.). 8 NAMING CONVENTION DEL SISTEMA DI BORDO Il nome host del sistema di bordo deve essere univoco e deve essere composto come di seguito indicato: identificativo di 12 caratteri corrispondenti al campo Nome Rotabile del DIS, seguito da 6 caratteri che identificano ciascuno le applicazioni supportate. Detta stringa deve essere accettata da per la valorizzazione dei 6 caratteri finali. 9 MODALITÀ DI CONNESSIONE 9.1 Generalità sulle modalità di connessione Le modalità di connsessione possono essere quelle di seguito indicate: accesso remoto tramite GPRS-UMTS; connessione tramite Wireless LAN. Nella figura 1 sono schematizzate tutte le modalità di connessione alla intranet. Di seguito sono decritte le procedure di accesso per i diversi canali di comunicazione (GPRS-UMTS e connessionewifi). Codice identificazione: n Esp. 00 Pagina 8 di 12

9 Figura 1 Modalità di connessione 9.2 Connessioni di accesso remoto tramite GPRS-UMTS La connessione deve essere effettuata all attivazione del veicolo e deve essere mantenuta sempre attiva. La tipologia di modem (GSM-GPRS, GSMR-GPRS, EDGE, UMTS, HSDPA) ed il tipo di sim (RFI o pubblica) da utilizzare devono concordati con. Nel caso di interruzione accidentale della sessione di accesso remoto, il sistema deve provvedere a ristabilire automaticamente la sessione. Devono essere presi tutti gli accorgimenti del caso per evitare la generazione di traffico involontario sulla sessione attiva. La tipologia di autenticazione (es. CHAP o PAP) deve essere concordata con. L autenticazione deve essere eseguita su un APN specifico per ogni tipologia di SIM da concordare con (ad es. "apparati.trenitalia.it" per le sim RFI). I dati necessari all autenticazione sono forniti da e consistono in: nome utente nome dominio password numero da chiamare (ad es. *99#) eventuali comandi addizionali Codice identificazione: n Esp. 00 Pagina 9 di 12

10 Tali informazioni possono essere specifiche per ciascuna SIM fornita. Al termine del processo di autenticazione, conclusosi con esito positivo, il sistema deve ottenere dal DHCP un indirizzo IP valido e registrarsi sul DNS comunicato dal DHCP. La registrazione sulla rete aziendale e le azioni successive sono dettagliate al capitolo Connessioni tramite Wireless LAN Il sistema di bordo deve potersi collegare con i STP mediante connessione di rete LAN mista b e g. I livelli di protezione del collegamento con gli AP devono essere concordati con. L'SSID della rete WLAN transita sulla rete in modalità offuscata e deve essere concordato con. Il sistema di bordo deve quindi ottenere dal DHCP un indirizzo IP e registrarsi sul DNS comunicato dal DHCP. La registrazione sulla rete aziendale e le azioni successive sono dettagliata al capitolo 10. Il sistema di bordo deve poter iniziare le operazioni di trasferimento dati con il STP entro 5 secondi dalla disponibilità della connettività di rete (a livello OSI 2). Tale parametro può essere valutato misurando il tempo fra l associazione con l AP ed il trasferimento di un pacchetto campione da 10KB. 9.4 Priorità delle connessioni Un analisi dei volumi di traffico previsti per GPRS-UMTS e WLAN deve essere proposta dal fornitore ed accettata da. I dati valutati voluminosi da devono essere trasmessi esclusivamente tramite WLAN. La connessione GPRS deve essere effettuata all attivazione del veicolo e deve essere mantenuta sempre attiva, come descritto al par.9.2. Qualora venga rilevata la presenza della rete WLAN prevista, il sistema di bordo deve comunicare tramite WLAN come descritto al par.9.3 ed al capitolo 10, in particolare risolvendo nuovamente il nome host del STP-STG tramite il DNS ottenuto dal DHCP della connessione WLAN e registrando il proprio nome host sullo stesso DNS. Nel momento in cui si verifichi la mancanza della rete WLAN, il sistema di bordo deve ripristinare tutte le condizioni di esercizio della connettività GPRS, come descritto al par.9.2 ed al capitolo 10, in particolare risolvendo nuovamente il nome host del STP-STG tramite il DNS ottenuto dal DHCP della connessione Gprs-Umts e ri-registrando il proprio nome host sullo stesso DNS. 10 ACCESSO AI SERVER TI (STP, STG, SC) 10.1 Generalità sull accesso ai server TI Il sistema di bordo deve acquisire dal DHCP server, fra le altre, anche le seguenti informazioni: indirizzo IPv4 del client subnet mask default gateway indirizzi ip DNS primario e, se presente, secondario nome del dominio (campo opzionale 015) Codice identificazione: n Esp. 00 Pagina 10 di 12

11 Lease time dell indirizzo IP dinamico (campo opzionale 051) Al DHCP server che ha erogato l indirizzo, durante la negoziazione, deve essere anche fornito il nome host (univoco) del sistema di bordo (capitolo 8). A seguito della conclusione con successo della negoziazione DHCP, il sistema di bordo deve provvedere alla registrazione (con l apposito protocollo di registrazione) del proprio nome host sul DNS (ricevuto dal DHCP) nel dominio (sempre ricevuto dal DHCP) Accesso ai server di trasferimento dati (STP,STG) Tutti i Server di trasferimento dati (STP e STG) sono identificati dai medesimi alias sulla rete che devono essere risolti localmente dai DNS in modo da puntare ai server fisici corretti. Gli alias possono essere specifici in funzione delle applicazioni implementate dal sistema di bordo, come nell esempio che segue: IP dei Server fisici Alias WLAN B1 WLAN A WLAN B2 WLAN C GPRS DNS Locale A DNS Locale B DNS Locale C DNS centrale IP (stpa) IP (stpb1) IP (stpc1) IP (stg1) t-stp1diag t-stp1diag t-stp1diag t-stp1diag t-stp1pis t-stp1pis IP (stpc2) IP (stg2) t-stp1dis IP (stpb2) t-stp1pis t-stp1pis t-stp1ncd t-stp1dis IP (stpc3) t-stp1dis t-stp1ncd t-stp1dis t-stp1ncd IP (stpc4) t-stp1ncd L alias del STP e STG deve essere un parametro di configurazione della particolare applicazione del sistema di bordo e deve essere concordato con. L alias deve essere completato dal postfisso nome del dominio, componendo il nome FQDN che il sistema di bordo deve risolvere tramite DNS. Es: alias STP-STG: nome dominio: nomeserverfqdn: t-stp1teledi servizi.trenitalia.it t-stp1teledi.servizi.trenitalia.it 10.3 Accesso ai server centrali (SC) Ciascun Server Centrale (specifico di una particolare applicazione) è identificato sulla rete mediante un nome host o un alias univoco. L alias del SC deve essere un parametro di configurazione della particolare applicazione del sistema di bordo, e deve essere concordato con. L alias deve essere completato dal postfisso nome del dominio, componendo il nome FQDN che il sistema di bordo deve risolvere tramite DNS. Codice identificazione: n Esp. 00 Pagina 11 di 12

12 alias SC: nome dominio: nomeserverfqdn: t-sc1teledi servizi.trenitalia.it t-sc1teledi.servizi.trenitalia.it La comunicazione diretta con i server applicativi centrali può essere garantita mediante la sola connessione GPRS-UMTS, sempre nel rispetto di quanto indicato al capitolo 4. Tale comunicazione deve essere documentata nel dettaglio dal fornitore. 11 ACCESSO AL WEB SERVER DI BORDO Il web server di bordo deve avere come default la pagina di accesso. Il collegamento al web server deve avvenire collegandosi direttamente al nome host del sistema di bordo definito al cap.8 (es Dopo che è stata stabilita la connessione WLAN per almeno 5 minuti continuativi, il sistema di risoluzione aziendale garantisce la corretta risoluzione del nome del sistema di bordo (secondo l indirizzo corrispondente all interfaccia WLAN). Qualora siano trattate informazioni vitali o riservate, l autenticazione e la sessione sul sistema di bordo deve avvenire su canale sicuro (es: https). Le credenziali (nome utente e password) accettate dal sistema di bordo devono essere concordate con. Devono essere previste diverse credenziali per tutti i diversi livelli di accesso richiesti dal sistema (es. visione, manutenzione, configurazione, amministrazione etc..). Codice identificazione: n Esp. 00 Pagina 12 di 12