Вход | Регистрация
 

Шифрованный справочник

Шифрованный справочник
Я
   repin_mike
 
03.02.21 - 17:38
Задача - требуется создать справочник, данные в котором должны быть зашифрованы, то есть прочитать их нельзя даже под админскими правами запросом, стало быть настройка прав доступа и поиграться с отображением данных на форме не подходит. В реквизитах и табличных частях справочника есть как примитивные типы, так и ссылки (на незашифрованные справочники и документы). После ввода пароля пользователь имеет возможность как открывать эашифрованные элементы справочника, так и формировать отчёты, в котором данный справочник фигурирует. Кто-нибудь уже реализовывал что-либо подобное?
   Voronve
 
1 - 03.02.21 - 17:41
(0) сслыки оставь, на простейшие типы шифр цезаря
   d_monah
 
2 - 03.02.21 - 17:42
Существует универсальный ректальный электрический расшифровщик элементов/данных.Так-что твоя идея не прокатит
   Lama12
 
3 - 03.02.21 - 17:43
Убери у справочника "Наименование", и будет он у тебя зашифрованным (точнее закодированным).
Для чтения - кодовая таблица. Отчеты можно декодировать во второй базе которая недоступна админу первой. Все остальное решается (2).
   dka80
 
4 - 03.02.21 - 17:46
Убрать все права, создать новое право, дать нужному пользователю
   Voronve
 
5 - 03.02.21 - 17:47
(4) Одмин зайдет и добавит чебе прав
   dka80
 
6 - 03.02.21 - 17:48
(5) а что мешает админу изменить код и сохранить себе незашифрованые данные, когда пользователь введет пароль?
   d_monah
 
7 - 03.02.21 - 17:48
(4) Как бы еще нужно тайную комнату без окон, конкуренты могут в бинокль смотреть.
   d_monah
 
8 - 03.02.21 - 17:49
(6) Админ <> погроммист!
   dka80
 
9 - 03.02.21 - 17:50
(8) но программист=админ в большинстве случаев
   d_monah
 
10 - 03.02.21 - 17:53
(9) =электрик+телефонист+грузчик (не часто,но видал)
   fisher
 
11 - 03.02.21 - 17:54
Требование защиты "от админских прав" - невыполнимое. А раз так, то нет смысла шифровать данные в базе. Достаточно формировать обфусцированное представление при отсутствии нужных прав.
   dka80
 
12 - 03.02.21 - 17:56
Храни данные зашифрованными
http://catalog.mista.ru/1c/articles/1083158/
   RomanYS
 
13 - 03.02.21 - 17:59
(0) может отдельная база и подключение как к внешнему источнику данных?
   fisher
 
14 - 03.02.21 - 18:03
(12) Это очень смешное шифрование. Но от мамкиных взломщиков может и спасет.
   H A D G E H O G s
 
15 - 03.02.21 - 18:06
(0) шифруй простейшей xorкой с автоключом.
   fisher
 
16 - 03.02.21 - 18:08
(15) Свой шифроблокнот на каждое поле? В отдельной базе, что ли? :)
   repin_mike
 
17 - 03.02.21 - 18:10
Ну я тоже догадываюсь, что постановка задачи на 90% бред, но тем не менее придётся это хоть как-то реализовывать.

(13) Спасибо за мысль, попробую копнуть в этом направлении. Сейчас крутятся мысли про заворачивание данных формы в xml, шифровании каким-либо симметричным алгоритмом и записи в отдельный реквизит справочника, но внешний источник данных может оказаться проще.
   Aleksey
 
18 - 03.02.21 - 18:20
Так а что мешает админу посмотреть на скуле сырые незашифрованные данные?
   Йохохо
 
19 - 03.02.21 - 18:21
(18) незнание тисипидамп и рабочее место оборудованное по требованиям АСТ ГОЗ
   fisher
 
20 - 03.02.21 - 18:35
(17) Непонятны границы проблемы, которую ты решаешь. Вынесение секретных данных в отдельную базу - это не шифрование. Это перенос точки ответственности. Тогда непонятно как нужно защищать эту вторую базу.
   sitex
 
21 - 03.02.21 - 19:25
(14) Это можно адаптировать , и мамкины сынки будут курит в стороне n-лет.
   sitex
 
22 - 03.02.21 - 19:26
(20) Скорее всего что то связано с чернухой , бабло топ менеджерам , какие нить левые оплаты . Врядли - порнуха)))
   vde69
 
23 - 03.02.21 - 19:55
в целом задача вполне реализуема, только про то, что с данным справочником можно будет работать внутри самой 1с придется забыть.


делается так
1. на клиенты сравится гнусмус (пжп клиент)
2. для нужных юзеров генерятся закрытые ключи и устанавливаются в аладиновские "флешки" токины,
3. открытые ключи - записываются в справочник в 1с
4. любые данные которые вносит оператор в 1с по кому передаются в гнусмус и шифруются для каждого ключа отдельно (то есть сколько ключей столько и копий элемента справочника должно быть)
5. результат записываетсЯ в регистр, а в справочник записыватся информация где какой ключ.

при необходимости прочитать потребуется токин, без него ни один крипто анализатор не поможет. То есть будет физический ключ !!!
Разумеется расшифровка идет не в 1с и отображение результата должно идти не в 1с а в другой системе.
вызывается
   Вафель
 
24 - 03.02.21 - 19:56
шифование 1 справочника - это шифрованый блокнот чтоли?
про какие отчеты речь идёт?
регистр то не зашифруешь
   sitex
 
25 - 03.02.21 - 20:03
(23) Крипто-Про и Сертификаты.  Делали такое.
   RomanYS
 
26 - 03.02.21 - 22:02
(23) А 1с тут зачем? В принципе можно придумать как упаковать зашифрованные данные в какой-либо контейнер (внутри 1С или нет), только смысл при этом в 1С теряется и преимущества (быстрая разработка, формы, запросы, разделенный доступ с блокировками...)
   Bigbro
 
27 - 04.02.21 - 04:50
(23) похоже на рабочую схему. дико неудобную но тут уж как поставлена задача.
   DGorgoN
 
28 - 04.02.21 - 09:15
(23) Ну сейчас это и в 1С возможно. Есть поддержка ЭЦП и прочее. Сами данные шифровать можно. Т.е. без расшифровки строка будет вида "ыфвалаотивыаиорвыиаровыиаырвиаорыви52454" а после расшифровки "кам рит" к примеру. И в 1с возможно это будет использовать при вводе пароля/с помощью эцп/токена и проч.
   Bigbro
 
29 - 04.02.21 - 09:36
в (23) правильный вопрос поднят - про дублирование.
то есть мы либо дублируем каждым кто вводит данные
либо должны расшифровать предварительно весь объем данных чтобы проверить нет ли уже в них того что мы бы хотели внести.
применяя соответствующий ключ для каждого элемента..
то есть в топку запросы, все в топку, тупо перебор поэлементно и обработка
с соответствующей производительностью.
мне кажется что постановку задачи надо менять.
делать отдельный защищенный контур и внутри нормально в нем работать, а не сваливать в одну кучу все и потом мучаться с разделением данных и дешифровкой на каждое обращение со скоростью беременной улитки работая.
   RomanYS
 
30 - 04.02.21 - 09:48
(29) +100500
Если данные в зашифрованном контейнере, то смысла в 1С почти нет. Поэтому кроме (13) адекватных вариантов не вижу... или не 1С
 
 Рекламное место пустует
   DGorgoN
 
31 - 04.02.21 - 09:49
(29) Понятно что есть и ньюансы, но на то вы и программист что бы их все предусмотреть. Прям всё шифровать не стоит.
   Kassern
 
32 - 04.02.21 - 09:50
(0) Как вариант без использования токенов и прочих девайсов, можно сделать так:
1) Развернуть еще одну базу 1с возможно с обменом с рабочей базой и поднять на ней веб сервис. Рабочая база будет слать запросы, где параметрами будет ключ доступа и отборы, а ответом будет приходить нужная таблица.
2)На сайте развернуть таблицу и через http соединение получать данные по принципу варианта 1.
Там где ссылки, можно хранить гуиды, чтобы по ним получить нужные данные в 1с.
   Kassern
 
33 - 04.02.21 - 09:52
(32) Чтобы избежать дублей, можно по хешу вычислять полученные от рабочей базы данные, если сумма совпадает, то не записывать
   fisher
 
34 - 04.02.21 - 10:13
(23) Если на каждый элемент справочника отдельный ключ, то где будут хранится ключи?
   Bigbro
 
35 - 04.02.21 - 10:20
(34) у каждого кто работает со справочником должен быть свой закрытый ключ - для ввода новых элементов. и все открытые ключи прочих работников - для дешифровки того что они внесли.
короче так себе архитектура. я бы на такое не пошел.
   El_Duke
 
36 - 04.02.21 - 10:27
(0) Самый страшный вид паранойи - это паранойя в начальственных главах.
Страшна она тем что не лечится, т.к. генеральный папа не бывает неправ. А в особо запущенных случаях генерит хотелки вида (0)
   vde69
 
37 - 04.02.21 - 11:49
(32) если данные можно получить в коде 1с в расшифрованном видеЮ значит их можно спереть кодом 1с, по этому работа с расшифрованными данными должна вестись в системе в которая не предусматривает внедрение кода (и CRC этой системы можно отслеживать антивирусом)

(35) да, архитектура убогая, но если подумать - можно сделать разумные хеши для поиска и обработки запросами без детализации сути.
Короче мы не знаем чего нужно автору, по этому точно совета дать невозможно.

ALL - если уж подходить к шифрованию серьезно - расшифрованные данные единомеметно не должны находится даже в памяти компа, и  расшифровка должна вестись внутри специальных защищеных от дебагов контейнерах или на спец железе, по этому задача работы с зашифрованными данными внутри 1с - это бред лишенный смысла, шифрование и работа с данными должна вестись НЕ СРЕДСТВАМИ 1с
   RomanYS
 
38 - 04.02.21 - 12:10
(37) по 3. мысль непонятна.
>> задача работы с зашифрованными данными внутри 1с - это бред лишенный смысла
Если речь про структурированные данные (справочники, документы, регистры), то да - бред.

Если же речь про работу с контейнерами, то большой разницы нет - в 1С встроены механизмы работы с шифрованием в т.ч. со внешними модулями. Если же есть какие-то требования по сертификации, то вроде для этих целей существует специальная платформа.
   fisher
 
39 - 04.02.21 - 12:20
(37) Если свести задачу не к "защититься от админа", а к "изъятая база будет бесполезна" (а сабж, кмк, именно про это), то появляются варианты.
Но дальше вопрос в степени паранойи. Ведь если шифровать только текстовые данные а по изъятой базе кровь из носу захотят получить оперативную информацию по сделкам - то и расшифровывать ничего не надо. Достаточно сопоставить хозяйственные операции с уже имеющимися оперативными данными.
   mistеr
 
40 - 04.02.21 - 12:21
(0) Колись, что за данные. Все типовые задачи давно решены. (Не всегда на 1С).
   Вафель
 
41 - 04.02.21 - 12:21
вангую - черная база
   mistеr
 
42 - 04.02.21 - 12:23
(41) Нет. Черная база это не один справочник.

Может кредитки.
   Вафель
 
43 - 04.02.21 - 12:27
(42) а за отчеты что скажешь?
   mistеr
 
44 - 04.02.21 - 12:28
(43) ХЗ
   repin_mike
 
45 - 04.02.21 - 12:29
(41) Нет, там операции по аффилированной структуре, аффилированность которой афишировать нежелательно
   Вафель
 
46 - 04.02.21 - 12:30
ну те практически не черная, но тоже самое что и черная
   Вафель
 
47 - 04.02.21 - 12:30
самый верный вариант - вести в отдельной базе
   d_monah
 
48 - 04.02.21 - 12:31
(43) Тут похоже семья компьютерщиков.Жена админит,муж програмит.Вот что то и хочет муж скрыть.Может контакты любовниц,может заначки (45) Не используйте 1с для этого,если там реальные деньги
   Вафель
 
49 - 04.02.21 - 12:31
а в одной базе - это РЛС.
теоретически можно чтобы РЛС менялся не при старте, а по паролю
   mistеr
 
50 - 04.02.21 - 12:32
(45) Админ в курсе про афиллированность?
   vde69
 
51 - 04.02.21 - 12:34
(45) бугагагагагагагага
афилированость колется не по базе, 

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



ну а так просто организации перименуйте в (1,2,3,4,) и будет счастье
   Megas
 
52 - 04.02.21 - 12:35
(0) Делали же шифрованные данные, внешними компонетами, если не ошибаюсь. Работает это достаточно медленно.
   Megas
 
53 - 04.02.21 - 12:36
(52) + тут вопрос что вы с этим справочником хотите дальше делать и как его использовать.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.