Содержание к диссертации
Введение
1. Проблемы безопасности информационно телекоммуникационных технологий 11
1.1. Общие проблемы информационной безопасности информационно -телекоммуникационных технологий 12
1.2. Проблемы безопасности электронных платежных систем 19
1.3. Политика безопасности и архитектура безопасности
1.3.1. Основные типы политик безопасности 23
1.3.2. Типы моделей управления доступом
1.3.2.1. Модель дискреционного доступа 28
1.3.2.2. Модель мандатного доступа 32
1.3.2.3. Сравнение моделей управления доступом
1.4. Проблемы проектирования архитектур безопасности распределенных компьютерных систем 37
1.5. Выводы 41
2. Проблемы безопасности электронных платежей и электронных денег 43
2.1. Проблемы безопасности при платежах с помощью пластиковых карт 43
2.2. Электронная наличность 46
2.3. Система электронных монет чаума 48
2.4. Платежная система paycash 54
2.4.1 Модификация криптопротокола Чаума для системы PayCash 57
2.4.2. Платежная книжка в системе PayCash 59
2.4.3. Практические реализации системы PayCash и внесение дополнений в политику безопасности 64
2.5. Выводы
3. Анализ и выбор функций защиты для проектирования архитектур безопасности 69
3.1. Обзор подходов к защите распределенных компьютерных систем. 69
3.2. Обзор подходов обеспечения безопасности в ркс 70
3.3. Анализ средств обеспечения безопасности
3.3.1. Конфиденциальность 74
3.3.2. Аутентификация
3.3.3. Целостность 76
3.3.4. Управление доступом 78
3.3.5. Контроль участников взаимодействия 79
3.3.6. Доступность 80
3.3.7. Шифрование 80
3.3.8. Специальные средства обеспечения безопасности 81
3.4. Выбор основных механизмов защиты для реализации АБ 82
3.4.1. Механизмы управления доступом 82
3.4.2. Механизмы обеспечения целостности данных 83
3.4.3. Механизмы аутентификации 84
3.4.4. Механизмы подтверждения третьим лицом 85
3.4.5. Обзор средств и уровней применения механизмов защиты
3.4.5.1. Канальный уровень 87
3.4.5.2. Сетевой уровень 88
3.4.5.3. Транспортный уровень
3.5. Анализ архитектуры безопасности компании Cisco 91
3.6. Выводы 95
4. Разработка модели технологии 97
4.1. Формализация предметной области и построение модели 97
4.2. Выбор типовых функций для реализации АБ 101
4.2.1. Функция управления доступом (ACF) 102
4.2.2. Функция осуществления доступа (AEF) 105
4.2.3. Функция аутентификации (AF) 105
4.2.4. Функция целостности (IF) 108
4.2.5. Функция аудита (AudF) 109
4.2.6. Функции шифрования ПО
4.3. Разработка фреймовой модели по
4.4. Математическая модель построения политики безопасности в распределенной вычислительной сети 118
4.5. Многоуровневая модель доступа на основе модели белла-лападула 123
4.6. Выводы 133
5. Разработка методологии проектирования архитектур безопасности 135
5.1. Алгоритмизация проектирования архитектуры безопасности распределенных вычислительных систем 135
5.2. Учет классов защищенности вычислительных сетей 140
5.3. Построение защиты от внешних и внутренних воздействий 151
5.4. Алгоритм распределения функций безопасности 154
5.5. Пример применения разработанного алгоритма для проектирования аб существующей корпоративной сети
5.5.1. Потенциальные угрозы безопасности корпоративной сети 162
5.5.2. Выполнение требований целостности и конфиденциальности .164
5.5.3. Защита от внутренних угроз 166
5.5.4. Защита от угроз со стороны внешних коммуникаций 168
5.5.5. Полученные результаты 170
5.6. Применение разработанной методологии в подготовке специалистов по сетевым технологиям 173
5.6.1. Протоколы безопасности 174
5.6.2. Средства Cisco для обеспечения безопасности связи через Интернет 176
5.7. Выводы 183
Заключение 185
Литература
- Основные типы политик безопасности
- Модификация криптопротокола Чаума для системы PayCash
- Выбор основных механизмов защиты для реализации АБ
- Пример применения разработанного алгоритма для проектирования аб существующей корпоративной сети
Основные типы политик безопасности
Острота проблемы обеспечения безопасности субъектов информационных отношений, защиты их законных интересов при использовании информационных и управляющих систем, хранящейся и обрабатываемой в них информации все более возрастает. Этому есть целый ряд объективных причин.
Прежде всего - это расширение сферы применения средств вычислительной техники и возросший уровень доверия к автоматизированным системам управления и обработки информации. Компьютерным системам доверяют самую ответственную работу, от качества выполнения которой зависит жизнь и благосостояние многих людей. ЭВМ управляют технологическими процессами на предприятиях и атомных электростанциях, управляют движением самолетов и поездов, выполняют финансовые операции, обрабатывают секретную и конфиденциальную информацию.
Изменился подход и к самому понятию «информация». Этот термин все чаще используется для обозначения особого товара, стоимость которого зачастую превосходит стоимость вычислительной системы, в рамках которой он существует. Осуществляется переход к рыночным отношениям в области создания и предоставления информационных услуг, с присущей этим отношениям конкуренцией и промышленным шпионажем.
Проблема защиты вычислительных систем становится еще более серьезной и в связи с развитием и распространением вычислительных сетей, территориально распределенных систем и систем с удаленным доступом к совместно используемым ресурсам. Доступность средств вычислительной техники и прежде всего персональных ЭВМ привела к распространению компьютерной грамотности в широких слоях населения, что закономерно привело к увеличению числа попыток неправомерного вмешательства в работу государственных и коммерческих автоматизированных систем как со злым умыслом, так и чисто «из спортивного интереса». К сожалению, многие из этих попыток имеют успех и наносят значительный урон всем заинтересованным субъектам информационных отношений. Положение усугубляется тем, что практически отсутствует законодательное (правовое) обеспечение защиты интересов субъектов информационных отношений. Отставание в области создания стройной и непротиворечивой системы законодательно-правового регулирования отношений в сфере накопления и использования информации создает условия для возникновения и распространения «компьютерного хулиганства» и «компьютерной преступности».
Особую опасность для компьютерных систем представляют злоумышленники специалисты - профессионалы в области вычислительной техники и программирования, досконально знающие все достоинства и слабые места вычислительных систем и располагающие подробнейшей документацией и самыми совершенными инструментальными и технологическими средствами для анализа и взлома механизмов защиты. Еще одним весомым аргументом в пользу усиления внимания к вопросам безопасности вычислительных систем являются бурное развитие и распространение компьютерных вирусов, способных скрытно существовать в системе и совершать потенциально любые несанкционированные действия.
При выработке подходов к решению проблемы компьютерной, информационной безопасности следует всегда исходить из того, что защита информации и вычислительной системы не является самоцелью. Конечной целью создания системы компьютерной безопасности является защита всех категорий субъектов, прямо или косвенно участвующих в процессах информационного взаимодействия, от нанесения им ощутимого материального, морального или иного ущерба в результате случайных или преднамеренных воздействий на информацию и системы ее обработки и передачи [2,10,11,35,50,60].
В качестве возможных нежелательных воздействий на компьютерные системы должны рассматриваться: преднамеренные действия злоумышленников, ошибочные действия обслуживающего персонала и пользователей системы, проявления ошибок в ее программном обеспечении, сбои и отказы оборудования, аварии и стихийные бедствия.
В качестве защищаемых объектов должны рассматриваться информация и все ее носители (отдельные компоненты и автоматизированная система обработки информации в целом).
Обеспечение безопасности вычислительной системы предполагает создание препятствий для любого несанкционированного вмешательства в процесс ее функционирования, а также для попыток хищения, модификации, выведения из строя или разрушения ее компонентов, то есть защиту всех компонентов системы: оборудования, программного обеспечения, данных (информации) и ее персонала. В этом смысле защита информации от несанкционированного доступа (НСД) является только частью общей проблемы обеспечения безопасности компьютерных систем и защиты законных интересов субъектов информационных отношений, а сам термин НСД было бы правильнее трактовать не как «несанкционированный доступ» (к информации), а шире, - как «несанкционированные (неправомерные) действия», наносящие ущерб субъектам информационных отношений.
Модификация криптопротокола Чаума для системы PayCash
Обозначим соответствующие подписывающие и верифицирующие функции через Signp(-) и VerifyP(-,), так что VerifyP(X, Y) = True тогда и только тогда, когда Y= Signp(X). Монета, которую клиент получает в кооперации с банком, состоит из следующих данных: Com(i,P) = {i,P,&1(f(P))}, (2.2) то есть в качестве случайного серийного номера монеты в данной модификации используется случайный открытый ключ. Теперь, однако, в качестве платежа клиент отсылает расширенную монету {Order, Y,Coin(i,P)}, (2.3) где Y = SignP(Order), a Order — уникальное описание платежа, которое может, в частности, содержать номер счета, на который следует зачислить деньги. Формат описания не существен для общего рассмотрения. Банк авторизует платеж только в том случае, если монета со значением Р отсутствует списке использованных монет и выполнено равенство VerifyP(Order, Y) = True. (2.4) Если авторизация прошла успешно, то банк заносит монету (2.3) в список использованных монет, зачисляет на счет продавца надлежащую сумму и отправляет продавцу и плательщику подписанные квитанции, упоминающие Order.
Реализация такой модификации позволяет избавиться от необходимости для банка и плательщика доверять друг другу. Действительно, банк не может присвоить монету, так как он не в состоянии изготовить расширяющие монету данные, которые удовлетворяли бы соотношению (2.4). В свою очередь, банк защищается от обвинений в присвоении монеты, предъявляя расширяющие монету данные, которые удовлетворяют соотношению (2.4).
Эта модификация позволяет также легко связать платежную систему практически с любой торговой системой: достаточно в Order включить значение хэш-функции контракта, описывающего условия сделки. В этом случае квитанция с подписью банка будет связывать платеж и контракт, а содержание контракта останется для банка неизвестным.
Заметим также, что с теоретической точки зрения использование открытого ключа в качестве серийного номера монеты усиливает защищенность монеты. Например, если фальшивомонетчик научится обращать функцию f, то, чтобы воспользоваться монетой, ему потребуется найти секретный ключ, соответствующий открытому ключу монеты.
Во время платежа плательщик должен подписать Order столько раз, сколько монет включено в платеж. Так как платеж может включать множество монет, а вычисление цифровой подписи является довольно длительной операцией, то описанная схема может оказаться достаточно медленной, если иметь в виду существующий парк персональных компьютеров. Ситуацию можно заметно улучшить, если воспользоваться методом слепого возврата сдачи Чаума. В этом случае в каждом платеже может участвовать небольшое число монет, например одна.
В системе PayCash клиент расплачивается при помощи данных, которые называются платежной книжкой и имеют следующую структуру: PayBook(N, Р) = {N, Р, gN(f(P))}, (2.5) где Р, f и g имеют тот же смысл, что и в (2.2), и g"N(X) =g"1(g"1(...g"1(X)...)). Неотрицательное целое число N (диспозиция книжки) определяет платежеспособность книжки. Необходимым условием для того, чтобы тройка {n, Р, А} была платежной книжкой, является равенство: f(P) = gn(A), (2.6) которое может проверить любой участник системы, и в частности, сам владелец книжки. Таким образом, платежная книжка отличается от монеты Чаума тем, что вместо случайного серийного номера используется случайный открытый ключ, а сумма закодирована не с помощью "номинала", а с помощью степени подписывающего отображения.
Любой клиент, очевидно, может изготовить пустую платежную книжку, то есть книжку с нулевой диспозицией РауВоок(0, Р) = {0, Р, f(P)}. Кроме того, имея в своем распоряжении платежную книжку PayBook(N, Р), клиент может построить все книжки с тем же Р, но с меньшей диспозицией РауВоок(0, Р), РауВоок(1, Р),..., PayBook(N - 1, Р). (2.7) С другой стороны, понижение диспозиции известной клиенту книжки является единственным для него способом изготовления платежных книжек с ненулевой диспозицией без помощи банка. Изготовление платежных книжек с ненулевой диспозицией "с нуля" без помощи банка не менее трудно, чем изготовление монет в исходной системе Чаума. Действительно, если клиенту удалось изготовить платежную книжку PayBook(N, Р) = {N, Р, А} с диспозицией N 0, то в соответствующей системе Чаума ему также удалось изготовить монету Соіп(і, Р)= {і, Р, gN_1(A)}, где і— номинал, соответствующий подписи g" . Задача самостоятельного увеличения диспозиции непустой платежной книжки {N, Р, А}, которая не получена клиентом из известной ему книжки путем понижения ее диспозиции, эквивалентна получению банковской подписи g_1(A) для данных А = g"N(f(P)), которые являются фиксированными и имеют случайный характер.
В кооперации с банком клиент может пополнять платежную книжку, то есть увеличивать ее диспозицию, причем он может увеличить как диспозицию вновь созданной платежной книжки с нулевой диспозицией, так и диспозицию ранее пополнявшейся платежной книжки. Для пополнения платежной книжки PayBook(NbP) на сумму N2 клиент передает в банк ослепленные данные В. Один вариант ослепления, являющийся простейшей модификацией метода Чаума, имеет следующий вид:
Выбор основных механизмов защиты для реализации АБ
Функция аудита (AudF) позволяет вести непрерывный упорядоченный журнал важных системных событий, какое событие считать важным, определяется действующей политикой безопасности [121].
Все компоненты системы межсетевых экранов должны иметь возможность вести запись информации. Способ записи должен быть согласован, так чтобы информацией могли воспользоваться такие системы как утилиты оповещения, средства анализа контрольного журнала, средства обнаружения команд [127]. Эта информация предоставляется также авторизованному персоналу, позволяя следить за системой и ее безопасностью.
Систему аудита необходимо строить таким образом, чтобы при возникновении системных нарушений можно было бы восстановить события, приведшие к этим нарушениям. Кроме того, система аудита допускает наблюдение за системой до возникновения нарушения, что позволяет заметить попытку нарушения и принять необходимые меры.
Аудит не подразумевает хранения избыточной информации, кроме той, которая необходима для поддержания единообразия. Однако, для обеспечения отказоустойчивости, в частности, в неблагоприятных ситуациях, когда часть контрольной информации умышленно уничтожена, имеет смысл хранить в нескольких местах избыточную информацию: избыточность позволяет проводить перекрестный контроль правильности информации. Обнаруженное рассогласование может служить сигналом о возникновении нарушения. Записанные данные необходимо защищать от несанкционированного изменения, поиска и добавления. Следует защищать от нарушителей и саму систему аудита, в противном случае записанные данные нельзя считать достоверными. При проведении аудита в распределенных системах дополнительно рассматривают еще некоторые по аспекты: проблему хронологической синхронизации контрольных событий, согласованность форматов записей, вопросы присваивания имен и корреляцию событий, необходимые для проведения анализа. Рассмотрение этих вопросов выходит за рамки данной работы.
В разных политиках безопасности важность аудита понимается по-разному: в одних случаях наличие подсистем контроля обязательно, в других - нет. В первом случае имеется функциональная зависимость между всеми регистрирующими клиентами и самой системой контроля, аналогично зависимости сетевых средств защиты, например, управления доступом и аутентификации. В том случае, если подсистема контроля отсутствует, остальная часть системы не может работать до тех пор, пока функции подсистемы аудита не будут восстановлены.
Шифрование применяется для защиты от несанкционированного доступа к конфиденциальной информации при передаче ее через открытую (типа Интернет) сеть [15,79,102]. Применение шифрования для организации системы защиты целиком определяется задачами организации, поэтому в аспекте разработки АБ данная функция будет рассматриваться при выполнении необходимых операций.
Предлагаемый состав данных и процесс манипулирования с ними удобно описывать с использованием понятия фреймов, для чего воспользуемся понятиями фрейм-событие и фрейм-характеристика.
Под фреймом-событием будем понимать в нашем случае задание обобщенной структуры узла схемы передачи информации и правил соотношения типовых узлов. Фрейм-событие состоит из предиката и его аргументов и задается вершиной, определяющей предмет события, и ролевыми дугами, направленными к вершинам, представляющим аргументы предиката. Определение значения фрейма состоит в замещении аргументов предиката типовыми переменными из проблемной среды с проверкой на истинность и ложность высказывания.
Построение модели из рассмотренных компонентов позволяет понять, какие функциональные задачи ставятся перед системами защиты для реализации политики безопасности данного сетевого домена. Это явилось основанием выбора функциональной, а не какой-либо другой модели (например, модели обработки данных, классификационной модели или модели запрос-ответ) [122,124]. Такой подход позволяет рассматривать систему на концептуальном уровне, считая что система состоит из отдельных, взаимодействующих друг с другом функциональных компонент.
Предлагаемая модель может рассматриваться как система, составленная из защитных компонент нескольких типов. Эти компоненты связаны некоторыми ограничениями, образуют систему защиты и взаимодействуют друг с другом, а также с остальной частью системы, например, через функциональные интерфейсы или путем совместного использования информации о состоянии. Взаимодействие с остальной частью системы в модели не отражено.
Функции защиты (SF) применяются к входному и выходному трафику между участниками протокола А и В.
Рассмотрим ситуацию, когда участник протокола А, находящийся за пределами защищенного сетевого домена, пытается установить связь с участником протокола В, находящимся внутри этого домена.
Все данные, передаваемые по сети, можно разделить на порции (пакеты). Данная модель оперирует на одном уровне (или в диапазоне уровней) протокола с порциями обмена этого уровня (соответственно, диапазона) и обрабатывает как входной, так и выходной трафик. Порции обмена обрабатываются системой по отдельности, хотя состояние при этом может быть одним и тем же.
На рис. 4.5 прямоугольники с пометкой SF представляют собой совокупность функций защиты, аргументами которых являются порции обмена, передаваемые между участниками протокола А и В. Аргументом каждой функции SF является часть порции обмена или даже вся порция (ее копия) целиком. Для каждой порции обмена функция SF выдает результат TRUE или FALSE. Если значением функции является TRUE, то порция обмена передается дальше к месту назначения; если значением является FALSE, производится исключение и порция обмена отбраковывается с соответствующей записью в контрольный журнал. Разделение функции SF на две части соответствует передаче данных в двух направлениях.
На рис. 4.6 приведена более подробная модель технологии. Здесь представлена структура функций SF, добавлена функция реализации доступа и отражена степень возможного участия отправителя и получателя. Кроме того, на рис. 4.6. представлен ряд функций защиты, которые применены к коммуникационному трафику, входящему и выходящему из сетевого домена, и, реализуя сетевые средства защиты (AEF), осуществляют аутентификацию (AF), контроль целостности (IF), управление доступом (ACF) и аудит (AudF) в любой комбинации. Модель используется на одном из уровней протокола или в диапазоне этих уровней.
Пример применения разработанного алгоритма для проектирования аб существующей корпоративной сети
В данной таблице принято следующее старшинство операционных систем компании Microsoft: WIN 95-OSR2 или WIN 98, Win NT 4.0, WIN 2000. В качестве ОС Unix могут быть использованы различные ее клоны такие, как FreeBSD, OpenBSD, Linux, Solaris и др. на которые может быть установлена Samba версии 2.0.5 и выше. CFSD (cipher file system demon) - демон для поддержки шифрованной файловой системы.
Отметим, что введенные нами выше классы защищенности приблизительно соответствуют классам защищенности АС, уставленным ГОСТом 24.10485, и рекомендациями Гостехкомиссии России [22-26]. ГОСТ 24.10485 устанавливает девять классов защищенности АС от НСД к информации. Каждый класс характеризуется определенной минимальной совокупностью требований по защите. Классы подразделяются на три группы, отличающиеся особенностями обработки информации в АС. В пределах каждой группы соблюдается иерархия требований по защите в зависимости от ценности (конфиденциальности) информации и, следовательно, иерархия классов защищенности АС. Третья группа классифицирует АС, в которых работает один пользователь, допущенный ко всей информации АС, размещенной на носителях одного уровня конфиденциальности. Группа содержит два класса ЗБ и ЗА. Вторая группа классифицирует АС, в которых пользователи имеют одинаковые права доступа (полномочия) ко всей информации АС, обрабатываемой и (или) хранимой на носителях различного уровня конфиденциальности. Группа содержит два класса 2Б и 2А. Первая группа классифицирует многопользовательские АС, в которых одновременно обрабатывается и (или) хранится информация разных уровней конфиденциальности и не все пользователи имеют право доступа ко всей информации АС. Группа содержит пять классов ІД, 1Г, 1В, 1Би 1 А. В рамках разработанного подхода мы, фактически, рассматриваем только первую группу классов защищенности. Ввиду того, что требования данного ГОСТа на текущий момент несколько устарели, введенные абстрактные классы защищенности (1-5), описанные выше, приблизительно соответствуют классам Гостехкомиссии. Введенный абстрактный класс 5 примерно соответствует классу 1Д, класс 4 - классу 1Г и т.д.
Рассмотрим защиту от внешних воздействий, т.е. в рамках нашей модели защиту со стороны Интернет. Из рис. 5.2 следует, что внешнюю опасность для защищаемой сети представляют потоки 1=1,2,3,4. В настоящее время устройством, обеспечивающим защиту от внешних угроз, является межсетевой фильтр [87,94,102]. Здесь под межсетевым фильтром будем понимать комплекс программно-аппаратных решений, который защищает распределенные вычислительные системы и сетевые приложения от несанкционированных коммуникационных трафиков из Интернет в защищаемую сеть. Функции, возложенные на межсетевой фильтр, в принципе, могут находиться в любом месте защищаемой сети, но исходя из требований сохранения максимальной пропускной способности канала и минимальной стоимости дополнительно устанавливаемого оборудования и программного обеспечения, межсетевой фильтр, который является шлюзом между защищаемой локальной сетью и открытой сетью Интернет, должен располагаться на входе в защищаемую сеть. При этом межсетевой фильтр может быть реализован как на отдельном персональном компьютере, так и на нескольких компьютерах (или устройствах).
Возможна ситуация, при которой организация имеет больше одного выхода в Интернет. В этом случае необходима установка межсетевого экрана на каждый из имеющихся выходов в общедоступную сеть.
На компьютере (компьютерах), выполняющем функции межсетевого фильтра необходимо установить функцию фильтрации пакетов (по разрешенным портам или сервисам, исходя из политики безопасности), идентификации, прокси-сервера (для скрытия реальной топологии локальной сети), NAT - функцию трансляции сетевого адреса, функцию шифрования и расшифрования данных (для первого, второго и третьего классов защищенности), являющихся коммерческой тайной. Там же целесообразно разместить функцию аудита (для классов защищенности выше пятого). Объем аудита зависит от класса защищенности системы.
При наличии WEB-сервера, находящегося на границе или вынесенного за пределы защищенного периметра, для классов защищенности выше третьего подключение к нему должно производиться по HTTPS-протоколу.
При рассмотрении защиты от внутренних воздействий отметим, что установка межсетевого фильтра, к сожалению, не обеспечивает защиту локальной сети от внутренних атак. Для внутренней защиты локальной сети на сервере, который является контроллером домена (PDC), необходимо реализовать следующие функции защиты - идентификация, аутентификация, аудит, контроль целостности информации и шифрование информации в соответствии с требуемым классом защищенности. Например, при пятом классе защищенности в рамках аудита проводится только регистрация и учет входа/выхода субъектов доступа в/из системы (узла сети), а в классах ниже второго не предусматривается шифрование информационных потоков внутри сети. Авторизация прав пользователей на доступ к ресурсам должна осуществляться в зависимости от имени пользователя, группы или принадлежности к домену, исходя из политики безопасности. Если серверов несколько (например, для каждого домена свой сервер или существует PDC -резервный сервер), то на каждом из них необходимо реализовать все данные функции защиты.
На рабочих станциях следует реализовать возможность идентификации и аутентификации при посредстве сервера (PDC) (как доверенной стороны). Авторизация пользователя (при входе в систему) осуществляется на сервере, который является контроллером домена для данного пользователя (в соответствии с политикой безопасности). Кроме того, на рабочих станциях рекомендуется запретить вход в систему всем пользователям, за исключением пользователя, которому «принадлежит» данный компьютер. Если требуется класс защищенности выше третьего, то на каждой рабочей станции необходимо предусмотреть средства для криптографической защиты (шифрования) потоков информации (для первого и второго класса) и информации на дисках (для первого класса защищенности).
При наличии SQL сервера (или сервера с БД, или почтового сервера), на нем необходимо реализовать функции идентификации, аутентификации и аудита. Причем авторизация прав на доступ к информации должна происходить на SQL сервере (сервере с БД или почтовом сервере). Имеется в виду, что пользователь должен иметь несколько различных паролей для доступа к различным типам сервисов. Например, имя и пароль для входа в сеть и для доступа к почтовому ящику должны быть различны. Используемые протоколы почтовых серверов должны зависеть от требуемого класса защищенности системы. Нам представляется целесообразным для третьего, четвертого и пятого классов использовать протоколы SMTP и РОРЗ, для второго класса - SMTP через SSL и РОРЗ или IMAP4 через SSL, для первого класса защищенности - SMTP через SSL и IMAP4 через SSL.
Если требуется 1 или 2 класс защищенности, то на внутренний WWW-сервер следует установить средства для поддержки протокола https, а на FTP-сервер - средства для поддержки SFTP.
