Catedra De Riesgos Oracle

Notas del editor

• #17: Let’s first take a look at Database Vault Realms. Here we have a database, let’s assume that this is a consolidated database. As you would expect you have the DBA as well as several other applications, here we’ve included an HR and Financial application. One of the problems faced in this type of situation is that the DBA can, if he or she wished to do so, use their powerful privileges to take a look at application data. Even the possibility of this happening can be prevented using Database Vault Realms. Simply place a Realm around the HR application and the DBA will no longer be able to use his powerful privileges to access the application. The other situation is one I eluded to earlier. Application owners tend to have very powerful privileges. In a consolidated environment, it’s very likely that you’ll have more than one application and thus several powerful users in the database above and beyond the DBA. In this example, it’s possible for the HR DBA to look at the Financial application data. Obviously this wouldn’t be a good situation, especially if it was during the financial reporting quite period. Using a Database Vault Realm, the Financial application can be protected from powerful application owners. Summary, Realms can be easily applied to existing applications and with minimal performance impact.
• #18: In addition, to Realms, Database Vault also delivers Command Rules and Multi-Factor Authorization. Command Rules provide the ability to instruct the database to evaluate conditions prior to allowing a database command to execute. Combined with Multi-Factor authorization, this provides an extremely powerful tool to limit and restrict access to databases and applications. Let’s take another example. Here I’m showing a database with a single application and the DBA. One of the common problems customers have faced from a compliance perspective is unauthorized activity in the database. This may mean that additional database accounts or application tables have been created. This can raise alarms with auditors because it can point toward lax internal controls. Using a command rule, Database Vault gives the ability to control the conditions under which a command is allowed to execute. For example, a command rule can be associated with the database “Alter System….” command. Perhaps your policy states that all ‘alter system’ commands have to be executed from a connection originating from the server hosting the database. The command rule can check the IP address and reject the command. So the rule based on IP address blocks the action. Perhaps a powerful application DBA creates a new table, command rules combined with multi-factor authorization can block this action. In summary, command rules and multi-factor provide the flexibility to meet operational security requirements.
• #23: Disparidad de perfiles de usuario en directorios y aplicaciones para una única identidad Actualizacion muy costosa en recursos y pesada en ejecucion Posibilidad de datos erróneos sobre la misma identidad en los distintos directorios o bbdd
• #24: To date Identity Management has been treated as a separate management solution—something bolted on to applications after they have been deployed. Identity Management has more closely resembled traditional systems management offerings and has been treated as an extension of such. This is changing. A new phase of identity management is dawning, one that delivers management of user identities as a service such that the applications themselves utilize the service as if it’s part of the applications’ business process. Exposing identity management as a re-usable service for all applications drives the realization of significant business efficiencies. For example, a common practice such as creation of new user profile when an employee is first entered into the HR system, should be the same profile utilized to create, approve and enable their companywide system credentials. Their access privileges and appropriate system accounts, determined automatically by their job responsibilities, are created —all as part of a single business process. This process is initiated by the HR administrator—not a separate team that synchronizes newly created account information into separate, independent identity repositories to perform account management functions. Should the role or employment status of this user be changed at any time by HR, access privilege changes or termination of access and disabling of accounts occurs automatically based on the defined business process and associated policies. This significantly speeds user account access and in-access, streamlines the entire business process, and will further drive down administrative costs. Oracle views Identity Management as an application management function—not a systems management one. Application Centric Identity Management is: Integrated out-of-the-box with your business applications, in particular your HRMS system, such that Identity Management easily enables the business processes your organization relies on today. An integral component of a wider application development and deployment framework that seamlessly works together, such that identity management is always-ready for new applications and thus rapidly deployed Architected for future SOA application environment, so that as more and more applications are deployed as loosely coupled services, they can rely on a set of standards-based, reusable security services