네트워크 보안 - 8 | 인가

인가

이전 포스트에서는 접근제어의 두 가지 부분 중 하나인 인증에 대해 알아보았다. 그리고 이번 포스트에서는 나머지 반쪽인 인가에 대해 알아보고자 한다.

 

인가는 접근제어의 한 부분으로서 인증된 사용자의 활동을 제약하는 문제를 다룬다. 좀 더 자세히 말하자면, 인증이 시스템 자원에 접근하려는 사용자에 대한 판별의 문제라면, 인가는 이미 인증된 사용자가 하려는 행동을 제약하는 상황을 다룬다는 것이다.

 

인증과 인가를 같은 접근제어를 의미하는 용어로 사용하는 경우도 많이 있지만, 이번 포스트에서는 인증과 인가를 나누어 생각해 보기로 한다.

---

접근제어행렬

접근제어행렬은 주체와 객체를 행렬의 행과 열로 표현하는 방법을 말한다. 여기서 주체는 시스템 사용자로 정의되며, 객체는 시스템의 자원으로 정의된다. 이때 주체의 경우 반드시 사람일 필요가 없다. 예를 들어 특정한 프로그램의 경우 그 프로그램에 필요한 시스템 자원에 직접 접근하는 경우가 있을 수 있는데, 그 경우 해당 프로그램이 주체가 될 수 있다.

 

이러한 접근제어행렬은 인가 분야의 기본적인 두 가지 개념인 접근제어목록(ACL; Access Conrtol List)과 권한목록(C-list; capabilities)을 만들 수 있다. 접근제어목록과 권한목록에 대해 알아보기 전에 이를 모두 포괄하는 개념인 접근제어행렬이 어떤 식으로 작동하는지를 알아보자.

 

아래는 접근제어행렬의 한 예이다.

접근제어행렬

다음의 행렬표에서 x, r, w는 각각 실행, 읽기, 쓰기에 대한 권한을 나타낸다.

 

예를 들어 밥은 운영체제와 회계 프로그램은 읽고 실행할 수 있고, 회계 데이터는 읽기만 가능하고, 나머지 객체에 대해서는 접근할 수 없다. 앨리스는 밥보다 권한이 더 높아서 보험 데이터와 지급액 데이터를 읽고 쓰는 것이 가능하다.

또한 회계 프로그램은 주체일 수도 있고 객체일 수도 있는데, 사람에 의해 실행될 때는 객체로써 사용되지만, 해당 프로그램이 동작하면서 다른 객체인 여러 데이터들을 가져올 때에는 주체로써 동작하는 것을 확인할 수 있다.

 

이처럼 접근제어행렬은 어떠한 주체(사용자)가 특정한 객체(시스템 자원)에 접근하려는 것에 대한 인가결정의 근거로 사용될 수 있다. 하지만 실제로 방대해진 접근제어행렬을 관리하기 위해서는 현실적인 문제가 있다.

 

현실의 시스템은 수 백개 이상의 주체와 수 만개 이상의 객체를 가지고 있기 때문에, 어떤 주체가 어떤 객체에 대해 어떠한 권한을 가지고 있는지를 확인하기 위해서는 엄청나게 방대해진 접근제어행렬의 원소를 참조해야 한다. 보통의 일반적인 시스템에서는 이러한 크기의 연산을 다루는 것이 힘들기 때문에 뭔가 다른 방법이 필요하다.

접근제어목록과 권한목록

이러한 연산의 문제로 실제 인가에서는 접근제어행렬을 근거로 한 접근제어목록과 권한목록이 사용된다. 이들은 접근제어행렬을 관리가 용이한 크기의 여러 조각으로 분해한 것으로, 인가를 위한 연산이 실제 시스템에서 수용 가능한 정도가 되도록 해준다.

 

먼저 접근제어목록은 접근제어행렬을 열을 기준으로 분해한 후, 각 열을 해당 객체와 함께 저장하는 방법이다. 즉, 객체를 기준으로 하여 각 주체들이 해당 객체에 어떤 권한을 가지고 있는지를 저장하는 것이다.

위의 접근제어행렬 예시에서 지급액 데이터에 해당하는 접근제어목록은 다음과 같이 작성할 수 있을 것이다.

(밥, -), (앨리스, rw), (샘, rw), (회계 프로그램, r)

 

반면 권한목록의 경우 접근제어행렬을 행을 기준으로 분해한 후, 각 행을 해당 주체와 함께 저장하는 방법이다. 즉, 주체를 기준으로 하여 해당 주체가 각 객체에 어떤 권한을 가지고 있는지를 저장하는 것이다.

위의 접근제어행렬 예시에서 앨리스의 권한목록은 다음과 같이 작성할 수 있을 것이다.

(운영체제, rx), (회계 프로그램, rx), (회계 데이터, r), (보험 데이터, rw), (지급액 데이터, rw)

 

접근제어목록과 권한목록은 단순히 같은 정보를 저장하기 위한 두 가지 다른 방법에 불과하다고 볼 수 있다. 하지만 이 두 가지 방법은 서로 미묘한 차이점이 있다.

 

접근제어목록을 사용하면 특정 자원에 대한 권한을 변경하는 것이 용이해진다. 반면 권한목록을 사용하면 권한의 위임이 쉽고 사용자를 추가하거나 삭제하는 작업이 쉽다. 또한 권한을 위임할 수 있는 능력 덕분에 권한목록의 경우 접근제어목록에 비해 대리혼돈의 문제를 쉽게 피할 수 있다.

대리 혼돈

대리혼돈은 고전적인 보안문제로, 주체가 다른 프로그램을 사용할 때 그 프로그램의 권한을 이용해서 자신의 권한 이상의 행동을 하게 되는 문제를 말한다.

 

예를 들어 다음과 같은 접근제어행렬이 있다고 가정하자.

대리혼돈 문제의 접근제어행렬

해당 접근제어행렬에 따르면 앨리스는 컴파일러에 대한 실행 권한은 있지만, 청구서파일에 대한 권한이 없다. 하지만 컴파일러는 청구서파일에 대한 읽기와 쓰기 권한이 존재한다.

 

만약 앨리스가 컴파일러를 구동시켜서 청구서파일을 열어본다면 어떨까? 원칙적으로 앨리스는 청구서파일을 읽거나 수정할 권한이 없으므로, 어떠한 방법으로도 앨리스가 청구서파일에 접근할 수 없어야 한다. 하지만 앨리스를 대신해 동작하고 있는 컴파일러는 청구서파일을 읽고 쓸 권한이 있으므로, 결과적으로 앨리스가 컴파일러를 통해 자신의 권한 이상을 행사할 수 있게 된다.

 

따라서 이러한 문제를 해결하기 위해서는 권한의 위임이 필요하다. 앨리스가 컴파일러를 구동시킬 때 자신의 권한을 컴파일러에게 주어야 하고, 컴파일러는 동작하기 전에 권한을 검사하는 시점에서 앨리스의 권한을 부여받아 동작해야 한다. 이러한 과정을 거치는 경우 앨리스가 자신의 권한 이상의 권한을 행사하는 것을 막을 수 있다.

 

이러한 대리혼돈의 문제를 살펴볼 때 접근제어목록과 권한목록의 차이가 더욱 확연히 드러난다. 권한목록의 경우 주체를 기준으로 해당 주체의 권한에 대한 내용들을 관리하기 때문에, 해당 주체의 권한을 다른 객체로 위임하기가 비교적 용이하다. 하지만 접근제어목록의 경우 그렇지 못하기 때문에 대리혼돈을 피하기가 힘들다.

 

이외에도 접근제어목록과 권한목록은 상대적으로 장점과 단점을 가지고 있다. 이에 대해 더욱 자세히 알아보지는 못하겠지만, 전체적인 개념과 어떠한 차이가 있는지 정도만 알고 넘어가도 좋을 것 같다.

---

다단계 보안 모델

보안 모델은 정보보안을 위해 고안된 모델로, 단순히 보호의 윤곽을 잡는데 목적을 두고 있다. 이 중 다단계 보안 모델은 주체와 객체가 서로 상이한 등급에 있으면서 동일한 시스템 자원을 사용할 때 필요하다. 보안 모델에서 주체는 사용자이며 객체는 보호되어야 할 데이터가 되는데, 객체에는 기밀등급을 적용하고 주체에는 취급등급을 적용한다. 다단계 보안 시스템의 목적은 주체가 객체에 접근하는데 필요한 취급등급을 갖는 것에 대해 제약을 가하는 방식으로 접근제어를 하는 것이다.

 

이러한 다단계 보안은 비밀을 다루는 정부기관이나 군에서 많이 사용되어 왔지만, 오늘날은 일반적인 회사나 다른 분야에서도 유용하게 사용하고 있다. 예를 들어, 회사에서도 고위급 관리자에게만 공개가 허용되는 정보가 있는가 하면, 일반 관리자 모두에게 허용되는 정보도 있다. 이러한 정보가 하나의 시스템에 저장되어 있고 함께 관리된다면, 그 회사는 다단계 보안 문제를 고민해야만 한다.

 

이러한 다단계 보안 모델은 굉장히 다양한 종류가 있지만, 이번 포스트에서는 가장 기본적이고 단순한 형태의 모델 두 가지에 대해 간략히 알아보고자 한다.

벨-라파둘라 모델

벨-라파둘라(BLP) 모델은 비밀성을 중점으로 다루는 보안 모델로 다음의 두 가지 조건으로 구성되어 있다.

• 주체 S가 객체 O를 읽기 위한 필요충분조건은 L(O)$\leq$ L(S)이다.
• 주체 S가 객체 O를 쓰기 위한 필요충분조건은 L(S)$leq$ L(O)이다.

위의 조건을 이해하기 쉽게 풀어서 설명하면, 사용자가 데이터를 읽기 위해서는 사용자의 취급등급이 데이터의 기밀등급 이상이어야 하고, 사용자가 데이터를 쓰기 위해서는 사용자의 취급등급이 쓰일 데이터의 기밀등급 이하여야 한다.

 

자신보다 높은 등급에 데이터는 읽지 못하게 하는 것은 보안적으로 당연해 보이기 때문에 이상하게 보이지 않는다. 하지만 사용자가 어떤 데이터를 쓰기 위해서는 쓸 데이터보다 등급이 낮아야 한다는 것은 언뜻 보기에 이해가 되지 않는다.

 

이는 벨-라파둘라 모델이 보안의 세 가지 요소 중 비밀성에 중점을 맞추고 있기 때문이다. 만약 2급 비밀 취급등급을 가진 사용자가 3급 비밀을 작성한다면 어떨까? 이 경우 2급 비밀 정보다 3급 비밀문서에 쓰일 수 있고, 이는 다단계 보안의 보안성을 침해하는 결과를 가져온다.

 

이는 단순히 사람이 보안 문서를 작성함에 따라 실수로 자신이 알고 있는 상위의 보안 정보를 하위의 보안 문서에 작성함을 막는다는 의미도 있지만, 컴퓨터 바이러스로 인해 특정한 보안 등급을 가진 프로그램이 잘못 동작하여 기밀 정보를 노출하는 문제도 막는다는 의미도 가지고 있다.

 

이러한 모델을 어떠한 보안 알고리즘이나 프로토콜을 이용해 직접 구현할지는 해당 시스템을 직접적으로 구축하는 설계자에게 달려있는 문제이다. 중요한 것은 벨-라파둘라 모델에서는 "상향 읽기 금지"와 "하향 쓰기 금지"라는 단순한 규칙을 명시하여 비밀성을 다루기 위한 모안 모델의 전체적인 큰 틀을 제시한 것이다.

비바 모델

비바 모델은 벨-라파둘라 모델과 반대로 비밀성이 아닌 무결성을 다룬다. 그래서 비바 모델을 무결성에 대한 BLP라고 할 수도 있다. 비바 모델의 조건은 다음과 같은데, 이때 I(O)와 I(S)는 각각 객체 O와 객체 S에 대한 무결성을 뜻한다.

• 주체 S는 객체 O를 쓰기 위한 필요충분조건은 I(O)$leq$ I(S)이다.
• 주체 S가 객체 O를 읽기 위한 필요충분조건은 I(S)$leq$ I(O)이다.

이는 주체 S가 자신이 신뢰받고 있는 수준 이상으로 쓴 내용에 대해서는 신뢰하지 말아야 하고, S는 자신보다 높은 신뢰성을 가지고 있는 객체만 읽을 수 있다는 내용이다.

 

비바 모델에서는 무결성을 중점으로 다루기 때문에 저장된 자료가 오염되는 것을 극도로 경계한다.

 

만약 특정 무결성 등급을 가지고 있는 사용자가 데이터를 쓴다면, 해당 데이터는 그 데이터를 쓴 사용자의 무결성 등급보다 높을 수 없다. 일반적으로 낮은 신뢰도를 가진 사람이 쓴 내용은 아무리 잘 쳐줘도 그 작성자의 신뢰도 정도로만 봐야 하기 때문이다.

 

그리고 특이하게도 사용자는 항상 자신 이상의 무결성 등급을 가진 데이터만 읽을 수 있다. 이는 만약 높은 무결성 등급을 가진 사용자가 자신보다 낮은 무결성 등급의 자료를 읽는다면, 해당 사용자는 자신보다 낮은 무결성을 가진 객체에 의해 오염될 수 있다고 보기 때문이다. 따라서 이러한 경우 그 즉시 해당 사용자의 등급을 해당 낮은 무결성을 가진 객체와 같은 등급으로 내린다. 무결성을 다루기 때문에 어떠한 이유로든 무결성이 오염될 가능성을 제거하기 위해서이다.

 

이러한 이유로 비바 모델은 저수위 원칙을 지향한다고 볼 수 있는데, 저수위 원칙은 간단하게 아래와 같이 설명할 수 있다.

주체 S가 객체 O를 읽을 경우, I(S) = min(I(S), I(O))가 된다.

---

은닉통로

은닉통로는 시스템 설계자가 애초에 의도하지 않았던 통신통로로, 특히 네트워크 통신에서 많이 발생한다. 이러한 은닉통로는 공격자들이 정보를 빼내기 위해 주로 사용하는데, 근본적으로 모든 은닉통로를 제거하는 것은 불가능하기 때문에 이러한 통로를 통해 전달되는 정보의 양을 줄이는 것에 주안점을 둔다.

 

다단계 보안 시스템은 적법한 통로를 통한 통신에서 등급에 맞게 접근제어를 하기 위해 설계되었다. 하지만 은닉통로는 애초에 완전히 다른 방식으로 정보를 주고받기 때문에 이러한 다단계 보안 시스템을 위반할 수 있다.

 

예를 들어, 1급 비밀을 취급하는 앨리스가 일반적인 취급 등급만을 가진 밥에게 정보를 빼돌리려 한다고 가정하자. 이때 일반적인 방법으로는 앨리스가 밥에게 기밀 정보를 전달할 방법이 없다. 밥은 자신보다 높은 보안 등급의 자료를 확인할 수 없고, 앨리스도 자신보다 낮은 보안 등급의 자료를 쓸 수 없기 때문이다.

 

하지만 만약 보안과는 아무 상관이 없어 보이는 파일의 생성을 이용해 정보를 주고받는다면 어떨까? 앨리스가 FileXYZW를 생성하면 1, 생성하지 않으면 0을 보내는 것이라고 밥과 미리 모의했다고 하자. 그리고 밥은 시스템을 통해 특정 파일이 존재하는지는 확인할 수 있는 상태이다. 따라서 이러한 방식으로 비트를 하나씩 흘려보내면서 데이터를 밥에게 전달한다면, 보안 모델이 이를 확인하여 막아낼 방법이 없다.

 

이처럼 애초에 통신을 위해 설계된 방식이 아닌 것을 이용해 통신을 위해 은밀하게 사용하는 은닉통로는 이전에 공부한 정보은닉의 스테가노그래피와도 유사하다고 볼 수 있겠다. 이러한 은닉통로가 존재하기 위해서는 다음의 세 가지 조건을 만족해야 한다.

• 송신자와 수신자는 공유된 자원에 대한 접근권한을 가지고 있어야 한다.
• 송신자는 수신자가 관찰할 수 있는 공유자원의 특징을 변경할 수 있어야 한다.
• 송신자와 수신자는 그들 간의 통신을 동기화시킬 수 있어야 한다.

따라서 모든 은닉통로를 완전히 제거하는 방법은 사실상 공유자원과 통신을 모두 제거하는 방법 밖에 없을지도 모른다. 이에 대한 결론으로 은닉통로를 완전히 제거하는 것을 불가능하기에, 은닉통로를 통한 정보의 양을 줄이는 것이 최선의 방법이다. 위의 예시 같은 경우라면 파일의 생성 및 삭제에 어느 정도의 대기 시간이 걸리게 한다든지의 방법이 있을 수 있겠다.