Нужен совет коллективного разума. Ситуация: сервер 1с на ws2019, база в клиент серверном режиме, так же опубликована по web для удаленных юзеров (подключаются по vpn). Возникла необходимость добавить еще одну базу, и так же ее опубликовать для удаленных сотрудников. Но тут меня посетила мысль))) в теории если удаленный сотрудник работающий с базой А, узнает ссылку на базу Б, он может получить к ней доступ до момента авторизации, а далее если в базе А какой то нерадивый юзер использует пароль типа 12345, то сами понимаете…

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

(0) самое простое - политика паролей в 1С.

ничего не понял

Есть две ссылки на две опубликованные базы.
В каждой базе есть список пользователей.
Обычно админы не задумываются и почти каждый пользователь отображается в этом публичном списке.
На каком-то из пользователей вдруг окажется пустой или простой пароль.

Ну и какое отношение от база А к базе Б или наоборот?

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

(2) пользователь базы А, подключит к себе базу Б и начнёт перебирать пароли пользователей.

(4) так если список юзеров в базе Б раскрыт, а надется кто-то, кому попадание в ту самую базу Б будет интересно, но причем здесь наличие базы А ?
Конечно, перебор пользователей и паролей однозначно начнется с уже известных значений, которые есть в списке пользователей наверняка и к тому же они видны всем.

(0) А потом найдутся сотрудники, типа главбуха, котором необходим доступ в обе базы одновременно. Объявим их святым. В теории, да.

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

(0)Почему бы начать с того что 1С есть вои средства защиты.
1. Сложность пароля.
2. Не показывать юзеров в списке.

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

(7) Мимнимально хватит простого делегирования авторизации отдельному сервису. OpenID какой-нибудь или та же AD.
Ну или сколхозить fail2ban1С против подбора паролей по журналу регистрации =)

(9) Кстати, я вроде где то мельком видел, что в какой то платформе впилили защиту от брутфорса. Только вот номер не помню.

(2) Смысл в том, чтобы отделить базу А от базы Б. Пока в голове нарисовалась такая мысль, нельзя ли установить второй Apache на другой порт например. Тогда я смогу на маршрутизаторе этим управлять.. и вопросов нет.

(3) Домена к сожалению нет, а так вариант подошел бы.

(8) Такой вариант пришел в голову первый конечно. Но в идеале чтобы Юзеры баз А и Б вообще не знали о существовании друг друга.

(11) конечно можешь

(13) Сделай путь к базе через УИН.

(11) > Тогда я смогу на маршрутизаторе этим управлять

А есть какая-то связь между пользователями 1С и пользователями маршрутизатора?

(0) Совет: Перестать страдай фигней

(17) *страдать

(14) Второй Apache установить не дает, пишет уже установлен, идите лесом...

(15) А это как?

(16) у удаленных есть! Авторизация идет по VPN потом 1с

(20) Путь к базе будет http://server1c/1058b1ba-f9d4-403d-b302-de9f83b55f3f

(21) Так это у тебя авторизация рабочего места, а не сотрудника. Прикинь, Иванов зайдет с компьютера Петрова и введет в 1С кредишнлы Сидорова. Он кто?

(11) то, что ты сейчас здесь спрашиваешь никак не связано с вопросом "как отделить базу одну от другой". И вообще, отделять нечего. Они уже отделены, если это две разные публикации к двум разным базам.

При условии, что мы все одинаково понимаем слово _База_

(19) У всех работает у тебя нет. Странно. Читай мануалы как 2 апача на винду поставить.

(23)+ ... и при запуске vpn введет данные какого-нибуль Кызы-Оглы

(22) В связке с политикой паролей в 1с думаю хороший вариант будет! Спасибо за наводку.

Если надо совсем разделить то разные ip и разные домены на разных компах
Все остальное хрень какая то
Физически база может быть на одном но вход с разных сделать

(28)+ И да разные VPN

При публикации базы можно указать свое любое имя. Как пользователь Базы А узнает, что надо подключать базу "База_Б", а не "Б"???

А если он может подсмотреть параметры подключения у кого-то, то и всю остальную чушь с другими IP/портами он может точно так же подсмотреть.

(22) Дурдом, секьюрити бай обскурити...

А потом начальнику присылается письмо с ссылкой на какую-нибудь форму отчета/согласования, он тупо форвардит письмо с вопросом "эта чо" и все, ссылка утекла. И руками вводить ничего не надо.

(0) ИМХО, более чем достаточно в конфигураторе в параметрах информационной базы указать минимальную длину пароля, включить проверку сложности паролей пользователей, максимальное количество неуспешных попыток аутентификации (например, 5), коды дополнения имени пользователя при блокировке. Разумеется должно быть отключено у всех пользователей отображение имени в списке при входе. Имена для входа устанавливать так же сложные, а не "Ваня Иванов".
Это избавит от попыток входа перебором паролей.
Если пользователь аутентифицируется через AD, то разумеется настроить там аналогичные параметры и обязательную смену пароля каждые месяц-полтора.
Остальные меры считаю, мягко говоря, избыточными. Разнесение баз с разделением аутентификации и маршрутизации в сети конечно неплохо, но попахивает паранойей. Не говоря уже о том, что рано или поздно ссылки на базы утекут (специально или случайно и непреднамеренно).

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

есть ли решения типа fail2ban для винды?

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

+ к (32) https://its.1c.ru/db/v8320doc#bookmark:adm:TI000000994

Вроде как есть выход. Почитал мануал, можно в Apache несколько портов указать сразу.
Listen 80
Listen 8000

Ну а дальше уже на маршрутизаторе пользователям разных баз раздам разные пулы адресов и разрешу форвард только на нужные порты вот и все. Пока схема такая. Всем огромное спасибо!

(36) cmd
httpd /?
параметр -i -k

(36) И героически повесил на себя еще одну точку настройки. При добавлении пользователя в базу тебе придется перенастраивать правила на маршрутизаторе.

Строить защиту на том, что злоумышленник не знает, куда стучаться, бессмысленно. Он обязательно найдет, куда.

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

ОФФ.
Потом выяснится, что речь идёт о базах двух овощных ларьков на колхозном рынке, у которых один хозяин. А следующая ветка будет посвящена вопросам объединения двух отдельных баз УНФ в одну Управление Холдингом.

Ещё пара подобных тем и можно будет сделать вывод, что это реинкарнация ЛивингСтар настигла мисту очередной раз

(41) "Почитал мануал" (sic (36))

(38) там настраивать нечего, делов на 3 минуты. Пользователей там мало будет, до 5 чел.

(40) Дык. ЕРП уже есть - Вопрос по лицензированию 1с ERP а вот домена, к сожалению нет - см (12)

(43) > делов на 3 минуты
Ровно до той поры, пока ты в отпуск не уйдешь.

(39) там нет злоумышленников, по сути просто перестраховка.

(46) > перестраховка
Предоставление пользователям услуги безопасного секса в гамаке и на лыжах это, а не "перестраховка"

(43) >> Пользователей там мало будет, до 5 чел.

Божешь ты мой! Я то думал там какие-то мегабазы, куда даётся доступ сотням внешних сторонних пользователей, которые постоянно меняются, добавляются новые и отключаются старые.
А тут среди своих пяти пользователей не разораться. Которые ещё небось и сидят в одном кабинете и языками рассказывают друг другу больше секретов, чем можно было бы узнать, получив доступ к базам.

(48) о том и речь. Физически они в другом месте. Не растрепит там ни кто.

(34)
Если пользователь не авторизовался, то лицензия не съедается вроде

(49) Тогда как они вообще узнаю о существовании другой базы?
Какие-то одни противоречия.
Пользователи не знают о существовании друг друга, но могут узнать об адресе базы на сервере, о возможных именах пользователей в этой базе и даже потенциально возможных паролях.🤦‍♂️

По-моему, ты прост осам себе придумал несуществующую проблему и сам героически её решил. ИМХО.

(51) Думай как хочешь. Всех нюансов я тут не рассказывал, узнать могут элементарно, т.к. имя публикации = названию юрлица о существовании которого пользователи базы Б в курсе. Тупо вбить в браузере. Вот что бы от этого перестраховаться я и спросил. Уже чувствую что зря. Очень много комментариев не по теме от «специалистов».

(52) "имя публикации = названию юрлица о существовании которого пользователи базы Б в курсе" а зачем так?)

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

Ошибся, когда делалась публикация базы А

(52) Исходя, из твоей логики, более чем достаточно было бы просто поменять имя публикации. А не изобретать велосипед с квадратными колёсами.
Так что мнение моё о том, что ты сам себе придумал несуществующую проблему, только укрепилось.

(54) >> переделывать публикацию это вызовет кучу вопросов… проще решить проблему так.

Проще для кого?
В данный момент для тебя?
А что будут потом делать пользователи, когда (или если) ты уйдешь? Кто потом будет разбираться - как ты там настроил?
Фактор автобуса https://ru.wikipedia.org/wiki/Фактор_автобуса никто не отменял.

ОФФ. По поводу комментариев не по теме. Это миста. Тут даже специально в правилах прописано, что ветка не принадлежит автору с момента её публикации. Придётся смириться. ;)

(55) ну с А понятно, а с Б то??!1 лол

(52) Заведи еще пяток баз с разными названиями, тогда точно не угадают

(57) Чего не понятного то блин??? Б еще не публиковал даже. :))

(58) Нет ее еще в помине

(56) Не вижу ни чего такого, чтобы там сложно было разобраться. 2 правила в фаерволе или в таблице маршрутизации.

А вариант подключения удаленных пользователей по тонкому клиенту, минуя web сервер не подойдёт? Или они могут подключаться только из браузера?

(61) >> Не вижу ни чего такого, чтобы там сложно было разобраться. 2 правила в фаерволе или в таблице маршрутизации.

Я и не говорю, что это сложно.
Просто представь, что ты расстался с этим своим работодателем и на твоё место пришел другой человек.
Первое же заведение нового пользователя станет для него сюрпризом, когда пользователь, для которого всё корректно прописано не может с нового рабочего места попасть в базу. Не факт, что он сразу догадается, что надо ещё в фаерволе и таблице маршрутизации танцы устраивать.
Решение штатное, но нифига нетривиальное для данной задачи. Оно простое для того, кто его применил.

(63) мб другой человек не первый раз будет публиковать базу)

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

Но я б не стал, конечно же.

(62) из браузера

(63) да это вообще временное решение пока там мало юзеров(опять таки же, сколько это продлится по времени я не знаю. Как только дело пойдет само собой будет свой сервак итд. Говорю же, деталей много а вы цепляетесь. В принципе это хорошо, в споре рождается истина 😀👍🤝

(61) > Не вижу ни чего такого, чтобы там сложно было разобраться

Забавно это слышать от автора "Второй Apache установить не дает, пишет уже установлен, идите лесом.." =)

(65) И дополнительно ещё завязать выдачу внутренних IP (по которым идет проверка) в впн на имя пользователя. Ну, что бы уж точно с гарантией, да =)

(65) к одному интерфейсу тоже можно много айпи повесить и на них публиковать

(70)

Тогда по маку сетевухи?

Можно завиртуализировать web-серверы, на каждую публикацию отдельный, повесить на них жёсткие фильтры по ип и макам.
Тогда у злоумшленника появится еще одна проблема - узнать не только имя публикации, но и имя (адрес) самого сервера.
Идея бомба!

(71) И поднимать образ веб-сервера при первом обращении пользователя. Если у пользователя нет прав для разворота образа - он ничего не увидит.

(72)
а Вы знаете толк

(73) https://www.meme-arsenal.com/memes/601d190b881107f89552ac7cea5dafbf.jpg

(59) "Чего не понятного то блин??? Б еще не публиковал даже."
Ну так опубликуй и задай "хитрое" имя публикации для базы Б

(71) По маку сетевухи не выйдет =)) Надеюсь знаешь почему? (подсказка, мак живет до первого маршрутизатора)

(33) "есть ли решения типа fail2ban для винды?"
Недавно только ставил https://github.com/DigitalRuby/IPBan

(75) Да все уже, тему можно закрыть давно, а тут некоторые никак не угомонятся. Рад что тут так весело! Хороший форум (без сарказма)

(39) > Строить защиту на том, что злоумышленник не знает, куда стучаться, бессмысленно.
Иметь как один из элементов защиты - полезно. Фильтрует 99% ломоботов.

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

(50) съедается

(79) + Но это больше про поднять ssh на нестандартном порту и port knocking
Слишком уж много ботов туда молотит, хоть fail2ban и выручает.

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

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

(83) Тогда уж не первым стоит не apache а nginx

nginx быстрее,но разве им нужна скорость?

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

Чем не устраивает типовая защита через логин\пароль для авторизации на веб-сервере и указанием этих самых логинов\паролей в доп. параметрах подключения /wsn /wsp
Тогда до авторизации 1С дело не дойдет, пока не будет выполнена авторизация на веб сервере.