지난 회차에서 우리는 리눅스 보안의 기초 체력이 되는 전통적 권한 제어 방식인 임의 접근 제어(DAC)와 chmod, chown 명령어의 활용법을 다루었습니다. 소유자(User), 소유 그룹(Group), 나머지 제3자(Others)라는 세 가지 단위로 권한을 쪼개어 관리하는 이 전통적인 방식은 단순하고 명확하여 서버의 기초 방어벽을 세우는 데 매우 유용합니다.
하지만 현대의 복잡한 기업 인프라 운영 환경이나 다차원적인 개발 협업 환경에서는 전통적인 방식만으로 해결할 수 없는 치명적인 한계에 직면하게 됩니다.
예를 들어, 어떤 중요 프로젝트 디렉토리에 대해 소유자는 root이고 소유 그룹은 개발팀(dev_group)으로 지정되어 있다고 가정해 보겠습니다. 이때 기획팀의 김 대리(kim_pm)에게만 이 디렉토리의 '읽기' 권한을 추가로 부여해야 하는 상황이 발생했습니다.
전통적인 방식으로는 김 대리를 개발팀 그룹에 강제로 가입시키거나(개발팀의 다른 쓰기 권한까지 모두 노출되는 보안 위협 발생), 나머지 사용자(Others) 전체에게 읽기 권한을 열어주어야 합니다(시스템의 모든 일반 계정에 데이터가 노출되는 치명적인 보안 사고 발생).
이처럼 "제3의 특정 사용자나 특정 그룹에게만 독립적인 권한을 정교하게 부여하고 싶다"는 실무적 요구사항을 완벽하게 해결해 주는 구원투수가 바로 ACL(접근 제어 목록, Access Control List)입니다. 이번 6회차에서는 전통적 권한 제어의 한계를 뛰어넘는 복합 협업의 방패, ACL의 메커니즘과 getfacl, setfacl 명령어를 활용한 실무 제어 기법을 상세히 알아보겠습니다.
리눅스 ACL은 파일 시스템 수준에서 개별 파일이나 디렉토리에 대해 표준 권한 구조를 확장하여, 여러 명의 독립된 사용자나 복수의 그룹에 대해 각기 다른 권한을 맵핑할 수 있도록 지원하는 고차원 권한 관리 시스템입니다. RHEL, Rocky Linux, Ubuntu 등 현대 리눅스 배포판의 기본 파일 시스템(XFS, ext4)은 대개 이 ACL 기능을 기본적으로 활성화하여 제공합니다.
어떤 파일에 ACL 보안 정책이 주입되어 있는지는 ls -l 명령어의 권한 문자열 끝자락을 보면 쉽게 알 수 있습니다.
Bash
ls -l sample.txt
# 출력 예시 (ACL 미적용): -rw-r--r--. 1 root root 0 Jun 17 09:00 sample.txt
# 출력 예시 (ACL 적용): -rw-r--r--+ 1 root root 0 Jun 17 09:00 sample.txt
권한 표시의 가장 마지막 자리에 마침표(.) 대신 플러스(+) 기호가 붙어 있다면, 이 파일에는 전통적 권한 외에 숨겨진 복합 ACL 정책이 작동하고 있다는 뜻입니다.
전통적인 ls -l 명령어는 ACL이 적용되었음을 가리키는 + 기호만 보여줄 뿐, 구체적으로 어떤 사용자가 어떤 권한을 받았는지는 인쇄하지 못합니다. 이때 파일의 상세한 ACL 설정 지도를 시각화해 주는 명령어가 바로 getfacl(Get File ACL)입니다.
Bash
getfacl sample.txt
이 명령어를 실행하면 다음과 같은 정형화된 메타데이터 덤프가 출력됩니다.
Plaintext
# file: sample.txt
# owner: root
# group: root
user::rw-
user:kim_pm:r--
group::r--
mask::r--
other::r--
# file:, # owner:, # group:: 파일의 이름과 전통적인 소유자, 소유 그룹을 나타냅니다.
user::rw-: 전통적인 파일 소유자 본인의 권한입니다. (chmod로 수정하는 user 권한과 동기화됩니다.)
user:kim_pm:r--: ACL의 핵심 지점입니다. 특정 계정인 kim_pm에게 독립적으로 부여된 읽기(r) 권한을 명시하고 있습니다.
group::r--: 전통적인 소유 그룹의 권한입니다.
mask::r--: 이 파일이 가질 수 있는 최대 권한의 한계선(Mask)입니다. 아무리 특정 사용자에게 rwx를 주었더라도 마스크 값이 r--이면 최종 권한은 읽기로 제한됩니다.
other::r--: 소유자도 아니고, 소유 그룹도 아니며, 특별히 명시된 ACL 계정도 아닌 일반 제3자에게 적용되는 권한입니다.
setfacl(Set File ACL) 명령어는 파일이나 디렉토리에 새로운 ACL 규칙을 추가, 수정, 또는 삭제하는 칼 역할을 합니다. 실무에서 가장 빈번하게 발생하는 시나리오를 바탕으로 세부 옵션과 제어 기법을 마스터해 보겠습니다.
-m (Modify): 새로운 ACL 규칙을 추가하거나 기존 규칙을 수정합니다.
-x (Remove): 특정 사용자나 그룹에 지정되었던 ACL 규칙만 콕 집어서 제거합니다.
-b (Remove all): 설정된 모든 확장 ACL 규칙을 파괴하고 전통적인 권한 구조(+ 제거 상태)로 회귀시킵니다.
-R (Recursive): 하위 디렉토리와 파일까지 규칙을 일괄 순회 적용합니다.
특정 사용자 권한 추가: u:[사용자명]:[권한] (예: u:kim_pm:rx)
특정 그룹 권한 추가: g:[그룹명]:[권한] (예: g:audit_team:r)
공동 개발 공간인 /var/www/project 디렉토리가 있습니다. 이 디렉토리의 주인은 root이고 그룹은 dev_team입니다. 외부 감사를 위해 파견된 보안 컨설턴트 계정 ciso_user에게 이 디렉토리와 하위 파일들을 수정하지는 못하되, 내부 소스코드 구조를 읽고 진입할 수 있는 권한(r-x)을 임시로 주입해야 합니다.
Bash
# 1. ciso_user에게 /var/www/project 디렉토리의 읽기 및 진입 권한을 재귀적으로(-R) 주입
setfacl -R -m u:ciso_user:rx /var/www/project
# 2. 주입된 결과 지도가 정상적으로 반영되었는지 검증
getfacl /var/www/project
# 출력 결과 중 user:ciso_user:r-x 항목이 정상 확인되면 완료됩니다.
프로젝트 공용 공유 폴더인 /share/docs 디렉토리가 있습니다. 마케팅팀(mkt_group) 구성원들이 이 디렉토리 내부에 앞으로 파일이나 폴더를 새로 생성할 때마다, 관리자가 개입하지 않아도 새로 태어나는 모든 하위 파일에 마케팅팀 구성원들의 읽기/쓰기 권한이 자동으로 상속되어 박히도록 세팅하고 싶습니다.
이때 사용하는 것이 바로 디렉토리 전용 특수 기능인 기본 ACL(Default ACL)입니다. 패턴 앞에 d: 접두사를 붙여 지정합니다.
Bash
# 1. /share/docs 디렉토리 자체에 마케팅 그룹의 권한 부여
setfacl -m g:mkt_group:rwx /share/docs
# 2. 앞으로 이 디렉토리 하위에 생성될 모든 미래의 파일들에 적용될 기본(Default) ACL 정책 주입
setfacl -m d:g:mkt_group:rwx /share/docs
# 3. 설정 상태 확인
getfacl /share/docs
# 출력 하단에 default:group:mkt_group:rwx 형태로 규칙이 박혀있는 것을 볼 수 있습니다.
이렇게 설정을 마치면, 이후 다른 사용자가 이 폴더 안에 어떤 텍스트 파일을 새로 만들더라도 그 파일에는 마케팅 그룹의 rw 권한이 자동으로 상속되므로 권한 오류 없는 완벽한 다중 협업 전용 공간이 완성됩니다.
감사 업무나 공동 프로젝트가 완전히 종료되어 외부 계정에게 주었던 특수 권한을 철저히 회수해야 하는 보안 정돈 단계입니다.
Bash
# 1. ciso_user 계정에게 주었던 ACL 규칙만 콕 집어서 파괴
setfacl -x u:ciso_user /var/www/project
# 2. 만약 복잡하게 꼬인 해당 디렉토리의 모든 확장 ACL을 지우고 깨끗한 전통적 구조로 돌리고 싶다면
setfacl -b /var/www/project
ACL을 실무에 적용할 때 가장 많은 트러블슈팅을 유발하는 요소가 바로 마스크(mask) 개념입니다.
마스크는 앞서 설명했듯이 파일 소유자와 일반 제3자(other)를 제외한, 확장 ACL 규칙을 가진 모든 사용자 및 그룹들이 가질 수 있는 최상위 권한의 천장(Limit)을 뜻합니다.
만약 관리자가 setfacl -m u:worker01:rwx shared.dat 명령어를 통해 worker01에게 실행 권한까지 완벽히 부여했더라도, 무심코 전통적인 명령어인 chmod 640 shared.dat를 실행하여 그룹 권한 대역을 좁혀버리면 시스템 내부적으로 마스크 값이 r--로 재조정됩니다.
이 경우 getfacl로 확인해 보면 다음과 같은 경고성 메시지가 출력됩니다.
Plaintext
user:worker01:rwx #effective:r--
mask::r--
#effective:r--라는 표시는 사용자가 원래 rwx 권한을 부여받았을지라도 마스크의 천장에 가로막혀 실제 작동하는 유효 권한(Effective Permission)은 읽기(r)뿐이라는 무서운 경고입니다. 따라서 ACL 기반의 협업 디렉토리를 제어할 때는 chmod 명령어를 혼용하여 마스크 값을 깨뜨리지 않도록 각별히 주의해야 하며, 권한 꼬임 현상이 발생하면 getfacl을 통해 유효 권한 레벨을 반드시 재확인해야 합니다.
리눅스 ACL은 복잡하고 다각화된 현대 인프라 협업 환경에서 정보의 기밀성을 유지하면서도 업무의 유연성을 보장하는 가장 정교한 방패입니다.
전통적인 권한 구조가 막다른 길에 다다랐을 때 getfacl로 숨겨진 권한 지도를 스캔하고,
setfacl -m을 통해 특정 계정과 그룹에만 핀포인트로 권한을 부여하며,
기본 ACL(d:u:[이름]:[권한]) 설정을 활용하여 자동으로 권한이 상속되는 완벽한 협업 공유 폴더를 빌드하고,
마스크(Mask)의 권한 제한 메커니즘을 명확히 이해하여 유효 권한 오류를 예방해야 합니다.
이 정교한 접근 제어 기술이 시스템 운영 체계에 자연스럽게 녹아들 때, 인프라의 권한 구조는 군더더기 없이 깔끔하게 정돈되며 보안 위협과 업무 비효율을 동시에 잡아내는 최고 수준의 인프라 아키텍처를 유지할 수 있습니다. 다음 7회차에서는 파일의 외형적 권한 통제를 넘어, 텍스트 스트림의 뼈대를 터미널 안에서 실시간으로 깎고 다듬는 '텍스트 스트림의 편집과 변환의 지존, awk와 sed' 명령어에 대해 자세히 알아보겠습니다.