SSO под другим углом

Продолжая работать над проектом SSO, всё чаще замечаю одну интересную вещь. Практически любой разговор про системы единого входа очень быстро сводится к логину, паролю, токенам, OAuth, OpenID Connect и другим вещам, которые так или иначе относятся к авторизации.

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

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

И самое интересное — все эти задачи объединяет вовсе не авторизация. Их объединяет точка, в которой они возникают. Пользователь в любом случае проходит через SSO.

Получается, что SSO — это не только сервис, который умеет подтвердить личность пользователя. Это ещё и единственная точка, через которую гарантированно проходит каждый сотрудник перед тем, как попасть в корпоративную систему.

А раз такая точка уже существует, возникает вполне логичный вопрос: почему бы не использовать её для чего-то большего?

В этой статье хочу посмотреть на SSO именно под таким углом. Не со стороны способов входа и сравнения протоколов, а со стороны двух задач, которые могут заметно изменить архитектуру корпоративных систем:

1. SSO как единый поставщик данных о пользователе.

2. SSO как точка дополнительной обработки в процессе авторизации.

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

Все привыкли думать, что SSO — это вход

Начнём с самого простого примера.

Допустим, в компании есть корпоративный портал, система управления задачами, база знаний, CRM и несколько внутренних сервисов. Без SSO пользователь должен отдельно входить в каждую систему. С SSO он проходит авторизацию один раз, после чего приложения доверяют результату этой проверки.

В этом и заключается привычная роль SSO.

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

На этом объяснение обычно заканчивается.

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

И вот здесь граница между «системой входа» и полноценным инфраструктурным компонентом начинает постепенно исчезать.

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

Почему именно SSO?

На первый взгляд может показаться, что все дальнейшие задачи можно решить и без SSO:

• Нужны данные сотрудника — приложение может обратиться в кадровую систему;

• Нужно проверить доступ — приложение может вызвать сервис политик;

• Нужно записать событие входа — приложение может отправить его в аудит;

• Нужно выполнить скрипт — можно встроить его непосредственно в приложение.

Технически всё это действительно возможно. Проблема начинается, когда приложений становится не два, а двадцать. Или двести.

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

Потом меняется API кадровой системы, структура подразделений или правила доступа. И одно изменение приходится повторять во всех подключённых приложениях. То же самое происходит с аудитом, согласиями, дополнительными проверками и любой другой общей логикой.

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

Это не означает, что SSO должен превратиться в огромный монолит, который знает обо всех процессах компании. Наоборот, его задача — стать понятной точкой подключения внешних источников данных, политик и обработчиков.

И здесь мы подходим к первому большому кейсу.

SSO как единый поставщик данных

Представьте обычный корпоративный портал.

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

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

Часть информации может храниться в Active Directory, должность и подразделение — в кадровой системе, проекты — в системе управления ресурсами, уровень допуска — в IDM, контакты — во внутреннем справочнике, а временные разрешения могут находиться вообще в отдельной базе.

Если портал начнёт получать всё это самостоятельно, он быстро перестанет быть просто порталом. Внутри появятся коннекторы, очереди, кэш, расписание синхронизации, повторные запросы и обработка десятка возможных ошибок. А ведь рядом есть CRM, Service Desk, база знаний и другие приложения, которым нужны примерно те же данные.

Получается знакомая схема:

Количество связей растёт намного быстрее количества систем.

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

Теперь посмотрим на ту же задачу под другим углом:

SSO собирает необходимый пользовательский контекст и передаёт его подключённым системам в виде claims — утверждений о пользователе.

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

Оно доверяет не каждому источнику отдельно, а установленному процессу формирования токена.

Не единая база, а единая точка доверия

Здесь важно не попасть в ловушку определения «единый источник истины».

SSO не обязательно должен физически хранить все данные пользователя. Более того, часто это будет плохим решением. Кадровая система должна оставаться владельцем кадровых данных, IDM — владельцем информации о доступах, а внутренний справочник — владельцем контактных данных.

Роль SSO в другом. Он может стать единой точкой, через которую приложения получают подтверждённый пользовательский контекст. То есть не единой базой данных, а единой точкой доверия.

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

Простой пример с электронной визиткой

Одним из самых понятных примеров может быть сервис электронных визиток.

Пользователь входит в сервис, а тот получает из SSO имя, должность, подразделение, телефон, фотографию и другие разрешённые поля. На основе этих данных автоматически формируется визитка.

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

Если сотрудник сменил должность или подразделение, изменения появляются без отдельной синхронизации именно с сервисом визиток.

На практике таким же образом можно строить не только визитки:

• автоматически заполнять профиль на корпоративном портале;

• назначать стартовый набор ролей в приложении;

• определять подразделение для маршрутизации заявки;

• показывать пользователю доступные внутренние ресурсы;

• подставлять руководителя в процесс согласования;

• формировать контекст для аудита и аналитики.

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

Централизация не должна означать бесконтрольную раздачу полного профиля пользователя.

А если данные принадлежат внешнему поставщику?

До этого момента мы подразумевали, что SSO сам получил сведения из LDAP или кадровой системы и просто добавил их в токен, как из источника профилей пользователей

Но есть и другой вариант.

Допустим, уровень допуска сотрудника рассчитывает отдельный сервис. SSO не является владельцем этих данных и не должен самостоятельно утверждать, что пользователь имеет определённый уровень доступа. Такое утверждение должен подписать именно тот поставщик, которому доверяют в этом вопросе.

В OpenID Connect для подобных случаев определены aggregated и distributed claims. В случае aggregated claims внешний поставщик формирует и подписывает набор утверждений, а OpenID Provider включает этот подписанный JWT в общий ответ. В случае distributed claims SSO передаёт ссылку на источник, откуда приложение может получить утверждения отдельно. Поддержка этих типов claims в OIDC является дополнительной, а не обязательной возможностью.

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

Для корпоративной среды это особенно интересно. Один поставщик может подтверждать статус сотрудника, другой — его допуски, третий — профессиональную квалификацию или право работать с конкретной системой.

SSO в такой схеме становится не владельцем всех данных, а агрегатором доверенных утверждений.

Что это даёт приложениям?

Главный результат — приложения перестают разбираться во внутреннем устройстве всей компании. Им не нужно знать:

• в какой версии кадровой системы хранится должность;

• каким способом IDM рассчитывает доступ;

• где находится профиль подрядчика;

• по какому API запрашивается филиал;

• как проверить подпись каждого внутреннего сервиса по отдельности.

Приложение знает набор claims, который оно может запросить и получить в процессе стандартной авторизации.

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

На этом можно было бы остановиться и сказать, что SSO стал удобным поставщиком пользовательского профиля. Но дальше — больше...

SSO как точка дополнительной обработки

Есть небольшой промежуток в процессе авторизации, который пользователь обычно даже не замечает. Он уже ввёл логин и пароль. Система уже поняла, кто перед ней. Но токен ещё не выдан, а авторизация не завершена. И вот в этот момент можно сделать гораздо больше, чем просто подтвердить личность пользователя.

Например:

• проверить, продолжает ли сотрудник работать в компании;

• убедиться, что вход разрешён из текущей сети;

• запросить решение у системы политик;

• потребовать дополнительный фактор аутентификации;

• показать обязательное соглашение;

• получить внешние claims;

• выполнить дополнительный обработчик или скрипт;

• записать расширенный контекст в аудит.

Получается своего рода конвейер авторизации:

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

Главная идея заключается в том, что приложения больше не обязаны реализовывать весь этот процесс самостоятельно.

Синхронная проверка: можно ли завершить вход?

Допустим, пользователь успешно подтвердил свою личность, но этого недостаточно для доступа к конкретной системе. Нужно проверить дополнительные правила.

Например:

• сотрудник должен состоять в определённом подразделении;

• подрядчику разрешён вход только до даты завершения договора;

• доступ из внешней сети возможен только с управляемого устройства;

• для финансовой системы требуется определённый уровень аутентификации;

• учётная запись не должна находиться под временным ограничением;

• вход разрешён только при низком уровне риска.

Такое решение удобно вынести в отдельный Policy Decision Point, или PDP — сервис, который получает контекст запроса и возвращает решение: разрешить или запретить действие.

SSO в этой схеме выступает как Policy Enforcement Point. Он не обязан хранить внутри себя все правила. Он спрашивает внешний PDP и исполняет полученный ответ.

Именно эту связь стандартизирует Authorization API 1.0 рабочей группы OpenID. AuthZEN: PEP отправляет запрос PDP и получает решение, которое может быть положительным или отрицательным. Отрицательное решение означает, что операция не должна продолжаться. Спецификация также позволяет вернуть дополнительный контекст — например, причину отказа или обязательные действия.

На уровне идеи всё выглядит очень просто:

SSO: Пользователь может войти в финансовую систему?
PDP: Нет. Для этого ресурса требуется MFA.
SSO: Показывает дополнительный этап аутентификации.

Или:

SSO: Подрядчик может войти в систему?
PDP: Нет. Срок договора завершён
SSO: Не выдаёт токен и завершает процесс с отказом.

Важный момент: AuthZEN сам по себе не описывает все возможные корпоративные правила. Он стандартизирует разговор между системой, которая должна применить решение, и системой, которая это решение принимает.

Благодаря этому SSO не привязывается навсегда к конкретному движку политик. Теоретически PDP можно заменить, не переписывая весь процесс авторизации.

Почему нельзя просто положить роли в токен?

Здесь может возникнуть справедливый вопрос. Зачем обращаться к внешнему сервису политик, если можно заранее добавить пользователю роль finance или admin? Для простых сценариев роли действительно работают отлично. Проблема появляется, когда решение зависит не только от пользователя.

Например:

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

Одной роли здесь недостаточно.

Нужно учитывать:

• пользователя;

• ресурс;

• действие;

• устройство;

• сеть;

• время;

• уровень аутентификации;

• дополнительные признаки риска.

Такие решения динамичны. Сегодня запрос разрешён, через час — уже нет. На одном устройстве доступ есть, на другом отсутствует. Поэтому роль в токене и внешняя проверка политики не заменяют друг друга. Роль остаётся частью контекста, а PDP принимает окончательное решение на основе всех доступных условий.

Обязательные действия до выдачи токена

Не каждая проверка заканчивается простым allow или deny. Иногда пользователю сначала нужно выполнить дополнительное действие:

• принять новую редакцию соглашения;

• обновить устаревшие данные;

• подключить MFA;

• сменить временный пароль;

• подтвердить корпоративную почту;

• выбрать активное подразделение или организацию;

• пройти обязательный этап онбординга.

В таком случае процесс авторизации можно временно остановить. Пользователь уже распознан, но токен ещё не выдан. После выполнения обязательного шага процесс продолжается с того же места.

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

Если реализовывать такие действия отдельно в каждом сервисе, придётся синхронизировать их состояние. Пользователь может принять соглашение в одном приложении, но второе об этом не узнает. Или включить MFA для одного сервиса, продолжая входить без него в остальные.

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

Внешний обработчик и script-runner

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

• обратиться к внутреннему REST API;

• выполнить расчёт по нескольким источникам;

• проверить запись в собственной базе;

• применить временное правило для пилотного проекта;

• преобразовать внешние данные;

• запустить небольшой бизнес-сценарий.

Самый очевидный путь — разрешить выполнять произвольный код внутри SSO. И это же один из самых опасных путей.

Пользовательский скрипт может зависнуть, съесть память, обратиться к внутренним компонентам, повредить процесс авторизации или просто уронить весь сервис. Кроме того, обновление ядра SSO становится сложнее: встроенные скрипты начинают зависеть от внутренних API и конкретной версии продукта.

Поэтому логичнее вынести выполнение кода в отдельный изолированный script-runner. Для SSO такой runner может выглядеть как обычный внешний PDP:

Сам script-runner не является отдельным стандартом OpenID. Это архитектурный способ реализации. Но если он принимает стандартный запрос и возвращает решение через совместимый интерфейс, SSO не обязан знать, что внутри решение принял скрипт, движок политик или отдельный корпоративный сервис. Для SSO это просто PDP.

Такой подход даёт сразу несколько преимуществ:

• чужой код не выполняется внутри основного процесса SSO;

• для скриптов можно задать ограничения по времени и ресурсам;

• runner можно обновлять независимо;

• ошибки конкретного обработчика проще локализовать;

• интерфейс между компонентами остаётся стабильным;

• в будущем runner можно заменить другим PDP.

При этом нужно заранее определить поведение при недоступности runner. Если проверка влияет на безопасность, разумнее закрывать доступ при ошибке. Если обработка носит вспомогательный характер, возможно продолжение входа без неё. Но это должно быть явным правилом, а не случайным последствием тайм-аута.

Не всё должно блокировать вход

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

• отправить событие в SIEM;

• обновить статистику посещаемости;

• запустить онбординг;

• уведомить систему управления сессиями;

• зафиксировать вход в отдельном журнале;

• передать сигнал в систему анализа риска;

• обновить инвентарь активных сессий.

Если ждать завершения всех этих операций, вход станет зависеть от десятка внешних сервисов. Упал сервис статистики — пользователь не может войти. Медленно отвечает аудит — страница авторизации зависает. Временная проблема в очереди превращается в проблему всей компании. Поэтому такие действия лучше выполнять асинхронно.

SSO завершает авторизацию, выдаёт токен и отдельно публикует событие. Получатели обрабатывают его независимо и не влияют на вход пользователя.

Для стандартизированного обмена подобными сигналами OpenID Foundation развивает Shared Signals Framework. SSF задаёт механизм обмена событиями между доверяющими друг другу сторонами, а профиль CAEP определяет события, связанные с изменениями состояния доступа и сессий. В CAEP 1.0, например, определено событие session-established, сообщающее о создании новой сессии; получатели могут использовать его для инвентаризации сессий или выявления неожиданных входов.

Схема выглядит примерно так:

Главное отличие от policy-проверки — событие не влияет на завершение текущего входа. PDP отвечает на вопрос: «Можно ли продолжить?». SSF и CAEP сообщают: «Что-то уже произошло или состояние изменилось». Это две совершенно разные задачи, хотя обе находятся рядом с процессом авторизации.

Четыре типа расширения процесса

Если собрать рассмотренные возможности в одну таблицу, получится достаточно понятная модель.

Эта таблица интересна не сама по себе. Интересно то, что четыре механизма закрывают четыре разных вопроса:

1. Можно ли пользователю продолжить вход?

2. Кого нужно уведомить о произошедшем событии?

3. Какие подтверждённые данные нужно добавить в контекст?

4. Как выполнить нестандартную корпоративную логику, не встраивая её в ядро SSO?

На практике один процесс авторизации может использовать сразу несколько типов. Например:

1. SSO подтверждает личность пользователя.

2. Claims Provider добавляет уровень допуска из IDM.

3. PDP проверяет, разрешён ли вход в выбранное приложение.

4. Script Runner рассчитывает временный контекст для пилотного проекта.

5. SSO выдаёт токен.

6. Через SSF отправляется событие о создании сессии.

Для пользователя всё это по-прежнему выглядит как обычный вход.

Почему не реализовать всё в приложениях?

Теперь вернёмся к главному архитектурному вопросу. Почему бы каждому приложению не выполнять нужные проверки самостоятельно?

В небольшом проекте именно так часто и проще сделать. Если есть одно приложение и одна специфическая проверка, отдельная инфраструктура может оказаться избыточной. Но корпоративная среда редко остаётся маленькой. Сегодня проверка нужна порталу. Завтра то же правило появляется в CRM. Через месяц его добавляют в систему документооборота. Затем меняется источник данных или формат ответа. Если логика находится внутри приложений, начинаются расхождения.

Центральная обработка через SSO даёт несколько практических преимуществ.

• Единое применение правил
  Если пользователь не должен входить без MFA, это правило срабатывает до выдачи токена, а не зависит от добросовестности каждого приложения.

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

• Единый аудит
  Можно увидеть не только факт входа, но и то, какие проверки выполнялись, какое решение вернул PDP, откуда пришли claims и какие события были отправлены.

• Управляемое развитие
  Новый Claims Provider или обработчик подключается к центральному процессу. Не нужно выпускать новую версию каждого приложения.

• Разделение ответственности
  Кадровая система отвечает за кадровые данные. IDM — за доступы. PDP — за политики. Script Runner — за изолированное выполнение специальной логики. SSO собирает этот процесс и формирует итоговый результат.

Это заметно правильнее чем "все в SSO", внутри которого постепенно появляется копия всей корпоративной инфраструктуры.

Но у централизации есть цена

Было бы неправильно рассказать только о плюсах. Чем больше задач проходит через SSO, тем критичнее становится его доступность и предсказуемость. Если внешний Claims Provider отвечает десять секунд, пользователь будет ждать. Если PDP недоступен, система должна понимать, разрешать вход или запрещать. Если обязательный обработчик вернул некорректный ответ, нужен понятный сценарий ошибки.

Поэтому подобную архитектуру нельзя строить по принципу «подключим всё, что найдём». Нужно заранее определить:

• какие проверки являются блокирующими;

• какие операции можно выполнять асинхронно;

• сколько времени SSO ждёт внешний сервис;

• можно ли использовать кэш;

• что происходит при недоступности источника;

• какие claims разрешены конкретному приложению;

• кто отвечает за достоверность каждого утверждения;

• как журналируются решения;

• где проходит граница между SSO и бизнес-системами.

Особенно важно не переносить в SSO полноценные бизнес-процессы. SSO может спросить, разрешён ли вход. Может получить данные. Может запустить обязательный шаг или отправить событие. Но он не должен превращаться в кадровую систему, BPM-движок, IDM, SIEM и корпоративную шину одновременно.

Хорошая архитектура расширяет SSO через внешние компоненты.

Плохая — постепенно встраивает все компоненты внутрь SSO.

Где заканчивается авторизация и начинается платформа

Когда-то SSO решал достаточно понятную задачу: пользователь входит один раз и получает доступ к нескольким ресурсам. Эта задача никуда не исчезла. Более того, она остаётся основой всей системы. Но вокруг неё постепенно формируется новый слой. SSO начинает:

• собирать пользовательский контекст;

• принимать внешние claims;

• обращаться к сервисам политик;

• запускать обязательные действия;

• передавать сигналы о сессиях;

• подключать изолированные обработчики;

• формировать единый аудит процесса входа.

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

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

Подведем черту

Работая над SSO, я долго воспринимал дополнительные claims, проверки и обработчики как отдельные функции, которые просто нужно добавить в продукт. Одна задача пришла от конкретного приложения. Другая появилась из требований безопасности. Третья понадобилась для интеграции с внутренней системой. Но если собрать их вместе, становится заметна общая идея.

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

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

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

Возможно, вопрос: «Какой SSO выбрать?» окончательно перестанет быть вопросом только про способы входа и поддерживаемые протоколы, потому что выбирать будут уже не просто страницу авторизации, а полноценную платформу, вокруг которой строится корпоративная идентичность.