Защита информации в облачных 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 для решения этих задач используется сразу несколько инструментов, которые не только позволяют добиться поставленных целей, но и, при всех их достоинствах, делают их не менее безопасными, чем десктопные приложения.
lair
А как же SSO и вообще федерация?
Это в какой «облачной CRM» так делают?
В смысле — все сессии этого пользователя, или конкретная?
На основании чего вы делаете вывод о «не менее безопасные»? Например, как вы оцениваете угрозу НДВ внутри SaaS решения, или вероятность злого умысла со стороны сотрудников SaaS-провайдера?
gydex Автор
А как же SSO и вообще федерация?
Во многих случаях нам как раз не требуется SSO и единый вход. Часто бывает необходимо дать одному и тому же человеку учетные записи с одним логиином, но разными паролями. И чтобы при входе с одним паролем вообще не было понятно, что существуют другие доступные базы по входу с тем же логином, но другими паролями.
Это в какой «облачной CRM» так делают?
В смысле — все сессии этого пользователя, или конкретная?
В данном случае — речь о конкретной текущей сессии. Если мы будем выбрасывать пользователя из системы по каждому непонятному поводу — то работать будет невозможно.
На основании чего вы делаете вывод о «не менее безопасные»? Например, как вы оцениваете угрозу НДВ внутри SaaS решения, или вероятность злого умысла со стороны сотрудников SaaS-провайдера?
В этой статье не идет речь о количественной оценке угрозы НДВ и сертификации программного продукта. Если такие меры необходимы, то их необходимо проводить как для десктопного, так и для облачного ПО.
lair
Кому «нам»?
Это у вас такое странное понимание multitenancy?
Как можно «разлогинить» пользователя, если он только проходит аутентификацию?
Тогда на основании чего вы делаете утверждение о том, что «облачные CRM» не менее безопасны, чем десктопные (кстати, противопоставление неверно, должны быть on-premise).
gydex Автор
Кому «нам»?
Нам — разработчикам и реализаторам ПО.
Это у вас такое странное понимание multitenancy?
А какое у вас понимание? Мы исходим из решения практических поставленных задач, а не академических терминов.
Как можно «разлогинить» пользователя, если он только проходит аутентификацию?
Вы не путайте авторизацию и аутентификацию, это разные процессы.
Тогда на основании чего вы делаете утверждение о том, что «облачные CRM» не менее безопасны, чем десктопные (кстати, противопоставление неверно, должны быть on-premise).
А где вы здесь видите противопоставление? Статья о мерах защиты, применяемых внутри облачных CRM-решений, призванных минимизировать угрозы несанкционированного доступа.
lair
Понимаете ли, в чем дело, что нужно разработчикам — никого не волнует. Простите за прямоту. Волнует то, что нужно заказчику — а заказчику регулярно нужно, чтобы его сотрудники логинились на свой компьютер, а дальше получали доступ к любой LOB-системе исходя из доменной учетки (ну и в обратную сторону: учетку в домене заблокировали — никто никуда больше не попадает).
У меня понимание простое — если в облаке есть компания А и компания Б, и в обеих есть сотрудник с логином jsmith, то есть явный способ определить, в какую компанию идет логин (без проверок на пароли).
Я и не путаю.
«В облачных CRM [...] делают их не менее безопасными, чем десктопные приложения.» Облачные CRM противопоставляются десктопным (что, как я уже писал, неграмотно).
Эта статья содержит конкретное процитированное мной утверждение. На чем оно основано?
gydex Автор
А нашим заказчикам нужно с точностью до наборот — разные пароли на одну учетную запись в разных системах. Причем, чтобы при работе в системе А не было ни намека на доступ в систему Б, но — при одинаковых логинах в двух системах. Может, в системе А собственник вредный дышит в плечо и ему нельзя показывать систему Б, или какие-то иные внутренние соображения.
Это не противопоставление, а в целом даже сравнение. В статье описан обзор мер защиты наших облачных систем. Многие из этих мер неосуществимы для десктопных систем, например, централизованное резервное копирование.
lair
Так все-таки, это multi-tenancy, plausible deniability или что-то третье? Я не понимаю, откуда требование на одинаковый логин.
(ну и да, то, что вы продолжаете игнорировать SSO, много говорит о спектре ваших заказчиков)
О, наконец-то вы озвучили, что это защита информации не в облачных CRM, а в ваших облачных CRM.
Вы продолжаете меня не слышать. Ок, пойдем с другой стороны: приведите пример широко распространенной сейчас «десктопной» CRM-системы.
gydex Автор
Мы не комментируем наших заказчиков.
Я дал ответ: главные представители ряда заказчиков не хотят запоминать несколько логинов, но не могут использовать единый вход в несколько доступных им систем по ряду внутренних причин.
Десктопные системы — не совсем корректно выразился. Речь об устанавливаемом на сервере у заказчика ПО. Взять то же 1С Предприятие.
lair
Что подтверждает мой тезис о том, что это не «защита в облачных CRM», а «у нас в CRM так сделано, и мы даже не можем объяснить, почему».
Я вам об этом с самого начала говорю — термин «десктопные системы» не на месте. Ок, следующий вопрос: а что неосуществимого в централизованном резервном копировании системы, установленной на сервере у заказчика?