एसक्यूएल

में अक्षम/सक्षम ट्रिगर्स के लिए लेखापरीक्षा जब कोई हमारे डेटाबेस में एक ट्रिगर को सक्षम या अक्षम करने का प्रयास करता है तो मुझे ऑडिट करने का एक तरीका चाहिए। DDL ट्रिगर विकल्प महान लेकिन केवल तभी जब उपयोगकर्ता का उपयोग करताएसक्यूएल

ALTER TABLE <tableName> ENABLE TRIGGER <triggerName>

या

ALTER TABLE <tableName> DISABLE TRIGGER <triggerName>

बयान के लिए शर्त के तहत काम करता है। मैं क्या निर्धारित किया है से, DDL विधि बेकार renders उपयोगकर्ता निम्नलिखित बयान है कि ALTER आदेश बाईपास कार्यान्वित करता है, तो:

DISABLE TRIGGER <triggerName> ON <tableName> 
ENABLE TRIGGER <triggerName> ON <tableName>

मैं कब्जा इन घटनाओं उनमें से कोई भी काम पर कई विचार किया है। इनमें से एक था अगर मैं sys.triggers दृश्य के अंतर्गत तालिका तक पहुंच सकता था, तो मैं उस तालिका पर एक सम्मिलित/अद्यतन ट्रिगर रख सकता था और ऑडिट प्राप्त करने के लिए ट्रिगर नाम पर फ़िल्टर कर सकता था; लेकिन मेरा संदेह यह है कि यह संभवतः अनंत पुनरावृत्ति का कारण बनता है, भले ही ऐसा करना संभव हो।

क्या किसी के पास इस समस्या के वैकल्पिक समाधान के लिए कोई संभावित सुझाव है? मुझे समझ में नहीं आ रहा है कि क्यों एमएस लेखा परीक्षा के दायरे से बचने के लिए कथन के उन्नत संस्करणों की अनुमति देगा। यही है, सबसे सरल तरीकों से लेखा परीक्षा; एसक्यूएल प्रोफाइलर का उपयोग इस के लिए अनचाहे ओवरहेड लगता है।

स्रोत

2011-10-24 Mark

वाह - क्या आप कह रहे हैं कि सक्षम ट्रिगर ... चालू ... वाक्यविन्यास एसक्यूएल 2008 डीडीएल ऑडिट को बाईपास करता है? http://msdn.microsoft.com/en-us/library/dd392015(v=sql.100).aspx – StuartLC

बस डीएमएल संभवतः ट्रिगर करता है जैसे कि कोई डीडीएल ट्रिगर्स को अक्षम कर सकता है, वे आपके ऑडिट ट्रिगर को भी अक्षम कर सकते हैं? यह मुझे लगता है कि डिफ़ॉल्ट निशान में दर्ज किया गया है। –

हाँ, कोई वाक्य रचना अक्षम TRIGGER पर तो मैं एक DDL ट्रिगर के माध्यम से उस घटना पर कब्जा करने का कोई तरीका नहीं होता है का उपयोग कर मेरी DML ट्रिगर निष्क्रिय करने के लिए थे। – Mark

मैं पहले इसे अनुमतियों के माध्यम से संबोधित करता हूं। कुछ डीबीए को छोड़कर कोई भी प्रोड पर तालिका अनुमतियों को बदलना चाहिए और इस प्रकार ट्रिगर को सक्षम या अक्षम नहीं कर सकता है। यदि कोई एप्लिकेशन इसका उपयोग कर रहा है, तो इसे रोकना चाहिए। किसी भी उपयोगकर्ता को तालिकाओं को बदलने की आवश्यकता के लिए कोई बहाना नहीं है। यदि आप ऐसा करना चाहते हैं, तो आपके पास एक डिज़ाइन दोष है। यदि आपके पास वास्तविक रूप से ट्रिगर अक्षम करने वाले लोग हैं, तो आपके पास निश्चित रूप से एक डिज़ाइन दोष है। कोड समीक्षा के दौरान इसमें अक्षम ट्रिगर वाला कोई भी कोड एक बड़ा लाल झंडा होना चाहिए। यह एप्लिकेशन कोड में एक ट्रिगर को अक्षम करने के लिए अस्वीकार्य होना चाहिए। यह ऐसा कुछ है जो केवल डीबीए द्वारा किया जाना चाहिए जिनके पास यह जानने का अनुभव है कि इसे कब करना है। यदि आप एप्लिकेशन कोड लिख रहे हैं और आपके कोड को काम करने के लिए ट्रिगर को अक्षम करने की आवश्यकता है, तो आपका कोड गलत है या ट्रिगर को फिर से लिखना होगा, ट्रिगर को अक्षम करना केवल दुर्लभ मामलों में होना चाहिए।

स्रोत

2011-10-24 17:25:02 HLGEM

मेरी इच्छा है कि मैं फिर से उभारा सकता हूं। एसक्यूएल टूटा नहीं गया है क्योंकि आप ट्रिगर्स को अक्षम करने वाले लोगों का ऑडिट नहीं कर सकते हैं, नीति टूट गई है क्योंकि जिन लोगों पर भरोसा नहीं है वे बहुत अधिक शक्ति रखते हैं। –

जबकि हर कोई अपनी राय के लिए सही हकदार है और मैं यह भी मानता हूं कि सिस्टम का शासन समान रूप से महत्वपूर्ण है; मैं दृढ़ता से असहमत हूं कि इस प्रकार की घटनाओं को दोषपूर्ण नहीं होने की अक्षमता में असमर्थता। कहने के लिए यह कहना होगा कि समान घटनाओं का ऑडिट करने की क्षमता अलग-अलग वाक्यविन्यास के साथ एक सुरक्षा उपकरण के विपरीत एक लक्जरी है। अन्यथा, डीडीएल मॉडल से ट्रिगर्स की ऑडिटिंग को पूरी तरह से क्यों न हटाएं? इसका एक और पक्ष यह है कि यह प्रशासन नीतियों के लिए एक दोष है या नहीं; यह जानना कि आपके सिस्टम पर घटनाओं को निष्पादित करना कौन जरूरी है। – Mark

मैं मानता हूं कि यह एक दोष है, लेकिन लोगों को ऐसी चीजों को करने का अधिकार एक बड़ी गड़बड़ी है। – HLGEM

एसक्यूएल

उत्तर

संबंधित मुद्दे