Re: Permissions

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Permissions
Дата
Msg-id CAKFQuwbNvJHW_5Cq+nQaUkqrB642bJeywm27KWppk6=ZUa6XLA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Permissions  (Andre Labuschagne <technical@eduadmin.com>)
Ответы Re: Permissions  (Andre Labuschagne <technical@eduadmin.com>)
Список pgsql-novice
On Tue, Sep 20, 2016 at 2:17 PM, Andre Labuschagne <technical@eduadmin.com> wrote:

Hi David

Our usage of the terms is the exact opposite.

I am simply referring to the database being taken else mounted and accused.  We can refer to that as at rest.  If we restrict access when it has “left” the initial PG server and mounted onto another PG server then we have a solution.   But your reference to the little tool that enables trust seems to blow all security out of the water.  It is troublesome.


​There are many external tools that will encrypt files.  You can also setup a filesystem that has encryption features.​  You don't necessarily need the full cooperation of PostgreSQL to make things meet your definition/trade-off of secure.

IMHO, The "little tool that enables trust" really isn't a problem by itself (and its not really a tool...) but rather has a slight impact of the potential risk surface and learning curve.  It probably shouldn't be used in production but can come in handy in other setups.  You've already lost once some gets a hold of unencrytped data files - a problem that can be readily solved outside of PostgreSQL - that its a bit easier to spin up the database and access the database is just opening the barn door a bit further.

There are many others on these lists, and in the community, more knowledgeable in security than I.  It can be made considerably more secure than it comes "out of the box".

David J.

В списке pgsql-novice по дате отправления:

Предыдущее
От: Skylar Thompson
Дата:
Сообщение: Re: Permissions
Следующее
От: Andre Labuschagne
Дата:
Сообщение: Re: Permissions