Database Reference
In-Depth Information
copy of the financial data. The key control is ensuring a malfeasant (bad guy) can't
change
the production copy to an
unauthorized value, and thus subvert the process. So maintaining integrity as part of
process security
is a huge driver
for privileged access control in financial services. Learning lessons from Societe Generale and J.P. Morgan's London
Whale incident enable us to see that secrecy enabled a trader to hide their losses while they attempted to double
up their lost bet. If the reporting had been more open then the ability to hide losses would have decreased—thus
resulting in a safer bank. Again, Part VI will analyze the architectural risk aspects in greater depth. Before that, the next
chapter will focus on the practices of applied privilege access control on Oracle RDBMS with relevance to Oracle.
Consolidation as PAC Driver
Lastly, the largest business factor fueling the need to control high privilege is the process of consolidating IT, both to
cloud and off-shoring or simply by efficient internal automation and hardware consolidation, such as that involved in
12c projects. It is said that one of the main reasons behind 12c's PDB/CDB architecture is to allow many e-business
suite installations to be brought together on a single piece of hardware without renaming the schemas. Higher power
hardware enables this consolidation, and 12c PDBs enable multiple schemas with the same name on one CDB.
Privileged access control is a prerequisite to this consolidation, as there may be a reduction or movement of workforce.
Let's see how PAC can be achieved through practical commercial implementations in the following chapter.
