Приветствую
Есть такой вопрос. Возможно ли как-то разграничить доступ к базам на 1С сервере Windows пользователям без внесения изменений в сами базы?
Т.е. чтобы пользователю А соответствовала база А1, а пользователю Б - Б1. Но при этом пользователь А никак не могу получить доступа к базе Б1, чтобы пользователь Б в не наворотил. И наоборот соответственно.

Создать им каждому пользователя в соот.базе, прописать виндовз-авторизацию.

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

(2) Чо? Читай (1) пока не прозреешь.

(3)п...ц

(0) срочно отойди от базы!

Я не хочу влезать в базу, есть возможность средствами платформы или сервера ограничить конкретному Windows пользователю доступ к конкретной базе, или нельзя?
Понятно что можно прописать Windows авторизацию для пользователей в базе, но это подразумевает наличие минимум двух пользователей в базе. 1С пользователя с правами админа и Windows пользователя. А вопрос в том можно ли ограничить доступ к серверу ДО авторизации в самой базе.

(6) нельзя если базы на одном сервере 1с

или в каждой базе только 1 пользователь windows? на уровне скуля можно

(2) какое изменение? Создание пользователей - это штатное действие с базой, не требует вмешательства в конфигурацию!

А если на разных можно?

(10) на разных серверах 1с - значит у вас 2 сервера 1с с купленными ключиками для них

(8) как? Обращается-то сервер, тем пользователем, которого указали при создании базы. На клиентское приложение это не влияет.

(9) Я что-то говорил про конфигурацию? Штатное действие не изменяет базу данных? Прочитайте пожалуйста вопрос и уточнения.

короче коннект к службе сервер 1с по определённому порту, соответственно для какого-то юзера можно закрыть порты, которые ему не нужны

(0) Хоть скажи, у тебя базы файловые или sql ?

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

(15) + не, туплю) так не прокатит

Воот, я уже весь мозг сломал

(14) 1С сервер не умеет работать с файловыми базами данных.

(13) Думал на этот счет, но это еще более менее катит если не надо автоматизировать. И если у тебя до 10 пользователей. Да и отдельный инстанс поднимать под каждого пользователя - жирновато.

(17) покури (13), если сервера 1с разные - соответственно у них разный ИП (имяхоста), для пользователя на уровне сети можно отрезать доступ, а-ля как доступ к шаре, только к ИП

(18) Некоторые сервером называют "вон тот шумящий ящик".
Переводи в файловую версию и раздавай права на каталог :)

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

и так, у тебя 10 юзеров. права на уровне сети раздавать накладно, а права в самой 1с - религия не позволяет? это самы нормальный вариант, или юзеры в базе из под "неавторизован" работают с полными правами?

(17) можно, для этого нужен анализатор IP пакетов.

для каждого юзера настраиваешь фаервол на запрет исходящего соединения с определенным началом содержания IP пакета.

правда никогда не встречал фаеров с такой фунцкией, но думаю что существуют...

(0) Почти у всех базах 1С есть разделение прав по организациям (РЛС) + как вариант создать ЦБ + РИБ организаций и раздавать права

в правах на доступ к папке

(21) больше 100 пользователей, работают с разных машин. Общий объем баз - 150 гб, средний размер базы - 400 мб. Да, файловый режим работы это то что мне надо =)))
Говорят новый 2012 сервер хорош в этом плане, но терзают меня смутные сомнения.

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

(24) Будет работать только в случае если соединение не шифруется, но вообще какое-то благородное безумство в этом проглядывает.

(25) Подразумевает вмешательство в структуру базы.

(26) Сервер баз данных, права на папку это хорошо, когда у тебя 3 базы и 10 пользователей.

(24)+ ммм даже лучше, фаер ставится на сервер где критится сервер 1с и рубится входящий трафик.

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

(27) соединение шифруется ВСЕГДА, но определить базу и пользователя - можно

(27)+(25) не подразумевается никакого вмешательства в код, 100%
А делать для 1С разгарничение через файл.системы и права на папки и на БД нелогично.

объясни нормально чем не нравится завести юзеров в 1с с вин-авторизацией?
или действительно у вас в базах вход без пароля? тогда это ахтунг натуральный

(31) Кому интересны простые пути?

(27) А если соединение внутри шифрованного VPN туннеля тоже можно?

(28) Ок, а если клиентом у нас терминальный сервер с которого ходит 10 клиентов, как мне их разграничить?

(29) В код нет, в базу да.

(31) Да не хочу я знать что там с авторизацией внутри базы + Например загружает пользователь свой dt со своими пользователями. Ему ремаппинг надо делать.

(32) Да, простых путей мы не ищем.

(32) Никому. Решение проблемы знают все. Здесь соревнование по it-изврату.

(32) Не по существу. Предложите свой вариант решения задачи.

> Да не хочу я знать что там с авторизацией внутри базы + Например загружает пользователь свой dt со своими пользователями. Ему ремаппинг надо делать.
У тебя юзеры свои базы на работу таскают? И какое тебе дело до их баз?

(33) Куда загружает? На сервер? А кто ж ему таких прав даст?

(36) + (37) Ну допустим у меня 10 злобных кодеров-фрилансеров. Которые работают на моих серверах с чужими базами. И мне не надо чтобы они ходили в базы друг друга. Но при этом мое участие должно быть минимальным. Т.е. кодер должен иметь возможность - создать базу, залить в нее любую конфигурацию или выгрузку. При этом соседний злобный кодер доступа к этой базе не должен иметь. И вообще, это не относится к вопросу. Это административный способ решения задачи, а меня интересует техническая сторона - возможно или нет. Походу нет.

Каждому свою виртуалку с своим сервером предприятия

Жирно будет. Нет, не так. Каждому виртуалку - значит программист может отожрать под свои задачи не 32 гб памяти, а только 4. А этого ему мало. Да и поддерживать 10 серверов сложнее. И масштабируемость хромает.

Не, ну можно, конечно, и 10 серверов предприятия в одной ОС запустить, для каждого прописать соответствующего администратора, но это не меньший изврат, чем (39)

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

(41) Короче говоря - отметаем. Кроме того, доступ к базе таким образом не защищен.

(42) Ну уж интерфейс для создания-удаления баз без доступа к консоли управления сервером 1С я смогу сделать.

(33)

>>> Ок, а если клиентом у нас терминальный сервер с которого ходит 10 клиентов, как мне их разграничить?

в КАЖДОМ (почти каждом) пакете виндовый логин имеется, причем в открытом виде, вне зависимости от авторизации.

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

на крайняк можно железку купить, циски точно это умеют делать....

eshkatot,
вирусописатель, не?

(44) + (45) Хм, да имя базы передается в открытую. Можно будет попробовать.

(46) Что вы, просто скромный админ. А вы, кстати, какое решение предлагаете?

(47) занизить собственные амбиции

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

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

(48) При чем здесь амбиции? Есть конкретная задача. Вот товарищ vde69 предложил костыльное, но имеющее право на жизнь решение.

(49) Насколько я понимаю (ни разу не разработчик 1С) это велосипед. Т.к. есть специальный режим 1С сервера, который это позволяет. v8: 1c и c#. Если не прав - поправьте.

(51) нет ты не прав,
1с реализовано как 2 разных DCOM сервера

первый - это управление кластером и тут требуется авторизация админа кластера/сервера

второй - рабочий, тут авторизация базы

ни первый ни второй сервер не позволяют реализовать сабж

---------------------

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

Вариант сделать через файловые базы, задать права на папку только конкретному юзверю, указать квоту, впустить через терминал с подключением домашней заданой папки, и все. Тогда будем иметь доступ только к 1-му себе ) как и надо.

непонятно:
1. Если ребята работают на сервере, значит у них есть логин и пароль на сервер и, как следствие, личная папка в которой делай что хочешь и никто доступа не будет иметь. Зачем тут еще куда то и как-то вмешиваться?
2. Если предполагается, что ребята будут ставить базу используя один кластер в сервере 1с и одну СУБД, то никто не мешает каждому из таким уникумов создать пользователей в скуле и чтобы только под ним они могли разворачивать базы. Соответственно другой пользователь не сможет удалить эту базу из скуля.

Конфликты:
1. В сервере 1с можно посмотреть все созданные базы и попытаться из клиента 1с к ним подцепиться, но если стоит любой пароль, тогда без доступа к БД в скуле, его никак не взломать.
2. Проблема 2, никто не мешает в сервере 1с из кластера удалить базы своих "коллег". Понятно, что сама БД будет жива и ничего не сложно прицепить заново БД в кластере, но это бесило бы, особенно если базы не просто для работы программера а еще и реально рабочие для остальных пользователей.

Вывод. Если вы можете сделать как написали в (43) то почему это все не взлетит?

(52) C 8.1 1С уже не DCOM.

а если запустить несколько процессов 1С на разных портах, и по  портам ограничить пользаков

Подниму тред, ибо решения все-таки пока не накопал. Смиренно прошу еще немного внимания.

(53) Через файловые не катит, т.к. пользователей много, базы большие, по сетке производительность не устраивает.

(54) Опять-таки речь идет о том чтобы уйти от файловой версии баз. А с использованием одного сервера возникает проблема. Хочется ограничить доступ к базе не внося изменений в структуру базы. Чтобы пользователь виндовый гарантировано не мог подключиться к чужой базе, даже если она пустая.

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

(57) Почему это через.файл не прокатит, если через терминал пустить, все будет норм со скоростью.

(57) Я за виртуализацию всего, как самое простое решение.

Твои требования противоречивы. Как будто на ходу придумываешь.

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

Добавим к этому (предположительно) Windows и SQL Server. И будем рассуждать логически.
Каждый пользователь должен иметь учетку Windows на сервере. OK, уже имеет.
Чтобы работать с базой, пользователь должен иметь учетку в базе SQL Server. Хотя авторизоваться он может виндовой учеткой.
Чтобы иметь возможность создать базу в SQL, пользователь должен быть SA! Либо ты сам будешь создавать им базы и учетки в них по требованию. Так как дать им sa ты не можешь, а создавать базы сам не хочешь, то выход - виртуализация.

Это мы еще до серверов 1С не добрались. С ними, кстати, можно более-менее нормально доступ разрулить. На каждого пользователя по кластеру, ты будешь администратором центрального сервера, а пользователь админом кластера. В чужой кластер залезть не сможет.

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

(59) Че это только SA? Просто дать права "GRANT CREATE DATABASE..."?

(57) вы в (43) написали, что сможете сделать "Ну уж интерфейс для создания-удаления баз без доступа к консоли управления сервером 1С я смогу сделать."

Соответственно они не смогут удалить уже созданные БД в кластере 1с других пользователей. Даже если к ним смогут подключиться, то 1с-ка спросит логин и пароль и они конечно не знают его. Узнать пароль на вход в 1с в SQL-ых версий без доступа в БД в СУБД никак нельзя.

Вам надо будет только каждому выдавать свой логин и пароль в MS SQL чтобы они там не имели доступа в базы созданные не ими.

(0) сделай для каждой организации, которая арендует площадку отдельный виртуальный сервер. Туда же локально поставь сервер приложений (или просто файловый вариант базы). На VMWare все очень просто разруливается)

(60) Могу и ошибаться. Так написано в желтой книжке.
(Если быть точным, не sa, а sysadmin)