Chapter 2. Architecture patterns for externalizing security from
2.3 Database level approach
In many of today’s collaborative business environments, organizations may have to share data with a variety of partners, employees, and others outside the organization, most of whom need access only to a particular segment of the data available to them in the environment in which they share information. This data may have to be accessed from a number of applications and channels. Because it is not always possible to modify the applications to enforce data-level security, it may be necessary to enforce controls at the database level to ensure that the right information is being disseminated to the right requestor for the right reason or in the right context. The database and the data that it holds become a natural point where one can apply and enforce security policies, particularly access entitlements.
This approach, where the security controls are implemented on the databases instead of modifying the applications, is called the
database level approach
. Architecturally, this is a good fit when consistent access policies to data are required regardless of the applications and channels that access the data.Let us review the database based approach through the following healthcare organization example.
2.3.1 Customer example
A healthcare organization is constantly receiving data, such as medical records from healthcare providers, and claims and other benefits-related information from insurance providers. At the same time, the company is sending out data to third parties, such as companies to whom billing or other services are
outsourced. In such a scenario, data security requires that information be shared strictly on a need-to-know basis so that, for example, healthcare providers have access only to medical records, and not claims or billing information, insurers see only data related to claims and benefits, and providers of outsourced services are limited to views of data related to the services they provide.
Both medical and financial data represent particularly sensitive types of information that, when combined with
Personally Identifiable Information (PII)
, can cause great damage to the person to which they relate, if they get into the wrong hands. In such a case, the healthcare provider would be held liable for the damage or would face respective charges of liability due to lack of due diligence. So it is obvious in this scenario how business needs directly relate to the successful implementation of security measures.A number of past incidents of data leakage that had wide press coverage have shown that there is a less direct, but potentially far more severe, risk to the business due to this issue: loss of reputation and resulting decline of future revenue caused by customers walking away. In many countries, it is not possible anymore to try to avoid this reputation damage by simply refusing to comment on the incident because regulations require that data loss must be reported.
The following, non-exclusive list of data related and business driven requirements have been identified based on data security needs: Grant access to data on a need-to-know basis.
Make sure that access is granted consistently across all applications and all data stores.
Pay special attention to privileged users such as system administrators. Monitor sensitivity of data as time evolves.
Be prepared for rapidly growing data volume.
Need-to-know principles
A user should only have access to those data elements that are necessary to fulfill the respective duties based on their role. So, for example, a physician in a hospital needs to see the entire medical record of a patient to avoid
mistreatment, but should not be able to see credit card information. A person in charge of billing, conversely, needs access to the insurance data, to be able to distinguish which treatment is covered by the insurance, and which treatment is not covered and must be billed to the patient directly.
Consistent fine-grained access control
Regardless of the number of applications, business imposed rules and policies apply to the entire organization. All applications operating on the same data must follow the same rules. When applications need to be changed or new
applications are introduced, it should take little effort to establish consistency of data access entitlements.
Privileged user management
System administrators often need privileges far beyond what their duties require, simply because the system platform does not provide the level of granularity for access control that the business needs dictate. Specifically, this means that a system administrator can often access sensitive business or personally identifiable data as a side effect of their administration privileges. It is a best practice to reduce these privileges by adding an additional enforcement layer that has much finer granularity both in determining a user’s role as well as the significance of the data element being accessed. Administrators benefit because they are no longer a prime suspect in case of a breach because the organization can apply the same principles related to business data to administrators as well as any other user.
Changing sensitivity of data
As time passes, certain information elements may lose their former importance or gain additional importance. Data that is critical one day is less consequential, perhaps not even relevant, at another time. For example, a temporary medical condition may be critical only until the patient has fully recovered. After that, it may not matter any more that the patient ever suffered from this problem. Financial transactions may be kept secret until a certain point in time, after which they become public knowledge. Policies may be needed to address conditions like this, for example, a specified date can trigger an automatic change in the status of a data element.
Growing data volume
Data growth is exploding today, with data volumes doubling every 18 to 24 months according to some analysts. The implications for data security in the data center are vast, as organizations store increasing amounts of content there. More storage is required to support such massive data growth, and organizations must make sure that the addition of more data stores takes place in accordance to the existing access policies at any given point in time. There must not be a single instant at which this principle is violated.
Data in different states
So far we have discussed how data entitlements are handled in the context of business applications that carry out well defined, intended business processes. For the sake of completeness, regulations require policies to be put in place to ensure confidentiality and integrity of data at all times, including when they are in transit (and thus prone to unauthorized interception) or at rest (and thus
potentially subject to intrusion attacks or information loss).
2.3.2 Integrating policy at the database level
We now take a look at the steps required to establish the database level security policy enforcement approach.
Database resource discovery and classification
To be able to formulate policies related to data, the context of that data must first be known to the policy management solution. A discovery mechanism is required to provide information about relevant data, including metadata such as schema and table structures, further classification of the data based on business
requirements, state of the data, and so on. Data classification is a task of its own and can be carried out separately from policy management. It provides important input to policy management, especially in providing important business contexts to information. Classification applies to both structured (database) as well as non-structured data (residing in the file systems).
Database security policy authoring
After the resource hierarchy has been identified, policies can then be defined and associated with data elements or classification of data elements. Most
commercially available databases already provide a mechanism for enforcing both coarse and fine levels of authorization policies; but they are specific to the target database. Hence, policy authoring should provide an abstraction so that you do not need to understand the details of all the database implementations. There may be more than one policy required to accomplish the database specific actions.
Policy configuration and distribution
Because the policies are defined with a level of abstraction, configuration is needed to map the parameters of the policy into enforceable entities on the database where these policies would be enforced. The policies and configuration information for databases may then be transformed into database commands and distributed to databases where they will be enforced.
Enforcement at the database
Because a database server receives actions to perform natively, enforcement requires merely to execute the actions, but additional conditions may have to be accommodated for a proper context. The achievable granularity depends on the combination of options available both on the management side and the specific enforcement points. When calls by different applications invoke the same type of operation on the database, consistent policy enforcement can be achieved and eventually demonstrate compliance to the business. This situation also includes control over actions carried out by privileged users with administrator rights who have opportunities to bypass the business applications and access data directly by using administrative tools.
Application integration
When using the fine grained access capabilities in databases, you need the context of the user in addition to the application or system ID that is typically used to connect to them. Some databases support this notion and provide the ability to propagate identity, in which case there may not be any application changes required. In other cases, where automatic propagation of identity is not possible, applications may have to provide it explicitly during connection time.
Auditing
Accountability of both the business as a whole and the user as an individual is essential. Auditing of policy management solution and enforcement is the key approach. Given the fact that the pattern of database level enforcement presents itself as a combined effort between the security policy management component and the database, it is likely that the same situation applies to auditing. This situation implies that a correlation of different audit logs with different formats is likely to be needed. Specialized log and event management solutions provide both the technical and the business side of this requirement. They can normalize and abstract from the specific log formats and they can assess compliance with business driven or law imposed rules and regulations such as the
Health
Insurance Portability and Accountability Act (HIPAA)
. Log management also helps to prove completeness and integrity of the logs, thus making it a business supporting feature rather than just a technical component.More information about the database level approach can be found in Chapter 7, “Database level integration” on page 187.