موتور تصمیم با نقطه اعمال یکی نیست
Open Policy Agent یا OPA برای ارزیابی سیاست بر اساس ورودی و داده به کار می‌رود. سیاست‌ها با زبان Rego بیان می‌شوند و برنامه مصرف‌کننده نتیجه را در جریان کار خود به کار می‌گیرد. نکته کلیدی این است که نتیجه موتور سیاست، به‌خودی‌خود جای اجرای کنترل در برنامه یا درگاه را نمی‌گیرد.
این جداسازی می‌تواند قواعد مشترک را قابل بازبینی‌تر کند، اما قرارداد میان برنامه و موتور سیاست باید روشن باشد. برنامه چه اطلاعاتی می‌فرستد؟ کدام داده قابل اعتماد است؟ پاسخ مورد انتظار یک مقدار بولی است یا ساختاری شامل جزئیات؟ رفتار در برابر پاسخ ناقص باید از قبل تعریف شود.
نشان همراه مقاله از همان وب‌سایت رسمی OPA گرفته شده است؛ این تصویر، نمودار یک استقرار مشخص یا گواهی تأیید پیکربندی نیست.
یک مثال فرضی برای مجوز گزارش‌ها
فرض کنید کاربر می‌خواهد گزارش یک پروژه را بخواند. ورودی سیاست می‌تواند هویت تأییدشده کاربر، پروژه هدف و عملیات درخواستی را شامل شود. اما شناسه هویتی که مستقیماً از بدنه درخواست نامطمئن می‌آید، نباید بدون اعتبارسنجی معادل هویت کاربر فرض شود.
برای شروع، جدولی از حالت‌ها بسازید: عضو پروژه می‌خواند، عضو پروژه دیگر رد می‌شود، کاربر بدون هویت رد می‌شود و کاربری با نقش خاص فقط عملیات تعریف‌شده را انجام می‌دهد. سپس همان جدول را به آزمون‌های خودکار تبدیل کنید. نتیجه مجاز و غیرمجاز هر دو لازم‌اند؛ تنها داشتن یک نمونه موفق کافی نیست.
شکست چگونه باید دیده شود؟
پیشنهاد تحریریه این است که «رد مجوز»، «نبود داده لازم» و «در دسترس نبودن موتور سیاست» در گزارش‌ها از هم جدا باشند. تصمیم درباره اجازه‌دادن یا ندادن در زمان خطا باید آگاهانه و متناسب با حساسیت عملیات باشد؛ یک پیش‌فرض پنهان ممکن است هنگام اختلال به دسترسی ناخواسته یا توقف خدمت منجر شود.
در محیط آزمایشی، پاسخ نامعتبر و قطع ارتباط را نیز امتحان کنید. از ثبت کل داده ورودی در لاگ عمومی پرهیز کنید؛ برای عیب‌یابی معمولاً شناسه درخواست، نسخه سیاست و نتیجه تصمیم مفیدتر از انتشار اطلاعات حساس کاربر است.
چرخه انتشار سیاست
سیاست را مانند بخشی از محصول منتشر کنید: بازبینی تغییر، آزمون سناریوها، انتشار محدود و مسیر بازگشت. نسخه سیاست و نسخه داده مرجع را ثبت کنید تا بعداً معلوم باشد یک تصمیم با چه زمینه‌ای گرفته شده است. جداکردن موتور تصمیم، مسئولیت طراحی قرارداد و کنترل ورودی را از بین نمی‌برد.
قرارداد ورودی را مانند یک API طراحی کنید
ورودی سیاست باید شکل مشخص و قابل آزمون داشته باشد. برای مثال، هویت تأییدشده، عمل درخواستی، شناسه منبع و ویژگی‌های زمینه را در بخش‌های جدا نگه دارید. نبودن یک فیلد نباید به صورت تصادفی همان معنای مقدار خالی یا مقدار عمومی را پیدا کند. اگر شناسه پروژه الزامی است، قبل از ارزیابی یا داخل قرارداد سیاست روشن کنید نبودن آن چه نتیجه‌ای دارد. این تصمیم به ویژه زمانی مهم است که چند برنامه با زبان‌ها و کتابخانه‌های مختلف از یک سیاست استفاده می‌کنند.
در نمونه گزارش، شناسه پروژه ممکن است هم در مسیر URL و هم در بدنه درخواست وجود داشته باشد. برنامه باید مشخص کند کدام مقدار مرجع است و آیا دو مقدار باید برابر باشند. اگر سیاست یک مقدار را بررسی کند ولی برنامه داده مربوط به مقدار دیگر را بخواند، نتیجه مجاز سیاست از عملیات واقعی محافظت نمی‌کند. این نوع اختلاف را با آزمونی بسنجید که دو شناسه متفاوت ارسال می‌کند. داشتن زبان سیاست قوی، ضعف قرارداد میان ارزیابی و اجرای عملیات را خودکار برطرف نمی‌کند.
داده مرجع و تازگی آن
سیاست ممکن است برای تصمیم به عضویت کاربر در پروژه یا فهرست نقش‌ها نیاز داشته باشد. این اطلاعات از کجا می‌آیند و چه مدت معتبرند؟ اگر داده به صورت بسته‌ای بارگیری می‌شود، زمان آخرین به‌روزرسانی را مشاهده‌پذیر کنید. اگر کاربری از پروژه حذف شود ولی نسخه قدیمی عضویت هنوز در موتور باشد، رفتار باید مطابق سیاست تازگی از قبل تعریف شده باشد. نیاز یک گزارش عمومی با عملیات تغییر دسترسی مدیر یکسان نیست و می‌تواند تحمل متفاوتی نسبت به داده قدیمی داشته باشد.
در آزمایش، ابتدا کاربر مجاز را در داده مرجع قرار دهید و تصمیم را ثبت کنید. سپس عضویت را حذف کنید و مدت زمان لازم تا تغییر تصمیم را اندازه بگیرید. این عدد را به عنوان نتیجه همان استقرار گزارش کنید، نه ویژگی ثابت OPA. مسیر توزیع داده، فاصله دریافت و روش کش برنامه بر نتیجه اثر دارند. اگر چند نمونه موتور دارید، بررسی کنید همه آنها نسخه یکسانی را دریافت کرده‌اند؛ عبور درخواست از نمونه‌های متفاوت نباید بدون توضیح، پاسخ متناقض بسازد.
نوشتن سیاست قابل بازبینی
نام قواعد باید معنای تصمیم را روشن کند. سیاستی که همه منطق را در یک عبارت طولانی پنهان کرده، هنگام تغییر سخت‌تر بررسی می‌شود. می‌توانید تشخیص عضویت، نوع عملیات و شرط مالکیت منبع را به بخش‌های قابل فهم تقسیم کنید. با این حال تعداد زیاد قواعد کوچک هم به تنهایی کیفیت نمی‌آورد؛ بازبین باید بتواند از ورودی مشخص به نتیجه برسد. برای هر قاعده مهم، یک مثال مجاز و یک مثال نزدیک ولی غیرمجاز نگه دارید تا مرز تصمیم روشن باشد.
از پیش‌فرض‌های ضمنی دوری کنید. اگر نتیجه مورد انتظار یک مقدار بولی است، برنامه نباید هر پاسخ غیرخالی را مجاز تلقی کند. پاسخ ساختاریافته، خطای ارزیابی و نبود نتیجه باید به شکل صریح پردازش شوند. یک آزمون عمداً پاسخ ناقص تولید کند و نشان دهد برنامه در آن حالت چه می‌کند. این موضوع به امنیت و پایداری هر دو مربوط است: باز گذاشتن مسیر در خطا ممکن است دسترسی ناخواسته بسازد و توقف همه عملیات در خطای کم‌اهمیت نیز می‌تواند خدمت را مختل کند.
آزمون واحد و آزمون یکپارچه
آزمون واحد سیاست باید ترکیب‌های معنی‌دار ورودی را پوشش دهد. برای مثال، کاربر عضو پروژه با عمل خواندن، همان کاربر با عمل حذف، کاربر پروژه دیگر و کاربر بدون هویت را جدا بسنجید. موارد مرزی مانند فهرست نقش خالی، نام منبع نامعتبر و نوع داده اشتباه نیز اهمیت دارند. همه ورودی‌های نامعتبر را صرفاً با یک نمونه خالی نمایندگی نکنید. ممکن است رشته و عدد در مسیرهای مختلف برنامه به شکل متفاوتی تبدیل شوند و همان تفاوت بر نتیجه اثر بگذارد.
آزمون یکپارچه نشان می‌دهد تصمیم واقعاً در نقطه درست اعمال می‌شود. در برنامه نمونه، یک درخواست ممنوع بفرستید و بررسی کنید داده حساس در پاسخ یا لاگ ظاهر نشده باشد. اگر برنامه ابتدا داده را می‌خواند و سپس تصمیم را می‌پرسد، باید آثار جانبی این ترتیب بررسی شود. همچنین مسیرهای جایگزین مانند دانلود فایل، خروجی گروهی و عملیات پس‌زمینه را فراموش نکنید. کنترل روی یک endpoint به معنی پوشش همه راه‌های دسترسی به همان منبع نیست.
استقرار محلی یا سرویس مشترک
استقرار موتور نزدیک برنامه می‌تواند وابستگی شبکه برای هر تصمیم را کاهش دهد، ولی توزیع سیاست و داده میان نمونه‌ها همچنان لازم است. یک سرویس مشترک مدیریت متمرکزتری دارد اما مسیر شبکه و ظرفیت آن در دسترس‌پذیری برنامه اثر می‌گذارد. انتخاب را بر اساس حساسیت تأخیر، تعداد تصمیم‌ها، حجم داده مرجع و مسئولیت تیم‌ها انجام دهید. نام الگوی استقرار به تنهایی پاسخ درست را تعیین نمی‌کند؛ باید رفتار هنگام قطع ارتباط و هنگام به‌روزرسانی سیاست را آزمایش کنید.
در هر دو الگو، دسترسی مدیریتی به بارگذاری سیاست را از دسترسی صرفاً ارزیابی جدا کنید. کسی که می‌تواند قاعده اجازه را عوض کند عملاً بر مجوزهای برنامه اثر دارد. بسته سیاست باید از مسیر قابل اعتماد بیاید و تغییر آن قابل ردیابی باشد. اگر محیط توسعه و تولید مشترک‌اند، یک آزمایش برنامه‌نویس نباید سیاست تولید را تغییر دهد. این مرز را با حساب‌ها، مسیر استقرار و بررسی عملی مجوزها روشن کنید، نه فقط با توافق شفاهی تیم.
مشاهده تصمیم بدون افشای اطلاعات
برای عیب‌یابی، شناسه درخواست، نتیجه تصمیم، نسخه سیاست و علت سطح بالای رد معمولاً مفیدند. ثبت کامل همه ویژگی‌های کاربر ممکن است اطلاعات شخصی یا داده محرمانه پروژه را منتشر کند. طرح لاگ را با نمونه‌های واقعی مرور کنید و فیلدهایی را که لازم نیستند حذف کنید. علت رد برای کاربر نیز نباید اطلاعاتی درباره وجود منبعی که اجازه دیدنش را ندارد آشکار کند. پیام داخلی تیم پشتیبانی می‌تواند با پیام عمومی پاسخ متفاوت باشد.
نرخ رد را همراه با نوع عملیات بررسی کنید. افزایش ناگهانی رد ممکن است ناشی از تغییر صحیح سیاست، داده مرجع قدیمی یا خطای قالب ورودی باشد. یک نمودار کلی بدون تفکیک این حالت‌ها می‌تواند تیم را به بازگرداندن یک کنترل درست ترغیب کند. هنگام تغییر سیاست، نمونه‌ای از تصمیم‌های قبلی را در محیط آزمایشی دوباره ارزیابی کنید و اختلاف‌ها را توضیح دهید. این مقایسه باید با داده پاک‌سازی‌شده انجام شود تا آرشیو آزمون به مخزن غیرضروری اطلاعات حساس تبدیل نشود.
تغییر سیاست و بازگشت کنترل‌شده
قبل از انتشار، مشخص کنید کدام گروه کاربران و کدام عملیات باید رفتار متفاوتی بگیرند. اگر هدف محدود کردن حذف گزارش است، تغییر نتیجه خواندن گزارش نیاز به توضیح دارد. انتشار محدود و مقایسه تصمیم‌ها می‌تواند اثر ناخواسته را آشکار کند، ولی تصمیم آزمایشی نباید بدون کنترل به عملیات واقعی تبدیل شود. نسخه قبلی سیاست و نسخه سازگار داده را نگه دارید؛ بازگرداندن فقط یکی از این دو ممکن است رفتار قبلی را بازسازی نکند.
در پایان، سند سیاست باید به زبان کسب‌وکار نیز قابل فهم باشد. جمله «اعضای پروژه می‌توانند گزارش همان پروژه را بخوانند» را به آزمون‌ها و قواعد مربوط وصل کنید. اگر استثنایی برای پشتیبانی وجود دارد، دامنه، علت و پایان اعتبارش را بنویسید. این پیوند میان قاعده فنی و نیاز واقعی باعث می‌شود بازبینی امنیتی به مرور نحو Rego محدود نماند. موفقیت زمانی است که تیم بتواند برای یک درخواست مشخص توضیح دهد چرا تصمیم گرفته شد و کدام جزء اجرای آن را تضمین کرد.
برای بررسی کیفیت قرارداد، از یک همکار بخواهید بدون دیدن کد سیاست، از روی توضیح کسب‌وکار نتیجه چند درخواست را پیش‌بینی کند. سپس پیش‌بینی او را با آزمون‌ها مقایسه کنید. اختلاف ممکن است نشانه ابهام نیاز باشد، نه خطای نحو. اگر اعضای تیم درباره معنای «مالک پروژه» توافق ندارند، افزودن قواعد بیشتر ابهام را حل نمی‌کند. ابتدا تعریف نقش، زمان اعتبار و منبع حقیقت را روشن کنید. پس از توافق، یک مثال مرزی تازه به مجموعه آزمون اضافه کنید تا همان اختلاف در تغییرهای آینده دوباره ایجاد نشود. این بازبینی کوچک به ویژه برای سیاست‌هایی مفید است که چند تیم مستقل از آنها استفاده می‌کنند.
