10 ancaman API teratas OWASP

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Dokumen ini menjelaskan berbagai pendekatan yang dapat Anda gunakan dalam Apigee untuk mengatasi kerentanan keamanan yang diidentifikasi oleh OWASP. Untuk pendekatan tambahan yang didokumentasikan untuk Apigee, lihat 10 opsi mitigasi teratas OWASP 2021 di Google Cloud.

Pengantar

OWASP adalah komunitas terbuka yang didedikasikan untuk membantu organisasi mengembangkan, membeli, dan mengelola aplikasi dan API tepercaya. Melalui project Keamanan API OWASP, OWASP memublikasikan risiko keamanan paling penting untuk aplikasi web dan REST API serta memberikan rekomendasi untuk mengatasi risiko tersebut.

Dokumen ini akan membahas pendekatan untuk melindungi dari serangan berbasis API umum, seperti yang diidentifikasi oleh sepuluh ancaman keamanan API teratas OWASP 2019. Tema umum dalam ancaman teratas yang ditandai oleh daftar terbaru disebabkan oleh penempatan kontrol autentikasi dan otorisasi yang tidak tepat, seperti mengandalkan pemfilteran data yang ditampilkan oleh permintaan API dalam aplikasi klien, dengan menggunakan anti-pola yang mengandalkan aplikasi klien yang menggunakan untuk melakukan penerapan kontrol akses.

Dengan pertumbuhan ekosistem API yang terus berlanjut dengan cepat, penyalahgunaan dan kesalahan penggunaan API yang mengakibatkan ekstraksi data oleh penyerang sayangnya menjadi salah satu vektor serangan paling umum saat ini. Keamanan terus menjadi prioritas utama bagi Apigee, dengan sejumlah fitur baru seperti Advanced API Ops, yang mencakup fitur pelaporan keamanan dan deteksi anomali. Namun, mendesain dan menerapkan fitur keamanan Apigee dengan benar sangat penting untuk mengurangi kemungkinan serangan yang berhasil terhadap API Anda.

Aplikasi Konsumen harus dianggap tidak tepercaya, atau "publik", karena Anda tidak mengontrol platform tempat aplikasi berjalan. Asumsikan bahwa aplikasi publik dapat dan akan disusupi, sehingga aplikasi tersebut tidak dapat dipercaya untuk menerapkan kontrol akses (API1, API5), memfilter data respons (API6), atau menyimpan secret klien dengan aman (API2) seperti kunci API atau token akses. Beberapa rekomendasi muncul dari pemeriksaan 10 teratas OWASP 2019:

  • Tentukan jenis aplikasi klien yang akan menggunakan API Anda (SPA, seluler, atau berbasis browser), dan desain pola autentikasi, otorisasi, dan keamanan yang sesuai.
  • Selalu gunakan alur OAuth atau OpenID Connect “klien publik” (penggunaan PKCE sangat direkomendasikan)
  • Pikirkan logika bisnis aplikasi Anda, tentukan spesifikasi OpenAPI terlebih dahulu, dan desain proxy API untuk memfilter semua data respons dari backend dalam Apigee. Jangan pernah mengandalkan logika kode aplikasi downstream untuk melakukan ini.
  • Filter semua permintaan data yang berisi PII khusus pengguna agar hanya mengizinkan data dari backend Anda yang dimiliki oleh pengguna yang meminta.

API1:2019 Otorisasi level objek rusak

Deskripsi ancaman

Validasi otorisasi yang tidak memadai untuk permintaan akses objek memungkinkan penyerang melakukan tindakan yang tidak sah dengan menggunakan kembali token akses. Ancaman ini disebabkan oleh konfigurasi validasi otorisasi yang tidak tepat. Apigee menyediakan kebijakan VerifyApiKey, OAuth, dan Token Web JSON (JWT), yang membantu melindungi dari kerentanan ini, tetapi kebijakan ini harus dikonfigurasi dengan benar untuk mencegah ancaman ini.

Untuk mencegah ancaman ini, tim pengembangan aplikasi dan tim keamanan harus berkolaborasi secara erat. Otorisasi pada dasarnya adalah topik yang kompleks, dan otorisasi terperinci yang efektif memerlukan pemahaman mendalam tentang logika bisnis aplikasi.

Ada dua aspek utama yang perlu dipertimbangkan dari perspektif penerapan Apigee:

  • Integritas token akses
  • Penerapan kontrol akses

Integritas Token Akses

Anda harus memvalidasi bahwa token yang diberikan oleh klien yang meminta belum dimodifikasi, dengan menggunakan alur OAuth atau OpenID Connect yang benar beserta mekanisme penandatanganan atau validasi kredensial yang sesuai. Apigee mendukung semua alur OAuth yang umum digunakan.

Kebijakan verifikasi token akses Apigee mencakup:

Penerapan Kontrol Akses

Setelah validitas token akses diverifikasi, Anda harus menerapkan kebijakan penerapan kontrol akses untuk mengevaluasi setiap permintaan API yang masuk berdasarkan hak akses token otorisasi.

Apigee menyediakan dua mekanisme utama untuk memverifikasi dan menerapkan kebijakan otorisasi:

  • Internal: menggunakan alur bersyarat untuk mengevaluasi permintaan akses berdasarkan klaim yang diekstrak sebagai variabel alur dari token otorisasi
  • Didelegasikan: menggunakan info layanan ke solusi pengelolaan akses pihak ketiga

Pendekatan internal (diilustrasikan pada gambar di atas) direkomendasikan jika model kontrol akses relatif mudah. Misalnya, jika klaim yang diekstrak dari token akses dapat digunakan untuk mengevaluasi dan memberikan otorisasi langsung pada permintaan objek API.

Gunakan variabel alur yang tersedia untuk kebijakan OAuth atau JWT guna mengevaluasi permintaan akses menggunakan pernyataan alur bersyarat.

Pendekatan didelegasikan (diilustrasikan pada gambar di atas) direkomendasikan jika klaim yang diekstrak dari token akses tidak dapat digunakan secara langsung untuk memberikan otorisasi pada permintaan API ke objek backend, atau untuk jenis alur OAuth yang lebih kompleks yang memerlukan panggilan terpisah ke server otorisasi untuk mendapatkan token akses.

Dengan menggunakan kebijakan info layanan, Anda dapat meminta keputusan kebijakan otorisasi dari layanan pihak ketiga, atau mendapatkan informasi klaim tambahan tentang agen yang meminta, lalu membuat keputusan kontrol akses menggunakan alur bersyarat

API2:2019 Autentikasi pengguna rusak

Deskripsi ancaman

Kebijakan autentikasi pengguna yang diterapkan dengan buruk memungkinkan penyerang meniru identitas pengguna yang sah dengan memanfaatkan kekurangan implementasi dalam implementasi autentikasi. Beberapa prinsip autentikasi yang perlu diingat saat menerapkan pendekatan autentikasi meliputi:

  • Selalu autentikasi agen pengguna (aplikasi) dan pengguna yang meminta
  • Gunakan pola autentikasi dan otorisasi yang didelegasikan dan hindari meneruskan sandi secara langsung dalam permintaan API
  • Selalu validasi tanda tangan kredensial akses, dan pastikan semua kredensial akses yang digunakan memiliki waktu habis masa berlaku yang ditentukan
  • Mencegah serangan brute force dengan menetapkan kuota dan menggunakan Apigee Sense untuk mendeteksi dan merespons serangan brute force yang didorong bot

Berdasarkan paradigma outside-in, desain API dibuat berdasarkan kasus penggunaan konsumen untuk data, bukan struktur data yang ada di sistem backend Anda, dan keamanan adalah elemen penting saat mendesain API untuk konsumen eksternal. Sistem backend biasanya tidak dibuat dengan implementasi autentikasi yang cukup kuat untuk diekspos ke jaringan publik. Di sinilah Apigee, yang digabungkan dengan solusi pengelolaan akses dan identitas, dapat menawarkan solusi yang kuat untuk melindungi dari ancaman ini.

Ada beberapa elemen utama yang perlu dipertimbangkan di sini, yang keduanya akan dibahas di bagian berikutnya:

  • Desain keamanan: memanfaatkan fitur Apigee sepenuhnya untuk menerapkan pola autentikasi
  • Pemerintahan: memastikan bahwa penggunaan pola autentikasi yang dirancang digunakan secara konsisten, di semua produk API yang dipublikasikan
  • Keamanan operasional: dapat mendeteksi perilaku yang mencurigakan atau anomali dan upaya untuk mengakali atau melakukan brute force pada proxy API yang diautentikasi

Desain Keamanan

Tujuan desain keamanan adalah menerapkan alur autentikasi dan integrasi dengan alat identitas pihak ketiga dengan benar. Desain keamanan adalah fase penting, dan dimulai dengan memahami jenis alur autentikasi yang tepat untuk digunakan berdasarkan jenis aplikasi yang akan menggunakan endpoint API Anda. Langkah berikutnya adalah menentukan, bersama dengan tim identitas Anda, pola integrasi yang akan diterapkan dengan solusi identitas Anda.

RFC OpenID Connect dan OAuth menyediakan sejumlah besar alur autentikasi dan otorisasi yang didelegasikan, serta aktor yang terlibat dalam alur ini. Ini adalah topik yang kompleks, dan tidak mengherankan bahwa autentikasi yang rusak adalah salah satu ancaman API OWASP teratas. Memberikan pengantar komprehensif tentang penerapan standar identitas yang benar berada di luar cakupan dokumen ini, tetapi Apigee memiliki banyak referensi tambahan untuk lebih memahami alur OAuth, seperti ebook dan webcast ini, serta contoh penerapan.

Kebijakan autentikasi

Kebijakan Apigee yang membantu mengatasi masalah identitas dan autentikasi meliputi:

Pengelolaan Traffic

Fitur pengelolaan traffic Apigee berikut membantu melindungi dari serangan brute force:

  • Kebijakan Spike Arrest, untuk menetapkan batas kapasitas rata-rata bergulir secara keseluruhan pada proxy API
  • Kebijakan kuota, untuk menetapkan batas kapasitas yang terperinci ke proxy API berdasarkan kuota yang ditentukan oleh kunci aplikasi, developer, atau kuota produk API
  • Kebijakan penyimpanan dalam cache, untuk menyimpan dalam cache token akses yang disimpan berdasarkan waktu habis masa berlaku yang ditentukan, serta kemampuan untuk invalidate kredensial yang disimpan dalam cache (misalnya, dalam situasi saat token akses yang valid disusupi)

Tata kelola

Keamanan adalah proses yang berkelanjutan, bukan project “set and forget”, dan salah satu penyebab terbesar pelanggaran keamanan adalah kesalahan konfigurasi. Setelah alur autentikasi, pola integrasi identitas, dan kebijakan pengelolaan traffic terkait autentikasi ditentukan, penerapannya harus dilakukan dengan benar dan konsisten.

Apigee menyediakan sejumlah fitur dan alat untuk memastikan integritas penerapan dan mencegah error miskonfigurasi.

Kontrol Akses Berbasis Peran (RBAC)

Baik Anda adalah perusahaan besar maupun startup kecil, menghindari error konfigurasi yang salah dimulai dengan memastikan bahwa hanya orang dan tim yang tepat yang dapat mengakses dan mengubah konfigurasi proxy API. Program API didukung oleh tim multidisipliner di seluruh organisasi Anda. Setiap tim hanya boleh diberi izin yang diperlukan untuk melakukan tugasnya sebagai bagian dari perjalanan API Anda.

Apigee menyediakan fitur bagi Anda untuk mengelola akses berbasis peran dengan menyediakan kemampuan bagi Anda untuk menetapkan pengguna ke peran yang telah ditentukan sebelumnya, atau membuat peran kustom yang sesuai dengan tim API Anda. Menentukan dan mengelola penetapan peran dengan benar sangat penting agar Anda dapat menskalakan program API dengan aman. Anda juga dapat menggunakan federasi untuk berintegrasi dengan direktori perusahaan yang ada, dan untuk mengurangi kebutuhan Anda dalam mengelola kumpulan kredensial administrator kedua dalam Apigee.

Alur Bersama

Alur bersama memungkinkan Anda menentukan kebijakan dan resource ke dalam objek yang dapat digunakan kembali dan dapat diterapkan di seluruh proxy API. Misalnya, Anda mungkin telah mendesain secara kolaboratif dengan tim keamanan beberapa pola desain autentikasi berdasarkan jenis aplikasi yang menggunakan API. Developer API tidak perlu menjadi pakar identitas untuk menggunakan kembali ini, mereka hanya perlu mengetahui alur bersama yang benar untuk ditambahkan ke konfigurasi proxy API yang ada menggunakan kebijakan Flow callout.

Gambar: Alur Bersama adalah paket kebijakan dan logika kondisional yang dapat digunakan kembali yang memungkinkan Anda mempertahankan pola komposit.

Pelaporan Keamanan

Setelah memastikan bahwa hanya orang yang tepat di organisasi Anda yang dapat mengubah pola autentikasi, dan Anda telah menentukan alur autentikasi bersama, Anda harus memastikan bahwa proxy API yang dikembangkan oleh tim API Anda menggunakan pola autentikasi tersebut secara konsisten.

Fitur Advanced API Ops baru Apigee mencakup pelaporan keamanan lanjutan, yang memungkinkan tim Ops dan keamanan melihat laporan di semua proxy API dengan mudah, dan berfokus pada kepatuhan terhadap kebijakan keamanan seperti penggunaan alur bersama. Pelaporan, logging, dan pemberitahuan adalah elemen utama keamanan API yang akan dibahas secara lebih mendetail di bagian API10: logging tidak memadai, tetapi dari perspektif mencegah risiko autentikasi yang rusak, hal ini sangat berguna dalam memastikan kepatuhan terhadap standar autentikasi yang Anda tentukan yang diterapkan sebagai alur bersama.

Keamanan Operasional

Setelah API Anda diproduksi menggunakan pola autentikasi yang tepat dengan pengelolaan traffic dasar yang diterapkan, tim SecOps Anda juga harus dapat memantau dan merespons aktivitas yang mencurigakan, yang sering kali dimulai dengan upaya untuk membahayakan kredensial autentikasi.

Apigee Sense

Apigee Sense melindungi API Anda dari traffic permintaan yang tidak diinginkan, termasuk serangan dari klien berbahaya. Apigee Sense menganalisis traffic permintaan API, yang mengidentifikasi pola yang mungkin mewakili permintaan yang tidak diinginkan. Dengan analisis ini, Anda dapat mengidentifikasi klien yang membuat permintaan yang tidak diinginkan, lalu mengambil tindakan untuk mengizinkan, memblokir, atau menandai permintaan tersebut. Fitur Sense mendatang akan mencakup kemampuan untuk mengaktifkan verifikasi reCAPTCHA secara otomatis pada traffic yang mencurigakan.

Dengan Apigee Sense, Anda dapat melindungi API dari pola permintaan yang mencakup:

  • Perilaku otomatis yang menyatu dengan perilaku manusia
  • Upaya yang terus-menerus dari IP yang sama
  • Rasio error yang tidak biasa
  • Permintaan klien yang mencurigakan
  • Crawling data
  • Pengumpulan kunci dan serangan brute force autentikasi
  • Lonjakan aktivitas
  • Pola geografis

Operasi API Lanjutan

Meskipun Sense telah dirancang secara khusus untuk mendeteksi dan merespons ancaman seperti bot, Advanced API Ops mencakup definisi deteksi anomali dan peringatan lanjutan.

Deteksi anomali berfungsi dengan menerapkan model kecerdasan buatan (AI) dan Machine Learning (ML) ke data API historis Anda. Deteksi anomali kemudian dapat memunculkan pemberitahuan secara real time untuk skenario yang bahkan belum Anda bayangkan untuk meningkatkan produktivitas dan mengurangi waktu rata-rata untuk menyelesaikan masalah API.

Advanced API Ops dibuat berdasarkan mekanisme pemberitahuan Pemantauan API yang ada untuk menambahkan jenis pemberitahuan lanjutan berikut:

  • Total notifikasi traffic. Memunculkan pemberitahuan saat traffic berubah sebesar persentase yang ditentukan selama rentang waktu. Misalnya, Anda dapat memicu pemberitahuan saat traffic meningkat sebesar 5% atau lebih selama satu jam, atau menurun sebesar 10% atau lebih selama satu minggu
  • Notifikasi anomali. Edge mendeteksi masalah traffic dan performa, sehingga Anda tidak perlu menentukannya terlebih dahulu. Kemudian, Anda dapat memunculkan pemberitahuan untuk anomali ini
  • Pemberitahuan Akhir Masa Berlaku TLS. Menampilkan notifikasi saat masa berlaku sertifikat TLS hampir habis

API3:2019 Eksposur data yang berlebihan

Deskripsi ancaman

API yang dipublikasikan mungkin mengekspos lebih banyak data daripada yang diperlukan, dengan mengandalkan aplikasi klien untuk melakukan pemfilteran yang diperlukan. Jika penyerang langsung membuat kueri API yang mendasarinya, mereka dapat mengakses data sensitif.

Salah satu prinsip desain “outside-in” Apigee untuk desain API adalah parsimoni data. Bekerja sama dengan desainer UX dan developer untuk hanya mengekspos data melalui API yang diperlukan dalam UI aplikasi Anda. Sistem backend tidak dibuat untuk pola penggunaan publik, sehingga salah satu tugas pertama desain API first dengan Apigee adalah mengurangi data yang diekspos ke minimum yang diperlukan untuk menyediakan produk API yang bagus bagi pelanggan dan developer Anda.

Prinsip desain Apigee lainnya adalah kemampuan penggunaan kembali. Selain masalah keamanan, mengandalkan aplikasi untuk memfilter data yang disediakan oleh API akan menghasilkan persyaratan untuk mem-port logika pemfilteran tersebut di setiap platform tempat Anda mengembangkan aplikasi.

Dari perspektif keamanan, ancaman ini dihasilkan dari mendelegasikan penerapan otorisasi ke aplikasi, tetapi sering kali di platform atau OS yang tidak Anda kontrol. Kita telah memeriksa di API1 dan API2 pentingnya menerapkan autentikasi dan otorisasi dengan benar untuk menghindari akses data yang tidak sah.

Bagian berikutnya akan membahas cara:

  • Menulis ulang permintaan dan respons ke layanan backend untuk meminimalkan eksposur data
  • Terapkan penanganan error untuk mencegah pesan error panjang mengekspos informasi lingkungan sensitif kepada penyerang tentang layanan backend Anda

Menulis ulang respons dan permintaan

Sistem backend biasanya tidak dirancang untuk digunakan di aplikasi publik atau di seluruh jaringan publik yang tidak tepercaya. Apigee Edge dirancang untuk memungkinkan Anda men-deploy produk API publik dengan melindungi backend dari eksposur data yang berlebihan.

Untuk melakukannya, Apigee menggunakan tiga kebijakan utama:

  • Tugaskan Pesan
  • Info kode
  • Penanganan error

Menetapkan kebijakan Pesan

Kebijakan Tetapkan Pesan mengubah atau membuat pesan permintaan dan respons baru selama Alur proxy API. Kebijakan ini memungkinkan Anda melakukan tindakan berikut pada pesan tersebut:

  • Menambahkan parameter formulir, header, atau parameter kueri baru ke pesan
  • Menyalin properti yang ada dari satu pesan ke pesan lain
  • Menghapus header, parameter kueri, parameter formulir, dan/atau payload pesan dari pesan
  • Menetapkan nilai properti yang ada dalam pesan

Dengan Menetapkan Pesan, Anda biasanya menambahkan, mengubah, atau menghapus properti permintaan atau respons. Namun, Anda juga dapat menggunakan Tetapkan Pesan untuk membuat pesan permintaan atau respons kustom dan meneruskannya ke target alternatif, seperti yang dijelaskan dalam Membuat pesan permintaan kustom.

Penulisan ulang yang kompleks dengan kode kustom

Untuk aturan penanganan dan penulisan ulang data yang kompleks yang kompleksitasnya melebihi kemampuan kebijakan Tetapkan pesan, Anda dapat menggunakan bahasa prosedural seperti JavaScript, Java, atau Python. Anda dapat menambahkan kode kustom ke proxy API, lalu memanggilnya dari kebijakan yang ditambahkan ke alur proxy. Dukungan untuk kode prosedural dirancang untuk memudahkan Anda menerapkan penanganan kompleks terhadap variabel alur, error, serta isi permintaan dan respons.

Dengan kode prosedural, Anda dapat:

  • Membuat atau memanipulasi nilai isi yang kompleks, seperti nilai permintaan dan respons.
  • Menulis ulang URL, seperti untuk menyamarkan URL endpoint target.

Apigee Edge menyertakan kebijakan terpisah untuk bahasa yang didukung: kebijakan JavaScript, kebijakan Callout Java, dan kebijakan Skrip Python.

Penanganan fault

Dengan Apigee, Anda dapat melakukan penanganan pengecualian kustom menggunakan kebijakan jenis Raise Fault. Kebijakan Raise Fault, yang merupakan variasi dari kebijakan Assign Message, memungkinkan Anda membuat respons error kustom sebagai respons terhadap kondisi error.

Alur Bersama

Alur bersama dapat digunakan untuk menerapkan standarisasi pesan error. Misalnya, kebijakan yang dikonfigurasi sama yang mendeteksi kode error HTTP tertentu dari backend dapat digunakan untuk menulis ulang respons error guna menampilkan pesan error umum.

API4:2019 Kurangnya resource & pembatasan kapasitas

Deskripsi ancaman

Dengan tidak menerapkan kebijakan pembatasan kapasitas, penyerang dapat membebani backend dengan serangan denial-of-service.

Ancaman ini dapat diatasi dengan mudah menggunakan fitur Apigee berikut:

  • Kebijakan Kuota dan Penghentian Lonjakan sebagai kontrol pencegahan untuk menerapkan batas traffic pada permintaan API masuk
  • Apigee Sense untuk mendeteksi dan merespons serangan yang didorong bot secara dinamis
  • Pemantauan dan pemberitahuan API lanjutan sebagai kontrol detektif untuk mendapatkan pemberitahuan tentang serangan DDoS yang sedang berlangsung

Pembatasan kapasitas dengan kebijakan Kuota dan Penangkapan Lonjakan

Apigee menyediakan dua kebijakan untuk pembatasan kapasitas:

  • Spike arrest memberikan kebijakan umum, yang ditentukan di tingkat proxy API, untuk membatasi jumlah permintaan masuk secara keseluruhan ke backend
  • Kuota menyediakan alat kebijakan terperinci untuk menerapkan kebijakan kuota, baik di proxy API maupun di tingkat produk API

Penahanan Lonjakan

Kebijakan Spike Arrest melindungi dari lonjakan traffic. Kebijakan ini membatasi jumlah permintaan yang diproses oleh proxy API dan dikirim ke backend, yang melindungi dari jeda performa dan periode nonaktif, menggunakan nilai rata-rata bergulir yang dapat ditentukan dalam kebijakan.

Kuota

Kebijakan Kuota memungkinkan konfigurasi jumlah pesan permintaan yang diizinkan oleh proxy API selama jangka waktu tertentu, seperti menit, jam, hari, minggu, atau bulan. Anda dapat menetapkan kuota agar sama untuk semua aplikasi yang mengakses proxy API, atau Anda dapat menetapkan kuota berdasarkan:

  • Produk yang berisi proxy API
  • Aplikasi yang meminta API
  • Developer aplikasi
  • Banyak kriteria lainnya

Kebijakan ini lebih terperinci daripada Penghentian lonjakan, dan umumnya harus digunakan secara serentak dengan kebijakan tersebut.

Pendeteksian bot dengan Apigee Sense

Dengan Apigee Sense, Anda dapat mengambil tindakan untuk mengizinkan, memblokir, atau menandai permintaan secara eksplisit dari klien, rentang IP, atau organisasi Autonomous System tertentu, berdasarkan klien atau lokasi tersebut yang menunjukkan perilaku malicious atau mencurigakan. Apigee Edge menerapkan tindakan ini ke permintaan sebelum proxy API Anda memprosesnya. Misalnya, rentang IP atau klien tertentu yang menunjukkan perilaku “brute guessor” dapat dideteksi, lalu diblokir atau ditandai.

Deteksi ancaman dengan Advanced API Ops Monitoring

Gunakan notifikasi traffic untuk menampilkan notifikasi saat traffic untuk lingkungan, proxy, atau wilayah berubah sebesar persentase yang ditentukan selama rentang waktu. Fitur ini dapat secara dinamis memunculkan pemberitahuan saat traffic menyimpang secara signifikan dari throughput yang Anda harapkan, seperti yang terjadi selama serangan DDoS. Notifikasi ini dapat dengan mudah dikirim ke solusi pemantauan dan logging pihak ketiga.

API5:2019 Otorisasi level fungsi rusak

Deskripsi ancaman

Ancaman ini adalah variasi dari API1, dan juga merupakan kerentanan otorisasi. Dengan ancaman ini, penyerang dapat melakukan tindakan dengan mengirimkan permintaan ke fungsi yang tidak diizinkan untuk diakses. Misalnya, penyerang mungkin dapat mengubah atau menghapus data yang hanya diberi otorisasi untuk dibaca jika endpoint API tidak memvalidasi kata kerja permintaan HTTP, dengan mengganti GET dengan PUT atau DELETE. Atau, dengan tidak menerapkan kontrol akses yang cukup ketat pada jalur URI resource API, endpoint API dapat mengizinkan penyerang melihat data pengguna lain hanya dengan mengubah jalur dalam permintaan.

Jenis ancaman ini menyoroti nilai penggunaan Apigee sebagai lapisan mediasi dan abstraksi, karena banyak sistem backend - yang tidak dirancang untuk akses publik - mungkin secara default menyediakan satu endpoint untuk menjalankan beberapa fungsi logika bisnis, termasuk fungsi administratif berisiko tinggi.

Elemen konseptual untuk mengurangi kemungkinan ancaman ini biasanya dibagi menjadi:

  • Apa yang dilindungi? Pikirkan strategi produk API Anda, dan terapkan segmentasi fungsi yang logis saat menggunakan praktik terbaik RESTful untuk mendesain jalur dan resource yang diekspos oleh proxy API, produk, dan fitur aplikasi Apigee.
  • Siapa yang mengakses resource API Anda? Tentukan persona tingkat tinggi dan terapkan hak akses default “hak istimewa minimum” dengan menggunakan beberapa fitur autentikasi dan otorisasi Apigee seperti yang diuraikan dalam API1 dan API2.
  • Bagaimana cara kebijakan akses Anda diterapkan? Gunakan alur dan error bersyarat untuk memvalidasi jalur dan kata kerja URL dari semua permintaan API.

Gambar: Diagram ini menunjukkan cara penerapan otorisasi tingkat fungsi di Apigee, menggunakan cakupan yang disediakan dalam token akses sebagai hak.

Segmentasi Logis dengan proxy, produk, dan aplikasi API

Apigee menyediakan toolkit yang sangat fleksibel untuk memungkinkan segmentasi logis resource API, sehingga proxy API dapat dipaketkan ke dalam sejumlah produk API, yang pada akhirnya digunakan oleh developer aplikasi Anda, yang dapat mendaftarkan aplikasi yang menggunakan produk API Anda. Kebijakan akses dapat ditentukan di salah satu tingkat ini.

Namun, untuk menerapkan otorisasi dan segmentasi fungsional yang efektif, Anda harus menentukan strategi produk API. Bagian dari proses penting dan berkelanjutan ini adalah definisi “siapa” dan “apa” dari produk API Anda, dengan melihat resource API dari perspektif pelanggan dan developer, lalu menentukan hingga ke resource jalur dan tingkat kata kerja HTTP, jenis permintaan apa yang akan diizinkan.

Gambar: Resource API yang dipaketkan ke dalam produk API dapat berasal dari satu atau beberapa API, sehingga Anda dapat menggabungkan resource untuk membuat tingkat penggunaan dan batas otorisasi.

Kontrol Akses tingkat Fungsi dengan cakupan OAuth dan klaim JWT

Meskipun pendekatan otorisasi yang dipertimbangkan di atas untuk API1:2019 Broken object authorization menangani kontrol akses yang sangat terperinci di tingkat objek, penting juga untuk menangani kontrol akses yang kasar di tingkat fungsi. Apakah pengguna yang meminta diizinkan untuk meminta jalur URL ini? Jenis kebijakan ini sering kali ditentukan per persona pengguna (pelanggan, karyawan, administrator, developer internal atau pihak ketiga).

Untuk mengurangi risiko kesalahan konfigurasi, rekomendasi di sini adalah bekerja sama dengan tim keamanan Anda untuk memastikan bahwa pernyataan tentang pengguna yang meminta disertakan dalam token akses, baik dengan penggunaan cakupan OAuth atau klaim JWT.

Meminta validasi dengan alur kondisional

Pada tingkat dasar, panggilan REST API terdiri dari hal berikut:

  • Endpoint
  • Referensi
  • Kata kerja tindakan
  • Jumlah atribut permintaan tambahan, seperti parameter kueri

Jenis serangan yang dijelaskan dalam ancaman ini biasanya disebabkan oleh pemfilteran permintaan API yang tidak memadai, sehingga memungkinkan penyerang melakukan tindakan atau akses yang tidak sah terhadap resource yang dilindungi. Selain logika kondisional yang memungkinkan Anda memfilter permintaan berdasarkan token atau klaim akses, Apigee memungkinkan implementasi logika pemfilteran berdasarkan permintaan itu sendiri.

Setelah Anda memahami dan menentukan logika bisnis produk API dengan jelas, fungsi apa saja yang diizinkan oleh API Anda, langkah berikutnya adalah membatasi permintaan apa pun yang berada di luar ini melalui fitur produk Apigee berikut:

  • Logika kondisional dan kebijakan Raise Fault untuk membatasi jalur atau kata kerja resource pada langkah apa pun dalam konfigurasi alur proxy
  • Kebijakan perlindungan terhadap ancaman JSON dan XML untuk melindungi dari serangan berbasis konten menggunakan payload permintaan JSON atau XML yang salah format

API6:Penetapan massal 2019

Deskripsi ancaman

Data yang tidak difilter yang disediakan melalui API ke aplikasi klien memungkinkan penyerang menebak properti objek melalui permintaan, atau menggunakan konvensi penamaan endpoint untuk mengetahui tempat melakukan modikasi atau mengakses properti yang tidak sah pada objek data yang disimpan di backend.

Ancaman ini disebabkan saat data yang tidak difilter (biasanya dalam JSON atau XML) dikirim ke klien, sehingga penyerang dapat menebak detail implementasi yang mendasari sistem backend Anda, serta nama properti elemen data rahasia. Hasil dari jenis serangan ini berpotensi memberi penyerang kemampuan untuk membaca atau memanipulasi data yang tidak pantas, atau dalam skenario terburuk, dapat mengaktifkan kerentanan eksekusi kode jarak jauh.

Ada dua aspek yang biasanya terlibat dalam memungkinkan jenis ancaman ini:

  • Perspektif desain API. Jangan pernah mengandalkan logika aplikasi untuk melakukan pemfilteran data sisi klien, karena aplikasi dapat dieksploitasi oleh penyerang dan dianggap tepercaya. Selalu desain skema data API Anda untuk hanya mengekspos data minimal yang diperlukan untuk mengaktifkan layanan API
  • Perspektif implementasi API. Terapkan pemfilteran data dan validasi skema untuk mencegah eksposur data rahasia yang tidak disengaja ke aplikasi klien

Dari perspektif produk Apigee, kami menyediakan beberapa fitur berguna untuk memastikan penerapan pemfilteran data yang andal untuk API Anda.

Kebijakan pemfilteran Spesifikasi OpenAPI

Kebijakan OASValidation (OpenAPI Specification Validation) memungkinkan Anda memvalidasi permintaan masuk atau pesan respons terhadap Spesifikasi OpenAPI 3.0 (JSON atau YAML). Kebijakan ini memungkinkan Anda untuk:

  1. Mendesain API dengan membuat spesifikasi OpenAPI (OAS)
  2. Menerapkan logika mediasi, keamanan, dan penyimpanan dalam cache yang diperlukan untuk mengekspos produk API dengan aman dari backend Anda dengan Apigee
  3. Memvalidasi permintaan yang masuk berdasarkan skema data yang ditentukan dalam spesifikasi OAS Anda, termasuk basepath, verb, request message policy, dan parameters

Kebijakan Validasi Pesan SOAP

Kebijakan validasi Pesan SOAP memungkinkan Anda memvalidasi permintaan berbasis XML, dengan memvalidasi pesan XML terhadap skema XSD, atau memvalidasi pesan SOAP terhadap definisi WSDL. Selain itu, Anda dapat menggunakan kebijakan Validasi Pesan untuk mengonfirmasi bahwa payload pesan JSON atau XML dibuat dengan benar, yang mencakup verifikasi hal berikut dalam pesan XML atau JSON:

  • Ada satu elemen root
  • Tidak ada karakter terlarang dalam konten
  • Objek dan tag disusun bertingkat dengan benar
  • Tag awal dan akhir cocok

API7:2019 Kesalahan konfigurasi keamanan

Deskripsi ancaman

Kesalahan konfigurasi keamanan biasanya merupakan hasil dari konfigurasi default yang tidak aman, konfigurasi ad hoc yang tidak lengkap atau terbuka, penyimpanan cloud terbuka, header HTTP yang salah dikonfigurasi, metode HTTP yang tidak perlu, Cross-Origin resource sharing (CORS) yang permisif, dan pesan error panjang yang berisi informasi sensitif. Penyerang sering kali mencoba menemukan kekurangan yang tidak di-patch, endpoint umum, atau file dan direktori yang tidak dilindungi untuk mendapatkan akses atau pengetahuan yang tidak sah tentang sistem yang ingin mereka serang. Konfigurasi keamanan yang salah tidak hanya dapat mengekspos data pengguna yang sensitif, tetapi juga detail sistem yang dapat menyebabkan server disusupi sepenuhnya. Selain itu, beberapa kasus penggunaan lainnya untuk kerentanan terkait kesalahan konfigurasi keamanan dapat mencakup:

  • TLS yang salah dikonfigurasi
  • Pesan error dengan stack trace
  • Sistem yang tidak di-patch
  • Panel pengelolaan server atau penyimpanan yang diekspos

Ada berbagai langkah yang dapat dilakukan organisasi untuk mengatasi dan memitigasi tantangan terkait kesalahan konfigurasi keamanan, yang mencakup:

  1. Menetapkan dan menstandarkan proses hardening dan patching
  2. Mengembangkan tata kelola di sekitar ekosistem API
  3. Membatasi akses administratif serta mengaktifkan audit dan pemberitahuan

Alur Bersama dan Flowhook

Apigee mendukung konsep alur bersama yang memungkinkan developer API menggabungkan kebijakan dan resource ke dalam grup yang dapat digunakan kembali. Dengan menangkap fungsi yang dapat digunakan kembali di satu tempat, alur bersama membantu Anda memastikan konsistensi, mempersingkat waktu pengembangan, dan mengelola kode dengan lebih mudah. Anda dapat menyertakan alur bersama di dalam setiap proxy API, atau Anda dapat melakukan langkah lebih lanjut dan menempatkan alur bersama di hook alur untuk mengeksekusi logika alur bersama secara otomatis untuk setiap proxy API yang di-deploy di lingkungan yang sama dengan alur bersama.

Pelaporan Keamanan API

Saat organisasi berupaya mengembangkan framework tata kelola, Apigee menyediakan kemampuan seputar pelaporan keamanan API yang membantu tim operasi dengan visibilitas yang mereka butuhkan untuk atribut keamanan API guna:

  • Memastikan kepatuhan terhadap kebijakan keamanan dan persyaratan konfigurasi
  • Melindungi data sensitif dari penyalahgunaan internal dan eksternal
  • Mengidentifikasi, mendiagnosis, dan menyelesaikan insiden keamanan secara proaktif

Pelaporan Keamanan Apigee memberikan insight mendalam bagi tim operasi untuk memastikan kepatuhan terhadap kebijakan dan persyaratan konfigurasi, melindungi API dari penyalahgunaan internal dan eksternal, serta mengidentifikasi dan menyelesaikan insiden keamanan dengan cepat.

Dengan pelaporan keamanan, administrator keamanan dapat dengan cepat memahami cara proxy API Anda dikonfigurasi untuk keamanan, serta kondisi runtime yang dapat memengaruhi keamanan proxy. Dengan menggunakan informasi ini, Anda dapat menyesuaikan konfigurasi untuk memastikan Anda memiliki tingkat keamanan yang sesuai untuk setiap proxy.

Pemantauan API

Apigee menyediakan platform Pemantauan API yang komprehensif yang melengkapi kemampuan pelaporan keamanan. Pemantauan API memungkinkan organisasi mendeteksi masalah performa dan traffic API secara proaktif. Pemantauan API Apigee berfungsi bersama dengan Apigee Edge untuk Public Cloud guna memberikan insight kontekstual real-time tentang performa API, membantu mendiagnosis masalah dengan cepat, dan memfasilitasi tindakan perbaikan untuk kelangsungan bisnis.

Gambar: Pemantauan API Apigee menyediakan berbagai alat untuk memantau, menyelidiki, dan mengatasi masalah. Fitur ini memanfaatkan fitur intelijen terbaik dari Google Cloud Platform.

Apigee Sense

Apigee Sense membantu melindungi API dari traffic permintaan yang tidak diinginkan, termasuk serangan dari klien berbahaya. Apigee Sense menganalisis traffic permintaan API, yang mengidentifikasi pola yang mungkin mewakili permintaan yang tidak diinginkan.

Dengan analisis ini, organisasi dapat mengidentifikasi klien yang membuat permintaan yang tidak diinginkan, lalu mengambil tindakan untuk mengizinkan, memblokir, atau menandai permintaan tersebut. Dengan Apigee Sense, Anda dapat melindungi API dari pola permintaan yang mencakup:

  • Perilaku otomatis yang menyatu dengan perilaku manusia
  • Upaya yang terus-menerus dari IP yang sama
  • Rasio error yang tidak biasa
  • Permintaan klien yang mencurigakan
  • Crawling data
  • Pengumpulan kunci
  • Lonjakan aktivitas
  • Pola geografis

Injeksi API8:2019

Deskripsi ancaman

Injeksi data yang tidak tepercaya, seperti SQL, NoSQL, XML Parser, ORM, LDAP, Perintah OS, dan JavaScript, ke dalam permintaan API dapat mengakibatkan eksekusi perintah yang tidak diinginkan atau akses data yang tidak sah. Penyerang akan memberi API data berbahaya melalui vektor injeksi apa pun yang tersedia seperti input langsung, parameter, layanan terintegrasi, dan sebagainya, dengan harapan data tersebut akan dikirim ke penafsir. Penyerang dapat menemukan kekurangan ini dengan mudah saat meninjau kode sumber menggunakan pemindai kerentanan dan fuzzer. Injeksi yang berhasil dapat menyebabkan pengungkapan informasi yang memengaruhi kerahasiaan dan kehilangan data, atau dalam beberapa kasus juga dapat menyebabkan DoS.

Praktik terbaik untuk mengurangi error/serangan injeksi mencakup penentuan data input secara ketat seperti skema, jenis, pola string, melakukan validasi input, pemeriksaan batas, dan menerapkannya saat runtime. Platform Apigee memungkinkan validasi data yang masuk menggunakan filter untuk hanya mengizinkan nilai yang valid untuk setiap parameter input.

Apigee Edge, yang bertindak sebagai server untuk permintaan API masuk, memeriksa untuk memastikan struktur payload berada dalam rentang yang dapat diterima, yang juga dikenal sebagai pemeriksaan batas. Anda dapat mengonfigurasi proxy API agar rutinitas validasi input mengubah input untuk menghapus urutan karakter berisiko dan menggantinya dengan nilai yang aman.

Kebijakan Perlindungan Ekspresi Reguler

Kebijakan RegularExpressionProtection mengekstrak informasi dari pesan (misalnya, Jalur URI, Parameter Kueri, Header, Parameter Formulir, Variabel, Payload XML, atau Payload JSON) dan mengevaluasi konten tersebut berdasarkan ekspresi reguler yang telah ditentukan. Jika ekspresi reguler yang ditentukan bernilai benar, pesan dianggap sebagai ancaman dan ditolak. Ekspresi reguler, atau regex, adalah kumpulan string yang menentukan pola dalam string. Ekspresi reguler memungkinkan konten dievaluasi secara terprogram untuk pola. Ekspresi reguler dapat digunakan, misalnya, untuk mengevaluasi alamat email guna memastikan alamat tersebut terstruktur dengan benar.

Penggunaan RegularExpressionProtection yang paling umum adalah evaluasi payload JSON dan XML untuk konten berbahaya.

Tidak ada ekspresi reguler yang dapat menghilangkan semua serangan berbasis konten, dan beberapa mekanisme harus digabungkan untuk mengaktifkan pertahanan menyeluruh. Bagian ini menjelaskan beberapa pola yang direkomendasikan untuk mencegah akses ke konten.

Ada beberapa pendekatan lain untuk memvalidasi input yang tersedia dengan platform Apigee:

Memvalidasi Jenis Konten

Jenis konten mengacu pada konten file yang ditransfer melalui HTTP dan diklasifikasikan sesuai dengan struktur dua bagian. Apigee merekomendasikan untuk memvalidasi jenis konten untuk Permintaan dan Respons menggunakan logika kondisional seperti yang dijelaskan di bawah.

Pelaporan Keamanan API

Saat organisasi berupaya mengembangkan framework tata kelola, Apigee menyediakan kemampuan seputar pelaporan keamanan API, yang membantu dan memberi tim operasi visibilitas yang mereka perlukan untuk mengamankan API dengan memberikan visibilitas yang mereka perlukan untuk atribut keamanan API guna:

  • Pastikan kepatuhan terhadap kebijakan keamanan dan persyaratan konfigurasi.
  • Melindungi data sensitif dari penyalahgunaan internal dan eksternal.
  • Mengidentifikasi, mendiagnosis, dan menyelesaikan insiden keamanan secara proaktif.

API9:2019 Manajemen aset yang tidak tepat

Deskripsi Ancaman

Pengelolaan lingkungan dan pemisahan lingkungan yang tidak memadai memungkinkan penyerang mengakses endpoint API yang kurang aman. Kurangnya pengamanan tata kelola juga menyebabkan eksposur resource yang tidak digunakan lagi secara tidak perlu.

Ancaman ini dapat diatasi dengan memanfaatkan kemampuan Apigee yang matang untuk mengelola siklus proses API secara menyeluruh, sehingga Anda dapat membuat model tata kelola komprehensif yang memungkinkan kolaborasi antartim, dan pada saat yang sama, menerapkan pemisahan tanggung jawab antara pemangku kepentingan keamanan dan developer API. Batas dan kontrol dapat dikonfigurasi dan dikelola menggunakan:

Organisasi, Lingkungan, dan Revisi: Pembatasan virtual dan fisik yang menjamin isolasi dan proses promosi yang aman melalui konteks runtime.

Role Based Access Control: Hanya orang yang diperlukan di tim API Anda yang akan memiliki izin untuk mengelola perubahan konfigurasi dan juga proses promosi.

Pengelolaan Audiens untuk Dokumentasi API: Setelah API dipublikasikan di portal developer, Anda dapat membatasi visibilitas dokumentasi dengan mengelola target audiens.

Flow Hooks: Anda dapat menerapkan kebijakan dan pola global yang dapat dikelola sebagai pembatasan dengan hak istimewa yang tidak dapat diubah oleh developer API.

Pelaporan Keamanan: Pemangku kepentingan keamanan memiliki visibilitas menyeluruh terhadap API yang dipublikasikan dan konfigurasi pendukungnya. Kepatuhan terhadap kebijakan keamanan global dapat diaudit dan dievaluasi berdasarkan profil risiko untuk setiap endpoint API yang dipublikasikan.

Organisasi dan Lingkungan

Artefak, pengguna, dan fitur konfigurasi di Apigee dapat dicakup untuk organisasi dan/atau lingkungan tertentu. Artinya, platform ini memiliki pembatasan bawaan yang dapat ditempatkan di sekitar API dan konfigurasi pendukungnya.

Organisasi: Organisasi adalah tenant tingkat teratas di Apigee. Hal ini memungkinkan Anda memiliki pemisahan penuh untuk traffic, konfigurasi, dan pengguna. Sebagai praktik terbaik tata kelola, Anda harus mempertimbangkan untuk memiliki organisasi produksi dan non-produksi yang terpisah. Praktik ini secara efektif menghindari pencampuran data produksi, pengguna, dan traffic dengan lingkungan yang lebih rendah.

Lingkungan: API di Apigee dapat dipromosikan melalui beberapa status deployment; setiap status ditautkan ke konteks eksekusi. Konteks lingkungan tidak disertakan selama proses promosi, sehingga menghindari eksposur konfigurasi sensitif kepada pengguna yang tidak memiliki hak istimewa.

Revisi: Revisi memungkinkan API dan fitur individual dipromosikan dengan lancar melalui lingkungan.

Kontrol Akses Berbasis Peran

Untuk mengurangi API9, Anda harus memiliki definisi dan pemisahan tugas yang jelas antara pemangku kepentingan keamanan dan Developer API. Seperti yang dinyatakan sebelumnya dalam dokumen ini, Apigee memiliki kemampuan Role Based Access Control yang fleksibel yang memungkinkan Anda menetapkan izin ke peran kustom. Untuk ancaman khusus ini, peran dapat dicakup untuk memiliki hak istimewa terbatas per organisasi, lingkungan, atau izin konfigurasi yang lebih terperinci. Sebagai praktik yang lebih disukai, pertimbangkan untuk membatasi hak istimewa guna mengubah status deployment API melalui lingkungan dan juga untuk memastikan developer tidak dapat mengakses atau mengubah library keamanan global (Flow Hooks). Peran terbatas ini akan mencegah perubahan yang tidak diminta pada kebijakan keamanan global yang memiliki cakupan luas pada endpoint lama dan yang dipublikasikan saat ini.

Dokumentasi Pengelolaan Audiens untuk API

Portal Developer adalah komponen penting untuk keberhasilan Strategi API Anda; portal ini memungkinkan Anda menyimpan inventaris komprehensif dari semua dokumentasi yang terkait dengan API Anda, termasuk host/endpoint, resource, operasi, skema payload, dan lainnya. Di Apigee, Anda dapat mengelompokkan API menggunakan konstruksi Produk API. Produk API ditentukan oleh paket resource dan operasi yang berada dalam konteks bisnis dan keamanan yang sama (misalnya, paket layanan, domain bisnis, kategori, hierarki perusahaan, dll.).

Dengan Portal Developer Terintegrasi Apigee, Anda dapat memublikasikan Produk API dan membatasi visibilitas konten yang dipublikasikan dengan mengelola target audiens. Kemampuan ini mematuhi strategi segmentasi konten yang selaras dengan persyaratan bisnis dan keamanan.

Flow Hook

Proses promosi dan rilis untuk API harus selalu menyertakan proses kepatuhan dan sertifikasi keamanan. Agar efektif, tim API yang menggunakan alat yang sesuai harus dapat membuat pembatasan yang menjamin pemisahan tanggung jawab dan mempertahankan siklus rilis yang lincah.

Apigee memungkinkan Anda meningkatkan tugas tata kelola keamanan dengan menerapkan kebijakan global melalui Hook Alur. Kebijakan global ini dapat dikelola sebagai pembatasan hak istimewa yang tidak dapat diubah oleh developer API, sehingga menjamin pemisahan tanggung jawab dan juga mendorong fleksibilitas dengan menerapkan keamanan default dan, secara luas, memberikan kepatuhan keamanan untuk semua API yang di-deploy di lingkungan eksekusi tertentu.

Gambar: Pembatasan dengan hak istimewa dapat dikonfigurasi di Apigee melalui Hook Aliran dan Aliran Bersama. Pemangku kepentingan keamanan bertanggung jawab untuk mempertahankan kebijakan global terkait keamanan. Fitur ini menjamin pemisahan tanggung jawab dan mendorong siklus proses pengembangan yang gesit.

Pelaporan Keamanan

Audit keamanan dimaksudkan untuk menilai dan menguji kebijakan keamanan yang dimaksudkan untuk melindungi data dan tujuan bisnis organisasi Anda. API adalah antarmuka publik atau pribadi standar yang perlu dilindungi oleh model tata kelola keamanan yang komprehensif dan sekaligus dapat diaudit.

Di Apigee, Anda memiliki akses ke laporan keamanan khusus yang membantu memastikan kepatuhan terhadap kebijakan yang ditentukan dan memungkinkan tim keamanan Anda mengambil tindakan berdasarkan insight komprehensif tentang:

Traffic Runtime: Tampilan terpadu untuk insight traffic API di: Server Target, Virtual Host, konfigurasi TLS, perubahan traffic per lingkungan, dan lainnya.

Konfigurasi: Kemampuan audit untuk konfigurasi proxy API yang memberikan visibilitas menyeluruh atas semua kebijakan yang diterapkan di tingkat Proxy API dan juga spektrum penerapan alur bersama yang dilampirkan di tingkat organisasi atau proxy.

Aktivitas Pengguna: Melacak operasi sensitif yang dilakukan oleh pengguna platform. Analisis aktivitas mencurigakan dengan melihat perincian aktivitas mencurigakan.

API10:2019 Logging & pemantauan yang tidak memadai

Deskripsi Ancaman

Pencatatan log, pemantauan, dan pemberitahuan yang tidak memadai memungkinkan serangan yang sedang berlangsung tidak terdeteksi, sehingga strategi harus diperlukan untuk mendapatkan insight tentang peristiwa penting yang berdampak pada bisnis Anda.

Strategi pengelolaan peristiwa dan logging untuk API harus mempertimbangkan praktik terbaik berikut:

  • Kebijakan Pengelolaan Log: Mendokumentasikan dan menerapkan aturan untuk menstandarkan dan mengontrol detail log, level log, integritas log, repositori terpusat, dan lainnya
  • Kebijakan Pengelolaan Peristiwa: Memastikan bahwa setiap peristiwa harus dapat dilacak ke sumbernya. Selain itu, peristiwa harus dapat dikategorikan berdasarkan tingkat keparahan dan dampak bisnis
  • Laporan dan Audit: Pemangku kepentingan keamanan dan operasi harus dapat mengakses dan bereaksi terhadap log dan peristiwa secara real time. Selain itu, siklus penguatan dapat dilakukan oleh pemangku kepentingan untuk menyesuaikan pola deteksi berdasarkan data historis

Apigee menyediakan alat yang diperlukan untuk membuat strategi pengelolaan logging dan peristiwa yang komprehensif. Alat ini mencakup:

Kebijakan Logging Pesan: Membuat aliran log berdasarkan data traffic atau metadata dari traffic API Anda. Anda memiliki fleksibilitas untuk menentukan panjang aliran data dengan memanfaatkan logika bersyarat dan template pesan.

Google Cloud Operation Suite: Manfaatkan integrasi siap pakai ke dalam alat pemantauan dan logging yang sangat skalabel dari Google.

Kebijakan Info Layanan: Menambahkan dukungan untuk aliran log yang memerlukan endpoint HTTP untuk mengirim peristiwa.

Analytics: Mengakses dan menganalisis metadata traffic historis melalui laporan siap pakai dan/atau yang disesuaikan. Buat dan kelola pemberitahuan berdasarkan tren dan pahami anomali traffic.

Pemantauan API: Seperti yang dijelaskan sebelumnya, alat ini menyediakan kemampuan pemberitahuan yang dapat dipicu berdasarkan peristiwa penting. Log traffic dapat dianalisis dan ditindaklanjuti lebih lanjut.