path: root/sections/section8.tex

\section{Защита автоматизированных информационных систем}
\newrefsection

\subsection{Требования к подсистемам защиты информации в АС}

Автоматизированные системы, хранящие, обрабатывающие, передающие информацию
могут основываться на самых различных технических средствах. Поэтому, в
отношении вопросов обеспечения безопасности к ним сформулированы самые общие
требования, позволяющие сформировать комплекс программно-технических средств и
процедурных решений по защите информации от НСД. Система защиты информации в АС
представляется условно состоящей из следующих четырех подсистем:
\begin{itemize}
  \item управления доступом;
  \item регистрации и учета;
  \item криптографической;
  \item обеспечения целостности.
\end{itemize}

В зависимости от класса АС в каждой подсистеме количество и детализация
требований возрастает. Наибольший объём требований к обеспечению безопасности АС
можно представить следующим образом.

\subsubsection{Требования к подсистеме управления доступом}

\begin{enumerate}
  \item
    должна осуществляться проверка подлинности субъектов доступа при входе в
    систему по паролю условно-постоянного действия, длиной не менее 6 -- 8
    буквенно-цифровых символов,
  \item
    должна осуществляться идентификация всех устройств ввода-вывода информации,
  \item
    должна осуществляться идентификация всех информационных ресурсов системы,
  \item
    на основании идентификации субъектов, устройств и информационных ресурсов
    выполняется управление доступом по мандатному или дискреционному принципам.
\end{enumerate}

Аутентификация субъекта может быть однофакторной и многофакторной в зависимости
от количества различных способов аутентификации, используемых при регистрации
объекта в системе. Различают следующие способы аутентификации:
\begin{itemize}
  \item
    на основании того, что субъект знает (пароль),
  \item
    на основании того, что субъект имеет (электронный ключ),
  \item
    на основании того, что субъект собой представляет (папиллярный узор,
    сетчатка глаза).
\end{itemize}

\subsubsection{Требования к подсистеме регистрации и учета}

\begin{enumerate}
  \item
    должна осуществляться регистрация (с указанием субъекта и времени):
    \begin{itemize}
      \item
        входа (выхода) пользователя в систему,
      \item
        факта и контекста неуспешных попыток,
      \item
        факта, содержания, объема и уровня конфиденциальности документов,
        выводимых через устройства твердой копии,
      \item
        доступа к узлам сети,
      \item
        доступа к защищаемым файлам и каталогам,
      \item
        программ, осуществляющих доступ к защищаемым ресурсам с указанием вида
        операции и результата,
      \item
        должна осуществляться регистрация изменений полномочий субъектов доступа
        и статуса объектов доступа,
      \item
        создаваемых объектов,
    \end{itemize}
  \item
    должна проводиться маркировка носителей информации и их учет с записью в
    журналах регистрации (создание, выдача),
  \item
    должно осуществляться очистка использованных областей памяти (с различной
    кратностью перезаписи),
  \item
    должна осуществляться регистрация попыток нарушения защиты.
\end{enumerate}

\subsubsection{Требования к подсистеме обеспечения целостности}

\begin{enumerate}
  \item
    должна обеспечиваться  относительная неизменность программной среды АС,
    контролем при загрузке по наличию имен, контрольных сумм компонент СЗИ,
    отсутствием в АС средств разработки и отладки программ;
  \item
    должна осуществляться физическая охрана СВТ (контроль доступа в помещения АС
    посторонних лиц, наличие надежных препятствий для несанкционированного
    проникновения в помещения АС и хранилище носителей информации, особенно в
    нерабочее время);
  \item
    должно проводиться периодическое тестирование функций СЗИ НСД при изменении
    программной среды и персонала АС с помощью тест-программ, имитирующих
    попытки НСД;
  \item
    должны быть в наличии средства восстановления СЗИ НСД, предусматривающие
    ведение двух копий программных средств СЗИ НСД и их периодическое обновление
    и контроль работоспособности;
  \item
    за состоянием целостности системы должен следить специально выделенный
    сотрудник;
  \item
    СЗИ должны быть сертифицированы.
\end{enumerate}

Требования к криптографической подсистеме:

\begin{enumerate}
  \item
    должно осуществляться шифрование конфиденциальной информации, записываемой
    на совместно используемые различными субъектами доступа (разделяемые)
    носители данных, в каналах связи, а также на съемные носители данных;
  \item
    доступ субъектов к операциям шифрования и криптографическим ключам должен
    дополнительно контролироваться подсистемой управления доступом;
  \item
    доступ субъектов к операциям шифрования и к соответствующим
    криптографическим ключам должен дополнительно контролироваться посредством
    подсистемы управления доступом,
  \item
    СКЗИ должны быть сертифицированы.
\end{enumerate}


\subsection{Требования к защищенности вычислительных систем и комплексов}

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

Итак при описании защищенности СВТ:
\begin{itemize}
  \item
    уточняются требования к управлению доступом: Для каждой пары (субъект –
    объект) задается явное и недвусмысленное перечисление допустимых типов
    доступа. При этом допускается изменение субъектов, объектов и правил
    разграничения доступа. Для мандатного доступа вводится требование учета в
    матрице доступа в качестве объектов отчуждаемые носители информации.
  \item
    уточняются требования к очистке памяти: к каким типам и областям памяти
    должен предотвращаться доступ, а какие области должны вычищаться.
  \item
    вводится новое понятие: гарантии проектирования, которые требуют учитывать
    использование механизмов защиты уже на этапе проектирования системы, в том
    числе учет правил разграничения доступа, контроля модификации системы.
  \item
    вводится понятие контроля дистрибуции т.е. соответствия поставляемого
    образца сертифицированному.
  \item
    вводится новое понятие изоляции исполняемых модулей, которое устанавливает
    требование защиты областей функционирования процессов друг от друга, что бы
    они не могли косвенно влиять один на другой.
  \item
    уточняются требования к регистрируемым событиям и параметрам
    взаимодействующих объектов и субъектов, а так же впервые обсуждается вопрос
    доступа к журналам: запрет простым пользователям и регистрация доступа
    администратора.
  \item
    уточняется, что тестированию, которое, как мы знаем относится к подсистеме
    обеспечения целостности, подвергаются все критичные функции системы,
    отвечающие за реализацию параметров защиты, например функции контроля
    разграничения доступа, аутентификации, изоляции процессов, очистки памяти,
    регистрацию событий, защиты от НСД,
  \item
    уточняются требования к документированию средств обработки и защиты
    информации (конструкторская, пользовательская, тестовая), а именно, какие
    вопросы обязательно должны быть в ней отражены:
  \item
    порядок установки,
  \item
    описание интерфейса,
  \item
    описание принципов работы,
  \item
    контролируемые функции,
  \item
    порядок проведения испытаний,
  \item
    механизмов защиты.
\end{itemize}

Защита межкомпьютерного взаимодействия строится на понятии межсетевых экранов.

Межсетевые экраны, как и обычные средства СЗИ должны удовлетворять требованиям
защищенности, предъявляемым к СВТ, однако функция управления доступом у них
специфична. Требования управления доступом для МЭ экранов выглядят как
требования выполнять фильтрацию передаваемых данных:
\begin{itemize}
  \item на уровне сетевых адресов,
  \item на уровне пакетов сетевых протоколов и содержимого их полей,
  \item на уровне адресов прикладных протоколов.
\end{itemize}

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

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

Устанавливается четыре уровня контроля отсутствия недекларированных
возможностей:

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

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

Мероприятия по защите от недекларированных возможностей:
\begin{enumerate}
  \item
    Контроль состава и содержания документации должен предусматривать анализ
    представленных описаний программ (контрольные суммы файлов, логические связи
    между программами, описание среды функционирования), описаний применения
    (функциональное назначение, ограничения применения) и исходных текстов
    программ;
  \item
    Статический анализ исходных текстов программ должен включать:
    \begin{itemize}
      \item
        контроль полноты и отсутствия избыточности исходных текстов ПО на уровне
        файлов;
      \item
        контроль соответствия исходных текстов ПО его объектному (загрузочному)
        коду;
      \item
        контроль связей функциональных объектов (модулей, процедур, функций) по
        управлению;
      \item
        контроль связей функциональных объектов (модулей, процедур, функций) по
        информации;
      \item
        контроль информационных объектов различных типов (например, локальных
        переменных, глобальных переменных, внешних переменных и т.п.);
      \item
        формирование перечня маршрутов выполнения функциональных объектов
        (процедур, функций).
    \end{itemize}
  \item
    Динамический анализ   исходных текстов программ должен включать следующие
    технологические операции:
    \begin{itemize}
      \item
        контроль выполнения функциональных объектов (процедур, функций);
      \item
        сопоставление фактических маршрутов выполнения функциональных объектов
        (процедур, функций) и маршрутов, построенных в процессе проведения
        статического анализа.
    \end{itemize}

    Фактический маршрут выполнения функциональных объектов – последовательность
    фактически выполняемых функциональных объектов при определённых условиях
    (входных данных);
  \item Составление отчета о проведенных исследованиях и испытаниях.
\end{enumerate}


\subsection{Использование электронной подписи, как разновидности СКЗИ}

Согласно данного нормативного акта существует три вида электронных подписей:
\begin{enumerate}
  \item
    простая электронная подпись, которая посредством использования кодов,
    паролей или иных средств подтверждает факт формирования электронной подписи
    определенным лицом.

  \item
    неквалифицированная электронная подпись, которая:
    \begin{enumerate}
      \item
        получена в результате криптографического преобразования информации с
        использованием ключа электронной подписи;
      \item
        позволяет определить лицо, подписавшее электронный документ;
      \item
        позволяет обнаружить факт внесения изменений в электронный документ
        после момента его подписания;
      \item
        создается с использованием средств электронной подписи.
    \end{enumerate}

  \item
    квалифицированная электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:
    \begin{enumerate}
      \item
        ключ проверки электронной подписи указан в квалифицированном
        сертификате;
      \item
        для создания и проверки электронной подписи используются средства
        электронной подписи, получившие подтверждение соответствия требованиям,
        установленным в соответствии с настоящим Федеральным законом.
    \end{enumerate}
\end{enumerate}

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

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

В системе реализации механизма ЭП предусмотрено два ключа: ключ ЭП и ключ
проверки ЭП. Их два, потому что для проверки подлинности используется
асимметричное шифрование, в результате которого для зашифровки объекта
используется открытый ключ, а для его расшифровки – секретный или закрытый ключ.

В соответствии с алгоритмом использования ЭП, ключ ЭП – это секретный ключ, а
ключ проверки ЭП – открытый.

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

Простая и неквалифицированная ЭП не требует создания сертификата ключа проверки
ЭП, хотя и предусматривает его существование. Для квалифицированной подписи это
обязательно. Кроме того, квалифицированная ЭП создается и используется только на
средствах ЭП, прошедших сертификацию ФСБ и ФСТЭК.

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

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

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

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

Создает (выпускает) сертификаты удостоверяющий центр (УЦ).

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

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

Взаимодействие пользователя с удостоверяющим центром происходит следующим
образом:
\begin{itemize}
  \item
    Пользователь создает ключевую пару (открытый и закрытый ключи).
  \item
    Пользователь отправляет в удостоверяющий центр запрос на сертификат, в
    который включает открытый ключ и всю необходимую информацию о себе и о
    ключах. Набор необходимых сведений определяется регламентом удостоверяющего
    центра, но всегда необходимо указывать имя владельца, назначение ключей,
    дату создания.
  \item
    Удостоверяющий центр получает запрос и проверяет его подлинность. Если
    результат проверки запроса положительный, удостоверяющий центр создает
    сертификат на открытый ключ, подписывает его, заносит в свою базу данных и
    отправляет пользователю.
  \item
    Пользователь получает сертификат и устанавливает его у себя в системе.
\end{itemize}

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

Понятие «Проверка подписи» подразумевает проверку соответствия подписи
документу, который подписан этой подписью. Если подпись соответствует документу,
документ считается подлинным и корректным.

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

Для этого проводится проверка сертификата на этот ключ. Понятие «проверка
сертификата» означает проверку подписи под этим сертификатом. Подпись под
сертификатом проверяется на открытом ключе того, кто создал и подписал
сертификат — т.е. на открытом ключе удостоверяющего центра.

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

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

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

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

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

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

\printbibliography