로컬 사용자 vs. 중앙 집중식 인증: 올바른 Linux 설정 선택하기

Linux 인증은 작은 문제에서 시작됩니다. 서버 한 대, 관리자 한 명, 로컬 계정 하나. 그러면 두 번째 서버가 나타납니다. 그러면 계약자가 임시 액세스가 필요합니다. 그러면 누군가 회사를 떠납니다. 그 시점에서 질문은 더 이상 "useradd로 사용자를 추가할 수 있나요?"가 아닙니다. 질문은 누가 액세스 권한이 있는지 증명할 수 있는지, 액세스 권한을 신속하게 제거할 수 있는지, 여러 시스템에서 권한을 일관되게 유지할 수 있는지입니다.

로컬 사용자와 중앙 집중식 인증 모두 나름의 위치가 있습니다. 로컬 계정은 격리된 시스템에 대해 간단하고 안정적입니다. LDAP, Active Directory, FreeIPA 또는 유사한 디렉터리 서비스를 통한 중앙 집중식 인증은 일반적으로 Linux 서버가 공유 인프라가 되면 더 적합합니다.

로컬 인증 이해하기 (`/etc/passwd` 모델)

로컬 사용자 관리는 독립형 Linux 시스템에서 사용자 계정을 처리하는 기본적이면서 가장 간단한 방법입니다. 모든 사용자 및 그룹 정보는 로컬 파일 시스템에 직접 저장됩니다.

로컬 인증 작동 방식

사용자 자격 증명, 사용자 ID(UID), 그룹 ID(GID), 홈 디렉터리 및 기본 셸은 특정 시스템 파일 내에서 관리됩니다.

/etc/passwd: 사용자 이름, UID, 기본 GID, 홈 디렉터리 및 셸과 같은 사용자 계정 정보를 저장합니다. 최신 시스템에서는 일반적으로 비밀번호 해시를 저장하지 않습니다.
/etc/shadow: 암호화된 비밀번호 해시와 비밀번호 에이징 정보를 저장합니다(이 파일은 루트만 읽을 수 있습니다).
/etc/group: 그룹 정보를 저장합니다.

로컬 인증의 장점

단순성 및 속도: 한두 대의 시스템에 대해 설정하기가 매우 쉽습니다. useradd와 같은 도구를 사용하거나 파일을 수동으로 편집하여 사용자를 추가하는 것은 간단합니다(도구 사용이 선호됨).
오프라인 가용성: 네트워크가 다운되거나 중앙 인증 서버에 연결할 수 없는 경우에도 사용자가 로그인할 수 있습니다.
외부 종속성 없음: 추가 인프라, 전용 서버 또는 복잡한 네트워크 구성이 필요하지 않습니다.

로컬 인증의 단점

확장성 문제: 수십 또는 수백 대의 서버가 있는 환경에서는 일관성을 유지하는 것이 어려워집니다. 사용자가 20대의 서버에 액세스해야 하는 경우 프로세스를 자동화하지 않으면 20개의 계정이 필요할 수 있습니다.
보안 위험: 액세스 권한을 취소하려면 영향을 받는 모든 시스템에 개별적으로 로그인해야 합니다. 서버 하나를 잊어버리면 승인되지 않은 계정이 활성 상태로 남게 됩니다.
UID/GID 불일치: 여러 시스템에서 UID를 수동으로 관리하면 종종 충돌이 발생하여 파일 시스템(예: NFS)을 공유할 때 권한 문제가 발생합니다.

UID 문제는 과소평가하기 쉽습니다. Linux 파일 소유권은 이름이 아닌 숫자 ID로 저장됩니다. 한 서버에서 alice의 UID가 1001이고 다른 서버에서 bob의 UID가 1001인 경우 공유 스토리지에서 보는 위치에 따라 파일이 잘못된 사람 소유로 표시될 수 있습니다. 이것은 실험실에서는 성가시고 프로덕션에서는 위험합니다.

실제 예: 로컬 사용자 추가

로컬로 analyst1이라는 새 사용자를 추가하려면:

sudo useradd -m -s /bin/bash analyst1
sudo passwd analyst1
# 메시지가 표시되면 비밀번호 설정

중앙 집중식 인증 이해하기

중앙 집중식 인증은 사용자 신원을 확인하는 책임을 전용 네트워크 액세스 가능 서비스에 위임합니다. 사용자가 Linux 시스템에 로그인을 시도하면 해당 시스템은 확인을 위해 중앙 디렉터리 서버를 쿼리합니다.

주요 중앙 집중식 기술

Linux 환경의 중앙 집중식 인증 분야를 지배하는 두 가지 주요 기술이 있습니다.

LDAP(Lightweight Directory Access Protocol): OpenLDAP, 389 Directory Server 또는 더 큰 ID 플랫폼의 일부로 구현되는 디렉터리 액세스 프로토콜입니다. 유연하지만, 원시 LDAP 환경은 신중한 스키마, TLS, 복제 및 액세스 제어 설계가 필요합니다.
Active Directory(AD): Microsoft의 디렉터리 서비스입니다. Linux 시스템은 일반적으로 인증을 위해 Kerberos를, ID 조회 및 그룹 매핑을 위해 SSSD 또는 Winbind를 사용하여 AD와 통합합니다.
FreeIPA/IdM: LDAP, Kerberos, DNS, 인증서 및 정책 관리를 결합한 Linux 중심 ID 플랫폼입니다. 환경이 대부분 Linux이고 이미 AD에 의존하지 않는 경우 고려할 가치가 있습니다.

중앙 집중식 인증의 장점

단일 정보 소스: 사용자 생성, 수정 및 삭제가 한 곳에서 이루어져 연결된 모든 시스템에서 즉각적인 일관성을 보장합니다.
확장성: 수동으로 관리되는 로컬 계정보다 훨씬 더 잘 확장됩니다. 여전히 운영 작업이 필요하지만 사용자 수명 주기 관리는 중앙에서 이루어집니다.
향상된 보안 및 규정 준수: 캐시 설정 및 서비스 동작에 따라 액세스 권한 취소가 한 곳에서 광범위하게 적용될 수 있습니다. 중앙 집중식 시스템은 MFA, 비밀번호 정책, 그룹 기반 액세스 및 감사 프로세스와 더 자연스럽게 통합됩니다.
UID/GID 일관성: 중앙 집중식 시스템은 POSIX 속성(UID, GID, 홈 디렉터리)을 중앙에서 관리하여 공유 스토리지를 사용할 때 충돌을 제거합니다.

중앙 집중식 인증의 단점

네트워크 종속성: 디렉터리 서버 또는 네트워크 연결이 실패하면 중앙 집중식 자격 증명에만 의존하는 사용자는 로그인하지 못할 수 있습니다(SSSD 참조, 캐싱으로 완화됨).
복잡성: 초기 설정에는 전용 인프라, 네트워크 구성 및 특수 클라이언트 소프트웨어(예: SSSD 또는 Kerberos 라이브러리)가 필요합니다.
초기 비용: LDAP는 오픈 소스일 수 있지만 강력한 AD 환경을 설정하고 유지 관리하려면 라이선스 및 전문 지식이 필요합니다.

올바른 전략 선택: 환경 규모 및 요구 사항

최적의 선택은 조직의 규모, 복잡성 및 보안 요구 사항에 크게 좌우됩니다.

기능	로컬 인증 (`/etc/passwd`)	중앙 집중식 인증 (LDAP/AD)
환경 규모	소수의 독립형 시스템	공유 플릿, 팀 또는 엔터프라이즈 환경
관리 오버헤드	높음 (서버별 유지 관리)	낮음 (단일 제어 지점)
보안 정책 시행	일관성 유지 어려움	우수 (전역 정책)
오프라인 액세스	우수	캐싱 필요 (예: SSSD)
초기 설정 난이도	매우 낮음	높음

로컬 인증을 사용해야 하는 경우

로컬 인증은 다음에 이상적입니다.

소규모 실험실 또는 개인 워크스테이션: 신뢰할 수 있는 한두 명의 개인만 액세스해야 하는 환경.
격리된 시스템: 디렉터리 서버에 대한 네트워크 연결이 불가능하거나 바람직하지 않은 에어갭 시스템 또는 IoT 장치.
임시 배스천 호스트: 전체 디렉터리 통합 스택을 배포하는 것이 과도한 단기간 사용되는 시스템.

중앙 집중식 인증을 구현해야 하는 경우

중앙 집중식 인증은 일반적으로 다음에 더 나은 선택입니다.

기업 환경: 사용자가 여러 서버, 네트워크 공유 또는 서비스에 액세스해야 하는 모든 환경.
규정 준수 요구 사항: 일관된 액세스 제어 및 감사 추적을 요구하는 감사 또는 엄격한 규정 준수 대상 환경.
대규모 배포: 온보딩 및 오프보딩이 빠르고 반복 가능하며 감사 가능해야 하는 경우.

모든 사람에게 답이 바뀌는 마법의 서버 수는 없습니다. 실험실에서 관리자 한 명이 있는 서버 5대는 로컬 사용자로도 충분할 수 있습니다. 규제된 데이터를 보유한 프로덕션 서버 3대는 즉시 중앙 집중식 제어가 필요할 수 있습니다. 동기는 규모뿐만 아니라 위험, 이직률, 규정 준수, 공유 스토리지 및 액세스 변경 빈도입니다.

중앙 집중식 인증 구현: 주요 도구

AD, LDAP 또는 FreeIPA와 통합하는 많은 최신 Linux 시스템의 경우 sssd(시스템 보안 서비스 데몬)가 일반적인 클라이언트입니다. nss_ldap 및 pam_ldap과 같은 이전 도구는 일부 환경에 여전히 존재하지만 SSSD는 일반적으로 캐싱 및 공급자 통합에 더 나은 기본값입니다.

SSSD의 역할

SSSD는 로컬 시스템 서비스와 원격 디렉터리 공급자(LDAP 또는 AD) 간의 브리지 역할을 합니다. 주요 기능은 다음과 같습니다.

캐싱: SSSD는 인증 데이터를 로컬에 캐시합니다. 디렉터리 서버에 대한 연결이 끊어지면 최근에 로그인한 사용자는 구성된 기간 동안 로컬로 계속 인증할 수 있어 오프라인 액세스 단점을 해결합니다.
PAM/NSS 통합: PAM(Pluggable Authentication Modules) 및 NSS(Name Service Switch)와 원활하게 통합되어 표준 Linux 명령(login, ssh)이 원격 계정에서 투명하게 작동하도록 합니다.

실제 예: SSSD 구성 스니펫(개념)

Active Directory와 통합하려면 종종 realm 또는 adcli와 같은 도구를 사용하여 도메인에 가입한 다음 SSSD가 ID 및 인증을 처리하도록 하는 작업이 포함됩니다. 실제 구성은 도메인 정책, DNS, TLS, 액세스 규칙 및 배포 기본값에 따라 다릅니다. 이 단순화된 스니펫은 일반적인 형태만 보여줍니다.

# AD 통합을 위한 /etc/sssd/sssd.conf 스니펫
[domain/example.com]
cache_credentials = True
ldap_search_base = dc=example,dc=com

[sssd]
services = nss, pam
domains = example.com

작은 스니펫을 프로덕션에 복사하여 완전하다고 기대하지 마십시오. SSSD는 /etc/sssd/sssd.conf에 대한 올바른 파일 권한, 작동하는 DNS, Kerberos를 위한 시간 동기화 및 공급자별 설정이 필요합니다. 플릿 전체에 배포하기 전에 관리자가 아닌 계정으로 로그인을 테스트하십시오.

하이브리드 설정은 일반적입니다.

중앙 집중식 인증이 표준인 경우에도 대부분의 Linux 시스템은 여전히 몇 개의 로컬 계정을 유지합니다. 루트 계정이 존재합니다. 클라우드 이미지에는 로컬 부트스트랩 사용자가 있을 수 있습니다. ID 공급자에 연결할 수 없는 비상 상황을 위해 비상 계정이 필요할 수 있습니다.

괜찮지만 로컬 예외에는 규율이 필요합니다.

로컬 인간 계정 수를 적게 유지하십시오.
적절한 경우 SSH 키 또는 잠긴 비밀번호를 사용하십시오.
로컬 계정을 정기적으로 감사하십시오.
비상 사용을 문서화하고 사용 후 자격 증명을 교체하십시오.
모든 관리자에게 모든 서버에 별도의 관리되지 않는 로컬 계정을 제공하지 마십시오.

일반적인 패턴은 일반 관리를 위한 중앙 집중식 로그인, 디렉터리 그룹을 기반으로 하는 sudo 규칙 및 엄격하게 제어되는 하나의 비상 경로입니다. 이렇게 하면 ID 중단 중에도 복구를 불가능하게 만들지 않으면서 일상적인 감사 가능성을 얻을 수 있습니다.

성공을 결정하는 운영 세부 사항

중앙 집중식 인증은 DNS, 시간, 인증서 및 캐싱과 같은 지루한 이유로 가장 자주 실패합니다.

Kerberos는 시간 차이에 민감합니다. 서버 시계가 표류하면 비밀번호가 정확하더라도 로그인이 실패할 수 있습니다. NTP 또는 chrony를 사용하고 모니터링하십시오.

디렉터리 조회는 DNS에 따라 다릅니다. Linux 클라이언트가 도메인 컨트롤러 또는 LDAP 서버를 안정적으로 찾을 수 없으면 인증이 불안정하게 느껴질 수 있습니다. 단일 서버를 하드코딩하면 유지 관리 날짜까지 작동할 수 있습니다. 디렉터리 서비스에 권장되는 검색 메커니즘을 사용하십시오.

LDAP의 경우 TLS가 중요합니다. 적절한 전송 보안 없이 자격 증명 또는 디렉터리 데이터를 보내는 것은 특히 완전히 제어할 수 없는 네트워크를 통과하는 경우 나쁜 습관입니다. "그냥 작동하게" 하기 위해 검사를 비활성화하는 대신 인증서의 유효성을 검사하십시오.

캐싱에는 의식적인 정책이 필요합니다. SSSD는 최근에 인증된 사용자가 중단 중에도 로그인할 수 있도록 허용할 수 있으며 이는 유용합니다. 그러나 캐시 수명이 길면 취소가 지연될 수 있습니다. 캐시 수명이 짧으면 제어 기능이 향상되지만 중단이 더 고통스러워집니다. 환경의 위험에 따라 선택하십시오.

사용자 관리 모범 사례

선택한 경로에 관계없이 다음 모범 사례를 준수하십시오.

루트 사용 피하기: 일상적인 관리 작업에 로컬 루트 계정을 사용하지 마십시오. 중앙 집중식 계정과 sudo 메커니즘을 활용하십시오.
정기적인 감사: 로컬 계정을 사용하는 경우 승인되지 않았거나 오래된 항목이 있는지 /etc/passwd 및 /etc/shadow를 정기적으로 감사하십시오.
최소 권한 원칙: 사용자에게 역할에 필요한 최소 권한만 부여되도록 하십시오. 중앙 집중식 시스템은 그룹 멤버십을 통해 이를 더 쉽게 시행할 수 있습니다.
UID 표준화: 로컬 계정을 중앙 집중식 계정과 함께 사용해야 하는 경우 로컬 UID가 디렉터리 사용자에 사용되는 범위와 겹치지 않도록 하십시오. 정확한 범위는 배포 및 ID 설정에 따라 다르므로 로컬 규칙을 문서화하십시오.

마이그레이션 조언

로컬 사용자에서 중앙 집중식 인증으로 이동하는 경우 모든 서버를 한 번에 전환하지 마십시오. 중요하지 않은 호스트부터 시작하십시오. id username으로 사용자가 확인되는지, 그룹이 올바르게 나타나는지, sudo 규칙이 작동하는지, SSH 로그인이 예상대로 작동하는지, 캐시된 로그인이 정책에 따라 작동하는지 확인하십시오.

그런 다음 파일 소유권을 처리하십시오. 로컬 UID가 디렉터리 UID와 다른 경우 파일 소유권을 변경해야 할 수 있습니다. 공유 홈 디렉터리 및 NFS 마운트는 특별한 주의가 필요합니다. 대량 chown 변경을 수행하기 전에 백업하고 실제 사용자 워크플로로 테스트하십시오.

마지막으로 디렉터리 경로가 작동한 후 오래된 로컬 계정을 제거하거나 잠그십시오. 두 시스템을 영원히 활성 상태로 두면 얻으려는 많은 보안 이점이 사라질 수 있습니다.

최종 확인

로컬 사용자는 시스템이 진정으로 독립적이고 액세스가 거의 변경되지 않으며 영향 범위가 작은 경우에 가장 좋습니다. 중앙 집중식 인증은 사람, 서버 및 권한이 수동 계정 관리를 위험하게 만들 정도로 자주 변경될 때 더 좋습니다. 로컬 비상 액세스를 유지하지만 일반 경로는 중앙 집중식, 감사 가능 및 그룹 기반으로 만드십시오. 이것이 대부분의 팀이 누가 어디에 로그인할 수 있는지 놓치지 않고 운영할 수 있는 설정입니다.