CHAPTER 4

ENCRYPTING DATA STORED IN DATABASE

CHAPTER CONTRIBUTOR: Dr. K. Ruth Ramya

4.1 INTRODUCTION TO ENCRYPTING DATA STORED IN THE

DATABASE:

• In some cases, we are told we must encrypt out data, and in others it may be in our best
interest in protecting corporate reputation, brand value, and customer relationship.
• It turns out there are valid reasons for wanting to encrypt data stored in the database.
• First, you might be forced to comply with a regulation (legal, industrial, or organizational
directive) that states that certain classes of data must be stored using encryption.
• A second valid requirement for encryption is assurance that data can be protected throughout
its life cycle. Think about data storage as a life cycle: data is created, stored, modified, moved, backed
up, and deleted over time.
• At some points in the life cycle, data can be found outside of the protected medium of the
database, as data is moved from the database to tape or another system for backup or disaster recovery
purposes.
• Employing encryption in the database provides a level of security that can be maintained
throughout the entire storage life cycle.
• For example, traditionally, it may be the case that policy specifies that sensitive data must not
be accessed by database administrators (DBAs).
• This is also a necessity and is a
• legitimate security issue when attempting to pr-otect privacy-related data.
• Until version 10.2, encryption was the only
• way to keep data secure from DBAs.
• Their rights allowed them to pick information from
any table and could only be monitored by auditing
• (a compensation, rather than proactive control).

the importance of encrypting data stored in a database for various reasons, including compliance
with regulations and maintaining data security throughout its lifecycle. Let me break down the points
you've mentioned:

Compliance with Regulations: Some regulations, whether legal, industry-specific, or

organizational, may require certain types of data to be stored using encryption. This is often done to
ensure that sensitive information is protected and in compliance with data protection laws.

Data Lifecycle Protection: Data goes through various stages in its lifecycle, from creation to
storage, modification, movement, backup, and eventual deletion. At different points in this lifecycle,
data may exist outside the secure database environment. Encrypting the data within the database helps
maintain security throughout this entire process.
 Backup and Disaster Recovery: Data is frequently moved from the database to backup systems,
such as tape or remote storage, for disaster recovery purposes. Employing encryption within the
database ensures that data remains secure even during these offsite storage phases.

Protecting Sensitive Data: Sensitive data, especially privacy-related information, may need to be
protected from unauthorized access, including database administrators (DBAs). Encrypting data in the
database is a way to secure it from potential breaches by individuals with high-level database access.

Historical Context: You mention that until version 10.2, encryption was the only way to keep data
secure from DBAs. This suggests that there may be new methods or features introduced in later
versions of the database management system to address security concerns.

Fig 1. How to configure Transparent Data Encryption (TDE) in sql server.

This figure 1 represents the security and protection of data stored in a database through
encryption. Just as a padlock secures a physical door, encryption secures data from unauthorized
access.
Monitoring and Auditing: It's important to mention that even with encryption, it's still necessary
to have auditing and monitoring mechanisms in place to track and review who accesses the data. This
is often a compensatory control for data security.

4.2 ORACLE USERS WE WILL USE OR CREATE

i. SYS
 Is a Default Oracle system administrator.
• SYS has a schema (by the same name) and has lots of structures belonging to his
account.
• You can connect (log in) to a database as SYS.
• A unique requirement of that user is can use SYSDBA privilege.
CONNECT sys AS sysdba;
• At that point, you will have to enter the password associated with the SYS user.
• SYSDBA is a unique system privilege called “super” system privilege. It provides
practically unlimited administrative ability.
 • It can be granted to any user, but is best left granted only to SYS.
• As SYS you can check who has SYSDBA:
SELECT * FROM sys.v$pwfile_users;
• With this query, you request to SELECT (see) all the columns of data (*) from the
V$PWFILE_USERS view.
• The sys. prefix on that view name indicates the schema (user) that owns the view.
• You will see a couple of other super system privileges listed in this query: SYSOPER
and SYSASM.
• These should also only be granted to SYS.
ii. HR
It is a default schema. Human resources user/schema; installs with sample Oracle
structures.
iii. secadm
It means security administrator; we will create this account and give it privileges to
implement all the security measures we need.
iv. appsec
Our application security user; we will create this user and load code and other structures
into her schema that we can use for app security.
v. appusr
Our first application user account; this account will only have the privileges needed to use
the client application.
vi. osusr
This is a pseudonym for any operating system username on your system; e.g., the
username you use to log into Windows.
vii. appver
User for application verification.

It describes various user accounts and their roles within an Oracle database system. Let
me provide an overview of the users you've mentioned:

i. SYS:

Description: SYS is the default Oracle system administrator. It has its own schema with
various system structures.
Privileges: SYS has the SYSDBA privilege, which is a powerful system privilege
providing extensive administrative capabilities. It's recommended to be granted only to SYS.
Usage: You can connect to the database as SYS with SYSDBA privileges, allowing you
to perform superuser actions. For example, you can check who has SYSDBA using a query
on sys.v$pwfile_users.
ii. HR:
Description: HR is a default schema that typically represents the Human Resources
department. It comes with pre-installed Oracle structures for HR-related data.
iii. secadm:

Description: Secadm stands for "security administrator." This account is created to

manage and implement security measures within the database.
iv. appsec:

Description: Appsec represents the application security user. It is created to load code and
other structures into its schema for the purpose of application security.
 v. appusr:

Description: Appusr is the first application user account. This account is typically
restricted to only the privileges needed for using the client application.
vi. osusr:

Description: Osusr is a pseudonym for any operating system username on your system.
It's not a database user but is used to refer to operating system users who interact with the
database.
vii. appver:

Description: Appver represents a user account created for application verification. It may
be used for testing and verifying applications within the database environment.
These user accounts have different roles and privileges within the Oracle database, and
they are typically created and managed to ensure proper access control and security within
the system. The specific roles and privileges granted to each user should align with their
intended functions and responsibilities

Roles:
• Roles are collections of granted privileges that are much more granular and diverse
and limited than the super system privileges.
• Instead of granting SYSDBA privileges mentioned in the above section, the preferred
method for giving users access to the various privileges is to grant the privileges to a
role, then grant the role to the user.
• If you do this, you can always substitute a different user in a job, or replicate the
privileges required for a job to another user by simply granting the existing role to the
new user.
• For example, I can create a role named appaccess and grant the ability to read the
application tables to that role.
• Then I can grant that role to a user. When I have another user who needs access to the
same application, I can permit that by granting the appaccess role to the new user as
well.
• And when I delete the first user, the permissions required for other users to access the
application do not disappear in the process.
• I need to grant access to the application data as described previously, because the data
tables will be in a schema belonging to the application, and each user will have her
own schema.
• Users cannot read data in other schemas unless that access is specifically granted to
them or to a special user named PUBLIC.
• Anything granted to PUBLIC is granted to all users.
 Fig 2. Secure and Efficient Data retrieval over encrypted data

4.3 ORACLE ROLES WE WILL USE OR CREATE:

i. DBA
This predefined role comes with Oracle upon installation and provides system administrative
privileges for the database; we will not grant this role to any user.
ii. CONNECT
This predefined role allows users to connect to Oracle; we are encouraged not to use predefined
roles, so we won’t.
iii. create_session_role
Our role to allow users to connect to Oracle.
iv. secadm_role
Our security administrator role; we will grant the privileges required to perform security
administration to this role, and we will grant this role to the SECADM user.
v. hrview_role
Our secure application role for granting access to data in the human resources (HR) sample
schema.
vi. appsec_role
A non-default role used by APPSEC when configuring application security.
vii. appver_role
Secure application role for running application verification.

DBA:

Description: The DBA role is a predefined role that comes with Oracle upon installation. It
provides system administrative privileges for the database. Typically, it grants extensive database
management capabilities.
Usage: As you mentioned, it's not recommended to grant this role to any user, as it gives broad
administrative powers.
ii. CONNECT:

Description: The CONNECT role is another predefined role that allows users to connect to Oracle.
However, you mentioned that you are encouraged not to use predefined roles, so you won't be
using this role.
iii. create_session_role:

Description: This is a custom role created to allow users to connect to Oracle. It's a way to control
access to the database by granting this role to users who need to establish sessions.
iv. secadm_role:

Description: Secadm_role is a custom security administrator role. It is designed to grant the

necessary privileges for performing security administration tasks within the database. This role
will be granted to the SECADM user.
v. hrview_role:

Description: Hrview_role is a custom secure application role used for granting access to data in the
Human Resources (HR) sample schema. It seems to be used to control access to HR-related data
for specific users or applications.
vi. appsec_role:

Description: Appsec_role is a non-default role used by APPSEC when configuring application

security. It likely contains privileges and permissions necessary for application security.
vii. appver_role:

Description: Appver_role is a secure application role created for running application verification.
It ensures that users have the appropriate permissions to test and verify applications.
These roles play a significant role in managing and controlling access and privileges within the
Oracle database, aligning users with their responsibilities and permissions. Custom roles are often
created to tailor access and privileges to specific organizational needs.

Roles for Database Administration

DBA: The Database Administrator (DBA) is responsible for managing all aspects of the Oracle
database, including installation, configuration, security, performance, and troubleshooting.
Oracle DBA role iconOpens in a new window
medium.com
Oracle DBA role icon
SYSTEM: The SYSTEM role is the most powerful role in the Oracle database. It has all system
privileges and can perform any operation on the database.
Oracle SYSTEM role iconOpens in a new window
rpforacle.blogspot.com
Oracle SYSTEM role icon
SYSDBA: The SYSDBA role is similar to the SYSTEM role, but it has the additional ability to
grant and revoke system privileges.
Oracle SYSDBA role iconOpens in a new window
stackoverflow.com
Oracle SYSDBA role icon
Roles for Application Development

APP_DEVELOPER: The APP_DEVELOPER role is granted to users who need to develop

applications that access the Oracle database. This role has privileges to create and modify tables,
views, and procedures.
Oracle APP_DEVELOPER role iconOpens in a new window
appdevelopermagazine.com
Oracle APP_DEVELOPER role icon
APP_USER: The APP_USER role is granted to users who need to run applications that access the
Oracle database. This role has privileges to select, insert, update, and delete data.
Oracle APP_USER role iconOpens in a new window
stackoverflow.com
Oracle APP_USER role icon
Roles for Data Reporting

DATA_REPORTER: The DATA_REPORTER role is granted to users who need to generate

reports from the Oracle database. This role has privileges to select data from tables and views.
Oracle DATA_REPORTER role iconOpens in a new window
ruepprich.wordpress.com
Oracle DATA_REPORTER role icon
Roles for Data Loading

DATA_LOADER: The DATA_LOADER role is granted to users who need to load data into the
Oracle database. This role has privileges to insert data into tables.
 Oracle DATA_LOADER role iconOpens in a new window
hcmcloudhub.com
Oracle DATA_LOADER role icon
Roles for Data Security

SECURITY_ADMIN: The SECURITY_ADMIN role is granted to users who need to manage the
security of the Oracle database. This role has privileges to create and manage users, roles, and
privileges.
Oracle SECURITY_ADMIN role iconOpens in a new window
docs.oracle.com
Oracle SECURITY_ADMIN role icon
AUDITOR: The AUDITOR role is granted to users who need to audit the Oracle database. This
role has privileges to view audit logs and other security-related information.

4.4 THE DBA ROLE

• In recent releases of Oracle, database administrators have been discouraged from using the
DBA role.
• Rather, they are encouraged to create their own roles and to grant just those administrative
privileges that are required.
• Therefore, we will not grant DBA role to any user.
• We will be creating a security administrator role, secadm_role.
• We will use this role for most of our administrative actions.
• This approach adheres to the concept of “least privilege,” which means providing only the
privileges required for the task at hand.
• Oracle Database Vault is a product that allows you to use DBA and other privileged roles
while restricting their access.
• This is geared toward Department of Defense and national security users, where a database
administrator does not necessarily have access to the data.

SELF ASSESSMENT QUESTIONS

1. What is data encryption in the context of a database, and why is it important?

2. What are the different types of data encryption commonly used in database systems?
3. Explain the concept of data-at-rest encryption and data-in-transit encryption. How do
they differ?

4. What are the key benefits of encrypting data in a database?

5. List some common scenarios or reasons for encrypting data stored in a database.

6. What is the role of encryption keys in database encryption, and how are they managed?

7. Can you describe the process of encrypting data before it is stored in a database? What
happens when data is decrypted?

8. What is the impact of database encryption on performance and resource utilization?

9. How can encryption help in compliance with data protection regulations and standards?

10. Explain the difference between encrypting the entire database and encrypting specific
columns or data elements.

11. What are some best practices for implementing and managing database encryption in an
organization?

12. In what situations would you use Transparent Data Encryption (TDE) in a database?

13. How can you ensure the security and integrity of encryption keys in a database?

14. What is the role of database administrators (DBAs) in managing encrypted data in a
database?
 15. Can you describe any potential challenges or considerations when implementing
encryption in a database?

TERMINAL QUESTIONS
1. What are the different types of database encryption?
2. What are the advantages and disadvantages of each type of database encryption?
3. How do you choose the right type of database encryption for your needs?
4. What are the best practices for encrypting data stored in a database?
5. How do you manage encryption keys for a database?

6. How do you encrypt data at rest in a database?

7. How do you encrypt data in transit between a database and another system or application?
8. What are the different types of cryptographic algorithms used for database encryption?
9. How do you generate, store, and distribute encryption keys for a database?
10. How do you monitor and audit encryption activity in a database?
11. How do you encrypt data stored in a MySQL database?
12. How do you encrypt data stored in an Oracle database?
13. How do you encrypt data stored in a SQL Server database?
14. How do you encrypt data stored in a PostgreSQL database?
15. How do you encrypt data stored in a MongoDB database?
16. Troubleshooting questions
17. What are the common problems that can occur when encrypting data in a database?
18. How do you troubleshoot problems with database encryption?
19. What are the best practices for recovering from a database encryption failure?