Які процеси або інструменти дозволяють розділити обов'язки, коли інженери одночасно розгортають і запускають код?

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

Традиційно це означає, що розробники розробляють код, а потім передають його операціям, однак у багатьох операційних моделях DevOps розділення між розробкою та операціями як мінімум розмито:

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

• У моделі "Ви будуєте її, ви запускаєте її" немає окремої функції операцій.

Після того, як місяці витрачалися на першопричини механізму сегрегації обов'язків, здається, переважно існує задоволення Сарбанаса Окслі Розділ 404 : Оцінка управління внутрішнім контролем:

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

(1) заявити відповідальність керівництва за створення та підтримку адекватної структури внутрішнього контролю та процедур фінансової звітності; і

(2) містять оцінку ефективності структури внутрішнього контролю та процедур емітента для фінансової звітності станом на кінець останнього фінансового року емітента.

(b) Оцінка та звітність внутрішнього контролю. Щодо оцінки внутрішнього контролю, що вимагається підпунктом (а), кожна зареєстрована державна бухгалтерська фірма, яка готує або видає аудиторський звіт для емітента, повинна засвідчувати та звітувати про оцінку, зроблену керівництвом емітента. Атестація, зроблена відповідно до цього підрозділу, проводиться відповідно до стандартів щодо атестаційних завдань, виданих або прийнятих Радою. Будь-яка така атестація не є предметом окремої участі.

На основі коментарів важливо висловити кілька припущень, які я висловлюю:

• Я переважно вважаю фінансові послуги масового ринку, тобто обсяги транзакцій є високими, але відносно низькими. Це було б на відміну від комерційних фінансових послуг, які мають інший профіль вартості транзакцій.
• Інтернет-пропозиція фінансової установи складається з багатьох компонентів, що мають різні аспекти ризику:
  • Перемістити гроші - переміщення грошей між рахунками або перекази між рахунками різних власників. Назвіть декілька операцій, які повинні враховувати протидії відмиванню грошей, захисту від шахрайства та ембарго.
  • Придбання клієнта - Менш ризикований, оскільки він має невеликі обсяги транзакцій порівняно з Переміщенням грошей, але все ще потребує розгляду.
  • Інтернет-банкінг - охоплює широкий спектр послуг з різним рівнем ризику, переміщення грошей вважатиметься частиною цього.
• Можливо, для кожного може бути застосований різний підхід, залежно від ризику, однак, в інтересах простоти, я працюю над рішенням, яке стосуватиметься деяких найризикованіших операцій.

TL; DR : На керівництві покладено обов'язок забезпечити належний внутрішній контроль, який відповідає регламенту Комісії з цінних паперів та бірж .

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

У компанії, яка використовує практику і культуру DevOps, де розробники регулярно мають доступ як до контролю над джерелами, так і до виробництва, як можна досягти поділу обов'язків, або загалом, як можна зменшити ризик змови.

Схоже, ваше запитання не дає жодних припущень щодо платформи / ОС, про яку йдеться. Ось чому може бути доцільним додати відповідь про те, як це зазвичай робиться / вирішується в середовищі мейнфреймів, де "інженери" (як у вашій назві питання) насправді є групами людей, де десятки (можливо, сотні) людей залучений. Моя відповідь заснована на використанні продукту SCM, з яким я найбільше знайомий (не впевнений, чи потрібно розкривати назву продукту).

---

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

---

Ось основні моменти, як я відповів би на ваше запитання:

• Весь код (і пов'язані з ним артефакти, такі як виконувані файли тощо) зберігається у файлах, які разом називають структуру бібліотеки .
• Для кожного середовища в кожній (можливо, віддаленій) цільовій системі існує сервер ("розпочате завдання" в основному режимі розмови), який піклується про ВСІ (повторюємо: ВСІ) оновлення до будь-чого в структурі бібліотеки. Є кілька винятків (як люди із безпеки, або команда управління простором), але крім цього, ніхто (повторюємо: ніхто) не має права застосовувати оновлення до будь-якого файлу в цій структурі бібліотеки. Іншими словами: сервер отримує ексклюзивні права оновлення всієї структури бібліотеки . Увага: люди OPS підуть на заїзд, якщо ви заходите обмежувати їхній доступ (спочатку вони чинять опір ...), тож переконайтеся, що вас охоплює вище керівництво (CxO), щоб накласти ці правила доступу ...
• Фактичні зміни програмного забезпечення складаються з одного компонента (крихітний виправлення коду посеред ночі ...), а також це може бути сотні чи тисячі джерел, виконуваних файлів або будь-яких інших артефактів (під час вихідних вихідних). Щоб зробити їх керованими, речі, які слід переміщувати (більш-менш) разом, одночасно поєднуються в те, що називається пакетом змін програмного забезпечення .

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

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

---

2. Ролі та дозволи

---

Сервер гарантує, що користувач, який намагається щось зробити (наприклад, "схвалити щось"), зможе зробити це лише у разі дозволу користувача. Ця частина проста. Але ви не хочете використовувати систему SCM для адміністрування всіх цих дозволів для всіх залучених користувачів, саме це належить до вашої системи безпеки (а не до системи SCM!), Щоб ви могли адаптувати ваш робочий процес (у своїй системі SCM) перейти перевірити ці дозволи, коли це доречно. Наведені нижче кроки містять додаткові деталі щодо цього.

Крок 1: Налаштування дозволів (у системі безпеки)

• Визначте об'єкти безпеки у своїй системі безпеки із чітко визначеними назвами для цих об'єктів. Кілька зразків (додайте стільки подібних, щоб відповідати вашим власним потребам):

  • PrmUnit, Використовуваний для отримання дозволу , щоб запросити Заохочувати сказати Unit -тестування.
  • 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 .

IMHO, Developers & Operations можуть бути представлені нічим іншим, як лише двома сховищами git для однієї бази даних , з кожним чіткою моделлю дозволів, так що команди взагалі не будуть втручатися в роботу один одного.

Назвемо їх Dev.mygithub.co & ops.mygithub.co , як приклад.

Ідея полягає в тому, що розробники вільні створювати / розгалужувати / зливатись із вмістом свого серця - git забезпечує повну простежуваність, і саме це важливо тут, тим часом, у моменти, коли регуляторна база передбачає зусилля щодо перегляду, може бути піднято запит на отримання, злиття відбувається контрольованим чином.

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

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

Примітка. Описану вище модель можна дотримуватися, навіть якщо Ops & Dev повністю перекриваються!

вище дорожче:

• відмінні сайти та методи для розробників та ops для перенесення роботи від одного до іншого
• відмінні системи та методи розробки та операцій, як описано вище
• відмінні сховища dev та ops git / vcs та пов'язані з ними методи
• окремі гілки dev та ops git / vcs (захищені) та пов'язані з ними методи

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

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