Конструирование логики работы с данными

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

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

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

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

2) процедуру добавления данных;

3) процедуру изменения данных;

4) процедуру удаления данных.

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

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

Вопросы безопасности баз данных

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

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

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

Защищенные соединения. Все подключения к БД необходимовыполнять по защищенному подключению. Наиболее распространенным является SSL-подключение (криптографический протокол, который обеспечивает установление безопасного соединения междуклиентом и сервером).

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

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

SELECTid, nameFROMproductsWHEREmanufacturer = ‘@ price’,

где вместо ключевого слова «@price» динамически подставляетсязначение поля с названием производителя, которое заполняет пользователь. Если злоумышленник в качестве наименования производителя введет следующий текст (корректность синтаксиса зависитотиспользуемойСУБД

фыаыва’; deletefromproducts; commit

то запрос выполнится корректно, но также удалятся все данные опродуктах.

Наши рекомендации