Download Technical Architecture Specification - BGCheckInfo

Technical Architecture Specification
Background Check System
IT Technical Design Guide
Version 01
5/12/2017
Protecting Patients through Background Checks
Table of Contents
1
Overview ................................................................................................................................................ 4
2
Physical Architecture Overview .......................................................................................................... 4
3
4
5
6
7
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
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
Development Guidelines ...................................................................................................................... 8
4.1
Development Platform ................................................................................................................... 8
4.2
ASP.NET MVC .............................................................................................................................. 9
4.3
Razor View Engine ........................................................................................................................ 9
4.4
Knockout ........................................................................................................................................ 9
Deployment Guidelines ...................................................................................................................... 10
5.1
Target Deployment Platform ....................................................................................................... 10
5.2
Deployment Responsibilities ....................................................................................................... 10
Security................................................................................................................................................ 11
6.1
User Authentication ..................................................................................................................... 11
6.2
User Authorization ....................................................................................................................... 12
6.3
Database Encryption ................................................................................................................... 12
Communication................................................................................................................................... 13
7.1
Database ..................................................................................................................................... 13
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 2 of 13
Protecting Patients through Background Checks
7.2
Physical Security ......................................................................................................................... 13
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 3 of 13
Protecting Patients through Background Checks
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.
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 4 of 13
Protecting Patients through Background Checks
2.1
System Architecture
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 5 of 13
Protecting Patients through Background Checks
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.
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 6 of 13
Protecting Patients through Background Checks
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+
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 7 of 13
Protecting Patients through Background Checks
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+
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 8 of 13
Protecting Patients through Background Checks
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/.
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 9 of 13
Protecting Patients through Background Checks
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.
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 10 of 13
Protecting Patients through Background Checks
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.
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 11 of 13
Protecting Patients through Background Checks
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 fieldlevel 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
256-bit keys.
Technical Architecture Specification
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 12 of 13
Protecting Patients through Background Checks
6.3.2
Cell / Column Level Encryption
The BCS also implements field-level encryption. In SQL Server 2008, this process is referred to as celllevel 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
Version 01 | 5/12/2017 | IT Technical Design Guide | Audience: State IT Staff
Page 13 of 13