Architettura generale. Se al momento dell’approvazione di un PAP residenziale per l’accesso alla RSA in modulo base non vi è disponibilità di titoli di acquisto, l’utente titolare del PAP è collocato in una lista di priorità, nella posizione determinata dal punteggio risultante da apposita scheda allegata al PAP.
Architettura generale. L’offerente dovrà realizzare un sistema integrato basato su piattaforma web che includa le seguenti componenti: - un sistema di gestione e produzione dei contenuti (CMS), composto almeno dai seguenti moduli: o un portale accessibile dalla rete internet, che consenta la consultazione dei bollettini, da rendere disponibili anche in formato navigabile, e che metta a disposizione funzionalità avanzate di ricerca all’interno dell’archivio. Attraverso il portale, previa registrazione e autenticazione dell’utente (privato cittadino o dipendente di un ente pubblico), sarà possibile inserire un annuncio utilizzando appositi form che consentano anche il pagamento online dell’inserzione. L’utente dovrà poter accedere allo storico delle inserzioni da lui inviate, con viste elenco e di dettaglio;
Architettura generale. L’infrastruttura che eroga il servizio di protezione è posizionata all’interno del backbone IP pubblico di TIM. Questo ambiente rappresenta un sistema autonomamente consistente nella gestione dei protocolli di routing e ciò rende particolarmente efficace l’interazione tra gli apparati di rete che compongono il backbone e quelli dedicati al servizio di protezione, permettendo la variazione dinamica dei flussi di traffico che è alla base dei meccanismi di reazione alla presenza di un attacco DDoS. Le tecnologia scelta per l’implementazione del servizio è Arbor Networks, leader di mercato. All’’interno dell’ infrastruttura di rete TIM sono state definite alcune aree di “cleaning”, dette Security Farm, interamente ridondate, dedicate all’erogazione del servizio DDoS. La posizione delle Security Farm è stata individuata anche in funzione della vicinanza ai punti di interconnessione internazionale dai quali provengono la maggior parte degli attacchi. In condizione di normale erogazione dei servizi sulla rete pubblica, i flussi di traffico vengono gestiti dal backbone IP e indirizzati al centro servizi nel quale sono ospitati i sistemi destinazione. Nel caso specifico il traffico è indirizzato verso i sistemi realizzati dalle Amministrazione nei Data Center dello RTI mediante i servizi IaaS (VM e VDC) e/o PaaS acquisiti nell’ambito della convenzione SPC Cloud Lotto 1. La figura seguente mostra in generale l’architettura di funzionamento in assenza di attacchi.
Architettura generale. L’infrastruttura tecnologica del sistema e-Learning necessita di un’architettura completamente Web, così composta: L’accesso al sistema “Learning Channel” dovrà avvenire in due modalità in base alla tipologia di utenti: accesso da parte di utenti già registrati alla piattaforma ESP e accesso da parte di utenti non registrati alla piattaforma ESP. In tutti e due i casi, con l’Access Manager, si gestirà la definizione del profilo dell’utente consentendo sia di distinguere gli studenti dai docenti/tutor/amministratori, sia di strutturare la stessa tipologia di utenti (es. eventuale suddivisione degli studenti per struttura organizzativa, per livello gerarchico, per competenze, ...). Nei casi in cui l’utente del sistema sia già autenticato alla piattaforma ESP, l’applicazione non richiederà ulteriori step di riconoscimento ma, in modo completamente automatico, interfacciandosi con l’Access Manager, imposterà il cookie di connessione e procederà con l’accesso al Learning Channel in base al profilo dell’utente (single sign on). In caso di utente esterno, previa registrazione al LMS, l’identificazione sarà gestita direttamente dall’Access Manager.
Architettura generale. Con riferimento agli elaborati grafici facenti parte della documentazione progettuale, il sistema è basato su una serie di componenti tra loro integrati per realizzare le funzioni di localizzazione del veicolo, controllo e comando degli scambi, asservimento semaforico, sia a supporto del conducente del tram che per supervisionare da un’unica postazione centralizzata il regolare svolgimento dell’esercizio lungo le linee, consentendo una gestione centralizzata ed ottimizzata dell’esercizio tramviario. Il sistema utilizza come supporto trasmissivo una rete in fibra ottica (Gigabit Ethernet) che collega il PCC a tutti i siti periferici (fermate SSE) e una rete Radio a standard Tetra per il collegamento tra il PCC e i singoli veicoli in Linea. Lungo la linea sono localizzate Unità di Comunicazione terra/bordo, dotate di loop induttivi, connesse alla Rete in Fibra ottica. Tramite tali loop saranno effettuate la rilevazione della presenza dei tram in fermata, la richiesta di preferenziazione semaforica e il comando degli scambi. L’intero sistema è concepito per essere “ a sicurezza intrinseca”. Nel caso in cui, infatti, nonostante gli elementi di sicurezza introdotti nella trasmissione, dovesse fallire la comunicazione bordo - terra, non si verificherebbero mai condizioni di pericolo, ma verrebbero solo a mancare le condizioni per la realizzazione delle funzionalità richieste: • non verrebbe visualizzato il transito del veicolo sul sinottico del PCC; • non si realizzerebbe l’asservimento semaforico; • non si realizzerebbe la commutazione degli scambi. In tutti i casi, comunque, si avrebbero condizioni di esercizio alterato o ritardato, ma non si peggiorerebbero le condizioni di sicurezza generali, dato che, rispettivamente: • i segnali tranviari non concederebbero il via libera al tram, causando la fermata dello stesso; • il macchinista dovrebbe imporre lo spostamento dello scambio in modo manuale, mediante la leva meccanica. I futuri veicoli tramviari dovranno essere equipaggiati con una Unità di Bordo in grado di gestire le comunicazioni radio, tramite unità radio Tetra, le comunicazioni induttive, tramite una apposita unità di comunicazione con antenna, e di interfacciare gli apparati di bordo per informazioni al pubblico, di realizzare tutte le logiche necessarie a supporto della operatività e di gestire la console a disposizione del conducente. Il tram in servizio, alla rilevazione di un loop, dovrà trasmettere il proprio identificativo alla Unità di Comunic...
Architettura generale. L’architettura ECaaS/CCaaS è funzionalmente suddivisa in tre livelli (planes) che supportano il classico modello Supply/Delivery/Demand delle piattaforme Cloud. • Il Back plane fornisce le risorse infrastrutturali (IaaS) necessarie ad ogni istanza ECaaS/CCaaS e di fatto coincide con la piattaforma Cloud SPC, basata su OpenStack. • Il Core plane implementa le funzionalità fondamentali che erogano i servizi basati su tecnologia Containers (Containers Orchestration), la loro gestione (Delivery Management) e la connessione con funzioni per lo sviluppo di servizi applicativi basati su incapsulamento a Containers (CI/CD pipeline instances). • Il Front plane permette agli utenti finali di accedere e fruire i servizi offerti dalla piattaforma, tramite una console (dashboard) sia in modalità diretta (utente) che programmatica (a mezzo di funzioni API). I vari moduli architetturali sono costituiti da diversi prodotti/soluzioni software (pressoché basati su progetti open source) integrati tra loro opportunamente usando chiamate API. Tutti questi moduli sono incapsulati in Containers per cui la stessa piattaforma ECaaS/CCaaS è di fatto realizzata usando la stessa tecnologia offerta per i servizi erogati. Come già anticipato la piattaforma OpenStack SPC-Cloud fornisce l’accesso alle risorse IaaS necessarie all’ECaaS/CCaaS. In particolare ogni istanza ECaaS fa uso di due tenant OpenStack. Il primo ❶ per ospitare le risorse virtuali contestualizzate in un VDC, utili a istanziare la piattaforma di gestione ❷ e fornire i nodi iniziali del cluster ❸; questi nodi corrispondono a VM le cui dimensioni (numero di virtual CPU e RAM) sono ottimizzate per un impiego in un cluster Docker. Un secondo tenant ❹, sempre basato su VDC, ospita gli eventuali nodi computazionali aggiuntivi necessari, sempre usati dal cluster Docker ❺; le VM hanno la stessa configurazione del primo tenant ma sono destinate ad un uso flessibile (consumo orario) per poter sfruttare in modo efficace le necessità di “flessione” computazionale dei servizi secondo un modello di capacity on demand. I nodi aggiuntivi (del cluster Docker), rispetto a quelli iniziali, sono associati sempre al secondo tenant. Le risorse XxxX previste per un’istanza CCaaS o ECaaS: • Macchine virtuali di base: o ECaaS: ▪ 10 VM per la parte di management ▪ 4 VM per il cluster Docker o CCaaS: ▪ 7 VM per la parte di management ▪ 2 VM per il cluster Docker • Macchine virtuali aggiuntive per cluster Docker a consumo: numero variabile in funz...