Изоляция межкорпоративных данных и мультиарендная архитектура в проектировании баз данных ERP

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

Архитектура ERP и структура холдинга

При проектировании архитектуры ERP для группы компаний основная цель заключается в объединении операций различных юридических лиц под одной цифровой крышей с сохранением операционной независимости. Одной из фундаментальных концепций, возникающих в данном контексте, является структура арендатора (tenant). В сценариях с несколькими компаниями (multi-company или multi-tenant) на этапе проектирования базы данных можно выделить три основных подхода: раздельные базы данных, изоляция на основе схем и безопасность на уровне строк (Row-Level Security — RLS).

1. Подход с раздельными базами данных

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

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

2. Изоляция на основе схем

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

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

3. Безопасность на уровне строк (RLS)

Данные всех компаний хранятся в одних и тех же таблицах, однако к каждой строке добавляется идентификатор компании (tenant id). Благодаря правилам на уровне базы данных пользователи видят только те строки, на просмотр которых у них есть права.

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

Управление общими основными данными и процессы принятия решений

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

Гипотетический сценарий: Структура из трех компаний и реализация RLS

В этом сценарии мы рассматриваем то, как настроена модель безопасности на уровне строк (RLS) для холдинга, состоящего из трех различных юридических лиц, осуществляющих деятельность в сферах производства, логистики и розничной торговли. Руководство холдинга приняло решение использовать единую базу данных и общие таблицы с целью снижения всех операционных расходов и получения мгновенных отчетов о консолидированной прибыльности. Команда разработчиков начала работу с добавления колонки «tenant_id» в таблицы счетов-фактур, заказов и движения запасов. Когда производственная компания (Tenant A) входит в систему, вступают в силу правила безопасности на уровне базы данных, и независимо от уровня приложения фильтруются только строки, имеющие значение ID Tenant A. Благодаря этому сотрудники розничной компании никоим образом не имеют доступа к производственным данным.

Тем не менее, эта архитектура влечет за собой серьезные компромиссы в отношении коммерческой эффективности и производительности. Если в таблице движений запасов с миллионами строк не настроено правильное индексирование, условие «WHERE tenant_id = X», автоматически добавляемое к каждому запросу, создает нагрузку на движок базы данных и увеличивает затраты на планы выполнения (execution plan). С точки зрения управления ошибками, сценарии катастроф могут возникнуть в случае забывчивости или неправильной настройки контекста арендатора (tenant context), отправляемого с уровня приложения; поскольку при пропуске правил RLS данные всех компаний могут перепутаться. Чтобы устранить эти риски, управление пулом соединений базы данных (connection pooling) должно строго контролироваться, а автоматические тесты на проникновение должны запускаться в каждом спринте.

Контрольный список внедрения изоляции базы данных ERP

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

1. Анализ правовых и финансовых требований: Местные законы о хранении данных тех стран, где ведут деятельность компании, должны быть предварительно изучены на предмет того, требуют ли они обязательного наличия раздельных баз данных.
2. Стандартизация идентификаторов арендаторов: Во всех таблицах должны быть определены колонки арендаторов с оптимизированным типом данных (например, UUID или Integer), совместимым со структурой первичных ключей.
3. Кодирование политик базы данных: Безопасность на уровне строк (RLS) или полномочия на основе схем должны обеспечиваться непосредственно на уровне базы данных (хранимые процедуры и политики безопасности), а не перекладываться на код приложения.
4. Управление пулом соединений и контекстом: Во избежание утечек состояния сеанса или контекста соединения в мультиарендных архитектурах сеансы базы данных должны сбрасываться после каждого запроса.
5. Комплексное тестирование интеграции и нагрузки: Необходимо проверить, не снижают ли производительность механизмы изоляции при запросах больших объемов данных, поступающих одновременно от разных арендаторов.

Этот контрольный список представляет собой дорожную карту для минимизации архитектурных рисков, с которыми можно столкнуться в проектах Корпоративное ПО и ERP, а также для беспрепятственного прохождения процессов аудита.

Источники

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