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