SUSE SLES 15에서 사용자 지정 애플리케이션용 AppArmor 프로필을 설정하는 방법

버전 참고 (2026년 10월 6일 확인): 이 절차는 AppArmor를 사용하는 SUSE Linux Enterprise Server(SLES) 15 SP7 및 호환되는 SLE 15 시스템에 적용됩니다. SUSE는 SLES 15 SP7에 AppArmor가 기본적으로 설치 및 실행된다고 명시하고 있습니다. SUSE Linux 16.0은 AppArmor를 제거하고 SELinux를 사용하므로 아래 명령을 16.0 버전에 적용하지 마십시오. SUSE의 SUSE Linux 16.0 비교 가이드 와 해당 릴리스의 SELinux 문서를 참조하십시오.

AppArmor는 프로그램이 접근할 수 있는 영역을 제한하는 Linux 보안 모듈입니다. 프로필은 실행 파일에 적용되는 정책으로, 파일, 기능 및 기타 리소스에 대한 접근을 허용하거나 거부할 수 있습니다. 이 가이드는 플랫폼 확인부터 테스트를 거친 프로필 적용까지 단계별로 안내하며, 사용자 지정 애플리케이션이 예기치 않게 오작동할 가능성을 줄이기 위해 신중한 학습 단계를 포함합니다.

프로필을 만들기 전에 무엇을 준비해야 할까요?

애플리케이션이 중요한 경우 테스트 또는 유지 관리 기간을 활용하세요. 관리자 계정 sudo, 애플리케이션의 실제 실행 경로, 그리고 애플리케이션이 수행하는 일반적인 작업 목록이 필요합니다. 백그라운드 작업, 시작 및 종료, 구성 재설정, 업로드 또는 내보내기, 예약된 작업, 그리고 네트워크 연결 기능 등을 모두 포함하세요. 한 번 실행으로 얻은 프로필로는 사용하지 않는 기능까지 추론할 수 없습니다.

애플리케이션이 데이터를 읽고 쓰는 위치, 실행 계정, 그리고 도우미 프로세스를 시작하는지 여부를 파악하십시오. 가능한 한 민감한 운영 데이터를 대상으로 테스트하지 마십시오. 변경하기 전에 현재 서비스 상태를 기록하고 기존 프로필의 사본을 보관하십시오.

이 SUSE 릴리스에서 AppArmor를 사용할 수 있는지 어떻게 확인할 수 있습니까?

먼저 운영 체제 버전과 현재 AppArmor 상태를 확인하십시오.

cat /etc/os-release
sudo aa-status

시스템이 SLES 15 SP7 또는 AppArmor를 지원하는 문서가 있는 다른 릴리스를 보고하는지 확인하십시오. SLES 15 SP7의 경우 SUSE 가이드에 따르면 AppArmor는 기본적으로 설치 및 실행됩니다. AppArmor가 설치되어 있지 않은 경우 SUSE 문서에서 설치 방법을 sudo zypper in -t pattern apparmor확인할 수 있습니다. 서비스가 설치되어 있지만 실행되지 않는 경우, 서비스를 활성화하기 전에 시스템 시작 정책 및 서비스 상태를 확인하십시오. 애플리케이션 문제를 해결하기 위해 보안 모듈을 비활성화하지 마십시오. 릴리스별 자세한 내용은 SLES 15 SP7 AppArmor 시작 가이드 및 SLES 15 SP7 AppArmor 명령줄 도구 가이드를 참조하십시오.

AppArmor가 프로파일링해야 할 실행 파일을 어떻게 식별합니까?

AppArmor 프로필은 프로그램 경로와 연결되어 있으므로 사용자가 입력한 명령어가 실행 파일이라고 가정하는 대신 실제 실행 파일을 식별해야 합니다. 셸 경로를 통해 사용할 수 있는 명령어를 확인하려면 다음을 실행하세요.

command -v myapp

서비스의 경우, 시스템에서 사용 가능한 도구를 사용하여 서비스 단위 정의 및 프로세스 세부 정보를 검사하십시오. 실행 스크립트, 심볼릭 링크 또는 인터프리터가 예상과 다른 실행 파일을 가리킬 수 있습니다. readlink -f /path/to/myapp적절한 경우 알려진 경로를 확인하십시오. 아래 모든 명령에서 확인된 절대 경로를 사용하십시오. /usr/local/bin/myapp는 예시일 뿐입니다.

프로파일링을 시작하기 전에, SUSE 프로파일 저장소에 이미 프로파일이 있는지 확인하십시오 /etc/apparmor.d. SUSE는 프로파일을 해당 위치에 저장하며, 파일 이름은 일반적으로 실행 파일 경로의 슬래시(/)를 마침표(.)로 바꿉니다. 예를 들어, /usr/local/bin/myapp는 와 같은 파일 이름에 usr.local.bin.myapp해당합니다. 기존 공급업체 프로파일이나 로컬에서 관리하는 프로파일을 검토 없이 덮어쓰지 마십시오. SUSE는 또한 프로파일 저장소 아래에 추가 프로파일 목록을 제공합니다 . /usr/share/apparmor/extra-profiles적합한 프로파일이 시작점으로 활용될 수 있지만, 애플리케이션 및 릴리스에 맞게 검토해야 합니다( SUSE 프로파일 저장소 문서 참조 ).

안전하게 초기 프로필을 생성하는 방법은 무엇인가요?

프로필 생성 도구를 관리자 권한으로 실행하고 전체 실행 파일 경로를 입력하십시오.

sudo aa-genprof /usr/local/bin/myapp

aa-genprof시작 프로필을 생성하고 프로그램을 실행하는 동안 경고 모드로 전환합니다. 경고 모드는 정책 위반 사항을 기록하지만 거부된 작업을 차단하지는 않으므로 정책 적용 전에 동작을 관찰할 수 있습니다. 도구의 안내에 따라 진행하고, 애플리케이션 실행 후 스캔 옵션을 사용하여 기록된 이벤트를 검토하십시오. SUSE는 이 과정이 반복적인 과정이며 자동으로 제안된 프로필이 완벽하다는 보장은 아니라고 설명합니다.

어떤 조치를 테스트해야 하며, 거부 사례는 어디에서 찾을 수 있습니까?

프로필이 오류 보고 모드인 동안에는 일반 운영자처럼 애플리케이션을 사용하십시오. 읽기, 쓰기, 업로드, 보고서 생성, 서비스 재시작 및 도우미 작업 등 일반적인 워크플로와 빈도는 낮지만 지원되는 작업을 테스트하십시오. 테스트는 실제 상황을 반영해야 합니다. 프로그램은 내보내기 시와 홈 화면에서 서로 다른 파일이나 자식 프로세스를 사용할 수 있습니다.

AppArmor 관련 이벤트가 있는지 커널 메시지와 감사 로그를 검토하십시오.

sudo journalctl -k | grep -i apparmor

시스템의 로깅 설정에 따라 SUSE는 /var/log/audit/audit.log, journalctl | grep -i apparmor, 및 로그 뷰도 참조합니다 dmesg -T. 하나의 로그 뷰에서 일치하는 항목이 없다고 해서 프로파일이 올바르다고 단정할 수는 없습니다. 애플리케이션이 제대로 실행되었는지 확인하고 로깅 서비스 및 기타 문서화된 로그 위치를 점검하십시오. 애플리케이션이 한 번 시작되었다는 이유만으로 생성된 프로파일이 테스트되었다고 간주하지 마십시오.

프로필을 어떻게 검토하고 다듬어야 할까요?

루트 권한으로 aa-logprof로그된 이벤트를 처리하고 프롬프트에 응답하세요.

sudo aa-logprof

각 이벤트에 대해 해당 액세스가 문서화된 애플리케이션 작업에 필요한지 여부를 확인하십시오. 프로그램에 필요한 제한된 경로, 액세스 모드 또는 기능만 허용하십시오. 구성 파일 읽기는 예상되는 작업일 수 있지만, 계획되지 않은 관련 없는 디렉터리에 쓰기가 발생하면 오류가 발생했거나 조사해야 할 다른 구성 요소가 있을 수 있습니다. 규칙이 너무 광범위하면 접근 제한이 약화되고, 너무 좁으면 유효한 작업이 제대로 수행되지 않을 수 있습니다.

• 모든 메시지에 자동으로 동의하거나 모든 파일에 대한 일괄적인 접근 권한을 부여하지 마십시오.
• 광범위한 와일드카드와 불필요한 기능은 피하고, 정확한 경로와 최소한의 필수 권한을 사용하는 것이 좋습니다.
• 프로필 수정 후 작업 부하 및 로그 검토 주기를 반복합니다. 별도의 서비스 운영 및 백그라운드 작업을 포함합니다.
• 변경 사항은 대상 애플리케이션에 한정하십시오. 불필요한 알림을 없애기 위해 관련 없는 프로필을 수정하지 마십시오.

프로필은 액세스 제어 경계이므로 프롬프트에 대한 응답은 단순히 로그에 나타났다는 이유만으로 하는 것이 아니라 애플리케이션 동작 및 운영 요구 사항에 따라 이루어져야 합니다. SUSE SLES 15 SP7 AppArmor 명령줄 도구 가이드에서는 명령줄 도구에 대해 설명하고 있으며, SUSE AppArmor 지원 참조aa-genprof 링크는 , aa-logprof, 및 를 포함한 관련 man 페이지에 대한 링크를 제공합니다 apparmor_parser.

프로필을 언제 강제 적용 모드로 전환해야 합니까?

대표 워크플로가 성공적으로 완료되고 정상적인 이벤트를 검토한 후에만 정책 적용 단계로 넘어가십시오. 애플리케이션 프로필 하나를 적용하고, AppArmor의 프로필 세트를 다시 로드한 다음, 애플리케이션 또는 서비스를 다시 시작하여 실행 중인 프로세스가 업데이트된 정책을 사용하도록 하십시오.

sudo aa-enforce /usr/local/bin/myapp
sudo systemctl reload apparmor

SUSE는 프로필을 다시 로드하면 프로필이 다시 읽히므로 /etc/apparmor.d이미 실행 중인 프로그램은 업데이트된 프로필이 적용되기 전에 다시 시작해야 할 수 있다고 명시합니다. 서비스 소유자와 재시작 일정을 조율하고 해당 애플리케이션에 맞는 서비스 관리 명령을 사용하십시오. 그런 다음, 오류 보고 모드에서 성공했다고 해서 변경 없이도 작동할 것이라고 가정하지 말고, 적용 모드에서 주요 워크플로를 다시 실행하십시오.

결과를 어떻게 검증하고 회귀 오류를 어떻게 복구합니까?

테스트 후 프로필 상태를 확인하고 새로운 거부 사항이 있는지 살펴보세요.

sudo aa-status
sudo journalctl -k | grep -i apparmor

의도한 프로필이 로드되어 적용 모드에 있는지, 서비스가 정상적으로 작동하는지, 필요한 모든 작업이 제대로 수행되는지 확인하십시오. 적용으로 인해 정상적인 작업이 차단되는 경우 관련 이벤트를 수집하고 액세스가 실제로 필요한지 검토한 후 프로필을 더욱 세분화하십시오. 간략하고 통제된 진단을 위해 sudo aa-complain /usr/local/bin/myapp해당 프로그램의 프로필을 경고 모드로 전환할 수 있습니다. 조사, 업데이트 및 재테스트를 수행한 후 다시 적용 모드로 되돌리 aa-enforce십시오. 필요한 경우 프로필을 다시 로드하고 재시작하십시오. 임시 해결책으로 AppArmor를 전역적으로 비활성화하거나 광범위한 권한을 부여하는 것은 피하십시오.

흔히 저지르는 실수 중 피해야 할 것은 무엇일까요?

• 잘못된 릴리스 지침을 사용하고 있습니다. 여기 제시된 워크플로는 SLES 15 AppArmor용입니다. SUSE의 비교 가이드에 따르면 SUSE Linux 16.0은 SELinux를 사용합니다.
• 실제 프로그램 대신 래퍼를 프로파일링하여 실제로 실행되는 실행 파일을 검증합니다. 특히 서비스 및 스크립트에 유용합니다.
• 학습량이 너무 적으면 테스트되지 않은 기능은 관찰된 접근을 생성하지 않으므로 불완전한 프로필은 나중에 오류를 일으킬 수 있습니다.
• 맥락 없이 권한 요청 메시지를 승인하는 것은 바람직하지 않습니다. 추가되는 모든 권한은 애플리케이션에 필요한 작업을 수행하는 데 기여해야 합니다.
• 재시작을 잊어버린 경우: 프로필을 다시 로드한 다음 필요할 때 실행 중인 애플리케이션을 다시 시작하여 프로세스가 정책을 적용하도록 하십시오.
• 롤백 경로 없이 편집하기: 로컬에 저장된 프로필을 백업하고 버전 관리 또는 시스템 구성 관리 프로세스를 통해 변경 사항을 추적하세요.

SUSE 공식 참조 자료

• SLES 15 SP7 AppArmor 시작 가이드
• SLES 15 SP7 AppArmor 명령줄 도구 가이드
• SUSE 프로필 저장소 문서
• SUSE AppArmor 지원 참조
• SUSE Linux 16.0 비교 가이드

이 참조 자료는 2026년 10월 6일에 확인되었습니다. 명령어 및 패키지 세부 정보는 제품 릴리스에 따라 다를 수 있으므로 변경하기 전에 설치된 SLES 서비스 팩에 대한 문서를 확인하십시오.