Файл: А ттестационный лист.docx

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

Базой для разработки положения становятся:

• 
  международные и национальные стандарты – ISO, ГОСТы;
  
• 
  регламентирующие документы ФСТЭК РФ, содержащие организационные, программные, технические требования, которые должны быть реализованы в целях обеспечения безопасности БД.
  

В инструкция по безопасности БД должны быть следующие разделы:

1. 
   нормативная подоснова;
   
2. 
   категории информации;
   
3. 
   управление доступом;
   
4. 
   безопасность удаленного доступа;
   
5. 
   защита от внешних атак;
   
6. 
   технические требования;
   
7. 
   обязанности пользователей;
   
8. 
   ответственность за невыполнение норм политики.
   

1. Нормативно-правовая основа

Большинство нормативных требований, которые должны быть учтены в инструкции, включены в законы «О персональных данных» и «Об информации». Если в БД обрабатываются персональные данные, то нормативные требования можно найти в разъяснениях и рекомендациях ФСТЭК. Они же будут актуальны, если компания имеет доступ к государственной тайне.

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

2. Классификация информации

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

Выделяют четыре группы конфиденциальности:

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

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

3. Регламентация доступа

После того как информация структурирована начинается создание модели ограниченного доступа на организационном, программном и техническом уровнях. Рекомендации по дифференциации доступа можно найти в руководящих документах ФСТЭК РФ.

---

В инструкции обязательно прописывают:

• 
  процедуры идентификации и аутентификации;
  
• 
  категории пользователей: управленческий персонал, сотрудники СБ, сотрудники IТ-подразделений и системные администраторы, работающие с выделенными для них каталогами БД, прочие пользователи;
  
• 
  модель управления дифференцированным доступом – на основе меток или ролей.
  

4. Безопасность удаленного доступа

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

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

Если доступ однозначно разрешен, в политике необходимо описать:

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

5. Защита от внешних атак

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

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

Методы снижения вероятности реализации угроз:

---

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

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

• 
  антивирусы;
  
• 
  межсетевые экраны;
  
• 
  средства аудита действий пользователей;
  
• 
  средства доверенной загрузки;
  
• 
  средства криптографической защиты.
  

6. Технические требования

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

7. Обязанности пользователей

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

Необходимо регламентировать:

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

8. Ответственность за невыполнение норм политики

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

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

---

Разработка элементов физической схемы и словари базы данных

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

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

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

Таблица 1 пример логической и физической модели данных

Сущность	Таблица
Студент	student
Преподаватель	prepod
Группа	group
Вариант задания	variant
Задание студента	zadanie
Тема задания	theme
История	history
Материал	material
План работы	plan
Параметр	parameters

В разработанной базе данных для предприятия имеются следующие модели:



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

---

Ниже представлены все словари данных таблиц:



Восстановление данных после сбоев и повреждений

Для восстановления после сбоя базы данных системы управления базами данных используют ряд методов управления восстановлением. Рассмотрим различные подходы к восстановлению базы данных.

Типичные стратегии восстановления базы данных:

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

Восстановление после сбоя питания

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

В случае режима немедленного обновления менеджер восстановления выполняет следующие действия:

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

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

Восстановление после сбоя диска

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

---