Автоподстановка учетных записей

ℹ️ О разделе

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

Как работает автоподстановка

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

🎯 Умный поиск

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

🏆 Приоритизация

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

⚡ Быстрый доступ

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

🔀 Интерфейс выбора

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

Алгоритм поиска по дереву объектов

Автоподстановка использует алгоритм поиска снизу вверх по иерархии объектов приложения:

  1. Текущий уровень — система сначала ищет учетные записи, привязанные непосредственно к запрошенному объекту
  2. Родительский уровень — если на текущем уровне ничего не найдено, система переходит к родительскому объекту
  3. Выше по иерархии — процесс продолжается до корня приложения
  4. Корень приложения — в корне могут храниться общие учетные записи для всего приложения
✅ Пример

Запрашивается доступ к объекту /myapp/servers/production/web-01.

Порядок поиска:

  1. /myapp/servers/production/web-01 — текущий сервер
  2. /myapp/servers/production — группа серверов production
  3. /myapp/servers — все серверы
  4. /myapp — корень приложения

Система приоритетов

На каждом уровне иерархии применяется строгая система приоритетов при выборе учетной записи:

Приоритет Тип учетной записи Описание
1 Типизированная личная Личная учетная запись пользователя с типом, соответствующим запросу (RDP, SSH, VNC и т.д.)
2 Типизированная групповая Групповая учетная запись с типом, соответствующим запросу, доступная членам группы
3 Универсальная личная Личная универсальная учетная запись, подходящая для любого типа подключения
4 Универсальная групповая Групповая универсальная учетная запись, доступная членам группы
ℹ️ Логика выбора

На каждом уровне иерархии система проверяет все четыре приоритета по порядку. Если на уровне найдена ровно одна учетная запись наивысшего доступного приоритета — она используется автоматически. Если найдено несколько учетных записей одного приоритета — показывается интерфейс выбора. Если ничего не найдено — поиск переходит на следующий (родительский) уровень.

Типизированные и универсальные учетные записи

IDENTYX поддерживает два класса учетных записей с разным поведением при автоподстановке:

Типизированные учетные записи

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

Поддерживаемые типы:

  • RDP — учетные данные для Remote Desktop Protocol (удаленный рабочий стол Windows)
  • SSH — учетные данные для SSH подключений (может включать SSH ключи)
  • VNC — учетные данные для VNC подключений
  • Winbox — учетные данные для MikroTik Winbox
  • VMware — учетные данные для VMware vCenter/ESXi
  • Proxmox — учетные данные для Proxmox VE
✅ Преимущества типизированных УЗ
  • Точное соответствие типу подключения
  • Высший приоритет при автоподстановке
  • Удобство организации учетных данных по назначению
  • Возможность иметь разные учетные данные для разных типов подключений к одному объекту

Универсальные учетные записи

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

🔓 Гибкость

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

📦 Простота

Нет необходимости указывать тип — универсальная УЗ работает везде, где требуются учетные данные.

⚠️ Приоритет универсальных УЗ

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

Интерфейс выбора учетных записей

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

Когда показывается интерфейс выбора

  • Несколько учетных записей одного приоритета — например, две личных типизированных УЗ для RDP на одном объекте
  • Принудительный выбор — приложение может явно запросить показ интерфейса выбора, даже если есть единственная УЗ
  • Первое использование — при первом доступе к объекту, когда нет сохраненных учетных записей

Структура интерфейса

Интерфейс выбора организован в виде вкладок и групп для удобной навигации:

📋 Вкладка "Все пароли"

Показывает все доступные учетные записи: и личные, и групповые. Удобно для быстрого просмотра всех вариантов.

👤 Вкладка "Мои пароли"

Показывает только личные учетные записи пользователя. Полезно, когда нужно найти конкретную личную УЗ.

👥 Вкладка "Пароли групп"

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

Группировка по уровням иерархии:

  • Текущий объект — учетные записи, привязанные непосредственно к запрошенному объекту (отмечены иконкой 📍)
  • Наследуемые от родительских объектов — учетные записи с верхних уровней иерархии (отмечены иконкой 🌲)
  • Ручной ввод — возможность создать новую учетную запись или ввести данные вручную без сохранения
ℹ️ Информация об объекте

В интерфейсе выбора отображается путь к объекту, для которого запрашиваются учетные данные, например: /myapp/servers/production/web-01. Это помогает понять контекст выбора.

Ручной ввод учетных данных

В интерфейсе выбора всегда доступна опция "Ручной ввод". Она позволяет:

  • Создать новую учетную запись прямо из интерфейса выбора
  • Ввести учетные данные для разового использования без сохранения
  • Использовать временные учетные данные

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

Строгий режим и совместимость типов

Приложения могут запрашивать учетные записи в двух режимах:

Обычный режим

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

Пример: Приложение запрашивает учетную запись типа ssh. Система найдет:

  • Типизированные SSH учетные записи (наивысший приоритет)
  • Универсальные учетные записи (как запасной вариант)

Строгий режим

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

Пример: Приложение запрашивает учетную запись типа rdp в строгом режиме. Система найдет:

  • Только типизированные RDP учетные записи
  • Универсальные учетные записи будут проигнорированы
⚠️ Когда используется строгий режим

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

Практические сценарии автоподстановки

Сценарий 1: Единственная учетная запись

Ситуация: У пользователя есть одна личная RDP учетная запись для сервера /servers/prod/web-01.

Поведение: При запросе доступа к этому серверу по RDP система автоматически использует эту учетную запись без показа интерфейса выбора.

Сценарий 2: Несколько учетных записей на одном уровне

Ситуация: У пользователя есть две личные RDP учетные записи для сервера: одна для обычного пользователя, другая для администратора.

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

Сценарий 3: Наследование от родительского уровня

Ситуация: Для сервера /servers/prod/web-01 нет личных учетных записей, но для родительской папки /servers/prod создана универсальная учетная запись.

Поведение: Система не находит УЗ на уровне web-01, поднимается на уровень prod, находит универсальную УЗ и использует её автоматически.

Сценарий 4: Личные и групповые учетные записи

Ситуация: Для сервера есть групповая SSH учетная запись и личная универсальная учетная запись пользователя.

Поведение: При запросе SSH подключения система выбирает типизированную групповую SSH учетную запись (приоритет 2), так как она имеет более высокий приоритет, чем универсальная личная (приоритет 3).

Сценарий 5: Первый доступ без сохраненных УЗ

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

Поведение: Система показывает интерфейс с предложением создать новую учетную запись или ввести данные вручную.

Рекомендации по использованию

🎯 Используйте типизированные УЗ

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

📁 Организуйте иерархию

Размещайте общие учетные записи на верхних уровнях иерархии (например, на уровне всех серверов), а специфические — на нижних (конкретный сервер).

👥 Используйте групповые УЗ для команд

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

🔐 Личные УЗ для персональных ресурсов

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

✅ Оптимальная стратегия

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

Интеграция с IDENTYX Proxy

Автоподстановка учетных записей особенно эффективна при использовании с IDENTYX Proxy. Proxy автоматически:

  • Запрашивает учетные записи для приложений без изменения их кода
  • Применяет алгоритм автоподстановки прозрачно для пользователя
  • Автоматически заполняет формы входа в приложения
  • Управляет сессиями и повторной аутентификацией
ℹ️ Подробнее о Proxy

Детальная информация о настройке и использовании IDENTYX Proxy с автоподстановкой учетных записей доступна в разделе IDENTYX Proxy.

Решение проблем

Показывается интерфейс выбора, хотя учетная запись одна

Возможные причины:

  • На одном уровне иерархии есть несколько учетных записей одного приоритета (например, две личные типизированные RDP)
  • Приложение явно запрашивает показ интерфейса выбора (параметр forceChoice)

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

Используется не та учетная запись

Возможные причины:

  • Неправильная организация иерархии объектов
  • Несоответствие типа учетной записи запрашиваемому типу
  • Приоритет групповой типизированной УЗ выше личной универсальной

Решение: Создайте типизированную личную учетную запись нужного типа на более низком уровне иерархии — она будет иметь наивысший приоритет.

Универсальная УЗ не используется для типизированного запроса

Причина: Приложение запрашивает учетную запись в строгом режиме.

Решение: Создайте типизированную учетную запись нужного типа (RDP, SSH и т.д.) вместо универсальной.

Учетная запись не найдена, хотя она создана

Возможные причины:

  • Учетная запись привязана к другому объекту, не в иерархии запрашиваемого
  • Учетная запись принадлежит группе, в которой пользователь не состоит
  • Неправильный тип учетной записи для строгого режима

Решение: Убедитесь, что учетная запись привязана к правильному объекту или его родителю. Проверьте членство в группах для групповых УЗ. Проверьте тип учетной записи.

✅ Готовы продолжить?

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