Giới thiệu cơ bản về DevSecOps (Phần 2)

[Sugi_b3o]

Ngày nay, với việc công nghệ đang thay đổi theo từng ngày, DevOps được triển khai rộng rãi và phổ biến vào các công ty công nghệ, đòi hỏi môi trường cho các sản phẩm Production cũng thay đổi với tốc độ chóng mặt. Thời gian để cung cấp là tính năng đóng vai trò rất quan trọng trong quá trình này, vì thế câu hỏi được đưa ra cho các Chuyên gia bảo mật là "Làm cách nào để tôi đảm bảo an toàn cho quy trình này?" hoặc "Các sản phẩm có được phát hành ra của của chúng tôi được bảo mật ở mức độ nào?".

Để trả lời cho vấn đề này, đòi hỏi chúng ta phải tích hợp Security vào toàn bộ chu trình DevOps để thử nghiệm, đánh giá toàn bộ các bước Security một cách tự động. Vì vậy, việc đưa văn hóa DevSecOps giúp chúng ta đảm bảo chiến lược shift-left được đề ra trong quá trình hoàn thiện vòng đời của sản phẩm.

Vậy chiến lược bảo mật Shift-left là gì?​

Ta có thể hiểu một cách đơn đơn giản, chiến lược bảo mật shift-left là một cách hoặc giải pháp để nhúng bảo mật như một phần của quá trình phát triển sản phẩm của chúng ta và được quy hoạch các chốt chặn bảo mật từ các bước khởi đầu của ứng dụng hoặc thiết kế hệ thống. Shannon Lietz, người sáng lập quỹ DevSecOps, cho biết: Mục đích và ý định của DevSecOps là xây dựng trên suy nghĩ rằng 'mọi người đều có trách nhiệm về bảo mật' với mục tiêu chia sẻ phân tán các chốt kiểm tra bảo mật một cách tự động để đưa ra các quyết định bảo mật với mức độ an toàn hợp lý.

Xây dựng văn hóa DevSecOps​

Như bạn đã nghe trước khi chúng tôi muốn nói về bảo mật Shift-left. Điều đó có nghĩa là chúng ta nên xem xét bảo mật từ thiết kế mà mục tiêu là thực hiện việc bảo mật sớm hơn trong quá trình phát triển.

Giả sử rằng bạn đang làm việc trong một nhóm DevOps và bạn đang thực hiện kiểm tra bảo mật theo truyền thống. Quy trình là sản phẩm phải đạt tất cả các bài kiểm tra QA và nhóm develop phải thực hiện fix các bug sau khi test QA thì quá trình kiểm thử bảo mật được diễn ra, sau khi quá trình bảo mật kết thúc, QA phải thực hiện test lại 1 lần nữa, và retest từ phía bảo mật lại diễn ra. Điều đó làm mất thời gian, chi phí và có thể phải bị cuốn sâu vào vòng lặp, thậm chí phải hy sinh một số giai đoạn để đáp ứng các nhu cầu về mặt Business.

Giải pháp là thực hiện theo chiến lược Shift-Left để có các chốt chặn bảo mật trước ngay từ khi khơi động, để giảm chi phí và thời gian thực hiện ở các giai đoạn sau, dưới đây là hình ảnh khác biệt khi thực hiện DevOps và DevSecOps

Quyền riêng tư​

Quyền riêng tư đã trở thành một chủ đề chính cho các công ty thuộc mọi quy mô, kể từ khi các thông tin các nhân được định nghĩa theo các chuẩn Quốc Tế như: GDPR (Quy định bảo vệ dữ liệu chung của châu Âu), CCPA (Đạo luật bảo mật người tiêu dùng California), LGPD - Lei Geral de Proteção de Dados của Brazil và các luật và quy định khác đang được thực thi trên toàn Thế Giới. Các ứng dụng phải xử lý một khối lượng lớn PII (thông tin nhận dạng cá nhân) buộc chúng ta điều chỉnh, thiết kế quy trình DevSecOps để không bị vi phạm chính sách Quyền Riêng Tư trong toàn bộ vòng đời sản phẩm

Chiến lược kiểm thử phần mềm​

Các chiến lược kiểm thử phần mềm

1 Positive Testing​

Thực hiện trong điều kiện bình thường và đầu vào, mọi thứ sẽ hoạt động như mong đợi. Nó được thực hiện với giả định rằng chỉ những điều hợp lệ và có liên quan sẽ xảy ra: tập dữ liệu và tất cả các chức năng khác sẽ như mong đợi.

2 Negative Tesing​

Thực hiện kiểm tra hành vi hệ thống trong điều kiện bất ngờ. Negative Tesing đóng một vai trò quan trọng trong việc phát triển phần mềm hiệu suất cao: nó kiểm tra hành vi phần mềm trong điều kiện và đầu vào bất ngờ.

Các phương pháp kiểm thử phần mềm​

1 Static Testing​

Static Testing kiểm tra lỗi phần mềm mà không thực thi mã ứng dụng. Quá trình này, được thực hiện trong giai đoạn đầu của sự phát triển để tránh lỗi, vì nó dễ dàng hơn để tìm mã nguồn có lỗi và nó có thể được khắc phục dễ dàng. Một số vấn đề không thể tìm thấy khi sử dụng Dynamic Testing, có thể dễ dàng tìm thấy bằng Static Testing. Những vấn đề như vậy bao gồm thông tin đăng nhập sử dụng mã hóa đã lỗi thời, không sử dụng các thuật toán mã hóa, các hàm ngẫu nhiên có độ phức tạp yếu, v.v. Hầu hết các công cụ phân tích tĩnh có phạm vi thử nghiệm giới hạn ở một thành phần của mã nguồn.

2 Dynamic Testing​

Dynamic Testing phân tích hành vi của mã ứng dụng tại thời gian chạy. Công cụ gửi các yêu cầu được viết theo kịch bản đặc biệt để khai thác ứng dụng mục tiêu. Các thông số yêu cầu liên tục được sửa đổi trong quá trình thử nghiệm để kiểm thử và tìm ra một loạt các lỗ hổng. Dựa trên phản hồi của ứng dụng, công cụ sau đó có thể xác định các lỗ hổng tiềm ẩn và báo cáo lại. Một số vấn đề không thể tìm thấy bằng phân tích tĩnh nhưng dễ dàng được phát hiện bằng phân tích động như các lỗ hổng phía khách hàng như xác thực * vấn đề phiên làm việc, dữ liệu nhạy cảm được gửi bằng văn bản thuần túy, v.v. Các công cụ phân tích động có khả năng kiểm tra toàn bộ luồng ứng dụng (nhiều thành phần cùng một lúc).

3 Interactive analysis​

Còn được gọi là Interactive Application Security Testig (IAST) giám sát ứng dụng trong khi các hệ thống khác tương tác với nó và quan sát các lỗ hổng. Các cảm biến có thể nhìn thấy toàn bộ luồng từ yêu cầu HTTP xuống mã đã thực thi, theo dõi dữ liệu thông qua ứng dụng. Tương tự như phân tích tĩnh, nó có thể kiểm tra một thành phần tại một thời điểm, nhưng không phải là đa thành phần cùng một lúc.