Nền tảng AI
DevSecOps là gì? Nguyên tắc, Quy trình và Thực hành tốt nhất
Thêm Unite.AI vào các nguồn ưu tiên của bạn trên Google
DevSecOps tích hợp các thực tiễn bảo mật vào việc lập kế hoạch, phát triển, giao hàng và vận hành phần mềm. Mục tiêu không phải là thêm một cổng bảo mật cuối cùng vào DevOps; mà là làm cho các thiết lập mặc định an toàn, phản hồi nhanh, bằng chứng và trách nhiệm chia sẻ trở thành một phần của hệ thống giao hàng.
Công cụ chỉ là một lớp. DevSecOps hiệu quả còn cần các yêu cầu dựa trên thông tin đe dọa, đội ngũ được đào tạo, một danh mục phần mềm được duy trì, hạ tầng xây dựng được bảo vệ, đánh giá dựa trên rủi ro, phản hồi lỗ hổng và các chỉ số liên kết với kết quả thực tế.
Những điểm chính
- Xác định các yêu cầu bảo mật và giả định về đe dọa trước khi triển khai.
- Cung cấp cho nhà phát triển phản hồi nhanh, có thể hành động ngay trong các công cụ họ đã sử dụng.
- Bảo vệ mã nguồn, phụ thuộc, bản dựng, artefact, thông tin đăng nhập và danh tính triển khai như một chuỗi cung ứng duy nhất.
- Sử dụng tự động hoá để thực thi chính sách một cách nhất quán, đồng thời có sự xem xét của chuyên gia cho các rủi ro phụ thuộc vào ngữ cảnh.
Đẩy sang trái và vận hành sang phải
Các đánh giá thiết kế sớm, mô hình đe dọa, tiêu chuẩn mã hóa an toàn và các bài kiểm tra giảm thiểu công việc sửa chữa tốn kém. Điều này thường được gọi là đẩy sang trái. Vận hành sang phải bổ sung cho nó bằng cấu hình sản xuất, thu thập dữ liệu, bảo vệ thời gian chạy, phản hồi sự cố và học hỏi từ các thất bại thực tế.
Công việc bảo mật nên tỷ lệ với mức độ rủi ro. Dịch vụ xác thực hướng ra internet cần các kiểm soát khác so với một trang tĩnh nội bộ. Các chuyên gia An ninh mạng giúp các đội hiểu các phát hiện thay vì biến mọi cảnh báo của công cụ quét thành nhiệm vụ có độ ưu tiên bằng nhau.
Một pipeline giao hàng an toàn
Một pipeline tiêu chuẩn kiểm tra các thay đổi mã nguồn, bí mật, phụ thuộc, mã hạ tầng, container và hành vi ứng dụng. Các bản dựng nên có khả năng tái tạo khi khả thi, artefact được ký, nguồn gốc được ghi lại và môi trường triển khai được tách biệt bằng các danh tính có phạm vi.
Các cổng tự động cần có các ngoại lệ được ghi chép và thời hạn. Việc chặn dựa trên các quy tắc ồn ào dẫn đến các giải pháp tạm thời; bỏ qua các phát hiện tạo ra nợ ẩn. Điều chỉnh chính sách dựa trên khả năng khai thác, mức độ phơi bày, giá trị tài sản và các biện pháp giảm thiểu sẵn có.
Kiểm soát chuỗi cung ứng phần mềm
Duy trì một danh mục các thành phần trực tiếp và gián tiếp, giám sát các khuyến cáo, xác minh nguồn, cố định các phụ thuộc quan trọng và tạo ra một bảng kê phần mềm (SBOM) khi nó hỗ trợ nhu cầu của khách hàng hoặc phản hồi. Bảo vệ dịch vụ xây dựng vì nó có thể thay đổi mọi artefact hạ nguồn.
Mã của bên thứ ba không chuyển giao trách nhiệm. Các đội cần một quy trình để đánh giá, cập nhật, cô lập hoặc thay thế các phụ thuộc. Hoạt động IT và phát triển nên chia sẻ quyền sở hữu đối với các phiên bản được hỗ trợ và các bản vá khẩn cấp.
Con người, bằng chứng và cải tiến
Các chuyên gia bảo mật có thể kết nối chuyên môn trung tâm với ngữ cảnh sản phẩm, nhưng họ cần thời gian và thẩm quyền. Đào tạo nên sử dụng công nghệ thực tế của tổ chức và lịch sử sự cố. Các nhà điều hành phải tài trợ cho việc khắc phục thay vì chỉ đo lường các đội bằng tốc độ phát hành.
Theo dõi thời gian dẫn đầu cho các bản sửa lỗi quan trọng, tần suất tái diễn, lỗ hổng đã thoát, mức độ bao phủ các thành phần có rủi ro cao, tuổi của ngoại lệ, tính toàn vẹn của bản dựng và ảnh hưởng của sự cố. Chỉ đếm số lượng công cụ quét không phản ánh phần mềm an toàn hơn.
Mô hình đe dọa và thiết kế an toàn
Mô hình đe dọa xác định tài sản, ranh giới tin cậy, mục tiêu của kẻ tấn công, các trường hợp lạm dụng và các biện pháp giảm thiểu trước khi mã hoàn thiện. Sơ đồ luồng dữ liệu cho thấy nơi đầu vào người dùng, thông tin đăng nhập, dịch vụ bên thứ ba, hệ thống xây dựng và dữ liệu sản xuất vượt qua các ranh giới. Kết quả nên trở thành các mục trong backlog và các bài kiểm tra, không phải là một tài liệu được lưu trữ.
Thiết kế an toàn bao gồm danh tính mạnh, quyền tối thiểu, các thiết lập mặc định an toàn, kiểm tra đầu vào và đầu ra, mã hoá, cô lập, giới hạn tần suất và khả năng phục hồi khi lỗi. Loại bỏ các loại lỗi thông qua các khung và các primitive nền tảng thay vì yêu cầu mỗi nhà phát triển nhớ cùng một quy tắc cấp thấp.
Đối với phần mềm hỗ trợ AI, cần bao gồm tấn công chèn lời nhắc, đầu ra mô hình không tin cậy, nhiễm độc dữ liệu, nguồn gốc mô hình và bộ dữ liệu, sử dụng công cụ không an toàn, tiết lộ thông tin nhạy cảm và tự động hoá quá mức. Mô hình là một phụ thuộc trong bề mặt tấn công rộng hơn; quyền truy cập ứng dụng phải vẫn giữ tính quyền lực.
Kiểm soát pipeline và bằng chứng
Bảo vệ các kho mã nguồn bằng các thay đổi đã được xem xét, kiểm soát nhánh, các commit được ký khi cần thiết và giám sát quyền truy cập của quản trị viên. Các worker xây dựng nên tạm thời hoặc được cứng hoá, cô lập khỏi thông tin đăng nhập sản xuất và chỉ có thể tải các phụ thuộc đã được phê duyệt. Tách biệt quyền thay đổi mã nguồn với quyền triển khai.
Phân tích tĩnh kiểm tra mã mà không chạy nó; kiểm thử động quan sát một ứng dụng đang chạy; phân tích thành phần phần mềm theo dõi các phụ thuộc; các công cụ quét hạ tầng và container kiểm tra artefact triển khai. Các phát hiện nên bao gồm vị trí, quy tắc, mức độ nghiêm trọng, độ tin cậy, người chịu trách nhiệm và lộ trình khắc phục. Việc bỏ qua cần có lý do và thời hạn.
Nguồn gốc của artefact ghi lại cách thức, nơi và từ những đầu vào nào phần mềm được xây dựng. Chữ ký và xác nhận giúp chính sách triển khai xác thực nguồn gốc mong đợi. Chúng không chứng minh mã là an toàn, vì vậy nguồn gốc bổ sung cho việc kiểm thử, đánh giá và các kiểm soát thời gian chạy.
Phản hồi lỗ hổng và sự cố
Quy trình phản hồi lỗ hổng phải nhận các tiết lộ, phân loại mức độ phơi bày, xác định các phiên bản bị ảnh hưởng, tạo và kiểm thử các bản sửa, phối hợp phát hành và giao tiếp với khách hàng. SBOM có thể tăng tốc việc xác định phạm vi nhưng chỉ khi danh tính thành phần và các phiên bản đã triển khai là chính xác.
Các tín hiệu bảo mật trong môi trường sản xuất nên kết nối với quyền sở hữu dịch vụ và tự động hoá sự cố. Bảo quản bằng chứng, xoay vòng các thông tin đăng nhập bị xâm phạm, vá hoặc giảm thiểu, xác thực quá trình phục hồi và tìm kiếm các điểm yếu liên quan. Các hành động sau sự cố nên thay đổi thiết kế, kiểm thử, thiết lập mặc định và đào tạo thay vì chỉ đổ lỗi cho người đã đưa ra lỗi cuối cùng.
Các nhà điều hành cần các chỉ số rủi ro và kết quả: thời gian phơi bày quan trọng, tần suất tái diễn, tỷ lệ phần trăm bản dựng được bảo vệ, trạng thái hỗ trợ phụ thuộc, độ tin cậy của việc khắc phục và tác động tới khách hàng. Các mục tiêu thưởng cho việc không báo cáo lỗ hổng tạo ra sự che giấu; một chương trình lành mạnh sẽ nhanh chóng phát hiện, sửa chữa và học hỏi.
Ví dụ thực tế: bảo mật đường truyền dịch vụ container hoá
Một nhà phát triển bắt đầu từ mẫu kho đã được phê duyệt với bảo vệ nhánh, chính sách phụ thuộc, quét bí mật và một hình ảnh cơ bản tối thiểu. Các pull request chạy các bài kiểm tra, phân tích tĩnh, kiểm tra hạ tầng và phân tích thành phần phần mềm. Quá trình xây dựng diễn ra trên một runner cô lập, tạo ra một artefact bất biến, ký nó, tạo SBOM và xác nhận nguồn gốc, và chỉ đẩy lên một registry được kiểm soát. Các bí mật được tiêm vào thời gian chạy, không được sao chép vào mã, hình ảnh hoặc nhật ký CI.
Chính sách nhập khẩu xác minh chữ ký, nguồn gốc, registry cho phép, ngoại lệ lỗ hổng, cài đặt quyền tối thiểu và các ràng buộc môi trường trước khi triển khai. Các kiểm soát thời gian chạy hạn chế truy cập mạng và hệ thống tệp, trong khi khả năng quan sát liên kết các thay đổi với hành vi dịch vụ. Một lỗ hổng nghiêm trọng kích hoạt quá trình phân loại dựa trên khả năng tiếp cận, khai thác, phơi bày và các kiểm soát bù đắp — không phải là gián đoạn sản xuất tự động chỉ dựa trên điểm số của công cụ quét. Các thay đổi khẩn cấp sử dụng phê duyệt có thời hạn và được xem xét sau đó.
Đo lường thời gian khắc phục, mức độ phơi bày lỗ hổng, các sự cố bí mật, việc bỏ qua chính sách, độ mới của phụ thuộc, mức độ bao phủ artefact đã ký và thời gian chờ của nhà phát triển. Kiểm thử pipeline đối với một phụ thuộc bị xâm phạm, thông tin đăng nhập bị đánh cắp, artefact bị giả mạo và công cụ quét không khả dụng. DevSecOps thành công khi giao hàng an toàn có thể lặp lại và đủ nhanh để sử dụng; một tập hợp các công cụ chặn mà không có quyền sở hữu, mô hình đe dọa và phản hồi chỉ chuyển rủi ro sang các ngoại lệ và quy trình bóng tối.
Quản trị phát hành nên xác định ai có thể phê duyệt các ngoại lệ rủi ro, bằng chứng nào cần thiết, thời gian ngoại lệ kéo dài bao lâu và cách thu hồi chúng. Giữ các danh tính phát triển, xây dựng và sản xuất riêng biệt, xoay vòng tài liệu ký và kiểm toán các thay đổi pipeline có đặc quyền. Sao lưu cấu hình quan trọng và xác thực việc phục hồi hệ thống giao hàng. Một mặt phẳng điều khiển CI/CD bị xâm phạm có thể phân phối các artefact độc hại đáng tin cậy nhanh hơn so với một cuộc xâm nhập máy chủ thông thường, vì vậy nó phải nằm trong mô hình đe dọa và kế hoạch sự cố.
Danh sách kiểm tra triển khai thực tế
Biến ý tưởng thành một quy trình có giới hạn, có thể kiểm thử: lập kế hoạch → thiết kế → mã hoá → xây dựng → triển khai → vận hành. Đặt tên cho người chịu trách nhiệm, ghi chép dữ liệu và các phụ thuộc, thiết lập một chuẩn cơ bản đơn giản, đặt tiêu chí chấp nhận và dừng, kiểm thử các lỗi đại diện, và xác định việc giám sát, khôi phục và đánh giá trước khi mở rộng phạm vi. Ghi lại các phiên bản và giả định để đội khác có thể tái tạo kết quả và hiểu những gì đã thay đổi.
Trước khi ra mắt, thực hiện một cuộc đánh giá sẵn sàng được ghi chép với những người xây dựng, vận hành, bảo mật và bị ảnh hưởng bởi hệ thống. Kiểm thử các trường hợp bình thường, điều kiện biên, lỗi phụ thuộc và lạm dụng; bảo quản bằng chứng và các rủi ro chưa giải quyết. Xác định ai có thể phê duyệt phát hành, thay đổi ngưỡng, ghi đè đầu ra hoặc dừng hoạt động. Xem lại quyết định sau khi dữ liệu thực tế đến, vì một dự án thí điểm thành công về mặt kỹ thuật không đảm bảo hiệu suất đáng tin cậy ở quy mô rộng hơn.
- NGƯỜI DÙNG: sở hữu chung với sự hỗ trợ của chuyên gia.
- QUY TRÌNH: kiểm tra nhanh và artefact có thể xác minh.
- HOẠT ĐỘNG: giám sát, phản hồi, vá và học hỏi.
Câu hỏi thường gặp
DevSecOps là sản phẩm hay chuỗi công cụ?
Không. Các công cụ hỗ trợ nó, nhưng DevSecOps là một cách tiếp cận vận hành kết hợp con người, quy trình, công nghệ, bằng chứng và trách nhiệm trong suốt vòng đời phần mềm.
Việc đẩy an ninh sang trái có thay thế bảo mật thời gian chạy không?
Không. Các kiểm soát thiết kế và xây dựng ngăn ngừa nhiều vấn đề; giám sát sản xuất, phản hồi, vá và phục hồi vẫn là thiết yếu.
Tài liệu tham khảo chính
