Kontrol untuk membatasi akses ke API yang disetujui satu per satu

Last reviewed 2024-02-06 UTC

Banyak organisasi memiliki persyaratan kepatuhan untuk membatasi akses jaringan ke daftar API yang disetujui secara eksplisit, berdasarkan persyaratan internal atau sebagai bagian dari penerapan Assured Workloads. Secara lokal, persyaratan ini sering kali diatasi dengan kontrol proxy, tetapi di Virtual Private Cloud (VPC) Google, Anda dapat mengatasi persyaratan ini dengan Penggunaan Layanan Sumber Batasan Kebijakan Organisasi. Kebijakan ini memungkinkan administrator menentukan yang sumber Google Cloud dapat dibuat dalam hierarki resource-nya, namun untuk menggunakan Kebijakan Organisasi ini secara efektif, Anda harus menyelaraskan berbagai kontrol jaringan di lingkungan Anda.

Dokumen ini menjelaskan cara membatasi akses ke Google API yang disetujui secara individual menggunakan Layanan Kebijakan Organisasi dan kontrol jaringan lainnya, serta tantangan dalam menerapkan pendekatan berbasis proxy lokal untuk layanan Google Cloud. Dokumen ini ditujukan untuk administrator jaringan atau tim keamanan yang ingin membatasi Google Cloud API yang dapat dijangkau dari endpoint jaringan VPC mereka.

Tantangan terkait proxy untuk kontrol akses ke Google API

Dalam jaringan lokal, perusahaan Anda mungkin memiliki persyaratan kepatuhan untuk mengizinkan traffic keluar hanya ke layanan dan domain yang disetujui. Persyaratan ini dapat diterapkan dengan memfilter traffic keluar melalui proxy web atau gateway akses aman. Proxy ini menghadang semua traffic keluar dan mengizinkan traffic keluar hanya ke API yang disetujui secara eksplisit.

Di beberapa perusahaan, Anda mungkin juga memiliki persyaratan kepatuhan untuk membatasi akses dari jaringan VPC Anda ke Google Cloud API yang disetujui. Kontrol kepatuhan ini sering terlihat dalam skenario berikut:

  • Sebuah perusahaan menggunakan Assured Workloads untuk workload sensitif dan kontrol kepatuhan.
  • Perusahaan memiliki persyaratan kepatuhan internal bahwa endpoint jaringan di Google Cloud hanya diizinkan untuk mengakses Google Cloud API yang disetujui melalui proses internal.
  • Sebuah perusahaan ingin memigrasikan workload Infrastructure as a Service (IaaS) ke Google Cloud dengan pemfaktoran ulang yang minimal.
  • Perusahaan belum mengembangkan kontrol untuk cloud dan lebih memilih untuk memperluas kontrol yang ada dari lingkungan lokal.

Meskipun perusahaan Anda mungkin menggunakan proxy web untuk mengontrol traffic keluar dari jaringan lokal ke layanan web, kami tidak merekomendasikan pendekatan ini untuk mengontrol akses dari jaringan VPC Anda ke Google Cloud APIs. Penggunaan pendekatan proxy ini menimbulkan masalah skalabilitas, menciptakan satu titik kegagalan, dan tidak mengatasi risiko pemindahan data yang tidak sah menggunakan Google Cloud API.

Sebaiknya gunakan Kebijakan Organisasi Batasi Penggunaan Layanan Resource, bukan proxy, untuk mengizinkan akses ke setiap Google Cloud API secara selektif. Tantangan yang terkait dengan membangun dan memelihara proxy web untuk kontrol akses ke setiap Google API dibahas di bagian berikut.

Rentang alamat IP bersama yang digunakan oleh beberapa Google API

Anda tidak dapat mengontrol akses ke Google API individual berdasarkan aturan proxy atau firewall yang memfilter ke satu alamat IP. Google menggunakan rentang alamat IP dinamis untuk domain default. Dalam alamat IP ini, tidak ada hubungan one-to-one antara alamat IP khusus dan API tertentu.

Domain bersama yang digunakan oleh Google API

Untuk beberapa Google API, Anda tidak dapat mengontrol akses jaringan dengan memfilter traffic di domain. Sebagian besar Google API dapat dijangkau di endpoint yang membedakan API tertentu berdasarkan jalur dan dimulai dengan URI yang diawali dengan www.googleapis.com. Google API tertentu juga menggunakan endpoint dengan subdomain khusus. Misalnya, referensi Cloud Storage API mendokumentasikan URI yang berkaitan dengan storage.googleapis.com/storage/v1 endpoint, tetapi Anda juga dapat menggunakan URI yang dimulai dengan www.googleapis.com/storage/v1 untuk memanggil metode API yang sama.

Jika Anda menggunakan beberapa API yang hanya memiliki endpoint di domain www.googleapis.com, proxy traffic keluar tidak dapat membedakan berbagai API yang hanya didasarkan pada domain tersebut. Misalnya, beberapa API Google Cloud seperti Deployment Manager, dan Google API lainnya, seperti Tag Manager atau Google Play Game, hanya dapat diakses di domainwww.googleapis.com. Selain itu, semua Google Cloud API menggunakan enkripsi TLS secara default. Jika Anda ingin mengizinkan salah satu API ini tetapi memblokir yang lainnya, proxy harus mendekripsi permintaan untuk memfilter jalur URI, sehingga meningkatkan kompleksitas.

Kesulitan yang disebabkan oleh proxy

Jika semua traffic dari jaringan VPC Anda ke Google API harus melalui proxy traffic keluar, proxy tersebut dapat menjadi bottleneck. Jika Anda menggunakan proxy egress untuk traffic dari jaringan VPC Anda ke Google API, sebaiknya Anda membangun proxy untuk ketersediaan tinggi guna menghindari gangguan layanan. Mempertahankan dan menskalakan proxy dapat menjadi hal yang rumit karena seiring dengan pertumbuhan organisasi, proxy dapat menimbulkan satu titik kegagalan, latensi, dan penurunan throughput. Mungkin ada dampak tertentu pada operasi yang mentransfer data dalam jumlah besar.

Risiko pemindahan yang tidak sah dari layanan ke layanan

Proxy web dapat membatasi apakah Google API dapat dijangkau dari jaringan VPC Anda, tetapi tidak mengatasi jalur pemindahan yang tidak sah lain yang menggunakan Google API. Misalnya, karyawan di perusahaan Anda mungkin memiliki hak istimewa IAM yang sah untuk membaca bucket Cloud Storage internal. With this privilege, they could read internal data and then copy that data to a public bucket. Dengan hak istimewa ini, mereka dapat membaca data internal lalu menyalin data tersebut ke bucket publik. Proxy traffic keluar tidak dapat membatasi traffic API ke API yang tidak berasal dari VPC Anda, atau mengontrol cara traffic internet mencapai endpoint publik untuk Google Cloud API.

Untuk data sensitif, perimeter Kontrol Layanan VPC membantu mengurangi jenis pemindahan yang tidak sah ini. Menerapkan perimeter Kontrol Layanan VPC membantu melindungi resource di dalam perimeter dari kebijakan IAM yang salah dikonfigurasi, pemindahan yang tidak sah, dan kredensial yang disusupi.

Mengonfigurasi kontrol jaringan untuk membatasi layanan yang tidak disetujui

Saat menggunakan Kebijakan Organisasi Batasi Penggunaan Layanan Resource, untuk membatasi akses ke layanan secara efektif, Anda harus mempertimbangkan cara jaringan VPC Anda membatasi traffic keluar dan jalur pemindahan yang tidak sah. Bagian berikut menjelaskan praktik terbaik untuk desain jaringan agar dapat menggunakan menggunakan Kebijakan Organisasi Batasi Penggunaan Layanan Resource secara efektif.

Mengonfigurasi Kontrol Layanan VPC

Saat menggunakan Kebijakan Organisasi Batasi Penggunaan Layanan Resource, kami menyarankan agar Anda juga mengonfigurasi Kontrol Layanan VPC. Dengan menerapkan Kebijakan Organisasi dalam sebuah project, Anda membatasi layanan yang dapat digunakan dalam project tersebut, tetapi Kebijakan Organisasi tidak mencegah layanan dalam project ini berkomunikasi dengan layanan dalam project lain. Sebagai perbandingan, Kontrol Layanan VPC memungkinkan Anda menentukan perimeter untuk mencegah komunikasi dengan layanan di luar perimeter.

Misalnya, jika Anda menentukan Kebijakan Organisasi untuk mengizinkan Compute Engine dan menolak Cloud Storage dalam project Anda, VM dalam project ini tidak dapat membuat atau berkomunikasi dengan bucket Cloud Storage dalam project Anda. Namun, VM dapat membuat permintaan ke bucket Cloud Storage di project lain, sehingga pemindahan yang tidak sah dengan layanan Cloud Storage masih dapat dilakukan. Untuk memblokir komunikasi dengan Cloud Storage atau layanan Google lainnya di luar perimeter, Anda harus mengonfigurasi perimeter Kontrol Layanan VPC.

Gunakan kontrol ini bersama-sama untuk mengizinkan layanan yang disetujui secara selektif di lingkungan Anda dan memblokir berbagai jalur pemin dahan yang tidak sah ke layanan yang tidak disetujui.

Menghapus jalur ke internet

Jika resource di jaringan VPC Anda dapat berkomunikasi langsung ke internet, mungkin ada jalur alternatif ke Google API yang tidak disetujui dan layanan lain yang ingin Anda blokir. Oleh karena itu, sebaiknya Anda hanya menggunakan alamat IP internal di VM dan jangan mengizinkan rute traffic keluar melalui solusi NAT atau proxy. Kebijakan Organisasi Batasi Penggunaan Resource Service Usage tidak mengurangi jalur pemindahan yang tidak sah ke internet publik, sehingga layanan yang tidak disetujui masih dapat diakses secara tidak langsung dari server di luar lingkungan Anda.

Mengonfigurasi endpoint pribadi untuk akses API

Untuk mengontrol endpoint API di jaringan Anda, sebaiknya akses Google API menggunakan Private Service Connect. Saat Anda mengonfigurasi Akses Google Pribadi untuk mengizinkan VM dengan hanya IP internal agar dapat mengakses Google API, ini termasuk akses ke semua Google API, termasuk yang tidak didukung oleh Kontrol Layanan VPC atau Kebijakan Organisasi Batasi Penggunaan Anda dapat membatasi Akses Google Pribadi hanya ke API yang didukung dengan mengonfigurasi juga Private Service Connect dengan paket vpc-sc.

Misalnya, mengaktifkan Akses Google Pribadi akan mengizinkan jalur jaringan pribadi ke semua Google API, seperti Google Drive atau Google Maps Platform. Seorang karyawan dapat menyalin data ke Google Drive pribadinya dari instance Compute Engine menggunakan API Google Drive. Anda dapat mencegah jalur pemindahan yang tidak sah ini dengan mengonfigurasi Private Service Connect denganvpc-sc paket untuk memberikan akses ke kumpulanlayanan yang didukung oleh IP virtual (VIP) terbatas di endpoint restricted.googleapis.com. Sebagai perbandingan, kumpulan Google API yang lebih luas dapat dicapai menggunakan Akses Google Pribadi saat Anda menggunakan domain default Google, endpoint Private Service Connect yang dikonfigurasi dengan all-apis, atau VIP pribadi (private.googleapis.com).

Atau, Anda dapat mengonfigurasi rute ke restricted.googleapis.com. Anda dapat memilih untuk menggunakan VIP yang dibatasi jika tidak ingin membuat endpoint Private Service Connect untuk setiap region dan setiap jaringan VPC di lingkungan Anda. Namun, sebaiknya gunakan pendekatan Private Service Connect karena Anda dapat membuat endpoint internal ke jaringan VPC, dibandingkan dengan pendekatan VIP terbatas yang memerlukan rute ke endpoint yang diumumkan secara publik.

Langkah berikutnya