Protecting Patients through Background Checks
Technical Architecture Specification
Background Check System
IT Technical Design Guide
Version 01
2/19/2015
Table of Contents
1 Overview 4
2 Physical Architecture Overview 4
2.1 System Architecture 5
2.2 External Network 6
2.3 DMZ Network 6
2.4 Internal Network 6
2.5 Data Interchange 6
3 Hardware and Software Requirements 7
3.1 Database Server 7
3.2 Application/Web Server 7
3.3 Server Sharing 8
3.4 Virtualization 8
4 Development Guidelines 8
4.1 Development Platform 8
4.2 ASP.NET MVC 9
4.3 Razor View Engine 9
4.4 Knockout 9
5 Deployment Guidelines 10
5.1 Target Deployment Platform 10
5.2 Deployment Responsibilities 10
6 Security 11
6.1 User Authentication 11
6.2 User Authorization 12
6.3 Database Encryption 12
7 Communication 13
7.1 Database 13
7.2 Physical Security 13
1 Overview
This document describes the high-level architecture and design of the core Background Check System (BCS), making customizations for each National Background Check Program (NBCP) grantee State. This document discusses a generic architecture that can be tailored to meet State-specific network security requirements and other needs. This architecture will support the grantee State agency and external users in executing the background check process for applicants seeking direct access employment in the long term care industry. This includes supporting tasks such as entering applicants, checking public registries, conducting criminal background checks, and tracking employment.
This document may be used to gain consensus among State information technology (IT) stakeholders regarding the customization and deployment of the BCS. The document provides a description of the physical architecture for BCS customization, features used to control access by external users, recommended hardware and software, guidelines for customization, and target deployment.
2 Physical Architecture Overview
The figure on the following page illustrates the physical architecture of the core system, which can be customized. The figure also shows features that can be used to control access by external users and facilitate data imports.
2.1 System Architecture
2.2 External Network
The external network is terminated by the perimeter firewall, which is responsible for limiting access to the application. Only secure HTTP traffic (i.e., HTTPS traffic) is allowed through, to ensure all communication to and from the system is over an encrypted channel. If using Secured File Transmission Protocol (SFTP) for file transmissions, the port for the SFTP is opened only to the SFTP server for the Registry Providers that drop data updates. (See Section 2.5 below.)
2.3 DMZ Network
The DMZ (or demilitarized zone) Network houses the externally facing servers. Hosts in the DMZ are configured on the DMZ virtual local area network (VLAN) and subnet. These include the Application servers and the SFTP servers. The Application servers are behind a network load balancer in a web farm configuration. This provides high availability (HA) and maximizes the throughput of the system. To scale out the application, more servers have been added to the web farm. Servers in the DMZ Network have very limited access to servers in the Internal Network. Application servers are only able to communicate over the designated database ports to the database servers in the Internal Network.
2.4 Internal Network
The Internal Network is the most secure and includes database servers and any other server(s) that should not be externally facing. Hosts in the Internal Network are configured on the Internal VLAN and subnet. Servers in the Internal Network do not have access to the External Network and have very limited access to machines in the DMZ Network. Databases in this network encrypt data before it is written to disk. Database HA Clustering is used to provide redundancy at the database level. A Database Integration Server is responsible for performing data transformations from flat-file data dumps from Registry Providers and importing the data into the Application Database.
2.5 Data Interchange
2.5.1 Web Services
For Registry Providers that provide access to their data through web services, the application queries the web services in real time. Data from the Registry Provider is only kept for the lifetime of the application request and is never stored in the Application Database unless otherwise directed. The request to the web services is sourced from the particular server in the farm that is handling the application request, so access to the web services needs to be open for all servers in the web farm.
2.5.2 Data Push
For Registry Providers that provide access to their data through data exports, an SFTP server is used. On a regular basis, the Registry Provider connects to the SFTP server within the DMZ Network and transfers the data files over an encrypted connection. Then, a scheduled job runs on the Database Integration Server to pull the latest data files from the SFTP server and process them through a data transformation service. This data transformation extracts the data needed and then imports that data into the Application Database. This data is stored encrypted inside the Application Database.
3 Hardware and Software Requirements
The following hardware and software is recommended for implementation of the BCS.
3.1 Database Server
· Windows Server 2008 R2
· Microsoft SQL Server 2008 R2 (Service Pack 2)
· CPU: 4+core 3.0+GHz
· 16+ GB ECC RAM
· 50-100 GB hard drive space
· Enterprise (to take advantage of transparent data encryption)
3.2 Application/Web Server
· Windows Server 2008 R2 (Service Pack 1)
· CPU: 4+core 2.5+GHz
· 4+ GB RAM
· 20+ GB hard drive space
· IIS 7+
3.3 Server Sharing
Although it is technically possible to host the system on a single server, this is not recommended since it would imply that the database is in the DMZ and not protected behind a firewall. A dedicated server is not absolutely required, but is highly recommended. For a development environment, sharing the same server is acceptable.
3.4 Virtualization
The database server can be shared on a server that contains multiple production databases. Virtualization, however, is not recommended for the database server. For production purposes, we recommend that the database server be located on a physical machine. The web server can be shared on a web server that contains other websites within the Internet Information Services and could reside within a virtual machine.
4 Development Guidelines
This section describes in detail aspects of the development platform.
4.1 Development Platform
· Database: SQL Server 2008 R2 (Service Pack 2)
o SQL Server Reporting Services (SSRS)
· Development IDE: Visual Studio 2012 (2010 is also supported)
o C#
o Business Intelligence Development Studio (BIDS: RDL development)
o Entity Framework 4.1
o Enterprise Library 5.0 (Data, Logging, Exception Handling)
· ASP.NET MVC 3.0
o Razor View Engine
o JQuery 1.11+
o JQuery UI 1.10+
o Knockout 2.3+
4.2 ASP.NET MVC
The Microsoft ASP.NET MVC framework is a lightweight, highly testable presentation framework that is integrated with existing ASP.NET features. Some of the more commonly cited advantages of using the MVC framework (rather than legacy Web Forms) are that it:
· Enables clean separation of concerns,
· Enables full control over the rendered HTML,
· Has no ViewState or PostBack events,
· Has an SEO (Search Engine Optimization) and REST (Representational State Transfer) friendly URL,
· Enables test-driven development,
· Follows the stateless nature of the Web,
· Provides an extensible and pluggable framework,
· Allows for easy integration with JavaScript frameworks, and
· Is an ideal platform for Web 2.0 applications.
More information on ASP.NET MVC framework can be accessed at: http://www.asp.net/mvc/overview/getting-started/what-is-aspnet-mvc.
4.3 Razor View Engine
Razor View Engine is used due to its ease-of-use, implicit encoding, and improved readability.
4.4 Knockout
Knockout is a JavaScript library that extends the MVC paradigm to the client browser. Knockout is a separate utility currently used with MVC 3.0 in BCS technical architecture. Knockout is included in MVC 4.0. More information can be accessed at http://knockoutjs.com/.
5 Deployment Guidelines
This section describes the target deployment platform from which the BCS is developed. It also discusses deployment responsibilities.
5.1 Target Deployment Platform
· Microsoft .NET Framework 4.0+
· IIS 7.0
· SQL Server Database 2008 R2
· SSRS
· SQL Server Integration Services (SSIS)
· Client Browser Support
o IE 8+
o Firefox 10+
o Safari 5+
· Simple Mail Transfer Protocol
5.2 Deployment Responsibilities
· The grantee State agency or its designee will manage all aspects of deployment environments.
· CNA will provide:
o The Deployment Guide documentation to facilitate source installation in a local State machine;
o A source code package;
o BCS Application, database, task service, reporting (SSRS), and SSIS;
o Knowledge transfer; and
o General guidance on deployment.
· CNA will not have access to production environments.
6 Security
The purpose of this section is to describe BCS security models.
6.1 User Authentication
The BCS uses forms authentication for users against credentials stored in the Application Database. User passwords are salted and hashed using strong one-way encryption, which implies that they cannot be recovered. An administrator uses the Reset Password function to generate an email with a new password when needed.
Passwords are subjected to the following policies:
· A configurable number of invalid password entries (default is three) causes the user's account to be locked until he or she is unlocked by a system administrator.
· Passwords must be changed at a configurable interval (default is 90 days).
· A previously used password cannot be reused.
· Passwords must be complex. The password rules are configurable, but in the default configuration, passwords must meet the following conditions:
o Length between 8 and 16 characters,
o Contain at least one uppercase character and one lowercase character,
o Contain at least one number, and
o Contain at least one symbol.
· The system can be configured to cause user-created and auto-generated passwords to expire in a defined number of days. Once expired, the system requires the user to change the password.
· The system requires the user to change an auto-generated password upon the first login.
6.2 User Authorization
BCS users are authorized via a customizable, permission-driven, role-based security model.
Permissions are defined within the BCS for tasks that require explicit authorization. Permissions are flagged as eligible for State users, provider users, or both.
A role is a set of permissions that can be granted to a user. For example, a role named Provider_DataEntry could be defined as the permissions granted to a provider employee who is doing data entry of new applicants—the role would only include the permissions necessary for this task. In addition, provider users only have access to data associated with their own organizations. Administrators are able to add permissions to roles and assign roles to users.
6.3 Database Encryption
The BCS accesses its application database(s) using SQL Server authentication. An application account is created and granted permissions to the database entities it requires (lowest level of authorization for performing its job duties). These account credentials are stored in the .config file(s) where they are encrypted by the system administrator using the aspnet_regiis.exe utility.
The BCS uses two levels of encryption in order to secure the data. SQL Server 2008 R2 Enterprise edition is used to implement full database encryption for all data, as well as an additional level of field-level encryption for the data specifically covered by CJIS security requirements. The two levels of encryption use separate encryption keys.
6.3.1 Transparent Data Encryption (TDE)
Transparent data encryption (TDE) is the method used by SQL Server 2008 to encrypt the entire database. TDE performs real-time I/O encryption and decryption of both the data and the log files. The encryption uses a database encryption key (DEK), which is stored in the database boot record for availability during recovery. The DEK is a symmetric key secured by using a certificate stored in the master database of the server.
Once TDE is enabled on a user database, all backups are also encrypted. TDE protects data "at rest”, meaning that if someone is able to get access to the physical data file or backup file, they will not be able to load the database and gain access to the data.
TDE is designed to be as transparent as possible. No application changes are required and the user experience is the same whether using a TDE-encrypted database or a non-encrypted database.
TDE is implemented with encryption algorithms that are Advanced Encryption Standard (AES) with 256bit keys.
6.3.2 Cell / Column Level Encryption
The BCS also implements field-level encryption. In SQL Server 2008, this process is referred to as cell-level or column-level encryption. Data elements within the application that are identified as requiring CJIS level security are encrypted and decrypted using built in database encryption functions. A separate encryption key is used for field-level encryption in addition to the TDE DEK. If TDE is ever destroyed or subverted, the data protected by the cell level encryption would still be safe.
7 Communication
The BCS requires all access to the web application to be secured using SSL/HTTPS. The State is responsible for the configuration and management of certificates.
7.1 Database
The BCS accesses its application database(s) using SQL Server authentication. An application account is created and granted permissions to the required database entities. These account credentials are stored in the .config file(s) where they can be encrypted by the system administrator using the aspnet_regiis.exe utility. The following roles are assigned to the SQL Server login:
· db_datareader
· db_datawriter
· db_executor
Using a ‘sa’ or ‘dbo’ type of an account is not recommended.
7.2 Physical Security
The physical security of the BCS is the responsibility of the State or the web-hosting company managing the hardware and access to the hardware.
Technical Architecture Specification Page 13 of 13
Version 01 | 2/19/2015 | IT Technical Design Guide | Audience: State IT Staff