رویکرد Metabase به مجوزها

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

پروژه Metabase رابطه جالبی با مجوزها و کنترل‌های دسترسی داشته است. ما همزمان شفافیت کامل را ترویج کرده‌ایم در حالی که محدودیت‌های کنترل دسترسی بسیار سخت‌گیرانه‌ای روی نمونه‌ای که به صورت داخلی اجرا می‌کنیم داشته‌ایم.

ابتدا کمی تاریخ — Metabase به عنوان سیستم تحلیل داخلی Expa (www.expa.com) شروع شد. در طول آن دوره زمانی، Metabase نیازهای متضادی داشت. از یک طرف، ما می‌خواستیم هر شرکتی به شدت مبتنی بر داده باشد، و دسترسی شرکت‌محور به اطلاعات، تحلیل و کشف از پایین به بالا را ترویج کردیم. از طرف دیگر، ما انواع شرکت‌هایی با کسب‌وکارهای به شدت متفاوت، پروفایل‌های عمومی و از این رو مدل‌های تهدید امنیتی داشتیم. در شروع، ما مسیر معمول را رفتیم، و یک مدل مجوز نسبتاً عمومی داشتیم. ما هر شرکت را به گروه خودش تقسیم کردیم و به آن گروه دسترسی به داده‌های شرکت در انبار داده متمرکز ما دادیم. اگر به forensics کد منبع تمایل دارید، می‌توانید انواع باقی‌مانده‌های جالب از این را در commitهای اولیه عمومی ما پیدا کنید. همانطور که از فرآیند قفل کردن تدریجی چیزها عبور کردیم، در نهایت تصمیم گرفتیم که ایجاد پارتیشن‌های سخت بین داده‌های شرکت‌های مختلف منطقی‌تر است. حساب‌های کاربری، داده‌های برنامه، و انبار داده‌های زیربنایی همه تقسیم شدند و روی VMهای جداگانه ذخیره شدند، و برنامه به تدریج در پاسخ به این تغییر شکل داد.

وقتی Metabase را منبع باز کردیم، این دیدگاه نسبتاً باینری از جهان را با انتظار اینکه استفاده اصلی Metabase در شرکت‌های کوچک یا تیم‌های نسبتاً همگن در شرکت‌های بزرگتر باشد منتقل کردیم. همانطور که ما پذیرش در شرکت‌های بزرگتر و ناهمگن‌تر پیدا کرده‌ایم، بازخورد دریافت کرده‌ایم که این تقسیم جهان کمی... بگذارید بگوییم ساده‌لوحانه است؟ راهی برای کنترل مجوزهای دسترسی در بالای فهرست بازخورد از همه کسانی که با آنها صحبت کرده‌ایم بوده است. issueهای متعدد و به طور گسترده رأی‌گیری شده در github مرتبط با کنترل‌های دسترسی وجود داشته است. مشتریان به معنای واقعی کلمه به ما تلفن زده‌اند تا این را درخواست کنند.

در همان زمان، تیم کمی در مورد فقط "چسباندن یک نسخه بد LDAP روی آن" تردید داشته است. از آغاز پروژه، ما تمایل قوی به ارسال یک برنامه که ساده، ظریف و آسان برای استفاده، نصب و مدیریت است داشتیم. برای رسیدن به اینکه سیستم مجوز نهایی ما آن اهداف را برآورده کند، تصمیم گرفتیم سعی کنیم تا حد امکان اطلاعات درباره سناریوهای مختلف کاربران خود که نیاز به کنترل‌های دسترسی داشتند جمع‌آوری کنیم. ما مکالمات زیادی در github و همچنین حضوری داشته‌ایم، و به تدریج یک راه‌حل برای این مشکلات زیربنایی ترکیب کرده‌ایم.

خوشحالیم که بگوییم با شروع از آخرین نسخه ما (0.20)، ما یک چارچوب مجوز را که می‌تواند برای ارائه دسترسی کنترل شده به داده استفاده شود راه‌اندازی می‌کنیم.

در هسته آن، چارچوب مجوزی که ما در 0.20 ارسال می‌کنیم ساده است — می‌توانید کاربران را به گروه‌ها اختصاص دهید و می‌توانید به گروه‌ها دسترسی به داده بدهید. گروه‌ها می‌توانند محدودیت‌هایی روی پایگاه‌های داده، جداول و دسترسی SQL خام داشته باشند. Metabase مشخص می‌کند که کدام داشبوردها، سوالات و pulseها یک کاربر معین می‌تواند بر اساس مجوزهای دسترسی داده گروه‌های خود ببیند. به طور خلاصه ما توجه شما را روی داده‌ای که کاربر به آن دسترسی دارد متمرکز می‌کنیم به جای اینکه کدام داشبوردها می‌توانند مشاهده کنند. چرا ما این کار را انجام می‌دهیم به جای اینکه به شما کنترل مستقیم بر اینکه چه کسی کدام داشبورد یا سوال را مستقیماً می‌بیند بدهیم؟

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

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

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

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