ALTER TABLE अनुमति देना कितना खतरनाक है?

Question

निम्नलिखित परिदृश्य की कल्पना करें

CREATE DATABASE test

GO

USE test;    

CREATE TABLE dbo.Customer
  (
     CustomerId   INT,
     Email        VARCHAR(100),
     SensitiveData VARCHAR(20)
  );

INSERT INTO dbo.Customer
VALUES     (1,'[e-mail]','12346789');

कुछ बिंदु पर एक ईटीएल प्रक्रिया लिखी जाती है जो testडेटाबेस में कुछ गतिविधियाँ करती है।

CREATE USER etlUser WITHOUT LOGIN; /*For demo purposes*/

CREATE TABLE dbo.StagingTable
  (
     StagingTableId INT,
     SomeData       VARCHAR(100),
  )

GRANT UPDATE,INSERT,DELETE,SELECT,ALTER ON dbo.StagingTable TO etlUser;

DENY SELECT ON dbo.Customer TO etlUser;
DENY SELECT ON dbo.Customer (SensitiveData) TO etlUser; /*For good measure*/

EtlUser के पास Customerतालिका के लिए अनुमतियाँ नहीं होनी चाहिए (और निश्चित रूप से SensitiveDataस्तंभ के लिए नहीं ) तो ये स्पष्ट रूप से ऊपर से वंचित हैं।

ETL प्रक्रिया ट्रंकटेट करती है, dbo.StagingTableइसलिए ALTERउस पर तालिका की अनुमति दी जाती है।

इसे सुरक्षा ऑडिट के दौरान चिह्नित किया जाता है। यह परिदृश्य कितना खतरनाक है?

Comments

अन्य तालिका ADD COLUMN जैसी अपेक्षाकृत हानिरहित क्रियाएँ अन्य कार्यों (ALTER, DROP, बाधाओं, ट्रिगर) के समान क्यों मानी जाती हैं?

— 22

Answer 1

बहुत खतरनाक ...

StagingTableस्वयं की संरचना को बदलने के लिए स्पष्ट अनुमति के अलावा ALTER TABLEअनुमति उन्हें मेज पर ट्रिगर्स बनाने की अनुमति देती है। इसलिए इस मामले में स्वामित्व के माध्यम से वे दोनों संवेदनशील ग्राहक डेटा (स्पष्ट DENYअनुमति के बावजूद ) देखने में सक्षम हैं और इस दूसरी मेज पर बर्बरता करते हैं।

EXECUTE AS user='etlUser'

GO

CREATE OR ALTER TRIGGER TR ON dbo.StagingTable AFTER UPDATE AS 
/*Exposure of sensitive data*/
SELECT * FROM dbo.Customer;

/*Vandalism*/
DELETE FROM dbo.Customer;

go

--Fire the trigger
UPDATE dbo.StagingTable SET SomeData = SomeData WHERE 1=0;

REVERT

Answer 2

ट्रिगर्स जोड़ने में सक्षम होने के अलावा, ALTER TABLE अनुमति भी इसके लिए अनुमति देता है:

1. ट्रिगर अक्षम करना (ऑडिट ट्रेल से बचें)
2. अड़चनें (खराब डेटा की अनुमति)
3. दूषित कंटेंट (खराब डेटा के लिए अनुमति)
4. स्तंभ परिभाषाओं में परिवर्तन (परिवर्तन डेटाटाइप, अधिकतम आकार, पूर्णता)
5. एक कंप्यूटेड कॉलम जोड़ें जो T-SQL UDF कहता है (समानांतर योजना प्राप्त करना बहुत मुश्किल है, जो प्रदर्शन को आसानी से चोट पहुंचा सकता है)

यह स्तंभों को हटाने के लिए भी अनुमति देता है, लेकिन यह किसी का ध्यान नहीं जाने की संभावना है (क्योंकि ऐसा लगता है कि हम यहां संभावित कार्यों की तलाश कर रहे हैं जो दुर्भावनापूर्ण से अधिक भ्रामक हैं)।

सौभाग्य से, किसी को भी यह अनुमति देना आवश्यक नहीं है, और न ही इसे किसी संग्रहीत प्रक्रिया में लपेटना आवश्यक है जो EXECUTE ASखंड (आमतौर पर 'dbo'या उसके बाद OWNER) का उपयोग करता है । मॉड्यूल साइनिंग हस्ताक्षरित कोड (संग्रहीत प्रक्रियाओं, ट्रिगर, स्केलर UDFs, और मल्टी-स्टेटमेंट TVFs) के पीछे विशेषाधिकार प्राप्त कार्यों के आसान अमूर्तता के लिए अनुमति देता है। मेरे पास उदाहरण कोड है जो निम्नलिखित उत्तरों में इसे पूरा करने का तरीका दिखा रहा है, यहाँ DBA.SE पर:

• एसक्यूएल अनुमति ट्रंकट टेबल के लिए
• SQL सर्वर TRUNCATE टेबल अनुमतियाँ

उन दो उत्तरों के बीच का अंतर हस्ताक्षर-आधारित उपयोगकर्ता को दी गई अनुमति है। दी जाने वाली अनुमति (या डीबी रोल को जोड़ा जाना) उस दायरे पर निर्भर करता है, जिसकी आवश्यकता है। यदि आपको केवल एक तालिका के लिए अनुमति की आवश्यकता है, तो केवल ALTERउस तालिका पर अनुदान दें। यदि किसी विशिष्ट स्कीमा में सभी तालिकाओं के लिए अनुमति आवश्यक है, तो व्यक्तिगत तालिकाओं को अनुमति न दें, बल्कि स्कीमा को ही अनुमति दें। और इसी तरह।

ईटीएल उपयोगकर्ता के लिए स्कीमा बनाने, या EXECUTE ASक्लॉज का उपयोग करने की तुलना में मॉड्यूल हस्ताक्षर कुछ अतिरिक्त कदम हैं , लेकिन:

1. यह वास्तव में सिर्फ एक सरल कॉपी और पेस्ट है जिसे कोड ऊपर दिए गए दोनों उत्तरों में उपलब्ध है, और
2. यह निश्चित रूप से सबसे सुरक्षित विकल्प उपलब्ध है। यह केवल उस कोड के माध्यम से उस ऑपरेशन की अनुमति देता है, और केवल EXECUTEउस कोड को अनुमति देता है। स्कीमा का मालिक होने के नाते कुछ निहित अनुमति के लिए अनुमति देता है जो अनावश्यक हैं। और, मालिक का उपयोग करना ( EXECUTE AS 'dbo'या EXECUTE AS OWNERमान लेना dbo) पूरी प्रक्रिया देगा , उस बिंदु से आगे, dboअनुमतियाँ, न कि केवल संग्रहीत प्रक्रिया / ट्रिगर / फ़ंक्शन जो आपने उपयोग EXECUTE ASकिया था। मॉड्यूल हस्ताक्षर करने की अनुमति केवल उस कोड को देती है, जिस पर आपने हस्ताक्षर किए थे, और हस्ताक्षरित कोड द्वारा बुलाया गया कोई कोड नहीं।

Comments

कुछ प्रणालियों (कम से कम कुछ MySQL संस्करणों) के साथ एक प्रभावी तरीके से वास्तु स्तंभ को प्रभावी ढंग से नष्ट करने का एक तरीका है, इसके बिना कार्यक्रमों को तुरंत देखा जा सकता है: इसका आकार कम करें 0. यह इसे हटा देगा, और चुपचाप कुछ भी लिखा जाएगा यह ...

— रैकैंडबॉमनमैन

Answer 3

ईटीएल उपयोगकर्ता के स्वामित्व में एक बेहतर अभ्यास एक स्टेजिंग स्कीमा बनाना होगा। तब ईटीएल प्रक्रिया स्टैगिंग स्कीमा के भीतर तालिकाओं को कम कर सकती है, बाधाओं को अक्षम कर सकती है, विभाजन स्विचिंग आदि कर सकती है। ETL उपयोगकर्ता को केवल अन्य स्कीमा पर सीमित अनुमति की आवश्यकता होगी।

आप एकल उपयोगकर्ता के बजाय डेटाबेस भूमिका का भी उपयोग कर सकते हैं।

बेशक, आप अपने सीमित उपयोगकर्ता को इस तरह से एक dbo- स्वामित्व वाली संग्रहीत कार्यविधि के साथ तालिका truncations करने में सक्षम कर सकते हैं:

create procedure truncate_t 
with execute as owner
as
begin
  truncate table t;
end