Cloudflare Access (Zero Trust) - giới hạn truy cập từ internet cho ứng dụng self-hosted

Cùng với các giải pháp bảo mật Zero Trust khác, Cloudflare Zero Trust trong vài năm gần đây liên tục cung cấp thêm các tính năng mới.
Trong bài này mình sẽ chia sẻ về cách dùng Cloudflare Access - một phần trong Cloudflare Zero Trust - để cho phép người dùng truy cập ứng dụng nội bộ thông qua internet một cách an toàn.

Đây là một giải pháp tổng thể, gồm nhiều phần nhỏ bên trong. Hiểu một cách đơn giản, thì tư tưởng chung của CF Zero Trust (hay bất cứ giải pháp Zero Trust nào nói chung) đó là:

Tạm dịch: Trong kiến trúc Zero Trust, bất kể ai / cái gì cũng đều không đáng tin. Tất cả những gì truy cập vào hệ thống cũng cần phải được xác thực danh tính.

Cá nhân mình từng làm trong một team DevOps mà cứ một tuần sẽ có một hoặc nhiều team khác (Development, R&D) yêu cầu triển khai công nghệ mới. Điều này dẫn đến một vấn đề: việc giới hạn truy cập cho các công nghệ này - nếu chỉ thông qua Firewall, sẽ mất khá nhiều thời gian, và khó có thể đảm bảo an toàn cho toàn bộ hệ thống (do tính phức tạp và thiếu nhất quán, dễ dẫn đến trường hợp ai đó vô tình expose Kafka UI, endpoint môi trường dev - có bật debug - ra ngoài internet).

Tình cờ thời điểm đó, có một người anh làm security bày cho mình: “Ey, có thằng CF Zero Trust này hay lắm, nó làm được mấy cái secure login portal (MFA) đấy. Mà quản trị tất tần tật trong CF thôi, nên apply cho domain nào cũng được. Free Tier đủ dùng, ít nhất là cho team R&D. Anh có làm POC luôn rồi, anh em chỉ việc apply thôi 😊.”

Để các bạn dễ hình dung, mình sẽ lấy một ví dụ thực tế. Đó là dùng CF Zero Trust Access để giới hạn truy cập tới Admin Dashboard của một site Wordpress.

Trong ví dụ này, bất kể ai truy cập vào trang admin cũng cần xác thực OTP qua email. Nếu email đó chưa được whitelist trên Zero Trust dashboard, người dùng sẽ không thể truy cập vào Wordpress Admin.

Khi sử dụng Cloudflare Access, người dùng sẽ cần xác thực danh tính - trong trường hợp phía dưới là nhập địa chỉ email và OTP (gửi về email).

Cloudflare hay bất cứ công nghệ proxy, firewall cũng chỉ là vỏ bọc bên ngoài. Muốn đảm bảo hệ thống được an toàn một cách toàn diện, bạn cần cài đặt thêm firewall rule ở phía server nguồn để đảm bảo server này chỉ có thể được truy cập từ Cloudflare IPs. Sẽ thật vô nghĩa nếu bạn tìm đủ mọi cách để config Cloudflare Zero Trust (hay bất cứ dịch vụ nào khác của Cloudflare), trong để lộ IP và cho phép hacker truy cập trực tiếp vào IP của server phía sau.

Để đảm bảo 100% không xảy ra lỗi lầm này, cách duy nhất là chỉ expose endpoint của ứng dụng nội bộ ra internet khi thực sự cần thiết, hoặc dùng một giải pháp VPN hoặc Tunnel thay thế (ví dụ Cloudflare Tunnel) để cho phép người dùng kết nối vào private network. Khi đó người dùng sẽ cần thực hiện thêm một số thao tác trên thiết bị cá nhân. Mỗi giải pháp sẽ có những ưu nhược điểm riêng, mình sẽ trình bày trong một bài viết khác.

CF Access cho phép người dùng xác minh danh tính theo nhiều phương thức khác nhau. Trên thực tế, đa phần các công ty sẽ sử dụng một giải pháp Identity Provider (IdP) nào đó. Các bạn có thể truy cập vào phần Settings > Authentication > Login methods > Add new để thêm phương thức xác thực.

Tiếp đến là phần quan trọng nhất, định nghĩa các access rule bạn mong muốn, để cho phép / ngăn chặn truy cập từ một hay nhiều người dùng nhất định.

CF cho phép giới hạn tệp người dùng theo nhiều điều kiện khác nhau: Country, Email, IPs, v.v. Ở đây mình chọn cho phép truy cập theo Email của người dùng.

Lưu ý: trên thực tế, các bạn nên gom người dùng thành các group để tiện quản lý, ví dụ quản lý người dùng theo từng team một. Các bạn có thể vào Access > Access groups để thực hiện điều này.

Và cuối cùng là các cài đặt liên quan tới CORS và Cookie.

Ở đây để tiện demo, mình Allow All cho phần CORS vì trước đó mình có gặp một số issue liên quan tới phần CORS khi sử dụng CF RUM (mặc định), dẫn đến lỗi Too many redirects .

Sau khi đã hoàn thành các bước trên, các bạn truy cập vào wp-admin của Wordpress (ví dụ: https://wordpress.example.com/wp-admin) sẽ thấy một Portal hiện lên, yêu cầu xác thực OTP thông qua email, giống như phần ví dụ phía trên mình có trình bày.

Các bạn có thể vào phần Logs > Access để audit lại tất cả các truy cập vào wp-admin.

Từ góc độ người dùng cuối, CF Access xác thực người dùng dựa vào cookie (request header) trong mỗi request gửi tới CF.

Cookie
	cf_clearance=2.XXXX-XX-1.2.1.1-X.QgFCR9Fk4fCASNekiSHO55rLVwYRykuAjF.X.LIRtvp.gl.X.B_96WYZK7XYFn0Njj.1siBcIwyVSvz.X; CF_AppSession=XXX; CF_Authorization=XX…X.X-XX-X-UcIK8j5wP0_PHXRzNonwjgF99Y-X-XX-QFXS-s; wordpress_test_cookie=WP%20Cookie%20check; slimstat_tracking_code=xxx

Với những request không chứa Cookie này hoặc Cookie có giá trị không hợp lệ (token hết hạn, v.v.) Cloudflare sẽ yêu cầu người dùng xác thực danh tính. Ngược lại, khi cookie hợp lệ, CF sẽ cho forward requests tới server nguồn, và người dùng sử dụng website như bình thường.

Thời hạn của Cookie sẽ tuỳ vào config session time được thiết lập trong CF Access application (phần trên).

CF Access chỉ là một phần nhỏ trong tổng thể giải pháp Zero Trust của CF. Để tìm hiểu thêm các bạn có thể vào đây. Cá nhân mình thấy phần Cloudflare Tunnel rất đáng tìm hiểu:
https://developers.cloudflare.com/cloudflare-one/.

Nếu bạn gặp vấn đề với ERR_TOO_MANY_REDIRECTS thì có thể troubleshoot theo guideline này. Ngoài ra, nếu bạn có cài đặt CORS cho website giống mình, thì có thể check thêm config của phần CORS trên server và trên CF Access:
https://developers.cloudflare.com/ssl/troubleshooting/too-many-redirects/.

Mình có viết một bài khác liên quan tới CF Logs ở đây, bạn nào tò mò có thể tham khảo nhé:
https://techmaster.vn/posts/38236/su-dung-python-graphql-phan-tich-logs-cua-cloudflare-firewall-event-ban-free!

Hẹn gặp lại các bạn trong các bài viết tiếp theo liên quan tới chủ đề Cloudflare. Nếu các bạn có trải nghiệm nào thú vị liên quan đến Cloudflare Access, thì hãy để lại dưới phần comment để mọi người cùng học hỏi nhé!

Peace ❤️