شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات
برای اینکه یک مشتری در Apigee Edge Public Cloud با PCI سازگار باشد، برخی اقدامات و فرآیندهایی وجود دارد که مشتری تحت «مدل مسئولیت مشترک» مالک آن است. موارد زیر باید توسط مشتریانی که بسته انطباق PCI را خریداری کرده اند و باید مطابق با PCI باشند بررسی شود. این موارد در Edge سلف سرویس هستند و باید برای سازمان مشتری (org) مورد بررسی قرار گیرند تا با PCI سازگار باشد. مفهوم کلی این است که "گوگل پلتفرم را ایمن می کند، مشتری داده های خود را ایمن می کند."
ماتریس مسئولیت مشتری
مشتریان باید هنگام انجام ممیزی PCI خود، به ماتریس مسئولیت Google Apigee PCI-DSS 3.2.1 مراجعه کنند و آن را با ارزیاب امنیتی واجد شرایط PCI خود به اشتراک بگذارند.
نقشه برداری نیازهای PCI
نیاز PCI | بخش |
---|---|
الزام 7: محدود کردن دسترسی به داده های دارنده کارت توسط کسب و کار نیاز به دانستن | |
شرط 3: از داده های ذخیره شده دارنده کارت محافظت کنید | |
پیش نیاز 10: همه دسترسی ها به منابع شبکه و داده های دارنده کارت را ردیابی و نظارت کنید | |
شرط 8: به هر شخصی که به رایانه دسترسی دارد یک شناسه منحصر به فرد اختصاص دهید | |
شرط 11: سیستم ها و فرآیندهای امنیتی را به طور منظم آزمایش کنید | |
شرط 4: رمزگذاری انتقال داده های دارنده کارت در شبکه های باز و عمومی | |
شرط 3: از داده های ذخیره شده دارنده کارت محافظت کنید | |
شرط 4: رمزگذاری انتقال داده های دارنده کارت در شبکه های باز و عمومی |
برای دریافت گواهی انطباق استاندارد امنیت داده PCI (AOC)، یک بلیط با پشتیبانی Apigee باز کنید یا با تیم فروش Apigee خود تماس بگیرید.
ردیابی / اشکال زدایی
Trace/Debug یک ابزار عیبیابی است که به کاربر امکان میدهد وضعیت و محتوای یک تماس API را همانطور که از طریق پردازشگر پیام Apigee پردازش میشود، مشاهده کند. Trace و Debug دو نام برای یک سرویس هستند اما از طریق مکانیسمهای مختلف قابل دسترسی هستند. Trace نام این سرویس در داخل رابط کاربری Edge است. Debug نام همان سرویس است که از طریق تماس های API استفاده می شود. استفاده از عبارت Trace در این سند برای Trace و Debug معتبر است.
در طول یک جلسه Trace، "Data masking" اجرا می شود. این ابزار می تواند از نمایش داده ها در طول Trace جلوگیری کند. بخش پوشش داده ها را در زیر ببینید.
نقشههای ارزش کلید رمزگذاری شده (KVM) ممکن است برای مشتریان PCI استفاده شود. اگر یک KVM رمزگذاری شده در حال استفاده باشد، Trace ممکن است همچنان استفاده شود، اما برخی از متغیرها در صفحه نمایش Trace قابل مشاهده نخواهند بود. ممکن است اقدامات اضافی برای نمایش این متغیرها در طول Trace انجام شود.
دستورالعمل های دقیق در مورد استفاده از Trace در استفاده از ابزار Trace موجود است.
جزئیات مربوط به KVM ها، از جمله KVM های رمزگذاری شده، در Working with key value maps موجود است.
استفاده/مجوزها
دسترسی به Trace از طریق سیستم RBAC (Role-Based Access Control) برای حساب های کاربری در Edge مدیریت می شود. دستورالعملهای دقیق در مورد استفاده از سیستم RBAC برای دادن و لغو امتیازات Trace در بخش اختصاص نقشها و ایجاد نقشهای سفارشی در رابط کاربری موجود است. مجوزهای Trace به کاربر این امکان را می دهد که یک Trace را راه اندازی کند، یک Trace را متوقف کند، و به خروجی یک جلسه Trace دسترسی داشته باشد.
از آنجایی که Trace به محموله تماسهای API (که به طور رسمی «متن پیام» نامیده میشود) دسترسی دارد، مهم است که در نظر بگیرید چه کسی برای اجرای Trace دسترسی دارد. از آنجا که مدیریت کاربر یک مسئولیت مشتری است، اعطای مجوزهای Trace نیز مسئولیت مشتری است. Apigee، به عنوان مالک پلتفرم، توانایی اضافه کردن کاربر به سازمان مشتری و اختصاص امتیازات را دارد. این توانایی تنها در صورت درخواست مشتری برای پشتیبانی در شرایطی استفاده میشود که به نظر میرسد خدمات مشتری شکست میخورد و تصور میشود که بررسی جلسه Trace بهترین اطلاعات را در مورد علت اصلی ارائه میدهد.
پوشش داده ها
پوشاندن داده از نمایش دادههای حساس فقط در طول جلسه Trace/Debug، هم در Trace (Edge UI) و هم در Backend توسط Debug (Edge API) جلوگیری میکند. جزئیات نحوه تنظیم پوشش در Data masking and hiding موجود است. پوشاندن داده های حساس بخشی از نیاز PCI 3 - محافظت از داده های ذخیره شده دارنده کارت است
پوشاندن داده مانع از قابل مشاهده شدن داده ها در فایل های گزارش، حافظه پنهان، تجزیه و تحلیل و غیره نمی شود. برای کمک به پوشاندن داده ها در گزارش ها، اضافه کردن یک الگوی regex به فایل logback.xml را در نظر بگیرید. دادههای حساس معمولاً نباید بدون توجیه تجاری قوی و بررسی توسط تیمهای امنیتی و حقوقی مشتری در حافظه پنهان یا تجزیه و تحلیل نوشته شوند.
حافظه نهان L1 و L2
حافظه پنهان برای مشتریان PCI فقط برای استفاده با داده های غیرقانونی در دسترس است. کش نباید برای داده های دارنده کارت PCI (CHD) استفاده شود. توسط ممیزی Apigee PCI Compliance به عنوان محل ذخیره سازی CHD تایید نشده است. بر اساس راهنمایی PCI ( شرایط 3: محافظت از داده های ذخیره شده دارنده کارت )، داده های PCI باید فقط در یک مکان سازگار با PCI ذخیره شوند. استفاده از کش L1 به طور خودکار از کش L2 نیز استفاده می کند. کش L1 "فقط حافظه" است در حالی که کش L2 داده ها را روی دیسک می نویسد تا در چند کش L1 همگام شود. حافظه پنهان L2 چیزی است که چندین پردازشگر پیام را در یک منطقه و در سطح جهانی همگام نگه می دارد. در حال حاضر امکان فعال کردن کش L1 بدون وجود حافظه نهان L2 در پشت آن وجود ندارد. حافظه پنهان L2 داده ها را روی دیسک می نویسد تا بتوان آن ها را با سایر پردازشگرهای پیام برای سازمان مشتری همگام سازی کرد. از آنجا که L2 Cache داده ها را روی دیسک می نویسد، استفاده از حافظه پنهان برای CHD یا سایر داده های محدود پشتیبانی نمی شود.
استفاده از حافظه پنهان توسط مشتریان برای داده های غیر CHD و سایر داده های نامحدود مجاز است. ما کش را به طور پیشفرض برای مشتریان PCI غیرفعال نمیکنیم، زیرا برخی از مشتریان هم تماسهای API مربوط به PCI و هم غیر PCI را از طریق یک سازمان اجرا میکنند. از آنجایی که این قابلیت همچنان برای مشتریان PCI فعال است، این مسئولیت بر عهده مشتری است که از سرویس به درستی استفاده کند و به کاربران خود آموزش دهد که از حافظه پنهان استفاده نکنند، زمانی که داده PCI احتمالاً در تماس API وجود دارد. ممیزی Apigee PCI Compliance از CHD ذخیره شده در حافظه پنهان پشتیبانی نمی کند.
دستورالعمل های دقیق در مورد استفاده از حافظه پنهان در 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 ارسال شده و سپس به مرکز داده مشتری تحویل داده می شود. آزمایش منابع مشترک، مانند UI پورتال مدیریت، برای مشتریان منفرد تأیید نشده است (گزارش شخص ثالثی که آزمایش سرویس های مشترک را پوشش می دهد، تحت یک توافق نامه عدم افشا و در صورت درخواست در دسترس مشتریان است).
مشتریان باید، و تشویق می شوند تا نقاط پایانی 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 وجود دارد. مشتریان ممکن است انتخاب کنند که از حافظه پنهان، نقشه های ارزش کلیدی یا تجزیه و تحلیل برای ذخیره سازی داده استفاده کنند. هیچ یک از این خدمات برای ذخیره سازی CHD بر اساس ممیزی PCI Apigee مجاز نیستند. طبق الزامات PCI 3 (محافظت از داده های ذخیره شده دارنده کارت) ، داده های PCI باید فقط در مکان های سازگار با PCI ذخیره شوند. استفاده از این خدمات برای مشتریان برای ذخیره داده های غیر PCI یا سایر داده های نامحدود مشروط به الزامات امنیتی و قانونی مشتری در دسترس است. این سرویسها اقلام سلفسرویس مشتری هستند، بنابراین مسئولیت پیکربندی آنها به گونهای است که CHD را ضبط یا ذخیره نکنید. برای جلوگیری از استفاده تصادفی یا مخرب از سرویسهای ذخیرهسازی داده در Edge به روشی غیرمنطبق، بررسی پیکربندی، خطمشیها و استقرار توسط مدیران مشتری توصیه میشود.
رمزگذاری داده ها
ابزارهای رمزگذاری داده ها برای استفاده در داخل Edge به مشتریان ارائه نمی شود. با این حال، مشتریان می توانند قبل از ارسال به Edge، داده های PCI خود را رمزگذاری کنند. شرط PCI 4: (رمزگذاری انتقال داده های دارنده کارت در شبکه های باز و عمومی) توصیه می شود داده های دارنده کارت را در شبکه های باز و عمومی رمزگذاری کنید. داده های رمزگذاری شده در محموله (یا متن پیام) مانع از عملکرد Edge نمی شود. برخی از خطمشیهای Edge در صورت دریافت رمزگذاری شده توسط مشتری، ممکن است نتوانند با دادهها تعامل داشته باشند. به عنوان مثال، اگر خود داده برای تغییر در دسترس Edge نباشد، تبدیل امکان پذیر نیست. اما سایر خطمشیها و سیاستها و بستههای ساخته شده توسط مشتری حتی اگر محموله داده رمزگذاری شده باشد، کار خواهند کرد.