The T2S Dedicated Link solution. Connectivity Workshop 27 February S. Orsini, B. Giangregorio, D. Bernabucci Banca d Italia (4CB)

Transcription

1 The T2S Dedicated Link solution Connectivity Workshop 27 February 2012 S. Orsini, B. Giangregorio, D. Bernabucci Banca d Italia (4CB) 1

2 Disclaimer The following slides summarize the envisaged implementation of the T2S Dedicated Links Connectivity Services. Network connectivity is out of the scope of this presentation. Proof of Concepts with VANs providers (SWIFT and SIA-COLT) are in progress. Consequently some optimizations and fine tunings of Data Exchange Protocol (DEP) are expected; the final version of the protocol will be made available at the end of the PoCs. All pictures are just given as an example and are not intended to be exhaustive of all options. 2

3 AGENDA 1. OVERVIEW 2. CONNECTIVITY SERVICES 3. VALUE ADDED CONNECTIVITY SERVICES 3

4 1. OVERVIEW Connectivity options DiCoA 1 DiCoA 2 DiCoA 3 DiCoA 4 DiCoA 5 VA-NSP 1 VA-NSP 2 CORENET Region 1 SITE A SITE C Region 2 SITE B SITE D 4CB Network BdE SITE E SITE F Region 3 4

5 1. OVERVIEW Recovery management - principles No changes or update of configuration shall be requested to the DiCoAs in case of the following events: Periodical rotation between Region 1 and Region 2; Local recovery (swap of sites within a Region); Regional recovery (swap of Regions); and during the recovery/rotation tests. 5

6 1. OVERVIEW Recovery management - DNS T2S DiCoA DNS cache CPE Site A root DNS DNS cache DNS cache CPE CPE PE PE DNS CORENET DNS PE PE PE PE CPE CPE DNS cache Site B DNS cache root DNS Site C DNS cache CPE = IBM WebSphere Site D 6

7 1. OVERVIEW Capacity Planning DiCoAs shall provide theirs capacity planning breakdown data to T2S in order to size and configure the T2S interface for incoming and outgoing traffic. Any deviation (e.g. new workload figures, changes in the daily traffic profile) shall be communicated in due time to T2S to adjust the configuration. 7

8 AGENDA 1. OVERVIEW 2. CONNECTIVITY SERVICES Application to application (A2A) 3. VALUE ADDED CONNECTIVITY SERVICES A2A - Scenarios A2A - Data Exchange Protocol (DEP) A2A - W connection User to application (U2A) 8

9 2. CONNECTIVITY SERVICES A2A scenarios The communication T2S - DiCoA via VA-NSPs VAN Protocol W Data Exchange Protocol (DEP) The communication T2S - DiCoA via CORENET W Data Exchange Protocol (DEP) 9

10 2. CONNECTIVITY SERVICES A2A - Data Exchange Protocol (DEP) T2S VA-NSP 1 DiCoA1 W -DEP W M Q VAN protocol CORENET W -DEP DiCoA2 10

11 2. CONNECTIVITY SERVICES A2A scenarios VA-NSPs provide three level of services: Pure connectivity services (network level); DEP translation and handling; Value Added Connectivity Services (e.g. real time, store and forward, Closed Group of Users, PKI, timeout management, size management, nonrepudiation). CORENET provides : Pure connectivity services (network level). Value Added Connectivity Services are provided by T2S 11

12 2. CONNECTIVITY SERVICES A2A - Data Exchange Protocol (DEP) Sender and receiver information in the Technical Header are used to perform network addressing and are based on the distinguished name (DN) of the digital certificate The Business Header contains the signature of the business information made with the end-user certificate DEP TECHNICAL INFORMATION BUSINESS INFORMATION TECHNICAL HEADER Sender, Receiver, Service Name, Technical Signature,. BUSINESS HEADER.. Business Signature,. BUSINESS AREA Message or file payload MESSAGE/FILE 12

13 2. CONNECTIVITY SERVICES A2A - W connection DiCoA DiCoA DiCoA DiCoA DiCoA DiCoA GW VA NSP 1 GW VA NSP 2 z/os Middlew are Middleware Middlew are Middleware Middlew are Middleware Middlew are Middleware The policy used to connect to T2S follows the rules reported below: Each DiCoA connected via CORENET or VA-NSP provider has its own dedicated set of channels Each set of channels is composed by: - At least a couple of channels (incoming and outgoing from T2S) for each message/file flow - Channels dedicated to technical acknowledgement for each message flow Connectivity is protected by SSL with mutual authentication based on digital certificates provided by T2S AF Access Facade AF Access Facade AF Access Facade AF Access Facade APPL APPL APPL APPL 13

14 2. CONNECTIVITY SERVICES A2A - W connection T2S Server-Server DiCoA1 T2S Server-Client DiCoA1 DiCoA1.in.L01 DiCoA1.out.R 01(xmitq) RCVR SDR DiCoA1.MRT.IN.RCV. 01 DiCoA1.MRT.OUT.SEN.0 1 SDR DiCoA1.out.R01 (xmitq) RCVR DiCoA1.in.L01 DiCoA1.in.L01 DiCoA1.out.L0 1 SRVCONN SRVCONN DiCoA1.MRT.IN.SRV.0 1 DiCoA1.MRT.OUT.SRV.0 1 API DiCoA2 DiCoA2 DiCoA2.in.L01 DiCoA2.out.R 01(xmitq) RCVR SDR DiCoA2.MRT.IN.RCV. 01 DiCoA2.MRT.IN.SEN.0 1 SDR RCVR DiCoA2.out.R01 (xmitq) DiCoA2.in.L01 DiCoA2.in.L01 DiCoA2.out.L0 1 SRVCONN SRVCONN DiCoA2.MRT.IN.SRV.01 DiCoA2.MRT.OUT.SRV.0 1 API Both configuration are supported by T2S For availability and recovery reason T2S suggests to use W server-server communication mode Client-server communication is supported as well, but in this case is out of the responsibility of T2S the loss of messages due to connection failure or bad management of commit phase from client side 14

15 2. CONNECTIVITY SERVICES A2A - W naming convention Channels ccc.mmmm.ddd.ttt.nn ccc connector identifier(van/dicoa) mmmm messaging service identifier ddd direction ttt Type nn number example: DC1.MRT.IN.SRV.01 Queues cbbl.ddd.xxxxxxxxxx.ttnn cbb VAN name/dicoa l logical environment (optional) ddd direction xxxxxxxxxx name suggested by application supplier (eg. Messaging service) tt queue type nn progressive number (optional) example: DC1.IN.MSG_RT.SHnn 15

16 2. CONNECTIVITY SERVICES A2A - W security SSL connection W z/os DiCoA DN=DiCoA DiCoA.MRT.IN.SRV.01 DiCoA.MRT.OUT.SRV.01 incoming outgoing DiCoA.MRT.IN.RCV.01 Channel definition SSL certificate required. : Yes Userid: DiCoA DiCoA.IN.L01 SSL peer name : CN=DiCoA.net.eac,OU=Servizi di certificazione dei sistemi informatici - Collaudo,O=Banca d'italia Collaudo,C=it DiCoA.OUT.L01 PUTAUTH:OnlyMCA MCAUSER:DiCoA DN=T2S Channel initiator Queue Manager VAN1 DN=VAN VAN.MRT.IN.SRV.01 incoming VAN.MRT.IN.SRV.01 Channel definition SSL certificate required. : Yes SSL peer name : CN=van.net.eac,OU=Servizi di certificazione dei sistemi informatici - Userid:VAN Collaudo,O=Banca d'italia Collaudo,C=it PUTAUTH:OnlyMCA MCAUSER:VAN VAN.IN.L01 VAN.OUT.L02 VAN.MRT.OUT.SRV.01 outgoing DN=T2S 16

17 2. CONNECTIVITY SERVICES User to application (U2A) The T2S shall provide for U2A the following services: enabling web traffic between the T2S users workstations and the T2S platform; exchanging data using HTTPs protocol; identifying and authenticating the T2S users via digital certificates used to establish the HTTPs session with the T2S platform. 17

18 AGENDA 1. OVERVIEW 2. CONNECTIVITY SERVICES 3. VALUE ADDED CONNECTIVITY SERVICES Store and Forward Real Time Closed User Group Throttling PKI Non-repudiation 18

19 3. VALUE ADDED CONNECTIVITY SERVICES Store and Forward VA-NSP T2S Request Tech.Ack CORENET DiCoA1 Guaranteed delivery of messages the VAN provider stores the messages received by the sender and controls the delivery of message to the receiver. Controlled by the following parameters : Retry 10 times to send the message to the receiver in case of missing technical ack within 10 minutes Storing messages for 14 days in case of unavailability of the receiver dep:deliverynotification flag enables the reception of a DeliveryNotification messages with the status of the exchange (failed or successful) EnableSnfTraffic DisableSnfTraffic DEP primitives used to control the SnF service 19

20 3. VALUE ADDED CONNECTIVITY SERVICES Store and Forward For DL connection, the store-and-forward service can be implemented in two ways (excluding the retry in case of missing acks that must be implemented) depending on the W connection chosen by the DiCoA: 1. server-server W connection 2. client-server W connection SnF functions are implemented inheriting partially inheriting W basic W functionalities basic functionalities integrated Store by messages the sender in client the transmission application queues is similar to the function provided Store messages by the VAN in the that client stores application messages in provides case of a unavailability similar function of the to store receiver messages in case of unavailability of the receiver Confirm on Delivery report can be checked by the sender in case of needs and it can replace the usage of dep:deliverynotification flag Availability of channels (in running or stopped status) can replace the usage of EnableSnfTraffic DisableSnfTraffic DEP primitives used to control the SnF services 20

21 3. VALUE ADDED CONNECTIVITY SERVICES Real Time T2S CORENET Request Tech.Ack Response Tech.Ack DiCoA1 Real time messaging service is based on the following parameters : request-response chain must be completed in 60 seconds: in case that the response production is not finished within the 60 seconds, then the communication should be interrupted request-response chain is normally done on the same messaging services (e.g. request and response sent via MSGRT service). In case that the response size doesn t fit the request messaging service, then the response need to be sent via another messaging service to the receiver Based on this two limitation the timeout management and oversize management functions are developed by T2S 21

22 3. VALUE ADDED CONNECTIVITY SERVICES Real Time Timeout management In order to heal the timeout limit (60 seconds), T2S applies an effective protocol. T2S defines a timeout limit that anticipates the RT timeout limit. If the processing of a response takes longer than the T2S timeout limit the transfer mode of the response changes from real-time to store and forward. T2S process steps: 1. a RT response is sent to the DiCoA containing Inbound Processing Rejection ReceiptAcknowledgement and indicating that a T2S timeout occurred anyway the request is still in process; 2. when the data is available, the response is sent in store and forward mode to the the DiCoA (sender). 22

23 3. VALUE ADDED CONNECTIVITY SERVICES Real Time Oversize management if the response to a request on the message channel is over the size limit (32KB), the file Store and forward channel is used. T2S process steps: 1. a RT response is sent to the DiCoA containing an Inbound Processing Rejection ReceiptAcknowledgement in real-time mode indicating the change of the transfer mode; 2. the response is sent in store and forward mode. 23

24 3. VALUE ADDED CONNECTIVITY SERVICES Closed User Group Technical infrastructure for Closed User Group (CUG) to segregate traffic are implemented at different layers in T2S (transport network is out of the scope of VACS): Firewall; W ; DEP protocol; T2S middleware. 24

25 3. VALUE ADDED CONNECTIVITY SERVICES CUG-logical view DiCoA 1 T2S CPE CPE EAC MIG1 MIG2 UTEST DiCoA 2 EAC PE PE CPE MIG1 MIG2 CPE PE CORENET PE UTEST DiCoA 3 PE PE PE CPE PROD CPE CPE PROD 25

26 3. VALUE ADDED CONNECTIVITY SERVICES CUG - Firewalls A basic IP filtering is implemented on the T2S firewalls although any distinction between different environment (Production vs Test and Training). 26

27 3. VALUE ADDED CONNECTIVITY SERVICES CUG - W segregation Separation between Test and Training vs Production environments. Test and Training environments and Production run in different regions (i.e. different data center). A W instance is dedicated to each logical environment. Each W instance uses different TCP ports. Each DiCoA has its own dedicated set of W resources in T2S (channels and queues). The DiCoA authentication is based on digital certificates exchanged in a SSL session. The DiCoA authorization to access the relative dedicated set of queue is achieved checking the DN in the digital certificate (that contains the logical environment too). 27

28 3. VALUE ADDED CONNECTIVITY SERVICES CUG - DEP segregation dep:technicalserviceid <mandatory tag> Name of the service used to send messages and files, formed by the Network Service Provider name, the message pattern and the environment of reference. Specifying a message pattern, it s possible to manage a message or a file as a payload of the DEP message. Message pattern meaning is the following: MSGRT: Real Time Message; MSGSNF: Store & Forward Message; FILERT: Real Time File; FILESNF: Store & Forward File. Restriction is set on base type "string [60]", with expression in the format: [NSP_name].[msg_pattern].[environment] where msg_pattern= {MSGRT MSGSNF FILERT FILESNF} and environment= {EAC UTEST MIG1 MIG2 PROD }. <dep:technicalserviceid> nsp-name1.msgrt.prod </dep:technicalserviceid> 28

29 3.The Value Added Connectivity Services CUG T2S middleware implementation T2S checks the ExchangeHeader content during the reception process of messages through the following tags dep:technicalserviceid is checked to verify the correct addressing of message against the specific logical environment dep:sender is controlled to verify that the DiCoA is delivering messages with the proper technical sender identifier. 29

30 3. VALUE ADDED CONNECTIVITY SERVICES Throttling DiCoA Middleware Middleware Middleware DiCoA DiCoA Middleware AF APPL DiCoA DiCoA Throttling mechanism is used to avoid that single user can overload the system. Exclusion of single DiCoA can be performed by closing the dedicated channel 30

31 3.The Value Added Connectivity Services CUG U2A Identity and Access Management In U2A a IAM infrastructure will be provided for strong authentication of users based on smart card or USB token. DN of certificates registered in the Static Data are periodically imported in IAM directory. IAM will control the validity of the certificate and checks that the certificate DN is in the IAM directory. IAM directory are segregated per environment. 31

32 3. VALUE ADDED CONNECTIVITY SERVICES Public Key Infrastructure (PKI) T2S will deliver a PKI compliant to the ISO standard and to the EU Directive. It provides the following functions: Registration Authority; Key Generation; Certificate Management; Certificate validation. T2S will provide interface to the PKI services to T2S platform and T2S actors. Digital certificates will be stored in smart card/usb token (U2A) and in HSM (A2A). 32

33 3. VALUE ADDED CONNECTIVITY SERVICES PKI Digital Keys used in U2A scenario T2S platform HTTPS protocol CORENET T2S DiCoA Digital key used by T2S for server authentication Digital key used by DiCoAs for user authentication 33

34 3. VALUE ADDED CONNECTIVITY SERVICES Digital keys used in A2A scenario T2S platform DEP SSL protocol CORENET DiCoA Digital keys used to authenticate the channel Digital key used by DiCoA to sign DEP (technical header and technical ack) Digital key used by T2S to sign DEP (technical header and technical ack) and business information (business header) Digital key used by T2S DiCoA to sign business information 34

35 3. VALUE ADDED CONNECTIVITY SERVICES PKI Provisioning of certificates The identification of users will be managed by the T2S Registration Authority. With regard to certificates for individual users, private and public keys are generated in T2S premises during the process of producing the smartcard/usb token and the certificate. Regarding application certificates, private and public keys ( key pairs ) are generated on the HSM at the DiCoA site; the T2S PKI will be responsible of generating the related certificate. 35

36 3. VALUE ADDED CONNECTIVITY SERVICES PKI Certificate issuance process Roles: Security Officer at DiCoA initiates the process for requesting new certificates The T2S service desk ensures the identification of the user and deliver the smart cards and certificates to the users The T2S service desk acts as Registration authority and interacts with T2S CA administrators. T2S CA administrators produce the smart cards or USB tokens and generate the certificates. 36

37 3. VALUE ADDED CONNECTIVITY SERVICES PKI - Certificate issuance process for individual users T2S Certificate issuance process for individual users DiCoA T2S Service desk T2S PKI Admin. Define the users Fill in the forms Formal check yes Send the forms filled in to the NCB Receive the forms Approve the request Evaluate the forms and ensure the identification of the user Generate the certificates Forms ok yes Register the request in the RA web application Prepare the PKI kit (smart card, documentation, PIN, PUK, ) no Request the missing information 37

38 3. VALUE ADDED CONNECTIVITY SERVICES PKI - Certificate issuance process for apps and devices T2S Certificate issuance process for applications and devices DiCoA T2S Service Desk T2S PKI Admin. Define the user (Institution or device name) Receive the forms Fill in the forms Send the forms filled in to the NCB Evaluate the forms Forms ok no Request the missing information yes Forward the forms to the T2S PKI Admin. Formal check yes Send Reference Number to the T2S Service Desk Generate keys and Certificate Signing Request using the Reference Number Send a Certificate Signing Request to the T2S Service Desk Receive and install the certificate Forward the reference number to the DiCoA Forward the Certificate Signing Request to T2S PKI Admin Forward the certificate to the DiCoA Enroll the certificate 38

39 3. VALUE ADDED CONNECTIVITY SERVICES PKI CRL and non repudiation During verification of signature DiCoA shall verify certificates against the CRL of the T2S PKI CA T2S will provide CRL proxy to allow DiCoA to access the CRL via the CORENET. Non repudiation of emission and receipt is foreseen in case of messages with dep:non-repudiation flag in Exchange header 39

40 3. VALUE ADDED CONNECTIVITY SERVICES PKI - Non repudiation (1/2) Incoming messages (Store and Forward service) B-MSG [NRO] DEP: NRE T2S platform TECH-ACK DEP: NRR 2 CORENET 1 T2S DiCoA T2S NR log DEP T2S DiCoA NR log 1 DiCoAs send business message with signature for NRO to T2S using DEP-Protocol with NRE option (NR flag in technical header and signature of message with DiCoA key) 2 T2S sends TECH-ACK to DiCoA including receiving time and signature for NRR of T2S 40

41 3. VALUE ADDED CONNECTIVITY SERVICES PKI - Non repudiation (2/2) Outgoing messages (Store and Forward service) B-MSG [NRO] DEP: NRE 1 T2S platform CORENET 2 TECH-ACK DEP: NRR T2S DiCoA T2S NR log DEP T2S DiCoA NR log 1 2 T2S sends businsess message to DiCoA with T2S signature for NRO using DEP-Protocol with NRE option (NR flag in technical header and signature of message with T2S key) DiCoA sends TECH-ACK to T2S with a signature for NRR 41

42 Q & A 42