Двоичные файлы, содержащие конфиденциальные данные, должны быть замаскированы
Заголовок
Сведения
Компонент
Граница доверия между компьютерами
Этап SDL
Развертывание
Применимые технологии
Универсальный
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Двоичные файлы, содержащие конфиденциальные данные, например коммерческие тайны или конфиденциальную бизнес-логику, которую нельзя отменить, следует маскировать. Это позволит остановить проведение инженерного анализа сборок. Для этой цели можно использовать такой инструмент, как CryptoObfuscator.
Используйте шифрование на уровне файловой системы (EFS) для защиты конфиденциальных данных пользователя
Заголовок
Сведения
Компонент
Граница доверия между компьютерами
Этап SDL
Сборка
Применимые технологии
Универсальный
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Рассмотрите возможность использования шифрования на уровне файловой системы для защиты конфиденциальных данных пользователя от злоумышленников, использующих физический доступ к компьютеру.
Настройте шифрование конфиденциальных данных, сохраняемых приложением в файловой системе
Заголовок
Сведения
Компонент
Граница доверия между компьютерами
Этап SDL
Развертывание
Применимые технологии
Универсальный
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Шифруйте конфиденциальные данные, сохраняемые приложением в файловой системе (например, с помощью DPAPI), если невозможно применить шифрование на уровне файловой системы.
Конфиденциальное содержимое не должно кэшироваться в браузере
Заголовок
Сведения
Компонент
Веб-приложение
Этап SDL
Сборка
Применимые технологии
Универсальные, веб-формы, MVC 5, MVC 6
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Браузеры могут сохранять информацию для кэширования и ведения истории. Эти кэшированные файлы хранятся в папке, подобной папке временных файлов Интернета в Internet Explorer. При повторном обращении к страницам браузер отображает их из кэша. Если конфиденциальные сведения отображаются пользователю (например, адреса, данные кредитной карты, номер социального страхования или имя пользователя), эта информация может быть сохранена в кэше браузера, а значит, ее можно получить путем проверки кэша браузера или просто нажатием кнопки "Назад" в браузере. Задайте для заголовка ответа Cache-Control значение no-store ("не сохранять") для всех страниц.
Вы можете сделать это, используя фильтр. Воспользуйтесь следующим примером.
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext == null || (filterContext.HttpContext != null && filterContext.HttpContext.Response != null && filterContext.HttpContext.Response.IsRequestBeingRedirected))
{
//// Since this is MVC pipeline, this should never be null.
return;
}
var attributes = filterContext.ActionDescriptor.GetCustomAttributes(typeof(System.Web.Mvc.OutputCacheAttribute), false);
if (attributes == null || **Attributes**.Count() == 0)
{
filterContext.HttpContext.Response.Cache.SetNoStore();
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
if (!filterContext.IsChildAction)
{
filterContext.HttpContext.Response.AppendHeader("Pragma", "no-cache");
}
}
base.OnActionExecuting(filterContext);
}
Зашифруйте разделы файлов конфигурации веб-приложения, содержащие конфиденциальные данные
Такие файлы конфигурации, как web.config и appsettings.json, часто используются для хранения конфиденциальной информации, включая имена пользователей, пароли, строки подключения к базам данных и ключи шифрования. Если эти данные не защищены, приложение становится уязвимым для злоумышленников, которые таким образом могут получить различные конфиденциальные сведения, например имена учетных записей пользователей, пароли, имена баз данных и имена серверов. На основе типа развертывания (Azure или локального) зашифруйте конфиденциальные разделы файлов конфигурации с помощью DPAPI или таких служб, как Azure Key Vault.
Явным образом отключите автозаполнение атрибута HTML в конфиденциальных формах и входных данных
Атрибут autocompletee указывает, включено ли автозаполнение формы. Если автозаполнение включено, браузер автоматически использует значения, введенные пользователем. Например, если форма, в которую вы ввели новое имя и пароль, успешно отправлена, браузер спрашивает, нужно ли сохранить пароль. В дальнейшем при отображении формы имя и пароль заполняются автоматически или непосредственно во время введения имени. Злоумышленник, у которого есть локальный доступ, может получить открытый пароль из кэша браузера. По умолчанию автозаполнение включено, поэтому его явным образом следует отключить.
Замаскируйте конфиденциальные данные, отображаемые на экране пользователя
Заголовок
Сведения
Компонент
Веб-приложение
Этап SDL
Сборка
Применимые технологии
Универсальный
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Конфиденциальные данные, такие как пароли, номера кредитных карт, номера социального страхования и т. д., при отображении на экране должны быть скрыты. Это необходимо для предотвращения несанкционированного доступа к данным (например, сотрудники могут просмотреть пароль при его вводе другим сотрудником, персонал группы поддержки может просмотреть номера социального страхования пользователей). Убедитесь, что эти данные не отображаются в обычном тексте и что они скрыты должным образом. Вам необходимо позаботиться об этом как на этапе принятия их в качестве входных данных (например, input type="password"), так и при отображении на экране (например, отображать только последние 4 цифры номера кредитной карты).
Реализуйте динамическую маскировку данных, чтобы уменьшить шансы раскрытия конфиденциальных данных для непривилегированных пользователей
Назначение динамического маскирования данных — ограничение раскрытия конфиденциальных данных, при котором пользователи, у которых нет доступа к данным, не смогут их просматривать. Динамическое маскирование данных не сможет помешать пользователям подключиться к базе данных напрямую и выполнить запросы для получения фрагментов конфиденциальных данных. Динамическая маскировка данных дополняет другие функции безопасности SQL Server (аудит, шифрование, защита на уровне строк и т. д.). Мы рекомендуем использовать эту функцию в сочетании с другими для обеспечения лучшей защиты конфиденциальных сведений базы данных. Обратите внимание, что эта функция поддерживается только в SQL Server (начиная с версии 2016) и Базе данных SQL Azure.
Обеспечьте хранение паролей в формате хэша с использованием случайной строки данных
Пароли не должны храниться в пользовательских базах данных хранилища. Вместо этого хэши паролей должны храниться со случайными данными. Эти данные должны быть уникальными для каждого пользователя. Кроме того, перед сохранением пароля необходимо применить bcrypt, scrypt или PBKDF2 с минимальным числом итераций рабочего фактора в 150 000 циклов, чтобы предотвратить возможность атак методом подбора.
Шифруйте конфиденциальные данные в столбцах базы данных
В базе данных должны быть зашифрованы такие конфиденциальные данные, как номера кредитных карт. К данным можно применять шифрование на уровне столбцов или функции шифрования с помощью функции-приложения.
Функция прозрачного шифрования данных (TDE) в SQL Server помогает шифровать конфиденциальные данные в базе данных и защищать ключи, используемые для шифрования данных с помощью сертификата. Таким образом, пользователи без ключей не смогут использовать эти данные. Функция прозрачного шифрования данных защищает "неактивные" данные, то есть файлы данных и журналов. Благодаря ей обеспечивается соответствие требованиям различных законов, постановлений и рекомендаций, действующих в разных отраслях.
SQL Server может шифровать данные при создании резервной копии. Для создания зашифрованных файлов резервной копии достаточно указать алгоритм шифрования и шифратор (сертификат или асимметричный ключ) при создании резервной копии.
В хранилище браузера не должны храниться конфиденциальные данные, относящиеся к веб-API
Заголовок
Сведения
Компонент
Веб-интерфейс API
Этап SDL
Сборка
Применимые технологии
MVC 5, MVC 6
Атрибуты
Поставщик удостоверений — ADFS, поставщик удостоверений — идентификатор Microsoft Entra
Ссылки
Н/П
Шаги
В некоторых реализациях конфиденциальные артефакты, связанные с проверкой подлинности веб-API, хранятся в локальном хранилище браузера. Например, артефакты проверки подлинности Microsoft Entra, такие как adal.idtoken, adal.nonce.idtoken, adal.access.token.key, adal.token.keys, adal.state.login, adal.session.state, adal.expiration.key и т. д.
Эти артефакты доступны даже после выхода или закрытия браузера. Если злоумышленник получит доступ к этим артефактам, он может повторно использовать их для доступа к защищенным ресурсам (API). Убедитесь, что все конфиденциальные артефакты, относящиеся к веб-API, не хранятся в хранилище браузера. Когда доступ к клиентскому хранилищу (например, одностраничные приложения, которые используют неявные потоки OpenIdConnect или OAuth, хранят маркеры доступа локально) неизбежен, используйте временные хранилища. Например, вместо локального хранилища используйте хранилище для сеанса.
Пример
Приведенный ниже фрагмент кода JavaScript взят из пользовательской библиотеки проверки подлинности, хранящей артефакты проверки подлинности в локальном хранилище. Необходимо избегать таких реализаций.
ns.AuthHelper.Authenticate = function () {
window.config = {
instance: 'https://login.microsoftonline.com/',
tenant: ns.Configurations.Tenant,
clientId: ns.Configurations.AADApplicationClientID,
postLogoutRedirectUri: window.location.origin,
cacheLocation: 'localStorage', // enable this for Internet Explorer, as sessionStorage does not work for localhost.
};
Шифрование конфиденциальных данных, хранящихся в Cosmos DB
Заголовок
Сведения
Компонент
Azure DocumentDB
Этап SDL
Сборка
Применимые технологии
Универсальный
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Зашифруйте конфиденциальные данные на уровне приложения, прежде чем сохранить их в DocumentDB, или сохраните все конфиденциальные данные в других решениях хранения, например в службе хранилища Azure или Azure SQL.
Шифруйте диски, используемые виртуальными машинами, с помощью шифрования дисков Azure
Шифрование дисков Azure — это новая функция, которая в настоящее время находится на этапе предварительной версии. Она позволяет шифровать диски ОС и данных, используемые виртуальными машинами IaaS. Для Windows диски шифруются с помощью стандартной отраслевой технологии шифрования BitLocker. Для Linux диски шифруются с помощью технологии DM-Crypt. Функция интегрируется с хранилищем ключей Azure, что позволяет управлять ключами шифрования дисков. Решение для шифрования дисков Azure поддерживает следующие три сценария шифрования данных клиента:
включение шифрования в новых виртуальных машинах IaaS, созданных на основе шифруемых клиентом файлов VHD и предоставленных клиентом ключей шифрования, которые хранятся в хранилище ключей Azure;
включение шифрования в новых виртуальных машинах IaaS, созданных с помощью Azure Marketplace;
включение шифрования в существующих виртуальных машинах IaaS, которые уже работают в Azure.
Секретом может считаться любая конфиденциальная информации, например строка подключения к хранилищу, пароль или другое значение, которое не должно обрабатываться в виде обычного текста. Используйте Azure Key Vault для управления ключами и секретами в приложениях Service Fabric.
Выполняйте моделирование безопасности, при необходимости привлекая рабочие подразделения и группы
Заголовок
Сведения
Компонент
Dynamics CRM
Этап SDL
Сборка
Применимые технологии
Универсальный
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Выполняйте моделирование безопасности, при необходимости привлекая рабочие подразделения и группы
Ограничьте доступ к общим функциям критически важных сущностей
Заголовок
Сведения
Компонент
Dynamics CRM
Этап SDL
Развертывание
Применимые технологии
Универсальный
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Ограничьте доступ к общим функциям критически важных сущностей
Информируйте пользователей о рисках, связанных с использованием функции "Поделиться" Dynamics CRM, и предоставьте им рекомендации безопасности
Заголовок
Сведения
Компонент
Dynamics CRM
Этап SDL
Развертывание
Применимые технологии
Универсальный
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Информируйте пользователей о рисках, связанных с использованием функции "Поделиться" Dynamics CRM, и предоставьте им рекомендации безопасности
Включите стандартные правила разработки, запрещающие показ данных о конфигурации в управлении исключениями
Заголовок
Сведения
Компонент
Dynamics CRM
Этап SDL
Развертывание
Применимые технологии
Универсальный
Атрибуты
Н/П
Ссылки
Н/П
Шаги
Включите стандартные правила разработки, запрещающие показ данных о конфигурации в управлении исключениями за пределами среды разработки. Протестируйте эту возможность как часть проверки кода или во время периодических проверок.
Используйте шифрование службы хранилища Azure (SSE) для неактивных данных (предварительная версия)
Шифрование службы хранилища Azure (SSE) для неактивных данных помогает защитить данные в соответствии с предложениями по безопасности и соответствию вашей организации. С помощью этой функции служба хранилища Azure автоматически шифрует данные перед сохранением в хранилище и расшифровывает их перед извлечением. Шифрование, расшифровка и управление ключами полностью прозрачны для пользователей. Шифрование службы хранилища применяется только к блочным, страничным и добавочным BLOB-объектам. Другие типы данных, включая таблицы, очереди и файлы, не шифруются.
Ниже описан рабочий процесс шифрования и расшифровки.
Клиент включает шифрование в учетной записи хранения.
Когда клиент записывает новые данные (выполняя операции PUT Blob, PUT Block, PUT Page и другие) в хранилище BLOB-объектов, к каждой операции записи применяется 256-разрядное шифрование AES, являющееся самой надежной технологией блочного шифрования на сегодняшний день.
Когда клиенту требуется получить доступ к данным (например, GET Blob и т. д.), они автоматически расшифровываются перед возвратом пользователю.
Если шифрование отключено, новые операции записи не шифруются, а уже зашифрованные данные остаются в таком состоянии, пока не будут перезаписаны пользователем. Когда шифрование включено, операции записи в хранилище BLOB-объектов шифруются. Состояние данных не изменяется, когда пользователь переключается между включенным и отключенным шифрованием для учетной записи хранения.
Все ключи шифрования хранятся в зашифрованном виде и управляются корпорацией Майкрософт.
Обратите внимание, что в настоящее время ключами, используемыми для шифрования, управляет корпорация Майкрософт. Майкрософт создает исходные ключи и управляет их безопасным хранением, а также регулярной заменой в соответствии с внутренней политикой Майкрософт. В будущем клиенты получат возможность управлять своими ключами шифрования самостоятельно и им будет предоставлен план перехода с ключей, управляемых корпорацией Майкрософт, на ключи, управляемые клиентом.
Используйте шифрование на стороне клиента для хранения конфиденциальных данных в службе хранилища Azure
Клиентская библиотека службы хранилища Azure для пакета Nuget для .NET поддерживает шифрование данных в клиентских приложениях перед их отправкой в службу хранилища Azure и их расшифровку во время скачивания клиентом. Библиотека также поддерживает интеграцию с хранилищем ключей Azure для управления ключами учетной записи хранения. Вот краткое описание того, как работает шифрование на стороне клиента.
Пакет SDK клиента хранилища Azure создает ключ шифрования содержимого (CEK), который является одноразовым симметричным ключом.
Данные пользователей шифруются с помощью этого ключа CEK.
Ключ CEK, в свою очередь, шифруется с помощью ключа шифрования ключа KEK. Ключ шифрования ключей определяется идентификатором ключа и может быть парой асимметричных ключей или симметричным ключом. Вы можете управлять им локально или хранить его в хранилище ключей Azure. У самого клиента хранилища нет доступа к KEK. Он просто вызывает алгоритм шифрования ключа, предоставляемый хранилищем ключей. Пользователи могут при необходимости использовать настраиваемые поставщики для шифрования и расшифровки ключа.
Зашифрованные данные затем передаются в службу хранилища Azure. Просмотрите ссылки в разделе справочных сведений, чтобы получить низкоуровневые сведения о реализации.
Шифруйте конфиденциальные данные или личные данные, записываемые в локальное хранилище телефонов
Перед записью в локальную файловую систему персональные данные пользователя (электронная почта, номер телефона, имя, фамилия, параметры и т. д.), которые приложение записывает в файловую систему мобильного устройства, должны быть зашифрованы. Если приложение является корпоративным, рассмотрите возможности публикации приложения с помощью Windows Intune.
Пример
Вы можете настроить Intune со следующими политиками безопасности для защиты конфиденциальных данных:
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
Пример
Если приложение не является корпоративным, используйте предоставленное платформой хранилище ключей и цепочки ключей для хранения ключей шифрования и выполняйте тип операции шифрования, допустимый в файловой системе. Фрагмент кода ниже отображает получение ключа из цепочки ключей с помощью Xamarin.
protected static string EncryptionKey
{
get
{
if (String.IsNullOrEmpty(_Key))
{
var query = new SecRecord(SecKind.GenericPassword);
query.Service = NSBundle.MainBundle.BundleIdentifier;
query.Account = "UniqueID";
NSData uniqueId = SecKeyChain.QueryAsData(query);
if (uniqueId == null)
{
query.ValueData = NSData.FromString(System.Guid.NewGuid().ToString());
var err = SecKeyChain.Add(query);
_Key = query.ValueData.ToString();
}
else
{
_Key = uniqueId.ToString();
}
}
return _Key;
}
}
Маскируйте созданные двоичные файлы перед их распространением конечным пользователям
Созданные двоичные файлы (сборки в APK) должны быть замаскированы, чтобы остановить проведение инженерного анализа сборок. Для этой цели могут использоваться такие инструменты, как CryptoObfuscator.
Установите для параметра clientCredentialType значение Certificate или Windows.
Использование маркера имени пользователя с открытым паролем в незащищенном канале делает пароль уязвимым к атакам злоумышленников, которые могут получить доступ к сообщениям, передаваемым по протоколу SOAP. Поставщики служб, которые используют маркер имени пользователя, могут принять пароли, отправленные обычным текстом. В случае отправки открытых паролей через незащищенный канал учетные данные становятся уязвимыми к атакам злоумышленников, которые могут получить доступ к сообщениям, передаваемым по протоколу SOAP.
Пример
Ниже представлена конфигурация поставщика службы WCF, в которой используется маркер имени пользователя.
Безопасность доставки и сообщений не определена. Приложения, передающие сообщения без защиты доставки или сообщений, не могут гарантировать их целостность и конфиденциальность. Если для привязки безопасности WCF задано значение None, безопасность доставки и сообщений отключена.
Пример
В конфигурации ниже для режима безопасности задано значение None.
Ниже приведены пять режимов безопасности, доступных для всех привязок служб.
Нет. Отключает безопасность.
Transport. Применяет безопасность доставки для взаимной проверки подлинности и защиты сообщений.
Сообщение. Применяет безопасность сообщений для взаимной проверки подлинности и защиты сообщений.
Оба. Позволяет задать параметры безопасности доставки и сообщений (только для MSMQ).
TransportWithMessageCredential. Учетные данные передаются с сообщением, а безопасность сообщений и проверка подлинности сервера обеспечиваются на уровне доставки.
TransportCredentialOnly. Учетные данные клиента передаются на уровне доставки, безопасность сообщений не применяется. Применяйте безопасность доставки и сообщений для защиты целостности и конфиденциальности сообщений. Ниже представлен пример конфигурации, в соответствии с которым служба будет применять защиту доставки с использованием учетных данных сообщения.