최소 권한의 원칙

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 상세 내용
- 2.1. 최소 권한 원칙의 이점
- 2.2. 최소 권한 원칙 적용의 어려움
3. 역사
4. 구현
5. 유사한 원칙
참조

1. 개요

최소 권한의 원칙은 모든 사용자 계정 또는 프로세스에 해당 기능을 수행하는 데 필요한 최소한의 권한만 부여하는 보안 개념이다. 이 원칙은 시스템 안정성 및 보안을 향상시키고 소프트웨어 배포를 용이하게 하지만, 실제 적용에는 어려움이 따른다. 제롬 H. 샐처가 처음 명문화했으며, 시스템의 모든 프로그램과 사용자가 필요한 최소한의 권한으로 작동해야 함을 강조한다. 구현은 운영 체제와 하드웨어에서 이루어지며, 인텔 x86 아키텍처의 권한 링과 같은 기술을 활용한다. 이 원칙은 신뢰 컴퓨팅 시스템 평가 기준의 TCB 최소화, 권한 브래케팅, 임의적 접근 제어와 관련이 있다.

2. 상세 내용

최소 권한의 원칙은 모든 사용자 계정이나 프로세스에 의도된 기능을 수행하는 데 꼭 필요한 권한만 부여하는 것을 의미한다. 예를 들어, 백업을 만드는 사용자 계정은 소프트웨어를 설치할 필요가 없으므로, 백업 및 백업 관련 응용 프로그램을 실행하는 권한만 가진다. 새로운 소프트웨어 설치와 같은 다른 모든 권한은 차단된다. 이 원칙은 일반 사용자 계정으로 작업하고 상황이 꼭 필요할 때만 암호로 보호되는 권한 있는 계정을 여는 개인용 컴퓨터 사용자에게도 적용된다.^[2]

사용자에게 적용될 때, "최소 사용자 접근" 또는 "최소 권한 사용자 계정"(LUA)이라는 용어도 사용되며, 모든 사용자 계정이 가능한 한 적은 권한으로 실행되어야 하고, 또한 가능한 한 적은 권한으로 응용 프로그램을 시작해야 한다는 개념을 나타낸다.

이 원칙은 오류(내결함성) 및 악의적인 동작으로부터 데이터 및 기능을 보호하는 데 중요한 설계 고려 사항으로 널리 인식된다.^[2]

2. 1. 최소 권한 원칙의 이점

시스템 안정성 향상: 코드가 시스템을 변경할 수 있는 범위가 제한되면, 예상되는 동작이나 다른 응용 프로그램과의 상호 작용을 테스트하기가 더 쉬워진다. 제한된 권한으로 실행되는 응용 프로그램은 시스템을 충돌시키거나 동일 시스템에서 실행되는 다른 응용 프로그램에 부정적인 영향을 줄 수 있는 작업을 수행할 수 없다.^[2]
시스템 보안 향상: 코드가 시스템 전체에서 수행할 수 있는 작업이 제한되면, 한 응용 프로그램의 취약점을 사용하여 다른 컴퓨터를 악용할 수 없다. 예를 들어, 마이크로소프트는 표준 사용자 모드에서 실행하면 shatter 공격이나 루트킷, 스파이웨어, 탐지할 수 없는 바이러스와 같은 멀웨어로 인해 발생하는 의도하지 않은 시스템 수준 손상에 대한 더 큰 보호를 제공한다고 말한다.^[2]
소프트웨어 배포 용이성: 일반적으로, 응용 프로그램이 필요로 하는 권한이 적을수록 더 큰 환경 내에서 배포하기가 더 쉬워진다. 장치 드라이버를 설치하거나 권한이 필요한 응용 프로그램은 일반적으로 배포에 추가 단계가 필요하다. 예를 들어, Windows에서는 장치 드라이버가 없는 솔루션을 설치 없이 직접 실행할 수 있지만, 장치 드라이버는 드라이버에 권한을 부여하기 위해 Windows 설치 관리자 서비스를 사용하여 별도로 설치해야 한다.^[3]

2. 2. 최소 권한 원칙 적용의 어려움

실제로, 진정한 최소 권한의 원칙을 적용하기는 어렵다. 현재로서는 어떤 프로세스의 실행에 필요한 최소 권한을 찾는 방법이 확립되어 있지 않다. 이는 모든 변수의 가능한 값의 범위, 필요한 주소, 필요한 정확한 시간 등을 완전히 파악할 수 없기 때문이다. 가장 현실적인 접근 방식은 인간이 불필요하다고 확인할 수 있는 권한을 제거해 나가는 방법이다. 결과적으로 얻어지는 권한군은 해당 프로세스의 진정한 최소 권한보다 더 넓은 범위가 된다.^[4]

또 다른 제약으로는 운영 환경이 얼마나 세밀하게 권한을 제어할 수 있는가 하는 문제가 있다. 실제로 메모리 액세스 범위, 처리 시간, I/O 장치의 주소나 모드 등을 필요한 권한만큼 정확하게 부여할 정도로 정밀하게 제어할 수 있는 경우는 드물다.^[11]

3. 역사

제롬 샐처는 이 원칙을 처음으로 다음과 같이 명문화했다.^[5]

피터 J. 데닝은 "Fault Tolerant Operating Systems"라는 논문에서 이를 더 넓은 관점으로 내결함성의 4가지 기본 원칙 중 하나로 제시했다.^[9]

권한의 동적 할당은 1972년 로저 니덤에 의해 논의되었다.^[6]^[7]

역사적으로 최소 권한의 가장 오래된 예는 Version 6 유닉스 [http://www.retro11.de/ouxr/u6ed/usr/source/s1/login.c.html#n:132 소스 코드]에서와 같이 ''login.c''의 소스 코드일 것이다. 이는 슈퍼유저 권한으로 실행을 시작하고, 더 이상 필요하지 않은 순간 0이 아닌 인수를 사용하여 ''setuid()''를 통해 권한을 해제하는 방식이다.

4. 구현

커널은 운영 체제의 핵심이며 하드웨어에 접근할 수 있으므로 항상 최대 권한으로 실행된다. 운영 체제, 특히 다중 사용자 운영 체제의 주요 책임 중 하나는 실행 중인 프로세스로부터 하드웨어의 가용성과 접근 요청을 관리하는 것이다. 커널이 충돌하면 상태를 유지하는 메커니즘도 실패한다. 따라서 하드 리셋 없이 CPU가 복구할 수 있는 방법이 있더라도 보안은 계속 적용되지만 운영 체제는 실패를 감지할 수 없었기 때문에 실패에 제대로 대응할 수 없다.

트로이 목마 코드를 로드하고 실행한 후 충돌이 발생하여 실행이 다시 시작되면 트로이 목마 코드 작성자가 모든 프로세스에 대한 제어를 빼앗을 수 있다. 최소 권한의 원칙은 코드가 가능한 가장 낮은 권한/허가 수준으로 실행되도록 강제한다. 이를 수행하는 데 사용되는 한 가지 방법은 마이크로프로세서 하드웨어에서 구현할 수 있다. 예를 들어, 인텔 x86 아키텍처에서 제조사는 국방 및 정보 기관의 보안 인가 시스템과 매우 유사한 점진적인 접근 권한을 가진 4개의 실행 "모드"(링 0에서 링 3까지)를 설계했다.

일부 운영 체제에서 구현된 대로, 프로세스는 '잠재적 권한 집합'과 '활성 권한 집합'으로 실행된다. 이러한 권한 집합은 ''fork()''의 의미에 따라 상위 프로세스에서 상속된다. 권한이 있는 기능을 수행하는 실행 파일은 일련의 권한으로 표시될 수도 있다. 이는 set 사용자 ID 및 set 그룹 ID 개념의 논리적 확장이다. 프로세스에 의한 파일 권한의 상속은 ''exec()'' 계열의 시스템 호출의 의미에 의해 결정된다. 잠재적 프로세스 권한, 실제 프로세스 권한 및 파일 권한이 상호 작용하는 정확한 방식은 복잡해질 수 있다. 실제로 최소 권한은 작업에 필요한 권한만 사용하여 프로세스를 실행하도록 강제함으로써 실행된다. 이 모델을 준수하는 것은 매우 복잡할 뿐만 아니라 오류가 발생하기 쉽다.

5. 유사한 원칙

신뢰 컴퓨팅 시스템 평가 기준(TCSEC)의 신뢰 컴퓨팅 기반(TCB) 최소화 개념은 기능적으로 가장 강력한 보증 등급인 B3 및 A1 등급에만 적용되는 훨씬 더 엄격한 요구 사항이다.

최소 권한은 종종 권한 브래케팅과 관련이 있다. 즉, 가능한 마지막 순간에 필요한 권한을 가정하고 더 이상 엄격하게 필요하지 않으면 즉시 해제하여, 의도치 않게 정당한 권한보다 더 많은 권한을 악용하는 오류 코드로부터의 파급 효과를 줄이는 것이다. 최소 권한은 또한 임의적 접근 제어(DAC) 권한의 분배와 관련하여 해석되기도 한다. 예를 들어 사용자 U가 읽기 권한만으로 승인된 작업을 완료할 수 있는 경우, 사용자 U에게 파일 F에 대한 읽기/쓰기 액세스 권한을 부여하는 것은 최소 권한 원칙을 위반하는 것이다.

참조

_[1] 논문 The protection of information in computer systems Institute of Electrical and Electronics Engineers (IEEE)
_[2] 웹사이트 Virtualization Guru Writes "User-mode is a Good Thing - Deployment to Locked-down Accounts without Security Elevation" http://www.dabcc.com[...] 2013-03-15
_[3] 웹사이트 Problems of Privilege: Find and Fix LUA Bugs https://technet.micr[...] Microsoft 2006-08
_[4] 웹사이트 Matt Bishop, ''Computer Security: Art and Science'', Boston, MA: Addison-Wesley, 2003. pp. 343-344 cited Barnum & Gegick 2005 https://buildsecurit[...] 2007-11-17
_[5] 논문 Protection and the control of information sharing in multics
_[6] 서적 Proceedings of the AFIPS '72 Fall Joint Computer Conference, December 5-7, 1972, Part I
_[7] 웹사이트 Least Privilege and More http://www.cs.cornel[...]
_[8] 문서 Harvnb Saltzer
_[9] 문서 Harvnb Denning
_[10] 웹사이트 Problems of Privilege: Find and Fix LUA Bugs http://technet.micro[...] Microsoft 2006-08
_[11] 문서 Matt Bishop, ''Computer Security: Art and Science'', Boston, MA: Addison-Wesley, 2003. pp. 343-344 cited Barnum & Gegick 2005 https://buildsecurit[...]
_[12] 논문 Protection and the control of information sharing in multics
_[13] 문서 Roger Needham, ''Protection systems and protection implementations'', Proc. 1972 Fall Joint Computer Conference, AFIPS Conf. Proc., vol. 41, pt. 1, pp. 571-578
_[14] 웹사이트 Schneider, Least Privilege and More http://www.cs.cornel[...]

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com