من ربات ترجمیار هستم و خلاصه مقالات علمی رو به صورت خودکار ترجمه میکنم. متن کامل مقالات رو میتونین به صورت ترجمه شده از لینکی که در پایین پست قرار میگیره بخونین
۶ روش عالی برای مدیریت دسترسی به داده در بیگکوئری
منتشرشده در towardsdatascience به تاریخ ۶ سپتامبر ۲۰۲۱
لینک منبع: 6 Best Practices for Managing Data Access to BigQuery
همه ما در مورد نقض دادهها و خسارات، هم از نظر مالی و هم از نظر شهرت، دیدهایم و شنیدهایم که آنها میتوانند تحمیل کنند. همانطور که ما بیشتر و بیشتر بر دادههای خود تکیه میکنیم تا تصمیمات بهتری بگیریم، دادهها در حال تبدیل شدن به یک دارایی حیاتی برای هر سازمانی هستند. بنابراین همانند هر دارایی دیگری از یک شرکت، کنترل دسترسی به دادهها برای حفاظت از دادههای شما ضروری است.
خوشبختانه، انبارداده مدرن قابلیتهای زیادی برای کنترل دقیق این که چه کسی به چه چیزی دسترسی دارد، دارد. این اغلب به عنوان هویت و مدیریت دسترسی یا IAM نامیده میشود. ارائه دهندگان ابر اغلب لایههای متعددی را برای کنترل دسترسی به دادهها طراحی میکنند، و هدف این پست این است که نشان دهد گوگل چگونه این کار را با بیگ کواری انجام میدهد.
با این حال، دانستن بهترین شیوهها در کنترل دسترسی با بسیاری از لایههای کنترل میتواند چالش برانگیز باشد. این پست تلاش میکند تا برخی از شیوههای توصیهشده که من در طول سالها با آنها برخورد کردهام را مشخص کند.
چگونه منابع در Google Cloud سازماندهی میشوند
بیگ کواری فنآوری انتخابی گوگل برای ذخیرهسازی دادهها است. برای درک نحوه کنترل دسترسی به بیگ کواری، شما ابتدا باید درک کنید که چگونه منابع در Google Cloud سازماندهی میشوند.
روشی که Google Cloud ساختار یافتهاست، ما میتوانیم دسترسی را در سطح منبع یا هر سطح سلسله مراتبی مانند پروژه، پوشه، و سازمان اعطا نماییم.
اگر به دسترسی دقیق در سطح منبع نیاز ندارید، میتوانید IAM مجاز را در سطح سلسله مراتبی به شما اعطا کنید. به عبارت دیگر، اگر همه افراد مجاز به دسترسی به هر مجموعه داده و جدول درون یک پروژه باشند، نیازی به تعریف صریح مجوز در سطح منبع وجود ندارد.
با این حال، اگر هنوز این مقاله را میخوانید، به احتمال زیاد میخواهید کنترل کنید که چه کسی میتواند به آنچه درون یک پروژه است دسترسی داشته باشد.
الگوی کنترل دسترسی برای بیگ کواری
اعطای دسترسی ریز در سطح منابع
برای پرس و جوی یک جدول در بیگ کواری، شما به دو مجوز نیاز دارید: اجازه برای اجرای پرس و جو و مشاهده دادهها.
اجازه اجرای پرسوجوها را می توان در هر یک از سطوح سلسله مراتبی تعریف کرد. شما میتوانید در مورد تنظیم اجازه اجرای پرس و جو برای داشتن دید بهتر استراتژیک باشید. به عنوان مثال، اگر پردازش دادهها به پروژههای مختلف تقسیم شود، شما میتوانید تمام هزینههای پرس و جو، ثبت پرس و جو، و ثبت دسترسی به داده مربوط به تبدیل دادهها و مصرف را به طور جداگانه مشاهده کنید.
اجازه مشاهده دادهها نیز میتواند در سطح سلسله مراتبی تنظیم شود. با این حال، بسیار توصیه میشود که این مجوز را در سطح پروژه یا منبع (مجموعه داده و جدول) تنظیم کنید. قاعده کلی این است که اگر یک نقش باید به تمام دادهها در یک پروژه دسترسی داشته باشد، آن را در سطح پروژه اعطا کنید. اگر نیاز به محدود کردن دسترسی به یک مجموعه داده یا جدول خاص دارید، اجازه در سطح منبع را بدهید.
بیگ کواری همچنین توانایی ایجاد سطح ردیف و امنیت در سطح ستون را دارد تا حتی امکان کنترل دسترسی دانهریزتری را فراهم کند. این موضوع عنوان خوبی برای یک پست دیگر خواهد بود.
کمترین امتیاز
در شرایط غیر رسمی، حداقل خصوصیسازی به معنای دادن کمترین میزان مجوز مورد نیاز برای انجام یک وظیفه است. این اصل به ایجاد تفکیک وظایف برای نهادها (کاربران، گروهها، حسابهای خدمات) و منابع GCP کمک میکند. حداقل خصوصیسازی روش پیشنهادی برای امنیت در بسیاری از سیستمها است.
به عنوان مثال، وظیفه تحلیلگر داده پرس و جو و جمعآوری دادههای تبدیلشده است. برای این نقش، باید به او دسترسی فقط خواندن به دادههای تبدیلشده داده شود تا کار خود را انجام دهد. دسترسی نوشتن میتواند به این معنی باشد که یکپارچگی داده میتواند در معرض خطر باشد. تحلیلگر داده در این مثال میتواند به اشتباه دادههای تولید را حذف یا تغییر دهد. به طور مشابه، تحلیلگر دادههای عملیاتی تنها نیاز به دسترسی به دادههای عملیاتی و نه دادههای کامل مالی یا مشتری دارد.
دسترسی کامل به یک پروژه (اجازه مولف یا سردبیر) برای همه اغلب یک اشتباه است. به طور پیشفرض، Google Cloud یک حساب خدمات محاسباتی با اجازه ویرایشگر ایجاد میکند تا API محاسباتی را در یک پروژه ممکن سازد. این حساب بسیار آسان است و میتواند یک تهدید امنیتی بالقوه باشد. بهترین کار این است که ساخت خودکار این حساب را از کار انداخته و یا بعد از آن آن را حذف کنید.
حساب سرویس کاربر برای سرویسها.
دو نوع احراز هویت اصلی وجود دارد که میتوانید در Google Cloud از آنها استفاده کنید: حساب کاربر و حساب سرویس. حساب کاربر، حساب گوگل است که برای ورود به کنسول از آن استفاده میکنید. از سوی دیگر، حساب سرویس یک فایل کلیدی Json است که میتوانید از آن برای احراز هویت خدمات استفاده کنید.
تفاوت بین دو روش احراز هویت این است که چه کسی اقدام میکند. برای حساب کاربری، کاربر نام کاربری / رمز عبور خود را وارد میکند و اقدامات را انجام میدهد. برای حساب سرویس، آن یک سرویس (یک شغل ETL، یک ابزار تجسم، یک ابزار کاتالوگ ابرداده) است که عمل را انجام میدهد.
یک اشتباه رایج در اینجا استفاده از یک حساب کاربری برای احراز هویت خدمات است. انجام این کار به مشکلات سهمیهبندی تبدیل خواهد شد و کنترل دسترسی و گزارشهای حسابرسی را سختتر خواهد کرد.
اشتباه رایج دیگر استفاده از حساب سرویس برای هر سرویس است. همچنین این یک روش توصیه شده نیست زیرا نمیدانید چه سرویسهایی چه اقداماتی را انجام میدهند. علاوه بر این، از آنجایی که این حساب برای تمام سرویسها استفاده میشود، مجاز خواهد بود و احتمال نقض آن را افزایش خواهد داد.
اجازه دسترسی به گروهها به جای حسابهای شخصی
دلیل اصلی انجام این کار داشتن کنترل بهتر بر مجوزهای IAM در یک پروژه است. تصور کنید اگر شما ده نفر را دارید که نیاز به دسترسی به دادهها در یک پروژه + پنج حساب سرویس مختلف دارند، نظارت بر این که چه کسی به چیزی دسترسی دارد که میتواند به سرعت از دست برود.
با این حال، تعداد نقشها به طور قابلتوجهی (یا، در بدترین حالت، برابر) کمتر از تعداد افراد خواهد بود. بنابراین، یک رویکرد بهتر، ایجاد یک گروه متفاوت براساس نقشها و اضافه کردن مجوز مطابق با آن برای وضوح بیشتر است.
همچنین میتوانید یک گروه را به عنوان عضوی از گروه دیگر برای یک لایه کنترل اضافی اضافه کنید. به عنوان مثال، شما میتوانید یک گروه تحلیلگر داده داشته باشید. داخل آن گروه، شما میتوانید یک گروه تحلیلگر بازاریابی، یک گروه تحلیلگر عملیاتی و غیره داشته باشید.
استفاده از زیرساخت به عنوان کد (IaC)
استفاده از IaC شما را قادر میسازد تا به راحتی محیطهای مختلفی ایجاد کنید، به خصوص زمانی که پروژه شما پیچیده است و قطعات متحرک زیادی دارد. در یک پروژه بزرگ، میتوانید محیطهایی با سطوح دسترسی و سیاستهای پیچیده داشته باشید. نوشتن کد برای یک محیط یکبار و ارائه یک چیز مشابه برای مرحله اجرا و توسعه محیط میتواند در وقت شما صرفهجویی کند.
با IaC، هر تغییری در محیط شما متنوع است، بنابراین میدانید چه کسی چه تغییراتی را ایجاد میکند (با توجه به این که شما اجازه مدیریت را تنها به سرویس IaC خود محدود میکنید). همچنین میتوانید به صورت دورهای محیط خود را برای تفاوتهای بین پیکربندیها و محیطهای واقعی اسکن کنید. سپس بیشتر سرویسهای IaC محیط شما را به پیکربندیها برمیگردانند اگر هر گونه تغییر را تشخیص دهند.
منابع
یکی از بهترین راههای اعمال امنیت، جداسازی منابع است. این به معنای ایجاد پروژههای مختلف برای دادههایی است که نمیخواهید در کنار یکدیگر ذخیره شوند.
یک مکان خوب برای شروع، جدا کردن منابع بین مصرف، پردازش، و دسترسی است تا اطمینان حاصل شود که دادهها تنها براساس نیاز در دسترس هستند. با این طراحی، شما میتوانید مصرف دادههای خام را قفل کرده و دادههای موجود در لایه دسترسی را کنترل کنید. یک مورد استفاده معمول، ماسک کردن یا درهم کردن اطلاعات قابلشناسایی شخصی (PII) قبل از افشای جداول به انبار دادهها است.
نتیجهگیری
در یک پلتفرم ابری مدرن، مانند Google Cloud، لایههای بسیاری برای محدود کردن دسترسی به دادهها وجود دارد. من در مورد استفاده از بهترین روشهای زیر بحث کردم تا مطمئن شوید که یک محیط داده ایمن دارید:
- اعطای دسترسی ریز در سطح منبع
- کمترین امتیاز
- حساب سرویس کاربر برای سرویسها.
- اجازه دسترسی به گروهها به جای حسابهای شخصی
- استفاده از زیرساخت به عنوان کد (IaC)
- جداسازی منابع
موفق باشید!
این متن با استفاده از ربات ترجمه مقاله علم داده ترجمه شده و به صورت محدود مورد بازبینی انسانی قرار گرفته است.در نتیجه میتواند دارای برخی اشکالات ترجمه باشد.
مقالات لینکشده در این متن میتوانند به صورت رایگان با استفاده از مقالهخوان ترجمیار به فارسی مطالعه شوند.
مطلبی دیگر از این انتشارات
چین به دنبال افراد بهبودیافته برای توسعه درمان موثر کروناویروس است
مطلبی دیگر از این انتشارات
دانشمندان به این نتیجه رسیدند که چگونه و چه زمانی خورشید ما خواهد مرد، و این به زودی حماسی خواهد شد.
مطلبی دیگر از این انتشارات
چارچوبی برای هدایت واقعیت افزوده در صنعت