최신 리눅스 시스템은 바이러스 공격 및 기타 필수 보안 기능에 대한 보호 기능이 내장되어 있어 매우 안전합니다. 그러나 오늘날의 원격 액세스 및 국제 전자 상거래 세계에서는 위험성이 높으며 일부 CIO와 네트워크 관리자는 리눅스 시스템을 더욱 안전하게 만들 수 있는지 알고 싶어 합니다. 리눅스 환경에 다른 보안 계층을 추가하는 또 다른 옵션은 필수 액세스 제어(MAC)를 통합하는 것입니다.
필수 액세스 제어는 군사 기밀 및 기타 특권 정보에 사용되는 다단계 보안 시스템에서 발전된 개념입니다. MAC를 이해하는 가장 좋은 방법은 기성 리눅스 환경에서 사용되는 기존 Unix 기반인 임의 액세스 제어 (DAC) 시스템과 어떻게 다른지 고려하는 것입니다.
기존 리눅스 시스템은 리소스에 읽기/쓰기/실행 권한을 할당하고 소유자 또는 관리자가 사용자 및 그룹에 대한 액세스 권한을 부여할 수 있도록 합니다. 수퍼 사용자 (종종 “루트”사용자라고 함)는 시스템에 대한 완전한 제어 권한을 가지며 모든 리소스에 액세스하거나 액세스 권한을 부여 할 수 있습니다. 모든 사람이 행동하고 아무도 실수하지 않으면, 유연하고 이해하기 쉬우며 매우 안전합니다. 그러나 리소스 소유자가 무심코 리소스를 가져서는 안되는 사람에게 액세스 권한을 부여하면 어떻게 될까요? 또는, 더 중요한 것은 사용자 계정이 손상되고, 침입자가 DAC 시스템에 내장된 유연성을 이용하여 권한을 상승시키는 경우 어떻게 될까요?
강력한 "루트"계정의 존재는 매우 안전한 조직에서 사용되는 세분화된 보안 원칙과 일치하지 않는 또 다른 기능입니다. 매우 안전한 환경은 정확한 책임에 따라 시스템 관리자에게 역할을 할당하는 경향이 있습니다. 필수 액세스 제어를 사용하면 사용자에게 필요한 최소 권한을 부여하고 변경 및 권한 상승을 방지하는 정책을 만들 수 있습니다. IT의 모든 것은 비용이 들기 때문에, 필수 액세스 제어를 위한 시스템을 채택하기 전에, 필요한 것이 맞는지 확인하십시오. 유연성의 상실은 비즈니스 프로세스에 오버헤드와 복잡성을 추가할 수 있으며, 때로는 일반 작업이 될 수 있는 관리 개입을 강요할 수 있습니다.
리눅스에서 필수 액세스 제어를 위해 가장 많이 사용되는 두 가지 도구는 SELinux와 AppArmor입니다. CentOS 7 및 CentOS 8과 같은 Red Hat 기반 배포판은 SELinux 용으로 사전 구성되어 있습니다. Ubuntu 및 openSUSE는 AppArmor를 사용합니다. 그러나 개발자는 AppArmor에 더 익숙하거나 환경에서 더 잘 작동할 것이라고 생각하는 경우 항상 AppArmor를 제거하고 SELinux를 설정할 수 있습니다. AppArmor와 SELinux는 모두 리눅스 커널 모듈의 형태를 취하며 기술 지원 수준은 다를 수 있지만, 대부분의 주요 리눅스 시스템에서 실행되도록 구성할 수 있습니다.
일반적으로 AppArmor는 구성 및 작동이 더 쉽습니다. 그러나 AppArmor는 매우 안전하고 필수 액세스 제어 프레임워크 없이 작동하는 것보다 훨씬 안전하지만 SELinux 는 더 깊고 다양한 수준의 보호를 제공합니다. AppArmor는 파일 및 기타 리소스를 보호하도록 설계되었습니다. 그러나 프로세스에 대해 동등한 보호를 제공하지 않습니다. 또한 AppArmor는 경로별로 리소스를 참조하기 때문에 이미 시스템에있는 침입자는 이론적으로 inode 기반 SELinux를 사용하여 불가능한 하드 링크로 몇 가지 트릭을 수행할 수 있습니다.
SELinux는 원래 미국 국방부의 국가 수준 정보 기관인 미국 국가안보국(NSA)의 연구를 기반으로 개발되었습니다. 액세스 제어에 대한 보다 완벽한 접근 방식을 제공합니다. 그러나 구성 및 운영이 더 어렵기 때문에, 추가 구성 시간과 IT 직원의 학습 시간이 길어질 것으로 예상됩니다.
팀 승인을 통해 MAC의 이점은 많으며 전체 회사 구조를 통해 느끼는 보안 우선 인식의 길을 열 수 있습니다.
댓글 (2)
“an intruder who is already on the system could theoretically play some tricks with hard links that wouldn’t be possible using the Linode-based SELinux.”
That should probably be “inode-based”.
Hey Rudolph – thanks for bringing this to our attention! I’ll let our team know so that they can review this.