Показано с 1 по 1 из 1.

Защита системы электронного документооборота

  1. #1
    Junior Member Репутация
    Регистрация
    01.12.2006
    Сообщений
    4
    Вес репутации
    37

    Защита системы электронного документооборота


    Это статья молодых авторов - Б.Б. Борисенко и К.А, Шадрина (Институт криптографии, связи и информатики), которые доверили мне ее как редактору и корректору. Она уже опубликована в журнале "Information Security" № 5-2006 (в сокращенном варианте) и на сайте www.itsec.ru, и теперь я с радостью публикую ее на форуме.


    Электронный документооборот (ЭДО) уже достаточно давно развит на территории РФ. С введением в 2002 г. ФЗ "Об электронной цифровой подписи" появились правовые условия, определяющие такого рода действия. В настоящее время, когда все больше государственных учреждений и коммерческих организаций переходят на ЭДО, встает вопрос о безопасности передачи важной, конфиденциальной и, тем более, секретной информации в системах ЭДО.

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

    Основным элементом УЦ является ЦС, к функциям которого относятся:
    - выработка и удаление сертификатов ЭЦП зарегистрированных пользователей;
    - хранение базы данных сертификатов и соответствующих им закрытых ключей ЭЦП;
    - обеспечение шифрования и целостности передаваемых данных между ЦС и ЦР с двусторонней аутентификацией по протоколу TLS;
    обеспечение уникальности открытого ключа и серийного номера в сертификатах;
    - организация первоначальной процедуры выработки закрытых ключей и сертификатов для компонентов УЦ.
    ЦР - компонент УЦ, отвечающий за регистрацию и хранение информации о пользователях, а также являющийся связующим звеном между пользователями системы и ЦС. Это единственная точка входа зарегистрированного пользователя в систему. К его функциям относятся:
    - создание и ведение базы данных зарегистрированных пользователей, содержащей личную информацию, сертификаты открытых ключей ЭЦП и сами открытые ключи ЭЦП;
    - обеспечение шифрования и целостности передаваемых данных с двусторонней аутентификацией по протоколу TLS;
    - обеспечение взаимодействия с ЦС: прием от АРМА запросов на выдачу и отзыв сертификатов ЭЦП и передача их в ЦС с подписью на ключе ЦР, прием и передача от ЦС сформированных сертификатов, проверка подписи ЦС принимаемой от него информации;
    - обеспечение доступа внешним приложениям через SOAP-интерфейс на базе HTTP(S);
    - обеспечение выполнения ЦР в автоматическом режиме таких задач, как организация процедуры проверки подлинности ЭЦП, оповещение пользователей по электронной почте об истечении срока действия сертификатов, оповещение пользователей по электронной почте о необходимости замены ключей, оповещение администратора безопасности о возникновении следующей из критических ситуаций: запрос на сертификат какого-либо пользователя не удовлетворен УЦ (администратор безопасности не обладает полномочиями привилегированного пользователя УЦ, его рабочая станция располагается в сети зарегистрированных пользователей для контроля безопасности);
    - формирование списка отозванных сертификатов (СОС).
    АРМА предназначен для организационно-технических мероприятий, то есть для поддержания работоспособности УЦ и внесения необходимых изменений в базы данных ЦР и ЦС. Он является консолью УЦ. Функции АРМА - обеспечение шифрования и целостности данных, передаваемых на ЦР с двусторонней аутентификацией по протоколу TLS, а также организация взаимодействия с ЦР, а именно:
    - создание запросов на создание, удаление пользователей, а также внесение изменений в существующие профили в ЦР;
    - создание запросов на выдачу и отзыв сертификатов передаваемых в ЦС через ЦР;
    - проверка состояния отправленных запросов.
    Для обеспечения работоспособности в каждом из трех основных компонентов УЦ вырабатываются и устанавливаются свои закрытые ключи и сертификаты, а также хранятся сертификаты двух остальных. Так, например, в ЦС вырабатывается и устанавливается по одному закрытому ключу и сертификату для выработки сертификатов пользователей системы и для защищенного взаимодействия с ЦР (для Web-сервера). В то же время в справочнике ЦС должны находиться личный сертификат сервера ЦР для формирования ЭЦП сообщений, передаваемых в ЦС от ЦР, а также сертификат АРМА для проверки ЭЦП сообщений, передаваемых от АРМА, и аутентификации при взаимодействии по сети ЦР и АРМА.

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

    Модели нарушителя
    Для создания защищенной системы на базе построенной модели необходимо исследовать последнюю на предмет уязвимостей и предложить способы ее модернизации и рекомендации по организации защиты. Анализ данной модели выявил следующие возможности расположения нарушителя, а именно (от более слабого к более сильному):
    - нарушитель находится в сети зарегистрированных пользователей, имеет возможность подключиться к Web-интерфейсу ЦР, но не является зарегистрированным пользователем УЦ;
    - нарушитель имеет возможность подключиться к Web-интерфейсу ЦР и обладает правами зарегистрированного пользователя УЦ;
    - нарушитель находится в изолированной сети УЦ;
    - нарушитель захватил АРМА;
    - нарушитель получил доступ к ЦР;
    - нарушитель завладел ЦС(см. схему расположения перечисленных нарушителей)

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

    Нарушитель имеет доступ к Web-интерфейсу центра регистрации (ЦР)
    Самый слабый случай атаки - когда нарушитель имеет доступ к Web-интерфейсу ЦР, но не входит в круг лиц, зарегистрированных в УЦ.
    Наиболее проста в реализации атака типа "отказ в обслуживании". Для этого злоумышленник может проводить как атаки на конкретного пользователя, так и на всю сеть (например, SYN-flood по всем IP-адресам сети). Но от атак такого рода на всю систему легко защититься, ограничив число соединений с одним IP-адресом либо ограничив число одновременно пропускаемых соединений на граничном МСЭ, соответствующим образом настроив его.
    Также нарушитель имеет возможность проводить атаки из категории "раскрытие параметров". Если злоумышленник подключился к сети, то существует потенциальная опасность того, что он сможет перехватить пакеты в сети и из информации, содержащейся в них, определить маску сети, пару IP-MAC-адресов сети, информацию о рабочих станциях.
    Отсюда вытекает возможность проведения атаки типа "нарушение целостности", например используя уязвимости ОС или прикладного ПО. Последние две разновидности атак на всю систему в данном случае невозможны, так как у злоумышленника есть лишь HTTPS доступ к Web-интерфейсу ЦР, причем на пути между ним и ЦР стоит аппаратный МСЭ (достаточно запретить выполнение и изменение приложений на Web-сервере ЦР у подключающихся пользователей).
    Для защиты от данных атак администратору безопасности необходимо постоянно отслеживать новые подключения к сети и просматривать сетевой трафик. Кроме того, сеть следует конфигурировать так, чтобы злоумышленник не имел возможности перехватывать пакеты (например, посредством коммутаторов с заблокированным зеркальным портом).
    Если нарушитель каким-либо образом узнал MAC-адрес и IP-адрес пользователя сети УЦ и вошел с его параметрами в сеть, то у него не должно быть возможности осуществлять какие-либо действия от имени пользователя. Как следствие, в сети должна существовать система аутентификации и авторизации пользователей, чтобы нарушитель, узнавший физические параметры ЭВМ в сети, не смог воспользоваться ими. Аутентификацию можно проводить при помощи ЭЦП. При этом следует запретить хранение закрытого ключа ЭЦП в реестре рабочей станции и снабдить пользователей ключевыми носителями (например, брелоками Touch Memory), а обращение к ним защитить паролем. В случае утери пользователем такового организовать, помимо выдачи резервного ключа, смену ЭЦП данного пользователя, а его предыдущую подпись поместить в СОС. Таким образом, даже завладев ключевым носителем, нарушитель будет вынужден столкнуться с проблемой подбора пароля.

    Нарушитель является зарегистрированным пользователем
    Рассмотрим ситуацию, в которой нарушитель обладает полномочиями зарегистрированного пользователя в сети и имеет доступ к его ресурсам, то есть нарушитель - зарегистрированный пользователь, прошедший процедуры аутентификации и авторизации. В данном случае нарушитель обладает всеми доступными обычному пользователю возможностями: обменом подписанными сообщениями с другими зарегистрированными пользователями, возможностью подтверждать достоверность ЭЦП, посылать запросы на выдачу и отзыв сертификата ключа подписи, а также вносить изменения в уже существующий профиль.
    Из категории атак типа "нарушение целостности" пользователь может создать запросы на создание и отзыв сертификатов или изменить параметры существующих. Серьезной угрозой в данном случае является возможность использования нарушителем ЭЦП зарегистрированного пользователя.
    Злоумышленник зарегистрирован в ЦР, и его запросы будут пропускаться в ЦС. Поэтому для защиты от возможных атак на УЦ следует ограничить число одновременных подключений с одного IP-адреса, запретить соединение пользователей с каким-либо компонентом, кроме ЦР, а к ЦР разрешить лишь доступ на чтение к Web-интерфейсу по протоколу HTTPS.
    Чтобы свести возможности злоумышленника, завладевшего рабочей станцией пользователя, к минимуму, необходимо в УЦ запретить автоматическую обработку запросов на выдачу, отзыв или изменение сертификатов с компьютеров пользователей системы. Данные манипуляции с сертификатами следует осуществлять непосредственно с компонента УЦ - АРМА.

    Нарушитель находится в выделенной сети УЦ
    Выше были рассмотрены ситуации, в которых нарушитель проводит атаки из внешней сети зарегистрированных пользователей. Перейдем к рассмотрению случаев, когда злоумышленник находится внутри изолированной сети удостоверяющего центра, то есть имеет физическое соединение со всеми компонентами УЦ и ему уже не препятствует граничный МСЭ центра.
    Так, к примеру, узнав пару IP-MAC-адресов ЦР, злоумышленник может отправлять пакеты от имени ЦР в ЦС, предварительно проведя на ЦР атаку типа "отказ в обслуживании" и выставив его сетевые параметры у себя на рабочей станции. Кроме того, нарушитель может отправлять запрос на регистрацию пользователя от АРМА в ЦР.
    В данной модели злоумышленник может конфигурировать пакеты и изменять адрес отправителя, указывая адрес компонентов системы (например, отправлять от имени АРМА в ЦР). Для защиты от таких атак все элементы УЦ должны иметь ЭЦП, что позволит идентифицировать получаемые пакеты и защититься от возможных фальсифицированных пакетов.
    Нарушитель не должен иметь возможности зарегистрироваться в ЦР, следовательно, ЦР необходимо настроить таким образом, чтобы он принимал запросы на регистрацию нового пользователя только от АРМА, подписанные соответствующим ключом, а все остальные не обрабатывал, делая соответствующую запись в журнале о появлении таковых.
    В ЦС должна храниться база данных сертификатов открытых ключей ЭЦП и закрытые ключи ЭЦП только зарегистрированных пользователей. Таким образом, прежде чем попасть в ЦС, запрос сначала должен пройти проверку на соответствие в ЦР. В случае отправки от зарегистрированного пользователя он передается в ЦС, иначе не пропускается. Следовательно, в ЦС попадают только те запросы, которые прошли ЦР, отсюда получаем целесообразность установки аппаратного МСЭ перед ЦС, пропускающего лишь пакеты от ЦР для защиты от потенциальных атак со стороны других компонентов УЦ.

    Нарушитель захватил АРМА
    Рассмотрим, на какие элементы УЦ непосредственно могут быть проведены атаки типа "отказ в обслуживании". Потенциально им может быть подвержен ЦР. В то же время успешная атака, проведенная на ЦР, повлияет на работоспособность всей системы и будет являться косвенной атакой данного типа на рабочие станции зарегистрированных пользователей УЦ. Кроме того, пока ЦР недоступен, подменяются сетевые настройки АРМА на ЦР. Если МСЭ пропускает пакеты от нарушителя к ЦСЮ, то можно реализовывать атаки на ЦС.
    Злоумышленник может формировать запросы на регистрацию новых пользователей и удаление или модификацию уже существующих профилей, ЦР сделает соответствующие изменения в своей базе данных. Помимо того, нарушитель может сформировать запрос на создание или отзыв сертификатов, а также скопировать базу данных зарегистрированных пользователей ЦР и базу данных сертификатов этих пользователей ЦС.
    Целесообразным является разделение полномочий у пользователей УЦ. Предполагается наличие двух пользователей УЦ: администратора УЦ и оператора УЦ. Администратор УЦ отвечает за первоначальную настройку ПО УЦ, создание баз данных ЦР и ЦС, имеет право на изменение или удаление профилей зарегистрированных пользователей (создание соответствующего запроса), а также на отзыв действующих сертификатов (помещение их в СОС) и публикацию СОС. В случае сбоя в системе администратор УЦ обязан восстановить работоспособность, используя резервные копии. Оператор УЦ имеет право на создание пользователей (создание запроса на регистрацию нового пользователя) и выдачу сертификатов пользователям (создание запроса на выдачу сертификата). Оба пользователя УЦ не имеют права на установку и модификацию ПО. Для затруднения просмотра баз данных ЦР и ЦС должны быть запрещены команды вывода на экран всей базы данных (например, SELECT * from USER, SELECT * from SERT).

    Нарушитель захватил ЦР
    В данном случае нарушитель завладел связующим звеном между пользователями системы ЭЦП и УЦ и обладает таким образом огромными полномочиями. В его власти физическое отключение от сети ЦР, блокировка ЦС и тем самым приостановление деятельности УЦ. Как следствие, все манипуляции с ЭЦП в это время будут неликвидны, также будет невозможно подтвердить ту или иную ЭЦП.
    Реализация атаки типа "раскрытие параметров" не вызывает серьезных затруднений. Помимо параметров самого ЦР в нем прописаны соответствующие сетевые настройки АРМА и ЦС.
    Что касается атак типа "нарушение целостности", можно формировать запросы к ЦС напрямую (по сертификатам). К профилям пользователей можно обращаться непосредственно и вносить изменения в базу данных, в том числе удалить ее физически. Кроме деструктивных действий нарушитель может незаметно наблюдать за происходящим в системе или скопировать базу данных зарегистрированных пользователей УЦ.
    В целях повышения безопасности в ЦР должно быть реализовано разграничение полномочий, а именно: добавлены две роли УЦ - оператор ЦР и администратор ЦР. У обоих пользователей должны отсутствовать права на установку или модификацию ПО. Причем у оператора есть все необходимые полномочия для нормального функционирования ЦР, то есть права подписывать запросы на выпуск сертификатов, добавлять новые, обрабатывать запросы пользователей на подтверждение ЭЦП и т.д. В то же время у него отсутствуют права удаления базы данных пользователей, создания новой таблицы, вывода таблицы полностью на экран или периферийное устройство, изменения и просмотра реестра сертификатов и секретных ключей ЦР, которыми обладает администратор ЦР.

    Нарушитель захватил ЦС
    В заключение рассмотрим наиболее опасный для всей системы случай: нарушитель завладел основным элементом УЦ и у него под контролем находится база данных сертификатов открытых ключей ЭЦП зарегистрированных пользователей, а также секретных ключей ЭЦП, соответствующих этим сертификатам.
    Наиболее простая атака типа "отказ в обслуживании" - изменение сетевых настроек или выключение сетевого интерфейса (наиболее тривиально отключение питания) - приведет к остановке всей системы ЭЦП. К этому же приведет удаление базы данных сертификатов открытых ключей и соответствующих им секретных ключей.
    Нарушитель может узнать состав самого ЦС, а также сетевые параметры ЦР и, возможно, версию ОС и ПО ЦР.
    Наиболее опасны атаки типа "нарушение целостности". Злоумышленник имеет доступ к базе данных ЦС, т.е. может вносить изменения в нее - добавлять сертификаты пользователей или помечать их как отозванные. Помимо того, скопировав базу, он может проводить действия от имени пользователей ЭЦП (при подключении к сети зарегистрированных пользователей).
    В ЦС должно быть введено ролевое разграничение полномочий посредством введения двух ролей УЦ: оператора ЦС и администратора ЦС. Права ролей не должны пересекаться. Оператор УЦ обладает правом создания новых учетных записей, но у него отсутствует право их изменять. Администратор ЦС обладает правами на создание и удаление баз данных, у него отсутствуют права на добавление новых записей в базы данных сертификатов открытых ключей ЭЦП и соответствующих им закрытых ключей зарегистрированных пользователей УЦ, но есть привилегия изменять их. У обеих ролей должно отсутствовать право на установку и модификацию ПО, а также права на вывод содержимого баз данных.
    Само собой, кроме перечисленных рекомендаций необходимо соблюдение технических и административных мер безопасности, таких как размещение ЦР и ЦС в специально оборудованных категорированных помещениях с соответствующей защитой и наблюдением, отсутствие в ЦР и ЦС периферийных устройств (в том числе видеоадаптера), невозможность загрузки со сменного носителя, использование антивирусных средств, системы аудита и т.п. Только тогда можно с уверенностью считать, что система электронного документооборота в вашей организации действительно защищена.

    www.itsec.ru
    Изображения Изображения
    • Тип файла: gif sheme.gif (19.8 Кб, 56 просмотров)

  2. Реклама
     

Похожие темы

  1. Ответов: 1
    Последнее сообщение: 30.01.2011, 09:00
  2. Завершено тестирование системы SecureLogin и электронного идентификатора Рутокен
    От Сyberwriter в разделе Новости программного обеспечения
    Ответов: 0
    Последнее сообщение: 08.02.2010, 18:40
  3. Ответов: 5
    Последнее сообщение: 31.01.2010, 11:17
  4. Мягкая защита от электронного мусора
    От SDA в разделе Антиспам
    Ответов: 1
    Последнее сообщение: 21.03.2008, 16:42

Свернуть/Развернуть Ваши права в разделе

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •  
Page generated in 0.00282 seconds with 18 queries