Building secure database applications is done on the assumption that the database is already operating securely. To ensure this happens, you often have to perform certain tasks to create a tighter security implementation. There are many important lessons in this chapter.
Securing database schemas means ensuring not only new schemas are created and managed properly but also that the default schemas are secured. The default schemas and their passwords are well known. There are several ways to prevent unwanted and unauthorized users from connecting to these well known and highly privileged accounts. Several techniques were shown for applying the defense in depth principle.
An understanding of Oracle’s use of passwords is necessary because password authentication represents the most common authentication mechanism to the database. The database supports both password complexity routines and password profiles to support the secure and proper use of passwords.
Oracle’s default roles exist today for legacy reasons and should rarely be used, and revoking existing privileges and limiting grants to the user group PUBLIC is essential for securing the database.
A final necessary piece of the security puzzle is network security. The entire security of an application and database can be subverted through poor network security. The database provides several ways to prevent this from happening. Applying security at the network tier ensures all the links in the security chain are strong.
Part II: Identification and Authentication
- Chapter 3: Understanding Identification and Authentication
- Chapter 4: Connection Pools and Proxy Authentication
- Chapter 5: Identity Management and Enterprise Users
- Chapter 6: Identification and Authentication for Web Applications
Chapter 3: Understanding Identification and Authentication
Before you begin to code your database applications, you should have a clear understanding of the security design. This is critical because the design decisions you make before you begin to build determine how effective your security implementation will be once you have built it.
In this chapter, we will review the first steps in the security process known as identification and authentication (I&A). I&A is the necessary base step upon which the database security depends. Therefore, your I&A design decisions are very important. The material presented here will provide supporting information that you can use in determining which methods are appropriate for your organization.
In today’s world, a lot of the identification and authentication occurs at the application or application server. In Chapter 5 shows another design you may use to provide an efficient way to centrally manage the database users. This chapter provides an overview of the I&A concepts that is necessary for making the correct decisions on material presented in later chapters.
Importance of Identification and Authentication
The database security process flow can be summarized by the following three steps:
First, a user presents an identity to the database. For example, they enter their username.
The user proves that the identity just presented is valid. For example, they provide a password. The password is checked by the database to determine if it’s the correct password for the username presented.
Assuming the password is correct, the database assumes the identity can be trusted. The database will then determine, based on the identity, what privileges and authorizations the user has. Data access is regulated by the user’s privileges and authorizations.
Typically, people spend the majority of their time and security efforts implementing the processes needed for the third step. The first two steps are important because they form the foundation of security; you need them to get to step three. Step one is identification. Step two is authentication.
There is an often overlooked fact about designing and implementing security solutions: security cannot be based on anonymity.
You must first identify yourself. To do this securely requires authentication or proof that you are in fact who you say you are. If an application or database doesn’t know who you are, it can’t grant you the proper authorizations, apply the necessary access controls, and audit your actions. This seems obvious, but in countless database application designs, this point is lost. Most, if not all, database security is based on knowing who the user is.
As a validation of this principle, consider an e-mail application where all the e-mail is stored in a single database. The security policy for e-mail is simply that users can only access their personal e-mail. How would the security be implemented if the user’s identity is unknown? It couldn’t. Clearly, identifying the user has to be done.
The authentication has to be provided as well to ensure that users aren’t trying to impersonate other users. If the authentication is not provided, or is provided weakly, the entire security processes in the application and database will be negated. The application and database will not prevent the nefarious user from carrying out their actions (meaning accessing someone else’s e-mail) because the application and database think it is the authorized user.
Let’s explore the various ways identification can be implemented to determine how to do it best.