Membatasi cakupan kepatuhan untuk lingkungan PCI di Google Cloud

Dokumen ini menjelaskan praktik terbaik untuk merancang lingkungan cloud sesuai dengan kepatuhan Payment Card Industry (PCI) Security Standards Council. Praktik terbaik ini berguna bagi organisasi yang memigrasikan atau mendesain sistem di cloud yang tunduk pada persyaratan kepatuhan PCI. Dokumen ini mengacu pada persyaratan PCI DSS 4.0 jika berlaku.

Memahami ruang lingkup penilaian PCI DSS

Jika organisasi Anda terlibat dalam perdagangan melalui internet, Anda perlu mendukung dan menjaga kepatuhan terhadap PCI. Cara Anda mendesain dan mengelola lingkungan cloud akan memengaruhi cakupan sistem Anda untuk penilaian Standar Keamanan Data (DSS) PCI. Pencakupan memiliki implikasi penting bagi keamanan aset IT dan kemampuan Anda untuk mendukung dan menjaga kepatuhan terhadap PCI. Untuk memastikan bahwa lingkungan PCI tercakup dengan benar, Anda perlu memahami bagaimana proses bisnis dan keputusan desain dapat memengaruhi cakupan.

Apa yang dimaksud dengan ruang lingkup?

Semua sistem yang menyimpan, memproses, atau mengirimkan data pemegang kartu (CHD) berada dalam cakupan penilaian PCI DSS Anda. Keamanan penting untuk seluruh lingkungan cloud Anda, tetapi penyusupan sistem dalam cakupan dapat menyebabkan pelanggaran data dan kebocoran CHD.

Pada Gambar 1, lingkungan data pemegang kartu (CDE), sistem yang terhubung ke sistem dan sistem yang berdampak pada keamanan berada di dalam batas cakupan penilaian, sementara sistem yang tidak tepercaya dan di luar ruang lingkup berada di luar batas ruang lingkup penilaian singkat ini.

Menurut PCI DSS, sistem dalam cakupan adalah tepercaya. Sistem dalam cakupan mencakup CDE dan sistem apa pun yang terhubung ke, atau dapat memengaruhi, keamanan CDE Anda.

Sistem terhubung ke jika berada pada jaringan yang sama, berbagi database atau penyimpanan file, atau memiliki akses, konektivitas ke sistem, atau proses apa pun yang berada dalam CDE, tetapi tidak memiliki akses langsung ke CHD.

Suatu sistem berdampak pada keamanan jika dapat disusupi, maka memungkinkan bagi penyerang untuk mendapatkan akses ke CDE. Semua sistem yang terhubung dan berdampak pada keamanan selalu berada dalam cakupan.

Sistem di luar cakupan untrusted menurut definisi PCI DSS, dan tidak memiliki nilai bagi penyerang yang ingin mendapatkan akses ke CHD atau data autentikasi sensitif (SAD). Suatu sistem berada di luar ruang lingkup jika tidak dapat berdampak pada keamanan sistem dalam ruang lingkup, meskipun sistem di luar ruang lingkup disusupi. Meskipun sistem di luar cakupan tidak dinilai secara langsung, PCI Qualified Security Assessor (QSA) memverifikasi bahwa cakupan Anda akurat dan melindungi CHD berdasarkan PCI DSS. Oleh karena itu, batas cakupan Anda harus dilindungi dengan ketat, dipantau secara terus-menerus dan menyeluruh, serta didokumentasikan dengan jelas.

Koneksi dalam konteks PCI

Beberapa persyaratan PCI DSS mereferensikan koneksi, tetapi PCI DSS tidak secara eksplisit menentukan koneksi. Anda dapat menafsirkan arti koneksi dalam konteks ini dengan memahami pohon keputusan pencakupan dalam Panduan PCI SSC untuk pencakupan dan segmentasi jaringan PCI DSS (PDF).

Untuk tujuan mengevaluasi cakupan PCI, koneksi ditentukan oleh hal berikut:

• Transportasi informasi aktif yang menghubungkan dua komputer atau sistem
• Manakah dari dua pihak yang memulai panggilan

Saat mendokumentasikan lingkungan, sebaiknya tunjukkan dengan jelas pihak mana yang diizinkan untuk memulai koneksi. Firewall yang dikonfigurasi hanya untuk mengizinkan lalu lintas dalam satu arah dapat menerapkan koneksi satu arah. Misalnya, aplikasi pemrosesan pembayaran dalam cakupan dapat membuat kueri ke server database tanpa server di luar cakupan yang akan masuk ke dalam cakupan jika semua hal berikut benar:

• Koneksi dan database di luar cakupan tidak menyimpan, memproses, atau mengirimkan CHD atau SAD.
• Database berada di jaringan terpisah atau disegmentasikan dari CDE.
• Database tidak dapat memulai panggilan apa pun ke CDE secara langsung atau tidak langsung.
• Database tidak menyediakan layanan keamanan ke CDE.
• Database tidak memengaruhi konfigurasi atau keamanan CDE.
• Database mendukung persyaratan PCI DSS.

Diagram berikut menunjukkan faktor yang menentukan cakupan sistem:

Pada gambar 2, cakupan sistem ditentukan sebagai berikut:

• Komponen sistem yang tercakup dalam PCI DSS:

  • Sistem yang berada dalam CDE memiliki salah satu hal berikut:
    • Komponen sistem menyimpan, memproses, atau mengirimkan CHD atau SAD.
    • Komponen sistem berada pada segmen jaringan yang sama, misalnya pada subnet atau VLAN yang sama dengan sistem yang menyimpan, memproses, atau mengirimkan CHD.
  • Sistem yang terhubung ke sistem yang berdampak pada keamanan atau yang mengalami salah satu hal berikut:
    • Komponen sistem terhubung langsung ke CDE.
    • Komponen sistem berdampak pada konfigurasi atau keamanan CDE.
    • Komponen sistem mengelompokkan sistem CDE dari sistem dan jaringan di luar cakupan.
    • Komponen sistem secara tidak langsung terhubung ke CDE.
    • Komponen sistem menyediakan layanan keamanan ke CDE.
    • Komponen sistem mendukung persyaratan PCI DSS.

• Komponen sistem dapat dianggap tidak tepercaya dan berada di luar cakupan PCI DSS jika semua hal berikut berlaku:

  • Komponen sistem tidak menyimpan, memproses, atau mengirimkan CHD atau SAD.
  • Komponen sistem bukan merupakan segmen jaringan yang sama, misalnya pada subnet atau VLAN yang sama, dengan sistem yang menyimpan, memproses, atau mengirimkan CHD atau SAD.
  • Komponen sistem tidak dapat terhubung ke sistem apa pun di CDE.
  • Komponen sistem tidak memenuhi kriteria apa pun untuk sistem yang terhubung ke atau yang berdampak pada keamanan.

  Sistem di luar cakupan dapat mencakup sistem yang terhubung ke komponen sistem yang terhubung atau berdampak pada keamanan, di mana kontrol yang ada digunakan untuk mencegah sistem di luar ruang lingkup untuk mendapatkan akses ke CDE dengan menggunakan komponen sistem dalam ruang lingkup.

Dalam istilah praktis, definisi cakupan sistem PCI DSS dapat berarti bahwa penyimpanan sesi dan database e-commerce aplikasi web Anda mungkin memenuhi syarat sebagai di luar cakupan jika segmentasi diterapkan dan didokumentasikan dengan benar. Diagram berikut menunjukkan cara kerja koneksi baca dan tulis antara sistem dalam cakupan dan sistem di luar cakupan:

Gambar 3 menunjukkan koneksi berikut:

• Hanya baca:
  • Aplikasi pemrosesan pembayaran dalam cakupan membaca ID keranjang dari database keranjang yang berada di luar cakupan serta membaca data dari DNS dan NTP.
• Hanya tulis:
  • Aplikasi pemrosesan pembayaran dalam cakupan menulis ke database utama aplikasi di luar cakupan dan Cloud Logging.
  • Aplikasi web utama di luar cakupan menulis data ke layanan logging. Data ini tidak termasuk CHD atau SAD.
• Membaca dan menulis:
  • Pengguna web publik membaca dan menulis metadata permintaan sebagai berikut:
    • Pengguna membaca dan menulis ke aplikasi pemrosesan pembayaran dalam cakupan. Metadata permintaan ini adalah ID keranjang dan kunci autentikasi keranjang yang berisi CHD dan SAD.
    • Pengguna membaca dan menulis ke aplikasi web utama di luar cakupan. Metadata permintaan ini adalah ID sesi yang tidak berisi CHD atau SAD.
  • Aplikasi web utama di luar cakupan membaca dan menulis data ke database keranjang yang berada di luar cakupan, penyimpanan sesi, dan database utama aplikasi. Data ini tidak termasuk CHD atau SAD.
  • Aplikasi pemrosesan pembayaran dalam cakupan membaca dan menulis data ke layanan tokenisasi kartu dalam cakupan dan ke pemroses kartu kredit di web publik. Data ini mencakup CHD dan SAD.

Arsitektur pada gambar 3 menggambarkan dua aplikasi web terpisah: aplikasi web utama (aplikasi utama) yang berada di luar cakupan PCI, dan aplikasi pemrosesan pembayaran (aplikasi checkout) yang berada dalam cakupan. Pada arsitektur ini, koneksi dapat dimulai antara dua entity hanya dalam petunjuk yang dijelaskan pada daftar sebelumnya. Koneksi antar-entity dapat bersifat hanya baca, baca dan tulis, atau hanya tulis dari perspektif pemanggil. Setiap jalur atau arah permintaan yang tidak dijelaskan secara eksplisit akan diblokir oleh segmentasi. Misalnya, aplikasi pemrosesan pembayaran dapat membaca dari database keranjang dan menulis ke layanan logging yang melibatkan inisialisasi koneksi ke entity tersebut.

Sistem dalam ruang lingkup biasanya disebut sistem dan layanan di luar ruang lingkup. Koneksi ini tetap aman karena segmentasi mencegah pemanggil jarak jauh (selain pemegang kartu) untuk memulai koneksi ke CDE secara langsung atau tidak langsung. Gambar 3 menunjukkan bahwa satu-satunya jalur masuk ke aplikasi checkout adalah dari pengguna.

Pada Gambar 3, tidak ada layanan atau aplikasi di luar cakupan yang menyediakan konfigurasi atau data keamanan apa pun ke aplikasi pemrosesan pembayaran. Data mengalir melalui arsitektur sebagai berikut:

1. Aplikasi utama meneruskan pengguna ke aplikasi checkout dan menggunakan POST HTTP untuk mengirimkan CartID dan validator yang disebut CartAuthKey. CartAuthKey adalah hash dari CartID dan rahasia pra-berbagi yang hanya diketahui untuk aplikasi utama dan checkout.
2. Aplikasi checkout memvalidasi pengguna dengan melakukan hashing CartID bersama dengan rahasia dan membandingkan nilai tersebut dengan CartAuthKey.
3. Setelah data pengguna diautentikasi, CartID akan digunakan untuk membaca konten keranjang dari database keranjang. Semua data pemegang kartu dikirim dari pengguna langsung ke aplikasi checkout.
4. Jika profil pembayaran digunakan, data pemegang kartu akan disimpan di layanan tokenisasi.
5. Setelah pembayaran diproses, hasilnya dimasukkan ke dalam database aplikasi utama dengan akun layanan database hanya tulis.

Pertimbangan cakupan

Dalam Panduan untuk pencakupan dan segmentasi jaringan PCI DSS, PCI Security Standards Council (SSC) merekomendasikan agar Anda mengasumsikan bahwa semuanya berada dalam cakupan hingga diverifikasi sebaliknya. Rekomendasi SSC ini tidak berarti bahwa Anda harus membuat cakupan seluas mungkin. sebaliknya, QSA akan menilai semua sistem seolah-olah sistem tersebut tepercaya, kecuali jika Anda dapat menunjukkan bahwa sistem tidak memiliki konektivitas atau dampak keamanan pada CDE. Untuk memenuhi persyaratan kepatuhan terhadap peraturan dan menjaga keamanan aset IT, Anda harus mengatur lingkungan sesuai dengan prinsip hak istimewa terendah dengan memercayai sistem sesedikit mungkin.

Sebelum penilaian, evaluasi lingkungan Anda untuk memahami dan mendokumentasikan batas antara sistem dalam ruang lingkup dan di luar ruang lingkup. Tugas pertama QSA adalah mengonfirmasi bahwa cakupan yang didokumentasikan secara wajar mengenkapsulasi CDE dan sistem yang terhubung. Sebagai bagian dari penilaian keseluruhan, QSA kemudian memverifikasi bahwa sistem di luar ruang lingkup tidak memberikan dampak negatif pada sistem dalam ruang lingkup.

Pastikan Anda memahami setiap keadaan khusus yang spesifik bagi lingkungan, seperti pada berikut:

• Jika Anda mengumpulkan data pemegang kartu melalui telepon atau melalui sistem VOIP, pertimbangkan masalah cakupan tambahan yang dijelaskan dalam Melindungi data kartu pembayaran berbasis telepon (PDF).
• Jika penyedia layanan Anda memerlukan akses ke CDE (PDF) untuk mengoperasikan sistem tempat penjualan, sistem yang digunakan penyedia layanan Anda dapat dianggap sebagai sistem yang terhubung ke sistem. Hal ini mungkin memerlukan pertimbangan cakupan dan uji kelayakan tambahan.

Praktik terbaik keamanan Google dapat membantu Anda menetapkan dan menunjukkan batas yang jelas dan dapat dipertahankan antara sistem dalam cakupan dan sistem tidak tepercaya, yang akan membantu penilaian Anda. Saat mengelola akses dan keamanan dengan menerapkan prinsip hak istimewa terendah, Anda membantu meminimalkan jumlah titik eksposur untuk data pemegang kartu, meminimalkan area serangan pada CDE, dan akibatnya akan mengurangi ruang lingkup proyek Anda. Saat mengurangi jejak sistem dalam cakupan, Anda membantu mengurangi kompleksitas sistem dan menyederhanakan penilaian PCI DSS.

Risiko pemberian cakupan yang salah

Cakupan yang terlalu luas dapat menyebabkan penilaian yang mahal dan meningkatkan risiko kepatuhan. Untuk membantu mempertahankan cakupan yang sempit, percayakan sesedikit mungkin sistem dan berikan akses hanya ke beberapa pengguna tertentu yang ditetapkan. Melalui evaluasi dan penilaian mandiri yang cermat, Anda dapat mengidentifikasi sistem yang seharusnya tidak termasuk dalam cakupan PCI DSS, memverifikasi bahwa sistem tersebut memenuhi pedoman untuk sistem di luar ruang lingkup, dan mengurangi cakupan sebagaimana mestinya. Proses eliminasi ini adalah cara paling aman untuk menemukan sistem mana yang tidak tepercaya, dan membantu memastikan bahwa sistem tersebut tidak dapat memengaruhi sistem dalam cakupan.

Jika Anda memerlukan jejak infrastruktur yang besar untuk memenuhi persyaratan PCI DSS, sistem yang tidak relevan dapat disertakan dalam cakupan penilaian. Saat Anda menyertakan sistem yang tidak relevan dalam cakupan, hal tersebut berisiko terhadap kemampuan untuk mencapai kepatuhan. Hal ini juga dapat menurunkan postur keamanan Anda secara keseluruhan dengan memperluas area serangan pada lingkungan dalam cakupan tepercaya.

Prinsip inti keamanan jaringan dan PCI DSS adalah dengan mengasumsikan bahwa sebagian atau semua jaringan Anda telah disusupi. Prinsip ini tertuang dalam model keamanan zero-trustGoogle, yang menolak keamanan khusus perimeter dan mendukung model di mana setiap sistem bertanggung jawab untuk mengamankan dirinya sendiri. Model keamanan Google selaras dengan PCI DSS yang merekomendasikan agar CDE dan sistemnya yang terhubung di-deploy di ruang kecil yang tepercaya dan tersegmentasi dari lingkungan IT Anda yang lebih luas dan tidak bercampur dengannya.

Dalam lingkungan PCI dalam cakupan Anda, jangan tempatkan CDE di ruang yang besar dan tepercaya dengan perimeter yang luas. Melakukannya dapat menciptakan kesan keamanan yang palsu dan merusak strategi defense-in-depth secara menyeluruh. Jika melanggar keamanan perimeter, penyerang dapat beroperasi dengan mudah di dalam intranet pribadi yang tepercaya. Pertimbangkan cara agar Anda dapat memperketat ruang tepercaya agar hanya memuat hal yang diperlukan untuk beroperasi dan mengamankan dirinya sendiri, serta menghindari hanya mengandalkan keamanan perimeter. Dengan memahami dan mengikuti prinsip ini, Anda dapat mendesain lingkungan cloud untuk membantu mengamankan sistem penting dan mengurangi risiko kontaminasi dari sistem yang disusupi.

Lingkungan sistem tepercaya yang luas dan dalam cakupan memerlukan alat pengelolaan yang besar untuk mempertahankan pemantauan, pemeliharaan, audit, dan inventaris sistem ini secara berkelanjutan. Kompleksitas arsitektur sistem, proses manajemen perubahan, dan kebijakan kontrol akses dapat menimbulkan risiko keamanan dan kepatuhan. Kesulitan dalam mempertahankan proses pemantauan ini dapat menyebabkan kesulitan dalam memenuhi persyaratan PCI DSS 10 dan 11. Penting untuk memahami risiko ini, dan menerapkan strategi untuk membatasi ruang lingkup lingkungan yang dievaluasi. Untuk informasi selengkapnya, lihat Mendukung kepatuhan berkelanjutan nanti dalam dokumen ini.

Layanan Google Cloud dalam cakupan PCI DSS

Sebelum Anda mulai mengurangi cakupan lingkungan PCI, pahami layanan Google Cloud mana yang termasuk dalam cakupan untuk PCI DSS. Layanan ini menyediakan infrastruktur yang dapat Anda gunakan untuk membuat layanan atau aplikasi Anda sendiri yang menyimpan, memproses, atau mengirim data pemegang kartu.

Strategi untuk mengurangi ruang lingkup

Bagian ini membahas tentang strategi untuk mengurangi cakupan penilaian: kontrol hierarki resource, segmentasiKontrol Layanan VPC dan tokenisasi. Daripada memilih satu pendekatan, pertimbangkan untuk menggunakan semua strategi ini guna memaksimalkan potensi pengurangan cakupan Anda.

Tidak ada solusi universal untuk pencakupan PCI. Anda mungkin telah menerapkan segmentasi di jaringan lokal, atau solusi pemrosesan kartu yang dapat menyebabkan desain infrastruktur Anda terlihat sedikit berbeda dibandingkan dengan yang dijelaskan di sini. Gunakan strategi ini sebagai prinsip yang dapat diterapkan pada lingkungan Anda sendiri.

Menetapkan kontrol hierarki resource

Resource Google Cloud diatur secara hierarkis sebagai berikut:

• Resource Organisasi adalah node root dalam hierarki resource Google Cloud. Resource organisasi berisi resource folder dan project. Kebijakan kontrol akses Identity and Access Management (IAM) yang diterapkan ke resource Organisasi akan berlaku di seluruh hierarki pada semua resource di organisasi.
• Folder dapat berisi project dan folder lain, serta mengontrol akses ke resource-nya menggunakan izin IAM level folder. Folder umumnya digunakan untuk mengelompokkan project yang serupa.
• Project adalah batas kepercayaan untuk semua resource Anda dan merupakan titik penerapan IAM.

Untuk membantu mengurangi cakupan penilaian, ikuti praktik terbaik Google untuk menentukan hierarki resource Anda. Gambar berikut menunjukkan contoh hierarki resource untuk kepatuhan PCI:

Pada Gambar 4, semua project yang berada dalam cakupan PCI dikelompokkan dalam satu folder untuk diisolasi pada level folder. Folder cakupan PCI berisi CDE dan project lain yang berisi layanan bersama. Saat Anda menerapkan hierarki resource yang sama, folder cakupan PCI akan membentuk root logis dari cakupan kepatuhan PCI Anda. Dengan memastikan bahwa hanya pengguna yang ditetapkan yang memiliki akses ke folder dan project ini, Anda dapat mengecualikan folder, project, dan resource lain dalam hierarki Anda dari cakupan penilaian.

Saat Anda memberi pengguna akses hanya ke folder dan project yang diperlukan sesuai kebutuhan, pastikan bahwa hanya pengguna yang ditetapkan yang memiliki akses ke komponen dalam cakupan. Panduan ini mendukung persyaratan PCI DSS 7.2 dan 7.3 (PDF), dan lainnya. Untuk memastikan izin untuk Organisasi dan folder induk ditetapkan dengan tepat, pahami implikasi pewarisan kebijakan. Untuk mendukung persyaratan PCI DSS 8.4.1, pastikan untuk menerapkan autentikasi multi-faktor (MFA) bagi pengguna yang ditentukan, dan lihat pelengkap PCI DSS terkait panduan untuk autentikasi multi-faktor (PDF). Untuk memastikan kepatuhan dalam hierarki resource, pastikan Anda memahami cara menetapkan Batasan kebijakan organisasi. Batasan ini mendukung kepatuhan berkelanjutan dan dapat membantu melindungi lingkungan tepercaya Anda dari eskalasi akses.

Sama halnya dengan semua kepatuhan PCI, logging dan pemantauan yang memadai terhadap lingkungan dan komponen cakupannya diperlukan untuk menetapkan batas cakupan yang jelas. Hierarki resource terkait erat dengan pengelolaan akses dan identitas. Selain itu, logging, audit, dan pemantauan tindakan pengguna yang efektif diperlukan untuk menerapkan dan mempertahankan pemisahan.

Menerapkan segmentasi jaringan

Segmentasi jaringan adalah pola arsitektur penting untuk membantu mengamankan CDE dan sistem terhubung Anda, seperti yang dijelaskan dalam panduan tambahan tentang segmentasi jaringan (PDF) PCI SSC. Jika diterapkan dengan benar, segmentasi jaringan akan mempersempit cakupan penilaian Anda dengan menghapus rute jaringan yang mungkin digunakan oleh sistem yang tidak tepercaya untuk mengakses CDE atau komponen yang terhubung. Hanya tentukan rute yang diperlukan untuk memungkinkan komunikasi antar-komponen tepercaya. Jika sistem tidak tepercaya tidak memiliki rute untuk mengirim atau menerima paket dari sistem tepercaya, maka sistem tidak tepercaya berada di luar cakupan dan tidak dapat memengaruhi keamanan dalam ruang lingkup komponen Anda.

Untuk mengimplementasikan segmentasi jaringan, tempatkan CDE Anda di Virtual Private Cloud (VPC) khusus dengan mengaktifkan Kontrol Layanan VPC. Buat VPC ini dalam mode kustom untuk memastikan tidak ada subnet atau rute asing yang dibuat yang mungkin mengaktifkan akses default ke jaringan tepercaya. Terapkan batasan kebijakan organisasi untuk memastikan bahwa VPC ini tidak dapat dibagikan dengan project lain, dan hanya dapat di-peering dengan jaringan tepercaya lainnya.

Diagram berikut menunjukkan bagaimana strategi segmentasi jaringan sangat berkaitan dengan hierarki resource. Diagram ini mengasumsikan hierarki resource dengan satu folder untuk lingkungan PCI dalam cakupan Anda, dan dua project dalam folder tersebut untuk CDE dan layanan bersama.

Pada Gambar 5, project layanan bersama bukan bagian dari CDE, tetapi merupakan sistem yang terhubung ke, sehingga berada dalam cakupan PCI. Akses ke CDE dibatasi pada tingkat jaringan oleh load balancer dan aturan firewall atau kebijakan firewall untuk melindungi jaringan ini dan memenuhi persyaratan PCI DSS 1.2 dan 1.3. Sistem tokenisasi dan pembayaran ditempatkan pada subnet terpisah, dan komunikasinya diatur oleh aturan firewall di antara setiap subnet untuk mengizinkan komunikasi yang diperlukan saja. Fungsi logging, pemantauan, dan pemberitahuan yang diperlukan yang memenuhi Persyaratan PCI DSS 10.2, 10.4, dan 10.5 berada di project yang terpisah. Layanan bersama dan CDE berada di dalam perimeter keamanan Kontrol Layanan VPC untuk melindungi dari kesalahan konfigurasi yang tidak disengaja atau penyusupan terhadap kontrol akses IAM.

Jika deployment Anda dilakukan di Google Kubernetes Engine (GKE), berikut adalah cara lain untuk mengelompokkan CDE dan melindungi data pemegang kartu dari sistem yang tidak tepercaya:

• Namespace menawarkan lapisan tambahan isolasi kontrol akses sehingga pengguna hanya dapat diberi akses ke Pod, layanan, dan deployment tertentu dalam cluster Kubernetes Anda. Hal ini berguna untuk memberikan akses yang lebih terperinci ke pengguna yang diizinkan.
• Kebijakan jaringan dapat mengisolasi Pod dan layanan satu sama lain untuk membatasi aliran data, dan dapat memberikan lapisan segmentasi jaringan tambahan dalam cluster Anda.
• PodSecurity adalah pengontrol penerimaan Kubernetes yang dapat digunakan untuk menerapkan Standar Keamanan Pod ke Pod yang berjalan di cluster GKE.

Setiap lapisan ini membentuk bagian penting dari postur keamanan pertahanan yang mendalam dan membantu mempersempit cakupan dengan mengisolasi dan melindungi lebih lanjut komponen tepercaya dari lingkungan di sekitarnya. Jika Anda men-deploy semua atau sebagian CDE dengan Kubernetes, pelajari lebih lanjut cara menjalankan lingkungan yang sesuai dengan PCI di GKE.

Mengimplementasikan tokenisasi

Tokenisasi adalah proses mengaburkan nomor akun utama (PAN) secara permanen. PAN yang ditokenkan, atau token, tidak dapat ditukarkan dengan PAN melalui cara matematika. PCI SSC menawarkan panduan tentang pencakupan dampak tokenisasi dalam Bab 3 pelengkapan panduan tokenisasi (PDF). Cakupan PCI DSS dipengaruhi oleh kumpulan komponen yang menyimpan dan mengirimkan data pemegang kartu. Jika diterapkan dengan benar, tokenisasi dapat membantu mengurangi cakupan penilaian dengan meminimalkan kemunculan dan pengiriman nomor akun utama.

Tokenisasi juga merupakan bentuk segmentasi berdasarkan aliran data karena memisahkan sistem yang menyimpan dan mengirim data pemegang kartu dari sistem yang dapat melakukan operasi menggunakan token saja. Misalnya, sistem yang menganalisis aktivitas konsumen untuk penipuan mungkin tidak memerlukan PAN, tetapi melakukan analisis menggunakan data berupa token. Tokenisasi juga menambahkan lapisan pemisah antara sistem yang menyimpan dan mengirimkan PAN dan aplikasi web e-commerce Anda. Saat aplikasi web Anda hanya berinteraksi dengan sistem yang menggunakan token, aplikasi web tersebut dapat berpotensi dihapus dari kumpulan sistem yang terhubung ke internet sehingga mengurangi cakupan.

Diagram berikut menunjukkan cara penanganan CHD, PAN, dan data berupa token dalam sistem tokenisasi standar:

Pada Gambar 6, PAN dan data pemegang kartu lainnya diterima dari pengguna, lalu data segera dikirim ke layanan tokenisasi. Layanan tokenisasi mengenkripsi PAN, membuat token, lalu menyimpan keduanya di vault token yang aman. Hanya layanan yang ditetapkan, seperti layanan pelunasan, yang dapat mengakses vault di jaringan dan diizinkan untuk menukarkan PAN menggunakan token yang dihasilkan. Layanan pelunasan hanya menggunakan PAN untuk mengirimkannya ke pemroses pembayaran. PAN atau data pemegang kartu lainnya tidak pernah terjadi di luar aliran data yang dikontrol ketat. Sebagai bagian dari strategi defense in depth, arsitektur ini juga menggunakan Perlindungan Data Sensitif sebagai lapisan pertahanan lain terhadap kebocoran PAN atau data pemegang kartu lainnya yang tidak diinginkan.

Pada gambar 6, sistem tokenisasi menggunakan Hashicorp Vault, penyimpanan rahasia yang dijaga ketat untuk mengelola pemetaan PAN-ke-token. Hanya pengguna dan layanan yang diizinkan yang dapat menukarkan PAN dari token menggunakan proses pencarian. Komponen yang diberi izin untuk mengakses vault token dapat diberi akses dengan batasan waktu sehingga komponen tersebut hanya dapat menukarkan PAN selama jangka waktu tertentu yang diperlukan untuk menjalankan fungsinya. Penyimpanan data lainnya dapat disesuaikan dengan kebutuhan bisnis Anda. Untuk mengetahui informasi selengkapnya tentang cara mengimplementasikan tokenisasi dengan aman di lingkungan Anda, lihat Membuat token data pemegang kartu sensitif untuk PCI DSS.

Contoh arsitektur

Diagram berikut mengilustrasikan contoh arsitektur untuk memproses transaksi dengan token menggunakan Pub/Sub dan Dataflow, serta menyimpan data transaksi dengan token di Spanner.

Pada Gambar 7, project pemrosesan transaksi adalah sistem terhubung ke, dan dalam cakupan untuk PCI. Hal ini tidak memengaruhi keamanan, karena penyusupan komponen apa pun dalam project pemrosesan transaksi tidak dapat memberi penyerang akses ke CHD. Project webapp berada di luar cakupan karena tidak terhubung ke CDE dan hanya berinteraksi dengan data yang bersih.

Data berupa token dikirim dari CDE ke Pub/Sub. Sebelum data bertoken dipublikasikan ke pelanggan lain, Sensitive Data Protection akan memverifikasi bahwa data tersebut tidak berisi CHD. Data yang berupa token akan diproses oleh Dataflow dan disimpan di database transaksi Spanner. Transaksi dapat dikaitkan dengan pengguna tertentu melalui token tanpa mengakses PAN. Database transaksi Spanner juga dapat digunakan untuk pelaporan dan analisis menggunakan alat business intelligence (BI) seperti Looker.

Mendukung kepatuhan berkelanjutan

Keamanan dan kepatuhan lebih dari sekadar arsitektur yang tepat dan teknik yang baik. Arsitektur yang benar dapat menunjukkan bahwa lingkungan Anda dirancang dengan aman secara teori. Anda juga memerlukan proses audit, logging, pemantauan, dan perbaikan yang efektif untuk membantu memastikan lingkungan Anda tetap amansaat praktik.

Untuk mendukung kepatuhan terhadap masing-masing 12 kategori persyaratan PCI DSS, Anda harus memantau penerapan persyaratan tersebut secara berkelanjutan. Anda harus membuktikan kepada diri sendiri dan penilai bahwa komponen dalam cakupan akan tetap aman di masa mendatang, lama setelah penilaian PCI DSS selesai. Pengawasan tepat yang dipasangkan dengan tindakan perbaikan cepat disebut dengan kepatuhan berkelanjutan. Kepatuhan berkelanjutan adalah persyaratan PCI DSS, jika diterapkan dengan benar, hal ini dapat membantu memaksimalkan efek dari strategi pengurangan cakupan lainnya.

Google Cloud dapat Anda gunakan untuk mencatat segala hal yang terjadi di jaringan Anda ke dalam log menggunakan Firewall Rules Logging, VPC Flow Logs, log Kontrol Layanan VPC, dan log Cloud Load Balancing. Anda dapat memantau aktivitas sistem dan pengguna menggunakan Cloud Audit Logs. Memantau log ini secara rutin membantu Anda mematuhi Persyaratan PCI DSS 10.4, dan memungkinkan Anda merespons serta memulihkan potensi ancaman keamanan dengan cepat. Untuk mengetahui informasi selengkapnya, lihat Pelengkap PCI DSS tentang pemantauan log harian yang efektif (PDF).

Security Command Center memungkinkan Anda memahami keamanan dan area serangan data Anda dengan menyediakan inventaris aset, penemuan, penelusuran, dan pengelolaan. Security Command Center dapat menganalisis hasil pemindaian Perlindungan Data Sensitif untuk membantu mengidentifikasi kebocoran data pemegang kartu, dan membantu memverifikasi bahwa sistem tokenisasi Anda tidak disalahgunakan untuk menukarkan PAN dengan niat jahat. Dengan menggunakan Event Threat Detection, Security Command Center dapat membantu Anda secara proaktif mendeteksi ancaman dan aktivitas tidak biasa di jaringan dan VM, serta dapat menunjukkan bahwa penyerang mungkin memeriksa sistem untuk mengidentifikasi kemampuan pertahanannya. Security Command Center juga memungkinkan Anda membuat sumber keamanan kustom yang spesifik untuk lingkungan Anda.

Google Cloud Armor dapat memberikan perlindungan tambahan untuk aplikasi web Google Cloud yang ditampilkan kepada publik dan membantu Anda mematuhi Persyaratan PCI DSS 6.4. Google Cloud Armor mengevaluasi permintaan masuk untuk berbagai serangan web umum dan dapat membantu Anda menghindari peninjauan kode manual yang memakan banyak tenaga, yang ditentukan dalam persyaratan 6.4. Dengan menerapkan WAF, Anda dapat menjaga kepatuhan secara berkelanjutan sekaligus mengurangi biaya dan risiko kepatuhan yang berkelanjutan.

Langkah selanjutnya

• Tinjau praktik terbaik untuk mengelola kewajiban kepatuhan.
• Baca Kepatuhan standar keamanan data PCI di Google Cloud.
• Panduan PCI Council untuk cakupan dan segmentasi jaringan PCI DSS (PDF).
• Coba PCI pada blueprint GKE.
• Amankan workload Kubernetes Anda untuk PCI DSS.
• Membuat token data pemegang kartu sensitif untuk PCI DSS.
• Deploy project Terraform PCI Starter.
• Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.