Praktik terbaik untuk mengamankan aplikasi dan API Anda adalah menggunakan Apigee

Last reviewed 2024-03-19 UTC

Dokumen ini menjelaskan praktik terbaik yang dapat membantu Anda mengamankan aplikasi dan API Anda menggunakan Pengelolaan API Apigee serta produk Google Cloud berikut:

Dokumen ini ditujukan untuk arsitek API, arsitek keamanan, dan pemimpin engineer yang mengelola infrastruktur aplikasi dan yang ingin mengekspos API yang aman, skalabel, serta berperforma tinggi.

Dokumen ini menggunakan serangkaian contoh arsitektur untuk menunjukkan praktik terbaik selama menggunakan Pengelolaan API Apigee. Dokumen ini juga membahas tentang praktik terbaik selama menggunakan aplikasi web dan Perlindungan API (WAAP), sebuah solusi keamanan komprehensif yang dapat Anda gunakan untuk membantu mengamankan aplikasi dan API Anda.

Dokumen ini mengasumsikan bahwa Anda telah memahami tentang jaringan, API, dan Google Cloud.

Pengelolaan API Apigee

Apigee adalah sebuah platform untuk mengembangkan dan mengelola API. Dengan menambahkan sebuah lapisan proxy ke layanan Anda, Apigee menyediakan abstraksi atau facade yang membantu Anda untuk mengamankan API layanan backend.

Pengguna dapat berinteraksi dengan aplikasi menggunakan OAuth 2.0 dan rentang alamat IP yang diizinkan. Seperti yang telah ditampilkan pada gambar berikut, pengguna dapat berinteraksi dengan aplikasi, dan data serta layanan terekspos ke aliran dua arah.

Poin-poin keamanan antara interaksi pengguna dengan aplikasi dan backend.

Poin-poin keamanannya adalah sebagai berikut:

  • Pengguna:
    • OAuth 2.0
    • Kontrol akses alamat IP
  • Aplikasi
    • Kunci API
    • OAuth 2.0
    • TLS
  • Para developer dan partner
    • SSO
    • RBAC
  • API
    • OAuth 2.0
    • OpenID Connect
    • Kuota
    • Penahanan lonjakan
    • Perlindungan terhadap ancaman
  • Tim API
    • RBAC IAM
    • Logika gabungan
    • Data masking
    • Log audit
  • Backend
    • Jaringan pribadi
    • TLS bersama
    • Kontrol akses alamat IP

Seperti yang telah ditampilkan pada gambar sebelumnya, Anda dapat menggunakan mekanisme keamanan yang berbeda dalam aplikasi, seperti kunci API atau OAuth 2.0 dengan Transport Layer Security (TLS). Anda juga dapat menambahkan pembatasan kapasitas, kebijakan perlindungan terhadap ancaman, dan mengonfigurasi TLS bersama ke backend lapisan API Anda.

Untuk membantu Anda mengelola akses bagi tim API di platform Apigee, Apigee memiliki kontrol akses berbasis peran (RBAC) dan login gabungan.

Sebaiknya gunakan kebijakan default Apigee untuk mengamankan API Anda. Kebijakan tersebut adalah sebagai berikut:

  • Pengelolaan Traffic. Membantu Anda mengonfigurasi perilaku caching, mengontrol kuota, mengurangi dampak dari lonjakan, dan mengontrol traffic API.
  • Perlindungan pada tingkat pesan. Memungkinkan Anda untuk memeriksa dan memvalidasi permintaan payloads untuk membantu melindungi backend Anda dari penyerang berbahaya.
  • Keamanan. Membantu Anda mengontrol akses ke API Anda.

Anda dapat melampirkan salah satu atau beberapa kebijakan-kebijakan ini ke lapisan proxy Anda. Tabel berikut mencantumkan kasus penggunaan keamanan untuk setiap kebijakan, yang dikategorikan berdasarkan jenis kebijakan.

Jenis kebijakan Nama kebijakan Kasus penggunaan keamanan
Pengelolaan traffic Kebijakan SpikeArrest Menerapkan pembatasan kapasitas terhadap jumlah permintaan yang dikirim ke backend.
Pengelolaan traffic Kebijakan kuota Membantu organisasi Anda untuk menetapkan kuota (jumlah panggilan API yang telah dilakukan) untuk tiap konsumen.
Pengelolaan traffic Kebijakan ResponseCache Menyimpan respons dalam cache, dapat mengurangi jumlah permintaan ke backend.
Perlindungan pada tingkat-pesan Kebijakan OASValidation Memvalidasi permintaan yang masuk atau pesan respons terhadap OpenAPI 3.0 Spesifikasi (JSON atau YAML).
Perlindungan pada tingkat-pesan Kebijakan SOAPMessageValidation Memvalidasi pesan XML terhadap skema pilihan Anda. Memvalidasi pesan SOAP terhadap WSDL serta menentukan apakah pesan JSON dan XML dibuat dengan benar.
Perlindungan pada tingkat-pesan Kebijakan JSONThreatProtection Membantu mengurangi risiko serangan di tingkat konten dengan mengizinkan Anda untuk menentukan batas pada struktur JSON seperti array dan string.
Perlindungan pada tingkat-pesan Kebijakan XMLThreatProtection Membantu Anda dalam mengatasi kerentanan XML dan mengurangi risiko serangan dengan mengevaluasi isi pesan serta mendeteksi pesan yang rusak dan salah format sebelum pesan-pesan tersebut dapat diurai.
Perlindungan pada tingkat-pesan Kebijakan RegularExpressionProtection Mengevaluasi konten terhadap ekspresi reguler yang telah ditetapkan dan berhak menolaknya jika ekspresi tersebut benar.
Keamanan Kebijakan BasicAuthentication Base64 mengenkode dan mendekode kredensial pengguna.
Keamanan Kebijakan VerifyAPIKey Menerapkan verifikasi dan validasi kunci API saat runtime. Hanya mengizinkan aplikasi dengan kunci API yang disetujui dan terkait dengan produk API Anda untuk mengakses API Anda.
Keamanan Kebijakan OAuthV2 Menjalankan operasi pemberian izin terhadap OAuth 2.0 untuk membuat dan memvalidasi token akses.
Keamanan Kebijakan JWS dan JWT Membuat, memverifikasi, dan mendekode JSON Web Token (JWT) and JSON Web Signature (JWS).
Keamanan Kebijakan HMAC Mengkomputasi dan memverifikasi kode autentikasi pesan yang berbasis-hash (HMAC) untuk keperluan autentikasi dan pemeriksaan integritas terhadap tingkat aplikasi.
Keamanan Kebijakan SAMLAssertion
  • Memvalidasi pesan masuk yang berisi pernyataan SAML yang telah ditandatangani secara digital.
  • Membuat pernyataan SAML untuk mengeluarkan permintaan XML
Keamanan Kebijakan CORS Memungkinkan Anda menetapkan header cross-origin resource sharing (CORS) untuk API yang digunakan oleh aplikasi web.

Sebaiknya gunakan Google Cloud Armor untuk kontrol akses berbasis alamat IP dan posisi geografis. Namun, jika tidak memungkinkan, Anda dapat menggunakan Kebijakan KontrolAkses. Untuk membantu mengamankan koneksi dari Apigee ke backend Anda, Apigee juga menyediakan pengelolaan keystore, yang memungkinkan Anda untuk mengonfigurasi keystore dan truststore untuk handshake TLS.

Anda dapat menggunakan Apigee untuk membuat produk API yang memungkinkan Anda memadukan operasi API Anda dan membuatnya tersedia bagi developer aplikasi untuk digunakan. Sebuah produk API memadukan satu operasi atau lebih. Sebuah operasi menentukan proxy API dan jalur resource yang dapat diakses pada proxy tersebut . Sebuah operasi yang dilakukan juga dapat membatasi akses berdasarkan metode HTTP dan kuota.

Anda dapat menggunakan produk-produk API Anda untuk mengontrol akses ke API Anda. Dengan menentukan satu produk API atau lebih dalam aplikasi developer, Anda dapat membatasi akses ke proxy dengan menggunakan kunci API. Misalnya, aplikasi seluler yang digunakan oleh pelanggan hanya dapat melakukan operasi POST pada endpoint /v1/payments, dalam konteks ini adalah sebagai berikut, https://$DOMAIN/v1/payments. Pada contoh lain, pusat panggilan aplikasi yang digunakan oleh staf pusat panggilan dapat melakukan operasi seperti MANFAATKAN atau HAPUS pada endpoint /payments, seperti https://$DOMAIN/v1/payments/1234, untuk mengembalikan atau membatalkan pembayaran.

Arsitektur awal

Bagian ini menjelaskan sebuah contoh arsitektur microservice dengan layanan-layanan yang di-deploy di pusat data dan penyedia cloud. Praktik terbaik arsitektur berikut ini menunjukkan bagaimana Anda dapat meningkatkan (kualitas) dan meningkatkan arsitektur awal.

Contoh arsitektur microservice dengan layanan-layanan yang di-deploy di pusat data dan penyedia cloud.

Berikut merupakan gambaran dari arsitektur awal:

  • Layanan pembayaran dan akun dihosting di pusat data, sementara layanan transfer uang dihosting di Google Cloud.
  • Load Balancer Aplikasi eksternal mengontrol dan mengonfigurasi traffic masuk ke layanan.
  • Load Balancer Aplikasi eksternal meneruskan permintaan ke backend atau layanan pihak ketiga yang tepat dan menangani handshake TLS.

Pada status awalnya, arsitektur contoh memiliki batasan sebagai berikut:

  • Tidak memungkinkan untuk diskalakan.
  • Tidak memungkinkan untuk melindungi sistem dari serangan berbahaya.
  • Tidak mencerminkan praktik terbaik yang konsisten untuk keamanan dan logging karena layanan-layanan tersebut dikembangkan dan dipelihara oleh tim-tim yang berbeda dalam organisasi.

Praktik terbaik arsitektur

Apigee dapat memberikan nilai tambah dan memudahkan Anda dalam mengekspos layanan Anda kepada konsumen dengan menerapkan serangkaian kebijakan standar keamanan di seluruh API. Bagian ini membahas praktik terbaik penggunaan Apigee untuk membantu mengamankan API Anda.

Menggunakan Apigee sebagai lapisan proxy

Diagram berikut menunjukkan arsitektur awal dengan penambahan Apigee sebagai lapisan proxy (facade):

Apigee digunakan sebagai lapisan proxy.

Apigee disediakan di dalam project Google Cloud serta runtime disediakan dan di-peering dalam project tenant menggunakan Peering Jaringan VPC. Untuk membantu mengamankan sistem Anda, alih-alih mengirimkan data melalui internet, Anda dapat menggunakan Apigee sebagai lapisan proxy untuk membuat koneksi langsung (pribadi) ke pusat data Anda menggunakan Cloud Interconnect.

Alur permintaannya adalah sebagai berikut:

  1. Klien mengirimkan permintaan ke Load Balancer Aplikasi eksternal dengan kredensial untuk aplikasi—misalnya, kunci, token, atau sertifikat.
  2. Load balancer merutekan permintaan ke Apigee.
  3. Apigee memproses permintaan tersebut, menjalankan kebijakan keamanan sebagaimana dijelaskan di Pengelolaan API Apigee, dan memutuskan permintaan tersebut disetujui atau ditolak. Apigee juga dapat digunakan untuk merutekan permintaan ke backends yang berbeda berdasarkan klien, permintaan, atau keduanya.
  4. Apigee meneruskan permintaan ke backend GKE secara langsung melalui alamat IP internal. Komunikasi antara Apigee dan layanan transfer uang dapat terjalin melalui alamat RFC 1918 (alamat IP internal) karena mereka berada dalam jaringan yang di-peering.
  5. Apigee mengirimkan permintaan ke backend pusat data pribadi melalui Cloud Interconnect.
  6. Apigee mengirimkan permintaan ke layanan pihak ketiga melalui penyediaan alamat IP Apigee NAT.

Menggunakan Google Cloud Armor sebagai lapisan WAF dengan Apigee

Anda dapat menambahkan Google Cloud Armor ke dalam arsitektur ini untuk meningkatkan batas keamanan Anda. Google Cloud Armor adalah bagian dari infrastruktur load balancing global untuk Google Cloud. Google Cloud Armor menyediakan kemampuan firewall aplikasi web (WAF) dan membantu untuk mencegah serangan Distributed Denial of Service (DDoS). Google Cloud Armor juga dapat membantu Anda memitigasi ancaman terhadap applications dari berbagai risiko yang tercantum di OWASP Top 10.

Anda dapat mengonfigurasi aturan-aturan dan kebijakan-kebijakan di Google Cloud Armor untuk mengevaluasi setiap panggilan dari klien terhadap Load Balancer Aplikasi. Anda juga dapat mengotomatiskan konfigurasi dari kebijakan Google Cloud Armor. Untuk informasi lebih lanjut mengenai cara mengonfigurasi aturan-aturan di Google Cloud Armor, lihat Panduan cara kerja Google Cloud Armor.

Diagram berikut menunjukkan arsitektur contoh dengan keberadaan Apigee dan Google Cloud Armor:

Arsitektur dengan keberadaan Google Cloud Armor.

Alur peristiwa di arsitektur ini mirip dengan poin Menggunakan Apigee sebagai lapisan proxy yang dibahas di awal dokumen. Alur permintaannya adalah sebagai berikut:

  1. Klien mengirimkan permintaan ke Load Balancer Aplikasi eksternal dengan kredensial untuk aplikasi—misalnya, kunci, token, atau sertifikat.
  2. Google Cloud Armor memfilter permintaan yang masuk karena Load Balancer Aplikasi eksternal telah mengaktifkannya. Proses pemfilteran ini menerapkan dan mengevaluasi seluruh aturan dan kebijakan yang telah dikonfigurasi. Jika terdapat aturan yang dilanggar, maka Google Cloud Armor menolak permintaan yang masuk dan memberi Anda sebuah pesan error dan kode status.
  3. Jika tidak ada aturan Google Cloud Armor yang dilanggar, maka Load Balancer Aplikasi eksternal akan merutekan permintaan ke Apigee.
  4. Apigee memproses permintaan tersebut, menjalankan kebijakan keamanan, dan memutuskan permintaan tersebut disetujui atau ditolak. Google Cloud Armor juga dapat digunakan untuk merutekan permintaan ke backend yang berbeda berdasarkan klien, permintaan atau keduanya.
  5. Apigee meneruskan permintaan ke backend GKE secara langsung melalui alamat IP internal. Komunikasi antara Apigee dan layanan transfer uang dapat terjalin melalui alamat RFC 1918 (alamat IP internal) karena mereka berada dalam jaringan yang di-peering.
  6. Apigee mengirimkan permintaan ke backend pusat data pribadi melalui Cloud Interconnect.
  7. Apigee mengirimkan permintaan ke layanan pihak ketiga melalui penyediaan alamat IP Apigee NAT.

Penggunaan WAAP

Untuk lebih meningkatkan profil keamanan, Anda juga dapat menggunakan WAAP yang menyatukan Google Cloud Armor, reCAPTCHA, dan Apigee untuk membantu melindungi sistem Anda dari serangan DDoS dan bot. WAAP juga menyediakan perlindungan WAF dan API.

Sebaiknya gunakan WAAP untuk kasus penggunaan perusahaan jika panggilan API dilakukan dari situs dan aplikasi seluler. Anda dapat menyiapkan aplikasi guna memuat library reCAPTCHA untuk membuat token reCAPTCHA dan mengirimkannya saat klien membuat permintaan.

Diagram berikut menunjukkan alur kerja:

Alur permintaan untuk WAAP.

Alur permintaan dalam diagram sebelumnya adalah sebagai berikut:

  • (1) Seluruh permintaan HTTP(S) oleh pelanggan dan konsumen API akan dikirim ke Load Balancer Aplikasi eksternal.
  • (2) Kontak pertama untuk solusi WAAP adalah Google Cloud Armor.
  • (2a) Jika tidak satupun dari aturan-aturan ini dipicu oleh kebijakan Google Cloud Armor, maka permintaan dikirim ke reCAPTCHA API agar dievaluasi oleh mereka apakah traffic yang masuk adalah permintaan yang sah atau tidak.
  • (3a) Jika permintaan yang dikirim adalah permintaan yang sah, maka permintaan tersebut akan diteruskan ke backend.
  • (2b) Jika permintaan yang dikirim tidak sah, maka Google Cloud Armor dapat menolak permintaan tersebut dan mengirimkan kode respons 403 ke pengguna.
  • (3b) Untuk setiap permintaan API, setelah aturan OWASP Google Cloud Armor dan perlindungan DDoS dievaluasi, selanjutnya permintaan akan diteruskan ke Apigee agar Apigee dapat memeriksa keabsahan permintaan API.
  • (4) Apigee berhak menentukan apakah kunci API atau token akses yang digunakan dalam permintaan valid atau tidak. Jika Apigee menentukan bahwa permintaan tersebut tidak sah, maka Apigee dapat mengirimkan kode respons 403.
  • (5) Jika permintaan yang dikirim sah, maka Apigee akan meneruskan permintaan tersebut ke backend.

Diagram berikut menunjukkan arsitektur WAAP dengan Google Cloud Armor, reCAPTCHA, dan Apigee untuk permintaan API.

Alur permintaan untuk WAAP dengan Google Cloud Armor, reCAPTCHA, dan Apigee.

Alur permintaan dalam diagram sebelumnya adalah sebagai berikut:

  1. Klien mengirimkan permintaan ke Load Balancer Aplikasi eksternal dengan kredensial untuk aplikasi—misalnya, kunci, token, atau sertifikat.
  2. Karena Load Balancer Aplikasi eksternal telah mengaktifkan Google Cloud Armor, Google Cloud Armor akan memilih permintaan tersebut. Proses pemilihan permintaan ini menerapkan dan mengevaluasi seluruh aturan dan kebijakan yang telah dikonfigurasi. Jika terdapat aturan yang dilanggar, maka Google Cloud Armor menolak permintaan yang masuk dengan mengirimkan sebuah pesan error dan kode status.
  3. Untuk panggilan situs seperti pengiriman formulir pada halaman login, Google Cloud Armor telah terintegrasi dengan reCAPTCHA. reCAPTCHA mengevaluasi traffic yang masuk dan menambahkan skor risiko ke traffic yang sah. Untuk traffic yang dinyatakan tidak sah, maka Google Cloud Armor berhak menolak permintaan tersebut.
  4. Jika tidak ada aturan Google Cloud Armor yang dilanggar, maka Load Balancer Aplikasi eksternal akan merutekan permintaan API ke Apigee.
  5. Apigee memproses permintaan tersebut, menjalankan kebijakan keamanan, dan memutuskan permintaan tersebut disetujui atau ditolak. Apigee juga dapat digunakan untuk merutekan permintaan ke backends yang berbeda berdasarkan klien, permintaan, atau keduanya.
  6. Apigee meneruskan permintaan ke backend GKE secara langsung melalui alamat IP internal. Komunikasi antara Apigee dan layanan transfer uang dapat terjalin melalui alamat RFC 1918, yang merupakan sebuah alamat IP internal, karena mereka berada dalam jaringan yang di-peering.
  7. Apigee mengirimkan permintaan ke backend pusat data pribadi melalui Cloud Interconnect.
  8. Apigee mengirimkan permintaan ke layanan pihak ketiga melalui penyediaan alamat IP Apigee Nat.

Menggunakan Cloud CDN untuk penyimpanan cache

Cloud CDN menggunakan jaringan global Google untuk menghadirkan konten agar lebih dekat ke pengguna, sehingga mempercepat waktu respons bagi situs dan aplikasi Anda. Cloud CDN juga menawarkan kemampuan penyimpanan cache yang dapat membantu Anda mengamankan backend dengan mengembalikan respons dari cache itu sendiri. Dengan meng-cache data yang sering diakses di Google Front End (GFE) , yang berada di edge jaringan Google, hal ini dapat menyimpan data sedekat mungkin dengan pengguna dan memungkinkan akses yang paling cepat.

Cloud CDN juga membantu organisasi menangani lonjakan musiman di dalam traffic dengan lancar —misalnya, lonjakan yang mungkin saja terjadi selama musim liburan atau tahun ajaran baru. Pendekatan penyimpanan cache ini membantu meningkatkan keandalan dan pengalaman pengguna dalam sebuah ekosistem. Pendekatan penyimpanan cache juga dapat membantu meminimalkan muatan server web, komputasi, dan penggunaan jaringan. Untuk menerapkan arsitektur ini, Anda harus mengaktifkan Cloud CDN pada load balancer yang bertugas menyalurkan traffic ke Apigee.

Cloud CDN dapat digunakan dengan salah satu opsi yang dibahas di dalam dokumen ini. Diagram berikut menunjukkan contoh arsitektur awal milik WAAP dengan penambahan Cloud CDN.

Alur permintaan penggunaan Cloud CDN.

Alur permintaan yang ditampilkan dalam diagram sebelumnya adalah sebagai berikut:

  1. Klien menggunakan library reCAPTCHA untuk mendapatkan token dan mengirim permintaan ke Load Balancer Aplikasi eksternal dengan kredensial untuk aplikasi—misalnya, kunci, token, atau sertifikat.
  2. Cloud CDN memeriksa cache dengan kunci cache dan menampilkan respons jika cache ditemukan benar.
  3. Jika cache ditemukan salah, maka Google Cloud Armor akan memfilter permintaan karena Load Balancer Aplikasi eksternal mengaktifkan Google Cloud Armor. Google Cloud Armor menerapkan dan mengevaluasi seluruh aturan dan kebijakan yang telah dikonfigurasi. Jika terdapat aturan yang dilanggar, maka Google Cloud Armor menolak permintaan yang masuk dengan mengirimkan sebuah pesan error dan kode status.
  4. Google Cloud Armor terintegrasi dengan reCAPTCHA, yang mengevaluasi traffic masuk yang sah dengan skor risiko. Untuk traffic yang tidak sah, Google Cloud Armor dapat menolak permintaan tersebut.
  5. Jika tidak ada aturan Google Cloud Armor yang dilanggar, maka Load Balancer Aplikasi eksternal akan merutekan permintaan ke Apigee.
  6. Apigee memproses permintaan tersebut, menjalankan kebijakan keamanan sebagaimana dijelaskan di Pengelolaan API Apigee, dan memutuskan permintaan tersebut disetujui atau ditolak. Google Cloud Armor juga dapat digunakan untuk merutekan permintaan ke backend yang berbeda berdasarkan klien, permintaan atau keduanya.
  7. Apigee meneruskan permintaan ke backend GKE secara langsung melalui alamat IP internal. Komunikasi antara Apigee dan layanan transfer uang dapat terjalin melalui alamat RFC 1918, yang merupakan sebuah alamat IP internal, karena mereka berada dalam jaringan yang di-peering.
  8. Apigee mengirimkan permintaan ke backend pusat data pribadi melalui Cloud Interconnect.
  9. Apigee mengirimkan permintaan ke layanan pihak ketiga melalui penyediaan alamat IP Apigee NAT.
  10. Saat respons mengarah kembali kepada klien, Cloud CDN menyimpan respons dalam cache sangat cepat sehingga dapat mengembalikan respons dari cache untuk panggilan di masa mendatang.

Langkah berikutnya