Аутентифікація користувачів

Використання сертифікатів

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

Аутентифікація користувача

У цьому діалозі потрібно вказати ім'я користувача. Це можна зробити кількома способами:

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

Якщо користувачу призначено пароль, його потрібно ввести в поле Пароль. Після зазначення імені та пароля користувача процес запуску продовжиться після натискання кнопки ОК. Натискання кнопки Відмінити дає змогу відмовитися від запуску.

У правій частині поля введення пароля є кнопка, яка дає змогу переглянути пароль у відкритому вигляді.

Прихований пароль

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

Відкритий пароль

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

Використання сертифікатів

Загальна інформація

Під час роботи через публічні канали зв'язку (Інтернет) важливо захистити інформацію, що передається таким каналом, від перехоплення та підміни. Розглянемо організацію такого з'єднання в системі 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.