DDL_admin বনাম db_owner অনুমতি


15

আমি এমন একটি প্রকল্প গ্রহণ করছি যার মধ্যে রয়েছে আমাদের সার্ভার ফার্ম জুড়ে সমস্ত ডাটাবেস ব্যবহারকারীদের অনুমতি সরানো এবং সীমাবদ্ধ করা। (মজা বার)

বর্তমানে সীমাবদ্ধ থাকার অনুমতিগুলির মধ্যে একটি হ'ল ডিবি মালিক মালিকের অনুমতি।
এই অনুমতিটি কেস-কেস-কেস ভিত্তিতে পর্যালোচনা করা হচ্ছে, তবে একটি সাধারণ পরিবর্তন হ'ল নিম্নলিখিত সাথে db_owner অনুমতিগুলি প্রতিস্থাপন করা:

আমি উভয় (ক্লায়েন্টকে অবহিত করতে) এর মধ্যে সঠিক পার্থক্যটি সংজ্ঞায়িত করতে চাই।
তবে যতদূর আমি বলতে পারি, দুজনের মধ্যে পার্থক্য হওয়া উচিত:

  • db_accessadmin অনুমতি
  • db_backupoperator অনুমতি
  • db_ সুরক্ষা অ্যাডমিন অনুমতি

সুতরাং কার্যকরী তারা হারাবে:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE],[ALTER ANY ROLE]
[DROP DATABASE]

উপরের চারটি ভূমিকা দ্বারা db_owner প্রতিস্থাপন করা হলে কোনও ব্যবহারকারী কি আলগা হবে?
এটি কি কোনও উদ্দেশ্য সুরক্ষা অনুসারে কাজ করে?

উত্তর:


16

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]

লক্ষ্য করে যে। । ।

  1. db_datareaderSELECTসমস্ত টেবিল অ্যাক্সেস অনুমতি দেবে
  2. db_datarwriterঅনুমতি দেয় INSERT, UPDATEএবং DELETEসমস্ত টেবিল অ্যাক্সেস
  3. db_executorEXECUTEসমস্ত এক্সিকিউটেবল অবজেক্টে অ্যাক্সেসের অনুমতি দেবে

যোগসূত্র হিসাবে, db_ddladmin ভূমিকা অনুমতি থাকার অর্থ হতে পারে। । ।

দ্রষ্টব্য: ২০০৫ - ২০১৪ সাল থেকে আপনার কাছে এসকিউএল সার্ভারের অনেকগুলি ভিন্ন সংস্করণ রয়েছে, তাই কে কেঙ্কস ইত্যাদিতে আস্তে আস্তে আস্তে আস্তে আস্তে আস্তে আসে সে দেখার জন্য প্রথমে ব্যবহারকারীদের একটি ছোট সেট এটি পরীক্ষা করা ভাল be

  • এই ভূমিকার সাথে তাদের যে বিষয়গুলির মালিকানা রয়েছে সেগুলি ডিবিওর মালিকানাধীন হবে না তাই এই স্তরের কিছু নিয়ে যদি কখনও সমস্যা হয় তবে আপনাকে মালিকানা দেওয়ার সমস্যাগুলি মোকাবেলা করতে হতে পারে। আমি 100% নিশ্চিত নই যে এটি একটি সমস্যা হবে তবে এটি কেবল ক্ষেত্রে উল্লেখ করার মতো।

    সূত্র: মালিকানা চেইন

  • এই ভূমিকার সাথে (এসকিউএল সার্ভারের সংস্করণ অনুসারে পৃথক হতে পারে) তারা বর্তমান ডিবিতে সংজ্ঞায়িত এসকিউএল সুরক্ষা নীতিগুলি এখনও অবধি তাদের নিজস্ব অবজেক্টগুলিতে যুক্ত করতে সক্ষম হতে পারে, কেবল সমস্ত বস্তু নয় (যাদের নিজস্ব নয়) বা একটি নতুন সার্ভার যুক্ত করতে পারে ডিবি স্তরে স্তরের সংজ্ঞা দেওয়া হয়েছে le


অতিরিক্তভাবে, ডিবিও রোলের অনুমতি না থাকার অর্থ হতে পারে। । ।

দ্রষ্টব্য: ২০০৫ - ২০১৪ সাল থেকে আপনার কাছে এসকিউএল সার্ভারের অনেকগুলি ভিন্ন সংস্করণ রয়েছে, তাই কে কেঙ্কস ইত্যাদিতে আস্তে আস্তে আস্তে আস্তে আস্তে আস্তে আসে সে দেখার জন্য প্রথমে ব্যবহারকারীদের একটি ছোট সেট এটি পরীক্ষা করা ভাল be

  • ডিবিও ভূমিকা না রাখার ফলে নির্দিষ্ট এসএসএমএস ডিজাইনার জিইউআই ইন্টারফেসগুলি (এসকিউএল সার্ভার সংস্করণ পরিবর্তিত হতে পারে) জনবসতি বা ত্রুটি ছাড়াই খোলার (যেমন জিইউআইয়ের মাধ্যমে টেবিল বা কলামগুলি সংশোধন করার সময় ) আটকাতে পারে যদিও এটি টি-এসকিউএল কর্মের মাধ্যমে করা হয় এবং অনুমতিগুলি স্থানে থাকে । এসকিউএল সার্ভারের কয়েকটি সংস্করণে এটি GRANT VIEW DEFINITIONযেখানে এটি একটি সমস্যা তা মঞ্জুরি দিয়ে সমাধান করা যেতে পারে এবং এটি কেবলমাত্র এসকিউএল সার্ভারের কয়েকটি সংস্করণে কেবল একটি সতর্কতা হতে পারে।

    সম্পদ

    • আপনি ডেটাবেস মালিক হিসাবে বা ব্যবহারকারী হিসাবে যে db_owner ভূমিকা সদস্য হিসাবে লগ ইন নেই। আপনি নিজের পছন্দ মতো টেবিলগুলিতে পরিবর্তনগুলি সংরক্ষণ করতে সক্ষম হবেন না।

    • db_ddladmin ভূমিকা SSMS এ "ডিজাইন" ফাংশন ব্যবহারের অনুমতি দেয় না

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

      আমি জানি না এটি কোনও ত্রুটি বা কোনও বৈশিষ্ট্য অনুরোধ কিনা তবে আমি এটি একটি বাগ হিসাবে বিবেচনা করি যেহেতু ব্যবহারকারীর টিএসকিউএল এর মাধ্যমে টেবিলটি পরিবর্তনের জন্য যথেষ্ট অনুমতি রয়েছে তবে জিইউআই তাদের বার্তা দেয় যাতে:

      " আপনি ডাটাবেস মালিক বা সিস্টেম অ্যাডমিনিস্ট্রেটর হিসাবে লগ ইন করেন নি You আপনি নিজেরাই টেবিলগুলির পরিবর্তনগুলি সংরক্ষণ করতে পারবেন না" " এবং "সারণীটি [schema].[table]কেবলমাত্র পড়ার জন্য সেট করা আছে, এই টেবিলে ব্যবহারকারীর পর্যাপ্ত অধিকার নেই। "

      একটি ট্রেস মনে হচ্ছে এই চেকটি is_membre ('db_owner') হিসাবে দেখায় যা db_ddladmin সদস্যদের বাস্তবে পরিবর্তন করার অনুমতি থাকলেও তাদেরকে বাদ দেবে। মাইক্রোসফ্ট এসকিউএল সার্ভার ম্যানেজমেন্ট স্টুডিও "


      এজেন্ট ডিবিএ পোস্ট করেছেন 1/25/2010 এ সকাল 7:06 এ

      আমি একই ধরণের সমস্যা পেয়েছি এবং নিম্নলিখিত অনুদানটি সম্পাদন করে এটি সমাধান করতে সক্ষম হয়েছি

      GRANT view definition on schema:: <schemaname> to <username>

অন্যান্য বিবেচ্য বিষয়

যেহেতু আপনি বলেছেন যে এটি কেস-কেস-কেস ভিত্তিতে পর্যালোচনা করা হচ্ছে

বর্তমানে সীমাবদ্ধ থাকার অনুমতিগুলির মধ্যে একটি হ'ল ডিবি_মালার অনুমতি।

এই অনুমতিটি কেস-কেস-কেস ভিত্তিতে পর্যালোচনা করা হচ্ছে, তবে একটি সাধারণ পরিবর্তন হ'ল নিম্নলিখিত সাথে 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

আমি এমন একটি ডিবি_ডিডিএলডিডমিন_সংশ্লিষ্ট ভূমিকাটিও ভাগ করে নিতে চেয়েছিলাম যা আপনি স্পষ্ট DENYকরে অন্যটি তৈরি করার বিষয়ে বিবেচনা করতে চাইতে পারেন db_ddladminযাতে কোন অ্যাক্সেস দেয় তা সীমাবদ্ধ করার জন্য আপনি কমপক্ষে এটি ডিবিগুলিতে তৈরি করতে পারেন যেখানে আপনি এই ভূমিকাটি প্রদান করেন এবং 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

8

সমস্ত অনুমতি তালিকার জন্য একটি এসকিউএল স্ক্রিপ্ট ব্যবহার করে, আমি গিয়েছিলাম এবং প্রতিটি ক্ষেত্রে ব্যবহারকারী তৈরি করেছি।

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

আমি তখন ফলাফলগুলি তুলনা করে নীচে তালিকায় এসেছি, প্রাথমিকভাবে এমএসডিএন থেকে ডকুমেন্টেশন সহ (বিশেষভাবে উল্লেখ করা কোনও উদ্ধৃতি এমএসডিএন লিঙ্কের নয়)।
নীচে আমি এমন কিছু ডকুমেন্টেশন দিয়েছি যেগুলি আমি লোকদের জানাতে ব্যবহৃত হয়েছিল যারা ডিবো অনুমতিগুলি হারাবে যা তারা ঠিক কী হারাচ্ছে।

ALTER

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

যে কোনও আবেদনের ভূমিকা পরিবর্তন করুন
যে
কোনও ডেটাবেস অডিট যে কোনও রোলের পরিবর্তে
যে কোনও ব্যবহারকারীর

ডেটাবেস সিকিউরিবলের পৃথক দৃষ্টান্ত তৈরি করতে, পরিবর্তিত করতে বা DROP করার দক্ষতার বিষয়টি নিশ্চিত করে। উদাহরণস্বরূপ, অ্যালটার যে কোনও পরিকল্পনা ডেটাবেসে কোনও স্কিমা তৈরি, পরিবর্তন বা ড্রপ করার ক্ষমতা প্রদান করে।

অ্যাপ্লিকেশন ভূমিকা হ'ল ডাটাবেস প্রিন্সিপাল যা কোনও অ্যাপ্লিকেশনকে তার নিজস্ব, ব্যবহারকারীর মতো অনুমতি দিয়ে চালাতে সক্ষম করে।

এসকিউএল সার্ভার বা একটি এসকিউএল সার্ভার ডাটাবেসের একটি উদাহরণ অডিটিংয়ে সিস্টেমে ঘটে যাওয়া ইভেন্টগুলি ট্র্যাকিং এবং লগিংয়ের সাথে জড়িত। ডাটাবেস-স্তর অডিট নির্দিষ্টকরণের অবজেক্টটি একটি নিরীক্ষার অন্তর্ভুক্ত। আপনি প্রতি নিরীক্ষায় এসকিউএল সার্ভার ডাটাবেসের জন্য একটি ডেটাবেস অডিট স্পেসিফিকেশন তৈরি করতে পারেন।

ডেটাবেস রোলগুলি সহজেই আপনার ডাটাবেসে অনুমতিগুলি পরিচালনা করতে ব্যবহার করা হয়, এসকিউএল সার্ভার বিভিন্ন ভূমিকা দেয় যা সুরক্ষা প্রিন্সিপালগুলি যা অন্য প্রিন্সিপালদের গোষ্ঠী করে। তারা মাইক্রোসফ্ট উইন্ডোজ অপারেটিং সিস্টেমের গ্রুপগুলির মতো। ডাটাবেস-স্তরের ভূমিকাগুলি তাদের অনুমতির সুযোগে ডাটাবেস-প্রশস্ত।

এ প্রমাণীকৃত
MSDN খুঁজে পাওয়া গেছে।

ক্রস ডাটাবেস এবং সার্ভার-অ্যাক্সেসে (যথাক্রমে) দৃশ্যাবলীগুলিতে কেবল এক্সকিউটি হিসাবে ব্যবহার করার সময় প্রমাণীকরণ এবং প্রমাণীকরণের সার্ভারের অনুমতিগুলি ব্যবহৃত হয়।

ব্যাকআপ ডেটাবেস
ব্যাকআপ লগ

সংযুক্ত নিবন্ধ

ডাটাবেস প্রতিলিপি অনুমতি জন্য ব্যবহৃত ।

নিয়ন্ত্রণ

গ্রান্টিতে মালিকানার মতো ক্ষমতাগুলি নিশ্চিত করে। গ্রান্টির কার্যকরভাবে সুরক্ষার উপর সমস্ত সংজ্ঞায়িত অনুমতি রয়েছে। একটি অধ্যক্ষ যা কন্ট্রোলকে মঞ্জুর করা হয়েছে সেগুলিও সুরক্ষার জন্য অনুমতি দিতে পারে।

ভূমিকা তৈরি করুন

গ্রান্টিকে ডেটাবেস সিকিওরিবল তৈরির ক্ষমতা নিশ্চিত করে।

SHOWPLAN

শোপলান অনুমতিগুলি বিভিন্ন শোপ্ল্যান এসইটি স্টেটমেন্ট বিকল্পগুলির জন্য ব্যবহৃত হয় যখন সেগুলি ট্রান্সঅ্যাক্ট-এসকিউএল ব্যাচগুলির সাথে ব্যবহৃত হয়

সাবস্ক্রাইব করুন QUERY বিজ্ঞপ্তিগুলি

ক্যোয়ারী বিজ্ঞপ্তিগুলি সম্পর্কে ডকুমেন্টেশন।

পরিষেবা ব্রোকার অবকাঠামোতে নির্মিত, ক্যোয়ারী বিজ্ঞপ্তিগুলি ডেটা পরিবর্তিত হয়ে গেলে অ্যাপ্লিকেশনগুলিকে অবহিত করার অনুমতি দেয়। এই বৈশিষ্ট্যটি অ্যাপ্লিকেশনগুলির জন্য বিশেষভাবে কার্যকর যা একটি ডেটাবেস থেকে যেমন একটি ওয়েব অ্যাপ্লিকেশন থেকে তথ্য ক্যাশে সরবরাহ করে এবং উত্সের ডেটা পরিবর্তন করা হয় তখন তাকে অবহিত করা প্রয়োজন।

মালিকানা নিন

মঞ্জুরিপ্রাপ্ত ব্যক্তি যে সুরক্ষার উপর মঞ্জুরিপ্রাপ্ত তার মালিকানা নিতে সক্ষম করে।

ডেটাবেস রাজ্য দেখুন

ডায়নামিক ম্যানেজমেন্ট ভিউ এবং ফাংশন (লেনদেন-এসকিউএল) দেখতে ব্যবহৃত হয় ।

সংজ্ঞা দেখুন

দর্শন সংজ্ঞা অনুমতি সংক্রান্ত নথি

ভিউ সংজ্ঞা অনুমোদনের মাধ্যমে ব্যবহারকারীকে অনুমতি দেওয়া হয় এমন সুরক্ষার মেটাডেটা দেখতে দেয়। যাইহোক, ভিউ সংজ্ঞাটি অনুমতি নিজেই সুরক্ষার মধ্যে অ্যাক্সেস সরবরাহ করে না। উদাহরণস্বরূপ, কোনও ব্যবহারকারী যাকে কেবল কোনও টেবিলে কেবল VIIF সংজ্ঞা অনুমোদনের অনুমতি দেওয়া হয়েছে সে সিস.ওবজেক্টস ক্যাটালগ ভিউতে টেবিলের সাথে সম্পর্কিত মেটাডেটা দেখতে পাবে। তবে, SELECT বা নিয়ন্ত্রণের মতো অতিরিক্ত অনুমতি ব্যতীত ব্যবহারকারী টেবিল থেকে ডেটা পড়তে পারবেন না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.