Kepatuhan PCI DSS di GKE

Last reviewed 2023-10-31 UTC

Panduan ini dimaksudkan untuk membantu Anda mengatasi masalah unik pada aplikasi Google Kubernetes Engine (GKE) saat Anda mengimplementasikan tanggung jawab pelanggan untuk persyaratan Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS).

Pernyataan penyangkalan: Panduan ini hanya untuk tujuan informasi. Google tidak bermaksud bahwa informasi atau rekomendasi dalam panduan ini sebagai saran hukum atau audit. Setiap pelanggan bertanggung jawab untuk mengevaluasi penggunaan khusus mereka sendiri atas layanan yang sesuai untuk mendukung kewajiban hukum dan kepatuhan mereka secara independen.

Pengantar kepatuhan PCI DSS dan GKE

Saat 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 adopsi luas 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 menjadi populer baru-baru ini dengan banyak workload lama yang bermigrasi dari arsitektur berbasis virtual machine (VM) ke dalam container. Google Kubernetes Engine adalah lingkungan terkelola dan siap produksi untuk men-deploy aplikasi dalam container. Platform ini menghadirkan inovasi terbaru Google dalam produktivitas developer, efisiensi resource, operasi otomatis, dan fleksibilitas open source untuk mempercepat waktu penyiapan produk.

Kepatuhan adalah tanggung jawab bersama di cloud. Google Cloud, termasuk GKE (mode operasi Autopilot dan Standar), 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 menggunakan GKE.
  • Developer, petugas keamanan, pejabat kepatuhan, admin IT, dan karyawan lain yang bertanggung jawab untuk menerapkan kontrol dan memastikan kepatuhan terhadap persyaratan PCI DSS.

Sebelum memulai

Untuk rekomendasi yang mengikutinya, Anda mungkin harus menggunakan hal berikut:

  • Resource Project, Folder, dan Organisasi 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 mereka yang sudah memahami container dan GKE.

Cakupan

Panduan ini mengidentifikasi persyaratan dari PCI DSS berikut yang merupakan masalah unik untuk GKE dan menyediakan panduan untuk memenuhinya. Versi ini ditulis berdasarkan standar versi 4.0. Panduan ini tidak mencakup semua persyaratan dalam PCI DSS. Informasi yang diberikan dalam panduan ini mungkin membantu organisasi dalam mencapai kepatuhan PCI DSS, tetapi bukan merupakan saran yang komprehensif. Organisasi dapat meminta Penilai Keamanan Berkualitas PCI (QSA) untuk mendapatkan validasi formal.

Sasaran PCI DSS Persyaratan PCI DSS
Menyegmentasikan lingkungan data pemegang kartu Terkadang disebut sebagai persyaratan 0. Meskipun bukan keharusan untuk kepatuhan terhadap PCI, kami merekomendasikan persyaratan ini untuk menjaga cakupan PCI tetap terbatas.
Membangun dan memelihara jaringan dan sistem yang aman 1. Menginstal dan mengelola kontrol keamanan jaringan

2. Terapkan konfigurasi yang aman ke semua komponen sistem
Lindungi data akun 3. Melindungi data akun yang tersimpan

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

6. Mengembangkan dan memelihara sistem dan software yang aman
Mengimplementasikan langkah-langkah kontrol akses yang kuat 7. Membatasi akses ke komponen sistem dan data pemegang kartu berdasarkan kebutuhan bisnis

8. Mengidentifikasi dan mengautentikasi akses ke komponen sistem

9. Membatasi akses fisik ke data pemegang kartu
Memantau dan menguji jaringan secara rutin 10. Membuat log dan memantau semua akses ke komponen sistem dan data pemegang kartu

11. Uji 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 detail selengkapnya, lihat glosarium PCI DSS.

PJB

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

  • 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

nomor akun utama. Bagian penting dari data pemegang kartu yang wajib Anda lindungi berdasarkan PCI DSS. PAN biasanya berupa nomor 16 digit yang unik untuk kartu pembayaran (kredit dan debit) serta 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.

UM (Uji Mutu)

penilai keamanan yang memenuhi syarat. Seseorang yang mendapatkan sertifikasi dari 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 membutuhkan perlindungan SAD. Selain itu, SAD tidak dapat dipertahankan oleh penjual dan pemroses pembayarannya. SAD mencakup hal-hal berikut:

  • Data "Lacak" dari setrip magnetik
  • "Melacak data yang setara" yang dibuat oleh chip dan kartu nirsentuh
  • Kode validasi keamanan (misalnya, nomor 3-4 digit yang tercetak di kartu) yang digunakan untuk transaksi online dan dengan kartu di luar kartu.
  • PIN dan blok PIN
segmentasi

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

  • Ruang lingkup dan biaya penilaian PCI DSS
  • Biaya dan kesulitan menerapkan dan memelihara kontrol PCI DSS
  • Risiko terhadap organisasi (dikurangi dengan menggabungkan data pemegang kartu menjadi lokasi yang lebih sedikit dan 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 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 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 sesedikit mungkin lokasi dengan menghilangkan data yang tidak diperlukan 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 hal-hal berikut:

  • Segmentasi logis dengan menggunakan hierarki resource
  • Segmentasi jaringan menggunakan VPC dan subnet
  • Segmentasi tingkat layanan menggunakan VPC
  • Pertimbangan lain untuk setiap 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. Mereka juga digunakan untuk mengelompokkan proyek 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 di level folder. Anda juga dapat menggunakan satu project untuk semua cluster dan aplikasi PCI dalam cakupan, atau Anda dapat membuat project dan cluster untuk setiap aplikasi PCI dalam cakupan dan menggunakannya untuk mengatur resource Google Cloud Anda. Dalam kasus apa pun, sebaiknya Anda mempertahankan beban kerja dalam ruang lingkup dan di luar ruang lingkup dalam berbagai project.

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 satu 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 serta baca arsitektur referensi dan praktik terbaik.

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 menambah perimeter keamanan di lapisan 7. Anda dapat menggunakan Kontrol Layanan VPC untuk membuat perimeter di sekeliling project CDE dalam cakupan. Kontrol Layanan VPC memberikan kontrol berikut:

  • Kontrol traffic masuk. Hanya identitas dan klien yang diotorisasi yang diizinkan masuk ke perimeter keamanan Anda.
  • Kontrol keluar. Hanya tujuan resmi yang diizinkan untuk identitas dan klien dalam perimeter keamanan Anda.

Anda dapat menggunakan Google Cloud Armor untuk membuat daftar alamat IP untuk mengizinkan atau menolak akses ke load balancer HTTP(S) Anda di edge jaringan Google Cloud. Dengan memeriksa alamat IP sedekat mungkin dengan pengguna dan traffic berbahaya, Anda membantu mencegah traffic berbahaya agar tidak memakai 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. Mencapai segmentasi menggunakan Kontrol Layanan VPC.
Gambar 1. Mencapai segmentasi menggunakan Kontrol Layanan 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 terhubung secara langsung, tanpa NAT, bahkan lintas node. Hal ini menghasilkan topologi jaringan sederhana yang mungkin mengejutkan jika Anda terbiasa mengelola sistem yang lebih kompleks. Langkah pertama dalam keamanan jaringan untuk GKE adalah mengedukasi diri Anda tentang konsep jaringan ini.

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

Sebelum mempelajari persyaratan individual dalam Persyaratan 1, sebaiknya Anda 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 dengan instance lainnya. Dalam jaringan, Anda dapat menggunakan tag untuk menerapkan aturan firewall ini ke setiap instance. Setiap kumpulan node menerima kumpulan tagnya sendiri yang dapat digunakan pada aturan. Secara default, setiap instance yang termasuk dalam node pool menerima tag yang mengidentifikasi cluster GKE spesifik yang menjadi bagian dari kumpulan node 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 kumpulan node menggunakan flag --tags di Google Cloud CLI.

  • Kebijakan jaringan. Kebijakan jaringan memungkinkan Anda membatasi koneksi jaringan antar-pod, yang dapat membantu membatasi perubahan posisi jaringan dan pergerakan lateral di dalam cluster jika terjadi masalah keamanan dengan 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 Anda dimulai ulang. Perilaku defaultnya adalah semua komunikasi pod ke pod selalu terbuka. Oleh karena itu, jika ingin mengelompokkan 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 level pod ini menentukan pod dan layanan mana yang dapat mengakses satu sama lain di dalam cluster Anda.

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

Diagram berikut mengilustrasikan konsep sebelumnya dalam kaitannya satu sama lain dan dengan 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 memelihara kontrol keamanan jaringan didefinisikan 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 Kubernetes (RBAC) sebagai bagian dari strategi otorisasi Kubernetes.

Pada dasarnya, semua konfigurasi IAM berlaku untuk semua resource Google Cloud dan semua cluster di dalam suatu project. Konfigurasi RBAC Kubernetes berlaku untuk resource di setiap cluster Kubernetes, dan memungkinkan otorisasi terperinci di level namespace. Dengan GKE, pendekatan untuk otorisasi ini bekerja secara paralel, dengan kemampuan pengguna yang secara efektif mewakili 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 Kubernetes RBAC 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 menjadi justifikasi untuk semua pengguna dan izin IAM dan RBAC. Biasanya, saat menguji kontrol, QSA mencari justifikasi bisnis untuk contoh IAM dan RBAC.

Persyaratan 1.2

{i>Network security controls<i} (NSC) dikonfigurasi dan dikelola.

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

Selanjutnya, Anda akan mengonfigurasi kebijakan jaringan untuk membatasi alur dan melindungi pod di cluster. Kebijakan jaringan adalah spesifikasi tentang cara grup pod diizinkan untuk berkomunikasi satu sama lain dan dengan endpoint jaringan lainnya. Anda dapat menggunakan penegakan kebijakan jaringan GKE untuk mengontrol komunikasi antara pod dan layanan cluster Anda. Untuk menyegmentasi cluster lebih lanjut, buat beberapa namespace di dalamnya. Namespace secara logis terpisah satu sama lain. Library ini 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 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 dalam namespace, semua traffic masuk dan keluar akan diizinkan ke dan dari pod dalam 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 ditetapkan pada Persyaratan 6.5.1.

Untuk memperlakukan konfigurasi dan infrastruktur jaringan Anda sebagai kode, Anda harus membuat pipeline continuous integration dan continuous delivery (CI/CD) sebagai bagian dari proses manajemen 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 lingkungan produksi saat ini atau lingkungan lainnya. Kemudian, Anda dapat menulis pengujian unit dan pengujian lainnya untuk memastikan perubahan jaringan berfungsi seperti yang diharapkan. Proses kontrol perubahan yang menyertakan persetujuan dapat dikelola melalui file konfigurasi yang disimpan di repositori versi.

Dengan Validator Config Terraform, 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 akan memvalidasi paket 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 mendapatkan 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 memberikan akses yang aman ke endpoint master cluster Anda dari internet publik. Akses ini memberi Anda fleksibilitas untuk mengelola cluster dari mana saja. Dengan jaringan yang diizinkan, Anda dapat lebih membatasi akses ke kumpulan alamat IP tertentu.

Anda dapat menggunakan Google Cloud Armor untuk membuat daftar tolak IP serta daftar izin dan kebijakan keamanan untuk aplikasi yang dihosting GKE. Di cluster GKE, traffic yang 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 mengetahui 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 menggunakan Kontrol Layanan VPC dan Akses Google Pribadi.

Persyaratan 1.3.1

Traffic masuk ke CDE dibatasi sebagai berikut:

  • Untuk traffic yang diperlukan saja.
  • Semua traffic lain ditolak secara khusus.

Pertimbangkan untuk menerapkan penyiapan Cloud NAT dengan GKE guna membatasi traffic internet masuk hanya ke cluster tersebut. Anda dapat menyiapkan cluster pribadi untuk cluster yang diakses oleh non-publik dalam 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 yang terpercaya dan tidak dapat dipercaya.

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 anti-spoofing dengan menggunakan alamat IP alias pada pod dan cluster GKE untuk mendeteksi dan memblokir alamat IP sumber palsu agar tidak memasuki jaringan. Cluster yang menggunakan rentang IP alias disebut cluster native VPC.

Persyaratan 1.4.5

Pengungkapan alamat IP internal dan informasi perutean dibatasi hanya untuk pihak yang diotorisasi.

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

Persyaratan 2

Terapkan konfigurasi yang aman ke semua komponen sistem.

Persyaratan 2 menentukan cara melakukan hardening parameter keamanan dengan menghapus default dan kredensial yang disediakan vendor. Melakukan hardening pada 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 diterapkan 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 container ke GKE, sebaiknya lakukan hal berikut:

  • Mulai dengan container image dasar terkelola yang dibangun, dikelola, dan diperiksa kerentanan oleh sumber tepercaya. Pertimbangkan untuk membuat kumpulan image dasar "baik yang terkenal" atau "emas" yang dapat digunakan developer. Opsi yang lebih ketat adalah menggunakan image tanpa distro atau image dasar awal.
  • Gunakan Artifact Analysis untuk memindai kerentanan pada image container Anda.
  • Tetapkan kebijakan DevOps/SecOps internal untuk hanya menyertakan library dan biner yang disetujui dan tepercaya ke dalam container.

Saat penyiapan

Selama penyiapan, sebaiknya lakukan tindakan 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 atau tidak. Jika node perlu diperbaiki, node tersebut akan dikosongkan dan node baru akan dibuat dan ditambahkan ke cluster.
  • Aktifkan Cloud Monitoring dan Cloud Logging untuk melihat semua peristiwa, termasuk peristiwa keamanan dan status kondisi 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 ada) bagian GKE di panduan Google Cloud CIS Benchmark. Logging audit Kubernetes sudah diaktifkan secara default, dan log untuk kedua permintaan ke kubectl dan GKE API akan ditulis ke Cloud Audit Logs.
  • Mengonfigurasi logging audit.

Lindungi data akun

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

Persyaratan 3

Melindungi data akun yang tersimpan.

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

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

Contoh sistem tempat CHD dapat dipertahankan sebagai bagian dari alur pemrosesan pembayaran Anda saat berjalan di Google Cloud adalah:

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

Perlu diketahui bahwa CHD mungkin tersimpan secara tidak sengaja dalam email atau log komunikasi layanan pelanggan. Sebaiknya gunakan Perlindungan Data Sensitif untuk memfilter aliran data ini agar Anda membatasi lingkungan dalam cakupan hanya untuk sistem pemrosesan pembayaran.

Perlu diperhatikan bahwa di Google Cloud, data dienkripsi dalam penyimpanan secara default, dan dienkripsi saat transit secara default saat melintasi batas fisik. Tidak ada konfigurasi tambahan yang diperlukan untuk mengaktifkan perlindungan ini.

Persyaratan 3.5

Nomor rekening utama (PAN) dilindungi di mana pun nomor ini disimpan.

Salah satu mekanisme untuk membuat data PAN tidak dapat dibaca adalah tokenisasi. Untuk mengetahui informasi selengkapnya, lihat panduan solusi tentang pembuatan 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 native untuk memindai dan mengklasifikasikan data PAN 12–19 digit di Cloud Storage, BigQuery, dan Datastore. API 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 memotong (menyamarkan) atau melakukan hashing pada data.

Persyaratan 3.6

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

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

Secret dalam konteks Kubernetes adalah objek rahasia Kubernetes yang dapat Anda gunakan untuk 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 dari Anda. Enkripsi secret lapisan aplikasi memberikan lapisan keamanan tambahan bagi data sensitif seperti secret. Dengan fungsi ini, Anda dapat menyediakan 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.

Rahasia lapisan aplikasi dengan GKE.
Gambar 4. Rahasia lapisan aplikasi dengan GKE

Persyaratan 4

Melindungi data pemegang kartu dengan kriptografi yang kuat selama transmisi melalui jaringan publik yang 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 melapisi secara transparan ke aplikasi terdistribusi yang sudah ada. Istio mengelola autentikasi, otorisasi, dan enkripsi traffic antar-layanan microservice secara skalabel. Ini adalah platform yang menyertakan API yang memungkinkan Anda berintegrasi ke dalam 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 antarlayanan, dan pemantauan. Anda juga dapat menggunakannya untuk memberikan komunikasi layanan-ke-layanan yang aman dalam cluster—dengan autentikasi dan otorisasi berbasis identitas yang kuat berdasarkan TLS bersama. TLS (mTLS) adalah handshake TLS yang dilakukan dua kali sehingga menetapkan tingkat kepercayaan yang sama di kedua arah (berlawanan dengan kepercayaan server klien satu arah).

Komunikasi antarlayanan yang aman menggunakan Istio dan mTLS.
Gambar 5. Komunikasi antarlayanan yang aman 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 pembanding mereka dengan kuat. Komunikasi layanan-ke-layanan disalurkan melalui proxy Envoy sisi klien dan sisi server. Envoy menggunakan ID SPIFFE untuk membuat koneksi mTLS antarlayanan. Untuk mengetahui informasi tentang cara men-deploy Istio di GKE, lihat dokumentasi GKE. Untuk mengetahui informasi tentang versi TLS yang didukung, baca referensi Pengelolaan Traffic Istio. Menggunakan TLS versi 1.2 dan yang lebih baru.

Jika aplikasi Anda terekspos 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 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 traffic masuk GKE akan membuat load balancer Cloud HTTP(S) dan mengonfigurasinya sesuai dengan informasi dalam Ingress dan Layanan terkaitnya.

Mempertahankan program manajemen kerentanan

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

Persyaratan 5

Melindungi 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—tidak terkecuali container.

Persyaratan 5.2

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

Anda harus mengimplementasikan program pengelolaan kerentanan untuk image container.

Sebaiknya lakukan tindakan berikut:

  • Periksa dan terapkan patch keamanan terbaru secara rutin pada container.
  • Lakukan pemindaian kerentanan secara rutin terhadap aplikasi dan biner/library dalam container.
  • Memindai image sebagai bagian dari pipeline build.
  • Berlangganan ke 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 tervalidasi untuk meningkatkan kedalaman pertahanan di lingkungan GKE Anda. Untuk mengetahui daftar partner keamanan terbaru yang divalidasi Google Cloud, lihat Partner Keamanan.

Persyaratan 5.2.2

Solusi anti-malware yang telah 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 malware akan dievaluasi secara berkala untuk menyertakan hal berikut:

  • Daftar terdokumentasi dari semua komponen sistem yang tidak berisiko terkena malware.
  • Identifikasi dan evaluasi ancaman malware yang terus 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 rentan. Penjual biasanya menyatakan server Linux, mainframe, dan mesin serupa mereka sebagai tidak "umumnya terpengaruh oleh software berbahaya" sehingga dikecualikan dari 5.2.2. Dalam hal ini, 5.2.3 berlaku, dan Anda harus mengimplementasikan sistem untuk evaluasi ancaman berkala.

Perlu diingat bahwa aturan ini berlaku untuk node dan pod di 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) pada host dalam cakupan apa pun. Sebaiknya terapkan solusi dengan semua node dapat dipindai oleh agen tepercaya dalam cluster atau saat setiap node memiliki pemindai yang melaporkan hingga 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 dengan mengunci container Anda sehingga hanya folder tertentu yang diizinkan yang memiliki akses tulis. Untuk melakukannya, jalankan container sebagai pengguna non-root dan gunakan izin sistem file untuk mencegah akses tulis ke semua direktori kecuali direktori yang berfungsi dalam sistem file container. Larang eskalasi akses untuk menghindari pengelakan aturan sistem file.

Persyaratan 6

Mengembangkan dan memelihara sistem dan software yang aman.

Persyaratan 6 PCI DSS menyatakan bahwa Anda menetapkan siklus proses pengembangan software yang kuat dengan keamanan bawaan pada setiap langkah pengembangan software.

Persyaratan 6.2

Software kustom dan kustom dikembangkan dengan aman.

Persyaratan 6.2.1

Software kustom 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).
  • Mempertimbangkan 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 diizinkan oleh satu atau beberapa attestor tertentu, Anda dapat mengonfigurasi Otorisasi Biner untuk menerapkan kebijakan dengan aturan yang memerlukan attestations berdasarkan hasil pemindaian kerentanan. Anda juga dapat menulis kebijakan yang mengharuskan satu atau beberapa pihak tepercaya (disebut "attestor") untuk menyetujui image sebelum dapat di-deploy. Untuk pipeline deployment multi-tahap dengan progres image dari pengembangan, pengujian, hingga cluster produksi, Anda dapat menggunakan attestor untuk memastikan bahwa semua proses yang diperlukan telah selesai sebelum software berpindah ke tahap berikutnya.

Pada waktu deployment, Otorisasi Biner memberlakukan kebijakan Anda dengan memeriksa bahwa image container telah melewati semua batasan yang diperlukan, termasuk bahwa semua attestor yang diperlukan telah memverifikasi bahwa image siap untuk deployment. Jika image lulus, layanan akan mengizinkannya untuk 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 hanya memerlukan image tepercaya yang diterapkan ke cluster GKE

Untuk informasi selengkapnya tentang Otorisasi Biner, lihat Menyiapkan 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 bagi container untuk berinteraksi langsung dengan host, menyingkat permukaan serangan untuk penyusupan host, dan membatasi pergerakan pihak berbahaya.

Persyaratan 6.3

Kerentanan keamanan diidentifikasi dan diatasi.

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 dampak.
  • Peringkat risiko mengidentifikasi, setidaknya, semua kerentanan yang dianggap berisiko tinggi atau penting bagi lingkungan.
  • Kerentanan untuk software kustom dan kustom, serta software pihak ketiga (misalnya sistem operasi dan database) juga 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 pada VM tersebut, serta database etcd. Hal ini termasuk 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 akan segera menyediakan patch apa pun ke image ini. Jika Anda mengaktifkan upgrade otomatis, patch ini akan otomatis di-deploy. (Ini adalah lapisan dasar container Anda. Ini tidak sama dengan sistem operasi yang berjalan di container Anda.)

Untuk mengetahui informasi selengkapnya tentang model tanggung jawab bersama GKE, lihat Mengeksplorasi 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 di image container, Anda dapat menggunakan Pemindaian Kerentanan Analisis Artefak Google. 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 dikenal. Kerentanan diberi tingkat keparahan (kritis, tinggi, sedang, rendah, dan minimal) berdasarkan skor CVSS.

Persyaratan 6.4

Aplikasi web yang ditampilkan ke publik dilindungi dari serangan.

Dengan Web Security Scanner, Anda dapat memindai aplikasi web App Engine, Compute Engine, dan GKE yang berhubungan secara publik untuk mendeteksi kerentanan umum, mulai dari pembuatan skrip lintas situs dan kesalahan konfigurasi hingga resource yang rentan. Pemindaian dapat dilakukan secara on demand dan dijadwalkan dari Google Cloud Console. Dengan 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 dari PCI DSS.

Persyaratan 7

Membatasi akses ke komponen sistem dan data pemegang kartu menurut kebutuhan bisnis.

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

Persyaratan 7.2

Akses ke komponen sistem dan data telah 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 Kubernetes role-based access control (RBAC) bekerja sama untuk menyediakan kontrol akses yang sangat terperinci ke lingkungan GKE Anda. IAM digunakan untuk mengelola akses pengguna dan izin 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 dalam cluster Anda, seperti membuat dan menghapus cluster.

Dengan Kubernetes RBAC, Anda dapat mengonfigurasi kumpulan izin terperinci yang menentukan cara pengguna Google Cloud, akun layanan Google Cloud, atau grup pengguna tertentu (Google Grup) dapat berinteraksi dengan objek Kubernetes apa pun di cluster Anda, atau di namespace tertentu di cluster Anda. Contoh izin RBAC termasuk mengedit deployment atau configmap, menghapus pod, atau melihat log dari pod. Anda memberi pengguna atau layanan izin IAM terbatas, seperti Google Kubernetes Engine Cluster Viewer atau peran khusus, 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 sebuah 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, container juga harus mematuhi prinsip hak istimewa terendah. Praktik terbaik saat menjalankan container adalah dengan menjalankan proses dengan pengguna non-root. Anda dapat menyelesaikan dan menerapkan praktik ini menggunakan pengontrol penerimaan PodSecurity.

PodSecurity adalah pengontrol penerimaan Kubernetes yang dapat digunakan untuk menerapkan Standar Keamanan Pod ke Pod yang berjalan di cluster GKE. Standar Keamanan Pod adalah kebijakan keamanan yang telah ditetapkan dan mencakup kebutuhan tingkat tinggi dari keamanan Pod di Kubernetes. Kebijakan ini bervariasi mulai dari yang sangat permisif hingga sangat ketat. PodSecurity menggantikan pengontrol penerimaan PodSecurityPolicy sebelumnya yang telah 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 diberikan kepada setiap orang yang memiliki akses ke sistem PCI dalam cakupan untuk memastikan bahwa setiap individu secara unik bertanggung jawab atas tindakannya.

Persyaratan 8.2

Identifikasi pengguna dan akun terkait untuk pengguna dan administrator dikelola secara ketat sepanjang siklus hidup 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 kepada pengguna. Sebaiknya pengguna 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 telah 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 smart.
  • Sesuatu tentang Anda, seperti elemen biometrik.

Sertifikat terikat dengan identitas pengguna saat 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 autentikasi berhasil.

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

Membuat log dan memantau semua akses ke komponen sistem dan data pemegang kartu.

Persyaratan 10.2

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

Cluster Kubernetes mengaktifkan logging audit Kubernetes secara default, yang menyimpan catatan kronologis panggilan yang telah 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 juga memiliki entri yang ditulis oleh GKE.

Untuk membedakan beban kerja 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

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 berjenis LogEntry yang berisi kolom berikut:

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

Persyaratan 11

Uji keamanan sistem dan jaringan secara teratur.

Persyaratan 11.3

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

Persyaratan 11.3.1

Pemindaian kerentanan internal dilakukan sebagai berikut:
  • Minimal tiga bulan sekali.
  • Kerentanan berisiko tinggi dan kritis (sesuai peringkat risiko kerentanan entitas yang ditentukan dalam Persyaratan 6.3.1) telah diselesaikan.
  • Pemindaian ulang dilakukan untuk mengonfirmasi bahwa semua kerentanan berisiko tinggi dan kritis (seperti disebutkan di atas) telah diatasi.
  • Alat pemindaian terus diupdate dengan informasi kerentanan terbaru.
  • Pemindaian dilakukan oleh personel yang berkualitas dan independensi organisasi penguji.

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, basis image, dan kekerentanan kejadian untuk image.

  • Pemindaian inkremental. Artifact Analysis memindai image baru ketika 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 akan terdeteksi dan ditanggapi.

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 sekeliling CDE.
  • Semua traffic dipantau di titik-titik penting di CDE.
  • Personel akan diberi tahu tentang dugaan kompromi.
  • Semua mesin deteksi penyusupan dan pencegahan, dasar pengukuran, dan tanda tangan akan selalu diperbarui.

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), serta malware.

Security Command Center memberi Anda visibilitas terpusat tentang status keamanan layanan dan aset Google Cloud (termasuk GKE) di seluruh organisasi Anda, sehingga mencegah, mendeteksi, dan merespons ancaman dengan lebih mudah. 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 apa yang diharapkan dari mereka. Dalam hal ini, "orang" mengacu pada karyawan purnawaktu 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 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 timbulnya biaya pada akun Google Cloud Anda dengan menghapus project tempat Anda menggunakan resource tersebut.

  1. Di konsol Google Cloud, buka halaman Manage resource.

    Buka Manage resource

  2. Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
  3. Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus project.

Langkah selanjutnya