Защита информации в субд реферат

Обновлено: 05.07.2024

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

Ключевые слова

Текст научной работы

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

К основным средствам защиты информации относят следующие:

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

Защита БД производится на двух уровнях:

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

Безопасная система авторизации и регистрации является одним из важнейших элементов при создании проекта. Один из возможных способов — это создание системы регистрации с помощью PHP и MySQL.

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

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

Обзор учетных записей

Рисунок 2. Обзор учетных записей

Кроме того, также можно ограничить доступ не только к самой системе управления базами данных, но и отдельно к базам данных, к таблицам базы данных, к записям конкретных таблиц и даже к значениям полей таблиц или записей. Стоит отметить, что встроенные функции шифрования присутствуют далеко не во всех СУБД. Следовательно, универсальным данный метод назвать нельзя. Данная СУБД предлагает два однотипных набора функций шифрования, в одном из которых реализован алгоритм DES, а в другом — AES. Кроме того, в MySQL реализовано несколько алгоритмов хэширования. Набор криптографических функций данной СУБД выглядит так:

Зашифрование данных алгоритмом AES.

Расшифрование данных алгоритмом AES.

Зашифрование данных алгоритмом DES.

Расшифрование данных алгоритмом DES.

Зашифрование данных функцией crypt().

Хэширование данных алгоритмом MD5.

Хэширование данных алгоритмом SHA-1.

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

  1. Макарова Н.В.
  2. Матвеева А.Е.
  3. Суржикова О.В.

Список литературы

Цитировать

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

Содержание работы

1. Введение 2
2. Идентификация и проверка подлинности пользователей 3
3. Управление доступом 3
3.1. Основные понятия 3
3.2. Основные категории пользователей 4
3.3. Виды привилегий 5
3.3.1. Привилегии безопасности 5
3.3.2. Привилегии доступа 6
3.3.3. Получение информации о привилегиях 9
3.4. Использование представлений для управления доступом 9
3.5. Иерархия прав доступа 10
3.6. Метки безопасности и принудительный контроль доступа 12
4. Поддержание целостности данных в СУБД 14
4.1. Ограничения 14
4.2. Правила 16
5. Средства поддержания высокой готовности 17
5.1. Кластерная организация сервера баз данных 17
5.1.1. Аппаратная организация SPARCcluster PDB Server 17
5.1.2. Программная организация SPARCcluster PDB Server 18
5.1.3. Нейтрализация отказа узла 19
5.2. Тиражирование данных 20
6. Угрозы, специфичные для СУБД 22
6.1. Получение информации путем логических выводов 22
6.2. Агрегирование данных 25
6.3. Покушения на высокую готовность (доступность) 26
7. Защита коммуникаций между сервером и клиентами 27
8. Заключение 28
9. Литература 28

Файлы: 1 файл

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

Федеральное государственное автономное

высшего профессионального образования

Институт педагогики психологии и социологии

Кафедра педагогики профессионального обучения

по Базам данных и управлением ими

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

Преподаватель Кублицкая Ю.Г.

Студент ФО10-01 091012069 Горяев Д.А.

2. Идентификация и проверка подлинности пользователей 3

3. Управление доступом 3

3.1. Основные понятия 3

3.2. Основные категории пользователей 4

3.3. Виды привилегий 5

3.3.1. Привилегии безопасности 5

3.3.2. Привилегии доступа 6

3.3.3. Получение информации о привилегиях 9

3.4. Использование представлений для управления доступом 9

3.5. Иерархия прав доступа 10

3.6. Метки безопасности и принудительный контроль доступа 12

4. Поддержание целостности данных в СУБД 14

4.1. Ограничения 14

5. Средства поддержания высокой готовности 17

5.1. Кластерная организация сервера баз данных 17

5.1.1. Аппаратная организация SPARCcluster PDB Server 17

5.1.2. Программная организация SPARCcluster PDB Server 18

5.1.3. Нейтрализация отказа узла 19

5.2. Тиражирование данных 20

6. Угрозы, специфичные для СУБД 22

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

6.2. Агрегирование данных 25

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

7. Защита коммуникаций между сервером и клиентами 27

8. Заключение 28

9. Литература 28

Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом хранения больших массивов информации. Сколько-нибудь развитые информационные приложения полагаются не на файловые структуры операционных систем, а на многопользовательские СУБД, выполненные в технологии клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в первую очередь их серверных компонентов, приобретает решающее значение для безопасности организации в целом.
Для СУБД важны все три основных аспекта информационной безопасности - конфиденциальность, целостность и доступность [6]. Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в "Критериях оценки надежных компьютерных систем". В принципе некоторые СУБД предлагают дополнения, характерные для класса B1, однако практическое применение подобных дополнений имеет смысл, только если все компоненты информационной структуры организации соответствуют категории безопасности B. Достичь этого непросто и с технической, и с финансовой точек зрения. Следует, кроме того, учитывать два обстоятельства. Во-первых, для подавляющего большинства коммерческих организаций класс безопасности C2 достаточен. Во-вторых, более защищенные версии отстают по содержательным возможностям от обычных "собратьев", так что поборники секретности по сути обречены на использование морально устаревших (хотя и тщательно проверенных) продуктов со всеми вытекающими последствиями в плане сопровождения.
Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES, Informix и Oracle.

  1. Идентификация и проверка подлинности пользователей

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

CONNECT пользователь[/пароль] [@база_данных];

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

Для иллюстрации вопросов, связанных с управлением доступом, будет использоваться СУБД INGRES.

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

Пользователей СУБД можно разбить на три категории:

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

    В последующих разделах будет детально проанализирована система привилегий СУБД INGRES. Здесь мы отметим только, что администратор сервера баз данных, как самый привилегированный пользователь, нуждается в особой защите. Компрометация его пароля фактически означает компрометацию сервера и всех хранящихся на нем баз данных.
    Поручать администрирование различных баз данных разным людям имеет смысл только тогда, когда эти базы независимы и по отношению к ним не придется проводить согласованную политику выделения привилегий или резервного копирования. В таком случае каждый из администраторов будет знать ровно столько, сколько необходимо.
    Можно провести аналогию между пользователем ingres и администраторами баз данных с одной стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.) с другой стороны. Введение служебных пользователей позволяет администрировать функциональные подсистемы, не получая привилегий суперпользователя. Точно так же информацию, хранящуюся на сервере баз данных, можно разделить на отсеки, так что компрометация администратора одного отсека не означает обязательной компрометации другого.

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


    Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или всем) во время его создания (оператором CREATE USER) или изменения характеристик (оператором ALTER USER). Таких привилегий пять:

      • security - право управлять безопасностью СУБД и отслеживать действия пользователей. Пользователь с этой привилегией может подключаться к любой базе данных, создавать, удалять и изменять характеристики пользователей, групп и ролей, передавать права на доступ к базам данным другим пользователям, управлять записью регистрационной информации, отслеживать запросы других пользователей и, наконец, запускать INGRES-команды от имени других пользователей. Привилегия security необходима администратору сервера баз данных, а также лицу, персонально отвечающему за информационную безопасность. Передача этой привилегии другим пользователям (например, администраторам баз данных) увеличивает число потенциально слабых мест в защите сервера баз данных.
      • createdb - право на создание и удаление баз данных. Этой привилегией, помимо администратора сервера, должны обладать пользователи, которым отводится роль администраторов отдельных баз данных.
      • operator - право на выполнение действий, которые традиционно относят к компетенции оператора. Имеются в виду запуск и остановка сервера, сохранение и восстановление информации. Помимо администраторов сервера и баз данных этой привилегией целесообразно наделить также администратора операционной системы.
      • maintain_locations - право на управление расположением баз администраторы сервера баз данных и операционной системы.
      • trace - право на изменение состояния флагов отладочной трассировки. Данная привилегия полезна администратору сервера баз данных и другим знающим пользователям при анализе сложных, непонятных ситуаций.
          1. Привилегии доступа


          Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора GRANT и изымаются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает владелец соответствующих объектов (он же - администратор базы данных) или обладатель привилегии security (обычно администратор сервера баз данных).
          Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с помощью операторов CREATE GROUP и CREATE ROLE.
          Для изменения состава группы служит оператор ALTER GROUP.
          Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен список членов группы.
          Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE - для удаления ролей.
          Напомним, что создавать и удалять именованные носители привилегий, а также изменять их характеристики может лишь пользователь с привилегией security. При совершении подобных действий необходимо иметь подключение к базе данных iidbdb, в которой хранятся сведения о субъектах и их привилегиях.
          Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся. В СУБД INGRES таких видов пять:

            • таблицы и представления
            • процедуры
            • базы данных
            • сервер баз данных
            • события

            Присваивание привилегий доступа производится с помощью оператора GRANT. В самом общем виде оператор GRANT имеет следующий формат:

            GRANT привилегии
            ON объекты
            TO кому;

            Применительно к таблицам и представлениям можно управлять следующими правами доступа:

            Достижение поставленной цели и подтверждения гипотезы потребовало решения следующих задач:
            Выявление угроз безопасности баз данных, последствия, реализация последствий;
            Указать основные принципы обеспечения защиты информации;
            Обеспечение безопасности данных;
            Проанализировать защиту информации в среде MS SQL Server ЗАТО Александровск.

            Содержание

            ВВЕДЕНИЕ 3
            ГЛАВА 1. ИСТОЧНИКИ ВОЗНИКНОВЕНИЯ И ПОСЛЕДСТВИЯ РЕАЛИЗАЦИИ УГРОЗ БАЗ ДАННЫХ 6
            1.1. Классификация источников угроз 6
            1.2. Воздействие вредоносных прорамм 9
            1.3. Реализации возникновения угроз безопасности баз данных 12
            Выводы по первой главе 14
            ГЛАВА 2. ЗАЩИТА БАЗ ДАННЫХ И СИСТЕМА УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 16
            2.1. Основные понятия о базах данных 16
            2.2. Методы и средства защиты информации 18
            2.3. Особенности защиты информации в базах данных 22
            Выводы по второй главе 27
            ГЛАВА 3. ЗАЩИТА ДАННЫХ В СРЕДЕ MS SQL SERVER МУНИЦИПАЛЬНОГО ОБРАЗОВАНИЯ ЗАТО АЛЕКСАНДРОВСК 28
            3.1. Защита и управление доступом 28
            3.2. Администрирование системы безопасности 31
            3.3. Предоставление и отмена предоставленных привилегий пользователю 33
            Отмена предоставленных пользователям привилегий. 33
            3.4. Реализация прав на доступ к объектам баз данных в среде MS SQL Server 35
            Предоставление прав 37
            Права на выполнение команд SQL 38
            Выводы по третьей главе 40
            ЗАКЛЮЧЕНИЕ 42
            ГЛОССАРИЙ 45
            СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 47
            СПИСОК СОКРАЩЕНИЙ 50
            ПРИЛОЖЕНИЯ 51

            Вложенные файлы: 1 файл

            Защита информации в базах данных.doc

            ГЛАВА 1. ИСТОЧНИКИ ВОЗНИКНОВЕНИЯ И ПОСЛЕДСТВИЯ РЕАЛИЗАЦИИ УГРОЗ БАЗ ДАННЫХ 6

            1.1. Классификация источников угроз 6

            1.2. Воздействие вредоносных прорамм 9

            1.3. Реализации возникновения угроз безопасности баз данных 12

            Выводы по первой главе 14

            ГЛАВА 2. ЗАЩИТА БАЗ ДАННЫХ И СИСТЕМА УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 16

            2.1. Основные понятия о базах данных 16

            2.2. Методы и средства защиты информации 18

            2.3. Особенности защиты информации в базах данных 22

            Выводы по второй главе 27

            ГЛАВА 3. ЗАЩИТА ДАННЫХ В СРЕДЕ MS SQL SERVER МУНИЦИПАЛЬНОГО ОБРАЗОВАНИЯ ЗАТО АЛЕКСАНДРОВСК 28

            3.1. Защита и управление доступом 28

            3.2. Администрирование системы безопасности 31

            3.3. Предоставление и отмена предоставленных привилегий пользователю 33

            Отмена предоставленных пользователям привилегий. 33

            3.4. Реализация прав на доступ к объектам баз данных в среде MS SQL Server 35

            Предоставление прав 37

            Права на выполнение команд SQL 38

            Выводы по третьей главе 40

            СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 47

            СПИСОК СОКРАЩЕНИЙ 50

            ВВЕДЕНИЕ

            Одной из главных тенденций в современном мире является постоянное повышение роли информации.

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

            С повышением значимости и ценности информации соответственно растёт и важность её защиты.

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

            Эта проблема на данный момент является одной из самых актуальных задач. Её можно свести к минимуму, если заранее планировать обеспечение безопасности программных продуктов [12,57].

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

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

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

            Цель данной работы – анализ методов и средств защиты информации в базах данных.

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

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

            Достижение поставленной цели и подтверждения гипотезы потребовало решения следующих задач:

              • Выявление угроз безопасности баз данных, последствия, реализация последствий;
              • Указать основные принципы обеспечения защиты информации;
              • Обеспечение безопасности данных;
              • Проанализировать защиту информации в среде MS SQL Server ЗАТО Александровск.

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

              Предметом исследования – методы и средства защиты информации в базах данных.

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

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

              ГЛАВА 1. ИСТОЧНИКИ ВОЗНИКНОВЕНИЯ И ПОСЛЕДСТВИЯ РЕАЛИЗАЦИИ УГРОЗ БАЗ ДАННЫХ

              1.1 Классификация источников угроз

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

              1) Обусловленные действиями субъекта (антропогенные источники угроз).

              2) Обусловленные техническими средствами (техногенные источники угрозы).

              3) Обусловленные стихийными источниками. [6, 153]

              Антропогенные источники угроз.

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

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

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

              1) криминальные структуры;

              2) потенциальные преступники и хакеры;

              3) недобросовестные партнеры;

              4) технический персонал поставщиков сетевых услуг;

              5) представители надзорных организаций и аварийных служб;

              6) представители силовых структур.

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

              1) основной персонал (пользователи, программисты, разработчики);

              2) представители службы защиты информации;

              3) вспомогательный персонал (уборщики, охрана);

              4) технический персонал (жизнеобеспечение, эксплуатация).

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

              Техногенные источники угроз.

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

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

              1) средства связи;

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

              3) некачественные технические средства обработки информации;

              4) некачественные программные средства обработки информации;

              5)вспомогательные средства (охраны, сигнализации, телефонии);

              6) другие технические средства, применяемые в учреждении. [9,193]

              Стихийные источники угроз.

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

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

              5) различные непредвиденные обстоятельства;

              6) необъяснимые явления;

              7) другие форс-мажорные обстоятельства. [9,204]

              Воздействия вредоносных программ

              скрывать признаки своего присутствия в программной среде ОИ;

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

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

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


              В статье будет три части:

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


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

              Защита подключений

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

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

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

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

              Как это повлияет на производительность СУБД?

              Посмотрим на примере PostgreSQL, как SSL влияет на нагрузку CPU, увеличение таймингов и уменьшение TPS, не уйдет ли слишком много ресурсов, если его включить.

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

              Тест 1 без SSL и с использованием SSL — соединение устанавливается при каждой транзакции:


              vs


              Тест 2 без SSL и с использованием SSL — все транзакции выполняются в одно соединение:


              vs


              Остальные настройки:


              Результаты тестирования:

              NO SSL SSL
              Устанавливается соединение при каждой транзакции
              latency average 171.915 ms 187.695 ms
              tps including connections establishing 58.168112 53.278062
              tps excluding connections establishing 64.084546 58.725846
              CPU 24% 28%
              Все транзакции выполняются в одно соединение
              latency average 6.722 ms 6.342 ms
              tps including connections establishing 1587.657278 1576.792883
              tps excluding connections establishing 1588.380574 1577.694766
              CPU 17% 21%

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

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

              У нас был кейс, когда мы подключали Zabbix в режиме trust, то есть md5 не проверяли, в аутентификации не было необходимости. Потом заказчик попросил включить режим md5-аутентификации. Это дало большую нагрузку на CPU, производительность просела. Стали искать пути оптимизации. Одно из возможных решений проблемы — реализовать сетевое ограничение, сделать для СУБД отдельные VLAN, добавить настройки, чтобы было понятно, кто и откуда подключается и убрать аутентификацию.Также можно оптимизировать настройки аутентификации, чтобы снизить издержки при включении аутентификации, но в целом применение различных методов аутентификации влияет на производительность и требует учитывать эти факторы при проектировании вычислительных мощностей серверов (железа) для СУБД.

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

              Аудит действий

              Аудит может быть не только СУБД. Аудит — это получение информации о том, что происходит на разных сегментах. Это может быть и database firewall, и операционная система, на которой строится СУБД.

              В коммерческих СУБД уровня Enterprise с аудитом все хорошо, в open source — не всегда. Вот, что есть в PostgreSQL:

              • default log — встроенное логирование;
              • extensions: pgaudit — если вам не хватает дефолтного логирования, можно воспользоваться отдельными настройками, которые решают часть задач.

              «Базовая регистрация операторов может быть обеспечена стандартным средством ведения журнала с log_statement = all.

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

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

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

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

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

              Это может показаться простой задачей для базового аудита и grep, но что, если вам представится что-то вроде этого (намеренно запутанного) примера:

              DO $$
              BEGIN
              EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
              END $$;

              Стандартное ведение журнала даст вам это:

              LOG: statement: DO $$
              BEGIN
              EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
              END $$;

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

              Это не идеально, так как было бы предпочтительнее просто искать по имени таблицы.

              Вот где будет полезен pgAudit.

              Для того же самого ввода он выдаст этот вывод в журнале:

              AUDIT: SESSION,33,1,FUNCTION,DO. «DO $$
              BEGIN
              EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
              END $$;"
              AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

              Регистрируется не только блок DO, но и полный текст CREATE TABLE с типом оператора, типом объекта и полным именем, что облегчает поиск.

              При ведении журнала операторов SELECT и DML pgAudit можно настроить для регистрации отдельной записи для каждого отношения, на которое есть ссылка в операторе.

              Как это повлияет на производительность СУБД?

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

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

              log_destination = 'stderr'
              logging_collector = on
              log_truncate_on_rotation = on
              log_rotation_age = 1d
              log_rotation_size = 10MB
              log_min_messages = debug5
              log_min_error_statement = debug5
              log_min_duration_statement = 0
              debug_print_parse = on              		 debug_print_rewritten = on
              debug_print_plan = on
              debug_pretty_print = on
              log_checkpoints = on
              log_connections = on
              log_disconnections = on
              log_duration = on
              log_hostname = on
              log_lock_waits = on
              log_replication_commands = on
              log_temp_files = 0
              log_timezone = 'Europe/Moscow'

              На СУБД PostgreSQL с параметрами 1 CPU, 2,8 ГГц, 2 Гб ОЗУ, 40 Гб HDD проводим три нагрузочных теста, используя команды:


              Результаты тестирования:

              Без логирования С логированием
              Итоговое время наполнения БД 43,74 сек 53,23 сек
              ОЗУ 24% 40%
              CPU 72% 91%
              Тест 1 (50 коннектов)
              Кол-во транзакций за 10 мин 74169 32445
              Транзакций/сек 123 54
              Средняя задержка 405 мс 925 мс
              Тест 2 (150 коннектов при 100 возможных)
              Кол-во транзакций за 10 мин 81727 31429
              Транзакций/сек 136 52
              Средняя задержка 550 мс 1432 мс
              Про размеры
              Размер БД 2251 МБ 2262 МБ
              Размер логов БД 0 Мб 4587 Мб

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

              Смотрим другие параметры:

              • Скорость сильно не меняется: без логирования — 43,74 сек, с логированием — 53,23 сек.
              • Производительность по ОЗУ и CPU будет проседать, так как нужно сформировать файл с аудитом. Это также заметно на продуктиве.

              В корпорациях с аудитом еще сложнее:

              • данных много;
              • аудит нужен не только через syslog в SIEM, но и в файлы: вдруг с syslog что-то произойдет, должен быть близко к базе файл, в котором сохранятся данные;
              • для аудита нужна отдельная полка, чтобы не просесть по I/O дисков, так как он занимает много места;
              • бывает, что сотрудникам ИБ нужны везде ГОСТы, они требуют гостовую идентификацию.

              Ограничение доступа к данным

              Посмотрим на технологии, которые используют для защиты данных и доступа к ним в коммерческих СУБД и open source.

              Что в целом можно использовать:

              1. Шифрование и обфускация процедур и функций (Wrapping) — то есть отдельные инструменты и утилиты, которые из читаемого кода делают нечитаемый. Правда, потом его нельзя ни поменять, ни зарефакторить обратно. Такой подход иногда требуется как минимум на стороне СУБД — логика лицензионных ограничений или логика авторизации шифруется именно на уровне процедуры и функции.
              2. Ограничение видимости данных по строкам (RLS) — это когда разные пользователи видят одну таблицу, но разный состав строк в ней, то есть кому-то что-то нельзя показывать на уровне строк.
              3. Редактирование отображаемых данных (Masking) — это когда пользователи в одной колонке таблицы видят или данные, или только звездочки, то есть для каких-то пользователей информация будет закрыта. Технология определяет, какому пользователю что показывать с учетом уровня доступа.
              4. Разграничение доступа Security DBA/Application DBA/DBA — это, скорее, про ограничение доступа к самой СУБД, то есть сотрудников ИБ можно отделить от database-администраторов и application-администраторов. В open source таких технологий немного, в коммерческих СУБД их хватает. Они нужны, когда много пользователей с доступом к самим серверам.
              5. Ограничение доступа к файлам на уровне файловой системы. Можно выдавать права, привилегии доступа к каталогам, чтобы каждый администратор получал доступ только к нужным данным.
              6. Мандатный доступ и очистка памяти — эти технологии применяют редко.
              7. End-to-end encryption непосредственно СУБД — это client-side шифрование с управлением ключами на серверной стороне.
              8. Шифрование данных. Например, колоночное шифрование — когда вы используете механизм, который шифрует отдельную колонку базы.

              Как это влияет на производительность СУБД?

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

              Проведем тест c pgcrypto. Создадим таблицу с зашифрованными данными и с обычными данными. Ниже команды для создания таблиц, в самой первой строке полезная команда — создание самого extension с регистрацией СУБД:


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

              Выборка из таблицы без функции шифрования:

              id | text1 | text2
              ------+-------+-------
              1 | 1 | 1
              2 | 2 | 2
              3 | 3 | 3
              …
              997 | 997 | 997
              998 | 998 | 998
              999 | 999 | 999
              1000 | 1000 | 1000
              (1000 строк)

              Выборка из таблицы с функцией шифрования:

              id | decrypt | decrypt
              -----+--------------+------------
              1 | \x31 | \x31
              2 | \x32 | \x32
              3 | \x33 | \x33
              …
              999 | \x393939 | \x393939
              1000 | \x31303030 | \x31303030
              (1000 строк)

              Результаты тестирования:

              Без шифрования Pgcrypto (decrypt)
              Выборка 1000 строк 1,386 мс 50,203 мс
              CPU 15% 35%
              ОЗУ +5%

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

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

              Когда на всю колонку для всех пользователей один ключ (даже если не для всех, а для клиентов ограниченного набора), — это не всегда хорошо и правильно. Именно поэтому начали делать end-to-end шифрование, в СУБД стали рассматривать варианты шифрования данных со стороны клиента и сервера, появились те самые key-vault хранилища — отдельные продукты, которые обеспечивают управление ключами на стороне СУБД.


              Средства безопасности в коммерческих и open source СУБД

              Функции Тип Password Policy Audit Защита исходного кода процедур и функций RLS Encryption
              Oracle Коммерческая + + + + +
              MsSql Коммерческая + + + + +
              Jatoba Коммерческая + + + + extensions
              PostgreSQL Free extensions extensions - + extensions
              MongoDb Free - + - - Available in MongoDB Enterprise only

              Таблица далеко не полная, но ситуация такая: в коммерческих продуктах задачи безопасности решаются давно, в open source, как правило, для безопасности используют какие-то надстройки, многих функций не хватает, иногда приходится что-то дописывать. Например, парольные политики — в PostgreSQL много разных расширений (1, 2, 3, 4, 5), которые реализуют парольные политики, но все потребности отечественного корпоративного сегмента, на мой взгляд, ни одно не покрывает.

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

              Второй вариант — самостоятельно написать, что нужно, реализовать на уровне процедур доступ к данным и шифрование в приложении. Правда, с ГОСТом будет сложнее. Но в целом — вы можете скрыть данные, как нужно, сложить в СУБД, потом достать и расшифровать как надо, прямо на уровне application. При этом сразу думайте, как вы будете эти алгоритмы на application защищать. На наш взгляд, это нужно делать на уровне СУБД, потому что так будет работать быстрее.

              Читайте также: