보안

클라이언트 인증과 데이터베이스 롤은 보안에서 중요한 요소입니다. AgensGraph는 PostgreSQL을 기반으로 개발되었으므로, RDB 측(GDB 측이 아닌)의 기능을 소개할 때는 PostgreSQL 기술 문서를 인용하였습니다.

클라이언트 인증

클라이언트 애플리케이션이 데이터베이스 서버에 연결할 때, 접근이 허용되는 데이터베이스 사용자의 수를 제한하는 것이 중요합니다. 인증은 데이터베이스 서버가 클라이언트 ID를 구성하고, 클라이언트 애플리케이션이 데이터베이스 사용자(또는 클라이언트 애플리케이션을 실행하는 사용자)의 이름으로 접근을 시도할 때 그 연결을 허용할지 여부를 결정하는 과정입니다.

AgensGraph는 여러 가지 서로 다른 클라이언트 인증 방식을 제공합니다. 특정 클라이언트 연결을 인증하는 데 사용되는 이러한 방식은 (클라이언트) 호스트 주소, 데이터베이스, 사용자 등을 기준으로 선택할 수 있습니다.

AgensGraph 데이터베이스의 사용자 이름은 서버가 실행 중인 운영 체제의 사용자 이름과 논리적으로 구분됩니다. 특정 서버의 모든 사용자는 서버 머신에 계정을 가질 수 있습니다. 그러나 운영 체제 사용자 이름과 일치하는 데이터베이스 사용자 이름을 할당하는 것이 합리적입니다. 문제는 원격 연결을 허용하는 서버에는 로컬 운영 체제 계정이 없는 많은 데이터베이스 사용자가 있을 수 있다는 점이며, 이러한 경우에는 데이터베이스 사용자 이름을 OS 사용자 이름과 연관시킬 필요가 없습니다.

pg_hba.conf 파일

클라이언트 인증은 전통적으로 설정 파일인 pg_hba.conf에 의해 제어되며, 이 파일은 데이터베이스 클러스터의 데이터 디렉터리에 저장됩니다.

pg_hba.conf의 형식은 레코드의 집합이며, 각 줄이 하나의 레코드입니다. 빈 줄은 무시되고, “#” 뒤에 오는 텍스트도 무시됩니다. 줄 바꿈 이후로 이어질 수 없는 레코드는 공백이나 탭 등의 구분자로 나뉜 여러 필드로 구성됩니다. 필드 값에 큰따옴표를 사용하면 필드 안에 공백을 포함할 수 있습니다. 데이터베이스나 사용자/주소 필드의 키워드에 따옴표를 사용하면 해당 단어는 특수한 의미를 잃게 됩니다.

각 레코드는 이러한 매개변수와 일치하는 연결에 사용할 연결 유형, 클라이언트 IP 주소의 범위(해당하는 경우), 데이터베이스 이름, 사용자 이름, 인증 방식을 지정합니다. 인증 과정에서는 연결 유형, 클라이언트 주소, 요청된 데이터베이스, 사용자 이름과 일치하는 첫 번째 레코드가 사용됩니다. “fall-through”나 “backup”은 없습니다. 어떤 레코드가 선택되었으나 인증에 실패한 경우, 다음 레코드는 인증되지 않습니다. 일치하는 레코드가 없으면 접근이 거부됩니다.

레코드는 다음 일곱 가지 유형 중 하나입니다:

local     databaseuserauth-method                   [auth-options]
host      databaseuseraddressauth-method            [auth-options]
hostssl   databaseuseraddressauth-method            [auth-options]
hostnossl databaseuseraddressauth-method            [auth-options]
host      databaseuserIP-addressIP-maskauth-method  [auth-options]
hostssl   databaseuserIP-addressIP-maskauth-method  [auth-options]
hostnossl databaseuserIP-addressIP-maskauth-method  [auth-options]

각 필드의 의미는 다음과 같습니다:

  • local
    이 레코드는 Unix 도메인 소켓을 통한 연결에 해당합니다. 이 유형의 레코드가 없으면 Unix 도메인 소켓 연결이 불가능합니다.

  • host
    이 레코드는 TCP/IP를 통한 연결에 해당합니다. host 레코드는 SSL(또는 비SSL) 연결 시도와 일치합니다.

  • hostssl
    이 레코드가 TCP/IP를 통한 연결 시도와 일치하더라도, SSL 암호화를 사용하는 연결에만 해당합니다. 이 옵션을 사용하려면 서버에 SSL 지원이 내장되어 있어야 합니다. 서버가 시작될 때 SSL을 활성화하려면 ssl 설정 매개변수를 지정하십시오.

  • hostnossl
    이 유형의 레코드는 hostssl과 반대로 동작하며, SSL을 사용하지 않는 TCP/IP 연결 시도와 일치합니다.

  • database
    이 레코드는 데이터베이스 이름을 지정합니다.

    • 모든 데이터베이스와 일치시키려면 all을 지정합니다.

    • 요청된 데이터베이스가 요청된 사용자와 동일한 이름을 가질 때 레코드와 일치시키려면 sameuser를 지정합니다.

    • 요청된 사용자가 요청된 데이터베이스와 동일한 “롤”의 멤버여야 하는지 여부를 나타내려면 samerole을 지정합니다. “superuser”는 단지 슈퍼유저라는 이유만으로는 (samerole에서) 롤의 멤버로 간주되지 않으며, 직접 또는 간접적으로 명시적인 롤의 멤버가 아닌 경우에는 멤버로 간주되지 않습니다.

    • 복제 연결이 요청된 경우 레코드와 일치시키려면 replication을 지정합니다(복제 연결은 특정 데이터베이스를 지정하지 않습니다). 그 외의 경우에는 특정 AgensGraph 데이터베이스의 이름입니다. 여러 데이터베이스 이름을 쉼표로 구분하여 작성할 수 있습니다. 데이터베이스 이름을 담은 파일은 파일 이름 앞에 @를 붙여 지정할 수 있습니다.

  • user
    이 레코드와 일치하는 데이터베이스 사용자 이름을 지정합니다. 값 all은 모든 사용자와 일치함을 지정합니다. 그렇지 않으면 특정 데이터베이스 사용자의 이름이거나, 앞에 +가 붙은 그룹 이름입니다. (PostgreSQL에서는 사용자와 그룹 사이에 실질적인 구분이 없다는 점을 기억하십시오. + 기호는 실제로 “이 롤의 직접 또는 간접적인 멤버인 롤 중 하나와 일치”를 의미하며, + 기호가 없는 이름은 해당 특정 롤에만 일치합니다.) 이를 위해 슈퍼유저는 단지 슈퍼유저라는 이유가 아니라 직접 또는 간접적으로 명시적인 롤의 멤버인 경우에만 그 롤의 멤버로 간주됩니다. 여러 사용자 이름은 쉼표로 구분하여 지정할 수 있습니다. 사용자 이름을 담은 별도의 파일은 파일 이름 앞에 @를 붙여 지정할 수 있습니다.

    이 레코드와 일치하는 데이터베이스 사용자 이름을 지정합니다. 모든 사용자와 일치시키려면 all을 지정합니다. 그 외의 경우에는 특정 데이터베이스 사용자의 이름이거나 앞에 +가 붙은 그룹 이름입니다. (AgensGraph에서는 사용자 이름과 그룹 이름 사이에 실질적인 차이가 없습니다. “” 기호는 실제로 “이 롤의 직접 또는 간접적인 멤버인 모든 롤과 일치”를 의미하며, “+” 기호가 없는 이름은 특정 롤과 일치합니다.) 이러한 이유로 슈퍼유저는 단지 슈퍼유저이기 때문이 아니라 직접 또는 간접적으로 명시적인 롤의 멤버일 때에만 롤 멤버로 간주됩니다. 여러 사용자 이름을 쉼표로 구분하여 사용할 수 있습니다. 사용자 이름을 담은 파일은 파일 이름 앞에 @를 붙여 지정할 수 있습니다.

  • address
    이 레코드와 일치하는 클라이언트 머신 주소를 지정합니다. 이 필드에는 호스트 이름, IP 주소 범위, 또는 아래에 설명된 특수 키워드 중 하나가 들어갈 수 있습니다.

    IP 주소는 CIDR 마스크 길이의 점으로 구분된 십진 표준 표기법으로 지정됩니다. 마스크 길이는 일치시킬 클라이언트 IP 주소의 상위 비트 수를 나타냅니다. 이 비트의 오른쪽에 있는 비트는 주어진 IP 주소에서 0이어야 합니다. IP 주소, “/”, CIDR 마스크 길이 사이에는 공백이 없어야 합니다.

    이러한 IP 주소 범위의 일반적인 예: 단일 호스트의 경우 172.20.143.89/32, 소규모 네트워크의 경우 172.20.143.0/24, 대규모 네트워크의 경우 10.6.0.0/16입니다. 0.0.0.0/0은 모든 IPv4 주소를 나타내고, ::/0은 모든 IPv6 주소를 나타냅니다. 단일 호스트를 지정하려면 IPv4의 경우 CIDR 마스크 32, IPv6의 경우 128을 사용하십시오. 네트워크 주소 끝의 0을 생략하지 마십시오.

    모든 IP 주소와 일치시키려면 “all”을, 서버 자신의 IP 주소에만 일치시키려면 samehost를 사용할 수 있습니다. 또한 서버가 직접 연결된 서브넷의 모든 주소와 일치시키려면 samenet을 사용할 수도 있습니다.

  • IP-address, IP-mask
    이 필드는 CIDR-address 표기법의 대안으로 사용할 수 있습니다. 마스크 길이를 지정하는 대신, 실제 마스크를 쉼표로 구분하여 지정합니다. 예를 들어, 255.0.0.0은 IPv4 CIDR 마스크 길이 8을 나타내고, 255.255.255.255는 CIDR 마스크 길이 32를 나타냅니다.

    이 필드는 host, hostssl, hostnossl 레코드에 적용됩니다.

  • auth-method
    연결이 이 레코드와 일치할 때 사용할 인증 방식을 지정합니다. 가능한 선택지는 다음과 같습니다:

    • trust
      무조건적인 연결을 허용합니다. 이 방식은 로그인한 모든 사용자가 비밀번호나 기타 인증을 요구받지 않고 AgensGraph 데이터베이스 서버에 연결할 수 있도록 허용합니다.

    • reject
      무조건적인 연결을 거부합니다. 이는 그룹 내의 특정 호스트를 “필터링”하려는 경우에 유용합니다. 예를 들어, reject 줄은 특정 호스트의 연결을 차단하고, 이후의 줄에서 특정 네트워크의 다른 호스트에 대한 연결을 허용합니다.

    • md5
      클라이언트는 인증을 위해 이중 MD5 해시된 비밀번호를 제공해야 합니다.

    • password
      클라이언트는 인증을 위해 암호화되지 않은 비밀번호를 제공해야 합니다. 비밀번호가 네트워크를 통해 평문으로 전송되므로, 신뢰할 수 없는 네트워크에서는 사용하지 마십시오.

    • gss
      GSSAPI를 사용하여 사용자를 인증합니다. 이는 TCP/IP 연결에서만 사용할 수 있습니다.

    • sspi
      SSPI를 사용하여 사용자를 인증합니다. 이는 Windows에서만 사용할 수 있습니다.

    • ident
      클라이언트의 ident 서버에 접속하여 클라이언트의 운영 체제 사용자 이름을 얻고, 그것이 요청된 데이터베이스 사용자 이름과 일치하는지 확인합니다. ident 인증은 TCP/IP 연결에서만 사용할 수 있습니다. 로컬 연결의 경우 대신 peer 인증이 사용됩니다.

    • peer
      운영 체제로부터 클라이언트의 운영 체제 사용자 이름을 얻고, 그것이 요청된 데이터베이스 사용자 이름과 일치하는지 확인합니다. 이는 로컬 연결에서만 사용할 수 있습니다.

    • ldap
      LDAP 서버를 사용한 인증입니다.

    • radius
      RADIUS 서버를 사용한 인증입니다.

    • cert
      SSL 클라이언트 인증을 사용한 인증입니다.

    • pam
      운영 체제가 제공하는 Pluggable Authentication Modules(PAM)를 사용하여 인증합니다.

    • auth-options
      auth-method 필드 뒤에는 인증 방식에 대한 옵션을 지정하는 name=value 필드가 올 수 있습니다.

    @를 포함하는 파일은 공백이나 쉼표로 구분된 이름 목록으로 읽힙니다. pg_hba.conf처럼 #로 표시된 주석과 중첩된 @ 구문이 허용됩니다. @ 뒤에 오는 파일 이름이 절대 경로가 아니면, 참조 파일이 위치한 디렉터리에 대한 상대 경로로 처리됩니다.

    pg_hba.conf 레코드는 각 연결 시도마다 순차적으로 검사되므로 레코드의 순서가 중요합니다. 앞쪽 레코드에서는 연결(일치) 매개변수가 엄격하고 인증 방식이 느슨하며, 뒤쪽 레코드에서는 연결 일치 매개변수가 느슨하고 인증 방식이 강합니다. 예를 들어, 원격 TCP/IP 연결을 수행하면서 로컬 TCP/IP 연결에는 trust 인증을 사용할 수 있습니다. 이러한 경우, 127.0.0.1로부터의 연결에 대해 trust 인증을 지정하는 레코드가 다양한 허용된 클라이언트 IP 주소에 대해 비밀번호 인증을 지원하는 레코드보다 앞에 나타납니다.

사용자 이름 맵

Ident나 GSSAPI와 같은 외부 인증 시스템을 사용하는 경우, 연결을 시작하는 운영 체제 사용자의 이름이 연결할 데이터베이스 사용자의 이름과 다를 수 있습니다. 이러한 경우, 사용자 이름 맵을 사용하여 운영 체제 사용자 이름을 데이터베이스 사용자 이름에 매핑할 수 있습니다. 사용자 이름 매핑을 사용하려면, pg_hba.conf의 옵션 필드에 map=map-name을 지정해야 합니다. 이 옵션은 외부 사용자 이름을 받는 모든 인증 방식에서 지원됩니다. 연결마다 서로 다른 매핑이 필요할 수 있으므로, 사용할 맵의 이름은(연결별 맵을 지정하기 위해) pg_hba.conf의 map-name 매개변수에 지정할 수 있습니다.

사용자 이름 맵은 ident 맵 파일에 정의되며, 그 이름은 pg_ident.conf(기본값)이고 데이터 디렉터리에 저장됩니다.

map-name system-username database-username

주석과 공백은 pg_hba.conf에서와 동일하게 처리됩니다. map-name은 매핑을 참조하기 위해 pg_hba.conf에서 사용되는 임의의 이름입니다. 나머지 두 필드는 운영 체제 사용자 이름과 데이터베이스 사용자 이름을 지정합니다. 동일한 map-name을 여러 번 사용하여 하나의 맵 안에 여러 사용자 매핑을 지정할 수 있습니다.

주어진 운영 체제 사용자에 대응하는 데이터베이스 사용자의 수(및 그 반대)에는 제한이 없습니다. 따라서 맵의 항목에 대해서는 사용자가 동일하다는 것이 아니라 “이 운영 체제 사용자가 데이터베이스 사용자로 연결할 수 있도록 허용됨”이라고 간주해야 합니다. 외부 인증 시스템에서 얻은 사용자 이름이 사용자가 연결을 요청할 때 사용한 데이터베이스 사용자 이름과 짝을 이루는 맵 항목이 있으면 연결이 허용됩니다.

system-username 필드가 슬래시(/)로 시작하면, 필드의 나머지 부분은 정규 표현식으로 처리됩니다. 정규 표현식에는 단일 캡처나 대괄호 표현식이 포함될 수 있으며, database-username 필드에서 \1(백슬래시)로 참조할 수 있습니다. 한 줄에서 여러 사용자 이름을 매핑할 수 있으며, 특히 단순한 구문 치환에 유용합니다. 예제:

mymap /^(.*)@mydomain\.com$\1
mymap /^(.*)@otherdomain\.com$ guest

이 항목은 @mydomain.com으로 끝나는 시스템 사용자 이름을 사용하는 사용자에 대해 도메인 부분을 삭제하고, 시스템 이름이 @otherdomain.com으로 끝나는 모든 사용자가 guest로 로그인할 수 있도록 허용합니다.

인증 방식

이 절에서는 인증 방식을 자세히 설명합니다.

Trust 인증

trust 인증이 지정되면, AgensGraph는 지정된 데이터베이스 사용자 이름을 사용하여 서버에 연결할 수 있는 모든 사람이 데이터베이스 접근에 대해 인증된 것으로 간주합니다(슈퍼유저 이름 포함). database 및 user 열의 제한은 여전히 적용됩니다. 이 방식은 서버 연결에 대해 적절한 운영 체제 수준의 보호가 제공되는 경우에만 사용해야 합니다.

trust 인증은 단일 사용자 워크스테이션에 대한 로컬 연결에 적합하며 매우 편리합니다. 그러나 일반적으로 다중 사용자 머신에는 적합하지 않습니다. trust 인증은 서버에 연결이 허용된 모든 머신의 모든 사용자가 trust를 지정하는 pg_hba.conf에서 신뢰되는 경우에만 TCP/IP 연결에 적합합니다. localhost(127.0.0.1)를 제외한 TCP/IP 연결에 trust를 사용하는 것은 합리적이지 않습니다.

Password 인증

비밀번호 기반 인증 방식은 md5와 password입니다. 두 방식은 비밀번호가 각각 MD5 해시와 평문으로 전송된다는 점을 제외하면 유사하게 동작합니다.

비밀번호 “스니핑” 공격을 방어하기 위해서는 md5를 사용하는 것이 바람직하며, 일반 password는 가능하면 피해야 합니다. 그러나 md5는 db_user_namespace 기능과 함께 사용할 수 없습니다. 연결이 SSL 암호화로 보호되는 경우에는 password를 안전하게 사용할 수 있습니다.

AgensGraph 데이터베이스 비밀번호는 운영 체제 사용자 비밀번호와 구분됩니다. 각 데이터베이스 사용자의 비밀번호는 pg_authid 시스템 카탈로그에 저장됩니다. 이러한 비밀번호는 SQL 명령 CREATE USER와 ALTER ROLE로 관리할 수 있습니다(예: CREATE USER foo WITH PASSWORD ‘secret’). 사용자에 대해 비밀번호가 설정되지 않은 경우, 저장된 비밀번호는 null이며 해당 사용자에 대한 비밀번호 인증은 항상 실패합니다.

GSSAPI 인증

GSSAPI는 RFC 2743에 정의된 보안 인증을 위한 업계 표준 프로토콜로, GSSAPI를 지원하는 시스템에 대해 단일 로그인(single sign-on)을 제공합니다. 인증 자체는 안전하지만, SSL을 사용하지 않으면 데이터베이스 연결을 통해 전송되는 데이터는 암호화되지 않은 채로 전송됩니다.

데이터베이스에 연결할 때, 요청된 데이터베이스 사용자의 이름과 일치하는 보안 규칙에 대한 티켓이 있는지 확인해야 합니다. 예를 들어, 데이터베이스 이름이 fred인 경우, 보안 규칙 fred@EXAMPLE.COM으로 연결할 수 있습니다.

GSSAPI에 대해 다음 설정 옵션이 지원됩니다.

  • include_realm
    1로 설정하면, 인증된 사용자 보안 규칙의 realm 이름이 사용자 이름 매핑을 통해 전달되는 시스템 사용자 이름에 포함됩니다. 이는 여러 realm의 사용자를 처리할 때 유용합니다.

  • map
    시스템 사용자 이름과 데이터베이스 사용자 이름 간의 매핑을 허용합니다.

  • krb_realm
    사용자 보안 규칙 이름과 일치하는 realm을 설정합니다. 이 매개변수가 설정되면, 해당 realm의 사용자만 허용됩니다. 설정하지 않으면 모든 realm의 사용자가 연결할 수 있으며, realm은 사용자 이름 매핑의 완전성 여부에 따라 달라집니다.

SSPI 인증

SSPI는 단일 로그인(SSO) 보안 인증을 위한 Windows 기술입니다. AgensGraph는 negotiate 모드에서 SSPI를 사용합니다. 사용 가능한 경우 Kerberos를 사용하고, 그 외의 경우에는 자동으로 NTLM으로 폴백합니다. SSPI 인증은 서버와 클라이언트가 모두 Windows를 사용할 때에만 동작합니다. GSSAPI를 사용할 수 있는 경우에는 비Windows 환경에서도 동작합니다.

Kerberos 인증을 사용하는 동안 SSPI는 GSSAPI와 동일한 방식으로 동작합니다.

SSPI에 대해 다음 설정 옵션이 지원됩니다.

  • include_realm
    1로 설정하면, 인증된 사용자 보안 규칙의 realm 이름이 사용자 이름 매핑을 통해 전달되는 시스템 사용자 이름에 포함됩니다. 이는 여러 realm의 사용자를 처리할 때 유용합니다.

  • map
    시스템 사용자 이름과 데이터베이스 사용자 이름 간의 매핑을 허용합니다.

  • krb_realm
    사용자 보안 규칙 이름과 일치하는 realm을 설정합니다. 이 매개변수가 설정되면, 해당 realm의 사용자만 허용됩니다. 설정하지 않으면 모든 realm의 사용자가 연결할 수 있으며, realm은 사용자 이름 매핑의 완전성 여부에 따라 달라집니다.

Ident 인증

ident 인증 방식은 ident 서버로부터 클라이언트의 운영 체제 사용자 이름을 얻고 이를 허용된 데이터베이스 사용자 이름으로 사용하는 방식으로 동작합니다(선택적 사용자 이름 매핑이 적용됨). 이 인증은 TCP/IP 연결에서만 지원됩니다.

ident에 대해 다음 설정 옵션이 지원됩니다:

  • map
    시스템 사용자 이름과 데이터베이스 사용자 이름 간의 매핑을 허용합니다.

일부 ident 서버에는 반환된 사용자 이름을 원본 머신의 관리자만 아는 키로 암호화할 수 있는 비표준 옵션이 있습니다. AgensGraph는 반환된 문자열을 복호화하여 실제 사용자 이름을 확인할 방법이 없으므로, ident 서버에서 AgensGraph를 사용하는 경우 이 옵션을 사용하지 마십시오.

Peer 인증

peer 인증 방식은 커널로부터 클라이언트의 운영 체제 사용자 이름을 얻고 이를 허용된 데이터베이스 사용자 이름으로 사용하는 방식으로 동작합니다(선택적 사용자 이름 매핑이 적용됨). 이 인증은 로컬 연결에서만 지원됩니다.

peer에 대해 다음 설정 옵션이 지원됩니다:

  • map
    시스템 사용자 이름과 데이터베이스 사용자 이름 간의 매핑을 허용합니다.

peer 인증은 getpeereid(), SO_PEERCRED(소켓 매개변수) 또는 이와 유사한 메커니즘을 제공하는 Linux와 같은 운영 체제에서만 사용할 수 있습니다.

LDAP 인증

이 인증은 LDAP를 비밀번호 검증 방식으로 사용하는 경우를 제외하면 password처럼 동작합니다. LDAP는 사용자 이름/비밀번호 쌍을 검증할 때에만 사용됩니다. 이는 인증에 LDAP를 적용하기 전에 사용자가 데이터베이스에 존재해야 함을 의미합니다.

LDAP 인증은 두 가지 모드로 수행할 수 있습니다. 첫 번째 모드(단순 바인딩 모드)는 서버를 prefix username suffix로 구성된 고유한 이름에 바인딩하는 것입니다. 일반적으로 prefix 매개변수는 액티브 디렉터리 환경에서 cn= 또는 DOMAIN\을 지정하는 데 사용되고, suffix는 액티브 디렉터리 환경의 나머지를 지정하는 데 사용됩니다.

두 번째 모드(검색+바인딩 모드)에서는, 서버가 먼저 ldapbinddn과 ldapbindpasswd를 통해 지정된 고정 사용자 이름과 비밀번호를 사용하여 LDAP 디렉터리에 바인딩한 다음, 데이터베이스에 로그인하려는 사용자를 검색합니다. 사용자와 비밀번호가 설정되지 않은 경우, 디렉터리에 대한 익명 바인딩이 시도됩니다. 검색은 ldapbasedn의 하위 트리에서 수행되며 ldapsearchattribute와 정확히 일치하는 항목이 검색됩니다. 이 검색에서 사용자를 찾으면, 서버는 연결을 끊고 클라이언트에서 지정한 비밀번호를 사용하여 해당 사용자로 디렉터리에 다시 바인딩하여 로그인이 올바른지 확인합니다. 이 모드는 Apache mod_authnz_ldap나 pam_ldap와 같은 다른 소프트웨어의 LDAP 인증 스키마에서 사용되는 방식과 동일합니다. LDAP 인증은 사용자 객체가 디렉터리에 있을 때 더 유연하게 동작하지만, 두 LDAP 서버의 연결을 끊습니다.

다음 설정 옵션은 두 모드 모두에서 사용됩니다.

  • ldapserver
    연결할 LDAP 서버의 이름 또는 IP 주소입니다. 공백으로 구분하여 여러 서버를 지정할 수 있습니다.

  • ldapport
    연결할 LDAP 서버의 포트 번호입니다. 포트를 지정하지 않으면 LDAP 라이브러리의 기본 포트 설정이 사용됩니다.

  • ldaptls
    1로 설정하면, AgensGraph는 TLS 암호화를 사용하여 LDAP 서버에 연결됩니다. 이는 LDAP 서버로의 트래픽만 암호화합니다. SSL을 사용하지 않는 한 클라이언트로의 연결은 암호화되지 않은 상태로 유지됩니다.

다음 옵션은 단순 바인딩 모드에서만 사용됩니다.

  • ldapprefix
    단순 바인딩 인증을 수행할 때 DN 바인딩에서 사용자 이름 앞에 붙이는 문자열입니다.

  • ldapsuffix
    단순 바인딩 인증을 수행할 때 DN 바인딩에서 사용자 이름 뒤에 붙이는 문자열입니다.

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

  • ldapbasedn
    검색+바인딩 인증을 수행할 때 사용자 검색이 시작되는 루트 DN입니다.

  • ldapbinddn
    검색+바인딩 인증 중 검색을 수행하기 위해 디렉터리에 바인딩하는 사용자 DN입니다.

  • ldapbindpasswd
    검색+바인딩 인증 중 검색을 수행하기 위해 디렉터리에 바인딩하는 사용자의 비밀번호입니다.

  • ldapsearchattribute
    검색+바인딩 인증을 수행할 때 검색에서 사용자 이름과 일치하는 속성입니다. 속성을 지정하지 않으면 uid 속성이 사용됩니다.

  • ldapurl
    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은 현재 OpenLDAP에서만 지원되며 Windows에서는 지원되지 않습니다.

단순 바인딩의 설정 옵션과 검색+바인딩의 옵션을 섞어 사용하는 것은 오류입니다.

단순 바인딩 LDAP 설정의 예:

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

데이터베이스 사용자 someuser가 데이터베이스 서버에 연결을 요청하면, AgensGraph는 DN cn=someuser와 dc=example, dc=net, 그리고 클라이언트가 제공한 비밀번호를 사용하여 LDAP 서버에 바인딩을 시도합니다. 연결이 성공하면 데이터베이스 접근이 허용됩니다.

검색+바인딩 설정의 예는 다음과 같습니다:

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

데이터베이스 사용자 someuser가 데이터베이스 서버에 연결을 요청하면, AgensGraph는 (ldapbinddn이 지정되지 않았으므로) LDAP 서버에 익명으로 바인딩을 시도하고 지정된 기본 DN 하위에서 (uid=someuser)에 대한 검색을 수행합니다. 항목을 찾으면, 발견된 정보와 클라이언트가 제공한 비밀번호를 사용하여 바인딩을 시도합니다. 보조 연결이 성공하면 데이터베이스 접근이 허용됩니다.

URL을 사용한 동일한 검색+바인딩 설정은 다음과 같습니다:

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

LDAP 인증을 지원하는 다른 소프트웨어도 동일한 URL 형식을 사용하므로, 설정을 공유하기가 더 쉬워집니다.

RADIUS 인증

이 인증은 LDAP를 비밀번호 검증 방식으로 사용하는 경우를 제외하면 password처럼 동작합니다. RADIUS는 사용자 이름/비밀번호 쌍을 검증할 때에만 사용됩니다. 이는 인증에 RADIUS를 적용하기 전에 사용자가 데이터베이스에 존재해야 함을 의미합니다.

RADIUS 인증을 사용하는 경우, 설정된 RADIUS 서버로 Access Request 메시지가 전송됩니다. 이 요청은 Authenticate Only 유형이며 user name, password(암호화됨), NAS Identifier에 대한 매개변수를 포함합니다. 요청은 서버와 공유되는 secret을 사용하여 암호화됩니다. RADIUS 서버는 Access Accept 또는 Access Reject를 회신합니다. RADIUS 계정은 지원되지 않습니다.

RADIUS에 대해 다음 설정 옵션이 지원됩니다.

  • radiusserver
    연결할 RADIUS 서버의 이름 또는 IP 주소입니다. 이 매개변수는 필수입니다.

  • radiussecret
    보안을 유지하면서 RADIUS 서버와 통신할 때 사용되는 공유 secret입니다. AgensGraph와 RADIUS 서버에서의 값은 동일해야 합니다. 최소 16자 이상의 문자열을 권장합니다. 이 매개변수는 필수입니다.

  • radiusport
    연결할 RADIUS 서버의 포트 번호입니다. 포트를 지정하지 않으면 기본 포트 “1812”가 사용됩니다.

  • radiusidentifier
    RADIUS 요청에서 NAS 식별자로 사용되는 문자열입니다. 예를 들어, 이 매개변수는 인증할 데이터베이스 사용자를 식별함으로써 RADIUS 서버에서 보조 매개변수로 사용할 수 있습니다. 식별자를 지정하지 않으면 기본값 postgresql이 사용됩니다.

Certificate 인증

이 방식은 SSL 클라이언트 인증서를 사용하여 인증을 수행하므로 SSL 연결에서만 사용할 수 있습니다. 이 인증 방식을 적용하면, 서버는 클라이언트에게 유효한 인증서를 제공하도록 요구합니다. 비밀번호 프롬프트는 클라이언트로 전송되지 않습니다. 인증서의 cn(common name) 속성은 요청된 데이터베이스 사용자 이름과 비교되며, 일치하면 로그인이 허용됩니다. 사용자 이름 매핑을 사용하여 cn을 데이터베이스 사용자 이름과 다르게 설정할 수 있습니다.

SSL 인증서 인증에 대해 다음 설정 옵션이 지원됩니다.

  • map
    시스템 사용자 이름과 데이터베이스 사용자 이름 간의 매핑을 허용합니다.

PAM 인증

이 인증은 Pluggable Authentication Modules(PAM)를 인증 메커니즘으로 사용하는 경우를 제외하면 password처럼 동작합니다. 기본 PAM 서비스 이름은 postgresql입니다. PAM은 사용자 이름/비밀번호 쌍을 검증할 때에만 사용됩니다. 이는 인증에 PAM을 적용하기 전에 사용자가 데이터베이스에 존재해야 함을 의미합니다.

PAM에 대해 다음 설정 옵션이 지원됩니다.

  • pamservice
    PAM 서비스 이름입니다.

인증 문제

인증 실패와 관련 문제는 일반적으로 다음과 같은 오류 메시지를 통해 드러납니다:

FATAL:no pg_hba.conf entry for host "123.123.123.123", user "andym", database "testdb"

이는 해당 사용자로 연결이 가능함을 의미합니다. 메시지에 나타난 것처럼, 서버는 pg_hba.conf 설정 파일에서 일치하는 항목을 찾지 못했기 때문에 연결 요청을 거부했습니다.

FATAL:password authentication failed for user "andym"

이 메시지는 사용자가 서버에 접속하여 해당 사용자로 연결이 가능하지만, 사용자가 pg_hba.conf 파일에 지정된 인증 방식을 통과해야 함을 의미합니다. 사용자가 입력한 비밀번호를 확인하거나, 이 인증 유형에 문제가 있는 경우 사용자의 Kerberos 또는 ident 소프트웨어를 점검해야 합니다.

FATAL:user "andym" does not exist

표시된 데이터베이스 사용자 이름을 찾지 못했습니다.

FATAL:database "testdb" does not exist

연결하려는 데이터베이스가 존재하지 않습니다. 데이터베이스 이름을 지정하지 않으면, 데이터베이스 사용자 이름이 데이터베이스 이름으로 간주됩니다.

name은 SQL 식별자의 규칙을 따릅니다(특수 문자나 큰따옴표는 허용되지 않습니다). 기존 롤을 삭제하려면 DROP ROLE 명령을 사용합니다.

db=# DROP ROLE name;

편의를 위해, 셸 명령줄에서 호출할 수 있는 createuser와 dropuser 프로그램이 SQL 명령의 래퍼로 제공됩니다.

createuser name
dropuser name

기존 롤 집합을 확인하려면 pg_roles 시스템 카탈로그를 조회하십시오. 예를 들면 다음과 같습니다:

db=# SELECT rolname FROM pg_roles;

psql 프로그램의 \du 메타 명령도 기존 롤을 나열하는 데 유용합니다.

롤 속성

데이터베이스 롤에는 권한을 정의하고 클라이언트 인증 시스템과 상호작용하는 여러 속성이 있습니다.

  • 로그인 권한
    데이터베이스 연결의 초기 롤 이름으로는 LOGIN 속성을 가진 롤만 사용할 수 있습니다. LOGIN 속성을 가진 롤은 “데이터베이스 사용자”와 동일하게 간주할 수 있습니다. 로그인 권한을 가진 롤을 생성하려면 다음 중 하나를 사용하십시오:

    CREATE ROLE name LOGIN;
CREATE USER name;

    (CREATE USER는 기본적으로 LOGIN 권한을 부여한다는 점에서 CREATE ROLE과 다릅니다.)

  • 슈퍼유저 상태
    데이터베이스 슈퍼유저는 로그인 권한을 제외한 모든 권한 검사를 건너뜁니다. 슈퍼유저 권한은 위험할 수 있으므로 신중하지 못하게 사용해서는 안 됩니다. 대부분의 작업은 슈퍼유저가 아닌 롤로 처리하는 것이 권장됩니다. 새로운 데이터베이스 슈퍼유저를 생성하려면 CREATE ROLE name SUPERUSER를 사용하며, 이 작업은 슈퍼유저 롤이 수행해야 합니다.

  • 데이터베이스 생성
    데이터베이스를 생성하려면, 필요한 권한이 롤에 명시적으로 부여되어야 합니다(모든 권한 검사를 건너뛰는 슈퍼유저는 제외). 이 롤을 생성하려면 CREATE ROLE name CREATEDB를 사용합니다.

  • 롤 생성
    추가 롤을 생성하려면, 필요한 권한이 롤에 명시적으로 부여되어야 합니다(모든 권한 검사를 건너뛰는 슈퍼유저는 제외). 이 롤을 생성하려면 CREATE ROLE name CREATEROLE을 사용합니다. CREATEROLE 권한을 가진 롤은 다른 롤을 변경 및 삭제할 수 있으며 멤버십을 부여하거나 취소할 수 있습니다. 그러나 슈퍼유저 롤을 생성, 변경, 삭제하거나 그 멤버십을 변경하려면 슈퍼유저 상태가 필요하며, CREATEROLE로는 이 작업을 수행할 수 없습니다.

  • 복제 시작
    스트리밍 복제를 시작하려면, 해당 권한이 롤에 명시적으로 부여되어야 합니다(모든 권한 검사를 건너뛰는 슈퍼유저는 제외). 스트리밍 복제에 사용되는 롤은 항상 LOGIN 권한을 가지고 있어야 합니다. 이 롤을 생성하려면 CREATE ROLE name REPLICATION LOGIN을 사용합니다.

  • password
    비밀번호는 사용자가 데이터베이스에 연결할 때 비밀번호 입력을 요구하는 클라이언트 인증 방식의 경우에만 중요합니다. password와 md5 인증 방식은 비밀번호를 사용합니다. 데이터베이스 비밀번호는 운영 체제 사용자 비밀번호와 구별됩니다. 롤을 생성할 때 CREATE ROLE name PASSWORD 'string'을 사용하여 비밀번호를 지정할 수 있습니다.

롤 멤버십

권한 관리의 편의를 위해 사용자를 그룹화할 수 있습니다. 이를 통해 그룹 단위로 권한을 부여하거나 취소할 수 있습니다. AgensGraph에서는 그룹을 나타내는 롤을 생성한 다음, 그 그룹 롤의 멤버십을 개별 사용자 롤에 할당함으로써 이를 수행합니다.

그룹 롤을 설정하려면, 먼저 롤을 생성해야 합니다.

CREATE ROLE name;

일반적으로 그룹으로 사용되는 롤은 LOGIN 속성을 갖지 않지만, 필요한 경우 설정할 수 있습니다.

그룹 롤이 존재하면, GRANT와 REVOKE 명령을 사용하여 멤버를 추가하고 삭제할 수 있습니다.

GRANT group_role TO role1, ... ;
REVOKE group_role FROM role1, ... ;

다른 그룹 롤에도 멤버십을 부여할 수 있습니다(그룹 롤과 비그룹 롤 사이에 실질적인 구분은 없습니다). 데이터베이스는 순환 멤버십 루프를 설정하거나 PUBLIC에 롤 멤버십을 부여하는 것을 허용하지 않습니다.

그룹 롤의 멤버는 두 가지 방식으로 해당 롤의 권한을 사용할 수 있습니다. 첫째, 그룹의 모든 멤버는 SET ROLE을 명시적으로 수행하여 일시적으로 그룹 롤이 “됩니다”. 이 상태에서 데이터베이스 세션은 (원래 로그인 롤이 아니라) 그룹 롤에 접근하며, 생성된 데이터베이스 객체는 로그인 롤이 아니라 그룹 롤이 소유한 것으로 간주됩니다. 둘째, INHERIT 속성을 가진 멤버 롤은 해당 롤로부터 상속된 모든 권한을 포함하여, 멤버로서 그 롤의 권한을 자동으로 갖습니다. 예를 들어, 다음을 실행했다고 가정해 보겠습니다:

CREATE ROLE joe LOGIN INHERIT;
CREATE ROLE admin NOINHERIT;
CREATE ROLE wheel NOINHERIT;
GRANT admin TO joe;
GRANT wheel TO admin;

데이터베이스 세션이 joe 롤로 연결된 직후, joe는 (joe에게 직접 부여된 권한에 더해) admin의 권한을 “상속”하여 이를 사용할 수 있습니다. joe는 간접적으로 wheel의 멤버입니다. 그러나 이 멤버십은 NOINHERIT 속성을 가진 admin을 통해 부여되었으므로, wheel에 부여된 권한은 사용할 수 없습니다.

SET ROLE admin;

위 명령을 실행하면, 세션은 admin에 부여된 권한만 사용하며 joe에 부여된 권한은 사용하지 않습니다.

SET ROLE wheel;

위 명령을 실행하면, 세션은 joe나 admin에 부여된 권한이 아니라 wheel에 부여된 권한만 사용합니다. 원래의 권한 상태는 다음 중 하나를 사용하여 복원됩니다:

SET ROLE joe;
SET ROLE NONE;
RESET ROLE;

LOGIN(롤 속성), SUPERUSER, CREATEDB, CREATEROLE은 특수 권한으로 생각할 수 있지만, 데이터베이스 객체의 일반 권한처럼 상속되지는 않습니다. 이들을 사용하려면, 이러한 속성 중 하나를 가진 특정 롤로 실제로 SET ROLE을 수행해야 합니다. 위 예제에서는 admin 롤에 CREATEDB와 CREATEROLE을 부여하는 것도 가능합니다. 그러나 joe 롤로 연결된 세션은 이러한 권한을 즉시 가질 수 없으며, SET ROLE admin을 실행한 후에야 부여됩니다.

그룹 롤을 삭제하려면 DROP ROLE을 사용해야 합니다.

DROP ROLE name;

그룹 롤의 멤버십은 자동으로 취소됩니다(다만 멤버 롤은 영향을 받지 않습니다). 그룹 롤이 소유한 객체는 먼저 삭제하거나 다른 소유자에게 재할당해야 하며, 그룹 롤에 부여된 권한은 반드시 취소해야 한다는 점에 유의하십시오.