Часть 1. Введение: Почему в банке всё устроено сложнее?
В первом уроке Вы разобрались, чем методолог отличается от бизнес-аналитика и системного аналитика. Теперь нужно понять среду, в которой ему приходится работать. Одни и те же действия – выдать сотруднику доступ, развернуть сервер, установить обновление – в маленькой компании занимают пять минут и одно сообщение администратору, а в крупном банке превращаются в процесс с согласованиями, проверками и записями в журналах. Новичку это часто кажется лишней бюрократией. Чтобы так не казалось, полезно понять, откуда эти правила берутся.
Причин три. Первая – цена ошибки. Если в небольшой компании на час перестанет работать корпоративный портал, сотрудники немного поработают без него. Если на час остановится обработка платежей в банке, клиенты не смогут расплатиться, банк потеряет деньги и доверие, а регулятор потребует объяснений. Вторая – требования регулятора. Банки находятся под надзором Банка России и обязаны соблюдать законы о защите персональных данных, о безопасности критической информационной инфраструктуры и множество отраслевых требований. Мало их выполнять, нужно ещё и уметь это доказать проверяющим. Третья – масштаб и наследие: в крупном банке сотни систем и тысячи серверов, часть из них работает десятилетиями, потому что на них держится важная функция, и менять такие системы приходится осторожно.
Хорошая аналогия – авиация. В кафе ошибка повара означает недовольного гостя, поэтому там обходятся без сложных процедур. Самолёт же перед вылетом проверяют по чек-листу, а результат подписывают двое, потому что ошибка обслуживания может стоить жизней. ИТ крупного банка ближе ко второму случаю: любое действие, которое может повлиять на деньги или данные клиентов, делается по правилам, оставляет след и проверяется.
Отсюда важная мысль для методолога: правила банка существуют не ради бюрократии, каждое из них отвечает на конкретный риск. Ваша задача не отменить контроль, а встроить его в процесс так, чтобы он был понятным, быстрым и проверяемым. Это тот самый третий вопрос из прошлого урока: «Как это должно быть организовано и как мы убедимся, что так работают все?»
И ещё одно понятие, которое будет встречаться постоянно. ИТ-ресурсы – это всё, что нужно банку для работы ИТ: оборудование и серверные мощности, программное обеспечение и лицензии, доступы и учётные записи, сети и каналы связи, данные, а также люди и бюджет. Управление ресурсами – это ответы на несколько вопросов: что у нас есть, кому это принадлежит, кто имеет к этому доступ, сколько это стоит и когда это нужно обновить или вывести из эксплуатации.
Часть 2. Ключевые особенности ИТ-процессов в банковском секторе
Пять особенностей ниже встречаются в любой крупной организации, но в банке проявляются сильнее всего. Это не отдельные процессы, а требования, которые приходится учитывать почти в любом ИТ-процессе: при заказе сервера, выдаче доступа, установке обновления. Многие банки строят процессы на основе ITIL – свода рекомендаций по управлению ИТ как услугой (такой подход называют ITSM), поэтому термины ниже Вы встретите в большинстве регламентов. Если Вы описываете процесс и не знаете, где нужен контроль, пройдите по этим пяти пунктам, как по чек-листу.
1. Регуляторные требования и аудит: Вы строите процесс так, чтобы его соблюдение можно было доказать.
Соответствие требованиям закона и регулятора называют комплаенсом, а проверку того, что оно соблюдается, – аудитом: внутренним, который проводит служба самого банка, или внешним. В банке действует негласное правило: если действие нигде не записано, считается, что его не было. Представьте, что аудитор спрашивает: «Кто и когда согласовал этому сотруднику доступ к клиентской базе?» Если ответ приходится искать в чьей-то почте, процесс устроен плохо. Если ответ находится в системе за минуту, с датой, именами и основанием, процесс устроен хорошо. Такую запись называют аудиторским следом, и методолог проектирует процесс так, чтобы след появлялся сам, а не восстанавливался задним числом.
2. Информационная безопасность и разделение полномочий: Вы следите, чтобы никто не мог в одиночку выполнить критичное действие от начала до конца.
Информационная безопасность (ИБ) отвечает за то, чтобы данные и системы были защищены от утечек, взлома и злоупотреблений. Два принципа лежат в основе большинства правил. Первый – принцип наименьших привилегий: человеку выдаётся ровно столько прав, сколько нужно для работы, и на нужный срок. Второй – разделение полномочий: тот, кто просит доступ, не должен сам его согласовывать и выдавать, иначе контроль теряет смысл. Его часто называют принципом «четырёх глаз»: важное действие видят минимум два человека. Если администратор может сам себе выдать права на промышленную систему, никакая политика безопасности не сработает. Методолог превращает эти принципы в роли и точки согласования: кто запрашивает, кто согласует, кто исполняет и кто проверяет.
3. Управление изменениями: Вы проектируете порядок, при котором любое изменение в ИТ-среде проходит оценку, согласование и имеет план отката.
Изменением называют любое вмешательство в работающую ИТ-среду: установку обновления, настройку сервера, подключение нового сервиса. Практика показывает, что многие сбои происходят именно после таких вмешательств, поэтому в крупных организациях их проводят через управление изменениями. Перед работой оценивают, на какие системы она повлияет, и согласуют её, иногда на специальном комитете по изменениям (CAB). Затем назначают окно работ – время минимальной нагрузки, например ночь или выходной, – и заранее готовят план отката: как вернуть всё как было, если что-то пойдёт не так. Типовые безопасные изменения обычно одобряют заранее по шаблону, чтобы не согласовывать их каждый раз, а серьёзные проходят полный путь.
4. Управление ИТ-активами и ресурсами: Вы добиваетесь, чтобы у каждого ресурса были учёт, владелец и понятный жизненный цикл.
ИТ-активом называют любой ресурс, который имеет ценность и за который кто-то отвечает: сервер, лицензию на программу, приложение. Сведения о них собирают в реестре активов. Продвинутый вариант такого реестра, где хранятся ещё и связи между объектами (какое приложение на каком сервере работает), называют CMDB. У каждого актива должен быть владелец – человек или команда, которые отвечают за него и решают, когда его обновить или отключить. Кроме того, у каждого актива есть жизненный цикл: заказ, получение, использование, обновление, вывод из эксплуатации. Типичная беда – сервер создали и забыли о нём: его никто не обновляет, он становится уязвимым, на нём работает программа без оплаченной лицензии, а банк продолжает платить за его содержание. Поэтому для методолога процесс выдачи ресурса не заканчивается самой выдачей: он должен гарантировать запись в реестре и закрепление за владельцем.
5. Непрерывность и критичность систем: Вы учитываете, что чем важнее система, тем строже правила и тем быстрее её нужно восстанавливать.
Не все системы одинаково важны: остановка мобильного банка для миллионов клиентов и недоступность внутреннего справочника – события несопоставимого масштаба. Поэтому системы делят по критичности, а от неё зависит всё остальное: насколько строгим будет согласование, как часто делают резервные копии, как быстро нужно реагировать на сбой. Для описания этих требований используют несколько понятий. SLA – соглашение об уровне сервиса: какую доступность и какие сроки реакции обещают потребителю. RTO – за какое время систему нужно восстановить после сбоя, RPO – сколько данных (в пересчёте на время) допустимо потерять, например последние пятнадцать минут. Внеплановую остановку или ухудшение работы сервиса называют инцидентом: чем критичнее система, тем выше приоритет инцидента и тем жёстче сроки.
Часть 3. Модель взаимодействия на примере кейса «Доступ разработчика к промышленной системе»
Посмотрим, как особенности из Части 2 работают вместе. Разработчику нужно разобраться с ошибкой в промышленной системе банка, и для этого ему нужен временный доступ к её журналам. В маленькой компании администратор просто добавил бы его в нужную группу. В банке запрос проходит цепочку участников, и у каждого своя ответственность. Обратите внимание, какая особенность проявляется на каждом шаге.
Инициатор (разработчик и его руководитель): «Прошу доступ на чтение журналов системы на три дня: нужно найти причину ошибки в обработке платежей».
Запрос оформляется в системе заявок, а не в чате или по телефону. В нём обязательно указаны система, нужные права, срок и причина. Это принцип наименьших привилегий и основа аудиторского следа. Руководитель подтверждает, что доступ действительно нужен для работы.
Владелец системы: «Согласую: доступ только на чтение и только на указанный срок».
Владелец отвечает за систему и её данные, поэтому именно он решает, кого к ней допускать. Он видит последствия, которые не видны инициатору. Здесь работает разделение полномочий: тот, кто просит, не тот, кто разрешает.
Служба информационной безопасности: «В журналах есть персональные данные клиентов, поэтому нужны дополнительные ограничения».
ИБ оценивает риск независимо и от владельца, и от инициатора. Если в журналах есть данные клиентов, она может потребовать скрыть часть полей или ограничить срок. Чем выше риск и критичность системы, тем строже проверка, а для безопасных запросов она может быть упрощённой.
ИТ-администратор: «Выдаю ровно согласованные права на согласованный срок».
Исполнитель не принимает решений о доступе, а выполняет согласованное. В хорошо устроенном процессе он не может расширить права «по доброте душевной», а данные для входа передаёт через систему, а не в мессенджере.
Система учёта и журнал: записывает, кто, что и когда запросил, согласовал и выдал, и закрывает доступ по истечении срока.
Запись возникает автоматически на каждом шаге, поэтому аудитор может восстановить всю цепочку за минуты. По окончании срока доступ закрывается без напоминаний, а при регулярной перепроверке прав обнаруживаются те, которые остались без необходимости.
Всю эту цепочку проектирует методолог: решает, какие шаги обязательны, кто за что отвечает, сколько времени отводится на каждый шаг (SLA) и что делать, если кто-то не ответил. Он же следит, чтобы контроль не превратился в тормоз: если согласование занимает неделю, разработчик не сможет вовремя найти ошибку, и банк потеряет больше, чем сэкономит на осторожности. Поэтому для безопасных и типовых запросов (например, доступ к тестовой среде без реальных данных) методолог предлагает упрощённый путь, а полную цепочку оставляет для критичных систем.
Цепочка выглядит так: инициатор просит, владелец разрешает, ИБ оценивает риск, администратор исполняет, система записывает. Каждый шаг отвечает на свой вопрос и опирается на предыдущий, а качество всего процесса измеряется тем, насколько он надёжен и при этом не мешает работе.
Часть 4. Практическое задание (Case Study)
Теперь поработайте в роли методолога. Не читайте ключи, пока не выполните оба задания сами: ошибки и сомнения при самостоятельном решении учат лучше, чем готовый ответ. Сначала внимательно прочитайте легенду и описание AS IS.
Легенда: Вы работаете ИТ-методологом-аналитиком в крупном банке. Команды разработки регулярно запрашивают серверы под новые сервисы, и процесс выделения ИТ-ресурсов давно никто не пересматривал. Недавно внутренний аудит выявил серьёзные замечания, и Вам поручили привести процесс в порядок.
Входящие данные (фрагмент описания AS IS): «Руководитель команды разработки пишет письмо начальнику ИТ-инфраструктуры с просьбой выделить серверы под новый сервис. Начальник устно соглашается. Администратор создаёт серверы в удобное для него время, не оценивая, как это повлияет на соседние сервисы, и отправляет разработчикам данные для входа в мессенджере. О том, насколько новый сервис важен и как его восстанавливать после сбоя, никто не спрашивает. Служба ИБ узнаёт о новых серверах уже после запуска, если вообще узнаёт. Сведения о серверах попадают в общий Excel-реестр, когда администратор о них вспомнит, а ответственного указывают не всегда. Через год внутренний аудит обнаружил серверы, которые не принадлежат ни одной команде, но продолжают работать и стоить денег. А когда регулятор запросил перечень систем с персональными данными клиентов, банк собирал его три недели».
Прежде чем решать, прочитайте AS IS второй раз, с карандашом. Отметьте, кто участвует в процессе, кто принимает решения и кто их проверяет, где остаётся письменный след, а где нет. Эти пометки пригодятся в обоих заданиях.
Задание 1: Распознавание нарушений
Для каждой ситуации определите, какая из пяти особенностей ИТ-процессов банка из Части 2 в ней нарушена: регуляторные требования и аудит; информационная безопасность и разделение полномочий; управление изменениями; управление ИТ-активами; непрерывность и критичность систем. Обоснуйте ответ одним предложением:
Для каждой ситуации задайте себе два вопроса: что именно пошло не так и какой контроль должен был это предотвратить. Ответ на второй вопрос обычно сразу указывает на нужную особенность.
1. Данные для входа на новые серверы администратор отправляет разработчикам в мессенджере.
2. Через год выяснилось, что часть серверов не принадлежит ни одной команде.
3. Регулятор запросил перечень систем с персональными данными клиентов, и банк собирал его три недели.
4. Серверы создаются в любое время, без оценки влияния на соседние сервисы и без согласования окна работ.
5. При создании серверов никто не выясняет, насколько важен новый сервис и как его восстанавливать после сбоя.
Задание 2: Проектирование контролируемого процесса
Выполните ключевую работу ИТ-методолога-аналитика:
1. Анализ рисков: выпишите 3 конкретных риска текущего процесса для банка.
Формулируйте каждый риск по схеме «если..., то...»: не «плохо с безопасностью», а «если данные для входа остаются в мессенджере, то ими может воспользоваться посторонний, и это приведёт к утечке». Так видно и причину, и последствие, а без последствия риск не убедит руководство.
2. Проектирование TO BE: опишите укрупнённую схему процесса TO BE в нотации BPMN 2.0 (например, пулы: Команда разработки, ИТ-инфраструктура, Служба ИБ, Система заявок и реестр активов) и отметьте на ней минимум 4 контрольные точки.
Контрольная точка – место, где процесс проверяет, что можно двигаться дальше: согласование, проверка, обязательная запись. Для каждой точки ответьте на три вопроса: кто проверяет, что именно проверяет и что происходит при отказе. Двигайтесь от начала к концу, как и в прошлом уроке, а развилки (шлюзы) ставьте там, где путь зависит от условия.
3. Баланс контроля и скорости: предложите, какие запросы можно пустить по упрощённому пути и что при этом должно остаться обязательным.
Подумайте, какие запросы повторяются из раза в раз (серверы с типовыми параметрами), какие системы малокритичны (тестовая среда без реальных данных клиентов) и без чего нельзя обойтись при любом пути. Идея в том, чтобы строгость процесса соответствовала риску: чем он выше, тем больше проверок.
Часть 5. Ключи к заданию (для самопроверки)
Сравнивайте свои ответы с ключами только после того, как выполнили оба задания. Совпадение формулировок слово в слово не требуется: важно, чтобы совпал смысл. Если Ваш ответ отличается, разберитесь почему, прежде чем исправлять его: многие ситуации затрагивают сразу несколько особенностей, и Ваш вариант тоже может быть верным.
Ключи к Заданию 1: 1 – информационная безопасность и разделение полномочий (данные для входа нельзя передавать по незащищённым каналам), 2 – управление ИТ-активами (у ресурса нет владельца и учёта), 3 – регуляторные требования и аудит (нет возможности быстро подтвердить, что и где хранится), 4 – управление изменениями (нет оценки влияния и окна работ), 5 – непрерывность и критичность систем (не определены важность сервиса и требования к восстановлению).
Разберём каждый ответ. В первой ситуации главный риск – утечка: мессенджер не предназначен для передачи учётных данных, и любой, кто получит доступ к переписке, получит доступ к серверам. Во второй ситуации виноват не администратор, а процесс: ни при заказе, ни при выдаче не требовалось назначить владельца, поэтому серверы остались без хозяина, без обновлений и без контроля расходов. Третья ситуация показывает, зачем нужен единый реестр: в нём перечень систем с персональными данными собирается за час, а не за три недели. Заметьте, что она связана и со второй: причина в том, что учёт ведётся плохо, а последствие проявляется в общении с регулятором.
В четвёртой ситуации администратор создаёт серверы, не зная, что они могут нарушить работу соседних сервисов, и делает это в любое время, в том числе в пиковую нагрузку. Для этого и существуют оценка влияния и окно работ. В пятой ситуации нет ответа на вопрос, насколько система важна. Без него нельзя определить ни строгость согласования, ни требования к резервному копированию, ни приоритет при сбое.
Ключи к Заданию 2 (ожидаемые риски): утечка или компрометация учётных данных, переданных в мессенджере; серверы без владельца, обновлений и оплаченных лицензий; невозможность быстро ответить на запрос регулятора или аудитора; сбои соседних сервисов из-за неконтролируемых изменений; долгое восстановление сервиса без плана и без понимания его важности. Достаточно трёх любых, сформулированных с последствием.
Ключи к Заданию 2 (ожидаемые контрольные точки): 1. Заявка оформляется в системе с обязательными полями: назначение, владелец, критичность, перечень данных. 2. Руководитель подтверждает необходимость. 3. Служба ИБ проверяет заявки на системы с данными клиентов. 4. Оценивается влияние на другие системы и согласуется окно работ. 5. До выдачи ресурса автоматически создаётся запись в реестре активов с указанием владельца.
Посмотрите на логику схемы. Процесс начинается с заявки в системе, а не с письма: это даёт аудиторский след и обязательные поля, из которых позже складывается реестр. Дальше идут развилки. Шлюз «Система работает с данными клиентов?» направляет заявку на проверку ИБ или минует её. Шлюз «Нужны нестандартные параметры?» решает, согласуются ли изменения в полном порядке. Важно, что запись в реестр стоит перед выдачей ресурса: тогда забыть про неё невозможно, ведь без записи ресурс просто не выдаётся. Каждая точка отвечает за свою особенность из Части 2: заявка и реестр – за аудит и учёт, ИБ и подтверждение руководителя – за безопасность и разделение полномочий, оценка влияния – за управление изменениями, поле критичности – за непрерывность.
Ключи к Заданию 2 (баланс контроля и скорости): упрощённый путь подходит для типовых серверов из заранее согласованного каталога, для малокритичных систем и для сред без реальных данных клиентов, например тестовых. При любом пути обязательными остаются владелец, запись в реестре активов и журнал действий.
Идея здесь в том, чтобы договариваться заранее, а не каждый раз. Если параметры стандартного сервера один раз проверили безопасность и инфраструктуру, то при каждом следующем заказе повторять эту проверку незачем: запрос оформляется и выполняется автоматически. Разбираться вручную приходится только с нестандартными заявками, где риск выше. А владелец, учёт и журнал не зависят от упрощения: они нужны всегда, потому что именно по ним банк отвечает перед аудитором и регулятором.
Часть 6. Ключевые выводы (Takeaways)
1. В банке ИТ-процесс нужен не только для того, чтобы сделать работу, но и чтобы доказать, что она сделана правильно.
Банк отвечает перед регулятором, аудиторами и клиентами, поэтому недостаточно выполнить действие правильно, нужно уметь показать, что оно выполнено правильно. Процесс, в котором след возникает сам (заявка, согласования, журнал), сильнее процесса, где всё держится на доверии к конкретному администратору.
2. Контроль и скорость не противоположности: решение – контроль, соразмерный риску.
Если одинаково строго проверять всё подряд, процесс становится медленным, и люди начинают его обходить, то есть контроль перестаёт работать. Если не проверять ничего, банк рискует деньгами и репутацией. Методолог ищет золотую середину: типовое и безопасное идёт по быстрому пути, критичное проходит полную проверку.
3. У каждого ресурса должны быть владелец, учёт и жизненный цикл.
Ресурс, о котором никто не помнит, превращается в источник затрат и рисков: за него платят, но не обновляют и не контролируют. Поэтому хороший процесс не заканчивается выдачей ресурса: он гарантирует, что у него есть хозяин, запись в реестре и понятный срок жизни. Запомните это правило, оно пригодится в каждом следующем уроке.