در چشم‌انداز در حال تحول سریع استقرار مدل‌های زبانی بزرگ (LLM) محلی، Open WebUI به عنوان رابطی اصلی برای تعامل با مدل‌های اجرا شده روی سخت‌افزار محلی ظهور کرده است. با این حال، با گذار سازمان‌ها از آزمایش‌های فردی به محیط‌های خوشه‌ای مشترک، امنیت و کنترل دسترسی به اهمیت حیاتی می‌رسند. این مقاله بررسی می‌کند که چگونه می‌توان کنترل دسترسی مبتنی بر نقش (RBAC) چند مستأجری (Multi-Tenant) را به‌طور محکم در Open WebUI پیاده‌سازی کرد تا اطمینان حاصل شود که خوشه‌های LLM محلی مشترک ایمن، کارآمد و مطابق با استانداردها باقی می‌مانند.
درک چالش چند مستأجری در خوشه‌های محلی
هنگام استقرار LLMها به صورت محلی، به ویژه در خوشه‌های پرمصرف منابع که از فناوری‌هایی مانند Ollama یا llama.cpp استفاده می‌کنند، اغلب چندین تیم یا کاربر به مدل‌های بک‌اند یکسان نیاز به دسترسی دارند. بدون جداسازی مناسب، این پیکربندی می‌تواند منجر به ریسک‌های امنیتی قابل توجهی شود، از جمله دسترسی غیرمجاز به داده‌ها، حملات تزریق پرامپت و رقابت بر سر منابع. چند مستأجری (Multi-tenancy) به گروه‌های متمایز (مستأجران) اجازه می‌دهد از زیرساخت یکسان بهره‌مند شوند، در حالی که جداسازی منطقی داده‌ها و مجوزها حفظ می‌شود.
Open WebUI، با وجود قدرت خود، به طور پیش‌فرض در پیکربندی‌های سازمانی پیچیده، مرزهای سختگیرانه مستأجری را به صورت بومی اعمال نمی‌کند. بنابراین، معماران باید پلتفرم و زیرساخت‌های اطراف آن را برای پشتیبانی مؤثر از RBAC پیکربندی کنند.
استراتژی معماری: جداسازی و مدیریت هویت
استراتژی اصلی شامل سه لایه است: احراز هویت هویت، تعریف نقش‌ها و سیاست‌های دسترسی به منابع.
- احراز هویت هویت: Open WebUI را با یک ارائه‌دهنده هویت (IdP) خارجی مانند LDAP، SAML یا OpenID Connect (OIDC) یکپارچه کنید. این کار اطمینان می‌بخشد که هویت کاربران به صورت متمرکز مدیریت و تأیید می‌شود.
- تعریف نقش‌ها: نقش‌های ظریف را در سازمان خود تعریف کنید. برای مثال:
- مدیر (Admin): دسترسی کامل به مدیریت مدل‌ها و مدیریت کاربران.
- توسعه‌دهنده (Developer): دسترسی به ایجاد و تست مدل‌ها، مشاهده لاگ‌ها.
- کاربر نهایی (End-User): دسترسی فقط به مدل‌های تأیید شده از پیش و تاریخچه چت.
- سیاست‌های دسترسی به منابع: نقش‌ها را به مدل‌های خاص یا گروه‌های مدل نگاشت کنید. این کار از دسترسی، برای مثال، یک کاربر نهایی عمومی به یک مدل فاین‌تیون شده داخلی حساس جلوگیری می‌کند.
پیاده‌سازی: پیکربندی Open WebUI با OIDC
در زیر یک مثال عملی از نحوه پیکربندی Open WebUI برای استفاده از یک IdP خارجی از طریق متغیرهای محیطی هنگام استقرار با Docker یا Kubernetes آورده شده است. این اولین گام در اعمال RBAC است، زیرا به IdP شما اجازه می‌دهد گروه‌ها و نقش‌های کاربر را در توکن JWT تزریق کند.
docker run -d -p 3000:8080 \
-v open-webui:/app/backend/data \
-e OPEN_WEBUI_AUTH_REGISTRATION=False \
-e OPEN_WEBUI_USE_OAUTH=True \
-e OPEN_WEBUI_OAUTH_CLIENT_ID="your-client-id" \
-e OPEN_WEBUI_OAUTH_CLIENT_SECRET="your-client-secret" \
-e OPEN_WEBUI_OAUTH_AUTHORIZATION_URL="https://idp.example.com/auth" \
-e OPEN_WEBUI_OAUTH_TOKEN_URL="https://idp.example.com/token" \
-e OPEN_WEBUI_OAUTH_USERINFO_URL="https://idp.example.com/userinfo" \
-e OPEN_WEBUI_ALLOWED_OAUTH_ROLES="admin,developer,user" \
open-webui/open-webui:main
در این پیکربندی، متغیر OPEN_WEBUI_ALLOWED_OAUTH_ROLES به عنوان دروازه‌بان عمل می‌کند. اگر توکن JWT ارائه شده توسط IdP حاوی یکی از نقش‌های فهرست شده نباشد، دسترسی رد می‌شود. این پایه و اساس RBAC است.
اعمال کنترل دسترسی در سطح مدل
پس از اینکه کاربران احراز هویت شدند و نقش‌ها به آن‌ها اختصاص داده شد، باید اطمینان حاصل کنید که آن‌ها فقط می‌توانند با مدل‌های مجاز تعامل کنند. Open WebUI امکان اسکریپت‌های سفارشی و گسترش‌های میانی‌افزار (middleware) را فراهم می‌کند. برای پیکربندی‌های پیشرفته، می‌توانید یک میانی‌افزار سفارشی در بک‌اند LLM خود (مثلاً یک پروکسی سفارشی Ollama) پیاده‌سازی کنید که قبل از ارائه پاسخ مدل، توکن JWT را بازرسی می‌کند.
در اینجا یک مثال شبه‌کد از یک بررسی میانی‌افزار در یک پروکسی مبتنی بر Python آورده شده است:
from functools import wraps
from fastapi import Depends, HTTPException
import jwt
def require_role(role: str):
def decorator(func):
@wraps(func)
def wrapper(*args, **kwargs):
token = get_current_token() # Extract from request header
try:
payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
if role not in payload.get("roles", []):
raise HTTPException(status_code=403, detail="Insufficient permissions")
except jwt.ExpiredSignatureError:
raise HTTPException(status_code=401, detail="Token expired")
except jwt.InvalidTokenError:
raise HTTPException(status_code=401, detail="Invalid token")
return func(*args, **kwargs)
return wrapper
return decorator
@app.get("/models/{model_id}/chat")
@require_role("developer")
async def chat(model_id: str):
# Only developers can access this specific model
return await llm_service.generate(model_id)
بهترین روش‌ها برای خوشه‌های مشترک ایمن
- ممیزی منظم: لاگ‌گیری را در Open WebUI فعال کنید و لاگ‌ها را به یک ابزار SIEM ارسال کنید. برای الگوهای دسترسی غیرعادی، مانند تلاش نقش "کاربر" برای دسترسی به یک نقطه پایانی "مدیر"، پایش انجام دهید.
- بخش‌بندی شبکه: نمونه Open WebUI و بک‌اند LLM را در بخش‌های شبکه جداگانه قرار دهید. از فایروال‌ها برای محدود کردن دسترسی مستقیم به API LLM استفاده کنید و اطمینان حاصل کنید که تمام ترافیک از طریق پروکسی Open WebUI عبور می‌کند، جایی که بررسی‌های RBAC انجام می‌شود.
- مدیریت رازها: از یک مدیر راز مانند HashiCorp Vault یا Kubernetes Secrets برای ذخیره کلیدهای API و رازهای JWT استفاده کنید. هرگز رازها را در فایل‌های پیکربندی به صورت سفت و سخت (hardcode) نکنید.
- اصل حداقل امتیاز: پایین‌ترین نقش ممکن را به هر کاربر اختصاص دهید. به طور منظم تخصیص نقش‌ها را بازبینی کنید تا دسترسی کارمندانی که نقش خود را تغییر داده‌اند یا از سازمان خارج شده‌اند را حذف کنید.
نتیجه‌گیری
پیاده‌سازی RBAC چند مستأجری در Open WebUI برای خوشه‌های LLM محلی مشترک برای استقرارهای سطح سازمانی ضروری است. با یکپارچه‌سازی با IdPهای خارجی، تعریف نقش‌های ظریف و اعمال کنترل‌های دسترسی در سطح مدل، می‌توانید یک محیط ایمن و مقیاس‌پذیر ایجاد کنید. این رویکرد نه تنها داده‌ها و مدل‌های حساس را محافظت می‌کند، بلکه همچنین با مقررات امنیتی داخلی و خارجی مطابقت دارد. با رشد پذیرش هوش مصنوعی محلی، سرمایه‌گذاری در مکانیزم‌های کنترل دسترسی محکم، یک تمایز کلیدی برای سازمان‌هایی خواهد بود که به دنبال بهره‌گیری ایمن و کارآمد از قدرت LLMها هستند.