Database Reference
In-Depth Information
Moving to the Cloud
First, when a company puts their data in someone else's data center there is an obvious shift in the power balance,
and there is a predictable opportunity for the provider to overcharge in the future. I have experienced commercial
situations in which legal action has had to be taken to gain servers back from shared hosting providers. Long-term
data ownership will be a legal, security-related concern for clouds. With private clouds the internal centralization
of data access control increases the potential for power imbalance and corruption, especially in the absence of
transparent audit processes.
Second, the passing of responsibility for inhouse security of sensitive data from the parent company to the
cloud provider is a very sticky issue. Privileged-access control of system administrator privilege is non-trivial, as
evidenced by CIA whistleblower Ed Snowden's online testimonies regarding the PRISM project. Snowden says that as
a system administrator he could see more than business users who had the highest access. With cloud the question
is
Who cares most about my company's data being breached—my company or the cloud provider?
What guarantees,
protections, and insurances are in place to cover eventualities such as a rogue insider? These concerns have caused
many to de-prioritize the public cloud and recommend internal private cloud consolidation, as enabled by more
powerful hardware.
Third, private cloud consolidation, i.e., the centralizing of many DBs onto a single shared server, will result in
a lower requirement for DBA resources long term. This raises more concerns regarding internal privileged access
control. The fact that root and SYS accounts have been allowed to remain largely uncontrollable and non-identifiable
has partly been because the teams that use their credentials have naturally been growing. When the reverse is true,
the weakness in the internal security control of these credentials becomes a serious issue due to infighting where the
consolidation process has been poorly managed. Within banking, internal security has always been a high priority.
Hence banking's use of break-glass access control, where a separate break-glass server holds the privileged credential;
DBAs check out the SYS password, which then gets reset at the end of the day. So DBAs tend to just have SYS for a
day at a time. CyberArk has sold their Enterprise Password Vault (EPV) system quite successfully for a number of
years, and now Oracle has an equivalent in the form of Oracle Privileged Account Manager. These separate services
can maintain a random and daily changing value for the SYS password, which helps to balance the problem of SYS
being immune to password controls in the profile. Problem is that these systems have integrity issues as we shall
see, and in 12c the many PDBs on a single CDB all have the same SYS password due to a single shared password file.
This contradicts the idea of having the separate privileged-access control system, supposedly maintaining unique
password values, but we will give advice on how to plan and cope with this in Part IV. (PDB = Pluggable Database and
CDB is Container Database.)
These three points just discussed lead us to conclude that the role of compliance and audit will increase with the
movement to cloud in order to balance the added risks. Cloud security auditors will be a growing area of employment.
We will return to that subject in Chapter 19, which is focused on cloud security and EM12c Cloud Control.
Ensuring Replication Security
Another trend has been the research focus on replication security. In 11g, Dataguard has the facility to be opened
for SELECTs as a separate copy of production, but it is susceptible to brute force due to being read-only (no failed
login count). The other problem with Dataguard is how does production authenticate to the standby and vice versa
without the plaintext password, which is only known to the DBA? The answer is: by using the hash. The problem
is that this leaves Dataguard open to a “pass the hash” attack on the SYS account at the standby. 12c deals with this
to some extent by introducing the SYSDG privilege so that SYS is not required for Dataguard. This is another good
development among the many in 12c, as we shall see.
