본문으로 바로가기

이 세 녀석들의 지난 비교가 만족스럽지 않았다.

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로 보는 것이 맞을 것이다.



댓글을 달아 주세요

티스토리 툴바