Oracle Database 1.The Top New Features for DBAs and Developers.Oracle Database 1.Transparent Tablespace Encryption, to Access Control Lists for UTL_TCP/HTTP/SMTP.See Series TOCDefault Passwords. Mkv Adobe Media Encoder Plugin Download . Oracle Database 1. DBA_USERS_WITH_DEFPWD. Note that DBA_ is a standard prefix; it does not contain only DBA users with default passwords.) You can identify these users by issuing. Security. Oracle Database 11g delivers a rich new security functionality—from case-sensitive passwords, to Transparent Tablespace Encryption, to Access Control. And here is the output. SI_INFORMTN_SCHEMA. You can see SCOTT listed above, because his password is TIGER, the default one. Change it with. SQL> alter user scott identified by tiger. Now if you check the view. SQL> select * from dba_users_with_defpwd. You won't see SCOTT on the list anymore. It's that simple! Case- Sensitive Passwords. In Oracle Database prior to release 1. For example. SQL> conn scott/tiger. SQL> conn scott/TIGER. This arrangement presents a problem for standards such as the Payment Card Industry (PCI) Data Security Standard, which require passwords to be case sensitive. Problem solved; in Oracle Database 1. While creating the database via DBCA, you will be prompted whether you want to upgrade to the "new security standards," one of which is the case- sensitive password. If you accept, passwords will be recorded in the same case as they were created. Here is the resulting behavior, assuming you have accepted the new standard. SQL> conn scott/tiger. SQL> conn scott/TIGER. ORA- 0. 10. 17: invalid username/password; logon denied. Warning: You are no longer connected to ORACLE. Note how "tiger" and "TIGER" are treated differently. Now, some of your apps may not be passing the password in proper case right now. A typical example is a user input form: Many forms accept passwords with no case conversion being performed.However, with Oracle Database 1.If you wish, however, it is still possible to revert to case insensitivity by altering a system parameter, SEC_CASE_SENSITIVE_LOGON, as shown in the example below. . SQL> conn / as sysdba.SQL> alter system set sec_case_sensitive_logon = false.System altered. SQL> conn scott/TIGER. Connected. When you upgrade an existing Oracle 1. You can check the status of the password by querying the DBA_USERS view, especially the new column PASSWORD_VERSIONS. USERNAME PASSWORD PASSWORD. SYSTEM 1. G 1. 1G. SYS 1. G 1. 1G. MGMT_VIEW 1. G 1. 1G. The first thing you notice is that the password column is NULL, not populated with the hashed value as it is in Oracle Database 1. So what happened to the password? It's still stored in the database (in the table USER$) but it is not visible in the DBA_USERS view. When the user is created as either global or externally authenticated, the status is indicated—GLOBAL or EXTERNAL—but the hash value of the password is not displayed. Next, note the column PASSWORD_VERSIONS, which is new in Oracle Database 1. This column signifies the case sensitivity of the password. The value "1. 0G 1. G" signifies that the user was either created in 1. You can enforce, if you wish, the sensitivity of the SYSDBA password as well by entering a new parameter, ignorecase, while creating the password file as shown below. PRODB3 password=abc. In the above example the SYSDBA password will be abc. ABC1. 23 or any other variation in case. The possibility of enforcing a case- sensitive password not only makes it more difficult to crack passwords by brute force, but also enables you to meet many more compliance requirements. Even more important, you can enforce the password requirement dynamically without needing a database shutdown, which comes in handy during upgrades and debugging login issues when upgrading legacy apps. Profiles and Password Verify Function. Remember the password verification function in Oracle Database? Many of you may not be even aware of its existence, let alone use it. The function is a quick and easy way to enforce quality of database passwords—for example, they should contain a certain number of characters, should not be identical to the username, and so on. Perhaps its best feature is that it is built- in; all you have to do is turn it on. More likely than not, you didn't. In Oracle Database 1. If you examine the password verification file utlpwdmg. ORACLE_HOME/rdbms/admin, you will notice that the script creates a new password function called verify_fnction_1. At the end, the script has the following lines. ALTER PROFILE DEFAULT LIMIT. PASSWORD_LIFE_TIME 1. PASSWORD_GRACE_TIME 7. PASSWORD_REUSE_TIME UNLIMITED. PASSWORD_REUSE_MAX UNLIMITED. FAILED_LOGIN_ATTEMPTS 1. PASSWORD_LOCK_TIME 1. PASSWORD_VERIFY_FUNCTION verify_function_1. G. The script attaches the function to the profile DEFAULT, which is the default profile for all users, unless something else is explicitly assigned. This makes the authentication compliant with many regulations. All you have to do is run this script to create the 1. Improved Out- of- Box Auditing. Auditing is another common pain point. Oracle Database includes powerful auditing features that can be used for tracking user activities. Most people, fearing an I/O contention issue, do not take advantage of them. But the truth is that some auditing can be safely turned on with little risk. Examples include CREATE SESSION, which writes a record when a session starts and then updates the record when it ends. This audit has minimal impact on I/O but provides powerful benefits. In Oracle Database 1. First, the database parameter audit_trail is now set to DB by default, not NONE, as it was in previous versions. This allows you to turn on auditing on any object, statement, or privilege without recycling the database. The second change is more statements have been placed under audit by default. Here is the list. CREATE ANY TABLE. ALTER ANY TABLE. CREATE PUBLIC DATABASE LINK. CREATE ANY PROCEDURE. ALTER ANY PROCEDURE. DROP ANY PROCEDURE. GRANT ANY PRIVILEGE. CREATE ANY LIBRARY. EXEMPT ACCESS POLICY. GRANT ANY OBJECT PRIVILEGE. CREATE EXTERNAL JOB. As you can see, auditing these activities would not cause significant I/O issues, making it possible to maintain some acceptable level of auditing with minimal performance impact. These two changes create some powerful auditing capabilities out of the box. Of course, they are just database parameters and audit settings; if you want, you can turn them off easily. But if you look at the list of statements, you may actually find them worth auditing, even in development databases. You may want to fine tune them, however. For example, in data warehouses, users create and drop a lot of temporary tables so auditing CREATE/DROP TABLE might flood the audit trail.)Caution: When you upgrade to Oracle Database 1. Thus audit trails will be written to the table AUD$ in the SYSTEM tablespace, which may fill up quickly. Watch this space closely. Transparent Tablespace Encryption. Encryption is getting more and more attention these days, thanks to myriad new laws and regulations. You need to encrypt data somehow but the big question is, how? For those still on Oracle Database 1. Release 1 and previous releases, the DBMS_CRYPTO and DBMS_OBFUSCATION_TOOLKIT toolkits let you build your own encryption framework. In Oracle Database 1. . Release 2, this framework is baked in via the great Transparent Data Encryption feature.Transparent Data Encryption lets you encrypt specific columns, which is adequate for most requirements. However, performance can be an issue with this feature (or any other encryption solution for that matter): Index range scan cannot be applied to encrypted columns, which creates a major drag on performance. This is where Transparent Tablespace Encryption in Oracle Database 1. When the tablespace is declared encrypted any data on the tablespace (including transportable tablespaces, backups, and so on), not just tables individually declared as such, is encrypted. But during index scanning, the scanning occurs in memory where the data is unencrypted, therefore causing no performance impact. Excited yet? Let's see how it is done. The encryption procedure is identical to that of Transparent Data Encryption: You need to create a wallet where the master encryption key is stored. If you don't have Transparent Data Encryption set up already, you will need to create the wallet and the key. First, create the file location for the wallet; the default location is $ORACLE_BASE/admin//wallet. The wallet subdirectory does not exist by default; you need to create it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |