مطالعه بیشتر

نحوه فکر کردن درباره ساختاردهی گروه‌ها و مجوزها در متابیس.

استراتژی‌های مجوز

نحوه فکر کردن درباره ساختاردهی گروه‌ها و مجوزها در متابیس.

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

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

اگر به دنبال یک نمای کلی از نحوه کار مجوزها در متابیس هستید، مستندات ما را بررسی کنید.

مبانی ساختاردهی مجوزها

ساختار مجوز شما در تقاطع سه بخش متحرک قرار دارد:

مجموعه‌هایی که در متابیس می‌سازید
نحوه map کردن گروه‌ها در متابیس به org chart شما
data warehouse زیربنایی شما

پیش‌فرض permissive یا پیش‌فرض restrictive

بر اساس بخش و فرهنگ شرکت، بیشتر سازمان‌ها یا به یک نقطه شروع permissive یا restrictive پیش‌فرض می‌روند. حالا این یک تنظیماتی که در جایی در متابیس انتخاب می‌کنید نیست، بلکه یک چارچوب برای فکر کردن هنگام ساختاردهی مجوزهای شما است. آیا با همه داده و داشبوردها باز شروع می‌کنید و در صورت نیاز محدود می‌کنید؟ یا سازمان شما نیاز دارد همه داده را از ابتدا محدود کند، و فقط دسترسی به داشبوردها و سؤال‌ها را بر اساس need-to-know باز کند؟

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

امنیت و compliance

اگر سازمان شما داده‌های پزشکی، مالی، یا به طور مشابه حساس را handle می‌کند، محدودیت‌های سختی دارید که باید هنگام ایجاد مجوزهای داده و مجموعه رعایت کنید. در این سناریوها، discoverability در متابیس باید به امنیت و compliance اولویت بدهد.

نحوه رویکرد به مجوزها

در سطح بالا، این فرآیند باید چیزی شبیه این باشد:

سازمان خود را به گروه‌ها تقسیم کنید. این گروه‌ها ممکن است مستقیماً به org chart شما map شوند، در خطوط نقش‌هایی که کارمندان مختلف انجام می‌دهند قرار گیرند، یا به سطوح دسترسی (مثل security clearanceها) تقسیم شوند.
در هر گروه، بفهمید چه سؤال‌هایی و داشبوردهایی مشتریان نیاز دارند ببینند تا کار خود را انجام دهند، و اگر هنوز ایجاد نکرده‌اید آن‌ها را ایجاد کنید (یا بگذارید چیزهای خود را ایجاد کنند).
شناسایی کنید هر گروه نیاز دارد به چه چیزهایی دسترسی self-service داشته باشد، و مطمئن شوید می‌توانند آن مجموعه‌ها را curate کنند.
هر داده‌ای که نیاز دارید به شدت در سازمان خود برای دلایل امنیتی یا compliance قانونی کنترل شده نگه دارید را pinpoint و محدود کنید.
گروه‌ها و مجوزهای متابیس خود را به طور منظم ارزیابی و اصلاح کنید.

ساده بهترین است

ایده خوبی است مجوزهای متابیس خود را تا حد امکان ساده در محدودیت‌های نیازهای امنیتی و دسترسی سازمان خود نگه دارید. به سادگی، مشتریان وقتی به طیف وسیعی از ابزارها و اطلاعات دسترسی دارند مولدتر هستند. هر چه سطوح مجوز بیشتری داشته باشید، enforce کردن پیچیده‌تر می‌شود. مهم است راه‌هایی برای segment کردن داده حساس بدون شکستن browsability و سازماندهی پیدا کنید، پس سعی کنید با کمترین گروه‌های ممکن کارها را انجام دهید، چون گروه‌های کمتر با گذشت زمان ساده‌تر maintain می‌شوند. یک ساختار مجوز ساده و self-explanatory همچنین می‌تواند در صورت جابجایی کارکنان کارها را آسان‌تر کند. اگر یک مدیر واحد یک سیستم پیچیده برای اعطای مجوزهای مجموعه کنار هم می‌گذارد و سپس شرکت را ترک می‌کند، کارمندان باقی‌مانده ممکن است ندانند چگونه قطعات را بردارند.

انتظار تغییر استراتژی خود را داشته باشید

نیازهای شما تغییر خواهد کرد، پس به صورت سه‌ماهه check in کنید تا ارزیابی کنید ساختار مجوز شما چگونه کار می‌کند. آیا مشتریان در سازمان شما قادر به دسترسی به سؤال‌ها و داشبوردهایی که برای انجام کار خود نیاز دارند هستند؟ آیا داده حساس شما قفل شده است؟

ساختارهای مجوز نمونه

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

مجوزهای مبتنی بر org chart

ساده‌ترین، مستقیم‌ترین گزینه — و جایی که بیشتر شرکت‌ها می‌خواهند شروع کنند — map کردن گروه‌ها و مجموعه‌ها در متابیس به org chart موجود شما است. اگر بخش‌های Marketing و Accounting دارید، گروه‌های Marketing و Accounting متناظر، و همچنین مجموعه‌هایی که سؤال‌ها و داشبوردهای ذخیره شده برای نیازهای Marketing و Accounting را نگه می‌دارند ایجاد کنید.

در این سناریو، همه چیزهایی که یک شخص برای انجام کار خود نیاز دارد می‌تواند مستقیماً به گروهی که در آن هستند trace شود. مشتریان در بخش Marketing (و به طور گسترش، گروه) می‌توانند مجموعه Marketing را edit کنند، که می‌تواند توسط بخش Accounting مشاهده شود — اما edit نشود. احتمالاً نیاز به زیرمجموعه‌ها برای house کردن نیازهای Marketing خاص‌تر دارید — مثلاً، سؤال‌های ذخیره شده مرتبط با یک کمپین خاص. اگر آن پوشه‌های فرعی اطلاعات حساس دارند، می‌توانید آن‌ها را محدود کنید، و Accounting اصلاً آن‌ها را نمی‌بیند. نیاز دارید مجوزها را روی هر مجموعه و زیرمجموعه تنظیم کنید تا مطمئن شوید برای کسانی که به آن‌ها نیاز دارند قابل دسترسی هستند — این مقاله را برای یادگیری بیشتر درباره آن فرآیند ببینید.

مجوزهای مبتنی بر org chart، جایی که مجموعه‌های سطح بالا توسط همه قابل خواندن و توسط برخی قابل نوشتن هستند، با زیرمجموعه‌های مخفی در صورت نیاز، شروع عالی برای بیشتر سازمان‌ها هستند. این ساختار زمانی مؤثرترین است که هر شخص به یک گروه واحد تعلق دارد. همانطور که سازمان شما پیچیده‌تر می‌شود، ممکن است مجوزهای مبتنی بر org chart را دست‌وپاگیر بیابید، به خصوص اگر روی همکاری cross-departmental بزرگ هستید. اگر چنین است، ممکن است بخواهید یک رویکرد مبتنی بر attribute به مجوزهای متابیس را در نظر بگیرید.

مجوزهای مبتنی بر attribute

مجوزهای مبتنی بر attribute ممکن است مفید باشد اگر سازمان شما به یک ساختار سازمانی matrix-style پایبند است، جایی که مشتریان به طور منظم در podها یا در سراسر تیم‌ها کار می‌کنند. اگر چنین است، و متوجه شده‌اید یک گروه برای هر شخص دیگر کافی نیست، map کردن گروه‌های خود به functionها ممکن است مؤثرتر باشد.

بیایید بگوییم یک کارمند جدید دارید. آن‌ها یک analyst هستند، روی یک کمپین marketing خاص کار خواهند کرد، و نیاز به دسترسی به داده event زیربنایی دارند. این سه attribute نمی‌توانند به طور تمیز توسط یک map کردن گروه departmental ساده capture شوند، پس به جای آن، می‌توانید گروه‌هایی ایجاد کنید که شروع به mirror کردن functionها به جای مکان‌ها در org chart می‌کنند. چون مشتریان می‌توانند به چندین گروه در متابیس تعلق داشته باشند، این مسیر انعطاف‌پذیری بیشتری برای crafting راه‌حل‌های مجوز در سطح granularتر ارائه می‌دهد.

مجوزهای onion ring

یک مدل سوم برای در نظر گرفتن شامل فکر کردن به ساختار مجوز خود مثل یک پیاز، با حلقه‌ها یا لایه‌های مختلف نشان‌دهنده breadth دسترسی به مجموعه‌ها است. یک مثال ساده یک شرکت خواهد بود جایی که همه چیز transparent و قابل edit توسط همه است، به جز یک لایه (یا مجموعه) درون آن که فقط توسط executives و پرسنل HR قابل دسترسی است. رویکرد به مجوزها با این مدل onion ring در ذهن می‌تواند به شما کمک کند عمق دسترسی که هر شخص یا گروه در سازمان شما نیاز دارد را در نظر بگیرید.