‏کنترل دسترسی سند‌به‌سند در Amazon Quick با ACL

سازمان‌هایی که داده‌های حساس دارن، با چالش بزرگی روبرو بودن: می‌خواستن از قابلیت‌های جستجو و چت هوش مصنوعی توی Amazon Quick استفاده کنن، ولی نمی‌تونستن مطمئن بشن که هر کاربری فقط به اسنادی که مجاز هست دسترسی داره. حالا با قابلیت Document-level ACL برای knowledge base‌های S3، این مشکل حل شده.

وقتی ACL فعاله، Quick هویت کاربر رو در زمان پرسش‌وجواب بررسی می‌کنه و فقط محتوایی رو برمی‌گردونه که کاربر مجاز به دیدنش هست. یه نکته مهم: رفتار پیش‌فرض deny هست؛ یعنی هر سند یا پوشه‌ای که توی تنظیمات ACL بهش اشاره نشده، به‌طور خودکار برای همه غیرقابل دسترسه. اگه هم یه کاربر هم‌زمان ALLOW و DENY داشته باشه، DENY اولویت داره.

دو روش برای پیکربندی ACL وجود داره. روش اول فایل مرکزی ACL.json هست که یه فایل واحد در ریشه باکت S3 قرار می‌گیره و دسترسی‌ها رو در سطح پوشه (prefix) تعریف می‌کنه؛ مناسب وقتی که ساختار دسترسی‌ها ثابته. روش دوم فایل‌های metadata هست که کنار هر سند یه فایل .metadata.json جداگانه قرار می‌گیره؛ مناسب وقتی که دسترسی‌ها زیاد تغییر می‌کنن، چون فقط اسناد تغییرکرده نیاز به reindex دارن نه کل پوشه.

نمونه‌ای از ساختار فایل metadata برای یک سند:

{
    "AccessControlList": [
        {
            "Name": "finance-team",
            "Type": "GROUP",
            "Access": "ALLOW"
        },
        {
            "Name": "contractor@example.com",
            "Type": "USER",
            "Access": "DENY"
        }
    ]
}

علاوه بر کنترل دسترسی به اسناد، می‌شه با IAM policy assignment توی Quick مشخص کرد که چه کسی اصلاً مجاز به ساختن knowledge base از روی یه باکت خاص هست. این یه لایه امنیتی مهمه؛ چون بدون این کنترل، یه کاربر می‌تونه روی همون باکت حساس یه knowledge base جدید بدون ACL بسازه و همه محدودیت‌ها رو دور بزنه.

Quick Flows هم از ACL پشتیبانی می‌کنه؛ یعنی می‌شه workflow‌های اتوماتیک ساخت که در زمان اجرا هویت کاربر رو بررسی می‌کنن و خروجی رو فقط از اسنادی که کاربر مجاز به دیدنشه تولید می‌کنن. برای مثال می‌شه یه Flow برای تولید خلاصه اجرایی ساخت که اگه کاربر به هیچ سند داخلی دسترسی نداشت، به‌طور خودکار جستجوی وب رو به‌عنوان fallback اجرا کنه.

چند نکته مهم قبل از فعال‌سازی: ACL بعد از فعال شدن قابل غیرفعال کردن نیست و باید knowledge base جدید ساخت. تطابق هویت کاربران بر اساس ایمیل انجام می‌شه و باید دقیقاً با آدرس ایمیل ثبت‌شده توی Quick مطابقت داشته باشه. تغییرات ACL بلافاصله اعمال نمی‌شن و باید sync دستی اجرا بشه. همچنین دسترسی write به فایل‌های ACL باید به مدیران محدود بشه، چون هر کسی که بتونه این فایل‌ها رو ویرایش کنه، می‌تونه به هر سندی دسترسی بده.

نکات کلیدی:

• Document-level ACL در Amazon Quick دسترسی به اسناد S3 رو در سطح فایل یا پوشه کنترل می‌کنه
• رفتار پیش‌فرض deny-by-default هست؛ هر چیزی که صریحاً ALLOW نشده، مسدوده
• دو روش پیکربندی: فایل مرکزی ACL.json برای ساختارهای ثابت، و metadata file برای تغییرات مکرر
• فعال‌سازی ACL یک‌طرفه‌ست و قابل برگشت نیست؛ حتماً اول روی محیط تست امتحان کن
• IAM policy assignment یه لایه کنترل اضافه برای محدود کردن ساخت knowledge base فراهم می‌کنه
• Quick Flows هم از ACL آگاهه و می‌تونه workflow‌های permission-aware بسازه