امنیت در میکروسرویس‌ها - قسمت دوم

1. مقدمه:

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

2. امنیت مرزهای نرم‌افزار:

میکروسرویس‎ها هنگام انتشار معمولا بصورت مستقیم در معرض دید نرم‌افزار‏های مشتری و دنیای خارج قرار نمی‌گیرند. به طور معمول میکروسرویس‌‎ها از مجوعه‌ای از APIها تشکیل شده اند که به واسطه API Gatewayدر معرض دید جهان خارج قرار می‌گیرند، در عمل با استفاده از API Gateway که در ورودی میکروسرویس‎ها مستقر هستند، تمام پیغام‎های ورودی را غربالگری می‌شوند.

در تصویر 1، استقرار میکروسرویس‎هایی شبیه به میکروسرویس‌های نت‌فیلیکس نمایش داده شده است که ازAPI Gateway به نام Zull استفاده می‌کنند. Zuul امکاناتی نظیر آدرس‎دهی پویا، رصدکردن، انعطاف پذیری، امنیت و... را فراهم می کند. در اصل به‌عنوان دریچه ورودی زیرساخت سرور نت‌فیلیکس عمل کرده و ترافیک کاربران نت‌فیلیکس از سرتاسر جهان را مدیریت می‌کند. در این تصویر، Zuul برای به معرض گذاشتن برخی میکروسرویس‌ها بواسطه API استفاده شده است. باقی میکروسرویس‎‌های مستقر نیازی به معرض دید قرار گرفتن بواسطه‌‎ی API را ندارند، چرا که نیازی نیست توسط اپلیکیشن‎های بیرونی مورد استفاده قرار بگیرند. در یک استقرار معمول میکروسرویسی، مجموعه‎‌ای از میکروسرویس‎ها هستند که اپلیکیشن‌‎های بیرونی نیاز به دسترسی به آنها دارند، و مجموعه‏ای از میکروسرویس‌‎ها هستند که اپلیکیشن‎‌های بیرونی نیازی به دسترسی به آنها ندارند. فقط دسته‌‏ی اول به واسطه‌‎ی API gateway به دنیای بیرون عرضه می‌شوند.

2. نقش API Gateway در دنیای میکروسرویس‌ها:

با گذر زمان، APIها تبدیل به چهره عمومی شرکت‎‌ها شدند. اغراق نکرده‌ایم اگر بگوییم یک شرکت بدون API مثل یک رایانه بدون اینترنت است. اگر شما توسعه‌‎دهنده باشید حتما درک می‌کنید که زندگی بدون اینترنت به چه شکلی است!

برای بسیاری از شرکت‏‌ها، APIها کانال اصلی درآمدزایی هم هستند. بعنوان مثال در شرکت ایکس‌پدیا 90 درصد درآمد کل شرکت از طریق APIها تامین می‌شود. در سلفورث 50 درصد و در ای‌بی 60 درصد درآمد را ایجاد می‌کنند. نتفیلیکس هم شرکت دیگری است که بطور جدی روی APIها سرمایه گذاری کرده است. حساب‎‌های کاربری نتفیلیکس که درصد قابل توجهی از تمام ترافیک اینترنت شمال آمریکا و جهان را بخود اختصاص داده است، تماما از طریق APIهای نتفیلیکس منتقل میشوند.

میکروسرویس‌ها و APIها،مثل یک زوج موفق دست در دست هم هستند. در بسیاری از اوقات، یک میکروسرویس که باید برای نرم‌افزار مشتری دردسترس باشد، بعنوان یک API و توسط API Gateway عرضه می‌شود. یکی از نقش‌های کلیدی API Gateway در استقرار میکروسرویس‎‌ها، عرضه مجموعه‌‎ای منتخب از میکروسرویس‌‎ها به دنیای بیرون به‌عنوان API است و ساخت امکان کیفیتِ خدمت (QoS). امکانات QoS شامل امنیت، گلوگاه بودن و تحلیل است.

عرضه میکروسرویس‎‌ها به دنیای بیرون الزاما به این معنا نیست که در سطح اینترنت بصورت عمومی دیده شوند. ممکن است صرفا به خارج از یک دپارتمان دیگر داخل شرکت نیاز به عرضه API وجود داشته باشد، یعنی اجازه دهیم کاربران یا سیستم‎‌های یک دپارتمان دیگر درون همان مرزبندی سازمانی مشترک با ما، با میکروسرویس‎‌ها بواسطه API Gateway صحبت کنند.

3. احراز هویت در مرزها:

مشابه میکروسرویس‎‌ها، برای APIها نیز، مخاطب سیستمی است که بجای خودش یا بجای کاربر انسانی یا سیستم دیگر عمل با API کار می‌کند (تصویر 2 را ببینید).این نکته را در نظر داشته باشید که این امکان فراهم است که کاربر انسانی مستقیما با APIها کار کند، اما معمولا این اتفاق نمی‌افتد. در اغلب اوقات APIها به API Gateway ها عرضه می‌شوند و در نهایت API Gatewayها با سیستم‌‎های بیرونی کار می‌کنند. در ادامه، ما در مورد گزینه‎‌هایی که برای احراز هویت یک سیستم (یا نرم‌افزار مشتری) در API Gateway داریم صحبت خواهیم کرد.

3.1. احراز هویت مبتنی بر گواهی نامه:

احراز هویت مبتنی بر گواهینامه از API در مرزها با استفاده mutual transport layer security که از این به بعد به طور اختصار mTLS می‌گوییم، محافظت می‌کند . در استقرار میکروسرویس‌‎های نتفیلیکس، دسترسی به APIها با استفاده از گواهینامه‌‎ها محافظت می‌شود. فقط مشتریانی که گواهینامه‌‎ی معتبر دارند امکان دسترسی به APIهای نتفیلیکس را دارند. نقش API Gateway در اینجا این است که اطمینان حاصل کند که فقط مشتریان دارای گواهینامه‌‎ی قابل اطمینان به API دسترسی دارند و فقط درخواست‎‌های این مشتریان است که به سمت میکروسرویس‎های سرویس دهنده فرستاده می‌شوند. در قسمت‌های بعدی این سری مطالب در مورد این حوزه توضیحات دقیق‌تری را ارائه خواهیم کرد.

3.2. تفویض اختیار به کمک OAuth 2.0:

هر کسی می‌تواند برنامه‌‎ای بسازد که از APIهای فیسبوک و تویتر و ... استفاده کند.این برنامه‌‎ها میتوانند نرم‌افزارهای تحت وب، موبایل یا ... باشند. نرم‌افزاری که توسعه داده می‌شود می‌تواند به عنوان خودش یا کاربری دیگر به API دسترسی داشته باشد. OAuth 2.0 یک چارچوب احراز صلاحیت و تفویض اختیار است. این روش، برای محافظت از APIها در زمانی است که یک سیستم تقاضای دسترسی به API بجای یک سیستم دیگر یا کاربر را دارد توصیه شده است. در قسمت‌های بعدی در مورد OAuth 2.0 و روش استفاده از آن جهت تفویض اختیارات و احراز صلاحیت بیشتر صحبت خواهیم کرد.

نقش API Gateway اعتبارسنجی توکن‌‎های امنیتی OAuth 2.0 می باشد که در هر درخواست برای API وجود دارند. توکن امنیتی OAuth شامل نشان می‌دهد که کدام برنامه و از طرف چه کاربری قصد استفاده از API را دارد و می‌توان تشخیص داد برنامه‌ای که سراغ APIما آمده از طرف کدام کاربر وکالت دارد به اطلاعات سامانه ما دسترسی داشته باشد!

برای کسانی که دقیق‌تر با OAuth آشنا هستند شاید این استفاده از OAuth و جایگاهی که برای آن در نظر گرفته شده است کمی عجیب به نظر برسد! اما در قسمت‌های بعد با بیان جزئیات بیشتر از OAuth و نحوه استفاده از آن در روال‌های میکروسرویس ابهامات برطرف خواهد شد.

4. احراز مجوز و صلاحیت در مرزها:

یکی دیگر از مواردی که در مرز‌ها و در API Gateway قابل بررسی است، احراز مجوز و صلاحیت است. با توجه به مرکزیت این قسمت، قبل از انجام کار، مجوز‌های کاربر بررسی می‌شود که شامل دسترسی به منبع مورد نظر باشد و در صورتی که مجوز این کار را دارا نبود جلوی دسترسی گرفته می‌شود.

5. انتقال اطلاعات زمینه‌ای کاربر و نرم‌افزار مشتری به میکروسرویس‌ها:

تمام اتصالات مشتری‌ها به سرویس‌ها به API Gateway ختم می‌شود، اگر همه شرایط مساعد باشد، درخواست ‎ها به میکروسرویس‌های اصلی سرویس ‎دهنده منتقل خواهند شد. راهی نیاز است تا از کانال‎‌های ارتباطاتی بین API Gateway و میکروسرویس مربوطه محافظت شود، و همینطور راهی نیز برای ارسال اطلاعات زمینه‌ای کاربر/نرم‌افزار مشتری به میکروسرویس خدمات دهنده نیاز داریم. اطلاعات زمینه‌ای کاربر شامل یکسری اطلاعات پایه‌‎ای درمورد کاربر نهایی و همینطور اطلاعاتی درمورد نرم‌افزار مشتری می‌باشد. این اطلاعات عموما در میکروسرویس خدمات دهنده برای کنترل دقیق‌تر دسترسی در سطح سرویس مورد استفاده قرار می‌گیرد.

همانطور که به احتمال زیاد حدس می‌زنید، ارتباط بین API Gateway و میکروسرویس‌‎ها از نوع سیستم به سیستم است، پس می‌توانیم از mLTS برای امن کردن کانال ارتباطی استفاده کنیم. اما چطور باید اطلاعات کاربر و نرم‌افزار مشتری را برای میکروسرویس سرویس دهنده ارسال کنید؟ چند گزینه دارید: ارسال این اطلاعات در Headerهای HTTP یا ایجاد JWT با داده‎‌های کاربر. گزینه‌ی اول بسیار ساده است، اما کمی گرفتاری برای قابلیت اطمینان به این اطلاعات وجود دارد.زمانی که اولین میکروسرویس اطلاعات کاربر را دریافت می‌کند و برای ادامه کار فرایند را به میکروسرویس دیگری منتقل می‌کند اطلاعات زمینه‌ای کاربر و نرم‌افزار مشتری را در Headerهای درخواست HTTP برای یک میکروسرویس دوم ارسال می کند. میکروسرویس دوم هیچ تضمینی مبنی بر اینکه اطلاعات کاربر تغییر نکرده است ندارد و نمی‌تواند مطمئن باشد میکروسرویس اول این اطلاعات را متناسب با خواست خود تغییر نداده باشد. اما با JWT شما اطلاعات را در قالبی دارید که اگر یک سرویس واسط قبل از رسیدن JWT به دست شما اطلاعات آن را تغییر دهند، این تغییر را متوجه خواهید شد، چرا که صادر کننده‌ی JWT آن را امضا کرده است.

اگر با JWT آشنایی ندارید آن‌را محتوای امضا شده‎ای تصور کنید که داده (در این مثال اطلاعات زمینه‌ای کاربر و نرم‌افزار مشتری) را در حالت رمز شده و مطمئن منتقل می‌کند. API Gatewayها می‌توانند JWTای شامل اطلاعات کاربر (و یا اطلاعات نرم‌افزار مشتری) را ایجاد کنند و آن را برای میکروسرویس سرویس‎ دهنده ارسال کنند. (این نکته را در نظر بگیرید که معمولا عنصر سومی مسئول تولید JWT است که در این‌جا برای سادگی API Gateway را برای تولید آن در نظر گرفته‌ایم، در قسمت‌های بعد این مسئولیت و نحوه انجام آن را دقیق‌تر بررسی خواهیم کرد.) میکروسرویس دریافت کننده با تایید کردن امضای JWT به کمک کلید عمومیِ بخشی که JWT را صادر کرده است، آن را اعتبارسنجی می‌کند.

6. امنیت در ارتباط سرویس به سرویس:

تعدد ارتباط‌های سرویس با سرویس در استقرار میکروسرویس‌‎ها بالاست. ارتباطات بین دو میکروسرویس میتواند درون یک حوزه مطمئن یا بین دو حوزه مطمئن باشد. حوزه مطمئن بیانگر مالکیت است. میکروسرویس‌‎ها با هم و احتمالا درون یک حوزه مطمئن یا یک مرزبندی مطمئن که در سطح سازمان تعریف شده است و درنظر گرفتن فاکتورهای دیگر، توسعه، نصب و مدیریت می‌شوند.

مدل امنیتی که به‌منظور محافظت از ارتباطات سرویس به سرویس توسعه می‌دهیم، باید با درنظر گرفتن کانال‎های ارتباطی بین مرزبندی‎های مطمئن باشد و همینطور چگونگی ارتباطاتی که در واقع میخواهیم بین میکروسرویس‌‎ها باشد. همانطور که می‌دانید این ارتباط‌ها می‌تواند Sync یا Async باشد. غالب اوقات ارتباطات Sync بر بستر HTTP رخ می‎دهد. ارتباطات Async می‌تواند با هر نوع سیستمِ پیام‎رسانی نظیر RabbitMQ، Kafka، ActiveMQ و یا حتی Amazon Simple Queue Service (SQS) رخ دهد.

6.1. احراز هویت سرویس به سرویس:

برای امن کردن ارتباطات سرویس‌‎ها در قالب میکروسرویس سه روش معمول وجود دارد: اطمینان به شبکه ، mTLS و JWTها.

6.1.1. اطمینان به شبکه:

روش اطمینان به شبکه قدیمی‎‌ترین راه حلی است که مورد استفاده قرار می‌گیرد. این روش در عمل امنیتی را هم در ارتباطات سرویس به سرویس اجبار نمی‌کند. در واقع این مدل به امنیت در لایه شبکه اکتفا می‌کند. امنیت لایه شبکه باید این تضمین را بدهد که هیچ حمله‎‌کننده‎ای امکان شنود ارتباطات میکروسرویس‌‎ها را ندارد. همچنین هر میکروسرویس بعنوان سیستم مطمئن شناخته می‌شود. این انتخاب می‌تواند مبتنی بر انتظار شما از سطح امنیت و اعتماد شما به اجزای درون شبکه باشد.

روش قدیمی دیگری که در این حوزه مورد استفاده قرار میگیرد ، با عنوان شبکه‌‎ی نامطمئن یا zero trusted network شناخته می‌شود که نقطه مقابل روش اطمینان به شبکه است.در این روش یک پیشفرض را همیشه در نظر می‌گیریم که شبکه همواره نامطمئن و آسیب‎‌پذیر است و به هیچ جزئی دسترسی‌‎ای اعطا نمی‌شود. هر درخواستی که به هر میکروسرویسی می‌رسد، پیش از آنکه برای پردازش پذیرفته شود، هربار باید احرازهویت و احراز مجوز شود.

6.1.2. استفاده از mTLS:

یکی از روش‎های مرسوم دیگر برای امن کردن ارتباطات سرویس به سرویس در استقرار میکروسرویس‌‎ها، روش Mutual TLS می‌باشد . در حقیقت، این روش پر استفاده‌‎ترین شکل از احراز هویت در این روزهاست. هر میکروسرویسی که در استقرار وجود دارد، برای ارتباط با میکروسرویس گیرنده باید جفت کلیدهای عمومی/خصوصی را با خود حمل کند و با استفاده از mTLS احراز هویت کند.

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

6.1.2. استفاده از JWT:

سومین روش برای امن کردن ارتباطات سرویس به سرویس در استقرار میکروسرویس‎‌ها، استفاده از JWT است. برخلاف mTLS که در لایه Transport فعالیت می‌کرد JWT در لایه‌‎ی Application کار می کند، نه لایه‏ ی انتقال. JWT در عمل همچون یک ظرف عمل می کند که میتواند مجموعه‎‌ای از داده‌ها را از جایی به جای دیگر منتقل کند.

این اطلاعات، هرچیزی می تواند باشد، مثل خصوصیات کاربر نهایی (آدرس ایمیل، شماره تلفن)، عملکردهای قابل قبول کاربر نهایی (این که چه کارهایی می تواند انجام دهد) یا هرچیز دیگری که میکروسرویس جاری میخواهد برای میکروسرویس گیرنده ارسال کند. JWT شامل این اطلاعات می شود.اطلاعات داخل JWT توسط صادر کننده‌ی JWT امضا می شود. صادر کننده میتواند یک Security Token Service یا به اختصار STS خارجی باشد یا خود میکروسرویس جاری.

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

6.2. احراز مجوز و صلاحیت در سطح سرویس:

در یک استقرار معمول میکروسرویس‌‎ها، احرازصلاحیت می‌تواند در مرز صورت بگیرد یا در هر سرویس یا در هر دو . وقتی احراز صلاحیت در سطح سرویس انجام شود، دست بازتری برای اعمال سیاست‎‌های کنترل دسترسی‎‌هایی که دلمان می‌خواهد داشته باشیم، خواهیم داشت. دو روش برای اعمال صلاحیت دسترسی در سطح سرویس مطرح است: مدل مرکزی PDP و مدل توکار PDP. در اینجا PDP مخفف Policy Decision Point می‌باشد.

در مدل مرکزی PDP، تمام سیاست‎های کنترل دسترسی، در یک‌جای مرکزی، ایجاد، نگهداری و اجرا می‌شوند (تصویر 3 را ببینید). هربار که سرویس بخواهد یک درخواست را اعتبارسنجی کند، باید با نقطه انتهایی که توسط PDP مرکزی عرضه شده است صحبت کند. این روش به طور جدی به PDP وابسته است و تاخیر را به علت هزینه فراخوانی از راه دور با نقطه‌ انتهاییPDP افزایش می‌دهد. در این موارد، با ذخیره موقت سیاست‎های کنترل دسترسی در سطح سرویس می‌توانیم این تاخیر را ازبین ببریم، اما وقتی این ذخیره موقت بخاطر محدودیت زمانی از بین برود، یا برای دریافت سیاست‎های جدید، طبعا دوباره باید با PDP ارتباط بگیرد. در عمل، سیاست‌های جدید به ندرت اضافه می‌شوند، اما انقضای زمانی حافظه‎ ی موقت مسئله‎ای پر رخداد است.

با PDP توکار، سیاست‎ها به شکل مرکزی تعریف، اما در سطح سرویس نگهداری و اجرا می شوند. چالش PDPهای توکار این است که چطور سیاست‎ها را از طریق Policy Administration Point یا به اختصار PAP مرکزی بروز رسانی کنیم.

برای انجام این کار دو روش متداول وجود دارد. یک روش دریافت مستمر از PAP بعد از یک بازه زمانی می‌باشد و مجدد دریافت سیاست‎های جدید از PAP. روش دیگر، مکانیزم ارسال است. زمانی که سیاستی تغییر کرد یا اضافه شد، خود PAP آن را بعنوان یک رخداد منتشر میکند. در این حالت، هر میکروسرویس بعنوان دریافت کننده رخداد عمل میکند و سیاست‎های مربوط به خودش را از PAP می‌گیرد و PDP توکار خودش را بروز می‌کند.

برخی معتقدندکه هر دوی این روش‎‌ها مخرب و عذاب‌آور هستند. به همین دلیل آن‌ها سیاست‎ها را فقط در زمانی که سرور بالا میاید روی PDP توکار بارگذاری می‌کنند. و هر زمانی که سیاست جدیدی اضافه شد یا تغییر کرد، تمام سرویس‌ها براید دریافت تغییرات مجبور به شروع مجدد هستند.

6.3. انتشار اطلاعات زمینه‌ای کاربر:

زمانیکه یک میکروسرویس یک میکروسرویس دیگر را فراخوانی میکند، نیاز دارد که شناسه‌‎ی کاربرنهایی و شناسه‌‏ی خود میکروسرویس را ارسال کند. زمانیکه یک میکروسرویس با استفاده از mTLS و JWT احراز هویت می‌کند، شناسه‎‌ی میکروسرویس فراخوانی کننده درون اعتبارنامه‎‌ی توکار آن تزریق می‌شود. سه راه معمول برای ارسال اطلاعات زمینه‌ای کاربرنهایی از یک میکروسرویس به یک میکروسرویس دیگر وجود دارد:

روش اول ارسال اطلاعات کاربر در Headerهای HTTP است. این تکنیک به میکروسرویس دریافت کننده کمک می‌کند تا کاربر را تشخیص دهد، اما لازمه این کار اعتماد دریافت کننده به فراخوانی کننده است. اگر فراخوانی کننده بخواهد که دریافت کننده را فریب دهد به آسانی فقط با تنظیم نام دلخواهش در Headerهای HTTP می‌تواند اینکار را انجام دهد.

روش دوم استفاده از JWT است. JWT اطلاعات زمینه‌ای کاربر را از میکروسرویس فراخوانی کننده به میکروسرویس گیرنده حمل می‌کند و او هم آن را درون سربرگ HTTP قرار میدهد. اگر قرار باشد سرویس صدا زننده خودش صادرکننده JWT باشد، هیچ ارزش افزوده‎ای نسبت به روش اول ندارد. JWTای که سرویس صدازننده تولید می‌کند، توسط خود سرویس فراخوانی کننده امضا می‌شود، فلذا براحتی می‌تواند میکروسرویس دریافت کننده را با اضافه کردن هر اطلاعات دلخواهی به آن در مورد اطلاعات زمینه‌ای کاربر فریب دهد.

سومین روش نیز استفاده از JWTای که توسط یک STS خارجی صادر شده است و برای تمام ماشین‎‌های درون استقرار قابل اطمینان است. اطلاعات زمینه‌ای کاربر که درون JWT قرار گرفته است امکان تغییر ندارد، چنانچه تغییر کند، امضای JWT نامعتبر می‌شود. این امن‎‌ترین روش است. زمانی که JWT را از یک STS خارجی دارید، میکروسرویس فراخوانی کننده میتواند آن را درون یک JWT دیگر کار بگذارد و با اینکار JWT تو درتو ایجاد کند.

6.4. عبور از محدوده امن:

به طور معمول هنگام انتشار میکروسرویس‌ها چندین محدوده مورد اطمینان خواهیم داشت. این محدوده‌های مورد اطمینان آن‌هایی هستند که تیم‌های توسعه میکروسرویس بر روی استراتژی‌ها و نحوه مدیریت آن‌ها نظارت دارند یا به کمک روابط سازمانی می‌توانند آن‌ها را کنترل کنند. برای مثلا در یک سیستم خرده فروشی، واحد خرید و فروش احتمالا بر روی تمامی سرویس‌های توسعه داده شده در این حوزه کنترل و نظارت دارد و محدوده مورد اطمینان خود را می‌سازد.

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

اگر یک میکروسرویس بخواهد با میکروسرویس خارج از محدوده اطمینان جاری خود ارتباط برقرار کند دو حالت کلی برای انجام این کار وجود دارد. برای تشریح اولین حالت به تصویر 4 نگاه کنید.

فرض کنید که سرویس Order Processing در دامنه اطمینان foo می‌خواهد با میکروسرویس Delivery Service در دامنه اطمینان bar ارتباط برقرار کند. ابتدا میکروسرویس Order Processing باید یک توکن که مورد قبول میکروسرویس‌های حاضر در محدوده bar هستند را به دست آورد. به بیان دیگر سرویس حاضر در محدوده foo باید برای دریافت نشان امنیتی از طریق STSحاضر در محدوده امنیتی bar اقدام نماید. مراحل انجام این کار به شرح زیر می‌باشد.

• در اولین قدم API Gateway درخواست را از اپلیکیشن مشتری به میکروسرویس Order Processing در حوزه مطمئن foo بهمراه JWT امضا شده توسط API Gateway یا توسط STS متصل به آن ارسال می‌کند. از آنجاییکه تمام میکروسرویس‎های حوزه مطمئن foo به STS بالاترین سطح اطمینان دارند، میکروسرویس Order Processing توکن را بعنوان نشانه معتبر می‌پذیرد. JWT خاصیتی دارد بنام aud که سیستم هدف JWT را مشخص میکند. در این مورد، مقدار aud با میکروسرویس Order Processing حوزه foo تنظیم شده است. در حالت ایده‎‌آل، زمانی که میکروسرویس Order Processing یک JWT را با مقدار متفاوت aud دریافت کند، باید آن JWT را نادیده بگیرد، حتی اگر امضای آن معتبر باشد.
• قدم دوم این است که میکروسرویس Order Processing آن JWTای که از API Gateway یا STS سطح بالاتر گرفته است برای STS درون حوزه مطمئن foo ارسال میکند. تکرار می کنم، STS حوزه foo باید مقدار aud درون JWTای که دریافت کرده است را اعتبارسنجی کند. اگر نتواند نشانه آن را شناسایی کند، باید آن را نادیده بگیرد.
• سومین قدم این است که STS درون foo یک JWT جدید که توسط خودش امضا کرده است و مقدار aud آن را برابر با STS حوزه مطمئن bar قرار داده است برمی‌گرداند.
• در چهارمین و پنجمین قدم میکروسرویس Order Processing به STS حوزه مطمئن bar دسترسی پیدا می‌کند و JWT بدست آمده از قدم سوم را ارسال کرده و یک JWT امضا شده توسط STS حوزه مطمئن bar دریافت می‌کند و البته مقدار aud آن را برابر با میکروسرویس Delivery قرار می‌دهد.
• قدم ششم میکروسرویس Order Processing به میکروسرویس Delivery بواسطه JWT بدست آمده از قدم پنج دسترسی می‌گیرد و از آنجاییکه STS حوزه bar این JWT را امضا کرده است و مقدار aud درست می‌باشد، میکروسرویس Delivery توکن را می‌پذیرد.

اما در حالت دوم سرویس‌ها پشت یک API Gateway قرار ندارند. در این حالت هر میکروسرویس در حوزه اطمینان خود و با یک API Gateway جداگانه قرار دارد که نمونه‌ای از این حالت را در تصویر 5 مشاهده می‌کنید.

در چنین شرایطی انجام ارتباط به شرح زیر صورت خواهد پذیرفت.

• در اولین قدم API Gateway درون حوزه‌‎ی مطمئن fooدرخواست را از نرم‌افزار مشتری به سمت میکروسرویس Order Processingبهمراه JWTامضا شده توسط API Gateway یا توسط STS درون foo که به API Gateway این حوزه چسبیده شده ارسال می‌کند. از آنجاییکه تمام میکروسرویس‌‎های درون حوزه foo به STS این حوزه اعتماد دارند، میکروسرویس Order Processing توکن رسیده را معتبر به حساب می‌آورد.
• در قدم دوم میکروسرویس Order Process، JWT اصلی را که از API Gateway یا همان STS حوزه foo دریافت کرده است را برای STS خود ارسال می‌کند.
• قدم سوم به این شکل است که STS حوزه foo یک JWT جدید برمی‌گرداند که توسط خودش برای API Gateway درون حوزه مطمئن bar امضا کرده است.
• در چهارمین قدم میکروسرویس Order Processing توسط JWTای که در قدم سوم بدست آمد، به میکروسرویس Delivery درون حوزه مطمئن bar دسترسی پیدا می‌کند. از آنجاییکه API Gateway حوزه bar به STS حوزه foo اطمینان دارد، JWT را معتبر تشخیص می‌دهد. JWT توسط STS حوزه foo امضا شده است و با API Gatewayحوزه bar همخوانی دارد.
• قدم پنجم این است که API Gatewayحوزه bar با STS حوزه bar صحبت می‌کند تا JWT خودش را ایجاد کند (یعنی توسط STS حوزه bar امضا شده باشد) که برای میکروسرویس Delivery امضا شده باشد.
• در انتها و ششمین قدم API Gatewayحوزه bar درخواست را به‌ همراه JWT صادر شده از STS حوزه bar به سمت میکروسرویس Delivery ارسال می‌کند. از آنجایی که میکروسرویس Delivery به STS خودش اطمینان دارد، نشانه بعنوان معتبر پذیرفته می‌شود.

7. جمع بندی:

در این قسمت با بخش دیگری از مقدمات امنیت در میکروسرویس‌ها آشنا شدیم، با هم دیدیم چالش‌های یکسانی در ارتباط با دنیای بیرون اپلیکیشن از طریق API Gateway و دنیای داخل اپلیکیشن بین میکروسرویس‌ها وجود دارد که برای هر چالش و صورت مسئله مثل شناسایی کاربر و مشتری و ... راهکارهای متفاوتی در دو حوزه وجود دارد!

در قسمت‌های بعد مطالبی که در این دو قسمت به صورت اجمالی بیان شده است را با جزئیات بیشتری بررسی خواهیم کرد!

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