<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Информационная безопасность &#187; Защита сетевых процессов обмена данными</title>
	<atom:link href="http://www.microfinance.uz/category/model-informacionnyx-potokov/zashhita-setevyx-processov-obmena-dannymi/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.microfinance.uz</link>
	<description>Бухгалтерский и налоговый учёт</description>
	<lastBuildDate>Thu, 26 Jan 2012 14:59:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
		<item>
		<title>Защита сетевых процессов обмена данными</title>
		<link>http://www.microfinance.uz/zashhita-setevyx-processov-obmena-dannymi/</link>
		<comments>http://www.microfinance.uz/zashhita-setevyx-processov-obmena-dannymi/#comments</comments>
		<pubDate>Mon, 06 Oct 2008 06:21:18 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Защита сетевых процессов обмена данными]]></category>

		<guid isPermaLink="false">http://www.microfinance.uz/zashhita-setevyx-processov-obmena-dannymi/</guid>
		<description><![CDATA[Те, кто прочитал раздел &#8220;Классификация средств обработки информации: стандарт CCITSE&#8221; главы 6, возможно, обратили внимание на классы FTP и FCS, которые составляют для системы основу безопасного обмена данными с другими системами. Это как раз те механизмы обеспечения защиты обмена данными, когда информация не остается незащищенной ни на каком из этапов перемещения между системами. В. основном, [...]]]></description>
			<content:encoded><![CDATA[<p>Те, кто прочитал раздел &#8220;Классификация средств обработки информации: стандарт CCITSE&#8221; главы 6, возможно, обратили внимание на классы FTP и FCS, которые составляют для системы основу безопасного обмена данными с другими системами. Это как раз те механизмы обеспечения защиты обмена данными, когда информация не остается незащищенной ни на каком из этапов перемещения между системами. В. основном, работа таких механизмов основана, конечно, на работе криптографических средств.<span id="more-51"></span><br />
Если информационное пространство предприятия ориентировано на стек TCP/IP и есть возможность в случае необходимости дорабатывать системы, то в настоящее время с появлением новых механизмов и протоколов защиты обеспечивать безопасность такого пространства становится проще. В главе 22, посвященной сетевым протоколам безопасности, будут затронуты такие средства, как IPSec, ISAKMP, IKE, SSL и пр., которые делают обмен данными защищенным и работают одинаково вне зависимости от того, располагаются ли информационные системы в одной локальной сети или используют в качестве канала связи Интернет.<br />
При этом независимо от того, используется ли в качестве сетевого протокола TCP/IP или другой стек протоколов, следует помнить о классической семиуровневой сетевой модели (OSI — Open System Interconnection). Это означает, что построение механизмов защиты должно также носить многоуровневый характер. Проще пояснить это на примерах. Если нас интересует только защита конфиденциальности и целостности данных в приложениях, то, обычно, этот вопрос можно решить на верхних уровнях (приложения или представления данных). Если встает вопрос об обеспечении надежной доставки — акценты смещаются к транспортному уровню. Если обмен информацией между системами должен скрывать внутреннюю сетевую структуру систем, то речь идет о сетевом уровне. Если необходимо учесть опасность широковещательных сообщений (например, угрозы использования пассивного прослушивания сегмента), следует говорить о канальном уровне. Физический уровень обычно затрагивается, когда речь идет о защите от побочных электромагнитных излучениях или возможности физического внедрения злоумышленника в канал связи. Когда в главе 5 рассматривалась проблема инвентаризации информационных систем, одними из рекомендуемых ко включению в обследование вопросов были источники получения и цели отправления информации. Если это обследование было произведено качественно, то становится легко составить схему информационных потоков (причем не виртуально, а именно нарисовать на бумаге). Возможно, части этой схемы следует показать обследуемым и опрашиваемым пользователям для уточнения. Теперь, имея подобную схему, можно проанализировать тонкие места построенной или планируемой системы защиты данных.<br />
Если обе системы, между которыми происходит обмен данными, поддерживают одни и те же протоколы безопасности, то при соответствующей настройке они смогут обеспечить требуемый уровень безопасности. А если одна из систем представляет собой &#8220;черный ящик&#8221; без возможности модификаций и не может импортировать/экспортировать никакие другие данные, кроме как в обычном текстовом или другом незащищенном формате?<br />
Здесь необходимо подойти к вопросу оценки необходимости защиты с точки зрения классификации информации, используемой в системе, т. е. определить, к какой категории относится данная информация, какая составляющая для нее наиболее критична: конфиденциальность, целостность, доступность и т. д. Далее необходимо проанализировать, какие альтернативные средства защиты, предоставляемые системой, можно использовать. Возможно, система может рассчитывать некую контрольную сумму экспортируемых/импортируемых данных (аналог электронно-цифровой подписи), либо она ведет расширенный регистрационный журнал загруженных/выгруженных данных и т. п. Необходимо рассмотреть, как имеющиеся средства могут быть использованы второй системой.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.microfinance.uz/zashhita-setevyx-processov-obmena-dannymi/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

