Які можливі реалізації (або приклади) принципу "чотири очі"?

Michael Grünewald нещодавно опублікував цей коментар :

Дуже важливим методом, який ви не згадуєте, є "принцип чотирьох очей", який використовується у фінансах - або як регуляторне зобов'язання, або як безпека. У галузі програмного забезпечення він реалізується різними способами, як, наприклад, огляд коду, але також може бути використаний для перевірки команд, що впливають на живі системи.

Виправте мене, якщо я помиляюся, але мене вчили, що "принцип чотирьох очей" - це те, що "схвалено відбутися", після того, як принаймні 2 людини (та / або автоматизовані процеси) дали своє попереднє благословення. Або використати (злегка виправлене) формулювання про "правило про дві людини" з Вікіпедії :

Правило для двох людей - це механізм управління, призначений для досягнення високого рівня безпеки особливо важливих матеріалів або операцій. Згідно з цим правилом, весь доступ та дії вимагають присутності двох уповноважених людей у ​​всі часи.

Нормативні зобов'язання тут, безумовно, поза темою, але в контексті "безпечної охорони", які можливі концептуальні реалізації цього принципу "чотири очі", які, ймовірно, можуть стосуватися будь-якої платформи / ОС / обладнання, яке використовується?

Однією з реалізацій коду є модель Pull Request (PR), популяризована GitHub.

Основне міркування полягає в тому, що лише невеликий набір обслуговуючого продукту дозволить об'єднати код у гілку випуску. Кожна нова функція / виправлення буде відбуватися в новій гілці, і як тільки буде зроблено, буде визначено запит на витяг.

Це дозволяє перевірити на злиття з фактичного випуску (головного) коду з кодом в PR автоматичним способом (Travis є найпопулярнішим для публічного проекту насправді) і дати перший відгук на якість коду. Travis CI (наприклад) може працювати за результатом фактичного майстра з кодом з об'єднаного в нього запиту на витяг, тому він вийде з ладу, якщо об'єднання неможливе, або якщо команди, визначені в travisci.yml, повернуть не нульовий вихід код

Після автоматичного тестування за принципом "4 очі" все-таки потрібно конфігурувати кількість осіб для перегляду та затвердження змін до її об'єднання, очевидно, принаймні 1 особа (яка не є автором піару), щоб примусити 4 очі переглядати зміни.

Існує широкий спектр варіантів автоматичного злиття після того, як буде досягнуто кворум рецензентів або все ж потрібне ручне злиття з боку технічного обслуговування.

Дозволи на перегляд та злиття можна розділити, що допомагає надати більшій кількості людей право "голосувати" за статус злиття, зберігаючи при цьому можливість обмежити, хто може насправді зробити об'єднання.

Огляди коду

Йдеться про те, щоб хоча б 1 особа подивилася на код, написаний кимось, наприклад, щоб оцінити, чи відповідає він певним заздалегідь визначеним критеріям, наприклад:

• Стандарти кодування (відступи тощо).
• Вбудована документація.
• Ремонтопридатність коду.
• Помилка обробки.
• Повнота (наприклад, if/then/elseабо case/whenконструкції охоплюють усі можливі випадки).

Дозволу на оновлення деяких цільових середовищ

Йдеться про наявність щонайменше 2 підтверджень від якоїсь особи та / або автоматизованої системи, перш ніж буде дозволено оновити деяке цільове середовище (яке може бути в прямому ефірі або може бути чимось на зразок головного файлу / базової бібліотеки). Деякі приклади:

• Допускається лише обмежений набір попереджень при перетворенні (побудові) вихідних компонентів у виконувані компоненти.
• Деякий набір автоматизованих тестів повинен бути виконаний без жодних проблем.
• Деякі люди повинні вказати своє попереднє схвалення (і без цього будь-які спроби оновити цільове середовище автоматично провалюються).

Це стратегії / зразки, про які я можу придумати:

Розмежування обов'язку

Як я вважаю, DevOps, принаймні, не означає втілення і розробників, і операторів в одній людині. Отже, ще можна розділити обов'язок таким чином, щоб той, хто пише код (dev), був не тим, хто його виконує (ops).

Наприклад, якщо оператор SQL повинен бути виконаний у прямому середовищі, один записує SQL, а інший виконує його. Що передбачається, це те, що потрібно виконувати також, щоб мати розуміння SQL, а не просто виконувати.

Розгорнути курок

Поки є заслуга в постійному розгортанні. Команда в більш регульованій галузі може призначити іншу (окрему) сторону, щоб запустити розгортання замість розгортання автоматично. Контрольний список, автоматизовані тести, контрольні суми можливі перевірки перед запуском розгортання.

Після запуску автоматизація може продовжувати виконувати розгортання.

Парне програмування

Особисто я не називав цю методику як аудиторський метод для задоволення принципу перевірки та балансу. Але потенційно я думаю, що це може бути стратегія.

МЗС

Я, можливо, трохи розтягнувся з цим, але можливо, з якоїсь причини, що ви не хочете одностороннього входу в систему, хтось може тримати пароль, а інша людина тримати маркер або пристрій на один часовий код. Отже, для оцінки системи повинні бути присутні 2 людини.