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

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

Традиционно это означает, что разработчики разрабатывают код, а затем передают его в Operations, однако во многих операционных моделях DevOps разделение между Development и Operations, как минимум, размыто:

• В практике Google Надежность сайта , или SRE, в Google есть отдельная функция SRE, однако разработчики привлекаются к поддержке SRE в периоды высокой рабочей нагрузки.

• В модели «Вы это создаете, вы запускаете» нет отдельной функции операций.

Потратив месяцы на детализацию основных причин механизма разделения обязанностей, кажется, что он в основном существует, чтобы удовлетворить Sarbanes Oxley Раздел 404 : Оценка управления внутреннего контроля:

(а) Требуемые правила. Комиссия должна установить правила, требующие, чтобы каждый годовой отчет, согласно разделу 13 (а) или 15 (d) Закона о бирже ценных бумаг 1934 года, содержал отчет о внутреннем контроле, который:

(1) установить ответственность руководства за создание и поддержание адекватной структуры внутреннего контроля и процедур финансовой отчетности; и

(2) содержать оценку на конец самого последнего финансового года эмитента эффективности структуры внутреннего контроля и процедур эмитента в отношении финансовой отчетности.

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

Основываясь на комментариях, важно высказать пару предположений, которые я делаю:

• Я преимущественно рассматриваю финансовые услуги массового рынка, то есть объемы транзакций высоки, но относительно низки. Это будет в отличие от коммерческих финансовых услуг, которые имеют другой профиль стоимости транзакции.
• Онлайн-предложение финансового учреждения будет состоять из множества компонентов, которые имеют различные факторы риска:
  • Переместить деньги - перемещение денег между счетами или переводы между счетами разных владельцев. Операция, которая должна учитывать страны по борьбе с отмыванием денег, защитой от мошенничества и эмбарго.
  • Приобретение клиентов - менее рискованный, поскольку он имеет низкие объемы транзакций по сравнению с Move Money, но все еще требует рассмотрения.
  • Интернет-банкинг - охватывает широкий спектр услуг с различными уровнями риска, Move Money будет рассматриваться как часть этого.
• Вероятно, для каждого из них может быть выбран другой подход в зависимости от риска, однако, в целях упрощения, я работаю над решением, которое применимо к некоторым наиболее рискованным операциям.

TL; DR : Это ответственность руководства , чтобы обеспечить адекватный внутренний контроль в месте , которые соответствуют в Комиссии по ценным бумагам и биржам по правилам .

Sarbanes Oxley 404, как правило, удовлетворен путем завершения нисходящей оценки риска, часть которой оценивает риск сговора и предлагает стратегии смягчения последствий.

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

Ваш вопрос, кажется, не предполагает каких-либо предположений о платформе / ОС, о которой идет речь. Вот почему может иметь смысл добавить ответ о том, как это обычно делается / решается в среде мэйнфреймов, где «инженеры» (как в названии вашего вопроса) на самом деле представляют собой группы людей, из которых десятки (возможно, сотни) людей участвует. Мой ответ основан на использовании продукта SCM, с которым я больше всего знаком (не уверен, нужно ли раскрывать название продукта).

---

1. Архитектура

---

Вот основные моменты того, как я отвечу на ваш вопрос:

• Весь код (и связанные с ним артефакты, такие как исполняемые файлы и т. Д.) Хранятся в файлах, которые вместе представляют собой то, что мы называем структурой библиотеки .
• Для каждой среды в каждой (возможно, удаленной) целевой системе существует сервер («запущенная задача» в мейнфрейме), который заботится обо всех (повтор: ВСЕХ) обновлениях чего-либо в структуре библиотеки. Есть несколько исключений (например, сотрудники службы безопасности или группа управления пространством), но кроме этого никто (повторяю: никто) не имеет полномочий применять обновления к любому файлу в этой структуре библиотеки. Другими словами: сервер получает эксклюзивные полномочия на обновление всей структуры библиотеки . Внимание: OPS-люди будут сумасшедшими, если вы войдете, чтобы ограничить их доступ (сначала они будут сопротивляться ...), поэтому убедитесь, что вы накрыты высшим руководством (CxO), чтобы навязать эти правила доступа ...
• Реальные изменения в программном обеспечении могут состоять из одного компонента (крошечное исправление кода посреди ночи ...), или это могут быть также сотни или тысячи источников, исполняемых файлов или любых других артефактов (в выходные дни релиза). Чтобы сделать их управляемыми, вещи, которые должны быть перемещены (более или менее) вместе, в то же время, объединены в так называемый пакет изменений программного обеспечения .

С учетом вышесказанного любое обновление, которое будет применено сервером к структуре библиотеки, будет возможно только через четко определенный рабочий процесс, который мы называем жизненным циклом пакета изменений программного обеспечения (SDLC, если вы предпочитаете). Чтобы фактически выполнить различные шаги в этом рабочем процессе, вот что нужно, чтобы это произошло:

• Только сервер выполнит необходимые (и предварительно сконфигурированные) шаги.
• Сервер выполнит только определенный шаг (= обновит что-то где-нибудь в структуре библиотеки) после того, как будут получены необходимые одобрения (от людей) для выполнения такого шага.
• Одобрения могут быть предоставлены только теми пользователями, у которых есть роль, которая позволяет им (= разрешение) выдавать такие одобрения.

---

2. Роли и разрешения

---

Сервер будет гарантировать, что пользователь, пытающийся заставить что-то произойти (например, «утвердить что-то»), сможет сделать это только при наличии соответствующих разрешений пользователя. Эта часть проста. Но вы не хотите использовать систему SCM для администрирования всех этих разрешений для всех вовлеченных пользователей, это то, что принадлежит вашей системе безопасности (а не системе SCM!), Чтобы вы могли адаптировать свой рабочий процесс (в вашей системе SCM) чтобы проверить эти разрешения, когда это уместно. Шаги ниже предоставляют некоторые подробности об этом.

Шаг 1. Настройка разрешений (в системе безопасности)

• Определите объекты безопасности в вашей системе безопасности с четко определенными именами для этих объектов. Несколько примеров (добавьте столько же похожих, сколько вам нужно):

  • PrmUnitИспользуется для получения разрешения на запрос повышения в программе « Unit -testing».
  • PrmQA, Используемый для получения разрешения , чтобы запросить Поощрять сказать Qa -тестирование (давайте предположим , что это самый высокий уровень тестирования).
  • PrdEnduserиспользуется конечными пользователями, вовлеченными в определенный уровень тестирования, чтобы показать, что они удовлетворены результатами, полученными в результате какого-либо тестирования. И из-за этого эти конечные пользователи соглашаются с изменением, продвигающимся в структуре библиотеки.
  • PrdRelmgntИспользуется менеджерами релизов для авторизации активации в производстве (= последний / самый высокий уровень в структуре библиотеки).

• Определите группы пользователей в вашей системе безопасности. Несколько примеров (добавьте столько же похожих, сколько вам нужно):

  • GrpDevsчто, скажем, соответствует вашим разработчикам (вероятно, больше, чем просто 1).
  • GrpEnduser, который (скажем) соответствует вашим конечным пользователям (по крайней мере 1, предпочтительно с более похожими пользователями).
  • GrpRelMgntчто, скажем, соответствует вашим менеджерам релизов (по крайней мере, 1, желательно еще несколько пользователей).

• Предоставьте разрешения , также используя вашу систему безопасности, чтобы разрешить доступ к выбранным « объектам безопасности » для выбранных « групп пользователей ». Чтобы продолжить приведенный выше пример, вот что кажется подходящим (адаптируйте его под свои нужды):

  • Группа GrpDevsполучает доступ к (только!) Охранному объекту PrmUnit.
  • Группа GrpEnduserполучает доступ к (только!) Охранному объекту PrdEnduser.
  • Группа GrpRelMgntполучает доступ к (как!) Объекту безопасности, так PrmQAи PrdRelmgnt.

Шаг 2: Настройте рабочий процесс (в системе SCM)

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

Вот несколько примеров того, как вы бы сконфигурировали свою систему SCM, чтобы волшебство произошло:

• Если пользователь имеет доступ к PrmUnit, то такой пользователь может запросить Содействие в блок -тестирования. Очевидно, что пользователи в группе GrpDevsявляются авторизованными для этого пользователями (примечание: нет, например, пользователи в группе GrpRelMgnt).
• Если у пользователя есть доступ к нему PrmQA, ему разрешается запросить повышение в QA- тестировании. Очевидно, что пользователи в группе GrpRelMgnt- это пользователи, авторизованные для этого (примечание: нет, например, пользователи в группе GrpDevsили в группе GrpEnduser).
• Если у пользователя есть доступ к нему PrdEnduser, то ему разрешается авторизовать изменение, продвигающееся в структуре библиотеки (что обычно является обязательным условием для пользователей в группе, GrpRelMgntчтобы даже иметь возможность просматривать изменения). Очевидно, что пользователи в группе GrpEnduserявляются (единственными) пользователями, авторизованными для этого.
• Если у пользователя есть доступ к нему PrdRelmgnt, ему разрешается авторизовать активацию в производственной среде (= последний / самый высокий уровень в структуре библиотеки).

---

3. Ожидайте неожиданное и будьте к нему готовы

---

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

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

Что произошло, когда и почему, и какой авторизованный пользователь фактически одобрил это ... авансом?

Но, вероятно, самая сложная часть - иметь адекватные инструменты отчетности (и знать, как их использовать). По крайней мере, чтобы (легко) удовлетворить запросы ИТ-аудиторов (их вопросы могут быть очень сложными). Но также указывать на соответствующие записи журнала в вашей системе SCM, чтобы ответить на всевозможные вопросы «Что случилось» в кризисных ситуациях, когда (часть) производство не работает.

---

PS: Я оставляю это на усмотрение каждого, если мой ответ будет положительным или нет DevOps-совместимым.

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

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

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

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

Связанным ресурсом является норма ISO27001 .

ИМХО, «Разработчики и Операции» могут быть представлены не более чем двумя репозиториями git для одной и той же кодовой базы , каждая с отдельной моделью разрешений, так что команды вообще не будут вмешиваться в работу друг друга.

Давайте назовем их Dev.mygithub.co & ops.mygithub.co , просто в качестве примера.

Идея заключается в том, что разработчики могут свободно создавать / разветвлять / объединять все, что душе угодно - git обеспечивает полную отслеживаемость, и вот что важно здесь - в то время, когда нормативно-правовая база подразумевает усилия по рассмотрению, запрос на извлечение может быть поднят, слияние произойдет контролируемым образом.

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

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

NB. Описанная выше модель может следовать, даже если Ops & Dev полностью перекрываются!

выше дороже

• различные dev & ops сайты и методы для переноса работы с одного на другой
• различные системы и методы разработки и разработки, описанные выше
• различные dev и ops git / vcs репозитории и связанные с ними методы
• отдельные ветки dev и ops git / vcs (защищенные) и связанные с ними методы

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

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