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

Штатно? если только отнять у него ПолныеПрава и раздать все остальные.
Но это не точно

(0)[я уже долго воюю с данным вопросом]
ты проиграла

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

(0) Полные права, на то и полные, чтобы делать все.
Администратор - всегда может добавить себе любые права.
А администратор СУБД может забрать себе домой базу.
Если хотите что бы администратор не видел части данных, вынесите эти данные в другую базу, и не давайте ему туда доступ.

(0)(4)
ИМХО
Внешняя компонента + шифрование, иначе никак.

Захотелось пофлеймить :)
Еще варианты:
NDA с администратором
Доверять ключевым людям в компании
Пусть администратором будет директор/учредитель

(5) имхо, слишком сложно и дорого.
(0) Юля, а каков размер компании и бюджет на эту фичу? Ну просто любопытно. И порядок сумм, которые хотите спрятать.
Да и еще, это же не БП и вы не прячете обороты по одному из счетов?

биржа небось?

(0) Создай пользователя с именем Админестратор, всего делов )

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

(2) Расскажи, пожалуйста - решена ли эта проблема в более дорогих системах?

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

Смотри фреш. По факту все работают в одной базе, но доступ разграничен через области

в 1с то никак .. или полные права со всеми данными или все самому.

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

Помню еще лет 20 назад .. слышал фразу какого то спеца не из 1с .. какая говорит прекрасная программа .. мы говорит всем отделом ей зарплаты в своем холдинге смотрим

(13) Плохо, когда не только мозги, но и руки кривые?

(16) ну что ты можешь сделать против пользователя с полными правами то ?

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

(17) Забрать полные права, разумеется.
И надавать по рукам тем, кто их даёт. См (14) в программе твоих кумиров это сделали. И в 1с то же можно сделать.

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

(19) у кумиров шифрование , кстати

(20) Если задача поставлена криво, то это проблема задачи.

(22) ну оно не крива сформулирована .. так обычно формулируют люди которые не понимают к чему такое ведет.
Вот например ты закрылся стойким алгоритмом, дал ключ одному человеку .. а он в аварию попал. И все .. конец всем сокровищам спрятанным от глаз.
Тут конечно попроще, но смысл то тот же .. хотим что бы админ нашей базы не видел что мы там творим ..
ну так админте ее сами .. какие вопросы

(0) Именно в данной формулировке решить задачу невозможно.
Меняйте постановку и/или подход к решению. И тут возможны различные варианты.
Но все они не будут на 100% идеальными. Т.к. специфика 1С заключается в том, что всё равно должен оставаться хотя бы один пользователь, который будет иметь самые что ни на есть полные права с доступом везде, ко всему и всегда. Хотя бы на тот случай, если придётся базу чинить и восстанавливать (остальное - типа накатывания обновлений и всяческие регламентные процедуры - можно автоматизировать).

Затея стоит недёшево. Имеет смысл только, когда речь идёт о каких-то данных с реально высокой степенью критичности их утечки.

+ к (24). Единственный более или менее реальный способ ограничения - не допускать к базе данных пользователей с полными правами, от которых что-то должно быть скрыто.
Реализовать это можно только таким образом, чтобы разработчики и админы разрабатывали и тестировали код на базах, из которых критичная информация полностью или частично удалена или обфускцирована до уровня, при котором понять и корректно интерпретировать её невозможно (иногда по сути - до уровня мусора).
Код после разработки и до перевода в продуктив должен подвергаться аудиту и тестированию на безопасность. И делать это должны отдельные независимые люди, а не сами разрабы, и тоже на тестовых даных.
Перевод любой разработки в продуктив должен проводиться человеком (или под присмотром человека), который имеет доступ к критичной информации.
Есть ещё вариант автоматизировать перевод проверенного и доверенного кода в продуктив без участия человека. Но настраивать такую автоматизацию всё равно придётся человеку, имеющему доступ.
Такой подход крайне проблематичен, т.к. постоянно возникает вопрос с отладкой сложных алгоритмов на реальных данных (т.к. на тестовых всё обычно работает гладко), поиском ошибок пользователей в реальных данных и т.д. и т.п. Ну и естественно возникает куча дополнительных затрат времени и труда на все промежуточные шаги (подготовка тестовых и разработочных баз с тестовой информацией, аудит безопасности кода, контроль на всех этапах от подготовки разработочной базы до перевода в продуктив). Даже если максимально автоматизированы каждый из этапов.
Ну и само собой админы на серверах, где стоит СУБД и 1С, админ СУБД, админ (владелец) базы на сервере СУБД, админ кластера серверов 1С и рабочих серверов 1С, и админ базы данных - всё это должны быть разные люди или хотя бы разные учетные записи, чьи действия подвергаются аудиту и логированию с архивированием логов и невозможностью их удаления.

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