Panduan ini membantu Anda mempelajari cara menerapkan Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS) untuk bisnis Anda di Google Cloud. Panduan ini tidak hanya membahas Panduan Cloud Computing PCI SSC (PDF) untuk memberikan latar belakang tentang standar, menjelaskan peran Anda dalam kepatuhan berbasis cloud, lalu memberi Anda panduan untuk mendesain, men-deploy, dan mengonfigurasi aplikasi pemrosesan pembayaran menggunakan PCI DSS. Tutorial ini juga membahas metode untuk memantau, mencatat log, dan memvalidasi aplikasi Anda.
Dokumen ini merujuk pada persyaratan PCI DSS 4.0 jika berlaku.
Standar Keamanan Data PCI, yang dibuat oleh PCI Security Standards Council, adalah standar keamanan informasi untuk bisnis yang menangani informasi kartu pembayaran (baik kredit maupun debit). PCI Security Standards Council mencakup setiap perusahaan kartu pembayaran utama. Bisnis yang menerima Visa, MasterCard, Discover, American Express, JCB, atau UnionPay diharapkan mematuhi PCI DSS, dan mereka dapat didenda atau dikenai sanksi jika tidak mematuhinya.
PCI DSS mencakup klasifikasi untuk beberapa jenis penjual, mulai dari penjual yang mengumpulkan informasi pembayaran secara langsung hingga penjual yang sepenuhnya melakukan outsourcing pemrosesan pembayaran. Panduan ini membahas jenis penjual SAQ A, SAQ A-EP, dan SAQ D.
Tujuan
- Tinjau arsitektur aplikasi pemrosesan pembayaran.
- Siapkan lingkungan pemrosesan pembayaran Anda.
- Men-deploy dan mengonfigurasi server aplikasi.
- Siapkan logging dan monitoring.
- Validasi lingkungan pemrosesan pembayaran Anda.
Definisi
Panduan ini menggunakan banyak frasa unik. Berikut beberapa yang paling umum. Untuk mengetahui informasi selengkapnya, lihat glosarium PCI DSS.
CDE: Singkatan dari lingkungan data pemegang kartu. Akronim ini mengacu pada bagian aplikasi Anda yang menyimpan atau mentransfer data pemegang kartu, termasuk nomor akun pembayaran atau informasi identitas pribadi apa pun yang terkait dengan kartu.
Kontrol kompensasi: Solusi alternatif yang dapat dipertimbangkan jika entitas tidak dapat memenuhi persyaratan secara eksplisit seperti yang dinyatakan, karena batasan bisnis teknis atau terdokumentasi yang sah. Entitas harus memitigasi risiko yang terkait dengan persyaratan tersebut secara memadai saat menerapkan kontrol lain ini. Lihat "Kontrol Kompensasi" Lampiran B dan C dalam Persyaratan PCI DSS dan Prosedur Penilaian Keamanan untuk mendapatkan panduan tentang penggunaan kontrol kompensasi.
PAN: Singkatan dari primary account number dan juga disebut sebagai nomor akun. Nomor ini adalah nomor kartu pembayaran unik yang mengidentifikasi penerbit dan rekening pemegang kartu.
QSA: Singkatan dari Qualified Security Assessor. QSA memenuhi syarat oleh PCI Security Standards Council (SSC) untuk melakukan penilaian PCI DSS di lokasi. Persyaratan Kualifikasi untuk Penilai Keamanan yang Memenuhi Syarat (QSA) memberikan detail tentang persyaratan untuk perusahaan dan karyawan QSA.
SAQ: Akronim untuk Kuesioner Penilaian Mandiri, alat pelaporan yang digunakan untuk mendokumentasikan hasil pemeriksaan mandiri dari penilaian PCI DSS entitas. Hal ini hanya berlaku untuk entitas yang memenuhi syarat untuk penilaian mandiri.
Cakupan: Sistem, prosedur, dan orang yang akan disertakan dalam penilaian PCI DSS.
Tokenisasi: Proses yang mengganti nomor rekening utama (PAN) dengan nilai pengganti yang disebut token. PAN kemudian disimpan dalam pencarian yang aman. De-tokenisasi adalah proses terbalik dari pencarian PAN berdasarkan tokennya. Token dapat berupa hash atau nilai yang ditetapkan.
Latar belakang
PCI DSS menyediakan daftar persyaratan yang dirancang untuk meningkatkan keamanan pemegang kartu. Persyaratan ini dibagi menjadi dua belas bagian utama yang diberi nomor dan banyak subbagian. Dokumen ini mereferensikan nomor bagian ini untuk menambahkan konteks, tetapi referensi bagian tersebut bukan daftar lengkap persyaratan yang berlaku.
Persyaratan kepatuhan PCI DSS Anda bervariasi bergantung pada cara perusahaan Anda menangani transaksi kartu pembayaran (jenis) dan jumlah transaksi yang dilakukan setiap tahun (tingkat).
Seiring meningkatnya jumlah transaksi, tingkat penjual PCI DSS Anda akan meningkat, dan pedoman kepatuhan PCI DSS akan menjadi lebih ketat. Pada tingkat penjual tertinggi, Level 1, PCI DSS memerlukan audit. Tingkatnya bervariasi menurut merek kartu. Level 1 ditentukan oleh American Express sebagai 2,5 juta transaksi tahunan, dan oleh Visa, Mastercard, dan Discover sebagai 6 juta transaksi tahunan. Setiap merek kartu memiliki persyaratan level tambahan yang berada di luar cakupan dokumen ini. Pastikan lingkungan pemrosesan pembayaran Anda diaudit untuk mendukung level penjual Anda.
Karena Google Cloud adalah penyedia layanan yang mematuhi PCI DSS 4.0 Level 1, Google Cloud dapat mendukung kebutuhan kepatuhan PCI DSS Anda, apa pun level penjual perusahaan Anda. Bagian Komitmen terhadap kepatuhan menjelaskan area mana yang ditanggung oleh Google untuk Anda.
Variabel mendasar lainnya adalah jenis SAQ Anda. SAQ menguraikan kriteria yang harus Anda penuhi untuk mematuhi PCI DSS jika Anda memenuhi syarat untuk penilaian mandiri. Jenis SAQ ditentukan oleh arsitektur aplikasi dan cara akurat Anda menangani data kartu pembayaran. Sebagian besar penjual di cloud adalah salah satu dari berikut:
| Jenis SAQ | Deskripsi |
|---|---|
| A | Penjual yang telah sepenuhnya melakukan outsourcing pemrosesan kartu pembayaran ke
situs pihak ketiga. Pelanggan meninggalkan domain Anda (termasuk melalui
formulir web <iframe>), menyelesaikan pembayaran, lalu kembali ke
aplikasi Anda.Dengan kata lain, perusahaan Anda tidak dapat menyentuh data kartu pelanggan dengan cara apa pun. |
| A-EP | Penjual yang melakukan outsourcing pemrosesan pembayaran ke penyedia pihak ketiga, tetapi
dapat mengakses data kartu pelanggan kapan saja dalam prosesnya. Penjual
yang dapat mengakses data kartu mencakup elemen halaman yang dikontrol penjual seperti
JavaScript atau CSS yang disematkan di halaman pembayaran pihak ketiga. Dengan kata lain, aplikasi pemrosesan pembayaran Anda meneruskan data kartu ke pemroses di sisi klien, atau pemroses merender konten apa pun yang dihosting oleh Anda. |
| D | Penjual yang menerima pembayaran secara online dan tidak memenuhi syarat untuk SAQ A atau
SAQ A-EP. Jenis ini mencakup semua penjual yang memanggil API pemroses pembayaran
dari server mereka sendiri, terlepas dari tokenisasi. Dengan kata lain, jika Anda bukan SAQ A atau SAQ A-EP, Anda adalah SAQ D. SAQ D membedakan antara penjual dan penyedia layanan. Penyedia layanan tidak dibahas dalam dokumen ini, dan semua referensi SAQ D membahas penjual seperti yang ditentukan dalam PCI DSS. |
Berkomitmen untuk mematuhi kebijakan
Google menggunakan berbagai teknologi dan proses untuk mengamankan informasi yang disimpan di server Google. Google memvalidasi secara independen persyaratan PCI DSS yang berlaku untuk teknologi dan infrastruktur Google Cloud yang dikelola oleh Google. Anda dapat mendownload laporan kepatuhan PCI DSS Google dari Pengelola Laporan Kepatuhan. Meskipun Google menawarkan banyak kontrol kepada penjual atas instance komputasi mereka yang berjalan di infrastruktur Google, Google tidak mengontrol keamanan untuk sistem operasi, paket, atau aplikasi yang di-deploy penjual di Google Cloud. Anda bertanggung jawab untuk mematuhi persyaratan PCI DSS untuk paket sistem operasi dan aplikasi yang Anda deploy, selain penyesuaian lain yang diperlukan oleh arsitektur Anda.
Google Cloud mengikuti persyaratan PCI DSS yang ditetapkan untuk Penyedia Layanan Level 1 dan semua persyaratan penyedia layanan yang berlaku. Matriks Tanggung Jawab Bersama Google Cloud menguraikan kewajiban kepatuhan PCI DSS. Matriks tanggung jawab dapat menjadi referensi yang berguna saat Anda mengejar kepatuhan PCI DSS dan melakukan audit PCI DSS Anda sendiri.
Panduan produk
Bagian ini berisi panduan untuk layanan Google Cloud yang umum digunakan dalam arsitektur yang digunakan untuk lingkungan PCI DSS.
App Engine
Gunakan aturan firewall masuk dan kontrol traffic keluar App Engine.
Cloud Run
Gunakan setelan ingress, Kontrol Layanan VPC, dan kontrol egress di konektor VPC Cloud Run. Jika perlu, konfigurasi alamat IP keluar statis.
Fungsi Cloud Run
Gunakan setelan jaringan masuk dan keluar fungsi Cloud Run.
Cloud Logging
Catat interaksi dengan Cloud Logging.
Cloud Monitoring
Pantau interaksi dengan Cloud Monitoring.
Google Kubernetes Engine
Untuk informasi tentang cara menggunakan Google Kubernetes Engine untuk lingkungan PCI DSS, lihat Kepatuhan PCI DSS di GKE.
Cloud Storage
Persyaratan 3.5 menetapkan bahwa nomor akun utama (PAN) diamankan di mana pun disimpan. Meskipun Google secara otomatis menawarkan enkripsi saat dalam penyimpanan, Google tidak otomatis melakukan hash satu arah, pemotongan, atau tokenisasi yang juga diperlukan oleh aturan.
Contoh arsitektur
Bagian ini mengilustrasikan pendekatan untuk menerapkan lingkungan yang mematuhi SAQ A, SAQ A-EP, dan SAQ D.
Ringkasan arsitektur
SAQ A
SAQ A adalah arsitektur pemrosesan pembayaran yang paling dasar. Pembayaran diproses oleh pihak ketiga, dan tidak ada data kartu yang diakses oleh aplikasi atau halaman penjual.
Pada tingkat tinggi, alur pemrosesan pembayaran adalah sebagai berikut:
Pelanggan menentukan pilihan dan melanjutkan ke check out.
Aplikasi checkout mengalihkan pelanggan ke pemroses pembayaran pihak ketiga.
Pelanggan memasukkan informasi kartu pembayarannya ke dalam formulir pembayaran yang dimiliki dan dikelola oleh pemroses pihak ketiga.
Pemroses pembayaran pihak ketiga memeriksa informasi kartu pembayaran, lalu menagih atau menolak kartu.
Setelah memproses transaksi, pemroses pembayaran pihak ketiga akan mengirim pelanggan kembali ke aplikasi penjual beserta detail transaksi.
Aplikasi penjual mengirimkan permintaan verifikasi ke pemroses pembayaran untuk mengonfirmasi transaksi.
Pemroses pembayaran akan merespons untuk memverifikasi detail transaksi.
SAQ A-EP
Arsitektur pemrosesan pembayaran SAQ A-EP berpusat pada aplikasi pemrosesan pembayaran yang berjalan di instance virtual machine Compute Engine. Instance ini berada di jaringan pribadi yang aman, dan menggunakan saluran aman untuk berkomunikasi dengan layanan yang berada di luar jaringan.
Pada tingkat tinggi, alur pemrosesan pembayaran adalah sebagai berikut:
Pelanggan memasukkan informasi kartu pembayarannya ke dalam formulir pembayaran yang dimiliki dan dikelola perusahaan Anda.
Saat pelanggan mengirimkan informasinya, informasi formulir akan diteruskan dengan aman ke pemroses pembayaran pihak ketiga.
Pemroses pembayaran pihak ketiga memeriksa informasi kartu pembayaran, lalu menagih atau menolak kartu.
Pemroses pembayaran mengirimkan respons kembali ke aplikasi pembayaran Anda, yang kemudian meneruskan pesan ke aplikasi inti Anda.
Semua interaksi ini dicatat dan dipantau dengan Cloud Logging dan Cloud Monitoring.
SAQ D
Arsitektur pemrosesan pembayaran SAQ D berfokus pada aplikasi pemrosesan pembayaran yang berjalan di instance virtual machine Compute Engine. Instance ini berada dalam jaringan pribadi yang aman dan menggunakan saluran aman untuk berkomunikasi dengan layanan yang berada di luar jaringan.
Pada tingkat tinggi, alur pemrosesan pembayaran adalah sebagai berikut:
Pelanggan memasukkan informasi kartu pembayaran mereka ke dalam formulir pembayaran yang dimiliki dan dikelola perusahaan Anda.
Saat pelanggan mengirimkan informasinya, aplikasi pembayaran Anda akan menerima informasi formulir.
Aplikasi pembayaran Anda memvalidasi informasi pembayaran dan meneruskannya dengan aman ke pemroses pembayaran pihak ketiga melalui API backend.
Pemroses pembayaran pihak ketiga memeriksa informasi kartu pembayaran, lalu menagih atau menolak kartu.
Pemroses pembayaran mengirimkan respons kembali ke aplikasi pembayaran Anda, yang kemudian meneruskan pesan ke aplikasi inti Anda.
Semua interaksi ini dicatat dalam log dan dipantau dengan Logging dan Monitoring.
Alur pemrosesan pembayaran yang ditampilkan kepada pelanggan
SAQ A
Bagian ini menjelaskan alur pemrosesan pembayaran pihak ketiga dari perspektif pelanggan yang menggunakan aplikasi Anda.
Saat pelanggan mengakses formulir pembayaran, aplikasi akan menampilkan
<iframe> yang dihosting oleh pemroses pembayaran. Aplikasi
Anda tidak dapat mengakses atau memantau konten
<iframe> karena
pembatasan berbagi resource lintas origin.
Saat pelanggan mengirimkan informasi kartu pembayarannya, pemroses pembayaran akan menerima atau menolak kartu, lalu mengirim pelanggan kembali ke aplikasi Anda. Kemudian, aplikasi Anda akan memeriksa respons transaksi dari pemroses pembayaran dan bertindak sesuai dengan respons tersebut. Aplikasi Anda tidak mengakses atau
menangani informasi kartu pembayaran apa pun.
SAQ A-EP
Bagian ini menjelaskan alur pemrosesan pembayaran internal yang sama seperti yang dijelaskan sebelumnya, tetapi dari perspektif pelanggan yang menggunakan aplikasi Anda.
Saat pelanggan mengakses URL untuk formulir pembayaran, situs akan menampilkan formulir yang dihosting oleh aplikasi pembayaran Anda. Saat pelanggan mengirimkan informasi kartu pembayaran, formulir akan langsung diarahkan ke pemroses pembayaran. Pemroses menerima atau menolak kartu, lalu mengirim pelanggan kembali ke aplikasi Anda. Kemudian, aplikasi Anda akan memeriksa respons transaksi dari pemroses pembayaran dan bertindak sesuai dengan respons tersebut. Pelanggan mungkin tidak melihat pemroses pembayaran pihak ketiga, tetapi aplikasi Anda tidak mengakses informasi kartu pembayaran apa pun di sisi server.
SAQ D
Bagian ini menjelaskan alur pemrosesan pembayaran internal dari perspektif pelanggan yang menggunakan aplikasi Anda.
Saat pelanggan mengakses URL untuk formulir pembayaran, mereka akan dirutekan secara aman ke formulir melalui load balancer HTTPS. Saat pelanggan mengirimkan informasi kartu pembayarannya, aplikasi pemrosesan pembayaran Anda akan mengirim informasi tersebut ke pemroses pembayaran pihak ketiga dengan aman. Pemroses pembayaran pihak ketiga menerima atau menolak kartu, lalu menampilkan respons ke aplikasi pemrosesan pembayaran Anda.
Alur internal pemrosesan pembayaran
SAQ A & A-EP
Bagian ini menjelaskan alur pemrosesan pembayaran dari perspektif server yang menjalankan aplikasi Anda.
Aplikasi pemrosesan pembayaran Anda menerima dan mengurai respons yang ditampilkan oleh pemroses pembayaran pihak ketiga, lalu mengirim beberapa atau semua data respons ke aplikasi inti. Pada tahap ini, aplikasi pemrosesan pembayaran Anda telah menyelesaikan transaksi. Aplikasi inti menangani tugas untuk memberi tahu pelanggan Anda.
SAQ D
Bagian ini menjelaskan alur pemrosesan pembayaran internal dari perspektif server yang menjalankan aplikasi Anda.
Aplikasi pemrosesan pembayaran Anda memvalidasi informasi kartu pembayaran yang dikirimkan oleh pelanggan, lalu mengirimkannya ke pemroses pembayaran melalui API backend. Pemroses mencoba tagihan dan merespons dengan detail transaksi. Aplikasi Anda menerima dan memproses respons, lalu mengirim beberapa atau semua data respons ke aplikasi inti. Pada titik ini, aplikasi pemrosesan pembayaran Anda telah menyelesaikan transaksi. Aplikasi inti menangani tugas untuk memberi tahu pelanggan dan mengirimkan produk.
Memantau dan melakukan logging aliran data
Alur pemantauan dan logging dirancang sebagai berikut:
Menyiapkan lingkungan pemrosesan pembayaran
Bagian ini menjelaskan cara menyiapkan lingkungan pemrosesan pembayaran. Penyiapan mencakup hal berikut:
- Membuat akun Google Cloud baru untuk mengisolasi lingkungan pemrosesan pembayaran dari lingkungan produksi.
- Membatasi akses ke lingkungan Anda.
- Menyiapkan resource virtual Anda.
- Mendesain image Linux dasar yang akan Anda gunakan untuk menyiapkan server aplikasi.
- Menerapkan solusi pengelolaan paket yang aman.
Menyiapkan akun baru
Untuk menyederhanakan pembatasan akses dan audit kepatuhan, buat lingkungan pemrosesan pembayaran berkualitas produksi yang sepenuhnya terisolasi dari lingkungan produksi standar dan lingkungan pengembangan serta UM (persyaratan 6.5.3). Untuk memastikan isolasi, buat dan gunakan akun Google Cloud yang terpisah dari akun lingkungan produksi inti Anda. Pengguna yang berpengalaman dengan konfigurasi Identity and Access Management (IAM) dapat melakukan isolasi yang setara dengan menggunakan project terpisah untuk pekerjaan dalam cakupan.
Membatasi akses ke lingkungan Anda
Izinkan akses lingkungan pemrosesan pembayaran hanya kepada individu yang men-deploy kode sistem pembayaran atau mengelola mesin sistem pembayaran Anda (bagian 7.2 dan persyaratan 8.2.1). Hal ini dikenal sebagai prinsip hak istimewa terendah. Gunakan peran IAM untuk membatasi akses. Praktik terbaik mencakup penggunaan peran jika memungkinkan, hanya memberikan izin yang diperlukan untuk melakukan pekerjaan yang diharapkan, dan hanya memberikan peran Pemilik kepada akun utama yang secara sah memerlukan akses root penuh ke layanan Anda. Lihat panduan keamanan IAM untuk mengetahui informasi selengkapnya.
Akses otomatis ke layanan terkelola harus mengandalkan akun layanan. Akun layanan menyederhanakan siklus proses pengelolaan aplikasi dengan memberi Anda cara untuk mengelola autentikasi dan otorisasi aplikasi. Akun ini memberi Anda cara yang fleksibel, tetapi aman untuk mengelompokkan instance virtual machine dengan aplikasi dan fungsi serupa yang memiliki identitas yang sama. Anda dapat menerapkan keamanan dan kontrol akses di tingkat akun layanan melalui peran IAM dan aturan firewall VPC.
Aturan IAM yang Anda terapkan ke folder diwarisi oleh semua item yang terdapat dalam folder tersebut. Izin default adalah tolak semua (persyaratan 7.2.3), dan setiap aturan yang Anda terapkan hanya menambahkan izin.
Persyaratan 8.3.6 memberikan beberapa aturan dasar untuk sandi pengguna. National Institute of Standards and Technology (NIST) menentukan kumpulan aturan yang lebih aman untuk sandi yang aman di bagian 5.1.1 NIST SP800-63B. Google merekomendasikan untuk mengikuti panduan NIST Digital Identity jika memungkinkan.
PCI DSS SAQ D bagian 12.7 mewajibkan individu yang memiliki akses ke lingkungan dalam cakupan Anda untuk lulus pemeriksaan latar belakang, sesuai dengan hukum setempat, sebelum mereka diberi akses ke lingkungan tersebut. Untuk mengurangi risiko pelanggaran kepatuhan, sebaiknya lakukan pemeriksaan latar belakang kriminal dan pemeriksaan referensi ini pada setiap individu, terlepas dari jenis kepatuhan Anda.
Mengamankan jaringan Anda
Untuk mengamankan traffic masuk dan keluar ke dan dari jaringan aplikasi pemrosesan pembayaran, Anda perlu membuat hal berikut:
- Kebijakan Cloud Next Generation Firewall atau aturan firewall Compute Engine
- Tunnel Cloud VPN
- Load Balancer Aplikasi Eksternal
Untuk membuat VPC, sebaiknya gunakan Cloud NAT sebagai lapisan keamanan jaringan tambahan. Ada banyak opsi canggih yang tersedia untuk mengamankan jaringan instance Compute Engine dan GKE.
Membuat aturan firewall
Gunakan policies Cloud Next Generation Firewall atau aturan firewall VPC untuk membatasi traffic masuk ke setiap instance Compute Engine Anda (persyaratan 1.3 dan 1.4). Izinkan traffic masuk hanya dari tiga sumber berikut:
- HTTPS publik, sehingga pelanggan dapat membuka halaman pembayaran Anda.
- Jaringan aplikasi Anda, sehingga aplikasi pemrosesan pembayaran dapat menerima respons dari pemroses pembayaran pihak ketiga.
- Jaringan internal kantor Anda, sehingga Anda dapat mengakses instance untuk tujuan audit dan manajemen.
Gunakan aturan firewall di setiap instance untuk membatasi traffic keluar. Anda dapat menerapkan aturan ini secara lokal dengan iptables atau, secara lebih luas, menggunakan aturan firewall VPC dan tag jaringan. Izinkan traffic keluar hanya dari formulir pembayaran Anda ke pemroses pembayaran pihak ketiga. Koneksi ini harus khusus HTTPS. Untuk menguji pekerjaan Anda, lihat bagian tentang Logging Aturan Firewall nanti dalam dokumen ini.
Cloud DNS menawarkan zona DNS pribadi sehingga Anda dapat memberi nama host dengan aman dalam CDE tanpa potensi kebocoran data topologi jaringan sensitif kepada publik.
Batasi traffic sebagai berikut:
| Asal | Tujuan | Port | Arah dan alasan |
|---|---|---|---|
| Load balancer publik | Formulir pembayaran pihak ketiga | tcp:443 | Masuk Akses publik ke aplikasi pemrosesan pembayaran |
| Formulir pembayaran pihak ketiga | Pemroses pembayaran pihak ketiga | tcp:443 | Keluar Teruskan permintaan AUTH ke penyedia layanan pembayaran |
| Pemroses pembayaran pihak ketiga | Aplikasi pemrosesan pembayaran Anda | tcp:5480 | Masuk Menerima permintaan AUTH dari sistem pembayaran (tidak berisi data pemegang kartu) |
| Jaringan kantor perusahaan Anda | Gateway VPN | tcp:8000 | Masuk Akses ke lingkungan pemrosesan pembayaran untuk akses ke log dan mesin pengembangan |
Selain itu, traffic berikut terjadi dengan aman di jaringan internal aplikasi pemrosesan pembayaran Anda:
| Asal | Tujuan | Port | Alasan |
|---|---|---|---|
| Formulir kartu | Proxy PCI | tcp:5480 | Pertukaran data kartu terenkripsi untuk token instrumen pembayaran |
| Semua Host | Server NTP Google | udp:123 | Sinkronisasi waktu |
| Gateway VPN | Semua Host | tcp:22 | Koneksi Secure Shell (SSH) |
Membuat tunnel VPN yang aman
Anda dapat menggunakan Cloud VPN untuk membuat tunnel VPN yang aman antara lingkungan lokal dan lingkungan pemrosesan pembayaran Anda (bagian 2.2.7 dan 4.2).
Membuat Load Balancer Aplikasi Eksternal
Anda dapat membantu memastikan bahwa traffic pelanggan yang masuk aman dengan membuat Load Balancer Aplikasi eksternal (bagian 2.2.7 dan 4.2). Untuk membuat Load Balancer Aplikasi eksternal, Anda memerlukan hal berikut:
- Subdomain situs Anda yang digunakan untuk formulir pemrosesan pembayaran, misalnya,
payments.your-domain-name.com. - Sertifikat SSL yang valid dan ditandatangani yang telah didaftarkan untuk subdomain Anda.
Pastikan domain Anda valid dengan melihat setelan DNS-nya di antarmuka konfigurasi domain registrar web Anda.
Membuat image Linux dasar
PCI DSS berisi persyaratan yang menjelaskan cara menyiapkan mesin yang merupakan bagian dari arsitektur pemrosesan pembayaran yang mematuhi kebijakan. Anda dapat menerapkan persyaratan ini dengan beberapa cara, tetapi pendekatan yang paling mudah adalah sebagai berikut:
Buat daftar software dan library yang harus diinstal di setiap server yang termasuk dalam cakupan aplikasi pemrosesan pembayaran Anda. Untuk menghindari kerentanan yang tidak perlu pada sistem Anda (persyaratan 2.2.4), hanya sertakan software dan library minimum yang Anda perlukan untuk menjalankan aplikasi. Kandidat dapat mencakup Google Cloud CLI, runtime dan library khusus bahasa, atau server web.
Buat instance Compute Engine yang menggunakan salah satu image sistem operasi yang telah dikonfigurasi sebelumnya Compute Engine.
Instal library dan software yang Anda cantumkan sebelumnya.
Instal dan konfigurasikan
ntpagar jam sistem tetap sinkron. Mengelola jam server dengan Network Time Protocol memastikan integritas stempel waktu dalam log (bagian 10.6).Pastikan image mengikuti praktik terbaik untuk membuat image Compute Engine yang aman (semua bagian 2.2).
Setelah mengonfigurasi image dasar, buat disk image Compute Engine kustom dari image Anda. Image ini memungkinkan Anda menggunakan image Linux dasar saat membuat instance virtual machine.
Menggunakan pengelolaan paket yang aman
Pengelolaan paket adalah komponen utama dari lingkungan hosting yang ditingkatkan keamanannya. Sesuai dengan pasal 2.2, Anda harus menerapkan standar hardening yang diterima industri. Kecuali jika Anda menggunakan Container-Optimized OS dari Google, Anda mungkin telah menginstal pengelola paket seperti RPM, Yum, atau Apt. Aplikasi Anda mungkin menggunakan pengelola paket khusus bahasa pemrogramannya sendiri seperti NPM, PyPi, atau Composer, dan mendownload dependensi saat pertama kali dijalankan.
Jika aplikasi dapat mengambil update dari internet, Anda harus memperlakukan sumber update sebagai potensi risiko keamanan. Serangan sisi suplai, atau upstream, yang disertakan secara berbahaya dalam paket yang dihosting secara publik menjadi lebih umum. Bayangkan efek dari menginstal update ke SSH yang berisi kode berbahaya.
Anda dapat memitigasi risiko serangan sisi suplai dengan membuat daftar penerima yang aman untuk paket Anda dan memverifikasi bahwa paket tersebut cocok dengan daftar. Simpan daftar nomor versi yang telah diuji dan disetujui untuk setiap paket yang Anda gunakan. Catat nomor versi beserta hash atau tanda tangannya. Pastikan pengelola paket memvalidasi hash atau tanda tangan sebelum menginstal atau mengupdate aplikasi.
Sebagian besar sistem pengelolaan paket mengizinkan hosting pribadi. Jika memungkinkan, luncurkan server pengelolaan paket pribadi Anda sendiri dan hanya host software yang telah diuji dan disetujui. Kunci pengelola paket agar tidak dapat menghubungi server lain untuk mendapatkan update.
Idealnya, proses build aplikasi Anda mengambil dan memvalidasi semua paket, lalu membuat revisi image disk kustom yang menyertakan semua yang diperlukan penampung. Dengan cara ini, server Anda akan diluncurkan dan diskalakan tanpa penundaan penginstal, dan kemungkinan error acak pada waktu peluncuran akan berkurang. Anda juga dapat meninjau kembali versi aplikasi sebelumnya persis seperti dalam produksi dengan meluncurkan image-nya, yang dapat membantu untuk diagnostik dan forensik.
Deployment dan konfigurasi
Selanjutnya, siapkan deployment dan konfigurasi instance dari image dasar Anda.
Men-deploy lingkungan
Untuk memenuhi persyaratan PCI DSS, pastikan Anda men-deploy aplikasi yang benar setiap saat, men-deploy aplikasi dengan aman, dan tidak menginstal paket software lainnya selama deployment. Untuk menyederhanakan proses deployment, pertimbangkan untuk membuat deployment otomatis untuk aplikasi Anda menggunakan Terraform. Terraform memungkinkan Anda mendeskripsikan seluruh lingkungan pemrosesan pembayaran, termasuk aturan firewall, gateway, load balancer, dan instance dalam kode.
Dalam deployment otomatis, Anda harus memverifikasi integritas software yang di-deploy, baik dari pihak ketiga maupun milik Anda sendiri. Anda dapat memverifikasi software dengan menjalankan hash otomatis terhadap setiap paket saat paket diinstal. Setelah hash diverifikasi, Anda dapat menggunakan framework pengujian otomatis untuk menjalankan keamanan dan pengujian lainnya, serta memverifikasi bahwa pengujian telah lulus.
Terakhir, saat men-deploy instance Compute Engine, buat rencana pemulihan jika instance Anda gagal. Jika periode nonaktif yang dapat diterima cukup lama, rencana pemulihan manual mungkin sudah memadai. Jika tidak, Anda harus mendesain rencana pemulihan otomatis. Lihat Panduan perencanaan disaster recovery, Mendesain sistem yang andal, dan Mem-build aplikasi web yang skalabel dan tangguh untuk mendapatkan panduan.
Mengonfigurasi lingkungan Anda
Setelah instance di-deploy, pastikan instance tersebut dikonfigurasi dengan benar. Instal software dan library tambahan di atas setiap image dasar instance sesuai kebutuhan. Untuk menghindari kompleksitas, overhead, dan risiko keseluruhan konfigurasi manual, gunakan alat pengelolaan konfigurasi otomatis seperti Skaffold, Chef, Puppet, Ansible, atau Salt.
Mengimplementasikan logging audit yang tidak dapat diubah
Logging menghasilkan log audit secara otomatis untuk berbagai aktivitas di banyak produk. Untuk jangka panjang, Anda dapat menyimpan log yang tidak dapat diubah dengan aman menggunakan kunci bucket Cloud Storage (bagian 10.3). Kunci bucket memungkinkan Anda menetapkan kebijakan untuk membuat semua objek tidak dapat diubah dan tidak dapat dihapus selama jangka waktu yang Anda tentukan, dari detik hingga tahun.
Menerapkan Log Alur Virtual Private Cloud
Layanan VPC Flow Logs dirancang untuk mencatat alur jaringan yang dikirim dari atau diterima oleh instance virtual machine. Anda dapat menggunakan log ini untuk pemantauan jaringan, forensik, dan analisis keamanan real-time (bagian 10.2).
Menginstal agen Logging
Setelah Anda menyiapkan iptables di server, setiap server akan mencatat setiap aktivitas ke block storage server. Lihat halaman harga Logging untuk mengetahui detail tentang alokasi gratis dan harga transfer data. Untuk mempertahankan log ini dan membuat pemberitahuan berdasarkan aktivitas yang mencurigakan, streamingkan log ke Logging dan Monitoring dengan menginstal Agen logging di setiap server (bagian 10.3).
Mengintegrasikan Intrusion Detection System
Untuk membantu memastikan keamanan lingkungan pemrosesan pembayaran Anda, yang dijelaskan di bagian 11.5, gunakan sistem deteksi intrusi (IDS), sehingga Anda tahu kapan pelaku kejahatan mencoba menyerang sistem. Ada dua cara untuk menempatkan IDS di lingkungan pemrosesan pembayaran: tempatkan IDS di setiap titik entri, atau instal IDS di setiap server.
Untuk mengurangi kompleksitas arsitektur lingkungan dan menyederhanakan kepatuhan terhadap 11.5, instal IDS di setiap server. Setelah Anda meneliti dan memilih software IDS yang akan digunakan, buat penginstalan IDS menjadi bagian dari skrip penginstalan startup untuk setiap server.
Cloud Intrusion Detection System (Cloud IDS), layanan deteksi penyusupan, menyediakan deteksi ancaman untuk intrusi, malware, spyware, serta serangan perintah dan kontrol di jaringan Anda. Cloud IDS memberikan visibilitas penuh ke traffic jaringan, termasuk traffic utara-selatan dan timur-barat, sehingga Anda dapat memantau komunikasi VM-ke-VM untuk mendeteksi pergerakan lateral. Anda juga dapat menggunakan Cloud IDS untuk menyederhanakan kepatuhan terhadap persyaratan 11.5.
Log IDS termasuk dalam cakupan kepatuhan PCI DSS, dan harus dikirim ke logging dan pemantauan untuk pelaporan, pemberitahuan, dan audit.
Mengimplementasikan Security Command Center
Security Command Center helps security teams gather data, identify threats, and respond to threats before they result in business damage or loss. Fitur ini menawarkan insight mendalam tentang risiko aplikasi dan data sehingga Anda dapat dengan cepat mengurangi ancaman terhadap resource cloud dan mengevaluasi kesehatan secara keseluruhan. Security Command Center memungkinkan Anda menampilkan dan memantau inventaris aset cloud Anda, memindai sistem penyimpanan untuk mencari data sensitif, mendeteksi kerentanan web umum, dan meninjau hak akses ke resource penting Anda, semuanya dalam satu dasbor yang terpusat. Hal ini dapat membantu Anda mematuhi beberapa persyaratan, termasuk bagian 5 dan 6.4.
Mengotomatiskan deployment aplikasi
Buat alat pengelolaan konfigurasi untuk mengambil dan meluncurkan versi terbaru aplikasi Anda dengan aman. Aplikasi Anda dapat diambil dari lokasi mana pun, seperti Cloud Storage, asalkan lokasi tersebut aman.
Banyak alat pengelolaan konfigurasi yang disebutkan sebelumnya mendukung alur kerja continuous integration dan deployment (CI/CD), yang juga dapat digunakan untuk melakukan pemindaian otomatis (bagian 11.3) dan untuk memastikan bahwa kode ditinjau (persyaratan 6.2.3).
Mengambil log Configuration Manager
Saat menyiapkan pengelola konfigurasi, pastikan pengelola tersebut mencatat semua detail penginstalan. Setelah menyelesaikan proses konfigurasi, pastikan konfigurasi tersebut mengirim log ke Logging dan Pemantauan.
Logging dan pemantauan
Untuk memastikan kepatuhan PCI DSS berdasarkan pasal 10, pastikan setiap langkah yang dilakukan di lingkungan pemrosesan pembayaran Anda dipantau dan dicatat. Setiap aktivitas server di setiap instance harus dicatat ke dalam log, dan setiap tindakan pengguna harus dapat diperiksa di lain waktu.
Mengaktifkan Transparansi Akses
Melalui Transparansi Akses, Logging kini menawarkan log yang mendekati real-time saat admin Google Cloud mengakses konten Anda. Log Cloud Audit Logs sudah menyediakan visibilitas terhadap tindakan admin Anda sendiri. Namun, jejak audit ini biasanya mengecualikan tindakan yang dilakukan oleh tim dukungan atau engineer penyedia cloud Anda. Misalnya, sebelum logging Persetujuan Akses, jika Anda membuka tiket dengan Dukungan Google yang memerlukan akses data, tiket tersebut tidak akan dilacak di Log Audit Cloud. Persetujuan Akses menutup celah tersebut dengan merekam log akses manual bertarget hampir real-time yang dilakukan oleh tim dukungan atau engineer.
Persetujuan Akses memungkinkan Anda menyetujui akses ke data atau konfigurasi Anda secara eksplisit di Google Cloud sebelum akses tersebut terjadi. Persetujuan Akses juga memberikan insight tentang akses oleh Dukungan dan Engineering Google.
Mengaktifkan Firewall Rules Logging
Logging Aturan Firewall memungkinkan Anda mengaktifkan logging di tingkat aturan individual. Fitur ini dapat merekam koneksi TCP dan UDP di dalam VPC untuk setiap aturan yang Anda buat sendiri. Tindakan ini dapat berguna untuk mengaudit akses jaringan atau memberikan peringatan dini bahwa jaringan sedang digunakan dengan cara yang tidak disetujui.
Menggunakan Kontrol Layanan VPC
Kontrol Layanan VPC memungkinkan Anda menentukan perimeter keamanan di sekitar resource Google Cloud seperti bucket Cloud Storage, instance Bigtable, dan set data BigQuery untuk membatasi data di jaringan VPC dan membantu memitigasi risiko pemindahan data yang tidak sah (persyaratan 1.3.1 dan 1.3.2). Dengan Kontrol Layanan VPC, Anda dapat menjaga kerahasiaan data sensitif saat memanfaatkan kemampuan pemrosesan data dan penyimpanan yang terkelola sepenuhnya di Google Cloud.
Menyiapkan Log Aliran VPC
Log Aliran VPC mencatat alur traffic jaringan yang dikirim atau diterima oleh instance VM. Log ini berguna dalam PCI DSS untuk pemantauan, audit, forensik, dan analisis keamanan real-time. Setiap subnet jaringan VPC dapat mengaktifkan atau menonaktifkan Log Aliran secara terpisah. Anda dapat meminimalkan jumlah data log dengan hanya mengaktifkan Log Aliran di CDE dalam cakupan. Log Aliran, yang digabungkan dengan aturan firewall keluar, memungkinkan Anda membatasi traffic keluar ke endpoint resmi dengan cara yang dapat diaudit dan sulit untuk dihindari (persyaratan 1.2.1 dan 1.3.4).
Diagram berikut menunjukkan cara VPC Flow Logs mencatat alur traffic jaringan yang dikirim atau diterima oleh instance VM."
Jika memerlukan data yang lebih mendetail daripada yang dapat disediakan oleh Log Aliran, seperti logging permintaan HTTP individual, Anda dapat menerapkan kontrol di aplikasi atau permintaan keluar proxy. Anda melakukannya melalui server proxy terbalik Anda sendiri yang dikonfigurasi untuk meneruskan log akses ke Logging. Untuk petunjuk cara menyiapkan server proxy Squid di Compute Engine, lihat Menyiapkan proxy jaringan. Untuk menghindari bottleneck, siapkan minimal dua server proxy redundan.
Mencatat data akses internal ke dalam log
Selain mencatat ancaman eksternal ke dalam log, pantau dan catat aktivitas individu yang memiliki akses administrator ke lingkungan pemrosesan pembayaran Anda (bagian 10.2). Untuk melakukannya, Anda dapat mencatat perintah shell ke dalam log. Beberapa alat open source dapat mengaudit perintah shell dan mengirimkannya ke logging. Pilihan populer untuk tugas ini mencakup OSSEC atau Tripwire.
Menyiapkan pemberitahuan pemantauan
Konfigurasikan Monitoring untuk mengirim pemberitahuan jika terjadi masalah di lingkungan pemrosesan pembayaran Anda (bagian 10.6). Pastikan pemberitahuan Anda mencakup peristiwa aplikasi internal, audit, dan lingkungan. Dasarkan strategi pemberitahuan Anda pada potensi risiko atau vektor serangan untuk setiap komponen aplikasi pemrosesan pembayaran Anda. Misalnya, picu pemberitahuan Pemantauan jika IDS Anda mendeteksi upaya penyusupan, baik yang berhasil maupun yang gagal. Anda juga dapat menggunakan Logging Aturan Firewall untuk memicu pemberitahuan sebagai respons terhadap upaya untuk melanggar kebijakan jaringan tertentu.
Melakukan streaming log ke BigQuery
Jika ingin, Anda dapat merutekan log Logging ke BigQuery untuk dianalisis nanti; lihat Ringkasan pemilihan rute dan penyimpanan: Sink untuk mengetahui detailnya. Karena BigQuery dioptimalkan untuk membuat kueri set data besar, BigQuery adalah alat yang ideal untuk analisis log berskala besar. Logging bahkan dapat mencatat log langsung ke BigQuery untuk log yang memerlukan analisis mendekati real-time (persyaratan 10.4.1).
Menggunakan Sensitive Data Protection untuk membersihkan data
Ada banyak alasan untuk menggunakan bagian data yang terdapat dalam aplikasi dalam cakupan Anda yang tidak termasuk dalam cakupan, seperti untuk analisis atau pengembangan. Berikan akses ke data PCI kepada aplikasi hanya setelah data tersebut dibersihkan dengan Sensitive Data Protection (persyaratan 6.5.1).
Keamanan aplikasi
Untuk membantu mengamankan aplikasi, Anda harus mengevaluasi antarmuka administrator terlebih dahulu. Anda mungkin juga ingin menggunakan Cloud Key Management Service.
Mengevaluasi antarmuka administrator
Sebagian besar aplikasi e-commerce memiliki antarmuka administrator non-konsol sendiri, seperti portal penagihan layanan pelanggan. Alat tersebut harus memiliki kontrol akses yang kuat; alat tersebut harus memiliki akses individual yang menggunakan autentikasi multi-faktor (bagian 8.4); dan alat tersebut harus dilengkapi dengan logging audit (bagian 10.2).
Setiap log yang Anda buat harus menjawab pertanyaan berikut: Siapa yang melakukan apa? Di mana mereka melakukannya? Kapan mereka melakukannya? Menurut bagian 2.2.7, semua akses ke alat tersebut harus menggunakan enkripsi transpor yang kuat. Gunakan Perlindungan Data Sensitif untuk memfilter informasi sensitif sebelum menampilkannya di alat administrasi apa pun.
Menggunakan Cloud Key Management Service (Cloud KMS)
Cloud KMS adalah layanan yang memungkinkan Anda mengelola kunci enkripsi. Cloud KMS dapat membuat, menggunakan, merotasi, dan menghancurkan kunci enkripsi AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256, dan EC P384. Cloud KMS memungkinkan Anda menghapus sandi teks biasa yang disimpan dalam kode atau file konfigurasi, yang menyederhanakan kepatuhan terhadap bagian 2.2.2, 3.6, 3.7, dan 8.2.
Memvalidasi lingkungan Anda
Setelah lingkungan diterapkan, tetapi sebelum traffic produksi mengalir melalui lingkungan tersebut, Anda harus memvalidasi lingkungan:
- Jika Anda adalah penjual Level 1, lingkungan Anda harus divalidasi oleh Penilai Keamanan Berkualifikasi (QSA). QSA adalah perusahaan atau individu yang disetujui oleh PCI Security Standards Council untuk memvalidasi lingkungan PCI dan memberikan stempel persetujuan.
- Jika Anda adalah penjual Level 2 atau lebih rendah, Anda dapat memvalidasi lingkungan dengan mengisi Kuesioner Penilaian Mandiri.
Langkah berikutnya
- Library dokumen PCI DSS
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.