-
30/08/2016
-
317
-
446 bài viết
Giới thiệu cơ bản về DevSecOps (Phần 1)
Bài viết hôm nay mình sẽ giới thiệu về DevSecOps, tính bảo mật trong quy trình phát triển phần mềm áp dụng mô hình DevOps cùng một số công cụ và best practices, cũng như để bạn đọc nắm bắt được xu thế Shift-left của Security áp dụng vào DevOps như thế nào.
SAST có thể được xem như quá trình test mũ trắng hay test hộp trắng, nơi mà người test biết thông tin về hệ thống và phần mềm được test, bao gồm cả kiến trúc hệ thống, mã nguồn,… Những công cụ SAST kiểm tra mã nguồn để dò tìm và báo cáo những điểm yếu có thể dẫn đến những lỗ hổng an ninh. Việc phân tích mã nguồn có thể được thực hiện trên một mã nguồn chưa được dịch để kiểm tra những rủi ro như những lỗi số, xác thực đầu vào, những điều kiện biên, những con trỏ, tham chiếu, và nhiều hơn thế. Những bộ phân tích nhị phân và mã nguồn làm những công việc tương tự đối với những mã nguồn đã được build và dịch. Một vài công cụ chỉ chạy trên mã nguồn chưa được dịch, vài công cụ chỉ chạy trên mã nguồn đã dịch và một số khác có thể chạy trên cả hai.
SCA (Software Composition Analysis)
Những công cụ SCA kiểm tra phần mềm để xác định nguồn gốc của tất cả các thành phần và những thư viện bên trong phần mềm. Những công cụ này có hiệu quả cao trong việc chỉ ra và tìm kiếm các lỗ hổng trong các thành phần chung và phổ biến và những thành phần mã nguồn mở riêng biệt. Tuy vậy, chúng không dò tìm được các thành phần được phát triển và tùy biến theo cách riêng. Các công cụ SCA làm việc dựa trên việc so sánh những module đã được biết từ trước được tìm thấy trong mã nguồn với các lỗ hổng đã được biết từ trước. Các công cụ SCA cũng tìm kiếm các thành phần đã được biết từ trước và những lỗ hổng đã được tài liệu hóa và đưa ra cảnh báo nếu có những thành phần lâu chưa được cập nhật bản vá hoặc có những bản vá mới cần cập nhật. Những công cụ SCA có thể chạy trên mã nguồn, mã byte, mã nhị phân, hoặc một vài sự kết hợp khác.
IAST (Interactive Application Security Testing)
Các công cụ IAST sử dụng kết hợp các kỹ thuật phân tích động và tĩnh. Chúng có thể test tất cả các lỗ hổng được biết đến trong mã nguồn mà có thể thực sự bị khai thác trong khi chạy ứng dụng. Các công cụ IAST sử dụng kiến thức của luồng ứng dụng và luồng dữ liệu để sáng tạo các kịch bản tấn công nâng cao và sử dụng các kết quả phân tích động. Như một sự quét động được thực hiện, công cụ sẽ học những thứ của ứng dụng dựa trên cách nó đáp ứng với những testcase. Một vài ứng dụng sẽ sử dụng kiến thức này để sáng tạo thêm các testcase, cái mà sau đó sẽ lại cung cấp thêm hiểu biết để sáng tạo những testcase khác và tiếp tục như thế. Các công cụ IAST giúp làm giảm đáng kể số lượng lỗi, làm việc tốt với môi trường Algile và DevOps, nơi mà các công cụ DAST và SAST có thể sẽ tiêu tốn rất nhiều thời gian của chu kỳ phát triển.
DAST (Dynamic Application Security Test)
Đối lập với SAST, các công cụ DAST được coi như các công cụ test mũ đen hoặc hộp đen, nơi mà những người test không có hiểu biết về hệ thống. Họ dò tìm những lỗ hổng an ninh của một ứng dụng trong trạng thái chạy của nó. Những công cụ DAST chạy trên code đang hoạt động để dò tìm các vấn đề với các giao tiếp, những yêu cầu, những phản hồi, những script (ví dụ javascript), lỗ hổng dữ liệu, sự xác thực, và nhiều hơn thế. Các công cụ DAST sử dụng kỹ thuật fuzzing: Đưa những testcase được biết đến là không có giá trị và không được chờ đợi vào ứng dụng, thường là với một khối lượng lớn.
Chúng ta có thể tùy chỉnh các bước của quy trình theo Vòng đời phát triển phần mềm (SDLC) hoặc kiến trúc phần mềm và thêm tự động hóa dần dần. Ví dụ: chúng ta có thể chuyển từ SAST / DAST sang một bộ thử nghiệm thông thường với các biện pháp kiểm soát bảo mật tích hợp sẵn hoặc thêm một tập lệnh kiểm tra để tìm các phần phụ thuộc dễ bị tấn công đã công bố publics.
Bức tranh overview sau khi tích hợp Security vào DevOps
SecOps trong CI/CD là một chốt chặn quan trọng trong kiểm soát bảo mật, chất lượng của sản phẩm. Tuy nhiên, khi sử dụng các công cụ CI / CD một cách tự động hóa, các bạn phải biết rằng các công cụ này thường sẽ mở rộng phạm vi tấn công của bạn, vì vậy hãy đặt các biện pháp, tiêu chí để kiểm soát bảo mật đối với việc xây dựng, triển khai và tự động hóa quy trình phát triển phần mềm.
DevSecOps là gì ?
DevSecOps là thành quả của việc tích hợp Security vào DevOps bao gồm trong CI/CD được thiết kế vào quy trình phát triển phần mềm.Tại sao lại áp dụng Sec vào DevOps ?
OWASP Proactive Controls đã liệt kê 10 yêu cầu cẩn phải có trong bảo mật mà tất cả các nhà phát triển phải thực hiện trong khi thiết kế, kiến trúc, phát triển hoặc kiểm soát quy trình phát triển phần mềm:- C1: Define Security Requirements
- C2: Leverage Security Frameworks and Libraries
- C3: Secure Database Access
- C4: Encode and Escape Data
- C5: Validate All Inputs
- C6: Implement Digital Identity
- C7: Enforce Access Controls
- C8: Protect Data Everywhere
- C9: Implement Security Logging and Monitoring
- C10: Handle All Errors and Exceptions
Cần làm gì để áp dụng Security vào DevOps ?
Kiểm tra các thông tin đăng nhập (user/password, apikey, …) trong repo git
SAST (Static Application Security Test)SAST có thể được xem như quá trình test mũ trắng hay test hộp trắng, nơi mà người test biết thông tin về hệ thống và phần mềm được test, bao gồm cả kiến trúc hệ thống, mã nguồn,… Những công cụ SAST kiểm tra mã nguồn để dò tìm và báo cáo những điểm yếu có thể dẫn đến những lỗ hổng an ninh. Việc phân tích mã nguồn có thể được thực hiện trên một mã nguồn chưa được dịch để kiểm tra những rủi ro như những lỗi số, xác thực đầu vào, những điều kiện biên, những con trỏ, tham chiếu, và nhiều hơn thế. Những bộ phân tích nhị phân và mã nguồn làm những công việc tương tự đối với những mã nguồn đã được build và dịch. Một vài công cụ chỉ chạy trên mã nguồn chưa được dịch, vài công cụ chỉ chạy trên mã nguồn đã dịch và một số khác có thể chạy trên cả hai.
SCA (Software Composition Analysis)
Những công cụ SCA kiểm tra phần mềm để xác định nguồn gốc của tất cả các thành phần và những thư viện bên trong phần mềm. Những công cụ này có hiệu quả cao trong việc chỉ ra và tìm kiếm các lỗ hổng trong các thành phần chung và phổ biến và những thành phần mã nguồn mở riêng biệt. Tuy vậy, chúng không dò tìm được các thành phần được phát triển và tùy biến theo cách riêng. Các công cụ SCA làm việc dựa trên việc so sánh những module đã được biết từ trước được tìm thấy trong mã nguồn với các lỗ hổng đã được biết từ trước. Các công cụ SCA cũng tìm kiếm các thành phần đã được biết từ trước và những lỗ hổng đã được tài liệu hóa và đưa ra cảnh báo nếu có những thành phần lâu chưa được cập nhật bản vá hoặc có những bản vá mới cần cập nhật. Những công cụ SCA có thể chạy trên mã nguồn, mã byte, mã nhị phân, hoặc một vài sự kết hợp khác.
IAST (Interactive Application Security Testing)
Các công cụ IAST sử dụng kết hợp các kỹ thuật phân tích động và tĩnh. Chúng có thể test tất cả các lỗ hổng được biết đến trong mã nguồn mà có thể thực sự bị khai thác trong khi chạy ứng dụng. Các công cụ IAST sử dụng kiến thức của luồng ứng dụng và luồng dữ liệu để sáng tạo các kịch bản tấn công nâng cao và sử dụng các kết quả phân tích động. Như một sự quét động được thực hiện, công cụ sẽ học những thứ của ứng dụng dựa trên cách nó đáp ứng với những testcase. Một vài ứng dụng sẽ sử dụng kiến thức này để sáng tạo thêm các testcase, cái mà sau đó sẽ lại cung cấp thêm hiểu biết để sáng tạo những testcase khác và tiếp tục như thế. Các công cụ IAST giúp làm giảm đáng kể số lượng lỗi, làm việc tốt với môi trường Algile và DevOps, nơi mà các công cụ DAST và SAST có thể sẽ tiêu tốn rất nhiều thời gian của chu kỳ phát triển.
DAST (Dynamic Application Security Test)
Đối lập với SAST, các công cụ DAST được coi như các công cụ test mũ đen hoặc hộp đen, nơi mà những người test không có hiểu biết về hệ thống. Họ dò tìm những lỗ hổng an ninh của một ứng dụng trong trạng thái chạy của nó. Những công cụ DAST chạy trên code đang hoạt động để dò tìm các vấn đề với các giao tiếp, những yêu cầu, những phản hồi, những script (ví dụ javascript), lỗ hổng dữ liệu, sự xác thực, và nhiều hơn thế. Các công cụ DAST sử dụng kỹ thuật fuzzing: Đưa những testcase được biết đến là không có giá trị và không được chờ đợi vào ứng dụng, thường là với một khối lượng lớn.
Rà quét các lỗ hổng bảo mật hạ tầng
Rà quét lỗ hổng bảo mật hạ tầng là quá trình xác định các điểm yếu và lỗ hổng bảo mật đã được công bố public, tập lệnh cấu hình có trong hệ thống, network và phần mềm chạy trên các nền tảng hạ tầng như image, docker, k8s.Kiểm tra tính tuân thủ
Kiểm tra sự tuân thủ là quá trình xem xét và phân tích các kiểm soát đã thực hiện để kiểm tra xem các kiểm soát đã thực hiện và đầu ra của chúng có đáp ứng các yêu cầu bảo mật được nêu trong kế hoạch an toàn thông tin và kế hoạch xử lý rủi ro hay không.Chúng ta có thể tùy chỉnh các bước của quy trình theo Vòng đời phát triển phần mềm (SDLC) hoặc kiến trúc phần mềm và thêm tự động hóa dần dần. Ví dụ: chúng ta có thể chuyển từ SAST / DAST sang một bộ thử nghiệm thông thường với các biện pháp kiểm soát bảo mật tích hợp sẵn hoặc thêm một tập lệnh kiểm tra để tìm các phần phụ thuộc dễ bị tấn công đã công bố publics.
Bức tranh overview sau khi tích hợp Security vào DevOps
SecOps trong CI/CD là một chốt chặn quan trọng trong kiểm soát bảo mật, chất lượng của sản phẩm. Tuy nhiên, khi sử dụng các công cụ CI / CD một cách tự động hóa, các bạn phải biết rằng các công cụ này thường sẽ mở rộng phạm vi tấn công của bạn, vì vậy hãy đặt các biện pháp, tiêu chí để kiểm soát bảo mật đối với việc xây dựng, triển khai và tự động hóa quy trình phát triển phần mềm.
Chỉnh sửa lần cuối bởi người điều hành: