Модель OSI (Open System Interconnect Reference Model, Эталонная модель взаимодействия открытых систем) представляет собой универсальный стандарт на взаимодействие двух систем (компьютеров) через вычислительную сеть.

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

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

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

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

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

Вернемся к примеру: приложения не знают о том, что их данные преобразуются именно путем фрагментации/сборки, им достаточно знать то, что нижний уровень предоставляет им некий “правильный” сервис преобразования данных. Если же для какой-то другой сети понадобится не фрагментация/сборка пакетов, а, скажем, перестановка местами четных и нечетных бит, то процессы рассматриваемого уровня будут заменены, но приложения ничего не заметят, так как их интерфейсы с нижележащим уровнем стандартизованы, а конкретные действия нижележащих уровней скрыты от них.

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

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

1.1.1. Уровни модели OSI

Ниже перечислены (в направлении сверху вниз) уровни модели OSI и указаны их общие функции.

Уровень приложения (Application) - интерфейс с прикладными процессами.

Уровень представления (Presentation) - согласование представления (форматов, кодировок) данных прикладных процессов.

Сеансовый уровень (Session) - установление, поддержка и закрытие логического сеанса связи между удаленными процессами.

Транспортный уровень (Transport) - обеспечение безошибочного сквозного обмена потоками данных между процессами во время сеанса.

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

Канальный уровень (Data Link) - управление каналом передачи данных, управление доступом к среде передачи, передача данных по каналу, обнаружение ошибок в канале и их коррекция.

Физический уровень (Physical) - физический интерфейс с каналом передачи данных, представление данных в виде физических сигналов и их кодирование (модуляция).

1.1.2. Инкапсуляция и обработка пакетов

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

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

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

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

Модель OSI предложена достаточно давно, однако протоколы, на ней основанные, используются редко, во-первых, в силу своей не всегда оправданной сложности, во-вторых, из-за существования хотя и не соответствующих строго модели OSI, но уже хорошо зарекомендовавших себя стеков протоколов (например, TCP/IP).

Поэтому модель OSI сто ит рассматривать, в основном, как опорную базу для классификации и сопоставления протокольных стеков.

1.2. Стек протоколов TCP/IP

TCP/IP - собирательное название для набора (стека) сетевых протоколов разных уровней, используемых в Интернет. Особенности TCP/IP:

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

Рис. 1.2.1. Стек протоколов TCP/IP

Стек протоколов TCP/IP делится на 4 уровня: прикладной (application ), транспортный (transport ), межсетевой (internet ) и уровень доступа к среде передачи (network access ). Термины, применяемые для обозначения блока передаваемых данных, различны при использовании разных протоколов транспортного уровня - TCP и UDP, поэтому на рисунке 1.2.1 изображено два стека. Как и в модели OSI, данные более верхних уровней инкапсулируются в пакеты нижних уровней (см. рис. 1.2.2).

Рис. 1.2.2. Пример инкапсуляции пакетов в стеке TCP/IP

Примерное соотношение уровней стеков OSI и TCP/IP показано на рис. 1.2.3.

Рис. 1.2.3. Соотношение уровней стеков OSI и TCP/IP

Ниже кратко рассматриваются функции каждого уровня и примеры протоколов. Программа, реализующая функции того или иного протокола, часто называется модулем, например, “IP-модуль”, “модуль TCP”.

1.2.1. Уровень приложений

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

Распространенными примерами приложений являются программы telnet, ftp, HTTP-серверы и клиенты (WWW-броузеры), программы работы с электронной почтой.

Для пересылки данных другому приложению, приложение обращается к тому или иному модулю транспортного уровня.

1.2.2. Транспортный уровень

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

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

На транспортном уровне работают два основных протокола: UDP и TCP .

TCP (Transmission Control Protocol - протокол контроля передачи) - надежный протокол с установлением соединения : он управляет логическим сеансом связи (устанавливает, поддерживает и закрывает соединение) между процессами и обеспечивает надежную (безошибочную и гарантированную) доставку прикладных данных от процесса к процессу.

Данными для TCP является не интерпретируемая протоколом последовательность пользовательских октетов, разбиваемая для передачи по частям. Каждая часть передается в отдельном TCP-сегменте. Для продвижения сегмента по сети между компьютером-отправителем и компьютером-получателем модуль TCP пользуется сервисом межсетевого уровня (вызывает модуль IP).

Более подробно работа протокола TCP рассматривается в главе 3 .

Все приложения, приведенные как пример в предыдущем пункте, пользуются услугами TCP.

UDP (User Datagram Protocol, протокол пользовательских дейтаграмм) фактически не выполняет каких-либо особых функций дополнительно к функциям межсетевого уровня (протокола IP, см. и гл. 2). Протокол UDP используется либо при пересылке коротких сообщений, когда накладные расходы на установление сеанса и проверку успешной доставки данных оказываются выше расходов на повторную (в случае неудачи) пересылку сообщения, либо в том случае, когда сама организация процесса-приложения обеспечивает установление соединения и проверку доставки пакетов (например, NFS).

Пользовательские данные, поступившие от прикладного уровня, предваряются UDP-заголовком, и сформированный таким образом UDP-пакет отправляется на межсетевой уровень.

UDP-заголовок состоит из двух 32-битных слов:

Значения полей:

Source Port - номер порта процесса-отправителя.

Destination Port - номер порта процесса-получателя.

Length - длина UDP-пакета вместе с заголовком в октетах.

Checksum - контрольная сумма. Контрольная сумма вычисляется таким же образом, как и в TCP-заголовке (см. п. 3.2); если UDP-пакет имеет нечетную длину, то при вычислении контрольной суммы к нему добавляется нулевой октет.

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

При получении пакета от межсетевого уровня модуль UDP проверяет контрольную сумму и передает содержимое сообщения прикладному процессу, чей номер порта указан в поле “Destination Port”.

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

Максимальная длина UDP-сообщения равна максимальной длине IP-дейтаграммы (65535 октетов) за вычетом минимального IP-заголовка (20) и UDP-заголовка (8), т.е. 65507 октетов. На практике обычно используются сообщения длиной 8192 октета.

Примеры прикладных процессов, использующих протокол UDP: NFS (Network File System - сетевая файловая система), TFTP (Trivial File Transfer Protocol - простой протокол передачи файлов), SNMP (Simple Network Management Protocol - простой протокол управления сетью), DNS (Domain Name Service - доменная служба имен).

1.2.3. Межсетевой уровень и протокол IP

Основным протоколом этого уровня является протокол IP (Internet Protocol).

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

Не все компьютеры могут непосредственно связаться друг с другом; часто для того, чтобы передать дейтаграмму по назначению, требуется направить ее через один или несколько промежуточных компьютеров по тому или иному маршруту. Задача определения маршрута для каждой дейтаграммы решается протоколом IP.

Когда модуль IP получает дейтаграмму с нижнего уровня, он проверяет IP-адрес назначения. Если дейтаграмма адресована данному компьютеру, то данные из нее передаются на обработку модулю вышестоящего уровня (какому конкретно - указано в заголовке дейтаграммы). Если же адрес назначения дейтаграммы - чужой, то модуль IP может принять два решения: первое - уничтожить дейтаграмму, второе - отправить ее дальше к месту назначения, определив маршрут следования - так поступают промежуточные станции - маршрутизаторы.

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

Если модуль IP по какой-либо причине не может доставить дейтаграмму, она уничтожается. При этом модуль IP может отправить компьютеру-источнику этой дейтаграммы уведомление об ошибке; такие уведомления отправляются с помощью протокола ICMP, являющегося неотъемлемой частью модуля IP. Более никаких средств контроля корректности данных, подтверждения их доставки, обеспечения правильного порядка следования дейтаграмм, предварительного установления соединения между компьютерами протокол IP не имеет. Эта задача возложена на транспортный уровень.

Многие IP-адреса имеют эквивалентную форму записи в виде доменного имени (например, IP-адрес 194.84.124.4 может быть записан как maria.vvsu.ru). Преобразование между этими двумя формами выполняется службой DNS (Domain Name Service). Доменные имена обсуждаются в курсе “Введение в Интернет”, служба DNS рассматривается в курсе “Технологии Интернет” . Доменные имена введены для удобства использования человеком. Все TCP/IP-процессы и коммуникационное оборудование используют только IP-адреса.

Протоколы IP и ICMP подробно рассмотрены в главе 2 .

1.2.4. Уровень доступа к среде передачи

Функции этого уровня:

• отображение IP-адресов в физические адреса сети (MAC-адреса, например, Ethernet-адрес в случае сети Ethernet). Эту функцию выполняет протокол ARP (см. раздел 2.6);
• инкапсуляция IP-дейтаграмм в кадры для передачи по физическому каналу и извлечение дейтаграмм из кадров. При этом не требуется какого-либо контроля безошибочности передачи (хотя он может и присутствовать), поскольку в стеке TCP/IP такой контроль возложен на транспортный уровень или на само приложение. В заголовке кадров указывается точка доступа к сервису (SAP, Service Access Point) - поле, содержащее код протокола межсетевого уровня, которому следует передать содержимое кадра (в нашем случае это протокол IP);
• определение метода доступа к среде передачи - то есть способа, с помощью которого компьютер устанавливает свое право на произведение передачи данных (передача токена, опрос компьютеров, множественный доступ с детектированием коллизий и т.п.).
• определение представления данных в физической среде;
• пересылка и прием кадра.

Стек TCP/IP не подразумевает использования каких-либо определенных протоколов уровня доступа к среде передачи и физических сред передачи данных. От уровня доступа к среде передачи требуется наличие интерфейса с модулем IP, обеспечивающего передачу дейтаграммы между уровнями. Также требуется обеспечить преобразование IP-адреса узла сети, на который передается дейтаграмма, в MAC-адрес. Часто в качестве уровня доступа к среде передачи могут выступать целые протокольные стеки, тогда говорят об IP поверх ATM, IP поверх IPX, IP поверх X.25 и т.п.

Инкапсуляция пакетов и промежуточные узлы

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

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

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

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

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

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

Протоколы, основанные на модели OSI используются редко:

В силу своей не всегда оправданной сложности;

Поэтому модель OSI - опорная база для классификации и сопоставления протокольных стеков.

Модель и четыре уровня стеков TCP/IP

Сеть Internet отличается от других сетей своими протоколами и в первую очередь протоколами TCP/IP.

Протокол - это набор правил, определяющий характер взаимодействия пользователей, последовательность выполнения ими действий при обмене информацией.

Термин TCP/IP означает все, что связано с протоколами взаимодействия между компьютерами в сети. Данный протокол представляет собой совокупность нескольких протоколов, прикладные программы и даже саму сеть.

Свое название протокол TCP/IP получил от двух типов протоколов связи:

Transmission Control Protocol (TCP);

Internet Protocol (IP).

Таким образом, TCP/IP - собирательное название для стека сетевых протоколов разных уровней, используемых в Internet.

Особенности TCP/IP.

Открытые стандарты протоколов, разрабатываемые независимо от программного и аппаратного обеспечения;

Независимость от физической среды передачи;

Система уникальной адресации;

Стандартизованные протоколы высокого уровня для распространенных пользовательских сервисов.

Стек протоколов TCP/IP делится на четыре уровня :

I.Прикладной (application ). Приложения, работающие со стеком TCP/IP, могут также выполнять функции уровней представления и частично сеансового модели OSI.

Распространенными примерами приложений являются программы telnet, ftp, WWW-серверы и клиенты (Интернет-браузеры), программы работы с электронной почтой. Для пересылки данных через сеть другому приложению оно обращается к тому или иному модулю транспортного уровня;

II.Транспортный (transport). Протоколы данного уровня обеспечивают прозрачную (сквозную) доставку данных между двумя прикладными процессами. Для передачи и получения данных, отправляемых друг другу, они используют межсетевой уровень. На транспортном уровне работают два основных протокола:

1. TCP (Transmission Control Protocol) - надежный протокол с установлением соединения: он управляет логическим сеансом свя зи (устанавливает, поддерживает и закрывает соединение) между процессами и обеспечивает надежную (безошибочную и гарантированную) доставку прикладных данных от процесса к процессу;

Таким образом, протокол TCP обеспечивает надежную доставку, безошибочность и правильный порядок приема передаваемых данных.

Протокол TCP (Transmission Control Protocol , Протокол контроля передачи) обеспечивает сквозную доставку данных между прикладными процессами, запущенными на узлах, взаимодействующих по сети.

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

Протокол TCP рассматривает данные клиента как непрерывный неинтерпретируемый поток пакетов. TCP разделяет этот поток на части для пересылки на другой узел в TCP -сегментах некоторого размера. Для отправки или получения сегмента модуль TCP вызывает модуль IP .

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

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

В сети Internet используется большое число и других протоколов, однако эту сеть часто называют TCP/IP сетью, так как эти два протокола являются важнейшими.

2. UDP (User Datagram Protocol ) - протокол дейтаграмм пользователя - является ненадежным протоколом без установления соединения: это значит, что ни логический сеанс связи , ни надежная доставка прикладных данных этим протоколом не обеспечиваются. Фактически UDP не предоставляет никаких услуг, кроме мультиплексирования пакетов с прикладными данными - то есть направления данных тому или иному приложению в зависимости от номера порта. Услугами UDP пользуются, например, доменная система имен (DNS), сетевая файловая система NFS;

III. Сетевой (межсетевой, или Internet ). Основным протоколом этого уровня является протокол IP (Internet Protocol). Этот протокол является центром, вокруг которого строится весь стек TCP/IP.

Протокол IP отвечает за поиск маршрута (или маршрутов) в Internet от одного компьютера к другому через множество промежуточных сетей, шлюзов и маршрутизаторов и передачу блоков данных по этим маршрутам.

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

Протокол IP обрабатывает каждую дейтаграмму как независимую единицу, не имеющую связи ни с какими другими дейтаграммами в Internet. После того, как дейтаграмма отправляется в сеть, ее дальнейшая судьба никак не контролируется отправителем (на уровне протокола IP ). Если дейтаграмма не может быть доставлена, она уничтожается. Узел, уничтоживший дейтаграмму, может оправить по обратному адресу ICMP-сообщение , о причине сбоя.

Одна из основных задач, решаемых протоколом IP , - маршрутизация дейтаграмм, т.е. определение пути следования дейтаграммы от одного узла сети к другому на основании адреса получателя.

Таким образом, протокол IP доставляет блоки данных, называемые дейтаграммами, от одного IP-адреса к другому через компьютерную сеть. IP-адрес является уникальным 32-битным идентификатором компьютера (точнее, его сетевого интерфейса). Данными для дейтаграммы является блок данных, передаваемых IP-модулю транспортным уровнем. IP-модуль предваряет эти данные заголовком, содержащим IP-адреса отправителя и получателя и другую служебную информацию, и сформированная таким образом дейтаграмма передается на уровень доступа к сети для отправки по каналу передачи данных;

IV. Уровень доступа к сети (network access ), который выполняет следующие функции:

· отображение IP-адресов в физические адреса сети. Эту функцию выполняет протокол разрешения адресов ARP (Address Resolution Protocol);

· инкапсуляция IP-дейтаграмм в кадры для передачи по физическому каналу и извлечение дейтаграмм из кадров. При этом не требуется какого-либо контроля безошибочности передачи, поскольку в стеке TCP/IP такой контроль возложен на транспортный уровень или на само приложение;

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

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

· пересылка и прием кадра.

Часто в качестве уровня доступа к сети выступают целые протокольные стеки; тогда говорят об IP поверх ATM, IP поверх IPX и т. д.

Governance Institute, ITGI), который является де-юре автором всех методик, продвигаемых ISACA. Дополнительную информацию об ITGI можно найти на его официальном сайте.

Взаимосвязи трех основных методологий, предлагаемых ISACA, показаны на рис. 15.1 . Это методологии COBIT, Val IT и Risk IT.

Рис. 15.1.

Центральной в этой картине является методология COBIT, последний релиз которой, COBIT 4.1 (CobiT, 2007) , мы сейчас кратко рассмотрим.

COBIT 4.1

Аббревиатура "COBIT" с трудом поддается адекватному переводу на русский язык из-за многозначности английского слова control , широко используемого в терминологии COBIT. Опубликованный русский перевод названия методологии Control Objectives for Information and Related Technology (COBIT) - "Цели контроля для информационных и смежных технологий" (COBIT 4.1 рус, 2008), на мой взгляд, содержательно неточен. Я предпочитаю менее компактный, но более понятный и передающий смысл документа перевод: "Цели управления информационными и связанными с ними технологиями", хотя возможны и другие варианты. Вообще, я буду использовать разные варианты перевода слова control в зависимости от контекста. Чаще других будут употребляться термины "средство управления" или просто "управление".

Существует целый ряд публикаций по COBIT, подготовленных ISACA. Значительная часть их доступна только членам ISACA, и только несколько документов - всем желающим. К сожалению, у меня нет доступа к полному комплекту документов ISACA, поэтому все дальнейшее изложение базируется только на открытых источниках, в первую очередь (COBIT, 2007). Я использовал также русский перевод этого документа (CobiT 4.1 рус, 2008).

В связи с этим нужно сделать важную оговорку. Все неточности, недоговоренности и неясности, встречающиеся в (CobiT, 2007), возможно, разъясняются в других документах по COBIT, поэтому не всегда следует относить их на счет несовершенства и недоработанности самой методологии.

Концепция и основные понятия COBIT

По утверждению авторов, COBIT представляет собой совокупность признанных практик (good practices ) методов управления ИТ, изложенных с использованием процессного подхода . Акцент в COBIT делается не на детальном описании процессов, а на методах их организации, оценки, измерения и т. п. С точки зрения COBIT, для того, чтобы ИТ удовлетворяли требованиям бизнеса, менеджмент должен позаботиться о том, чтобы разработать и внедрить специальную систему управления ИТ. Методология COBIT является кандидатом на роль такой системы, поскольку она:

• устанавливает связь между ИТ и бизнесом;
• использует общепризнанный процессный подход для описания ИТ-активностей;
• выявляет основные ИТ-ресурсы, которые следует использовать;
• определяет цели управления для рассмотрения их менеджментом.

Для решения первой из перечисленных задач в COBIT вводится понятие ИТ-цели, обусловленной целями бизнеса. Это принципиально важное понятие, которое не встречалось ни в одной из рассмотренных ранее методик. Обратимся, например, к ITIL .

На рис. 15.2 показаны взаимосвязи между бизнес-услугой, ИТ-услугой, целями бизнеса и место , которое должны были бы занимать цели ИТ в парадигме ITIL v.3. Видно, что достижение целей бизнеса в ITIL обеспечивается опосредованно за счет того, что ИТ-услуги создаются и развиваются как инструмент, обеспечивающий реализацию бизнес-услуг и в точном соответствии с требованиями последних. Бизнес-услуги через бизнес-процессы связаны с целями бизнеса. Таким образом, никакая ИТ-услуга не может появиться вне связи с целью бизнеса, т. е. в модели ITIL v.3 "цель ИТ" просто лишняя.

Рис. 15.2.

Это означает, что в COBIT принята другая, нежели в ITIL , модель взаимодействия бизнеса и ИТ. Однажды определив долгосрочные цели ИТ, связанные с целями бизнеса, ИТ-организация далее развивается как бы автономно до момента, когда эти цели будут скорректированы. Это приводит к появлению в модели процессов COBIT такого процесса, как стратегическое планирование ИТ (см. ниже). В ITIL v.3 подобного процесса нет, а есть только Портфель услуг, наполнение которого в каждый момент времени и определяет все планы развития ИТ. Я сравниваю COBIT именно с ITIL v.3, потому что COBIT тоже придерживается взгляда на взаимодействие ИТ-организации и бизнеса как на предоставление и потребление услуг, использует понятия Портфеля и Каталога услуг, хотя и на гораздо менее конкретном уровне, чем ITIL v.3.

Методы построения целей ИТ остаются за рамками COBIT. В приложениях к (COBIT, 2007) приведены лишь примеры условных целей бизнеса и соответствующих им столь же условных целей ИТ. Между тем попытки применить этот подход на практике показывают, что построение целей ИТ не является тривиальной задачей. Во-первых, цели бизнеса не являются постоянными, застывшими, и далеко не везде и не всегда их изменение происходит дискретно в запланированные сроки. Непонятно, как в этом случае организовать непрерывную коррекцию соответствующих целей ИТ. Во-вторых, цели бизнеса и ИТ формулируются на совершенно разных языках, и это порождает проблемы. Такие понятия как, например, "рентабельность", "прозрачность", "прибыльность", обычные для бизнес-языка, объективно оказываются очень сложными и многозначными при попытке перевода их на язык ИТ. Для выполнения работы по переводу целей бизнеса в цели ИТ нужен переводчик, одинаково хорошо владеющий языком бизнеса и техническим языком ИТ и пользующийся полным доверием бизнеса и ИТ-специалистов. Даже если переводчиком служит квалифицированный и профессиональный независимый консультант, обеспечить доверие к переводу, особенно со стороны бизнеса, удается далеко не всегда. Таким образом, попытка построить управление, отталкиваясь от целей ИТ, порождает целый ряд сложностей и во всяком случае не является единственно возможным подходом к стратегическому планированию ИТ.

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

В основе системы - совокупность средств и механизмов управления, называемых в оригинале controls . Сюда включаются "политики, процедуры, практики и организационные структуры, сконструированные так, чтобы обеспечить то, что цели бизнеса достигаются, а нежелательные события исключаются или распознаются и корректируются". Точных определений, эталонного перечня средств управления или хотя бы набора примеров книга (COBIT, 2007) не дает.

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

На уровне бизнес-процессов, согласно COBIT, существует две разновидности средств управления процессом: ручные (например, распределение ролей в процессе) и автоматические (разработанные приложения, выполняющие отдельные задачи). Последние в оригинале называются "средствами управления, реализованными в виде приложений" ( application controls); я буду для краткости называть их просто "автоматическими". Бизнес отвечает за определение и использование как ручных, так и автоматических средств управления. Роль ИТ-организации - только поддерживать автоматические средства управления. В COBIT приводятся следующие примеры автоматических средств управления:

• средства обеспечения законченности транзакции;
• средства обеспечения точности информации;
• средства обеспечения достоверности вводимых данных;
• средства управления правами доступа;
• средства распределения ролей по выполнению транзакций.

Еще одна категория средств управления возникает в связи с взглядом, согласно которому ИТ-организация отвечает за предоставление ИТ-услуг, общих для нескольких бизнес-процессов или даже для всего предприятия. Средства управления деятельностью по предоставлению ИТ-услуг называются общими ( general ). Примерами общих средств управления ИТ служат, согласно COBIT:

• средства управления разработкой систем;
• средства управления изменениями;
• средства обеспечения информационной безопасности;
• средства обеспечения функционирования компьютеров.

Сами по себе средства управления в COBIT не изучаются, и структура их для COBIT не представляет интереса. Они важны только как объект целеполагания, т. е. как то, чему можно сопоставить цель. Эти цели называются целями управления (control objectives ); они играют фундаментальную роль в концепции COBIT.

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

Для того чтобы как-то структурировать этот набор разнородных целей, в COBIT используется собственная модель процессов управления ИТ, называемых ИТ-процессами; каждый процесс в модели состоит из активностей. С помощью модели процессов строится иерархия целей управления. На самом верхнем уровне расположены цели управления ИТ (или цели ИТ), затем - цели управления процессами, и на нижнем уровне - цели управления активностями. Цели общих средств управления выражаются целями процессов и активностей. Из этой стройной картины выпадают цели приложений, да и вообще, понятие "цели" применительно к автоматическому средству управления выглядит довольно странно. В COBIT рекомендованные цели приложений для всех приложений одинаковы и сформулированы следующим образом ( нумерация COBIT сохранена).

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

АС2. Сбор и ввод исходных данных

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

АС3. Проверка на точность, завершенность и аутентичность

Обеспечить точность, завершенность и достоверность транзакции. Проверять введенные данные, редактировать или возвращать для исправления как можно ближе к точке ввода.

АС4. Работа с целостностью и достоверностью

Поддерживать целостность и достоверность данных на протяжении всего цикла обработки. Обнаружение ошибочных транзакций не отражается на обработке правильных транзакций.

АС5. Выходные проверки

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

АС6. Аутентификация и целостность транзакции

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

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

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

• сравнительный анализ 1в оригинале - benchmarking эффективности и развитости процессов управления ИТ с помощью модели зрелости, близкой к модели CMM ;
• использование иерархии целей и метрик для ИТ в целом, ИТ-процессов и составляющих их активностей.

Более подробно об оценке эффективности процессов будет говориться в разделе, посвященном ИТ-процессам.

Прежде чем переходить к более подробному анализу структуры и содержания модели ИТ-процессов COBIT, стоит сделать два замечания. Во-первых, несмотря на постоянно акцентируемую поддержку взаимосвязи методов управления ИТ и бизнеса, COBIT не предлагает ничего нового в этой сфере. Задача обеспечения взаимосвязи декларируется (как и в множестве других методик, например SPICE ), но конструктивных способов ее решения не даётся. Во-вторых, иерархия целей управления, о которой столько говорится, играет на самом деле чисто декоративную роль: никаких специфических задач, связанных с этой иерархией, не ставится и специальных методических приемов не используется (сразу оговорюсь, что эта иерархия , возможно, используется при аудите, о методике проведения которого в (COBIT, 2007) ничего не говорится). Пожалуй, единственное, для чего эта иерархия может оказаться полезной, - это разработка общего языка для руководителей бизнеса, ИТ-руководителей и специалистов. С этой точки зрения, однако, система понятий, выстроенная COBIT, не оправдывает своего назначения: объем усилий, потраченных на то, чтобы разобраться в невнятном обосновании COBIT, в конечном итоге не вознаграждается, поскольку не приводит к простому и компактному набору убедительных положений, которые могли бы лечь в основу такого языка. Безусловными недостатками (COBIT, 2007) являются многословие, избыток плохо определенных терминов, ненужные "формальные" рассуждения, использующиеся для объяснения очевидных вещей, и поверхностность изложения. Еще хуже обстоит дело с русским переводом (COBIT 4.1 рус, 2008), авторы которого вынуждены были буквально следовать невнятному и косноязычному английскому оригиналу и не могли изложить материал своими словами.

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

Таблица 3.3. Сравнение некоторых стандартов аудита ИТ

Ассоциация ISACA, в отличие от других, занимается открытым аудитом информационных систем. Она основана в 1969 году и в настоящее время объединяет более 35 тыс. членов из более чем 100 стран, в том числе и России. Ассоциация IS АС А координирует деятельность более чем 38 тыс. сертифицированных аудиторов информационных систем (CISA - Certified Information System Auditor), имеет свою систему стандартов в этой области, ведет исследовательские работы, занимается подготовкой кадров, проводит конференции. Ассоциация ISACA под аудитом информационной безопасности в информационной системе понимает процесс сбора сведений, позволяющих установить, обеспечиваются ли безопасность ресурсов компании, необходимые параметры целостности и доступности данных, достигаются ли цели предприятии в части эффективности информационных технологий.

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

Концепция изложена в документе под названием CobiT 3rd Edition (Control Objectives for Information and Related Technology), который состоит из шести частей:

Часть 1: Резюме для руководителей (Executive Summary);

Часть 2: Определения и основные понятия (Framework). Помимо определений и основных понятий в этой части сформулированы требования к ним;

Часть 3: Цели контроля (Control Objectives);

Часть 4: Принципы аудита (Audit Guidelines);

Часть 5: Набор средств внедрения (Implementation Tool Set);

Часть 6: Принципы управления (Management Guidelines).

Третья часть этого документа в некотором смысле аналогична международному стандарту ISO 17799:2005 (BS 7799-1:2002). Примерно так же подробно приведены практические рекомендации по разработке политик безопасности и управлению информационной безопасностью в целом, но модели систем управления в сравниваемых стандартах сильно различаются. Стандарт CobiT (Control Objectives for Information and Related Technology) - пакет открытых документов, первое издание которого было опубликовано в 1996 году. Кратко основная идея стандарта CobiT выражается следующим образом: все ресурсы информационной системы должны управляться набором естественно сгруппированных процессов (рис. 3.10) для обеспечения компании необходимой и надежной информацией.

Рас. 3.10. Процессы управления ресурсами информационной системы

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

Рис. 3.11. Объекты контроля и управления информационными технологиями

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

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

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