Повышение безопасности приложений: все дело в приложениях (часть 7)

Опубликовано: 6 Апреля, 2023
Повышение безопасности приложений: все дело в приложениях (часть 7)

  • Application Security Redux: все дело в приложениях (часть 4)
  • Application Security Redux: все дело в приложениях (часть 6)
  • Снижение безопасности приложений: все дело в приложениях (часть 8)

Введение

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

В части 4 мы начали изучать Microsoft AppLocker, а в части 5 мы углубились в использование PowerShell для настройки и управления AppLocker. В части 6 мы обсудили новую возможность управления приложениями на мобильных устройствах с Windows 10.

Все сводится к данным

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

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

Некоторые данные безопасны для публичного обнародования; некоторые требуют минимального контроля, а некоторые — такие как номера кредитных карт клиентов и банковских счетов, личная информация сотрудников, медицинские данные пациентов, коммерческая тайна компании и т. д. — могут привести к катастрофе, если попадут в чужие руки. Некоторые из вышеперечисленных подпадают под действие государственных постановлений, и их разоблачение может привести к штрафам или худшим последствиям. Кроме того, утечка данных может серьезно повредить репутации организации и привести к потере бизнеса.

Защита таких данных, независимо от того, предусмотрена она законом или нет, вероятно, является самой важной частью вашей стратегии безопасности приложений, поскольку последствия ее невыполнения очень серьезны. Тем не менее, многие компании явно не поняли, как правильно обеспечить безопасность данных; согласно статистике Breach Level Index (BLI), в 2015 году было взломано более семисот миллионов записей данных.

Все сложно

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

Данные могут находиться на локальных жестких дисках, на файловых серверах в локальной сети, на устройствах хранения в локальной сети (NAS или SAN) или где-то в облаке. Некоторые данные существуют только пока они находятся в энергозависимой памяти (ОЗУ) компьютера или устройства. Кроме того, есть данные мобильных устройств, которые представляют другую и более сложную модель угроз по сравнению с данными на настольном компьютере или сервере. И как будто этого было недостаточно, нам также приходится бороться с данными, когда они, возможно, находятся в наиболее уязвимом состоянии из всех: когда они перемещаются из одного места в другое, особенно когда они передаются через общедоступный Интернет.

Еще одна сложность, связанная с защитой данных приложений, заключается в том, что безопасность по самой своей природе неудобна для пользователя. Шифрование данных требует времени и циклов процессора, что замедляет работу большинства систем. Хуже того, с точки зрения пользователей, им часто становится труднее получить доступ к информации, необходимой им для выполнения своей работы. Они должны прыгать через обручи, вводить пароли или иным образом аутентифицироваться, чтобы расшифровать информацию. Безопасность и удобство всегда будут жить на противоположных концах континуума; чем больше у вас одного, тем меньше у вас другого. Таким образом, многие пользователи будут сопротивляться любым мерам безопасности, которые не работают полностью бесшовным образом.

Матрица решений по обеспечению безопасности данных

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

Защита данных начинается с ограничения доступа к компьютерной системе и/или сети, что достигается с помощью политик, требующих строгой аутентификации для входа в систему. Аутентификация по имени пользователя и паролю по-прежнему является стандартом во многих организациях, но многофакторная аутентификация становится все более популярной. Сегодня у организаций есть много вариантов в этом отношении, включая смарт-карты, жетоны, аутентификацию смартфона, отпечатки пальцев, сканирование радужной оболочки/сетчатки, распознавание образов, PIN-код или технологии распознавания лиц в качестве второго фактора в дополнение к традиционным учетным данным.

Однако тот факт, что пользователю доверяют доступ к компьютеру или сети, не означает, что ему доверяют доступ ко всем хранящимся там данным. Таким образом, вторым шагом в защите конфиденциальных данных является внедрение эффективного контроля доступа. Контроль доступа включает в себя настройку разрешений, касающихся того, какие аутентифицированные пользователи могут получить доступ к определенным файлам, папкам или дискам/томам, и что именно они могут делать с данными при доступе к ним (только чтение, изменение, удаление и т. д.).

Далее мы подходим к способам шифрования данных, когда они находятся в состоянии покоя. Мы не будем вдаваться в технические особенности различных широко используемых криптоалгоритмов — DES, RSA, AES и т. д. — или основных методов шифрования (симметричного, асимметричного и хеширования). Мы также не будем вдаваться в подробности ключей шифрования, управления ключами и обмена ключами. В Интернете есть много ресурсов, которые охватывают эту информацию, и вам нужно только выполнить поиск в Интернете по слову «криптография», чтобы найти гораздо больше деталей, чем вы когда-либо хотели.

Для целей данного обсуждения данные на диске обычно шифруются одним из двух способов: на уровне файла (что включает шифрование отдельных файлов и/или папок) или на уровне диска/тома (что включает шифрование всего диска или тома).. В Windows шифрование на уровне файлов обычно выполняется с помощью шифрующей файловой системы (EFS), а шифрование на уровне томов — с помощью BitLocker.

Данные в пути — это отдельная история. Методы шифрования, используемые для шифрования сохраненных данных, обычно не защищают данные при их отправке по сети. Чтобы злоумышленник не смог перехватить и прочитать его, его необходимо зашифровать. Веб-трафик данных обычно шифруется с помощью Transport Layer Security (TLS), который является более новой итерацией Secure Sockets Layer (SSL). Не веб-данные могут быть зашифрованы с использованием протоколов VPN, таких как туннелирование IPsec или SSH. Электронная почта может быть зашифрована с помощью S/MIME или PGP.

Наконец, конфиденциальные данные должны быть защищены от возможности того, что авторизованный пользователь, которому предоставлен доступ к данным, может намеренно или случайно поделиться ими с лицами, не имеющими права доступа к ним. Это может включать пересылку электронной почты, копирование и вставку информации из документа Word, распечатку содержимого и оставление его там, где кто-то может его увидеть, и тому подобные сценарии. В сетях Windows этого можно избежать, внедрив службы управления правами Active Directory или Azure Rights Management. С помощью управления правами владелец/отправитель файла или сообщения может установить для него права, ограничивающие действия получателя. Вы можете заблокировать возможность пересылки, изменения, копирования или печати и даже установить период времени, по истечении которого файл больше не будет доступен исходному получателю.

ТИП ДАННЫХ

ВОПРОС БЕЗОПАСНОСТИ

РЕШЕНИЕ(Я)

Данные в состоянии покоя

Ненадежные пользователи

Аутентификация по паролю

Многофакторная аутентификация

Данные в состоянии покоя

Несанкционированный доступ

Контроль доступа

Шифрование сохраненных данных:

Шифрование на уровне файлов

Шифрование на уровне диска/тома

Данные в пути

Захват и несанкционированный доступ

Сетевое шифрование

VPN-протоколы

SSL/TLS

Документы и электронная почта

Совместное использование авторизованными пользователями с неавторизованными пользователями

Управление правами

Завершение

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

  • Application Security Redux: все дело в приложениях (часть 4)
  • Снижение безопасности приложений: все дело в приложениях (часть 8)