Security Requirements

Security Requirements

Objectives After completing this lesson, you should be able to do the following: Describe fundamental security requirements Define the following terms: Least privilege Authorization Authentication Describe security policies Describe the concept of security in detail

Industry-Security Requirements
Legal: Sarbanes-Oxley Act (SOX) Health Information Portability and Accountability Act (HIPAA) California Breach Law UK Data Protection Act Auditing Industry-Security Requirements Security requirements have been a matter of individual concern until recently. Unless you were handling government or military data, there were few legal requirements. This is rapidly changing. A variety of laws have been passed to enforce privacy and accuracy of data. Along with these laws comes a requirement to audit the security measures that are in place. Legal: Each of the laws listed here has specific requirements. This list is representative of many other laws that are being passed worldwide. Sarbanes-Oxley Act (SOX) requires that public companies strengthen and document internal controls to prevent individuals from committing fraudulent acts that may compromise an organization’s financial position or the accuracy of its financial statements. The chief executive officer and the chief financial officer must attest to the adequacy of the internal controls and accuracy of the financial report. These officers are subject to fines and imprisonment for a fraudulent report. The requirements of SOX include providing information that is used to generate the reports and providing documentation about the internal controls used to assure the integrity of the financial information.

Do your policies meet the standards?
Security Standards Recognized security standards: ISO 17799 SANS Institute CERT/CC Recognized Security Standards Do your security standards measure up to the industry standards? Some good resources for industry-standard practices are SysAdmin, Audit, Network, Security (SANS) Institute, CERT/CC operated by Carnegie Mellon University for the Department of Defense, and the ISO certification standard: ISO is an international standard of security practices. It includes best practices, certification, and risk assessment. It covers a broad range of issues and includes prewritten policies. Security requirements are changing. It is important to be aware of the changes and their impact. The organizations listed above (and others) provide newsletters and study opportunities. Do your policies meet the standards?

Fundamental Data-Security Requirements
You should know the following fundamental data-security requirements: Confidentiality Integrity Availability Fundamental Data-Security Requirements Legal and business standards require that your security meet the following fundamental requirements: Confidentiality: Individuals see only the data that they are supposed to see. Confidentiality may require encryption of the data in the database or in transit to meet the following needs: Privacy of communication Secure storage of data, including backup media Secure transmission of sensitive data Restricted access to services Authenticated users Granular access control Integrity: A secure system ensures that the data it contains is valid. Data integrity means that data is protected from deletion and corruption, both while it resides within the database and while it is being transmitted over the network. Integrity has several aspects: System and object privileges control access to application tables and system commands, so that only authorized users can change data.

Components for Enforcing Security
Authentication Authorization Access control Auditing Components for Enforcing Security The following components are used to enforce security: Authentication is the process by which a user’s identity is checked. When a user is authenticated, the user is verified as an authorized user of an application. Authorization is the process by which a user’s privileges are ascertained. Access control is the process by which a user’s access to physical data in the application is limited, based on the user’s privileges. These are critical issues in distributed systems. Auditing is the process that allows users to be held accountable for their actions, both by verifying that users are not using their privileges improperly and as a deterrent to unauthorized access attempts. For example, if JAUSTEN is trying to access the database, authentication would identify her as a valid user. Authorization would verify her right to connect to the database with Product Manager privileges. Access control would enforce the Product Manager privileges upon her user session. Auditing could record her connection times and any access made to sensitive data.

Security Risks Risk analysis includes: External attack:
Unauthorized users Denial of service Unauthorized data and service access Internal abuse: data or service theft Sabotage: data or service corruption Complexity Security Risks Security risks come with accessibility. Accessibility makes your data valuable. If all your data was in filing cabinets or vaults, you could be sure that it was secure, but the time to retrieve it would make it worthless. External exploits by criminals breaking into systems get big headlines, but industry specialists estimate that 80% to 90% of the damage to information systems is done by insiders. External Threats Unauthorized users: These are outsiders who gain access to your system. They may use software exploits, bypass login information, crack passwords, or use social engineering. They may be helped by poor passwords, unattended terminal sessions, and unsecured servers or modem lines. Even your trash may contain information that allows them to get into your system. Denial of service: It can be an attack from a malicious source that requests limited resources such as port allocations to disrupt authorized users. It can be accidentally caused by authorized users who make inappropriate requests. Unauthorized data and service access: After outsiders have got past authentication, the system sees them as insiders.

Risk Analysis Threat Vulnerability Control Attack Prevent Discover
Protect Control Risk Analysis No system can be guaranteed to be 100% secure. The costs of securing a system are weighed against the possible costs of a security breach, whether it is internal or external. A thorough review can be expensive. But it is important to be aware of the issues, set the priorities, and determine the funding. Some of the security standards, such as ISO 17799, require a risk assessment and provide guidance. The basics of risk analysis involve three main dimensions: Vulnerabilities are listed and removed, if possible. Any system may have unknown vulnerabilities. Threats are listed. You must assume that every vulnerability is an attack vector. Of course there are unknown threats. It is likely that new exploits will be developed that use attack vectors that have not been considered. Controls are put in place to prevent threats, protect vulnerabilities, and discover attacks. Risk analysis includes considerations for “what if” scenarios. If authentication has been defeated, will additional protections be in place to limit or discover the intruder? The security policy implements the controls found though analysis. Because there is always the possibility of unknown vulnerabilities and threats, the security policy should apply the principles of “least privilege” and “defense in depth” (covered in the next several slides).

Principle of Least Privilege
Install only the required software on the machine. Activate only the required services on the machine. Give operating system (OS) and database access to only those users who require access. Limit access to the root or administrator account. Limit access to SYSDBA and SYSOPER accounts. Limit users’ access to only the database objects that are required to do their jobs. Principle of Least Privilege Apply the principle of “least privilege” starting at the lowest level, and continue at every level. There will always be new security exploits that cannot be anticipated. By applying this principle, the possibility of the exploit is reduced and the damage can be contained. Install only required software on the machine: Reduce maintenance, upgrades, the possibility of security holes, and software conflicts by reducing the number of software packages installed. Activate only required services on the machine: Fewer services imply fewer open ports and fewer attack vectors. Give OS and database access to only those users who require access: Having fewer users means requiring fewer passwords and accounts. Reduce the possibility of open or stale accounts. With fewer accounts, it is easier for the administrator to keep the accounts current. Limit access to the root or administrator account: The administrator account must be carefully guarded, audited, and never shared. Limit access to SYSDBA and SYSOPER accounts: Users who require access to these roles must each have their own account, and the accounts must be audited. Limit users’ access to only the database objects required to do their jobs: Do they have a need to know? Users who have access to more objects and services than they require have an opportunity for mischief.

Defining a Security Policy
What is a security policy? A set of rules Specific to an area and site Required Approved by management What is a standard? Rules specific to a system or process Required for everyone What are guidelines? Suggestions and best practices Specific to a system or a process Defining a Security Policy A security policy is set of documents that are specific to your site. Policy documents are approved by the management. They identify what is required by the company. The policy applies to a specific security area, such as acceptable use of modems, or formation of passwords. A policy is a set of mandatory rules. It must be only as long as required (a couple of pages) and easy to understand. It must be enforceable. To be successful, a policy must balance protection and productivity. Policies should include: Configuration management: Who is responsible for the security and to what level? Incident reports: How are security incidents handled? Infractions: What are the consequences of security violations? A standard is a set of rules that apply to a specific system or process (for example, securing external procedures). Policies refer to standards. Standards, procedures, and guidelines are established at the department level and are much more detailed. They spell out what must be done to meet the policy. A guideline is a suggestion or a best practice for a specific system or process. Policies refer to guidelines. For novices, it is critical to get examples, especially for meeting the requirements of SOX or HIPPA. The Sys Admin, Audit, Network, Security (SANS) Institute and CERT/CC are very good resources.

Developing Your Security Policy
The steps to develop your security policy are: 1. Assemble your security team. 2. Define your security requirements. 3. Develop procedures and systems to meet these requirements. 4. Implement security procedures. Developing Your Security Policy Assembling Your Security Team First, determine which people in your organization will participate on the security team. To be effective, this team must include system architects, system administrators, database administrators (DBAs), network administrators, data owners, and representatives of end users. Although technical personnel monitor security, you must also include data owners and end users when defining your security requirements. Others to be included in the team are business experts who understand the organization, security, and disclosure requirements, and legal experts who know the legal requirements for handling the data of the organization. Defining Security Requirements To define your security requirements, examine who needs access to which data and services and why they need it. Developing Security Procedures and Systems After you know the security requirements of your organization, you can develop procedures and systems to meet these requirements. Implementing Security Procedures Now that you have defined a policy, implement it to secure the data on a day-to-day basis.

Examining All Aspects of Security
Consider the following dimensions: Physical Personnel Technical Procedural Example: An employee leaves his or her desk while using an application. Examining All Aspects of Security To protect all the elements of complex computing systems, you must address security issues in the following dimensions: Physical: Your computers must be physically inaccessible to unauthorized users. This means that you must keep them in a secure physical environment. Personnel: The people responsible for system administration and data security at your site must be reliable. You may need to perform background checks on DBAs before making hiring decisions. Technical: Storage, access, manipulation, and transmission of data must be safeguarded by the technology that enforces your particular information-control policies. Procedural: The procedures used in the operation of your system must assure reliable data. These procedures are developed after looking at the other three aspects of security. For example, one person might be responsible for database backups. The person’s only role is to ensure that the database is functional. Another person might be responsible for generating application reports involving payroll or sales data. This person’s role is to examine the data and verify its integrity. It may be wise to separate out the functional roles of the users in data management. Think carefully about the specific security risks to your data, and make sure that the solutions you adopt actually address the problems.

Implementing a Security Policy
Implement your standards and procedures. Implement the plan for developing new systems and applications. Monitor and enforce the policy. Keep systems and applications up-to-date with security patches. Educate users. Implementing a Security Policy Now that you have a policy defined, implement it to secure the data on a day-to-day basis. If you need to add systems or develop new applications to complete your security policy, immediately implement as much of the policy as you can without these systems. Then as you complete the new systems and applications, revise your security policy to include them. Monitoring and Enforcing Security Ensure that all employees understand the significance of keeping your organization secure. The employees must understand the security issues associated with their functions in the organization. They must also be aware of how they might be disciplined if they breach the security policy. Applying Security Patches System administrators and DBAs who are responsible for software installations must search for and apply security patches on a periodic basis. As part of the security policy, include a schedule to search for and apply new security patches.

Defense in Depth Using the concept of “defense in depth”:
Enforce security policies Train users Harden the operating system Use firewalls Use network security Use database-security features Defense in Depth “Defense in depth” means that you consider every level. The defeat of one security feature must not give full access to all data or services. A policy is a roadmap for security implementation, but it must be implemented to be effective. Users must be trained to avoid activities that could easily breach security. You may have a perfect firewall and antivirus checking on all incoming traffic, but if a user working from home downloads a virus or a trojan, then it can infect the network from behind the firewall. The operating systems on machines that host the application server, the database, the mail server, and other critical services must be hardened. The network services, firewalls, and proxies add another layer. Then secure the database. Every layer needs to be in place. Note how they complement each other to achieve better security. Defense in depth considers everything.

Hardening the Operating System
Limit services to required services. Limit users. Use security from the service. Apply all security patches and workarounds. Protect backups. Test security for in-house development. Require strong passwords. Control physical access. Audit system activity. Use intrusion-detection tools. Hardening the Operating System If the operating system is compromised, especially with root access, nothing on the machine is secure. By applying the principle of least privilege, damage due to a breach of a nonroot account can be limited. By reducing services and ports, the attack vectors for obtaining root account access are limited. Keeping Only Required Services A service is any functionality that is provided by a computer to its users. The term is used very broadly, including access to applications, as well as access to data. When possible, do not install unused services with software. Or, if already installed, remove unused services. This reduces your workload because you do not have to maintain security on these services. Also, it reduces the chances that security flaws in these services are used to compromise your security. For example, harden the operating system by removing unused services. Both UNIX and Windows operating systems provide a variety of services, such as FTP, TFTP, and TELNET, that may not be necessary for your deployment. Make sure to close both the UDP and TCP ports for each service that is being disabled. Disabling one type of port and not the other does not make the operating system more secure.

Easing Administration
Examine the security features of the service: Select the features that meet your security requirements. Integrate the features to simplify administration. Ease security administration by: Using single sign-on Delegating security authority Grouping users with common privileges Synchronizing with other sources Easing Administration Complex administrative features that require the time of the system administrator mean that mundane and tedious tasks, such as reviewing audit logs, will be done seldom if at all. Automating and simplifying security functions help to ensure that they are performed. Integrating Security Features Many services include their own security features; others rely on the security features of the host. Some include both capabilities. Examine the security features of all your services, determine which features best meet your security needs, and determine how the security features can be integrated to ease administration. For example, you might want to configure the Oracle database to write audit records to the operating system audit trail. This could simplify administration by centralizing auditing records. Audit trails can be further protected by sending all audit records to a separate machine.

Using a Firewall to Restrict Network Access
Database server Client computers Firewall Application Web server Firewall Using a Firewall to Restrict Network Access A firewall is a single point of control on a network. It is used to prevent unauthorized client computers from reaching the server. It acts as a filter, screening out unauthorized network users from using the intranet. It does this by enforcing access control based on the contents of the packets of data that are being transmitted. Thus, it can protect individual protocols or applications against attacks. Firewalls are rule based. They have a list of rules that define which client computers can connect and which cannot. They can compare the client computer’s host name or IP name with the rules, and either grant the client computer access or not. A firewall must be used in conjunction with other security measure to be effective. For more information about using firewalls, see the appendix titled “Using Oracle Connection Manager as a Firewall.”

Hardening Oracle Services
Harden the database. Harden Oracle Net Services. Use Connection Manager as a firewall. Use available components: Fine-grained access control Enterprise user authentication Encryption Label security Strong authentication by using public key infrastructure or Kerberos Harden the middle tier. Hardening Oracle Services The following topics are covered in subsequent lessons: Hardening the database Hardening Oracle Net Services Using Connection Manager as a firewall Using available components: Fine-grained access control Enterprise user authentication Encryption Label security (requires Oracle Label Security) Strong authentication by using public key infrastructure (PKI) or Kerberos (requires Oracle Advanced Security) Hardening the middle tier

Summary In this lesson, you should have learned how to:
List and describe fundamental security requirements Define the following terms: Principle of least privilege Authorization Authentication Describe some security risks and requirements Describe the concept of security in detail Security Summary Security is not easy. Developing and implementing thorough security policies require management support. The attacks on a secure environment are constantly changing. To counter these risks, sometimes you need to think like a hacker. Maintaining secure environment often requires a certain level of paranoia. The exploits and attacks are becoming more sophisticated. The average administrator or security officer may not have the time or the background to keep up with new attack vectors. The recommendations presented here are derived from the best industry practices. Applying these recommendations may not prevent an attack, but they can help mitigate the damage, reduce the access, and track the offender.

Security Solutions

Objectives After completing this lesson, you should be able to describe the following recommended solutions to common problems: Preventing exploits Maintaining data integrity Protecting data Controlling data access

Preventing Exploits Use industry-standard practices:
Harden the database. Harden the operating system. Harden the network. Preventing Exploits Although there is no guaranteed way to prevent all exploits, you can use industry-standard practices to reduce or eliminate many possible exploits. Harden the database: Use database features to properly authenticate, authorize, and audit the users. Harden the operating system (OS): Use the principle of least privilege to reduce the damage if the OS is compromised. Harden the network: Use firewalls not only to prevent outsiders from accessing your network, but also to reduce and control access of insiders to only needed areas. This is a simple example of defense in depth. Each layer provides another barrier to the unauthenticated or unauthorized user.

Maintaining Data Integrity
Sarbanes-Oxley requires assurance of the integrity of the data that is used to produce financial reports. Oracle Database 10g can provide the following: Standard auditing Fine-grained auditing Privileged-account auditing Network encryption Maintaining Data Integrity Sarbanes-Oxley and other industry regulations require assurance of the integrity of data that is used to produce financial reports. Other data in your organization may have similar requirements. You must track who accessed the data, when it was accessed, and how it was changed. In addition to triggers and integrity constraints, Oracle Database 10g can provide the following: Standard database auditing: Can show the time of access, the user(s) who accessed a database object, or the privilege that was used Fine-grained auditing (FGA): Reveals the SQL statements that were issued; can be focused on the access of specific columns. FGA when used in combination with flashback can show the statement and the data that was viewed. Privileged-account auditing: Can track every statement that is issued by a user who is connected as SYSDBA Network encryption: Prevents the possibility that data was changed in transit

Data Protection Under CA-SB-1386, personally identifiable information must be protected. Use the following techniques: Restrict access. Encrypt stored data. Encrypt network traffic. Restrict network access. Monitor activity. Harden every layer. MyCreditCardNum Data Protection The California Breach Laws CA-SB-1386 and CA-AB-1950 require that personally identifiable information (PII) be protected. If the information has been compromised, the holders of that information must notify all affected individuals. These laws (and similar laws being considered in other states and countries) mean that PII must be protected. Restrict access: This is the first step. Use database hardening and access control to limit the access to authorized persons. Encrypt stored data: This step assumes that the OS can be compromised. Encrypting the stored data protects data files from being scanned by OS utilities. Encrypting the data also assures the protection of backups. Encrypt network traffic: The data must be protected while in transit. For Oracle Net traffic, end-to-end encryption is provided with Oracle Advanced Security (OAS). Restrict network access: Restrict network access to authorized individuals. Departmental or data center firewalls are another layer of protection. Monitor activity: Monitor activity with intrusion detection tools and auditing tools. Unusual activity on the network or database at odd times can signal an attack or illegal access. Harden every layer: Practice defense in depth. Do not neglect the OS, database, or network. OKYMSEISPDTGA

Access Control The law requires that only certain persons may access specific data. Access control and monitoring include: Implement the Virtual Private Database (VPD): Application context Fine-grained access control (FGAC) Use Oracle Label Security (OLS). Apply auditing. Access Control Several laws in the U.S. and other countries limit who may access personal data. National security data, weapons data, and proprietary data require strict access control. Some of the measures that are available in Oracle Database 10g to control and monitor access control are as follows: Implement the Virtual Private Database (VPD) to control access based on user attributes and data characteristics. Application context and fine-grained access control are the database features that are used together to implement the VPD. Use Oracle Label Security (OLS), which is a certified solution that controls access at the row level. OLS is built on the same technology as the VPD, but it does not require in-house development. Apply auditing to assure that only authorized users access the rows and to have accountability for those administrators who are allowed to bypass the row-level controls. Consider all forms of auditing: standard, FGA, and privileged-user auditing.

Middle-Tier Authentication and Authorization
Applications often handle the authentication and authorization for application users. Secure solutions are: Pass-thru Proxy User Secure Application Role Enterprise User Security Middle-Tier Authentication and Authorization Many applications handle the authentication and authorization for application users. This is usually expensive and less secure than other solutions. The expense comes with coding the security into each application, and the application developer may not have the experience to code, test, and maintain the security module. Auditing can be a problem in the environment where the user is not known to the database. Some of the solutions to these problems are: Pass-thru: The user provides the database login credentials. The application server passes the credentials to the database. The database performs the authentication and authorization. Proxy User: The user has a database account, and the application has been granted the privilege to connect on behalf of the user. The connection can be either with or without a user password and may include the privilege to enable some or all of the roles granted to the user. Secure Application Role: The application connects as a low privileged user, and then may enable roles only through a secure package. In this case, the end user may not be known to the database, and the application is responsible for authorizing the user and enabling required roles. Enterprise User Security (EUS): The end user may be a schema-independent user, unknown to the database, but authenticated in Oracle Internet Directory (OID). Application server Database

Network-wide Authentication
Solutions involving single sign-on or single point of authentication reduce administration costs and can improve security. There are several solutions: Oracle Identity Management Enterprise User Security (EUS) Integration with Active Directory Integration with Kerberos Network-wide Authentication For secure systems, users must have strong passwords (longer than x characters, with digits and special characters). When users have multiple accounts, this requirement is often met with resistance and increase help-desk costs for password resets. If a user needs only one strong enterprise-wide password, the resistance and costs diminish. There are several solutions: Oracle Identity Management (OIM) provides single sign-on that is integrated with the Oracle Applications server. OIM can provide self-service password resets and account provisioning (creation). It can be integrated with the existing Lightweight Directory Access Protocol (LDAP) v3 directories. Enterprise User Security (EUS) provides a single point of authentication. EUS can be configured to use passwords, certificates, or Kerberos v5 tickets. It gives administrators a centralized repository for user-account information. Integration with Active Directory (AD) from Microsoft can be used for network-wide authentication. The Oracle database may be configured to use AD as an authentication source. Integration with Kerberos can be used for network-wide authentication. The Oracle database may be configured to use Kerberos as an authentication source.

Summary In this lesson, you should have learned how to describe the following recommended solutions to common problems: Preventing exploits Maintaining data integrity Protecting data Controlling data access

Internal Database Security

Objectives After completing this lesson, you should be able to do the following: Apply the principle of least privilege to the database Apply security patches (Critical Patch Update) Lock and expire default user accounts Change default user passwords Create strong passwords Enforce password management Protect the data dictionary Objectives More Information This lesson also explains how to configure Oracle Database 10g in a secure manner by adhering to industry-standard “best security practices” for operational database deployments. Details about specific database-related tasks and actions can be found in the following: Other lessons in this course Other courses, including the following: Oracle Database 10g: Administration Workshop I Oracle Database 10g: Administration Workshop II Oracle Application Server 10g: Administration I Oracle Application Server 10g: Administration II Oracle Database 10g documentation set For a detailed explanation of the topics covered in this lesson, refer to Oracle Database 10g Security Guide 10g Release 1 (10.1) Part No. B

Database Security: Checklist
Apply the principle of least privilege: Install only what is required. Harden the operating system (OS). Maintain installed products. Manage default user accounts. Enforce password management. Protect the data dictionary. Revoke unnecessary privileges from PUBLIC. Restrict the directories accessible by the user. Limit users with administrative privileges. Restrict remote database authentication. Use other database security features. Database Security: Checklist The Oracle Database 10g server leads the industry in security. However, to fully maximize the security features that are offered, it is imperative that the database itself is well protected. Furthermore, proper use of its security features and adherence to basic security practices help protect against database-related threats and attacks and provide a much more secure operating environment for the database. Practicing the Principle of Least Privilege The principle of least privilege means that a user must be given only those privileges that are required to efficiently complete a task. This reduces the risk of a user, either accidentally or maliciously, modifying the data that he or she does not have the privilege to modify. Hardening the OS Follow the instructions in the lesson titled “Security Requirements.”

Reducing Administration Effort
Use roles to group users by job function. Enable and disable roles as appropriate. Use single sign-on. Reducing Administration Effort Easing Administration of Database Security Group users with the same security requirements into roles. Normally roles are organized around the job function of the employee. These roles are independent of the user. Therefore, if another user needs the same privileges, he or she can be assigned those privileges in a role. If a user is dropped, any directly granted privileges are also dropped. Assigning privileges through roles allows the role definition to exist without being assigned to a user. As users change jobs, roles can be enabled or disabled for each user. When the job responsibilities change or the process changes, different privileges may be required. Then privileges can be added or removed from a role. In sites with large numbers of users or a large number of systems, a significant effort is required just to keep user accounts current on each system so that users can continue to work. Often, administrators do not have the time or the information required to purge accounts of users who no longer have a need for access or users who are no longer authorized. Assume a system with hundreds of users, each with accounts on many systems. When a user is removed, the administrator may not know all the accounts that need to be locked. A central authentication system, which manages the user’s credentials and authorizations, reduces the effort required to manage (both create and purge) accounts.

Installing Only What Is Required
Install only the required products and features. Plan your installation: Determine what needs to be installed. You may require a custom installation. You can always install additional products later. Installing Only What Is Required The Oracle Database 10g CD pack contains many products in addition to the database server. Install additional products and options only as necessary. There is no need to maintain the additional products and options if they are not being used. They can always be properly and easily installed as required. By reducing the number of products installed, you can reduce the possibility of patches being required and also the possibility of software conflicts. And, typically, you can reduce the cost of licenses and maintenance. These principles apply to all software products. Note: The Oracle inventory directory keeps a record of installed software, and patches are only applied to the installed software. In many cases, if a new product or option is installed from the prepatched base distribution, the patches must be reapplied.

Applying Security Patches
Use the Critical Patch Update process. Apply all security patches and workarounds. See the Oracle Security Products Web site. Applying Security Patches Critical Patch Update (CPU) Process Oracle Corporation initiated the CPU process in January 2005 that bundles together critical patches on a quarterly basis. This program replaces the Security Alert patch releases. These patches are cumulative and include commonly requested and required prerequisite patches. The quarterly patch release comes with a risk assessment matrix to enable you to determine for your site the impact and security risks. See MetaLink Note: : “Oracle Critical Patch Update Program General FAQ.” You must subscribe to MetaLink to receive these updates. Applying All Security Patches and Workarounds Always apply all relevant and current security patches for both the operating system on which the database resides and the Oracle software, and for all installed options and components. Referring to the Oracle Security Products Web Site If you find a security vulnerability in the Oracle software, follow the instructions provided at the Security Alerts link at or at

SYS and SYSTEM Accounts
The SYS account: Is granted the DBA role Has all privileges with ADMIN OPTION Is required for startup, shutdown, and some maintenance commands Owns the data dictionary The SYSTEM account is granted the DBA role. These accounts are not used normally. SYS and SYSTEM Accounts The SYS and SYSTEM accounts have the DBA role granted to them by default. The SYS account in addition has all privileges with ADMIN OPTION and owns the data dictionary. To connect to the SYS account, you must use the AS SYSDBA clause. Any user who is granted the SYSDBA privilege can connect to the SYS account by using the AS SYSDBA clause. Only users who are granted the SYSDBA or SYSOPER privilege are allowed to start up and shut down the database instance. The SYSTEM account is granted the DBA role by default, but not the SYSDBA privilege. Applying the principle of least privilege, these accounts are not used for routine operations. Users who need the DBA privileges have separate accounts with the required privileges granted to them. For example, Jim has a low privileged account called jim and a privileged account called jim_dba. This method enables the principle of least privilege to be applied, eliminates the need for account sharing, and enables individual actions to be audited. The SYS and SYSTEM accounts are required accounts in the database. They cannot be dropped.

SYSOPER and SYSDBA SYSOPER and SYSDBA
SYSOPER: It is a special database administration privilege that permits a database administrator to use the STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP, ARCHIVE LOG, and RECOVER commands. This privilege includes the RESTRICTED SESSION privileges. SYSOPER does not have the ability to look at data. When you connect as SYSOPER, you are in the PUBLIC schema with only those privileges that are granted to the PUBLIC user. SYSDBA: It is a special database administration privilege that contains every system privilege with the ADMIN OPTION and SYSOPER system privileges. SYSDBA also permits the CREATE DATABASE actions and incomplete recovery. When you connect with the SYSDBA privileges, you are in the schema owned by SYS. If users are granted the SYSDBA or SYSOPER role, they can connect using their normal account names with the AS SYSDBA clause. For example, Julie connects with the username jsmith but when she needs to shut down the database, she connects with jsmith AS SYSDBA.

Locking and Expiring Default User Accounts
The Database Configuration Assistant (DBCA) expires and locks all accounts, except: SYS SYSTEM SYSMAN DBSNMP For a manual installation, lock and expire accounts by using: ALTER USER hr PASSWORD EXPIRE ACCOUNT LOCK; Locking and Expiring Default User Accounts Oracle Database 10g installs a number of default, preset database server user accounts. During the successful installation of the database server, the Database Configuration Assistant (DBCA) tool automatically locks and expires all default database user accounts, except for the following: SYS SYSTEM SYSMAN DBSNMP MGMTVIEW The MGMTVIEW account, which is used for Oracle Enterprise Manager Database Control, has been granted the MGMT_USER role with only select privileges on some SYSMAN views. In Oracle9i, the following accounts were not locked and expired by the DBCA: SCOTT OUTLN Three JServer accounts: AURORA$JIS$UTILITY$ AURORA$ORB$UNAUTHENTICATED OSE$HTTP$ADMIN Note: The JServer accounts are not installed with Oracle Database 10g.

Changing Default Account Passwords
Default accounts provide easy access to the database. Change the password on any account that has not been locked. To change the password of the SH account to s9049gbnij, run: SQL> ALTER USER sh IDENTIFIED BY s9049gbnij; User altered. SQL> Changing Default Account Passwords The most trivial method by which the database can be compromised is by connecting to a default user account that still has a default password. Several exploits require access only to a low-privilege account. Changing Default Passwords of Administrative Users Change the default passwords associated with the SYS and SYSTEM users immediately upon the installation and initial configuration of the database server. The DBCA and Oracle Universal Installer (OUI) tools force you to change the SYS, SYSTEM, SYSMAN, and DBSNMP passwords when creating new databases. Unlocking Accounts The other default accounts are created with a default password that is exactly the same as the username. For example, the MDSYS user is created with the MDSYS password. If any of the other default user accounts that were locked and expired upon installation need to be activated, then assign a new password to that user account. Patching Locked Default Accounts If the patch process changes the schema objects of an account that is locked, then you may be required to unlock the account for the patch to succeed.

Enforcing Password Management
Use a password verification routine to enforce constraints on the user’s new password. The profile identifies which routine to use: A verification routine is created by the utlpwdmg.s ql script. Use the Oracle Advanced Security option for strong authentication. ALTER PROFILE all_users LIMIT ... PASSWORD_VERIFY_FUNCTION verify_function; Enforcing Password Management Apply the basic password management rules, such as password length, history, and complexity, as provided by the database to all user passwords. Ensure that all users must change their passwords periodically. The password management rules may be applied in the database to manage the database user, or in Oracle Internet Directory to enforce the same rules on enterprise users. Strong Authentication Use Oracle Advanced Security with network authentication services, token cards, smart cards, or X.509 certificates. These services enable strong authentication of users to provide better protection against unauthorized access to the database. Strong Passwords A strong password is a password that is not easily guessed or cracked. It is: Not a dictionary word, jargon, or an easily guessed name (for example, a fictional character) Not related to the username, as in Social Security Number, birth date, or address Not a simple substitution of one of the above with numbers for letters (for example, 3 for E) A strong password has seven or more characters with at least one digit and one special character. This, combined with the requirements above, makes it difficult for users to remember their passwords.

Protecting the Data Dictionary
The data dictionary is protected by default with the initialization parameter set: This configuration prevents users with the ANY system privileges from accessing data dictionary base tables. The SELECT ANY DICTIONARY system privilege allows read access to the dictionary only. O7_DICTIONARY_ACCESSIBILITY = FALSE Enabling Data Dictionary Protection In Oracle Database 10g, by default the data dictionary is protected to prevent users having the ANY system privileges from using such privileges on the data dictionary. The initialization parameter that controls this behavior is: O7_DICTIONARY_ACCESSIBILITY = FALSE This configuration does not restrict users who have the DBA privilege, such as SYSDBA. If a user requires view access to the data dictionary, it is permissible to grant that user the SELECT ANY DICTIONARY system privilege. This configuration allows the user to read the data dictionary, but does not give the user access to objects owned by other schemas. In Oracle9i and later releases, the default value for O7_DICTIONARY_ACCESSIBILITY is FALSE. However, in Oracle8i, it defaults to TRUE. Therefore, you must manually set it to FALSE to enable data dictionary protection. Example If this parameter is not set to FALSE, any user with a DROP ANY TABLE system privilege can drop parts of the data dictionary either maliciously or accidentally.

System and Object Privileges
Applying the principle of least privilege: Limit object privileges to actual needs Do not use GRANT ALL ON object Limit system privileges Do not grant the DBA role to users Encapsulate sensitive objects System and Object Privileges Analyze your system, keeping the principle of least privilege in mind. This requires more effort, but it can prevent misuse. There will always be bugs, and ingenious individuals will find new ways of exploiting weaknesses in the very complex business systems that have been deployed. Although the next exploit cannot be predicted, if you put the principle of least privilege into practice, the number and severity of possible exploitations can be reduced. Grant only the privileges required. The GRANT ALL… command gives a user the ability to drop or alter a database object. These privileges must be reserved to the database administrator (DBA) and the object owner, except in special cases. Granting the DBA role must be limited to the actual DBA. At many sites even the DBA role has more privileges than required, and a new role must be created with a subset of the DBA role privileges. The CONNECT, RESOURCE, and DBA roles are provided in the database for backward compatibility. These roles have more privileges than are required in most cases. Create new roles customized to the requirements of your site. Encapsulate objects containing sensitive data and access them only through stored procedures and packages. Sensitive data is not just data of a confidential nature, but data and objects that must be kept correct to prevent business disruption. The stored procedure can apply stringent controls on what can be updated easily. These procedures can also provide auditing mechanisms beyond the capability of database auditing features.

Restricting the Directories Accessible by the User
Do not use the UTL_FILE_DIR parameter. Use the DIRECTORY objects: Allows granular access to directory paths by the user Allows read or write access separately Is limited to the directories that the Oracle process can access Example: CREATE DIRECTORY local AS '/user/local/dbs'; GRANT READ, WRITE ON DIRECTORY local TO scott; Restricting the Directories Accessible by the User The UTL_FILE_DIR configuration parameter has been deprecated in favor of the DIRECTORY object. By default, no directories can be accessed. With UTL_FILE_DIR, all PL/SQL users can read from or write to all files in the directories specified by this parameter. Thus, all PL/SQL users must be trusted with the information in the directories specified by this parameter. Never set UTL_FILE_DIR = *, because this enables access to all directories accessible by the Oracle instance, including the data file and redo log directories. Directory Objects The recommended method of controlling database-user access to OS directories is through directory objects. Any OS path that is accessible to the Oracle software owner can be accessed through a directory object. A DIRECTORY object is created with a name and a path, as shown in the slide. All directories are created in a single namespace and are not owned by an individual schema. You must have the CREATE ANY DIRECTORY system privilege to create directories. When a user creates a directory, that user is automatically granted the READ and WRITE object privileges on the directory with grant option. The DBA can also grant these privileges to other users and roles.

Limiting Users with Administrative Privileges
Restrict the following types of privileges: Grants of system and object privileges SYS-privileged connections: SYSDBA and SYSOPER DBA-type privileges, such as DROP ANY TABLE Restrict run-time permissions. Example: List all users with the DBA role: SQL> SELECT grantee FROM dba_role_privs 2 WHERE granted_role = 'DBA'; GRANTEE SYS SYSTEM Limiting Users with Administrative Privileges Do not provide database users more privileges than necessary. To implement the least privilege, restrict the following types of privileges: Grants of system and object privileges SYS-privileged connections to the database, such as SYSDBA and SYSOPER Other DBA-type privileges, such as DROP ANY TABLE Restricting Permissions on Run-Time Facilities Do not assign all permissions to any database server run-time facility, such as the Oracle Java Virtual Machine. Grant specific permissions to the explicit file paths for such facilities that may execute files and packages outside the database server. The following example of a vulnerable run-time gives SCOTT read access to all files and directories below the root directory: call dbms_java.grant_permission ( 'SCOTT', 'SYS:java.io.FilePermission', '/-', 'read' ); The following example of a better and more secure run-time call restricts SCOTT to reading all the files in the HR directory: 'SCOTT', 'SYS:java.io.FilePermission', '/hr/*', 'read' ); Example The example in the slide lists all users who have the DBA role granted to them. The two users displayed are the built-in users with the DBA role granted.

Separation of Responsibilities
Users with DBA privileges must be trusted, but separation of responsibilities can: Prevent abuse of trust Allow audit trails to protect the trusted position To implement separation of trust: DBA responsibilities must be shared Accounts must never be shared DBA and system administrator must be different people SYSOPER and SYSDBA responsibilities must be separated. Separation of Responsibilities These are the main requirements for a satisfactory separation of duties. Many small companies do not have enough people to fulfill all these requirements. DBAs must be trusted. It is hard to restrict a DBA. To do their job, DBAs require high-level privileges. A DBA has a position of trust and must be thoroughly vetted. Even a trusted DBA must have accountability. A policy of separation of responsibility can: Prevent abuse of trust: A DBA can view the encrypted passwords in the DBA_USERS table. The DBA can save any user’s encrypted password, change the password, and connect as that user. When finished, the DBA can replace the user’s original password by using the following command: ALTER USER username IDENTIFIED BY VALUES 'encrypted_password'; The DBA need not know the original password. This action is not traceable unless auditing for the ALTER ANY USER privilege is turned on. Allow audit trails protect the trusted position: When auditing is carefully implemented and the guidelines have been followed, the audit trail can show that the particular person did not violate procedures or commit a damaging act. If a malicious user tries to cast suspicion on a trusted user, well-designed audit trails catch the act. In the lesson titled “Database Auditing,” you implement auditing on the SYSDBA users.

Using Other Database Security Features
Authenticate the users through the middle tier. Use secure application roles. Use virtual private databases. Audit user activity, especially privileged activity. Encrypt columns for additional privacy protection. Using Other Database Security Features Use the following database features to restrict data access: Enable and disable roles to restrict the current privileges of a user. Enabling and disabling roles are discussed in the Oracle Database 10g: Administration Workshop I course. Use secure application roles to enable roles only after they pass a validation check. Use virtual private databases to limit the rows that a user can access from a table of view. Encrypt columns for additional privacy protection. Secure application roles, middle-tier authentication, virtual private databases, and encryption are covered in subsequent lessons in this course.

Apply the principle of least privilege to the database Apply security patches (Critical Patch Update) Lock and expire default user accounts Change default user passwords Create strong passwords Enforce password management Protect the data dictionary

Database Auditing

Objectives After completing this lesson, you should be able to do the following: Implement basic database auditing Implement auditing of the privileged user Implement DML and DDL auditing

Monitoring for Suspicious Activity
Monitoring or auditing should be an integral part of your security procedures. The built-in audit tools in Oracle Database 10g include: Database auditing Value-based auditing Fine-grained auditing (FGA) Monitoring for Suspicious Activity Even authorized, authenticated users can sometimes compromise your system. Identifying unusual database activity (such as an employee who suddenly begins querying large amounts of credit card information, research results, or other sensitive information) can be the first step to detecting information theft. Oracle Database 10g provides a rich set of auditing tools to track user activity and identify suspicious trends. Oracle Database 10g provides three different types of auditing. The administrator can audit all actions that take place within the database. It is important to remember that capturing and storing information about what is happening in the system increases the amount of work the system must do. Auditing should be focused so that only events that are of interest are captured. Properly focused auditing has minimal impact on system performance. Improperly focused auditing can significantly affect performance. Standard database auditing captures several pieces of information about an audited event, including that the event occurred, when it occurred, the user who caused the audited event, and which client machine the user was on when the event happened.

Audit Tool Comparisons
Fixed set of data, including the SQL statement SQL statements (INSERT, UPDATE, DELETE, and SELECT) based on content Fine-grained auditing (FGA) Administrator defined Data changed by DML statements Value-based auditing Fixed set of data Privilege use including object access Standard database auditing What Is in the Audit Trail? What Is Audited? Type of Audit Audit Tool Comparisons Several new features have been added to fine-grained auditing in Oracle Database 10g. Data manipulation language (DML) statement auditing, including MERGE, has been added. Multiple columns per policy and auditing of large objects (LOBs) have been added. In Oracle9i, only SELECT statements could be audited. Each policy could name only one relevant column, and LOB auditing was implemented through event handlers, if required.

Standard Database Auditing
Is enabled through the AUDIT_TRAIL parameter NONE: Disables collection of audit records DB: Enables auditing with records stored in the database OS: Enables auditing with records stored in the OS audit trail Can audit: Login events Exercise of system privileges Exercise of object privileges Use of SQL statements Standard Database Auditing To use database auditing, you must first set the nondynamic AUDIT_TRAIL parameter to point to a storage location for audit records. The normal setting for this parameter is DB, which causes audit records to be stored in the DBA_AUDIT_TRAIL table. Database auditing can capture information about login events, the exercise of system privileges, and the exercise of object privileges. Audit information can be focused by the user generating the audit event or by the status of the event (successful or not). The following audit command that generates information is probably not required because it is not well focused. This option captures any operation that affects any table: SQL> AUDIT TABLE; Audit succeeded. A better example of an audit command (because it is more narrowly focused) is: SQL> AUDIT DELETE ON hr.employees WHENEVER SUCCESSFUL;

Specifying Audit Options
SQL statement auditing: System-privilege auditing (nonfocused and focused): Object-privilege auditing (nonfocused and focused): AUDIT table; AUDIT select any table, create any trigger; AUDIT select any table BY hr BY SESSION; Specifying Audited Options SQL statement auditing: The statement shown in the slide can audit any data definition language (DDL) statement that affects a table, including CREATE TABLE, DROP TABLE, TRUNCATE TABLE, and so on. SQL statement auditing can be focused by username or by success or failure: SQL> AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL; System-privilege auditing: It can be used to audit the exercise of any system privilege (such as DROP ANY TABLE). It can be focused by username or by success or failure. By default, auditing is BY ACCESS. Each time an audited system privilege is exercised, an audit record is generated. You can choose to group those records with the BY SESSION clause so that only one record is generated per session (this way, if a user updates 100,000 records in a table belonging to another user, you only gather one audit record). Consider using the BY SESSION clause to limit the performance and storage impact of system-privilege auditing. Object-privilege auditing: It can be used to audit actions on tables, views, procedures, sequences, directories, and user-defined data types. This type of auditing can be focused by success or failure and grouped by session or access. Unlike system-privilege auditing, the default grouping is by session. So you must implicitly specify BY ACCESS if you want a separate audit trail record generated for each action. AUDIT ALL on hr.employees; AUDIT UPDATE,DELETE on hr.employees BY ACCESS;

Auditing Sessions Audit unsuccessful attempts to connect:
Monitor DBA_AUDIT_SESSION: Check DBA_AUDIT_TRAIL.COMMENT_TEXT. AUDIT CREATE SESSION BY ACCESS WHENEVER NOT SUCCESSFUL; USERNA ACTION_NAME RETURNCODE LOGOFF FRED LOGON FRED LOGOFF :39 FRED LOGOFF BY CLEANUP :40 FRED LOGON Auditing Sessions The AUDIT SESSION option audits the creation of user sessions in the database by auditing the CREATE SESSION privilege. It can be focused by username or by success or failure. This option is unique because it generates a single audit record for each session created by connections to an instance. An audit record is inserted into the audit trail at connect time and updated at disconnect time. Cumulative information about a session (such as connection time, disconnection time, and logical and physical I/Os processed) is stored in a single audit record that corresponds to the session. In many databases, it is common to use the AUDIT SESSION (unfocused) command. In almost all databases, you should audit unsuccessful login attempts because this allows you to detect attempts to break into your database. The AUDIT SESSION command is one of the primary sources of confusion for new auditors. Records produced by this audit option are unusual in that they are updated after the initial write to the audit trail. The initial record is written with an action of LOGON, and when the user disconnects, the record is updated and the action is changed. This can cause confusion. You find only a scattering of the LOGON records, but many LOGOFF records in the audit trail. If AUDIT SESSION is enabled, session statistics are accumulated for each successful connection and written when the session ends.

Viewing Auditing Options
Data Dictionary View ALL_DEF_AUDIT_OPTS DBA_STMT_AUDIT_OPTS DBA_PRIV_AUDIT_OPTS DBA_OBJ_AUDIT_OPTS Description Default audit options Statement auditing options Privilege auditing options Schema object auditing options Viewing Auditing Options To see which audit options have been selected, use the views listed in the slide. DBA_STMT_AUDIT_OPTS and DBA_PRIV_AUDIT_OPTS contain only records of statement or privilege audit options that have been specified. DBA_OBJ_AUDIT_OPTS contains one record per auditable object regardless of what object audit options have been specified. The view shows a column for each auditable option. For example, INSERT audit options are shown in the INS column. Audit options are displayed as SUCCESSFUL/NOT SUCCESSFUL with three possible values for each status: - Not audited S Collect audit records by session A Collect audit records by access SQL> SELECT object_name, object_type, ins, upd FROM dba_obj_audit_opts WHERE object_name = 'EMPLOYEES‘ OBJECT_NAME OBJECT_TY INS UPD EMPLOYEES TABLE A/S -/-

Standard Database Auditing
Enable database auditing. Parameter file DBA User executes command. Specify audit options. Database Server process Audit options Generate audit trail. Audit trail Standard Database Auditing After the administrator has enabled database auditing (with the AUDIT_TRAIL parameter) and specified auditing options (with SQL statements as shown on the previous few pages), the database begins collecting audit information. If AUDIT_TRAIL is set to OS, the audit records are stored in the operating system’s audit system. On a Windows system, this is the event log. On a UNIX or Linux system, audit records are stored in a file. AUDIT_FILE_DEST specifies the location of the audit file. If AUDIT_TRAIL is set to DB, audit records are stored in the AUD$ table that is part of the SYS schema. The AUD$ table is stored in the SYSTEM tablespace by default. The AUD$ table can be moved as described in MetaLink Note: The AUD$ table is moved to the SYSTEM schema when Oracle Label Security (OLS) is installed. It is important to protect the audit trail. A knowledgeable person would do his or her best to remove traces of unauthorized activity from the audit trail. Export the audit trail regularly if it is in the database. If it is on the OS, copy it to another machine. Maintaining the audit trail is an important administrative task. Depending on the focus of the audit options, the audit trail can grow very large very quickly. If not properly maintained, the audit trail can consume so much space that it affects the performance of the system. OS audit trail Review audit information.

Viewing Auditing Results
Audit Trail View DBA_AUDIT_TRAIL DBA_AUDIT_EXISTS DBA_AUDIT_OBJECT DBA_AUDIT_SESSION DBA_AUDIT_STATEMENT Description All audit trail entries Records for AUDIT EXISTS/NOT EXISTS Records concerning schema objects All connect and disconnect entries Auditing records at the statement level Viewing Auditing Results Access to audit records should be tightly controlled because they may contain sensitive information. Usually the task of managing the audit trail is handled by the administrator. But if it needs to be delegated, DELETE_CATALOG_ROLE grants permission to delete it from the audit trail. The audit trail and the privileges required to access it must be audited, with a method different from standard auditing.

Auditing the SYSDBA and SYSOPER Users
Control auditing of privileged users with the following parameters: audit_sys_operations enables additional auditing of the SYSDBA or SYSOPER actions. audit_file_dest controls the location of the audit trail. The default is: $ORACLE_HOME/rdbms/audit (UNIX or Linux) Windows Event Log (Windows) Auditing the SYSDBA and SYSOPER Users The SYSDBA and SYSOPER users have privileges to start and shut down the database. Because they may make changes while the database is closed, the audit trail for these privileges must be stored outside the database. The instance captures login events by the SYSDBA and SYSOPER users automatically, but does not capture anything other than the login events unless auditing is specifically enabled. The audit trail file requires frequent monitoring due to growth. Enable the auditing of the SYSDBA and SYSOPER users by setting the initialization parameter: audit_sys_operations=TRUE (the default is FALSE) If SYS operations are audited, the audit_file_dest initialization parameter controls where the audit records will be stored. On a Windows platform, the audit trail defaults to the Windows Application Log. On UNIX or Linux platforms, audit records are stored in $ORACLE_HOME/rdbms/audit. The audit file on Linux is named ora_N.aud, where N is the process ID. Note: All the initialization parameters affecting auditing are static.

Viewing the SYSDBA Audit Trails
Even if the DBA is trusted, it is critical to review failed connections to the SYSDBA account. This is the only way to detect a password-cracking attempt against SYSDBA. A brute-force attack against the password of a known sysdba account eventually succeeds. The SYSDBA connection attempts always go to the OS audit log regardless of whether SYSDBA auditing is enabled. But these records are often ignored or deleted to conserve space. The SYSDBA auditing provides a valuable way to track authorized or unauthorized SYSDBA actions, but it is only useful if the OS audit trail is reviewed. On the Windows platform, audit information is always written to the Event Viewer. So, AUDIT_FILE_DEST is not supported in Windows. The audit record is viewed by navigating to the Event Viewer and selecting the Application Log. Notice that in the slide a record with a source of Oracle.orcl is selected for viewing. Some operations (such as startup and shutdown, and connect attempts) are always captured. An excerpt from the audit file from a Linux system is shown on the next page.

It is inserted into an audit trail table.
Value-Based Auditing A user makes change. Trigger fires. Audit record is created by trigger. The user’s change is made. It is inserted into an audit trail table. Value-Based Auditing Database auditing records that inserts, updates, and deletes have occurred on audited objects, but does not capture the actual values that have been changed. Value-based auditing extends database auditing, capturing the actual values that have been changed. Value-based auditing leverages database triggers (event-driven PL/SQL constructs). When a user inserts, updates, or deletes data from a table with the appropriate trigger attached, the trigger works in the background to copy audit information to a table designed to contain the audit information. Value-based auditing tends to degrade performance more than standard database auditing because the audit trigger code must be executed each time the insert, update, or delete operation occurs. The degree of degradation depends on the efficiency of the trigger code. Value-based auditing should be used only in situations where the information captured by standard database auditing is insufficient.

Triggers and Autonomous Transactions
Further enhance and protect the auditing by: Capturing DML changes to shadow table Replicating audit records to another table Capturing attempts to change audit records Triggers and Autonomous Transactions You can use database triggers to log events transparently. Suppose that you want to track all DML changes to a table, even those that roll back. You can use a trigger to insert duplicate rows into a shadow table as an autonomous transaction. Because it is autonomous, the trigger can commit changes to the shadow table whether or not you commit changes to the main table. The transaction of autonomous triggers is independent of the transaction and action that fire the trigger. See a full example on the next page.

Implement basic database auditing Implement auditing of the privileged user Implement DML and DDL auditing

Fine-Grained Auditing

Objectives After completing this lesson, you should be able to do the following: Implement fine-grained auditing (FGA) Maintain FGA policies Implement an FGA audit event handler Read FGA audit events from the FGA audit trail

Fine-Grained Auditing (FGA)
Monitors data access based on content Audits SELECT, INSERT, UPDATE, or DELETE Can be linked to a table or view May fire a procedure Is administered with the DBMS_FGA package Policy: AUDIT_EMPS_SALARY SELECT name, salary FROM employees WHERE department_id = 10; Fine-Grained Auditing (FGA) Database auditing records that an operation has occurred, but does not capture information about the statement that caused the operation. Fine-grained auditing (FGA) extends that capability to allow the capture of actual SQL statements that query or manipulate data. FGA also allows auditing to be more narrowly focused than standard or value-based database auditing. FGA audit options can be focused by individual columns within a table or view, and can even be conditional so that audits are captured only if certain administrator-defined specifications are met. Unlike value-based auditing, FGA does not require the use of database triggers and has a performance impact similar to standard database auditing. The administrator uses the DBMS_FGA PL/SQL package to create an audit policy on the target table or view. If any of the rows returned from a query block matches the audited column and the audit condition, then an audit event causes an audit record to be created and stored in the audit trail. Optionally, the audit event can also execute a procedure. FGA automatically focuses auditing at the statement level. So a SELECT statement that returns thousands of rows generates only one audit record. employees

FGA Policy Defines: Is created with DBMS_FGA .ADD_POLICY
object_schema => 'hr', object_name => 'employees', policy_name => 'audit_emps_salary', audit_condition=> 'department_id=10', audit_column => 'salary', handler_schema => 'secure', handler_module => 'log_emps_salary', enable => TRUE, statement_types=> 'select' ); Defines: Audit criteria Audit action Is created with DBMS_FGA .ADD_POLICY SELECT name, job_id FROM employees; SELECT name, salary FROM employees WHERE department_id = 10; FGA Policy The example in the slide shows an FGA policy being created with the DBMS_FGA.ADD_POLICY procedure. The procedure accepts the following arguments: Policy Name Assign each FGA policy a name when you create it. The example in the slide names the policy AUDIT_EMPS_SALARY, using the following argument: policy_name => 'audit_emps_salary' Audit Condition The audit condition is a SQL predicate that defines when the audit event should fire. In the example in the slide, all rows in the sales department are audited, using the following condition argument: audit_condition => 'department_id = 10' Statement Type Which type of statements should be audited? The choices are SELECT and (all one string) INSERT, UPDATE, or DELETE. SECURE.LOG_ EMPS_SALARY employees

Triggering Audit Events
The following SQL statements cause an audit: The following statement does not cause an audit: SELECT count(*) FROM hr.employees WHERE department_id = 10 AND salary > v_salary; SELECT salary FROM hr.employees; SELECT last_name FROM hr.employees WHERE department_id = 10; Triggering Audit Events In general, the FGA policy is based on columns audited and simple user-defined SQL predicates. During parsing whenever policy conditions are met for a statement, the statement is audited, and if there is an event handler, it is also fired. The audit function is executed as an autonomous transaction. Each audit policy is applied individually. That is, as long as the rows being returned or changed fit into any of the audit conditions defined on the table, an audit record is generated, and there is one record generated for each policy per SQL statement. Examples The first two examples in the slide cause an audit event because they access the salary column and rows with department_id = 10. The Oracle database server is aware that the second example accesses the rows in department 10, even though department_id is not referenced in the SQL statement WHERE clause. No audit record is created if there are no records for department 10. The last example does not cause an audit event because the salary column is not accessed. If the salary column had not been specified as AUDIT_COLUMN when the policy was created, then this SELECT statement would cause an audit event. Metalink Note: “10g: Fine Grained Auditing” gives full examples of FGA behavior.

Data Dictionary Views All FGA policies for objects in the current user schema USER_AUDIT_POLICIES All FGA policies in the database DBA_AUDIT_POLICIES All FGA policies for objects that the current user can access ALL_AUDIT_POLICIES All FGA events DBA_FGA_AUDIT_TRAIL Description View Name Data Dictionary Views FGA audit entries are logged into a separate table from object and privilege audits. The entries are recorded in the DBA_FGA_AUDIT_TRAIL view. The other three views listed in the slide contain policy definitions.

DBA_FGA_AUDIT_TRAIL SQL> SELECT to_char(timestamp, 'YYMMDDHH24MI')
AS timestamp, 3 db_user, 4 policy_name, 5 sql_bind, 6 sql_text 7 FROM dba_fga_audit_trail; TIMESTAMP DB_USER POLICY_NAME SQL_BIND SQL_TEXT SYSTEM AUDIT_EMPS_SALARY #1(4):1000 SELECT count(*) FROM hr.employees WHERE department_id = 10 AND salary > :b1 DBA_FGA_AUDIT_TRAIL Name Description TIMESTAMP The date and time of execution DB_USER The database name of the user who is executing OS_USER The operating system name of the user who is executing OBJECT_SCHEMA The owner of the audited object OBJECT_NAME The name of the audited object POLICY_NAME The policy name that caused the audit event SCN The system change number (SCN) of the transaction SQL_TEXT The SQL statement causing the audit event SQL_BIND The bind variable of the audit event, formatted as #n(s):v: where n is the number of the bind variable in the statement, s is the bind variable length, and v is the bind variable value COMMENT$TEXT A comment Note: This is a partial list of columns available in dba_fga_audit_trail. For more information, refer to the Oracle Database Reference Guide.

DBA_FGA_AUDIT_TRAIL (continued) Selecting from the FGA Audit Trail
The following example displays the two audit rows created by the valid examples from the previous page. The sql_bind column in the second row has a value of #1(4):1000, which includes the following components: #1 indicates that this is the first bind variable in the statement. (4) Indicates that the bind variable has a length of 4. 1000 indicates that the bind variable has a value of 1000. Example The output below is from the SQL statement in the slide, except that it also includes a row for a policy without a bind variable: TIMESTAMP DB_USER POLICY_NAME SQL_BIND SQL_TEXT SYSTEM AUDIT_EMPS_SALARY #1(4):1000 SELECT count(*) FROM hr.employees WHERE department_id = AND salary > :b SYSTEM AUDIT_EMPS_SALARY SELECT salary FROM hr.employees

DBMS_FGA Package Use DBMS_FGA to maintain FGA policies.
Grant the EXECUTE privilege only to administrators. The DBMS_FGA package includes the following subprograms: Disables an audit policy DISABLE_POLICY Enables an audit policy ENABLE_POLICY Drops an audit policy DROP_POLICY Creates an audit policy by using the supplied predicate as the audit condition ADD_POLICY Description Subprogram DBMS_FGA Package The DBMS_FGA package is the administration tool for FGA functions. The EXECUTE privileges on DBMS_FGA are needed to administer FGA policies. Because the FGA trail can contain sensitive information, the EXECUTE privileges on this package must be reserved for administrators only.

Enabling and Disabling an FGA Policy
Enable a policy: Disable a policy: dbms_fga.enable_policy ( object_schema => 'hr', object_name => 'employees', policy_name => 'audit_emps_salary' ); dbms_fga.disable_policy ( object_schema => 'hr', object_name => 'employees', policy_name => 'audit_emps_salary' ); Enabling and Disabling an FGA Policy Disabling an FGA policy means that the policy does not generate audit events. You can cause the policy to start generating log events again by enabling it. By default, the policy is enabled when it is created. The example in the slide shows how to enable and disable a policy. For both procedures, all arguments are required.

Dropping an FGA Policy SQL> EXEC dbms_fga.drop_policy ( -
> object_schema => 'hr', - > object_name => 'employees', - > policy_name => 'audit_emps_salary'); PL/SQL procedure successfully completed. SQL> Dropping an FGA Policy If you no longer require an FGA policy, you can remove it with DBMS_FGA.DROP_POLICY. All arguments are required.

FGA Usage To audit all statements, use a null condition.
If you try to add a policy that already exists, error ORA is raised. The audited table or view must already exist when you create a policy. If the audit condition syntax is invalid, an ORA is raised when the audited object is accessed. If the audit column does not exist in the table, no rows are audited. If the event handler does not exist, no error is returned, and the audit record is created. FGA Usage Audit Condition When creating a new FGA policy, the audit condition defaults to null, which means all statements will be audited. FGA with null (audit all) can be extremely useful in capturing SQL to determine whether tuning (or developer training) is needed. It can also help troubleshoot data corruption from GUI applications by capturing the data manipulation language (DML) plus bind variables. Policy-Name Error Policy names must be unique within the database. They have no owner. If a duplicate name is used, you receive the following error when creating the policy: ORA-28101: policy already exists Audited-Object Errors The audited table or view must exist when you create the policy. If it does not, you receive the following error: ORA-00942: table or view does not exist

Maintaining the Audit Trail
Maintaining the audit trail must include: Reviewing and storing old records Preventing storage problems Avoiding loss of records Maintaining the Audit Trail Each type of audit trail must be maintained. Basic maintenance must include reviewing the audit records and removing older records from the database or operating system. Audit trails can grow to fill the available storage. If the file system is full, the system may crash or just cause performance problems. If the database audit trail fills the tablespace, audited actions do not complete. If the audit trail fills the system tablespace, the performance of other operations are affected before audit operations halt. The audit trail for standard auditing is stored in the AUD$ table. The audit trail for FGA auditing is the FGA_LOG$ table. Both these tables are created in the SYSTEM tablespace by default. You can move these tables to another tablespace by using the export and import utilities. Note: Moving the audit tables out of the SYSTEM tablespace is not supported, but it should work (see MetaLink Note ). The audit tables must be in the SYSTEM tablespace during upgrades. Audit records can be lost during the process of removing records from the audit tables. A copy operation that is followed by a delete or truncate operation can remove records that are not captured by the copy operation. A better method is to perform an export of records that is based on the timestamp, and then delete those records that have the same (or an earlier) timestamp.

Selective Audit Uniquely integrates Oracle database auditing technologies in one tool, including: Standard auditing at database, user, and object levels FGA at row and column levels SQL Capture Flashback Query Log Miner Provides audit analysis, reporting, and graphing Proactively alerts on audit events Selective Audit It is a graphical tool developed by Oracle Advanced Performance Group (APG) and Civilian Consulting on the basis of requirements from intelligence and law-enforcement agencies. The purpose of this tool is to provide in one place the ability to manage the various Oracle database auditing features. This tool provides audit analysis, reporting, and graphing. Manages Auditing Features Oracle Standard Auditing (over 250 audit actions): Auditing at database, user, and object levels—DBA_AUDIT_TRAIL Oracle Fine-Grained Auditing: Auditing at the row and column level—DBA_FGA_AUDIT_TRAIL SQL Capture: Captures the SQL text and bind variables Oracle Flashback Query: Allows replay of the query with the original data Oracle Log Miner: Allows tracking of all transaction-related changes. Provides Audit-Analysis Tools: Reporting and Graphing The audit trail’s SQL statement can be converted to a query and executed, and it can then be compared with the redo and archive log data for additional transaction data. Proactively Alerts on Audit Events Alerts and notifications can be configured on audit events.

Summary In this lesson, you should have learned how to: Implement FGA
Maintain FGA policies Implement an FGA audit event handler Read FGA audit events from the FGA audit trail

Basic User Authentication

Objectives After completing this lesson, you should be able to do the following: Authenticate users with passwords Protect passwords Authenticate users with the operating system (OS) Restrict remote OS authentication Protect database link passwords Audit database links Objectives More Information This lesson also explains how to configure Oracle Database 10g in a secure manner by adhering to industry-standard “best security practices” for operational database deployments. Details about specific database-related tasks and actions can also be found in the following: Other lessons in this course Other courses, including the following: Oracle Database 10g: Administration Workshop I Oracle Database 10g: Administration Workshop II Oracle Application Server 10g: Administration I Oracle Application Server 10g: Administration II Oracle Database 10g documentation set For a detailed explanation of the topics covered in this lesson, refer to the Oracle Database 10g Security Guide 10g Release 1 (10.1) Part No. B

User Authentication Identify the user in the following ways:
Basic authentication Database user identified by a password Database user identified by the operating system Strong authentication Enterprise User Security Proxy authentication User Authentication A basic security requirement is that you must know your users. You must identify them before you can determine their privileges and access rights, so that you can audit their actions on the data. In this lesson, you create and audit database authenticated users and operating system authenticated users. Users can be authenticated in a number of different ways before they are allowed to create a database session. In database authentication, you can define users such that the database performs authentication of users. In external authentication, you can define users such that authentication is performed by the operating system or network service. In later lessons, you see that you can define users such that they are authenticated by strong authentication methods: certificates, smart cards, and Kerberos. Enterprise users are authenticated through an enterprise directory and authorized for access to the database through enterprise roles. Finally, you can specify users who are allowed to connect through a middle-tier server. The middle-tier server authenticates and assumes the identity of the user and is allowed to enable specific roles for the user. This is called proxy authentication.

User Identified by a Password
A database user: Has a schema Is easily audited Is authenticated by a password in the database CREATE USER username IDENTIFIED BY password;

User Identified Externally
A database user: Has a schema Is easily audited Is authenticated by the operating system CREATE USER username IDENTIFIED EXTERNALLY;

Protecting Passwords A password must never be embedded in files.
Beware that passwords entered on the command line are visible to ps. Beware that passwords placed in an environment variable is visible to ps. Use externally authenticated users for server scripts and tools. Protecting Passwords Passwords used in scripts, job schedulers, and command lines are vulnerable. A password must never be placed in script files in clear text. Even passwords embedded in executable files are vulnerable to the strings command or a hex editor. Entering the password on the command line may seem safe if no one sees you type it. But on some UNIX systems, it is possible to view the full command line including the username and password by using the ps command with the appropriate switches. If an OS account is compromised, someone viewing the shell command history file may find passwords to privileged database accounts. Using environment variables to hold a password is also vulnerable to ps with the show environment switch. The externally authenticated database user account is a secure way to protect the password: CREATE OPS$FRED IDENTIFIED EXTERNALLY; GRANT CREATE SESSION TO OPS$FRED; Suppose Fred is a database administrator (DBA) and needs to run batch jobs on the server machine. With the two preceding commands, an OS user with a login of fred can now connect to the database with “/” and run a script without a password: sqlplus

Restricting Remote Database Authentication
Remote authentication must be used only when you trust all clients to appropriately authenticate users. In the remote authentication process: The client authenticates the user. The user logs in to the database without further authentication. To disable, use the following instance initialization parameter: REMOTE_OS_AUTHENT = FALSE Restricting Remote Database Authentication When the remote authentication security feature is enabled (TRUE), it defers authentication of database users to the remote client. This means that the database implicitly trusts any client to have authenticated the user properly. Many clients, such as PCs, cannot be trusted to perform operating system authentication properly and, therefore, it is a very poor security practice to turn on this feature. Any machine can be broken into unless the machine is physically secure. When OS_AUTHENT_PREFIX is set to the default OPS$ or any string other than the null string, and REMOTE_OS_AUTHENT is TRUE, any user with externally identified user account is vulnerable. A malicious user may create an account on a client machine that matches OPS$<username> on the server. When logged on to the client machine as that user, he or she can access the database with sqlplus For a more secure configuration, disable this feature so that the database enforces proper, server-based authentication of users connecting to an Oracle database. To restrict remote authentication, set the initialization parameter by using the following statement: REMOTE_OS_AUTHENT = FALSE FALSE is the default value for this parameter.

Fixed Database Links Create a public fixed database link:
Use a public database link: CREATE PUBLIC DATABASE LINK test CONNECT TO scott IDENTIFIED BY tiger USING ‘FINANCE’; SELECT * FROM connect scott/tiger Fixed User Database Links To create a fixed user database link, you embed the credentials (in this case, a username and password) required to access the remote database in the definition of the link: CREATE DATABASE LINK ... CONNECT TO username IDENTIFIED BY password ...; The following statement creates a public link to the remote supply database by using the global database name. The link connects to the remote database with the user ID and password as scott and tiger, respectively: CREATE PUBLIC DATABASE LINK supply.us.acme.com CONNECT TO scott IDENTIFIED BY tiger; The following statement creates a private fixed user link called foo to the database with service name‘finance’. The link connects to the remote database with the user ID and password as jane and doe, respectively: CREATE DATABASE LINK foo CONNECT TO jane IDENTIFIED BY doe USING 'finance'; When an application uses a fixed user database link, the local server always establishes a connection to a fixed remote schema in the remote database. The local server also sends the fixed user’s credentials across the network when an application uses the link to access the remote database. FINANCE

Viewing Database Link Passwords
A privileged user may view database link passwords: The passwords for fixed links are stored in clear text: SELECT USERID,PASSWORD FROM SYS.LINK$ WHERE PASSWORD IS NOT NULL; USERID PASSWORD SYSTEM ORACLE SCOTT TIGER Viewing Database Link Passwords Only USER_DB_LINKS contains a column for password information. However, if you are an administrative user (SYS or users who connect to SYS by using AS SYSDBA), you can view passwords for all links in the database by querying the LINK$ table. If you are not an administrative user, you can be authorized to query the LINK$ table by one of the following methods: Being granted specific object privilege for the LINK$ table Being granted the SELECT ANY DICTIONARY system privilege (Oracle Database 10g removes LINK$ from SELECT ANY DICTIONARY.) For more information about privileges that are necessary to view objects in the SYS schema, see the Oracle Database Security Guide. You can also view the link and password information together in a join by creating and executing the following script: SELECT DISTINCT d.OWNER,d.DB_LINK,d.USERNAME,l.PASSWORD, l.AUTHUSR,l.AUTHPWD,d.HOST,d.CREATED FROM DBA_DB_LINKS d, SYS.LINK$ l WHERE PASSWORD IS NOT NULL AND d.USERNAME = l.USERID

Database Links Without Credentials
Creating a connected user database link: Creating a current user database link: CREATE DATABASE LINK sales.division3.acme.com USING 'sales'; CREATE DATABASE LINK sales CONNECT TO CURRENT_USER USING 'sales'; Database Links Without Credentials Connected user and current user database links do not include credentials in the definition of the link. The credentials that are used to connect to the remote database can change depending on the user that references the database link and the operation performed by the application. In many distributed applications, you do not want a user to have privileges in a remote database. One simple way to achieve this result is to create a procedure that contains a fixed user or current user database link within it. In this way, the user accessing the procedure temporarily assumes the privileges of another user. Creating a Connected User Database Link To create a connected user database link, omit the CONNECT TO clause. The following syntax creates a connected user database link, where dblink is the name of the link and net_service_name is an optional connect string: CREATE [SHARED] [PUBLIC] DATABASE LINK dblink ... [USING 'net_service_name']; Creating a Current User Database Link To create a current user database link, use the CONNECT TO CURRENT_USER clause in the link creation statement. Current user links are only available through the Oracle Advanced Security option.

Local database audits jane Remote database audits scott
Audit Database Links connect jane/doe connect scott/tiger FINANCE Local database audits jane Remote database audits scott Audit Database Links You must always perform auditing operations locally. That is, if a user acts in a local database and accesses a remote database through a database link, the local actions are audited in the local database, and the remote actions are audited in the remote database, provided appropriate audit options are set in the respective databases. The remote database cannot determine whether a successful connect request and subsequent SQL statements come from another server or from a locally connected client. For example, assume the following: A fixed user link hq.acme.com connects local user jane to the remote hq database as remote user scott. The scott user is audited on the remote database. Actions performed during the remote database session are audited as if scott were connected locally to hq and performing the same actions there. You must set audit options in the remote database to capture the actions of the user (in this case, scott on the hq database) that is embedded in the link if the desired effect is to audit what jane does in the remote database. Note:You can audit the global username for global users. You cannot set local auditing options on remote objects. Therefore, you cannot audit the use of a database link, although access to remote objects can be audited on the remote database.

Authenticate users with passwords Protect passwords Authenticate users with the operating system (OS) Restrict remote OS authentication Protect database link passwords Audit database links

Strong Authentication

Objectives After completing this lesson, you should be able to do the following: Describe strong authentication by using: Certificates Kerberos RADIUS Describe a setup for strong authentication by using: KDC

Strong User Authentication
Strong authentication: Is stronger than password authentication Often includes single sign-on functionality Is supported by the following authentication technologies: Certificates, public key infrastructure (PKI) RADIUS, token, and smart cards Kerberos Integrates with Oracle Net Services Requires Oracle Advanced Security Strong User Authentication Strong user authentication is a way of confirming the identity of the user with something other than a password. Smart cards, biometrics, certificates, and Kerberos tokens provide strong user authentication. Some of these methods are known as two-factor or multifactor authentication. Two-factor authentication requires something that the user knows plus something that the user has. Several of the strong authentication options use centralized authentication, which gives you high confidence in the identity of users, clients, and servers in distributed environments. These centralized servers may also include single sign-on. Certificates, PKI Certificates are digital documents that are used to provide proof of identity. Certificates can use PKI or a web of trust to authenticate a user or a machine. They are used in one-way authentication to authenticate a server to a user and in two-way authentication that additionally authenticates the user to the server. The process for exchanging certificates is based on the TCP secure sockets layer (SSL)–enabled protocol called TCPS. SSL has been superceded by Transport Layer Security (TLS), but is still referred to as SSL. The certificates require the use of the SSL libraries that are available with Oracle Advanced Security.

Authentication server
Single Sign-On Single sign-on is a centralized authentication service. The user has a single username and password. Servers authenticate users through the central service. Authentication server Client Server Single Sign-On Confidence in the identity of users and hosts can be achieved by using a centralized, secure authentication service rather than relying on hosts and users identifying themselves to one another directly. Single sign-on is a centralized authentication service that allows users to access multiple services with a single login. An alternative is a centralized authentication server that allows the use of a single username and password. Network authentication services, such as certificates, also can provide the benefit of single sign-on for users. OracleAS Single Sign-On requires Oracle Advanced Security. When a central authentication service is not available, users generally respond to multiple accounts in one of the following ways: The users may set the passwords the same on all machines (which results in a potentially large exposure in the event of a compromised password). The users may just write the passwords down or forget them, either of which severely compromises password secrecy and service availability. Provide a single sign-on or a centralized authentication server so that users can access multiple accounts and applications with a single password. This eliminates the need for multiple passwords for users and simplifies management of user accounts and passwords for system administrators.

Public Key Infrastructure (PKI) Tools
The Oracle database PKI implementation includes: Components: Oracle Advanced Security Oracle Identity Management Infrastructure Management tools: Oracle Wallet Manager Oracle Enterprise Security Manager Public Key Infrastructure (PKI) Tools The authentication systems based on the public key cryptography issue digital certificates to users. Users use the certificates to authenticate directly to servers in the enterprise without the direct involvement of an authentication server. Oracle provides a PKI for using public keys and certificates. Some of its features and tools are as follows: Oracle Wallet Manager 3.0 (OWM) is a stand-alone Java application that is used to manage and edit the security credentials in Oracle wallets. Oracle wallets are data structures that contain a user private key, a user certificate, and a set of trust points (the list of root certificates that the user trusts). OWM uses the Public-Key Cryptography Standards (PKCS) #12 specification for the wallet format, and PKCS #10 for certificate requests. Integration with Entrust PKI provides full certificate life cycle management and certificate revocation list (CRL) checking. An Oracle environment supports hardware devices by providing APIs that conform to the RSA Security, Inc., PKCS #11 specification.

Certificates Certificates: Certificate authority: Certificate use:
Are digital documents Provide proof of identity Certificate authority: Is a trusted organization (trust point) Attests to the identity of the certificate Issues trusted certificates Certificate use: Requires an SSL Requires a level of trust in the signing authority Certificates Certificates are digital documents that are used to provide proof of identity. For example, a certificate from a bank’s URL convinces bank customers that they have connected to the bank and not a spoofed site that is designed to collect their account numbers. When used in a PKI, each certificate includes an issuing certificate authority (CA). The CA asserts that it is a valid certificate. The CA is also known as a trust point and is hierarchical. If George connects to a Web site that presents a certificate signed by a CA that George does not recognize, he can check the signer of the CA certificate and so on. The certificate contains identity credentials: name, public key, expiration time, and a URL of a signing authority. Each signing authority provides a certificate of another signing authority at a higher level. This chain of certificates repeats to a self-signed root certificate provided by one of the root certificate authorities such as Verisign. This chain of trust is the PKI. For SSL sessions, certificates are exchanged, and the public keys are used to pass a shared key. Then the much faster symmetric encryption algorithms are used for the session messages. Certificates may be used between a client and a server without any centralized server. Note that only the client and the server are involved in the authentication after the certificates have been issued.

How to Use Certificates for Authentication
Install the required components. Configure the server for SSL. Configure the server-side Oracle Net files: listener.ora sqlnet.ora tnsnames.ora Configure the client for SSL Configure the client-side Oracle Net files: Create a user that is authenticated with a certificate. Connect to the database. How to Use Certificates for Authentication 1. Install the required components: You must install Oracle Advanced Security. Oracle Advanced Security provides the SSL libraries and tools for managing certificates. Enterprise Identity Management (EIM), though not required for SSL, provides Oracle Internet Directory (OID), directory management tools, and OracleAS Single Sign-On. 2. Configure the server for SSL: Use Oracle Wallet Manager to configure a wallet for the node. The same steps are required for both the server and client wallets. 3. Configure the server-side Oracle Net files: Use Net Manager to configure the Oracle Net files to use SSL. 4. Configure the client for SSL: Use Oracle Wallet Manager to configure a wallet for the user. The same steps are required for both the server and client wallets 5. Configure the client-side Oracle Net files: Use Net Manager. 6. Create a user that is authenticated with a certificate: Use the distinguished name. 7. Connect to the database. The connect string that named the SSL listener port and the distinguished name of the server authenticate a user by using only the certificate. The Oracle database checks the directory by using the user distinguished name for the user authorizations.

Configuring SSL on the Server
To obtain a certificate, you must generate a certificate request for the server database instance and send the request to a CA. You must import the certificates that you receive into the wallet. Oracle Wallet Manager (OWM) is used to create the wallet, generate the request, and import the certificates into the wallet. The user certificate refers to a certificate that matches the certificate request, in this case a database. The certificates returned by the CA are the trusted certificate and the user certificate. The trusted certificate must be imported first. For the server, it is important that the distinguished name (DN) be the same as the service name. The wallet can be stored in the system’s default location, in a specified directory, or in the Windows registry. The wallet has a password. The Oracle Wallet Manager auto login feature creates an encrypted copy of the wallet. File system permissions provide the necessary security for auto login wallets. When auto login is enabled for a wallet, it is only available to the operating system user who created that wallet. You must enable auto login if you want single sign-on access to multiple Oracle databases, which is disabled by default. Sometimes these wallets are called “SSO wallets” because they provide single sign-on capability.

Configuring Oracle Net Files on the Server
Setting the Wallet Location Set the wallet location in both the listener.ora and sqlnet.ora files: wallet_location = (SOURCE= (METHOD=File) (METHOD_DATA= (DIRECTORY=<wallet_location>))) where <wallet_location> is the name of the directory holding the wallet. Set the listener.ora file to listen on an endpoint for the TCPS protocol. The recommended port is 2484: LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS) (HOST = <server_name>) (PORT = 2484)) )

Configuring SSL on the Client
This process is almost identical to configuring SSL on the server. On the server, the certificate request is for the server machine or database. On the client, the certificate request is for a user and is requested with the DN of that user. The DN of the user is used to query the directory to obtain the user authorizations.

Configuring Oracle Net Files on the Client
On the client, specify: The server’s distinguished name The TCPS protocol listener port The client wallet location Configuring Oracle Net Files On the client: Set the wallet location in the sqlnet.ora file. Set the requirement that the client use SSL authentication and the server service name match the distinguished name. These choices are shown as follows: SSL_CLIENT_AUTHENTICATION =TRUE wallet_location = (SOURCE= (METHOD=File) (METHOD_DATA= (DIRECTORY=wallet_location))) SSL_SERVER_DN_MATCH=(ON) where <wallet_location> is the name of the directory holding the wallet. SSL_SERVER_DN_MATCH=ON requires that the DN of the server match the service name listed in the tnsnames.ora entry.

Creating a User Identified by Certificate
When you create a global user, you can specify the X.509 name that identifies this user at the enterprise directory server: Create a global user that is mapped to the appropriate schema by the directory information: CREATE USER global_user1 IDENTIFIED GLOBALLY AS 'CN=analyst,OU=division1, O=oracle, C=US'; CREATE USER global_user2 IDENTIFIED GLOBALLY AS ''; Creating a User Identified by Certificate The following command creates a database user identified by a distinguished name: CREATE USER global_user1 IDENTIFIED GLOBALLY AS 'CN=analyst,OU=division1, O=oracle, C=US'; Roles can be assigned directly to this user, or the authorizations can be stored in the directory. The following command creates a database user: CREATE USER global_user2 IDENTIFIED GLOBALLY AS ''; No one connects directly to the global_user2 schema. A user that is mapped to this schema in the directory can connect to this schema.

Connecting to the Database
The user that owns the client wallet may connect to the database by using: CONNECT Connecting to the Database The user that owns the client wallet may connect to the database without a password as shown in the slide. The wallet is accessed and the certificate information is passed to the server. The server certificate information is passed to the client. All this information is passed as encrypted text. The user authorizations, such as roles, are retrieved from Oracle Internet Directory. Use the user DN created in the previous slide as an example. The certificate for this user must have a DN of CN=analyst,OU=division1, O=oracle,C=US to connect as the global_user user.

orapki Utility orapki is a command-line utility for scripting common PKI management tasks. It can be used for: Creating and viewing signed certificates for testing purposes Managing Oracle wallets Creating and displaying Oracle wallets Renaming CRLs with a hash value for certificate validation orapki Utility The orapki utility is provided to manage PKI elements, such as wallets and certificate revocation lists, on the command line so that the tasks it performs can be incorporated into scripts. Providing a way to incorporate the management of PKI elements into scripts makes it possible to automate many of the routine tasks of maintaining a PKI. This command-line utility can be used to perform the following tasks: Creating and viewing signed certificates for testing purposes Managing Oracle wallets Creating and displaying Oracle wallets: Adding and removing certificate requests Adding and removing certificates Adding and removing trusted certificates Managing certificate revocation lists (CRLs) Renaming CRLs with a hash value for certificate validation: Uploading, listing, viewing, and deleting CRLs in Oracle Internet Directory

How to Use Kerberos for Authentication
Install Kerberos. Configure a service principal for the database server. Extract a service table from Kerberos. 4. Install an Oracle database server and a client. 5. Install Oracle components. 6. Configure Oracle Net Services and the Oracle database. 7. Configure Kerberos authentication. 8. Create a Kerberos user. 9. Create an externally authenticated Oracle user. 10. Get an initial ticket for the Kerberos and Oracle user. How to Use Kerberos for Authentication To use Kerberos authentication, you must perform the following steps (Additional details are available in the Oracle Database Advanced Security Administrator’s Guide 10g Release 1.): 1. Install Kerberos. Install it on the machine that functions as the authentication server. 2. Configure a service principal for an Oracle database server. Create a name in Kerberos to identify the Oracle database. This name has the following format: kservice is a case-sensitive string. It may be the same as the database service name. kinstance is typically the fully qualified name of the system on which the Oracle database is running. REALM is the domain name of the database server. REALM must always be uppercase and is typically the DNS domain name. Example:

How to Use KDC with Windows 2000 for Authentication
Configure an Oracle Kerberos client to interoperate with a Windows 2000 domain controller KDC. Configure a Windows 2000 domain controller KDC to interoperate with an Oracle client. Configure an Oracle database to interoperate with a Windows 2000 domain controller KDC. Get an initial ticket for the Kerberos and Oracle user. How to Use KDC with Windows 2000 for Authentication Windows 2000 Server includes a version of Kerberos called KDC that configures Kerberos to operate with Windows 2000 domain controllers. This is a high-level overview of the configuration process. For details, see the Oracle Database Advanced Security Administrator’s Guide 10g Release 1. 1. Configure the Oracle Kerberos client to interoperate with a Windows 2000 domain controller KDC. On the computers that use the Oracle client, perform the following steps: a. Create the Kerberos client configuration files: kbr.conf, kbr5.conf and kbr5.realms. b. Specify Oracle Net configuration parameters in the sqlnet.ora file. These may be specified with Net Manager. c. For UNIX clients, specify the listening port number. Set the port number in the /etc/services file to UDP/TCP port 88.

RADIUS Authentication: Overview
RADIUS is a protocol for remote authentication and access. You may use any authentication method that supports the RADIUS standard. You may change authentication methods without changing the database or client configuration. The user is defined in the database as IDENTIFIED EXTERNALLY. Radius Authentication: Overview RADIUS is a client/server security protocol that is widely used to enable remote authentication and access. Oracle Advanced Security uses this industry standard in a client/server network environment. You can enable the network to use any authentication method that supports the RADIUS standard, including token cards and smart cards, by installing and configuring the RADIUS protocol. Moreover, when you use RADIUS, you can change the authentication method without modifying either the Oracle client or the Oracle database server. For details about enabling RADIUS authentication, see the Oracle Database Advanced Security Administrator’s Guide 10g Release 1. From the user’s perspective, the entire authentication process is transparent. When the user seeks access to an Oracle database server, the Oracle database server (acting as the RADIUS client) notifies the RADIUS server. The RADIUS server: Looks up the user’s security information Passes authentication and authorization information between the appropriate authentication server or servers and the Oracle database server Grants the user access to the Oracle database server Logs session information, including when, how often, and for how long the user is connected to the Oracle database server

Describe strong authentication by using: Certificates Kerberos RADIUS Describe a setup for strong authentication by using: KDC

Enterprise User Security

Objectives After completing this lesson, you should be able to do the following: Describe Enterprise User Security Set up Enterprise User Security Create an enterprise user Use shared schemas Use enterprise roles Audit enterprise users Enable enterprise roles Migrate users from the database to Oracle Internet Directory Objectives This lesson describes the basic components of Enterprise User Security. It shows the architecture of this feature and describes the installation process. The components required to create and manage an enterprise user are discussed. In addition, the lesson explains the techniques for using the enterprise user in the context of the database server and integrating the enterprise user with familiar security policies and auditing.

Enterprise User Security
Enterprise User Security stores user credentials and authorizations in a central location (Oracle Internet Directory). It eases administration through centralization. It enables single-point authentication. It eliminates the need for client-side wallets. Example: User changes job roles. Security administrator changes the user roles in Oracle Internet Directory. No changes are made to the services that the user accesses. Enterprise User Security Enterprise User Security addresses the user, the administrative, and the security challenges by centralizing storage and management of user-related information in a Lightweight Directory Access Protocol (LDAP)–compliant directory service. When an employee changes jobs in such an environment, the administrator need to only modify information in one location (the directory) to make effective changes in multiple databases and systems. This centralization can substantially lower administrative costs while materially improving enterprise security. Enterprise User Security requires that Oracle Identity Management Infrastructure must be installed.

Oracle Identity Management Infrastructure: Default Deployment
sso.mydomain.com SSO DAS Oracle Internet Directory Server Identity Management Infrastructure Database Oracle Identity Management Infrastructure: Default Deployment A default installation of the Oracle Application Server infrastructure consists of installing all infrastructure components on the same system, including OracleAS Single Sign-On (SSO), Oracle Application Server Certificate Authority (OCA), and Oracle Delegated Administration Services (DAS). This deployment is simple, and it automatically configures SSO, OCA, and DAS as part of the repository and Oracle Internet Directory (OID). This deployment is adequate for setting up a quick development or testing environment. This deployment is all that is required for Enterprise User Security. The Oracle HTTP Server, OracleAS Containers for J2EE (OC4J), and Oracle Enterprise Manager components are always installed. OCA

Oracle Database: Enterprise User Security Architecture
Oracle Identity Management OracleAS Metadata Repository OID Verifies the user Applies roles Oracle DB Oracle Database: Enterprise User Security Architecture The Enterprise User Security architecture is transparent to the end user. In the example shown in the slide, a client can submit the same connect command, whether connecting as a database user or an enterprise user. The enterprise user has the additional benefit of allowing the use of a shared schema. The authentication process is as follows: 1. The user presents a username and password (or other credentials). 2. The directory returns the authorization token to the database. 3. The schema is mapped from OID information. 4. The directory supplies the global roles for the user. Enterprise roles are defined in OID and mapped to global roles in the database. 5. The directory can supply the application context. An application context supplied from OID is called a global context. Client Username and password

Enterprise User Security (EUS) by Database Version
Oracle8i: EUS with certificate authentication Oracle9i: EUS with password authentication Oracle Database 10g: EUS with Kerberos authentication Enterprise User Security by Database Version Enterprise User Security (EUS) is being enhanced with each version of the database software. In Oracle8i, certificates and Oracle Advanced Security were required to use the EUS functionality. In Oracle9i, password authentication was added, so users no longer required a certificate. With Oracle Database 10g, EUS functionality is available with Kerberos, version 5 tickets.

Authenticating Enterprise Users
Enterprise User Security supports the following authentication methods: Password authentication SSL authentication Kerberos authentication Authenticating Enterprise Users Enterprise User Security supports three authentication methods. Each authentication method has advantages and disadvantages listed below. These determine which authentication method is best for your Enterprise User Security implementation. Configuring password authentication is described in this lesson. Configuration details for the other methods can be found in the Oracle Database Advanced Security Administrator’s Guide 10g Release 1 (10.1). All Three Methods All the three methods provide centralized user and credential management. User identity can be used in two-tier or multitier applications. The methods support current user database links if the connection between databases is over the secure sockets layer (SSL). Password Authentication It is password-based authentication. Separate authentications are required for each database connection. It retains users’ current authentication methods. It supports Oracle Release 7.3 (and later) clients with Oracle Database 10g.

Setting Up Enterprise User Security
1. Install OracleAS Infrastructure. 2. Register the database. Setting Up Enterprise User Security In the following slides, the steps required to set up Enterprise User Security are described.

Installing OracleAS Infrastructure
OUI_InstallAS.gif Installing OracleAS Infrastructure Oracle Internet Directory (OID) must be installed to use Enterprise User Security. OID requires a metadata repository in an Oracle database. The simplest way to meet these requirements is to use the default installation of OracleAS Infrastructure with a metadata repository from Oracle Universal Installer.

Registering the Database
DBCA_reg_oid.gif Registering the Database The database must be configured to use LDAP. The first choice is to use Domain Name Services (DNS) to perform automatic domain name lookup to locate the directory on your network. The network administrator must have entered a DNS Service Location Record (SRV) into the domain name server. The database administrator (DBA) can use Oracle Net Configuration Assistant to create an ldap.ora file for your Oracle home. This configuration file specifies the directory host and port information, and the name of the identity management realm so that the database can connect to the directory. This step is required if you are not using automatic domain name lookup. Use the Database Configuration Assistant (DBCA) to register the database in the directory. Registration creates an entry in the directory so that the database can bind or log in to it. The DBCA performs several configuration tasks, including creating a wallet for the database and assigning a password for the wallet.

Creating an Enterprise User
There are two types of enterprise users: An enterprise user with a schema is identified in the database as a global user: An enterprise user sharing an application schema is not identified in the database: CREATE USER scott IDENTIFIED GLOBALLY AS ‘’; CREATE USER appschema IDENTIFIED GLOBALLY; Creating an Enterprise User To create an enterprise user, OracleAS Infrastructure 10g must be installed and running and Oracle9i Database or Oracle Database 10g must be running. Enterprise users that are identified in the database are created as global users. Creating a global user who is authenticated by a password and authorized by the enterprise directory service is illustrated by the following statement: CREATE USER scott IDENTIFIED GLOBALLY AS ‘’; In this case, scott is an enterprise user with a schema in the database. The disadvantage here is that the scott user must then be created in every database that he accesses with a schema and the directory. Shared schema users are not created in the database. The application schema owner is created in the database, as shown in the slide. The directory maps the enterprise user to a shared schema. This allows multiple enterprise users to access a single schema in the database. This type of enterprise user: Is authenticated by SSL, Kerberos, or passwords Is created only in the directory Connects to a shared schema

Creating an Enterprise User in the Directory
You can create enterprise users in the directory by using Enterprise Security Manager (ESM). In the example in the slide, the user Scott Taylor is created. He has a user ID of staylor. This is the name Scott will use when he attempts to connect. His distinguished name (DN) is cn=Scott Taylor, cn=users, dc=us, dc=oracle, dc=com. esm_cr_ent_user.gif

Creating a Schema Mapping Object in the Directory
You can create multiple enterprise users and a mapping object in the directory. The mapping object informs the database about how you want to map the DN of the users to the shared schema. Either you can do a full DN mapping (one enterpriser user to one DB schema) or you can map, for example, every user containing the DN components dc=us,dc=oracle,dc=com to appschema. The Add Database Schema Mappings window in ESM is shown in the slide. On UNIX or Linux, you can start this tool by using the following command: $ oemapp esm Most users do not need their own schemas, and implementing shared schemas divorces users from databases. Create an enterprise user once in the directory, then that user can access shared schema in any database where the schema mapping exists. For further details and practice in creating enterprise users, see “Enterprise User Security” in the Oracle By Example (OBE) series at: esm_schema_mapping.gif

Identifying the Enterprise User
Who is the real user? Show the current shared schema: Show the real user: SELECT user FROM dual; select sys_context ('userenv' , 'external_name') from dual; SYS_CONTEXT('USERENV','EXTERNAL_NAME') cn=Scott Taylor,cn=Users,dc=us,dc=oracle,dc=com Identifying the Enterprise User The enterprise user who is mapped to a shared schema is unknown to the database. When OID is used to authenticate the user to the database, the “real” name of the enterprise user can be found in his or her login session by using the sys_context function. This name is held in the external_name attribute of the userenv context. The shared schema is shown by: $ sqlplus staylor/welcome1 SQL> SELECT user FROM dual; USER GUEST The real user is shown by checking the external_name attribute of the userenv context: SQL> select sys_context ('userenv' , 'external_name') from dual; SYS_CONTEXT('USERENV','EXTERNAL_NAME') cn=Scott Taylor,cn=Users,dc=us,dc=oracle,dc=com

Enabling Current User Database Links
Oracle Identity Management OracleAS Metadata Repository OID Verifies user Applies roles Username and password SSL Oracle DB Enabling Current User Database Links Current user database links require SSL-enabled network connections between the databases. Before you can enable current user database links, you must enable SSL, create Oracle wallets, and obtain PKI credentials for all databases involved. OID and OracleAS Metadata Repository are not required. If you are using OID, use ESM to enable current user database links between databases within the enterprise domain in the directory by performing the following steps: 1. Select a specific enterprise domain in the navigator pane. 2. Click the Databases tab, and select Enable Current User Database Links. 3. Click Apply. For more information about this task, see the Oracle Database Advanced Security Administrator’s Guide 10g Release 1 (10.1). Oracle DB Client Current User database link

Creating an Enterprise Role
Ems_cr_ent_role.gif Creating an Enterprise Role An enterprise role is a directory structure that can contain global roles on multiple databases. The enterprise role can be granted to enterprise users. When an enterprise user attempts to connect to the database, the enterprise directory is queried to obtain any global roles associated with the user. The global role is defined locally in the database by granting privileges and roles to it, but you cannot grant the global role itself to any user or other role in the database. An enterprise user can be authorized to use the role only by an enterprise directory service. Use the ESM utility to create an enterprise role. This creates a container for the global roles. An example is dbaccessentrole as shown in the slide.

Assigning a Global Role to an Enterprise Role
Ems_add_global_role.gif Assigning a Global Role to an Enterprise Role Global roles are created locally in the database. The following statement creates a global role in the database: CREATE ROLE mydbaccess IDENTIFIED GLOBALLY; In the ESM tool, associate the enterprise role (already defined in the previous slide) with the global role. Associate the mydbaccess global role with the dbaccessentrole enterprise role.

Assigning an Enterprise User to an Enterprise Role
ems_add_ent_user.gif Assigning an Enterprise User to an Enterprise Role The ESM tool enables you to associate an enterprise role with a user. When the user connects to the database, the global roles assigned to the enterprise role are enabled for the user. In the ESM tool, navigate to Enterprise Roles, select the enterprise role that is defined in the previous slide, and click the Users tab. In the Add Enterprise Users dialog box, navigate to the cn=Users node, and click Search. Select the users that you want to add to the role, and click OK. Assigning Enterprise Roles to Groups Assigning the enterprise role to many users by using this method can be tedious. Enterprise roles can be assigned to groups of users. Use the Oracle Delegated Administration Services tool to create the group and assign users to the group. Then use ESM to assign the group to the role in the same way as discussed here by using the cn=Groups node instead of the cn=Users node.

User Migration Utility
The user migration utility is a command-line tool. It: Migrates users from the database to OID: External users Local users A supplied list of users Migrates users in a two-phase process: Phase 1 populates a table in the database with user information. The DBA is allowed to modify the table data as required. Phase 2 updates the directory and the database. User Migration Utility The user migration utility is a command-line utility that is used to move users from a local database model to an enterprise-user model. This utility makes it easy to migrate local and external database users to an enterprise-user environment in an LDAP directory. It uses the Oracle JDBC OCI driver to connect to the database. Enterprise-user administrators can select for migration any combination of the following user subsets in a database: List of users specified on the command line or in a file All external users All local users In addition, enterprise-user administrators can specify values for utility parameters that determine how the users are migrated, such as: Where to put the migrated users in the LDAP directory tree Mapping a user with multiple accounts on various databases to a single directory user entry

Enterprise-User Auditing
Exclusive schema Shared schema Standard audit USERNAME Standard audit USERNAME GLOBAL_UID Fine-grained audit DB_USER Fine-grained audit DB_USER GLOBAL_UID Enterprise-User Auditing If auditing is turned on, Oracle Database 10g captures the identity of enterprise users in its audit trails. OID can store additional attributes for each user to help identify both authorized and unauthorized users. When an enterprise user has his or her own schema (an exclusive schema) in the database, the database username represents the enterprise user. The enterpriser user has a one-to-one mapping to the database user or schema. When enterprise users access exclusive schemas: In standard auditing: The USERNAME column shows the user identity in the database, and the GLOBAL_UID column shows the same user’s global identity. In fine-grained auditing: The DB_USER column shows the user identity in the database, and the GLOBAL_UID column shows the same user’s global identity. When enterprise users map to a shared schema in the database, the audit trails capture both the username of the shared schema user and the identity of the actual user managed in the directory. When enterprise users access shared schemas: In standard auditing: The USERNAME column shows the shared schema, and the GLOBAL_UID column shows the identity of the enterprise user. In fine-grained auditing: The DB_USER column shows the shared schema, and the GLOBAL_UID column shows the identity of the enterprise user.

Demonstration This demonstration shows you how to perform the following actions: Setting up EUS authentication Configuring an enterprise role Configuring shared schema for groups Demonstration This demonstration is available as a viewlet in your $HOME/demos directory. Your instructor may demonstrate these steps.

Describe Enterprise User Security Set up Enterprise User Security Create an enterprise user Use shared schemas Use enterprise roles Audit enterprise users Enable enterprise roles Migrate users from the database to Oracle Internet Directory

Proxy Authentication

Objectives After completing this lesson, you should be able to do the following: Describe how proxy authentication works Manage users being authenticated by using proxy authentication Audit users authenticated by proxy

Security Challenges of Three-Tier Computing
Who is the real user? Can the user be reauthenticated to the database? Does the middle tier have more privileges than required? Oracle Application Server Database User Security Challenges of Three-Tier Computing Although three-tier computing provides many benefits, it raises a number of new security issues. These issues are described in the subsequent sections: Who is the real user? Should the user be reauthenticated to the database? Does the middle tier have more privileges than required?

Who Is the Real User? For the following security functions, the application needs the end user, not the proxy user: Authentication Data access control Auditing If only the application server knows the end-user ID, then: Security must be coded in the application Security enforced in the application is expensive Who Is the Real User? For access control and auditing, most organizations need to know the identity of the actual user who is accessing the database. User accountability is diminished if the identity of the user cannot be traced through all tiers of the application. Furthermore, if only the application server knows who the user is, then all per-user security enforcement must be done by the application itself. Application-based security is very expensive. If each application that accesses the data must enforce security, then security must be reimplemented in each and every application. It is often preferable to build security on the data itself, with per-user accountability enforced within the database. How to Audit and Whom to Audit? Accountability through auditing is a basic principle of information security. Most organizations want to know on whose behalf a transaction has been accomplished, not just that a particular application server performed a transaction. A system must, therefore, be able to differentiate between a user performing a transaction and an application server performing a transaction on behalf of a user. Auditing in three-tier systems should be tied to the issue of knowing the real user; if you cannot preserve the user’s identity through the middle tier of a three-tier application, then you cannot audit actions on behalf of the user.

User Reauthentication
Types of authentication in three-tier systems: Middle tier to database authentication Client to middle tier authentication Client reauthentication through the middle tier to the database: Does the end user need to log in multiple times? Can the end user’s database account information be stored in the application? Can the user be authenticated by using LDAP? Point-to-point protocols, such as SSL, can only authenticate to one node Single authentication User Reauthentication Can the User Be Reauthenticated to the Database? In client-server systems, authentication tends to be straightforward; the client authenticates to the server. In three-tier systems, authentication is more difficult because there are several potential types of authentication: Middle tier to database authentication End user to middle tier authentication End-user reauthentication through the middle tier to the database Middle Tier to Database Authentication Because the middle tier usually initiates a connection to a database to retrieve data, whether on its own behalf or on behalf of the user, this connection clearly must be authenticated. In fact, the Oracle database does not allow unauthenticated connections. Middle tier to database authentication can also be mutual if you are using a protocol that supports this, such as secure sockets layer (SSL). If you are using connection pooling, then the application server authenticates to the database when it builds the pool during startup.

Common Implementations of Authentication
Pass-thru: The user is unknown to the application. One big-application user: The user is unknown to the database. Other methods: The user is reauthenticated to the database. The user is identified to the database. The user is proxied. Oracle Application Server Database User Common Implementations of Authentication There are several implementations of three-tier authentication methods and variations of those methods. Most of these methods can be grouped into the following categories: Pass-thru (The user is unknown to the application): In this model, the application would query the user for credentials and pass the response to the database for authentication. This is a traditional model requiring each user to have a database schema and login. This method can be moved to an enterprise-user model with no changes to the application. The application is not responsible for authentication, authorization, or access control. Auditing is easy. The real user is obvious. This method is no different from the client-server model, where the user connects directly to the database. One big-application user (The user is unknown to the database): In this model, the application is responsible for authentication, authorization, and access control. All end users present their credentials to the application, and the application user connects to the database. Often the application user is the application owner with all the privileges to all application objects. This method is easy to code, but violates the principle of least privilege. When the authentication process is determined by the application, it can use an LDAP directory, local files, or some other method to validate the user. The application can make use of roles, enabling and disabling roles to control access. Unless the application keeps some kind of mapping, end-user auditing can be difficult or impossible.

Does the Middle Tier Have More Privileges Than Required?
Middle tier connects to the database: Same database user for all application users The database user has all privileges for all application users. The database may not know the end-user ID. Application server must have limited privileges. Does the Middle Tier Have More Privileges Than Required? Some organizations are willing to accept three-tier systems within the enterprise. In these systems, “all-privileged” middle tiers, such as transaction processing (TP) monitors, can perform all actions for all users. In this architecture, the middle tier connects to the database as the same user for all application users. It, therefore, needs to have all privileges that application users need to do their jobs. This is also called the “one big-application user” model. This computing model can be undesirable on the Internet, where the middle tier resides outside, on, or just inside a firewall. If the middle tier is compromised, all the application data is exposed. More desirable, in this context, is a limited trust model, in which the identity of the real client is known to the data server, and the application server (or other middle tier) has a restricted privilege set. Application Server Must Have Limited Privileges Limit the privileges granted to the application. Only allow the application to connect on behalf of certain users, and only allow it to assume certain roles on behalf of the user. For example, many organizations would prefer that users have different privileges, depending on where they are connecting from. Users connecting to a Web server or an application server on the firewall may be able to access only a minimal set of data, whereas users connecting to a server within the enterprise may be able to exercise all privileges that they are otherwise entitled to have.

Implementing Proxy Authentication Solutions
Proxy authentication solutions depend on the type of the end user: Known to the database: Database user and enterprise user Possible to reauthenticate to the database Auditing actions taken on behalf of the real user Unknown to the database: End user known only to the application Support for application-user models Limiting the privilege of the middle tier Proxy Authentication Solutions Proxy authentication is implemented in two ways, depending on the identity of the end user. The first is for the database user and the enterprise user. Both these users are identified to the database. The second is for the end user who is known only to the application. Passing Through the Identity of the Real User Many organizations want to know who the user is through all the tiers of an application, without sacrificing the benefits of a middle tier. The Oracle database supports proxy authentication for preserving user identity through the middle tier of an application. The real user can be identified in the following situations: Database users have a database account that maintains their identity. Enterprise-user identities are maintained in Oracle Internet Directory (OID) and are identified by using a distinguished name (DN). Application users are known to the application, but not to the database. Reauthenticating the Real User Database and enterprise users can be reauthenticated to the database after connecting to the application server. Database users can supply a password that is passed to the database.

Authenticating Database and Enterprise Users
Use OCI or JDBC. The authentication process is as follows: 1. Client authenticates to the middle tier. 2. Middle tier authenticates to the database. 3. Middle tier creates the end user’s session. 4. Database verifies that the middle tier can: - Create the session for the user - Assign the roles assigned to the user Database users can be: Authenticated to the application server Reauthenticated to the database Authenticating Database and Enterprise Users For enterprise users or database users, Oracle Call Interface (OCI) or Java Database Connectivity (JDBC) enables a middle tier to set up, within a single database connection, a number of lightweight user sessions, each of which uniquely identifies a connected user. These lightweight sessions reduce the network overhead of creating separate network connections from the middle tier to the database. The application can switch between these sessions as required to process transactions on behalf of users. The full authentication sequence from the client to the middle tier to the database occurs as follows: 1. The client authenticates to the middle tier, using whatever form of authentication the middle tier accepts. For example, the client can authenticate to the middle tier by using a username and password, or an X.509 certificate by means of SSL. 2. The middle tier creating the lightweight sessions must first connect to the database as a database user rather than an enterprise user. The middle tier authenticates itself to the database, using whatever form of authentication the database accepts. This can be a password or an authentication mechanism supported by Oracle Advanced Security, such as a Kerberos ticket or an X.509 certificate (SSL).

Using Proxy Authentication for Database Users
Authenticate the user without a database password: Authenticate the user with a database password: ALTER USER phall GRANT CONNECT THROUGH appsrv; ALTER USER phall GRANT CONNECT THROUGH appsrv AUTHENTICATED USING PASSWORD; Using Proxy Authentication for Database Users Middle-tier authentication allows one JDBC connection (session) to act as a proxy for other JDBC connections. Use the CONNECT THROUGH clause in the ALTER USER command to indicate that the user is authenticated through a middle tier. Authenticating Without a Database Password When the middle tier authenticates the user, you may not want to give the middle tier the user’s database password. If the middle tier does not know the password, the user can be authenticated without a database password, using the following command: ALTER USER phall GRANT CONNECT THROUGH appsrv; The user can connect as PHALL by using the already authenticated credentials of the middle-tier APPSRV. This method assumes that the middle tier is trusted to perform the authentication. The created session behaves as if PHALL has been connected normally; PHALL does not have to divulge his password to the middle tier. The proxy session accesses the schema of PHALL.

Using Proxy Authentication for Enterprise Users
Authenticate the user with a distinguished name: Authenticate the user with a certificate: ALTER USER phall GRANT CONNECT THROUGH appsrv AUTHENTICATED USING DISTINGUISHED NAME; ALTER USER phall GRANT CONNECT THROUGH appsrv AUTHENTICATED USING CERTIFICATE TYPE 'X.509' VERSION '3'; Using Proxy Authentication for Enterprise Users In both the DISTINGUISHED NAME and CERTIFICATE cases, the proxy has already authenticated to the database and acts on behalf of a global database user who is known to the database. The application server is responsible for the authentication in both cases and is trusted by the database. Authenticating with a Distinguished Name To authenticate the user with a distinguished name, use the following command: ALTER USER phall GRANT CONNECT THROUGH appsrv AUTHENTICATED USING DISTINGUISHED NAME; The distinguished name is a global name in lieu of the password of the user being proxied for. For example, the distinguished name can be the following: CN=phall,OU=americas,O=oracle,L=redwoodshores,ST=ca,C=us The distinguished name is provided by the application server when the server connects for the user. The distinguished name may initially be provided by the user to the application server or the application server may retrieve the distinguished name from an LDAP directory.

Revoking Proxy Authentication
Revoke proxy authentication through a middle tier: Do not include the AUTHENTICATED USING clause with REVOKE. ALTER USER phall REVOKE CONNECT THROUGH appsrv; Revoking CONNECT THROUGH The following statement takes away the right of the user PHALL to connect through the proxy user APPSRV: ALTER USER phall REVOKE CONNECT THROUGH appsrv; You cannot specify the AUTHENTICATED USING clause as part of a REVOKE CONNECT THROUGH PROXY clause.

Application-User Model
Use the OCI, thin JDBC, or thick JDBC. End-user identity is set by the middle tier. The authentication process is as follows: 1. The middle tier authenticates to the database. 2. The end user authenticates to the middle tier. 3. The middle tier allocates a session to the user, identifying the user with client_identifier. 4. Optionally, the middle tier can enable roles to restrict the privileges of the user. Examples: Certificate Application username and password Application-User Model Many applications use session pooling to set up a number of sessions to be reused by multiple users. In this context, the end users who are not known to the database are authenticated to the middle tier of an application. Oracle Database 10g supports an application-user proxy for these types of applications. In this model, the middle tier passes a client identifier to the database upon the session establishment. (The client identifier can actually be anything that represents an end user connecting to the middle tier; for example, the end user ID or an IP address.) The client identifier, representing the end user, is available in user-session information and can also be accessed via an application context (via the USERENV naming context). In this way, applications can set up and reuse sessions, while still being able to keep track of the end user in the session. Applications can reset the client identifier and, thus, reuse the session for a different user, enabling high performance. For OCI-based connections, alteration of CLIENT_IDENTIFIER is combined with the other OCI calls to further enhance performance. An application-user proxy is available in thin JDBC, thick JDBC, and OCI, and provides the benefits of connection pooling without the overhead of separate user sessions (even lightweight ones).

Data Dictionary Views for Proxy Authentication
DBA_PROXIES: All proxy connections USER_PROXIES: Connections that the current user is allowed to proxy PROXY_USERS: Users who can assume the identity of other users V$SESSION_CONNECT_INFO: Network connections for all current sessions V$SESSION: Session-connect details: Program column shows “proxy-user…” Module column shows “proxy-user…” Data Dictionary Views for Proxy Authentication USER_PROXIES USER_PROXIES displays information about connections that the current user is allowed to proxy. This view does not display the PROXY column. PROXY_USERS PROXY_USERS describes users who can assume the identity of other users. V$SESSION_CONNECT_INFO This view displays information about network connections for all current sessions. V$SESSION V$SESSION columns (PROGRAM and MODULE) have a value of “proxy-user…” when the session is being proxied.

Data Dictionary Views: DBA_PROXIES and USER_PROXIES
SQL> SELECT proxy, client, authentication, 2* authorization_constraint FROM dba_proxies PROXY CLIENT AUTH AUTHORIZATION_CONSTRAINT HRUSER PHALL NO PROXY MAY ACTIVATE ROLE APPSVR PHALL NO NO CLIENT ROLES MAY BE ACTIVATED HRUSER PFAY YES PROXY MAY ACTIVATE ALL CLIENT ROLES DBA_PROXIES DBA_PROXIES displays information about all proxy connections in the system. In the slide, HRUSER may activate any or all roles granted to PFAY. HRUSER may only activate a specified role for PHALL. APPSVR may not activate any roles for PHALL. USER_PROXIES USER_PROXIES contains connections that the current user is allowed to proxy. Columns The column names for both DBA_PROXIES and USER_PROXIES are: Name Description PROXY Proxy username, in DBA_PROXIES only CLIENT Name of the client user on whose behalf the proxy user can act AUTHENTICATION Credential passed by the proxy for the client AUTHORIZATION Indicates the authority of the proxy to exercise roles on client’s _CONSTRAINT behalf. ROLE The role referenced in authorization constraint

Data Dictionary Views: V$SESSION_CONNECT_INFO
SQL> SELECT * FROM v$session_connect_info WHERE sid = 141; SID AUTHENTI OSUSER NETWORK_SERVICE_BANNER DATABASE oracle TCP/IP NT Protocol Adapter for Linux: Version Production 141 DATABASE oracle Oracle Advanced Security: encryption service for Linux: Version Production 141 DATABASE oracle Oracle Advanced Security: crypto-checksumming service for Linux: Version Production V$SESSION_CONNECT_INFO This view displays information about network connections for the current session. The SID column can be used to join this view with V$SESSION. There can be multiple rows returned for each session. This is a banner for one session started by OSUSER oracle. Columns The column names and descriptions are: Column Data Type Description SID NUMBER Session identifier AUTHENTICATION VARCHAR2(15) How the user is authenticated: _TYPE DATABASE: Username and password OS: External operating system NETWORK: Network or Advanced Network Option (ANO) PROXY: OCI proxy connection OSUSER VARCHAR2(30) External username for the database user NETWORK_SERVICE VARCHAR2(2000) Product banners for each Net8 service _BANNER used for this connection, with one row per banner

Auditing Actions Taken on Behalf of the Real User
Audit SELECTs on the EMPLOYEES table that HRAPPSERVER initiates for PHALL as follows: Audit SELECTs on the EMPLOYEES table that HRAPPSERVER initiates for any user as follows: The statements in this slide audit only SELECTs initiated by HRAPPSERVER. You cannot audit CONNECT ON BEHALF OF 'DN'. AUDIT SELECT TABLE ON employees BY hrappserver ON BEHALF OF phall; AUDIT SELECT TABLE ON employees BY hrappserver ON BEHALF OF ANY; Auditing Actions Taken on Behalf of the Real User You can use the proxy authentication features of the database to audit the actions that the middle tier performs on behalf of a user. Auditing on Behalf of a Specific User For example, suppose an application server HRAPPSERVER creates multiple lightweight sessions for the PHALL user. You can enable auditing for SELECTs on the EMPLOYEES table that HRAPPSERVER initiates for PHALL, as follows: AUDIT SELECT TABLE ON employees BY hrappserver ON BEHALF OF phall;

Data Dictionary Views: DBA_STMT_AUDIT_OPTS
DBA_STMT_AUDIT_OPTS describes current system auditing options. USER_NAME column: ANY CLIENT: Access by a proxy is audited NULL: Systemwide auditing PROXY_NAME column: The name of the proxy user performing an operation for the client NULL if the client is performing the operation directly Data Dictionary Views: DBA_STMT_AUDIT_OPTS This view describes the current system auditing options across the system and by the user. Columns The following columns are related to auditing the actions of the proxy user: Column Data Type Description USER_NAME VARCHAR2(30) If auditing user actions, then the username is recorded. If access by a proxy on behalf of a client is being audited, then ANY CLIENT is recorded. If auditing system-wide, then NULL is recorded. PROXY_NAME VARCHAR2(30) The name of the proxy user who is performing an operation for the client, or NULL if the client is performing the operation directly. Other columns that are not related to proxy users are not listed.

Data Dictionary Views: DBA_AUDIT_TRAIL
These views list audit-trail entries: DBA_AUDIT_TRAIL USER_AUDIT_TRAIL The COMMENT_TEXT column can indicate how the user has been authenticated: DATABASE: Authentication done by the password NETWORK: Authentication done by Net8 or the Advanced Security option PROXY: Authentication by another user Data Dictionary Views: DBA_AUDIT_TRAIL DBA_AUDIT_TRAIL This view lists all audit-trail entries. USER_AUDIT_TRAIL This view contains all audit-trail entries related to the current user. Columns Related to Proxies The COMMENT_TEXT column can indicate how the user has been authenticated. The method can be one of the following: DATABASE: Authentication has been done by the password. NETWORK: Authentication has been done by Oracle Net Services or the Advanced Security option. PROXY: The client has been authenticated by another user; the name of the proxy user follows the method type.

Describe how proxy authentication works Manage users being authenticated by using proxy authentication Audit users authenticated by proxy

Authorization Methods

Objectives After completing this lesson, you should be able to do the following: Implement roles Implement the securing of objects through procedures Describe how secure application roles work Manage roles and users by using secure application roles

Authorization Authorization determines the privileges that the user has in the database. User privileges are set in the database by: System privileges Object privileges Roles Authorization Authorization is the process that determines the privileges that the user is allowed to exercise. In the Oracle database, authorization is determined by the grant of system and object privileges. A named set of grants is a role, and it may be granted as a unit.

Privileges There are two types of user privileges:
System: Enables users to perform particular actions in the database Object: Enables users to access and manipulate a specific object Privileges A privilege is a right to execute a particular type of SQL statement or to access another user’s object. The Oracle database allows very fine-grained control over what users can or cannot do within the database. Privileges are divided into two categories: System privileges: Each system privilege allows a user to perform a particular database operation or class of database operations (for example, the privilege to create tablespaces is a system privilege). System privileges can be granted by the administrator or by someone who explicitly gives permission to administer the privilege. There are over 150 distinct system privileges. Object privileges: Object privileges allow a user to perform a particular action on a specific object, such as a table, view, sequence, procedure, function, or package. Without specific permission, users can access only their own objects. Object privileges can be granted by the owner of an object, by the administrator, or by someone who has been explicitly given permission to grant privileges on the object.

Roles Users Neena Girard Vance Roles HR_MGR HR_CLERK Delete employees
Select employees Update employees Privileges Insert employees Roles In most systems, it is too time consuming to grant necessary privileges to each user individually, and there is too great a chance of error. The Oracle database provides for easy and controlled privilege management through roles. Roles are named groups of related privileges that are granted to users or to other roles. They are designed to ease the administration of privileges in the database and, therefore, improve security. Role Characteristics Privileges are granted to and revoked from roles as if the role were a user. Roles can be granted to and revoked from users or other roles as if they were system privileges. A role can consist of both system and object privileges. A role can be enabled or disabled for each user who is granted the role. A role can require a password to be enabled. Roles are not owned by anyone, and they are not in any schema. In the example in the slide, the HR_CLERK role is granted the SELECT and UPDATE privileges on the employees table. The HR_MGR role is granted the DELETE and INSERT privileges on the employees table and granted the HR_CLERK role. The manager is granted the HR_MGR role and can now select, delete, insert, and update the employees table.

Benefits of Roles Easier privilege management
Dynamic privilege management Selective availability of privileges Can be granted through the operating system Benefits of Roles Easier Privilege Management Use roles to simplify privilege management. Rather than granting the same set of privileges to several users, you can grant the privileges to a role, and then grant that role to each user. Dynamic Privilege Management If the privileges associated with a role are modified, all the users who are granted the role acquire the modified privileges automatically and immediately. Selective Availability of Privileges Roles can be enabled and disabled to turn privileges on and off temporarily. Enabling a role can also be used to verify that a user has been granted that role. Granting Through the Operating System Operating system commands or utilities can be used to assign roles to users in the database.

Predefined Roles CREATE ANY JOB, CREATE JOB, EXECUTE ANY CLASS, EXECUTE ANY PROGRAM, MANAGE SCHEDULER SCHEDULER_ ADMIN No system privileges, but over 1600 object privileges on the data dictionary SELECT_ CATALOG_ ROLE Most system privileges, several other roles. Do not grant to nonadministrators. DBA CREATE TABLE, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TRIGGER, CREATE TYPE, CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR RESOURCE CREATE SESSION, CREATE TABLE, CREATE VIEW, CREATE SYNONYM, CREATE SEQUENCE, CREATE DATABASE LINK, CREATE CLUSTER, ALTER SESSION CONNECT Predefined Roles There are several roles that are defined automatically for Oracle databases when you run database creation scripts. CONNECT is granted automatically to any user who is created with Oracle Enterprise Manager. SELECT_CATALOG_ROLE is provided for accessing data dictionary views and packages. (This role is deprecated in favor of the SELECT_ANY_DICTIONARY system privilege.) The DBA role includes nearly all privileges and should not be granted to nonadministrators. Functional Roles Other roles that authorize you to administer special functions are created when that functionality is installed. For example, XDBADMIN contains the privileges that are required to administer the XML database if that feature is installed. AQ_ADMINISTRATOR_ROLE provides privileges to administer advanced queuing. HS_ADMIN_ROLE includes the privileges needed to administer heterogeneous services. You must not alter the privileges granted to these functional roles without the assistance of Oracle Support because you may inadvertently disable the needed functionality.

Using Proxy Authentication with Roles
Specify roles that the proxy is allowed to activate: Prevent any roles from being activated by the proxy: ALTER USER phall GRANT CONNECT THROUGH hruser WITH ROLE hr_clerk; ALTER USER phall GRANT CONNECT THROUGH appsrv WITH NO ROLES; Using Proxy Authentication with Roles The default allows a proxy to activate all roles that are granted to a user. If a user is allowed only certain privileges through a specific application, then you can limit the roles that the proxy may activate, as shown in the slide or with: ALTER USER phall GRANT CONNECT THROUGH appsrv WITH ALL ROLES EXCEPT hr_manager; If the user does not require any privileges in a specific application, then the proxy user can be prevented from activating any roles that may be granted to the user for use in other applications, with: ALTER USER phall GRANT CONNECT THROUGH appsrv WITH NO ROLES;

Securing Objects with Procedures
Object access can be strictly controlled through procedures. The object owner creates procedures and functions to access the object. Users are granted the EXECUTE privileges on program units. Users do not have direct access to objects. Securing Objects with Procedures When the built-in authorization mechanisms are not sufficient, an object-oriented approach is useful. Program units, procedures, and functions in the database, by default, run with definer’s rights. This means that the program unit executes with the privileges of the owner of the unit. The HR application owner has a Medical_History table with very strict access controls. The HR user creates PL/SQL procedures and functions to implement the allowed access. HR can grant the EXECUTE privilege on these program units to authorize certain users to perform only the actions that are implemented in the procedures. Users can only access the table through the procedures because they have not been granted any other object privileges. The procedures successfully access the table because they run with the privileges of HR. Program units can also run with invoker’s right. In this case, the procedure executes with only the privileges of the user that executes the procedure. This is useful for procedures that are very general and owned by SYS. An example is the DBMS_LOB package that provides the LOB access routines that may called by any user. But the invoker must have privileges to access LOB.

Secure Application Role
The secure application role solves the problem of preventing unauthorized access to data through other client programs. It is better than the previous mechanism with a hidden password. It uses the same SYS_CONTEXT mechanism as Virtual Private Database. Enabling a role is checked through a package, and not a password. Secure Application Role Often users are authorized to access certain objects only through an application that can control and check their actions. Before Oracle9i, password-enabled roles offered limited control because the password had to be supplied by the user or embedded in the application. If users have the password, they can enable the role at any time. If the password is embedded (hidden in the application code), there are several utilities that can easily reveal the password. The secure application role is only enabled through a package. The server checks the calling stack to ensure that the proper package is being used, so that it cannot be spoofed. To enable a secure application role, the associated procedure must be called, which controls whether the role is enabled. The procedure can make additional checks and get information about the user’s environment by using a call to SYS_CONTEXT('USERENV',nnn), where nnn can be, for example, IP_ADDRESS or PROXY_ACCOUNT. The EXECUTE privilege is granted on the package only to the application. So even if users know the details of the package, they cannot enable the role, except through the application.

Implementing a Secure Application Role
1. Create the role. 2. Create the package that sets the role: a. Create the package specification. b. Create the package body. 3. Grant the execute privilege on the package. 4. Write the application server code that sets the role. Implementing a Secure Application Role Roles grant authorizations to the authenticated user. You may require additional validation. For example, access may be restricted by time of day or client IP address. Because a secure application role is a role implemented by a package, the package can do the desired validation. Besides limiting the privileges of the application server, the secure application role prevents users from accessing data outside an application. They are forced to work within the framework of the application privileges that they have been granted. To create a secure application role, perform the following steps: 1. Create the secure application role. 2. Create the package that sets the role: a. Create the package specification. b. Create the package body. 3. Grant the execute privilege on the package so that the application server can set the role for the application user. 4. Write the application server code that sets the role by calling the package just created. Because the package does not need to exist when the CREATE ROLE command is issued, step 2 can be performed before step 1.

Step 1: Create the Role The CREATE ROLE command identifies the package that sets the role. The package does not need to exist. Example: CREATE ROLE oe_sales_rep IDENTIFIED USING secure.oe_roles; Step 1: Create the Role The CREATE ROLE command identifies the package that sets the role. The package does not need to exist when the role is created. When the procedure is called to set the OE_SALES_REP role, the calling stack is checked for the SECURE.OE_ROLES package.

Step 2.1: Create the Package Specification
The OE_ROLES package is referenced in the CREATE ROLE command. The AUTHID CURRENT_USER clause is required to properly set the role. Example: CREATE OR REPLACE PACKAGE oe_roles AUTHID CURRENT_USER IS PROCEDURE set_sales_rep_role; END; / Step 2.1: Create the Package Specification That Enables the Role Because procedures with definer’s rights always execute with the privileges of the owner, secure application roles can only be enabled inside procedures with invoker’s rights. The AUTHID CURRENT_USER clause defines procedures with invoker’s rights. It only applies to packages and stand-alone procedures and functions. For a package, it must be coded in the specification of the package and cannot be coded in the procedures or functions of the package: CREATE OR REPLACE PACKAGE oe_roles AUTHID CURRENT_USER IS PROCEDURE set_sales_rep_role; END; / Sometimes a secure package may need to access a secure table to retrieve all the roles that may be enabled. This table must be accessed by a definer’s rights procedure called from the secure procedure that sets the role. Create a definer’s rights package to return a list of roles from the secure schema (via an open cursor) to the invoker’s rights procedure. Then fetch from the cursor the list of roles to be enabled.

Step 2.2: Create the Package Body
... SELECT id INTO v_id FROM oe.app_roles WHERE username = sys_context ('userenv','current_user') AND role = 'SALES_REP' AND ip_address = sys_context ('userenv','ip_address'); dbms_session.set_role('oe_sales_rep'); Step 2.2: Create the Package Body That Enables the Role The package that enforces the secure application role selects from the APP_ROLES table. The APP_ROLES table validates users in the application by ensuring that the user enabling the role is connecting from a valid IP address. It contains the following columns: USERNAME contains the name of the user who is trying to enable the role. ROLE contains the name of the role that the user wants to enable. IP_ADDRESS contains the address of the client that can enable the row. For example, if the PHALL user can enable only the SALES_REP role from the IP addresses and , then the table would contain the following rows: USERNAME ROLE IP_ADDRESS PHALL SALES_REP PHALL SALES_REP

Step 3: Grant the EXECUTE Privilege on the Package
The application server connects as the appsrv user. It sets the role after it starts the user’s session. Example: GRANT execute ON oe_roles TO appsrv; Step 3: Grant the EXECUTE Privilege on the Package In this example, the account used by the application server is granted the EXECUTE privilege on the package. The application server can execute the package as it creates a session for the end user: GRANT execute ON oe_roles TO appsrv;

Step 4: Write the Application Server Code That Sets the Role
When starting, the application server: Connects as the APPSRV user Creates a connection pool When starting a session for a user, the application server: Gets a connection from the pool Starts a session for the user Sets the user’s role Set the user’s role by using: Step 4: Write the Application Server Code That Sets the Role To set the role for a user, the application server calls a procedure in the package referenced in the CREATE ROLE command. The procedure is called after the application server establishes a session for the user. Note: Do not grant the secure role to the user as a default role. If the role is granted to the user, it is enabled at login. If users have roles that they should have at login, the following command disables the secure role: ALTER USER phall DEFAULT ROLE ALL EXCEPT oe_sales_rep; secure.oe_roles.set_sales_rep_role;

Data Dictionary Views SQL> SELECT * 2 FROM dba_application_roles
3 WHERE ROLE = 'OE_SALES_REP'; ROLE SCHEMA PACKAGE OE_SALES_REP SECURE OE_ROLES SQL> SESSION_ROLES After the application server sets the role, the role appears in the SESSION_ROLES data dictionary view. DBA_APPLICATION_ROLES This data dictionary view lists all the secure application roles in the database. The example in the slide selects the role previously created. The SCHEMA column contains the owner of the package. Roles are not owned by a schema.

Implement roles Implement the securing of objects through procedures Describe how secure application roles work Manage roles and users by using secure application roles

Using Application Contexts

Objectives After completing this lesson, you should be able to do the following: Describe how an application context is used Describe the sources of application context values Implement a local context Implement an application context that is accessed globally

Application Context: Description
An application context is a memory container with attributes: The container is called a namespace. A namespace has attributes. Each namespace is independent of others. The namespace is populated by a package. Application Context An application context is a memory container with read-only attributes. You can use these attributes explicitly or implicitly in your application. Using an application context is like writing down an often-used phone number and pasting it next to your phone, where you can find it easily, rather than looking it up every time you need it. A context has an allocated area of memory called a namespace. The context or namespace has named attributes. Each attribute can hold a text string value. In some programming languages, this is known as an associative array. The application context namespace identifies the application context. For example, you may have the HRAPP and OEAPP namespaces that are used with the Human Resources and Order Entry applications, respectively. Multiple namespaces enable you to use the same attribute’s name in a different namespace without interfering with other namespaces. For example, the HRAPP and OEAPP application contexts can each have an attribute named ID that contains a different value in each context.

Namespace Use the CREATE CONTEXT command to:
HRAPP Use the CREATE CONTEXT command to: Create a context in a namespace Associate a package with the context CREATE CONTEXT hrapp USING hr_context; Use the SET_CONTEXT procedure to: Create attributes Set values of attributes Namespace A namespace is a set of names in a naming system where all names are unique. Each context is created in its own namespace. In the example in the slide, each attribute of the HRAPP context is unique within the HRAPP context. When a context is created, a memory area is allocated, and the context is given a name. A package is associated with the context at creation. This package is the only package that is allowed to set the attributes in a context. In the example in the slide, the HRAPP context is created and a package is named that has exclusive rights to set the attributes of the context. In the example, the package is HR_CONTEXT. The package calls the SET_CONTEXT procedure of the DBMS_SESSION package to set the value of an attribute. If the attribute does not exist, it is created. In the example, the emp_id attribute is created in the HRAPP context and the value of v_emp_id is assigned. The details of the PL/SQL calls are covered later in this lesson. dbms_session.set_context ( 'hrapp', 'emp_id', v_emp_id );

Using the Application Context
An application context: Is read by applications Can be used to: Authorize users Limit access to data, called FGAC Set attributes used in the application Using the Application Context Although the main benefit of using application contexts is improved performance, contexts are used with Oracle database security features, such as Virtual Private Database. With application context, you can write applications that use the attributes of the application context to perform the following: Authorize users when they log on. For example, you can verify that the user is connecting through a specific computer by verifying the user’s IP address. Set context attributes that are used by fine-grained access control (FGAC). Session properties may be used to limit the rows that the user can access. In an order-entry application, customers can access only their own orders by setting a context attribute with the current user’s customer number. Because of the way the context is set and used, you can implement FGAC without changing the application. Set the attributes that are used in the application. In this situation, set the attributes as part of the context, rather than accessing the attributes from a table. For example, if the user’s employee number is used frequently in the application, you can create a context attribute that contains the employee number, rather than selecting the employee number from a table.

Setting the Application Context
The context attributes are set by a package, which: Creates attributes in the context Assigns values to the attributes of the context Is usually called when a user connects Each application can use one or more contexts. A context may be used by more than one application. USERENV is a built-in context with session properties and is available to all applications. Setting the Application Context Setting the Attributes The application developer or security developer writes a package that assigns values to the context attributes. The attributes of the context can be set only with this package. This is the package that is associated with the context when the context is created. This package can be called by the application or a logon trigger. The package sets the attributes that are used for that session. These must be attributes that are frequently used by the application. The benefit of the context comes from caching these values in memory and not having to perform SQL or system callouts to retrieve them. Each application can have its own application-specific context. For example, the context attributes for a human resources application can include position, organizational unit, and country, whereas context attributes for the order-entry system may be customer ID and name. Applications can use more than one context, and a context may be used by more than one application. A special context is the built-in USERENV context. The USERENV context is populated with values that are commonly found in the V$SESSION and V$PROCESS views. For a full list of the attributes of the USERENV context, see the appendix titled “USERENV Context.”

Application Context Data Sources
The built-in USERENV context contains session primitives as attributes. Example: Client IP address A local context uses database objects. The developer sets these attributes. Example: The EMPLOYEE_ID column in the EMPLOYEES table An externalized context can get values from an external source, such as Oracle Call Interface (OCI). A global context uses values from the directory-entry attributes. Sources of Context Values A context can be classified by the source of the data values that it contains. The value that is assigned to the context attribute can have different sources. Built-in Context The built-in context called USERENV includes the following types of attributes: Client properties, such as the IP address of the client computer User properties, such as the proxy, session, and operating system user Authentication methods, such as the type (which indicates whether the user is authenticated through the database), the operating system, the network, or a proxy NLS settings, such as NLS_TERRITORY For a complete list, see “SYS_CONTEXT” in the Oracle Database SQL Reference 10g Release 1 (10.1) manual. Local Application Contexts You can retrieve attributes that are used for FGAC from any database object. For example, an EMPLOYEES table can include cost center, title, signing authority, and other information that is useful for FGAC. Also, values returned from procedures and functions can be used. For example, use a function that returns the employee ID to assign a value to the context attribute.

Implementing a Local Context
1. Create an application context. 2. Create a PL/SQL package that sets the context. 3. Call the package to set the context attribute. 4. Read the context attribute in the application. Set Application context Read PL/SQL package PL/SQL program Implementing a Local Context To build an application context, perform the following steps: 1. Create an application context. The application context is associated with the package in step 2. This ensures that the context is changed only through the package. 2. Create a PL/SQL package that sets the attributes in the application context. 3. Call the package from the application or in a logon trigger. The logon trigger is shown in this example. 4. Read the application context attributes in your application. Note: Steps 1 and 2 can be reversed. In the following example, an application context, HRAPP, is created by using the hr_context package. The context holds an emp_id attribute that has the value of employee_id for each user that logs in. The value is retrieved from the hr.employees table on the basis of the user’s address. It is assumed for this example that the user’s login name is the same as the user’s ID.

Step 1: Create an Application Context
Create a unique context: Names the context HRAPP Associates it with an HR_CONTEXT package You can set the context attributes only: In the package named in CREATE CONTEXT In the function associated with a policy In the package, set attributes by calling DBMS_SESSION.SET_CONTEXT. Alternatively, you can use Oracle Policy Manager GUI. CREATE CONTEXT hrapp USING hr_context; Step 1: Create an Application Context To perform this task, use the CREATE CONTEXT statement. Each context must have a unique attribute and must belong to a namespace. That is, context names must be unique within the database, not just within a schema. Contexts are always owned by the SYS schema. Example: CREATE CONTEXT hrapp USING hr_context; where: HRAPP is the context namespace HR_CONTEXT is the trusted package that can set attributes in the context namespace

Step 2: Create a PL/SQL Package That Sets the Context
Create the HR_CONTEXT.SET_EMP_ID procedure: Use SYS_CONTEXT to get the session username: sys_context('userenv', 'session_user'); Use the session username to get the employee ID: SELECT employee_id INTO v_emp_id FROM employees WHERE = sys_context('userenv', 'session_user'); Use SET_CONTEXT to set a context attribute: Step 2: Create a PL/SQL Package That Sets the Context Create a PL/SQL package with functions that sets the context for your application. The following example creates the HR_CONTEXT package. The package sets the EMP_ID attribute of the HRAPP context: CREATE OR REPLACE PACKAGE hr_context IS PROCEDURE set_emp_id; END; / CREATE OR REPLACE PACKAGE BODY hr_context IS PROCEDURE set_emp_id IS v_emp_id NUMBER; BEGIN SELECT employee_id INTO v_emp_id FROM hr.employees WHERE = SYS_CONTEXT('USERENV', 'SESSION_USER'); DBMS_SESSION.SET_CONTEXT ('hrapp', 'emp_id', v_emp_id); EXCEPTION WHEN no_data_found THEN ('hrapp', 'emp_id', 0); dbms_session.set_context ( 'hrapp', 'emp_id', v_emp_id );

Step 3: Call the Package Create a logon trigger that calls the HR_CONTEXT.SET_EMP_ID procedure: CREATE OR REPLACE TRIGGER hr_context_logon AFTER LOGON ON phall.SCHEMA BEGIN hr_context.set_emp_id(); END; / Step 3: Call the Package Although a logon trigger is not required (the application can initialize the context at any time), it is highly recommended because the user’s context must be set before the user accesses any data: CREATE OR REPLACE TRIGGER hr_context_logon AFTER LOGON ON phall.SCHEMA BEGIN hr_context.set_emp_id(); END; / The example shows a logon trigger that affects only a single user or schema. If all application users are connecting as PHALL, this is an effective method of setting the context. If all users are connecting with their own usernames, the following alternative logon trigger can be used: AFTER LOGON ON DATABASE

Step 4: Read the Context Attribute in the Application
To return an attribute value, use: There are two arguments: Name of the context Name of the attribute Example in SELECT: sys_context('hrapp', 'emp_id') SELECT * FROM departments WHERE manager_id = sys_context('hrapp','emp_id'); Step 4: Read the Context Attribute in the Application Access the application context attributes, and use them where they are needed in your application.

SYS_CONTEXT PL/SQL Function
SYS_CONTEXT returns context attributes: sys_context ('context', 'attribute') To return the client IP address from the built-in context, use: To return EMP_ID from the HRAPP context, use: sys_context ('userenv', 'ip_address') sys_context ('hrapp', 'emp_id') PL/SQL Function SYS_CONTEXT This function returns the values of context attributes, including: Built-in attributes from the USERENV context, which contains session properties User-defined attributes from user-defined contexts Syntax This function has the following syntax: SYS_CONTEXT ('context', 'attribute') where: context is the name of the application context attribute is the name of the attribute in this context The function returns the value of the attribute. Example: The examples in the slide show SYS_CONTEXT being used to: Return the IP address of the client computer, by using the IP_ADDRESS attribute of the built-in USERENV context Return the employee ID from the HRAPP context

Application Context Accessed Globally
Shares a context across sessions Simplifies connection pooling from a middle tier Uses a client identifier to identify the user of a session SGA Application context is EMP ID = 101 PL/SQL program A PL/SQL program B Application Context Accessed Globally By default, the memory for the application context is allocated from the session’s Private Global Area (PGA). In many application architectures, the middle-tier application is responsible for managing connection pooling for application users. Users authenticate themselves to the application. The application then uses a single identity to log in to the database and maintains all the connections. In a connection pooling environment, usually any user can use any connection. The application decides the connection that a user request can use. In this environment, it is not possible to maintain application attributes by using session-dependent secure application context, because the context is private to each session. And because of the sessionless model of the application, any user can use any session. The application context accessed globally is a type of secure application context that can be shared among trusted sessions. It can be shared because the memory for the context is allocated from the Shared Global Area (SGA). Middle-tier applications use globally accessed application contexts to manage application attributes securely and globally. Global application contexts with connection pooling allow multiple connections to access one or more contexts, instead of setting up an application context for each user session. Globally accessed application contexts provide additional flexibility for Web-based applications. They also provide enhanced performance through the reuse of common application contexts among multiple sessions, instead of setting up application contexts for each session. User Database Session 1 User Database Session 2

How the Application Context Accessed Globally Works
2. Logs in 6. Makes another request 8. Logs out 1. Builds connection pool 3. Establishes session 4. Processes request 5. Completes request 7. Processes second request 9. Clears context How the Application Context Accessed Globally Works The boxes in the slide show the actions being performed. The box on the left shows the actions taken by the user. The box on the right shows the actions taken by a program running on the application server. 1. The application server starts up and builds its connection pool by establishing multiple connections to the database as the APPSMGR user. 2. The user PHALL logs in to and is authenticated by the application server. 3. The application server establishes a session for the request from PHALL by: Using a connection from the connection pool Calling SET_IDENTIFIER to assign a session client identifier for the PHALL username Setting the application context Saving the client identifier in the browser of PHALL as part of a cookie, or maintaining the client identifier within the application server 4. The application server processes the request of PHALL. When the application reads contexts, it does not include the client identifier because the SET_IDENTIFIER call in step 3 has already identified the session. PHALL Application Server Oracle9i

PL/SQL Packages and Procedures
DBMS_SESSION manages: Contexts: Global identifiers: set_context(context, attribute, value ); dbms_session.set_context ('hrapp', 'emp_id', v_emp_id ); dbms_session.set_identifier(client_id); dbms_session.set_identifier(12345); PL/SQL Packages and Procedures DBMS_SESSION Use the programs in the DBMS_SESSION package to: Maintain application contexts List application contexts Maintain client identifiers that are used with global application contexts The procedures and functions in DBMS_SESSION listed on the following pages include only those that are related to application contexts. Examples: The first SET_CONTEXT example sets the EMP_ID attribute in the HRAPP context to the value in the V_EMP_ID PL/SQL variable. Because the client identifier is not included as an argument, this context is not being shared. The second example sets a session client identifier for PHALL, enabling the session to access a context accessed globally.

Implementing the Application Context Accessed Globally
1. Create the application context accessed globally. 2. Modify the program that establishes a session: Set the application context. Set the session client identifier. Clear the client identifier when the request ends. 3. Modify the application server program that handles subsequent requests in the same session: Set the session client identifier from this session. 4. Create or modify the application server program that ends a session to clear the context. Implementing the Application Context Accessed Globally To implement an application context accessed globally, perform the steps mentioned in the slide. Because the application server sets the session client identifier when a session is established, the application programs that access the application context are coded the same, whether or not the context is accessed globally. In either case, you do not include the session client identifier when reading an application context. These instructions apply only to application contexts that need to be preserved between database connections. For a stateless session, you can use an application context without accessing it globally. The SET_IDENTIFIER procedure sets an arbitrary value as CLIENT_ID. This value is used to identify a user. A user can receive the same client identifier every time he or she connects, or it can be unique every day or every hour. When you decide on the assignment of the client identifier, consider how cookies can be intercepted and possibly used to hijack user sessions or spoof user authentications. The client identifier must never contain any private or personal information that may be used to steal a user’s identity.

Step 1: Create the Application Context Accessed Globally
Create the context by using: The ACCESSED GLOBALLY clause indicates that the context can be accessed from multiple sessions. CREATE CONTEXT hrapp USING hr_context ACCESSED GLOBALLY; Step 1: Create the Application Context Accessed Globally The example in the slide creates the HRAPP application context that is initialized in the HR_CONTEXT package. You must indicate that the application context is accessed globally.

Step 2: Establish a Session
1. Get a unique value to use as a client identifier. 2. Set the application context: 3. Set the session client identifier: 4. Save the client identifier in a cookie. dbms_session.set_context (context, attr, value, username, client_id); dbms_session.set_context ('hrapp','id','phall','APPSMGR', ); ('hrapp','dept','sales','APPSMGR', ); Step 2: Establish a Session When the user connects to the application server, the application server uses a connection from its connection pool to connect that user to the database. After the connection is obtained, the application server checks to see whether the user has already established a session. It checks for the cookie containing the session client identifier. If there is no client identifier, the application server establishes the session by: 1. Getting a unique client identifier (for example, the username) 2. Calling the package that sets up the context for this session by using the client identifier. The package must include the client identifier when it sets the context. 3. Setting the session client identifier by using SET_IDENTIFIER 4. Saving the client identifier in a cookie If there is a client identifier in the cookie, this is not the initial request; the procedure for a subsequent request is used. Using the Global Application Context In the application, all SYS_CONTEXT calls within this database session return application context values belonging to the client session only. For example, the call SYS_CONTEXT('hrapp', 'id') returns PHALL. dbms_session.set_identifier( );

Step 3: Handle Subsequent Requests
1. Get the client identifier from the cookie. 2. Set the client identifier for this session: 3. Clear the client identifier when the request ends: dbms_session.set_identifier( ); dbms_session.clear_identifier(); Step 3: Handle Subsequent Requests 1. Get the client identifier: If there is a session client identifier in the cookie, this user has already established a session. Therefore, use the client identifier to ensure that the users access the correct application context. 2. Set the client identifier for this session: Because the application context can be shared among database connections, it does not matter which database connection processes this request from the user. 3. Clear the identifier: At the end of the request, before the connection is put back into the connection pool, clear the current client identifier. This ensures that the next session cannot inadvertently use a left-over client identifier to access an inappropriate context.

Step 4: End a Session 1. Get the client identifier from the cookie.
2. Clear the context: EXEC dbms_session.clear_context ('HRAPP', '12345'); Step 4: End a Session When the user has completed all requests and wants to end his or her session, clear the context that applies to the user’s session. In the example in the slide, all the attributes for the HRAPP application context for the client identifier are cleared, because the attribute name is not included as the third argument.

Data Dictionary Views SQL> CREATE CONTEXT hrapp USING hr_context;
Context created. SQL> SELECT * 2 FROM dba_context 3 WHERE namespace = 'HRAPP'; NAMESPACE SCHEMA PACKAGE TYPE HRAPP SYS HR_CONTEXT ACCESSED LOCALLY SQL> Data Dictionary Views The data dictionary includes the following views that are related to application contexts: ALL_CONTEXT describes all context namespaces in the current session for which attributes and values have been specified by using the DBMS_SESSION.SET_CONTEXT procedure. It has the same columns as DBA_CONTEXT. DBA_CONTEXT describes all context namespaces that are defined in the database, regardless of whether any attributes have been specified for them by using the DBMS_SESSION.SET_CONTEXT procedure. The example in the slide uses this view. DBA_GLOBAL_CONTEXT contains a description of all context information that is accessible globally. This view is a subset of the information in DBA_CONTEXT.

Guidelines Attempting to change the context outside of its package results in the following error message: ORA-01031: insufficient privileges SYS_CONTEXT works much like a bind variable. Versioning does not apply to contexts accessed globally. There are parallel query and RAC limitations. Context sources must be validated. Guidelines Setting the Context Outside of the Package If you try to change the context outside of the package specified in the CREATE CONTEXT command, you receive an error message stating that you do not have the privilege required to change the context: SQL> exec DBMS_SESSION.SET_CONTEXT ('hrapp', 'emp_id', 0); BEGIN DBMS_SESSION.SET_CONTEXT ('hrapp', 'emp_id', 0); END; * ERROR at line 1: ORA-01031: insufficient privileges ORA-06512: at "SYS.DBMS_SESSION", line 78 ORA-06512: at line 1

Use an application context Access the sources of application context values Implement a local context Implement an application context that is accessed globally

Using Fine-Grained Access Control

Objectives After completing this lesson, you should be able to do the following: Describe how fine-grained access control (FGAC) and the Virtual Private Database (VPD) work Implement FGAC or the VPD Group policies

Fine-Grained Access Control: Overview
SELECT * FROM orders; Limits row access Uses a predicate Is returned from a function Is associated with a table or view Is automatically enforced SELECT * FROM orders WHERE sales_rep_id = 406; ORDERS SELECT * FROM orders; Fine-Grained Access Control: Overview Fine-grained access control (FGAC) enables you to build applications that enforce security policies at a low level of granularity. You can use FGAC to restrict access by rows and columns, as in the following examples: Customers can see only their own accounts. Physicians see only the records of their own patients. Managers see only the records of employees who work for them. A fulfillment clerk sees customer records for shipping purposes, but not columns with credit card numbers. To use FGAC, create security policy functions that return a predicate (a WHERE condition). After you attach the function to a table or view, the predicate controls the rows accessed from the table or view. When a user enters a SQL statement (SELECT, INSERT, UPDATE, or DELETE) on that object, the Oracle instance dynamically modifies the user’s statement—transparently to the user or application—so that the user sees only the appropriate rows. The policy can be set to add the predicate only when certain columns of interest are accessed, allowing the control to be more fine-grained and reducing the overhead when those columns are not accessed. SELECT * FROM orders WHERE sales_rep_id = 152;

Benefits Security: FGAC is always applied. Simplicity: Flexibility:
Define once Independent of application Flexibility: Apply different access to different SQL statements. Group policies. High performance: Static and dynamic policies Active policies stored in memory Benefits Security FGAC attaches security policies to tables or views. No matter how a user accesses the data, the same security is always in force. Simplicity Adding the security policy to the table or view means that you make the addition only once, rather than repeatedly adding it to each of your table- or view-based applications. Flexibility You can have one security policy for the SELECT statement, another for the INSERT statement, and still others for the UPDATE and DELETE statements. For example, you may want to enable a Human Resources clerk to select all employee records in his or her division, but to update salaries only for those employees in his or her division whose last names begin with “A” through “F.” High Performance You can control the evaluation frequency of the policies by declaring them static, context-sensitive, or dynamic in Oracle Database 10g. Active policies are cached in the shared pool for fast evaluation.

Virtual Private Database
A Virtual Private Database (VPD) combines an application context and FGAC to: Enforce business rules to limit row access Use a secure application context to provide high performance resolution of user attributes. Virtual Private Database A Virtual Private Database (VPD) uses FGAC to limit row and column access and an application context to provide the information that is used to set the policy predicates. FGAC is an enabling technology that is a building block for a VPD and Oracle Label Security. FGAC without the use of an application context often requires subqueries and repeated evaluation of the policy. By using a context, the policy predicate often remains the same, reducing or eliminating the need to reevaluate the policy and eliminating the cost of executing a subquery. The VPD feature is available with Oracle Database 10g Enterprise Edition.

Examples of the Virtual Private Database
The VPD allows multiple policies on the same table: Customer example: Context attribute: cust_id Predicate: customer_id = sys_context ('oeapp', 'cust_id') Sales representative example: Context attribute: emp_id Predicate: sales_rep_id = sys_context ('oeapp', 'emp_id') Examples of the Virtual Private Database Consider an order-entry application, which enforces the following rules: Customers see only their own orders. Account managers see only orders for their customers. Sales representatives see only the orders that they entered. Sales analysts do not see credit card numbers. These rules require different predicates: one for customers, another for employees. For customers, the predicate uses the customer identifier to limit the rows that are accessed. So you define a context with a cust_id attribute. For employees, you can define an application context with an employee identifier and job-title attribute, and these attributes can be accessed within the policy function to return the correct predicate, depending on the value of the attributes. Thus, you can enable a user in the account manager position to retrieve all the orders for his or her customers. The sales analyst can view and summarize customer information without having access to sensitive information. The sales representative can access all the records for his or her customers. To design a VPD policy to return a specific predicate for an attribute, access the application context within the function that implements the policy.

How Fine-Grained Access Control Works
1. The user accesses a table or view with a policy. 2. The data server calls the policy function. 3. The policy function returns a predicate. 4. The data server adds the predicate to the statement. 5. The data server executes the modified statement. SELECT * FROM orders; SELECT * FROM orders WHERE customer_id = sys_context ('oeapp', 'cust_id'); How Fine-Grained Access Control Works FGAC is based on dynamically modified statements. For example, you have implemented a policy that customers can see only their own orders. The policy causes any data manipulation language (DML) statement, including SELECT, which accesses the ORDERS table to be modified to restrict row access. This description is for the row-level access control. For column-level access control, the columns of interest are checked first. If no columns of interest are accessed, no predicate is applied. An example of FGAC policy execution is as follows: 1. The user accesses the object ORDERS table with the statement: SELECT * FROM orders_tab; The DML statement can be SELECT, UPDATE, INSERT, DELETE, or MERGE. For MERGE, the policy is applied as the statement performs the UPDATE and INSERT phases of its operation. For SELECT, the security is enforced even when the table is accessed in a subquery. 2. The Oracle server calls the security function that implements the security policy for the ORDERS table. If you are using policy groups, the Oracle data server looks up the driving context to determine the policy group in effect and calls the security function in that group. becomes

Tools The PL/SQL procedures and packages, such as:
SYS_CONTEXT returns context attributes DBMS_SESSION manages: - Contexts - Global identifiers DBMS_RLS manages: - Policies - Policy groups Oracle Policy Manager is a GUI that: Uses DBMS_RLS Provides security policy administration Manages the VPD and Oracle Label Security Tools SYS_CONTEXT This function returns the values of context attributes, including: Built-in attributes that contains session properties User-defined attributes from user-defined contexts DBMS_SESSION Use the procedures and functions in the DBMS_SESSION package to: Maintain application contexts List application contexts Maintain identifiers used with global contexts Note: The DBMS_SESSION package runs with the rights of the calling user. Some procedures and functions are executable by the PUBLIC user. The routines that set and modify the context must be called directly or indirectly by the trusted package. The security of the context is controlled by the privileges granted on the trusted package. The DBMS_SESSION routines check the calling stack for the trusted package. Therefore, these DBMS_SESSION routines cannot be run from the SQL*Plus command line directly.

Oracle Policy Manager Oracle Policy Manager
Oracle Policy Manager (OPM) is the GUI administration tool for the following features: Oracle Label Security Virtual Private Database Application context It is not automatically installed with Oracle Enterprise Manager Database Control. This tool is part of the Java console and is installed from the Oracle Database 10g Client CD. The tool is invoked by entering the following command at the operating system command prompt: $ oemapp opm APIs are available in place of OPM. For more information, see the Oracle Label Security Administrator’s Guide and Application Developer’s Guide.

DBMS_RLS Associate policies with tables or views:
ADD_POLICY ADD_GROUPED_POLICY Enable and disable policies: ENABLE_POLICY ENABLE_GROUPED_POLICY Refresh policies: REFRESH_POLICY Group policies: CREATE_POLICY_GROUP Manage driving contexts: ADD_POLICY_CONTEXT DROP_POLICY DROP_GROUPED_POLICY DISABLE_GROUPED_POLICY REFRESH_GROUPED_POLICY DELETE_POLICY_GROUP DROP_POLICY_CONTEXT DBMS_RLS Package Procedures These procedures are used to create, drop, enable, disable, and group policies. Note that the argument for the policy group name is different in different procedures. It can be POLICY_GROUP or GROUP_NAME. The DBMS_RLS procedures cause current DML transactions, if any, to commit before the operation. However, the procedures do not cause a commit first if they are inside a data definition language (DDL) event trigger. The DBMS_RLS procedures are part of DDL transactions. Syntax for the procedures in the DBMS_RLS package is shown in the slides where those procedures are discussed. The syntax for the other procedures is shown in PL/SQL Packages and Types Reference 10g Release 1 (10.1). Parameters The parameters that are used by the procedures in the DBMS_RLS package have common names. Every parameter has the same meaning regardless from which procedure the parameter is called. For example, object_schema always means the name of the schema containing the table, view, or synonym (current default schema, if NULL).

Column-Level VPD Statements are not always rewritten.
Example: A policy protects the SALARY and the COMMISSION_PCT columns of the EMPLOYEES table. The FGAC is: Not enforced for this query: Enforced for these queries: SQL> SELECT last_name FROM employees; SQL> SELECT last_name, salary 2 FROM employees; Column-Level VPD Suppose that the business policy and the imposed VPD policy is that a manager can access the EMPLOYEES sensitive information only for his or her employees. The SALARY and COMMISSION_PCT columns are considered sensitive information. The Oracle database does not enforce the VPD policy when you select only the LAST_NAME column from the EMPLOYEES table. So all employees can access nonsensitive information in the EMPLOYEES table. However, when you issue queries that access columns considered as security relevant, the VPD applies the FGAC defined by the policy function. One of the benefits of using column-level VPD is that the statements are only rewritten when they access security-relevant columns. This means that the combination of row-level access control and security-relevant columns implies that you can control access down to the element referenced. Note: Some commands explicitly reference the columns and others reference them implicitly. Depending on how you define the policy function, it can be applied for DML statements as well. SQL> SELECT * FROM employees;

Column-Level VPD: Example
BEGIN dbms_rls.add_policy(object_schema => 'hr', object_name => 'employees', policy_name => 'hr_policy', function_schema =>'hr', policy_function => 'hrsec', statement_types =>'select,insert', sec_relevant_cols=>'salary,commission_pct' sec_relevant_col_opts=> dbms_rls.ALL_ROWS); END; / Column-Level VPD: Example When you apply the policy to the table, view, or synonym by using the DBMS_RLS package, use the sec_relevant_cols parameter to name the significant columns. Then you may apply the sec_relevant_col_opts constant. There are two options: ALL_ROWS and NULL. In the example, you apply the policy that is implemented by the HRSEC function to the EMPLOYEES table. You also set the policy to apply only the VPD predicate for the SELECT and INSERT statements. The two security-relevant columns in the EMPLOYEES table are SALARY and COMMISSION_PCT. sec_relevant_col_opts applies only to the SELECT operations. When set to dbms_rls.ALL_ROWS, all rows are displayed but the columns named in sec_relevant_cols have NULL values for the rows that the user is not permitted to access. When sec_relevant_col_opts is NULL, only the rows that are allowed by the policy are displayed.

Policy Types: Overview
The policy types specify how often a policy function should be reevaluated. The types are: Dynamic DBMS_RLS.DYNAMIC (Default) Static DBMS_RLS.STATIC DBMS_RLS.SHARED_STATIC Context sensitive DBMS_RLS.CONTEXT_SENSITIVE DBMS_RLS.SHARED_CONTEXT_SENSITIVE Shared: Shared policies allow you to share the same policy function with different objects Policy Types: Overview The execution of policy functions can consume a significant amount of system resources. If you can minimize the number of times policy functions must execute, you can optimize your database performance. In Oracle9i, policies were dynamic by default. This means that the Oracle database executed the policy function for each DML statement. In addition to dynamic policies, Oracle Database 10g provides static and context-sensitive policies. These policy types provide a way to improve server performance because they do not always reexecute policy functions for each DML statement, and they can be shared across multiple database objects. The five different policy types in three groups are listed in the slide. The DBMS_RLS.DYNAMIC type is the default and corresponds to what was available in previous releases. DBMS_RLS.DYNAMIC means that the Oracle database assumes that the predicate may be affected by any system or session attribute. The Oracle database makes no assumption about when the change takes place and, therefore, always reexecutes the policy function on each statement parsing or execution. Shared policies allow you to specify the same policy on multiple objects.

Static Policies The policy function is evaluated once.
The resulting policy predicate is cached in memory. Every statement accessing protected objects uses the same policy predicate. exec dbms_rls.add_policy( object_schema =>'hr', object_name => 'employees', - policy_name => 'hr_policy' , - function_schema =>'hr',policy_function=>'hrsec' , - statement_types => 'select,insert' , - policy_type => dbms_rls.static , - sec_relevant_cols =>'salary,commission_pct'); Static Policies When you use static policies, VPD always enforces the same predicate for access control. Regardless of which user accesses the objects, everyone gets the same predicate. The policy function is executed only once. The returned predicate is cached in system global area (SGA) for all static policies with the same policy function. This makes static policies very fast because the policy function is not executed for each query. You can use a static policy when every query needs the same policy predicate. The caching behavior for shared static policies is exactly the same as static policies, except that the Oracle database first looks for cached predicates generated by the same policy function of the same policy type. You can enable static or shared static policies by setting the POLICY_TYPE parameter of the DBMS_RLS.ADD_POLICY procedure to DBMS_RLS.STATIC or DBMS_RLS.SHARED_STATIC, respectively. In this example, the business policy is that a manager can access the EMPLOYEES sensitive information only for his or her employees. Note: The policy predicate is the same for every rewritten statement. But each execution of the same rewritten statement can produce a different row set because the predicate may filter the data differently according to context attributes or functions (such as SYSDATE).

Context-Sensitive Policies
The policy function is evaluated for each session when: The statement is first parsed There is a related change in the local application context The resulting policy predicate is cached in the user’s session memory. exec dbms_rls.add_policy( object_schema =>'hr', object_name =>'employees2', - policy_name => 'hr_policy2' , - function_schema =>'hr',policy_function=>'hrsec2', - statement_types => 'select,insert' , - policy_type => dbms_rls.context_sensitive , - sec_relevant_cols =>'salary,commission_pct'); Context-Sensitive Policies Policies are not always static or dynamic. Policy predicates may be static for a particular user session, but different for other users. In some cases, policy predicates can change when certain context attributes are changed within a user session. For either of these situations, you enable context-sensitive or shared context-sensitive policies by setting the POLICY_TYPE parameter of the DBMS_RLS.ADD_POLICY procedure. A policy type of DBM_RLS.CONTEXT_SENSITIVE assumes that the policy predicate may be changed after statement parsing for a particular database session. This change can occur only if there are some session context changes. Therefore, the server reevaluates the policy function at statement execution time if it detects context changes since the last use of the cursor. The policy predicate is cached in the session memory. When the policy type is set to DBMS_RLS.SHARED_CONTEXT_SENSITIVE, the context-sensitive policy shares its policy function. The caching behavior is similar to the nonshared policy except that the server first looks for cached policy predicate generated by the same policy function for the same policy type within the same database session. In this example, the business policy is that a manager can access the EMPLOYEES2 sensitive information only for his or her employees, and employees who are not managers can access only their own sensitive information.

Sharing Policy Functions
departments emp_v Same policy function Sharing Policy Functions With Oracle Database 10g, you can apply both the static and nonstatic VPD policies to multiple objects. These policies are called shared policies. With shared policies, you can enforce a company’s business policy (such as “Users should see only data relevant to their business line”) on several objects by using a single policy function. This is very helpful in easing the administration of policy functions. This is a better model than repeatedly creating one policy function per object. To share policy functions, you must use the same policy function in each policy that you define with the DBMS_RLS.ADD_POLICY procedure. Each policy has its own name, but the corresponding functions are the same. The policy type must be DBMS_RLS.SHARED_STATIC or DBMS_RLS.SHARED_CONTEXT_SENSITIVE. countries employees

Exceptions to FGAC Policies
Policies are not enforced for: DIRECT path export Users with DBA privileges ( AS SYSDBA ) Users granted EXEMPT_ACCESS_POLICY Exceptions to FGAC Policies FGAC policies are the basis for the VPD and Oracle Label Security. The exceptions listed here apply to both: DIRECT Path Export FGAC policies are not enforced during DIRECT path export. Only SYS, a user with the EXPORT_FULL_DATABASE role enabled, or a user who has been granted the EXEMPT ACCESS POLICY privilege can perform DIRECT path export. Users with DBA Privileges ( AS SYSDBA ) FGAC policies cannot be applied to objects in the SYS schema. Consequently, the SYS user and users making a DBA-privileged connection to the database (for example, CONNECT /AS SYSDBA) do not have FGAC policies applied to their actions. They are always exempted from FGAC enforcement. However, the SYSDBA actions can be audited. Users Granted EXEMPT ACCESS POLICY Database users that are granted the EXEMPT ACCESS POLICY privilege, either directly or through a database role, are exempted from FGAC enforcements. EXEMPT ACCESS POLICY is a very powerful privilege and should be carefully managed. Do not grant this privilege by using the WITH ADMIN OPTION clause.

Implementing a VPD 1. Create a PL/SQL package that sets the context.
2. Create an application context: Is associated with the package created in step 1 Prevents the context from being changed 3. Write the function that creates a predicate: Use the application context created in step 2. Return a predicate for a WHERE clause. 4. Create a policy: Associates the function with a table Causes the predicate to be added to the WHERE clauses Implementing a VPD To implement a VPD, perform the steps listed in the slide and shown in the example in the following slides and notes. Steps 1 and 2 are the same as listed in the lesson titled “Using Application Contexts” but use a different context and package. Step 1: Create a PL/SQL package that sets the context. Notice that OEAPP is the name of the context. The following creates the oe_security package: CREATE OR REPLACE PACKAGE oe_security IS PROCEDURE set_cust_id; END; / CREATE OR REPLACE PACKAGE BODY oe_security IS PROCEDURE set_cust_id IS v_cust_id NUMBER; ...

Step 3: Write the Function That Creates a Predicate
CREATE PACKAGE BODY oe_security AS FUNCTION cust_order ( object_schema VARCHAR2, object_name VARCHAR2 ) RETURN VARCHAR2 IS BEGIN RETURN 'customer_id = sys_context(''oeapp'', ''cust_id'')'; END cust_order; END oe_security; Step 3: Write the Function That Creates a Predicate The function that implements the security policy on the database object can access the context for best performance. This function can be stand-alone or part of a package. The example shows the function as part of a package, assuming that the security policies for the entire order-entry application would be implemented as functions in the OE_SECURITY package. Function Specification The policy functions are called by the server. They require the following specification: FUNCTION policy_function ( object_schema IN VARCHAR2, object_name IN VARCHAR2 ) RETURN VARCHAR2 where: object_schema is the schema owning the table or view. object_name is the name of the table or view to which the policy is applied.

Testing the Security Function
SQL> SELECT oe_security.cust_order('a', 'b') FROM dual; OE_SECURITY.CUST_ORDER('A','B') customer_id = SYS_CONTEXT('oeapp', 'cust_id') Testing the Security Function Because the security function does not access the context, you can easily test the function by calling it and verifying that the appropriate predicate is returned: SQL> SELECT oe_security.cust_order('a', 'b') FROM dual; OE_SECURITY.CUST_ORDER('A','B') customer_id = SYS_CONTEXT('oeapp', 'cust_id')

Writing a Function That Returns Different Predicates
The owner of the table has access to all rows: Sales representatives see only their orders: Customers can see only their own orders: Other users have no access: RETURN '1=1'; RETURN 'sales_rep_id = sys_context(''hrapp'', ''emp_id'')'; RETURN 'customer_id = sys_context(''oeapp'', ''cust_id'')'; Writing a Function That Returns Different Predicates In reality, you may have several different predicates based on a user’s status. For example, a sales manager would be able to see the records only for his or her customers, and a customer can only see his or her own orders. To implement these policies, expand the cust_order function to return different predicates depending on the context values of the user. Example: The example enforces the following rules: The owner of the table has access to all rows in the table. Sales representatives can see only the orders that they have entered. Customers can see only their own orders. Any other user has no access to the table. The rules enforced in this function use the following logic: If the user is the owner of the object, which is the first argument, then the predicate 1=1 is returned, which always evaluates to TRUE and lets the owner see all the rows in the table. RETURN '1=2';

Step 4: Create a Policy Create the policy as follows:
Arguments include the following: Associated table: OE.ORDERS Policy name: OE_POLICY Function: SECURE.OE_SECURITY.CUST_ORDER Applies to: SELECT dbms_rls.add_policy ( object_schema =>'oe', object_name => 'orders', policy_name => 'oe_policy', function_schema =>'secure', policy_function =>'oe_security.cust_order', statement_types =>'select') Step 4: Create a Policy Create the policy by using the code in the slide. This statement adds a policy named OE_POLICY to the ORDERS table in the OE schema. The OE_SECURITY.CUST_ORDER function is stored in the SECURE schema and returns the policy predicate. The policy applies to the SELECT statements only. Naming the Policy The policy name includes the two entities that are involved in the security relationship; customers (CUST) can see only their own orders (ORDER). Execute Privilege on the Policy Function You need not grant the execute privilege on the security package to application users.

Partitioned Fine-Grained Access Control
Application-driven security policies Different policies apply, depending on the active driving context Policies can be developed independently. The default policy always applies. Useful when hosting applications Order-entry policy group Inventory policy group Default policy AND AND Orders Partitioned Fine-Grained Access Control Before the introduction of partitioned FGAC in Oracle9i, all policies defined on a table or view were applied to all SQL statements. The policies written for one product would generate predicates for other products. This required development groups to collude on policies. Partitioned FGAC is introduced to allow application-driven security policies. A partitioned application context facilitates application development by using VPD. Because development groups no longer need to collude, applications can have different security policies based on their individual application needs. You can use policy groups and a driving application context to partition FGAC enforcement so that different policies apply for each application that is accessing the data. The application sets the active driving context so that only the policy group for that application is applied. This simplifies application development. Driving Application Context A driving application context is a context that holds at least one attribute. This attribute is used to determine which group of policies will be applied. The driving application context is set by the application that is accessing the data. The Oracle data server references the driving application context to determine which policy group to apply.

Grouping Policies 1. Determine the default policies.
2. Set up a driving context for each table: a. Create the context. b. Create the function that sets the context. c. Make the context the driving context. 3. Create a policy group for each application. 4. Add each policy to the appropriate group. Grouping Policies The slide outlines the steps to create and implement grouped policies.

Default Policy Group A predefined default policy group is always applied. It is named SYS_DEFAULT. Each object has a default group. Default Policy Group With the partitioning of FGAC policies, administrators can specify which policy group the policy belongs to when adding a policy to a table or view by using the ADD_POLICY_TO_GROUP interface. SYS_DEFAULT Group There is a predefined policy group named SYS_DEFAULT. Policies defined in this policy group for a particular table or view are always executed along with the policy group specified by the driving context. Default Group By default, all policies belong to the SYS_DEFAULT policy group. The policies defined in this group for a particular table or view are always executed along with the policy group specified by the driving context. The SYS_DEFAULT policy group may or may not contain policies. For example, in a hosting environment, the policy that restricts the customers to seeing their own rows may be in this group.

Creating a Driving Context
Create the context: Create the procedure that sets the context: CREATE CONTEXT app_driver USING secure.apps_cxt_pkg; CREATE OR REPLACE PACKAGE BODY secure.apps_cxt_pkg PROCEDURE set_driver( policy_group VARCHAR2)... APP_ DRIVER Creating a Driving Context Create a context and a trusted package to set the attributes in the same way as described in the lesson titled “Using Application Contexts.” The driving context holds the name of the active application context. The name of the attribute is arbitrary, but it is specified in the ADD_POLICY_CONTEXT procedure. The value returned from the driving context attribute defines the driving context of the policy. The following steps can be performed in any order. Creating a Context Create a namespace for the driving context and associate it with a trusted package. For example: CREATE CONTEXT app_driver USING secure.apps_cxt_pkg; SECURE.APPS_CXT_PKG

Making the Context a Driving Context
Associate the driving context with a table: dbms_rls.add_policy_context( object_schema =>'OE', object_name => 'ORDERS' , namespace => 'APP_DRIVER', attribute => 'ACTIVE_APP') APP_ DRIVER Orders Making the Context a Driving Context Associating the Driving Context with a Table The ADD_POLICY_CONTEXT procedure in the DBMS_RLS package makes a context a driving application context. The driving context enforces the policies. It is the driving context that determines which application is running. When using this procedure, consider the following guidelines: The driving context can be local or accessed globally. If the driving context is NULL, policies from all policy groups are used. There must be at least one driving context defined for each object that has FGAC policies; otherwise, all policies for the object are executed. Adding multiple context to the same object causes policies from multiple policy groups to be enforced. Define the driving context for the ORDERS table: DBMS_RLS.ADD_POLICY_CONTEXT ('OE', 'ORDERS' , 'APP_DRIVER', 'ACTIVE_APP');

Creating a Policy Group
Create the OE group: Create the AC group: dbms_rls.create_policy_group( object_schema =>'OE', object_name => 'ORDERS', policy_group => 'OE_GRP' ); dbms_rls.create_policy_group ( 'OE', 'ORDERS', 'AC_GRP' ); Creating a Policy Group Each policy group must have a unique name for each table. No table can have two policy groups with the same name. The CREATE_POLICY_GROUP procedure of the DBMS_RLS package creates the policy group and associates it with a table or view. This example creates the OE_GRP and AC_GRP groups: DBMS_RLS.CREATE_POLICY_GROUP('OE', 'ORDERS', 'OE'); DBMS_RLS.CREATE_POLICY_GROUP('OE', 'ORDERS', 'AC'); Syntax PROCEDURE create_policy_group ( object_schema IN VARCHAR2 := NULL, object_name IN VARCHAR2 := NULL, policy_group IN VARCHAR2 ); where: object_schema is the owner of the table or view that the policy group is applied to; current user is the default. object_name is the name of the table or view that the policy group is applied to. policy_name is the name of the policy group.

Adding a Policy to a Group
1. Add the OE_SECURITY policy to the OE group: 2. Add the AC_SECURITY policy to the AC group: dbms_rls.add_grouped_policy ( object_schema=>'oe', object_name=>'orders', policy_group =>'oe_grp', policy_name => 'oe_security', function_schema =>'secure', policy_function => 'oe_context'); dbms_rls.add_grouped_policy ( 'oe', 'orders', 'ac_grp', 'ac_security', 'secure', 'ac_context'); Adding a Policy to a Group When you create a policy that is part of a policy group, use the ADD_GROUPED_POLICY procedure of the DBMS_RLS package, instead of the ADD_POLICY procedure. The first step in the slide adds a policy named OE_SECURITY to the OE_GRP policy group. The SECURE.OE_CONTEXT function returns the predicate to enforce security on the OE.ORDERS table. The second step adds a policy named AC_SECURITY to the AC policy group. The SECURE.AC_CONTEXT function returns the predicate to enforce security on the OE.ORDERS table. You must also create the appropriate security functions.

Guidelines Restrict SELECT and DML with the same policy.
If there is no context, SYS_CONTEXT returns NULL. You cannot select from the table within the policy. Avoid recursive contexts. Look in the session trace file to resolve errors. Guidelines Restrict with the Same Policy If you do not restrict all DML statements, then you can get unexpected results. For example, if you restrict only the SELECT statement, the customer issues this query to count the rows in the table: SQL> SELECT COUNT(*) 2 FROM oe.orders 3 GROUP BY customer_id; COUNT(*) 1 However, if the customer updates the table, he or she can access all the rows in the table, as in the following: SQL> UPDATE oe.orders 2 SET sales_rep_id = 152; 107 rows updated. If you apply different policies or predicates for different statement types on the same user and table, then be aware of this implication.

Performance For best performance:
Consider indexing the column in the predicate Do not use subqueries in the predicate Do not use literals in the predicate Use STATIC_POLICY=TRUE when possible Use DBMS_RLS.STATIC_POLICY or SHARED_STATIC_POLICY when possible Performance Index the Column in the Predicate Because the columns used in the predicate are used to access the table, you may be able to improve query performance by indexing on these columns. Do Not Use Subqueries in the Predicate To avoid the overhead of a subquery, do not include them in the predicate. Instead, perform the query and use the result to set a context and use the context in the predicate. The correct code is as follows: Set the context value with the query: SELECT customer_id INTO v_cust_id FROM oe.customers WHERE cust_first_name || '_' || cust_last_name = SYS_CONTEXT('USERENV', 'SESSION_USER'); DBMS_SESSION.SET_CONTEXT('oe', 'cust_id', v_cust_id); From the security function, return this predicate, which uses the context: customer_id = SYS_CONTEXT('oe', 'cust_id')

Export and Import For export and import, consider the following guidelines: To restore the policies, the user must have the execute privilege on the DBMS_RLS package. If a user attempts to export a table with fine-grained access policies enabled, then only those rows that the exporter is privileged to read are exported. Only SYS or a user with the EXPORT_FULL_DATABASE role enabled can perform DIRECT path export. Export and Import Export and Import, and Fine-Grained Access Control You can export tables with fine-grained access policies enabled. When doing so, consider the following: To restore the policies, the user who imports from an export file containing such tables must have the execute privilege on the DBMS_RLS package so that the security policies of the tables can be reinstated. If a user without the right privileges attempts to export a table with fine-grained access policies enabled, only those rows that the exporter is privileged to read are exported. Only SYS, a user with the EXPORT_FULL_DATABASE role enabled, or a user who has been granted the EXEMPT ACCESS POLICY privilege can perform DIRECT path export.

Policy Views Policy views list security policies: *_POLICIES
Policy context views list driving contexts: *_POLICY_CONTEXTS Policy group views list policy groups: *_POLICY_GROUPS Dynamic performance views list active policies: V$VPD_POLICY GV$VPD_POLICY Policy Views View Names and Descriptions DBA_POLICIES: All security policies in the database ALL_POLICIES: All security policies on all tables and views accessible to the current user USER_POLICIES: All security policies for tables or views owned by the user View Columns Column Data Type Description OBJECT_OWNER VARCHAR2(30) Owner of the table or view OBJECT_NAME VARCHAR2(30) Name of the table or view POLICY_NAME VARCHAR2(30) Name of the policy PF_OWNER VARCHAR2(30) Owner of the policy function PACKAGE VARCHAR2(30) Name of the package containing the policy function FUNCTION VARCHAR2(30) Name of the policy function SEL VARCHAR2(3) If YES, policy is applied to query on the object.

Checking for Policies Applied to SQL Statements
SQL> SELECT distinct policy, predicate, sql_text FROM v$vpd_policy p, v$sql s WHERE s.child_address = p.address; POLICY PREDICATE SQL_TEXT OE_POLICY 1=1 select * from oe.orders OE_POLICY sales_rep_id = SYS_CONTEXT('hrapp', 'id') Checking for Policies Applied to SQL Statements V$VPD_POLICY contains the policies that are applied to SQL statements. To find which policy corresponds to a particular SQL statement, perform the following query: COL predicate FORMAT A60 COL policy FORMAT A15 SELECT distinct policy, predicate, sql_text FROM v$vpd_policy p, v$sql s WHERE s.child_address = p.address; This query is executed after a user lsmith (a sales representative) and the OE user accessed the ORDERS table with the following statement: SELECT count(*) FROM oe.orders; There are no group policies in effect at the time of the queries.

Describe how FGAC and the VPD work Implement FGAC or the VPD by using the DBMS_RLS package Group policies: Using the DBMS_RLS package to group policies Setting up a driving application context by using DBMS_RLS

Installing Oracle Label Security

Objectives After completing this lesson, you should be able to do the following: Describe Oracle Label Security Install Oracle Label Security Objectives This lesson is an introduction to Oracle Label Security. For more information about the implementation of Oracle Label Security, refer to the Oracle Label Security Administrator’s Guide 10g Release 1.

Access Control: Overview
Oracle provides two complementary access control models: Discretionary access control (DAC) Allows only grant and revoke Controls access on an entire object Controls access by privilege Row-level security Allows sophisticated access rules Supplements DAC Is provided by the Virtual Private Database and Oracle Label Security DAC and row-level security dictate row access. Access Control: Overview Access control defines the user’s right to read, insert, update, and delete information. Every object in the Oracle database is protected by discretionary access control (DAC). Discretionary access control: DAC provides SELECT, INSERT, UPDATE, and DELETE privileges on an object to a user. The user may be granted one or more of these privileges. The limitation of DAC is that it gives access to all of the data in a table or allows access to none of the data in the table. Note: There are more object privileges than are mentioned here, and some privileges can be used to restrict access on a column basis. Row-level security: It enables sophisticated access control rules beyond those of DAC by using data in the row. Oracle provides the Virtual Private Database (VPD) and Oracle Label Security to control row-level security. Row-level access control depends first on the basic DAC policy. DAC and row-level security together dictate the criteria, controlling whether access to a row is permitted or denied.

Discretionary Access Control
GRANT SELECT ON emp TO JOE; Joe REVOKE SELECT ON emp FROM FRED; Discretionary Access Control Access to every table in the database is controlled by DAC. In the example in the slide, Joe issues a SELECT statement against the emp table. Because Joe has received the SELECT privileges on the emp table, he sees a result returned. Because Fred’s access privilege is revoked, when he issues a SELECT statement against the emp table, he sees the error message “Table or view does not exist.” The granularity of DAC is at the object level by privilege. There are four basic privileges (SELECT, INSERT, UPDATE, and DELETE) plus several more that depend on the object type. In most databases, DAC is sufficient to handle the access control needs. If viewing certain columns is limited to certain individuals or job functions, then DAC can handle it. Place those columns in a separate table and join on a key value, or hide the columns from all but authorized users by defining a view of all but the sensitive columns. Even in situations where DAC does not meet the needs for access control, there are seldom more than a few tables that require row-level access control. If the data in a row determines who is allowed to access the row, then discretionary access control is inadequate. For these situations, row-level access control is required. Fred

Oracle Label Security SQL request Discretionary access control
Object privileges Label security policy Row-level security Oracle Label Security Oracle Label Security does not bypass DAC but supplements it. For all users making a SQL request, DAC is applied first. DAC denies access to all users without the correct privileges. After DAC is applied, the Oracle database checks whether an Oracle Label Security policy is applied. Additional predicates can easily be added to the policies to further refine access because Oracle Label Security is built on the same infrastructure as the VPD. The objects in the database can have rows that are labeled. Access to rows is restricted on the basis of Oracle Label Security authorizations. There are a few conditions under which Oracle Label Security is not enforced. It is not enforced during DIRECT path export and cannot be applied to objects in the SYS schema. Note also that the SYS user and users with the special EXEMPT_ACCESS_POLICY database privilege are exempt from both Oracle Label Security and VPD enforcement. The EXEMPT_ACCESS_POLICY privilege is a powerful database privilege and should be managed carefully.

How Sensitivity Labels Are Used
Users Top Secret Access mediation Authorizations Labels Data Data sensitivity Secret How Sensitivity Labels Are Used Specifying data sensitivity: Labels are used to specify the sensitivity of a data. These are known as data labels. Each row has a data label. In the example in the slide, the row has a label of “Secret::”. Authorizations: Labels are used to specify a user’s “security clearance” or label authorization. Each user is assigned a set of labels that indicate the range of data labels that the user is allowed to read and write. In the example, the user has a label of “Top Secret::”. Access mediation: The user label and the data labels are compared in a process known as access mediation that uses a set of algorithms supplied by Oracle Label Security. The user is allowed to view the row when his or her label dominates the data label of that row; otherwise he or she is not able to see the row.

Installing Oracle Label Security
To install Oracle Label Security, perform the following steps: 1. Use the Custom Install option of Oracle Universal Installer (OUI) to add Oracle Label Security components. 2. Use the Database Configuration Assistant (DBCA) to configure Oracle Label Security. 3. Use the OUI Client installation to add the Oracle Policy Manager tool. Installing Oracle Label Security To install Oracle Label Security, perform the following steps: 1. Use the OUI Custom Install option. Use the Custom Install option of Oracle Universal Installer (OUI) to add the Label Security option to a base installation. 2. Use the DBCA to configure Oracle Label Security. Oracle highly recommends that you use the Database Configuration Assistant (DBCA) to configure the Label Security option. This configuration creates the LBACSYS user and LBAC_DBA role, and more than 200 objects. The database must be restarted after the configuration is complete. 3. Use the OUI Client installation to add the Oracle Policy Manager tool. Oracle Policy Manager is a GUI tool that enables you to create policies and manage labels and policies from a Java-based console. This tool is installed with the Administrator option of the Oracle Database 10g Client installation.

Oracle Label Security: Features
Oracle Label Security provides: Row-level security based on the VPD technology A complete infrastructure for managing label security policies, sensitivity labels, and user security clearances Oracle Policy Manager, a graphical user interface for managing Oracle Label Security A complete command-line interface to supplement Oracle Policy Manager Integration with Oracle Identity Management starting in Oracle Database 10g Release 1 Oracle Label Security: Features Oracle Label Security is a packaged system that provides an easy-to-implement row-level security solution where access control is based on data sensitivity. Security requirements are complicated by data restrictions generated by regulatory compliance. Medical data can be viewed only by attending medical professionals and by the person whose data it is. Nuclear weapon data is restricted to persons who have the proper security clearance and compartment endorsement. Different users need to see different data depending on their jobs, positions, or roles. When this data can be separated into different tables, DAC can provide the required granularity. When the data restrictions are based on row and column values, the need for fine-grained access becomes obvious. Row-Level Security Oracle Label Security is built on the fine-grained access control technology of the VPD, which is already explained in this course. The major advantage of using Oracle Label Security, rather than building the policies, is that OLS is a complete system. It is a ready-to-use VPD. Oracle Label Security provides sophisticated functions and procedures for evaluating and comparing sensitivity labels. It provides a sophisticated infrastructure for storing and managing sensitivity labels and user security clearances.

Comparing Oracle Label Security and the VPD
The VPD provides: API for implementing row-level security by using application context and PL/SQL Oracle Label Security provides: A system evaluated under Common Criteria EAL 4 All required packages for access mediation Complete data dictionary for managing policies, sensitivity labels, and user clearances A complete user interface for managing Oracle Label Security Integration with Oracle Identity Management Comparing Oracle Label Security and the VPD The VPD provides an API for implementing row-level security by using application context. The policy procedures, the application context, and the rules for control access to the data must be created by developers. Oracle Label Security provides a complete system: Access rules: Oracle Label Security comes with predefined access rules. These rules meet the requirements of many applications without modification. These rules can be customized to meet special circumstances. Common Criteria: Oracle Label Security has been evaluated under the International Common Criteria (ISO 15408) at Evaluation Assurance Level (EAL) 4. The Common Criteria standard has superceded the DOD Orange Book standard and other European and Russian standards. Complete data dictionary: It is provided in the database to manage the aspects of Oracle Label Security. A complete user interface: Oracle Policy Manager is graphical interface that allows point and click control. The SA_* packages provide a complete command-line interface.

When to Use Oracle Label Security
VPD Uses existing user attributes Uses natural data attributes Oracle Label Security Uses created user labels Uses assigned data labels When to Use Oracle Label Security Oracle Label Security is built on the same technology as that used for the VPD. Oracle Label Security does not depend on preexisting data attributes as the basis for access control. The VPD provides row-level access control by using application context. The application context is set by using an attribute that is usually obtained from the user or derived from a user attribute. This attribute can be a customer identifier from a table in the database. The attribute of the row is then used to control which rows are accessed. An example is that customers are only allowed to access rows with their customer_id. Oracle Label Security allows users to be assigned authorization labels, and rows to be assigned labels. It can be used to control access where a relationship between data attributes and user attributes does not already exist. The Oracle Label Security access mediation ensures that a user can only access rows that the user label allows. The VPD usually depends on a “natural” relationship between a user attribute and a data attribute. If that relationship does not exist, Oracle Label Security creates a relationship by adding a label to the data and users. Only when the user label dominates the data label, the rows are accessible.

Describe the main features of Oracle Label Security Install and configure Oracle Label Security

Implementing Oracle Label Security

Objectives After completing this lesson, you should be able to implement a simple Oracle Label Security policy by: Creating policies Defining labels Setting up user authorizations Applying policies to tables

Implementing the Oracle Label Security Policy
The steps to implement an Oracle Label Security solution are: 1. Develop a strategy to understand the security problem. 2. Analyze the data levels in the application 3. Create policies. 4. Define labels. 5. Assign user authorizations. 6. Apply policies. 7. Review and document your policy decisions. Implementing the Oracle Label Security Policy 1. Develop a strategy: Talk to the right people. Identify those individuals in your organization who really understand the business-security problem. Make sure that you understand the problem before adding additional security to your application. 2. Analyze the data to be protected: Ask the following questions: Where does the sensitive data reside in the application? Who needs access to this data? Who owns the data? Who should be able to read the data? Who should be able to make updates? This analysis includes a grouping of the user community by access needs: Does that grouping follow organizational lines? Does it depend on the job function? This process is repeated for each set of data that is to be protected. 3. Create policies: Name the policies.

Analyzing the Needs Identify application tables that need Oracle Label Security: Majority of the tables do not require Oracle Label Security. Use existing tools when possible. Do not apply Oracle Label Security to everything. Identify important application queries where possible. Discretionary access control (DAC) is sufficient for most tables: Database roles Secure application roles Stored procedures and functions Analyzing the Needs Identify the application tables that need Oracle Label Security: Usually only a very few tables hold data that requires the protection provided by Oracle Label Security. Do not apply Oracle Label Security where it is not needed. Use the appropriate security technology for your problem. The built-in technologies listed below frequently meet the business-security requirements with minimal overhead. Oracle Label Security has a performance cost. Identify the the most resource-intensive application queries and tune them for use in the Oracle Label Security environment. Discretionary access control (DAC) is sufficient for most tables: DAC is always applied before the Oracle Label Security policies. DAC specifies access control privileges at the object level. Stored procedures and functions: These can be used to encapsulate objects, allowing the owner to expose only certain methods of accessing the object. This technique can provide very tight control over data integrity. Database roles and secure application roles: These have been covered in previous lessons.

Creating Policies Create the policy to contain the label information:
Policy name is FACILITY. Policy label column is FACLAB. BEGIN SA_SYSDBA.CREATE_POLICY( POLICY_NAME =>'FACILITY', COLUMN_NAME => 'FACLAB', DEFAULT_OPTIONS => 'READ_CONTROL,CHECK_CONTROL,LABEL_DEFAULT,HIDE'); END; Creating Policies The first step in setting up Oracle Label Security is to create policies. The named policy is a container for all the information that is associated with a policy: labels, tables, views, privileges, and procedures. Creating the Policy Use the CREATE_POLICY procedure to create a new Oracle Label Security policy, to define a policy-specific column name, and to specify a set of default policy options. The column is added to every table associated with the policy. The policy may be created by using Oracle Policy Manager (OPM) or with PL/SQL as follows: Syntax PROCEDURE CREATE_POLICY ( policy_name IN VARCHAR2, column_name IN VARCHAR2 DEFAULT NULL, default_options IN VARCHAR2 DEFAULT NULL); Example: EXECUTE SA_SYSDBA.CREATE_POLICY('FACILITY','FACLAB',\ 'READ_CONTROL,CHECK_CONTROL,LABEL_DEFAULT,HIDE');

Defining Labels: Overview
Labels have three parts: Level Group Compartment Each part must be defined. The label is defined on the basis of the combinations of the parts. Defining Labels: Overview Each data label can have three parts: a level, one or more compartments, and one or more groups. Every label must have a level; the compartment and group portions of the label are optional. The levels, compartments, and groups must be defined before they can be used in labels. Defining the needed levels, groups, and compartments follows the analysis of the data-security needs. Each part of the label is defined. The following slides cover: Defining levels Defining groups Defining compartments Identifying labels

Defining Levels The data level is set to SENSITIVE.
Numeric Form Long Form Short Form 400 HIGHLY_SENSITIVE HS 300 SENSITIVE S 200 CONFIDENTIAL C 100 PUBLIC P The data level is set to SENSITIVE. These levels are part of the label that is assigned to users and data. Defining Levels Every label must have a level defined, and by implication every row protected by Oracle Label Security must be assigned to a level. The following are characteristics of levels: A level is an arbitrary name, such as SENSITIVE or CLASSIFIED. Higher and lower levels are determined by the “tag” (the numeric form of the level). The numeric form can range from 0 through A user with a higher level can access lower levels. Levels have ranking determined by the numeric tag. Assume that only levels are used. A user with a label of SENSITIVE may access data with a level SENSITIVE or below. Each policy has its own set of levels.

Creating Levels BEGIN SA_COMPONENTS.CREATE_LEVEL(
POLICY_NAME =>'FACILITY', LEVEL_NUMBER => '100', SHORT_NAME => 'P', LONG_NAME => 'PUBLIC'); END; Creating Levels To define levels, the database administrator (DBA) or security administrator uses the CREATE_LEVEL procedure of the SA_COMPONENTS package or OPM. Syntax PROCEDURE CREATE_LEVEL ( policy_name IN VARCHAR2, level_num IN INTEGER, short_name IN VARCHAR2, long_name IN VARCHAR2);

Defining Groups The group is WR_FINANCE.
Numeric Form Long Form Short Form Parent 1000 WESTERN_REGION WR 1100 WR_SALES WR_SAL 1200 WR_FINANCE WR_FIN 1210 WR_ACCT_PAYABLE WR_AP The group is WR_FINANCE. The data label shows WR_FIN in the level:compartment:group group field. Defining Groups A data label can have zero or more groups assigned to it. Groups are a means of making a hierarchical assignment. Data assigned to a group can be accessed by a user belonging to that group or a parent of the group. WESTERN_REGION is the parent group to WR_FINANCE and WR_SALES. A user belonging to the WESTERN_REGION group can access data belonging to either the WR_FINANCE group or the WR_SALES group. But a user belonging to the WR_SALES group cannot access data belonging to WR_FINANCE or WESTERN_REGION. A label can include multiple groups. A user having permission on any of the groups in the data label is allowed access. The numeric form does not indicate any type of ranking. It does not indicate a parent-child relationship, or greater or less sensitivity. It only controls the display order of the short form of the group name in the label character string.

Creating Groups BEGIN SA_COMPONENTS.CREATE_GROUP(
POLICY_NAME =>'FACILITY', GROUP_NUMBER => '1000', SHORT_NAME => 'WR_SAL', LONG_NAME => 'WR_SALES', PARENT_NAME => 'WR'); END; Creating Groups To define groups, the DBA or security administrator uses the CREATE_GROUP procedure of the SA_COMPONENTS package or OPM. Syntax PROCEDURE CREATE_GROUP ( policy_name IN VARCHAR2, group_num IN INTEGER, short_name IN VARCHAR2, long_name IN VARCHAR2, parent_name IN VARCHAR2 DEFAULT NULL); Example: BEGIN SA_COMPONENTS.CREATE_GROUP('FACILITY',1000, 'WR','WESTERN_REGION'); SA_COMPONENTS.CREATE_GROUP('FACILITY',1200, 'WR_FIN','WR_FINANCE','WR'); SA_COMPONENTS.CREATE_GROUP('FACILITY',1210, 'WR_AP','WR_ACCT_PAYABLE','WR_FIN'); END;

Defining Compartments
Numeric Form Long Form Short Form 85 Financial FIN 65 Chemical CH 45 Operations OP Compartments are OP, CH, and FIN. The second field in the data label shows OP, CH, and FIN. Defining Compartments Compartments provide a finer granularity to the level classification. To access rows with compartments included in the data label, the user label must include the level and the compartment. The following are the characteristics of compartments: Compartments are independent classifications. A data label can have zero or more compartments assigned to it. For a user to access that row, the user authorization must first have the correct level and include all the compartments. Compartments can be used to separate the work of various projects. In the example, a data row has a label with two compartments: OP and CH. To access the row, the user must have a label with the same or higher level, and at least the two compartments (OP and CH). The numeric tags for compartments do not indicate a higher or lower classification. This tag only provides a way to order the compartment-name strings in a label. For example, FIN is not higher than OP, but in a label, OP appears before FIN: S:OP,FIN.

Creating Compartments
BEGIN SA_COMPONENTS.CREATE_COMPARTMENT( POLICY_NAME =>'FACILITY', COMP_NUMBER => '85', SHORT_NAME => 'FIN', LONG_NAME => 'Financial'); END; Creating Compartments To define compartments, the DBA or security administrator uses the CREATE_COMPARTMENT procedure of the SA_COMPONENTS package or OPM. Syntax PROCEDURE CREATE_COMPARTMENT ( policy_name IN VARCHAR2, comp_num IN INTEGER, short_name IN VARCHAR2, long_name IN VARCHAR2);

Identifying Data Labels
The administrator creates a set of data labels that are actually used from the components already defined. LEVEL:COMPARMENT:GROUP SENSITIVE:FINANCIAL,CHEMICAL:WESTERN_REGION CONFIDENTIAL:FINANCIAL:WR_SALES SENSITIVE:: HIGHLY_SENSITIVE:FINANCIAL: SENSITIVE::WESTERN_REGION Identifying Data Labels After defining label components, the administrator creates data labels by combining particular sets of levels, compartments, and groups. Out of all the possible permutations of label components, the administrator specifies those combinations that are actually used as valid data labels in the database. The maximum length of the short form of the label is 4,000 characters. The short form is used in the label_value parameter of the CREATE_LABEL procedure. When a valid data label is created, two additional things occur: The label is automatically designated as a valid data label. This functionality limits the labels that can be assigned to data. Oracle Label Security can also create valid data labels dynamically at run time, from those that are predefined in Oracle Internet Directory. Most users, however, prefer to create the labels manually to limit data-label proliferation. A numeric label tag is associated with the text string representing the label. It is this numeric label tag (not the text string) that is stored in the policy label column of the protected table. This tag must be unique across all policies in the database. It is a good practice for performance reasons to set tags for labels of higher sensitivity to a higher numeric value than tags for labels of lower sensitivity.

Creating Data Labels BEGIN SA_LABEL_ADMIN.CREATE_LABEL(
POLICY_NAME =>'FACILITY', LABEL_TAG => '201000', LABEL_VALUE => 'S::WR'); END; Creating Data Labels When the FACILITY policy is created, a role named FACILITY_DBA is also created with the EXECUTE privilege on several packages owned by LBACSYS. The DBA or a user who is assigned the <policy>_DBA role can create labels by using the CREATE_LABEL procedure in the SA_LABEL_ADMIN package or by using OPM. The <policy>_DBA role is created when the policy is created. Syntax PROCEDURE CREATE_LABEL ( policy_name IN VARCHAR2, label_tag IN INTEGER, label_value IN VARCHAR2, data_label IN BOOLEAN DEFAULT TRUE); Example: BEGIN SA_LABEL_ADMIN.CREATE_LABEL('FACILITY',1000,'P'); SA_LABEL_ADMIN.CREATE_LABEL('FACILITY',2101,'S::US'); SA_LABEL_ADMIN.CREATE_LABEL('FACILITY',3101,'HS::US'); END;

Assigning User Authorization Labels
A user is assigned: Maximum and minimum labels A default session label A row label for inserts BEGIN SA_USER_ADMIN.SET_USER_LABELS ( POLICY_NAME =>'FACILITY', USER_NAME => 'MYCO_MGR', MAX_READ_LABEL =>'S::US,EU,ASIA'); END; Assigning User Authorization Labels Users can access data only within the range of their own label authorizations. A user has: Maximum and minimum labels A set of authorized compartments A set of authorized groups (and, implicitly, authorization for any subgroups) Each user has a session label and a row label. The session label is the particular combination of levels, compartments, and groups on which a user works at any given time. The user can change the session label to any combination of components for which he or she is authorized. When a user writes data without specifying its label, a row label is assigned automatically, using the user’s session label. However, the user can set the label for the written row within certain restrictions on the components of the label that he or she specifies with the SA_SESSION.SET_ROW_LABEL procedure. The administrator specifies the user’s initial session label and an initial default row label when setting up user authorizations. These authorizations are kept in the Oracle Label Security data dictionary tables for each user. To define user authorizations, the DBA or

Access Mediation User session label Access mediation SQL request
SQL results Row data label Access Mediation The process of comparing user authorization and data label to decide what access is granted is called access mediation. User authorizations are stored in tables. When the user logs in, these tables are accessed to determine the initial session label and row label. There are two types of access mediation for protected tables: read and write. A user can read any data up to his or her maximum level. Write access is a subset of read access. A user cannot write lower than his or her minimum level. This controls the user’s ability to disseminate data by lowering its sensitivity. In addition, there are separate lists of compartments and groups for which the user is authorized; that is, for which the user has at least read access. An access flag indicates whether the user can also write to individual compartments or groups. The DBA can further customize user data access by granting policy privileges and setting policy-enforcement options.

Administering Labels Using Oracle Policy Manager, the administrator can: Define and manage labels Apply policy to tables or schemas Assign labels to users Set user label privileges Administering Labels Oracle Label Security provides administrative interfaces to define and manage the labels used in a database. You can define labels in an Oracle database by using Oracle Label Security packages or by using Oracle Policy Manager. Initially, an administrator must define the levels, compartments, and groups that compose the labels, and then he or she can define the set of valid data labels for the contents of the database. The administrator can apply a policy to individual tables in the database, or to entire application schemas. Finally, the administrator assigns to each database user the label components (and privileges, if needed) that are appropriate for the person’s job function. The administrator sets the privileges that allow data labels to be changed by certain users, if appropriate. Some sites may not allow anyone to change a label. Some customers may have specific individuals who are responsible for reviewing and assigning the appropriate labels. Users are allowed to change their session label, as well as row label, within the range of their minimum and maximum labels by using the SET_LABEL and SET_ROW_LABEL procedures of the SA_SESSION package.

Adding Labels to Data Labels are defined by the administrator.
Access mediation requires all rows to have labels. Labels are set on rows. Adding Labels to Data The components of the labels have been created. The data labels have been created and marked as valid. For access mediation to work properly, the individual rows must have a label assigned. Labels must be defined: The labels that are assigned to data rows must first be created. There are usually many more permutations of the different components of the labels than are actually used. Most sites require that the labels that are actually used are created by an administrator to control the proliferation of labels. All rows must have labels: When creating policies, the label column for existing rows is initially NULL. The NULL value does not match any label, so the data is not accessible, except by users with the FULL access privilege. Set labels by updating rows: For existing rows, a user who has full access privileges, typically the security administrator, updates the rows, setting the label column to the proper label value for that row. For new rows, users or the application supplies the label, either directly by a pick list, defaulted to the session labels, or by a policy function.

Policy-Enforcement Options
Access-control enforcement: READ_CONTROL WRITE_CONTROL Label-management enforcement: LABEL_DEFAULT LABEL_UPDATE CHECK_CONTROL Options to override enforcement: ALL_CONTROL NO_CONTROL Policy-Enforcement Options This is a brief introduction to the policy-enforcement options. For more details, see the Oracle Label Security Administrator‘’ Guide 10g Release 1. A basic policy with full enforcement would have the READ_CONTROL, WRITE_CONTROL, and LABEL_DEFAULT options enforced. The interaction of the various enforcement options should be well understood for effectively designing an Oracle Label Security system. Access-control enforcement controls read and write access to the data. The policies can be set for each type of data manipulation language (DML): READ_CONTROL enforces the policy for all queries, controlling which data rows are accessible for SELECT, UPDATE, and DELETE. If READ_CONTROL is OFF on a policy, then for any table protected by the policy, all rows are accessible to all users. WRITE_CONTROL determines the ability to insert, update, and delete data in a row. If this option is active, it enforces INSERT_CONTROL, UPDATE_CONTROL, and DELETE_CONTROL. You can apply INSERT_CONTROL, UPDATE_CONTROL, and DELETE_CONTROL separately.

Applying the Policy to a Table
Add the FACILITY policy to the LOCATIONS table. TABLE_OPTION => NULL implies that the policy default options are used. BEGIN SA_POLICY_ADMIN.APPLY_TABLE_POLICY ( POLICY_NAME => 'FACILITY', SCHEMA_NAME => 'HR', TABLE_NAME => 'LOCATIONS', TABLE_OPTIONS => NULL, LABEL_FUNCTION => NULL); END; Applying the Policy to a Table When you apply a policy to a table, the policy is automatically enabled. To disable a policy is to turn off its protections, although it is still applied to the table. To enable a policy is to turn on and enforce its protections for a particular table or schema. To remove a policy is to take it entirely away from the table or schema. Note, however, that the policy label column and labels remain in the table unless you explicitly drop them. Use the APPLY_TABLE_POLICY procedure or OPM to add the specified policy to a table. A policy label column is added to the table if it does not exist, and is set to NULL. When a policy is applied, it is automatically enabled. To change the table options, labeling function, or predicate, you must first remove the policy, and then reapply it. Syntax PROCEDURE APPLY_TABLE_POLICY ( policy_name IN VARCHAR2, schema_name IN VARCHAR2, table_name IN VARCHAR2, table_options IN VARCHAR2 DEFAULT NULL, label_function IN VARCHAR2 DEFAULT NULL, predicate IN VARCHAR2 DEFAULT NULL);

Oracle Label Security Privileges
Oracle Label Security supports these privileges that allow authorized users to bypass certain parts of the policy: READ FULL COMPACCESS SET_ACCESS_PROFILE Oracle Label Security Privileges READ Allows read access to all data protected by the policy FULL Allows full read and write access to all data protected by the policy COMPACCESS Allows a session access to data authorized by the row’s compartments, independent of the row groups SET_ACCESS_PROFILE Allows a session to change its labels and privileges to those of a different user

Example: READ Privilege
User Label Authorizations None All rows returned READ privilege Example: READ Privilege The READ privilege enables the user to bypass the Oracle Label Security policy entirely for read access to data. A user with the READ privilege can read all data protected by the policy, regardless of his or her authorizations or session label. The user does not even need to have label authorizations. However, access mediation is still enforced on the UPDATE, INSERT, and DELETE operations. A user with the READ privilege can write only to data rows for which he or she has write access, based on any label authorizations. Application Uses Data export Report generation Executive management privilege SELECT Labeled data rows

Example: FULL Privilege
User Label Authorizations Any Labeled data rows FULL privilege Example: FULL Privilege The FULL privilege has the same effect and benefits as the READ privilege, with one difference: a user with the FULL privilege can also write to all the data. The ability to write effectively bypasses all Oracle Label Security controls. Oracle discretionary access controls still protect the underlying table. For example, if a user does not have the UPDATE privilege on the underlying table and attempts to update a table directly with an UPDATE SQL statement, the statement would fail. Any DML All rows affected

Example: COMPACCESS Privilege
User Label Authorizations Compartment = OP Data label Compartment = OP, Group=Any COMPACCESS privilege Example: COMPACCESS Privilege The COMPACCESS privilege allows a session to access rows on the basis of the row’s compartments, independent of the row groups. If a row has no compartments, then access is determined by the group authorizations. However, when compartments exist, and access to them is authorized, then the group authorization is bypassed. Level authorizations are still enforced. If the row has a data label of Confidential:Operations:Western_Region and the user label is Confidential:Operations:Central_Region, then the user can access the row on the basis of the compartment. The group is ignored. Labeled data rows

Using SET_ACCESS_PROFILE
The SA_SESSION.SET_ACCESS_PROFILE function in Oracle Label Security: Allows an application session to assume a different Oracle Label Security authorization Is used when application users do not have real database accounts Note: Users who are assigned Oracle Label Security authorizations do not need to be real database users. SQL>connect appuser/mypassword SQL>execute set_access_profile(‘finance’,’team1’); Using SET_ACCESS_PROFILE The SA_SESSION.SET_ACCESS_PROFILE procedure sets the Oracle Label Security authorizations and privileges of the database session to those of the specified user. (Note that the originating user retains the PROFILE_ACCESS privilege.) The user executing the SA_SESSION.SET_ACCESS_PROFILE procedure must have the PROFILE_ACCESS privilege. Note that the database user (the session user ID) who has logged in does not change. That user assumes only the authorizations and privileges of the specified user. By contrast, the Oracle Label Security username is changed. Shared Schema Support User accounts defined in Oracle Internet Directory cannot be given individual Oracle Label Security authorizations. However, authorizations can be given to the shared schema to which the directory users are mapped. The Oracle Label Security SET_ACCESS_PROFILE function can be used programmatically to set the label authorization profile to use after a user has been authenticated and mapped to a shared schema. Oracle Label Security does not enforce a mapping between users who are given label authorizations in Oracle Label Security and actual database users.

Trusted Stored Package Units
To create a trusted stored package unit, you must: Grant the Oracle Label Security privileges to a program unit Have the special policy_DBA role Use OPM or the SA_USER_ADMIN package to grant privileges SQL> EXECUTE SA_USER_ADMIN.SET_PROG_PRIVS(- 2> POLICY_NAME=>‘HR’,- 3> SCHEMA_NAME=>’MYSCHEMA’,- 4> PROGRAM_UNIT_NAME =>’SUM_PURCHASES’,- 5> PRIVILEGE=>’READ’); Trusted Stored Package Units A trusted stored program unit is a stored procedure, function, or package that has been granted one or more Oracle Label Security privileges. Trusted stored program units are typically used to enable users to downgrade information in a controlled manner, or update data at several labels. This is the optimal way in which users can be enabled to access data beyond their authorization. To grant privileges to a stored program unit, you must have the special policy_DBA role (where policy is the name of a policy) and the EXECUTE permission on the program unit. Use either OPM or the SA_USER_ADMIN package to program unit privileges. The SA_USER_ADMIN.SET_PROG_PRIVS procedure sets policy-specific privileges for program units. In the example on the slide, the sum_purchases procedure has been granted the READ privilege. When the sum_purchases procedure is called, it executes with the READ privilege as well as the current user’s Oracle Label Security privileges. This allows the total purchases to be calculated.

Exporting with Oracle Label Security
Only rows with labels authorized for read access are exported. The HIDE property is not exported. The LBACSYS schema cannot be exported. Exporting with Oracle Label Security Only rows with labels authorized for read access are exported. To export all the data, the user must be granted the READ or FULL access. A user with the EXEMPT ACCESS POLICY privilege can also export all the data. The HIDE property is not exported. When protected tables are exported, the label columns in those tables are also exported (as numeric values). However, if a label column is hidden, it is exported as a normal, unhidden column. The LBACSYS schema cannot be exported due to the use of opaque types in Oracle Label Security. An export of the entire database (parameter FULL=Y) with Oracle Label Security installed can be performed, except that the LBACSYS schema would not be exported. One option is to maintain the policy on the production side from the beginning with scripts.

Importing with Oracle Label Security
Precreate the Oracle Label Security policies and tables. Labels and tag values must be the same. Importing with Oracle Label Security To use the import utility with Oracle Label Security, you must prepare the import database and ensure that the import user has proper authorizations. Preparing the Import Database 1. Install Oracle Label Security. 2. Create any Oracle Label Security policies that protect the data to be imported. The policies must use the same column names as in the export database. 3. Define in the import database all the label components and individual labels used in tables being imported. Tag values assigned to the policy labels in each database must be the same. Verifying Import User Authorizations To successfully import data under Oracle Label Security, the user running the import operation must be authorized for all the labels required to insert the data and labels contained in the export file. The following requirements must be met: Requirement 1: The user must have the policy_DBA role for all policies with data being imported. After each schema or table is imported, any policies from the export database are reapplied to the imported objects. Requirement 2: The user must have the ability to write all rows that have been exported.

Performance Tips Analyze the LBACSYS schema.
Apply a bitmap index on the policy label column. Plan a label tag strategy. Partition on the basis of the label. Allow time to tune your application after applying Oracle Label Security. Performance Tips Analyzing the LBACSYS schema Run the DBMS_STATS.GATHER_SCHEMA_STATS procedure on the LBACSYS schema, so that the cost-based optimizer can improve execution plans on queries. Having the statistic for the Oracle Label Security data dictionary tables improves Oracle Label Security performance. Indexing the Policy Label Column Create a bitmap index on the policy label column on the basis of the number of distinct values. Planning a Label Tag Strategy For optimal performance, you can plan a strategy for assigning values to label tags. In general, it is best to assign higher numeric values to labels with higher sensitivity levels. Usually, many more users can see data at comparatively low levels; fewer users at higher levels can see many levels of data. With READ_CONTROL set, Oracle Label Security generates a predicate that uses a BETWEEN clause to restrict the rows to be processed by the query. If the higher-sensitivity labels do not have a higher label tag than the lower-sensitivity labels, then the query potentially examines a larger set of rows. This affects performance.

Install and configure Oracle Label Security Use Oracle Policy Manager Create and implement a simple Oracle Label Security policy

Encrypting Table Data

Objectives After completing this lesson, you should be able to do the following: Describe the encryption options available with Oracle Database 10g Generate random encryption keys Encrypt and decrypt table columns

Overview Data encryption issues Data encryption challenges
DBMS_CRYPTO package: Encrypts column data Decrypts column data Supercedes DBMS_OBFUSCATION_TOOLKIT MyCreditCardNum OKYMSEISPDTGA CUST.CREDITCARD DBMS_CRYPTO Overview Among other security technologies, the Oracle database protects data through strong, standards-based encryption. Encryption of network data is supported through Oracle Advanced Security. Encryption of column data is supported using encryption within the database. Note: This lesson addresses encryption of data that is stored in the database. It does not consider the issue of encryption of data as it passes through the network. For information about the topic of secure transmission, see the lesson titled “Network Security.” The issues and challenges of encryption are examined next. Several topics, such as access control, database administrator (DBA) access, key management, and secure transmission of keys, are considered. The DBMS_CRYPTO package is provided to perform encryption and decryption. This package supports bulk data encryption and includes procedures to encrypt and decrypt data, as well as a random number generator for generating secure encryption keys. Before Oracle Database 10g, the supplied DBMS_OFUSCATION_TOOLKIT package provided the encryption tools required by customers. The DBMS_CRYPTO package provides greater functionality. A comparison of the two packages is shown later in this lesson.

Encryption Issues: Cost
Encryption and decryption of data Accessibility Performance Management of encryption keys Secure transmission Administrative overhead Encryption Issues: Cost Although there are many good reasons to encrypt data, encryption does not solve all security problems, and may even make some problems worse. Because there is some overhead associated with the encrypting and decrypting of data, it should only be applied in the appropriate situation. While the encryption and decryption of data uses CPU resources, the management of encryption keys requires personnel resources. Cost of Managing Encryption Because the human resources (HR) records are considered sensitive information, it is tempting to think that this information should all be encrypted for better security. However, encryption does not enforce granular access control and may actually hinder data access. In the human resources example, an employee, his or her manager, and the HR clerk all need to access the employee’s record. If employee data is encrypted, then each person also must be able to access the data in unencrypted form. Therefore, the employee, the manager and the HR clerk would have to share the same encryption key to decrypt the data. Encryption would not provide any additional security in the sense of better access control, and the encryption might actually hinder the proper functioning of the application. There is the additional issue of securely transmitting and sharing the encryption keys among multiple users of a system.

Encryption Issues: Access Control
Do not use encryption instead of access control. Strong data access mechanisms are available. Encryption must not interfere with access control. Encryption Issues: Access Control Most organizations need to limit data access to those who have a need to know. For example, an HR system may limit employees to reviewing only their own employment records, while managers of employees may see the employment records of those employees working for them. HR specialists may also need to see employee records for multiple employees. These requirements are typically addressed by access control mechanisms, rather than encryption. The Oracle database provides strong, independently-evaluated access control mechanisms. A basic principle behind encrypting stored data is that it must not interfere with access control. For example, a user who has the SELECT privilege on EMP should not be limited by the encryption mechanism from seeing all the data he or she is otherwise allowed to see. Although encryption is not a substitute for effective access control, you can obtain an additional measure of security by selectively encrypting sensitive data before it is stored in the database. Credit card numbers, national identity numbers, or trade secrets are examples of sensitive information that warrant encryption. Applications for which a user is authenticated to the application, rather than to the database, may also use encryption to protect the application user password or cookie.

Encryption Issues: Access by Privileged Users
DBAs can access all data. Limit and monitor the DBA by: Using SYSOPER with limited privileges Creating junior DBA roles to limit access Auditing the actions of the DBA Running background checks on the DBAs Encrypting sensitive columns The system administrator has access to all data files. Backup media may be compromised. Encryption Issues: Access by Privileged Users DBAs Can Access All Data Some organizations are concerned that DBAs can see all the data in the database, because they typically have all privileges. These organizations feel that DBAs should merely administer the database, but should not be able to see the data that the database contains. Some organizations are also concerned about the concentration of privileges in one person, and would prefer to partition the DBA function, or enforce a two-person rule. Limiting the privileges of the DBA is discussed in the lesson titled “Internal Database Security.” The Oracle instance can audit all the actions taken by users with the SYSDBA privilege, as covered in the lesson titled “Database Auditing.” The DBA job position by its nature requires a trustworthy person. Even organizations with the most sensitive data, such as intelligence agencies, do not typically partition the DBA function. Instead, they scrutinize their DBAs closely, because it is a position of trust. If an untrustworthy user has significant privilege, he or she may pose far more significant threats to an organization than viewing unencrypted credit card numbers. Still encrypting select columns and keeping the key out of the hands of the DBA can be effective. Encryption of sensitive columns in the database has some additional benefits.

Encryption Issues: Do Not Encrypt Everything
Encrypting everything does not make data secure. Data is unavailable during key changes. Lost keys mean lost data. The management of keys becomes critical. Encryption Issues: Do Not Encrypt Everything It is a pervasive tendency to think that if encrypting some data strengthens security, then encrypting everything can make all data secure. Encryption does not make data secure if the issues of key management and transmission are not adequately addressed. It just changes the point of attack. Encryption does not address access control issues. Consider the implications of encrypting an entire production database. All data must be decrypted to be read, updated, or deleted, and the encryption must not interfere with normal access controls. Encryption is a performance-intensive operation; encrypting all data significantly affects performance. Availability is a key aspect of security. If the data is unavailable in a timely manner because it is encrypted, you have created a new security problem. Encryption keys must be changed regularly as part of a good security practice, which means that the data be inaccessible while it is being decrypted and reencrypted with a new key or keys. This also adversely affects availability. The management of encryption keys is critical. If a key is lost, the encrypted data is also lost. If a key is compromised, the data must be reencrypted. This is no different than changing the locks when an employee that has keys leaves the company.

Data Encryption: Challenges
Key management: Generation Changing Transmission Storage Encrypting special types of data: Indexed Large objects (LOBs) Data Encryption: Challenges Key Management Key management, including both generation and secure storage of cryptographic keys, is arguably one of the most important aspects of encryption. If keys are poorly chosen or stored improperly, it makes it far easier for an attacker to break the encryption. Rather than searching through all the possible keys in hopes of finding the correct decryption key, hackers can seek weaknesses in the choice of keys or the way in which keys are stored. Any cryptographic scheme can be broken if there is sufficient time. So changing the keys on a regular basis reduces the time during which it might be possible to discover the key. When a key must be known to more than one person or machine, how will the keys be protected during transmission? Encrypting Special Types of Data Indexes need to be fast to be useful. If the index is over a column that is encrypted, the index should be encrypted as well. This causes performance problems and limits the types of index lookups that are possible. Large objects have a unique set of problems due to their possible size and considerations for access methods.

Encryption Key Management: Key Generation
Keys are generated with random numbers. Use an approved random-number generator: DBMS_CRYPTO.RANDOMBYTES is based on RSA x9.31 PRNG. DBMS_RANDOM is not approved. DBMS_OBFUSCATION_TOOLKIT.GETKEY is still available. Encryption Key Management: Key Generation Key generation is an important aspect of encryption. Typically, keys are generated automatically through a random-number generator, from a cryptographic seed. Provided that the random-number generation is sufficiently strong, this can be a secure form of key generation. However, if random numbers are not well formed, but have elements of predictability, the security of the encryption may be easily compromised. To address the issue of secure cryptographic key generation, Oracle Database 10g supports secure random-number generation. The RandomBytes procedure of DBMS_CRYPTO calls a secure random-number generator based on the RSA x9.31 PRNG (Pseudo-Random Number Generator) standard, which is an approved random-number generator as per the Federal Information Processing Standard (FIPS) Annex C. Developers should not use the DBMS_RANDOM package that generates pseudo-random numbers, rather than random numbers. As RFC-1750 states, “the use of pseudo-random processes to generate secret quantities can result in pseudo-security.” The GetKey procedure of the DBMS_OBFUSCATION_TOOLKIT package is an approved FIPS-140 random-number generator and is still available for backward compatibility.

Encryption Key Management: Key Modification and Transmission
Modify periodically, like you would a password: Reduce the possibility of brute force key discovery. Reencrypt the data. Transmit the keys in a secure manner: Electronic transmission (encrypt the key) Physical transmission Encryption Key Management: Key Modification and Transmission Key Modification Prudent security practice dictates that you periodically change encryption keys. For stored data, this requires periodically decrypting the data and reencrypting it with another well-chosen key. This should be done while the data is not being accessed. This creates another challenge for applications that need to be continuously available. Consider a Web-based application encrypting credit card numbers. You do not want to make the entire application unavailable while you switch encryption keys. Key Transmission If the key is used outside the database, is used by multiple users, or is changed, then the key must be transmitted in some manner. The method depends on where and to whom the key is to be passed. If the key is to be passed over the network, it must be encrypted. Otherwise, a network snooper may grab the key as it is being transmitted. The use of network encryption, such as that provided by Oracle Advanced Security, protects all data in transit from modification or interception, including cryptographic keys. The physical transmission of the key also has the risk of losing the key copy or having it stolen.

Encryption Key Management: Storage
Store the keys by using one of the following methods: Store the key in the database. Store the key in an operating system file. Let the user manage the key. Encryption Key Management: Key Storage Key storage is one of the most important, yet difficult, aspects of encryption. To recover data encrypted with a symmetric key, the key must be accessible to the application or user seeking to decrypt data. Users must be able to access encrypted data without significant performance degradation. Authorized users must be able to retrieve the key quickly, but the key must be secure enough so that an unauthorized user cannot easily recover it. There are three basic options: Store the key in the database. Store the key in an operating system file. Let the user manage the key.

Storing the Key in the Database
The techniques for protecting keys in the database are: Store keys in a separate table. Perform additional data transformation. Wrap the PL/SQL package that performs the encryption. Use a key per row. Combine the techniques. Storing the Key in the Database Storing the keys in the database cannot protect data against the DBA accessing encrypted data. An all-privileged DBA can access tables containing encryption keys. However, it can often provide good security against the casual snooper or against someone reading the database file from a compromised operating system account. If an intruder gets access to the encryption key, he or she can decrypt and read the encrypted data. So it is important to keep the key private. Some techniques for providing additional security for encryption include the following: Never store the key in the same table as the encrypted data. Once hackers have access to the table, they can decrypt the data. Encrypt the data with a technique that performs some additional data transformation, such as perform an XOR operation on the encrypted data with another value. You can use another column, but that column must not change. For example, you can use the primary key of the row as the additional value. Wrap the PL/SQL package body that performs encryption. The wrap utility transforms the code so that the package body is not human readable. For example, to wrap a package body stored in the keymanage.sql file, perform the following: wrap iname=keymanage.sql

Storing the Key in the Operating System
Use this method to restrict DBA access to the keys: 1. Set up the file storing the keys so that the DBA does not have access to the file. 2. Retrieve the data from the database without decrypting the data. 3. Decrypt the data in the application accessing the data. The DBA must also be denied access to this application. Storing the Key in the Operating System Storing keys in a file in the operating system is another option. You can use the UTL_FILE package to make callouts from PL/SQL, which you can use to retrieve encryption keys. However, if you store keys in the operating system (OS) and make callouts to it, your data is only as secure as the protection on the OS. If you are encrypting data stored in the database because the database can be broken into from the OS, then storing the keys in the OS makes it easier for an intruder to retrieve encrypted data than if the keys were stored in the database itself. The following technique may be used to hide the data from the DBA: 1. Set up the file storing the keys so that the DBA does not have access to the file. 2. Retrieve the data from the database without decrypting the data. 3. Decrypt the data in the application accessing the data. The DBA must also be denied access to this application.

Letting the User Manage the Key
User-managed keys have these problems: Users forget the key. Users archive the key in an insecure manner. Users must use secure transmission methods, such as network encryption. Letting the User Manage the Key Having the user supply and manage the key is another technique for managing keys. However, considering the estimate that 70% of the help-desk calls are from the users who have forgotten their passwords, you can see the risks of having users manage encryption keys. In all likelihood, users either forget an encryption key or write the key down, which creates a security weakness. If a user forgets an encryption key or leaves the company, your data is unrecoverable. If you elect to have user-supplied or user-managed keys, then you must use network encryption so that the key is not passed from the client to the server unencrypted. You must also develop key archive mechanisms, which are another difficult security problems. Arguably, key archives create the security weaknesses that encryption attempts to address in the first place.

Encrypting Special Types of Data
Indexed data: Encrypt the variable used to access the data Not supported Large objects (LOBs): Use the ENCRYPT procedure of the DBMS_CRYPTO package. Encrypting Special Types of Data Even in cases where encryption can provide additional security, it is not without technical challenges, as described in the following sections. Encrypting Indexed Data Special difficulties arise in handling encrypted data that is indexed. For example, a company wants to encrypt credit card numbers. The company also wants to use credit card numbers to access sales records. So database designers want to have an index on the credit card number column for better performance. If DBMS_OBFUSCATION_TOOLKIT, DBMS_CRYPTO, or some other tool is used to encrypt data in a column, then an index on that column also contains encrypted values. This index can still be used for equality lookups, but is generally not useful for other purposes. Oracle Support recommends that you do not index encrypted data.

Comparing DBMS_CRYPTO with DBMS_OBFUSCATION_TOOLKIT
Package Feature DBMS_CRYPTO DBMS_OBFUSCATION_TOOLKIT Cryptographic algorithms DES, 3DES, AES, RC4, 3DES_2KEY DES, 3DES Database types RAW, CLOB, BLOB RAW, VARCHAR2 Block cipher chaining modes CBC, CFB, ECB, OFB CBC Cryptographic hash algorithms MD5, SHA-1, MD4 MD5 Keyed hash (MAC) algorithms HMAC_MD5, HMAC_SH1 None supported Comparing DBMS_CRYPTO with DBMS_OBFUSCATION_TOOLKIT The DBMS_CRYPTO package provides enhanced procedures and functions for encryption, decryption, hash functions, and key generation. One of the major differences is that DBMS_CRYPTO does not take the VARCHAR2 data type as an argument. The UTL_RAW package is supplied to cast data types to and from raw, and the UTL_I18N package to convert character data types to and from raw, including the conversions required for character sets. The following is the rest of the comparison table: Package Feature DBMS_CRYPTO DBMS_OBFUSCATION_TOOLKIT Padding forms PKCS5, zeroes None supported Cryptographic RAW, NUMBER, RAW, VARCHAR2 pseudo-random number BINARY_INTEGER generator DBMS_CRYPTO is intended to replace the obfuscation toolkit because it is easier to use and it supports a range of algorithms, accommodating both new and existing systems. Although 3DES_2KEY and MD4 are provided for backward compatibility, you achieve better security by using 3DES, AES, MD5, or SHA-1. Thus 3DES_2KEY and MD4 are not recommended.

DBMS_CRYPTO Package Functionality:
Random-number generation for encryption keys Encryption and decryption by using various algorithms Multiple cipher block chaining modes Multiple cryptographic hash algorithms Multiple padding forms Procedures and functions in the package include: RANDOMBYTES creates random keys. ENCRYPT to encrypt columns or LOBs DECRYPT to decrypt columns or LOBs HASH applies a hash algorithm to data. DBMS_CRYPTO Functionality DBMS_CRYPTO contains basic cryptographic functions and procedures. To use this package correctly and securely, a general level of security expertise is assumed. The DBMS_CRYPTO package enables encryption and decryption for common Oracle data types, including RAW and large objects (LOBs), such as images and sound. Specifically, it supports binary large objects (BLOBs) and character large objects (CLOBs). In addition, it provides globalization support for encrypting data across different database character sets. The following cryptographic algorithms are supported: Data Encryption Standard (DES), Triple DES (3DES: 2-key and 3-key) Advanced Encryption Standard (AES) MD5, MD4, and SHA-1 cryptographic hashes MD5 and SHA-1 Message Authentication Code (MAC) Block cipher modifiers are also provided with DBMS_CRYPTO. You can choose from several padding options, including PKCS (Public Key Cryptographic Standard) #5, and from four block cipher chaining modes, including Cipher Block Chaining (CBC). The DBMS_CRYPTO package is installed in the SYS schema. You can then grant package access to existing users and roles as needed.

Using ENCRYPT and DECRYPT
encrypted_raw := dbms_crypto.Encrypt ( src => raw_input, typ => dbms_crypto.DES3_CBC_PKCS5, key => raw_key, iv => NULL); decrypted_raw := dbms_ crypto.Decrypt ( encrypted_raw, dbms_crypto.DES3_CBC_PKCS5, raw_key); Using ENCRYPT and DECRYPT The simplest way to encrypt and decrypt data is by using the ENCRYPT and DECRYPT functions. The iv argument defaults to NULL. All other arguments for these routines are required. Multiple Encryption Passes You cannot execute multiple passes of encryption. The 3DES algorithm encrypts data multiple times. You cannot call the ENCRYPT function more than once to encrypt the same data. If the user tries to encrypt data more than once, the procedure raises the following error: ORA “Source data was previously encrypted” Example: The code in the slide uses functions to encrypt and decrypt the data. A full example of using the ENCRYPT and DECRYPT functions is on the following page. Notice that src, key, and returned values are all RAW data types. The developer is responsible for converting the character or number data types to and from RAW. The UTL_RAW package simplies this process. The UTL_I18N package performs similar functions with the added feature of allowing for character set conversions.

Using RANDOMBYTES Generate a key: Encrypt:
raw_key := dbms_crypto.randombytes ( number_bytes => 24); encrypted_raw := dbms_crypto.encrypt ( src => raw_input, typ => DBMS_CRYPTO.DES3_CBC_PKCS5 key => raw_key); Using RANDOMBYTES This function returns a RAW value containing a cryptographically secure pseudo-random sequence of bytes, which can be used to generate random material for encryption keys. The RANDOMBYTES function is based on RSA X9.31 PRNG (Pseudo-Random Number Generator), and it draws its entropy (seed) from the sqlnet.ora file parameter SQLNET.CRYPTO_SEED. number_bytes: It is the number of bytes returned. This parameter allows the RANDOMBYTES function to provide key values for various encryption algorithms. In the previous example, the DES algorithm requires a key at least 8-byte long. In this example, the key length for DES3 is 24. The AES algorithms can use 16-, 24-, or 32-byte key lengths. The AES keys must be exactly the correct number of bits; the DES algorithms discard extra key bits. Example: The code in the slide uses functions to produce a key and to encrypt and decrypt the data. It is taken from the example on the following page.

Enhanced Security Using the Cipher Block Modes
Initial value block Encrypted first block Encrypted next block Encrypt Encrypt Cipher Block Chaining Enhanced Security Using the Cipher Block Modes The DBMS_CRYPTO encryption procedures allow you to choose one of the four cipher block modes: CHAIN_ECB (Electronic Codebook): Encrypts each plain text block independently CHAIN_CBC (Cipher Block Chaining): Plain text is combined with the previous cipher text block with an XOR operation before it is encrypted (shown in the slide) CHAIN_CFB (Cipher-Feedback): Enables encrypting units of data smaller than the block size CHAIN_OFB (Output-Feedback): Enables running a block cipher as a synchronous stream cipher. This is similar to CFB, except that n bits of the previous output block are moved into the right-most positions of the data queue waiting to be encrypted. Cipher Block Chaining (CBC) mode is the most common and the strongest of the modes. You can further secure your data by including a random block of text with your data with an initial value block. In CBC mode, before a block of plain text is encrypted, it is combined with the previous encrypted block in an XOR operation. CBC mode enhances security because every block depends on its predecessors, which makes the breaking of the code more difficult. The block CBC is 64 bits (8 bytes) long. The disadvantage is that if any block is lost, none of the following blocks can be decrypted. First block Next block

Hash and Message Authentication Code
DBMS_CRYPTO includes both HASH and Message Authentication Code (MAC) functions. Both produce a one-way hash of an LOB or RAW. Use this hash to verify data integrity. MAC uses a secret key. Example: encrypted_raw := dbms_crypto.Mac( src => raw_input, typ => DBMS_CRYPTO.HMAC_MD5, key => raw_key); Using Hash and Message Authentication The DBMS_CRYPTO package includes two different types of one-way hash functions: the HASH function and the MAC function. Hash functions operate on an arbitrary-length input message and return a fixed-length hash value. One-way hash functions work in one direction only. It is easy to compute a hash value from an input message, but it is extremely difficult to generate an input message that hashes to a particular value. Note that hash values must be at least 128 bits in length to be considered secure. You can use hash values to verify whether data has been altered. For example, before storing data, you can run DBMS_CRYPTO.HASH against the stored data to create a hash value. When you retrieve the stored data at a later date, you can again run the hash function against it, using the same algorithm. If the second hash value is identical to the first one, then the data has not been altered. Hash values are similar to “file fingerprints” and are used to ensure data integrity. The HASH function included with DBMS_CRYPTO is a one-way hash function that you can use to generate a hash value from either the RAW or LOB data. The DBMS_CRYPTO.MAC function is also a one-way hash function, but with the addition of a secret key. It works in the same way as the DBMS_CRYPTO.HASH function, except that only someone with the key can verify the hash value.

Describe the encryption options available with Oracle Database 10g Use DBMS_CRYPTO to: Generate random encryption keys Encrypt and decrypt table columns

Oracle Net Services: Security Checklists

Objectives After completing this lesson, you should be able to do the following: Describe the items on the client, listener, and network security checklists Secure administration of the network Restrict access by IP address Encrypt network traffic Objectives This lesson describes the steps required to secure the listener and the network.

Overview: Security Checklists
The following are security checklists: Client checklist Network checklist: Secure traffic Secure administration Use firewalls Listener checklist: Limit listener privileges Monitor activity Overview: Security Checklists Client Checklist Client-computer authentication is difficult over the Internet. Most Internet services rely on user authentication. There are some steps that you can take to secure the client computer. Listener Checklist Because the listener is the gateway to the network, this topic is included here. Network Checklist Network security is enforced by protecting the network traffic from being accessed or modified. In addition to restricting physical access to the network, you must protect the access points to the network from unauthorized access. This is done by protecting the network-related software on the computers, bridges, and routers. If your data needs to be secure, then you must use encryption. Firewalls are used to prevent access to the intranet of your organization when you allow Internet access. Firewalls are covered in the appendix titled “Using Oracle Connection Manager as a Firewall.”

Client Checklist Internet access to secure data requires user authentication, rather than client-computer authentication. The options are: Bypass client-computer configuration and rely on user authentication to a middle tier. Configure the client computer: Authentication Authorization Administer client certificates. Educate users. Client Checklist Proper client-computer identification is difficult over the Internet. So most Internet services require user authentication, rather than client-computer authentication. However, if you can secure the client computer, you can configure it to use strong authentication, such as certificates. A certificate issued to the client computer authenticates anyone who uses that computer. For additional security, configure the client computer to encrypt sensitive network traffic. With Oracle Advanced Security Option, you can configure the client computer to use the secure sockets layer (SSL), strong authentication techniques, and end-to-end encryption. Educate the User In most cases, authentication requires the user to be identified, rather than the client computer. Make sure to properly educate users about the importance of security. Users can be fooled into giving out identity information, such as account names and passwords, on the phone by malefactors posing as help-desk technicians. Users should never leave open sessions unattended, write down passwords, or use easy-to-guess passwords.

Securing the Client Computer
Why the client computer cannot be secured: IP addresses can be spoofed. The client operating system (OS) is seldom secure. The client computer is seldom physically secure. When the client OS cannot be secured: User must authenticate to the database Disable REMOTE_OS_AUTHENTICATION to the database Configure the client computer to use: Certificates Encryption Checksumming Issues with Securing the Client Computer The client computer often cannot be secured. The IP address of the computer can be spoofed. Any computer can easily be set to use that address. An unattended session can allow anyone with access to the computer to assume the user’s identity. Any computer that is not physically secure can be broken into by anyone with a boot disk. Client systems that are administered by the user are vulnerable to attack because of weaknesses in the operating system or in other software loaded on the system. The user often does not have the system-administration skills that are required to secure the computer and its software. Your security is only as strong as its weakest link. A weak operating system authorization on client computers can lead to a security infraction. A breach of the client’s operating system can allow an intruder to use an identifier stored on that system to assume the identity of the user or client computer. A safe assumption is that the client computers are not secure. By using Oracle Advanced Security, you can require strong authentication of the user with biometrics, certificates, smart cards, and so on. Additional measures such as session encryption and message checksums provide additional assurances that session data is not being diverted, altered, or subject to eavesdropping.

Configuring the Browser
Browsers include the following security features: SSL encryption by using the HTTPS protocol Certificate authorization: Client Server Configuring the Browser The most popular Internet browsers include the following security features: SSL encryption and decryption is enforced by using the HTTPS protocol, which uses HTTP with SSL. Authentication of the client computer and the server is enforced by using one of the the following methods: The client computer is authenticated by storing the appropriate certificates in the browser. Most organizations and users do not use client or user certificates. The server is authenticated by setting options on the browser to validate certificates. The server authenticates to the browser and, in most cases, the user decides whether to accept the certificate. Two-way authentication requires that the client should authenticate to the server and the server should authenticate to the client. This is a secure method of assuring that the client and the server are truly the expected computers. This method requires that both have certificates.

Configuring the Client
Configure client computers to use Oracle Advanced Security features with Oracle Net Services: Native encryption SSL authentication by using certificates SSL encryption Configuring the Client Oracle Advanced Security Oracle Advanced Security Option is required in addition to Oracle Net Services to configure a client computer to use encryption or certificates. Client computers and servers can be configured for Oracle Advanced Security by using Oracle Net Manager. Oracle Advanced Security enables the following features: Native Encryption Native encryption does not require certificates and provides end-to-end encryption rather than the point-to-point encryption provided by SSL encryption SSL Authentication Using Certificates SSL authentication requires a certificate for each user or each computer. Unless the computer is physically secure, the application allows anyone to access the database from an authorized computer; a certificate for a client computer is not recommended. SSL Encryption SSL encryption provides encryption between two computers. It is not an end-to-end solution. SSL encryption requires the use of certificates.

Using Certificates Considerations when using certificates for authentication: Distinguished name and issuer uniquely identify the user. Test for expiring certificates. Use certificate reissues to update certificate information. Audit certificate revocations. Using Certificates Distinguished Name and Issuer Uniquely Identify the User The combination of issuer and distinguished name (DN) is used as identification; there must be no chance of duplication. Consider the possibility of duplicates even if you expect to use the certificate only within an intranet, because you may later decide to outsource services. If you find duplicates, the certificate must be reissued with a different DN. Note that authentication based on the public key has some consequences, because you would have to revoke it if the private key were compromised or lost. Test for Expiring Certificates In Oracle Advanced Security 10g, you now have the option to configure checking of certificate revocation status for both the client and the server. Certificate revocation status is checked against certificate revocation lists (CRLs), which are located in file system directories or Oracle Internet Directory, or downloaded from the location specified in the CRL Distribution Point (CRL DP) extension on the certificate. Applications that use certificates must include tests for expiring certificates. Certificates expire automatically, typically within one year. If expiring certificates are not included in tests by application systems that use certificates, they can become bugs. Consider the consequences of an expiring certificate on distributed transactions, replicated transactions,

Network Security: Checklist
Use a firewall. Restrict IP addresses. Encrypt network traffic. Prevent remote administration of Connection Manager (CMAN). Use network log files to monitor connections. Network Security Data access and secure transfer of data are important considerations when deploying the Oracle database. Network security is enhanced with the features that are listed in the slide.

Using a Firewall to Restrict Network Access
Database server Client computers Firewall Application Web server Firewall Using a Firewall to Restrict Network Access A firewall is a single point of control on a network. It is used to prevent unauthorized client computers from reaching the server. It acts as a filter, screening out unauthorized network users from using the intranet. It does this by enforcing access control on the basis of the contents of the packets of data that are being transmitted. It can thus protect against attacks on individual protocols or applications. Firewalls are rule based. They have a list of rules that define which client computers can connect and which cannot. They can compare the client computer’s host name or IP name with the rules, and either grant the client computer access or not. A firewall protects the perimeter. It cannot protect from insider threats. Many organizations partition their networks with departmental firewalls to further limit privileges. For more information about using firewalls, see the appendix titled “Using Oracle Connection Manager as a Firewall.”

Restricting Network IP Addresses: Valid Node Checking
Set the following SQLNET.ORA parameters: Turn on the feature: Deny access from these nodes: Allow access from these nodes: tcp.validnode_checking = YES tcp.excluded_nodes = tcp.invited_nodes = ( , ) Restricting Network IP Addresses: Valid Node Checking You can use the Oracle Net “valid node checking” security feature to allow or deny access to the Oracle server processes from network client computers with specified IP addresses. By restricting client-computer IP addresses from making connections to the Oracle instance, you can limit access to the database. The listener is responsible for making this check. If the listener is not used to make the connection, this check is not enforced. To use this feature, set the following SQLNET.ORA parameters: TCP.VALIDNODE_CHECKING: If this field is YES, Oracle Net Services checks the TCP.EXCLUDED_NODES and TCP.VALIDNODE_CHECKING parameters to determine which client computers must be allowed access to the database. The default value is NO. tcp.validnode_checking = YES TCP.EXCLUDED_NODES: Specifies which client computers that use the TCP/IP protocol are denied access to the database. It has the following format: tcp.excluded_nodes = {list of IP addresses} TCP.INVITED_NODES: Specifies which client computers that use the TCP/IP protocol are allowed access to the database. It has the following format: tcp.invited_nodes = {list of IP addresses}

Restricting Network IP Addresses: Guidelines
Network IP restrictions can help secure access to your server. Consider the following guidelines: Do not use IP restrictions as your only security. IP addresses can be spoofed. Use Connection Manager to limit access by node. Limit access by protocol. Protect dispatcher ports. IP restrictions do not prevent connections to the dispatcher. Restricting Network IP Addresses: Guidelines IP Address Spoofing Because IP addresses can be spoofed, do not use this technique as your primary method for authorizing users. Using Connection Manager to Limit Access by Node IP restrictions can be enhanced by using them in conjunction with Connection Manager (CMAN). CMAN is a rule-based firewall, allowing connections on matches of source, destination, and service. Clients can be forced to come through CMAN nodes to access the server when IP restrictions are used. See the appendix titled “Using Oracle Connection Manager as a Firewall” for instructions about configuring Connection Manager. Limiting Access by Protocol The protocols included in the LISTENER.ORA file limit which protocol can access the database. However, because most networks use the TCP/IP protocol, this restriction is not as important as it once was. Protecting Dispatcher Ports Setting the EXCLUDED_NODES parameter does not prevent connection directly to the database dispatcher. If the ports that the dispatchers are listening on are discovered, a connection to the database can be made. Port discovery is simple with tools such as nmap.

Configuring IP Restrictions with Net Manager
To start Net Manager on a UNIX or Linux system, the command is: $ netmgr To start Net Manager on Windows, use the Start menu: Start=>Programs=>Oracle-OraDB10g_home1=>Configuration and Migration Tools=>Net Manager To configure database access control, perform the following steps: 1. Start Oracle Net Manager. 2. In the navigator pane, select Local > Profile. 3. From the drop-down list in the right pane, select General. 4. Click the Access Rights tab. The window is shown in the slide. 5. Ensure that the Check TCP/IP Client Access Rights check box is selected. 6. In the two list boxes, enter either a host name or an IP address for a client computer that you want to include or exclude, using commas to delimit entries placed on the same line.

Restricting Open Ports
Limit open ports to needed applications: Open ports are network-attack opportunities. Know which ports are open on your computer. Find open ports: Oracle product installation ports in portlist.ini Listener ports in listener.ora CMAN ports by using: CMCTL -c <cman_name> SHOW SERVICES Dispatcher ports by using lsnrctl services Other ports by using netstat or nmap Restricting Open Ports It is part of the principle of least privilege to open only those ports on your computer that are being used. Open ports can give an attacker valuable information, such as the OS and version, or which services are available. It is important to know which ports on your computer are open and have a justification for each open port. Finding the open ports is not an obvious task. The netstat -a command shows all process network connections either in LISTEN or ESTABLISH mode. The ports being used by installed Oracle products are listed in the portlist.ini file in the ORACLE_HOME/install directory. The listener ports are defined in the listener.ora file in the TNS_ADMIN directory or the ORACLE_HOME/network/admin directory. The CMAN listener port is assigned in the cman.ora file, but the ports used by the gateway and administration processes are seemingly random. All the ports used by CMAN processes can be seen by using the SHOW SERVICES command in CMCTL. The dispatcher port can be seen through the lsnrctl tool with the SERVICES command if they have registered with the listener. Other ports can be checked with port scanning tools, such as nmap. Make sure to ask permission and notify proper administrators before scanning ports. Some firewall software may detect a port scan and block the scan, possibly closing ports to all traffic.

Encrypting Network Traffic
Guideline: Encrypt sensitive network traffic. Tasks: Use HTTPS when sending sensitive data between the client computer and the server. Use SSL or native encryption to encrypt Oracle Net Services traffic. Use the TCPS protocol for TCP/IP with SSL: ... (ADDRESS= (PROTOCOL=tcps) Encrypting Network Traffic Although you might want to avoid the overhead of encrypting and decrypting internal network communication, remember that 70% of security violations are from internal sources. Both SSL and Oracle Net native encryption encrypts all network traffic between a client and a server. While the SSL solution also provides authentication, it requires the use of certificates. Oracle Net native encryption provides end-to-end encryption in an n-tier environment without a certificate. Encrypting Sensitive Client-Server Communication HTTPS Use the HTTPS protocol to encrypt sensitive data passed between the client computer and the HTTP server. Encrypting Oracle Net Services Traffic Use Oracle Advanced Security to encrypt network traffic between client computers, databases, and application servers. Oracle Advanced Security is available only with the Enterprise Edition of the Oracle database. Oracle Advanced Security provides data encryption and integrity for all network protocols into the Oracle database, including Oracle Net with native encryption, Oracle Net/SSL, IIOP/SSL, and Java-based encryption for thin Java Database Connectivity (JDBC) clients. Connect Manager handles network traffic by using the native encryption.

End-to-End Encryption
We will go public on Wednesday. We will go public on Wednesday. Encrypt Decrypt Computer A Computer B End-to-End Encryption Oracle Advanced Security provides the ability to have end-to-end encryption. This option allows the encryption of all the Oracle Net packets even through Connection Manager. Encryption Techniques Oracle Advanced Security supports the following common encryption methods: DES: The U.S. Data Encryption Standard (DES) algorithm uses symmetric key cryptography. 3DES: Triple-DES Encryption encrypts message data with three passes of DES. RSA RC4: The RC4 algorithm, developed by RSA Data Security, Inc., uses a secret, randomly generated key that is unique to each session. AES: Advanced Encryption Standard (AES) is a new cryptographic algorithm that uses cipher keys with lengths of 128, 192, and 256 bits. Network encryption provides varying levels of security and performance for different types of data transfers. Longer key length provides stronger encryption and is harder to break, but uses more resources during encryption and decryption. fdh37djf246gs’b[da,\ssk

Checksumming We will go public on Wednesday. We will go public
Computer A Computer B Wedn- esday -lic on go pub- We will D C B A Checksumming Checksumming ensures the integrity of data packets. A checksum or digest is produced by applying the checksumming algorithm to all the data. The same algorithm is applied at the packet destination. If the checksum produced has a different value, then the data has been changed during transmission. To ensure the integrity of data packets during transmission, the checksumming algorithm generates a cryptographically secure message digest and includes it with each message sent across a network. Data integrity algorithms add little overhead and protect against the following attacks: Data modification Deleted packets Replay attacks Oracle Advanced Security supports common industry-standard algorithms: MD5 SHA-1 SHA-1 is slightly slower than MD5, but produces a larger message digest to make it more secure against brute-force collision and inversion attacks.

Oracle Net Services Log Files
Listener CMADMIN process listener.log <name>_cmadm_pid.log Database server CMAN listener CMGW process <name>_pid.log sqlnet.log Using Log and Trace Files You can understand and resolve network problems better through the use of Oracle Net Services log and trace files. These files keep track of the interaction between network components as errors occur. Evaluating this information helps you to diagnose and troubleshoot even the most complex network problems. These files can also be used to resolve security problems. Logging Versus Tracing Trace files contain some of the same information that is included in log files; however, the format in the log file is easier to read. The trace file is used for debugging. Logging Error Information All errors encountered in Oracle Net Services are appended to a log file. When the error message on the screen is inadequate to understand the failure, this file provides you with additional information to resolve the problem. The log file, by way of the error stack, shows the state of the software at various layers. The log file for the listener also includes audit trail information about every client connection request, as well as most listener control commands. <name>_cmgw_pid.log

Describe the items on the client, listener, and network security checklists Secure administration of the network Restrict access by IP address Encrypt network traffic

Securing the Listener

Objectives After completing this lesson, you should be able to do the following: Describe how to limit the privileges of the listener Administer the listener securely Analyze listener log files Objectives This lesson describes the steps that are required to secure the listener and the network.

Listener Security: Checklist
Restrict the privileges of the listener. Secure administration by: Protecting the listener with a password for remote administration Using SSL when administering the listener Protect against denial-of-service attacks. Monitor listener activity. Listener Security: Checklist Because the listener acts as the gateway to the network, some of these checklist items are closely related to network checklist items. For example, “Using SSL” to encrypt network traffic is on the listener checklist and is part of the network checklist. The items listed in the slide are covered in the following slides.

Restricting the Privileges of the Listener
Restrict the privileges of a separate listener process. A sample configuration is: EXTPROC_LISTENER= (DESCRIPTION= (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))) SID_LIST_EXTPROC_LISTENER= (SID_LIST= (SID_DESC= (SID_NAME=plsextproc) (ORACLE_HOME= /u1/app/oracle/product/10.1.0/db_1) (PROGRAM=extproc))) Listener Process Privileges The external procedure agent spawned by the listener and the external procedures executed by the agent inherit the operating system privileges of the listener. If the privileges of the listener are not limited, then external procedures have the ability to read or write to database files or to the Oracle server address space. Default Listener Configuration By default, the listener is configured to start external procedures. If you do not intend to use them, remove the external procedure configuration from the listener.ora file. Restricting Listener Privileges If you are using external procedures, you must restrict the privileges of the listener process. The owner of this separate listener process should not be the owner that installed Oracle software or executes the Oracle instance. The listener process should not have permission to read or write to database files or to the Oracle server address space. Also, the owner of this separate listener process should not be the ORACLE user, which is the default owner of the server executable and database files.

Use the CREATE LIBRARY Privilege Sparingly
External procedures: Are executed from a library Run with the privileges of the listener By default, the listener has the write privilege to: Database files The memory space of the instance To avoid misuse of this privilege: Use it only when needed Limit the privileges of the listener CREATE LIBRARY Privilege The CREATE LIBRARY privilege allows the user to create a library and run modules from the library. The modules in the library are called external procedures. The user can grant the EXECUTE privileges on the external procedures by creating a PL/SQL program unit for the external procedure and granting EXECUTE on the PL/SQL program unit. External procedures run with the privileges of the listener process that starts the external procedure. Avoiding Misuse of External Procedures Only administrators and trusted users should have the CREATE LIBRARY privilege. Limit the privilege of the listener by creating a separate listener for external procedures.

Password Protect the Listener
Establish a password for the Oracle listener to prevent unauthorized listener administration. From the Listener Control utility, issue the following command: LSNRCTL> CHANGE_PASSWORD Old password: lsnrc80 New password: lsnrc90 Reenter new password: lsnrc90 LSNRCTL> SET PASSWORD Password: The command completed successfully LSNRCTL> SAVE_CONFIG Password Protect the Listener In Oracle Database 10g, by default, the listener can only be administered from the node it is running on and by the process owner. A password is only useful if you want to remotely administer the listener or allow other users to manage the listener. The PASSWORDS_listener_name parameter stores an encrypted password for a listener. Note: A listener may be stopped and managed remotely, but it cannot be started remotely. Configuring Password Authentication for the Listener Use the CHANGE_PASSWORD command of the Listener Control utility or Oracle Net Manager to set or modify an encrypted password in the PASSWORDS_listener_name parameter in the LISTENER.ORA file. For example, using the default listener name of LISTENER, the PASSWORDS_listener_name parameter, with an encrypted password, might look like the following: PASSWORDS_LISTENER=(2D6C48144CF753AC) An encrypted password can be set by using either the CHANGE_PASSWORD command of the Listener Control utility or Oracle Net Manager.

Preventing Online Administration of the Listener
Listener configuration cannot be changed online. To change the configuration, you must: Make the changes in the LISTENER.ORA file Reload the configuration In the LISTENER.ORA file, enter the following: This configuration requires the administrator to have: Write privileges on the LISTENER.ORA file ADMIN_RESTRICTIONS_LISTENER=ON Preventing Online Administration of the Listener You can restrict the run-time administration of the listener by using the ADMIN_RESTRICTIONS_listener_name parameter. When this parameter is set, the listener refuses to accept the SET commands that alter its parameters. This feature provides additional security on the locally managed listener. To change any of the listener parameters, including ADMIN_RESTRICTIONS_listener_name, modify the LISTENER.ORA file and use the RELOAD command to reload the parameters. This RELOAD command enables the new changes without explicitly stopping and restarting the listener. To turn the parameter on for the default listener, enter the following LISTENER.ORA parameter: ADMIN_RESTRICTIONS_LISTENER=ON To turn the parameter on for a listener named PAY_LSNR, include the following parameter: ADMIN_RESTRICTIONS_PAY_LSNR=ON To change LISTENER.ORA, the user must have a write operating system privilege on the file. This feature is useful only with a listener without a password. Remote administration of the listener is not allowed without a password.

Administering the Listener Using TCP/IP with SSL
Use TCP/IP with SSL when administering over an insecure network. Make the TCPS protocol the first entry in the address list. Example (LISTENER.ORA file configured for SSL): LISTENER= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=tcps) (HOST = ed-pdsun1.us.oracle.com) (PORT = 8281))) ... Administering the Listener Using TCP/IP with SSL If you are administering the listener remotely over an insecure network and require maximum security, configure the listener with a secure protocol address that uses TCP/IP with the secure sockets layer (SSL) protocol. If the listener has multiple protocol addresses, ensure that TCP/IP, with the SSL protocol address, is listed first in the LISTENER.ORA file. To use TCP/IP with SSL, configure LISTENER.ORA with the PROTOCOL=TCPS parameter as shown in the slide. Note: To use SSL, Oracle Advanced Security must be installed, and you must have certificates for the server and the client. To administer the listener remotely, you must define the listener in the client computer’s TNSNAMES.ORA file. For example, to access the USER281 listener remotely, use the following configuration: user281 = (DESCRIPTION = (ADDRESS = (PROTOCOL = tcps) (HOST = ed-pdsun1.us.oracle.com) (PORT = 8281))))

INBOUND_CONNECT_TIMEOUT
Protect the listener from denial-of-service attacks with the following network parameters: SQLNET.INBOUND_CONNECT_TIMEOUT INBOUND_CONNECT_TIMEOUT_listener_name These parameters: Set the time allowed for a connection to complete authentication Log failures with source IP addresses INBOUND_CONNECT_TIMEOUT It is possible for connections without authentication to stay open indefinitely. Malicious clients can attempt to flood database servers with connect requests that consume resources. This is a possible scenario for a denial-of-service (DoS) or distributed DoS attack. To prevent this scenario, use the SQLNET.INBOUND_CONNECT_TIMEOUT parameter in the sqlnet.ora file and the INBOUND_CONNECT_TIMEOUT_listener_name parameter in the listener.ora file. These parameters specify the time (in seconds) for a client to connect and authenticate with the database server. Without these parameters, a client connection to the database server can stay open indefinitely without authentication. If the client fails to establish a connection and complete authentication in the time specified, the database server terminates the connection. The database server logs the IP address of the client and an ORA-12170: TNS:Connect timeout occurred error message to the sqlnet.log file.

Setting Listener Logging Parameters
In the LISTENER.ORA file: LOG_DIRECTORY_listener_name LOG_FILE_listener_name With Oracle Net Manager: With the SET command in the Listener Control utility: LOG_DIRECTORY LOG_FILE Setting Listener Logging Parameters You can set the following logging parameters in the listener.ora file: LOG_DIRECTORY_listener_name is the destination directory for the log file. The default directory on UNIX is $ORACLE_HOME/network/log and on Windows is %ORACLE_HOME%\network\log. LOG_FILE_listener_name is the file name for the log file. The default name is listener.log. Setting Logging in the Listener To set the logging parameters in Oracle Net Manager, perform the following steps: 1. In the navigation pane, select the listener that you want to configure. 2. Select General Parameter in the drop-down list. 3. Click the Logging & Tracing tab. 4. Set the parameter. The directory and log file names are a single parameter. 5. To save the configuration by using the menu options, select File > Save Network Configuration.

Analyzing Listener Log Files
The listener log contains the following information: Listener log audits: Client connection request Listener Control utility commands Listener service registration events: service_register service_update service_died Listener direct hand-off information Analyzing Listener Log Files Listener Log Audit Trail The listener log file contains audit trail information that helps you analyze network usage. The following information is recorded: A client connection request A RELOAD, START, STOP, STATUS, or SERVICES command issued by the Listener Control utility The audit trail record has the following format: Timestamp * Connect Data * [Protocol] * Event * [SID|Service] * Return Code The audit trail fields have the following properties: Protocol address information and system identifier (SID) or service name information appear only when a connection is attempted. A successful connection or command returns a code of zero. A failed connection or command includes a return code that maps to an error message. When diagnosing security problems, you primarily use the listener audit records.

Listener Log Connect: Examples
24-APR :02:51 * (CONNECT_DATA=(SERVICE_NAME=orcl)(CID= (PROGRAM=sqlplus)(HOST=EDRSR3P1)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp)(HOST= ) (PORT=56688)) * establish * orcl * 0 ... 24-APR :03:05 * (CONNECT_DATA=(SERVICE_NAME=mydb)(CID= (PORT=1067)) * establish * mydb * 12514 TNS-12514: TNS:listener does not currently know of service requested in connect descriptor Connection Request: Examples Each record in the listener.log file is on a single line. An asterisk (*) is used to delimit the fields in the log record. These examples are formatted for readability. The example in the slide contains the following records: The first record shows a successful connect request. It includes the following components: The current date and time: 24-APR :02:51 The computer and user that originated the request: *(CONNECT_DATA=(SERVICE_NAME=orcl)(CID=(PROGRAM=sqlplus) (HOST=EDRSR3P1)(USER=oracle))) The destination requested: *(ADDRESS=(PROTOCOL=tcp)(HOST= ) (PORT=56688)) The type of request: * establish The service requested: * orcl The return code: * 0

Listener Log Command: Examples
1 TNSLSNR for Linux: Version ... System parameter file is ... Started with pid=2280 Listening on: ... 23-APR :52:02 * ... * status * 0 23-APR :35:48 * ... * reload * 0 No longer listening on: ... 23-APR :35:56 * ... * stop * 0 2 3 4 Listener Log Command: Examples The examples in the slide contain the following records: 1. The first record shows a successful listener startup: TNSLSNR for Linux: Version Production on 23-APR :26:41 Copyright (c) 1991, 2004, Oracle. All rights reserved. System parameter file is /u01/app/oracle/product/10.1.0/db_1/network/admin/listener.ora Log messages written to /u01/app/oracle/product/10.1.0/db_1/network/log/listener.log Trace information written to /u01/app/oracle/product/10.1.0/db_1/network/trace/listener.trc Trace level is currently 0 Started with pid=22911 Listening on: DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC))) Listening on: DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=EDRSR5P1)(PORT=1521)))

Limit the privileges of the listener Administer the listener securely Analyze listener log files

Using Oracle Connection Manager as a Firewall

Objectives After completing this lesson, you should be able to do the following: Describe how firewalls are used to restrict network access Describe the guidelines for positioning servers within firewalls Configure Oracle Connection Manager to accept or reject connection requests Configure Oracle Connection Manager to log connection events Read connection events from the Oracle Connection Manager log Background There is no single best architecture for accommodating Internet requests requiring access to corporate intranets. Instead, trade-offs must be made between two competing goals: Security of the intranet against an Internet attack Ease of access to services by both Internet and intranet clients Neither goal can be totally met because complete security means no access to services, whereas complete ease of access means that anyone is free to peruse, corrupt, or modify corporate sites. You can only try to reach a balance between these goals, whose relative priorities are often unclear.

Overview of Firewalls Filter network traffic
Deny or allow access to subnets or intranets Prevent unauthorized access Clients Application Web server Firewall Firewall Database server Firewalls To eliminate potential weak points in the network infrastructure, you may choose to pass data from one protocol to another without the complexity of decryption and reencryption. To do so securely, you must have some way to securely transfer data across network protocol boundaries. You can connect your corporate intranet to a broad public network by using the Internet. Although this capability provides enormous business advantages, it also entails risk to your data and your computer system. One way of protecting the privacy and integrity of your system is to place a firewall between the public network and your intranet. A firewall is a single point of control on a network, used to prevent unauthorized clients from reaching the server. It acts as a filter, screening out unauthorized network users from using the intranet. It does this by enforcing access control based on the contents of the packets of data being transmitted. It can thus protect against attacks on individual protocols or applications. Firewalls are rule based. They have a list of rules that define which clients can connect and which cannot. They can compare the client’s host name or IP name with the rules, and either grant the client access or not. A firewall may refer to a single physical device or more often to several network devices used together.

Network Architecture Regions
Database server Clients Exterior firewall Application Web server Interior firewall Internet DMZ Intranet Network Architecture Regions Network architecture can be divided into three regions. On one side is the Internet, on the other is the corporate intranet, and between them is the De-Militarized Zone (DMZ), which is separated from both by firewalls. The firewalls block or allow data transfers on the basis of IP address, port, protocol type, or some combination of these. The servers in the DMZ are called bastion hosts. They are well-fortified servers running initial point of contact protocols, such as HTTP or SMTP. They are set up with the expectation that outsiders will attempt to break into them. Special care is taken to ensure that break-ins are difficult. If a break-in occurs, there should be good fault containment. It should be noted that “outgoing” requests should be handled differently and have different policies than incoming requests. Thus, a reasonable policy might be to allow “outgoing” HTTP requests but no incoming HTTP requests. Architecture Benefits By following the guidelines in this lesson, this architecture provides the following benefits: Internet clients are denied access to computers on the intranet. Internet clients cannot fraudulently identify themselves as computers located in the intranet or DMZ.

Guidelines for Positioning Servers Within Firewalls
Use a firewall to restrict database access. Use a stateful exterior firewall. Allow exterior access to only specific IP and port addresses. Allow only messages from the DMZ through the interior firewall. Send outgoing messages through DMZ proxies. Disallow all other traffic types. Do not store sensitive information in the DMZ. Guidelines This section presents the guidelines for using the recommended architectures in the Internet environment. These guidelines are taken from the white paper titled “Security Best Practices” by Bruce Lowenthall. In general, allow through the exterior firewall only protocols and ports that are required and have a business justification. Incoming messages originating outside the firewall are allowed only to contact DMZ machines. The interior firewall allows only messages originating on DMZ machines to access the intranet, and often only specific servers. Outgoing messages are only allowed though proxies on the DMZ. This simplifies the firewall rules: no intranet-to-Internet traffic; traffic only from the DMZ to Internet, and only from intranet to the DMZ is allowed. Do not store information on the DMZ that is sensitive or can be written back to the information of record. Assume that the DMZ servers will be compromised at some time, and make provisions to rapidly detect the breach and to sanitize and restore DMZ hosts.

Using a Firewall to Restrict Database Access
Keep your servers behind a firewall. Limit holes through the firewall. Database server Clients Firewall Application Web server Firewall Using a Firewall to Restrict Database Access Keep the database server behind a firewall. Oracle Net (formerly known as Net8 and SQL*Net) offers support for a variety of firewalls from various vendors. Oracle partners with firewall vendors to provide Oracle Net support. Contact your firewall vendor for current information. Limiting Holes Through a Firewall A firewall blocks all traffic by default. The network administrator establishes rules to allow traffic on particular ports. If the database server is behind a firewall, do not open the Oracle listener port of 1521 to make a connection to the Internet or vice versa. Doing so will introduce a number of significant security vulnerabilities, including more port openings through the firewall, multithreaded operating system server issues, and revelation of crucial information about databases behind the firewall. Such a plethora of information and the availability of an ill-configured firewall provide an attacker ample opportunity to launch malicious attacks on the target databases.

Types of Firewalls Stateless: Stateful: Application:
Simple checking (source, destination) Allows ACK packets Stateful: Tracks connections Allows ACK to valid connections Checks TCP headers Application: Deep checking Can examine data inside the packets Firewall Types of Firewalls Firewalls can be grouped into three categories: stateless, stateful, and application firewalls. Stateless firewalls only look at the TCP header; the rules include source, destination, port, and packet state. The state of the connection is not known. This allows an outside user to probe through your firewall by sending acknowledge (ACK) packets to IP addresses inside your firewall. There is no record kept of requests or open connections for the firewall to check for valid ACK packets. Stateful firewalls are the most common. Using a table of connections, the firewall allows only ACK packets in for established connection. The firewall keeps track of the state of the connection and should allow only valid state transitions. Application firewalls require additional processing to disassemble the packet and examine the application-level information inside. Application firewalls are generally used as proxy servers in conjunction with a firewall.

Allowing Only Traffic from the DMZ Through the Interior Firewall
Clients Exterior firewall Application Web server Interior firewall Database server Internet DMZ Intranet Incoming message rules: Not from *** Only to * Incoming message rules: Only from * Only to ** Allowing Only Traffic from the DMZ Through the Interior Firewall Internet-initiated requests to the DMZ are not a problem, but no direct access to the intranet from the Internet should be allowed. All incoming messages must first be processed on the DMZ. To isolate the intranet from the Internet clients, set the interior firewall rules to allow messages through to the intranet only if they originate from servers residing on the DMZ. And, to ensure that Internet clients do not spoof DMZ or intranet addresses, do not allow incoming client messages from the Internet to use any DMZ or intranet addresses. Example: In the example in the slide, the servers have the following addresses: Servers in the DMZ have an IP address of * Servers in the intranet have an IP address of ** In the previous IP addresses, “*” indicates any digit.

Using Oracle Connection Manager as a Firewall
Configure Oracle Connection Manager to: Allow only specific protocols Allow access Deny access Analyze the Oracle Connection Manager log for connection events. Using Oracle Connection Manager as a Firewall Problem The Oracle instance creates dedicated user connections on seemingly random ports. By default, the dispatchers start on high-numbered available ports. It is very hard to predict which ports are going to be used. Because administrators need to know the ports that will be used to configure the firewall, the needed ports are most often blocked. Solution Configure Oracle Connection Manager (a proxy server) inside the firewall to accept incoming traffic on a single or a few predefined ports. Oracle Connection Manager (CMAN) then redirects the traffic to the proper listener or dispatcher ports on the database server.

Oracle Connection Manager: Overview
Resides on a separate server Functions as a proxy server Can be configured to perform: Access control filtering Session multiplexing Protocol conversion Is rule based Is used by third-party firewall vendors to allow access to Oracle instances Overview of Oracle Connection Manager Oracle Connection Manager is a software component that resides on its own computer, separate from a client or an Oracle database server. Oracle Connection Manager proxies requests destined for the database server. You can also configure Oracle Connection Manager to multiplex sessions, control access, or convert protocols. Rule-based configuration can be used to provide access control and filter client requests. When configured for session multiplexing, Oracle Connection Manager funnels multiple sessions through a single transport protocol connection to a particular destination. This enables the database server to use few connection end points for incoming requests. Oracle Connection Manager enables a client and an Oracle database server that have different networking protocols to communicate with each other. Note: You must perform a custom installation when using Oracle Universal Installer to install Oracle Connection Manager. Oracle provides a version of CMAN to partner firewall vendors who want to provide Oracle Net support in their products.

Oracle Connection Manager Processes
Listener process: Receives client connections Is used for dynamic registration Uses rules to evaluate connection and determine whether to allow access Gateway process: CMGW Forwards requests to the next relay if access is allowed Also multiplexes client connections Administrative process: CMADMIN Multithreaded process Performs administrative functions The processes are started with the Oracle Connection Manager Control utility. Oracle Connection Manager Processes Oracle Connection Manager has three components: Listener Gateway (CMGW) Administrative (CMADMIN) The listener receives client connections and evaluates against a set of rules whether to deny or allow access. If it allows access, the listener forwards a request to a gateway process, selecting the one with the fewest connections. The CMGW process, in turn, forwards the request to another Oracle Connection Manager or directly to the database server, relaying data until the connection terminates. If a connection to the server already exists, the gateway multiplexes or funnels its connections through the existing connection. CMADMIN monitors the health of the gateway processes and the listener, shutting down or starting up processes as needed. In addition, it registers the location and load of the gateway processes with the listener, and it answers requests from the Oracle Connection Manager Control utility. The processes are started with the Oracle Connection Manager Control utility.

Oracle Connection Manager Architecture
Internet clients Oracle Connection Manager server 4 Listener 3 5 1 Database server 6 CMADMIN process 2 7 CMGW process Oracle Connection Manager Architecture The slide depicts the following steps for CMAN startup and connection processing: 1. The administrative process (CMADMIN) registers with the listener. 2. The gateway process (CMGW) registers with CMADMIN. CMADMIN forwards the gateway registration and load information to the listener. 3. The PMON database instance process registers with the CMAN listener. 4. All client connection requests are handled by the listener. 5. The listener forwards the connection to the least-loaded gateway process. 6. The listener denies access to one of the clients on the basis of rules. 7. The two client connections that are allowed are multiplexed through a single network protocol connection to the database server. Intranet clients

Access Control with Oracle Connection Manager
You can control access to Oracle databases by using filtering rules. Client access is based on: Source host names or IP addresses for client Destination host names or IP addresses for servers Destination database service names Client use of Oracle Advanced Security Configure Oracle Connection Manager to: Allow only specific protocols Deny access Accept access Access Control with Oracle Connection Manager You can allow or restrict client access to a server by using filtering rules, based on the following criteria: Source host names or IP addresses for clients Destination host names or IP addresses for servers Destination database service names Client use of Oracle Advanced Security Access control filtering is specified through the CMAN_RULES parameter in the cman.ora file. The cman.ora file is located in the $ORACLE_HOME/network/admin directory on UNIX and in the %ORACLE_HOME%\network\admin directory on Windows NT. This lesson includes instructions for configuring Oracle Connection Manager to perform the following tasks: Allowing only specific protocols Denying access Accepting access

Configuring Oracle Connection Manager
Configure the cman.ora file. Configure clients with: Address of Oracle Connection Manager Address of the listener Configuring Oracle Connection Manager Configuring Oracle Connection Manager is a three-step process: 1. Configure the cman.ora file on the Oracle Connection Manager computer. This file specifies listening endpoints for the server, the route path for Oracle Connection Manager, access control rules, and Oracle Connection Manager performance parameters. 2. Configure the database instances to register with the CMAN listener. 3. Configure clients with the protocol addresses of Oracle Connection Manager and the listener. Each of these steps is addressed in detail on the next few pages.

Configuring the cman.ora File
Define the following in the cman.ora file: Listening endpoint list for the CMAN listener Access control rule list Parameter list Configuring the cman.ora File The cman.ora file is located in the $ORACLE_HOME/network/admin directory on UNIX and in %ORACLE_HOME%\network\admin on Windows NT. The cman.ora file can also be stored in the following locations: The directory specified by the TNS_ADMIN environment variable or registry value The node’s global configuration directory. For Sun Solaris, this directory is /var/opt/oracle. Windows does not have a central directory. Note: Oracle Net Manager does not support configuration of the cman.ora file, so you must edit the file manually. Listening Endpoint Specify the listening endpoint or the protocol address for the listener process by using the CMAN parameter. The following example uses the default port of 1521: CMAN=(ADDRESS=(PROTOCOL=tcp)(HOST=ed-ixsun1)(PORT=1521)) Note that the Oracle Connection Manager listener always listens on the TCP/IP protocol.

Preventing Remote Administration of Oracle Connection Manager
To prevent remote administration of Oracle Connection Manager, in the CMAN.ORA file, include: CMAN_PROFILE= (PARAMETER_LIST= (REMOTE_ADMIN=NO)) Preventing Remote Administration of Oracle Connection Manager The REMOTE_ADMIN parameter determines whether remote access to Oracle Connection Manager is allowed. The following two values are valid: YES allows access from a remote Oracle Connection Manager Control utility session to Oracle Connection Manager. NO allows access only to the local Oracle Connection Manager. This value prevents a user that is running a remote Oracle Connection Manager Control utility session access to Oracle Connection Manager. A rule must also exist allowing connections from the node where the cmctl command is issued to the cmon service.

Allowing or Denying Access
CMAN_RULES clause allows or denies access. Example: Deny access from only Example: Allow access from subnet * CMAN_RULES= (RULE=(SRC= )(DST=dlsun1) (SRV=*)(ACT=reject)) CMAN_RULES= (RULE=(SRC= /27)(DST=dlsun1) (SRV=*)(ACT=accept)) Access Control Rule List You can use the access control rule list to specify which connections are accepted, rejected, or dropped. You can specify this information by using the CMAN_RULES parameter, which filters a connection or group of connections. Syntax CMAN_RULES= (RULE_LIST= (RULE= (SRC=host) (DST=host) (SRV=service_name|sid) (ACT=accept|reject|drop)) [(RULE= ...)]) where: SRC is the source host name or IP address (in dot notation) DST is the destination server host name or IP address (in dot notation) SRV is the database service name of the Oracle database, which is one of the following: The service name from the SERVICE_NAME parameter in the initialization parameter file of an Oracle Database 8.1 or later version instance The Oracle System Identifier (ORACLE_SID) environment variable or registry value ACT: Accept, drop, or reject incoming requests with the previous characteristics.

Configuring Clients to Use CMAN
For localized management (tnsnames.ora) or directory naming: Configure the Oracle Connection Manager protocol address. Configure the service name or SID of the target database. Configuring Clients Local Naming and Directory Naming To configure a protocol address for Oracle Connection Manager, perform the following steps by using Oracle Net Manager: 1. In the navigator pane, expand Directory or Local. Select Service Naming. 2. Click the plus (+) sign on the toolbar, or select Edit > Create. This invokes the Net Service Name Wizard. 3. Enter the name in the Net Service Name field. Click Next. 4. On the Protocol Settings page, select the protocol on which Oracle Connection Manager is configured to listen. Click Next. 5. Specify the parameter information for the selected protocol. Click Next. 6. On the Service page, specify the release and enter the name of the destination database service. Click Next. Do not test the connection at this time. 7. Click Finish to save your configuration and close the Net Service Name Wizard.

Configuring Database Servers to Use CMAN
Specify a Net Service name for the CMAN listener in the tnsnames.ora file on the server: Set the REMOTE_LISTENER parameter in the database: list_cman= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp) (HOST=proxyserver1) (PORT=1521)))) ALTER SYSTEM SET REMOTE_LISTENER = list_cman Configuring Clients Configuring the database server is a two-part process that involves registering database information remotely with Oracle Connection Manager and, optionally, configuring the server for multiplexing. Registering Database Services with CMAN To enable the database server to communicate with Oracle Connection Manager, the init.ora initialization parameter file must contain a descriptor that specifies the listening address of Oracle Connection Manager. Because this address is TCP, port 1521 but not the default local listening address of TCP, port 1521, you must specify an alias, using the REMOTE_LISTENER parameter: REMOTE_LISTENER=cman_list After the alias is specified, it must be resolved with a service name entry in the tnsnames.ora file. For example, an alias for an Oracle Connection Manager listener located at proxyserver1 might look like this in the init.ora file: REMOTE_LISTENER=listener_cman The listeners_cman alias would then be resolved to the following entry in the tnsnames.ora file: list_cman= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=proxyserver1)(PORT=1521))))

Oracle Connection Manager Control Utility
The Oracle Connection Manager Control utility is used to administer Oracle Connection Manager. The types of commands that are supported are: Operational (ADMINISTER, STARTUP, SHUTDOWN) Modifier (SET, SET LOG LEVEL) Informational (SHOW, SHOW SERVICES, SHOW STATUS, SHOW RULES) Utility operational (EXIT, HELP, QUIT) Oracle Connection Manager Control Utility The Oracle Connection Manager Control utility enables you to administer Oracle Connection Manager. You can use its commands to perform basic management functions on one or more Oracle Connection Manager instances. Additionally, you can view and change parameter settings. The basic syntax for the utility is as follows: cmctl command [argument] You can also issue the cmctl command without any arguments at the operating system prompt. You can then issue the Oracle Connection Manager utility commands at the CMCTL> program prompt.

Starting and Shutting Down Oracle Connection Manager
$cmctl CMCTL> ADMINISTER -c cman_edrsr3p1 CMCTL> STARTUP $cmctl CMCTL> ADMINISTER CMCTL> SHUTDOWN Starting and Shutting Down Oracle Connection Manager Starting Oracle Connection Manager On Windows NT, Oracle Connection Manager can be started and stopped through the Control Panel as follows: 1. Click the Services icon in the Control Panel window. 2. Select the <OracleHome_Name>CMAdmin<CmanName> service, and click Start to start the CMAN instance or click Stop to shut down the CMAN instance. 3. In the Services window, click Close. On UNIX and Linux, after you have installed and configured Oracle Connection Manager, you can start it with the Oracle Connection Manager Control utility as follows: 1. Invoke the utility from the operating system prompt, and issue the ADMINISTER command: $ cmctl CMCTL>ADMINISTER local_cman Current instance is CMAN_user-sun.us.oracle.com (instance not yet started). Connections refer to (address=(protocol=tcp)(host=user-sun.us.oracle.com)(port=1630)). The command completed successfully

Additional Commands List the protocol address of Oracle Connection Manager: CMCTL> SHOW PARAMETERS Display the version, start time, and current statistics: CMCTL> SHOW STATUS Oracle Connection Manager Utility Commands The SHOW PARAMETERS command lists the protocol address of Oracle Connection Manager as in the following example: CMCTL> SHOW PARAMETERS listener_address | (address=(protocol=tcp)(host=user-sun.us.oracle.com)(port=1630)) aso_authentication_filter | ON connection_statistics | ON … password | OFF remote_admin | OFF trace_directory | /ade/user_cman_test/oracle/network/trace/ trace_level | SUPPORT trace_timestamp | OFF trace_filelen | 0 trace_fileno | 0 The command completed successfully

Monitoring Connection Events Using the CMAN Log File
The LOG_LEVEL parameter controls the type of information logged. Any level other than off logs connection events. Example of using the cman.ora parameter: Example of using the SET command in Oracle Connection Manager: CMAN_PROFILE=(PARAMETER_LIST=(LOG_LEVEL=OFF)) CMCTL> SET LOG_LEVEL SUPPORT CMAN_user-sun.us.oracle.com parameter log_level set to support The command completed successfully Monitoring Connection Events Using the CMAN Log File By setting the log level in the Connection Manager configuration file, you can enable Oracle Connection Manager to log connection events. Setting Logging cman.ora Log Parameters LOG_DIRECTORY = <path> This parameter sets the location of the log file directory. LOG_LEVEL = level The LOG_LEVEL parameter is set in the profile of the cman.ora file. It establishes the level of logging. The following four levels are supported: off for no logging user for user log information admin for administrative log information support for Oracle Support Services log information Choose off to capture a minimum amount of log information; choose support to capture a maximum amount.

Analyzing Oracle Connection Manager Log Files
Separate log files for the listener, gateway, and administrative processes. The gateway process uses the <cman_name>_cmgw_pid.log file. The administrative process uses the <cman_name>_cmadmin_pid.log file. The listener process uses the <cman_name>_pid.log file. The connection events are in the CMAN listener log file. Analyzing Oracle Connection Manager Log Files The log files generated by Oracle Connection Manager are: <cman_name>_cmgw_pid.log for the gateway process <cman_name>_cmadm_pid.log for the administrative process <cman_name>_pid.log for the listener process In the gateway process files (cman_pid.log on UNIX and cmanpid.log on Windows NT), events are reported by using event names. The reporting of events depends on the setting of the EVENT_GROUP parameter in the cman.ora file or the setting of SET EVENT with the Oracle Connection Manager Control utility command: SET EVENT event_group {on | off} . EVENT_GROUP Use the EVENT_GROUP parameter to specify which event groups are logged. Multiple events may be designated by using a comma-separated list. This parameter accepts the following values: INIT_AND_TERM—Initialization and termination MEMORY_OPS—Memory operations CONN_HDLG—Connection handling

Describe how firewalls are used to restrict network access Describe the guidelines for positioning servers within firewalls Configure Oracle Connection Manager to accept or reject connection requests Configure Oracle Connection Manager to log connection events Read connection events from the Connection Manager log

Securing SQL*Plus and iSQL*Plus

Objectives After completing this lesson, you should be able to do the following: Describe how the PRODUCT_USER_PROFILE (PUP) table is used in SQL*Plus Use the PUP table to disable commands or roles in SQL*Plus Describe how users access iSQL*Plus Disable and enable iSQL*Plus Enable DBA access to iSQL*Plus Restrict the database instances that are accessible through iSQL*Plus

Limiting Commands Available in SQL*Plus
The PRODUCT_USER_PROFILE (PUP) table: Provides product-level security Can be used to disable: SQL commands SQL*Plus commands PL/SQL blocks Database roles Contains rows indicating what commands are disabled Disables these items on a per-user basis Provides security enforced by SQL*Plus, not the database Limiting Commands Available in SQL*Plus The PRODUCT_USER_PROFILE (PUP) table can be used to provide product-level security that supplements the user-level security provided by the SQL GRANT and REVOKE commands and user roles. Although the PUP table can be used by any Oracle application, including in-house applications, this topic focuses on using the PUP table with SQL*Plus. You can use the PUP table to disable the following items: SQL commands SQL*Plus commands PL/SQL blocks Database roles You can disable the command or role by inserting the appropriate columns in the PUP table. To reenable a command, delete the row containing the restriction. These items are disabled on a per-user basis. SQL*Plus, not the Oracle instance, enforces this security. You can restrict access to the GRANT, REVOKE, and SET ROLE commands to control users’ ability to change their database privileges.

Creating the PUP Table SQL> SELECT product, 2 userid, 3 attribute,
char_value 5 FROM product_user_profile; PRODUCT USERID ATTRIBUTE CHAR_VALUE SQL*Plus HR INSERT DISABLED SQL*Plus SH ROLES HR_CLERK SQL*Plus SH SET ROLE DISABLED SQL> Creating the PUP Table Create the PUP table by running the script named PUPBLD.SQL as SYSTEM. The exact format of the file extension and the location of the file are system dependent. For Windows, the file is located in %ORACLE_HOME%\SQLPLUS\ADMIN. Example Query The query in the slide show rows that prevent the following actions in SQL*Plus: The HR user cannot perform the INSERT command. The HR_CLERK role for the SH user is disabled when SH connects. The SH user cannot execute the SET ROLE command.

Commands That Can Be Disabled
The consequences of disabling certain SQL*Plus commands are: HOST also disables your operating system’s alias for HOST, such as ! on UNIX. Disabling the SQL*Plus SET command also disables the SQL SET commands. Disabling the START command also disables the and commands. Disabling BEGIN and DECLARE does not disable the SQL*Plus EXECUTE command. Commands That Can Be Disabled You can disable the following SQL*Plus commands: COPY EXIT PASSWORD SAVE START EDIT GET QUIT SET EXECUTE HOST RUN SPOOL You can disable the following SQL commands: ALTER DELETE NOAUDIT SET ROLE ANALYZE DROP RENAME SET TRANSACTION AUDIT GRANT REVOKE TRUNCATE CONNECT INSERT SELECT UPDATE CREATE LOCK SET CONSTRAINTS You can also disable the following PL/SQL commands: BEGIN DECLARE See the slide for additional information about disabling commands.

Example: Disabling a Command
1. Prevent the HR user from executing INSERT: 2. Connect as HR and try to execute INSERT: SQL> CONNECT system/manager Connected. SQL> INSERT INTO product_user_profile 2 VALUES ('SQL*Plus', 'HR', 'INSERT', 3 NULL, NULL, 'DISABLED', NULL, NULL); 1 row created. SQL> CONNECT hr/hr Connected. SQL> INSERT INTO jobs VALUES ('C','C',0,0); SP2-0544: invalid command: insert Maintaining the PUP Table Because the SYSTEM user owns the PUP table, connect as SYSTEM when maintaining the table. Example: The example in the slide adds a row to the PUP table that prevents the HR user from executing an INSERT command. Then the HR user attempts to execute an INSERT command and receives the SP error. Removing a Restriction To allow the HR user to execute INSERT from SQL*Plus, delete the row with the restriction: SQL> CONNECT system/manager Connected. SQL> DELETE FROM product_user_profile 2 WHERE userid = 'HR' AND attribute = 'INSERT'; 1 row deleted.

Disabling a Role Disabling a role in the PUP table disables that role when the user logs in. Example: The PUP table disables the HR_CLERK role for the SH user: When SH connects, SQL*Plus issues the following command: PRODUCT USERID ATTRIBUTE CHAR_VALUE SQL*Plus SH ROLES HR_CLERK Disabling User Roles To disable a role, insert a row in the PUP table containing the following column values: PRODUCT: Contains SQL*Plus USERID: Is the username, in uppercase ATTRIBUTE: Contains the character string ROLES CHAR_VALUE: Contains the role name SQL*Plus disables the roles by issuing a SET ROLE ALL EXCEPT command. You must use only PUBLIC or % in the USERID column for roles that are granted to PUBLIC. If you try to disable a role that has not been granted to a user, none of the roles for that user are disabled. To reenable roles, delete the row containing the restriction. Disabling SET ROLE To ensure that users do not use the SET ROLE command to change their roles after login, disable the SET ROLE command. You must also disable the PL/SQL DECLARE and BEGIN commands and the SQL*Plus EXECUTE commands to prevent application users from enabling application roles through a PL/SQL block. Disabling these commands allows the SQL*Plus user only those privileges that are associated with the roles that are enabled when they started SQL*Plus. SQL> SET ROLE ALL EXCEPT HR_CLERK;

Example: Disabling a Role
Disable the HR_CLERK role from the SH user: SQL> INSERT INTO product_user_profile 2 VALUES ('SQL*Plus', 'SH', 'ROLES', NULL, NULL, 'HR_CLERK', NULL, NULL); 1 row created. As the SH user, select from HR.JOBS: SQL> CONNECT sh/sh Connected. SQL> SELECT * FROM hr.jobs; SELECT * FROM hr.jobs; * ERROR at line 1: ORA-00942: table or view does not exist Example: Disabling a Role 1. Set up the HR_CLERK role to SELECT from the HR.JOBS table: SQL> CONNECT system/manager Connected. SQL> CREATE ROLE hr_clerk; Role created. SQL> CONNECT hr/hr SQL> GRANT SELECT ON hr.jobs TO hr_clerk; Grant succeeded. 2. Grant the HR_CLERK role to the SH user: SQL> GRANT hr_clerk TO sh;

Using SET ROLE to Enable a Disabled Role
The user can enable the role by using SET ROLE: SQL> SET ROLE hr_clerk; Role set. SQL> SELECT * FROM hr.jobs 2 WHERE job_title = 'Programmer'; JOB_ID JOB_TITLE MIN_SALARY MAX_SALARY IT_PROG Programmer To prevent the user from enabling the role, use one of the following techniques: Use a role password not known by the user. Disable SET ROLE and PL/SQL for the user. Using SET ROLE to Enable a Disabled Role Even if the PUP table disables a role for the user, the user can still enable the role by using the SET ROLE command. Use one or both of the following techniques to prevent the user from enabling the disabled row: Add a row to the PUP table that prevents the user from executing the SET ROLE command and PL/SQL procedures. Assign the role a password that is not known by the user. Without the password, the user cannot enable the role. SQL> CONNECT system/manager Connected. SQL> ALTER ROLE hr_clerk IDENTIFIED BY jmo43t5; Role altered. SQL> CONNECT sh/sh SQL> SET ROLE hr_clerk; SET ROLE hr_clerk * ERROR at line 1: ORA-01979:missing or invalid password for role 'HR_CLERK'

Example: Disabling SET ROLE
As SYSTEM, disable SET ROLE: SQL> INSERT INTO product_user_profile 2 VALUES ('SQL*Plus', 'SH', 'SET ROLE', NULL, NULL, 'DISABLED', NULL, NULL); Test it: SQL> CONNECT sh/sh Connected. SQL> SET ROLE hr_clerk; SP2-0544: invalid command: set role Example: Disabling SET ROLE 1. Prevent the SH user from executing the SET ROLE command: SQL> connect system/manager Connected. SQL> INSERT INTO product_user_profile 2 VALUES ('SQL*Plus', 'SH', 'SET ROLE', NULL, NULL, 'DISABLED', NULL, NULL); 1 row created. 2. Retest the disabled role: SQL> CONNECT sh/sh SQL> SELECT * FROM hr.jobs 2 WHERE job_title = 'Programmer'; SELECT * FROM hr.jobs * ERROR at line 1: ORA-00942: table or view does not exist 3. Ensure that the SH user cannot execute the SET ROLE command: SQL> SET ROLE hr_clerk; SP2-0544: invalid command: set role

Product-User Profile: Guidelines
Users can see the PUP rows applicable to them. SQL*Plus reads PUP when the user connects. If PUP is created incorrectly, the user receives an error message while connecting. Users with the SYSDBA or SYSOPER privileges bypass the PUP table. The PUP table applies only to the local database. Product-User Profile: Guidelines Selecting from the PUP Table The SYSTEM user owns the PUP table. The SELECT privilege is granted to PUBLIC on the PUP table, which allows all users to view the restrictions applicable to themselves. SQL*Plus Reads PUP When the User Connects SQL*Plus reads the PUP table when a user logs in to SQL*Plus. Therefore, changes to the PUP table only take effect the next time the affected users log in to SQL*Plus. Errors in the PUP Table If the PUP table is created incorrectly, all users other than privileged users see a warning, when connecting to the instance, that the PUP table information is not loaded. Bypassing the PUP Table Restrictions do not apply to SYSTEM, SYS, or a user authenticating with the SYSDBA or SYSOPER privileges, because SQL*Plus does not read the PUP table for these users. PUP and Remote Databases The PUP table applies only to the local database. If accessing a remote database with a database link, the remote database cannot extract the username from the database link to determine the current user.

iSQL*Plus Is a Web-based user interface Is similar to SQL*Plus
Includes security features Browsers iSQL*Plus iSQL*Plus provides Web-based access to Oracle databases with functionality similar to SQL*Plus. iSQL*Plus Architecture The iSQL*Plus processing engine is configured in a three-tier model consisting of the following components: Client tier includes the iSQL*Plus user interface, typically a Web browser Middle tier includes the following components, which must be on the same machine: iSQL*Plus Server Oracle Net Services Oracle HTTP Server This tier coordinates interactions and resources between the client tier and the database tier. The Oracle database tier is accessed via Oracle Net Services. iSQL*Plus Security Because iSQL*Plus provides a powerful interface to the database, iSQL*Plus includes security features that enable you to configure it to meet your security needs. PDAs iSQL*Plus Oracle9i databases

Accessing iSQL*Plus Access iSQL*Plus as a normal user:
URL: By default, does not require iSQL*Plus authentication Access iSQL*Plus as a user with the SYSDBA or SYSOPER privileges: URL: Requires iSQL*Plus authentication iSQL*Plus authentication does not replace database authentication. Accessing iSQL*Plus iSQL*Plus can be accessed by using two different URLs: is used for normal database users is used for users with the SYSDBA or SYSOPER privileges. In both URLs, server_name is the name of the host machine. iSQL*Plus authentication is separate from database authentication. Whether or not users are required to be authenticated to iSQL*Plus, they still must be authenticated to the database.

iSQL*Plus Security Two areas for iSQL*Plus security and authentication are: Browser to Oracle HTTP Server Oracle HTTP Server to Oracle instance Browser to Oracle HTTP Server connections can use SSL. iSQL*Plus cannot access the middle-tier operating system. iSQL*Plus Security Two main areas are considered for security and authentication when using iSQL*Plus: 1. The HTTP protocol connection between the Web browser and the Oracle HTTP Server. 2. The Oracle Net connection between the iSQL*Plus Server and the Oracle instance. It is useful to note that in iSQL*Plus, you cannot access the middle-tier operating system to run commands such as HOST, EDIT, and SPOOL. Browser to Oracle HTTP Server In iSQL*Plus, security for the connection between the Web browser and the Oracle HTTP Server is provided by standard HTTPS, which is fully supported by Oracle. It enables secure listener connections with an Oracle-provided encryption mechanism via the secure sockets layer (SSL). For information about configuring SSL connections between iSQL*Plus and the browser, see the SQL*Plus User’s Guide and Reference Release For detailed information about implementing SSL, see the Oracle Application Server Containers for J2EE Security Guide. iSQL*Plus to Oracle Instance The Oracle Net connection between the iSQL*Plus Server and the Oracle instance provides the same security as in Oracle client/server architectures.

Disabling iSQL*Plus Disable iSQL*Plus by removing the reference to iSQL*Plus from the server.xml configuration file. Perform these steps: 1. Edit the server.xml file. 2. Comment out the line with the form: 3. Stop and restart the iSQL*Plus Application Server. To reenable iSQL*Plus: 1. Uncomment the appropriate line. 2. Restart the iSQL*Plus Application Server. <application name="isqlplus" ...> Enabling or Disabling iSQL*Plus You can edit the Application Server configuration file to disable iSQL*Plus. To disable iSQL*Plus, perform the following steps: Stop the Application Server with isqlplusctl stop. Open server.xml located in $ORACLE_HOME/oc4j/j2ee/isqplus/config. Find the application tag for iSQL*Plus. It has the form: <application name="isqlplus" ...>. Wrap it with the comment tags: . The line to change in the configuration file to disable or enable iSQL*Plus is: <application name="isqlplus" path="../applications/isqlplus.ear" auto-start="true" /> To disable:  4. Start the Application Server with isqlplusctl start.

Enabling DBA Access By default, the SYSDBA and SYSOPER privileged connections are not available. To enable these types of connections, use the OC4J user manager. Use the JAZN shell to add the IDBA user: JAZN:> adduser "iSQL*Plus DBA" IDBA oracle Enabling DBA Access By default, the SYSDBA and SYSOPER privileged connections are not available to iSQL*Plus users. To access the iSQL*Plus DBA URL, you must set up the OC4J (Oracle Application Server Containers for J2EE) user manager. You can set up OC4J to use: The XML-based provider type, jazn-data.xml The LDAP-based provider type, Oracle Internet Directory To set up the iSQL*Plus DBA URL by using the XML-based provider type, perform the following steps: Create users for the iSQL*Plus DBA URL. Grant the webDba role to users. Test iSQL*Plus DBA access. The Oracle JAAS Provider, otherwise known as JAZN (Java AuthoriZatioN), is Oracle’s implementation of Java Authentication and Authorization Service (JAAS). The Oracle JAAS Provider is referred to as JAZN in the remainder of this document. Note: For more information about JAZN, see Oracle9iAS Containers for J2EE. The next page has a full example of creating the user for DBA access.

Enabling Restricted Database Access
Limit the databases available through iSQL*Plus. Edit the web.xmlfile. Add Net Services names in the following section: where PROD and TEST are the Oracle Net Services connection identifiers. <init-param> <param-name>iSQLPlusConnectIdList</param-name> <param-value>PROD;TEST</param-value> </init-param> Enabling Restricted Database Access If you decide to limit the databases that users can access in iSQL*Plus, configure the restricted database parameter in the web.xml file. When enabled, a drop-down list of available databases is displayed in place of the Connection Identifier text field on the Login screen. This allows greater security for iSQL*Plus Servers in hosted environments. The connection identifiers are listed in the order defined in the iSQLPlusConnectIdList parameter. Connection identifiers are case insensitive, and each connection identifier listed in the argument should be identical to an alias in the tnsnames.ora file. When set, all connections made through iSQL*Plus are refused, unless the connection is to one of the databases in the restricted list.

iSQL*Plus Security: Guidelines
Database authentication is required, even without iSQL*Plus DBA authentication. SYSDBA or SYSOPER reauthentication is not required until you restart your browser. Database connection restrictions apply to iSQL*Plus and iSQL*Plus DBA. The Product User Profile restrictions apply to iSQL*Plus connections. glogin.sql is read from the middle-tier machine. No user login.sql file is read. Do not change iSQLPlusAllowUserMarkup, which prevents cross-scripting iSQL*Plus Security: Guidelines Database Authentication is Required The username and password that are used in the authentication file are independent of the Oracle database username and password. The authentication to the HTTP Server is done in addition to the authentication to the database. By adding the user with the JAZN shell command adduser, users are not only required to enter their database usernames and passwords, but they are also prompted to enter an iSQL*Plus Application Server authentication username and password. SYSDBA or SYSOPER Reauthentication After you have successfully logged in with the SYSDBA or SYSOPER privileges and authenticated with your iSQL*Plus Application Server authentication username and password, you may not be required to reauthenticate to the iSQL*Plus Application Server until you restart your browser. However, you are still required to log in with your database username and password. Product User Profile Restrictions The Product User Profile restrictions apply to iSQL*Plus connections. The PUP restrictions are applied per user, per database as for SQL*Plus.

Describe how the PRODUCT_USER_PROFILE (PUP) table is used in SQL*Plus Use the PUP table to disable commands or roles in SQL*Plus Describe how users access iSQL*Plus Disable and enable iSQL*Plus Enable DBA access to iSQL*Plus Restrict the database instances that are accessible through iSQL*Plus

Security Requirements

Similar presentations

Presentation on theme: "Security Requirements"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Security Requirements

Similar presentations

Presentation on theme: "Security Requirements"— Presentation transcript:

Similar presentations

About project

Feedback