Переключаясь с проекта на проект, одной из первых задач становится анализ текущего состояния системы и информационных баз. Смотришь, какая используется конфигурация, насколько она изменена, как реализованы внешние доработки, есть ли интеграции и нестандартные решения.
И чаще всего у разных заказчиков сталкиваешься с одними и теми же проблемами:
🟣логин/пароль к FTP - прямо в модуле обработки
🟣пользователь и пароль к базе - в коде подключения
🟣параметры внешних ресурсов, которые уезжают вместе с .epf, конфигурацией или выгрузкой базы
▶️Почему это опасно?
Я ловлю себя на мысли, что это странно объяснять: кажется, все и так всё понимают. Но, увы, почти каждый проект одно и тоже.
Код живёт дольше, чем кажется:
🟣Сегодня разработчик «на минутку» прописал пароль прямо в обработке
🟣Завтра эту обработку отправили подрядчику
🟣Послезавтра выгрузили пустую базу для анализа
🟣Потом сделали CF/DT для тестового стенда
А пароль всё ещё там. 😆
И внезапно вместе с «пустой базой» или «просто внешней обработкой» третьим лицам уезжают реальные доступы: к FTP, почте, API, бухгалтерской базе или внешнему сервису. Проблема не в том, что кто-то специально хотел сделать плохо. Проблема в том, что временные решения очень быстро становятся постоянными - и начинают жить своей жизнью.
▶️Безопасное хранение паролей
У 1С на эту тему есть отдельный стандарт:
https://its.1c.ru/db/v8std/content/740/hdoc
Смысл там очень правильный:
🟢по возможности не хранить пароли в информационной базе вообще;
🟢если хранить всё-таки нужно - не класть их в обычные реквизиты объектов;
🟢использовать отдельный объект метаданных с ограниченными правами;
🟢если есть БСП - использовать безопасное хранилище паролей;
🟢не передавать пароль на клиент и не хранить его в реквизитах формы;
🟢читать пароль на сервере непосредственно перед использованием.
▶️В БСП для этого есть методы:
ЗаписатьДанныеВБезопасноеХранилище()
ПрочитатьДанныеИзБезопасногоХранилища()
УдалитьДанныеИзБезопасногоХранилища()
В документации по БСП больше информации:
https://its.1c.ru/db/bsp321doc#content:127:hdoc
Это тот случай, когда лучше взять стандартный механизм, чем писать
"ПарольFTP = 12345" в модуле.▶️А если БСП нет?
Тоже не повод писать пароль в коде. Можно сделать свой объект хранения (регистр сведений, пвх и. т.п). Закрыть правами, читать значения только на сервере и только в момент обращения к ресурсу. Это не идеальная защита, но это уже лучше, чем пароль строкой в модуле, который потом уедет неизвестно куда.
▶️Резюме
Пароли в коде - это не «настройка для удобства разработчика». Это доступ к чужим системам, данным и деньгам, поэтому если вы видите в коде логин/пароль - это не технический долг, а место, которое нужно исправлять в первую очередь. Крик души окончен. 😊
❓
#tech@it_lunch
🔥 Подписывайся на IT Ланч!