محدودیت های امنیتی سطح ردیف SQL Server 2016 ، عملکرد و عیب یابی

در قسمت اول این نکته ، از امنیت سطح ردیف در SQL Server 2016 ، قسمت 1 استفاده کنید ، من دلایل استفاده از امنیت سطح ردیف را شرح دادم و نمونه های ساده ای از استفاده از فیلتر سطح ردیف را با استفاده از نام حساب SQL یا Context_info نشان دادم(). برای جلوگیری از حواس پرتی ، من جزئیات مهمی را که احتمالاً قبل از اجرای این ویژگی باید از آنها آگاه باشید ، کنار گذاشتم.

راه حل

محدودیت های مختلفی در اولین تکرار امنیت سطح ردیف وجود دارد. در این نکته ، من اطلاعاتی در مورد آن ها ، و همچنین برخی از کارهایی که می توانید برای کاهش آنها انجام دهید (در برخی موارد) ارائه می دهم. خوشبختانه ، بسیاری از موارد ذکر شده در زیر فقط به طور موقت است و در طول چرخه CTP در برخی از نقاط برطرف می شود. اما شما هنوز هم باید از بیشتر آنها آگاه باشید حتی اگر این ویژگی را لمس نکنید تا اینکه بعد از SQL Server 2016 RTM بروید.

محدودیت های امنیتی سطح SQL Server Row Level

مبادله کردن

من در قسمت اول این نکته ذکر کردم که عملکرد محمول باید با طرح بندی ایجاد شود. اگر عملکردی را بدون این تنظیم ایجاد کرده و سپس سعی کنید آن را به یک خط مشی امنیتی متصل کنید ، خطای زیر را دریافت خواهید کرد:

MSG 4513 ، سطح 16 نمی تواند خط مشی امنیت "سیاست" را به هم پیوند دهد."dbo. function" طرحواره ای محدود نیست.

این امر نه تنها شما را از دسترسی به نمایشگاه های محلی و DMV ها ، که قبلاً به آنها اشاره کردم ، جلوگیری می کند ، بلکه شما همچنین قادر به اجرای منطق امنیتی بر اساس جداول جستجو نیست که در سایر پایگاه های داده ذخیره می شوند. این بدان معناست که اگر لیست های کنترل دسترسی را به صورت مرکزی (در جای دیگر) ذخیره کرده اید ، باید به این پایگاه داده تکثیر شوید ، یا داده های مرکزی را جابجا کنید و با استفاده از نماها ، مترادف ها یا پرس و جوهای به روز شده ، سایر منابع را در اینجا نشان دهید.

نماهای نمایه شده

امنیت سطح ردیف با جداول که نماهای نمایه شده را نشان می دهد سازگار نیست. اگر سعی می کنید یک نمای فهرست بندی شده را در برابر یک جدول با یک خط مشی امنیتی ایجاد کنید ، خطای زیر را دریافت خواهید کرد:

MSG 33266 ، سطح 16 شاخص در نمای "نمایش" نمی تواند ایجاد شود زیرا نمای جدول "جدول" را که توسط یک سیاست امنیتی ارجاع شده است ، ارجاع می دهد.

و نه ، شما نمی توانید این کار را انجام دهید تا در اطراف آن کار کنید. اگر یک جدول با یک دیدگاه فهرست بندی شده ارجاع شود ، از یک سیاست امنیتی استفاده نمی شود:

MSG 33265 ، سطح 16 سیاست امنیتی "سیاست" نمی تواند در جدول "جدول" داشته باشد زیرا این جدول توسط نمای فهرست "نمای" ارجاع شده است.

توجه: در صورت تلاش برای اعمال یک خط مشی امنیتی در جدول که توسط یک نمای تقسیم شده ارجاع شده است ، ممکن است با همان مشکلات روبرو شوید.

OLTP در حافظه

در ساختهای فعلی (در زمان نوشتن ، جدیدترین ساخت CTP 2. 2 بود) ، میزهای OLTP در حافظه پشتیبانی نمی شوند. من گمان می کنم که با رسیدن به RTM ، این ویژگی باید کاملاً پشتیبانی شود ، زیرا مایکروسافت برای ساخت ویژگی های اصلی موتور مانند این به طول بسیار خوبی رفته است (به ستون ستون نیز مراجعه کنید) با تمام ویژگی های جدید سازگار است.

ایندکس های متن کامل

شاخص های متن کامل پشتیبانی می شوند ، اما این نکته را باید در نظر داشته باشید که این شاخص ها بر اساس داده های فیلتر نشده است ، بنابراین ممکن است که با وجود سیاست امنیتی در جدول ، نشت داده ها رخ دهد. این سیاست مانع از جستجوی ردیف های غیرقابل دسترسی نمی شود.

SQL Server Row Level Security تأثیر عملکرد

برای نمایش داده های منتخب ، قطعاً یک تغییر قابل مشاهده در برنامه اجرای به منظور فیلتر وجود دارد. در بیشتر موارد ، شما می بینید که یک ضایعات سمت چپ در برابر هر جدول (های) در عملکرد محمول استفاده می شود.

در اینجا دو برنامه برای همان پرس و جو انتخابی * وجود دارد ، اول بدون سیاست امنیتی در محل اجرا شد و دومین فیلتر سطح ردیف اعمال شده است:

در حالی که جای تعجب ندارد که منطق و اپراتورهای موجود در عملکرد با ارزش جدول درون خطی برای پرس و جو اصلی در برنامه اجرا قرار می گیرند ، این باید نشان دهد که بهینه سازی عملکرد محمول به منظور به حداقل رساندن تأثیر آن از اهمیت ویژه ای برخوردار است. می تواند داشته باشدچگونگی تأثیر آن در نهایت بر عملکرد کلی بار کاری شما بستگی به عوامل مختلفی از جمله الگوهای پرس و جو ، منطق در عملکرد و سایر عوامل دارد.

توجه به این نکته حائز اهمیت است که کاربران خارج از Sysadmin ، DB_OWNER ، DB_DDLADMIN و صاحب جدول دسترسی مستقیم به DBCC Show_statistics ندارند (از آنجا که این می تواند منجر به نشت اطلاعات شود) ، بنابراین ممکن است در بعضی موارد تخمین ها از بین بروند.

ناگفته نماند که شما باید برنامه (های) خود را برای رگرسیون رفتار و عملکرد کاملاً آزمایش کنید.

عیب یابی امنیتی سطح سرور SQL

به طور پیش فرض ، حتی DBO و Sysadmin به همه ردیف های جدول دسترسی ندارند. اگر نیاز به عیب یابی پرس و جو ، مواردی را تکرار کنید ، یا حتی فقط به طور اتفاقی داده ها را بازرسی کنید ، می خواهید اطمینان حاصل کنید که عملکرد محمول به شما امکان می دهد ، یا اینکه می توان از یک کاربر که دسترسی کامل دارد ، جعل کند. باز هم ، لطفاً حتماً تمام جنبه های برنامه (های) برنامه خود ، از جمله موارد لبه و حالت های وحشت را کاملاً آزمایش کنید.

علاوه بر این ، کاملاً ممکن است که یک برنامه اجرای پیچیده برای یک پرس و جو نسبتاً ساده ، باعث سردرگمی شود. برای کاربران بسیار سخت خواهد بود که بتوانند با هم جمع شوند که چرا اشیاء موجود در عملکرد محمول در برنامه پیچیده می شوند ، هنگامی که نه عملکرد و نه آن اشیاء در متن پرس و جو ارجاع نمی شوند.

SQL Server Row Level Security Data Leakage

روش های مختلفی وجود دارد که کاربران می توانند امنیت سطح ردیف را به دست آورند (در واقع ، در واقع ، من هنوز کمی مردد بوده ام که هنوز این ویژگی را به عنوان یک ویژگی امنیتی تحت فشار قرار داده ام). من قبلاً اشاره کردم که شاخص های متن کامل می توانند یک مشکل ایجاد کنند ، اما در اینجا چند سناریو دیگر وجود دارد که باید بر اساس کاربران ، طرحواره ها و سیاست های ایجاد شده در قسمت 1 - چندین مورد از آنها "حملات کانال جانبی تلقی شوند"."

مدیران سیاست و تبانی

همانطور که قبلاً ذکر شد ، حتی DBO و Sysadmin به داده های جدول دسترسی ندارند مگر اینکه صریحاً از طریق عملکرد محمول اعطا شود. با این حال ، بدیهی است ، اگر شخص مسئول مدیریت سیاست های امنیتی نیز به اصلاح توابع مورد استفاده در آن سیاست ها دسترسی داشته باشد ، آنها به راحتی می توانند منطق را برای گسترش دسترسی خود دستکاری کنند (این به راحتی با استفاده از محرک های DDL قابل کنترل است) ، یا با سایر موارد تبانی می کنند. کاربران برای به دست آوردن دید در ردیف هایی که کاربر می تواند ببیند. آنها همچنین می توانند به سادگی سیاست را به طور موقت غیرفعال کنند (هرچند که چنین اقداماتی را می توان حسابرسی کرد). یک یادداشت بسیار طولانی در مورد مدیر سیاست امنیتی مخرب در مستندات وجود دارد.

Context_info

در قسمت 1 ، من در مورد چگونگی اجرای یک سطح متوسط یا وب می توانند فیلتر سطح ردیف را حتی در صورت استفاده از یک ورود مشترک برای همه کاربران ، با عبور از ویژگی های خاص کاربر از طریق Context_info () صحبت کنم. البته مشکل در اینجا این است که اگر هر کاربر دسترسی به پرس و جو موقت را داشته باشد ، می تواند زمینه را نیز جعل کند. بنابراین کاربر من قبلاً ایجاد کردم ، Peon ، می تواند با استفاده از کد زیر ، داده های مربوط به هر کاربر مورد نظر خود را ببیند:

اجرای به عنوان کاربر = n'peon '؛GO DELDARECI VARBINARY (128) = CONVER (VARBINARY (128) ، N'Rep1 ') ؛Context_infoCi را تنظیم کنید ؛user_name () ، * را از dbo. accounts انتخاب کنید. برو برگردرفتن

یک راه حل بالقوه در اینجا اضافه کردن ماسک های داده پویا ، رمزگذاری در سطح ستون یا نوعی هشدار / مبهم / نمک زدن به نام Rep است ، بنابراین یک کاربر مخرب نمی داند چه چیزی را تنظیم کند.

اما به طور کلی ، شما همچنین باید دسترسی به این داده ها را از طریق روشهای ذخیره شده و کد برنامه کنترل کنید تا دسترسی مستقیم موقت پشتیبانی نشود.(من برای سهولت در تظاهرات ، از دسترسی مستقیم Ad Hoc در این نکات استفاده کردم ، نه به عنوان بهترین عمل.)

پرس و جوهای هوشمندانه هوشمندانه

While a query on its own can't retu rows the user can't access, it can be written in such a way that the user could deduce information about those rows. In the following example, the user Peon can determine which Reps have at least one account with AnnualFees>75000 دلار:

EXECUTE AS USER = N'Peon'; GO DECLARE @i INT = 1; BEGIN TRY SELECT * FROM dbo.Accounts WHERE CASE WHEN RepID = @i THEN CASE WHEN AnnualFees> 75000 THEN CONVERT(INT, 'x') -- designed to raise an exception END END = 1; END TRY BEGIN CATCH PRINT N'Rep ' + RTRIM(@i) + N' has an account with fees>75،000 دلار. '؛End Catch Go Revert ؛رفتن

If you put a loop around it, incrementing @i, this batch will print a line for each rep that has an account with AnnualFees>75000 دلار. این امر به این دلیل است که برخی از عبارات قبل از وقوع فیلتر سطح ردیف قابل ارزیابی هستند ، بنابراین می توان از طریق آن و ساخت بندهایی که می تواند به شما در استنباط اطلاعات زیادی در مورد سایر ردیف های جدول کمک کند ، آسان شود..

به احتمال زیاد ، در وهله اول هرگز نباید به Peon دسترسی پیدا کند ، اما به خاطر داشته باشید که هر نماینده دیگری می تواند همان نوع حمله را اجرا کند. امیدوارم که این نوع بهره برداری قبل از RTM بسته شود.

وارد کردن ردیف های نامعتبر

نکته دیگر این است که ، در ساختهای فعلی ، دسترسی به نوشتن توسط این خط مشی مسدود نمی شود - بنابراین اگر بتوانم روی جدول بنویسم ، می توانم سهوا (یا حتی عمداً) یک ردیف را برای یک نماینده دیگر وارد کنم:

Grant Insert ، به روزرسانی در DBO. Accounts به Rep1 ؛GO EXEC ('insert dbo. accounts (AccountId ، سالانه ، repid) مقادیر (99،50000،2) ؛') به عنوان کاربر = n'rep1 '؛

من فقط یک ردیف را درج کرده ام که حتی نمی توانم آن را ببینم (شما می توانید با موارد زیر اعتبار کنید):

exec ('انتخاب * از dbo. accounts که در آن حساب کاربری = 99 ؛') به عنوان کاربر = n'rep1 '؛exec ('انتخاب * از dbo. accounts که در آن حساب کاربری = 99 ؛') به عنوان کاربر = n'rep2 '؛

این مثال در این مورد از ارزش کمی برخوردار است ، اما هنوز هم قابل ذکر است. در یک محیط حساس تر ، قادر به وارد کردن ردیف هایی که در نهایت توسط مشتری یا مستاجر دیگر دیده می شود می تواند یک مشکل بسیار جدی باشد.

با این همه گفته شده ، قبل از RTM ، باید توانایی گسترش یافته به گونه ای را مشاهده کنیم که درج ها نیز تحت سیاست های امنیتی سطحی قرار بگیرند. در حال حاضر ، شما می توانید با استفاده از محدودیت های چک یا به جای محرک هایی که منطق استفاده شده در عملکرد محمول مربوطه را تقلید می کند ، از جدول درج های سرکش یا تصادفی محافظت کنید ، یا به سادگی کنترل درج ها را از طریق روشهای ذخیره شده که اجازه نمی دهد از ستون های مستاجر کلیدی غلبه کند ، محافظت کنید.

در هر صورت ، حتی در ساختهای فعلی ، DML دیگر از قبل نیز محافظت می شود. من نمی توانم یک ردیف را که در وهله اول نمی توانم به روز کنم یا حذف کنم. به عنوان مثال هیچ تغییری در اینجا رخ نمی دهد:

EXEC ('به روز رسانی dbo. Accounts set سالانه*= 2 که در آن حساب کاربری = 99 ؛') به عنوان کاربر = n'rep1 '؛EXEC ('انتخاب * از dbo. accounts که در آن حساب کاربری = 99 ؛') به عنوان کاربر = n'susan '؛

ضبط داده ها را تغییر داده و ردیابی را تغییر دهید

هر دوی این ویژگی ها می توانند ردیف ها را در معرض کاربران غیرمجاز قرار دهند حتی اگر یک سیاست امنیتی سطح ردیف از آن داده ها در جدول منبع محافظت کند. برای جزئیات بیشتر و سایر سناریوهای نشت داده های بالقوه ، به اسناد مراجعه کنید.

خلاصه

در حالی که امنیت سطح ردیف امکان ایجاد کنترل دسترسی دقیق با حداقل کدگذاری و تغییر برنامه را فراهم می کند ، برخی از این محدودیت ها ، تأثیرات و آسیب پذیری ها بسیار مهم هستند که باید در نظر داشته باشید که شما در نظر دارید که این ویژگی را برای محافظت از داده های خود در نظر بگیرید.

مراحل بعدی

• آخرین CTP SQL Server 2016 را بارگیری کنید (یا برای آزمایش Azure SQL Database V12 ، جایی که این ویژگی در ابتدا ظاهر شد) ثبت نام کنید.
• امنیت سطح ردیف را در سناریوهایی که ممکن است مفید به نظر برسد ، امتحان کنید.
• به این نکات مرتبط و منابع دیگر مراجعه کنید:
  • از امنیت سطح ردیف در SQL Server 2016 ، قسمت 1 استفاده کنید
  • نحوه تنظیم امنیت سطح ردیف برای SQL Server
  • اجرای SQL Server Row و Security Security
  • استفاده از سلسله مراتب فرزند والدین در SQL Server برای اجرای یک طرح امنیتی سفارشی
  • امنیت سطح ردیف (MSDN)
  • تمام نکات امنیتی