운영체제는 신원확인, 인증, 접근제어, 일관된 보안제어를 하기 위한 감사 같은 기본원칙들의 조합이다.
일단 우리는 유동성과 다양한 보안정책들, 점점 복잡해지는 보안 메커니즘들을 지원하기 위해 결정한다.
그러한 환경속에서, TCB는 너무 크기때문에 작은 보안 커널에는 적합하지 않다.
층 모델에서 우리는 지금 운영체제 레벨에서 제공되는 보안 제어들을 본다. 운영체제의 보안에 접근하고자 할 때, 다음 질문들이 너의 분석에 도움을 줄 것이다.
1.어느 보안 특징들이 향상되어 왔는가?
2.이러한 보안 특징들이 어떻게 관리어야 하는가?
3.보안 특징들이 효과적일 거라는 어떤 확신이 있는가?
대부분의 상업 운영체제들은 보안 제어가 정규화되어 있고, 일반적인 패턴이 있다.
유저들의 정보는 user accounts에 저장된다.
한 유저에게 부여된 어떤 권한들은 이 account에 저장된다.
신원확인과 인증은 유저의 권한과 유저에 의해 시작된 어떤 한 프로세스와 관련하여 시스템이 허가해주는 유저의 신원을 증명해 준다.
자원들의 인가는 시스템 관리자나 자원 소유자에 의해 주어질 수 있다.
접근 요청을 허가해야할지 거부해야할지 결정해야 할때, 운영체제는 유저의 신원, 유저의 권한과 자원에 대한 인가 집합이 고려할 지도 모른다.
보안은 인증되지 않은 활동에 대해 예방하는 것뿐만 아니라 그들의 발견도 병행되어야 한다.
우리는 공격자들이 방지 메커니즘을 우회하는 방법을 찾을지 모른다는 사실에 직면해야 한다.
준비는 보안침해 또는 시도된 공격 흔적을 조사할 수 있기 위해 수행되는 활동 유저들을 기억하고 있도록 만들어지는 것이다.
그러므로 운영체제는 지켜지고 보호된 적절한 보안 사건들의 audit log가 요구될 수 있다.
마지막으로, 운영체제의 최고의 보안 기능은 그것들이 적당히 사용되지 않는다면 쓸모가 없다.
시스템은 보안상태에서 시작된다. 따라서 운영체제의 installation과 configuragion은 중요한 문제이다.
부적절한 기본 셋티은 주된 보안약점이 될 수 있다.
운영체제은 매우 복잡하고 지속적으로 진화하고 있는 소프트웨어 시스템이다.
그러므로, 취약점들이 발견되고 제거되고 혹은, 우연히 새로운 점이 소개될 가능성이 항상있다.
경고 시스템 관리자는 현재 상황과 대면하여 유지해야 한다.
6.1.1 Unix Security Architecture
대부분의 보안 운영체제는 어떻게 보안을 강력히하고 어디에 적절한 보안 데이터를 유지시킬지에 대해 설명하는 보안 구조를 가지고 있던 동안에 유닉스는 분기와 수렴 버전의 역사를 가지고 있다.
이것은 보안기능이 오리지날보다 더 나은 것의 필요성이 생길 때마다 유닉스에 더해졌다는 사실을 반영하는 것이다.
유닉스는 본래 네트환경 안의 소규모 다중사용자 컴퓨터를 위해 설계되었다, 후에, 상업 서버들에서는 늘었고, PC에서는 줄었다.
인터넷처럼, 유닉스도 연구실 혹은 대학들과 같은 환경속에서 개발되었고, 보안 구조는 약했었다. 유닉스가 개발될때마다, 새로운 보안제어는 시스템에 추가되었고, 존재하는 제어는 강력해졌다.
어떻게 새로운 기능을 추가할지를 결정할 때, 설계자는 유닉스 구조를 될 수 있는데로 훼손하려고 하는 욕망에 의해 좌지우지된다.
유닉스 설계 정신은 일반 사용자가 아닌, 숙련된 관리자에 의해 보안이 관리된다고 가정을 한다.
따라서, 보안 관리에 대한 지원이 스크립트나 command line tool들의 형태로 종종 나온다.
Programming/보안