Большинству веб-приложений сегодня требуется хотя бы некоторая базовая стратегия безопасности. Например, сайты, предлагающие контент, защищенный паролем, сайты только с административной частью, блоги и личные журналы, сайты электронной коммерции, корпоративные интрасети и т. д.
Наиболее распространенным подходом к созданию веб-приложений такого типа является интеграция политики безопасности в бизнес-логику веб-приложения, при которой приложение определяет, имеет ли пользователь разрешение на доступ к определенным данным в базе данных. В этом сценарии роль базы данных — просто хранить данные и обслуживать их по запросу. Другими словами, если веб-приложение дает команду базе данных предоставить определенную информацию, база данных выполняет команду напрямую, не проверяя разрешения пользователя.
В этой статье вы узнаете, как использовать встроенные функции безопасности Oracle для обеспечения соблюдения правил безопасности приложений на уровне базы данных и повышения общей безопасности вашего приложения. Дополнительным преимуществом является обеспечение доступа к данным непосредственно в базе данных, что не только повышает безопасность приложений, но и помогает снизить сложность.
А как насчетнеобходимости обеспечения безопасности на стороне базы данных
для контроля доступа к данным из веб-приложений? В большинстве случаев проблем нет; это хорошее решение, особенно если задействованные данные не являются критически важными или совершенно секретными. Этот метод используется во многих книгах и интернет-ресурсах. Фактически, одна популярная книга по PHP/MySQL явно не рекомендует создавать более одной учетной записи пользователя базы данных для каждого приложения, поскольку «дополнительные пользователи или сложные разрешения могут потребовать дополнительных проверок перед продолжением работы и замедлить скорость выполнения MySQL». Это правда; однако есть несколько вещей, которые вы, возможно, захотите рассмотреть, прежде чем отказываться от идеи интеграции безопасности в логику вашей базы данных. Давайте посмотрим на следующий пример.
Допустим, вы создаете систему управления контентом (CMS). База данных используется для хранения контента, опубликованного на сайте. Большая часть данных является общедоступной, что позволяет анонимным пользователям сети читать их. Только редакторы могут изменять данные. Используйте одну учетную запись базы данных для доступа и изменения записей в базе данных, а также контролируйте безопасность с помощью кода PHP, защищая паролем доступ к страницам только для администратора.
Если публичная часть веб-приложения подвергается такой атаке, как внедрение SQL-кода в общедоступную форму поиска (то есть форму, которая недостаточно четко закодирована), злоумышленник может выполнить произвольные операторы SQL над объектами базы данных, которые публичный аккаунт имеет доступ. Конечно, в этом случае выполнение оператора SELECT не представляет большой проблемы, поскольку данные являются общедоступными. Но поскольку общие и административные права используют одну и ту же учетную запись базы данных, злоумышленник также может выполнять операторы UPDATE и DELETE или даже удалять таблицы из базы данных.
Как мы можем предотвратить это? Самый простой способ — полностью ограничить права учетной записи общедоступной базы данных на изменение данных. Давайте посмотрим, как Oracle решает эту проблему.
Базовый обзор безопасности Oracle
База данных Oracle предоставляет веб-разработчикам множество способов управления доступом к данным: от управления доступом к конкретным объектам базы данных, таким как таблицы, представления и процедуры, до управления доступом к данным в отдельных строках или столбцах. Очевидно, что обсуждение каждой функции или опции безопасности, доступной в Oracle, выходит за рамки этой статьи. Здесь мы не будем вдаваться в подробности, а только самые основные аспекты безопасности доступа к данным Oracle:
· Аутентификация и учетные записи пользователей · Разрешения · Ролевая
аутентификация и учетные записи пользователей. Как и в случае с другими базами данных, каждый пользователь (учетная запись базы данных), запрашивающий доступ к Oracle, должен пройти аутентификацию. Проверка может выполняться с помощью базы данных, операционной системы или сетевой службы. Помимо базовой аутентификации (парольной аутентификации), Oracle также поддерживает механизмы строгой аутентификации, такие как Kerberos, CyberSafe, RADIUS и т. д.
Роль. Роль Oracle — это именованный набор разрешений. Хотя вы можете предоставлять разрешения учетной записи пользователя напрямую, использование ролей может значительно упростить управление пользователями, особенно если вам необходимо управлять большим количеством пользователей. Очень эффективно создавать небольшие управляемые роли, а затем предоставлять пользователям одну или несколько ролей в зависимости от их уровня безопасности. Не говоря уже о том, насколько легко изменить разрешения — просто измените роль, с которой связана эта роль, а не изменяйте каждую учетную запись пользователя.
Чтобы упростить первоначальную работу по созданию новых пользователей, Oracle предлагает три предопределенные роли:
· Роль CONNECT. Эта роль позволяет пользователям подключаться к базе данных и выполнять основные операции, такие как создание собственных таблиц. По умолчанию эта роль не имеет доступа к таблицам других пользователей.
·Роль RESOURCE. Роль RESOURCE аналогична роли CONNECT, но позволяет пользователям иметь больше системных разрешений, например создание триггеров или хранимых процедур.
·Роль администратора базы данных — позволяет пользователю иметь все системные привилегии.
Используемые авторизации и разрешения
В этом разделе мы обсудим, как использовать авторизацию и разрешения Oracle для повышения безопасности простого примера CMS, рассмотренного в начале этой статьи. Предполагается, что контент, предоставляемый пользователям приложения, хранится в таблице WEB_CONTENT.
Сначала создайте таблицу. Запустите Oracle Database Special Edition и войдите в систему как системный администратор. Освободите образца пользователя отдела кадров, если он еще не освобожден. Следуйте инструкциям руководства по началу работы, включенного в установку Special Edition. Обратите внимание, что по умолчанию пользователям отдела кадров назначается роль РЕСУРС. Здесь дайте пользователю роль администратора базы данных, чтобы эту учетную запись можно было использовать для управления аспектами базы данных приложения CMS. Разумеется, учетная запись пользователя HR не будет использоваться для онлайн-доступа, а только для администрирования базы данных.
Теперь вы можете создать новую таблицу с помощью обозревателя объектов или выполнив окно команд SQL. Вот код для создания таблицы:
CREATE TABLE WEB_CONTENT (
page_id НОМЕР ПЕРВИЧНОГО КЛЮЧА,
page_content VARCHAR2(255)
);
Поскольку таблица была создана с использованием учетной записи пользователя HR, она принадлежит учетной записи HR и находится в схеме HR, и другие пользователи не могут получить доступ к таблице, пока им явно не предоставлено разрешение на доступ к таблице. Если вы не верите, вы можете создать нового пользователя и попробовать использовать этого пользователя для доступа к таблице WEB_CONTENT.
Теперь создайте двух новых пользователей: CMS_USER и CMS_EDITOR. Наконец, CMS_USER будут предоставлены разрешения только на чтение таблицы WEB_CONTENT, и этот пользователь будет использоваться в качестве учетной записи базы данных, которая обслуживает контент в качестве анонимного веб-пользователя. Учетная запись CMS_EDITOR будет иметь больше разрешений для таблицы и будет использоваться в качестве учетной записи редактора CMS (учетная запись, необходимая для изменения и обслуживания данных в таблице).
Новых пользователей можно создать с помощью графического интерфейса XE или выполнив следующую команду:
CREATE USER cms_user IDENTIFIED BY cms_user;
СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ cms_editor, ИДЕНТИФИЦИРОВАННОГО cms_editor;
(Для простоты пароль здесь соответствует имени пользователя.)
Чтобы обе учетные записи могли войти в базу данных, нам нужно предоставить им роль CONNECT. Для этого установите флажок ПОДКЛЮЧИТЬСЯ в разделе «Информация о пользователе» в разделе «Администрирование/Пользователи базы данных» графического интерфейса XE или выполните следующую команду:
GRANT CONNECT to cms_user;
GRANT CONNECT to cms_editor;
Теперь, если вы попытаетесь войти в систему как пользователь CMS_USER или CMS_EDITOR и попытаться прочитать данные из таблицы WEB_CONTENT (выберите * из hr.web_content;), вы столкнетесь со следующей ошибкой:
ORA-00942: таблица или представление. не
существует. Чтобы получить доступ к данным или просто просмотреть таблицу, вам необходимо предоставить учетным записям CMS_USER и CMS_EDITOR разрешения только на чтение для таблицы WEB_CONTENT:
GRANT SELECT на hr.web_content для cms_user;
GRANT SELECT для hr.web_content для cms_editor.
Приведенный выше код позволяет этим двум учетным записям выполнять инструкции SELECT для таблицы WEB_CONTENT; Если вы попытаетесь выполнить другие инструкции, вы столкнетесь с ошибкой. Например, вставка строки:
INSERT INTO hr.web_content (page_id,page_content) VALUES (1, «привет, мир!»)
приведет к появлению сообщения об ошибке
ORA-01031: недостаточно прав,
чтобы позволить CMS_EDITOR изменить содержимое этой таблицы. необходимо предоставить следующие разрешения:
GRANT INSERT, UPDATE, DELETE для hr.web_content для cms_editor.
С этого момента учетная запись CMS_EDITOR может выполнять операторы INSERT, UPDATE и DELETE в таблице WEB_CONTENT;
Посмотрите, как это легко! Видно, что управление разрешениями через роли — более эффективный метод. Если используемая база данных Oracle не XE, вы можете выполнить следующие операции:
Создать роль:
CREATE ROLE Reader;
CREATE ROLE Writer
Предоставить разрешения роли:
GRANT SELECT ON web_content TO read;
GRANT INSERT, UPDATE, DELETE ON web_content TO Writer
Дайте роль пользователю:
GRANT Reader TO cms_user;
ПРЕДОСТАВИТЬ читателю cms_editor (им тоже нужно читать)
GRANT Writer TO cms_editor
Обратите внимание: если вы измените определение роли READER, эти изменения затронут все учетные записи пользователей с этой ролью. Если разрешения предоставляются непосредственно пользователям, каждую учетную запись пользователя необходимо обновлять индивидуально.
После выполнения вышеуказанных шагов вы можете настроить свое PHP-приложение на использование учетной записи CMS_USER для всех подключений к базе данных, запрашиваемых анонимными веб-пользователями, и учетной записи CMS_EDITOR для подключений, инициируемых защищенными паролем административными страницами. Теперь, даже если общедоступная веб-форма будет скомпрометирована, влияние на базу данных будет минимальным, поскольку учетная запись CMS_USER имеет разрешения только на чтение.
Заключение
В этой статье мы лишь кратко представили некоторые из самых основных функций безопасности доступа к данным Oracle. Кроме того, Oracle предлагает множество других функций, которые выводят безопасность ваших веб-приложений на новый уровень, включая виртуальную частную базу данных (VPD) и безопасность тегов.