SELinux·AppArmor·Secure Boot·TPM으로 구성하는 운영체제 보안

접근 제어와 부팅 신뢰를 함께 다루는 운영체제 보안

운영체제 보안은 프로세스 권한을 제한하는 데서 끝나지 않는다. 실행 중인 프로세스의 접근을 통제하는 MAC 체계와, 부팅 단계에서 변조를 막는 Secure Boot, 하드웨어에 키와 측정값을 보관하는 TPM이 연결되어야 시스템 무결성과 데이터 보호의 기반이 갖춰진다.

SELinux와 AppArmor는 프로세스가 파일과 리소스에 접근하는 범위를 좁힌다. Secure Boot는 신뢰할 수 없는 부트로더와 커널의 실행을 막고, TPM은 암호화 키 및 플랫폼 상태를 하드웨어 수준에서 다룬다.

SELinux가 정책으로 제한하는 프로세스 접근

SELinux는 Security-Enhanced Linux의 약자로, NSA(미국 국가안보국)에서 개발한 MAC 프레임워크다. 프로세스와 파일에 보안 컨텍스트(Security Context)를 부여하고, 정책을 기준으로 세밀한 권한을 판정한다.

⤢✕

SELinux는 Enforcing, Permissive, Disabled 모드로 동작한다. Enforcing에서는 정책 위반을 차단하고 로그를 기록한다. Permissive는 위반을 허용하되 로그만 남기므로 디버깅에 쓰이며, Disabled는 SELinux를 비활성화한 상태다.

보안 컨텍스트는 다음과 같이 구성된다.

user:role:type:level
system_u:object_r:httpd_sys_content_t:s0

user는 system_u, unconfined_u 등 SELinux 사용자를 나타낸다. role은 object_r, system_r 등의 역할 기반 접근 제어 요소다. type은 타입 강제(Type Enforcement)의 핵심이며 실제 접근 제어 기준이 된다. level은 MLS(Multi-Level Security) 레벨을 표현한다.

웹 서버는 httpd_t 타입으로 웹 프로세스를 격리할 수 있고, 데이터베이스에는 postgresql_t 등 DB별 전용 컨텍스트를 적용할 수 있다. 컨테이너 프로세스는 container_t 타입으로 샌드박싱하며, AVC 로그를 분석한 뒤 audit2allow로 필요한 정책을 추가하는 방식도 활용된다.

AppArmor는 파일 경로와 프로필을 기준으로 제한한다

AppArmor는 Canonical(Ubuntu)이 주도해 개발한 경로(Path-based) 기반 접근 제어 체계다. 프로필(Profile) 단위로 프로세스를 제약하며, SELinux와 비교해 설정이 단순하고 학습 곡선이 완만하다.

프로필은 Enforce, Complain, Unconfined 모드를 가질 수 있다. Enforce는 규칙을 강제하고, Complain은 위반 로그만 기록하며 실제 접근을 막지 않는다. Unconfined는 프로필을 적용하지 않는 상태다.

/usr/bin/firefox {
  /etc/passwd r,
  /home/*/** rw,
  /proc/*/status r,
  deny /etc/shadow rwx,
}

여기서 r, w, x, ix는 각각 읽기, 쓰기, 실행, 상속 실행을 뜻한다. deny는 명시적 거부 규칙이다.

⤢✕

RHEL/CentOS/Fedora 환경은 SELinux가 기본 탑재되어 있고 관련 생태계가 성숙해 있다. Ubuntu/Debian에서는 기본 탑재된 AppArmor로 빠르게 적용할 수 있다. Docker와 Kubernetes 환경은 두 체계를 모두 지원한다. 정부 및 금융권의 규제 준수 요구에서는 SELinux가 유리하다.

Secure Boot가 부팅 체인의 변조를 차단하는 방식

Secure Boot는 UEFI 펌웨어 수준에서 동작하는 보안 메커니즘이다. 서명되지 않은 부트로더나 커널의 실행을 차단해 루트킷과 부트킷 방어에 사용되며, 부팅 단계 전체에 신뢰 체인(Chain of Trust)을 구성한다.

⤢✕

키 관리 구조에는 최상위 키인 PK (Platform Key), PK로 서명되어 DB/DBX 갱신에 쓰이는 KEK (Key Exchange Key), 허용된 부트로더와 드라이버 서명을 보관하는 DB (Authorized Signature Database), 금지된 서명 블랙리스트인 DBX (Forbidden Signature Database)가 있다.

리눅스에서는 Microsoft 서명과 배포판 서명 체인을 사용하는 shim 부트로더를 활용한다. MOK (Machine Owner Key)로 사용자가 자체 서명한 모듈을 등록할 수 있으며, kmodsign 도구로 커널 드라이버에 서명한다.

커스텀 커널이나 드라이버는 MOK 등록 또는 Secure Boot 비활성화가 필요하다. 듀얼 부팅 환경에서는 Windows와 키를 공유하거나 별도로 관리해야 한다. 서버는 원격 키 관리와 IPMI/BMC를 통한 펌웨어 업데이트를 고려해야 하며, 금융 및 공공 부문에서는 Secure Boot가 필수다.

TPM은 키와 플랫폼 상태를 하드웨어에서 다룬다

TPM은 Trusted Platform Module의 약자다. 암호화 키를 안전하게 저장하는 하드웨어 보안 칩이며 ISO/IEC 11889 표준을 준수한다. TPM 1.2는 레거시 버전이고 TPM 2.0은 현행 버전이다.

⤢✕

PCR (Platform Configuration Register)은 0~23번 레지스터에 각 단계의 해시 값을 누적 저장한다. PCR 0-7은 펌웨어, 부트로더, OS 로더 측정에 사용되고, PCR 8-15는 OS 및 애플리케이션 측정에 사용된다. Extend 연산은 다음과 같다.

PCR_new = SHA(PCR_old || 측정값)

봉인(Sealing)은 특정 PCR 값일 때만 복호화할 수 있도록 데이터를 암호화하는 방식이다. 언봉(Unsealing)은 PCR 값이 일치할 때만 데이터를 복호화한다. BitLocker와 LUKS 같은 디스크 암호화 키 보호에 활용된다.

TPM은 LUKS와 결합한 전체 디스크 암호화(FDE) 자동 언락, Windows BitLocker의 키 관리, 변조 시 부팅 차단 또는 경고를 위한 부트 무결성 검증에 쓰인다. 클라우드 인프라에서는 원격 증명으로 노드 신뢰성을 확인할 수 있고, 가상화 환경에서는 vTPM으로 VM별 독립된 신뢰 루트를 제공한다.

TPM 2.0은 RSA 외 ECC, SHA-256/384을 지원해 알고리즘 선택 폭을 넓혔다. 부모-자식 키 관계의 계층적 구조로 키 관리를 단순화하고, HMAC 및 정책 기반 접근 제어를 포함한 인증 기능을 제공한다. PC뿐 아니라 IoT와 모바일 플랫폼으로도 적용 범위가 확장됐다.

하드웨어에서 애플리케이션까지 이어지는 방어 계층

⤢✕

보안 스택은 TPM 기반 디스크 암호화와 Secure Boot 활성화로 물리 보안 계층을 마련하고, SELinux Enforcing 모드와 최소 권한 정책으로 OS 보안을 구성할 수 있다. 네트워크에는 iptables/nftables, VPN, TLS/mTLS를 적용하며, 애플리케이션 계층에서는 컨테이너 격리와 서비스별 AppArmor 프로필을 사용한다.

MAC 시스템의 오버헤드는 워크로드별 조정이 필요하다. 레거시 애플리케이션과 SELinux/AppArmor의 충돌, 자동화 도구(Ansible, Puppet)를 활용한 관리 복잡도, auditd와 rsyslog를 이용한 보안 이벤트 중앙 집중도 함께 검토해야 한다. Secure Boot 키 갱신 절차를 정책화하고 TPM 키 백업 및 복구 절차를 문서화하는 일도 운영 범위에 포함된다.

운영 환경에서 확인할 보안 설정

SELinux와 AppArmor는 getenforce, aa-status로 모드를 확인한다. AVC 거부 로그는 /var/log/audit/audit.log에서 분석하며, 정책 상태는 semodule -l, aa-enforce로 확인한다. 불필요한 권한은 최소 권한 원칙에 따라 제거한다.

Secure Boot 상태는 mokutil --sb-state로 확인할 수 있다. dmesg | grep -i secure로 부팅 로그를 확인하고, efivar -l | grep -i pk로 키 상태를 확인한다. Shim/GRUB에는 최신 패치가 적용되었는지도 점검한다.

TPM은 /sys/class/tpm/tpm0/에서 존재 여부를 확인한다. tpm2_pcrread로 PCR 값을 조회하고, tpm2_getcap properties-fixed로 소유권을 확인한다. 펌웨어 업데이트는 제조사 권고사항을 따른다.