• 
  USB-ключи, смарт-карты, iButton;
  
• 
  одноразовый код в виде СМС или email;
  
• 
  генератор паролей (технология SecurID);
  
• 
  биометрические данные и т. д.
  

Автоматизированные системы защиты

Это специализированные системы обеспечения безопасности баз данных, представляющие собой решения DAM (Database Activity Monitoring) и DBF (Database Firewall). Применяются, когда уже реализованы вышеописанные меры защиты баз данных.

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

DAM (Database Activity Monitoring):

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

DBF (Database Firewall) — это сетевой шлюз, смежное с DAM решение, которое может работать как в проактивном режиме, так и в пассивном с копией трафика.

Основные функции DBF (Database Firewall):

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

4 Защита ПК от несанкционированного доступа

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

• 
  подавляющая часть ПК располагается непосредственно в ра­бочих комнатах специалистов, что создает благоприятные условия для доступа к ним посторонних лиц;
  
• 
  многие ПК служат коллективным средством обработки ин­формации, что обезличивает ответственность, в том числе и за за­щиту информации;
  
• 
  современные  ПК оснащены  несъемными  накопителями на ЖМД очень большой емкости, причем информация на них сохра­няется даже в обесточенном состоянии;
  
• 
  накопители на ГМД производятся в таком массовом количе­стве, что уже используются для распространения информации так же, как и бумажные носители;
  
• 
  первоначально   ПК   создавались   именно   как   персональное средство  автоматизации   обработки   информации,   а   потому  и  не оснащались специально средствами защиты от НСД.
  

---

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

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

5 Администрирование базы данных

5.1 Управление данными в базах данных

Непосредственное управление данными во внешней памяти. Эта функция включает обеспечение необходимых структур внешней памяти как для хранения непосредственных данных, входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, а если использует, то как организованы в ней файлы. В частности, СУБД поддерживает собственную систему именования объектов БД (это очень важно, поскольку имена объектов базы данных соответствуют именам объектов предметной области). Существует множество различных способов организации внешней памяти баз данных. Как и все решения, принимаемые при организации баз данных, конкретные методы организации внешней памяти необходимо выбирать в тесной связи со всеми остальными решениями. Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно превышает доступный объем оперативной памяти. Понятно, если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Единственным же способом реального увеличения этой скорости является буферизация данных в оперативной памяти. И даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов. При управлении буферами основной памяти приходится разрабатывать и применять согласованные алгоритмы буферизации, журнализации и синхронизации. Заметим, что существует отдельное направление СУБД, которые ориентированы на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в предвидимом будущем объем оперативной памяти компьютеров сможет быть настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.

---

5.2 Управление транзакциями.

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

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

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

---

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

Журнал – это особая часть БД, недоступная пользователям СУБД и поддерживаемая особо тщательно (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), а порой запись соответствует минимальной внутренней операции модификации страницы внешней памяти. В некоторых системах одновременно используются оба подхода. Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log – WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя. Самая простая ситуация восстановления – индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции выполнением обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу). При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти.

---

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия – это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. К сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после конца восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.


6 Определение понятий и признаков программы для ЭВМ и базы данных.
В законах Российской Федерации «О правовой охране программ для электронных вычислительных машин и баз данных» от 23 сентября 1992 года «Об авторском праве и смежных правах» от 9 июля 1993 года программа для ЭВМ определяется как «объективная форма представления совокупности данных и команд, предназначенных для функционирования электронных вычислительных машин и других компьютерных устройств с целью получения определенного результата. Под программой для ЭВМ подразумеваются также подготовительные материалы, полученные в ходе ее разработки, и порождаемые ею аудиовизуальные отображения» (ст. 1 и 4 соответственно). Такое определение программы для ЭВМ характерно для законодательств большинства стран мира.

Согласно статье 1261 четвертой части ГК РФ авторские права на все виды программ для ЭВМ (в том числе на операционные системы и программные комплексы), которые могут быть выражены на любом языке и в любой форме, включая исходный текст и объектный код, охраняются так же, как авторские права на произведения литературы. Программой для ЭВМ является представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата, включая подготовительные материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею аудиовизуальные отображения.

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

---

Смотрите также файлы

• Ф. И. О. руководителя, должность Руководитель практики от оспо фио панарина Анна Игоревна.docx

• Ответ Пателланы сырты шеті.docx

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

• 1 Корпоративные стандарты обслуживания клиентов (пао сбербанк, ао гутабанк).docx

• Федеральное агентство.docx