TAILIEUCHUNG - Applied Oracle Security: Developing Secure Database and Middleware Environments- P5

Applied Oracle Security: Developing Secure Database and Middleware Environments- P5:Computer security is a field of study that continues to undergo significant changes at an extremely fast pace. As a result of research combined with increases in computing capacity, computer security has reached what many consider to be “early adulthood.” From advances in encryption and encryption devices to identity management and enterprise auditing, the computer security field is as vast and complex as it is sophisticated and powerful | 14 Part I Oracle Database Security New Features For a single application for example it s not uncommon to see base tables in one schema code in another schema and metadata or summary data in a third schema. Isolating these might allow procedural code updates to the code schema to be done without significant if any impact on the other schemas. Likewise building new summary data structures would have little impact on the procedural and data schemas. And finally backups may be more frequently done on the data schema as the data probably changes more often than do the procedural and code structures. It s not our intent here to illustrate all the possible ways or possible reasons barring the security reason to separate objects into different schemas. Architecture and application design and implementation is as much an art as it is a science. The important point conveyed here is not so much stating the laws on how to organize schemas but that you should apply a functional and logical organization to your schemas. Security Concerns You should understand security implications associated with schemas as this is critical to ensuring a secure application design and implementation. It s important that we point out that no objectlevel security within a database schema guards itself from itself. The schema owner has full access to all the objects within the schema. It may sound a bit ridiculous to say this because naturally that is why you may decide to co-locate the objects code and so forth. The obvious interrelationships and interactions among objects that are necessary for the application to work need to exist without security barriers. It is a fairly common worst practice to allow users general application users in this reference to log into the object owner accounts that is the schemas where the objects reside . When this is done the thinking is usually that the application code will protect the objects from any malicious or malevolent user intent. It is most often done to