DDL_admin बनाम db_owner अनुमतियाँ

मैं एक परियोजना ले रहा हूं जिसमें हमारे सर्वर फ़ार्म में सभी डेटाबेस उपयोगकर्ताओं की अनुमतियों को निकालना और सीमित करना शामिल है। (मनोरंजन समय)

वर्तमान में सीमित अनुमतियों में से एक db_owner अनुमतियाँ है।
इस अनुमति की समीक्षा केस-बाय-केस आधार पर की जा रही है, लेकिन db_owner अनुमतियों को निम्न के साथ बदलना एक सामान्य परिवर्तन है:

db_datareader
db_datawriter
db_ddladmin
db_executor

मैं दोनों के बीच सटीक अंतर को परिभाषित करना चाहता हूं (ग्राहकों को सूचित करना)।
हालाँकि, जहाँ तक मैं बता सकता हूँ, दोनों के बीच अंतर होना चाहिए:

db_accessadmin अनुमतियाँ
db_backupoperator अनुमतियाँ
db_securityadmin अनुमतियाँ

तो प्रभाव में वे खो देगा:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE],[ALTER ANY ROLE]
[DROP DATABASE]

क्या कुछ और है जो एक उपयोगकर्ता db_owner को ऊपर की चार भूमिकाओं द्वारा प्रतिस्थापित करने के बाद ढीला कर देगा?
क्या यह वास्तव में एक उद्देश्य सुरक्षा वार की बहुत सेवा करता है?

sql-server permissions

— Reaces
स्रोत

जवाबों:

db_ddladmin बनाम db_owner

जो मैंने परीक्षण किया और जिस पर पढ़ा, उससे मैं बता सकता हूं कि अधिकांश भाग के लिए आपकी सूची सटीक दिखती है, केवल db_ddladminडीईईएस आपको अनुमति नहीं देता है CREATE SCHEMA। मैंने पुष्टि की कि आपके द्वारा सूचीबद्ध अन्य सुरक्षा अनुमतियाँ वास्तव में अस्वीकृत थीं।

केवल DDLADMIN के साथ अस्वीकृत:

[ALTER ANY USER]

[BACKUP DATABASE], [BACKUP LOG],[CHECKPOINT]

[ALTER ANY APPLICATION ROLE], [ALTER ANY ROLE]

[DROP DATABASE]

यह देखते हुए कि। । ।

db_datareaderSELECTसभी तालिकाओं तक पहुंच की अनुमति देगा
db_datarwriterअनुमति देगा INSERT, UPDATEऔर DELETEसभी तालिकाओं तक पहुँच देगा
db_executorEXECUTEसभी निष्पादन योग्य वस्तुओं तक पहुंच की अनुमति देगा

Additonally, db_ddladmin भूमिका अनुमतियाँ होने का मतलब हो सकता है। । ।

नोट: चूंकि आपके पास 2005 - 2014 से SQL सर्वर के इतने अलग-अलग संस्करण हैं, इसलिए यह शुरू करने के लिए उपयोगकर्ताओं के एक छोटे से सेट का परीक्षण करना सबसे अच्छा हो सकता है, यह देखने के लिए कि कौन किसी भी किंक आदि को बाहर करने के लिए चिल्लाता है।

यदि वे इस भूमिका के मालिक हैं, तो वे डीबीओ के स्वामित्व में नहीं होंगे, इसलिए आपको स्वामित्व जप के मुद्दों से निपटना पड़ सकता है, यदि इस स्तर पर कभी किसी चीज की समस्या है। मैं 100% निश्चित नहीं हूं कि यह एक समस्या होगी लेकिन यह सिर्फ मामले में उल्लेख के लायक है।

स्रोत: स्वामित्व जंजीरों
इस भूमिका के साथ (एसक्यूएल सर्वर के संस्करण के आधार पर भिन्न हो सकते हैं) वे वर्तमान डीबी में परिभाषित एसक्यूएल सुरक्षा सिद्धांतों को उन वस्तुओं में जोड़ने में सक्षम हो सकते हैं जो अभी भी उनके पास हैं , न कि सभी ऑब्जेक्ट्स (जिनके पास वे स्वयं नहीं हैं) और न ही एक नया सर्वर जोड़ें -लेवल परिभाषित प्रिंसिपल को DB स्तर पर।

इसके अतिरिक्त, DBO भूमिका की अनुमति नहीं होने का मतलब हो सकता है। । ।

नोट: चूंकि आपके पास 2005 - 2014 से SQL सर्वर के इतने अलग-अलग संस्करण हैं, इसलिए यह शुरू करने के लिए उपयोगकर्ताओं के एक छोटे से सेट का परीक्षण करना सबसे अच्छा हो सकता है, यह देखने के लिए कि कौन किसी भी किंक आदि को बाहर करने के लिए चिल्लाता है।

DBO की भूमिका नहीं होने से कुछ SSMS डिज़ाइनर GUI इंटरफेस (SQL सर्वर संस्करण अलग-अलग) को बिना किसी त्रुटि के पॉप्युलेट या ओपन करने से रोका जा सकता है (उदाहरण के लिए GUI के माध्यम से टेबल या कॉलम को संशोधित करते हुए) भले ही यह T-SQL कार्यों और अनुमतियों के माध्यम से हो। । SQL सर्वर के कुछ संस्करणों में GRANT VIEW DEFINITIONजहां यह एक समस्या है, यह अनुमति देकर हल किया जा सकता है और यह केवल SQL सर्वर के कुछ संस्करणों पर चेतावनी भी हो सकती है।

साधन
- आप डेटाबेस के स्वामी या db_owner भूमिका के सदस्य के रूप में लॉग इन नहीं होते हैं। आप उन तालिकाओं में परिवर्तन नहीं बचा पाएंगे जो आपके पास नहीं हैं।
- db_ddladmin भूमिका SSMS में "डिज़ाइन" फ़ंक्शन के उपयोग की अनुमति नहीं देती है
  _{"हम अपने क्यूए डेटाबेस में उपयोगकर्ताओं / डेवलपर्स डीबीओ को जितना हो सके, देने से रोकने की कोशिश करते हैं। इसके साथ समस्याओं में से एक यह है कि उन्हें अभी भी डेटाबेस टेबल जैसे उपयोगकर्ता टेबल बनाने और संशोधित करने में सक्षम होने की आवश्यकता है। कई देव नए हैं। MS SQL और इस तरह से इस तरह के काम के लिए GUI (SSMS) से चिपके रहते हैं। समस्या तब उत्पन्न होती है जब हम उन्हें db_ddladmin (dbo नहीं) प्रदान करते हैं और वे तालिका डिज़ाइनर GUI के माध्यम से तालिकाओं या स्तंभों को संशोधित करने में सक्षम नहीं होते हैं। उन्हें TSQL कमांड और उनके सिंटैक्स को सीखने के लिए अतिरिक्त समय लेना पड़ता है (ताकि उन्हें फिर कभी ज़रूरत न हो) या डीबीए टीम को संलग्न करें जो हमारी अन्य गतिविधियों से समय लेता है।}
  
  _{मुझे नहीं पता कि यह बग या फीचर अनुरोध है, लेकिन मैं इसे बग मानता हूं क्योंकि उपयोगकर्ता के पास TSQL के माध्यम से तालिका को बदलने की पर्याप्त अनुमति है लेकिन जीयूआई उन्हें संदेश देता है:}
  
  _{" आप डेटाबेस के स्वामी या सिस्टम व्यवस्थापक के रूप में लॉग ऑन नहीं हैं। आप उन तालिकाओं में परिवर्तन सहेजने में सक्षम नहीं हो सकते हैं जो आपके पास नहीं हैं।" और "तालिका [schema].[table]केवल पढ़ने के लिए सेट की गई है, इस तालिका में उपयोगकर्ता के पास पर्याप्त अधिकार नहीं हैं। "}
  
  _{एक ट्रेस चेक को एक is_member ('db_owner') होने की ओर इशारा करता है, जो db_ddladmin के सदस्यों को शामिल नहीं करेगा, भले ही उनके पास वास्तव में ऑब्जेक्ट को संशोधित करने की अनुमति हो। Microsoft SQL सर्वर प्रबंधन स्टूडियो "}
  
  _{_{एजेंट डीबीए द्वारा 1/25/2010 को 7:06 बजे पोस्ट किया गया}}
  
  _{मेरे पास एक समान मुद्दा था और निम्नलिखित अनुदान प्रदर्शन करके इसे हल करने में कामयाब रहा}
```
GRANT view definition on schema:: <schemaname> to <username>
```

अन्य बातें

चूंकि आप कहते हैं कि इस मामले की समीक्षा केस-बाय-केस आधार पर की जा रही है

वर्तमान में सीमित अनुमतियों में से एक db_owner अनुमतियाँ है।

इस अनुमति की समीक्षा केस-बाय-केस आधार पर की जा रही है, लेकिन db_owner अनुमतियों को निम्न के साथ बदलना एक सामान्य परिवर्तन है:

db_datareader

db_datawriter

db_ddladmin

db_executor

क्या आपने "सभी ऑब्जेक्ट" डीबी-स्तरीय पहुंच के लिए अतिरिक्त कस्टम भूमिकाएं बनाने पर विचार किया है जो प्रत्येक व्यक्ति को उन्हें देने के बजाय आवश्यक है db_ddladmin भूमिका क्योंकि संभवतः उन्हें डीबी स्तर की वस्तुओं के साथ-साथ उन्हें और भी अधिक आवश्यकता होगी।

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

----Custom Database Roles

/* CREATE A NEW ROLE  -- Execute to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_Execute
GRANT EXECUTE TO db_All_StoredProc_Execute

/* CREATE A NEW ROLE  -- Alter to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_Alter
GRANT ALTER ANY SCHEMA TO db_All_StoredProc_Alter

/* CREATE A NEW ROLE  -- View Definition to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_View
GRANT VIEW DEFINITION TO db_All_StoredProc_View

/* CREATE A NEW ROLE - Any schema alter and create procedure permissions */
-- Database specific
CREATE ROLE db_All_CreateProc_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateProc_AlterSchema
GRANT CREATE PROCEDURE TO db_All_CreateProc_AlterSchema
GO

/* CREATE A NEW ROLE - Any schema alter and create table permissions */
-- Database specific
CREATE ROLE db_All_CreateTable_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateTable_AlterSchema
GRANT CREATE TABLE TO db_All_CreateTable_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create function permissions */
-- Database specific
CREATE ROLE db_All_CreateFunction_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateFunction_AlterSchema
GRANT CREATE FUNCTION TO db_All_CreateFunction_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create aggregate permissions */
-- Database specific
CREATE ROLE db_All_CreateAggregate_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateAggregate_AlterSchema
GRANT CREATE AGGREGATE TO db_All_CreateAggregate_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create view permissions */
-- Database specific
CREATE ROLE db_All_CreateView_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateView_AlterSchema
GRANT CREATE VIEW TO db_All_CreateView_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create schema permissions */
-- Database specific
CREATE ROLE db_All_CreateSchema_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateSchema_AlterSchema
GRANT CREATE SCHEMA TO db_All_CreateSchema_AlterSchema

मैं एक db_DDLAdmin_Restriction भूमिका भी साझा करना चाहता था जिसे आप बनाने पर विचार करना चाहते हैं अन्यथा स्पष्ट रूप DENYसे प्रतिबंधित कर सकते हैं कि क्या db_ddladminपहुँच प्रदान करें ताकि आप कम से कम DBs पर इसे बना सकें जहाँ आप उन्हें यह भूमिका प्रदान करते हैं और DENYवास्तविक ऑब्जेक्ट प्रकारों के लिए स्पष्ट सेट करते हैं , आदि तुम उन्हें करने के लिए उपयोग नहीं करना चाहते हैं।

उदाहरण के लिए, यदि आप जानते हैं वे निश्चित रूप से संग्रहित प्रक्रियाओं और कार्यों बनाने हो, आप निकाल सकते हैं होगा DENY CREATE FUNCTION, DENY CREATE PROCEDURE, DENY ALTER ANY SCHEMA।

---Create ddladmin restriction custom DB role
DENY ALTER ANY ASSEMBLY                    TO db_DDLAdmin_Restriction
DENY ALTER ANY ASYMMETRIC KEY              TO db_DDLAdmin_Restriction
DENY ALTER ANY CERTIFICATE                 TO db_DDLAdmin_Restriction
DENY ALTER ANY CONTRACT                    TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE DDL TRIGGER        TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE EVENT NOTIFICATION TO db_DDLAdmin_Restriction
DENY ALTER ANY DATASPACE                   TO db_DDLAdmin_Restriction
DENY ALTER ANY FULLTEXT CATALOG            TO db_DDLAdmin_Restriction
DENY ALTER ANY MESSAGE TYPE                TO db_DDLAdmin_Restriction
DENY ALTER ANY REMOTE SERVICE BINDING      TO db_DDLAdmin_Restriction
DENY ALTER ANY ROUTE                       TO db_DDLAdmin_Restriction
DENY ALTER ANY SCHEMA                      TO db_DDLAdmin_Restriction
DENY ALTER ANY SERVICE                     TO db_DDLAdmin_Restriction
DENY ALTER ANY SYMMETRIC KEY               TO db_DDLAdmin_Restriction
DENY CHECKPOINT                            TO db_DDLAdmin_Restriction
DENY CREATE AGGREGATE                      TO db_DDLAdmin_Restriction
DENY CREATE DEFAULT                        TO db_DDLAdmin_Restriction
DENY CREATE FUNCTION                       TO db_DDLAdmin_Restriction
DENY CREATE PROCEDURE                      TO db_DDLAdmin_Restriction
DENY CREATE QUEUE                          TO db_DDLAdmin_Restriction
DENY CREATE RULE                           TO db_DDLAdmin_Restriction
DENY CREATE SYNONYM                        TO db_DDLAdmin_Restriction
DENY CREATE TABLE                          TO db_DDLAdmin_Restriction
DENY CREATE TYPE                           TO db_DDLAdmin_Restriction
DENY CREATE VIEW                           TO db_DDLAdmin_Restriction
DENY CREATE XML SCHEMA COLLECTION          TO db_DDLAdmin_Restriction
DENY REFERENCES                            TO db_DDLAdmin_Restriction
GO

— दलाल जूस आईटी
स्रोत

सभी अनुमतियों को सूचीबद्ध करने के लिए SQL स्क्रिप्ट का उपयोग करते हुए, मैं गया और प्रत्येक मामले के लिए उपयोगकर्ता बनाया।

EXECUTE AS USER = 'test_user'
SELECT 
    permission_name 
FROM fn_my_permissions(null, 'DATABASE')
ORDER BY subentity_name, permission_name
REVERT;

मैंने तब परिणामों की तुलना की, और मुख्य रूप से msdn से प्रलेखन के साथ निम्नलिखित सूची में आया (किसी भी विशेष रूप से संदर्भित नहीं किए गए उद्धरण msdn लिंक से हैं)।
नीचे कुछ दस्तावेज़ीकरण हैं जो मैं लोगों को सूचित करता था कि वे dbo अनुमतियाँ खो रहे हैं जो वास्तव में वे खो रहे थे।

ALTER

संपत्तियों को बदलने की क्षमता को नियंत्रित करता है, स्वामित्व को छोड़कर, एक विशेष रूप से सुरक्षित। जब किसी स्कोप पर दिया जाता है, तो ALTER उस स्कोप के भीतर निहित किसी भी सिक्योरिटी को बदलने, बनाने या छोड़ने की क्षमता को भी बेहतर बनाता है। उदाहरण के लिए, स्कीमा पर ALTER अनुमति में स्कीमा से ऑब्जेक्ट बनाने, बदलने और ड्रॉप करने की क्षमता शामिल है।

ALTER किसी भी आवेदन भूमिका
ALTER किसी भी डेटाबेस लेखा परीक्षा
ALTER किसी भी भूमिका
ALTER किसी भी उपयोगकर्ता

डेटाबेस सिक्योरेबल के अलग-अलग इंस्ट्रूमेंट्स को क्रिएट, ऑल्टर या डीआरआरपी करने की क्षमता देता है। उदाहरण के लिए, किसी भी SCHEMA डेटाबेस में किसी भी स्कीमा को बनाने, बदलने, या छोड़ने की क्षमता प्रदान करता है।

एप्लिकेशन भूमिकाएं डेटाबेस प्रिंसिपल हैं जो एप्लिकेशन को अपने स्वयं के, उपयोगकर्ता जैसी अनुमतियों के साथ चलने में सक्षम बनाती हैं।

SQL सर्वर या SQL सर्वर डेटाबेस के एक उदाहरण की ऑडिटिंग में सिस्टम पर होने वाली घटनाओं को ट्रैक करना और लॉग करना शामिल है। डेटाबेस-स्तर ऑडिट विशिष्टता ऑब्जेक्ट एक ऑडिट के अंतर्गत आता है। आप प्रति ऑडिट प्रति SQL सर्वर डेटाबेस में एक डेटाबेस ऑडिट विनिर्देश बना सकते हैं।

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

Msdn
में स्वचालित पाया गया।

क्रॉस डेटाबेस और सर्वर-एक्सेस (क्रमशः) परिदृश्यों में EXECUTE AS का उपयोग करते समय स्वचालित और स्वचालित सर्वर अनुमतियों का उपयोग किया जाता है।

बेकपेट डेटा
बैक लॉग

कनेक्ट की प्रतिक्रिया

डेटाबेस प्रतिकृति अनुमतियों के लिए उपयोग किया जाता है ।

नियंत्रण

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

रोल बनाएं

डेटाबेस सिक्योरेबल बनाने की क्षमता प्रदान करने के लिए कन्फर्मर्स।

SHOWPLAN

Showplan अनुमतियाँ विभिन्न Showplan SET स्टेटमेंट विकल्पों के लिए उपयोग की जाती हैं जब वे Transact-SQL बैचों के साथ उपयोग किए जाते हैं ।

सदस्यताएँ अधिसूचनाएँ

क्वेरी सूचनाओं के बारे में प्रलेखन।

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

स्वामित्व लेने

अनुदान प्राप्तकर्ता को उस पर स्वामित्व प्राप्त करने में सक्षम बनाता है जिस पर उसे दिया जाता है।

DATABASE STATE देखें

डायनेमिक मैनेजमेंट व्यूज़ और फ़ंक्शंस (Transact-SQL) देखने के लिए उपयोग किया जाता है ।

दृश्य देखें

परिभाषा परिभाषा को देखने पर प्रलेखन ।

VIEW DEFINITION अनुमति उपयोगकर्ता को उस सिक्योरिटी के मेटाडेटा को देखने देती है जिस पर अनुमति दी गई है। हालाँकि, दृश्य परिभाषा अनुमति सुरक्षित करने के लिए पहुँच प्रदान नहीं करता है। उदाहरण के लिए, किसी तालिका पर केवल VIEW DEFINITION अनुमति दी गई उपयोगकर्ता sys.objects कैटलॉग दृश्य में तालिका से संबंधित मेटाडेटा देख सकता है। हालाँकि, बिना अतिरिक्त अनुमतियाँ जैसे कि SELECT या CONTROL के बिना, उपयोगकर्ता तालिका से डेटा नहीं पढ़ सकता है।

— Reaces
स्रोत