Panduan ini membantu Anda mempelajari cara menerapkan Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS) untuk bisnis Anda di Google Cloud. Panduan ini lebih dari sekadar Panduan Cloud Computing PCI SSC (PDF) untuk memberikan latar belakang tentang standar ini, menjelaskan peran Anda dalam kepatuhan berbasis cloud, dan kemudian memberi Anda panduan untuk mendesain, men-deploy, dan mengonfigurasi aplikasi pemrosesan pembayaran menggunakan PCI DSS. Tutorial ini juga membahas metode untuk memantau, melakukan logging, dan memvalidasi aplikasi Anda.
Dokumen ini mengacu 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 semua perusahaan kartu pembayaran terkemuka. Bisnis yang menggunakan Visa, MasterCard, Discover, American Express, JCB, atau UnionPay diharapkan mematuhi PCI DSS, dan dapat didenda atau dikenakan hukuman jika tidak mematuhi PCI DSS.
PCI DSS mencakup klasifikasi untuk beberapa jenis penjual, dari penjual yang mengumpulkan informasi pembayaran secara langsung hingga penjual yang mengalihkan pemrosesan pembayaran sepenuhnya. 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 mengonfigurasikan server aplikasi.
- Siapkan logging dan monitoring.
- Validasi lingkungan pemrosesan pembayaran Anda.
Definisi
Panduan ini menggunakan banyak frasa unik. Berikut beberapa tag yang paling umum. Untuk informasi selengkapnya, lihat glosarium PCI DSS.
CDE: Akronim dari lingkungan data pemegang kartu. Akronim ini mengacu pada setiap bagian aplikasi Anda yang menyimpan atau mentransfer data pemegang kartu, termasuk nomor rekening pembayaran atau informasi identitas pribadi apa pun yang terkait dengan kartu tersebut.
Kontrol kompensasi: Solusi alternatif yang dapat dipertimbangkan jika entitas tidak dapat memenuhi persyaratan secara eksplisit seperti yang dinyatakan, karena kendala teknis atau bisnis terdokumentasi yang sah. Entitas harus secara memadai mengurangi risiko yang terkait dengan persyaratan saat menerapkan kontrol lain ini. Lihat "Kontrol Kompensasi" Lampiran B dan C dalam Persyaratan dan Prosedur Penilaian Keamanan PCI DSS untuk panduan penggunaan kontrol kompensasi.
PAN: Akronim untuk nomor akun utama dan juga disebut sebagai nomor akun. Nomor ini adalah nomor kartu pembayaran unik yang mengidentifikasi penerbit dan rekening pemegang kartu.
QSA: Akronim 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 akun utama (PAN) dengan nilai pengganti yang disebut token. PAN kemudian disimpan dalam pencarian aman. De-tokenisasi adalah proses kebalikan dari pencarian PAN dengan 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 bernomor utama dan banyak subbagian. Dokumen ini merujuk pada nomor bagian ini untuk menambahkan konteks, tetapi referensi bagian tersebut bukanlah daftar lengkap persyaratan yang berlaku.
Persyaratan kepatuhan PCI DSS Anda bervariasi, bergantung pada cara perusahaan Anda menangani (jenis) transaksi kartu pembayaran dan jumlah transaksi yang dijalankannya setiap tahun (tingkat).
Seiring dengan meningkatnya jumlah transaksi, level penjual PCI DSS Anda akan meningkat, dan panduan kepatuhan PCI DSS akan semakin ketat. Pada tingkat penjual tertinggi, Level 1, PCI DSS memerlukan audit. Level bervariasi menurut merek kartu. Level 1 didefinisikan 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 tingkat 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 tingkat penjual perusahaan Anda. Bagian Berkomitmen pada kepatuhan menjabarkan area mana yang dicakup untuk Anda oleh Google.
Variabel dasar lainnya adalah jenis SAQ. SAQ menguraikan kriteria yang harus Anda tangani untuk mematuhi PCI DSS jika Anda memenuhi syarat untuk penilaian mandiri. Jenis SAQ ditentukan oleh arsitektur aplikasi dan cara yang tepat dalam menangani data kartu pembayaran. Sebagian besar penjual di cloud adalah salah satu dari yang berikut:
| Jenis SAQ | Deskripsi |
|---|---|
| A | Penjual yang telah mengalihkan pemrosesan kartu pembayaran sepenuhnya ke situs pihak ketiga. Pelanggan keluar dari domain Anda (termasuk melalui formulir web <iframe>), menyelesaikan pembayaran, lalu kembali ke aplikasi Anda.Dengan kata lain, perusahaan Anda tidak dapat menghubungi data kartu pelanggan dengan cara apa pun. |
| A-EP | Penjual yang mengalihkan pemrosesan pembayaran ke penyedia pihak ketiga, tetapi
yang dapat mengakses data kartu pelanggan kapan saja dalam proses ini. 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 yang dilakukan. Dengan kata lain, jika Anda bukan SAQ A atau SAQ A-EP, berarti Anda adalah SAQ D. SAQ D membedakan antara penjual dan penyedia layanan. Penyedia layanan tidak dibahas dalam dokumen ini, dan semua referensi SAQ D ditujukan untuk penjual seperti yang ditetapkan dalam PCI DSS. |
Berkomitmen pada kepatuhan
Google menggunakan berbagai teknologi dan proses untuk mengamankan informasi yang disimpan di server Google. Persyaratan PCI DSS yang divalidasi secara independen dan 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 memberi penjual banyak kontrol atas instance komputasi mereka yang berjalan di infrastruktur Google, Google tidak mengontrol keamanan untuk sistem operasi, paket, atau aplikasi yang di-deploy oleh penjual di Google Cloud. Anda bertanggung jawab untuk mematuhi persyaratan PCI DSS untuk paket sistem operasi dan aplikasi yang di-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 bermanfaat saat Anda memenuhi kepatuhan PCI DSS dan melakukan audit PCI DSS Anda sendiri.
Panduan produk
Bagian ini berisi panduan untuk layanan Google Cloud yang biasa 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 traffic masuk Cloud Run, Kontrol Layanan VPC, dan kontrol keluar pada konektor VPC. Jika diperlukan, konfigurasikan alamat IP keluar statis.
Cloud Functions
Gunakan setelan jaringan masuk dan keluar Cloud Functions.
Cloud Logging
Catat interaksi dengan Cloud Logging.
Cloud Monitoring
Pantau interaksi dengan Cloud Monitoring.
Google Kubernetes Engine
Untuk mengetahui informasi tentang penggunaan Google Kubernetes Engine untuk lingkungan PCI DSS, lihat Kepatuhan PCI DSS di GKE.
Cloud Storage
Persyaratan 3.5 menetapkan bahwa nomor rekening utama (PAN) diamankan di mana pun disimpan. Meskipun otomatis menawarkan enkripsi dalam penyimpanan, Google tidak otomatis melakukan hash, pemotongan, atau tokenisasi satu arah yang juga diperlukan oleh aturan tersebut.
Contoh arsitektur
Bagian ini menggambarkan pendekatan untuk menerapkan lingkungan yang sesuai dengan SAQ A, SAQ A-EP, dan SAQ D.
Ringkasan arsitektur
SAQ A
SAQ A adalah arsitektur pemrosesan pembayaran paling dasar. Pembayaran diproses oleh pihak ketiga, dan tidak ada data kartu yang diakses oleh aplikasi atau halaman penjual.
Pada level 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 pembayaran ke dalam formulir pembayaran yang dimiliki dan dikelola oleh pemroses pihak ketiga.
Pemroses pembayaran pihak ketiga akan memeriksa informasi kartu pembayaran, lalu menagih atau menolak kartu tersebut.
Setelah memproses transaksi, pemroses pembayaran pihak ketiga akan mengarahkan pelanggan kembali ke aplikasi penjual bersama dengan 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 A-EP SAQ 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 di luar jaringan.
Pada level tinggi, alur pemrosesan pembayaran adalah sebagai berikut:
Pelanggan memasukkan informasi kartu pembayaran ke formulir pembayaran yang dimiliki dan dikelola perusahaan Anda.
Saat pelanggan mengirimkan informasinya, informasi formulir tersebut akan diteruskan dengan aman ke pemroses pembayaran pihak ketiga.
Pemroses pembayaran pihak ketiga akan memeriksa informasi kartu pembayaran, lalu menagih atau menolak kartu tersebut.
Pemroses pembayaran mengirimkan respons kembali ke aplikasi pembayaran Anda, yang kemudian meneruskan pesan ke aplikasi inti Anda.
Semua interaksi ini dicatat ke dalam log dan dipantau dengan Cloud Logging dan Cloud Monitoring.
SAQ D
Arsitektur pemrosesan pembayaran SAQ D 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 level tinggi, alur pemrosesan pembayaran adalah sebagai berikut:
Pelanggan memasukkan informasi kartu pembayaran ke 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 akan memeriksa informasi kartu pembayaran, lalu menagih atau menolak kartu tersebut.
Pemroses pembayaran mengirimkan respons kembali ke aplikasi pembayaran Anda, yang kemudian meneruskan pesan ke aplikasi inti Anda.
Semua interaksi ini dicatat dan dipantau dengan Logging dan Monitoring.
Alur pemrosesan pembayaran yang berlaku untuk pelanggan
SAQ A
Bagian ini menjelaskan alur pemrosesan pembayaran pihak ketiga dari perspektif pelanggan yang menggunakan aplikasi Anda.
Saat pelanggan mengakses formulir pembayaran Anda, aplikasi akan menyajikan
<iframe> yang dihosting oleh pemroses pembayaran. Aplikasi
Anda tidak dapat mengakses atau memantau konten
<iframe> karena
batasan berbagi resource lintas origin.
Saat pelanggan mengirimkan informasi kartu pembayaran, pemroses
pembayaran akan menerima atau menolak kartu, lalu mengarahkan pelanggan kembali ke
aplikasi Anda. Kemudian, aplikasi Anda akan memeriksa respons transaksi dari
pemroses pembayaran dan bertindak sebagaimana mestinya. 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 formulir pembayaran Anda, situs tersebut akan menyajikan formulir yang dihosting oleh aplikasi pembayaran Anda. Saat pelanggan mengirimkan informasi kartu pembayaran, formulir tersebut akan langsung dikirim ke pemroses pembayaran. Pemroses menerima atau menolak kartu, lalu mengarahkan pelanggan kembali ke aplikasi Anda. Aplikasi Anda kemudian memeriksa respons transaksi dari pemroses pembayaran dan bertindak sebagaimana mestinya. 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 Anda, mereka akan dirutekan dengan aman ke formulir melalui load balancer HTTPS. Saat pelanggan mengirimkan informasi kartu pembayaran mereka, aplikasi pemrosesan pembayaran Anda akan mengirimkan informasi tersebut dengan aman ke pemroses pembayaran pihak ketiga. 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 mengirimkan beberapa atau semua data respons ke aplikasi inti. Pada tahap ini, aplikasi pemrosesan pembayaran Anda telah selesai dengan 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 akan memvalidasi informasi kartu pembayaran yang dikirimkan oleh pelanggan, lalu mengirimkannya ke pemroses pembayaran melalui API backend. Pemroses mencoba menagih dan merespons dengan detail transaksi. Aplikasi Anda menerima dan memproses respons, lalu mengirimkan beberapa atau semua data respons ke aplikasi inti. Pada tahap ini, aplikasi pemrosesan pembayaran selesai dengan transaksi. Aplikasi inti menangani tugas untuk memberi tahu pelanggan dan mengirimkan produk.
Memantau dan melakukan logging aliran data
Alur pemantauan dan logging didesain sebagai berikut:
Menyiapkan lingkungan pemrosesan pembayaran
Bagian ini menjelaskan cara menyiapkan lingkungan pemrosesan pembayaran Anda. Penyiapan mencakup hal-hal berikut:
- Membuat akun Google Cloud baru untuk mengisolasi lingkungan pemrosesan pembayaran dari lingkungan produksi Anda.
- Membatasi akses ke lingkungan Anda.
- Menyiapkan resource virtual.
- 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 serta lingkungan pengembangan dan QA apa pun (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 menyelesaikan isolasi yang setara dengan menggunakan project terpisah untuk pekerjaan dalam cakupan.
Membatasi akses ke lingkungan Anda
Izinkan akses lingkungan pemrosesan pembayaran hanya bagi individu yang men-deploy kode sistem pembayaran atau mengelola mesin sistem pembayaran Anda (pasal 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 Owner kepada akun utama yang secara sah memerlukan akses root penuh ke layanan Anda. Baca panduan keamanan IAM untuk informasi selengkapnya.
Akses otomatis ke layanan terkelola apa pun 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 umum. 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 ada 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 menyediakan beberapa aturan dasar untuk {i>password<i} pengguna. National Institute of Standards and Technology (NIST) menetapkan serangkaian aturan yang lebih aman untuk sandi yang aman di pasal 5.1.1 NIST SP800-63B. Google merekomendasikan untuk mengikuti panduan Identitas Digital NIST jika memungkinkan.
PCI DSS SAQ D pasal 12.7 mewajibkan individu yang memiliki akses ke lingkungan dalam cakupan Anda untuk lulus pemeriksaan latar belakang, sesuai dengan hukum setempat, sebelum diberi akses ke lingkungan tersebut. Untuk mengurangi risiko pelanggaran kepatuhan, pertimbangkan untuk melakukan 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 harus membuat hal berikut:
- Kebijakan Firewall Cloud Next Generation atau aturan firewall Compute Engine
- Tunnel Cloud VPN
- Load Balancer Aplikasi Eksternal
Untuk membuat VPC Anda, sebaiknya gunakan juga Cloud NAT sebagai lapisan keamanan jaringan tambahan. Ada banyak opsi efektif yang tersedia untuk mengamankan jaringan Compute Engine dan instance GKE.
Membuat aturan firewall
Gunakan kebijakan Cloud Next Generation Firewall atau aturan firewall VPC untuk membatasi traffic masuk ke setiap instance Compute Engine Anda (persyaratan 1.3 dan 1.4). Mengizinkan traffic masuk hanya dari tiga sumber berikut:
- HTTPS publik, agar pelanggan dapat membuka halaman pembayaran Anda.
- Jaringan aplikasi Anda, agar aplikasi pemrosesan pembayaran Anda 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 pada setiap instance untuk membatasi traffic keluar. Anda dapat menerapkan aturan ini secara lokal dengan iptable, atau secara lebih luas lagi, menggunakan aturan firewall VPC dan tag jaringan. Mengizinkan traffic keluar hanya dari formulir pembayaran Anda ke pemroses pembayaran pihak ketiga. Koneksi ini harus khusus HTTPS. Untuk menguji pekerjaan Anda, lihat bagian mengenai Logging Aturan Firewall nanti dalam dokumen ini.
Cloud DNS menawarkan zona DNS pribadi sehingga Anda dapat memberi nama host dengan aman dalam CDE tanpa berpotensi membocorkan data topologi jaringan yang sensitif ke publik.
Batasi traffic seperti 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 Meneruskan 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 apa pun) |
| Jaringan kantor perusahaan Anda | vpn-gateway | 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 dengan 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 (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 terdaftar 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 tercakup dalam aplikasi pemrosesan pembayaran Anda. Untuk menghindari kerentanan yang tidak perlu pada sistem Anda (persyaratan 2.2.4), sertakan hanya software dan library minimum yang Anda perlukan untuk menjalankan aplikasi Anda. Kandidat dapat mencakup Google Cloud CLI, runtime dan library untuk bahasa tertentu, atau server web.
Buat instance Compute Engine yang menggunakan salah satu image sistem operasi Compute Engine yang telah dikonfigurasi sebelumnya.
Instal {i>library<i} dan perangkat lunak yang Anda cantumkan sebelumnya.
Menginstal dan mengonfigurasikan
ntpuntuk menjaga agar jam sistem tetap sinkron. Mengelola jam server dengan Protokol Waktu Jaringan 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 di-hardening keamanan. Sesuai dengan bagian 2.2, Anda harus menerapkan standar hardening yang diterima industri. Kecuali jika Anda menggunakan Container-Optimized OS dari Google, Anda mungkin sudah menginstal pengelola paket seperti RPM, Yum, atau Apt. Aplikasi Anda dapat menggunakan pengelola paket khusus bahasa pemrogramannya sendiri, seperti NPM, PyPi, atau Composer, dan dependensi download 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 dimasukkan dengan berbahaya dalam paket yang dihosting secara publik menjadi makin umum. Bayangkan efek menginstal update ke SSH yang berisi kode berbahaya.
Anda dapat mengurangi risiko serangan sisi suplai dengan membuat daftar penerima yang aman untuk paket Anda dan memverifikasi bahwa paket tersebut cocok dengan daftar yang ada. 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 diuji dan disetujui. Kunci pengelola paket agar tidak dapat menghubungi server lain untuk meminta pembaruan.
Idealnya, proses build aplikasi Anda mengambil dan memvalidasi semua paket, lalu membuat revisi disk image kustom yang mencakup semua yang diperlukan container. Dengan cara ini, server Anda akan diluncurkan dan diskalakan tanpa penundaan penginstal, dan peluang error acak pada waktu peluncuran berkurang. Anda juga dapat membuka kembali versi aplikasi sebelumnya persis seperti saat versi produksinya dengan meluncurkan image-nya, yang dapat berguna untuk diagnostik dan forensik.
Deployment dan konfigurasi
Selanjutnya, siapkan deployment dan konfigurasi instance dari image dasar.
Men-deploy lingkungan Anda
Untuk memenuhi persyaratan PCI DSS, pastikan Anda men-deploy aplikasi yang benar setiap saat, men-deploy aplikasi dengan aman, dan tidak menginstal paket software lain selama deployment. Untuk menyederhanakan proses deployment, pertimbangkan untuk membuat deployment otomatis untuk aplikasi Anda menggunakan Terraform. Terraform berguna untuk mendeskripsikan seluruh lingkungan pemrosesan pembayaran Anda, termasuk aturan firewall, gateway, load balancing, dan instance dalam kode.
Dalam deployment otomatis, Anda harus memverifikasi integritas software yang di-deploy, baik dari pihak ketiga atau 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 pengujian keamanan dan pengujian lainnya, serta untuk memverifikasi bahwa pengujian telah lulus.
Terakhir, saat men-deploy instance Compute Engine, buat desain rencana pemulihan jika instance gagal. Jika periode periode nonaktif yang dapat diterima cukup besar, rencana pemulihan manual mungkin cukup; jika tidak, Anda harus mendesain rencana pemulihan otomatis. Lihat Panduan perencanaan pemulihan dari bencana (disaster recovery), Mendesain sistem yang andal, dan Membuat 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.
Menerapkan logging audit yang tidak dapat diubah
Logging menghasilkan log audit secara otomatis untuk berbagai aktivitas di banyak produk. Dalam jangka panjang, Anda dapat menyimpan log yang tidak dapat diubah dengan aman menggunakan kunci bucket Cloud Storage (bagian 10.3). Penguncian bucket memungkinkan Anda menetapkan kebijakan untuk membuat semua objek tidak dapat diubah dan tidak dapat didelegasikan selama jangka waktu yang ditentukan, dari hitungan detik hingga bertahun-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 iptable di server, setiap server akan mencatat setiap aktivitas ke dalam block storage server. Lihat halaman harga Logging untuk mengetahui detail tentang harga alokasi dan transfer data gratis. Untuk menyimpan log ini dan menghasilkan pemberitahuan berdasarkan aktivitas yang mencurigakan, streaming log tersebut 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, yang dijelaskan di bagian 11.5, gunakan intrusion detection system (IDS), sehingga Anda tahu ketika ada pihak tidak bertanggung jawab yang mencoba menyerang sistem. Ada dua cara untuk menempatkan IDS di lingkungan pemrosesan pembayaran: menempatkan IDS di setiap titik entri, atau menginstal IDS di setiap server.
Untuk mengurangi kompleksitas arsitektur lingkungan Anda dan menyederhanakan kepatuhan terhadap versi 11.5, instal IDS di setiap server. Setelah melakukan riset dan memilih software IDS yang akan digunakan, jadikan penginstalan IDS sebagai bagian dari skrip penginstalan startup untuk setiap server.
Cloud Intrusion Detection System (Cloud IDS), layanan deteksi intrusi, 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 membantu tim keamanan mengumpulkan data, mengidentifikasi ancaman, dan merespons ancaman sebelum mengakibatkan kerusakan atau kerugian bisnis. Fitur ini menawarkan insight mendalam tentang risiko aplikasi dan data sehingga Anda dapat dengan cepat memitigasi ancaman terhadap resource cloud dan mengevaluasi kondisi 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. Langkah ini dapat membantu Anda mematuhi beberapa persyaratan, termasuk bagian 5 dan 6.4.
Mengotomatiskan deployment aplikasi
Build alat manajemen konfigurasi untuk mengambil dan meluncurkan versi terbaru aplikasi Anda dengan aman. Aplikasi Anda dapat diambil dari lokasi mana pun, seperti Cloud Storage, selama 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 konfigurasi mencatat semua detail penginstalan. Setelah menyelesaikan proses konfigurasi, pastikan proses tersebut mengirimkan log ke Logging dan Monitoring.
Logging dan pemantauan
Untuk memastikan kepatuhan PCI DSS berdasarkan pasal 10, pastikan setiap langkah yang diambil di lingkungan pemrosesan pembayaran Anda dipantau dan dicatat. Setiap aktivitas server pada 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 memberikan visibilitas pada tindakan admin Anda sendiri. Namun, jejak audit ini biasanya tidak menyertakan tindakan yang diambil 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 terlacak di Cloud Audit Logs. Persetujuan Akses menutup kesenjangan tersebut, yang mengambil log akses manual yang ditargetkan oleh dukungan atau engineering yang mendekati real-time.
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
Firewall Rules Logging memungkinkan Anda mengaktifkan logging di level aturan individual. VPC 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 seputar resource Google Cloud, seperti bucket Cloud Storage, instance Bigtable, dan set data BigQuery untuk membatasi data di jaringan VPC dan membantu mengurangi risiko pemindahan data yang tidak sah (persyaratan 1.3.1 dan 1.3.2). Dengan Kontrol Layanan VPC, Anda dapat menjaga kerahasiaan data sensitif Anda dengan 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, pengauditan, forensik, dan analisis keamanan secara real-time. Setiap subnet jaringan VPC dapat mengaktifkan atau menonaktifkan Log Aliran secara independen. Anda dapat meminimalkan jumlah data log hanya dengan mengaktifkan Log Alur di CDE dalam cakupan. Log Aliran, yang dikombinasikan dengan aturan firewall keluar, memungkinkan Anda membatasi traffic keluar ke endpoint yang diberi otorisasi dengan cara yang dapat diaudit dan sulit dihindari (persyaratan 1.2.1 dan 1.3.4).
Diagram berikut menunjukkan cara Log Aliran VPC mencatat alur traffic jaringan yang dikirim atau diterima oleh instance VM."
Jika memerlukan data yang lebih mendetail daripada yang dapat disediakan Log Aliran, seperti logging permintaan HTTP individual, Anda dapat menerapkan kontrol dalam aplikasi atau permintaan keluar proxy. Anda melakukan hal ini melalui server reverse proxy Anda sendiri yang dikonfigurasi untuk meneruskan log akses ke Logging. Untuk mendapatkan petunjuk tentang cara menyiapkan server proxy Squid di Compute Engine, lihat Menyiapkan proxy jaringan. Untuk menghindari bottleneck, siapkan setidaknya dua server proxy redundan.
Mencatat data akses internal
Selain mencatat ancaman eksternal ke dalam log, pantau dan catat juga aktivitas individu yang memiliki akses administrator ke lingkungan pemrosesan pembayaran Anda (pasal 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
Konfigurasi Monitoring untuk mengirim pemberitahuan jika terjadi masalah di lingkungan pemrosesan pembayaran Anda (bagian 10.6). Pastikan pemberitahuan Anda mencakup peristiwa lingkungan, audit, dan aplikasi internal. Dasarkan strategi pemberitahuan Anda pada potensi vektor risiko atau serangan untuk setiap komponen aplikasi pemrosesan pembayaran. Misalnya, picu peringatan Monitoring jika IDS Anda mendeteksi upaya penyusupan, baik berhasil maupun tidak. Anda juga dapat menggunakan Firewall Rules Logging untuk memicu pemberitahuan sebagai respons atas upaya untuk melanggar kebijakan jaringan tertentu.
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 langsung mencatat log 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. Beri aplikasi akses ke data PCI hanya setelah aplikasi disanitasi dengan Perlindungan Data Sensitif (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 miliknya sendiri, seperti portal penagihan layanan pelanggan. Alat tersebut harus memiliki kontrol akses yang kuat; alat harus memiliki akses individual yang menggunakan autentikasi multi-faktor (pasal 8.4); dan harus diinstrumentasikan dengan logging audit (pasal 10.2).
Setiap log yang Anda buat harus menjawab pertanyaan berikut: Siapa yang melakukan apa? Di mana mereka melakukannya? Kapan mereka melakukannya? Menurut pasal 2.2.7, semua akses ke alat tersebut harus menggunakan enkripsi transpor yang kuat. Gunakan Sensitive Data Protection 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. Layanan ini dapat membuat, menggunakan, merotasi, dan menghancurkan kunci enkripsi AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256, dan EC P384. Dengan Cloud KMS, Anda dapat menghapus sandi berteks biasa yang disimpan dalam kode atau file konfigurasi, sehingga menyederhanakan kepatuhan terhadap bagian 2.2.2, 3.6, 3.7, dan 8.2.
Memvalidasi lingkungan Anda
Setelah lingkungan Anda diimplementasikan, tetapi sebelum traffic produksi mengalir melaluinya, Anda harus memvalidasi lingkungan tersebut:
- 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 cap persetujuan.
- Jika Anda adalah penjual Level 2 atau lebih rendah, Anda dapat memvalidasi lingkungan dengan mengisi Kuesioner Penilaian Mandiri.
Langkah selanjutnya
- Library dokumen PCI DSS
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.