Развёртывание центра сертификации. Курсовая_Киселев_Финал_1А8. Курсовой проект по дисциплине Комплексные системы защиты информации в сетях и системах связи студенту гр. 1А8 Радиотехнического факультета
 Скачать 1.39 Mb.
|
|
Министерство науки и высшего образования Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОННИКИ (ТУСУР) Кафедра радиоэлектроники и систем связи (РСС) Развёртывание и использование корпоративного центра сертификации в инфраструктуре Пояснительная записка к курсовому проекту по дисциплине «Комплексные системы защиты информации в сетях и системах связи» Выполнил: студент гр. 1А8 ____________Киселев Е.С. «___» __________ 2022 г. Проверил: Доцент кафедры РСС,к.т.н. __________Кураленко А.И. «___» __________ 2022 г. Томск 2022 2 Министерство науки и высшего образования Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР) Кафедра радиоэлектроники и систем связи (РСС) «УТВЕРЖДАЮ» Зав. кафедрой РСС, к.т.н., доцент ______________ А. В. Фатеев «____»___________2022 г. одпись) ТЕХНИЧЕСКОЕ ЗАДАНИЕ на курсовой проект по дисциплине «Комплексные системы защиты информации в сетях и системах связи» студенту гр.1А8 Радиотехнического факультета Киселеву Евгению Сергеевичу 1. Тема проекта: Развёртывание и использование корпоративного центра сертификации в инфраструктуре 2. Цель проекта: Развёртывание и настройка инфраструктуры открытого ключа с корпоративным центром сертификации 3. Срок сдачи проекта: «___» __________ 2022 г. 4. Исходные данные для проекта: 4.1 Правовые акты по цифровым правонарушениям; 4.2 Документация по программным решениям и утилитам от вендоров. 5. Технические требования Операционные системы: Настройка будет рассматриваться на базе Ubuntu; Программное обеспечение: Ставить дистрибутив ОС Linux будем на виртуальную машину (Virtual Box). 6. Вопросы, подлежащие разработке: 6.1 Изучить правовые акты по цифровым правонарушениям в РФ; 6.2 Изучить документацию программных решений; 6.3 Описать основные теоретические аспекты реализации предлагаемого решения; 6.4 Инсталлировать программы и утилиты на виртуальную машину; 6.5 Анализ полученных результатов расследования; 6.6 Подготовка отчетных материалов по итогам (выводы, итоги, результаты) 3 7. По окончанию работы предъявляется пояснительная записка, соответствующая требованиям ГОСТ 7.32-2001 «Отчет о научно-исследовательской работе» и стандарта ТУСУР на оформление текстовых документов. Руководитель курсового проекта Доцент каф. РСС _____________Кураленко И.А. Задание принято к исполнению: «___» __________ 2022 г. Студент гр. 1А8 _____________ Киселев Е.С. 4 Реферат Курсовой проект 23 стр., 23 рис., 3 источников, 1 приложения. PUBLIC KEY INFRASTRUCTURE, PKI, CERTIFICATE AUTHORITY, CA, ИНФРАСТРУКТУРА ОТКРЫТОГО КЛЮЧА, ЦЕНТР СЕРТИФИКАЦИИ. Цель курсового проекта: развёртывание и настройка инфраструктуры открытого ключа с корпоративным центром сертификации. В результате будет построена тестовая корпоративная сеть с сертифицированным ключом. Настройка сети проводилась в программной среде PUTTY, а также с помощью облачного сервера. Оформление пояснительной записки производилось в текстовом редакторе Microsoft Word 2019. 5 Содержание 1. Введение ..................................................................................................................................... 6 2. Краткая теория ........................................................................................................................... 7 3. Практическая часть ................................................................................................................... 8 3.1 Создание облачного сервера ............................................................................................... 8 3.2 Настройка корневого центра сертификации ................................................................... 11 4. Работа с сертификатами .......................................................................................................... 16 4.1 Выдача сертификатов ........................................................................................................ 16 4.2 Отзыв сертификата ............................................................................................................ 20 5. Заключение ............................................................................................................................... 21 Список литературы ...................................................................................................................... 22 Приложение А .............................................................................................................................. 23 6 1. Введение Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет. Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет. Как следствие, новые условия диктуют новые требования к защите данных. Крупные производители ПО активно продвигают идеологию «безопасного интернета», требуя поддержки цифровых сертификатов, начиная от серверов с конфиденциальными данными, облачных служб, вплоть до кухонного чайника или бельевого утюга. Некоторые компании делают это весьма настойчиво. Так, начиная с 2017 года, компания Google считает все сайты без поддержки HTTPS небезопасными: Moving towards a more secure web. И это весьма ощутимо влияет на интернет-индустрию. Во-первых, предупреждение в браузере (Google Chrome) явно не будет радовать ваших потенциальных клиентов и просто посетителей. Во-вторых, сайты без поддержки HTTPS опускаются в поисковой выдаче. Mozilla и другие крупные вендоры также не отстают от Google: Deprecating Non-Secure HTTP. С одной стороны, компании давят на интернет- индустрию, толкая организации на дополнительные расходы, связанные с цифровыми сертификатами. С другой стороны, это — вынужденный шаг, и всем нужно идти в ногу со временем. Однако текущее положение Internet PKI не позволяет решать эти вопросы достаточно гибко и удобно, требуя существенных затрат. Например, один сертификат SSL для публичного веб-сервера вам обойдётся в сумму порядка $100, а если хотите сертификат с зелёной полосой, это вам будет стоить ещё дороже. И это только за один сертификат! При этом автоматизация процессов находится в самом зачаточном состоянии. Для решения этих проблем крупнейшие вендоры ПО объединились и совместными усилиями наводят порядок с цифровыми сертификатами в Internet PKI. Во-первых, создан единый стандартизирующий орган — CAB Forum (CA/Browser Forum), который определяет стандартные практики для коммерческих CA, производителей веб-ПО и потребителей сертификатов. Во-вторых, активное продвижение некоммерческого CA (но глобально доверенного) Let’s Encrypt для обеспечения бесплатными сертификатами с возможностью автоматического продления. Казалось бы, это решает все проблемы безопасной коммуникации, и частные PKI (разворачиваемые в пределах организации) стали сразу ненужными. В какой-то, да, если частный PKI занимался обслуживанием внешних серверов (веб, VPN и т.д.). Но сервисы наподобие Let’s Encrypt в настоящее время покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей. Часть задач, как аутентификация клиентов не покрывается совсем. Ещё одним ограничением является то, что для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных PKI остаётся на очень высоком уровне. 7 2. Краткая теория Прежде чем приступать к настройке стоит разобраться в нескольких основополагающих вопросах. Что такое сертификат? Сертификат – это набор полей в формате x.509, содержащий идентификатор субъекта (например, имя пользователя или компьютера), время действия, имя издателя, назначение, используемые алгоритмы хеширования и шифрования, правила проверки подлинности и открытый ключ, а также цифровую подпись, которая позволяет удостоверить подлинность и целостность сертификата. Как формируется цифровая подпись? От всех значащих полей сертификата считается хеш-функция и шифруется закрытым ключом центра сертификации. В само- подписанных сертификатах или сертификатах корневого центра сертификации результаты хеш-функции шифруются закрытым ключом непосредственного субъекта сертификации. Как проверяется сертификат? Предположим, мы подключаемся к веб-серверу по протоколу https и получаем его сертификат. • Проверяем его срок годности. • Проверяем находится ли CA которым был выпущен сертификат, списке доверительных CA на нашем ПК. • Проверяем подпись сертификата, те считаем заново хеш-сумму от всех значащих полей сертификата, расшифровываем цифровую подпись сертификата при помощи открытого ключа CA и сравниваем с нашей хеш-суммой, если совпадает — значит сертификат действительный. • Если в сертификате указана точка распространения списка отзыва сертификатов (CDP), то забираем оттуда список отзыва сертификатов (CRL), проверяем его цифровую подпись и отсутствие в этом списке нашего сертификата. • Проверяем дополнительные поля, например, может ли этот сертификат использоваться для шифрования веб-трафика. Этот процесс нужно очень хорошо понимать. Что такое центр сертификации? Центр сертификации (CA) — это некоторый набор софта, главная функция которого выдача, контроль и отзыв сертификатов. Каждый CA имеет свой сертификат и закрытый ключ. Закрытый ключ нужно хранить как зеницу ока, потому что он используется для подписи всех выдаваемых сертификатов и списков отзыва (CRL). Сертификату CA должны по априори доверять все компьютеры в сети. Что такое PKI? PKI (Public Key Infrastructure — Инфраструктура Открытого Ключа) — это набор средств и правил необходимых для поддержания иерархии сертификатов. Проще говоря — это совокупность сертификатов, правил их выдачи и отзыва, правил хранения ключей, центров сертификации и т.д. Что такое одноуровневая PKI? Одноуровневая иерархия PKI — это наиболее простое решение для управления сертификатами, это один корневой центр сертификации, который подписывает все выдаваемые сертификаты организации. Недостаток одноуровневой системы заключается в недостаточной защищенности, возможности компрометации закрытого ключа корневого центра сертификации. 8 3. Практическая часть 3.1 Создание облачного сервера Итак, для того чтобы нам начать нашу работу необходимо прежде всего создать облачный сервер. В этом нам поможет такая платформа как Digital Ocean. После прохождения регистрации\авторизации на данной платформе перед нами появится окно для создания нашего проект. Рисунок 3.1.1 – Меню создания проекта После мы уже переходим непосредственно к созданию нашего облачного сервера, на котором у нас будет развёртываться инфраструктура нашего открытого ключа. Рисунок 3.1.2 – Меню создания облачного сервера 9 Нам необходимо будет выбрать операционную систему (ОС), на которой у нас будет базироваться наш сервер. В данной работе выбор пал на ОС Linux, а если быть точнее, то на конкретный дистрибутив – Ubuntu 16.04. Далее нужно выбрать план производительности нашего сервера. Так как у нас сервер будет просто выдавать сертификаты (корневой сертификат и список отзыва будут доступны через сеть), то из этого следует, что нагрузки на этот сервер фактически не будет. Из вышесказанного делаем вывод что нам подходит тариф 5$\месяц с параметрами сервера: 1 ГБ оперативной памяти, 1 процессор, 25 ГБ SSD накопителя. Дальше мы выбираем область, где будет находиться данный сервер. Выбор пал на Франкфурт, потому что там самые быстрые каналы относительно нашего местоположения. Затем выбираем способ аутентификации, у нас это SSH-ключ. После нам необходимо написать наше доменное имя, у нас это ca.hhbb.me. После чего мы можем уже создать наш дроплет. Рисунок 3.1.3 – Созданный сервер 10 После того как мы создали наш сервер, и он развернулся, необходимо скопировать его IP-адрес и обновить в DNS. Но перед этим мы создадим ещё один сервер, а если точнее веб-сервер. Для того чтобы показать, как этот веб-сервер будет использовать наши сертификаты из центра сертификации. По аналогии создаём ещё один сервер, только немного с другими параметрами, а именно план производительности. Предположим, у нас будет не сильно загруженный портал, а это значит нам подходит тариф 15$\месяц с параметрами сервера: 3 ГБ оперативной памяти, 1 процессор, 60 ГБ SSD накопителя. Доменное имя у него также изменится на hhbb.me. Рисунок 3.1.4 – Развёрнутый веб-сервер Рисунок 3.1.5 – Прописка IP-адресов серверов в DNS 11 3.2 Настройка корневого центра сертификации Итак, мы наконец перешли к настройке нашего центра сертификации. Для этого нам необходимо запустить программу PuTTY и вбить туда доменное имя нашего первого сервера и непосредственно наш ключ. После чего у нас запуститься наша консоль, где для начала мы проверим работоспособность нашего сервера. Рисунок 3.2.1 – Характеристики сервера Собственно, далее мы переходим в директорию /etc/pki/CA, с этого момента она станет нашей рабочей директорией и все 100% действий мы будем делать в пределах нее. Потом создаем необходимые для работы файлы, в index.txt будут записываться все выдаваемые сертификаты, в файлах serial будет храниться последний серийный номер выданного сертификата, а в crlnumber номер последнего списка отзыва сертификатов. Кажется мелочь, а работать без них ничего не будет. Создаем директорию request, в нее мы будем складывать запросы на подпись сертификата. Рисунок 3.2.2 – Консоль после создания дополнительных фалов 12 Итак, есть важный момент. Когда мы будем запускать утилиту для генерации наших сертификатов нужно будет отвечать на разные вопросы. Чтобы этого не делать нам необходимо создать некий профиль, а в этом профиле будет находиться вся необходимая информация. Копируем файл с настройками центра сертификации и переходим к его редактированию. Далее, нужно подправить файл настроек чтобы все заработало как нужно. Рисунок 3.2.3 – Файл настроек Мы производим настройки такого рода как пояснение в какой директории мы работаем, исправление опечаток в оригинальном файле с настройками, также можем редактировать параметры нашего месторасположения (страна, город и т.д.), после пишем название нашей фирмы на своё усмотрение, добавляем параметр, который укажет место, где можно скачать корневой сертификат, также добавим точку распространения списка отзывов сертификатов. В конце нам необходимо добавить переменную pathlen с параметром ноль чтобы нельзя было подписывать сертификаты с помощью цепочки сертификатов. Теперь создадим сертификат корневого ЦС сроком на 5 лет, он спросит у нас пароль что бы зашифровать закрытый ключ и предложит заполнить несколько полей, в принципе немного раньше мы задали для них значения по умолчанию, поэтому смело щелкаем Enter, за исключением Common Name (CN) туда мы вводим полное название нашего CA: Horns and hooves, LLC Certification Authority. 13 Рисунок 3.2.4 – Результат создания сертификата После создания файла сертификата, нам необходимо создать для него пароль. Он будет храниться в файле key. После этого у нас начнётся генерация сертификата и начнут задавать те самые вопросы, которые были описаны выше. Но так как в файле настроек мы уже указали параметры по умолчанию, то вопросы можно просто пропустить. Далее есть важный момент, нас попросят ввести наше доменное имя и там мы пишем название центра нашей сертификации, а после необходимо ввести адрес электронной почты вашей организации. Рисунок 3.2.5 – Результат генерации сертификата Итак, чтобы проверить что у нас сертификат сгенерировался мы установим midnight commander. Ниже будет представлен рисунок, на котором изображен открытый фай с сертификатом. 14 Рисунок 3.2.6 – Файл сертификата Итак, далее нам нужно создать список отзыва сертификатов (CRL), пока он будет пустым. Однако очень важно, чтобы он существовал и был доступным, если клиент не сможет получить CRL, то сертификат скорее всего будет признан недействительным. После запуска openssl запросит пароль от закрытого ключа ЦС необходимый для подписи CRL. Далее нам необходимо установить веб-сервер apache для того, чтобы мы могли распространять наш корневой сертификат. Рисунок 3.2.7 – Результат установки веб-сервера apache Теперь нужно опубликовать в интернете сертификат CA и список отзыва. У фирмы ООО “Рога и копыта” есть сайт ca.hhbb.me, для простоты эксперимента предположим, что у нас настроен сервере Apache, который перенаправляет все запросы с ca.hhbb.me в директорию /var/www/html/pki. Итак, создадим две символические ссылки. Результатом будет то, что мы сможем скачать сертификат с данного сайта. 15 Рисунок 3.2.8 – Результат настройки символических ссылок Рисунок 3.2.9 – Скаченный сертификат В итоге у нас получился полностью работоспособный корневой центр сертификации. 16 4. Работа с сертификатами 4.1 Выдача сертификатов Что ж, основной центр сертификации мы настроили, то есть корневой, а теперь нам необходимо раздавать сертификаты для других серверов. А именно мы выдадим сертификат для нашего веб-сервера, который мы создали ещё в начале работы. То есть предположим, что нам нужно выдать сертификат для защищенного при помощи SSLv3 сайта hhbb.me. Создадим запрос к центру сертификации, как и при создании корневого ЦС он задаст нам кучу вопросов, мы их все пропускаем, как и в прошлый раз, а в Common Name (имя домена веб-сервера) вводим имя узла: hhbb.me. Рисунок 4.1.1 – Результат выдачи сертификата веб-серверу Теперь, когда мы выдали сертификат нашему веб-серверу, нам необходимо его подписать ключом корневого центра сертификации. Для этого нам необходимо отправить запрос на сертификат hhbb.me.csr на подпись в CA и на выходе мы получим готовый подписанный сертификат. Для подписи потребуется ввести пароль закрытого ключа CA и два раза согласиться щелкнув y. Рисунок 4.1.2 – Результат подписи сертификата Итак, сертификат мы получили, получили для него подпись. Нам остаётся теперь только его применить. А применять мы его будем на нашем веб-сервере. Следовательно, для него тоже необходимо провести настройку, а именно обновить список пакетов в репозитории, да и в принципе обновить весь сервер. Далее также проводим установку веб- сервера apache. 17 Рисунок 4.1.3 – Результат начала настройки веб-сервера Можно заметить, что сервер apache работает исправно, но также стоит сказать, что на рисунке видно, что соединение не защищено. После установки веб-сервера снова устанавливаем midnight commander чтобы в дальнейшем скопировать сертификат. На рисунке ниже будет показан результат работы, а именно получение сертификата для веб- сервера из корневого центра сертификации. Но есть один важный момент для нашего веб- сервера нужно переконвертировать файл сертификата в формат .pem. Затем копируем файл сертификата и ключ из центра сертификации. В итоге чтобы всё заработало нам нужно подкорректировать файл конфигурации apache, а после перезапустим его. Рисунок 4.1.4 – Работа сервера apache после проведения корректировок 18 Рисунок 4.1.5 – Повторный переход на сайт после получения сертификации Как видно у нас теперь всплывает сообщение о небезопасном соединении. Проверим наличие сертификации. На рисунке ниже видно, что сертификат был присвоен успешно. Рисунок 4.1.6 – Сертификат присвоенный веб-серверу Есть ещё один вопрос для рассмотрения. Нужно сделать так чтобы браузер доверял сертификату, выданного из корневого центра сертификации. И чтобы больше не всплывало сообщение о небезопасном соединении. А для этого нам необходимо импортировать корневой сертификат в хранилище сертификатов браузера. Как раз для этого и был скачан сертификат ранее. 19 Рисунок 4.1.7 – Результат внедрение корневого сертификата в браузер Можно заметить, что больше не появляется предупреждение о небезопасном соединении и появился значок замка. 20 4.2 Отзыв сертификата Следующая задача отозвать скомпрометированный сертификат веб-сервера hhbb.me. Для выполнения команд потребуется пароль от закрытого ключа ЦС. Помечаем сертификат в базе CA как отозванный. Результат отзыва сертификаты будет представлен на рисунке ниже. Рисунок 4.2.1 – Результат отзыва сертификата Далее нам необходимо переподписать список отзыва, потому что мы отозвали наш сертификат. Ранее там не было никакой информации. Итак, обновляем список отзыва сертификатов CRL. На рисунке ниже будет видно, что после того как сертификат был отозван, то подключение вновь стало не защищённым и собственно придёт предупреждение. Рисунок 4.2.2 – Состояние веб-сервера после отзыва сертификата 21 5. Заключение Таким образом, мы настроили инфаструктуру открытых ключей (Privat Key Infrastructure) с собственным центром сертификации (CA). Были приобретены навыки установки корневого сертификата CA в доверенное хранилище, и выдать всем серверам сертификаты, соединения будут защищены и никаких утечек информации. 22 Список литературы 1. Установка центра сертификации на предприятии [Электронный ресурс] – Режим доступа: https://habr.com/ru/company/microsoft/blog/348944/ , свободный. 2. Как развернуть и настроить инфраструктуру открытого ключа (PKI) и корпоративным центом сертификации (CA) [Электронный ресурс] – Режим доступа: https://my-sertif.ru/kak- razvernut-i-nastroit-infrastrukturu-otkrytogo-klyuha-pki-i-korporativnym-tsentom-sertifikatsii-a- blog-universiteta-sediomm/ , свободный. 3. Службы сертификации и их применение [Электронный ресурс] – Режим доступа: https://intuit.ru/studies/courses/498/354/lecture/8428 , свободный. 23 Приложение А Список команд mkdir -p /etc/pki/CA cd /etc/pki/CA touch index.txt echo 01 > serial echo 01 > crlnumber mkdir request cp ../etc/ssl/openssl.cnf . vim openssl.cnf openssl req -config openssl.cnf -new -x509 -keyout private/cakey.pem -out cacert.pem -days 1825 openssl ca -config openssl.cnf -gencrl -out crl.pem apt-get install apache2 ln -s /etc/pki/CA/cacert.pem /var/www/html/rootca.crt ln -s /etc/pki/CA/crl.pem /var/www/html/rootca.crl openssl req -config openssl.cnf -new -nodes -keyout private/hhbb.me.key -out request/hhbb.me.csr mkdir newcerts certs openssl ca -config openssl.cnf -out certs/hhbb.me.crt -infiles request/hhbb.me.csr openssl x509 -in hhbb.me.crt -out hhbb.me.pem openssl ca -config openssl.cnf -revoke certs/hhbb.me.crt openssl ca -config openssl.cnf -gencrl -out crl.pem |