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 berdedikasi untuk membantu organisasi mengembangkan, membeli, dan memelihara 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, sebagaimana diidentifikasi oleh sepuluh ancaman keamanan API teratas OWASP tahun 2019. Tema umum dalam ancaman teratas yang disoroti 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 penegakan kontrol akses.

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

Aplikasi Konsumen harus dianggap tidak tepercaya, atau “publik”, karena Anda tidak mengontrol platform tempat aplikasi berjalan. Anggap bahwa aplikasi publik apa pun 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 rancang pola autentikasi, otorisasi, dan keamanan yang sesuai.
  • Selalu gunakan alur OAuth atau OpenID Connect “klien publik” (sangat disarankan untuk menggunakan PKCE)
  • Pikirkan logika bisnis aplikasi Anda, tentukan spesifikasi OpenAPI Anda terlebih dahulu, dan rancang proxy API Anda untuk memfilter semua data respons dari backend dalam Apigee. Jangan pernah mengandalkan logika kode aplikasi hilir untuk melakukan hal ini.
  • Memfilter semua permintaan data yang berisi PII khusus pengguna agar hanya mengizinkan data dari backend Anda yang dimiliki oleh pengguna yang meminta.

API1:2019 Otorisasi tingkat objek yang 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 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 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

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 meliputi:

Penerapan Kontrol Akses

Setelah validitas token akses diverifikasi, Anda harus menerapkan kebijakan penerapan kontrol akses untuk mengevaluasi setiap permintaan API 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
  • Delegasi: menggunakan panggilan layanan ke solusi pengelolaan akses pihak ketiga

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

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 saat 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 kebijakan service callout, 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 yang rusak

Deskripsi ancaman

Kebijakan autentikasi pengguna yang diterapkan dengan buruk memungkinkan penyerang meniru identitas pengguna yang sah dengan memanfaatkan kelemahan penerapan dalam penerapan 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 serta hindari meneruskan sandi secara langsung dalam permintaan API
  • Selalu validasi tanda tangan kredensial akses, dan pastikan bahwa 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

Dalam paradigma dari luar ke dalam, desain API dibangun 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 penerapan autentikasi yang cukup kuat untuk diekspos ke jaringan publik. Di sinilah Apigee, yang dipadukan dengan solusi pengelolaan akses dan identitas, dapat menawarkan solusi yang efektif untuk melindungi dari ancaman ini.

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

  • Desain keamanan: memanfaatkan sepenuhnya fitur Apigee untuk menerapkan pola autentikasi
  • Tata kelola: memastikan bahwa penggunaan pola autentikasi yang dirancang dengan benar digunakan secara konsisten di semua produk API yang dipublikasikan
  • Keamanan operasional: kemampuan untuk mendeteksi perilaku mencurigakan atau anomali dan upaya untuk menghindari atau melakukan serangan brute force pada proxy API yang diautentikasi

Desain Keamanan

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

RFC OpenID Connect dan OAuth menyediakan sejumlah besar alur otorisasi dan autentikasi yang didelegasikan, serta aktor yang terlibat dalam alur ini. Ini adalah topik yang kompleks, dan tidak mengherankan jika autentikasi yang rusak adalah salah satu ancaman API teratas OWASP. 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 ini.

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 keseluruhan pada proxy API
  • Kebijakan kuota, untuk menetapkan batas frekuensi yang terperinci ke proxy API berdasarkan kuota yang ditentukan oleh kunci aplikasi, developer, atau kuota produk API
  • Kebijakan caching, untuk melakukan caching token akses yang disimpan berdasarkan waktu habis masa berlakunya yang ditentukan, serta kemampuan untuk membatalkan validasi kredensial yang di-cache (misalnya, dalam situasi saat token akses yang valid disusupi)

Tata kelola

Keamanan adalah proses berkelanjutan, bukan project “siap pakai”, dan salah satu penyebab terbesar pelanggaran keamanan adalah kesalahan konfigurasi. Setelah alur autentikasi, pola integrasi identitas, dan kebijakan pengelolaan traffic terkait autentikasi ditentukan, sangat penting untuk menerapkannya dengan benar dan konsisten.

Apigee menyediakan sejumlah fitur dan alat untuk memastikan integritas penerapan dan mencegah error akibat kesalahan konfigurasi.

Role-based Access Control (RBAC)

Baik Anda adalah perusahaan besar atau 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 harus diberi izin yang diperlukan untuk melakukan pekerjaan 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 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 mengurangi kebutuhan Anda untuk mengelola set kedua kredensial administrator 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 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 alur 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 kumpulan kebijakan dan logika bersyarat yang dapat digunakan kembali yang memungkinkan Anda mempertahankan pola komposit.

Keamanan Operasional

Setelah API Anda dalam produksi 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 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, 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 pada masa 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 terus-menerus dari IP yang sama
  • Tingkat error yang tidak biasa
  • Permintaan klien yang mencurigakan
  • Peng-crawl data
  • Serangan brute force autentikasi dan pengumpulan kunci
  • Lonjakan aktivitas
  • Pola geografis

Operasi API Lanjutan

Meskipun Sense dirancang khusus untuk mendeteksi dan merespons ancaman seperti bot, Advanced API Ops mencakup deteksi anomali dan definisi pemberitahuan 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 pikirkan untuk meningkatkan produktivitas dan mengurangi mean time to resolution (MTTR) masalah API Anda.

API Ops tingkat lanjut dibangun berdasarkan mekanisme pemberitahuan Pemantauan API yang ada untuk menambahkan jenis pemberitahuan tingkat lanjut berikut:

  • Peringatan anomali. Edge mendeteksi masalah traffic dan performa, sehingga Anda tidak perlu menentukannya sendiri. Kemudian, Anda dapat memunculkan pemberitahuan untuk anomali ini
  • Peringatan Kedaluwarsa TLS. Menampilkan notifikasi saat masa berlaku sertifikat TLS hampir berakhir

API3:2019 Eksposur data 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 pokok, mereka dapat mengakses data sensitif.

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

Salah satu prinsip desain Apigee lainnya adalah kemampuan penggunaan ulang. Selain masalah keamanan, mengandalkan aplikasi untuk memfilter data yang disediakan oleh API akan menghasilkan persyaratan untuk memindahkan logika pemfilteran tersebut di setiap platform yang Anda kembangkan untuk aplikasi.

Dari perspektif keamanan, ancaman ini muncul akibat mendelegasikan penerapan otorisasi ke aplikasi, sering kali di platform atau OS yang tidak dapat 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
  • Menerapkan penanganan kesalahan untuk mencegah pesan error panjang mengekspos informasi lingkungan yang 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 Anda dari eksposur data yang berlebihan.

Untuk melakukannya, Apigee menggunakan tiga kebijakan utama:

  • Tugaskan Pesan
  • Info kode
  • Penanganan kesalahan

Kebijakan Assign Message

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:

  • Tambahkan 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 Assign Message, 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 penulisan ulang dan penanganan data yang kompleks yang kompleksitasnya melampaui 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 mempermudah Anda menerapkan penanganan kompleks variabel alur, kesalahan, 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 Panggilan Java, dan kebijakan Skrip Python.

Penanganan kesalahan

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

Alur Bersama

Alur bersama dapat digunakan untuk menerapkan standardisasi pesan kesalahan. Misalnya, kebijakan terkonfigurasi yang sama yang mendeteksi kode error HTTP tertentu dari backend dapat digunakan untuk menulis ulang respons error agar menampilkan pesan error umum.

API4:2019 Kurangnya resource & pembatasan kecepatan

Deskripsi ancaman

Jika tidak menerapkan kebijakan pembatasan kecepatan, penyerang dapat membanjiri backend dengan serangan penolakan layanan.

Ancaman ini dapat dengan mudah diatasi dengan menggunakan fitur Apigee berikut:

  • Kebijakan Kuota dan Spike Arrest sebagai kontrol pencegahan untuk membatasi traffic pada permintaan API masuk
  • Apigee Sense untuk mendeteksi dan merespons serangan yang didorong bot secara dinamis
  • Pemantauan dan pemberitahuan API tingkat lanjut sebagai kontrol detektif untuk mendapatkan pemberitahuan tentang serangan DDoS yang sedang berlangsung

Pembatasan kapasitas dengan kebijakan Kuota dan Spike Arrest

Apigee menyediakan dua kebijakan untuk pembatasan kapasitas:

  • Penghentian lonjakan menyediakan kebijakan umum, yang ditentukan di tingkat proxy API, untuk pembatasan kapasitas jumlah keseluruhan permintaan masuk 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, sehingga melindungi dari penurunan performa dan periode nonaktif, 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 yang 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 Pencegahan lonjakan, dan umumnya harus digunakan secara bersamaan dengan kebijakan tersebut.

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 Sistem Otonom tertentu, berdasarkan klien atau lokasi yang menunjukkan perilaku berbahaya atau mencurigakan. Apigee Edge menerapkan tindakan ini ke permintaan sebelum diproses oleh proxy API Anda. Misalnya, rentang IP atau klien tertentu yang menunjukkan perilaku “brute guessor” dapat dideteksi, lalu diblokir atau ditandai.

Deteksi ancaman dengan Pemantauan Operasi API Tingkat Lanjut

Gunakan pemberitahuan traffic untuk memunculkan notifikasi saat traffic untuk lingkungan, proxy, atau wilayah berubah sebesar persentase tertentu selama jangka waktu tertentu. Fitur ini dapat secara dinamis memunculkan pemberitahuan saat traffic menyimpang secara signifikan dari throughput yang diharapkan, seperti yang terjadi selama serangan DDoS. Pemberitahuan ini dapat dengan mudah dikirim ke solusi pencatatan dalam log dan pemantauan pihak ketiga.

API5:2019 Otorisasi tingkat fungsi yang 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 berhak mereka akses. Misalnya, penyerang mungkin dapat mengubah atau menghapus data yang hanya diizinkan 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 mungkin memungkinkan penyerang melihat data pengguna lain hanya dengan mengubah jalur dalam permintaan.

Jenis ancaman ini menyoroti pentingnya 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 bahkan 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 fitur produk dan aplikasi proxy API Apigee.
  • Siapa yang mengakses resource API Anda? Tentukan persona tingkat tinggi dan terapkan hak akses default “hak istimewa terendah” dengan menggunakan beberapa fitur autentikasi dan otorisasi Apigee seperti yang diuraikan dalam API1 dan API2.
  • Bagaimana kebijakan akses Anda diterapkan? Gunakan alur dan kesalahan bersyarat untuk memvalidasi jalur dan kata kerja URL dari semua permintaan API.

Gambar: Diagram ini menunjukkan cara otorisasi tingkat fungsi akan diterapkan di Apigee, menggunakan cakupan yang diberikan 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 gilirannya digunakan oleh developer aplikasi Anda, yang dapat mendaftarkan aplikasi yang menggunakan produk API Anda. Kebijakan akses dapat ditentukan di salah satu tingkat ini.

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” produk API Anda, dengan melihat resource API dari perspektif pelanggan dan developer Anda, lalu menentukan hingga ke tingkat resource jalur dan kata kerja HTTP, jenis permintaan apa saja yang akan diizinkan.

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

Akses tingkat Fungsi Kontrol dengan cakupan OAuth dan klaim JWT

Meskipun pendekatan otorisasi yang dipertimbangkan di atas untuk API1:2019 Otorisasi objek yang rusak menangani kontrol akses terperinci di tingkat objek, sama pentingnya untuk menangani kontrol akses 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 terkandung dalam token akses, baik dengan penggunaan cakupan OAuth atau klaim JWT.

Meminta validasi dengan alur bersyarat

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

  • 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 atau akses yang tidak sah ke resource yang dilindungi. Selain logika bersyarat yang memungkinkan Anda memfilter permintaan berdasarkan token akses atau klaim, Apigee memungkinkan penerapan logika pemfilteran berdasarkan permintaan itu sendiri.

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

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

API6:2019 Penetapan massal

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 atau akses properti yang tidak sah pada objek data yang disimpan di backend.

Ancaman ini terjadi saat data yang tidak difilter (biasanya dalam JSON atau XML) dikirim ke klien, sehingga memungkinkan penyerang menebak detail penerapan 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 memungkinkan kerentanan eksekusi kode jarak jauh.

Biasanya ada dua aspek yang 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. Menerapkan pemfilteran data dan validasi skema untuk mencegah eksposur tidak disengaja data rahasia ke aplikasi klien

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

Kebijakan pemfilteran Spesifikasi OpenAPI

Kebijakan OASValidation (Validasi Spesifikasi OpenAPI) memungkinkan Anda memvalidasi pesan permintaan atau respons masuk 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 caching yang diperlukan untuk mengekspos produk API dari backend Anda dengan aman menggunakan Apigee
  3. Memvalidasi permintaan masuk terhadap skema data yang ditentukan dalam spesifikasi OAS Anda, termasuk basepath, 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 terhadap definisi WSDL. Selain itu, Anda dapat menggunakan kebijakan Validasi Pesan untuk mengonfirmasi bahwa payload pesan JSON atau XML memiliki format yang baik, yang mencakup memverifikasi hal berikut dalam pesan XML atau JSON:

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

API7:2019 Kesalahan konfigurasi keamanan

Deskripsi ancaman

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

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

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

  1. Membangun dan menstandardisasi proses penguatan dan patching
  2. Mengembangkan tata kelola di sekitar ekosistem API
  3. Membatasi akses administratif serta mengaktifkan audit dan pemberitahuan

Alur Bersama dan Hook Alur

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 proxy API individual, atau Anda dapat melakukan langkah lebih lanjut dan menempatkan alur bersama di flow hook untuk menjalankan logika alur bersama secara otomatis bagi setiap proxy API yang di-deploy di lingkungan yang sama dengan alur bersama.

API Monitoring

Apigee menyediakan platform Pemantauan API yang komprehensif. Pemantauan API memungkinkan organisasi mendeteksi masalah performa dan traffic API secara proaktif. Pemantauan API Apigee bekerja bersama 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 menindaklanjuti masalah. Alat ini 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, 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, API dapat dilindungi dari pola permintaan yang mencakup:

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

API8:2019 Injeksi

Deskripsi ancaman

Injeksi data yang tidak tepercaya, seperti SQL, NoSQL, XML Parser, ORM, LDAP, Perintah OS, dan JavaScript, ke dalam permintaan API dapat menyebabkan eksekusi perintah yang tidak diinginkan atau akses data yang tidak sah. Penyerang akan memasukkan data berbahaya ke API melalui vektor injeksi apa pun yang tersedia, seperti input langsung, parameter, layanan terintegrasi, dan sebagainya, dengan harapan data tersebut akan dikirim ke interpreter. Penyerang dapat dengan mudah menemukan kelemahan ini 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 memitigasi kesalahan/serangan injeksi mencakup menentukan data input secara ketat seperti skema, jenis, pola string, melakukan validasi input, pemeriksaan batas, dan menerapkannya saat runtime. Platform Apigee memungkinkan validasi data masuk menggunakan filter untuk hanya mengizinkan nilai yang valid untuk setiap parameter input.

Apigee Edge, yang berperan 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 menghilangkan 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 terhadap ekspresi reguler yang telah ditentukan sebelumnya. Jika ada ekspresi reguler yang ditentukan bernilai benar, pesan akan dianggap sebagai ancaman dan ditolak. Ekspresi reguler, atau regex, adalah sekumpulan 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 strukturnya sudah 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 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:

Memvalidasi Jenis Konten

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

API9:2019 Pengelolaan aset yang tidak tepat

Deskripsi Ancaman

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

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

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

Role Based Access Control: Hanya orang-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.

Hook Alur: Anda dapat menerapkan kebijakan dan pola global yang dapat dikelola sebagai pembatasan istimewa yang tidak dapat diubah oleh developer API.

Organisasi dan Lingkungan

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

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

Lingkungan: API di Apigee dapat dipromosikan melalui beberapa status deployment; setiap status ditautkan ke konteks eksekusi. Konteks lingkungan tidak dibawa selama proses promosi, sehingga tidak 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, Anda harus memiliki definisi yang jelas dan pemisahan tugas antara pemangku kepentingan keamanan dan Developer API. Seperti yang dinyatakan sebelumnya dalam dokumen ini, Apigee memiliki kemampuan Kontrol Akses Berbasis Peran yang fleksibel yang memungkinkan Anda menetapkan izin ke peran kustom. Untuk ancaman khusus ini, peran dapat ditetapkan cakupannya agar memiliki hak istimewa terbatas per organisasi, lingkungan, atau izin konfigurasi yang lebih terperinci. Sebagai praktik yang lebih baik, pertimbangkan untuk membatasi hak istimewa untuk mengubah status deployment API melalui lingkungan dan juga untuk memastikan developer tidak dapat mengakses atau mengubah library keamanan global (Hook Alur). Peran terbatas ini akan mencegah perubahan yang tidak diminta pada kebijakan keamanan global yang memiliki cakupan luas pada endpoint yang dipublikasikan lama dan saat ini.

Dokumentasi Audience Management API

Portal Developer adalah komponen penting untuk keberhasilan Strategi API Anda; dengan portal ini, Anda dapat mempertahankan 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 kumpulan resource dan operasi yang termasuk 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 mencakup proses kepatuhan dan sertifikasi keamanan. Agar efektif, tim API yang menggunakan alat yang sesuai harus dapat membuat pembatas yang menjamin pemisahan tanggung jawab dan sekaligus mempertahankan siklus rilis yang gesit.

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

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

API10:2019 Logging & pemantauan yang tidak memadai

Deskripsi Ancaman

Logging, pemantauan, dan pemberitahuan yang tidak memadai memungkinkan serangan yang sedang berlangsung tidak terdeteksi dan oleh karena itu, 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 menstandardisasi dan mengontrol panjang log, tingkat log, integritas log, repositori terpusat, dan lainnya
  • Kebijakan Pengelolaan Acara: Menjamin bahwa setiap acara 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 dan menanggapi 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-alat ini mencakup:

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

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

Kebijakan Panggilan: Menambahkan dukungan untuk streaming log yang memerlukan endpoint HTTP untuk mengirim peristiwa.

Analytics: Akses dan analisis 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 lebih lanjut dan ditindaklanjuti.