| PostgreSQL 9.6.2 문서 | |||
|---|---|---|---|
| 이전 | 위로 | 장 20. 클라이언트 인증 | 다음 |
아래 절에서는 인증 방법을 자세하게 다룬다.
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를 사용하는 것은 별로 합당하지 않다.
패스워드 기반 인증 방법은 md5 및 password이다. 패스워드가 연결 간에, 즉 MD5 해시 및 일반 텍스트로 각각 전송되는 방법을 제외하고는 이 방법은 유사하게 작동된다.
어쨌든 패스워드 "스니핑" 공격에 관심이 있는 경우에는 md5가 바람직하다. 항상 일반 password는 가능하면 피해야 한다. 단, md5는 db_user_namespacedb_user_namespace 기능과 함께 사용할 수 없다. 연결이 SSL 암호화로 보호되는 경우 password를 안전하게 사용할 수 있다(SSL을 사용하는 경우 SSL 인증서 인증이 더 나을 수 있지만).
PostgreSQL 데이터베이스 패스워드는 운영 체제 사용자 패스워드와 구분된다. 각 데이터베이스 사용자에 대한 패스워드는 pg_authid 시스템 카탈로그에 저장된다. 패스워드는 SQL 명령 CREATE USER 및 ALTER ROLE으로 관리할 수 있으며, 예를 들면 CREATE USER foo WITH PASSWORD 'secret'와 같다. 패스워드가 사용자에 대해 설정되지 않은 경우 저장된 패스워드는 null이고 패스워드 인증은 해당 사용자에 대해 항상 실패한다.
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) 상세 정보를 지정할 때 특별히 주의해야 한다. (32.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에 대해 지원된다.
If set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping (20.2절). This is discouraged and is primarily available for backwards compatibility, as it is not secure in multi-realm environments unless krb_realm is also used. It is recommended to leave include_realm set to the default (1) and to provide an explicit mapping in pg_ident.conf to convert principal names to PostgreSQL user names.
시스템과 데이터베이스 사용자 이름 사이의 매핑을 허용한다. 자세한 내용은 20.2절을 참조 바란다. For a GSSAPI/Kerberos principal, such as username@EXAMPLE.COM (or, less commonly, username/hostbased@EXAMPLE.COM), the user name used for mapping is username@EXAMPLE.COM (or username/hostbased@EXAMPLE.COM, respectively), unless include_realm has been set to 0, in which case username (or username/hostbased) is what is seen as the system user name when mapping.
사용자 보안 주체(principal) 이름과 일치하는 영역(realm)을 설정한다. 이 매개 변수가 설정된 경우 해당 영역(realm)의 사용자만 허용된다. 설정되지 않으면 모든 영역(realm)의 사용자가 연결할 수 있으며, 사용자 이름 매핑 완료 여부에 달려 있다.
SSPI는 단일 사인온(sign-on)의 보안 인증을 위한 Windows 기술이다. PostgreSQL은 negotiate모드에서 SSPI를 사용한다. 이것은 가능한 경우 Kerberos를 사용하고, 그 외에는 NTLM으로 자동 폴백(fall back)된다. SSPI 인증은 서버와 클라이언트가 모두 Windows를 사용하는 경우에만 작동되고, GSSAPI를 사용할 수 있는 경우에는 비 Windows에서 작동된다.
Kerberos 인증 사용 중에는 SSPI가 GSSAPI와 동일한 방식으로 작동된다. 자세한 내용은 20.3.3절을 참조 바란다.
다음 환경 설정 옵션이 SSPI에 대해 지원된다.
If set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping (20.2절). This is discouraged and is primarily available for backwards compatibility, as it is not secure in multi-realm environments unless krb_realm is also used. It is recommended to leave include_realm set to the default (1) and to provide an explicit mapping in pg_ident.conf to convert principal names to PostgreSQL user names.
If set to 1, the domain's SAM-compatible name (also known as the NetBIOS name) is used for the include_realm option. This is the default. If set to 0, the true realm name from the Kerberos user principal name is used.
Do not disable this option unless your server runs under a domain account (this includes virtual service accounts on a domain member system) and all clients authenticating through SSPI are also using domain accounts, or authentication will fail.
If this option is enabled along with compat_realm, the user name from the Kerberos UPN is used for authentication. If it is disabled (the default), the SAM-compatible user name is used. By default, these two names are identical for new user accounts.
Note that libpq uses the SAM-compatible name if no explicit user name is specified. If you use libpq or a driver based on it, you should leave this option disabled or explicitly specify user name in the connection string.
시스템과 데이터베이스 사용자 이름 사이의 매핑을 허용한다. 자세한 내용은 20.2절을 참조 바란다. For a SSPI/Kerberos principal, such as username@EXAMPLE.COM (or, less commonly, username/hostbased@EXAMPLE.COM), the user name used for mapping is username@EXAMPLE.COM (or username/hostbased@EXAMPLE.COM, respectively), unless include_realm has been set to 0, in which case username (or username/hostbased) is what is seen as the system user name when mapping.
사용자 보안 주체(principal) 이름과 일치하는 영역(realm)을 설정한다. 이 매개 변수가 설정된 경우 해당 영역(realm)의 사용자만 허용된다. 설정되지 않으면 모든 영역(realm)의 사용자가 연결할 수 있으며, 영역은 사용자 이름 매핑 완료 여부에 달려 있다.
ident 인증 방법은 클라이언트의 운영 체제 사용자 이름을 ident 서버로부터 획득하고, 허용된 데이터베이스 사용자 이름으로 사용함으로써 작동된다(선택적 사용자 이름 매핑 사용). 이것은 TCP/IP 연결에서만 지원된다.
참고: 로컬(비 TCP/IP) 연결에 대해 ident를 지정하는 경우 피어(peer) 인증이 대신 사용된다(20.3.6절 참조).
다음 구성 옵션이 ident에 대해 지원된다.
시스템과 데이터베이스 사용자 이름 사이의 매핑을 허용한다. 자세한 내용은 20.2절을 참조 바란다.
"신분확인 프로토콜(Identification Protocol)"은 RFC 1413에 설명되어 있다. 실제로 모든 Unix 류의 운영 체제에는 기본적으로 TCP 포트 113에서 listen하는 ident 서버가 내장되어 있다. ident 서버의 기본적인 기능은, "너의 포트 X에서 출력되어 내 포트 Y에 연결되는 연결을 초기화한 사용자는 누구인가?" 같은 질문에 응답하는 것이다. 실제 연결이 성립되면 PostgreSQL은 X와 Y를 모두 알고 있으므로 연결 클라이언트의 호스트에 대한 정보를 ident 서버에서 얻을 수 있으며, 주어진 연결에서 운영 체제 사용자를 이론적으로 판단할 수 있다.
이 방법의 단점은 클라이언트의 무결성에 따라 달라진다. 클라이언트 머신을 신뢰할 수 없거나 손상된 경우 공격자(attacker)는 포트 113에서 프로그램을 실행하고, 선택한 사용자 이름으로 리턴할 수 있다. 따라서 인증 방법은 각 클라이언트 머신이 엄격하게 제어되고, 데이터베이스 및 시스템 관리자의 협력이 긴밀하게 이뤄지는 폐쇄된 네트워크의 경우에만 적합하다. 즉, 사용자는 ident 서버가 실행되는 머신을 신뢰해야 한다. 다음 경고에 유의해야 한다.
신분확인 프로토콜은 인증 또는 액세스 제어 프로토콜로 사용할 수 없다(The Identification Protocol is not intended as an authorization or access control protocol). | ||
| --RFC 1413 | ||
일부 ident 서버는 원래 머신의 관리자만 알고 있는 키를 사용하여, 리턴된 사용자 이름을 암호화되도록 하는 비표준 옵션이 있다. PostgreSQL는 실제 사용자 이름을 결정하기 위해 리턴된 string의 암호를 해제할 방법이 없으므로 ident 서버에서 PostgreSQL을 사용하는 경우에는 이 옵션을 사용해서는 안 된다.
피어(peer) 인증 방법은 클라이언트의 운영 체제 사용자 이름을 커널로부터 획득하고, 허용된 데이터베이스 사용자 이름으로 사용함으로써 작동된다(선택적 사용자 이름 매핑 사용). 이 방법은 로컬 연결에만 지원된다.
다음 구성 옵션이 피어(peer)에 대해 지원된다.
시스템과 데이터베이스 사용자 이름 사이의 매핑을 허용한다. 자세한 내용은 20.2절을 참조 바란다.
피어(Peer) 인증은 getpeereid() 함수, SO_PEERCRED 소켓 매개 변수 또는 유사 메커니즘이 제공되는 운영 체제에서만 사용할 수 있다. 현재 Linux가 포함되며,
OS X 및 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 서버의 이름 또는 IP 주소. 공백으로 구분된 서버를 여러 개 지정할 수 있다.
연결할 LDAP 서버의 포트 번호. 포트가 지정되지 않으면 LDAP 라이브러리의 기본 포트 설정이 사용된다.
1로 설정하면 TLS 암호화를 사용하여 PostgreSQL과 LDAP 서버가 연결된다. 이것은 LDAP 서버로의 트래픽만 암호화된다. 클라이언트에 대한 연결은 SSL을 사용하지 않는 한 암호화되지 않은 상태가 지속된다.
다음 옵션은 간단 바인딩 모드에만 사용된다.
간단 바인딩 인증 수행 시 DN 바인딩의 사용자 이름 앞에 추가하는 string.
간단 바인딩 인증 수행 시 DN 바인딩의 사용자 이름 뒤에 추가하는 string.
다음 옵션은 검색+바인딩 모드에만 사용된다.
검색+바인딩 인증 수행 시 사용자 검색을 시작하는 루트 DN.
검색+바인딩 인증 수행 시 검색 수행하기 위해 디렉토리에 바인딩하는 사용자 DN.
검색+바인딩 인증 수행 시 검색 수행하기 위해 디렉토리에 바인딩하는 사용자의 패스워드.
검색+바인딩 인증 수행 시 검색에서 사용자 이름에 대해 일치하는 속성. 속성이 지정되지 않으면 uid 속성이 사용된다.
RFC 4516 LDAP URL. 이것은 다른 LDAP 옵션 중 일부를 좀 더 간결한 표준 형식으로 작성하는 다른 방법이다. 기본값은 다음과 같다.
ldap://host[:port]/basedn[?[attribute][?[scope]]]
scope는 base, one, sub 중 하나여야 하며, 일반적으로 후자이다. 한 가지 속성만 사용되며, 필터 및 확장 같은 표준 LDAP URL의 다른 일부 구성은 지원되지 않는다.
비 익명 바인딩의 경우 ldapbinddn 및 ldapbindpasswd는 별도의 옵션으로 지정되어야 한다.
암호화된 LDAP 연결을 사용하려면 ldapurl 외에도 ldaptls 옵션을 사용해야 한다. ldaps URL 스키마(다이렉트 SSL 연결)는 지원되지 않는다.
LDAP URL은 현재 Windows가 아니라 with OpenLDAP에서만 지원된다.
간단한 바인딩의 구성 옵션과 검색+바인딩의 옵션을 혼용하는 것은 에러이다.
간단한 바인딩 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 형식을 사용하므로 구성을 공유하기 쉬워진다.
작은 정보: LDAP는 주로 쉼표와 공백을 사용하여 DN의 서로 다른 부분을 구분하므로 예시에 표시된 대로 LDAP 옵션을 구성할 때 매개 변수를 큰따옴표로 둘러싸야 하는 경우가 있다.
이 인증 방법은 패스워드 검증 방법으로 RADIUS를 사용할 때 외에는 password와 유사하게 작동된다. RADIUS는 사용자 이름/패스워드 쌍을 검증할 때에만 사용된다. 따라서 RADIUS를 인증에 사용하기 전에 사용자가 데이터베이스에 존재해야 한다. authentication.
RADIUS 인증을 사용 중인 경우 구성된 RADIUS 서버로 액세스 요청(Access Request) 메시지가 전송된다. 이 요청은 Authenticate Only 유형이며, user name, password(암호화됨) 및 NAS Identifier에 대한 매개 변수가 포함된다. 요청은 서버와 공유되는 비밀을 사용하여 암호화된다. RADIUS 서버는 Access Accept 또는 Access Reject를 사용하여 이 서버에 응답한다. RADIUS 계정에 대한 지원은 없다.
다음 구성 옵션이 RADIUS에 대해 지원된다.
연결할 RADIUS 서버의 이름 또는 IP 주소. 이 매개 변수는 필수이다.
보안을 유지하면서 RADIUS 서버와 통신할 때 사용되는 공유 비밀. 이것은 PostgreSQL 및 RADIUS 서버에서 값이 정확하게 동일해야 한다. 최소 16자의 string이 권장된다. 이 매개 변수는 필수이다.
참고: 사용되는 암호화 벡터는 PostgreSQL가 OpenSSL을 지원하도록 빌드된 경우 강력한 방식으로 암호화되어야 한다. 그 외의 경우에, RADIUS 서버로의 전송은 보안이 되지 않은 obfuscated로 간주해야 하며, 필요 시 외부 보안 대책을 적용해야 한다.
연결할 RADIUS 서버의 포트 번호. 포트가 지정되지 않으면 기본 포트 1812가 사용된다.
RADIUS 요청에서 NAS Identifier로 사용되는 string. 이 매개 변수는 예를 들면, 사용자가 인증하려는 데이터베이스 사용자를 식별하여 RADIUS 서버에서 정책 일치용으로 이용되는 제2의 매개 변수로 사용될 수 있다. 식별자가 지정되지 않으면 기본 postgresql이 사용된다.
이 인증 방법은 SSL 클라이언트 인증서를 사용하여 인증을 수행한다. 따라서 SSL 연결에서만 사용 가능하다. 이 인증 방법을 사용하는 경우 서버는 클라이언트가 유효한 (신뢰할 수 있는) 인증서를 제공할 것을 요구한다. 패스워드 없음 프롬프트는 클라이언트로 전송된다. 인증서의 cn(공통 이름) 속성은 요청된 데이터베이스 사용자 이름과 비교되며, 일치하는 경우 로그인이 허용된다. 사용자 이름 매핑을 사용하여 cn을 데이터베이스 사용자 이름과 다르게 할 수 있다.
다음 구성 옵션이 SSL 인증서 인증에 대해 지원된다.
시스템과 데이터베이스 사용자 이름 사이의 매핑을 허용한다. 자세한 내용은 20.2절을 참조 바란다.
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에 대해 지원된다.
PAM 서비스 이름.
Determines whether the remote IP address or the host name is provided to PAM modules through the PAM_RHOST item. By default, the IP address is used. Set this option to 1 to use the resolved host name instead. Host name resolution can lead to login delays. (Most PAM configurations don't use this information, so it is only necessary to consider this setting if a PAM configuration was specifically created to make use of it.)
참고: PAM이 /etc/shadow를 읽도록 설정된 경우 PostgreSQL 서버는 root가 아닌 다른 사용자로 시작되므로 인증이 실패한다. 단, PAM이 LDAP 또는 다른 인증 방법을 사용하도록 구성된 경우 이것이 실행되지 않는다.
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.
참고: To use BSD Authentication, the PostgreSQL user account (that is, the operating system user running the server) must first be added to the auth group. The auth group exists by default on OpenBSD systems.