Введение в разработку безопасных приложений для Windows

Статья
07/08/2024

Эта вводная статья поможет архитекторам приложений и разработчикам лучше понять различные возможности платформы Windows 10, которые ускоряют создание безопасных приложений универсальная платформа Windows (UWP). В нем подробно описано, как использовать функции безопасности Windows, доступные на каждом из следующих этапов: проверка подлинности, проверка подлинности, проверка подлинности, проверка подлинности и неактивных данных. Подробные сведения о каждой теме можно найти, просмотрив дополнительные ресурсы, включенные в каждую главу.

1. Введение

Разработка безопасного приложения может быть проблемой. В современном быстро развивающемся мире мобильных, социальных, облачных и сложных корпоративных приложений клиенты ожидают, что приложения становятся доступными и обновленными быстрее, чем когда-либо. Они также используют множество типов устройств, добавляя к сложности создания приложений. Если вы создаете для Windows универсальная платформа Windows (UWP), это может включать в себя традиционный список настольных компьютеров, ноутбуков, планшетов и мобильных устройств; в дополнение к растущему списку новых устройств, охватывающих Интернет вещей, Xbox One, Microsoft Surface Hub и HoloLens. Разработчик должен безопасно обмениваться данными и хранить данные на всех платформах или устройствах, участвующих в разработке.

Ниже приведены некоторые преимущества использования функций безопасности Windows.

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

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

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

Наконец, данные неактивных данных связаны с данными, находящимися в памяти или на носителе хранилища. Приложения Windows имеют модель приложения, которая предотвращает несанкционированный доступ к данным между приложениями и предлагает API-интерфейсы шифрования для дальнейшего защиты данных на устройстве. Функцию с именем Credential Locker можно использовать для безопасного хранения учетных данных пользователей на устройстве с помощью операционной системы, предотвращающей доступ к другим приложениям.

2 факторы проверки подлинности

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

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

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

Пароль, созданный пользователем, сам по себе является фактором проверки подлинности, но зачастую это недостаточно; Любой пользователь, который знает пароль, может олицетворить пользователя, которому он принадлежит. Смарт-карта может обеспечить более высокий уровень безопасности, но это может быть украдено, потеряно или неправильно. Система, которая может пройти проверку подлинности пользователя по отпечатку пальца или по окулярному сканированию, может обеспечить самый высокий и удобный уровень безопасности, но требует дорогого и специализированного оборудования (например, камеры Intel RealSense для распознавания лиц), которые могут быть недоступны для всех пользователей.

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

2.1 Однофакторная проверка подлинности

Эта форма проверки подлинности основана на учетных данных одного пользователя. Обычно это пароль, но это также может быть личный идентификационный номер (ПИН-код).

Ниже приведен процесс однофакторной проверки подлинности.

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

однофакторная проверка подлинности

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

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

Для всех его недостатков однофакторная проверка подлинности обеспечивает пользовательский контроль учетных данных. Они создают его и изменяют его, и для процесса проверки подлинности требуется только клавиатура. Это основной аспект, который отличает однофакторную проверку подлинности от многофакторной проверки подлинности.

Брокер веб-проверки подлинности 2.1.1

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

Используя OAuth, ИТ-отделы могут эффективно "аутсорсинг" сложность поддержания базы данных с именами пользователей и паролями, сброса функциональных возможностей паролей и т. д. сторонним поставщиком удостоверений, например Facebook, X или Майкрософт.

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

Брокер веб-проверки подлинности в Windows предоставляет набор API и инфраструктуры для приложений для использования протоколов проверки подлинности и авторизации, таких как OAuth и OpenID. Приложения могут инициировать операции проверки подлинности через API WebAuthenticationBroker, что приводит к возврату WebAuthenticationResult. Обзор потока коммуникации показан на следующем рисунке.

рабочий процесс wab

Приложение выступает в качестве брокера, инициируя проверку подлинности с помощью поставщика удостоверений через WebView в приложении. Когда поставщик удостоверений прошел проверку подлинности пользователя, он возвращает маркер приложению, которое можно использовать для запроса сведений о пользователе от поставщика удостоверений. В качестве меры безопасности приложение должно быть зарегистрировано в поставщике удостоверений, прежде чем он сможет брокером процессов проверки подлинности с поставщиком удостоверений. Эти шаги регистрации отличаются для каждого поставщика.

Ниже приведен общий рабочий процесс вызова API WebAuthenticationBroker для взаимодействия с поставщиком.

Создайте строки запроса для отправки поставщику удостоверений. Количество строк и сведения в каждой строке отличаются для каждой веб-службы, но обычно они включают две строки URI, содержащие URL-адрес: один, в который отправляется запрос проверки подлинности, и один из которых перенаправляется пользователем после завершения авторизации.
Вызовите WebAuthenticationBroker.AuthenticationAsync, передавая строки запроса, и дождитесь ответа от поставщика удостоверений.
Вызовите WebAuthenticationResult.ResponseStatus , чтобы получить состояние при получении ответа.
Если связь выполнена успешно, обработайте строку ответа, возвращенную поставщиком удостоверений. Если ошибка не выполнена, обработайте ошибку.

Если связь выполнена успешно, обработайте строку ответа, возвращенную поставщиком удостоверений. Если ошибка не выполнена, обработайте ошибку.

Пример кода C#, который для этого процесса приведен ниже. Дополнительные сведения и подробное пошаговое руководство см. в разделе WebAuthenticationBroker. Полный пример кода см. в примере WebAuthenticationBroker на сайте GitHub.

string startURL = "https://<providerendpoint>?client_id=<clientid>";
string endURL = "http://<AppEndPoint>";

var startURI = new System.Uri(startURL);
var endURI = new System.Uri(endURL);

try
{
    WebAuthenticationResult webAuthenticationResult = 
        await WebAuthenticationBroker.AuthenticateAsync( 
            WebAuthenticationOptions.None, startURI, endURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case WebAuthenticationStatus.Success:
            // Successful authentication. 
            break;
        case WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            break;
        default:
            // Other error.
        break;
    }
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and
    // Network Unavailable errors here. 
}

2.2 Многофакторная проверка подлинности

Многофакторная проверка подлинности использует несколько факторов проверки подлинности. Как правило, "то, что вы знаете", например пароль, сочетается с "то, что у вас есть", которое может быть мобильным телефоном или смарт-картой. Даже если злоумышленник обнаруживает пароль пользователя, учетная запись по-прежнему недоступна без устройства или карты. И если скомпрометировано только устройство или карточка, злоумышленнику не будет полезно без пароля. Поэтому многофакторная проверка подлинности является более безопасной, но и более сложной, чем однофакторная проверка подлинности.

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

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

двухфакторная проверка подлинности

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

2.2.1 Azure Active Directory

Azure Active Directory (Azure AD) — это облачная служба управления удостоверениями и доступом, которая может служить поставщиком удостоверений в однофакторной или многофакторной проверке подлинности. Аутентификация Azure AD может использоваться с кодом проверки или без нее.

Хотя Azure AD также может реализовать однофакторную проверку подлинности, предприятия обычно требуют более высокой безопасности многофакторной проверки подлинности. В конфигурации многофакторной проверки подлинности пользователь, выполняющий проверку подлинности с помощью учетной записи Azure AD, может иметь код проверки, отправленный в виде SMS-сообщения на мобильный телефон или мобильное приложение Azure Authenticator.

Кроме того, Azure AD можно использовать в качестве поставщика OAuth, предоставляя стандартному пользователю механизм проверки подлинности и авторизации приложениям на различных платформах. Дополнительные сведения см. в статье Azure Active Directory и Многофакторная идентификация в Azure.

2.4 Windows Hello

В Windows удобный механизм многофакторной проверки подлинности встроен в операционную систему. Windows Hello — это новая система биометрического входа, встроенная в Windows. Так как он встроен непосредственно в операционную систему, Windows Hello позволяет идентификации лиц или отпечатков пальцев разблокировать устройства пользователей. Хранилище безопасных учетных данных Windows защищает биометрические данные на устройстве.

Windows Hello предоставляет надежный способ распознавания отдельного пользователя устройства, который обращается к первой части пути между пользователем и запрошенной службой или элементом данных. После того как устройство распознало пользователя, он по-прежнему должен пройти проверку подлинности пользователя, прежде чем определить, следует ли предоставлять доступ к запрошенным ресурсам. Windows Hello также обеспечивает надежную двухфакторную проверку подлинности (2FA), которая полностью интегрирована в Windows и заменяет повторно используемые пароли сочетанием определенного устройства, биометрического жеста или ПИН-кода. ПИН-код указывается пользователем в рамках регистрации учетной записи Майкрософт.

Windows Hello — это не просто замена традиционных систем 2FA, хотя. Это концептуально похоже на смарт-карты: проверка подлинности выполняется с помощью криптографических примитивов вместо сравнения строк, а основной материал пользователя безопасно в защищенном оборудовании. Microsoft Hello не требует дополнительных компонентов инфраструктуры, необходимых для развертывания смарт-карт. В частности, для управления сертификатами не требуется инфраструктура открытых ключей (PKI), если у вас нет. Windows Hello объединяет основные преимущества смарт-карт — гибкость развертывания виртуальных смарт-карт и надежную безопасность для физических смарт-карт без каких-либо недостатков.

Устройство должно быть зарегистрировано в Windows Hello, прежде чем пользователи смогут пройти проверку подлинности. Windows Hello использует асимметричное шифрование (открытый или закрытый ключ), в котором одна сторона использует открытый ключ для шифрования данных, которые другая сторона может расшифровывать с помощью закрытого ключа. В случае Windows Hello он создает набор пар открытых и закрытых ключей и записывает закрытые ключи на микросхему доверенного платформенного модуля (TPM) устройства. После регистрации устройства приложения UWP могут вызывать системные API для получения открытого ключа пользователя, который можно использовать для регистрации пользователя на сервере.

Рабочий процесс регистрации приложения может выглядеть следующим образом:

регистрация windows hello

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

Дополнительные сведения о Windows Hello см. в Windows Hello для бизнеса обзоре и руководстве разработчика Windows Hello.

3 Методы безопасности в полете

Методы безопасности в полете применяются к данным, передаваемым между устройствами, подключенными к сети. Данные могут передаваться между системами в среде высокой безопасности частной корпоративной интрасети или между клиентом и веб-службой в небезопасной среде интернета. Приложения Windows поддерживают такие стандарты, как SSL через свои сетевые API, и работают с такими технологиями, как Azure Управление API, с помощью которых разработчики могут обеспечить соответствующий уровень безопасности для своих приложений.

3.1 Удаленная проверка подлинности системы

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

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

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

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

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

3.2 SSL-подключения

Для установления и поддержания безопасных подключений к клиентам веб-службы могут использовать протокол SSL, который поддерживается протоколом HTTPS. SSL обеспечивает конфиденциальность сообщений и целостность, поддерживая шифрование открытых ключей, а также сертификаты сервера. ПРОТОКОЛ SSL заменен протоколом TLS, но ПРОТОКОЛ TLS часто называется SSL.

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

Закрепление SSL 3.2.1

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

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

SSL-манифест

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

Следующий код C# иллюстрирует этот метод закрепления SSL. Метод ValidateSSLRoot использует класс HttpClient для выполнения HTTP-запроса. После отправки ответа клиент использует коллекцию RequestMessage.TransportInformation.ServerIntermediateCertificates для проверки сертификатов, возвращаемых сервером. Затем клиент может проверить всю цепочку сертификатов с отпечатками, которые он включил. Этот метод требует обновления отпечатков сертификата в приложении при истечении срока действия сертификата и возобновления.

private async Task ValidateSSLRoot()
{
    // Send a get request to Bing
    var httpClient = new HttpClient();
    var bingUri = new Uri("https://www.bing.com");
    HttpResponseMessage response = 
        await httpClient.GetAsync(bingUri);

    // Get the list of certificates that were used to
    // validate the server's identity
    IReadOnlyList<Certificate> serverCertificates = response.RequestMessage.TransportInformation.ServerIntermediateCertificates;
  
    // Perform validation
    if (!ValidateCertificates(serverCertificates))
    {
        // Close connection as chain is not valid
        return;
    }
    // Validation passed, continue with connection to service
}

private bool ValidateCertificates(IReadOnlyList<Certificate> certs)
{
    // In this example, we iterate through the certificates
    // and check that the chain contains
    // one specific certificate we are expecting
    foreach (var cert in certs)
    {
        byte[] thumbprint = cert.GetHashValue();

        // Check if the thumbprint matches whatever you 
        // are expecting
        var expected = new byte[] { 212, 222, 32, 208, 94, 102, 
            252, 83, 254, 26, 80, 136, 44, 120, 219, 40, 82, 202, 
            228, 116 };

        // ThumbprintMatches does the byte[] comparison 
        if (ThumbprintMatches(thumbprint, expected))
        {
            return true;
        }
    }
    return false;
}

3.3. Публикация и защита доступа к REST API

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

Издатели и администраторы API могут легко настроить API с помощью портала издателя Azure Управление API. Здесь можно создать наборы API и получить к ним доступ, чтобы управлять доступом к каким API-интерфейсам.

Разработчики , желающие получить доступ к этим API, могут выполнять запросы через портал разработчика, который может немедленно предоставить доступ или требовать утверждения издателем или администратором. Разработчики также могут просматривать документацию по API и пример кода на портале разработчиков, чтобы быстро внедрить API, предлагаемые веб-службой.

Приложения, создаваемые этими разработчиками, затем получают доступ к API через прокси-сервер, предлагаемый Azure Управление API. Прокси-сервер предоставляет слой некурсности, скрывая фактическую конечную точку API на сервере издателя или администратора, а также может включать дополнительную логику, например перевод API, чтобы обеспечить согласованность доступного API при перенаправлении вызова к одному API на другой. Он также может использовать фильтрацию IP-адресов для блокировки вызовов API, исходящих из определенного ДОМЕНА ИЛИ набора доменов. Azure Управление API также защищает свои веб-службы с помощью набора открытых ключей, называемых ключами API, для проверки подлинности и авторизации каждого вызова API. При сбое авторизации доступ к API и поддерживаемым функциям блокируется.

Azure Управление API также может уменьшить количество вызовов API к службе (процедура, называемая регулированием), чтобы оптимизировать производительность веб-службы. Дополнительные сведения см. в статье azure Управление API и Azure Управление API в AzureCon 2015.

4 методы безопасности в неактивных данных

Когда данные поступают на устройство, мы называем его "неактивных данных". Эти данные должны храниться на устройстве в безопасном режиме, чтобы он не был несанкционированным пользователями или приложениями. Модель приложения в Windows делает много, чтобы гарантировать, что данные, хранящиеся любым приложением, доступны только этому приложению, предоставляя API для предоставления общего доступа к данным при необходимости. Дополнительные API также доступны для обеспечения безопасного шифрования данных и хранения учетных данных.

Модель приложения Windows 4.1

Традиционно Windows никогда не имел определения приложения. Это чаще всего называется исполняемым файлом (.exe), и это никогда не включало установку, хранение состояния, длину выполнения, управление версиями, интеграцию ОС или связь между приложениями. Модель универсальная платформа Windows определяет модель приложения, которая охватывает установку, среду выполнения, управление ресурсами, обновления, модель данных и удаление.

Приложения Windows 10 выполняются в контейнере, что означает, что они имеют ограниченные привилегии по умолчанию (дополнительные привилегии можно запрашивать и предоставлять пользователю). Например, если приложение хочет получить доступ к файлам в системе, средство выбора файлов из пространства имен Windows.Storage.Pickers должно использоваться, чтобы разрешить пользователю выбирать файл (прямой доступ к файлам не включен). Другой пример заключается в том, если приложение хочет получить доступ к данным о расположении пользователя, оно должно включить возможность устройства расположения, которое должно быть объявлено, запрашивая пользователю во время загрузки, что это приложение запрашивает доступ к расположению пользователя. Поверх этого приложение впервые хочет получить доступ к расположению пользователя, отображается дополнительный запрос согласия для пользователя, запрашивая разрешение на доступ к данным.

Обратите внимание, что эта модель приложения выступает в качестве "тюрьмы" для приложений, что означает, что они не могут связаться, но это не "замок", который не может быть достигнут извне (приложения с правами администратора могут, конечно, достичь). Device Guard в Windows, которая позволяет организациям или ИТ указать, какие приложения (Win32) разрешены для выполнения, могут дополнительно ограничить этот доступ.

Модель приложения также управляет жизненным циклом приложения. Это ограничивает фоновое выполнение приложений по умолчанию, например. Как только приложение переходит в фоновый режим, процесс приостановлен ( после предоставления приложению краткого периода для решения приостановки приложения в коде- и его память заморожена. Операционная система предоставляет механизмы для приложений запрашивать конкретное фоновое выполнение задачи (по расписанию, активируется различными событиями, такими как подключение к Интернету или Bluetooth, изменения питания и т. д., а также в определенных сценариях, таких как воспроизведение музыки или отслеживание GPS).

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

Дополнительные сведения см. в статье "Универсальное руководство. Понимание жизненного цикла приложения Windows 10/11".

Защита сохраненных учетных данных 4.2

Приложения Windows, которые обращаются к службам, прошедшим проверку подлинности, часто предоставляют пользователям возможность хранения учетных данных на локальном устройстве. Это удобно для пользователей; когда они предоставляют имя пользователя и пароль, приложение автоматически использует их в последующих запусках приложения. Так как это может быть проблемой безопасности, если злоумышленник получает доступ к этим сохраненным данным, Windows предоставляет возможность упаковаемых приложений хранить учетные данные пользователей в защищенном хранилище учетных данных. Приложение вызывает API Locker учетных данных для хранения и получения учетных данных из хранилища, а не хранения их в контейнере хранилища приложения. Хранилище учетных данных управляется операционной системой, но доступ ограничен приложением, которое хранит их, предоставляя безопасно управляемое решение для хранения учетных данных.

Когда пользователь предоставляет учетные данные для хранения, приложение получает ссылку на хранилище учетных данных с помощью объекта PasswordVault в пространстве имен Windows.Security.Credentials. Затем он создает объект PasswordCredential , содержащий идентификатор для приложения Windows и имени пользователя и пароля. Это передается методу PasswordVault.Add для хранения учетных данных в хранилище. В следующем примере кода C# показано, как это сделать.

var vault = new PasswordVault();
vault.Add(new PasswordCredential("My App", username, password));

В следующем примере кода C# приложение запрашивает все учетные данные, соответствующие приложению, вызывая метод FindAllByResource объекта PasswordVault. Если возвращается несколько, пользователь предложит ввести свое имя пользователя. Если учетные данные не находятся в хранилище, приложение предложит пользователю. Затем пользователь вошел на сервер с помощью учетных данных.

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    PasswordCredential loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }
    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}

private PasswordCredential GetCredentialFromLocker()
{
    PasswordCredential credential = null;

    var vault = new PasswordVault();

    IReadOnlyList<PasswordCredential> credentialList = null;

    try
    {
        credentialList = vault.FindAllByResource(resourceName);
    }
    catch(Exception)
    {
        return null;
    }

    if (credentialList.Count == 1)
    {
        credential = credentialList[0];
    }
    else if (credentialList.Count > 0)
    {
        // When there are multiple usernames,
        // retrieve the default username. If one doesn't
        // exist, then display UI to have the user select
        // a default username.
        defaultUserName = GetDefaultUserNameUI();

        credential = vault.Retrieve(resourceName, defaultUserName);
    }
    return credential;
}

Дополнительные сведения см. в разделе "Хранилище учетных данных".

4.3 Хранимая защита данных

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

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

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

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

Разработчики приложений Windows могут использовать классы SymmetricKeyAlgorithmProvider и AsymmetricKeyAlgorithmProvider для реализации симметричного и асимметричного шифрования в своих приложениях UWP. Кроме того, класс CryptographicEngine можно использовать для шифрования и расшифровки данных, подписывания содержимого и проверки цифровых подписей. Приложения также могут использовать класс DataProtectionProvider в пространстве имен Windows.Security.Cryptography.DataProtection для шифрования и расшифровки сохраненных локальных данных.

4.3.2. Обнаружение изменения сообщений (MACs, хэши и подписи)

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

MACs проверяют такие сообщения.

Отправитель наследует тег MAC с помощью секретного ключа в качестве входных данных для алгоритма MAC.
Отправитель отправляет тег MAC и сообщение получателю.
Получатель получает тег MAC с помощью секретного ключа и сообщения в качестве входных данных для алгоритма MAC.
Получатель сравнивает тег MAC с тегом MAC отправителя. Если они одинаковы, то мы знаем, что сообщение не было изменено.

Проверка mac

Приложения Windows могут реализовать проверку сообщений MAC путем вызова класса MacAlgorithmProvider для создания ключа и класса CryptographicEngine для выполнения алгоритма шифрования MAC.

4.3.3 Использование хэшей

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

Хэш-значение можно использовать вместо MAC в приведенном выше сценарии передачи сообщений. Отправитель отправляет хэш-значение и сообщение, а получатель получает собственное хэш-значение от хэш-значения и сообщения отправителя и сравнивает два хэш-значения. Приложения, работающие в Windows, могут вызывать класс HashAlgorithmProvider , чтобы перечислить доступные хэш-алгоритмы и запустить один из них. Класс CryptographicHash представляет хэш-значение. Метод CryptographicHash.GetValueAndReset можно использовать для многократного хэширования разных данных без необходимости повторного создания объекта для каждого использования. Метод Append класса CryptographicHash добавляет новые данные в буфер для хэширования. Весь процесс показан в следующем примере кода C#.

public void SampleReusableHash()
{
    // Create a string that contains the name of the
    // hashing algorithm to use.
    string strAlgName = HashAlgorithmNames.Sha512;

    // Create a HashAlgorithmProvider object.
    HashAlgorithmProvider objAlgProv = HashAlgorithmProvider.OpenAlgorithm(strAlgName);

    // Create a CryptographicHash object. This object can be reused to continually
    // hash new messages.
    CryptographicHash objHash = objAlgProv.CreateHash();

    // Hash message 1.
    string strMsg1 = "This is message 1";
    IBuffer buffMsg1 = CryptographicBuffer.ConvertStringToBinary(strMsg1, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg1);
    IBuffer buffHash1 = objHash.GetValueAndReset();

    // Hash message 2.
    string strMsg2 = "This is message 2";
    IBuffer buffMsg2 = CryptographicBuffer.ConvertStringToBinary(strMsg2, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg2);
    IBuffer buffHash2 = objHash.GetValueAndReset();

    // Convert the hashes to string values (for display);
    string strHash1 = CryptographicBuffer.EncodeToBase64String(buffHash1);
    string strHash2 = CryptographicBuffer.EncodeToBase64String(buffHash2);
}

4.3.4 Цифровые подписи

Целостность данных хранимого сообщения с цифровой подписью проверяется аналогично проверке подлинности MAC. Вот как работает рабочий процесс цифровой подписи.

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

цифровые подписи

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

Дополнительные сведения см. в статьях по цифровым подписям, maCs, хэшам и подписям, а также криптографии.

Сводка 5

Универсальная платформа Windows в Windows предлагает ряд способов использования возможностей операционной системы для создания более безопасных приложений. В различных сценариях проверки подлинности, таких как однофакторная, многофакторная или брокерская проверка подлинности с помощью поставщика удостоверений OAuth, API существуют для устранения наиболее распространенных проблем с проверкой подлинности. Windows Hello предоставляет новую биометрическую систему входа, которая распознает пользователя и активно разбивает усилия по обходу правильной идентификации. Он также предоставляет несколько уровней ключей и сертификатов, которые никогда не могут быть выявлены или использованы вне доверенного модуля платформы. Кроме того, можно получить дополнительный уровень безопасности с помощью дополнительных ключей идентификации и сертификатов аттестации.

Для защиты данных во время полета API существуют для безопасного взаимодействия с удаленными системами по протоколу SSL, обеспечивая возможность проверки подлинности сервера с помощью закрепления SSL. Безопасное публикация API-интерфейсов и в управляемом режиме — это то, в котором azure Управление API помогает, предоставляя мощные параметры конфигурации для предоставления API-интерфейсов в Интернете с помощью прокси-сервера, который обеспечивает дополнительную маскировку конечной точки API. Доступ к этим API защищен с помощью ключей API и вызовов API можно регулировать для управления производительностью.

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

Поделиться через