اخوتى ال DBA ارجو المساعدة ....
كيف امنع اى User من الدخول على قاعدة البيانات باستخدام برامج مساعدة ليست من انتاج Oracle على سبيل المثال برنامج مثل الTOAD . اعرف ان هناك جدول من جداول الDictionary يتبع sys يمكن منه ايقاف الدخول من SQL ولكن هذه الطريقة لاتنجح مع البرامج المنتجة بواسطة شركة غير اوراكل. ارجو الافادة عاجلا. وشكرا

SEARCH FOR A DICTIONARY TABLE CALLED SYS.PRODUCT_USER_PROFILE
AND INSERT THE USER ID ON THAT TABLE

اخى ابو عزت . . شكرا على سرعة الرد ولكنى اوضح شيئا
اريد المستخدم ان يتصل بقاعدة البيانات عن طريق فورمة Login انا عاملها ثم من خلالها الدخول الى باقى التطبيقات (حسابات و مخازن و...). وفى نفس الوقت اريد ان امنع المستخدم من الدخول الى قاعدة البيانات عن طريق برنامج ال TOAD.

Can PRODUCT_USER_PROFILE be used to limit access to a database from products other than SQL*Plus, such as TOAD?

No, the PRODUCT_USER_PROFILE table is read by SQL*Plus and it is not employed by the database in any way. The features enabled or disabled by the entries in the PRODUCT_USER_PROFILE table only apply when using the SQL*Plus tool and do not apply when using any other tool to connect to the database. This is covered in the 9.2.0 documentation on SQL*PLus in this excerpt:
DBAs can use the PUP table to disable certain SQL and SQL*Plus commands in the SQL*Plus environment on a per-user basis. SQL*Plus--not the database--enforces this security. DBAs can even restrict access to the GRANT, REVOKE, and SET ROLE commands to control users' ability to change their database privileges.

المصدر:
http://expertanswercenter.techtarget.com/e...i977714,00.html

إليك حــل مبدئي:
قم بعمل Trigger يعمل على قتل الـSession التي تُـخلق عن طريق TOAD !!

يمكن للـTrigger أن يعرف المعلومة من v$session:

SELECT sid, serial#, program FROM v$session;

من المفترض أن تكون قيمة program تساوي TOAD.exe

تم تعديل 13 سبتمبر 200520 سنة بواسطة عروة

شكرا عروة لتفاعلك بالموضوع.. وقد حفذنى ردك للبحث عن trigger مناسب لوضع جملة ال Kill session بداخله ووجدت ان هناك Trigger يمكن عمله على مستوى db ككل وليس على مستوى جدول فقط وهذه صيغته المبدئية لحين ان اجربه واوافيكم بالنتائج

CREATE TRIGGER my_check AFTER LOGON ON my_database
Begin
/*some code to kill session*/
end;

تم تعديل 14 سبتمبر 200520 سنة بواسطة kash

اخوي kash شو صار معك بالنسبة للكود جربته؟؟؟؟ وايش هو لاني محتاجه ضروري ؟؟؟؟ لاني ما بدي اخلي لـuser يدخل من الـtoad . ضروري اعملني اياه

الاخوة الافاضل ...
لقد قمت بكتابة الكود فى ال Trigger ولكن قابلتنى مشكلة ارجو من خبراء الDBA مساعدتى فيها لكى استكمل الحل وتعم الفائدة لى وللاخ yamar911 والمشكلة هى ان الTrigger لم يتعرف على الV$SESSION ويعطى Table or view does not exist
مع العلم انه عند الدخول بنفس المستخدم الذى يحاول انشاء الTrigger عند الدخول به على DB بواسطة SQL فأنى استطيع ان اعمل desc V$SESSION وايضا استطيع ان اعمل Select منه.
فلماذا استطيع ذلك من SQL ولا استطيع رؤيته من داخل جملة انشاء الtrigger?

جرب استخدام sys.v$_session

تم تعديل 18 سبتمبر 200520 سنة بواسطة chayah

السلام عليكم

عملت تجربة للكود الآتى ولكن لم يفلح

[/code]
CREATE OR REPLACE TRIGGER my_check AFTER LOGON ON my_database
sd varchar2(100);
ser varchar2(100);
Begin
SELECT sid, serial# into sd,ser FROM sys.v$session where MODULE='T.O.A.D.';
ALTER SYSTEM KILL SESSION sd||','||ser;
end;

CREATE OR REPLACE TRIGGER no_toad AFTER LOGON ON  DATABASE
DECLARE
modul varchar2(100);
Begin
SELECT module into modul FROM v$session where MODULE='T.O.A.D.';
IF modul='T.O.A.D.'  THEN
  RAISE_APPLICATION_ERROR (-20001, 'You are not allowed to logon from TOAD');
  END IF;
end;

جربوا هذا الـTrigger .. أخوكم اشتغل معاه
بس ما ظهر لي رسالة الـERROR الموضحة أعلاه ! إنما ظهـر رسالة خاصة بـTOAD والتي ظهـر فيها إسم الـTrigger نفسه !!

بصراحة أخوكم علاقته حالياً بالـPL/SQL ضعيفة .. وتعبت جداً عشان أشغل الـTriggrt هذا..
على العموم إذا استطاع أحدكم أن يظهر لنا الخطأ المبين أعلاه دون أن يظهر لمستخدم TOAD معلومات سرية (مثل إسم الـTrigger المتحكم في منعه) ياريت يخبرنا ..

السلام عليكم
MODULE لن يعطيك معلومات عن اسم البرنامج .. حيث ستكون قيمته خاليه ...
بل يعطيك اسم البرنامج بعد الدخول على البرنامج .. وبذلك لن يراه ال trigger

يمكن استخدام program بدل MODULE

ولكن يمكن التحايل على ذلك بتغيير اسم ال toad إلى اي اسم آخر

وبذلك أعتقد أنه من المستحيل تطبيق ما هوه مطلوب

للأسف ، كنت متوهماً أن الـTriggrt قد منع دخول TOAD !!
لكني اكتشفت أنني منعت دخول أي مستخدم من الدخول لقاعدة البيانات !! وذلك لعدم تفاعل الـTriggrt بسبب محاولة استرجاع معلومات من V$SESSION والتي لا يمكن استرجاعها إلا عن طريق مستخدم له صلاحية ذلك (مثل SYS و SYSTEM) .. وبالفعل استطعت استخدام TOAD عن طريق المستخدمSYSTEM دون اعتراض !! وهذا يدل على صحة المعلومة التي أشارت لها الأخت عزة:

MODULE لن يعطيك معلومات عن اسم البرنامج .. حيث ستكون قيمته خاليه ... بل يعطيك اسم البرنامج بعد الدخول على البرنامج .. وبذلك لن يراه ال trigger

لكن رغم ذلك .. لا أعتقد أنه من الصعب تطبيق ما هو مطلوب

وللحديث بقية . . .

يبدو يا عزة أن قيمة MODULE مش لوحدها خالية أثناء إطلاق الـTrigger !!

فقد ثبت لي - بعد إجراء بعض التجارب - أن الـTriggger أدناه يُطلق قبل أن يحرر الأوراكل سيرفر Session_id للـConnection الجديد!! أي أن السجل الخاص بالـConnection الجديد لن يضاف أصلاً إلى الجدول V$SESSION قبل إطلاق الـTrigger !!

CREATE OR REPLACE TRIGGER KILL_TOAD AFTER LOGON ON  DATABASE
DECLARE
SERIAL NUMBER(4);
BEGIN
SELECT SERIAL# INTO SERIAL FROM V$SESSION WHERE SID=152;
EXECUTE IMMEDIATE 'ALTER SYSTEM KILL SESSION '||''''||152||','||SERIAL||'''';
END;

واضح من الـCode أعلاه أن التجربة مبنية على التخمين .. لكن التخمين زبط معايه - كيف ؟؟ ده موضوع تاني !!

الخلاصــة: إذا كانت المعلومة المذكورة أعلاه صحيحة !! إذاً من المستحيل منع دخول TOAD بهذه الطريقة (أي عن طريق AFTER LOGON ON DATABASE )

ها يا شباب . . . إتلحلحو شويه .. فين أهل الخبرة ؟؟؟

يبدو يا عزة أن قيمة MODULE ليست وحدها خالية أثناء إطلاق الـTrigger !!

فقد ثبت لي - بعد إجراء بعض التجارب - أن الـTriggger أدناه يُطلق قبل أن يحرر الأوراكل سيرفر Session_id للـConnection الجديد!! أي أن السجل الخاص بالـConnection الجديد لن يضاف أصلاً إلى الجدول V$SESSION قبل إطلاق الـTrigger !!

CREATE OR REPLACE TRIGGER KILL_TOAD AFTER LOGON ON  DATABASE
DECLARE
SERIAL NUMBER(4);
BEGIN
SELECT SERIAL# INTO SERIAL FROM V$SESSION WHERE SID=152;
EXECUTE IMMEDIATE 'ALTER SYSTEM KILL SESSION '||''''||152||','||SERIAL||'''';
END;

واضح من الـCode أعلاه أن التجربة مبنية على التخمين .. لكن التخمين زبط معايه - كيف ؟؟ ده موضوع تاني !!

الخلاصــة: إذا كانت المعلومة المذكورة أعلاه صحيحة !! إذاً من المستحيل منع دخول TOAD بهذه الطريقة (أي عن طريق AFTER LOGON ON DATABASE )

ها يا شباب . . . إتلحلحو شويه .. فين أهل الخبرة ؟؟؟
هوه أكيد في حل . . . يمكن الموضوع ماراح يتحل بـKill Session ؟؟
مين عارف ؟

أخي عروة .. مافي حل لهذا الموضوع
فقد حاولت مرارات حل هذه المسألة دون جدوى

إذا في حد يعرف الحل يخبرنا

شكرا لتفاعل الاخوة والاخوات اعضاء المنتدى واخص بالذكر عروة وعزة ...
ربما يكون هناك حل أخر غير ال DataBase trigger فلماذا نحصر تفكيرنا فى هذا الموضوع.
اعتقد ان هناك حل اكيد لانه لايمكن لمنتج ضخم مثل اوراكل ان يتم اختراق قاعده بياناته بمثل هذه السهولة. والحل اكيد عند واحد DBA شاطر ونحن ننتظر منه هذه المشاركة نظرا لاهمية وجدة الموضوع.

أخواني: ماهي المشكلة بالضبط ولماذا تريد منع الدخول من برنامج مثل toda إذا كان يمكن للمستخدم الدخول من خلال sql*plus والقيام بنفس العمليات.
إذا كان المستخدم يعرف كلمة السر (فهو مؤهل للدخول إلى حسابه) من أي برنامج
سؤالي هل هذا الشيء مطلوب وواقعي يحتاج إلى حل لعلنا نستطيع المشاركة في إيجاد حل له؟ أم أن مجرد مثال!

أخي وجهة نظرك سليمة مئة بالمئة
فلو فرضنا أننا نريد منع المستخدم من استعمال ال toad فسيدخل بال sqlplus
ولو منعناه سيدخل بال plsql developer
أو Golden
أو ...... وهناك العديد من البرامج لها نفس الغرض

إخواني وأخواتي الأعزاء
أعتقد أن الحل النهائي بنسبة 99% عن طريق ال ROLES
1- CREATE ROLE MY_ROLE IDENTIFIED BY 123;
2- GRANT SELECT,UPDATE,INSERT,DELETE ON MY_TABLE TO MY_ROLE;
3- CREATE USER USER1 IDENTIFIED BY USER123;
4- GRANT CONNECT,CREATE SESSION TO USER1;
4- GRANT MY_ROLE TO MY_USER;

SO ALAWYS WHEN USER1 WANT TO LOGIN TO THE DATABASE HE NEEDS THE PASSWORD
WHATEVER FROM ORACLE PRODUCTS OR OUTSIDE ORACLE PRODUCTS LIKE TOAD
لاتنسونا بالدعاء

نسيت هذه الخطوة وعليكم إضافتها بعد الخطوة رقم 4
ALTER USER USER1 DEFAULT ROLE ALL EXCEPT MY_ROLE;

جزاك الله خيراً اخي الكريم و زادك علماً

ردا على تساؤلات الاخ chayah واقتراحات الاخ abu_ezzat فانى لتوضيح المشكلة اعطى المثال البسيط التالى: لنفترض ان هناك جدول للعملاء يحتوى على كود واسم العميل وبيانات عن قيمة مشترياته وقيمة سداداته.
table cust_data
---------------------------
cust_code number
tot_sal number
tot_pay number
ونفترض ان مستخدم user2 له الصلاحية select , insert, update , delete على هذا الجدول.
الوضع الصحيح ان يدخل user2 من برنامج اصدار الفواتير الذى يقوم بزيادة حقل tot_sal وان يدخل برنامج تحصيل النقدية الذى يقوم بزيادة حقل tot_pay بحيث فى اى لحظة نطبع تقرير عن العميل نحصل على بيانات صحيحة.
لنفترض الان ان user2 غير امين على صحة لبيانات لسبب او لاخر وان عنده برنامج Toad, or Golden, or...others فهل ستمنعه الRoles التى اقترحها الاخ abu_ezzat من الدخول على مثل هذه البرامج وتعديل قيم الحقول المذكورة؟
وتلخيصا لما سبق , الموضوع فى غاية الاهمية وواقعى لانى اريد ان اعطى صلاحيات على جداول معينة لمستخدم بشرط ان يؤثر فيها من خلال قواعد عمل مدروسة وموضوعة فى البرامج المتاح له العمل عليها (مثل شاشة اصدار الفاتورة والسداد النقدى و...) وللمحافظة على هذه القواعد لابد ان يمنع المستخدم من التأثير على الجداول مباشرة من البرامج الاخرى مثل Toad.
ارجو ان اكون اوضحت الهدف من السؤال.

CONNECT / AS SYSDBA;

CREATE OR REPLACE TRIGGER block_toad_from_prod
AFTER LOGON ON DATABASE
DECLARE
v_prog sys.v_$session.program%TYPE;
BEGIN
SELECT program INTO v_prog FROM sys.v_$session
WHERE audsid = USERENV('SESSIONID')
AND audsid != 0 -- Don't Check SYS Connections
AND rownum = 1; -- Parallel processes will have the same AUDSID's

IF UPPER(v_prog) LIKE '%TOAD%' OR UPPER(v_prog) LIKE '%T.O.A.D%' THEN
RAISE_APPLICATION_ERROR(-20000, 'Toad users not allowed on PROD DB!');
END IF;
END;
/
SHOW ERRORS


try this

i hope it will help you

regards

يبدو يا عزة أن قيمة MODULE ليست وحدها خالية أثناء إطلاق الـTrigger !!

فقد ثبت لي - بعد إجراء بعض التجارب - أن الـTriggger أدناه يُطلق قبل أن يحرر الأوراكل سيرفر Session_id للـConnection الجديد!! أي أن السجل الخاص بالـConnection الجديد لن يضاف أصلاً إلى الجدول V$SESSION  قبل إطلاق الـTrigger !!
.
.
.
.
الخلاصــة: إذا كانت المعلومة المذكورة أعلاه صحيحة !! إذاً من المستحيل منع دخول TOAD بهذه الطريقة (أي عن طريق AFTER LOGON ON  DATABASE )

ها يا شباب . . . إتلحلحو شويه    .. فين أهل الخبرة ؟؟؟
هوه أكيد في حل . . . يمكن الموضوع ماراح يتحل بـKill Session ؟؟
مين عارف ؟ 

48002[/snapback]

يا سلام عليك يا enrique2k ..

طلعت التجارب اللي عملها أخوك صفر على الشمال .. عشان كده لازم أقوي علاقتي شويه مع الـPL/SQL علشان كمان ماطلعـش DBA على الشمال وربنا يستر . . .

لكن في شيئ غريب حصل معي ! أتمنى أن أجد له تفسير عندكم .. وهو أنني عدلت في الـTrigger بحيث يسترجع قيمة MODULE بدلاً من PROGRAM .. وبعدها قمت بتغيير إسم الملف التنفيذي إلى abc.exe ، عندها لم يستطع الـTrigger منع البرنامج من الدخول إلى القاعدة (حينها تأكدت أن كلام الأخت aza مضبوط 100%)

ـ MODULE لن يعطيك معلومات عن اسم البرنامج .. حيث ستكون قيمته خاليه ...

.. لــكن عندما رجعت إسم ملف التنفيذ إلى TOAD.exe إستطاع الـTrigger منعه من استخدام القاعدة !!!!.. على الرغم من أنني ما زلت أستخدم قيمة MUDULE بدلاً من PROGRAM !!

ملحوطة: المستخدم الذي استخدمته للدخول عن طريق TOAD هو "HR"

تم تعديل 3 أكتوبر 200520 سنة بواسطة عروة