Особенности инфраструктуры

Инфраструктура крупных банков очень разнообразна и включает в себя до нескольких сотен IT-систем. Часть из них могут быть унаследованы, например, в результате слияний и поглощений. Некоторые ресурсы могут быть собственностью внешних компаний: например, банк сотрудничает с процессинговой организацией, и работникам банка нужен доступ во внешние системы контрагента. Также в структуру финансовых компаний входит много разнообразных тестовых сред разрабатываемого самим банком программного обеспечения. Доступ в такие среды должен быть отделен от доступа в эксплуатируемую бизнес-среду. 

По сути, в инфраструктуре любого банка есть два контура информационных систем: 1) системы общего доступа — электронная почта, внутренний портал и т.п.; 2) системы ограниченного доступа, содержащие некую специализированную информацию, зачастую конфиденциальную. 

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

Кому в банке это нужно

Кто в банке заинтересован в повышении эффективности процессов управления доступом? Прежде всего бизнес, которому надо максимально оперативно получать права доступа в нужные информационные системы, чтобы выполнять поставленные бизнес-задачи. Сами бизнес-подразделения являются владельцами различных информационных систем (продажи «владеют» базами CRM, бухгалтерия — системой «1С: Бухгалтерия», юристы — «1С: Документооборот» и т.д.). Соответственно они как владельцы заинтересованы в работоспособности этих систем, в их готовности участвовать в связных бизнес-процессах, поэтому им небезразлично, кто и на каких основаниях имеет доступ к этим системам.

Вторая заинтересованная сторона — IT-подразделение, которое должно вовремя предоставить бизнесу необходимый доступ к запрашиваемым ресурсам, соблюдя SLA. Из-за перегрузки рутинными операциями по выдаче доступа IT-подразделение не только не успевает уложиться в отведенные сроки по предоставлению прав, но и совершенно не может выделять ресурсы на развитие инфраструктуры, утопая в выполнении потока заявок на предоставление/изменение доступа. 

И, наконец, третья заинтересованная сторона— служба безопасности, которая отвечает за снижение рисков. Для этого нужно всегда обеспечивать пользователей минимально достаточным доступом: вовремя его предоставить, вовремя аннулировать и следить за отсутствием лишних прав. Службе информационной безопасности (ИБ) приходится соблюдать различные требования регуляторов, предъявляемые к финансовой сфере (PCI DSS, СТО БР ИББС, ГОСТ Р ИСО/МЭК 27001, 152-ФЗ «О персональных данных» и др.), часть которых касается обеспечения безопасного доступа. Крупные банки проходят по 10–15 аудиторских проверок в год, частью которых является подтверждение обеспечения безопасного доступа к информации и информационным системам.

Какие задачи управления доступом решают банки

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

Для банков существуют специфические требования регуляторов, согласно которым доступ новых сотрудников к отдельным системам должен быть предоставлен не раньше первого официального рабочего дня. В ручном режиме очень сложно организовать работу так, чтобы доступы для всех новичков ко всему десятку систем были согласованы ровно ко дню их выхода на работу. И финансовые аудиторы очень строго проверяют соблюдение этого требования: нельзя без официального приказа пустить сотрудника в банковские системы ограниченного доступа.

При появлении в банке любой новой информационной системы необходимо, чтобы доступ к ней предоставлялся каждому сотруднику в соответствии с той должностью, которую человек занимает. То есть нужна ролевая модель управления доступом всех сотрудников ко всем системам банка, что на практике встречается редко. Часто бывает так: IT-департамент закупает новую информационную систему, которую нужно срочно ввести в эксплуатацию, о безопасности не думают — лишь бы система побыстрее начала работать, а ролевую модель потом выстроим… Об этом на год забывают, через год — сюрприз! Инцидент несанкционированного доступа. 

За создание и актуализацию ролевой модели, как правило, несет ответственность владелец ресурса, доступ к которому нужно предоставить. После создания модели ее нужно постоянно сопровождать, вносить изменения, поддерживать в актуальном состоянии. Делать это в ручном режиме крайне сложно — сотрудников, ролей и полномочий в крупном банке очень много.

Как правило, ролевые модели в большинстве банков представлены либо в бумажных документах, либо в компьютерных файлах, с которыми IT-специалисты вынуждены постоянно сверяться при каждом запросе на доступ. Со временем такая ролевая модель неизменно устаревает — появляются новые программы, новые сотрудники и отделы, меняются должности, а автоматического пересмотра ролевой модели не происходит. Автоматизированное же создание и ведение ролевой модели, к сожалению, в российских банках встречаются крайне редко.

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

Типичная для современного банка картина: наняли внешних сотрудников под временный проект, дали им какой-то доступ в какие-то системы, проект завершен, люди ушли, а доступ им закрыть забыли. Поскольку этих людей в кадровой базе банка нет, никакого сигнала об окончании их работы над проектом в IT-службу не поступает. Проблема остается на совести руководителя проекта, запросившего для аутсорсеров доступ. Но руководитель мог смениться или просто забыть о том, что нужно отозвать права. А во времена повсеместной «удаленки», когда и вовсе никуда физически приходить не надо, чтобы войти в системы, такое отношение к доступу создает гигантскую брешь в безопасности финансовой организации.

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

Наконец, очень актуальная задача для любого банка — работа с конфликтами полномочий (SOD-конфликтами). Прежде всего регуляторы требуют от банков, чтобы в одних руках не находились функции проведения и контроля финансовых операций. Но как быть с удаленными мини-отделениями, например, в продовольственном магазине в каком-нибудь маленьком городке или где-нибудь в сибирской тайге, где в отделении всего два человека — кассир и менеджер? Если, например, кто-то из них заболел, банк же не может закрыть отделение — иначе весь населенный пункт останется без финансовых услуг. В таком случае хочешь — не хочешь, а функции проведения и контроля операций приходится совмещать в одних руках. Значит, в правилах могут быть исключения, за которыми, тем не менее, нужно следить — и делать это эффективно можно только с помощью автоматизации.

Решение перечисленных задач отягчается одним обстоятельством: в 2020 году банковская сфера была признана лидером среди всех отраслей по объему текучести персонала.

В банках традиционно велико количество сотрудников, занимающих одинаковые должности, в особенности среди низкоквалифицированного персонала. Это порой десятки тысяч операционистов, которые не задерживаются долго на одной должности — либо уходят на повышение, либо увольняются. Каждому такому работнику при приеме надо оперативно создать учетные записи в нужных информационных системах, чтобы он мог быстро приступить к обслуживанию клиентов. И так же оперативно надо эти права менять (при переводе сотрудника) или блокировать (при увольнении). В крупных банках со штатом в десятки тысяч сотрудников ежедневно создается и блокируется несколько сотен учетных записей.

Как проблемы доступа решают без автоматизации

Без специализированных систем управления доступом (IDM/IGA) эти проблемы частично решают с помощью лоскутной автоматизации. Самое простое, с чего начинают все банки, — написание собственной программы блокировки учетных данных уволившихся сотрудников, чтобы быстро выполнить одно из наиболее критичных требований регуляторов. Вроде бы здорово — оперативно удалось решить задачу… Однако такая программа не сможет охватить всех пользователей: например, данных подрядчиков и внештатных сотрудников нет в кадровой базе, а доступы им выдаются.

Также для быстрого предоставления доступа и соблюдения SLA можно нанять в штат 50 системных администраторов. Правда, этим людям надо постоянно платить зарплату, и подсчет расходов на ФОТ и на IDM/IGA за требуемый на внедрение промежуток времени складывается не в пользу первого.

Кроме того, IT-службы крупных банков берут на вооружение системы IT Service Management, чтобы можно было контролировать свою собственную работу. Побочным направлением использования таких систем является обработка заявок пользователей на доступ к ресурсам банка. Однако такая система позволяет лишь автоматически получать заявку на доступ, а исполнение заявок ведется по старинке вручную.

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

Выход — автоматизированные системы управления доступом

С помощью IDM/IGA в компании формируется ролевая модель управления доступом — если ее нет и права выдаются спонтанно. В зрелой IDM/IGA-системе есть инструменты Role Mining, позволяющие анализировать все имеющиеся на данный момент в компании доступы и принимать решение, объединять ли их в роли или оставлять индивидуальными. На основании ролевой модели автоматизируются процессы предоставления и изменения базовых прав при наступлении определенных кадровых событий: прием на работу, перевод на новую должность или увольнение. 

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

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

Также IDM/IGA может запускать в организации автоматизированный пересмотр ролевой модели управления доступом. Система автоматически выгрузит все текущие роли, распределит их по владельцам информационных систем, те быстро проверят актуальность ролевой модели — не поменялась ли у них какая-либо функциональность. В случае необходимости в систему будут внесены данные об изменениях в правах доступа и ролях, и ролевая модель автоматически актуализируется в соответствии с изменениями.

Кроме того, развитая система автоматизированного управления доступом имеет эффективные механизмы контроля соблюдения правил ИБ организации. В ручном режиме сотрудникам службы ИБ, чтобы понять, кто из персонала имеет доступ в ту или иную систему, нужно делать запрос в IT-отдел о предоставлении отчета обо всех пользователях информационной системы и их правах. Составление, согласование формата и предоставление такого отчета может занимать несколько недель, учитывая загрузку IT-персонала.

В случае с IDM/IGA ИБ-специалисты имеют собственный инструмент контроля прав доступа и учетных записей персонала организации. Они могут самостоятельно составлять отчеты, проводить внутренние аудиты по ИБ в части управления доступом, инициировать пересмотры полномочий пользователей, расследовать инциденты.

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

Очень важной с точки зрения ИБ банков является возможность автоматического выявления и блокирования бесхозных и неиспользуемых учетных записей. Как в любых крупных организациях, в банках постоянно создается множество технических учетных записей, которыми посменно пользуются десятки администраторов. Если произошел инцидент, без IDM/IGA-системы крайне сложно разобраться, кто воспользовался этой учетной записью в конкретный момент. Централизованное решение по управлению доступом позволяет закрепить ответственность за каждую учетную запись, будь она личная или административная/техническая. Если вдруг появляется бесхозная «учетка», система сразу направляет предупреждение в службу ИБ. Определяется и закрепляется ее владелец, и он далее несет ответственность за все действия, совершенные от имени этой учетной записи.

Технологии автоматизированного управления доступом позволяют предупреждать возникновение конфликтов полномочий. IDM/IGA-система может сообщить пользователю, что запрашиваемые им права приводят к конфликту полномочий, или же вовсе не дать человеку оформить конфликтующие права.

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

Синергия с передовыми технологиями на службе у банков

IDM/IGA-системы — важная, но не единственная вещь, которая нужна банкам для выстраивания комплексной экосистемы автоматизации и безопасности управления доступом. Чтобы сделать доступ удобным, прозрачным и безопасным, IDM/IGA должен дополняться технологией многофакторной аутентификации и SSO (технологией единого входа в систему). Что это такое, расскажем на примере проекта, который был реализован в 2018 году в СДМ-банке.

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

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

Кроме того, в проекте СДМ-банка IDM/IGA-система была интегрирована со СКУД — системой контроля и управления доступом, реализующей доступ сотрудников на территорию банка с помощью электронного пропуска. При входе сотрудника по пропуску на территорию банка доступ к рабочим системам автоматически открывался, а при выходе за периметр — блокировался.

Также сегодня растет спрос финансовых компаний на технологии, комплексно решающие задачи ИБ. 

Для управления доступом к неструктурированным данным на рынке появились специальные технологии DCAP, позволяющие осуществлять проверку и контролировать доступ к данным в различных сетевых хранилищах, рассредоточенных по всей инфраструктуре компании. Скажем, где-то в открытом доступе и в совершенно разрозненном виде находятся различные конфиденциальные данные — здесь номера паспортов, а там — номера кредитных карт, а где-то еще — выгрузка из CRM или данные из протокола конкурсной комиссии и т.п. Для обеспечения безопасности такой информации целесообразно использовать комплекс технологий IDM/IGA и DCAP. DCAP поможет обнаружить конфиденциальные данные в общих массивах неструктурированной информации, разбить их на категории и поместить в соответствующие каждому типу данных хранилища, доступ к которым будет контролировать и защищать IDM/IGA.

Привилегированные учетные записи, имеющие слишком высокий уровень прав, технические «учетки», которые применяются для администрирования, всегда несут повышенный риск для бизнеса. Учетные записи: «root», «admin», «system» часто используются несколькими сотрудниками IT-отдела. Поэтому для надежного и эффективного управления и мониторинга привилегированного доступа в финансовых компаниях востребованы инструменты PAM (Privileged Access Management). Они определяют правила и сроки использования привилегированных «учеток», позволяют отслеживать и записывать все сеансы работы с ними, выявлять любые аномалии в их поведении. Совместное использование решений IdM/IGA и PAM позволяет собрать воедино все данные о пользователях и учетных записях. Такая синергия помогает контролировать работу на основании утвержденной политики компании как с общими стандартными правами, которые используют бизнес-подразделения, так и привилегированными пользователями, которые занимаются администрированием приложений.

Послесловие

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

Мы поделились основными сценариями использования IDM/IGA, которые помогут решить подобные задачи и в вашей организации.