Прячем 1С за огнеупорную стену

image Многие системные администраторы, задумываясь о безопасности данных своей компании и, в частности, о безопасности базы данных 1С, пренебрегают простым, но эффективным решением – изолировать сервер от пользователей. В данной статье проанализированы угрозы безопасности, возникающие при размещении клиентской части 1С и серверов 1С в одном сегменте сети, и рассмотрен процесс перевода серверной части 1С в другой сегмент сети. Данная статья не содержит принципиально новых решений, но может служить справочным пособием, которое объединяет информацию из различных источников.

Исходные данные

  • 1С Предприятие 8 клиент-серверный вариант;
  • сервер 1С Предприятия развернут на базе операционной системы Windows Server 2003;
  • 1С Предприятие использует выделенный сервер MS SQL, развернутый на базе операционной системы Windows Server 2003;
  • доступ пользователей к 1С осуществляется через терминальные сервера, развернутые на базе Windows Server 2003;
  • все сервера находятся в сегменте одной сети, развернутой на базе домена Active Directory.

Угрозы безопасности

Для выявления угроз безопасности составим схему движения трафика в имеющейся сети.
image
Рисунок 1. Исходные потоки трафика

Замечания к иллюстрации
  • Под «LDAP» подразумевается не один порт, а совокупность. Порты и протоколы, используемые в Active Directory, описаны в статье базы знаний Microsoft «Службы и сетевые порты в серверных системах Microsoft Windows». В зависимости от того, что терминальный сервер требует от контроллера домена, это могут быть разные наборы. В данной статье я буду использовать следующий набор портов и протоколов:
    Порт Протокол Назначение
    88 UDP Kerberos. Этот порт прослушивает процесс lsass.exe (Local Security Authority Service).
    135 TCP RPC
    139 TCP Служба сеансов NetBIOS
    389 TCP/UDP Локатор контроллеров домена
    445 TCP SMB
    1025 TCP Используется процессом lsass.exe. Дополнительная информация здесь.
    - ICMP ICMP используется для получения различной информации, поэтому пакеты данного протокола должны свободно проходить в направлении контроллеров домена.


    Данного списка достаточно для авторизации в домене и запуска netlogon-скриптов.
  • Под «SMB» подразумевается набор портов, с помощью которых реализуется обмен файлами по протоколу SMB. Данный набор портов является подмножеством набора «LDAP» и местами приведен для наглядности.
  • Под «RDP» подразумевается подключение по протоколу RDP. Для этого используются порты 3389:3390 (почему два – рассказано ниже).
  • Под «1С» подразумеваются порты, необходимые для работы клиента 1С с сервером. Это порты 1541, 1560:1591 (Информация о портах получена из «1С: Предприятие 8.2 — Клиент-серверный вариант Руководство администратора»).
  • Под «MS SQL» подразумевается порт для работы с сервером MS SQL (по умолчанию – порт 1433).

Что мы имеем:
  • операционная система Windows Server 2003 обладает уязвимостями, не связанными с 1С и MS SQL, но атаки с использованием этих уязвимостей могут способствовать получению контроля над данными перечисленных приложений;
  • пользователи могут передавать файлы из удаленного сеанса на компьютеры сети по протоколу SMB;
  • различные вирусы, распространяющиеся по сети, также создают угрозы безопасности;
  • так как пользователи находятся в одном сегменте сети с серверами, то особо умные могут пытаться соединиться с ними по портам MS SQL и 1C.

Задачи

  1. Минимизировать риски реализации уязвимостей операционной системы.
  2. Сделать невозможной передачу файлов по протоколу SMB с терминальных серверов на компьютеры пользователей.
  3. Исключить возможность доступа пользователей к серверам 1С и MS SQL.
  4. Минимизировать количество пользователей, которые могут передавать файлы на свои компьютеры по протоколу RDP.

Требования к реализации

Обеспечить простоту и удобство использования ресурсов 1С Предприятия.

Решение

Составим схему движения необходимых потоков трафика.
image
Рисунок 2. Необходимые потоки трафика
Как видно, для полноценного функционирования 1С нужно не так уж и много.
Компьютер Исходящие подключения Входящие подключения
AD DC Не требуются Все компьютеры сети
Сервер 1С Сервер БД 1С Терминальные сервера
Сервер БД 1С Не требуются Сервер 1С
Терминальные сервера Сервер 1С Пользователи

Из таблицы видно, что сеть можно разделить на три сегмента:
  1. «Сервер 1С» + «Сервер БД 1С»;
  2. «Терминальные сервера»;
  3. «Пользователи» + «AD DC».

Далее я буду использовать терминологию из «Information Technology Security Guideline. Network Security Zoning»:
Operation Zone (OZ) – стандартная среда для повседневных операций, в которой располагается большая часть пользовательских систем и серверов. Здесь может обрабатываться конфиденциальная информация, однако она не подходит для хранения больших массивов конфиденциальной информации или для критических приложений.
Restricted Zone (RZ) – обеспечивает контролируемую сетевую среду для критических сервисов или для больших массивов конфиденциальной информации.

Для выполнения задач 1-3 разделим сеть на несколько зон:
  1. RZ1C – в эту зону войдут «Сервер 1С» и «Сервер БД 1С».
  2. RZTS – в эту зону войдут терминальные сервера.
  3. OZ – в эту зону войдут контроллер домена «AD DC» и пользователи.

Прохождение трафика будем регулировать маршрутизатором, в который внесем необходимые правила.
image
Рисунок 3. Схема зонирования сети
Для решения задачи 4 выполним следующее:
  • на каждом терминальном сервере создадим новое подключение в дополнение к стандартному, оно будет функционировать на порту 3390;
  • разрешим подключаться на порт 3389 всем пользователям, а на порт 3390 только пользователям группы TerminalDisk;
  • в свойствах подключений на терминальных серверах отключим клиентам возможность подключать локальные диски на порту 3389 и разрешим подключать локальные диски на порту 3390.

Таким образом мы сможем разрешать подключать локальные диски только конкретным пользователям.

Реализация

Маршрутизация

В качестве маршрутизатора в этой статье я буду использовать компьютер с тремя сетевыми картами с операционной системой семейства GNU/Linux. Программное обеспечение для маршрутизации – Iptables. Скрипт настройки Iptables приведен ниже.
#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward
OZ=192.168.0.0/24
RZTS=192.168.2.0/24
RZ1C=192.168.1.0/24
ADDC=192.168.0.1
# Удаляем все имеющиеся правила
iptables –F
iptables –X
iptables –-flush
# Устанавливаем политику по умолчанию
iptables –P INPUT DROP
iptables –P OUTPUT DROP
iptables –P FORWARD DROP
# Разрешаем пакеты с состоянием ESTABLISHED и RELATED по протоколам TCP и UDP
iptables –A FORWARD –p tcp –m state --state ESTABLISHED,RELATED –j ACCEPT
iptables –A FORWARD –p udp –m state --state ESTABLISHED,RELATED –j ACCEPT
# Разрешаем протокол RDP в направлении OZ->RZTS
iptables –A FORWARD --src $OZ --dst $RZTS –p tcp --dport 3389:3390 –j ACCEPT
# Разрешаем DNS-запросы в направлении RZTS->ADDC, RZ1C->ADDC
iptables -A FORWARD –-src $RZTS --dst $ADDC -p udp --dport 53 -j ACCEPT
iptables –A FORWARD --src $RZ1C –-dst $ADDC –p udp --dport 53 –j ACCEPT
# Открываем порты для Active Directory
iptables –A FORWARD --src $RZTS --dst $ADDC –p udp --dport 88 –j ACCEPT
iptables –A FORWARD --src $RZ1C --dst $ADDC –p udp --dport 88 –j ACCEPT
iptables –A FORWARD --src $RZTS --dst $ADDC –p tcp --dport 135 –j ACCEPT
iptables –A FORWARD --src $RZ1C --dst $ADDC –p tcp --dport 135 –j ACCEPT
iptables –A FORWARD --src $RZTS --dst $ADDC –p tcp --dport 139 –j ACCEPT
iptables –A FORWARD --src $RZ1C --dst $ADDC –p tcp --dport 139 –j ACCEPT
iptables –A FORWARD --src $RZTS --dst $ADDC –p tcp --dport 389 –j ACCEPT
iptables –A FORWARD --src $RZ1C --dst $ADDC –p tcp --dport 389 –j ACCEPT
iptables –A FORWARD --src $RZTS --dst $ADDC –p udp --dport 389 –j ACCEPT
iptables –A FORWARD --src $RZ1C --dst $ADDC –p udp --dport 389 –j ACCEPT
iptables –A FORWARD --src $RZTS --dst $ADDC –p tcp --dport 445 –j ACCEPT
iptables –A FORWARD --src $RZ1C --dst $ADDC –p tcp --dport 445 –j ACCEPT
iptables –A FORWARD --src $RZTS --dst $ADDC –p tcp --dport 1025 –j ACCEPT
iptables –A FORWARD --src $RZ1C --dst $ADDC –p tcp --dport 1025 –j ACCEPT
# Разрешаем порты 1С
iptables –A FORWARD --src $RZTS --dst $RZ1C –p tcp --dport 1541 –j ACCEPT
iptables –A FORWARD --src $RZTS --dst $RZ1C –p tcp --dport 1560:1591 –j ACCEPT
# Разрешаем пинг, чтобы все работало
iptables –A FORWARD --src $RZTS --dst $ADDC –p icmp –j ACCEPT
iptables –A FORWARD --src $RZ1C --dst $ADDC –p icmp –j ACCEPT
iptables –A FORWARD --src $OZ --dst $ADDC –p icmp –j ACCEPT
# REJECT все остальное
iptables –A FORWARD –j REJECT
# REJECT еще раз
iptables –A INPUT –j REJECT


Замечания к скрипту

Действие DROP просто «сбрасывает» пакет и iptables «забывает» о его существовании. «Сброшенные» пакеты прекращают свое движение полностью, т.е. они не передаются в другие таблицы, как это происходит в случае с действием ACCEPT. Следует помнить, что данное действие может иметь негативные последствия, поскольку может оставлять незакрытые «мертвые» сокеты как на стороне сервера, так и на стороне клиента, наилучшим способом защиты будет использование действия REJECT особенно при защите от сканирования портов (Iptables Tutorial).

В случае если ключи HASP установлены не на терминальном сервере и менеджер лицензий находится в другой сети, необходимо выполнить несколько действий.
  1. Разрешить прохождение через маршрутизатор пакетов UDP и TCP по порту 475 в двустороннем направлении Сервер_лицензий<->Клиент_1С.

    iptables –A FORWARD --src СЕТЬ_КЛИЕНТА --dst МЕНЕДЖЕР_ЛИЦЕНЗИЙ –p udp --dport 475 –j ACCEPT
    iptables –A FORWARD --src СЕТЬ_КЛИЕНТА --dst МЕНЕДЖЕР_ЛИЦЕНЗИЙ –p tcp --dport 475 –j ACCEPT
    iptables –A FORWARD –-src МЕНЕДЖЕР_ЛИЦЕНЗИЙ --dst СЕТЬ_КЛИЕНТА –p udp --sport 475 –j ACCEPT
    iptables –A FORWARD –-src МЕНЕДЖЕР_ЛИЦЕНЗИЙ --dst СЕТЬ_КЛИЕНТА –p tcp --sport 475 –j ACCEPT

  2. Указать в файле nethasp.ini (должен располагаться в одной директории с исполняемым файлом программы) адрес сервера лицензий.
    --------------------- nethasp.ini-------------------------------
    [NH_COMMON]
    NH_TCPIP = Enabled
    ...
    [NH_TCPIP]
    NH_SERVER_ADDR = 168.192.1.10 // ip-адрес компьютера, где расположен Менеджер лицензий.
    NH_TCPIP_METHOD = TCP
    NH_USE_BROADCAST = Disabled
    ---------------------------------------------------------------


Сопоставление локальных дисков клиента

Посредством визуальных мастеров мы не можем просто так добавить новый прослушиваемый порт на терминальном сервере: для этого необходимо, чтобы эти подключения были доступны с разных интерфейсов, или по разным протоколам, о чем и говорит появляющаяся при попытке обмануть судьбу ошибка.
image
Рисунок 4. Попытка создать новое подключение с существующими параметрами
Однако нас такой вариант развития событий не устроит.
Стандартно подключение имеет название «RDP-Tcp», а информация о нем хранится в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\ИМЯ_ПОДКЛЮЧЕНИЯ
Для создания нового подключения необходимо:
  • экспортировать указанную ветвь реестра в файл с раширением *.reg;
  • открыть этот файл с помощью текстового редактора;
  • изменить в файле экспорта HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\ИМЯ_ПОДКЛЮЧЕНИЯ на HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\ИМЯ_ПОДКЛЮЧЕНИЯ2
  • найти в файле экспорта строку PortNumber и изменить числовое значение на 0xd3e (3390 в десятеричной системе, хотя можно использовать любой другой);
  • импортировать получившийся файл в реестр.

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

Заключение

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

Источники

  1. Information Technology Security Guideline (ITSG-38) – Network Security Zoning (Design Considerations for Placement of Services within Zones) — http://www.cse-cst.gc.ca/its-sti/publications/itsg-csti/itsg38-eng.html.
  2. Службы и сетевые порты в серверных системах Microsoft Windows — http://support.microsoft.com/kb/832017.
  3. Restricting Active Directory replication traffic and client RPC traffic to a specific port — http://support.microsoft.com/kb/224196/en-us.
  4. Руководство по iptables (Iptables Tutorial 1.1.19) — http://www.opennet.ru/docs/RUS/iptables/.
  5. How can I add a new RDP listening port to Windows 2000/2003 Terminal Server? - http://www.petri.co.il/add_a_new_rdp_listening_port_to_terminal_server.htm.
  6. 1С: Предприятие 8.2. Клиент-серверный вариант. Руководство администратора.
  7. 1C типичные проблемы при работе с HASP - http://itunion.com.ua/article.php?id=39.
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 29

    0
    Ну вот и первый минус. Жаль, что автор не решился его прокомментировать. А ведь, можно было бы учесть его пожелания и в дальнейшем избегать ошибок, которые он посчитал критическими для публикации.
    Москва ведь тоже не сразу строилась.
      0
      Извиняюсь за лишнюю запятую между «ведь» и «можно».
        0
        Скорее всего, тонкая душевная организация минусующего была расстроена, когда автор увидел в названии статьи «1С». Не обращайте внимания.
          0
          Я теперь тоже склоняюсь к этому мнению. Судя по всему, большинство тут не использует этот_продукт, а сидит на чем-то другом: крутом, дорогом.
          Но дело ведь не в том, что я обожаю продукты фирмы_котрую_тут_оказывается_нельзя_упоминать, а в том, что кто-то один купил, поставил, настроил это хозяйство, а кто-то другой, не имевший к этому процессу отношения, теперь должен думать о безопасности.
          +1
          Мелочи жизни. За комментарии в карму я получал минусы в карму и от яблочников и от вендузятников… А недавно даже от Убунтоидов парочку получил, несмотря на то, что сам системой пользуюсь как минимум не один месяц, если уже не год.
          +1
          > Прячем 1С за огненную стену

          К вашему сведению, Firewall (он же брандмауэр, [нем. Brandmauer]) — это не огненная стена, а противопожарная (огнестойкая) стена.
          В изначальном значении это слово означает глухую огнестойкую стену, разделяющую смежные строения или части строения в противопожарных целях, чтобы огонь не распространялся и не перекидвался от одного здания к другому. Только потом из инженерно-строительной терминологии это слово перекочевало в компьютерную терминологию.
            +1
            То есть это слово нельзя использовать в публикациях на компьютерную тематику?
            А еще нельзя немного иронизировать? И даже если специально для обозначения иронии прямо под заголовок вставлено соответствующее изображение?
              0
              Извиняюсь за резкость, был немного возбужден :) Спасибо за информацию, впоследствии буду учитывать это :)
              +1
              Хорошая статья, спасибо. Таки интересно, в процессе изменения рисунка 1 на рисунок 3 уменьшилась ли нагрузка на сеть? Спрашиваю из праздного любопытства ради общего развития.
                +1
                В целом не особо, так как единственное, что по сути могло повышать нагрузку — передача файлов по SMB с серверов на компьютеры, но она там не круглосуточная. Да и основной целью развертывания этой архитектуры было не снижение нагрузки на сеть :)
                0
                Очень логичное изложение.
                  0
                  Спасибо, старался учесть опыт двух предыдущих статей, которые провисели по две недели в песочнице и так и не потянули на инвайт :) Судя по всему, получилось.
                  +2
                  Как-то у вас очень коряво обозначены сетевые соединения (что на схеме, что в таблице сетевого доступа). У каждого соединения есть источник/инициатор соединения (source) и целевая cторона (target или destination), принимающая эти соединения. На схеме это обозначается стрелочкой (двусторонней в случае двунаправленного доступа), а в таблице доступа дополнительными колонками source/target. Это важно для понимания направления сетевых подключений и корректной настройки межсетевых экранов.

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

                  1) Port 88 TCP/UDP — для Kerberos. По умолчанию Kerberos, конечно, инициируется по UDP 88, но при некоторых условиях может переходить и на TCP 88. Лучше заранее это учесть в правилах сетевого доступа.

                  2) Port 389 TCP/UDP — для LDAP (UDP 389 — LDAP ping, TCP 389 — LDAP connection).
                  Если у вас настроен LDAP SSL, то дополнительно нужно ещё открывать 636 TCP.

                  3) Port 3268 TCP — если у вас на контроллере поднят и используется Global Catalog (если у вас в организации всего один AD-домен и нет Exchange-серверов, то Global Catalog может и не быть).
                  Если у вас настроен доступ к Global Catalog с использованием SSL, то нужно дополнительно открывать ещё и 3269 TCP.

                  4) Port 53 TCP/UDP — для DNS, если у вас DNS поднят на контроллере домена. Клиенты используют запросы к DNS-серверу по UDP 53 (DNS Lookup), поэтому от клиентов до DNS-сервера достаточно будет UDP 53. TCP 53 используется для общения между DNS-серверами, для трансфера DNS-зон и прочих AXFR-запросов.

                  5) Port 445 TCP — для SMB (windows file sharing). Иногда для работы SMB кроме TCP 445 рекомендуют ещё открывать UDP 445, но я лично не встречал в этом потребности, всегда было достаточно TCP 445.

                  6) Port 123 UDP — для NTP (для синхронизации времени с контроллером).

                  7) Port 135 TCP — для RPC endpoint mapper.

                  8) Port range: 1024-65535 TCP (для Win2003), 49152-65535 TCP (для Win2008/2008-R2) — широкий динамический диапазон TCP-портов для назначения их клиентским RPC-подключениям к сервисам Netlogon, LSA (NTDS), NTFRS.

                  В действительности клиенты по RPC подключаются к нескольким различным AD-сервисам на контроллере домена, а именно: Netlogon, LSA (NTDS), плюс для репликации файлов между Win2000/2003-контроллерами ещё используется сервис NTFRS (тоже по RPC). Для подключения клиентов к сервисам, работающим по RPC, используются динамически выдаваемые TCP-порты из широкого диапазона TCP-портов (в Win2003 порты выше 1024 до 65535, в Win2008/2008-R2 порты выше 49152 до 65535). При этом клиент сначала подключается к контроллеру домена по TCP 135, RPC endpoint mapper назначает клиенту конкретные порты из широкого диапазона, по которым ему следует подключаться к конкретным RPC-сервисам данного контроллера. А дальше клиент уже подключается к службам Netlogon и LSA (NTDS) по указанным ему TCP-портам. Разным клиентам для одних и тех же RPC-сервисов контроллер может выдать разные порты (из указанного широкого диапазона), т.е. одному клиенту сказал подключаться к Netlogon на порт TCP 1025, другому назначил для того же RPC-сервиса порт TCP 1026 и т.д. По умолчанию заранее неизвестно, какой именно порт и кому назначит RPC endpoint mapper. И это усложняет настройку правил сетевого доступа на файрволе.

                  Поскольку по умолчанию порты для RPC-подключений клиенту выдаются динамически случайным образом из очень широкого диапазона, то открывать такой огромный жиапазон сразу на файрволе — это совсем не вариант. Поэтому для открытия портов для данных RPC-сервисов на межсетевом экране нужно:
                  а) Либо, чтобы firewall (например, на стороне самого контроллера домена) слушал общение клиента с RPC endpoint mapper'ом и автоматически понимал, какие TCP-порты тот назначил для RPC-подключений конкретному клиенту, чтобы динамически менять правила и разрешать эти назначенные порты для подключений конкретного клиента.
                  б) Либо на стороне контроллеров домена заранее биндить все RPC-сервисы на конкретные TCP-порты (без динамического диапазона). А потом в статических правилах на файрволе добавлять разрешения на подключения клиентских машин к контроллерам домена на эти конкретные жёстко заранее назначенные TCP-порты.

                  Конкретный TCP-порт для каждого RPC-сервиса назначается в параметрах системного реестра на контроллерах домена, например, так (значения можно дать любые незанятые):

                  HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
                  «TCP/IP Port» = 50001

                  HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
                  «DCTcpipPort» = 50002

                  HKLM\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters
                  «RPC TCP/IP Port Assignment» = 50003

                  После этого RPC endpoint mapper будет выдавать всем клиентам без исключения именно эти значения TCP-портов для подключения к соответствующим своим RPC-сервисам. Соответственно в правилах на файрволе нужно будет разрешить TCP-подключения от клиентов к контроллерам домена именно на эти фиксированные порты (50001 и 50002), а если есть межсетевые экраны между контроллерами домена, то в оба направления разрешить подключения между контроллерами на фиксированные порты 50001, 50002 и 50003.

                  9) Port 3389 TCP — для подключений по протоколу RDP (можно открывать не со всей сети, а только с отдельных администраторских машин).

                  10) ICMP Echo Request/Reply — для обмена пингами, для диагностики, для поиска ближайшего контроллера перед применением групповых политик.

                  Вот этого джентльменского набора портов/протоколов будет достаточно для настройки в правилах межсетевого экрана разрешений на клиентские сетевые подключения к контроллерам домена. При наличии на контроллерах домена дополнительных сервисов (DHCP, DFS, SMTP и др.) в эти правила могут добавиться какие-то дополнительные наборы TCP/UDP-портов.

                  Если у вас в сети нет машин с Win9x/NT4, то клиентские подключения к контроллерам на TCP/UPD-порты 137, 138, 139 — не нужны. Забудьте о NBT (NetBIOS over TCP/IP) и прочее убогое наследие NetBIOS, сейчас вместо него везде достаточно только SMB (TCP 445).
                    0
                    Спасибо за развернутый комментарий.
                    Собственно, я и ожидал от хабра в первую очередь общения с более знающими людьми и обмена опытом.
                    Обязательно учту и переработаю в соответствии с вашими замечаниями. К сожалению, котелок в данный момент уже не очень варит :)
                      0
                      все верно, только забыли маленькую весч: печать с терминальных серверов:
                      1) через RDP (перенаправленные принтеры/easyprint) — глючно и/или тормознуто — но порты открывать не надо
                      2) screw driver (и прочие продукты) — это уже не MS + кому интересно — посмотрите на стоимость
                      3) печать на машины к которым подключены принтеры (обычная печать) — нужно открывание smb портов, что нивелирует безопасность
                      4) печать на принт-серверы — нужно открывание порта + не все принтеры работают
                      5) удешевление варианта 4 — печать на машины к которым подключены принтеры (через lpd) — нужно открывание порта + не все принтеры работают
                      6) аналогично 5, только через дополнительный эмулятор PS принтера, чтобы работало с большим количеством принтеров — костыли, но, бывает, единственный рабочий вариант.
                      7) идеал — все принтеры с поддержкой сети/с принтсерверами — нужно открывание 1го порта

                      Все вышеперечисленное написано с учетом реального опыта и работающих (поддерживаемых) систем. К сожалению, если есть ЗООпарк принтеров (+где есть win-принтеры и нет денег на их замену/приобретение screwdriver) с- пасает 6й вариант.
                        0
                        > все верно, только забыли маленькую весч: печать с терминальных серверов:

                        Каким образом печать связана с открытием сетевого доступа между клиентскими машинами и контроллерами домена? Я писал только об этом. А печать — это отдельный вопрос.
                          0
                          >доступ пользователей к 1С осуществляется через терминальные сервера, развернутые на базе Windows Server 2003

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

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

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

                            P.S. Из моих собственных наблюдений: как только пользователям говорят, что для выполнения какой-то опциональной процедуры ему придется обращаться в Службу Безопасности за разрешением (а некоторые вопросы будут проходить через руководство компании), да еще и с обоснованием, сначала начинается вой, а потом привыкают, и количество запросов становится настолько разумным, что их даже не особо влом и обработать.
                              0
                              Вы вообще смотрите, на что именно вы отвечаете?
                              В моём комментарии не было ни слова ни по 1С, ни про терминальные серверы, ни про печать. Я написал лишь об одном аспекте: сетевом доступе между рабочими станциями и контроллером домена. В ответ на это вы зачем-то мне написали, что в этой схеме я забыл про печать.
                            0
                            > через RDP (перенаправленные принтеры/easyprint) — глючно и/или тормознуто — но порты открывать не надо

                            Честно говоря, в данный момент тормозов печати в этом варианте не наблюдается. Это при обширной географии размещения клиентов и режиме работы приблизительно 14/6. Глюки, конечно, бывают. Но их количество настолько мало, что рассмотрение пунктов 2-7 в данный момент не требуется.
                              0
                              если парк принтеров причесан, то возможно (с кэнонами как дела? ;)) если печать нужна быстрая (например, на выписке оптового клиента) — то rdp-печать тормоз, по сравнению с другими
                                0
                                Большая часть принтеров именно Canon MF3228 — корпоративный стандарт. Большая часть клиентов, правда, сосредоточена в пределах одной области. Но и у клиентов из других областей проблем не наблюдается. А вообще — спасибо. Буду иметь ввиду :)
                          –1
                          Слово «сервер» во множественном числе будет «серверы», а не «сервера».
                            0
                            А можно пояснить?
                            Первые две ссылки, которые я нашел говорят об обратном:
                            dic.academic.ru/dic.nsf/rus_orthography/94077/%D1%84%D0%B0%D0%B9%D0%BB-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80
                            www.gramota.ru/slovari/dic/?all=x&word=%25F1%25E5%25F0%25E2%25E5%25F0
                              0
                              Они не говорят об обратном.
                              Если вы не в курсе, то в орфографических словарях приводится окончание существительных в родительном падеже ед.числа (нет чего? сервера). Это никак не говорит о том, что во множественном числе окончание должно быть -а.
                              Тракторы, компьютеры, серверы — именно такое правильное окончание во множественном числе.
                                0
                                Действительно, затупил.
                                Снимаю шляпу :) Я обязательно перепишу статью, учитывая все ваши замечания и с указанием вашего ника :)
                                Благодарю за конструктивные и содержательные комментарии.
                                  0
                                  Прошу прощения за некоторую сумбурность в расстановке знаков препинания. Весь день ужасно хочется спать, каждый комментарий по три раза пересматриваю перед отправкой и все равно где-то что-то забываю.
                              0
                              По-моему это профессиональный жаргонизм, как компАс (вместо кОмпас) у моряков. :)
                                0
                                Скорее это непрофессиональный жаргон =)) От этого «сервера» профи только морщатся.

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

                            Самое читаемое