Wiki ТНТУ - Внесок користувача [uk]

Формули MS Word MathType

2011-10-24T12:57:21Z

Nixiedelacruz:

'''Інструкції з написання формул вручну ви можете знайти [http://uk.wikipedia.org/wiki/Довідка:Математичні_формули_та_спецсимволи тут].'''

Для генерації формул в середовищі MS Word (MathType), необхідно:

== Що треба ==

# MS Word
# MathType вер. 6.Х (www.dessci.com/en/products/mathtype/) - він замінить і значно розширить функціонал стандартного редактора формул, вам сподобається.
Вона платна, рекомендую останню версію 6.7 (див.файлообмінник або шукайте на torrents.ru).

== Як вставляти згенеровану формулу з MathType в WiKi ==
Середовище MathType загалом нагадує інтегрований в MS Word за замовчуванням пакет Microsoft Equation 3.0, але в ньому більше можливостей, зокрема щодо вставлення формул практично у будь-які програми, форми й ресурси (розглядається версія 6.7), в т.ч. й у Вікі. Загальний вигляд програми такий: 
<div style="text-align: center;">[[Файл:MathType-Skrin1.png]]</div>
Вставити формулу в ресурс досить просто. Для цього після введення формули в середовищі MathType потрібно в налаштуваннях вказати тип даних, що поміщатимуться у буфер обміну Windows, або власне ресурс, куди надалі пройде вставлення скопійованої в буфер обміну формули. Отже, в російській версії програми (прохання: доповніть мене хтось англійською) виконуємо наступну команду: ''Установки''->''Вырезание_и_копирование...'' З'явиться наступне вікно: 
<div style="text-align: center;">[[Файл:MathType-Skrin2.png]]</div>
Далі можна піти такими шляхами:
* встановити перемикач налаштувань у варіант ''MathWL_или_TeX'' і з випадного списку обрати варіант ''LaTeX_2.09_and_later'';
* або ж у позиції перемикача ''Формула_для_приложения_или_веб-сайта'' з випадного списку обрати ''Wikipedia''.
Далі, клацнувши на кнопці ''ОК'', можна "мишковим" (''ЛКМ''->''Копіювати'') чи клавіатурним (''Ctrl+C'') методом скопіювати виділену у середовищі MathType формулу, після чого без трудноців вставити у нашу улюблену Вікіпедію. :-)

== Приклади ==

<math>\sqrt{{{b}^{2}}-4ac}\frac{-b\pm \sqrt{{{b}^{2}}-4ac}}{2a}\frac{n!}{r!\left( n-r \right)!}</math>

<math>\frac{-b\pm \sqrt{{{b}^{2}}-4ac}}{2a}\frac{n!}{r!\left( n-r \right)!}\iint_{\underset{x\to \infty }{\mathop{\lim }}\,}{\sqrt{{{a}^{2}}+{{b}^{2}}}}</math>

<math>\frac{-b\pm \sqrt{{{b}^{2}}-4ac}}{2a}</math>

<math>\sqrt {{b^2} - 4ac} {{ - b \pm \sqrt {{b^2} - 4ac} } \over {2a}}{{n!} \over {r!\left( {n - r} \right)!}}\mathop {\lim }\limits_{x \to \infty } \int\!\!\!\int_{{{ - b \pm \sqrt {{b^2} - 4ac} } \over {2a}}} {\sqrt {{a^2} + {b^2}} } </math>

<math>\sqrt{{{b}^{2}}-4ac}\frac{-b\pm \sqrt{{{b}^{2}}-4ac}}{2a}\frac{n!}{r!\left( n-r \right)!}\underset{x\to \infty }{\mathop{\lim }}\,\iint_{\frac{-b\pm \sqrt{{{b}^{2}}-4ac}}{2a}}{\sqrt{{{a}^{2}}+{{b}^{2}}}}</math>

<math>\sqrt{{{b}^{2}}-4ac}\frac{-b\pm \sqrt{{{b}^{2}}-4ac}}{2a}\frac{n!}{r!\left( n-r \right)!}\int_{\sqrt{{{a}^{2}}+{{b}^{2}}}}^{{}}{\frac{-b\pm \sqrt{{{b}^{2}}-4ac}}{2a}}</math>

<math>
x^3+(sqrt(1/(1+x^(x^3-3))))/(1+x^5-3*4^3+13)
</math>

<math>
\operatorname{erfc}(x) =
\frac{2}{\sqrt{\pi}} \int_x^{\infty} e^{-t^2}\,dt =
\frac{e^{-x^2}}{x\sqrt{\pi}}\sum_{n=0}^\infty (-1)^n \frac{(2n)!}{n!(2x)^{2n}}
</math>

<math>\sum\nolimits_{1}^{1sdfsd}{sdfg}\frac{-b\pm \sqrt{{{b}^{2}}-4asdfsdf\frac{1}{2}\sqrt{sdf\prod\limits_{234}^{sdf}{sdf}}c}}{2a}</math>

<math>\frac{n!}{r!\left( n-r \right)!}\frac{-b\pm \sqrt{{{b}^{2}}-4ac}}{2a}\sqrt{{{b}^{2}}-4ac}\underset{x\to \infty }{\mathop{\lim }}\,\infty \bigcap\limits_{{}}{\Epsilon \sum\nolimits_{\frac{n!}{r!\left( n-r \right)!}}^{{}}{\frac{-b\pm \sqrt{{{b}^{2}}-4ac}}{2a}}}</math>

[http://custom-paper-writing.com/ custom term papers]

URL

2011-10-24T12:57:20Z

Nixiedelacruz:

=='''Історія'''==
URL був винайдений Тімом Бернерсом-Лі в 1990 році в стінах Європейської ради з ядерних досліджень (фр. Conseil Européen pour la Recherche Nucléaire, CERN) у Женеві, Швейцарія. URL став фундаментальною інновацією в Інтернеті. Спочатку URL призначався для позначення місць розташування ресурсів (найчастіше файлів) у Всесвітній павутині. Зараз URL застосовується для позначення адрес майже всіх ресурсів Інтернету. Стандарт URL закріплений у документі RFC 1738, колишня версія була визначена в RFC 1630. Зараз URL позиціонується як частина більш загальної системи ідентифікації ресурсів URI, сам термін URL поступово поступається місцем більш широкому терміну URI. Стандарт URL регулюється організацією IETF і її підрозділами.

=='''Структура URL'''==
Спочатку локатор URL був розроблений як система для максимально спрощенї вказівки на місцезнаходження ресурсів у мережі. Локатор повинен був бути легко розширюваною і використовувати лише обмежений набір ASCII-символів (наприклад, пропуск ніколи не застосовується в URL). У зв'язку з цим, виникла наступна традиційна форма запису URL:

<Схема >://< логін>: <пароль> @ <хост>: <порт> / <URL-путь>? <Параметри> # <якір>

У цьому записі:
 '''схема'''
 схема звернення до ресурсу; в більшості випадків мається на увазі мережевий протокол
 '''логін'''
 ім'я користувача, використовуване для доступу до ресурсу
 '''пароль'''
 пароль указаного користувача
 '''хост'''
 повністю прописане доменне ім'я хоста в системі DNS або IP-адреса хоста у формі чотирьох десяткових чисел, розділених крапками; числа - натуральні в інтервалі від 0 до 255.
 '''порт'''
 порт хоста для підключення
 '''URL-шлях'''
 уточнююча інформація про місце знаходження ресурсу; залежить від протоколу.
 '''параметри'''
 рядок запиту з переданими на сервер (методом GET) параметрами. Роздільник параметрів - знак '''&'''. Приклад:? Параметр_1 = значення_1 & параметр_2 = значення_2 & параметр3 = значення_3
 '''якоря'''
 ідентифікатор «якоря», що посилається на деяку частину (розділ) відкривається документа.
На сьогоднішній день Тім Бернес-Лі визнає, що символ подвійної косої риси у структурі URL є надлишковим.

Адреси хост-комп'ютерів в мережі Інтернет можуть мати подвійну кодування:

* Обов'язкове кодування, зручну для роботи системи телекомунікації в мережі: IP-адресу;
* Необов'язкову кодування, зручну для абонента мережі: доменний DNS-адреса (DNS - Domain Name System).

Цифровий IP-адреса версії V.4 представляє собою 32-розрядне двійкове число. Для зручності він розділяється на чотири блоки по 8 біт, які можна записати в десятковому вигляді. Адреса містить повну інформацію, необхідну для ідентифікації комп'ютера. Зважаючи на величезну кількість підключених до мережі комп'ютерів і різних організацій відчувається обмеженість 32-розрядних IP-адрес, тому ведеться розробка модернізованого протоколу IP-адресації, що має на меті:

* Підвищення пропускної здатності мережі;
* Створення краще масштабується і адаптируемой схеми адресації;
* Забезпечення гарантій якості транспортних послуг;
* Забезпечення захисту інформації, переданої в мережі.

Основою нового протоколу V.6 є 128-бітові адреси, забезпечують понад 1000 адрес на кожного жителя землі. Впровадження цієї адресації зніме проблему дефіциту цифрових адрес. Проте головною метою розробки нового протоколу є не стільки розширення розрядності адреси, скільки збільшення рівнів ієрархії в адресі, що відбиває тепер 5 ідентифікаторів: два старших для провайдерів мережі (ідентифікатори провайдера та його реєстру) і три для абонентів (абонента, його мережі і вузла мережі) .

Доменний адреса складається з кількох, що відділяються один від одного крапкою буквено-цифрових доменів (domain - область). Ця адреса побудований на основі ієрархічної класифікації: кожен домен, крім крайнього лівого, визначає цілу групу комп'ютерів, виділених за якою-небудь ознакою, при цьому домен групи, що знаходиться зліва, є підгрупою правого домену. Всього в мережі зараз налічується більше 120 000 різних доменів.

Наприклад, географічні дволітерні домени деяких країн:

* Австрія - at;
* Болгарія - br;
* Канада - са;
* Росія - ru;
* США - us;
* Франція - fr.

Існують і домени, виділені за тематичними ознаками. Такі домени мають трибуквенне скорочена назва.

* Урядові установи - gov.
* Комерційні організації - com.
* Навчальні заклади - edu.
* Військові установи - mil.
* Мережеві організації - net.
* Інші організації - org.

Доменну адресу може мати довільну довжину. На відміну від цифрового адреси він читається в зворотному порядку. Спочатку вказується домен нижнього рівня - ім'я хост-комп'ютера, потім домени - імена підмереж і мереж, в яких він знаходиться, і, нарешті, домен верхнього рівня - найчастіше ідентифікатор географічного регіону (країни).

Перетворення доменної адреси у відповідний цифровий IP-адреса виконують спеціальні сервери DNS (Domain Name Server) - сервери імен. Тому користувачеві не потрібно знати цифрові адреси.

Але більш ефективно для адресації використовувати не просто доменну адресу, а універсальний локатор ресурсів - URL (Universal Resource Locator), який додатково до доменного адресою містить вказівки на використовувану технологію доступу до ресурсів і специфікацію ресурсу всередині файлової структури комп'ютера.

Наприклад, в URL http://www.engec.ru/user/lab/met.htm зазначені:

* Http - протокол передачі гіпертексту, що використовується для доступу. У переважній більшості випадків у WWW використовується саме гіпертекстовий протокол;
* Www.engec.ru - доменну адресу web-сервера. Адреси більшої частини серверів починаються з префікса www;
* User / lab / met.htm - специфікація файлу met.htm. Вказується шлях у файловій системі комп'ютера та ім'я файлу. У цій частині адреси може бути вміщена і інша інформація, що відображає, наприклад, параметри запиту користувача і обробної запит програми. Якщо специфікація файлу не вказана, то користувачеві буде виданий файл, за замовчуванням призначений для представлення сервера (сайту).

: [[Файл:Uniform Resource Locator.jpg]]

:Перше поняття - URL. Що таке URL? URL (Uniform Resource Locator) - це унікальний адреса для доступу до інформаційних ресурсів в інтернеті (зокрема, до веб-сторінок). Якщо користувачеві відомий URL веб-сторінки, він може побачити її, задавши цей URL в адресному рядку браузера.

URL представляє собою текстову рядок без пробілів. У цьому рядку спочатку вказується метод доступу до ресурсу, тобто протокол доступу, потім адресу ресурсу в Мережі (ім'я домену і хост-машини) і, нарешті, повний шлях до файлу на сервері.

:[[Файл:формат url.jpg]]

:[[Файл:url.jpg]]

:Що таке статичний URL
Статичний URL - це той, який не змінюється і зазвичай не містить URL параметрів. Він виглядет приблизно так:

http://www.example.com/archive/january.htm

Статичні URL можна знайти в Google, використовуючи конструкцію filetype: htm. Для великих, часто оновлюваних сайтів: форумів, онлайн магазинів, блогів і систем управління контентом вебмайстра використовують динамічні URL.
Що таке динамічний URL
Якщо контент сайту збережений у базі даних і відображається на сторінках за запитом, тоді можуть використовуватися динамічні урли. У цьому випадку сайт складається тільки з шаблонів для контенту. Зазвичай динамічний URL виглядає приблизно так:

http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31

Google уважає, що якщо в урле є знаки?, =, &, Тоді це динамічний URL. Один з недоліків динамічного URL в тому, що можливий випадок дублювання контенту. Тобто урл з різними параметрами може привести до одного і того ж контенту. Це одна з причин, по якій вебмайстра реврайтят урли в статичні.
Google рекомендує не переписувати динамічні URL в статичні
У своєму пості гуглі говорять і підкреслюють не потрібно переформовувати динамічні URL, щоб вони виглядали статичними, але в той же час визнають, що "статичні URL може мати невелику перевагу в клікабельності (CTR) ". І знову ж таки говорять про те, що "динамічні URL мають привілеї над статичними ". Коротко резюміруюя їх статтю, можна зробити висновок, що вони активно рекомендують використовувати динамічні URL і не переписувати їх у статичні, аргументуючи це тим, що:

* досить складно зробити правильним зміна динамічних URL в статичні
* Googblebot може успішно індексувати динамічні URL й інтерпретувати різні параметри
* при зміні URL ви можете позбавити бота цінних параметрів, що беруть участь в ранжируванні

Думки вебмайстрів про динамічних і статичних URL
У коментарях до згаданої статті вебмайстра у великому числі висловлюють невдоволення, посилаючись на переваги статичних урлов. Однак працівники Google у відповідях заявляють, і правильно помічають, що блог для веб-майстрів, а не для SEOшніков і пост писався саме для цієї аудиторії. Дійсно, багато вебмастера далеко не є знавцями SEO і можуть наробити багато помилок при реврайте динамічних URL в статичні. Google намагається з одного боку допомогти вебмайстрам, а з іншого зробити свою пошукову видачу більш релевантною для користувача.
Ренд Фішкін у своєму блозі висловлює думку про те, що Google дивиться на цю проблему з іншого ракурсу, як фахівець з маркетингу. Говорить про те, що Google не обманює або дізінформірует, а лише переймаються про найголовніше - ефективно і раціонально індексувати web і зберігати точні дані про контент сторінок.
Переваги динамічних URL

* зазвичай вони коротші
* гугл (перший з 4-х головних пошукачів) говорить, що може їх ефективно індексувати

Недоліки динамічних URL

* низький CTR в серп, в електронних листах, а також на форумах / блогах, де просто використовують копіпаст
* велика веротяность обрізання кінцевої частини URL і в результаті отримання чотиреста четвертий помилки при копіпаст
* низька релевантність ключового слова
* майже неможливо написати вручну і поширювати на бізнес-картах або диктувати по телефону
* дуже складно запам'ятовується або не запам'ятовується зовсім
* користувач точно не знає, чого очікувати перед тим, як запросить сторінку
* не оптимізовані для анкорного тексту (часто при копіпаст в блоги, форуми та ін)

Переваги статичних URL

* високий CTR у пошукових результатах, електронних листах (email), на сторінках і т.д.
* велика релевантність ключових словах
* просто для копіювання, вставки, і розповсюдження онлайн та офлайн
* легко запам'ятати і таким чином можна використовувати в брендінгу та офлайн медіа
* користувач зараннее може інтуїтивно знати, що йому очікувати при введенні урла в браузері
* можна чекати гарного анкорного тексту при використанні посилань у вигляді урла
* всі 4 з головних пошукачів і безліч інших псів зазвичай працюють зі статичними URL набагато простіше, ніж з динамічними, особливо при великій кількості параметрів

Недоліки статичних URL

* ви можете наплутати чого-небудь у процесі реврайта, що призведе до проблем отримання контенту користувачами і ботами

=='''Схеми (протоколи) URL'''==
 Загальноприйняті схеми (протоколи) URL включають:
 • ftp - Протокол передачі файлів FTP
 • http - Протокол передачі гіпертексту HTTP
 • https - Спеціальна реалізація протоколу HTTP, що використовує шифрування (як правило, SSL або TLS)
 • gopher - Протокол Gopher
 • mailto - Адреса електронної пошти
 • news - Новини Usenet
 • nntp - Новини Usenet через протокол NNTP
 • irc - Протокол IRC
 • prospero - Служба каталогів Prospero Directory Service
 • telnet - Посилання на інтерактивну сесію Telnet
 • wais - База даних системи WAIS
 • xmpp - Протокол XMPP (частина Jabber)
 • file - Ім'я локального файлу
 • data - Безпосередні дані (Data: URL)
 Екзотичні схеми URL:
 • afs - Глобальне ім'я файлу у файловій системі Andrew File System
 • cid - Ідентифікатор вмісту для частин MIME
 • mid - Ідентифікатор повідомлень для електронної пошти
 • mailserver - Доступ до даних з поштових серверів
 • nfs - Ім'я файлу в мережевій файловій системі NFS
 • tn3270 - Емуляція інтерактивної сесії Telnet 3270
 • z39.50 - Доступ до служб ANSI Z39.50
 • skype - Протокол Skype
 • smsto - Відкриття редактора SMS в деяких мобільних телефонах
 • ed2k - Файлообмінна мережа eDonkey, побудована за принципом P2P

=='''Кодування URL'''==

Поява адрес URL стало суттєвим нововведенням в Інтернеті. Проте з моменту його винаходу і до цього дня стандарт URL володіє серйозним недоліком - у ньому можна використовувати тільки обмежений набір символів, навіть менший, ніж в ASCII: латинські літери, цифри і лише деякі розділові знаки. Якщо ми захочемо використовувати в URL символи кирилиці, або ієрогліфи, або, скажімо, специфічні символи французької мови, то потрібні нам символи повинні бути перекодовані особливим чином.

У російськомовній Вікіпедії щодня доводиться бачити приклад кодування URL, оскільки російська мова використовує символи кирилиці. Наприклад, рядок виду:

<nowiki>http://ru.wikipedia.org/wiki/Микрокредит</nowiki>

 кодується в URL як:

<nowiki>http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0%B8%D1%82</nowiki>
Таке перетворення відбувається в два етапи: спочатку кожен символ кирилиці кодується в Юнікод ([[UTF-8]]) в послідовність з двох байтів, а потім кожен байт цієї послідовності записується в [[шістнадцяткова система числення | шістнадцятковому]] поданні:

М → D0 и 9C → %D0%9C
и → D0 и B8 → %D0%B8
к → D0 и BA → %D0%BA
р → D1 и 80 → %D1%80, и т. д.
Перед кожним таким шістнадцятковим кодом байта, згідно специфікації URL [2], ставиться знак відсотка (%) - звідси навіть виник англійський термін «percent-encoding», що позначає спосіб кодування символів в URL і URI.

Оскільки такого перетворення піддаються літери всіх алфавітів, окрім базової латиниці, то URL зі словами на переважній більшості мов (крім англійської, італійської, латинської) може втратити здатність сприйматися людьми.
Це все входить у протиріччя з принципом інтернаціоналізму, провозглашаемого усіма провідними організаціями Інтернету, включаючи W3C і ISOC. Цю проблему покликаний вирішити стандарт IRI (англ. International Resource Identifier) - міжнародних ідентифікаторів ресурсів, в яких можна було б без проблем використовувати символи Юнікоду, і які тому не ущемляли б права інших мов. Хоча заздалегідь складно сказати, чи зможуть коли-небудь ідентифікатори IRI замінити настільки широковживаними URL (і URI в цілому).

=='''Ініціатива PURL'''==
Ще один кардинальний недолік URL полягає у відсутності гнучкості. Ресурси у Всесвітній павутині та Інтернеті переміщуються, а посилання у вигляді URL залишаються, вказуючи на вже відсутні ресурси. Це особливо болісно для електронних бібліотек, каталогів та енциклопедій. Для вирішення цієї проблеми було запропоновано постійні локатори PURL (англ. Persistent Uniform Resource Locator). По суті це ті ж URL, але вони вказують не на конкретне місце розташування ресурсу, а на запис в базі даних PURL, де, у свою чергу, записаний вже конкретний URL-адресу ресурсу. При зверненні до PURL сервер знаходить потрібну запис в цій базі даних і перенаправляє запит вже на конкретне місце розташування ресурсу. Якщо адресу ресурсу змінюється, то немає потреби виправляти всі незліченні посилання на нього - досить лише змінити запис у БД. На даний момент ця ідея не стандартизована і не має широкого розповсюдження.
=='''Список використаних джерел'''==
# http://wiki.fizmat.tnpu.edu.ua/index.php/URL
# http://richvibe.blogspot.com/2010/10/url.html
# http://denweb.ru/put-veb-mastera/osnovnye-ponyatiyaurl-cookies-kilobajty-i-kilobity-chast3.html

[http://custom-paper-writing.com/custom_research_paper research paper help]

Управління ризиками

2011-10-24T12:57:14Z

Nixiedelacruz:

Управління ризиками розглядається на адміністративному рівні ІБ, оскільки тільки керівництво організації здатне виділити необхідні ресурси, ініціювати і контролювати виконання відповідних програм.
{{Студент | Name=Ірина| Surname=Гуменюк | FatherNAme=Олександрівна|Faculti=ФІС | Group=СН-41 | Zalbook=№ ПК 06-040}}
==Основні поняття==
Взагалі кажучи, управління ризиками, так само як і вироблення власної політики безпеки, актуально тільки для тих організацій, інформаційні системи яких і/або оброблювані дані можна вважати нестандартними. Звичайну організацію цілком влаштує типовий набір захисних заходів, вибраний на основі уявлення про типові ризики або взагалі без жодного аналізу ризиків (особливо це вірно з формальної точки зору, в світлі проаналізованого нами раніше законодавства в області ІБ). Можна провести аналогію між індивідуальним будівництвом і отриманням квартири в районі масової забудови. У першому випадку необхідно прийняти безліч рішень, оформити велику кількість паперів, в другому досить визначитися лише з декількома параметрами. Більш детально даний аспект розглянутий в статті Сергія Симонова "Анализ рисков, управления рисками" (Jet Info, 1999, 1). 
Використання інформаційних систем пов'язане з певною сукупністю ризиків. Коли можливий збиток неприйнятно великий, необхідно вжити економічно виправданих заходів захисту. Періодична (пере) оцінка ризиків необхідна для контролю ефективності діяльності в області безпеки і для врахування змін обстановки. 
З кількісної точки зору рівень ризику є функцією вірогідності реалізації певної загрози (що використовує деякі вразливі місця), а також величини можливого збитку. 
Таким чином, суть заходів щодо управління ризиками полягає у тому, щоб оцінити їх розмір, виробити ефективні і економічні заходи зниження ризиків, а потім переконатися, що ризики поміщені в прийнятні рамки (і залишаються такими). Отже, управління ризиками включає два види діяльності, які чергуються циклічно:
*(пере)оцінка (вимірювання) ризиків;
*вибір ефективних і економічних захисних засобів (нейтралізація ризиків).
По відношенню до виявлених ризиків можливі наступні дії:
*ліквідація ризику (наприклад, за рахунок усунення причини);
*зменшення ризику (наприклад, за рахунок використання додаткових захисних засобів);
*прийняття ризику (і вироблення плану дії у відповідних умовах);
*переадресація ризику (наприклад, шляхом укладення страхової угоди).
Процес управління ризиками можна розділити на наступні етапи:
#Вибір аналізованих об'єктів і рівня деталізації їх розгляду.
#Вибір методології оцінки ризиків.
#Ідентифікація активів.
#Аналіз загроз і їх наслідків, виявлення вразливих місць в захисті.
#Оцінка ризиків.
#Вибір захисних заходів.
#Реалізація та перевірка вибраних заходів.
#Оцінка залишкових ризиків.
Етапи 6 і 7 відносяться до вибирання захисних засобів (нейтралізації ризиків), решта – до оцінки ризиків.
Вже перерахування етапів показує, що управління ризиками – процесс циклічний. По суті, останній етап – це оператор кінця циклу, що приписує повернутися до початку. Ризики потрібно контролювати постійно, періодично проводячи їх переоцінку. Відзначимо, що сумлінно виконана і ретельно документована перша оцінка може істотно спростити подальшу діяльність. 
Управління ризиками, як і будь-яку іншу діяльність в області інформаційної безпеки, необхідно інтегрувати в життєвий цикл ІС. Тоді ефект виявляється найбільшим, а витрати – мінімальними. Раніше ми визначили п'ять етапів життєвого циклу. Стисло опишемо, що може дати управління ризиками на кожному з них. 
На етапі ініціації відомі ризики слід врахувати при виробленні вимог до системи взагалі і засобів безпеки зокрема.
На етапі закупівлі (розробки) знання ризиків допоможе вибрати відповідні архітектурні рішення, які грають ключову роль в забезпеченні безпеки.
На етапі встановлення виявлені ризики слід враховувати при конфігурації, тестуванні і перевірці раніше сформульованих вимог, а повний цикл управління ризиками повинен передувати впровадженню системи в експлуатацію. 
На етапі експлуатації управління ризиками повинне супроводжувати всі істотні зміни в системі. 
При виведенні системи з експлуатації управління ризиками допомагає переконатися в тому, що міграція даних відбувається безпечним чином.

==Підготовчі етапи==

Вибір аналізованих об'єктів і рівня деталізації їх розгляду – перший крок в оцінці ризиків. Для невеликої організації допустимо розглядати всю інформаційну інфраструктуру; проте якщо організація крупна, всеосяжна оцінка може вимагати неприйнятних витрат часу і сил. У такому разі слід зосередитися на найбільш важливих сервісах, заздалегідь погоджуючись з наближеністю підсумкової оцінки. Якщо важливих сервісів все ще багато, вибираються ті з них, ризики для яких свідомо великі або невідомі. 
Ми вже указували на доцільність створення карти інформаційної системи організації. Для управління ризиками подібна карта особливо важлива, оскільки вона наочно показує, які сервіси вибрані для аналізу, а якими довелося нехтувати. Якщо ІС міняється, а карта підтримується в актуальному стані, то при переоцінці ризиків відразу стане ясно, які нові або істотно змінені сервіси потребують розгляду. 
Взагалі кажучи, уразливим є кожен компонент інформаційної системи - від мережевого кабелю, який можуть прогризти миші, до бази даних, яка може бути зруйнована через невмілі дії адміністратора. Як правило, у сферу аналізу неможливо включити кожен гвинтик і кожен байт. Доводиться зупинятися на деякому рівні деталізації, знову-таки віддаючи собі звіт в наближеності оцінки. Для нових систем переважний детальний аналіз; стара система, що піддалася невеликим модифікаціям, може бути проаналізована поверхнево. 
Дуже важливо вибрати розумну методологію оцінки ризиків. Метою оцінки є отримання відповіді на два питання: чи прийнятні існуючі ризики, і якщо ні, то які захисні засоби варто використовувати. Значить, оцінка повинна бути кількісною, такою, що допускає порівняння із заздалегідь вибраними межами допустимості і витратами на реалізацію нових регуляторів безпеки. Управління ризиками - типове оптимізаційне завдання, і існує досить багато програмних продуктів, здатних допомогти в його вирішенні (іноді подібні продукти просто додаються до книг по інформаційній безпеці). Принципова трудність, проте, полягає в неточності початкових даних. Можна, звичайно, спробувати отримати для всіх аналізованих величин грошовий вираз, вирахувати все з точністю до копійки, але великого сенсу в цьому немає. Практичніше користуватися умовними одиницями. У простому і цілком допустимому випадку можна користуватися трибальною шкалою. Далі ми продемонструємо, як це робиться. 
При ідентифікації активів, тобто тих ресурсів і цінностей, які організація намагається захистити, слід, звичайно, враховувати не тільки компоненти інформаційної системи, але і підтримуючу інфраструктуру, персонал, а також нематеріальні цінності, такі як репутація організації. Відправною точкою тут є уявлення про місію організації, тобто про основні напрями діяльності, які бажано (або необхідно) зберегти у будь-якому випадку. Виражаючись об'єктно-орієнтованою мовою, слід в першу чергу описати зовнішній інтерфейс організації, що розглядається як абстрактний об'єкт. 
Одним з головних результатів процесу ідентифікації активів є отримання детальної інформаційної структури організації і способів її (структури) використання. Ці відомості доцільно нанести на карту ІС як грані відповідних об'єктів. 
Інформаційною основою скільки-небудь крупної організації є мережа, тому в число апаратних активів слід включити комп'ютери (сервери, робочі станції, ПК), периферійні пристрої, зовнішні інтерфейси, кабельне господарство, активне мережеве устаткування (мости, маршрутизатори і т.п.). До програмних активів, ймовірно, будуть віднесені операційні системи (мережева, серверні і клієнтські), прикладне програмне забезпечення, інструментальні засоби, засоби управління мережею і окремими системами. Важливо зафіксувати, де (у яких вузлах мережі) зберігається програмне забезпечення, і з яких вузлів воно використовується. Третім видом інформаційних активів є дані, які зберігаються, обробляються і передаються по мережі. Слід класифікувати дані по типах і ступеню конфіденційності, виявити місця їх зберігання і обробки, способи доступу до них. Все це важливо для оцінки наслідків порушень інформаційної безпеки. 
Управління ризиками – процесс далеко не лінійний. Практично всі його етапи пов'язані між собою, і після закінчення будь-якого з них може виникнути необхідність повернення до попереднього. Так, при ідентифікації активів може виявитися, що вибрані межі аналізу слід розширити, а ступінь деталізації – збільшити. Особливо важкий первинний аналіз, коли багатократні повернення до початку неминучі.

==Основні етапи==

Етапи, що передують аналізу загроз, можна вважати підготовчими, оскільки, строго кажучи, вони безпосередньо з ризиками не пов'язані. Ризик з'являється там, де є загрози. 
Короткий перелік найбільш поширених загроз був розглянутий раніше. На жаль, на практиці загроз значно більше, причому далеко не всі з них носять комп'ютерний характер. Так, цілком реальною загрозою є наявність мишей і тарганів в приміщеннях, де розташована організація. Перші можуть пошкодити кабелі, другі викликати коротке замикання. Як правило, наявність тієї чи іншої загрози є наслідком недоліків у захисті інформаційної системи, які, у свою чергу, пояснюються відсутністю деяких сервісів безпеки або недоліками в захисних механізмах, що її реалузують. Небезпека прогризання кабелів виникає не просто там, де є миші, вона пов'язана з відсутністю або недостатньою міцністю захисної оболонки. 
Перший крок в аналізі загроз – їх ідентифікація. Дані види загроз слід вибирати виходячи з міркувань здорового глузду (виключивши, наприклад, землетруси, проте не забуваючи про можливість захоплення організації терористами), але в межах вибраних видів провести максимально детальний аналіз. 
Доцільно виявляти не тільки самі загрози, але і джерела їх виникнення - це допоможе у виборі додаткових засобів захисту. Наприклад, нелегальний вхід у систему може стати наслідком відтворення початкового діалогу, підбору пароля або підключення до мережі неавторизованого устаткування. Очевидно, для протидії кожному з перерахованих способів нелегального входу потрібні свої механізми безпеки.
Після ідентифікації загрози необхідно оцінити вірогідність її здійснення. Допустимо використовувати при цьому трибальну шкалу (низька (1), середня (2) і висока (3) вірогідність). 
Окрім вірогідності здійснення, важливий розмір потенційного збитку. Наприклад, пожежі бувають нечасто, але збиток від кожної з них, як правило, великий. Тяжкість збитку також можна оцінити за трибальною шкалою. 
Оцінюючи розмір збитку, необхідно мати на увазі не тільки безпосередні витрати на заміну устаткування або відновлення інформації, але і віддаленіші, такі як підрив репутації, ослаблення позицій на ринку і т.п. Хай, наприклад, в результаті дефектів в управлінні доступом до бухгалтерської інформації співробітники дістали можливість коректувати дані про власну заробітну плату. Наслідком такого стану справ може стати не тільки перевитрата бюджетних або корпоративних коштів, але і повне розкладання колективу, що загрожує розвалом організації. 
Вразливі місця володіють властивістю притягати до себе не тільки зловмисників, але і порівняно чесних людей. Не всякий встоїть перед спокусою трішки збільшити свою зарплату, якщо є упевненість, що це зійде з рук. Тому, оцінюючи вірогідність здійснення загроз, доцільно виходити не тільки з середньостатистичних даних, але зважати також на специфіку конкретних інформаційних систем. Якщо у підвалі будинку, що займає організація, розташовується сауна, а сам будинок має дерев'яні перекриття, то вірогідність пожежі, на жаль, виявляється істотно вище середньої.
Після того, як накопичено початкові дані і оцінений ступінь невизначеності, можна переходити до обробки інформації, тобто власне до оцінки ризиків. Цілком допустимо застосувати такий простий метод, як множення вірогідності здійснення загрози на передбачуваний збиток. Якщо для вірогідності і збитку використовувати трибальну шкалу, то можливих добутків буде шість: 1, 2, 3, 4, 6 і 9. Перші два результати можна віднести до низького ризику, третій і четвертий – до середнього, два останніх - до високого, після чого з'являється можливість знову привести їх до трибальної шкали. За цією шкалою і слід оцінювати прийнятність ризиків. Правда, граничні випадки, коли обчислена величина співпала з прийнятною, доцільно розглядати ретельніше через наближений характер результату. 
Якщо якісь ризики виявилися неприпустимо високими, необхідно їх нейтралізувати, реалізувавши додаткові заходи захисту. Як правило, для ліквідації або нейтралізації вразливого місця, що зробило загрозу реальною, існує декілька механізмів безпеки, різних по ефективності і вартості. Наприклад, якщо велика вірогідність нелегального входу в систему, можна вимагати, щоб користувачі обирали довгі паролі (скажімо, не менше восьми символів), задіювати програму генерації паролів або купити інтегровану систему аутентифікації на основі інтелектуальних карт. Якщо є вірогідність умисного пошкодження сервера баз даних, що може мати серйозні наслідки, можна врізати замок у двері серверної кімнати або поставити біля кожного сервера по охоронцеві. 
Оцінюючи вартість заходів захисту, доводиться, зрозуміло, враховувати не тільки прямі витрати на закупівлю устаткування і/або програм, але і витрати на впровадження новинки і, зокрема, навчання і перепідготовку персоналу. Цю вартість також можна оцінити за трибальною шкалою і потім порівняти її з різницею між обчисленим і допустимим ризиком. Якщо по цьому показнику новий засіб виявляється економічно вигідним, його можна узяти на замітку (відповідних засобів, ймовірно, буде декілька). Проте якщо засіб виявиться дорогим, його не слід відразу відкидати, пам'ятаючи про наближеність розрахунків. 
Вибираючи відповідний спосіб захисту, доцільно враховувати можливість екранування одним механізмом забезпечення безпеки відразу декількох прикладних сервісів. Так поступили в Масачусетському технологічному інституті, захистивши декілька тисяч комп'ютерів сервером аутентифікації Kerberos. 
Важливою обставиною є сумісність нового засобу з організаційною і апаратно-програмною структурою, що склалася і традиціями організації. Заходи безпеки, як правило, носять недружній характер, що може негативно позначитися на ентузіазмі співробітників. Деколи збереження духу відвертості важливіше за мінімізацію матеріальних втрат. Втім, такого роду орієнтири повинні бути співставлені в політиці безпеки верхнього рівня.
Можна уявити собі ситуацію, коли для нейтралізації ризиків не існує ефективних і прийнятних за ціною заходів. Наприклад, компанія, що базується у сейсмічно небезпечній зоні, не завжди може дозволити собі будівництво захищеної штаб-квартири. У такому разі доводиться піднімати планку прийнятного ризику і переносити центр тяжіння на пом'якшення наслідків і вироблення планів відновлення після аварій, стихійних лих та інших подій. Продовжуючи приклад з сейсмонебезпекою, можна рекомендувати регулярне тиражування даних в інше місто та оволодіння засобами відновлення первинної бази даних. 
Як і всяку іншу діяльність, реалізацію і перевірку нових регуляторів безпеки слід заздалегідь планувати. У плані необхідно врахувати наявність фінансових коштів і терміни навчання персоналу. Якщо мова йде про програмно-технічний механізм захисту, потрібно скласти план тестування (автономного і комплексного). 
Коли накреслені заходи прийняті, необхідно перевірити їх дієвість, тобто переконатися, що залишкові ризики стали прийнятними. Якщо це насправді так, значить, можна спокійно намічати дату найближчої переоцінки. У іншому випадку доведеться проаналізувати допущені помилки і провести повторний сеанс управління ризиками негайно.

==Перелік посилань==
# [http://dl.tstu.edu.ua/123/content/3265/ Управління ризиками]

[[Категорія: Індивідуальні завдання виступу на семінарах з предмету "Комп'ютерні системи захисту інформації"]]
[[Категорія:Виступ на семінарі]]

[http://custom-paper-writing.com/ custom term paper]