ERP-архитектура и изоляция данных для многокомпанейских структур

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

1. Определение стратегии изоляции данных

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

• Разделение физических баз данных: Для каждой компании создается полностью независимый экземпляр (instance) базы данных. Это обеспечивает наивысший уровень изоляции, однако затраты на оборудование и обслуживание высоки.
• Изоляция на уровне схем: На едином сервере баз данных для каждой компании используются отдельные схемы. Структуры таблиц управляются совместно, но данные разделяются логически.
• Архитектура общих таблиц (Tenant ID): Все данные хранятся в одних и тех же таблицах, а фильтрация выполняется на уровне строк (Row-Level Security).

2. Проектирование схем и управление общими объектами

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

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

3. Авторизация и контроль доступа

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

4. Уровень консолидации и отчетности

Даже если данные разных компаний изолированы, создание консолидированной отчетности для высшего руководства является обязательным требованием. На этом этапе настраиваются специальные запросы и процессы ETL, работающие на уровне базы данных или на уровне хранилища данных (Data Warehouse). Централизованные финансовые отчеты формируются с правами только для чтения без нарушения правил изоляции.

5. Гипотетический пример работы: Структура из трех компаний под зонтиком холдинга

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

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

6. Подробный контрольный список реализации для многокомпанейской ERP-архитектуры

Для минимизации технических рисков и предотвращения утечек данных при запуске многокомпанейских ERP-проектов в промышленную эксплуатацию необходимо в полном объеме выполнить следующие шаги:

• Выбор архитектуры: Необходимо проанализировать законодательные требования, объемы данных и бюджеты компаний, чтобы четко определить модель физической, схемной или построчной изоляции.
• Развертывание базы данных и схем: Tenant ID и ключи компании должны быть добавлены во все операционные таблицы в качестве обязательных полей, а индексация должна быть оптимизирована по этим ключам.
• Матрица доступа и полномочий: С помощью ролевого контроля доступа (RBAC) на уровне базы данных и приложения должен быть заблокирован доступ пользователей к данным за пределами границ их компаний.
• Процессы интеграции и ETL: Для межфирменных перевозок товаров и консолидированной отчетности должны быть спроектированы безопасные, зашифрованные API и конвейеры ETL (pipelines).
• Управление ошибками и сбоями: Для обрывов соединений с базой данных или попыток несанкционированного доступа должны быть созданы механизмы мгновенного логирования и системы оповещений.
• Тестирование производительности и нагрузочное тестирование: Следует провести комплексные стресс-тесты для наблюдения за поведением системы в условиях одновременной отчетности по нескольким компаниям.

Источники

• Корпоративное ПО и ERP — Cy Logic Software