در عصر تکثیر گسترده دادهها، ساخت یک معماری Data Lakehouse مستحکم دیگر تنها درباره ظرفیت ذخیرهسازی نیست؛ بلکه اساساً درباره حاکمیت و امنیت است. با پذیرش Apache Iceberg توسط سازمانها به دلیل قابلیتهای فرمت جدول با عملکرد بالا، آنها اغلب با یک چالش حیاتی مواجه میشوند: چگونه مرزهای امنیتی چندمستأجری سختگیرانه را بدون قربانی کردن انعطافپذیری کوئری اعمال کنند.
در حالی که Iceberg استانداردهای جدول باز عالی را ارائه میدهد، اما به طور بومی کنترل دسترسی را در سطح فایل یا ردیف برای نیازهای پیچیده سازمانی مدیریت نمیکند. اینجاست که Apache Ranger وارد عمل میشود. با یکپارچهسازی Ranger به عنوان مدیر سیاست امنیتی مرکزی، میتوانید الگوهای امنیتی سطح ستون و سطح ردیفی را پیادهسازی کنید که برای محیطهای چندمستأجری ضروری هستند. این پست به بررسی نحوه معماری این یکپارچهسازی به طور موثر میپردازد.
چرا Ranger و Iceberg؟ شکاف امنیتی
Apache Iceberg در تراکنشهای ACID و کوئریهای سفر در زمان عالی عمل میکند، اما برای کنترل دسترسی به سیستمهای ذخیرهسازی زیرین (مانند HDFS، S3 یا Azure Blob) متکی است. در یک سناریوی چندمستأجری، مستأجر A نباید به طور تصادفی (یا مخرب) به دادههای PII حساس مستأجر B دسترسی پیدا کند. مجوزهای POSIX استاندارد در S3 یا HDFS اغلب بسیار کلی هستند. Ranger این خلأ را با ارائه یک رابط مدیریتی یکپارچه برای تعریف سیاستهایی پر میکند که توسط سرویسهایی مانند HiveServer2، Presto یا Trino هنگام کوئری جداول Iceberg اعمال میشوند.
معماری لایه سیاست
هسته این پیادهسازی شامل تعریف سیاستهایی است که به منابع خاصی در دریاچه داده شما نگاشت میشوند. در Ranger، یک منبع معمولاً نماینده یک پایگاه داده یا جدول در Hive Metastore (که متادیتای Iceberg را مدیریت میکند) است. برای ایمنسازی چندمستأجری، منابع خود را به صورت سلسلهمراتبی ساختاردهی میکنیم.
سناریویی را در نظر بگیرید که در آن چندین مستأجر یک طرحواره Iceberg واحد را به اشتراک میگذارند. میتوانید سیاستهای Ranger را ایجاد کنید که دسترسی را بر اساس شناسههای مستأجر تعبیه شده در متادیتای جدول یا ساختارهای پارتیشن فیلتر میکنند. در زیر یک مثال مفهومی از نحوه ساختاردهی یک سیاست در کنسول مدیریتی Ranger یا از طریق REST API آن، با تمرکز بر دید سطح ستون آورده شده است.
پیادهسازی امنیت سطح ستون
یکی از قدرتمندترین الگوها، پنهان کردن ستونهای حساس از کاربران یا نقشهای خاص است. به عنوان مثال، کارکنان منابع انسانی باید دادههای حقوق را ببینند، اما تحلیلگران بازاریابی نباید. در Ranger، این کار با اعطای دسترسی "SELECT" به تمام ستونها به جز موارد محدود شده انجام میشود.
// پیکربندی شبه برای سیاست Ranger
{
"policyName": "iceberg_hr_table_masking",
"resource": {
"db": "sales_data",
"table": "customer_pii"
},
"accesses": {
"column": "SELECT"
},
"columns": [
{"column": "customer_id", "access": "ALLOW"},
{"column": "email", "access": "DENY"}, // حساس
{"column": "ssn", "access": "DENY"}, // بسیار حساس
{"column": "region", "access": "ALLOW"}
],
"users": [
"marketing_analyst_group"
],
"options": {
"deny": true
}
}
در این پیکربندی، زمانی که کاربری در گروه marketing_analyst_group جدول Iceberg را از طریق یک موتور سازگار مانند Presto کوئری میکند، Ranger درخواست را مداخله میکند. آن به طور پویا کوئری را بازنویسی میکند یا دسترسی به ستونهای ممنوعه را مسدود میکند، اطمینان حاصل میشود که فایلهای Iceberg زیرین برای آن فیلدهای خاص هرگز خوانده نمیشوند.
پیشرفته: امنیت سطح ردیف با برچسبها
فراتر از ماسکزنی ستون، چندمستأجری اغلب نیاز به جداسازی سطح ردیف دارد. اگرچه موتور سیاست بومی Ranger مبتنی بر منبع است، اما میتوانید امنیت سطح ردیف را با ترکیب Ranger با طبقهبندی مبتنی بر برچسب به دست آورید. با برچسبگذاری ردیفها با شناسههای مستأجر و اعمال سیاستهایی که فقط به کاربران اجازه دسترسی به ردیفهایی را میدهد که با برچسب مستأجر آنها مطابقت دارند، میتوانید جداسازی واقعی را شبیهسازی کنید.
در غیر این صورت، اگر موتور کوئری شما از آن پشتیبانی میکند (مانند Presto با پلاگین Ranger)، میتوانید شرایط فیلتر را در طرح کوئری تزریق کنید. به عنوان مثال، یک سیاست میتواند به طور خودکار WHERE tenant_id = 'TENANT_123' را به هر کوئری که توسط کاربری متعلق به مستأجر 123 اجرا میشود اضافه کند، اطمینان حاصل میشود که آنها نمیتوانند دادههای سایر مستأجران را کوئری کنند، حتی اگر تلاش کنند فیلتر را حذف کنند.
بهترین شیوهها برای پیادهسازی
- مدیریت متادیتای سازگار: اطمینان حاصل کنید که Hive Metastore شما به درستی پیکربندی شده است تا جداول Iceberg را به عنوان جداول استاندارد برای کشف منابع Ranger در نظر بگیرد.
- آزمایش با دادههای غیرتولیدی: همیشه اعمال سیاست را در یک محیط پیشتولید قبل از اعمال بر بارهای کاری تولید اعتبارسنجی کنید.
- پایش لاگهای حسابرسی: لاگهای حسابرسی Ranger را برای ردگیری تخلفات سیاست و تلاشهای دسترسی فعال کنید، که لایه ضروری پایش انطباق را فراهم میکند.
نتیجهگیری
ایمنسازی یک دریاچه داده Apache Iceberg فقط محدود کردن دسترسی به فایلها نیست؛ بلکه یکپارچهسازی حاکمیت در لایه کوئری است. با بهرهگیری از موتور سیاست انعطافپذیر Apache Ranger، میتوانید الگوهای امنیتی چندمستأجری پیچیده را پیادهسازی کنید که دادههای حساس را محافظت میکنند در حالی که مزایای عملکرد بالای فرمت Iceberg را حفظ میکنند. با رشد دریاچه داده شما، اتخاذ این رویکرد ترکیبی اطمینان حاصل میکند که وضعیت امنیتی شما در کنار حجم دادههای شما مقیاسپذیر باشد.