Tutorial Mengamankan Aplikasi Internal dengan Cloudflare Access pada Workers

Cloudflare meluncurkan fitur baru yang memungkinkan developer mengamankan aplikasi Workers secara bawaan menggunakan Cloudflare Access. Fitur ini menjawab kekhawatiran banyak organisasi di mana karyawan dapat dengan cepat membuat dan men-deploy aplikasi ke internet tanpa otentikasi yang memadai. Artikel ini menjelaskan cara mengkonfigurasi Cloudflare Access pada Workers langkah demi langkah.

Menurut Cloudflare Blog, sekarang kamu dapat menerapkan kebijakan Access langsung ke satu Worker atau ke seluruh Worker di akun. Setiap deployment, baik production maupun preview, akan otomatis berada di balik login perusahaan tanpa bergantung pada konfigurasi manual oleh masing-masing developer.

Mengapa Access pada Workers Penting

Sebelum fitur ini hadir, konfigurasi Access harus dilakukan per hostname. Jika developer menambahkan custom domain baru ke Worker, mereka harus mengupdate kebijakan Access terlebih dahulu atau domain tersebut akan dapat diakses tanpa otentikasi. Dengan Access yang ditempelkan pada Worker itu sendiri, setiap domain atau URL yang terasosiasi dengan Worker tersebut secara otomatis terlindungi.

Fitur ini juga memberikan identitas pengguna yang terotentikasi langsung di dalam kode Worker melalui ctx.access.getIdentity(). Sebelumnya, developer harus melakukan validasi JWT secara manual yang rumit dan rawan kesalahan.

Langkah 1: Mengaktifkan Access di Level Akun

Masuk ke dashboard Cloudflare dan navigasi ke bagian Workers & Pages. Di sana kamu akan menemukan opsi untuk mengatur kebijakan Access di level akun. Aktifkan kebijakan ini agar setiap Worker yang ada dan yang akan datang secara default bersifat privat.

Pilih cakupan kebijakan yang sesuai kebutuhan organisasimu:

• Preview only: Hanya URL preview yang memerlukan otentikasi. Berguna jika production Worker memang sengaja publik.

• All hostnames: Semua domain, custom domain, workers.dev subdomain, dan preview URL dilindungi.

Jika ada Worker tertentu yang memang harus publik, kamu dapat membuat pengecualian (bypass) pada Worker tersebut tanpa mempengaruhi kebijakan akun secara keseluruhan.

Langkah 2: Mengkonfigurasi Access pada Worker Spesifik

Jika kebijakan di level akun terlalu luas, kamu dapat menerapkan Access pada Worker individual. Buka halaman detail Worker yang ingin dilindungi, lalu pilih tab Access yang baru. Di tab ini, kamu dapat melihat kebijakan apa saja yang berlaku untuk aplikasi tersebut.

Prioritas kebijakan mengikuti urutan berikut: kebijakan hostname paling spesifik, kemudian kebijakan Worker, dan terakhir kebijakan akun. Ini memungkinkan konfigurasi yang fleksibel sesuai kompleksitas organisasimu.

Hubungkan identity provider yang sudah kamu gunakan, seperti Google Workspace, Azure AD, atau Okta. Karyawan akan login dengan kredensial yang mereka gunakan sehari-hari. Kamu juga dapat membatasi akses berdasarkan domain email, alamat email spesifik, atau grup tertentu.

Langkah 3: Mengakses Identitas Pengguna di Kode Worker

Setelah Access aktif, setiap request yang masuk ke Worker akan membawa objek context dengan metadata otentikasi. Gunakan ctx.access.getIdentity() untuk mendapatkan email, nama, dan grup pengguna tanpa perlu memvalidasi JWT sendiri.

export default {
  async fetch(request, env, ctx) {
    if (!ctx.access) {
      return new Response("Access required", { status: 403 });
    }

    const identity = await ctx.access.getIdentity();
    const email = identity?.email ?? "unknown";

    return new Response("Hello, " + email);
  }
};

Kode di atas memeriksa apakah Access aktif pada Worker. Jika tidak, request ditolak dengan status 403. Jika aktif, email pengguna diekstrak dan digunakan untuk personalisasi respons. Informasi grup juga tersedia untuk enforcement permission yang lebih granular.

Langkah 4: Menguji Lokal dengan wrangler dev

Cloudflare menyediakan cara untuk mensimulasikan otentikasi saat development lokal. Tambahkan blok access di file wrangler.jsonc untuk mensimulasikan pengguna yang sudah login:

{
  "access": {
    "dev": {
      "aud": "my-app",
      "identity": { "email": "admin@company.com" }
    }
  }
}

Dengan konfigurasi ini, ctx.access.getIdentity() akan mengembalikan objek identitas yang sama bentuknya dengan production. Kamu dapat mengganti email untuk menguji sebagai pengguna berbeda tanpa harus deploy dan login melalui Access setiap kali.

Pendekatan ini sangat menghemat waktu development karena kamu dapat memverifikasi bahwa konten yang tepat muncul untuk pengguna yang tepat secara lokal.

Langkah 5: Membangun Internal Platform dengan Workers for Platforms

Jika organisasimu mengelola platform internal di mana karyawan dapat membuat prototype dan deploy aplikasi, Workers for Platforms adalah solusi yang tepat. Setiap Worker berada di dalam namespace, dan semua traffic ke namespace tersebut melewati satu entry point: dispatch Worker.

Tetapkan kebijakan Access pada dispatch Worker, maka setiap Worker yang di-deploy melalui platform tersebut secara otomatis privat. Cloudflare telah menyediakan template open source untuk internal static site platform yang dapat di-deploy langsung.

Template ini mencakup drag-and-drop deployment interface di mana setiap situs yang di-deploy melalui platform otomatis dilindungi oleh kebijakan Access yang sama. Ini sangat cocok untuk tim yang ingin mendorong inovasi tanpa mengorbankan keamanan.

Keuntungan dan Praktik Terbaik

Menerapkan Access pada Workers secara default mengurangi risiko data exposure akibat human error. Developer tidak perlu lagi mengingat untuk mengaktifkan otentikasi setiap kali membuat Worker baru. Service token juga tersedia untuk memberikan akses kepada AI agent atau microservice yang memerlukan komunikasi antar layanan internal.

Gunakan audit log yang tersedia di dashboard Cloudflare One untuk melacak siapa saja yang mengakses aplikasi internalmu. Kombinasikan dengan kebijakan Zero Trust untuk memastikan bahwa akses tidak hanya bergantung pada lokasi jaringan, melainkan pada identitas dan konteks setiap request.

Kesimpulan

Cloudflare Access pada Workers mengubah cara organisasi mengamankan aplikasi internal. Dengan kebijakan yang dapat diterapkan di level akun, Worker individual, atau dispatch Worker, setiap deployment secara default terlindungi di balik login perusahaan. Fitur ctx.access.getIdentity() menghilangkan kompleksitas validasi JWT manual dan memungkinkan personalisasi berbasis identitas dengan mudah.

Dokumentasi lengkap tersedia di Cloudflare Access for Workers documentation.