Transcript Solution Overview - NHS Connecting for Health

Clinical Dashboards
HTTPS Security Solution
18 November 2009
SmartCard Security
1.
Requirements
•
2.
Statement of Requirements
Overview
•
Pre-Requisites & Configuration
3. Implementation
•
Plan
4. Impact
•
•
Solution Overview
User Interface
Appendices
•
•
•
SSL – How It Works
Guidance on Creating an HTTPS Domain Certificate
System C – Documentation & Contact
2
1. Requirements
Statement of Requirements – Security
Pilot Requirement 3.3.5.1
The Pilot technology solution must provide a browser based thin client user interface that is standards based. The
following standards should be supported: a) HTTP1.1, b) HTMLV4.01, and c) TLS1.0.
Connecting for Health Requirement
The requirement from NHS CFH is that all sensitive data is protected in transit if there is any possibility that the
patient sensitive data could be intercepted and its confidentiality impacted:
• Transfer of clinical data over the N3 network requires the data to be protected ‘in transit’. N3 is a 'private'
network but it is not secure and there are no guarantees of confidentiality for data transmitted over it. This
could be done either by encrypting the data prior to transmission or sending the data over an encrypted link.
• Transfer of clinical data over the Trust network also requires the data to be protected ‘in transit’. How the data
is protected is one for the Trust to determine in line with published guidance such as the Department of Health
Information Security Management: Code of Practice, official statute such as the Data Protection Act, and the
Connecting for Health - Infrastructure Security – Good Practice Guide.
To bring this about all Clinical Dashboard solutions are required to use a secure infrastructure based on public-key
cryptography by using digital certificates with technologies such as Transport Sockets Layer (TLS 1.0 / SSL).
3
1. Requirements
Secure Socket Layer (SSL) is a security protocol used to protect your information when you send and receive
sensitive data. SSL always uses HTTPS the secure HTTP protocol. It has private and public key for encryption
and decryption of the data.
This document provides an overview of what is required to setup such an environment for the Medway Sigma BI
based solution.
N.B. If a Trust feels that it is not necessary to ensure the security of the data then CfH would need:
(i) a statement from the Trust confirming that their network is configured in line with published guidance such as
the Department of Health Information Security Management: Code of Practice, official statute such as the Data
Protection Act, and meets the requirements documented in the Connecting for Health - Infrastructure Security –
Good Practice Guide,
and
(ii) a Risk Assessment to determine the risks to sensitive information they hold and whether any additional
controls or countermeasures are required to protect that data signed-off by their Caldicott Guardian.
4
2. Overview
Pre-Requisites & Configuration
Medway Sigma BI can be configured to use it as an extra layer of protection to encrypt data (patient data in
particular) when running reports or viewing Dashboards via a web browser.
Domain Certificates
Certificates are required for both the Sharepoint and Reporting Services servers. There are two approaches to
obtaining certificates can be used:
1. Using an internal only domain based certificate authority typically that associated with the Active Directory
Domain (see Appendix). This will not work if any external access (access from outside the domain/network)
is required.
2. An Internet Trusted certificate authority service (e.g. http://www.verisign.co.uk/ssl/index.html) to generate a
Public Certificate. These certificates have a cost associated with them and have to be renewed every two
years (e.g. VeriSign® Secure Site SSL Certificates).
Validity Period
Price
1-year
£259 excl.
2-year
£399 excl. VAT
3-year
£525 excl. VAT
The Medway Sigma BI solution requires a wildcard certificate e.g. *.dashboard.sch.com
N.B. For any site implementing SmartCard Access for the Clinical Dashboard via the Microsoft
Intelligent Application Gateway a certificate will also be required for the IAG Appliance.
5
2. Overview
Pre-Requisites & Configuration
The following activities need to be completed to implement HTTPS communications for the Sharepoint and
Reporting Services server(s).
Configure ‘Host(A)’ record entries on your DNS for SigmaBI:
•To point ‘reports.dashboard.fqdn' at the Application Server’s IP address for Reporting Services
•To point ‘sharepoint.dashboard.fqdn' at the Application Server’s IP address for the SharePoint site
•To point ‘perfpoint.dashboard.fqdn' at the Application Server’s IP address if PerformancePoint is used in the
Dashboard
Create Service Principle Names for the service account (HDMSQL):
•setspn - A http/reports.dashboard.fqdn domain\HDMSQL
•setspn - A http/sharepoint.dashboard.fqdn domain\HDMSQL
•setspn - A http/perfpoint.dashboard.fqdn domain\HDMSQL (if applicable)
Implement a Group Policy to add the following URLs to each Sigma BI Dashboard users Local Intranet Zone in their
Browser settings:
•‘https://reports.dashboard.fqdn’ ‘https://sharepoint.dashboard.fqdn’
•‘https://perfpoint.dashboard.fqdn’ (if applicable)
Change any existing documentation, shortcuts, intranet links and communicate to all Dashboard users the new
URL’s for the Dashboards and planned downtime. Note that existing favourites or bookmarks will no longer function.
For further details see Medway Sigma BI support documents in the Appendix.
6
3. Implementation
Installation Plan per Site (2 days down time)
Trust (Pre-requisites & Configuration)
•
Obtain HTTPS certificates
•
Configure URL alias names
•
Configure Kerberos service principle names
•
Set Trusted sites for new names
Communicate down time
System C
•
Update the server configurations to support HTTPS and disable HTTP (est. 1/2 day)
•
Configure SharePoint site links (est. 1 day elapsed – multiple developers will have to work concurrently)
•
Testing all pages (est. 1/2 day)
Trust
•
Publicise new URL for Dashboard access
•
Amend and re-issue any user documentation as relevant
•
Revise any links, e.g. intranet, bookmarks, etc
7
4. Impact (Solution Overview)
8
4. Impact (User Interface)
HTTPS Padlock
When browsing to a Dashboard site you can view the padlock symbol in your browser as highlighted below:
HTTP View Certificates
The padlock can be selected to view certificates:
9
4. Impact (User Interface)
HTTPS Certificate Details
The Certificate Details window displays further information about the HTTPS certificate:
1
Appendices
11
SSL – How It Works
Secure Sockets Layer (SSL) technology protects your Web site and makes it easy for your Web site visitors to trust you in three essential
ways:
1. An SSL Certificate enables encryption of sensitive information during online transactions.
2. Each SSL Certificate contains unique, authenticated information about the certificate owner.
3. A Certificate Authority verifies the identity of the certificate owner when it is issued.
You need SSL if...
• you have an online store or accept online orders and credit cards
• you offer a log-in or sign-in on your site
• you process sensitive data such as address, birth date, licence or ID numbers
• you need to comply with privacy and security requirements
• you value privacy and expect others to trust you.
How Encryption Works
An SSL Certificate establishes a private communication channel enabling encryption of the data during transmission. Encryption
scrambles the data, essentially creating an envelope for message privacy. Each SSL Certificate consists of a public key and a private
key. The public key is used to encrypt information and the private key is used to decipher it. When a Web browser points to a secured
domain, a Secure Sockets Layer handshake authenticates the server (Web site) and the client (Web browser). An encryption method is
established with a unique session key and secure transmission can begin.
How Authentication Works
Every SSL Certificate is created for a particular server in a specific domain for a verified business entity. When the SSL handshake
occurs, the browser requires authentication information from the server. By clicking the closed padlock in the browser window or certain
SSL trust marks the Web site visitor sees the authenticated organisation name. In high-security browsers, the authenticated organisation
name is prominently displayed and the address bar turns green when an Extended Validation SSL Certificate is detected. If the
information does not match or the certificate has expired, the browser displays an error message or warning.
Guidance on Creating an
HTTPS Domain Certificate
This supplemental information is provided to sites for them to use as required and gives specific information
on all the steps required to create an internal security certificate for use with an HTTPS Dashboard installation. It requires
a site to have a Domain Certification Authority configured within their network. Advice on creating a Domain Certification
Authority is outside the remit of this guidance.
Alternatively, a site can use a public certificate issued by an External Certification Authority and should
consult the external site’s website for further information as appropriate.
Important: You need to be logged in to the Application Server as a Domain Administrator to have the
appropriate authority to request a certificate.
•
•
•
Launch Server ManagerRolesWeb Server (IIS)
Highlight Server Name and open the Server Certificates IIS Feature
Select ‘Create Domain Certificate’ on the far right of the screen
Guidance on Creating an
HTTPS Domain Certificate
•
Complete the Distinguished Name Properties dialogue box in accordance with the example shown
below substituting your site’s details accordingly. Ensure however that the Common name for the
certificate is set to ‘*.dashboard’ and add the rest of your fully qualified domain name.
•Click Next
•Enter details for your own Certification Authority. If one exists on your domain you can click ‘Select’ to see
the available CAs on a drop down list
•Set the friendly name to the same common name you entered earlier
Guidance on Creating an
HTTPS Domain Certificate
•Click Finish
•The certificate request will be sent to the CA and be returned and available in the server’s ‘Server Certificates’
IIS feature window within minutes.
•You can Right Click on the highlighted certificate to view the Issuing Authority details
Guidance on Creating an
HTTPS Domain Certificate
•The certificate will additionally be stored by default in the personal certificate store of the local computer
•You can see this by selecting StartRunmmcFileAdd/Remove Snap In
•Highlight ‘Certficates’ and Click Add Select Computer Account
•Click ‘Next’ and accept default ‘Local Computer’. Click ‘Finish’ and then ‘OK’
•Expand PersonalCertificates to see the new security certificate in the store
Guidance on Creating an
HTTPS Domain Certificate
•Confirm the site’s issuing Certificate Authority is stored in the Local Computers’ ‘Trusted root certificate authority’
to ensure the certificate will automatically be trusted by clients when they access the site.
•Expand Local Computer Trusted Root Certification AuthoritiesCertificates
System C
Medway Sigma BI Support Documents
Medway Sigma BI – HTTPS
Provides a basic overview of how HTTPS works in the Medway Sigma BI based solution.
Medway Sigma BI – Installation Prerequisites Checklist
An updated checklist that includes the new pre-requisites for HTTPS.
System C Contact
•
Darryl Davies – System C Product Development Manager