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

18

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

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

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

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

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

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

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

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

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

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

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

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

sre financial-services operating-model Ричард Слейтер
источник
Основная идея организации Devops - привлечь всех в Команду к ответственности за то, что происходит на производстве, не может быть разделения обязанностей. Это в основном означает, что такого рода организация не может быть реально использована, когда есть нормативные потребности для такого разделения.
Тенсибай
@Tensbai Я принципиально не согласен с утверждением, что DevOps несовместим с разделением обязанностей. Законы не являются предписывающими в отношении способа контроля, и при этом регуляторы не навязывают заранее определенный процесс банкам и финансовым услугам. Организация в основном должна определить, что уместно, и быть полностью прозрачной с регулирующими органами и их назначенными аудиторами. В качестве примера, как ING, так и Barclays приняли практики DevOps, чтобы позволить им повысить свою способность приносить прибыль своим клиентам.
Ричард Слейтер
Да, разработчики на предметах, не связанных с разделением по нормативам, и они воспользовались преимуществами автоматизации традиционной организации на основе бункера для ограниченных предметов (которых на самом деле очень мало). У них просто есть два вида организаций, в зависимости от того, какие операции будет выполнять программное обеспечение
Tensibai
Не существует такой вещи, как «Разделение регулятивных норм», в законодательных актах / законах и регулирующих органах не предусматривается разделение финансовых учреждений, они налагают управленческую ответственность за наличие «Соответствующего контроля» для управления финансовыми рисками. Подобно тому, как Agile переводил разработку программного обеспечения из длинных циклов в небольшие циклы, DevOps переводит операции в небольшие циклы, так как DevOps в Financial Services должен найти способ разделить обязанности на небольшие циклы, например, путем создания конвейера CD, который обеспечивает "надлежащий контроль", такой как рецензирование и продвижение на основе одобрения.
Ричард Слейтер
1
@ Pierre.Vriens да, широкий вопрос в названии, я попытался расширить его, сделав некоторые предположения. Роли, вероятно, будут частью решения, как и такие вещи, как Break-Glass и управление привилегированными учетными записями. Роли и обязанности являются интересной концепцией в DevOps / Agile, так как когда-то у вас были Java-разработчик, F / E Developer, дизайнер, PM, инженер по сборке, Release Manager и Ops Engineer - теперь у вас есть группа людей, которые могут носить несколько шляп - кросс-функциональные команды, состоящие из «инженеров», которые могут специализироваться, но в конечном итоге разделить ответственность.
Ричард Слейтер

Ответы:

8

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

Pierre.Vriens
источник
Это звучит как базовая реализация нисходящей оценки риска, я не понимаю, как она решает вопрос о том, как это может быть реализовано способом devops, где у разработчиков были бы права на запуск переключателя «развернуть». Является ли идея, что вы не можете сделать это в организации Devops?
Тенсибай
@Tensibai «если» разработчики будут обладать авторизацией (ролью) (например) окончательного утверждения для prod (которого они обычно НЕ имеют в таких организациях), то такой сервер (запущенная задача) начнет развертывание. А что касается названия вопроса, я думаю, что это «возможный» ответ. Однако можно задаться вопросом, является ли это тем, что мы назвали бы организацией DevOps, но я знаю, что аудиторам действительно нравится этот вид «конфигурируемой» разделения обязанностей (например: четыре глаза и варианты этого). Может быть, Ричард может помочь нам с его точкой зрения на это?
Pierre.Vriens
1
Я согласен, что аудиторам это нравится, я просто упустил, как это соотносится с «взрывом» доступа, который аудитору обычно не нравится, когда в списке более 6-7 человек. Сказать, что это не подходит, является абсолютно верным ответом ИМХО.
Тенсибай
1
Спасибо, что уделили так много времени ответу. Я на самом деле думаю о реализации правила из 3 человек, в котором один разработчик пишет код, другой разработчик просматривает код, а третье лицо нажимает кнопку выпуска, чтобы развернуть код. Другое соображение заключается в том, что это является частью внедрения Agile / DevOps в масштабах всей компании, команды разработчиков которого довольно малы, с чистым эффектом от небольших групп людей, имеющих доступ к продукции для тонкого куска продукции, это кажется благоприятным с точки зрения риска ,
Ричард Слейтер,
1
@ Pierre.Vriens Не могу дважды проголосовать, отличное продолжение :)
Тенсибай
5

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

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

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

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

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

Tensibai
источник
Интересный ответ и очень актуальный, так как многие европейские банки действительно работают во Франции. Есть ли шанс, что вы могли бы расширить, что означает «Emit Money», то есть это просто наличные из банкомата или включает в себя перевод баланса. В этом случае ссылки на законодательные акты были бы полезны, поскольку они дают указатель на соответствующие законы, независимо от того, на
Ричард Слейтер,
@RichardSlater Короче говоря, любая компания, работающая с деньгами, может быть инвестиционной компанией, а также кредитными брокерами в традиционных банках. В основном это касается всего, что имеет какое-либо финансовое влияние (из немногих исключений, которые могут быть предоставлены властями в случае непредвиденных обстоятельств). Законный «список» на французском здесь , но даже по - французски это не всегда очевидно.
Тенсибай
Я делаю предположение, что ссылка на стандарт ISO должна быть на самом деле ISO27001: 2013
Ричард Слейтер,
@Richard действительно, кажется, что ссылка на французский с английского не была обновлена ​​в Википедии. Я
обновлю
связанный: Как я могу убедить разработчиков в моей команде принять «Вы создаете это, вы управляете этим»?
Дан
0

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

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

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

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

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

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

fgeorgatos
источник
1
Конечно, этот же контроль может быть достигнут с помощью запросов на получение данных и перехватов после фиксации, которые гарантируют, что разработчики могут фиксировать свободно, однако фиксацию слиянием может выполнять только утвержденная группа людей. Точно так же тот же хук после фиксации мог бы гарантировать, что в число авторов коммитов, составляющих запрос на извлечение, не входило лицо, выполняющее запрос на извлечение.
Ричард Слейтер
@RichardSlater: причина, по которой вы захотите иметь два разных репозитория, заключается в том, что у вас есть двойная необходимость разрешать разработчикам объединяться - когда они свободно меняются кодом в режиме разработчика - а также блокировать большинство разработчиков от объединения кода, когда он перейти к производству (по модулю SysOps, т. е. так называемая «утвержденная группа людей»).
fgeorgatos
Опять же, вы можете добиться этого с помощью перехватов после фиксации и запросов на получение, не говоря уже о том, что GitHub Enterprise разрешает защищенные ветви.
Ричард Слейтер
0

выше дороже

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

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

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

fgeorgatos
источник