Imperva Incapsula là gì?

Scrapeless Scraping Browser cung cấp các phiên trình duyệt được quản lý cho việc trích xuất được ủy quyền từ các trang công khai động.

Imperva Incapsula là tên lịch sử liên quan đến dịch vụ bảo vệ và phân phối ứng dụng dựa trên đám mây của Imperva, hiện nay thường được thảo luận là Imperva Cloud WAF. Dịch vụ này ngồi trước các ứng dụng được bảo vệ và áp dụng các biện pháp bảo mật cho lưu lượng truy cập đến. Lịch sử của nó bao gồm bảo vệ tường lửa ứng dụng web, kiểm soát bot, giảm thiểu DDoS và các chức năng phân phối nội dung.

Đối với một nhà phát triển gặp phải phản hồi mang thương hiệu Imperva, câu hỏi quan trọng là lớp nào đã tạo ra nó. Một từ chối của tường lửa, một thử thách của trình duyệt, một vấn đề ở phía trên, và một phản hồi đã được cache có những ý nghĩa khác nhau. Không nên suy ra bất kỳ điều gì chỉ từ việc thiếu một trường trong trình phân tích của bạn.

Cách Incapsula Liên quan đến Imperva Cloud WAF

Incapsula là một tên sản phẩm cũ trong lịch sử bảo mật ứng dụng đám mây của Imperva. Nghiên cứu hiện tại nên bao gồm các Gia đình sản phẩm Imperva Cloud WAF thay vì giả định rằng một hướng dẫn Incapsula cũ mô tả giao diện hoặc khả năng của ngày hôm nay.

Tên gọi lịch sử có thể được giữ lại trong ghi chú tích hợp, các định danh dịch vụ hoặc tài liệu cũ hơn. Bảo tồn những định danh đó khi chẩn đoán một hệ thống thực, nhưng xác nhận sản phẩm đã triển khai và cấu hình với chủ sở hữu. Một nhãn di sản không chứng minh rằng một tính năng không được hỗ trợ hoặc rằng mọi tính năng hiện tại đều có sẵn trong dịch vụ ban đầu.

Tránh đối xử tất cả các sản phẩm của Imperva như thể chúng có thể hoán đổi cho nhau. Các sản phẩm bảo mật ứng dụng của công ty có các mô hình triển khai khác nhau. Bài viết này tập trung vào bối cảnh bảo vệ đám mây liên quan đến Incapsula, không phải mọi sản phẩm trong danh mục đầu tư của Imperva.

Vị trí Reverse-Proxy trong đường dẫn yêu cầu

Một dịch vụ bảo vệ ứng dụng đám mây có thể nhận yêu cầu của khách truy cập trước ứng dụng gốc và quyết định cách mà yêu cầu đó nên được xử lý. Vị trí trung gian này giải thích tại sao các quan sát ở phía biên và phía gốc có thể khác nhau.

Quy tắc chung Mô hình trung gian HTTP phân biệt các cổng với máy chủ nguồn. Nếu một lớp bảo mật từ chối một yêu cầu trước khi chuyển tiếp nó, nhật ký ứng dụng bình thường của nguồn có thể không chứa một hoạt động kinh doanh tương ứng. Nếu yêu cầu đến được nguồn và nguồn thất bại, thì trung gian có thể trả về một lỗi upstream.

Đối với một chủ sở hữu trang web, liên kết sự kiện biên, yêu cầu gốc và kết quả ứng dụng. Đối với một khách truy cập, bảo quản phản hồi mà bạn thực sự nhận được và tránh tuyên bố rằng nguồn gốc là khỏe mạnh hoặc không khỏe mạnh mà không có bằng chứng. Một trang lỗi có thương hiệu xác định một phần của con đường giao hàng, không nhất thiết là nguyên nhân gốc rễ.

Không bao giờ điều tra một trang bảo vệ bằng cách tìm kiếm nguồn gốc ẩn để tránh kiểm soát của nó. Nếu bạn sở hữu ứng dụng, hãy sử dụng các kênh quan sát và quản trị nội bộ được phê duyệt của bạn. Nếu bạn không sở hữu, hãy yêu cầu người vận hành xem xét yêu cầu bị ảnh hưởng.

WAF, Các Điều Khiển Bot, Bảo Vệ DDoS và Bộ Nhớ Cache

Việc cung cấp ứng dụng có thể kết hợp nhiều chức năng có mục tiêu chồng chéo nhưng không giống nhau. Giữ chúng tách biệt giúp bạn chọn phản ứng đúng cho một sự cố.

Luật: 1. Chỉ xuất ra văn bản đã dịch — không giải thích, không mã bao bọc thêm. 2. Giữ nguyên cấu trúc Markdown/HTML (tiêu đề, danh sách, liên kết, bảng) chính xác. 3. Giữ nguyên bất kỳ mã giữ chỗ nào như @@CODEBLOCK_0@@ hoặc @@INLINECODE_0@@ chính xác như vậy; không bao giờ dịch, thay đổi thứ tự, hợp nhất hoặc định dạng lại chúng. 4. Không thêm hoặc xóa ``` mã bao bọc, và KHÔNG bọc văn bản bình thường vào trong một khối mã. Quy định về bộ nhớ đệm HTTP xác định khi nào các phản hồi lưu trữ có thể được sử dụng lại. Một đại diện được lưu trữ và một đại diện bị từ chối bảo mật là hai thứ khác nhau. Đừng coi mỗi trang không mong đợi là một thử thách của bot, đặc biệt là khi vấn đề có thể là nội dung cũ hoặc phụ thuộc vào ngữ cảnh.

Các Khung tự động đe dọa của OWASP cũng phân biệt các loại lạm dụng ứng dụng khác nhau. Điều đó quan trọng khi giải thích các kiểm soát bot: một công việc thu thập chỉ đọc công khai và một cuộc tấn công tài khoản tự động có thể yêu cầu các chính sách khác nhau ngay cả khi cả hai đều sử dụng các khách hàng phần mềm.

Phản hồi của Imperva có thể và không thể cho bạn biết gì

Một phản hồi mang thương hiệu Imperva có thể giúp xác định dịch vụ bảo vệ hoặc phân phối liên quan, nhưng nó không tự mình tiết lộ quy tắc chính xác hoặc toàn bộ triển khai. Phân loại thông điệp trước khi quy cho một nguyên nhân.

Đọc trạng thái phản hồi, tiêu đề trang, giải thích rõ ràng và bất kỳ định danh tham chiếu nào. Một sự từ chối nên được ghi nhận là một sự từ chối. Một thời gian chờ nên được ghi nhận là một sự cố thời gian. Nếu trang được mong đợi xuất hiện nhưng thiếu các trường, kiểm tra trạng thái ứng dụng và đánh dấu trước khi mở một sự cố bảo mật.

Giữ một trường độ tin cậy quy attribution riêng biệt trong các chẩn đoán nội bộ nếu việc xác định nhà cung cấp quan trọng đối với nhóm của bạn. “Xác nhận bởi cấu hình chủ sở hữu” mạnh hơn “đề xuất bởi thương hiệu trang.” Điều này ngăn không cho một manh mối phản hồi nông trở thành một tuyên bố kiến trúc không được hỗ trợ trong các báo cáo sau này.

Như một ví dụ minh họa, một danh bạ công cộng có thể trả về trang đúng với lựa chọn khu vực khác nhau. Sự không khớp dữ liệu thuộc về ngữ cảnh trang. Một phản hồi từ chối một cách rõ ràng yêu cầu thuộc về xử lý quyền truy cập. Cả hai có thể trông sai với bộ trích xuất, nhưng hành động khắc phục của họ khác nhau.

Một quy trình khắc phục sự cố cho người thu thập dữ liệu công cộng

Một người thu thập dữ liệu công cộng nên trước tiên xác thực tài nguyên và nội dung đã trả về, sau đó xác định xem sự cố có nằm trong quyền kiểm soát được ủy quyền của nó hay không. Một khách hàng được quản lý không cấp cho người thu thập quyền thay đổi chính sách bảo mật của điểm đến.

1. Xác nhận tuyến đường công khai chính xác, phương thức yêu cầu và các trường dự kiến.
2. Kiểm tra URL cuối cùng, loại nội dung và phản hồi rõ ràng trước khi phân tích.
3. Xác định sự từ chối rõ ràng, giới hạn tỷ lệ hoặc thông điệp sự cố phía trên.
4. Kiểm tra xem có cần các bước trình duyệt hoặc lựa chọn khu vực cho phép hay không.
5. Giữ lưu lượng yêu cầu trong phạm vi đã thống nhất và kiểm tra tất cả các công việc liên quan.
6. Thăng tiến các quyết định bảo mật do chủ sở hữu kiểm soát với một gói chứng cứ đã che đậy.

Không lưu một trang bị từ chối như là kết quả trống hợp lệ. Nếu một người thu thập không thể quan sát một danh sách công khai, ghi lại quan sát như không khả dụng. Một danh sách trống nên có nghĩa là một trang hợp lệ không chứa các bản ghi phù hợp, không phải là lớp bảo mật ngăn quyền truy cập.

Giữ các thay đổi trình duyệt và mạng liên quan đến một giả thuyết. Nếu trang cần JavaScript, một trình duyệt có thể cung cấp môi trường thực thi cần thiết. Nếu phản hồi là một sự từ chối chính sách, việc thay đổi hành vi hiển thị có thể không giải quyết được điều đó. Chứng cứ nên xác định hành động tiếp theo.

Những gì Chủ sở hữu Trang nên xác thực sau khi thay đổi chính sách

Các chủ sở hữu trang nên xác thực quyền truy cập hợp pháp, độ chính xác của ứng dụng và việc bảo vệ tiếp tục cùng nhau sau khi thay đổi quy tắc WAF đám mây. Khôi phục quyền truy cập của một khách truy cập là không đủ nếu thay đổi mở ra các tuyến đường nhạy cảm không liên quan.

Bắt đầu với yêu cầu bị ảnh hưởng và sự kiện phù hợp của nó. Xác định xem chính sách có phản ánh hợp đồng ứng dụng dự kiến hay không. Nếu một quy tắc quá rộng, thu hẹp các điều kiện của nó hoặc thiết lập một tích hợp rõ ràng được phê duyệt thay vì vô hiệu hóa lọc trên toàn bộ dịch vụ.

Kiểm tra các tuyến đường được lưu trữ và động một cách riêng biệt. Một trang tĩnh công cộng có thể dễ dàng được xác thực, trong khi một tuyến đường tìm kiếm hoặc tài khoản lại có các yêu cầu trạng thái và quyền xác thực khác nhau. Sử dụng những hành trình đại diện và xác nhận kết quả ứng dụng, không chỉ là sự biến mất của một màn hình lỗi.

Tài liệu quy tắc trước đó, phạm vi mới, lý do thay đổi và con đường quay lại. Giữ cho quyền sở hữu rõ ràng đối với bất kỳ ngoại lệ nào. Các quy tắc bảo mật tích lũy mà không có chủ sở hữu trở nên khó để đánh giá khi ứng dụng hoặc người dùng của nó thay đổi.

Scrapeless và Lớp Thực thi Trình duyệt

Trình duyệt Scrapeless Scraping cung cấp thực thi trình duyệt được quản lý cho các quy trình công khai được ủy quyền. Nó có thể cung cấp môi trường thực thi cần thiết cho nội dung động trong khi để lại các quyết định truy cập cho điểm đến.

Sử dụng tài liệu Trình duyệt Scrapeless Scraping để hiểu khả năng trình duyệt được hỗ trợ. Giữ cho danh tính trang yêu cầu, thị trường và các trường cần thiết rõ ràng trong xác thực. Giải thích về proxy đám mây cung cấp ngữ cảnh liên quan về định tuyến trung gian, điều này nên được giữ tách biệt khỏi quyền ứng dụng và trình diễn trình duyệt.

Lập kế hoạch khối lượng thu thập quanh khối lượng công việc được phép của trang và các nhu cầu thực phẩm thực tế của bạn. Xem xét giá cả Scrapeless cho mặt hạ tầng của kế hoạch. Một phân bổ trình duyệt lớn hơn không mở rộng quyền truy cập hoặc mức lưu lượng truy cập của trang web.

Nếu yêu cầu dữ liệu không thể được đáp ứng thông qua tuyến đường công khai được phép, hãy tìm kiếm một xuất khẩu phê duyệt hoặc giao diện đối tác. Giữ cho khoảng trống rõ ràng cho các người tiêu dùng ở hạ nguồn thay vì lấp đầy nó bằng các giá trị đoán hoặc lặp đi lặp lại coi sự từ chối như một vấn đề phân tích.

Kết luận

Imperva Incapsula thuộc về lịch sử dịch vụ bảo vệ ứng dụng đám mây của Imperva. Hiểu vị trí reverse-proxy giúp phân biệt các quyết định bảo mật, sự cố nguồn và hành vi phân phối nội dung. Các người thu thập nên phân loại trang đã trả về và tôn trọng ranh giới quyền truy cập; các chủ sở hữu nên liên kết các sự kiện và thực hiện các sửa đổi chính sách được định hình hẹp.