개발 프레임워크 만들기 대장정 36 - 개발 프레임워크 보안 설계

아직 Spring.NET의 구체적인 API 및 설정 방법 등에 대해서는 모두는 알아보지 않았다. 그러나 사용 컨셉은 알게 되었다. 따라서 최소한 달봉이 머릿속에는 기업용 개발 프레임워크를 만들기 위해서 어떻게 사용해야 하는지는 레이어별로 가닥이 잡힌 듯 하다.

 

혹시 Spring.NET을 어떻게 사용할까 또는 이것을 이용해서 기업용 개발 프레임워크를 직접 만들 수 있지 않을까 하는 기대를 가지고 이 글을 읽고 있는 독자들이 있다면 달봉이와 같은 마음이길 바란다. 그러나 아직 그렇지 않더라도 실망할 필요는 없을 듯 하다. 사실 달봉이는 몇개의 프레임워크 다뤄본 경험이 있다. 그래서 그것을 염두에 두고 글을 쓰고 있기에 기존의 기업용 개발 프레임워크에서 필요로 하는 요구사항들을 어느 정도는 알고 있다. 그래서 그 기능을 구현하기 위해서 어떻게 Spring.NET을 사용할 수 있을까를 생각하면서 글을 쓰고 있는 것이다. 그런 요구사항들에 아직 경험이 없는 독자들이라면 아직 Spring.NET을 어떻게 사용해야 할지를 난감해할 지도 모르겠다. 그러나 언젠가는 빛이 나타날 수 있을 것이라 본다. 달봉이도 최선을 다해서 이 연재를 마치려고 한다. 언젠가는 Spring.NET을 이용해서 꼭 개발 프레임워크의 구현을 이루고 싶다. 독자들에게는 그때가 바로 Spring.NET이 “하늘에 떠 있는  뜬 구름”이 아닌 “땅위에 완성된 건물”로 다가올 것이라 본다.

 

이번 포스트 토픽으로 무엇을 할 것인가 고민을 했다. 지난 포스트에서 Spring.NET의 트랜잭션 얘기를 했으니 이번에는 실제로 트랜잭션을 이용하는 샘플을 만들어 볼까도 했다. 그러나 어차피 기업용 개발 프레임워크를 본격적으로 구현하는 단계에 들어가면 샘플은 있어야 한다. 구현된 코드는 그때 가서 보기로 결정했다.

아니면 Spring.NET의 WCF에 대한 지원 이야기를 해 볼까도 생각했다. 그러나 Spring.NET이 지원하는 내용은 WebServices에 대한 대한 내용과 크게 다를 것은 없을 것 같다는 생각을 했다. 물론 WebServices와 WCF 자체의 기술적인 차이는 크다. 그러나 Spring.NET 입장 그리고 개발 프레임워크를 만드는 우리 입장에서는 그 기술들의 세세한 내용은 지금 단계에서는 중요하지 않다고 판단했다. 이 또한 구현의 단계에서 고려해야 할 토픽이라고 여겼다.

이렇게 생각하고 보니 다음 토픽으로 무엇을 해야 할까가 쉽게 떠오르지 않았다. 만약 토픽이 없다면 이제 개발로 들어가야 하나 하는 생각을 하다 하나를 발견했다.

바로 권한 설계 !

 

■ 프레임워크 보안 설계(권한 설계)

 

흔히 개발 현장에서는 “권한”이라는 말을 자연스럽게 쓰고 있지만 상당히 뭉뚱그린 표현이다. 대화의 문맥에 따라 “권한”이라는 표현이 “사용자별 접근 가능한 메뉴”에 대한 권한일 수도 있고 또는 “한 화면에서의 CRUD에 대한 권한”이라는 의미를 가질 수도 있고 그리고 어떤 상황에서는 “사용자별 접근 가능한 데이터”라는 의미로도 사용된다.

그러나 구분없이 사용하는 이 “권한”이라는 표현을 영문으로 하면 문맥에 따라서 전혀 다른 표현으로 사용된다.

개발 프레임워크의 보안(권한) 설계에 대한 이해를 좀 더 명확히 하는데 도움이 되기 위해서, 이 포스트에서는 먼저 Windows 시스템의 보안에 대한 내용을 개념적으로 잠시 짚어보고 갈 것이다. 달봉이는 이 개념들을 개발 프레임워크의 보안 설계에 그대로 적용하려고 한다.  Windows의 보안에 대한 기본 개념은 지난 포스트에서 설명한 적이 있다. 참고하면 많은 도움이 될 것으로 보인다.

Windows 보안에 대한 자세한 내용을 보고 싶다면 여기 링크를 클릭해 보길 바란다. 책 한 권을 온라인에 올라와 있다. .NET 개발자로서 알아야 하는 Windows 보안에 대해 설명해 놓고 있다. 

Windows 보안과 관련된 기본적인 녀석들이 박스로 표현되어 있다. 먼저 Privilege라는 것이 것이 있다. 이 녀석은 사용자가 시스템( Operation Systme )에 대해서 어떤 작업( operation)을 할 수 있는지를 결정한다. 시스템 관리자는 “Local Security Policy”라는 관리툴을 이용해서 사용자(그룹)별로 어떤 작업을 할 수 있나를 설정할 수 있다. 커맨드 창에서 “secpol.msc”를 실행하면 수행된다.

작업(operation)들을 보면 시스템의 time zone을 변경하거나 시스템을 리부팅시킬 수 있는 권한을 부여하거나 하는 작업을 할 수 있다. Privilege라는 것은 사용자(그룹)가 시스템을 상대로 하는 작업에 대한 권한이라고 볼 수 있겠다.

사용자 Identity라는 것은 로그인 인증을 통해서 갖게 되는 정보이다. 사용자가 로그인을 하게 되면 사용자에 대한 토큰이 생성된다. 이 토큰에는 사용자 Identity, 사용자의 Privilege에 대한 정보 외에도 더 많은 정보가 포함되어 있지만 기본적으로 이 녀석은 “Who are you?”, “What are you allowed to do?”에 대해 답할 수 있는 정보가 포함되어 있다. 사용자가 프로그램을 실행시키면 사용자 토큰은 그대로 프로그램의 프로세스로 전달된다. 그런 식으로 사용자의 권한이 그 프로세스가 할 수 있는 권한을 결정하게 되는 것이다.

그림에는 Permission이라는 녀석이 있다. 이것도 우리말로는 흔히 “권한”이라는 것으로 표현되는데 이 녀석은 Privilege와는 다르다. 리소스에 대한 접근 권한이다. Windows 시스템에는 Permission에 의해 접근이 결정될 수 있는 여러 자원이 있다 : Files, registry keys, services, 프로세스 같은 커널 객체들 등. 이런 녀석들은 사용자( 프로세스 )가 자신들에 어떤 작업을 할 수 있는지를 결정해 놓은 목록이 있다. 이름하여 ACL( Access Control List)라는 것이다.

예를 들어 파일 시스템에서는 어떤 파일에 대해서 어떤 사용자가 어떤 작업( CRUD )을 할 수 있는지를 설정해 놓은 목록이 있다. 파일 및 폴더 자원에 대한 ACL 관리는 우리가 자주 사용하는 파일이나 폴더의 속성창을 통해서 할 수 있다.

사용자가 자원을 사용할 수 있느냐 마느냐는 이 사용자에 대해서 설정된 Permission에 의해서 결정되는 것이다.

분명 Privilege와 Permission은 개념적으로 다른 녀석들이다. “권한”이라는 하나의 표현으로 뭉뚱그리기에는 억울한 녀석들인 것이다.

 

■ Windows의 기본 보안 개념의 개발 프레임워크로의 적용

 

Privilege는 시스템을 상대로 해서 어떤 작업(operation)을 할 수 있는가를 결정한다고 했다.업무용 시스템에서라면 그 operation이라는 것은  “업무”를 말할 것이다. 예를 들어서 사용자 정보를 관리하는 업무, 인사 정보를 관리하는 업무 등등. 그런 업무들은 계층 구조를 가질 수 있어서 구체적인 업무로 다시 분류될 수도 있을 것이다. 이런 업무는 시스템에서는 “메뉴”로 구분될 수 있다. 즉 메뉴 체계는 보통 그 기업에서의 업무 구조를 근거로 해서 만들어지게 된다. 메뉴를 통해서 어떤 업무 작업을 할 수 있다는 것은 바로 Windows의 Privilege의 구현이라고 볼 수 있겠다. 즉 메뉴에 대한 사용자별( 사용자 그룹별) 권한을 부여한다는 것은 사용자에 대한 Privilege를 부여하는 작업에 해당된다고 할 수 있다. 혹시 달봉이가 만들 샘플 시스템에 예를 들어서 Privilege Mangement 라는 메뉴가 있다면 사용자(그룹)에 메뉴에 대한 권한(privilege)를  관리하는 프로그램이라고 보면 되겠다.

사용자 Identity는 사용자를 구분( authentication )하는 최소한의 정보이다. 달봉이가 구상하는 프레임워크에서는 이것을 표현할 UserIdentity 같은 클래스가 만들어질 것이다. 여기에는 사용자의 Id가 전부이다. 이 Id는 그 기업에서의 사번이 될 수도 있겠고 아니면 주민번호도 될 수 있을 것이고 아니면 고유한 일련의 문자열이 될 수도 있을 것이다. 사용자 Identity는 사용자를 인증하는 최소한의 정보를 가지고 있다.

그러나 시스템에 로그인하면 기본적으로 프레임워크단에서 가지고 있어주면 좋겠다는 사용자 정보에 대한 요구 항목이 기업마다 달라질 수 있다. 보통 사용자가 소속된 부서 코드만 포함시켜주길 바라는 곳도 있지만 어떤 기업 시스템에서는 그 기업만이 갖는 특수한 구조때문에 사용자 정보에 그런 항목도 포함되길 바라는 곳도 있다.

이런 상황을 고려해서 달봉이는 4개 이상의 타입을 도입할 것이다 : IIdentity, UserIdentity, IUserInfo, UserInfo, SiteUserInfo. 앞에서 4개 정도는 달봉이의 개발 프레임워크에서 제공할 것이고, 마지막 녀석은 현장에서 기업별로 제공되는 사용자 정보 클래스이다. 이 타입들의 구조에 대한 이야기는 다음 구현 단계에서 한번 더 있을 것이다.

Permission은 자원에 대한 접근 권한이라고 했다. 이때의 자원이라면 데이터에 대한 접근 권한이라고 할 수 있겠다. 즉 데이터에 대한 CRUD 권한은 달봉이 프레임워크에서는 Permission이라는 용어로 표현될 것이다.

 

이제 다음 포스트는 뭐로 할까요. 이제 개발로 들어가야 하나. 배고파! 돈이 없으니 더 배고프다. 쓰으..