Каковы возможные реализации (или примеры) принципа четырех глаз?

Михаэль Грюневальд недавно опубликовал этот комментарий :

Очень важный метод, который вы не упоминаете, - это «принцип четырех глаз», который используется в финансах - либо в качестве регулирующего обязательства, либо в качестве гарантии безопасности. В индустрии программного обеспечения это реализуется различными способами, например, для проверки кода, но также может использоваться для проверки команд, влияющих на работающие системы.

Поправьте меня, если я ошибаюсь, но меня учили, что «принцип четырех глаз» - это то, что «одобрено для того, чтобы происходить», после того, как по крайней мере 2 человека (и / или автоматизированные процессы) дали свое предварительное благословение. Или использовать (слегка исправленную) формулировку о «правиле двух человек» из Википедии :

Правило двух человек - это механизм управления, предназначенный для достижения высокого уровня безопасности для особо важных материалов или операций. Согласно этому правилу любой доступ и действия требуют постоянного присутствия двух уполномоченных лиц.

Обязательства по регулированию, конечно, здесь неуместны, но в контексте «безопасной охраны», каковы возможные концептуальные реализации этого принципа четырех глаз, который, вероятно, мог бы применяться к любой используемой платформе / ОС / аппаратному обеспечению?

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

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

Это позволяет автоматически проверять слияние с реальным (основным) кодом с кодом в PR (Travis является самым популярным для публичного проекта) и дает первую обратную связь по качеству кода. Travis CI (например) может работать на результате фактического мастера с кодом из запроса извлечения, слитым в него, поэтому он потерпит неудачу, если объединение невозможно или если команды, определенные в travisci.yml, возвращают ненулевой выход код

После того, как автоматические тесты пройдены, для принципа 4 глаза все еще требуется настраиваемое количество людей, чтобы рассмотреть и утвердить изменение, прежде чем оно будет объединено, очевидно, по крайней мере, 1 человек (который не является автором PR), чтобы принудить 4 глаза пересмотреть меняется.

Существует широкий спектр вариантов слияния автоматически после того, как кворум рецензентов соблюдается или все же требуется ручное слияние со стороны сопровождающего.

Разрешения на просмотр и слияние могут быть разделены, что помогает дать больше людей "голосовать" за статус слияния, сохраняя при этом возможность ограничить, кто на самом деле может сделать слияние.

Код Отзывы

Речь идет о том, чтобы хотя бы еще один человек посмотрел на код, написанный кем-то, например, чтобы оценить, соответствует ли он некоторым заранее определенным критериям, таким как:

• Стандарты кодирования (отступы и т. Д.).
• Встроенная документация.
• Ремонтопригодность кода.
• Обработка ошибок.
• Полнота (например, if/then/elseили case/whenконструкции охватывают все возможные случаи).

Одобрения для обновления некоторых целевых сред

Речь идет о наличии как минимум 2 подтверждений от какого-либо человека и / или автоматизированной системы, прежде чем будет разрешено обновить какую-либо целевую среду (которая может быть активной или может быть чем-то вроде некоторого основного файла / базовой библиотеки). Вот некоторые примеры:

• При преобразовании (построении) исходных компонентов в исполняемые компоненты допускается только ограниченный набор предупреждений.
• Некоторый набор автоматических тестов должен быть выполнен без каких-либо проблем.
• Некоторые люди должны были указать свое предварительное одобрение (и без этого любые попытки обновить целевые среды автоматически потерпят неудачу).

Это стратегии / модели, которые я могу придумать:

Разделение обязанностей

DevOps, по моему мнению, по крайней мере, не означает воплощение как dev, так и ops в одном человеке. Таким образом, все еще возможно разделить обязанность так, что тот, кто пишет код (dev), не тот, кто его выполняет (ops).

Например, если оператор SQL должен выполняться в реальной среде, один записывает SQL, а другой выполняет его. Это предполагает, что тот, кто выполняет, должен также иметь представление о SQL, а не просто выполнять.

Развернуть триггер

Пока есть заслуга в постоянном развертывании. Команда в более регулируемой отрасли может назначить другую (отдельную) сторону для запуска развертывания вместо автоматического развертывания. Контрольный список, автоматические тесты, контрольные суммы - это возможные проверки перед запуском развертывания.

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

Парное программирование

Лично я не привел этот метод в качестве метода для аудитора, чтобы удовлетворить принцип проверки и баланса. Но потенциально я думаю, что это может быть стратегия.

МИД

Я, возможно, немного растягиваюсь с этим, но возможно, что по какой-то причине вы не хотите одностороннего входа в систему, кто-то может держать пароль, а другой человек держит токен или устройство для одного временного кода. Таким образом, 2 человека должны присутствовать для оценки системы.