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

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

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

Такой разрозненный метод создавал ряд серьезных проблем.

• Невозможность отслеживания истории доступов: было практически нереально узнать, кто и когда имел доступ к определенным ресурсам.

• Отсутствие прозрачности в процессе согласования: история согласований (кто и когда одобрил доступ) была не отслеживаемой.

• Сложности с отзывом временного доступа: своевременное прекращение временных разрешений стало практически невыполнимой задачей.

Эти проблемы не только снижали эффективность работы ИТ-отдела, но и создавали серьезные риски для информационной безопасности (ИБ) компании. Стало очевидно, что требуется комплексное решение, которое могло бы унифицировать и автоматизировать процессы управления доступом across всех информационных систем.

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

Что хотел заказчик

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

Каждая из десяти ИС имела свой уникальный набор атрибутов для заявок на доступ. Например:

• для файлового сервера требовалось указывать имена сетевых папок;

• в случае с 1С необходимо было определить перечень ролей и баз данных;

• для корпоративных справочников важно было указать категории и области доступа.

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

• Усложнение администрирования. ИТ-отделу пришлось бы поддерживать десять различных процессов, что увеличило бы нагрузку и риск ошибок.

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

• Сложности с масштабированием. При добавлении новых систем потребовалась бы разработка новых форм и процессов с нуля.

• Отсутствие централизованного контроля. Разрозненные процессы затруднили бы общий мониторинг и аудит доступов.

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

Этап проектирования: начало работ и предложения по решению задач заказчика 

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

• Неполнота исходных требований. Заказчики часто не могут сформулировать все свои потребности на начальном этапе проекта.

• Недооценка роста. Клиенты могут неправильно оценить масштабы будущего роста своих процессов и систем.

• Эволюция процессов. Любой бизнес-процесс со временем развивается, что приводит к появлению новых требований.

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

• Создать универсальный справочник ресурсов. Например, базы данных, сетевые папки.

• Разработать универсальный справочник ролей: «бухгалтер», «кладовщик», «читатель» и т.д.

• Связать ресурсы и роли между собой и с информационной системой. Это нужно, чтобы при выборе ИС видеть только роли и области соответствующей ИС.

• Добавить необязательный атрибут «Владелец» у ролей, ресурсов, ИС, который участвует в согласовании, если атрибут заполнен.

• Внедрить справочник согласующих: ИТ-директор, финансовый директор, архитектор и т.д.

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

• Настроить процедуры автоматического ведения реестра доступов, запись в котором формируется при подаче заявки. Запись реестра должна содержать информацию об ИС, ресурсе, роли, сроке действия, заявке на предоставление и отзыв. После исполнения заявки автоматически актуализируется запись реестра доступов.

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

• При блокировке учетной записи AD настроить автоматическое создание заявки на отзыв доступа к ресурсам, доступ к которым осуществляется не по доменной учетной записи. И аналогично для временного доступа при истечении периода доступа.

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

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

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

Перед угрозой потери важного контракта инженеры Intel предложили решение: вместо создания узкоспециализированных микросхем использовать один центральный процессор. Заказчик, японская компания Busicom, одобрил эту идею.

Результатом стал Intel 4004 – первый в мире коммерчески доступный микропроцессор общего назначения. Этот четырехбитный процессор, выпущенный в 1971 году, не только удовлетворил потребности заказчика, но и открыл новую эру в истории вычислительной техники. 

Микропроцессор при размере кристалла 3×4 мм мог выполнять порядка 60 000 инструкций в секунду (для сравнения: один из первых полностью электронных компьютеров ENIAC выполнял только до 5000 инструкций в секунду, занимал 280 м² и весил 27 тонн. Компания Intel предугадала решающее значение микропроцессоров в миниатюризации компьютеров и выкупила у фирмы Busicom авторские права на микропроцессор 4004 за 60 000 долларов. 

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

https://ru.wikipedia.org/wiki/Intel_4004

Особенности работы с медленно изменяющимися значениями 

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

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

Новые требования заказчика, которые практически не увеличивали трудозатраты из-за грамотного проектирования

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

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

Перед командой встал выбор между двумя вариантами реализации:

• создание одного усложненного маршрута согласования, который бы учитывал все возможные сценарии;

• формирование отдельного набора голосов для каждого запрашиваемого доступа.

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

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

С какими проблемами столкнулась команда «ЛАНИТ-Интеграции»

Каждая из непредвиденных трудностей существенно повлияла на ход работ и потребовала дополнительных ресурсов.

1. Значительно увеличились трудозатраты из-за ошибочной первоначальной оценки сложности одного из модулей системы. На этапе проектирования мы поняли, что придется разрабатывать большое количество функционала с нуля, а именно виджеты. Разработка этих виджетов велась на платформе SimpleOne.

Итак, мы выбрали SimpleOne, потому что она задумана и создана именно как платформа, а не отдельный программный продукт с ограниченной гибкостью. 

Платформа состоит из трех основных слоев.

• Нижний слой – базовые low-code инструменты (визуальные редакторы процессов, конструкторы условий, механизмы импорта данных и другие фундаментальные компоненты).

• Средний слой – набор встроенных инструментов Enterprise Service Management (ESM), включая управление услугами, продуктами, контрактами, потребностями и другими сущностями, необходимыми для создания бизнес-приложений.

• Верхний слой – готовые бизнес-приложения и продукты, предлагаемые вендором (ITSM, ITAM, SDLC, CRM, HRM и другие). Эти продукты используют возможности нижележащих слоев платформы и бесшовно интегрированы друг с другом.

А теперь будет несколько информационных справок, чтобы вы, читатели, лучше понимали контекст. 

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

Пользовательский интерфейс или портал – один из каналов связи для подачи обращений. На портале пользователю доступен личный кабинет, в котором он может отслеживать статус обработки его обращений, общаться с исполнителями, просматривать информацию о своих КЕ, читать статьи, базы знаний и др.

Обобщая, исполнительский интерфейс – это все, что находится «под капотом» системы, в то время как пользовательский портал – симпатичная и удобная «обертка».

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

А теперь, что такое виджеты.

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

Если говорить о специфике виджетов в SimpleOne, то следует рассказать об их архитектуре: любой виджет состоит их четырех компонентов: HTML-шаблона, CSS-стилей, серверного и клиентского скриптов. Виджет отправляет, получает и обрабатывает события через клиентский и серверный контроллеры.

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

В виджете прописаны все вышеуказанные алгоритмы:

• логика фильтрации справочников с областями и ролями в контексте информационной системы;

• логика срочных и бессрочных доступов; 

• подсказки для пользователей по заполнению; 

• проверка итогового содержимого на дубликаты;

• автоматическое создание записей в реестре доступов.

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

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

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

• список согласующих,

• статусы согласований.

Что же в итоге получил заказчик?

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

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

• Постоянно обновляемый и актуальный каталог доступных ресурсов и ролей.

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

• Функционал запроса доступов по аналогии с ролями других сотрудников, упрощающий процесс назначения прав.

• Повышение прозрачности процесса управления доступами в масштабах всей компании.

• Автоматизированная система управления временными доступами для сотрудников подрядных организаций и штатного персонала.

Краткие выводы

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

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

• Стратегическое развитие ИТ-систем нужно продумывать на начальных этапах проекта и предусматривать их при реализации проекта.

• Систематизация требований и пожеланий заказчика перед началом проектирования значительно снижает риски переделок и улучшает качество конечного продукта. 

• Приоритет качественного проектирования. Поверьте, ошибки на этапе проектирования обходятся компаниям значительно дороже, чем ошибки внедрения.

• Документация и поддержка. Рекомендуем внедрять практики «документирования для будущего», обеспечивая такой уровень детализации и структурирования информации, который позволит разобраться в системе даже через год после завершения проекта.

• Углубленное понимание потребностей клиента. Простая фиксация озвученных пожеланий уже не отвечает требованиям современного рынка. Важно вести активный диалог с заказчиком.

• Визуализация как инструмент коммуникации. Используйте диаграммы, прототипы и макеты для демонстрации концепций и получения обратной связи от заказчика.

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

Статья написана в соавторстве с @daen_izae.