অন্য ডাটাবেসে অ্যাকাউন্ট ছাড়াই অন্য ডাটাবেসে টেবিলের ভিত্তিতে অ্যাক্সেস ভিউ

Question

আমি ডাটাবেস 2-এ টেবিলের উপর ভিত্তি করে ডাটাবেস 1 এ ভিউ তৈরি করেছি। আমি এমন SELECTএক ব্যবহারকারীকে অনুমতি দিয়েছি যার কেবলমাত্র ডাটাবেস 1 এ অ্যাক্সেস রয়েছে। ব্যবহারকারী এই ভিউটি কাজ করতে পারবেন না কারণ তার ডাটাবেস 2 এ অ্যাকাউন্ট নেই। আমি কীভাবে এই সমস্যাটি সমাধান করতে পারি? আমি ডাটাবেস 2 এ একটি অ্যাকাউন্ট তৈরি করতে চাই না।

Comments

@ মুস্তাকসিও না, এটি অন্যান্য প্রশ্ন / উত্তরের সদৃশ নয় কারণ পরিস্থিতিটি একই ডাটাবেসের মধ্যে ছিল এবং এই প্রশ্নটি ডেটাবেসগুলি বিস্তৃত সম্পর্কে। ডিফল্টরূপে এটি অনুমোদিত নয়। কাউকে ক্রস-ডাটাবেস মালিকানার চেইন সক্ষম করতে হবে এবং এটি এমন সংকীর্ণ প্রয়োজনের জন্য খোলার জন্য একটি বিশাল সুরক্ষা গর্ত।

— সলোমন রুটজকি 21

@ সলোমনরুটজকি, আমি ডিবি_সিএইচিংকে একটি "বিশাল সুরক্ষা গর্ত" বলব না। সাধারণ উত্পাদন পরিবেশে যেখানে কেবল সিসাদমিন ভূমিকা সদস্যরা অবজেক্ট তৈরি করতে পারে, এটি একটি নন-ইস্যু। এটি বলেছে যে, নন-সিসাদমিন ভূমিকা সদস্যদের নিজস্ব মালিকানা বাদে অন্য কোনও স্কিমায় নিয়ন্ত্রণের অনুমতি রয়েছে সে ক্ষেত্রে এটি সাবধানতার সাথে ব্যবহার করা উচিত।

— ড্যান গুজম্যান

@ ডানগুজমান "আমাকে বিশ্বাস করুন, সবসময় পরিকল্পনা অনুসারে চলবে" কোনও কার্যকর কৌশল নয়। এই যুক্তি অনুসারে, TRUSTWORTHY ONঅ্যাপ্লিকেশন লগ ইন হিসাবে সেট করা বা রাখার কোনও ঝুঁকি নেই sa। ডিবি ওনারশিপ চেইনিং এবং TRUSTWORTHYবিদ্যমান সময়ে একমাত্র সমাধান হওয়ার কারণে এটি বিদ্যমান। তবে এখন, বিশাল ঝুঁকি না হলেও, ডিবি চেইনিং অবশ্যই একটি অপ্রয়োজনীয় ঝুঁকি, কারণ মডিউল সাইন ইন করা এতটা কঠিন নয়। এবং যদি কেউ ডিবি শৃঙ্খলার উপর নির্ভর করে এবং তারপরে ডায়নামিক এসকিউএল ব্যবহার করে তবে তারা এটি TRUSTWORTHY ONঠিক করার পক্ষে আরও বেশি সম্ভাবনা রয়েছে , অন্যদিকে মডিউল সাইন ইন করে এটি ভেঙে পড়েনি।

— সলোমন রুটজকি

@ সলোমনরুতজকি, আমি যদি ভিউয়ের পরিবর্তে কোনও মডিউল সম্পর্কে প্রশ্নটি করি তবে আমি মডিউল সই করার পরামর্শ দিতাম। আমার চিন্তাভাবনাটি হ'ল DB_CHAININGইন্ট্রা-ডাটাবেস মালিকানা শৃঙ্খলা ছাড়া আর কোনও ঝুঁকিপূর্ণ নয় যখন কোনওভাবেই বস্তুগুলি একই ডাটাবেসে থাকা উচিত ছিল।

— ড্যান গুজম্যান

@ ডানগুজম্যান কেন ধরে নিলেন যে "যে কোনও উপায়ে একই ডাটাবেসে থাকা উচিত ছিল"? ওবি কেবলমাত্র বিপরীতে নির্দেশ করেছে কারণ তারা ডিবি অ্যাক্সেসকে আলাদা রাখতে চায়। ওপি একটি ভিউ ব্যবহার করছে বলেই আমি একটি সঞ্চিত পদ্ধতির পরিবর্তে একটি টিভিএফের পরামর্শ দিয়েছি, তবে এর অর্থ এই নয় যে একটি ভিউ ব্যবহার করা অব্যাহত রাখা সর্বোত্তম ক্রিয়া। কাঠামোগত পরিবর্তন এবং / অথবা পদ্ধতির যখন এটি করার বুদ্ধি হয় তখন তা প্রস্তাব দেওয়া সাধারণ বিষয়, যেমনটি এখানে রয়েছে। তবুও, আমি আমার উত্তরে একটি alচ্ছিক মোড়কের ভিউ যুক্ত করেছি। এবং, প্রদত্ত যে "ডিবিও" এর পক্ষে সমস্ত কিছুর মালিকানা সবচেয়ে সাধারণ, হ্যাঁ, DB_CHAININGএটি বেশ ঝুঁকিপূর্ণ।

— সলোমন রুটজকি

Answer 1

মডিউল সাইনিং ব্যবহার করে খুব নিরাপদ উপায়ে এটি সম্পাদন করা সহজ। এটি ডিবিএ.স্ট্যাকএক্সচেঞ্জ-এ আমার নিম্নলিখিত দুটি জবাবের সমান হবে, যা কেবল এটি করার উদাহরণ দেয়:

হিসাবে চালানো, ক্রস ডাটাবেস কোয়েরি এবং মডিউল স্বাক্ষর সহ পদ্ধতি সুরক্ষিত

ক্রস ডাটাবেস শংসাপত্র ব্যবহার করার সময় ট্রিগারগুলিতে অনুমতি

এই নির্দিষ্ট প্রশ্নের পার্থক্য হ'ল এটি একটি দর্শনের সাথে সম্পর্কিত এবং ভিউগুলিতে স্বাক্ষর করা যায় না। সুতরাং, আপনাকে ভিউটি একটি বহু-বিবৃতি টেবিল-মূল্যযুক্ত ফাংশন (টিভিএফ) এ রূপান্তর করতে হবে কারণ সেগুলিতে সাইন ইন করা যেতে পারে এবং একটি দৃশ্যের মতো অ্যাক্সেস করা যায় (ভালভাবে, SELECTঅ্যাক্সেসের জন্য )।

নিম্নলিখিত উদাহরণ কোডটিতে লগইন / ব্যবহারকারী "রিস্ট্রাকটেড ইউজার" কেবল "ডাটাবেসএ" এ অ্যাক্সেস পেয়েছে এবং এখনও "ডাটাবেসবি" থেকে ডেটা পেতে সক্ষম হয়েছে এমন প্রশ্নের মধ্যে অনুরোধ করা হচ্ছে ঠিক তা করছে তা দেখায়। এটি কেবলমাত্র এই একটি টিভিএফ থেকে নির্বাচন করে কাজ করে এবং কেবল এটি স্বাক্ষরিত হওয়ার কারণে।

ভিউ ব্যবহার করার সময় এই ধরণের ক্রস-ডাটাবেস অ্যাক্সেস সম্পন্ন করা এবং ব্যবহারকারীর কোনও অতিরিক্ত অনুমতি না দেওয়ার জন্য ক্রস-ডাটাবেস মালিকানা চেইন সক্ষম করা প্রয়োজন। এটি অনেক কম সুরক্ষিত কারণ এটি উভয় ডেটাবেসগুলির মধ্যে থাকা সমস্ত সামগ্রীর জন্য সম্পূর্ণ উন্মুক্ত (এটি কিছু নির্দিষ্ট বস্তু এবং / অথবা ব্যবহারকারীদের মধ্যে সীমাবদ্ধ করা যায় না)। মডিউল সইনিং কেবল এই একটি টিভিএফকে ক্রস-ডিবি অ্যাক্সেসের অনুমতি দেয় (ব্যবহারকারীর অনুমতি নেই, টিভিএফের অনুমতি নেই) এবং যে ব্যবহারকারীরা 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. শংসাপত্র দিয়ে টিভিএফ স্বাক্ষর করে
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;

যদি যাইহোক , যদি কোনও কারণে দৃষ্টিভঙ্গি হওয়ার প্রয়োজন হয়, তবে আপনি কেবলমাত্র এমন একটি ভিউ তৈরি করতে পারবেন যা উপরের দেখানো টিভিএফ থেকে নির্বাচন করে। এবং, যে পরিস্থিতিতে, SELECTএক্সেস নেই না TVF, শুধুমাত্র দৃশ্যে মঞ্জুর করা, নিচের প্রদর্শিত প্রয়োজন:

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

নিয়মিত ব্যাকআপের অংশ হিসাবে শংসাপত্রগুলি ব্যাক আপ হয়? বা এগুলি অন্য কোথাও সঞ্চিত রয়েছে এবং পাশাপাশি ফাইল ফাইলের ব্যাকআপেরও প্রয়োজন? এবং আপনি যদি এমন কোনও নিম্ন পরিবেশে পুনরুদ্ধার করেন যা বিভিন্ন পাসওয়ার্ড ইত্যাদি ব্যবহার করতে পারে?

— ক্রিস অ্যালডরিচ

@ ক্রিসআল্ডরিচ এখানে প্রদর্শিত ব্যবহারে এটি ডিবি-র সাথে ব্যাক আপ করা হয়েছে যেহেতু এটি সম্পূর্ণভাবে ডেটাবেসের মধ্যে রয়েছে held আপনি যদি ব্যবহার করেন ALTER CERTIFICATE ... DROP PRIVATE KEYতবে ব্যাকআপ সার্টিফিকেট ব্যবহার করে যদি আপনি প্রথমে কোনও ফাইলটিতে ব্যাক আপ না রাখেন তবে ব্যক্তিগত কী চলে যাবে । তবে, পাবলিক কীটি এখনও রয়েছে sys.certificates। এবং পাবলিক কীটির পাসওয়ার্ডের দরকার নেই। মডিউলটিতে স্বাক্ষর করতে শুধুমাত্র ব্যক্তিগত কী ব্যবহার করার জন্য পাসওয়ার্ডের প্রয়োজন হয় (যা সার্ভারগুলি জুড়ে একই, মাস্টার কী এর মাধ্যমে সুরক্ষিত করার ক্ষেত্রে নয়)।

— সলোমন রুটজকি