сности.
Операционные системы с ядром Linux защищены от вредоносных программ гораздо лучше Windows. Уже только привычка не работать в системе под учетной записью администратора снижает опасность заражения. Но… «Никогда не говори никогда» – это правило особенно актуально в области информационной безопасности. Создать эффективный вирус или руткит для Linux сложно, но отнюдь не невозможно. Вопрос в материальной выгоде вирусописателей. Более того, нет резона оставлять вредоносное ПО для Windows без внимания, если оно оказывается в «поле зрения» Linux-ПК, который, например, может служить почтовым, файловым и Web-сервером небольшой или даже средней по размеру организации. Зачем пропускать на компьютеры локальной сети вирусы, черви, ссылки на фишинговые сайты и прочий способный отравить жизнь простого пользователя код, если можно эффективно пресечь цикл его жизнедеятельности наименее затратным (во всех отношениях) способом?
Даже если речь идет о единственном ПК, работающем под управлением Linux, запуск антивирусного ПО не будет пустой тратой денег и аппаратных ресурсов. Избавить от застарелого «трояна» НЖМД с ценными архивными данными, снятый с древнего «пентиума», наконец-то списанного с баланса госорганизации? Проверить и пролечить, если потребуется, Windows-раздел на единственном в доме компьютере или ноутбуке? Для решения таких задач антивирусный пакет на Linux-ПК прекрасно подойдет.
В качестве такого пакета рассмотрим Dr.Web Desktop Security Suite для Linux (32– и 64-разрядные версии), уже изначально кросс-платформенный. Дистрибутив Dr.Web Desktop Security Suite для Linux (например, в виде бинарного файла с расширением. run или напрямую из репозитория) доступен на сайте www.drweb.com. Для установки достаточно загрузить дистрибутив, присвоить ему корректные права, запустить (потребуется пароль администратора системы!) и принять лицензионное соглашение. За развертыванием программы, получением и вводом ключа следует автоматическое обновление антивирусных баз.
Работа с антивирусом возможна как в графическом, так и в консольном режиме. В обоих случаях доступны детальные настройки ПО безопасности и управление всеми его компонентами. Так, Spider Guard резидентно размещается в оперативной памяти с момента запуска системы и постоянно проверяет файлы в режиме реального времени в соответствии с заданными настройками (отметим, что Dr.Web Desktop Security Suite для Linux запускается при каждом старте системы автоматически). Антивирусное ПО работает со списком исключений, что позволяет при необходимости заметно снизить нагрузку на компьютерное «железо».
Компонент «Сканер» позволяет (в режимах быстрой, полной или выборочной проверки) проверять файлы, расположенные на локальном компьютере и подключенных к нему сетевых дисках и внешних носителях, а также логические разделы целиком. И главные загрузочные записи (MBR) жестких дисков. Функция «Карантин» отвечает за временное хранение всех найденных подозрительных и зараженных файлов, а доступ к результатам работы антивирусных модулей осуществляет утилита «Отчет».
Даже самый прожженный линуксоид вряд ли сможет устоять перед обаянием Dr.Web Desktop Security Suite для Linux, запустив из командной строки подробнейшее руководство по эксплуатации этого ПО привычной командой man drweb. Доступна к тому же возможность редактирования конфигурационных файлов (в соответствии с документацией из каталога /opt/drweb/doc).
При необходимости Desktop Security Suite обеспечивает интеграцию с корпоративным продуктом Dr.Web Enterprise Suite. Антивирус легко настроить на работу в режиме централизованной защиты, подключившись к серверу антивирусной защиты компании. Сейчас такую возможность начинают использовать все большее число системных администраторов в различных структурах, а также поставщики Интернета, предоставляющие подключаемым к нему пользователям антивирусную защиту как услугу. А значит, еще больше рядовых пользователей ПК под управлением Windows получают возможность работать, отдыхать, играть в существенно более безопасной среде благодаря усилиям Linux-компьютеров, на которых развернут Dr.Web Desktop Security Suite для Linux.
Инфраструктура Решения и технологии
Разделение данных и другие новые возможности «1С: Предприятия 8»
Никита Зайцев
Выпуск новой версии технологической платформы «1С: Предприятие 8» обычно сам по себе не является поводом для тщательного рассмотрения и анализа новых возможностей. Мы привыкли к тому, что эволюционное развитие платформы в пределах старшей версии представляет интерес только для технических специалистов, не затрагивая напрямую пользователей и владельцев информационных систем. Но версия 8.2.14, представленная фирмой «1С» летом 2011 г., явно выделяется из общего ряда и заслуживает самого пристального внимания.
Механизм разделения данных
Наиболее серьезным и даже в некотором смысле революционным новшеством версии 8.2.14 стал механизм разделения данных, позволяющий разделять единую информационную базу «1С: Предприятия» на отдельные изолированные области и реализовывать такие сценарии, при которых пользователи будут работать в единой базе, но независимо друг от друга.
Архитектура множественных экземпляров
Для каких задач автоматизации может потребоваться такой механизм? Вот несколько типичных примеров.
Пример первый – компания предоставляет услуги бухгалтерского обслуживания. Каждый из бухгалтеров, находящихся в штате компании, ведет фискальный учет нескольких сторонних организаций, в качестве прикладного решения используется типовая конфигурация «Бухгалтерия предприятия». Понятно, что каждый из бухгалтеров должен обладать полным доступом к данным своих подопечных предприятий, но ему абсолютно незачем иметь доступ к данным других обслуживаемых компанией организаций даже на чтение.
Пример второй – компания предоставляет услуги аренды ПО по модели SaaS («software as a service», программное обеспечение как услуга). В качестве прикладного решения используется одна из типовых или отраслевых конфигураций «1С: Предприятия». Например, бизнес-центр может предложить своим арендаторам функциональность прикладного решения «Управление небольшой фирмой», полностью взяв на себя заботы о серверном оборудовании, поддержке работоспособности, регламентном обслуживании, установке новых версий конфигурации и т. д. Пользователями прикладного решения являются посторонние друг для друга организации – они, разумеется, должны иметь доступ только к своим собственным данным.
Пример третий, из текущей практики автора, – расчетно-кассовый центр предоставляет услуги биллинга и приема платежей. Прикладным решением служит конфигурация собственной разработки, пользователи – также сторонние и независимые друг от друга организации. Какие-то данные будут общими для всех пользователей (классификаторы, тарифы, нормативы), какие-то будут персональной собственностью пользователя (начисления, расчеты, платежи). Пользователи должны сосуществовать в едином информационном пространстве расчетного центра, но не иметь доступа к «чужой» информации.
Следует заметить, что в приведенных примерах, кроме, пожалуй, первого, собственно разграничение доступа к данным не является единственным, и, возможно, даже главным требованием. Это требование, по мнению автора, наиболее очевидно с точки зрения потребностей бизнеса, но с технической точки зрения не менее важно требование обеспечения такой архитектуры прикладного решения, при которой деятельность одного абонента не будет создавать технологических противоречий и помех деятельности других абонентов.
Нельзя сказать, что подобные задачи на платформе «1С: Предприятие» вообще невозможно было решить без специального механизма разделения данных. Разграничение доступа реализовать можно было и ранее, причем двумя принципиально разными способами.
Простое решение: развернуть для каждого пользователя (под пользователем здесь понимается именно предприятие-пользователь, а не отдельно взятый оператор) свою информационную базу, а взаимодействие между ними реализовать посредством механизмов интеграции, имеющихся в платформе. Например, задействовать механизм распределенной информационной базы (РИБ). В литературе по информационным технологиям такая архитектура определяется термином «multiinstance» (множественные экземпляры).
Это действительно очень простое решение, но оно обладает рядом серьезных недостатков. Во-первых, поддерживать и администрировать множество информационных баз значительно сложнее и дороже, чем одну. Во-вторых, регламентные процедуры (например, обновление индекса полнотекстового поиска или резервное копирование) также будут выполняться в каждой информационной базе, а это создаст дополнительную нагрузку на оборудование. В-третьих, практически всегда существуют какие-то общие для всех пользователей данные (в простейшем случае – классификатор банков и адресный классификатор). Эти данные необходимо хранить и поддерживать в актуальном состоянии в каждой информационной базе, как следствие – нужно будет позаботиться о синхронизации (не говоря о том, что разместить одну и ту же таблицу КЛАДР в сотнях баз данных явно не очень хорошая идея с точки зрения эффективного использования аппаратных ресурсов).
Архитектура множественной арендыНаконец, в некоторых задачах «суперпользователю» (предприятию-владельцу информационного пространства) требуется работать со всей совокупностью данных как с единым целым, например, расчетному центру, как минимум, нужно формировать консолидированную отчетность. Реализация такого требования влечет за собой как интенсивный обмен данными между узлами РИБ (что опять же означает дополнительную нагрузку на оборудование), так и дублирование данных не менее чем в двух разных базах.
Более сложное, но конструктивно более правильное решение – работать с единой информационной базой, а для изоляции «персональных областей данных пользователей» друг от друга использовать механизм RLS (Record Level Security, доступ на уровне записей). Преимущества этого решения зеркально повторяют недостатки первого: