Traffic keluar dengan akses terbatas

Last reviewed 2023-12-14 UTC

Arsitektur pola jaringan traffic keluar dengan akses terbatas didasarkan pada mengekspos API tertentu dari lingkungan lokal atau lingkungan cloud lain ke workload yang di-deploy di Google Cloud. Hal ini dilakukan tanpa mengeksposnya secara langsung ke internet publik dari lingkungan lokal atau dari lingkungan cloud lainnya. Anda dapat memfasilitasi eksposur terbatas ini melalui gateway atau proxy API, atau load balancer yang berfungsi sebagai facade untuk workload yang ada. Anda dapat men-deploy fungsi gateway API di segmen jaringan perimeter yang terisolasi, seperti jaringan perimeter.

Pola jaringan eksekusi terkontrol terutama berlaku untuk (tetapi tidak terbatas pada) pola arsitektur aplikasi bertingkat dan pola arsitektur aplikasi yang dipartisi. Saat men-deploy workload backend dalam jaringan internal, jaringan egress yang dibatasi membantu mempertahankan tingkat keamanan yang lebih tinggi dalam lingkungan komputasi lokal Anda. Pola ini mengharuskan Anda menghubungkan lingkungan komputasi dengan cara yang memenuhi persyaratan komunikasi berikut:

  • Workload yang Anda deploy di Google Cloud dapat berkomunikasi dengan gateway API atau load balancer (atau endpoint Private Service Connect) yang mengekspos aplikasi menggunakan alamat IP internal.
  • Sistem lain di lingkungan komputasi pribadi tidak dapat dijangkau secara langsung dari dalam Google Cloud.
  • Komunikasi dari lingkungan komputasi pribadi ke workload apa pun yang di-deploy di Google Cloud tidak diizinkan.
  • Traffic ke API pribadi di lingkungan lain hanya dimulai dari dalam lingkungan Google Cloud.

Fokus panduan ini adalah pada lingkungan hybrid dan multicloud yang terhubung melalui jaringan hybrid pribadi. Jika persyaratan keamanan organisasi Anda mengizinkannya, panggilan API ke API target jarak jauh dengan alamat IP publik dapat dijangkau langsung melalui internet. Namun, Anda harus mempertimbangkan mekanisme keamanan berikut:

  • API OAuth 2.0 dengan Transport Layer Security (TLS).
  • Pembatasan kapasitas.
  • Kebijakan perlindungan terhadap ancaman.
  • TLS bersama yang dikonfigurasi ke backend lapisan API Anda.
  • Pemfilteran daftar yang diizinkan alamat IP dikonfigurasi untuk hanya mengizinkan komunikasi dengan sumber dan tujuan API yang telah ditentukan dari kedua sisi.

Untuk mengamankan proxy API, pertimbangkan aspek keamanan lainnya ini. Untuk informasi selengkapnya, lihat Praktik terbaik untuk mengamankan aplikasi dan API Anda menggunakan Apigee.

Arsitektur

Diagram berikut menunjukkan arsitektur referensi yang mendukung persyaratan komunikasi yang tercantum di bagian sebelumnya:

Data mengalir dalam satu arah dari project host di Google Cloud ke workload di lingkungan lokal.

Data mengalir melalui diagram sebelumnya sebagai berikut:

  • Di sisi Google Cloud, Anda dapat men-deploy workload ke dalam virtual private cloud (VPC). VPC dapat berupa satu atau beberapa (bersama atau tidak bersama). Deployment harus selaras dengan project dan desain hierarki resource organisasi Anda.
  • Jaringan VPC dari lingkungan Google Cloud diperluas ke lingkungan komputasi lainnya. Lingkungan dapat berada di lokal atau di cloud lain. Untuk memfasilitasi komunikasi antar-lingkungan menggunakan alamat IP internal, gunakan konektivitas jaringan hybrid dan multicloud yang sesuai.
  • Untuk membatasi traffic yang berasal dari alamat IP VPC tertentu, dan ditujukan untuk gateway jarak jauh atau load balancer, gunakan pemfilteran daftar yang diizinkan alamat IP. Traffic return dari koneksi ini diizinkan saat menggunakan aturan firewall stateful. Anda dapat menggunakan kombinasi kemampuan berikut untuk mengamankan dan membatasi komunikasi hanya ke alamat IP sumber dan tujuan yang diizinkan:

  • Semua lingkungan menggunakan ruang alamat IP RFC 1918 yang bebas tumpang-tindih.

Variasi

Pola arsitektur eksekusi terkontrol dapat digabungkan dengan pendekatan lain untuk memenuhi persyaratan desain yang berbeda yang masih mempertimbangkan persyaratan komunikasi pola ini. Pola ini menawarkan opsi berikut:

Menggunakan gateway Google Cloud API dan frontend global

Data yang mengalir di Google Cloud dari Apigee ke VPC project pelanggan, lalu keluar dari Cloud ke lingkungan lokal atau instance cloud lainnya.

Dengan pendekatan desain ini, eksposur dan pengelolaan API berada dalam Google Cloud. Seperti yang ditunjukkan pada diagram sebelumnya, Anda dapat melakukannya melalui penerapan Apigee sebagai platform API. Keputusan untuk men-deploy gateway API atau load balancer di lingkungan jarak jauh bergantung pada kebutuhan spesifik dan konfigurasi saat ini. Apigee menyediakan dua opsi untuk menyediakan konektivitas:

  • Dengan peering VPC
  • Tanpa peering VPC

Kemampuan frontend global Google Cloud seperti Cloud Load Balancing, Cloud CDN (saat diakses melalui Cloud Interconnect), dan Cross-Cloud Interconnect meningkatkan kecepatan pengguna dalam mengakses aplikasi yang memiliki backend yang dihosting di lingkungan lokal Anda dan di lingkungan cloud lainnya.

Kecepatan pengiriman konten dapat dioptimalkan dengan mengirimkan aplikasi tersebut dari point of presence (PoP) Google Cloud. PoP Google Cloud tersedia di lebih dari 180 pertukaran internet dan lebih dari 160 fasilitas interkoneksi di seluruh dunia.

Untuk melihat cara PoP membantu memberikan API berperforma tinggi saat menggunakan Apigee dengan Cloud CDN untuk mencapai hal berikut, tonton Menyediakan API berperforma tinggi dengan Apigee dan Cloud CDN di YouTube:

  • Mengurangi latensi.
  • Menghosting API secara global.
  • Meningkatkan ketersediaan untuk traffic puncak.

Contoh desain yang diilustrasikan dalam diagram sebelumnya didasarkan pada Private Service Connect tanpa peering VPC.

Jaringan northbound dalam desain ini dibuat melalui:

  • Load balancer (LB dalam diagram), tempat permintaan klien dihentikan, memproses traffic, lalu merutekannya ke backend Private Service Connect.
  • Backend Private Service Connect memungkinkan load balancer Google Cloud mengirim permintaan klien melalui koneksi Private Service Connect yang terkait dengan lampiran layanan produsen ke layanan yang dipublikasikan (instance runtime Apigee) menggunakan grup endpoint jaringan (NEG) Private Service Connect.

Jaringan southbound dibuat melalui:

  • Endpoint Private Service Connect yang mereferensikan lampiran layanan yang terkait dengan load balancer internal (ILB dalam diagram) di VPC pelanggan.
  • ILB di-deploy dengan grup endpoint jaringan konektivitas hybrid (NEG konektivitas hybrid).

  • Layanan hybrid diakses melalui NEG konektivitas hybrid melalui konektivitas jaringan hybrid, seperti VPN atau Cloud Interconnect.

Untuk mengetahui informasi selengkapnya, lihat Menyiapkan Load Balancer Jaringan proxy internal regional dengan konektivitas hybrid dan Pola deployment Private Service Connect.

Mengekspos layanan jarak jauh menggunakan Private Service Connect

Data yang mengalir dari Google Cloud ke lingkungan lokal atau cloud lain, setelah berasal dari beban kerja di VPC, dan melalui Cloud Load Balancing, NEG konektivitas hybrid, serta Cloud VPN atau interconnect.

Gunakan opsi Private Service Connect untuk mengekspos layanan jarak jauh untuk skenario berikut:

  • Anda tidak menggunakan platform API atau ingin menghindari menghubungkan seluruh jaringan VPC langsung ke lingkungan eksternal karena alasan berikut:
    • Anda memiliki batasan keamanan atau persyaratan kepatuhan.
    • Anda memiliki rentang alamat IP yang tumpang-tindih, seperti dalam skenario penggabungan dan akuisisi.
  • Untuk mengaktifkan komunikasi searah yang aman antara klien, aplikasi, dan layanan di seluruh lingkungan meskipun Anda memiliki batas waktu yang singkat.
  • Anda mungkin perlu menyediakan konektivitas ke beberapa VPC konsumen melalui VPC produsen layanan (VPC transportasi umum) untuk menawarkan model layanan multi-tenant atau layanan single-tenant yang sangat skalabel, untuk menjangkau layanan yang dipublikasikan di lingkungan lain.

Menggunakan Private Service Connect untuk aplikasi yang digunakan sebagai API menyediakan alamat IP internal untuk aplikasi yang dipublikasikan, sehingga memungkinkan akses aman dalam jaringan pribadi di seluruh region dan melalui konektivitas hibrida. Abstraksi ini memfasilitasi integrasi resource dari berbagai cloud dan lingkungan on-premise melalui model konektivitas hybrid dan multicloud. Anda dapat mempercepat integrasi aplikasi dan mengekspos aplikasi yang berada di lingkungan lokal, atau lingkungan cloud lainnya, dengan aman menggunakan Private Service Connect untuk memublikasikan layanan dengan akses terperinci. Dalam hal ini, Anda dapat menggunakan opsi berikut:

Pada diagram sebelumnya, beban kerja di jaringan VPC aplikasi Anda dapat menjangkau layanan hybrid yang berjalan di lingkungan lokal, atau di lingkungan cloud lainnya, melalui endpoint Private Service Connect, seperti yang diilustrasikan dalam diagram berikut. Opsi desain ini untuk komunikasi satu arah memberikan opsi alternatif untuk peering ke VPC transit.

Data yang mengalir melalui dan di antara beberapa VPC di dalam Google Cloud sebelum keluar melalui Cloud VPN atau Cloud Interconnect dan masuk ke lingkungan lokal atau cloud lain.

Sebagai bagian dari desain dalam diagram sebelumnya, beberapa frontend, backend, atau endpoint dapat terhubung ke lampiran layanan yang sama, yang memungkinkan beberapa jaringan VPC atau beberapa konsumen mengakses layanan yang sama. Seperti yang diilustrasikan dalam diagram berikut, Anda dapat membuat aplikasi dapat diakses oleh beberapa VPC. Aksesibilitas ini dapat membantu dalam skenario layanan multi-tenant saat layanan Anda digunakan oleh beberapa VPC konsumen meskipun rentang alamat IP-nya tumpang-tindih.

Tumpang-tindih alamat IP adalah salah satu masalah paling umum saat mengintegrasikan aplikasi yang berada di lingkungan yang berbeda. Koneksi Private Service Connect dalam diagram berikut membantu menghindari masalah tumpang-tindih alamat IP. Hal ini dilakukan tanpa memerlukan penyediaan atau pengelolaan komponen jaringan tambahan, seperti Cloud NAT atau NVA, untuk melakukan penafsiran alamat IP. Untuk contoh konfigurasi, lihat Memublikasikan layanan hybrid menggunakan Private Service Connect.

Desain ini memiliki keunggulan berikut:

  • Menghindari potensi dependensi penskalaan bersama dan pengelolaan yang rumit dalam skala besar.
  • Meningkatkan keamanan dengan menyediakan kontrol konektivitas yang mendetail.
  • Mengurangi koordinasi alamat IP antara produsen dan konsumen layanan serta lingkungan eksternal jarak jauh.

Pendekatan desain dalam diagram sebelumnya dapat diperluas pada tahap selanjutnya untuk mengintegrasikan Apigee sebagai platform API menggunakan opsi desain jaringan yang telah dibahas sebelumnya, termasuk opsi Private Service Connect.

Anda dapat membuat endpoint Private Service Connect dapat diakses dari region lain menggunakan akses global Private Service Connect.

Klien yang terhubung ke endpoint Private Service Connect dapat berada di region yang sama dengan endpoint atau di region yang berbeda. Pendekatan ini dapat digunakan untuk memberikan ketersediaan tinggi di seluruh layanan yang dihosting di beberapa region, atau untuk mengakses layanan yang tersedia di satu region dari region lain. Saat endpoint Private Service Connect diakses oleh resource yang dihosting di region lain, biaya keluar antar-regional akan berlaku untuk traffic yang dituju ke endpoint dengan akses global.

Praktik terbaik

  • Mempertimbangkan Apigee dan Apigee Hybrid sebagai solusi platform API Anda menawarkan beberapa manfaat. Apigee menyediakan lapisan proxy, dan abstraksi atau fasad, untuk API layanan backend Anda yang dikombinasikan dengan kemampuan keamanan, pembatasan kecepatan, kuota, dan analisis.
  • VPC dan desain project di Google Cloud harus didasarkan pada hierarki resource dan persyaratan model komunikasi aman Anda.
  • Saat API dengan gateway API digunakan, Anda juga harus menggunakan daftar alamat IP yang diizinkan. Daftar yang diizinkan membatasi komunikasi ke sumber dan tujuan alamat IP tertentu dari konsumen API dan gateway API yang mungkin dihosting di lingkungan yang berbeda.
  • Gunakan aturan firewall VPC atau kebijakan firewall untuk mengontrol akses ke resource Private Service Connect melalui endpoint Private Service Connect.
  • Jika aplikasi diekspos secara eksternal melalui load balancer aplikasi, pertimbangkan untuk menggunakan Google Cloud Armor sebagai lapisan keamanan tambahan untuk melindungi dari ancaman keamanan lapisan aplikasi dan DDoS.
  • Jika instance memerlukan akses internet, gunakan Cloud NAT di VPC aplikasi (konsumen) untuk mengizinkan workload mengakses internet. Dengan demikian, Anda dapat menghindari penetapan instance VM dengan alamat IP publik eksternal di sistem yang di-deploy di belakang gateway API atau load balancer.

  • Tinjau praktik terbaik umum untuk pola jaringan hybrid dan multicloud.