Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом разделе представлена информация о передовой практике, которая поможет вам планировать и оценивать безопасность при разработке развертывания служб федерации Active Directory (AD FS). Этот раздел является отправной точкой для проверки и оценки рекомендаций, влияющих на общую безопасность использования AD FS. Сведения в этом разделе предназначены для дополнения и расширения существующего планирования безопасности и других рекомендаций по проектированию.
Основные рекомендации по безопасности для AD FS
Следующие основные рекомендации являются общими для всех установок AD FS, в которых требуется улучшить или расширить безопасность проектирования или развертывания:
Защита AD FS в качестве системы уровня 0
Поскольку AD FS является основной системой проверки подлинности, она должна рассматриваться как система уровня 0, как и другие системы удостоверений в вашей сети. Дополнительные сведения см. в разделе "Модель административного уровня Active Directory".
Используйте средство настройки безопасности, чтобы применять лучшие практики безопасности, специфичные для AD FS, к серверам федерации и прокси-компьютерам сервера федерации
Мастер настройки безопасности (SCW) — это средство, предварительно установленное на всех компьютерах Windows Server 2008, Windows Server 2008 R2 и Windows Server 2012. Его можно использовать для применения рекомендаций по обеспечению безопасности, которые помогут уменьшить область атаки для сервера на основе установленных ролей сервера.
При установке AD FS программа установки создает файлы расширения ролей, которые можно использовать с SCW для создания политики безопасности, которая будет применяться к конкретной роли AD FS-сервера (либо сервер федерации, либо прокси-сервер федерации), выбранной вами в процессе настройки.
Каждый установленный файл расширения роли представляет тип роли и подроли, для которого настроен каждый компьютер. Следующие файлы расширения ролей устанавливаются в каталог C:WindowsADFSScw:
Farm.xml
SQLFarm.xml
StandAlone.xml
Proxy.xml (этот файл присутствует, только если вы настроили компьютер в роли прокси-сервера федерации.)
Чтобы применить расширения ролей AD FS в SCW, выполните следующие действия.
Установите AD FS и выберите соответствующую роль сервера для этого компьютера. Дополнительные сведения см. в разделе "Установка службы прокси-роли службы федерации " в руководстве по развертыванию AD FS.
Зарегистрируйте соответствующий файл расширения роли с помощью средства командной строки Scwcmd. Дополнительные сведения об использовании этого средства см. в следующей таблице в роли, для которой настроен компьютер.
Убедитесь, что команда успешно завершена, проверив файл SCWRegister_log.xml, расположенный в каталоге WindowssecurityMsscwLogs.
Необходимо выполнить все эти действия на каждом сервере федерации или прокси-компьютере сервера федерации, к которому необходимо применить политики безопасности SCW на основе AD FS.
В следующей таблице объясняется, как зарегистрировать соответствующее расширение роли SCW на основе роли сервера AD FS, выбранной на компьютере, на котором установлено AD FS.
Роль сервера AD FS Используемая база данных конфигурации AD FS Введите следующую команду в командной строке: Автономный сервер федерации Внутренняя база данных Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwStandAlone.xml"Сервер федерации, присоединенный к ферме Внутренняя база данных Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwFarm.xml"Сервер федерации, присоединенный к ферме SQL Server scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwSQLFarm.xml"Прокси-сервер федерации N/A scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwProxy.xml"Дополнительные сведения о базах данных, которые можно использовать с AD FS, см. в разделе "Роль базы данных конфигурации AD FS".
Используйте обнаружение повторного использования токенов в ситуациях, когда безопасность является очень важным вопросом, например, при использовании киосков. Обнаружение воспроизведения токенов — это функция AD FS, которая гарантирует, что любая попытка воспроизвести запрос токена, сделанная в службе федерации, выявляется и отклоняется. Обнаружение воспроизведения токена включено по умолчанию. Он работает как для WS-Federation пассивного профиля, так и для профиля WebSSO языка разметки утверждений безопасности (SAML), гарантируя, что один и тот же токен никогда не используется более одного раза.
При запуске службы федерации начинается создание кэша любых запросов на токены, которые она обслуживает. Со временем, когда последующие запросы токена добавляются в кэш, способность службы федерации обнаруживать любые попытки повторного воспроизведения запроса токена увеличивается. Если вы отключите обнаружение воспроизведения маркеров, а затем снова включите его, помните, что служба федерации по-прежнему будет принимать маркеры некоторое время, даже если они были использованы ранее, пока кеш воспроизведения не восстановит свое содержимое. Дополнительные сведения см. в разделе "Роль базы данных конфигурации AD FS".
Используйте шифрование токенов, особенно если вы используете разрешение артефактов SAML.
Шифрование токенов настоятельно рекомендуется, чтобы повысить безопасность и защиту от потенциальных атак типа «человек посередине» (MITM), которые могут быть совершены против развертывания AD FS. Использование шифрования может оказать небольшое влияние на все, но в целом это не должно быть замечено, и во многих развертываниях преимущества для повышения безопасности превышают любые затраты с точки зрения производительности сервера.
Чтобы включить шифрование маркеров, сначала добавьте и настройте сертификат шифрования для доверяющих сторон. Сертификат шифрования можно настроить либо при создании отношения доверия с доверяющей стороной, либо позже. Чтобы добавить сертификат шифрования позже в существующее доверие проверяющей стороны, можно задать сертификат для использования на вкладке "Шифрование" в свойствах доверия при использовании оснастки AD FS. Чтобы указать сертификат для существующего доверия с помощью командлетов AD FS, используйте параметр EncryptionCertificate командлетов Set-ClaimsProviderTrust или Set-RelyingPartyTrust . Чтобы задать сертификат для службы федерации, используемый при расшифровке маркеров, используйте командлет Set-ADFSCertificate и укажите "
Token-Encryption" для параметра CertificateType . Включение и отключение шифрования для определенного доверия проверяющей стороны можно сделать с помощью параметра EncryptClaims командлета Set-RelyingPartyTrust .Использование расширенной защиты для проверки подлинности
Чтобы защитить развертывания, можно настроить и использовать расширенную защиту для проверки подлинности с помощью AD FS. Этот параметр задает уровень расширенной защиты для проверки подлинности, поддерживаемой сервером федерации.
Расширенная защита для проверки подлинности помогает защитить от атак типа «человек посередине» (MITM), в которых злоумышленник перехватывает учетные данные клиента и перенаправляет их на сервер. Защита от таких атак возможна с помощью маркера привязки канала (CBT), который может быть обязательным, разрешенным или не требуется сервером при установлении связи с клиентами.
Чтобы включить функцию расширенной защиты, используйте параметр ExtendedProtectionTokenCheck в командлете Set-ADFSProperties . Возможные значения этого параметра и уровень безопасности, предоставляемые значениями, описаны в следующей таблице.
Значение параметра Уровень безопасности Параметр защиты Require Сервер полностью защищён. Расширенная защита применяется и всегда требуется. Allow Сервер частично затверден. Расширенная защита применяется, когда участвующие в них системы обновлены для обеспечения поддержки. None Сервер уязвим. Расширенная защита не применяется. Если вы используете ведение журнала и трассировку, убедитесь в конфиденциальности любой конфиденциальной информации.
AD FS по умолчанию не предоставляет или не отслеживает персональные идентификационные данные (PII) непосредственно в контексте службы федерации или обычных операций. Если ведение журнала событий и журнала трассировки отладки включено в AD FS, однако в соответствии с настроенной вами политикой утверждений некоторые типы утверждений и их связанные значения могут содержать личные данные, которые могут быть зарегистрированы в событиях AD FS или журналах трассировки.
Поэтому настоятельно рекомендуется применять управление доступом к конфигурации AD FS и его файлам журнала. Если вы не хотите, чтобы эта информация была видна, следует отключить вход или отфильтровать любые личные данные или конфиденциальные данные в журналах, прежде чем предоставлять им общий доступ к ним другим пользователям.
Вам помогут следующие советы, чтобы предотвратить случайное раскрытие содержимого файла журнала.
Убедитесь, что журнал событий AD FS и файлы журналов трассировки защищены списками управления доступом (ACL), которые ограничивают доступ только к доверенным администраторам, которым требуется доступ к ним.
Не копируйте или архивируйте файлы журналов с помощью расширений файлов или путей, которые можно легко обслуживать с помощью веб-запроса. Например, расширение имени файла .xml не является безопасным выбором. Вы можете проверить руководство по администрированию служб IIS, чтобы просмотреть список расширений, которые можно обслуживать.
Если изменить путь к файлу журнала, обязательно укажите абсолютный путь к расположению файла журнала, который должен находиться за пределами общедоступного каталога виртуального корневого каталога веб-узла (vroot), чтобы предотвратить доступ к нему внешней стороной с помощью веб-браузера.
AD FS Extranet Soft Lockout (мягкая блокировка) и AD FS Extranet Smart Lockout Protection (умная защита блокировки)
В случае атаки в виде запросов проверки подлинности с недопустимыми (плохими) паролями, поступающими через прокси веб-приложения, блокировка экстрасети AD FS позволяет защитить пользователей от блокировки учетной записи AD FS. Помимо защиты пользователей от блокировки учетной записи AD FS, блокировка подсистемы AD FS для внешнего доступа также защищает от атак методом подбора паролей.
Сведения о мягкой блокировке экстрасети для AD FS в Windows Server 2012 R2 см. в статье AD FS Extranet Soft Lockout Protection.
См. сведения о Smart Lockout для экстрасети AD FS в Windows Server 2016 в статье AD FS Extranet Smart Lockout Protection.
Рекомендации по безопасности sql Server для AD FS
Следующие рекомендации по обеспечению безопасности относятся к использованию Microsoft SQL Server® или Внутренней базы данных Windows (WID), когда эти технологии баз данных используются для управления данными в проектировании и развертывании AD FS.
Note
Эти рекомендации предназначены для расширения, но не замены, рекомендации по безопасности продуктов SQL Server. Дополнительные сведения о планировании безопасной установки SQL Server см. в статьях "Вопросы безопасности" для безопасной установки SQL (https://go.microsoft.com/fwlink/?LinkID=139831).
Всегда развертывайте SQL Server за брандмауэром в физическо защищенной сетевой среде.
Установка SQL Server никогда не должна иметь доступ непосредственно к Интернету. Только компьютеры, находящиеся в центре обработки данных, должны иметь возможность получить доступ к установке SQL Server, поддерживающей AD FS. Дополнительные сведения см. в контрольном списке рекомендаций по безопасности (https://go.microsoft.com/fwlink/?LinkID=189229).
Запустите SQL Server под учетной записью службы вместо использования встроенных системных учетных записей службы по умолчанию.
По умолчанию SQL Server часто устанавливается и настраивается для использования одной из поддерживаемых встроенных системных учетных записей, например учетных записей LocalSystem или NetworkService. Чтобы повысить безопасность установки SQL Server для AD FS, везде, где возможно, используйте отдельную учетную запись службы для доступа к службе SQL Server и включите проверку подлинности Kerberos, зарегистрируя имя субъекта безопасности (SPN) этой учетной записи в развертывании Active Directory. Это обеспечивает взаимную проверку подлинности между клиентом и сервером. Без регистрации SPN отдельной служебной учетной записи SQL Server будет использовать NTLM для аутентификации на основе Windows, где проверяется только клиент.
Сведите к минимуму область поверхности SQL Server.
Включите только те конечные точки SQL Server, которые необходимы. По умолчанию SQL Server предоставляет одну встроенную конечную точку TCP, которая не может быть удалена. Для AD FS необходимо включить эту конечную точку TCP для проверки подлинности Kerberos. Чтобы просмотреть текущие конечные точки TCP, чтобы узнать, добавляются ли дополнительные пользовательские TCP-порты в установку SQL, можно использовать инструкцию запроса SELECT * FROM sys.tcp_endpoints в сеансе Transact-SQL (T-SQL). Дополнительные сведения о конфигурации конечной точки SQL Server см. в статье "Практическое руководство. Настройка ядра СУБД для прослушивания нескольких TCP-портов (https://go.microsoft.com/fwlink/?LinkID=189231).
Избегайте использования проверки подлинности на основе SQL.
Чтобы избежать необходимости передавать пароли как чистый текст по сети или хранить пароли в параметрах конфигурации, используйте проверку подлинности Windows только с установкой SQL Server. Проверка подлинности SQL Server — это устаревший режим проверки подлинности. Хранение учетных данных входа на языке структурированных запросов (SQL) (имена пользователей и пароли SQL) при использовании проверки подлинности SQL Server не рекомендуется. Дополнительные сведения см. в разделе "Режимы проверки подлинности " (https://go.microsoft.com/fwlink/?LinkID=189232).
Тщательно оцените потребность в дополнительной безопасности каналов в установке SQL.
Даже при использовании аутентификации Kerberos интерфейс поставщика поддержки безопасности SQL Server (SSPI) не обеспечивает защиту на уровне канала. Однако для установок, в которых серверы безопасно находятся в защищенной брандмауэром сети, шифрование обмена данными SQL может не потребоваться.
Хотя шифрование является ценным средством для обеспечения безопасности, оно не должно рассматриваться для всех данных или подключений. При принятии решения о том, следует ли реализовать шифрование, рассмотрите способ доступа пользователей к данным. Если пользователи получают доступ к данным через общедоступную сеть, шифрование данных может потребоваться для повышения безопасности. Однако если весь доступ к данным SQL с помощью AD FS включает в себя безопасную конфигурацию интрасети, шифрование может не потребоваться. Любое использование шифрования также должно включать стратегию обслуживания для паролей, ключей и сертификатов.
Если возникает проблема с тем, что любые данные SQL могут быть замечены или изменены по сети, используйте протокол безопасности Интернета (IPsec) или SSL, чтобы защитить подключения SQL. Однако это может негативно повлиять на производительность SQL Server, что может повлиять на производительность AD FS или ограничить их производительность в некоторых ситуациях. Например, производительность AD FS в выпуске маркеров может снизиться, если поиск атрибутов из хранилища атрибутов на основе SQL имеет решающее значение для выдачи маркеров. Вы можете более эффективно устранить угрозу подделки SQL, имея надежную конфигурацию безопасности периметра. Например, лучшее решение для защиты установки SQL Server заключается в том, чтобы гарантировать, что он остается недоступным для пользователей и компьютеров Интернета, и он остается доступным только пользователями или компьютерами в среде центра обработки данных.
Дополнительные сведения см. в разделе "Шифрование подключений к SQL Server " или "Шифрование SQL Server".
Настройте безопасный доступ, используя хранимые процедуры для выполнения всех SQL-подстановок AD FS по хранимым данным SQL.
Чтобы обеспечить более качественное обслуживание и изоляцию данных, можно создать хранимые процедуры для всех команд обращения к хранилищу атрибутов. Вы можете создать роль базы данных, которой затем предоставьте разрешение на выполнение хранимых процедур. Назначьте идентификатор службы Windows AD FS этой роли базы данных. Служба Windows AD FS не должна выполнять любую другую инструкцию SQL, кроме соответствующих хранимых процедур, которые используются для поиска атрибутов. Блокировка доступа к базе данных SQL Server таким образом снижает риск атаки на повышение привилегий.