Довідковий матеріал

Безпечне зберігання паролів

<em>Область застосування: керований застосунок, мобільний застосунок, звичайний застосунок.</em>

Абстрактна сцена безпечного зберігання паролів: закрите сховище під захистом щита отримує дані захищеним каналом від клієнтського пристрою.

Область застосування: керований застосунок, мобільний застосунок, звичайний застосунок.

1. Під час розробки підсистем, що взаємодіють із різними зовнішніми ресурсами (електронною поштою, вебсервісами, FTP-ресурсами тощо), виникає необхідність запитувати та передавати дані автентифікації до цих ресурсів: логін і пароль.

2. Щоб звести до мінімуму можливість перехоплення пароля зловмисниками, не слід зберігати паролі та іншу конфіденційну інформацію в інформаційній базі. При цьому мінімальний рівень захищеності — у файлових інформаційних базах, у яких файл бази може бути повністю скопійований будь-яким користувачем інформаційної бази. У клієнт-серверній інформаційній базі доступ до бази даних, як правило, мають лише адміністратори СУБД.

Таким чином, слід запитувати логін і пароль у користувача та передавати їх одразу, не зберігаючи в інформаційній базі.

3. У низці випадків така схема роботи створює об’єктивні незручності або є принципово неможливою:

  • інтерактивний запит логіна й пароля для кожної операції може створювати значний дискомфорт під час роботи, а тимчасового зберігання на боці клієнта недостатньо;
  • взаємодія з різними зовнішніми ресурсами має виконуватися на сервері незалежно від інтенсивності роботи користувачів із програмою.

У таких випадках допустимо організувати зберігання паролів та іншої конфіденційної інформації в інформаційній базі, попередивши користувачів про наслідки. Слід пам’ятати, що подібне зберігання паролів не вирішує всіх проблем безпеки, а лише ускладнює завдання для зловмисника.

3.1. При цьому не слід зберігати паролі та іншу конфіденційну інформацію в реквізитах тих самих об’єктів метаданих, з якими ведеться повсякденна робота. Для зберігання такої інформації слід використовувати окремий об’єкт метаданих (наприклад, регістр відомостей), організувавши до нього безпечний доступ на рівні системи прав доступу 1С:Підприємства.

3.2. Під час використання Бібліотеки стандартних підсистем (БСП) слід використовувати безпечне сховище паролів, яке вирішує низку завдань:

  • Маючи доступ до об’єкта метаданих, користувач може прочитати вміст реквізиту з паролем, що неможливо під час використання безпечного сховища. Щоб виключити випадки несанкціонованого доступу до безпечного сховища, отримання та запис даних (паролів) можливі лише в привілейованому режимі.
  • Дані в безпечному сховищі зберігаються в закритому вигляді, і тим самим виключаються випадки ненавмисного «розкриття» паролів.
  • Безпечне сховище виключено з планів обміну, що запобігає витоку паролів з інформаційної бази під час обміну даними.

Для роботи з безпечним сховищем паролів призначені процедури та функції загального модуля ОбщегоНазначения: ЗаписатьДанныеВБезопасноеХранилище, ПрочитатьДанныеИзБезопасногоХранилища і УдалитьДанныеИзБезопасногоХранилища. Докладніше див. коментарі до цих функцій у БСП і розділ «3.4. Базова функціональність — Використання під час розробки конфігурації — Безпечне сховище паролів» документації БСП.

3.3. Не слід зберігати паролі в реквізитах форми, їх слід отримувати лише на боці сервера й безпосередньо перед їх використанням. В іншому разі під час відкриття форми із замаскованим введенням (або переглядом) пароля пароль передається із сервера на клієнт у відкритому вигляді, що уможливлює його перехоплення. Установлення привілейованого режиму виконується безпосередньо перед викликом функцій, а не всередині них, щоб виключити отримання або запис будь-яких паролів у сеансі з будь-якими правами. Безпеку виклику має забезпечувати код, що викликає, який звертається до конкретних паролів.

Для маскування пароля на формі в обробнику події форми ПриСозданииНаСервере необхідно розмістити такий код:

УстановитьПривилегированныйРежим(Истина); Пароли = ОбщегоНазначения.ПрочитатьДанныеИзБезопасногоХранилища(Объект.Ссылка, "Пароль, ПарольSMTP"); // Пароль, ПарольSMTP – ключі відповідності даних у безпечному сховищі УстановитьПривилегированныйРежим(Ложь); Пароль = ?(ЗначениеЗаполнено(Пароли.Пароль), ЭтотОбъект.УникальныйИдентификатор, ""); ПарольSMTP = ?(ЗначениеЗаполнено(Пароли.ПарольSMTP), ЭтотОбъект.УникальныйИдентификатор, "");

В обробнику події форми ПриЗаписиНаСервере:

Если ПарольИзменен Тогда УстановитьПривилегированныйРежим(Истина); ОбщегоНазначения.ЗаписатьДанныеВБезопасноеХранилище(ТекущийОбъект.Ссылка, Пароль); Пароль = ?(ЗначениеЗаполнено(Пароль), ЭтотОбъект.УникальныйИдентификатор, ""); КонецЕсли; Если ПарольSMTPИзменен Тогда УстановитьПривилегированныйРежим(Истина); ОбщегоНазначения.ЗаписатьДанныеВБезопасноеХранилище(ТекущийОбъект.Ссылка, ПарольSMTP, "ПарольSMTP"); ПарольSMTP = ?(ЗначениеЗаполнено(ПарольSMTP), ЭтотОбъект.УникальныйИдентификатор, ""); КонецЕсли;

де Пароль і ПарольSMTP — реквізити форми. Якщо пароль раніше було збережено в програмі, то відповідному реквізиту слід призначити унікальний ідентифікатор форми, що імітує наявність пароля. Під час запису об’єкта у формі, якщо було введено новий пароль, записуємо його в об’єкт, а реквізит форми знову затираємо унікальним ідентифікатором.

Записатися телефоном