Vậy, đúng mực thì DevSecOps có nghĩa là gì ? Điều tiên phong ( hoàn toàn có thể rõ ràng ) bạn cần biết chính là ” Sec ” trong DevSecOps là viết tắt của từ Security – bảo mật thông tin .
Đối với nhiều tổ chức triển khai, việc triển khai một tư duy DevOps gồm có ” thu hẹp khoảng cách ” – hoặc ” xóa bỏ những silo trung gian ” – trong những nhóm tăng trưởng ứng dụng và hoạt động giải trí công nghệ thông tin, thường với tiềm năng hoàn toàn có thể phát hành ứng dụng nhanh hơn và không thay đổi hơn .

DevSecOps, sau đó, là một phần mở rộng của tư duy DevOps và thường được trình bày với khẩu hiệu ” dịch chuyển bảo mật lên sớm hơn” trong vòng đời phát triển phần mềm (SDLC – software development lifecycle), thay vì xử lý các đánh giá/kiểm tra bảo mật ở cuối chu trình, khi bất kỳ phát hiện nào cần xử lý sẽ gây khó khăn và tốn kém hơn để thực hiện.

Trên thực tiễn, nguyên tắc đằng sau DevSecOps – liên tục đẩy chất lượng đến gần nguồn hơn – là nguyên tắc chính của The Second Way of DevOps ( phản hồi ) như được tranh luận trong Cẩm nang DevOps :
” Trong những mạng lưới hệ thống phức tạp, việc thêm nhiều bước kiểm tra và quy trình tiến độ phê duyệt thực sự làm tăng năng lực thất bại trong tương lai. Hiệu quả của những quá trình phê duyệt giảm xuống khi những quyết định hành động bị đẩy xa khỏi nơi việc làm được thực thi. Làm như vậy không chỉ làm giảm chất lượng của những quyết định hành động, mà cũng làm tăng thời hạn chu kỳ luân hồi, do đó làm giảm sức mạnh của sự phản hồi giữa nguyên do và hiệu quả và giảm năng lực học hỏi từ những thành công xuất sắc và thất bại ” .
W. Edwards Deming, một kỹ sư, giáo sư thống kê và tư vấn quản trị đã giúp phát động Phong trào Chất lượng Toàn diện ở Hoa Kỳ, đưa ra ý tưởng sáng tạo tựa như ( sớm hơn nhiều ) trong phần thứ ba ( trong tổng số 14 ) những nguyên tắc quản trị chính để quy đổi hiệu suất cao kinh doanh thương mại :
” Dễ dàng phụ thuộc vào vào kiểm tra để đạt được chất lượng. Loại bỏ nhu yếu kiểm tra lớn bằng cách thiết kế xây dựng chất lượng vào mẫu sản phẩm ngay từ đầu ” .

Nguyên tắc không nhất thiết phải thực hành bình đẳng

Những nguyên tắc này không mới và về triết lý có vẻ như khá đơn thuần, nhưng thực sự là trong thực tiễn, nhiều tổ chức triển khai không quản lý và vận hành theo cách này .
Nếu một tổ chức triển khai ưu tiên bảo mật thông tin, điều đó thường nhằm mục đích đạt được những tiêu chuẩn tối thiểu cho một số ít loại tuân thủ, thường là với một nhóm bảo mật thông tin được bảo vệ .
Trong bài viết DZone của mình : ” 10 lời khuyên để tích hợp bảo mật thông tin vào DevOps “, Gene Kim đã miêu tả thử thách này :
” Tỷ lệ kỹ sư tăng trưởng, quản lý và vận hành và Infosec ( An toàn thông tin ) trong một tổ chức triển khai công nghệ tiên tiến nổi bật là 100 : 10 : 1. Khi Infosec trở nên tiêu biểu vượt trội mà không tự động hóa và tích hợp bảo mật thông tin thông tin vào việc làm hàng ngày của Dev và Ops, Infosec chỉ hoàn toàn có thể tuân thủ kiểm tra, và điều này trái ngược lại với kỹ thuật bảo mật thông tin ” .
Một ví dụ nổi bật của ngữ cảnh này được minh họa trong “ Dự án Phượng hoàng : Câu chuyện về Công nghệ thông tin, DevOps và Giúp bạn giành thắng lợi trong kinh doanh thương mại ”, nơi nhân vật Giám đốc công nghệ thông tin ( CISO ), John, đi qua một cuộc khủng hoảng cục bộ hiện hữu khi công ty của anh ta vượt qua cuộc truy thuế kiểm toán SOX-404 mà không cần phải phụ thuộc vào vào những giải pháp trấn áp bảo mật thông tin nặng nề của mình .

Sau một thời gian khi nhận thấy tất cả công việc khó khăn của mình không thực sự tăng thêm giá trị cho công ty, CISO John “trỗi dậy từ đống tro tàn”. Anh bắt đầu tìm hiểu làm thế nào vai trò của mình có thể giúp công ty đạt được mục tiêu doanh nghiệp, làm việc hợp tác hơn với các bộ phận phát triển phần mềm và hoạt động công nghệ thông tin để hiểu cách anh ấy có thể giúp công việc của họ trở nên dễ dàng hơn. Chẳng bao lâu, bộ ba Dev, Ops và Infecec bắt đầu làm việc cùng nhau để giải quyết các mục tiêu kinh doanh chung đó, và trở nên linh hoạt hơn trong các quá trình, tăng thêm tự động hóa để giảm thiểu công việc và rủi ro bảo mật bất cứ khi nào có thể.

Sự thay đổi văn hóa trong cả hai hướng

Trong một cuộc phỏng vấn với Computer Business Review, Giám đốc công nghệ tiên tiến của Sonatype, Brian Fox, đã san sẻ tâm lý của mình về sự biến hóa đang diễn ra trong khoảng trống DevOps và DevSecOps : ” Những gì tất cả chúng ta thấy trên thị trường chính là : thử thách lớn nhất của người mua ngày này, thường là sự đổi khác văn hóa truyền thống cần có để khiến toàn bộ những chủ sở hữu quy trình tiến độ phải tâm lý cởi mở hơn, vượt ra ngoài những tiến trình thừa kế mà họ tìm thấy. ”
Một trong những người sáng lập DevSecOps, Shannon Lietz của Intuit, cũng lặp lại quan điểm đó trong một bài đăng trên blog What is DevSecOps ? trên devsecops.org, nêu rõ ” … với sự đổi khác đang diễn ra của DevOps, bảo mật thông tin truyền thống cuội nguồn không còn là một lựa chọn nữa. ”
Lietz cho biết : ” Mục đích của DevSecOps là thiết kế xây dựng trên tâm lý rằng ‘ mọi người đều có nghĩa vụ và trách nhiệm bảo mật thông tin ‘, với tiềm năng phân phối những quyết định hành động bảo mật thông tin một cách bảo đảm an toàn, với vận tốc và quy mô, để những người nắm giữ vị trí cao nhất mà không phải hy sinh sự bảo đảm an toàn thiết yếu ” .
Khi bạn nghĩ về DevSecOps như một môn học hợp tác, thành phần quan trọng cho cách tiếp cận thành công xuất sắc thường dẫn đến sự biến hóa trong tư duy văn hóa truyền thống của tổ chức triển khai khi bạn chuyển hướng .
Các tác giả của Cẩm nang DevOps đều chấp thuận đồng ý với quan điểm trên :
” Bằng cách này, chúng tôi thực sự làm cho chất lượng trở thành nghĩa vụ và trách nhiệm của mọi người, thay vì đó là nghĩa vụ và trách nhiệm duy nhất của một bộ phận riêng không liên quan gì đến nhau. Bảo mật thông tin không chỉ là việc làm của đội ngũ Bảo mật thông tin, giống như sự sẵn có không chỉ là việc làm của đội ngũ hoạt động giải trí ” .
Tại Sonatype, cách tiếp cận với DevSecOps gồm có ” thiết kế xây dựng chất lượng “, bằng cách tích hợp những giải pháp bảo mật thông tin vào tổng thể những quá trình của đường ống DevOps – từ trên xuống dưới, từ lựa chọn thành phần nguồn mở bắt đầu đến kiến thiết xây dựng, dàn dựng và phát hành ứng dụng của bạn .
Khi bạn tích hợp bảo mật thông tin vào toàn bộ những quy trình tiến độ của vòng đời tăng trưởng ứng dụng, bạn cũng đang làm những việc làm gồm có :

• Quét và đánh giá các rủi ro thành phần nguồn mở trong cả các ứng dụng cũ và hiện có;
• Ngăn chặn các thành phần OSS (Hệ thống hỗ trợ vận hành – Operating Support System) “xấu” không xâm nhập vào hệ sinh thái của bạn ngay từ đầu;
• Liên tục theo dõi tất cả các ứng dụng trong sản xuất, tự động cảnh báo cho các nhóm phát triển khi có lỗ hổng phát sinh ảnh hưởng đến ứng dụng của họ.

Các chuyên gia đã đề cập đến một đoạn trích từ Tuyên ngôn DevSecOps từ devsecops.org, là trung tâm của nhiệm vụ của các chuyên gia tại Sonatype:

” Bằng cách tăng trưởng bảo mật thông tin dưới dạng mã, những chuyên viên sẽ cố gắng nỗ lực tạo ra những mẫu sản phẩm và dịch vụ tuyệt vời, phân phối thông tin nâng cao, trực tiếp cho những nhà tăng trưởng, và thường lặp đi lặp lại để luôn đưa ra câu vấn đáp tốt nhất trước khi tiến hành. Các chuyên viên sẽ quản lý và vận hành như những nhà tăng trưởng, nhằm mục đích bảo vệ sự sẵn có của bảo mật thông tin và tuân thủ, để chuẩn bị sẵn sàng sử dụng như những dịch vụ. Các chuyên viên sẽ mở khóa và bỏ chặn những đường dẫn mới, để giúp những chuyên viên khác thấy ý tưởng sáng tạo của họ trở thành hiện thực ” .
Bài viết này bắt đầu được xuất bản dưới dạng Hướng dẫn Sonatype, một phần của Cộng đồng Sonatype. Cộng đồng Sonatype là nơi bạn hoàn toàn có thể đặt câu hỏi cho những người dùng Nexus khác và nhóm Sonatype. Nó cũng phân phối nội dung và lộ trình học tập từ một nhóm những chuyên viên, giúp việc sử dụng Nexus trở nên thuận tiện hơn .

Source: http://139.180.218.5
Category: Thuật ngữ đời thường