مجوز با استفاده از کنترل دسترسی مبتنی بر نقش

کنترل دسترسی مبتنی بر نقش (RBAC) روشی برای کنترل دسترسی به سیستم بر اساس نقش هایی است که به کاربران در یک سازمان اختصاص داده شده است. RBAC در اطراف نقش های از پیش تعریف شده و امتیازات مرتبط با آن نقش ها (همچنین به عنوان الزام نقش شناخته می شود) تعریف شده است. نقش ها مجموعه ای از مجوزهاست که می توانید به یک منبع متصل شوید. این الزام آور اجازه می دهد تا امتیازات مرتبط با آن نقش بر روی آن منبع انجام شود. شما باید در زمانی که منبعی را به نقش متصل می کنید ، نقش را به یک مدیر اعطا کنید.

با استفاده از RBAC ، می توانید مدیریت کنید که چه کسی به منابع خاص بستر های نرم افزاری دسترسی دارد ، و اقداماتی که کاربر می تواند در آن منبع انجام دهد. RBAC سرویس ابرداده پلتفرم تلاقی را برای پیکربندی و مدیریت اجرای RBAC خود از یک زمینه پیکربندی متمرکز اعمال می کند ، از این طریق مدیریت دسترسی را در منابع پلت فرم تلاقی ساده می کند.

قبل از اجرای RBAC باید نیازهای امنیتی کاربران در سازمان خود را ارزیابی کنید و بر اساس منابعی که برای انجام وظایف خود نیاز دارند ، کاربران گروه را به نقش هایی که برآورده می شود ، گروه بندی کنید. برای نمونه ای از این کار برنامه ریزی به موارد استفاده از نقش RBAC مراجعه کنید. این بهترین روش برای محدود کردن کاربران به حداقل نقش لازم برای انجام وظایف اختصاص یافته خود است.

مانند ACL ، RBAC از اصولگرایان استفاده می کند ، بنابراین می توانید هر آنچه را که مشتری با یک نقش RBAC استفاده می کند ، مرتبط کنید ، که توسط مجوز سرور Confluent برای برقراری ارتباط با RBAC و ACL مجاز است. برای جزئیات بیشتر در مورد مجوز سرور Confluent ، به پیکربندی مجوز سرور Confluent مراجعه کنید. نقش های RBAC از قوانین انکار پشتیبانی نمی کند ، و هیچ تفاوتی در نحوه ایجاد و استفاده از ACL های مبتنی بر Legacy Zookeeper و در عین حال استفاده از RBAC وجود ندارد. با این حال ، اگر قصد استفاده از ACL را دارید ، توصیه می کنیم به ACL های متمرکز ، که اطلاعات ACL را در MDS ذخیره می کنند ، دقیقاً مانند اتصال نقش ، مهاجرت کنید. ACL های مبتنی بر میراث Zookeeper در این میان به کار خود ادامه خواهند داد.

مزایای RBAC ¶

• مدیریت دسترسی امنیتی را در سراسر سکوی تلاقی (Kafka ، KSQLDB ، Connect ، Registry Schema ، مرکز کنترل مخلوط) با استفاده از مجوزهای دانه ای برای کنترل دسترسی کاربر و گروه مدیریت کنید. به عنوان مثال ، با RBAC می توانید مجوزهای مربوط به هر کانکتور را در یک خوشه مشخص کنید ، و باعث می شود چندین اتصالات در حال اجرا و سریعتر آسانتر و سریعتر شوند.
• مدیریت مجوز را در مقیاس. مدیران می توانند به طور متمرکز تکلیف نقش های از پیش تعریف شده را مدیریت کنند ، و همچنین مسئولیت مدیریت دسترسی و مجوزها را به بخش های مختلف یا واحدهای تجاری که صاحبان واقعی هستند و بیشتر با آن منابع آشنا هستند ، واگذار می کنند.
• مدیریت تأیید اعتبار و مجوز برای خوشه های متعدد ، که شامل موارد زیر است: MDS ، یک خوشه کافکا ، اتصال ، KSQLDB ، خوشه های رجیستری طرحواره و یک نمونه واحد از مرکز کنترل تلاقی.

چگونه RBAC کار می کند

تکالیف نقش از پیش تعریف شده تعیین می کند که چه کسی می تواند به منابع خاص بستر تلاقی دسترسی داشته باشد ، و چه اقداماتی یک کاربر شخصی می تواند در آن منبع انجام دهد. یک سرپرست نقش های از پیش تعریف شده ای را در منابع مختلف به کاربران و گروه ها اختصاص می دهد. به هر کاربر می توان چندین نقش را در هر منبع اختصاص داد. برخی از کاربران ممتاز (مانند UserAdmin یا SystemAdmin) نقش هایی را به کاربران و گروه ها اختصاص می دهند ، و سپس منابع خاص را به آن نقش های کاربر ترسیم می کنند. به عنوان مثال ، یک منبع منابع مالی در بخش دارایی می تواند به اعضای بخش دسترسی به کلیه موضوعاتی که از پیشوند Financial_ استفاده می کنند ، اعطا کند و این باعث می شود مدیریت منابعی را که با آنها بیشتر آشنا هستند ، برای آنها آسانتر کند.

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

با استفاده از RBAC ، مدیر کاربر می تواند نقش هایی را برای کاربران LDAP و گروه هایی که به منابع خاص (نقش اتصال) اختصاص داده شده اند ، نقشه برداری کند. پس از تنظیم یک نقش با استفاده از فرمان Cli Cli Cli Confluent IAM RBAC CORE-BINDING COMEN ، کاربران نمی توانند برای دور زدن و دسترسی به منابع به یک مرکز کنترل API یا Confluent مراجعه کنند. نقش های اتصال به گروه ها ، مدیران مشتری را قادر می سازد تا از دسترسی صریح به هر کاربر در هر مؤلفه خودداری کنند. برای جزئیات بیشتر در مورد مشاهده پیوندهای نقش ، به دستور لیست لیست نقش اتصال نقش IAM RBAC CLI CLI مراجعه کنید. توجه داشته باشید که اتصال نقش از تطابق کارت وحشی به نام اصلی پشتیبانی نمی کند. برای جزئیات بیشتر ، به مدیران Wildcard مراجعه کنید.

هنگام تنظیم الزامات نقش (ایجاد نقش اتصال IAM RBAC) ، اگر نیاز به عیب یابی دارید ، ممکن است مشاهده سیاهههای حسابرسی در پرواز برای شناسایی رویدادهای مجوز برای اصول ، منابع یا عملیات خاص مفید باشد. برای جزئیات بیشتر ، به مشاهده سیاهههای مربوط به حسابرسی در پرواز مراجعه کنید.

رجیستری خوشه پلتفرم Clobuent راهی را برای مدیران خوشه فراهم می کند تا به طور مرکزی خوشه های کافکا را در سرویس ابرداده (MDS) ثبت کنند تا یک تجربه الزام آور نقش RBAC کاربر پسند تری داشته باشد. برای جزئیات بیشتر ، به رجیستری خوشه مراجعه کنید.

سرویس ابرداده پلتفرم مخلوط شده

MDS مکانیسم اصلی است که توسط آن RBAC اجرا می شود ، و یک زمینه پیکربندی متمرکز را ارائه می دهد که پس از تنظیم یک خوشه ، مدیران را از وظیفه پیچیده و وقت گیر تعیین و تعیین نقش برای هر منبع به صورت جداگانه نجات می دهد. پلت فرم مخلوط MDS پیکربندی خوشه ای Kafka را در منابع مختلف (مانند موضوعات ، اتصالات و طرحواره ها) متصل و اجرا می کند. سرویس ابرداده (MDS) به عنوان مقام اصلی برای کلیه داده های مجوز و احراز هویت عمل می کند. شما باید هر کارگزار Kafka را در خوشه MDS با MDS پیکربندی کنید.

MDS سهولت استفاده و راحتی را در اجرای کنترل دسترسی مبتنی بر نقش (RBAC) فراهم می کند. همچنین می تواند مقیاس کند تا بتوانید از همین مدل مجوزهای غیر الزام آور برای ارائه انواع دیگر امنیت استفاده کنید.

MDS که روی یک کارگزار Kafka اجرا می شود ، با LDAP یکپارچه شده است تا تأیید هویت و نشانه های حامل قابل تجدید برای جعل هویت را ارائه دهد. MDS همچنین استاد رکورد برای اتصال نقش است. برای جزئیات بیشتر در مورد پیکربندی یکپارچه سازی LDAP با RBAC ، به پیکربندی LDAP و پیکربندی احراز هویت LDAP مراجعه کنید. برای جزئیات بیشتر در مورد پیکربندی MDS ، به پیکربندی خدمات ابرداده (MDS) مراجعه کنید.

RBAC و ACLS¶

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

RBAC یک مکانیسم مجوز اضافی را اضافه می کند که هنگام استفاده از ACL به چالش های مجوز زیر می پردازد:

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

RBAC امکان ارائه دسترسی به منابع گرانول به منابع مرکز کنترل متناوب را فراهم می کند. قبل از RBAC ، هر کاربر با دسترسی به مرکز کنترل تلاقی دسترسی کامل یا فقط خواندنی به موضوعات و منابع داشت. اگر کنترل دسترسی دانه ای در مرکز کنترل مخلوط الزامی باشد ، RBAC توصیه می شود.

RBAC یک مکانیزم احراز هویت و مجوز مداوم را برای دسترسی کاربران در کل سکوی تلاقی فراهم می کند ، که فقط در صورت استفاده از ACL امکان پذیر نیست.

قبل از RBAC ، ایجاد و مدیریت ACL ها می تواند مدیریت و نگهداری آن دشوار باشد و در سازمان هایی با هزاران منبع و کاربر ، راه اندازی ACL می تواند مدت زمان زیادی طول بکشد. با RBAC ، مسئولیت منابع مختلف با استفاده از نقش منابع منابع مدیریت می شود.

به عنوان مثال ، می گویند شما مسئول مدیریت دسترسی کاربر به 1000 موضوع هستید. با استفاده از RBAC ، شما می توانید ResourceNer را به سایر کاربران اعطا کنید تا موضوعات متعلق به واحدهای تجاری خاص را مدیریت کنند و به نوبه خود ، این کاربران می توانند دسترسی دیگران را در تیم های خود مدیریت کنند. با استفاده از ACL در این سناریو ، شما باید به طور مرکزی دسترسی به همه موضوعات را مدیریت کنید ، که این یک کار زمان و منابع است.

گزینه های احراز هویت RBAC گزینه

گزینه های احراز هویت مورد استفاده قبل از اجرای RBAC ممکن است به پیکربندی اضافی نیاز داشته باشد ، یا ممکن است شما نیاز به استفاده از یک روش تأیید هویت متفاوت داشته باشید.

مؤلفه های بستر های نرم افزاری که دارای نقطه پایانی استراحت هستند (مانند رجیستری طرحواره و مرکز کنترل مخلوط) ، از استفاده اصلی حاصل از تأیید اعتبار MTLS هنگام استفاده از RBAC پشتیبانی نمی کنند. بنابراین اگر قبل از پیکربندی RBAC به تأیید اعتبار گواهی SSL در سراسر بستر های نرم افزاری متکی هستید ، هنگام استفاده از RBAC ، باید اعتبارنامه های اصلی HTTP (مانند کاربر LDAP) را نیز ارائه دهید تا در برابر سایر مؤلفه ها یا نقاط پایانی API را تأیید کنید.

HTTP Basic Auth اعتبار ورود به سایر مؤلفه های بستر های نرم افزاری را ارائه می دهد و این مؤلفه از آن اعتبارنامه ها برای دریافت نشانه OAuth برای کاربر با MDS استفاده می کند (که اعتبار آن را در برابر LDAP تأیید می کند) و سپس این مؤلفه از Token OAuth استفاده می کند تا درخواست های مجوز MDS را درخواست کندوادشما باید توکن حامل را برای تأیید هویت اصلی HTTP مشخص کنید و به طور خاص تر ، باید Basic. Auth. user. info و basic. auth. credentials. source را مشخص کنید.

هنگام پیکربندی اجزای پلتفرم Confluent (به عنوان مثال، Confluent Control Center، ksqlDB و REST Proxy) برای RBAC، از OAuth برای احراز هویت با خوشه‌های MDS و Kafka استفاده کنید. برای احراز هویت با سایر اجزای پلتفرم Confluent، از احراز هویت پایه HTTP استفاده کنید.

هنگام استفاده از RBAC با Schema Registry و Connect می توانید از هر یک از روش های احراز هویت پشتیبانی شده توسط Confluent Platform برای برقراری ارتباط با خوشه های کافکا و MDS استفاده کنید. برای احراز هویت با سایر اجزای پلتفرم Confluent، از احراز هویت پایه HTTP استفاده کنید.

هنگام استفاده از RBAC با کلاینت‌های کافکا، می‌توانید از هر یک از روش‌های احراز هویت پشتیبانی شده توسط پلتفرم Confluent به جز OAUTHBEARER استفاده کنید. برای جزئیات، به پیکربندی مشتریان کافکا مراجعه کنید.

گزینه های احراز هویت RBAC ¶

واژه شناسی¶

اصطلاحات زیر در RBAC استفاده می شود:

کنترل دسترسی دسترسی توانایی یک کاربر یا برنامه کاربردی برای انجام یک کار خاص است، مانند مشاهده، ایجاد یا تغییر یک منبع (مثلاً موضوعات). کنترل دسترسی دسترسی ایمن به خدمات و منابع پلتفرم Confluent را امکان پذیر می کند. Principal هویت کاربر یا نرم افزاری که درخواست مجوز برای انجام یک عمل خاص در یک منبع خاص دارد. اصول می توانند احراز هویت یا غیر احراز هویت (ناشناس). اصل کاربر یک هویت واحد که به یک کاربر یا نرم افزار خاص گره خورده است. گروه اصلی هویت مشترکی که فهرستی از اصول کاربر و/یا دیگر اصول گروه را گروه بندی می کند. نقش مجموعه ای از مجوزها که به مدیران اجازه می دهد تا عملیات خاصی را انجام دهند. منبع یک منبع می تواند یک موضوع Apache Kafka®، گروه مصرف کننده، شناسه تراکنش، کلاستر، ثبت طرحواره، ksqlDB، و هر مؤلفه Confluent Platform باشد. Role binding ترکیبی از اصل-نقش-منبع که به یک مدیر اجازه می دهد تا عملیاتی را بر روی یک منبع یا مجموعه ای از منابع که توسط نقش تعریف شده است انجام دهد. کنترل دسترسی مبتنی بر نقش (RBAC) با RBAC، مجوزها با نقش‌ها مرتبط می‌شوند و کاربران یا گروه‌ها به نقش‌های مناسب اختصاص می‌یابند. نقش ها بر اساس شایستگی شغلی، اختیارات و مسئولیت در شرکت تعریف می شوند. کاربران و گروه ها به راحتی از یک نقش به نقش دیگر اختصاص داده می شوند. مجوزهای اختصاص داده شده به نقش‌ها در مقایسه با تغییرات عضویت کاربر در نقش‌ها، نسبتاً آهسته تغییر می‌کنند.

محدودیت های RBAC¶

برای عملکرد بهینه پیکربندی RBAC، توصیه می‌کنیم این محدودیت‌ها را رعایت کنید.

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

کدهای خطای RBAC¶

کدهای خطای دسترسی کاربر HTTP زیر برای RBAC استفاده می شود:

در برخی موارد، زمانی که اعتبار کاربری صحیح است، اما کاربر مجوزهای صحیح را ندارد، هنگام جستجوی یک منبع ناموجود، انتظار خطای 404 را دارید. در چنین مواردی، کد خطای 403 برای جلوگیری از افشای جزئیات مربوط به منابع خاص بازگردانده می شود.

401 ورود کاربر به دلیل اعتبار از دست رفته یا ناکافی انجام نشد (کاربر فاقد مجوزهای کافی است). 403 اعتبار کاربر ممکن است صحیح باشد ، اما ورود به سیستم ناموفق بود زیرا کاربر مجوز برای یک منبع خاص (مانند رجیستری طرحواره یا اتصال) ندارد. 404 یافت نشد: کاربر دارای اعتبار صحیح و دسترسی به یک منبع است (به عنوان مثال ، کاربر نقش ResourceNower را دارد) ، اما منبع (مانند اتصال) وجود ندارد. 502 MDS غیرقابل دستیابی است. با مدیر امنیتی خود تماس بگیرید.

رجیستری طرحواره دارای بسیاری از کدهای خطای گرانول است که فراتر از متن RBAC است. برای توصیف خطاهای ثبت نام طرحواره HTTP (به عنوان مثال ، 40401) در اینجا پوشش داده نشده است.

چک لیست اجرای RBAC ¶

در این بخش یک چک لیست برای کمک به شما در برنامه ریزی اجرای RBAC ارائه شده است.

Ansible روشی ساده تر برای پیکربندی و استقرار RBAC و MDS ارائه می دهد. برای جزئیات بیشتر به تنظیمات RBAC Ansible مراجعه کنید.

platform پلت فرم تلاقی ، از جمله مؤلفه تجاری Confluent-Server را نصب کنید. برای اطلاعات بیشتر ، به پلت فرم مهاجرت Clonfuent به سرور Clonfuent مراجعه کنید.

☐ برای ارزیابی نیازهای کاربران در سازمان خود با تیم امنیتی خود کار کنید و بر اساس منابعی که برای انجام وظایف خود نیاز دارند ، مشخص کنید که کدام نقش ها باید به کاربران و گروه ها اختصاص یابد.

برای توصیف برخی موارد استفاده معمولی و نقش های مورد نیاز برای هر یک ، به موارد استفاده از نقش RBAC مراجعه کنید.

برای Bootstrap RBAC ، شما باید یک Super. user سطح ACL را در سرور کارگزار Kafka شناسایی کنید. پرونده های موجود در خوشه ای که میزبان MDS است. این سوپر. حتماً مشخص کنید که کدام کاربر به عنوان Super. user bootstrap خدمت خواهد کرد. برای جزئیات بیشتر ، به نقش های کنترل دسترسی مبتنی بر نقش از پیش تعریف شده مراجعه کنید.

MDS عملکرد اصلی RBAC را پیاده سازی کرده و با LDAP ارتباط برقرار می کند تا اطلاعات کاربر و گروهی را بدست آورد و کاربران را تأیید کند. پس از پیکربندی MDS ، می توانید با اتصال به نقش و پیکربندی سایر اجزای پلتفرم تلاقی ادامه دهید.

برای مشاهده پیکربندی LDAP برای MDS به پیکربندی ارائه دهنده هویت LDAP مراجعه کنید.

☐ پس از تعیین اینکه کدام نقش ها باید به کاربران و گروه ها اختصاص داده شود ، برای دسترسی به منابع (به عنوان مثال ، رجیستری طرحواره ، KSQLDB ، Connect و Controluent Control) که برای انجام وظایف خود نیاز دارند ، الزامات مناسبی را برای کاربران ایجاد کنید.

☐ نقش کاربر و گروهی را که تعریف کرده اید با استفاده از دستور لیست لیست نقش اتصال IAM RBAC تأیید کنید.

☐ برای برقراری ارتباط با MDS برای احراز هویت و مجوز ، اجزای پلتفرم تلاقی را پیکربندی کنید. برای جزئیات بیشتر ، به:

برای دیدن یک نمونه کار از کنترل دسترسی مبتنی بر نقش (RBAC) ، نسخه ی نمایشی پلتفرم Confluent را بررسی کنید. این آموزش نسخه ی نمایشی و همراه به کاربران نشان می دهد که چگونه می توانند یک برنامه پخش رویداد Apache Kafka® را مستقر کنند. تمام مؤلفه های نسخه ی نمایشی دارای امنیت هستند که از جمله RBAC از جمله RBAC استفاده می کنند.

Confluent Cloud یک سرویس کاملاً مدیریت شده Apache Kafka است که در هر سه ابر اصلی موجود است. امروز آن را رایگان امتحان کنید.

کپی رایت © Confluent ، Inc. 2014-. Apache ، Apache Kafka ، Kafka و نام پروژه های منبع باز مربوط به علائم تجاری بنیاد نرم افزار Apache هستند