Как ограничить доступ пользователя с полными правами? #584247

Стоит задача ограничить доступ к данным пользователя с административными привилегиями. Даже в большой степени вопрос как ему запретить редактировать роли и создать юзера с нужной ему ролью?

Стоит задача ограничить доступ к данным пользователя с административными привилегиями. Даже в большой степени вопрос как ему запретить редактировать роли и создать юзера с нужной ему ролью?

А можно тупой вопрос, а зачем? Дайте пользователю не полные права.

отобрать полные права? не?

забрать у него админпривилегии.

забрать не получиться ибо она программер. и ему все равно придеться кое что делать в конфигураторе.

Побей ее немного. :-)

Дайте ей тогда базу без этих данных. Ограничивать в правах программиста в базе, в которой он пишет код - это какой-то клинический идиотизм.

Цветы, конфеты, билеты в кино/таетр )))

программист без прав))))))

Программер себе даже с ролью ТолькоЧтение сможет полные права сделать. Достаточно все действия перенести в привилегированный модуль.

Ты ее не обманешь..))

блин (в первом посте была допущена ошибка, вместо "она" следует читать он)

в офисе нет ни одного вменяемого сотрудника, который обновит рабочую конфигурацию тем, что программист наклепал в инструментальной ?

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

есть такая идея - при запуске проверять соответствие ролей пользователя с тем что записано в справочнике и завершать прогу(что то подобное реализована в 1с консолидации )

Сделай копию базы и хранилице, обновляй из хранилища роботом. Это даст гарантию от необдуманых косяков, но 100% защиты ты не получишь

Конечно. Программист ведь этот код ни в жисть не отключит.

не поможет. Вариант два или смериться или не давать доступ к рабочим данным

Что мешает программисту отключить эту проверку?

Следующий вопрос: "Как ограничить права себе"

вот в этом и трабла. ставить пароль на код? поставить таблице в Микроскуле только чтение ?

модуль закрыть паролем

А просто уволить не пробывали?

+1 можно отрезать руки или выколоть глаза))))

ага... а потом вообще у программиста 1С удалить 1С... т

речь не о конкретном программисте а о любом кто будет сидеть на этой должности.

16) модуль закрыть паролем- как запретить ему отключить проверку в ПриНачелеРаботы?

запретить ему программировать. Зарплату чтобы получал, а к базе не прикасался. Ни-ни.

И? Я просто вызов этой функции отключу, нафиг мне ваш модуль впился? :) Модуль приложения не запаролишь.

Может ли всемогущий бог создать камень, который сам же не сможет поднять? (с)

где можно почитать о структуре таблиц одинэс в скуль?

ещё раз есть только один путь не программировать в продуктиве и не давать доступ программисту к базе на сиквеле

Периодически подключайся к базе и проверяй список пользователей. Если что-то не так СМС + мэйл.

Удалить 1С, выкинуть комп, вести учет в тетрадке, которую прятать в трусы.

система протоколирования и так работает.

В СП

сколько остроумия блин.

СП?

А на что ты рассчитывал, задавая столь дурацкий вопрос?

какой вопрос, такой и ответ. Ты еще спроси, как повору ограничить доступ к плите.

на то что мне скажут что нибудь чего я не знаю:(

Если ты даже найдешь способ ограничить доступ, то специалист (Вам же нужен именно специалист). Это ограничение сможет обойти 100 и 1 способом.

Ипатовским методом только. Ипать, ипать и еще раз ипать за каждое неверное телодвижение в рабочей базе.

Самый правильный вариант. Сделал неправильно - вычли из зарплаты.

а если она только это и ждет :)

+ да, всё-таки лучший способ - взять программера девушку. Она точно не будет искать способы.

Выполнять процедуру публично.

Всем офисом?

и обязательно включить это в бизнес-процессы предприятия.

а Вы шалун ;)

Откройте для себя хранилище. Механизм автоматического резервного копирования и обновления рабочей конфигурации из хранилища реализован в типовых (ну или его можно допилить, чтобы обновлялась автоматом из хранилища). Прог ДОЛЖЕН работать только в базе разработки, где у него ДОЛЖНЫ быть полные права. Пускать прога в рабочую базу вообще нельзя. За данные отвечает только пользователь. При желании можно сделать полный обмен данными между рабочей базой и базой разработки (только получатель), если необходимо иметь актуальные данные для разработки и тестирования.

как вариант.

Что скажете о крпитовании части кода?

столь же нелепая затея, как всё, что ты нам впариваешь

Тебе в и написали уже приемлемые варианты. +100

маразм! Главное непонятно зачем.

но ведь если программер захочет навредить, он просто это сделает в программе, а эту программу запустит другой человек, который с полными правами.

конечно, но при этом останется cf и весь зловредный код

я таких работодателей называю идиотами с параноидальными наклонностями....

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

все. обсуждение думаю можно закрывать.

Так он код напишет чтоб эти данные на почту куда-то выложились ))))

Нет таких данных. Программист как врач или адвокат - не доверяешь, увольняй.

или вы дибила в программеры ищите? Проблема в недоверии к сотрудникам такого уровня

Ну слава богу. Посади его в темный подвал и еду выдавай еду по количеству строк кода. Обязательно монитор поставь не работающий.

Навредить как? Если речь идёт о преднамеренных деструктивных действиях, то ни какая защита не поможет против программиста, который конфигурирует базу. Вообще ни какая. Прог может вставить обработчик любого события в любое место конфы и рано или поздно его деструктивный код сработает. При чем от имени другого пользователя.

+1 Если захочет увидеть что не должен видеть, увидет.

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

+100 идешь к гинекологу и боишся что он пупок увидет :)

>> Нет таких данных. Программист как врач или адвокат - не доверяешь, увольняй. Это не так. Закрыть данные от прога можно.

И кто убирать будет?

Не должен видеть данных базы? Или кода?

не спорю, но тогда нужен еще один прог, который будет проводить аудит кода, который сделал этот прог.

При настройке плана обмена определяется какие таблицы (справочники, регистры, документы) в обмене учавствовать не будут. Конечно это весьма проблематично, учитывая, что они не в вакууме висят, а связаны с другими объектами (таблицами). Но это уже надо смотреть конкретную задачу.

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

а потом еще одного и еще, обязательно надо прогамера  от СБ, от учредителя и т.д.

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

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

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

+ нанять третьего программера, который пишет еще один план обмена?

Для написания плана обмена отдельный прог не нужен. Прикинь, ужас какой. :))

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

Да что за бред? Зачем другие какие-то программисты для написани яплана обмена? объясните мне тупому.

Можно исходить из данных, что программист просто не будет смотреть секретные данные. Тогда и делать ничего не надо.

А это спорное утверждение :) человеку свойственно любопытство.

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

Самое простое решение: договор о не разглашении комерческой (или иной) информации

Программист не должен работать с рабочей базой. У него там даже аккаунта быть не должно. Прог работает только с базой разработки, где данные неполные.

Кодер - да. Но не всегда обязанности программиста ограничиваются только написанием кода. Поддержку пользователей как делать на не актуальных и не полных данных?

а кто напишет этот план обмена? Уборщица? Или тупой админ? В общем есть только один вариант. НЕ брать никакого программера, а заказать всё во франче. Они всё сделают и уедут, и база им ваша не нужна.

Логичная страховка на случай неоправдавшего доверия сотрудника. Смысл работать с теми, кому не доверяешь? >> Я исхожу из того, что программист не станет писать закладки То есть ты ему доверяешь, XNL

Это административный вопрос. Но при желании его можно решить.

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

Да я не против. Просто если есть одно допущение, можно сделать и другое.

Вот именно, что административный вопрос пытаются решить техническими средставим.

>> кто напишет этот план обмена? Тот же самый программист. Не вижу тут проблемы. В момент внедрения и настройки плана обмена за спиной прога может посидеть полдня сотрудник СБ, если там действительно какие-то большие секреты.

От преднамеренных действий прога защиты почти нет. Ну или она слишком дорога.

что и требовалось доказать :)

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