OpenLDAP 기반 통합 인증 아키텍처 (3) — 클라이언트 연동과 접근정책 구성

1. 개요

이 문서는 리눅스 서버(클라이언트) 가 OpenLDAP 서버를 통해 중앙 인증을 수행하도록 설정하는 과정을 다룬다.
이를 통해 각 서버의 로컬 계정 관리 없이 LDAP 계정으로 SSH 로그인, sudo, su 권한 제어를 통합할 수 있다.

⚠️ 주의:
본문에 등장하는 IP, 도메인명, hostname, 계정명은 모두 예시이며,
실제 운영 환경에서는 반드시 조직의 보안정책에 맞게 변경해야 한다.

2. 구성 개요

LDAP 기반 인증 구조는 다음과 같다.

[사용자 SSH 로그인]
   ↓
[PAM → NSS → SSSD/nslcd]
   ↓
[OpenLDAP Server]
   ↓
[그룹 정책 / sudo 권한 / ACL 매핑]
   ↓
[Auditd → 중앙 로그 서버]

핵심은 클라이언트 측의 PAM/SSSD 설정이며,
이를 통해 SSH 로그인·sudo 권한·그룹 기반 접근이 모두 LDAP 정책과 연동된다.

3. 클라이언트 패키지 설치

CentOS / RHEL 계열

# yum install -y openldap-clients nss-pam-ldapd sssd authconfig

Ubuntu 계열

# apt install -y libnss-ldap libpam-ldap nslcd sssd

4. LDAP 서버 연결 설정

4.1 기본 인증 구성 (authconfig)

# authconfig \
  --enableldap \
  --enableldapauth \
  --ldapserver=ldap://ldap.example.com \
  --ldapbasedn="dc=example,dc=com" \
  --enablemkhomedir \
  --update

--enablemkhomedir 옵션은 LDAP 계정이 처음 로그인할 때 자동으로 홈디렉토리를 생성한다.

서비스 등록:

# systemctl enable nslcd
# systemctl restart nslcd

5. NSS/PAM 연동 확인

5.1 /etc/nsswitch.conf

passwd:     files ldap
shadow:     files ldap
group:      files ldap

5.2 /etc/pam.d/system-auth

(authconfig가 자동 구성하지만, 수동 편집 시 예시)

auth       required     pam_env.so
auth       sufficient   pam_unix.so nullok try_first_pass
auth       sufficient   pam_ldap.so use_first_pass
account    required     pam_unix.so broken_shadow
account    sufficient   pam_localuser.so
account    sufficient   pam_ldap.so
password   sufficient   pam_ldap.so use_authtok
session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077

6. LDAP DB ACL (데이터 접근제어)

여기서 다루는 ACL은 LDAP 서버 내부 데이터베이스 접근제어 정책이다.
이는 SSH나 sudo 같은 시스템 접근 제어가 아니라,
LDAP 데이터(userPassword, 그룹 정보 등)에 대한 읽기/쓰기 권한을 정의한다.

예시 LDIF:

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attr=userPassword
  by dn="cn=manager,dc=example,dc=com" write
  by self write
  by * read
olcAccess: {1}to *
  by dn="cn=manager,dc=example,dc=com" write
  by * read

의미:

• 관리자(manager)는 모든 항목 수정 가능
• 사용자는 자신의 암호 속성만 변경 가능
• 그 외 사용자는 LDAP 데이터를 읽기만 가능

이 ACL은 LDAP 서버 데이터 무결성과 보안을 강화하기 위한 설정이다.
즉, “어떤 사용자가 LDAP 엔트리를 수정할 수 있는가”를 정의하는 수준이지,
서버 로그인이나 sudo 권한과는 직접적인 관련이 없다.

7. 그룹 기반 접근정책 (클라이언트 측)

조직 단위로 ou=Group 아래에 팀별 그룹을 정의한다.

ou=Group,dc=example,dc=com
 ├── cn=ops
 ├── cn=dev
 └── cn=qa

각 사용자(uid=user01)는 memberOf 속성으로 그룹에 소속되며,
SSSD가 이 정보를 OS 그룹으로 변환한다.
이를 통해 디렉토리 접근권한, sudo 정책, su 제한이 적용된다.

8. 디렉토리 접근권한 예시

운영팀은 /srv/app 디렉토리에 읽기·쓰기 가능,
개발팀은 읽기 전용으로 설정하는 예시:

# setfacl -R -m g:ops:rwX /srv/app
# setfacl -R -m g:dev:rX /srv/app

⚠️ 대문자 X는 디렉토리 또는 이미 실행 가능한 파일에만 실행 권한을 부여한다.
불필요한 실행 속성 부여를 방지하기 위해 일반적으로 x 대신 X를 사용한다.

9. SUDO 정책 LDAP 연동

LDAP 서버에 sudo.schema가 적용되어 있다면,
그룹별 sudo 권한을 중앙에서 관리할 수 있다.

클라이언트 설정 파일 /etc/sudo-ldap.conf:

base    dc=example,dc=com
uri     ldap://ldap.example.com
BINDDN  cn=manager,dc=example,dc=com
BINDPW  <manager_password>
SUDOERS_BASE ou=sudo,ou=people,dc=example,dc=com

/etc/nsswitch.conf에 추가:

sudoers: files ldap

이후 LDAP 상의 ou=sudo 내 cn=ops 그룹에 운영팀 UID를 추가하면,
해당 그룹 사용자는 자동으로 sudo 권한을 얻게 된다.

10. 서비스 재시작 및 테스트

# systemctl restart nslcd
# getent passwd user01
# su - user01

정상적으로 LDAP 계정이 조회되고 로그인 가능하면 연동이 완료된 것이다.

11. 문제 해결 가이드

12. 다음 단계 예고

다음 4편에서는 LDAP 기반 sudo 권한 세분화와 감사(Audit) 로그 통합을 다룬다.
LDAP sudoRole 구조 확장과 auditd + rsyslog를 이용한 명령 이력 중앙화를 정리할 예정이다.

🛠 마지막 수정일: 2025.10.21