Что сделать чтобы пользователь не подвесил бд
Защищаем MySql. Шаг за шагом
- База данных MySQL будет использоваться только PHP приложениями, установленными на том же самом хосте;
- Для управления базой данных будут использоваться стандартные административные средства, типа mysqladmin, mysql,mysqldump и т.д.;
- Для удаленного резервирования MySQL данных будет использоваться SSH протокол.
- база данных mysql должна быть выполнена в chrooted среде;
- процессы mysql должны выполняться под уникальным UID/GID, неиспользуемым никаким другим системным процессом;
- Должен быть разрешен только локальный доступ к mysql;
- Основная учетная запись mysql должна быть защищена “сложным” паролем;
- Будет переименована учетная запись администратора;
- Должен быть заблокирован анонимный доступ к базе данных (используя учетную запись nobody);
- Должны быть удалены все типовые базы данных и таблицы.
pw groupadd mysql
pw useradd mysql-c » mysql Сервер «-d/dev/null-g mysql-s/sbin/nologin
./configure —prefix=/usr/local/mysql —with-mysqld-user=mysql —with-unix-socket-path=/tmp/mysql.sock —with-mysqld-ldflags=-all-static
make
su
make install
strip /usr/local/mysql/libexec/mysqld
scripts/mysql_install_db
chown -R root /usr/local/mysql
chown -R mysql /usr/local/mysql/var
chgrp -R mysql /usr/local/mysql
cp support-files/my-medium.cnf /etc/my.cnf
chown root:sys /etc/my.cnf
chmod 644 /etc/my.cnf
/usr/local/mysql/bin/mysqladmin -u root shutdown
mkdir -p /chroot/mysql/dev
mkdir -p /chroot/mysql/etc
mkdir -p /chroot/mysql/tmp
mkdir -p /chroot/mysql/var/tmp
mkdir -p /chroot/mysql/usr/local/mysql/libexec
mkdir -p /chroot/mysql/usr/local/mysql/share/mysql/english
chown -R root:sys /chroot/mysql
chmod -R 755 /chroot/mysql
chmod 1777 /chroot/mysql/tmp
cp/usr/local/mysql/libexec/mysqld/chroot/mysql/usr/local/mysql/libexec/
cp/usr/local/mysql/share/mysql/english/er rmsg.sys/chroot/mysql/usr/local/mysql/share/mys ql/english/
cp/etc/hosts/chroot/mysql/etc/
cp/etc/host.conf/chroot/mysql/etc/
cp/etc/resolv.conf/chroot/mysql/etc/
cp/etc/group/chroot/mysql/etc/
cp/etc/master.passwd/chroot/mysql/etc/passwords
cp/etc/my.cnf/chroot/mysql/etc/
cd /chroot/mysql/etc
pwd_mkdb -d /chroot/mysql/etc passwords
rm -rf /chroot/mysql/etc/master.passwd
ls -al /dev/null
crw-rw-rw- 1 root sys 2, 2 Jun 21 18:31 /dev/null
mknod /chroot/mysql/dev/null c 2 2
chown root:sys /chroot/mysql/dev/null
chmod 666 /chroot/mysql/dev/null
cp-R/usr/local/mysql/var//chroot/mysql/usr/local/mysql/var
chown-R mysql:mysql/chroot/mysql/usr/local/mysql/var
chrootuid /chroot/mysql mysql /usr/local/mysql/libexec/mysqld &
skip-networking
backuphost$ ssh mysqlserver /usr/local/mysql/bin/mysqldump -A > backup
socket = /chroot/mysql/tmp/mysql.sock
chrootuid /chroot/mysql mysql /usr/local/mysql/libexec/mysqld &
/usr/local/mysql/bin/mysql -u root
mysql> SET PASSWORD FOR root@localhost=PASSWORD(‘new_password’);
mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host=»localhost» and user=»root»);
mysql> flush privileges;
mysql> update user set user=»mydbadmin» where user=»root»;
mysql> flush privileges;
Что сделать чтобы пользователь не подвесил бд
Защита от редактирования записей/полей таблиц в Access
Защита таблиц от редактирования от пользователей
У меня есть форма с авторизацией, где пользователь и администратор входят и должны вести пароль.
Защита базы данных Microsoft Access и её таблиц
— Защита базы данных Microsoft Access и её таблиц, запросов, форм, отчетов и макросов средствами.
Запрос на удаление из полей нескольких таблиц не пустых записей
Пробовал составить правильно данный запрос (каскадное удаление включено. так-что должны.
Автоматическое создание таблиц из наименований таблиц, имен полей, типов полей
Форумчане, доброго времени суток! Есть таблица в которую автоматом выгрузили имена всех таблиц.
Базу данных не стащить: правильные способы защитить данные в таблицах БД
Как же ошибаются те люди, которые доверяют защиту данных исключительно самой
СУБД. Мол, если пароль на подключение хороший и версия демона – самая последняя,
то все будет нормально. Ничего подобного. Базы как сливали, так и будут сливать.
А наша задача – сделать их нечитаемыми для тех, кому они не предназначены.
Актуальная проблема из мира информационной безопасности – обеспечить
сохранность данных. Есть ситуации, в которых даже при наличии серьезной защиты
системы, сохранность данных оказывается под большим вопросом. Как так? Могу
привести пример из личного опыта, когда в разглашении информации был виновен
засланный сотрудник конкурирующей компании. Находясь на рабочем местом и будучи
технически подкованным, он взламывал сервера баз данных банальным брутфорсом
через терминальное соединение. Базы с клиентами "засланец" перепродавал другим
компаниям, а "интересная" информация о ведении бизнеса отправлялась сотрудникам
силовых структур. Что из этого вышло, объяснять излишне.
Вообще, имея физический доступ к локальной сети, инсайдер мог поступить
гораздо проще: атаковать программу, которая работает с базой данных. Нередко
сценарий взлома сводится к тому, что из программы разными способами извлекаются
конфиги для подключения к базе. Захватив ту же 1С, которая хранит в себе конфиги
подключения к базе (в том числе, шифрованный обычным XOR’ом пароль),
злоумышленник получает доступ к самой базе. Особо не стесняясь, он может ее
выкачать, модифицировать или просто удалить. Такая брешь в защите способна
сыграть злую шутку, особенно в корпоративной среде.
В статье я как раз хочу рассказать о том, как обезопасить информацию в
обычной базе данных. Даже если СУБД будет взломана или левый человек скопирует
данные, утечки конфиденциальной информации не произойдет!
Шифрованию – быть!
Общий подход прост до гениального: раз злоумышленник гипотетически сможет
извлечь данные, надо сделать так, чтобы он их не смог прочитать. Информацию все
равно придется хранить в базе, но… ничего не мешает хранить ее в каком угодно
виде, в том числе зашифрованном! Главное, чтобы мы сами потом смогли
расшифровать :).
Компания Spelabs (www.spellabs.ru/spellabsCrypto1C.htm)
как-то анонсировала продукт, организующий дополнительную безопасность
бухгалтерских 1С на уровне шифрования данных, причем на полностью прозрачном
уровне. Пользовательские приложения, не подозревая о надстройке, работали в
обычном режиме. Увы, компания прекратила разработку этого направления. Но
реально обойтись и без подобных инструментов, ведь для шифрования сгодятся даже
штатные средства СУБД!
Любая современная СУБД, если это, конечно, не собранная на коленке курсовая,
может похвастаться достаточно надежными механизмами шифрования данных. В той же
самой MySQL я по памяти насчитал около 14 соответствующих функций, которые тебе
наверняка хорошо известны:
- AES_ENCRYPT() — шифрование AES
- AES_DECRYPT() — расшифровка AES
- COMPRESS() — возвращение результата в бинарном виде
- DES_ENCRYPT() — шифрование DES
- DES_DECRYPT() — дешифрование DES
- ENCODE() — шифрование строки поверхностным паролем (на выходе
получается шифрованное слово первоначальной "plaintext" длины - DECODE() — расшифровка текста, обработанного функцией ENCODE()
- ENCRYPT() — шифрование с помощью Unix’ового системного вызова crypt
- MD5() — подсчет MD-5 суммы
- SHA1(), SHA() — подсчет SHA-1 (160-бит)
Для их применения надо лишь чуть изменить свои SQL-запросы, добавив в нужном
месте функции AES_ENCRYPT() или DES_ENCRYPT(), которые считаются наиболее
надежными в MySQL на текущий момент. Например, так:
INSERT INTO t VALUES (1,AES_ENCRYPT(‘text’,’password’));
Приятно признать, что хорошие программисты эти функции используют. Часто во
время проведения SQL-инжекции мне приходилось ломать голову и определять
функцию, которую использовал кодер для крипточки данных. В результате, требуется
производить те же AES_DECRYPT(AES_ENCRYPT()) наряду с unhex(hex()).
Помимо симметричного шифрования, когда упаковка и распаковка текста
производятся одним и тем же ключом (общим для двух участников обмена
сообщениями), поддерживается и ассиметричное криптование. Идея ассиметричных
алгоритмов подразумевает наличие двух ключей – открытого и закрытого
(секретного). Один из них используется для шифрования информации, а другой — для
дешифрования. Если кодирование осуществляется с помощью открытого ключа, то
расшифровать такие данные можно только с помощью парного ему закрытого.
Предлагаю разобраться с этим на примере Microsoft SQL Server, который часто
используется в корпоративных порталах и сложных приложениях.
Для шифрования применяются функции T-SQL, представляющие собой специальное
дополнение языка SQL. Оно поддерживает управляющие операторы, локальные
переменные и различные дополнительные функции.
Одна из таких функций — EncryptByCert(), используемая для ассиметричного
шифрования данных с помощью сертификатов. Открытым ключом тут выступает
сертификат. Только откуда этот сертификат взять? Ответ прост – сгенерировать с
помощью другой специальной функции. Покажу на примере, как можно сгенерировать
сертификат с именем для andrej базы "Bank" с помощью хранимой процедуры:
USE Bank;
CREATE CERTIFICATE andrej
ENCRYPTION BY PASSWORD = ‘pGFD4bb925DGvbd2439587y’
# Для генерации с использованием подгрузки из файла
# FROM FILE = ‘c:\Shipping\Certs\Shipping11.cer’
# WITH PRIVATE KEY (FILE = ‘c:\Shipping\Certs\Shipping11.pvk’,
WITH SUBJECT = ‘Employers Access’,
EXPIRY_DATE = ’10/31/2009′;
GO
У нас создался сертификат! Теперь его можно без проблем использовать для
размещения в таблице зашифрованных записей, выполняя привычные SQL-запросы:
INSERT INTO [БАЗА].[ТАБЛИЦА]
values( N’ДАННЫЕ ДЛЯ ЗАШИФРОВКИ’,
EncryptByCert(Cert_ID(‘andrej’), @cleartext) );
GO
В этом примере неформатированный текст из переменной @cleartext шифруется
сертификатом с именем "andrej". Зашифрованные данные помещаются в таблицу
"ТАБЛИЦА". Уточню, что данные могут быть расшифрованы только с помощью
соответствующего закрытого ключа (как уже было сказано, "приватного").
Имя функции для обратного преобразования угадать несложно: DecryptByCert(). А
вот синтаксис более хитер, и с ним все чуть сложнее. Дело в том, что на
приватный ключ, как правило, закладывается дополнительный пароль (passphrase).
Его необходимо ввести, и по этой причине он обязательно будет присутствовать в
коде запроса или процедуры. Это не очень хорошо, потому что в этом случае его
можно быстро увести. Но с этим мы разберемся позже, когда поговорим о
безопасности хранимых процедур. А пока – код для извлечения данных из
шифрованной базы данных:
SELECT convert(nvarchar(max), DecryptByCert(Cert_Id(‘andrej’),
ProtectedData, N’pGFD4bb925DGvbd2439587y’))
FROM [БАЗА].[ТАБЛИЦА]
WHERE Description
= N’Employers Access’;
GO
В этом примере производится выборка строк из таблицы [БАЗА].[ТАБЛИЦА],
помеченных как "Employers Access". Пример дешифрует зашифрованный текст с
помощью закрытого ключа сертификата "Andrej" и дополнительного пароля
pGFD4bb925DGvbd2439587y. Расшифрованные данные преобразуются из типа varbinary в
тип nvarchar.
Надо сказать, что ассиметричные преобразования гораздо более накладны, чем
шифрование и дешифрование с использованием симметричного ключа. Поэтому
использование ассиметричного шифрования не рекомендуется при работе с большими
объемами данных, например, таблицами пользовательских данных. Это важно
учитывать при особо больших базах, а также базах, структура которых не приведена
к одной из нормальных форм.
Прячем хранимые процедуры!
Если ты не заметил, многое упирается в то, что вся конфиденциальность и
целостность завязана на использование хранимых процедур или функций. Получается,
что, получив к ним доступ и грамотно проанализировав их код, любой опытный хакер
сможет преобразовать шифрованную белиберду в исходный текст. Конечно, добраться
до кода процедур далеко не всегда реально, потому здесь всплывает вопрос об
утечке программной начинки производства, а именно – логике ПО. Но именно по этой
причине необходимо прибегать к шифрованию процедур и функций в базе. Одно из
самых популярных и удачных средств для таких действий – это программа SQL Shield
(www.sql-shield.com).
После несложной установки приложения не забудь указывать дополнительный флаг
/*sqlshield*/ с выражением "WITH ENCRYPTION" всякий раз, когда будешь создавать
защищенную процедуру. Вот пример функции, которая исполняет простейший запрос к
базе:
CREATE PROCEDURE MyTest
WITH /*sqlshield*/ ENCRYPTION
AS
SELECT 2+2
Исполняем процедуру и получаем:
Проверим, в каком виде хранится процедура, с помощью специального средства
для ковыряния в файлах базы. Подойдет SQL Server Syscomments Decryptor (www.geocities.com/d0mn4r/dSQLSRVD.html),
который при отображении текста процедуры показывает одни лишь знаки вопроса.
Все работает!
Как облегчить себе жизнь?
В заключение – не менее интересный продукт XP_CRYPT (www.xpcrypt.com).
Это средство осуществляет весь тот геморрой, который мы только что проделали
вручную. Все, что от тебя требуется, – скачать дистрибутив проги, установить ее
на сервер (к сожалению, есть версия только для Винды), обозначить свою базу
данных и начать химию с таблицами с помощью удобного GUI-интерфейса.
Организуем знакомство на примере из практики. Предположим, у нас есть
интернет-магазин, где каким-то образом хранятся данные о кредитных картах
клиентов (распространенная ситуация, хотя это категорически запрещено!). Наша
задача — зашифровать конкретные данные о клиентах, т.е. поля с паролем, номером
кредитной карточки и т.п. Пока мы ничего не делали, при запросе SELECT * FROM
tbl_CCards, СУБД возвращает все в открытом виде:
Username Password CredCardNum
james god 1234567890123456
lucas sex 2894787650102827
anna love 3234563638716434
Напишем внешнюю функцию UDF (расшифровывается, как "User-Defined-Function",
подробности) для преобразования строки в SHA-хеш:
CREATE FUNCTION ud_MakeSHA1 (@clearpass VARCHAR (8000) )
RETURNS VARCHAR (40)
AS
BEGIN
DECLARE @ret as VARCHAR(40)
EXEC master..xp_sha1 @clearpass,@ret OUTPUT
RETURN @ret
END
Отдаем команду: UPDATE tbl_CCards SET password = dbo.ud_MakeSHA1(Password).
После чего еще раз проверяем содержимое базы той же командой. Что видим? Все
зашифровано, все пароли захешировались!
Теперь нужно не забыть о том, что мы используем шифрование при обращении к
базе. В нашем случае, когда ты будешь делать авторизацию пользователей,
процедура проверки пароля по хешу будет выглядеть примерно так:
CREATE FUNCTION ud_CheckUser (@username VARCHAR(16),@clear_pass VARCHAR
(16))
RETURNS INTEGER
AS BEGIN
DECLARE @res INTEGER
SELECT @res = count(*) FROM tbl_CCards where username=@username AND
password=dbo.ud_MakeSHA1(@clear_pass)
IF @res > 1 SELECT @res= 0
RETURN @res
END
Проверяем исполнением команды:
SELECT dbo.ud_CheckUser (‘anna’,’kolbaska’)
>1 (неправильно)
SELECT dbo.ud_CheckUser (‘anna’,’love’)
>0 (окейно!)
К шифрованию номера кредитной карты надо подойти более серьезно. Впрочем, мы
не будем вникать в различного рода стандарты по информационной безопасности в
платежно-карточной сфере (вроде PCI; хотя организации, работающие с кредитными
картами, безусловно обязаны это делать). В бесплатной версии XP_CRYPT существует
возможность генерации только 256-битного ключа RSA. Вот этим и можно
воспользоваться (пусть упомянутый стандарт и требует, как минимум, 768-битного
ключа). Я бы мог сейчас привести код по генерации публичного и приватного ключа,
но… поступим проще. Все действия можно выполнить из понятного графического
интерфейса, и во многих случаях оставить все на совести программы, не написав ни
строчки кода. И поверь, будет работать!
Пример из личного опыта
Сотрудниками одной из компаний платежно-карточного сектора велась база данных
для выдачи зарплат. Для простого понимания, – пусть это будет примерно следующая
структура:
ID LastName FirstName Emp
Sum
354 Somov Oleg
IT-Manager M0x8900f56543
643 Antipova Alexandra Director
4343Lax#dsdsss
411 Timurov Valeriy Technical Dep.
0x2322322222
Выборку из базы я привел абсолютно произвольную, а теперь суть идеи.
"Безопасниками" компании было предпринято вполне благородное решение – шифровать
данные о зарплатах, которые очень часто бывают "серыми". Инсайдер получил доступ
к базе и сильно обломался, заимев информацию в таком виде. Однако, он не
отчаялся и проделал следующий фокус. Резонно предположив, что человек с
должностью директора должен получать больше, чем простой менеджер, он поменял
соответствующие поля со значениями зарплат одно на другое, тем самым – подложив
бухгалтерскому отделу абсолютно левую информацию. В благополучный день такая
вещь прокатила, и все безопасники были уволены. Для справки: этим сотрудником
был не я, как впрочем, и не безопасником.
Так делать не стоит
В SQL Server можно создавать четыре типа объектов (хранимые процедуры,
представления, пользовательские функции и триггеры) с параметром WITH
ENCRYPTION. Этот параметр позволяет зашифровать определение объекта таким
образом, что тот можно будет использовать, но получить его определение
стандартными способами станет невозможно. Это средство рекомендуется и
Microsoft. К сожалению, на практике никакой защиты применение стандартных
средств шифрования не обеспечивает! Алгоритм, используемый при шифровании
определений объектов, выглядит так:
- SQL Server берет GUID той базы данных, в которой создается объект, и
значение столбца colid таблицы syscomments для создаваемого объекта (чаще
всего, его значение – 1 или 2) и производит их конкатенацию; - Из полученного значения генерируется ключ при помощи алгоритма SHA;
- Этот хеш используется в качестве входящего значения при применении еще
одного алгоритма хеширования – RSA. С его помощью генерируется набор символов,
равный по длине шифруемому определению объекта; - С этим набором символов и с реальным определением объекта производится
операция XOR. В результате получаются данные, которые помещаются в столбец
ctext таблицы syscomments.
У этой схемы есть два слабых места:
- Нам ничего не мешает заиметь исходные значения (GUID и colid) для
выполнения тех же самых операций и получить ключ на расшифровку. Это можно
сделать, например, использовав утилиту dSQLSRVD. Правда, для получения GUID
базы данных (и для запуска этой утилиты) нам нужны права системного
администратора; - Если у нас есть права на создание объектов в базе данных, можно
сгенерировать точно такой же ключ для объекта, определение которого нам уже
известно (путем сравнения шифрованного определения с незашифрованным). Ну и –
использовать его для расшифровки значения другого объекта.
Как можно расшифровать зашифрованные объекты на SQL Server? Есть два
варианта:
Как предотвратить слив базы данных суперпользователями
Привилегированные пользователи баз данных нередко становятся объектами атак хакеров или сами, пользуясь расширенными правами, эксплуатируют информацию не только в служебных целях. Существует несколько эффективных способов закрытия этих уязвимостей, среди которых можно выделить установку DLP-системы, разграничение доступа, а также ограничение прав суперпользователей до необходимых и достаточных, но удобнее всего автоматизировать защиту от возможных утечек информации из баз данных с помощью коробочных решений, например СУБД Jatoba от компании «Газинформсервис».
Введение
Утечка данных грозит бизнесу серьёзными финансовыми потерями и репутационными рисками. Для собственников бизнеса давно не секрет, что в утечке значимой информации из компании чаще всего виноваты не хакеры или неисправности систем, а сами сотрудники организаций.
По данным исследования «СёрчИнформ», в первом полугодии 2020 года более чем в 90 % российских компаний «утекли» базы с данными клиентов, персональные сведения о сотрудниках или финансовые документы. Авторы исследования утверждают, что в 60 % случаев причиной стали намеренные действия сотрудников, а 40 % утечек произошли по причинам невнимательности и доверчивости.
В условиях удалённой работы, когда контролировать персонал становится всё сложнее, риски таких умышленных и неумышленных утечек информации растут в геометрической прогрессии. Особого внимания к себе требуют специалисты работающие с базами данных, ведь именно там хранится информация, которую чаще всего стараются захватить с собой увольняющиеся менеджеры и управленцы.
Несанкционированное копирование базы данных сотрудниками компании считается внутренней утечкой данных. Полностью обезопасить себя от таких случаев нельзя, но можно существенно снизить риски их реализации. Для этого достаточно выполнять простые правила: разъяснять сотрудникам их персональную ответственность за разглашение сведений, контролировать потоки исходящей информации, предоставлять доступ к данным в соответствии с иерархией и функциональными обязанностями сотрудников, контролировать тех, кто по роду своей работы осуществляет функции контроля за различными информационными системами.
Раскроем подробнее смысл каждой из описанных мер.
Разработка системы документов в области обеспечения информационной безопасности
Системный подход к обеспечению информационной безопасности в компании позволит существенно снизить риски в ИБ без затрат на покупку специализированных продуктов. Введите в компании режим защиты коммерческой тайны, подготовив специальную документационную базу, в которой будет чётко описано, какие сведения являются коммерческой тайной, кто и как обязан её защищать, передавать, использовать, какие санкции будут применяться к тем, кто нарушил правила работы с ней. Разработайте и подписывайте с каждым из сотрудников и с контрагентами договор о неразглашении коммерческой тайны (NDA).
Установка DLP
Программное решение такого класса отслеживает попытки передачи информации посторонним. Программа будет проверять в режиме реального времени все операции, блокировать подозрительные действия и уведомлять о нарушениях со стороны ответственных за защиту от утечек данных.
К недостаткам DLP-системы можно отнести высокую стоимость её интеграции и невозможность установки на личные устройства сотрудников, то есть, работая удалённо, сотрудник сможет бесконтрольно передавать информацию при наличии доступа к ней. Отсюда вытекает ещё одно необходимое условие — разграничение доступа.
Разграничение доступа
Один из самых простых способов обезопасить ценную информацию — разграничивать доступ к данным и давать их сотрудникам только в том объёме, в котором это необходимо для работы. Например, передавать менеджеру не всю базу, а только контакты клиентов, с которыми он взаимодействует, или настроить уровни доступа к документации.
Ограничение прав суперпользователей при работе с базами данных
Решить вопрос с простыми пользователями обычно не представляется проблемой: ограничения требуют скорее управленческой воли, нежели сложных технических решений. Однако при работе с информационными системами, например базами данных (БД), всегда есть те, у кого больше прав, чем у всех остальных, так называемые суперпользователи. Им доступна информация скрытая от обычных сотрудников. Соответственно, и похитить данные им, как правило, проще.
Такими суперпользователями являются администраторы баз данных. Зачастую они единолично и всецело несут ответственность не только за бесперебойность работы, но и за целостность и безопасность хранения данных, определяют механизмы отказоустойчивости, политики резервирования, а также меры и инструменты для обеспечения нужного уровня защиты данных.
Безусловно, наличие прав суперпользователя у администратора оправданно и необходимо для реализации целого блока операций:
- выполнение бэкапов, выгрузка дампов;
- работа со статистикой;
- работа с объектами БД (рекомпиляция, перестройка, анализ ошибок).
Однако часто работодатели забывают, что для выполнения обязанностей администратору необязательно иметь доступ непосредственно к данным всех приложений.
Как же решить эту проблему? К сожалению, в продуктах Open Source часто отсутствует возможность как ограничения прав суперпользователей, так и в принципе разграничения ролей. Например, в СУБД PostgreSQL для пользователей с опцией SUPERUSER проверки прав и привилегий для конкретных объектов БД (таблицы, представления и пр.) не проводится совсем, что делает невозможным использование штатных механизмов ограничения через выдачу прав на объекты (GRANT\REVOKE). Таким образом, любой пользователь, обладающий ролью с опцией SUPERUSER, автоматически получает доступ ко всем таблицам всех баз данных. Складывается ситуация, когда не собственник бизнеса, а наёмный сотрудник может пользоваться базой данных компании практически без ограничений, а зачастую и без какого-либо контроля и отслеживания его действий. Не самое безопасное решение.
Важно отметить, что далеко не все проприетарные системы управления базами данных способны решить задачу ограничения суперпользователей в правах, но есть и исключения. Например, в отечественной СУБД Jatoba эта функциональность реализована при помощи модуля Jatoba Data Vault (JDV). Модуль обеспечивает внутренний контроль доступа всех пользователей со встроенной ролью SUPERUSER, которая присутствует в большинстве систем управления базами данных, построенных на ядре PostgreSQL. Подробнее о работе PostgreSQL с ролью «суперпользователь» можно узнать здесь.
Создать роль весьма легко – ниже представлена команда для её создания.
Принцип работы Jatoba Data Vault
Начинать работу необходимо с конфигурирования расширения. Для этого нужно указать требуемые параметры в конфигурационном файле БД и выполнить команду:
Далее в БД будут созданы встроенные роли dv_owner, dv_secanalyst и dv_acctmgr, а также схема jdv со служебной таблицей (jdv_table) и вспомогательными функциями.
Рисунок 1. Схема работы Jatoba Data Vault
Роль dv_owner необходима для работы с функциями расширения и модуля JDV.
Роль dv_secanalyst предназначена для мониторинга доступов и предоставляет возможность просматривать jdv.jdv_table (select from jdv.jdv_table). Пользователь dv_owner по умолчанию включён в роль dv_secanalyst и может назначать её другим пользователям.
Роль dv_acctmgr эксклюзивно получает права на CREATE / ALTER / DROP / ‘\password [username]’ для всех ROLE / USER, кроме dv_owner и включенных в неё ролей.
Все роли СУБД, которые имеют атрибут CREATEROLE до момента создания dv_acctmgr (включая SUPERUSER), теряют эту возможность.
При добавлении роли или объекта в политики JDV для них автоматически включается логирование (для схем по умолчанию логирование не задано). Модуль JDV позволяет гибко настраивать логирование. После включения опции JDV для роли dv_owner становятся доступны следующие функции управления списком защищаемых таблиц:
- добавления в список защищаемых таблиц;
- удаления из списка защищаемых таблиц;
- установки разрешения на работу с таблицей;
- сброса разрешения на работу с таблицей.
Все таблицы, добавленные в список защищаемых, будут дополнительно проверяться на наличие у пользователя прав доступа. Даже если пользователю выдали явные права на работу с таблицей (через grant) без дополнительного разрешения от владельца (db_owner), доступ не будет работать, будет возникать ошибка «ERROR: permission denied for table [tablename]». Такая же ошибка будет возникать для пользователей с ролью SUPERUSER.
Jatoba Data Vault учитывает нюансы архитектурных особенностей ядра СУБД, в частности: ограничение доступа к данным работает в том числе для секционированных (partitioning) таблиц, контролирует выдачу прав через наследование. Дополнительные правила и политики JDV ограничивают доступ к защищаемым данным даже для пользователей с самыми широкими полномочиями.
Для обеспечения безопасности на уровне ролей администратор информационной безопасности также получает и роль dv_acctmgr, которая эксклюзивно имеет право на полный контроль учётных записей. То есть SUPERUSER не может сделать нового пользователя или поменять пароль, чтобы в итоге стать тем пользователем, который имеет доступы к закрытым данным.
Использование подобных модулей, позволяющих разграничивать права доступа даже для привилегированных пользователей, не только даёт собственникам бизнеса возможность повысить уровень информационной безопасности компании и уменьшить вероятность несанкционированного использования служебной информации, но и обеспечивает соблюдение Приказ №21 от 18.02.2013 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных», мер УПД.5 «Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы» и УПД.4 «Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы».
Подробнее о продукте СУБД Jatoba и его функциональных возможностях можно узнать на сайте компании «Газинформсервис».
Выводы
Мы рассмотрели несколько методов противодействия утечкам критически важной информации по вине суперпользователей баз данных. Это важный вектор внутренних киберугроз, и желательно использовать комплекс мер, чтобы исключить случайное или намеренное раскрытие важных сведений.
Рекомендуется разработать план внедрения необходимых процессов и программного обеспечения и реализовать его: от модели угроз, которые могут быть реализованы через таких привилегированных пользователей, до проверки закрытия уязвимостей информационной системы предприятия с помощью контрольного пентеста.
Авторы:
Денис Рожков, руководитель разработки компания «Газинформсервис»
Георгий Тарасов, ведущий разработчик группы СУБД компании «Газинформсервис»
Что сделать чтобы пользователь не подвесил бд
Защищаем MySql. Шаг за шагом
- База данных MySQL будет использоваться только PHP приложениями, установленными на том же самом хосте;
- Для управления базой данных будут использоваться стандартные административные средства, типа mysqladmin, mysql,mysqldump и т.д.;
- Для удаленного резервирования MySQL данных будет использоваться SSH протокол.
- база данных mysql должна быть выполнена в chrooted среде;
- процессы mysql должны выполняться под уникальным UID/GID, неиспользуемым никаким другим системным процессом;
- Должен быть разрешен только локальный доступ к mysql;
- Основная учетная запись mysql должна быть защищена “сложным” паролем;
- Будет переименована учетная запись администратора;
- Должен быть заблокирован анонимный доступ к базе данных (используя учетную запись nobody);
- Должны быть удалены все типовые базы данных и таблицы.
pw groupadd mysql
pw useradd mysql-c » mysql Сервер «-d/dev/null-g mysql-s/sbin/nologin
./configure —prefix=/usr/local/mysql —with-mysqld-user=mysql —with-unix-socket-path=/tmp/mysql.sock —with-mysqld-ldflags=-all-static
make
su
make install
strip /usr/local/mysql/libexec/mysqld
scripts/mysql_install_db
chown -R root /usr/local/mysql
chown -R mysql /usr/local/mysql/var
chgrp -R mysql /usr/local/mysql
cp support-files/my-medium.cnf /etc/my.cnf
chown root:sys /etc/my.cnf
chmod 644 /etc/my.cnf
/usr/local/mysql/bin/mysqladmin -u root shutdown
mkdir -p /chroot/mysql/dev
mkdir -p /chroot/mysql/etc
mkdir -p /chroot/mysql/tmp
mkdir -p /chroot/mysql/var/tmp
mkdir -p /chroot/mysql/usr/local/mysql/libexec
mkdir -p /chroot/mysql/usr/local/mysql/share/mysql/english
chown -R root:sys /chroot/mysql
chmod -R 755 /chroot/mysql
chmod 1777 /chroot/mysql/tmp
cp/usr/local/mysql/libexec/mysqld/chroot/mysql/usr/local/mysql/libexec/
cp/usr/local/mysql/share/mysql/english/er rmsg.sys/chroot/mysql/usr/local/mysql/share/mys ql/english/
cp/etc/hosts/chroot/mysql/etc/
cp/etc/host.conf/chroot/mysql/etc/
cp/etc/resolv.conf/chroot/mysql/etc/
cp/etc/group/chroot/mysql/etc/
cp/etc/master.passwd/chroot/mysql/etc/passwords
cp/etc/my.cnf/chroot/mysql/etc/
cd /chroot/mysql/etc
pwd_mkdb -d /chroot/mysql/etc passwords
rm -rf /chroot/mysql/etc/master.passwd
ls -al /dev/null
crw-rw-rw- 1 root sys 2, 2 Jun 21 18:31 /dev/null
mknod /chroot/mysql/dev/null c 2 2
chown root:sys /chroot/mysql/dev/null
chmod 666 /chroot/mysql/dev/null
cp-R/usr/local/mysql/var//chroot/mysql/usr/local/mysql/var
chown-R mysql:mysql/chroot/mysql/usr/local/mysql/var
chrootuid /chroot/mysql mysql /usr/local/mysql/libexec/mysqld &
skip-networking
backuphost$ ssh mysqlserver /usr/local/mysql/bin/mysqldump -A > backup
socket = /chroot/mysql/tmp/mysql.sock
chrootuid /chroot/mysql mysql /usr/local/mysql/libexec/mysqld &
/usr/local/mysql/bin/mysql -u root
mysql> SET PASSWORD FOR root@localhost=PASSWORD(‘new_password’);
mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host=»localhost» and user=»root»);
mysql> flush privileges;
mysql> update user set user=»mydbadmin» where user=»root»;
mysql> flush privileges;
Что делать, чтобы не сотрудники не уводили клиентов. Защита базы данных клиентов
Я расскажу о последних новостях и публикациях.
Читайте меня, где угодно. Будьте всегда в курсе главного!
Всегда говорю, что защищать бизнес системно всегда дешевле, чем тушить пожары.
Поскольку в течение этого года ко мне неоднократно обращались предприниматели по вопросу защиты баз данных, клиентских баз, а также минимизации потерь от кражи таких баз, от того, что сотрудники уводили клиентов, сегодня расскажу как защититься от кражи клиентской базы.
Под клиентской базой, чтоб вдруг ни у кого не возникло недопонимания, будем понимать совокупность сведений о клиентах компании, когда-либо вступавших в отношения, либо потенциальных клиентах.
Собственно в интернете можно найти много готовых баз по самым разным интересам, можно собрать их самостоятельно из открытых источников и даже купить чужие, украденные базы.
Для предпринимателя, как мне представляется, ценность базы и в том, что сведения, содержащиеся в ней не известны конкурентам, так и в том, что продажа по готовой базе менее трудозатратна.
Хотя есть и ряд стереотипов, например, что клиентская база не такой ценный ресурс, вроде как ее и заново можно собрать. Но предприниматели, которые считают деньги, знают, что дешевле продать тому, кто у тебя уже что то купил, чем вновь привлеченному клиенту.
Некоторые вовсе считают, что с утечкой базы ничего нельзя сделать, что также в корне неверно, и об этом пойдет речь ниже.
Учитывая ценность обладания такой информацией гипотетически может возникнуть ситуация, когда появляются желающие монетизировать такое обладание клиентской базой.
Убежден, что хищение клиентских баз носит повсеместный характер, причем во всем мире. Где-то читал исследования, согласно этим исследованиям половина сотрудников крадет данные и почти столько же планируют использовать их на новой работе после увольнения. Вроде как я участвовал в сборе базы, значит я тоже могу ей пользоваться по своему усмотрению.
Утечки данных происходят в бизнесах любого масштаба, потери данных носят повсеместный характер, потому что их практически не охраняют, микро и малый бизнес вовсе не имеют бюджета, а также компетенций для защиты таких активов.
Многие предприниматели сталкивались с тем, что работник, имеющий доступ к клиентской базе при переходе на новую работу копировал базу с фамилиями, телефонами и e-mail клиентов. Примечательно, что большинство сотрудников даже нарушением это не считает.
Риски в данном случае появляются не только в части недополучения повторных продаж, но и возможны ситуации, что клиенты жалуются, что из данные, попадают в открытый доступ.
Защитить клиентскую базу от копирования непросто, но возможно.
Волшебной таблетки, конечно, нет, но задача собственника отбить у потенциальных воришек желание копировать базу.
ПРИЧИНЫ КРАЖИ КЛИЕНТСКИХ БАЗ
По статистике главными причинами утечек баз данных являются халатность и злой умысел со стороны сотрудников
Взять, например, отдел продаж. Именно сотрудники отдела продаж генерируют основные продажи, находят покупателей и заказчиков, заключают договоры.
Но они же представляют и самую большую угрозу для клиентских баз в силу того, что у них есть доступ к этому ресурсу. Да, чаще всего именно менеджеры уводят клиентов.
Как мне представляется, возможны как правовые, так и управленческие механизмы минимизации риска кражи базы клиентов.
Если разбираться в том, что служит причиной кражи либо переманивания клиента, станет понятно что необходимо делать, чтобы минимизировать риски.
Я не буду в статье касаться управленческих механизмов, не моя специализация, хотя понятно, что если компания предлагает клиентам более выгодные условия работы, цену, чем недобросовестный сотрудник, пытающийся увести клиента, то клиент продолжит работать с компанией.
Не буду касаться вопросов, связанных с наймом работников, думаю, что всем понятно, что если прямо спрашивать у кандидатов на должность продажника придет ли он со своей базой, то в случае положительного ответа из вашей компании он также уйдет с клиентской базой с вероятностью 100%.
Оставлю соответствующим специалистам вопросы, касающиеся полиграфов, при приеме на работу, настройку доступов и распределение ролей в CRM, введение учета рабочего времени, с логированием всех действий но компьютере работник и пр., а расскажу основные правовые методы.
ЗАКОННЫЕ СПОСОБЫ ЗАЩИТЫ КЛИЕНТСКОЙ БАЗЫ
В действующем законодательстве есть такое понятие как коммерческая тайна, так вот необходимо корректно ввести такой режим коммерческой тайны.
Чтобы его ввести необходимо определить перечень сведений, которые как вы полагаете являются ценными в силу их неизвестности третьим лицам.
Этот перечень, конечно, может не ограничиваться сведениями о клиентах, более того, целесообразно его расширить иными сведениями о производстве, управлении, планах, финансах, партнерах, переговорах, договорах, ценах, технологиях и прочих.
Затем необходимо разработать и утвердить положение о коммерческой тайне, где описать порядок работы с документами, содержащими коммерческую тайну, а также ответственность за нарушение порядка.
Обязательно пометить все документы, а также иные носители коммерческой тайны грифом «Коммерческая тайна».
Все сотрудники также должны подписать лист ознакомления с положением, а также подписать соответствующее соглашение.
Затем необходимо документально зафиксировать, например, мы это делаем актом, некоторые ведут соответствующие журналы, факт допуска к носителям коммерческой тайны.
Сложность функционирования режима коммерческой тайны, по моему опыту, заключается именно в реализации положений, устанавливающих порядок работы с документами, содержащими коммерческую тайну. Полагаю, что это задача руководителя сделать так, чтобы работники не могли не соблюдать Положение о коммерческой тайне.
Чтобы в случае суда не оказаться проигравшей стороной, доступ к базе клиентов должен быть ограничен, поскольку если будет установлено, что база клиентов находилась в открытом доступе суд не сможет защитить интересы собственника.
В регламентах сотрудников должны быть прописаны положения по соблюдению режима конфиденциальности и во взаимоотношениях с любыми другими третьими лицами. Заключая договор с контрагентами также необходимо подписывать соглашение о неразглашении, а не ограничиваться двумя абстрактными предложениями в тексте основного договора.
Очевидно, что такой серьезный подход вызовет скорее уважение в глазах партнеров вашей компании, поскольку свидетельствует о вашем отношении к важности информации.
Занижу градус ожиданий, соглашения о конфиденциальности, так называемые NDA, не очень то работают в России, в том числе и потому, что хоть организации и констатируют факт введения режима конфиденциальности, положения и правила предусмотренные этим режимом не соблюдают.
При этом подавляющее большинство обращений связано с просьбой создать документ, в котором будет прописана ответственность за нарушение положений о коммерческой тайне, за незаконное копирование и распространение клиентских баз.
Очевидно, что чисто психологически наличие такого документа может остановить большую часть сотрудников, которые потенциально могли бы скопировать базу, но подписав соответствующий документ, получив его на руки и детально ознакомившись с которым побоятся нарушать договоренность, увести клиента.
И просто не забывайте напоминать сотрудникам, что копирование клиентской базы незаконно, а с негативными правовыми последствиями они могут ознакомиться в их экземпляре соглашения.
Преимущества введения режима коммерческой тайны на самом деле не ограничиваются восторженными взглядами ваших партнеров.
Например, можно отказать в предоставлении информации ряду контролирующих органов (сразу скажу на налоговую не распространяется) ссылаясь на то, что у вас введен режим конфиденциальности, при этом предложить в судебном порядке затребовать такие сведения, объяснив суду необходимость такого запроса.
У меня недавно было дело, заказчик по госконтракту затребовал сведения об организациях, у которых закупался товар и копии всех документов, обосновывая это тем, что у него якобы имелись подозрения в сговоре и завышении цены. После отказа в предоставлении документов заказчик обратился в суд, где ему было отказано.
В завершение отмечу, что коллеги также рекомендуют оформлять клиентские базы в качестве нематериальных активов, документально подтверждая, что базы были именно приобретены на законных основаниях. Вроде как в случае копирования таких баз, деяния злодеев могут быть квалифицированы по ст. 158 УК РФ (кража), либо 165 УК РФ (причинение имущественного ущерба путем обмана или злоупотребления доверием».
Не скажу есть ли перспектива привлечения недобросовестных сотрудников по данным статьям уголовного кодекса, но совершенно точно будет не лишним объяснить всем сотрудникам какие санкции предусмотрены данными статьями, начинающимися от 800 000 рублей штрафа до пяти лет лишения свободы.
Подписывайтесь на меня в соцсетях
Задавайте вопросы в комментариях или звоните 8 906 767 45 66.
Обращайтесь, если понадобиться помощь в введении режима конфиденциальности.
Можно ли ограничть подключени к БД с сервера только одним пользователем?
Есть сеть, а в сети есть сервер, который досутпен всем и БД Oracle.
Хочется сделать так, чтобы с этого сервера можно было подключаться только одним конкретным техническим пользователем. Подключения с других серверов не должны ограничваться.
Можно наверное написать триггер на логон, который будет отклонять все сесии с указаного сервера, если подключается не тех. уз. Однако, это выглядит ужасным решением.
Возможно у Oracle есть какие нибудь настройки безопасности или еще что-то, что позволит органичть подключение?
Краткое напоминание, что происходит, если с именем пользователя БД выполняется комманда connect .
Сначала, посредством Oracle Net, устанавливается сетевое соединение (сессия). Через это соединение происходит всё дальнейшее общение между клиентом и БД.
Клиент посылает запрос авторизации пользователя в БД, на основании которого создаётся новая сессия БД.
На первом шаге возможно ограничить доступ только на уровне протокола: IP, имя хоста, доступные сервисы БД. Но никак нельзя ограничить по имени пользователя, так как оно на этом шаге пока неизвестно.
Из этого следует, что на стороне сервера БД огранничить возможно только при авторизации пользователя (шаг два) посредством логон триггера. Например:
Попытки подсоединится с хоста с заданным IP будут отклонены:
Возможно, что лучшее алтернативное решение будет: ввести ограничения на подключение к БД на стороне сервера приложений, как средствами ОС, так и самого приложения.