Сотрудник крупного предприятия держит в голове десяток адресов: бухгалтерская система, кадровый учёт, заявки в ИТ, документооборот, справочник телефонов, внутренние регламенты. К каждому – свой логин. Половину паролей он записывает на стикерах. Корпоративный портал убирает этот хаос: одна точка входа, одна аутентификация, единый каталог сервисов. Для госучреждения, где счёт пользователей идёт на тысячи, а требования к учёту доступа диктует регулятор, такая консолидация – не удобство, а необходимость.

Что портал решает на самом деле

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

Под капотом это означает интеграцию. Портал сам почти ничего не хранит – он обращается к учётным системам, к каталогу LDAP или Active Directory, к серверам документооборота. Именно поэтому портальный проект на 70% состоит из работы со смежными системами и лишь на 30% – из вёрстки витрины.

Архитектура: витрина поверх работающего бэкенда

Типичная ошибка – начинать с дизайна страниц. Начинать надо с инвентаризации источников. Какие системы публикуют сервисы, по каким протоколам, кто отвечает за справочники пользователей. На рынке для этого складывается слой портальных платформ (Liferay, SharePoint, JBoss Portal) и стандарт портлетов JSR-168/286, который позволяет встраивать чужие приложения в общую раму без переписывания.

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

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

Безопасность: единая точка входа – единая точка риска

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

Вывод

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