Database Reference
In-Depth Information
Additionally, reports of high performance utilizations for CDBs with 20 or more PDBs are giving food for thought
at this URL:
Multi-tenant is a chargeable option and a lot of 12c upgrades will not be using it, especially since there is no
RECONVERT command to convert PDBs back to normal databases. To retreat from PDBs you will need transportable
tablespaces and datapump. However, 12c upgrades will certainly have to happen as 11.2 will roll off the end of
extended support in January 2018, as shown here:
I strongly recommend starting to plan your strategy for 12c upgrade and recommend the materials at this URL:
Please do remember, it has been possible to negotiate support even for pre-10g versions when required. Oracle
partly wants you to upgrade for their own commercial reasons. An example of this is the fact that a CDB has to have all
options enabled, and by default the seed PDB will also have all options enabled, and it can be difficult to remove those
options. Thus it will be easy for an organization to accidentally overstep their own licensing. The solution to this is to
provision from your own fresh PDB without all options enabled. That way you will be in charge of your own upgrade
and provisioning process. On this note, I should say that the multi-tenancy option does smooth out the consolidation
process, and on the whole
it works
, so I believe it will mature into a long-term product.
More generally, I see a move to business-process security compared to the traditional interest in just data
security, so it is worth watching business process documentation innovators such as Process Gene:
For senior DBAs who are gaining management skills, a strategic overview is important in order to provide
prioritization so planning can be done, and the conclusion aims to achieve that.
Conclusions
12c has some excellent improvements, and many of them, such as redaction, are coming into 11.2.0.4 too. We can
add this new feature to the many other security-related add-ons that have come through in recent years. We did show
how to bypass redaction secrecy, and in my view these additions take our minds away from the important core issues
in the basic DB product that still need resolving. If I could make one feature request to Oracle Corp, it would be to
improve password file managed accounts (e.g., SYS) so that they can be forced to use complex passwords which can
be verified as “certainly complex” by an auditor—without having to see the plaintext. In my view this is not that hard
and would reduce risk in the core product significantly. In the meantime, third-party add-ons fulfill this requirement,
such as BeyondTrust, CyberArk and Xceedium.
The current implementation of wallets is not a complete replacement for secure passwords, because the wallets
are owned by
"oracle"
unix. If they are to be used to secure the Oracle DB then they need to be owned by a Unix
account that is outside the purview of
"oracle"
so that they can't be modified or deleted by a process exiting the DB
to the OS as
"oracle"
. I hope this topic has reinforced the fact that the security of
"oracle"
is dependent on checking
from
"root"
, and that depends on DBA privileges not having direct access to
"root"
, only limited commands through
sudo/PowerBroker. This segregation avoids the need for a separate notarization service for storing known-good
checksums on a separate safebox. Root on the OS of the DB becames the stronghold point of trust and can react more
quickly than a centralized safebox or off-host monitoring.
