PAM/ko
PAM, 또는 장착 가능 인증 모듈은, 모듈화 인증 기법입니다. (서드 파티) 서비스에서 PAM 기능 활성 시스템에서 사용할 수 있도록 서비스에 인증 모듈을 제공할 수 있도록 합니다. PAM 인증 기능을 사용하는 서비스는 모듈을 따로 빌드하지 않고 바로 사용할 수 있습니다.
도입부
리눅스 서버의 인증 관리(접근 관리 일부)는 PAM(장착 가능 인증 모듈)으로 처리할 수 있습니다. PAM은, 서비스 자체에서 인증 서비스를 제공할 필요가 없게 합니다. 대신, 시스템에서 사용하는 PAM 모듈에 의존합니다. 각각의 서비스는 제각각의 서비스마다 유사하게 대부분의 시간 기반 인증을 처리하지만, 원하는 경우 제각기 다른 PAM 설정을 사용할 수 있습니다. PAM 모듈을 호출하면, 특별하게 2개 인자 인증을 지원할 수 있으며, 집중 인증 저장소 그 이상의 기능을 바로 사용할 수 있습니다.
PAM은 다음 서비스에 대해 유연한 모듈식 구조를 지원합니다:
- 인증 관리 - 사용자 계정 접근을 인증할 때 사용자가 누군지 검증
- 계정 관리 - 사용자의 암호 기간이 끝났거나 사용자로 하여금 제각각의 서비스에 접근할 수 있는지 확인.
- 세션 관리 - 사용자의 로그인, 로그오프 작업(감사, 파일 시스템 마운트 등)을 실행.
- 암호 관리 - 암호 초기화 같은 목적을 다루는 인터페이스 제공.
PAM에서는 승인을 목적으로 하는 서비스는 제공하지 않습니다. 일반적으로 절차 승인은 프로그램에서 처리합니다. 일부 프로그램에서는 그룹 기반 승인을 지원합니다(때문에 그룹의 구성원이 되면 적당한 권한을 승인받습니다). 이런 일련의 과정의 경우 일반적(이지만 PAM만큼 일반적인건 아닙니다)인 접근은 NSS(이름 서비스 전환)를 지원하는 방안입니다. NSS는 PAM과 설계 관점에서 근본적으로 유사합니다. 사실 리눅스 시스템의 승인 과정은 NSS 라이브러리에서 처리합니다.
PAM에 숨겨놓은 원리
PAM을 다룰 때, 관리자 여러분께서는 PAM과 동작하는 요소가 무엇인지 간단하게 살펴보도록 하겠습니다.
첫번째는 백엔드 독립성입니다. PAM을 인지하는 프로그램은 데이터베이스, LDAP 서비스, 암호 파일, WS-보안 가능 웹서비스 또는 아직 고안하지 않은 다른 백엔드 같은 부분을 다룰 어떤 로직도 포함할 필요가 없습니다. PAM을 사용하면 프로그램 백엔드 통합 로직 자체로부터 프로그램을 따로 떨어뜨려놓습니다. 이 자체로 필요한 기능이 PAM 기능입니다.
다른 원리는 설정 원리입니다. 관리자는 제각기 다른 프로그램에서 LDAP 서버와 어떻게 인증 단계에서 상호 작용할지 알아볼 필요가 없습니다. 대신 PAM에서 제공하는 동일한 설정 구조를 쓰시면 됩니다.
PAM 이름의 일부이자 최종 원리는 장착 가능 구조 입니다. 새 백엔드를 통합해야 한다면 모든 관리자가 해야 할 일은 이 백엔드용 라이브러리의 설치(시스템의 올바른 티렉터리에 복사)와 이 모듈의 설정(대부분의 모듈은 단일 설정 파일을 사용함)입니다. 이 시점이 지나면, 프로그램용 모듈을 사용할 수 있습니다. 관리자는 백엔드를 사용할 수 있게 인증을 설정할 수 있으며, 단지 프로그램을 다시 시작하기만 하면 됩니다.
PAM 동작 원리
PAM 연결을 사용하려는 프로그램은 PAM 라이브러리(libpam)와 연결하며 서비스에 얹혀 돌아가는 필요 함수를 호출합니다. 이 외에는, PAM에서 모두 처리하므로 프로그램에서 이 서비스에 대한 특정 기능을 구현할 필요가 없습니다. 따라서 사용자가 자체 인증을 처리하고 싶다고 웹 프로그램에 알리면 이 웹 프로그램에서 PAM을 호출하고(사용자 ID와 암호 또는 구문을 전달하겠(...)죠) 사용자에게 인증 허가를 내어 프로그램 접근을 허가했을 때 살펴볼 PAM 반환 값을 확인합니다. 이 과정이 바로 PAM이 신원 인증을 처리하는 대상에 대해 근본적으로 확인하는 작업입니다.
PAM의 강력함은 PAM 기능을 모든 사람들이 PAM 기능을 사용할 수 있는 서비스 또는 프로그램에 통합할 PAM 모듈을 빌드할 수 있다는 점입니다. 어떤 회사에서 새 인증 서비스를 출시하려 한다면, 필요한 모든 일은 서비스와 함께 동작하는 PAM 모듈을 제공하는 일이며, 단지 이렇게 제공하고 나서는 PAM 기능을 사용하는 모든 프로그램이 이 서비스와 함께 직접적으로 동작할 수 있습니다. 프로그램을 다시 빌드하든지 개선할 필요가 없습니다.
설정
PAM의 또 다른 중요한 점은 다중 모듈 연동을 지원한다는 점입니다. 이름 없는 서비스용 PAM 설정 파일을 살펴보도록 하겠습니다:
/etc/pam.d/someservice"someservice" 서비스용 PAM 설정 파일 예제# Authentication
auth required pam_env.so
auth required pam_ldap.so
# Account management
account required pam_ldap.so
# Password management
password required pam_ldap.so
# Session management
session optional pam_loginuid.so
session required pam_selinux.so close
session required pam_env.so
session required pam_log.so level=audit
session required pam_selinux.so open multiple
session optional pam_mail.so
설정 파일은 인증, 계정 관리, 암호 관리, 세션 관리, 네 가지의 PAM 지원 서비스 도메인으로 구성했음을 보고 있습니다.
설정 파일의 각 부분에서는 하나 이상의 PAM 모듈을 호출합니다. 예를 들어 pam_env.so 는 각 모듈에서 사용할 수 있는 환경 변수를 설정합니다. 제어 지시문(위 예제에서는 필요하거나 선택)과 함께 있는 PAM 모듈에서는 반환 코드를 제공한 후 어떻게 처리할지 PAM이 결정하도록합니다.
제어 지시문
PAM은 다음 제어 지시문을 지원합니다.
| 제어문 | 설명 |
|---|---|
required
|
제공한 PAM 모듈은 전체 서비스(인증)를 제대로 처리하려면 반드시 성공처리해야 합니다. PAM 모듈 동작에 실패하면, (서비스 자체를 거부하더라도)다른 PAM 모듈을 여전히 호출합니다 . |
requisite
|
제공한 PAM 모듈은 전체 서비스를 제대로 처리 하려면 반드시 성공처리해야 합니다. required와는 달리, PAM 모듈 동작에 실패하면, 제어권을 되돌리며, 서비스 자체에서 거절합니다. |
sufficient
|
제공한 PAM 모듈 처리에 성공하면, 전체 서비스 접근을 허용합니다. 나머지 PAM 모듈은 검사하지 않습니다. 그럼에도 불구하고 PAM 모듈 처리에 실패하면 나머지 PAM 모듈을 처리하며, 처리에 실패한 PAM 일부 모듈은 무시합니다. |
optional
|
PAM 모듈 일부의 성공/실패 처리여부는 모듈을 스택에 올렸을 때만 중요합니다. |
| required
| The provided PAM module must succeed in order for the entire service (such as authentication) to succeed. If a PAM module fails, other PAM modules are still called upon (even though it is already certain that the service itself will be denied).
|-
| requisite
| The provided PAM module must succeed in order for the entire service to succeed. Unlike required, if the PAM module fails, control is immediately handed back and the service itself is denied.
|-
| sufficient
| If the provided PAM module succeeds, then the entire service is granted. The remainder of the PAM modules is not checked. If however the PAM module fails, then the remainder of the PAM modules is handled and the failure of this particular PAM module is ignored.
|-
| optional
| The success or failure of this particular PAM module is only important if it is the only module in the stack.
|-
| include
| Includes the contents of another PAM module's configuration file which matches the given type.
|-
|}
다중 인증을 처리하는 모듈을 엮으면, 세션을 만드는 그 외의 과정을 진행하는 동안에도 여러 작업을 처리할 수 있습니다.
PAM 설정 파일 관리
프로그램에서 PAM 설정 파일로 인증 단계를 다룰 때 설정 파일을 조심스럽게 다루는 것이 상당히 중요합니다. 보통 설정 파일은 /etc/pam.d/ 디렉터리에 있습니다.
대기업체나, 보안에 민감한 시스템에서는 PAM 설정 파일 수정을 적절하게 감독해야 합니다.
설정은 PAM 모듈 자체가 들어가는 위치(/lib/security 또는 /lib64/security)에 동일하게 넣습니다.
PAM과 젠투
조건에 따라 PAM을 지원할 수 있는 프로그램은 pam USE 플래그를 사용합니다. 젠투 시스템이 PAM 없이(USE="-pam" 설정) 동작할 수 있지만, 기본적으로는 PAM 지원 기능이 있는 상태로 시스템이 동작합니다.
When upgrading remote systems it is possible to leave the system inaccessible. To avoid this after an upgrade while being still logged in to the machine:
- check that logging is up and running
- check necessary configuration updates in /etc/ssh and /etc/pam.d
- check news items whether breaking changes were introduced, e.g. PAM related news Item
- check that changing passwords works flawlessly, e.g. passwd for root/ any user and cancel before actually changing the password
- restart SSH server in case it got updated
- check that a new login to the remote machine works
What could happen:
- without logging errors during the checks cannot be analyzed
- passwd errors out because of PAM module errors
- SSH prohibits login because of PAM misconfiguration/ module errors, e.g. plain connection closed
- password policies changed, e.g. prohibiting root without password
Example of how to parse system configuration
In this forum post in 2021 given by GDH-gentoo, the configuration of a system is tracked down step-by-step, in order to find which service creates the directory /run/user/<uid> on a user login.
추가 참조
- PAM (보안 핸드북)
- SSH 공개키 기반 인증을 처리하는 개별 PAM 모듈의 설치 및 설정 방법을 설명하는 PAM ssh agent moduleen 게시글
- 구글 인증 프로그램을 PAM으로 인증할 때 설치 및 설정 방법을 설명하는 Google authenticatoren 게시글
외부 자료
- 젠투 개발자 설명서에 있는 PAM 다루기 부분