В крупной фирме имеется одна центральная информационная база 1С:Предприятие 8.1 "Управление производственным предприятием" и несколько периферийных баз, обмен данными происходит через файлы XML. После выявления многочисленных случаев несанкционированного доступа к конфиденциальной информации, а именно кассовым и банковским документам при обмене данными, руководством было решено защитить данные при обмене информацией между центральной базой и периферийными базами. Перемещение данных между базами происходит через файлы XML, по нескольким каналам связи FTP, HTTP, POP, SMTP, а также на сменных носителях (типа USB Flash Drive). В связи с этим решено использовать внешнюю компоненту для шифрования файлов XML и небольшой доработки конфигурации баз данных.
Защита информации при обмене с распределенной базой данных.
В крупной фирме имеется одна центральная информационная база 1С:Предприятие 8.1 «Управление производственным предприятием» и несколько периферийных баз, обмен данными происходит через файлы XML. После выявления многочисленных случаев несанкционированного доступа к конфиденциальной информации, а именно кассовым и банковским документам при обмене данными, руководством было решено защитить данные при обмене информацией между центральной базой и периферийными базами. Перемещение данных между базами происходит через файлы XML, по нескольким каналам связи FTP, HTTP, POP, SMTP, а также на сменных носителях (типа USB Flash Drive). В связи с этим решено использовать внешнюю компоненту для шифрования файлов XML и небольшой доработки конфигурации баз данных. В общем обмен проводился по старой схеме следующим образом: Центральная ИБ — файл XML — передача по каналу FTP, HTTP, e-mail.
Новая схема предполагала передавать по каналам передачи данных только зашифрованные данные.
Сначала в Центральной базе попробуем выгрузить в файл XML и зашифровать его один документ «Приходный кассовый ордер». Необходимо выбрать файл XML, выбрать документ ПКО, ввести пароль и нажать на кнопку «Выгрузить документ».
В периферийной базе загружаем документ из файла с помощью это обработки. Переходим на закладку «Загрузить документ из файла», выбираем файл, вводим пароль и нажимаем кнопку «Загрузить документ».
Мы рассмотрели пример выгрузки-загрузки только одного документа, аналогичным образом можно обмениваться сразу несколькими документами разных видов. В общем система работает достаточно стабильно. Каждой информационной базе назначен свой пароль, который хранится в отдельном справочнике, недоступном для пользователей. Случаи несанкционированного доступа практически исчезли сразу после внедрения этой системы, потому что до этого файлы XML могли загружать и читать все лица которые имели к ним доступ.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
а компонента зачем? aes256 уже не котируется? а это встроено в платформу
(0) А что пароль на архив длиной в гуид не надежно?
aes256 применяется только для ZIP архивов, к тому же там не применяется алгоритм хеширования пароля. Для непонятливых могу пояснить это такая функция которая выдает строчку из определенного набора букв и цифр из исходной строки пароля, которая не позволяет провести атаку по словарю.
(0) Я понимаю конечно, что это реклама вашей компоненты 🙂 но пример не очень удачный… Пароля на архив, действительно, вполне достаточно.
А хоть какой длины пароль! При аес 256 беруться для пароля только 256 байт из пароля, а как тама они берутся из начала или из конца это знают только разработчики 1С
(0) Кстати интересно, а какой канал связи используется при передаче данных? Если почта, то есть ПГП, если ФТП то админу по шапке..
(3,5) ты это сам придумал, или кто подсказал? и интересно, каким методом твоя компонента шифрует? еще такой вариант шифрования есть:
К сожалению прожект 2941 не генерит ключ ?
(8) В смысле?… )
(7) +1
кроме того, ты сохраняешь файлы на диск как минимум в 3х местах (клиент1, сервер/флешка, клиент2), в таких системах надо исключать по максимому сами места хранения (если можно инфу скопировать, то и взломать можно). Самым слабым местом обычно бывает сервер/флешка.
кроме того как дополнение, рекомендую отдельным потоком слать ХЕШ файла (контроль от изменения)…
вообще смотри я давно рекомендую такой подход, для него
1. реально выделить разных SQL пользователей (что-бы друг друга не видели)
2. шифровать поточно (вообще не сохраняя файлы на клиентах)
(8)RTFM — любой нормальный симметричный алгоритм, ВСЕГДА работает с ключом одной длинны — максимальной. Таким образом любая библиотека шифрования обязана либо требовать ввод ключа заданной длины, либо сама сгенерирует хеш с длиной ключа шифрования (32, 64, 128, …) на основании пароля, и кодирование будет выполнено с использованием этого ключа.