Summary of

Chapter

6

User Administration

and Security

السلام عليكم
يرجى مراجعة الموضوع ؟؟ هل من لينكات ام ماذا ؟؟

السلام عليكم
يرجى مراجعة الموضوع ؟؟ هل من لينكات ام ماذا ؟؟

هذا هو وبالتوفيق إن شاء الله

Chapter_06.rar

جزاك الله خيرا
ننتظر المزيد

إخواني الكرام
السلم عليكم ورحمة الله
شكرًا على متابعتكم
إليكم محتوى الملف لأن الرابط لايعمل

Chapter

6

User Administration and Security

ORACLE DATABASE 10 G:

ADMINISTRATION I EXAM OBJECTIVES COVERED IN THIS CHAPTER:

- Administering Users

- Create and manage database user accounts

- Create and manage roles.

- Grant and revoke privileges

- Control resource usage by users

- Oracle Database Security

- Apply the principle of least privilege.

- Manage default user accounts.
- Implement standard password security features.
- Control resource usage by users.


DBAs must maintain the security, integrity, performance, and availability of their databases. In this chapter, you will learn about managing database security:
1- How to manage user accounts,
2- Implement password expiration and complexity rules, and
3- Configure security policies using object, system, and role privileges.
To further enhance your ability to monitor and manage database access, you will learn
1- How to use auditing mechanisms to fine-tune your security policy,
2- Identify attempts to access areas of your database that the user is not authorized to visit, and identify intrusion attempts.
يتعين على مديري قواعد البيانات الحفاظ على أمن وسلامة وأداء وإتاحة قواعد بياناتهم. وفي هذا الفصل سوف نتعلم إدارة وتأمين قاعدة البيانات وفيه:
1- كيف تدير حسابات المستخدم.
2- تطبيق انتهاء كلمات السر وقواعد التعقيد.
3- تهيئة سياسات التأمين باستخدام امتيازات الكائنات، النظام، والدور.
ولتحسين مقدرتك على مراقبة وإدارة تشغيل قاعدة البيانات، سوف نتعلم:
1- كيف يتم استخدام آليات المراقبة لتنغيم سياسات التأمين.
2- رصد محاولات تشغيل المناطق التي ليس مصرحاً للمستخدم الوصول إليها وكذلك رصد محاولات التطفل.

Creating and Managing User Accounts

One of the most basic administrative requirements for a database is to identify the users. Each user who connects to your database should have an account. Shared accounts are difficult to troubleshoot and audit , and having them are a poor security practice.
أحد متطلبات الإدارة الأساسية لقاعدة البيانات هو تحديد المستخدمين. كل مستخدم يتصل بقاعدة البيانات يجب أن يكون له حساب. الحسابات المشتركة يكون من الصعوبة التعامل معها ومراقبتها، وامتلاكها أمر يفتقر لسياسة التأمين.
You create a new database account with the CREATE USER statement. When you create a new account, at a minimum, you must assign a unique username and authentication method. You can optionally assign additional attributes to the user account with the CREATE USER statement. To change or assign new attributes to an existing user account, use the ALTER USER statement.
عند إنشاء مستخدم جديد باستخدام جملة (CREATE USER)، فعلى الأقل يجب تخصيص اسم فريد وحيد للمستخدم وطريقة تصديق. من الممكن تخصيص خواص إضافية لحساب المستخدم مع جملة (CREATE USER) . لتغيير خواص حساب مستخدم موجود استخدم جملة (ALTER USER)

The terms user account ,account ,user , and schema are all interchangeable and refer to a database user account that owns schema objects.
المصطلحات التالية : حساب مستخدم، حساب، مستخدم، سكيما، كلها تدل على حساب مستخدم قاعدة بيانات يمتلك كائنات بالإسكيما (مخطط قاعدة البيانات)
In the following sections, you will learn how to create a new account, how to assign and change the authentication mechanism, and how to define how this account will allocate and use certain database resources.
في القسم التالي، سوف نتعلم:
1- كيف ننشئ حساباً جديداَ.
2- كيف نخصص و نغير آلية التحقق.
3- كيف سيتعامل هذا الحساب مع موارد قاعدة البيانات.

Configuring Authentication:

When you connect to an Oracle database instance, your user account must be authenticated.
Authentication involves validating the identity of the user and confirming that they have the authority to use the database.
Oracle offers three authentication methods for your user accounts:
1- Password authentication (the most common),
2- External authentication, and
3- Global authentication.
تهيئة التحقق:
عند اتصالك بقاعدة بيانات أوراكل فإن حسابك لابد له من تحقق. يتضمّن التحقّق تصديق هوية المستخدم ويؤكّد بأنّ له السلطة لاستخدام قاعدة البيانات. تقدم أوراكل ثلاثة أصناف من طرق التحقق لحسابات المستخدم:
1- تحقق باستخدام كلمة السر (و هو الأكثر شيوعاً).
2- تحقق خارجي.
3- تحقق عالمي.
We will look at each of these authentication methods in the following sections.
1- Password Authenticated Users
When a user with password authentication attempts to connect to the database, the database verifies that the username is a valid database account and that the password supplied matches that user’s password as stored in the database.
المستخدمون الذين يتم التحقق منهم باستخدام كلمة السر:
عندما يحاول مستخدم من الذين يتم التحقق منهم باستخدام كلمة السر الاتصال بقاعدة البيانات، فإن قاعدة البيانات تقوم بالتحقق من أنه حساباً صالحاً لقاعدة البيانات وأن كلمة السر التي تم استخدامها تطابق كلمة سر المستخدم المخزنة في قاعدة البيانات.
Password authenticated user accounts are the most common and are sometimes referred to as database authenticated accounts. With a password authenticated account, the database stores the encrypted password in the data dictionary.
إن حسابات المستخدمين التي يتم التحقق منها باستخدام كلمة سر تعد الأكثر شيوعا ويشار إليها أحيانا بأنها حسابات قاعدة البيانات المحققة. مع حساب محقق باستخدام كلمة سر ، تقوم قاعدة البيانات بتخزين كلمة السر المشفرة في قاموس البيانات. على سبيل المثال:
For example, to create a password authenticated user named Heima with a password of Welcome , you execute the following:
CREATE USER Heima IDENTIFIED BY welcome;
The keywords IDENTIFIED BY password (in this case, password is welcome ) tell the database that this user account is a password authenticated account.
2- Externally Authenticated Users
When an externally identified user attempts to connect to the database, the database verifies that the username is a valid database account and trusts that the operating system has performed authentication.
عندما يحاول مستخدم خارجي محدد الاتصال بقاعدة البيانات، تقوم قاعدة البيانات بالتحقق من أن اسم المستخدم هو حساب صالح بقاعدة البيانات ويثق بأن نظام التشغيل قد قام بالتحقق.
Externally authenticated user accounts do not store or validate a password in the database.
حسابات المستخدمين التي يتم التحقق منها خارجياً لا تخزن أو تصادق على كلمة سر في قاعدة البيانات.
These accounts are sometimes referred to as OPS$ (pronounced ahps dollar ) accounts, because when Oracle introduced them in Oracle 6, the account had to be prefixed with the keyword OPS$.
With all releases of the database since then, including Oracle 10g, you can configure this OS_AUTHENT_PREFIX in the initialization or SPFILE file. For example, to create an externally authenticated user named oracle , using the default OS_AUTHENT_PREFIX , you execute the following:
CREATE USER ops$oracle IDENTIFIED EXTERNALLY;
The keywords IDENTIFIED EXTERNALLY tell the database that this user account is an externally authenticated account.

Externally authenticated accounts are frequently used for administrative scripts so that a password does not have to be embedded in a human-readable script.
حسابات المستخدمين التي يتم التحقق منها خارجياً تستخدم كثيراً للنصوص الإدارية لذلك كلمة السر يجب ألا تدرج في نصوص بشرية مقروءة.
3- Globally Authenticated Users
When a globally identified user attempts to connect to the database, the database verifies that the username is valid and passes the connection information to the advanced security option for authentication. The advanced security option supports several mechanisms for authentication, including biometrics, X.509 certificates, Kerberos, and RADIUS.
عندما يحاول مستخدم عالمي محدد الاتصال بقاعدة البيانات، تقوم قاعدة البيانات بالتحقق من أن اسم المستخدم هو حساب صالح (بقاعدة البيانات) وتمرر معلومات الاتصال لاختيار التأمين المتقدم من أجل التحقق. واختيار التأمين المتقدم من أجل التحقق يتضمن القياسات الحيوية (شهادات X.509) (Kerberos, and RADIUS).
Globally authenticated user accounts do not store or validate a password in the database as a password authenticated account does. These accounts rely on authentication provide by a service supported through the advanced security option.
حسابات المستخدمين التي يتم التحقق منها عالمياً لا تخزن أو تصادق على كلمة سر في قاعدة البيانات ككلمة سر مصدقة. هذه الحسابات تعتمد على التحقّق تقدّم من قبل خدمة التي تدعم خلال خيار الأمن المتقدّم.
The syntax for creating a globally authenticated account depends on the service called, but all use the keywords IDENTIFIED GLOBALLY , which tell the database to engage the advanced security option for authentication. Here is an example:
CREATE USER spy_master IDENTIFIED GLOBALLY AS 'CN=spy_master, OU=tier2, O=security, C=US';

Assigning a Default Tablespace

Every user is assigned a default tablespace. The default tablespace for a user is that tablespace where schema objects are stored when no TABLESPACE clause is given in statements that create tables or indexes. If you execute a CREATE TABLE
statement and do not explicitly specify a tablespace, the database uses your default tablespace.
كل مستخدم يخصص له ملف جداول افتراضي. ملف الجداول الافتراضي لمستخدم هو ملف الجداول الذي يخزن فيه كائنات الاسكيما عندما لايتم إعطاء عبارة (TABLESPACE) في الجمل التي تنشئ جداول أو فهارس.
If you do not explicitly assign a default tablespace to a user at the time you create the user, the database assigns the database’s default tablespace to the new user account. Use the keywords DEFAULT TABLESPACE tablespace_name to assign a default tablespace to either a new user via a CREATE USER statement or an existing user, like this:
إذا لم تخصص صراحة ملف جداول افتراضي لمستخدم وقت إنشاء المستخدم، فإن قاعدة البيانات تخصص ملف الجداول الافتراضي لحساب المستخدم الجديد.
CREATE USER heima IDENTIFIED BY heima
DEFAULT TABLESPACE users;

Or via an ALTER USER statement:
ALTER USER heima DEFAULT TABLESPACE users;

To change the database default tablespace (the value that users inherit if no default
tablespace is provided), use the ALTER DATABASE statement, like this:
ALTER DATABASE DEFAULT TABLESPACE users;
لتغيير ملف الجداول الافتراضي لقاعدة البيانات (القيمة التي سوف يرثها المستخدمون إذا لم يتم تقديم ملف جداول) استخدم جملة (ALTER DATABASE) كالأمر السابق.
Assigning a Temporary Tablespace
Every user is assigned a temporary tablespace in which the database stores temporary segments.
كل مستخدم يخصص له ملف جداول مؤقت الذي فيه تقوم قاعدة البيانات بتخزين القطع المؤقتة.

Temporary segments are created during large sorting operations, such as:
(ORDER BY , GROUP BY, SELECT DISTINCT, MERGE JOIN, or CREATE INDEX.)
القطع المؤقتة يتم إنشائها أثناء عمليات التبويب الكبيرة مثل:

(ORDER BY , GROUP BY, SELECT DISTINCT, MERGE JOIN, or CREATE INDEX)

Temporary segments are also used when a temporary table is used. The database creates and drops temporary segments transparently to the user. Because of the transitory nature of temporary segments, you must use a dedicated tablespace of type
TEMPORARY for your user’s temporary tablespace setting.
يتم استخدام القطع المؤقتة أيضاً عند استخدام جدول مؤقت. تقوم قاعدة البيانات بإنشاء وإسقاط القطع المؤقتة بشفافية للمستخدم. بسبب الطبيعة العابرة للقطع المؤقتة فإنه يجب أن تخصص ملف جداول من النوع المؤقت لإعدادات ملف الجداول المؤقتة للمستخدم.
If you do not explicitly assign a temporary tablespace at user creation time, the database assigns the database default temporary tablespace to the new user account.
إذا لم تخصص صراحة ملف جداول مؤقت وقت إنشاء المستخدم، فإن قاعدة البيانات تقوم بتخصيص ملف الجداول الافتراضي لقاعدة البيانات لحساب المستخدم الجديد.
Use the keywords TEMPORARY TABLESPACE tablespace_name to assign a temporary tablespace either to a new user via the CREATE USER statement:
CREATE USER heima IDENTIFIED BY heima
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
Or to an existing user via an ALTER USER statement:
ALTER USER heima TEMPORARY TABLESPACE temp;
To change the database default temporary tablespace, use the ALTER DATABASE statement, like this:
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;

To avoid having to set the default and temporary tablespace for each user account that you create, change the database defaults with the ALTER DATABASE statement.
لتتجنب ضبط ملف الجداول المؤقت لكل مستخدم تقوم بإنشائه، قم بتغيير الافتراضيات باستخدام جملة (ALTER DATABASE)
Assigning a Profile to a User
In addition to default and temporary tablespaces, every user is assigned a profile. A profile serves two purposes: first, it can limit the resource usage of some resources, and second, it can enforce password-management rules.
بالإضافة إلى ملفات الجداول الافتراضية والمؤقتة، فإن كل مستخدم يتم تخصيص (profile) له.
يخدم البروفايل غرضين:
الأول: يستطيع تحديد استخدام مصادر بعض الموارد.
والثاني: يستطيع أن يفرض قواعد إدارة كلمة السر.
The default profile is appropriately named default. To explicitly assign a profile to a user, include the keywords PROFILE profile_name in the CREATE USER or ALTER USER statement.
For example, to assign the profile named resource_profile to the new user heima_1 as well as to the existing user heima, execute the following SQL:

CREATE USER heima_1 IDENTIFIED BY "heima_1.1"
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
PROFILE resource_profile;

ALTER USER heima_1
PROFILE resource_profile;

Removing a User from the Database
You use the DROP USER statement to remove a user from the database. You can optionally include the keyword CASCADE to tell the database to recursively drop all objects owned by that user.
تستخدم جملة (DROP USER) لإزالة مستخدم من قاعدة البيانات. ويمكن اختيارياً تضمين الكلمة الدليلية (CASCADE) لإخبار قاعدة البيانات أن تسقط بشكل تكراري كل الكائنات المملوكة لهذا المستخدم.
To drop both user heima and all objects he owns, execute the following:
DROP USER heima CASCADE;
لإسقاط المستخدم (heima) وكل الكائنات التي يمتلكها نفذ الأمر السابق.
Dropping a user implicitly drops any object (but not role or system) privileges in which the user was the grantor.
The data dictionary records both grantee and grantor for object privileges, but only the grantee is recorded for role and system privileges.
إسقاط مستخدم ضمنيا يسقط امتيازات أي كائن (لكن ليس دوراً أو نظاماً) كان له المستخدم مانحاً.
يقوم قاموس البيانات بتسجيل كلاً من الممنوح والمانح لامتيازات الكائن، لكن الممنوح فقط هو الذي يتم تسجيله لامتيازات الدور والنظام.

Granting and Revoking Privileges

Privileges allow a user to access database objects or execute stored programs that are owned by another user. Privileges also enable a user to perform system-level operations, such as connecting to the database, creating a table, or altering the database.
تسمح الإمتيازات للمستخدم بتشغيل كائنات قاعدة البيانات أو تنفيذ برامج مخزنة مملوكة لمستخدم آخر. كما تمكن الإمتيازات أيضاً المستخدم من أداء عمليات على مستوى النظام على سبيل المثال الاتصال بقاعدة البيانات، إنشاء جدول، أو تعديل قاعدة البيانات.
Privileges are assigned to a user, to the special user PUBLIC, or to a role with the GRANT statement and can be rescinded with the REVOKE statement.
تخصص الإمتيازات لمستخدم، لمستخدم خاص (PUBLIC) أو لدور باستخدام جملة (GRANT) ويمكن أن تلغى باستخدام جملة (REVOKE)
An Oracle 10g database has three types of privileges:
1- Object privileges
Permissions on schema objects such as tables, views, sequences, procedures, and packages. To use a schema object owned by another user, you need privileges on that object.
صلاحيات على الاسكيما مثل الجداول، (Views)، ال(sequences)، الإجراءات (procedures) و(packages). لتقوم باستخدام كائن بإسكيما مملوك لمستخدم آخر فأنت تحتاج لامتياز على هذا الكائن.
2- System privileges
Permissions on database-level operations, such as connecting to the database, creating users, altering the database, or consuming unlimited amounts of tablespace.
صلاحيات على مستوى عمليات قاعدة البيانات، مثل الاتصال بقاعدة البيانات، إنشاء مستخدمين، تعديل قاعدة البيانات، أو استخدام مقدار غير محدود من ملفات الجداول.
3- Role privileges
Object and system privileges that a user has by way of a role. Roles are tools for administering groups of privileges.
صلاحيات على الكائنات والنظام والتي يمتلكها مستخدم بطريقة الدور. تعتبر الأدوار أداة لإدارة مجموعات الصلاحيات.

We will look at each of these privileges and how to grant them in the following sections.
1- Granting Object Privileges
Object privileges bestow upon the grantee the permission to use a schema object owned by another user in a particular way. There are several types of object privileges. Some privileges apply only to certain schema objects. For example, the INDEX privilege applies only to tables, and the SELECT privilege applies to tables, views, and sequences.
تمنح صلاحيات الكائنات الشخص الذي تم منحه (الممنوح) الإذن باستخدام كائن بإسكيما مملوكة لمستخدم آخر على نحو معين. يوجد عدة أنواع من صلاحيات الكائنات. بعض الصلاحيات تطبق فقط على كائنات إسكيما معينة. على سبيل المثال صلاحية الفهرس(الدليل) تطبق فقط على الجداول، كما أن صلاحية (SELECT) تطبق على الجداول، ال(Views) وال(Sequences)
The following object privileges can be granted individually, grouped in a list, or with the keyword ALL to implicitly grant all available object privileges for a particular schema object.
صلاحيات الكائنات التالية يمكن أن تمنح فرادى ، مجمعة في قائمة، أو بالكلمة الدليلية (ALL) لتمنح ضمنياً كل صلاحيات الكائنات المتاحة لكائن معين بإسكيما.
Be careful when using ALL. It may implicitly grant powerful privileges.
كن حذراً عند استخدام كلمة (ALL) فربما تمنح ضمنيا صلاحيات قوية جداً.

SELECT

The most commonly used privilege for tables. With this privilege, the table owner permits the grantee to query the specified table with a SELECT statement.

INSERT
Permits the grantee to create new rows in the specified table with an INSERT statement.
UPDATE
Permits the grantee to modify existing rows in the specified table with an UPDATE statement.
DELETE

Permits the grantee to remove rows from the specified table with a DELETE statement.

ALTER

The following are powerful administrative privileges on tables; grant them cautiously.

Permits the grantee to execute an ALTER TABLE statement on the specified table.

This privilege can be used to add, modify, or rename columns in the table, to move the table

to another tablespace, or even to rename the specified table.
DEBUG
Permits the grantee to access, via a debugger, the PL/SQL code in any triggers on the specified table.
INDEX
Permits the grantee to create new indexes on the table. These new indexes will be owned by a different user than the table, which is an unusual practice. In most cases, the indexes on a table are owned by the same user who owns the table itself.
REFERENCES
Permits the grantee to create foreign key constraints that reference the specified table.

View object privileges

SELECT
The most commonly used privilege for views. With this privilege, the view owner permits the grantee to query the view.
INSERT
Permits the grantee to execute an INSERT statement on the specified view to create new rows.
UPDATE
Permits the grantee to modify existing rows in the specified view with an UPDATE statement.
DELETE
Permits the grantee to execute a DELETE statement on the specified view to remove rows.
DEBUG

Permits the grantee to access, via a debugger, the PL/SQL code in the body of any trigger on this view.

REFERENCES
Permits the grantee create foreign key constraints on the specified view.

Sequence object privileges

SELECT

Permits the grantee to access the current and next values (CURRVAL and NEXTVAL) of the specified sequence.

ALTER
Permits the grantee to change the attributes of the specified sequence with an ALTER statement.

Stored functions, procedures, packages, and Java object privileges

DEBUG
Permits the grantee to access, via a debugger, all the public and private variables and types declared in the specified program. If the specified object is a package, both the specification and the body are accessible to the grantee. The grantee can also use a debugger to place breakpoints in the specified program.
EXECUTE
Permits the grantee to execute the specified program. If the specified object is a package, any program, variable, type, cursor, or record declared in the package specification is accessible to the grantee.

Table object privileges

You use the GRANT statement to confer object privileges on either a user or a role. The optional keywords WITH GRANT OPTION additionally allow the grantee to confer these privileges on other users and roles.
تستخدم جملة (GRANT) لمنح صلاحيات كائن لكل من مستخدم أو دور. الكلمة الدليلية (WITH GRANT OPTION) تسمح للممنوح بالإضافة إلى ذلك أن يمنح امتيازات لمستخدمين وأدوار أخر.
For example, to give SELECT, INSERT, UPDATE, and DELETE privileges on the table CUSTOMERS to the role SALES_MANAGER, execute the following statement while connected as the owner of table CUSTOMERS:
GRANT SELECT,INSERT,UPDATE,DELETE ON customers TO sales_manager;

If you grant privileges to the special user PUBLIC, you make them available to all current and future database users.
إذا قمت بمنح صلاحيات للمستخدم الخاص (PUBLIC) فإنك تجعله متاحاً لجميع مستخدمي قاعدة البيانات الحالين والذين يأتون في المستقبل.
For example, to give all database users the SELECT privilege on table CUSTOMERS, execute the following while connected as the owner of the table:
GRANT SELECT ON customers TO public;
على سبيل المثال، لتعطي جميع مستخدمي قاعدة البيانات صلاحية (SELECT) على الجدول (CUSTOMERS) نفذ الأمر السابق عند اتصالك كمالك للجدول.
When you extend a privilege to another user or role, you can also extend the ability for that grantee to turn around and grant the privilege to others. To extend this extra option, include the keywords WITH GRANT OPTION in the GRANT statement.
عندما تقوم بمد الصلاحية لمستخدم آخر أو دور، يمكنك أيضاً تمديد القدرة للممنوح للالتفاف حول هذا و منح الامتياز لآخرين. لتمديد هذا الاختيار الزائد قم بتضمين الكلمة الدليلية (WITH GRANT OPTION) في جملة (GRANT).
For example, to give the SELECT privilege on table SALES.CUSTOMERS to the user SALES_ADMIN together with the permission for SALES_ADMIN to grant the SELECT privilege to others, execute the following:
GRANT SELECT ON sales.customers TO sales_admin WITH GRANT OPTION;

You can only include the WITH GRANT OPTION keywords when the grantee is a user or the special account PUBLIC. You cannot use WITH GRANT OPTION when the grantee is a role.
يمكنك فقط تضمين الكلمة الدليلية (WITH GRANT OPTION) عندما يكون الممنوح مستخدم أو حساب مستخدم خاص ولا يمكن استخدامها عندما يكون الممنوح دوراً.
If you grant an object privilege using the WITH GRANT OPTION keywords and later revoke that privilege, the revoke cascades, and the privileges created by the grantee are also revoked.
لو قمت بمنح صلاحية كائن مستخدماً الكلمة الدليلية (WITH GRANT OPTION) ثم قمت بسحب سحب هذه الصلاحية بعد ذلك فإن سحب التتالي والصلاحيات التي تم إنشائها بواسطة الممنوح يتم سحبها.

For example, Mary grants SELECT privileges on her table clients to Zachary with the WITH GRANT OPTION keywords. Zachary then creates a view based on the table mary.clients and grants the SELECT privilege on it to Rex. If Mary revokes the SELECT privilege from Zachary, the revoke cascades and removes the privilege from Rex. See Figure 6.1 for an illustration of this example.

2- Granting System Privileges
In general, system privileges permit the grantee to execute Data Definition Language (DDL) statements—such as CREATE, ALTER, and DROP—or Data Manipulation Language (DML) statements system wide. Oracle 10g has more than 170 system privileges, all of which are listed in the data dictionary view SYSTEM_PRIVILEGE_MAP.
بصفة عامة، صلاحيات النظام تسمح للممنوح بتنفيذ جمل (DDL) مثل: (CREATE, ALTER, DROP) أو جمل (DML) بشكل واسع. تمتلك أوراكل أكثر من 170 صلاحية نظام، جميعها موجودة في قاموس البيانات (SYSTEM_PRIVILEGE_MAP)
You will not be required to know all these privileges for the certification exam (thank goodness!), as many are for features that fall outside the scope of the exam.
Warning:
The CREATE ANY JOB privilege gives the grantee the ability to execute programs using any other user’s credentials. Grant it cautiously.

The GRANT ANY ROLE privilege permits grantees to assign or rescind powerful administrative roles, such as SCHEDULER_ADMIN and IMP_FULL_DATABASE to or from any user, including themselves or other DBAs. Grant it cautiously.
The ALTER USER privilege allows the grantee to change the authentication method or password for any user (and also change it back). This makes it possible for the grantee to masquerade as another user. Grant this privilege cautiously.

As with object privileges, you use the GRANT statement to confer system privileges on either a user or a role. Unlike object privileges, the optional keywords WITH ADMIN OPTION are required to additionally allow the grantee to confer these privileges on other users and roles.
كما في صلاحيات الكائنات، تستخدم جملة (GRANT) لتقوم بمنح صلاحيات نظام لكل من مستخدم أو دور. ليس مثل صلاحيات الكائنات ، الكلمة الدليلية (WITH ADMIN OPTION) تكون مطلوبة لتسمح للممنوح إضافة إلى ما تم منحه إليه أن يمنح تلك الصلاحيات لمستخدمين آخرين أو أدوار أخرى.
For example, to give the CREATE USER, ALTER USER, and DROP USER privileges to the role APPL_DBA, you execute the following statement:
GRANT create user, alter user, drop user TO appl_dba;

System and role privileges require the wording WITH ADMIN OPTION; object privileges require the wording WITH GRANT OPTION.
صلاحيات النظام والدور تتطلب كتابة الكلمات (WITH ADMIN OPTION)، بينما صلاحيات الكائنات تتطلب كتابة الكلمات (WITH GRANT OPTION).
Because the function is so similar, but the syntax is different, be sure you know when to use ADMIN and when to use GRANT.
A question involving this subtle difference may appear on the exam.
نظراً لأن الوظيفة متشابهة إلى حد كبير، لكن المعنى مختلف، لذا اعلم جيداً متى تستخدم (ADMIN) ومتى تستخدم (GRANT)
As with object privileges, you can grant system privileges to the special user PUBLIC. Granting privileges to PUBLIC allows anyone with a database account to exercise this privilege. In general, because system privileges are more powerful than object privileges, take care when granting a system privilege to PUBLIC.
كما في صلاحيات الكائنات، تستطيع منح صلاحيات نظام للمستخدم الخاص (PUBLIC). منح صلاحيات للمستخدم (PUBLIC) يسمح لأي واحد له حساب في قاعدة البيانات أن يستعمل هذه الصلاحية. بصفة عامة، نظراً لأن صلاحيات النظام أقوى كثيراً من صلاحيات الكائنات ، لذا انتبه جيداً عند منحك صلاحية نظام للمستخدم (PUBLIC).
For example, to give all current and future database users the FLASHBACK ANY TABLE privilege, execute the following:
على سبيل المثال لتقوم بإعطاء جميع المستخدمين الحاليين والمستحدثين في المستقبل صلاحية (FLASHBACK ANY TABLE) نفذ الأمر التالي:
GRANT flashback any table TO public;

To give the INDEX ANY TABLE privilege to the role APPL_DBA together with the permission to allow anyone with the role APPL_DBA to grant this privilege to others, execute the following:
GRANT index any table TO appl_dba WITH ADMIN OPTION;
If you grant a system privilege WITH ADMIN OPTION and later revoke that privilege, the privileges created by the grantee will not be revoked. Unlike object privileges, revocation of system privileges does not cascade.
لو قمت بمنح صلاحية نظام (WITH ADMIN OPTION) ثم تراجعت وسحبت هذه الصلاحية، فإن الصلاحيات التي تم إنشاؤها بواسطة الممنوح سوف لن تسحب. على غير ما في صلاحيات الكائنات، سحب صلاحيات النظام لا تسحب ما تحتها بالتتالي.
Think of it this way:
WITH GRANT OPTION includes the keyword GRANT and so implies that a revoke cascades, but WITH ADMIN OPTION does not mention GRANT, so a revoke has no effect.
مع (WITH GRANT OPTION) المتضمن الكلمة الدليلية (GRANT) لذا يشير إلى سحب الصلاحية بالتتالي، لكن مع (WITH ADMIN OPTION) لا يذكر (GRANT)، لذلك (revoke) ليس له تأثير.
Here’s an example.
1- Mary grants SELECT ANY TABLE privilege to new DBA Zachary with ADMIN OPTION.
2- Zachary then grants this privilege to Rex.
3- Later, Zachary gets promoted and leaves the department, so Mary revokes the SELECT ANY TABLE privilege from Zachary.
4- Rex’s privilege remains unaffected.
You can see this in Figure 6.3.
This behavior differs from object privileges, because the database does not record both grantor and grantee for system privileges only the grantee is recorded.
هذا السلوك يختلف عن صلاحيات الكائنات، لأن قاعدة البيانات لا تسجل كلا من المانح والممنوح لصلاحيات النظام، فقط الممنوح هو الذي يسجل.

To create a role, use the CREATE ROLE statement. You can optionally include an INDENTIFIED BY clause that requires users to authenticate themselves before enabling the role.

لإنشاء دور استخدم جملة (CREATE ROLE). تستطيع اختياريا أن تضمن عبارة (INDENTIFIED BY) التي تتطلب أن يحقق المستخدمون أنفسهم قبل تمكين الدور.

Roles requiring authentication are typically used inside an application, where a user’s activities are controlled by the application.

الأدوار التي تتطلب تحققاً تستخدم نموذجياً داخل تطبيق، حيث يتم التحكم في أنشطة المستخدمين بواسطة التطبيق.

To create the role heima_DBA, execute the following:

لإنشاء دور (APPL_DBA) نفذ الأمر التالي:

CREATE ROLE heima_dba;

To enable a role, execute a SET ROLE statement, like this:

لتمكين الدور، نفذ جملة (SET ROLE) كالتالي:
SET ROLE heima_dba IDENTIFIED BY heima_dba;

To create role:

SQL> CREATE ROLE heima_dba;

Role created.

To enable role:

SQL> SET ROLE heima_dba IDENTIFIED BY heima_dba;

Role set.

To grant role to user heima:

SQL> grant heima_dba to heima;

Grant succeeded.

SQL> SELECT role FROM session_roles;

ROLE

------------------------------

HEIMA_DBA

Granting privileges to role using Enterprise Manager:

System Privileges:

GRANT ALTER ANY TABLE TO "HEIMA_DBA"

GRANT ALTER SESSION TO "HEIMA_DBA"
GRANT ALTER SYSTEM TO "HEIMA_DBA"
GRANT CREATE ANY TABLE TO "HEIMA_DBA"
GRANT FLASHBACK ANY TABLE TO "HEIMA_DBA"

Object Privileges:

GRANT ALTER ON "HR"."COUNTRIES" TO "HEIMA_DBA"

GRANT DELETE ON "HR"."COUNTRIES" TO "HEIMA_DBA"
GRANT INSERT ON "HR"."COUNTRIES" TO "HEIMA_DBA"
GRANT SELECT ON "HR"."COUNTRIES" TO "HEIMA_DBA"
GRANT UPDATE ON "HR"."COUNTRIES" TO "HEIMA_DBA"
GRANT ALTER ON "HR"."DEPARTMENTS" TO "HEIMA_DBA"
GRANT DELETE ON "HR"."DEPARTMENTS" TO "HEIMA_DBA"
GRANT INSERT ON "HR"."DEPARTMENTS" TO "HEIMA_DBA"
GRANT SELECT ON "HR"."DEPARTMENTS" TO "HEIMA_DBA"
GRANT UPDATE ON "HR"."DEPARTMENTS" TO "HEIMA_DBA"
GRANT ALTER ON "HR"."EMPLOYEES" TO "HEIMA_DBA"
GRANT DELETE ON "HR"."EMPLOYEES" TO "HEIMA_DBA"
GRANT INSERT ON "HR"."EMPLOYEES" TO "HEIMA_DBA"
GRANT SELECT ON "HR"."EMPLOYEES" TO "HEIMA_DBA"
GRANT UPDATE ON "HR"."EMPLOYEES" TO "HEIMA_DBA"
GRANT ALTER ON "HR"."JOBS" TO "HEIMA_DBA"
GRANT DELETE ON "HR"."JOBS" TO "HEIMA_DBA"
GRANT INSERT ON "HR"."JOBS" TO "HEIMA_DBA"
GRANT SELECT ON "HR"."JOBS" TO "HEIMA_DBA"
GRANT UPDATE ON "HR"."JOBS" TO "HEIMA_DBA"
GRANT ALTER ON "HR"."JOB_HISTORY" TO "HEIMA_DBA"
GRANT DELETE ON "HR"."JOB_HISTORY" TO "HEIMA_DBA"
GRANT INSERT ON "HR"."JOB_HISTORY" TO "HEIMA_DBA"
GRANT SELECT ON "HR"."JOB_HISTORY" TO "HEIMA_DBA"
GRANT UPDATE ON "HR"."JOB_HISTORY" TO "HEIMA_DBA"
GRANT ALTER ON "HR"."LOCATIONS" TO "HEIMA_DBA"
GRANT DELETE ON "HR"."LOCATIONS" TO "HEIMA_DBA"
GRANT INSERT ON "HR"."LOCATIONS" TO "HEIMA_DBA"
GRANT SELECT ON "HR"."LOCATIONS" TO "HEIMA_DBA"
GRANT UPDATE ON "HR"."LOCATIONS" TO "HEIMA_DBA"
GRANT ALTER ON "HR"."REGIONS" TO "HEIMA_DBA"
GRANT DELETE ON "HR"."REGIONS" TO "HEIMA_DBA"
GRANT INSERT ON "HR"."REGIONS" TO "HEIMA_DBA"
GRANT SELECT ON "HR"."REGIONS" TO "HEIMA_DBA"
GRANT UPDATE ON "HR"."REGIONS" TO "HEIMA_DBA"
GRANT ALTER ON "HR"."SYS_TEMP_FBT" TO "HEIMA_DBA"
GRANT DELETE ON "HR"."SYS_TEMP_FBT" TO "HEIMA_DBA"
GRANT INSERT ON "HR"."SYS_TEMP_FBT" TO "HEIMA_DBA"
GRANT SELECT ON "HR"."SYS_TEMP_FBT" TO "HEIMA_DBA"
GRANT UPDATE ON "HR"."SYS_TEMP_FBT" TO "HEIMA_DBA"
GRANT ALTER ON "HR"."TEST" TO "HEIMA_DBA"
GRANT DELETE ON "HR"."TEST" TO "HEIMA_DBA"
GRANT INSERT ON "HR"."TEST" TO "HEIMA_DBA"
GRANT SELECT ON "HR"."TEST" TO "HEIMA_DBA"
GRANT UPDATE ON "HR"."TEST" TO "HEIMA_DBA"

3- Granting Role Privileges
As with object and system privileges, you use the GRANT statement to confer role privileges on either a user or another role. Also, like system privileges, the optional keywords WITH ADMIN OPTION allow the grantee to confer these privileges on other users and roles.
كما في صلاحيات الكائنات والنظام، فإننا نستخدم جملة (GRANT) لمنح صلاحيات لأي من مستخدم أو دور. أيضا كما في صلاحيات النظام، الكلمة الاختيارية الدليلية (WITH ADMIN OPTION) تسمح للممنوح أن يقوم بمنح صلاحيات لمستخدمين آخرين أو أدوار أخر.
For example, to give the OEM_MONITOR role to user heima, execute the following:
على سبيل المثال، لإعطاء دور (OEM_MONITOR) للمستخدم (heima) نفذ الأمر التالي:
GRANT oem_monitor TO charlie;
ملاحظة: دور (OEM_MONITOR) هو دور يجعل المستخدم الذي تم منحه هذا الدور قادراً على الدخول عبر (Enterprise Manager) ومراقبة عمل قاعدة البيانات حسب ماله من صلاحيات
(Normal, Sysoper or Sysdba).
As with the other privileges, you can grant role privileges to the special user PUBLIC. Granting privileges to PUBLIC allows anyone with a database account to exercise this privilege.
كما في الصلاحيات الأخرى، تستطيع أن تمنح صلاحيات دور للمستخدم الخاص (PUBLIC).
إن منح صلاحيات للمستخدم (PUBLIC) يسمح لأي مستخدم له حساب بقاعدة البيانات أن يمارس تلك الصلاحية.
For example, to give all current and future database users use of the plustrace role, execute the following:
على سبيل المثال لإعطاء المستخدمين الحاليين والمستحدثين صلاحية استخدام الدور (plustrace) نفذ الأمر التالي:
GRANT plustrace TO public;

To give the INDEX ANY TABLE privilege to the role heima_DBA together with the permission to allow anyone with the role heima_DBA to grant this privilege to others, execute the following:
لإعطاء صلاحية (INDEX ANY TABLE) – عمل فهرس أو دليل لأي جدول- للدور (heima_DBA) مصحوباً بالإذن لأي أحد مع الدور (heima_DBA) بمنح هذه الصلاحية للآخرين، نفذ الأمر التالي:
GRANT index any table TO heima_DBA WITH ADMIN OPTION;
When it comes to granting a role WITH ADMIN OPTION, roles behave like system privileges, and subsequent revocations do not cascade.
عندما يتعلق الأمر بمنح دور خيار الإدارة(WITH ADMIN OPTION) ، فإن الأدوار تتصرّف مثل امتيازات النظام، وإلغاء هذه الامتيازات لا يتساقط بالتتالي.
ALTER PROFILE "MONITORING_PROFILE" LIMIT IDLE_TIME 60

Enabling Roles
Roles can be enabled or disabled for that matter selectively in each database session. If you have two concurrent sessions, the roles in effect for each session can be different.
يتم تمكين الأدوار أو تعطيلها بشكل انتقائي في كل جلسة لقاعدة البيانات. إذا كنت تمتلك جلستين متزامنتين فإن الأدوار لكلّ جلسة يمكن أن تكون مختلفة.
Use the SET ROLE role_list statement to enable one or more roles. role_list is a comma-delimited list of roles to enable. This list can include the keyword ALL, which enables all the roles granted to the user.
استخدم الجملة (SET ROLE role_list) لتمكين دور أو أكثر. العبارة (role_list) قائمة محددة من الفاصلات للأدوار المراد تمكينها. هذه القائمة يمكن أن تشمل الكلمة المفتاحية (ALL) والتي تقوم بتمكين كل الأدوار الممنوحة للمستخدم.
You can optionally append a list of roles to exclude from the ALL list by specifying ALL EXCEPT exclusion_list.

يمكن تذييل قائمة اختيارية من الأدوار لتستبعد من قائمة (ALL) بتحديد قائمة الأدوار المستبعدة
(ALL EXCEPT exclusion_list).
If a role has a password associated with it, the keywords IDENTIFIED BY password must immediately follow the role name in the role_list.
إذا كان الدور له كلمة سر مصاحبة له، فإن الكلمة المفتاحية (IDENTIFIED BY password) يجب إتباعها فوراً لإسم الدور في قائمة الأدوار.
For example, to enable the password-protected role HR_ADMIN, together with the unprotected role EMPLOYEE, execute the following:
على سبيل المثال لتمكين الدور (HR_ADMIN) المحمي بكلمة سر، مع الدور (EMPLOYEE) غير المحمي، نفذ الأمر التالي:
SET ROLE hr_admin IDENTIFIED BY "my!seekrit", employee;

To enable all roles except HR_ADMIN, run this:
لتمكين كل الأدوار ماعدا الدور (HR_ADMIN) نفذ الآتي:
SET ROLE ALL EXCEPT hr_admin;
You can enable as many roles as have been granted to you, up to the MAX_ENABLED_ROLES initialization parameter.
يمكنك تمكين أدوار بقدر ما تم منحه لك حتى الرقم الأقصى الموجود بالمعامل الإبتدائي (MAX_ENABLED_ROLES)
Identifying Enabled Roles
The roles that are enabled in your session are listed in the data dictionary view SESSION_ROLES. To identify these enabled roles for your session, run the following:
الأدوار التي تم تمكينها في جلسة الاتصال تدرج في قاموس البيانات (SESSION_ROLES). لتحديد هذه الأدوار نفذ الآتي:
SELECT role FROM session_roles;
These roles include the roles that have been granted to you, the roles that have been granted to the special user PUBLIC, and the roles that you have inherited by way of other roles. To identify the roles granted to either user or the special user PUBLIC, run the following:
هذه الأدوار تتضمن الأدوار التي تم منحها لك ، الأدوار التي تم منحها للمستخدم الخاص (PUBLIC) والأدوار التي تم وراثتها عن طريق أدوار أخرى. لتحدد الأدوار التي تم منحها لمستخدم أو للمستخدم الخاص (PUBLIC)، نفذ الآتي:
SELECT granted_role FROM user_role_privs WHERE username IN (USER, 'PUBLIC');
The role DBA includes the role SCHEDULER_ADMIN, which in turn has system privileges (such as CREATE ANY JOB). A user who has been granted the DBA role inherits the SCHEDULER_ADMIN role indirectly.
الدور (DBA) يتضمن الدور (SCHEDULER_ADMIN) الذي تباعاً له امتيازات النظام (مثل CREATE ANY JOB). المستخدم الذي تم منحه الدور (DBA) يرث الدور (SCHEDULER_ADMIN) بصورة غير مباشرة.
To identify the roles that are both enabled in your session and granted directly to you or PUBLIC but not those roles that you inherited, run this:
لتحديد الأدوار التي تم تفعيلها في جلسة اتصالك والتي تم منحها مباشرة لك أو للمستخدم (PUBLIC) ولكن ليس أولئك الأدوار التي قد ورثتها، نفذ الآتي:
SELECT role FROM session_roles
INTERSECT
SELECT granted_role FROM user_role_privs
WHERE username IN (USER, 'PUBLIC');
In your sessions, you can disable only these directly granted and public roles.

Disabling Roles
Roles can be disabled in a database session either en masse or by exception. Use the SET ROLE NONE statement to disable all roles. Use the SET ROLE ALL EXCEPT role_list statement to enable all roles except those in the comma-delimited role_list.
يمكن تعطيل الأدوار في جلسة اتصال بقاعدة البيانات إما بشكل جماعي أو بشكل استثنائي. استخدم الجملة (SET ROLE NONE) لتعطيل. استخدم الجملة (SET ROLE NONE EXCEPT role_list) لتفعيل كل الأدوار فيما عدا المحدد أسماؤهم في القائمة.
There is no way to selectively disable a single role. Also, you cannot disable roles that you inherit by way of another role without disabling the parent role. For example, you cannot disable the SCHEDULER_ADMIN role without disabling the DBA role.
لا يوجد طريقة لتعطيل دور منفرد بشكل انتقائي. أيضاً لا يمكن تعطيل دور تم وراثته بواسطة دور آخر بدون تعطيل الدور الأصل. على سبيل المثال: لا يمكن تعطيل الدور (SCHEDULER_ADMIN) بدون تعطيل الدور (DBA).
Setting Default Roles
Roles that are enabled by default when you log on are called default roles. You do not need to specify a password for default roles and do not have to execute a SET ROLE statement to enable a default role.
Change the default roles for a user account with an ALTER USER DEFAULT ROLE role_list statement. The role_list can include the keywords ALL, NONE, and EXCEPT, in the same manner as with a SET ROLE statement.
- الأدوار التي تم تمكينها بالأساس عند الدخول تسمى أدواراً أصلية. أنت لست بحاجة إلى تحديد كلمة سر للأدوار الأصلية وليس من الضروري تنفيذ جملة (SET ROLE) لتمكين دور أصلي.
- تغيير الأدوار الأصلية لحساب مستخدم بجملة (ALTER USER DEFAULT ROLE role_list)
- قائمة الأدوار ممكن أن تتضمّن الكلمات الدليلية (ALL, NONE, and EXCEPT) بنفس الطّريقة كما في جملة (SET ROLE).
Including a password-protected role in the role_list defeats the purpose of password protecting the role as it is automatically enabled without the password.
تضمين دور محمي بكلمة سر في الـ (role_list) تحبط غرض كلمة السر التي تحمي الدور كما لو تم تمكينها آليا بدون كلمة السر.
When you create a role, you are implicitly granted that role with the admin option, and it is configured as a default role for your account.
عندما تقوم بإنشاء دور ، فأنت تُمنح ضمنياً هذا الدور مع خيار الإدارة (WITH ADMIN OPTION) ويتم تهيئته كدور أساسي لحسابك.
For example, to create the role EMPLOYEE, grant it to user scott, and configure all of scott’s roles except PLUSTRACE as default roles, run the following:
CREATE ROLE employee;
GRANT employee TO scott;
ALTER USER scott DEFAULT ROLE ALL EXCEPT plustrace;
Because the creator of a role automatically has that role assigned as a default role, administrative users (such as SYS or SYSTEM) who create many roles may need to alter their default role list. If you attempt to log on with more default roles than allowed by the MAX_ENABLED_ROLES initialization parameter, you will raise an exception and your logon will fail.

Real World Scenario
Password-Protected Role
Lucinda works in HR and needs to be able to modify an employee’s salary after they have a review and their raise is approved. The HR application ensures that the raise is approved and falls within corporate guidelines. Although Lucinda needs to be able to change employee salaries, she should be allowed to do so only from within the HR application, because it ensures that business rules are followed.
تعمل لوسيندا في إدارة الموارد البشرية ومن الضروري أن تكون قادرة على تعديل راتب مستخدم بعد أن تتم المراجعة والموافقة على الترقية. يقوم تطبيق الموارد البشرية بالتأكد من الموافقة على الترقية وتقع ضمن التعليمات المتعلّقة بالشركة. على الرغم من أن لوسيندا من الضروري أن تكون قادرة على تغيير رواتب المستخدمين، فإنه يجب أن يسمح لها أن تعمل ذلك فقط من خلال تطبيق الموارد البشرية، لأنه يضمن أنّ قواعد العمل قد تم إتباعها.
You wisely choose to use a password-protected role to satisfy these requirements. Update on the salary table is granted to the password-protected role salary_admin. Lucinda is then granted the salary_admin role, but she is not told the password for it. The HR application has the password encoded within it, so when Lucinda runs the HR application, unbeknownst to her, a SET ROLE salary_admin IDENTIFY BY password statement is executed, enabling the role and allowing her to change the salary.
لقد قمت بحكمة باختيار أن تستخدم دوراً محمياً بكلمة سر لاستيفاء هذه المتطلبات. التحديث في جدول الرواتب يُمنح إلى الدور المحمي بكلمة السر (salary_admin). تمنح لوسيندا حينئذ الدور (salary_admin) ، لكنّها لم تخبر بكلمة السر الخاصة به. يمتلك تطبيق الموارد البشرية كلمة السر مشفرة به، لذلك عندما تقوم لوسيندا بتشغيل تطبيق الموارد البشرية، فإن شيئاً مجهولاً لها , يتم تنفيذه بجملة:
(SET ROLE salary_admin IDENTIFY BY password(
لتقوم بتمكين الدور ويسمح لها بتغيير الراتب.
If Lucinda tries to execute an UPDATE statement on the salary table from iSQLPlus, she will get an insufficient privileges error.
إذا حاولت لوسيندا تنفيذ جملة (UPDATE) على جدول الرواتب من خلال (iSQLPlus) فإنها سوف تحصل على رسالة " خطأ بأن الإمتيازات غير كافية "
أقابل نهديك بكل شوق ولهفة وألمس ردفيك كالطفل المدلل


Create User Heima identified by Heima;
Create Role Heima_admin identified by ha;
Grant Heima_admin to Heima;
Grant Create session to Heima;
Grant Update on hr.employees to Heima_admin;
Grant Select on hr.Employees to Heima_admin;
Grant OEM_Monitor to Heima_admin;

Controlling Resource Usage by Users

An Oracle 10g database lets you limit some resources that your user accounts consume. Disk space limits are governed by tablespace quotas, and CPU, memory, and hybrid limits are implemented with profiles.
In the following sections, you will learn how to manage resource consumption in your database with roles and quotas.
تحدّد قاعدة بيانات أوراكل 10 g بعض الموارد التي تستعملها حسابات المستخدمين. حدود سعة قرص يتم التحكم فيها بواسطة حصص ملف الجداول، ووحدة المعالجة المركزية والذاكرة، والحدود الهجينة مطبّقة بلمحات الحياة. في الأقسام التالية، سوف تتعلّم كيف تدير استهلاك المورد في قاعدة بياناتك بالأدوار والحصص.

Assigning Tablespace Quotas
Before a user can create objects in a tablespace, they must have a space usage quota for that tablespace. Tablespace quotas limit the amount of disk space that a user can consume. The default quota is none, which is why you need to assign a quota before you can create objects in a tablespace. You can assign a space usage quota at the same time you create a user, with the CREATE USER statement:
CREATE USER chip IDENTIFIED BY "Seek!r3t"
QUOTA 100M ON USERS;
Or after the user has been created with the ALTER USER statement:
ALTER USER bart QUOTA UNLIMTED ON USERS;
The special keyword UNLIMITED tells the database that the user should not have a preset limit on the amount of space that their objects can consume.

Assigning Resource Limits with a Profile
CPU and session-oriented resource limits are managed through the use of a profile. Profiles let you set limits for several resources, including CPU time, memory, and the number of logical reads performed during a user session or database call. A database call is either a parse, an execute, or a fetch. Usually, the database implicitly performs these calls for you. You can explicitly make these database calls from Java, PL/SQL, or OCI (Oracle Call Interface) programs.
وحدة المعالجة المركزية و حدود جلسة الموارد الموجهة تدار من خلال إستعمال (profile). تقوم ال(profiles) بجعلك تقوم بضبط حدود لعدة موارد، متضمنة وقت وحدة المعالجة المركزية، الذاكرة، وعدد القراءات المنطقيّة المؤداة أثناء جلسة مستخدم أو نداء قاعدة بيانات. نداء قاعدة البيانات إمّا استدعاء، تنفيذ، أو جلب. عادة، يمكن أن تجعل نداءات قاعدة البيانات هذه صراحة من (from Java, PL/SQL, or OCI (Oracle Call Interface) programs.
A logical read is a measure of the amount of work that the database performs while executing SQL statements. Statements that generate more logical reads require the database to perform more work than statements generating fewer logical reads. Technically, a logical read is counted for each row accessed via ROWID (index access) and for each data block accessed via multiblock read (full table scan or index fast full scan).
القراءات المنطقيّة هي مقياس لكمية العمل التي تؤدّيها قاعدة البيانات أثناء تنفيذ بيانات جمل (SQL. الجمل التي تولّد قراءات منطقيّة أكثر تطلب من قاعدة البيانات أداء عمل أكثر من البيانات التي تولّد قراءات منطقيّة أقل. تقنياً القراءة المنطقيّة تحسب لكلّ صفّ تم تشغيله عن طريق (ROWID) (تشغيل دليلي) ولكلّ كتلة بيانات تم تشغيلها عن طريق قراءة الكتل المتعددة (مسح كامل الجدول أو مسح كامل سريع للفهرس).
To enable resource limit restrictions with profiles, first enable them in the database by setting the initialization parameter resource_limit to true, like this:
ALTER SYSTEM SET resource_limit = TRUE SCOPE = BOTH;
لتمكين قيود حدّ الموارد بال (profiles)، أولا قم بتمكين ذلك في قاعدة البيانات بضبط المعامل الإبتدائي(resource_limit) بالقيمة (TRUE) ، كالتالي:
To assign resource limits to a profile, use the CREATE PROFILE or ALTER PROFILE statement with one or more of the kernel resource parameters. These statements support the following clauses to limit resources:
لتخصيص حدود مصادر لبروفايل استخدم جملة (CREATE PROFILE or ALTER PROFILE) مع واحد أو أكثر من موارد كرنل. هذه الجمل تدعم العبارات التالية لتحديد الموارد:
ALTER USER "LUCINDA" PROFILE "MONITORING_PROFILE"
1- CONNECT_TIME
Limits any session established by a user having this profile to the specified number of minutes.
When a session exceeds the specified number of minutes, the database rolls back any uncommitted changes and terminates the session.
When a session exceeds the specified number of minutes, the database rolls back any uncommitted changes and terminates the session.
The next call to the database raises an exception. You can use the special value UNLIMITED to tell the database that there is no limit to a session’s duration.
تقوم بتحديد أي جلسة اتصال تم إنشائها من قبل مستخدم يمتلك هذا البروفايل بعدد محدد من الدقائق.
زمن الاتصال أحياناً يسمى (wall clock time) لتمييزه عن زمن البروسيسور.
عندما يزيد زمن الاتصال للجلسة عن عدد الدقائق المحدد فإن قاعدة البيانات تتراجع عن التغييرات غير المؤكدة وتنهي الاتصال.
الاستدعاء التالي لقاعدة البيانات يولد استثناء. يمكن استخدام القيمة الخاصة (UNLIMITED) لإخبار قاعدة البيانات بأن لاحدود لزمن الاتصال.

CREATE PROFILE agent LIMIT CONNECT_TIME 10;
ALTER PROFILE data_analyst LIMIT CONNECT_TIME UNLIMITED;

2- CPU_PER_CALL
Limits the amount of CPU time that can be consumed by any single database call in any session established by a user with this profile.
When this limit is breached, the statement fails and is automatically rolled back, and an exception is raised.
The user can then commit or roll back any uncommitted changes in the transaction.
تقوم بتحديد مقدار زمن البروسيسور الذي يتم استهلاكه بواسطة نداء واحد لقاعدة البيانات في أي جلسة اتصال تم إنشائها بواسطة مستخدم.
عندما يخترق هذا الحاجز فإن الجمل تفشل ويتم التراجع عنها أوتوماتيكيا وإظهار استثناء.
يستطيع المستخدم حينئذ تأكيد التغييرات غير المؤكدة أو التراجع عنها في الإجراءات.
CREATE PROFILE agent LIMIT CPU_PER_CALL 3000;
ALTER PROFILE data_analyst LIMIT CPU_PER_CALL UNLIMITED;

3- CPU_PER_SESSION
Limits the amount of CPU time that can be consumed in any session established by a user with this profile.
When this limit is breached, the current statement fails, the transaction is automatically rolled back, and an exception is raised.
The user can then commit or roll back any uncommitted changes in the transaction before logging off.
يقوم بتحديد مقدار زمن البروسيسور الذي يتم استهلاكه في أي جلسة اتصال تم إنشائها بواسطة مستخدم مع هذا البروفايل.
عندما يخترق هذا الحاجز فإن الجمل تفشل ويتم التراجع عنها أوتوماتيكيا وإظهار استثناء.
يستطيع المستخدم حينئذ تأكيد التغييرات غير المؤكدة أو التراجع عنها في الإجراءات قبل الخروج.
CREATE PROFILE agent LIMIT CPU_PER_CALL 30000;
ALTER PROFILE data_analyst LIMIT CPU_PER_CALL UNLIMITED;

4- IDLE_TIME
Limits the duration of time between database calls to the specified number of minutes.
If a user having this profile exceeds this setting, the next statement fails, and the user is allowed to either commit or roll back any uncommitted changes before logging off.
Long-running statements are not affected by this setting.
- يقوم بتحديد الزمن المستغرق بين نداءات قاعدة البيانات بعدد محدد من الدقائق.
- عندما يزيد مستخدم يمتلك هذا البروفايل عما تم ضبطه فإن الجملة التالية سوف تفشل ويتم السماح للمستخدم بتأكيد التغييرات غير المؤكدة أو التراجع عنها
في الإجراءات قبل الخروج.
- الجمل التي تستغرق زمناً طويلاً في التنفيذ لا تتأثر بهذا الضبط.
CREATE PROFILE agent LIMIT IDLE_TIME 10;
ALTER PROFILE daemon LIMIT IDLE_TIME UNLIMITED;

5- LOGICAL_READS_PER_CALL
Caps the amount of work that any individual database call performs to the specified number of logical reads.
The database call is either a parse, an execute, or a fetch.
If the limit is exceeded, the database rolls back the statement, returns an error to the calling program, and allows the user to either commit or roll back any uncommitted changes.
Logical reads are computed as the sum of consistent gets plus current mode gets.
يتوج مقدار العمل الذي يؤديه نداء فردي لقاعدة البيانات بعدد محدد من القراءات المنطقية.
نداء قاعدة البيانات يكون إما تعريب أو تنفيذ أو استدعاء.
لو تم تخطي الحاجز فإن قاعدة البيانات تتراجع للخلف أو ترجع خطأً للبرنامج الذي قام بالاستدعاء ويسمح للمستخدم بتأكيد التغييرات غير المؤكدة أو التراجع عنها.
يتم حساب القراءات المنطقية بحساب مجموع القراءات الثابتة بالإضافة إلى القراءات الحالية.
CREATE PROFILE agent LIMIT LOGICAL_READS_PER_CALL 2500;
ALTER PROFILE data_analyst LIMIT LOGICAL_READS_PER_CALL 1000000;



6- LOGICAL_READS_PER_SESSION
Limits the amount of database work that a user’s session can consume to the specified number of logical reads.
When the limit is exceeded, the current statement fails and an exception is raised, and the user must either commit or roll back the transaction and end the session.
Logical reads are computed as the sum of consistent gets plus current mode gets.
يحدد مقدار عمل قاعدة البيانات التي تستهلكها جلسة اتصال برقم محدد من القراءات المنطقية.
عندما يتخطى هذا الحد فإن الجملة التالية سوف تفشل ويتم السماح للمستخدم بتأكيد التغييرات غير المؤكدة أو التراجع عنها في الإجراء ويتم إنهاء الاتصال.
يتم حساب القراءات المنطقية بحساب مجموع القراءات الثابتة بالإضافة إلى القراءات الحالية.

CREATE PROFILE agent LIMIT LOGICAL_READS_PER_SESSION 250000;
ALTER PROFILE data_analyst LIMIT LOGICAL_READS_PER_SESSION 35000000;

7- PRIVATE_SGA
Limits the amount of SGA (System Global Area) memory in bytes that a user connecting with shared servers (via multithreaded server [MTS]) can allocate to the persistent area in the PGA (Program Global Area).
This area contains bind information among other items.
يحدد مقدار الـ (SGA-System Global Area)بالبايت التي يتصل بها مستخدم مع الـ(shared servers) من خلال الـ(multithreaded server [MTS]))
هذه المساحة تحتوي على معلومات ربط بين العناصر الأخرى.
CREATE PROFILE agent LIMIT PRIVATE_SGA 2500;
ALTER PROFILE data_analyst LIMIT PRIVATE_SGA UNLIMITED;

8- SESSIONS_PER_USER
Restricts a user with this profile to the specified number of database sessions.
This setting can be useful to discourage DBAs from all connecting to a shared administrative account to do their work when corporate policy indicates that they should be connecting to their individual accounts.
يقوم بتقييد المستخدم مع هذا البروفايل بعدد محدد من جلسات الاتصال بقاعدة البيانات.
هذه الإعدادات تكون مفيدة في تثبيط عزيمة مديري قواعد البيانات من كل اتصال بالحساب الإداري المشترك لأداء أعمالهم عندما تشير سياسة متعلّقة بالشركة بأنّهم يجب أن يتصلوا من خلال حساباتهم الفردية.
CREATE PROFILE admin_profile LIMIT SESSIONS_PER_USER 2;
ALTER PROFILE data_analyst LIMIT SESSIONS_PER_USER 6;

9- COMPOSITE_LIMIT
Limits the number of service units that can be consumed during a user session.

Service units are calculated as the weighted sum of CPU_PER_SESSION, LOGICAL_READS_PER_SESSION, CONNECT_TIME, and PRIVATE_SGA values.

The weightings are established with the ALTER RESOURCE COST statement and can be viewed from the RESOURCE_COST data dictionary view.

يقوم بتحديد عدد وحدات الخدمة التي يتم استهلاكها أثناء جلسة الاتصال.
يتم حساب وحدات الخدمة كمجموع قيم (CPU_PER_SESSION, LOGICAL_READS_PER_SESSION, CONNECT_TIME, and PRIVATE_SGA)

CREATE PROFILE admi_profile LIMIT COMPOSITE_LIMIT UNLIMITED;

ALTER PROFILE data_analyst LIMIT COMPOSITE_LIMIT 100000;

ALTER USER "LUCINDA" PROFILE "ADMIN_PROFILE";

To enforce the resource limits established with profiles, you must enable them by setting the initialization parameter RESOURCE_LIMIT to TRUE. The default setting is FALSE. Set this parameter with the ALTER SYSTEM statement, like this:
لفرض حدود الموارد التي تم إنشائها مع البروفايلز ، يجب أن يتم تمكين حدود الموارد بضبط المتغير الابتدائي (RESOURCE_LIMIT) للقيمة (TRUE). الإعداد الأصلي هو القيمة (FALSE):
ALTER SYSTEM SET resource_limit = TRUE SCOPE=BOTH;
You can also use profiles to manage passwords.

Applying the Principle of Least Privilege تطبيق مبدأ أقل الامتيازات:

The principle of least privilege states that each user should only be given the minimal privileges needed to perform their job.
This principle is a central tenet to the initially closed philosophy whereby all access is initially closed or unavailable and access is opened on a need-to-know basis. Highly secure environments typically operate under an initially closed philosophy. The contrasting philosophy is an initially open philosophy, whereby all access is by default open to all users and only sensitive areas are closed.
Academic or learning environments typically operate under an initially open philosophy.
ينص مبدأ أقلّ الامتيازات على أن كل مستخدم يجب أن يعطي فقط أقل الامتيازات المطلوبة لأداء وظيفته.
هذا المبدأ هو العقيدة المركزية في الفلسفة المغلقة حيث أن الوصول(التشغيل) مغلق أو غير متوفر أوليا والوصول يكون مفتوحاً عند الحاجة.
بيئات الأعمال المؤمنة جدا (بشكل نموذجي) تعمل تحت فلسفة مغلقة أوليا. إنّ الفلسفة المتضاربة فلسفة مفتوحة أوليا، حيث كلّ الوصول (التشغيل) بالأساس مفتوح إلى كلّ المستخدمين والمناطق الحسّاسة فقط هي التي تكون مغلقة.
بيئات الأعمال الأكاديمية أو التعليمية تعمل نموذجياً تحت فلسفة الفتح الأولي.

Many IT organizations want the most secure policies for production systems, which calls for the initially closed approach to security.
To support the need for administrators and programmers to quickly learn new technology, these shops frequently create “sandbox” systems that follow the initially open philosophy.
كثير من شركات تكنولوجيا المعلومات تريد السياسات الأكثر أمناً لأنظمة الإنتاج، التي تدعو إلى المنهج الأمني المغلق أوليا.
لدعم حاجة مدراء قواعد البيانات والمبرمجين لتعلّم تقنية جديدة بسرعة، هذه المحلات كثيراً تخلق أنظمة "sandbox" التي تتبع الفلسفة المفتوحة أوليا.
These sandbox systems afford their limited users the learning benefit of the initially open approach, while not storing or giving gateway access to any sensitive information elsewhere in the enterprise.
تتحمّل هذه الأنظمة (sandbox) لمستخدميهم المحدودين منافع التعلّم لمنهج الانفتاح الأولي، بينما لا تخزن أو تعطي وصول لبوّابة أيّ معلومات حسّاسة في مكان آخر في المشروع.
To implement the principle of least privilege on your production or development systems, you should take several actions, or best practices, while setting up or locking down the database.
لتطبيق مبدأ أقلّ الامتيازات على أنظمة الإنتاج أو التطوير، يجب أن تتّخذ عدّة إجراءات، أو أفضل الممارسات، عند بدء ضبط أو تأمين قاعدة البيانات.
1- Protect the data dictionary.
Ensure that users with the SELECT ANY TABLE privilege cannot access the tables that underlie the data dictionary by setting:
O7_DICTIONARY_ACCESSIBILITY = FALSE. This is the default setting.

2- Revoke unnecessary privileges from PUBLIC.
By default, several packages and roles are granted to the special user PUBLIC. Review these privileges and revoke the EXECUTE privilege from PUBLIC if these packages are not necessary. Some of these packages include the following:
UTL_TCP
Permits the grantee to establish a network connection to any waiting TCP/IP network service. Once a connection is established, arbitrary information can be sent and received directly from the database to and from the other TCP services on your network.
If your organization is concerned about information exchange over TCP/IP, revoke the EXECUTE privilege on this package from PUBLIC. Grant privileges on this package only to those users who need it.
يسمح للممنوح بإنشاء اتصال شبكي لأي خدمة تشبيك (TCP/IP) بالانتظار. بمجرد إنشاء الاتصال فإن معلومات اختيارية يمكن أن يتم إرسالها و استقبالها مباشرة من قاعدة البيانات إلى أو من خدمات (TCP) أخرى على الشبكة.
لو أن شركتك معنية بتبادل المعلومات عبر (TCP/IP) قم بسحب امتياز (EXECUTE) على هذه الحزمة من المستخدم (PUBLIC).
UTL_SMTP
Permits the grantee to send arbitrary e-mail. If your organization is concerned about information exchange via e-mail, revoke the EXECUTE privilege on this package from PUBLIC. Grant privileges on this package only to those users who need it.
يسمح للممنوح بإرسال بريد اختياري.لو أن شركتك معنية بتبادل المعلومات عبر البريد الالكتروني، قم بسحب الامتياز (EXECUTE) على هذه الحزمة من المستخدم (PUBLIC). قم بمنح هذا الامتياز فقط للمستخدمين الذين يحتاجونه.
UTL_HTTP
Permits the grantee to send and receive arbitrary data via the HTTP protocol.
If your organization is concerned about information exchange via HTTP, revoke the
EXECUTE privilege on this package from PUBLIC. Grant privileges on this package only to those users who need it.
يسمح للممنوح بإرسال واستقبال بيانات اختيارية عبر بروتوكول (HTTP). .لو أن شركتك معنية بتبادل المعلومات عبر بروتوكول (HTTP)، قم بسحب الامتياز (EXECUTE) على هذه الحزمة من المستخدم (PUBLIC). قم بمنح هذا الامتياز فقط للمستخدمين الذين يحتاجونه.

UTL_FILE
Permits the grantee to read and write text data to and from arbitrary operating system files that are in the designated directories. UTL_FILE does not manage concurrency, so multiple user sessions can step on each other, overwriting changes via UTL_FILE. Consider revoking the EXECUTE privilege on this package from PUBLIC.
يسمح للممنوح بقراءة وكتابة بيانات نصية من وإلى ملفات اختيارية لنظام التشغيل موجودة بالأدلة المعنية. لا يقوم امتياز (UTL_FILE) بإدارة التلاقي لذلك جلسات الاتصال يمكنها تخطي بعضها بالكتابة الفوقية من خلاله. اعتمد سحب امتياز (EXECUTE) على هذه الحزمة من المستخدم (PUBLIC).


DBMS_OBFUSCATION_TOOLKIT and DBMS_CRYPTO
Permit the grantee to employ encryption technologies. In a managed environment using encryption, the keys are stored and managed. If encryption keys are lost, the encrypted data is undecipherable.
Consider revoking the EXECUTE privilege on these packages from PUBLIC.
يسمح للممنوح بتطبيق تقنيات تشفير. في بيئات الأعمال التي تستخدم تشفير فإن المفاتيح يتم تخزينها وإدارتها. فإذا ما فقدت مفاتيح التشفير ، فإن البيانات المشفّرة تكون مستحيلة الحل.. اعتمد سحب امتياز (EXECUTE) على هذه الحزمة من المستخدم (PUBLIC).
You can revoke the EXECUTE privileges like this:
REVOKE EXECUTE ON utl_tcp FROM PUBLIC;
REVOKE EXECUTE ON utl_smtp FROM PUBLIC;
REVOKE EXECUTE ON utl_http FROM PUBLIC;
REVOKE EXECUTE ON utl_file FROM PUBLIC;
REVOKE EXECUTE ON dbms_obfuscation_toolkit FROM PUBLIC;
REVOKE EXECUTE ON dbms_crypto FROM PUBLIC;
You can query the data dictionary to see what other packages may need to be locked down by revoking the EXECUTE privilege from PUBLIC.
Here is a query to list the packages, owned by user SYS, that have EXECUTE privilege granted to PUBLIC:


SELECT TABLE_NAME
FROM DBA_TAB_PRIVS P,DBA_OBJECTS O
WHERE P.OWNER=O.OWNER
AND P.TABLE_NAME = O.OBJECT_NAME
AND P.OWNER = 'SYS'
AND P.PRIVILEGE = 'EXECUTE'
AND P.GRANTEE = 'PUBLIC'
AND O.OBJECT_TYPE='PACKAGE';

3- Limit the users who have administrative privileges.
Grant administrative privileges to user accounts cautiously. Some powerful administrative privileges and roles to exercise caution with include the following:
SYSDBA Gives the grantee the highest level of privileges with the Oracle database software.
A clever user with the SYSDBA role can circumvent most database security measures.
أي مستخدم ذكي له دور SYSDBA يمكن أن يراوغ أكثر تدابير قاعدة البيانات أمناً.
There is usually no good reason to grant this role to any account except SYS, and the SYS password should be both cautiously guarded and changed regularly. Also guard operating system accounts carefully.
لا يوجد سبب منطقي لمنح هذا الدور لأي حساب فيما عدا (SYS)، وكلمة السر للمستخدم (SYS) يجب أن يتم حمايتها وتغييرها بحذر وبانتظام.
If you are logged on to the database server using a privileged operating system account, you might be able to connect to the database with SYSDBA authority and no password by entering connect / as sysdba in SQL*Plus.
DBA Permits the grantee to assign privileges and manipulate data throughout the database.
A clever user with the DBA role can circumvent most database security measures. Grant this role only to those users who need it.
The ANY system privileges SELECT ANY TABLE, GRANT ANY ROLE, DELETE ANY TABLE, and so on permit the grantee to assign privileges and manipulate data throughout the database.
A malicious user with the one of these roles can wreak havoc in your database. Grant
these privileges only to those users who need them.
4- Do not enable REMOTE_OS_AUTHENT.
The default setting for the initialization parameter REMOTE_OS_AUTHENT is FALSE. There is rarely a reason to enable this feature. When set to TRUE, this parameter tells the database to trust any client to authenticate externally authenticated
accounts.
الضبط الطبيعي للمعامل الابتدائي (REMOTE_OS_AUTHENT) هو (FALSE). نادراً ما يوجد سبب لتمكين هذه السمة. عند ضبطها لـ (TRUE) فإن هذا المعامل يخبر قاعدة البيانات بالوثوق في أي عميل للتصديق عليه خارجياً كحسابات مصادق عليها.
For example, if you have an externally identified account named ORACLE that has DBA privileges for use in administrative scripts running on the database server (a common practice), setting this parameter to TRUE will allow someone with a notebook or desktop PC with a locally created ORACLE account to connect to your database with DBA credentials and no password.
على سبيل المثال لو أنك تمتلك حساباً خارجياً محدداً بإسم (ORACLE) له امتيازات (DBA) لاستخدامها في تشغيل نصوص إدارية على خادم قاعدة البيانات. ضبط هذا المعامل ل(TRUE) سوف يسمح لواحد بكمبيوتر محمول أو جهاز كمبيوتر شخصي بحساب محلي تم إنشاؤه (ORACLE) بالاتصال بقاعدة البيانات بأوراق اعتماد (DBA) وبدون كلمة سر.

Managing Default User Accounts

The SYS and SYSTEM user accounts are always created with an Oracle 10g database. Additionally, the SYSMAN and DBSNMP accounts are created together with a database via the Database Configuration Assistant (DBCA).
Other special accounts may be created to support installed products, such as RMAN
(Recovery Manager) or XMLDB. When created via the DBCA, these special accounts are locked and expired, leaving only SYS, SYSTEM, SYSMAN, and DBSNMP open. The SYS and SYSTEM accounts are the data dictionary owner and an administrative account, respectively.
SYSMAN and DBSNMP are used by Enterprise Manager.
If your database is created via any means other than DBCA, ensure that the accounts are locked and expired, and that the default passwords are changed. You expire and lock an account using the ALTER USER statement like this:
ALTER USER mdsys PASSWORD EXPIRE ACCOUNT LOCK;
Depending on the functionality installed in your Oracle 10g database, you may need to lock and expire several default user accounts. Your database-created user accounts may include the following:
Csmig odm sysman
ctxsys odm_mtr system
dbsnmp olapsys tracesvr
demo ordplugins websys
dip ordsys wkproxy
dmsys outln wksys
exfsys perfstat wk_test
lbacsys rman wmsys
mddata scott xdb
mdsys si_informtn_schema xdm
oas_public sys


Implementing Standard Password Security Features
For users who are configured for database authentication, password security rules are enforced with profiles and password-complexity rules with verification functions. Profiles have a set of standard rules that define:
1- How long a password can remain valid,
2- The elapsed time,
3- The number of password changes before a password can be reused,
4- The number of failed login attempts that will lock the account, and
5- How long the account will remain locked.
للمستخدمين الذين يتم تهيئتهم للتوثيق من قبل قاعدة البيانات، فإن قواعد تأمين كلمات السر تفرض ببروفايلز وقواعد تعقيد كلمات السر مع قاعدة التحقق.
البروفايلز لها مجموعة من القواعد القياسية تحدد كالتالي:
1- كم من الوقت تبقى كلمة السر صالحة.
2- الوقت المنقضي.
3- عدد مرات تغيير كلمة السر قبل أن يمكن إعادة استعمالها.
4- عدد محاولات الاتصال الفاشلة التي تتسبب في إغلاق الحساب.
5- كم من الوقت يظل الحساب مغلق.
If you want a parameter to inherit the setting from the DEFAULT profile, set the parameter’s value to the keyword DEFAULT. Explicitly assign password rules to a profile using the CREATE PROFILE or ALTER PROFILE statement.
لو أردت لمتغير أن يرث الإعدادات من البروفايل (DEFAULT) قم بضبط قيمة المتغير بالكلمة الدليلية (DEFAULT)
صراحة قم بتخصيص قواعد كلمة السر لبروفايل باستخدام جملة (CREATE PROFILE) أو جملة (ALTER PROFILE).
These profile assignment statements support the following clauses to configure the standard password rules:
I- FAILED_LOGIN_ATTEMPTS and PASSWORD_LOCK_TIME
The FAILED_LOGIN_ATTEMPTS parameter specifies how many times in a row the user can fail password authentication.
يحدد هذا المتغير كم عدد المرات المتتالية يمكن أن يفشل فيها المستخدم في تحقق كلمة السر.
If this limit is breached, the account is locked for PASSWORD_LOCK_TIME days. If the PASSWORD_LOCK_TIME parameter is set to UNLIMITED and a user exceeds FAILED_LOGIN_ATTEMPTS, the account must be manually unlocked.
فإذا ماتم تعدي هذا الحد فإن الحساب يتم إغلاقه لعدد محدد من الأيام طبقاً لما جاء في المعامل (PASSWORD_LOCK_TIME)
ولو أن المعامل (PASSWORD_LOCK_TIME) تم ضبطه بالقيمة (UNLIMITED) وقام المستخدم بتجاوز المحاولات المسموح بالفشل فيها فإن الحساب يجب أن يعاد فتحه يدوياً.


You can set these parameters in a CREATE PROFILE or ALTER PROFILE statement like this:
-- lock account for 10 minutes if 3 consecutive logins fail
-- إغلاق الحساب لمدة 10 دقائق بعد 3 محاولات فاشلة متتالية.
CREATE PROFILE agent LIMIT
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 10/1440;
-- remove failed login restrictions
ALTER PROFILE student LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED;
-- manually unlock an account
ALTER USER scott ACCOUNT UNLOCK;
II- PASSWORD_LIFE_TIME and PASSWORD_GRACE_TIME
The PASSWORD_LIFE_TIME parameter specifies the maximum number of days that a password can remain in force, and the PASSWORD_GRACE_TIME is the number of days after the first successful login following password expiration, during which the user will be reminded to change their password, but allowed to log in.
يحدد المعامل (PASSWORD_LIFE_TIME) أقصى عدد من الأيام تظل فيه كلمة السر سارية بينما يحدد المعامل (PASSWORD_GRACE_TIME) عدد الأيام بعد أول محاولة دخول ناجحة تتبع بانتهاء كلمة السر وفي أثناء ذلك يتم إعلام المستخدم لتغيير كلمة السر الخاصة به بينما يسمح له بالدخول.
After the PASSWORD_GRACE_TIME limit is reached, the user must change their password.
بعد أن يصل المعامل (PASSWORD_GRACE_TIME) للحد فإن المستخدم يجب أن يغير كلمة السر الخاصة به.
If you set PASSWORD_LIFE_TIME to a value and set PASSWORD_GRACE_TIME to UNLIMITED, users will be reminded to change their password every time they log in, but never forced to actually do so.
إذا تم ضبط المعامل (PASSWORD_LIFE_TIME) بقيمة وأن المعامل (PASSWORD_GRACE_TIME) تم ضبطه بالقيمة (UNLIMITED) فإنه يتم تنبيه المستخدمين بتغيير كلمات السر في كل مرة عند دخولهم لكنهم لا يجبروا إطلاقاً على فعل ذلك.
You can set these two parameters in a CREATE PROFILE or ALTER PROFILE statement like this:
-- limit the password lifetime to 90 days
-- during the last 14 days the user will be reminded to change the password

-- تحديد عمر كلمة السر ب 90 يوماً

-- خلال الأربعة عشر يوماً الأخيرة يتم تنبيه المستخدم لتغيير كلمة السر.
CREATE PROFILE agent LIMIT
PASSWORD_LIFE_TIME 90 – 14
PASSWORD_GRACE_TIME 14;
-- set no limit to password lifetime
-- ضبط عمر كلمة السر بلا حد.
ALTER PROFILE student LIMIT
PASSWORD_LIFE_TIME UNLIMITED
PASSWORD_GRACE_TIME DEFAULT;
III- PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX
The PASSWORD_REUSE_TIME parameter specifies the minimum number of days that must transpire before a password can be reused.
يحدد المعامل (PASSWORD_REUSE_TIME) أقل عدد من الأيام يجب أن تمر قبل أن يمكن إعادة استخدام كلمة السر.
PASSWORD_REUSE_MAX specifies the minimum number of password changes that must occur before a password can be reused.
If you specify a value for one of these two parameters and UNLIMITED for the other, passwords can never be reused.
يحدد المعامل (PASSWORD_REUSE_MAX) أقل عدد من مرات تغيير كلمة السر يجب أن يحدث قبل أن يعاد استخدامها.
إذا تم تحديد قيمة لأحد هذين المعاملين وتم ضبط الآخر بالقيمة (UNLIMITED) فإن كلمة السر لا يمكن إعادة استخدامها مطلقاً.
If you set both PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX to UNLIMITED, these parameters are essentially disabled.
إذا تم ضبط كلا المعاملين (PASSWORD_REUSE_TIME) و (PASSWORD_REUSE_MAX) بالقيمة (UNLIMITED) فإنهما بالأساس قد تم تعطيلهما.
You can set these password parameters in a CREATE PROFILE or ALTER PROFILE statement like this:
-- require at least 4 password changes and 1 year
-- before a password may be reused.
-- لطلب تغيير كلمة السر 4 مرات وعاماً واحداً قبل إعادة استخدام كلمة السر.
CREATE PROFILE agent LIMIT
PASSWORD_REUSE_TIME 365
PASSWORD_REUSE_MAX 4;
-- remove password reuse constraints
-- لإزالة القيود على إعادة استخدام كلمة السر.
ALTER PROFILE student LIMIT
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED;
Several password attributes are durations expressed in days. These durations are normally set with integer values, such as 30, 90, or 365 days. But decimal values are supported as well. You can set the password timeout to 5 minutes (5/1,440 days) or 5 seconds (5/86,400 days).
Using a fractional number of days is a great way to try out combinations of values and observe the results of setting these password rules.
عدة خواص لكلمات السر هي المدد الزمنية يتم التعبير عنها بالأيام. هذه المدد الزمنية من الطبيعي ضبطها بقيم صحيحة مثل 30، 90، 365 يوماً. لكن القيم العشرية مدعمة أيضاً. يمكن ضبط الفاصل الزمني بخمس دقائق (5/1,440 days) أو خمس ثواني (5/86,400 days).
استخدام رقم كسر من الأيام هو طريقة عظيمة لتجربة توليفة من القيم وملاحظة النتائج بضبط قواعد كلمة السر هذه.


IV- PASSWORD_VERIFY_FUNCTION
The PASSWORD_VERIFY_FUNCTION parameter lets you codify additional rules that will be verified when a password is changed. These rules usually verify password complexity such as minimal password length or check that a password does not appear in a dictionary.
يمكنك هذا المعامل (PASSWORD_VERIFY_FUNCTION) من تصنيف قواعد إضافية يتم التحقق منها عند تغيير كلمة السر. هذه القواعد عادة تحقق تعقيد كلمة السر مثل أقل طول لكلمة السر أو التأكد أن كلمة السر لاتظهر في القاموس.
The PASSWORD_VERIFY_FUNCTION must be created under the user SYS and must have three pass parameters of type VARCHAR2. These pass parameters must contain the username in the first parameter, the new password in the second, and the old password in the third.
يجب أن يتم إنشاء هذا المعامل (PASSWORD_VERIFY_FUNCTION) تحت المستخدم (SYS) كما يجب أن يمتلك ثلاثة متغيرات من النوع (VARCHAR2) هذه المتغيرات يجب أن تحتوي على اسم المستخدم في المتغير الأول، كلمة السر الجديدة في المتغير الثاني، و كلمة السر الأخيرة في الثالث.
You can set this parameter in a CREATE PROFILE or ALTER PROFILE statement like this:
-- use a custom password function
CREATE PROFILE agent LIMIT PASSWORD_VERIFY_FUNCTION my_function;
-- disable use of a custom function
ALTER PROFILE student LIMIT PASSWORD_VERIFY_FUNCTION DEFAULT;

Real World Scenario

Implementing a Corporate Password Security Policy
Many companies have security policies requiring that several password complexity rules be followed. For your Oracle 10g database, these rules can be incorporated into a password verify function. Here is an example of three password-complexity requirements and how they are satisfied through a password verify function named MY_PASSWORD_VERIFY.

The first rule:
specifies that the password must be at least six characters in length.

The second rule:
disallows passwords containing some form of either the username or the
word password.
The third rule:
requires the password to contain at least one alphabetic character,
at least one digit, and at least one punctuation character.

If the new password fails any of these tests, the function raises an exception, and the password change fails.

After creating this function as user SYS, assign it to a profile, like this:
ALTER PROFILE student LIMIT password_verify_function my_password_verify;
Any user having the student profile will have to abide by the password rules enforced by the my_password_verify function:
CREATE OR REPLACE FUNCTION my_password_verify
(username VARCHAR2
,password VARCHAR2
,old_password VARCHAR2
) RETURN BOOLEAN
IS
BEGIN
-- Check for the minimum length of the password
IF LENGTH(password) < 6 THEN
raise_application_error(-20001
,'Password must be at least 6 characters long');
END IF;
-- Check that the password does not contain any
-- upper/lowercase version of either the user name
-- or the keyword PASSWORD
IF ( regexp_like(password,username,'i')
OR regexp_like(password,'password','i')) THEN
raise_application_error(-20002
,'Password cannot contain username or PASSWORD');
END IF;
-- Check that the password contains at least one letter,
-- one digit and one punctuation character
IF NOT( regexp_like(password,'[[:digit:]]')
AND regexp_like(password,'[[:alpha:]]')
AND regexp_like(password,'[[:punct:]]')
) THEN
raise_application_error(-20003
,'Password must contain at least one digit '||
'and one letter and one punctuation character');
END IF;
-- password is okey dokey
RETURN(TRUE);
END;
/

Auditing Database Activity
Auditing involves monitoring and recording specific database activity. An Oracle 10g database supports four levels of auditing and affords you two locations for recording these activities.
تشتمل المراقبة على مراقبة و تسجيل نشاط معين لقاعدة البيانات. تدعم قاعدة بيانات أوراكل 10g أربع مستويات من المراقبة كما تقدم لك مكانين لتسجيل هذه الأنشطة.
Audit records can be stored in the database or in operating system files for greater security. You tell the database where to record audit trail records by setting the initialization parameter audit_trail. The default is NONE.
AUDIT_TRAIL=DB tells the database to record audit records in the database.
مراقبة السجلات يمكن تخزينها في قاعدة البيانات أو في ملفات نظام التشغيل لمزيد من السرية. أنت تخبر قاعدة البيانات أين تسجل أثر مراقبة السجلات بضبط المعامل الابتدائي (audit_trail). المعرف الأساسي هو (NONE) .
عند ضبط المعامل الابتدائي ب (DB) كالتالي: AUDIT_TRAIL=DB فإن ذلك يخبر قاعدة البيانات بتسجيل السجلات في قاعدة البيانات.
AUDIT_TRAIL=DB_EXTENDED tells the database to record audit records in the
database together with bind variables (SQLBIND) and the SQL statement triggering the audit entry (SQLTEXT).
عند ضبط المعامل الابتدائي بـ (DB_ EXTENDED) كالتالي:
AUDIT_TRAIL=DB_ EXTENDED فإن ذلك يخبر قاعدة البيانات بتسجيل سجلات المراقبة في قاعدة البيانات سوياً مع إحضار المتغيرات (SQLBIND) وجمل إس كيو إل التي تطلق زناد مدخلات المراقبة (SQLTEXT) .
AUDIT_TRAIL=OS tells the database to record audit records in operating system files. You cannot change this parameter in memory, only in your PFILE or SPFILE.
عند ضبط المعامل الابتدائي بـ (DB_ OS) كالتالي:
AUDIT_TRAIL=DB_OS فإن ذلك يخبر قاعدة البيانات بتسجيل سجلات المراقبة في ملفات نظام التشغيل.
لا يمكنك تغيير هذا المعامل في الذاكرة، فقط في ملف المعاملات أو ملف معاملات الخادم. كالتالي:
For example, the following statement will change the location of audit records in the SPFILE:
ALTER SYSTEM SET audit_trail=DB SCOPE=SPFILE;

After changing the audit_trail parameter, you will need to bounce (shut down and start up) your database instance for the change to take effect.
When recorded in the database, most audit entries are recorded in the SYS.AUD$ table. On Unix systems, operating system audit records are written into files in the directory specified by the initialization parameter audit_file_dest (which defaults to $ORACLE_HOME/rdbms/audit).
On Microsoft Windows systems, these audit records are written to the Event Viewer log file.
The four levels of auditing:
1- STATEMENT,
2- PRIVILEGE,
3- OBJECT,
4- FINE-GRAINED ACCESS.
are described in detail in the following sections.
SQL> select USERID, OBJ$NAME, TIMESTAMP#, SQLTEXT from SYS.AUD$;

USERID OBJ$NAME
TIMESTAMP SQLTEXT
------------------------------ ----------------------------------
--------------------------------------- --------- ---------------
----------
HEIMA HEIMA
HEIMA HEIMA
HEIMA HEIMA
HEIMA HEIMA
HEIMA AZIMA
HEIMA TEST
HEIMA TEST

7 rows selected.
www.facebook.com/awal.satr
SQL>

Managing Statement Auditing
Statement auditing involves monitoring and recording the execution of specific types of SQL statements. In the following sections, you will learn how to enable and disable statement auditing as well as identify what statement auditing options are enabled.
تشتمل مراقبة الجمل على مراقبة وتسجيل تنفيذ أنواع معينة من جمل (SQL). في الأقسام التالية سوف تتعلم كيف تمكن وتعطل مراقبة الجمل وأيضاً تحديد أي اختيارات مراقبة الجمل يتم تمكينها.
Enabling Statement Auditing
You enable auditing of specific SQL statements with an AUDIT statement. For example, to audit the SQL statements CREATE TABLE, DROP TABLE, or TRUNCATE TABLE, use the TABLE audit option like this:
على سبيل المثال، لكي تراقب جمل (SQL) (CREATE TABLE, DROP TABLE, or TRUNCATE TABLE) استخدم اختيار (TABLE audit) كالتالي:
AUDIT table;
To record audit entries for specific users only, include a BY USER clause in the AUDIT statement.
For example, to audit CREATE, DROP, or TRUNCATE TABLE statements for user Heima only, execute the following:
لكي تسجل مدخلات المراقبة لمستخدمين محددين فقط ، قم بتضمين عبارة (BY USER) في جملة (AUDIT).
فعلى سبيل المثال لمراقبة جمل (CREATE, DROP, or TRUNCATE TABLE) للمستخدم (Heima) نفذ الآتي:
AUDIT table BY Heima;
Frequently, you want to record only attempts that fail—perhaps to look for users who are probing the system to see what they can get away with. To further limit auditing to only these unsuccessful executions, use a WHENEVER clause like this:
كثيرا ما تريد تسجيل المحاولات الفاشلة فقط ربما للبحث عن المستعملين الذين يتقصّون النظام لرؤية ما يمكن أن يفلتوا به بدون عقاب. إلى حدّ بعيد لمراقبة المحاولات غير الناجحة فقط ، استعمل العبارة (WHENEVER) كالتالي:
AUDIT table BY Heima WHENEVER NOT SUCCESSFUL;
You can alternately specify WHENEVER SUCCESSFUL to record only successful statements.
عوضاً عن ذلك حدد العبارة (WHENEVER SUCCESSFUL) لتسجل فقط الجمل الناجحة.
AUDIT table BY Heima WHENEVER SUCCESSFUL;
If you do not include a WHENEVER clause, both successful and unsuccessful statements trigger audit records.
إذا لم تضمن عبارة (WHENEVER) فإن زناد كلاً من الجمل الناجحة وغير الناجحة يقوم بمراقبة السجلات.


You can further configure non-DDL statements to record one audit entry for the triggering session or one entry for each auditable action during the session.
يمكن أن تهيئ جمل (non-DDL) لتقوم بتسجيل سجل مراقبة واحد لزناد جلسة اتصال أو إدخال واحد لكل فعل قابل للمراقبة خلال الجلسة.
Specify BY ACCESS or BY SESSION in the AUDIT statement, like this:
AUDIT INSERT TABLE BY Heima BY ACCESS;
There are many auditing options other than TABLE or INSERT TABLE. Table 6.1 shows all of the statement auditing options.

Identifying Enabled Statement Auditing Options
You can identify the statement auditing options that have been enabled in your database by querying the DBA_STMT_AUDIT_OPTS data dictionary view.
يمكن أن تحدد اختيارات جملة المراقبة التي تم تمكينها في قاعدة بياناتك بالاستعلام(DBA_STMT_AUDIT_OPTS)
For example, the following example shows that SESSION auditing is enabled for all users, NOT EXISTS auditing is enabled for all users, and TABLE auditing WHENEVER NOT SUCCESSFUL is enabled for user juanita:
<a name="OLE_LINK3">SELECT audit_option, failure, success, user_name
FROM dba_stmt_audit_opts
ORDER BY audit_option, user_name;

Disabling Statement Auditing
To disable auditing of a specific SQL statement, use a NOAUDIT statement, which allows the same BY and WHENEVER options as the AUDIT statement. If you enable auditing for a specific user, specify that user in the NOAUDIT statement as well.
However, it is not necessary to include the WHENEVER NOT SUCCESSFUL clause in the NOAUDIT statement.
For example, to disable the three audit options in the previous section, execute the following three statements:
NOAUDIT session;
NOAUDIT not exists;
NOAUDIT table BY Heima;
Examining the Audit Trail
Statement, privilege, and object audit records are written to the SYS.AUD$ table and made available via the data dictionary views DBA_AUDIT_TRAIL and USER_AUDIT_TRAIL. These data dictionary views may not contain values for every record because this view is used for three different types of audit records. For example, you can view the user, time, and type of statement audited for user Heima by executing the following:
SELECT username, timestamp, action_name
FROM dba_audit_trail
WHERE username = 'Heima';
TIP If you enable AUDIT SESSION, the database creates one audit record when a user logs on and updates that record when the user logs off successfully.
إذا قمت بتفعيل (AUDIT SESSION) فإن قاعدة البيانات تقوم بإنشاء سجل مراقبة واحد عندما يسجل المستخدم الدخول كما تقوم بتحديث هذا السجل عندما يسجل المستخدم الخروج.
These session audit records contain some valuable information that can help you narrow the focus of your tuning efforts. Among the information recorded in the audit records are the username, logon time, logoff time, and the number of physical reads and logical reads performed during the session.
By looking for sessions with high counts of logical or physical reads, you can identify high-resource-consuming jobs and narrow the focus of your tuning efforts.