دو مرحله شناسایی متفاوت
در SPIRE، سرور و عامل نقش‌های جدا دارند. عامل روی گره قرار می‌گیرد و به بارهای کاری واجد شرایط خدمت می‌دهد؛ سرور در مدیریت هویت و صدور اعتبارنامه نقش مرکزی دارد. احراز ویژگی‌های گره و احراز ویژگی‌های بار کاری، دو مرحله مرتبط اما مستقل‌اند.
نتیجه می‌تواند ارائه یک SVID، یعنی مدرک قابل اعتبارسنجی هویت SPIFFE، به بار کاری باشد. اعتماد به یک رشته نام کافی نیست؛ صادرکننده و زمینه اعتماد نیز باید معتبر باشند. نمودار همراه از صفحه رسمی مفاهیم SPIRE گرفته شده است.
این سازوکار را با مجوز نامحدود اشتباه نگیرید. پس از شناخت هویت یک سرویس، سامانه مقصد هنوز باید تصمیم بگیرد آن هویت اجازه کدام عملیات را دارد.
سناریوی فرضی سه سرویس
سه سرویس سفارش، پرداخت و گزارش را در نظر بگیرید. پیشنهاد تحریریه این است که پیش از نصب ابزار، هویت مورد انتظار و ارتباط‌های مجاز آن‌ها را بنویسید. سرویس گزارش نباید فقط به دلیل داشتن هویت معتبر بتواند عملیات ثبت پرداخت انجام دهد.
سپس ویژگی‌هایی را که بر اساس آن‌ها هویت به بار کاری داده می‌شود بررسی کنید. آیا کاربری با اختیار کم می‌تواند همان ویژگی‌ها را روی برنامه دیگری قرار دهد؟ هر انتخاب‌گر باید با مرز دسترسی واقعی سازگار باشد. یک برچسب قابل تغییر توسط همه، به‌تنهایی پایه مناسبی برای اعتماد حساس نیست.
صدور و تمدید را جدا آزمایش کنید
در محیط غیرعملیاتی، ابتدا دریافت اعتبارنامه و استفاده از آن را بسنجید. سپس وضعیت تمدید، راه‌اندازی مجدد عامل و در دسترس نبودن موقت صادرکننده را بررسی کنید. هدف، شناخت رفتار واقعی مصرف‌کننده هنگام تغییر یا پایان اعتبار است؛ نه فقط موفقیت اولین ارتباط.
آزمون منفی نیز بسازید: بار کاری نامرتبط نباید هویت سرویس پرداخت را دریافت کند. هویتی از حوزه اعتماد نامعتبر باید طبق طراحی رد شود. نتیجه این آزمون‌ها را به جای محتوای کلید خصوصی یا توکن، با شناسه آزمایش و وضعیت پذیرش ثبت کنید.
مرز نگه‌داری
سرور هویت، عامل‌ها، قواعد ثبت و مصرف‌کنندگان همه به مالک عملیاتی نیاز دارند. نسخه پشتیبان تنظیمات و روش جایگزینی گره را پیش از رخداد مشخص کنید. اعتبارنامه کوتاه‌عمر بخشی از طراحی است، اما خطای قواعد صدور یا دسترسی بیش از حد به مدیریت همچنان می‌تواند هویت اشتباه ایجاد کند.
پیشنهاد ما شروع با یک ارتباط محدود، آزمون شکست و گسترش تدریجی است. این مقاله یک مثال معماری است و نتیجه بررسی امنیت خوشه خاصی را گزارش نمی‌کند.
هویت بار کاری چه مشکلی را حل می‌کند؟
در یک سامانه چندسرویسی، دانستن نشانی IP برای تصمیم اعتماد کافی نیست. نشانی با جابه‌جایی pod یا ماشین عوض می‌شود و چند برنامه ممکن است از یک میزبان یا پراکسی عبور کنند. از طرف دیگر، توزیع یک رمز ثابت بین همه نمونه‌ها پاسخ به افشا را دشوار می‌کند. هویت بار کاری تلاش می‌کند برنامه را بر اساس شواهد محیط اجرا شناسایی کند و اعتبارنامه مناسب و قابل تمدید به آن بدهد. SPIRE پیاده‌سازی این ایده در چارچوب استاندارد SPIFFE است.
SPIFFE ID یک شناسه است، نه رمز و نه نشانی‌ای که الزاماً باید از شبکه باز شود. بخش trust domain محدوده اعتماد را مشخص می‌کند و مسیر هویت باید با سیاست سازمان سازگار باشد. بهتر است هویت به نقش پایدار بار کاری اشاره کند، نه شناسه تصادفی هر اجرای کوتاه. با این حال، دقت نام‌گذاری نباید از دقت شواهد بیشتر باشد؛ اگر دو برنامه از دید attestation قابل تفکیک نیستند، نام‌های متفاوت به تنهایی جداسازی واقعی ایجاد نمی‌کنند.
نقش server و agent
SPIRE Server ثبت هویت‌ها، شرایط صدور و کلیدهای مربوط به صدور را مدیریت می‌کند. Agent روی گره میزبان بار کاری قرار می‌گیرد و رابط محلی دریافت هویت را در دسترس می‌گذارد. ابتدا خود agent باید در فرایند node attestation شناخته شود. سپس هنگام درخواست برنامه، agent شواهد بار کاری را ارزیابی می‌کند. این دو مرحله دو پرسش جدا را پاسخ می‌دهند: این گره مجاز است و این فرایند روی آن گره با کدام هویت تطبیق دارد.
این معماری به معنی بی‌نیازی کامل از ریشه اعتماد نیست. برای شناسایی اولیه گره باید یک سازوکار قابل اتکا وجود داشته باشد؛ مثلاً شواهد محیط ابری یا روش bootstrap مناسب. اگر هر فرایند ناشناس بتواند خود را گره مورد اعتماد معرفی کند، صدور هویت ارزش حفاظتی ندارد. انتخاب plugin به محیط واقعی وابسته است. پیش از اجرا، بنویسید چه کسی می‌تواند شواهد آن plugin را ایجاد، تغییر یا جعل کند و این توانایی چه سطح دسترسی به هویت‌ها می‌دهد.
selectorها را به قرارداد امنیتی تبدیل کنید
Registration entry شرایطی را بیان می‌کند که برای صدور یک هویت لازم است. selectorها می‌توانند از اطلاعات محیط اجرا حاصل شوند، اما همه اطلاعات به یک اندازه قابل اعتماد نیستند. نامی که مالک برنامه آزادانه می‌تواند تغییر دهد، برای تمایز امنیتی با داده‌ای که کنترل‌پلین مورد اعتماد تأیید می‌کند یکسان نیست. باید مشخص شود کدام مدیر یا سرویس حق تغییر این ویژگی‌ها را دارد. در غیر این صورت، یک تغییر ساده برچسب می‌تواند ناخواسته به امکان گرفتن هویت حساس تبدیل شود.
یک مثال آموزشی، تفکیک سرویس گزارش و سرویس پرداخت روی یک گره است. برای هر کدام entry جدا بسازید و شرایطی انتخاب کنید که از دید agent واقعاً متفاوت باشند. سپس نشان دهید گزارش نمی‌تواند صرفاً با درخواست نام پرداخت، اعتبارنامه آن را بگیرد. اگر این آزمون شکست خورد، مشکل با کوتاه کردن عمر گواهی حل نمی‌شود؛ مرز شناسایی بار کاری ضعیف است. طراحی selector و کنترل تغییر آن باید هم‌زمان بررسی شوند.
Workload API و تحویل اعتبارنامه
برنامه از رابط محلی Workload API برای دریافت مواد هویتی و اطلاعات اعتماد استفاده می‌کند. حفاظت socket و نحوه نصب آن داخل محیط بار کاری مهم است. اشتراک بیش از حد socket یا قرار دادن آن در محیطی با فرایندهای نامطمئن می‌تواند دامنه دسترسی را بزرگ کند. تنها بررسی وجود فایل socket کافی نیست؛ باید معلوم باشد درخواست‌کننده چگونه به فرایند و شواهد واقعی آن نسبت داده می‌شود. مستندات integration مورد استفاده را با مدل namespace و دسترسی میزبان تطبیق دهید.
اعتبارنامه باید در برنامه یا پراکسی به شکل درست مصرف شود. گرفتن SVID و ذخیره آن در فایلی که هیچ‌گاه reload نمی‌شود، هدف تمدید خودکار را ناقص می‌کند. برنامه باید تغییر هویت و trust bundle را دریافت و در اتصال‌های تازه استفاده کند. برای آزمایش، عمر کوتاه در محیط آزمایشگاهی انتخاب کنید و چند چرخه تمدید را مشاهده کنید. فقط اولین اتصال سالم معیار کافی نیست؛ خطا اغلب زمانی ظاهر می‌شود که اعتبارنامه قبلی منقضی شده است.
X.509 و JWT را یکسان فرض نکنید
X.509-SVID برای سناریوهایی مانند اتصال احراز هویت‌شده مناسب است و به کلید خصوصی مربوط می‌شود. JWT-SVID کاربرد و نحوه ارائه متفاوتی دارد و مفهوم مخاطب در اعتبارسنجی آن اهمیت دارد. یک token صادرشده برای یک مصرف‌کننده نباید بدون بررسی مخاطب در جای دیگر پذیرفته شود. انتخاب نوع اعتبارنامه باید از نیاز پروتکل و مصرف‌کننده بیاید، نه صرفاً آسان‌تر بودن چاپ یا انتقال آن. همچنین قرار دادن token در log همانند افشای یک داده معمولی نیست.
در هر دو حالت، هویت تأییدشده هنوز باید به سیاست مجوز وصل شود. SPIRE به خودی خود تعیین نمی‌کند سرویس گزارش اجازه حذف سفارش دارد یا خیر. برنامه، پراکسی یا موتور سیاست باید درباره عمل و منبع تصمیم بگیرد. این جداسازی کمک می‌کند تغییر نام‌گذاری هویت، صدور اعتبارنامه و سیاست کسب‌وکار با هم قاطی نشوند. گزارش یک درخواست باید نشان دهد کدام هویت تشخیص داده شد و کدام سیاست نتیجه را تعیین کرد.
وابستگی به زمان و دسترس‌پذیری
هویت کوتاه‌عمر نیازمند ساعت درست و مسیر تمدید قابل اتکاست. اگر agent یا server موقتاً از دسترس خارج شود، رفتار بار کاری به اعتبارنامه موجود و نحوه مصرف آن وابسته است. نمی‌توان صرفاً گفت قطع server بلافاصله همه ارتباط‌ها را قطع می‌کند یا هیچ اثری ندارد. آزمایش باید مدت قطعی، عمر باقی‌مانده اعتبارنامه و رفتار ایجاد اتصال تازه را نشان دهد. این نتایج برای تعیین هشدار پیش از انقضا ارزش عملی دارند.
مخزن server، کلیدهای صدور و تنظیمات ثبت هویت نیز نیاز به حفاظت و بازیابی دارند. نسخه پشتیبان باید با طرح امنیتی و نقش مرجع صدور هماهنگ باشد. کپی کلید صدور به هر محیط آزمایشی، مرز اعتماد را بی‌دلیل گسترش می‌دهد. برای آزمایش از trust domain و کلید جدا استفاده کنید. اگر قرار است چند server داشته باشید، سازگاری datastore و سازوکار صدور را از معماری پشتیبانی‌شده انتخاب کنید؛ تکثیر صرف فرایند، دسترس‌پذیری درست ایجاد نمی‌کند.
اعتماد میان دامنه‌ها
Federation امکان شناخت هویت از trust domain دیگری را فراهم می‌کند، اما معادل دادن مجوز کامل به همه هویت‌های آن دامنه نیست. دریافت و به‌روزرسانی bundle باید از مسیر مورد اعتماد انجام شود و سیاست مصرف‌کننده همچنان شناسه‌های مجاز را محدود کند. یک تغییر در مرجع اعتماد دامنه بیرونی می‌تواند بر اعتبارسنجی شما اثر بگذارد. بنابراین مالک رابطه اعتماد، روش لغو و رفتار هنگام قطع endpoint مربوط باید از ابتدا مشخص باشند.
عیب‌یابی با تفکیک مراحل
اگر برنامه هیچ هویتی نمی‌گیرد، ابتدا دسترسی به Workload API و سپس نتیجه attestation را بررسی کنید. اگر agent به server وصل نمی‌شود، مشکل می‌تواند در bootstrap، گواهی، نام‌گشایی یا سیاست شبکه باشد. اگر هویت دریافت شده ولی اتصال سرویس رد می‌شود، trust bundle، استخراج شناسه و سیاست مجوز مقصد را مقایسه کنید. ثبت این مراحل به شما اجازه می‌دهد به جای تعویض تصادفی همه کلیدها، همان مرز خراب را اصلاح کنید.
یک آزمون پذیرش خوب شامل گره نامجاز، بار کاری با selector اشتباه، هویت معتبر با مجوز ناکافی و تمدید هنگام اجرای طولانی است. نتیجه هر کدام باید قابل توضیح باشد. هدف نهایی حذف همه پیچیدگی‌ها نیست؛ هدف جایگزین کردن رازهای پراکنده و دائمی با فرایند صدور، مصرف و لغو قابل مشاهده است. اگر تیم نتواند توضیح دهد چرا یک برنامه هویت خاص را گرفته، هنوز بخش مهمی از طراحی نیاز به اصلاح دارد.
