چت بات

مدیر منطقه فقط آمار منطقه‌ی خودش را ببیند: دسترسی سطح ردیف در دیتابیس هوشمند دانابات

وقتی مدیران به فارسی از پایگاه داده سؤال می‌پرسند، مسئله‌ی اصلی امنیت است. ببینید دسترسی سطح ردیف در دیتابیس هوشمند دانابات چطور کار می‌کند و اگر محدودیت اعمال نشود چه می‌شود.

م
مرتضی علیزاده
8 دقیقه مطالعه
۳۹ بازدید
دسترسی سطح ردیف در دیتابیس هوشمند دانابات: هر مدیر فقط داده‌ی مجاز خودش را می‌بیند
دسترسی سطح ردیف در پرسش از پایگاه داده با دانابات | ArtinMag

پاسخ سریع

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

فهرست مطالب (11 بخش)

سوالی که مدیر امنیت قبل از مدیر فروش می‌پرسد

وقتی یک سازمان بزرگ درباره‌ی «پرسش از پایگاه داده به زبان فارسی» می‌شنود، اولین واکنش مدیران عملیاتی هیجان است: «پس دیگر لازم نیست برای هر گزارش به کارشناس درخواست بدهم.» اولین واکنش مدیر امنیت یا مدیر فناوری اما یک پرسش است: «اگر مدیر یک منطقه بپرسد کل شرکت چقدر فروخت، جواب می‌گیرد؟»

این پرسش، درست‌ترین پرسش ممکن است. چون سیستمی که به هر کس اجازه بدهد از کل پایگاه داده سؤال بپرسد، حتی اگر دقیق و سریع باشد، برای سازمان بزرگ قابل‌استفاده نیست. در مقاله‌ی دیتابیس هوشمند توضیح دادیم که مدیر به فارسی می‌پرسد و جواب را به شکل جدول، نمودار یا Excel می‌گیرد. این مقاله به همان پرسش امنیتی می‌پردازد: هر کاربر دقیقاً چه چیزی را می‌بیند و اگر سیستم نتواند این را تضمین کند، چه می‌شود.

چرا کنترل دسترسی در سطح جدول کافی نیست

ساده‌ترین شکل کنترل دسترسی در پایگاه داده این است که بگوییم فلان کاربر به جدول «فروش» دسترسی دارد و فلان کاربر ندارد. اما در عمل، مشکل از جای دیگری شروع می‌شود. جدول فروش یک جدول واحد است که ردیف‌هایش مربوط به همه‌ی شعبه‌ها و منطقه‌هاست. مدیر منطقه‌ی شمال به جدول فروش نیاز دارد، اما نه به ردیف‌های منطقه‌ی جنوب.

همین‌جاست که کنترل در سطح جدول کم می‌آورد. دو راه ساده‌ی ظاهری وجود دارد و هر دو بد است. یا به مدیر منطقه کل جدول را بدهید که یعنی همه‌چیز را ببیند، یا اصلاً به او دسترسی ندهید که یعنی ابزار برایش بی‌فایده است. راه سوم، دسترسی سطح ردیف است: هر کاربر از همان جدول فقط ردیف‌هایی را می‌بیند که به او مربوط است.

دسترسی سطح ردیف یعنی چه

در دیتابیس هوشمند دانابات، هر کاربر فقط داده‌ی مجاز خودش را می‌بیند. اگر مدیر منطقه‌ی شمال و مدیرعامل هر دو دقیقاً یک جمله بپرسند، «فروش ماه گذشته چقدر بود؟»، جوابشان فرق دارد: اولی عدد منطقه‌ی خودش را می‌گیرد و دومی عدد کل شرکت را. پرسش یکی است و پاسخ بر اساس هویت و حق دسترسی کاربر ساخته می‌شود.

نکته‌ی مهم این است که این محدودیت روی پاسخ نهایی «پوشانده» نمی‌شود؛ روی پرسشی که از پایگاه داده پرسیده می‌شود اعمال می‌شود. یعنی داده‌ی غیرمجاز اصلاً به پاسخ نمی‌رسد. این همان اصلی است که در همه‌ی بخش‌های دانابات رعایت می‌شود: فیلتر روی ورودی، نه روی خروجی.

«بستن به جای نمایش»: اگر محدودیت اعمال نشود

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

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

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

پیش از ردیف: جدول و ستون

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

و چون همه‌چیز در این بخش فقط خواندنی است، حتی در بدترین حالت هم هیچ داده‌ای تغییر نمی‌کند. دانابات پایگاه داده را فقط می‌خواند؛ نه چیزی اضافه می‌کند، نه ویرایش می‌کند و نه حذف می‌کند.

وقتی دو مدیر دو عدد متفاوت می‌بینند

دسترسی سطح ردیف یک پیامد جانبی دارد که باید از قبل بدانید: دو مدیر که یک پرسش را می‌پرسند، عددهای متفاوتی می‌گیرند، و این رفتار درست است. اما اگر سازمان آماده نباشد، همین موضوع اختلاف ایجاد می‌کند: «چرا عدد شما با عدد من فرق دارد؟»

بخش مهمی از این اختلاف‌ها واقعاً از دسترسی نیست، از تعریف است. «فروش ماه» برای یک واحد یعنی فروش ثبت‌شده، و برای واحد دیگر یعنی فروش وصول‌شده. برای همین دیتابیس هوشمند یک قابلیت به نام شاخص‌های رسمی دارد: سؤال‌هایی که زیاد تکرار می‌شوند، یک تعریف قطعی می‌گیرند و پاسخ سریع و یکسان تحویل می‌دهند. نتیجه این است که اختلاف عدد فقط وقتی پیش می‌آید که به‌خاطر دسترسی متفاوت باشد، نه به‌خاطر تعریف متفاوت.

سه سناریوی واقعی‌نما

این سناریوها فرضی‌اند و نمونه‌ی مشتری مشخصی نیستند.

سناریوی اول، یک شرکت با پنج منطقه‌ی فروش. مدیر منطقه‌ی شمال می‌پرسد «فروش ماه گذشته به تفکیک محصول چقدر بود؟» و جدول و نمودار فروش منطقه‌ی خودش را می‌گیرد. مدیر فروش کل شرکت همان سؤال را می‌پرسد و عدد کل را می‌بیند. کسی نیاز نداشت گزارش اختصاصی بسازد.

سناریوی دوم، واحد منابع انسانی. مدیر یک واحد می‌پرسد «تأخیر و غیبت کارکنان واحد من در سه ماه گذشته چقدر بوده؟» و فقط ردیف‌های همان واحد را می‌بیند. اگر همان مدیر بپرسد «حقوق کارکنان چقدر است؟» و ستون حقوق برایش بسته باشد، پاسخ نمی‌گیرد. دو لایه‌ی جدول و ستون و ردیف با هم کار می‌کنند.

سناریوی سوم، حالت خطا. به‌دلیل یک اشتباه تنظیمات، هویت یک کاربر جدید به دانابات نرسیده است. او می‌پرسد «فروش ماه چقدر بود؟» اما به‌جای عدد کل شرکت، پاسخی نمی‌گیرد. تیم فنی خطا را پیدا و اصلاح می‌کند. اگر سیستم برعکس رفتار می‌کرد، در همان لحظه یک کاربر ناشناس کل آمار شرکت را می‌دید.

محدودیت‌هایی که باید بدانید

اگر فقط خوبی‌ها را بگوییم، به شما خدمت نکرده‌ایم، پس چند محدودیت را روشن می‌گوییم.

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

دوم، دانابات باید بداند کاربر کیست. اجرای محدودیت به این بستگی دارد که هویت کاربر به‌درستی در اختیار دانابات قرار گیرد. اگر این اتصال ناقص باشد، سیستم طبق اصل «بسته در خطا» پاسخ نمی‌دهد و کاربر این را به شکل پاسخ خالی تجربه می‌کند.

سوم، این بخش روی سه نوع پایگاه داده کار می‌کند: SQL Server، PostgreSQL و SQLite. اگر پایگاه داده‌ی اصلی شما از این سه نیست، پیش از هر تصمیمی باید این را در جلسه‌ی شناخت روشن کنید.

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

پنجم، تنظیم و آزمون دسترسی کار و زمان می‌برد. هر چه قواعد دسترسی پیچیده‌تر باشد، آزمونش هم بیشتر طول می‌کشد.

مسیر شروع برای سازمانی که دسترسی مهم است

روش پیشنهادی دانابات پنج مرحله است. اول جلسه‌ی شناخت، که در آن پایگاه داده‌ای انتخاب می‌شود که بیشترین پرسش گزارش را دارد. بعد اثبات مفهوم روی بخشی از داده‌ی واقعی، یک تا دو هفته. بعد ارزیابی با سؤال‌های واقعی مدیران، حدود یک هفته. بعد بهره‌برداری آزمایشی در یک واحد، حدود دو هفته. و در نهایت گسترش تدریجی. درباره‌ی نحوه‌ی ارزیابی دقت با سؤال‌های واقعی، در مقاله‌ی سنجش دقت توضیح داده‌ایم.

برای سازمانی که دسترسی سطح ردیف مهم است، یک کار را باید به این مسیر اضافه کنید: آزمون با حساب‌های واقعی. چند کاربر واقعی با سطح‌های دسترسی مختلف انتخاب کنید، یک مجموعه پرسش یکسان از همه بپرسید و ببینید هر نفر دقیقاً چه چیزی می‌بیند.

اشتباهی که در این مرحله رایج است

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

برای همین، همان‌طور که در مسیر شروع گفتیم، آزمون باید با حساب‌های واقعی و محدود انجام شود، نه فقط با حساب مدیر. و اشتباه دوم، تعریف قواعد فقط بر اساس عنوان شغلی است. «مدیر» در یک سازمان ممکن است مدیر یک واحد کوچک باشد یا مدیر کل یک حوزه. قاعده را بر اساس واحد و حوزه‌ی مسئولیت واقعی تعریف کنید، نه فقط عنوان. اصول عمومی کنترل دسترسی را در مقاله‌ی حاکمیت داده و دسترسی هم آورده‌ایم.

جمع‌بندی

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

تحلیل آرتین

این مقاله مسئله را از زاویه‌ی نگرانی واقعی مدیر امنیت می‌گوید: نه «پاسخ چقدر دقیق است» بلکه «اگر چیزی خراب شود چه کسی چه چیزی می‌بیند». هزینه‌ی رفتار بسته در خطا، یعنی پاسخ خالی برای کاربر مجاز، صریحاً گفته شده تا مخاطب فنی آن را کشف نکند.

اثر بر کسب‌وکار

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

در ایران

سازمان‌های بزرگ و دولتی ایران معمولاً ساختار چندواحدی و حساسیت بالا به محرمانگی دارند و ابزارهای ابری عمومی برایشان قابل‌پذیرش نیست؛ دسترسی سطح ردیف با نصب داخل شبکه مکمل یکدیگرند.

سوالات متداول

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

نظرات (0)

اطلاعات شما محفوظ می‌ماند و در نظرات بعدی نیاز به وارد کردن مجدد نیست

ک
نظر شما پس از تایید نمایش داده می‌شود

هنوز نظری ثبت نشده است

اولین نفری باشید که نظر می‌دهد!