Зачем «плевать» — для решения разных задач есть разные инструменты. Можно сделать и так как предлагаете вы, но в этом сценарии будет перерасход ресурсов, так как далеко не весь трафик критичен на столько, чтобы его дублировать по всем имеющимся каналам.
Можно посмотреть небольшое видео о том как выглядит автоматическое подключение и аварийное отключение канала при использовании NetScaler SD-WAN — https://www.youtube.com/watch?v=Vllfj7xUW8g
Так как Citrix исторически связан с предоставлением удалённого доступа конечным пользователям, то одним из приоритетов при разработке решений является обеспечение высокой комфортности работы пользователей. Система настраивается администратором таким образом, чтобы обеспечить комфортность и непрерывность работы приложений пользователя. При необходимости можно разбрасывать трафик по разным физическим каналам или дублировать его передачу и это определяется в зависимости от критичности приложения и его требований к каналам передачи данных.
У нас (Citrix Systems) есть своё решение NetScaler SD-WAN. В зависимости от модели можно обеспечить до 550 фиксированных виртуальных путей или до 32 динамических. https://www.citrix.com/content/dam/citrix/en_us/documents/data-sheet/netscaler-sd-wan-data-sheet.pdf
В данном тексте мы не рассказывали о каком-то конкретном проекте, но тут https://www.citrix.com/customers/agrifish-en.html?product=cloudbridge можно ознакомиться с примером успешного внедрения технологии NetScaler SD-WAN у заказчика из государственного сектора Дании
HA = High Availability = Высокая Доступность и это подразумевает, что вы возможно потеряете то, что в данный момент находилось в оперативной памяти, https://en.wikipedia.org/wiki/High_availability
Виртуальная машина и её данные в случае HA должны располагаться на общей для пула серверов системе хранения данных и тогда, в случае падения ВМ, которая работала на сервере 1, она перезапускается на сервере 2 с общей СХД и оттуда же берёт данные, необходимые ей для работы. Этот подход отличается от Fault Tolerance, кластеризации серверных приложений и других методов обеспечения непрерывности и отказоустойчивости. Так что это «быстрый перезапуск», а данные лучше располагать за пределами ВМ, на отдельном ресурсе. Ну и общая практика такова — чем больше «девяток» вы хотите получить для своей системы, тем более дорогой она оказывается.
По трафику — один из наших заказчиков недавно проводил тестирование (самостоятельно, без участия вендора, с использованием автоматизированных средств тестирования) работы терминальных приложений (без мультимедийных возможностей). В результате усреднённая нагрузка на канал составила около 30 кбит/сек (это с печатью и прикреплением документов с локальной рабочей станции). На случай, если печать и прикрепление файлов будет идти с большинства рабочих станций одновременно была выдана рекомендация на предоставление 1 пользователю 64 кбит/сек.
Теперь про XenServer 4 — давно надо обновлять. Версия XenServer 7.1 также доступна в виде бесплатной редакции. Единственное отличие от XenServer Standard Edition — на бесплатную редакцию нельзя купить техническую поддержку. Так что спокойно добавляйте в пул второй сервер и машины можно будет сразу перемещать между хостами (при условии что у вас процессоры одинаковые или могут быть маскированы гипервизором). High Availability тоже работает в бесплатной редакции и если вы его настроите, то машина в случае падения узла 1 автоматически перезапустится на узле 2, но (!) данные с которыми она работала — потеряются.
Правильно заданный вопрос содержит в себе часть ответа :)
Для того, чтобы сказать, какая скорость дисковой подсистемы понадобится нужно знать что за рабочую нагрузку вы «крутите» внутри виртуальных машин. В одном случае необходимые вычисления могут полагаться только на оперативную память и тактовую частоту процессора, а в другом случае активно работать с дисковой подсистемой. Естественно ответ будет в каждом случае разный. С сетью такая же ситуация + нужно понимать какой аспект интересует: сколько кбит/сек нужно для работы пользователя с той или иной виртуальной машиной (тогда это вообще вопрос не к гипервизору, а к терминальной системе или системе виртуализации десктопов) или интересует полоса пропускания, необходимая для например перемещения виртуальной машины с одного хоста на другой (XenMotion или Storage XenMotion) в случае нахождения хостов на разных площадках. Тут опять нет однозначного ответа — всё сильно зависит от размера виртуальной машины и объёма виртуальной оперативной памяти.
У вас есть один сервер с XenServer, с работающими виртуальными машинами. Если вы хотите, чтобы в случае аварии машины автоматически перезапустились на другом хосте или при необходимости можно было бы переместить машины не прерывая предоставления сервиса, то для начала нужно добавить в пул второй сервер. HA, XenMotion, Storage XenMotion доступны даже в бесплатной редакции.
Commercially available as Virtual Shared Graphics Adaptor (vDGA, VMWare) and Remote FX (Microsoft), this graphics virtualization approach requires a virtual graphics driver in a virtual machine, use an API forwarding technique to interface with the Intel’s graphics hardware (fig-2). Single GPU hardware can be shared amongst many concurrent users, while the graphics hardware remains abstracted from the applications. Specific sharing algorithms remain proprietary to the virtual graphics driver. Many commercial desktop and workstation remoting products in the market use this approach.
Коллега, да я с этим не спорю. Именно поэтому мы в рамках Citrix XenDesktop официально поддерживаем 4 (!) гипервизора — XenServer (входящий в состав), MS Hyper-V, Nutanix Acropolis и VMware ESX. Тут больше вопрос, что нужно по требованиям проекта и хватит ли на это бюджета :). С точки зрения масштабируемости проектов у заказчиков разницы особой нет — есть проекты на 100 000 пользователей на разных гипервизорах. А с точки зрения экономической эффективности конечно можно и на Феррари за картошкой в деревню по просёлочной дороге ездить.
И всё-таки я останусь при своём мнении.
Если пройти по ссылке — https://xenserver.org/about-xenserver-open-source.html
там в самом начале как раз и написано: XenServer is an open source project and community managed by Citrix. The project develops open source software for securely running multiple operating systems and applications on a single device, enabling hardware consolidation and automation to reduce costs and simplify IT management of servers and applications.
Citrix provides a commercial support and services for XenServer under an enterprise license agreement for those users who need dedicated support.
Коллега, извините, но не соглашусь:
https://www.citrix.com/products/xenserver/
и
https://en.wikipedia.org/wiki/Xen
XenSource — то, что разрабатывает сообщество, а XenServer это то, что делает на его основе Citrix.
На основе XenSource не только Citrix ведёт разработки, достаточно посмотреть на список компаний-участников: — https://www.xenproject.org/directory/project-members.html
С точки зрения MDM между разными поставщиками нет большой разницы, так как MDM решения могут делать только то, что разрешает ОС через свои API. Поэтому наиболее важно смотреть с какой версией Android нам надо работать. Для старых версий выбор технических возможностей будет очень ограниченным. Смотреть нужно на самые свежие версии Android, а в рамках XenMobile мы можем ограничить каким версиям позволено подключаться к инфраструктуре.
Вот, например, по первому пункту — реальность показывает, что современные мобильные антивирусы предоставляют довольно слабую защиту — в особенности, если это была целенаправленная атака, а не просто попадание под раздачу.
Ну давайте будем честны – если компания, в которой вы работаете, является целью специализированно заточенной атаки, то тут будет очень самонадеянно полагаться только на MDM/MAM решения. Да и в принципе любая оборона должна строиться эшелонировано.
Ещё по нулевому пункту — конечно, можно отключить камеру, GPS, Wi-Fi — но тогда проще выдать пользователю старое звонило — набор функций будет примерно тем же и мы потеряем все возможности мобильного приложения...
Это так, за исключением того факта, что отключать можно основываясь на координатах :) или по расписанию, или по приложениям. Например, запускаем внутреннее финансовое приложение и не можем сделать снимок экрана, переключаемся на игру и хотим похвастаться результатом – пожалуйста, сделали снимок экрана и отправили штатным почтовым клиентом или прикрепили к посту на фейсбуке. Вошли в производственную площадку компании и не можем пользоваться фотокамерой, покинули территорию и эта возможность вернулась назад. Geo-fencing активно используется «там» в медицине. Как только планшет с историей болезни покидает пределы клиники, вся информация на нём автоматически очищается.
По третьему пункту — длина пина и сложность пароля не имеет значения, если хакер получил контроль над пользовательским вводом… Это правда, но, чем длиннее и сложнее пароль, тем больше времени потребуется злоумышленнику. За это время информация о потери устройства дойдёт до технической поддержки или пользователь решит очистить своё устройство через портал самообслуживания или в настройках приложения указана «time-bomb», которая требует через какое-то время подключаться к системе иначе контейнер будет очищен.
По четвёртому пункту — касательно рутованности и джейлбрейка — у вас действительно есть возможность 100% определения того, что это произошло? Как, если не секрет? К тому же, хакеру ничто не сможет помешать скопировать все данные с вашего телефона, не включая его, и вы никак не сможете этому помешать. Да, я в очередной раз соглашусь, если информация так ценна, что профессиональный хакер (читай спецслужбы или очень богатые компании) готовы тратить время и средства на кражу, расшифровку данных, то тут надо серьёзно обдумать как и что защищать и возможно мобильность для такого заказчика противопоказана. Стоимость средств защиты не должна превышать стоимости информации которую эти средства защищают.
По шестому — а где можно почитать подробнее про шифрованный контейнер? про технологию MDX можно почитать здесь
Делюсь ссылкой на любопытный материал как раз по этой теме, ссылки в конце статьи также рекомендую к прочтению. Это очень важная проблема в авиации, особенно в массовой, где даже небольшая экономия в одном рейсе в масштабе всей авиакомпании за год может дать существенную сумму.
Я бы предложил не внедрять мобильность ради мобильности. В разных компаниях есть разные группы сотрудников кому это будет полезно, но далеко не для всех пользователей это необходимо. В первую очередь в компаниях такими технологиями интересуются руководители высшего звена. Затем внимание обращают на сотрудников, которые работают в полях и которые в настоящий момент вынуждены использовать стационарные решения, что приводит к задержкам в обновлении информации или невозможности предоставления данных вообще. Мобильность это инструмент, который должен применяться обдуманно, иначе можно прийти к ситуации, когда микроскопом забивают гвозди.
Спасибо за интерес к статье и технологиям, постараюсь развеять ваши сомнения.
Какая-то невнятная маркетинговая каша без описания хотя бы одной реальной проблемы и её решения. В статье говорится про личные приложения, что показывает, что мы используем устройство пользователя. Что туда добавили? Защиту от copy paste? Правда? Не смешите мои тапочки. Пользователь может просто сделать скриншот, а если у него рутованный девайс — может всё что угодно. Начнём с того, что системы MAM и MDM проверяют «рутованность» или «джейлбрейк» устройства и могут просто запретить регистрацию такого устройства в системе управления и распространения корпоративного ПО. Если у пользователя устройство сначала было зарегистрировано в системе управления и на него «приехали» корпоративные приложения, а уже потом пользователь решил «взломать» своё устройство, то как только он это сделает, администратор в консоли это увидит, получит предупреждение и дальше всё будет зависеть от принятых в компании правил, которые трансформируются в политики. Как вариант — «выбрасывание» устройства из системы и очистка всей корпоративной информации на устройстве пользователя. С точки зрения запрета copy-paste – это только одна из возможностей. Другими могут быть — блокирование возможности снятия скриншота :) (ваши тапочки могут быть спокойными); отключение фотокамеры на устройстве; отключение GPS и другие возможности подробно описанные в документации на продукт.
Немного про реальные проблемы:
1. Изначально просканировать девайс пользователя на наличие вредоносного ПО? А если оно уже прописалось в прошивку? К сожалению, реальность такова, что на мобильные устройства так же настоятельно рекомендуется устанавливать антивирусы. После того как агент установлен, антивирус может быть доставлен из корпоративного магазина или официального магазина (Google, Apple). Также можно осуществить проверку на наличие известных вредоносов. С точки зрения вредоносов установленных в прошивку то тут поможет только тот факт, что корпоративные приложения доставляются в виде контейнера и когда им необходимо взаимодействовать с серверами компании это взаимодействие будет осуществляться по принципу микро-VPN (конкретное приложение до необходимого ему серверу).
2. Как защитить пользователя от установки вредоносного ПО? Да, в том числе из Google Play? Тут возможны разные ситуации – если это устройство пользователя, то мы конечно можем запретить пользователю установку ПО, но не думаю что пользователь будет рад таким перспективам. Такой вариант подходит для корпоративных устройств. В случае личного устройства – технология MAM позволит «привозить» корпоративное ПО в закрытом контейнере, которое недоступно для личного ПО, установленного пользователем.
3. Как привязать корпоративное ПО конкретному пользователю, чтобы никто не мог им воспользоваться, например найля потерянный телефон? Аутентификация в ПО, удалённая очистка «похищенных»/потерянных устройств, политики безопасности по доступу к устройству – например «длинный» и сложный PIN.
4. Как защитить пользователя от уязвимостей самой ОС, которые порой могут получить рутовые права прямо через браузер? — в случае «рутования устройства» его можно отключить от предоставляемых сервисов и очистить весь корпоративный контент, включая приложения.
5. Как защитить пользователя от перехвата трафика при помощи вражеских вайфайных точек и не дай бог вышек? — возможны разные варианты, например от запрета подключения к сторонним Wi-Fi сетям, до передачи данных только по микро-VPN каналам.
6. Как защитить от реверса ваших приложений на устройстве пользователя? — приложения поставляются в зашифрованном контейнере.
7. Как защититься от слива информации между разными устройствами пользователя по его инициативе? — если у пользователя есть желание «слить» информацию, то никто не помешает ему например взять ручку и лист бумаги и переписать нужную ему информацию. Технически можно запретить пересылку сообщений «штатными» почтовыми клиентами и разрешить использование только SecureMail, к которому применяются корпоративные политики. В решении ShareFile можно настроить интеграцию с IRM и DLP системами. Доступ к контейнеру где хранится информация (ShareFile) открыт только для приложений поставляемых компанией с использованием политик ограничивающих взаимодействие с приложениями пользователя.
Хотя на каждый вопрос можно дать частичный ответ, ни один из них на текущий вопрос рльзя решить полностью. И это я вопросы взял с потолка, набирая с планшета в метро — на самом деле их гораздо больше. Возможностей у современных решений по управлению корпоративной мобильности также много, особенно если осуществлять интеграцию с другими вендорами (DLP, IRM, антивирус итд)
Посмотрим в глаза правде — мобильность сотрудников сейчас просто необходима. Но это абсолютная адовая дыра, единственная защита от которой — понимать, что ты допускает эту дыру в своей инфраструктуре и относиться к этому с соответствующей осторожностью. Вот тут я полностью с вами согласен. Мобильность – необходима, но требуется понимание кому и для чего мы даём доступ к корпоративным ресурсам, а также как мы эти ресурсы будем защищать. Но это справедливо также и для обычных решений по удалённому доступу.
В целом да – идея именно такая. Убирается зависимость от того, на какой платформе работает приложение, какое устройство у пользователя есть сейчас в руках, а также где сейчас находится этот пользователь. Если есть сеть передачи данных, есть устройство, которое может подключаться к этой сети, и есть агент для данной платформы, то пользователь может работать со своими приложениями. Сейчас даже последнее требование не является обязательным, так как есть возможность подключиться к системам, используя браузер с поддержкой HTML5.
А он никуда и не девался. На самом деле можно исторически вернуться в ещё более далёкое прошлое и вспомнить мейнфреймы и алфавитно-цифровые терминалы. Та же самая идея – работа осуществляется на мощной машине, разделяя её ресурсы, а простые конечные устройства использовались лишь для ввода и отображения информации. Затем наступила эра ПК, и идеи удалённой работы на какое-то время отошли на второй план. Затем терминальные сервисы стали использоваться как средство решения определённых тактических задач, а сейчас они же + виртуализация десктопов позволяют говорить о переносе нагрузки в облака и переходе к использованию различных xaaS решений.
Всё очень сильно зависит от тех задач, которые хотят решить с помощью решения с виртуальными десктопами или терминальными приложениями. Если основной целью внедрения является предоставление возможности сотрудникам работать по каналам с минимальным потреблением трафика, то да – вы абсолютно правы, администратор будет изыскивать все возможности, чтобы с помощью политик, твиков убрать у пользователя всё, что вызывает дополнительную нагрузку с точки зрения сетевой подсистемы. С другой стороны есть множество примеров, когда основными триггерами внедрения были – повышение безопасности решения; доступ пользователей к бизнес приложениям с любых устройств (планшеты, смартфоны, альтернативные ОС); возможность привлечения талантов из других регионов; экономия на стоимости рабочей силы и арендных платежей; необходимость предоставления доступа к тяжёлым графическим приложениям. Во всех этих случаях обеспечение комфортности работы пользователя является одной из приоритетных задач.
Мако_357 и navion – описанные вами ситуации были справедливы к системам развёртываемым несколько лет назад. Прогресс на месте не стоит
Про графику сказали :) Сейчас есть различные варианты предоставления графических возможностей при удалённой работе: Терминальные приложения могут воспользоваться ресурсами графической карты установленной в сервер (если речь идёт про аппаратный сервер). В случае виртуальной машины можно использовать проброс графического ядра в ВМ, можно работать с виртуальной графической картой vGPU от NVidia или GVT-g от компании Intel. Если нагрузка со стороны графики не очень большая, то можно использовать варианты эмуляции графических карт средствами гипервизора. На стороне клиентского устройства применяются свои «хитрости» — обработка графической информации не центральным процессором, а выделенным чипом, что позволяет например на устройстве, стоимостью менее 100$, построенном на ARM процессоре, осуществлять просмотр FullHD видео. Но не следует забывать о том, в комфортность работы пользователя немалый вклад вносит протокол и доступная полоса пропускания.
Можно посмотреть небольшое видео о том как выглядит автоматическое подключение и аварийное отключение канала при использовании NetScaler SD-WAN — https://www.youtube.com/watch?v=Vllfj7xUW8g
Так как Citrix исторически связан с предоставлением удалённого доступа конечным пользователям, то одним из приоритетов при разработке решений является обеспечение высокой комфортности работы пользователей. Система настраивается администратором таким образом, чтобы обеспечить комфортность и непрерывность работы приложений пользователя. При необходимости можно разбрасывать трафик по разным физическим каналам или дублировать его передачу и это определяется в зависимости от критичности приложения и его требований к каналам передачи данных.
В данном тексте мы не рассказывали о каком-то конкретном проекте, но тут https://www.citrix.com/customers/agrifish-en.html?product=cloudbridge можно ознакомиться с примером успешного внедрения технологии NetScaler SD-WAN у заказчика из государственного сектора Дании
Виртуальная машина и её данные в случае HA должны располагаться на общей для пула серверов системе хранения данных и тогда, в случае падения ВМ, которая работала на сервере 1, она перезапускается на сервере 2 с общей СХД и оттуда же берёт данные, необходимые ей для работы. Этот подход отличается от Fault Tolerance, кластеризации серверных приложений и других методов обеспечения непрерывности и отказоустойчивости. Так что это «быстрый перезапуск», а данные лучше располагать за пределами ВМ, на отдельном ресурсе. Ну и общая практика такова — чем больше «девяток» вы хотите получить для своей системы, тем более дорогой она оказывается.
Теперь про XenServer 4 — давно надо обновлять. Версия XenServer 7.1 также доступна в виде бесплатной редакции. Единственное отличие от XenServer Standard Edition — на бесплатную редакцию нельзя купить техническую поддержку. Так что спокойно добавляйте в пул второй сервер и машины можно будет сразу перемещать между хостами (при условии что у вас процессоры одинаковые или могут быть маскированы гипервизором). High Availability тоже работает в бесплатной редакции и если вы его настроите, то машина в случае падения узла 1 автоматически перезапустится на узле 2, но (!) данные с которыми она работала — потеряются.
Для того, чтобы сказать, какая скорость дисковой подсистемы понадобится нужно знать что за рабочую нагрузку вы «крутите» внутри виртуальных машин. В одном случае необходимые вычисления могут полагаться только на оперативную память и тактовую частоту процессора, а в другом случае активно работать с дисковой подсистемой. Естественно ответ будет в каждом случае разный. С сетью такая же ситуация + нужно понимать какой аспект интересует: сколько кбит/сек нужно для работы пользователя с той или иной виртуальной машиной (тогда это вообще вопрос не к гипервизору, а к терминальной системе или системе виртуализации десктопов) или интересует полоса пропускания, необходимая для например перемещения виртуальной машины с одного хоста на другой (XenMotion или Storage XenMotion) в случае нахождения хостов на разных площадках. Тут опять нет однозначного ответа — всё сильно зависит от размера виртуальной машины и объёма виртуальной оперативной памяти.
У вас есть один сервер с XenServer, с работающими виртуальными машинами. Если вы хотите, чтобы в случае аварии машины автоматически перезапустились на другом хосте или при необходимости можно было бы переместить машины не прерывая предоставления сервиса, то для начала нужно добавить в пул второй сервер. HA, XenMotion, Storage XenMotion доступны даже в бесплатной редакции.
Скорее всего на сайте коллег речь идёт о поддержке GVT-s, а не GVT-g
выдержка с сайта Интел (https://software.intel.com/en-us/blogs/2014/05/02/intel-graphics-virtualization-update)
Intel GVT-s
Commercially available as Virtual Shared Graphics Adaptor (vDGA, VMWare) and Remote FX (Microsoft), this graphics virtualization approach requires a virtual graphics driver in a virtual machine, use an API forwarding technique to interface with the Intel’s graphics hardware (fig-2). Single GPU hardware can be shared amongst many concurrent users, while the graphics hardware remains abstracted from the applications. Specific sharing algorithms remain proprietary to the virtual graphics driver. Many commercial desktop and workstation remoting products in the market use this approach.
Отличия разных вариантов виртуализации графики Интел рассматриваются тут — https://01.org/sites/default/files/downloads/igvt-g/gvtflyer.pdf
На сайте, где рассматривается GVT-g упоминаются XenServer и KVM https://01.org/igvt-g
Подробно об использовании технологии виртуализации графики Intel в XenDesktop можно прочитать тут — https://01.org/sites/default/files/documentation/intel-citrix-vdesktop-refresh_0.pdf
Сравнение производителей графических чипов с точки зрения виртуализации хорошо рассмотрено тут — http://www.brianmadden.com/opinion/NVIDIA-AMD-and-Intel-How-they-do-their-GPU-virtualization
Если пройти по ссылке — https://xenserver.org/about-xenserver-open-source.html
там в самом начале как раз и написано:
XenServer is an open source project and community managed by Citrix. The project develops open source software for securely running multiple operating systems and applications on a single device, enabling hardware consolidation and automation to reduce costs and simplify IT management of servers and applications.
Citrix provides a commercial support and services for XenServer under an enterprise license agreement for those users who need dedicated support.
https://www.citrix.com/products/xenserver/
и
https://en.wikipedia.org/wiki/Xen
XenSource — то, что разрабатывает сообщество, а XenServer это то, что делает на его основе Citrix.
На основе XenSource не только Citrix ведёт разработки, достаточно посмотреть на список компаний-участников: — https://www.xenproject.org/directory/project-members.html
Сергей
Вот, например, по первому пункту — реальность показывает, что современные мобильные антивирусы предоставляют довольно слабую защиту — в особенности, если это была целенаправленная атака, а не просто попадание под раздачу.
Ну давайте будем честны – если компания, в которой вы работаете, является целью специализированно заточенной атаки, то тут будет очень самонадеянно полагаться только на MDM/MAM решения. Да и в принципе любая оборона должна строиться эшелонировано.
Ещё по нулевому пункту — конечно, можно отключить камеру, GPS, Wi-Fi — но тогда проще выдать пользователю старое звонило — набор функций будет примерно тем же и мы потеряем все возможности мобильного приложения...
Это так, за исключением того факта, что отключать можно основываясь на координатах :) или по расписанию, или по приложениям. Например, запускаем внутреннее финансовое приложение и не можем сделать снимок экрана, переключаемся на игру и хотим похвастаться результатом – пожалуйста, сделали снимок экрана и отправили штатным почтовым клиентом или прикрепили к посту на фейсбуке. Вошли в производственную площадку компании и не можем пользоваться фотокамерой, покинули территорию и эта возможность вернулась назад. Geo-fencing активно используется «там» в медицине. Как только планшет с историей болезни покидает пределы клиники, вся информация на нём автоматически очищается.
По третьему пункту — длина пина и сложность пароля не имеет значения, если хакер получил контроль над пользовательским вводом… Это правда, но, чем длиннее и сложнее пароль, тем больше времени потребуется злоумышленнику. За это время информация о потери устройства дойдёт до технической поддержки или пользователь решит очистить своё устройство через портал самообслуживания или в настройках приложения указана «time-bomb», которая требует через какое-то время подключаться к системе иначе контейнер будет очищен.
По четвёртому пункту — касательно рутованности и джейлбрейка — у вас действительно есть возможность 100% определения того, что это произошло? Как, если не секрет? К тому же, хакеру ничто не сможет помешать скопировать все данные с вашего телефона, не включая его, и вы никак не сможете этому помешать. Да, я в очередной раз соглашусь, если информация так ценна, что профессиональный хакер (читай спецслужбы или очень богатые компании) готовы тратить время и средства на кражу, расшифровку данных, то тут надо серьёзно обдумать как и что защищать и возможно мобильность для такого заказчика противопоказана. Стоимость средств защиты не должна превышать стоимости информации которую эти средства защищают.
По шестому — а где можно почитать подробнее про шифрованный контейнер? про технологию MDX можно почитать здесь
Какая-то невнятная маркетинговая каша без описания хотя бы одной реальной проблемы и её решения. В статье говорится про личные приложения, что показывает, что мы используем устройство пользователя. Что туда добавили? Защиту от copy paste? Правда? Не смешите мои тапочки. Пользователь может просто сделать скриншот, а если у него рутованный девайс — может всё что угодно. Начнём с того, что системы MAM и MDM проверяют «рутованность» или «джейлбрейк» устройства и могут просто запретить регистрацию такого устройства в системе управления и распространения корпоративного ПО. Если у пользователя устройство сначала было зарегистрировано в системе управления и на него «приехали» корпоративные приложения, а уже потом пользователь решил «взломать» своё устройство, то как только он это сделает, администратор в консоли это увидит, получит предупреждение и дальше всё будет зависеть от принятых в компании правил, которые трансформируются в политики. Как вариант — «выбрасывание» устройства из системы и очистка всей корпоративной информации на устройстве пользователя. С точки зрения запрета copy-paste – это только одна из возможностей. Другими могут быть — блокирование возможности снятия скриншота :) (ваши тапочки могут быть спокойными); отключение фотокамеры на устройстве; отключение GPS и другие возможности подробно описанные в документации на продукт.
Немного про реальные проблемы:
1. Изначально просканировать девайс пользователя на наличие вредоносного ПО? А если оно уже прописалось в прошивку? К сожалению, реальность такова, что на мобильные устройства так же настоятельно рекомендуется устанавливать антивирусы. После того как агент установлен, антивирус может быть доставлен из корпоративного магазина или официального магазина (Google, Apple). Также можно осуществить проверку на наличие известных вредоносов. С точки зрения вредоносов установленных в прошивку то тут поможет только тот факт, что корпоративные приложения доставляются в виде контейнера и когда им необходимо взаимодействовать с серверами компании это взаимодействие будет осуществляться по принципу микро-VPN (конкретное приложение до необходимого ему серверу).
2. Как защитить пользователя от установки вредоносного ПО? Да, в том числе из Google Play? Тут возможны разные ситуации – если это устройство пользователя, то мы конечно можем запретить пользователю установку ПО, но не думаю что пользователь будет рад таким перспективам. Такой вариант подходит для корпоративных устройств. В случае личного устройства – технология MAM позволит «привозить» корпоративное ПО в закрытом контейнере, которое недоступно для личного ПО, установленного пользователем.
3. Как привязать корпоративное ПО конкретному пользователю, чтобы никто не мог им воспользоваться, например найля потерянный телефон? Аутентификация в ПО, удалённая очистка «похищенных»/потерянных устройств, политики безопасности по доступу к устройству – например «длинный» и сложный PIN.
4. Как защитить пользователя от уязвимостей самой ОС, которые порой могут получить рутовые права прямо через браузер? — в случае «рутования устройства» его можно отключить от предоставляемых сервисов и очистить весь корпоративный контент, включая приложения.
5. Как защитить пользователя от перехвата трафика при помощи вражеских вайфайных точек и не дай бог вышек? — возможны разные варианты, например от запрета подключения к сторонним Wi-Fi сетям, до передачи данных только по микро-VPN каналам.
6. Как защитить от реверса ваших приложений на устройстве пользователя? — приложения поставляются в зашифрованном контейнере.
7. Как защититься от слива информации между разными устройствами пользователя по его инициативе? — если у пользователя есть желание «слить» информацию, то никто не помешает ему например взять ручку и лист бумаги и переписать нужную ему информацию. Технически можно запретить пересылку сообщений «штатными» почтовыми клиентами и разрешить использование только SecureMail, к которому применяются корпоративные политики. В решении ShareFile можно настроить интеграцию с IRM и DLP системами. Доступ к контейнеру где хранится информация (ShareFile) открыт только для приложений поставляемых компанией с использованием политик ограничивающих взаимодействие с приложениями пользователя.
Хотя на каждый вопрос можно дать частичный ответ, ни один из них на текущий вопрос рльзя решить полностью. И это я вопросы взял с потолка, набирая с планшета в метро — на самом деле их гораздо больше. Возможностей у современных решений по управлению корпоративной мобильности также много, особенно если осуществлять интеграцию с другими вендорами (DLP, IRM, антивирус итд)
Посмотрим в глаза правде — мобильность сотрудников сейчас просто необходима. Но это абсолютная адовая дыра, единственная защита от которой — понимать, что ты допускает эту дыру в своей инфраструктуре и относиться к этому с соответствующей осторожностью. Вот тут я полностью с вами согласен. Мобильность – необходима, но требуется понимание кому и для чего мы даём доступ к корпоративным ресурсам, а также как мы эти ресурсы будем защищать. Но это справедливо также и для обычных решений по удалённому доступу.
Мако_357 и navion – описанные вами ситуации были справедливы к системам развёртываемым несколько лет назад. Прогресс на месте не стоит