\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