سوالی که مدیر امنیت قبل از مدیر فروش میپرسد
وقتی یک سازمان بزرگ دربارهی «پرسش از پایگاه داده به زبان فارسی» میشنود، اولین واکنش مدیران عملیاتی هیجان است: «پس دیگر لازم نیست برای هر گزارش به کارشناس درخواست بدهم.» اولین واکنش مدیر امنیت یا مدیر فناوری اما یک پرسش است: «اگر مدیر یک منطقه بپرسد کل شرکت چقدر فروخت، جواب میگیرد؟»
این پرسش، درستترین پرسش ممکن است. چون سیستمی که به هر کس اجازه بدهد از کل پایگاه داده سؤال بپرسد، حتی اگر دقیق و سریع باشد، برای سازمان بزرگ قابلاستفاده نیست. در مقالهی دیتابیس هوشمند توضیح دادیم که مدیر به فارسی میپرسد و جواب را به شکل جدول، نمودار یا Excel میگیرد. این مقاله به همان پرسش امنیتی میپردازد: هر کاربر دقیقاً چه چیزی را میبیند و اگر سیستم نتواند این را تضمین کند، چه میشود.
چرا کنترل دسترسی در سطح جدول کافی نیست
سادهترین شکل کنترل دسترسی در پایگاه داده این است که بگوییم فلان کاربر به جدول «فروش» دسترسی دارد و فلان کاربر ندارد. اما در عمل، مشکل از جای دیگری شروع میشود. جدول فروش یک جدول واحد است که ردیفهایش مربوط به همهی شعبهها و منطقههاست. مدیر منطقهی شمال به جدول فروش نیاز دارد، اما نه به ردیفهای منطقهی جنوب.
همینجاست که کنترل در سطح جدول کم میآورد. دو راه سادهی ظاهری وجود دارد و هر دو بد است. یا به مدیر منطقه کل جدول را بدهید که یعنی همهچیز را ببیند، یا اصلاً به او دسترسی ندهید که یعنی ابزار برایش بیفایده است. راه سوم، دسترسی سطح ردیف است: هر کاربر از همان جدول فقط ردیفهایی را میبیند که به او مربوط است.
دسترسی سطح ردیف یعنی چه
در دیتابیس هوشمند دانابات، هر کاربر فقط دادهی مجاز خودش را میبیند. اگر مدیر منطقهی شمال و مدیرعامل هر دو دقیقاً یک جمله بپرسند، «فروش ماه گذشته چقدر بود؟»، جوابشان فرق دارد: اولی عدد منطقهی خودش را میگیرد و دومی عدد کل شرکت را. پرسش یکی است و پاسخ بر اساس هویت و حق دسترسی کاربر ساخته میشود.
نکتهی مهم این است که این محدودیت روی پاسخ نهایی «پوشانده» نمیشود؛ روی پرسشی که از پایگاه داده پرسیده میشود اعمال میشود. یعنی دادهی غیرمجاز اصلاً به پاسخ نمیرسد. این همان اصلی است که در همهی بخشهای دانابات رعایت میشود: فیلتر روی ورودی، نه روی خروجی.
«بستن به جای نمایش»: اگر محدودیت اعمال نشود
مهمترین رفتار این بخش، رفتار در حالت خطاست. فرض کنید به هر دلیلی سیستم نتواند محدودیت کاربر را اعمال کند: هویت کاربر مشخص نیست، قاعدهی دسترسی او تعریف نشده، یا هر مشکل دیگری پیش آمده. دو رفتار ممکن است. رفتار اول این است که سیستم برای اینکه کاربر ناراضی نشود، پاسخ را بدون محدودیت بدهد. رفتار دوم این است که سیستم چیزی نشان ندهد.
دانابات رفتار دوم را انتخاب کرده است. اگر سیستم نتواند محدودیت را اعمال کند، بهجای نمایش داده، میبندد و چیزی نشان نمیدهد. در دنیای امنیت به این رفتار «بسته در خطا» میگویند، و دلیلش ساده است: وقتی چیزی خراب میشود، بهتر است خرابی در جهت پنهان کردن داده باشد، نه افشای آن.
این رفتار هزینه هم دارد و بهتر است صادقانه گفته شود. گاهی کاربری که حق دیدن داده را دارد، به دلیل یک مشکل در تنظیمات، پاسخ خالی میگیرد و ناراحت میشود. این ناراحتی قابلپیگیری و رفعشدنی است. اما دادهی لورفته را نمیتوان پس گرفت.
پیش از ردیف: جدول و ستون
دسترسی سطح ردیف تنها لایهی کنترل نیست. پیش از آن، دسترسی در سطح جدول و ستون هم تعریف میشود. یعنی سازمان میتواند مشخص کند فلان کاربر اصلاً جدول حقوق و دستمزد را نبیند، یا ستون شمارهی ملی در هیچ پاسخی نیاید. لایهی ردیف روی اینها سوار میشود: کاربری که به جدول مجاز است، فقط ردیفهای خودش را میبیند.
و چون همهچیز در این بخش فقط خواندنی است، حتی در بدترین حالت هم هیچ دادهای تغییر نمیکند. دانابات پایگاه داده را فقط میخواند؛ نه چیزی اضافه میکند، نه ویرایش میکند و نه حذف میکند.
وقتی دو مدیر دو عدد متفاوت میبینند
دسترسی سطح ردیف یک پیامد جانبی دارد که باید از قبل بدانید: دو مدیر که یک پرسش را میپرسند، عددهای متفاوتی میگیرند، و این رفتار درست است. اما اگر سازمان آماده نباشد، همین موضوع اختلاف ایجاد میکند: «چرا عدد شما با عدد من فرق دارد؟»
بخش مهمی از این اختلافها واقعاً از دسترسی نیست، از تعریف است. «فروش ماه» برای یک واحد یعنی فروش ثبتشده، و برای واحد دیگر یعنی فروش وصولشده. برای همین دیتابیس هوشمند یک قابلیت به نام شاخصهای رسمی دارد: سؤالهایی که زیاد تکرار میشوند، یک تعریف قطعی میگیرند و پاسخ سریع و یکسان تحویل میدهند. نتیجه این است که اختلاف عدد فقط وقتی پیش میآید که بهخاطر دسترسی متفاوت باشد، نه بهخاطر تعریف متفاوت.
سه سناریوی واقعینما
این سناریوها فرضیاند و نمونهی مشتری مشخصی نیستند.
سناریوی اول، یک شرکت با پنج منطقهی فروش. مدیر منطقهی شمال میپرسد «فروش ماه گذشته به تفکیک محصول چقدر بود؟» و جدول و نمودار فروش منطقهی خودش را میگیرد. مدیر فروش کل شرکت همان سؤال را میپرسد و عدد کل را میبیند. کسی نیاز نداشت گزارش اختصاصی بسازد.
سناریوی دوم، واحد منابع انسانی. مدیر یک واحد میپرسد «تأخیر و غیبت کارکنان واحد من در سه ماه گذشته چقدر بوده؟» و فقط ردیفهای همان واحد را میبیند. اگر همان مدیر بپرسد «حقوق کارکنان چقدر است؟» و ستون حقوق برایش بسته باشد، پاسخ نمیگیرد. دو لایهی جدول و ستون و ردیف با هم کار میکنند.
سناریوی سوم، حالت خطا. بهدلیل یک اشتباه تنظیمات، هویت یک کاربر جدید به دانابات نرسیده است. او میپرسد «فروش ماه چقدر بود؟» اما بهجای عدد کل شرکت، پاسخی نمیگیرد. تیم فنی خطا را پیدا و اصلاح میکند. اگر سیستم برعکس رفتار میکرد، در همان لحظه یک کاربر ناشناس کل آمار شرکت را میدید.

