Доброго всем.
Решаю небольшую хотелку заказчика. Подразумевается обмен между базами по средством веб-сервисов. Соответственно направил письмо "местным" админам, чтобы те поставили на сервер "Apache Server 2.4.x ". В результате получил ответ:

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

Мое личное ИМХО - бред. Есть реальные доводы по поводу снижения безопасности в данной ситуации?

Установка Apache на сервер и его ГРАМОТНАЯ настройка никоим образом не снижают безопасность сервера, не считая возможных дыр в реализации самого Apache (но что-то о них на каждом шагу не вспоминают).
Подключение сервера к интернет действительно снижает безопасность сервера, но опять же ГРАМОТНАЯ настройка шлюза до сервера и FireWall-а на сервере сводят к минимуму риски взлома.

поставить отдельный сервер для апача? не?

(1)  А кто это делать то будет и за сколько ? Выход - обмен  не на веб-сервисах , а на чем то ином .

пусть настроят проброс порта с наружи на этот сервис.
И вообще - задача админа - выполнять поставленную задачу, а не саботировать её по соображениям собственной криворукости.

+(3) По мимо решения прикладной задачи придется кому то решать  
задачи системные ... - это кто то делать будет ?

Соотвтетственно к задаче надо приступать тогда - когда  базы будут  смотреть в инет . А это  должны делать специально обученные люди .

(2) Не

(3) Тоже "не"

(4) Можно подробней про "настроят проброс порта с наружи на этот сервис"

???

(9) А ты потом подробно расскажешь про все это пославшим тебя админам?!

(9) Админам скажи эти волшебные слова.
Если не моймут - уволить и нанять других

(10) Сперва сам прочту - потом им расскажу :)

(11) я понимаю что такое проброс порта, но не представляю, как его пробросить на конкретный сервис? Можешь инфой поделиться?

Смотря что храниться на сервере, если какая-нить ЕГАИС, то вам за этот Апач руки по отрывают, а в случае потери базы, так вообще фирму закроют.
Так что, может админ не так уж и не прав. А то что апач благодаря своим дырам снижает защищенность сервера, - это 100%.

(13) Вот здесь : http://www.dlink.ru/ru/faq/68/275.html в стиле "для больших и маленьких" на примере Д-Линк. Правда я не понимаю как проброс порта может повысить безопасность сервиса?

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

(14) Если он так 100% снижает безопасность, то как же тогда 1С базы публикуют на этом веб-сервере?

(16) Давай доводы. Давай варианты решения! Очень внимательно слушаю.

(17) Ну на чем то же нужно публиковать. А вообще по возможности так лучше не делать.

(18) Ты лучше очень внимательно изложи задачу. Вполне возможно она также легко решается отправкой пакетов обмена по почте?
Насколько критичен именно онлайн обмен?

(18) то есть в интернет смотрят, так?
елементарно, примитивный ddos через твой вебсервис уложит сервер без особых затрат.
сам апач вполне надёжен, дыры - это скорее кривые настройки или сервисы/контент, с которыми он работает.

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

Кстати, а можно у 1С-web-сервиса спросить о наличие остатков на складе из интернет-магазина? И если да какое будет время отклика.

По уму - apache ставится на отдельную машину, а уже он сам обращается к Web-сервису на сервере 1С, чтобы, во-первых, не было прямого доступа к Web-сервису, во-вторых, оградить Web-сервис от множественных непонятных запросов.

(20)(21) Произвожу обмен между центральной базой и мобильным устройством. Обмен планирую реализовывать через веб-сервисы (Обмен через почту отметаем. ВПН-ка на мобильнйо платформе не поддерживается).

Т.е. мой веб-сервис будет выложен в инет и мобильная платформа будет слать туда данные,а так же получать ответы. Разумеется подразумевается некая авторизация по ID устройства + заложенный пароль.

(23) Это будет зависеть от реализации в коде 1С.

(23) можно. По времени отклика не замерял ,но думаю вполне вменяемое.

(23) Если в сервисе реализована соответствующая операция - почему нет? И в примерах по мобильному приложению такая операция вполне описана.

(25) Таки вам как раз и нужен посредник в виде Apache и php, чтобы всю авторизацию и обработку вёл он, а в базу 1С через Web-сервис уже шли за данными только тогда, когда это уже нужно.

(24) Ты предлагаешь отдельный сервер покупать специально под АПАЧ ?

(29) не совсем понял о чем ты...какой посредник?

(26)(27)(28) Надо будет глянуть, это же по-сути решение очень многих проблем, и с остатками и с дисконтами всякими...

(25) "подразумевается некая авторизация по ID устройства + заложенный пароль." Вообще для доступа к веб сервису 1С вполне достаточно имя и пароль пользователя базы, от которой опубликован сервис. То есть все штатно. То уже внутри самого сервиса он может отрабатывать "по ID устройства + заложенный пароль".

(30) Под apache вполне годиться любой компьютер с любой операционной системой.

+ Если админы не хотят, чтобы к основному серверу был хоть какой-то доступ из интернета, то придётся всё равно делать Proxy - или пробросом портов или http-proxy для запросов к Web-сервису.

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

(34)(35) По сути - для меня разницы НЕТ! Мне главное чтобы мой веб-сервис был доступен из вне. А какие там будут производиться манипуляции для этого - мне по барабану.

допускаю, что сервера вообще нет "по темже соображениям безопасности"

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

(0)[к тому же сервер в принципе отключен от интернета по темже соображениям безопасности. ]
админ прав

(0) Админ прав

(40) (41) И согласен сам на дискетках носить инфо извне ибо так надежнее?!
:)

(42) На дискетках и флэшках нельзя так как туда может вирус записаться , надо на перфокартах набивать или в тетрадках двоичными кодами записывать.

(39) :)
а как сервер хостера будет общаться с базой? получается теперь есть 2 точки для потенциальных атак - веб-сервер и сервер с 1с.

а, ну да. тут туннель можно поднять.

(42) Это уже другой вопрос.
1. Админ прав.
2. Владельцы бизнеса должны принять решение что им важнее - безопасность базы или онлайн доступ к данным. Т.е риски появляются дополнительные.
Если данные не сильно важны, то вперед и с песней. Ну например интернет магазин какой-нибудь. Да всех пофиг на его данные, главное чтобы заказы записывал.

А так ли нужен онлайн? Может модно обойтись офлайн обменом?

поднять апач на соседнем серваке не предлагать?

(47) Предлагать, но ток с большей конкретикой, плиз и обоснованием "+\-"!

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

(48) ну не нужно же сервак 1с выставлять наружу, этого же админы не хотят.
только есть не нулевая вероятность, что они и от этого варианта откажутся.

(49) И в чем принципиальная разница от того, что все крутится на одном физическом сервере?

все не прочитал...

(0) web сервер должен стоять в DMZ, если ты хочешь вывести сервер 1с в DMZ - то флаг тебе в руки, но админ ПРАВ!!!

(48) правильная схема такая
апач - отдельный сервак на нем стоит второй сервер 1с, за апачем стоит фаерворл.

SQL сервер общий, но на нем 2 базы

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

фаервол закрывает все порты кроме 1433, в случае взлома апача преступник получает доступ к урезаным данным и порту 1433 с учеткой только от базы 2.

(52)+ так-же в случае взлома основная база нормально работает,

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

(52) Фигасе ты разогнался...2 физических сервера, 2 1С сервера, 2 базы с последующей переброской данных в обе стороны...

(51) в том что в инет смотрит только один сервер, на котором кроме апача ничего нет.

(54) Все правильно. Тебе показали рост аппетитов из "небольшой хотелки заказчика". Ты только сделай и к тебе обратятся еще разок.

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

(55) Это я понял. Мне интересно какого уровня угроза может "нависнуть" над бедными людьми, если Апч и 1С будут крутиться на одном серваке.

(54) ты прочитай про DMZ, что это и ЗАЧЕМ она существует...

без нее ты безопасность не получишь ни при каких раскладах...

(58) например ddos атака, и у тебя сервер 1с для всей компании встанет колом....

или запрос 100000 конектов в 1с, и у тебя сервер лицензии закипит....

я тебе могу привести десятки угроз....

(59) Я не понял.. а где вообще у ТС требования насчет работы в публичном инете? Может это для корпоративной впн-локалки?

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

(52) Если будет 2 базы и между ними обмен. Т.е данные не актуальные в единицу времени. То нафига тогда вообще эта заморочка? Тогда делать офлайн обмен в базу сайте или чего там использовать ТС хочет.
Сервисы в 1С имеет смысл мутить только если нужен жесткий Онлайн.
К тому же не надо забывать что это сервис легко может положить на лопатки базу 1С (хотя бы DDOS) в которой работает контора. И получится что из-за какого то сран.ого мобильного приложения фирма встанет

(60) +

(60) а вариант с отдельным серваком на линуксе и апачем на нем. чтобы его выпустить в инет. а 1с с соседнего сервера публиковать на нем?

(65) при взломе этого отдельного сервака злодей попадает во внутренюю сетку, где любым снифером утащит все пароли....

для этого и ставится фаер, а как поставили - имеем DMZ

(66) а сервер 1с - относительно не сложно ломается на предмет получения пароля админа кластера....

(66) прочитал про DMZ... ух епт...

(67) а как можно что-то сделать с кластером 1с?
с SQL такой проблемы нет?

(66) А кто говорит, что сервер будет сразу во внутренней сети.
Можно поставить FireWall между Web-сервером и внутренней сетью.
Если мы предполагаем, что Apache точно взломают, то через FireWall будет сложнее пробраться, да и порты можно отфильтровать так, что только Web-сервис и будет доступен.
В любом случае, такое решение в случае DDOS-атаки не позволит положить основной сервер.

вот моя статья по этому поводу http://infostart.ru/public/303420/

(67) Неужели 1С хранит пароль кластера, а не его хеш? Пароль на СУБД, понятное дело, надо хранить используя обратимое шифрование, но зачем 1С пароль хранить открытым?

(52) дыра типа heardbleed и все твои танцы с разделением коту под хвост

(73) такие дыры редко бывают.
И разве MS SQL использует Open SSL?

(74) Это просто пример. Не одна дыра, так другая.

(75) дыры такого масштаба большая редкость. Уязвимость 0 дня штука неприятная, но её обычно патчат до того как она становится общедоступной.

Ну, на самом деле, если вспоминать про дыры, то получается:
1) Голый сервер очень мало уязвим, так как на нём ничего нет.
2) Ставим SQL-сервер, появляются дополнительные уязвимости, так как из SQL-сервера можно выполнять какой-то код на сервере.
3) Ставим 1С - тут сразу же начинает исполняться серверный код, из которого опять же что-то можно сделать - когда не было 1С - этой возможности тоже не было.
4) Ставим Apache - добавляется ещё возможность что-то сделать.

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

"я против установки апача на Сервер"...

А кто просил установить апач на Сервер? Пусть хоть на мобильник себе ставит и спит с ним, задача ведь - установить. Да и кто спрашивает, против там админ или просто лень(?)