Ringkasan desain keamanan infrastruktur Google

Konten ini terakhir diperbarui pada Juni 2023, dan menampilkan kondisi pada saat konten tersebut ditulis. Kebijakan dan sistem keamanan Google dapat berubah di masa mendatang, seiring upaya kami untuk meningkatkan perlindungan bagi pelanggan.

Pengantar

Dokumen ini memberikan ringkasan tentang cara keamanan dirancang ke dalam infrastruktur teknis Google. Dokumen ini ditujukan untuk eksekutif keamanan, arsitek keamanan, dan auditor.

Dokumen ini menjelaskan hal berikut:

  • Infrastruktur teknis global Google, yang dirancang untuk memberikan keamanan di sepanjang seluruh siklus proses pemrosesan informasi di Google. Infrastruktur ini membantu menyediakan hal berikut:
    • Deployment layanan yang aman
    • Penyimpanan data yang aman dengan perlindungan privasi pengguna akhir
    • Komunikasi yang aman antarlayanan
    • Komunikasi yang aman dan pribadi dengan pelanggan melalui internet
    • Pengoperasian yang aman oleh engineer Google
  • Cara kami menggunakan infrastruktur ini untuk membuat layanan internet, termasuk layanan konsumen seperti Google Penelusuran, Gmail, dan Google Foto, serta layanan perusahaan seperti Google Workspace dan Google Cloud.
  • Investasi kami dalam mengamankan infrastruktur dan operasi kami. Kami memiliki banyak engineer yang berdedikasi terhadap keamanan dan privasi di seluruh Google, termasuk banyak dari mereka yang diakui sebagai otoritas industri.
  • Produk dan layanan keamanan kami merupakan hasil dari inovasi yang kami terapkan secara internal untuk memenuhi kebutuhan keamanan kami. Misalnya, BeyondCorp merupakan hasil langsung dari implementasi internal model keamanan zero-trust.

  • Cara keamanan infrastruktur dirancang di lapisan progresif. Lapisan tersebut meliputi:

Bagian selanjutnya dari dokumen ini menjelaskan terkait lapisan keamanan.

Mengamankan infrastruktur tingkat rendah

Bagian ini menjelaskan cara kami mengamankan lokasi fisik tempat pusat data berada, hardware dalam pusat data, dan stack software yang berjalan di hardware.

Keamanan lokasi fisik

Kami merancang dan membangun pusat data kami sendiri, yang menggabungkan beberapa lapisan keamanan fisik. Akses ke pusat data ini dikontrol secara ketat. Kami menggunakan beberapa lapisan keamanan fisik untuk melindungi area pusat data kami. Kami menggunakan identifikasi biometrik, deteksi logam, kamera, penghalang kendaraan, dan sistem deteksi penyusupan berbasis laser. Untuk informasi selengkapnya, lihat Keamanan pusat data.

Kami juga menghosting beberapa server di pusat data pihak ketiga. Di pusat data ini, kami memastikan bahwa terdapat langkah-langkah keamanan fisik yang dikontrol Google di atas lapisan keamanan yang disediakan oleh operator pusat data. Misalnya, kami mengoperasikan sistem identifikasi biometrik, kamera, dan detektor logam yang terpisah dari lapisan keamanan yang disediakan oleh operator pusat data.

Rancangan dan pembuatan hardware

Pusat data Google terdiri dari ribuan server yang terhubung ke jaringan lokal. Kami merancang server board dan peralatan jaringan. Kami memeriksa dengan cermat vendor komponen yang bekerja sama dengan kami dan memilih komponen dengan hati-hati. Kami bekerja dengan vendor untuk mengaudit dan memvalidasi properti keamanan yang disediakan oleh komponen. Kami juga mendesain chip kustom, termasuk chip keamanan hardware (disebut sebagai Titan), yang kami deploy di server, perangkat, dan periferal. Chip ini memungkinkan kami mengidentifikasi dan mengautentikasi perangkat Google yang sah di tingkat hardware dan berfungsi sebagai root of trust hardware.

Stack booting dan identitas mesin yang aman

Server Google menggunakan berbagai teknologi untuk memastikan bahwa server tersebut mem-booting stack software yang benar. Kami menggunakan tanda tangan kriptografi untuk komponen tingkat rendah seperti Baseboard Management Controller (BMC), BIOS, bootloader, kernel, dan image sistem operasi dasar. Tanda tangan ini dapat divalidasi selama setiap siklus booting atau update. Pemeriksaan integritas pertama untuk server Google menggunakan root of trust hardware. Komponennya dikontrol, dibangun, dan diperkuat dengan proses hardening oleh Google dengan pengesahan integritas. Dengan setiap hardware generasi baru, kami berusaha untuk terus meningkatkan keamanan. Misalnya, tergantung pada generasi desain server, root of trust rantai boot dapat berada di salah satu opsi berikut:

  • Chip hardware Titan
  • Chip firmware yang dapat dikunci
  • Mikrokontroler yang menjalankan kode keamanan kami sendiri

Setiap server di pusat data memiliki identitas uniknya sendiri. Identitas ini dapat dikaitkan dengan root of trust hardware dan software yang di-booting oleh mesin. Identitas ini digunakan untuk mengautentikasi panggilan API ke dan dari layanan pengelolaan tingkat rendah pada mesin. Identitas ini juga digunakan untuk autentikasi server bersama dan enkripsi transport. Kami mengembangkan sistem Application Layer Transport Security (ALTS) untuk mengamankan komunikasi remote procedure call (RPC) dalam infrastruktur kami. Identitas mesin ini dapat dicabut secara terpusat sebagai respons terhadap insiden keamanan. Selain itu, sertifikat dan kunci identitas mesin secara rutin dirotasi, dan yang lama dicabut.

Kami mengembangkan sistem otomatis untuk melakukan hal berikut:

  • Memastikan bahwa server menjalankan stack software versi terbaru mereka (termasuk patch keamanan).
  • Mendeteksi dan mendiagnosis masalah hardware dan software.
  • Memastikan integritas mesin dan periferal dengan booting terverifikasi dan pengesahan implisit.
  • Memastikan hanya mesin yang menjalankan software dan firmware yang diinginkan dapat mengakses kredensial yang memungkinkan mereka berkomunikasi dalam jaringan produksi.
  • Menghapus atau mengalokasikan ulang mesin dari layanan saat tidak diperlukan lagi.

Deployment layanan yang aman

Layanan Google adalah biner aplikasi yang ditulis dan dijalankan oleh developer di infrastruktur kami. Contoh layanan Google adalah server Gmail, database Spanner, server Cloud Storage, transcoder video YouTube, dan VM Compute Engine yang menjalankan aplikasi pelanggan. Untuk menangani skala workload yang diperlukan, ribuan mesin mungkin menjalankan biner layanan yang sama. Layanan orkestrasi cluster, yang disebut sebagai Borg, mengontrol layanan yang berjalan langsung pada infrastruktur.

Infrastruktur tidak mengasumsikan adanya kepercayaan antara layanan yang berjalan di infrastruktur. Model kepercayaan ini disebut sebagai model keamanan zero-trust. Model keamanan zero-trust artinya tidak ada perangkat atau pengguna yang dipercaya secara default, baik mereka berada di dalam maupun di luar jaringan.

Karena infrastruktur dirancang untuk multi-tenant, data dari pelanggan kami (konsumen, bisnis, dan bahkan data kami sendiri) didistribusikan di seluruh infrastruktur bersama. Infrastruktur ini terdiri dari puluhan ribu mesin homogen. Infrastruktur tidak memisahkan data pelanggan ke satu atau serangkaian mesin, kecuali dalam keadaan khusus, seperti saat Anda menggunakan Google Cloud untuk menyediakan VM pada sole-tenant node untuk Compute Engine.

Google Cloud dan Google Workspace mendukung persyaratan peraturan seputar residensi data. Untuk informasi selengkapnya tentang residensi data dan Google Cloud, lihat Menerapkan persyaratan residensi dan kedaulatan data. Untuk informasi selengkapnya tentang residensi data dan Google Workspace, lihat Region data: Memilih lokasi geografis untuk data Anda.

Identitas, integritas, dan isolasi layanan

Untuk mengaktifkan komunikasi antarlayanan, aplikasi menggunakan autentikasi dan otorisasi kriptografi. Autentikasi dan otorisasi menyediakan kontrol akses yang kuat pada tingkat abstraksi dan perincian yang dapat dipahami oleh administrator dan layanan.

Layanan tidak bergantung pada segmentasi jaringan internal atau penggunaan firewall sebagai mekanisme keamanan utama. Pemfilteran traffic masuk dan keluar di berbagai titik dalam jaringan kami membantu mencegah IP spoofing. Pendekatan ini juga membantu kami memaksimalkan kinerja dan ketersediaan jaringan kami. Untuk Google Cloud, Anda dapat menambahkan mekanisme keamanan tambahan seperti Kontrol Layanan VPC dan Cloud Interconnect.

Setiap layanan yang berjalan pada infrastruktur memiliki identitas akun layanan yang terkait. Layanan dilengkapi dengan kredensial kriptografis yang dapat digunakan untuk membuktikan identitasnya ke layanan lain saat membuat atau menerima RPC. Identitas ini digunakan dalam kebijakan keamanan. Kebijakan keamanan memastikan bahwa klien berkomunikasi dengan server yang diinginkan, dan memastikan bahwa server membatasi metode dan data yang dapat diakses oleh klien tertentu.

Kami menggunakan berbagai teknik isolasi dan sandbox untuk membantu melindungi layanan dari layanan lain yang berjalan di mesin yang sama. Teknik ini mencakup pemisah pengguna Linux, sandbox berbasis bahasa (seperti Sandboxed API) dan sandbox berbasis kernel, kernel aplikasi untuk container (seperti gVisor), dan virtualisasi hardware. Secara umum, kami menggunakan lebih banyak lapisan isolasi untuk workload yang lebih berisiko. Workload yang lebih berisiko mencakup item yang disediakan pengguna yang memerlukan pemrosesan tambahan. Misalnya, workload yang lebih berisiko mencakup menjalankan konverter file kompleks pada data yang disediakan pengguna atau menjalankan kode yang disediakan pengguna untuk produk seperti App Engine atau Compute Engine.

Untuk keamanan tambahan, layanan sensitif, seperti layanan orkestrasi cluster dan beberapa key management service, dijalankan secara eksklusif pada mesin khusus.

Di Google Cloud, untuk menyediakan isolasi kriptografi yang lebih kuat untuk workload Anda dan melindungi data aktif, kami mendukung layanan Confidential Computing untuk VM Compute Engine dan node Google Kubernetes Engine (GKE).

Pengelolaan akses antarlayanan

Pemilik layanan dapat menggunakan fitur pengelolaan akses yang disediakan oleh infrastruktur untuk menentukan dengan tepat layanan lain mana yang dapat berkomunikasi dengan layanan tersebut. Misalnya, layanan dapat membatasi RPC masuk hanya ke daftar layanan lain yang diizinkan. Layanan tersebut dapat dikonfigurasi dengan daftar identitas layanan yang diizinkan, dan infrastruktur secara otomatis menerapkan batasan akses ini. Penerapan mencakup logging audit, justifikasi, dan pembatasan akses sepihak (misalnya, untuk permintaan engineer).

Engineer Google yang memerlukan akses ke layanan juga diberi identitas individu. Layanan dapat dikonfigurasi untuk mengizinkan atau menolak akses berdasarkan identitasnya. Semua identitas ini (mesin, layanan, dan karyawan) berada dalam namespace global yang dijaga oleh infrastruktur.

Untuk mengelola identitas ini, infrastruktur menyediakan sistem alur kerja yang mencakup rantai persetujuan, logging, dan notifikasi. Misalnya, kebijakan keamanan dapat menerapkan otorisasi banyak pihak. Sistem ini menggunakan aturan dua orang (two-person rule) untuk memastikan bahwa engineer yang bertindak sendirian tidak dapat menjalankan operasi sensitif tanpa mendapatkan persetujuan terlebih dahulu dari engineer lain yang berwenang. Dengan sistem ini, proses pengelolaan akses yang aman dapat diskalakan hingga mencakup ribuan layanan yang berjalan di infrastruktur.

Infrastruktur juga menyediakan layanan dengan layanan kanonis untuk pengguna, grup, dan pengelolaan keanggotaan, sehingga mereka dapat menerapkan kontrol akses khusus dan terperinci jika diperlukan.

Identitas pengguna akhir dikelola secara terpisah, sebagaimana dijelaskan dalam Pengelolaan akses data pengguna akhir di Google Workspace.

Enkripsi komunikasi antarlayanan

Infrastruktur memberikan kerahasiaan dan integritas untuk data RPC di jaringan. Semua traffic jaringan virtual Google Cloud dienkripsi. Semua komunikasi antara layanan infrastruktur diautentikasi dan sebagian besar komunikasi antar-layanan dienkripsi, yang menambahkan lapisan keamanan tambahan untuk membantu mengamankan komunikasi bahkan jika jaringan disadap atau perangkat jaringan disusupi. Pengecualian terhadap persyaratan enkripsi untuk komunikasi antar-layanan hanya diberikan untuk traffic yang memiliki persyaratan latensi rendah, dan tidak meninggalkan satu pun fabric jaringan dalam beberapa lapisan keamanan fisik di pusat data kami.

Infrastruktur secara otomatis dan efisien (dengan bantuan pengurangan beban hardware) menyediakan enkripsi end-to-end untuk traffic RPC infrastruktur yang melewati jaringan di antara pusat data.

Pengelolaan akses data pengguna akhir di Google Workspace

Layanan umum dari Google Workspace ditulis untuk melakukan suatu tindakan untuk pengguna akhir. Misalnya, pengguna akhir dapat menyimpan email mereka di Gmail. Interaksi pengguna akhir dengan aplikasi seperti Gmail mungkin melibatkan layanan lain dalam infrastruktur. Misalnya, Gmail mungkin memanggil People API untuk mengakses buku alamat pengguna akhir.

Bagian Enkripsi komunikasi antarlayanan menjelaskan cara layanan (seperti Google Kontak) dirancang untuk melindungi permintaan RPC dari layanan lain (seperti Gmail). Namun, tingkat kontrol akses ini masih berupa serangkaian izin yang luas karena Gmail dapat meminta kontak pengguna mana pun kapan saja.

Saat Gmail membuat permintaan RPC ke Google Kontak atas nama pengguna akhir, infrastruktur memungkinkan Gmail menyertakan tiket izin pengguna akhir dalam permintaan RPC. Tiket ini membuktikan bahwa Gmail membuat permintaan RPC atas nama pengguna akhir tersebut. Tiket memungkinkan Google Kontak menerapkan pengamanan sehingga tiket hanya menampilkan data untuk pengguna akhir yang disebutkan dalam tiket tersebut.

Infrastruktur ini menyediakan layanan identitas pengguna terpusat yang menerbitkan tiket konteks pengguna akhir. Layanan identitas memverifikasi login pengguna akhir, lalu menerbitkan kredensial pengguna, seperti cookie atau token OAuth, ke perangkat pengguna. Setiap permintaan berikutnya dari perangkat ke infrastruktur kami harus menunjukkan kredensial pengguna akhir tersebut.

Saat menerima kredensial pengguna akhir, layanan tersebut akan meneruskan kredensial tersebut ke layanan identitas untuk diverifikasi. Jika kredensial pengguna akhir diverifikasi, layanan identitas akan menampilkan tiket konteks pengguna akhir yang berlaku singkat yang dapat digunakan untuk RPC yang terkait dengan permintaan pengguna. Dalam contoh kami, layanan yang mendapatkan tiket konteks pengguna akhir adalah Gmail, yang meneruskan tiket tersebut ke Google Kontak. Sejak saat itu, untuk setiap panggilan beruntun, layanan yang memanggil dapat mengirimkan tiket konteks pengguna akhir ke tujuan panggilan sebagai bagian dari RPC.

Diagram berikut menunjukkan cara Layanan A dan Layanan B berkomunikasi. Infrastruktur tersebut menyediakan identitas layanan, autentikasi bersama secara otomatis, komunikasi antarlayanan yang terenkripsi, dan penerapan kebijakan akses yang ditentukan oleh pemilik layanan. Setiap layanan memiliki konfigurasi keamanan, yang dibuat oleh pemilik layanan. Untuk komunikasi antarlayanan yang terenkripsi, autentikasi bersama secara otomatis menggunakan identitas penelepon dan tujuan panggilan. Komunikasi hanya dapat terjadi jika konfigurasi aturan akses mengizinkannya.

Diagram yang menunjukkan cara Layanan A dan Layanan B berkomunikasi.

Untuk informasi tentang pengelolaan akses di Google Cloud, lihat Ringkasan IAM.

Pengelolaan akses data pengguna akhir di Google Cloud

Mirip dengan Pengelolaan akses data pengguna akhir di Google Workspace, infrastruktur ini menyediakan layanan identitas pengguna terpusat yang mengautentikasi akun layanan dan mengeluarkan tiket konteks pengguna akhir setelah akun layanan diautentikasi. Pengelolaan akses antara layanan Google Cloud biasanya dilakukan dengan agen layanan, bukan menggunakan tiket konteks pengguna akhir.

Google Cloud menggunakan Identity and Access Management (IAM) dan produk kontekstual, seperti Identity-Aware Proxy, agar Anda dapat mengelola akses ke resource di organisasi Google Cloud Anda. Semua permintaan ke layanan Google Cloud melewati IAM untuk memverifikasi izin.

Proses pengelolaan akses adalah sebagai berikut:

  1. Permintaan masuk melalui layanan Google Front End (GFE) atau layanan Cloud Front End untuk VM pelanggan.
  2. Permintaan diarahkan ke layanan identitas pengguna pusat yang menyelesaikan pemeriksaan autentikasi dan mengeluarkan tiket konteks pengguna akhir.
  3. Permintaan juga diarahkan untuk memeriksa item seperti berikut:
  4. Setelah semua pemeriksaan ini lulus, layanan backend Google Cloud dipanggil.Permintaan diarahkan ke layanan identitas pengguna pusat yang menyelesaikan pemeriksaan autentikasi dan mengeluarkan tiket konteks pengguna akhir.

Untuk informasi tentang pengelolaan akses di Google Cloud, lihat ringkasan IAM.

Penyimpanan data yang aman

Bagian ini menjelaskan cara kami menerapkan keamanan untuk data yang disimpan di infrastruktur.

Enkripsi dalam penyimpanan

Infrastruktur Google menyediakan berbagai layanan penyimpanan dan sistem file terdistribusi (misalnya, Spanner dan Colossus), serta key management service terpusat. Aplikasi di Google mengakses penyimpanan fisik dengan menggunakan infrastruktur penyimpanan. Kami menggunakan beberapa lapisan enkripsi untuk melindungi data dalam penyimpanan. Secara default, infrastruktur penyimpanan mengenkripsi semua data pengguna sebelum ditulis ke penyimpanan fisik.

Infrastruktur tersebut melakukan enkripsi pada lapisan aplikasi atau lapisan infrastruktur penyimpanan. Enkripsi memungkinkan infrastruktur mengisolasi dirinya dari potensi ancaman pada tingkat penyimpanan yang lebih rendah, seperti firmware disk berbahaya. Jika memungkinkan, kami juga mengaktifkan dukungan enkripsi hardware di hard drive dan SSD kami, serta melacak setiap drive dengan cermat melalui siklus prosesnya. Sebelum perangkat penyimpanan terenkripsi yang sudah tidak digunakan meninggalkan kendali kami, perangkat tersebut dibersihkan melalui proses bertahap dengan dua verifikasi independen. Perangkat yang tidak lulus proses pembersihan ini akan dihancurkan secara fisik (yaitu, dibelah) di lokal.

Selain enkripsi yang dilakukan oleh infrastruktur, Google Cloud dan Google Workspace menyediakan key management service. Untuk Google Cloud, Cloud KMS adalah layanan cloud yang dapat digunakan pelanggan untuk mengelola kunci kriptografis. Untuk Google Workspace, Anda dapat menggunakan enkripsi sisi klien. Untuk informasi selengkapnya, lihat Enkripsi sisi klien dan kolaborasi yang diperkuat di Google Workspace.

Penghapusan data

Penghapusan data biasanya dimulai dengan menandai data tertentu sebagai dijadwalkan untuk dihapus, bukan benar-benar menghapus data. Pendekatan ini memungkinkan kami melakukan pemulihan dari penghapusan yang tidak disengaja, baik yang dimulai oleh pelanggan, disebabkan oleh bug, atau akibat dari error proses internal. Setelah ditandai sebagai dijadwalkan untuk dihapus, data akan dihapus sesuai dengan kebijakan spesifik layanan.

Saat pengguna akhir menghapus akunnya, infrastruktur akan memberi tahu layanan yang menangani data pengguna akhir bahwa akun tersebut telah dihapus. Selanjutnya, layanan dapat menjadwalkan penghapusan data yang terkait dengan akun pengguna akhir yang dihapus. Fitur ini memungkinkan pengguna akhir mengontrol datanya sendiri.

Untuk informasi selengkapnya, lihat Penghapusan data di Google Cloud.

Komunikasi internet yang aman

Bagian ini menjelaskan cara kami mengamankan komunikasi antara internet dan layanan yang berjalan di infrastruktur Google.

Seperti yang dibahas dalam Rancangan dan pembuatan hardware, infrastruktur terdiri dari banyak mesin fisik yang saling terhubung melalui LAN dan WAN. Keamanan komunikasi antarlayanan tidak bergantung pada keamanan jaringan. Namun, kami mengisolasi infrastruktur kami dari internet ke dalam ruang alamat IP pribadi. Kami hanya mengekspos sejumlah kecil mesin secara langsung ke traffic internet eksternal sehingga kami dapat menerapkan perlindungan tambahan seperti pertahanan terhadap serangan denial of service (DoS).

Layanan Google Front End

Ketika sebuah layanan harus menjadi tersedia di internet, layanan tersebut dapat mendaftarkan dirinya dengan layanan infrastruktur yang disebut sebagai Google Front End (GFE). GFE memastikan bahwa semua koneksi TLS dihentikan dengan sertifikat yang benar dan dengan mengikuti praktik terbaik seperti mendukung forward secrecy yang sempurna. GFE juga menerapkan perlindungan terhadap serangan DoS. Kemudian, GFE meneruskan permintaan layanan menggunakan protokol keamanan RPC yang dibahas dalam Pengelolaan akses data pengguna akhir di Google Workspace.

Dengan demikian, setiap layanan internal yang harus melakukan publikasi sendiri secara eksternal akan menggunakan GFE sebagai frontend reverse proxy cerdas. GFE menyediakan hosting alamat IP publik untuk nama DNS publiknya, perlindungan DoS, dan TLS termination. GFE berjalan di infrastruktur seperti layanan lainnya dan dapat diskalakan agar sesuai dengan volume permintaan masuk.

VM Pelanggan di Google Cloud tidak terdaftar di GFE. Sebagai gantinya, mereka mendaftar ke Cloud Front End, yang merupakan konfigurasi khusus GFE yang menggunakan stack jaringan Compute Engine. Dengan Cloud Front End, VM pelanggan dapat mengakses layanan Google secara langsung menggunakan alamat IP publik atau pribadi mereka. (Alamat IP pribadi hanya tersedia jika Akses Google Pribadi diaktifkan.)

Perlindungan terhadap DoS

Skala infrastruktur kami memungkinkannya untuk menangani banyak serangan DoS. Untuk lebih mengurangi risiko dampak DoS terhadap layanan, kami memiliki perlindungan DoS multi-tingkat dan multi-lapisan.

Saat backbone serat optik mengirimkan koneksi eksternal ke salah satu pusat data, koneksi tersebut akan melewati beberapa lapisan load balancer hardware dan software. Load balancer ini melaporkan informasi tentang traffic yang masuk ke layanan DoS pusat yang berjalan di infrastruktur. Saat layanan DoS pusat mendeteksi serangan DoS, layanan dapat mengonfigurasi load balancer untuk menurunkan atau membatasi traffic yang terkait dengan serangan tersebut.

Instance GFE juga melaporkan informasi tentang permintaan yang diterima ke layanan DoS pusat, termasuk informasi lapisan aplikasi yang tidak dapat diakses oleh load balancer. Layanan DoS pusat kemudian dapat mengonfigurasi instance GFE untuk menurunkan atau membatasi traffic serangan.

Autentikasi pengguna

Setelah perlindungan DoS, lapisan pertahanan berikutnya untuk komunikasi yang aman berasal dari layanan identitas pusat. Pengguna akhir berinteraksi dengan layanan ini melalui halaman login Google. Layanan ini meminta nama pengguna dan sandi, serta dapat meminta informasi tambahan berdasarkan faktor risiko. Contoh faktor risiko mencakup apakah pengguna pernah login dari perangkat atau dari lokasi yang sama sebelumnya. Setelah mengautentikasi pengguna, layanan identitas mengeluarkan kredensial seperti cookie dan token OAuth yang dapat digunakan untuk panggilan berikutnya.

Saat pengguna login, mereka dapat menggunakan faktor kedua seperti OTP atau kunci keamanan yang tahan terhadap ancaman phishing, seperti Kunci Keamanan Titan. Kunci Keamanan Titan adalah token fisik yang mendukung FIDO Universal 2nd Factor (U2F). Kami membantu mengembangkan standar terbuka U2F dengan FIDO Alliance. Sebagian besar platform web dan browser telah mengadopsi standar autentikasi terbuka ini.

Keamanan operasional

Bagian ini menjelaskan pengembangan software infrastruktur, perlindungan mesin dan kredensial karyawan, serta pertahanan terhadap ancaman baik dari pelaku internal maupun eksternal terhadap infrastruktur.

Pengembangan software yang aman

Selain perlindungan kontrol sumber dan proses peninjauan dua pihak yang dijelaskan sebelumnya, kami menggunakan library yang mencegah developer memasukkan class bug keamanan tertentu. Misalnya, kami memiliki library dan framework yang membantu menghilangkan kerentanan XSS di aplikasi web. Kami juga menggunakan alat otomatis seperti fuzzer, alat analisis statis, dan pemindai keamanan web untuk mendeteksi bug keamanan secara otomatis.

Sebagai langkah pemeriksaan terakhir, kami melakukan tinjauan keamanan manual yang melibatkan triase cepat untuk fitur yang kurang berisiko hingga tinjauan desain dan implementasi mendalam untuk fitur yang paling berisiko. Tim yang melakukan tinjauan ini termasuk para ahli keamanan web, kriptografi, dan keamanan sistem operasi. Peninjauan tersebut dapat mengarah pada pengembangan fitur library keamanan baru dan fuzzer baru yang dapat kami gunakan untuk produk mendatang.

Selain itu, kami menjalankan Vulnerability Reward Program yang memberikan reward kepada siapa pun yang menemukan dan memberi tahu kami tentang bug di infrastruktur atau aplikasi kami. Untuk informasi selengkapnya tentang program ini, termasuk reward yang telah kami berikan, lihat Statistik utama Bug hunter.

Kami juga berinvestasi dalam menemukan eksploitasi zero-day dan masalah keamanan lainnya dalam software open source yang kami gunakan. Kami menjalankan Project Zero, yang merupakan Tim Riset Google yang berdedikasi untuk meneliti kerentanan zero-day, termasuk Spectre dan Meltdown. Selain itu, kami adalah pengirim CVE dan perbaikan bug keamanan terbesar untuk hypervisor Linux KVM.

Perlindungan kode sumber

Kode sumber kami disimpan dalam repositori dengan integritas dan tata kelola sumber bawaan, tempat versi layanan saat ini dan versi lama dapat diaudit. Infrastruktur ini mengharuskan biner layanan di-build dari kode sumber tertentu setelah ditinjau, di-check in, dan diuji. Otorisasi Biner untuk Borg (BAB) adalah pemeriksaan penerapan internal yang terjadi saat layanan di-deploy. BAB melakukan hal berikut:

  • Memastikan konfigurasi dan software produksi yang di-deploy di Google ditinjau dan diotorisasi, terutama saat kode tersebut dapat mengakses data pengguna.
  • Memastikan deployment kode dan konfigurasi memenuhi standar minimum tertentu.
  • Membatasi kemampuan orang dalam atau penyerang untuk melakukan modifikasi berbahaya pada kode sumber dan juga menyediakan jejak forensik dari layanan kembali ke sumbernya.

Menjaga keamanan perangkat dan kredensial karyawan

Kami menerapkan pengamanan untuk membantu melindungi perangkat dan kredensial karyawan kami dari penyusupan. Untuk membantu melindungi karyawan kami dari upaya phishing yang canggih, kami telah mengganti autentikasi faktor kedua OTP dengan penggunaan wajib kunci keamanan yang kompatibel dengan U2F.

Kami memantau perangkat klien yang digunakan karyawan untuk mengoperasikan infrastruktur kami. Kami memastikan bahwa image sistem operasi untuk perangkat ini sudah diperbarui dengan patch keamanan dan kami mengontrol aplikasi yang dapat diinstal karyawan di perangkat mereka. Kami juga memiliki sistem yang memindai aplikasi, download, ekstensi browser, dan konten browser web yang diinstal pengguna untuk menentukan apakah aplikasi tersebut cocok untuk perangkat perusahaan.

Terhubung ke LAN perusahaan bukanlah mekanisme utama kami untuk memberikan hak istimewa akses. Sebagai gantinya, kami menggunakan keamanan zero-trust untuk membantu melindungi akses karyawan ke resource kami. Kontrol pengelolaan akses di tingkat aplikasi mengekspos aplikasi internal kepada karyawan hanya ketika karyawan menggunakan perangkat terkelola dan terhubung dari jaringan dan lokasi geografis yang diharapkan. Perangkat klien dipercaya berdasarkan sertifikat yang dikeluarkan untuk setiap mesin, dan berdasarkan pernyataan tentang konfigurasinya (seperti software terbaru). Untuk informasi selengkapnya, lihat BeyondCorp.

Mengurangi risiko pihak internal

Risiko orang dalam adalah potensi dari karyawan, mantan karyawan, kontraktor, atau partner bisnis lainnya yang memiliki atau pernah memiliki akses sah ke jaringan, sistem, atau data kami untuk menyalahgunakan akses tersebut dan merugikan kerahasiaan, integritas, atau ketersediaan informasi atau sistem informasi kami.

Untuk membantu mengurangi risiko pihak internal, kami membatasi dan secara aktif memantau aktivitas karyawan yang telah diberi akses administratif ke infrastruktur. Kami terus berupaya meniadakan kebutuhan akses hak istimewa untuk tugas tertentu dengan menggunakan otomatisasi yang dapat menyelesaikan tugas yang sama secara aman dan terkontrol. Kami mengekspos API terbatas yang memungkinkan proses debug tanpa mengekspos data sensitif, dan kami memerlukan persetujuan dua pihak untuk tindakan sensitif tertentu yang dilakukan oleh operator manusia.

Akses karyawan Google ke informasi pengguna akhir dapat dicatat dalam log melalui hook infrastruktur tingkat rendah. Tim keamanan kami memantau pola akses dan menyelidiki peristiwa yang tidak biasa. Untuk informasi selengkapnya, lihat Pengelolaan Akses dengan Hak Istimewa di Google Cloud (PDF).

Kami menggunakan otorisasi biner untuk Borg guna membantu melindungi supply chain kami dari risiko pihak internal. Selain itu, investasi kami dalam BeyondProd membantu melindungi data pengguna di infrastruktur Google dan membangun kepercayaan pada layanan kami.

Di Google Cloud, Anda dapat memantau akses ke data Anda menggunakan Transparansi Akses. Log Transparansi Akses memungkinkan Anda memverifikasi bahwa personel Google mengakses konten Anda hanya untuk alasan bisnis yang valid, seperti memperbaiki pemadaman layanan atau memenuhi permintaan dukungan Anda. Persetujuan Akses memastikan bahwa Cloud Customer Care dan engineering memerlukan persetujuan eksplisit Anda setiap kali mereka perlu mengakses data Anda. Persetujuan diverifikasi secara kriptografis untuk memastikan integritas persetujuan akses.

Pemantauan ancaman

Grup Analisis Ancaman di Google memantau pelaku ancaman serta evolusi taktik dan tekniknya. Tujuan grup ini adalah membantu meningkatkan keselamatan dan keamanan produk Google serta berbagi kecerdasan ini untuk kepentingan komunitas online.

Untuk Google Cloud, Anda dapat menggunakan Google Cloud Threat Intelligence for Chronicle dan VirusTotal untuk memantau dan merespons berbagai jenis malware. Google Cloud Threat Intelligence for Chronicle adalah tim peneliti ancaman yang mengembangkan kecerdasan ancaman untuk digunakan dengan Chronicle. VirusTotal adalah solusi visualisasi dan database malware yang dapat Anda gunakan untuk lebih memahami cara malware beroperasi dalam perusahaan Anda.

Untuk informasi selengkapnya tentang aktivitas pemantauan ancaman kami, lihat laporan Horizon Ancaman.

Deteksi penyusupan

Kami menggunakan pipeline pemrosesan data canggih untuk mengintegrasikan sinyal berbasis host pada perangkat individu, sinyal berbasis jaringan dari berbagai titik pemantauan dalam infrastruktur, dan sinyal dari layanan infrastruktur. Aturan dan kecerdasan mesin yang dibangun di atas pipeline ini memberikan peringatan kepada engineer keamanan operasional tentang kemungkinan terjadinya insiden. Tim investigasi dan respons insiden kami melakukan triase, menginvestigasi, dan merespons potensi insiden ini 24 jam sehari, 365 hari setahun. Kami melakukan penilaian Red Team guna mengukur dan meningkatkan efektivitas mekanisme deteksi dan respons kami.

Langkah selanjutnya