Overview - Protecting Vulnerable Populations Through ...
Technical Architecture SpecificationBackground Check SystemIT Technical Design GuideVersion 01 SAVEDATE \@ "M/d/yyyy" \* MERGEFORMAT 2/19/2015Table of Contents TOC \o "1-2" \u 1Overview PAGEREF _Toc411930287 \h 42Physical Architecture Overview PAGEREF _Toc411930288 \h 42.1System Architecture PAGEREF _Toc411930289 \h 52.2External Network PAGEREF _Toc411930290 \h 62.3DMZ Network PAGEREF _Toc411930291 \h 62.4Internal Network PAGEREF _Toc411930292 \h 62.5Data Interchange PAGEREF _Toc411930293 \h 63Hardware and Software Requirements PAGEREF _Toc411930294 \h 73.1Database Server PAGEREF _Toc411930295 \h 73.2Application/Web Server PAGEREF _Toc411930296 \h 73.3Server Sharing PAGEREF _Toc411930297 \h 83.4Virtualization PAGEREF _Toc411930298 \h 84Development Guidelines PAGEREF _Toc411930299 \h 84.1Development Platform PAGEREF _Toc411930300 \h 84. MVC PAGEREF _Toc411930301 \h 94.3Razor View Engine PAGEREF _Toc411930302 \h 94.4Knockout PAGEREF _Toc411930303 \h 95Deployment Guidelines PAGEREF _Toc411930304 \h 105.1Target Deployment Platform PAGEREF _Toc411930305 \h 105.2Deployment Responsibilities PAGEREF _Toc411930306 \h 106Security PAGEREF _Toc411930307 \h 116.1User Authentication PAGEREF _Toc411930308 \h 116.2User Authorization PAGEREF _Toc411930309 \h 126.3Database Encryption PAGEREF _Toc411930310 \h 127Communication PAGEREF _Toc411930311 \h 137.1Database PAGEREF _Toc411930312 \h 137.2Physical Security PAGEREF _Toc411930313 \h 13OverviewThis 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.Physical Architecture OverviewThe 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.System ArchitectureExternal NetworkThe 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.)DMZ NetworkThe 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.Internal NetworkThe 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.Data InterchangeWeb ServicesFor 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.Data PushFor 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.Hardware and Software RequirementsThe following hardware and software is recommended for implementation of the BCS.Database ServerWindows Server 2008 R2Microsoft SQL Server 2008 R2 (Service Pack 2)CPU: 4+core 3.0+GHz16+ GB ECC RAM50-100 GB hard drive spaceEnterprise (to take advantage of transparent data encryption)Application/Web ServerWindows Server 2008 R2 (Service Pack 1)CPU: 4+core 2.5+GHz4+ GB RAM20+ GB hard drive spaceIIS 7+Server SharingAlthough 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.VirtualizationThe 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.Development GuidelinesThis section describes in detail aspects of the development platform.Development PlatformDatabase: SQL Server 2008 R2 (Service Pack 2)SQL Server Reporting Services (SSRS)Development IDE: Visual Studio 2012 (2010 is also supported)C#Business Intelligence Development Studio (BIDS: RDL development)Entity Framework 4.1Enterprise Library 5.0 (Data, Logging, Exception Handling) MVC 3.0Razor View EngineJQuery 1.11+JQuery UI 1.10+Knockout 2.3+ MVCThe Microsoft MVC framework is a lightweight, highly testable presentation framework that is integrated with existing 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, andIs an ideal platform for Web 2.0 applications.More information on MVC framework can be accessed at: View EngineRazor View Engine is used due to its ease-of-use, implicit encoding, and improved readability.KnockoutKnockout 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 GuidelinesThis section describes the target deployment platform from which the BCS is developed. It also discusses deployment responsibilities.Target Deployment PlatformMicrosoft .NET Framework 4.0+IIS 7.0SQL Server Database 2008 R2SSRSSQL Server Integration Services (SSIS)Client Browser SupportIE 8+Firefox 10+Safari 5+Simple Mail Transfer ProtocolDeployment ResponsibilitiesThe grantee State agency or its designee will manage all aspects of deployment A will provide:The Deployment Guide documentation to facilitate source installation in a local State machine;A source code package;BCS Application, database, task service, reporting (SSRS), and SSIS;Knowledge transfer; andGeneral guidance on A will not have access to production environments.SecurityThe purpose of this section is to describe BCS security models.User AuthenticationThe 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:Length between 8 and 16 characters,Contain at least one uppercase character and one lowercase character,Contain at least one number, andContain 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.User AuthorizationBCS 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.Database EncryptionThe 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.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.Cell / Column Level EncryptionThe 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 municationThe 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.DatabaseThe 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_datareaderdb_datawriterdb_executorUsing a ‘sa’ or ‘dbo’ type of an account is not recommended.Physical SecurityThe physical security of the BCS is the responsibility of the State or the web-hosting company managing the hardware and access to the hardware. ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- step by step exercises
- program helloworld
- trojan source invisible vulnerabilities
- web services tutorial
- title feb 49 38 am 1 of 24
- serial ports and com ports selecting a port
- keyboard shortcuts visual studio code
- microsoft terraserver a spatial data warehouse
- overview protecting vulnerable populations through
- revit 2009 getting started autodesk
Related searches
- man protecting woman
- how many populations in the world
- trityl protecting group
- frontline and vulnerable communities
- through and through gunshot wound
- protecting yourself from evil spirits
- song about protecting someone
- who is responsible for protecting cui
- song about protecting others
- songs about protecting something
- songs about protecting the environment
- songs about protecting nature