Безопасность корпоративного портала: шифрование, аудит и изоляция данных

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

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

Из чего складывается безопасность корпоративного портала

Безопасность портала держится на нескольких независимых слоях. Если хотя бы один проседает, остальные не спасут. Минимальный набор, который должна закрывать платформа:

• Изоляция данных между разными компаниями (арендаторами).
• Шифрование данных там, где это критично, — прежде всего секретов и тома базы данных.
• Контроль доступа — кто и что может видеть и менять (RBAC, принцип наименьших привилегий).
• Аудит-лог и журнал сессий — кто, когда и откуда выполнял действия.
• Управляемая аутентификация — SSO, принудительный вход через корпоративный провайдер.

Разберём каждый слой так, как он реализован в TeamHero, без маркетинговых преувеличений.

Изоляция данных: schema-per-space

Главный страх любой службы безопасности при работе с облачным сервисом — «а что, если данные одной компании утекут к другой». В TeamHero за это отвечает архитектура multi-tenant по модели schema-per-space.

Каждой компании (space) выделяется отдельная схема в базе данных. Это значит, что таблицы с новостями, сотрудниками, комментариями и вложениями одного клиента физически лежат в собственной схеме и не пересекаются с данными другого клиента на уровне запросов. Запрос, выполненный в контексте одной компании, не может «случайно» зацепить строки другой — изоляция обеспечивается границами схемы, а не только фильтром WHERE company_id = ..., который легко забыть проставить.

Поверх этого работает шифрование тома базы данных на уровне инфраструктуры: физические файлы хранилища зашифрованы, и доступ к диску сам по себе не даёт читаемых данных.

Важно быть честным в формулировках: это не «каждое поле в базе зашифровано отдельным ключом». Это изоляция арендаторов по схемам плюс шифрование тома at-rest. Такой подход закрывает реалистичные сценарии угроз — компрометацию диска, ошибку cross-tenant выборки — и при этом не ломает производительность, как это делает пополевое шифрование всего подряд.

Шифрование данных: секреты SSO at-rest

Отдельно стоит поговорить про шифрование данных, потому что вокруг этого слова много путаницы. В TeamHero шифрование at-rest целенаправленно применяется к самой опасной категории — секретам интеграций.

Когда вы настраиваете единый вход (SSO), портал хранит client_secret вашего провайдера, SAML-сертификаты и другие учётные данные интеграций. Если эти секреты утекут, злоумышленник сможет выдать себя за ваш портал перед Okta или Azure AD. Поэтому такие значения шифруются алгоритмом Fernet (AES-256) перед записью в базу: даже при доступе к строкам таблицы секрет остаётся нечитаемым без ключа шифрования.

Ключ шифрования хранится отдельно от данных — в окружении сервиса, а не в самой базе. Это разделение «данные в одном месте, ключ в другом» — базовое требование к корректному шифрованию секретов.

Итого по слою шифрования стоит запомнить две вещи:

1. Секреты SSO (client_secret, SAML-сертификаты) — шифруются Fernet/AES-256 at-rest.
2. Том базы данных — шифруется на уровне инфраструктуры.

Этого достаточно, чтобы закрыть ключевые риски, и честнее, чем расплывчатое «у нас всё зашифровано».

Аудит-лог и журнал сессий: кто, когда и откуда

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

В TeamHero ведётся два связанных журнала:

• Аудит-лог действий — кто и что сделал: создал и удалил пользователя, изменил роль, поменял настройки доступа, выгрузил данные. Это та самая «лента ответственности», по которой можно понять, кто инициировал изменение.
• Журнал сессий — кто, когда и откуда вошёл: время входа, источник. Это помогает заметить аномалию — например, вход из неожиданной геолокации или всплеск активности под одной учёткой.

Связка «аудит-лог + журнал сессий» закрывает базовое требование любого внутреннего регламента ИБ: действия не анонимны, их можно проследить до конкретного пользователя и сессии. Это же — основа для расследований и для выполнения требований по защите данных сотрудников в рамках 152-ФЗ, где важна подотчётность обработки персональных данных.

Контроль доступа: RBAC и принцип наименьших привилегий

Даже самый защищённый портал станет проблемой, если все сотрудники видят всё. Поэтому доступ в TeamHero строится на RBAC (ролевой модели) с опорой на принцип наименьших привилегий: пользователь получает ровно те права, которые нужны для его задачи, и не больше.

Права привязаны к ролям, роли — к зонам ответственности. Администратор пространства, контент-менеджер, рядовой сотрудник видят разный объём данных и имеют разный набор действий. Это снижает «радиус поражения» при компрометации одной учётной записи: украденный доступ рядового пользователя не открывает административную панель.

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

Управляемая аутентификация: SSO и принудительный вход

Чем меньше отдельных паролей, тем меньше поверхность атаки. TeamHero поддерживает корпоративный единый вход через SSO — Okta, Azure AD и стандарт SAML. Это позволяет сотрудникам входить под той же учётной записью, что и в остальные корпоративные системы, а ИБ-команде — централизованно управлять доступом из своего провайдера.

К SSO прилагаются два важных механизма:

• JIT-провижининг (Just-In-Time) — учётная запись в портале создаётся автоматически при первом входе через корпоративный провайдер, на основе данных из него. Не нужно вручную заводить и синхронизировать пользователей.
• Принудительный SSO (enforce) — режим, при котором вход возможен только через корпоративный провайдер. Локальные пароли отключаются, и сотрудник не может обойти политики вашего IdP (MFA, условный доступ, блокировки). Для службы безопасности это ключевая настройка: она гарантирует, что портал не станет «дырой в обход» корпоративной аутентификации.

Чек-лист: что спросить у вендора про безопасность

Чтобы оценка не свелась к «у них на сайте написано secure», задайте поставщику конкретные вопросы. Вот рабочий список:

• Изоляция: как разделяются данные разных компаний — на уровне схемы/базы или только фильтром в коде? Зашифрован ли том базы данных at-rest?
• Шифрование: какие именно данные шифруются (секреты, том, поля)? Какой алгоритм? Где хранится ключ — отдельно от данных?
• Секреты интеграций: как хранятся client_secret и сертификаты SSO — в открытом виде или зашифрованными?
• Аудит: есть ли журнал действий администраторов? Фиксируются ли входы (кто, когда, откуда)? Можно ли выгрузить эти логи?
• Доступ: поддерживается ли RBAC и гранулярные роли? Реализован ли принцип наименьших привилегий по умолчанию?
• Аутентификация: есть ли SSO (SAML/Okta/Azure AD)? Можно ли включить принудительный вход и отключить локальные пароли? Поддерживается ли JIT-провижининг?
• Интеграции: как устроены API-ключи, можно ли их отзывать независимо от пользователей?
• Соответствие: как платформа помогает выполнять требования 152-ФЗ по защите персональных данных сотрудников?

Если вендор отвечает на эти вопросы конкретикой — «изоляция по схемам, секреты шифруются AES-256, аудит выгружается, enforce SSO есть» — это хороший знак. Если отделывается общими словами «всё надёжно зашифровано» — стоит копнуть глубже.

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