Андрей, замечательное уточнение. Ну, дропать таблицу фронтенду, по правилам, наверное, не требуется, но удалять отдельную запись - может требоваться.
Но тут другой вопрос интересный есть: нет механизма "принуждения" вебморды к тому чтобы все было безопасно. Поэтому на этапе проектирования, естественно, все хотят все безопасно делать, а на этапе эксплуатации часто все становится не так хорошо в плане безопасности, как хотелось бы. (напр, когда-то может потребоваться полный доступ на базу для отладки, а потом забыли убрать). А вот работа через API позволяет четче это разделить и усложняет незаметное неправильное использование.
Да, я именно о прослойке и говорю.
Либо прослойка (API) вообще базу изолирует, либо же отдельная ценная таблица (customers) за ней, а всякие с публичными и техническими данными - можно и локально на вебсервере.
Так если оно не используется фронтендом - можно просто исключить доступ к этим полям, для надежности. То, что захешировано - можно ведь все равно подобрать (имен - фамилий не так уж много, по крайней мере популярных, телефонных номеров - диапазон короткий). Хеш - защищает, конечно, но не так как полное отсутствие/недоступность данных.
profesor08, вот в том что я предлагаю (вижу в своих мечтах), в пределах сессии, можно получить доступ только к той записи, с которой я прошел аутентификацию.
То есть, наше веб приложение дергает метод /api/login (передает логин и пароль). Получает некий sessid (если все успешно). Затем дергает /api/profile и получает данные о пользователе. Именно о том, который в /api/login был. (Там userid даже не передается). Чтобы получить профайл другого юзера, надо успешно залогиниться как другой юзер, то есть, знать его пароль.
Более сложная ситуация:
Если же у нас есть оператор (ну как оператор в сбербанке, к которому может прийти любой клиент сбера, даже из другой страны), то для оператора будет метод вроде /api/customer_profile/. Но при этом можно сделать счетчик обращений. Оператор в день обслуживает N клиентов в среднем, можно разрешить получить данные для 2*N, следующий (2*N+1) запрос к /api/customer_profile уже не пройдет и вызовет какой-то алерт. Операционистка сбера, даже зная уязвимость в приложении, не может слить всех клиентов.
Насколько я знаю (но может плохо знаю) у обычных СУБД нет механизмов для подобных ограничений.
Антон Р., хешировать только пароль можно. Даже ФИО пользователя уже не захешируешь, т.к. приложение должно с ними работать. Либо придется шифровать, но при этом ключ хранить рядом с замком, что не слишком-то помогает.
Это же, если правильно понимаю, прослойка между приложением (базой) и ядром, чтобы доступ к объектам ОС (файлам) контролировать? А в том случае, который я имею в виду, надо в пределах таблицы доступ ограничивать и по частоте обращений, и по строкам.
Хеши тоже довольно полезные. Да и ФИО, адреса - в общем, в базе довольно много того, что если удастся получить в большом количестве - то можно использовать.
Идея в том, что у API в принципе нет метода (по крайней мере доступного для фронтенда) чтобы сделать то, что фронтенду не нужно (напр, получить всех юзеров или дропнуть таблицу). Поэтому обращаться некуда.
Сделать доступ к записи пользователя только после его аутентификации - возможно? А лимитировать "дать не более 100 записей из табл. customers" за день ?
По производительности: у меня сейчас идея как раз в том, чтобы только маленькую часть данных (самую конфиденциальную) так надежно защищать, поэтому, даже если логин будет происходит не 0.01s а 10s - это все равно терпимо. А 90-99% данных могут быть по прежнему в базе, пусть даже утекают - их утечка мало что даст.
database firewalls прямо звучит как надо :-) Еще вопрос: а что-то опен-сорсное, бесплатное есть в этой сфере? По первому впечатлению, Imperva - это что-то для компаний типа боинга или кока-колы, за миллионы долларов.
Проблема в том, что я наверняка не знаю, что у меня жрет ресурсы. Сервер (VPS) при не очень высокой нагрузке более-менее нагружен. И у меня есть подозрение, что это связано с логированием (возможно, это и есть стадия "логи начали влиять на производительность"), но я в нем не уверен (возможно, другие части приложения грузят базу, и база тормозит не потому что загружена логами, а по иной причине).
Можно ли как-то посмотреть/сравнить сколько ресурсов отжирает работа с каждой таблицей?
Погляжу, спасибо, но предварительно эта идея кажется оверкиллом. Логи в моем случае очень маленькая и не очень важная часть приложения, и разворачивать целый стек ПО для этой задачи - "ну такое"...
Примерно как для шелл скрипта вся схема логирования - это код: echo `date` message >> $LOG
Тут, мне кажется, проблема не с CORS а с OPTIONS. Запрос на OPTIONS возможно не доходит от вебсервера до этого куска кода. Под каким вебсервером крутится это приложение? Может быть такое, что код исполняется только для методов GET/POST но не для OPTIONS?
RoffDaniel, bad ownership or modes for chroot directory component "/var/kov-mc/"
Вот и ответ. Надо медитировать на тему владельца-группы и прав доступа /var/kov-mc/
В целом, я с вами согласен, это все разумно. Но вот в моем случае, похоже, не подойдет:
1. Stress тест
Приложение сейчас хостится на VPSках. Соответственно, тут две стороны - с одной, на дешевой VPS в предел производительности мы точно можем упереться довольно легко. С другой - всегда есть решение в виде простого апгрейда тарифа на более мощную VPS. (Но мне, технически, конечно хотелось бы заранее знать, что архитектура у меня такая, что масштабироваться будет легко, даже когда дальше уже некуда апгрейдиться). А вот stress-тест сделать на облачной базе - можно ли? Или выйдет достаточно дорого (ведь нужно ее забить огромными объемами) ?
2. Read Only запросы
Увы, приложение по большей части собирает данные. Конечно, иногда и отдает тоже, но в обычном случае, наверное, на 100-1000 read есть один write, а у меня наоборот.
Хотя кто потом будет читать этот вопрос, для них это, возможно, будет правильными советами, сам так считаю.
Но тут другой вопрос интересный есть: нет механизма "принуждения" вебморды к тому чтобы все было безопасно. Поэтому на этапе проектирования, естественно, все хотят все безопасно делать, а на этапе эксплуатации часто все становится не так хорошо в плане безопасности, как хотелось бы. (напр, когда-то может потребоваться полный доступ на базу для отладки, а потом забыли убрать). А вот работа через API позволяет четче это разделить и усложняет незаметное неправильное использование.