Windows Server поддерживает технологии, основанные на шифровании открытым ключом: защищенные каналы, смарт- карты, Authenticode, шифрованную файловую систему (Encrypt- ing File System, EPS) и Internet Protocol Security (IPSec).
Защищенные каналы
В Windows Server пакет аутентификации Secure Channel (SChannel) расположен ниже интерфейса Security Support Pro- vider Interface (SSPI) (рис. 8.5).
Рис. 8.5. Архитектура Authentication Services в Windows Server
Пакет аутентификации SChannel поддерживает протоколы Secure Sockets Layer (SSL) 3.0 и Transport Layer Security (TLS). SSL и TLS — гибкие защищенные протоколы, способные вы- полняться поверх прочих транспортных протоколов, — основа- ны на технологии аутентификации с применением открытых ключей и для создания уникального ключа шифрования для каждого сеанса связи клиента с сервером обмениваются откры- тыми ключами.
Протокол TLS основан на протоколе SSL 3.0. Хотя разли- чия между TLS 1.0 и SSL 3.0 и незначительны, взаимодейство- вать TLS 1.0 и SSL 3.0 не могут. Однако в TLS 1.0 предусмотрен механизм согласования, поэтому TLS может использовать SSL
Следовательно, клиент, поддерживающий только SSL 3.0, может общаться с сервером, поддерживающим TLS 1.0.
SSL и TLS, обеспечивают безопасную передачу информа- ции путем шифрования, аутентификации клиента и (необяза- тельно) аутентификации сервера. Оба применяются для обмена
конфиденциальными данными по Интернету с применением аутентификации по открытому ключу.
Протокол SSL/TLS обеспечивается поставщиком SChannel (таким как IIS, Proxy Server и Exchange) и клиентским интернет- приложением (например, Internet Explorer или клиент электрон- ной почты Outlook). Приложения запрашивают службы SSL и TLS через API-интерфейс SSPI.
SSL и TLS дают следующие преимущества:
аутентификация гарантирует клиенту, что данные по- сылаются на нужный сервер и этот сервер защищен;
шифрование гарантирует, что данные сможет прочитать только целевой защищенный сервер;
проверка целостности обеспечивает неизменность по- лученных данных.
Смарт-карты
Применяются для хранения открытого и закрытого ключа пользователя и сертификата. Это более надежный способ защи- ты и контроля ключей пользователя, чем хранение их на компь- ютере. Пользовательские ключи и сертификаты перемещаются вместе с ним. Смарт-карта производит уязвимые с точки зрения безопасности вычисления, не открывая закрытый ключ пользо- вателя компьютеру.
Для работы со смарт-картой компьютеру требуется устройство считывания. Смарт-карта — это совместимое со стандартом ISO 7816 устройство, содержащее встроенный мик- ропроцессор, RSA или эквивалентный криптографический со- процессор и локальное запоминающее устройство.
Локальное запоминающее устройство обычно включает: 6–24 кб ПЗУ для ОС смарт-карты и программ; 128–512 байт ОЗУ для временных данных; 1–16 кб ОЗУ для данных пользова- теля.
8.2.2.1. Вход в систему с помощью смарт-карты
Windows поддерживает вход в систему со смарт-карты как альтернативу паролям для доменной аутентификации. Для взаи-
модействия с системой контроля доступа Kerberos в процессе аутентификации используется протокол PKINIT.
Система распознает событие вставки смарт-карты как аль- тернативу стандартной комбинации клавиш Ctrl+Alt+Del для входа, а затем запрашивает у пользователя PIN-код смарт- карты, открывающий доступ к операциям с сохраненным на смарт-карте закрытым ключом. Смарт-карта также содержит ко- пию сертификата пользователя (выпущенного ЦС предприя- тия). Это позволяет пользователю входить в домен с разных компьютеров.
Технология Authenticode
Широкое использование Интернета увеличило зависи- мость от его активного содержания: Windows-приложений, эле- ментов управления ActiveX и Java-апплетов. Появилась острая необходимость защитить клиентские системы от опасного кода, зачастую выполняемого без ведома пользователя.
В 1996 г. Microsoft была введена технология цифровой подписи Authenticode, а в 1997 г. она была значительно усовер- шенствована.
Технология Authenticode, элемент безопасности в Microsoft Internet Explorer, гарантирует аутентификацию программных компонентов в Интернете. Authenticode проверяет, что ПО не искажено и распознает его изготовителя. В каждом конкретном случае пользователи могут принимать решения о загрузке кода, основанные на их опыте и доверии изготовителю ПО. Подпись, которую разработчики удостоверяют свой код, — основа дове- рия к ним со стороны пользователей.
Authenticode позволяет разработчикам ПО ставить цифро- вую подпись на любую форму активного содержания, включая многотомные архивы. Эти подписи могут быть использованы для проверки как разработчиков содержимого, так и целостно- сти самого содержимого при загрузке. Windows. PKI позволяет выпускать Authenticode-сертификаты для внутренних разработ- чиков или подрядчиков, так что любой сотрудник может прове- рить источник и целостность загружаемых приложений.
Шифрованная файловая система
Шифрованная файловая система позволяет пользователям шифровать и расшифровывать файлы и применяется для защиты файлов от злоумышленников, которые могут получить несанк- ционированный физический доступ к хранимым конфиденци- альным данным (например, украв переносной компьютер или внешний диск).
Для обеспечения секретности данных в процессе шифро- вания применяется открытый ключ пользователя. Посторонние не смогут расшифровать информацию без соответствующего закрытого ключа. Для каждого зашифрованного файла создается специальный восстанавливающий ключ — его использует ком- петентный администратор в экстренных ситуациях, например в случае отсутствия сотрудника или при потере закрытого ключа.
Шифрование/расшифровка производится в ходе ввода- вывода автоматически и практически не влияет на производи- тельность.
EFS также поддерживает шифрование/расшифровку фай- лов на удаленных томах NTFS.
Файлы могут быть экспортированы в зашифрованном ви- де, но по умолчанию данные перемещаются по сети незашифро- ванными. Для шифрования данных при перемещении по сети Windows поддерживает сетевые протоколы SSL, TLS и IPSec.
Защита данных
EFS использует комбинацию открытого и закрытого клю- чей пользователя, а также выбранный случайным образом ключ шифрования файла (file encryption key, FEK).
FEK — это 128-разрядный ключ в версии для Северной Америки и 40-разрядный — для международных версий.
Windows использует для шифрования файлов алгоритм Da- ta Encryption Standard X (DESX).
Восстановление данных
Политика восстановления зашифрованных данных (En- crypted Data Recovery Policy, EDRP) указывает, кто может вос- становить данные в случае, если личный ключ пользователя
утерян. На изолированных компьютерах EDRP генерируется ав- томатически для упрощения администрирования.
Компьютеры домена получают EDRP из политики домена. По соображениям безопасности восстанавливают только за- шифрованные данные, а ключи пользователей восстановить нельзя.
Шифрование при резервном копировании и восстановлении
Так как члены группы Backup Operators (Операторы архи- ва) не имеют ключей для расшифровки, шифрованные данные считываются и записываются в резервную копию как фоновый поток данных.
Отказоустойчивость
Шифрование и расшифровка — операции уязвимые, так как сбой может привести к потере данных. Поэтому EFS выполняет все операции автоматически. Операция, которая не может быть завершена, отменяется. Например, если электропитание компью- тера отключается при шифровании, EFS отменяет эту операцию при перезагрузке, и файл остается в исходном состоянии.
После того как файл зашифрован, процессы шифрова- ния/расшифровки проходят автоматически и незаметно для пользователей и программ. За раз можно зашифровать один файл или одну папку.
Файл или папку можно зашифровать в Windows Explorer или из командной строки.
Невозможно одновременно использовать сжатие NTFS и шифрование для одного и того же файла — это взаимоисклю- чающие операции.
Шифрование в EFS
EFS шифрует, дешифрует и восстанавливает файлы (рис. 8.6).
Рис. 8.6. Процесс шифрования в EFS
Когда пользователь шифрует файл в EFS, происходит сле- дующее:
Служба EFS открывает файл для монопольного доступа.
Все данные, записываемые в файл, копируются во временный файл.
Ключ файла генерируется случайным образом и ис- пользуется для шифрования файла согласно схеме шифрования DES.
Создается поле расшифровки данных (Data Decryption Field, DDF), которое содержит ключ файла, зашифрованный от- крытым ключом пользователя.
Создается поле восстановления данных (Data Recovery Field, DRF), содержащее ключ файла, на этот раз зашифрован- ный открытым ключом агента восстановления. Открытый ключ агента восстановления извлекается из EDRP.
Сервер EFS записывает шифрованные данные с DDF
и DRF обратно в файл.
Расшифровка в EFS
Процесс расшифровки использует поле DDF, созданное при шифровании (рис. 8.7).
Рис. 8.7. Процесс расшифровки в EFS
Когда файл дешифруется в EFS, происходит следующее:
Когда какая-либо программа открывает зашифрованный файл, NTFS посылает запрос драйверу EFS.
Драйвер EFS возвращает значение DDF и передает его службе EFS.
Служба EFS дешифрует DDF с помощью закрытого ключа пользователя и получает ключ файла.
Служба EFS передает ключ файла обратно драйверу
EFS.
Драйвер EFS использует ключ файла для расшифровки
файла.
Драйвер EFS возвращает расшифрованные данные фай- ловой системе NTFS, которая завершает запрос файла и посыла- ет данные программе-заказчику.
Восстановление EFS
Восстановление EFS сходно с процессом расшифровки (рис. 8.8).
Когда файл восстанавливается в EFS, происходят следую- щие процессы.
NTFS посылает запрос драйверу EFS.
Драйвер EFS возвращает DRF и передает его службе
EFS.
Служба EFS восстанавливает DRF, пользуясь закрытым
ключом агента восстановления для получения ключа файла.
Служба EFS отправляет ключ файла обратно драйверу
EFS.
Драйвер EFS использует ключ файла для восстановле-
ния файла.
Драйвер EFS возвращает зашифрованные данные фай- ловой системе NTFS, которая завершает запрос файла и посыла- ет данные программе-заказчику.
Рис. 8.8. Процесс восстановления EFS
Утилита командной строки cipher (шифр)
Утилита cipher позволяет шифровать/дешифровать файлы из командной строки:
Do'stlaringiz bilan baham: |