i`m no db expert and in the cissp is the topic about DB security.
One point is to that you should not mix classified and unclassified information in one table. Ok, understand.
But how it works if I divide the information in different tables and there is a relationship between them.
The user who have access to the table with the unclassified information could have access to the classified information over the relationship.
How the DB blocks this access?
Hope you can help and bring it closer to my understanding.
Mostly you can classify with below type in data
-- Confidential – GDPR
-- Highly Confidential
-- Highly Confidential – GDPR
-- Contact Info
-- Credit Card
-- Date of Birth
-- National ID
There is option to display only recommended values to particular users using with encryption/decryption methods.
Well, I will start, and hopefully others will jump in.
I would say the answer depends on the Database being used. Each DB has/have their own way of applying security.
My thoughts only: Once you have classified the data (I recommend about four levels) and understand who needs/should have access, you need to sit with the DB admins and ensure that the appropriate queries are developed for users. Test these to ensure that the appropriate access is provided and only that access.
When dealing with DBs, where possible I recommend encryption however some DBs do not allow encryption.
Some measures that you should implement when dealing with DB include (but not limited to):
@OliLue We need to start by being sure all are using the same definitions.
In the context of general data management, all information is classified, in the sense that the information owners and users have (often unacknowledgedly) decided that some of the information is private or sensitive, and other information is public or non-sensitive. Let's call this definition DefP (for Public). @97kamaraj has provided a list of information classifications that represent more specific categories of that may need to be used by a given enterprise.
However, those of us with extensive military or government experience tend to use a different definition of Classified (note the capitalization) when referring to information. In this context Classified means information determined to be sensitive and not releasable to the public because its release would threaten national security. We can refer to this definition as DefG (for Government). Using DefP, we even have a category of Unclassified (DefG), which refers to non-sensitive information that is potentially releasable to the public.
Note that the process of determining information to be Classified or Unclassified (DefG) is the result of a classification (DefP) decision. It becomes obvious that the government usage of the term Unclassified (DefG) is confusing when conflating DefG with DefP, because information has to be classified (DefP) in order to determine that it is Unclassified (DefG). For instance, a lot of Unclassified (DefG) information has been classified (DefP) as sensitive and not generally releasable, even though release does not threaten national security. The release of such Sensitive But Unclassified (SBU) (DefG) information to the public would violate strictures in law or regulation pertaining to personal privacy, contractual obligations, proprietary business information, et cetera.
Side note: Consider the difference between data and information. Realize that a database organizes data in order to provide information based on how selected data is correlated and presented. In general, a data element of location (e.g. address or latitude/longitude coordinates) is not by itself private or sensitive. Nor is the name of an individual, or a date and time. However, if you provide information that brings together the identity of
an important government offical with location at a specific day and time, that information could well be highly sensitive and need to be Classified in order to protect the official from assassination attempts.
Now, to your question about segregating data into separate tables based on data classification (DefP). Look at the protection options from @dcontesti. You need to think about the protection of the information using Diana's list. Further, go back to the basics by thinking in terms of protecting the C-I-A of the information and of the date. DefG is all about protecting Confidentiality, but DefP needs to focus as much or more also on protecting data Integrity and Availability.
One detail point to consider. You are likely to have database users with differing levels of access to information, so your internal access controls have to allow for that. There are advanced database systems that offer "row based security" to help manage such limitations. For instance, everyone in a company should be able to find the office address and work phone number of other employees, but only HR staff should be able to see performance review information, and only selected managers and financial staff should have access to pay information.