programming4us
         
 
 
SQL Server

Protecting SQL Server Data : CELL-LEVEL ENCRYPTION - Views and Stored Procedures (part 1) - Creating the View

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
3/29/2012 4:11:03 PM
The sensitive data that is contained within the Borrower_Identification table is now protected with cell-level encryption. Our next steps are to create the views and stored procedures via which our users can interact with the Borrower_Identification table. With the inclusion of cryptographic functionality to these objects we will need to pay careful attention to the handling of failed encryption and decryption efforts.

Failed Decryption Handling

Currently, when an attempt to open the symmetric key, and perform decryption, fails due to the user not having the appropriate permissions to the key, the value of NULL is returned. This is not very informative to the end user and does not differentiate a true NULL value from a failed decryption attempt. Therefore, we will present the following requirement:

Requirement 5: Handling unauthorized decryption attempts

When the value of NULL is returned by a failed decryption attempt, it will be replaced with the value " <SECUREDVALUE> ".

Data Modification Handling

Protecting the integrity of the encrypted data that is stored in the database is a critical concern. When a user updates or inserts a row that contains data in our high sensitivity column, the encryption key will need to be opened. If the user has the required permission to use the key, encryption will be applied and the transaction will be committed. However, if the user does not have the necessary permissions to the encryption key, the value that will be captured in the encrypted column will be a value of NULL, resulting in the loss of the value passed to the table.

By restricting insert or update activity to those who have permissions granted to the encryption key, we ensure that the value that is passed to the encrypted column contains valid encrypted data. Based on this observation, we define our final requirement:

Requirement 6: Restricting data modification

Transactions that update or insert rows into a table that contains encrypted columns are to be performed only by the members of roles who have been granted permissions to the corresponding keys. For better control of this requirement all data modifications will occur through stored procedures.

Creating the View

Requirement 2 denies all members of the Sensitive_high, Sensitive_medium and Sensitive_low permission to directly access the tables in our database. Access to the data within our tables is to be gained through views.

The script shown in Listing 1 creates a view called vwBorrower_Identification, which will reflect the columns that are contained within the base table.

The reference to the encrypted column, Identification_Value_E, will utilize the DecryptByKeyAutoCert method to decrypt the data. The DecryptByKeyAutoCert method performs, in a single command, the opening of any symmetric keys protected by the MyHighCert certificate, the decryption of the Identification_Value_E column, including the specified authenticator, and the closing of the symmetric keys protected by the MyHighCert certificate.

If a user who calls this view does not have the sufficient permissions granted to open the symmetric keys that are protected by the MyHighCert certificate, the decrypted value returned will be NULL. The script uses the COALESCE method to instead return a value of <SECURED VALUE>, if decryption fails. This fulfills the requirements of Requirement 5.

Listing 1. Creating the vwBorrower_Identification view.

Please note that we selected to return the column name as Identification_Value since it is a more intuitive name than the underlying Identification_Value_E column name.

The final step in implementing this view is to grant the appropriate permissions to it. In Requirement 6, we specified that all data modification activities would be managed through stored procedures; therefore we will only grant SELECT permissions to the view.

The Borrower_Information table contains four columns, three of which have the sensitivity classification of "Medium". Disclosure of the column that has the sensitivity classification of "High" is managed through the permissions to the symmetric key that decrypts it. There are no columns with the sensitivity classification of "Low"; therefore we will grant SELECT permissions only to the Sensitive_high and Sensitive_medium database roles.

Listing 2. Granting permission to access the view.

Let's now verify that the permissions are effective and that the decryption performs as expected. As described earlier, we'll use EXECUTEASUSER to impersonate a user that is a member of the Sensitive_high database role, a user that is a member of the Sensitive_medium database role and a user that is a member of the Sensitive_low database role, as shown in Listing 3.

Listing 3. Verification of permissions to vwBorrower_Identification.

The result of this verification will reflect that rows were returned for the queries from the Sensitive_high and Sensitive_medium members; but since permissions did not exist for the Sensitive_low member the actual rows will not be returned. Instead the following will appear:



The permissions set for this view are not to be confused with the permissions set to the keys that are used to encrypt and decrypt. These permissions are reflected through the actual results that come from the execution of this view. For example, the WOLFBA user will have the decrypted version of the encrypted data appearing in their results; while the KELLEYWB user will see the value " <SECURED VALUE> " in the sensitive column.

Other -----------------
- Protecting SQL Server Data : Implementing Cell-Level Encryption
- Protecting SQL Server Data : Preparing for Cell-Level Encryption
- Microsoft SQL Server 2008 R2 : Monitoring Replication (part 2) - New and Improved Peer-to-Peer Replication
- Microsoft SQL Server 2008 R2 : Monitoring Replication (part 1) - Replication Monitoring SQL Statements
- Microsoft SQL Server 2008 R2 : Scripting Replication
- Processing and Storing Data in SQL Server 2005 : Data Migration from One Data Store to Another Data Store
- Processing and Storing Data in SQL Server 2005 : Implementing the Record Failure Code
- Processing and Storing Data in SQL Server 2005 : Data Tracking Validation
- Processing and Storing Data in SQL Server 2005 : Updating the FileWorker Class
- Microsoft SQL Server 2008 R2 : Setting Up Replication (part 4) - Creating Subscriptions
- Microsoft SQL Server 2008 R2 : Setting Up Replication (part 3) - Horizontal and Vertical Filtering
- Microsoft SQL Server 2008 R2 : Setting Up Replication (part 2) - Creating a Publication
- Microsoft SQL Server 2008 R2 : Setting Up Replication (part 1) - Creating a Distributor and Enabling Publishing
- SQL Server 2008 R2 : Basing the Replication Design on User Requirements
- SQL Server 2008 R2 : Planning for SQL Server Data Replication & SQL Server Replication Types
- SQL Server 2008 R2 : Replication Agents
- SQL Server 2008 : Replication - Subscriptions
- SQL Server 2008 : Replication Scenarios
- Protecting SQL Server Data : CELL-LEVEL ENCRYPTION - Special Considerations
- Protecting SQL Server Data : SCHEMA ARCHITECTURE STRATEGIES - Harnessing Linked Servers
 
 
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.