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 tahun 2021 OWASP di Google Cloud.

Pengantar

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

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

Dengan pertumbuhan ekosistem API yang pesat, penyalahgunaan dan penyalahgunaan API yang mengakibatkan pemindahan data yang tidak sah oleh penyerang sayangnya menjadi salah satu vektor serangan yang 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, merancang dan mengimplementasikan fitur keamanan Apigee secara tepat sangat penting untuk mengurangi kemungkinan keberhasilan serangan pada API Anda.

Aplikasi Konsumen harus dianggap tidak tepercaya, atau "publik", karena Anda tidak mengontrol platform tempat aplikasi berjalan. Asumsikan bahwa setiap aplikasi publik dapat dan akan disusupi, aplikasi tersebut tidak dapat dipercaya untuk menerapkan kontrol akses (API1, API5), data respons filter (API6), atau menyimpan rahasia klien dengan aman (API2) seperti kunci API atau token akses. Beberapa rekomendasi muncul setelah menilik 10 teratas versi OWASP tahun 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 disarankan)
  • 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 hal ini.
  • Filter semua permintaan data yang berisi PII khusus pengguna agar hanya mengizinkan data dari backend yang dimiliki pengguna yang meminta.

API1:2019 Otorisasi level objek rusak

Deskripsi ancaman

Validasi otorisasi permintaan akses objek yang tidak memadai 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 JSON Web Token (JWT), yang membantu melindungi dari kerentanan ini. Namun, kebijakan ini harus dikonfigurasi dengan benar untuk mencegah ancaman ini.

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

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

  • Integritas token akses
  • Penerapan kontrol akses

Integritas Token Akses

Sangat penting untuk memvalidasi bahwa token yang diberikan oleh klien yang meminta tidak dirusak, 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, penerapan kebijakan penerapan kontrol akses sangat penting 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 dalam gambar di atas) direkomendasikan jika model kontrol akses relatif sederhana. Misalnya, jika klaim yang diekstrak dari token akses dapat digunakan untuk mengevaluasi dan memberikan otorisasi secara langsung atas permintaan objek API.

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

Pendekatan yang didelegasikan (diilustrasikan dalam gambar di atas) direkomendasikan jika klaim yang diekstrak dari token akses tidak dapat langsung digunakan untuk mengizinkan 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, untuk kemudian membuat keputusan kontrol akses menggunakan alur bersyarat

API2:2019 Autentikasi pengguna yang rusak

Deskripsi ancaman

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

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

Dengan paradigma di luar dari dalam, desain API dibuat berdasarkan kasus penggunaan data konsumen, bukan struktur data yang ada di sistem backend Anda, dan keamanan adalah elemen penting saat mendesain API untuk konsumen eksternal. Sistem backend secara tradisional tidak dibangun dengan implementasi autentikasi yang cukup kuat untuk paparan ke jaringan publik. Di sinilah Apigee, ditambah dengan solusi pengelolaan akses dan identitas, dapat menawarkan solusi kuat untuk memberikan perlindungan dari ancaman ini.

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

  • Desain keamanan: memanfaatkan sepenuhnya fitur Apigee untuk mengimplementasikan pola autentikasi
  • Tata kelola: memastikan penggunaan yang benar atas pola autentikasi yang dirancang digunakan secara konsisten, di semua produk API yang dipublikasikan
  • Keamanan operasional: mampu mendeteksi perilaku yang mencurigakan atau tidak wajar, serta mencoba menghindari atau melakukan brute force proxy API yang diautentikasi

Desain Keamanan

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

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

Kebijakan autentikasi

Kebijakan Apigee yang membantu mengatasi masalah identitas dan autentikasi meliputi:

Pengelolaan Traffic

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

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

Tata kelola

Keamanan adalah proses berkelanjutan, bukan project "tetapkan dan lupakan", dan salah satu penyebab terbesar pelanggaran keamanan adalah kesalahan konfigurasi. Setelah alur autentikasi, pola integrasi identitas, dan kebijakan pengelolaan traffic terkait autentikasi ditentukan, penerapan kebijakan tersebut dengan benar dan konsisten sangatlah penting.

Apigee menyediakan sejumlah fitur dan alat untuk memastikan integritas implementasi serta mencegah error kesalahan konfigurasi.

Kontrol akses berbasis peran, {i>Role-based access control<i}

Baik Anda berupa perusahaan besar atau startup kecil, upaya untuk menghindari error konfigurasi dimulai dengan memastikan bahwa hanya orang dan tim yang tepat yang dapat mengakses dan mengubah konfigurasi proxy API. Program API didukung oleh tim multidisiplin di seluruh organisasi Anda. Sangatlah penting bagi setiap tim untuk hanya diberi izin yang diperlukan agar dapat melakukan tugas mereka 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 salah satu peran yang telah ditetapkan, atau untuk membuat peran khusus 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 mengintegrasikan dengan direktori perusahaan yang ada, dan mengurangi kebutuhan untuk mengelola set 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 berkolaborasi dengan tim keamanan untuk mendesain beberapa pola desain autentikasi berdasarkan jenis aplikasi yang menggunakan API. Developer API tidak perlu menjadi pakar identitas untuk menggunakan kembali fitur ini, tetapi hanya perlu mengetahui alur bersama yang benar untuk ditambahkan ke konfigurasi proxy API yang ada menggunakan kebijakan Info Alur.

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

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 Operasi API Lanjutan Apigee yang baru mencakup pelaporan keamanan lanjutan, yang memungkinkan tim Operasional dan keamanan melihat laporan dengan mudah di semua proxy API, 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 API10: logging tidak memadai, tetapi dari perspektif mencegah risiko autentikasi rusak, hal ini sangat berguna dalam memastikan kepatuhan terhadap standar autentikasi yang ditentukan yang diterapkan sebagai alur bersama.

Keamanan Operasional

Setelah API Anda diproduksi menggunakan pola autentikasi yang tepat dengan pengelolaan traffic dasar, tim SecOps Anda juga harus dapat memantau dan merespons aktivitas mencurigakan, yang sering kali dimulai dengan upaya penyusupan 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, dengan 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 meliputi:

  • Perilaku otomatis yang menyatu dengan perilaku manusia
  • Upaya terus-menerus dari IP yang sama
  • Tingkat kesalahan yang tidak biasa
  • Permintaan klien yang mencurigakan
  • Crawl data
  • Serangan {i>brute force<i} untuk pengambilan kunci dan autentikasi
  • burst aktivitas
  • Pola geografis

Operasi API Lanjutan

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

Deteksi anomali bekerja 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 terpikirkan untuk meningkatkan produktivitas dan mengurangi waktu rata-rata untuk penyelesaian (MTTR) masalah API Anda.

Operasi API Lanjutan di-build berdasarkan mekanisme pemberitahuan API Monitoring yang ada untuk menambahkan jenis pemberitahuan lanjutan berikut:

  • Total notifikasi traffic. Memicu peringatan saat traffic berubah menurut persentase yang ditentukan selama rentang waktu tertentu. Misalnya, Anda dapat membuat 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 sendiri. Anda kemudian dapat meningkatkan peringatan untuk anomali ini
  • Notifikasi Masa Berlaku TLS. Meningkatkan notifikasi saat sertifikat TLS hampir habis masa berlakunya

API3:2019 Eksposur data yang berlebihan

Deskripsi ancaman

API yang dipublikasikan mungkin mengekspos data lebih banyak 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 parsimony data. Bekerja samalah dengan desainer dan developer UX agar hanya mengekspos data melalui API yang diperlukan dalam UI aplikasi Anda. Sistem backend tidak dibangun untuk pola penggunaan publik, sehingga salah satu tugas pertama dari desain API pertama dengan Apigee adalah mengurangi data yang terekspos ke minimum yang diperlukan untuk menyediakan produk API yang bagus bagi pelanggan dan developer Anda.

Salah satu prinsip desain Apigee lainnya adalah penggunaan kembali. Di samping masalah keamanan, mengandalkan aplikasi untuk memfilter data yang disediakan oleh API berarti Anda harus mem-port logika pemfilteran tersebut di setiap platform yang aplikasinya Anda kembangkan.

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

Bagian berikutnya mempelajari cara:

  • Tulis ulang permintaan dan respons ke layanan backend untuk meminimalkan eksposur data
  • Implementasikan penanganan kesalahan untuk mencegah pesan error yang panjang agar tidak mengekspos informasi lingkungan yang sensitif kepada penyerang tentang layanan backend Anda

Menulis ulang respons dan permintaan

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

Untuk melakukannya, Apigee menggunakan tiga kebijakan utama:

  • Tetapkan Pesan
  • Info kode
  • Penanganan error

Tetapkan kebijakan Pesan

Kebijakan Assign Message 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 lainnya
  • Hapus header, parameter kueri, parameter formulir, dan/atau payload pesan dari pesan
  • Tetapkan nilai properti yang ada dalam pesan

Dengan Tetapkan Pesan, Anda biasanya menambahkan, mengubah, atau menghapus properti permintaan maupun 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 rumit dengan kode kustom

Untuk aturan penanganan data yang kompleks dan penulisan ulang yang kompleksitasnya di luar 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 prosedur dirancang untuk memudahkan Anda menerapkan penanganan yang kompleks terhadap variabel alur, kesalahan, serta isi permintaan dan respons.

Dengan kode prosedur, Anda dapat:

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

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

Penanganan fault

Apigee memungkinkan Anda melakukan penanganan pengecualian kustom menggunakan kebijakan jenis Raise Fault. Kebijakan Raise Fault, yang merupakan variasi dari kebijakan Tetapkan Pesan, memungkinkan Anda menghasilkan respons kesalahan kustom sebagai respons terhadap kondisi error.

Alur Bersama

Alur bersama dapat digunakan untuk menerapkan standardisasi pesan kesalahan. 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 Penahanan Lonjakan sebagai kontrol preventif untuk membatasi traffic pada permintaan API masuk
  • Apigee Sense untuk mendeteksi dan merespons serangan berbasis bot secara dinamis
  • Pemantauan dan pemberitahuan API lanjutan sebagai kontrol detektif yang akan diperingatkan tentang serangan DDoS yang sedang berlangsung

Pembatasan kapasitas dengan kebijakan Kuota dan Penahanan Lonjakan

Apigee menyediakan dua kebijakan untuk pembatasan kapasitas:

  • Spike arrest menyediakan kebijakan umum, yang ditetapkan pada level proxy API, untuk pembatasan kapasitas jumlah keseluruhan permintaan masuk ke backend
  • Kuota menyediakan alat kebijakan terperinci untuk menerapkan kebijakan kuota, baik pada proxy API atau pada level produk API

Penangkapan Lonjakan

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

Kuota

Kebijakan Quota 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 menetapkan kuota berdasarkan:

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

Kebijakan ini lebih terperinci daripada penangkapan lonjakan lonjakan, dan umumnya harus digunakan secara bersamaan dengannya.

Deteksi bot dengan Apigee Sense

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

Deteksi ancaman dengan Advanced API Ops Monitoring

Gunakan pemberitahuan traffic untuk mengaktifkan notifikasi saat traffic untuk lingkungan, proxy, atau region berubah sebesar persentase yang ditentukan selama rentang waktu tertentu. Fitur ini dapat memunculkan peringatan secara dinamis ketika traffic menyimpang jauh dari throughput yang diharapkan, seperti yang terjadi selama serangan DDoS. Pemberitahuan ini dapat dengan mudah dikirim ke solusi logging dan pemantauan pihak ketiga.

API5:2019 Otorisasi level fungsi rusak

Deskripsi ancaman

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

Ancaman jenis ini menyoroti manfaat 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 yang berisiko tinggi.

Elemen konseptual untuk mengurangi kemungkinan ancaman ini biasanya dipecah menjadi:

  • Apa saja yang dilindungi? Pikirkan strategi produk API Anda, dan terapkan segmentasi fungsi secara logis saat menggunakan praktik terbaik RESTful untuk mendesain jalur dan resource yang diekspos oleh proxy, produk, dan fitur aplikasi Apigee API.
  • Siapa saja yang mengakses resource API Anda? Tentukan persona tingkat tinggi dan terapkan hak akses default “hak istimewa terendah” menggunakan beberapa fitur autentikasi dan otorisasi Apigee seperti yang diuraikan dalam API1 dan API2.
  • Bagaimana kebijakan akses Anda ditegakkan? Gunakan flow dan fault kondisional untuk memvalidasi jalur URL dan verb dari semua permintaan API.

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

Logical Segmentation dengan proxy, produk, dan aplikasi API

Apigee menyediakan toolkit yang sangat fleksibel untuk mengaktifkan segmentasi logis resource API, yang memungkinkan proxy API digabungkan ke dalam sejumlah produk API, yang kemudian digunakan oleh developer aplikasi Anda, yang dapat mendaftarkan aplikasi yang menggunakan produk API Anda. Kebijakan akses dapat ditentukan di salah satu tingkat berikut.

Sebelum menerapkan otorisasi dan segmentasi fungsional yang efektif, sangat penting untuk menentukan strategi produk API. Bagian dari proses yang penting dan berkelanjutan ini adalah definisi “siapa” dan “apa” dari produk API Anda, dengan melihat resource API dari perspektif pelanggan dan developer, lalu menentukan ke resource jalur dan level 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 memadupadankan resource untuk membuat tingkat pemakaian 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 terperinci di level objek, kontrol akses terperinci di level fungsi juga sama pentingnya. Apakah pengguna yang meminta diizinkan untuk meminta jalur URL ini? Jenis kebijakan ini sering ditentukan per persona pengguna (pelanggan, karyawan, administrator, developer internal, atau pihak ketiga).

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

Meminta validasi dengan alur bersyarat

Pada level dasar, panggilan REST API terdiri dari:

  • Sebuah endpoint
  • Resource
  • Kata kerja tindakan
  • Sejumlah 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 yang tidak sah atau mengakses resource yang dilindungi. Selain logika kondisional yang memungkinkan Anda memfilter permintaan berdasarkan token akses atau klaim, 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 selanjutnya adalah membatasi permintaan apa pun yang berada di luar logika tersebut melalui fitur produk Apigee berikut:

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

Penetapan Massa API6: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 mendapatkan petunjuk tentang tempat melakukan modifikasi yang tidak sah atau mengakses properti pada objek data yang disimpan di backend.

Ancaman ini terjadi ketika data yang tidak difilter (biasanya dalam JSON atau XML) dikirim ke klien, yang memungkinkan penyerang menebak detail implementasi yang mendasarinya dari sistem backend Anda, serta nama properti dari elemen data rahasia. Akibat dari serangan jenis ini dapat 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 agar hanya mengekspos data minimal yang diperlukan untuk mengaktifkan layanan API
  • Perspektif penerapan API. Terapkan pemfilteran data dan validasi skema untuk mencegah eksposur data rahasia secara tidak sengaja ke aplikasi klien

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

Kebijakan pemfilteran Spesifikasi OpenAPI

Kebijakan OASValidation (Validasi Spesifikasi OpenAPI) memungkinkan Anda memvalidasi permintaan atau pesan respons yang masuk berdasarkan Spesifikasi OpenAPI 3.0 (JSON atau YAML). Kebijakan ini memungkinkan Anda:

  1. Rancang API Anda dengan membuat spesifikasi OpenAPI (OAS)
  2. Implementasikan logika mediasi, keamanan, dan caching yang diperlukan untuk mengekspos produk API dengan aman dari backend Anda dengan Apigee
  3. Validasi permintaan masuk terhadap skema data yang ditentukan dalam spesifikasi OAS Anda, termasuk jalur basis, verb, kebijakan pesan permintaan, dan parameter

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 berdasarkan definisi WSDL. Selain itu, Anda dapat menggunakan kebijakan Validasi Pesan untuk mengonfirmasi bahwa payload pesan JSON atau XML tersusun dengan baik, yang mencakup verifikasi hal berikut dalam pesan XML atau JSON:

  • Ada satu elemen {i>root<i}
  • Tidak ada karakter ilegal dalam konten tersebut
  • Objek dan tag disusun bertingkat dengan benar
  • Tag awal dan akhir cocok

API7:2019 Kesalahan konfigurasi keamanan

Deskripsi ancaman

Kesalahan konfigurasi keamanan biasanya disebabkan oleh konfigurasi default yang tidak aman, konfigurasi ad-hoc atau tidak lengkap, penyimpanan cloud terbuka, header HTTP yang salah dikonfigurasi, metode HTTP yang tidak diperlukan, berbagi resource Cross-Origin (CORS) yang permisif, dan pesan error panjang yang berisi informasi sensitif. Penyerang sering mencoba menemukan cacat yang tidak di-patch, endpoint umum, atau file dan direktori yang tidak dilindungi untuk mendapatkan akses tidak sah atau pengetahuan tentang sistem yang ingin diserang. Kesalahan konfigurasi keamanan tidak hanya dapat mengekspos data pengguna yang sensitif, tetapi juga detail sistem yang dapat menyebabkan penyusupan server secara penuh. Selain itu, beberapa kasus penggunaan lain untuk kerentanan kesalahan konfigurasi keamanan dapat mencakup:

  • TLS yang salah dikonfigurasi
  • Pesan error dengan pelacakan tumpukan
  • Sistem yang tidak di-patch
  • Panel pengelolaan server atau penyimpanan terekspos

Ada berbagai langkah yang dapat diambil organisasi untuk mengatasi dan memitigasi tantangan terkait kesalahan konfigurasi keamanan yang meliputi:

  1. Menetapkan dan menstandardisasi proses hardening dan patching
  2. Mengembangkan tata kelola seputar ekosistem API
  3. Membatasi akses administratif serta mengaktifkan pengauditan dan pemberitahuan

Alur Bersama dan Pengikat Alur

Apigee mendukung konsep alur bersama yang memungkinkan developer API menggabungkan kebijakan dan resource ke dalam satu grup yang dapat digunakan kembali. Dengan mengambil fungsionalitas yang dapat digunakan kembali di satu tempat, alur bersama akan 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 melangkah lebih jauh dan menempatkan alur bersama di hook alur untuk otomatis menjalankan logika alur bersama bagi setiap proxy API yang di-deploy di lingkungan yang sama dengan alur bersama.

Pelaporan Keamanan API

Saat organisasi berusaha mengembangkan framework tata kelola, Apigee menyediakan kemampuan seputar pelaporan keamanan API yang membantu tim operasi visibilitas bahwa mereka membutuhkan atribut keamanan API untuk:

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

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 konfigurasi proxy API Anda untuk keamanan, serta kondisi runtime yang mungkin memengaruhi keamanan proxy. Dengan menggunakan informasi ini, Anda dapat menyesuaikan konfigurasi untuk memastikan bahwa Anda memiliki tingkat keamanan yang sesuai untuk setiap proxy.

Pemantauan API

Apigee menyediakan platform Pemantauan API komprehensif yang melengkapi kemampuan pelaporan keamanan. Dengan Pemantauan API, organisasi dapat mendeteksi traffic dan masalah performa API secara proaktif. Apigee API Monitoring bekerja sama 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: Monitoring API Apigee menyediakan berbagai alat untuk memantau, menyelidiki, dan menindaklanjuti masalah. Google Cloud Platform memanfaatkan fitur kecerdasan terbaik di kelasnya 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, dengan 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 terus-menerus dari IP yang sama
  • Tingkat kesalahan yang tidak biasa
  • Permintaan klien yang mencurigakan
  • Crawl data
  • Pengumpulan kunci
  • burst aktivitas
  • Pola geografis

API8:Injeksi 2019

Deskripsi ancaman

Injeksi data yang tidak tepercaya, seperti SQL, NoSQL, Parser XML, 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 memberikan data berbahaya ke API melalui vektor injeksi apa pun yang tersedia, seperti input langsung, parameter, layanan terintegrasi, dan sebagainya, dengan harapan akan dikirim ke penafsir. Penyerang dapat menemukan kecacatan 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, informasi tersebut 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 penerapannya saat runtime. Platform Apigee memungkinkan validasi data yang masuk menggunakan filter agar hanya mengizinkan nilai yang valid untuk setiap parameter input.

Apigee Edge, yang bertindak sebagai server untuk permintaan API yang masuk, memeriksa untuk memastikan bahwa 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 yang berisiko dan menggantinya dengan nilai yang aman.

Kebijakan Perlindungan Ekspresi Reguler

Kebijakan RegularExpressionProtection mengekstrak informasi dari pesan (misalnya, URI Path, Query Param, Header, Form Param, Variable, XML Payload, atau JSON Payload) dan mengevaluasi konten tersebut berdasarkan ekspresi reguler yang telah ditetapkan. Jika ekspresi reguler yang ditentukan bernilai benar (true), pesan akan dianggap sebagai ancaman dan akan ditolak. Ekspresi reguler, atau disingkat ekspresi reguler, adalah kumpulan string yang menetapkan pola dalam string. Ekspresi reguler memungkinkan konten dievaluasi secara terprogram untuk menemukan pola. Ekspresi reguler dapat digunakan, misalnya, untuk mengevaluasi alamat email guna memastikan bahwa strukturnya 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 memungkinkan pertahanan mendalam. Bagian ini menjelaskan beberapa pola yang direkomendasikan untuk mencegah akses ke konten.

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

Validasi 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 berusaha mengembangkan framework tata kelola, Apigee menyediakan kemampuan seputar pelaporan keamanan API, yang membantu dan memberi tim operasi visibilitas yang mereka butuhkan untuk mengamankan API dengan memberikan visibilitas kepada tim operasi yang membutuhkan atribut keamanan API untuk:

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

API9:2019 Pengelolaan aset yang tidak tepat

Deskripsi Ancaman

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

Ancaman ini dapat diatasi dengan memanfaatkan kemampuan Apigee yang matang untuk mengelola siklus proses API secara penuh, 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: Pelindung virtual dan fisik yang menjamin isolasi dan proses promosi yang aman melalui konteks runtime.

Kontrol Akses Berbasis Peran: 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 Hook: Anda dapat menerapkan kebijakan dan pola global yang dapat dikelola sebagai pagar pembatas dengan hak istimewa yang tidak dapat dimodifikasi oleh developer API.

Pelaporan Keamanan: Pemangku kepentingan keamanan memiliki visibilitas end-to-end untuk 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 konfigurasi, pengguna, dan fitur di Apigee dapat dicakup ke organisasi dan/atau lingkungan tertentu. Artinya, platform ini memiliki pagar pembatas 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 secara 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 mengekspos 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 memitigasi API9, penting untuk memiliki definisi dan pemisahan tugas yang jelas antara pemangku kepentingan keamanan dan Developer API. Seperti yang disebutkan sebelumnya dalam dokumen ini, Apigee memiliki kemampuan Kontrol Akses Berbasis Peran fleksibel yang memungkinkan Anda menetapkan izin ke peran khusus. Untuk ancaman khusus ini, peran dapat tercakup sehingga memiliki hak istimewa terbatas per organisasi, lingkungan, atau izin konfigurasi yang lebih terperinci. Sebagai praktik yang disukai, pertimbangkan untuk membatasi hak istimewa guna mengubah status deployment API melalui lingkungan dan juga untuk memastikan developer tidak dapat mengakses atau memodifikasi library keamanan global (Flow Hook). Peran yang terbatas ini akan mencegah perubahan yang tidak diminta terhadap kebijakan keamanan global yang memiliki cakupan luas, baik pada endpoint lama maupun yang saat ini dipublikasikan.

Pengelolaan Audiens untuk Dokumentasi API

Portal Developer adalah komponen penting untuk keberhasilan Strategi API. Portal ini memungkinkan Anda untuk menyimpan inventaris semua dokumentasi yang komprehensif terkait API Anda, termasuk host/endpoint, resource, operasi, skema payload, dan banyak lagi. Di Apigee, Anda dapat mengelompokkan API menggunakan konstruksi Produk API. Produk API ditentukan berdasarkan 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 sesuai dengan strategi segmentasi konten yang selaras dengan persyaratan bisnis dan keamanan.

Kait Aliran

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 menciptakan pagar pembatas yang menjamin pemisahan tanggung jawab dan sekaligus mempertahankan siklus rilis yang tangkas.

Dengan Apigee, Anda dapat meningkatkan tugas tata kelola keamanan dengan menerapkan kebijakan global melalui Flow Hook. Kebijakan global ini dapat dikelola sebagai pagar pengaman istimewa yang tidak dapat diubah oleh developer API, sehingga menjamin pemisahan tanggung jawab dan juga meningkatkan ketangkasan dengan menerapkan keamanan default dan, oleh karena itu, memberikan kepatuhan keamanan untuk semua API yang di-deploy di lingkungan eksekusi tertentu.

Gambar: Pagar pembatas khusus dapat dikonfigurasi di Apigee melalui Flow Hook dan Flow Bersama. Pemangku kepentingan keamanan bertanggung jawab untuk memelihara kebijakan global yang terkait dengan keamanan. Fitur-fitur ini menjamin pemisahan tanggung jawab dan mendukung siklus proses pengembangan yang dinamis.

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 terstandardisasi yang perlu dilindungi oleh model tata kelola keamanan yang komprehensif dan, pada saat yang sama, dapat diaudit.

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

Traffic Runtime: Tampilan terpadu untuk insight traffic API tentang Server Target, Host Virtual, 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 level Proxy API dan juga spektrum penerapan alur bersama yang terpasang 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 tidak memadai

Deskripsi Ancaman

Logging, pemantauan, dan pemberitahuan yang tidak memadai memungkinkan serangan yang sedang berlangsung tidak terdeteksi, sehingga diperlukan strategi 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 panjang log, level log, integritas log, repositori terpusat, dan lainnya
  • Kebijakan Pengelolaan Peristiwa: Menjamin bahwa setiap peristiwa harus dapat dilacak ke sumbernya. Selain itu, peristiwa harus dapat dikategorikan berdasarkan kekritisan dan dampak bisnis
  • Laporan dan Audit: Pemangku kepentingan keamanan dan operasi harus dapat mengakses serta merespons log dan peristiwa secara real time. Selain itu, siklus penguatan dapat dilakukan oleh pemangku kepentingan untuk menyesuaikan pola deteksi berdasarkan data historis

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

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

Cloud Operation Suite Google: Manfaatkan integrasi siap pakai ke 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: Akses dan analisis metadata traffic historis melalui laporan langsung dan/atau laporan yang disesuaikan. Buat dan kelola notifikasi 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.