itmo_conspects
Лекция 9. Безопасность
На прошлой лекции мы разбирали, как обеспечить надежность систем базы данных. Если задуматься, то “надежность” можно считать синонимом “безопасности”, но дело в том, что надежность системы противостоит со случайными ошибками (race-condition, аномалии), тогда как безопасность борется с сознательным нарушением целостности данных - с человеком
Orange Book
Критерии определения безопасности компьютерных систем или же просто оранжевая книга, выпущенная в 1985 году, описывает критерии безопасной системы
Оранжевой книгой ее назовут по цвету обложки
Оранжевая книга вводит классификацию:
-
Класс D
-
Класс C и подклассы C1 и C2
-
Класс B и подклассы B1, B2, B3
-
Класс A
Система класса D - система, которая не подходит под требования безопасности других классов
Теперь, переходя к другим классам, определим безопасную систему:
Безопасная система - система контроля доступа (создание, чтение, обновление, удаление - CRUD) данных, которая предоставляет только имеющим нужные полномочия лицам и процессам, действующие от их имени, право на доступ к данным
Система класса C - система, в которой реализованы:
-
подсистемы идентификации, аутенфикации, авторизации
-
учет событий (логгирование)
-
и сам главное - дискреционный контроль доступа
Начнем с того, что компьютерная система абстрагирована от конечного пользователя и, чтобы связать физическую личность с доступом к данным, существует учетная запись - логическое представление человека в системе. При создании учетной записи субъекту присваивается идентификатор, который при входе проверяется
Выделяют 3 класса идентификаторов:
-
То, что пользователь знает: пароль, пинкод
-
То, чем пользователь владеет: номер телефона, смарт-карта
-
Неотъемлимая характеристика: биометрия - отпечаток пальца, сетчатка радужки и др.
При этом важно уметь различать эти 3 понятия:
Идентификация - присвоение пользователю идентификатора в базе данных
Аутентификация - сопоставление предъявляемого идентификатора с данным, хранимым в системе
Авторизация - предоставление доступ после аутентификации к системе
Аутентификация может быть многофакторной: например, пароль + код от смс, или пароль + отпечаток пальца
Дискреционный контроль доступа представляет собой матрицу субъекты/объекты:
| O1 | O2 | … | On | |
|---|---|---|---|---|
| S1 | r | r | ||
| S2 | ru | |||
| … | ||||
| Sm |
На пересечении столбцов и строчек матрицы определены типы доступа CRUD.
Возникает проблема: как ей пользоваться и как ее хранить? Дискреционная матрица выходит очень разреженной - зачастую только один рабочий отдел имеет доступ к объектам своего типа, поэтому матрицу можно представить как массив списков - хранить для субъектов только те субъекты, в которых есть записи (или наоборот). Помимо этого есть и другие способы хранение
Кто должен назначать эти права?
1) Суперпользователь или суперадмин - единственный человек, который может менять эту матрицу. В этом случае легко определить, кто изменил ее, но этот администратор не может работать круглосуточно
2) Владельцы у объектов: отмечаем для каждого объекта субъекта, который будет владет объектом, и только этот владелец имеет право менять привилегии для своего объекта
3) Право менять поля является правом доступа к данным (CRUD + право менять матрицу)
Система подкласса C1 предполагает, что существует доверительная вычислительная база - вся процедура от аутентификации до авторизации централизованно контролируется
Система подкласса C2 гарантируется гранулированность субъектов до конкретного пользователя - в матрице один субъект может представлять не одного пользователя, а нескольких
Класс C защищает от несанкционированного CRUD, но не защищает от того, что пользователь, который имеет доступ к данным, не сможет разгласить его тем, кто такого доступа не имеет
Система класса B реализует мандатный доступ
В чем смысл: создаем набор меток M1, M2, …, Mn; каждому субъекту присваиваем какую-то метку, и каждому объекту какую-то метку (они естественно могут повторяться) - таким образом метки образуют упорядоченный набор множества. Метки можно обозвать так:
-
M1 - совершенно секретно
-
M2 - секретно
-
M3 - для служебного пользования
-
M4 - общественная информация и так далее.
Теперь устанавливаем правила:
- Пользователь с сильной меткой может читать объекты со своей меткой и слабее,
- А также пользователь может изменять объекты со своей меткой и сильнее
Таким образом, пользователь может “отчитаться руководству” и не разгласить данные, которые секретнее его метки
В системе подкласса B1 мы сами определяем, какие объекты будут иметь мандатный доступ
В системе подкласса B2 все объекты имеет только мандатный доступ
В системе подкласса B3 вводим отдельную роль “администратор безопасности”, который назначает эти метки
Но, что если в компанию наймется разработчик, который оставит в коде бэкдор, который позволит ему украсть из системы много миллионов денег и при этом беспроблемно исчезнуть. Тогда может помочь система класса A
Класс A предполагает проверенный дизайн: независимая проверка архитектуры, кода на поиск проблем безопасности
Другие методы защиты
Мандатный доступ - это, конечно, круто, но применяется он редко: это не удобно, сложно настраивается
Если рассмотреть дискреционный доступ, то может возникнуть такая проблема: человека с должности удалили (или перевели на другую должность), но по всем ячейкам матрицы изменять доступ данных тяжело. Поэтому поможет ролевая модель доступа: мы строим матрицу не субъект-объект, а роль-объект;
| O1 | O2 | … | On | |
|---|---|---|---|---|
| R1 | r | r | ||
| R2 | ru | |||
| … | ||||
| Rm | crud |
и отдельно матрицу роль-субъект:
| S1 | S2 | … | Sn | |
|---|---|---|---|---|
| R1 | X | X | ||
| R2 | X | |||
| … | ||||
| Rm | X | X |
В этой модели субъект может иметь несколько ролей. Конечно, мы теряем производительность (соединение двух таблиц не бесплатно), к тому же из-за множества ролей может возникнуть противоречие флагов доступа данных
При всем это следует помнить, что система безопасности работает как открытая система - в среде неучтенных угроз.
Существует еще один способ заметить слабые места системы - аудит - журналирование, к которому добавляется механизм анализа журнала
Помимо этого, помним, что данные записываются на диск; администратор операционной системы может обратиться к этим незащищеным файлам, тогда можно применить шифрование данных. Выделяют 4 вида:
-
Прозрачное шифрование базы данных: данные шифруются при записи и дешифруются при чтении
-
Шифрование на уровне столбцов: отдельные столбцы дешифруются при чтении
-
Шифрование на уровне файловой системы: драйвер файловой системы перед чтением шифрует данные
-
Шифрование на уровне приложений: данные шифруются в самой базе данных (но невозможно использовать индексы)
Также в системе может применять резервное копирование: если пользователь с высоким доступом внезапно сходит с ума, то его действия можно откатить к валидной версией
В то же время проблема суперадмина, субъекта, имеющего столько власти, не имеет решения - разделить его обязанности просто не получиться.
В итоге, можно сказать, что в отличии от любой ограниченной математической модели, система должна противостоять бесчисленному количеству неучтенных угроз - будь то сумашедший человек, сила обладающего волей естественного интеллекта или сотрудники одной компании, который выходят всей группой за кофе, чтобы приукрасить журнал рабочих часов. Но все приведенные выше методы должны уменьшить вероятность умышленного нападения на систему