Средства безопасности Windows Server 2003

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Средства безопасности Windows Server 2003

Средства безопасности Windows Server 2003

Федеральное агентство по образованию

Государственное образовательное учреждение

высшего профессионального образования

Дальневосточный государственный технический университет

(ДВПИ им. В.В. Куйбышева)

Кафедра конструирования и производства радиоаппаратуры

Реферат

на тему:

Средства безопасности 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
• Сертификаты
• Использование сертификатов для обеспечения безопасности
• Центры сертификации
• Использование сертификатов в Интернете
• Хранилища сертификатов
• Запрос сертификата
• Установка центра сертификации

Цифровые (электронные) подписи

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

· только владелец секретного ключа может создать цифровую подпись;

· любой пользователь, обладающий соответствующим открытым ключом, может проверить истинность цифровой подписи;

· любая модификация подписанных данных (даже изменение одного бита) делает неверной цифровую подпись.

Цифровые подписи гарантируют целостность (integrity) и подлинность (nonrepudiation) данных. Когда данные распространяются открытым текстом (без шифрования), получатели должны иметь возможность проверки, что данные в сообщении не были изменены. Добавление подписи не изменяет содержания данных: в этом случае генерируется цифровая подпись, которая может быть связана с данными или передаваться отдельно. Для выполнения этой операции клиентская программа создает дайджест, снимок данных, используя метод хэширования (например, MDS). Программа использует ваш личный ключ для шифрования дайджеста и подписывает данные или сообщение с помощью вашего сертификата, добавляя ваш открытый ключ. Соответствующая программа адресата сообщения использует открытый ключ для расшифровки дайджеста, затем использует тот же алгоритм хэширования для создания другого дайджеста данных. Данная программа затем сравнивает два дайджеста сообщений. Если они идентичны, то подтверждаются целостность и подлинность данных сообщения.

Распределенная аутентификация

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

Что такое сертификат

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

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

Наиболее распространенным на данный момент стандартом сертификатов является ITU-T X.509. Эта фундаментальная технология применяется в Windows 2000 и Windows Server 2003. Однако это не единственная форма сертификатов.

Центр сертификации

Центр сертификации (ЦС), или поставщик сертификатов (Certificate Authority, CA), -- это организация или служба, создающая сертификаты. ЦС выступает в качестве гаранта истинности связи между открытым ключом субъекта и идентифицирующей этот субъект информацией, содержащейся в сертификате. Различные ЦС могут применять для проверки связи различные средства, поэтому перед выбором достойного доверия ЦС важно хорошо понять политику данного ЦС и применяемые им процедуры проверки.

Рисунок.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 предназначена для проверки и подписи объектов и в основном используется при получении информации через Интернет.

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

· каким образом клиент будет получать информацию о секрете?

· каким образом клиент будет предоставлять серверу аутентификации информацию о своих полномочиях?

· каким образом клиент будет проверять полномочия сервера?

· каким образом сервер сможет убедиться в том, что полномочия, предоставленные клиентом, подлинные?

· каким образом будет обеспечиваться безопасность взаимодействия сервера и клиента в ходе проверки полномочий?

· каким образом будет исключаться возможность использования перехваченных пакетов?

В процедуре аутентификации участвуют три стороны;

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

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

· сервер, хранящий информацию о секретах всех клиентов. В терминологии Kerberos этот сервер получил название Центра распределения ключей (Key Distribution Center, KDC). Центр распределения ключей берет на себя роль посредника между серверами и их клиентами. Каждое подключение должно иметь уникальный секрет, поскольку к любому серверу может обращаться произвольное число пользователей. Центр распределения ключей решает эту задачу, обеспечивая каждое подобное подключение собственным уникальным секретом, известным только клиенту и серверу.

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

Аутентификация выполняется следующим образом: 1. Клиент посылает запрос серверу аутентификации (Authentication Server, AS) на информацию, однозначно идентифицирующую некоторый нужный клиенту сервер. 2. Сервер AS передает требуемую информацию, зашифрованную с помощью известного пользователю ключа. Переданная информация состоит из билета сервера и временного ключа, предназначенного для шифрования (часто называемого ключом сеанса). 3. Клиент пересылает серверу билет, содержащий идентификатор клиента и ключ сеанса, зашифрованные с помощью ключа, известного серверу. 4. Теперь ключ сеанса известен и клиенту, и серверу. Он может быть использован для аутентификации клиента, а также для аутентификации сервера. Ключ сеанса можно применять для шифрования передаваемой в сеансе информации или для взаимного обмена ключами подсеанса, предназначенными для шифрования последующей передаваемой информации. Протокол Kerberos функционирует на одном или нескольких серверах аутентификации, работающих на физически защищенном хосте. Серверы аутентификации ведут базы данных партнеров по обмену информацией в сети (пользователей, серверов и т. д.) и их секретных ключей. Программный код, обеспечивающий функционирование самого протокола и шифрование данных, находится в специальных библиотеках. Для того чтобы выполнять аутентификацию Kerberos для своих транзакций, приложения должны сделать несколько обращений к библиотекам Kerberos. Процесс аутентификации состоит из обмена необходимыми сообщениями с сервером аутентификации Kerberos.

Протокол Kerberos состоит из нескольких субпротоколов (или протоколов обмена сообщениями). Существует два метода, которыми клиент может запросить у сервера Kerberos информацию, идентифицирующую определенный сервер. Первый способ предполагает, что клиент посылает AS простой текстовый запрос билета для конкретного сервера, а в ответ получает данные, зашифрованные с помощью своего секретного ключа. Как правило, в данном случае клиент посылает запрос на билет, позволяющий получить билет (Ticket Granting Ticket, TGT), который в дальнейшем используется для работы с выдающим билеты сервером (Ticket Granting Server, TGS). Второй способ предполагает, что клиент посылает TGT-билеты на TGS-сервер так же, как будто он обменивается информацией с другим сервером приложений, требующим аутентификации Kerberos.

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

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

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

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

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

Модель распределенной безопасности Windows Server 2003

Модель распределенной безопасности Windows Server 2003 основана на трех основных концепциях.

· Каждая рабочая станция и сервер имеют прямой доверенный путь (trust path) к контроллеру домена, членом которого является данная машина. Доверенный путь устанавливается службой NetLogon с помощью аутентифицированного соединения RPC с контроллером домена. Защищенный канал устанавливается и с другими доменами с помощью междоменных доверительных отношений. Этот канал используется для проверки информации безопасности, включая идентификаторы безопасности (Security Identifiers, SID) пользователей и групп.

· Перед выполнением запрошенных клиентом операций сетевые службы имперсонализируют контекст безопасности этого клиента. Имперсонализация основана на маркере адреса безопасности, созданном локальным администратором безопасности (Local Security Authority, LSA). Он представляет собой авторизацию клиента на сервере. Поток, находящийся на сервере и соответствующий данному клиенту, имперсонализирует контекст безопасности клиента и выполняет операции в соответствии с авторизацией данного клиента, а не в соответствии с идентификатором безопасности сервера. Имперсонализация поддерживается всеми службами Windows Server 2003, включая, например, службу удаленного файлового сервера CIFS/SNB. Аутентифицированный RPC и DCOM поддерживают имперсонализацию для распределенных приложений. Серверы семейства BackOffice: Exchange Server, SNA Server и Internet Information Server также поддерживают имперсонализацию.

· Ядро Windows Server 2003 поддерживает объектно-ориентированное управление доступом, сравнивая SID в маркере доступа с правами доступа, определенными в списке управления доступом данного объекта. Каждый объект Windows Sewer 2003 (ключи реестра, файлы и каталоги NTFS, общие ресурсы, объекты ядра, очереди печати и т. д.) имеют собственные списки управления доступом. Ядро Windows Server 2003 проверяет разрешения при каждой попытке доступа к данному объекту. Управление доступом и аудит осуществляются с помощью настройки свойств безопасности объекта, позволяющих предоставить пользователю или группе доступ к объекту. Управление авторизацией выполняется централизованно посредством включения пользователей в локальные группы системы, которым предоставлены необходимые права доступа. В операционной системе Windows Server 2003 существуют дополнительные средства обеспечения безопасности -- аутентификация клиента с помощью открытого ключа посредством SSL/TLS и протокола Kerberos версии 5, которые интегрированы в систему безопасности.

Интегрированная аутентификация Kerberos

В Windows Server 2003 аутентификация Kerberos реализована на уровне доменов, что позволяет выполнять одну регистрацию в системе при доступе ко всем ресурсам сети и поддерживать модель распределенной безопасности Windows Server 2003. На любом участке дерева доменов Active Directory протокол Kerberos обеспечивает взаимную аутентификацию, ускоренную аутентификацию и транзитное доверие на аутентификацию. Аутентификация Kerberos в Windows Server 2003 используется для выполнения интерактивной регистрации пользователя в домене. Расширение стандартной аутентификации Kerberos для применения открытого ключа позволяет применять регистрацию в Windows Server 2003 с помощью смарт-карты. Протокол Kerberos реачизован в виде поставщика безопасности, доступ к которому осуществляется с применением интерфейса поддержки поставщика безопасности (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 в много платформенных системах, а также подпись, обеспечивающую целостность данных и устанавливаемую КОС.

Применение Kerberos в сетях Windows 2000/Server 2003

Аутентификация Kerberos используется многими службами домена Active Directory. Интерфейс SSPI применяется для аутентификации в большинстве системных служб, поэтому их перевод с аутентификации NTLM на Kerberos требует минимальных усилий. Более сложные изменения необходимы на сервере SMB, который не использовал SSPI до версии Windows 2000. Многие новые распределенные службы Windows 2000 используют аутентификацию Kerberos. Примеры областей применения аутентификации Kerberos в Windows 2000/Server 2003:

· аутентификация в Active Directory с применением LDAP для запросов или управления каталогом;

· протокол удаленного доступа к файлам CIFS/SMB;

· управление распределенной файловой системой DFS;

· защищенное обновление адресов DNS;

· службы печати;

· необязательная взаимная аутентификация IPSec-хостов при работе протоколов ISAKMP/Oakley;

· запросы резервирования для службы качества обслуживания (Quality of Service);

· аутентификация интрасети в службах Internet Information Services;

· аутентификация запросов сертификата открытого ключа, приходящих от пользователей и компьютеров домена, в службах Certificate Services;

· удаленное управление сервером или рабочей станцией с помощью аутентифицированного RPC и DCOM.

Это первый шаг к основной цели, поставленной в Windows 2000, -- полному исключению аутентификации NTLM в компьютерных сетях, основанных на этой операционной системе.

Совместная работа средств обеспечения безопасности сети

Домены Active Directory должны иметь возможность одновременно поддерживать клиентские компьютеры и серверы, на которых работает программное обеспечение Windows NT 3.x--4.0, Windows 9х/МЕ, а также Windows 2000/XP и Windows Server 2003. Для этого в Windows Server 2003 остается поддержка аутентификации NTLM, обеспечивающей совместимость с операционными системами более ранних версий. Обновленные версии клиента Active Directory обеспечивают расширенные возможности аутентификации по протоколу NTLM v.2; хотя протокол Kerberos не поддерживается.

Эти проблемы характеризуются такими показателями, как целостность данных, конфиденциальность и подлинность. Кроме того, защита от повторного использования (replay protection) предотвращает принятие повторно посланного пакета.

Примечание Реализация безопасности IP в Windows Server 2003 основана на стандартах RFC, разработанных консорциумом Internet Engineering Task Force (IETF), рабочей группой IP Security (IPSEC).

Возможности стандарта IPSec и подробности реализации очень сложны и описаны подробно в ряде RFC и проектов IETF, а также в документах Microsoft. IPSec использует криптографическую защиту для обеспечения управления доступом, целостности без установления логического соединения, удостоверения подлинности данных, защиты от повторного использования, полной и ограниченной конфиденциальности потока данных. Поскольку протокол IPSec работает на уровне IP, его услуги доступны протоколам верхнего уровня в стеке и, очевидно, существующим приложениям.

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

IPSec может защищать пути между компьютерами, между шлюзами защиты или между шлюзами защиты и компьютерами. Услуги, доступные и требуемые для трафика, настраиваются с использованием политики IPSec. Политика IPSec может быть настроена локально на отдельном компьютере или может быть назначена через механизм групповых политик в Active Directory. Политика IPSec определяет, как компьютеры доверяют друг другу. Самое простое -- полагаться на применение доменов доверия Active Directory, основанных на протоколе Kerberos. Для того чтобы доверять компьютерам в том же самом или в другом доверенном домене, задается предопределенная политика IPSec.

Каждая датаграмма на уровне протокола IP сравнивается с набором фильтров, предоставляемых политикой безопасности, которая поддерживается администратором для компьютера, пользователя, организационной единицы (OU) или всего домена. С любой датаграммой службы IP могут выполнить одно из трех действий:

· передать на обработку службам IPSec;

· передать ее без изменений;

· игнорировать ее.

Установка IPSec включает описание характеристик трафика для фильтрации (IP-адрес источника/адресата, протокол, порт и т. д.) и определение того, какие механизмы требуется применить для трафика, соответствующего фильтру (фильтрам). Например, в очень простом случае два автономных компьютера могут быть сконфигурированы для использования IPSec между ними в одном и том же домене Active Directory и активизации политики блокировки (lockdown). Если два компьютера -- не элементы одного и того же или доверенного домена, то доверие должно быть сконфигурировано с использованием пароля или ключа pre-shared в режиме "закрытый". Для этого выполняются операции:

· установка фильтра, который определяет весь трафик между двумя компьютерами;

· выбор метода опознавания (выбор ключа pre-shared или ввод пароля);

· выбор политики переговоров (в режиме "закрытый", при этом весь трафик, соответствующий фильтру (фильтрам), должен использовать IPSec);

· определение типа подключения (ЛВС, коммутируемое соединение или оба типа подключения).

Применение политики блокировки также ограничит все другие типы трафика от достижимых адресатов, которые не понимают IPSec или не являются частью той же самой доверенной группы. Безопасная политика инициатора обеспечивает установки, применяемые лучше всего к тем серверам, для которых предпринята защита трафика, но если клиент "не понимает" IPSec, то результатом переговоров будет возобновление посылки "чистых" текстовых пакетов. Когда IPSec применяется для шифрования данных, производительность сети понижается из-за непроизводительных затрат на обработку и шифрование. Один из возможных методов уменьшения воздействия этих непроизводительных затрат -- обработка на аппаратном уровне. Поскольку интерфейс NDIS 5.1 поддерживает такую функцию, можно включить аппаратные средства шифрования в сетевой адаптер. Адаптер, обеспечивающий перегрузку 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-пакета.

· Протокол инкапсуляции безопасности (ESP, Encapsulating Security Protocol). В дополнение к услугам АН, описанным выше, ESP обеспечивает конфиденциальность, используя алгоритм DES-CBC.

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

Рисунок 2. Архитектура безопасности IP в Windows Server 2003

· Политика переговоров (negotiation policy)

Политика переговоров определяет службы безопасности, используемые во время связи. Можно выбрать услуги, включающие конфиденциальность (ESP) или не обеспечивающие конфиденциальность (АН), или можно определить, какой алгоритм нужно использовать для безопасности IP. Можно установить несколько методов безопасности для каждой политики переговоров. Если первый метод недопустим для ассоциации безопасности, служба ISAKMP/Oakley продолжит просмотр этого списка до тех пор, пока не будет найден тот алгоритм, который безопасность IP сможет использовать для установления ассоциации. Если переговоры не увенчались успехом, устанавливается соединение без безопасности IP.

· IP-фильтры

IP-фильтры определяют различные действия, зависящие от направления передачи IP-пакета, от типа применяемого IP-протокола (например, TCP или UDP) и от того, какие порты используются в соответствии с протоколом. Фильтр применяется непосредственно -- как шаблон, с которым сравниваются IP-пакеты. Каждый IP-пакет сверяется с 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

На уровне пользователя процесс доставки IP-пакетов прозрачен. Пользователь 1 просто запускает приложение, которое использует протокол стека TCP/IP, например FTP, и посылает данные Пользователю 2. Политики безопасности, назначенные Компьютеру А и Компьютеру В администратором, определяют уровень безопасности взаимодействия. Они выбираются агентом политики и передаются службе ISAKMP/Oakley и драйверу IPSec. Служба ISAKMP/Oakley на каждом компьютере использует политику переговоров, связанную с назначенной политикой безопасности, чтобы установить ключ и общий метод переговоров (ассоциация безопасности). Результаты переговоров о политике ISAKMP между двумя компьютерами передаются драйверу IPSec, который использует ключ для шифрования данных. В заключение драйвер IPSec посылает шифрованные данные на Компьютер В. Драйвер IPSec на Компьютере В дешифрует данные и передает их приложению-получателю (см. описание процесса на рис. 5). Примечание Любые маршрутизаторы или коммутаторы, которые находятся на пути между поддерживающими связь компьютерами, вне зависимости от того, общаются ли два пользователя или пользователь и файловый сервер, должны просто пропускать шифрованные IP-пакеты к адресату. Если между поддерживающими связь компьютерами находится брандмауэр или другой шлюз, поддерживающий систему безопасности, то на нем должна быть разрешена функция пересылки IP-пакетов или настроена специальная фильтрация, которая разрешает пересылку пакетов безопасности IP, чтобы IP-пакеты правильно достигали адресата.

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

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

1. Создать политику безопасности с именем Legal и привязать ее к заданной по умолчанию политике домена (Default Domain Policy). Поскольку каждый компьютер входит в домен компании, агент политики компьютера выберет политику безопасности Legal в каталоге Active Directory. Политика безопасности 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, которая обеспечивает установление подлинности, защиту от изменений и конфиденциальность связи.

Рисунок 6. Управление политиками IP Security в окне оснастки Default Domain Policy

Можно конфигурировать безопасность IP, используя оснастки Local Security Settings (Локальные параметры безопасности) (на локальном компьютере) или Default Domain Policy (рис. 6) (для домена). Также можно подключить к консоли ММС изолированную оснастку IP Security Policy Management (Управление политикой безопасности IP) и настроить ее для компьютера или домена.

Все перечисленные выше проблемы позволяет решить шифрующая фашювая система (Encrypting File System, EFS), впервые реализованная в Windows 2000 и работающая только на NTFS 5.0. В следующих разделах подробно описаны технология шифрования, место шифрования в операционной системе, взаимодействие с пользователями и способ восстановления данных.

Рисунок 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, устанавливаемая по умолчанию, позволяет пользователю шифровать свои файлы без всякого вмешательства со стороны администратора. В этом случае EFS автоматически генерирует для пользователя пару ключей (открытый и личный), применяемых для криптозащиты данных, и подписывает сертификат.

Шифрование и дешифрование файлов может быть выполнено как для определенных файлов, так и для целого каталога. Эти операции прозрачны для пользователя. При шифровании каталога автоматически шифруются и все входящие в него файлы и подкаталоги. Каждый файл обладает уникальным ключом, позволяющим легко выполнять операцию переименования. Если вы переименовываете файл, находящийся в зашифрованном каталоге, и переносите его в незашифрованный каталог, сам файл остается зашифрованным (при условии, что целевой каталог находится на томе NTFS 5.0). Средства шифрования и дешифрования доступны через Windows Explorer. Кроме того, можно использовать все возможности шифрования данных с помощью набора утилит командной строки и интерфейсов администрирования. Если зашифрованные файлы хранятся на общих ресурсах, то для работы с ними пользователи должны иметь сертификат и личный ключ того, кто установил шифрование этих файлов. Впоследствии каждый пользователь может при необходимости независимо расшифровать файл при помощи своего личного ключа.

Создание агента восстановления

Описываемая ниже процедура должна выполняться на автономном компьютере, на котором планируется использование системы 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 (Восстановление файлов).

Теперь можно использовать шифрование информации, не опасаясь потери "ключа" к ней.

Шифрование файлов и каталогов

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

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

Примечание

Для шифрования/дешифрования файлов и папок можно также использовать утилиту командной строки Cipher.exe.

Шифрование информации задается в окне свойств файла или папки: 1. Укажите файл или папку, которую требуется зашифровать, нажмите правую кнопку мыши и выберите в контекстном меню команду Properties (Свойства).

2. В появившемся окне свойств на вкладке General (Общие) нажмите кнопку Advanced (Другие). Появится диалоговое окно Advanced Attributes (Дополнительные атрибуты).

3. В группе Compress or Encrypt attributes (Атрибуты сжатия и шифрования) установите флажок Encrypt contents to secure data (Шифровать содержимое для защиты данных) и нажмите кнопку ОК.

4. Нажмите кнопку ОК в окне свойств зашифровываемого файла или папки. В появившемся диалоговом окне подтвердите режим шифрования.

При шифровании папки можно указать следующие режимы:

· Apply changes to this folder (Только к этой папке);

· Apply changes to this folder, subfolders and files (К этой папке и всем вложенным папкам и файлам).

Шифрование файлов для совместного использования

Системы 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. Например, резервная копия зашифрованных файлов может быть создана на гибком диске.

Управление сертификатами пользователей

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

Примечание

В вышесказанном легко убедиться, если после инсталляции системы запустить оснастку Certificates и раскрыть узел (папку) Personal: этот узел будет пуст. Если затем зашифровать некоторый файл или папку и вернуться в оснастку Certificates, то можно увидеть, что в папке Personal появился сертификат, выданный текущему пользователю. Управление сертификатами, их импорт и экспорт осуществляются с помощью контекстных меню оснастки Certificates (см. также ниже разд. "Импорт к экспорт сертификатов"). Пользователи имеют возможность управлять только своими собственными сертификатами.

Восстановление зашифрованных файлов на другом компьютере

Иногда возникает необходимость восстановить зашифрованную информацию не на том компьютере, на котором она была заархивирована. Это можно выполнить с помощью утилиты архивации, которая сохраняет информацию в зашифрованном виде вместе с атрибутом шифрования. Однако нужно позаботиться о переносе на новый компьютер соответствующего сертификата и личного ключа пользователя либо с помощью перемещаемого профиля, либо вручную. На любом компьютере, где зарегистрировался пользователь, обладающий перемещаемым профилем, будут применяться одни и те же ключи шифрования. Ручной перенос личного ключа и сертификата выполняется в два этапа: сначала следует создать резервную копию сертификата и личного ключа (при этом сертификат и секретный ключ должны быть экспортированы в файл с расширением pfx), а затем восстановить созданную копию на другом компьютере. (Эта процедура имеет смысл только для компьютеров, не входящих в домен. В домене можно использовать процедуру, описанную выше в разд. "Шифрование файлов для совместного использования".) В результате этой процедуры текущий пользователь (который импортировал сертификат) получит возможность работать с зашифрованными данными на этом компьютере.

Аутентификация

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

Сертификаты служат для обеспечения аутентификации в следующих случаях:

· аутентификация пользователя для защищенного веб-узла посредством протоколов 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).

Все сертификаты имеют ограниченный срок действия. Даты начала и окончания срока действия сертификата указываются в сертификате. Для каждого ЦС устанавливается политика обновления сертификатов с истекшим сроком действия.

Если в компании для организации центра сертификации установлены службы сертификации на Windows 2000 Server или Windows Server 2003, то используется один из двух типов ЦС:

· центр сертификации предприятия (enterprise certification authority). Требует наличия Active Directory. Использует информацию, доступную в Active Directory, для проверки идентификационной информации запрашивающего сертификат. Публикует списки отозванных сертификатов в Active Directory, а также в общей папке;

· изолированный (автономный) центр сертификации (stand-alone certification authority). He зависит от Active Directory. По умолчанию пользователи могут запрашивать сертификаты у данного центра только с веб-страниц. Изолированный центр сертификации публикует списки отозванных сертификатов в общей папке или в Active Directory (если служба каталогов доступна).

Рисунок 10. Окно оснастки Certificates

Таблица 1. Список папок хранилища сертификатов с кратким описанием

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

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

Команда Find Certificates (Поиск сертификатов) (контекстного меню или меню Action (Действие)) помогает отыскать выпущенные сертификаты в хранилищах сертификатов. Вы можете провести поиск в определенном хранилище или во всех хранилищах и ограничить поиск на основании определенной информации сертификатов, например, искать сертификаты, выпущенные определенным центром сертификации.

6. Введите дружественное имя сертификата и его описание.

7. После выбора и проверки всех параметров нажмите кнопку Finish (Готово).

Импорт и экспорт сертификатов

При импорте или экспорте сертификат копируется в хранилище или из хранилища. Импорт или экспорт сертификата проводится при выполнении следующих задач:

· инсталляция сертификата, полученного вами от другого пользователя (импорт);

· восстановление сертификата, который хранился в виде резервной копии (импорт);

· создание резервной копии сертификата (экспорт);

· копирование сертификата или ключа для использования на другом компьютере (экспорт).

Передавать сертификаты можно в следующих форматах.

· 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.

5. Если вы собираетесь изменить параметры шифрования по умолчанию, установите флажок Use custom setting to generate the key pair and CA certificate (Использовать специальные параметры для генерации пары ключей и сертификата ЦС).

6. Нажмите кнопку Next.

7. Укажите имя ЦС и срок действия сертификатов. Введите необходимую информацию и нажмите кнопку Next.

8. Укажите папку на локальном или общем диске для хранения сертификатов и нажмите кнопку Next.

9. По окончании процедуры инсталляции нажмите кнопку Finish (Готово).

Управление центром сертификации

После инсталляции центра сертификации можно запустить управляющую оснастку Certification Authority. Для этого в меню Administrative Tools выполните команду Certification Authority. В окне оснастки (рис. 11) можно просматривать списки сертификатов, а также работать с шаблонами сертификатов. В системах Windows Server 2003 шаблоны сертификатов можно создавать и модифицировать, для чего имеется специальная оснастка -- Certificate Templates.

Рисунок 11. Окно оснастки Certification Authority