Những quy trình hoặc công cụ nào cho phép Phân chia nhiệm vụ khi các kỹ sư vừa triển khai vừa chạy mã?

Trong các môi trường được kiểm soát chặt chẽ, như lĩnh vực Dịch vụ Tài chính, Phân chia Nhiệm vụ là một cơ chế thiết yếu để tránh xung đột giữa các cá nhân có trách nhiệm phát triển và đặc quyền sản xuất.

Theo truyền thống, điều này có nghĩa là Nhà phát triển phát triển mã và sau đó chuyển giao cho Hoạt động, tuy nhiên, trong nhiều Mô hình hoạt động của DevOps, sự tách biệt giữa Phát triển và Hoạt động, ở mức tối thiểu, bị mờ:

• Trong Kỹ thuật Độ tin cậy Trang web của Google , hoặc SRE, thực tế có một chức năng SRE riêng trong Google, tuy nhiên, Nhà phát triển được đưa vào để ngăn chặn SRE trong thời gian tải hoạt động cao.

• Trong mô hình "Bạn xây dựng nó, bạn chạy nó" không có chức năng hoạt động riêng biệt.

Sau nhiều tháng đi sâu vào các nguyên nhân cốt lõi của cơ chế Phân chia Nhiệm vụ, dường như nó tồn tại chủ yếu để đáp ứng Sarbanes Oxley Phần 404 : Đánh giá Quản lý Kiểm soát Nội bộ:

(a) Quy tắc bắt buộc. Ủy ban sẽ quy định các quy tắc yêu cầu mỗi báo cáo hàng năm theo yêu cầu của phần 13 (a) hoặc 15 (d) của Đạo luật Giao dịch Chứng khoán năm 1934 để chứa một báo cáo kiểm soát nội bộ, trong đó--

(1) nêu trách nhiệm của ban quản lý trong việc thiết lập và duy trì một cấu trúc và quy trình kiểm soát nội bộ đầy đủ cho báo cáo tài chính; và

(2) có một đánh giá, kể từ cuối năm tài chính gần nhất của tổ chức phát hành, về hiệu quả của cấu trúc và quy trình kiểm soát nội bộ của tổ chức phát hành báo cáo tài chính.

(b) Đánh giá và báo cáo kiểm soát nội bộ. Về đánh giá kiểm soát nội bộ theo yêu cầu của tiểu mục (a), mỗi công ty kế toán công đã đăng ký chuẩn bị hoặc phát hành báo cáo kiểm toán cho tổ chức phát hành phải chứng thực và báo cáo về đánh giá của ban quản lý tổ chức phát hành. Một chứng thực được thực hiện theo tiểu mục này sẽ được thực hiện theo các tiêu chuẩn cho các cam kết chứng thực được ban hành hoặc thông qua bởi Hội đồng. Bất kỳ chứng thực như vậy sẽ không phải là chủ đề của một cam kết riêng biệt.

Dựa trên các ý kiến, điều quan trọng là gọi ra một vài giả định tôi đang thực hiện:

• Tôi chủ yếu xem xét các dịch vụ tài chính thị trường đại chúng, tức là khối lượng giao dịch cao nhưng giá trị tương đối thấp. Điều này sẽ trái ngược với các dịch vụ tài chính thương mại có hồ sơ giá trị giao dịch khác nhau.
• Việc cung cấp trực tuyến của một tổ chức tài chính sẽ được tạo thành từ nhiều thành phần có các cân nhắc rủi ro khác nhau:
  • Chuyển tiền - Chuyển tiền giữa các tài khoản hoặc chuyển giữa các tài khoản của các chủ sở hữu khác nhau. Một hoạt động phải xem xét các hoạt động phòng chống rửa tiền, chống gian lận và cấm vận của một số quốc gia.
  • Thu hút khách hàng - Ít "rủi ro" hơn vì nó có khối lượng giao dịch thấp so với Move Money nhưng vẫn cần xem xét.
  • Internet Banking - Bao gồm một loạt các dịch vụ với mức độ rủi ro khác nhau, Move Money sẽ được coi là một phần của điều này.
• Có thể hiểu một cách tiếp cận khác nhau có thể được thực hiện cho mỗi tùy thuộc vào rủi ro, tuy nhiên, vì lợi ích của việc đơn giản, tôi đang hướng tới một giải pháp áp dụng cho một số hoạt động rủi ro nhất.

TL; DR : Ban quản lý có trách nhiệm đảm bảo rằng các biện pháp kiểm soát nội bộ đầy đủ được thực hiện theo các quy định của Ủy ban Chứng khoán và Giao dịch .

Sarbanes Oxley 404 thường được thỏa mãn thông qua việc hoàn thành Đánh giá rủi ro từ trên xuống, một phần trong đó sẽ đánh giá rủi ro thông đồng và đưa ra các chiến lược giảm thiểu.

Trong một công ty sử dụng thực tiễn và văn hóa DevOps, nơi các Nhà phát triển thường xuyên có quyền truy cập vào cả kiểm soát nguồn và sản xuất, làm thế nào để Phân chia nhiệm vụ có thể đạt được, hay nói chung là làm thế nào để giảm thiểu rủi ro thông đồng.

Câu hỏi của bạn dường như không đưa ra bất kỳ giả định nào về nền tảng / HĐH. Đó là lý do tại sao có thể có ý nghĩa để thêm một câu trả lời về cách thường được thực hiện / giải quyết trong môi trường máy tính lớn, trong đó các "kỹ sư" (như trong tiêu đề câu hỏi của bạn) thực sự là nhóm người có hàng chục (có thể hàng trăm) người bị liên lụy. Câu trả lời của tôi dựa trên việc sử dụng sản phẩm SCM nơi tôi quen thuộc nhất (không chắc có cần tiết lộ tên sản phẩm không).

---

1. Kiến trúc

---

Dưới đây là những điểm nổi bật về cách tôi trả lời câu hỏi của bạn:

• Tất cả các mã (và các tạo phẩm liên quan như tệp thực thi, v.v.) được lưu trữ trong các tệp, tất cả cùng nhau là cái mà chúng ta gọi là cấu trúc thư viện .
• Đối với mỗi môi trường trên mỗi hệ thống đích (có thể là từ xa), có một máy chủ ("tác vụ bắt đầu" trong máy tính lớn), đảm nhiệm việc cập nhật TẤT CẢ (lặp lại: TẤT CẢ) cho mọi thứ trong cấu trúc thư viện. Có một vài trường hợp ngoại lệ (như nhân viên bảo mật hoặc nhóm quản lý không gian), nhưng ngoài ra, không ai (lặp lại: không ai) có quyền áp dụng các bản cập nhật cho bất kỳ tệp nào trong cấu trúc thư viện đó. Nói cách khác: máy chủ có quyền cập nhật độc quyền cho toàn bộ cấu trúc thư viện . Chú ý: Người OPS sẽ đi bon bon nếu bạn bước vào để hạn chế quyền truy cập của họ (lúc đầu họ sẽ chống lại ...), vì vậy hãy đảm bảo bạn được quản lý cấp trên (CxO) bảo vệ để áp đặt các quy tắc truy cập đó ...
• Phần mềm thực tế thay đổi bao gồm một thành phần duy nhất (sửa mã nhỏ vào giữa đêm ...) hoặc cũng có thể là hàng trăm hoặc hàng ngàn nguồn, tệp thực thi hoặc bất kỳ tạo phẩm nào khác (trong cuối tuần phát hành). Để làm cho chúng có thể quản lý được, những thứ nên được di chuyển (nhiều hơn hoặc ít hơn) cùng một lúc, được gói cùng nhau trong cái được gọi là gói thay đổi phần mềm .

Với những điều đã nêu ở trên, bất kỳ loại cập nhật nào được máy chủ áp dụng cho cấu trúc thư viện, sẽ chỉ có thể được thực hiện thông qua một quy trình công việc được xác định rõ, mà chúng tôi gọi là vòng đời của gói thay đổi phần mềm (SDLC nếu bạn muốn). Để thực sự thực hiện các bước khác nhau trong quy trình công việc đó, đây là những gì cần có để thực hiện:

• Chỉ máy chủ sẽ thực hiện các bước cần thiết (và cấu hình sẵn).
• Máy chủ sẽ chỉ thực hiện một bước cụ thể (= cập nhật một cái gì đó trong cấu trúc thư viện), sau khi các phê duyệt cần thiết (từ con người) đã được tập hợp để thực hiện bước đó.
• Các phê duyệt chỉ có thể được đưa ra bởi những người dùng có vai trò cho phép họ (= quyền) đưa ra các phê duyệt đó.

---

2. Vai trò và quyền

---

Máy chủ sẽ đảm bảo rằng người dùng đang cố gắng thực hiện điều gì đó (như 'phê duyệt điều gì đó') sẽ chỉ có thể làm điều đó, nếu quyền của người dùng là phù hợp. Phần đó là dễ dàng. Nhưng bạn không muốn sử dụng hệ thống SCM để quản lý tất cả các quyền đó cho tất cả người dùng có liên quan, đó là những gì thuộc về hệ thống bảo mật của bạn (không phải hệ thống SCM!), Để bạn có thể điều chỉnh quy trình làm việc của mình (trong hệ thống SCM của bạn) để đi kiểm tra các quyền đó bất cứ khi nào thích hợp. Các bước dưới đây cung cấp thêm một số chi tiết về điều đó.

Bước 1: Định cấu hình quyền (trong hệ thống bảo mật)

• Xác định các thực thể bảo mật trong hệ thống bảo mật của bạn, với các tên được xác định rõ cho các thực thể đó. Một vài mẫu (thêm nhiều mẫu tương tự để phù hợp với nhu cầu của riêng bạn):

  • PrmUnit, được sử dụng để nhận được quyền yêu cầu Quảng cáo để nói Đơn vị kiểm tra.
  • PrmQA, được sử dụng để nhận được quyền yêu cầu Quảng cáo để nói Qa -testing (giả sử đây là cấp độ thử nghiệm cao nhất).
  • PrdEnduser, được sử dụng bởi người dùng cuối liên quan đến một số cấp độ thử nghiệm, để cho biết rằng họ hài lòng với kết quả được tạo ra bởi một loại thử nghiệm nào đó. Và vì điều đó, những người dùng cuối đồng ý với sự thay đổi tiến lên trong cấu trúc thư viện.
  • PrdRelmgnt, được sử dụng bởi người quản lý phát hành để ủy quyền Kích hoạt trong sản xuất (= mức cuối cùng / cao nhất trong cấu trúc thư viện).

• Xác định các nhóm người dùng trong hệ thống bảo mật của bạn. Một vài mẫu (thêm nhiều mẫu tương tự để phù hợp với nhu cầu của riêng bạn):

  • GrpDevs, mà (nói) tương ứng với các nhà phát triển của bạn (có thể nhiều hơn chỉ 1).
  • GrpEnduser, mà (nói) tương ứng với người dùng cuối của bạn (ít nhất là 1, tốt nhất là với nhiều người dùng tương tự hơn).
  • GrpRelMgnt, mà (nói) tương ứng với các trình quản lý phát hành của bạn (ít nhất là 1, tốt nhất là thêm một vài người dùng).

• Cấp quyền , cũng sử dụng hệ thống bảo mật của bạn, để cho phép truy cập vào các " thực thể bảo mật " được chọn cho " nhóm người dùng " đã chọn. Để tiếp tục ví dụ trên, đây là những gì có vẻ phù hợp (thích ứng để phù hợp với nhu cầu của riêng bạn):

  • Nhóm GrpDevsđược quyền truy cập vào (chỉ!) Thực thể bảo mật PrmUnit.
  • Nhóm GrpEnduserđược quyền truy cập vào (chỉ!) Thực thể bảo mật PrdEnduser.
  • Nhóm GrpRelMgntđược quyền truy cập vào (cả!) Thực thể bảo mật PrmQAvà PrdRelmgnt.

Bước 2: Định cấu hình quy trình làm việc (trong hệ thống SCM)

Sau khi các quyền được định cấu hình trong hệ thống bảo mật của bạn (như Bước 1), tất cả những gì còn lại phải làm trong hệ thống SCM của bạn là định cấu hình cách các bước khác nhau trong vòng đời khớp với các thực thể bảo mật có liên quan trong hệ thống bảo mật của bạn. Nghĩa là, chỉ những người dùng có quyền truy cập phù hợp vào thực thể bảo mật được yêu cầu, mới được phép yêu cầu máy chủ thực hiện bước tương ứng trong quy trình làm việc.

Dưới đây là một số ví dụ về cách bạn định cấu hình hệ thống SCM của mình để thực hiện một số phép thuật:

• Nếu người dùng có quyền truy cập PrmUnit, thì người dùng đó được phép yêu cầu Quảng cáo lên đơn vị . Rõ ràng, người dùng trong nhóm GrpDevslà người dùng được ủy quyền cho việc này (lưu ý: không, ví dụ: người dùng trong nhóm GrpRelMgnt).
• Nếu người dùng có quyền truy cập PrmQA, thì người dùng đó được phép yêu cầu Quảng cáo lên QA -testing. Rõ ràng, người dùng trong nhóm GrpRelMgntlà người dùng được ủy quyền cho việc này (lưu ý: không, ví dụ: người dùng trong nhóm GrpDevshoặc theo nhóm GrpEnduser).
• Nếu người dùng có quyền truy cập PrdEnduser, thì người dùng đó được phép cho phép thay đổi tiến lên trong cấu trúc thư viện (thường là điều kiện tiên quyết để người dùng trong nhóm GrpRelMgntthậm chí có thể xem xét thay đổi). Rõ ràng, người dùng trong nhóm GrpEnduserlà người dùng (duy nhất) được ủy quyền cho việc này.
• Nếu người dùng có quyền truy cập PrdRelmgnt, thì người dùng đó được phép ủy quyền Kích hoạt trong sản xuất (= mức cuối cùng / cao nhất trong cấu trúc thư viện).

---

3. Mong đợi những điều bất ngờ, và sẵn sàng cho nó

---

Trên đây chỉ là một bản kế hoạch chi tiết, hy vọng sẽ giúp hiểu được cuối cùng nó là máy chủ đảm nhiệm việc phân chia nhiệm vụ như thế nào ... miễn là bạn có CxO bảo vệ bạn áp đặt một số quy tắc truy cập mà không phải ai cũng thích.

Để hoàn thành bức tranh như được giải thích ở trên, máy chủ tạo ra một bản kiểm toán (ghi nhật ký) bất kỳ điều gì đang xảy ra trong hệ thống. Vì vậy, tại bất kỳ thời điểm nào, luôn có thể trả lời các câu hỏi như

Điều gì đã xảy ra khi nào và tại sao, và người dùng được ủy quyền nào thực sự chấp thuận nó ... trả trước?

Nhưng, có lẽ phần khó nhất là có sẵn các công cụ báo cáo đầy đủ (và biết cách sử dụng chúng). Ít nhất để (dễ dàng) đáp ứng các yêu cầu từ kiểm toán viên CNTT (câu hỏi của họ có thể rất khó khăn). Nhưng cũng để chỉ ra các bản ghi nhật ký có liên quan trong hệ thống SCM của bạn để trả lời tất cả các câu hỏi "Chuyện gì đã xảy ra" trong các tình huống khủng hoảng khi sản xuất (một phần) bị ngừng hoạt động.

---

Tái bút: Tôi để mọi người tự đánh giá nếu câu trả lời của tôi là có hoặc không tuân thủ DevOps.

Trả lời dựa trên kiến ​​thức của tôi về quy định "Kiểm soát nội bộ" của Pháp, loại tương đương với quy định của SEC mà bạn chỉ ra, tôi cho rằng việc liên kết ở đây với văn bản pháp lý của Pháp sẽ không thực sự hữu ích và tôi biết không có bản dịch tốt về nó.

Trong một mô hình lý tưởng 'Bạn xây dựng nó, bạn chạy nó', mọi người trong nhóm sẽ chịu trách nhiệm cho sự thay đổi. Việc đánh giá rủi ro không thể được thực thi bằng cách phân chia nhiệm vụ và cách duy nhất tôi biết để tuân thủ quy định là kiểm tra các giao dịch theo chu kỳ ngắn định kỳ cùng với theo dõi hành động không thể thay đổi để quay lại với người đã phát hành .
Điều này có nghĩa là tất cả các nhật ký giao dịch và hành động được đẩy đến một khu vực hạn chế mà nhóm không có quyền truy cập, một sự thay đổi trong nội dung được ghi lại "nên" được kiểm tra bằng chức năng mà nhóm không có quyền truy cập và tệ hơn sẽ bị bắt bởi kiểm toán và theo dõi tác giả của nó.

Điều này không áp dụng cho tất cả các sản phẩm, tại thời điểm viết tại Pháp, bất kỳ công ty nào được phép phát hành tiền (chủ yếu là ngân hàng), phải đảm bảo mọi giao dịch sẽ được ghi lại và do đó không thể có nguy cơ bỏ lỡ giao dịch.
Mặt khác, họ không có nghĩa vụ pháp lý để theo dõi bất kỳ đề nghị thương mại hoặc đánh giá rủi ro nào khi ai đó hỏi vay tiền, và do đó, các sản phẩm xử lý lựa chọn của khách hàng này và tính toán các khoản phí sẽ được cung cấp dễ dàng hơn trong một bài đăng mô hình kiểm toán miễn phí.

Ý tưởng chính là mô hình phát hành phải được điều chỉnh theo nghĩa vụ đánh giá rủi ro.

Một tài nguyên liên quan là định mức ISO27001 .

IMHO, Nhà phát triển & Hoạt động có thể được đại diện bởi không chỉ có hai kho lưu trữ git cho cùng một cơ sở mã , với mỗi mô hình quyền riêng biệt, do đó, các nhóm sẽ không can thiệp vào công việc của nhau.

Hãy gọi chúng là Dev.mygithub.co & ops.mygithub.co , làm ví dụ.

Ý tưởng là, Nhà phát triển có thể tự do tạo / phân nhánh / hợp nhất với nội dung trái tim của họ - nó cung cấp khả năng truy nguyên đầy đủ và đó là vấn đề quan trọng ở đây - tại thời điểm đó, khung pháp lý ngụ ý nỗ lực xem xét có thể đưa ra Yêu cầu Kéo sự hợp nhất để xảy ra một cách có kiểm soát.

Đưa khái niệm đó lên cấp độ tiếp theo, một nhánh phát triển có thể được truyền tới sản xuất của Ops từ xa thông qua một hành động Yêu cầu kéo khác . Phần cuối cùng đó phải xảy ra bằng tay và mắt của các hoạt động, vì họ có trách nhiệm đưa nó vào sản xuất và họ chọn mức độ xem xét.

Sơ đồ như vậy cho phép linh hoạt vô hạn, truy xuất nguồn gốc đầy đủ, khả năng nắm bắt các vấn đề sớm thông qua nhiều quy trình, phân tách mối quan tâm và trải nghiệm người dùng rất hợp lý trong quy trình !

NB Mô hình được mô tả ở trên có thể được theo dõi ngay cả khi Ops & Dev hoàn toàn trùng lặp!

cao hơn là đắt hơn:

• các trang web và phương pháp khác nhau của dev và ops để tiếp tục công việc từ cái này sang cái khác
• khác biệt hệ thống dev và ops & phương pháp như trên
• kho dev và ops git / vcs khác nhau và các phương thức liên quan
• phân nhánh dev và ops git / vcs (được bảo vệ) và các phương thức liên quan

Tùy thuộc vào những gì bạn làm, một số giải pháp tốt hơn các giải pháp khác, ví dụ: nếu bạn có nhu cầu phục vụ hai nhóm có vai trò riêng biệt trong đó và mỗi nhóm có quyền sở hữu và cung cấp truy xuất nguồn gốc đầy đủ, bạn sẽ di chuột qua ba nhóm đầu tiên.

Nói tóm lại, bất cứ điều gì ép buộc một anh chàng hoặc cô gái đều không thể lấy bóng một mình và chạy với nó, và anh ta vượt qua một ranh giới rõ ràng giữa các dev & op. Bây giờ, tùy thuộc vào mức độ rủi ro, ranh giới đó có thể được thực thi hay không.