شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات
امنیت لایه حمل و نقل (TLS)، که سلف آن لایه سوکت های امن (SSL) است، فناوری امنیتی استاندارد برای ایجاد یک پیوند رمزگذاری شده بین یک وب سرور و یک سرویس گیرنده وب، مانند یک مرورگر یا یک برنامه است. یک پیوند رمزگذاری شده تضمین می کند که تمام داده های منتقل شده بین سرور و مشتری خصوصی باقی می مانند. برای استفاده از TLS، یک کلاینت با استفاده از پروتکل HTTPS رمزگذاری شده، به جای پروتکل HTTP رمزگذاری نشده، درخواست ایمن از سرور می کند.
Edge از TLS یک طرفه و TLS دو طرفه هم در فضای ابری و هم در استقرار داخلی پشتیبانی می کند (برای نسخه های پشتیبانی شده TLS به نرم افزار پشتیبانی شده و نسخه های پشتیبانی شده مراجعه کنید). TLS یک طرفه به مشتری TLS امکان می دهد هویت سرور TLS را تأیید کند. به عنوان مثال، یک برنامه در حال اجرا بر روی یک تلفن Android (کلینت) می تواند هویت API های Edge (سرور) را تأیید کند.
Apigee همچنین از نوع قوی‌تری از احراز هویت با استفاده از TLS دو طرفه یا کلاینت پشتیبانی می‌کند. شما معمولاً TLS دو طرفه را برای افزایش امنیت سرتاسر و محافظت از داده‌های خود در برابر حملات کلاینت مانند جعل کلاینت یا حملات انسان در میان پیاده‌سازی می‌کنید. در TLS دو طرفه، مشتری هویت سرور را تأیید می کند و سپس سرور هویت مشتری را تأیید می کند.
اصطلاحات TLS
قبل از پیکربندی TLS باید با اصطلاحات و مفاهیم مهم زیر آشنا باشید:
مدت | تعریف |
|---|---|
CA | مرجع صدور گواهی. یک نهاد مورد اعتماد، مانند Symantec یا VeriSign، برای صدور گواهینامه ها و تأیید اعتبار یک گواهی استفاده می شود. یکی از انواع گواهینامه ها که گواهی نامه خود امضا نامیده می شود، به CA نیاز ندارد. |
زنجیره گواهی | اغلب شما گواهی امضا شده توسط کلید خصوصی ریشه CA خود را ندارید. در عوض، شما گواهینامه خود را به همراه یک یا چند گواهی میانی دارید که یک زنجیره را تشکیل می دهند. آخرین گواهی میانی در زنجیره معمولاً توسط کلید خصوصی ریشه CA امضا می شود. |
CSR | درخواست امضای گواهی CSR فایلی است که بر روی سرور TLS بر اساس کلید خصوصی تولید می شود. CSR حاوی کلید عمومی و اطلاعات دیگری مانند نام سازمان، مکان و نام دامنه است. CA برای ایجاد گواهی TLS، CSR را امضا می کند. شما معمولاً زمانی یک CSR ایجاد می کنید که گواهی منقضی شده ای داشته باشید و بخواهید آن را تمدید کنید. |
| DER | قوانین رمزگذاری ممتاز فرمت DER به جای فرمت ASCII PEM یک فرم باینری از یک گواهی است. گاهی اوقات پسوند فایل .der دارد اما اغلب پسوند فایل cer. تنها راه برای تشخیص تفاوت بین فایل DER .cer و فایل PEM .cer این است که فایل را در یک ویرایشگر متن باز کنید و به دنبال دستور |
| نام مستعار کلیدی | یک نام مستعار کلید به طور منحصربه‌فردی یک ورودی فروشگاه کلید (گواهی TLS و کلید خصوصی مربوطه) را در فروشگاه کلید شناسایی می‌کند. در Apigee Edge، هنگامی که گواهی/کلید را با استفاده از UI یا API در فروشگاه‌های کلید آپلود می‌کنید، |
فروشگاه کلید | فروشگاه کلید مخزنی است که حاوی یک یا چند گواهی TLS و یک کلید خصوصی مربوطه است که برای شناسایی موجودیت در طی یک دست دادن TLS بین مشتری و سرور استفاده می شود. در اتصال شمال ، روتر به عنوان سرور عمل می کند و گواهی آن در فروشگاه کلید در Apigee Edge ذخیره می شود. در اتصال به جنوب ، پردازشگر پیام به عنوان مشتری و سرور باطن به عنوان سرور عمل می کند. گواهی مشتری و کلید خصوصی آن در فروشگاه کلید در Apigee Edge ذخیره می شود. |
| P7B | فرمت PKCS #7 یا P7B معمولاً در قالب Base64 ASCII ذخیره می شود و پسوند فایل p7b یا p7c. است. گواهی‌های P7B حاوی عبارت‌های |
PEM | فرمت نامه ارتقا یافته حریم خصوصی (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 یک کپی از کلید عمومی سرور دارند. |
| مراجع | مراجع سطحی از غیر جهت را برای ذخیره‌سازی کلید فراهم می‌کنند. بنابراین، تا زمانی که همان مرجع و نام مستعار کلید حفظ شود، تغییرات فروشگاه کلید نیازی به به‌روزرسانی میزبان مجازی ندارد. این به شما این امکان را می دهد که با تیم پشتیبانی Apigee به این تغییرات خود خدمت کنید و وابستگی ها را کاهش دهید. |
گواهی خود امضا شده | گواهینامه ای که توسط یک CA قابل اعتماد امضا نشده است. صادرکننده و موضوع یکسان هستند. آنها با کلید خصوصی مطابق با کلید عمومی آنها امضا می شوند. |
SNI | نشانگر نام سرور به چندین هدف HTTPS اجازه می‌دهد تا از یک آدرس IP و پورت یکسان بدون نیاز به استفاده از یک گواهی توسط آن اهداف استفاده شود. |
گواهی TLS | یک فایل دیجیتالی که یک موجودیت را در یک تراکنش TLS شناسایی می کند. بسته به پیکربندی TLS می توان از یک گواهی یا گواهی برای شناسایی سرور TLS و کلاینت TLS استفاده کرد. |
فروشگاه اعتماد | حاوی گواهی های قابل اعتماد در یک کلاینت TLS است که برای تأیید اعتبار گواهی سرور TLS ارائه شده به مشتری استفاده می شود. این گواهی‌ها معمولاً گواهی‌هایی هستند که خود امضا می‌کنند یا گواهی‌هایی که توسط یک CA مورد اعتماد امضا نشده‌اند. در اتصال شمال ، گواهی‌های برنامه مشتری در Truststore در Apigee Edge ذخیره می‌شوند. این فقط در صورتی لازم است که یک TLS دو طرفه را بین مشتری و Apigee پیکربندی کرده باشید. در اتصال به جنوب ، گواهی‌های سرور باطن در Truststore در Apigee Edge ذخیره می‌شوند. اگر می‌خواهید گواهی پشتیبان را در Apigee Edge در ارتباط TLS یک طرفه یا دو طرفه بین Apigee Edge و سرور باطن تأیید کنید، لازم است. Apigee Edge یک شیء Truststore مجزا ندارد. بنابراین، Truststores به‌عنوان یک شی ذخیره‌سازی کلید ایجاد می‌شوند، اما در هر کجا که استفاده می‌شود به عنوان Truststore ارجاع داده می‌شود (مثلاً در میزبان مجازی، نقاط پایانی هدف، سرورهای هدف و غیره). |
| میزبان مجازی | میزبان مجازی نقطه پایانی Apigee API را برای برنامه های مشتری نشان می دهد. این موجودیتی است که به میزبانی چندین نام دامنه (با مدیریت جداگانه هر نام) روی یک سرور واحد (یا مجموعه ای از سرورها) کمک می کند. این به یک سرور اجازه می‌دهد تا منابع خود، مانند چرخه‌های حافظه و پردازنده را بدون نیاز به استفاده از نام میزبان یکسان، به اشتراک بگذارد. یک میزبان مجازی می تواند ترافیک HTTP یا HTTPS (فعال SSL) را ارائه دهد. یک میزبان مجازی دارای SSL را می توان در حالت TLS یک طرفه یا دو طرفه پیکربندی کرد. با موارد زیر پیکربندی شده است:
|
TLS/SSL یک طرفه
شکل زیر دست دادن TLS/SSL را برای احراز هویت یک طرفه بین کلاینت TLS و سرور TLS نشان می دهد:
در پیکربندی TLS یک طرفه، دست دادن به شرح زیر است:
- مشتری یک درخواست جلسه را به سرور ارسال می کند.
- سرور با یک گواهی پاسخ می دهد که حاوی کلید عمومی آن است. این گواهی از فروشگاه کلید سرور می آید که حاوی کلید خصوصی سرور نیز می باشد. کلید خصوصی هرگز برای مشتری ارسال نمی شود.
- برای یک گواهی امضا شده، مشتری از یک Truststore حاوی گواهی‌های سرور و کلیدهای عمومی استفاده می‌کند تا تأیید کند که زنجیره گواهی توسط یک مرجع گواهی معتبر (CA) امضا شده است.
- سرویس گیرنده و سرور چندین پیام دیگر را برای اعتبارسنجی کلیدها مبادله می کنند.
- کلاینت انتقال داده TLS را با سرور آغاز می کند.
شکل زیر دست دادن TLS/SSL را با استفاده از یک Truststore اختیاری روی کلاینت نشان می دهد:
اگر سرور TLS از گواهی خودامضا یا گواهینامه ای استفاده می کند که توسط یک CA قابل اعتماد امضا نشده است، شما یک Truststore در مشتری ایجاد می کنید. کلاینت فروشگاه اعتماد خود را با گواهی های سرور و کلیدهای عمومی که به آنها اعتماد دارد پر می کند. هنگامی که مشتری یک گواهی را دریافت می کند، گواهی دریافتی پس از آن در برابر گواهی های موجود در فروشگاه اعتماد آن تایید می شود.
در TLS یک طرفه، Edge می تواند سرور یا کلاینت به شرح زیر باشد:
Edge به عنوان سرور TLS
Edge سروری است که نقطه پایانی TLS را میزبانی می کند، جایی که نقطه پایانی TLS مربوط به یک پروکسی API است که در یک میزبان مجازی مستقر شده است. کلاینت اپلیکیشنی است که تلاش می کند به پروکسی API دسترسی پیدا کند. در این سناریو، Edge دارای فروشگاه کلید حاوی گواهی و کلید خصوصی است.
Edge به عنوان مشتری TLS
Edge به عنوان کلاینتی عمل می کند که به یک سرویس Backend دسترسی پیدا می کند. در این مورد، سرویس Backend مربوط به سروری است که یک نقطه پایانی TLS را میزبانی می کند. بنابراین سرور باطن دارای یک فروشگاه کلید است که حاوی گواهینامه و کلید خصوصی آن است.
TLS دو طرفه
شکل زیر دست دادن TLS/SSL را برای احراز هویت دو طرفه TLS بین مشتری و سرور نشان می دهد:
در TLS دو طرفه، دست دادن به شرح زیر است:
- کلاینت و سرور هر دو کلیدهای مخصوص به خود را دارند. فروشگاه کلید کلاینت شامل گواهی و کلید خصوصی آن و فروشگاه کلید سرور حاوی کلید گواهی و کلید خصوصی آن است.
- سرور TLS گواهینامه خود را به مشتری TLS ارائه می کند تا خود را احراز هویت کند. سپس مشتری هویت سرور را قبل از ارسال گواهی آن به سرور تأیید می کند.
- کلاینت TLS گواهینامه خود را به سرور TLS ارائه می کند تا خود را به سرور احراز هویت کند.
شکل زیر دست دادن TLS را با استفاده از یک Truststore اختیاری نشان می دهد:
در این سناریو، دست دادن به شرح زیر است:
- اگر سرور TLS از گواهی خودامضا یا گواهینامه‌ای استفاده می‌کند که توسط یک CA قابل اعتماد امضا نشده است، یک Truststore در مشتری ایجاد می‌کنید. مشتری یک کپی از گواهی سرور در فروشگاه اعتماد خود دارد. در طول دست دادن TLS، مشتری گواهی موجود در فروشگاه اعتماد خود را با گواهی ارسال شده از سرور مقایسه می کند تا هویت سرور را تأیید کند.
- اگر سرویس گیرنده TLS از گواهی خودامضا یا گواهینامه ای استفاده می کند که توسط یک CA قابل اعتماد امضا نشده است، شما یک Truststore در سرور ایجاد می کنید. سرور یک کپی از گواهی مشتری در Truststore خود دارد. در طول دست دادن TLS، سرور گواهی را در فروشگاه اعتماد خود با گواهی ارسال شده از مشتری مقایسه می کند تا هویت مشتری را تأیید کند.
مشتری یا سرور یا هر دو می توانند از یک Truststore استفاده کنند.
در TLS دو طرفه، Edge می تواند سرور یا کلاینت به شرح زیر باشد:
Edge به عنوان سرور
Edge سروری است که نقطه پایانی TLS را میزبانی می کند، جایی که نقطه پایانی TLS با یک پروکسی API مطابقت دارد. کلاینت اپلیکیشنی است که تلاش می کند به پروکسی API دسترسی پیدا کند. در این سناریو، Edge دارای یک فروشگاه کلید حاوی گواهی و کلید خصوصی است و به یک Truststore حاوی گواهی مشتری و زنجیره CA نیاز دارد.
لبه به عنوان مشتری
Edge به عنوان یک کلاینت عمل می کند که به یک سرویس Backend دسترسی دارد. در این مورد، سرویس Backend مربوط به سروری است که نقطه پایانی TLS را میزبانی می کند. بنابراین سرور باطن دارای یک فروشگاه کلید است که حاوی گواهینامه و کلید خصوصی آن است.
Edge همچنین باید یک keystore که حاوی گواهی مورد نیاز برای اعتبار سنجی خود به سرویس Backend باشد، و در صورت استفاده از سرور از گواهی خودامضا یا گواهینامه‌ای که توسط یک CA مورد اعتماد امضا نشده است، یک Truststore حاوی گواهی از سرور backend نیز تعریف کند. .
نکته مهمی که باید به خاطر داشته باشید این است که Edge به اندازه کافی انعطاف پذیر است تا از 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 استفاده می شود. به طور معمول روتر نقطه ورود در Apigee Edge است و درخواست های دریافتی به Apigee Edge را مدیریت می کند. بنابراین در Apigee، نقطه پایانی مورد استفاده برای ارتباط بین برنامه مشتری و Apigee Edge (روتر) به عنوان Northbound نامیده می شود.
در Apigee، Southbound به نقطه پایانی هدفی اشاره دارد که Apigee برای برقراری ارتباط با سرور باطن استفاده می‌کند. بنابراین در Apigee، نقطه پایانی مورد استفاده برای ارتباط بین Apigee Edge (پردازنده پیام) و سرور backend به عنوان Southbound نامیده می شود. پردازشگر پیام یکی از اجزای Apigee Edge است که درخواست‌های API را برای سرورهای هدف پشتیبان پراکسی می‌کند.
شکل زیر اتصالات شمال و جنوب Apigee Edge را نشان می دهد:
