Представим обычное веб-приложение с базой данных. Люди логинятся, что-то делают через веб-интерфейс, это отражается в базе. Возникает вопрос безопасности. Защитить вебморду - сложно. Тут у нас сто тыщщ триллионов угроз, от SQL Injection, XSS дыр в Apache и бэкдоров в коде вебморды. Зато вот если БД стоит на отдельной машине - защитить ее уже проще (а вебсервер - хрен с ним, секреты-то у нас в БД).
Возникает очевидная идея, между "опасным" вебсервером (который никогда нельзя на 100% защитить), и базой данных поставить "прослойку", некий фильтр, файрволл. Который мог бы делать разное, например:
1. Разрешена проверка логина (SELECT COUNT(1) FROM users WHERE username='vasya' .... ), в базе для этого разрешен доступ к таблице users, но фильтр блокирует, скажем, SELECT * из нее. То есть, даже взломав вебсайт, нельзя украсть всю базу пользователей.
2. Защита от SQL Injection. В настройках фильтра прописаны типовые запросы, и если в ту же операцию проверки логина, удастся подсунуть юзернейм с SQL спецсимволами и запрос "извратиться" - такого запроса в списке разрешенных не будет, и фильтр его не пропустит.
3. Защита от XSS итд - для всех полей можно прописать их синтаксис (юзернеймы - "[a-z0-9]*"), и не получится вставить в базу "кривое" значение, которое бы "плохо" отобразилось потом в браузере.
4. Счетчики. Для той же операции логина, вебприложение может передавать фильтру "контекст" (например, IP адрес с которого пришел запрос), и фильтр может, например, блокировать попытки логина, если за час с одного адреса было более 10 попыток залогиниться с разными именами.
5. Фильтрация результатов. Например, нельзя в принципе приложению получить ответ от базы с более чем одной строчкой из таблицы users. Или получить из таблицы payments строчки с разными значениями userid (никогда юзеру Васе не нужно видеть платежи Пети).
6. Целостность баланса базы. Например, INSERT в таблицу заказов веб-магазина покупки на $100, выполнится только если только что в этой же сессии было успешно снято с баланса покупателя $100. Если каким-то магическим способом обновления таблицы балансов не было, а приложение пытается оформить покупку - то хрен вам и включаем сирены.
В принципе, всю это логику можно и в самом приложении в корячить, но нет гарантии, что приложение везде ее использует, и нигде не работает "в обход". И если вебсервер взломан (а это вероятно, т.к. он в Сеть смотрит) - то там уже просто не приложением могут работать а обычным клиентом типа mysql. Кроме того, удобно всю безопасность видеть и "рулить" в одном месте.
Мне кажется, интересная и полезная идея. Мне интересно - есть уже что-то такое (должно же быть, "все уже украдено для нас") или самому надо писать? Нашелся только сомнительный greensql.com (может, кстати, кто-то им пользовался, есть отзывы?)
