Di artikel sebelumnya, kita sudah berhasil membuat aplikasi di home server bisa diakses dari internet menggunakan Cloudflare Tunnel — tanpa IP public dan tanpa membuka port di router.
Sekarang muncul masalah berikutnya.
Aplikasi kita memang sudah bisa diakses dari mana saja, tapi artinya siapa pun yang mengetahui alamatnya juga bisa mencoba mengaksesnya.
Misalnya kita punya:
https://portainer.domainkamu.com
https://monitor.domainkamu.com
https://dashboard.domainkamu.com
Untuk aplikasi publik tentu tidak masalah.
Tapi bagaimana dengan dashboard internal, monitoring, atau aplikasi pribadi?
Kita bisa menambahkan satu lapisan autentikasi menggunakan Cloudflare Access.
Hasil akhirnya:
Internet
│
▼
Cloudflare
│
▼
Cloudflare Access
│
│ Apakah user diizinkan?
│
├── Tidak → Block
│
└── Ya
│
▼
Cloudflare Tunnel
│
▼
Home Server
│
▼
Application
Request bahkan belum sampai ke home server sebelum lolos dari Cloudflare Access.
Apa Itu Cloudflare Access?
Cloudflare Access adalah bagian dari Cloudflare Zero Trust yang memungkinkan kita menambahkan authentication dan authorization di depan sebuah aplikasi.
Sederhananya, Cloudflare menjadi satpam sebelum request masuk ke aplikasi.
Tanpa Access:
Browser
↓
Cloudflare
↓
Tunnel
↓
Application
Dengan Access:
Browser
↓
Cloudflare
↓
Access Policy
↓
Authentication
↓
Tunnel
↓
Application
User harus memenuhi policy yang kita tentukan sebelum Cloudflare meneruskan request.
Menariknya, aplikasi di belakangnya tidak perlu dimodifikasi.
1. Kapan Cloudflare Access Berguna?
Tidak semua aplikasi perlu dipasang Cloudflare Access.
Untuk aplikasi yang memang ditujukan ke publik seperti:
blog.domainkamu.com
api.domainkamu.com
website.domainkamu.com
Access tentu tidak diperlukan.
Tapi untuk service seperti:
portainer.domainkamu.com
monitor.domainkamu.com
grafana.domainkamu.com
admin.domainkamu.com
Access sangat berguna.
Terutama jika service tersebut hanya digunakan oleh kita sendiri atau beberapa orang tertentu.
2. Sebelum Memulai
Pastikan kita sudah mempunyai:
- domain yang menggunakan Cloudflare
- Cloudflare Tunnel yang aktif
- aplikasi yang sudah bisa diakses melalui domain
- akun Cloudflare Zero Trust
Contohnya, kita sudah memiliki:
https://monitor.domainkamu.com
yang diarahkan melalui Cloudflare Tunnel ke:
http://192.168.1.10:3001
Sebelum memasang Access, pastikan URL tersebut memang sudah bisa dibuka.
Dengan begitu kalau nanti terjadi masalah, kita tahu masalahnya berada di konfigurasi Access, bukan Tunnel.
3. Buka Cloudflare Zero Trust
Masuk ke dashboard Cloudflare kemudian buka:
Zero Trust
→ Access
→ Applications
Pilih:
Add an application
Untuk aplikasi web yang berada di home server, pilih:
Self-hosted
Self-hosted di sini bukan berarti Cloudflare menjalankan aplikasinya.
Aplikasinya tetap berjalan di server kita.
Cloudflare hanya melindungi akses menuju aplikasi tersebut.
4. Tambahkan Domain Aplikasi
Misalnya kita ingin melindungi:
monitor.domainkamu.com
Masukkan hostname tersebut sebagai domain aplikasi:
Application name:
Home Server Monitor
Domain:
monitor.domainkamu.com
Cloudflare sekarang mengetahui bahwa request menuju domain tersebut harus melewati Access terlebih dahulu.
5. Membuat Access Policy
Ini bagian terpenting.
Kita perlu menentukan:
Siapa yang boleh masuk?
Buat policy baru, misalnya:
Policy name:
Allow My Email
Action:
Allow
Kemudian pada bagian Include pilih:
Emails
Masukkan email kita:
Artinya hanya akun dengan email tersebut yang boleh melewati Cloudflare Access.
Request dari user lain akan ditolak sebelum mencapai home server.
6. Login Menggunakan Email OTP
Untuk setup pribadi, kita tidak harus langsung menghubungkan Google, GitHub, Microsoft, atau identity provider lainnya.
Cloudflare menyediakan metode:
One-time PIN
Flow-nya sederhana.
Ketika membuka:
https://monitor.domainkamu.com
Cloudflare menampilkan halaman login.
Kita memasukkan email.
Cloudflare kemudian mengirim kode verifikasi ke email tersebut.
Email
↓
One-time PIN
↓
Cloudflare Access
↓
Application
Masukkan kode tersebut dan jika email memenuhi Access Policy, kita bisa masuk ke aplikasi.
Untuk home server pribadi, metode ini sudah cukup nyaman.
7. Kenapa Email Policy Penting?
Jangan hanya mengaktifkan login tanpa membatasi siapa yang boleh masuk.
Misalnya policy kita terlalu luas:
Include:
Everyone
Artinya siapa pun yang berhasil melakukan authentication bisa masuk.
Untuk service pribadi lebih aman menggunakan:
Emails:
[email protected]
atau jika digunakan oleh beberapa orang:
Cloudflare Access kemudian berfungsi sebagai authorization layer, bukan sekadar halaman login.
8. Test Cloudflare Access
Setelah policy disimpan, buka aplikasi menggunakan Incognito atau Private Window:
https://monitor.domainkamu.com
Seharusnya kita tidak langsung melihat aplikasi.
Cloudflare akan menampilkan halaman authentication terlebih dahulu.
Flow lengkapnya sekarang:
monitor.domainkamu.com
↓
Cloudflare Edge
↓
Cloudflare Access
↓
Authentication
↓
Access Policy
↓
Cloudflare Tunnel
↓
Home Server
↓
Monitoring App
Kalau menggunakan email yang tidak ada di policy, request akan ditolak.
Kalau menggunakan email yang diizinkan, request diteruskan ke aplikasi.
9. Apakah Login Aplikasi Masih Diperlukan?
Misalnya Portainer sudah mempunyai login sendiri.
Kemudian kita memasang Cloudflare Access di depannya.
Sekarang user harus melewati:
Cloudflare Access Login
↓
Portainer Login
Apakah redundant?
Sedikit.
Tapi justru ini bisa menjadi defense in depth.
Login aplikasi tetap menjadi authentication utama aplikasi.
Cloudflare Access menjadi lapisan tambahan sebelum aplikasi tersebut bahkan dapat dijangkau.
Jadi attacker dari internet tidak langsung berhadapan dengan halaman login Portainer.
Mereka harus melewati Cloudflare Access terlebih dahulu.
10. Lindungi Dashboard Internal
Sekarang kita bisa melakukan hal yang sama untuk service lain.
Misalnya:
portainer.domainkamu.com
grafana.domainkamu.com
monitor.domainkamu.com
npm.domainkamu.com
Daripada semuanya langsung tersedia dari internet:
Internet
↓
Application Login
kita tempatkan Access di depannya:
Internet
↓
Cloudflare Access
↓
Application Login
Ini sangat cocok untuk dashboard administratif.
11. Satu Policy untuk Banyak Aplikasi
Kalau mempunyai banyak aplikasi internal, kita tidak harus membuat aturan email yang berbeda-beda.
Kita bisa membuat pola policy yang konsisten:
Home Server Admin
Allow:
[email protected]
Kemudian gunakan policy yang sama untuk beberapa aplikasi internal.
┌── Portainer
│
Cloudflare Access ──┼── Grafana
│
├── Monitoring
│
└── Admin Dashboard
Satu identitas bisa digunakan untuk mengakses beberapa service.
12. Bagaimana dengan Wildcard?
Misalnya sebelumnya kita menggunakan hostname:
*.home.domainkamu.com
untuk berbagai aplikasi home server.
Kita mungkin tergoda membuat satu policy wildcard dan menganggap semuanya selesai.
Secara teknis bisa berguna, tetapi tetap harus memikirkan klasifikasi aplikasinya.
Karena tidak semua service mempunyai tingkat akses yang sama.
Contohnya:
photos.home.domainkamu.com
mungkin digunakan keluarga.
Sedangkan:
portainer.home.domainkamu.com
hanya boleh digunakan administrator.
Lebih baik pisahkan policy berdasarkan kebutuhan daripada membuat satu policy super luas hanya karena lebih praktis.
13. Cloudflare Access Bukan Pengganti Firewall
Cloudflare Access melindungi jalur:
Internet
→ Cloudflare
→ Tunnel
→ Application
Tapi kita tetap harus memastikan aplikasi tidak mempunyai jalur publik lain yang bisa melewati Cloudflare.
Misalnya jangan sampai:
Internet
→ Public IP
→ Port Forwarding
→ Application
masih tersedia.
Kalau attacker bisa mengakses aplikasi langsung melalui IP public, Cloudflare Access bisa dilewati sepenuhnya.
Karena itu salah satu keuntungan kombinasi Cloudflare Tunnel + Access adalah kita tidak perlu membuka port aplikasi ke internet.
14. Cloudflare Access vs Tailscale
Kalau mengikuti setup home server cukup lama, mungkin muncul pertanyaan:
Kalau sudah ada Cloudflare Access, masih perlu Tailscale?
Menurut saya keduanya mempunyai fungsi yang sedikit berbeda.
Cloudflare Access cocok ketika kita ingin mengakses aplikasi melalui browser tanpa harus terhubung ke VPN terlebih dahulu:
https://monitor.domainkamu.com
Sedangkan Tailscale lebih cocok untuk akses private seperti:
SSH
Database
Samba
Internal API
Server management
Saya biasanya membaginya seperti ini:
WEB APPLICATION
↓
Cloudflare Tunnel + Access
sedangkan:
PRIVATE NETWORK
↓
Tailscale
Dengan pembagian tersebut, kita tidak perlu memaksakan satu teknologi untuk semua kebutuhan.
15. Arsitektur Akhir Home Server
Setelah tiga bagian seri ini, arsitektur home server kita mulai terlihat seperti ini:
Internet
│
▼
Cloudflare
│
┌─────────┴─────────┐
│ │
▼ ▼
Public App Private Web App
│ │
│ Cloudflare Access
│ │
└─────────┬─────────┘
│
▼
Cloudflare Tunnel
│
▼
Home Server
Untuk akses administratif jaringan:
Laptop
│
▼
Tailscale
│
▼
Home Server
│
├── SSH
├── Database
└── Internal Services
Dengan setup seperti ini kita tidak sekadar membuat home server bisa diakses dari internet.
Kita mulai menentukan siapa yang boleh mengakses apa.
Penutup
Cloudflare Tunnel menyelesaikan masalah:
Bagaimana aplikasi di home server bisa diakses dari internet tanpa IP public dan port forwarding?
Cloudflare Access menjawab pertanyaan berikutnya:
Setelah bisa diakses dari internet, bagaimana kita membatasi siapa yang boleh masuk?
Kombinasi keduanya membuat service internal tetap nyaman diakses tanpa harus mengekspos server secara langsung.
Untuk aplikasi publik, cukup gunakan Cloudflare Tunnel.
Untuk dashboard dan aplikasi pribadi, tambahkan Cloudflare Access.
Sedangkan untuk SSH, database, dan akses jaringan internal lainnya, kita bisa menggunakan private network seperti Tailscale.
Dengan begitu home server kita bukan hanya accessible from anywhere, tetapi aksesnya juga jauh lebih terkontrol.
Seri ini terdiri dari:
- Home Server Bisa Diakses dari Mana Saja — kenapa Cloudflare Tunnel menarik
- Setup Cloudflare Tunnel dari Nol — step by step installasi
- Amankan Home Server dengan Cloudflare Access — artikel ini
THREADS ↗
COMMENTS & DISCUSSION