شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات
مطابقت HIPAA با Apigee Edge
اطمینان از ایمن بودن، ایمن بودن و همیشه در دسترس بودن داده های مشتریان یکی از اولویت های اصلی ما است. برای نشان دادن انطباق ما با استانداردهای امنیتی در صنعت، Google به دنبال و دریافت گواهینامه های امنیتی مانند گواهینامه ISO 27001 و ممیزی های SOC 2 و SOC 3 نوع II است. برای مشتریانی که مشمول الزامات قانون مسئولیت‌پذیری و مسئولیت‌پذیری بیمه سلامت (HIPAA) هستند، Apigee Edge می‌تواند از انطباق با HIPAA نیز پشتیبانی کند.
تحت HIPAA، اطلاعات خاصی در مورد خدمات بهداشتی یا مراقبت های بهداشتی یک فرد به عنوان اطلاعات بهداشتی محافظت شده (PHI) طبقه بندی می شود. مشتریان Apigee Edge که مشمول HIPAA هستند و مایل به استفاده از Apigee Edge با PHI هستند، باید یک قرارداد همکاری تجاری (BAA) با Google امضا کنند.
مشتریان Apigee Edge مسئول تعیین اینکه آیا مشمول الزامات HIPAA هستند و اینکه آیا از خدمات Google در ارتباط با PHI استفاده می‌کنند یا قصد استفاده از آن را دارند، هستند. مشتریانی که BAA را با Google امضا نکرده اند، نباید از خدمات Google در ارتباط با PHI استفاده کنند.
مدیران باید قبل از استفاده از خدمات Google با PHI، یک BAA را بررسی کرده و بپذیرند.
ما راهنمای پیکربندی Apigee HIPAA خود را در این مبحث منتشر کرده‌ایم تا به مشتریان در درک نحوه سازماندهی داده‌ها در سرویس‌های Google در هنگام مدیریت PHI کمک کنیم. این راهنما برای کارمندان سازمان‌هایی در نظر گرفته شده است که مسئولیت اجرای HIPAA و مطابقت با Apigee Edge را بر عهده دارند.
راهنمای پیکربندی HIPAA برای Edge Public Cloud
این راهنما فقط برای مقاصد اطلاعاتی است. Apigee قصد ندارد اطلاعات یا توصیه های این راهنما به منزله مشاوره حقوقی باشد. هر مشتری مسئول ارزیابی مستقل استفاده خاص خود از خدمات برای حمایت از تعهدات قانونی خود است.
موارد زیر باید توسط مشتریان مشمول قانون قابل حمل و پاسخگویی بیمه سلامت (معروف به HIPAA، اصلاح شده، از جمله توسط فناوری اطلاعات سلامت برای سلامت اقتصادی و بالینی — قانون HITECH) که بسته مطابقت HIPAA را خریداری کرده اند، بررسی شود. این موارد در Edge سلف سرویس هستند و می توانند به سازمان مشتری (org) در انجام تعهدات مطابق با HIPAA کمک کنند. مفهوم کلی این است که "گوگل پلتفرم را ایمن می کند، مشتری داده های خود را ایمن می کند."
| الزامات HIPAA | بخش ها |
|---|---|
| مطابقت HIPAA: امنیت - کنترل دسترسی | استفاده/مجوزها |
| انطباق با HIPAA: فرآیند مدیریت امنیت - بررسی فعالیت سیستم اطلاعات | دنباله حسابرسی |
| انطباق با HIPAA: مدیریت رمز عبور امنیتی | الزامات رمز عبور پیچیده یا SAML |
| انطباق با HIPAA: امنیت - فرآیند مدیریت امنیت | اسکن نقطه پایانی |
| مطابقت HIPAA: امنیت - انتقال | پیکربندی TLS |
ردیابی / اشکال زدایی
Trace/Debug یک ابزار عیب‌یابی است که به کاربر امکان می‌دهد وضعیت و محتوای یک تماس API را همانطور که از طریق پردازشگر پیام Apigee پردازش می‌شود، مشاهده کند. Trace و Debug دو نام برای یک سرویس هستند اما از طریق مکانیسم‌های مختلف قابل دسترسی هستند. Trace نام این سرویس در داخل رابط کاربری Edge است. Debug نام همان سرویس است که از طریق تماس های API استفاده می شود. استفاده از عبارت Trace در این سند برای Trace و Debug معتبر است.
در طول یک جلسه Trace، اگر توسط مشتری فعال و پیکربندی شده باشد، "Data masking" اعمال می شود. این ابزار می تواند از نمایش داده ها در طول Trace جلوگیری کند. بخش پوشش داده ها را در زیر ببینید.
نقشه‌های ارزش کلیدی رمزگذاری شده (KVM) برای مشتریانی استفاده می‌شود که به انطباق با HIPAA نیاز دارند. با استفاده از KVM رمزگذاری شده، Trace ممکن است همچنان استفاده شود، اما برخی از متغیرها در صفحه نمایش Trace قابل مشاهده نخواهند بود. ممکن است اقدامات اضافی برای نمایش این متغیرها در طول Trace انجام شود.
دستورالعمل های دقیق در مورد استفاده از Trace در استفاده از ابزار Trace موجود است.
جزئیات مربوط به KVM ها، از جمله KVM های رمزگذاری شده در نقشه های کار با مقادیر کلیدی موجود است.
استفاده/مجوزها
دسترسی به Trace از طریق سیستم RBAC (کنترل دسترسی مبتنی بر نقش) برای حساب‌های کاربری در Edge مدیریت می‌شود ( انطباق HIPAA: امنیت - کنترل دسترسی ). دستورالعمل‌های دقیق در مورد استفاده از سیستم RBAC برای دادن و لغو امتیازات Trace در بخش اختصاص نقش‌ها و ایجاد نقش‌های سفارشی در رابط کاربری موجود است. مجوزهای Trace به کاربر این امکان را می دهد که یک Trace را راه اندازی کند، یک Trace را متوقف کند، و به خروجی یک جلسه Trace دسترسی داشته باشد.
از آنجایی که Trace به محموله تماس‌های API (که به طور رسمی «متن پیام» نامیده می‌شود) دسترسی دارد، مهم است که در نظر بگیرید چه کسی برای اجرای Trace دسترسی دارد. از آنجا که مدیریت کاربر یک مسئولیت مشتری است، اعطای مجوزهای Trace نیز مسئولیت مشتری است. Apigee، به عنوان مالک پلتفرم، توانایی اضافه کردن کاربر به سازمان مشتری و اختصاص امتیازات را دارد. این توانایی تنها در صورت درخواست مشتری برای پشتیبانی در شرایطی استفاده می‌شود که به نظر می‌رسد خدمات مشتری شکست می‌خورد و تصور می‌شود که بررسی جلسه Trace بهترین اطلاعات را در مورد علت اصلی ارائه می‌دهد.
پوشش داده ها
پوشاندن داده از نمایش داده‌های حساس فقط در طول جلسه Trace/Debug، هم در Trace (Edge UI) و هم در Backend توسط Debug (Edge API) جلوگیری می‌کند. جزئیات نحوه تنظیم Masking در Data masking and hiding موجود است.
پوشاندن داده مانع از قابل مشاهده شدن داده ها در فایل های گزارش، حافظه پنهان، تجزیه و تحلیل و غیره نمی شود. برای کمک به پوشاندن داده ها در گزارش ها، اضافه کردن یک الگوی regex به فایل logback.xml را در نظر بگیرید. معمولاً داده‌های حساس نباید بدون توجیه تجاری قوی و بررسی توسط تیم‌های امنیتی و حقوقی شما در حافظه پنهان یا تجزیه و تحلیل نوشته شوند.
حافظه نهان L1 و L2
استفاده از کش L1 به طور خودکار از کش L2 نیز استفاده می کند. کش L1 "فقط حافظه" است در حالی که کش L2 داده ها را روی دیسک می نویسد تا در چند کش L1 همگام شود. حافظه پنهان L2 چیزی است که چندین پردازشگر پیام را در یک منطقه و در سطح جهانی همگام نگه می دارد. در حال حاضر امکان فعال کردن کش L1 بدون وجود حافظه نهان L2 در پشت آن وجود ندارد. حافظه پنهان L2 داده ها را روی دیسک می نویسد تا بتوان آن ها را با سایر پردازشگرهای پیام برای سازمان مشتری همگام سازی کرد. دستورالعمل های دقیق در مورد استفاده از حافظه پنهان در Adding caching and persistence موجود است.
دنباله حسابرسی
مشتریان این توانایی را دارند که دنباله حسابرسی تمام فعالیت‌های اداری انجام شده در سازمان مشتری، از جمله استفاده از Trace ( تطابق با HIPAA: فرآیند مدیریت امنیت - بررسی فعالیت سیستم اطلاعاتی ) را بررسی کنند. دستورالعمل های دقیق در اینجا و در استفاده از ابزار Trace موجود است.
الزامات رمز عبور پیچیده یا SAML
برای مشتریان HIPAA، گذرواژه‌های کاربر برای برآورده کردن الزامات پیشرفته مانند طول، پیچیدگی و طول عمر پیکربندی شده‌اند. ( تطابق با HIPAA: مدیریت رمز عبور امنیتی )
Edge همچنین احراز هویت چند عاملی را ارائه می‌کند که در Enable authentic two-factor برای حساب Apigee شما توضیح داده شده است و SAML که در Enabling SAML Authentication برای Edge توضیح داده شده است، به عنوان جایگزینی برای کنترل‌های احراز هویت ارائه می‌کند.
امنیت نقطه پایانی
اسکن نقطه پایانی
مشتریان Edge Cloud مسئول اسکن و آزمایش نقاط پایانی API خود هستند (که گاهی اوقات "اجزای زمان اجرا" نامیده می شود) در Edge ( تطابق با HIPAA: امنیت - فرآیند مدیریت امنیت ). آزمایش مشتری باید خدمات پراکسی API واقعی میزبانی شده در Edge را پوشش دهد، جایی که ترافیک API قبل از پردازش به Edge ارسال شده و سپس به مرکز داده مشتری تحویل داده می شود. آزمایش منابع مشترک، مانند UI پورتال مدیریت، برای مشتریان منفرد تأیید نشده است (گزارش شخص ثالثی که آزمایش سرویس های مشترک را پوشش می دهد، تحت یک توافق نامه عدم افشا و در صورت درخواست در دسترس مشتریان است).
مشتریان باید، و تشویق می شوند تا نقاط پایانی API خود را آزمایش کنند. توافق شما با Apigee آزمایش نقاط پایانی API شما را ممنوع نمی کند، اما از شما درخواست می کند که رابط کاربری مدیریت مشترک را آزمایش نکنید. اگر چه در صورت نیاز به توضیح بیشتر، لطفاً یک بلیط پشتیبانی را باز کنید که به آزمایش برنامه ریزی شده شما اشاره دارد. اطلاع رسانی به Apigee از قبل قدردانی می شود تا بتوانیم از ترافیک آزمایشی مطلع شویم.
مشتریانی که نقاط پایانی خود را آزمایش می کنند باید به دنبال هر گونه مشکل خاص API، هر گونه مشکل مربوط به خدمات Apigee باشند، و همچنین TLS و سایر موارد قابل تنظیم را بررسی کنند. هر موردی که یافت می شود و مربوط به خدمات Apigee است باید از طریق تیکت پشتیبانی به Apigee اطلاع داده شود.
بیشتر موارد مربوط به نقطه پایانی موارد سلف سرویس مشتری هستند و با بررسی مستندات Edge قابل رفع هستند. اگر مواردی وجود دارد که نحوه رفع آنها مشخص نیست، لطفاً یک درخواست پشتیبانی باز کنید.
پیکربندی TLS
مشتریان مسئول تعریف و پیکربندی نقاط پایانی TLS خود برای پراکسی های API هستند. این یک ویژگی سلف سرویس در Edge است. الزامات مشتری در مورد رمزگذاری، پروتکل و انتخاب الگوریتم به طور گسترده ای متغیر و مختص موارد استفاده فردی است. از آنجایی که Apigee از جزئیات طراحی API و محموله های داده هر مشتری اطلاعی ندارد، مشتریان مسئولیت تعیین رمزگذاری مناسب برای داده های در حال انتقال را دارند ( انطباق HIPAA: امنیت - انتقال) .
دستورالعمل های دقیق در مورد پیکربندی TLS در TLS/SSL موجود است.
ذخیره سازی داده ها
ذخیره سازی داده ها در Edge برای عملکرد صحیح Edge لازم نیست. با این حال، خدماتی برای ذخیره سازی داده ها در Edge وجود دارد. مشتریان ممکن است انتخاب کنند که از حافظه پنهان یا تجزیه و تحلیل برای ذخیره داده استفاده کنند. برای جلوگیری از استفاده تصادفی یا مخرب از سرویس‌های ذخیره‌سازی داده در Edge به روشی غیرمنطبق، بررسی پیکربندی، خط‌مشی‌ها و استقرار توسط مدیران مشتری توصیه می‌شود.
رمزگذاری داده های محموله
ابزارهای رمزگذاری داده ها برای استفاده در داخل Edge به مشتریان ارائه نمی شود. با این حال، مشتریان می توانند قبل از ارسال به Edge، داده ها را رمزگذاری کنند. داده های رمزگذاری شده در محموله (یا متن پیام) مانع از عملکرد Edge نمی شود. اگر داده ها به صورت رمزگذاری شده توسط مشتری دریافت شوند، ممکن است چند خط مشی Edge نتوانند با داده ها تعامل داشته باشند. به عنوان مثال، اگر خود داده برای تغییر در دسترس Edge نباشد، تبدیل امکان پذیر نیست. اما سایر خط‌مشی‌ها و سیاست‌ها و بسته‌های ساخته شده توسط مشتری حتی اگر محموله داده رمزگذاری شده باشد، کار خواهند کرد.
PII در URI ها
پلتفرم تجزیه و تحلیل یکپارچه Apigee (UAP) داده های تحلیلی، از جمله هر PHI یا سایر داده های حساس موجود در شناسه منبع یکنواخت (URI) یک فراخوانی API را به Apigee Edge می گیرد و آن را به مدت 13 ماه حفظ می کند. PHI در URI توسط استانداردهای Fast Healthcare Interoperability Resources (FHIR) پشتیبانی می شود و بنابراین توسط Apigee پشتیبانی می شود. داده های تجزیه و تحلیل در UAP به طور پیش فرض در حالت استراحت رمزگذاری می شوند.
Apigee در حال حاضر پشتیبانی نمی کند:
- پوشاندن داده به UAP
- تغییر چرخه نگهداری
- انصراف از UAP
- حذف URI از جمع آوری داده های UAP
شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات
مطابقت HIPAA با Apigee Edge
اطمینان از ایمن بودن، ایمن بودن و همیشه در دسترس بودن داده های مشتریان یکی از اولویت های اصلی ما است. برای نشان دادن انطباق ما با استانداردهای امنیتی در صنعت، Google به دنبال و دریافت گواهینامه های امنیتی مانند گواهینامه ISO 27001 و ممیزی های SOC 2 و SOC 3 نوع II است. برای مشتریانی که مشمول الزامات قانون مسئولیت‌پذیری و مسئولیت‌پذیری بیمه سلامت (HIPAA) هستند، Apigee Edge می‌تواند از انطباق با HIPAA نیز پشتیبانی کند.
تحت HIPAA، اطلاعات خاصی در مورد خدمات بهداشتی یا مراقبت های بهداشتی یک فرد به عنوان اطلاعات بهداشتی محافظت شده (PHI) طبقه بندی می شود. مشتریان Apigee Edge که مشمول HIPAA هستند و مایل به استفاده از Apigee Edge با PHI هستند، باید یک قرارداد همکاری تجاری (BAA) با Google امضا کنند.
مشتریان Apigee Edge مسئول تعیین اینکه آیا مشمول الزامات HIPAA هستند و اینکه آیا از خدمات Google در ارتباط با PHI استفاده می‌کنند یا قصد استفاده از آن را دارند، هستند. مشتریانی که BAA را با Google امضا نکرده اند، نباید از خدمات Google در ارتباط با PHI استفاده کنند.
مدیران باید قبل از استفاده از خدمات Google با PHI، یک BAA را بررسی کرده و بپذیرند.
ما راهنمای پیکربندی Apigee HIPAA خود را در این مبحث منتشر کرده‌ایم تا به مشتریان در درک نحوه سازماندهی داده‌ها در سرویس‌های Google در هنگام مدیریت PHI کمک کنیم. این راهنما برای کارمندان سازمان‌هایی در نظر گرفته شده است که مسئولیت اجرای HIPAA و مطابقت با Apigee Edge را بر عهده دارند.
راهنمای پیکربندی HIPAA برای Edge Public Cloud
این راهنما فقط برای مقاصد اطلاعاتی است. Apigee قصد ندارد اطلاعات یا توصیه های این راهنما به منزله مشاوره حقوقی باشد. هر مشتری مسئول ارزیابی مستقل استفاده خاص خود از خدمات برای حمایت از تعهدات قانونی خود است.
موارد زیر باید توسط مشتریان مشمول قانون قابل حمل و پاسخگویی بیمه سلامت (معروف به HIPAA، اصلاح شده، از جمله توسط فناوری اطلاعات سلامت برای سلامت اقتصادی و بالینی — قانون HITECH) که بسته مطابقت HIPAA را خریداری کرده اند، بررسی شود. این موارد در Edge سلف سرویس هستند و می توانند به سازمان مشتری (org) در انجام تعهدات مطابق با HIPAA کمک کنند. مفهوم کلی این است که "گوگل پلتفرم را ایمن می کند، مشتری داده های خود را ایمن می کند."
| الزامات HIPAA | بخش ها |
|---|---|
| مطابقت HIPAA: امنیت - کنترل دسترسی | استفاده/مجوزها |
| انطباق با HIPAA: فرآیند مدیریت امنیت - بررسی فعالیت سیستم اطلاعات | دنباله حسابرسی |
| انطباق با HIPAA: مدیریت رمز عبور امنیتی | الزامات رمز عبور پیچیده یا SAML |
| انطباق با HIPAA: امنیت - فرآیند مدیریت امنیت | اسکن نقطه پایانی |
| مطابقت HIPAA: امنیت - انتقال | پیکربندی TLS |
ردیابی / اشکال زدایی
Trace/Debug یک ابزار عیب‌یابی است که به کاربر امکان می‌دهد وضعیت و محتوای یک تماس API را همانطور که از طریق پردازشگر پیام Apigee پردازش می‌شود، مشاهده کند. Trace و Debug دو نام برای یک سرویس هستند اما از طریق مکانیسم‌های مختلف قابل دسترسی هستند. Trace نام این سرویس در داخل رابط کاربری Edge است. Debug نام همان سرویس است که از طریق تماس های API استفاده می شود. استفاده از عبارت Trace در این سند برای Trace و Debug معتبر است.
در طول یک جلسه Trace، اگر توسط مشتری فعال و پیکربندی شده باشد، "Data masking" اعمال می شود. این ابزار می تواند از نمایش داده ها در طول Trace جلوگیری کند. بخش پوشش داده ها را در زیر ببینید.
نقشه‌های ارزش کلیدی رمزگذاری شده (KVM) برای مشتریانی استفاده می‌شود که به انطباق با HIPAA نیاز دارند. با استفاده از KVM رمزگذاری شده، Trace ممکن است همچنان استفاده شود، اما برخی از متغیرها در صفحه نمایش Trace قابل مشاهده نخواهند بود. ممکن است اقدامات اضافی برای نمایش این متغیرها در طول Trace انجام شود.
دستورالعمل های دقیق در مورد استفاده از Trace در استفاده از ابزار Trace موجود است.
جزئیات مربوط به KVM ها، از جمله KVM های رمزگذاری شده در نقشه های کار با مقادیر کلیدی موجود است.
استفاده/مجوزها
دسترسی به Trace از طریق سیستم RBAC (کنترل دسترسی مبتنی بر نقش) برای حساب‌های کاربری در Edge مدیریت می‌شود ( انطباق HIPAA: امنیت - کنترل دسترسی ). دستورالعمل‌های دقیق در مورد استفاده از سیستم RBAC برای دادن و لغو امتیازات Trace در بخش اختصاص نقش‌ها و ایجاد نقش‌های سفارشی در رابط کاربری موجود است. مجوزهای Trace به کاربر این امکان را می دهد که یک Trace را راه اندازی کند، یک Trace را متوقف کند، و به خروجی یک جلسه Trace دسترسی داشته باشد.
از آنجایی که Trace به محموله تماس‌های API (که به طور رسمی «متن پیام» نامیده می‌شود) دسترسی دارد، مهم است که در نظر بگیرید چه کسی برای اجرای Trace دسترسی دارد. از آنجا که مدیریت کاربر یک مسئولیت مشتری است، اعطای مجوزهای Trace نیز مسئولیت مشتری است. Apigee، به عنوان مالک پلتفرم، توانایی اضافه کردن کاربر به سازمان مشتری و اختصاص امتیازات را دارد. این توانایی تنها در صورت درخواست مشتری برای پشتیبانی در شرایطی استفاده می‌شود که به نظر می‌رسد خدمات مشتری شکست می‌خورد و تصور می‌شود که بررسی جلسه Trace بهترین اطلاعات را در مورد علت اصلی ارائه می‌دهد.
پوشش داده ها
پوشاندن داده از نمایش داده‌های حساس فقط در طول جلسه Trace/Debug، هم در Trace (Edge UI) و هم در Backend توسط Debug (Edge API) جلوگیری می‌کند. جزئیات نحوه تنظیم Masking در Data masking and hiding موجود است.
پوشاندن داده مانع از قابل مشاهده شدن داده ها در فایل های گزارش، حافظه پنهان، تجزیه و تحلیل و غیره نمی شود. برای کمک به پوشاندن داده ها در گزارش ها، اضافه کردن یک الگوی regex به فایل logback.xml را در نظر بگیرید. معمولاً داده‌های حساس نباید بدون توجیه تجاری قوی و بررسی توسط تیم‌های امنیتی و حقوقی شما در حافظه پنهان یا تجزیه و تحلیل نوشته شوند.
حافظه نهان L1 و L2
استفاده از کش L1 به طور خودکار از کش L2 نیز استفاده می کند. کش L1 "فقط حافظه" است در حالی که کش L2 داده ها را روی دیسک می نویسد تا در چند کش L1 همگام شود. حافظه پنهان L2 چیزی است که چندین پردازشگر پیام را در یک منطقه و در سطح جهانی همگام نگه می دارد. در حال حاضر امکان فعال کردن کش L1 بدون وجود حافظه نهان L2 در پشت آن وجود ندارد. حافظه پنهان L2 داده ها را روی دیسک می نویسد تا بتوان آن ها را با سایر پردازشگرهای پیام برای سازمان مشتری همگام سازی کرد. دستورالعمل های دقیق در مورد استفاده از حافظه پنهان در Adding caching and persistence موجود است.
دنباله حسابرسی
مشتریان این توانایی را دارند که دنباله حسابرسی تمام فعالیت‌های اداری انجام شده در سازمان مشتری، از جمله استفاده از Trace ( تطابق با HIPAA: فرآیند مدیریت امنیت - بررسی فعالیت سیستم اطلاعاتی ) را بررسی کنند. دستورالعمل های دقیق در اینجا و در استفاده از ابزار Trace موجود است.
الزامات رمز عبور پیچیده یا SAML
برای مشتریان HIPAA، گذرواژه‌های کاربر برای برآورده کردن الزامات پیشرفته مانند طول، پیچیدگی و طول عمر پیکربندی شده‌اند. ( تطابق با HIPAA: مدیریت رمز عبور امنیتی )
Edge همچنین احراز هویت چند عاملی را ارائه می‌کند که در Enable authentic two-factor برای حساب Apigee شما توضیح داده شده است و SAML که در Enabling SAML Authentication برای Edge توضیح داده شده است، به عنوان جایگزینی برای کنترل‌های احراز هویت ارائه می‌کند.
امنیت نقطه پایانی
اسکن نقطه پایانی
مشتریان Edge Cloud مسئول اسکن و آزمایش نقاط پایانی API خود هستند (که گاهی اوقات "اجزای زمان اجرا" نامیده می شود) در Edge ( تطابق با HIPAA: امنیت - فرآیند مدیریت امنیت ). آزمایش مشتری باید خدمات پراکسی API واقعی میزبانی شده در Edge را پوشش دهد، جایی که ترافیک API قبل از پردازش به Edge ارسال شده و سپس به مرکز داده مشتری تحویل داده می شود. آزمایش منابع مشترک، مانند UI پورتال مدیریت، برای مشتریان منفرد تأیید نشده است (گزارش شخص ثالثی که آزمایش سرویس های مشترک را پوشش می دهد، تحت یک توافق نامه عدم افشا و در صورت درخواست در دسترس مشتریان است).
مشتریان باید، و تشویق می شوند تا نقاط پایانی API خود را آزمایش کنند. توافق شما با Apigee آزمایش نقاط پایانی API شما را ممنوع نمی کند، اما از شما درخواست می کند که رابط کاربری مدیریت مشترک را آزمایش نکنید. اگر چه در صورت نیاز به توضیح بیشتر، لطفاً یک بلیط پشتیبانی را باز کنید که به آزمایش برنامه ریزی شده شما اشاره دارد. اطلاع رسانی به Apigee از قبل قدردانی می شود تا بتوانیم از ترافیک آزمایشی مطلع شویم.
مشتریانی که نقاط پایانی خود را آزمایش می کنند باید به دنبال هر گونه مشکل خاص API، هر گونه مشکل مربوط به خدمات Apigee باشند، و همچنین TLS و سایر موارد قابل تنظیم را بررسی کنند. هر موردی که یافت می شود و مربوط به خدمات Apigee است باید از طریق تیکت پشتیبانی به Apigee اطلاع داده شود.
بیشتر موارد مربوط به نقطه پایانی موارد سلف سرویس مشتری هستند و با بررسی مستندات Edge قابل رفع هستند. اگر مواردی وجود دارد که نحوه رفع آنها مشخص نیست، لطفاً یک درخواست پشتیبانی باز کنید.
پیکربندی TLS
مشتریان مسئول تعریف و پیکربندی نقاط پایانی TLS خود برای پراکسی های API هستند. این یک ویژگی سلف سرویس در Edge است. الزامات مشتری در مورد رمزگذاری، پروتکل و انتخاب الگوریتم به طور گسترده ای متغیر و مختص موارد استفاده فردی است. از آنجایی که Apigee از جزئیات طراحی API و محموله های داده هر مشتری اطلاعی ندارد، مشتریان مسئولیت تعیین رمزگذاری مناسب برای داده های در حال انتقال را دارند ( انطباق HIPAA: امنیت - انتقال) .
دستورالعمل های دقیق در مورد پیکربندی TLS در TLS/SSL موجود است.
ذخیره سازی داده ها
ذخیره سازی داده ها در Edge برای عملکرد صحیح Edge لازم نیست. با این حال، خدماتی برای ذخیره سازی داده ها در Edge وجود دارد. مشتریان ممکن است انتخاب کنند که از حافظه پنهان یا تجزیه و تحلیل برای ذخیره سازی داده استفاده کنند. برای جلوگیری از استفاده تصادفی یا مخرب از سرویس‌های ذخیره‌سازی داده در Edge به روشی غیرمنطبق، بررسی پیکربندی، خط‌مشی‌ها و استقرار توسط مدیران مشتری توصیه می‌شود.
رمزگذاری داده های محموله
ابزارهای رمزگذاری داده ها برای استفاده در داخل Edge به مشتریان ارائه نمی شود. با این حال، مشتریان می توانند قبل از ارسال به Edge، داده ها را رمزگذاری کنند. داده های رمزگذاری شده در محموله (یا متن پیام) از عملکرد Edge جلوگیری نمی کند. اگر داده‌ها به‌صورت رمزگذاری شده توسط مشتری دریافت شوند، ممکن است چند خط‌مشی Edge نتوانند با داده‌ها تعامل داشته باشند. به عنوان مثال، اگر خود داده برای تغییر در دسترس Edge نباشد، تبدیل امکان پذیر نیست. اما سایر خط‌مشی‌ها و سیاست‌ها و بسته‌های ساخته شده توسط مشتری حتی اگر محموله داده رمزگذاری شده باشد، کار خواهند کرد.
PII در URI ها
پلتفرم تجزیه و تحلیل یکپارچه Apigee (UAP) داده های تحلیلی، از جمله هر PHI یا سایر داده های حساس موجود در شناسه منبع یکنواخت (URI) یک فراخوانی API را به Apigee Edge می گیرد و آن را به مدت 13 ماه حفظ می کند. PHI در URI توسط استانداردهای Fast Healthcare Interoperability Resources (FHIR) پشتیبانی می شود و بنابراین توسط Apigee پشتیبانی می شود. داده های تجزیه و تحلیل در UAP به طور پیش فرض در حالت استراحت رمزگذاری می شوند.
Apigee در حال حاضر پشتیبانی نمی کند:
- پوشاندن داده ها به UAP
- تغییر چرخه نگهداری
- انصراف از UAP
- حذف URI از مجموعه داده های UAP