Kontrol fondasi perusahaan yang aman

Gunakan batasan boolean automaticIamGrantsForDefaultServiceAccounts untuk menonaktifkan pemberian peran otomatis saat Cloud de Confiance by S3NS layanan otomatis membuat akun layanan default dengan peran yang terlalu permisif.

Secara default, beberapa sistem memberikan izin yang terlalu luas ke akun otomatis, yang merupakan potensi risiko keamanan. Misalnya, jika Anda tidak menerapkan batasan ini dan Anda membuat akun layanan default, akun layanan tersebut akan otomatis diberi peran Editor (roles/editor) di project Anda. Jika penyerang menyusupi satu bagian sistem, mereka dapat mengontrol seluruh project. Batasan ini menonaktifkan izin otomatis tingkat tinggi tersebut, sehingga memaksa pendekatan yang lebih aman dan disengaja di mana hanya izin yang diperlukan minimal yang diberikan.

Gunakan batasan boolean iam.disableServiceAccountKeyCreation untuk menonaktifkan pembuatan kunci akun layanan eksternal. Batasan ini memungkinkan Anda mengontrol penggunaan kredensial jangka panjang yang tidak dikelola untuk akun layanan. Jika batasan ini ditetapkan, Anda tidak dapat membuat kredensial yang dikelola pengguna untuk akun layanan di project yang terpengaruh oleh batasan tersebut.

Gunakan batasan boolean iam.disableServiceAccountKeyUpload untuk menonaktifkan upload kunci publik eksternal ke akun layanan. Jika batasan ini ditetapkan, pengguna tidak dapat mengupload kunci publik ke akun layanan dalam project yang terpengaruh oleh batasan tersebut.

Google merekomendasikan Kunci Keamanan Titan untuk verifikasi 2 langkah (2SV) untuk akun admin super. Namun, untuk kasus penggunaan yang tidak memungkinkan hal ini, sebaiknya gunakan kunci keamanan lain sebagai alternatif.

Menerapkan verifikasi 2 langkah (2SV) untuk unit organisasi (OU) tertentu atau seluruh organisasi. Sebaiknya buat OU untuk admin super dan terapkan Verifikasi 2 Langkah di OU tersebut.

Tidak memiliki satu-satunya admin super atau Administrator Organisasi. Buat satu atau beberapa (hingga 20) akun administrator cadangan. Satu-satunya admin super atau Administrator Organisasi dapat menyebabkan skenario terkunci. Situasi ini juga membawa risiko yang lebih tinggi karena satu orang dapat membuat perubahan yang memengaruhi platform, yang berpotensi tanpa pengawasan.

Gunakan Privileged Access Manager untuk mengelola akses istimewa. Untuk semua akses lainnya, gunakan grup akses, biarkan masa berlaku keanggotaan grup berakhir secara otomatis, dan terapkan alur kerja persetujuan untuk keanggotaan grup.

Dengan menggunakan model hak istimewa terendah, Anda hanya dapat memberikan akses saat diperlukan, untuk resource yang diperlukan. Penggunaan peran bawaan menyederhanakan penggunaan dan mengurangi penyebaran yang disebabkan oleh peran kustom sehingga Anda tidak perlu khawatir tentang pengelolaan siklus proses peran.

Tentukan sumber tepercaya Anda untuk menyediakan identitas pengguna terkelola. Pola ini mencakup pembuatan identitas pengguna di Cloud Identity, menyinkronkan identitas dari penyedia identitas yang ada, atau menggunakan Workforce Identity Federation.

Menerapkan sandi yang kuat dan unik untuk semua akun pengguna. Pertimbangkan untuk menggunakan pengelola sandi. Kredensial yang lemah atau tidak ada adalah pola umum yang dapat dengan mudah dieksploitasi oleh pengguna berbahaya.

Gunakan peran Identity and Access Management (IAM) yang didasarkan pada fungsi tugas untuk menetapkan izin kepada pengguna. Fungsi tugas adalah peran bawaan yang memungkinkan admin memberikan serangkaian izin yang terbatas pada fungsi tugas, sehingga meningkatkan produktivitas dan mengurangi bolak-balik meminta izin. Untuk lebih menyelaraskan dengan persyaratan organisasi Anda, Anda dapat membuat peran khusus berdasarkan peran bawaan.

Menetapkan kebijakan seluruh organisasi untuk mencegah penambahan anggota eksternal ke Google Grup.

Secara default, akun pengguna eksternal dapat ditambahkan ke grup di Cloud Identity. Sebaiknya Anda mengonfigurasi setelan berbagi agar pemilik grup tidak dapat menambahkan anggota eksternal.

Perhatikan bahwa pembatasan ini tidak berlaku untuk akun admin super atau untuk administrator lain yang didelegasikan dengan izin admin Google Grup. Karena federasi dari penyedia identitas Anda berjalan dengan hak istimewa administrator, setelan berbagi grup tidak berlaku untuk sinkronisasi grup ini. Sebaiknya tinjau kontrol di penyedia identitas dan mekanisme sinkronisasi untuk memastikan bahwa anggota non-domain tidak ditambahkan ke grup, atau Anda menerapkan batasan grup.

Tetapkan durasi sesi untuk layanan Cloud de Confiance by S3NS agar berakhir setidaknya sekali sehari. Membiarkan akun tetap login dalam jangka waktu yang lama merupakan risiko keamanan. Menerapkan durasi sesi maksimum akan otomatis mengakhiri sesi setelah waktu yang ditetapkan, sehingga memaksa login baru yang aman.

Praktik ini mengurangi peluang pengguna berbahaya menggunakan sandi yang dicuri dan memastikan akses diverifikasi ulang secara rutin.

Untuk pelanggan baru, durasi sesi default 16 jam akan otomatis diterapkan. Pelanggan yang membuat organisasi Cloud de Confiance by S3NS sebelum tahun 2023 mungkin memiliki setelan default untuk tidak pernah mewajibkan autentikasi ulang. Tinjau setelan ini untuk memastikan bahwa Anda memiliki kebijakan autentikasi ulang dengan durasi sesi antara 1 hingga 24 jam. Kebijakan autentikasi ulang akan membatalkan validasi token refresh dan memaksa pengguna untuk mengautentikasi ulang gcloud CLI secara teratur dengan sandi atau kunci keamanannya.

Durasi sesi untuk layanan Cloud de Confiance by S3NS adalah setelan yang berbeda dari durasi sesi untuk layanan Google, yang mengontrol sesi web untuk login di seluruh layanan Google Workspace, tetapi tidak mengontrol autentikasi ulang untuk Cloud de Confiance by S3NS. Jika Anda menggunakan layanan Google Workspace, tetapkan durasi sesi untuk keduanya.

Jangan izinkan akun konsumen yang tidak dikelola. Gabungkan semua akun konsumen yang tidak dikelola, dan pertimbangkan solusi untuk mencegah pembuatan akun konsumen yang tidak dikelola lebih lanjut dengan domain Anda.

Akun konsumen yang tidak dikelola tidak diatur oleh proses joiner-mover-leaver (JML) Anda, sehingga menimbulkan risiko bahwa karyawan masih memiliki akses ke resource Anda setelah mereka keluar dari pekerjaannya. Akun ini juga diperlakukan sebagai eksternal terkait kontrol seperti berbagi yang dibatasi domain.

Pastikan akun admin super terpisah dari akun pengguna sehari-hari. Akun admin super harus berupa akun khusus yang hanya digunakan saat membuat perubahan penting. Untuk meningkatkan keamanan, aktifkan persetujuan banyak pihak untuk tindakan admin. Mengaktifkan persetujuan banyak pihak berarti tindakan sensitif disetujui oleh dua administrator, yang membantu mencegah penyerang membahayakan akun admin dan mengunci pengguna admin lainnya.

Aktifkan autentikasi multi-faktor (MFA), yang juga dikenal sebagai autentikasi 2 langkah (2SV) untuk semua pengguna Akun Google dan Cloud Identity, bukan hanya admin super. MFA untuk admin super diaktifkan secara default. MFA menambahkan lapisan pertahanan lain karena sandi saja sering kali tidak cukup kuat sebagai langkah keamanan.

Hapus peran Project Creator dan Billing Account Creator di seluruh domain yang diberikan secara default kepada semua anggota di organisasi baru.

Organisasi baru memberikan peran Project Creator dan Billing Account Creator kepada semua identitas pengguna terkelola di domain. Meskipun berguna untuk memulai, konfigurasi ini tidak ditujukan untuk lingkungan produksi. Membiarkan akun penagihan berkembang biak menyebabkan peningkatan beban administratif dan memiliki konsekuensi teknis saat memisahkan layanan di beberapa Akun Penagihan. Mengizinkan pembuatan project bentuk bebas dapat menyebabkan project tidak mematuhi konvensi tata kelola Anda.

Sebagai gantinya, hapus peran ini dan buat proses pembuatan project untuk meminta project baru dan mengaitkannya dengan penagihan.

Jika Anda harus menggunakan kunci akun layanan, rotasi kunci setidaknya sekali setiap 90 hari.

Interval rotasi membatasi berapa lama penyerang dapat memiliki akses ke sistem. Tanpa interval rotasi, penyerang akan memiliki akses selamanya. Jika memungkinkan, sebaiknya gunakan Workload Identity Federation, bukan kunci akun layanan.

Gunakan Workload Identity Federation agar sistem CI/CD dan workload yang berjalan di cloud lain dapat melakukan autentikasi ke Cloud de Confiance by S3NS. Workload Identity Federation memungkinkan beban kerja yang berjalan di luar Cloud de Confiance melakukan autentikasi tanpa memerlukan kunci akun layanan. Dengan menghindari kunci akun layanan dan kredensial lain yang aktif dalam waktu lama, Workload Identity Federation dapat membantu Anda mengurangi risiko kebocoran kredensial.

Secara default, pemulihan mandiri akun admin super dinonaktifkan untuk pelanggan baru. Namun, pelanggan lama mungkin mengaktifkan setelan ini. Menonaktifkan setelan ini membantu mengurangi risiko bahwa ponsel yang disusupi, email yang disusupi, atau serangan manipulasi psikologis dapat memungkinkan penyerang mendapatkan hak istimewa admin super atas lingkungan Anda.

Rencanakan proses internal bagi admin super untuk menghubungi admin super lain di organisasi Anda jika mereka kehilangan akses ke akunnya, dan pastikan semua admin super memahami proses pemulihan yang dibantu dukungan.

Untuk menonaktifkan fitur ini, buka setelan pemulihan akun di konsol Google Admin.

Tetapkan waktu tunggu sesi tidak ada aktivitas menjadi 15 menit untuk kasus penggunaan sensitif. Sesi yang tidak aktif dapat digunakan oleh penyerang untuk pencurian kredensial.

Berikan kunci keamanan hardware, jika memungkinkan, kepada admin super atau Administrator Organisasi sebagai faktor kedua. Akun admin super adalah target bernilai tertinggi untuk serangan canggih. Kunci keamanan hardware memberikan tingkat perlindungan yang tinggi karena tahan terhadap phishing. Kunci keamanan hardware adalah pertahanan terkuat terhadap pengambilalihan akun untuk administrator terpenting Anda dan dibuat berdasarkan kebijakan MFA standar Anda.

Jika Anda menggunakan penyedia identitas eksternal, siapkan verifikasi pasca-SSO.

Aktifkan lapisan kontrol tambahan berdasarkan analisis risiko login Google. Setelah Anda menerapkan setelan ini, pengguna mungkin melihat verifikasi login berbasis risiko tambahan saat login jika Google menentukan bahwa login pengguna mencurigakan.

Aktifkan kebijakan principal access boundary (PAB) untuk membatasi akses entitas dan membantu melindungi dari phishing dan pemindahan data yang tidak sah. Aktifkan kebijakan PAB untuk organisasi guna menghindari serangan phishing eksternal. PAB meningkatkan keamanan dengan mengurangi tingkat serangan yang menggunakan identitas yang disusupi, dan juga membantu mencegah serangan phishing eksternal dan serangan eksfiltrasi lainnya.

Tag memberikan cara untuk membuat anotasi untuk resource, dan dalam beberapa kasus, mengizinkan atau menolak kebijakan secara bersyarat berdasarkan apakah resource memiliki tag tertentu. Gunakan tag dan penerapan kebijakan bersyarat untuk mendapatkan kontrol yang terperinci di seluruh hierarki resource Anda.

Gunakan Cloud Audit Logs untuk memantau aktivitas berisiko tinggi, seperti akun yang diberi peran berisiko tinggi seperti Admin Organisasi dan Admin Super. Siapkan notifikasi untuk jenis aktivitas ini.

Untuk menghindari pemberian akses yang berlebihan ke Cloud de Confiance by S3NS, blokir akses ke Cloud Shell untuk akun pengguna yang dikelola Cloud Identity.

Dengan Akses Kontekstual, Anda dapat membuat kebijakan keamanan kontrol akses terperinci untuk aplikasi berdasarkan berbagai atribut, seperti identitas pengguna, lokasi, status keamanan perangkat, dan alamat IP. Sebaiknya gunakan Akses Kontekstual untuk membatasi akses ke konsol Cloud de Confiance (https://console.cloud.google.com/) dan konsol Google Admin (https://admin.cloud.google.com).

Cloud de Confiance mendukung beberapa versi protokol TLS. Untuk memenuhi persyaratan kepatuhan, Anda mungkin ingin menolak permintaan handshake dari klien yang menggunakan versi TLS yang lebih lama.

Untuk mengonfigurasi kontrol ini, gunakan batasan kebijakan organisasi Membatasi Versi TLS (gcp.restrictTLSVersion). Anda dapat menerapkan batasan ini ke organisasi, folder, atau project dalam hierarki resource. Batasan Restrict TLS Versions menggunakan daftar penolakan, yang menolak nilai eksplisit dan mengizinkan semua nilai lainnya. Error terjadi jika Anda mencoba menggunakan daftar yang diizinkan.

Karena perilaku evaluasi hierarki kebijakan organisasi, pembatasan versi TLS berlaku untuk node resource yang ditentukan dan semua folder serta projectnya (turunan). Misalnya, jika Anda menolak TLS versi 1.0 untuk organisasi, TLS versi 1.0 juga akan ditolak untuk semua turunan yang berasal dari organisasi tersebut.

Anda dapat mengganti pembatasan versi TLS yang diwariskan dengan memperbarui kebijakan organisasi pada resource turunan. Misalnya, jika kebijakan organisasi Anda menolak TLS 1.0 di tingkat organisasi, Anda dapat menghapus batasan untuk folder turunan dengan menetapkan kebijakan organisasi terpisah pada folder tersebut. Jika folder memiliki turunan, kebijakan folder juga akan diterapkan pada setiap resource turunan karena pewarisan kebijakan.

Untuk lebih membatasi versi TLS hanya ke TLS 1.3, Anda dapat menetapkan kebijakan ini untuk juga membatasi versi TLS 1.2. Anda harus menerapkan kontrol ini pada aplikasi yang Anda hosting di dalam Cloud de Confiance by S3NS. Misalnya, di tingkat organisasi, tetapkan:

["TLS_VERSION_1","TLS_VERSION_1.1","TLS_VERSION_1.2"]

Pastikan hanya identitas dari organisasi Anda yang diizinkan di Cloud de Confiance by S3NS lingkungan Anda. Gunakan batasan kebijakan organisasi Berbagi yang dibatasi domain (iam.allowedPolicyMemberDomains) atau iam.managed.allowedPolicyMembers untuk menentukan satu atau beberapa ID pelanggan Cloud Identity atau Google Workspace yang pokoknya dapat ditambahkan ke kebijakan Identity and Access Management (IAM).

Batasan ini membantu mencegah karyawan memberikan akses ke akun eksternal di luar kontrol organisasi Anda yang tidak mengikuti kebijakan keamanan Anda untuk autentikasi multi-faktor (MFA) atau pengelolaan sandi. Kontrol ini sangat penting untuk mencegah akses yang tidak sah, sehingga memastikan bahwa hanya identitas perusahaan terkelola yang tepercaya yang dapat digunakan.

Batasan gcp.restrictServiceUsage memastikan bahwa hanya layanan yang disetujui Cloud de Confiance by S3NS yang digunakan di tempat yang tepat. Misalnya, folder produksi atau folder yang berisi data yang sangat sensitif memiliki daftar kecil Cloud de Confiance layanan yang disetujui untuk menyimpan data. Folder sandbox mungkin memiliki daftar layanan yang lebih besar dan kontrol keamanan data yang menyertainya untuk membantu mencegah pemindahan data yang tidak sah. Nilai ini khusus untuk sistem Anda dan cocok dengan daftar layanan dan dependensi yang disetujui untuk folder dan project tertentu.

Batasan ini memungkinkan organisasi Anda membuat daftar yang diizinkan untuk layanan yang disetujui, yang membantu mencegah karyawan menggunakan layanan yang tidak diperiksa.

Batasan Lokasi Resource (gcp.resourceLocations) memastikan bahwa hanya region yang Anda setujui Cloud de Confiance by S3NS yang digunakan untuk menyimpan data. Nilai ini khusus untuk sistem Anda dan cocok dengan daftar wilayah yang disetujui organisasi Anda untuk residensi data.

Batasan ini memungkinkan organisasi Anda memastikan bahwa resource dan data Anda hanya dibuat dan disimpan di wilayah geografis tertentu yang telah disetujui.

Batasan boolean compute.skipDefaultNetworkCreation tidak akan membuat jaringan default dan resource terkait saat membuat project Cloud de Confiance by S3NS .

Jaringan default adalah jaringan Virtual Private Cloud (VPC) mode otomatis dengan aturan firewall IPv4 yang sudah terisi otomatis untuk mengizinkan jalur komunikasi internal. Secara umum, penyiapan ini bukan postur keamanan yang direkomendasikan untuk lingkungan produksi.

Domain Name System Security Extensions (DNSSEC) adalah fitur Domain Name System (DNS) yang mengautentikasi respons terhadap pencarian nama domain. Fitur ini tidak memberikan perlindungan privasi untuk pencarian tersebut, tetapi mencegah penyerang memanipulasi atau merusak respons terhadap permintaan DNS.

Dalam Cloud DNS, aktifkan DNSSEC di tempat berikut:

• Zona DNS
• Domain level teratas (TLD)
• Resolusi DNS

Aktifkan Akses Google Pribadi di semua subnet.

Aktifkan akses layanan pribadi untuk membuat jaringan pribadi antara Cloud de Confiance by S3NS layanan seperti jaringan lama Google Cloud VMware Engine dan produsen layanan seperti Cloud SQL. Akses layanan pribadi membantu menghindari pemaparan koneksi jaringan beban kerja ke internet secara tidak perlu.

Nonaktifkan pembuatan subnet eksternal IPv6 kecuali jika diperlukan secara khusus. Untuk mengurangi permukaan serangan, pertimbangkan untuk menonaktifkan IPv6 pada sistem dan jaringan yang tidak dikelola atau diperlukan secara aktif. Banyak organisasi memiliki kontrol dan pemantauan keamanan yang matang untuk IPv4, tetapi alat dan kebijakan mereka mungkin tidak sepenuhnya mencakup IPv6, yang dapat menciptakan titik buta yang signifikan terhadap ancaman. Menjalankan jaringan dual-stack juga menimbulkan kompleksitas operasional, yang memerlukan konfigurasi dan keahlian khusus untuk mengelola dan memecahkan masalah secara efektif. Oleh karena itu, jika Anda tidak memiliki pendorong bisnis yang jelas untuk IPv6, menonaktifkannya dapat menyederhanakan lingkungan Anda dan memastikan semua traffic difilter secara konsisten melalui postur keamanan IPv4 yang telah ditetapkan.

Batasi akses ke sumber eksternal karena secara default, semua akses keluar diizinkan. Tetapkan aturan firewall tertentu untuk pola traffic yang dimaksudkan yang perlu keluar.

Secara default, sistem sering kali diizinkan untuk membuat koneksi keluar ke internet, yang dapat dianggap sebagai risiko keamanan. Kebijakan tolak secara default memblokir traffic keluar dan mengharuskan aturan khusus dibuat hanya untuk tujuan yang diketahui dan diperlukan.

Jika memungkinkan, batasi akses masuk hanya ke resource dan rentang resource tertentu. Jika Identity-Aware Proxy (IAP) dikonfigurasi, tetapkan aturan firewall SSH dan Remote Desktop Protocol (RDP) inbound ke rentang IP IAP sebagai sumber.

Aturan firewall SSH dan RDP yang permisif memungkinkan terjadinya serangan brute force. Sebagai gantinya, gunakan proxy yang mendukung identitas Cloud de Confiance by S3NS (seperti IAP) untuk SSH dan RDP.

Aktifkan Kontrol Layanan VPC sebagai lapisan perlindungan tambahan untuk mencegah potensi kehilangan data.

Kontrol Layanan VPC dapat membantu mencegah pemindahan data yang tidak sah dengan membuat perimeter isolasi di sekitar resource cloud, data sensitif, dan jaringan Anda.

Perimeter layanan membatasi kegunaan kredensial yang disusupi karena perimeter memblokir permintaan ke layanan yang dibatasi yang berasal dari endpoint yang dikontrol penyerang yang berada di luar lingkungan Anda.

Untuk aplikasi yang diekspos di belakang Cloud Load Balancing, gunakan kebijakan default Google Cloud Armor atau konfigurasikan kebijakan Anda sendiri untuk menambahkan perlindungan jaringan Lapisan 3 hingga Lapisan 7 untuk aplikasi atau layanan yang dapat diakses dari luar. Kebijakan keamanan Cloud Armor membantu melindungi aplikasi Anda dengan menyediakan pemfilteran Lapisan 7. Kebijakan ini juga meninjau permintaan masuk untuk serangan web umum atau atribut Lapisan 7 lainnya, sehingga dapat memblokir traffic sebelum mencapai layanan backend ber-load balancer atau bucket backend Anda. Setiap kebijakan keamanan terdiri dari serangkaian aturan yang mencakup atribut dari Lapisan 3 hingga Lapisan 7.

Untuk setiap perimeter layanan, konfirmasi di konsol Cloud de Confiance bahwa jenis perimeter ditetapkan ke reguler.

Untuk setiap perimeter layanan, gunakan Access Context Manager untuk mengonfirmasi bahwa perimeter melindungi API.

Batasan boolean compute.setNewProjectDefaultToZonalDNSOnly memungkinkan Anda menetapkan setelan DNS internal untuk project baru agar hanya menggunakan DNS zona. Gunakan DNS zona karena menawarkan keandalan yang lebih tinggi dibandingkan dengan zona individual karena DNS zona mengisolasi kegagalan dalam pendaftaran DNS .

Jika menggunakan Cloud Identity, bagikan log audit dari Cloud Identity ke Cloud de Confiance by S3NS.

Log audit Aktivitas Admin dari Google Workspace atau Cloud Identity biasanya dikelola dan dilihat di konsol Google Admin, secara terpisah dari log di lingkungan Cloud de Confiance Anda. Log ini berisi informasi yang relevan untuk lingkungan Cloud de Confiance Anda, seperti peristiwa login pengguna.

Sebaiknya bagikan log audit Cloud Identity ke lingkungan Cloud de Confiance Anda untuk mengelola log secara terpusat dari semua sumber.

LayananCloud de Confiance menulis entri log audit untuk menjawab siapa yang melakukan apa, di mana, dan kapan dengan resource Cloud de Confiance .

Aktifkan logging audit di tingkat organisasi. Anda dapat mengonfigurasi logging menggunakan pipeline yang Anda gunakan untuk menyiapkan organisasi Cloud de Confiance .

VPC Flow Logs mencatat sampel alur jaringan yang dikirim dari dan diterima oleh instance VM, termasuk yang digunakan sebagai node Google Kubernetes Engine (GKE). Sampel biasanya berjumlah 50% atau kurang dari alur jaringan VPC.

Dengan mengaktifkan Log Alur VPC, Anda mengaktifkan logging untuk semua VM di subnet. Namun, Anda dapat mengurangi jumlah informasi yang ditulis ke logging.

Aktifkan VPC Flow Logs untuk setiap subnet VPC. Anda dapat mengonfigurasi logging menggunakan pipeline yang Anda gunakan untuk membuat project.

Secara default, aturan firewall tidak otomatis menulis log.Firewall Rules Logging memungkinkan Anda mengaudit, memverifikasi, dan menganalisis efek aturan firewall Anda. Misalnya, Anda dapat menentukan apakah aturan firewall yang dirancang untuk menolak traffic berfungsi sebagaimana mestinya. Logging juga berguna jika Anda ingin menentukan jumlah koneksi yang terpengaruh oleh aturan firewall tertentu.

Aktifkan logging untuk setiap aturan firewall. Anda dapat mengonfigurasi logging menggunakan pipeline yang Anda gunakan untuk membuat firewall.

Secara default, Cloud de Confiance mengaktifkan dan tidak mengizinkan siapa pun menonaktifkan audit aktivitas administrator utama untuk akun istimewa.

Log audit Aktivitas Admin berisi entri log untuk panggilan API atau tindakan lain yang mengubah konfigurasi atau metadata resource. Misalnya, log ini mencatat saat pengguna membuat instance VM atau mengubah izin IAM.

Log audit Aktivitas Admin berisi entri log untuk pembuatan, modifikasi, dan penghapusan batasan kebijakan organisasi dari tingkat organisasi, folder, dan project.

Log audit Aktivitas Admin selalu ditulis; Anda tidak dapat mengonfigurasi, mengecualikan, atau menonaktifkannya. Meskipun Anda menonaktifkan Cloud Logging API, log audit Aktivitas Admin tetap dibuat.

Sebaiknya organisasi Anda menyiapkan kebijakan dan prosedur untuk memantau pemberitahuan ini, serta membuat tindakan atau pemberitahuan sesuai dengan kebijakan akses perusahaan Anda untuk memantau aktivitas administrator.

Berlangganan notifikasi buletin keamanan untuk Cloud de Confiance by S3NS layanan guna menerima pemberitahuan tentang kerentanan dan langkah-langkah mitigasi.

Jika tersedia buletin keamanan yang relevan dengan layanan Anda (seperti GKE), layanan tersebut dapat memublikasikan notifikasi tentang peristiwa tersebut sebagai pesan ke topik Pub/Sub yang Anda konfigurasikan. Cloud de Confiance by S3NS Anda dapat menerima notifikasi ini di langganan Pub/Sub, berintegrasi dengan layanan pihak ketiga, dan memfilter jenis notifikasi yang ingin diterima.

Konfigurasi Kontak Penting untuk memastikan bahwa alias grup atau milis yang dipantau menerima notifikasi penting.

Menggunakan alamat email grup yang dipantau akan membantu memastikan bahwa pemberitahuan yang mendesak ini dikirimkan ke tim aktif yang dapat merespons dengan cepat.

Gunakan fitur anomali penagihan di Penagihan Cloud untuk melacak lonjakan atau penyimpangan dalam pembelanjaan yang diharapkan.

Lonjakan tagihan cloud yang tiba-tiba dan tidak terduga adalah indikator utama kompromi keamanan. Lonjakan penagihan yang tidak terduga terkadang disebabkan oleh penyerang yang telah mendapatkan akses dan menggunakan resource untuk aktivitas yang tidak sah.

Mengaktifkan deteksi anomali penagihan akan menyediakan sistem peringatan dini yang penting sehingga Anda dapat menandai aktivitas mencurigakan ini secara otomatis.

Buat sink log untuk mengekspor log bagi solusi pemantauan keamanan Anda dan tetapkan periode retensi data untuk memenuhi persyaratan Anda.

Periode retensi log default sering kali tidak cukup lama untuk memenuhi persyaratan 1-7 tahun yang diwajibkan oleh peraturan kepatuhan seperti PCI atau HIPAA.

Membuat sink log untuk mengekspor log ke lokasi penyimpanan jangka panjang sangat penting untuk memenuhi kewajiban hukum dan peraturan tertentu. Sink log juga memungkinkan Anda mengirim log ke sistem pemantauan keamanan terpusat untuk deteksi ancaman tingkat lanjut.

Untuk melacak siapa yang mengakses data di lingkungan Cloud de Confiance by S3NS Anda, aktifkan log audit Akses Data. Log ini mencatat panggilan API yang membaca, membuat, atau mengubah data pengguna, serta panggilan API yang membaca konfigurasi resource.

Sebaiknya aktifkan log audit Akses Data untuk model AI generatif dan data sensitif guna memastikan Anda dapat mengaudit siapa yang telah membaca informasi tersebut. Untuk menggunakan log audit Akses Data, Anda harus menyiapkan logika deteksi kustom sendiri untuk aktivitas tertentu, seperti login admin super.

Volume log audit Akses Data bisa besar. Mengaktifkan log Akses Data dapat menyebabkan project Cloud de Confiance Anda dikenai biaya untuk penggunaan log tambahan.

Hindari tagihan yang tidak terduga dengan membuat anggaran Penagihan Cloud untuk memantau semua biaya Cloud de Confiance by S3NS di satu tempat. Setelah menetapkan jumlah anggaran, tetapkan aturan nilai minimum pemberitahuan anggaran berdasarkan per project untuk memicu notifikasi email. Notifikasi ini membantu Anda melacak pengeluaran terhadap anggaran. Anda juga dapat menggunakan anggaran Penagihan Cloud untuk mengotomatiskan respons pengendalian biaya.

Log standar menunjukkan tindakan yang dilakukan pengguna organisasi Anda sendiri, tetapi log Transparansi Akses menunjukkan tindakan yang dilakukan staf dukungan Google saat mereka mengakses akun. Akses ini biasanya hanya terjadi sebagai respons terhadap permintaan dukungan. Log Transparansi Akses memberikan jejak audit yang lengkap dan dapat diverifikasi untuk semua akses, yang penting untuk memenuhi persyaratan kepatuhan dan tata kelola data yang ketat.

Anda dapat mengaktifkan Transparansi Akses di tingkat organisasi.

Untuk analisis penagihan lebih lanjut, Anda dapat mengekspor Cloud de Confiance by S3NS data penagihan ke BigQuery atau file JSON. Misalnya, Anda dapat mengekspor data mendetail secara otomatis, seperti penggunaan, perkiraan biaya, dan harga, sepanjang hari ke set data BigQuery yang Anda tentukan. Kemudian, Anda dapat mengakses data Penagihan Cloud dari BigQuery untuk memperoleh analisis yang mendetail, atau menggunakan alat seperti Data Studio untuk memvisualisasikan data Anda.

Semua data di Cloud de Confiance dienkripsi dalam penyimpanan secara default menggunakan algoritma yang disetujui NIST.

Pastikan Cloud Key Management Service (Cloud KMS) hanya menggunakan algoritma yang disetujui NIST untuk menyimpan kunci sensitif di lingkungan. Kontrol ini memastikan penggunaan kunci yang aman hanya dengan algoritma dan keamanan yang disetujui NIST. Kolom CryptoKeyVersionAlgorithm adalah daftar yang diizinkan yang diberikan.

Menghapus algoritma yang tidak mematuhi kebijakan organisasi Anda.

Tetapkan tujuan kunci Cloud KMS ke ENCRYPT_DECRYPT agar kunci hanya digunakan untuk mengenkripsi dan mendekripsi data. Kontrol ini memblokir fungsi lain, seperti penandatanganan, dan memastikan bahwa kunci hanya digunakan untuk tujuan yang dimaksudkan. Jika Anda menggunakan kunci untuk fungsi lain, validasi kasus penggunaan tersebut dan pertimbangkan untuk membuat kunci tambahan.

Level perlindungan menunjukkan cara operasi kriptografi dilakukan. Setelah membuat kunci enkripsi yang dikelola pelanggan (CMEK), Anda tidak dapat mengubah tingkat perlindungan. Tingkat perlindungan yang didukung adalah sebagai berikut:

• SOFTWARE: Operasi kriptografi dilakukan di software.
• HSM: Operasi kriptografi dilakukan di modul keamanan hardware (HSM).
• EKSTERNAL: Operasi kriptografi dilakukan menggunakan kunci yang disimpan di pengelola kunci eksternal yang terhubung ke Cloud de Confiance melalui internet. Terbatas pada enkripsi simetris dan penandatanganan asimetris.
• EXTERNAL_VPC: Operasi kriptografi dilakukan menggunakan kunci yang disimpan di pengelola kunci eksternal yang terhubung ke Cloud de Confiance melalui jaringan Virtual Private Cloud (VPC). Terbatas pada enkripsi simetris dan penandatanganan asimetris.

Pastikan periode rotasi kunci Cloud KMS Anda ditetapkan ke 90 hari. Praktik terbaik umum adalah merotasi kunci keamanan Anda secara berkala. Kontrol ini menerapkan rotasi kunci untuk kunci yang dibuat dengan layanan HSM.

Saat membuat periode rotasi ini, buat juga kebijakan dan prosedur yang sesuai untuk menangani pembuatan, penghapusan, dan modifikasi materi utama secara aman sehingga Anda dapat membantu melindungi informasi Anda dan memastikan ketersediaan. Pastikan periode ini mematuhi kebijakan perusahaan Anda untuk rotasi kunci.

Buat strategi pengelolaan enkripsi menggunakan Cloud Key Management Service (Cloud KMS) dengan Autokey, Cloud External Key Manager (Cloud EKM), atau keduanya. Strategi ini memungkinkan organisasi Anda menggunakan dan mengelola kunci enkripsinya sendiri untuk memenuhi persyaratan spesifik Anda. Penggunaan kunci enkripsi Anda sendiri memberikan kontrol terperinci yang dapat diaudit atas akses data, termasuk kemampuan untuk langsung memblokir akses ke data dengan menonaktifkan kunci.

Gunakan batasan kebijakan organisasi Batasi project mana yang dapat menyediakan CryptoKey KMS untuk CMEK (gcp.restrictCmekCryptoKeyProjects) untuk menentukan project mana yang dapat menyimpan kunci enkripsi yang dikelola pelanggan (CMEK). Batasan ini memungkinkan Anda memusatkan tata kelola dan pengelolaan kunci enkripsi. Jika kunci yang dipilih tidak memenuhi batasan ini, pembuatan resource akan gagal.

Untuk mengubah batasan ini, administrator memerlukan peran IAM Organization Policy Administrator (roles/orgpolicy.policyAdmin).

Jika Anda ingin menambahkan lapisan perlindungan kedua, seperti bawa kunci Anda sendiri, ubah batasan ini untuk merepresentasikan nama kunci CMEK yang diaktifkan.

Detail produk:

• Di Gemini Enterprise Agent Platform, Anda menyimpan kunci di project KEY PROJECTS.

Jika memerlukan kontrol lebih besar atas operasi kunci daripada yang diizinkan oleh Google Cloud-powered encryption keys , Anda dapat menggunakan kunci enkripsi yang dikelola pelanggan (CMEK). Kunci ini dibuat dan dikelola menggunakan Cloud KMS. Simpan kunci sebagai kunci software, dalam cluster HSM, atau dalam sistem pengelolaan kunci eksternal.

Tingkat enkripsi dan dekripsi Cloud KMS bergantung pada kuota.

Spesifikasi Cloud Storage

Di Cloud Storage, gunakan CMEK pada setiap objek, atau konfigurasi bucket Cloud Storage Anda untuk menggunakan CMEK secara default pada semua objek baru yang ditambahkan ke bucket. Saat menggunakan CMEK, objek dienkripsi dengan kunci tersebut oleh Cloud Storage pada saat disimpan dalam bucket, dan objek secara otomatis didekripsi oleh Cloud Storage saat objek disajikan kepada pemohon.

Batasan berikut berlaku saat menggunakan CMEK dengan Cloud Storage:

• Anda tidak dapat mengenkripsi objek dengan CMEK dengan memperbarui metadata objek. Sertakan kunci sebagai bagian dari penulisan ulang objek.
• Cloud Storage Anda menggunakan perintah update objek untuk menetapkan kunci enkripsi pada objek, tetapi perintah tersebut akan menulis ulang objek sebagai bagian dari permintaan.
• Anda harus membuat key ring Cloud KMS di lokasi yang sama dengan data yang ingin Anda enkripsi. Misalnya, jika bucket Anda berada di us-east1, key ring apa pun yang digunakan untuk mengenkripsi objek di bucket tersebut juga harus dibuat di us-east1.
• Untuk sebagian besar dual-region, Anda harus membuat key ring Cloud KMS di multi-region yang terkait. Misalnya, jika bucket Anda berada di pasangan us-east1, us-west1, key ring apa pun yang digunakan untuk mengenkripsi objek di bucket tersebut harus dibuat di multi-region Amerika Serikat.
• Untuk dual-region asia1, eur4, dan nam4 yang telah ditetapkan sebelumnya, Anda harus membuat key ring di dual-region yang sama yang telah ditetapkan sebelumnya.
• Checksum CRC32C dan hash MD5 objek yang dienkripsi dengan CMEK tidak ditampilkan saat mencantumkan objek dengan JSON API.
• Menggunakan alat seperti Cloud Storage untuk melakukan permintaan GET metadata tambahan pada setiap objek enkripsi guna mengambil informasi CRC32C dan MD5 dapat membuat daftar menjadi jauh lebih pendek. Cloud Storage tidak dapat menggunakan bagian dekripsi dari kunci asimetris yang disimpan di Cloud KMS untuk secara otomatis mendekripsi objek yang relevan dengan cara yang sama seperti yang dilakukan oleh CMEK.