Аутентификация пользователей

Использование сертификатов

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

Аутентификация пользователя

В этом диалоге необходимо указать имя пользователя. Это можно сделать несколькими способами:

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

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

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

Скрытый пароль

После нажатия кнопки пароль перестает маскироваться символами «*» и отображается открыто, а кнопка меняет свое изображение.

Открытый пароль

Повторные нажатия кнопки в поле ввода пароля циклически переключают режим отображения: пароль маскируется «*» — пароль отображается открытым текстом. При повторном открытии диалога аутентификации пользователя пароль будет вводиться в маскированном режиме.

Использование сертификатов

Общая информация

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

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

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

В этом мире один человек (Прохожий) встречает другого человека (Полицейского), который хочет удостовериться, что человек перед ним — действительно Прохожий. Для этого Полицейский просит у Прохожего его паспорт. Прежде чем предъявить свои документы, Прохожий хочет убедиться, что перед ним настоящий Полицейский. Он просит у Полицейского удостоверение личности, связывается с Министерством управления полицией и по номеру проверяет, что человек перед ним — действительно тот, за кого себя выдает, то есть Полицейский. После успешной процедуры аутентификации Прохожий передает свой паспорт Полицейскому. В паспорте указано, что он выдан Министерством выдачи документов, и указан номер паспорта. Полицейский связывается с Министерством и с помощью номера паспорта убеждается, что человек перед ним — действительно Прохожий.

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

Теперь представим эту простую схему с точки зрения объектов PKI и сетевой инфраструктуры. Клиентское прикладное приложение выступает в роли Прохожего. Веб-сервер, с помощью которого клиентское прикладное приложение хочет получить доступ к информационной базе, выступает в роли Полицейского. Министерство выдачи документов и Министерство управления полицией играют роль Удостоверяющих центров. Сертификат, используемый при установлении HTTPS-соединения, представлен как паспорт Прохожего и удостоверение личности Полицейского.

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

Выше приведена общая схема установления защищенного соединения.

Схемы установления защищенного соединения

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

В таблице использованы следующие термины:

• Сертификат — означает наличие (Сертификат+) или отсутствие (Сертификат-) соответствующего сертификата:

  • для сервера — серверного сертификата;
  • для клиента — клиентского сертификата.
• Корневые — означает наличие (Корневые+) или отсутствие (Корневые-) списка сертификатов удостоверяющих центров (УЦ или CA), с помощью которых можно проверить предъявленный сертификат. Список удостоверяющих центров должен позволять проверить сертификат, предоставленный клиентским прикладным приложением или веб-сервером.

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

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

Источники и форматы сертификатов

Источниками сертификатов могут быть следующие хранилища:

• Системное хранилище сертификатов — для ОС Windows.
• Хранилище сертификатов ОС Linux, расположенное в каталоге /etc/ssl/certs. Все сертификаты, находящиеся в этом каталоге, считаются доверенными.

В некоторых дистрибутивах ОС Linux также поддерживаются следующие каталоги размещения корневых сертификатов:

• Debian, Mint, Ubuntu: каталог /etc/ssl/certs/ca-certificates.crt.

  • CentOS, Fedora, RedHat: каталог /etc/ssl/certs/ca-bundle.trusted.crt или /etc/pki/tls/certs/ca-bundle.crt.
  • Alt Linux: каталог /etc/share/ca-certificates/ca-bundle.crt.
• Файловые сертификаты — для ОС Linux или Windows.

Допустимые форматы файловых сертификатов:

• PEM (base-64 encoded X.509) — зашифрованные ключи и сертификаты стандарта X.509 в текстовом формате. Данные сертификатов и ключей кодируются в кодировке base-64. Закрытые ключи сертификатов защищены паролем. Этот формат файлов сертификатов используется по умолчанию, например веб-сервером Apache. Если закрытый ключ клиентского сертификата хранится в отдельном файле, необходимо добавить содержимое этого файла в файл клиентского сертификата.
• P12/PFX (PKCS#12) — зашифрованные ключи и сертификаты стандарта PKCS#12. Файл может быть защищен паролем. Это основной формат экспорта и импорта системных хранилищ сертификатов для ОС Windows. Используется, например, веб-сервером Microsoft Internet Information Services. Файл клиентского сертификата должен содержать его закрытый ключ.

Формат файла выбирается по его расширению:

• *.p12, *.pfx — формат файла P12,
• *.pem — формат файла PEM,
• по умолчанию выбирается формат файла PEM.