उस अन्य डेटाबेस में खाते के बिना किसी अन्य डेटाबेस में तालिका के आधार पर पहुंच दृश्य

Question

मैंने डेटाबेस 1 में तालिकाओं के आधार पर डेटाबेस 1 में दृश्य बनाया। मैंने SELECTएक उपयोगकर्ता को अनुमति दी है जिसके पास केवल डेटाबेस 1 तक पहुंच है। उपयोगकर्ता को यह दृश्य काम करने के लिए नहीं मिल सकता है क्योंकि उसके पास डेटाबेस 2 में खाता नहीं है। कैसे मैं इस मुद्दे को हल कर सकता हूँ? मैं डेटाबेस 2 में खाता नहीं बनाना चाहता।

Comments

@mustaccio नहीं, यह उस अन्य प्रश्न / उत्तर का डुप्लिकेट नहीं है क्योंकि यह स्थिति सभी एक ही डेटाबेस में थी, और यह प्रश्न डेटाबेस को फैलाने के बारे में है। डिफ़ॉल्ट रूप से जिसे अनुमति नहीं है। किसी को क्रॉस-डेटाबेस स्वामित्व चाइनिंग सक्षम करना होगा, और इस तरह की संकीर्ण आवश्यकता के लिए खोलने के लिए एक बड़ा सुरक्षा छेद है।

— सोलोमन रटज़की

@SolomonRutzky, मैं DB_CHAINING को "विशाल सुरक्षा छेद" नहीं कहूंगा। विशिष्ट उत्पादन वातावरण में जहाँ केवल sysadmin भूमिका सदस्य ही ऑब्जेक्ट बना सकते हैं, यह एक गैर-समस्या है। उस ने कहा, इसका उपयोग उन मामलों में सावधानीपूर्वक किया जाना चाहिए, जहां गैर-सिसाडमिन भूमिका सदस्यों के पास उनके अलावा अन्य स्कीमाओं पर नियंत्रण की अनुमति है।

— डैन गुज़मैन

@DanGuzman "मुझ पर विश्वास करो, सब कुछ हमेशा योजना के अनुसार चलेगा" एक प्रभावी रणनीति नहीं है। उस तर्क के द्वारा, TRUSTWORTHY ONएप्लिकेशन लॉग इन करने या स्थापित करने में लगभग कोई जोखिम नहीं है sa। TRUSTWORTHYसमय पर एकमात्र समाधान होने के कारण DB स्वामित्व चैनिंग और मुख्य रूप से मौजूद है। लेकिन अब, भले ही बहुत बड़ा जोखिम न हो, लेकिन मॉड्यूल साइनिंग के बाद डीबी चेनिंग निश्चित रूप से एक अनावश्यक जोखिम है, जो कि मुश्किल नहीं है। और अगर कोई DB चेनिंग पर भरोसा करता है और फिर डायनेमिक एसक्यूएल का उपयोग करता है, तो वे TRUSTWORTHY ONइसे ठीक करने के लिए सेट होने की अधिक संभावना रखते हैं , जबकि मॉड्यूल साइनिंग के साथ यह टूट नहीं होता।

— सोलोमन रटज़की

@SolomonRutzky, अगर कोई प्रश्न एक दृश्य के बजाय एक मॉड्यूल के बारे में था, तो मैंने मॉड्यूल हस्ताक्षर करने का सुझाव दिया होगा। मेरी सोच यह है कि DB_CHAININGइंट्रा-डेटाबेस स्वामित्व की तुलना में कोई अधिक जोखिम भरा नहीं है जब वस्तुओं को वैसे ही डेटाबेस में होना चाहिए था।

— डैन गुज़मैन

@DanGuzman क्यों मान लें कि "ऑब्जेक्ट्स को वैसे ही डेटाबेस में होना चाहिए था"? ओपी ने केवल इसके विपरीत संकेत दिया है क्योंकि वे डीबी पहुंच को अलग रखना चाहते हैं। ओपी एक दृश्य का उपयोग कर रहा है, इसलिए मैंने एक संग्रहीत प्रक्रिया के बजाय एक टीवीएफ का सुझाव दिया है, लेकिन इसका मतलब यह नहीं है कि दृश्य का उपयोग करना जारी रखना कार्रवाई का सबसे अच्छा कोर्स है। जब यह करने के लिए समझ में आता है, तो संरचना और / या दृष्टिकोण को संशोधित करना आम है। फिर भी, मैंने अपने जवाब में एक वैकल्पिक आवरण दृश्य जोड़ा। और, यह देखते हुए कि यह सब कुछ "हाँ" के लिए सबसे आम है, हाँ, DB_CHAININGकाफी जोखिम भरा है।

— सोलोमन रटज़की

Answer 1

यह मॉड्यूल साइनिंग का उपयोग करके बहुत सुरक्षित तरीके से पूरा करना आसान है। यह मेरे निम्नलिखित दो उत्तरों के समान होगा, यहाँ DBA.StackExchange पर भी, जो कि सिर्फ करने के उदाहरण देते हैं:

निष्पादित प्रक्रिया के साथ संग्रहीत कार्यविधि सुरक्षा, क्रॉस डेटाबेस क्वेरीज़, और मॉड्यूल साइनिंग

क्रॉस डेटाबेस प्रमाणपत्र का उपयोग करते समय ट्रिगर में अनुमतियाँ

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

निम्नलिखित उदाहरण कोड यह दर्शाता है कि लॉगिन / उपयोगकर्ता "प्रतिबंधित" में केवल इस सवाल का अनुरोध किया जा रहा है कि केवल "डेटाबेसए" तक पहुंच है और अभी भी "डेटाबेसबी" से डेटा प्राप्त करने में सक्षम है। यह केवल इस एक TVF से चुनकर काम करता है , और केवल इस पर हस्ताक्षर होने के कारण।

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

USE [master];

CREATE LOGIN [RestrictedUser] WITH PASSWORD = 'No way? Yes way!';
GO

---

USE [DatabaseA];

CREATE USER [RestrictedUser] FOR LOGIN [RestrictedUser];

GO
CREATE FUNCTION dbo.DataFromOtherDB()
RETURNS @Results TABLE ([SomeValue] INT)
AS
BEGIN
    INSERT INTO @Results ([SomeValue])
        SELECT [SomeValue]
        FROM   DatabaseB.dbo.LotsOfValues;

    RETURN;
END;
GO

GRANT SELECT ON dbo.[DataFromOtherDB] TO [RestrictedUser];
GO
---

USE [DatabaseB];

CREATE TABLE dbo.[LotsOfValues]
(
    [LotsOfValuesID] INT IDENTITY(1, 1) NOT NULL
        CONSTRAINT [PK_LotsOfValues] PRIMARY KEY,
    [SomeValue] INT
);

INSERT INTO dbo.[LotsOfValues] VALUES
    (1), (10), (100), (1000);
GO

---

USE [DatabaseA];

SELECT * FROM dbo.[DataFromOtherDB]();


EXECUTE AS LOGIN = 'RestrictedUser';

SELECT * FROM dbo.[DataFromOtherDB]();
/*
Msg 916, Level 14, State 1, Line XXXXX
The server principal "RestrictedUser" is not able to access
the database "DatabaseB" under the current security context.
*/

REVERT;

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

नीचे दिए गए कदमों ने मॉड्यूल गायन की स्थापना की। यह निम्न कार्य करता है:

1. डेटाबेसए में एक प्रमाण पत्र बनाता है
2. प्रमाणपत्र के साथ TVF पर हस्ताक्षर करता है
3. सर्टिफिकेट (निजी कुंजी के बिना) डेटाबेस बी के लिए
4. प्रमाण पत्र से डेटाबेस में एक उपयोगकर्ता बनाता है
5. अनुदान SELECTप्रमाणपत्र-आधारित उपयोगकर्ता को DatabaseB में टेबल की अनुमति

मॉड्यूल हस्ताक्षर सेटअप:

CREATE CERTIFICATE [AccessOtherDB]
    ENCRYPTION BY PASSWORD = 'SomePassword'
    WITH SUBJECT = 'Used for accessing other DB',
    EXPIRY_DATE = '2099-12-31';

ADD SIGNATURE
    TO dbo.[DataFromOtherDB]
    BY CERTIFICATE [AccessOtherDB]
    WITH PASSWORD = 'SomePassword';

---
DECLARE @CertificatePublicKey NVARCHAR(MAX) =
            CONVERT(NVARCHAR(MAX), CERTENCODED(CERT_ID(N'AccessOtherDB')), 1);

SELECT @CertificatePublicKey AS [Cert / PublicKey]; -- debug

EXEC (N'USE [DatabaseB];
CREATE CERTIFICATE [AccessOtherDB] FROM BINARY = ' + @CertificatePublicKey + N';');
---


EXEC (N'
USE [DatabaseB];
CREATE USER [AccessOtherDbUser] FROM CERTIFICATE [AccessOtherDB];

GRANT SELECT ON dbo.[LotsOfValues] TO [AccessOtherDbUser];
');

---



EXECUTE AS LOGIN = 'RestrictedUser';

SELECT * FROM dbo.[DataFromOtherDB]();
-- Success!!

SELECT * FROM [DatabaseB].[dbo].[LotsOfValues];
/*
Msg 916, Level 14, State 1, Line XXXXX
The server principal "RestrictedUser" is not able to access
the database "DatabaseB" under the current security context.
*/

REVERT;

यदि किसी कारण से, यह देखने के लिए आवश्यक है, तो आप बस ऊपर दिखाए गए टीवीएफ से एक दृश्य बना सकते हैं। और, उस स्थिति में, TVF को केवल व्यू के अनुसार SELECTएक्सेस करने की आवश्यकता नहीं है, जैसा कि नीचे दिखाया गया है:

GO
CREATE VIEW dbo.[DataFromTVF]
AS
SELECT [SomeValue]
FROM   dbo.DataFromOtherDB();
GO

-- Remove direct access to the TVF as it is no longer needed:
REVOKE SELECT ON dbo.[DataFromOtherDB] FROM [RestrictedUser];

GRANT SELECT ON dbo.[DataFromTVF] TO [RestrictedUser];

और अब इसका परीक्षण करने के लिए:

EXECUTE AS LOGIN = 'RestrictedUser';


SELECT * FROM dbo.[DataFromOtherDB]();
/*
Msg 229, Level 14, State 5, Line XXXXX
The SELECT permission was denied on the object 'DataFromOtherDB',
database 'DatabaseA', schema 'dbo'.
*/


SELECT * FROM [OwnershipChaining].[dbo].[LotsOfValues];
/*
Msg 916, Level 14, State 1, Line XXXXX
The server principal "RestrictedUser" is not able to access
the database "DatabaseB" under the current security context.
*/


SELECT * FROM dbo.[DataFromTVF];
-- Success!!


REVERT;

---

मॉड्यूल हस्ताक्षर पर अधिक जानकारी के लिए, कृपया देखें: https://ModuleSigning.Info/

Comments

क्या नियमित बैकअप के हिस्से के रूप में सीट्स का बैकअप लिया जाता है? या वे कहीं और संग्रहीत हैं और एक फाइल सिस्टम बैकअप की आवश्यकता है? और क्या होता है यदि आप एक कम वातावरण में बहाल करते हैं जो विभिन्न पासवर्डों आदि का उपयोग कर सकता है?

— क्रिस एल्डरिच

@ChrisAldrich यहां दिखाए गए उपयोग में, यह DB के साथ बैकअप है क्योंकि यह पूरी तरह से डेटाबेस के भीतर आयोजित होता है। यदि आप उपयोग करते हैं ALTER CERTIFICATE ... DROP PRIVATE KEYतो निजी कुंजी चली जाएगी यदि आपने पहले इसे BACKUP CERTIFICATE का उपयोग करके किसी फ़ाइल में वापस नहीं किया है । लेकिन, सार्वजनिक कुंजी अभी भी अंदर है sys.certificates। और सार्वजनिक कुंजी को पासवर्ड की आवश्यकता नहीं है। केवल एक मॉड्यूल पर हस्ताक्षर करने के लिए निजी कुंजी का उपयोग करने के लिए पासवर्ड की आवश्यकता होती है (जो कि मास्टर कुंजी के माध्यम से सुरक्षा के विपरीत सर्वर के समान है)।

— सोलोमन रटज़की ने