Kepatuhan PCI DSS di GKE

Panduan ini dimaksudkan untuk membantu Anda mengatasi masalah khusus pada aplikasi Google Kubernetes Engine (GKE) saat menerapkan tanggung jawab pelanggan untuk persyaratan Payment Card Industry Data Security Standard (PCI DSS).

Pernyataan penyangkalan: Panduan ini hanya untuk tujuan informasi. Google tidak bermaksud menjadikan informasi atau rekomendasi dalam panduan ini sebagai nasihat hukum atau audit. Setiap pelanggan bertanggung jawab untuk mengevaluasi penggunaan layanan mereka sendiri secara independen sesuai kebutuhan untuk mendukung kewajiban hukum dan kepatuhannya.

Pengantar kepatuhan PCI DSS dan GKE

Jika Anda menangani data kartu pembayaran, Anda harus mengamankannya—baik data tersebut berada di database lokal maupun di cloud. PCI DSS dikembangkan untuk mendorong dan meningkatkan keamanan data pemilik kartu serta memfasilitasi adopsi luas langkah-langkah keamanan data yang konsisten secara global. PCI DSS menyediakan dasar persyaratan teknis dan operasional yang dirancang untuk melindungi data kartu kredit. PCI DSS berlaku untuk semua entitas yang terlibat dalam pemrosesan kartu pembayaran—termasuk penjual, pemroses, acquirer, penerbit, dan penyedia layanan. PCI DSS juga berlaku untuk semua entitas lain yang menyimpan, memproses, atau mengirimkan data pemegang kartu (CHD) atau data autentikasi sensitif (SAD), atau keduanya.

Aplikasi dalam container telah menjadi populer baru-baru ini dengan banyaknya workload lama yang dimigrasikan dari arsitektur berbasis virtual machine (VM) ke arsitektur berbasis container. Google Kubernetes Engine adalah lingkungan terkelola dan siap produksi untuk men-deploy aplikasi dalam container. Kubernetes Engine menghadirkan inovasi terbaru Google dalam produktivitas developer, efisiensi resource, operasi otomatis, dan fleksibilitas open source untuk mempercepat waktu penyiapan produk Anda.

Kepatuhan adalah tanggung jawab bersama di cloud. Google Cloud, termasuk GKE (mode operasi Autopilot dan Standard), mematuhi persyaratan PCI DSS. Kami menguraikan tanggung jawab kami dalam Matriks tanggung jawab bersama.

Audiens yang ditargetkan

• Pelanggan yang ingin membawa workload yang sesuai dengan PCI ke Google Cloud yang melibatkan GKE.
• Developer, petugas keamanan, petugas kepatuhan, administrator IT, dan karyawan lain yang bertanggung jawab untuk menerapkan kontrol dan memastikan kepatuhan terhadap persyaratan PCI DSS.

Sebelum memulai

Untuk rekomendasi berikut, Anda mungkin harus menggunakan hal berikut:

• Google Cloud Resource Organisasi, Folder, dan Project
• Identity and Access Management (IAM)
• Google Kubernetes Engine
• Google Cloud VPC
• Google Cloud Armor
• Cloud Data Loss Prevention API (bagian dari Sensitive Data Protection)
• Identity-Aware Proxy (IAP)
• Security Command Center

Panduan ini ditujukan bagi pengguna yang sudah memahami container dan GKE.

Cakupan

Panduan ini mengidentifikasi persyaratan berikut dari PCI DSS yang merupakan masalah unik untuk GKE dan memberikan panduan untuk memenuhinya. Ditulis berdasarkan versi 4.0 standar. Panduan ini tidak mencakup semua persyaratan dalam PCI DSS. Informasi yang diberikan dalam panduan ini dapat membantu organisasi dalam upaya mereka untuk mematuhi PCI DSS, tetapi bukan saran yang komprehensif. Organisasi dapat melibatkan Penilai Keamanan Berkualifikasi (QSA) PCI untuk validasi formal.

Tujuan PCI DSS	Persyaratan PCI DSS
Menyegmentasikan lingkungan data pemegang kartu Anda	Terkadang disebut sebagai persyaratan 0. Meskipun tidak wajib untuk kepatuhan PCI, kami merekomendasikan persyaratan ini untuk menjaga cakupan PCI tetap terbatas.
Membangun dan memelihara jaringan dan sistem yang aman	1. Menginstal dan memelihara kontrol keamanan jaringan Persyaratan 1.1 Persyaratan 1.1.2 Persyaratan 1.2 Persyaratan 1.2.2 Persyaratan 1.2.5 Persyaratan 1.3 Persyaratan 1.3.1 Persyaratan 1.4 Persyaratan 1.4.3 Persyaratan 1.4.5 2. Menerapkan konfigurasi yang aman ke semua komponen sistem Persyaratan 2.2 Persyaratan 2.2.4 Persyaratan 2.2.5 Persyaratan 2.2.6
Melindungi data akun	3. Melindungi data akun yang disimpan Persyaratan 3.5 Persyaratan 3.6 4. Melindungi data pemegang kartu dengan kriptografi yang kuat selama transmisi melalui jaringan publik terbuka Persyaratan 4.1
Memelihara program pengelolaan kerentanan	5. Lindungi semua sistem dan jaringan dari software berbahaya Persyaratan 5.2 Persyaratan 5.2.3 Persyaratan 5.3 6. Mengembangkan dan memelihara sistem dan software yang aman Persyaratan 6.2 Persyaratan 6.2.1 Persyaratan 6.3 Persyaratan 6.3.1 Persyaratan 6.4
Menerapkan langkah-langkah kontrol akses yang kuat	7. Membatasi akses ke komponen sistem dan data pemegang kartu hanya untuk hal-hal yang perlu diketahui saja Persyaratan 7.2 Persyaratan 7.2.2 8. Mengidentifikasi dan mengautentikasi akses ke komponen sistem Persyaratan 8.2 Persyaratan 8.2.1 Persyaratan 8.2.5 Persyaratan 8.3 Persyaratan 8.3.1 9. Membatasi akses fisik ke data pemegang kartu
Memantau dan menguji jaringan secara rutin	10. Mencatat dan memantau semua akses ke komponen sistem dan data pemegang kartu Persyaratan 10.2 Persyaratan 10.2.2 11. Uji keamanan sistem dan jaringan secara rutin Persyaratan 11.3 Persyaratan 11.3.1 Persyaratan 11.5 Persyaratan 11.5.1
Mempertahankan kebijakan keamanan informasi	12. Mendukung keamanan informasi dengan kebijakan dan program organisasi

Terminologi

Bagian ini mendefinisikan istilah yang digunakan dalam panduan ini. Untuk mengetahui detail selengkapnya, lihat glosarium PCI DSS.

CHD

Data pemegang kartu Setidaknya, terdiri dari nomor akun utama (PAN) lengkap. Data pemegang kartu juga dapat muncul dalam bentuk PAN lengkap ditambah salah satu dari berikut ini:

• Nama pemegang kartu
• Tanggal habis masa berlaku atau kode layanan
• Data autentikasi sensitif (SAD)

CDE

lingkungan data pemegang kartu. Orang, proses, dan teknologi yang menyimpan, memproses, atau mengirimkan data pemegang kartu atau data autentikasi sensitif.

PAN

nomor rekening utama. Bagian penting dari data pemegang kartu yang wajib Anda lindungi berdasarkan PCI DSS. PAN umumnya adalah nomor 16 digit yang unik untuk kartu pembayaran (kredit dan debit) dan yang mengidentifikasi penerbit dan rekening pemegang kartu.

PIN

Nomor tanda pengenal pribadi. Password numerik yang hanya diketahui oleh pengguna dan sistem; yang digunakan untuk mengotentikasi pengguna ke sistem.

QSA

penilai keamanan yang memenuhi syarat. Orang yang disertifikasi oleh PCI Security Standards Council untuk melakukan audit dan analisis kepatuhan.

SAD

data autentikasi sensitif. Dalam kepatuhan PCI, data yang digunakan oleh penerbit kartu untuk mengotorisasi transaksi. Mirip dengan data pemegang kartu, PCI DSS mewajibkan perlindungan SAD. Selain itu, SAD tidak dapat dipertahankan oleh penjual dan pemroses pembayaran mereka. SAD mencakup hal berikut:

• Data "Track" dari kartu gesek
• "Melacak data yang setara" yang dihasilkan oleh kartu chip dan kartu nirsentuh
• Kode validasi keamanan (misalnya, angka 3-4 digit yang tercetak di kartu) yang digunakan untuk transaksi online dan transaksi tanpa kartu.
• PIN dan blok PIN

segmentasi

Dalam konteks PCI DSS, praktik mengisolasi CDE dari jaringan entitas lainnya. Segmentasi bukan persyaratan PCI DSS. Namun, sangat direkomendasikan sebagai metode yang dapat membantu mengurangi hal berikut:

• Cakupan dan biaya penilaian PCI DSS
• Biaya dan kesulitan dalam menerapkan dan memelihara kontrol PCI DSS
• Risiko bagi organisasi (dikurangi dengan menggabungkan data pemegang kartu ke dalam lebih sedikit lokasi yang lebih terkontrol)

Menyegmentasikan lingkungan data pemegang kartu Anda

Lingkungan data pemegang kartu (CDE) terdiri dari orang, proses, dan teknologi yang menyimpan, memproses, atau mengirimkan data pemegang kartu atau data autentikasi sensitif. Dalam konteks GKE, CDE juga mencakup hal berikut:

• Sistem yang menyediakan layanan keamanan (misalnya, IAM).
• Sistem yang memfasilitasi segmentasi (misalnya, project, folder, firewall, virtual private cloud (VPC), dan subnet).
• Pod dan cluster aplikasi yang menyimpan, memproses, atau mengirimkan data pemegang kartu. Tanpa segmentasi yang memadai, seluruh jejak cloud Anda dapat tercakup dalam PCI DSS.

Agar dianggap berada di luar cakupan PCI DSS, komponen sistem harus diisolasi dengan benar dari CDE sehingga meskipun komponen sistem di luar cakupan disusupi, hal itu tidak akan memengaruhi keamanan CDE.

Prasyarat penting untuk mengurangi cakupan CDE adalah pemahaman yang jelas tentang kebutuhan dan proses bisnis yang terkait dengan penyimpanan, pemrosesan, dan transmisi data pemegang kartu. Membatasi data pemegang kartu ke sesedikit mungkin lokasi dengan menghapus data yang tidak diperlukan dan menggabungkan data yang diperlukan mungkin mengharuskan Anda merekayasa ulang praktik bisnis yang sudah lama ada.

Anda dapat menyegmentasikan CDE dengan benar melalui sejumlah cara di Google Cloud. Bagian ini membahas cara berikut:

• Segmentasi logis menggunakan hierarki resource
• Segmentasi jaringan menggunakan VPC dan subnet
• Segmentasi tingkat layanan menggunakan VPC
• Pertimbangan lain untuk cluster dalam cakupan

Segmentasi logis menggunakan hierarki resource

Ada beberapa cara untuk mengisolasi CDE dalam struktur organisasi Anda menggunakan hierarki resource Google Cloud's. ResourceGoogle Cloud diatur secara hierarkis. Resource Organisasi adalah node root dalam hierarki resource Google Cloud . Folder dan project berada di bawah resource Organisasi. Folder dapat berisi project dan folder. Folder digunakan untuk mengontrol akses ke resource dalam hierarki folder melalui izin IAM level folder. Folder juga digunakan untuk mengelompokkan project serupa. Project adalah batas kepercayaan untuk semua resource Anda dan titik penerapan IAM.

Anda dapat mengelompokkan semua project yang berada dalam cakupan PCI dalam folder untuk mengisolasi pada level folder. Anda juga dapat menggunakan satu project untuk semua cluster dan aplikasi PCI yang tercakup, atau membuat project dan cluster untuk setiap aplikasi PCI yang tercakup dan menggunakannya untuk mengaturGoogle Cloud resource. Bagaimanapun, sebaiknya Anda menyimpan workload dalam cakupan dan di luar cakupan dalam project yang berbeda.

Segmentasi jaringan menggunakan jaringan dan subnet VPC

Anda dapat menggunakan Virtual Private Cloud (VPC) dan subnet untuk menyediakan jaringan Anda serta mengelompokkan dan mengisolasi resource terkait CDE. VPC adalah isolasi logis dari bagian cloud publik. Jaringan VPC menyediakan jaringan yang skalabel dan fleksibel untuk instance mesin virtual (VM) Compute Engine Anda dan untuk layanan yang menggunakan instance VM, termasuk GKE. Untuk detail selengkapnya, lihat ringkasan VPC dan lihat praktik terbaik dan arsitektur referensi.

Segmentasi tingkat layanan menggunakan Kontrol Layanan VPC dan Cloud Armor

Meskipun VPC dan subnet menyediakan segmentasi dan membuat perimeter untuk mengisolasi CDE Anda, Kontrol Layanan VPC memperluas perimeter keamanan di layer 7. Anda dapat menggunakan Kontrol Layanan VPC untuk membuat perimeter di sekitar project CDE dalam cakupan Anda. Kontrol Layanan VPC memberi Anda kontrol berikut:

• Kontrol ingress. Hanya identitas dan klien yang sah yang diizinkan masuk ke perimeter keamanan Anda.
• Kontrol keluar. Hanya tujuan yang sah yang diizinkan untuk identitas dan klien dalam perimeter keamanan Anda.

Anda dapat menggunakan Cloud Armor untuk membuat daftar alamat IP yang diizinkan atau ditolak aksesnya ke load balancer HTTP(S) di edge jaringan Google Cloud . Dengan memeriksa alamat IP sedekat mungkin dengan pengguna dan traffic berbahaya, Anda membantu mencegah traffic berbahaya menggunakan resource atau memasuki jaringan VPC Anda.

Gunakan Kontrol Layanan VPC untuk menentukan perimeter layanan di sekitar project dalam cakupan Anda. Perimeter ini mengatur jalur VM-ke-layanan dan layanan-ke-layanan, serta traffic masuk dan keluar VPC.

Membangun dan memelihara jaringan dan sistem yang aman

Membangun dan memelihara jaringan yang aman mencakup persyaratan 1 dan 2 PCI DSS.

Persyaratan 1

Menginstal dan memelihara konfigurasi firewall untuk melindungi data pemegang kartu dan lalu lintas ke dalam dan ke luar CDE.

Konsep jaringan untuk container dan GKE berbeda dengan konsep jaringan untuk VM tradisional. Pod dapat saling menjangkau secara langsung, tanpa NAT, bahkan di seluruh node. Hal ini menciptakan topologi jaringan sederhana yang mungkin mengejutkan jika Anda terbiasa mengelola sistem yang lebih kompleks. Langkah pertama dalam keamanan jaringan untuk GKE adalah mempelajari konsep jaringan ini.

Sebelum mempelajari persyaratan satu per satu dalam Persyaratan 1, Anda mungkin ingin meninjau konsep jaringan berikut yang terkait dengan GKE:

• Aturan firewall. Aturan firewall digunakan untuk membatasi traffic ke node Anda. Node GKE disediakan sebagai instance Compute Engine dan menggunakan mekanisme firewall yang sama seperti instance lainnya. Dalam jaringan, Anda dapat menggunakan tag untuk menerapkan aturan firewall ini ke setiap instance. Setiap node pool menerima serangkaian tagnya sendiri yang dapat Anda gunakan dalam aturan. Secara default, setiap instance yang termasuk dalam node pool menerima tag yang mengidentifikasi cluster GKE tertentu yang menjadi bagian dari node pool ini. Tag ini digunakan dalam aturan firewall yang dibuat GKE secara otomatis untuk Anda. Anda dapat menambahkan tag kustom pada waktu pembuatan cluster atau node pool menggunakan flag --tags di Google Cloud CLI.

• Kebijakan jaringan. Kebijakan jaringan memungkinkan Anda membatasi koneksi jaringan antar-pod, yang dapat membantu membatasi pengalihan jaringan dan pergerakan lateral di dalam cluster jika terjadi masalah keamanan pada pod. Untuk menggunakan kebijakan jaringan, Anda harus mengaktifkan fitur ini secara eksplisit saat membuat cluster GKE. Anda dapat mengaktifkannya di cluster yang ada, tetapi hal ini akan menyebabkan node cluster Anda dimulai ulang. Perilaku defaultnya adalah semua komunikasi pod-ke-pod selalu terbuka. Oleh karena itu, jika Anda ingin menyegmentasikan jaringan, Anda perlu menerapkan kebijakan jaringan tingkat pod. Di GKE, Anda dapat menentukan kebijakan jaringan menggunakan Kubernetes Network Policy API atau menggunakan alat kubectl. Aturan kebijakan traffic tingkat pod ini menentukan pod dan layanan mana yang dapat saling mengakses di dalam cluster Anda.

• Namespaces. Namespace memungkinkan segmentasi resource di dalam cluster Kubernetes Anda. Kubernetes dilengkapi dengan namespace default secara langsung, tetapi Anda dapat membuat beberapa namespace dalam cluster Anda. Namespace diisolasi secara logis satu sama lain. Namespace menyediakan cakupan untuk pod, layanan, dan deployment di cluster, sehingga pengguna yang berinteraksi dengan satu namespace tidak akan melihat konten di namespace lain. Namun, namespace dalam cluster yang sama tidak membatasi komunikasi antar-namespace; di sinilah peran kebijakan jaringan. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi namespace, lihat postingan blog Praktik Terbaik Namespace.

Diagram berikut menggambarkan konsep sebelumnya dalam kaitannya satu sama lain dan komponen GKE lainnya seperti cluster, node, dan pod.

Persyaratan 1.1

Proses dan mekanisme untuk menginstal dan memelihara kontrol keamanan jaringan telah ditentukan dan dipahami.

Persyaratan 1.1.2

Menjelaskan grup, peran, dan tanggung jawab untuk mengelola komponen jaringan.

Pertama, seperti yang Anda lakukan pada sebagian besar layanan di Google Cloud, Anda perlu mengonfigurasi peran IAM untuk menyiapkan otorisasi di GKE. Setelah menyiapkan peran IAM, Anda perlu menambahkan konfigurasi kontrol akses berbasis peran (RBAC) Kubernetes sebagai bagian dari strategi otorisasi Kubernetes.

Pada dasarnya, semua konfigurasi IAM berlaku untuk semua Google Cloud resource dan semua cluster dalam project. Konfigurasi RBAC Kubernetes berlaku untuk resource di setiap cluster Kubernetes, dan memungkinkan otorisasi terperinci di tingkat namespace. Dengan GKE, pendekatan otorisasi ini bekerja secara paralel, dengan kemampuan pengguna secara efektif merepresentasikan gabungan peran IAM dan RBAC yang ditetapkan kepadanya:

• Gunakan IAM untuk mengontrol grup, peran, dan tanggung jawab untuk pengelolaan logis komponen jaringan di GKE.
• Gunakan RBAC Kubernetes untuk memberikan izin terperinci ke kebijakan jaringan dalam cluster Kubernetes, untuk mengontrol traffic pod-ke-pod, dan untuk mencegah perubahan yang tidak sah atau tidak disengaja dari pengguna non-CDE.
• Dapat memberikan justifikasi untuk semua pengguna dan izin IAM dan RBAC. Biasanya, saat menguji kontrol, QSA mencari justifikasi bisnis untuk sampel IAM dan RBAC.

Persyaratan 1.2

Kontrol keamanan jaringan (NSC) dikonfigurasi dan dikelola.

Pertama, Anda mengonfigurasi aturan firewall di instance Compute Engine yang menjalankan node GKE Anda. Aturan firewall melindungi node cluster ini.

Selanjutnya, Anda mengonfigurasi kebijakan jaringan untuk membatasi alur dan melindungi pod dalam cluster. Kebijakan jaringan adalah spesifikasi pemberian izin pada grup pod untuk berkomunikasi satu sama lain dan dengan endpoint jaringan lainnya. Anda dapat menggunakan penerapan kebijakan jaringan GKE untuk mengontrol komunikasi antara pod dan layanan cluster Anda. Untuk menyegmentasikan cluster lebih lanjut, buat beberapa namespace di dalamnya. Namespace secara logis terpisah satu sama lain. Namespace menyediakan cakupan untuk pod, layanan, dan deployment dalam cluster, sehingga pengguna yang berinteraksi dengan satu namespace tidak akan melihat konten di namespace lain. Namun, namespace dalam cluster yang sama tidak membatasi komunikasi antar-namespace; di sinilah kebijakan jaringan berperan. Namespace memungkinkan segmentasi resource di dalam cluster Kubernetes Anda. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi namespace, lihat postingan blog Praktik Terbaik Namespace.

Secara default, jika tidak ada kebijakan di namespace, semua traffic masuk dan keluar diizinkan ke dan dari pod di namespace tersebut. Misalnya, Anda dapat membuat kebijakan isolasi default untuk namespace dengan membuat kebijakan jaringan yang memilih semua pod, tetapi tidak mengizinkan traffic masuk ke pod tersebut.

Persyaratan 1.2.2

Semua perubahan pada koneksi jaringan dan konfigurasi NSC disetujui dan dikelola sesuai dengan proses kontrol perubahan yang ditentukan dalam Persyaratan 6.5.1.

Untuk memperlakukan konfigurasi dan infrastruktur jaringan sebagai kode, Anda harus membuat pipeline continuous integration dan continuous delivery (CI/CD) sebagai bagian dari proses pengelolaan dan pengendalian perubahan.

Anda dapat menggunakan template Cloud Deployment Manager atau Terraform sebagai bagian dari pipeline CI/CD untuk membuat kebijakan jaringan di cluster Anda. Dengan Deployment Manager atau Terraform, Anda dapat memperlakukan konfigurasi dan infrastruktur sebagai kode yang dapat mereproduksi salinan yang konsisten dari lingkungan produksi saat ini atau lingkungan lainnya. Kemudian, Anda dapat menulis pengujian unit dan pengujian lainnya untuk memastikan perubahan jaringan Anda berfungsi seperti yang diharapkan. Proses kontrol perubahan yang mencakup persetujuan dapat dikelola melalui file konfigurasi yang disimpan di repositori versi.

Dengan Terraform Config Validator, Anda dapat menentukan batasan untuk menerapkan kebijakan keamanan dan tata kelola. Dengan menambahkan Config Validator ke pipeline CI/CD, Anda dapat menambahkan langkah ke alur kerja apa pun. Langkah ini memvalidasi rencana Terraform dan menolaknya jika ditemukan pelanggaran.

Persyaratan 1.2.5

Semua layanan, protokol, dan port yang diizinkan diidentifikasi, disetujui, dan memiliki kebutuhan bisnis yang ditentukan.

Untuk kontrol ingress yang kuat bagi cluster GKE, Anda dapat menggunakan jaringan yang diizinkan untuk membatasi rentang IP tertentu yang dapat menjangkau bidang kontrol cluster Anda. GKE menggunakan Transport Layer Security (TLS) dan autentikasi untuk menyediakan akses yang aman ke endpoint bidang kontrol cluster Anda dari internet publik. Akses ini memberi Anda fleksibilitas untuk mengelola cluster dari mana saja. Dengan menggunakan jaringan yang diizinkan, Anda dapat membatasi akses lebih lanjut ke kumpulan alamat IP tertentu.

Anda dapat menggunakan Cloud Armor untuk membuat daftar penolakan dan daftar izin IP serta kebijakan keamanan untuk aplikasi yang dihosting GKE. Di cluster GKE, traffic masuk ditangani oleh HTTP(S) Load Balancing, yang merupakan komponen Cloud Load Balancing. Biasanya, load balancer HTTP(S) dikonfigurasi oleh pengontrol ingress GKE, yang mendapatkan informasi konfigurasi dari objek Ingress Kubernetes. Untuk mengetahui informasi selengkapnya, lihat cara mengonfigurasi kebijakan Cloud Armor dengan GKE.

Persyaratan 1.3

Akses jaringan ke dan dari lingkungan data pemegang kartu dibatasi.

Untuk menjaga kerahasiaan data sensitif, Anda dapat mengonfigurasi komunikasi pribadi antara cluster GKE di dalam jaringan VPC dan deployment hybrid lokal dengan menggunakan Kontrol Layanan VPC dan Akses Google Pribadi.

Persyaratan 1.3.1

Pertimbangkan untuk menerapkan penyiapan Cloud NAT dengan GKE untuk membatasi traffic internet masuk hanya ke cluster tersebut. Anda dapat menyiapkan cluster pribadi untuk cluster yang tidak menghadap publik di CDE Anda. Dalam cluster pribadi, node hanya memiliki alamat IP RFC 1918 internal, yang memastikan bahwa beban kerjanya terpisah dari Internet publik.

Persyaratan 1.4

Koneksi jaringan antara jaringan tepercaya dan tidak tepercaya dikontrol.

Anda dapat memenuhi persyaratan ini menggunakan metode yang sama yang tercantum untuk Persyaratan 1.3.

Persyaratan 1.4.3

Tindakan anti-spoofing diterapkan untuk mendeteksi dan memblokir alamat IP sumber palsu agar tidak memasuki jaringan tepercaya.

Anda menerapkan langkah-langkah anti-spoofing dengan menggunakan alamat IP alias di pod dan cluster GKE untuk mendeteksi dan memblokir alamat IP sumber palsu agar tidak memasuki jaringan. Cluster yang menggunakan rentang IP alias disebut cluster VPC native.

Persyaratan 1.4.5

Pengungkapan alamat IP internal dan informasi perutean hanya terbatas pada pihak yang berwenang.

Anda dapat menggunakan agen penyamaran IP GKE untuk melakukan penafsiran alamat jaringan (NAT) untuk penafsiran alamat IP many-to-one di cluster. Penyamaran menyembunyikan beberapa alamat IP sumber di balik satu alamat.

Persyaratan 2

Terapkan konfigurasi yang aman ke semua komponen sistem.

Persyaratan 2 menentukan cara memperkuat parameter keamanan dengan menghapus kredensial default dan yang disediakan vendor. Memperkuat cluster Anda adalah tanggung jawab pelanggan.

Persyaratan 2.2

Persyaratan 2.2.4

Hanya layanan, protokol, daemon, dan fungsi yang diperlukan yang diaktifkan, dan semua fungsi yang tidak diperlukan dihapus atau dinonaktifkan.

Persyaratan 2.2.5

Persyaratan 2.2.6

Parameter keamanan sistem dikonfigurasi untuk mencegah penyalahgunaan.

Pra-deployment

Sebelum memindahkan penampung ke GKE, sebaiknya lakukan hal berikut:

• Mulai dengan image dasar terkelola container yang dibuat, dikelola, dan diperiksa kerentanannya oleh sumber tepercaya. Pertimbangkan untuk membuat serangkaian gambar dasar "berkualitas baik" atau "golden" yang dapat digunakan oleh developer Anda. Opsi yang lebih ketat adalah menggunakan image tanpa distro atau image dasar scratch.
• Gunakan Artifact Analysis untuk memindai kerentanan pada image container.
• Buat kebijakan DevOps/SecOps internal untuk menyertakan hanya library dan biner yang disetujui dan tepercaya ke dalam container.

Saat penyiapan

Selama penyiapan, sebaiknya lakukan hal berikut:

• Gunakan Container-Optimized OS default sebagai image node untuk GKE. Container-Optimized OS didasarkan pada Chromium OS dan dioptimalkan untuk keamanan node.
• Aktifkan upgrade otomatis node untuk cluster yang menjalankan aplikasi Anda. Fitur ini otomatis mengupgrade node ke versi Kubernetes yang berjalan di bidang kontrol terkelola, sehingga memberikan stabilitas dan keamanan yang lebih baik.
• Aktifkan perbaikan otomatis node. Jika fitur ini diaktifkan, GKE akan memeriksa dan menggunakan status respons node secara berkala untuk menentukan apakah node perlu diperbaiki. Jika node memerlukan perbaikan, node tersebut akan dikosongkan dan node baru akan dibuat serta ditambahkan ke cluster.
• Aktifkan Cloud Monitoring dan Cloud Logging untuk visibilitas semua peristiwa, termasuk peristiwa keamanan dan status kesehatan node. Buat kebijakan pemberitahuan Cloud Monitoring untuk mendapatkan notifikasi jika terjadi insiden keamanan.
• Menerapkan akun layanan dengan hak istimewa terendah untuk node GKE
• Tinjau dan terapkan (jika berlaku) bagian GKE dalam panduan Google Cloud CIS Benchmark. Logging audit Kubernetes sudah diaktifkan secara default, dan log untuk permintaan ke kubectl dan GKE API ditulis ke Cloud Audit Logs.
• Konfigurasi logging audit.

Melindungi data akun

Melindungi data pemegang kartu mencakup persyaratan 3 dan 4 PCI DSS.

Persyaratan 3

Melindungi data akun yang disimpan.

Persyaratan 3 PCI DSS menetapkan bahwa teknik perlindungan seperti enkripsi, pemotongan, penyamaran, dan hashing adalah komponen penting dari perlindungan data pemegang kartu. Jika penyusup mengakali kontrol keamanan lainnya dan mendapatkan akses ke data terenkripsi, tanpa kunci kriptografi yang tepat, data tersebut tidak dapat dibaca dan digunakan oleh orang tersebut.

Anda juga dapat mempertimbangkan metode lain untuk melindungi data tersimpan sebagai peluang mitigasi risiko potensial. Misalnya, metode untuk meminimalkan risiko mencakup tidak menyimpan data pemegang kartu kecuali benar-benar diperlukan, memangkas data pemegang kartu jika PAN lengkap tidak diperlukan, dan tidak mengirim PAN yang tidak dilindungi menggunakan teknologi pesan pengguna akhir, seperti email dan pesan instan.

Contoh sistem tempat CHD mungkin tetap ada sebagai bagian dari alur pemrosesan pembayaran Anda saat berjalan di Google Cloud adalah:

• Bucket Cloud Storage
• Instance BigQuery
• Datastore
• Cloud SQL

Perhatikan bahwa CHD mungkin tidak sengaja disimpan dalam log komunikasi layanan pelanggan atau email. Sebaiknya gunakan Sensitive Data Protection untuk memfilter aliran data ini sehingga Anda membatasi lingkungan dalam cakupan ke sistem pemrosesan pembayaran.

Perhatikan bahwa di Google Cloud, data dienkripsi dalam penyimpanan secara default, dan dienkripsi dalam pengiriman secara default saat melintasi batas fisik. Tidak diperlukan konfigurasi tambahan untuk mengaktifkan perlindungan ini.

Persyaratan 3.5

Nomor akun utama (PAN) diamankan di mana pun nomor tersebut disimpan.

Salah satu mekanisme untuk membuat data PAN tidak dapat dibaca adalah tokenisasi. Untuk mengetahui informasi selengkapnya, lihat panduan solusi tentang membuat token data pemegang kartu sensitif untuk PCI DSS.

Anda dapat menggunakan DLP API untuk memindai, menemukan, dan melaporkan data pemegang kartu. Sensitive Data Protection memiliki dukungan bawaan untuk memindai dan mengklasifikasikan data PAN 12–19 digit di Cloud Storage, BigQuery, dan Datastore. Platform ini juga memiliki API konten streaming untuk mengaktifkan dukungan bagi sumber data tambahan, beban kerja kustom, dan aplikasi. Anda juga dapat menggunakan DLP API untuk memangkas (menyamarkan) atau melakukan hashing data.

Persyaratan 3.6

Kunci kriptografi yang digunakan untuk melindungi data akun tersimpan diamankan.

Cloud Key Management Service (KMS) adalah sistem penyimpanan terkelola untuk kunci kriptografi. Layanan ini dapat membuat, menggunakan, merotasi, dan menghancurkan kunci kriptografi. Meskipun Cloud KMS tidak secara langsung menyimpan secret seperti data pemegang kartu, Cloud KMS dapat digunakan untuk mengenkripsi data tersebut.

Secret dalam konteks Kubernetes adalah objek secret Kubernetes yang memungkinkan Anda menyimpan dan mengelola informasi sensitif, seperti sandi, token, dan kunci.

Secara default, Google Cloud mengenkripsi konten pelanggan yang disimpan dalam penyimpanan. GKE menangani dan mengelola enkripsi default ini untuk Anda tanpa perlu tindakan tambahan. Enkripsi secret lapisan aplikasi memberikan lapisan keamanan tambahan untuk data sensitif seperti secret. Dengan menggunakan fungsionalitas ini, Anda dapat memberikan kunci yang Anda kelola di Cloud KMS, untuk mengenkripsi data pada lapisan aplikasi. Hal ini melindungi dari penyerang yang mendapatkan akses ke salinan instance penyimpanan konfigurasi Kubernetes cluster Anda.

Persyaratan 4

Lindungi data pemegang kartu dengan kriptografi yang kuat selama transmisi melalui jaringan publik terbuka.

Data dalam cakupan harus dienkripsi selama transmisi melalui jaringan yang mudah diakses oleh individu berbahaya, misalnya, jaringan publik.

Istio adalah mesh layanan open source yang ditambahkan secara transparan ke aplikasi terdistribusi yang sudah ada. Istio secara terukur mengelola autentikasi, otorisasi, dan enkripsi traffic antar-microservice. Ini adalah platform yang mencakup API yang memungkinkan Anda berintegrasi dengan platform logging, telemetri, atau sistem kebijakan apa pun. Set fitur Istio memungkinkan Anda menjalankan arsitektur microservice terdistribusi secara efisien dan menyediakan cara yang seragam untuk mengamankan, menghubungkan, dan memantau microservice.

Persyaratan 4.1

Proses dan mekanisme untuk melindungi data pemegang kartu dengan kriptografi yang kuat selama transmisi melalui jaringan publik terbuka ditentukan dan didokumentasikan.

Anda dapat menggunakan Istio untuk membuat jaringan layanan yang di-deploy—dengan load balancing, autentikasi layanan-ke-layanan, dan pemantauan. Anda juga dapat menggunakannya untuk menghadirkan komunikasi service-to-service yang aman dalam cluster—dengan autentikasi dan otorisasi berbasis identitas yang kuat berdasarkan TLS bersama. TLS Bersama (mTLS) adalah handshake TLS yang dilakukan dua kali, yang menetapkan tingkat kepercayaan yang sama di kedua arah (berbeda dengan kepercayaan klien-server satu arah).

Istio memungkinkan Anda men-deploy sertifikat TLS ke setiap pod GKE dalam aplikasi. Layanan yang berjalan di pod dapat menggunakan mTLS untuk mengidentifikasi identitas peer mereka secara kuat. Komunikasi antarlayanan di-tunneling melalui proxy Envoy sisi klien dan sisi server. Envoy menggunakan ID SPIFFE untuk membuat koneksi mTLS antar-layanan. Untuk mengetahui informasi tentang cara men-deploy Istio di GKE, lihat dokumentasi GKE. Untuk mengetahui informasi tentang versi TLS yang didukung, lihat referensi Pengelolaan Traffic Istio. Gunakan TLS versi 1.2 dan yang lebih baru.

Jika aplikasi Anda diekspos ke internet, gunakan Load Balancing HTTP(S) GKE dengan perutean ingress yang disetel untuk menggunakan HTTP(S). Load Balancing HTTP(S), yang dikonfigurasi oleh objek Ingress, mencakup fitur berikut:

• Konfigurasi fleksibel untuk layanan. Objek Ingress menentukan cara traffic mencapai layanan Anda dan cara traffic dirutekan ke aplikasi Anda. Selain itu, Ingress dapat menyediakan satu alamat IP untuk beberapa layanan di cluster Anda.
• Integrasi dengan Google Cloud layanan jaringan. Objek Ingress dapat mengonfigurasi fitur Google Cloud seperti Sertifikat SSL yang dikelola Google (beta), Cloud Armor, Cloud CDN, dan Identity-Aware Proxy.
• Dukungan untuk beberapa sertifikat TLS. Objek Ingress dapat menentukan penggunaan beberapa sertifikat TLS untuk penghentian permintaan.

Saat Anda membuat objek Ingress, pengontrol ingress GKE akan membuat load balancer HTTP(S) Cloud dan mengonfigurasinya sesuai dengan informasi di Ingress dan Layanan terkait.

Menjalankan program pengelolaan kerentanan

Mempertahankan program pengelolaan kerentanan mencakup persyaratan 5 dan 6 PCI DSS.

Persyaratan 5

Lindungi semua sistem dan jaringan dari software berbahaya.

Persyaratan 5 PCI DSS menetapkan bahwa software antivirus harus digunakan di semua sistem yang biasanya terpengaruh oleh malware untuk melindungi sistem dari ancaman software berbahaya saat ini dan yang terus berkembang—dan container tidak terkecuali.

Persyaratan 5.2

Software berbahaya (malware) dicegah, atau dideteksi dan ditangani.

Anda harus menerapkan program pengelolaan kerentanan untuk image container Anda.

Sebaiknya lakukan tindakan berikut:

• Periksa dan terapkan patch keamanan terbaru pada container secara rutin.
• Lakukan pemindaian kerentanan secara rutin terhadap aplikasi dan biner/library dalam container.
• Memindai gambar sebagai bagian dari pipeline build.
• Berlangganan ke layanan analisis kerentanan untuk menerima informasi kerentanan terbaru yang relevan dengan lingkungan dan library yang digunakan dalam container.

Google Cloud bekerja sama dengan berbagai penyedia solusi keamanan penampung untuk meningkatkan postur keamanan dalam deployment pelanggan. Google Cloud Sebaiknya manfaatkan solusi dan teknologi keamanan tervalidasi untuk meningkatkan kedalaman pertahanan di lingkungan GKE Anda. Untuk daftar partner keamanan yang divalidasi Google Cloudterbaru, lihat Partner Keamanan.

Persyaratan 5.2.2

Persyaratan 5.2.3

Ada banyak solusi yang tersedia untuk melakukan pemindaian malware, tetapi PCI DSS mengakui bahwa tidak semua sistem memiliki kemungkinan yang sama untuk rentan. Penjual biasanya menyatakan bahwa server Linux, mainframe, dan mesin serupa mereka tidak "umumnya terpengaruh oleh software berbahaya" dan oleh karena itu dikecualikan dari 5.2.2. Dalam hal ini, 5.2.3 berlaku, dan Anda harus menerapkan sistem untuk evaluasi ancaman berkala.

Perlu diingat bahwa aturan ini berlaku untuk node dan pod dalam cluster GKE.

Persyaratan 5.3

Mekanisme dan proses anti-malware aktif, dipelihara, dan dipantau.

Persyaratan 5.2, 5.3, dan 11.5 memerlukan pemindaian antivirus dan pemantauan integritas file (FIM) di host dalam cakupan. Sebaiknya terapkan solusi yang memungkinkan semua node dipindai oleh agen tepercaya dalam cluster atau yang memungkinkan setiap node memiliki pemindai yang melaporkan ke satu endpoint pengelolaan.

Untuk mengetahui informasi selengkapnya, lihat ringkasan keamanan untuk GKE, dan ringkasan keamanan untuk Container-Optimized OS.

Solusi umum untuk persyaratan antivirus dan FIM adalah mengamankan container Anda sehingga hanya folder tertentu yang diizinkan memiliki akses tulis. Untuk melakukannya, Anda menjalankan container sebagai pengguna non-root dan menggunakan izin sistem file untuk mencegah akses tulis ke semua direktori, kecuali direktori kerja dalam sistem file container. Melarang eskalasi akses untuk menghindari pengelakan aturan sistem file.

Persyaratan 6

Mengembangkan dan memelihara sistem dan software yang aman.

Persyaratan 6 PCI DSS menetapkan bahwa Anda harus membuat siklus proses pengembangan software yang kuat dengan keamanan yang diterapkan di setiap langkah pengembangan software.

Persyaratan 6.2

Software khusus dan kustom dikembangkan dengan aman.

Persyaratan 6.2.1

Anda dapat menggunakan Otorisasi Biner untuk membantu memastikan bahwa hanya container tepercaya yang di-deploy ke GKE. Jika Anda hanya ingin mengizinkan image yang disahkan oleh satu atau beberapa pengesah tertentu, Anda dapat mengonfigurasi Otorisasi Biner untuk menerapkan kebijakan dengan aturan yang mewajibkan pengesahan berdasarkan hasil pemindaian kerentanan. Anda juga dapat menulis kebijakan yang mewajibkan satu atau beberapa pihak tepercaya (disebut "pengesah") untuk menyetujui image sebelum image tersebut dapat di-deploy. Untuk pipeline deployment multi-tahap di mana image berkembang dari cluster pengembangan ke pengujian hingga produksi, Anda dapat menggunakan pengesah untuk memastikan bahwa semua proses yang diperlukan telah selesai sebelum software berpindah ke tahap berikutnya.

Pada waktu deployment, Otorisasi Biner menerapkan kebijakan Anda dengan memeriksa apakah image container telah lulus semua batasan yang diperlukan—termasuk bahwa semua pengesah yang diperlukan telah memverifikasi bahwa image siap untuk di-deploy. Jika gambar lulus, layanan akan mengizinkannya di-deploy. Jika tidak, deployment akan diblokir dan image tidak dapat di-deploy hingga mematuhi kebijakan.

Untuk mengetahui informasi selengkapnya tentang Otorisasi Biner, lihat Menyiapkan untuk GKE.

Dalam keadaan darurat, Anda dapat melewati kebijakan Otorisasi Biner menggunakan alur kerja akses darurat. Semua insiden akses darurat dicatat di Cloud Audit Logs.

GKE Sandbox mengurangi kebutuhan container untuk berinteraksi langsung dengan host, sehingga memperkecil permukaan serangan untuk kompromi host, dan membatasi pergerakan pelaku kejahatan.

Persyaratan 6.3

Kerentanan keamanan diidentifikasi dan ditangani.

Persyaratan 6.3.1

Keamanan di cloud adalah tanggung jawab bersama antara penyedia cloud dan pelanggan.

Di GKE, Google mengelola bidang kontrol, yang mencakup VM utama, server API, dan komponen lain yang berjalan di VM tersebut, serta database etcd. Hal ini mencakup upgrade dan patching, penskalaan, dan perbaikan, semuanya didukung oleh tujuan tingkat layanan (SLO). Untuk sistem operasi node, seperti Container-Optimized OS atau Ubuntu, GKE segera menyediakan patch apa pun untuk image ini. Jika Anda mengaktifkan upgrade otomatis, patch ini akan otomatis di-deploy. (Ini adalah lapisan dasar container Anda—tidak sama dengan sistem operasi yang berjalan di container Anda.)

Untuk mengetahui informasi selengkapnya tentang model tanggung jawab bersama GKE, lihat Menjelajahi keamanan container: model tanggung jawab bersama di GKE.

Google menyediakan beberapa layanan keamanan untuk membantu membangun keamanan ke dalam pipeline CI/CD Anda. Untuk mengidentifikasi kerentanan dalam image container, Anda dapat menggunakan Pemindaian Kerentanan Google Artifact Analysis. Saat image container dikirim ke Google Container Registry (GCR), pemindaian kerentanan secara otomatis memindai image untuk menemukan kerentanan dan eksposur yang diketahui dari sumber CVE yang diketahui. Kerentanan diberi tingkat keparahan (kritis, tinggi, sedang, rendah, dan minimal) berdasarkan skor CVSS.

Persyaratan 6.4

Aplikasi web yang menghadap publik dilindungi dari serangan.

Web Security Scanner memungkinkan Anda memindai aplikasi web App Engine, Compute Engine, dan GKE yang menghadap publik untuk menemukan kerentanan umum mulai dari pembuatan skrip lintas situs dan kesalahan konfigurasi hingga resource yang rentan. Pemindaian dapat dilakukan sesuai permintaan dan dijadwalkan dari Google Cloud console. Dengan menggunakan Security Scanner API, Anda dapat mengotomatiskan pemindaian sebagai bagian dari rangkaian pengujian keamanan di pipeline build aplikasi.

Menerapkan langkah-langkah kontrol akses yang kuat

Menerapkan langkah-langkah pengendalian akses yang kuat mencakup persyaratan 7, 8, dan 9 PCI DSS.

Persyaratan 7

Membatasi akses ke komponen sistem dan data pemegang kartu hanya untuk hal-hal yang perlu diketahui saja.

Persyaratan 7 berfokus pada hak istimewa terendah atau perlu diketahui. PCI DSS mendefinisikan hal ini sebagai pemberian akses ke data dalam jumlah paling sedikit dan pemberian hak istimewa paling sedikit yang diperlukan untuk melakukan tugas.

Persyaratan 7.2

Akses ke komponen dan data sistem ditentukan dan ditetapkan dengan tepat.

IAM dan kontrol akses berbasis peran (RBAC) Kubernetes bekerja sama untuk menyediakan kontrol akses terperinci ke lingkungan GKE Anda. IAM digunakan untuk mengelola akses dan izin pengguna ke Google Cloud resource di project CDE Anda. Di GKE, Anda juga dapat menggunakan IAM untuk mengelola akses dan tindakan yang dapat dilakukan pengguna dan akun layanan di cluster Anda, seperti membuat dan menghapus cluster.

RBAC Kubernetes memungkinkan Anda mengonfigurasi serangkaian izin terperinci yang menentukan cara Google Cloud pengguna, Google Cloud akun layanan, atau grup pengguna (Google Grup) tertentu berinteraksi dengan objek Kubernetes di cluster Anda, atau di namespace tertentu di cluster Anda. Contoh izin RBAC mencakup pengeditan penerapan atau configmap, penghapusan pod, atau melihat log dari pod. Anda memberikan izin IAM terbatas kepada pengguna atau layanan, seperti Google Kubernetes Engine Cluster Viewer atau peran kustom, lalu menerapkan RoleBinding RBAC Kubernetes sebagaimana mestinya.

Cloud Identity Aware Proxy (IAP) dapat diintegrasikan melalui ingress untuk GKE guna mengontrol akses tingkat aplikasi bagi karyawan atau orang yang memerlukan akses ke aplikasi PCI Anda.

Selain itu, Anda dapat menggunakan Kebijakan organisasi untuk membatasi API dan layanan yang tersedia dalam project.

Persyaratan 7.2.2

Selain memastikan pengguna dan akun layanan mematuhi prinsip hak istimewa terendah, container juga harus mematuhinya. Praktik terbaik saat menjalankan penampung adalah menjalankan proses dengan pengguna non-root. Anda dapat menerapkan praktik ini menggunakan pengontrol penerimaan PodSecurity.

PodSecurity adalah pengontrol penerimaan Kubernetes yang memungkinkan Anda menerapkan Standar Keamanan Pod ke Pod yang berjalan di cluster GKE. Standar Keamanan Pod adalah kebijakan keamanan yang telah ditetapkan sebelumnya dan mencakup kebutuhan keamanan Pod tingkat tinggi di Kubernetes. Kebijakan ini bervariasi, mulai dari yang sangat permisif hingga sangat ketat. PodSecurity menggantikan pengontrol penerimaan PodSecurityPolicy sebelumnya yang dihapus di Kubernetes v1.25. Petunjuk tersedia untuk bermigrasi dari PodSecurityPolicy ke pengontrol penerimaan PodSecurity.

Persyaratan 8

Mengidentifikasi pengguna dan mengautentikasi akses ke komponen sistem

Persyaratan 8 menyatakan bahwa ID unik harus ditetapkan untuk setiap orang yang memiliki akses ke sistem PCI dalam cakupan untuk memastikan bahwa setiap individu bertanggung jawab secara unik atas tindakannya.

Persyaratan 8.2

Identifikasi pengguna dan akun terkait untuk pengguna dan administrator dikelola secara ketat di seluruh siklus proses akun.

Persyaratan 8.2.1

Semua pengguna diberi ID unik sebelum akses ke komponen sistem atau data pemegang kartu diizinkan.

Persyaratan 8.2.5

Akses untuk pengguna yang dihentikan segera dicabut.

IAM dan RBAC Kubernetes dapat digunakan untuk mengontrol akses ke cluster GKE Anda, dan dalam kedua kasus tersebut, Anda dapat memberikan izin kepada pengguna. Sebaiknya pengguna dikaitkan kembali dengan sistem identitas yang ada, sehingga Anda dapat mengelola akun dan kebijakan pengguna di satu lokasi.

Persyaratan 8.3

Autentikasi yang kuat untuk pengguna dan administrator ditetapkan dan dikelola.

Persyaratan 8.3.1

Sertifikat terikat dengan identitas pengguna saat pengguna melakukan autentikasi ke kubectl. Semua cluster GKE dikonfigurasi untuk menerima identitas pengguna dan akun layanan Google Cloud , dengan memvalidasi kredensial dan mengambil alamat email yang terkait dengan identitas pengguna atau akun layanan. Oleh karena itu, kredensial untuk akun tersebut harus menyertakan cakupan OAuth userinfo.email agar berhasil mengautentikasi.

Persyaratan 9

Membatasi akses fisik ke data pemegang kartu.

Google bertanggung jawab atas kontrol keamanan fisik di semua pusat data Google yang mendasariGoogle Cloud.

Memantau dan menguji jaringan secara rutin

Memantau dan menguji jaringan secara rutin mencakup persyaratan 10 dan 11 PCI DSS.

Persyaratan 10

Mencatat dan memantau semua akses ke komponen sistem dan data pemegang kartu.

Persyaratan 10.2

Log audit diterapkan untuk mendukung deteksi anomali dan aktivitas yang mencurigakan, serta analisis forensik peristiwa.

Cluster Kubernetes memiliki logging audit Kubernetes diaktifkan secara default, yang menyimpan kumpulan data kronologis terkait panggilan yang dilakukan ke server Kubernetes API. Entri log audit Kubernetes berguna untuk menyelidiki permintaan API yang mencurigakan, mengumpulkan statistik, atau membuat pemberitahuan pemantauan terkait panggilan API yang tidak diinginkan.

Cluster GKE mengintegrasikan konfigurasi default untuk logging audit GKE dengan Cloud Audit Logs dan Logging. Anda dapat melihat entri log audit Kubernetes di Google Cloud project Anda.

Selain entri yang ditulis oleh Kubernetes, log audit project Anda memiliki entri yang ditulis oleh GKE.

Untuk membedakan workload CDE dan non-CDE, sebaiknya tambahkan label ke pod GKE yang akan meresap ke dalam metrik dan log yang dikeluarkan dari workload tersebut.

Persyaratan 10.2.2

Setiap entri log audit di Logging adalah objek berjenis LogEntry yang berisi kolom berikut:

• Payload, yang berjenis protoPayload. Payload setiap entri log audit adalah objek dengan jenis AuditLog. Anda dapat menemukan identitas pengguna di kolom AuthenticationInfo objek AuditLog.
• Peristiwa tertentu, yang dapat Anda temukan di kolom methodName dari AuditLog.
• Stempel waktu.
• Status acara, yang dapat Anda temukan di objek response dalam objek AuditLog.
• Permintaan operasi, yang dapat Anda temukan di objek request dan requestMetadata dalam objek AuditLog.
• Layanan yang akan dilakukan, yang dapat Anda temukan di objek AuditData dalam serviceData.

Persyaratan 11

Uji keamanan sistem dan jaringan secara rutin.

Persyaratan 11.3

Kerentanan eksternal dan internal diidentifikasi, diprioritaskan, dan ditangani secara rutin.

Persyaratan 11.3.1

Pemindaian kerentanan Artifact Analysis melakukan jenis pemindaian kerentanan berikut untuk image di Container Registry:

• Pemindaian awal. Saat Anda pertama kali mengaktifkan Artifact Analysis API, API ini akan memindai image Anda di Container Registry dan mengekstrak pengelola paket, dasar image, dan kemunculan kerentanan untuk image tersebut.

• Pemindaian inkremental. Artifact Analysis memindai image baru saat diupload ke Container Registry.

• Analisis berkelanjutan: Saat menerima informasi kerentanan baru dan yang diperbarui dari sumber kerentanan, Artifact Analysis akan menjalankan ulang analisis container untuk menyimpan daftar kemunculan kerentanan untuk gambar yang telah dipindai hingga date.

Persyaratan 11.5

Intrusi jaringan dan perubahan file yang tidak terduga terdeteksi dan ditangani.

Persyaratan 11.5.1

Google Cloud Duplikasi Paket dapat digunakan dengan Cloud IDS untuk mendeteksi penyusupan jaringan. Google Cloud Duplikasi paket meneruskan semua traffic jaringan dari VM atau cluster Compute Engine Anda ke alamat yang ditentukan. Google Cloud Cloud IDS dapat menggunakan traffic yang diduplikasi ini untuk mendeteksi berbagai ancaman, termasuk upaya eksploitasi, pemindaian port, buffer overflow, fragmentasi protokol, traffic perintah dan kontrol (C2), dan malware.

Security Command Center memberi Anda visibilitas terpusat ke status keamanan Google Cloud layanan (termasuk GKE) dan aset di seluruh organisasi Anda, sehingga memudahkan Anda mencegah, mendeteksi, dan merespons ancaman. Dengan Security Command Center, Anda dapat melihat kapan ancaman berisiko tinggi seperti malware, cryptomining, akses tidak sah ke resource, serangan DDoS keluar, pemindaian port, dan SSH brute force telah terdeteksi berdasarkan log Cloud Logging Anda. Google Cloud

Mempertahankan kebijakan keamanan informasi

Kebijakan keamanan yang kuat menetapkan nuansa keamanan dan memberi tahu orang-orang tentang apa yang diharapkan dari mereka. Dalam hal ini, "orang" mengacu pada karyawan penuh waktu dan paruh waktu, karyawan sementara, kontraktor, dan konsultan yang memiliki akses ke CDE Anda.

Persyaratan 12

Mendukung keamanan informasi dengan kebijakan dan program organisasi.

Untuk mengetahui informasi tentang persyaratan 12, lihat Google Cloud Matriks Tanggung Jawab Bersama PCI.

Pembersihan

Jika Anda menggunakan resource apa pun saat mengikuti artikel ini—misalnya, jika Anda memulai VM baru atau menggunakan skrip Terraform—Anda dapat menghindari tagihan pada akun Google Cloud Anda dengan menghapus project tempat Anda menggunakan resource tersebut.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Langkah berikutnya

• Pelajari lebih lanjut tentang kepatuhan Standar Keamanan Data PCI.
• Coba Terraform Starter Kit.
• Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.