شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات
امنیت لایه انتقال (TLS)، که سلف آن لایه سوکتهای امن (SSL) است، فناوری امنیتی استاندارد برای ایجاد یک لینک رمزگذاری شده بین یک وب سرور و یک کلاینت وب، مانند یک مرورگر یا یک برنامه است. یک لینک رمزگذاری شده تضمین میکند که تمام دادههای عبوری بین سرور و کلاینت، خصوصی باقی میمانند. برای استفاده از TLS، کلاینت با استفاده از پروتکل رمزگذاری شده HTTPS ، به جای پروتکل رمزگذاری نشده HTTP ، یک درخواست امن به سرور ارسال میکند.
Edge از TLS یک طرفه و دو طرفه هم در فضای ابری و هم در محل استقرار پشتیبانی میکند (برای نسخههای پشتیبانی شده TLS به نرمافزارهای پشتیبانی شده و نسخههای پشتیبانی شده مراجعه کنید). TLS یک طرفه، کلاینت TLS را قادر میسازد تا هویت سرور TLS را تأیید کند. به عنوان مثال، یک برنامه که روی یک تلفن اندروید (کلاینت) اجرا میشود، میتواند هویت APIهای Edge (سرور) را تأیید کند.
Apigee همچنین از نوع قویتری از احراز هویت با استفاده از TLS دوطرفه یا کلاینت پشتیبانی میکند. شما معمولاً TLS دوطرفه را برای افزایش امنیت سرتاسری و محافظت از دادههای خود در برابر حملات کلاینت مانند جعل کلاینت یا حملات مرد میانی پیادهسازی میکنید. در TLS دوطرفه، کلاینت هویت سرور را تأیید میکند و به دنبال آن سرور هویت کلاینت را تأیید میکند.
اصطلاحات TLS
قبل از پیکربندی TLS باید با اصطلاحات و مفاهیم مهم زیر آشنا باشید:
مدت | تعریف |
|---|---|
کالیفرنیا | مرجع صدور گواهی. یک نهاد معتبر، مانند Symantec یا VeriSign، که برای صدور گواهی و تأیید صحت آن استفاده میشود. نوعی از گواهی، به نام گواهی خودامضا ، نیازی به CA ندارد. |
زنجیره گواهی | اغلب شما گواهیای که توسط کلید خصوصی ریشه CA شما امضا شده باشد، نخواهید داشت. در عوض، گواهی خود را به همراه یک یا چند گواهی میانی دارید که یک زنجیره را تشکیل میدهند. آخرین گواهی میانی در این زنجیره معمولاً توسط کلید خصوصی ریشه CA امضا میشود. |
مسئولیت اجتماعی شرکتی | درخواست امضای گواهی. CSR فایلی است که بر اساس کلید خصوصی در سرور TLS تولید میشود. CSR حاوی کلید عمومی و سایر اطلاعات مانند نام سازمان، مکان و نام دامنه است. CA برای ایجاد گواهی TLS، CSR را امضا میکند. شما معمولاً زمانی یک CSR تولید میکنید که یک گواهی منقضی شده دارید و میخواهید آن را تمدید کنید. |
| در | قوانین رمزگذاری متمایز. فرمت DER یک فرم دودویی از گواهی است، نه فرمت ASCII PEM. گاهی اوقات پسوند فایل آن .der است، اما اغلب پسوند فایل آن .cer است. تنها راه برای تشخیص تفاوت بین یک فایل DER .cer و یک فایل PEM .cer، باز کردن فایل در یک ویرایشگر متن و جستجوی عبارات |
| نام مستعار کلید | یک نام مستعار کلید، ورودی کلید (گواهی TLS و کلید خصوصی مربوطه) را به طور منحصر به فرد در کلید شناسایی میکند. در Apigee Edge، |
فروشگاه کلید | یک keystore مخزنی است که شامل یک یا چند گواهی TLS و یک کلید خصوصی مربوطه است که برای شناسایی موجودیت در طول یک handshake TLS بین کلاینت و سرور استفاده میشود. در اتصال به سمت شمال ، روتر به عنوان سرور عمل میکند و گواهی آن در keystore در Apigee Edge ذخیره میشود. در اتصال به سمت جنوب ، پردازنده پیام به عنوان کلاینت و سرور backend به عنوان سرور عمل میکند. گواهی کلاینت و کلید خصوصی آن در keystore در Apigee Edge ذخیره میشوند. |
| P7B | فرمت PKCS #7 یا P7B معمولاً در قالب Base64 ASCII ذخیره میشود و پسوند فایل .p7b یا .p7c دارد. گواهیهای P7B شامل دستورات |
پی ای ام | فرمت ایمیل با حفظ حریم خصوصی (PEM) یک فرمت ASCII مبتنی بر متن است که یک کدگذاری Base64 از فرمت قوانین کدگذاری متمایز (DER) باینری است. گواهیهای PEM را میتوان در هر ویرایشگر متنی باز کرد و محتوای واقعی گواهی بین عبارات این با فرمت X.509 برای ذخیره گواهی، زنجیره گواهی یا کلید خصوصی مطابقت دارد. اگر گواهی یا کلید خصوصی شما توسط یک فایل PEM تعریف نشده است، میتوانید با استفاده از ابزارهایی مانند OpenSSL آن را به یک فایل PEM تبدیل کنید. |
| PKCS #12/PFX | فرمت PKCS #12 یا PFX یک فرمت دودویی برای ذخیره گواهی سرور، هرگونه گواهی واسطه و کلید خصوصی در یک فایل قابل رمزگذاری است. فایلهای PFX معمولاً پسوندهایی مانند .pfx و .p12 دارند. فایلهای PFX معمولاً در دستگاههای ویندوز برای وارد کردن و صادر کردن گواهیها و کلیدهای خصوصی استفاده میشوند. |
کلید خصوصی | برای رمزگشایی دادهها در سرور TLS استفاده میشود. فقط سرور TLS کلید خصوصی را دارد - این کلید با کلاینتهای TLS به اشتراک گذاشته نمیشود. |
کلید عمومی | برای رمزگذاری دادههای ارسالی از یک کلاینت TLS به یک سرور TLS استفاده میشود. کلید عمومی در گواهینامه موجود است. همه کلاینتهای TLS یک کپی از کلید عمومی سرور دارند. |
| منابع | ارجاعات سطحی از غیرمستقیم بودن را برای keystoreها فراهم میکنند؛ بنابراین، تغییرات keystore تا زمانی که همان ارجاع و نام مستعار کلید حفظ شوند، نیازی به بهروزرسانی میزبان مجازی ندارند. این امر به شما این امکان را میدهد که این تغییرات را به صورت خودکار انجام دهید و وابستگیها را با تیم پشتیبانی Apigee کاهش دهید. |
گواهی خودامضا | گواهینامهای که توسط یک مرجع صدور گواهی معتبر امضا نشده است. صادرکننده و موضوع گواهی یکسان هستند؛ آنها با کلید خصوصی مطابق با کلید عمومی موجود در آنها امضا شدهاند. |
اس ان آی | نشانگر نام سرور. اجازه میدهد چندین هدف HTTPS از طریق آدرس IP و پورت یکسان، بدون نیاز به استفاده از گواهی یکسان، سرویسدهی شوند. |
گواهی TLS | یک فایل دیجیتالی که یک موجودیت را در یک تراکنش TLS شناسایی میکند. بسته به پیکربندی TLS، میتوان از یک گواهی یا cert برای شناسایی سرور TLS و کلاینت TLS استفاده کرد. |
فروشگاه تراست | شامل گواهیهای معتبر روی یک کلاینت TLS است که برای اعتبارسنجی گواهی سرور TLS ارائه شده به کلاینت استفاده میشود. این گواهیها معمولاً گواهیهای خودامضا یا گواهیهایی هستند که توسط یک CA معتبر امضا نشدهاند. در اتصال به سمت شمال ، گواهیهای برنامهی کلاینت در حافظهی امن Apigee Edge ذخیره میشوند. این مورد فقط در صورتی لازم است که یک TLS دوطرفه بین کلاینت و Apigee پیکربندی کرده باشید. در اتصال به سمت جنوب ، گواهیهای سرور backend در truststore در Apigee Edge ذخیره میشوند. این مورد در صورتی لازم است که بخواهید گواهی backend را در Apigee Edge در ارتباط TLS یک طرفه یا دو طرفه بین Apigee Edge و سرور backend تأیید کنید. Apigee Edge شیء truststore جداگانهای ندارد. بنابراین، truststoreها به عنوان یک شیء keystore ایجاد میشوند، اما در هر کجا که استفاده شوند (مثلاً در میزبان مجازی، نقاط انتهایی هدف، سرورهای هدف و غیره) به عنوان truststore ارجاع داده میشوند. |
| میزبان مجازی | میزبان مجازی، نقطه پایانی API Apigee را برای برنامههای کلاینت نشان میدهد. این یک موجودیت است که به میزبانی چندین نام دامنه (با مدیریت جداگانه هر نام) در یک سرور واحد (یا مجموعهای از سرورها) کمک میکند. این به یک سرور اجازه میدهد تا منابع خود، مانند حافظه و چرخههای پردازنده را بدون نیاز به استفاده از نام میزبان یکسان برای همه سرویسهای ارائه شده، به اشتراک بگذارد. یک میزبان مجازی میتواند ترافیک HTTP یا HTTPS (با قابلیت SSL) را ارائه دهد. یک میزبان مجازی با قابلیت SSL میتواند در حالت TLS یک طرفه یا دو طرفه پیکربندی شود. این حالت با موارد زیر پیکربندی میشود:
|
TLS/SSL یک طرفه
شکل زیر، روش دستدهی TLS/SSL را برای احراز هویت یکطرفه بین یک کلاینت TLS و سرور TLS نشان میدهد:
در پیکربندی TLS یک طرفه، handshake به شرح زیر است:
- کلاینت یک درخواست جلسه به سرور ارسال میکند.
- سرور با یک گواهینامه پاسخ میدهد که حاوی کلید عمومی آن است. این گواهینامه از انبار کلید سرور میآید که حاوی کلید خصوصی سرور نیز هست. کلید خصوصی هرگز برای کلاینت ارسال نمیشود.
- برای یک گواهی امضا شده، کلاینت از یک مخزن اعتماد حاوی گواهیهای سرور و کلیدهای عمومی استفاده میکند تا تأیید کند که زنجیره گواهی توسط یک مرجع صدور گواهی (CA) معتبر امضا شده است.
- کلاینت و سرور چندین پیام دیگر برای اعتبارسنجی کلیدها رد و بدل میکنند.
- کلاینت انتقال داده TLS را با سرور آغاز میکند.
شکل زیر، فرآیند handshaking مربوط به TLS/SSL را با استفاده از یک truststore اختیاری روی کلاینت نشان میدهد:
اگر سرور TLS از یک گواهی خودامضا یا گواهیای که توسط یک CA معتبر امضا نشده است استفاده کند، شما یک truststore روی کلاینت ایجاد میکنید. کلاینت truststore خود را با گواهیهای سرور و کلیدهای عمومی که به آنها اعتماد دارد، پر میکند. هنگامی که کلاینت یک گواهی دریافت میکند، گواهی دریافتی در مقایسه با گواهیهای موجود در truststore آن اعتبارسنجی میشود.
در TLS یکطرفه، Edge میتواند به صورت زیر سرور یا کلاینت باشد:
Edge به عنوان سرور TLS
Edge سروری است که میزبان نقطه پایانی TLS است، جایی که نقطه پایانی TLS مربوط به یک پروکسی API است که در یک میزبان مجازی مستقر شده است. کلاینت برنامهای است که سعی در دسترسی به پروکسی API دارد. در این سناریو، Edge دارای کلید اصلی است که حاوی گواهی و کلید خصوصی است.
Edge به عنوان کلاینت TLS
Edge به عنوان کلاینتی عمل میکند که به یک سرویس backend دسترسی دارد. در این حالت، سرویس backend مربوط به سروری است که میزبان یک نقطه پایانی TLS است. بنابراین سرور backend دارای یک keystore است که شامل گواهی و کلید خصوصی آن است.
TLS دو طرفه
شکل زیر، روش دستدهی TLS/SSL را برای احراز هویت دوطرفه TLS بین کلاینت و سرور نشان میدهد:
در TLS دوطرفه، دستدهی به صورت زیر است:
- کلاینت و سرور هر دو دارای keystore های مخصوص به خود هستند. keystore کلاینت شامل cert و کلید خصوصی آن است و keystore سرور شامل cert و کلید خصوصی آن است.
- سرور TLS گواهی خود را برای احراز هویت به کلاینت TLS ارائه میدهد. سپس کلاینت قبل از ارسال گواهی خود به سرور، هویت سرور را تأیید میکند.
- کلاینت TLS گواهی خود را به سرور TLS ارائه میدهد تا خود را به سرور احراز هویت کند.
شکل زیر، TLS handshaking را با استفاده از یک truststore اختیاری نشان میدهد:
در این سناریو، دست دادن به صورت زیر است:
- اگر سرور TLS از یک گواهی خودامضا یا گواهیای که توسط یک CA معتبر امضا نشده است استفاده کند، شما یک truststore روی کلاینت ایجاد میکنید. کلاینت یک کپی از گواهی سرور را در truststore خود دارد. در طول TLS handshaking، کلاینت گواهی موجود در truststore خود را با گواهی ارسالی از سرور مقایسه میکند تا هویت سرور را تأیید کند.
- اگر کلاینت TLS از یک گواهی خودامضا یا گواهیای که توسط یک CA معتبر امضا نشده است استفاده کند، شما یک truststore روی سرور ایجاد میکنید. سرور یک کپی از گواهی کلاینت را در truststore خود دارد. در طول TLS handshaking، سرور گواهی موجود در truststore خود را با گواهی ارسالی از کلاینت مقایسه میکند تا هویت کلاینت را تأیید کند.
کلاینت یا سرور یا هر دو میتوانند از یک فروشگاه اعتماد استفاده کنند.
در TLS دوطرفه، Edge میتواند به صورت زیر سرور یا کلاینت باشد:
لبه به عنوان سرور
Edge سروری است که میزبان نقطه پایانی TLS است، جایی که نقطه پایانی TLS با یک پروکسی API مطابقت دارد. کلاینت، برنامهای است که سعی در دسترسی به پروکسی API دارد. در این سناریو، Edge دارای یک keystore حاوی گواهی و کلید خصوصی است و به یک truststore حاوی گواهی و زنجیره CA کلاینت نیاز دارد.
لبه به عنوان کلاینت
Edge به عنوان کلاینتی عمل میکند که به یک سرویس backend دسترسی دارد. در این حالت، سرویس backend مربوط به سروری است که میزبان نقطه پایانی TLS است. بنابراین، سرور backend دارای یک keystore است که حاوی گواهی و کلید خصوصی آن است.
Edge همچنین باید یک keystore تعریف کند که شامل گواهی مورد نیاز برای اعتبارسنجی خود در سرویس backend باشد، و در صورت استفاده از گواهی self-signed یا گواهی که توسط یک CA معتبر امضا نشده است، به صورت اختیاری یک truststore حاوی گواهی از سرور backend نیز تعریف کند.
نکتهی مهمی که باید به خاطر داشته باشید این است که اج به اندازهی کافی انعطافپذیر است تا از TLS دوطرفه پشتیبانی کند، صرف نظر از اینکه چگونه تصمیم به پیکربندی آن بگیرید.
پشتیبانی SNI
Edge از استفاده از نشانگر نام سرور (SNI) از پروکسیهای API به Edge، که در آن Edge به عنوان سرور TLS عمل میکند، و از Edge به نقاط انتهایی هدف، که در آن Edge به عنوان کلاینت TLS عمل میکند، در هر دو نصب Cloud و Private Cloud پشتیبانی میکند.
با SNI، که افزونهای از TLS/SSL است، میتوان چندین هدف HTTPS را از طریق یک آدرس IP و پورت یکسان، بدون نیاز به استفاده از گواهینامه یکسان، ارائه داد.
برای اطلاعات بیشتر در مورد فعال کردن SNI برای نصب در محل، به بخش «استفاده از SNI با Edge» مراجعه کنید.
به سمت شمال و جنوب
در Apigee، northbound به نقطه پایانی API اشاره دارد که توسط برنامههای کلاینت برای فراخوانی API Proxy استفاده میشود. معمولاً Router نقطه ورودی در Apigee Edge است و درخواستهای ورودی به Apigee Edge را مدیریت میکند. بنابراین در Apigee، نقطه پایانی مورد استفاده برای ارتباط بین برنامه کلاینت و Apigee Edge (روتر) به عنوان northbound شناخته میشود.
در Apigee، عبارت southbound به نقطه پایانی هدفی اشاره دارد که Apigee برای ارتباط با سرور backend از آن استفاده میکند. بنابراین در Apigee، نقطه پایانی مورد استفاده برای ارتباط بین Apigee Edge (پردازنده پیام) و سرور backend، southbound نامیده میشود. پردازنده پیام، جزئی از Apigee Edge است که درخواستهای API را به سرورهای هدف backend ارسال میکند.
شکل زیر اتصالات شمال و جنوب را برای Apigee Edge نشان میدهد:
