Cách giải quyết các vấn đề bảo mật trong báo cáo Allure

Báo cáo kiểm tra chi tiết và trực quan hấp dẫn là rất quan trọng để người kiểm thử phần mềm hiểu được kết quả kiểm tra và đưa ra quyết định sáng suốt. Với sự chú ý tỉ mỉ đến từng chi tiết, nhóm của Nhóm Khám phá Xã hội đã tạo ra các báo cáo thử nghiệm trực quan hấp dẫn với sự trợ giúp của Allure Reports - cường quốc nguồn mở dường như có tất cả các câu trả lời. Tuy nhiên, chúng tôi đã phát hiện ra một lỗ hổng: bảo mật. Bất kỳ ai có liên kết đều có thể nhìn vào bên trong và khả năng thích ứng của nó trên các hệ thống con còn thiếu. Trong bài viết này, nhóm thử nghiệm SDG chia sẻ cách họ giải quyết các vấn đề bảo mật trong báo cáo Allure bằng cách tạo Allure Docker thích hợp và sửa đổi sơ đồ lưu trữ.

Môi trường phát triển SDG dựa trên các sản phẩm của Microsoft, với Azure DevOps được sử dụng để thực thi các quy trình CI/CD. Thông qua quy trình CI, kho lưu trữ các bài kiểm tra tự động được xây dựng, sau đó là phân loại thông qua một số quy trình CD dựa trên sở thích của người kiểm tra khi chạy thử nghiệm.

Hãy xem xét sơ đồ như ban đầu nó được thiết lập:

Trong thiết lập này, quy trình CD cũng đóng vai trò là trình tạo cho hai báo cáo Allure: một cho thông báo Slack, cung cấp cho người thử nghiệm một liên kết dễ đọc, chỉ định các giai đoạn và danh mục thử nghiệm, còn một báo cáo khác để xuất báo cáo Allure sang Azure DevOps.

Điều này đạt được thông qua việc cài đặt tiện ích mở rộng trong Azure DevOps, cho phép tạo báo cáo và sau đó tải lên vùng chứa $web cho các trang web tĩnh trong tài khoản lưu trữ Azure. Cấu hình được kích hoạt của quyền truy cập ẩn danh cho phép báo cáo được hiển thị thông qua một liên kết.

Để thuận tiện hơn, một plugin bổ sung cũng được sử dụng để hiển thị báo cáo Allure trong quy trình xây dựng.

Mặc dù sơ đồ này hoạt động hiệu quả nhưng nó có một số nhược điểm nhất định:

Thứ nhất, phương pháp này thiếu bảo mật vì bất kỳ ai có liên kết đều có thể truy cập được báo cáo Allure. Tùy thuộc vào thử nghiệm, báo cáo có thể chứa thông tin bí mật về các dịch vụ, lỗ hổng bảo mật của chúng và bất kỳ dữ liệu nhạy cảm nào khác cần hạn chế quyền truy cập công khai. Quyền truy cập chung được cấp do cờ "truy cập ẩn danh" được bật trong tài khoản lưu trữ Azure, cờ này cung cấp cho bất kỳ ai quyền truy cập vào địa chỉ. Việc tắt chức năng này sẽ ngừng quyền truy cập từ bên ngoài vào các tệp đối với những cá nhân không được ủy quyền nhưng cũng sẽ khiến báo cáo không thể truy cập được trên trang Azure DevOps.

Thứ hai, phương pháp này không được áp dụng phổ biến trên các hệ thống con. Nếu chúng tôi kiểm tra danh sách công việc trong hệ thống CD, chúng tôi sẽ thấy rằng công việc gốc "azcopy" được sử dụng để sao chép báo cáo vào tài khoản lưu trữ. Công việc này chỉ có ở Agent trên Windows, khi dùng Linux thì báo lỗi.

Thứ ba, có sự bất tiện khi xem lịch sử và xu hướng kiểm tra. Lịch sử báo cáo duy nhất có sẵn chỉ có thể truy cập được thông qua thông báo Slack, đây không phải là phương pháp thuận tiện để tìm kiếm các bài kiểm tra cụ thể.

Tất cả các yếu tố nêu trên dẫn đến kết luận rằng hệ thống hiện tại cần phải được sửa đổi. Vì vậy, một số giải pháp cho vấn đề này đã được xem xét:

1. Tạo một phương pháp để tạo tệp .html hợp nhất sẽ kết hợp toàn bộ dự án báo cáo Allure vào một tài liệu.

2. Sử dụng các dịch vụ của bên thứ ba cung cấp xác thực để xem báo cáo.

3. Tìm kiếm hình ảnh được tạo sẵn có xác thực riêng để xem báo cáo.

   
   

Bây giờ chúng ta hãy đi sâu vào từng điểm này một cách chi tiết hơn.

Như đã đề cập trước đó, việc vô hiệu hóa chức năng "truy cập ẩn danh" trong tài khoản lưu trữ sẽ hạn chế quyền truy cập vào các tệp qua liên kết đối với người dùng trái phép. Để cung cấp quyền truy cập cho các cá nhân cụ thể từ bên ngoài, bản thân Azure cung cấp một số tùy chọn khả thi - bao gồm cấp mã thông báo SAS và định cấu hình chính sách Truy cập. Tuy nhiên, do tính chất của việc tạo báo cáo Allure, cụ thể là tệp index.html, tham chiếu các tập lệnh JavaScript hiện có trong cấu trúc dự án:

Khi mở báo cáo, trang này trống vì quyền truy cập giữa các tệp trong bộ lưu trữ blob bị hạn chế.

Để tạo một tệp .html duy nhất, chúng tôi đã phát hiện ra một hình ảnh khi được triển khai, đã tạo điều kiện thuận lợi cho việc tạo tệp từ toàn bộ dự án Allure bằng cách sử dụng lệnh nhúng "allure-combine ./path/to/allure/generated/report/folder." Tuy nhiên, quá trình này yêu cầu tác nhân phải cài đặt Python. Thật không may, cách tiếp cận này tỏ ra không hiệu quả do không có tệp đính kèm với kết quả kiểm tra API, đây là những thành phần quan trọng để đảm bảo công việc của người kiểm tra hoạt động bình thường.

Cũng cần lưu ý rằng Azure cung cấp danh sách IP trắng, cho phép lọc những cá nhân cần quyền truy cập. Tuy nhiên, vì nhóm cần truy cập không có địa chỉ IP tĩnh nên phương pháp này không phù hợp.

Xét rằng Allure là một phương pháp phổ biến để thu thập các bài kiểm tra trong môi trường phát triển, nên có các dịch vụ trả phí trực tuyến. Ví dụ: dịch vụ https://qameta.io/ cung cấp khả năng lưu trữ và tạo báo cáo Allure trong giao diện web thân thiện với người dùng. Tuy nhiên, những dịch vụ như vậy thường phải trả phí và chức năng cần thiết ở mức tối thiểu. Vì vậy, chúng tôi coi phương án triển khai này là phương sách cuối cùng.

Lựa chọn mà chúng tôi đưa ra là hình ảnh Docker của dịch vụ allure-docker ( https://github.com/fescobar/allure-docker-service ) với khả năng tích hợp của bảng giao diện người dùng ( https://github.com/fescobar/ allure-docker-service-ui ) bằng xác thực. Giao tiếp với dịch vụ được định cấu hình qua HTTP/HTTPS và bản thân hình ảnh hỗ trợ chức năng thông qua các yêu cầu API.

Hãy nêu bật một số ưu điểm của giải pháp này:

1. Bảo mật: Việc truyền dữ liệu được mã hóa bằng cơ chế SSL và TLS, đồng thời hình ảnh cung cấp cho người dùng "quản trị viên" và "người xem" tích hợp thông tin đăng nhập có thể được sửa đổi và cung cấp cho người dùng dựa trên nhu cầu của họ.

2. Thuận tiện: Dịch vụ đi kèm với giao diện trực quan riêng cung cấp nhiều chức năng khác nhau để làm việc với báo cáo Allure.

3. Chức năng: Nhờ các yêu cầu API, các kết hợp thú vị có thể được tạo ra với các quy trình phát hành ở phía Azure DevOps. Ví dụ: tạo báo cáo, tải báo cáo lên và sau đó xóa bộ nhớ đệm trong một giai đoạn.

   
   

Tóm lại, quy trình phát hành của chúng tôi trông như thế này:

Điều đáng chú ý là chúng tôi đã không rời bỏ tiện ích mở rộng Azure DevOps, tiện ích cho phép tải lên các báo cáo Allure, vì vào thời điểm đó, chúng tôi đã chuyển đổi sang các đại lý của riêng mình và tuân thủ ý tưởng để mọi thứ "tự hoạt động" "máy móc.

Về lưu trữ, chúng tôi đã thử nghiệm ghi vào tài khoản lưu trữ Azure, cụ thể là tải lên Chia sẻ tệp, Blob và Blob bằng tiện ích azcopy.

Kết quả thay đổi đáng kể. Khi sử dụng lệnh cho File Share az lưu trữ tải lên tệp lưu trữ, tốc độ ghi cho thử nghiệm của chúng tôi là hơn một giờ:

Khi sử dụng Blob Storage bằng lệnh az storage blob upload-batch, hiệu suất được cải thiện gấp sáu lần, mất khoảng 11 phút:

Kết quả nhanh nhất là bằng công cụ azcopy:

Mặc dù sử dụng tính năng tích hợp sẵn của azcopy trong quy trình phát hành nhưng nó không tương thích với các máy Linux. Tuy nhiên, bằng cách sử dụng công việc Azure CLI và cài đặt tiện ích này trên tác nhân, lệnh có thể được sử dụng một cách tự tin:

sao chép azcopy 'NGUỒN' 'ĐIỂM' --recursive=true

Nhờ phát hiện ra hình ảnh Allure Docker từ sâu trong mạng, chúng tôi đã có thể sửa đổi sơ đồ lưu trữ và hiển thị các báo cáo. Việc truy cập dữ liệu hiện được bảo vệ bằng mật khẩu, đồng thời việc tạo và xử lý báo cáo vẫn diễn ra nhanh chóng. Hơn nữa, từ góc độ của người dùng (người thử nghiệm), những thay đổi là rất nhỏ. Giải pháp hoạt động độc lập với các chương trình khác, nhờ một tác nhân riêng biệt trong cụm và không thể ảnh hưởng đến các quá trình phát triển khác. Hiệu quả chi phí của giải pháp này tương đương với hiệu quả của một tác nhân tự lưu trữ riêng biệt ($15, miễn là nó bị cô lập), rẻ hơn nhiều so với các giải pháp thay thế hiện có. Ví dụ: qameta.io được xem xét trước đây, trong đó giá cho một người dùng là 30 USD/tháng.

Viết bởi Dmitrijs Gusarovs, Kỹ sư DevOps cấp trung tại Social Discovery Group.