คู่มือ DigitalOcean Cloud Firewall 2026 — ตั้งค่าความปลอดภัย

A hands-on guide to configuring DigitalOcean Cloud Firewall rules, tags, and troubleshooting for developers.

Cloud Firewall คืออะไร ต่างจาก ufw/iptables ยังไง

DigitalOcean Cloud Firewall คือไฟร์วอลล์ระดับเครือข่ายที่ทำงานอยู่นอกตัว Droplet ผู้ดูแลระบบตั้งกฎผ่าน Control Panel, doctl หรือ API แล้วระบบจะบังคับใช้กฎนั้นที่ระดับ hypervisor ก่อนที่ทราฟฟิกจะไปถึงเครื่องจริง บทความนี้เจาะลึกเฉพาะการตั้งค่า Cloud Firewall แบบใช้งานจริง ตั้งแต่กฎ Inbound/Outbound การใช้ Tags จัดกลุ่ม Droplet จำนวนมาก ไปจนถึงการแก้ปัญหาเมื่อกฎบล็อกผิดที่ ไม่ใช่ภาพรวมความปลอดภัยทั่วไปที่เคยเขียนไว้ในบทความอื่น ความต่างหลักจาก ufw หรือ iptables คือตำแหน่งที่ทำงาน ufw และ iptables เป็นซอฟต์แวร์ที่รันอยู่ภายในระบบปฏิบัติการของ Droplet เอง กฎทั้งหมดถูกเก็บและประมวลผลโดย kernel ของเครื่องนั้น ถ้า Droplet โดนโจมตีจนมีสิทธิ์ root หรือ service ที่รันอยู่มีช่องโหว่ ผู้โจมตีที่เข้าถึงเครื่องได้ในระดับสูงพอสามารถแก้ไขหรือปิดกฎ ufw ได้ ขณะที่ Cloud Firewall ถูกบังคับใช้จากภายนอกเครื่องทั้งหมด การเข้าถึงเครื่องผ่าน SSH หรือช่องโหว่ใน service ไม่สามารถแก้กฎ Cloud Firewall ได้เลย ต้องเข้าไปแก้ผ่านบัญชี DigitalOcean เท่านั้น ทำให้เป็นชั้นป้องกันที่แยกอิสระจากตัว Droplet จริง ๆ อีกจุดต่างคือการจัดการหลายเครื่องพร้อมกัน ufw ต้อง SSH เข้าไปแก้กฎทีละเครื่อง ถ้ามี Droplet 20 ตัวที่ต้องเปิดพอร์ตเดียวกันหมด ต้องรันคำสั่งซ้ำ 20 รอบหรือเขียนสคริปต์ automation เอง ส่วน Cloud Firewall ใช้ระบบ Tags ผูกกฎเดียวเข้ากับ Droplet ได้ทั้งกลุ่มพร้อมกัน แก้กฎครั้งเดียวมีผลกับทุกเครื่องที่มี Tag ตรงกันทันที โดยไม่ต้องแตะ Droplet ทีละตัว ในแง่ประสิทธิภาพ Cloud Firewall ไม่กิน CPU หรือ RAM ของ Droplet เลยเพราะประมวลผลอยู่นอกเครื่อง ต่างจาก iptables ที่แม้จะเบา แต่ก็ยังใช้ทรัพยากรของ Droplet ในการตรวจแพ็กเก็ตทุกตัว สำหรับ Droplet ขนาดเล็กอย่างแผน 512 MiB RAM ราคา $4 ต่อเดือน ความต่างนี้มีนัยสำคัญกว่าที่คิด อย่างไรก็ตาม แนวทางที่แนะนำคือใช้ทั้งสองชั้นร่วมกันแบบ defense-in-depth ไม่ใช่เลือกอย่างใดอย่างหนึ่ง Cloud Firewall ทำหน้าที่เป็นด่านแรกกรองทราฟฟิกจากอินเทอร์เน็ต ส่วน ufw ภายในเครื่องทำหน้าที่เป็นด่านสำรองกรณีมีการเชื่อมต่อภายในที่ Cloud Firewall อาจไม่ได้ครอบคลุมทุกกรณี

DigitalOcean Cloud Firewall is a network-level firewall operating outside Droplets. Administrators set rules via Control Panel, doctl, or API, and the system enforces them at the hypervisor level before traffic reaches the actual machine. This article focuses on practical Cloud Firewall setup—inbound/outbound rules, using Tags to group multiple Droplets, and troubleshooting when rules incorrectly block traffic. It is not a general security overview. The primary difference from ufw or iptables is the location of enforcement. ufw and iptables are software running inside the Droplet's OS. All rules are stored and processed by the machine's kernel. If a Droplet is compromised with root access or a running service has a vulnerability, an attacker with sufficient privileges can modify or disable ufw rules. Cloud Firewall, on the other hand, is enforced entirely from outside the machine. Gaining SSH access or exploiting a service vulnerability cannot change Cloud Firewall rules—only the DigitalOcean account can modify them. This makes it an independent protective layer separate from the actual Droplet itself. Another difference is managing multiple machines. ufw requires SSH access to configure each Droplet individually. With 20 Droplets needing the same open port, you either repeat the command 20 times or write your own automation script. Cloud Firewall uses Tags to bind a single rule to an entire group of Droplets simultaneously. Edit the rule once, and it takes effect on all Droplets with the matching Tag instantly—no need to touch each machine individually. From a performance angle, Cloud Firewall consumes no CPU or RAM from the Droplet because it processes traffic outside the machine. Unlike iptables, which inspects every packet but still uses the Droplet's resources, on a small Droplet like the $4/month 512 MiB RAM plan, this difference is significant. The recommended approach, however, is to use both layers together in a defense-in-depth model, not one instead of the other. Cloud Firewall serves as the first checkpoint filtering internet traffic, while ufw inside the machine acts as a secondary layer against internal connections that Cloud Firewall might not fully cover.

1. Cloud Firewall ทำงานที่ระดับเครือข่าย (network edge) ก่อนทราฟฟิกถึง Droplet ต่างจาก ufw/iptables ที่รันเป็นซอฟต์แวร์ในตัว OS
2. ไม่กิน CPU/RAM ของ Droplet เพราะประมวลผลนอกเครื่อง
3. จัดการกฎเดียวแล้ว sync กับหลาย Droplet พร้อมกันผ่าน Tags

สร้าง Firewall กฎ Inbound/Outbound

การสร้าง Cloud Firewall เริ่มจากตัดสินใจว่ากลุ่ม Droplet ไหนต้องการกฎแบบไหน จากนั้นตั้งค่าผ่าน Control Panel ที่เมนู Networking > Firewalls > Create Firewall หรือใช้ doctl สำหรับ automation กฎ Inbound กำหนดว่าใครเชื่อมต่อเข้ามาที่ Droplet ได้บ้าง ประกอบด้วยสามส่วนหลักคือ protocol (TCP/UDP/ICMP), port หรือช่วง port, และ source ที่อนุญาต ซึ่ง source เลือกได้ทั้งเป็น IP/CIDR เฉพาะ, Tag ของ Droplet อื่น, Load Balancer, หรือเปิดกว้างด้วย 0.0.0.0/0 และ ::/0 สำหรับทุกคนบนอินเทอร์เน็ต ตัวอย่างการสร้าง Firewall สำหรับเว็บเซิร์ฟเวอร์ผ่าน doctl: doctl compute firewall create --name web-firewall --inbound-rules "protocol:tcp,ports:22,address:203.0.113.10/32 protocol:tcp,ports:80,address:0.0.0.0/0,address:::0/0 protocol:tcp,ports:443,address:0.0.0.0/0,address:::0/0" --outbound-rules "protocol:tcp,ports:all,address:0.0.0.0/0,address:::0/0 protocol:udp,ports:all,address:0.0.0.0/0,address:::0/0 protocol:icmp,address:0.0.0.0/0,address:::0/0" --tag-names web จุดที่มือใหม่พลาดบ่อยคือกฎ Outbound เมื่อไม่ได้แตะ Firewall เลย DigitalOcean จะอนุญาต outbound ทุกทิศทางเป็นค่าเริ่มต้น แต่ทันทีที่เริ่มระบุกฎ Outbound เอง ระบบจะเปลี่ยนไปใช้หลัก default-deny กับ outbound ด้วยเช่นกัน หมายความว่าต้องเปิดพอร์ตที่ Droplet ต้องใช้เชื่อมต่อออกไปเองทั้งหมด ที่สำคัญที่สุดคือ DNS (UDP/TCP port 53), NTP (UDP port 123) สำหรับซิงก์เวลา, และ HTTP/HTTPS (80/443) สำหรับ apt update หรือ package manager อื่น ๆ ถ้าลืมเปิดพอร์ตเหล่านี้ Droplet จะยังทำงานได้แต่ apt update จะค้างหรือ fail และ resolve โดเมนไม่ได้ หลักการสำคัญอีกข้อคือ default-deny ของ inbound พอร์ตใดที่ไม่ได้ระบุไว้ในกฎจะถูกบล็อกทั้งหมดโดยอัตโนมัติ ไม่ต้องเขียนกฎ deny เองเหมือน iptables ซึ่งทำให้ตั้งค่าเข้าใจง่ายกว่า แต่ก็ต้องระวังไม่ให้ลืมเปิดพอร์ตที่แอปพลิเคชันต้องใช้จริง เช่นถ้ารันเว็บบน port 8080 แล้วลืมเปิด ผู้ใช้จะเชื่อมต่อไม่ได้ทั้งที่ nginx รันปกติ หลังสร้าง Firewall แล้วสามารถเพิ่มกฎภายหลังได้โดยไม่ต้องลบสร้างใหม่ ด้วยคำสั่ง doctl compute firewall add-rules FIREWALL_ID --inbound-rules "protocol:tcp,ports:8080,address:0.0.0.0/0" หรือลบกฎด้วย remove-rules ในรูปแบบเดียวกัน ทำให้ปรับแก้กฎแบบ incremental ได้สะดวกโดยไม่กระทบ Droplet ที่กำลังใช้งานอยู่

• กฎ Inbound กำหนด protocol + port + source ที่อนุญาตให้เข้า พอร์ตอื่นที่ไม่ระบุถูกบล็อกทั้งหมดโดย default
• กฎ Outbound กำหนดปลายทางที่ Droplet เชื่อมต่อออกได้ ถ้าตั้งเองต้องเปิด DNS(53)/NTP(123)/HTTP(80)/HTTPS(443) ไม่งั้น apt update ล้มเหลว
• สร้างผ่าน Control Panel, doctl หรือ API v2 ได้เหมือนกัน

ใช้ Tags จัดกลุ่ม Droplet หลายตัว

Tags เป็นกลไกสำคัญที่ทำให้ Cloud Firewall จัดการ Droplet จำนวนมากได้โดยไม่ต้องผูกทีละเครื่อง หลักการคือสร้าง Tag ขึ้นมาก่อน แปะ Tag นั้นเข้ากับ Droplet ที่ต้องการ แล้วผูก Firewall เข้ากับ Tag แทนที่จะผูกกับ Droplet ตรง ๆ ผลคือ Droplet ใหม่ที่สร้างขึ้นในอนาคตพร้อม Tag เดียวกันจะได้รับกฎ Firewall ทันทีโดยอัตโนมัติ ไม่ต้องกลับมาผูกมือเพิ่ม ขั้นตอนเริ่มจากสร้าง Tag ด้วย doctl compute tag create app-prod จากนั้นตอนสร้าง Droplet ใหม่ให้ระบุ Tag ไปพร้อมกัน เช่น doctl compute droplet create web-01 --image ubuntu-24-04-x64 --size s-1vcpu-1gb --region sgp1 --tag-names app-prod สำหรับ Droplet ที่มีอยู่แล้วสามารถแปะ Tag เพิ่มทีหลังผ่าน Control Panel ในหน้า Droplet ได้เช่นกัน เมื่อ Tag พร้อมแล้วให้ผูกเข้ากับ Firewall ด้วย doctl compute firewall add-tags FIREWALL_ID --tag-names app-prod และถอดออกด้วย remove-tags ในรูปแบบเดียวกัน รูปแบบการใช้งานที่พบบ่อยที่สุดคือระบบที่มีการ scale บ่อย เช่นกลุ่ม web server หลัง Load Balancer ที่เพิ่ม-ลดจำนวน Droplet ตามโหลด หรือ worker node ที่สร้างใหม่อัตโนมัติ การผูกกฎกับ Tag แทนที่จะผูกกับ Droplet ID ทำให้ไม่ต้องเขียนสคริปต์เพิ่มเติมเพื่อจัดการ Firewall ทุกครั้งที่มีเครื่องใหม่เกิดขึ้น ลดความเสี่ยงที่จะมี Droplet หลุดจากการป้องกันเพราะลืมผูก Firewall ให้ ข้อควรรู้คือ Droplet หนึ่งตัวสามารถอยู่ภายใต้ Firewall ได้มากกว่าหนึ่งตัวพร้อมกัน เช่นมี Firewall "base-security" ที่ทุก Droplet ต้องมี และ Firewall เฉพาะทางอย่าง "database-only" ผูกเพิ่มเฉพาะเครื่อง DB เมื่อมีหลาย Firewall ซ้อนกัน กฎทั้งหมดจะรวมกันแบบ union คือถ้ากฎใดกฎหนึ่งอนุญาตก็ถือว่าอนุญาต ไม่ใช่ต้องผ่านทุกกฎ ดังนั้นต้องออกแบบ Tag และ Firewall ให้ชัดเจนไม่ให้เกิดกฎที่เปิดกว้างเกินจำเป็นโดยไม่ตั้งใจ นอกจากนี้ Tag ยังใช้ข้ามได้ทุก region ในบัญชีเดียวกัน ทำให้จัดกลุ่ม Droplet ที่กระจายอยู่หลาย datacenter เช่น sgp1 และ blr1 ให้อยู่ภายใต้นโยบาย Firewall เดียวกันได้ง่าย

• สร้าง Tag ด้วย doctl compute tag create แล้วผูกกับ Firewall ด้วย doctl compute firewall add-tags
• Droplet ใหม่ที่สร้างพร้อม --tag-names จะได้กฎ Firewall ทันทีโดยไม่ต้องผูกมือ
• เหมาะกับกลุ่ม Droplet ที่ scale บ่อย เช่น web server หลัง Load Balancer
• Droplet หนึ่งตัวผูกได้หลาย Firewall พร้อมกัน กฎจะรวมกันแบบ union
• Tag ใช้ข้าม region ได้ในบัญชีเดียวกัน จัดกลุ่ม Droplet ต่าง datacenter ได้

ตัวอย่างกฎมาตรฐาน: เว็บเซิร์ฟเวอร์/SSH/Database

เมื่อเข้าใจกลไก Inbound/Outbound และ Tags แล้ว ขั้นตอนต่อไปคือออกแบบกฎจริงสำหรับสถาปัตยกรรมทั่วไปที่แยกเป็นสามชั้น คือ web server, application server และ database ซึ่งแต่ละชั้นควรมี Firewall หรือ Tag ของตัวเองแยกกัน ไม่รวมกฎทั้งหมดไว้ที่เดียว สำหรับ web server ที่รับทราฟฟิกจากผู้ใช้ทั่วไป เปิด port 80 และ 443 จากทุกที่ (0.0.0.0/0 และ ::/0) เพราะไม่รู้ล่วงหน้าว่าผู้เยี่ยมชมจะมาจาก IP ไหน ส่วน port 22 สำหรับ SSH ไม่ควรเปิดกว้างแบบเดียวกัน ควรจำกัดเฉพาะ IP ของออฟฟิศ, VPN, หรือ bastion host เท่านั้น เช่น protocol:tcp,ports:22,address:203.0.113.10/32 การเปิด SSH ให้ทุกคนบนโลกเป็นสาเหตุอันดับต้น ๆ ของการโดนสแกนและโจมตี brute-force สำหรับ application server ที่อยู่ชั้นกลาง มักไม่จำเป็นต้องเปิดสู่อินเทอร์เน็ตโดยตรงเลยถ้าอยู่หลัง Load Balancer แล้ว ให้เปิดเฉพาะ port ที่ Load Balancer หรือ web server ชั้นหน้าเรียกเข้ามา เช่น port 3000 หรือ 8080 โดยจำกัด source เป็น Tag ของ web server เท่านั้น ไม่ใช่เปิดกว้าง สำหรับฐานข้อมูลคือจุดที่ต้องระวังที่สุด ห้ามเปิด port ฐานข้อมูลอย่าง 5432 (PostgreSQL) หรือ 3306 (MySQL) ออกสู่อินเทอร์เน็ตเด็ดขาด ควรเปิดเฉพาะจาก Tag ของ application server เท่านั้น ตัวอย่างคำสั่ง: doctl compute firewall create --name db-firewall --inbound-rules "protocol:tcp,ports:5432,tag:app-prod" --outbound-rules "protocol:tcp,ports:all,address:0.0.0.0/0,address:::0/0" --tag-names database สังเกตว่า source ของกฎนี้ใช้ tag:app-prod แทนที่จะเป็น IP ทำให้แม้ application server จะถูกสร้างใหม่หรือมี IP เปลี่ยน กฎยังใช้งานได้โดยไม่ต้องแก้ไข ถ้าใช้ Managed Database ของ DigitalOcean แทนการ self-host บน Droplet เอง การจำกัด source ทำผ่านหน้า Trusted Sources ของ Managed Database โดยตรงซึ่งทำงานคล้ายหลักการเดียวกัน ก่อน apply กฎจริงควรตรวจสอบด้วย doctl compute firewall get FIREWALL_ID เพื่อดูว่ากฎที่บันทึกตรงกับที่ตั้งใจหรือไม่ ก่อนที่จะเชื่อมกับระบบ production จริง

• เว็บเซิร์ฟเวอร์: เปิด 80/443 จากทุกที่ เปิด 22 เฉพาะ IP ออฟฟิศหรือ VPN เท่านั้น
• ฐานข้อมูล: เปิดพอร์ต DB เช่น 5432 หรือ 3306 เฉพาะจาก Tag ของ application server ห้ามเปิดสู่อินเทอร์เน็ต
• application server ชั้นกลางไม่ต้องเปิดสู่อินเทอร์เน็ตตรงถ้าอยู่หลัง Load Balancer แล้ว

ราคาฟรี ไม่มีค่าใช้จ่ายเพิ่ม

ในประสบการณ์ของเรา หนึ่งในจุดแข็งที่ทำให้ DigitalOcean Cloud Firewall คุ้มค่าใช้งานคือไม่มีค่าใช้จ่ายเพิ่มใด ๆ ทั้งสิ้น ไม่ว่าจะสร้าง Firewall กี่ตัว มีกฎ Inbound/Outbound กี่ข้อ หรือผูกกับ Droplet กี่เครื่องก็ตาม ฟีเจอร์นี้รวมอยู่ในทุกบัญชีตั้งแต่แผน Droplet เล็กที่สุดคือ 512 MiB RAM ราคา $4 ต่อเดือน ไปจนถึงระดับองค์กรที่มี Droplet หลักร้อยหลักพันเครื่อง โดยไม่ต้องอัพเกรดแผนหรือซื้อ add-on ใด ๆ เพื่อปลดล็อกฟีเจอร์นี้ ต่างจากผู้ให้บริการ cloud บางเจ้าที่แยกราคา security group หรือ managed firewall ขั้นสูงออกจากแผนพื้นฐาน เพราะ Cloud Firewall ทำงานที่ระดับ network edge ไม่ใช่การรัน proxy หรือ gateway แยกต่างหาก การใช้งานจึงไม่นับรวมหรือหักออกจากโควตา Transfer (bandwidth) ที่มากับ Droplet แต่ละแผน ทราฟฟิกที่ถูกบล็อกจะไม่ถึงเครื่องเลยด้วยซ้ำ จึงไม่มีผลต่อค่า bandwidth หรือ performance ของ Droplet ไม่ว่าจะตั้งกฎซับซ้อนแค่ไหน ในแง่การวางแผนงบประมาณ นี่หมายความว่าทีมพัฒนาสามารถออกแบบ network segmentation แบบละเอียด แยก Firewall ตาม environment (dev/staging/prod) หรือตาม layer (web/app/db) ได้อย่างอิสระโดยไม่ต้องกังวลเรื่องต้นทุนเพิ่มขึ้นตามจำนวน Firewall หรือความซับซ้อนของกฎ ต่างจากการซื้อ hardware firewall หรือบริการ WAF บางเจ้าที่คิดราคาตามจำนวน rule หรือ throughput สิ่งเดียวที่มีต้นทุนในระบบนี้คือเวลาที่ใช้ออกแบบและดูแลกฎให้ถูกต้อง ไม่ใช่ตัวเงินที่จ่ายให้ DigitalOcean เพิ่มเติม ข้อควรระวังคือแม้ Cloud Firewall จะฟรี แต่ resource อื่นที่เกี่ยวข้องกันยังมีค่าใช้จ่ายตามปกติ เช่นถ้าใช้ Load Balancer ควบคู่กันราคาเริ่มต้นที่ $12 ต่อเดือนยังคงต้องจ่ายตามปกติ หรือถ้าเชื่อม VPC ซึ่งฟรีเช่นกันแต่เป็นคนละฟีเจอร์กับ Cloud Firewall ดังนั้นเวลาคำนวณต้นทุนโครงสร้างเครือข่ายทั้งระบบ ควรแยกให้ชัดว่าอะไรฟรีจริงและอะไรมีค่าใช้จ่าย

• Cloud Firewall ฟรี 100% ไม่มีค่าใช้จ่ายเพิ่มไม่ว่าจะมีกี่กฎหรือผูกกี่ Droplet
• ใช้ได้ตั้งแต่ Droplet เล็กสุด 512 MiB RAM ราคา $4/เดือน ไปจนถึงระดับองค์กร
• ไม่กระทบ Transfer quota ของ Droplet เพราะเป็นการกรองที่ network edge ไม่ใช่ proxy
• ไม่ต้องซื้อ add-on หรืออัพเกรดแผนใดๆ เพื่อใช้ฟีเจอร์นี้
• resource อื่นที่ใช้ร่วมกัน เช่น Load Balancer ($12/เดือน) ยังมีค่าใช้จ่ายตามปกติ

แก้ปัญหา Firewall บล็อกผิดพลาด และตรวจสอบการเชื่อมต่อ

ปัญหาที่พบบ่อยที่สุดของมือใหม่คือตั้งกฎ SSH ผิดจนล็อกตัวเองออกจาก Droplet เช่นระบุ source ผิด IP หรือลืมรวม IPv6 ไว้ด้วย ข่าวดีคือ DigitalOcean มี Recovery Console (Droplet Console) ในหน้า Control Panel ที่เชื่อมต่อผ่านช่องทาง out-of-band แยกจาก network ปกติของ Droplet โดยสิ้นเชิง การเข้าถึงผ่านช่องทางนี้ไม่ผ่าน Cloud Firewall เลย จึงยังใช้ได้แม้กฎ Inbound จะบล็อก SSH ไปทั้งหมด เข้าไปแก้ไข Firewall จาก Control Panel ให้ถูกต้องแล้วค่อยกลับมาต่อผ่าน SSH ตามปกติ เมื่อสงสัยว่ากฎที่ apply ไปจริงตรงกับที่ตั้งใจหรือไม่ วิธีตรวจสอบที่เร็วที่สุดคือดึงกฎปัจจุบันออกมาดูตรง ๆ ด้วย doctl compute firewall get FIREWALL_ID ซึ่งจะแสดงผลเป็น JSON ครบทุก inbound/outbound rule และ Tag ที่ผูกอยู่ ช่วยตัดปัญหาที่มักเกิดจากการจำผิดว่าเคยตั้งอะไรไว้ ปัญหาที่พบบ่อยรองลงมาคือลืมเปิด IPv6 คู่กับ IPv4 บาง client โดยเฉพาะมือถือหรือเครือข่ายบางประเทศเชื่อมต่อผ่าน IPv6 เป็นหลัก ถ้ากฎระบุแค่ 0.0.0.0/0 โดยไม่มี ::/0 คู่กัน ผู้ใช้กลุ่มนั้นจะเชื่อมต่อไม่ได้เลยโดยที่ผู้ดูแลระบบไม่รู้ตัวเพราะทดสอบจากเครื่องตัวเองที่ใช้ IPv4 แล้วผ่านปกติ เมื่อไม่แน่ใจว่าปัญหาการเชื่อมต่อเกิดจาก Cloud Firewall หรือจากตัวแอปพลิเคชันเอง ให้ SSH เข้า Droplet แล้วรัน tcpdump -i eth0 port 443 ระหว่างพยายามเชื่อมต่อจากภายนอก ถ้าไม่เห็นแพ็กเก็ตเข้ามาเลยแปลว่าโดนกรองอยู่ที่ Cloud Firewall ก่อนถึงเครื่อง ต้องกลับไปตรวจกฎ Inbound แต่ถ้าเห็นแพ็กเก็ตเข้ามาปกติแต่ยังเชื่อมต่อไม่ได้ แปลว่าปัญหาน่าจะอยู่ที่ตัว service หรือ application เอง ไม่เกี่ยวกับ Firewall เลย วิธีแยกจุดนี้ช่วยประหยัดเวลา debug ได้มากในสถานการณ์จริง อีกจุดที่ควรตรวจเป็นประจำโดยเฉพาะทีมที่ใช้ Tag คือ mismatch ระหว่างชื่อ Tag ที่ผูกกับ Firewall กับ Tag ที่แปะไว้บน Droplet จริง พิมพ์ผิดแม้ตัวเดียว เช่น app-prod กับ app_prod จะทำให้กฎไม่ทำงานเลยแบบเงียบ ๆ โดยไม่มี error แจ้งเตือน ควรตรวจด้วย doctl compute droplet list --format Name,Tags เทียบกับ Tag ที่ผูกไว้ใน Firewall เป็นระยะ

• ถ้าเผลอบล็อค SSH ตัวเองให้เข้าผ่าน DigitalOcean Recovery Console (out-of-band ไม่ผ่าน Cloud Firewall) เพื่อแก้กฎได้ทันที
• ใช้ doctl compute firewall get ตรวจกฎปัจจุบันแบบ JSON ก่อนสงสัยว่าอะไรผิด
• ตรวจสอบว่าลืมเปิด source เป็น IPv6 (::/0) คู่กับ IPv4 (0.0.0.0/0) หรือไม่
• ใช้ tcpdump บน Droplet เช็คว่าแพ็กเก็ตมาถึงเครื่องหรือไม่ แยกปัญหา Firewall ออกจากปัญหาแอป

เมื่อไหร่ควรใช้ฟีเจอร์นี้ (Use Case จริง)

ตรงนี้สำคัญ — cloud Firewall เหมาะกับเกือบทุกโปรเจกต์ที่รัน Droplet บน DigitalOcean แต่มีสถานการณ์เฉพาะที่เห็นความคุ้มค่าชัดเจนที่สุด สถานการณ์แรกคือระบบที่แยก Droplet เป็นหลายชั้น (multi-tier) เช่น web server, application server, worker queue, และ database ที่ต้องคุยกันเองภายในแต่ไม่ต้องการเปิดให้อินเทอร์เน็ตเข้าถึงทุกชั้น การใช้ Tag แยกแต่ละชั้น เช่น tier:web, tier:app, tier:worker, tier:db แล้วผูก Firewall เฉพาะของแต่ละ tier ทำให้ควบคุมทิศทางการเชื่อมต่อระหว่างชั้นได้ชัดเจน เช่นอนุญาตให้ tier:app คุยกับ tier:db ได้เฉพาะ port ฐานข้อมูล แต่ tier:web คุยกับ tier:db ไม่ได้เลยแม้จะอยู่ใน VPC เดียวกัน สถานการณ์ที่สองคือการจำกัด Database Droplet ให้รับ connection เฉพาะจาก IP หรือ Tag ของ application server เท่านั้น กรณีนี้พบบ่อยในทีมที่ self-host PostgreSQL หรือ MySQL บน Droplet เอง (ไม่ใช้ Managed Database) เพราะฐานข้อมูลมักเป็นเป้าหมายการโจมตีอันดับต้น ถ้า port 5432 หรือ 3306 เปิดสู่อินเทอร์เน็ตแม้จะมีรหัสผ่านแข็งแรงแค่ไหน ก็ยังเสี่ยงต่อการโดนสแกนหาช่องโหว่หรือ brute-force การใช้ Cloud Firewall จำกัด source เป็น tag:app-server เพียงอย่างเดียวตัดความเสี่ยงนี้ออกไปตั้งแต่ระดับเครือข่าย โดยไม่ต้องพึ่งการตั้งค่าฝั่งฐานข้อมูลเลย สถานการณ์ที่สามคือการแยกสภาพแวดล้อม staging และ production ออกจากกันด้วย Firewall คนละชุด ทีมพัฒนาหลายคนมักทดสอบ feature ใหม่บน staging ที่ควรเข้าถึงได้เฉพาะทีมงานหรือ VPN office เท่านั้น ไม่เปิดสู่สาธารณะเหมือน production ด้วยการสร้าง Firewall แยกกันชื่อเช่น staging-firewall และ production-firewall ผูกกับ Tag env:staging และ env:prod ตามลำดับ ทำให้เผลอเปิด staging ให้คนนอกเข้าถึงได้ยากขึ้นมาก และเมื่อ promote Droplet จาก staging ไป production เพียงเปลี่ยน Tag ก็เปลี่ยนชุดกฎที่บังคับใช้ทันทีโดยไม่ต้องตั้งค่าใหม่ทั้งหมด โดยสรุป Cloud Firewall เหมาะเป็นพิเศษกับระบบที่มีมากกว่าหนึ่ง Droplet ที่ต้องคุยกันเอง หรือระบบที่มีข้อมูลสำคัญอย่างฐานข้อมูลที่ไม่ควรเปิดสู่สาธารณะ ส่วนโปรเจกต์ Droplet เดี่ยวเล็ก ๆ ที่ไม่มี service ภายในให้ป้องกัน อาจใช้แค่ ufw ธรรมดาก็เพียงพอ แต่การผูก Cloud Firewall ไว้ตั้งแต่แรกก็ไม่มีข้อเสียเพราะฟรีและตั้งค่าเพิ่มภายหลังได้เสมอ

• Multi-tier app (web/app/worker/db) ใช้ Tag แยกแต่ละชั้น ควบคุมทิศทางการเชื่อมต่อระหว่างชั้นได้ชัดเจน
• Self-host Database บน Droplet ควรจำกัด source เป็น tag ของ app server เท่านั้น ตัดความเสี่ยงจากการสแกน/brute-force สู่ port DB
• แยก staging กับ production ด้วย Firewall คนละชุด ผูก Tag env:staging / env:prod ป้องกันเผลอเปิด staging สู่สาธารณะ
• Promote Droplet จาก staging ไป production แค่เปลี่ยน Tag ก็เปลี่ยนชุดกฎทันที ไม่ต้องตั้งใหม่

แนวทางปฏิบัติที่ดีที่สุด (Best Practices)

หลักการออกแบบกฎ Cloud Firewall ที่ดีที่สุดคือ least privilege เปิดเฉพาะ port และ source ที่จำเป็นจริง ๆ เท่านั้น ไม่เปิดกว้างไว้ก่อนเผื่ออนาคต เพราะทุกกฎที่เปิดกว้างเกินจำเป็นคือพื้นที่โจมตีที่เพิ่มขึ้นโดยไม่มีประโยชน์ ก่อนเปิด port ใดควรถามตัวเองก่อนเสมอว่าใครต้องเชื่อมต่อจริง ถ้าคำตอบคือ "เฉพาะ application server อีกเครื่อง" ก็ควรระบุ source เป็น Tag ของเครื่องนั้น ไม่ใช่เปิดเป็น 0.0.0.0/0 เพราะสะดวกกว่าตอนตั้งค่าครั้งแรก ข้อแนะนำถัดมาคือใช้ Tags แทน IP เดี่ยวทุกครั้งที่ทำได้ แม้การระบุ IP ตรง ๆ จะดูง่ายกว่าในตอนเริ่มต้น แต่พอระบบโตขึ้นมี Droplet เพิ่มหรือ IP เปลี่ยนจากการ resize/rebuild กฎที่ผูกกับ IP ตรงจะต้องตามแก้ทุกครั้ง ในขณะที่กฎที่ผูกกับ Tag จะทำงานถูกต้องเสมอไม่ว่า Droplet เบื้องหลัง Tag นั้นจะเปลี่ยนไปกี่ครั้งก็ตาม ทีมที่ดูแล Droplet มากกว่า 5-10 เครื่องขึ้นไปควรวางโครงสร้าง Tag ให้ชัดเจนตั้งแต่ต้น เช่นแยกตาม tier, environment, และ region เพื่อให้ผูก Firewall ได้อย่างเป็นระบบ การตรวจสอบกฎเป็นระยะ (periodic audit) ก็สำคัญไม่แพ้กัน ควรตั้งรอบรีวิว Firewall rules อย่างน้อยทุกไตรมาส โดยดึงรายการทั้งหมดออกมาด้วย doctl compute firewall list --format Name,InboundRules,OutboundRules แล้วเช็คว่ายังมีกฎที่เปิดไว้เผื่อทดสอบชั่วคราวแล้วลืมปิดหรือไม่ เช่น IP ของอดีตพนักงานที่ยังผูกอยู่ หรือ port ที่เปิดไว้ debug ตอน deploy ครั้งก่อนแล้วไม่เคยปิด กฎที่ค้างแบบนี้เป็นช่องโหว่เงียบที่มักไม่มีใครสังเกตจนกว่าจะเกิดปัญหาจริง สุดท้ายคือการรวม Cloud Firewall เข้ากับ VPC เพื่อสร้าง defense-in-depth ที่แข็งแรงกว่าการใช้อย่างใดอย่างหนึ่งเพียงอย่างเดียว VPC ตัดขาด Droplet ภายในออกจากการ route ตรงจากอินเทอร์เน็ตสาธารณะตั้งแต่ระดับเครือข่ายก่อนเลย ส่วน Cloud Firewall ทำหน้าที่กรองอีกชั้นแม้แต่ภายใน VPC เดียวกัน เพราะ default ของ VPC เองไม่ได้บล็อกการเชื่อมต่อระหว่าง Droplet ภายในให้อัตโนมัติ การซ้อนสองชั้นนี้หมายความว่าแม้ Droplet ตัวหนึ่งใน VPC จะถูกยึดได้ ผู้โจมตีก็ยังต้องเจอกฎ Cloud Firewall ก่อนจะขยับไปยัง Droplet ตัวอื่นในเครือข่ายเดียวกัน ไม่ใช่เข้าถึงได้อัตโนมัติเพียงเพราะอยู่ VPC เดียวกัน ทั้งสองฟีเจอร์นี้ฟรีทั้งคู่ จึงไม่มีเหตุผลด้านต้นทุนที่จะไม่ใช้ร่วมกัน

1. Least privilege: เปิดเฉพาะ port/source ที่จำเป็นจริง ห้ามเปิดกว้างไว้เผื่ออนาคต
2. ใช้ Tag แทน IP เดี่ยวเสมอเมื่อทำได้ ทนต่อ IP เปลี่ยนจากการ resize/rebuild Droplet
3. รีวิวกฎ Firewall เป็นระยะด้วย doctl compute firewall list อย่างน้อยทุกไตรมาส หากฎค้างที่ลืมปิด
4. รวม Cloud Firewall กับ VPC เป็น defense-in-depth เพราะ VPC เองไม่ได้บล็อกการเชื่อมต่อภายในให้อัตโนมัติ
5. ทั้ง Cloud Firewall และ VPC ฟรีทั้งคู่ ไม่มีเหตุผลด้านต้นทุนที่จะไม่ใช้ร่วมกัน

รับ $200 Free Credit →