Средства безопасности Windows Server 2003 реферат 2010 по информатике , Сочинения из Информатика

Скачай Средства безопасности Windows Server 2003 реферат 2010 по информатике и еще Сочинения в формате PDF Информатика только на Docsity! Федеральное агентство по образованию Государственное образовательное учреждение высшего профессионального образования Дальневосточный государственный технический университет (ДВПИ им. В.В. Куйбышева) Кафедра конструирования и производства радиоаппаратуры Реферат на тему: Средства безопасности Windows Server 2003 2010 Содержание Введение Общие понятия безопасности Шифрование с открытым ключом Обеспечение истинности открытых ключей Применение алгоритмов шифрования с открытым ключом в Windows Server 2003 Компоненты Windows Server 2003, обеспечивающие шифрование Политики безопасности Протокол аутентификации Kerberos Основные понятия Аутентификация Kerberos в доменах Active Directory Безопасность IP (IPSec) Достоинства IP Security Базовые механизмы и концепции Архитектура безопасности IP Разработка плана безопасности Администрирование безопасности IP Шифрующая файловая система EFS Архитектура EFS Система EFS и Windows Server 2003 Работа с EFS Сертификаты Использование сертификатов для обеспечения безопасности Центры сертификации Использование сертификатов в Интернете Хранилища сертификатов Запрос сертификата Установка центра сертификации предотвращение их получение несанкционированной стороной. Применяя хороший алгоритм шифрования, можно сделать практически невозможным, с точки зрения необходимых вычислительных и временных ресурсов, взлом защиты и получение открытого текста подбором ключа. Для быстрого выполнения подобного преобразования необходим расшифровывающий ключ. В традиционном шифровании с секретным ключом (secret key) (симметричное шифрование) зашифровывающий и расшифровывающий ключи совпадают. Стороны, обменивающиеся зашифрованными данными, должны знать общий секретный ключ. Процесс обмена информацией о секретном ключе представляет собой брешь в безопасности вычислительной системы. Фундаментальное отличие шифрования с открытым ключом (асимметричное шифрование) заключается в том, что зашифровывающий и расшифровывающий ключи не совпадают. Шифрование информации является односторонним процессом: открытые данные шифруются с помощью зашифровывающего ключа, однако с помощью того же ключа нельзя осуществить обратное преобразование и получить открытые данные. Для этого необходим расшифровывающий ключ, который связан с зашифровывающим ключом, но не совпадает с ним. Подобная технология шифрования предполагает, что каждый пользователь имеет в своем распоряжении пару ключей — открытый ключ (public key) и личный или закрытый ключ (private key). Свободно распространяя открытый ключ, вы даете возможность другим пользователям посылать вам зашифрованные данные, которые могут быть расшифрованы с помощью известного только вам личного ключа. Аналогично, с помощью личного ключа вы можете преобразовать данные так, чтобы другая сторона убедилась в том, что информация пришла именно от вас. Эта возможность применяется при работе с цифровыми или электронными подписями. Шифрование с открытым ключом имеет все возможности шифрования с закрытым ключом, но может проходить медленнее из-за необходимости генерировать два ключа. Однако этот метод безопаснее. Появление пары "личный ключ/открытый ключ" привело к возникновению нескольких новых технологий, наиболее важными из которых являются цифровые подписи, распределенная аутентификация, соглашение о секретном ключе, достигаемое с применением открытого ключа, и шифрование больших объемов данных без предварительного соглашения о секретном ключе. Существует несколько хорошо известных алгоритмов шифрования с открытым ключом. Некоторые из них, например RSA (Rivest-Shamir- Adelman) и шифрование с помощью эллиптической кривой (Elliptic Curve Criptography, ECC), являются алгоритмами общего употребления в том смысле, что они поддерживают все упомянутые выше операции. Другие алгоритмы поддерживают только некоторые операции. К ним относятся: алгоритм цифровой подписи (Digital Signature Algorithm, DSA), используемый только для работы с цифровыми подписями, и алгоритм Diffie- Hellman (D-H), применяемый только для соглашений о секретных ключах. Алгоритмы шифрования, используемые безопасностью IP (IP Security), подробнее описаны в данной главе в разд. "Безопасность IP". Ниже кратко рассмотрены основные области применения шифрования с открытым ключом. Цифровые (электронные) подписи Наверное, наиболее ярким проявлением всех преимуществ шифрования с открытым ключом является технология цифровых или электронных подписей. Она основана на математическом преобразовании, комбинирующем данные с секретным ключом таким образом, что: • только владелец секретного ключа может создать цифровую подпись; • любой пользователь, обладающий соответствующим открытым ключом, может проверить истинность цифровой подписи; • любая модификация подписанных данных (даже изменение одного бита) делает неверной цифровую подпись. Цифровые подписи гарантируют целостность (integrity) и подлинность (nonrepudiation) данных. Когда данные распространяются открытым текстом (без шифрования), получатели должны иметь возможность проверки, что данные в сообщении не были изменены. Добавление подписи не изменяет содержания данных: в этом случае генерируется цифровая подпись, которая может быть связана с данными или передаваться отдельно. Для выполнения этой операции клиентская программа создает дайджест, снимок данных, используя метод хэширования (например, MDS). Программа использует ваш личный ключ для шифрования дайджеста и подписывает данные или сообщение с помощью вашего сертификата, добавляя ваш открытый ключ. Соответствующая программа адресата сообщения использует открытый ключ для расшифровки дайджеста, затем использует тот же алгоритм хэширования для создания другого дайджеста данных. Данная программа затем сравнивает два дайджеста сообщений. Если они идентичны, то подтверждаются целостность и подлинность данных сообщения. Распределенная аутентификация Шифрование с открытым ключом применяется для создания надежной службы распределенной аутентификации, гарантирующей, что данные пришли получателю от истинного корреспондента. Соглашение о секретном ключе, достигаемое с помощью открытого ключа. Шифрование с открытым ключом позволяет двум сторонам, используя открытый ключ в незащищенной сети, договориться о секретном ключе. Обе стороны посылают друг другу половины секретного ключа, зашифрованного соответствующими открытыми ключами. Каждая из сторон получает ЦС предприятия, поддерживающих создание и отзыв сертификатов. Они интегрированы в Active Directory, где хранится информация о политике ЦС и их местоположении. Кроме того, с помощью Active Directory выполняется публикация информации о сертификатах и их отзыве. Средства работы с открытым ключом не заменяют существующих механизмов доверительных отношений между доменами и аутентификации, реализованных с помощью контроллеров доменов и центров распространения ключей Kerberos (Key Distribution Center, KDC). Напротив, данные средства взаимодействуют с этими службами, что позволяет приложениям безопасно передавать конфиденциальную информацию через Интернет и корпоративным глобальным каналам. Рисунок.1. Взаимосвязь средств Windows 2000 и Windows Server 2003, предназначенных для работы с открытым ключом Поддержка прикладных средств шифрования информации с открытым ключом включена в состав программного обеспечения всех операционных систем Windows. Основой архитектуры поддержки прикладных программ шифрования информации с открытым ключом является библиотека CryptoAPI. Она позволяет работать со всеми устанавливаемыми поставщиками услуг шифрования (Cryptographic Service Providers, CSP) через стандартный интерфейс. CSP могут быть реализованы на программном уровне или с помощью специального оборудования. Они поддерживают различные длины ключей и алгоритмы шифрования. Один из CSP поддерживает смарт-карты. Услугами служб шифрования пользуются службы управления сертификатами. Они соответствуют стандарту Х.509 v3 и позволяют организовывать принудительное хранение, службы подсчета и дешифрования. Кроме того, эти службы предназначены для работы с различными отраслевыми стандартами сообщений. В основном они поддерживают стандарты PKCS и разработанный в IETF (Internet Engineering Task Force) набор предварительных стандартов PKIX (Public Key Infrastructure, X.509). Остальные службы используют CryptoAPI для придания дополнительной функциональности прикладным программам. Защищенный канал (Secure Channel) поддерживает сетевую аутентификацию и шифрование в соответствии со стандартными протоколами TLS и SSL, обращение к которым может быть выполнено с помощью интерфейсов Microsoft Winlnet и SSPI. Служба Authenticode предназначена для проверки и подписи объектов и в основном используется при получении информации через Интернет. Политики безопасности Политики безопасности действуют в рамках сайта, домена или контейнера (подразделения, или организационной единицы, OU) и распространяются на группы, компьютеры и пользователей — т. е. на все объекты администрирования. Безопасность шифрования с открытым ключом является одним из аспектов общей политики безопасности Windows 2000/ Server 2003 и интегрирована в ее структуру. Это механизм, с помощью которого можно посредством объектов политики безопасности централизованно осуществлять настройку и управление глобальной политикой работы с открытым ключом. С помощью политики открытого ключа можно определять следующие аспекты безопасности Windows 2000/ Server 2003: • доверенные корни ЦС; • процесс регистрации и обновления сертификатов; • регистрация в системе с помощью смарт-карты. Протокол аутентификации Kerberos Протокол аутентификации Kerberos является основным механизмом аутентификации, используемым в среде Windows 2000/Server 2003. Этот протокол был разработан в Массачусетском технологическом институте (Massachusetts Institute of Technology, MIT) в начале 1980-х гг. Существует несколько версий протокола Kerberos. В среде Windows 2000/Server 2003 применяется пятая версия протокола Kerberos, спецификация которого определена в стандарте RFC 1510. Основные понятия Проблема аутентификации пользователя заключается в необходимости проверки того факта, что он является тем, за кого себя выдает. Наука знает множество различных способов проверки подлинности личности, которые упрощенно можно разделить на две группы: • проверка личности на факт соответствия некоторым индивидуальным характеристикам человека (проверка отпечатков пальцев, снимков радужки глаза, код ДНК и т. д.). Для применения этой группы методов аутентификации необходимо задействовать специальное оборудование; • проверка личности на факт знания некоторого секрета (пароли, цифровые комбинации и последовательности). В данном случае под секретом понимается некая символьная или цифровая последовательность, факт знания которой позволяет судить о подлинности пользователя. Указанные методы аутентификации наиболее просты в технологическом исполнении. Именно эти методы получили широкое распространение в современных операционных системах. Протокол аутентификации Kerberos также относится к этой группе методов. При реализации метода аутентификации, базирующегося на проверке факта знания некоторого секрета, необходимо решить следующие вопросы: • каким образом клиент будет получать информацию о секрете? секретных ключей. Программный код, обеспечивающий функционирование самого протокола и шифрование данных, находится в специальных библиотеках. Для того чтобы выполнять аутентификацию Kerberos для своих транзакций, приложения должны сделать несколько обращений к библиотекам Kerberos. Процесс аутентификации состоит из обмена необходимыми сообщениями с сервером аутентификации Kerberos. Протокол Kerberos состоит из нескольких субпротоколов (или протоколов обмена сообщениями). Существует два метода, которыми клиент может запросить у сервера Kerberos информацию, идентифицирующую определенный сервер. Первый способ предполагает, что клиент посылает AS простой текстовый запрос билета для конкретного сервера, а в ответ получает данные, зашифрованные с помощью своего секретного ключа. Как правило, в данном случае клиент посылает запрос на билет, позволяющий получить билет (Ticket Granting Ticket, TGT), который в дальнейшем используется для работы с выдающим билеты сервером (Ticket Granting Server, TGS). Второй способ предполагает, что клиент посылает TGT-билеты на TGS-сервер так же, как будто он обменивается информацией с другим сервером приложений, требующим аутентификации Kerberos. Информация, идентифицирующая сервер, может быть использована для идентификации партнеров по транзакции, что позволит гарантировать целостность передаваемых между ними сообщений или сохранить в секрете передаваемую информацию. Для идентификации партнеров по транзакции клиент посылает билет на сервер. Поскольку посылаемый билет "открыт" (некоторые его части зашифрованы, но они не помешают выполнить посылку копии) и может быть перехвачен и использован злоумышленником, для подтверждения истинности партнера, пославшего билет, передается дополнительная информация, называемая аутентификатором. Она зашифрована с помощью ключа сеанса и содержит отсчет времени, подтверждающий, что сообщение было сгенерировано недавно и не является копией оригинальной посылки. Шифрование аутентификатора с помощью ключа сеанса доказывает, что информация была передана истинным партнером по обмену данными. Поскольку, кроме запрашивающего партнера и сервера, никто не знает ключ сеанса (он никогда не посылается по сети в открытом виде), с его помощью можно полностью гарантировать истинность партнера. Целостность сообщений, которыми обмениваются партнеры, гарантируется с помощью ключа сеанса (передается в билете и содержится в информации идентификации партнера). Этот подход позволяет обнаружить атаки типа посылки злоумышленником перехваченной копии запроса и модификации потока данных. Это достигается генерированием и пересылкой контрольной суммы (хэш-функции) сообщения клиента, зашифрованной с помощью ключа сеанса. Безопасность и целостность сообщений, которыми обмениваются партнеры, может быть обеспечена шифрованием передаваемых данных с помощью ключа сеанса, передаваемого в билете и содержащегося в информации идентификации партнера. Описанная выше аутентификация требует доступа на чтение к базе данных Kerberos. Однако иногда записи базы данных могут быть модифицированы. Это происходит, например, при добавлении новых партнеров по обмену информацией или при изменении секретного ключа партнера. Изменения базы данных выполняются с помощью специального протокола обмена между клиентом и сервером Kerberos, применяющимся и при поддержке нескольких копий баз данных Kerberos. Для нормальной работы протокола Kerberos необходимо, чтобы каждый хост сети имел часы, которые были приблизительно синхронизированы с часами других хостов. Синхронизация необходима, чтобы было легче обнаружить факт передачи копии заранее перехваченного сообщения. Степень приблизительности синхронизации может быть установлена индивидуально для каждого сервера. Сам протокол синхронизации серверов сети должен быть защищен от атак злоумышленников. Аутентификация Kerberos в доменах Active Directory По мере роста и усложнения компьютерных сетей предприятия, построенных на основе систем Windows, становится необходимым применение протокола, обеспечивающего более совершенную и надежную аутентификацию пользователей при доступе к распределенным ресурсам. В операционных системах Windows 2000 для этих целей начат применяться протокол аутентификации Kerberos версии 5, входящий в систему безопасности доменов Windows 2000, тесно интегрированную с Active Directory. Реализация протокола Kerberos версии 5 в Windows 2000 основана на RFC 1510. Этот документ широко обсуждался и корректировался многими организациями, работающими в области создания и применения защищенных средств передачи информации по компьютерным сетям. Аутентификация Kerberos полностью отвечает требованиям к протоколам подобного назначения и позволяет создать высокопроизводительную и защищенную сеть предприятия. Программное обеспечение Kerberos, созданное Microsoft, поддерживает всех клиентов, удовлетворяющих RFC 1510. Однако полную поддержку сетей Windows 2000 осуществляет только клиент Kerberos, разработанный Microsoft, поскольку версия Kerberos Microsoft обладает рядом расширений. Системы Windows Server 2003 в полной мере используют все средства распределенной безопасности, внедренные в Windows 2000. Протокол Kerberos интегрирован в существующую модель распределенной безопасности Windows 2000/Server 2003. В этих системах используются расширения протокола Kerberos — так же, как и другие архитектуры безопасности, например ОСЕ и SESAME. Протокол Kerberos — один из протоколов безопасности, поддерживаемых Windows 2000/Server 2003. Кроме него, поддерживаются протоколы NTLM для совместимости с предыдущими версиями, SSL и стандарт IETF безопасности транспортного уровня. В качестве механизма безопасности применяется протокол защищенных переговоров (Simple Protected Negotiation, SPNEGO). Для обеспечения которому осуществляется с применением интерфейса поддержки поставщика безопасности (Security Support Provider Interface, SSPI). Поставщик безопасности Kerberos используется клиентом и сервером SMB (Server Message Block). Он также доступен для DCOM, авторизованного RPC и любого протокола, использующего SSPI для обеспечения безопасности информации, передаваемой по сети. SSPI — это интерфейс безопасности Win32, который существует в составе Windows NT, начиная с версии 3.5. Он также поддерживается в Windows 95/98. В SSPI применяются те же архитектурные концепции, что и в наборе программных вызовов общих служб безопасности (Generic Security Services API, GSS-API), соответствующих RFC 1964. SSPI позволяет освободить приложения от непосредственного взаимодействия с протоколами сетевой безопасности. В системах Windows 2000 и Windows Server 2003 реализован Центр распространения ключей Kerberos (Kerberos Key Distribution Center, KDC). На каждом контроллере домена помимо службы Active Directory имеется служба KDC, выполняющаяся вместе с Active Directory как процесс в привилегированном режиме. Оба процесса осуществляют управление жизненно важной информацией, включая пароли учетных записей пользователей. Active Directory выполняет автоматическую репликацию служебной информации на всех контроллерах домена. Поэтому создавать новые учетные записи пользователей, настраивать членство пользователей в группах или переустанавливать пароли можно на любом контроллере домена. Это означает, что в отличие от Windows NT 4,0, где изменить административную информацию можно было только на главном контроллере домена (Primary Domain Controller, PDC) с последующим обновлением доступных только для чтения реплик на резервных контроллерах домена (Backup Domain Controller, BDC), в доменах Active Directory можно изменять любую реплику каталога, хранящуюся на некотором контроллере домена. Клиенты и серверы используют протокол Kerberos для взаимной аутентификации. Запрос Kerberos содержит билет сеанса и аутентификатор, получаемый в КDС и позволяющий исключить возможность подмены билета сеанса. Поставщик безопасности Kerberos на стороне клиента интегрируется с локальным администратором безопасности, поддерживающим локальный кэш билетов. При инициализации клиентом контекста безопасности поставщик безопасности Kerberos считывает билет сеанса, соответствующий целевой службе, или запрашивает новый билет сеанса в КОС. Сообщение запроса Kerberos, созданного поставщиком безопасности Kerberos, соответствует форматам маркера механизма GSS KerbS, описанным в RFC 1964. Клиенты могут аутентифицироваться для любой службы домена или доверенного владения, поддерживающего механизм GSS. Поставщик безопасности Kerberos может воспринять запрос Kerberos, который сгенерирован любым клиентом, поддерживающим форматы маркера в стандарте GSS, RFC 1964. Такой уровень взаимодействия позволяет осуществлять поддержку традиционной аутентификации Kerberos, основанной на именах, в многоплатфорных средах. Для имперсонализации и управления доступом в рамках принятой модели распределенной безопасности системным службам достаточно данных авторизации, находящихся в билете сеанса. Протокол Kerberos и авторизация Windows Server 2003 Имперсонализация Windows Server 2003 требует, чтобы локальный администратор безопасности (LSA) сервера мог безопасно получать SID пользователя и список идентификаторов безопасности членов групп. Идентификаторы безопасности генерируются системой безопасности домена и используются в LSA при создании маркеров доступа для имперсонализации. После создания соединения связанный с ним поток имперсонализирует зарегистрировавшегося пользователя, после чего операционная система сравнивает маркер доступа клиента с ACL объекта, к которому пользователь пытается получить доступ. При аутентификации NTLM идентификаторы безопасности пользователя и группы передаются с помощью защищенного канала Net Logon прямо с контроллера домена или любого доверенного домена. При использовании протокола Kerberos идентификаторы безопасности пользователей и групп передаются в составе данных авторизации билета сеанса Kerberos. Данные авторизации, находящиеся в билете Kerberos, полученном из КDС, содержат список идентификаторов безопасности пользователей и идентификаторов, определяющих членство в группах. Локальному администратору безопасности данные авторизации нужны для поддержки имперсонализации поставщика безопасности Kerberos. Протокол Kerberos позволяет обращаться к данным авторизации билета Kerberos, которые определяются приложением. Они полностью соответствуют RFC 1510. Кроме того, их структура преобразована для уменьшения проблем, возникающих при совместной работе с другими операционными системами. При первоначальной регистрации пользователя в домене КDС помещает в TGT данные авторизации, включающие идентификаторы безопасности пользователей или групп домена учетных записей (account domain). Членство в группах также определяется при первоначальной регистрации. После этого КDС копирует данные авторизации из ТОТ в билеты сеанса, применяемые для аутентификации серверов приложений. В сети с несколькими доменами КОС, управляющий запросами на получение билетов сеанса, может добавлять в данные авторизации дополнительные группы целевого домена, к которым может принадлежать пользователь. По мере развития ОС Windows Server 2003 формат данных авторизации может изменяться. Но в любом случае эти данные будут содержать список идентификаторов безопасности, предназначенных для поддержки аутентификации Kerberos в много платформенных системах, а также подпись, обеспечивающую целостность данных и устанавливаемую КОС. Безопасность IP (IPSec) Средства безопасности протокола IP позволяют управлять защитой всего IP-трафика от источника информации до ее получателя. Возможности технологии IP Security Management (Управление безопасностью IP) в Windows Server 2003 позволяют назначать и применять политику безопасности IP, которая гарантирует защищенный обмен информацией для всей сети. Механизм безопасности IP представляет собой прозрачную для пользователя реализацию протокола безопасности IP (IP Security, IPSec), причем администрирование безопасности централизовано и совмещает гарантии безопасного обмена информацией с легкостью применения. Потребность в защите сетей, основанных на протоколе IP, достаточно велика и растет с каждым годом. В настоящее время в тесно взаимосвязанном деловом мире сетей Интернет, интранет, экстранет (extranet — корпоративная сеть, части которой связаны через открытые сети, например, через Интернет), филиалов и удаленного доступа по сетям передается важная информация, конфиденциальность которой нельзя нарушать. Одним из основных требований, предъявляемых к сети со стороны сетевых администраторов и прочих профессионалов, обслуживающих и использующих сети, является требование гарантии, что этот трафик будет защищен от: • доступа субъектов, не имеющих на это прав; • перехвата, просмотра или копирования; • модификации данных во время пути по сети. Эти проблемы характеризуются такими показателями, как целостность данных, конфиденциальность и подлинность. Кроме того, защита от повторного использования (replay protection) предотвращает принятие повторно посланного пакета. Примечание Реализация безопасности IP в Windows Server 2003 основана на стандартах RFC, разработанных консорциумом Internet Engineering Task Force (IETF), рабочей группой IP Security (IPSEC). Достоинства IP Security Сетевые атаки могут привести к неработоспособности системы, считыванию конфиденциальных данных и другим дорогостоящим нарушениям. Для защиты информации требуются методы "сильного" шифрования и сертификации, основанные на криптографических алгоритмах. Однако высокий уровень безопасности не должен ухудшать производительность труда пользователей или увеличивать затраты на администрирование. IP Security в системах Windows 2000 и Windows Server 2003 обеспечивает следующие преимущества, которые помогают достичь высокого уровня безопасности взаимодействия при низких затратах. • Централизованное администрирование политикой безопасности, что уменьшает затраты на административные издержки. Политика IPSec может быть создана и назначена на уровне домена (при этом она хранится в Active Directory), что устраняет необходимость индивидуального конфигурирования каждого компьютера. Однако, если компьютер имеет уникальные требования, или это автономный компьютер, политика может быть назначена непосредственно. • Прозрачность безопасности IP для пользователей и прикладных программ. Не нужно иметь отдельные программные средства безопасности для каждого протокола в стеке TCP/IP, поскольку приложения, использующие TCP/IP, передают данные уровню протокола IP, где они шифруются. Установленная и настроенная служба IPSec прозрачна для пользователя и не требует обучения. • Гибкость конфигурирования политики безопасности, которая помогает решать задачи в различных конфигурациях. Внутри каждой политики можно настроить службы безопасности, чтобы обеспечить потребности на всех уровнях, начиная с уровня индивидуального пользователя и заканчивая уровнем серверов или предприятия. Политику можно сконфигурировать в соответствии с экспортными правилами и ограничениями. • Конфиденциальные службы, предотвращающие попытки несанкционированного доступа к важным данным во время передачи этих данных между поддерживающими связь сторонами. • Туннелирование. Данные могут быть посланы через безопасные туннели для обмена информацией в Интернете и корпоративных сетях. • Усиленная служба аутентификации, которая предотвращает перехват данных путем подмены идентификаторов. • Ключи большой длины и динамический повторный обмен ключами в течение текущих сеансов связи, что помогает защитить соединение от атак. • Безопасная связь от начала до конца для частных пользователей сети внутри одного и того же домена или через любой доверенный (trusted) домен внутри корпоративной сети. • Безопасная связь между пользователями в любом домене корпоративной сети, основанной на протоколе IP. • Отраслевой стандарт IPSec открыт для реализации других технологий шифрования IP, что позволяет взаимодействовать с другими платформами и продуктами. • Сертификаты с -открытым ключом и поддержка ключей pre- shared (заранее известных). Это требуется для разрешения установления безопасной связи с компьютерами, которые не являются частью доверенного домена. • IPSec работает во взаимодействии с другими механизмами защиты, сетевыми протоколами и базовыми механизмами безопасности операционной системы. • Поддерживается шифрование сообщений RSVP для реализации служб QoS и ACS, т. е. IPSec не мешает использовать все преимущества приоритетного управления шириной полосы пропускания, обеспечиваемые этими службами. можно включить аппаратные средства шифрования в сетевой адаптер. Адаптер, обеспечивающий перегрузку IPSec на аппаратные средства, скоро представят на рынке несколько поставщиков аппаратного обеспечения. Базовые механизмы и концепции Алгоритмы шифрования Для защиты данных применяются математические алгоритмы шифрования. Безопасность IP в Windows 2000/Server 2003 использует стандартные криптографические алгоритмы, перечисленные ниже. • Методика Diffie-Hellman (D-H). Алгоритм шифрования с открытым ключом (названный по имени изобретателей — Diffie и Hellman), который позволяет двум поддерживающим связь объектам договариваться об общедоступном ключе без требования шифрования во время порождения ключа. Процесс начинают два объекта, обменивающиеся общедоступной информацией. Затем каждый объект объединяет общую информацию другой стороны со своей собственной секретной информацией, чтобы сгенерировать секретное общедоступное значение. • Код аутентификации хэшированного сообщения (НМАС, Hash Message Authentication Code). НМАС — алгоритм шифрования с закрытым ключом, обеспечивающий целостность сообщений, установление их подлинности и предотвращение повторного использования. Установление подлинности, использующее функции хэширования (перемешивания), объединено с методом закрытого ключа. Хэшированное значение, известное также как дайджест (digest), или выборка сообщений, используется для создания и проверки цифровой подписи. Это уникальное значение намного меньше, чем первоначальное сообщение, созданное из цифровой копии кадра данных. Если передаваемое сообщение изменилось по пути следования, то хэшированное значение будет отличаться от оригинала, а IP-пакет будет отброшен. • HMAC-MD5. Дайджест сообщений-5 (MD5, Message Digest) — функция хэширования, которая порождает 128-разрядное значение, являющееся подписью данного блока данных. Эта подпись служит для установления подлинности, целостности и предотвращения повторного использования. • HMAC-SHA. Безопасный алгоритм хэширования (SHA, Secure Hash Algorithm) — еще одна функция хэширования, которая порождает 160- разрядное значение подписи, необходимое для установления подлинности, целостности и предотвращения повторного использования. • DES-CBC. Стандарт шифрования данных (Data Encryption Standard, DES) — формирование цепочки шифрованных блоков (Cipher Block Chaining, CBC) — алгоритм шифрования с закрытым ключом, обеспечивающий конфиденциальность. Генерируется случайное число, которое используется совместно с закрытым ключом для шифрования данных. Ключи Для обеспечения безопасности данных в криптографии совместно с алгоритмами используются ключи. Ключ — это некоторое значение, применяемое для шифрования или дешифрования информации. Для шифрования в системах безопасности могут использоваться как закрытые, так и открытые ключи. Даже если алгоритм известен, без ключа данные нельзя просмотреть или изменить. Безопасность IP в Windows Server 2003 использует ключи большой длины, чтобы обеспечить повышенную безопасность. Если длину ключа увеличить на один бит, число возможных комбинаций удваивается. Безопасность IP в Windows Server 2003 также применяет динамическое обновление ключей; это означает, что после определенного интервала для продолжения обмена данными генерируется новый ключ. Такое решение позволяет защититься от злоумышленника, который получил доступ к части информации во время ее передачи. Протоколы безопасности На базе протоколов безопасности реализуются различные службы, обеспечивающие безопасный обмен информацией по сети. Windows 2000 и Windows Server 2003 используют протоколы безопасности, описанные далее. • Протокол ассоциаций безопасности и управления ключами Интернет (ISAKMP, Internet Security Association and Key Management Protocol) Прежде чем IP-пакеты будут переданы от одного компьютера другому, должна быть установлена ассоциация, или сопоставление, безопасности (Security Association, SA). SA — набор параметров, который определяет необходимые для защищенной связи услуги и механизмы, типы ключей для безопасных протоколов. SA должна существовать между двумя поддерживающими связь сторонами, использующими безопасность IP. ISAKMP определяет основу для поддержки и установления ассоциаций безопасности. Протокол ISAKMP не связан ни с одним конкретным алгоритмом, методом порождения ключей или протоколом безопасности. • Oakley. Протокол определения ключей, который использует алгоритм обмена ключами Diffie-Hellman (D-H). Oakley генерирует ключи, необходимые для безопасного обмена информацией. • Заголовок аутентификации IP (АН, Authentication Header). АН обеспечивает целостность, установление подлинности и защиту от повторного использования. Также при помощи АН поддерживается конфиденциальность. АН основан на некотором алгоритме вычисления ключевого кэшированного значения сообщения (НМАС) для каждого IP- пакета. Для поддержки обмена информацией с использованием безопасности IP на каждом компьютере с Windows Server 2003 устанавливаются локальные службы и драйверы. • Служба агента политики безопасности (Policy Agent Service) Агент политики — локальный, резидентный агент. Он отыскивает политику безопасности IP в Active Directory во время инициализации системы. Затем он передает информацию о политике сетевому драйверу безопасности IP (IPSec-драйверу) и службе ISAKMP/Oakley. Агент политики не хранит политику безопасности локально, а находит ее в Active Directory (рис. 3). Рисунок 3. Функционирование агента политики безопасности • Служба управления ключами ISAKMP/Oakley Это локальный, резидентный агент, который получает политику безопасности от агента политики. При использовании политики безопасности служба ISAKMP устанавливает ассоциацию безопасности (SA) с компьютером-получателем. Тождество поддерживающих связь сторон опознается с помощью центра распределения ключей Kerberos. В заключение служба ISAKMP посылает SA и информацию о ключе драйверу IPSec. Служба ISAKMP/Oakley запускается агентом политики. • Драйвер безопасности IP (IPSec-драйвер) Это локальный, резидентный агент, который просматривает все IP- пакеты на соответствие фильтру IP. Если он находит соответствие, то задерживает пакеты в очереди, в то время как служба ISAKMP/Oakley генерирует необходимую SA и ключ, чтобы защитить обмен информацией. Агент, получив эту информацию от службы ISAKMP, шифрует IP-пакеты и посылает их компьютеру-адресату (рис. 4). Драйвер IPSec запускается агентом политики. Рисунок 4. Функционирование драйвера IPSec Все три перечисленные компонента установлены в Windows Server 2003 по умолчанию и запускаются автоматически. Примечание Каждый контроллер домена содержит Центр распространения ключей Kerberos (Kerberos Distribution Center, KDC) для установления подлинности, который конфигурируется сетевым администратором. Протокол Kerberos служит третьим доверенным лицом, которое проверяет подлинность поддерживающей связь стороны. Безопасность IP в Windows Server 2003 использует Kerberos для идентификации компьютеров. Рассмотрим пример, в котором пользователь Компьютера А (Пользователь 1) посылает данные пользователю Компьютера В (Пользователю 2). Безопасность IP установлена на обоих компьютерах. Рисунок 5. Пример реализации безопасности IP безопасности Legal могла бы иметь описанные ниже политику переговоров и IP-фильтры, связанные с ней. 2. Создать две политики переговоров и связать их с политикой безопасности Legal: • первую политику переговоров, Legal NP 1, настроенную на службы и обеспечивающую конфиденциальность для взаимодействия пользователей юридического отдела с пользователями других отделов ("передаваемые данные будут конфиденциальны, подлинны и не модифицированы" — парадигма протокола безопасности ESP); • вторую политику переговоров, Legal NP 2, настроенную на службы и обеспечивающую только установление подлинности и защиту от изменений, когда пользователи юридического отдела общаются друг с другом ("передаваемые данные будут подлинны и не модифицированы" — парадигма протокола безопасности АН). 3. Создать два IP-фильтра и связать каждый с политикой переговоров. Пользователи в юридическом отделе находятся в сети 157.55.0.0 с маской подсети 255.255.0.0. Пользователи других отделов находятся в сети 147.20.0.0 с маской подсети 255.255.0.0. Первый IP-фильтр, Legal IP Filter 1, предназначен для пользователей в юридическом отделе, которые связываются с пользователями других отделов. Он будет связан с политикой переговоров Legal NP 1. Администратор устанавливает свойства фильтра в соответствии со следующими значениями: • заданный IP-адрес для источника — 157.55.0.0. Этот адрес будет соответствовать любому адресу IP в сети юридического отдела, т. к. он является IP-адресом подсети; • заданный IP-адрес для получателя — 147.20.0.0; • поскольку план безопасности компании обусловливает безопасность всех данных, посланных при помощи протокола IP, тип протокола — любой (Any). Пользователи юридического отдела, поддерживающие связь с другими пользователями внутри отдела, используют второй IP-фильтр, Legal IP Filter 2. Он связан с политикой переговоров, Legal NP 2, а параметры фильтра установлены в соответствии со следующими значениями: • заданный IP-адрес для источника — 157.55.0.0; • заданный IP-адрес для получателя — 157.55.0.0; • тип протокола — любой (Any). Когда пользователь в юридическом отделе посылает информацию любому другому пользователю, адреса источника и получателя IP-пакетов сверяются с IP-фильтрами политики безопасности Legal. Если адреса соответствуют одному из фильтров, связанная политика переговоров определяет уровень IP-безопасности для поддержания взаимодействия. Например, если пользователь в юридическом отделе с адресом IP 157.55.2.1 посылает данные пользователю с адресом 147.20.4.5, это соответствует Legal IP Filter 1. Это означает, что связь будет организована на уровне безопасности, определенном политикой переговоров Legal NP 1, которая обеспечивает установление подлинности, защиту от изменений и конфиденциальность связи. Администрирование безопасности IP Управление безопасностью IP в Windows Server 2003 позволяет администраторам создавать настраиваемую политику безопасности с уникальной политикой переговоров и IP-фильтрами. Не требуются никакие изменения прикладных программ. Также не требуется обучать конечных пользователей, поскольку администраторы конфигурируют всю политику безопасности в службе Active Directory, а действия шифрования прозрачны на уровне конечного пользователя. Рисунок 6. Управление политиками IP Security в окне оснастки Default Domain Policy Можно конфигурировать безопасность IP, используя оснастки Local Security Settings (Локальные параметры безопасности) (на локальном компьютере) или Default Domain Policy (рис. 6) (для домена). Также можно подключить к консоли ММС изолированную оснастку IP Security Policy Management (Управление политикой безопасности IP) и настроить ее для компьютера или домена. Шифрующая файловая система EFS На персональном компьютере операционную систему можно загрузить не с жесткого, а с гибкого диска. Это позволяет обойти проблемы, связанные с отказом жесткого диска и разрушением загрузочных разделов. Однако, поскольку с помощью гибкого диска можно загружать различные операционные системы, любой пользователь, получивший физический доступ к компьютеру, может обойти встроенную систему управления доступом файловой системы NTFS и с помощью определенных инструментов прочесть информацию жесткого диска. Единственно надежный способ защиты информации — это шифрующая файловая система. На рынке программного обеспечения существует целый набор продуктов, обеспечивающих шифрование данных с помощью образованного от пароля ключа на уровне приложений. Однако такой подход имеет ряд ограничений. • Ручное шифрование и дешифрование. Службы шифрования большинства продуктов непрозрачны для пользователей. Пользователю приходится расшифровывать файл перед каждым его использованием, а затем опять зашифровывать. Если пользователь забывает зашифровать файл по окончании работы с ним, информация остается незащищенной. Поскольку каждый раз необходимо указывать, какой файл должен быть зашифрован (и Рисунок 7. Архитектура EFS • Служба EFS. Служба EFS (EFS Service) является частью системы безопасности операционной системы. Для обмена данными с драйвером EFS она использует порт связи LPC, существующий между Локальным администратором безопасности (Local Security Authority, LSA) и монитором безопасности, работающим в привилегированном режиме. В режиме пользователя для создания ключей шифрования файлов и генерирования данных для DDF и DRF служба EFS использует CryptoAPI. Она также поддерживает набор API для Win32. • Набор API для Win32. Этот набор интерфейсов прикладного программирования позволяет выполнять шифрование файлов, дешифрование и восстановление зашифрованных файлов, а также их импорт и экспорт (без предварительного дешифрования). Эти API поддерживаются стандартным системным модулем DLL — advapi32.dll. Технологии шифрования EFS Данный раздел поможет вам понять, как шифруется информация и почему перед использованием EFS обязательно экспортировать сертификаты (вместе с личными ключами) пользователей и агентов восстановления данных. Очень часто непонимание этих моментов приводит к тому, что зашифрованные данные безвозвратно теряются по вине пользователей. EFS основана на шифровании с открытым ключом и использует все возможности архитектуры CryptoAPI. Каждый файл шифруется с помощью случайно сгенерированного ключа, зависящего от пары открытого (public) и личного, закрытого (private), ключей пользователя. Подобный подход в значительной степени затрудняет осуществление большого набора атак, основанных на криптоанализе. При криптозащите файлов может быть применен любой ачгоритм симметричного шифрования. EFS позволяет осуществлять шифрование и дешифрование файлов, находящихся на удаленных файловых серверах. Примечание В данном случае EFS может работать только с файлами, находящимися на диске. Шифрующая файловая система не осуществляет криптозащиту данных, передаваемых по сети. Для шифрования передаваемой информации следует применять специальные сетевые протоколы, например SSL/PCT. В EFS для шифрования и дешифрования информации используются открытые ключи. Данные зашифровываются с помощью симметричного алгоритма с применением Ключа шифрования фаша (File Encryption Key, FEK). FEK — это сгенерированный случайным образом ключ, имеющий определенную длину. В свою очередь, FEK шифруется с помощью одного или нескольких открытых ключей, предназначенных для криптозашиты ключа. В этом случае создается список зашифрованных ключей FEK, что позволяет организовать доступ к файлу со стороны нескольких пользователей. Для шифрования набора FEK используется открытая часть пары ключей каждого пользователя. Список зашифрованных ключей FEK хранится вместе с зашифрованным файлом в специальном атрибуте EFS, называемом Полем дешифрования данных (Data Decryption Field, DDF). Информация, требуемая для дешифрования, привязывается к самому файлу. Секретная часть ключа пользователя используется при дешифровании FEK. Она хранится в безопасном месте, например на смарт-карте или другом устройстве, обладающем высокой степенью защищенности. FEK применяется для создания ключей восстановления. Для этого FEK шифруется с помощью одного или нескольких открытых мючей восстановления. Список FEK, зашифрованных для целей восстановления, хранится вместе с зашифрованным файлом в специальном атрибуте EFS, называемом Полем восстановления данных (Data Recovery Field, DRF). Благодаря существованию набора зашифрованных ключей FEK агенты восстановления данных могут дешифровать файл. Для шифрования ключа FEK в поле DRF необходима только общая часть пары ключей восстановления, ее присутствие в системе необходимо в любой момент времени для нормального функционирования файловой системы. Сама процедура восстановления выполняется довольно редко, когда пользователь увольняется из организации или забывает секретную часть ключа. Поэтому агенты восстановления могут хранить секретную часть ключей восстановления в безопасном месте, например на смарт-картах или других хорошо защищенных устройствах. Система EFS и Windows Server 2003 EPS тесно взаимодействует с NTFS 5.0. Временные файлы, создаваемые приложениями, наследуют атрибуты оригинальных файлов (если файлы находятся в разделе NTFS). Вместе с файлом шифруются также и его временные копии. EFS находится в ядре Windows Server 2003 и использует для хранения ключей специальный пул, не выгружаемый на жесткий диск. Поэтому ключи никогда не попадают в файл подкачки. В Windows Server 2003 файловая система EFS имеет некоторые новые возможности: • с зашифрованными файлами могут работать несколько пользователей. Пользователь, зашифровавший файл, может разрешить другим локальным и доменным пользователям (на компьютерах под управлением Windows 2000 и Windows XP) работать с этим файлом; • можно шифровать автономные папки и файлы (offline folders); • агент восстановления (recovery agent) по умолчанию не используется; • стандартный алгоритм шифрования — Advanced Encryption Standard, AES (Rijndael) (256 бит). Алгоритм DESX, используемый по умолчанию системой EFS в Windows 2000 и Windows XP Professional, не может применяться для шифрования файлов в Windows Server 2003; Работа с EFS Самая серьезная и, к сожалению, нередко встречающаяся ошибка при работе с EFS заключается в том, что пользователи шифруют данные на локальном компьютере (или компьютере — члене группы), а затем переустанавливают операционную систему. В этом случае данные будут безвозвратно утеряны, т. к. доступ к ним имели только два пользователя той системы, в которой данные были зашифрованы: пользователь, выполнивший эту операцию, и агент восстановления. Ошибка состоит в том, что для расшифровки данных необходимо предъявить сертификаты одного из названных пользователей, а для этого соответствующие сертификаты нужно было экспортировать и сохранить. EFS располагает встроенными средствами восстановления зашифрованных данных в условиях, когда неизвестен личный ключ пользователя. Пользователи, которые могут восстанавливать зашифрованные данные в условиях утраты личного ключа, называются агентами восстановления данных. Агенты восстановления данных обладают сертификатом (Х.509 v.3) на восстановление файлов и личным ключом, с помощью которых выполняется операция восстановления зашифрованных файлов. Используя ключ восстановления, можно получить только сгенерированный случайным образом ключ, с помощью которого был зашифрован конкретный файл. Поэтому агенту восстановления не может случайно стать доступной другая конфиденциальная информация. Средства восстановления данных предназначены для применения в разнообразных конфигурациях вычислительных сред. Параметры процедуры восстановления зашифрованных данных в условиях утраты личного ключа задаются политикой восстановления. Она представляет собой одну из политик открытого ключа (public key policy). Политика восстановления определяется только в домене Windows Server 2003. Администратор домена одновременно является и агентом восстановления с соответствующими полномочиями. Могут быть добавлены и другие агенты. Это делается с помощью оснастки Group Policy Object Editor (Групповая политика), в окне которой нужно выбрать узел Security Settings | Public Key Policies | Encrypting File System. В контекстном меню этого узла имеются команды, позволяющие управлять агентами и политиками восстановления. Политика восстановления может быть задана и на одиночном компьютере. Внимание Политики восстановления в Windows Server 2003 работают иначе, чем в Windows 2000. По умолчанию на компьютерах под управлением Windows Server 2003 агенты восстановления не создаются и политика восстановления не препятствует работе EFS. Это означает, что восстановить зашифрованную информацию могут только те пользователи, которые ее зашифровали. Создание агента восстановления Описываемая ниже процедура должна выполняться на автономном компьютере, на котором планируется использование системы EFS. Сначала необходимо создать сертификат агента восстановления (лучше использовать административную учетную запись, хотя, строго говоря, это не обязательно), импортировать его, а затем назначить политику восстановления. Чтобы создать сертификат агента восстановления: 1. Войдите в систему как администратор. 2. В окне консоли введите команду cipher /R: имя Файла — без расширения. 3. Введите и подтвердите пароль, защищающий личный ключ. В текущем каталоге будут созданы два файла: с расширением сer (содержит только сгенерированный ключ) и с расширением pfx (содержит и ключ, и сертификат агента восстановления). Для большей сохранности перепишите файлы на дискету. Для импорта сертификата, с помощью которого можно восстанавливать индивидуальные файлы пользователей: 1. Зарегистрируйтесь в системе как администратор. 2. Запустите оснастку Certificates, откройте узел Personal. 3. Импортируйте созданный РЕХ-файл. Чтобы определить политику агента восстановления для любых операций шифрования: 1. Запустите оснастку Local Security Settings. 2. Выберите узел Public Key Policies | Encrypting File System (Политики открытого ключа | Файловая система EPS). 3. В контекстном меню выполните команду Add Data Recovery Agent (Добавить агента восстановления данных). 4. В окне мастера Add Recovery Agent Wizard (Мастер добавления агента восстановления) нажмите кнопку Browse Folders (Обзор папок) и выберите местоположение созданного ранее файла сертификата с расширением сеr. (Имя пользователя будет неизвестно, поскольку оно не хранится в файле — это нормальная ситуация.) 5. Нажмите кнопку Next (Далее) и на следующей странице мастера — Finish (Готово). Сертификат будет импортирован и его владелец станет агентом восстановления на данном компьютере. Обратите внимание на то, что в столбце Intended Purposes (Назначение) импортированного сертификата указано File Recovery (Восстановление файлов). Теперь можно использовать шифрование информации, не опасаясь потери "ключа" к ней. Шифрование файлов и каталогов Шифрование файлов для совместного использования Системы Windows XP и Windows Server 2003, в отличие от Windows 2000, поддерживают совместный доступ к зашифрованным файлам, расположенным на общих сетевых ресурсах в домене на базе Active Directory или на локальных дисках. Дополнительные разрешения нужно давать для каждого файла индивидуально. После того как владелец-создатель зашифровал файл, он может снова открыть окно Advanced Attributes (Дополнительные атрибуты) и нажать кнопку Details (Подробно). Появится окно, аналогичное показанному на рис. 8 (для изолированного компьютера картина будет аналогичной). В приведенном примере видно, что к файлу помимо агента восстановления имеют доступ еще два пользователя. Рисунок 8. В этом окне перечислены все пользователи, имеющие доступ к зашифрованному файлу Рисунок 9. Данное окно позволяет выбрать пользователя и просмотреть его сертификат Примечание Зашифровав файл или папку и открыв заново окно Encryption Details (Подробности шифрования), вы можете легко проверить, определен ли в вашей системе агент восстановления. Теперь можно нажать кнопку Add (Добавить) и в окне Select User (Выбор пользователя) (рис. 9) указать, какие пользователи смогут также работать с зашифрованным файлом. Окно Select User позволяет просмотреть имеющиеся сертификаты пользователей и искать пользователей в каталоге Active Directory. Дешифрование файлов и каталогов Чтобы дешифровать файл или каталог: 1. На вкладке Sharing окна свойств соответствующего объекта нажмите кнопку Advanced. 2. В открывшемся диалоговом окне в группе Compress or Encrypt attributes сбросьте флажок Encrypt contents to secure data. Копирование, перемещение, переименование и уничтожение зашифрованных файлов и папок Операции копирования, перемещения, переименования и уничтожения зашифрованных файлов и папок выполняются точно так же, как и с незашифрованными объектами. Однако следует помнить, что пункт назначения зашифрованной информации должен поддерживать шифрование (должен иметь файловую систему NTFS 5.0). В противном случае при копировании данные будут расшифрованы, и копия будет содержать открытую информацию. Архивация зашифрованных файлов Резервную копию зашифрованного файла можно создать с помощью простого копирования его на другой жесткий диск или с использованием утилиты архивации. Однако, как сказано в предыдущем разделе, простое копирование, например, на дискету или оптический диск может привести к тому, что резервная копия будет содержать открытые данные. То есть, если скопировать зашифрованный файл в FAT-раздел или на дискету, копия будет не зашифрована и, следовательно, доступна для чтения любому пользователю. Специализированная операция архивации не требует для ее выполнения доступа к открытым ключам пользователя — только к архивируемой информации. Поэтому для обеспечения безопасности конфиденциальных данных при создании резервных копий рекомендуется применять специальные утилиты архивации. Для этих целей предназначена стандартная утилита архивации данных Backup. В процессе архивации зашифрованные данные будут скопированы на указанный носитель без дешифрования. Целевой носитель может не поддерживать NTFS 5.0. Например, резервная копия зашифрованных файлов может быть создана на гибком диске. другу, в таких сетях можно обмениваться данными, не применяя средств безопасности. В открытых сетях, таких как Интернет, информация может попасть в руки пользователей, намерения которых никому не известны. Информация, не представляющая особой ценности, не нуждается и в безопасности. Однако, если информация является ценной или конфиденциальной, необходимо предпринять соответствующие меры безопасности для ее защиты. Использование сертификатов для обеспечения безопасности Сертификаты можно использовать для решения различных задач безопасности. • Аутентификация (authentication) или проверка подлинности. Проверка того, что объект, с которым вы взаимодействуете, является в действительности авторизованным объектом. • Обеспечение конфиденциальности (privacy) или секретности. Обеспечение доступа к информации только авторизованным пользователям, даже если любой пользователь сети может перехватить сообщение. • Шифрование (encryption). Обеспечивает доступ к информации только для того пользователя, которому она предназначена. • Цифровые подписи (digital signatures). Обеспечение целостности и подлинности данных. Аутентификация Аутентификация является необходимым условием обеспечения секретности обмена данными. Пользователи должны иметь возможность подтвердить свою подлинность и проверить идентификацию других пользователей, с которым они общаются. Цифровой сертификат является распространенным средством идентификации. Сертификаты служат для обеспечения аутентификации в следующих случаях: • аутентификация пользователя для защищенного веб-узла посредством протоколов Transport Layer Security (TLS) или Secure Sockets Layer (SSL); • аутентификация сервера для пользователя посредством TLS. Конфиденциальность Для обеспечения конфиденциальности при передаче данных в незащищенных сетях или по частным локальным сетям применяется шифрование с секретным, или закрытым, ключом (secret key encryption). Сертификаты обеспечивают конфиденциальность передаваемых данных при помощи ряда методов. Протоколы, наиболее широко используемые для обеспечения секретности: • Secure Multipurpose Internet Mail Extensions (S/MIME); • Transport Layer Security (TLS); • IP Security (IPSec). Центры сертификации Центр сертификации (также встречается термин поставщик сертификатов) (Certification Authority, CA) представляет собой службу, которой доверен выпуск сертификатов, если индивидуальный пользователь или организация, которые запрашивают сертификат, удовлетворяют условиям установленной политики. Это осуществляется путем принятия запроса на получение сертификата, проверки и регистрации имени запрашивающего сертификат пользователя и открытого ключа в соответствии с политикой. Каждый ЦС должен получить от запрашивающей сертификат стороны подтверждение ее идентичности, такое как удостоверение личности или физический адрес. Затем производится подписание и назначение сертификата, подтверждающего выполнение пользователем критериев политики, которые были установлены для авторизации. Большинство используемых на сегодня сертификатов основаны на стандарте Х.509, эта фундаментальная технология применяется в инфраструктуре открытых ключей Windows 2000 и Windows Server 2003. Центром сертификации может быть удаленная организация, такая как VeriSign, или локальная служба, созданная в вашей организации путем инсталляции служб Certificate Services (Служб сертификации). Выбор ЦС основывается на доверительном отношении (trust). Вы доверяете, что ЦС использует правильную политику при рассмотрении запросов на подписание сертификатов. Кроме того, вы доверяете, что ЦС отзывает сертификаты с истекшим сроком действия путем публикации списка отозванных сертификатов (certificate revocation list). Центры сертификации также имеют собственные сертификаты. Причем вышестоящий центр подписывает сертификаты для нижестоящих центров. Таким образом, формируется иерархия сертификатов (certificate hierarchy). Доверие центру сертификации устанавливается при наличии копии корневого сертификата в хранилище доверяемых корневых центров сертификации, а также действительного пути к сертификату. Это означает, что ни один из сертификатов иерархии (пути сертификатов) не был отозван и не имеет истекшего срока действия. Если в организации используется Active Directory, то доверие к центрам сертификации вашей организации устанавливается автоматически на основе решений и установок, выполненных системным администратором. Сертификат удостоверяет, что индивидуальный пользователь или ЦС, представляющий сертификат, был авторизован в соответствии с политикой, Рисунок 10. Окно оснастки Certificates Таблица 1. Список папок хранилища сертификатов с кратким описанием Сортировка по Папка Содержит Логическим хранилищам Personal (Личные) Сертификаты, связанные с закрытыми ключами пользователя. Сертификаты, которые были выданы компьютеру или службе, для которых выполняется управление сертификатами Trusted Root Certification Authorities (Доверенные корневые центры сертификации) Полностью доверяемые центры сертификации Enterprise Trust (Доверительные отношения в предприятии) Списки доверяемых отношений сертификатов (certificate trust list). Обеспечивает механизм доверия к корневым сертификатам со стороны других организаций Intermediate Certification Authorities (Промежуточные центры сертификации) Сертификаты, выпущенные для других пользователей и центров сертификации Active Directory User Object (Объект пользователя Active Directory) Сертификаты, связанные с вашим пользовательским объектом и опубликованные в Active Directory Trusted Publishers (Доверенные издатели) Сертификаты, выпущенные центрами сертификации, которые соответствуют политикам Software Restriction Untrusted Certificates (Сертификаты, к которым нет доверия) Сертификаты, для которых явно установлено отсутствие доверительных отношений Third-Party Root Certification Authorities (Сторонние корневые центры сертификации) Доверяемые корневые сертификаты от центров сертификации, отличных от Microsoft и вашей собственной организации Trusted People (Доверенные лица) Сертификаты, выпущенные для других пользователей или конечных устройств, с которыми налажены доверительные отношения По назначению Server Authentication (Проверка подлинности сервера) Сертификаты, которые используются серверными программами для аутентификации при обращении к клиентам Client Authentication (Проверка подлинности клиента) Сертификаты, которые используются клиентскими программами для аутентификации при обращении к серверам Code Signing (Подписывание кода) Сертификаты, связанные с парами ключей, используемых для подписи активного содержания Secure Email (Защищенная электронная почта) Сертификаты, связанные с парами ключей, используемых для подписи электронных сообщений Encrypting File System (Шифрующая файловая система) Сертификаты, связанные с парами ключей, которые шифруют и дешифруют симметричный ключ, используемый для шифрования и расшифровки данных File Recovery (Восстановление файлов) Сертификаты, связанные с парами ключей, которые шифруют и дешифруют симметричный ключ, используемый для восстановления зашифрованных данных При наличии соответствующих прав вы можете импортировать или Импорт и экспорт сертификатов При импорте или экспорте сертификат копируется в хранилище или из хранилища. Импорт или экспорт сертификата проводится при выполнении следующих задач: • инсталляция сертификата, полученного вами от другого пользователя (импорт); • восстановление сертификата, который хранился в виде резервной копии (импорт); • создание резервной копии сертификата (экспорт); • копирование сертификата или ключа для использования на другом компьютере (экспорт). Передавать сертификаты можно в следующих форматах. • Personal Information Exchange (Обмен персональной информацией) (PKCS #12) Данный формат (Personal Information Exchange, PFX) позволяет приложениям передавать сертификаты и соответствующие личные ключи с одного компьютера на другой, на съемный накопитель или смарт-карту. PKCS #12 является стандартным в отрасли форматом, применяемым для передачи или резервного копирования и восстановления сертификатов и их ключей. Сертификаты в этом формате могут передаваться между продуктами одного или различных производителей, например, Microsoft и IBM. Для использования формата PKCS #12 поставщик услуг шифрования (CSP) должен считать сертификаты и ключи доступными для экспорта. Экспорт личного ключа — рискованная операция, поскольку ключом могут завладеть посторонние лица. Поэтому PKCS #12 является единственным форматом, который Microsoft поддерживает для экспорта сертификатов и связанных с ними личных ключей. • Cryptographic Message Syntax Standard (Криптографический стандарт на синтаксис сообщений) (PKCS #7) Определяет общий синтаксис данных и дает рекомендации по шифрованию, цифровым подписям и цепочкам сертификатов. PKCS #7 определяет точный формат, в котором данные шифруются или подписываются, а также то, как определяются алгоритмы шифрования. PKCS #7 позволяет передавать сертификат и все сертификаты в пути сертификата с одного компьютера на другой или с компьютера на съемный диск. Имена файлов сертификатов имеют расширение р7Ь. • DER Encoded Binary X.509 Формат могут использовать центры сертификации, находящиеся не на серверах Windows. Имена файлов сертификатов имеют расширение сеr. • Base64 Encoded X. 509 Данный формат могут применять ЦС, находящиеся не на серверах Windows, — например, ЦС, использующие программное обеспечение Netscape. Имена файлов сертификатов имеют расширение сеr. Установка центра сертификации Центр сертификации (ЦС) — важный элемент в системе безопасности организации, поэтому в большинстве организаций имеется собственный ЦС. В Windows Server 2003 центры сертификации могут быть двух классов: ЦС предприятия (Enterprise СА) и изолированный ЦС (Stand-alone CA). Внутри каждого класса могут быть два типа ЦС: корневой (root) и подчиненный (subordinate). В большинстве случаев центры сертификации организованы в иерархическом порядке, где наиболее доверяемый, или корневой, центр находится на вершине иерархии. В корпоративной сети все остальные ЦС в иерархии являются подчиненными. В корпоративной сети ЦС предприятия имеет максимальное доверие. ЦС предприятия имеют специальный модуль политик, который определяет, как обрабатываются и выпускаются сертификаты. Информация политики из данного модуля хранится в Active Directory, поэтому для инсталляции ЦС предприятия сначала следует установить Active Directory. Изолированные ЦС имеют очень простой модуль политик и не хранят никакой информации на удаленном сервере, поэтому для инсталляции данного центра не требуется наличия Active Directory. Для развертывания собственного ЦС: 1. Выберите на панели управления значок Add or Remove Programs (Установка и удаление программ). 2. В открывшемся окне нажмите кнопку Add/Remove Windows Components (Добавление и удаление компонентов Windows). 3. В окне мастера Windows Components Wizard (Мастер компонентов Windows) установите флажок Certificate Services (Службы сертификации) (при этом система предупредит вас о последствиях установки этих служб) и нажмите кнопку Next (Далее). 4. На следующей странице мастера необходимо выбрать тип ЦС. Существуют четыре типа ЦС: • Enterprise root СА (Корневой ЦС предприятия) — установите переключатель в это положение, если данный ЦС будет выпускать сертификаты для всех устройств, подключенных к сети в организации, и будет зарегистрирован в Active Directory. Данный ЦС является корнем в корпоративной иерархии ЦС и может устанавливаться только на контроллере домена. Обычно корневой ЦС предприятия выпускает сертификаты только для подчиненных ЦС; • Enterprise subordinate СА (Подчиненный ЦС предприятия) — если у вас уже установлен корневой ЦС предприятия, выберите это положение переключателя. Однако данный ЦС не имеет наивысшего доверия в организации, поскольку он подчиняется корневому ЦС. Может устанавливаться только на контроллере домена; • Stand-alone root CA (Изолированный корневой ЦС) — данный ЦС устанавливается для выпуска сертификатов за пределами корпоративной