SLES 라이브 패칭을 활성화하고 커널 수정 사항을 검증하세요.
SLES 16.0 또는 15 SP7에 맞는 라이브 패치 경로를 설정하고, 적용 가능한 커널 수정 사항을 적용하고, 재부팅이 필요한 커널 업데이트와 혼동하지 않고 현재 활성화된 항목을 확인하십시오.
SUSE는 2025년 11월 4일에 SLES 16.0을 발표했으며, 이 버전에서는 AppArmor 대신 SELinux가 기본 필수 접근 제어 프레임워크로 사용됩니다. 서버에서 SLES 16이 실행 중인 경우 AppArmor가 설치되어 있거나 활성화되어 있다고 가정하지 마십시오. 이러한 명령을 사용하기 전에 해당 배포에서 지원하는 프레임워크를 확인하십시오. 아래 절차는 AppArmor가 기본적으로 설치 및 실행 중인 SUSE의 SLES 15 SP7 AppArmor 설명서를 따릅니다.
SLES 15 SP7에서 사용자 정의 애플리케이션을 구현하는 실질적인 방법은 aa-genprof시작 프로파일을 생성하고, 경고 모드에서 애플리케이션을 실행하고, 기록된 각 요청을 검토한 다음, 프로파일이 제대로 적용되는지 확인하는 것입니다. 예제에서는 가상 /usr/local/bin/report-worker의 실행 파일 경로를 사용했지만, 실제 애플리케이션 실행 파일 경로로 바꿔야 합니다.
AppArmor 프로필은 .app / /etc/apparmor.d...apparmor-utils
sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker

SUSE는 SLES 15 설치 시 AppArmor가 기본적으로 활성화되어 있다고 명시하고 있습니다. AppArmor 도구 또는 전체 패턴이 누락된 경우, 다음 명령어를 사용하여 패턴을 설치하십시오 sudo zypper in -t pattern apparmor. AppArmor가 활성화되어 있지 않은 경우, 프로파일링 전에 프로파일 파일만으로 보호가 된다고 가정하기보다는 그 원인을 파악해야 합니다. 프로파일은 실행 파일 경로에 연결됩니다. 실제 워크로드가 다른 바이너리로 실행되는 상황에서 래퍼를 프로파일링하면 중요한 프로세스가 제한되지 않을 수 있습니다.
제너레이터를 시작하세요. 이미 실행 중인 경우 애플리케이션을 중지한 다음 프로필 생성을 시작하세요.
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker

서비스 이름은 예시일 뿐입니다. 실제 장치 이름을 사용하거나 프로그램이 실행 중이 아닌 경우 정지 명령을 생략하십시오. 프로파일이 aa-genprof없는 경우 대략적인 프로파일을 생성하고, 경고(학습) 모드로 전환한 다음, 프로그램을 다시 로드하고 로그에 표시합니다. 경고 모드는 정책을 위반하는 요청을 기록하지만 허용합니다. 이는 일시적인 학습 상태이며 강제 적용 상태가 아닙니다.
실제 애플리케이션 동작을 연습하세요. 생성기를 열어둔 상태로, 다른 터미널에서 서비스를 시작하고 대표적인 작업이나 기능을 실행해 보세요.
sudo systemctl start report-worker
sudo journalctl -f

정상적인 시작, 예상 입력 및 출력 경로, 예약된 작업, 오류 처리, 그리고 애플리케이션이 실행하는 모든 도우미 프로그램을 포함해야 합니다. 프로파일은 테스트 중에 생성된 요청만 학습할 수 있습니다. 단순히 이벤트를 생성하기 위해 실제 운영 환경에 민감한 워크로드를 사용하지 마십시오. 안전한 테스트 환경과 대표적인 테스트 데이터를 사용하는 것이 바람직합니다.
각 접근 요청을 검토하십시오. 표시된 로그 범위를 스캔하려면 돌아가서 aa-genprof누르십시오 S. 각 프롬프트에 대해 애플리케이션이 해당 파일, 기능 또는 하위 프로그램 전환이 실제로 필요한지 판단하십시오. 가장 적합한 경로와 권한만 허용하십시오. 일반적인 작업을 정확하게 포괄하는 경우 추상화를 허용하고, 일치하는 파일이 동일한 신뢰 및 접근 요구 사항을 공유하는 경우에만 전체 범위를 사용하십시오. 우연적이거나 설명되지 않은 요청은 거부하거나 건너뛰십시오.

실행 요청에 특히 주의하십시오. 제한 없는 전환은 자식 프로세스가 부모 프로세스의 정책을 벗어나게 할 수 있으므로, 정당한 설계상의 필요성이 있는 경우에만 사용하십시오. 적절한 규칙을 추가한 후에는 연습 및 스캔 주기를 반복하십시오. 프로파일이 테스트된 동작을 모두 포함하게 되면 생성기를 완료하십시오. SUSE는 새로운 aa-genprof학습 주기가 완료되면 일반적으로 프로파일이 적용 모드로 전환된다고 언급합니다.
생성된 정책을 검토하십시오. 이 예시 경로의 경우, SUSE의 명명 규칙에 따라 실행 파일 경로의 슬래시(/)가 마침표(.)로 변환되어 생성됩니다 /etc/apparmor.d/usr.local.bin.report-worker. 생성된 규칙을 자동으로 안전한 것으로 간주하지 말고 결과를 검토하십시오.
sudo less /etc/apparmor.d/usr.local.bin.report-worker

프로필 이름이 의도한 실행 파일인지, 필요한 헤더 파일을 포함하는지, 그리고 애플리케이션이 실제로 필요로 하는 구성, 데이터, 로그, 소켓 및 도우미 프로그램에만 액세스 권한을 부여하는지 확인하십시오. 거부 반응을 /무시하기 위해 특정 디렉터리 아래에 무제한 액세스 권한을 부여하거나 전체 디렉터리 트리에 쓰기 권한을 부여하는 것과 같은 포괄적인 규칙은 피하십시오. 애플리케이션은 여전히 일반적인 Unix 소유권 및 권한에 의존하며, AppArmor는 별도의 제한 계층을 추가합니다.
의도하는 모드를 명시적으로 설정하십시오. 검토 후 사용자 지정 프로그램에 대한 프로필을 적용하십시오.
sudo aa-enforce /usr/local/bin/report-worker

생성기가 종료된 후 수동으로 프로필을 편집한 경우, .suse 명령어를 사용하여 프로필 세트를 다시 로드하십시오 sudo systemctl reload apparmor. SUSE 문서에서는 다시 로드를 실행 중인 프로세스의 제한을 해제하지 않고 프로필을 다시 스캔하는 것으로 설명합니다. 새 정책이 해당 프로세스에 적용되도록 애플리케이션 서비스를 다시 시작하십시오.
프로파일이 적용 모드인 상태에서 동일한 대표 작업을 다시 실행합니다. 서비스가 시작되고, 의도한 입력을 읽고, 예상 출력을 작성하며, 필요한 도우미 또는 네트워크 작업을 수행할 수 있는지 확인합니다. 그런 다음 프로파일 상태와 최근 커널 메시지를 모두 검사합니다.
sudo aa-status
sudo journalctl -k -g apparmor --since today


사용자 지정 실행 파일은 로드되어 적용 모드로 표시되어야 합니다. 커널 저널에 기록된 AppArmor 거부는 정책에 의해 차단된 요청을 나타냅니다. 이러한 거부는 모든 로그된 경로를 허용하는 이유가 아니라 실제 애플리케이션 오류를 진단하는 데 사용해야 합니다. 정당한 권한 누락이 있는 경우, 를 실행하고 sudo aa-logprof, 제안 사항을 검토하고, 규칙을 필요한 부분만 수정하고, 수동으로 편집한 경우 다시 로드한 다음, 해당 애플리케이션 경로를 다시 실행하십시오.
재부팅이나 장기간 관찰을 거쳐야 하는 지속적으로 실행되는 서비스의 경우, SUSE는 aa-autodep, aa-complain, 반복 aa-logprof스캔을 사용하는 별도의 시스템 워크플로를 문서화했습니다. 학습 실행을 전체 테스트 기간 동안 열어둘 수 있다면 독립 실행 aa-genprof형 방식이 더 간단합니다. 두 워크플로 모두 실행되지 않은 애플리케이션 동작은 추론할 수 없으므로 소프트웨어 또는 구성이 변경될 때마다 프로파일을 지속적으로 검토해야 합니다.
SLES 16.0 또는 15 SP7에 맞는 라이브 패치 경로를 설정하고, 적용 가능한 커널 수정 사항을 적용하고, 재부팅이 필요한 커널 업데이트와 혼동하지 않고 현재 활성화된 항목을 확인하십시오.
SLES 15 SP5는 SP6으로 온라인 마이그레이션이 가능하지만, 각 노드를 재부팅해야 합니다. 워크로드에 계속 액세스할 수 있도록 테스트를 거친 롤링 업그레이드 또는 블루-그린 컷오버 방식을 사용하십시오.
SLES 15 SP7에서 최소 권한 AppArmor 프로필을 생성, 개선 및 검증하고, SLES 16의 SELinux 기본 설정에 대한 명확한 설명을 추가합니다.
SUSE에서 지원하는 STIG 프로파일을 사용하여 SLES 15를 스캔하고, 수정 사항을 테스트하고, 남아 있는 문제점을 검토하고, 평가 증거를 보존하십시오.
SUSE의 최신 지침에 따라 DNS, 포트 9090, systemd 소켓, firewalld, TLS 및 로그인 설정을 통해 Cockpit 연결 실패 원인을 추적하십시오.
YaST와 Wicked를 사용하여 SLES 15에서 이중화 이더넷 연결을 생성하고, 액티브-백업 본딩을 구성한 다음, 두 포트와 페일오버를 모두 확인합니다.
기존 SLES 15 시스템을 검토를 거친 AutoYaST 프로파일로 변환하고, 유효성을 검사한 후, 수동 작업을 줄여 테스트 서버를 배포하는 데 사용하세요.
SLES 15 KVM 및 libvirt 도구를 설치하고, 올바른 호스트 서비스를 활성화하고, 재부팅 후 선택한 가상 머신이 시작되도록 구성하십시오.
systemd 작업과 이전 부팅 저널을 사용하여 속도가 느린 서비스, 마운트 또는 스토리지 종속성을 찾아낸 다음 원인을 숨기지 않고 수정합니다.
firewall-cmd를 사용하여 활성 영역을 검사하고, HTTP를 안전하게 허용하고, SSH 액세스를 유지하고, SLES 15에서 재로드 후에도 규칙이 유지되는지 확인하십시오.