Kepatuhan PCI DSS di GKE

Last reviewed 2023-10-31 UTC

Panduan ini dimaksudkan untuk membantu Anda mengatasi masalah khusus pada aplikasi Google Kubernetes Engine (GKE) saat menerapkan tanggung jawab pelanggan untuk persyaratan Standar Keamanan Data Industri Kartu Pembayaran (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 layanannya 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 pemegang kartu serta memfasilitasi penerapan yang luas terhadap langkah-langkah keamanan data yang konsisten secara global. PCI DSS memberikan 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, pengakuisisi, 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 banyak beban kerja lama yang bermigrasi dari arsitektur berbasis virtual machine (VM) ke arsitektur dalam 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 memindahkan 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:

  • Resource Organisasi, Folder, dan Project Google Cloud
  • Identity and Access Management (IAM)
  • Google Kubernetes Engine
  • VPC Google Cloud
  • 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 penampung dan GKE.

Cakupan

Panduan ini mengidentifikasi persyaratan berikut dari PCI DSS yang merupakan masalah unik untuk GKE dan memberikan panduan untuk memenuhinya. Kode ini ditulis berdasarkan standar versi 4.0. 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 ini bukan saran yang komprehensif. Organisasi dapat melibatkan Penilai Keamanan Berkualifikasi (QSA) PCI untuk validasi formal.

Sasaran PCI DSS Persyaratan PCI DSS
Menyegmentasikan lingkungan data pemegang kartu Terkadang disebut sebagai persyaratan 0. Meskipun tidak wajib untuk kepatuhan PCI, sebaiknya gunakan persyaratan ini agar cakupan PCI tetap terbatas.
Membuat dan mengelola jaringan dan sistem yang aman 1. Menginstal dan mengelola kontrol keamanan jaringan

2. Menerapkan konfigurasi aman ke semua komponen sistem
Melindungi data akun 3. Melindungi data akun yang disimpan

4. Melindungi data pemegang kartu dengan kriptografi yang kuat selama transmisi melalui jaringan publik terbuka
Memelihara program pengelolaan kerentanan 5. Melindungi semua sistem dan jaringan dari software berbahaya

6. Mengembangkan dan memelihara sistem dan software yang aman
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

8. Mengidentifikasi dan mengautentikasi akses ke komponen sistem

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

11. Menguji keamanan sistem dan jaringan secara rutin
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 hal berikut:

  • Nama pemegang kartu
  • Tanggal habis masa berlaku dan/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

primary account number. Bagian penting data pemegang kartu yang wajib Anda lindungi berdasarkan PCI DSS. PAN umumnya berupa nomor 16 digit yang unik untuk kartu pembayaran (kredit dan debit) dan mengidentifikasi penerbit serta 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

asesor 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 memberikan otorisasi transaksi. Serupa dengan data pemegang kartu, PCI DSS mewajibkan perlindungan SAD. Selain itu, SAD tidak dapat disimpan oleh penjual dan pemroses pembayaran mereka. SAD mencakup hal berikut:

  • Data "jalur" dari strip magnetik
  • "Data setara pelacakan" yang dihasilkan oleh kartu chip dan nirsentuh
  • Kode validasi keamanan (misalnya, angka 3-4 digit yang dicetak di kartu) yang digunakan untuk transaksi online dan transaksi tanpa kartu.
  • PIN dan pemblokiran PIN
segmentasi

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

  • Cakupan dan biaya penilaian PCI DSS
  • Biaya dan kesulitan dalam menerapkan serta mempertahankan 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

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 terdiri dari 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 masuk dalam cakupan 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, komponen tersebut tidak dapat 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 sedikit mungkin lokasi dengan menghilangkan data yang tidak perlu dan menggabungkan data yang diperlukan mungkin mengharuskan Anda untuk 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 lainnya untuk cluster dalam cakupan

Segmentasi logis menggunakan hierarki resource

Ada beberapa cara untuk mengisolasi CDE dalam struktur organisasi Anda menggunakan hierarki resource Google Cloud. Resource Google Cloud dikelola secara hierarkis. Resource Organisasi adalah node root dalam hierarki resource Google Cloud. Folder dan project termasuk dalam 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 yang 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 diisolasi pada level folder. Anda juga dapat menggunakan satu project untuk semua cluster dan aplikasi PCI dalam cakupan, atau membuat project dan cluster untuk setiap aplikasi PCI dalam cakupan dan menggunakannya untuk mengatur resource Google Cloud Anda. Apa pun kasusnya, sebaiknya Anda menyimpan workload dalam cakupan dan di luar cakupan di project yang berbeda.

Segmentasi jaringan menggunakan jaringan dan subnet VPC

Anda dapat menggunakan Virtual Private Cloud (VPC) dan subnet untuk menyediakan jaringan 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 virtual machine (VM) Compute Engine dan untuk layanan yang memanfaatkan instance VM, termasuk GKE. Untuk mengetahui detail selengkapnya, lihat ringkasan VPC dan lihat praktik terbaik dan arsitektur referensi.

Segmentasi tingkat layanan menggunakan Kontrol Layanan VPC dan Google Cloud Armor

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

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

Anda dapat menggunakan Google Cloud Armor untuk membuat daftar alamat IP guna mengizinkan atau menolak akses ke load balancer HTTP(S) di edge jaringan Google Cloud. Dengan memeriksa alamat IP sesegera mungkin ke 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.

Gambar 1. Mendapatkan segmentasi menggunakan Kontrol Layanan VPC.
Gambar 1. Mendapatkan segmentasi menggunakan Kontrol Layanan VPC

Membuat dan memelihara jaringan dan sistem yang aman

Membuat dan mengelola 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 penampung dan GKE berbeda dengan konsep jaringan untuk VM tradisional. Pod dapat menjangkau satu sama lain secara langsung, tanpa NAT, bahkan di seluruh node. Hal ini akan membuat 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.

Tata letak logis cluster Kubernetes yang aman.
Gambar 2. Tata letak logis cluster Kubernetes yang aman

Sebelum membahas setiap persyaratan dalam Persyaratan 1, sebaiknya tinjau konsep jaringan berikut sehubungan 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 kumpulan 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 secara otomatis oleh GKE 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 pivoting jaringan dan gerakan lateral di dalam cluster jika terjadi masalah keamanan pada pod. Untuk menggunakan kebijakan jaringan, Anda harus mengaktifkan fitur secara eksplisit saat membuat cluster GKE. Anda dapat mengaktifkannya di cluster yang ada, tetapi tindakan ini akan menyebabkan node cluster dimulai ulang. Perilaku defaultnya adalah semua komunikasi pod-to-pod selalu terbuka. Oleh karena itu, jika 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 sudah dilengkapi dengan namespace default, tetapi Anda dapat membuat beberapa namespace dalam cluster. Namespace secara logis terpisah 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 kebijakan jaringan digunakan. Untuk informasi selengkapnya tentang cara mengonfigurasi namespace, lihat postingan blog Praktik Terbaik Namespace.

Diagram berikut mengilustrasikan konsep sebelumnya sehubungan dengan satu sama lain dan komponen GKE lainnya seperti cluster, node, dan pod.

Kebijakan jaringan Kubernetes yang mengontrol traffic dalam cluster.
Gambar 3. Kebijakan jaringan Kubernetes yang mengontrol traffic dalam cluster

Persyaratan 1.1

Proses dan mekanisme untuk menginstal dan mengelola kontrol keamanan jaringan ditentukan dan dipahami.

Persyaratan 1.1.2

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

Pertama, seperti yang Anda lakukan dengan 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 resource Google Cloud apa pun 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 berfungsi secara paralel, dengan kemampuan pengguna yang secara efektif mewakili gabungan peran IAM dan RBAC yang ditetapkan kepada mereka:

  • 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 membenarkan semua pengguna dan izin IAM dan RBAC. Biasanya, saat QSA menguji kontrol, mereka 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. Aturan firewall melindungi node cluster ini.

Selanjutnya, Anda mengonfigurasi kebijakan jaringan untuk membatasi alur dan melindungi pod di cluster. Kebijakan jaringan Kubernetes 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. 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 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 pada Persyaratan 6.5.1.

Untuk memperlakukan konfigurasi jaringan dan infrastruktur sebagai kode, Anda perlu membuat pipeline continuous integration dan continuous delivery (CI/CD) sebagai bagian dari proses pengelolaan perubahan dan kontrol 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 konsisten dari 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 menyertakan 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 pelanggaran ditemukan.

Persyaratan 1.2.5

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

Untuk kontrol masuk yang kuat bagi cluster GKE, Anda dapat menggunakan jaringan yang diizinkan untuk membatasi rentang IP tertentu yang dapat menjangkau panel kontrol cluster. GKE menggunakan Transport Layer Security (TLS) dan autentikasi untuk menyediakan akses yang aman ke endpoint master 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 Google Cloud Armor untuk membuat daftar tolak dan daftar yang diizinkan IP serta kebijakan keamanan untuk aplikasi yang dihosting GKE. Di cluster GKE, traffic masuk ditangani oleh Load Balancing HTTP(S), yang merupakan komponen dari Cloud Load Balancing. Biasanya, load balancer HTTP(S) dikonfigurasi oleh pengontrol ingress GKE, yang mendapatkan informasi konfigurasi dari objek Ingress Kubernetes. Untuk informasi selengkapnya, lihat cara mengonfigurasi kebijakan Google 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

Traffic masuk ke CDE dibatasi sebagai berikut:

  • Hanya untuk traffic yang diperlukan.
  • Semua traffic lain ditolak secara khusus.

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 ditampilkan kepada publik di CDE. 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

Langkah anti-spoofing diterapkan untuk mendeteksi dan memblokir alamat IP sumber palsu agar tidak masuk ke jaringan tepercaya.

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

Persyaratan 1.4.5

Pengungkapan alamat IP internal dan informasi pemilihan rute hanya terbatas untuk 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 aman ke semua komponen sistem.

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

Persyaratan 2.2

Komponen sistem dikonfigurasi dan dikelola dengan aman.

Pastikan standar ini mengatasi semua kerentanan keamanan yang diketahui dan konsisten dengan standar hardening sistem yang diterima industri. Sumber standar hardening sistem yang diterima industri dapat mencakup, tetapi tidak terbatas pada:

Persyaratan 2.2.4

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

Persyaratan 2.2.5

Jika ada layanan, protokol, atau daemon yang tidak aman:
  • Justifikasi bisnis didokumentasikan.
  • Fitur keamanan tambahan didokumentasikan dan diimplementasikan untuk mengurangi risiko penggunaan layanan, protokol, atau daemon yang tidak aman.

Persyaratan 2.2.6

Parameter keamanan sistem dikonfigurasi untuk mencegah penyalahgunaan.

Pra-deployment

Sebelum memindahkan penampung ke GKE, sebaiknya lakukan hal berikut:

  • Mulailah dengan image dasar terkelola container yang dibuat, dikelola, dan diperiksa kerentanannya oleh sumber tepercaya. Pertimbangkan untuk membuat kumpulan image dasar "known good" atau "golden" yang dapat digunakan developer Anda. Opsi yang lebih ketat adalah menggunakan image distroless atau image dasar awal.
  • Gunakan Artifact Analysis untuk memindai kerentanan pada image container.
  • Tetapkan kebijakan DevOps/SecOps internal untuk hanya menyertakan library dan biner yang disetujui dan tepercaya ke dalam penampung.

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 node upgrade otomatis 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 node perbaikan otomatis. Jika fitur ini diaktifkan, GKE akan memeriksa dan menggunakan status kondisi node secara berkala untuk menentukan apakah node perlu diperbaiki. Jika node memerlukan perbaikan, node tersebut akan dikosongkan dan node baru akan dibuat dan ditambahkan ke cluster.
  • Aktifkan Cloud Monitoring dan Cloud Logging untuk visibilitas semua peristiwa, termasuk peristiwa keamanan dan status kondisi node. Buat kebijakan pemberitahuan Cloud Monitoring untuk mendapatkan notifikasi jika insiden keamanan terjadi.
  • Menerapkan akun layanan dengan hak istimewa terendah untuk node GKE
  • Tinjau dan terapkan (jika berlaku) bagian GKE dalam panduan Tolok Ukur CIS Google Cloud. Logging audit Kubernetes sudah diaktifkan secara default, dan log untuk permintaan ke kubectl dan GKE API ditulis ke Cloud Audit Logs.
  • Mengonfigurasi 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, masking, dan hashing adalah komponen penting dari perlindungan data pemegang kartu. Jika penyusup mengakali kontrol keamanan lainnya dan mendapatkan akses ke data terenkripsi, tanpa kunci kriptografis yang tepat, data tersebut tidak dapat dibaca dan tidak dapat digunakan oleh orang tersebut.

Anda juga dapat mempertimbangkan metode lain untuk melindungi data yang disimpan sebagai potensi peluang mitigasi risiko. Misalnya, metode untuk meminimalkan risiko mencakup tidak menyimpan data pemegang kartu kecuali jika benar-benar diperlukan, memotong 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 disimpan.

Tokenisasi adalah salah satu mekanisme untuk membuat data PAN tidak dapat dibaca. Untuk mempelajari tokenisasi lebih lanjut, lihat Membatasi cakupan kepatuhan untuk lingkungan PCI di Google Cloud.

Anda dapat menggunakan DLP API untuk memindai, menemukan, dan melaporkan data pemegang kartu. Sensitive Data Protection memiliki dukungan native 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, beban kerja kustom, dan aplikasi tambahan. Anda juga dapat menggunakan DLP API untuk memotong (menyamar) atau melakukan hashing data.

Persyaratan 3.6

Kunci kriptografis yang digunakan untuk melindungi data akun yang disimpan diamankan.

Cloud Key Management Service (KMS) adalah sistem penyimpanan terkelola untuk kunci kriptografis. Key ring dapat membuat, menggunakan, memutar, dan menghancurkan kunci kriptografi. Meskipun Cloud KMS tidak menyimpan secret secara langsung 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 tindakan tambahan dari Anda. Enkripsi secret lapisan aplikasi memberikan lapisan keamanan tambahan untuk data sensitif seperti secret. Dengan menggunakan fungsi ini, Anda dapat memberikan kunci yang Anda kelola di Cloud KMS, untuk mengenkripsi data di lapisan aplikasi. Tindakan ini melindungi dari penyerang yang mendapatkan akses ke salinan instance penyimpanan konfigurasi Kubernetes cluster Anda.

Secret lapisan aplikasi dengan GKE.
Gambar 4. Secret lapisan aplikasi dengan GKE

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 menambahkan lapisan secara transparan ke aplikasi terdistribusi yang ada. Istio mengelola autentikasi, otorisasi, dan enkripsi traffic antar-microservice secara skalabel. Ini adalah platform yang menyertakan API yang memungkinkan Anda berintegrasi ke dalam platform logging, telemetri, atau sistem kebijakan. Kumpulan 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 mendukung 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 (bukan kepercayaan klien-server satu arah).

Amankan komunikasi antarlayanan menggunakan Istio dan mTLS.
Gambar 5. Mengamankan komunikasi antarlayanan menggunakan Istio dan mTLS

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 dengan kuat. Komunikasi antarlayanan di-tunnel melalui proxy Envoy sisi klien dan sisi server. Envoy menggunakan ID SPIFFE untuk membuat koneksi mTLS antarlayanan. Untuk informasi tentang cara men-deploy Istio di GKE, lihat dokumentasi GKE. Dan untuk 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, menyertakan fitur berikut:

  • Konfigurasi fleksibel untuk layanan. Objek Ingress menentukan cara traffic mencapai layanan dan cara traffic dirutekan ke aplikasi Anda. Selain itu, Ingress dapat menyediakan satu alamat IP untuk beberapa layanan di cluster Anda.
  • Integrasi dengan layanan jaringan Google Cloud. Objek Ingress dapat mengonfigurasi fitur Google Cloud seperti Sertifikat SSL yang dikelola Google (beta), Google 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.

Memelihara 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 berkembang—dan penampung tidak terkecuali.

Persyaratan 5.2

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

Anda harus menerapkan program pengelolaan kerentanan untuk image container.

Sebaiknya lakukan tindakan berikut:

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

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

Persyaratan 5.2.2

Solusi anti-malware yang di-deploy:

  • Mendeteksi semua jenis malware yang diketahui.
  • Menghapus, memblokir, atau berisi semua jenis malware yang diketahui.

Persyaratan 5.2.3

Setiap komponen sistem yang tidak berisiko terkena malware dievaluasi secara berkala untuk menyertakan hal berikut:

  • Daftar terdokumentasi dari semua komponen sistem yang tidak berisiko terkena malware.
  • Identifikasi dan evaluasi ancaman malware yang berkembang untuk komponen sistem tersebut.
  • Konfirmasi apakah komponen sistem tersebut terus tidak memerlukan perlindungan anti-malware.

Ada banyak solusi yang tersedia untuk melakukan pemindaian malware, tetapi PCI DSS menyadari bahwa tidak semua sistem memiliki kemungkinan yang sama untuk rentan. Biasanya, penjual mendeklarasikan server Linux, mainframe, dan mesin serupa mereka sebagai tidak "biasanya terpengaruh oleh software berbahaya" sehingga dikecualikan dari 5.2.2. Dalam hal ini, 5.2.3 berlaku, dan Anda harus menerapkan sistem untuk mengevaluasi ancaman secara berkala.

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

Persyaratan 5.3

Mekanisme dan proses anti-malware aktif, dikelola, 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 setiap node memiliki pemindai yang melaporkan hingga satu endpoint pengelolaan.

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

Solusi umum untuk persyaratan antivirus dan FIM adalah mengunci penampung sehingga hanya folder tertentu yang diizinkan yang memiliki akses tulis. Untuk melakukannya, Anda menjalankan penampung sebagai pengguna non-root dan menggunakan izin sistem file untuk mencegah akses tulis ke semua, kecuali direktori yang berfungsi dalam sistem file penampung. Jangan izinkan 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 menetapkan siklus proses pengembangan software yang kuat dengan keamanan yang terintegrasi di setiap langkah pengembangan software.

Persyaratan 6.2

Software khusus dan kustom dikembangkan dengan aman.

Persyaratan 6.2.1

Software khusus dan kustom dikembangkan dengan aman, sebagai berikut:

  • Berdasarkan standar industri dan/atau praktik terbaik untuk pengembangan yang aman.
  • Sesuai dengan PCI DSS (misalnya, autentikasi dan logging yang aman).
  • Mengintegrasikan pertimbangan masalah keamanan informasi selama setiap tahap siklus proses pengembangan software.

Anda dapat menggunakan Otorisasi Biner untuk membantu memastikan bahwa hanya container tepercaya yang di-deploy ke GKE. Jika hanya ingin mengaktifkan image yang diotorisasi 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 "penanda tangan") untuk menyetujui image sebelum dapat di-deploy. Untuk pipeline deployment multi-tahap tempat gambar berkembang dari pengembangan ke pengujian ke cluster produksi, Anda dapat menggunakan pengautentikasi untuk memastikan bahwa semua proses yang diperlukan telah selesai sebelum software berpindah ke tahap berikutnya.

Pada waktu deployment, Binary Authorization menerapkan kebijakan Anda dengan memeriksa apakah image container telah lulus semua batasan yang diperlukan—termasuk bahwa semua pengautentikasi yang diperlukan telah memverifikasi bahwa image siap untuk di-deploy. Jika gambar lulus, layanan akan mengizinkan gambar tersebut di-deploy. Jika tidak, deployment akan diblokir dan image tidak dapat di-deploy hingga sesuai.

Menggunakan Otorisasi Biner untuk menerapkan kebijakan yang hanya memerlukan image tepercaya yang diterapkan ke cluster GKE.
Gambar 6. Menggunakan Otorisasi Biner untuk menerapkan kebijakan yang mewajibkan hanya image tepercaya yang diterapkan ke cluster GKE

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

Dalam keadaan darurat, Anda dapat mengabaikan 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

Kerentanan keamanan diidentifikasi dan dikelola sebagai berikut:

  • Kerentanan keamanan baru diidentifikasi menggunakan sumber yang diakui industri untuk informasi kerentanan keamanan, termasuk pemberitahuan dari tim respons darurat komputer (CERT) internasional dan nasional.
  • Kerentanan diberi peringkat risiko berdasarkan praktik terbaik industri dan pertimbangan potensi dampaknya.
  • Peringkat risiko mengidentifikasi, setidaknya, semua kerentanan yang dianggap berisiko tinggi atau penting bagi lingkungan.
  • Kerentanan untuk software pihak ketiga, kustom, dan khusus (misalnya sistem operasi dan database) tercakup.

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

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

Untuk 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 akan 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 ditampilkan kepada publik dilindungi dari serangan.

Web Security Scanner memungkinkan Anda memindai aplikasi web App Engine, Compute Engine, dan GKE yang ditampilkan secara 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 konsol Google Cloud. 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 kontrol akses yang kuat mencakup persyaratan 7, 8, dan 9 PCI DSS.

Persyaratan 7

Batasi 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 memberikan akses ke jumlah data yang paling sedikit dan memberikan hak istimewa terkecil yang diperlukan untuk melakukan tugas.

Persyaratan 7.2

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

Menggunakan IAM dan RBAC untuk memberikan lapisan keamanan.
Gambar 7. Menggunakan IAM dan RBAC untuk memberikan lapisan keamanan

IAM dan kontrol akses berbasis peran (RBAC) Kubernetes berfungsi bersama untuk memberikan kontrol akses yang sangat terperinci ke lingkungan GKE Anda. IAM digunakan untuk mengelola akses dan izin pengguna terhadap resource Google Cloud 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 kumpulan izin terperinci yang menentukan cara pengguna Google Cloud tertentu, akun layanan Google Cloud, atau grup pengguna (Google Grup) dapat berinteraksi dengan objek Kubernetes apa pun di cluster Anda, atau di namespace tertentu di cluster Anda. Contoh izin RBAC mencakup mengedit deployment atau configmap, menghapus 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 traffic masuk 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

Akses ditetapkan kepada pengguna, termasuk pengguna dengan hak istimewa, berdasarkan:

  • Klasifikasi dan fungsi pekerjaan.
  • Hak istimewa terendah yang diperlukan untuk melakukan tanggung jawab pekerjaan.

Selain memastikan pengguna dan akun layanan mematuhi prinsip hak istimewa terendah, penampung juga harus melakukannya. Praktik terbaik saat menjalankan penampung adalah menjalankan proses dengan pengguna non-root. Anda dapat menyelesaikan dan menerapkan praktek 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 memigrasikan dari PodSecurityPolicy ke pengontrol penerimaan PodSecurity.

Persyaratan 8

Mengidentifikasi pengguna dan mengautentikasi akses ke komponen sistem

Persyaratan 8 menentukan 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 selama 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 akan segera dicabut.

IAM dan RBAC Kubernetes dapat digunakan untuk mengontrol akses ke cluster GKE, dan dalam kedua kasus tersebut, Anda dapat memberikan izin ke pengguna. Sebaiknya pengguna terikat kembali ke 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 dibuat dan dikelola.

Persyaratan 8.3.1

Semua akses pengguna ke komponen sistem untuk pengguna dan administrator diautentikasi melalui setidaknya salah satu faktor autentikasi berikut:
  • Sesuatu yang Anda ketahui, seperti sandi atau frasa sandi.
  • Sesuatu yang Anda miliki, seperti perangkat token atau kartu pintar.
  • Sesuatu tentang Anda, seperti elemen biometrik.

Sertifikat terikat dengan identitas pengguna saat mereka mengautentikasi 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 mendasari Google Cloud.

Memantau dan menguji jaringan secara rutin

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

Persyaratan 10

Catat dan pantau 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 yang 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 project Google Cloud 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 masuk ke metrik dan log yang dikeluarkan dari workload tersebut.

Persyaratan 10.2.2

Log audit mencatat detail berikut untuk setiap peristiwa yang dapat diaudit:
  • Identifikasi pengguna
  • Jenis peristiwa
  • Tanggal dan waktu
  • Indikasi keberhasilan atau kegagalan
  • Asal peristiwa
  • Identitas atau nama data, komponen sistem, resource, atau layanan yang terpengaruh (misalnya, nama dan protokol)

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

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

Persyaratan 11

Uji keamanan sistem dan jaringan secara berkala.

Persyaratan 11.3

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

Persyaratan 11.3.1

Pemindaian kerentanan internal dilakukan sebagai berikut:
  • Minimal sekali setiap tiga bulan.
  • Kerentanan berisiko tinggi dan kritis (sesuai dengan peringkat risiko kerentanan entitas yang ditentukan pada Persyaratan 6.3.1) telah diatasi.
  • Pemindaian ulang dilakukan untuk mengonfirmasi bahwa semua kerentanan berisiko tinggi dan kritis (seperti yang disebutkan di atas) telah diperbaiki.
  • Alat pemindaian selalu diperbarui dengan informasi kerentanan terbaru.
  • Pemindaian dilakukan oleh personel yang berkualifikasi dan pengujian independen dari organisasi ada.

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

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

  • Pemindaian inkremental. Artifact Analysis akan 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 direspons.

Persyaratan 11.5.1

Teknik deteksi penyusupan dan/atau pencegahan penyusupan digunakan untuk mendeteksi dan/atau mencegah penyusupan ke jaringan sebagai berikut:
  • Semua traffic dipantau di perimeter CDE.
  • Semua traffic dipantau di titik kritis dalam CDE.
  • Personel diberi tahu tentang dugaan penyerbuan.
  • Semua mesin deteksi dan pencegahan intrusi, dasar pengukuran, dan tanda tangan selalu diupdate.

Duplikasi Paket Google Cloud dapat digunakan dengan Cloud IDS untuk mendeteksi penyusupan jaringan. Duplikasi paket Google Cloud meneruskan semua traffic jaringan dari VM Compute Engine atau cluster Google Cloud Anda ke alamat yang ditetapkan. 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 layanan Google Cloud (termasuk GKE) dan aset di seluruh organisasi Anda, yang mempermudah pencegahan, deteksi, dan respons terhadap ancaman. Dengan Security Command Center, Anda dapat melihat kapan ancaman berisiko tinggi seperti malware, cryptomining, akses tidak sah ke resource Google Cloud, serangan DDoS keluar, pemindaian port, dan SSH brute force telah terdeteksi berdasarkan log Cloud Logging Anda.

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 informasi tentang persyaratan 12, lihat Matriks Tanggung Jawab Bersama PCI Google Cloud.

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 ke 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