Другим завданням є створення таких механізмів, під час використання яких неможливо було б підмінити будь-кого з учасників, тобто. потрібна цифровий підпис. При використанні комунікацій для вирішення широкого кола завдань, наприклад, у комерційних та приватних цілях, електронні повідомлення та документи повинні мати еквівалент підпису, що міститься у паперових документах. Необхідно створити метод, під час використання якого всі учасники будуть переконані, що повідомлення було надіслано конкретним учасником. Це сильніша вимога, ніж автентифікація.
Діффі та Хеллман досягли значних результатів, запропонувавши спосіб вирішення обох завдань, який радикально відрізняється від усіх попередніх підходів до шифрування.
Спочатку розглянемо загальні риси алгоритмів шифруванняз відкритим ключем та вимоги до цих алгоритмів. Визначимо вимоги, яким повинен відповідати алгоритм, що використовує один ключ для шифрування, інший ключ - для дешифрування, і при цьому обчислювально неможливо визначити ключ, що дешифрує, знаючи тільки алгоритм шифрування і шифруючий ключ.
Крім того, деякі алгоритми, наприклад RSA, мають наступну характеристику: кожен з двох ключів може використовуватися як для шифрування, так і для дешифрування.
Спочатку розглянемо алгоритми, що володіють обома характеристиками, а потім перейдемо до алгоритмів відкритого ключа, які не мають другої властивості.
При описі симетричне шифруваннята шифрування з відкритим ключем будемо використовувати наступну термінологію. Ключ , що використовується в симетричне шифрування, будемо називати секретним ключем. Два ключі, які використовуються при шифруванні з відкритим ключем, будемо називати відкритим ключемі закритим ключем. Закритий ключ тримається в секреті, але називатимемо його закритим ключем , а не секретним, щоб уникнути плутанини з ключем, що використовується в симетричне шифрування. Закритий ключ будемо позначати KR, відкритий ключ - KU.
Припускатимемо, що всі учасники мають доступ до відкритих ключів один одного, а закриті ключі створюються локально кожним учасником і, отже, не повинні розподілятися.
У будь-який час учасник може змінити свій закритий ключ і опублікувати складовий пару відкритий ключ, замінивши їм старий відкритий ключ.
Діффі та Хеллман описують вимоги, яким має задовольняти алгоритм шифруванняз відкритим ключем.
- Обчислювально легко створювати пару (відкритий ключ KU, закритий ключ KR).
- Обчислювально легко, маючи відкритий ключ і незашифроване повідомлення М створити відповідне зашифроване повідомлення:
- Обчислювально легко дешифрувати повідомлення, використовуючи закритий ключ:
М = D KR [C] = D KR]
- Обчислювально неможливо, знаючи відкритий ключ KU, визначити закритий ключ KR.
- Обчислювально неможливо, знаючи відкритий ключ KU і зашифроване повідомлення, відновити вихідне повідомлення М.
Можна додати шосту вимогу, хоча вона не виконується для всіх алгоритмів з відкритим ключем:
- Шифруючі та дешифруючі функції можуть застосовуватись у будь-якому порядку:
М = Е KU]
Це досить сильні вимоги, що вводять поняття. Односторонньою функцієюназивається така функція, яка має кожен аргумент має єдине зворотне значення, у своїй обчислити саму функцію легко, а обчислити зворотну функцію важко.
Зазвичай "легко" означає, що проблему можна вирішити за поліноміальний час від довжини входу. Таким чином, якщо довжина входу має n бітів, то час обчислення функції пропорційно n a де а - фіксована константа. Отже, кажуть, що алгоритм належить класу поліноміальних алгоритмів Р. Термін " складно " означає складніше поняття. Загалом вважатимемо, що проблему вирішити неможливо, якщо зусилля на її вирішення більше поліноміального часу від величини входу. Наприклад, якщо довжина входу n бітів, і час обчислення функції пропорційно 2 n то це вважається обчислювально неможливим завданням. На жаль, важко визначити, чи виявляє конкретний алгоритм таку складність. Понад те, традиційні ставлення до обчислювальної складності фокусуються на гіршому разі чи середньому випадку складності алгоритму. Це неприйнятно для криптографії, де потрібна неможливість інвертувати функцію для всіх або багатьох значень входів.
Повернемося до визначення односторонньої функції з люком, яку, подібно односторонньої функціїлегко обчислити в одному напрямку і важко обчислити у зворотному напрямку до тих пір, поки недоступна деяка додаткова інформація. За наявності цієї додаткової інформації інверсію можна визначити за поліноміальний час. Таким чином, одностороння функціяз люком належить сімейству односторонніх функцій f k таких, що
Ми бачимо, що розробка конкретного алгоритму з відкритим ключем залежить від відкриття відповідного односторонньої функції з люком.
Криптоаналіз алгоритмів із відкритим ключем
Як і у випадку симетричне шифрування, алгоритм шифруванняз відкритим ключем уразливий для лобової атаки. Контрзаходу стандартна: використовувати великі ключі.
Криптосистема з відкритим ключем застосовує певні неінвертовані математичні функції. Складність обчислень таких функцій перестав бути лінійної кількості бітів ключа, а зростає швидше, ніж ключ. Таким чином, розмір ключа повинен бути досить великим, щоб зробити лобову атаку непрактичною, і достатньо маленьким для практичного шифрування. Насправді розмір ключа роблять таким, щоб лобова атака була непрактичною, але в результаті швидкість шифрування виявляється досить повільною для використання алгоритму в загальних цілях. Тому шифрування з відкритим ключем в даний час в основному обмежується програмами керування ключем та підпису, в яких потрібне шифрування невеликого блоку даних.
Інша форма атаки полягає в тому, щоб знайти спосіб обчислення закритого ключа, знаючи відкритий ключ. Неможливо математично довести, що ця форма атаки виключена для конкретного алгоритму відкритого ключа. Таким чином, будь-який алгоритм, включаючи широко використовуваний алгоритм RSA є підозрілим.
Нарешті існує форма атаки, специфічна для способів використання систем з відкритим ключем. Це атака можливого повідомлення. Припустимо, наприклад, що повідомлення складається виключно з 56-бітного ключа сесії для алгоритму симетричного шифрування. Противник може зашифрувати всі можливі ключі , використовуючи відкритий ключ , і може дешифрувати будь-яке повідомлення, що відповідає зашифрованому тексту. Таким чином, незалежно від розміру ключа схеми відкритого ключа атака зводиться до лобової атаки на 56-бітний симетричний ключ. Захист від подібної атаки полягає у додаванні певної кількості випадкових бітів у прості повідомлення.
Основні способи використання алгоритмів із відкритим ключем
Основними способами використання алгоритмів з відкритим ключем є шифрування/дешифрування, створення та перевірка підпису та обмін ключа.
Шифруванняз відкритим ключем складається з наступних кроків:
Мал. 7.1.
- Користувач В створює пару ключів KU b і KR b , що використовуються для шифрування та дешифрування повідомлень, що передаються.
- Користувач робить доступним деяким надійним способом свій ключ шифрування, тобто. відкритий ключ KU b. Закладений ключ KR b, що становить пару, тримається в секреті.
- Якщо А хоче надіслати повідомлення У , він шифрує повідомлення, використовуючи відкритий ключ KU b .
- Коли отримує повідомлення, він дешифрує його, використовуючи свій закритий ключ KR b . Ніхто інший не зможе дешифрувати повідомлення, тому що цей закритий ключ знає лише .
Якщо користувач (кінцева система) надійно зберігає свій закритий ключ, ніхто не зможе підглянути повідомлення, що передаються.
Створення та перевірка підпису складається з наступних кроків:
Мал. 7.2.
- Користувач А створює пару ключів KR A і KU A , які використовуються для створення та перевірки підпису повідомлень, що передаються.
- Користувач А робить доступним у певний надійний спосіб свій ключ перевірки, тобто.
У чорний день для Росії 7 липня 2016 року, разом із підписанням пакета поправок Ярової, президент Путін доручив уряду звернути увагу на застосування норм закону «про відповідальність за використання на мережах зв'язку та (або) при передачі повідомлень в інформаційно-телекомунікаційній мережі інтернет несертифікованих засобів кодування (шифрування)» , а також на «розробку та ведення уповноваженим органом в галузі забезпечення безпеки Російської Федерації реєстру організаторів розповсюдження інформації в мережі Інтернет, які надають на запит уповноважених відомств інформацію, необхідну для декодування електронних повідомлень, що приймаються, передаються, додаються та (або) обробляються у разі їх додаткового кодування».
ФСБ було доручено затвердити порядок сертифікації засобів кодування під час передачі повідомлень в інтернеті, визначити перелік коштів, що підлягають сертифікації, а також порядок передачі ключів шифрування на адресу уповноваженого органу у сфері держбезпеки. Це потрібно для того, щоб спецслужби могли отримати ключі та розшифрувати трафік HTTPS та інші зашифровані дані користувачів у разі потреби. Цей захід набирає чинності вже зараз, тобто за півтора роки до набрання чинності нормою про обов'язкове зберігання всього трафіку строком до шести місяців.
12 серпня 2016 року Федеральна служба безпеки Російської Федерації опублікувала наказ № 432 від 19.07.2016 № 432 «Про затвердження Порядку подання організаторами поширення інформації в інформаційно-телекомунікаційній мережі «Інтернет» до Федеральної служби безпеки Російської Федерації інформації, необхідної для декодування даних, що передаються, електронних повідомлень користувачів інформаційно-телекомунікаційної мережі «Інтернет», що додаються та (або) оброблюються.
Цей наказ встановлює процедуру отримання ключів шифрування у власників серверів та інших інтернет-сервісів. Процедура цілком логічна та проста.
1. Організатор розповсюдження інформації у мережі «Інтернет» здійснює передачу інформації для декодування на підставі запиту уповноваженого підрозділу, підписаного начальником (заступника начальника).4. Інформація передається на магнітному носії поштою або електронною поштою. Як варіант можна узгодити з ФСБ доступ фахівців до інформації для декодування.
Уповноваженим підрозділом ФСБ щодо отримання ключів шифрування призначено Організаційно-аналітичне управління Науково-технічної служби Федеральної служби безпеки Російської Федерації.
Для довідки, до магнітних носіїв відносяться магнітні диски, магнітні карти, магнітні стрічки та магнітні барабани.
Якщо власник сервера відмовляється надати ключ, необхідний для розшифровки HTTPS або іншого зашифрованого трафіку, він може бути накладений штраф у мільйон рублів.
Ще до публікації конкретного порядку передачі ключів представники деяких інтернет-компаній висловили сумнів щодо можливості виконання закону щодо передачі ключів шифрування. Вони кажуть, що під час використання протоколу HTTPS ключі шифрування не можна зберігати технічно.
Але, як кажуть, проблеми індіанців шерифа не турбують. Процедура встановлена - її потрібно дотримуватись.
Безпека зашифрованих даних забезпечується як сильними алгоритмами шифрування. Недотримання принципів використання ключів шифрування може поставити під загрозу захищеність інформації навіть при тому, що в системі будуть реалізовані найкриптостійкі алгоритми.
Припустимо, є два користувача (назвемо їх I та J), які вирішили обмінюватися зашифрованими повідомленнями через Інтернет. Подивимося, як це зробити, з прикладу комплексного методу шифрування.
Комплексний метод
Цей метод застосування алгоритмів симетричного та асиметричного шифрування усуває ряд недоліків, властивих кожному з них при роздільному застосуванні. Отже, щоб обмінятися зашифрованими повідомленнями через Інтернет, користувачам I та J необхідно попередньо зробити таке.
1. Вибрати алгоритми шифрування та його параметри. Згадаймо (див. статтю "BYTE/Росія" No 8"2003), що кожен алгоритм має безліч параметрів, які мають бути ідентичні, - інакше навіть за наявності правильного ключа шифрування буде неможливо розшифрувати інформацію. Наприклад, для алгоритму ГОСТ 28147-89 повинні бути узгоджені таблиці замін, використовуваний режим алгоритму та принципи формування синхропосилок.
2. Згенерувати ключі асиметричного шифрування. Користувач I генерує пару ключів KsI (secret – секретний) та KpI (publIc – відкритий), користувач J створює пару KsJ та KpJ.
3. Обмінюватися відкритими ключами або зробити доступними один одному. Припустимо, що відкриті ключі KpI та KpJ користувачі пересилають один одному електронною поштою.
Не розглядатимемо тут проблему перехоплення відкритих ключів під час передачі та їх підміни зловмисником – це тема окремої розмови. Припустимо, ключі успішно передані та отримані, після чого можна надсилати зашифроване повідомлення. Це робить користувач J, відправляючи користувачеві I повідомлення M.
Процес обміну ілюструє рис. 1. Перед надсиланням повідомлення користувач J створює випадковий ключ симетричного шифрування (назвемо його Ksimm). Користувач J асиметрично зашифровує ключ Ksimm на відкритому ключі користувача I KpI і відправляє зашифрований ключ користувачу I. Потім користувач J зашифровує ключем Ksimm повідомлення M, і отриманий шифртекст C надсилається користувачу I. Користувач I отримує зашифрований ключ Ksimm і асимметричний . За допомогою отриманого ключа Ksimm користувач розшифровує повідомлення M.
Як було зазначено вище, недоліки алгоритмів симетричного та асиметричного шифрування при їхньому спільному використанні частково компенсуються. Зокрема, приховане поширення ключів симетричного шифрування досягається за рахунок того, що симетричний ключ Ksimm, на якому шифрується власне інформація, передається відкритими каналами зв'язку в зашифрованому вигляді - для його зашифрування використовується асиметричний алгоритм, що не має проблем із секретністю. Проблеми малої швидкості асиметричного шифрування у разі практично виникає, оскільки асиметричним алгоритмом шифрується лише короткий ключ Ksimm, проте дані шифруються швидким симетричним алгоритмом. Результат - швидке шифрування разом із зручним обміном ключами.
Ключові схеми
Маніпуляції із зашифруванням ключа Ksimm та його передачею разом із повідомленням є прикладом ключової схеми (так називаються схеми використання ключів шифрування). У випадку для розробки будь-якої системи, що дозволяє шифрувати файли чи повідомлення, недостатньо просто реалізувати алгоритм шифрування. Необхідно також продумати принципи генерації, передачі, зберігання та використання ключів шифрування: оскільки недостатній захист ключів на будь-якому з цих етапів або неправильне застосування їх поставить під загрозу всю зашифровану інформацію. Адже будь-яка "слабкість" етапів шифрування дасть можливість зловмисникові атакувати систему захисту для того, щоб отримати ключ шифрування замість того, щоб намагатися зламати сильний криптоалгоритм. І якщо він зробить це досить грамотно – таємниць від нього вже не буде.
Розглянемо типові ключові схеми, але спочатку введемо ряд визначень (див. врізання "Типи шифрування").
Абонентське шифрування
Подана на рис. 1 схема – простий приклад абонентського шифрування. Ясно, що це не єдина можлива ключова схема - варіантів таких схем безліч, конкретний вибирається, виходячи з вимог функціональності і безпеки конкретної системи захисту. Загалом існує два види ключових елементів: файлові та довготривалі.
Файлові ключі призначені для шифрування інформації. Часто їх назва відповідає конкретному виду даних, що шифруються: пакетні, сеансові або дискові. Зазвичай такі ключі генеруються випадковим чином для кожного об'єкта, що шифрується, наприклад, для кожного файлу, повідомлення електронної пошти, а іноді і IP-пакета. У нашому прикладі з користувачами I та J ключ Ksimm – це файловий ключ.
Довготривалі ключі використовуються для шифрування та передачі файлових. У схемі на рис. 1 ключ KpI – довготривалий.
Звичайно, це не означає, що для шифрування будь-якого об'єкта використовується рівно два ключі: файловий плюс довготривалий. Нижче ми розглянемо приклад ключової схеми, у якій шифрування файлового ключа використовується суперпозиція двох довгострокових ключів різного призначення. Крім того, між файловим та довготривалим ключами можуть розташовуватися проміжні, також одержувані за допомогою датчика випадкових чисел (наприклад, файловий ключ шифрується на проміжному, який, у свою чергу, шифрується на довготривалому).
Незалежно від кількості ключів, що використовуються для шифрування конкретного об'єкта, існує якийсь особливий довготривалий ключ, на якому побудовано весь захист. Якщо такий ключ потрапить до рук зловмисника, захищений об'єкт буде ним розшифрований незалежно від кількості інших ключів, що використовуються при шифруванні. Саме цей ключ необхідно зберігати, не допускаючи його компрометації (тобто втрати чи розкрадання).
Зазвичай для зберігання подібних ключів використовується персональний ключовий носій: дискета, смарт-карта, USB-токен, iButton і т. д., який завжди повинен знаходитися у користувача - власника ключа. На схемі із рис. 1 такий ключовий елемент у явному вигляді відсутній - це секретний ключ користувача I, KsI, який повинен знаходитися тільки у користувача I. В іншому випадку зловмисник, який заволодів ключем KsI, легко розшифрує повідомлення (спочатку за допомогою ключа KsI розшифровується ключ Ksimm, а потім - та саме повідомлення).
Архівне шифрування
Схема архівного шифрування (рис. 2) дуже схожа на описану вище схему абонентського шифрування. Основна відмінність між ними тільки в тому, що при шифруванні файлів "для себе" (тобто для зберігання у зашифрованому вигляді на своєму комп'ютері) не виникає проблем із розподілом ключів шифрування. Це означає, що асиметричне шифрування в цьому випадку просто не потрібне, тому файловий ключ шифрується на довготривалому за допомогою симетричного алгоритму.
 |
Мал. 2. Архівне шифрування. |
Може здатися, що в даному випадку немає логіки у використанні файлового ключа: чому б не шифрувати файл безпосередньо на довготривалому ключі, не витрачаючи час та ресурси на генерацію, шифрування та передачу файлового? Однак використання файлового ключа (крім описаного вище комбінування симетричних та асиметричних алгоритмів) має інші цілі.
По-перше, зменшується статистична навантаження на довготривалий ключ (тобто довготривалим ключем шифруються тільки короткі файлові ключі, а файлові ключі щоразу різні) - це суттєво знижує ймовірність успіху тих атак на довготривалий ключ, які використовують великі обсяги зашифрованої на конкретному ключі інформації.
По-друге, при перешифруванні (плановому або компрометації ключа) зашифрованого об'єкта з одного довготривалого ключа в інший досить лише перешифрувати короткий файловий ключ, який у заголовку. Сам об'єкт може бути як завгодно великим - наприклад, весь логічний диск комп'ютера. Не варто лякатися складності схем архівного та абонентського шифрування – наведені на них операції виконуються програмами шифрування автоматично. Користувач лише вказує файл, що захищається, і задає додаткові параметри, наприклад, на якому ключі або для якого користувача потрібно його шифрувати.
Прозоре шифрування
При прозорому шифруванні від користувача зазвичай потрібно лише одноразове налаштування системи, після чого все, що необхідно, зашифровуватиметься автоматично.
В даний час існує багато програм шифрування логічних дисків. Більшість з них створюють віртуальний логічний диск, який фізично є файлом-контейнером, що розміщується на одному з існуючих в системі логічних дисків. Зазвичай користувачеві достатньо раз налаштувати програму прозорого шифрування. Для цього він повинен створити файл-контейнер, задати його розмір, створити довготривалий ключ шифрування логічного диска (або задати пароль, з якого формуватиметься довготривалий ключ) і т.д. з прозорим шифруванням: під час запису такий логічний диск файли автоматично зашифровуються, під час читання - розшифровуються.
Ключова схема такого шифрування дуже схожа на представлену на рис. 2. Різниця лише в тому, що файловий ключ створюється не для кожного файлу, що записується на логічний диск, а для всього логічного диска (звідси і назва - дисковий ключ), і кожна з операцій (отримання дискового ключа за допомогою датчика випадкових чисел, його зашифрування на довготривалому ключі та запис у заголовок віртуального логічного диска) виконується при створенні файлу-контейнера одноразово. Якщо користувач пред'являє правильний довгостроковий ключ, то файловий ключ, що зберігається в заголовку, розшифровується і бере участь у подальших операціях шифрування файлів даного логічного диска.
Триключова схема
Повернемося ненадовго до абонентського шифрування. Буває, що в цьому випадку застосовуються лише симетричні алгоритми без асиметричного шифрування (хоча через те, що вітчизняний стандарт на алгоритм асиметричного шифрування просто відсутній). При цьому передбачається, що ключі симетричного шифрування поширюються на початок використання такої системи по довіреним каналам зв'язку (наприклад, кур'єром).
Для цих ключів дуже часто використовується матриця розмірністю N x N (де N - кількість користувачів системи), у кожному осередку якої міститься ключ парного зв'язку - ключ для двох конкретних користувачів системи (номер кожного відповідає номерам рядка та стовпця осередку з їх ключем парного зв'язку) для передачі зашифрованих повідомлень лише між ними. Відповідно до будь-якого іншого користувача системи, не кажучи вже про зовнішніх користувачів або зловмисників, зашифрована таким чином інформація буде недоступна.
Така матриця ключів генерується виділеним адміністратором безпеки, а не самими користувачами, причому останні отримують лише рядки матриці з набором ключів парного зв'язку між конкретним користувачем та іншими користувачами системи. Такий рядок називається мережним набором.
Розглянемо приклад використання мережного набору (рис. 3). У принципі його можна повністю зберігати на персональному ключовому носії, використовуючи той чи інший ключ парного зв'язку в міру потреби. Однак при великій кількості користувачів пам'яті ключового носія може просто не вистачити. Тому мережні набори зазвичай зберігають безпосередньо на жорсткому диску комп'ютера, попередньо зашифрувавши їх ще на одному ключі (такий ключ часто називається головним).
Як видно, довгостроковий ключовий елемент, на якому шифрується файловий, в даній схемі в явному вигляді відсутній - це результат розшифрування на головному ключі ключа парного зв'язку, записаний на жорсткому диску. У цьому випадку на персональному ключовому носії можна зберігати тільки головний ключ, оскільки він забезпечує секретність інших елементів ключової схеми.
Формат зашифрованого об'єкта
Залишилося сказати кілька слів про заголовок зашифрованого об'єкта. Очевидно, що необхідний елемент, який контролює правильність розшифрування об'єкта. Інакше при будь-якій помилці розшифрування (наприклад, при розбіжності параметрів алгоритму, використанні невірного довготривалого ключа тощо) неможливо буде зрозуміти, чи правильно розшифровані дані (звичайно, це не стосується банального обміну зашифрованими текстовими повідомленнями, де коректність розшифрування можна перевірити візуально). Такий елемент розміщується в заголовку об'єкта, і зазвичай його роль виконує імітоприставка (або будь-яка інша контрольна сума) вихідних даних, що обчислюється на файловому ключі.
Імітоприставка обчислюється перед зашифруванням, записується в заголовок, а після розшифрування її значення обчислюється повторно і порівнюється із заголовком, що зберігається. Крім того, щоб не розшифровувати весь об'єкт, у його заголовку зберігається й інша імітоприставка - файлового ключа, яка обчислюється на довготривалому ключі перед зашифруванням файлового та перевіряється після його розшифрування, але (!) до розшифрування всього об'єкта. За допомогою цієї другої імітоприставки можна легко діагностувати більшість помилок розшифрування на ранній стадії.
Отже, зашифрований об'єкт зазвичай містить щонайменше такі дані:
- власне інформація, зашифрована на файловому ключі;
- файловий ключ, зашифрований на довготривалому ключі;
- імітоприставка файлового ключа на довготривалому ключі;
- імітоприставка вихідних даних на файловому ключі.
***
Описані у цій статті ключові схеми - не можливі. Залежно від цілей конкретної системи захисту інформації ключові схеми може бути як значно складнішими, і дуже простими. Головне - ключова схема не повинна бути "слабкою ланкою" усієї системи.
Відкритий ключ – набір параметрів криптографічної системи асиметричного типу, який необхідний та достатній для виконання певних перетворень. Це один із ключів пари, відомий іншим учасникам і що відрізняється відкритим доступом.
Види ключів у криптографічній мережі
Ключі в криптографічній мережі поділяються на кілька видів з урахуванням алгоритмів, на базі яких вони використовуються:
- Симетричні (секретні) ключі застосовуються в алгоритмах симетричного типу, наприклад, у створенні кодів автентичності. Головною якістю таких ключів є той факт, що для шифрування або розшифрування, а також для виконання інших перетворень потрібно застосовувати ідентичні ключі. Можлива ситуація, коли ключ, призначений для зворотного шифрування, обчислюється ключем для прямого шифрування. Як результат, забезпечується конфіденційність інформації, але виникають проблеми з поширенням буквено-цифрових кодів у системах із великою кількістю учасників.
- Асиметричні - другий тип ключів, що застосовується в алгоритмах несиметричного типу. Такі ключі працюють у парі і є:
- Закритий (приватний) – ключ, який відомий лише господареві. Завдання власника полягає у збереженні коду потай від сторонніх, що унеможливлює ризик підробки та крадіжки інформації.
- Відкритий (публічний) — ключ, який може бути виставлений на огляд без побоювання бути скопійованим. Його особливість - перевірка справжності інформації та попередження шахрайських схем. Відкритий ключ є якоюсь функцією від закритого коду. З іншого боку, наявність на руках відкритого ключа не дозволяє визначити пару.
Як працюють ключі у криптографії
Ключ у криптографії - секретна інформація, що застосовується для декодування та шифрування повідомлень, постановки ЕЦП, перевірки операцій у криптовалютній мережі, розрахунку кодів автентичності та іншого. Рівень надійності ключа визначається його довжиною (одиниця виміру – біти). Застосовується такі типи ключів — на 128 і 256 біт (для SSL), а центрів сертифікації і криптовалютных мереж від 4096 біт і більше.
Асиметрична система шифрування є криптографічною мережею з відкритим ключем. Принцип дії має такий вигляд:
- Приватний (закритий) ключ генерується системою. Він є випадковим і є послідовністю цифр і букв. До нього за спеціальним алгоритмом підбирається пара - публічний чи відкритий ключ. Варто врахувати, що до одного закритого підходить лише певний варіант відкритого ключа. Згадані набори символів (публічний та приватний) діють лише у зв'язці один з одним.
- Відкритий ключ, отриманий шляхом генерації системи, направляється за допомогою відкритих каналів до адресата.
- Після отримання публічного (відкритого) ключа відправник з його допомогою здійснює шифрування інформації, після чого повертає її одержувачу. Останній здатний розшифрувати дані завдяки наявності приватного (закритого) ключа.
- За допомогою спеціального коду проводиться розшифровка інформації із застосуванням публічного та приватних ключів. У першому випадку йдеться про відкрити набор символів, за допомогою яких було зашифровано повідомлення.
Слід зазначити, що публічний (public) ключ використовується тільки для шифрування інформації. Використовувати його для розшифровки не вийде. У ролі дешифратора виступає приватний (private) ключ. Саме так працює механізм з урахуванням асиметричного шифрування.
У криптовалютній мережі (наприклад, Біткоїн) принцип роботи аналогічний - спочатку створюється закритий (private) ключ, після чого система його шифрує і перетворює на ключ відкритого типу. Щоб підтвердити будь-яку операцію, необхідно застосовувати закритий ключ, без якого не вийде дешифрувати відкритий.
Сфера застосування асиметричної криптографії
Асиметрична криптографія, а саме пара ключів (відкритий та закритий) активно застосовуються у різних сферах діяльності. Вони використовуються для шифрування послань у дипломатичному секторі. Крім того, шифрування застосовується різними меседжерами, роутерами та інтернет-ресурсами, що підтримують протокол HTTPS. Асиметрична криптографія використовується при формуванні електронного цифрового підпису, банківських системах, а також в алгоритмі блокчейна. Останній є базою побудови чинних сьогодні криптовалют, насамперед Біткоіна, Ефіріуму та інших.
Будьте в курсі всіх важливих подій United Traders - підписуйтесь на наш
З погляду інформаційної безпеки, криптографічні ключі є критично важливими даними. Якщо раніше, щоб обікрасти компанію, зловмисникам доводилося проникати на її територію, розкривати приміщення та сейфи, то тепер достатньо викрасти токен із криптографічним ключем та зробити переказ через систему Інтернет Клієнт-Банк. Фундаментом безпеки за допомогою систем криптографічного захисту інформації (СКЗІ) є підтримка конфіденційності криптографічних ключів.
А як забезпечити конфіденційність того, про існування чого ви не здогадуєтеся? Щоб прибрати токен із ключем у сейф, треба знати про існування токена та сейфа. Як це не парадоксально звучить, дуже мало компаній мають уявлення про точну кількість ключових документів, якими вони користуються. Це може відбуватися з низки причин, наприклад, недооцінка загроз інформаційної безпеки, відсутність налагоджених бізнес-процесів, недостатня кваліфікація персоналу у питаннях безпеки тощо. Згадують про це завдання зазвичай вже після інцидентів, таких як цей.
У цій статті буде описано перший крок на шляху вдосконалення захисту інформації за допомогою криптозасобів, а якщо точніше, то розглянемо один із підходів до проведення аудиту СКЗІ та криптоключів. Оповідання вестиметься від імені фахівця з інформаційної безпеки, при цьому вважатимемо, що роботи проводяться з нуля.
терміни та визначення
На початку статті, щоб не лякати непідготовленого читача складними визначеннями, ми широко використовували терміни криптографічний ключ або криптоключ, тепер настав час удосконалити наш понятійний апарат і привести його у відповідність до чинного законодавства. Це дуже важливий крок, оскільки він дозволить ефективно структурувати інформацію, отриману за результатами аудиту.
- Криптографічний ключ (криптоключ)- сукупність даних, що забезпечує вибір одного конкретного криптографічного перетворення з усіх можливих у цій криптографічної системі (визначення з «рожевої інструкції – Наказу ФАПСІ № 152 від 13 червня 2001 р., далі за текстом – ФАПСИ 152).
- Ключова інформація- Спеціальним чином організована сукупність криптоключів, призначена для здійснення криптографічного захисту інформації протягом певного терміну [ФАПСІ 152].
Зрозуміти принципову відмінність між криптоключем та ключовою інформацією можна на наступному прикладі. При організації HTTPS, генеруються ключова пара відкритий та закритий ключ, а з відкритого ключа та додаткової інформації виходить сертифікат. Так ось, у цій схемі сукупність сертифіката та закритого ключа утворюють ключову інформацію, а кожен з них окремо є криптокоключем. Тут можна керуватися наступним простим правилом – кінцеві користувачі під час роботи з СКЗІ використовують ключову інформацію, а криптоключі зазвичай використовують СКЗІ у собі. У той же час важливо розуміти, що ключова інформація може складатися з одного кріптоключа. - Ключові документи- електронні документи на будь-яких носіях інформації, а також документи на паперових носіях, які містять ключову інформацію обмеженого доступу для криптографічного перетворення інформації з використанням алгоритмів криптографічного перетворення інформації (криптографічний ключ) у шифрувальних (криптографічних) засобах. (ухвала з Постанови Уряду № 313 від 16 квітня 2012 р., далі за текстом – ПП-313)
Простою мовою ключовий документ - це ключова інформація, записана на носії. При аналізі ключової інформації та ключових документів слід виділити, що експлуатується (тобто використовується для криптографічних перетворень – шифрування, електронний підпис тощо) ключова інформація, а передаються працівникам ключові документи, що її містять. - Засоби криптографічного захисту інформації (СКЗД)– засоби шифрування, засоби імітозахисту, засоби електронного підпису, засоби кодування, засоби виготовлення ключових документів, ключові документи, апаратні шифрувальні (криптографічні) засоби, програмно-апаратні шифрувальні (криптографічні) засоби. [ПП-313]
При аналізі даного визначення можна знайти у ньому наявність терміна ключові документи. Термін дано у Постанові Уряду та змінювати її ми не маємо права. У той же час подальший опис вестиметься з розрахунку, що до СКЗІ будуть належати тільки засоби здійснення криптографічних перетворень). Даний підхід дозволить спростити проведення аудиту, але в той же час не позначатиметься на його якості, оскільки ключові документи ми все одно врахуємо, але у своєму розділі і своїми методами.
Методика аудиту та очікувані результати
Основними особливостями запропонованої в даній статті методики аудиту є постулати про те, що:
- жоден працівник компанії не може точно відповісти на запитання, які ставлять під час аудиту;
- існуючі джерела даних (переліки, реєстри та ін.) не точні або слабо структуровані.
Наведемо основні залежності, які нам у цьому допоможуть:
- Якщо є СКЗІ, то є і ключова інформація.
- Якщо є електронний документообіг (у тому числі з контрагентами та регуляторами), то швидше за все в ньому застосовується електронний підпис і як наслідок СКЗІ та ключова інформація.
- Електронний документообіг у цьому контексті слід розуміти широко, тобто до нього ставляться, як безпосередній обмін юридично значимими електронними документами, і здача звітності, і у платіжних чи торгових системах тощо. Перелік та форми електронного документообігу визначаються бізнес-процесами компанії, а також чинним законодавством.
- Якщо працівник задіяний в електронному документообігу, то, швидше за все, у нього є ключові документи.
- Під час організації електронного документообігу з контрагентами зазвичай випускаються організаційно-розпорядчі документи (накази) призначення відповідальних осіб.
- Якщо інформація передається через Інтернет (або інші громадські мережі), то швидше за все вона шифрується. Насамперед це стосується VPN та різних систем віддаленого доступу.
- Якщо в мережевому трафіку виявлено протоколи, що передають трафік у зашифрованому вигляді, то застосовуються СКЗІ та ключова інформація.
- Якщо здійснювалися розрахунки з контрагентами, що займаються: постачанням засобів захисту інформації, телекомунікаційних пристроїв, наданням послуг з передачі набряклості, послуг центрів, що засвідчують, то при даній взаємодії могли купуватися СКЗІ або ключові документи.
- Ключові документи можуть бути як на носіях, що відчужуються (дискетах, флешках, токенах, …), так і записані всередину комп'ютерів і апаратних СКЗІ.
- При використанні засобів віртуалізації ключові документи можуть зберігатися як усередині віртуальних машин, так і монтуватися до віртуальних машин за допомогою гіпервізора.
- Апаратні СКЗІ можуть встановлюватися в серверних і недоступні для аналізу по мережі.
- Деякі системи електронного документообігу можуть перебувати у неактивному чи малоактивному вигляді, але водночас містити активну ключову інформацію та СКЗІ.
- Внутрішня нормативна та організаційно-розпорядча документація може містити відомості про системи електронного документообігу, СКЗІ та ключові документи.
- опитувати працівників;
- проводити аналіз документації компанії, включаючи внутрішні нормативні та розпорядчі документи, а також вихідні платіжні доручення;
- проводити візуальний аналіз серверних кімнат та комунікаційних шаф;
- проводити технічний аналіз вмісту автоматизованих робочих місць (АРМ), серверів та засобів віртуалізації.
Перелік СКЗІ:
- Модель СКЗІ. Наприклад, СКЗІ Кріпто CSP 3.9, або OpenSSL 1.0.1
- Ідентифікатор екземпляра СКЗІ. Наприклад, серійний, ліцензійний (або реєстраційний ПКЗ-2005) номер СКЗІ
- Відомості про сертифікат ФСБ Росії на СКЗІ, включаючи номер та дати початку та закінчення термінів дії.
- Відомості про місце експлуатації СКЗІ. Наприклад, ім'я комп'ютера на яке встановлено програмне СКЗІ, або найменування технічних засобів або приміщення, де встановлені апаратні СКЗІ.
- Керувати вразливістю в СКЗІ, тобто швидко їх виявляти та виправляти.
- Відстежувати терміни дії сертифікатів на СКЗІ, а також перевіряти, чи використовується сертифіковане СКЗІ відповідно до правил, встановлених документацією чи ні.
- Планувати витрати на СКЗІ, знаючи скільки вже перебуває в експлуатації та скільки ще є зведених коштів.
- Формувати регламентну звітність.
По кожному елементу переліку фіксуємо такі дані:
- Найменування або ідентифікатор ключової інформації. Наприклад, «Ключ кваліфікованої ЕП. Серійний номер сертифіката 31:2D:AF», ідентифікатор слід підбирати таким чином, щоб по ньому можна було знайти ключ. Наприклад, центри, що засвідчують, коли посилають повідомлення, зазвичай ідентифікують ключі за номерами сертифікатів.
- Центр управління ключовою системою (ЦУКС), що випустив цю ключову інформацію. Це може бути організація, що випустила ключ, наприклад, що засвідчує центр.
- Фізична особа, на ім'я якого випущено ключову інформацію. Цю інформацію можна отримати з полів сертифікатів CN X.509
- Формат ключової інформації. Наприклад, СКЗІ КриптоПРО, СКЗІ Верба-OW, X.509 і т.д (або іншими словами для використання з якими СКЗІ призначена дана ключова інформація).
- Призначення ключової інформації. Наприклад, «Участь у торгах на майданчику Ощадбанк АСТ», «Кваліфікований електронний підпис для подання звітності» тощо. З точки зору техніки, в даному полі можна фіксувати зафіксовані органічні полях extended key usage та ін сертифікатів X.509.
- Початок та закінчення термінів дії ключової інформації.
- Порядок перевипуску ключової інформації. Тобто знання про те, що потрібно робити і як при перевипуску ключової інформації. Принаймні бажано фіксувати контакти посадових осіб ЦУКЗ, які випустили ключову інформацію.
- Перелік інформаційних систем, сервісів чи бізнес-процесів у межах яких використовується ключова інформація. Наприклад, "Система дистанційного банківського обслуговування Інтернет Клієнт-Банк".
- Відстежувати термін дії ключової інформації.
- У разі потреби швидко перевипускати ключову інформацію. Це може знадобитися як при плановому, так і позаплановому перевипуску.
- Блокувати використання ключової інформації, при звільненні працівника, на яку вона випущена.
- Розслідувати інциденти інформаційної безпеки, відповідаючи на запитання: «Хто мав ключі для здійснення платежів?» та ін.
По кожному елементу переліку фіксуємо такі дані:
- Ключова інформація, що міститься у ключовому документі.
- Носій ключової інформації, на який записано ключову інформацію.
- Обличчя, відповідальна за збереження ключового документа і конфіденційність ключової інформації, що міститься в ньому.
- Перевипускати ключову інформацію у випадках: звільнення працівників, які мають ключові документи, а також при компрометації носіїв.
- Забезпечувати конфіденційність ключової інформації шляхом інвентаризації носіїв, що її містять.
План аудиту
Настав час розглянути практично особливості проведення аудиту. Зробимо це з прикладу кредитно-фінансової організації чи іншими словами з прикладу банку. Цей приклад обрано не випадково. Банки використовують досить велику кількість різношерстих систем криптографічного захисту, які задіяні в гігантській кількості бізнес-процесів, та й до того ж практично всі банки є Ліцензіатами ФСБ Росії з криптографії. Далі у статті буде представлений план аудиту СКЗІ та криптоключів стосовно Банку. У той же час цей план може бути взятий за основу під час проведення аудиту практично будь-якої компанії. Для зручності сприйняття план розбитий на етапи, які в свою чергу згорнуті в сполєри.
Етап 1. Збір даних із інфраструктурних підрозділів компанії
| № | Дія | |
| Джерело – всі працівники компанії | ||
| 1 | Робимо розсилку по корпоративній пошті всім працівниками компанії з проханням повідомити в службу інформаційної безпеки про всі криптографічні ключі, які вони використовують. | Отримуємо електронні листи, на базі яких формуємо перелік ключової інформації та перелік ключових документів |
| Джерело – Керівник Служби інформаційних технологій | ||
| 1 | Запитуємо перелік ключової інформації та ключових документів | З деякою ймовірністю Служба ІТ веде подібні документи, використовуватимемо їх для формування та уточнення переліків ключової інформації, ключових документів та СКЗІ |
| 2 | Запитуємо список СКЗІ | |
| 3 | Запитуємо реєстр ПЗ, встановленого на серверах та робочих станціях | У цьому реєстрі шукаємо програмні СКЗІ та їх компоненти. Наприклад, КриптоПРО CSP, Верба-OW, Signal-COM CSP, Сигнатура, PGP, ruToken, eToken, КритоАРМ та ін На основі цих даних формуємо перелік СКЗІ. |
| 4 | Запитуємо перелік працівників (ймовірно технічна підтримка), які допомагають користувачам з використання СКЗІ та перевипуску ключової інформації. | Запитуємо у цих осіб аналогічну інформацію, що й у системних адміністраторів |
| Джерело – системні адміністратори Служби інформаційних технологій | ||
| 1 | Запитуємо перелік вітчизняних криптошлюзів (VIPNET, Континент, S-terra та ін.) | У випадках, коли в компанії не реалізовані регулярні бізнес-процеси управління ІТ та ІБ, подібні питання можуть допомогти згадати системним адміністраторам про існування того чи іншого пристрою чи ПЗ. Використовуємо цю інформацію для отримання переліку СКЗД. |
| 2 | Запитуємо перелік вітчизняних програмних СКЗІ (СКЗІ МагПро КриптоПакет, VIPNET CSP, CryptonDisk, SecretDisk, …) | |
| 3 | Просимо перелік маршрутизаторів, що реалізують VPN для: а) зв'язки офісів компанії; б) взаємодії з контрагентами та партнерами. |
|
| 4 | Запитуємо перелік інформаційних сервісів, опублікованих в Інтернеті (доступних з Інтернету). Вони можуть включати: а) корпоративну електронну пошту; б) системи обміну миттєвими повідомленнями; в) корпоративні веб-сайти; г) послуги для обміну інформацією з партнерами та контрагентами (extranet); д) системи дистанційного банківського обслуговування (якщо компанія – Банк); е) системи віддаленого доступу до мережі компанії. Для перевірки повноти наданих відомостей звіряємо їх із переліком правил Portforwarding прикордонних міжмережевих екранів. |
Аналізуючи отриману інформацію з високою ймовірністю можна зустріти використання СКЗІ та криптоключів. Використовуємо отримані дані для формування переліку СКЗІ та ключової інформації. |
| 5 | Запитуємо перелік інформаційних систем, що використовуються для подання звітності (Такська, Контур і т. д.) | У цих системах використовуються ключі кваліфікованого електронного підпису та СКЗД. Через цей перелік формуємо перелік СКЗІ, перелік ключової інформації, а також дізнаємось працівників, які користуються цими системами для формування переліку ключових документів. |
| 6 | Запитуємо перелік систем внутрішнього електронного документообігу (Lotus, DIRECTUM, 1С: Документообіг та ін.), а також їх користувачів. | У рамках внутрішніх систем електронного документообігу можуть зустрітись ключі електронного підпису. З отриманої інформації формуємо перелік ключової інформації та перелік ключових документів. |
| 7 | Запитуємо перелік внутрішніх центрів, що засвідчують. | Кошти, що використовуються для організації центрів, що засвідчують, фіксуємо в переліку СКЗІ. Надалі аналізуватимемо вміст баз даних центрів, що засвідчують, для виявлення ключової інформації. |
| 8 | Запитуємо інформацію про використання технологій: IEEE 802.1x, WiFiWPA2 Enterprise та систем IP-відеоспостереження | У разі використання цих технологій ми можемо виявити у задіяних пристроях ключові документи. |
| Джерело – Керівник кадрової служби | ||
| 1 | Просимо описати процес прийому та звільнення працівників. Фокусуємося на питанні про те, хто забирає у працівників, що звільняються, ключові документи | Аналізуємо документи (обхідні листи) щодо наявності у яких інформаційних систем у яких можна використовувати СКЗИ. |
Етап 2. Збір даних із бізнес-підрозділів компанії (на прикладі Банку)
| № | Дія | Очікуваний результат та його використання |
| Джерело – Керівник служби розрахунків (кореспондентських відносин) | ||
| 1 | Просимо надати схему організації взаємодії з платіжною системою Банку Росії. Зокрема, це буде актуально для Банків, які мають розвинену мережу філій, при якій філії можуть підключати до платіжної системи ЦП безпосередньо | На базі отриманих даних визначаємо місцезнаходження платіжних шлюзів (АРМ КБР, УТА) та перелік задіяних користувачів. Отриману інформацію використовуємо для формування переліку СКЗІ, ключової інформації та ключових документів. |
| 2 | Запитуємо перелік Банків, з якими встановлені прямі кореспондентські відносини, а також просимо розповісти, хто займається здійсненням переказів та які технічні засоби використовуються. | |
| 3 | Запитуємо перелік платіжних систем, у яких бере участь Банк (SWIFT, VISA, MasterCard, НСПК тощо), а також місцезнаходження терміналів для зв'язку | Аналогічно, як для платіжної системи Банку Росії |
| Джерело – Керівник підрозділу, який відповідає за надання дистанційних банківських послуг | ||
| 1 | Просимо перелік систем дистанційного банківського обслуговування. | У зазначених системах аналізуємо використання СКЗІ та ключової інформації. На підставі отриманих даних формуємо перелік СКЗІ та ключової інформації та ключових документів. |
| Джерело – Керівник підрозділу, який відповідає за функціонування процесингу платіжних карток | ||
| 1 | Запитуємо реєстр HSM | На базі отриманої інформації формуємо перелік СКЗІ, ключової інформації та ключових документів. |
| 2 | Запитуємо реєстр офіцерів безпеки | |
| 4 | Запитуємо інформацію про компоненти LMK HSM | |
| 5 | Запитуємо інформацію про організацію систем типу 3D-Secure та організацію персоналізації платіжних карток | |
| Джерело – Керівники підрозділів, які виконують функції казначейства та депозитарію | ||
| 1 | Перелік банків, з якими встановлені кореспондентські відносини та які беру участь у міжбанківському кредитуванні. | Використовуємо отриману інформацію для уточнення раніше отриманих даних від служби розрахунків, а також фіксуємо інформацію про взаємодію з біржами та депозитаріями. На базі отриманої інформації формуємо перелік СКЗІ та ключової інформації. |
| 2 | Перелік бірж та спеціалізованих депозитаріїв, з якими працює Банк | |
| Джерело – Керівники служб фінансового моніторингу та підрозділів відповідальних за подання звітності до Банку Росії | ||
| 1 | Запитуємо інформацію про те, як вони надсилають відомості та отримують відомості з ЦП. Перелік задіяних осіб та технічних засобів. | Інформаційна взаємодія з Банком Росії жорстко регламентована відповідними документами, наприклад, 2332-У, 321-І та багатьма іншими, перевіряємо відповідність цим документам та формуємо переліки СКЗІ, ключової інформації та ключових документів. |
| Джерело – Головний бухгалтер та працівники бухгалтерії, які займаються оплатою рахунків із внутрішньобанківських потреб | ||
| 1 | Запитуємо інформацію, про те, як відбувається підготовка та здавання звітності в податкові інспекції та Банк Росії | Уточнюємо раніше отримані відомості |
| 2 | Запитуємо реєстр платіжних документів для оплати внутрішньобанківських потреб | У даному реєстрі будемо шукати документи: 1) як адресати платежів зазначені посвідчувальні центри, спеціалізовані оператори зв'язку, виробники СКЗІ, постачальники телекомунікаційного обладнання. Найменування даних компаній можна отримати з Реєстру сертифікованих СКЗІ ФСБ Росії, переліку акредитованих центрів, що засвідчують Мінкомзв'язку та інших джерел. 2) як розшифрування платежу присутні слова: «СКЗІ», «підпис», «токен», «ключовий», «БКІ» тощо. |
| Джерело – Керівники служб по роботі з простроченою заборгованістю та управління ризиками | ||
| 1 | Запитуємо перелік бюро кредитних історій та колекторських агенцій, з якими працює Банк. | Спільно зі службою ІТ аналізуємо отримані дані з метою з'ясування організації електронного документообігу, з урахуванням чого уточнюємо переліки СКЗІ, ключової інформації та ключових документів. |
| Джерело – Керівники служб документообігу, внутрішнього контролю та внутрішнього аудиту | ||
| 1 | Запитуємо реєстр внутрішніх організаційно-розпорядчих документів (наказів). | У цих документах шукаємо документи, які стосуються СКЗІ. Для цього аналізуємо наявність ключових слів "безпека", "відповідальна особа", "адміністратор", "електронний підпис", "ЕП", "ЕЦП", "ЕДО", "АСП", "СКЗІ" та їх похідних. Після чого виявляємо перелік працівників Банку, зафіксованих у цих документах. Проводимо з працівниками інтерв'ю щодо використання ними криптосредств. Отриману інформацію відображаємо у переліках СКЗІ, ключової інформації та ключових документів. |
| 2 | Запитуємо переліки договорів із контрагентами | Намагаємося виявити договори про електронний документообіг, а також договори з компаніями, які займаються поставним засобом захисту інформації або надають послуги в цій галузі, а також компаніями, що надають послуги центрів, що посвідчують, та послуги здачі звітності через Інтернет. |
| 3 | Аналізуємо технологію зберігання документів дня в електронному вигляді | При реалізації зберігання документів дня в електронному вигляді обов'язково застосовуються СКЗІ |
Етап 3. Технічний аудит
| № | Дія | Очікуваний результат та його використання |
| 1 | Проводимо технічну інвентаризацію програмного забезпечення встановленого на комп'ютерах. Для цього використовуємо: · Аналітичні можливості корпоративних систем антивірусного захисту (наприклад, Антивірус Касперського вміє будувати подібний реєстр). · Скрипти WMI для опитування комп'ютерів під керуванням Windows; · Можливості пакетних менеджерів для опитування * nix систем; · Спеціалізоване ПЗ для інвентаризації. |
Серед встановленого програмного забезпечення шукаємо програмні СКЗІ, драйвера для апаратних СКЗІ та ключових носіїв. На базі отриманої інформації оновлюємо список СКЗІ. |
| 2 | Здійснюємо пошук ключових документів на серверах та робочих станціях. Для цього · Logon-скриптами опитуємо АРМ в домені щодо наявності сертифікатів із закритими ключами в профілях користувачів і профілях комп'ютера. · На всіх комп'ютерах, файлових серверах, гіпервізорах шукаємо файли з розширеннями: crt, cer, key, pfx, p12, pem, pse, jks та ін. · На гіпервізорах систем віртуалізації шукаємо примонтовані дисководи та образи дискет. |
Найчастіше ключові документи представлені у вигляді файлових ключових контейнерів, а також контейнерами, що зберігаються в реєстрах комп'ютерів, які працюють під керуванням Windows. Знайдені ключові документи фіксуємо в переліку ключових документів, а ключову інформацію, що міститься в них, у переліку ключової інформації. |
| 3 | Аналізуємо зміст баз даних центрів, що засвідчують | Бази даних центрів, що засвідчують, зазвичай містять у собі дані про випущені цим центрами сертифікатів. Отриману інформацію заносимо до переліку ключової інформації та переліку ключових документів. |
| 4 | Проводимо візуальний огляд серверних кімнат та комутаційних шаф, шукаємо СКЗІ та апаратні ключові носії (токени, дисководи) | У деяких випадках неможливо провести інвентаризацію СКЗІ та ключових документів через мережу. Системи можуть перебувати в ізольованих мережевих сегментах або взагалі не мати мережевих підключень. Для цього проводимо візуальний огляд, у результатах якого мають бути встановлені назви та призначення всього обладнання, представленого в серверних. Отриману інформацію заносимо до переліку СКЗІ та ключових документів. |
| 5 | Проводимо аналіз мережевого трафіку з метою виявлення інформаційних потоків, які використовують шифрований обмін | Шифровані протоколи – HTTPS, SSH та ін. дозволять нам ідентифікувати мережеві вузли, на яких виконуються криптографічні перетворення, і як наслідок містять СКЗІ та ключові документи. |
Висновок
У цій статті ми розглянули теорію та практику проведення аудиту СКЗІ та криптоключів. Як ви переконалися, ця процедура досить складна і трудомістка, але якщо до неї грамотно підходити цілком здійсненна. Будемо сподіватися, дана стаття вам допоможе в реальному житті. Дякую за увагу, чекаємо на ваші коментаріТеги: Додати теги
