Trước khi bắt đầu
Quý vị cần có:- quyền quản lý tích hợp và khóa truy cập trong Living Security
- một bên gửi phía máy chủ có khả năng thực hiện các yêu cầu HTTPS
POST - khu vực Living Security của tổ chức quý vị
- một tên nguồn ổn định và ít nhất một tên luồng
1. Đăng ký nguồn và các luồng
1
Mở Custom Push Source
Đi tới Cài đặt → Tích hợp → Danh mục, tìm Custom Push Source, rồi chọn Thêm.
2
Đặt tên cho nguồn
Nhập khóa định tuyến của nguồn và phần mô tả tùy chọn. Ví dụ, hãy dùng
custom-phishing-sim thay vì tên hiển thị có chứa khoảng trắng.3
Thêm các luồng
Thêm từng luồng mà bên gửi sẽ sử dụng. Cặp nguồn và luồng phải tồn tại trước lần đẩy dữ liệu đầu tiên; một cặp không xác định sẽ trả về
404 Not Found.4
Lưu nguồn
Sau khi tạo, hãy mở nguồn tại Cài đặt → Tích hợp → đã kết nối. Chế độ xem Push via API hiển thị mẫu điểm cuối và các lần chạy gần đây.
2. Tạo khóa push-ingest
Đi tới Cài đặt → Access Keys, chọn Create Access Key, rồi chọn phạm vi Push Ingest. Hãy sao chép giá trị được tạo ngay lập tức; giá trị này chỉ hiển thị một lần. Khóa được gắn với một tổ chức Living Security. Yêu cầu đẩy dữ liệu không cần tiêu đề tổ chức. Xem Khóa truy cập API để biết cách xoay vòng và thu hồi khóa.3. Chọn điểm cuối theo khu vực
Hãy dùng tên máy chủ tương ứng với tổ chức Living Security:
Nối thêm
/push-ingest/{integrationKey}/{streamName}. Đường dẫn phân biệt chữ hoa chữ thường và phải khớp chính xác với nguồn và luồng đã đăng ký.
string
bắt buộc
Tên nguồn đã đăng ký. Sử dụng 1–64 ký tự là chữ cái thường, chữ số hoặc dấu gạch nối, bắt đầu bằng chữ cái hoặc chữ số.
string
bắt buộc
Tên luồng đã đăng ký. Áp dụng các quy tắc tương tự, và cho phép thêm dấu gạch dưới.
string
bắt buộc
Gửi khóa truy cập push-ingest dưới dạng
Bearer <access-key>.string
Dùng
application/json cho JSON hoặc text/csv cho CSV. Máy chủ cũng có thể nhận diện mảng JSON khi bỏ qua tiêu đề này.string
UUID tổ chức (tùy chọn). Khóa truy cập đã xác định tổ chức. Nếu quý vị gửi tiêu đề này, giá trị phải khớp với tổ chức của khóa; không thể dùng tiêu đề này để chọn tổ chức khác.
Nội dung yêu cầu
Gửi một mảng JSON cấp cao nhất, không rỗng, gồm các đối tượng, hoặc các byte của tệp CSV có dòng tiêu đề. Không có trường bao bọc JSON được đặt tên. Mỗi lô có thể chứa tối đa 10,000 bản ghi và 10 MB.4. Gửi một lô JSON
Gửi một mảng JSON không rỗng có các phần tử là đối tượng.Content-Type: application/json được khuyến nghị và được nhiều sản phẩm gửi dữ liệu yêu cầu, mặc dù Living Security có thể nhận diện nội dung dạng mảng mà không cần tiêu đề này.
202 Accepted. Thẻ lỗi hiển thị 400 Bad Request khi nội dung JSON bị sai định dạng:
400, hãy sửa JSON hoặc gửi CSV kèm Content-Type: text/csv, rồi thử lại.
string
bắt buộc
ID lần chạy của lô được chấp nhận này. Hãy lưu lại để kiểm tra trạng thái xử lý.
number
bắt buộc
Số bản ghi đã được chấp nhận và lưu trữ.
string
bắt buộc
Tên nguồn được dùng cho lần đẩy này.
string
bắt buộc
Tên luồng được dùng cho lần đẩy này.
Gửi CSV thay thế
ĐặtContent-Type: text/csv và gửi các byte của tệp, như minh họa trong ví dụ yêu cầu CSV file ở trên. Dòng đầu tiên cung cấp tên các trường.
Văn bản Boolean được chuyển thành giá trị boolean và văn bản số thông thường được chuyển thành số. Các giá trị bắt đầu bằng số 0, số nguyên lớn không an toàn, ngày tháng và văn bản khác vẫn giữ nguyên là chuỗi. Ô trống sẽ bỏ qua trường đó. Các dòng sai định dạng, dấu ngoặc kép không cân xứng và tệp UTF-16 sẽ bị từ chối.
Giới hạn yêu cầu và thử lại
Hãy chia các tệp xuất lớn hơn thành những lô đáp ứng cả hai giới hạn. Chờ từng phản hồi và lưu lại
runId được trả về trong nhật ký của bên gửi.
Giới hạn thông thường của tổ chức đã xác thực trả về
503, không phải 429, nên các bên gửi webhook coi đây là lỗi có thể thử lại. 503 được trả về trước khi lô dữ liệu được lưu trữ; việc gửi lại chính lô đó sau khoảng thời gian được nêu sẽ không tạo ra lần chạy trùng lặp đã được chấp nhận.
Xác minh luồng dữ liệu
Mở Custom Push Source và xem lại Push History. Xác nhận luồng, số lượng bản ghi, thông tin khóa được gán và trạng thái xử lý. Dữ liệu có bộ diễn giải được duy trì sau đó có thể trở thành người dùng và hoạt động đã chuẩn hóa. Dữ liệu không có bộ diễn giải vẫn được lưu trữ nhưng không tạo ra hoạt động.Hãy sử dụng chính xác tên trường và cấu trúc payload từ hướng dẫn riêng của nhà cung cấp khi
có hướng dẫn đó. Một
202 thành công chỉ chứng minh việc gửi dữ liệu, không chứng minh rằng
một lược đồ bất kỳ sẽ ánh xạ sang hoạt động của Living Security.Danh sách kiểm tra khắc phục sự cố
- Sao chép điểm cuối từ đúng nguồn và thay thế phần giữ chỗ của luồng.
- Gửi khóa truy cập dưới dạng
Authorization: Bearer …;x-api-keykhông được chấp nhận. - Xác nhận nội dung là một mảng JSON cấp cao nhất, không phải một đối tượng đơn lẻ hoặc một lớp bao bọc quanh các bản ghi.
- Xác nhận chính tả của nguồn và luồng, bao gồm dấu gạch nối, dấu gạch dưới và chữ hoa chữ thường.
- Xem lại Push History trước khi gửi lại một lô có phản hồi bị mất.
- Khi liên hệ Bộ phận Hỗ trợ của Living Security, hãy cung cấp tổ chức, nguồn, luồng, thời điểm gửi yêu cầu,
runIdnếu có và trạng thái phản hồi. Không bao gồm khóa truy cập hoặc payload sự kiện.
Nội dung liên quan
Zscaler ZIA Cloud NSS
Cấu hình nguồn cấp dữ liệu nhật ký web Zscaler được hỗ trợ với đúng nguồn, luồng, tiêu đề và cấu trúc JSON.
Khóa truy cập API
Tạo, xoay vòng và thu hồi thông tin xác thực có phạm vi giới hạn.
Nguồn dữ liệu Tín hiệu
Tìm hiểu cách hoạt động tích hợp đã được diễn giải hỗ trợ các tín hiệu.

