Многоуровневая защита информации в облачных CRM

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

Физическая защита


Прежде всего, необходима физическая защита информации: чтобы сервер с данными не был похищен. Для этого сервера располагают в круглосуточно охраняемом дата-центре с видеонаблюдением и ограниченным доступом лиц в эти помещения. Туда допускается только ограниченный круг сотрудников, и ни представители клиентов, ни даже прочие сотрудники компании-разработчика не могут попасть туда.

Второй уровень физической защиты — обеспечение сохранности самих данных, содержащихся на этих серверах. Этот вопрос решается применением политики резервного копирования информации, которая предусматривает ежедневное автоматическое копирование базы данных и файлов 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 для решения этих задач используется сразу несколько инструментов, которые не только позволяют добиться поставленных целей, но и, при всех их достоинствах, делают их не менее безопасными, чем десктопные приложения.
Поделиться публикацией

Похожие публикации

Комментарии 16
    +4
    Каждый пользователь заходит в систему по выделенному ему логину и паролю. [...] Данные паролей пользователей хранятся в базе данных в закрытом виде в виде хэша.

    А как же SSO и вообще федерация?

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

    Это в какой «облачной CRM» так делают?

    При непрохождении аутентификации пользователь автоматически разлогинивается из системы.

    В смысле — все сессии этого пользователя, или конкретная?

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

    На основании чего вы делаете вывод о «не менее безопасные»? Например, как вы оцениваете угрозу НДВ внутри SaaS решения, или вероятность злого умысла со стороны сотрудников SaaS-провайдера?
      0
      А как же SSO и вообще федерация?

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

      Это в какой «облачной CRM» так делают?

      В смысле — все сессии этого пользователя, или конкретная?

      В данном случае — речь о конкретной текущей сессии. Если мы будем выбрасывать пользователя из системы по каждому непонятному поводу — то работать будет невозможно.

      На основании чего вы делаете вывод о «не менее безопасные»? Например, как вы оцениваете угрозу НДВ внутри SaaS решения, или вероятность злого умысла со стороны сотрудников SaaS-провайдера?

      В этой статье не идет речь о количественной оценке угрозы НДВ и сертификации программного продукта. Если такие меры необходимы, то их необходимо проводить как для десктопного, так и для облачного ПО.
        0
        Во многих случаях нам как раз не требуется SSO и единый вход.

        Кому «нам»?

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

        Это у вас такое странное понимание multitenancy?

        В данном случае — речь о конкретной текущей сессии. Если мы будем выбрасывать пользователя из системы по каждому непонятному поводу — то работать будет невозможно.

        Как можно «разлогинить» пользователя, если он только проходит аутентификацию?

        В этой статье не идет речь о количественной оценке угрозы НДВ и сертификации программного продукта.

        Тогда на основании чего вы делаете утверждение о том, что «облачные CRM» не менее безопасны, чем десктопные (кстати, противопоставление неверно, должны быть on-premise).
          –1
          Кому «нам»?

          Нам — разработчикам и реализаторам ПО.

          Это у вас такое странное понимание multitenancy?

          А какое у вас понимание? Мы исходим из решения практических поставленных задач, а не академических терминов.

          Как можно «разлогинить» пользователя, если он только проходит аутентификацию?

          Вы не путайте авторизацию и аутентификацию, это разные процессы.

          Тогда на основании чего вы делаете утверждение о том, что «облачные CRM» не менее безопасны, чем десктопные (кстати, противопоставление неверно, должны быть on-premise).

          А где вы здесь видите противопоставление? Статья о мерах защиты, применяемых внутри облачных CRM-решений, призванных минимизировать угрозы несанкционированного доступа.
            +1
            Нам — разработчикам и реализаторам ПО.

            Понимаете ли, в чем дело, что нужно разработчикам — никого не волнует. Простите за прямоту. Волнует то, что нужно заказчику — а заказчику регулярно нужно, чтобы его сотрудники логинились на свой компьютер, а дальше получали доступ к любой LOB-системе исходя из доменной учетки (ну и в обратную сторону: учетку в домене заблокировали — никто никуда больше не попадает).

            А какое у вас понимание? Мы исходим из решения практических поставленных задач, а не академических терминов.

            У меня понимание простое — если в облаке есть компания А и компания Б, и в обеих есть сотрудник с логином jsmith, то есть явный способ определить, в какую компанию идет логин (без проверок на пароли).

            Вы не путайте авторизацию и аутентификацию, это разные процессы.

            Я и не путаю.

            А где вы здесь видите противопоставление?

            «В облачных CRM [...] делают их не менее безопасными, чем десктопные приложения.» Облачные CRM противопоставляются десктопным (что, как я уже писал, неграмотно).

            Статья о мерах защиты, применяемых внутри облачных CRM-решений, призванных минимизировать угрозы несанкционированного доступа.

            Эта статья содержит конкретное процитированное мной утверждение. На чем оно основано?
              0
              А нашим заказчикам нужно с точностью до наборот — разные пароли на одну учетную запись в разных системах. Причем, чтобы при работе в системе А не было ни намека на доступ в систему Б, но — при одинаковых логинах в двух системах. Может, в системе А собственник вредный дышит в плечо и ему нельзя показывать систему Б, или какие-то иные внутренние соображения.

              Это не противопоставление, а в целом даже сравнение. В статье описан обзор мер защиты наших облачных систем. Многие из этих мер неосуществимы для десктопных систем, например, централизованное резервное копирование.
                0
                А нашим заказчикам нужно с точностью до наборот — разные пароли на одну учетную запись в разных системах. Причем, чтобы при работе в системе А не было ни намека на доступ в систему Б, но — при одинаковых логинах в двух системах. Может, в системе А собственник вредный дышит в плечо и ему нельзя показывать систему Б, или какие-то иные внутренние соображения.

                Так все-таки, это multi-tenancy, plausible deniability или что-то третье? Я не понимаю, откуда требование на одинаковый логин.

                (ну и да, то, что вы продолжаете игнорировать SSO, много говорит о спектре ваших заказчиков)

                В статье описан обзор мер защиты наших облачных систем.

                О, наконец-то вы озвучили, что это защита информации не в облачных CRM, а в ваших облачных CRM.

                Многие из этих мер неосуществимы для десктопных систем, например, централизованное резервное копирование.

                Вы продолжаете меня не слышать. Ок, пойдем с другой стороны: приведите пример широко распространенной сейчас «десктопной» CRM-системы.
                  0
                  Мы не комментируем наших заказчиков.
                  Я дал ответ: главные представители ряда заказчиков не хотят запоминать несколько логинов, но не могут использовать единый вход в несколько доступных им систем по ряду внутренних причин.

                  Десктопные системы — не совсем корректно выразился. Речь об устанавливаемом на сервере у заказчика ПО. Взять то же 1С Предприятие.
                    0
                    Я дал ответ: главные представители ряда заказчиков не хотят запоминать несколько логинов, но не могут использовать единый вход в несколько доступных им систем по ряду внутренних причин.

                    Что подтверждает мой тезис о том, что это не «защита в облачных CRM», а «у нас в CRM так сделано, и мы даже не можем объяснить, почему».

                    Десктопные системы — не совсем корректно выразился. Речь об устанавливаемом на сервере у заказчика ПО. Взять то же 1С Предприятие.

                    Я вам об этом с самого начала говорю — термин «десктопные системы» не на месте. Ок, следующий вопрос: а что неосуществимого в централизованном резервном копировании системы, установленной на сервере у заказчика?
                      0
                      Мы не раскрываем причин и не комментируем действий наших заказчиков. Есть ряд схожих разумных требований — мы их реализуем.

                      Этот сервер под управлением заказчика. Копирование настроить конечно возможно, но в общем случае полная ответственность за копирование и его результаты не может лежать на нас по ряду не зависящих от нас же факторов, например, при каких-либо технических накладках не на нашем оборудовании, при необдуманных действиях системных администраторов заказчика и т.п.
                        0
                        Мы не раскрываем причин и не комментируем действий наших заказчиков. Есть ряд схожих разумных требований — мы их реализуем.

                        Не стоит упоминать требование заказчика, которое вы не можете публично обосновать, как принятую практику в облачных CRM.

                        Этот сервер под управлением заказчика. Копирование настроить конечно возможно, но в общем случае полная ответственность за копирование и его результаты не может лежать на нас по ряду не зависящих от нас же факторов, например, при каких-либо технических накладках не на нашем оборудовании, при необдуманных действиях системных администраторов заказчика и т.п.

                        Таким образом, ничего неосуществимого в централизованном резервном копировании для on-premise систем нет, а все отличие состоит в том, кто ответственен за результат. И поверьте мне, не все заказчики будут рады переложить эту ответственность на внешнего агента.
                          0
                          Как раз в том и принципиальный вопрос, кто делает резервное копирование и отвечает за результат. За свои серверы мы отвечаем и обеспечить сохранность данных можем, а за чужие-нет. В случае облачной системы резервное копирование действительно централизованное, в отличие от клиентской установки системы.
                            0
                            Вы опять очень мило подменили клиентскую перспективу своей.

                            То, что вы не можете обеспечить сохранность данных, еще не значит, что ее нельзя осуществить вообще. И с точки зрения клиента «централизованное» копирование — это такое, при котором все его данные резервируются в одном хранилище и упраявляются едиными политиками.

                            Ваша политика ставит клиента в зависимость от вас: вы обспечиваете сохранность данных, которые резервируются в ваше централизованное хранилище. Далеко не всех это устроит, и далеко не всем это надо. И — самое главное — обратная ситуация в общем случае ничем не менее безопасна.
      +5
      Что ЭТО делает на Хабре?
        +2
        Проверяет как работает саморегуляция. Работает!
        +2
        Америку открыли. Тоже мне, бином Ньютона.

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

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