رفتن به محتوا

دسترسی فقط‌خواندنی

دسترسی فقط‌خواندنی یعنی حسابی که برای اتصال اوبا معرفی می‌کنید بتواند اطلاعات موردنیاز را بخواند، اما اجازهٔ ایجاد، تغییر یا حذف دادهٔ کسب‌وکار را نداشته باشد. هدف، آماده کردن محدوده‌ای مشخص برای تحلیل است؛ دسترسی کامل مدیر سامانه برای پرسیدن سؤال لازم نیست. این محدودیت را باید در خود منبع برقرار کنید تا وابسته به متن سؤال یا توضیح نوشته‌شده در برنامه نباشد.

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

مسئولیت‌ها را پیش از ساخت حساب تعیین کنید

Section titled “مسئولیت‌ها را پیش از ساخت حساب تعیین کنید”

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

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

محدودهٔ لازم را با یک هدف واقعی انتخاب کنید

Section titled “محدودهٔ لازم را با یک هدف واقعی انتخاب کنید”

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

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

حساب اختصاصی و مجوز خواندن

Section titled “حساب اختصاصی و مجوز خواندن”

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

از نقش‌های مدیریتی، مجوز ایجاد جدول و مجوز اجرای عملیات نوشتنی عمومی استفاده نکنید. دربارهٔ جدول‌های آینده نیز تصمیم بگیرید: آیا ایجاد یک جدول تازه باید خودکار آن را قابل خواندن کند یا هر بار نیاز به تأیید دارد؟ انتخاب پیش‌فرض گسترده می‌تواند بعدها داده‌ای را در اختیار اتصال بگذارد که هنگام راه‌اندازی وجود نداشت. بررسی دوره‌ای مجوزها این تغییر ناخواسته را آشکار می‌کند.

در Snowflake و BigQuery، نقش یا حساب سرویس باید فقط دامنهٔ خواندن لازم را داشته باشد. برای سرویس API و صفحه‌گسترده نیز اجازهٔ حساب و دامنهٔ خواندنی را مطابق سرویس تنظیم کنید. محدودیت‌های هر منبع متفاوت‌اند؛ دستور یک سامانه را بدون تطبیق روی سامانهٔ دیگر اجرا نکنید. برای نمونه‌های شبکه و MySQL به راهنمای دسترسی شبکه مراجعه کنید.

کنترل شبکه و اطلاعات ورود

Section titled “کنترل شبکه و اطلاعات ورود”

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

رمز باید اختصاصی باشد و در کانال یا فایل عمومی قرار نگیرد. آن را فقط در فیلد مربوط به اتصال وارد کنید. تغییر رمز در منبع نیاز به به‌روزرسانی تنظیمات اوبا دارد؛ وگرنه درخواست‌های تازه با اطلاعات قدیمی شکست می‌خورند. متن خطا و تصویر فرم نیز باید پیش از ارسال برای پشتیبانی از هرگونه راز یا اطلاعات شخصی غیرضروری پاک شوند.

مثال: حساب محدود برای گزارش فروش

Section titled “مثال: حساب محدود برای گزارش فروش”

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

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

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

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

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