四眼原理の可能な実装（または例）は何ですか？

MichaelGrünewaldが最近このコメントを投稿しました：

あなたが言及していない非常に重要な方法は、規制の義務として、またはセーフガードとして、金融で使用されている「四つ目の原則」です。ソフトウェア業界では、コードレビューなど、さまざまな方法で実装されていますが、ライブシステムに影響するコマンドの検証にも使用できます。

間違っている場合は修正しますが、少なくとも4人の人間（および/または自動化されたプロセス）が事前の祝福を与えた後、「4目原則」は「発生が承認された」ものに関するものであると教えられました。または、ウィキペディアの「二人（二人）のルール」に関する（わずかに修正された）表現を使用するには：

二人ルールは、特に重要な素材または操作に対して高レベルのセキュリティを実現するために設計された制御メカニズムです。この規則の下では、すべてのアクセスとアクションには、常に2人の許可された人の存在が必要です。

規制上の義務はここでは話題になりませんが、「セーフガード」の文脈では、おそらく使用されているプラ​​ットフォーム/ OS /ハードウェアに適用される可能性のあるこの4つ目の原則の概念的な実装は何ですか？

コードの実装の1つは、GitHubによって普及したプルリクエストモデル（PR）です。

背後にある主な理由は、製品の少数のメンテナーのみがリリースブランチにコードをマージできることです。すべての新しい機能/バグ修正は新しいブランチで発生し、一度実行されるとプルリクエストとして定義されます。

これにより、実際のリリース（マスター）コードとPRのコードとのマージを自動的にテストし（Travisは実際に公開プロジェクトで最も人気があります）、コード品質に関する最初のフィードバックを提供できます。Travis CI（たとえば）は、プルリクエストからのコードがマージされた実際のマスターの結果で実行できるため、マージが不可能な場合、またはtravisci.ymlで定義されたコマンドがゼロ以外の終了を返す場合、失敗しますコード

自動テストに合格した後、4目原則では、少なくとも1人（PR作成者ではない）が明らかにマージされる前に、変更を確認して承認する構成可能な人数が必要です。変更。

レビュアーの定足数に達したら自動的にマージするか、メンテナーが手動でマージする必要がある幅広いオプションがあります。

レビューとマージの許可を分離することができます。これにより、実際にマージを実行できるユーザーを制限する可能性を維持しながら、より多くの人にマージステータスに「投票」する権利を与えることができます。

コードレビュー

これは、誰かが書いたコードを少なくとも1人の他の人に見てもらうことです。たとえば、次のような定義済みの基準を満たしているかどうかを評価します。

• コーディング標準（インデントなど）。
• インラインドキュメント。
• コードの保守性。
• エラー処理。
• 完全性（if/then/elseまたはcase/when、可能性のあるすべてのケースを構成するものなど）。

一部のターゲット環境の更新の承認

これは、ターゲット環境（ライブ、またはマスターファイル/ベースラインライブラリのようなもの）の更新を許可する前に、人や自動システムから少なくとも2つの確認を取得することです。以下に例を示します。

• 実行可能コンポーネントのソースコンポーネントを変換（ビルド）する場合、限られた警告のみが許可されます。
• 自動テストのいくつかのセットは、プローベなしで完了している必要があります。
• 一部の人間は、事前の承認を示している必要があります（それなしでは、ターゲット環境を更新しようとすると自動的に失敗します）。

これらは私が考えることができる戦略/パターンです：

義務の分離

少なくとも私の考えでは、DevOpsは、1人でdevとopの両方を実施することを意味しません。したがって、コードを書いている人（dev）がそれを実行している人（ops）ではないように、義務を分離することはまだ可能です。

たとえば、SQLステートメントをライブ環境で実行する場合、SQLステートメントを作成し、別のステートメントを実行します。これが前提とするのは、実行するだけでなく、SQLについても理解する必要がある実行者です。

トリガーを展開する

継続的に展開するメリットがありますが。規制の厳しい業界のチームは、自動的に展開するのではなく、別の（別個の）パーティを指名して展開をトリガーできます。チェックリスト、自動テスト、チェックサムは、デプロイをトリガーする前の可能なチェックです。

トリガーされると、自動化は展開を実行します。

ペアプログラミング

個人的に、私はこのテクニックをチェックとバランスの原則を満たすための審査員への方法として引用していません。しかし、潜在的には戦略になると思います。

MFA

私はこれで少しストレッチしているかもしれませんが、何らかの理由でシステムに一方的に入力したくない場合は、誰かがパスワードを保持し、別の人がトークンまたはデバイスを一時コードで保持できる可能性があります。そのため、システムを評価するには2人が必要です。