انطباق و پیکربندی HIPAA با Apigee Edge

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

انطباق با HIPAA با Apigee Edge

اطمینان از اینکه داده‌های مشتریان ما ایمن، مطمئن و همیشه در دسترس آنها باشد، یکی از اولویت‌های اصلی ما است. گوگل برای نشان دادن انطباق خود با استانداردهای امنیتی در صنعت، گواهینامه‌های امنیتی مانند گواهینامه ISO 27001 و ممیزی‌های SOC 2 و SOC 3 نوع II را درخواست و دریافت کرده است. برای مشتریانی که مشمول الزامات قانون قابلیت انتقال و پاسخگویی بیمه سلامت (HIPAA) هستند، Apigee Edge همچنین می‌تواند از انطباق با HIPAA پشتیبانی کند.

طبق HIPAA، اطلاعات خاصی در مورد سلامت یا خدمات مراقبت‌های بهداشتی یک فرد به عنوان اطلاعات سلامت حفاظت‌شده (PHI) طبقه‌بندی می‌شود. مشتریان Apigee Edge که مشمول HIPAA هستند و مایل به استفاده از Apigee Edge با PHI هستند، باید یک توافقنامه همکاری تجاری (BAA) با گوگل امضا کنند.

مشتریان Apigee Edge مسئول تعیین این هستند که آیا مشمول الزامات HIPAA هستند یا خیر و اینکه آیا از خدمات گوگل در ارتباط با PHI استفاده می‌کنند یا قصد استفاده از آنها را دارند. مشتریانی که با گوگل قرارداد BAA امضا نکرده‌اند، نباید از خدمات گوگل در ارتباط با PHI استفاده کنند.

مدیران باید قبل از استفاده از سرویس‌های گوگل با PHI، BAA را بررسی و بپذیرند.

ما راهنمای پیکربندی Apigee HIPAA خود را در این موضوع منتشر کرده‌ایم تا به مشتریان در درک نحوه سازماندهی داده‌ها در سرویس‌های گوگل هنگام مدیریت PHI کمک کنیم. این راهنما برای کارمندان سازمان‌هایی در نظر گرفته شده است که مسئول اجرای HIPAA و انطباق با Apigee Edge هستند.

راهنمای پیکربندی HIPAA برای Edge Public Cloud

این راهنما صرفاً جهت اطلاع‌رسانی است. شرکت Apigee قصد ندارد اطلاعات یا توصیه‌های موجود در این راهنما را به عنوان مشاوره حقوقی ارائه دهد. هر مشتری مسئول است که به طور مستقل نحوه استفاده خاص خود از خدمات را ارزیابی کند تا از تعهدات قانونی خود در این زمینه پشتیبانی کند.

موارد زیر باید توسط مشتریانی که مشمول قانون قابلیت انتقال و پاسخگویی بیمه سلامت (معروف به HIPAA، اصلاح‌شده، از جمله قانون فناوری اطلاعات سلامت برای سلامت اقتصادی و بالینی - HITECH) هستند و بسته انطباق با HIPAA را خریداری کرده‌اند، بررسی شود. این موارد در Edge به صورت سلف سرویس ارائه می‌شوند و می‌توانند به سازمان مشتری (org) در انجام تعهدات انطباق با HIPAA کمک کنند. مفهوم کلی این است که "گوگل پلتفرم را ایمن می‌کند، مشتری داده‌های خود را ایمن می‌کند."

ردیابی / اشکال‌زدایی

Trace/Debug ابزاری برای عیب‌یابی است که به کاربر اجازه می‌دهد وضعیت و محتوای یک فراخوانی API را هنگام پردازش از طریق پردازنده پیام Apigee مشاهده کند. Trace و Debug دو نام برای یک سرویس هستند اما از طریق مکانیسم‌های مختلف قابل دسترسی هستند. Trace نام این سرویس در داخل رابط کاربری Edge است. Debug نام همان سرویس است که از طریق فراخوانی‌های API استفاده می‌شود. استفاده از اصطلاح Trace در این سند برای Trace و Debug معتبر است.

در طول یک جلسه ردیابی، در صورت فعال و پیکربندی توسط مشتری، "پوشش داده‌ها" اعمال می‌شود. این ابزار می‌تواند نمایش داده‌ها را در طول ردیابی مسدود کند. به بخش پوشش داده‌ها در زیر مراجعه کنید.

نقشه‌های کلید-مقدار رمزگذاری‌شده (KVM) برای مشتریانی که نیاز به انطباق با HIPAA دارند، استفاده می‌شوند. با استفاده از KVM رمزگذاری‌شده، می‌توان همچنان از Trace استفاده کرد، اما برخی از متغیرها در صفحه نمایش Trace قابل مشاهده نخواهند بود. می‌توان مراحل دیگری را نیز برای نمایش این متغیرها در طول Trace انجام داد.

دستورالعمل‌های دقیق در مورد استفاده از Trace در بخش «استفاده از ابزار Trace» موجود است.

جزئیات مربوط به KVMها، از جمله KVMهای رمزگذاری‌شده، در «کار با نقشه‌های کلید-مقدار» موجود است.

استفاده/مجوزها

دسترسی به Trace از طریق سیستم RBAC (کنترل دسترسی مبتنی بر نقش) برای حساب‌های کاربری در Edge مدیریت می‌شود ( انطباق با HIPAA: امنیت - کنترل دسترسی ). دستورالعمل‌های دقیق در مورد استفاده از سیستم RBAC برای اعطای و لغو امتیازات Trace در بخش «اختصاص نقش‌ها» و «ایجاد نقش‌های سفارشی در رابط کاربری» موجود است. مجوزهای Trace به کاربر اجازه می‌دهند تا یک Trace را راه‌اندازی کند، یک Trace را متوقف کند و به خروجی یک جلسه Trace دسترسی پیدا کند.

از آنجایی که Trace به محتوای فراخوانی‌های API (که رسماً "Message Body" نامیده می‌شود) دسترسی دارد، توجه به اینکه چه کسی به اجرای Trace دسترسی دارد، مهم است. از آنجا که مدیریت کاربر بر عهده مشتری است، اعطای مجوزهای Trace نیز بر عهده مشتری است. Apigee، به عنوان مالک پلتفرم، توانایی اضافه کردن کاربر به سازمان مشتری و اختصاص امتیازات را دارد. این توانایی فقط در صورت درخواست مشتری برای پشتیبانی در شرایطی استفاده می‌شود که به نظر می‌رسد خدمات مشتری با مشکل مواجه شده است و بررسی یک جلسه Trace بهترین اطلاعات را در مورد علت اصلی ارائه می‌دهد.

پوشش داده

پوشش داده‌ها از نمایش داده‌های حساس فقط در طول جلسه Trace/Debug، چه در Trace (رابط کاربری Edge) و چه در backend توسط Debug (رابط برنامه‌نویسی Edge) جلوگیری می‌کند. جزئیات نحوه تنظیم پوشش در بخش پوشش و پنهان‌سازی داده‌ها موجود است.

پنهان‌سازی داده‌ها مانع از مشاهده داده‌ها در فایل‌های لاگ، حافظه پنهان، تجزیه و تحلیل و غیره نمی‌شود. برای کمک به پنهان‌سازی داده‌ها در لاگ‌ها، اضافه کردن یک الگوی regex به فایل logback.xml را در نظر بگیرید. داده‌های حساس معمولاً نباید بدون توجیه قوی تجاری و بررسی توسط تیم‌های امنیتی و حقوقی شما در حافظه پنهان یا تجزیه و تحلیل نوشته شوند.

حافظه نهان سطح ۱ و سطح ۲

استفاده از حافظه نهان L1 به طور خودکار از حافظه نهان L2 نیز استفاده می‌کند. حافظه نهان L1 "فقط حافظه" است در حالی که حافظه نهان L2 داده‌ها را برای همگام‌سازی در چندین حافظه نهان L1 روی دیسک می‌نویسد. حافظه نهان L2 چیزی است که چندین پردازنده پیام را در یک منطقه و به صورت جهانی همگام نگه می‌دارد. در حال حاضر فعال کردن حافظه نهان L1 بدون حافظه نهان L2 در پشت آن امکان‌پذیر نیست. حافظه نهان L2 داده‌ها را روی دیسک می‌نویسد تا بتوان آنها را با سایر پردازنده‌های پیام برای سازمان مشتری همگام‌سازی کرد. دستورالعمل‌های دقیق در مورد استفاده از حافظه نهان در بخش افزودن حافظه نهان و ماندگاری موجود است.

دنباله حسابرسی

مشتریان می‌توانند دنباله حسابرسی تمام فعالیت‌های اداری انجام شده در سازمان خود، از جمله استفاده از Trace ( انطباق با HIPAA: فرآیند مدیریت امنیت - بررسی فعالیت سیستم اطلاعات ) را بررسی کنند. دستورالعمل‌های دقیق در اینجا و در استفاده از ابزار Trace موجود است.

الزامات رمز عبور پیچیده یا SAML

برای مشتریان HIPAA، رمزهای عبور کاربر به گونه‌ای پیکربندی می‌شوند که الزامات پیشرفته‌ای مانند طول، پیچیدگی و طول عمر را برآورده کنند. ( رعایت HIPAA: مدیریت رمز عبور امنیتی )

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

امنیت نقطه پایانی

اسکن نقطه پایانی

مشتریان Edge Cloud مسئول اسکن و آزمایش نقاط پایانی API خود (که گاهی اوقات "اجزای زمان اجرا" نامیده می‌شوند) در Edge هستند ( انطباق با HIPAA: امنیت - فرآیند مدیریت امنیت ). آزمایش مشتری باید سرویس‌های پروکسی API واقعی میزبانی شده در Edge را پوشش دهد که در آن ترافیک API قبل از پردازش به Edge ارسال می‌شود و سپس به مرکز داده مشتری تحویل داده می‌شود. آزمایش منابع مشترک، مانند رابط کاربری پورتال مدیریت، برای مشتریان شخصی تأیید نمی‌شود (گزارش شخص ثالث که آزمایش سرویس‌های مشترک را پوشش می‌دهد، تحت توافق‌نامه عدم افشا و بنا به درخواست در دسترس مشتریان است).

مشتریان باید و به این کار تشویق می‌شوند که نقاط پایانی 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 رمزگذاری کنند. داده‌های رمزگذاری شده در payload (یا Message Body) مانع از عملکرد Edge نمی‌شوند. اگر داده‌ها توسط مشتری رمزگذاری شوند، ممکن است برخی از سیاست‌های Edge قادر به تعامل با داده‌ها نباشند. به عنوان مثال، اگر خود داده‌ها برای Edge در دسترس نباشند، تبدیل امکان‌پذیر نیست. اما سایر سیاست‌ها و سیاست‌ها و بسته‌های ساخته شده توسط مشتری حتی اگر payload داده رمزگذاری شده باشد، کار خواهند کرد.

PII در URIها

پلتفرم یکپارچه تحلیلی (UAP) شرکت Apigee، داده‌های تحلیلی، شامل هرگونه PHI یا سایر داده‌های حساس موجود در شناسه منبع یکنواخت (URI) یک فراخوانی API در Apigee Edge را ضبط کرده و آن را به مدت ۱۳ ماه نگهداری می‌کند. PHI موجود در URI توسط استانداردهای منابع همکاری سریع مراقبت‌های بهداشتی (FHIR) پشتیبانی می‌شود و بنابراین توسط Apigee پشتیبانی می‌شود. داده‌های تحلیلی در UAP به طور پیش‌فرض در حالت سکون رمزگذاری می‌شوند.

Apigee در حال حاضر پشتیبانی نمی‌کند:

• پوشش داده به UAP
• تغییر چرخه نگهداری
• انصراف از UAP
• حذف URI از مجموعه داده‌های UAP