Книги, научные публикации
Pages: | 1 | ... | 11 | 12 | 13 | 14 | 15 | ... | 18 | Distributed Systems Guide Microsoft Windows 2000 Server Microsoft Press Распределенные системы Книга 1 Microsof Windows 2000 ...
-- [ Страница 13 ] --Дочерние объекты-контейнеры: АСЕ наследуют ся с установленным флагом только для насле дования, если только не установлен флаг NO_PROPAGATE_INHERIT_ACE Только CONTAINER_INHERIT_ACE Дочерние объекты, не являющиеся контейнера ми: родительские АСЕ не оказывают воздействия па дочерний объект.
Дочерние объекты-контейнеры: дочерний объект наследует действующую АСЕ. Унаследованная АСЕ является наследуемой, если только не уста новлен флаг NO_PROPAGATE_INHERIT_ACIE CONTAINER_INIIERIT_ACE и Дочерние объекты, не являющиеся контейнера OBJECT_INHERIT_ACE ми: АСЕ наследуются как действующие.
Дочерние объекты-контейнеры: дочернин объс кт наследует действующую АСЕ. Унаследованная АСЕ является наследуемой, если только не уста новлен флаг NO_PROPAGATE_INHERIT_AC E Если унаследованная АСЕ является действующей для дочернего объекта, система ус танавливает и переносит все общие права на конкретные права для дочернего объек та. Подобным образом система переносит общие (например, CREATOR_OWNER) и конкретные SID. Если унаследованная АСЕ предназначена только для наследован ш, никакие общие права или общие SID не изменяются, чтобы их можно было в даль нейшем корректно перенести, когда АСЕ будет унаследована следующим поколени ем дочерних объектов.
Когда контейнерный объект наследует АСЕ, которая одновременно является дей ствующей для контейнера и наследуется его потомками, контейнер может наследо вать две АСЕ. Это происходит в случаях, когда наследуемая АСЕ содержит общую Безопасность в распределенных системах 566 ЧАСТЬ информацию. Контейнер наследует АСЕ с флагом только для наследования, содер жащую общую информацию, и действующую АСЕ, в которой эта общая информа ция уже перенесена.
У объектно-зависимой АСЕ есть поле Тип объекта-наследника, где- содержится GUID-идентификатор, указывающий на тип объекта, который может ее наследо вать. Если такого идентификатора в этом иоле нет, наследование выполняется, как для стандартной АСЕ. Если GUID в поле присутствует, запись управления досту пом наследуется объектами с соответствующим GUID, если установлен флаг OBJECT_1NHERIT_ACE, и контейнерами с соответствующим GUID, если установ лен флаг CONTAINER_INHERITACE.
Порядок записей управления доступом в DACL Наиболее предпочтительный порядок записей управления доступом в DACL назы вается каноническим (canonical). В Windows 2000 существует следующие правила канонического порядка:
Х явно устанавливаемые АСЕ помещаются в группу перед любыми унаследован ными записями управления доступом;
Х в группе явно устанавливаемых АСЕ запрещающие АСЕ располагаются перед разрешающими АСЕ;
Х унаследованные АСЕ размещаются в том порядке, в каком они наследовались. Ч сначала АСЕ, унаследованные от родителя дочернего объекта, затем от де душки и так далее вверх по дереву объектов, Рис. 12-24 иллюстрирует канонический порядок.
Размер ACL Редакция ACL Число АСЕ Явно А С Е : Доступ запрещен устанавливаемые АСЕ: Доступ разрешен АСЕ: Доступ запрещен Унаследованные АСЕ: Доступ разрешен Рис. 12-24. Канонический порядок ЛСЕ Канонический порядок гарантирует, что явно установленные АСЕ запрещения об рабатываются прежде каких-либо явно установленных АСЕ разрешений. Таким об разом, владелец объекта может установить разрешения, предоставляющие доступ группе пользователей, например Everyone (Все), но закрывающие его подмножеству этой группы, например Marketing. Если АСЕ объекта расположены в каноническом порядке, запись управления доступом, запрещающая доступ группе Marketing, пред шествует АСК, разрешающей доступ группе Everyone (Все). При проверке доступа операционная система обрабатывает ЛСЕ в том порядке, в котором они располага ются в DACL объекта, следовательно, запрещающая АСЕ будет обработана раньше разрешающей. В результате доступа лишатся члены группы Marketing, а всем про чим он будет разрешен.
Кроме того, канонический порядок обеспечивает обработку сначала явно установ ленных, а потом унаследованных АСЕ. Это согласуется с концепцией избиратель ГЛАВА 12 Управление доступом ного (discretionary) управления доступом: доступом к дочерним объектам управля ет владелец дочернего объекта, а не владелец родителя. Владелец дочернего объек та может определять разрешения непосредственно на объекте. Предположим, что у родительского объекта имеется наследуемая АСЕ. запрещающая доступ группе Marketing. Допустим также, что владелец дочернего объекта добавляет в пего яв ную АСЕ, разрешающую доступ подмножеству группы Marketing, скажем, Бобу.
Если АСЕ дочернего объекта расположены в каноническом порядке, явно установ ленная АСЕ, предоставляющая Бобу доступ, предшествует любой из унаследован ных АСЕ, в том числе и АСЕ, запрещающей доступ группе Marketing. В результате Боб получит доступ к объекту несмотря на то, что он является членом группы Marketing. Другим членам этой группы доступ будет закрыт.
Отсутствие DACL и пустая DACL Дескриптор безопасности без DACL предоставляет безусловный доступ всем.
Дескриптор безопасности с пустой DACL не предоставляет доступа никому.
В Windows NT разработчику, желающему предоставить всем свободный дос туп к объекту, достаточно написать код создания объекта без DACL. В Win dows 2000 можно поступить также, но с небольшой поправкой: нужно допол нительно установить управляющий флаг дескриптора безопасности SE_DACL_PROTECTED. Если этого не сделать, объект приобретет DACL (а вместе с ней и одну пли более записей управления доступом) но механиз му наследования, а эта таблица управления доступом совсем не обязательно предоставит безусловный доступ всем. Если у родительского объекта вооб ще не окажется наследуемых разрешений, дочерний объект получит пустую DACL, то есть доступ к объекту будет закрыт всем. А это противоречит на мерениям создателя объекта.
Чтобы предоставить безусловный доступ к создаваемому Вашей программой объекту в Windows 2000 всем желающим, Вы должны назначить ему DACL с одной АСЕ, предоставляющей полный доступ группе Everyone (Все).
Процедуры при обновлении операционной системы После обновления операционной системы с Windows NT 4.0 на Windows 2000 изме нение порядка на канонический в DACL существующих объектов выполняется при первом же изменении их дескрипторов безопасности. Поскольку Windows 2000 ав томатически переносит АСЕ на существующие дочерние объекты, DACL всех объек тов, расположенных в иерархии ниже измененного объекта, также приводятся в со ответствие с каноническим порядком. В преобразованных дескрипторах безопаснос ти объектов устанавливаются управляющие флаги SE_DACL_AUTO INHERITED и SE_SACL_ALTO_INHERITED.
Перенос унаследованных АСЕ па дочерние объекты происходит по следующим пра вилам:
Х при наследовании АСЕ дочерним объектом без DACL образуется дочерний объект с DACL, содержащей только унаследованную запись управления доступом;
Х при наследовании АСЕ дочерним объектом с пустой DACL образуется дочер ний объект с DACL, содержащей только унаследованную запись управления доступом;
i Безопасность в распределенных системах 568 ЧАСТЬ Х при удалении наследуемой АСЕ из родительского объекта механизм автомати ческого наследования удаляет все копии этой АСЕ, унаследованные дочерними объектами;
Х если механизм автоматического наследования удаляет все АСЕ из DACL дочер него объекта, DACL дочернего объекта не уничтожается, а становиться пустым.
Процедуры при преобразовании тома FAT в том NTFS Когда том FAT преобразуется в том NTFS, Windows 2000 устанавливает разреше ния па всех папках и файлах преобразованного тома. Разрешения, устанавливае мые на существующих папках, показаны в таблице 12-13, а на существующих фай лах Ч в таблице 12-14. Все разрешения задаются в явно заданных АСЕ.
Таблица 12-13. DACL существующих папок после преобразования FAT в NTFS Тип Имя Разрешение Применяется Allow (Разрешить) System F u l l Control This folder only (Только для (Полный доступ) этой папки) Allow (Разрешить) Administrators Full Control (Администраторы) (Полный доступ) This folder only (Только для этой папки) Allow (Разрешить) АИ (Все) Full Control This folder, subfolders and (Полный доступ) files (Для этой папки, ее подпапок и файлов) Таблица 12-14. DACL существующих файлов после преобразования FAT в NTFS !ii Имя Разрешение A l l o w (Разрешить) System Full Control (Полный доступ) Allow (Разрешить) Administrators Full Control (Полный доступ) (Администраторы) Allow (Разрешить) All (Все) F u l l Control (Полный доступ) Только последняя запись управления доступом в DACL папки Ч наследуемая, по этому именно она наследуется новыми объектами в преобразованном томе. Б таб лице 12-15 показана DACL файлов и папок, созданных после преобразования.
Таблица 12-15. DACL новых файлов и папок после преобразования FAT в NTFS Тип Имя Разрешение Allow (Разрешить) АИ (Все) Full Control (Полный доступ) Такая DACL не создает трудностей на компьютерах под управлением Windows NT.
Однако на компьютерах под управлением Windows 2000 все не так просто. Пред положим, что некто, редактируя разрешения корня преобразованного тома, удаля ет наследуемое разрешение, предоставляющее группе Everyone (Все) полный дос туп к панке, ее под папкам и файлам. Так как в Windows 2000 изменения в наследу емых АСЕ переносятся вниз по дерену объектов, изменения в наследуемых АСЕ корневого объекта дерева распространяются на псе дерево. Объекты, существовав шие до преобразования, обладали явно установленными АСЕ, предоставляющими группе Everyone (Все) полный доступ. Эти АСЕ не были наследуемыми, поэтому на них не влияли изменения разрешений корневого объекта. После преобразова Управление доступом ГЛАВА 12 ния тома полный доступ группе Everyone (Вес) к созданным файлам и папкам пре доставляется наследуемыми АСЕ. Если эти АСЕ будут удалены из всех файлов и папок, созданных после преобразования тома, у каждого из этих объектов окажет ся пустая DACL, не предоставляющая доступа никому.
Дабы исправить эту ошибку, добавьте новую наследуемую АСЕ в корневой объект и распространите изменение вниз но дереву объектов. Однако ошибки всегда луч ше предотвращать, чем исправлять. Вы избежите проблем, поменяв наследуемые АСЕ корневого объекта на ненаслсдуемые. Это рекомендуется сделать сразу после преобразования FAT в NTFS.
^ Как избежать создания пустой DACL на преобразованном томе 1. Откройте Windows Explorer (Проводник) и найдите значок диска преобразован ного тома.
2. Щелкните значок диска правой кнопкой мыши и в контекстном меню выберите Properties (Свойства). В открывшемся диалоговом окне Properties (Свойства) перейдите к вкладке Security (Безопасность) и щелкните Advanced (Дополни тельно).
3. В открывшемся диалоговом окне Access Control Settings (Параметры управле ния доступом) на вкладке Permissions (Разрешения) дважды щелкните запись Administrators (Администраторы);
4. В поле со списком Apply to (Применить) выберите This folder, subfolders and files (Для этой папки, се подпапок и файлов).
5. Щелкните ОК.
6. На вкладке Permissions (Разрешения) дважды щелкните System (SYSTEM), 7. В поле со списком Apply to выберите This folder, subfolders and files (Для этой папки, ее подпапок и файлов).
Внимание! Не следует устанавливать флажок Reset permissions on all child objects and enable propagation of inheritable permissions (Сбросить разрешения для всех дочерних объектов и включить перепое наследуемых разрешений). Пе ренос наследуемых разрешений уже включен по умолчанию. Установка этого флажка сбрасывает управляющий флаг дескриптора безопасности SE_DACL_PROTECTED в дескрипторах безопасности всех дочерних объектов и отзывает разрешения, явно установленные на объектах. Ни одно из этих дей ствий не требуется для этой процедуры.
8. Щелкните насколько раз ОК. чтобы закрыть все диалоговые окна.
После внесения указанных изменений новые наследуемые АСЕ распространятся на дочерние объекты, находящиеся ниже корневой папки, и будут наследоваться вновь создаваемыми в этом дереве подпапками и файлами.
Проверка доступа и аудит Когда субъект пытается получить доступ к объекту, диспетчер объекта вызывает фун кцию Access CheckAnd Audit Alarm, позволяющую узнать, разрешен или запрещен до ступ, а также установлен ли аудит. Функция выполняет эту задачу в два этапа. Сна чала она определяет, запрещен или разрешен доступ для этого субъекта, а затем имеется ли необходимость создания записи аудита в журнале безопасности.
570 ЧАСТЬ 2 Безопасность в распределенных системах Проверка доступа Цель проверки доступа Ч определить, позволено ли субъекту совершить запраши ваемые им действия. Для этого используется функция AccessCheckAndAuditAlarm.
В качестве входных данных она принимает:
Х маркер доступа субъекта;
Х маску запрашиваемого доступа субъекта;
Х дескриптор безопасности объекта.
Маска запрашиваемого доступа (desired access mask) субъекта Ч это структура, дли ной 32 бита, в которой каждый бит соответствует отдельному праву доступа. Уста новленные биты указывают на запрашииаемые субъектом права, а сброшенные права, которые субъекту не требуются. Подробнее о маске доступа Ч в разделе Маска доступа ранее в этой главе.
Завершив проверку доступа, AccessCheckAndAuditAlarm возвращает диспетчеру объекта маску предоставленного доступа (granted access mask). Маска предостав ленного доступа - это 32-разрядная структура, идентичная маске запрашиваемого доступа, за исключением того, что все биты в ней изначально сброшены. В процес се проверки доступа при нахождении авторизации для каждого права, указанного в маске запрошенного доступа, бит, соответствующий этому праву, устанавливается в маске предоставленного доступа и сбрасывается в маске запрошенного доступа, После сброса всех битов в маске запрошенного доступа проверка доступа заверша ется. Маска предоставленного доступа возвращается вызывающему процессу.
При авторизации субъекта AccessCheckAndAuditAlarm следует определенным пра вилам. Они перечислены далее.
1. Если в дескрипторе безопасности объекта отсутствует DACL, маска предостав ленного доступа устанавливается равной маске запрошенного доступа, и провер ка доступа завершается. Субъект получает маску доступа, которую запрашивал.
2. Если маска запрошенного доступа пуста, проверка доступа завершается. Субъект не получает доступ к объекту.
3. Если в маске запрошенного доступа установлен бит, соответствующий праву доступа к SACL, маркер доступа субъекта проверяется на наличие привилегии Manage auditing and security log (Управление аудитом и журналом безопаснос ти) (SeSecurityPrivilege). При наличии такой привилегии в маркере доступа бит, соответствующий праву доступа к SACL, сбрасывается в маске запрошенного доступа и устанавливается в маске предоставленного доступа.
4. Если в маске запрошенного доступа установлены биты, соответствующие чте нию разрешений, смене разрешений или смене владельца, SID владельца в дес крипторе безопасности объекта сравнивается с SID в полях пользователя и групп в маркере доступа. При успешной проверке соответствующие биты сбра сываются в маске запрошенного доступа и устанавливаются в маске предостав ленного доступа.
5. Записи управления доступом (АСЕ) в DACL объекта проверяются по очереди, начиная с первой.
Х АСЕ-записи с установленным флагом наследования INHERIT_ONLY игно рируются.
Управление доступом ГЛАВА 12 Х Если идентификатор безопасности в АСЕ не совпадает ни с одним S1D в мар кере доступа субъекта, АСЕ пропускается.
Х Если АСЕ запрещает доступ, то права, которыми она управляет, сравнивают ся с правами, в маске запрошенного доступа субъекта. При совпадении хотя бы одного бита все биты в обеих масках сбрасываются, и проверка доступа завершается. Субъект не получает доступ к объекту, Х Если АСЕ разрешает доступ, права, которыми она управляет, сравниваются с правами в маске запрошенного доступа субъекта. Совпадающие биты сбра сываются в маске запрошенного доступа и устанавливаются в маске предос тавленного доступа.
Х Если в маске запрошенного доступа остались установленные биты, проверка доступа переходит к следующей АСЕ.
Х Если после завершения обработки всех записей управления доступом из DACL не все биты маски запрошенного доступа сброшены, доступ неявно запрещается. lice установленные биты в маске предоставленного доступа сбрасываются, и маска возвращается вызывающему процессу. Субъект не получает доступ к объекту.
Аудит Цель аудита создание записей успешных и/или неудачных попыток доступа к объекту в журнале безопасности. До завершения проверки доступа функция AccessC heck And Audit Alarm не знает, является ли попытка доступа успешной или неудачной, поэтому проверка доступа производится до аудита. Завершив проверку доступа, функция AccessCheckAndAudltAlarm определяет данные, которые необхо димо зарегистрировать в журнале, на основании следующей информации:
Х маркера доступа субъекта;
Х предъявленной субъектом маски запрошенного доступа;
Х маски предоставленного доступа, полученной в результате проверки доступа;
Х SACL объекта.
Проверка аудита значительно проще проверки доступа. В журнале безопасности требуется регистрировать только небольшую часть операций. Очень сложно пользо ваться журналами безопасности, содержащими слишком много информации, поэто му число отслеживаемых параметров ограничивается. Вот почему SACL обычна содержит существенно меньше записей управления доступом, чем DACL.
При обработке SACL объекта функция AccessCheckAndAuditAlarm следует опре деленным правилам.
1. АСЕ-записи с установленным флагом наследования 1NHERIT_ONLY игнориру ются.
2. Если идентификатор безопасности в АСЕ не совпадает ни с одним SID в марке ре доступа субъекта, АСЕ пропускается.
3. Если определенный бит в маске доступа АСЕ установлен, а в маске запрошен ного доступа Ч сброшен, АСЕ пропускается. Важны только записи управления доступом, права которых соответствуют правам, запрашиваемым субъектом.
572 ЧАСТЬ 2 Безопасность в распределенных системах 4. Если установлен флаг аудита SUCCESSFUL_ACCESS_ACE_FLAG, маска до ступа АСЕ сравнивается с маской предоставленного доступа. Если и в маске до ступа АСЕ, и в маске предоставленною доступа определенный бит установлен, в журнале безопасности регистрируется событие разрешения доступа.
5. Если установлен флаг аудита FAJLED_ACCESS_ACE_FLAG, маска доступа АСЕ сравнивается с маской предоставленного доступа. Если в маске доступа АСЕ определенный бит установлен, а в маске предоставленного доступа Ч сбро шен, в журнале безопасности записывается событие запрещения доступа.
6. После обработки всех записей SACL проверка аудита завершается.
ГЛАВА Обеспечение безопасности средствами технологии открытого ключа Проектирование системы безопасности, отвечающей требованиям по защите ко г фиденциальной и закрытой информации в организации, подразумевает разработку набора решений, соответствующих определенным сценариям риска. Многие ком поненты безопасности распределенных систем Microsoft Windows 2000, обеспечи вающие надежные и масштабируемые решения сетевой безопасности, работают па основе технологии открытого ключа. Понимание технологии открытого ключа, а также возможностей по обеспечению сетевой и информационной безопасности в Windows 2000 позволяет использовать их более эффективно.
В этой главе Уязвимость открытой сети Технологии безопасности в Windows 2000 Решения сетевой безопасности Стандарты технологии открытого ключа и взаимодействие программ Выбор оптимального решения безопасности Дополнительные материалы См. также Х Подробнее об основных принципах криптографии и технологиях открытого ключа, а также об ограничениях на экспорт криптографических технологий Ч в главе 14 Криптография в сетевых информационных системах.
Х Подробнее об инфраструктуре открытого ключа Windows 2000 и службах сер тификации Ч в главе 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000s>.
Х Подробнее о проектировании, тестировании и развертывании инфраструктуры открытого ключа в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000), 574 ЧАСТЬ 2 Безопасность в распределенных системах Уязвимость открытой сети Открытость современного предприятия позволяет поддерживать информационный обмен и совместную работу внутри его на невиданной ранее высоте. Вместе с тем сама природа открытых сетей затрудняет обеспечение безопасности ценных сете вых ресурсов и деловой информации.
Последний опрос, проведенный институтом Computer Security Institute (Институт компьютерной безопасности), показал, что 64% из 520 опрошенных сообщили о нарушении компьютерной безопасности на протяжении последнего года. Это на стораживает, так как это на 16% больше, чем в прошлом году. Самое тревожное, что 241 респондент сообщил о финансовых потерях, что в сумме составило 136 милли онов долларов (на 36% больше, чем в предыдущем году). Все это свидетельствует о необходимости укрепления безопасности в интрасетях и Интернете.
Сети на основе протокола IP (Internet Protocol), например частные интрасети и Интернет, обеспечивают открытую связь между пользователями и компьютерами, но их системы защиты подвергаются взломам и атакам злоумышленников. Переда ющаяся по таким сетям информация открыта для любого, имеющего к ним доступ.
Читать и изменять сообщения, пересылаемые по IP-сетях, а также нарушать рабо тоспособность этих сетей могут как легитимные сетевые пользователи, так и зло умышленники. Применяемые для этого программные средства легко доступны в Интернете. Как внутренние, так и внешние нарушители могут пользоваться откры тым характером IP-сетей чтобы:
Х похищать закрытую информацию и частные сообщения;
Х олицетворять (подменять собой) пользователей, клиенты и серверы в сети;
Х изменять информацию по пути ее следования к получателю;
Х перенаправлять информацию по другим адресам;
Х совершать атаки типа лотказ в обслуживании, использующие присущие IP-се тям уязвимые места или ошибки в реализации протокола, причиняя таким об разом вред организациям и пользователям в сетях.
Производителями программного обеспечения и сообществом Интернета разработа но множество новых технологий и стандартов для устранения указанных проблем, повышения безопасности и сохранения тайны информации в открытых сетях.
Технологии безопасности в Windows В Windows 2000 применяются разнообразные технологии безопасности распреде ленных систем, обеспечивающие на основе шифрования надежную и масштабируе мую защиту открытых и закрытых сетей. В основе многих современных техноло гий электронной криптографии лежит технология открытого ключа. Для реализа ции большинства функций безопасности открытого ключа в распределенных сис темах необходимо создание инфраструктуры открытого ключа (public key inf rastructure, PKI). В Windows 2000 она поддерживает самые разнообразные решени ях информационной безопасности па основе открытых ключей. Технологию откры того ключа можно применять вместе с другими технологиями безопасности для всесторонней защиты в интрасетях, экстрасетях и Интернете.
Эта технология применяется во многих подсистемах распределенной безопасности Windows 2000. К ее компонентам относятся:
Обеспечение безопасности средствами технологии открытого ключа ГЛАВА 13 Х проверка подлинности сетевого входа в систему с использованием протокола Kerberos v5, в том числе вход в систему со смарт-картой (допустимое расшире ние протокола Kerberos);
Х служба маршрутизации и удаленного доступа (Routing and Remote Access), под держивающая защищенный удаленный доступ к ресурсам сети, в том числе:
Х интеграцию с Active Directory, службой каталога Windows 2000, которая по зволяет управлять проверкой подлинности удаленных пользователей на ос нове сведений доменных учетных записей пользователей и параметров груп повой политики;
Х службу RADIUS (Remote Authentication Dial-in User Service), обеспечиваю щую управление аутентификацией удаленных пользователей средствами раз личных протоколов проверки подлинности;
Х проверку подлинности пользователей, па основе протокола EAP-TLS (Extensible Authentication Protocol and Transport Layer Security), который поддерживает проверку подлинности пользователей на основе сертификатов открытого ключа и входа в систему со смарт-картой;
Х защищенные соединения по общедоступным линиям Интернет, создаваемые средствами протокола L2TP (Layer 2 Tunneling Protocol) или РРТР (Point to-Point Tunneling Protocol);
Х удаленный сетевой доступ и вход в систему посредством виртуальных част ных сетей и поставщиков служб Интернета:
Х сервер IIS (Internet Information Services), поддерживающий безопасность Web узлов путем сопоставления сертификатов и создания безопасных каналов связи по протоколам SSL (Secure Sockets Layer), TLS (Secure Sockets Layer) и SGC (Server Gated Cryptography);
Х IP-безопасность (IP Security, IPScc), поддерживающую многие функции на уровне протокола IP Ч сквозную проверку подлинности, обеспечение целост ности сообщений, защиту от повторного использования пакетов и шифрование соединений в открытых IP-сетях, в том числе в Интернете;
Х шифрованная файловая система (EFS), позволяющая пользователю шифровать папки и файлы для их безопасного хранения, а администратору восстанавливать файлы в случае повреждения или потери закрытого ключа пользователя.
Кроме того, технологии безопасности распределенных систем Windows 2000 допол нены поддержкой широкого круга открытых стандартов сетевой и информацион ной безопасности, определенных в документах сообщества IETF (Internet En gineering Task Force) и других органов стандартизации. Например, инфраструктуш открытого ключа Windows 2000 основана на открытых стандартах, рекомендованных рабочей группой по инфраструктуре открытого ключи (Public Key Infrastructure, PKIX) в сообществе IEFT. Поскольку решения безопасности в Windows 2000 осно ваны на открытых стандартах, они способны взаимодействовать со многими совме стимыми по стандарту операционными системами и продуктами безопасности сто ронних поставщиков.
Безопасность па базе открытого ключа в Windows 2000 реализована на основе стан дартных промышленных технологий, таких, как алгоритм Диффи Ч Хеллмана (Diffie-Hellman), алгоритмы шифрования RSA, разработанные компанией RSA Data Security, и алгоритм цифровой подписи (Digital Signature Algorithm). В системе бе ЧАСТЬ 2 Безопасность в распределенных системах зопасности Windows 2000 также применяются цифровые сертификаты Х.509 v промышленного стандарта, создаваемые доверенными центрами сертификации. Для обеспечения проверки подлинности, целостности, конфиденциальности и невоз можности отрицания авторства в во многих компонентах Windows 2000 использу ются технологии открытого ключа и сертификаты.
Решения сетевой безопасности Windows 2000 позволяет развернуть множество различных решений информацион ной и сетевой безопасности, реализующих преимущества технологии открытого ключа и сертификатов. К этим преимуществам относятся:
Х локальная и удаленная проверка подлинности при входе в систему со смарт-кар той, использующая расширения протокола Kerberos v5 и протокол EAP-TLS;
Х проверка подлинности с применением смарт-карт и хранение сертификатов и закрытых ключей па смарт-картах;
Х система защищенной электронной почты, состоящая из клиентов и дополни тельных серверов защищенной почты, поддерживающих протокол S/MIME (Secure/Multipurpose Internet Mail Extensions);
Х безопасная связь через Интернет на основе протоколов SSL, TLS или SGC при взаимодействии с сервером IIS;
Х безопасный доступ к ресурсам Web-узлов, реализованных на основе сервера IIS, с использованием сопоставления сертификатов сетевым учетным записям пользо вателей;
Х цифровая подпись программного обеспечения, обеспечивающая подлинность и целостность программ, распространяемых в иптрасетях и Интернете;
Х защита папок и файлов путем их шифрования средствами шифрованной фай ловой системы, в том числе защита переносных компьютеров;
Х дополнительная проверка подлинности па основании сертификатов при связи но протоколу IPSec;
Х криптографическая безопасность при использовании поставщика службы безо пасности (cryptographic service provider, CSP), поддерживающего стандарт FIPS 140-1 (Federal Information Processing Standard);
Х повышение безопасности защищенной почты и безопасной связи через Интернет при помощи стандартных смарт-карт или криптографических карт FORTEZZA;
Х специальные приложения и службы сертификации для удовлетворения особых требований по безопасности.
Выпуском и управлением сертификатов занимаются центры сертификации (certification authorities, CA), или сокращенно ЦС, служб сертификации Windows или службы сертификации различных сторонних поставщиков.
Далее в этой главе мы расскажем, как использовать сертификаты и технологии бе зопасности распределенных систем Windows 2000 для повышения сетевой и инфор мационной безопасности. Подробнее об отдельных технологиях в справочной системе Microsoft Windows 2000 Server.
ГЛАВА 13 Обеспечение безопасности средствами технологии открытого ключа Защищенная почта Обычная электронная почта передается открытым текстом по незащищенным от крытым сетям. В современных сложных и развитых сетях открытость электронной почты существенно затрудняет обеспечение ее безопасности. Отслеживая почтовые серверы и сетевой трафик, злоумышленники получают возможность извлекать кон фиденциальную информацию и данные, составляющие интеллектуальную соб ственность компании. Отправляя почту через Интернет из своей компании, Вы рискуете разгласить закрытую или конфиденциальную служебную информации.
Пересылаемые через Интернет сообщения могут перехватить и прочитать не толь ко злоумышленники, вооруженные анализаторами трафика, но даже администра торы почтовых серверов и серверов-посредников, осуществляющих обработку и маршрутизацию сообщений.
Даже в организациях, политики безопасности которых запрещают пересылку за крытой служебной информации через Интернет, работники зачастую нарушают ;
ао правило. При этом не исключены ошибки адресации - и почтовые сообщения мо гут попасть в руки тех, кому доступ к содержащийся в них информации не разре шен или попросту запрещен.
Еще одна форма нарушения безопасности - олицетворение (impersonation), HIH маскарад. В IP-сетях весьма просто выдать себя за другого отправителя сообщения, попросту подменив IP-адрес отправителя и заголовок почтового отправления. При использовании обычной электронной почты никогда нельзя быть уверенным LI,гп ч ности реального отправителя сообщения и правильности его содержания. Boj ее того, злоумышленники могут нанести ощутимый вред компьютерам и сетям полу чателей, например, отправив по почте вложения с вирусами.
По этим причинам многие организации уделяют особое внимание реализации за щищенных почтовых служб, обеспечивающих конфиденциальность связи, целост ность данных и невозможность отрицания авторства сообщений. Однако до недав него времени многие из этих защищенных почтовых систем были частными (pro prietary) и широко не использовались.
Windows 2000 позволяет защитить почту для обеспечения целостности сообщений и конфиденциальности почтовой связи в Вашей организации.
Почтовые клиенты, поддерживающие стандарт S/MIME Рабочая группа по защищенной почте S/MIME (S/MIME Secure Mail working group) в сообществе IETF разработала открытый стандарт S/MIME, расширяющий оригинальный стандарт MIME (Multipurpose Internet Mail Extensions). Стандарт S/MIME поддерживает подписывание и шифрование конфиденциальной коррес понденции, что позволяет обеспечить независимость от платформы и операцион ной системы. Так как все функции шифрования выполняются самими клиентами защищенной почты, сообщения в стандарте S/M1ME пересылаются через Интер нет и не зависят от типов почтовых серверов, обрабатывающих сообщения на пути от отправителя к получателю. Почтовые серверы обрабатывают сообщения S/ MIME так же, как и стандартные MIME-сообщения, выполняя только их маршру тизацию и не изменяя их содержания.
К продуктам Microsoft, поддерживающих стандарт S/MIME, относится клиент об мена сообщениями и коллективной работы M i c r o s o f t Outlook 98 и Microsoft Outlook Express версий 4 и 5. Для обеспечения максимальной совместимости Безопасность в распределенных системах 578 ЧАСТЬ Outlook 98 и Outlook Express с другими приложениями S/MIME Microsoft сотруд ничает с рабочей группой по защищенной почте S/MIME в сообществе IETF и дру гими поставщиками. Многие популярные почтовые клиенты сторонних поставщи ков также поддерживают S/MIME.
В системе защищенной почты на базе протокола S/MTME используются сертифи каты Х.509 v3 промышленного стандарта и технология открытого ключа. Для обес печения проверки подлинности сообщений, целостности данных и невозможности отрицания их авторства применяется подписание сообщения закрытым ключом отправителя. Получатель сообщения применяет открытый ключ отправителя для проверки цифровой подписи и подлинности сообщения. Для создания подписан ных сообщений клиентам необходимо получить действительный сертификат защи щенной почты. Чтобы удостовериться ц авторстве подписи, получатели должны иметь экземпляр сертификата защищенной почты отправителя. В сертификате со держится отрытый ключ того, кому этот сертификат выдан.
Кроме того, клиенты системы защищенной почты способны отправлять и получать конфиденциальную корреспонденцию. Для обеспечения конфиденциальности они создают случайные секретные ключи сплошного симметричного шифрования, ко торые и применяют для шифрования сообщений. Затем секретный ключ сплошно го шифрования защищается путем шифрования его открытым ключом получателя и зашифрованный ключ вместе с зашифрованным сообщением пересылается полу чателю. Для отправки конфиденциальной корреспонденции автор сообщений дол жен иметь экземпляр сертификата защищенной почты получателя с открытым клю чом этого получателя. Получатель расшифровывает секретный ключ сплошного шифрования своим закрытым ключом и с помощью последнего расшифровывает само сообщение.
Подробнее о шифровании симметричным ключом, шифровании открытым ключом и цифровых подписях в главе 14 Криптография в сетевых информационных системах.
Клиенты защищенной почты Защищенная почта гарантирует, что целостность сообщений отправителей не бу дет нарушена и прочесть ее смогут только те получатели, которым она предназна чена. Кроме того, получатели уверены в подлинности сообщения и авторстве от правителя. Для нормальной работы защищенной почты необходимо наличие у каж дого почтового клиента действительного сертификата защищенной почты, клиен ты же должны доверять корневому ЦС в пути сертификации сертификата своего корреспондента. Для облегчения распространения сертификатов и общих ключей сертификаты публикуются в каталогах LDAP (Lightweight Directory Authentication Protocol), общих папках и па Web-страницах. В Windows 2000 сертификаты защи щенной почты публикуются в Active Directory в учетных записях, их получивших.
Кроме того, разрешается публикация сертификатов в общих папках, на Web-стра ницах или в других службах каталога, совместимых с LDAP. Для этого достаточно настроить параметры служб сертификации. Пользователи с поддерживающими LDAP почтовыми клиентами, например Outlook 98 или Outlook Express, получают возможность обращаться к службам каталога для поиска и получения опублико ванных сертификатов своих потенциальных корреспондентов.
Клиенты защищенной почты должны доверять сертификатам своих корреспонден тов. Вы можете настроить защищенную почту своей организации для доверия сер Обеспечение безопасности средствами технологии открытого ключа ГЛАВА 13 гификатам защищенной почты, выпущенным как собственным внутрикорпоратив ным центром сертификации, так и сторонними центрами сертификации. Сузив зону доверия до корневого ЦС своей организации. Вы ограничите возможность пользо вания защищенной почтой: защищенными сообщениями смогут обмениваться толь ко сотрудники Вашего предприятия. Для обмена защищенными почтовыми сооб щениями со сторонними организациями следует разрешить доверие их корневому ЦС защищенной почты.
Надежность шифрования, обеспечиваемая защищенной почтой, зависит от ограни чений на экспорт или импорт криптографических технологий из США. Длина клю ча шифрования доступная Вашим почтовым клиентам, зависит от ограничений на криптографические технологии, которые применяются в регионах, где эти почто вые клиенты устанавливаются. Обычно почтовые клиенты, использующие разре шенную к экспорту технологию, обеспечивают более слабую защиту, чем клиенты, применяющие не подлежащие экспорту криптографические технологии, Сертификаты для таких совместимых с S/M1ME клиентов защищенной почты, как Outlook 98 или Outlook Express, обычно выпускают службы сертификации. Для приема заявок и выпуска сертификатов защищенной почты через Интернет следу ет установить Web-страницы для подачи заявок через Интернет (Web Enrollment Support).
Кроме того, для управления защищенной почтой применяются почтовые службы, например Microsoft Exchange Server версии 5.5 - клиент-серверное приложение поддержки обмена сообщениями и коллективной работы. Для управления приемом заявок на сертификаты защищенной почты в службе сертификации устанавливает ся Exchange Server с компонентом Key Management server (KMS), который можно использовать для восстановления ключей, как это описано в следующем разделе.
Подробнее о доверии центрам сертификации и путях сертификации Ч в главе Службы сертификации и инфраструктура открытого ключа в Windows 2000.
Управление ключами и службы восстановления ключей Так как операции защищенной почты в S/MIME выполняются на стороне клиента, в данном стандарте нет требований по управлению или восстановлению ключей.
Тем не менее для восстановления ключей защищенной почты, которые не исполь зуются для подписания сообщений, Вы можете воспользоваться службой управле ния ключами, например KMS. Службы восстановления ключей хранят копии клю чей (кроме ключей, применяемых для подписания) в центральной защищенной базе данных, откуда их при необходимости извлекают и возвращают владельцам только авторизованные администраторы. Для обеспечения конфиденциальности ключи хранятся и передаются в защищенной паролем зашифрованной форме.
Внимание! Наличие копии ключа подписания компрометирует проверку подлинно сти, а также целостность и невозможность отрицания авторства, обеспечиваемые этим ключом. Злоумышленники, получившие доступ к дубликату, могут выступать от лица владельца, подписывая и отправляя поддельные сообщения. Поэтому зак рытые ключи, использующиеся для цифровой подписи, надо запретить копировать (экспортировать) или хранить в какой-либо системе восстановления ключей.
Пользователь не сможет прочитать шифрованное сообщение, если его закрытый ключ поврежден или разрушен и в системе не предусмотрено восстановление клю Безопасность в распределенных системах 580 ЧАСТЬ чей. Предположим, что у пользователя защищенной почты вышел из строя жест кий диск, а ему продолжают отправлять шифрованные сообщения. Если возмож ности восстановить потерянный закрытый ключ нет, пользователь так и не сможет прочесть эти сообщения. Для предупреждения такой ситуации не подписывающие закрытые ключи, используемые системами восстановления ключей, следует хранить в защищенной базе данных по крайне мере до истечения срока действия соответ ствующих сертификатов защищенной почты. По окончании срока действия серти фиката закрытый ключ больше не применяется для обмена защищенной почтой.
Закрытые ключи защищенной почты служат для шифрования секретных ключей сплошною шифрования (bulk encryption keys), которые в свою очередь используют ся для шифрования корреспонденции и цифрового подписания сообщении. В от сутствие системы восстановления ключей допустимо применять один и тот же сер тификат как для шифрования, так и для подписания сообщений. Однако при нали чии такой службы восстановления ключей, клиент должен иметь два сертификата:
один Ч только для шифрования корреспонденции, а второй Ч только для подписа ния сообщений. Закрытый ключ шифрования корреспонденции разрешается экс портировать и хранить для восстановления. Закрытый ключ подписания экспорти ровать и хранить в службе восстановления ключей нельзя.
Несмотря на то, что в инфраструктуре открытого ключа Windows 2000 нет особых возможностей восстановления ключей и выделенных служб для запроса сертифи катов для защищенной почты, в состав Exchange Server 5.5 входит собственный сер вер KMS, управляющий обработкой запросов на сертификаты и восстановлением закрытых ключей. KMS поддерживает защищенную базу данных восстановления ключей, содержащую все закрытые ключи сертификатов защищенной почты. Зак рытые ключи хранятся до истечения срока действия сертификата или до его отзы ва, после чего использование открытого ключа прекращается. Администраторы при меняют KMS для восстановления закрытых ключей и их безопасного возвращения владельцам (например, в случае повреждения закрытого ключа на компьютере вла дельца). Начиная с версии 5.5 Exchange Server с установленным Service Pack 1, со держащийся в нем сервер KMS для выпуска сертификатов защищенной почты ис пользует службы сертификации. В более ранних версиях сервера Exchange службы сертификации не применялись, а К MS издавал теперь уже устаревшие сертифика ты стандарта Х.509 vl. Для работы служб сертификации совместно с Exchange сле дует установить ЦС и модуль политики Exchange (Exchange Policy module). ЦС ис пользует этот модуль для выпуска сертификатов защищенной почты в ответ на за просы сертификатов от KMS.
Подробнее о модуле политики Exchange и об использовании службы сертифика ции с Exchange Server в справочной системе служб сертификации и в справоч ной системе Exchange Server.
Безопасная связь через Интернет Связь через Интернет, в основе которой лежат такие протоколы семейства TCP/IP (Transfer Control Protocol/Internet Protocol), как HTTP (Hypertext Transfer Pro tocol), Telnet и FTP (File Transfer Protocol), не является безопасной, так как осуще ствляется открытым текстом. Передаваемую при помощи этих протоколов конфи денциальную и важную информацию перехватить и прочитать достаточно легко, если, конечно, она не защищена посредством шифрования.
Обеспечение безопасности средствами технологии открытого ключа ГЛАВА 13 Кроме того, поскольку Web-сервер доступен любому Web-клиенту по протоколу HTTP, клиенты способны использовать во вред слабую защищенность этого прото кола или одной из его реализаций. Серверы, поддерживающие только стандартный HTTP, являются легкими мишенями для разного рода атак, самая популярная из которых Ч лотказ в обслуживании (Denial of service, DoS). Клиенты, использую щие стандартный HTTP, также легко становятся жертвами подставных серверов, имитирующих настоящие Web-узлы, па которых содержится предназначенное для загрузки программное обеспечение. Такие подставные серверы могут распрост ранять зараженные вирусами программы или вредоносные сценарии.
Для обеспечения в организации защищенных каналов связи через Интернет, обес печивающих целостность и конфиденциальность данных, рекомендуется использо вать Web-сервер IIS (Internet Information Services) в составе Windows 2000. Под робнее об IIS Ч в справочной системе fIS и книге Microsoft Internet Information Services 5.0 Resource Guide (Microsoft Press, 2000).
Протоколы для безопасной связи через Интернет Протоколы защищенной связи через Интернет позволяют проверять подлинность клиентов и серверов и обеспечивать конфиденциальность связи между ними. Для этих целей разработаны различные стандарты безопасной связи, использующие тех нологию открытых ключей. В их числе протокол SHTTP (Secure Hypertext Transfer Protocol), IP-безопасность (IP Security, IPSec), РРТР и L2TP. Самые популярные протоколы безопасной связи в Интернете для общих целей Ч это SSL 3.0 и откры тый протокол TLS, созданный па основе SSL. Протоколы SSL и TLS широко при меняются для организации защищенных каналов защищенной связи но протоколу TCP/IP в Интернете.
Однако SSL и TLT не лишены недостатков - на длину ключа шифрования в защи щенных каналах налагаются ограничения (правительственные ограничения на экс порт и импорт криптографических технологий). Например, длина ключа симмет ричного шифрования для запрещенных к экспорту технологий значительно боль ше (128 бит), чем для разрешенных (40 или 56 бит). При работе по защищенному каналу серверы и клиенты должны использовать ключи шифрования одинаковой длины и одинаковые криптографические алгоритмы. В начале сеансов по протоко лу SSL и TLT сервер выбирает максимально надежную технологию, доступную и серверу, и клиенту. Максимальная зашита связи по протоколам SSL и TL.S возмож на только между серверами и клиентами, поддерживающими надежное шифрова ние по запрещенной к экспорту технологии.
Для защиты связи через Интернет с банками и прочими финансовыми учреждени ями разработаны специальные протоколы с надежным шифрованием, не нйгтдаю щие под экспортно-импортные ограничения на криптографию. Правомочные уч реждения используют эти специальные протоколы для надежного шифрования транзакций в Интернете, обходя при этом экспортно-импортные ограничения, при меняющиеся в отношении протоколов SSL л TLS. Два самых популярных протоко ла защищенной связи в Интернете этого типа Ч SET (Secure Electronic Transaction) и SGC (Server Gated Cryptography). IIS поддерживает SGC. Компонент Бумажник Microsoft (Microsoft Wallet) в браузере Microsoft Internet Explorer 5 поддерживает протокол SET.
Протокол SGC является расширением SSL. Чтобы задействовать на Web-сервере шифрование 128-битным ключом, необходимо получить специальный сертификат Безопасность в распределенных системах 582 ЧАСТЬ SGC. Internet Explorer и многие другие Web-клиенты поддерживают SGC как в раз решенных, так и в запрещенных для экспорта версиях. Клиентам сертификаты для связи по протоколу SGC не нужны. Однако для применения SGC с Web-сервером Вам необходимо получить серверный сертификат SGC, выпущенный уполномочен ным коммерческим ЦС. Выдавая такой сертификат, ЦС подтверждает Ваше право работать по протоколу SGC. В настоящее время многим финансовым и некоторым другим учреждениям разрешено подучать сертификатов SGC. Подробнее о SGC и учреждениях, уполномоченным выдавать сертификаты SGC, - на Web-странице Web Resources по адресу webresources, ссылка Microsoft Security Advisor.
Преимущества безопасной связи через Интернет Далее перечислены преимущества использования протоколов SSL и TLS для защи щенной связи через Интернет.
Х Проверка подлинности сервера на основе серверного сертификата. Клиенты идентифицируют серверы по сертификатам и отдают предпочтение серверам, подлинность которых возможно проверить. Клиенты легко обнаруживают по пытки подменить подлинный Web-сервер.
Х Дополнительная взаимная проверка подлинности между серверами и клиента ми на основе доверенных сертификатов, причем такими сертификатами облада ют обе стороны. Как серверы, так и клиенты вправе отдавать предпочтение толь ко сертификатам, которые выпушены определенными ЦС.
Х Конфиденциальная связь через Интернет по защищенному шифрованием кана лу. Сервер и клиент договариваются о применении определенных криптографи ческих алгоритмов и о секретном общем ключе сеанса безопасной связи. По умолчанию для безопасной связи применяется секретный ключ сеанса макси мальной длины, которую поддерживает как сервер, так и клиент. Параметры IIS позволяют настроить сервер для обязательного использования надежных 128 разрядпых ключей сеанса или разрешить защиту связи более коротким ключом, который поддерживают Web-клиенты, использующие разрешенные к экспорту криптографические технологии, Х Обеспечение целостности данных при помощи алгоритма НМАС (Hash Message Authentication Codes). Злоумышленник не в состоянии исказить данные, так как вместе с информацией передаются выборки из сообщения (digest), значения ко торых проверяются до обработки самой информации клиентом или сервером.
Сервер IIS и связь через Интернет В состав Windows 2000 входит сервер ITS, позволяющий развертывать Web-узлы в интрасстях, экстрасетях и Интернете. Настройка параметров и управление Web-уз лами, в том числе настройка поддержки протоколов SSL и TLS, выполняется сред ствами оснастки Internet Information Services.
При безопасной связи через Интернет с односторонней проверкой подлинности сервера клиентом действительный сертификат проверки подлинности должен быть только у сервера, при взаимной проверке подлинности действительные сертифика ты должны иметь оба участника, в противном случае защищенный канал создать не удастся.
ГЛАВА 13 Обеспечение безопасности средствами технологии открытого ключа Сертификаты, выпущенные службами сертификации Windows 2000, используются для процедур проверки подлинности таких клиентов и серверов, как Internet Explorer и IIS, а также многих других Web-серверов и Web-клиентов. Для создания безопасных каналов разрешается также использовать сертификаты, выпускаемые службами сертификации других производителей.
Очень часто для сокращения расходов на службы сертификации предприятия со здают собственные центры сертификации. В этом случае управление доверием сер тификатов выполняет сама организация. Вместе с тем клиенты защищенной связи в Интернете обычно более склонны доверять серверным сертификатам, выданным коммерческими центрами сертификации, чем ЦС Вашей организацией. К тому же, управление собственными службами сертификации для поддержки проверки под линности Web-клиентов Интернета зачастую оказывается не таким уж и дешевим.
Поэтому для связи в Интернете сертификаты проверки подлинности Web-сервера рекомендуется получать у коммерческих ЦС. Что же касается Web-клиентов, дове рять следует сертификатам проверки подлинности клиента, полученным у ведущих коммерческих ЦС.
Когда настройка IIS требует обязательного использования сертификатов проверки подлинности клиента, доступ к Web-узлу получат только клиенты, сертификаты проверки подлинности которых действительны, а сертификат корневого ЦС в пути сертификации размещен в хранилище Trusted Root Certification Authorities (Дове ренные корневые центры сертификации). Кроме того, возможно создавать списки доверия сертификатов (certificate irust list, CTL). в которых указываются дру. не доверенные ЦС данного Web-узла. Так как корневые ЦС, сертификаты которых размещены в хранилище доверенных корневых центров сертификации, могут вы полнять широкий круг функций, то для установления доверия стороннему корне вому ЦС предпочтительнее использовать списки CTL. Например, создавайте от дельный список CTL, определяя доверие сертификатам проверки подлинности кли ентов, выпущенных ЦС деловых партнеров или коммерческими ЦС.
Варианты безопасной связи через Интернет Конфигурация сервера Internet Information Services по умолчанию предусматрина ет проверку подлинности сервера клиентами, причем самим клиентам нет необхо димости иметь сертификат и проходить проверку подлинности на сервере. Вы впра ве запретить I1S обслуживать клиентов без действительных и доверенных серти фикатов, что существенно снизит риск DoS-атак, а также использовать защищен ные каналы как для всех передаваемых через Интернет данных, что позволит за щитить всю передаваемую информацию, так и для их части Ч например, данных определенного типа, таких как личная информация или номера кредитных карт.
Обычно клиенты Web-узлов в Интернете используют самые разнообразные бр&у зеры, некоторые из них поддерживают надежное шифрование, а другие Ч нет, B U S протоколы SSL и TLS по умолчанию устанавливаются в конфигурации, которая позволяет (при невозможности использовать устойчивое шифрование) применять в защищенных каналах не самое надежное шифрование, поддерживаемое браузе ром пользователя.
Также можно сконфигурировать Web-узлы на поддержку только шифрования ло протоколам SSL и TLS ключом максимальной 128-битной длины, при этом авто матически будут лотсекаться Web-клиенты, не поддерживающие такого устойчи вого шифрования. Например, разрешается настроить ITS для поддержки устойчп Безопасность в распределенных системах 584 ЧАСТЬ вого шифрования в Интраиете или экстрасетях. Естественно, что в этом случае в Вашей организации надо установить Web-клиенты и Web-серверы, поддерживаю щие шифрование ключом максимальной длины, При наличии соответствующего разрешения на применение протокол SGC разре шается использовать в Интернете для шифрования 128-битным ключом соедине ний с клиентами, поддерживающими SGC. Чтобы применить протокол SGC на сер вере IIS, необходимо получить серверный сертификат SGC у коммерческого ЦС или настроить 11S для протоколов SSL, TLS и SGC (SGC -- если его поддерживает Web-клиент, в противном случае - SSL или TLS).
Применение защищенных каналов подразумевает, что операции шифрования и рас шифровки информации выполняются как на сервере, так и на клиенте. Большин ство современных клиентских компьютеров легко справляется с вычислительной нагрузкой, создаваемой этими операциями. Однако одновременная поддержка мно гочисленных защищенных каналов способна существенно загрузить Web-сервер.
Чтобы этого не происходило и чтобы повысить производительность Web-серверов, обслуживающих защищенные каналы, рекомендуется применять быстрые много процессорные компьютеры и платы криптоакселераторов. Другой вариант решения этой проблемы Ч создать Web-узел, в котором защищенные каналы используются для доступа только к части информационного наполнения. Например, только для пересылки данных из форм ввода конфиденциальных данных, таких, как номера кредитных карт или информация о заработной плате.
Безопасный доступ к ресурсам Web-узлов Избирательная настройка параметров безопасности Web-узла выполняется сред ствами оснастки Internet Information Services, как для всего Web-узла в целом, так и для его отдельных папок и файлов. После определения общих параметров безо пасности для всего Web-узла добавляются дополнительные требования безопасно сти, применяемые к отдельным папкам и файлам. Internet Information Services под держивает следующие методы управления доступом к ресурсам Web-узла:
Х анонимный доступ;
Х доступ с проверкой подлинности;
Х доступ на основе IP-адресов и доменных имен;
Х доступ на основе сопоставления сертификатов учетным записям пользователей.
Кроме того, для управления доступом к ресурсам Web-узла, размещенных на томах файловой системы NTFS, в Internet Information Services используются списки уп равления доступом (access control list, ACL).
Анонимный доступ Когда Internet Information Services настроен на поддержку анонимного доступа, сер вер разрешает соединения любых пользователей Интернета под анонимной госте вой учетной записью, в качестве которой может применяться любая действитель ная учетная запись пользователя Windows 2000.
Для анонимного доступа в Windows 2000 Server существует встроенная локальная учетная запись IUSR_5eroer, где Server - имя компьютера-сервера, на котором ус тановлен IIS. Для Web-узлов с анонимным доступом в I1S задан стандартный на бор прав и разрешений пользователей. Например, по умолчанию учетная запись Обеспечение безопасности средствами технологии открытого ключа ГЛАВА 13 WSR_Server дает обычным пользователям разрешение на чтение большинства ре сурсов Web-узла, а администраторам и системам Ч полный доступ ко всем ресур сам Web-узла. Вместо учетной записи lUSR_Sen>er администратор вправе задать другую пользовательскую учетную запись, предназначенную для пользователей анонимного доступа.
Обычно при разрешенном анонимном доступе пользователей для входа в систему и запроса Web-ресурсов имени пользователя и пароля не требуется. Однако рекви зиты пользователя обязательны, если в списках управления доступом запрашивае мых ресурсов установлены ограничения на доступ. Анонимный доступ обычно при годен для Web-узлов содержащих общедоступную информацию, но не конфиден циальную информацию или информацию, составляющую коммерческую тайну.
Доступ с проверкой подлинности Когда IIS сконфигурирован на доступ с проверкой подлинности, для получения доступа к запрашиваемым Web-ресурсам пользователь обязан вводить свои реюш зиты имя действительной учетной записи пользователя Windows и пароль. Па раметры проверки подлинности определяют, в каком виде пересылается пароль пользователя по сети - как открытый текст, как выборка из сообщения или как зашифрованный текст. Доступ с проверкой подлинности пригоден для Web-узлов с низким уровнем безопасности. Гораздо большую безопасность обеспечивают ка налы, защищенные протоколами SSL и TLS, а также механизм сопоставления сер тификатов.
Доступ на основе IP-адресов и доменных имен Для предоставления или запрещения доступа к определенным Web-ресурсам раз решается использовать IP-адреса и доменные имена, при этом создаются списки отдельных компьютеров или их групп, которым доступ предоставляется или запре щается в зависимости от адреса подсети или доменного имени. Вместе с тем слиш ком частое использование доменных имен снижает производительность Web-сер вера из-за необходимости выполнения запросов DNS. Такое управление доступом не обеспечивает надежной безопасности, так как клиентский IP-адрес или домен ное имя легко подделать. Безопасность еще более снизится при предоставлении доступа к Web-узлу с IP-адресов или доменных имен прокси-серверов, так как в этом случае разрешение на доступ распространится на всех клиентов, соединяю щихся через эти серверы, Сопоставление сертификатов учетным записям пользователей Для управления доступом к избранным Web-ресурсам применяется механизм сопос тавления (mapping) сертификатов учетным записям пользователей Windows 2000.
Таким образом обеспечивается высокая степень безопасности, основанной на нали чии у Web-клиента действительного сертификата для проверки подлинности. В конфигурации с поддержкой сопоставления сертификатов сервер Internet Information Services проверяет подлинность пользователей по сопоставленным сер тификатам и предоставляет им права и разрешения соответствующих учетных за писей. Существует два типа сопоставления сертификатов: однозначное (one-to-one mapping) и множественное (many-to-one mapping).
Однозначное сопоставление сертификат сопоставляется соответствующей учет ной записи пользователя Windows 2000 Ч владельца этого сертификата. Сервер 11S Безопасность в распределенных системах 586 ЧАСТЬ проверяет подлинность пользователей по имеющимся сертификатам и предоставля ет права и разрешения согласно данным соответствующей учетной записи пользова теля. Однозначное сопоставление поддерживается только для клиентов с учетны ми записями пользователей Windows 2000.
Множественное сопоставление Ч создаются правила, определяющие критерии со поставления сертификата. Информация в пользовательских сертификатах, напри мер название организации пользователя и выпускающего ЦС (issuing CA), проверя ется на предмет соответствия правилам и критериям сопоставления. При положи тельном результате проверки пользователи сопоставляются определенной учетной записи, заранее указанной администратором. При множественном сопоставлении управление пользовательскими правами и разрешениями для ресурсов Web-узла осуществляется при помощи прав и разрешений, предоставленных сопоставляемой учетной записи. В IIS также можно запретить доступ к Web-узлу пользователям, сертификаты которых соответствуют определенным правилам сопоставления. Мно жественное сопоставление применяют для управления доступом любых Web-кли ентов, владеющих действительными сертификатами для проверки подлинности.
Например, предоставлять доступ к ресурсам Web-узлов экстрассти при наличии у Web-клиента сертификата определенного типа, выпущенного конкретным коммер ческим ЦС или ЦС делового партнера, Администрирование однозначных сопоставлений требует больше усилий, чем управ ление множественными сопоставлениями. Поэтому для определения однозначных сопоставлений большого количества клиентов рекомендуется разработать специали зированные Web-страницы на базе технологии ASP (Active Server Pages), позволяю щие автоматизировать процесс сопоставления. Подробнее о создании специализиро ванных Web-страниц для приема запросов на автоматическое сопоставление серти фикатов - на Web-странице Web Resources по адресу windows2000/reskit/wcbresources, ссылка Microsoft Platform SDK.
Дополнительно использовать множественное сопоставление для управления досту пом к Web-узлу следует, лишь когда это оправдано. Однозначное сопоставление следует применять при относительно малом числе клиентов, например для предо ставления доступа к Web-узлу нескольким администраторам, а множественное со поставление остальным сотрудникам Вашей организации, некоторым консуль тантам и отдельным сотрудникам предприятий-партнеров.
Отдельные множественные сопоставления применяют для конкретных групп, ко торым предоставляется доступ к Web-узлу. Вы вправе создавать отдельные пользо вательские учетные записи, предоставляющие различные права и разрешения в за висимости от наличия у клиента тех или иных действительных сертификатов. На пример, сертификаты работников организации сопоставить пользовательским учет ным записям, разрешающим чтение всех ресурсов Web-узла, а сертификаты работ ников предприятий-партнеров Ч учетным записям, предоставляющим доступ толь ко к неконфиденииальной информации и к части информации, составляющей ком мерческую тайну.
Списки управления доступом NTFS Списки управления доступом NTFS дополняют механизм безопасности Web-узлов.
Когда ресурсы Web-узлов располагаются на томах файловой системы NTFS, права и разрешения на доступ пользователей к ним устанавливаются в ACL файловой системы. Изменяя параметры этих списков, Вы можете управлять доступом к от дельным Web-узлам, папкам или файлам. Для предоставления прав и разрешений Обеспечение безопасности средствами технологии открытого ключа ГЛАВА пользовательским учетным записям и группам безопасности зачастую применяют Windows Explorer (Проводник Windows). Если и ACL установлены ограничения на доступ к папкам и файлам, IIS попросит пользователя ввести свои реквизиты Windows 2000 для прохождения проверки подлинности доступа, даже если для за прашиваемого ресурса установлен анонимный доступ. Так как этот вид защиты не доступен в файловых системах FAT или FAT32, для обеспечения дополнительной защиты папок и файлов средствами NTFS на Web-узлах рекомендуется использо вать именно эту файловую систему.
Подписанное программное обеспечение Программное обеспечение, загружаемое пользователями из Интернета на ПК, мо жет содержать программы (вирусы, троянские программы), созданные для пред намеренного нанесения вреда или получения нелегального доступа к сети. По мере дальнейшего распространения сетей вредоносные программы и вирусы способны представлять угрозу не только для отдельных компьютеров, но и для целых иитра сетей. Один из способов борьбы с этой опасностью Ч применение цифровой под писи на распространяемом в иптрасетях и Интернете программном обеспечении, что гарантирует его целостность и подтверждает авторство разработчика или рас пространителя. Подписание позволяет пользователям проверить происхождение программ и убедиться в отсутствии подлога или модификации.
Microsoft разработала технологию Microsoft Authenticode, позволяющую разработ чикам ставить цифровую подпись па созданное программное обеспечение. Неш>с редственно перед выпуском программ разработчики снабжают их цифровой под писью. После этого при любых изменениях в программе эта цифровая подпись ста новится недействительной. Разработчики, применяющие технологию Authenticode и обладающие сертификатами Х.509 v3 для подписания кода, подписывают про граммное обеспечение при помощи собственных закрытых ключей. В технологиях подписания кода сторонних поставщиков для этих целей также используются циф ровые сертификаты.
Подписание кода внутри организации Исполняемые программы, сценарии и элементы управления ActiveX, распространя емые в доменах Windows 2000, следует снабжать цифровой подписью доверенных разработчиков. Для защиты сети от вредоносных программ и вирусов в браузере Internet Explorer предусмотрено определение параметров безопасности для несколь ких зон безопасности - Internet (Интернет), Local intranet (Местная интрасеть), Trusted sites (Надежные узлы) и Restricted sites (Ограниченные узлы)..В любой зоне Вы можете запретить пользователям загрузку и запуск неподписанного программно го обеспечения и, кроме того, настроить Internet Explorer для доверия определенным издателям программного обеспечения и для автоматической загрузки без уведомле ния пользователей любых программ, снабженных цифровой подписью таких издате лей. Подробнее о безопасности Internet Explorer - в книге Microsoft Internet Explorer 5 Resource Guide (Microsoft Press 2000).
В групповой политике открытого ключа (Public Key Group Policy) разрешается ука зывать доверенные в Вашей организации ЦС, выпускающие сертификаты подпи сания кода. Можно разрешить доверие сертификатам издателя программного обес печения, выданным коммерческими ЦС или ЦС Вашей организации. Кроме того, для управления доверия сертификатам подписания кода в домене применяются списки CTL.
ЧАСТЬ 2 Безопасность в распределенных системах Одна ид функций службы сертификации -- выпуск сертификатов, разрешающих разработчикам подписывать программное обеспечение, предназначенное для рас пространения в интрасети Вашей организации.
Подписание кода в Интернете Когда программное обеспечение распространяется в Интернете, пользователи бо лее склонны доверять программам, подписанным издателем, чей сертификат под писания кода (лсертификат издателя программного обеспечения) выпущен извес тным и хорошо зарекомендовавшим себя коммерческим ЦС. Обращение к коммер ческим ЦС также избавляет Вашу организацию от ответственности при работе в качестве коммерческого ЦС, поддерживающего распространение программного обес печения сторонних производите/сей. Поэтому при распространении программного обеспечения через Интернет рекомендуется пользоваться услугами коммерческого ЦС для выдачи сертификатов цифровой подписи своим внешним разработчикам.
Не забудьте также предусмотреть специальные меры защиты закрытых ключей, необходимых для подписания кода, так как злоумышленник получивший доступ к такому ключу сможет подписать низкосортный или вредоносный код, что нанесет вред репутации Вашей фирмы. Отдельные сторонние поставщики предлагают ре шения на смарт-картах, поддерживающие подписание кода. Одно из таких реше ний стоит применить, чтобы обеспечить смарт-картами разработчиков, ответствен ных за подписание кода. Таким образом, Вы дополнительно защитите закрытые ключи подписания кода.
Автоматизация подписания кода и распространения программного обеспечения Для автоматизации подписания кода и распространения программного обеспечения как в пределах отдельной организации, так и на внешних Web-узлах, Вы вправе создавать специальные приложения. Если внутренние и внешние разработчики или те, кто отвечают за распространение программ, обладают действительными серти фикатами подписания кода, то они могут использовать эти приложения для авто матического подписания и подготовки кода перед распространением. Развертыва ние приложений подписания кода подразумевает:
Х установку ЦС, выпускающих сертификаты подписания кода или подписку на службы сертификации, предоставляемые коммерческими ЦС;
Х разработку специализированных приложений подписания кода и распростране ния программного обеспечения;
Х выпуск сертификатов подписания кода для назначенных разработчиков и лиц, ответственных за распространение программ;
Х конфигурирование инфраструктуры и служб распространения программного обеспечения.
Например, Web-узлы для подписания кода и распространения программного обес печения создаются на базе сервера IIS и специализированных страниц Active Server Pages. Для предоставления доступа к Web-узлу пользователям с действительными сертификатами подписания кода Вы можете воспользоваться однозначным сопос тавлением. В этом случае пользователи без действительных сертификатов не полу чат доступа к узлу и пе смогут предоставлять свой код для подписания и распрост ранения.
ГЛАВА 13 Обеспечение безопасности средствами технологии открытого ключа Обеспечение безопасности средствами шифрованной файловой системы В состав Windows 2000 входит шифрованная файловая система (Encrypting File System, EPS) - технология безопасности, позволяющая пользователям шифровать свои файлы, для сохранения их конфиденциальности.
В EFS для обозначения шифрованных файлов применяется атрибут шифрования.
Если такой атрибут установлен, EFS хранит файл в виде зашифрованного текста.
Когда уполномоченный пользователь открывает зашифрованный файл в приложе нии, EFS в фоновом режиме расшифровывает этот файл и предоставляет его при ложению в виде открытого текста. Пользователь, обладающий соответствующими полномочиями, в состоянии просматривать и изменять файл, a EFS прозрачно со храняет все изменения в зашифрованном виде. Другим пользователям просмотр и изменение файлов, зашифрованных EFS недоступны. EFS защищает файлы посред ством сплошного шифрования, обеспечивая защиту от злоумышленников, способ ных прочитать файлы средствами низкоуровневого доступа к диску.
EFS работает в фоновом режиме на системном уровне, но приложения могут со хранять временные файлы в виде открытого текста в незащищенных шифрованной файловой системой файлах и этим непреднамеренно нарушать конфиденциаль ность, Чтобы этого не произошло, шифрование обычно применяется на уровне па пок, а не на уровне файлов. Это означает, что средства EFS следует применять не к отдельным файлам, а к специально выделенным для этого папкам. Все файлы, до бавляемые и создаваемые в защищенной EFS папке, шифруются автоматически.
Установка защиты папки средствами EFS выполняется средствами диалогового окна свойств папки в Windows Explorer (Проводник Windows).
Шифрованная файловая система поддерживается только версией NTFS для Win dows 2000 и не работает с другими файловыми системами, в том числе и с преды дущими версиями NTFS. Подробнее об EFS Ч в главе 15 Шифрованная файловая система*.
Шифрование файлов и технология открытого ключа Для нормальной работы EFS требуется наличие у пользователя действительного пользовательского сертификата EFS и по крайней мере одной учетной записи аген та восстановления EFS с действительным сертификатом. Для выпуска сертифика тов шифрованной файловой системы центр сертификации не нужен - EFS авто матически создает собственные сертификаты для пользователей и учетных запи сей агентов восстановления по умолчанию. Закрытые ключи EFS создаются и уп равляются средствами интерфейса CryptoAPI (Microsoft Cryptographic Application Programming Interface) совместно с поставщиком службы криптографии (CSP) Microsoft Base CSP.
При шифровании файла EFS выполняет следующие операции:
1. создает ключ сплошного симметричного шифрования;
2. шифрует файлы ключом, созданным па этапе 1;
3. шифрует ключ сплошного шифрования открытым ключом пользователя EFS;
Х1. размещает зашифрованный ключ сплошного шифрования в специальном поле защищаемого EFS файла - поле расшифровки данных (data decryption field, DDF).
Безопасность в распределенных системах 590 ЧАСТЬ В дальнейшем при обращении к файлу BFS применяет закрытый ключ пользовате ля для расшифровки ключа шифрования файла, после чего расшифровывается сам файл. Так как закрытый ключ есть только у пользователя, содержимое поля DDF недоступно никому другому.
Кроме того, назначенные агенты восстановления способны расшифровывать и вос станавливать файлы при утере или повреждении закрытого ключа пользователя.
Для каждого назначенного агента восстановления EFS выполняет следующие опе рации:
1. шифрует ключ шифрования файла открытым ключом из сертификата агента восстановления;
2. сохраняет зашифрованный ключ сплошного шифрования в специальном поле защищенного EFS файла в поле восстановления данных (data recovery field, DRF).
Поле восстановления данных может содержать информацию нескольких агентов восстановления. Каждый раз по завершении операции файловой системы с файлом (просмотр, открытие, копирование или перемещение) EFS обновляет поля DRF, используя самые последние версии открытых ключей действующих сертификатов агентов восстановления. Учетные записи агентов восстановления определяются в групповой политике агентов восстановления шифрованных данных (Encrypted Data Recovery Agents Group Policy).
Политика восстановления шифрованных данных Восстановить зашифрованный файл, например, требуется при увольнении работ ника или в случае повреждения закрытого ключа пользователя EFS. Восстановле ние файлов на компьютере, на котором расположены учетная запись текущего аген та восстановления, сертификат и закрытый ключ, выполняется средствами програм мы командной строки Cipher. Для восстановления файла администратор восстанов ления должен войти в систему под учетной записью агента восстановления и вос пользоваться Cipher. Программа Cipher работает только с учетными записями аген тов восстановления, перечисленными в DRF файлов я лишь при условии, что за крытый ключ восстановления расположен на этом же компьютере, Групповая политика агентов восстановления шифрованных данных Ч это подмно жество групповой политики открытого ключа (Public Key Group Policy). Она по зволяет назначать учетные записи агентов восстановления для доменов, подразде лений или изолированных компьютеров. Назначенные доверенные администрато ры восстановления вправе использовать учетные записи агентов восстановления для восстановления зашифрованных EPS-системой файлов в соответствующих до менах и подразделениях.
В загружаемой групповой политике агентов восстановления содержатся сертифи каты учетных записей всех назначенных агентов восстановления из области дей ствия данной политики. EFS использует информацию групповой политики аген тов восстановления шифрованных данных для создания и обновления полей DRF.
Сертификат агента восстановления содержит открытый ключ и информацию, ко торая уникально идентифицирует учетную запись этого агента, По умолчанию агентом восстановления для компьютеров в сети назначается учет ная запись Administrator (Администратор) па первом созданном в домене контрол лере. На изолированных компьютерах агентом восстановления EFS но умолчанию Обеспечение безопасности средствами технологии открытого ключа ГЛАВА 13 считается локальная учетная запись Administrator (Администратор). Шифрованная файловая система автоматически создает сертификаты восстановления EFS для стандартной учетной записи Administrator.
Внимание! Чтобы отключить действие EFS и домене, подразделении или на изоли рованном компьютере, задайте пустые параметры политики агентов восстанов ления шифрованных данных. До тех пор пока никаких изменений в политике не сделано и пока изменения политики агентов восстановления не распространились, действует стандартная политика и EFS использует агентов восстановления по умол чанию. После определения и применения параметров EFS применяет агенты вос становления, перечисленные в групповой политике агентов восстановления шифрованных данных. Если примененная политика пуста, EFS попросту не ра ботает.
В состав Windows 2000 Resource Kit входит программа Efsinfo.exe, позволяющая просматривать информацию о текущих агентах восстановления.
Учетные записи агентов восстановления Учетные записи агентов восстановления EFS по умолчанию удовлетворяют потреб ности многих организаций.- Если требуется более гибко управлять восстановлени ем EES, возможно, придется назначить другие учетные записи агентам восстанов ления. Для этого необходимо иметь возможность выпускать сертификаты восста новления EFS. Например, сертификаты восстановления для специально выделен ных компьютеров восстановления EFS, а не для стандартной учетной записи Administrator (Администратор) на контроллерах домена. Кроме того, Вы вправе из менить параметры агентов восстановления шифрованных данных для переносных компьютеров, чтобы на них использовались одни сертификаты агентов восстанов ления Ч как при работе в домене, так и вне сети.
Наряду с управлением восстановлением EFS на уровне домена допустимо назна чать агентов восстановления в отдельных подразделениях. Б одном подразделении разрешается назначить несколько учетных записей, используемых по мере необхо димости для восстановления пользовательских файлов.
Для выпуска сертификатов пользователей и агентов восстановления EFS следует установить службы сертификации. Если выпускающий ЦС предприятия доступен, шифрованная файловая система не создает сертификаты самостоятельно, a 3ai ра шиваст их в центре сертификации предприятия. Использование ЦС позволяет цен трализовано управлять сертификатами EFS и при необходимости публиковать списки отзыва сертификатов (certificate revocation lists, CRL).
Зашифрованные файлы EFS, с которыми долгое время не проводились операции (просмотр, открытие, копирование, перемещение) иногда содержат информацию лустаревших агентов восстановления. Чтобы сохранить возможность восстановле ния таких файлов с помощью старых сертификатов агентов восстановления и их закрытых ключей, рекомендуется вести архив агентов восстановления. Подробнее о восстановлении EFS в главе 16 Службы сертификации и инфраструктура от крытого ключа в Windows 2000 и главе 15 Шифрованная файловая система.
Безопасность в распределенных системах 592 ЧАСТЬ Безопасность переносных компьютеров Чаще всего EFS применяют для шифрования файлов на переносных компь ютерах для сохранения конфиденциальности даже в случае хищения компь ютера. Обычно шифрование в EFS выполняют средствами диалогового окна свойств папки в Windows Explorer (Проводник Windows). Для этих же це лей используют программу командной строки Cipher, Чтобы защитить средствами EFS файлы на переносном компьютере, выпол ните действия, описанные ниже.
Х Убедитесь, что пользовательская папка My Documents (Мои документы) пуста, и примените к ней защиту EFS (зашифруйте ее). Все новые файлы и подпапки, создаваемые в зашифрованной средствами EFS папке, авто матически шифруются. Пользователям разрешено создавать в папке My Documents (Мои документы) сколько угодно папок. Созданные (а значит, зашифрованные) Вами файлы другие пользователи прочитать не смогут.
Х Зашифруйте средствами EFS папки, используемые приложениями для хранения временных копий. Так как EFS работает на более низком уров не, чем приложения, последние имеют дело только с открытым текстом.
Если не защитить средствами EPS эти папки, временные файлы прило жения будут храниться в незашифрованном виде. Существует другой спо соб решения этой проблемы: сконфигурировать приложение для хране ния временных файлов в уже зашифрованных EFS папках.
Х Настроив параметры списков ACL файловой системы NTFS, запретите пользователям создавать незашифрованные EFS папки, а также изменять параметры самой шифрованной файловой системы.
Х Воспользуйтесь служебной программой System Key (SysKey) Windows для защиты закрытых ключей EFS. SysKey применяет надежные способы шифрования для повышения безопасности защищенных хранилищ пользо вателей, в которых хранятся закрытые ключи пользователей для EFS.
Защита средствами IP-безопасности Windows 2000 поддерживает семейство протоколов IP-безопасности (IP Security, IPSec), основанных на стандартах, определенных рабочей группой IP Security Protocol (1PSEC) сообщества IETF (internet Engineering Task Force). IPSec работа ет на сетевом и транспортном уровне TCP/UDP и прозрачен для операционной системы и приложений. IPSec обеспечивает сквозную безопасность между отправ ляющими и принимающими компьютерами в IP-сетях и конфигурируется для под держки одной или. нескольких перечисленных функций безопасности:
Х проверки подлинности отправителя IP-пакетов данных на базе протокола Kerberos, цифровых сертификатов или общего секретного ключа (пароля);
Х обеспечения целостности передающихся по IP-сетях пакетов данных;
Х шифрования всех передаваемых по сети данных для обеспечения полной их кон фиденциальности;
Х сокрытия от просмотра IP-адреса отправителя пакетов при их прохождении по сети.
Обеспечение безопасности средствами технологии открытого ключа ГЛАВА Обычно в IPSec проверка подлинности клиентов Kerberos выполняется по прото колу Kerberos. Кроме того, IPSec позволяет использовать цифровые сертифи апы для проверки подлинности клиентов, не поддерживающих протокол Kerberos (на пример, для клиентов деловых партнеров в экстрасети). Сертификаты гарантиру ют самую безопасную проверку подлинности клиентов IPSec, не поддерживающих Kerberos. Метод общих секретов (паролей) здесь сильно проигрывает и поэтому широко не используется, за исключением случаев тестирования IPSec или обеспе чения взаимодействия с некоторыми lPSec-клиснтами сторонних поставщиков.
Политика безопасности IPSec определяется как на уровне домена, так на уровне локального компьютера путем определения списка правил и фильтров, используе мых для управления безопасной связью с отдельными клиентами IPSec.
Для выпуска сертификатов проверки подлинности iPSec используются службы сер тификации Windows 2000 или сторонних поставщиков. Следует настроить полити ку безопасности IPSec, указав ЦС.доверенные для выпуска сертификатов провер ки подлинности IPSec. Например, развернув в своей организации службы серти фикации для выпуска сертификатов IPSec для клиентов не под управлением Win dows 2000, настройте политику безопасности IPSec на доверие сертификатам, вы пущенным этими ЦС. При этом для IPSec-связи в экстрасети можно применять сертификаты, выданные сторонними ПС (например, ЦС делового партнера).
Подробнее о IPSec -- в книге Сети TCP/IP. Ресурсы Microsoft Windows Server (Русская Редакция, 2001).
Смарт-карты в решениях безопасности Смарт-карта (smart card) - это устройство размером с кредитную карту, содержа щее интегральную схему. Смарт-карты защищены от копирования содержимого и используются для храпения сертификатов и закрытых ключей и выполнения та ких сложных криптографических операций с открытым ключом, как проверка под линности, цифровое подписание и обмен ключами.
Смарт-карты и устройства их чтения применяются в различных решениях безопас ности для повышения надежности проверки подлинности и невозможности отри цания авторства, а также для сетевого входа в систему, безопасной связи через Ин тернет и защиты почты, Преимущества смарт-карт Ниже перечислены преимущества смарт-карт.
Х Так как закрытые ключи хранятся на устойчивых к взлому смарт-картах, л не на таком слабо защищенном носителе, как жесткий диск, решения со смарт-кар тами обеспечивают высокую безопасность при проверке подлинности пользова телей и невозможность отрицания авторства.
Х Так как операции шифрования изолированы от операционной системы, смарт карты неуязвимы к атакам на операционную систему (например, к спровоциро ванному переполнению буфера или получению снимка памяти, последующий анализ которого позволит получить доступ к закрытым ключам или другим сек ретам).
Х Так как реквизиты входа в систему хранятся у пользователей, Вы можете выпу стить по одной смарт-карте для каждого из сетевых пользователей с единым набором реквизитов для входа в систему как в локальных, так и удаленных се Безопасность в распределенных системах 594 ЧАСТЬ тях. Это избавит администраторов от необходимости управлять несколькими учетными записями для каждого пользователя Ч для входа в систему по сети и удаленно.
Кроме того, вход в систему со смарт-картой обеспечивает большую безопасность, чем процессы сетевого входа в систему, полагающиеся на традиционные пароли. Адми нистративная поддержка пользовательских паролей требует в больших организаци ях значительных затрат, в том числе и потому, что пользователи постоянно забыва ют свои пароли или пропускают сроки их обновления. Применение же смарт-карт снижает издержки обслуживания пользователей. Вместо пароля в смарт-картах при меняется персональный идентификационный номер (personal identification number.
PIN), или PIN-код. Известный только владельцу смарт-карты, PIN-код защищает ее от несанкционированного использования. Для активизации смарт-карты пользова тель вставляет ее в подключенное к компьютеру устройство чтения смарт-карт и в ответ на запрос системы вводит свой PIN-код. Смарт-карту может использовать тот, кто знает PIN-код и имеет на руках саму смарт-карту.
PIN-коды и пароли Защита, предоставляемая PIN-кодом гораздо надежнее защиты стандартными се тевыми паролями. Пароли (или такие их производные, как, например, хэш) пере даются по сети и уязвимы для лобовых атак, при которых злоумышленник переби рает все возможные комбинации знаков в пароле, пока не обнаруживает правиль ную. Пароли также зачастую подбирают по словарю: злоумышленник перебира ет известные слова и распространенные имена, пытаясь угадать пароль. Так как большинство пользователей предпочитают хорошо запоминаемые пароли, атаки по словарю, по сравнению с лобовыми, обычно успешнее и занимают меньше време ни. Таким образом, надежность пароля во многом зависит от его длины, от того, насколько он защищен от посторонних своим владельцем, от степени его зашиты от перехвата в сети и от сложности самого пароля. Даже хорошие пароли, защи щенные шифрованием и неуязвимые для атак по словарю, опытный злоумыш ленник может взломать лобовой атакой в течение нескольких недель или месяцев.
В отличие от паролей PIN-код никогда не передается по сети, и следовательно, его невозможно перехватить. Кроме того, для выполнения любого рода атаки необхо димо наличие смарт-карты. Вместе с тем вероятность подбора PIN-кода злоумыш ленником, получившим в свое распоряжение смарт-карту очень мала, так как смарт карта автоматически блокируется после нескольких неудачных попыток набора PIN-кода. По этой причине попытки взлома смарт-карты по словарю и лобовые атаки неэффективны.
Другое преимущество смарт-карт в том, что политика PIN-кодов менее строга, чем политика сетевых паролей. В общем случае сетевые пароли должны быть длинны ми и сложными, кроме того, рекомендуется их часто менять. Как правило, в резуль тате пользователи.записывают трудно запоминаемые пароли. А PIN-коды обычно изменяются нечасто и сравнительно легки для запоминания, поэтому вероятность того, что пользователи их где-то запишут, существенно ниже.
Сетевой вход в систему со смарт-картой Windows 2000 поддерживает сетевой вход в систему со смарт-картой с помощью расширения протокола Kerberos v5. Обычно для сетевого входа в систему пользо ватели нажимают комбинацию клавиш CTRL^ALT+DEL, запускающую последова Обеспечение безопасности средствами технологии открытого ключа ГЛАВА 13 тельность безопасного обращения к системе Windows 2000 (Secure Attention Se quence, SAS). Для запуска SAS-последователыгости пользователь вставляет смарт карту в устройство чтения, а затем набирает PIN-код смарт-карты. Если представ ленный PIN-код и реквизиты смарт-карты действительны, пользователю разреша ется вход в систему и предоставляются права и разрешения его учетной записи.
Когда администратор подает от имени пользователя заявку на получение сертифи ката для входа в систему со смарт-картой, Windows 2000 автоматически сопостав ляет сертификат смарт-карты учетной записи пользователя в Active Directory. По этой причине сертификаты смарт-карт для сетевого входа в систему должны вы пускаться доверенным ПС предприятия.
Если в конфигурации системы для сетевого входа в систему в домене используют ся смарт-карты и в то же время некоторым пользователям позволено входить в си стему без них (например, при помощи комбинации CTRL+ALT+DEL для клиентов под управлением Windows 2000 или по протоколу NTLM для клиентов под управ лением Microsoft Windows98 и Microsoft Windows NT), то безопасность сети опре деляется самым слабым паролем в системе. Для усиления безопасности сетевого входа в систему следует применять решения на основе Windows 2000 и смарт-карт для всех пользователей при обязательном требовании использования смарт-карт для входа в систему на всех компьютерах всех доменов, в том числе удаленных.
Примечание Смарт-карты пригодны для входа в систему даже на компьютерах, от ключенных от сети и от домена. На настроенном для использования смарт-карт компьютере смарт-карты применяются для проверки подлинности пользователей как при локальном, так и при сетевом входе в систему. Поэтому при использова нии смарт-карт на переносных компьютерах Вам не придется выполнять дополни тельные процедуры для входа в систему и для работы внутри или вне сети.
Удаленный вход в систему Проверка подлинности сетевых пользователей, использующих удаленный доступ, в Windows 2000 выполняется службой маршрутизации и удаленного доступа (Rou ting and Remote Access Service, RRAS). Служба RRAS поддерживает проверку под линности со смарт-картами средствами расширения EAP-TLS протокола РРР (Point-to-Point Protocol). При наличии поддержки EAP-TLS в процессе проверки подлинности сетевого входа в систему удаленному пользователю предлагается вста вить смарт-карту в устройство чтения и набрать личный PIN-код. Если PIN-код пользователя и реквизиты смарт-карты действительны, пользователь войдет в сис тему с нравами и разрешениями соответствующей учетной записи сетевого пользо вателя. Подробнее о EAP-TLS Ч в книге Межсетевое взаимодействие. Ресурсы Microsoft Windows 2000 Server* (Русская Редакция*, 2001).
Другие приложения, поддерживающие смарт-карты Существует много сторонних поставщиков смарт-карт и устройств их чтения, со вместимых со спецификацией PC/SC (Personal Computer Smart Card) и работаю щих с компьютерами под управлением операционных систем Windows 2(4)0, Microsoft Windows 95, Windows 98 и Windows NT 4.0. Развертывание приложений, поддерживающие смарт-карты, позволяет повысить безопасность связи через Ин тернет, доступа к Web-узлам и защищенной электронной почты.
Безопасность в распределенных системах 596 ЧАСТЬ Microsoft Internet Explorer 5 и Outlook 98 поддерживают смарт-карты и использу ют их в операциях шифрования с открытым ключом. Например, в Internet Explorer смарт-карты применяются для проверки подлинности пользователей в се ансах безопасной связи через Интернет по протоколам SSL и TLS, а в Outlook Ч при выполнении операций протокола S/MIME для защищенной почты, Сторонние поставщики предлагают множество решений, способных удовлетворить самые разнообразные потребности. Например, приложения цифровой подписи, ис пользующие смарт-карты для подписания программного обеспечения по техноло гии Authenticode. Вы также вправе создавать собственные специализированные приложения для смарт-карт. Например, приложение для подписания кода, поддер живающее работу со смарт-картами.
Примечание Несмотря на то, что некоторые продукты для шифрования файлов сто ронних поставщиков поддерживают смарт-карты, в EFS поддержка смарт-карт не предусмотрена. Это обусловлено тем, что EFS разработана для автоматической про зрачной работы без какого-либо вмешательства со стороны пользователя.
Получение сертификатов для смарт-карт Получение сертификатов для смарт-карт от имени пользователей выполняется на Web-странице Smart Card Enrollment Station (Станция подачи заявок смарт-карт) служб сертификации, переход на которую осуществляется с Web-страницы Advanced Certificates Request (Расширенные запросы на сертификаты). Для предоставления сертификатов для смарт-карты только авторизованным сетевым пользователям (это наиболее безопасный вариант) рекомендуется применять решения, позволяющие централизованно управлять смарт-картами и выпускать сертификаты для них. Раз решив пользователям самим запрашивать сертификаты смарт-карт, Вы ослабите об щую безопасность, обеспечиваемую смарт-картами.
Существует возможность автоматически обновлять сертификаты смарт-карт кли ентов Windows 2000. Вместе с тем для обеспечения самого высокого уровня сете вой безопасности некоторым организациям может потребоваться периодическая смена сертификатов смарт-карт и PIN-кода. PIN-код изменяется только при выпус ке или обновлении сертификатов смарт-карт поставщиком GSP для смарт-карт Подробнее о станции подачи заявок смарт-карт Ч в главе 16 Службы сертифика ции и инфраструктура открытого ключа в Windows 2000.
Совместимость смарт-карт Windows 2000 поддерживает смарт-карты и устройства их чтения, соответствующие технологии Plug and Play, с логотипом Designed for Windows*. Указанный лого тип подтверждает, что данный продукт работает с Windows 2000, и гарантирует со вместимость смарт-карт и устройств чтения различных поставщиков.
Продукты Microsoft оснащены драйверами и поддерживают устройства чтения смарт-карт с логотипом, подтверждающим их совместимость с Windows. Бывает, что одни поставщики предоставляют драйверы нестандартных устройств чтения смарт-карт, которые не работают со смарт-картами других поставщиков. Случается и обратное: смарт-карты одних поставщиков несовместимы с устройствами чтения смарт-карт других поставщиков. Для обеспечения длительного срока службы и под держки устройств, а также максимальной совместимости смарт-карт с устройства Обеспечение безопасности средствами технологии открытого ключа ГЛАВА 13 ми чтения рекомендуется использовать с Windows 2000 только смарт-карты и уст ройства чтения, обладающие логотипом Designed for Windows.
Подробнее о программе и логотипе Designed for Windows Ч на Web-странице Web Resources no адресу web resources, ссылка Microsoft Hardware Testing. Текущий список совместимого оборудования для смарт-карт Вы найдете на Web-странице Web Resources no ад ресу ссылка Microsoft Windows Hardware Compatibility.
Параметры настройки смарт-карт При разработке инфраструктуры открытого ключа и планировании развертывания решения на смарт-картах Вам доступны определенные средства обеспечения безо пасности системы.
Запрет пользователям входить в систему без смарт-карт. Разрешив пользовате лям со смарт-картами применять последовательность CTRL+ALT+DEL для входа в систему, Вы сведете на нет все преимущества смарт-карт. Оба метода следует разрешать только в переходный период на время обучения пользователей и тести рования процесса входа в систему со смарт-картой в доменах. По окончании пере ходного периода комбинацию CTRL-ALT+DEL следует заблокировать для отдель ных учетных записей пользователей (но не групп безопасности), после чего пользо вателям придется применять только смарт-карты. Настройка параметров отдельных учетных записей пользователей выполняется средствами оснастки Active Directory Users and Computers (Active Directory - пользователи и компьютеры).
Блокировка системы при изъятии смарт-карты из устройства чтения. Когда пользователь отходит от компьютера во время открытого активного сеанса в систе ме, не выйдя из системы или не заблокировав вход, данные могут стать доступны злоумышленнику. Если для входа в систему применяются исключительно смарт карты. Вы можете включить принудительную блокировку системы при извлечении пользовательской смарт-карты из устройства чтения. Используйте эту возмож ность, чтобы обезопасить данные, особенно если они хранятся на компьютерах, рас положенных в легкодоступных местах. Для принудительной блокировки групп ком пьютеров при изъятии смарт-карт следует настроить параметры групповой поли тики.
Совмещение смарт-карт с идентификационными бейджами работников. Многие организации выпускают для своих работников карт-ключи и идентификационные бейджи. Для доступа в здание и входа в сеть можно использовать смарт-карту, объе диненную с ключом и фотографией. Такие комбинированные карты используются как для получения физического доступа в здания и охраняемые комнаты, так и для сетевого входа в систему. Комбинированные карты также применяют в дебетовых системах электронных платежей, например, для оплаты работниками покупок в кафетерии или магазине организации. За более подробной информацией о совме щении смарт-карт с карт-ключами и бейджами с фотографией обращайтесь к по ставщикам смарт-карт.
Стандарт FIPS 140-1 и криптографические карты FORTEZZA Windows 2000 поддерживает два федеральных стандарта криптографии, играющих важную роль при защите правительственной связи в США, Ч FJPS МО-1 и криптогра Безопасность в распределенных системах 598 ЧАСТЬ фические карты FORTEZZA. Подробнее о FIPS 140-1 и криптографических картах FORTEZZA на Web-странице Web Resources но адресу windows2000/reskit/webresources, ссылка Microsoft Security Advisor.
Стандарт FIPS 140- Стандарт FIPS 140-1 разработан в США, в Национальном институте стандартов и тех нологии (National Institute of Standards and Technology, NIST). В стандарте FIPS 140-1, озаглавленном Security Requirements for Cryptographic Modules (Требования безо пасности для криптографических модулей), указаны требования правительства США к разработке и применению аппаратных и программных модулей криптогра фии, выполняющих операции шифрования конфиденциальной, но несекретной ин формации. Стандарт FIPS 140-1 принят Канадской организацией по безопасности связи (Canadian Communication Security Establishment) и Американским нацио нальным институтом стандартов (American National Standards Institute, ANSI). Bo многих станах он признан стандартом де-факто для криптографических модулей и вошел в международный стандарт ISO 15408 Evaluation Criteria for Information Technology Security (Критерии оценки безопасности информационных технологий).
NIST сертифицирует аппаратные и программные модули криптографии, поддержива ющие FIPS 140-1, в том числе криптографические карты FORTEZZA. В FTPS 140- существуют четыре уровня безопасности: уровень 1 - самый низкий, уровень 4 Ч самый высокий. Эти уровни охватывают широкий круг приложений и сред, в кото рых используются модули криптографии.
Все поставщики службы криптографии (CSP) Windows 2000 поддерживают уро вень 1 стандарта F1PS 140-1 и предназначены для применения организациями, ко торым требуется сертификация FIPS 140-1. Подробнее о поставщиках службы криптографии Microsoft и стандарте FTPS 140-1 на Web-странице Web Resources по адресу ссылка Microsoft Security Advisor.
Криптографические карты FORTEZZA Криптографические карты FORTEZZA - это платы PCMCIA (Personal Computer Memory Card International Association), разработанные Национальным агентством безопасности (National Security Agency). Они представляют собой защищенные от постороннего вмешательства устройства, обеспечивающие при помощи шифрова ния конфиденциальность информации, проверку подлинности пользователей и це лостность данных. По своим функциям решения с криптографическими картами FORTEZZA похожи на решения со смарт-картами и устройствами их чтения, од нако у карт FORTEZZA больше памяти и мощнее процессор. Применяющиеся в них алгоритмы шифрования используются системой Defense Message System (сис тема защищенных сообщений) министерства обороны США.
Как и смарт-карты, карты FORTEZZA применяются для зашиты почты и обеспе чения безопасности связи через Интернет, когда передают конфиденциальную, но несекретную информацию. Вместе с тем существуют и усовершенствованные вер сии FORTEZZA для защиты секретной информации.
Криптографические карты FORTEZZA поддерживаются Microsoft при работе с за щищенной почтой в совместимых с Defense Message System версиях Exchange Server и клиента службы сообщений и совместной работы Outlook 98. Windows 2000, ГЛАВА 13 Обеспечение безопасности средствами технологии открытого ключа Internet Explorer и IIS также поддерживают FORTEZZA для безопасной связи че рез Интернет.
Для поддержки карт FORTEZZA необходимо установить на компьютерах интер фейсы PCMCIA. Это намного более дорогостоящее решение, чем смарт-карты про мышленных стандартов. Смарт-карты обеспечивают почти такой же уровень безо пасности, что и карты FORTEZZA, но при этом гораздо дешевле. По этой причине в некоторых правительственных учреждениях США применяются стандартные смарт-карты для обеспечения высокой безопасности почты и связи через Интер нет, а также для взаимодействия с поддерживающими общие стандарты системами обмена сообщениями и информационной безопасности на основе технологии от крытого ключа. В министерстве обороны США разрешены к применению два ком понента инфраструктуры открытого ключа: High Assurance Messaging System (сис тема обмена сообщениями высокой надежности) на базе карт FORTEZZA и Medium Assurance Messaging System (система обмена сообщениями средней надежности) па базе смарт-карт.
Системы сообщений высокой надежности обеспечивают высокую безопасность ин формации за счет использования дорогих карт FORTEZZA и криптографических модулей, совместимых с FIPS 140-1. Однако надо помнить, что системы на основе карт FORTEZZA несовместимы со стандартными системами информационной бе зопасности па основе технологии открытого ключа.
Системы средней надежности обеспечивают удовлетворительную безопасность ин формации за счет использования недорогих стандартных смарт-карт и инфраструк туры открытого ключа. Сторонние организации способны поддерживать безопас ную связь с учреждениями министерства обороны США при помощи стандартных систем обмена сообщениями и информационной безопасности, не вкладывая сред ства в дорогую технологию FORTEZZA, Криптографические карты FORTEZZA поставляют фирмы, список которых утвер ждается Агентством национальной безопасности США. За более подробной ин формацией о картах FORTEZZA обращайтесь непосредственно к поставщикам.
Специализированные приложения безопасности Стандартные компоненты и возможности инфраструктуры открытого ключа Win dows 2000 используются в различных решениях безопасности на базе технологий открытого ключа. Для удовлетворения особых требований безопасности Вы вправе строить собственные приложения, работающие со службами сертификации Windows 2000.
Разрешается создавать специализированные модули политики и модули выхода для интеграции служб сертификации с существующими базами данных и службами каталога сторонних поставщиков. Например, Вы можете разработать приложение, которое проверяет запросы сертификатов но информации о пользователях, содер жащейся в существующей базе данных или в произведенной сторонним поставщи ком службе каталога.
Кроме того, никто не запрещает разработать специализированное приложение, вы пускающее сертификаты особых типов. Например, программу, обрабатывающую электронные документы для создания их хэшей, которые затем включаются в сер тификаты с меткой времени. Такие сертификаты хранятся в базе данных реестра документов, обеспечивая целостность их оригинального содержания. Любая под Безопасность в распределенных системах 600 ЧАСТЬ мена в документе или внесение коррективов в него, выполненные с момента его регистрации, станут очевидными при сравнении документа с его хэшем в базе дан ных реестра. Средствами подобных реестров документов возможно создавать конт рольный след для аудита интерактивной проверки качества производимых Вами продуктов, обеспечивая этим целостность электронной документации по тестиро ванию и сертификации.
Для такого собственного приложения можно создать ASP-страницы для подачи заявок на получение и обновление сертификатов. Например, изменить стандартные Web-страницы служб сертификации, добавив или убрав отдельные элементы или разработать новые Web-страницы, поддерживающие интеграцию со службами сто ронних поставщиков или другими созданными Вами приложениями.
Прежде чем применять собственные приложения, следует убедиться, что они рабо тают корректно, и тщательно протестировать их в лаборатории и на пилотных сис темах. Подробнее о приложениях для поддержки безопасности на базе технологий открытого ключа, совместимых со службами сертификации, Ч па Web-странице Web Resources по адресу webresources, ссылка Microsoft Platform SDK.
Стандарты технологии открытого ключа и взаимодействие программ Для достижения максимальной совместимости (interoperability) с приложениями сторонних поставщиков в инфраструктуре открытого ключа Windows 2000 приме няются на стандарты, рекомендованные рабочей группой PKIX сообщества IETF, Другие рекомендованные IETF стандарты, в их числе стандарты для TLS, S/MIME и IPSec, также позволяют инфраструктуре открытого ключа взаимодействовать с продуктами сторонних разработчиков. Компания Microsoft разрабатывает эти от крытые стандарты вместе с другими членами IETF и полна решимости обеспечить соответствие элементов инфраструктуры открытого ключа рекомендациям и стан дартам IETF.
В технологии шифрования стандартом де-факто считаются криптографические стандарты открытого ключа (Public Key Cryptography Standards, PKCS), разрабо танные и поддерживаемые компанией RSA Data Security, Inc. В настоящее время технологии PKCS широко применяются, обеспечивая хорошо испытанный и понят ный базис для взаимодействия продуктов различных поставщиков. Когда рабочая группа РК1Х предложила новый стандарт управления сертификатами, рабочая группа S/MIME создала свое решение на основе PKCS. Такое оперативный подход типичен для деятельности IETF no разработке стандартов и отражает понимание сообществом складывающейся ситуации на рынке. Для достижения максимальной совместимости с продуктами безопасности, созданных на основе технологий откры того ключа сторонних поставщиков, Microsoft включил эти стандарты де-факто в инфраструктуру открытого ключа Windows 2000.
Однако стандарты не гарантируют взаимодействия между совместимыми с PKIX коммерческими продуктами, так как технология открытого ключа находится на ранней стадии развития. Исторически разработка коммерческих продуктов опере жает процесс появления стандартов. Это особенно верно для технологии открыто го ключа. В настоящее время одновременно несколько рабочих групп в сообществе Обеспечение безопасности средствами технологии открытого ключа ГЛАВА 13 IETF разрабатывают предложения но стандартам технологии открытого ключа, но многие из приложений, к которым эти стандарты относятся, уже поставляются в виде готовых продуктов. Более того, ни в одном стандарте нельзя предусмотреть все требования и взаимозависимости приложений, поэтому часто при реализации стандарты уточняются и расширяются. Таким образом, способность приложений вза имодействовать это результат постепенного изменения стандартов производителя ми, совместно работающими над обеспечением совместимости своих продуктов.
В настоящее время продукты многих поставщиков взаимодействуют друг с другом посредством SSL, TLS и S/MIME. По мере развития и конвергенции стандартов при совместной работе производителей все больше компонентов инфраструктуры открытого ключа становятся совместимыми. Возможно, когда-нибудь полная совме стимость будет восприниматься как должное, однако сейчас лабораторное тести ю вание является единственным способом достоверно проверить совместимость и воз можности продуктов различных поставщиков.
Выбор оптимального решения безопасности Технологии распределенной безопасности Windows 2000 позволяют создавать са мые разнообразные надежные и масштабируемые решениях на основе шифрования, обеспечивающие безопасность сети и данных. Такие решения отвечают требовани ям безопасности многих организаций. Выбор уровня безопасности всегда опреде ляется ценностью защищаемой информации и затратами на его реализацию.
В общем случае принимая решение о том, как защищать информацию, следует:
Х проанализировать системы обмена служебной информацией и связи;
Х определить цели защиты информации и связи;
Х определить требования к безопасности информации и связи;
Х оценить риски нарушения защиты;
Х оценить затраты на реализацию различных методов защиты и их преимущества;
Х протестировать избранное решение безопасности и определить оптимальное для организации.
Анализ системы обмена служебной информацией и системы связи Проанализируйте существующую в Вашей организации систему обмена служебной информацией и связи, чтобы выявить области нарушенной или слабой безопаснос ти и определить способы укрепления защиты, в том числе:
Х определите уровни секретности информации и политики безопасности для от крытой, коммерческой, особо секретной и конфиденциальной информации в организации;
Х оцените все данные организации (в файлах и базах данных), расположенные в сети, в том числе экстрассти и Интернете;
Х оцените все данные, которые организация пересылает по внутренним сетям,.ж стасетям и Интернету, Безопасность в распределенных системах 602 ЧАСТЬ Определение целей обеспечения безопасности информации и связи Проанализировав существующую систему обмена служебной информацией и свя зи, поставьте реалистичные цели обеспечения безопасности для Вашей организа ции. Этот этап во многом определяет общие затраты на реализацию мер безопасно сти. Реалистичные цели помогают обеспечить приемлемый уровень безопасности за разумную цену.
Какие цели обеспечения безопасности информации и связи можно считать реалис тичными?
Х Обеспечить надежную проверку подлинности при сетевом входе в систему, од новременно сократив расходы на службу поддержки пользователей, забывающих или не вовремя обновляющих свои пароли.
Х 1 [овысить защиту в Интернете, запретив пользователям загрузку и использова ние не вызывающих доверия или неподписанных данных.
Х Повысить безопасность в интрасети, запретив пользователям загрузку из интра сети и использование данных, которые не вызывают доверия или не подписаны.
Х Обеспечить целостность и невозможность отрицания авторства всех служебных сообщений электронной почты, пересылаемых в пределах организации и предо ставить пользователям при необходимости обмениваться конфиденциальными сообщениями электронной почты.
Х Обеспечить целостность, невозможность отрицания авторства и конфиденциаль ность всех служебных сообщений электронной почты, которыми обмениваются члены руководства и доверенный управляющий персонал.
Х Обеспечить целостность, невозможность отрицания авторства и конфиденциаль ность всех служебных сообщений электронной почты, пересылаемых через Ин тернет.
Х Обеспечить надежную проверку подлинности пользователей при обращении к Web-узлам, используемым для разработки продуктов и совместной работы над проектами.
Х Обеспечить проверку подлинности, целостность и конфиденциальность инте рактивных бухгалтерских операций.
Х Обеспечить устойчивый ко взлому процесс удаленного сетевого входа в систе му с применением единого набора реквизитов пользователя, уменьшив допол нительную административную нагрузку на поддержку отдельных локальных и удаленных учетных записей сетевого входа в систему для одних и тех же пользо вателей.
Нереалистичность целей обеспечения безопасности (например, указание слишком высокого уровня безопасности) увеличит Ваши затраты на реализацию и поддерж ку. Кроме того, эти цели вообще могут оказаться недостижимыми для существую щих технологий. Например, обеспечить проверку подлинности, целостность и кон фиденциальность на уровне IP для всех сетевых соединений, в принципе, удастся лишь через несколько лет, поэтому постановка такой цели при современной сете вой инфраструктуре и существующей технологии IPSec неразумна и нецелесооб разна. IPSec существенно увеличивает сетевой трафик, а сама технология все еще не поддерживается многими клиентами и приложениями.
ГЛАВА 13 Обеспечение безопасности средствами технологии открытого ключа Определение требований к безопасности связи и передачи информации Поставив цели обеспечения безопасности, следует определить уровни безопаснос ти, необходимые;
для различных типов данных. Для этого требуется:
Х продумать различные сценарии обмена информацией и связи, которые отража ют типы защищаемых данных и обмен ими, осуществляемый объектами в сети;
Х определить уровни безопасности, необходимые для реализации каждого из сце нариев;
Х определить технические требования для достижения поставленных целей обес печения безопасности.
Предположим, Вы разработали три различных сценария, отражающих информаци онный обмен в компании. Первый закрытый обмен сообщениями электронной почты между руководителями компании. Второй Ч обмен информацией и совмест ная работа над проектами по разработке закрытых продуктов с использованием выделенного для этих целей Web-узла. Третий Ч сетевой трафик и связь между работниками юридического отдела.
В первом сценарии указано, что информационный обмен между руководителями компании выполняется в форме конфиденциальных сообщений защищенной элек тронной почты, читать которые вправе только руководство и некоторые доверен ные сотрудники. К этому сценарию предъявляются особые требования по устойчи вости системы безопасности и защищенности от атак.
Согласно второму сценарию, только проверенные работники команды проекта име ют доступ к содержимому Web-узла. Кроме того, передача по сети особо сскрстн х данных требует тщательной защиты.
В третьем сценарии определено, что весь сетевой трафик между компьютерами со трудников юридического отдела следует тщательно защитить, причем у этих ком пьютеров не должно быть никакой связи с внешними системами, в том числе с дру гими компьютерами предприятия.
На основании требований, определенных на этой стадии, следует выбрать меры безопасности, позволяющие реализовать их на приемлемом уровне риска и с разум ными затратами.
Оценка риска нарушения защиты Оцените риск атак на Ваши сетевые ресурсы Ч как изнутри, так и извне. Риск атак и последующей компрометации системы определяется, прежде всего, перечислен ными далее факторами.
Х Уровень защищенности сети от внешних и внутренних атак. Если Ваша сеть со единена с Интернетом, всегда существует риск атаки извне. Этот риск весь via высок, если отсутствует защита в виде, например, сетевого экрана или прокси сервера. Если рабочие станции и серверы располагаются в защищенных поме щениях, риск внутренних атак обычно сравнительно низок. Однако он суще ственно возрастает, если не обладающие достаточными полномочиями пользо ватели получают доступ к рабочим станциям или если сетевые серверы не риз мешены в защищенных центрах данных.
Безопасность в распределенных системах 604 ЧАСТЬ Х Ценность сетевых ресурсов для потенциальных взломщиков. Для сети, в кото рой хранится и перемещается ценная финансовая информация, риск подверг нуться атаке существенно выше, чем для сети, где хранится несекретная обще доступная информация. Ценность атаки определяется не только стоимостью ресурсов сети. Злоумышленник, например, может считать доблестью взлом се тевой защиты Вашей организации.
Х Стоимость реализации атаки для взломщиков. Стоимость атаки в сети с шиф рованием трафика обычно весьма высока, а в сети, где связь осуществляется открытым текстом, чрезвычайно мала.
Обычно только злоумышленники, владеющие оборудованием и навыками крипто анализа, а также имеющие сильные побудительные мотивы к атаке, готовые потра тить на нее значительное время. Они предпринимают дорогостоящие атаки на ре сурсы, защищенные надежной технологией шифрования.
Чтобы выбрать подходящее решение безопасности, Вы должны сравнить риск атак и стоимость потенциального ущерба от успешных атак с затратами на развертыва ние и преимуществами от реализации предлагаемых решений безопасности.
Подробнее о факторах риска для безопасности на основе шифрования Ч в главе <Х Криптография в сетевых информационных системах.
Оценка стоимости и преимуществ различных решений безопасности Общие затраты на реализацию решения безопасности состоят из:
Х расходов на планирование, разработку, тестирование и развертывание выбран ной системы;
Х издержек администрирования и поддержки решения после развертывания;
Х ресурсов, необходимых для информирования клиентов о возможностях новой системы и обучения их использованию новой технологии;
Х расходов на поддержку новой системы (например, службы поддержки);
Х потерь в производительности труда пользователей по причине ограничений, на лагаемых системой безопасности;
Х увеличения нагрузки и снижения производительности компьютеров и сетей вследствие возросшей вычислительной нагрузки, создаваемой операциями шиф рования.
Оценка стоимость реализации различных решений поможет выбрать подходящую систему, обеспечивающую приемлемую безопасность и производительность за ра зумную цену. Стоимость реализации и поддержки систем безопасности, использу ющих технологии распределенной безопасности Windows 2000, сильно зависит от поставленных целей и требований к безопасности. Мы проиллюстрируем этот те зис двумя примерами.
Если для проверки подлинности сетевого входа в систему предполагается исполь зовать смарт-карты, Вам придется позаботиться и о создании плана выпуска сер тификатов смарт-карт для новых полыюкателей, и о поддержке пользователей, ко торые иногда теряют или забывают свои смарт-карты дома. Выбранные политики безопасности для смарт-карт значительно влияют на стоимость такого решения, Производительность труда существенно снизится, если сотрудники без смарт-карт Обеспечение безопасности средствами технологии открытого ключа ГЛАВА 13 на руках не смогут быстро и без проблем получить временный доступ в сеть. Вмес те с тем, позволив работникам входить и сеть без смарт-карт, Вы существенно сни зите сетевую безопасность. От программы и политик использования смарт-карт зависят стоимость поддержки пользователей, производительность труда работни ков и уровень общей сетевой безопасность.
Если для обеспечения надежной конфиденциальности информации особо секрет ных проектов используется безопасная связь через Интернет, рекомендуется раз вернуть службы сертификации для выпуска и поддержки цифровых сертификатов для всех участников проекта, которым необходим доступ к закрытым Web-узлам.
Стоимость такой системы определяется ресурсами, необходимыми для реализации и поддержки служб сертификации. Кроме того, большие объемы защищенного се тевого трафика отрицательно сказываются на производительности Web-сервера.
Это может заставить Вас для сохранения приемлемой производительности Wл'b серверов установить дорогостоящие платы криптоакселераторов. Общая стоимость решения также зависит от числа нуждающихся в поддержке пользователей и объе мов передаваемой по сети конфиденциальной информации. Если ограничить тра фик конфиденциальной информации и сохранить его па низком уровне, возможно, Вам удастся сэкономить, отказавшись от приобретения дорогих криптоакселсрато ров, Проверка плана обеспечения безопасности Независимо от выбранного решения, прежде чем развертывать его в сети предпри ятия, следует убедиться в корректности работы и тщательно протестировать его в лаборатории и па пилотных системах. Обязательно проверяйте работу системы в сетевом окружении, имитирующем реальную есть Вашей организации.
Во время проверки следует убедиться, что система обеспечивает не только расчет ную производительность, но и ожидаемый уровень безопасности. Протестируйте все возможности и функции системы. Разработайте и выполните формализованный план тестирования. Это позволит тщательно проверить все функции безопасности.
В настоящее время многие организации не ограничиваются проверкой в тестовых лабораториях и на пилотных системах и нанимают специальные команды для вы явления уязвимых мест сети посредством реальных атак на проверяемую систему.
Таким образом, зачастую удается обнаружить и устранить слабые места системы до того, как их найдут и используют настоящие злоумышленники. Мы рекомендуем проводить полевые испытания систем постоянно. Регулярные nni.ггапия в ус ловиях эксплуатации помогут Вам надежно защитить информацию.
Дополнительные материалы Подробнее о проектах стандартов и рекомендациях IETF - на Web-странице Web Resources по адресу webresources, ссылка Internet Engineering Task Force (IETF).
Подробнее о криптографических стандартах открытого ключа (Public Key Cryp tography Standards, PKCS) -- на Web-странице Web Resources по адресу ссылка RSA Data Security Безопасность в распределенных системах 606 ЧАСТЬ Подробнее о стандарте FIPS 140-1 Ч на Web-странице Web Resources по адресу ссылки Security Requirements for Cryptographic Modules и National Institute of Standards and Technology (NIST).
Подробнее о FIPS 140-1, как о международном стандарте де-факто для моду лей криптографии Ч на Web-странице Web Resources но адресу dows.microsoft.com/windows2000/reskit/webresources, ссылка international Organization for Standardization (выполните поиск по строке International Stan dard 15408: Evaluation Criteria for Information Technology Security).
Подробнее о логотипе Designed for Windows и поддерживаемых в настоящее время устройствах для работы со смарт-картами Ч на Web-странице Web Resources по адресу ссылка Microsoft Windows Hardware Compatibility List.
Подробнее о технологиях безопасности в продуктах Microsoft, в том числе об ог раничениях на экспорт криптографических технологий и требованиях к лицензи рованию - на Web-странице Web Resources по адрееу microsoft.com/windows2000/reskit/webresources, ссылка Microsoft Security Advisor.
Подробнее о влиянии экспортных ограничений па применяемые в Ваших реше ниях безопасности технологии шифрования Ч в главе 14 Криптография в се тевых информационных системах.
ГЛАВА Криптография в сетевых информационных системах Криптография является краеугольным камнем современных электронных техноло гий безопасности, применяющихся для защиты ценных информационных ресурсов в интрасетях, экстрасетях и Интернете. Microsoft Windows 2000 поддерживает мно жество технологий распределенной безопасности используемых для обеспечения сетевой и информационной безопасности. При выборе и планировании сетевых информационных систем безопасности в организации важно понимать основные кон цепции, компоненты и риски, связанные безопасностью на основе криптографии.
В этой главе Что такое криптография Основные компоненты современной криптографии Основные компоненты инфраструктуры открытого ключа Факторы риска криптографических систем Ограничения на экспорт криптографических технологий Дополнительные материалы См. также Х Подробнее о решениях безопасности на базе открытого ключа в главе Обеспечение безопасности средствами технологии открытого ключа.
Х Подробнее об инфраструктуре открытого ключа и службах сертификации в Windows 2000 в главе 16 Службы сертификации и инфраструктура откры того ключа в Windows 2000.
Х Подробнее о разработке, проверке и развертывании инфраструктуры открытого ключа Ч в книге Microsoft Windows 2000 Server Deployment Planning Guide > (Microsoft Press, 2000).
Безопасность в распределенных системах 60S ЧАСТЬ Что такое криптография Криптография, (cryptography) Ч это способ тайного письма. На протяжении длитель ного времени ее средства используются для обеспечения безопасности связи между людьми, государственными учреждениями и армейскими подразделениями. В насто ящее время криптография лежит в основе современных технологий, применяемых для защиты информации и ресурсов как в открытых, так и закрытых сетях.
Основы криптографии Традиционно криптография применялась для обеспечения секретности при пере даче сообщений между сторонами. Для защиты связи между уполномоченными сто ронами в криптографических системах используются особые процессы, приемы и механизмы, предназначенные для зашиты обмена данными, то есть для предотвра щения чтения или фальсификации сообщений посторонними лицами.
Простейшая форма криптографии Ч это шифрование сообщения посредством под мены или перестановки знаков. Схема такой подмены или перестановки традици онно называется шифром. Шифр позволяет преобразовать читаемое сообщение, или открытый текст, в нечитаемое, скремблированное или спрятанное сообщение, называющееся зашифрованным текстом или шифротекстом. Обратно преобразо вать зашифрованный текст в открытый может только владелец ключа расшифров ки. Автор кодированного сообщения должен безопасным способом передать ключ раскодирования только потенциальным получателям. Нарушение безопасности при передаче ключа чревато компрометацией этого ключа, так как, завладев ключом расшифровки, сторонние лица получают возможность преобразовать шифротекст в открытый текст и прочитать сообщение, Любое лицо, перехватившее зашифрованный текст сообщения и ключ расшифров ки, сможет прочитать секретные сообщения. Более того, всякий, кому известен шифр и ключ, сможет выдавать себя за отправителя и посылать поддельные (фаль сифицированные) сообщения. Вот почему криптографические системы должны предоставлять надежные методы безопасного распространения ключей расшифров ки. Следует иметь в виду, что, даже если злоумышленники узнают шифр, исполь зованный для шифрования сообщения, и получат зашифрованный текст, прочитать закодированное сообщение без ключа они не смогут. Кроме того, в криптографи ческих системах существуют специальные технологии и механизмы, позволяющие убедиться, что авторы кодированных сообщений являются теми, за кого себя выда ют, и проверить, изменялось ли сообщение на пути от отправителя к получателю.
Цели современных криптографических систем Никакую криптографическую систему нельзя считать абсолютно неуязвимой и не компрометируемой. Всегда найдется слабое место, атака на которое увенчается ус пехом. В истории криптографии немало примеров взломов и компрометации пгаф росистем, считавшихся неуязвимыми. Необходимо быть самим господом богом, что бы создавать криптосистемы без недостатков, которые способны противостоять са мым изощренным методам атаки. Но системы создаются в реальном мире, а зна чит, с учетом многих ограничений. У всех систем информационной безопасности, и том числе и у криптографических, есть уязвимые места, которые злоумышленники способны обнаружить и атаковать или использовать для компрометации.
Криптография в сетевых информационных системах.
ГЛАВА 14 Назначение современных криптосистем не в обеспечении абсолютной безопаснос ти информационных ресурсов, а скорее, в такой их защите, при которой затраты на нелегальное приобретение или подделку информации превышают потенциальные преимущества от ее незаконного использовании. Так как с течением времени цен ность информации, как правило, снижается, хорошая система безопасности обес печивает защиту информации, пока ее ценность значительно ниже затрат па незакон ное получение или искажение. Правильно реализованная и используемая криптоси стема делает попытки нарушения безопасности чрезвычайно невыгодным делом.
Например, многие современные криптосистемы сильно осложняют попытки полу чить ключ раскодирования, но успех все-таки не исключен. Криптосистемы защи щают ценную информацию в достаточной степени, хотя опытный взломщик, потра тив много времени и усилий, может в конце концов вычислить ключ. Однако ei о затраты на получение ключа во много раз превысят ценность защищенной этим ключом информации.
Уровень защиты от атаки грамотно спроектированных и проверенных криптосис тем без известных недостатков в основном определяется длиной ключа кодирова ния. Все криптосистемы с длиной ключа шифрования меньшей, чем открытый текст сообщения, уязвимы для атак методом полного перебора. Перепробовав все воз можные ключи, злоумышленник за разумное время найдет правильный. При ис пользовании длинных ключей для полного перебора потребуется сложное и доро гое компьютерное оборудование, а время поиска может исчисляться сотнями, ты сячами или даже триллионами лет. Защита криптосистем от атак такого типа вы полняется выбором достаточно длинного ключа, подбор которого технически неце лесообразен или слишком дорог.
Еще одна цель при создании любой системы информационной безопасности, в том числе криптографических систем, Ч снизить стоимость защиты информационных ресурсов. Она должна быть намного меньше, чем стоят сами защищаемые данные, то есть криптографическая система безопасности должна обеспечивать защиту ин формации за приемлемую цену Необходимо учитывать соотношение цена/качество.
Подробнее об оценке стоимости и преимуществ решений безопасности Ч в главе 13 Обеспечение безопасности средствами технологии открытого ключа, Основные задачи криптографии Наиболее часто под криптографией понимают обеспечение конфиденциальности информации. Однако область ее применения существенно шире Ч криптографии позволяет решать четыре основных задачи.
Pages: | 1 | ... | 11 | 12 | 13 | 14 | 15 | ... | 18 | Книги, научные публикации