Windows, iPad и Android — управление активами Office и их использование в мире планшетных компьютеров. Часть 4. Управление доступом на основе устройств
Исходная статья опубликована в четверг, 20 октября 2011 г.
Добро пожаловать в четвертую часть серии об управлении активами Office в мире планшетных компьютеров. В первой части я описал основные способы работы с Office в полнофункциональных клиентах, удаленных полнофункциональных клиентах, Office для Mac, веб-приложениях и Office для телефонов. Во второй части мы поговорили об использовании электронной почты на планшетных компьютерах с помощью Exchange ActiveSync, сравнили элементы управления, доступные на других платформах, с групповой политикой и описали варианты настройки Office. В третьей части я написал о веб-приложениях Office как части SharePoint 2010 или службы Office 365. Это подводит меня к текущей и, возможно, одной из самых запутанных тем данной серии — как дифференцировать доступ к ресурсам в зависимости от устройств.
Доверие на основе устройств и дифференцированные модели доступа
Когда дело доходит до защиты данных Office, я вспоминаю три основных варианта обеспечения безопасности:
- Защита локальной информации на жестком диске устройства.
- Защита информации, доступ к которой осуществляется удаленно с устройства.
- Защита передачи данных из удаленных источников на устройства.
Защита локального хранилища устройства чаще всего затрагивает методы шифрования и блокировки локального хранилища до предоставления определенного количества факторов проверки подлинности, необходимого для доказательства подлинности пользователя.
Шифрование диска
Windows использует шифрование диска BitLocker™ , при этом есть множество решений сторонних производителей, которые могут шифровать все тома жесткого диска. Планшетные компьютеры iPad также используют шифрование жесткого диска для защиты локальных данных, а Android Honeycomb и новые операционные системы для планшетных компьютеров также добавили поддержку шифрования жесткого диска. Bitlocker не хранит данные пользователя на незашифрованных разделах жесткого диска, а другие программы могут действовать по-другому и хранить важные данные проверки подлинности в незашифрованных и доступных областях жесткого диска. Популярные версии Android 1.6, 2.1 и 2.2 не обладают встроенными возможностями шифрования жесткого диска и будут уязвимы при компрометации устройств. Для ясности: в Windows необходимо убедиться, что используется шифрование и принудительно применить это как ИТ-политику. В противном случае появится множество способов для получения доступа к информации на жестких дисках (за счет удаления или загрузки других операционных систем), изменения паролей локальных учетных записей (с помощью сброса пароля ERD Commander) и т. д. Если вам требуется шифрование диска и вы принудительно применяете соответствующую политику, получить доступ к информации в локальном хранилище без определенных факторов проверки подлинности (доверенный платформенный модуль, ПИН-код, смарт-карта, USB-адаптер или пароль) будет чрезвычайно сложно.
Защита сети
Если разрешить неуправляемым устройствам подключаться к сети после брандмауэра, доступно несколько вариантов помимо обычных требований к сертификатам и настройкам прокси-сервера. Некоторые организации по соображениям безопасности реализуют параллельную сетевую инфраструктуру специально для доступа неуправляемых устройств и ограничения доступа к активам, управляемым через Exchange ActiveSync и связанную инфраструктуру. Хотя этого было достаточно для многих сред, ИТ-специалисты часто находятся под повышенным давлением, связанным с подключением таких устройств к корпоративному брандмауэру. Если такая ситуация кажется вам знакомой, можно кое-что сделать, чтобы дифференцировать доступ на основе типа устройства или браузера, подключающегося к данным SharePoint.
Существовали общие методы для определения работоспособности компьютерного объекта, обращающегося к сетевым ресурсам. Мы использовали такие вещи, как VPN-карантин и защита доступа к сети (NAP), в течение нескольких лет. В решении NAP устройство опрашивается при попытке доступа к сети и, если оно не соответствует стандартам (состояние обновления, последняя версия антивирусной программы и т. д.), ему даются нулевые права для доступа к сети. Описание того, как NAP работает с протоколами IPsec, VPN, 802.11x и DHCP можно найти на сайте TechNet , а на этом рисунке представлен процесс обнаружения и обработки устройства, не соответствующего требованиям, с помощью протокола IPsec.
Но для применения NAP требуется компьютер, поддерживающий NAP, например под управлением Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows Vista и Windows XP с пакетом обновлений 3 (SP3). Поэтому если мы хотим принудительно проверять работоспособность устройств с помощью NAP, нам потребуется развертывать устройства под управлением операционной системы Windows.
Допустим, я не могу использовать NAP, так как подключаемое устройство — это Mac, iPad или устройство с операционной системой Android. Что делать в этом случае? Есть несколько вариантов, использующих Microsoft Forefront Unified Access Gateway (UAG) для принудительного применения стандартов на устройствах без Windows (Mac и Linux), таких как обязательное использование антивирусной программы на таких устройствах. На следующем рисунке показан редактор политики в Forefront UAG и поддерживаемые платформы (помимо Windows).
Текст, показанный выше, отображается, если устройство не соответствует требованиям работоспособности, наложенным UAG. Сведения о требованиях UAG к клиенту можно найти на сайте TechNet. Для этого блога важно, что в Forefront UAG SP1 Update 1 добавлена поддержка браузеров для платформ iOS 4, Android 2.3 и 3.0.
Другой способ защиты файлов от загрузки на устройства — использование служб IIS для опроса подключающихся устройств, передачи полученных сведений на сервер IIS и принятия решения о разрешении или запрете загрузки файлов на основе этой информации. С помощью служб IIS я могу определить правила, который будут перенаправлять устройства, пытающиеся загрузить файлы. В этом случае я могу изучить журнал IIS и определить идентификаторы устройства.
В журнале, представленном выше, я вижу тип устройства "iPad" и браузер, подключающийся к документу. Затем я могу открыть службы IIS и настроить правило, которое перенаправляет вызовы от устройств с такими атрибутами на страницу, сообщающую о том, что они выполняют действие, неавторизованное администратором сети.
Как видно на рисунке диспетчера IIS выше, я создал правило, применимое ко всем DOCX-файлам. Если устройство совпадает с шаблоном и в его дескрипторе указан тип iPad, я перенаправляю пользователя на сайт интрасети download%20denied.aspx. Мне не нужно делать это для всех файлов по-отдельности, я могу определить одно правило для всех DOCX-файлов (или других расширений файлов). Удобно, что мы можем разрешить устройству просматривать документ с помощью Office Web Apps, так как он отображается на сервере SharePoint, а устройству передается только PNG-файл.
Если пользователи попытаются загрузить копию на неуправляемое устройство, они увидят следующее:
Это позволяет предотвратить загрузку файла на локальный диск и использование другой службы для передачи файла в другое нежелательное расположение. Если жесткий диск не зашифрован или устройство оснащено съемным хранилищем, это позволяет предотвратить сохранение файла в незащищенной файловой системе, на SD-карте и т. д. Это неидеальный способ, но он помогает сократить число нежелательных действий пользователей, при этом предоставляя права на просмотр документов с помощью Office Web Apps.
Безопасная передача данных
Передачу данных я упомянул среди прочего в начале этой статьи, но сетевые стеки большинства современных устройств под управлением iOS и Android поддерживаю стандарты WEP и WPA для защиты передачи данных на устройства и с устройств. Ключевым моментом здесь является использование этих методов в отличие от небезопасных сетей.
Заключение для четвертой части
Мобильные устройства прошли долгий путь и продолжают улучшаться. Но они не так управляемы, как большинство развитых платформ, обладающих встроенными возможностями для защиты как данных на устройстве, так и подключений к удаленным данным. Это неудивительно, учитывая современное окружение, где для получения доступа устройства получают определенные послабления, так как в противном случае они просто не соответствуют критериям безопасности. Надеемся, что некоторые методики, описанные в этом блоге, помогут вам определить методы для предоставления ограниченного, но достаточного уровня доступа неуправляемым устройствам, при использовании которых вы будете спокойны, а ваши пользователи — счастливы. Конечно, есть и другие механизмы, такие как служба управления правами на доступ к данным (IRM), с помощью которых неуправляемым устройствам Windows можно предоставить доступ к конфиденциальным файлам за счет поддержки Exchange ActiveSync в Windows Phone 7.5, Windows Mobile и Outlook Web Access, но эти методы недействительны для iPad и Android и не дают права сравнивать NAP с политиками UAG и IIS, поэтому я не очень подробно описал возможности IRM в данной статье.
Я хотел начать разговор с того, как предоставить удаленный доступ с помощью Citrix XenApp и служб удаленного рабочего стола в Windows Server, как настроить интерфейс пользователя Office и оболочку Windows для доступа с iPad или устройства на базе Android, но это я опишу в следующей и, скорее всего, последней статье этой серии.
Спасибо за внимание.
Джереми Чэпмен (Jeremy Chapman)
Старший менеджер по продуктам
Группа разработчиков Office IT Pro
Это локализованная запись блога. Исходная статья находится по ссылке Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 4) – Device-based Access Management