Подсистема защиты обособленного подразделения ООО «Центр защиты информации» Гриф

В настоящее время в нашей стране идет бурный процесс информатизации практически всех сфер общественной деятельности. Хотя бумажный документооборот все еще преобладает над электронным документооборотом в силу довольно слабой распространенности последнего, объем корпоративных электронных документов удваивается каждые три года.

С развитием вычислительной техники и электронных технологий обработки и передачи информации на расстоянии, а так же согласно федеральным программам, проводимым в России, осуществился переход к электронному документообороту, позволившему автоматизировать многие процессы делопроизводства.

Центр сертификации или удостоверяющий центр — это организация или подразделение организации, которая выпускает сертификаты ключей электронной цифровой подписи, это компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится удостоверяющими центрами в виде цифровых сертификатов.

Центр регистрации определяется как объект, ответственный за идентификацию и аутентификацию субъекта сертификата, но неспособный подписывать и издавать сертификат. Между центром регистрации и удостоверяющим центром идёт постоянный информационный обмен.

Существует объективная необходимость обеспечения защиты информации как на этапе информационного взаимодействия между центром регистрации и удостоверяющим центром, так и в процессе обработки и хранения информации, внутреннего документооборота центра регистрации.

Объектом исследования является подсистема защиты обособленного подразделения ООО «Центр защиты информации «Гриф». Предметом исследования является качество системы защиты информации подразделения.

В настоящий момент обособленное подразделение ООО «ЦЗИ «Гриф», которое является по своему функциональному назначению центром регистрации, имеет собственную систему безопасности, построенную в соответствии с инструкцией по безопасности, разработанной в соответствии с требованиями основных документов в сфере информационной безопасности. Тем не менее, практический опыт показал, что исходная система безопасности обособленного подразделения имеет ряд недостатков.

Целью данного проекта является разработка подсистемы защиты информации, которая бы более эффективной, чем исходная.

Основными задачами дипломного проекта являются диагностический анализ предприятия ООО «ЦЗИ «Гриф», исследование основных угроз и разработка обобщённой модели системы защиты информации.

1. Диагностический анализ ООО «ЦЗИ «ГРИФ»

1.1 Общая характеристика ООО «ЦЗИ «Гриф»

Центр защиты информации «Гриф» является организацией, специализирующейся на предоставлении услуг в области информационных технологий и защиты информации. Компания основана в 2008 году и успешно работает на рынке.

Центр защиты информации «Гриф» в соответствии Федеральным законом ФЗ-1 от 10.01.2002 «Об электронной цифровой подписи» предоставляет следующие услуги:

— изготавливает сертификаты ключей подписей;

— создает ключи электронных цифровых подписей по обращению участников информационной системы с гарантией сохранения в тайне закрытого ключа электронной цифровой подписи;

— приостанавливает и возобновляет действие сертификатов ключей подписей, а также аннулирует их;

— ведет реестр сертификатов ключей подписей, обеспечивает его актуальность и возможность свободного доступа к нему участников информационных систем;

— проверяет уникальность открытых ключей электронных цифровых подписей в реестре сертификатов ключей подписей и архиве удостоверяющего центра;

— выдает сертификаты ключей подписей в форме документов на бумажных носителях и (или) в форме электронных документов с информацией об их действии;

— осуществляет по обращениям пользователей сертификатов ключей подписей подтверждение подлинности электронной цифровой подписи в электронном документе в отношении выданных им сертификатов ключей подписей.

Сертификат уполномоченного лица удостоверяющего центра внесен в Единый государственный реестр. Сертификаты и ключи ЭЦП изготавливаются с использованием сертифицированного ФСБ РФ средства криптографической защиты «КриптоПро CSP» и соответствуют государственным стандартам Российской Федерации. Весь обмен информацией с Центром Регистрации Удостоверяющего Центра осуществляется с использованием защищенного протокола TLS с одно и двусторонней аутентификацией.

1.2 Анализ функциональной структуры ООО «ЦЗИ «Гриф»

Анализ функциональной структуры предприятия предполагает анализ процесса функционирования всей системы предприятия, который представляет собой взаимодействие ее элементов, обеспечивающее выполнение намеченных целей в условиях воздействия внешних факторов на основе имеющихся ресурсов.

Под функциональной структурой подразумевается специализация подразделений по отдельным функциям управления на всех уровнях иерархии системы. Такая организация значительно повышает качество управления благодаря специализации руководителей в более узких областях деятельности.

Общая деятельность предприятия представляет собой совокупность деятельности предприятия в различных функциональных областях, которая отражается в процессах.

1.2.1 Построение функциональной схемы ООО «ЦЗИ «Гриф»

Функциональная структурная схема предприятия представляет собой результат декомпозиции системы по функциональному принципу.

Рассмотрим основные подсистемы системы управления предприятием. К ним относятся:

— производственная система;

— обеспечивающая система;

— организационно-управленческая система.

Производственная подсистема включает в себя функциональную область по оказанию услуг населению.

Организационно-управленческая подсистема представляет собой второе звено функциональной системы ООО «ЦЗИ «Гриф» и включает в себя области:

— организацию производства;

— организацию обеспечения;

— управление производством;

— управление обеспечением.

Обеспечивающая подсистема ООО «ЦЗИ «Гриф» включает в себя:

— финансового обеспечения;

— информационного обеспечения;

— правового обеспечения;

— кадрового обеспечения;

— обеспечения транспортом, сырьем и материалами.

Таким образом, мы можем рассмотреть функции каждой подсистемы в декомпозиции.

Функциональная структура, представленная таким образом, даёт наглядное представление об иерархической структуре каждой из подсистем, без учёта деления элементов по процессам, происходящим в каждой из представленных областей.

Деление каждой из областей на внутренние процессы необходимо рассматривать в рамках отдельной декомпозиции, которая будет представлена далее. Функциональная структурная схема, построенная на основании проведенного анализа функционирования предприятия, представлена на рисунке 1.1.

Рисунок 1.1 — Функциональная структура ООО «ЦЗИ «Гриф»

1.2.2 Детализация функциональных областей управления

Каждая из функциональных областей управления предприятием предполагает наличие целого ряда внутренних процессов, связанных с ней.

Детализация функциональных областей управления ООО «ЦЗИ «Гриф» помогает раскрыть их внутреннюю структуру.

Для демонстрации взаимосвязи функциональных областей и процессов, вытекающей из анализа, представим информацию в таблице 1.1.

Таблица 1.1 — Таблица взаимосвязи функциональных областей и процессов предприятия

1.3 Анализ организационно-управленческой структуры ООО «ЦЗИ «Гриф»

Организационно-управленческая структура предприятия сформирована таким образом, что обеспечивает:

— оперативное реагирование на изменение рыночной ситуации;

— закрепление каждой функции, реализуемой предприятием, за каким-либо ее структурным подразделением;

— распределение и персонификацию ответственности за организацию и выполнение функций, реализуемых предприятием и принятие управленческих решений в каждой из областей.

— эффективное распределение принятия управленческих решений.

Каждый отдел предприятия является самостоятельным структурным подразделением ООО «ЦЗИ «Гриф». За назначение и увольнение начальников отделов лично отвечает генеральный директор.

Между главами отделов постоянно проводятся совещания, на которых принимается основная часть решений стратегического и тактического характера в рамках каждого отдела. От качества работы каждого отдела зависит качество работы всего предприятия в целом, поэтому к управлению предприятием необходим комплексный подход, который и достигается за счёт распределения ролей по отделам, в соответствии со специализацией каждого, но сохранения централизованной системы управления.

Каждое подразделение несёт ответственность за выполнение определённого круга задач.

Выделяется три уровня системы: верхний, средний и оперативный.

Организационно-управленческая структура предприятия ООО «ЦЗИ «Гриф» отражена на рисунке 1.2

Рисунок 1.2 — Организационно-управленческая структура предприятия ООО «ЦЗИ «Гриф»

К ключевым задачам отдела кадров можно отнести:

— подбор и распределение кадров на предприятии, путём оценки их квалификации и деловых качеств;

— организацию оформления сотрудников в связи с приёмом, увольнением или переводом на другую должность по всем правилам текущего законодательства;

— выдачу справок о трудовой деятельности сотрудников, а также заполнение, ведение и хранение трудовых книжек, ведение учёта документации отдела;

— размещение объявлений и приёме на работу, обработка поступающих резюме, приём соискателей;

— оформление документов и изучение материалов по вопросам нарушения трудовой дисциплины;

— организацию периодических медицинских осмотров и ознакомление новых работников с правилами текущего трудового распорядка предприятия;

— подбор инженеров-технологов, руководителей и служащих и оформление необходимых документов;

— осуществление инструктажа и ознакомления работников с предприятием;

— изучение дел работников, их личных и деловых качеств и предоставление руководству отчётов и рекомендаций по передвижению сотрудников по ступеням иерархии предприятия;

— обеспечение готовности документов в сфере пенсионного страхования и ведение учёта в системе Государственного пенсионного страхования;

— организация табельного учёта и обязательного медицинского страхования сотрудников.

К основным задачам юридического отдела можно отнести:

— обеспечение соответствия деятельности организации требованиям текущего законодательства, защиту правовых интересов предприятия;

— работа с договорами и исками, учёт судебной практики;

— осуществление правовой экспертизы актов организации, нормативно-правовых актов органов местного самоуправления;

— доведение до персонала особенностей текущего законодательства и порядок применения в работе подразделениями организации;

— участие во взаимодействии с правоохранительными органами, а также с органами государственной власти и местного самоуправления;

— разработка и утверждение нормативно-правовых актов внутри организации;

— анализ правовой базы и учёт нормативных актов организации.

Главной задачей отдела снабжения является обеспечение компании всеми необходимыми для ее деятельности материальными ресурсами.

Ключевые задачи финансово-экономического отдела:

— организация финансово-экономической деятельности предприятия и его подразделений;

— обеспечение расстановки в интересах предприятия личного состава бухгалтерских и финансовых служб с учетом их служебной квалификации, опыта, деловых и личных качеств;

— организация работы по обеспечению сохранности денежных средств и финансовой документации;

— организация работы по рассмотрению поступающих от личного состава жалоб и предложений по вопросам финансово-экономической деятельности;

— проведение проверок по фактам финансовых нарушений;

— определение источников и размеров финансовых ресурсов на предприятии.

Основными задачами бухгалтерии являются:

— составление отчётности, объективно отражающей финансовое состояние организации, и её деятельности для внутреннего пользования руководства и других уполномоченных лиц организации, а также, при необходимости, и партнёров;

— анализ и оценка использования внутренних резервов организации;

— выявление незадействованных производственных резервов и их мобилизация с целью последующего эффективного использования;

— предотвращение ситуаций, в которых деятельность организации может приносить убытки и попадать в положение финансовой неустойчивости;

— своевременное предоставление необходимой информации внутренним пользователям бухгалтерской отчётности для проведения различных контрольных мероприятий и осуществления хозяйственных операций с надлежащей эффективностью и целесообразностью.

Таким образом, при данной системе распределения ролей и функций на предприятии, достигается наибольшая эффективность реализации её основной деятельности, связанная с узкой специализацией каждого отдела ООО «ЦЗИ «Гриф».

1.4 Анализ целей ООО «ЦЗИ «Гриф»

Цель представляет собой идеальный или реальный предмет сознательного или бессознательного стремления субъекта, финальный результат, на который преднамеренно направлен процесс.

Постановка целей предполагает создание иерархической системы главных целей, которые будут разбиваться на более узкие конкретные цели.

Адекватная постановка целей деятельности позволяет точно выбрать способны и средства их достижения и максимально эффективно их достигнуть.

Для анализа целей предприятия необходимо построить дерево целей на основе имеющейся информации о системе. В данной иерархической системе цели более низкого уровня будут выступать средствами для достижения целей более высокого уровня.

Нам необходимо построить правильную, но простую модель. Для этого следовать будем следующим принципам:

1.Принципу полноты. Он подразумевает полное достижение цели благодаря достижению подцелей.

2.Принципу суперпозиции подцелей. Подцели представляются независимыми.

3.Принципу конечности декомпозиции Алгоритм декомпозиции включает в себя конечное число шагов.

С помощью таблицы 1.2 проиллюстрируем классификацию подцелей.

Исходя из анализа целей предприятия, построим дерево целей, которое показано на рисунке 1.3.

Таблица 1.2 — Анализ целей предприятия ООО «ЦЗИ «Гриф»

Рисунок 1.3 — Дерево целей ООО «ЦЗИ «Гриф»

Таким образом, мы получаем дерево целей, отвечающее заявленным принципам, отражающее структуру целей ООО «ЦЗИ «Гриф».

1.5 Выявление проблемных ситуаций ООО «ЦЗИ «Гриф»

Эффективность процесса управления предприятием во многом зависит от того, насколько хорошо выявляются проблемные ситуации в процессе производства и насколько оперативное и качественное решение принимается после выявления. Каждое предприятие необходимо рассматривать, учитывая специфику его работы.

При возникновении проблемы — ситуации расхождения между желаемым и реальным состоянием системы — применяется комплекс мер по преодолению такой ситуации.

Наиболее оптимальным признаётся комплексный подход решения проблемных ситуаций. При таком подходе важно правильно сформулировать ряд проблем и взаимосвязей между ними и решать не каждую проблему в отдельности, а группу проблем на том или ином уровне иерархии системы.

Для поэтапного рассмотрения проблемных ситуаций рассматривается каждый из уровней системы предприятия.

Любая из возможных ситуаций рассматривается на предмет расхождения между желаемым и действительным, а затем, выбирается метод решения, наиболее подходящий для разрешения данной ситуации.

Применительно к анализу ООО «ЦЗИ «Гриф», в качестве проблем будут, прежде всего, рассматриваться ситуации, при которых достижение подцелей может оказаться невозможным или затруднительным, что, в свою очередь, может помешать достижению ключевой цели организации.

Для представления возможных путей решения проблемных ситуаций предприятия сформируем перечень возможных проблем.

Анализ проблемных ситуаций ООО «ЦЗИ «Гриф» отражён в таблице 1.3.

Таблица 1.3 — Анализ проблемных ситуаций ООО «ЦЗИ «Гриф»

Таким образом, из составленной таблицы видно, что значительная часть проблем организации связана с обработкой, хранением, систематизацией и использованием информации различного рода, на различных уровнях.

Проблема хищения информации будет решена в процессе разработки данного проекта путём анализа имеющейся системы защиты информации, выявления недостатков этой системы и разработки новой, модифицированной системы защиты информации.

2. Анализ подсистемы проверки целостности и аутентичности информации ООО «ЦЗИ «Гриф»

Важными инструментами безопасности являются процедуры, позволяющие убедиться в целости и аутентичности данных. Проанализируем подсистему проверки целостности и аутентичности информации ООО «ЦЗИ «Гриф».

Способ, позволяющий шифровать сообщения, обмениваясь ключами по открытым каналам связи, был придуман в середине 70-х годов прошлого столетия, а в начале восьмидесятых появился первый реализующий его алгоритм — rsa. Теперь пользователь может сгенерировать два связанных между собой ключа — ключевую пару. Один из этих ключей по несекретным каналам рассылается всем, с кем пользователь хотел бы обмениваться конфиденциальными сообщениями. Этот ключ называют открытым (англ. public key). Зная открытый ключ пользователя, можно зашифровать адресованное ему сообщение, но расшифровать его позволяет лишь вторая часть ключевой пары — закрытый ключ (private key). При этом открытый ключ не дает возможности вычислить закрытый: такая задача, хоть и разрешима в принципе, но при достаточно большом размере ключа требует многих лет машинного времени. Для сохранения конфиденциальности получателю необходимо лишь хранить в строгом секрете свой закрытый ключ, а отправителю — убедиться, что имеющийся у него открытый ключ действительно принадлежит адресату.

Так как для шифрования и расшифровки используются различные ключи, алгоритмы такого рода назвали асимметричными. Наиболее существенным их недостатком является низкая производительность — они примерно в 100 раз медленнее симметричных алгоритмов. Поэтому были созданы криптографические схемы, использующие преимущества как симметричных, так и асимметричных алгоритмов:

— для шифрования файла или сообщения используется быстрый симметричный алгоритм, причем ключ шифрования генерируется случайным образом с обеспечением приемлемых статистических свойств;

— небольшой по размерам симметричный ключ шифрования шифруется при помощи асимметричного алгоритма с использованием открытого ключа адресата и в зашифрованном виде пересылается вместе с сообщением;

— получив сообщение, адресат своим закрытым ключом расшифровывает симметричный ключ, а с его помощью — и само сообщение.

Чтобы избежать шифрования всего сообщения при помощи асимметричных алгоритмов, используют хеширование: вычисляется хеш-значение исходного сообщения, и только эта короткая последовательность байтов шифруется закрытым ключом отправителя. Результат представляет собой электронную цифровую подпись. Добавление такой подписи к сообщению позволяет установить:

— аутентичность сообщения — создать подпись на основе закрытого ключа мог только его хозяин;

— целостность данных — вычислить хеш-значение полученного сообщения и сравнить его с тем, которое хранится в подписи: если значения совпадают, значит, сообщение не было изменено злоумышленником после того, как отправитель его подписал.

Таким образом, асимметричные алгоритмы позволяют решить две задачи: обмена ключами шифрования по открытым каналам связи и подписи сообщения. Чтобы воспользоваться этими возможностями, нужно сгенерировать и сохранить две ключевые пары — для обмена ключами и для подписей. В этом нам поможет CryptoAPI.

Каждый криптопровайдер располагает базой данных, в которой хранятся долговременные ключи пользователей. База данных содержит один или более контейнеров ключей. Пользователь может создать несколько контейнеров с различными именами (именем контейнера по умолчанию является имя пользователя в системе).

Подключение к контейнеру производится одновременно с получением контекста криптопровайдера при вызове функции cryptacquirecontext — имя контейнера ключей передается функции вторым ее аргументом. Если второй аргумент содержит пустой указатель (nil), то используется имя по умолчанию, то есть имя пользователя. В том случае, если доступ к контейнеру не нужен, можно передать в последнем аргументе функции флаг crypt_verifycontext; при необходимости создать новый контейнер используется флаг crypt_newkeyset; а для удаления существующего контейнера вместе с хранящимися в нем ключами — crypt_deletekeyset.

Каждый контейнер может содержать, как минимум, две ключевые пары — ключ обмена ключами и ключ подписи. Ключи, используемые для шифрования симметричными алгоритмами, не сохраняются.

После создания контейнера ключей необходимо сгенерировать ключевые пары обмена ключами и подписи. Эту работу в CryptoAPI выполняет функция cryptgenkey (провайдер, алгоритм, флаги, ключ):

— провайдер — дескриптор криптопровайдера, полученный в результате обращения к функции cryptacquirecontext;

— алгоритм — указывает, какому алгоритму шифрования будет соответствовать создаваемый ключ. Информация об алгоритме, таким образом, является частью описания ключа. Каждый криптопровайдер использует для обмена ключами и подписи строго определенные алгоритмы. Так, провайдеры типа prov_rsa_full, к которым относится и microsoft base cryptographic provider, реализуют алгоритм rsa;

— флаги — при создании асимметричных ключей управляет их размером. Используемый нами криптопровайдер позволяет генерировать ключ обмена ключами длиной от 384 до 512 бит, а ключ подписи — от 512 до 16 384 бит. Чем больше длина ключа, тем выше его надежность, поэтому не рекомендуется для использования ключ обмена ключами длиной менее 512 бит, а длину ключа подписи не рекомендуется делать меньше 1024 бит. По умолчанию криптопровайдер создает оба ключа длиной 512 бит. Необходимую длину ключа можно передать в старшем слове параметра флаги:

— ключ — в случае успешного завершения функции в этот параметр заносится дескриптор созданного ключа.

В поле «Контейнер» можно указать имя контейнера ключей; если оставить это поле пустым, будет использован контейнер по умолчанию. После генерации ключа в memo-поле выводится отчет о его параметрах. Для этого используется функция cryptgetkeyparam (ключ, параметр, буфер, размер, флаги). Чтобы получить информацию о требуемом параметре, нужно через второй аргумент функции передать соответствующую константу: kp_algid — идентификатор алгоритма, kp_keylen — размер ключа, и т. д.

procedure tgenerateform. okbtnclick (sender: tobject);

var cont: pchar;

err: string;

hprov: hcryptprov;

keyexchkey, signkey: hcryptkey;

flag, keylen: dword;

begin

{если ни один ключ не выбран — выход}

if not (kekcheckbox.checked or skcheckbox. checked) then exit;

{считываем имя контейнера}

if length (containeredit.text) = 0

then cont := nil

else

begin

err := containeredit. text;

cont := stralloc (length (err) + 1);

strpcopy (cont, err);

end;

cryptacquirecontext (@hprov, cont, nil, prov_rsa_full, 0);

{генерация ключа обмена ключами (key exchange key)}

if kekcheckbox. checked then

begin

{считываем длину ключа и помещаем ее в

старшее слово параметра ФЛАГИ}

keylen := strtoint (keyexchlenedit.text);

flag := keylen shl 16;

if not cryptgenkey (hprov, at_keyexchange, flag, @keyexchkey) then

begin

{обработка ошибок}

end

else

begin

reportmemo.lines.add ('');

reportmemo.lines.add ('Создан ключ обмена ключами:');

flag := 4;

if not cryptgetkeyparam (keyexchkey, kp_keylen, @keylen, @flag, 0) then

begin

{обработка ошибок}

end

else reportmemo.lines.add (' длина ключа — ' + inttostr (keylen));

flag := 4;

if not cryptgetkeyparam (keyexchkey, kp_algid, @keylen, @flag, 0) then

begin

{обработка ошибок}

end

else reportmemo.lines.add (' алгоритм — ' + algidtostr (keylen));

{функция algidtostr здесь не приводится. Она состоит из единственного

оператора case, отображающего целый идентификатор алгоритма в строку}

end;

end;

{генерация ключа подписи (signature key)}

if skcheckbox. checked then

begin

{выполняется аналогично генерации ключа обмена ключами}

end;

cryptreleasecontext (hprov, 0);

end;

При экспорте данные ключа сохраняются в одном из трех возможных форматов:

— publickeyblob — используется для сохранения открытых ключей. Поскольку открытые ключи не являются секретными, они сохраняются в незашифрованном виде;

— privatekeyblob — используется для сохранения ключевой пары целиком (открытого и закрытого ключей). Эти данные являются в высшей степени секретными, поэтому сохраняются в зашифрованном виде, причем для шифрования используется сеансовый ключ (и, соответственно, симметричный алгоритм);

— simpleblob — используется для сохранения сеансовых ключей. Для обеспечения секретности данные ключа шифруются с использованием открытого ключа получателя сообщения.

Экспорт ключей в CryptoAPI выполняется функцией cryptexportkey (экспортируемый ключ, ключ адресата, формат, флаги, буфер, размер буфера):

— экспортируемый ключ — дескриптор нужного ключа;

— ключ адресата — в случае сохранения открытого ключа должен быть равен нулю (данные не шифруются);

— формат — указывается один из возможных форматов экспорта (publickeyblob, privatekeyblob, simpleblob);

— флаги — зарезервирован на будущее (должен быть равен нулю);

— буфер — содержит адрес буфера, в который будет записан ключевой blob (binary large object — большой двоичный объект);

— размер буфера — при вызове функции в этой переменной должен находиться доступный размер буфера, а по окончании работы в нее записывается количество экспортируемых данных. Если размер буфера заранее не известен, то функцию нужно вызвать с параметром буфер, равным пустому указателю, тогда размер буфера будет вычислен и занесен в переменную размер буфера.

Экспорт ключевой пары целиком, включая и закрытый ключ, может понадобиться для того, чтобы иметь возможность подписывать документы на различных компьютерах (например, дома и на работе), или для сохранения страховочной копии. В этом случае нужно создать ключ шифрования на основании пароля и передать дескриптор этого ключа в качестве второго параметра функции cryptexportkey.

Запросить у криптопровайдера дескриптор самого экспортируемого ключа позволяет функция cryptgetuserkey (провайдер, описание ключа, дескриптор ключа). Описание ключа — это либо at_keyexchange, либо at_signature.

procedure texportform. okbtnclick (sender: tobject);

var cont: pchar;

err: string;

hprov: hcryptprov;

key, expkey: hcryptkey;

pbuf: pbyte;

buflen: dword;

f: file;

hash: hcrypthash;

begin

{если ни один ключ не выбран — выход}

if not (kekcheckbox.checked or skcheckbox. checked) then exit;

{если нужен пароль, т. е. экспортируется ключевая пара целиком}

if passwedit. enabled and (passwedit.text <> passw2edit. text) then

begin

messagedlg ('Ошибка при вводе пароля! Повторите ввод.', mterror, [mbok]., 0);

exit;

end;

…

" считываем" имя контейнера и подключаемся к криптопровайдеру

…

если нужен ключ шифрования — создаем его на основании пароля

…

{ключ обмена ключами}

if kekcheckbox. checked then

repeat

{получаем дескриптор ключа}

cryptgetuserkey (hprov, at_keyexchange, @key);

{определяем размер буфера для экспорта ключа}

if (whatradiogroup.itemindex = 0) then

cryptexportkey (key, 0, publickeyblob, 0, nil, @buflen)

else cryptexportkey (key, expkey, privatekeyblob, 0, nil, @buflen);

getmem (pbuf, buflen);

{экспортируем данные}

if (whatradiogroup.itemindex = 0) then

cryptexportkey (key, 0, publickeyblob, 0, pbuf, @buflen)

else cryptexportkey (key, expkey, privatekeyblob, 0, pbuf, @buflen);

{освобождаем дескриптор ключа обмена ключами

(сам ключ при этом не уничтожается)}

cryptdestroykey (key);

savedialog1.title := 'Укажите файл для сохранения ключа обмена ключами';

if savedialog1. execute then

begin

assignfile (f, savedialog1. filename);

rewrite (f, 1);

blockwrite (f, pbuf^, buflen);

closefile (f);

messagedlg ('Ключ обмена ключами успешно сохранен', mtinformation, [mbok]., 0);

end;

until true; {keyexchange}

{ключ подписи}

if skcheckbox. checked then

repeat

{аналогично ключу обмена ключами}

until true; {signature}

…

если создавался ключ на основании пароля — уничтожаем его,

после чего освобождаем контекст криптопровайдера

…

end;

Экспортированные таким образом открытые части ключей необходимы для проверки подписи и расшифровки сеансового ключа.

Импорт ключевых пар во вновь созданный контейнер является отдельной процедурой. Необходимо запросить у пользователя название контейнера и пароль, подключиться к провайдеру, создать на основании пароля ключ, считать из файла импортируемые данные в буфер, после чего воспользоваться функцией cryptimportkey (провайдер, буфер, длина буфера, ключ для расшифровки, флаги, импортируемый ключ). При необходимости обеспечить возможность экспорта импортируемой ключевой пары впоследствии в параметре флаги необходимо передать значение crypt_exportable, иначе случае вызов для данной ключевой пары функции cryptexportkey приводит к ошибке.

Выводы

1. Проведён поэтапный анализ ООО «ЦЗИ «Гриф».

2. В результате анализа функциональной структуры построена функциональная модель предприятия.

3. Выявлены основные цели, стоящие перед предприятием, и способы их достижения. Построено дерево целей.

4. Выявлены основные проблемные ситуации и определены методы их разрешения.

5. Выбрана проблемная ситуация для решения в дипломном проекте.

Выявлены основные задачи, стоящие перед организацией и расставлены приоритеты в решении задач. Анализ показал целесообразность и необходимость решения задачи, рассматриваемой в данной работе.

2. Анализ угроз информационной безопасности обособленного подразделения ООО «ЦЗИ «ГРИФ»

2.1 Анализ специфики информационных процессов в инфраструктуре открытых ключей (PKI)

Основным функциональным назначением рассматриваемого обособленного подразделения ООО «ЦЗИ «Гриф» является функция центра регистрации. Центр регистрации является одним из важнейших конечных компонентов инфраструктуры открытых ключей.

Для того чтобы определить основные угрозы безопасности обособленного подразделения, необходимо рассмотреть подразделение в качестве элемента системы, с которой оно ведёт активное взаимодействие.

Инфраструктура открытых ключей представляет собой комплексную систему, сервисы которой реализуются и предоставляются с использованием технологии открытых ключей. Цель PKI состоит в управлении ключами и сертификатами, посредством которого корпорация может поддерживать надежную сетевую среду. PKI позволяет использовать сервисы шифрования и выработки цифровой подписи согласованно с широким кругом приложений, функционирующих в среде открытых ключей.

Основными компонентами PKI являются:

— удостоверяющий центр;

— регистрационный центр;

— репозиторий сертификатов;

— архив сертификатов;

— конечные субъекты (пользователи).

Взаимодействие компонентов PKI иллюстрирует рисунок 1.1. В составе PKI функционируют подсистемы выпуска и аннулирования сертификатов, создания резервных копий и восстановления ключей, выполнения криптографических операций, управления жизненным циклом сертификатов и ключей. Клиентское программное обеспечение пользователей взаимодействует со всеми этими подсистемами.

Фундаментальная предпосылка криптографии с открытыми ключами заключалась в том, что два незнакомых субъекта должны иметь возможность безопасно связываться друг с другом. Например, если пользователь, А желает отправить конфиденциальное сообщение пользователю В, с которым он ранее не встречался, то для шифрования сообщения он должен иметь возможность связать каким-либо образом пользователя В и его открытый ключ. Для сообщества потенциальных пользователей, объединяющего сотни тысяч или миллионов субъектов, наиболее практичным способом связывания открытых ключей и их владельцев является организация доверенных центров. Этим центрам большая часть сообщества или, возможно, все сообщество доверяет выполнение функций связывания ключей и идентификационных данных (идентичности) пользователей.

Такие доверенные центры в терминологии PKI называются удостоверяющими (УЦ); они сертифицируют связывание пары ключей с идентичностью, заверяя цифровой подписью структуру данных, которая содержит некоторое представление идентичности и соответствующего открытого ключа. Эта структура данных называется сертификатом открытого ключа (или просто сертификатом). Сертификат представляет собой некое зарегистрированное удостоверение, которое хранится в цифровом формате и признается сообществом пользователей PKI законным и надежным. Для верификации электронного сертификата используется электронная цифровая подпись УЦ — в этом смысле удостоверяющий центр уподобляется нотариальной конторе, так как подтверждает подлинность сторон, участвующих в обмене электронными сообщениями или документами.

Хотя УЦ не всегда входит в состав PKI (особенно небольших инфраструктур или тех, которые оперируют в закрытых средах, где пользователи могут сами эффективно выполнять функции управления сертификатами), он является критически важным компонентом многих крупномасштабных PKI. Непосредственное использование открытых ключей требует дополнительной их защиты и идентификации для установления связи с секретным ключом. Без такой дополнительной защиты злоумышленник может выдавать себя как за отправителя подписанных данных, так и за получателя зашифрованных данных, заменив значение открытого ключа или нарушив его идентификацию. Все это приводит к необходимости проверки подлинности — верификации открытого ключа. 18].

Удостоверяющий центр объединяет людей, процессы, программные и аппаратные средства, вовлеченные в безопасное связывание имен пользователей и их открытых ключей. Удостоверяющий центр известен субъектам PKI по двум атрибутам: названию и открытому ключу. УЦ включает свое имя в каждый выпущенный им сертификат и в список аннулированных сертификатов (САС) и подписывает их при помощи собственного секретного ключа. Пользователи могут легко идентифицировать сертификаты по имени УЦ и убедиться в их подлинности, используя его открытый ключ.

Регистрационный центр (ЦР) является необязательным компонентом PKI. Обычно ЦР получает от удостоверяющего центра полномочия регистрировать пользователей, обеспечивать их взаимодействие с УЦ и проверять информацию, которая заносится в сертификат. Сертификат может содержать информацию, которая предоставлена субъектом, подающим заявку на сертификат и предъявляющим документ (паспорт, водительские права, чековую книжку и т. п.) или третьей стороной (например, кредитным агентством — о кредитном лимите пластиковой карты). Иногда в сертификат включается информация из отдела кадров или данные, характеризующие полномочия субъекта в компании (например, право подписи документов определенной категории). ЦР агрегирует эту информацию и предоставляет ее УЦ.

УЦ может работать с несколькими регистрационными центрами, в этом случае он поддерживает список аккредитованных регистрационных центров, то есть тех, которые признаны надежными. УЦ выдает сертификат РЦ и отличает его по имени и открытому ключу. ЦР выступает как объект, подчиненный УЦ, и должен адекватно защищать свой секретный ключ. Проверяя подпись ЦР на сообщении или документе, УЦ полагается на надежность предоставленной ЦР информации.

ЦР объединяет комплекс программного и аппаратного обеспечения и людей, работающих на нем. В функции ЦР может входить генерация и архивирование ключей, уведомление об аннулировании сертификатов, публикация сертификатов и САС в каталоге LDAP и др. Но ЦР не имеет полномочий выпускать сертификаты и списки аннулированных сертификатов. Иногда УЦ сам выполняет функции ЦР.

Репозиторий — специальный объект инфраструктуры открытых ключей, база данных, в которой хранится реестр сертификатов (термин «реестр сертификатов ключей подписей» введен в практику Законом РФ «Об электронной цифровой подписи»). Репозиторий значительно упрощает управление системой и доступ к ресурсам. Он предоставляет информацию о статусе сертификатов, обеспечивает хранение и распространение сертификатов и САС, управляет внесениями изменений в сертификаты. К репозиторию предъявляются следующие требования:

— простота и стандартность доступа;

— регулярность обновления информации;

— встроенная защищенность;

— простота управления;

— совместимость с другими хранилищами (необязательное требование).

Репозиторий обычно размещается на сервере каталогов, организованных в соответствии с международным стандартом X.500 и его подмножеством. Большинство серверов каталогов и прикладное программное обеспечение пользователей поддерживают упрощенный протокол доступа к каталогам LDAP (Lightweight Directory Access Protocol). Такой унифицированный подход позволяет обеспечивать функциональную совместимость приложений PKI и дает возможность доверяющим сторонам получать информацию о статусе сертификатов для верификации цифровых подписей.

На архив сертификатов возлагается функция долговременного хранения и защиты информации обо всех изданных сертификатах. Архив поддерживает базу данных, используемую при возникновении споров по поводу надежности электронных цифровых подписей, которыми в прошлом заверялись документы. Архив подтверждает качество информации в момент ее получения и обеспечивает целостность данных во время хранения. Информация, предоставляемая УЦ архиву, должна быть достаточной для определения статуса сертификатов и их издателя. Архив должен быть защищен соответствующими техническими средствами и процедурами. Конечные субъекты, или пользователи, PKI делятся на две категории: владельцы сертификатов и доверяющие стороны. Они используют некоторые сервисы и функции PKI, чтобы получить сертификаты или проверить сертификаты других субъектов. Владельцем сертификата может быть физическое или юридическое лицо, приложение, сервер и т. д. Доверяющие стороны запрашивают и полагаются на информацию о статусе сертификатов и открытых ключах подписи своих партнеров по деловому общению.

Представленная в данном подразделе информация позволяет нам продолжить декомпозицию по информационным процессам, происходящим в рассматриваемой системе.

Таким образом, можно сказать, что от безопасности обособленного подразделения во многом зависит безопасность общей системы инфраструктуры открытых ключей, в которую обособленное подразделение входит в качестве центра регистрации.

2.2 Анализ информационного обмена между обособленным подразделением и удостоверяющим центром

Между обособленным подразделением, которое будем далее называть центром регистрации (ЦР), и удостоверяющим центром (УЦ) происходит активный информационный обмен в процессе оказания услуг. В этот информационный обмен неизбежно вовлекается и конечный пользователь услуг предприятия.

Действия УЦ ограничены политикой применения сертификатов (ППС), которая определяет назначение и содержание сертификатов. УЦ выполняет адекватную защиту своего секретного ключа и открыто публикует свою политику, чтобы пользователи могли ознакомиться с назначением и правилами использования сертификатов. Ознакомившись с политикой применения сертификатов и решив, что доверяют УЦ и его деловым операциям, пользователи могут полагаться на сертификаты, выпущенные этим центром. Таким образом, в PKI удостоверяющие центры выступают как доверенная третья сторона.

Удостоверяющий центр доверяет регистрационному центру проверку информации о субъекте. Регистрационный центр, проверив правильность информации, подписывает её своим ключом и передаёт удостоверяющему центру, который, проверив ключ регистрационного центра, выписывает сертификат.

ЦР обеспечивает принятие, предварительную обработку внешних запросов на создание сертификатов или на изменение статуса уже действующих сертификатов.

ЦР обеспечивает:

1. Разграничение доступа к элементам управления ЦР на основе состава представленного Администратором взаимодействия с пользователем собственного электронного сертификата, определяющего ролевую принадлежность администратора и уровня полномочий.

2. Получение и обработку запроса от Администраторов взаимодействия с пользователями на выпуск сертификата или изменение статуса уже выпущенного сертификата с последующей передачей запроса в ЦС.

3. Хранение заверенных запросов и журналов событий в течение установленного срока, предусмотренного регламентом работы системы, в составе которой функционирует УЦ.

4. Резервное копирование на внешние носители локального архива.

5. Выполнение функций администрирования ЦР.

Политика безопасности ЦР предполагает обработку в ЦР запроса в формате PKCS#10. Область действия — запрос на создание электронного сертификата с локально (внешне, по отношению к УЦ) формированием ключевой пары. Срок действия сертификатов, созданных с помощью данного вида запросов, определен в конфигурации УЦ. На основе технологии данного вида запроса (в зависимости от конфигурации и принятой политики безопасности) в УЦ считаться допустимыми могут следующие разновидности:

1. Запрос сформирован не зарегистрированным ранее пользователем. Особенностью формата PKCS#10 является то, что запрос на формирование сертификата подписывается на закрытом ключе, соответствующий открытый ключ которого еще не зарегистрирован в системе и на него еще не выпущен сертификат. Поэтому для ЦР запрос является анонимным, фиксируется лишь тот факт, что составитель запроса владеет закрытым ключом и для соответствующего ему открытого ключа запрашивает выпустить заверенный в УЦ сертификат. Подобного рода запросы непосредственно не рекомендуются к обработке в ЦР.

2. Запрос сформирован как переиздание уже существующего, действующего на данный момент времени сертификата. Запрос упаковывается в оболочку CMC (RFC 2797). Техническая реализация позволяет сформировать такого вида запрос, не предоставляя пользователю возможности внести изменения в состав сертификата, причем контроль ведется как на абонентском пункте, так и на программном уровне в ЦР. Недостатком данного вида запросов является отсутствие контроля над числом самостоятельно выпущенных сертификатов пользователя.

3. Запрос сформирован на основе созданного ранее специального регистрационного сертификата (содержится специальное расширение, ограничивающее область применения только регистрационными процедурами). Запрос упаковывается в оболочку CMC (RFC 2797) с подписью на закрытом ключе регистрационного сертификата. Техническая реализация обеспечивает одноразовое использование регистрационных сертификатов.

4. Запрос создан самим пользователем и доставлен в службу Администраторов взаимодействия с пользователями (нет непосредственной доставки запроса в ЦР). Предварительно подобный запрос должен быть проверен на предмет истинности указанной информации и упакован в CMS за подписью Администратора взаимодействия с пользователями имеющего полномочия по выпуску сертификатов. Таким же способом могут быть приняты запросы и в режиме переиздания для собственных или регистрационных сертификатов.

Процесс взаимодействия ЦР и УЦ при обслуживании клиента оператором ЦР показан на рисунке 2.2.

информационный обмен аутентичность защита

2.3 Анализ подсистемы обмена зашифрованными сообщениями

Одним из ключевых компонентов системы защиты информации обособленного подразделения можно считать компонент шифрования. Данный компонент мы рассмотрим подробно и представим в виде модели.

Асимметричные алгоритмы позволяют легко обменяться ключами шифрования по открытому каналу связи, но работают слишком медленно.

Симметричные алгоритмы работают быстро, но для обмена ключами требуют наличия защищенного канала связи и нуждаются в частой смене ключей. Поэтому в современных криптосистемах используются сильные стороны обоих подходов.

Так, для шифрования сообщения используется симметричный алгоритм со случайным ключом шифрования, действующим только в пределах одного сеанса сеансовым ключом.

Чтобы впоследствии сообщение могло быть расшифровано, сеансовый ключ подвергается шифрованию асимметричным алгоритмом с использованием открытого ключа получателя сообщения. Зашифрованный таким образом сеансовый ключ сохраняется вместе с сообщением, образуя цифровой конверт. При необходимости цифровой конверт может содержать сеансовый ключ в нескольких экземплярах — зашифрованный открытыми ключами различных получателей.

Для создания электронной цифровой подписи необходимо вычислить хеш заданного файла и зашифровать этот «цифровой отпечаток сообщения» своим закрытым ключом — «подписать». Чтобы подпись впоследствии можно было проверить, необходимо указать, какой алгоритм хеширования использовался при ее создании. Листинг программы приведён в приложении А.

2.4 Анализ основных типов угроз информационной безопасности обособленного подразделения

На основе полученных сведений можно проанализировать основные типы угроз безопасности защищаемой информации обособленного подразделения на различных этапах информационного процесса.

На этапе хранения необработанных документов на бумажных носителях мы сталкиваемся с угрозой утери персональных данных. Документы могут быть потеряны либо украдены злоумышленником.

В центре регистрации:

— отсутствует система документооборота;

— не ведётся учёт документов, содержащих персональные данные;

— не предусмотрены меры ограничения доступа к документам.

За этапом хранения бумажной информации следует этап оцифровки имеющихся данных.

Этап оцифровки предполагает некоторую дополнительную обработку документов:

— присвоение заявлениям регистрационного номера;

— процесс регистрации заявителя в системе удостоверяющего центра посредством подачи заявки на регистрацию с внесёнными идентификационными данными;

— сканирование документов, именование сканов в соответствии с регистрационными номерами.

Далее, обработанная информация снова хранится, но теперь уже как в бумажном, так и в цифровом виде. Итак, этап хранения обработанной информации предполагает:

— хранение данных на бумажных носителях;

— хранение данных на жёстком диске.

На данном этапе актуальны следующие угрозы:

— угроза несанкционированного доступа к защищаемой информации, в том числе и с помощью программных закладок, вирусов;

— угроза копирования защищаемой информации;

— угроза модификации защищаемой информации;

— угроза утери, хищения защищаемой информации.

После этого избыточные данные на бумажных носителях — черновики, лишние копии заявлений, содержащие персональные данные — выбрасывают. Здесь мы сталкиваемся с тем, что образуется вещественный канал утечки информации и появляется угроза получения персональных данных злоумышленником, так как не предусмотрена технология уничтожения бумажных носителей.