DBA ARABIC

ﻤﺭﺍﻗﺒﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻫﻭ ﺠﺯﺀ ﻤﻥ ﺘﺄﻤﻴﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻨﺴﺘﻁﻴﻊ ﻤﻥ ﺨﻼل ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺇﻴﺠﺎﺩ ﻜﺜﻴﺭ ﻤﻥ ﺍﻹﺠﺎﺒﺎﺕ ﻟﺒﻌﺽ ﺍﻷﻤﻭﺭ ﺍﻟﺘﻲ ﺴﺘﻅل ﻏﺎﻤﻀﺔ ﻟﻭﻻ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ،

ﻭﻴﻤﻜﻥ ﺘﻘﺴﻴﻡ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺇﻟﻰ ﺜﻼﺙ ﺃﻨﻭﺍﻉ :-

1- Standard Database Auditing:

ﻭﻫﻭ ﻟﻤﺘﺎﺒﻌﺔ ﻭﺤﻔﻅ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﻋﻤﻠﻴﺎﺕ ﺍﻻﺘﺼﺎل ﻭﻗﻁﻊ ﺍﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ، ﻭﺃﻴﻀﺎﹰ ﻤﺘﺎﺒﻌﺔ ﺍﺴﺘﺨﺩﺍﻡ (Object Privileges and System Privileges)

ﺩﺍﺨل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ، ﻜﻌﻤﻠﻴﺎﺕ ﺍﻹﻨﺸﺎﺀ ﻭﺍﻟﺤﺫﻑ ﻭﺍﻻﺴﺘﻌﻼﻡ ﻭﺍﻟﺘﻌﺩﻴل ﻭﻏﻴﺭﻩ ﻤﻥ ﺍﻟﻌﻤﻠﻴﺎﺕ.

2 - Value-based auditing: ﻓﻲ ﺍﻟﻨﻭﻉ ﺍﻷﻭل ﺘﺎﺒﻌﻨﺎ ﻋﻤﻠﻴﺎﺕ ﺍﻻﺘﺼﺎل ﻭﻜﺫﻟﻙ ﻤﺘﺎﺒﻌﺔ ﺍﻟﻌﻤﻠﻴﺎﺕ ﺩﺍﺨل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ، ﻭﻟﻜﻥ ﻗﺩ ﻨﺤﺘﺎﺝ ﻟﻠﺤﻔﺎﻅ ﻋﻠﻲ ﺍﻟﻘﻴﻡ ﺍﻟﺘﻲ ﻴﺘﻡ ﺘﻐﻴﺭﻫﺎ ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.

3 - Fine-grained auditing: ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻟﺤﻔﻅ ﻋﺒﺎﺭﺍﺕ ﺍلSQL ﺍﻟﺘﻲ ﺘﻡ ﺘﻨﻔﻴﺫﻫﺎ ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.

ﻭﻟﻜﻥ ﻗﺒل ﺍﻟﺘﻔﺼﻴل ﻓﻲ ﺃﻨﻭﺍﻉ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻻﺒﺩ ﻤﻥ ﺍﻹﺸﺎﺭﺓ ﺇﻟﻲ ﺃﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻭﺭﻜل 10g ﻻﺒﺩ ﻤﻥ ﺘﻬﻴﺌﺘﻬﺎ ﻗﺒل ﺍﻟﺒﺩﺀ ﻓﻲ ﻋﻤﻠﻴﺎﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺘﻐﻴﺭ AUDIT_TRAIL ﺍﻟﺫﻱ ﻴﺄﺨﺫ ﺃﺤﺩ ﺍﻟﻘﻴﻡ ﺍﻟﺘﺎﻟﻴﺔ :-

1 - NONE: ﻭﻫﻰ ﺘﻌﻨﻰ ﺃﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻏﻴﺭ ﺠﺎﻫﺯﺓ ﻟﻌﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ.

2- DB: ﻭﻫﻰ ﺘﻌﻨﻰ ﺃﻥ ﻤﻌﻭﻤﺎﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻴﺘﻡ ﺤﻔﻅﻬﺎ ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻲ ﺠﺩﺍﻭل ﺘﻨﺘﻤﻲ ﻟﻠﻤﺴﺘﺨﺩﻡ SYS .

3 - :OS ﻭﻫﻰ ﺘﻌﻨﻰ ﺃﻥ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻴﺘﻡ ﺤﻔﻅﻬﺎ ﻋﻠﻰ ﻤﺴﺘﻭﻯ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل، ﻓﺈﺫﺍ ﻜﻨﺎ ﻨﻌﻤل ﻋﻠﻰ ﺒﻴﺌﺔ ﻭﻴﻨﺩﻭﺯ Widows ﻓﺎﻥ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺘﺤﻔﻅ ﻓﻲ ﺍلLog Event،

ﺃﻤﺎ ﺇﺫﺍ ﻜﻨﺎ ﻨﻌﻤل ﻋﻠﻰ UNIX or LINUX ﻓﺈﻥ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﺘﺨﺯﻥ ﻜﻤﻠﻔﺎﺕ ﻓﻲ ﺍﻟﻤﺴﺎﺭ ﺍﻟﻤﺤﺩﺩ ﻋﻠﻰ ﺍﻟﻤﺘﻐﻴﺭ AUDIT_FILE_DEST .

ﺍﻹﺼﺩﺍﺭ ﺍﻭﺭﻜل 10gﻴﺩﻋﻡ ﻤﺨﺘﻠﻑ ﺃﻨﻭﺍﻉ ﺍﻟﻤﺭﺍﻗﺒﺔ، ﺒﺤﻴﺙ ﻴﺴﺘﻁﻴﻊ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﺭﺍﻗﺒﺔ ﻜل ﻤﺎ ﻴﺤﺩﺙ ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ، ﺘﺨﻴﻠﺕ ﻤﻌﻲ ﺤﺠﻡ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﻲ ﻴﺘﻡ ﺘﺨﺯﻴﻨﻬﺎ ﺇﺫﺍ ﻗﻤﻨﺎ ﺒﻤﺭﺍﻗﺒﺔ ﻜل ﻤﺎ ﻴﺤﺩﺙ ﻓﻲ

ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻻ ﺸﻙ ﺃﻥ ﺫﻟﻙ ﺴﻴﻨﻌﻜﺱ ﺴﻠﺒﺎﹰ ﻋﻠﻰ ﺃﺩﺍﺀ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻟﺫﺍ ﻜﺎﻥ ﻟﺯﺍﻤﹰﺎ ﻋﻠﻰ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻟﺘﺭﻜﻴﺯ ﻓﻲ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺒﺤﻴﺙ ﻴﺘﻡ ﻤﺭﺍﻗﺒﺔ ﻤﺎ ﻨﺤﺘﺎﺠﻪ ﺩﻭﻥ ﺍﻹﻓﺭﺍﻁ ﻓﻲ ﺍﻟﻤﺭﺍﻗﺒﺔ.

ﻓﺈﺫﺍ ﺃﺭﺩﻨﺎ ﻤﺜﻼﹰ ﻤﺭﺍﻗﺒﺔ ﺒﻌﺽ ﺍﻟﺠﺩﺍﻭل ﻓﺎﻷﻓﻀل ﺍﻟﺘﺭﻜﻴﺯ ﻋﻠﻰ ﻨﻭﻉ ﺍﻟﻌﻤﻠﻴﺎﺕ ﺍﻟﺘﻲ ﻴﺠﺏ ﻤﺘﺎﺒﻌﺘﻬﺎ ﻤﺜﻼﹰ ﺍﻟﺤﺫﻑ ﻓﻘﻁ، ﺃﻤﺎ ﺇﺫﺍ ﻗﻤﺕ ﺒﻤﺘﺎﺒﻌﺔ ﻜل ﻤﺎ ﻴﺤﺩﺙ ﻟﻠﺠﺩﺍﻭل ﻓﺈﻥ ﺫﻟﻙ ﺴﻴﺅﺜﺭ ﻋﻠﻰ ﺃﺩﺍﺀ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ

ﻓﺴﻭﻑ ﻴﺘﻡ ﻤﺘﺎﺒﻌﺔ ﺍﻻﺴﺘﻌﻼﻤﺎﺕ ﻭﺍﻟﺘﻌﺩﻴل ﻭﺍﻟﺤﺫﻑ ﻭﻏﻴﺭﻩ ، ﺇﺫﺍ ﺍﻟﺘﺭﻜﻴﺯ ﺃﻤﺭ ﻤﻬﻡ ﻓﻲ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ.

ﻭﺃﻭل ﻤﺎ ﻴﻠﺯﻤﻨﺎ ﻓﻌﻠﻪ ﻫﻭ ﺘﻬﻴﺌﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺘﻐﻴﺭ ﻗﻴﻤﺔ ﺍﻟﻤﺘﻐﻴﺭ AUDIT_TRAIL ﻤﻥ ﺍﻟﻘﻴﻤﺔ NONE ﺇﻟﻰ ﺍﺤﺩ ﺍﻟﻘﻴﻡ ﺍﻟﺘﺎﻟﻴﺔ (OS or DB)

ﻭﻟﻨﻔﺘﺭﺽ ﻫﻨﺎ ﺃﻨﻨﺎ ﻨﺭﻴﺩ ﺘﺨﺯﻴﻥ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺩﺍﺨل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ، ﺇﺫﺍﹰ ﻨﺨﺘﺎﺭ ﺍﻟﻘﻴﻤﺔ DB .

ﻟﻜﻥ ﻗﺒل ﺫﻟﻙ ﻨﺘﺄﻜﺩ ﻤﻥ ﺍﻟﻤﺘﻐﻴﺭ AUDIT_TRAIL

SHOW PARAMETER AUDIT_TRAIL;

ﻨﻘﻭﻡ ﺒﺘﺤﻭﻴل ﻗﻴﻤﺔ ﺍﻟﻤﺘﻐﻴﺭ AUDIT_TRAIL ﺍﻟﻲ ﺍﻟﻘﻴﻤﺔ DB ﻤﻊ ﻤﺭﺍﻋﺎﺓ ﺃﻥ ﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﻏﻴﺭ ﺁﻟﻲ، ﺃﻱ ﻴﺤﺘﺎﺝ ﺇﻟﻰ ﺇﻏﻼﻕ ﻭﻓﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺤﺘﻰ ﺘﺘﺄﺜﺭ ﻗﻴﻤﺔ ﺍﻟﻤﺘﻐﻴﺭ.

ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE;

ﺜﻡ ﻨﻐﻠﻕ ﻭﻨﻔﺘﺢ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻨﺘﺄﻜﺩ ﻤﻥ ﻗﻴﻤﺔ ﺍﻟﻤﺘﻐﻴﺭ.

:Standard Database Auditing -1

ﻜﻤﺎ ﺫﻜﺭﻨﺎ ﺴﺎﺒﻘﺎﹰ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻴﺘﺭﻜﺯ ﻋﻠﻰ ﻤﺭﺍﻗﺒﺔ ﻋﻤﻠﻴﺔ ﺍﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻜﺫﻟﻙ (System Privileges and Object Privileges) .

ﻜﻤﺎ ﻴﺠﺏ ﺍﻟﺫﻜﺭ ﺇﻥ ﻫﻨﺎﻙ ﺨﻴﺎﺭﺍﻥ ﺃﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ (BY ACCESS & BY SESSION) .

BY SESSION: ﻭﻫﻰ ﺘﻌﻨﻰ ﺘﺨﺯﻴﻥ ﺤﻘل ﻭﺍﺤﺩ ﻤﻥ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﺃﺜﻨﺎﺀ ﻋﻤﻠﻴﺎﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻟﻨﻭﻉ ﻤﻌﻴﻥ ﻤﻥ ﺍﻟﻌﻤﻠﻴﺎﺕ ﻟﻜل SESSION، ﻭﻟﺘﻀﺢ ﺍﻟﺭﺅﻴﺔ ﺃﻜﺜﺭ ﻟﻨﻔﺘﺭﺽ ﺃﻨﻨﺎ ﻗﻤﻨﺎ ﺒﻤﺭﺍﻗﺒﺔ ﻋﻤﻠﻴﺔ ﺍﻟﺘﻌﺩﻴل

ﻋﻠﻰ ﺠﺩﺍﻭل ﻤﺴﺘﺨﺩﻡ ﻤﻌﻴﻥ ﻭﻟﻨﻔﺘﺭﺽ ﺃﻨﻪ X، ﻓﻘﺎﻡ ﺍﺤﺩ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﺒﻔﺘﺢ SESSION ﻭﺍﺴﺘﺨﺩﻡ ﻫﺫﻩ ﺍلSESSION ﻟﺘﻌﺩﻴل 5 ﺠﺩﺍﻭل ﺘﻨﺘﻤﻲ ﻟﻠﻤﺴﺘﺨﺩﻡ X .

ﻓﺈﻥ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺴﺘﻘﻭﻡ ﺒﺘﺨﺯﻴﻥ ﺤﻘل ﻭﺍﺤﺩ ﻓﻘﻁ ﻟﻌﻤﻠﻴﺔ ﺍﻟﺘﻌﺩﻴل ﻤﺎ ﺩﺍﻡ ﺃﻨﻪ ﻗﺎﻡ ﺒﺎﻟﺘﻌﺩﻴل ﺒﻨﻔﺱ ﺍلSESSION، ﺃﻱ ﺒﻤﻌﻨﻰ ﺁﺨﺭ ﺃﻨﻬﺎ ﺘﻭﺍﺯﻯ ﻋﺒﺎﺭﺓ GROUP BY SESSIION .

ACCESS :BY ﻴﻤﻜﻥ ﺍﺘﺨﺎﺫ ﻨﻔﺱ ﺍﻟﻤﺜﺎل ﺍﻟﺴﺎﺒﻕ، ﻟﻜﻥ ﻫﻨﺎ ﺴﻴﺘﻡ ﺘﺨﺯﻴﻥ 5 ﺤﻘﻭل ﻜل ﺤﻘل ﻫﻭ ﻋﺒﺎﺭﺓ ﻋﻥ ﻋﻤﻠﻴﺔ ﺍﻟﺘﻌﺩﻴل ﺍﻟﺘﻲ ﺤﺩﺜﺕ ﻟﻜل ﺠﺩﻭل.

ﻻ ﺸﻙ ﺃﻥ ﺍﻟﺨﻴﺎﺭ BY SESSION ﻗﺩ ﻻ ﻴﻜﻭﻥ ﻜﺎﻓﻴﺎﹰ ﺃﺤﻴﺎﻨﹰﺎ ﻟﻤﻌﺭﻓﺔ ﺘﻔﺎﺼﻴل ﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻟﺫﺍ ﻗﺩ ﻨﻠﺠﺄ ﻟﻠﺨﻴﺎﺭ BY ACCESS ﺍﻟﺫﻱ ﻨﺠﺩ ﻓﻴﻪ ﺘﻔﺎﺼﻴل ﺃﻜﺜﺭ ﻟﻜﻥ ﺒﺎﻟﻁﺒﻊ ﻴﺯﻴﺩ ﻋﻤﻠﻴﺎﺕ ﺘﺨﺯﻴﻥ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ.

ﻓﻲ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻜﻤﺎ ﺫﻜﺭﻨﺎ ﺍﻷﻓﻀل ﻓﻴﻪ ﻋﻤﻠﻴﺔ ﺍﻟﺘﺭﻜﻴﺯ ﻭﻴﻜﻭﻥ ﺍﻟﺘﺭﻜﻴﺯ ﺒﺘﺤﺩﻴﺩ ﺍﻟﻤﺴﺘﺨﺩﻡ ﻜﺫﻟﻙ ﺒﺘﺤﺩﻴﺩ ﻨﺠﺎﺡ ﺃﻭ ﻓﺸل ﺍﻟﻌﻤﻠﻴﺔ (SUCCESSFUL OR NOT SUCCESSFUL) .

ﻭﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ Standard Database Auditing ﻴﺤﺘﻭﻯ ﻋﻠﻰ ﺃﻗﺴﺎﻡ فرعية:-

SESSION AUDITING:

ﻭﻫﻰ ﺠﺯﺀ ﻤﻥ ﺍﻟﻨﻭﻉ ﺍﻷﻭل ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ Standard Database Auditing ، ﺒﺤﻴﺙ ﻴﺘﻡ ﻤﺭﺍﻗﺒﺔ ﻋﻤﻠﻴﺎﺕ ﺍﻻﺘﺼﺎل ﻭﻗﻁﻊ ﺍﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ، ﻭﻴﻤﻜﻥ ﺍﻟﺘﺭﻜﻴﺯ ﺒﺘﺤﺩﻴﺩ ﺍﻟﻤﺴﺘﺨﺩﻡ ﺍﻟﺫﻱ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﻋﻤﻠﻴﺎﺘﻪ

ﺍﺘﺼﺎﻟﻪ ﻜﻤﺎ ﻴﻤﻜﻥ ﻤﺘﺎﺒﻌﺔ ﻜل ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﺒﺎﺴﺘﺨﺩﺍﻡ ﺍﻷﻤﺭ AUDIT SESSION ﻜﻤﺎ ﻴﻤﻜﻥ ﺍﻟﺘﺭﻜﻴﺯ ﺃﻴﻀﺎً ﺒﺘﺤﺩﻴﺩ ﻋﻤﻠﻴﺔ ﻨﺠﺎﺡ ﺃﻭ ﻓﺸل ﻋﻤﻠﻴﺔ ﺍﻻﺘﺼﺎل.

ﻨﻔﺘﺭﺽ ﺃﻨﻨﺎ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﻜل ﻋﻤﻠﻴﺎﺕ ﺍﻻﺘﺼﺎل ﺍﻟﻨﺎﺠﺤﺔ ﻭﻗﻁﻊ ﺍﻻﺘﺼﺎل ﺒﺎﻟﻨﺴﺒﺔ ﻟﻠﻤﺴﺘﺨﺩﻡ TEST ﻭﻷﻨﻨﺎ ﻨﺭﻴﺩ ﻤﻌﺭﻓﺔ ﻭﻗﺕ ﺍﻻﺘﺼﺎل ﻭﻗﻁﻊ ﺍﻻﺘﺼﺎل ﻓﺎﻷﻓﻀل ﺍﺴﺘﺨﺩﻡ ﺍﻟﺨﻴﺎﺭ ACCESS .

AUDIT SESSION BY TEST BY ACCESS WHENEVER SUCCESSFUL;

ﻤﺎﺫﺍ ﺍﻵﻥ ﻟﻭ ﻗﺎﻡ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﺒﺎﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ؟

ﺍﻵﻥ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻴﺴﺘﻁﻴﻊ ﺃﻥ ﻴﺸﺎﻫﺩ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﻋﻤﻠﻴﺔ ﺍﻻﺘﺼﺎل ﺃﻋﻼﻩ

SELECT SERNAME,TERMINAL,ACTION_NAME,EXTENDED_TIMESTAMP FROM DBA_AUDIT_SESSION;

ستجد انه ﻅﻬﺭ ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺃﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﻗﺎﻡ ﺒﺎﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺎﻟﺘﺎﺭﻴﺦ ﻭﺍﻟﺯﻤﻥ ﺍﻟﻤﺤﺩﺩ ﻤﻥ ﺍﻟﺠﻬﺎﺯ NBS ﻜﻤﺎ ﻴﻤﻜﻥ ﺍﺴﺘﻌﺭﺍﺽ ﻤﻌﻠﻭﻤﺎﺕ ﺃﺨﺭﻯ ﻋﻥ ﺍﺴﻡ ﻤﺴﺘﺨﺩﻡ ﺍﻟﺠﻬﺎﺯ ﻭﻏﻴﺭﻩ ﻤﻥ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ.

ﻤﺎﺫﺍ ﻟﻭ ﻗﺎﻡ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﺒﻘﻁﻊ ﺍﻻﺘﺼﺎل؟ ﺒﺎﻟﻁﺒﻊ ﺴﺘﻅﻬﺭ ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﻌﻠﻭﻤﺎﺕ ﺇﻀﺎﻓﻴﺔ .

SELECT USERNAME,TERMINAL,ACTION_NAME,TO_CHAR(EXTENDED_TIM ESTAMP,'DD-MM-YYYY:HH-MI- SS'),TO_CHAR(LOGOFF_TIME,'DD-MM-YYYY:HH-MI-SS') FROM DBA_AUDIT_SESSION;

ﺍﻵﻥ ﻴﻅﻬﺭ ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺃﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﻗﺎﻡ ﺒﻘﻁﻊ ﺍﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻓﻲ ﺍﻟﺯﻤﻥ ﺍﻟﻤﺤﺩﺩ .

ﻴﻤﻜﻥ ﺃﻴﻀﺎﹰ ﺍﺴﺘﻌﻼﻡ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻻﺘﺼﺎل ﻭﻗﻁﻊ ﺍﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ عن طريق (DBA_AUDIT_TRAIL) .

.ﺇﺫﺍﹰ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻻﺘﺼﺎل ﻭﻗﻁﻊ ﺍﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﺘﻭﻓﺭﺓ ﻓﻲ ﻜل ﻤﻥ( DBA_AUDIT_TRAIL & DBA_AUDIT_SESSION) .

ﻴﻤﻜﻥ ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻻﺴﺘﻌﻼﻡ ﻋﻥ ﺨﻴﺎﺭﺍﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺍﻟﺘﻲ ﻗﺎﻡ ﺒﺘﻬﻴﺌﺘﻬﺎ ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﻭﺍﺴﻁﺔ:

DBA_OBJ_AUDIT_OPTS

DBA_STMT_AUDIT_OPTS

DBA_PRIV_AUDIT_OPTS

SELECT USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE FROM DBA_STMT_AUDIT_OPTS;

ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺇﻟﻐﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ، ﻓﻠﻭ ﺃﺭﺩﻨﺎ ﺇﻟﻐﺎﺀ ﻋﻤﻠﻴﺔ ﻤﺭﺍﻗﺒﺔ ﺍﺘﺼﺎل ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﺍﻟﺘﻲ ﻗﻤﻨﺎ بمﺭﺍﻗﺒﺘﻬﺎ ﺴﺎﺒﻘﺎﹰ.

NOAUDIT SESSION BY TEST;

ﺍﻵﻥ ﻟﻭ ﻗﻤﻨﺎ ﺒﻌﻤﻠﻴﺔ ﺍﺴﺘﻌﻼﻡ ﻟﻌﺭﺽ ﺨﻴﺎﺭﺍﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺍﻟﺘﻲ ﻗﻤﻨﺎ ﺒﺘﻬﻴﺌﺘﻬﺎ ﻓﻠﻥ ﻨﺠﺩ ﺨﻴﺎﺭ ﻤﺭﺍﻗﺒﺔ ﺍﺘﺼﺎل ﺍﻟﻤﺴﺘﺨﺩﻡ TEST .

SQL STATEMENT AUDITING:

ﺘﺨﻴل ﻤﻌﻲ ﺃﻥ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻴﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﻋﻤﻠﻴﺎﺕ ﺍلDDL ﻤﺜل ﺇﻨﺸﺎﺀ ﺃﻭ ﺤﺫﻑ ﺠﺩﻭل، ﻓﻲ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻴﻤﻜﻥ ﺍﻟﺘﺭﻜﻴﺯ ﺒﻭﺍﺴﻁﺔ ﺘﺤﺩﻴﺩ ﺍﻟﻤﺴﺘﺨﺩﻡ ﻭﻜﺫﻟﻙ ﺒﻭﺍﺴﻁﺔ ﻨﺠﺎﺡ ﺃﻭ ﻓﺸل ﺍﻟﻌﻤﻠﻴﺔ،

ﻟﻜﻥ ﻫﺫﺍ ﻓﻲ ﺇﻁﺎﺭ ﻤﺎ ﻴﻤﻠﻙ ﺍﻟﻤﺴﺘﺨﺩﻡ، ﻓﻠﻭ ﻗﺎﻡ ﻤﺴﺘﺨﺩﻡ ﻤﺜﻼﹰ ﺒﺈﻨﺸﺎﺀ ﺠﺩﻭل ﻓﻲ SCHEMA ﻟﻤﺴﺘﺨﺩﻡ ﺁﺨﺭ ﻓﺈﻥ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻴﺩﺨل ﻓﻴﻤﺎ ﻴﺴﻤﻰ AUDITING PRIVILEGE SYSTEM ﻭﻫﻭ ﻤﺎ ﺴﻨﻨﺎﻗﺸﻪ

ﻻﺤﻘﺎ، ﺃﻤﺎ ﻫﻨﺎ ﻓﻘﻁ ﻓﻲ ﺇﻁﺎﺭ ﻤﺎ ﻴﻤﻠﻙ ﺍﻟﻤﺴﺘﺨﺩﻡ ﻓﻘﻁ .

ﻭﻟﻨﻔﺘﺭﺽ ﺃﻨﻨﺎ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﻋﻤﻠﻴﺔ ﺇﻨﺸﺎﺀ ﺍﻟﺠﺩﺍﻭل ﺒﻭﺍﺴﻁﺔ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﺩﺍﺨل ﻤﺴﺎﺤﺘﻪ ﺃﻱ ﻓﻲ ﻨﻔﺱ الSCHEMA .

AUDIT CREATE TABLE BY TEST BY ACCESS;

ﺫﺍ ﻟﻭ ﻗﺎﻡ ﺍﻵﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﺒﺈﻨﺸﺎﺀ ﺠﺩﻭل؟

CREATE TABLE USER_MASTER (USER_NO NUMBER(٥),USER_NAME VARCHAR٢(٠٤),CONSTRAINT PK_USER_NO PRIMARY KEY(USER_NO));

ﺴﺘﻅﻬﺭ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.

SELECT USERNAME,OWNER,TO_CHAR(TIMESTAMP,'DD-MM- YYYY:HH-MI-SS'),OBJ_NAME,ACTION_NAME FROM DBA_AUDIT_TRAIL WHERE OWNER='TEST';

ﻟﻜﻥ ﻟﻭ ﻗﺎﻡ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﻤﺜﻼﹰ ﺒﺈﻨﺸﺎﺀ ﺠﺩﻭل ﻓﻲ SCHEMA ﺃﺨﺭﻯ ﻓﺈﻥ ﺨﻴﺎﺭﺍﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺃﻋﻼﻩ ﻟﻥ ﺘﺄﺘﻰ ﺒﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻠﻬﻡ ﺇﻻ ﺇﺫﺍ ﺭﺍﻗﺒﻨﺎ ﺍﻟﺼﻼﺤﻴﺔ TABLE ANY CREATE ﻭﻫﻭ ﻤﺎ ﺴﻨﻨﺎﻗﺸﻪ ﻓﻲ ﺍﻟﺨﻁﻭﺓ ﺍﻟﻘﺎﺩﻤﺔ .

ﻴﻤﻜﻥ ﺍﻻﺴﺘﻌﻼﻡ ﻋﻥ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻟﺘﻲ ﻗﻤﻨﺎ ﺒﺘﻬﻴﺌﺘﻬﺎ ﻟﻤﺭﺍﻗﺒﺔ SQL STATEMENT ﺒﻭﺍﺴﻁﺔ:

DBA_STMT_AUDIT_OPTS

DBA_PRIV_AUDIT_OPTS

ﻴﻤﻜﻥ ﺇﻟﻐﺎﺀ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺒﻭﺍﺴﻁﺔ:

NOAUDIT CREATE TABLE BY TEST;

SYSTEM PRIVILEGE AUDITING:

ﻭﺫﻟﻙ ﻟﻤﺭﺍﻗﺒﺔ ﻋﻤﻠﻴﺎﺕ ﺍﺴﺘﺨﺩﺍﻡ ﺍﻟﺼﻼﺤﻴﺎﺕ SYSTEM PRIVILEGES ﺩﺍﺨل ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ، ﻤﺜﻼﹰ ﺍﻟﺼﻼﺤﻴﺔ CREATE ANY TABLE ، ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺘﺭﻜﻴﺯ ﻋﻤﻠﻴﺔ ﻤﺭﺍﻗﺒﺔ ﺍﻟﺼﻼﺤﻴﺎﺕ ﺒﻭﺍﺴﻁﺔ ﻤﺴﺘﺨﺩﻡ ﻤﻌﻴﻥ ﻜﺫﻟﻙ ﺒﻭﺍﺴﻁﺔ ﻨﺠﺎﺡ ﺍﻟﻌﻤﻠﻴﺔ ﺃﻭ ﻓﺸﻠﻬﺎ، ﻓﻲ ﺍﻷﺼل ﻴﺘﻡ ﺘﺨﺯﻴﻥ ﻋﻤﻠﻴﺎﺕ ﻤﺭﺍﻗﺒﺔ ﺍﻟﺼﻼﺤﻴﺎﺕ SYSTEM PRIVILEGES ﻜﺤﻘل ﻟﻜل ﻋﻤﻠﻴﺔ ﻭﺫﻟﻙ ﻻﺴﺘﺨﺩﺍﻡ ﺍﻟﺨﻴﺎﺭ BY ACCESS ﻜﻭﻀﻊ ﺍﻓﺘﺭﺍﻀﻲ؛ ﻟﻜﻥ ﺒﺎﻟﻁﺒﻊ ﻴﻤﻜﻥ ﺍﺴﺘﻌﻤﺎل ﺍﻟﺨﻴﺎﺭ SESSION BY ﻟﺘﻘﻠﻴل ﻋﻤﻠﻴﺎﺕ ﺘﺨﺯﻴﻥ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﻓﻴﺘﻡ ﺘﺨﺯﻴﻥ ﺤﻘل ﻭﺍﺤﺩ ﻟﻜل SESSION ﺍﺴﺘﺨﺩﻤﺕ ﺍﻟﺼﻼﺤﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ. ﻭﻟﻨﻔﺘﺭﺽ ﺃﻨﻨﺎ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﺍﻟﺼﻼﺤﻴﺔ TABLE ANY CREATE ﻟﻠﻤﺴﺘﺨﺩﻡ TEST، ﺃﻱ ﺒﻤﻌﻨﻰ ﺁﺨﺭ ﺃﻨﻨﺎ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﻜل ﺍﻟﺠﺩﺍﻭل ﺍﻟﺘﻲ ﻴﻘﻭﻡ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﺒﺈﻨﺸﺎﺌﻬﺎ ﻓﻲ SCHEMA ﺃﺨﺭﻯ ﻤﺴﺘﺨﺩﻤﺎﹰ ﺍﻟﺼﻼﺤﻴﺔ CREATE ANY TABLE ﻭﻫﻰ ﺘﻌﻨﻰ ﺇﻨﺸﺎﺀ ﺠﺩﻭل ﻓﻲ SCHEMA ﺃﺨﺭﻯ.

AUDIT CREATE ANY TABLE BY TEST WHENEVER SUCCESSFUL;

ﺍﻵﻥ ﻤﺎﺫﺍ ﻟﻭ ﻗﺎﻡ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﺒﺈﻨﺸﺎﺀ ﺠﺩﻭل ﻓﻲ EMP SCHEMA ﺃﻱ ﻓﻲ ﻤﺴﺎﺤﺔ ﺍﻟﻤﺴﺘﺨﺩﻡ EMP .

CREATE TABLE EMP.EMPLOYEE (EMP_NO NUMBER(٤),EMP NAME VARCHAR(40));

ﺒﺎﻟﻁﺒﻊ ﻴﺴﺘﻁﻴﻊ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﺘﺎﺒﻌﺔ ﻫﺫﻩ ﺍﻟﺨﻁﻭﺓ .

SELECT USERNAME,OWNER,OBJ_NAME,ACTION_NAME,TO_CHAR(TIMEST AMP,'DD-MM-YYYY:HH-MI-SS') FROM DBA_AUDIT_OBJECT WHERE USERNAME='TEST';

ستلاحظ بالفعل ان المستخدم TEST ﻗﺎﻡ ﺒﺈﻨﺸﺎﺀ ﺠﺩﻭل EMPLOYEE ﻓﻲ ﺍﻟﻤﺴﺘﺨﺩﻡ EMP ﻓﻲ ﺍﻟﺯﻤﻥ المحدد .

ﺃﻴﻀﺎﹰ ﻴﻤﻜﻥ ﻤﺘﺎﺒﻌﺔ ﺒﺎﻗﻲ ﺍﻟﺼﻼﺤﻴﺎﺕ ﻤﺜﻼﹰ (DROP ANY TABLE) ﻭﻏﻴﺭﻫﺎ ﻤﻥ ﺍﻟﺼﻼﺤﻴﺎﺕ SYSTEM PRIVILEGES.

ﻟﻼﺴﺘﻌﻼﻡ ﻋﻥ ﺘﻬﻴﺌﺔ ﺨﻴﺎﺭﺍﺕ ﻤﺭﺍﻗﺒﺔ SYSTEM .

SELECT * FROM DBA_PRIV_AUDIT_OPTS WHERE PRIVILEGE='CREATE ANY TABLE';

كما يمكن إلغاء المراقبة .

NOAUDIT CRATE ANY TABLE BY TEST WHENEVER SECCESSFUL;

OBJECT PRIVILEGE AUDITING:

ﻭﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻟﻤﺭﺍﻗﺒﺔ ﺍﻟﻌﻤﻠﻴﺎﺕ ﺍﻟﺘﻲ ﺘﺤﺩﺙ ﻋﻠﻰ ﺍﻟﻜﺎﺌﻨﺎﺕ ﻤﻥ ﺠﺩﺍﻭل TABLES ﻭﻤﻨﺎﻅﻴﺭ VIEWS ﻭﻏﻴﺭﻫﺎ ﻤﻥ ﺍﻟﻜﺎﺌﻨﺎﺕ.

ﻴﻤﻜﻥ ﺍﻟﺘﺭﻜﻴﺯ ﺒﻭﺍﺴﻁﺔ ﺘﺤﺩﻴﺩ ﺍﻟﻤﺴﺘﺨﺩﻡ ﻭﻜﺫﻟﻙ ﺒﻭﺍﺴﻁﺔ ﻨﺠﺎﺡ ﺃﻭ ﻓﺸل ﺍﻟﻌﻤﻠﻴﺔ، ﺍﻷﺼل ﻓﻲ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺃﻥ ﺘﻜﻭﻥ BY SESSION ﻭﻟﻜﻥ ﻴﻤﻜﻥ ﺘﺤﺩﻴﺩ ﺍﻟﺨﻴﺎﺭ BY ACCESS.

ﻟﻨﻔﺘﺭﺽ ﺃﻨﻨﺎ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﻋﻤﻠﻴﺎﺕ ﺍﻹﻀﺎﻓﺔ ﻓﻲ ﺍﻟﺠﺩﻭل USER_MASTER ﺍﻟﻤﻭﺠﻭﺩ ﻓﻲ ﺍلSCHEMA ﺍﻟﺘﻲ ﺘﺴﻤﻰ TEST.

AUDIT INSERT ON TEST.USER_MASTER BY ACCESS;

ﺍﻵﻥ ﻟﻭ ﻗﺎﻡ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﺒﺈﻀﺎﻓﺔ ﺒﻴﺎﻨﺎﺕ ﻓﻲ ﺍﻟﺠﺩﻭل USER_MASTER يﺴﺘﻁﻴﻊ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﺘﺎﺒﻌﺔ ﺫﻟﻙ .

SELECT USERNAME,TO_CHAR(TIMESTAMP,'DD-MM-YY:HH- MI-SS'),OBJ_NAME,ACTION_NAME FROM DBA_AUDIT_TRAIL WHERE USERNAME='TEST' AND OBJ_NAME='USER_MASTER' AND ACTION_NAME='INSERT';

ﻟﻼﺴﺘﻌﻼﻡ ﻋﻥ ﺨﻴﺎﺭﺍﺕ ﺘﻬﻴﺌﺔ ﻤﺭﺍﻗﺒﺔ ﺍلOBJECT PRIVILEGES.

select * from DBA_OBJ_AUDIT_OPTS WHERE OWNER='TEST' AND OBJECT_NAME='USER_MASTER';

ﻫﻨﺎﻙ ﺜﻼﺙ ﻗﻴﻡ :

-: ﺘﻌﻨﻰ ﻋﺩﻡ ﺍﻟﻤﺭﺍﻗﺒﺔ.

A: ﺘﻌﻨﻰ ﺃﻥ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺘﺨﺯﻥ ACCESS BY .

S: ﺘﻌﻨﻰ ﺃﻥ ﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺘﺨﺯﻥ SESSION .BY

ﻻﺤﻅ ﺃﻨﻪ ﻤﻘﺎﺒل ﺍﻟﺤﻘل INS ﻭﺠﺩﺕ ﺍﻟﻘﻴﻤﺔ A/A ﺃﻱ ﺃﻨﻪ ﺘﺘﻡ ﻤﺭﺍﻗﺒﺔ ﻋﻤﻠﻴﺔ ﺍلINSERT ﺒﻭﺍﺴﻁﺔ ﺍﻟﺨﻴﺎﺭ BY ACCESS ﺴﻭﺍﺀ ﻨﺠﺤﺕ ﺍﻟﻌﻤﻠﻴﺔ ﺃﻭ ﻓﺸﻠﺕ،

ﺃﻤﺎ ﺇﺫﺍ ﻜﺎﻥ ﺍﻟﺨﻴﺎﺭ WHENEVER SUCCESSFUL ﻓﺈﻥ ﺍﻟﻘﻴﻤﺔ ﺴﺘﻜﻭﻥ A/-

يمكن ﺇﻟﻐﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺒﻭﺍﺴﻁﺔ.

NOAUDIT INSERT ON TEST.USER_MASTER;

ﻫﻜﺫﺍ ﻨﻜﻭﻥ ﻗﺩ ﻨﺎﻗﺸﻨﺎ ﺍﻟﺨﻴﺎﺭﺍﺕ ﺍﻟﻤﺘﺎﺤﺔ ﻟﻠﻤﺭﺍﻗﺒﺔ ﺍﻟﺘﻲ ﺘﻨﺘﻤﻲ ﻟﻠﺠﺯﺀ ﺍﻷﻭل Standard Database Auditing وهي:

.SESSION AUDITING

SQL STATEMENT AUDITING

SYSTEM PRIVILEGE AUDITING

OBJECT PRIVILEGE AUDITING

2- Value-Based Auditing:

ﻓﻲ ﺍﻟﻨﻭﻉ ﺍﻷﻭل ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ Standard Database Auditing اﺴﺘﻁﻌﻨﺎ ﻤﺭﺍﻗﺒﺔ ﻭﺤﻔﻅ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﺍﻟﻌﻤﻠﻴﺎﺕ ﺍﻟﺘﻲ ﺘﺤﺩﺙ ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ، ﻟﻜﻥ ﻗﺩ ﻨﺤﺘﺎﺝ ﺃﺤﻴﺎﻨﺎﹰ ﻟﺤﻔﻅ ﺍﻟﻘﻴﻡ ﺍﻟﺘﻲ ﻴﺘﻡ ﺘﻌﺩﻴﻠﻬﺎ ﺃﻭ

ﺤﺫﻓﻬﺎ ﻤﻥ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ، ﻫﺫﻩ ﺍﻟﻘﻴﻡ ﻻ ﻴﺘﻡ ﺤﻔﻅﻬﺎ ﻓﻲ ﺍلStandard Database Auditing ﻴﻌﻤل ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ Value-Based Auditing ﻤﻌﺘﻤﺩﺍﹰ ﻋﻠﻰ ﺨﻠﻕ Trigger ﺒﺤﻴﺙ

ﻴﺘﻡ ﺘﻨﻔﻴﺫﻩ ﺒﻌﺩ ﻋﻤﻠﻴﺔ ﺍﻟﺘﻌﺩﻴل ﺃﻭ ﺍﻟﺤﺫﻑ ﻟﻴﺤﻔﻅ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﻭﺍﻟﻘﻴﻡ ﺍﻟﺘﻲ ﻨﺭﻴﺩﻫﺎ ﻭﻴﺤﻔﻅﻬﺎ ﻓﻲ ﺠﺩﻭل ﻨﻘﻭﻡ ﺒﺈﻨﺸﺎﺌﻪ ﺨﺼﻴﺼﹰﺎ ﻟﺘﺨﺯﻴﻥ ﻫﺫﻩ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ.

ﺒﺎﻟﻁﺒﻊ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ Auditing Value-Based ﻴﻘﻠل ﻤﻥ ﺃﺩﺍﺀ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺃﻜﺜﺭ ﻤﻥ ﺍﻟﻨﻭﻉ Standard Database Auditing ﻭﺫﻟﻙ ﻷﻥ ﺍلTrigger ﻴﺘﻡ ﺘﻨﻔﻴﺫﻩ ﺒﻌﺩ ﻜل ﻋﻤﻠﻴﺔ ﺘﻌﺩﻴل ﺃﻭ ﺤﺫﻑ.

ﻭﻟﻨﻔﺘﺭﺽ ﺍﻵﻥ ﺃﻨﻨﺎ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﻭﺤﻔﻅ ﺍﻟﻘﻴﻡ ﺍﻟﺘﻲ ﺘﻡ ﺘﻌﺩﻴﻠﻬﺎ ﻓﻲ ﺍﻟﺤﻘل BOOK_NAME ﺍﻟﻤﻭﺠﻭﺩﺓ ﻓﻲ ﺍﻟﺠﺩﻭل BOOK ﺍﻟﻤﻤﻠﻭﻙ ﻟﻠﻤﺴﺘﺨﺩﻡ TEST .

ﻴﻠﺯﻡ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺃﻭﻻﹰ ﺘﺤﺩﻴﺩ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﺍﻟﺘﻲ ﻴﺭﻴﺩ ﺤﻔﻅﻬﺎ ﻭﻟﻨﻔﺘﺭﺽ ﺃﻨﻬﺎ:-

1- IP Address ﻟﻠﺠﻬﺎﺯ ﺍﻟﺫﻱ ﺍﺴﺘﺨﺩﻡ ﻟﻼﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.

2- ﺍﺴﻡ ﻤﺴﺘﺨﺩﻡ ﻨﻅﺎﻡ ﺍﻟﺘﺸﻐﻴل ﺍﻟﺫﻱ ﻗﺎﻡ ﺒﺎﻻﺘﺼﺎل ﺒﻘﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.

3- ﺍﻟﺘﺎﺭﻴﺦ ﻭﺍﻟﺯﻤﻥ.

4- ﻗﻴﻤﺔ ﺍﻟﺤﻘل ﻗﺒل ﺍﻟﺘﻌﺩﻴل ﻭﺒﻌﺩ ﺍﻟﺘﻌﺩﻴل.

ﺜﺎﻨﻴﹰﺎ: ﻴﻠﺯﻡ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺇﻨﺸﺎﺀ ﺍﻟﺠﺩﻭل ﻟﺘﺨﺯﻴﻥ ﺍﻟﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﻋﻤﻠﻴﺎﺕ ﺍﻟﺘﻌﺩﻴل.

CREATE TABLE BOOK_AUDIT(

OS_USER VARCHAR2(70),

UPDATE_DATE DATE,

IP_ADDRESS VARCHAR2(60),

OLD_NEW_NAME VARCHAR2(100));

ﺜﺎﻟﺜﺎﹰ ﻴﻘﻭﻡ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺒﺈﻨﺸﺎﺀ ﺍلTrigger.

CREATE OR REPLACE TRIGGER BOOK_NAME_AUDIT AFTER UPDATE OF BOOK_NAME

ON TEST.BOOK

REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW

BEGIN

IF :OLD.BOOK_NAME != :NEW.BOOK_NAME THEN INSERT INTO BOOK_AUDIT

VALUES (SYS_CONTEXT('USERENV','OS_USER'), SYSDATE, SYS_CONTEXT('USERENV','IP_ADDRESS'),

:NEW.BOOK_NO ||' BOOK_NO) CHANGED FROM '||:OLD.BOOK_NAME||

' TO '||:NEW.BOOK_NAME); END IF;

END;

ﻫﻜﺫﺍ ﺘﻡ ﺇﻨﺸﺎﺀ ﺍلTrigger ﻭﻟﻨﻔﺘﺭﺽ ﺃﻥ ﺍﻟﻤﺴﺘﺨﺩﻡ TEST ﻗﺎﻡ ﺒﺘﻌﺩﻴل ﻓﻲ ﺍﻟﺠﺩﻭل BOOK.

ﻴﺴﺘﻁﻴﻊ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻤﺘﺎﺒﻌﺔ ﺫﻟﻙ ﺍﻟﺘﻌﺩﻴل ﺒﻭﺍﺴﻁﺔ ﺍﻟﺠﺩﻭل BOOK_AUDIT.

SELECT OS_USER,TO_CHAR(UPDATE_DATE,'DD-MM-YY:HH- MI-SS'),IP ADDRESS,OLD NEW NAME FROM BOOK_AUDIT;

ﻹﻴﻘﺎﻑ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻴﻤﻜﻥ ﺘﻌﻁﻴل ﺃﻭ ﺤﺫﻑ ﻫﺫﺍ ﺍلTrigger.

3- (Fine-Grained Auditing (FGA:

ﺍﻷﻨﻭﺍﻉ ﺍﻟﺴﺎﺒﻘﺔ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ ﺘﺴﺘﻁﻴﻊ ﺤﻔﻅ ﻤﻌﻠﻭﻤﺎﺕ ﻋﻥ ﺍﻟﻌﻤﻠﻴﺎﺕ ﺍﻟﺘﻲ ﺘﺤﺩﺙ ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻜﻤﺎ ﻴﻤﻜﻥ ﺤﻔﻅ ﺍﻟﻘﻴﻡ ﺍﻟﺘﻲ ﺘﺘﻐﻴﺭ، ﺃﻤﺎ ﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻓﻬﻭ ﻟﺤﻔﻅ ﻋﺒﺎﺭﺍﺕ ﺍلSQL ﺍﻟﺘﻲ ﺘﻨﻔﺫ ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﻴﺸﻤل ﻜل ﻤﻥ ﺍﻟﻌﺒﺎﺭﺍﺕ ﺍﻵﺘﻴﺔ (DELETE & UPDATE & INSERT & SELECT).

ﻭﺫﻟﻙ ﺒﺎﺴﺘﺨﺩﺍﻡ DBMS_FGA PACKAGE، ﻫﺫﻩ ﺍﻟﺤﺯﻤﺔ ﺘﺤﺘﻭﻯ ﻋﻠﻰ ﺃﺭﺒﻌﺔ ﻤﻥ ﺍلProcedure:-

1 - ADD_POLICY: ﻹﻀﺎﻓﺔ POLICY ﺠﺩﻴﺩﺓ ﻟﻤﺭﺍﻗﺒﺔ ﻋﺒﺎﺭﺍﺕ ﺍلSQL ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﻭﺫﻟﻙ ﺤﺴﺏ ﺍﻟﻘﻴﻡ ﺍﻟﺘﻲ ﺴﻨﺤﺩﺩﻫﺎ ﻓﻲ ﺍﻹﺠﺭﺍﺀ.

2- DROP_POLICY: ﻟﺤﺫﻑ AUDIT POLICY ﻤﻭﺠﻭﺩﺓ.

.ﻜﺎﻨﺕ ﻤﻌﻁﻠﺔ AUDIT POLICY ﻟﺘﺸﻐﻴل :ENABLE_POLICY - 3

DISABLE POLICY - 4: ﻟﺘعطيل عمل AUDIT POLICY.

ﻭﻟﻨﻔﺘﺭﺽ ﺍﻵﻥ ﺃﻨﻨﺎ ﻨﺭﻴﺩ ﺤﻔﻅ ﻋﺒﺎﺭﺍﺕ ﺍلSELECT ﺍﻟﺘﻲ ﺘﺤﺩﺙ ﻟﻠﺠﺩﻭل BOOK ﺍﻟﻤﻤﻠﻭﻙ ﻟﻠﻤﺴﺘﺨﺩﻡ TEST، ﻭﺤﺘﻰ ﻻ ﻨﺤﻔﻅ ﻜل ﻋﺒﺎﺭﺍﺕ ﺍلSELECT ﺍﻟﺘﻲ ﺘﺤﺩﺙ ﻟﻠﺠﺩﻭل BOOK ﻓﻤﻥ ﺍﻟﻤﻤﻜﻥ ﺍﻟﺘﺭﻜﻴﺯ

ﻋﻠﻰ ﺒﻌﺽ ﺍﻟﺤﻘﻭل ﻭﺫﻟﻙ ﺒﺈﺴﺘﺨﺩﺍﻡ ﺒﻌﺽ ﺍﻟﺸﺭﻭﻁ.

.WHERE BOOK_NO=1 ﻤﺜﻼﹰ

ﻭﺫﻟﻙ ﻟﺘﺭﻜﻴﺯ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ .

ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺩﺍﺌﻤﺎﹰ ﻴﺠﺏ ﺃﻥ ﻴﺭﺍﻋﻰ ﺃﻥ ﻻ ﻴﻔﺭﻁ ﻓﻲ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ، ﺒل ﻴﺭﻜﺯ ﺩﺍﺌﻤﺎ ﻋﻠﻰ ﺍﻟﻤﻁﻠﻭﺏ. ﺍﻵﻥ ﻨﻘﻭﻡ ﺒﺘﻨﻔﻴﺫ ﺍﻹﺠﺭﺍﺀ ADD_POLICY ﻭﺫﻟﻙ ﻹﻀﺎﻓﺔ AUDIT POLICY ﺘﻘﻭﻡ ﺒﺤﻔﻅ ﻋﺒﺎﺭﺍﺕ

ﺍلSELECT ﺍﻟﺘﻲ ﺘﻨﻔﺫ ﻋﻠﻰ ﺍﻟﺠﺩﻭل BOOK ﻭﺫﻟﻙ ﺤﺴﺏ ﺍﻟﺸﺭﻭﻁ ﺍﻟﺘﻲ ﻨﺤﺩﺩﻫﺎ. ﺒﺎﻟﻁﺒﻊ ﻫﺫﺍ ﺍﻹﺠﺭﺍﺀ Procedure ﻴﺤﺘﻭﻯ ﻋﻠﻰ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ ﺍﻟﺘﻲ ﻴﺠﺏ ﺃﻥ ﻨﺤﺩﺩ ﻟﻬﺎ ﻗﻴﻡ، ﻫﺫﻩ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ ﺴﻨﺘﺤﺩﺙ

ﻋﻨﻬﺎ ﺒﺸﻲ ﻤﻥ ﺍﻟﺘﻔﺼﻴل ﻻﺤﻘﺎﹰ.

ﻫﺫﻩ ﺍﻹﺠﺭﺍﺀﺍﺕ Procedures ﻤﻭﺠﻭﺩﺓ ﻓﻲ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺩﺍﺨل ﺍﻟﺤﺯﻤﺔ DBMG_FGA ﺃﻱ ﻻ ﻴﺤﺘﺎﺝ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺇﻟﻲ ﺃﻨﺸﺎﺅﻫﺎ ﻓﻘﻁ ﻴﺤﺘﺎﺝ ﻟﺘﻨﻔﻴﺫﻩ ﺒﻌﺩ ﺘﺤﺩﻴﺩ ﻗﻴﻡ ﺍﻟﻤﺘﻐﻴﺭﺍﺕ.

DECLARE

OBJECT_SCHEMA VARCHAR2(200);

OBJECT_NAME VARCHAR2(200);

POLICY_NAME VARCHAR2(200);

AUDIT_CONDITION VARCHAR2(200);

AUDIT_COLUMN VARCHAR2(200);

HANDLER_SCHEMA VARCHAR2(200);

HANDLER_MODULE VARCHAR2(200);

ENABLE BOOLEAN;

STATEMENT_TYPES VARCHAR2(200);

AUDIT_TRAIL BINARY_INTEGER;

AUDIT_COLUMN_OPTS BINARY_INTEGER;

BEGIN

OBJECT_SCHEMA := 'TEST';

OBJECT_NAME := 'BOOK';

POLICY_NAME := 'BOOK_SELECT';

AUDIT_CONDITION := 'BOO_NO=1';

AUDIT_COLUMN := 'BOOK_NAME';

HANDLER_SCHEMA := NULL;

HANDLER_MODULE := NULL;

ENABLE := TRUE;

STATEMENT_TYPES := 'SELECT';

AUDIT_TRAIL := 1;

AUDIT_COLUMN_OPTS := 0;

SYS.DBMS_FGA.ADD_POLICY ( OBJECT_SCHEMA, OBJECT_NAME, POLICY_NAME, AUDIT_CONDITION, AUDIT_COLUMN, HANDLER_SCHEMA, HANDLER_MODULE, ENABLE, STATEMENT_TYPES, AUDIT_TRAIL, AUDIT_COLUMN_OPTS );

COMMIT;

END;

OBJECT_SCHEMA: ﻭﻫﻰ ﺘﻌﻨﻰ ﺍﻟﻤﺴﺘﺨﺩﻡ ﺍﻟﺫﻱ ﻴﺤﻭﻯ ﺍﻟﺠﺩﻭل ﺃﻭ ﺍﻟﻜﺎﺌﻥ ﺍﻟﺫﻱ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﻋﺒﺎﺭﺍﺕ ﺍلSELECT ﻋﻠﻴﻪ.

OBJECT_NAME: ﻭﻫﻭ ﺍﻟﻜﺎﺌﻥ ﺍﻟﺫﻱ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺔ ﻋﺒﺎﺭﺍﺕ ﺍلSELECT ﻋﻠﻴﻪ.

POLICY_NAME: ﻭﻫﻭ ﺍﺴﻡ ﺍلPOLICY AUDIT ﺍﻟﺘﻲ ﻨﺭﻴﺩ ﺨﻠﻘﻬﺎ.

AUDIT_CONDITION: ﻭﻫﻰ ﻟﺘﺤﺩﻴﺩ ﺍﻟﺸﺭﻭﻁ ﻟﺘﺭﻜﻴﺯ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ.

AUDIT_COLUMN: ﻭﻫﻭ ﺍﻟﻌﻤﻭﺩ ﺍﻟﺫﻱ ﻨﺭﻴﺩ ﺘﺭﻜﻴﺯ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ ﻋﻠﻴﻪ.

HANDLER_SCHEMA: ﺃﺤﻴﺎﻨﹰﺎ ﻗﺩ ﻨﺤﺘﺎﺝ ﻟﺘﺤﺩﻴﺩ ﺇﺠﺭﺍﺀ Procedure ﻟﻴﻘﻭﻡ ﺒﺒﻌﺽ ﺍﻷﺤﺩﺍﺙ ﺍﻹﻀﺎﻓﻴﺔ ﺃﺜﻨﺎﺀ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺭﺍﻗﺒﺔ، ﻓﻨﻘﻭﻡ ﻫﻨﺎ ﺒﺘﺤﺩﻴﺩ ﺍﻟﻤﺴﺘﺨﺩﻡ ﺍﻟﺫﻱ ﻴﺤﻭﻯ ﻫﺫﺍ ﺍﻹﺠﺭﺍﺀ.

ENABLE : ﻟﺘﻔﻌﻴل ﻋﻤل POLICY AUDIT ﻭﻴﺄﺨﺫ ﻫﺫﺍ ﺍﻟﻤﺘﻐﻴﺭ ﺍﻟﻘﻴﻤﺔ TRUE في الوضع الإفتراضي.

STATEMENT_TYPES : ﻟﺘﺤﺩﻴﺩ ﻨﻭﻉ ﻋﺒﺎﺭﺍﺕ ﺍلSQL ﺍﻟﺘﻲ ﻨﺭﻴﺩ ﻤﺭﺍﻗﺒﺘﻬﺎ والافتراضي SELECT.

AUDIT_TRAIL: ﻟﺘﺨﺯﻴﻥ ﻋﺒﺎﺭﺍﺕ ﺍلSQL ﺍﻟﻤﺭﺍﻗﺒﺔ ﻓﻲ ﺍل.AUDIT_TRAIL.

AUDIT_COLUMN_OPTS: ﻤﺎﺫﺍ ﻟﻭ ﻗﻤﺕ ﺒﺘﺤﺩﻴﺩ ﻋﺩﺩ ﻤﻥ ﺍﻷﻋﻤﺩﺓ ﻓﻲ ﺍﻟﻤﺘﻐﻴﺭ AUDIT_COLUMN، ﻫﻨﺎ ﻟﺘﺤﺩﻴﺩ ﻫل (ALL OR ANY).

ﺍﻵﻥ ﻤﺎﺫﺍ ﻟﻭ ﻗﺎﻡ ﺍﻟﻤﺴﺘﺨﺩﻡ EMP ﺒﻌﻤل ﺍﺴﺘﻌﻼﻡ ﻋﻠﻰ ﺍﻟﺠﺩﻭل BOOK ﺍﻟﻤﻨﺘﻤﻰ ﻟﻠﻤﺴﺘﺨﺩﻡ TEST ﺒﻨﻔﺱ ﺍﻟﺸﺭﻭﻁ ﺍﻟﻤﺫﻜﻭﺭﺓ ﺃﻋﻼﻩ ؟

SELECT * FROM TEST.BOOK WHERE BOOK_NO=1;

ﻴﺴﺘﻁﻴﻊ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻵﻥ ﻤﺘﺎﺒﻌﺔ ﻫﺫﺍ ﺍﻻﺴﺘﻌﻼﻡ.

SELECT USERHOST,OS_USER,DB_USER,TO_CHAR(TIMESTAMP,'DD-MM- YY:HH-MI-SS'),SQL_TEXT FROM DBA_FGA_AUDIT_TRAIL WHERE DB_USER='EMP;

ﻟﻭ ﻗﺎﻡ ﺍﻟﻤﺴﺘﺨﺩﻡ EMP ﺒﻌﻤل ﺍﺴﺘﻌﻼﻡ ﺁﺨﺭ ﻟﻡ ﺘﺘﺤﻘﻕ ﻓﻴﻪ ﺍﻟﺸﺭﻭﻁ ﺍﻟﻤﻭﻀﺤﺔ ﻓﻲ ﺍﻹﺠﺭﺍﺀ ADD_POLICY ﻓﺈﻥ ﻤﻌﻠﻭﻤﺎﺕ ﻫﺫﺍ ﺍﻻﺴﺘﻌﻼﻡ ﻟﻥ ﺘﻅﻬﺭ ﻟﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ.

ﺒﺎﻟﻁﺒﻊ ﻴﺴﺘﻁﻴﻊ ﻤﺩﻴﺭ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ ﺍﻻﺴﺘﻌﻼﻡ ﻋﻥ AUDIT_POLICIES ﺍﻟﺘﻲ ﺘﻌﻤل ﻓﻲ ﻗﺎﻋﺩﺓ DBA_AUDIT_POLICIES.

SELECT POLICY_NAME,OBJECT_SCHEMA,OBJECT_NAME,POLICY_COLUM N,SEL FROM DBA_AUDIT_POLICIES;

ﻴﻤﻜﻥ ﺘﻌﻁﻴل ﻫﺫﻩ ﺍلPOLICY AUDIT ﺒﻭﺍﺴﻁﺔ ﺍﻹﺠﺭﺍﺀ DISABLE_POLICY.

DECLARE

OBJECT_SCHEMA VARCHAR2(200);

OBJECT_NAME VARCHAR2(200);

POLICY_NAME VARCHAR2(200);

BEGIN

OBJECT_SCHEMA := 'TEST'; OBJECT_NAME := 'BOOK'; POLICY_NAME := 'BOOK_SELECT';

SYS.DBMS_FGA.DISABLE_POLICY ( OBJECT_SCHEMA, OBJECT_NAME, POLICY_NAME );

COMMIT;

END;

ﻜﻤﺎ ﻴﻤﻜﻥ ﺘﻔﻌﻴﻠﻬﺎ ﻤﺭﻩ ﺃﺨﺭﻯ ﺒﻭﺍﺴﻁﺔ ﺍﻹﺠﺭﺍﺀ ENABLE_POLICY.

DECLARE

OBJECT_SCHEMA VARCHAR2(200);

OBJECT_NAME VARCHAR2(200);

POLICY_NAME VARCHAR2(200);

BEGIN

OBJECT_SCHEMA := 'TEST';

OBJECT_NAME := 'BOOK';

POLICY_NAME := 'BOOK_SELECT';

SYS.DBMS_FGA.ENABLE_POLICY ( OBJECT_SCHEMA, OBJECT_NAME, POLICY_NAME );

COMMIT;

END;

ﻭﺃﺨﻴﺭﺍ ﻴﻤﻜﻥ ﺤﺫﻑ POLICY AUDIT ﺒﻭﺍﺴﻁﺔ ﺍﻹﺠﺭﺍﺀ DROP_POLICY.

DECLARE

OBJECT_SCHEMA VARCHAR2(200);

OBJECT_NAME VARCHAR2(200);

POLICY_NAME VARCHAR2(200);

BEGIN

OBJECT_SCHEMA := 'TEST';

OBJECT_NAME := 'BOOK';

POLICY_NAME := 'BOOK_SELECT';

SYS.DBMS_FGA.DROP_POLICY ( OBJECT_SCHEMA, OBJECT_NAME, POLICY_NAME );

COMMIT;

END;

ﺍﻵﻥ ﻟﻭ ﻗﻤﺕ ﺒﻌﻤل ﺍﺴﺘﻌﻼﻡ ﻋﻥ ﺍلAUDIT_POLICIES ﻓﻠﻥ ﺘﺠﺩ ﻫﺫﻩ ﺍلPOLICY ﻓﻲ ﻗﺎﻋﺩﺓ البيانات.

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

DATABASE

SQL

VIDEOS

Orcale Tutorial Content

Database Security & Monitoring - تأمين ومراقبة قاعدة البيانات

ﻤﺭﺍﻗﺒﺔ ﻗﺎﻋﺩﺓ ﺍﻟﺒﻴﺎﻨﺎﺕ - AUDITING

ﻭﻫﺫﺍ ﺍﻟﻨﻭﻉ ﻤﻥ ﺍﻟﻤﺭﺍﻗﺒﺔ Standard Database Auditing ﻴﺤﺘﻭﻯ ﻋﻠﻰ ﺃﻗﺴﺎﻡ فرعية:-