본문 바로가기

IT 살이/03. 관리 - 보안 관리

permissions, rights, privileges 비교(업데이트)

이들에 대한 지난 비교가 만족스럽지 않았다.
2016/10/14 - permissions, rights, privileges 비교 
다시 간략하게 요약해 보도록 한다. 

 

다음 그림은 세 개념의 관계를 표현하고 있다. 

 

다음은  이 그림의 관계를 이야기한다. 

 

모든 객체는 외부에 대해서 제공하는 서비스가 있다고 볼 수 있다. 파일은 내용을 "읽고", "쓰고", "수정"할 수 있는 서비스를 제공한다. 운영 체제는 "환경을 설정할 수 있는 서비스", 더 구체적인 예로는 "시스템의 시간을 변경할 수 있는 서비스"를 제공한다. 그리고 팩스 서버는 "팩스를 전송할 수 있는 서비스"를 제공한다. 또한 객체들은 다른 객체들의 서비스를 이용하고 조합해서 (mesh up) 자신의 서비스를 구현하기도 한다. 운영 체제가 다른 여러 구성 요소들과 그들의 서비스로 구현되어 있는 것을 생각해보면 이해가 쉬워진다.  

각 객체들( 파일, 팩스 서버, 운영체제등)은 누가 어떤 서비스를 사용할 수 있는지에 대한 설정 정보를 가질 수 있다. 팩스 서버에는 팩스 서비스와 관련된 권한 설정, 운영 체제에는 운영 체제가 제공하는 서비스와 관련된 권한 설정. 이렇게  객체에 정의된 권한은 말한대로 permissions이다. 

그러나 이것은 상황에 따라서는 rights라고 할 수 있는데, 그 상황이란 것은 보안 모델과 관련되어 있다. 접근 권한을 관리하기 위해서 "객체에 권한 설정"만으로 접근 통제를 하는 모델이 있고, "주체와 객체 양쪽 모두에 권한 정보를 설정"하는 모델이 있다. 

 

팩스 서버에 사용자 계정을 등록하고 팩스 서비스를 사용할 수 있는지를 설정하는 것이 첫번째 모델에 속한다. Windows 모델은 두번째 모델이다. 주체와 객체 예를 들어 사용자와 사용자가 사용하려는 파일 양쪽 모두에 적절한 설정이 되어 있어야 사용자는 정상적인 파일 서비스를 받을 수 있다. 

첫번째 모델에서는 객체에 설정하는 permissions만으로 주체의 rights가 결정된다. 이 경우는 permissions가 rights의 의미가 된다. 그러나 두번째 모델에서는 rights와 permissions이 정확히 구분된다. 그리고 첫번째 모델이나 두번째 모델에 상관없이 권한을 설정하는 권한은 privileges로 볼 수 있다.

※ 참고로 첫번째 모델을 DAC(Discretionary Access Control)이라 하고 두번째 모델을 MAC(Mandatory Access Control)이라고 한다.

 

 

참고) 일반 표현들의 이해

특정 권한 모델의 문맥하에서는 이렇게 "기계적"인 구분과 정의를 해 볼 수 있다. 그러나 일반적인 상황 즉 보안 모델에 상관없이 권한을 말할때는 rights, permissions, privileges가 상호 호환되어 사용되기도 하는 것으로 보인다. 그런 일반적인 상황에서는 "허용", "권리", "특권" 어떤 의미로 사용되는가에 따라서 용어를 구분해서 사용하면 될 것 같다. 

예1) "그 계정에는 권한이 너무 많이 부여되어 있다" 
보안 모델에 대한 언급이 없다. permissions, rights, privileges 어느 것을 사용하든 상관없겠지만 이때는 "특권"이라는 것으로 해석해서 privileges로 하면 적절할 것 같다.   

예2) "소프트웨어를 인스톨할 수 있는 권한이 없다"
다른 상황 설명이 없어서 본인은 privileges로 이해하겠다.


예3) "그 계정 그룹에는 Windows에 소프트웨어를 인스톨할 수 있는 권한이 없다"
 앞의 예문과 동일하지만 Windows라는 상황이 설명되어 있다. 이때는 그 계정 그룹에 대한 rights로 보는 것이 맞을 것이다.