Proxy cho dịch vụ máy chủ ArcGIS an toàn. Đảm bảo?

Để truy cập các dịch vụ bảo mật (dựa trên mã thông báo hoặc thông tin đăng nhập), Esri khuyên bạn nên sử dụng tệp proxy ( ví dụ .net github ). Khi định tuyến các yêu cầu thông qua proxy, bạn có thể yêu cầu các dịch vụ bảo mật thay mặt cho khách hàng mà không để lộ thông tin đăng nhập của bạn. Bạn có thể xác định một thuộc tính được gọi allowedReferersvà gán danh sách URL giới thiệu mà proxy sẽ hoạt động. Về cơ bản, proxy sẽ không thực hiện bất kỳ yêu cầu giới thiệu URL nào không được xác định. Nếu được đặt thành '*', mọi yêu cầu tham chiếu sẽ được xử lý.

Vấn đề là; tiêu đề yêu cầu được giả mạo dễ dàng bởi tin tặc chỉ bằng cách đặt thuộc tính HTTP Referenceer giả . Trong tình huống này, họ có thể truy cập các dịch vụ bảo mật bằng cách định tuyến tất cả các yêu cầu của họ thông qua proxy và đặt tiêu đề người giới thiệu thành một địa chỉ hợp lệ.

Tôi đang tìm kiếm các khuyến nghị về cách tốt nhất để giải quyết vấn đề này. Có khuyến nghị nào không?

— làm ơn
nguồn

Câu hỏi tuyệt vời. Gần đây chúng tôi cũng đã thử nghiệm điều này và rất buồn khi thấy rằng điều này có thể kém an toàn hơn so với việc chuyển mã thông báo qua chuỗi truy vấn. Như bạn đã chỉ ra, bạn chỉ có thể chuyển yêu cầu thông qua proxy. Chúng tôi đã có thể xác minh điều này chỉ bằng một vài dòng mã Python ... Chúng tôi có thể duyệt qua toàn bộ Thư mục dịch vụ của mình mà không cần thông tin xác thực. Ít nhất với mã thông báo được chuyển với yêu cầu, mã thông báo phải được kích hoạt / truy xuất trước, điều này có vẻ an toàn hơn một chút đối với tôi. Tôi cũng tò mò nếu ai có một số gợi ý tốt.

— crmackey

"Esri đề xuất ...": xem blog.esri.com/esri/supportcenter/2015/04/07/setting-up-a-proxy . Có vẻ tốt để trích dẫn một sự cố của khuyến nghị nói.

— gischimp

Cảm ơn gischimp. Đây là một tài nguyên tốt để thiết lập proxy nhưng nó không tham chiếu bất kỳ phương pháp nào để đảm bảo vấn đề chúng ta gặp phải. Tôi biết cả Portal và ArcGIS Online đều có oAuth2. Tôi tự hỏi nếu phiên bản tiếp theo của ArcGIS Server sẽ hỗ trợ điều này? Hiện tại, nó sẽ xuất hiện @crmackey là chính xác; phương pháp an toàn nhất (ít nhất là đối với các dịch vụ dựa trên mã thông báo) là không sử dụng proxy và chỉ đính kèm mã thông báo vào yêu cầu GET.

— jOshT

Điều đáng nói là bạn có thể thêm mã thông báo vào cookie bằng agstokenkhóa. Điều này không thêm toàn bộ bảo mật bổ sung nhưng ít nhất mã thông báo không xuất hiện trong chuỗi truy vấn.

— crmackey

Câu trả lời:

Tôi lưu trữ proxy Java trong Apache Tomcat cung cấp trang đăng nhập. Proxy ArcGIS chạy trong cùng bối cảnh ứng dụng với trang đăng nhập. Bằng cách này, người dùng của tôi có quyền truy cập với thông tin đăng nhập được lưu trữ trong một cơ sở dữ liệu an toàn, riêng biệt. Tomcat thực hiện quản lý phiên thông thường trong khi proxy ArcGIS được sửa đổi một chút sẽ xử lý các thông tin và mã thông báo ArcGIS ẩn. Tất cả điều này được thực hiện qua HTTPS.

Kết quả là:

Thông tin đăng nhập ArcGIS không bao giờ được truyền bên ngoài mạng nội bộ.
Người dùng không thể truy cập proxy mà không có phiên hợp lệ.
Các phiên hợp lệ chỉ được cấp cho người dùng có thông tin xác thực.

— C. David Gibson
nguồn

Khi định tuyến các yêu cầu thông qua proxy, bạn có thể yêu cầu các dịch vụ bảo mật thay mặt cho khách hàng mà không để lộ thông tin đăng nhập của bạn.

Tôi nghĩ rằng câu này là chìa khóa. Khi proxy xác thực với máy chủ GIS, proxy có được cấu hình với thông tin đăng nhập không? Nếu vậy, và những thông tin đó có quyền truy cập vào dịch vụ bản đồ được yêu cầu, thì có vẻ như nó "đang hoạt động như dự định".

Nếu proxy đang lưu trữ / chuyển thông tin đăng nhập, thì proxy quan tâm nhiều hơn đến việc giữ thông tin đăng nhập an toàn hơn là giữ an toàn cho dữ liệu. Hãy nghĩ về một trang web mạng nội bộ của công ty hiển thị dữ liệu bản đồ từ một dịch vụ bản đồ an toàn.

tiêu đề yêu cầu được giả mạo dễ dàng bởi tin tặc

Có phải tuyên bố trên có nghĩa là kẻ tấn công bên ngoài có thể truy cập proxy của bạn trực tiếp không? Nếu vậy, bạn có nhiều điều phải lo lắng hơn là một tiêu đề HTTP giả mạo.

Có phải người dùng, proxy và máy chủ GIS đều ở trong mạng của bạn hoặc người dùng đang sử dụng proxy để kết nối với các dịch vụ GIS bên ngoài mạng? Biết một số chi tiết về cấu trúc liên kết mạng của bạn có thể giúp bạn có một số câu trả lời tốt hơn.

chỉnh sửa: Nếu bạn có một ứng dụng web công cộng đang tìm nạp tài nguyên từ máy chủ GIS được bảo mật trong mạng, thì bạn có thể muốn một proxy ngược thay vì proxy chuyển tiếp.

— Bạc hà
nguồn

Tôi nghĩ rằng @jOshT chia sẻ cùng một mối quan tâm mà tôi làm đó là dường như không có cách nào để bảo vệ các điểm cuối REST khỏi những khách truy cập không mong muốn. Có, proxy ẩn thông tin đăng nhập, nhưng nếu bạn biết url proxy, bạn thậm chí không phải lo lắng về thông tin đăng nhập vì bạn chỉ có thể định tuyến tất cả các yêu cầu của mình thông qua proxy và thông tin đăng nhập được gửi ở mặt sau. Tôi đã thử nghiệm điều này với một vài dòng Python .

— crmackey

Tôi đồng ý rằng proxy thực hiện tốt việc bảo mật thông tin đăng nhập. Khi bạn nói 'tiếp cận proxy trực tiếp'; Tôi sẽ nói loại. Ứng dụng này là công khai (như là proxy), nhưng ai đó thực sự không thể 'nhìn thấy' nội dung của proxy của tôi (.net). Lấy ví dụ về một ví dụ Esri developers.arcgis.com/javascript/samples/ags_traffic . Ở đây họ đang sử dụng proxy để truy cập các dịch vụ an toàn. Sử dụng các công cụ mạng của nhà phát triển Chrome, tôi chỉ có thể sao chép yêu cầu (cURL) và thực hiện nó từ dòng lệnh để lấy thông tin. Làm thế nào các proxy có thể được bảo mật?

— jOshT

@jOshT Bạn có thể dán tệp proxy.config và xóa các bit nhạy cảm không? Mặc dù từ nhận xét của bạn, có vẻ như bạn có thể tốt hơn với proxy ngược thay vì proxy chuyển tiếp.

— Mintx

@Mintx Proxy của tôi về cơ bản giống như Esri ở đây: github.com/Esri/resource-proxy/tree/master/DotNet ngoại trừ tôi đã đặt cho phépReferers thành URL cho ứng dụng yêu cầu.

— jOshT