Добавил восьмую лекциюHEADmaster

1 files changed, 425 insertions, 0 deletions

diff --git a/sections/section8.tex b/sections/section8.tex
new file mode 100644
index 0000000..462c1d2
--- /dev/null
+++ b/sections/section8.tex
@@ -0,0 +1,425 @@
+\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
\ No newline at end of file