درباره TLS/SSL

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

«امنیت لایه انتقال» (TLS)، که پیش‌از آن «لایه اتصال امن» (SSL) بوده است، فناوری امنیتی استاندارد برای ایجاد پیوند رمزگذاری‌شده بین سرور وب و کارخواه وب، مثل مرورگر یا برنامه، است. پیوند رمزگذاری‌شده تضمین می‌کند که همه داده‌های ردوبدل‌شده بین سرور و کارخواه خصوصی باقی بماند. برای استفاده از TLS، کارخواه بااستفاده از پروتکل رمزگذاری‌شده HTTPS به‌جای پروتکل رمزگذاری‌نشده HTTP، درخواست امنی به سرور ارسال می‌کند.

‫Edge از «امنیت لایه انتقال» یک‌طرفه و «امنیت لایه انتقال» دوطرفه در استقرار ابری و در محل پشتیبانی می‌کند (برای نسخه‌های پشتیبانی‌شده «امنیت لایه انتقال»، نرم‌افزار پشتیبانی‌شده و نسخه‌های پشتیبانی‌شده را ببینید). «امنیت لایه انتقال» یک‌طرفه به کارخواه «امنیت لایه انتقال» امکان می‌دهد هویت سرور «امنیت لایه انتقال» را درستی‌سنجی کند. برای مثال، برنامه‌ای که در تلفن Android (کارخواه) اجرا می‌شود می‌تواند هویت «میاناهای برنامه‌سازی کاربردی Edge» (سرور) را درستی‌سنجی کند.

‫Apigee همچنین از شکل قوی‌تری از اصالت‌سنجی بااستفاده از TLS دوطرفه یا کارخواه پشتیبانی می‌کند. شما معمولاً «امنیت لایه انتقال دوطرفه» را برای بهبود امنیت سرتاسری و محافظت از داده‌هایتان دربرابر حملات کارخواه مثل جعل کارخواه یا حملات مرد میانی پیاده‌سازی می‌کنید. در TLS دوطرفه، کارخواه هویت سرور را درستی‌سنجی می‌کند و سپس سرور هویت کارخواه را درستی‌سنجی می‌کند.

اصطلاحات «امنیت لایه انتقال»

قبل‌از پیکربندی TLS، باید با اصطلاحات و مفاهیم مهم زیر آشنا باشید:

مدت	تعریف
CA	مرجع صدور گواهی. نهاد معتمدی، مانند Symantec یا VeriSign، که برای صدور گواهینامه‌ها و تأیید اصالت گواهینامه استفاده می‌شود. نوعی گواهی به نام گواهی خودامضا وجود دارد که به مرجع صدور گواهی نیاز ندارد.
زنجیره گواهینامه	اغلب گواهینامه‌ای که با کلید خصوصی ریشه «مرجع صدور گواهی» امضا شده باشد نخواهید داشت. درعوض، گواهینامه‌تان را به‌همراه یک یا چند گواهینامه واسطه دارید که زنجیره‌ای را تشکیل می‌دهند. آخرین گواهینامه واسط در زنجیره معمولاً با کلید خصوصی ریشه CA امضا می‌شود.
CSR	درخواست امضای گواهینامه. «درخواست گواهینامه» (CSR) فایلی است که در سرور TLS براساس کلید خصوصی تولید می‌شود. «درخواست امضای گواهینامه» حاوی کلید عمومی و اطلاعات دیگری مثل نام، مکان، و نام دامنه سازمان است. «مرجع صدور گواهی» «درخواست امضای گواهینامه» را امضا می‌کند تا گواهینامه «امنیت لایه انتقال» ایجاد کند. معمولاً زمانی که گواهینامه منقضی دارید و می‌خواهید آن را تمدید کنید، CSR تولید می‌کنید.
DER	قوانین متمایز کدبندی. قالب DER به‌جای قالب ASCII PEM، قالب باینری گواهی است. گاهی‌اوقات پسوند فایل آن ‎ .der است اما اغلب پسوند فایل آن ‎ .cer است. تنها راه تشخیص تفاوت بین فایل DER .cer و فایل PEM .cer باز کردن فایل در ویرایشگر نوشتار و جستجوی عبارت‌های BEGIN و END است. همه انواع گواهی‌ها و کلیدهای خصوصی می‌توانند در قالب DER کدبندی شوند. DER معمولاً با پلاتفرم‌های Java استفاده می‌شود.
نام مستعار کلید	نام مستعار کلید به‌طور یکتا ورودی محل ذخیره کلید (گواهی TLS و کلید خصوصی مربوطه) را در محل ذخیره کلید شناسایی می‌کند. در Apigee Edge، وقتی گواهی/کلید را بااستفاده از «میانای کاربری» یا «میانای برنامه‌سازی کاربردی» در مخزن کلیدها بارگذاری می‌کنید، KeyAlias به‌عنوان alias نامیده می‌شود.
Keystore	محل ذخیره کلید مخزنی است که حاوی یک یا چند گواهینامه «امنیت لایه انتقال» و کلید خصوصی مربوطه است که برای شناسایی نهاد درطول دست دادن «امنیت لایه انتقال» بین «کارخواه» و «سرور» استفاده می‌شود. در اتصال شمالی، «مسیریاب» به‌عنوان سرور عمل می‌کند و گواهینامه آن در انبار کلید در Apigee Edge ذخیره می‌شود. در اتصال جنوبی، «پردازشگر پیام» نقش کارخواه را ایفا می‌کند و سرور زیرینه نقش سرور را ایفا می‌کند. گواهینامه مشتری و کلید خصوصی آن در محل ذخیره کلید در Apigee Edge ذخیره می‌شود.
P7B	قالب PKCS #7 یا P7B معمولاً در قالب Base64 ASCII ذخیره می‌شود و پسوند فایل آن .p7b یا .p7c است. گواهینامه‌های P7B حاوی -----BEGIN PKCS7----- و -----END PKCS7----- بیانیه است. فایل P7B فقط حاوی گواهینامه‌ها و گواهینامه‌های زنجیره‌ای است، نه کلید خصوصی.
PEM	قالب «پست الکترونیکی با حریم خصوصی بهبودیافته» (PEM) قالبی نوشتاری مبتنی بر ASCII است که کدبندی Base64 قالب باینری «قوانین کدبندی متمایز» (DER) است. گواهینامه‌های PEM را می‌توان در هر «ویرایشگر نوشتار» باز کرد و محتوای گواهینامه واقعی بین عبارت‌های -----BEGIN CERTIFICATE----- و -----END CERTIFICATE----- محدود می‌شود. این قالب با قالب X.509 برای ذخیره گواهینامه، زنجیره گواهینامه، یا کلید خصوصی مطابقت دارد. اگر گواهی یا کلید خصوصی شما با فایل PEM تعریف نشده است، می‌توانید آن را بااستفاده از ابزارهایی مثل OpenSSL به فایل PEM تبدیل کنید.
‫PKCS #12/PFX	قالب PKCS ‎ #12 یا PFX قالبی دودویی برای ذخیره گواهی سرور، هرگونه گواهی واسطه، و کلید خصوصی در یک فایل رمزگذاری‌شدنی است. فایل‌های PFX معمولاً پسوندهایی مثل ‎ .pfx و ‎ .p12 دارند. فایل‌های PFX معمولاً در ماشین‌های Windows برای وارد کردن و صادر کردن گواهینامه‌ها و کلیدهای خصوصی استفاده می‌شوند.
کلید خصوصی	در سرور «امنیت لایه انتقال» برای رمزگشایی داده‌ها استفاده می‌شود. فقط سرور TLS کلید خصوصی را دارد—این کلید با کارخواه‌های TLS هم‌رسانی نمی‌شود.
کلید عمومی	برای رمزگذاری داده‌های ارسالی از کارخواه «امنیت لایه انتقال» به سرور «امنیت لایه انتقال» استفاده می‌شود. کلید عمومی در گواهینامه گنجانده شده است. همه کارخواه‌های «امنیت لایه انتقال» نسخه‌ای از کلید عمومی سرور دارند.
مرجع‌ها	ارجاع‌ها سطح غیرمستقیمی برای مخزن کلیدها فراهم می‌کنند؛ بنابراین، تغییرات مخزن کلیدها تا زمانی که همان ارجاع و نام مستعار کلید حفظ شود، نیازی به به‌روزرسانی میزبان مجازی ندارد. این امر به شما امکان می‌دهد این تغییرات را خودتان انجام دهید و وابستگی‌های خود را به تیم پشتیبانی Apigee کاهش دهید.
گواهینامه خودامضا	گواهینامه‌ای که توسط «مرجع صدور گواهی» معتمد امضا نشده باشد. صادرکننده و موضوع یکسان باشند؛ با کلید خصوصی که با کلید عمومی موجود در آن‌ها مطابقت دارد امضا شده باشند.
SNI	Server Name Indication (اعلام نام سرور). به چندین هدف HTTPS اجازه می‌دهد تا از همان نشانی IP و درگاه ارائه شوند بدون اینکه نیاز باشد آن اهداف از گواهینامه یکسانی استفاده کنند.
گواهینامه TLS	فایل دیجیتالی که نهادی را در تراکنش «امنیت لایه انتقال» شناسایی می‌کند. بسته به پیکربندی «امنیت لایه انتقال»، می‌توان از گواهینامه یا cert برای شناسایی سرور «امنیت لایه انتقال» و کارخواه «امنیت لایه انتقال» استفاده کرد.
مخزن مطمئن	حاوی گواهینامه‌های مطمئن در کارخواه امنیت لایه انتقال است که برای اعتبارسنجی گواهینامه سرور امنیت لایه انتقال ارائه‌شده به کارخواه استفاده می‌شود. این گواهینامه‌ها معمولاً گواهینامه‌های خودامضا یا گواهینامه‌هایی هستند که توسط یک مرجع صدور گواهینامه مورد اعتماد امضا نشده‌اند. در اتصال شمالی، گواهینامه‌های برنامه کارخواه در truststore در Apigee Edge ذخیره می‌شود. این کار فقط درصورتی لازم است که «امنیت لایه انتقال» دوطرفه بین کارخواه و Apigee پیکربندی کرده باشید. در اتصال جنوبی، گواهی‌های سرور پشتیبان در truststore در Apigee Edge ذخیره می‌شود. اگر بخواهید گواهینامه زیرینه را در Apigee Edge در ارتباط TLS یک‌طرفه یا دوطرفه بین Apigee Edge و سرور زیرینه درستی‌سنجی کنید، این کار لازم است. ‫Apigee Edge شیء truststore جداگانه‌ای ندارد. بنابراین، فروشگاه‌های مطمئن به‌صورت شیء فروشگاه کلید ایجاد می‌شوند، اما هرجا استفاده شوند (برای مثال، در میزبان مجازی، نقطه‌های پایانی هدف، سرورهای هدف، و غیره) به‌عنوان فروشگاه مطمئن ارجاع داده می‌شوند.
میزبان مجازی	میزبان مجازی نقطه پایان Apigee API را برای برنامه‌های مشتری نشان می‌دهد. این نهادی است که در میزبانی چندین نام دامنه ( با مدیریت جداگانه هر نام) در یک سرور (یا گروهی از سرورها) کمک می‌کند. این کار به یک سرور اجازه می‌دهد منابع خود، مانند حافظه و دوره‌های پردازنده، را بدون نیاز به استفاده از نام میزبان یکسان برای همه خدمات ارائه‌شده، هم‌رسانی کند. میزبان مجازی می‌تواند ترافیک HTTP یا HTTPS (فعال‌شده با SSL) را ارائه دهد. میزبان مجازی فعال‌شده با SSL می‌تواند در حالت یک‌طرفه یا دوطرفه TLS پیکربندی شود. با موارد زیر پیکربندی شده است: یک یا چند نام مستعار میزبان (نام ساناد نقطه پایانی API). درگاه Keystore نام مستعار کلید برای شناسایی یکتای یکی از گواهینامه‌های سرور در محل ذخیره کلید. درصورت تمایل، یک فروشگاه مطمئن (در «امنیت لایه انتقال» دوطرفه، جایی که اصالت‌سنجی کارخواه فعال است).

‫TLS/SSL یک‌طرفه

شکل زیر دست دادن «امنیت لایه انتقال»/ پوسته ایمن را برای اصالت‌سنجی یک‌طرفه بین کارخواه «امنیت لایه انتقال» و سرور «امنیت لایه انتقال» نشان می‌دهد:

در پیکربندی یک‌طرفه «امنیت لایه انتقال»، دست‌دهی به‌صورت زیر است:

• کارخواه درخواست جلسه را به سرور ارسال می‌کند.
• سرور با گواهینامه‌ای که حاوی کلید عمومی آن است پاسخ می‌دهد. این گواهینامه از انبار کلید سرور می‌آید که حاوی کلید خصوصی سرور نیز هست. کلید خصوصی هرگز به کارخواه ارسال نمی‌شود.
• برای گواهی امضاشده، کارخواه از یک مخزن اعتماد حاوی گواهینامه‌های سرور و کلیدهای عمومی استفاده می‌کند تا تأیید کند که زنجیره گواهینامه توسط یک «مرجع صدور گواهی» (CA) مورداعتماد امضا شده است.
• کارخواه و سرور چندین پیام دیگر برای اعتبارسنجی کلیدها مبادله می‌کنند.
• سرویس‌گیرنده انتقال داده «امنیت لایه انتقال» را با سرور شروع می‌کند.

شکل زیر دست دادن TLS/SSL را بااستفاده از یک فروشگاه اعتماد اختیاری در کارخواه نشان می‌دهد:

اگر سرور «امنیت لایه انتقال» از گواهینامه خودامضایی یا گواهینامه‌ای که توسط «مرجع گواهینامه» مورداعتماد امضا نشده است استفاده می‌کند، در کارخواه یک truststore ایجاد می‌کنید. سرویس‌گیرنده فروشگاه اعتماد خود را با گواهی‌های سرور و کلیدهای عمومی مورد اعتماد خود تکمیل می‌کند. وقتی کارخواه گواهینامه‌ای دریافت می‌کند، گواهینامه ورودی با گواهینامه‌های موجود در مخزن اعتماد آن اعتبارسنجی می‌شود.

در «امنیت لایه انتقال» یک‌طرفه، Edge می‌تواند سرور یا کارخواه باشد، به این صورت:

• ‫Edge به‌عنوان سرور «امنیت لایه انتقال»

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

• ‫Edge به‌عنوان کارخواه «امنیت لایه انتقال»

  ‫Edge به‌عنوان کارخواهی عمل می‌کند که به سرویس زیرینه دسترسی دارد. در این مورد، سرویس زیرینه با سروری که نقطه پایانی TLS را میزبانی می‌کند مطابقت دارد. بنابراین، سرور زیرینه یک keystore دارد که حاوی گواهی و کلید خصوصی آن است.

«امنیت لایه انتقال» دوطرفه

شکل زیر دست دادن «امنیت لایه انتقال»/ پوسته ایمن را برای اصالت‌سنجی «امنیت لایه انتقال» دوطرفه بین کارخواه و سرور نشان می‌دهد:

در TLS دوطرفه، دست‌دهی به‌صورت زیر است:

• کارخواه و سرور هر دو فروشگاه کلید خودشان را دارند. حافظه کلید کارخواه حاوی گواهینامه و کلید خصوصی آن است و حافظه کلید سرور حاوی گواهینامه و کلید خصوصی آن است.
• سرور «امنیت لایه انتقال» گواهینامه‌اش را به کارخواه «امنیت لایه انتقال» ارائه می‌دهد تا اصالت خود را تأیید کند. سپس کارخواه قبل‌از ارسال گواهینامه‌اش به سرور، هویت سرور را درستی‌سنجی می‌کند.
• کارخواه «امنیت لایه انتقال» گواهینامه‌اش را به سرور «امنیت لایه انتقال» ارائه می‌کند تا اصالت خود را به سرور ثابت کند.

شکل زیر دست‌دهی TLS را بااستفاده از یک فروشگاه اعتماد اختیاری نشان می‌دهد:

در این سناریو، دست دادن به این صورت است:

• اگر سرور «امنیت لایه انتقال» از گواهینامه خودامضایی یا گواهینامه‌ای استفاده می‌کند که توسط «مرکز صدور گواهینامه» مطمئن امضا نشده است، در کارخواه «انبار مطمئن» ایجاد می‌کنید. کارخواه نسخه‌ای از گواهینامه سرور را در مخزن اعتماد خود دارد. درطول دست دادن «امنیت لایه انتقال»، کارخواه گواهی موجود در فروشگاه اعتماد خود را با گواهی ارسالی از سرور مقایسه می‌کند تا هویت سرور را درستی‌سنجی کند.
• اگر کارخواه «امنیت لایه انتقال» از گواهینامه خودامضایی یا گواهینامه‌ای که توسط «مرکز صدور گواهینامه» مطمئنی امضا نشده است استفاده کند، در سرور یک truststore ایجاد می‌کنید.سرور نسخه‌ای از گواهینامه کارخواه را در truststore خود دارد. درطول دست دادن TLS، سرور گواهینامه موجود در انبار اعتماد خود را با گواهینامه ارسالی از کارخواه مقایسه می‌کند تا هویت کارخواه را درستی‌سنجی کند.

کارخواه یا سرور یا هر دو می‌توانند از مخزن اعتماد استفاده کنند.

در TLS دوطرفه، Edge می‌تواند هم سرور و هم کارخواه باشد، به این صورت:

• Edge به‌عنوان سرور

  ‫Edge سروری است که نقطه پایانی TLS را میزبانی می‌کند، جایی که نقطه پایانی TLS با یک پراکسی API مطابقت دارد. کارخواه برنامه‌ای است که تلاش می‌کند به پراکسی API دسترسی پیدا کند. در این سناریو، Edge یک انبار کلید دارد که حاوی گواهی و کلید خصوصی است و به یک انبار اعتماد نیاز دارد که حاوی گواهی سرویس‌گیرنده و زنجیره «مرجع صدور گواهی» است.

• ‫Edge به‌عنوان کارخواه

  ‫Edge به‌عنوان کارخواهی عمل می‌کند که به سرویس زیرینه دسترسی دارد. در این مورد، سرویس زیرینه با سروری که نقطه پایانی TLS را میزبانی می‌کند مطابقت دارد. بنابراین، سرور زیرینه یک keystore دارد که حاوی گواهی و کلید خصوصی آن است.

  ‫Edge همچنین باید یک انبار کلید تعریف کند که حاوی گواهینامه موردنیاز برای اعتبارسنجی خود در سرویس زیرینه باشد، و به‌صورت اختیاری یک انبار اعتماد حاوی گواهینامه سرور زیرینه درصورتی‌که سرور از گواهینامه خودامضا یا گواهینامه‌ای که توسط «مرکز صدور گواهینامه» مورداعتماد امضا نشده است استفاده کند.

نکته مهمی که باید به‌خاطر داشته باشید این است که Edge به‌اندازه کافی انعطاف‌پذیر است تا از TLS دوطرفه صرف‌نظر از اینکه چگونه آن را پیکربندی می‌کنید پشتیبانی کند.

پشتیبانی SNI

‫Edge از استفاده از «نشان نام سرور» (SNI) از پراکسی‌های API به Edge پشتیبانی می‌کند، در این حالت Edge به‌عنوان سرور TLS عمل می‌کند، و از Edge به نقاط پایانی هدف، در این حالت Edge به‌عنوان کارخواه TLS عمل می‌کند، در هر دو نصب Cloud و Private Cloud.

با SNI، که افزونه‌ای از TLS/SSL است، چندین هدف HTTPS می‌توانند از همان نشانی IP و درگاه بدون نیاز به استفاده از گواهینامه یکسان ارائه شوند.

برای کسب اطلاعات درباره فعال کردن SNI برای نصب در محل، به استفاده از SNI با Edge مراجعه کنید.

به‌سمت شمال و جنوب

در Apigee، «شمالی» به نقطه پایان API اشاره دارد که برنامه‌های کارخواه برای فراخوانی «پراکسی API» استفاده می‌کنند. معمولاً «مسیریاب» نقطه ورود در Apigee Edge است و درخواست‌های ورودی به Apigee Edge را مدیریت می‌کند. بنابراین در Apigee، نقطه پایانی که برای ارتباط بین برنامه مشتری و Apigee Edge (مسیریاب) استفاده می‌شود به‌عنوان شمالی نامیده می‌شود.

در Apigee، «جنوبی» به نقطه پایانی هدفی اشاره دارد که Apigee برای ارتباط با سرور پشتیبان استفاده می‌کند. بنابراین در Apigee، نقطه پایانی که برای ارتباط بین Apigee Edge (پردازشگر پیام) و سرور زیرینه استفاده می‌شود به‌عنوان جنوبی نامیده می‌شود. «پردازشگر پیام» یکی از اجزای Apigee Edge است که درخواست‌های API را به سرورهای هدف زیرینه پراکسی می‌کند.

شکل زیر اتصالات شمالی و جنوبی را برای Apigee Edge نشان می‌دهد: