امنیت سطح ردیف (RLS) ابزار امنیتی را در اختیار ما قرار می دهد که می تواند دسترسی به داده ها را در سطح ردیف داده ها محدود کند. این تکنیک امنیتی در موقعیت‌هایی که ممکن است نیاز به دسترسی مشخص به داده‌هایی داشته باشیم که در آن «کل» ذخیره می‌شود، اما فقط «بخشی» باید توسط کاربران قابل دسترسی باشد، ارزش دارد – مانند فهرست محصولات همه شرکت‌هایی که یک شرکت فقط می‌تواند آنها را ببیند. محصولات آن ها.
در حالی که این پست یک مثال در SQL Server است، امنیت سطح ردیف را می توان در SQL Server 2016 و بالاتر، Azure SQL، Azure SQL Managed Instance، Azure Synapse و Warehouse in Fabric استفاده کرد.
چه زمانی از امنیت سطح ردیف استفاده کنیم؟
در حالی که RLS تنها ابزاری نیست که در این شرایط به ما کمک می‌کند، ممکن است ابزاری باشد که در شرایط زیر مفید باشد و بتوانیم از آن استفاده کنیم. ما ممکن است RLS را در شرایط زیر در نظر بگیریم:
- مطابق با الزامات امنیتی سختگیرانه شرکت ما یا الزامات قانونی که دسترسی به داده های حساس باید توسط کاربر یا نقش در شرکت فیلتر شود.
- وقتی داده‌هایی که در سطح ردیف ذخیره می‌کنیم، مستقیماً به مسئولیت‌های کاربر یا نقشی که داده‌ها را مشاهده می‌کند، مربوط می‌شود. اگر داده ها مربوط به کاربر یا نقش در سطح ستون باشد، ما پوشش داده پویا را در نظر می گیریم.
یک روش بصری برای فکر کردن در مورد RLS یک نمودار دایره ای است که در آن هر قطعه از دایره نشان دهنده یک کاربر است و هر کاربر فقط باید بتواند قطعه خود را از کل دایره مشاهده کند. همانطور که خواهیم دید، مانند پوشش داده پویا، نگرانی‌های امنیتی در RLS وجود دارد که یکی از دلایلی است که در لیست توصیه‌های من از ابزارهای امنیتی قرار ندارد.
ملاحظات امنیتی سطح ردیف
مانند پوشش داده پویا، امنیت سطح ردیف (RLS) حملات را دعوت می کند زیرا داده ها در پایگاه داده وجود دارند. یک هکر می داند که اگر پایگاه داده شما را به خطر بیندازد، می تواند به داده های شما دسترسی پیدا کند. در مورد RLS، هکر می‌داند که موضوع فقط مجوزهاست. هکرها می توانند از مهندسی اجتماعی برای تعیین اینکه آیا یک شرکت از امنیت سطح ردیف استفاده می کند یا خیر استفاده کنند و اگر چنین است، آنها می دانند که فقط باید پایگاه داده را به خطر بیاندازند. یک مثال خاص تر از این (و شکلی از مهندسی اجتماعی) استفاده از رسانه های اجتماعی برای شناسایی افرادی است که در یک شرکت هدف کار می کنند، آیا از RLS استفاده می کنند یا خیر، و دسترسی افراد را به خطر می اندازد (Spearphishing از تجزیه و تحلیل رسانه های اجتماعی راه دیگری خواهد بود). . حتی اگر فرض کنیم هکر فقط یک کارمند را به خطر می اندازد (یکی کار دوم و سوم را آسان تر می کند)، برای به دست آوردن داده ها کافی است.
در مقابل، در مورد یک رویکرد امنیتی مانند همیشه رمزگذاری شده که در آن لایه دیگری کلید رمزگشایی داده‌ها را دارد، هکر باید دو لایه را به خطر بیندازد – به سادگی دریافت داده‌ها کافی نخواهد بود. در هر دو مورد پوشش داده پویا و امنیت سطح ردیف، این مورد نیست.
اگر قصد داریم از RLS استفاده کنیم، باید از عملکرد آن از طریق آزمایش کافی اطمینان حاصل کنیم. همانطور که در بالا دیدیم، AFTER و BFORE UPDATE در آنچه ممکن است برای کاربران اتفاق بیفتد متفاوت است. ما می‌خواهیم سناریوهای آزمایشی دقیقی داشته باشیم که اطمینان حاصل کند که امنیت سطح ردیف همانطور که در نظر گرفته شده است عمل می‌کند. همیشه باید به یاد داشته باشیم که برای شکست (یا در مورد امنیت، مصالحه) طراحی می کنیم. این بدان معنی است که ما با معماری خود به گونه ای آزمایش می کنیم که گویی می خواهیم امنیت را به خطر بیندازیم. من به شدت توصیه می کنم در مورد افرادی که از این ویژگی در معماری خود استفاده کرده اند تحقیق کنید، زیرا آنها برخی از مسائلی را که در محیط خود دیده اند یادداشت می کنند.
به خواندن کل پست با مثال های T-SQL ادامه دهید
