Browse Prior Art Database

Automated configuration of a Vertically Sliced Database Disclosure Number: IPCOM000247942D
Publication Date: 2016-Oct-13
Document File: 10 page(s) / 74K

Publishing Venue

The Prior Art Database


This article describes a mechanism for an automated configuration of a Vertically Sliced Database, a model for partitioning data vertically rather than horizontally. The benefit of a VSD includes protection from a compromised database, whereby if a single server were to be impacted only one data column would be exposed - exposing perhaps many millions of values for a specific field, but without associated data (e.g. names, dates, etc), and so help mitigate the risk from the exposed data.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 23% of the total text.

Page 01 of 10

Automated configuration of a Vertically Sliced Database

For a VSD, we need to map the original relational data schema (that the SQL is based on) to a suitable VSD structure of data columns spread across data servers, then provide this mapping to the other VSD servers that need to know how to direct queries to the data and get the response back to the requestor (e.g. query and router servers).  Decisions need to be made about what the VSD structure should be - when to map columns individually to separate servers for stronger security, whether certain columns can be grouped together onto a single VSD server for better performance and if there are any combinations of columns that must never be grouped together on a single server as this would create a security exposure. If these decisions are made manually, by different individuals, inconsistencies may arise in how these decisions are made. This could be due to differences in risk assessment, understanding of the data, interpretation of data security policies, etc. If the process of determining the optimal way to configure a VSD can be automated, these decisions can be made in a consistent way every time. We already have info about the original data schema (e.g. in a database system catalog). If we could describe (or 'declare') the security requirements for the data columns, like how secure they need to be and whether they need to be located individually on data servers in the VSD or whether they can be grouped together with other data columns, then it is possible to create a program that combines this 'metadata' with the original data schema information to derive the optimal VSD configuration that finds the right balance between competing demands, like security and performance.

The challenge is in how to get different people creating a VSD to declare security requirements in a consistent way. This publication addresses this problem with the use of a security policy which defines security requirements for different types of data . Each system, application or organisation will have it's own unique security policy but they might share some common policy 'rules' such as the handling of primary and foreign key columns. Some security requirements can be 'fixed' or hard-wired in the security policy and only require some automated assessment of the original database definition (e.g. the database System Catalog) to determine whether the particular policy rule applies. Other security requirements may require some human interpretation to determine if/how to apply the policy. The objective is to maximise automated application of the policy and minimize the need for human interpretation.

This publication describes the automation of the design of a VSD with a program that maps data columns in the original table to column/server combinations in the VSD based on criteria defined in a security policy such as the sensitivity/confidentiality/risk attributed to each data column. This criteria is use...