psql и че-то не допирает...

← →
RUNaum © (2006-05-21 20:48) [0]

Короче )

Есть БД psql, там таблицы с данными биллинга. Пишу клиент (для юзеров, IP-статические) к сей БД. Создаю юзера user_bil, даю права only read только на те таблицы, с которых буду формировать локальное представление детализации по потреблению трафика. Вот тут возникает трабла )

1. Данные в таблицах лежат смешанно. Т.е. все ипы в кучу, что есть гуд, imho.

2. Данные "конфиденциальны"

Поэтому если кто-то каким либо способом (буть то сниффер / дизасм клиента) определяет login/pass моего read only юзера - получает доступ к конфиденциальным данным.

Как быть? Может у кого есть идеи? Неужели никак кроме реструктуризации данных? Заранее спасибо, если кто откликнется.

з.ы. Проект не коммерческий.

← →
Desdechado © (2006-05-21 20:56) [1]

1. что есть psql ?
2. чем реструктуризация может помочь в деле защиты соединения?

← →
RUNaum © (2006-05-21 21:01) [2]

1. постгря (но не суть, это может быть и MySQL / MS SQL)
2. преобразовать структуру к виду - таблица - хранит инфу об одном IP :) тогда завести n-пользователей класса read only и дать им права только на свои таблицы, чтобы не усмотрели чужих данных.

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

← →
Sergey Masloff (2006-05-21 21:04) [3]

1) При чем тут дизассемблирование клинта? Пароля-то в нем нет
2) присоединяюсь к Desdechado © (21.05.06 20:56) [1] п.2

← →
RUNaum © (2006-05-21 21:09) [4]

Как это нет =) Еще как есть. Клиент (ПО, стоящее на машине пользователя) под login/pass"ом read-only юзера коннектится к БД для формирования детализации, которая в рюшечках будет предоставлена конечно пользователю.

про реструктаризацию указал в предыдущем посте.

← →
RUNaum © (2006-05-21 21:10) [5]

read-only юзер один ) логично заводить было бы под каждого пользователя свой акк в БД, но смысл, если данные лежат в "куче"? ) вот тут то и прошу совета. вдруг кого осенит.

← →
Desdechado © (2006-05-21 21:24) [6]

по таблице на IP - это полный изврат

если нужно показывать каждому пользователю свои строки, формируй запросы, например, с
WHERE ... AND IP=:IP_машины_откуда_запрос
если я правильно понял, о чем речь

зашивать пароль в код - обычно чушь, хотя иногда (в однопользовательском варианте) бывает

← →
RUNaum © (2006-05-21 21:35) [7]

понимаю что изврат, еще бы =))

а куда девать то его если не в код? выносить наружу? да одна фигня ( акк один, пользователей много.

проблема в том, что запрос то я могу таким образом сделать, но это не нужно )) а вот если упрут пароль от этого read only юзверя - то direct-доступом (из под того же Navicat / EMS, если рассматривать пример с MySQL) получат данные к конфиденциальной информации =(

черрт побери...

← →
Desdechado © (2006-05-21 21:59) [8]

> акк один, пользователей много.
одна учетная запись на всех - тоже неправильно

> то direct-доступом получат данные
для таких целей в оракле, например, есть RowLevelSecurity
у других серверов не знаю

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

> одна учетная запись на всех - тоже неправильно
понимаю. но в данном то случае почему не правильно? ) куча одна, пользователей кучи много, все имеют одни права, почему бы и не один акк?

по поводу прятания. сниффер к примеру и все, пиши пропало =) утек пароль. потому что все равно он либо зашит в программу, либо в защищенном хранилище - но он тем или иным образом передается на сервер. главное не дать паролю утеч.

можно конечно SSL замутить... хм... хех )

> сниффер к примеру и все, пиши пропало
сам-то пробовал?
не факт, что клиент отдает серверу при подключении именно пароль
как вариант, он может отдавать подсчитанный по известному им обоим алгоритму некий хэш, который подобрать тяжеловато будет

ну может ты и прав. сам не пробовал, слышал только ) но слухи уже придали мне немного неуверенности. короче решился на SSL + ныкание пасса внутрях.

psql и че-то не допирает... Найти похожие ветки