Капитан очевидность:
Реализуете ТОЛЬКО на уровне приложения и оставите полные права на уровне БД - готовьтесь огрести по-полной за утечку бизнес-информации.

Iceberg1985HawkmoonКапитан очевидность:
Реализуете ТОЛЬКО на уровне приложения и оставите полные права на уровне БД - готовьтесь огрести по-полной за утечку бизнес-информации.
Я не имею в виду открыть полный доступ на уровне БД. Я имею в виду, что буду ограничивать на уровне БД доступ к таблицам в целом, а на уровне приложения буду ограничивать по записям. В таком случае не грозит ли утечка информации?
Спасибо!

Ну вот это вроде как лучше. Хотя я бы все равно отобрал бы права на таблицы, создал бы хранимые функции, и только на эти функции давал бы права на доступ.
Функции Security definer

Тогда:
1. пользователь лезет не туда - прав нету, опа.
2. пользователь не может напрямую обратиться к табличкам.
3. пользователь лезет туда - получает выборку через хранимку (которая, ага, выполняется уже из-под прав того, кто имеет доступ к таблицам - но уже на уровне движка СУБД)
4. таким образом, написав хранимку, не подверженную SQL-инъекциям , получим более-менее защиту по правам.

Здесь жирный текст критичен, но он не так сложен к исполнению.

Если оставите же полный доступ к таблицам на уровне пользователя, и выборку в приложении, то система юзабельная, но нехакероустойчивая:

хакер ловит коннекшн-стринг, подключается с ним, и получает полный доступ к таблицам. В случае вышерассматриваемого сценария хакеру нужен будет логин/пароль не роли для приложения, а роли owner'а/суперпользователя.

Что рубится корректной настройкой PostgreSQL.

Iceberg19851. корректная настройка - это:
а) удаление или ограничение прав пользователя postgres, соответственно присвоение этому пользователю очень трудного пароля
суперпользователь должен быть. Соответственно, защищаем вЗлоМ0у$$т0i4ивbIм паролем, больше не ограничиваем.
Снести суперпользователя - огрести проблем. Это аксиома.
в) давать доступ извне только конкретным IP-адресам, настройка файрвола

Да.
б) настройка postgresql в соответствии с характеристикой сервера
г) использование для БД отдельного жесткого диска, для логов - другого жесткого диска

Имеет отношение к производительности, не имеет - к безопасности.
3. поискав в интернете, нашёл, что можно писать хранимые функции и на языке Python. Как это отразится на хакероустойчивость? Это лучше или хуже?
все равно. (см. SQL injection)

2. пример: допустим есть таблица create table a(k int primary key not null, n varchar(30), o varchar(100));
и допустим она заполнена некоторыми данными. Например у нас есть хранимая функция, которая выбирает из этой таблицы данные, соответствующие условию: выбирать из поля k значения, меньше 50: k<50.
CREATE OR REPLACE FUNCTION primer(t как писать_тип_таблица?)
AS $$
DECLARE

BEGIN
select * from a where k<50
END
$$
где_описывать_возвращение_функцией_таблицу_результата?
LANGUAGE plpgsql;


function ... returns setof a
где a = ваша таблица.
Для данного случая достаточно LANGUAGE sql;
главное - не устраивать динамическую конкатенацию запросов внутри (см. SQL injection)
Как с помощью хранимых функций дать доступ например web-странице?
также как и к таблице. Разница будет в том, что вместо select * from a пишите select * from primer()

Главное:
завести пользователя web_user, у которого отобрать права на a.
из под того, у кого есть права на a (например postgres), создать пример, при этом обозвав функцию security definer.
дать web_user права на primer()
подключиться из бек-энда под пользователем web_user.