Задача - требуется создать справочник, данные в котором должны быть зашифрованы, то есть прочитать их нельзя даже под админскими правами запросом, стало быть настройка прав доступа и поиграться с отображением данных на форме не подходит. В реквизитах и табличных частях справочника есть как примитивные типы, так и ссылки (на незашифрованные справочники и документы). После ввода пароля пользователь имеет возможность как открывать эашифрованные элементы справочника, так и формировать отчёты, в котором данный справочник фигурирует. Кто-нибудь уже реализовывал что-либо подобное?

(0) сслыки оставь, на простейшие типы шифр цезаря

Существует универсальный ректальный электрический расшифровщик элементов/данных.Так-что твоя идея не прокатит

Убери у справочника "Наименование", и будет он у тебя зашифрованным (точнее закодированным).
Для чтения - кодовая таблица. Отчеты можно декодировать во второй базе которая недоступна админу первой. Все остальное решается (2).

Убрать все права, создать новое право, дать нужному пользователю

(4) Одмин зайдет и добавит чебе прав

(5) а что мешает админу изменить код и сохранить себе незашифрованые данные, когда пользователь введет пароль?

(4) Как бы еще нужно тайную комнату без окон, конкуренты могут в бинокль смотреть.

(6) Админ <> погроммист!

(8) но программист=админ в большинстве случаев

(9) =электрик+телефонист+грузчик (не часто,но видал)

Требование защиты "от админских прав" - невыполнимое. А раз так, то нет смысла шифровать данные в базе. Достаточно формировать обфусцированное представление при отсутствии нужных прав.

Храни данные зашифрованными
http://catalog.mista.ru/1c/articles/1083158/

(0) может отдельная база и подключение как к внешнему источнику данных?

(12) Это очень смешное шифрование. Но от мамкиных взломщиков может и спасет.

(0) шифруй простейшей xorкой с автоключом.

(15) Свой шифроблокнот на каждое поле? В отдельной базе, что ли? :)

Ну я тоже догадываюсь, что постановка задачи на 90% бред, но тем не менее придётся это хоть как-то реализовывать.

(13) Спасибо за мысль, попробую копнуть в этом направлении. Сейчас крутятся мысли про заворачивание данных формы в xml, шифровании каким-либо симметричным алгоритмом и записи в отдельный реквизит справочника, но внешний источник данных может оказаться проще.

Так а что мешает админу посмотреть на скуле сырые незашифрованные данные?

(18) незнание тисипидамп и рабочее место оборудованное по требованиям АСТ ГОЗ

(17) Непонятны границы проблемы, которую ты решаешь. Вынесение секретных данных в отдельную базу - это не шифрование. Это перенос точки ответственности. Тогда непонятно как нужно защищать эту вторую базу.

(14) Это можно адаптировать , и мамкины сынки будут курит в стороне n-лет.

(20) Скорее всего что то связано с чернухой , бабло топ менеджерам , какие нить левые оплаты . Врядли - порнуха)))

в целом задача вполне реализуема, только про то, что с данным справочником можно будет работать внутри самой 1с придется забыть.


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

при необходимости прочитать потребуется токин, без него ни один крипто анализатор не поможет. То есть будет физический ключ !!!
Разумеется расшифровка идет не в 1с и отображение результата должно идти не в 1с а в другой системе.
вызывается

шифование 1 справочника - это шифрованый блокнот чтоли?
про какие отчеты речь идёт?
регистр то не зашифруешь

(23) Крипто-Про и Сертификаты.  Делали такое.

(23) А 1с тут зачем? В принципе можно придумать как упаковать зашифрованные данные в какой-либо контейнер (внутри 1С или нет), только смысл при этом в 1С теряется и преимущества (быстрая разработка, формы, запросы, разделенный доступ с блокировками...)

(23) похоже на рабочую схему. дико неудобную но тут уж как поставлена задача.

(23) Ну сейчас это и в 1С возможно. Есть поддержка ЭЦП и прочее. Сами данные шифровать можно. Т.е. без расшифровки строка будет вида "ыфвалаотивыаиорвыиаровыиаырвиаорыви52454" а после расшифровки "кам рит" к примеру. И в 1с возможно это будет использовать при вводе пароля/с помощью эцп/токена и проч.

в (23) правильный вопрос поднят - про дублирование.
то есть мы либо дублируем каждым кто вводит данные
либо должны расшифровать предварительно весь объем данных чтобы проверить нет ли уже в них того что мы бы хотели внести.
применяя соответствующий ключ для каждого элемента..
то есть в топку запросы, все в топку, тупо перебор поэлементно и обработка
с соответствующей производительностью.
мне кажется что постановку задачи надо менять.
делать отдельный защищенный контур и внутри нормально в нем работать, а не сваливать в одну кучу все и потом мучаться с разделением данных и дешифровкой на каждое обращение со скоростью беременной улитки работая.

(29) +100500
Если данные в зашифрованном контейнере, то смысла в 1С почти нет. Поэтому кроме (13) адекватных вариантов не вижу... или не 1С

(29) Понятно что есть и ньюансы, но на то вы и программист что бы их все предусмотреть. Прям всё шифровать не стоит.

(0) Как вариант без использования токенов и прочих девайсов, можно сделать так:
1) Развернуть еще одну базу 1с возможно с обменом с рабочей базой и поднять на ней веб сервис. Рабочая база будет слать запросы, где параметрами будет ключ доступа и отборы, а ответом будет приходить нужная таблица.
2)На сайте развернуть таблицу и через http соединение получать данные по принципу варианта 1.
Там где ссылки, можно хранить гуиды, чтобы по ним получить нужные данные в 1с.

(32) Чтобы избежать дублей, можно по хешу вычислять полученные от рабочей базы данные, если сумма совпадает, то не записывать

(23) Если на каждый элемент справочника отдельный ключ, то где будут хранится ключи?

(34) у каждого кто работает со справочником должен быть свой закрытый ключ - для ввода новых элементов. и все открытые ключи прочих работников - для дешифровки того что они внесли.
короче так себе архитектура. я бы на такое не пошел.

(0) Самый страшный вид паранойи - это паранойя в начальственных главах.
Страшна она тем что не лечится, т.к. генеральный папа не бывает неправ. А в особо запущенных случаях генерит хотелки вида (0)

(32) если данные можно получить в коде 1с в расшифрованном видеЮ значит их можно спереть кодом 1с, по этому работа с расшифрованными данными должна вестись в системе в которая не предусматривает внедрение кода (и CRC этой системы можно отслеживать антивирусом)

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

ALL - если уж подходить к шифрованию серьезно - расшифрованные данные единомеметно не должны находится даже в памяти компа, и  расшифровка должна вестись внутри специальных защищеных от дебагов контейнерах или на спец железе, по этому задача работы с зашифрованными данными внутри 1с - это бред лишенный смысла, шифрование и работа с данными должна вестись НЕ СРЕДСТВАМИ 1с

(37) по 3. мысль непонятна.
>> задача работы с зашифрованными данными внутри 1с - это бред лишенный смысла
Если речь про структурированные данные (справочники, документы, регистры), то да - бред.

Если же речь про работу с контейнерами, то большой разницы нет - в 1С встроены механизмы работы с шифрованием в т.ч. со внешними модулями. Если же есть какие-то требования по сертификации, то вроде для этих целей существует специальная платформа.

(37) Если свести задачу не к "защититься от админа", а к "изъятая база будет бесполезна" (а сабж, кмк, именно про это), то появляются варианты.
Но дальше вопрос в степени паранойи. Ведь если шифровать только текстовые данные а по изъятой базе кровь из носу захотят получить оперативную информацию по сделкам - то и расшифровывать ничего не надо. Достаточно сопоставить хозяйственные операции с уже имеющимися оперативными данными.

(0) Колись, что за данные. Все типовые задачи давно решены. (Не всегда на 1С).

вангую - черная база

(41) Нет. Черная база это не один справочник.

Может кредитки.

(42) а за отчеты что скажешь?

(43) ХЗ

(41) Нет, там операции по аффилированной структуре, аффилированность которой афишировать нежелательно

ну те практически не черная, но тоже самое что и черная

самый верный вариант - вести в отдельной базе

(43) Тут похоже семья компьютерщиков.Жена админит,муж програмит.Вот что то и хочет муж скрыть.Может контакты любовниц,может заначки (45) Не используйте 1с для этого,если там реальные деньги

а в одной базе - это РЛС.
теоретически можно чтобы РЛС менялся не при старте, а по паролю

(45) Админ в курсе про афиллированность?

(45) бугагагагагагагага

афилированость колется не по базе,

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



ну а так просто организации перименуйте в (1,2,3,4,) и будет счастье

(0) Делали же шифрованные данные, внешними компонетами, если не ошибаюсь. Работает это достаточно медленно.

(52) + тут вопрос что вы с этим справочником хотите дальше делать и как его использовать.