درحال مشاهده اسناد Apigee Edge هستید.
به
اسناد Apigee X بروید. اطلاعات
سازگاری با «قانون انتقال و مسئولیت بیمه سلامت» با 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 استفاده می‌کنند یا قصد دارند استفاده کنند. مشتریانی که با Google «قرارداد شریک تجاری» امضا نکرده‌اند نباید از سرویس‌های Google درارتباط با «اطلاعات بهداشتی محافظت‌شده» استفاده کنند.
سرپرستان باید قبل‌از استفاده از سرویس‌های Google با «اطلاعات بهداشتی محافظت‌شده» (PHI)، «قرارداد شریک تجاری» را مرور و بپذیرند.
ما راهنمای پیکربندی HIPAA خود را در این موضوع منتشر کرده‌ایم تا به مشتریان کمک کنیم بفهمند چگونه هنگام کار با PHI، داده‌ها را در سرویس‌های Google سازمان‌دهی کنند. این راهنما برای کارمندان سازمان‌هایی است که مسئول پیاده‌سازی HIPAA و رعایت آن با Apigee Edge هستند.
راهنمای پیکربندی HIPAA برای Edge Public Cloud
این راهنما فقط برای اهداف اطلاع‌رسانی است. Apigee قصد ندارد اطلاعات یا توصیه‌های این راهنما را به‌عنوان مشاوره حقوقی درنظر بگیرد. هر مشتری مسئولیت دارد استفاده خاص خود از سرویس‌ها را به‌طور مستقل ارزیابی کند تا از تعهدات رعایت قوانین خود پشتیبانی کند.
مشتریان مشمول «قانون انتقال‌پذیری و پاسخگویی بیمه درمانی» (که به‌عنوان HIPAA شناخته می‌شود، با اصلاحات بعدی، ازجمله «قانون فناوری اطلاعات سلامت برای سلامت اقتصادی و بالینی» — قانون HITECH) که بسته رعایت استاندارد HIPAA را خریداری کرده‌اند باید موارد زیر را بررسی کنند. این موارد در Edge خویش‌یار هستند و می‌توانند به سازمان مشتری (سازمان) در برآورده کردن تعهدات پیروی از HIPAA کمک کنند. مفهوم کلی این است که «Google پلاتفرم را ایمن می‌کند، مشتری داده‌هایش را ایمن می‌کند.»
| الزامات «قانون جوابگویی و انتقال‌پذیری بیمه درمانی» | بخش‌ها |
|---|---|
| رعایت «قانون جوابگویی و انتقال‌پذیری بیمه درمانی»: امنیت - کنترل دسترسی | استفاده/مجوزها |
| رعایت «قانون قابلیت انتقال و پاسخگویی بیمه سلامت» (HIPAA): فرایند مدیریت امنیت - مرور فعالیت سیستم اطلاعات | رد ممیزی |
| رعایت «قانون جوابگویی و انتقال‌پذیری بیمه درمانی»: مدیریت گذرواژه امنیتی | الزامات گذرواژه پیچیده یا SAML |
| رعایت «قانون جوابگویی و انتقال‌پذیری بیمه درمانی»: امنیت - فرایند مدیریت امنیت | اسکن نقطه پایان |
| رعایت «قانون جوابگویی و انتقال‌پذیری بیمه درمانی»: امنیت - انتقال | پیکربندی «امنیت لایه انتقال» |
ردیابی / اشکال‌زدایی
«ردیابی/اشکال‌زدایی» ابزار عیب‌یابی است که به کاربر امکان می‌دهد وضعیت و محتوای تماس API را هنگام پردازش ازطریق «پردازشگر پیام Apigee» مشاهده کند. «ردیابی» و «عیب‌یابی» دو نام برای یک سرویس هستند که ازطریق سازوکارهای مختلفی به آن‌ها دسترسی پیدا می‌شود. «ردیابی» نام این سرویس در «میانای کاربری Edge» است. وقتی ازطریق فراخوانی‌های API استفاده می‌شود، نام این سرویس «اشکال‌زدایی» است. استفاده از اصطلاح «ردیابی» در این سند برای «ردیابی» و «اشکال‌زدایی» معتبر است.
درطول جلسه «ردیابی»، اگر مشتری «پوشاندن داده‌ها» را فعال و پیکربندی کرده باشد، این ویژگی اعمال می‌شود. این ابزار می‌تواند نمایش داده‌ها را درطول «ردیابی» مسدود کند. به بخش پوشش داده‌ها در زیر مراجعه کنید.
«نقشه‌های مقدار کلید رمزگذاری‌شده» (KVM) برای مشتریانی استفاده می‌شود که به رعایت «قانون قابلیت انتقال و پاسخگویی بیمه سلامت» (HIPAA) نیاز دارند. بااستفاده از KVM رمزگذاری‌شده، همچنان می‌توان از Trace استفاده کرد، اما برخی‌از متغیرها در صفحه نمایش Trace قابل مشاهده نخواهند بود. می‌توانید مراحل بیشتری را برای نمایش این متغیرها درطول «ردیابی» انجام دهید.
دستورالعمل‌های دقیق درباره استفاده از «ردیابی» در استفاده از ابزار «ردیابی» دردسترس است.
جزئیات مربوط به KVM، ازجمله KVM رمزگذاری‌شده، در کار با نقشه‌های مقدار کلید دردسترس است.
استفاده/مجوزها
دسترسی به Trace ازطریق سیستم RBAC (کنترل دسترسی نقش‌مبنا) برای حساب‌های کاربر در Edge مدیریت می‌شود (رعایت HIPAA: امنیت - کنترل دسترسی). دستورالعمل‌های دقیق درباره استفاده از سیستم RBAC برای اعطا و لغو امتیازات «ردیابی» در اختصاص نقش‌ها و ایجاد نقش‌های سفارشی در واسط کاربر دردسترس است. اجازه‌های ردیابی به کاربر امکان می‌دهد «ردیابی» راه‌اندازی کند، «ردیابی» را متوقف کند، و به برونداد جلسه «ردیابی» دسترسی پیدا کند.
ازآنجایی‌که Trace به محتوای تماس‌های API (که قبلاً «متن پیام» نامیده می‌شد) دسترسی دارد، مهم است که درنظر بگیرید چه کسی به اجرای Trace دسترسی دارد. ازآنجایی‌که مدیریت کاربر مسئولیت مشتری است، اعطای اجازه‌های «ردیابی» نیز مسئولیت مشتری است. Apigee به‌عنوان مالک پلاتفرم، توانایی افزودن کاربر به سازمان مشتری و اختصاص دادن امتیازات را دارد. این قابلیت فقط درصورت درخواست مشتری برای پشتیبانی در موقعیتی که به‌نظر می‌رسد خدمات مشتری با مشکل مواجه شده است استفاده می‌شود و اعتقاد بر این است که بررسی جلسه «ردیابی» بهترین اطلاعات را درباره علت اصلی ارائه می‌دهد.
پوشاندن داده‌ها
پوشاندن داده‌ها فقط درطول جلسه «ردیابی/اشکال‌زدایی» از نمایش داده‌های حساس جلوگیری می‌کند، هم در «ردیابی» (میانای کاربری Edge) و هم در زیرینه با «اشکال‌زدایی» (Edge API). جزئیات نحوه راه‌اندازی «پوشش‌دهی» در پوشش‌دهی و پنهان کردن داده‌ها دردسترس است.
پوشش داده‌ها از نمایان شدن داده‌ها در فایل‌های گزارش، حافظه نهان، تجزیه‌وتحلیل، و غیره جلوگیری نمی‌کند. برای دریافت راهنمایی درباره پوشش داده‌ها در گزارش‌ها، الگوی عبارت باقاعده‌ای را به فایل logback.xml اضافه کنید. داده‌های حساس معمولاً نباید بدون توجیه کسب‌وکار قوی و بررسی توسط تیم‌های امنیتی و حقوقی شما در حافظه نهان یا تجزیه‌وتحلیل‌ها نوشته شوند.
حافظه نهان L1 و L2
استفاده از حافظه نهان L1 به‌طور خودکار از حافظه نهان L2 نیز استفاده می‌کند. حافظه نهان L1 «فقط حافظه» است درحالی‌که حافظه نهان L2 داده‌ها را روی دیسک می‌نویسد تا در چندین حافظه نهان L1 همگام‌سازی شود. حافظه نهان L2 چیزی است که چندین «پردازنده پیام» را در یک منطقه و در سطح جهانی همگام‌سازی می‌کند. درحال‌حاضر نمی‌توانید حافظه نهان L1 را بدون حافظه نهان L2 در پشت آن فعال کنید. حافظه نهان L2 داده‌ها را در دیسک می‌نویسد تا بتواند آن‌ها را با پردازشگرهای پیام دیگر برای سازمان مشتری همگام‌سازی کند. دستورالعمل‌های دقیق درباره استفاده از حافظه نهان در افزودن حافظه نهان و ماندگاری دردسترس است.
رد ممیزی
مشتریان می‌توانند «ردپای ممیزی» همه فعالیت‌های مدیریتی انجام‌شده در سازمان مشتری را، ازجمله استفاده از «پیگیری» (رعایت «قانون انتقال‌پذیری و پاسخگویی بیمه سلامت»: «فرایند مدیریت امنیت - بررسی فعالیت سیستم اطلاعات») بررسی کنند. دستورالعمل‌های مفصل در اینجا و در استفاده از ابزار ردیابی دردسترس است.
الزامات گذرواژه پیچیده یا SAML
برای مشتریان HIPAA، گذرواژه‌های کاربر به‌گونه‌ای پیکربندی می‌شوند که الزامات پیشرفته‌ای مانند طول، پیچیدگی، و طول عمر را برآورده کنند. (رعایت «قانون انتقال و مسئولیت بیمه سلامت» : مدیریت گذرواژه امنیتی)
Edge همچنین اصالت‌سنجی چندعاملی را که در فعال کردن اصالت‌سنجی دوعاملی برای حساب Apigee توضیح داده شده است و SAML را که در فعال کردن اصالت‌سنجی SAML برای Edge توضیح داده شده است به‌عنوان جایگزین برای کنترل‌های اصالت‌سنجی ارائه می‌دهد.
امنیت نقطه پایان
اسکن نقطه پایان
مشتریان Edge Cloud مسئول اسکن و آزمایش نقاط پایانی API خود (که گاهی اوقات «عناصر زمان اجرا» نامیده می‌شود) در Edge هستند ( رعایت «قانون انتقال‌پذیری و پاسخگویی بیمه سلامت»: امنیت - فرایند مدیریت امنیت). آزمایش مشتری باید خدمات کارگزار API واقعی میزبانی‌شده در Edge را که در آن ترافیک API قبل‌از پردازش و سپس تحویل به مرکز داده مشتری به Edge ارسال می‌شود پوشش دهد. آزمایش منابع مشترک، مثل واسط کاربر درگاه مدیریت، برای مشتریان فردی تأیید نمی‌شود (گزارش طرف سوم که آزمایش سرویس‌های مشترک را پوشش می‌دهد تحت قرارداد عدم افشا و درصورت درخواست دراختیار مشتریان قرار می‌گیرد).
مشتریان باید نقطه‌های پایانی API خود را آزمایش کنند و به انجام این کار تشویق می‌شوند. قرارداد شما با Apigee آزمایش نقاط پایانی API شما را ممنوع نمی‌کند، اما از شما می‌خواهد که واسط کاربر مدیریت مشترک را آزمایش نکنید. اگرچه درصورت نیاز به شفاف‌سازی بیشتر، لطفاً درخواست پشتیبانی را با ارجاع به آزمایش برنامه‌ریزی‌شده خود باز کنید. اعلام قبلی به Apigee مورد استقبال قرار می‌گیرد تا بتوانیم از ترافیک آزمایش مطلع شویم.
مشتریانی که نقطه‌های پایان خود را آزمایش می‌کنند باید به‌دنبال مشکلات خاص API، مشکلات مربوط به خدمات Apigee، و همچنین بررسی TLS و سایر موارد قابل پیکربندی باشند. هرگونه مورد یافت‌شده و مرتبط با خدمات Apigee باید ازطریق درخواست پشتیبانی به Apigee اطلاع داده شود.
بیشتر عناصر مربوط به نقطه پایانی عناصر خویش‌یار مشتری هستند و با مرور کردن مستندات Edge می‌توانید آن‌ها را برطرف کنید. اگر مواردی وجود دارد که نحوه رفع آن‌ها مشخص نیست، لطفاً درخواست پشتیبانی باز کنید.
پیکربندی «امنیت لایه انتقال»
مشتریان مسئول تعریف و پیکربندی نقاط پایانی TLS خودشان برای پراکسی‌های API هستند. این یک ویژگی سلف‌سرویس در Edge است. الزامات مشتری درخصوص رمزگذاری، پروتکل، و انتخاب الگوریتم بسیار متغیر و مختص موارد استفاده فردی است. ازآنجایی‌که Apigee از جزئیات طراحی API و داده‌بار هر مشتری مطلع نیست، مشتریان مسئول تعیین رمزگذاری مناسب برای داده‌های درحال انتقال هستند ( رعایت HIPAA: امنیت - انتقال).
دستورالعمل‌های دقیق درباره پیکربندی «امنیت لایه انتقال» در امنیت لایه انتقال/SSL دردسترس است.
ذخیره‌سازی داده
برای عملکرد صحیح Edge، ذخیره داده‌ها در Edge الزامی نیست. بااین‌حال، سرویس‌هایی برای ذخیره داده در Edge دردسترس است. مشتریان می‌توانند از حافظه نهان یا تجزیه‌وتحلیل برای ذخیره داده‌ها استفاده کنند. برای جلوگیری از استفاده تصادفی یا مخرب از خدمات ذخیره‌سازی داده‌ها در Edge به‌شیوه‌ای ناسازگار با خط‌مشی‌ها، توصیه می‌شود سرپرستان مشتری پیکربندی‌ها، خط‌مشی‌ها، و استقرارها را مرور کنند.
رمزگذاری داده‌های پایه‌بار
ابزارهای رمزگذاری داده برای استفاده مشتریان در Edge ارائه نمی‌شود. بااین‌حال، مشتریان می‌توانند داده‌ها را قبل‌از ارسال به Edge رمزگذاری کنند. داده‌های رمزگذاری‌شده در محتوای پیام (یا «بدنه پیام») مانع عملکرد Edge نمی‌شود. اگر داده‌ها به‌صورت رمزگذاری‌شده توسط مشتری دریافت شود، ممکن است چند خط‌مشی Edge نتوانند با آن تعامل داشته باشند. برای مثال، اگر خود داده‌ها برای Edge دردسترس نباشد تا آن‌ها را تغییر دهد، تبدیل امکان‌پذیر نیست. اما خط‌مشی‌های دیگر و خط‌مشی‌ها و دسته‌های ساخته‌شده توسط مشتری حتی اگر داده‌های بار رمزگذاری شده باشند کار خواهند کرد.
«اطلاعات شخصی و محرمانه» در نشانی‌های وب
پلاتفرم تجزیه‌وتحلیل یکپارچه (UAP) Apigee داده‌های تجزیه‌وتحلیل را، ازجمله هرگونه اطلاعات بهداشتی محافظت‌شده یا دیگر داده‌های حساس موجود در شناسه منبع یکسان (URI) تماس با API در Apigee Edge، ضبط می‌کند و آن‌ها را به‌مدت ۱۳ ماه نگهداری می‌کند. PHI در URI توسط استانداردهای Fast Healthcare Interoperability Resources (FHIR) پشتیبانی می‌شود و بنابراین توسط Apigee پشتیبانی می‌شود. داده‌های Analytics در UAP به‌طور پیش‌فرض در حالت سکون رمزگذاری می‌شود.
درحال‌حاضر Apigee از موارد زیر پشتیبانی نمی‌کند:
- پوشش داده به UAP
- تغییر چرخه نگهداری
- انصراف دادن از UAP
- حذف کردن نشانی وب از جمع‌آوری داده‌های UAP