کرسر در ۲ سپتامبر قابلیت تازهای ارائه کرد که اجرای ابزارهای عاملهای برنامهنویسی را به لپتاپ، ماشین مجازی، خوشه یا زیرساخت ایزولهای منتقل میکند که خود سازمان مدیریت میکند. این تغییر برای تیمهایی مهم است که مخزن کد، سامانه ساخت، خدمات داخلی یا سختافزار ویژهشان نباید در محیط اجرایی تحت مدیریت یک فروشنده بیرونی قرار بگیرد.
اما مرز این قابلیت محدودتر از چیزی است که عبارت «اجرای خودمیزبان» ممکن است القا کند. مستندات کرسر صریحاً میگوید چرخه تصمیمگیری عامل، پردازش مدل و برنامهریزی همچنان در زیرساخت ابری کرسر انجام میشود. ماشین سازمان فایلها را تغییر میدهد، فرمانها را اجرا میکند، مرورگر را کنترل میکند و به سرویسهای محلی MCP دسترسی دارد. بنابراین برای تیم امنیت یا حاکمیت، سؤال اصلی فقط این نیست که عامل کجا اجرا میشود؛ باید روشن باشد هر بخش از سامانه عامل در کدام محیط قرار دارد.
ماشین اجرایی منتقل میشود، نه چرخه تصمیمگیری
ماشین تحت مدیریت سازمان یک اتصال خروجی HTTPS به کرسر برقرار میکند و درخواست اجرای ابزار را دریافت میکند. کرسر پردازش مدل و برنامهریزی را انجام میدهد، عملیات لازم را برای اجرا به آن ماشین میفرستد و نتیجه را برای مرحله بعدی دریافت میکند. طبق مستندات شرکت، کرسر برای این کار از بیرون اتصال ورودی به شبکه مشتری برقرار نمیکند.
این تفکیک به سازمان امکان میدهد ماشین اجرای عملیات را مستقیماً کنترل کند. تیم میتواند سیستمعامل مورد نیاز خود را انتخاب کند، ابزارهای داخلی ساخت را نصب کند، از پردازندههای گرافیکی یا رایانههای مک استفاده کند و ماشین را در همان شبکهای قرار دهد که خدمات غیرقابل دسترس از اینترنت در آن قرار دارند. کرسر هم ماشین شخصی و هم مجموعههای اشتراکی برای تیمها را پشتیبانی میکند.
این معماری با یک سامانه برنامهنویسی هوشمند کاملاً خودمیزبان تفاوت دارد. محیطی که مخزن را نگه میدارد و فرمانها را اجرا میکند در اختیار مشتری است، اما هماهنگی عامل و پردازش مدل همچنان سرویس کرسر باقی میماند.
اجرای داخلی به معنی محلی ماندن همه دادهها نیست
مستندات کرسر درباره مرز شبکه شفاف است. نسخه کامل مخزن، حافظه میانی فرایند ساخت و اطلاعات احراز هویت ذخیرهشده روی ماشین در همان محیط میمانند، اما ماشین محتوایی را که جلسه عامل به آن نیاز دارد برای کرسر میفرستد. نمونههایی که خود شرکت نام میبرد شامل محتوای فایل، خروجی پایانه، تفاوت نسخهها، تصویر صفحه، نتیجه ابزارهای محلی MCP و اطلاعات مسیریابی است.
برخی خروجیهای عامل نیز میتوانند در فضای ذخیرهسازی تحت مدیریت کرسر بارگذاری شوند تا در درخواستهای ادغام کد یا صفحه مدیریتی دیده شوند. کرسر میگوید با فعال بودن حالت حریم خصوصی، کدی که از ماشین ارسال میشود برای آموزش مدل توسط کرسر یا ارائهدهندگان مدل استفاده نمیشود. اما «استفاده نشدن برای آموزش» با «خارج نشدن داده از شبکه سازمان» یکسان نیست.
این تفاوت در بررسی معماری مهم است. سازمان میتواند نسخه کامل مخزن و اسرار دسترسی را روی ماشینهای داخلی نگه دارد، در حالی که بخشهایی از کد و خروجی ابزارها برای پردازش به یک سرویس بیرونی ارسال میشود. پس اجرای خودمیزبان بهخودیخود به معنی پردازش کاملاً محلی یا تضمین کامل محل نگهداری داده نیست.
مزیت اصلی، دسترسی عامل به زیرساخت خصوصی است
این قابلیت زمانی بیشترین ارزش را دارد که عملیات عامل باید کنار زیرساخت موجود شرکت انجام شود. ماشین میتواند به مخزن خصوصی، بستههای نرمافزاری داخلی، فرایندهای ساخت، خدمات محلی و سختافزار تخصصی دسترسی داشته باشد، بدون اینکه لازم باشد آن زیرساختها به محیط اجرایی کرسر منتقل شوند.
کرسر همچنین مجموعههایی از ماشینهای اجرایی را پشتیبانی میکند که بر اساس صف درخواستها ظرفیتشان افزایش یا کاهش مییابد و میتوانند به چند مخزن خدمت دهند. مستندات شرکت از امکان استفاده از چند ارائهدهنده زیرساخت ایزوله و همچنین کنترل رایانه روی لینوکس و مک خبر میدهد. در نتیجه این قابلیت فقط یک رایانه راه دور برای یک توسعهدهنده نیست؛ میتواند در سکوی مهندسی موجود سازمان جا بگیرد.
برای تیم پلتفرم، گزینه معماری روشن است: محیط اجرای عملیات زیر کنترلهای فعلی زیرساخت باقی میماند، در حالی که کرسر چرخه تصمیمگیری عامل را ارائه میکند.
بررسی امنیتی باید دو مرز جداگانه را بسنجد
پیام عملی این معماری آن است که تیم امنیت باید دو مرز را جدا از هم ارزیابی کند.
مرز نخست، اجرای عملیات است: فرمانها کجا اجرا میشوند، نسخه کاری مخزن کجا قرار دارد، ماشین به کدام خدمات داخلی دسترسی دارد، چه اطلاعات احراز هویتی روی آن موجود است و جداسازی و بهروزرسانی ماشینها چگونه انجام میشود.
مرز دوم، پردازش اطلاعات است: کدام بخش از فایلها، خروجی فرمانها، تصاویر صفحه، نتایج MCP، متن جلسات و سایر خروجیها برای کرسر ارسال یا بیرون از ماشین ذخیره میشوند. پاسخ این پرسش تعیین میکند که آیا این معماری با الزامات محرمانگی، نگهداری داده یا مقررات یک سازمان سازگار است یا نه.
اگر هر دو موضوع زیر عنوان کلی «خودمیزبان» یکی فرض شوند، ممکن است تصور نادرستی از میزان کنترل ایجاد شود. این قابلیت میتواند دسترسی مستقیم زیرساخت و اطلاعات احراز هویت را محدودتر کند، اما همچنان یک مسیر خروجی داده دارد که باید صریحاً تحت سیاست قرار بگیرد.
برای استفاده در مخازن حساس، یک معیار ورود مناسب این است که پیش از فعالسازی، هر دو مرز در نمودار جریان داده و مدل تهدید ثبت شوند. سپس تیم میتواند مشخص کند کدام مخازن مجازند، ارتباط خروجی با چه مقصدهایی پذیرفته است، خروجی ابزارها چه اطلاعاتی میتواند داشته باشد، آیا بارگذاری خروجیها باید غیرفعال شود و چه قواعد قراردادی یا زمانی برای نگهداری اطلاعات لازم است.
کنترل بیشتر، مسئولیت عملیاتی بیشتری هم میآورد
کرسر برای بیشتر تیمها سرویس ابری تحت مدیریت خودش را پیشنهاد میکند و در مستندات یادآور میشود که در حالت اجرای خودمیزبان، مسئولیت تصویر نرمافزاری ماشین، زیرساخت، اطلاعات دسترسی، سیاست مقیاسپذیری و اعتبارسنجی عملیاتی بر عهده مشتری است. هزینه و نگهداری ماشینهای اجرا نیز در کنار هزینه استفاده از مدل به سازمان منتقل میشود.
این مبادله برای سازمانی که به شبکه خصوصی، سختافزار ویژه یا کنترل بیشتر بر محیط اجرای عملیات نیاز دارد منطقی است. اگر جداسازی محیط تحت مدیریت کرسر و اتصال خصوصی موجود از قبل نیازهای سازمان را پوشش دهد، مزیت آن کمتر میشود.
جمعبندی معماری دقیق است: کرسر محل انجام عملیات عامل را به زیرساخت تحت کنترل مشتری منتقل کرده، اما تصمیمگیری و پردازش مدل را منتقل نکرده است. در استقرار سازمانی، این تفکیک باید در مدل تهدید، نقشه جریان داده، بررسی خرید و معیارهای ورود به محیط عملیاتی بهروشنی دیده شود.