Предлагаемая статья
посвящена воспросам безопасностИнтернет и, в общем случае, сетей,
построениых на основе протоколов TCP/IP. Описаны основные вопросы
построения таких сетей, рассмотрена архитектура безопасности Интернет
и DOD/Internet. Рассмотрены принципы обеспечения безопасности
основных приложений Интернет (электронной почты, службы директорий,
передачи файлов и WWW). Приводится краткий обзор документов, определяющих
архитектуру безопасности Интернет.
Интернет представляет собой сообщество сетей, не имеющих единого централизованного управления и средств обеспечения и контроля качества сервисов (услуг). Каждая из участвующих или подключенных сетей является единственно ответственной за обеспечение всех доступных сервисов и, в частности, безопасности. Провайдеры услуг, частные операторы сетей, пользователи и поставщики оборудования и программных средств все вместе ответственны за обеспечение функционирования системы. Это в свою очередь накладывает своеобразный отпечаток на систему стандартизации в Интернет и обеспечение безопасности в Интернет, а также внедрение и использование сервисов безопасности.
Правила функционирования Интернет, наподобие правил этикета, являются волюнтаристскими (произвольными) и добровольными (непринудительными) до тех пор, пока они не противоречат национальным законам. В свою очередь, различие или даже отсутствие законов, регулирующих сферу существования Интернет, в разных странах, делает невозможным установление обязательных правил функционирования и использования Интернет.
Поскольку стандартизация - довольно дорогостоящая процедура, в настоящее время в области Интернет, телекоммуникаций и сетевых информационных технологий (СИТ) используются стандарты, разработанные и выпущенные различными органами стандартизации, как международными (ISO, IEEE, ICTT, ECMA, IETF ISOC), так и национальными (ANSI), а также так называемые стандарты де-факто, внедряемые крупными производителями и группами производителей в составе продукции или работающих систем.
Вся система стандартизации направлена на текущие и перспективные потребности рынка ИТ. Причем международной стандартизации подвергаются только важнейшие и наиболее концептуальные вопросы и технологии. Большинство стандартов используются в оригинальном виде или гармонизируются (переводятся, и согласовывается терминология).
Система стандартизации в Интернет имеет своеообразную структуру, носящей отпечаток того периода, когда Интернет развивалась, как научная сеть. Основные стандарты проходят путь через их первую версию, называемую RFC (Request For Comment - документ, предложенный для обсуждения), которая принимается Техническим Комитетом (IETF - Internat Engineering Task Force) при Обществе Интернет (ISOC - Internet Society), и начинают работать, как стандарты Интернет, а затем они могут приниматься IEEE или ISO (International Standard Organization).
В настоящее время опубликовано более 1900 RFC, которые стандартизуют все вопросы касающиеся применяемых в Интернет протоколов различных уровней модели ВОС (Взаимодействия Открытых Систем), операционных систем, приложений, систем обеспечения безопасности, представления и преобразования данных и информации. RFC могут иметь различный статус или версию: экспериментальный, для информации, проект, предложение и статус принятого стандарта Интернет.
Наиболее важные вопросы регламентируются стандартами ISO после их промышленной апробации. Если стандарты Интернет ориентированы на применение в среде сетей Интернет, то стандарты ISO, как правило, покрывают вопросы межсетевого взаимодействия или актуальные для множества существующих сетей и технологий и ориентированы на широкое промышленное применение.
ISO стандартизована Модель Взаимодействия Открытых Систем (ВОС). К важнейшим вопросам стандартизации ISO относятся интерфейсы, форматы данных, национальные шрифты и кодировки, протоколы взаимодействия открытых систем, протоколы маршрутизации.
IEEE стандартизованы интерфейсы локальных вычислительных сетей (ЛВС, LAN - Local Area Network) IEEE 802.3 (Ethernet), IEEE 802.4 (MAP или Token Bus), IEEE 802.5 (Token Ring), форматы данных и протоколы уровня данных др.
Большую группу стандартов, применяемых в телекоммуникационных сетях, составляют стандарты Международного Телекоммуникационного Союза (ITU-Т - International Telecommunication Union, Telecommunications Standardization Sector, в прошлом МКТТ) групп RS, V, X, которые относятся к различным уровням модели ВОС. Наиболее известными среди них являются стандарты, определяющие интерфейсы физического уровня RS-232C, RS-580, RS-485, RS-422, интерфейсы уровней данных V.21, V.32, V.35, X.21, X.25, X.75, а также группы стандартов, определяющих протоколы и услуги прикладного уровня: X.400 (система электронной почты, использующая функции почтового агента в структутре Клиент/Сервер); X.500 (распределенная служба директорий), которая также включает стандарт Х.509, описывающий системы обмена открытыми ключами; Х.700 (протоколы управления телекоммуникационными сетями), Х.800 (архитектура безопасности для открытых сетей передачи данныхв соответствии с моделью ВОС).
Группа протоколов TCP/IP,
являющаяся базовой для построения глобальной сети Internet, была
разработана в в ходе работ, финансированных Министерством обороны
США в рамках проектов DARPA (Defence Advanced Project Agency)
в 1970-х. Главной целью этой работы была разработка группы протоколов,
которые могли бы использоваться для широкого диапазона применений,
включая стратегические и тактические локальные и глобальные сети.
Разрабатываемые протоколы должны были быть независимы от нижних
сетвых уровней и работать в условиях изменяющейся топологии сети.
Группа протоколов TCP/IP
и их соответствие модели Взаимодействия открытых систем показаны
на рис. 3.1. Основные протоколы, входящие в группу TCP/IP:
ARP(Address Resolution
Protocol), RARP (Reverse Address Resolution Protocol) - протоколы
разрешения МАС- адресов (адресов доступа к среде, MAC - Media
Access Control), использующие широковещательные протоколы для
определения соответствия между Интернет-адресами (сетевыми адресами)
и МАС-адресами.
IP (Internet Protocol)
- протокол межсетевого обмена (Интернет- протокол).
ICMP (Internet Control
Message Protocol) - Протокол обмена управляющими сообщениями.
Используется в протоколах маршрутизации для обмена служебными
сообщениями.
TCP (Transmission Control
Protocol) - Протокол транспортного уровня, обеспечивающий дуплексный
обмен, установление и контроль соединениями.
UDP (User Datagram Protocol)
- упрощенный протокол транспортного уровня, не имеющий средств
управления соединениями. Формат заголовка имеет только поля портов
отправителя и получателя.
RPC (Remote Procedure
Call), XDR (External Data Representation), NFS (Network File System)
- сервисы распределенной файловой системы.
FTP (File Transfer Protocol)
- протокол передачи файлов между конечными системами.
Telnet - протокол эмуляции
терминала для удаленного доступа к системам.
SMTP (Simple Mail Transfer
Protocol) - протокол передачи почтовых сообщений.
SNMP (Simple Network Management
Protocol) - протокол управления малыми сетями, который применяется
для управления достаточно большими локальными, кампусными и региональными
сетями.
| Уровень модели ВОС | |||||
| 7 | Прикладной | ||||
| 6 | Представительный | ||||
| 5 | Сеансовый | ||||
| 4 | Транспортный | ||||
| 3 | Сетевой | ICMP | |||
| 2 | Данных | ||||
| 1 | Физический | ||||
Рис. 3.1. Группа протоколов
TCP/IP.
Форматы пакетов включают
в себя последовательно вложенные заголовки различных уровней сетевого
взаимодействия. Причем заголовок уровня данных следует первым,
в его поле данных помещается фрейм сетевого уровня, начинающийся
со своего заголовка, и т.д..
На рис. 3.2 приведен пример
пакета Ethernet, содержащего все заголовки последующих уровней
модели ВОС, которые находятся в поле данных исходного пакета,
длина которого задается требованием стандарта на Ethernet и не
должна превышать 1518 байт.
Рис. 3.2. Формат пакета
Ethernet, содержащий вложенные заголовки вышестоящих уровней.
На рис. 3.3 и 3.4 приведены
форматы пакетов сетевого уровня IP и транспортного уровня ТСР
соответственно.
Основные поля IP-пакета:
Version - номер версии
IP-протокола
IHL (IP Header Length)
- длина IP-заголовка
Type of Service - определяет
тип протокола более высокого уровня, который нужен для обработки
данной дейтаграммы, включая требования безопасности.
Total Length - общая длина
IP-пакета.
Identification - число,
идентифицирующее данную дейтаграмму. Это поле используется при
фрагментации исходной дейтаграммы.
Flags - указывает, может
ли данная дейтаграмма быть фрагментирована и является ли данная
дейтаграмма последней.
Fragment offset - смещение
фрагмента.
Time To Live - устанавливает
счетчик, который работает на вычитание пр каждом прохождении пакета
через межсетевое устройство. После обнуления счетчика пакет анулируется.
Protocol - определяет,
какой вышестоящий потокол должен получить полученный пакет.
Header Checksum - обеспечивает
целостность заголовка пакета.
Source Address, Destination
Address - указывают сетевые адреса отправителя и получателя.
Option - позволяет поддерживать
различные сервисы, включая сервисы безопасности.
Padding - ипсользуется
для дополнения пакета до необходимого размера, например, кратного
заданному числу.
Основные поля ТСР-пакета:
Source port, Destination
port - определяет номера портов, через которые доступны коммуницирующие
сервисы вышестоящих уровней.
Sequence number - определяет
номер, присвоенный первому байту текущего сообщения. Используется
при конвейерной пересылке данных (с использованием параметра Windows)в
режиме установления соединения.
Acknowledgement number
- указывает на номер следующего байта, который ожидает получить
получатель от отправителя при конвейерной пересылке данных.
Data offset - указывает
на число 32-битовых слов в ТСР-заголовке.
Reserved - поле зарезервировано
для последующего совершенствования ТСР-протокола.
Flags (URG, ACK, PSH,
RST, SYN, FIN) - поле флагов, используемых при коммуникациях и
установлении соединений.
Window - определяет размер
буфера входных данных получателя.
Checksum - используется
для контроля целосности ТСР-заголовка.
Urgent pointer - указывает
на первый байт срочных данных.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Рис. 3.3. Формат заголовка
IP-пакета (линейка вверху указывает номера битов).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| U
R G | A
C K | P
S H | R
S T | S
Y N | F
I N | ||||
Рис. 3.4. Формат заголовка
ТСP-пакета (линейка вверху указывает номера битов).
Сети общего пользования
DOD/Internet используют группу протоколов TCP/IP, используемых
также в Интернет. Однако архитектура безопасности DOD существенно
отличается от архитектуры безопасности Интернет, что является
следсвием различных исходным принципов/подходов к обеспечению
безопасности систем и приложений, сложившихся исторически.
В основе подхода DOD к обеспечению безопасности компьютерных сетей лежат три основных положения:
Особый характер информации,
циркулирующий в сетях DOD общего назначения, привел к использованию
принципа "минимальных привилегий" ("principle of
least privilege" или "need-to-now"), согласно которому
обработка данных в открытом виде производится только теми устройствами,
которые должны (уполномочены) это делать. Этот принцип приводит
к приоритетному использованию методов обеспечения безопасности
между конечными системами.
Упор на обеспечении гараантированной
безопасности компьютерных и сетевых систем в концепции безопасности
DOD привел к развитию парадигмы эталонного монитора (reference
monitor paradigm), релизуемого посредством безопасной операционной
системой, действующей как доверительный "посредник"
доступа субьектов (пользователей или процессов) к защищенным ресурсам,
называемым обьектами (представляющие собой файлы или процессы),
в системе. Чтобы быть эффективным, эталонный монитор должен быть
промежуточным для всех доступов всех субьектов к любым ресурсам
системы. При этом во главу угла ставится также конфиденциальность
любых соединений и доступов.
Практическая реализация указанных принципов и положений привела к архитектуре DOD/Internet, в основе которой лежит использование специальных "режимных" доверительных устройств обеспечения безопасности на уровнях Физическом, МАС (Media Access Level) и Сетевом (IP-уровне). Такие устройства соответсвенно выполняют следующие функции:
Устройства, реализующие
указанные функции являются очень дорогостоящими и, фактически,
целесообразны только действительно для особых критических применений,
где производится работа с очень чувствительной информацией.
Важным компонентом архитектуры
безопасности TCP/IP-сетей является обеспечение безопасности таких
сетевых приложений, как служба директорий и обмен сообщениями,
которые требуют использования механизмов обеспечения безопасности
на Прикладном уровне таких, как аутентификация, целостность, причастность,
контроль доступа.
Следствием применения
концепции эталонного монитора в архитектуре безопасности DOD является
необходимость использования доверительной безопасной операционной
системы для обеспечения гарантированной безопасности коммуникаций
между приложениями (задачами прикладного уровня), что является
еще одним дорогостоящим критическим компонентом архитектуры безопасности
DOD.
Архитектура безопасности
DOD использует механизмы контроля за доступом на основе правил
и централизованную систему распределения ключей, в то время как
архитектура безопасности Интернет использует механизмы контроля
за доступом на основе идентификации пользователя и соответственно
распределенную систему распределения открытых ключей на основе
Х.509..
Изложенные в [1] семь
принципов построения уровневой модели безопасности компьютерных
сетей в соответствии со стандартом ISO 7498-2 полностью применимы
для использования в Интернет. Однако для Интернет целесообразно
сформулировать ряд дополнительных принципов, определяющих применимость
механизмов безопасности в существующей модели и инфраструктуре
Интернет.
В Интернет может полностью
использоваться рекомендуемое в ISO 7498-2 соответствие между сервисами
безопасности и уровнями модели ВОС. Необходимость этого возникает
также исходя из применения в Интернет множества протоколов. Однако
предлагаемое соответствие имеет ряд ограничений, связанных с практическим
применением этих рекомендаций для реализации конкретных приложений
(сервисов) Интернет.
Поэтому для Интернет,
в соответствии с рекомендациями рабочей группы по вопросам обеспечения
конфиденциальности и безопасности в Интернет (PSRG - Privacy and
Security Research Group) IETF, наиболее эффективным является введение
комплексного соответствия между сетевыми информационными сервисами,
с одной стороны, и существующими сервисами и механизмами безопасности,
с другой стороны, что в основном ориентировано на обеспечение
совместимости отдельных реализаций сервисов в многопротокольной
глобальной среде Интернет. При таком подходе для каждого приложения
определяются требования к безопасности и соответствующие необходимые
сервисы и механизмы безопасности (протоколы и необходимая инфраструктура),
которые смогут удовлетворять этим требованиям. Т.е., фактически,
используемое в Интернет соответствие между сетевыми приложениями
(сервисами) и механизмами безопасности является обьединением и
обобщением предложенных в стандарте ISO 7498-2 карт соответствия
между сервисами безопасности и уровнями модели ВОС и между механизмами
и сервисами безопасности. Главной целью и преимуществом такого
подхода является обеспечение совместимости различных реализаций
приложений в Интернет, позволящей использовать продукты различных
производителей.
Ниже приводится краткий
обзор рекомендуемых и применяемых сервисов механизмов безопасности
для основных приложений Интернет: электронной почты, службы директорий,
управления сетью, удаленного терминала и передачи файлов, междоменной
и внутридоменной мрашрутизации, протокола обмена гипертекстовой
информацией в World Wide Web. Отдельно рассмотрены вопросы использования
брандмауэров для защиты внутренних и корпоративных сетей и создания
так называемого "периметра безопасности".
В Приложении 1 приведен
перечень RFC, определяющих архитектуру безопасности Интернет,
и дана их краткая аннотация.
5.2.1. Электронная
почта
Электронная почта является
наиболее широко используемым приложением Интернет. Поэтому обеспечению
защиты обмена почтовыми сообщениями (или просто сообщениями) посвящено
наибольшее количество стандартов и директивных документов Интернет,
ISO, ITU-T (МКТТ).
Отдельные сервисы электронной
почты в Интернет определяются стандартами RFC 822 (формат почтовых
сообщений), RFC 821 (простейший протокол передачи электронной
почты SMTP - Simple mail Transfer Protocol), RFC 1891 (Extended
SMTP), RFC 1225 (Post Offica Protocol, Version 3) и другими.
Сервисы безопасности для
почтовых сообщений должны включать обеспечение конфиденциальности
и целостности (для коммуникаций без установленния соединения),
аутентификацию происхождения данных, причастность (для отправителя
и получателя). Однако эти услуги касаются отправителя и получателя
сообщения, но не касаются провайдера услуг передачи электронной
почты.
Для обеспечения основынх
сервисов безопасности в рамках RFC 822 (для чисто текстовых документов)
был разработан протокол PEM (Privacy Enhanced Mail), изложенный
в RFC 1421-1424. PEM рекомендован и, фактически, используется
как единый стандарт в Интернет для защиты почтовых сообщений.
Особенностью применения PEM является необходимость использования
службы распределенной сертификации открытых ключей в соответствии
с Х.509. Защищенные обьекты PEM могут входить в состав собщения
в формате X.400.
Для обеспечения сервисов
безопасности расширенных форматов почтовых сообщений (MIME - Multupurpose
Internet Mail Extension) разработаны стандарты Интернет RFC 1847и
RFC 1848, которые определяют типы и форматы защищенных обьектов
почтовых сообщений MIME Object Security Service (MOSS).
Недавно разработан и находит
широкое распространение новый протокол защиты сообщений электронной
почты PGP (Pretty Good Privacy), который использует шифрование
при помощи открытого ключа для защиты почтового сообщения и файлов.
PGP включает конфиденциальность и цифровую подпись.
В Интернет широко применяется
система обработки сообщений в соответствии со стандартами ITU-T
группы Х.400, которые определяют протоколы и сервисы обработки
почтовых сообщений в открытых системах передачи данных. Станадарты
Х.400, Х.402, Х.411 наиболее полно определяют сервисы безопасности
для обработки почтовых сообщений как при передаче (включая учет
последовательности поступления сообщений), так и при их хранении:
конфиденциальность, целостность, аутентификацию происхождения
данных и станции отправителя, причастность (для отправителя и
получателя), а также использование меток и контекста безопасности.
В общем, архитектура безопасности Интернет должна позволять использовать как механизиы безопасности собственно Интернет (PEM, MOSS, PGP), так и соответствующие механизмы Х.400.
5.2.2. Служба директорий
В Интернет используется
две службы директорий DNS (Domain Name System - система доменных
имен) и Х.500. Сервисы безопасности и необходимые протоколы хорошо
определены для Х.500. Так, широкое применение находит система
распределения и сертификации открытых ключей Х.509. Однако нет
хорошо разработанной концепции и специальных механизмов безопасности
для DNS (RFC 1535).
Необходимыми сервисами
безопасности для службы директорий являются аутентификаци происхождения
данных и целостность данных для запросов и ответов. Контроль доступа
необходим для защиты хранимых в директории данных от модификации
и раскрытия неавторизованными пользователями.
Общей рекомендацией может
быть использование в Интернет для защиты директорий средств Х.500
на прикладном уровне и соответствующих протоколов более низких
уровней. Попытки реализовать необходимые сервисы безопасности
для DNS посредством сервисов и механизмов более низких уровней
не дает достаточной защищенности.
5.2.3. Управление сетями
Управление сетями в Интернет
обеспечивается при помощи протокола SNMP (Simple Network Management
Protocol). Ряд стандартов Интернет RFC 1352, 1446, 1472, 1910
определяют основные сервисы и механизмы безопасности при передаче
управляющей информации, доступе к базам данных управляющей информации
и управляющим обьектам.
Сервисы безопасности для
SNMP определяются для прикладного уровня: конфиденциальность и
целостность без установления соединения, аутентификация происхождения
данных и контроль доступа.
В последнее время отдельные
приложения в Интернет частично ориентиуются на использование протоколов
управления телекоммуникационными сетями передачи данных X.700,
которые имеют хорошо определенные сервисы и механизмы обеспечения
безопасности.
5.2.4. Виртуальный
терминал и передача файлов
Функции виртуального терминала
(или удаленного доступа) обеспечивается протоколом Telnet. Передача
файлов поддерживается протоколами FTP (File Transfer Protocol)
и FTAM (File Transfer, Access and Management). Необходимые сервисы
безопасности для обоих протоколов включают конфиденциальность
и целостность для коммуникаций с установлением соединений, аутентификацию
субьектов коммуникаций и контроль доступа на основе идентификации
субьекта коммуникаций. Эти сервисы могут быть полностью обеспечены
на прикладном уровне, однако целесообразно использовать некоторые
механизмы на более низких уровнях, в частности, используя специальные
защищенные протоколы сетевого и транспортного уровней NLSP (Network
Level Security Protocol), SSL (Secure Socket Level) и TLSP (Transport
Level Security Protocol). При этом устраняется дублирование сервисов
на более высоких уровнях, однако в возникает необходимость введения
новых программных модулей в ядро ОС.
5.2.5. Междоменная
и внутридоменная маршрутизация
Для междоменной маршрутизации
используются протоколы BGP (Border Gateway Protocol), IDRP (ISO
10747. IS-IS Inter-Domain Routing Protocol). Междоменная маршрутизация
обеспечивается протоколами RIP (Routing Information Protocol),
OSPF (Open Shortest Path First), IS-IS (ISO 10589. Intermediate
System to Intermediate System Intradomain Routing Exchange Protocol).
При работе эти протоколы обмениваются служебной и управляющей
информацией, которая определяет надежное функционирование сложной
сетевой ифраструктуры. Общими требованиями безопасности для протоколов
маршрутизации являются обеспечение аутентификации субьектов коммуникаций
и целостности для коммуникаций без установления соединений. Дополнительно
могут использоваться сервисы конфиденциальности и контроля доступа.
Учитывая то, что работа
протоколов маршрутизации относится к "инфраструктурному"
(сетевому и транспортному) уровню сети, эфективно для этой цели
использовать соответствующие механизмы и протоколы сетевого и
транспортного уровней (NLSP, TLSP). С другой стороны протокол
BGP сам имеет средства в структуре пакетов для поддержки аутентификации
и целостности.
5.2.6. Протокол передачи
гипертекстовой информации HTTP (HyperText Transfer Protocol)
Протокол передачи гипертекстовой
информации, являющийся базовым для построения World Wide Web,
относится к прикладному уровню и опирается на ряд протоколов более
низкого уровня и другие протоколы прикладного уровня, а также
используемые ими сервисы и механизмы обеспечения безопасности.
Широкое распоостранение
WWW, богатые возможности представления мультимедиа информации
и удобного инфтерфейса с пользователем привели к широкому использованию
WWW в бизнесе и развитию электронной коммерции через WWW, что
повлекло за собой необходимость разработки специальных средств
обеспечения безопасности коммуникаций при помощи HTTP. Так, были
разработаны и сейчас находится на стадии обсуждения в IETF протоколы
Secure HTTP (SHTTP) и Secure Socket Level (SSL).
Протокол SSL предназначен
для обеспечения безопасных коммуникаций между двумя приложениями
на транспортном уровне SSL (Secure Socket Communication), используя
порты или сокеты (sockets). Он обеспечивает конфиденциальность
коммуникаций между двумя приложениями через транспортный уровень,
а также может обеспечивать аутентификацию сервера и, дополнительно,
клиента. Приложения более высокого уровня (Telnet, FTP, HTTP)
могут использовать SSL для обеспечения безопасносго канала коммуникаций.
Протокол SHTTP обеспечивает
необходимые для приложений электронной коммерции сервисы безопасности
- конфиденциальность транзакций, аутентификацию, целостность сообщений,
причастность отправителя. SHTTP обеспечивает безопасные коммуникации
между конечными системами за счет использования криптографических
механизмов RSA при обмене сообщениями на прикладном уровне.
Брандмауэры (Firewall)
занимают важное место в архитектуре безопасности Интернет. Брандмауэры
используются для защиты сетей посредством контроля внешнего доступа
к внутренней сети и наоборот. Брандмауэры могут использоваться
для создания "периметра безопасности", который обеспечивает
защиту сети на сетевом уровне, позволяя таким образом упростить
требования к защищенности отдельных компьютеров и рабочих мест.
Брандмауэр обычно располагается
в точке доступа локальной или корпоративной сети к внешней сети,
например, Интернет. Брандмауэры могут также использоваться для
защиты отдельных сегментов корпоративной сети, реализуя специфические
функции по защите данного сегмента. Все соединения проходят через
брандмауэр и проверяются на соответствие установленным правилам
доступа на основе анализа заголовков IP-пакетов и, в отдельных
случаях, заголовков ТСР-пакетов (в частности, номеров портов,
определяющего типы коммуницирующих сервисов). В качестве брандмауэра
может использоваться маршрутизатор, персональный компьютер, рабочая
станция или система компьютеров, реализующих необходимые функции
по защите ресурсов сети от внешнего"злоумышленного"
доступа.
Концепция брандмауэров включает реализацию
Программные реализации
брандмауэров доступны как в коммерческом варианте (например, фирмы
Digital), так и свободно распространяемом варианте в Интернет
для некоммерческого использования (при этом государственные организации
не подлежат лицензионному соглашению на свободно распространяемые
программные продукты в Интернет).
1. Архитектуру безопасности Интернет, которая первоначально разрабатывалась для сетей общего пользования Министерства обороны США DOD/Internet, достаточно полно описывается группой стандартов Интернет RFC, описанными выше и приведенными в Приложении 1.
Важной особенностью этой
архитектуры является то, что она в своей основе ставит цель обеспечения
безопасности между конечными системами, которые для коммуникаций
используют неконтроллируемую (недоверительную) сетевую среду.
Это приводит к приоритетному использованию сервисов безопасности
на уровнях выше сетевого и транспортного, т.е. преобладающе на
прикладном уровне. Это в свою очередь позволяет использовать многие
сервисы и соответствующие программные продукты с другими группами
сетевых протоколов и различными сетевыми операционными системами.
2. Выделяются такие основные направления стандартизации в архитектуре безопасности Интернет:
В архитектуре безопасности
DOD/Internet дополнительно ставятся требования обеспечения доверительности
конечных компьютерных систем и конфиденциальности коммуникаций
в сети.
3. Все сервисы безопасности
реализуются, как дополнение к основным протоколам, и могут вводится
по желанию пользователей в зависмости от требуемого уровня безопасности
или доверительности к промежуточным системам. Это обьясняется
необходимостью использования дополнительных сетевых и вычислительных
ресурсов для обеспечения сервисов безопасности, что связано с
дополнительными расходами или падением производительности сетевых
приложений.
4. Существует прямое соответствие
между Сервисами безопасности модели ВОС в соответсвтии с ISO 7498-2
и сервисами безопасности Интернет (Конфиденциальность (Confidentiality),
Аутентификация (Authentication), Целостность (Integrity), Контроль
доступа (Access Control), Причастность ("неотпирательство",
Nonrepudiation)).
5. В соответствии с ISO 7498-2 базовыми являются модели соответсвия между сервисами безопасности и уровнями модели сетевого взаимодействия ВОС, а также между сервисами и механизмами безопасности.
В Интернет в качестве
базового подхода к безопасности используется карта соответствия
между сетевыми приложениями (сервисами) и механизмами безопасности,
что и нашло отражение в рассмотренных RFC.
6. Архитектура безопасности
Интернет в настоящее время является достаточно хорошо проработанной
и реализована в большом количестве программных продуктов и межсетевых
средствах. Основная ее ориентация на обеспечение безопасности
коммуникаций между конечными системами и пользователями делает
ее применимой для большинства групп сетевых протоколов и операционных
систем.
7. Важным элементом архитектуры
безопасности Интернет является обеспечения безопасности обмена
сообщениями по электронной почте, которая является наиболее широко
используемым приложением Интернет и современных коммуникаций.
Это стандарты PEM (Privacy Enhanced Mail), PGP (Pretty Good Privacy),
MOSS (MIME Object Security Services), которые также используются
для обмена защищенными сообщениями в других приложениях Интернет
(служба директорий, протоколы сетевого управления, видеоконференции
и т.д.).
8. Другим важным элементом
Архитектуры безопасности Интернет является архитектура распределения
и сертификации открытых ключей, которая обеспечивает средства
"заверения" третьей доверительной стороной открытых
ключей, основываясь на службе директорий Х.509 и моделях управления
телекоммуникационными сетями Х.700.
9. В настоящее время являются
стандартами де-факто протоколы SSL и SHTTP для обеспечения безопасности
обмена гипертекстовыми документами в среде World Wide Web (WWW),
которая в последнее время широко применяется в Интернет для создания
сети "Открытой коммерции".
Вопросам безопасности
посвящены ряд RFC, выполняющих роль стандартов Интернет, которые
по сути определяют архитектуру безопасности TCP/IP- cетей. Важной
особенностью этой архитектуры является то, что она в своей основе
ставит требование обеспечения безопасности между конечными системами,
которые коммуницируют в неконтроллируемом (недоверительном) сетевом
окружении. Это приводит к приоритетному использованию сервисов
безопасности на уровнях выше сетевого и транспортного, т.е. преобладающе
на прикладном уровне, что позволяет использовать многие сервисы
и соответствующие программные продукты с другими группами сетевых
протоколов и различными сетевыми операционными системами.
В таблице 1 приведен перечень
основных документов, определяющих архитектуру безопасности Интернет
и основные сервисы и механизмы безопасности, и их краткое содержание.
Таблица 1.
| Документ, название | Дата публик. | Кол. стр. | Резюме | |
| 1 | RFC 1244. (FYI: 8) Site Security Handbook.
Руководство к обеспечению безопасности узлов Интернет
| July 1991 | 101 | Данный документ является первой попыткой дать пользователям Интернет рекомендации: как обеспечивать безопасность работы в Интернет.
Рассматриваются вопросы, как установить политику безопасности узла или системы и что она должна включать, какие мероприятия и процедуры должны увеличить безопасности, даются также рекомендации, что делать в случае возникновения проблем. |
| 2 | RFC 1636. Report of IAB Workshop on Security in the Internet Architecture. February 8-10, 1994.
Рассмотрение вопросов безопасности в Интернет в работе Совета по Архитектурной организации Интернет. | June 1994 | 52 | Документ представляет собой краткий отчет о семинаре по вопросам безопасности в архитектуре Интернет, который проходил 8-10 февраля 1994 года, и содержит отдельные заметки и идеи, выработанные группой ведущих специалистов по вопросам развития архитектуры Интернет, включая вопросы маршрутизации, мобильности, сервисов реального времени, политики провайдеров и производителей технических средств Интернет. |
| 3 | RFC 1281. Guidlines for Secure Operation of the Internet.
Общий подход к обеспечению безопасности в Интернет | November 1991 | 10 | Целью этого документа является определение основных направлений и/или рекомендаций для обеспечения безопасной работы в Интернет. |
| 4 | RFC 1108. Security Options for the Internet Protocol
Средства обеспечения безопасности в протоколе Интернет (IP) | November 1991 | 17 | Документ описывает специальные дополнения к Интернет- протоколу для обеспечения безопасной передачи данных. Документ первоначально разработан для применения в сетях общего пользования Интернет Министерства Обороны США. |
| 5 | RFC 1455. Physical Link Security Type of Service
Определение типа сервиса обеспечения безопасности на физическом уровне в протоколе IP | May 1993 | 6 | Документ определяет способ задания типа сервиса обеспечения безопасности на физическом уровне. В документе рассматриваются угрозы нарушения безопасности сетей (передачи данных), которые могут возникать из-за плохой или недостаточной защищенности на физическом уровне.
Документ является дополнением к стандарту RFC 1346, определящему базовые понятия и основные TOS. Данный тип сервиса TOS требует от сети обеспечение определенного уровня защиты от тайного наблюдения трафика на физическом уровне посторонними лицами. Определяются два потенциальных требования к безопасности: противодействие наблюдению трафика и конфиденциальность. |
| 6 | RFC 1457. Security Label Framework for the Internet.
Определение меток безопасности для Интернет | May 1993 | 14 | Документ определяет структуру задания/ указания меток безопасности в протоколах Интернет. Документ предназначен для разработчиков протоколов, которые должны учитывать возможность поддержания меток безопасности на различных уровнях, а также для разработчиков систем, чтобы определить пригодность определенной группы протоколов требованиям безопасности. |
| 7 | RFC 1675. Security concerns for IPng.
Рассмотрение вопросов безопасности в новой версии протокола IPng | August 1994 | 4 | Рассматриваются некоторые вопросы, которые составляют определенные проблемы в обеспечении безопасности в существующей версии IPv4 и должны быть решены в ходе работы над новой версией протокола IPng (Internet Protocol next generation). При этом замечается, что новая версия протокола не должна исключить и затруднить работу существующих механизмов обеспечения безопасности, использующих информацию из IP-протокола. |
| 8 | RFC 1825. Security Architecture for Internet Protocol.
Архитектура безопасности IP- протокола | August 1995 | 22 | Данный документ описывает механизмы обеспечения безопасности передачи информации в протоколах IP версии 4 IPv4, используемой сейчас в Интернет, и новой версии 6 IPv6.
Определены механизмы безопасности и их применение на различных уровнях сетевых протоколов. Вводится понятие Ассоциации Безопасности. Показано, что степень и качество защиты, обеспечиваемые механизмами IР-протокола, зависят полностью от применяемых криптографических алгоритмов, ключей, корректности применения криптографических алгоритмов, безопасности протоколов распределения ключей и от правильности применения самих механизмов защиты на уровне IP-протокола. |
| 9 | RFC 1827. IP Encapsulation Security Payload (ESP).
Инкапсуляция защищенных данных в протоколе IP | August 1995 | 12 | Данный документ описывает принципы/ правила инкапсуляции защищенных данных в протоколе IP. ESP является механизмом обеспечения Целостности и Конфиденциальности в IP-дейтаграммах. Этот механизм работает как с IРv4, так и с новым протоколом IРv6.
ESP представляет собой механизм, предназначенный для обеспечения Цельности и Конфиденциальности IP-дейтаграмм посредством шифрования (encryption) данных и помещения их в поле данных группы полей "полезной нагрузки" (Payload) ESP. |
| 10 | RFC 1858. Security Consideration for IP Fragment Filtering.
Рассмотрение вопросов обеспечения безопасности при фильтрации фрагментированных IP-пакетов.
| October 1995 | 10 | Документ рассматривает возможные атаки, которые могут быть сделаны за счет маскировки ТСР-пакетов от IP-фильтров, и средства противодействия им. |
| 11 | RFC 1535. A Security Problems and Proposed Correction with widely Deployed DNS Software.
Проблемы безопасности и предлагаемые коррекции широко применяемого программного обеспечения для DNS (Domain Name Service) | October 1993 | 5 | Данный документ рассматривает некоторые недостатки ("дыры") распространяемого в то время программного обеспечения для разрешения доменных имен (DNS - Domain Name Service), основанного на резолвере (resolver) BSD BIND. Проблема безопасности связана с возможными записями неполных доменных имен, которые не закнчиваются точкой. В этом случае резолвер в процессе перебора различным комбинаций доменных имен может попасть на непредусмотренный адрес. |
| 12 | RFC 1507. Distributed Authentication Security Service.
Распределенная служба аутентификации для обеспечения безопасности в компьютерных сетях | September 1993 | 119 | Целью аутентификации, как сервиса безопасности, является надежная идентификация имени автора (отправителя) сообщения. Целью распределенной службы аутентификации DASS является обеспечение сервисов безопасности в распределенной среде, которая должна быть безопасна (защищена) и легко используема. Это обьясняется тем, что в сети пользователь обычно не просто входит (логируется) в один из компьютеров, а в дальнейшем запрашивает услуги и информацию у других компьютеров, при этом компьютер в который он первоначально залогировался, действует от его имени в таких соединениях. |
| 13 | RFC 1508. Generic Security Service Application Program Interface
Программный интерфейс к исходным приложениям сервисов безопасности. | September 1993 | 49 | Определение программного интерфейса к общим/базовым/исходным приложениям сервисов безопасности (ПИОПСБ, GSS-API - Generic Security Service Application Program Interface) обеспечивает вызывающему субьекту (программе или пользователю) сервисы безопасности в их общем/базовом виде с поддержкой механизмов и технологий нижнего уровня, что позволяет достичь переносимости исходных текстов приложений между различными аппаратными и программными платформами. Эта спецификация определяет сервисы и примитивы GSS-API на уровне, независимом от нижних уровней и языка программирования, и должна быть совместима/согласована с другими спецификациями.
Документ является практическим руководством к применению программного интерфейса к сервисам безопасности, однако интересен тем, что дает ряд основополагающих определений для взаимодействия с сервисами безопасности. |
| 14 | RFC 1509. Generic Security Service API: C-binding
Cвязывание программного интерфейса к исходным сервисам безопасности на языке С | September 1993 | 48 | Данный документ специфицирует программное связывание интерфейса к исходным сервисам безопасности, описанного в документе RFC 1508, на языке С. Рассматриваются конкретные конструкции языка С и этапы, необходимые для выполнения такого связывания при генерации прикладных программных модулей |
| 15 | RFC 1750. Randomness Recommendation for Security.
Рекомендации по генерации случайных чисел для целей обеспечения безопасности | December 1994 | 30 | Данный документ рассматривает слабые стороны использования традиционных псевдослучайных последовательностей. Рекомендуется использовать действительные случайные способы аппаратной генерации последовательностей, показано что существующее оборудование может быть использовано для этих целей. Использованием псевдослучайных последовательносей может привести к псевдо- защищенности, так возможно воспооизведение злоумышленником псевдослучайной последовательности и подбор криптографических ключей. |
| 16 | RFC 1824. The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4)
Криптографический протокол для обмена ключами аутентификации | August 1995 | 22 | Документ относится к информационному типу и описывает базовые механизмы и функции (identity-based) системы для аутентифицированного обмена криптографическими ключами, генерации подписи (сигнатуры) и аутентичного распределения открытых ключей. |
| 17 | RFC 1421. Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures.
Обеспечение конфиденциальности электронной почты в Интернет: Часть I: Процедуры шифрования и аутентификации сообщений. | February 1993 | 42 | Данный документ определяет процедуры шифрования и аутентификации сообщений для обеспечения конфиденциальной почты в среде Интернет. Описанные процедуры могут быть использованы с различными системами распределения ключей.
Конфиденциальность обеспечивается для коммуникаций между конечными системами и не требует никаких дополнительных функций от системы обработки сообщений. |
| 18 | RFC 1422. Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management.
Обеспечение конфиденциальности электронной почты в Интернет: Часть II: Система распределение открытых ключей с использованием сертификатов | February 1993 | 32 | Данный документ определяет необходимую для реализации РЕМ систему распределения открытых ключей с использованием сертификатов.
Описанная в этом документе система распределения ключей совместима с Х.509 и дополняет ее специальными процедурами для использования с РЕМ. Вводится понятие уполномоченной службы сертификации (Certification Authority) для создания инфраструктуры распределения открытых ключей. |
| 19 | RFC 1423. Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers.
Обеспечение конфиденциальности электронной почты в Интернет: Часть III: Алгоритмы, режимы и идентификаторы. | February 1993 | 14 | В документе даны основные определения, форматы, ссылки и краткое описание криптографических алгоритмов, используемых режимов и параметровдля поддержки РЕМ.
Документ явлется только руководством к более глубокому изучению необходимых средств и механизмов по другим документам. |
| 20 | RFC 1424. Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services.
Обеспечение конфиденциальности электронной почты в Интернет: Часть IV: Сертификация ключей и соответствующие сервисы. | February 1993 | 9 | Документ описывает три типа сервисов, необходимые для поддержки РЕМ: сертификация ключей, хранение списка ключей, вышедших из употребления, и получения такого списка от уполномоченных служб. |
| 21 | RFC 1847. Security multiparts for MIME: Multipart/Signed and Multipart/Encrypted
Защищенные компоненты почтовых сообщений в формате MIME (Multipurpose Internet Mail Extensions) | October 1995 | 11 | Этот документ определяет правила и форматы, как применять сервисы безопасности для защиты отдельных компонентов MIME-сообщения. Здесь не определяются сами по себе способы защиты. MIME-агент должен включать поддержку как описанных здесь правил и форматов, так и механизмы взаимодействия с протоколами безопасности, определяемыми другими регламентирующими документами. Таким образом, результирующая комбинация должна обеспечивать защиту как одно-компонентные, так и многокомпонентные текстовые и нетекстовые сообщения, использующие формат MIME. |
| 22 | RFC 1848. MIME Object Security Services.
Защита обьектов в многокомпонентных MIME- сообщениях | October 1995 | 48 | Данный документ определяет услуги обеспечения безопасности (защищенности) расширенных типов обьектов почтовых сообщений MIME Object Security Service (MOSS) с использованием форматов защищенных компонентов MIME-сообщений согласно RFC 1847 для применения цифровой подписи и/или шифрования отдельных компонентов сообщений. Данные сервисы реализуются через использование криптографии между конечными системами (пользователями) - отправителем и получателем сообщения. |
| 23 | RFC 1352. SNMP Security Protocols.
Протоколы обеспечения безопасности работы SNMP | July 1992 | 41 | В документе на основе модели администрирования протокола управления малыми сетями SNMP рассматривается модели безопасного управления сетями. Определяются протоколы для поддержки сервисов безопасности:
|
| 24 | RFC 1446. Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2).
Протоколы обеспечения безопасности для протокола управления малыми сетями версии 2 (SNMPv2) | April 1993 | 51 | В документе рассматривается модели безопасного управления сетями при помощи протокола SNMP, в основе которого лежат протоколы обеспечения сервисов безопасности:
Рассматриваются алгоритмы реализации соответствующих механизмов и сервисов. |
| 25 | RFC 1472. The Definition of Managed Objects for the Security Protocols of the Point-to-Point Protocol.
Определение управляемых обьектов для протоколов безопасности, используемых с протоколом PPP (Point-to-Point Protocol) | June 1993 | 12 | Данный документ определяет часть обьектов, используемых в Информационной Базе Сетевого Менеджмента (MIB - Management Information Base), предназначенных для безопасного управления протоколами РРР с использованием алгоритмов сетевого управления SNMPv2 (Simple Network Management Protocol Version2). |
| 26 | RFC 1910. User-based Security Model for SNMPv2.
Модель обеспечения безопасности для протокола SNMPv2, использующая идентификацию "пользователя" как субьекта доступа. | February 1996 | 44 | В рамках административной модели управления сетями при помощи протокола SNMP, которая включает сервисы аутентификации, авторизации, контроля доступа и конфиденциальности, определяются механизмы для достижения нужного уровня безопасности работы протокола.
Рассматривается модель контроля доступа, основанная на идентификации "пользователя" как субьекта доступа. |