„управление и защита на корпоративни информационни системи
PKI (Public Key Infrastrukture)
Изтегляне 1.15 Mb.
|
- Навигация на страницата:
- Цифрови сертификати
- Сертифициращи организации (Certificate Authorities, CA)
- Структура на PKI
- Заключение
- Използвани източници
3.3.2. PKI (Public Key Infrastrukture)
След като разгледахме криптографията, базирана на асиметрични алгоритми (Public Key Cryptography) , можем да дефинираме понятието Public Key Infrastructure (PKI), като комбинация от операционна система и приложни услуги, които правят възможен и лесен процеса на тази криптография. PKI най-често се реализира съгласно стандарта X.509 (виж.т.4) в структурата на PKI са заложени средства за:
Дотук използвахме понятието публичен ключ при обяснение на различните операции по криптиране и подписване на данните. Беше споменато, че публичните ключове са достояние на всеки, който иска да ги използва, било да криптира данните към даден получател или да декриптира нечий електронен подпис. Остава неизяснен въпросът как се разпространяват публичните ключове. За тази цел се използват т.н. цифрови сертификати. Важно е да се отбележи, че цифровите сертификати се използват за разпространение единствено на публичните ключове, докато частните ключове се пазят само при собствениците им, без да се пренасят по мрежата. Идеята на цифровия сертификат е да докаже по безспорен начин, че даден публичен ключ принадлежи на дадено лице (в общия случай може да се говори за институция, сървър и други). Цифровият сертификат съдържа публичния ключ, както и набор от атрибути, между които е и името на собственика на сертификата, срок за валидност на този ключ, сериен номер и др. (в последствие ще бъдат разяснени всички полета). И тъй като сертификатът идентифицира своя собственик, много е важно всеки, който има достъп до този сертификат, да бъде убеден в неговата достоверност. Ето защо всеки сертификат съдържа информация за това кой го е издал и е подписан от съответната Сертифицираща Организация. По този начин, когато даден сертификат се чете за извличане на публичния ключ или името на собственика, се проверява и коя организация го е издала. Ако организацията е в списъка от организации, на които потребителя се доверява, сертификатът се „признава” за валиден. В противен случай сертификатът е безполезен за четящия. С други думи, ползването на цифрови сертификати е много подобно на използването на идентификационните документи в реалния живот, които също трябва да бъдат издадени от оторизирани организации. Такава организация е Министерството на вътрешните работи, което е оторизирано да издава и личните карти на гражданите. На практика обаче не само Министерството издава документите. Това се прави от звена, които се намират на по-ниските нива от неговата йерархична структура. Абсолютно аналогично стоят нещата и при цифровите сертификати, където съществува т.н. сертификационна йерархия.
Организации, които издават цифрови сертификати се наричат Certificate Authorities (CA’s) и всяка една от тях е длъжна да подписва издадените от нея сертификати със собствения си частен ключ. Когато CA издава сертификат и го изпраща на този, който си го е поръчал, получателят задължително трябва да има достъп до сертификата на CA. Това е наложително, за да може той да декодира подписа на издадения сертификат и да се убеди, че този сертификат е издаден точно от CA , на която го е поръчал, а не от измамници. Самият сертифика на CA може да бъде издаден от друга CA, която е по-високо в йерархията от организации, или от самата CA, ако тя се намира на върха на йерархията, т.с. ако тя е Root Certificate Authority (RCA). Такъв сертификат се нарича Root сертификат. По правило сертификатът на върховната организация (RCA), която тя само си издава поради липса на по-висшестояща организация, се предава надолу по йерархията не по електронен път, а по някакъв друг по-сигурен начин. Сертифициращите организации издават на своите клиенти сертификати, които не могат да бъдат използвани за подписване на други сертификати. Такива се издават само на сертифициращи организации при изключително строги мерки за сигурност. В тази ситуация се допуска съществуването на сертификати, които не са подписани от друг сертификат. Такива сертификати се подписват от самите себе си и се наричат собственоръчно-подписани сертификати (self-signed-certifikates). В частност Root-сертификатите на сертифициращите организации от първо ниво се явяват self-signed сертификати. В общия случай един self-signed сертификат не може да удостоверява връзка между публичен ключ и дадено лице, защото с подходящ софтуер всеки може да генерира такъв сертификат на името на избрано от него лице или фирма. При комуникация по Интернет, където няма сигурен начин да се установи дали даден сертификат, изпратен по мрежата не е подменен някъде по пътя, не се използват self-signed сертификати, а само сертификати, издадени от утвърдени сертифициращи организации. Ако обобщим, издаването на сертификати по нивата на сертификация следва алгоритъма:
Сертификатът се признава за валиден от потребителите, ако те изрично са заявили своето доверие към CA , която го е издала, или той е подписан от CA, която е подписана от CA, на която вярваме (така наречената верига на доверие – виж т.3.4).
Практически инфраструктурата на PKI се изгражда и поддържа от три страни. Това са:
Ще се спрем по-подробно на тези организации. Инфраструктурата на публичните ключове (PKI) е съставена от много CA, които изграждат помежду си доверени връзки. Връзка на доверие (trust path) свързва „доверена трета страна” с такава, която и вярва (и/или е сключила подходящ договор с нея). Получателите на подписани съобщения, които нямат връзка със съответната CA, от която са получили сертификата, могат да ги проверят като се изгради път доверени връзки между тяхната CA и издалата съответния сертификат. CA потвърждава идентичността на участниците, които си комуникират по електронен път. Удостоверяването на идентичността е необходим елемент за участници, които си общуват по официален начин: например при разплащателни заявки. CA е основният изграждащ елемент на PKI. Тя е съвкупност от софтуер, хардуер и хора, които я управляват. CA се идентифицира по два атрибута – име и публичен ключ. Тя изпълнява следните основни функции във цялата инфраструктура:
Когато издава сертификати, СА гарантира, че субектът (чието име фигурира в сертификата) има частния ключ, който съответства на публичния ключ, който се съдържа в сертификата. Ако СА въведе допълнителна информация във сертификата, то се гарантира,че тази информация принадлежи също на субекта. Когато субект на сертифициране е друга СА, то тогава издателят гарантира, че можем да се доверим на сертификат издаден от друга СА. СА въвежда своето име във всеки сертификат или списъл с анулирани сертификати, които създава и след това ги подписва със воя частен ключ. Потребителите могат лесно да идентифицират сертификатите по името на СА, която ги е подписала. За да са сигурни, че те наистина са достоверни, проверяват добавения подпис като взимат публичния ключ на СА. Много е важно СА да предостави наистина сериозна защита на своя частен ключ. Регистрационната организация (RA) е единица, на която СА вярва. Целта й е да проверява, когато някой потребител прави заявка със своя публичен ключ да му бъде издаден сертификат или иска такъв да бъде анулиран, заради компрометиран ключ, дали потребителят е този, за когото се представя. Това обикновено става с лична информация, като адрес и/или месторабота, за по-сигурни цели – и документи, удостоверяващи самоличността, като лична карта и шофьорска книжка. RA е също съвкупност от хардуер, софтуер и хора, които управляват. Често RA може да се управлява от един човек. Когато цялата инфраструктура е по-голяма се налага RA да е отделно от CA. Всяко RA трябва да осигури адекватна защита на своя частен ключ. СА трябва да издават и координират Списъци с Анулирани Сертификати (Certificate Revocation List – CRLs). Тези списъци обикновено се подписват от същата организация, която издава сертификатите. Сертификатът може да бъде анулиран, ако собственикът му си загуби частния ключ или стане недостоверен, например, ако собственикът напусне компанията, в която работи или си смени името. Анулиране може да се получи и при компрометиране на частния ключ на СА. Списъците също поддържат информация за предишни анулирания на сертификати. Сертификатът е валиден, ако не му е изтекъл срокът на валидност или не е поставен в списъка с анулирани сертификати. СА могат да бъдат свързани по няколко начина. Повечето организации, които инсталират PKI, избират между йерархична и мрежова структура. В йерархичната структура СА са подредени йерархично под под главната (root CA), която издава сертификати на подчинените СА. В такава организация, всяка доверена страна знае публичния ключ на RCA и му се доверява. Всеки сертификат може да бъде проверен като се провери цялата верига от RCA. Например, ако Б иска да получи сертификат от А, то СА наБ ще подпише верига от СА1 до СА3, която минава през СА2 (Фиг.1.1). В мрежовата структура независими СА изграждат доверени връзки помежду си. Системата е децентрализирана. Доверена страна знае публичния ключ на СА, с която е сключила доверена връзка. Ако тази страна получи сертификат от СА, с която няма връзка, се проверява веригата от доверени връзки до въпросната СА. Например, ако А иска сертификат от Б, то може да се осъществи примерно веригата:СА1 получава и подписва сертификата от СА2, а СА2 подписва сертификата от СА4 (фиг.1.2). Съществува още една архитектура за връзка между инфраструктури. Мостова архитектура или за по-кратко мост (Bridge CA), която е проектирана да свързва инфраструктури, независимо от техните архитектури. Тази архитектура не издава директно сертификати към потребители, а към СА. Зa разлика от RCA на йерархичната структура, мостовата не е център, на който всички се доверяват. Обикновено мостовата архитектура изпълнява посреднически цели между различните архитектури – изгражда доверена връзка между потребителите на една архитектура с потребителите на друга. Ако една област на доверие (trust domain) е изградена като йерархична, мостовата структура ще изгради доверена връзка с RCA. A ако областта е изградена като мрежова, мостът ще направи доверена връзка само с едно СА от мрежовата структура. СА, която е свързана с моста се нарича главна (principal CA).
Резултатите от компютърните престъпления могат да бъдат в различна степен опасни за даден човек или организация, както да доведат и до други престъпления. От гледна точка на бизнеса най-опасните последствия са достъпът до търговските тайни, унищожаването на информация, която не може да бъде възстановена, и възпрепятстването на работата на вътрешните и външните информационни системи. Защитата на класифицирана информация в копоративната „INTRANET” е сложна задача, която изисква следене на множество параметри и области. В настоящата разработка е разгледана една малка част от техническата и програмно – техническата част от тази защита, която с навлизането на новите технологии става все по – скъпа и изисква все повече познания в областта. Могат да се изброят и много други управленски, организационни, програмни и програмно-технически мерки за защита на информацията в копоративната „ИНТРАНЕТ”, още повече, че практиката по този проблем е все още минимална. Малко са сертифицираните системи и мрежи у нас, все още няма утвърдени процедури по прилагането на ЗЗКИ и съпътстващите го наредби. В хода на работата в организационните единици възникват въпроси и предложения, които предстои да бъдат прилагани и решавани. За организациите, които не разполагат със служители с необходимата квалификация и финансов ресурс е трудно да проектират, изграждат, интегрират, управляват и поддържат ефективна архитектура на сигурността и създават съответно процедурите и политиките за сигурност, поддържащи тази архитектура. Изходът е да се възползват от професионални услуги в тази област, а именно:
Използвани източнициКниги:
Уеб адреси: 1. www.dksi.bg 2. www.security.org 3. www.sagabg.net/seminar 4. www.idg.bg 5. www.compulenta.ru/news/story237/ 6. www.hardwarecentral.com/hardwarecentral/reviews/1615/1/ 7. www.ademcoint.com/espanol/library/northern.htm 8. www.asi.com.ph/asi_biometric_veriprint.htm 9. www.lynkdata.com.uk/biometrics_fingerprint_readers.htm 10. www.dealtime.co.uk/xPC_tardus_defcon_autheriticator_20/79697 11. www.sony.net/Products/puppy/ 12. http://www.softerra.ru/tehnologizm/14845 13. www.sony.net/Products/puppy/ 14. www.eyenetwatch.com Нормативни актове:
1 По подробно определението е дадено в Петров, Р., Защита на информацията в компютрите и мрежите, Издателство „Корени", С., 2002. 2 Така се определят в закона организациите и фирмите, работещи с класифицирана информация. 3 Наредба за задължителните общи условия за сигурност на автоматизираните информационни системи/мрежи, в които се създава, обработва, съхранява и пренася класифицирана информация. 4 По подробно този елемент е развит в учебника на Павлов, П., Актуални информационни технологии в отбраната и сигурността, УИ „Стопанство”, 2001. 5 По подробно този въпрос е развит в гл. 4 на учебника: Павлов, Г., Информационни технологии в отбраната и сигурността, УИ „Стопанство”, 2003. В ЗЗКИ се определят три нива: „строго секретно”, „секретно”, „поверително” и „за служебно ползване”. 6 Пак там. 7 Тези елементи са подробно описани в издадените от ДКСИ методика за физическа сигурност. 8 „Документалната сигурност” е най-добре развитият елемент в законодателството и затова не се разглежда в статията. 9 Закон за защита на класифицираната информация, и съпътстващите го наредби. 10 За MT Digit някои параметри не са характерни 11 Под цифрови сертификати тук разбираме персонални цифрови сертификати. Те заместват паспорта (личната карта) или съдебното рещение за регистрацията на фирмата. Има и други видове сертификати, например такива, които се издават на сървъри, рутери и др. 12 Кракер (хакер) – оригиналното му значение е „компютърен ентусиаст” – някои, който изучава в дълбочина програмните езици и компютърните системи. Каталог: files -> files files -> Р е п у б л и к а б ъ л г а р и я files -> Дебелината на армираната изравнителна циментова замазка /позиция 3/ е 4 см files -> „Европейско законодателство и практики в помощ на добри управленски решения, която се състоя на 24 септември 2009 г в София files -> В сила oт 16. 03. 2011 Разяснение на нап здравни Вноски при Неплатен Отпуск ззо files -> В сила oт 23. 05. 2008 Указание нои прилагане на ксо и нпос ксо files -> 1. По пътя към паметник „1300 години България files -> Георги Димитров – Kreston BulMar files -> В сила oт 13. 05. 2005 Писмо мтсп обезщетение Неизползван Отпуск кт Изтегляне 1.15 Mb. Сподели с приятели:
|
