trust 인증이 지정된 경우 PostgreSQL는 지정한 데이터베이스 사용자 이름을 사용하여 서버에 연결 가능한 모든 이가 데이터베이스 액세스에 대한 인증을 받는 것으로 간주한다(수퍼유저 이름 포함). 물론, database 및 user 컬럼의 제한도 계속 적용된다. 이 방법은 서버 연결에 대한 적절한 운영 체제 수준의 보호가 제공되는 경우에만 사용되어야 한다.

trust 인증은 단일 사용자 워크스테이션에 대한 로컬 연결 시 적절하며, 매우 편리하다. 다중 사용자 머신에서는 일반적으로 적절하지 않다. 그러나, 파일 시스템 권한을 사용하여 서버의 Unix 도메인 소켓 파일에 대한 액세스를 제한하는 경우 다중 사용자 머신에서도 trust를 사용 가능할 수 있다. 이렇게 하려면 unix_socket_permissions(및 가능하면 unix_socket_group) 환경 설정 매개 변수를 19.3절에서 설명한 대로 설정해야 한다. 또는 unix_socket_directories 환경 설정 매개 변수를 설정하여 소켓 파일을 적절히 제한된 디렉터리에 배치할 수 있다.

파일 시스템 권한 설정은 Unix 소켓 연결 시에만 유용하다. 로컬 TCP/IP 연결은 파일 시스템 권한에 의해 제한되지 않는다. 따라서 로컬 보안을 위해 파일 시스템 권한을 사용하려면 host ... 127.0.0.1 ... 줄을 pg_hba.conf에서 삭제하거나, 비 trust 방법으로 변경해야 한다.

trust 인증은 trust를 지정하는 pg_hba.conf 줄에 의해 서버로의 연결이 허용된 모든 머신의 모든 사용자를 신뢰하는 경우에 TCP/IP 연결에 대해서만 적합하다. localhost(127.0.0.1) 외에 TCP/IP 연결에 대해 trust를 사용하는 것은 별로 합당하지 않다.

There are several password-based authentication methods. These methods operate similarly but differ in how the users' passwords are stored on the server and how the password provided by a client is sent across the connection.

PostgreSQL 데이터베이스 패스워드는 운영 체제 사용자 패스워드와 구분된다. 각 데이터베이스 사용자에 대한 패스워드는 pg_authid 시스템 카탈로그에 저장된다. 패스워드는 SQL 명령 CREATE USER 및 ALTER ROLE으로 관리할 수 있으며, 예를 들면 CREATE USER foo WITH PASSWORD 'secret', 또는 psql 내장 명령어 \password 같은 작업으로 처리한다. 패스워드가 사용자에 대해 설정되지 않은 경우 저장된 패스워드는 null이고 패스워드 인증은 해당 사용자에 대해 항상 실패한다.

The availability of the different password-based authentication methods depends on how a user's password on the server is encrypted (or hashed, more accurately). This is controlled by the configuration parameter password_encryption at the time the password is set. If a password was encrypted using the scram-sha-256 setting, then it can be used for the authentication methods scram-sha-256 and password (but password transmission will be in plain text in the latter case). The authentication method specification md5 will automatically switch to using the scram-sha-256 method in this case, as explained above, so it will also work. If a password was encrypted using the md5 setting, then it can be used only for the md5 and password authentication method specifications (again, with the password transmitted in plain text in the latter case). (Previous PostgreSQL releases supported storing the password on the server in plain text. This is no longer possible.) To check the currently stored password hashes, see the system catalog pg_authid.

To upgrade an existing installation from md5 to scram-sha-256, after having ensured that all client libraries in use are new enough to support SCRAM, set password_encryption = 'scram-sha-256' in postgresql.conf, make all users set new passwords, and change the authentication method specifications in pg_hba.conf to scram-sha-256.

GSSAPI는 RFC 2743에 정의된 보안 인증을 위한 산업 표준 프로토콜이다. PostgreSQL은 RFC 1964에 따라 Kerberos를 사용한 GSSAPI를 지원한다. GSSAPI은 이것을 지원하는 시스템에 대해 자동 인증(single sign-on)을 제공한다. 인증 자체는 안전하지만, SSL을 사용하지 않을 경우 데이터베이스 연결을 통해 전송된 데이터는 암호화되지 않은 상태로 전송된다.

GSSAPI는 PostgreSQL이 빌드된 경우 활성화되어야 한다. 자세한 내용은 16장을 참조 바란다.

GSSAPI가 Kerberos를 사용하는 경우 servicename/hostname@realm 형식으로 표준 보안 주체(principal)가 사용된다. PostgreSQL 서버가 서버에서 사용되는 키탭에 포함된 보안 주체(principal)를 수용하지만, krbsrvname 연결 매개 변수를 사용하여 클라이언트에서 연결을 할 때 올바른 보안 주체(principal) 상세 정보를 지정할 때 특별히 주의해야 한다. (33.1.2절도 참조 바란다.) 설치 기본값은 빌드 시에 ./configure --with-krb-srvnam=whatever를 사용하여 기본값 postgres에서 변경 가능하다. 대부분의 환경에서 이 매개 변수는 절대 변경할 필요가 없다. 일부 Kerberos 구현은 서비스 이름이 대문자여야 하는 Microsoft Active Directory처럼 서로 다른 서비스 이름을 요구할 수도 있다(POSTGRES).

hostname은 서버 머신의 정규화된 호스트 이름이다. 서비스 보안 주체의 영역(principal's realm)은 서버 머신의 기본 설정된 영역(realm)이다.

Client principals can be mapped to different PostgreSQL database user names with pg_ident.conf. For example, pgusername@realm could be mapped to just pgusername. Alternatively, you can use the full username@realm principal as the role name in PostgreSQL without any mapping.

PostgreSQL also supports a parameter to strip the realm from the principal. This method is supported for backwards compatibility and is strongly discouraged as it is then impossible to distinguish different users with the same user name but coming from different realms. To enable this, set include_realm to 0. For simple single-realm installations, doing that combined with setting the krb_realm parameter (which checks that the principal's realm matches exactly what is in the krb_realm parameter) is still secure; but this is a less capable approach compared to specifying an explicit mapping in pg_ident.conf.

사용자는 서버 키탭 파일을 PostgreSQL 서버 계정으로 읽기 가능한지(읽기 가능만, 쓰기 불가) 확인해야 한다. (18.1절도 참조 바란다.) 키 파일의 위치는 krb_server_keyfile 환경 설정 매개 변수에 의해 지정된다. 기본값은 /usr/local/pgsql/etc/krb5.keytab(또는 빌드 시 sysconfdir로 지정된 아무 디렉터리). 보안상의 이유로, 시스템 키탭 파일에 대한 권한을 여는 것보다는 PostgreSQL 서버에 대해 별개의 키탭을 사용하는 것이 바람직하다.

키탭 파일은 Kerberos 소프트웨어에 의해 생성된다. 자세한 내용은 Kerberos 문서를 참조 바란다. 다음 예시는 MIT 호환 Kerberos 5 구현에 대한 것이다.

kadmin% ank -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org

데이터베이스에 연결할 때 요청된 데이터베이스 사용자 이름과 일치하는 보안 주체(principal)에 대한 티켓이 있는지 확인해야 한다. 예를 들면, 데이터베이스 이름 fred의 경우 보안 주체(principal) fred@EXAMPLE.COM은 연결이 가능하다. 보안 주체(principal) fred/users.example.com@EXAMPLE.COM의 연결도 허용하려면 20.2절에 설명된 대로 사용자 이름 맵을 사용해야 한다.

다음 환경 설정 옵션이 GSSAPI에 대해 지원된다.

SSPI는 단일 사인온(sign-on)의 보안 인증을 위한 Windows 기술이다. PostgreSQL은 negotiate모드에서 SSPI를 사용한다. 이것은 가능한 경우 Kerberos를 사용하고, 그 외에는 NTLM으로 자동 폴백(fall back)된다. SSPI 인증은 서버와 클라이언트가 모두 Windows를 사용하는 경우에만 작동되고, GSSAPI를 사용할 수 있는 경우에는 비 Windows에서 작동된다.

Kerberos 인증 사용 중에는 SSPI가 GSSAPI와 동일한 방식으로 작동된다. 자세한 내용은 20.3.3절을 참조 바란다.

다음 환경 설정 옵션이 SSPI에 대해 지원된다.

ident 인증 방법은 클라이언트의 운영 체제 사용자 이름을 ident 서버로부터 획득하고, 허용된 데이터베이스 사용자 이름으로 사용함으로써 작동된다(선택적 사용자 이름 매핑 사용). 이것은 TCP/IP 연결에서만 지원된다.

다음 구성 옵션이 ident에 대해 지원된다.

“신분확인 프로토콜(Identification Protocol)”은 RFC 1413에 설명되어 있다. 실제로 모든 Unix 류의 운영 체제에는 기본적으로 TCP 포트 113에서 listen하는 ident 서버가 내장되어 있다. ident 서버의 기본적인 기능은, “너의 포트 X에서 출력되어 내 포트 Y에 연결되는 연결을 초기화한 사용자는 누구인가?” 같은 질문에 응답하는 것이다. 실제 연결이 성립되면 PostgreSQL은 X와 Y를 모두 알고 있으므로 연결 클라이언트의 호스트에 대한 정보를 ident 서버에서 얻을 수 있으며, 주어진 연결에서 운영 체제 사용자를 이론적으로 판단할 수 있다.

이 방법의 단점은 클라이언트의 무결성에 따라 달라진다. 클라이언트 머신을 신뢰할 수 없거나 손상된 경우 공격자(attacker)는 포트 113에서 프로그램을 실행하고, 선택한 사용자 이름으로 리턴할 수 있다. 따라서 인증 방법은 각 클라이언트 머신이 엄격하게 제어되고, 데이터베이스 및 시스템 관리자의 협력이 긴밀하게 이뤄지는 폐쇄된 네트워크의 경우에만 적합하다. 즉, 사용자는 ident 서버가 실행되는 머신을 신뢰해야 한다. 다음 경고에 유의해야 한다.

일부 ident 서버는 원래 머신의 관리자만 알고 있는 키를 사용하여, 리턴된 사용자 이름을 암호화되도록 하는 비표준 옵션이 있다. PostgreSQL는 실제 사용자 이름을 결정하기 위해 리턴된 string의 암호를 해제할 방법이 없으므로 ident 서버에서 PostgreSQL을 사용하는 경우에는 이 옵션을 사용해서는 안 된다.

피어(peer) 인증 방법은 클라이언트의 운영 체제 사용자 이름을 커널로부터 획득하고, 허용된 데이터베이스 사용자 이름으로 사용함으로써 작동된다(선택적 사용자 이름 매핑 사용). 이 방법은 로컬 연결에만 지원된다.

다음 구성 옵션이 피어(peer)에 대해 지원된다.

피어(Peer) 인증은 getpeereid() 함수, SO_PEERCRED 소켓 매개 변수 또는 유사 메커니즘이 제공되는 운영 체제에서만 사용할 수 있다. 현재 Linux가 포함되며, macOS 및 Solaris를 비롯한 BSD가 가장 선호된다.

이 인증 방법은 패스워드 검증 방법으로 LDAP를 사용할 때 외에는 password와 유사하게 작동된다. LDAP는 사용자 이름/패스워드 쌍을 검증할 때에만 사용된다. 따라서 LDAP를 인증에 사용하기 전에 사용자가 데이터베이스에 존재해야 한다.

LDAP 인증은 2가지 모드로 수행할 수 있다. 간단한 바인딩 모드라고 하는 첫 번째 방법은 서버가 prefix username suffix로 구성된 고유한 이름에 바인딩하는 것이다. 일반적으로 prefix 매개 변수는 Active Directory 환경에서 cn= 또는 DOMAIN\을 지정하는 데 사용된다. suffix는 비 Active Directory 환경의 나머지 부분을 지정할 때 사용된다.

검색+바인딩 모드라고 하는 두 번째 모드에서 서버는 ldapbinddn 및 ldapbindpasswd로 지정 및 고정된 사용자 이름과 패스워드를 사용하여 LDAP 디렉터리에 먼저 바인딩한 다음, 데이터베이스에 로그인하려는 사용자를 검색한다. 사용자 및 패스워드가 구성되지 않은 경우 익명 바인딩이 디렉터리에 시도된다. ldapbasedn의 서브 트리에서 검색이 수행되고 ldapsearchattribute에서 지정된 속성과 정확히 일치하는 것을 찾는다. 이 검색에서 사용자를 찾았으며, 서버는 연결을 끊고, 로그인이 올바른지 검증하기 위해 클라이언트에서 지정된 패스워드를 사용하여 이 사용자로 디렉터리에 다시 바인딩한다. 이 모드는 Apache mod_authnz_ldap 및 pam_ldap 같은 다른 소프트웨어의 LDAP 인증 스키마에서 사용되는 것과 동일하다. 이 방법은 사용자 개체가 디렉터리에 있는 곳에서 더 많은 유연성을 허용하지만 LDAP 서버에 대한 2개의 연결이 초래된다.

다음 구성 옵션이 양쪽 모드에 사용된다:

다음 옵션은 간단 바인딩 모드에만 사용된다.

다음 옵션은 검색+바인딩 모드에만 사용된다.

간단한 바인딩의 구성 옵션과 검색+바인딩의 옵션을 혼용하는 것은 에러이다.

간단한 바인딩 LDAP 구성의 예시는 다음과 같다.

host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"

데이터베이스 사용자 someuser로 데이터베이스 서버에 연결이 요청된 경우 PostgreSQL은 DN cn=someuser, dc=example, dc=net 및 클라이언트에서 제공된 패스워드를 사용하여 LDAP 서버에 바인딩을 시도한다. 해당 연결이 성공하면 데이터베이스 액세스가 허용된다.

검색+바인딩 구성의 예시는 다음과 같다.

host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid

데이터베이스 사용자 someuser로 데이터베이스 서버에 연결이 요청된 경우 PostgreSQL은 익명으로(ldapbinddn가 지정되지 않았으므로) LDAP 서버에 바인딩을 시도하고 지정된 베이스 DN 아래에서 (uid=someuser)에 대한 검색을 수행한다. 항목이 발견되면 발견된 정보와 클라이언트가 제공한 패스워드를 사용하여 바인딩을 시도한다. 해당 제2차 연결이 성공하면 데이터베이스 액세스가 허용된다.

URL로 작성한 동일한 검색+바인딩 구성은 다음과 같다.

host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"

LDAP에 대한 인증을 지원하는 일부 다른 소프트웨어는 동일한 URL 형식을 사용하므로 구성을 공유하기 쉬워진다.

이 인증 방법은 패스워드 검증 방법으로 RADIUS를 사용할 때 외에는 password와 유사하게 작동된다. RADIUS는 사용자 이름/패스워드 쌍을 검증할 때에만 사용된다. 따라서 RADIUS를 인증에 사용하기 전에 사용자가 데이터베이스에 존재해야 한다. authentication.

RADIUS 인증을 사용 중인 경우 구성된 RADIUS 서버로 액세스 요청(Access Request) 메시지가 전송된다. 이 요청은 Authenticate Only 유형이며, user name, password(암호화됨) 및 NAS Identifier에 대한 매개 변수가 포함된다. 요청은 서버와 공유되는 비밀을 사용하여 암호화된다. RADIUS 서버는 Access Accept 또는 Access Reject를 사용하여 이 서버에 응답한다. RADIUS 계정에 대한 지원은 없다.

Multiple RADIUS servers can be specified, in which case they will be tried sequentially. If a negative response is received from a server, the authentication will fail. If no response is received, the next server in the list will be tried. To specify multiple servers, put the names within quotes and separate the server names with a comma. If multiple servers are specified, all other RADIUS options can also be given as a comma separate list, to apply individual values to each server. They can also be specified as a single value, in which case this value will apply to all servers.

다음 구성 옵션이 RADIUS에 대해 지원된다.

이 인증 방법은 SSL 클라이언트 인증서를 사용하여 인증을 수행한다. 따라서 SSL 연결에서만 사용 가능하다. 이 인증 방법을 사용하는 경우 서버는 클라이언트가 유효한 (신뢰할 수 있는) 인증서를 제공할 것을 요구한다. 패스워드 없음 프롬프트는 클라이언트로 전송된다. 인증서의 cn(공통 이름) 속성은 요청된 데이터베이스 사용자 이름과 비교되며, 일치하는 경우 로그인이 허용된다. 사용자 이름 매핑을 사용하여 cn을 데이터베이스 사용자 이름과 다르게 할 수 있다.

다음 구성 옵션이 SSL 인증서 인증에 대해 지원된다.

In a pg_hba.conf record specifying certificate authentication, the authentication option clientcert is assumed to be 1, and it cannot be turned off since a client certificate is necessary for this method. What the cert method adds to the basic clientcert certificate validity test is a check that the cn attribute matches the database user name.

이 인증 방법은 인증 메커니즘으로 PAM(Pluggable Authentication Modules)을 사용하며, 나머지는 password 인증 방식과 비슷하다. 기본 PAM 서비스 이름은 postgresql이다. PAM 인증은 사용자 이름/비밀번호 조합의 유효성만 검사하거나, 선택적으로 접속하는 원격 호스트 이름 또는 IP 주소의 유효성을 검사하는데만 사용 된다. 그래서, PAM 인증에 사용될 사용자 이름은 해당 데이터베이스 사용자로 먼저 만들어져있어야 한다. PAM에 대한 자세한 정보는 Linux-PAM 페이지를 참고 바란다.

다음 구성 옵션이 PAM에 대해 지원된다.

This authentication method operates similarly to password except that it uses BSD Authentication to verify the password. BSD Authentication is used only to validate user name/password pairs. Therefore the user's role must already exist in the database before BSD Authentication can be used for authentication. BSD 인증 프레임워크는 현재 OpenBSD에서만 사용할 수 있다.

BSD Authentication in PostgreSQL uses the auth-postgresql login type and authenticates with the postgresql login class if that's defined in login.conf. By default that login class does not exist, and PostgreSQL will use the default login class.