Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву
Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Забезпечення безпеки даних у разі використання Sun RPCСодержание книги
Поиск на нашем сайте Для забезпечення безпеки даних у разі використання RPC застосовують аутенти-фікацію RPC-клієнтів перед доступом до сервера. Є кілька рівнів такої аутенти-фікації. Рівень AUTH NONE (використовуваний за замовчуванням) означає, що аутентифікації не виконують зовсім. Відповідно до нього будь-який клієнт у мережі, що може відсилати пакети RPC-серверу, має змогу викликати будь-яку реалізовану ним процедуру. Цей рівень не забезпечує ніякого захисту і не рекомендований до використання. Рівень AUTHUNIX означає, що кожний RPC-запит супроводжується ідентифікатором користувача (uid) і набором ідентифікаторів груп (gid). Мається на увазі, що ці ідентифікатори відповідають користувачу, який запустив клієнтське застосування, і що сервер довіряє цьому користувачу. Для використання такої аутентифікації на клієнті після виклику clnt_create() необхідно виконати код
// CLIENT *cl = clntcreate(...) authdestroy(cl ->cl_auth); cl->cl_auth = authsyscreatedefaultO; // задання AUTHJJNIX
Цей рівень теж не зовсім відповідає сучасним уявленням про мережну безпеку, оскільки зловмисник може створювати і відсилати RPC-пакети із довільними значеннями uid і gid, і їхнє авторство не може бути перевірене сервером. Наприклад, коли відомо, який користувач потрібен для виконання необхідних процедур, і в мережі є комп'ютер, на якому зловмисник має права root, він може створити користувача із необхідним uid і виконувати RPC-запити клієнтським процесом, запущеним під цим користувачем. Такі запити будуть успішно виконані, хоча пароль потрібного користувача RPC-сервера зловмисникові невідомий. Рівень AUTH_DES використовує гібридну криптосистему для організації захищеного каналу зв'язку для RPC-виклику. Реалізація такого рівня аутентифікації відома як Secure RPC. ] Використання Microsoft RPC Розробка застосувань із використанням Microsoft RPC ґрунтується на тих самих принципах, що і Sun RPC, але має деякі особливості [50]. Насамперед ця технологія може використовувати різні базові засоби зв'язку (зокрема TCP/IP та по-іменовані канали). Крім того, можлива розробка клієнтського застосування без явного задання з'єднання із сервером.
РозробкаIDL-файла Розробку застосування починають з опису його інтерфейсів на IDL. Кожному інтерфейсу ставлять у відповідність універсальний унікальний ідентифікатор (UUID) — 128-бітне число, генероване за допомогою спеціального алгоритму, що забезпечує високий ступінь унікальності. За цим ідентифікатором RPC-клієнти ідентифікують інтерфейси, експортовані серверами. Для створення UUID використовують утиліту uuidgen. Кожний інтерфейс супроводжують атрибути, перелічені у квадратних дужках перед ключовим словом interface: ♦uuid - UUID для цього інтерфейсу; ♦ version — версія інтерфейсу; ♦ auto handle - означає, що клієнтське застосування не повинне явно задавати код для встановлення з'єднання із сервером - це буде зроблено із коду заглушки (є й інші способи організації зв'язку, наприклад, за наявності атрибута implicithandle зв'язок має бути встановлений явно). Кожен параметр інтерфейсу теж супроводжують атрибути: ♦ in, out - режим параметра (in - вхідний, out - вихідний); ♦ string - параметр треба розглядати як рядок символів. Наведемо приклад IDL-файла, що задає один інтерфейс з однією процедурою. Далі вважатимемо, що він називається myrpc.idl.
[uuid(c0579cff-e76a-417d-878b-1195d366385). version(l.O). auto_handle] interface ihello { /* визначення інтерфейсу ihello */ void say_msg([in,string] unsigned char* msg): }
IDL-файл обробляють IDL-компілятором (midi):
midi.exe /app_config myrpc.idl
Параметр /appconfig задають y разі, коли в IDL-файлі присутні атрибути, що стосуються всього застосування (у нашому випадку це auto handle). Якщо його не вказати, такі атрибути задаються в окремому файлі з розширенням.acf. Внаслідок обробки IDL-файла створяться файли заглушок для клієнта і сервера (myrpc_c.c і myrpc_s.c), які треба скомпонувати у відповідні виконувані файли, а також заголовний файл myrpc.h, що має бути підключений у вихідні файли клієнта і сервера.
|
||
|
Последнее изменение этой страницы: 2017-02-06; просмотров: 244; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 216.73.217.128 (0.009 с.) |