طراحی مدیریت کاربر برای تعاملات ماشین با ماشین

ماشین‌ها نیز کاربر هستند، و شما باید با آنها مانند کاربران رفتار کنید تا اطمینان حاصل کنید که سرویس‌هایی که استفاده می‌کنند در دسترس، سریع، مقیاس‌پذیر و ایمن هستند. در اینجا نحوه

اگر کاربری فاقد ویژگی‌های انسانی است و شخصیت چندانی ندارد، ممکن است دلیل خوبی برای این کار وجود داشته باشد. کاربر ممکن است یک ماشین باشد.

امروزه، بیش از ۹۰ درصد از ترافیک اینترنت بین ماشین‌ها است. در واقعیت، ماشین‌هایی که برنامه B2B SaaS شما را مصرف می‌کنند نیز کاربر هستند – فقط یک نوع کاربر متفاوت. به همین دلیل است که امروزه هر برنامه آنلاین و SaaS باید شامل شیوه‌ها و خط‌مشی‌های مدیریت کاربر کاملاً فکر شده باشد که به‌طور خاص برای رسیدگی به چالش‌ها و الزامات مختلف تعاملات ماشین به ماشین (M2M) طراحی شده‌اند.

بر اساس سال‌ها تجربه در کمک به شرکت‌های B2B SaaS در مدیریت تعاملات M2M، راهنمای سریعی با بهترین شیوه‌ها برای مدیریت کارآمد، مؤثر و ایمن کاربر ماشین به ماشین تهیه کرده‌ام. بیایید شیرجه بزنیم.

کاربران M2M و موارد استفاده آنها را بشناسید

متن ممکن است در مدیریت کاربر انسانی حیاتی باشد، اما برای ماشین‌ها حیاتی‌تر است، زیرا کاربران ماشین اطلاعات بسیار کمتری درباره وضعیت، موقعیت و هدف خود ارائه می‌دهند. اغلب کاربران ماشین فقط به یک سرویس یا تعداد کمی از خدمات دسترسی دارند، در حالی که کاربران انسانی به خدمات بسیاری دسترسی دارند.

تعامل‌های ماشین به ماشین سرنخ‌های مفیدی مانند عامل مرورگر، آدرس MAC یا NIC، یا داده‌های موقعیت جغرافیایی را به همراه ندارند. آنها به احتمال زیاد یک فراخوانی API در یک پروتکل معمولی با حداقل ویژگی های شناسایی هستند. زمینه پیرامون درخواست‌های سرویسی که کاربر ماشین ارائه می‌کند باید نحوه اعمال خط‌مشی‌ها و طراحی مدیریت کاربر را تعیین کند.

برای مدیریت کاربر M2M، هر سرویس باید بداند که چگونه می‌تواند با سرویس‌های دیگر ارتباط برقرار کند و با کدام سرویس‌ها ارتباط برقرار کند. همه سرویس‌ها باید بدانند که چگونه با سرویس دیگری ارتباط برقرار می‌کنند و سرویس‌های کلیدی که باید به آنها اجازه دسترسی داده شود. این تا حدی چیزی است که دروازه‌های API و مش‌های سرویس می‌توانند ارائه دهند، اما هیچ یک رویکرد کاربر محور (حتی برای کاربران M2M) ندارند.

امنیت بدون احراز هویت چند عاملی

امروزه برای کاربران انسانی، MFA بخش مهمی از فرآیند اعتبارسنجی امنیتی است. برای کاربران ماشین، MFA یک گزینه نیست. در عین حال، تراکنش‌های M2M تمایل دارند در میلی‌ثانیه عمل کنند، زیرا ماشین‌ها می‌توانند با سرعت بسیار بالاتری نسبت به انسان‌ها تعامل داشته باشند. این یک منطقه سطح حمله جدیدی ایجاد می کند که بسیاری از مجرمان سایبری اکنون به طور فعال سعی می کنند از طریق حملات API از آن سوء استفاده کنند. برای تیم‌های SecDevOps که فرآیندهای مدیریت کاربر را در برابر تعاملات M2M اجرا می‌کنند، این بدان معناست که باید به مکانیسم‌های امنیتی دیگر مانند محدود کردن آدرس IP، محدود کردن نرخ درخواست، گواهی یا چرخش کلید، و در حالت ایده‌آل، سیاست‌های تولید شده توسط انسان یا ماشین توجه بیشتری شود. که الگوهای استفاده غیرعادی را تشخیص می دهند.

کاربران داخلی ماشین در مقابل کاربران ماشین خارجی

خواه یک درخواست از یک ماشین داخلی باشد یا یک کاربر خارجی باید ملاحظات امنیتی بسیار متفاوتی را ایجاد کند. اگر یک درخواست داخلی باشد و از درون یک خوشه Kubernetes از یک سرویس به سرویس دیگر می‌آید، احراز هویت به صورت داخلی و معمولاً با لمس سبک‌تر اعمال می‌شود. به عنوان مثال، مش های سرویس برای تنظیم خط مشی هایی استفاده می شود که هر سرویس داخلی معینی می تواند با آنها ارتباط برقرار کند. در واقعیت، بسیاری از سازمان‌ها هنوز تعاملات داخلی ماشین با ماشین را احراز هویت نمی‌کنند، اما CISO و تیم‌های مدیریت ریسک به سختی تلاش می‌کنند تا احراز هویت پایه را در همه جا پیاده‌سازی کنند.

تا به امروز، بسیاری از عملیات‌های پلتفرم و تیم‌های SecDevOps از احراز هویت ساده‌لوحانه برای امنیت داخلی استفاده می‌کنند – یعنی اسرار مشترک. با این حال، احراز هویت ساده‌لوح نیازمند یک فرآیند قوی است تا به راحتی اسرار نقض شده یا افشا شده را جایگزین کند. بدون این فرآیند مبادله مخفی، یک سازمان در حالی که اسرار جدید ایجاد و به اشتراک گذاشته می شود، با خطر خرابی مواجه می شود. در مقیاس، تغییر در اسرار که باید بین جفت یا سه نفر از کاربران ماشین هماهنگ شود کار زیادی است. بنابراین حتی برای ارتباطات داخلی M2M، چالش‌های فناوری وجود دارد.

برای ارتباطات خارجی M2M و مدیریت کاربر ماشین، همه چیز بسیار پیچیده تر می شود. اشتراک مخفی امنیت ناکافی است. برای نشان دادن این موضوع به مثال زیر توجه کنید. فرض کنید ما دو سرویس داریم – یک سرویس کاربر و یک سرویس ایمیل. ما می خواهیم برای یک کاربر ایمیل ارسال کنیم. همه کاربران حق دریافت ایمیل را ندارند. بنابراین برای مدیریت صحیح کاربر، برنامه باید آگاه باشد که کدام کاربر حق ارسال ایمیل را دارد و کدام ایمیل باید برای پیام های ارسال شده به آن کاربر مشخص شود. اسرار به سرعت در این دنیا از بین می روند.

JWTs در مقابل توکن‌های دسترسی در مقابل اعتبار مشتری

این مورد استفاده همچنین نشان می‌دهد که چرا رمزهای وب M2M JSON (JWT) به خدمات ارتباطی عمومی M2M ترجیح داده می‌شوند. سپس سرویس مدیریت کاربر باید یک نشانه برای یک کاربر خاص یا یک سازمان خاص ایجاد کند. رمز را می توان باطل کرد یا تنظیم کرد که در فواصل زمانی معینی نیاز به تمدید داشته باشد.

یک خط‌مشی چرخه عمر رمز و سیستم عملیاتی به خوبی طراحی شده، سرویس‌های امنیتی و مدیریت کاربر را قادر می‌سازد تا دسترسی سریع را لغو کنند یا کلیدها را بدون وقفه عملیاتی بچرخانند. خط مشی به طور خودکار از طریق لیست های لغو یا تمدید گواهی اعمال می شود. اگر تمدیدها در جدول زمانی نسبتاً کوتاهی انجام می‌شوند، می‌توان مدیریت کاربر را طوری تنظیم کرد که نزدیک به Zero Trust برای کاربران M2M فراهم شود. JWT ها می توانند چندین ویژگی را حمل کنند، بنابراین برای کدگذاری زمینه مفید هستند.

راه دومی که سازمان‌ها احراز هویت خارجی را مدیریت می‌کنند، از طریق نشانه دسترسی است – جایی که کاربر یک رشته مقدار واحد را دریافت می‌کند. نحوه عملکرد یک نشانه دسترسی به این صورت است:

1. کاربر درخواستی را به سرور مجوز ارسال می‌کند و رمز سرویس گیرنده، شناسه مشتری، و خدمات و محدوده‌های درخواستی را ارسال می‌کند.
2. سرور مجوز درخواست را تأیید می کند و پاسخی را با یک نشانه دسترسی ارسال می کند.
3. کاربر برای درخواست منبع ایمن از نقطه پایانی سرویس (API) مربوطه، رمز دسترسی را اعمال می‌کند.

یک نشانه دسترسی برای تراکنش‌های ساده بسیار خوب است، اما می‌تواند در سناریوهای پیچیده‌تر خراب شود و یک نقطه شکست ایجاد کند. به عنوان مثال، اگر به دلایلی رمز دسترسی تأیید نشده باشد، هیچ راه حل آسان و مکانیسم دیگری برای رتبه‌بندی اعتماد وجود ندارد. اجرا بر روی یک معماری میکروسرویس، این به معنای جریان پیچیده‌تری است که مدیریت آن سخت‌تر است. یک کاربر ماشین نیاز به اعتبارسنجی فوری دارد که به یک سرور اعتبارسنجی جداگانه و مسیر خدمات ارسال شود. با JWT ها، تنها چیزی که سرویس باید بداند این است که آیا کاربر JWT معتبری دارد که تمام زمینه دسترسی را ذخیره می کند یا خیر. برای تأیید این مورد نیازی به اجرای یک فرآیند جداگانه نیست.

یک مسیر سوم، اعتبار مشتری است. اینها مجموعه ای از اطلاعات شناسایی ارائه شده توسط یک برنامه کاربردی هستند، مانند شناسه مشتری و راز، که برای احراز هویت برنامه و اجازه دسترسی به یک سرور منبع استفاده می شود. اعتبار مشتری اغلب دارای JWT است و از مزایای ایمن تر بودن برخوردار است زیرا به دو قطعه شناسایی نیاز دارد. و در حالی که اعتبار مشتری می‌تواند کمتر کاربرپسند باشد، اما زمانی که کاربر یک انسان نباشد، این مشکل کمتر است.

با این حال، با اعتبار مشتری، سیستم باید با دقت طراحی شود تا امکان کاهش سریع خرابی ها و کاهش تنگناها فراهم شود. زمانی که به سایر سیستم‌های توزیع‌شده مانند Google یا OAuth یا یک گواهی ابری شخص ثالث یا مجوز توکن متکی هستید، این می‌تواند چالش‌برانگیز باشد. در این سناریو، یک سازمان ممکن است به JWT که تولید یا کنترل نمی‌کند تکیه کند.

یک حد وسط بین اعتبار مشتری و کنترل‌های دسترسی ممکن است TLS متقابل (mTLS) باشد. mTLS تضمین می کند که طرفین در هر انتهای یک اتصال شبکه با تأیید اینکه هر دو دارای کلید خصوصی صحیح هستند، کسانی هستند که ادعا می کنند هستند. این لایه مکانیسم های اعتبار سنجی اعتماد اضافی را در نقطه دست دادن ایجاد می کند. برخی از مش‌های سرویس، پراکسی‌های معکوس و دروازه‌های API به‌طور پیش‌فرض mTLS را اعمال می‌کنند، اما همگام‌سازی mTLS در کل پشته زیرساخت شما نیاز به طراحی واقعی سیستم و تفکر دقیق دارد.

گام به سوی استراتژی

از آنجایی که تعداد سرویس‌ها و ریزسرویس‌ها همچنان در حال افزایش است و برنامه‌های کاربردی بیشتری در بالای APIها طراحی می‌شوند، توسعه یک استراتژی مدیریت کاربر قوی و تمرین برای تعاملات M2M حیاتی می‌شود. این به این معنی است:

• ایجاد نقشه‌های گردش کار از همه عناصر پشته مدیریت کاربر و همه سرویس‌ها.
• شناسایی سرویس‌هایی که احتمالاً توسط کاربران ماشین قابل دسترسی هستند و رتبه‌بندی آن‌ها بر اساس اهمیت، ارزیابی ریسک تجاری و امنیتی.
• تجزیه و تحلیل و تصمیم گیری برای اینکه کدام یک از سرویس های کاربر M2M شما به کدام نوع احراز هویت نیاز دارد.
• ایجاد یک پشته مدیریت کاربر یکپارچه که تمامی الزامات مدیریت کاربر، هم انسانی و هم M2M را برآورده می‌کند.

به یاد داشته باشید، ماشین‌ها نیز کاربر هستند. باید با آنها مانند کاربران رفتار کنید تا مطمئن شوید خدماتی که استفاده می‌کنند در دسترس، سریع، مقیاس‌پذیر و ایمن هستند.

Aviad Mizrachi CTO و یکی از بنیانگذاران Frontegg.

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.