SELinux 대 AppArmor: 어떤 MAC 프레임워크가 귀하의 서버에 적합할까요?

SELinux와 AppArmor는 모두 리눅스에서 강제 접근 제어(MAC)를 적용하여, 프로세스가 루트 권한을 획득하더라도 수행할 수 있는 작업을 제한합니다. 차이점은 이를 구현하는 방식에 있습니다. SELinux는 모든 파일과 프로세스에 영구적인 레이블을 할당하는 반면, AppArmor는 파일 경로 규칙을 사용합니다. 이러한 하나의 설계 선택이 복잡성, 보안 수준, 그리고 어떤 배포판이 어떤 도구를 기본으로 제공하는지 등 모든 것을 결정합니다.

SELinux의 작동 원리

SELinux는 원래 NSA에서 개발되었으며, RHEL, CentOS, Fedora 및 Rocky Linux에 기본으로 탑재되어 있습니다. 이 시스템은 파일, 프로세스, 포트, 소켓을 포함한 시스템 내 모든 객체에 다음과 같은 형식의 보안 컨텍스트를 할당합니다 user:role:type:level의 형식으로 라벨을 부여합니다. type 필드는 Type Enforcement(TE)라는 메커니즘을 통해 대부분의 핵심 기능을 수행합니다.

예를 들어, Apache 웹 서버는 httpd_t로 실행됩니다. 웹 콘텐츠 파일은 다른 유형을 가집니다. 정책 규칙에서 명시적으로 httpd_t 해당 콘텐츠 유형에 대한 접근을 명시적으로 허용하는 정책 규칙이 없으면 요청이 거부됩니다. 이는 '기본 거부(deny-by-default)' 모델입니다. 규칙에 달리 명시되지 않는 한 어떤 것도 허용되지 않습니다.

SELinux는 또한 데이터를 민감도 수준에 따라 분류하고 그에 따라 접근을 제한하는 다단계 보안(MLS) 및 다범주 보안(MCS)을 지원합니다. MCS는 SELinux에 강력한 컨테이너 격리 기능을 제공하여, 컨테이너들이 서로 및 호스트와 분리되도록 유지합니다. 이는 포드들이 노드를 공유하는 쿠버네티스(Kubernetes) 및 오픈시프트(OpenShift) 환경에서 중요합니다.

대가는 복잡성입니다. SELinux는 학습 곡선이 가파릅니다. 접근 거부 문제를 해결하려면 감사 로그를 읽고, 보안 컨텍스트를 이해하며, 때로는 audit2allow. 전담 보안 인력이 없는 팀에게는 이러한 부하가 실질적인 부담이 됩니다.

AppArmor의 작동 원리

AppArmor는 다른 접근 방식을 취합니다. 객체에 레이블을 붙이는 대신, 파일 경로를 기반으로 애플리케이션에 보안 프로필을 적용합니다. /usr/sbin/nginx Nginx가 읽을 수 있는 디렉터리, 바인딩할 수 있는 포트, 필요한 기능을 정의합니다. 프로필은 /etc/apparmor.d/.

AppArmor는 Ubuntu, Debian 및 SUSE의 기본 MAC 프레임워크입니다. 이 프레임워크는 버전 2.6.36부터 리눅스 커널의 일부로 포함되어 있습니다. 프로필이 없는 애플리케이션은 표준 리눅스 DAC 권한으로 대체됩니다.

AppArmor는 프로필당 두 가지 모드(Enforce: 위반 사항 차단 및 기록, Complain: 차단 없이 위반 사항 기록)로 실행됩니다. 이를 통해 새로운 프로필을 점진적으로 적용하는 것이 가능합니다. Complain 모드로 시작하여 로그를 검토하고, 프로필을 강화한 후 Enforce 모드로 전환하십시오.

다음과 같은 도구들 aa-genprof 및 aa-logprof 와 같은 도구는 애플리케이션의 동작을 관찰하고 그 행동 패턴을 바탕으로 규칙을 생성하여 프로필을 대화식으로 구축하는 데 도움을 줍니다. SELinux 정책 모듈과 비교할 때, 구문은 훨씬 읽기 쉽고 수동으로 편집하기도 편리합니다.

단점은 경로 기반 규칙이 파일 이동 시 이를 따라가지 못한다는 점입니다. 이론적으로 하드 링크나 바인드 마운트를 사용하면 경로 기반 제한을 우회할 수 있습니다. 또한 AppArmor는 네이티브 MLS/MCS 지원을 제공하지 않으므로, SELinux와 달리 컨테이너를 호스트로부터는 격리할 수 있지만 컨테이너끼리 서로를 격리할 수는 없습니다.

나란히 비교

기본 구성

SELinux

현재 상태 확인:

sestatus
getenforce

아무것도 차단하지 않고 위반 사항을 기록하려면 Permissive 모드로 시작하십시오:

setenforce 0

대부분의 서버에는 "targeted" 정책을 사용하십시오. 이 정책은 웹 서버나 데이터베이스와 같은 고위험 서비스는 제한하는 반면, 그 외의 모든 것은 제한 없이 허용합니다. 다음에서 영구적으로 설정하십시오 /etc/selinux/config:

SELINUX=enforcing
SELINUXTYPE=targeted

파일 및 프로세스의 보안 컨텍스트 확인:

ls -Z /var/www/html
ps -eZ | grep httpd

서비스가 비표준 포트를 사용하는 경우 정책을 업데이트하십시오:

semanage port -a -t ssh_port_t -p tcp 9999

액세스 거부 오류가 발생하는 사용자 정의 애플리케이션의 경우, 감사 로그를 기반으로 정책 모듈을 생성하십시오:

ausearch -m avc -ts recent | audit2allow -M my_custom_policy
semodule -i my_custom_policy.pp

AppArmor

로드된 프로필을 확인하십시오:

sudo aa-status

프로필 관리 도구가 필요한 경우 유틸리티 패키지를 설치하십시오:

sudo apt install apparmor-utils

애플리케이션이 실행되는 동안 대화형으로 프로필을 생성하십시오:

sudo aa-genprof /path/to/binary

위반 사항을 찾기 위해 로그를 스캔하여 프로필을 조정하십시오:

sudo aa-logprof

프로필의 모드를 전환합니다:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

어떤 것을 사용해야 할까요?

대부분의 관리자에게 실용적인 답변은 배포판에 기본으로 포함된 것을 사용하라는 것입니다. RHEL, CentOS, Fedora, Rocky Linux에는 SELinux가 포함되어 있습니다. Ubuntu, Debian, SUSE에는 AppArmor가 포함되어 있습니다. 두 프레임워크 모두 해당 네이티브 플랫폼을 위한 성숙한 도구와 정책을 갖추고 있습니다. 어떤 배포판에서든 기본이 아닌 옵션으로 전환하면 작업량이 늘어나고 커뮤니티 지원이 줄어듭니다.

그 외에는 요구 사항에 따라 결정하십시오:

• PCI DSS, HIPAA 또는 DISA-STIG 준수가 필요한 경우 SELinux를 선택하세요. Kubernetes나 OpenShift에서 멀티테넌트 컨테이너 워크로드를 실행하는 경우. 공유 호스트에서 컨테이너 간 격리가 필요한 경우. 환경에서 기밀 또는 민감도 등급이 지정된 데이터를 처리하는 경우.
• Ubuntu나 Debian을 사용 중이며, 복잡한 설정 과정 없이 MAC(Mandatory Access Control) 보호 기능을 원한다면 AppArmor를 선택하십시오. 표준 웹 서비스를 실행하는 단일 서버나 소규모 클러스터 환경인 경우. 세분화된 레이블 수준 제어보다 빠른 배포가 더 중요한 경우.

두 프레임워크 모두 런타임 오버헤드가 최소화됩니다. SELinux는 액세스 결정 사항을 액세스 벡터 캐시(Access Vector Cache)에 저장합니다. AppArmor의 정책 로딩은 부팅 시 약간의 지연을 유발할 수 있으나, 런타임에는 미미한 영향만 미칩니다. 대부분의 호스팅 워크로드에서 이 두 가지 모두 병목 현상이 되지 않을 것입니다.

두 프레임워크 중 하나를 구성하기 위해 완전한 루트 권한이 필요한 안정적인 호스팅 기반이 필요하다면, FDC의 전용 서버나 VPS를 통해 환경에 필요한 방식으로 SELinux 또는 AppArmor를 설정할 수 있는 제어권을 확보할 수 있습니다.