Последний вопрос: будет ли дешифровка происходить на клиенте(libpq), или ключ

будет обрабатываться на сервере?

Всё, что выполняется в виде sql-запросов, происходит на сервере, входные параметры и сам текст запроса, а также результаты запроса (если только вы не план строите с explain analyze) будут и на клиенте, и на сервере (в памяти).

это печально с точки зрения безопасности

Дешифруйте на клиенте если хотите , что мешает?

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

Вы клиенту доверяете больше чем серверу? У вас там мессенджер с end-to-end шифрованием или что? Мне кажется, в большинстве продуктов доверия больше к серверу, т.к. клиентам доступ имеют больше людей.

Кроилово ведёт к попадалову.

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

Ну, добавьте TLS в канал связи. Для самоуспокоения.

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

1) Нет, по умолчанию вообще SSL в pg_hba не написан, да и сертификатов надо положыть. 2) Потому, что постгрес — это SQL-сервер. Клиенты — это проблемы клиентов, он вообще этим не занимается.

Например, есть масса клиентов, в которых нет вообще ни строчки из libpq и кода от сообщества. Тот жэ джавовский, плюс есть нативные клиенты на Tcl и вроде js.

А jdbc.postgresql.org это типа не сообщество ) ?

так речь о нативной клиентской библиотеке, очевидно, что за сторонние клиенты сообщество не отвечает

Не то, которое постгрес делает.

TLS -это дополнительные накладные расходы на транспорт, большинству это не нужно, т.к. обычно к субд подключаются по контролируемому каналу. Если надо подключаться "из интернета", то правильнее поднять vpn, чем светить наружу портом PostgreSQL (пусть даже с изменённым номером). Что касается обработки на стороне клиента - это вам к sqlite и т.п. решениям (но там и данные будут у клиента). Серверные реляционные субд выполняют запросы на сервере, на клиенте выполняются только действия, связанные с представлением получаемого от сервера потока байт в удобоваримую форму. Естественно, никто не мешает вам хранить в бд двоичные зашифрованные данные и на клиенте кодировать/закодировать, но при этом для субд это будет просто набором байт и, например, пофильтровать по ним уже не выйдет (кроме как проверки на равенство/неравенство).

Судя по намёкам — vpn там ужэ есть, пвтор его просто в чём-то подозревает.

В нативной клиентской библиотеке не будут появляться фичи, трудно(не)реализуемые в сторонних клиентских библиотеках и относящиеся к непосредственно обработке данных. Это тупо снижает применимость субд.

да, сетка условно внутренняя, но внутри бегают аутентификационные данные, по этому лучше перестраховаться, да и от ИБ наверняка будут вопросы

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

Шифрование канала есть в виде TLS (и его, по идее, должны поддерживать большинство клиентов), а шифровать отдельные значения - это несколько странная задача для (драйвера) субд. Если вам такое нужно - вы вольны делать это в коде, который непосредственно работает с драйвером.

да, наверное, Вы правы, просто я до последнего надеялся что в код лезть не придётся:)

Вы понимаете, что есть ненулевой шанс что то, что вы прикрутите, будет уязвимее TLS-шифрования подключения между БД и клиентом?

я писал про стандартные механизмы шифрования, в том числе и аппаратного, но, да, Вы правы, наверное это логичнее всёж на откуп приложению отдать, придётся вспоминать программирование.

TLS - это стандартный поддерживаемый механизм

tls это стандарт защиты канала, я же немного про другое -- про защиту данных, она может применяться для разных целей, от защиты от неавторизированных клиентов до каких-либо экзотических кейсов

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

это мой кейс, да, и tls его решает, но если смотреть чуть шире, то возможны и другие кейсы, это я к тому, что данный функционал может быть востребован не только в моём единичном случае попытки скрещивания ежа и ужа:))

Любое секьюрити начинается с проработки оценки всесторонних потенциальных векторов атаки (в т.ч. тех, которые вы закрыли теми или иными средствами), их вероятностей, критичности и возможного ущерба. В т.ч. в некоторых случаях оценивают trade-off между возможностью безвозвратной потери данных и их утечки. В идеале, если секьюрити важна, это должен быть поддерживаемый (обновляемый и аудируемый) внутренний документ. А без такого подхода, у вас не от чего отталкиваться и вы либо оставляете части системы менее защищёнными чем следовало, либо занимаетесь оверинжинирингом (либо ваш архитектор - гений, интуитивно чувствующий такие вещи).

допустим база это DBaS, вполне себе типичная ситуация, разве не так?