Защита информации в облачных CRM — ключевой камень преткновения в спорах между разработчиками SaaS и декстопных сервисов. Разберемся, как решают эту проблему представители первого лагеря.
Прежде всего, необходима физическая защита информации: чтобы сервер с данными не был похищен. Для этого сервера располагают в круглосуточно охраняемом дата-центре с видеонаблюдением и ограниченным доступом лиц в эти помещения. Туда допускается только ограниченный круг сотрудников, и ни представители клиентов, ни даже прочие сотрудники компании-разработчика не могут попасть туда.
Второй уровень физической защиты — обеспечение сохранности самих данных, содержащихся на этих серверах. Этот вопрос решается применением политики резервного копирования информации, которая предусматривает ежедневное автоматическое копирование базы данных и файлов CRM, а также — дважды в неделю — на отдельные иностранные сервера и локальный съемный носитель.
Передача данных тоже нуждается в защите, поскольку существует вероятность перехвата информации в момент ее транзита. Для облачных систем с веб-доступом актуально использование https-протокола с использованием SSL-сертификата. В результате шифрование траффика позволяет защитить данные системы от перехвата снифферами и т.п.
Каждый пользователь заходит в систему по выделенному ему логину и паролю. Программа автоматически определяет наличие доступных пользователю решений и организаций, и при их наличии предлагает ему выбрать базу для входа. Если такая программа только одна, то осуществляется вход в нее без дополнительных вопросов.
Данные паролей пользователей хранятся в базе данных в закрытом виде в виде хэша.
Во избежание похищения сессии авторизованных пользователей проверка логина и хэша пароля производится при загрузке каждой страницы системы. При непрохождении аутентификации пользователь автоматически разлогинивается из системы.
Один из удобных вариантов алгоритма, используемого при разработке CRM, основывается на положении «каждая операция в системе — это отдельный объект доступа». Этому объекту доступа, в свою очередь, можно назначать права для отдельных сотрудников. Эта модель близка к дискреционной политике управления доступом, что позволяет нам построить таблицу прав, строки в которой – это объекты системы, а столбцы — пользователи программы. На пересечении столбцов и строк ставится + либо -, что означает наличие, либо отсутствие доступа сотрудника к определенным объектам системы. Соответственно, у каждого пользователя получается свой отдельный столбец в этой таблице, реализуемый в программе как набор доступных ему действий.
Для облегчения понимания этой таблицы объекты системы разбиты на тематические группы.
Вот пример такой таблицы:
Интерфейс администрирования прав в CRM построен по аналогии с этой таблицей.
Таблица доступных прав автоматически формируется при аутентификации пользователя при загрузке каждой страницы CRM. При этом программа может проверить, есть ли право на то или иное действие у текущего пользователя или нет. Это делается одной строчкой кода примерно следующего вида:
Вызов этого метода применительно к показанной таблице позволяет выяснить, есть ли доступ к объекту 64 — просмотр списка номенклатуры у текущего пользователя.
Соответственно, программа покажет либо не покажет соответствующий раздел в системе.
Для ряда объектов системы требуется разграничение доступа по ролям. Роли отражают доступ к данным в системе согласно набору полномочий сотрудника в компании. Например, руководитель отдела имеет доступ к коммерческим предложениям, которые выставили все сотрудники его отдела, а каждый сотрудник — только к своим коммерческим предложениям.
Политика ролей закладывается при проектировании раздела программы и на программном уровне реализуется по принципу «черного ящика»: класс списка документов на основе профиля текущего сотрудника возвращает специальным методом список номеров доступных ему документов, либо, если раздел подразумевает большое количество документов, какие-либо формализованные правила для их фильтрации. Например, это могут быть параметры для выборки SQL-запроса к таблице базы данных, содержащих документы либо список сотрудников, к документам которых есть доступ.
Например, можно установить доступ к записям планировщика таким образом, что руководитель отдела сможет обрабатывать как свои записи, так и записи подчиненных сотрудников. В программе такой алгоритм доступа определяется с помощью простого метода:
Метод возвращает список сотрудников, записи которых видны заданному сотруднику. Список может быть подставлен в параметры выборки SQL-запроса к таблице базы данных, хранящей записи планировщика.
«Под капотом» этого метода содержится фактическая программная реализация всех политик ролей.
Для отдельных разделов программы реализовано разграничение доступа на уровне документов. Например, в файловом разделе можно управлять доступом к папкам на уровне отдельных пользователей: администратор системы может поделиться с сотрудниками любыми правами к папке (создание, удаление подпапок, загрузка, удаление файлов, перемещение папок и файлов), а сотрудник-создатель папки — только теми правами, которые ему в настоящее время выделены администратором.
Описанная выше функция реализована в виде кнопки «поделиться» у папки файлового реестра, которая вызывает окно вроде такого:
Например, мы работаем под «Сотрудником 2». Исключена возможность «выстрелить себе в ногу» — закрыть себе же доступ к папке: галочки в соответствующей строке неактивны. Столбец «Редактирование описания файла (свои файлы)» неактивен, т.к. у Сотрудника 2 нет таких прав в этой версии системы. Галочка же у него проставлена, т.к. для этой папки такие права ему все же выдали.
Факт любого доступа к любым данным программы фиксируется в системном журнале. Это позволяет администраторам отследить, кто получал доступ к каким данным. Сама запись системного журнала имеет следующие поля:
Системный журнал в программе может быть отфильтрован по любому из перечисленных полей.
Вот так может выглядеть системный журнал. В нем, в частности, показано, что Сотрудник 2 удалил определенные права у Тестового сотрудника:
Благодаря структуре общего журнала, в программе реализованы журналы событий для каждого документа — например, журнал событий счета. Изучив этот журнал, можно узнать, кто вносил какую информацию, когда, какие действия совершал конкретно по данному документу.
Кроме того, в CRM доступен отчет «Активность пользователей». Он позволяет выяснить время работы заданного сотрудника в заданный период: общее, по дням, по сессиям, и просмотреть полный журнал событий по данному сотруднику.
Наконец, с помощью журнала событий CRM создаются программные модули отчетов (в виде таблиц и графиков) о реальном времени работы сотрудников в системе. Эта функция позволяет контролировать использование рабочего времени сотрудника.
Покажем пример такого графического отчета:
Таким образом, система защиты информации в CRM преследует несколько основных целей: с одной стороны, она должна исходить из того, чтобы каждый сотрудник имел доступ к данным, необходимым ему для работы (и был застрахован от их случайного повреждения или удаления), а с другой стороны, необходимо защитить коммерческую информацию компании от несанкционированного доступа. В облачных CRM для решения этих задач используется сразу несколько инструментов, которые не только позволяют добиться поставленных целей, но и, при всех их достоинствах, делают их не менее безопасными, чем десктопные приложения.
Физическая защита
Прежде всего, необходима физическая защита информации: чтобы сервер с данными не был похищен. Для этого сервера располагают в круглосуточно охраняемом дата-центре с видеонаблюдением и ограниченным доступом лиц в эти помещения. Туда допускается только ограниченный круг сотрудников, и ни представители клиентов, ни даже прочие сотрудники компании-разработчика не могут попасть туда.
Второй уровень физической защиты — обеспечение сохранности самих данных, содержащихся на этих серверах. Этот вопрос решается применением политики резервного копирования информации, которая предусматривает ежедневное автоматическое копирование базы данных и файлов CRM, а также — дважды в неделю — на отдельные иностранные сервера и локальный съемный носитель.
Защита на уровне передачи данных
Передача данных тоже нуждается в защите, поскольку существует вероятность перехвата информации в момент ее транзита. Для облачных систем с веб-доступом актуально использование https-протокола с использованием SSL-сертификата. В результате шифрование траффика позволяет защитить данные системы от перехвата снифферами и т.п.
Авторизация в системе
Каждый пользователь заходит в систему по выделенному ему логину и паролю. Программа автоматически определяет наличие доступных пользователю решений и организаций, и при их наличии предлагает ему выбрать базу для входа. Если такая программа только одна, то осуществляется вход в нее без дополнительных вопросов.
Данные паролей пользователей хранятся в базе данных в закрытом виде в виде хэша.
Во избежание похищения сессии авторизованных пользователей проверка логина и хэша пароля производится при загрузке каждой страницы системы. При непрохождении аутентификации пользователь автоматически разлогинивается из системы.
Система прав и объектов
Один из удобных вариантов алгоритма, используемого при разработке CRM, основывается на положении «каждая операция в системе — это отдельный объект доступа». Этому объекту доступа, в свою очередь, можно назначать права для отдельных сотрудников. Эта модель близка к дискреционной политике управления доступом, что позволяет нам построить таблицу прав, строки в которой – это объекты системы, а столбцы — пользователи программы. На пересечении столбцов и строк ставится + либо -, что означает наличие, либо отсутствие доступа сотрудника к определенным объектам системы. Соответственно, у каждого пользователя получается свой отдельный столбец в этой таблице, реализуемый в программе как набор доступных ему действий.
Для облегчения понимания этой таблицы объекты системы разбиты на тематические группы.
Вот пример такой таблицы:
Интерфейс администрирования прав в CRM построен по аналогии с этой таблицей.
Таблица доступных прав автоматически формируется при аутентификации пользователя при загрузке каждой страницы CRM. При этом программа может проверить, есть ли право на то или иное действие у текущего пользователя или нет. Это делается одной строчкой кода примерно следующего вида:
$au->user_rights->CheckAccess(64);
Вызов этого метода применительно к показанной таблице позволяет выяснить, есть ли доступ к объекту 64 — просмотр списка номенклатуры у текущего пользователя.
Соответственно, программа покажет либо не покажет соответствующий раздел в системе.
Разграничение доступа в CRM на уровне документов по ролям
Для ряда объектов системы требуется разграничение доступа по ролям. Роли отражают доступ к данным в системе согласно набору полномочий сотрудника в компании. Например, руководитель отдела имеет доступ к коммерческим предложениям, которые выставили все сотрудники его отдела, а каждый сотрудник — только к своим коммерческим предложениям.
Политика ролей закладывается при проектировании раздела программы и на программном уровне реализуется по принципу «черного ящика»: класс списка документов на основе профиля текущего сотрудника возвращает специальным методом список номеров доступных ему документов, либо, если раздел подразумевает большое количество документов, какие-либо формализованные правила для их фильтрации. Например, это могут быть параметры для выборки SQL-запроса к таблице базы данных, содержащих документы либо список сотрудников, к документам которых есть доступ.
Например, можно установить доступ к записям планировщика таким образом, что руководитель отдела сможет обрабатывать как свои записи, так и записи подчиненных сотрудников. В программе такой алгоритм доступа определяется с помощью простого метода:
$viewed_ids=$_plans->GetAvailableUserIds($result['id']);
Метод возвращает список сотрудников, записи которых видны заданному сотруднику. Список может быть подставлен в параметры выборки SQL-запроса к таблице базы данных, хранящей записи планировщика.
«Под капотом» этого метода содержится фактическая программная реализация всех политик ролей.
Разграничение доступа в CRM на уровне документов по пользователям
Для отдельных разделов программы реализовано разграничение доступа на уровне документов. Например, в файловом разделе можно управлять доступом к папкам на уровне отдельных пользователей: администратор системы может поделиться с сотрудниками любыми правами к папке (создание, удаление подпапок, загрузка, удаление файлов, перемещение папок и файлов), а сотрудник-создатель папки — только теми правами, которые ему в настоящее время выделены администратором.
Описанная выше функция реализована в виде кнопки «поделиться» у папки файлового реестра, которая вызывает окно вроде такого:
Например, мы работаем под «Сотрудником 2». Исключена возможность «выстрелить себе в ногу» — закрыть себе же доступ к папке: галочки в соответствующей строке неактивны. Столбец «Редактирование описания файла (свои файлы)» неактивен, т.к. у Сотрудника 2 нет таких прав в этой версии системы. Галочка же у него проставлена, т.к. для этой папки такие права ему все же выдали.
Отчеты по безопасности
Факт любого доступа к любым данным программы фиксируется в системном журнале. Это позволяет администраторам отследить, кто получал доступ к каким данным. Сама запись системного журнала имеет следующие поля:
- Дата действия
- Название действия
- IP-адрес, с которого совершено действие
- Пользователь, совершивший действие
- Затронутый пользователь (если есть)
- Затронутая группа пользователей (если есть)
- Использованные права из таблицы прав
- Код затронутого документа
- Комментарии (содержат значения обновленных полей, пояснения к действию и т.п.)
Системный журнал в программе может быть отфильтрован по любому из перечисленных полей.
Вот так может выглядеть системный журнал. В нем, в частности, показано, что Сотрудник 2 удалил определенные права у Тестового сотрудника:
Благодаря структуре общего журнала, в программе реализованы журналы событий для каждого документа — например, журнал событий счета. Изучив этот журнал, можно узнать, кто вносил какую информацию, когда, какие действия совершал конкретно по данному документу.
Кроме того, в CRM доступен отчет «Активность пользователей». Он позволяет выяснить время работы заданного сотрудника в заданный период: общее, по дням, по сессиям, и просмотреть полный журнал событий по данному сотруднику.
Наконец, с помощью журнала событий CRM создаются программные модули отчетов (в виде таблиц и графиков) о реальном времени работы сотрудников в системе. Эта функция позволяет контролировать использование рабочего времени сотрудника.
Покажем пример такого графического отчета:
Резюме
Таким образом, система защиты информации в CRM преследует несколько основных целей: с одной стороны, она должна исходить из того, чтобы каждый сотрудник имел доступ к данным, необходимым ему для работы (и был застрахован от их случайного повреждения или удаления), а с другой стороны, необходимо защитить коммерческую информацию компании от несанкционированного доступа. В облачных CRM для решения этих задач используется сразу несколько инструментов, которые не только позволяют добиться поставленных целей, но и, при всех их достоинствах, делают их не менее безопасными, чем десктопные приложения.