Bảo mật mọi ứng dụng nội bộ chỉ với một cú nhấp chuột cùng Cloudflare Access

AI đã cho phép nhân viên ở mọi nhóm xây dựng ứng dụng nhanh hơn bao giờ hết.

Nhưng tốc độ đó cũng chính là điều khiến mọi CISO phải mất ngủ: bất kỳ nhân viên nào cũng có thể xây dựng một ứng dụng, triển khai nó lên Internet công cộng và vô tình làm lộ công việc nội bộ hoặc dữ liệu công ty.

Hôm nay, chúng tôi ra mắt các công cụ mới giúp việc giữ cho các ứng dụng được lưu trữ trên Workers ở chế độ riêng tư trở nên dễ dàng hơn. Giờ đây, bạn có thể áp dụng Cloudflare Access trực tiếp cho một Worker hoặc cho mọi Worker trong tài khoản của mình, để các ứng dụng của bạn mặc định nằm sau lớp đăng nhập của công ty mà không cần dựa vào việc từng lập trình viên phải tự thiết lập điều đó.

Giờ đây, bạn có thể:

Access trên Workers: cách thức hoạt động

Khi bạn bật Access trên một Worker, Cloudflare sẽ thực thi xác thực trước khi bất kỳ yêu cầu nào đến được mã ứng dụng của bạn. Không quan trọng yêu cầu đó đến Worker của bạn bằng cách nào, dù là thông qua tên miền tùy chỉnh, route, tên miền phụ workers.dev hay URL xem trước. Nếu Access được bật, người dùng phải xác thực trước.

Trước đây, bạn phải cấu hình việc này ở cấp hostname, nghĩa là phải thiết lập các chính sách Access trên mỗi tên miền mà Worker của bạn có thể truy cập được. Nếu muốn thêm một tên miền tùy chỉnh mới vào Worker, bạn cần cập nhật chính sách Access trước, nếu không hostname đó sẽ có thể truy cập được mà không cần xác thực. Giờ đây, chính sách được gắn trực tiếp vào Worker, vì vậy bất kỳ tên miền hoặc URL nào liên quan đến Worker đó đều được bảo vệ tự động. Bạn có thể chọn những gì cần bảo vệ: chỉ các URL xem trước hoặc tất cả các hostname.

Nếu bạn đặt thành chỉ xem trước, mọi URL xem trước được tạo cho ứng dụng đó, dù là URL xem trước workers.dev hay tên miền tùy chỉnh mà bạn sử dụng để xem trước, sẽ yêu cầu xác thực bất cứ khi nào bạn triển khai phiên bản mới. Nếu bạn đặt thành tất cả các hostname, mọi tên miền liên quan đến Worker đó đều được bảo vệ — bao gồm tên miền tùy chỉnh, route, tên miền phụ workers.dev và các URL xem trước.

Access cho phép bạn kiểm soát cách người dùng xác thực. Bạn có thể kết nối với nhà cung cấp danh tính (identity provider) hiện có để nhân viên đăng nhập bằng thông tin xác thực họ vẫn dùng, hoặc giới hạn quyền truy cập vào các địa chỉ email, tên miền email hoặc nhóm cụ thể. Đối với các tác nhân (agents), bạn có thể cấp quyền truy cập thông qua service tokens.

Đọc thêm trong tài liệu Cloudflare Access for Workers tại đây.

Giữ mọi Worker trong tài khoản của bạn ở chế độ riêng tư theo mặc định

Nếu bạn có các lập trình viên trên toàn tổ chức đang triển khai Workers, bạn không muốn phải dựa vào việc mỗi người phải nhớ bật Access. Bạn muốn mặc định phải là riêng tư.

Bạn có thể thiết lập chính sách Access một lần ở cấp tài khoản và mọi Worker trong tài khoản của bạn, cả hiện tại và tương lai, đều ở chế độ riêng tư ngay từ thời điểm được tạo.

Bạn chọn phạm vi áp dụng chính sách: chỉ lưu lượng truy cập URL xem trước, tất cả lưu lượng truy cập production, hoặc cả hai. Chế độ chỉ xem trước rất hữu ích nếu các Worker production của bạn cố tình để công khai, nhưng bạn không bao giờ muốn một bản triển khai đang thực hiện bị lộ.

Cần một Worker ở chế độ công khai? Hãy bỏ qua chính sách toàn tài khoản trên Worker cụ thể đó.

Bảo vệ một Worker cụ thể

Nếu bạn không cần mặc định toàn tài khoản và chỉ muốn khóa một Worker cụ thể, bạn có thể áp dụng Access trực tiếp cho Worker đó.

Tab Access mới trong giao diện Worker hiển thị chính xác những chính sách nào áp dụng cho ứng dụng đó. Nếu bạn có nhiều chính sách, chính sách cụ thể nhất sẽ được ưu tiên: chính sách hostname trước, sau đó đến chính sách Worker, và cuối cùng là chính sách tài khoản.

Xem ai đang truy cập ứng dụng của bạn

Khi Access bảo vệ Worker của bạn, bạn có thể nhận thông tin về người đang thực hiện từng yêu cầu — email, tên và nhóm của họ — để bạn có thể cá nhân hóa những gì họ thấy, thực thi quyền hoặc ghi nhật ký hoạt động theo từng người dùng.

Việc này hoạt động thông qua đối tượng ngữ cảnh (ctx) của Worker. Mọi yêu cầu gửi đến Worker của bạn đều mang theo một ctx chứa siêu dữ liệu về yêu cầu đó. Khi Access được bật, chúng tôi đính kèm danh tính của người dùng đã xác thực vào đó dưới dạng ctx.access. Từ đó, hãy gọi ctx.access.getIdentity để lấy lại email, tên và các thông tin khác của người dùng.

Trước đây, điều này có nghĩa là bạn phải tự xác thực JWT — phân tích cú pháp token, xác minh chữ ký và trích xuất các claims. Giờ đây, khi Access được bật trên Worker của bạn, mọi yêu cầu đã xác thực đều bao gồm ctx.access.

Đây là tất cả những gì bạn cần để lấy danh tính người dùng:

Kiểm thử cục bộ trước khi triển khai

Chúng tôi đã chỉ ra cách bạn có thể sử dụng ctx.access.getIdentity để cung cấp cho Worker thông tin về người đang thực hiện yêu cầu — email, tên và nhóm của họ.

Bạn có thể sử dụng điều này khi phát triển cục bộ với wrangler dev. Thêm một khối access vào tệp wrangler.jsonc của bạn để mô phỏng một người dùng đã xác thực:

Worker của bạn sẽ nhận thông tin đó thông qua ctx.access.getIdentity — trả về một đối tượng danh tính có cấu trúc giống như những gì bạn nhận được trong môi trường production. Hãy thay đổi email trong cấu hình của bạn để kiểm thử với tư cách là một người dùng khác.

Điều này có nghĩa là bạn có thể xác minh rằng nội dung phù hợp sẽ hiển thị cho đúng người dùng mà không cần phải triển khai và đăng nhập thông qua Access mỗi khi bạn thực hiện thay đổi.

Triển khai một nền tảng nội bộ nơi mọi ứng dụng đều ở chế độ riêng tư theo mặc định

Nếu bạn quản lý một nền tảng nội bộ nơi nhân viên có thể tạo mẫu và triển khai ứng dụng, bạn cần mọi ứng dụng phải ở chế độ riêng tư mà không cần cấu hình kiểm soát truy cập trên từng ứng dụng.

Workers for Platforms cho phép bạn triển khai Workers ở quy mô lớn. Mỗi Worker nằm trong một namespace và tất cả lưu lượng truy cập đến namespace đó đều đi qua một điểm nhập duy nhất: dispatch Worker.

Thiết lập chính sách Access trên dispatch Worker của bạn, và mọi Worker được triển khai thông qua nó sẽ mặc định ở chế độ riêng tư.

Chúng tôi cũng có một ví dụ mã nguồn mở nơi bạn có thể triển khai nền tảng triển khai kéo-thả nội bộ của riêng mình — cấu hình quyền truy cập trên dispatcher worker một lần và mọi trang web được triển khai thông qua nó sẽ mặc định ở chế độ riêng tư.

Nhấp vào nút bên dưới để tự triển khai!

Để biết kiến trúc đầy đủ, hãy xem kiến trúc tham chiếu Workers for Platforms của chúng tôi.

Được xây dựng trên nền tảng vững chắc

Tính năng này được hiện thực hóa nhờ FL2, proxy mô-đun dựa trên Rust mới vận hành edge của Cloudflare. Access là cổng chính dẫn đến các ứng dụng của bạn, và theo truyền thống, nó chạy trước tất cả logic của Workers trong quy trình xử lý yêu cầu. Nhưng để các ứng dụng Access có thể nhắm mục tiêu vào từng Worker riêng lẻ thay vì hostname của chúng, Access cần biết Worker nào mà một yêu cầu nhất định sẽ hướng tới. Do đó, chúng tôi cần tách biệt việc định tuyến Workers khỏi quá trình thực thi Workers và di chuyển logic định tuyến để nó có thể chạy trước Access.

Trong hệ thống FL1 cũ dựa trên NGINX và các mô-đun viết bằng Lua, thay đổi này sẽ rất phức tạp và rủi ro. Sự tương tác giữa các sản phẩm có thể rất tinh vi, và việc di chuyển logic sang giai đoạn sớm hơn của quy trình yêu cầu có thể không an toàn nếu nó phụ thuộc vào trạng thái chia sẻ bị sửa đổi bởi một sản phẩm khác.