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

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

برای اینکه یک مشتری در Apigee Edge Public Cloud با PCI سازگار باشد، برخی اقدامات و فرآیندها وجود دارد که مشتری تحت "مدل مسئولیت مشترک" مالک آنهاست. موارد زیر باید توسط مشتریانی که بسته انطباق با PCI را خریداری کرده‌اند و ملزم به انطباق با PCI هستند، بررسی شوند. این موارد در Edge به صورت سلف سرویس ارائه می‌شوند و برای اینکه سازمان مشتری (org) با PCI سازگار شود، باید به آنها رسیدگی شود. مفهوم کلی این است که "گوگل پلتفرم را ایمن می‌کند، مشتری داده‌های خود را ایمن می‌کند."

ماتریس مسئولیت مشتری

مشتریان باید هنگام انجام ممیزی PCI خود، به Google Cloud Plaform: PCI DSS v4.0.1 Shared Responsibility Matrix مراجعه کرده و آن را با ارزیاب امنیتی واجد شرایط PCI خود به اشتراک بگذارند.

نگاشت الزامات PCI

الزامات PCI بخش
الزام ۷: ​​محدود کردن دسترسی به اجزای سیستم و داده‌های دارنده کارت بر اساس کسب و کار، نکات ضروری

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

الزام ۳: محافظت از داده‌های ذخیره‌شده حساب کاربری

پوشش داده‌ها

الزام ۱۰: ثبت و نظارت بر تمام دسترسی‌ها به اجزای سیستم و داده‌های دارنده کارت

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

الزام ۸: شناسایی کاربران و احراز هویت دسترسی به اجزای سیستم

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

الزام ۱۱: تست منظم امنیت سیستم‌ها و شبکه‌ها

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

الزام ۴: محافظت از داده‌های دارنده کارت با رمزنگاری قوی در حین انتقال از طریق شبکه‌های عمومی و باز

پیکربندی TLS

الزام ۳: محافظت از داده‌های ذخیره‌شده حساب کاربری

ذخیره‌سازی داده‌ها

الزام ۴: محافظت از داده‌های دارنده کارت با رمزنگاری قوی در حین انتقال از طریق شبکه‌های عمومی و باز

رمزگذاری داده‌ها

برای دریافت گواهی انطباق با استاندارد امنیت داده‌های PCI (AOC)، با پشتیبانی Apigee تماس بگیرید یا با تیم فروش Apigee خود تماس بگیرید.

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

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

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

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

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

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

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

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

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

پوشش داده‌ها

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

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

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

ذخیره‌سازی فقط برای استفاده با داده‌های غیرتنظیم‌شده برای مشتریان PCI در دسترس است. حافظه پنهان نباید برای داده‌های دارنده کارت PCI (CHD) استفاده شود؛ این حافظه توسط ممیزی انطباق PCI Apigee به عنوان محل ذخیره‌سازی برای CHD تأیید نشده است. طبق دستورالعمل PCI ( الزام 3: محافظت از داده‌های ذخیره‌شده دارنده کارت )، داده‌های PCI فقط باید در یک محل سازگار با PCI ذخیره شوند. استفاده از حافظه پنهان L1 به طور خودکار از حافظه پنهان L2 نیز استفاده می‌کند. حافظه پنهان L1 "فقط حافظه" است در حالی که حافظه پنهان L2 داده‌ها را برای همگام‌سازی در چندین حافظه پنهان L1 روی دیسک می‌نویسد. حافظه پنهان L2 چیزی است که چندین پردازنده پیام را در یک منطقه و به صورت جهانی همگام نگه می‌دارد. در حال حاضر فعال کردن حافظه پنهان L1 بدون حافظه پنهان L2 در پشت آن امکان‌پذیر نیست. حافظه پنهان L2 داده‌ها را روی دیسک می‌نویسد تا بتوان آنها را با سایر پردازنده‌های پیام برای سازمان مشتری همگام‌سازی کرد. از آنجا که حافظه پنهان L2 داده‌ها را روی دیسک می‌نویسد، استفاده از حافظه پنهان برای CHD یا سایر داده‌های محدود پشتیبانی نمی‌شود.

استفاده از حافظه پنهان توسط مشتریان برای داده‌های غیر CHD و سایر داده‌های نامحدود مجاز است. ما حافظه پنهان را به طور پیش‌فرض برای مشتریان PCI غیرفعال نمی‌کنیم، زیرا برخی از مشتریان هر دو فراخوانی API مرتبط با PCI و غیر مرتبط با PCI را از طریق یک سازمان واحد اجرا می‌کنند. از آنجا که این قابلیت هنوز برای مشتریان PCI فعال است، مسئولیت استفاده صحیح از سرویس و آموزش کاربران خود برای عدم استفاده از حافظه پنهان در مواقعی که احتمال وجود داده‌های PCI در فراخوانی API وجود دارد، بر عهده مشتری است. ممیزی انطباق با PCI شرکت Apigee از CHD ذخیره شده در حافظه پنهان پشتیبانی نمی‌کند.

دستورالعمل‌های دقیق در مورد استفاده از حافظه پنهان (Cache) در بخش افزودن حافظه پنهان و ماندگاری (Adding caching and persistence) موجود است.

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

مشتریان می‌توانند ردیابی حسابرسی تمام فعالیت‌های اداری انجام‌شده در سازمان مشتری، از جمله استفاده از Trace را بررسی کنند. دستورالعمل‌های دقیق در اینجا و در استفاده از ابزار Trace موجود است. ( الزام PCI 10: ردیابی و نظارت بر تمام دسترسی‌ها به منابع شبکه و داده‌های دارنده کارت )

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

مشتریانی که الزامات رمز عبور خاصی دارند، باید از SAML برای برآورده کردن الزامات فردی خود استفاده کنند. به فعال کردن احراز هویت SAML برای Edge مراجعه کنید. Edge همچنین احراز هویت چند عاملی را ارائه می‌دهد ( الزام PCI 8: به هر شخصی که به کامپیوتر دسترسی دارد، یک شناسه منحصر به فرد اختصاص دهید ). به فعال کردن احراز هویت دو عاملی برای حساب Apigee خود مراجعه کنید.

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

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

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

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

مشتریانی که دستگاه‌های نهایی خود را آزمایش می‌کنند، باید به دنبال هرگونه مشکل خاص API، هرگونه مشکل مربوط به سرویس‌های Apigee و همچنین TLS و سایر موارد قابل تنظیم باشند. هر موردی که مربوط به سرویس‌های Apigee یافت شود، باید از طریق درخواست پشتیبانی به Apigee اطلاع داده شود.

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

پیکربندی TLS

طبق استانداردهای PCI ، SSL و TLS اولیه باید به نسخه‌های امن منتقل شوند. مشتریان مسئول تعریف و پیکربندی نقاط پایانی TLS خود برای پروکسی‌های API هستند. این یک ویژگی سلف سرویس در Edge است. الزامات مشتری در مورد رمزگذاری، پروتکل و انتخاب الگوریتم بسیار متغیر و مختص موارد استفاده فردی است. از آنجا که Apigee جزئیات طراحی API و داده‌های هر مشتری را نمی‌داند، مشتریان مسئولیت تعیین رمزگذاری مناسب برای داده‌های در حال انتقال را بر عهده دارند. دستورالعمل‌های دقیق در مورد پیکربندی TLS در TLS/SSL موجود است.

ذخیره‌سازی داده‌ها

ذخیره داده‌ها در Edge برای عملکرد صحیح Edge الزامی نیست. با این حال، سرویس‌هایی برای ذخیره‌سازی داده‌ها در Edge موجود است. مشتریان می‌توانند از حافظه پنهان، نقشه‌های کلید-مقدار یا تجزیه و تحلیل برای ذخیره‌سازی داده‌ها استفاده کنند. هیچ یک از این سرویس‌ها طبق ممیزی PCI Apigee برای ذخیره‌سازی CHD مجاز نیستند. طبق الزام PCI 3 (محافظت از داده‌های ذخیره شده دارنده کارت) ، داده‌های PCI فقط باید در مکان‌های سازگار با PCI ذخیره شوند. استفاده از این سرویس‌ها برای ذخیره داده‌های غیر PCI یا سایر داده‌های نامحدود که منوط به الزامات امنیتی و قانونی مشتری است، در دسترس مشتریان است. این سرویس‌ها اقلام سلف سرویس مشتری هستند، بنابراین مسئولیت پیکربندی آنها برای عدم ضبط یا ذخیره CHD بر عهده مشتری است. بررسی پیکربندی، سیاست‌ها و استقرارها توسط مدیران مشتری برای جلوگیری از استفاده تصادفی یا مخرب از سرویس‌های ذخیره‌سازی داده‌ها در Edge به شیوه‌ای غیر سازگار توصیه می‌شود.

رمزگذاری داده‌ها

ابزارهای رمزگذاری داده‌ها برای استفاده در داخل Edge به مشتریان ارائه نمی‌شوند. با این حال، مشتریان می‌توانند داده‌های PCI خود را قبل از ارسال به Edge رمزگذاری کنند. الزام PCI 4: (رمزگذاری انتقال داده‌های دارنده کارت در شبکه‌های باز و عمومی) توصیه می‌کند که داده‌های دارنده کارت در شبکه‌های باز و عمومی رمزگذاری شوند. داده‌های رمزگذاری شده در payload (یا بدنه پیام) مانع از عملکرد Edge نمی‌شود. برخی از سیاست‌های Edge ممکن است در صورت دریافت رمزگذاری شده توسط مشتری، قادر به تعامل با داده‌ها نباشند. به عنوان مثال، اگر خود داده‌ها برای تغییر در دسترس Edge نباشند، تبدیل امکان‌پذیر نیست. اما سایر سیاست‌ها و سیاست‌ها و بسته‌های ساخته شده توسط مشتری حتی اگر payload داده رمزگذاری شده باشد، کار خواهند کرد.