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 Pedoman Cloud Computing PCI SSC (PDF) untuk memberikan latar belakang tentang standar tersebut, 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, mencatat, dan memvalidasi aplikasi Anda.
Dokumen ini mengacu pada persyaratan PCI DSS 4.0 jika berlaku.
Standar Keamanan Data PCI, yang dibuat oleh Dewan Standar Keamanan PCI, adalah standar keamanan informasi untuk bisnis yang menangani kartu pembayaran (kredit dan debit) tidak akurat atau tidak sesuai. Dewan Standar Keamanan PCI mencakup setiap pembayaran besar perusahaan kartu kredit. Bisnis yang menerima Visa, MasterCard, Discover, American Express, JCB, atau UnionPay diharapkan mematuhi PCI DSS, dan dapat dikenai denda atau sanksi jika mereka tidak melakukannya.
PCI DSS mencakup klasifikasi untuk beberapa jenis penjual, dari penjual yang mengumpulkan informasi pembayaran secara langsung kepada penjual yang melakukan outsourcing pembayaran diproses secara keseluruhan. Panduan ini membahas SAQA, SAQ A-EP, dan SAQ D jenis penjual.
Tujuan
- Tinjau arsitektur aplikasi pemrosesan pembayaran.
- Siapkan lingkungan pemrosesan pembayaran Anda.
- Deploy dan konfigurasi server aplikasi Anda.
- Siapkan logging dan monitoring.
- Validasi lingkungan pemrosesan pembayaran Anda.
Definisi
Panduan ini menggunakan banyak frasa unik. Berikut adalah beberapa yang paling umum. Sebagai informasi selengkapnya, lihat Glosarium PCI DSS.
CDE: Akronim untuk lingkungan data pemegang kartu. Akronim ini mengacu pada bagian dari aplikasi Anda yang menyimpan atau mentransfer data pemegang kartu apa pun, termasuk nomor rekening 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 kendala 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 dan Prosedur Penilaian Keamanan PCI DSS untuk panduan tentang penggunaan kontrol kompensasi.
PAN: Akronim untuk nomor rekening utama dan juga disebut sebagai akun angka Nomor ini adalah nomor kartu pembayaran unik yang mengidentifikasi penerbit dan rekening pemegang kartu.
QSA: Akronim dari Qualified Security Assessor. QSA dikualifikasikan berdasarkan Dewan Standar Keamanan PCI (SSC) untuk melakukan penilaian di lokasi PCI DSS. Tujuan 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 bagi entitas yang memenuhi syarat untuk penilaian mandiri.
Cakupan: Sistem, prosedur, dan orang yang akan disertakan dalam PCI DSS penilaian.
Tokenisasi: Proses yang mengganti nomor rekening utama (PAN) dengan nilai surrogate yang disebut token. PAN kemudian disimpan dalam pencarian yang aman. De-tokenisasi adalah proses kebalikan 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 bernomor utama dan banyak subbagian. Dokumen ini mereferensikan nomor bagian untuk menambahkan konteks, tapi referensi bagian ini bukan yang lengkap daftar persyaratan yang berlaku.
Persyaratan kepatuhan PCI DSS Anda bervariasi, bergantung pada cara perusahaan Anda menangani transaksi (jenis) kartu pembayaran dan jumlah transaksi yang dilakukan setiap tahun (tingkat).
Seiring dengan meningkatnya jumlah transaksi, Level penjual PCI DSS meningkat, dan pedoman kepatuhan PCI DSS menjadi lebih ketat. Di titik tertinggi level penjual, Level 1, PCI DSS memerlukan audit. Level bervariasi menurut merek kartu. Level 1 didefinisikan oleh American Express sebagai 2,5 juta per tahun transaksi, dan oleh Visa, Mastercard, dan Discover sebagai 6 juta transaksi tahunan transaksi. Setiap merek kartu memiliki persyaratan level tambahan yang lebih dari cakupan dokumen ini. Pastikan lingkungan pemrosesan pembayaran Anda diaudit untuk mendukung tingkat penjual Anda.
Karena Google Cloud adalah layanan yang mematuhi PCI DSS 4.0 Level 1 penyedia layanan, penyedia ini dapat mendukung kebutuhan kepatuhan PCI DSS Anda, terlepas dari tingkat penjual perusahaan tersebut. Tujuan Berkomitmen pada kepatuhan menjabarkan area mana saja yang dicakup untuk Anda oleh Google.
Variabel dasar lainnya adalah jenis SAQ Anda. SAQ menguraikan yang harus dipenuhi untuk mematuhi PCI DSS jika Anda memenuhi syarat untuk penilaian mandiri. Jenis SAQ Anda adalah ditentukan oleh arsitektur aplikasi dan cara Anda menangani data kartu pembayaran. Sebagian besar penjual di cloud adalah salah satu dari berikut ini:
| Jenis SAQ | Deskripsi |
|---|---|
| A | Penjual yang telah sepenuhnya mengalihdayakan pemrosesan kartu pembayaran ke
situs pihak ketiga. Pelanggan meninggalkan domain Anda (termasuk melalui
<iframe> formulir web), lengkapi pembayaran, lalu kembali ke
aplikasi.Dengan kata lain, perusahaan Anda tidak dapat menyentuh data kartu pelanggan dengan sebelumnya. |
| A-EP | Penjual yang mengalihkan pemrosesan pembayaran ke penyedia pihak ketiga, tetapi
yang 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 di sisi klien, atau prosesor 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 pemroses pembayaran
API dari servernya 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 untuk alamat penjual sebagaimana didefinisikan dalam PCI DSS. |
Berkomitmen pada kepatuhan
Google menggunakan berbagai teknologi dan proses untuk mengamankan informasi yang disimpan di server Google. Google memvalidasi PCI DSS secara independen persyaratan 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 memiliki kontrol atas instance komputasi mereka yang berjalan di infrastruktur Google, tidak mengontrol keamanan sistem operasi, paket, atau aplikasi yang penjual melakukan deployment di Google Cloud. Anda bertanggung jawab untuk mematuhi Persyaratan PCI DSS untuk paket sistem operasi dan aplikasi yang Anda deploy, di tambahan untuk penyesuaian lain yang dibutuhkan oleh arsitektur Anda.
Google Cloud mengikuti persyaratan PCI DSS yang ditetapkan untuk Level 1 Penyedia Layanan dan semua persyaratan penyedia layanan yang berlaku. Tujuan Google Cloud Matriks Tanggung Jawab Bersama menguraikan kewajiban kepatuhan PCI DSS. Matriks tanggung jawab dapat menjadi referensi yang bermanfaat untuk memenuhi kepatuhan PCI DSS dan Audit PCI DSS.
Panduan produk
Bagian ini berisi panduan layanan Google Cloud yang umum digunakan dalam arsitektur yang digunakan untuk lingkungan PCI DSS.
App Engine
Gunakan aturan firewall masuk App Engine dan kontrol traffic keluar.
Cloud Run
Gunakan setelan masuk, Kontrol Layanan VPC Cloud Run, dan kontrol keluar pada konektor VPC. Jika perlu, konfigurasi alamat IP keluar statis.
Fungsi Cloud Run
Gunakan setelan jaringan masuk dan keluar fungsi Cloud Run.
Cloud Logging
Mencatat interaksi dengan Cloud Logging.
Cloud Monitoring
Memantau interaksi dengan Cloud Monitoring.
Google Kubernetes Engine
Untuk mengetahui 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 rekening utama (PAN) diamankan di mana pun nomor tersebut disimpan. Meskipun Google otomatis menawarkan enkripsi dalam penyimpanan, Google tidak secara otomatis melakukan {i>hash<i} satu arah, pemotongan, atau tokenisasi yang juga oleh aturan itu butuhkan.
Contoh arsitektur
Bagian ini menggambarkan 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 adalah diproses oleh pihak ketiga, dan tidak ada data kartu yang diakses oleh penjual aplikasi atau halaman.
Secara umum, alur pemrosesan pembayaran adalah sebagai berikut:
Pelanggan menentukan pilihan dan melanjutkan ke check out.
Aplikasi checkout mengalihkan pelanggan ke pembayaran pihak ketiga Prosesor Google Cloud.
Pelanggan memasukkan informasi kartu pembayarannya ke formulir pembayaran yang dimiliki dan dipelihara oleh pemroses pihak ketiga.
Pemroses pembayaran pihak ketiga memeriksa informasi kartu pembayaran lalu menagih atau menolak kartu tersebut.
Setelah memproses transaksi, pemroses pembayaran pihak ketiga mengirim pelanggan kembali ke aplikasi penjual bersama dengan detail transaksi.
Aplikasi penjual mengirimkan permintaan verifikasi ke pembayaran untuk mengonfirmasi transaksi.
Pemroses pembayaran merespons untuk memverifikasi detail transaksi.
SAQ A-EP
Arsitektur pemrosesan pembayaran SAQ A-EP berpusat pada aplikasi pemrosesan pembayaran yang berjalan di virtual Compute Engine di instance Compute Engine. {i>Instance <i}ini berada di jaringan pribadi yang aman, dan mereka menggunakan saluran yang aman untuk berkomunikasi dengan layanan yang berada di luar jaringan.
Secara umum, alur pemrosesan pembayaran adalah sebagai berikut:
Pelanggan memasukkan informasi kartu pembayarannya ke formulir pembayaran yang dimiliki dan dikelola oleh perusahaan Anda.
Ketika pelanggan mengirimkan informasi mereka, informasi formulir diteruskan dengan aman ke pemroses pembayaran pihak ketiga.
Pemroses pembayaran pihak ketiga 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 Cloud Logging dan Cloud Monitoring.
SAQ D
Arsitektur pemrosesan pembayaran SAQ D berpusat di aplikasi pemrosesan pembayaran yang berjalan di virtual Compute Engine di instance Compute Engine. {i>Instance <i}ini berada di jaringan pribadi yang aman dan menggunakan saluran yang aman untuk berkomunikasi dengan layanan yang berada di luar jaringan.
Secara umum, alur pemrosesan pembayaran adalah sebagai berikut:
Pelanggan memasukkan informasi kartu pembayarannya ke formulir pembayaran yang dimiliki dan dikelola oleh perusahaan Anda.
Saat pelanggan mengirimkan informasi mereka, aplikasi pembayaran Anda menerima informasi formulir.
Aplikasi pembayaran Anda memvalidasi informasi pembayaran dan dengan aman meneruskannya ke pemroses pembayaran pihak ketiga melalui API backend.
Pemroses pembayaran pihak ketiga 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 Pemantauan.
Alur pemrosesan pembayaran yang ditujukan 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 menampilkan
<iframe> dihosting oleh pemroses pembayaran. Nama
aplikasi tidak dapat mengakses
atau memantau konten
<iframe> karena
batasan berbagi resource lintas origin.
Ketika pelanggan mengirimkan informasi kartu pembayaran, pembayaran
pemroses menerima atau menolak kartu, lalu mengirim pelanggan kembali ke
. Aplikasi Anda kemudian memeriksa respons transaksi dari
pemroses pembayaran dan bertindak sesuai dengan itu. Aplikasi Anda tidak mengakses atau
menangani informasi
kartu pembayaran.
SAQ A-EP
Bagian ini menjelaskan alur pemrosesan pembayaran internal yang sama dengan dijelaskan sebelumnya, tetapi dari perspektif pelanggan yang menggunakan aplikasi Anda.
Saat pelanggan mengakses URL untuk formulir pembayaran Anda, situs menyajikan formulir yang dihosting oleh aplikasi pembayaran Anda. Saat pelanggan mengirimkan informasi kartu pembayaran, formulir akan langsung dikirim ke pemroses pembayaran. Pemroses menerima atau menolak kartu, lalu mengirim pelanggan kembali ke aplikasi Anda. Aplikasi Anda kemudian memeriksa respons transaksi dari pemroses pembayaran dan bertindak sesuai dengan itu. Pelanggan mungkin tidak melihat pemroses pembayaran pihak ketiga, tetapi aplikasi Anda tidak mengakses informasi kartu pembayaran di sisi server.
SAQ D
Bagian ini menjelaskan alur pemrosesan pembayaran internal dari perspektif pelanggan yang menggunakan aplikasi Anda.
Saat pelanggan mengakses URL untuk metode pembayaran Anda, mereka aman yang dirutekan ke formulir melalui load balancer HTTPS. Saat pelanggan mengirimkan informasi kartu pembayarannya, aplikasi pemrosesan pembayaran Anda dengan aman mengirimkan informasi tersebut ke pemroses pembayaran pihak ketiga. Pihak ketiga pemroses pembayaran menerima atau menolak kartu, lalu mengembalikan 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 akan menerima dan mengurai respons dikembalikan oleh pemroses pembayaran pihak ketiga, dan kemudian mengirimkan beberapa atau semua data respons ke aplikasi inti. Pada tahap ini, aplikasi pemrosesan pembayaran diselesaikan dengan transaksi. Bagian inti menangani tugas memberi tahu pelanggan Anda.
SAQ D
Bagian ini menjelaskan alur pemrosesan pembayaran internal dari perspektif server yang menjalankan aplikasi Anda.
Aplikasi pemrosesan pembayaran memvalidasi informasi kartu pembayaran dikirimkan oleh pelanggan, lalu mengirimkannya ke pemroses pembayaran melalui API backend. Prosesor mencoba mengisi daya dan merespons dengan detail transaksi. Aplikasi Anda menerima dan memproses respons lalu mengirim beberapa atau semua data respons ke aplikasi inti. Di pada tahap ini, aplikasi pemrosesan pembayaran Anda sudah selesai dengan saat melakukan transaksi. Aplikasi inti menangani tugas memberi tahu pelanggan dan memberikan produk.
Memantau dan melakukan logging aliran data
Alur pemantauan dan logging dirancang sebagai berikut:
Menyiapkan lingkungan pemrosesan pembayaran Anda
Bagian ini menjelaskan cara menyiapkan lingkungan pemrosesan pembayaran. Penyiapan mencakup hal berikut:
- Membuat akun Google Cloud baru untuk mengisolasi pembayaran online dari lingkungan produksi Anda.
- Membatasi akses ke lingkungan Anda.
- Menyiapkan resource virtual.
- Merancang image Linux dasar yang akan Anda gunakan untuk menyiapkan server aplikasi Google Cloud.
- Menerapkan solusi pengelolaan paket yang aman.
Menyiapkan akun baru
Untuk menyederhanakan pembatasan akses dan audit kepatuhan, buat kualitas produksi, dan lingkungan pemrosesan pembayaran yang sepenuhnya terisolasi dari lingkungan produksi standar serta lingkungan pengembangan dan UM (Uji Mutu) apa pun (persyaratan 6.5.3). Untuk memastikan isolasi, buat dan gunakan akun Google Cloud yang terpisah dari akun lingkungan produksi inti. Pengguna yang berpengalaman dengan Identity and Access Management (IAM) dapat menyelesaikan isolasi yang setara dengan menggunakan project terpisah untuk pekerjaan dalam ruang lingkup proyek.
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). Proses ini dikenal sebagai prinsip hak istimewa terendah. Menggunakan IAM peran untuk membatasi akses. Praktik terbaik adalah menggunakan peran bila memungkinkan, hanya memberikan izin yang diperlukan untuk melakukan pekerjaan yang diharapkan, dan hanya memberikan peran Pemilik kepada akun utama yang secara sah memerlukan akses {i>root<i} penuh ke layanan Anda. Lihat Panduan keamanan IAM untuk informasi selengkapnya.
Akses otomatis ke setiap layanan terkelola harus bergantung pada akun layanan Anda. Akun layanan menyederhanakan siklus proses pengelolaan aplikasi dengan memberi Anda untuk mengelola otentikasi dan otorisasi aplikasi. Akun ini memberikan cara yang fleksibel namun aman untuk mengelompokkan instance virtual machine dengan aplikasi dan fungsi yang memiliki identitas bersama. Anda dapat menegakkan keamanan dan memiliki 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 di 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 {i>password<i} pengguna. Nasional Institute of Standards and Technology (NIST) menentukan kumpulan aturan yang lebih aman untuk sandi yang aman di pasal 5.1.1 NIST SP800-63B. Google merekomendasikan untuk mengikuti panduan Identitas Digital NIST setiap kali sebaik mungkin.
PCI DSS SAQ D bagian 12.7 memerlukan individu yang memiliki akses ke dalam cakupan agar lulus pemeriksaan latar belakang, sesuai dengan hukum setempat, sebelum mereka diberi akses ke lingkungan. Untuk mengurangi risiko kepatuhan pelanggaran ini, pertimbangkan untuk melakukan pemeriksaan latar belakang kriminal ini pemeriksaan pada setiap individu terlepas dari jenis kepatuhan Anda.
Mengamankan jaringan Anda
Untuk mengamankan traffic masuk dan keluar ke dan dari pemrosesan pembayaran Anda jaringan aplikasi, Anda perlu membuat hal berikut:
- Kebijakan Firewall Cloud Next Generation atau aturan firewall Compute Engine
- Tunnel Cloud VPN
- Load Balancer Aplikasi Eksternal
Untuk membuat VPC, sebaiknya Anda juga Cloud NAT untuk lapisan keamanan jaringan tambahan. Ada banyak opsi canggih yang tersedia untuk mengamankan jaringan Compute Engine di instance GKE.
Membuat aturan firewall
Gunakan Kebijakan Firewall Cloud Next Generation atau aturan firewall VPC untuk membatasi traffic masuk ke setiap instance Compute Engine (persyaratan 1.3 dan 1.4). Izinkan traffic masuk hanya dari berikut ini tiga sumber:
- HTTPS publik, agar pelanggan dapat membuka halaman pembayaran Anda.
- Jaringan aplikasi Anda, agar aplikasi pemrosesan pembayaran menerima respons dari pemroses pembayaran pihak ketiga Anda.
- Jaringan internal kantor Anda, sehingga Anda dapat mengakses instance untuk tujuan audit dan manajemen.
Menggunakan aturan firewall pada instance individual untuk membatasi traffic keluar. Anda dapat menerapkan aturan ini secara lokal dengan iptable atau, lebih luas lagi, dengan menggunakan VPC aturan firewall dan tag jaringan. Hanya mengizinkan traffic keluar dari formulir pembayaran Anda ke pembayaran pihak ketiga Prosesor Google Cloud. Koneksi ini harus khusus HTTPS. Untuk menguji pekerjaan Anda, lihat bagian tentang Firewall Rules Logging nanti dalam dokumen ini.
Cloud DNS menawarkan zona DNS pribadi sehingga Anda dapat memberi nama {i>host<i} di dalam CDE dengan aman tanpa potensi membocorkan data topologi jaringan sensitif ke 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 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) |
| Jaringan kantor perusahaan Anda | Gateway VPN | tcp:8000 | Masuk Akses ke lingkungan pemrosesan pembayaran untuk mengakses log dan mesin pengembangan |
Selain itu, traffic berikut terjadi secara aman di jaringan internal aplikasi pemrosesan pembayaran:
| Asal | Tujuan | Port | Alasan |
|---|---|---|---|
| Formulir kartu | Proxy PCI | tcp:5480 | Pertukaran data kartu yang dienkripsi 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 di antara infrastruktur 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 berikut ini:
- Subdomain situs Anda yang digunakan untuk pemrosesan pembayaran
formulir, misalnya,
payments.your-domain-name.com. - Sertifikat SSL valid yang ditandatangani yang telah terdaftar untuk subdomain Anda.
Pastikan domain Anda valid dengan melihat setelan DNS-nya di web Anda antarmuka konfigurasi domain registrar.
Membuat image Linux dasar
PCI DSS berisi persyaratan yang menjelaskan cara mengatur mesin yang sebagai bagian dari arsitektur pemrosesan pembayaran yang sesuai dengan kebijakan. Anda dapat menerapkan persyaratan dalam beberapa cara, tetapi pendekatan yang paling mudah adalah sebagai berikut:
Membuat daftar {i>software<i} dan {i>library<i} yang harus diinstal setiap server yang tercakup dalam aplikasi pemrosesan pembayaran Anda. Kepada menghindari timbulnya kerentanan yang tidak perlu pada sistem Anda (persyaratan 2.2.4), hanya menyertakan perangkat lunak dan perpustakaan minimum yang Anda perlukan untuk menjalankan aplikasi. Kandidat dapat mencakup Google Cloud CLI, {i>runtime<i} dan pustaka untuk bahasa tertentu, atau server web.
Buat instance Compute Engine yang menggunakan salah satu Mesin Komputasi image sistem operasi yang telah dikonfigurasi sebelumnya.
Instal library dan software yang Anda cantumkan sebelumnya.
Instal dan konfigurasi
ntpagar jam sistem tetap sinkron. Mengelola jam server dengan Protokol Waktu Jaringan memastikan integritas dari stempel waktu di log (bagian 10.6).Pastikan gambar mengikuti praktik terbaik untuk membuat image Compute Engine yang aman (semua bagian 2.2).
Setelah Anda mengonfigurasi image dasar, buat disk image Compute Engine kustom dari gambar Anda. Dengan image ini, Anda dapat menggunakan image Linux dasar saat saat membuat instance virtual machine.
Menggunakan pengelolaan paket yang aman
Pengelolaan paket adalah komponen utama dari hosting yang diperkuat dengan keamanan lingkungan fleksibel App Engine. Sesuai dengan bagian 2.2, Anda harus menerapkan hardening yang diterima industri standar. Kecuali jika Anda menggunakan OS yang Dioptimalkan untuk Container dari Google, Anda mungkin telah menginstal pengelola paket seperti RPM, Yum, atau Apt. Nama aplikasi mungkin menggunakan pengelola paket khusus bahasa pemrograman sendiri seperti sebagai NPM, PyPi, atau Composer, dan mendownload dependensi saat pertama kali dijalankan.
Jika aplikasi Anda dapat mengambil update dari internet, Anda harus memperlakukan update sebagai potensi risiko keamanan. Serangan {i>supply-side<i}, atau upstream, yang yang termasuk jahat dalam paket yang di-{i>host <i}umum menjadi lebih umum ditemui. Bayangkan efek dari menginstal update ke SSH yang berisi kode berbahaya.
Anda dapat memitigasi risiko serangan sisi suplai dengan membuat penerima yang aman untuk paket Anda dan memverifikasi bahwa mereka cocok dengan daftar. Simpan daftar nomor versi yang diuji dan disetujui untuk setiap paket yang Anda gunakan. Rekam nomor versi beserta {i>hash <i}atau tanda tangannya. Pastikan bahwa pengelola paket memvalidasi hash atau tanda tangan sebelum menginstal atau mengupdate aplikasi.
Sebagian besar sistem manajemen paket mengizinkan hosting pribadi. Jika memungkinkan, luncurkan server pengelolaan paket pribadi Anda dan hanya {i>host<i} yang diuji dan disetujui {i>software<i}. Mengunci pengelola paket sehingga tidak dapat menjangkau orang lain server untuk pembaruan.
Idealnya, proses pembangunan aplikasi Anda mengambil dan memvalidasi semua paket, dan kemudian membuat revisi {i>disk image <i} khusus yang menyertakan semua yang dibutuhkan container. Dengan cara ini, server Anda diluncurkan dan meningkatkan skala tanpa penundaan {i>installer<i}, dan ada lebih sedikit kemungkinan kesalahan acak pada waktu peluncuran. Anda juga dapat membuka kembali versi aplikasi sebelumnya persis seperti sebelumnya dalam produksi dengan meluncurkan {i>image<i}-nya, yang dapat membantu untuk diagnostik dan forensik.
Deployment dan konfigurasi
Selanjutnya, siapkan deployment dan konfigurasi instance dari basis Anda gambar.
Men-deploy lingkungan Anda
Untuk memenuhi persyaratan PCI DSS, pastikan Anda men-deploy aplikasi Anda setiap saat, bahwa Anda men-deploy aplikasi dengan aman, dan bahwa Anda tidak menginstal paket perangkat lunak lain selama deployment. Kepada menyederhanakan proses deployment, pertimbangkan pembuatan deployment otomatis untuk aplikasi Anda menggunakan Terraform. Terraform memungkinkan Anda menggambarkan seluruh lingkungan pemrosesan pembayaran Anda, termasuk aturan firewall, gateway, load balancer, dan instance dalam kode.
Dalam deployment otomatis, Anda harus memverifikasi integritas software yang digunakan, baik itu dari pihak ketiga atau milik Anda sendiri. Anda dapat memverifikasi perangkat lunak Anda dengan menjalankan {i>hash <i} otomatis terhadap setiap paket sebagai paket diinstal. Setelah {i>hash<i} diverifikasi, Anda kemudian dapat menggunakan metode kerangka kerja pengujian untuk menjalankan pengujian keamanan dan lainnya, telah berlalu.
Terakhir, saat men-deploy instance Compute Engine, rancang pemulihan rencana jika terjadi kegagalan instance Anda. Jika jendela Anda untuk penerimaan periode nonaktif yang cukup besar, rencana pemulihan manual mungkin cukup memadai; jika tidak, Anda harus merancang rencana pemulihan otomatis. Lihat Panduan perencanaan pemulihan dari bencana, Mendesain sistem yang tangguh dan Membangun aplikasi web yang skalabel dan tangguh untuk panduan.
Mengonfigurasi lingkungan Anda
Setelah instance di-deploy, pastikan instance tersebut dikonfigurasi dengan benar. Menginstal software dan library tambahan di atas setiap instance image dasar sesuai kebutuhan. Untuk menghindari kerumitan, {i>overhead<i}, dan risiko keseluruhan konfigurasi manual, gunakan alat manajemen konfigurasi otomatis seperti Skaffold Koki, Boneka, Ansible, atau Garam.
Menerapkan logging audit yang tidak dapat diubah
Logging menghasilkan log audit secara otomatis untuk berbagai macam aktivitas di banyak produk. Dalam jangka panjang, Anda dapat dengan aman menyimpan log yang tidak dapat diubah dengan menggunakan Penguncian 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 tertentu yang Anda tentukan, dari detik hingga tahun.
Menerapkan Log Alur Virtual Private Cloud
Tujuan Log Aliran VPC dirancang untuk merekam aliran jaringan yang dikirim dari atau diterima oleh mengonfigurasi ulang instance virtual machine secara fleksibel. Anda dapat menggunakan log ini untuk pemantauan jaringan, forensik, dan analisis keamanan real-time (bagian 10.2).
Menginstal agen Logging
Setelah Anda menyiapkan {i>iptables<i} di server Anda, setiap server mencatat setiap aktivitas ke ke blok storage server. Lihat Logging halaman harga untuk mengetahui detail harga alokasi gratis dan transfer data. Untuk menyimpan log ini dan membuat notifikasi berdasarkan aktivitas yang mencurigakan, lakukan streaming ke Logging dan Monitoring dengan menginstal Agen Logging pada setiap server (bagian 10.3).
Mengintegrasikan Intrusion Detection System
Untuk membantu memastikan keamanan lingkungan pemrosesan pembayaran Anda, dijelaskan dalam bagian 11.5, gunakan intrusion detection system (IDS), jadi Anda tahu ketika pihak tidak bertanggung jawab mencoba untuk menyerang sistem. Ada dua cara untuk menempatkan IDS di lingkungan pemrosesan pembayaran: menempatkan IDS di setiap titik masuk, atau menginstal IDS di setiap server.
Untuk mengurangi kerumitan arsitektur lingkungan dan menyederhanakan kepatuhan terhadap 11.5, menginstal IDS pada setiap server. Setelah Anda meneliti dan memilih perangkat lunak IDS yang akan digunakan, membuat instalasi IDS menjadi bagian dari skrip instalasi startup untuk setiap server.
Cloud Intrusion Detection System (Cloud IDS), sebuah layanan deteksi penyusupan, menyediakan deteksi ancaman terhadap penyusupan, {i>malware<i}, 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 dapat juga menggunakan Cloud IDS untuk menyederhanakan kepatuhan terhadap persyaratan 11.5.
Log IDS termasuk dalam cakupan kepatuhan PCI DSS, dan harus dikirim ke Logging dan Monitoring untuk pelaporan, pemberitahuan, dan audit.
Mengimplementasikan Security Command Center
Security Command Center membantu tim keamanan mengumpulkan data, mengidentifikasi ancaman, dan merespons terhadap ancaman sebelum mengakibatkan kerusakan atau kerugian bisnis. Alat ini menawarkan insight yang mendalam terhadap risiko aplikasi dan data sehingga Anda dapat dengan cepat memitigasi ancaman terhadap resource cloud dan mengevaluasi kondisi 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
Bangun alat manajemen konfigurasi Anda untuk mengambil dan meluncurkan versi terbaru aplikasi Anda. Aplikasi Anda dapat diambil dari lokasi, seperti Penyimpanan Cloud, selama lokasi tersebut aman.
Banyak alat manajemen konfigurasi yang disebutkan sebelumnya mendukung integrasi 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 mencatat semua detail penginstalan. Setelah menyelesaikan proses konfigurasi, pastikan mengirimkan log ke Logging dan Monitoring.
Logging dan pemantauan
Untuk memastikan kepatuhan PCI DSS berdasarkan pasal 10, pastikan bahwa setiap langkah lingkungan pemrosesan pembayaran Anda dipantau dan dicatat. Setiap server di setiap instance harus dicatat, dan setiap tindakan pengguna harus dapat untuk ditinjau di lain waktu.
Mengaktifkan Transparansi Akses
Melalui Transparansi Akses, Pencatatan log sekarang menawarkan log yang mendekati real-time saat Admin Google Cloud mengakses konten Anda. Log Cloud Audit Logs sudah memberikan visibilitas tentang tindakan admin Anda. Namun, audit ini biasanya tidak mencakup tindakan yang diambil oleh dukungan penyedia {i>cloud<i} Anda atau teknik. Misalnya, sebelum pencatatan log Persetujuan Akses, jika jika Anda membuka tiket dengan Dukungan Google yang memerlukan akses data, tiket itu tidak akan telah dilacak di Cloud Audit Logs. Persetujuan Akses menutup yang gap, pencatatan log akses tertarget dan manual yang mendekati real-time oleh salah satu atau teknik.
Persetujuan Akses memungkinkan Anda secara eksplisit menyetujui akses ke data atau konfigurasi Anda di Google Cloud sebelum akses tersebut dilakukan. Persetujuan Akses juga memberikan insight tentang akses oleh Dukungan dan Engineering Google.
Mengaktifkan Firewall Rules Logging
Firewall Rules Logging memungkinkan Anda mengaktifkan pencatatan log di level aturan individual. Dapat merekam koneksi TCP dan UDP di dalam VPC untuk aturan apa pun yang Anda buat diri Anda 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 dapat Anda gunakan untuk menentukan perimeter keamanan di sekitar Google Cloud resource seperti bucket Cloud Storage, Bigtable instance, dan set data BigQuery untuk membatasi data dalam 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 data sensitif Anda tetap pribadi saat keuntungan dari penyimpanan yang terkelola sepenuhnya dan kemampuan pemrosesan data dari Google Cloud.
Menyiapkan Log Aliran VPC
Log Aliran VPC mencatat alur traffic jaringan yang dikirim atau diterima oleh instance VM. Log tersebut berguna berdasarkan PCI DSS untuk pemantauan, audit, forensik, dan keamanan {i>real-time<i} analisis data. Setiap subnet jaringan VPC dapat mengaktifkan Log Aliran atau dinonaktifkan secara terpisah. Anda dapat meminimalkan jumlah data log dengan hanya mengaktifkan Aliran Log pada CDE dalam cakupan Anda. Log Aliran, digabungkan dengan aturan firewall keluar, memungkinkan Anda membatasi permintaan keluar traffic ke endpoint yang diotorisasi dengan cara yang dapat diaudit dan sulit pengelakan (persyaratan 1.2.1 dan 1.3.4).
Diagram berikut menunjukkan bagaimana VPC Flow Logs mencatat alur traffic jaringan yang dikirim atau diterima oleh instance VM."
Jika Anda memerlukan data yang lebih mendetail daripada yang dapat disediakan oleh Log Aliran, seperti Pencatatan log permintaan HTTP, Anda dapat menerapkan kontrol dalam aplikasi atau permintaan keluar proxy. Anda melakukannya dengan cara membalikkan sendiri server proxy 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, pantau dan catat juga aktivitas individu yang memiliki akses administrator ke pemrosesan pembayaran Anda (Pasal 10.2). Untuk melakukannya, Anda dapat mencatat perintah shell. Beberapa terbuka alat sumber dapat mengaudit perintah {i>shell<i} dan mengirimkannya ke {i>logging<i}. Pilihan populer untuk tugas ini mencakup OSSEC atau Tripwire.
Menyiapkan pemberitahuan pemantauan
Mengonfigurasi Monitoring untuk mengirim pemberitahuan jika terjadi masalah di lingkungan pemrosesan pembayaran Anda (bagian 10.6). Pastikan bahwa pemberitahuan mencakup peristiwa lingkungan, audit, dan aplikasi internal. Siapkan dasar strategi peringatan tentang potensi risiko atau vektor serangan untuk setiap komponen aplikasi pemrosesan pembayaran Anda. Misalnya, pemicu (trigger) Memantau peringatan jika IDS Anda mendeteksi upaya penyusupan, apakah mereka berhasil atau gagal. Anda juga dapat menggunakan Firewall Rules Logging untuk memicu pemberitahuan sebagai respons terhadap upaya untuk melanggar kebijakan jaringan.
Streaming log ke BigQuery
Secara opsional, Anda dapat merutekan log Logging ke BigQuery untuk dianalisis nanti; lihat Ringkasan pemilihan rute dan penyimpanan: Sink untuk mengetahui detailnya. Karena BigQuery dioptimalkan untuk kueri {i>dataset<i} ini, ini adalah alat yang ideal untuk analisis log berskala besar. Pencatatan log bahkan dapat langsung 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-bagian dari data yang terdapat dalam dalam ruang lingkup Anda aplikasi yang tidak berada dalam cakupan, seperti untuk analisis atau pengembangan produk. Beri aplikasi akses ke data PCI 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 mereka sendiri, seperti portal penagihan layanan pelanggan. Alat tersebut harus memiliki akses yang kuat controls; perangkat itu harus memiliki akses individual yang menggunakan otentikasi (bagian 8.4); dan harus diinstrumentasikan dengan logging audit (bagian 10.2).
Setiap log yang Anda buat harus menjawab pertanyaan ini: Siapa yang melakukan apa? Di mana mereka lakukan? Kapan mereka melakukannya? Menurut pasal 2.2.7, semua akses terhadap 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. Cloud Functions dapat menghasilkan, menggunakan, memutar, dan menghancurkan AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256, dan EC P384 kunci enkripsi. Cloud KMS memungkinkan Anda menghapus teks biasa sandi yang disimpan dalam file kode atau konfigurasi, yang 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 lingkungannya:
- 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 Standard Council untuk memvalidasi lingkungan PCI dan memberikan bukti persetujuan.
- Jika Anda adalah penjual Level 2 atau lebih rendah, Anda dapat memvalidasi lingkungan Anda dengan mengisi Kuesioner Penilaian Mandiri.
Langkah berikutnya
- Koleksi dokumen PCI DSS
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.