Перейти к содержимому. | Перейти к навигации

Персональные инструменты
Вход Регистрация
Вы здесь: Главная БЛОГИ Александр Астахов Архитектура GRC-систем. Часть 1
Protectiva Compliance Manager
Навигация
 

Архитектура GRC-систем. Часть 1

Автор: Александр Астахов опубликовано: 19-10-2021 последнее изменение: 19-10-2021

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

Введение в GRC

Governance, Risk management and Compliance (GRC) - это взгляд на управление чем-либо с трёх точек зрения: высшего руководства (Governance), управления рисками (Risk management) и соответствия требованиям (Compliance). Любую деятельность можно разложить по этим трём составляющим. Подробнее о том, чем Governnance отличается от менеджмента написал в отдельном посте по ссылкеManagement vs Governance. В чем различие?

GRC система позволяет повысить эффективность решения, в том числе, следующих задач:

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

Сходство и различие между GRC и ERP

Прежде всего, разберемся в чем заключается отличие GRC-систем от сильно похожих на них ERP-систем. И те и другие предназначены для автоматизации внутренних процессов организации. И те и другие имеют схожую архитектуру, программную платформу, настраиваемые workflow, внутренние языки и безъязыковые средства разработки, наборы приложений для решения различных специфических задач из разных областей деятельности и т.п. Разница по сути заключается в видах и уровне автоматизируемых процессов.

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

Основные компоненты GRC системы

Платформа

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

Решение

Решения представляют собой пакеты приложений, объединённых для выполнения конкретной бизнес задачи, например, управления рисками, соответствием или внутренним аудитом. Так решение по управлению политиками может включать в себя следующие приложения: Политики, Базовые уровни защищенности (или соответствия), Стандарты, Источники. Функции, архитектуру и названия приложений придумывают сами разработчики, поэтому они могут быть какими угодно.

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

Решения также могут объединяться в пакеты, которые называются Сценариями использования. Например, типовой сценарий IT Security and Risk Management включает в себя решения по управлению ИТ инцидентами, уязвимостями, рисками, комплайенсом и т.п.

Сценарий использования

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

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

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

Приложение

Приложение служит контейнером для определенных типов записей, таких как инциденты, контроли, политики, активы и т.п. Приложение определяет контент и поведение записей. Например, Контакты, Задачи, Оповещения, Назначения или ИТ-активы.

Опросник

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

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

Интерфейсы

Back Office и Front Office

Пользовательский веб интерфейс (Web UI) состоит из двух областей:  Back Office и Front Office. В Back Office администраторы создают экземпляры объектов для различных сущностей GRC-платформы. В Front Office конечные пользователи работают с различными представлениями этих объектов. Другими словами в Back Office мы имеем дело со списками приложений, полей, макетов, форм и т.п., а в Front Office – со списками рисков, бизнес подразделений, уязвимостей и т.п.

Web Services API

Web Services API представляет собой набор веб-сервисов для взаимодействия с внешними приложениями по протоколу HTTPS, а также для обмена данными между различными приложениями в рамках единой физически распределенной платформы.

RESTful

RESTful (Representational State Transfer) – это упрощенная альтернатива SOAP сервисам. Сервисы RESTful позволяют пользователю работать с данными GRC-платформы.RESTful с ервис представляет собой набор ресурсов, объединенных в функциональные сегменты, доступ к которым осуществляется через контроллеры. Действия над ресурсами можно производить как в индивидуальном порядке, идентифицируя ресурс по ключу и идентификатору, так и в пакетном режиме. RESTful API использует формат JavaScript Object Notation (JSON) по умолчанию для запросов и ответов, но также поддерживается и XML. После идентификации ресурса над ним могут быть выполнены операции Создание, Чтение, Удаление с использованием стандартных HTTP методов, таких как POST, GET, PUT, PATCH, и DELETE.

Platform API

Интерфейсы Platform API служат для работы с Back Office и используется администраторами для автоматизации различных операций с объектами GRC-платформы.

Content API

Интерфейсы Content API служат для работы с Front Office и выполняют трансляцию метаданных и контента, конвертируя их в логические сущности, с которыми можно работать в пользовательском интерфейсе. Данные различных записей разбросаны по базам данных Back Office, но при просмотре их через Front Office, пользователи видят все эти данные на одном экране в заданном формате.

Продолжение следует ....

Comments (0)

Как стать участником |  Что может участник  |  Как работать с порталом  |  Реклама |  Авторские права  |  Контакты  |  Конкурсы  |  RSS  |  Форум
©2003 - 2021 GlobalTrust
Рейтинг@Mail.ru Rambler's Top100 Yandex