Kepatuhan PCI DSS di GKE

Last reviewed 2023-10-31 UTC

Panduan ini dimaksudkan untuk membantu Anda mengatasi masalah khusus terkait Aplikasi Google Kubernetes Engine (GKE) saat Anda mengimplementasikan layanan pelanggan tanggung jawab untuk Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS) lainnya.

Pernyataan penyangkalan: Panduan ini hanya untuk tujuan informasi. Google tidak bermaksud menggunakan informasi atau rekomendasi dalam panduan ini untuk merupakan saran hukum atau audit. Setiap pelanggan bertanggung jawab untuk mengevaluasi penggunaan khusus mereka sendiri atas layanan yang sesuai 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 dari database lokal atau di cloud. PCI DSS dikembangkan untuk mendorong dan meningkatkan keamanan data pemegang kartu dan memfasilitasi langkah-langkah keamanan data secara global. PCI DSS memberikan dasar pengetahuan teknis dan persyaratan operasional yang dirancang untuk melindungi data kartu kredit. PCI DSS menerapkan kepada 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 {i>sensitive authentication data<i} (SAD) atau keduanya.

Aplikasi dalam container telah menjadi populer akhir-akhir ini dengan banyak workload 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. Teknologi ini menghadirkan inovasi terbaru Google dalam bidang produktivitas, efisiensi resource, operasi otomatis, dan open source fleksibilitas untuk mempercepat waktu penyiapan produk.

Kepatuhan adalah tanggung jawab bersama di cloud. Google Cloud, termasuk GKE (mode operasi Autopilot dan Standard), mematuhi persyaratan PCI DSS. Kami menguraikan tanggung jawab kita 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, kepatuhan petugas, administrator IT, dan karyawan lain yang bertanggung jawab untuk menerapkan kontrol dan memastikan kepatuhan terhadap persyaratan PCI DSS.

Sebelum memulai

Untuk rekomendasi berikut ini, Anda mungkin harus menggunakan berikut ini:

  • 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 mereka yang sudah memahami container dan hanya pada container yang tepercaya.

Cakupan

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

Tujuan PCI DSS Persyaratan PCI DSS
Segmentasikan pemegang kartu Anda lingkungan data Terkadang disebut sebagai persyaratan 0. Meskipun PCI tidak wajib melakukannya kepatuhan, kami merekomendasikan persyaratan ini untuk menjaga cakupan PCI tetap terbatas.
Membangun dan mengelola jaringan dan sistem yang aman 1. Menginstal dan mengelola kontrol keamanan jaringan

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

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

6. Mengembangkan dan memelihara sistem dan software yang aman
Menerapkan kontrol akses yang kuat tindakan 7. Membatasi akses ke komponen sistem dan data pemegang kartu oleh bisnis perlu mengetahui

8. Mengidentifikasi dan mengautentikasi akses ke komponen sistem

9. Membatasi akses fisik ke data pemegang kartu
Pantau dan uji secara teratur jaringan 10. Catat dan pantau semua akses ke komponen sistem dan data pemegang kartu

11. Uji keamanan sistem dan jaringan secara rutin
Menjaga keamanan informasi kebijakan 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 Minimal terdiri dari nomor rekening utama yang lengkap (PAN). Data pemegang kartu mungkin juga muncul dalam bentuk PAN lengkap plus salah satu dari yang 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 otentikasi sensitif.

PAN

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

PIN

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

QSA

penilai keamanan yang berkualifikasi. Seseorang yang telah mendapatkan sertifikasi dari PCI Security Standards Council untuk melakukan audit dan analisis kepatuhan.

SAD

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

  • "Lacak" data dari pita magnetik
  • "Lacak data yang setara" dibuat oleh chip dan kartu nirsentuh
  • Kode validasi keamanan (misalnya, nomor 3-4 digit yang tercetak pada kartu) yang digunakan untuk transaksi {i>online<i} dan {i>card-not-present<i}.
  • Blok PIN dan PIN
segmentasi

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

  • Ruang lingkup dan biaya penilaian PCI DSS
  • Biaya dan kesulitan menerapkan dan memelihara kontrol PCI DSS
  • Risiko bagi organisasi (dikurangi dengan menggabungkan data pemegang kartu ke 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 mentransmisikan data pemegang kartu atau informasi data otentikasi. Dalam konteks GKE, CDE juga terdiri dari berikut ini:

  • 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 mentransmisikan data pemegang kartu. Tanpa segmentasi yang memadai, seluruh jejak cloud Anda bisa masuk dalam ruang lingkup PCI DSS.

Agar dianggap berada di luar cakupan PCI DSS, komponen sistem harus diisolasi dari CDE sehingga meskipun komponen sistem di luar ruang lingkup disusupi, maka tidak akan mempengaruhi keamanan CDE.

Prasyarat penting untuk mengurangi ruang lingkup CDE adalah pemahaman kebutuhan bisnis dan proses yang terkait dengan penyimpanan, pemrosesan, dan transmisi data pemegang kartu. Membatasi data pemegang kartu ke lokasi sesedikit mungkin dengan menghilangkan data yang tidak perlu dan menggabungkan data yang diperlukan mungkin mengharuskan Anda untuk merekayasa ulang data praktik bisnis.

Anda dapat menyegmentasi CDE dengan tepat melalui berbagai cara di Google Cloud. Bagian ini membahas cara-cara berikut:

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

Segmentasi logis menggunakan hierarki resource

Ada beberapa cara untuk mengisolasi CDE dalam struktur organisasi Anda menggunakan paket data hierarki resource Anda. Resource Google Cloud dikelola secara hierarkis. Tujuan Organisasi resource adalah node root dalam hierarki resource Google Cloud. Folder dan project yang 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. Tabel sementara juga digunakan untuk mengelompokkan project serupa. J project adalah batas kepercayaan untuk semua resource Anda dan titik penerapan IAM.

Anda dapat mengelompokkan semua proyek yang berada dalam cakupan PCI dalam folder untuk terpisah di level folder. Anda juga dapat menggunakan satu project untuk semua cluster dan aplikasi PCI dalam ruang lingkup, atau Anda dapat membuat proyek dan {i>cluster <i}untuk setiap aplikasi PCI dalam-cakupan dan menggunakannya untuk mengatur akses terperinci ke resource Google Cloud tertentu. Dalam kasus apa pun, sebaiknya tetap dalam ruang lingkup dan di luar ruang lingkup dalam berbagai proyek.

Segmentasi jaringan menggunakan subnet dan jaringan VPC

Anda dapat menggunakan Virtual Private Cloud (VPC) dan subnet untuk menyediakan jaringan Anda dan mengisolasi resource terkait CDE. VPC adalah isolasi logis dari bagian dari {i>public cloud<i}. Jaringan VPC menyediakan layanan jaringan yang fleksibel untuk instance virtual machine (VM) Compute Engine dan untuk layanan yang memanfaatkan instance VM, termasuk GKE. Sebagai detail selengkapnya, lihat Ringkasan VPC dan lihat arsitektur referensi dan praktik terbaik.

Segmentasi tingkat layanan menggunakan Kontrol Layanan VPC dan Google Cloud Armor

Sementara VPC dan subnet menyediakan segmentasi dan membuat perimeter untuk mengisolasi CDE, Kontrol Layanan VPC meningkatkan perimeter keamanan di lapisan 7. Anda dapat menggunakan Kontrol Layanan VPC untuk membuat perimeter di sekeliling proyek CDE dalam ruang lingkup Anda. Kontrol Layanan VPC memberi Anda kontrol berikut:

  • Kontrol traffic masuk. Hanya identitas dan klien resmi yang diizinkan ke dalam perimeter keamanan Anda.
  • Kontrol traffic 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 guna mengizinkan atau menolak akses ke Load balancer HTTP(S) di seluruh jaringan Google Cloud. Dengan memeriksa alamat IP sebagai sedekat mungkin dengan pengguna dan lalu lintas yang berbahaya, Anda membantu mencegah traffic berbahaya dari mengonsumsi resource atau memasuki jaringan VPC Anda.

Gunakan Kontrol Layanan VPC untuk menentukan perimeter layanan di sekeliling dalam cakupan project secara terprogram. 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

Bangun dan kelola jaringan dan sistem yang aman

Membangun dan memelihara jaringan yang aman meliputi persyaratan 1 dan 2 dari seperti 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 untuk VM tradisional. Pod dapat terhubung satu sama lain secara langsung, tanpa NAT, bahkan lintas node. Hal ini menciptakan topologi jaringan sederhana yang mungkin mengejutkan jika Anda digunakan untuk mengelola sistem yang lebih kompleks. Langkah pertama dalam keamanan jaringan untuk GKE adalah cara untuk mendidik diri sendiri tentang konsep-konsep jaringan ini.

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

Sebelum masuk ke persyaratan individual berdasarkan Persyaratan 1, Anda mungkin ingin untuk meninjau konsep jaringan berikut sehubungan dengan GKE:

  • Aturan firewall. Aturan firewall digunakan untuk membatasi lalu lintas ke {i>node<i} Anda. Node GKE kemudian disediakan sebagai instance Compute Engine dan menggunakan firewall yang sama yang sama dengan instance lainnya. Dalam jaringan, Anda dapat menggunakan tag untuk menerapkan aturan {i> firewall<i} ini ke setiap instance. Setiap kumpulan node menerima sekumpulan tag yang dapat digunakan dalam aturan. Secara default, setiap instance yang ke node pool menerima tag yang mengidentifikasi GKE cluster yang merupakan bagian dari kumpulan node ini. Tag ini digunakan di firewall aturan yang dibuat GKE secara otomatis untuk Anda. Anda dapat menambahkan tag kustom pada waktu pembuatan cluster atau kumpulan node dengan menggunakan --tags di Google Cloud CLI.

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

  • Namespaces. Namespace memungkinkan segmentasi resource di dalam cluster Kubernetes Anda. Kubernetes memiliki namespace {i>default<i} yang siap digunakan, tetapi Anda dapat membuat beberapa namespace dalam cluster Anda. Namespace secara logis diisolasi dari masing-masing lainnya. Keduanya memberikan cakupan untuk pod, service, dan deployment di 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-namespace; di sinilah kebijakan jaringan masuk. Untuk informasi selengkapnya tentang cara mengonfigurasi namespace, lihat Praktik Terbaik Namespace postingan blog kita.

Diagram berikut mengilustrasikan konsep sebelumnya dalam kaitannya dengan masing-masing komponen GKE lainnya dan komponen GKE lainnya seperti cluster, node, dan pod.

Kebijakan jaringan Kubernetes yang mengontrol traffic dalam .
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 kelompok, peran, dan tanggung jawab untuk mengelola komponen jaringan.

Pertama, seperti yang Anda lakukan dengan sebagian besar layanan di Google Cloud, Anda perlu atur IAM peran untuk menyiapkan otorisasi di GKE. Setelah Anda menyiapkan peran IAM, Anda perlu menambahkan 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 klaster dalam sebuah proyek. Konfigurasi RBAC Kubernetes berlaku untuk resource di setiap cluster Kubernetes, dan memungkinkan otorisasi terperinci di pada level namespace. Dengan GKE, pendekatan otorisasi bekerja secara paralel, dengan kemampuan pengguna yang secara efektif mewakili Peran IAM dan RBAC yang ditetapkan ke mereka:

  • Menggunakan IAM untuk mengontrol grup, peran, dan tanggung jawab untuk pengelolaan logis dari 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 tidak sah atau tidak disengaja dari pengguna non-CDE.
  • Dapat memberikan justifikasi untuk semua pengguna dan izin IAM dan RBAC. Biasanya, ketika QSA menguji kontrol, mereka mencari bisnis justifikasi untuk contoh IAM dan RBAC.

Persyaratan 1.2

Kontrol keamanan jaringan (NSC) dikonfigurasi dan dikelola.

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

Selanjutnya, Anda mengonfigurasi kebijakan jaringan untuk membatasi flow dan melindungi pod di cluster. J kebijakan jaringan adalah spesifikasi mengenai bagaimana grup pod diizinkan untuk berkomunikasi dengan satu sama lain dan dengan endpoint jaringan lain. Anda dapat menggunakan jaringan GKE penegakan kebijakan untuk mengontrol komunikasi antara pod cluster dan layanan IT perusahaan mereka. Untuk menyegmentasi cluster lebih lanjut, buat beberapa namespace di dalamnya. Namespace secara logis terpisah satu sama lain. {i>Sprint<i} memberikan ruang lingkup untuk pod, layanan, dan deployment di cluster, sehingga pengguna berinteraksi dengan satu tidak akan melihat konten dalam namespace lain. Namun, namespace dalam cluster yang sama tidak membatasi komunikasi antar-namespace; di sinilah tempat kebijakan jaringan. Namespace memungkinkan segmentasi resource di dalam Kubernetes. Untuk informasi selengkapnya tentang cara mengonfigurasi namespace, lihat Praktik Terbaik Namespace postingan blog kita.

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

Persyaratan 1.2.2

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

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

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

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

Persyaratan 1.2.5

Semua layanan, protokol, dan porta yang diizinkan adalah diidentifikasi, disetujui, dan memiliki bisnis yang sudah ditentukan butuhkan.

Untuk kontrol masuk yang kuat bagi cluster GKE, Anda dapat menggunakan jaringan resmi untuk membatasi rentang IP tertentu yang bisa menjangkau bidang kontrol. GKE menggunakan Transport Layer Security (TLS) dan juga autentikasi untuk memberikan akses aman ke endpoint master cluster dari internet publik. Akses ini memberi Anda fleksibilitas untuk mengelola {i>cluster <i}dari mana saja. Dengan menggunakan jaringan yang diizinkan, Anda dapat membatasi lebih jauh akses ke kumpulan alamat IP tertentu.

Anda dapat menggunakan Google Cloud Armor membuat daftar IP yang ditolak dan daftar yang diizinkan serta kebijakan keamanan untuk Aplikasi yang dihosting GKE. Dalam cluster GKE, lalu lintas masuk ditangani oleh Load Balancing HTTP(S), yang merupakan komponen dari Cloud Load Balancing. Biasanya, load balancer HTTP(S) dikonfigurasi oleh Pengontrol masuk GKE, yang mengambil informasi konfigurasi dari Traffic masuk . 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 privasi data sensitif, Anda dapat mengonfigurasi komunikasi pribadi antara Cluster GKE di dalam jaringan VPC dan hybrid lokal deployment 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 secara khusus ditolak.

Pertimbangkan untuk menerapkan Penyiapan Cloud NAT dengan GKE untuk membatasi traffic internet masuk hanya ke cluster tersebut. Anda dapat menyiapkan cluster pribadi untuk klaster 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 tepercaya dan tidak tepercaya dikontrol.

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

Persyaratan 1.4.3

Langkah anti-spoofing diterapkan untuk mendeteksi dan memblokir alamat IP sumber palsu dari memasuki jaringan terpercaya.

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

Persyaratan 1.4.5

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

Anda dapat menggunakan Agen penyamaran IP GKE melakukan penafsiran alamat jaringan (NAT) untuk penerjemahan alamat IP many-to-one pada cluster. Menyamarkan beberapa alamat IP sumber di belakang satu alamat IP alamat IPv6

Persyaratan 2

Terapkan konfigurasi aman ke semua komponen sistem.

Persyaratan 2 menentukan cara memperkuat keamanan parameter dengan menghapus {i>default<i} dan kredensial yang diberikan vendor. Memperkuat cluster Anda merupakan tanggung jawab pelanggan.

Persyaratan 2.2

Komponen sistem dikonfigurasi dan dikelola dengan aman.

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

Persyaratan 2.2.4

Hanya layanan, protokol, {i>daemon<i} yang diperlukan, dan fungsi diaktifkan, dan semua fungsi yang tidak diperlukan fungsinya dihapus atau dinonaktifkan.

Persyaratan 2.2.5

Jika ada layanan, protokol, atau data yang tidak aman ada {i>daemon<i}:
  • Justifikasi bisnis didokumentasikan.
  • Fitur keamanan tambahan didokumentasikan dan yang mengurangi risiko penggunaan layanan, protokol, atau {i>daemon<i} yang tidak aman.

Persyaratan 2.2.6

Parameter keamanan sistem dikonfigurasi untuk mencegah penyalahgunaan.

Pra-deployment

Sebelum Anda memindahkan container ke GKE, kami merekomendasikan berikut ini:

  • Memulai dengan container image dasar terkelola yang dibuat, dikelola, dan diperiksa kerentanannya oleh sumber terpercaya. Pertimbangkan untuk membuat kumpulan "item yang diketahui" atau "emas" image dasar yang yang dapat digunakan oleh developer. Opsi yang lebih membatasi adalah menggunakan gambar tanpa gangguan atau gambar dasar awal.
  • Gunakan Analisis Artefak untuk memindai image container untuk mencari kerentanan.
  • Menetapkan kebijakan DevOps/SecOps internal untuk hanya menyertakan, library dan biner tepercaya ke dalam container.

Saat penyiapan

Selama penyiapan, sebaiknya:

Melindungi 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, penyamaran, dan {i>hashing <i}adalah 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 tidak dapat dibaca dan tidak dapat digunakan oleh orang tersebut.

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

Contoh sistem yang mungkin mempertahankan CHD sebagai bagian dari pemrosesan pembayaran Anda alur saat berjalan di Google Cloud adalah:

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

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

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

Persyaratan 3.5

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

Salah satu mekanisme untuk membuat data PAN tidak dapat dibaca adalah tokenisasi. Untuk mempelajari lebih lanjut tentang tokenisasi, 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 mendukung pemindaian dan klasifikasi 12-19 digit data PAN pada Cloud Storage, BigQuery, dan Datastore. API ini juga memiliki API konten streaming guna mengaktifkan dukungan untuk data tambahan seperti sumber, workload kustom, dan aplikasi. Anda juga dapat menggunakan DLP API ke memotong (menyamarkan) atau melakukan hash yang mengupload data.

Persyaratan 3.6

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

Cloud Key Management Service (KMS) adalah sistem penyimpanan terkelola untuk kunci kriptografis. AI dapat menghasilkan, menggunakan, merotasi, dan menghancurkan kunci kriptografi. Meskipun Cloud KMS tidak secara langsung rahasia toko seperti data pemegang kartu, maka dapat digunakan untuk mengenkripsi data tersebut.

Rahasia dalam konteks Kubernetes adalah Kubernetes objek secret yang memungkinkan Anda menyimpan dan mengelola informasi sensitif, seperti {i>password<i}, 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 apa pun dari Anda. Enkripsi rahasia 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, mengenkripsi data di lapisan aplikasi. Hal ini melindungi dari penyerang yang mendapatkan akses ke salinan instance penyimpanan konfigurasi Kubernetes dari .

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

Persyaratan 4

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

Data dalam ruang lingkup harus dienkripsi selama transmisi melalui jaringan yang mudah diakses oleh individu jahat, misalnya, jaringan publik.

Istio adalah jaring layanan open source yang melapisinya secara transparan ke bagian yang ada aplikasi terdistribusi. Istio mengelola autentikasi, otorisasi, dan enkripsi traffic antar microservice. Ini adalah platform yang mencakup API yang memungkinkan Anda berintegrasi ke dalam setiap platform logging, telemetri, atau kebijakan sistem file. Dengan set fitur Istio, Anda dapat menjalankan microservice yang terdistribusi secara efisien dan menyediakan cara yang seragam untuk mengamankan, menghubungkan, dan memantau microservice dalam container.

Persyaratan 4.1

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

Anda dapat menggunakan Istio untuk membuat jaringan layanan yang di-deploy—dengan load balancing, otentikasi, dan pemantauan layanan-ke-layanan. Anda juga dapat menggunakannya untuk memberikan komunikasi antarlayanan yang aman di cluster—dengan otentikasi dan otorisasi berbasis identitas berdasarkan TLS bersama. TLS Bersama (mTLS) adalah TLS handshake yang dilakukan dua kali, menetapkan tingkat kepercayaan di kedua arah (bukan kepercayaan klien-server 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 pada pod dapat menggunakan mTLS untuk secara ketat mengidentifikasi identitas rekan sejawat mereka. Komunikasi antarlayanan disalurkan melalui sisi klien dan sisi server Envoy menggunakan {i>proxy<i}. Envoy menggunakan SPIFFE ID ke membuat koneksi mTLS di antara layanan. Untuk informasi tentang cara men-deploy Istio di GKE, lihat dokumentasi GKE. Dan untuk informasi tentang versi TLS yang didukung, lihat Istio Referensi Pengelolaan Traffic. Gunakan TLS versi 1.2 dan yang lebih baru.

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

  • Konfigurasi layanan yang fleksibel. Objek Ingress mendefinisikan bagaimana traffic mencapai layanan Anda dan cara traffic dirutekan ke aplikasi. Selain itu, Ingress dapat menyediakan satu alamat IP untuk 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 meminta penghentian.

Saat Anda membuat objek Ingress, Pengontrol masuk GKE membuat Load balancer Cloud HTTP(S) dan mengonfigurasinya sesuai dengan informasi dalam Ingress dan Layanan.

Memelihara program pengelolaan kerentanan

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

Persyaratan 5

Melindungi semua sistem dan jaringan dari software berbahaya.

Persyaratan 5 PCI DSS menetapkan bahwa perangkat lunak antivirus harus digunakan semua sistem yang biasanya terpengaruh oleh {i>malware <i}untuk melindungi sistem dari serangan ancaman software berbahaya yang terus berkembang, termasuk 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 pada container secara rutin.
  • Lakukan secara rutin pemindaian kerentanan terhadap aplikasi dan biner/library dalam container.
  • Memindai image sebagai bagian dari pipeline build.
  • Berlangganan layanan kecerdasan kerentanan untuk menerima informasi kerentanan terkini yang relevan dengan lingkungan dan library yang digunakan dalam container tersebut.

Google Cloud bekerja sama dengan berbagai penyedia solusi keamanan container untuk meningkatkan postur keamanan dalam deployment Google Cloud. Rab merekomendasikan pemanfaatan solusi dan teknologi keamanan yang tervalidasi untuk meningkatkan yang lebih mendalam di lingkungan GKE Anda. Untuk info terbaru Untuk daftar partner keamanan tervalidasi 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 {i>malware<i}.

Persyaratan 5.2.3

Setiap komponen sistem yang tidak berisiko untuk {i>malware <i}dievaluasi secara berkala untuk memasukkan berikut ini:

  • Daftar terdokumentasi dari semua komponen sistem yang tidak berisiko terkena {i>malware<i}.
  • Identifikasi dan evaluasi perkembangan ancaman {i>malware <i}untuk komponen sistem tersebut.
  • Konfirmasi apakah komponen sistem tersebut tetap tidak memerlukan perlindungan anti-{i>malware<i}.

Ada banyak solusi yang tersedia untuk melakukan pemindaian {i>malware<i}, namun PCI DSS menyadari bahwa tidak semua sistem memiliki kemungkinan yang sama. Penting umum bagi penjual untuk mendeklarasikan server Linux, mainframe, dan komputer yang tidak "umumnya terpengaruh oleh perangkat lunak berbahaya" dan karenanya mengecualikan dari 5.2.2. Dalam hal itu, 5.2.3 berlaku, dan Anda harus mengimplementasikan sistem untuk evaluasi ancaman berkala.

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

Persyaratan 5.3

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

Persyaratan 5.2, 5.3, dan 11.5 memerlukan pemindaian antivirus dan pemantauan integritas file (FIM) pada {i>host<i} dalam ruang lingkup proyek. Sebaiknya terapkan solusi dengan semua node dapat dipindai oleh agen tepercaya di dalam cluster atau di mana setiap node memiliki pemindai yang melaporkan hingga satu {i>endpoint<i} pengelolaan.

Untuk 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. Yang akan dilakukan ini, Anda menjalankan container sebagai pengguna non-root dan menggunakan izin akses sistem file untuk mencegah akses tulis ke semua perangkat direktori dalam sistem file kontainer. Larang eskalasi akses untuk menghindari pengelakan dari aturan sistem file.

Persyaratan 6

Mengembangkan dan memelihara sistem dan software yang aman.

Persyaratan 6 PCI DSS menyatakan bahwa Anda membuat perangkat lunak yang kuat pengembangan berkelanjutan di mana keamanan terintegrasi di setiap langkah software pengembangan produk.

Persyaratan 6.2

Software kustom dan dibuat khusus dikembangkan dengan aman.

Persyaratan 6.2.1

Software kustom dan kustom dikembangkan dengan aman, sebagai berikut:

  • Berdasarkan standar industri dan/atau untuk pengembangan yang aman.
  • Sesuai dengan PCI DSS (misalnya, autentikasi dan logging yang aman).
  • Menggabungkan pertimbangan informasi masalah keamanan selama setiap tahap pembuatan perangkat lunak siklus hidup pengembangan aplikasi.

Anda dapat menggunakan Otorisasi Biner untuk membantu memastikan bahwa hanya container tepercaya yang di-deploy ke GKE. Jika Anda ingin mengaktifkan hanya gambar yang diotorisasi oleh satu atau beberapa {i>attestor<i} tertentu, Anda dapat mengonfigurasi Otorisasi Biner untuk menerapkan kebijakan dengan aturan yang mengharuskan pengesahan berdasarkan hasil pemindaian kerentanan. Anda juga dapat menulis kebijakan yang mengharuskan satu atau beberapa pihak tepercaya (disebut "attestor") untuk menyetujui gambar sebelum layanan tersebut dapat di-deploy. Untuk pipeline deployment multi-tahap tempat image diproses dari pengembangan hingga pengujian hingga cluster produksi, Anda dapat menggunakan attestor untuk memastikan bahwa semua proses yang diperlukan telah selesai sebelum perangkat lunak berpindah ke tahap selanjutnya.

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

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 diterapkan ke cluster GKE

Untuk informasi selengkapnya tentang Otorisasi Biner, lihat Menyiapkan GKE.

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

Sandbox GKE mengurangi kebutuhan container untuk berinteraksi langsung dengan host, permukaan serangan untuk penyusupan {i>host<i}, 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 keamanan yang diakui di industri informasi kerentanan, termasuk peringatan dari kedaruratan komputer internasional dan nasional tim respons (CERT).
  • Kerentanan diberi peringkat risiko berdasarkan tentang praktik terbaik industri dan pertimbangan dampak potensial.
  • Peringkat risiko mengidentifikasi, setidaknya, semua kerentanan yang dianggap memiliki risiko atau yang penting bagi lingkungan.
  • Kerentanan untuk pesanan khusus dan kustom, serta software pihak ketiga (misalnya sistem operasi sistem dan {i>database<i}) akan dibahas.

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

Di GKE, Google mengelola bidang kontrol, yang meliputi VM master, server API, dan komponen lain yang berjalan pada VM tersebut, sebagai database etcd. Hal ini mencakup upgrade dan patching, penskalaan, dan dan perbaikan, semuanya didukung oleh tujuan tingkat layanan (SLO). Untuk node' beroperasi seperti Container-Optimized OS atau Ubuntu, GKE segera menyediakan {i>patch<i} untuk gambar tersebut. Jika Anda memiliki upgrade otomatis maka patch ini akan di-deploy secara otomatis. (Ini adalah lapisan dasar dari container Anda. Ini tidak sama dengan sistem operasi yang berjalan di containers.)

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

Google menyediakan beberapa layanan keamanan untuk membantu membangun keamanan di pipeline CI/CD. Untuk mengidentifikasi kerentanan pada image container, Anda dapat penggunaan Pemindaian Kerentanan Google Artifact Analysis. Saat image container dikirim ke Google Container Registry (GCR), pemindaian kerentanan secara otomatis memindai gambar untuk mendeteksi kerentanan dan paparan dari sumber yang diketahui CVE sumber. 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.

Web Security Scanner memungkinkan Anda memindai App Engine, Compute Engine yang tersedia secara publik, dan Aplikasi web GKE untuk kerentanan umum mulai dari pembuatan skrip lintas situs dan kesalahan konfigurasi terhadap resource yang rentan. Pemindaian dapat dijalankan secara on demand dan dijadwalkan dari Konsol Google Cloud. Dengan menggunakan Security Scanner API, Anda dapat mengotomatiskan pemindaian sebagai bagian dari paket pengujian keamanan di pipeline build aplikasi Anda.

Menerapkan langkah-langkah kontrol akses yang kuat

Menerapkan langkah-langkah kontrol akses yang kuat meliputi persyaratan 7, 8, dan 9 PCI DSS.

Persyaratan 7

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

Persyaratan 7 berfokus pada hak istimewa terendah atau yang perlu diketahui. PCI DSS mendefinisikan misalnya, memberikan akses ke data dengan jumlah data paling sedikit dan memberikan hak istimewa yang diperlukan untuk melakukan pekerjaan.

Persyaratan 7.2

Akses ke komponen sistem dan data telah didefinisikan 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 bekerja sama untuk memberikan kontrol akses yang lebih mendetail ke GKE Anda lingkungan fleksibel App Engine. IAM digunakan untuk mengelola akses dan izin pengguna dari resource Google Cloud di project CDE Anda. Di GKE, Anda dapat juga menggunakan IAM untuk mengelola akses dan tindakan yang yang dapat dilakukan akun layanan di cluster Anda, seperti membuat dan menghapus klaster.

Kubernetes RBAC memungkinkan Anda mengonfigurasi kumpulan izin akses yang menentukan cara pengguna Google Cloud tertentu, Google Cloud akun layanan, atau grup pengguna (Google Grup) dapat berinteraksi dengan objek Kubernetes apa pun di cluster Anda, atau dalam namespace. Contoh izin RBAC mencakup pengeditan deployment atau configmaps, menghapus pod, atau melihat log dari pod. Anda memberikan pengguna atau layanan, dengan izin IAM terbatas, seperti Viewer Cluster Google Kubernetes Engine atau peran khusus, lalu terapkan RBAC RoleBinding Kubernetes sebagaimana diperlukan.

Cloud Identity Aware Proxy (IAP) dapat diintegrasikan melalui traffic masuk agar GKE dapat mengontrol akses tingkat aplikasi untuk karyawan atau orang yang memerlukan akses ke PCI Anda menggunakan berbagai aplikasi obrolan.

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

Persyaratan 7.2.2

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

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

Selain memastikan bahwa pengguna dan akun layanan mematuhi prinsip hak istimewa terendah, container juga seharusnya. Praktik terbaik saat menjalankan container adalah menjalankan proses dengan pengguna non-root. Anda dapat mencapai dan melaksanakannya latihan dengan menggunakan Pengontrol penerimaan PodSecurity.

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

Persyaratan 8

Mengidentifikasi pengguna dan mengautentikasi akses ke komponen sistem

Persyaratan 8 menetapkan bahwa ID unik harus ditetapkan ke setiap orang yang memiliki akses ke sistem PCI dalam ruang lingkup untuk memastikan bahwa setiap individu bertanggung jawab atas tindakan mereka.

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 adalah diizinkan.

Persyaratan 8.2.5

Akses untuk pengguna yang dihentikan akan langsung dicabut.

IAM dan Kubernetes RBAC dapat digunakan untuk mengontrol akses ke ke cluster GKE Anda, dan dalam kedua kasus tersebut, Anda dapat memberikan izin kepada seorang pengguna. Sebaiknya pengguna mengaitkannya kembali dengan sistem identitas yang sudah 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 diotentikasi melalui di setidaknya salah satu faktor otentikasi 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 mereka melakukan autentikasi ke kubectl. Semua cluster GKE dikonfigurasi untuk menerima pengguna Google Cloud dan identitas akun layanan, dengan memvalidasi kredensial dan mengambil alamat email yang dikaitkan dengan identitas pengguna atau akun layanan. Hasilnya, kredensial untuk akun tersebut harus menyertakan userinfo.email cakupan OAuth agar berhasil diotentikasi.

Persyaratan 9

Membatasi akses fisik ke data pemegang kartu.

Google akuntabel untuk kontrol keamanan fisik di semua pusat data Google yang mendasarinya Google Cloud.

Memantau dan menguji jaringan secara teratur

Memantau dan menguji jaringan secara teratur mencakup persyaratan 10 dan 11 dari seperti PCI DSS.

Persyaratan 10

Catat dan pantau semua akses ke komponen sistem dan data pemegang kartu.

Persyaratan 10.2

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

Cluster Kubernetes memiliki Logging audit Kubernetes diaktifkan secara default, yang menyimpan catatan kronologis panggilan yang telah yang dibuat 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 Log Audit Cloud dan Logging. Anda dapat melihat entri log audit Kubernetes di project Google Cloud.

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

Untuk membedakan beban kerja CDE dan non-CDE, sebaiknya tambahkan label ke pod GKE Anda yang akan dimasukkan ke dalam metrik dan log dari beban kerja tersebut.

Persyaratan 10.2.2

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

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

  • Payload, yang berjenis protoPayload. Payload setiap audit entri log adalah objek berjenis AuditLog. Identitas pengguna dapat ditemukan di {i>field<i} AuthenticationInfo pada AuditLog objek.
  • Peristiwa tertentu, yang dapat Anda temukan di kolom methodName pada AuditLog.
  • Stempel waktu.
  • Status peristiwa, yang dapat Anda temukan di objek response di Objek AuditLog.
  • Permintaan operasi, yang dapat Anda temukan di request dan Objek requestMetadata dalam objek AuditLog.
  • Layanan yang akan dijalankan, yang dapat Anda temukan di Objek AuditData di serviceData.

Persyaratan 11

Menguji 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 ini:
  • Minimal tiga bulan sekali.
  • Kerentanan berisiko tinggi dan kritis (sesuai peringkat risiko kerentanan entity yang ditentukan di Persyaratan 6.3.1) telah diselesaikan.
  • Pemindaian ulang dilakukan untuk mengonfirmasi semua kerentanan berisiko tinggi dan kritis (seperti disebutkan di atas) telah diselesaikan.
  • Alat pemindaian selalu diupdate dengan versi terbaru informasi kerentanan.
  • Pemindaian dilakukan oleh personel yang berkualifikasi dan terdapat independensi organisasi penguji.

Analisis Artefak pemindaian kerentanan melakukan jenis pemindaian kerentanan berikut untuk image Container Registry:

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

  • Pemindaian inkremental. Artifact Analysis memindai image 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 {i>file<i} yang tidak terduga terdeteksi dan ditanggapi.

Persyaratan 11.5.1

Teknik deteksi penyusupan dan/atau pencegahan intrusi digunakan untuk mendeteksi dan/atau mencegah penyusupan ke dalam jaringan sebagai berikut:
  • Semua lalu lintas dipantau di perimeter CDE
  • Semua lalu lintas dipantau pada titik kritis dalam CDE
  • Personel diberi tahu jika ada dugaan kompromi.
  • Semua mesin deteksi penyusupan dan pencegahan, garis dasar, dan tanda tangan dijaga agar tetap mutakhir.

Pencerminan 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 ditentukan. Cloud IDS dapat menggunakan data traffic duplikat untuk mendeteksi berbagai macam ancaman, termasuk upaya eksploitasi, pemindaian port, luapan buffer, fragmentasi protokol, perintah dan kontrol (C2) lalu lintas, dan {i>malware<i}.

Security Command Center memberi Anda visibilitas terpusat tentang status keamanan Layanan Google Cloud (termasuk GKE) dan aset di seluruh seluruh organisasi, yang membuatnya lebih mudah untuk mencegah, mendeteksi, dan menanggapi 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 akan menentukan kondisi keamanan dan memberi tahu orang-orang apa yang yang mereka harapkan. Dalam hal ini, "orang" mengacu pada penuh waktu dan paruh waktu karyawan, karyawan sementara, kontraktor, dan konsultan yang memiliki akses ke CDE Anda.

Persyaratan 12

Mendukung keamanan informasi dengan kebijakan dan program organisasi.

Untuk mengetahui informasi tentang persyaratan 12, lihat Google Cloud PCI Shared Responsibility Matrix.

Pembersihan

Jika Anda menggunakan referensi apa pun saat mengikuti artikel ini—misalnya, jika Anda memulai VM baru atau menggunakan skrip Terraform. Anda dapat menghindari timbulnya tagihan ke akun Google Cloud Anda dengan menghapus project tempat Anda menggunakan sumber daya 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 berikutnya