Реферат: Безопасность в распределенных системах - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Безопасность в распределенных системах

Банк рефератов / Военная кафедра, гражданская оборона

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 249 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Безопасность в распределенных системах Введение Концентрация информации в компьютерах — аналогично концентрации наличных денег в банках — заставляет все более усиливать контроль в целях защиты информации . Юридиче ские вопросы , частная тайна , национальная безо пасность — все эти соображения т ребу ют усиления внутреннего контроля в коммерческ их и правительственных организациях . Работы в этом направлении привели к появлению нов ой дисциплины : безопасность информации . Специалист в области безопасности информации отвечает за разработку , реализацию и экспл уатацию системы обеспечения информационной безоп асности , направленной на поддержание целостности , пригодности и конфиденциальности накопленной в организации информации . В его функции входит обеспечение физической (технические сред ства , линии связи и удаленные комп ьютеры ) и логической (данные , прикладные програ ммы , операционная система ) защиты информационных ресурсов. Сложность создания системы защиты информа ции определяется тем , что данные могут быт ь похищены из компьютера и одновременно о ставаться на месте ; ценность некоторых д анных заключается в обладании ими , а не в уничтожении или изменении. Проблема защиты компьютерных сетей от несанкционированного доступа приобрела особую остроту . Развитие коммуникационных технологий поз воляет строить сети распре деленной архите ктуры , объединяющие большое количество сегментов , расположенных на значительном удалении друг от друга . Все это вызывает увеличение числа узлов сетей , разбросанных по всему миру , и количества различных линий связи между ними , что , в свою оч е р едь , повышает риск несанкционированного подключен ия к сети для доступа к важной информ ации . Особенно неприятной такая перспектива м ожет оказаться для банковских или государстве нных структур , обладающих секретной информацией коммерческого или любого друго г о характера . В этом случае необходимы специал ьные средства идентификации пользователей в с ети , обеспечивающие доступ к информации лишь в случае полной уверенности в наличии у пользователя прав доступа к ней. Существует ряд разработок , позволяющих с высокой степенью надежности идентифицирова ть пользователя при входе в систему . Среди них , например , есть технологии , идентифицирующ ие пользователя по сетчатке глаза или отп ечаткам пальцев . Кроме того , ряд систем ис пользуют технологии , основанные на применении сп е циального идентификационного кода , постоянно передаваемого по сети . Так , при использовании устройства SecureID (фирмы Security Dinamics) обеспечивается дополнительная информация о пользователе в виде шестизначного кода . В данном случае работа в сети невоз м ожна без наличия специальной карты SecureID (похожей на кредитную ), которая обеспечивает синхронизацию изм еняющегося кода пользователя с хранящимися на UNIX-хосте , При этом доступ в сеть и работа в ней может осуществляться лишь пр и знании текущего значени я кода , который отображается на дисплее устройства SecureID. Однако основным недостатком этой и ей подобных систем является необходимость в спец иальном оборудовании , что вызывает неудобства в работе и дополнительные затраты. В статье рассматриваются некотор ые возможности обеспечения безопасности в система х — шифрование информации при передаче п о каналам связи и использование надежных ( достоверных , доверительных ) (Trusted) систем — на при мере СУБД ORACLE, а так же система защиты о т несанкционированого доступ а к сет и Kerberos. Безопасность в среде баз данных Очевидные достоинства баз данных в со временной среде обработки данных служат гаран тией их дальнейшего развития и использования . Контроль доступа в этой области важен ввиду колоссал ьной концентрации информации. В настоящий момент “хребтом” базовых систем обработки информации во многих больших организациях является локальная сеть , котора я постепенно занимает такое же место и в фирмах меньшего размера . Растущая популяр ность локальных с етей требует соответству ющей защиты информации , но исторически они были спроектированы как раз не для раз граничения , а для облегчения доступа и кол лективного использования ресурсов . В среде ло кальных сетей в пределах здания или район а (городка ) сотрудник, имеющий доступ к физической линии , может просматривать дан ные , не предназначенные для него . В целях защиты информации в различных комбинациях используются контроль доступа , авторизация и шифрование информации , дополненные резервированием. Опре деление потребности в защи те информации Обеспечение безопасности информации — до рогое дело , и не столько из-за затрат н а закупку или установку средств , сколько и з-за того , что трудно квалифицированно определ ить границы разумной безопасности и соо тветствующего поддержания системы в работоспособ ном состоянии. Если локальная сеть разрабатывались в целях совместного использования лицензионных п рограммных средств , дорогих цветных принтеров или больших файлов общедоступной информации , то нет никакой потребности даже в м инимальных системах шифрования /дешифрования инфо рмации. Средства защиты информации нельзя проекти ровать , покупать или устанавливать до тех пор , пока не произведен соответствующий анали з. Анализ риска должен дать объективную оценку многи х факторов (подверженность по явлению нарушения работы , вероятность появления нарушения работы , ущерб от коммерческих пот ерь , снижение коэффициента готовности системы , общественные отношения , юридические проблемы ) и предоставить информацию для определения п одходящих типов и уровней безопасности . Коммерческие организации все в большей с тепени переносят критическую корпоративную инфор мацию с больших вычислительных систем в с реду открытых систем и встречаются с новы ми и сложными проблемами при реализации и экс п луатации системы безопасности . Сегодня все больше организаций разворачивают мощные распределенные базы данных и прил ожения клиент /сервер для управления коммерчес кими данными . При увеличении распределения во зрастает также и риск неавторизованного досту па к данным и их искажения. Шифрование данных традиционно использовалось правительственными и оборонными департаментами , но в связи с изменением потребностей и некоторые наиболее солидные компании нач инают использовать возможности , предоставляемые ш ифрованием д ля обеспечения конфиденциальност и информации. Финансовые службы компаний (прежде всего в США ) представляют важную и большую пользовательскую базу и часто специфические т ребования предъявляются к алгоритму , используемом у в процессе шифрования . Опубликованны е алгоритмы , например DES (См . ниже ), являются обяз ательными . В то же время , рынок коммерческ их систем не всегда требует такой строгой защиты , как правительственные или оборонные ведомства , поэтому возможно применение проду ктов и другого типа , например PG P (Pretty Good Privacy). Шифрование Шифрование данных может осуществляться в режимах On-Line (в темпе поступления информации ) и Off-Line (автономном ). Остановимся подробнее на п ервом типе , представляющем больший интерес . На иболее р аспространены два алгоритма. Стандарт шифрования данных DES (Data Encryption Standard) был ра зработан фирмой IBM в начале 70-х годов и в настоящее время является правительственным стандартом для шифрования цифровой информации . Он рекомендован Ассоциацией А мериканских Банкиров . Сложный алгоритм DES использует ключ длиной 56 бит и 8 битов проверки на четн ость и требует от злоумышленника перебора 72 квадриллионов возможных ключевых комбинаций , о беспечивая высокую степень защиты при небольш их расходах . При час т ой смене ключей алгоритм удовлетворительно решает проблем у превращения конфиденциальной информации в н едоступную. Алгоритм RSA был изобретен Ривестом , Шамиром и Альде-маном в 1976 году и представляет собой значительный шаг в криптографии . Этот алгоритм так же был принят в качест ве стандарта Национальным Бюро Стандартов. DES, технически , является СИММЕТРИЧНЫМ алгоритм ом , а RSA — АСИММЕТРИЧНЫМ , то есть он исп ользует разные ключи при шифровании и деш ифровании . Пользователи имеют два ключа и могут широко распрос транять свой открытый ключ . Открытый ключ используется для шифр ования сообщения пользователем , но только опр еделенный получатель может дешифровать его св оим секретным ключом ; открытый ключ бесполезе н для дешифрования . Это делает ненужными с екретные соглаш е ния о передаче кл ючей между корреспондентами . DES определяет длину данных и ключа в битах , а RSA может бы ть реализован при любой длине ключа . Чем длиннее ключ , тем выше уровень безопаснос ти (но становится длительнее и процесс шиф рования и дешифрования ). Е с ли ключ и DES можно сгенерировать за микросекунды , то примерное время генерации ключа RSA — десятк и секунд . Поэтому открытые ключи RSA предпочитаю т разработчики программных средств , а секретн ые ключи DES — разработчики аппаратуры. Некоторые реш ения Примером архитектуры клиент /сервер , котор ую хорошо дополняют средства шифрования , могу т служить Oracle Server, сетевые продукты (SQMNet) и программно е обеспечение клиента. Сетевая служба безопасности (SNS — Secure Network Services) пр едла гает стандартный , оптимизированный алгори тм шифрования DES с ключом длиной 56 бит для организаций , от которых требуется использовать стандарт DES. Для заказчиков вне пределов СШ А или Канады SNS предлагает DES40, в котором комб инируется использование алгор и тма шиф рования DES с общепринятым ключом длиной 40 бит (экспорт технологий шифрования в США законо дательно ограничен ). Наряду с DES возможно также использование алгоритма шифрования RSA RC4. Секретный , генерируемый случайным образом ключ для каждой сессии SQL* Net сохраняет в есь сетевой трафик — включая пароли , знач ения данных , SQL-утверждения и сохраняемые вызов ы и результаты. Для обнаружения модификации или подмены данных во время передачи SNS генерирует кри птографически защищенное значение , вычисляемое п о содержимому сообщения , и включает ег о в каждый пакет , передаваемый по сети . При получении пакета в пункте назначения SNS немедленно производит проверку целостности ка ждого пакета. Устойчивость к искажению данных обеспечив ается следующим образом : 1) крипт ографически защищенная контрольн ая сумма в каждом пакете SQL* Net обеспечивает з ащиту от модификации данных и замены опер ации ; 2) при обнаружении нарушений операции нез амедлительно автоматически завершаются ; 3) информация о всех нарушениях регистрир уется в журнале. Наряду с этим обеспечивается многопротоко льная перекодировка данных , т.е . полностью подд ерживается Oracle Multiprotocol Interchange — при работе с зашифрова нной сессией можно начинать работу с одни м сетевым протоколом , а заканчивать с друг им , при этом не требуется дешифрование или перешифрование информации . SNS полностью подде рживается сквозными шлюзами , Oracle Transparent Gateways, и процедурным и шлюзами , Oracle Procedural Gateways, которые дают возможность ор ганизовывать полностью зашифрованные сесс ии клиент /сервер к отличным от Oracle источник ам данных , включая Adabas, CA-Datacom, DB2, DRDA, FOCUS, IDMS, IMS, ISAM, MUMPS, QSAM, Rdb, RMS, SAP, SQL/DS, SQL/400, SUPRA, Teradata, TOTAL, VSAM и другие. SNS работает со всеми основными протокола ми , под держиваемыми SQL* Net, включая AppleTalk, Banyan, DECnet, LU6.2, MaxSix, NetBIOS, SPX/IPX, TCP/IP, X.25 и другие. Обеспечивается независимость от топологии сети — SNS работает во всех основных сет евых средах , поддерживаемых SQL-Net. SNS представляет собой дополнительный пр одукт к стандартному пакету SQL* Net, то есть тр ебуется предварительно приобрести лицензию на SQL* Net. Продукт надо покупать и для клиента , и для сервера. Вместе тем СУБД Oracle, начиная с версии 7.1, пароль передается по сети в зашифрова нном виде. Это означает , что при организации связ и клиент /сервер используется новый протокол установления связи , в котором применяется сеансовый ключ , пригодный только для единст венной попытки соединения с базой данных и используемый в качестве ключа для ш ифрования пароля , прежде чем он будет передан клиентам . Oracle-сервер находит зашифрован ный пароль для этого пользователя и испол ьзует его в качестве ключа , которым он зашифровывает сеансовый ключ . Затем сервер пересылает этот зашифрованный сеансовый ключ клиенту . Клиент шифрует (применяя тот же самый односторонний алгоритм , который используется сервером ) пароль , введенный поль зователем , и с его помощью дешифрует зашиф рованный сеансовый ключ . Обнаружив этот сеанс овый ключ , он использует его — это ст ановитс я совместным секретом клиента и сервера — для шифрования пароля пол ьзователя . Этот зашифрованный пароль затем пе редается через сеть серверу . Сервер дешифрует пароль и затем зашифровывает его , использ уя односторонний алгоритм сервера ; результат этих вычисле н ий сверяется со знач ением , хранимым в словаре данных . Если они совпадают , клиенту предоставляется доступ . Та кой подход реализуется как в соединениях типа клиент /сервер , так и сервер /сервер , где сеансы устанавливаются через так назыв аемые полномочные звень я баз данных (т.е . звенья баз данных без вложенных имен пользователей и паролей ). Понятия идентификации и аутентификаци и в достоверных системах Известны большие выгоды , которые дает переход к открытым системам . Но среди них не знач ится безопасность информации . Это и понятно — центр обработки данных передает некоторые из своих функций по контролю за системой отделам и пользователям и тем самым рассеивает объект безопаснос ти. Сохранить требуемый уровень безопасности системы возможно п ри использовании операц ионных систем класса В 1 (Trusted), которые позволяют администратору системы присвоить каждому пол ьзователю уровень доступности объектов системы (Secret, Confidential, Unclassified). Обработка секретной и конфиденциальной ин формации т ребует от системы использовать механизм гарантии соответствующей идентификации и аутентификации пользователей . Все возможны е подходы к идентификации и аутентификации ' должны быть идентифицированы , рассмотрены и сравнены с Критерием Оценки Достоверности Вы ч ислительных Систем (TCSEC), или с “Ор анжевой Книгой” (в Европе — Критерием Оце нки Безопасности Информационных Технологий , или “Белой Книгой” ). TCSEC делится на четыре класса : D, С , В и А . Эти классы упорядочены , причем самы й высокий класс (А ) зарезервирова н за системами , имеющими наивысший уровень защиты информации . Внутри классов В и С имею тся подклассы , которые тоже упорядочены в соответствии с обеспечиваемым уровнем защиты . Коротко говоря , принадлежность к классу D озна чает , что система не имеет средств защиты информации (неклассифицированная ), к классу С — что она имеет некоторые средства избирательной защиты (классифицированная ), к классу В — что к упомянутым р анее средствам добавляются гарантии безопасности и они описываются как “полномочные” (секр етн а я информация ), ну а если си стема отнесена к классу А , значит , средств а защиты ранее проверены (совершенно секретна я информация ). Многие популярные операционные системы (например , различные варианты PС UNIX, Sun Solaris 2.3 и т.п .) соответствуют классу С . В 1 — первый в классификации уровень , в котором имеет место контроль доступа и переноса данных , основанный на уровнях конфиденциальности . Для непривилегированных поль зователей используются данные идентификации и аутентификации для определения уровня автори з ации текущего пользователя , которые Достоверная Компьютерная База (ТСВ — Trusted Computer Base) сравнивает со своей базой данных пользо вателей , содержащей ранги авторизации для каж дого пользователя . Если информация , указанная при вхождении в связь , коррек т на и ее уровень признан соответствующим зап росу , ТСВ допускает пользователя в систему . При попытке доступа к файлам ТСВ высту пает в роли арбитра , при этом ТСВ осно вывается на уровне пользователя и метке ф айла или объекта , к которым пользователь п ытается п о лучить доступ . Поскольку уровень конфиденциальности представляется уровнем прозрачности и категорией доступа , а разр ешение на доступ к объекту определяется к онфиденциальностью и объекта , и субъекта (внеш ний п ( отношению к ТСВ ), авторизация субъек та стано в ится компонентом требований к авторизации. Оранжевая Книга фокусирует внимание на законченны вычислительных системах и определяе т шесть ключевых требований безопасности инфо рмации : 1) система должна иметь четкий сертификат безопасности 2) каждый объект , ас социированный с этим сертификате ! должен иметь метку контро ля доступа ; 3) индивидуальные пользователи должны быть идентифицированы ; 4) система должна поддерживать совокупность сведений накапливающихся со временем и и спользуемых для упрощен проверки средств защиты ; 5) система должна быть открыта для не зависимой оценки безопасности информации ; 6) система должна быть постоянно защищена от изменений конфигурации или каких-либо других изменений. Со времени выпуска Оранжевой книги бы ло опубликовано множество друг их документ ов с различными цветами обложек . Эта “раду жная серия” охватывает вопросы Интерпретации Достоверных Сетей (Trusted Network Interpretation), Интерпретации Достоверных Баз Данных (Trusted DataBase Interpretation), руководства по паролям , руководст в о по избирательному конт ролю доступа и Перечень Оцененных Средств. Некоторые реализации Корпорация Oracle разработала реляционную СУБД с обеспечением многоуровневой защиты информаци и (Multi-Level Security — MLS) — Trusted ORACLE7, обладающую , в том числе , и всеми стандартными возможностями ORACLE7. В прошлом компании , которые желали защ итить секретную или конфиденциальную информацию , вынуждены были использовать для этих цел ей специальное или выделенное оборудование . С появлением та ких продуктов , как Trusted ORACLE7, эта необходимость отпала . Trusted ORACLE7 позволяет размещать важную для конкурентов информацию в базе данных , в которой хранится общая информац ия , без всякого риска , что какой-то пользов атель случайно или преднамеренно полу чит доступ к секретной или конфиденциальной информации. Trusted ORACLE7 функционирует с использованием двух наборов правил : Избирательное Управление Доступ ом (DAC — Discretionary Access Control) и Полномочное Управление Досту пом (MAC — Mandatory Access Control). Использование DAC ограничивается такими объектами баз данных , как таблицы , виды , последовательности и хранимые процедур ы , основанные на идентификации пользователей , и групповые ассоциации . Создатель объектов ба з данных — например , таблиц — може т предоставлять доступ другому поль зователю. MAC представляет собой шаг вперед по с равнению с DAC и помечает содержание объектов баз данных . MAC ограничивает доступ к объекту путем сравнения так называемой метки объ екта с уровнем авторизации пользователя . П омимо меток MAC Trusted ORACLE7 помечает такие элементы объектов , как строки и таблицы . В резу льтате этого свойства даже при условии , чт о DAC пытается дать пользователю доступ к по меченному объекту , ему будет разрешен доступ , только если его уровень автор и зации будет не ниже , чем уровень а вторизации информации , к которой пытается пол учить доступ пользователь. Обратите внимание , что Trusted ORACLE7 должна функцио нировать над ОС с многоуровневой защитой информации , чтобы обеспечить уровни защиты ин формации , з аложенные в ней при проекти ровании . Обмен между системами с многоуровнев ой защитой (меточной ), а также между систем ой с многоуровневой защитой и обычной сис темой , не использующей метки , возможен только посредством меточного сетевого протокола . Та кие прото к олы передают в дополнен ие к другим атрибутам защиты информации , п одобно идентификаторам пользователей или групп , метки пакетов , которые обычно порождаются и з меток передающего процесса . Большинство общ их меточных протоколов являются вариантами пр отокола M a xSix, представляющего собой совок упность сетевых протоколов защиты информации и программных интерфейсов , теоретически спроектир ованного для поддержки сетей OSI и TCP/IP, хотя в настоящее время имеются только реализации MaxSix. Протоколы MaxSix соответству ю т RIPCO, CIPCO и DNSIX. Большинство поставщиков рабочих станций MLS с Режимом Разделения на Секции (CMW — Compartamented Mode Workstation) реа лизовали протоколы MaxSix в своих защищенных ОС . MaxSix обеспечивает не только службы расставления меток и трансл я ции , но и до пускает единственную заранее определенную метку MLS. Таким образом , помеченный сервер в дей ствительности действует как сторож ; аналогично , БД Trusted ORACLE7 на этом сервере работает как ст орож сервера СУБД. Как и обычные протоколы , SQL* Net по ддер живает эти меточные протоколы посредством про токольных адаптеров ; например , имеются реализации адаптеров протоколов SQL* Net для TNET фирмы Sun, MaxSix фирмы DEC и MaxSix фирмы HP. На станциях , где многоуровнев ая среда соединяется с неметочной средой, на одной стороне соединения (мног оуровневой ) работает адаптер SQL* Net для варианта MaxSix, а на другой — адаптер SQL* Net для протокола TCP/IP (неметочная среда ). Все продукты корпорации Oracle Developer 2000, Designer 2000 и др . могут использоваться с Tr usted ORACLE7. Перспективы развития С появлением Oracle RDBMS версии 7.2 разработчики при ложений смогут поставлять код PL/SQL в свернутом (Wrapped) формате . Разработчик , который планирует распр остранять приложения на PL/SQL, больш е не д олжен отправлять исходный код PL/SQL. Скрытие исход ного кода облегчает защиту интеллектуальной с обственности и уменьшает возможные злоупотреблен ия или искажения приложений. Защищенные СУБД других поставщиков Informix поставл яет OnLine/Secure 5.0, который , подобно другим конкурирующим продуктам в данной облас ти , представляет собой реляционную СУБД , обесп ечивающую многоуровневую защиту информации в БД и работающую с использованием двух наб оров правил DAC и MAC. Аналогичные меха низмы поддерживает Sybase в продукте Secure SQL Server Version 10.0. Система Kerberos Система Kerberos (по-русски — Цербер ), разработан ная участниками проекта Athena, обеспечивает защиту сети от несанкционированного доступа , бази руясь исключительно на программных решени ях , и предполагает многократную шифрование пе редаваемой по сети управляющей информации . Kerberos обеспечивает идентификацию пользователей сети и серверов , не основываясь на сетевых адрес ах и особенностях операционн ы х си стем рабочих станций пользователей , не требуя физической защиты информации на всех маш инах сети и исходя из предположения , что пакеты в сети могут быть легко прочи таны и при желании изменены. Клиент / Kerberos/ Cepв ep Kerberos имеет структуру типа клиент /сер вер и состоит из клиентских частей , устано вленных на все машины сети (рабочие станци и пользователей и серверы ), и Kerberos-сервера (ил и серверов ), располагающегося на каком-либо (не обязательно выделенном ) компьютере . Kerber o s-сервер , в свою очередь , делится на две равноправные части : сервер идентификации (authentication server) и сервер выдач и разрешений (ticket granting server). Следует отметить , что суще ствует в третий сервер Kerberos, который , однако , не участвует в иденти фикации пользователе й , а предназначен для административных целей . Область действия Kerberos (realm) распространяется на то т участок сети , все пользователи которого зарегистрированы под своими именами и паролям и в базе Kerberos-сервера и где все серверы об л адают общим кодовым ключом с идентификационной частью Kerberos. Эта область н е обязательно должна быть участком локальной сети , поскольку Kerberos не накладывает ограничения на тип используемых коммуникаций (о спосо бе доступа из области действия одного Ke r beros-сервера в область действия др угого будет сказано чуть ниже ). Упрощенно модель работы Kerberos можно описать следующим образом . Пользователь (Kerberos-клиент ), же лая получить доступ к ресурсу сети , направ ляет запрос идентификационному серверу Kerberos . Последний идентифицирует пользователя с помощью его имени и пароля и выдает разрешен ие на доступ к серверу выдачи разрешений , который , в свою очередь , дает “добро” на использование необходимых ресурсов сети . О днако данная модель не отвечает на вопрос о н адежности защиты информации , поскольку , с одной стороны , пользователь не может посылать идентификационному серверу свой пароль по сети , а с другой — раз решение на доступ к обслуживанию в сети не может быть послано пользователю в в иде обычного сообщения . В обоих сл учаях информация может быть перехвачена и использована для несанкционированного доступа в сеть . Для того , чтобы избежать подобных неприятностей Kerberos, применяет сложную систему м ногократного шифрования при передаче любой уп равляющей информации в сети. Доступ пользователей к сетевым серверам , файлам , приложениям , принтерам и т.д . осуще ствляется по следующей схеме. Клиент (под которым в дальнейшем будет пониматься клиентская часть Kerberos, установленная на рабочей станции пользователя ) направляет запрос идентификационному серверу на выда чу “разрешения на получение разрешения” (ticket-granting ticket), которое даст возможность обратиться к серверу выдачи разрешений . Идентификационный серв ер адресуется к базе данных , хранящей инфо рмацию о всех польз о вателях , и на основании содержащегося в запросе имени пользователя определяет его пароль . Затем клиенту отсылается “разрешение на получение разрешения” и специальный код сеанса (session key), к оторые шифруются с помощью пароля пользовател я как ключа . При п олучении этой информации пользователь на его рабочей с танции должен ввести свой пароль , и если он совпадает с хранящимися в базе Kerberos- сервера , “разрешение на получение разрешения” и код сеанса будут успешно расшифрованы . Таким образом решается проблем а с защитой пароля — в данном случае он не передается по сети. После того как клиент зарегистрировался с помощью идентификационного сервера Kerberos, он отправляет запрос серверу выдачи разрешений на получение доступа к требуемым ресурсам сети . Этот запрос (или “разрешения на получение разрешения” ) содержит имя поль зователя , его сетевой адрес , отметку времени , срок жизни этого разрешения и код сеан са . “Разрешение на получение разрешения” заши фровывается два раза : сначала с помощью сп ециального кода , который известен толь ко идентификационному серверу и серверу выдач и разрешений , а затем , как уже было ска зано , с помощью пароля пользователя . Это п редотвращает не только возможность использования этого разрешения при его перехвате , но и делает его недоступным сам о м у пользователю . Для того чтобы сервер выда чи разрешений дал клиенту доступ к требуе мым ресурсам , недостаточно только “разрешения на получение разрешения” . Вместе с ним кл иент посылает так называемый аутентикатор (authenticator), зашифровываемый с помощью кода се анса и содержащий имя пользователя , его се тевой адрес и еще одну отметку времени. Сервер выдачи разрешений расшифровывает п олученное от клиента “разрешение на получение разрешения” , проверяет , не истек ли срок его “годности” , а затем сравнивает имя пользователя и его сетевой адрес , нахо дящиеся в разрешении , с данными , которые у казаны в заголовке пакета пришедшего сообщени я . Однако на этом проверки не заканчиваютс я . Сервер выдачи разрешений расшифровывает ау тентикатор с помощью кода сеанса и еще раз с равнивает имя пользователя и его сетевой адрес с предыдущими двумя значениями , и только в случае положительног о результата может быть уверен наконец , чт о клиент именно тот , за кого себя выда ет . Поскольку аутентикатор используется для и дентификации клиента всего один раз и только в течение определенного периода времени , становится практически невозможным одн овременный перехват “разрешения на получение разрешения” и аутентикатора для последующих п опыток несанкционированного доступа к ресурсам сети . Каждый ра з , при необходимост и доступа к серверу сети , клиент посылает “разрешение на получение разрешения” многора зового использования и новый аутентикатор. После успешной идентификации клиента в качестве источника запроса сервер выдачи р азрешений отсылает пользоват елю разрешение на доступ к ресурсам сети (которое може т использоваться многократно в течение некото рого периода времени ) и новый код сеанса . Это разрешение зашифровано с помощью код а , известного только серверу выдачи разрешени й и серверу , к которому требу е т доступа клиент , и содержит внутри себя копию нового кода сеанса . Все сообщение (разрешение и новый код сеанса ) зашифрова но с помощью старого кода сеанса , поэтому расшифровать его может только клиент . Пос ле расшифровки клиент посылает целевому серве ру , р е сурсы которого нужны пользов ателю , разрешение на доступ и аутентикатор , зашифрованные с помощью нового кода сеанса. Для обеспечения еще более высокого ур овня защиты , клиент , в свою очередь , может потребовать идентификации целевого сервера , чтобы обезопасит ься от возможного перехва та информации , дающей право на доступ к ресурсам сети . В этом случае он требует от сервера высылки значения отметки врем ени , увеличенного на единицу и зашифрованного с помощью кода сеанса . Сервер извлекает копию кода сеанса , храня щ уюся внутри разрешения на доступ к серверу , использует его для расшифровки аутентикатора , прибавляет к отметке времени единицу , зашифро вывает полученную информацию с помощью кода сеанса и отсылает ее клиенту. Расшифровка этого сообщения позволяет кли енту и дентифицировать сервер . Использование в качестве кода отметки времени обеспечива ет уверенность в том , что пришедший клиент у ответ от сервера не является повтором ответа на какой-либо предыдущий запрос. Теперь клиент и сервер готовы к п ередаче необходимой и нформации с должной степенью защиты . Клиент обращается с запр осами к целевому серверу , используя полученно е разрешение . Последующие сообщения зашифровывают ся с помощью кода сеанса. Более сложной является ситуация , когда клиенту необходимо дать серверу прав о пользоваться какими-либо ресурсами от его имени . В качестве примера можно привести ситуацию , когда клиент посылает запрос серв еру печати , которому затем необходимо получит ь доступ к файлам пользователя , расположенным на файл-сервере . Кроме того , при вхо д е в удаленную систему пользовате лю необходимо , чтобы все идентификационные пр оцедуры выполнялись так же , как и с ло кальной машины . Эта проблема решается установ кой специальных флагов в “разрешении на п олучение разрешения” (дающих одноразовое разрешен ие на доступ к серверу от имен и клиента для первого примера и обеспечив ающих постоянную работу в этом режиме для второго ). Поскольку , как было сказано выше , разрешения строго привязаны к сетевому а дресу обладающей ими станции , то при налич ии подобных флагов сер в ер выдачи разрешений должен указать в разрешении с етевой адрес того сервера , которому передаютс я полномочия на действия от имени клиента. Следует отметить также , что для всех описанных выше процедур идентификации необхо димо обеспечить доступ к базе данных Kerberos только для чтения . Но иногда треб уется изменять базу , например , в случае из менения ключей или добавления новых пользоват елей . Тогда используется третий сервер Kerberos — административный (Kerberos Administration Server). He вдаваясь в подробности его работы , следует отметить , что его реализации могут сильно отличаться (т ак , возможно ведение нескольких копий базы одновременно ). Связь между Kerberos-областями Как уже было сказано выше , при исп ользовании Kerberos-серверов сет ь делится на области действия Kerberos. Схема доступа клиента , находящегося в области действия одного Kerberos-сер вера , к ресурсам сети , расположенным в обл асти действия другого Kerberos, осуществляется следующим образом. Целевой сервер Оба Kerberos-сервера должны быть обоюдно зар егистрированы , то есть знать общие секретные ключи и , следовательно , иметь доступ к базам пользователей друг друга . Обмен этими ключами между Kerberos-серверами (для работы в каждом направлении используетс я свой ключ ) позво-ляет зарегистрировать сервер выдачи разрешений каждой области как клиента в другой области . После этого клиент , требу ющий доступа к ресурсам , находящимся в обл асти действия другого Kerberos-сервера , может получи ть разрешение от сервера в ыдачи разрешений своего Kerberos по описанному выше алгор итму . Это разрешение , в свою очередь , дает право доступа к серверу выдачи разрешени й другого Kerberos-сервера и содержит в себе отметку о том , в какой Kerberos-области зареги стрирован пользователь . У даленный сервер выдачи разрешений использует один из общ их секретных ключей для расшифровки этого разрешения (который , естественно , отличается от ключа , используемого в пределах этой обла сти ) и при успешной расшифровке может быть уверен , что разрешение вы д ано клиенту соответствующей Kerberos-области . Полученное разрешение на доступ к ресурсам сети пред ъявляется целевому серверу для получения соот ветствующих услуг. Следует , однако , учитывать , что большое число Kerberos-серверов в сети ведет к увелич ению коли чества передаваемой идентификационн ой информации при связи между разными Kerberos-о бластями . При этом увеличивается нагрузка на сеть и на сами Kerberos-серверы . Поэтому бол ее эффективным следует считать наличие в большой сети всего нескольких Kerberos-сер в еров с большими областями действия , не жели использование множества Kerberos-серверов . Тая , Kerberos-система , установленная компанией Digital Equipment для больш ой банковской сети , объединяющей отделения в Нью-Йорке , Париже и Риме , имеет всего один Kerbero s -сервер . При этом , несмотря на наличие в сети глобальных коммуникаций , работа Kerberos-системы практически не отразилась на производительности сети. Kerberos-5 К настоящему времени Kerberos выдержал уже ч етыре модификации , из кото рых четвертая получила наибольшее распространение . Недавно гр уппа , продолжающая работу над Kerberos, опубликовала спецификацию пятой версии системы , основные о собенности которой отражены в стандарте RFC 1510. Эт а модификация Kerberos имеет ряд новых свойс т в , из которых можно выделить следующи е. Уже рассмотренный ранее механизм передачи полномочий серверу на действия от имени клиента , значительно облегчающий идентификацию в сети в ряде сложных случаев , является нововведением пятой версии. Пятая версия обеспе чивает более у прощенную идентификацию пользователей в удаленны х Kerberos-областях , с сокращенным числом передач секретных ключей между этими областями . Дан ное свойство , в свою очередь , базируется н а механизме передачи полномочий. Если в предыдущих версиях Kerberos для шифрования использовался исключительно алгоритм DES (Data Encryption Standard — Стандарт Шифрования Данных ), надежнос ть которого вызывала некоторые сомнения , то в данной версии возможно использование раз личных алгоритмов шифрования , отличных от DES. Заключение Многие производители сетевого и телекомму никационного оборудования обеспечивают поддержку работы с Kerberos в своих устройствах . Следует , однако , отметить , что использовани е Kerberos не является решением всех п роблем , связанных с попытками несанкционированного доступа в сеть (например , он бессилен , если кто-либо узнал пароль пользователя ), поэтому его наличие не исключает других стандартны х средств поддержания соответствующего уровня секретности в сети. Ни одна компьютерная сист ема защиты информации не является абсолютно безопасной . Однако адекватные меры защиты значительно затрудняют доступ к системе и снижают эффективность усилий злоумышленника (отношение средних затрат на взлом защиты системы и ожидаемых резу л ьтатов ) так , что проникновение в систему становится нецелесообразным . Ключевым элементом в системе безопасности является администратор системы . Какие бы средства вы ни приобретали , каче ство защиты будет зависеть от способностей и усилий этого человека.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Как же быстро летит жизнь! Еще юношеская дурь не успела выветриться, а уже старческий маразм наступил.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru