| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 20. 클라이언트 인증 | Fast Forward | Next |
이하의 소절에서는, 인증 방식에 대해 상세하게 설명합니다.
trust 인증이 지정될 때, PostgreSQL는 서버에 접속할 수 있는 모든 사람은 그들이 지정한 데이터베이스 사용자명을 이용해 서버로의 접속을 인증하는 것을 가정합니다(슈퍼유저도 포함). 물론 database와user열의 제한은 여전히 적용됩니다. 이 방식은 서버로의 접속에 대해서 충분한 operating system 레벨의 예방이 있을 경우에만 사용되어야 합니다.
trust인증은 한명의 유저 워크크스테이션상에서 로컬 접속을 실시하는 경우에 적절하며 동시에 매우 편리합니다. 복수의 유저가 존재하는 머신상에서는 일반적으로 적절하지 않습니다 . 그러나, 파일 시스템의 허가 속성을 사용해 서버의 Unix 도메인 소켓 파일의 접근을 제한하면 trust인증을 복수 유저 머신상에서 사용하는 일도 가능합니다. 이러한 방법은 Section 17.3에 기재되어 있듯이, unix_socket_permissions( 그리고 unix_socket_group가능합니다) 파라미터를 설정합니다. 또는 unix_socket_directory설정 파라미터를 적당히 제한된 디렉토리 안에 소켓 파일에 위치시도록 설정합니다.
Unix 소켓 접속을 실시하는 단 한가지 방법은 파일 시스템 허가를 설정하는 것입니다. 로컬 TCP/IP 접속은 파일 시스템에 의해 제한되지는 않습니다. 그러므로 로컬로 파일 시스템의 허가를 사용하려면pg_hba.conf로부터 host ... 127.0. 0.1 ...의 행을 삭제하거나, trust인증과 다른 방법으로 변경할 필요가 있습니다.
trust를 지정하는 pg_hba.conf 행에 의해 서버로의 접속을 허가하는 모든 머신상의 유저를 신뢰할 경우, TCP/IP 접속에 적합한 것은 오직 trust 인증입니다. TCP/IP 접속에서 localhost (127.0.0.1)가 아닌 trust를 사용하는 합리적인 이유는 거의 없습니다.
패스워드를 베이스로 한 인증 방식에는 md5,crypt 및 password가 있습니다. 이러한 방식은 패스워드가 접속에서 전송되는 방식(각각 MD5-hashed, crypt-encrypted, clear-text)을 제외하고 비슷하게 수행되어 집니다. crypt에 의한 방법은 pg_authid로 암호화된 패스워드와 함께 사용할 수 없습니다
만약 패스워드 "도청(sniffing)"공격에 대해 우려가 크다면, md5를 사용하는 하도록 권합니다. pre-7.2 클라이언트를 지원해야할 경우에만 crypt를 사용합니다. 단순한 password는(SSL나 접속 전후를 포함한 다른 통신 보안 wrapper를 사용하지 않는 한) 특히 개방적인 인터넷 환경의 접속을 피해야 합니다.
PostgreSQL데이터베이스 패스워드는 operating system의 유저 패스워드와 다른 것입니다. 각 데이터베이스 유저의 패스워드는pg_authid시스템 카탈로그 테이블 안에 저장됩니다. CREATE USER foo WITH PASSWORD 'secret';와 같이, 패스워드는 SQL 커멘드 CREATE USER 와 ALTER USER 를 사용해 관리할 수 있습니다. 디폴트에서는 패스워드가 설정되지 않는 경우, 저장되는 패스워드는 NULL가 되어, 그 유저의 패스워드 인증은 항상 실패합니다.
Kerberos는 업계표준의 안전한 인증 시스템으로, 공개 네트워크의 분산 컴퓨팅에 적합합니다 Kerberos시스템의 설명은 이 문서의 범위와 거리가 멉니다. 대체로 매우(강력합니다만) 복잡하다고 말할 수 있습니다. KerberosFAQ 나 MIT Kerberos 페이지는 검색을 시작하는 데 좋은 사이트입니다. Kerberos의 소스 코드 배포물은 일부 존재합니다. Kerberos는 안전한 인증을 제공하지만, 네트워크 넘어로 건네받는 쿼리나 데이터의 암호화를 실시하지 않습니다. 이 때문에는SSL를 사용해 주세요.
PostgreSQL는 Kerberos의 버젼 5를 지원하고 있습니다. Kerberos 인증의 서포트는 PostgreSQL가 구축 된 시점에서 가능합니다. 자세한 것은Chapter 14을 참조해 주세요.
PostgreSQL는 일반적인 Kerberos 서비스와 같이 작동합니다. 서비스의 법칙명은 servicename/hostname@realm 입니다.
servicename 는 krb_srvname설정 파라미터를 사용한 서버 측에 설정될 수 있습니다. 게다가 클라이언트 측에서는 krbsrvname접속 파라미터를 사용합니다. (Section 29.1도 참조해 주세요. ) 인스톨 시의 디폴트postgres(구축 시에는 ./configure --with-krb-srvnam=whatever를 사용함)는 변경 가능합니다. 많은 환경에서 이 파라미터는 변경할 필요는 없을 것입니다. 그렇지만, 동일 호스트내에서 복수의 PostgreSQL를 서포트하는 경우에는 필요합니다. 몇 개의 Kerberos의 실행에서는 다른 서비스명이 필요하게 됩니다. Microsoft 액티브 디렉토리에서는 서비스명은 대문자로 할 필요가 있습니다.(POSTGRES)
hostname 는 서버머신의 완전한 조건부 호스트명입니다. 서비스 법칙의 realm는 서버 머신의 realm를 선호합니다.
클라이언트 법칙은 그들의 PostgreSQL 데이터베이스 유저명으로 첫번째 컴포넌트를 가져야만 합니다. 예를 들면, pgusername/otherstuff@realm 입니다. 디폴트에서는 클라이언트의 realm을 PostgreSQL로 체크되지 않습니다. cross-realm 인증이 사용 가능하다면, 어느 realm의 법칙이라도 당신의 허가 없이 통신할 수 있습니다.
서버 keytab 파일이PostgreSQL서버 어카운트에 의해 읽어질 수 있는지를(그리고 될 수 있으면 read 전용) 확인해 주세요 (Section 16.1를 참조해 주세요). 키 파일의 장소는 krb_server_keyfile설정 파라미터로 지정됩니다 디폴트는 /usr/local/pgsql/etc/krb5.keytab(또는 구축시에 sysconfdir로 지정된 디렉토리)입니다.
keytab 파일은 Kerberos의 소프트웨어에 의해 작성됩니다. 자세한 것은 Kerberos의 문서를 참조해 주세요. MIT 호환의 Kerberos5 실행의 예는 다음과 같습니다.
kadmin% ank -randkey postgres/server.my.domain.org kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
데이터베이스에 접속하려고 할 때, 요청된 데이터베이스 유저명과 일치하는 법칙의 티켓을 소유하고 있는지를 확인해 주세요. 예를 들면, 데이터베이스 유저명fred에 대해, fred@EXAMPLE.COM와 fred/users.example.com@EXAMPLE.COM 법칙 모두는 데이터베이스 서버의 인증에 사용됩니다.
Apache Web 서버상에서 mod_auth_krb 와mod_perl를 사용한다면mod_perl스크립트로AuthType KerberosV5SaveCredentials가 사용 가능합니다. 이 방법으로 인해 여분의 패스워드가 요구되지 않으며, Web를 통한 안전한 데이터베이스 액세스가 생깁니다.
ident 인증 방식은 클라이언트 operating system의 유저명을 획득함으로서 실행됩니다. 그런 후 상응하는 이름으로 허가된 리스트를 가진 맵 파일을 사용해서 데이터베이스 유저명을 결정합니다. 클라이언트의 유저명 결정은 보안의 중요한 부분이며, 이는 접속 형식에 따라 다르게 작동합니다.
"신원 확인(Identification) 프로토콜"는 RFC 1413에서 설명되고 있습니다. 사실상 모든 Unix계의 operating system 배포는 디폴트로 TCP 포토 113을 감시하는 ident 서버가 속해 있습니다. ident 서버의 기본적인 기능은 "어느 유저가 포트 X 로부터의 접속을 시작해, 자신의 포트 Y 에 접속을 초기화했는가"에 대한 답입니다. PostgreSQL는 X 와 Y 를 인식하고 있습니다. 이에 따라 물리적 접속이 확립되었을 때, 접속한 클라이언트의 호스트 상의 ident 서버에게 신호를 보낼 수 있게 됩니다. 그리고 이론적으로 이러한 벙법으로 지정된 모든 접속에서는 operating system 유저를 결정할 수 있습니다.
이 절차의 결점은 클라이언트의 무결성에 의존한다는 것입니다. 만약 클라이언트 머신이 신용되어지지 않거나 위험하게 노출되고 있는 경우, 공격자는 포트 113 상의 어떤 프로그램이라도 실행할 수 있으며 공격자가 선택한 유저명을 반환할 수 있습니다. 따라서 이 인증 방식은 각 클라이언트 머신이 엄격한 관리 하에 있으며 데이터베이스와 시스템 관리자가 밀접한 연락으로 동작하는, 닫혀있는 네트워크에서만 적합하다고 할 수 있습니다. 다시 말하면, ident 서버에서 실행하는 머신은 무조건 신용해야합니다. 다음의 경고에 주의해 주세요.
|
신원 확인 프로토콜은 인증이나 액세스 관리 프로토콜로서 의도되지 않습니다. |
||
| --RFC 1413 | ||
일부 ident 서버는 유저명을 머신의 관리자만이 알고 있는 키를 사용해, 암호화하여 리턴하는 비표준 옵션을 가지고 있습니다. 이 옵션은 신원 확인 서버와 PostgreSQL를 함께 사용하는 경우에는 사용해서는 안됩니다 . 왜냐하면 PostgreSQL는 실제 유저명을 결정하기 위한 반환된 문자열을 해독하는 방법을 가지고 있지 않기 때문입니다.
Unix 도메인 소켓에 대해 SO_PEERCRED 요청을 서포트하고 있는 시스템(현시점에서는Linux,FreeBSD,NetBSD,OpenBSD과 BSD/OS) 상에서는, 로컬 접속에 대해서도 ident 인증을 적용할 수 있습니다. 이 경우, ident 인증 사용에 대한 위험은 없습니다. 실제, 이러한 시스템 상의 로컬 접속에서 추천되는 방법입니다.
SO_PEERCRED요청이 없는 시스템에서는 TCP/IP접속에 대해서만 ident 인증을 사용할 수 있습니다. 사용해 보려면 localhost주소127.0. 0.1을 지정하고 주소에 접속해 주세요. 이 방법은 로컬 ident 서버를 신뢰할 수 있는 범위까지 신뢰할 수 있습니다.
ident 기반 인증을 사용하는 경우, 접속을 시작한 operating system 유저명을 결정되면 PostgreSQL는 데이터베이스 시스템 유저로서 접속 요구를 하는 유저의 접속이 허가는지를 조사합니다. 이것은 pg_hba.conf파일 안의ident키워드 뒤에 있는 ident 맵 인자에 의해 제어됩니다. 이미 정의가 끝난 ident 맵sameuser이 있습니다. 이 맵은 같은 이름의 데이터베이스 유저(만약 존재한다면)로 접속하는 모든 operating system 유저를 허락합니다. 그 외의 맵은 수작업으로 작성되어 집니다.
sameuser가 아닌 ident 맵은 디폴트로 pg_ident.conf 라는 이름으로 ident 맵 파일에 정의됩니다. 그리고 클러스터의 데이터 디렉토리에 저장됩니다. (그러나, 다른 장소에 맵 파일을 설치할 수도 있습니다. ident_file설정 파라미터를 참조해 주세요). 보통 ident 맵 파일은 이하의 서식을 가집니다.
map-name ident-username database-username
코멘트와 공백은 pg_hba.conf와 같은 방법으로 다루어집니다. map-name 는 pg_hba.conf에서 매핑을 참조하기 위해서 사용되는 임의의 이름입니다. 다른 2개의 필드는 어느 operating system 유저가 어느 데이터베이스 유저로 접속하는 것이 허가되는지를 지정합니다. 같은 map-name 은 하나의 맵 안에서 다른 유저 매핑을 지정하기 위해서 반복해 사용할 수 있습니다. 얼마나 많은 데이터베이스 유저가 지정된 operating system 유저와 대응되는지와 관련된 제한은 없습니다. 반대의 경우도 마찬가지입니다.
pg_ident.conf파일은 설치할 때와 주서버 프로세스가SIGHUP 신호를 받았을 때에 읽힙니다. 실행 중인 시스템으로 파일을 편집했을 경우, (pg_ctl reload나 kill -HUP를 사용해) 서버에 파일을 다시 읽어보고 신호를 보내지 않으면 안됩니다.
Example 20-1에 있는 pg_hba.conf와 같이 사용가능한 pg_ident.conf파일은 Example 20-2으로 나타나고 있습니다. 이 설정의 예제는 bryanh,ann 또는robert라고 하는 Unix 유저명이외의 것으로 192.168 네트워크 머신에 로그인하게되면 액세스가 허가되지 않습니다. Unix 유저robert는 PostgreSQL유저bob로서 접속할 때만 허가됩니다. robert나 그 이외의 이름으로서가 아닙니다. ann는ann로서로 밖에 접속 허가되지 않습니다. 유저bryanh는 자신인 bryanh나 guest1로도 접속이 허가됩니다.
이 인증 방식은 password와 비슷하지만, 인증 방식으로 LDAP를 사용하는 점이 다릅니다. LDAP는 유저의 이름과 패스워드의 검증에만 사용됩니다. 그러므로 LDAP를 사용해 인증하기 전에, 유저는 데이터베이스에 존재해야만 합니다. 사용되는 서버와 파라미터는 pg_hba.conf파일 내의ldap키워드의 뒤에 지정되어 집니다. 이 파라미터의 서식은 이하에 나타냅니다.
ldap[
s
]://
servername
[:
port
]/
base dn
[;
prefix
[;
suffix
]]
콤마는 ldap 컴포넌트에 대한 복수의 아이템을 지정할 때에 사용됩니다. 그러나 인용부호가 붙지 않은 콤마는 pg_hba.conf에서 아이템의 separator로서 취급되기 때문에, 콤마가 존재하는 것을 보존하기 위해서 2겹인용부호로 ldap의 URL를 둘러싸는 것이 좋습니다. 이하는 예를 나타냅니다.
"ldap://ldap.example.net/dc=example,dc=net;EXAMPLE\"
ldap를 대신해ldaps를 지정하면, 접속에 대해 TLS 암호화가 유효하게 됩니다. 이 암호화가 PostgreSQL 서버와 LDAP 서버 간의 접속에서만 이뤄진다는 것을 주의해 주세요. 이러한 설정으로 클라이언트와 PostgreSQL 서버 간 통신에 영향을 미치지 않습니다. TLS 암호화를 사용하기 위해서는 PostgreSQL를 구축하기 전에 LDAP 라이브러리를 구축할 필요가 있을 지 모릅니다. 플랫폼의 LDAP 라이브러리가 지원하는 경우에만, 암호화된 LDAP를 사용할 수 있다는 점에 주의해 주세요.
포트의 지정이 없는 경우, LDAP 라이브러리에 디폴트로 포트가 설정됩니다.
서버는 클라이언트로부터 받은 유저명을 이용하여 base dn 로서 지정된 이름을 bind(속박)합니다. prefix 와 suffix 가 지정되었을 경우, 바인드 전에 유저명의 앞뒤로 부여됩니다. 일반적으로 prefix 파라미터는 cn= 나 Active Directory 환경의 DOMAIN\ 의 지정에 사용됩니다.
이 인증 방식은 인증 매커니즘으로서 PAM(Pluggable Authentication Modules)를 사용하는 것을 제외해고 password와 유사하게 작동됩니다. 디폴트의 PAM 서비스명은 postgresql입니다. pg_hba.conf파일의 pam키워드 이름을 붙여서 옵션으로 독자적인 서비스명을 지정할 수 있습니다. PAM는 확인된 유저명과 패스워드에서만 사용됩니다. 그러므로 사용자는 PAM이 인증을 위해 사용되어지기 전에 데이터베이스에 존재해야만 합니다. PAM에 대한 자세한 사항은 Linux-PAM페이지와 Solaris PAM 페이지를 읽어 주세요.