[Linux 보안] SELinux vs AppArmor: 선택 가이드와 실전 비교

목차

• 1. 왜 SELinux와 AppArmor가 중요한가
• 2. SELinux와 AppArmor 개념 설명
• 2-1. SELinux는 라벨 기반입니다
• 2-2. AppArmor는 경로 기반입니다
• 3. SELinux와 AppArmor 비교: 무엇이 다른가
• 4. 실전 구현: SELinux 기본 확인과 적용
• 5. 실전 구현: AppArmor 기본 확인과 프로파일 적용
• 6. 어떤 환경에서 무엇을 선택할까
• 7. ⚠️ 주의사항과 트러블슈팅
• 7-1. 서비스가 안 되면 바로 비활성화하지 마세요
• 7-2. 파일 권한과 보안 정책을 혼동하지 마세요
• 7-3. 로그 없는 수정은 거의 실패합니다
• 8. 검증과 결과 확인
• 9. 정리와 FAQ
• 자주 묻는 질문

[Linux 보안] SELinux vs AppArmor: 선택 가이드와 실전 비교

리눅스 서버를 운영하다 보면 결국 한 번은 붙잡게 되는 주제가 있습니다. 바로 SELinux AppArmor 비교입니다. 방화벽만 잘 열고 닫는다고 끝나는 게 아니더라고요. 실제 운영 환경에서는 프로세스가 어디까지 접근할 수 있는지, 침해 사고가 났을 때 피해 범위를 얼마나 좁힐 수 있는지가 정말 중요합니다. 저도 홈랩에서 웹 서버, 컨테이너, 파일 공유 서비스를 이것저것 올려보면서 Linux 보안을 강화하려다가 SELinux(Security-Enhanced Linux)와 AppArmor(Application Armor)를 번갈아 만져봤습니다. 처음엔 둘 다 비슷해 보였는데, 직접 써보니까 운영 철학부터 관리 포인트까지 꽤 다르더라고요.

혹시 이런 경험 있으신가요? 서비스는 분명 정상인데 권한 거부 때문에 접속이 안 되고, 로그를 보면 더 헷갈리는 상황 말입니다. 저도 처음엔 이게 뭔가 싶었는데, 기준만 잡고 보면 선택이 꽤 쉬워집니다. 이번 글에서는 SELinux vs AppArmor를 비교하면서, 어떤 환경에서 무엇을 선택하면 좋은지 경험 기준으로 풀어보겠습니다.

SELinux와 AppArmor가 커널 보안 계층에서 어떻게 동작하는지 보여주는 개요 이미지입니다.

1. 왜 SELinux와 AppArmor가 중요한가

쉽게 말해 둘 다 MAC(Mandatory Access Control, 강제 접근 통제) 계열입니다. 일반적인 파일 권한처럼 사용자가 알아서 결정하는 DAC(Discretionary Access Control, 임의 접근 통제)보다 훨씬 강하게 제어하는 방식이거든요. 프로세스가 root 권한을 가졌다고 해도, 보안 정책이 막고 있으면 파일을 읽거나 네트워크 동작을 하지 못하게 되는 겁니다.

이게 왜 중요하냐면, 서비스 하나가 뚫렸을 때 전체 서버로 번지는 걸 줄여주기 때문이에요. 예를 들어 웹 서버 프로세스가 취약점으로 악용되더라도, 원래 접근하면 안 되는 디렉터리나 소켓을 막아두면 피해 확산을 줄일 수 있습니다. 제가 홈랩에서 리버스 프록시, 파일 서버, 테스트용 앱을 굴릴 때도 결국 마지막 안전장치 역할은 이런 보안 정책이 하더라고요. 평소엔 귀찮아 보여도, 문제 생기면 존재감이 정말 확실합니다.

2. SELinux와 AppArmor 개념 설명

2-1. SELinux는 라벨 기반입니다

SELinux는 객체와 프로세스에 보안 컨텍스트(context, 보안 문맥) 라벨을 붙여서 제어합니다. 파일, 포트, 프로세스가 각각 어떤 타입인지 보고 허용 여부를 판단하는 방식이죠. 처음엔 정말 어렵습니다. 저도 파일 권한만 보다가 갑자기 컨텍스트를 보라니까 삽질 좀 했어요. 그런데 익숙해지면 정책이 꽤 정교하고 체계적이더라고요.

• 파일과 디렉터리에 보안 라벨을 부여합니다.
• 프로세스도 특정 도메인(domain, 실행 문맥)으로 실행됩니다.
• 정책이 세밀해서 대규모 운영 환경에 잘 맞는 편입니다.

2-2. AppArmor는 경로 기반입니다

AppArmor는 파일 경로(path, 경로)를 기준으로 제어합니다. 그래서 사람이 읽고 이해하기가 상대적으로 훨씬 쉽습니다. 특정 실행 파일이 어느 경로를 읽고 쓸 수 있는지 프로파일(profile, 정책 파일)로 정의하는 방식이거든요. Ubuntu 계열에서 처음 보안 강화 기능을 접할 때 부담이 덜한 이유가 바로 여기에 있습니다.

• 실행 파일별 프로파일을 적용합니다.
• 경로 기반이라 정책을 읽기 쉽습니다.
• 처음 도입할 때 학습 곡선이 비교적 완만합니다.

3. SELinux와 AppArmor 비교: 무엇이 다른가

여기서 중요한 포인트! SELinux AppArmor 비교를 할 때 단순히 "누가 더 강한가"로 보면 답이 잘 안 나옵니다. 실제로는 운영 방식에 맞는지가 훨씬 더 중요하거든요.

항목	SELinux	AppArmor
정책 기준	라벨 기반	경로 기반
학습 난이도	상대적으로 높음	상대적으로 낮음
정책 세밀도	매우 세밀함	직관적이고 단순한 편
대표 사용 환경	RHEL 계열에서 자주 사용	Ubuntu 계열에서 자주 사용
초기 운영 체감	로그 분석이 중요	프로파일 관리가 중요
적합한 상황	엄격한 통제, 장기 운영	빠른 도입, 단순한 서비스 보호

제 경험상 정리하면 이렇습니다.

• SELinux: 처음엔 어렵지만, 표준화된 운영과 세밀한 정책이 필요한 환경에서 정말 강합니다.
• AppArmor: 빠르게 적용하고 이해하기 쉬워서 소규모 서비스나 초기 구축에 부담이 훨씬 적습니다.
• 보안 강도만 볼 게 아니라, 팀이 정책을 유지할 수 있는지가 더 중요한 선택 기준이 됩니다.

4. 실전 구현: SELinux 기본 확인과 적용

이제 실전으로 가보겠습니다. 제가 직접 해보니 무조건 정책부터 건드리기보다, 현재 상태를 먼저 보는 게 훨씬 낫습니다. SELinux는 특히 더 그렇습니다. 상태 확인 없이 파일만 만지면 나중에 왜 막혔는지 추적이 훨씬 어려워지거든요.

1. SELinux 상태를 확인합니다.
2. 서비스 파일 컨텍스트를 점검합니다.
3. 필요하면 적절한 컨텍스트를 다시 지정합니다.
4. 로그를 보고 실제 차단 원인을 확인합니다.

getenforce
seststatus
ls -Z /var/www
ps -eZ | grep httpd

getenforce는 현재 모드를 빠르게 보여줍니다. Enforcing이면 정책이 실제로 강제 적용 중이고, Permissive면 차단 대신 로그만 남깁니다. 처음 테스트할 땐 Permissive 모드에서 원인부터 보는 게 훨씬 편하더라고요.

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"  
sudo restorecon -Rv /srv/myweb

이 명령은 웹 서버 콘텐츠 디렉터리에 적절한 타입을 지정하는 예시입니다. 여기서 정말 중요한 건 chmod로 해결하려고 하지 말고 컨텍스트를 봐야 한다는 점이에요. 저도 예전에 권한은 맞는데 계속 403이 떠서 한참 헤맸는데, 알고 보니 파일 라벨이 안 맞았던 경우가 정말 많았거든요.

sudo ausearch -m avc -ts recent
sudo journalctl -t setroubleshoot --since today

SELinux는 로그를 보는 습관이 정말 핵심입니다. 거부 로그를 보면 무엇이 막혔는지 힌트를 얻을 수 있어요. 드디어 됐다! 하는 순간이 대부분 여기서 옵니다.

SELinux에서 컨텍스트를 확인하고 복구하는 흐름을 단계별로 보여주는 이미지입니다.

5. 실전 구현: AppArmor 기본 확인과 프로파일 적용

AppArmor는 상대적으로 진입 장벽이 훨씬 낮습니다. 실제로 써보니까 정책 파일이 사람이 읽기 쉬워서, 빠르게 감을 잡기 정말 좋더라고요. 특히 단일 서비스 보호 용도로는 꽤 편했습니다.

1. AppArmor가 활성화되어 있는지 확인합니다.
2. 현재 로드된 프로파일과 적용 상태를 봅니다.
3. 필요한 프로파일을 enforce 모드로 전환합니다.
4. 로그를 보고 누락된 권한을 보완합니다.

sudo aa-status
sudo apparmor_status

배포판에 따라 둘 중 하나를 쓰게 되는 경우가 있습니다. 출력에서 어떤 프로파일이 enforce 모드인지, complain 모드인지 확인하면 됩니다. complain은 차단 대신 기록만 남기는 모드라서 테스트할 때 정말 유용해요.

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

AppArmor는 이렇게 프로파일 단위로 전환하는 방식이 직관적입니다. 경로 기반이라 "이 서비스가 이 디렉터리를 왜 못 읽지?"를 추적할 때 상대적으로 수월했어요. 다만 경로 변경이 잦은 환경에서는 프로파일 관리가 생각보다 귀찮을 수 있습니다.

sudo journalctl -k | grep DENIED
sudo dmesg | grep apparmor

차단 로그도 꼭 봐야 합니다. AppArmor는 쉬워 보이지만, 결국 로그를 안 보면 감으로 수정하게 되거든요. 그럼 나중에 정책이 지저분해져서 관리가 힘들어집니다.

6. 어떤 환경에서 무엇을 선택할까

SELinux AppArmor 비교의 결론은 기술 우열보다 운영 적합성에 있습니다. 제가 홈랩과 실무성 테스트 환경에서 느낀 기준을 정리해보면 이렇습니다.

• SELinux를 권하고 싶은 경우: RHEL 계열을 쓰고 있고, 정책 일관성과 세밀한 제어가 중요할 때
• AppArmor를 권하고 싶은 경우: Ubuntu 계열을 쓰고 있고, 빠르게 프로파일을 읽고 조정해야 할 때
• 팀 운영 관점: 로그 분석과 정책 유지에 익숙한 팀이면 SELinux도 충분히 잘 굴릴 수 있습니다.
• 개인 홈랩 관점: 처음 시작할 땐 AppArmor가 덜 부담스러울 수 있어요.

사실 제가 직접 써봤을 때 느낀 체감은 이랬습니다. SELinux는 한 번 체계가 잡히면 든든하고, AppArmor는 처음 붙을 때 편하다는 거죠. 둘 다 좋은 도구인데, 도구보다 운영자의 숙련도가 더 크게 작용하더라고요.

배포판, 운영 인력, 정책 복잡도에 따라 어떤 선택이 맞는지 보여주는 결정 흐름도입니다.

7. ⚠️ 주의사항과 트러블슈팅

이 섹션은 정말 중요합니다. 저도 처음엔 보안 기능을 꺼버리고 끝내고 싶었던 순간이 정말 많았거든요. 근데 그 습관 들이면 나중에 훨씬 더 힘들어집니다.

7-1. 서비스가 안 되면 바로 비활성화하지 마세요

가장 흔한 실수가 "일단 꺼서 되게 만들자"라는 생각입니다. 테스트 중 잠깐 상태를 완화하는 건 가능하지만, 영구 비활성화는 정말 신중해야 합니다. 문제 원인을 안 보고 끄면 이후에 보안 사고 대응력이 확 떨어지거든요.

7-2. 파일 권한과 보안 정책을 혼동하지 마세요

SELinux에서는 파일 권한이 맞아도 컨텍스트가 틀리면 접근이 막힙니다. AppArmor에서는 프로세스가 파일 경로 접근 권한을 갖고 있는지 별도로 봐야 합니다. 즉, chmod와 chown만으로는 완벽하게 해결되는 게 아닙니다.

7-3. 로그 없는 수정은 거의 실패합니다

• SELinux: AVC 거부 로그 확인
• AppArmor: DENIED 로그 확인
• 정책 변경 전후로 무엇이 달라졌는지 기록

제가 실무 비슷한 환경에서 자주 하는 방식은 간단합니다. 먼저 로그를 보고, 그다음 가장 좁은 범위로 수정합니다. 한 번에 크게 열어버리면 편하긴 한데, 나중에 왜 열었는지 기억이 안 나더라고요.

8. 검증과 결과 확인

설정을 끝냈다면 반드시 검증해야 합니다. 적용했다고 믿는 것과 실제로 동작하는 건 정말 다르거든요. 여기서 확인할 건 세 가지입니다.

1. 서비스가 정상 동작하는지 확인합니다.
2. 보안 정책이 실제로 enforce 중인지 확인합니다.
3. 거부 로그가 불필요하게 반복되지 않는지 봅니다.

curl -I http://localhost
getenforce
sudo aa-status
sudo journalctl -k --since "10 minutes ago"

정상 응답이 오고, 보안 모드가 의도한 상태이며, 로그에 반복적인 거부가 없다면 1차 검증은 통과입니다. ✅ 여기까지 오면 운영 가능한 상태에 꽤 가까워진 겁니다. 저도 이 단계까지 정리해두면 이후 서비스 추가가 훨씬 수월했어요.

서비스 정상 응답, 정책 적용 상태, 로그 감소 여부를 한눈에 확인하는 결과 이미지입니다.

9. 정리와 FAQ

SELinux vs AppArmor를 한 줄로 요약하면 이렇습니다. 세밀한 통제와 표준 운영이면 SELinux, 빠른 이해와 간결한 관리면 AppArmor를 선택하는 게 맞습니다. 물론 현실에선 배포판 기본값과 팀 경험이 선택에 큰 영향을 줍니다. 그래서 제 추천은 무조건 하나를 고집하기보다, 현재 운영 체계와 문제 해결 방식에 맞추는 거예요.

다음 단계로는 컨테이너 환경에서의 보안 프로파일, systemd 서비스 하드닝, seccomp(시스템 콜 필터링) 같은 주제까지 이어가면 좋습니다. 이 부분은 다음 글에서 다룰 예정입니다. 이전 글에서 다뤘던 리눅스 권한 구조와 함께 보시면 흐름이 더 잘 잡히실 거예요.

자주 묻는 질문

• Q. 둘 중 하나만 꼭 써야 하나요?
  A. 보통은 배포판과 운영 표준에 맞춰 하나를 중심으로 관리하는 편이 현실적입니다.
• Q. 초보자에게는 뭐가 더 쉬운가요?
  A. 대체로 AppArmor가 더 직관적입니다. 다만 장기 운영 기준에선 SELinux를 배워둘 가치가 정말 큽니다.
• Q. 보안 기능이 성능을 크게 떨어뜨리나요?
  A. 일반적인 서버 운영에서 체감보다 정책 정확성이 더 큰 이슈인 경우가 많았습니다.

선택 기준, 장단점, 추천 시나리오를 한 장으로 정리한 요약 인포그래픽입니다.

마지막으로, SELinux AppArmor 비교를 하다 보면 자꾸 정답 하나를 찾게 되는데요. 실제로 써보니까 정답은 환경마다 달랐습니다. 중요한 건 꺼두는 게 아니라 이해하고 운영하는 거예요. 처음엔 헷갈려도, 로그를 읽고 정책을 조금씩 줄여가다 보면 감이 옵니다. 그 과정이 조금 번거롭긴 해도, 서버를 오래 안정적으로 굴리려면 결국 한 번은 넘어야 할 산이더라고요. 이거 정말 중요합니다.

📚 함께 읽으면 좋은 글

• journald 로그 관리: systemd 실전 트러블슈팅 5가지
• Arch Linux 마이그레이션: Debian에서 Arch로 전환한 이유와 과정
• Fedora Ubuntu 비교: 1년 써본 홈 서버 분석