Những triển khai có thể (hoặc ví dụ) của nguyên tắc bốn mắt là gì?

Michael Grünewald gần đây đã đăng bình luận này :

Một phương pháp rất quan trọng mà bạn không đề cập đến là nguyên tắc bốn mắt của người Hồi giáo được sử dụng trong tài chính - như là một nghĩa vụ pháp lý hoặc là một người bảo vệ an toàn. Trong công nghiệp phần mềm, nó được triển khai theo nhiều cách khác nhau, ví dụ như đánh giá mã nhưng cũng có thể được sử dụng để xác nhận các lệnh ảnh hưởng đến các hệ thống trực tiếp.

Sửa lỗi cho tôi nếu tôi sai, nhưng tôi được dạy rằng "nguyên tắc bốn mắt" là về một điều gì đó "được chấp thuận xảy ra", sau khi ít nhất 2 con người (và / hoặc các quá trình tự động) ban phước lành trước đó. Hoặc để sử dụng từ ngữ (được sửa một chút) về "quy tắc hai người (wo)" từ Wikipedia :

Quy tắc hai người là một cơ chế kiểm soát được thiết kế để đạt được mức độ bảo mật cao cho các hoạt động hoặc tài liệu đặc biệt quan trọng. Theo quy tắc này, tất cả các quyền truy cập và hành động đều cần có sự hiện diện của hai người được ủy quyền mọi lúc.

Nghĩa vụ pháp lý là khá chắc chắn, lạc đề ở đây, nhưng trong bối cảnh "bảo vệ an toàn", những triển khai khái niệm có thể có của nguyên tắc bốn mắt này, có thể áp dụng cho bất kỳ nền tảng / HĐH / phần cứng nào đang được sử dụng?

Một trong những triển khai trên mã là mô hình Pull Request (PR) được phổ biến bởi GitHub.

Lý do chính đằng sau là chỉ một nhóm nhỏ các nhà bảo trì sản phẩm sẽ được phép hợp nhất mã vào nhánh phát hành. Mỗi tính năng / lỗi mới sẽ xảy ra trên một nhánh mới và sau khi hoàn thành sẽ được xác định là yêu cầu kéo.

Điều này cho phép kiểm tra sự hợp nhất từ ​​mã phát hành thực tế (chính) với mã trong PR theo cách tự động (Travis là phổ biến nhất cho dự án công cộng thực sự) và cung cấp phản hồi đầu tiên về chất lượng mã. Travis CI (ví dụ) có thể chạy trên kết quả của chủ thực tế với mã từ yêu cầu kéo được hợp nhất vào nó, do đó, nó sẽ thất bại nếu không thể hợp nhất hoặc nếu các lệnh được xác định trong travisci.yml trả về một lối thoát khác không mã

Khi các thử nghiệm tự động đã qua, đối với nguyên tắc 4 mắt, nó vẫn yêu cầu số lượng người có thể định cấu hình để xem xét và phê duyệt thay đổi trước khi hợp nhất rõ ràng ít nhất 1 người (không phải là tác giả PR) để thực thi 4 mắt xem xét thay đổi.

Có một loạt các tùy chọn để hợp nhất tự động sau khi nhóm đại biểu của người đánh giá được đáp ứng hoặc vẫn cần một sự hợp nhất thủ công của người bảo trì.

Các quyền để xem xét và hợp nhất có thể được tách ra, giúp cho nhiều người có quyền "bỏ phiếu" hơn trong trạng thái hợp nhất trong khi vẫn giữ khả năng hạn chế người thực sự có thể thực hiện hợp nhất.

Nhận xét mã

Đây là về việc có ít nhất 1 người khác nhìn vào mã được viết bởi ai đó, ví dụ để đánh giá xem nó có đáp ứng một số tiêu chí được xác định trước như:

• Tiêu chuẩn mã hóa (thụt đầu dòng, vv).
• Tài liệu nội tuyến.
• Khả năng duy trì của mã.
• Xử lý lỗi.
• Tính đầy đủ (ví dụ if/then/elsehoặc case/whencấu trúc bao gồm tất cả các trường hợp có thể).

Phê duyệt để cập nhật một số môi trường đích

Đây là về việc có ít nhất 2 xác nhận từ một số người và / hoặc hệ thống tự động trước khi được phép cập nhật một số môi trường đích (có thể là trực tiếp hoặc có thể giống như một số thư viện tệp / đường cơ sở chính). Một số ví dụ:

• Chỉ cho phép một bộ cảnh báo giới hạn khi chuyển đổi (xây dựng) các thành phần nguồn trong các thành phần thực thi.
• Một số bộ kiểm tra tự động phải được hoàn thành mà không có bất kỳ chứng thực nào.
• Một số con người phải chỉ ra sự chấp thuận trước của họ (và không có điều đó, mọi nỗ lực cập nhật môi trường đích sẽ tự động thất bại).

Đây là những chiến lược / mô hình tôi có thể nghĩ ra:

Tách nhiệm vụ

DevOps, theo quan điểm của tôi ít nhất, không có nghĩa là hiện thân của cả dev và op trong một người. Vì vậy, vẫn có thể phân tách nhiệm vụ sao cho người viết mã (dev) không phải là người thực thi nó (ops).

Ví dụ, nếu một câu lệnh SQL được thực thi trên môi trường trực tiếp, một câu lệnh sẽ viết SQL và một câu lệnh khác thực thi nó. Điều này giả định trước là một nhu cầu thực thi cũng cần có sự hiểu biết về SQL và không chỉ thực thi.

Triển khai kích hoạt

Trong khi có công để liên tục triển khai. Nhóm trong một ngành quy định hơn có thể chỉ định một bên (riêng) khác để kích hoạt triển khai thay vì triển khai tự động. Danh sách kiểm tra, kiểm tra tự động, tổng kiểm tra là những kiểm tra có thể có trước khi kích hoạt triển khai.

Sau khi được kích hoạt, tự động hóa có thể đi trước để thực hiện triển khai.

Lập trình cặp

Cá nhân tôi đã không trích dẫn kỹ thuật này như một phương pháp để kiểm toán viên để đáp ứng nguyên tắc kiểm tra và cân bằng. Nhưng có khả năng tôi nghĩ nó có thể là một chiến lược.

MFA

Tôi có thể kéo dài một chút với cái này, nhưng có thể vì một số lý do mà bạn không muốn nhập đơn phương vào hệ thống, ai đó có thể giữ mật khẩu và một người khác giữ mã thông báo hoặc thiết bị cho một lần mã. Vì vậy, 2 người phải có mặt để đánh giá hệ thống.