위키원
"접근제어"의 두 판 사이의 차이
잔글 |
|||
| (사용자 3명의 중간 판 8개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | '''접근제어'''( | + | '''접근제어'''(access control)는 적절한 [[권한]]을 가진 [[인가자]]만 특정 시스템이나 정보에 접근할 수 있도록 [[제어]]하는 것이다. 접근제어는 [[시스템]]의 [[보안]] 수준을 갖추기 위한 가장 기본적 방법이다.<ref name="접근제어"> 〈[https://terms.naver.com/entry.naver?docId=3431851&cid=58437&categoryId=58437 접근 제어]〉, 《네이버 지식백과》</ref> |
== 개요 == | == 개요 == | ||
| − | + | [[시스템]] 및 [[네트워크]]에 대한 접근제어의 가장 기본적인 수단은 [[아이피]](IP)와 서비스 [[포트]]이다. [[운영체제]], [[데이터베이스]], [[응용프로그램]] 및 [[네트워크]] 장비에서 각각 접근제어된다.<ref name="접근제어"></ref> 데이터 저장장치에 접근하는 권한을 정의하거나 제한하고, 권한 있는 자 및 프로그램, 기타 시스템만이 시스템 자원정보에 접근할 수 있도록 제한하며, 사용자 요청에 따라 시스템 자원을 지정하는 자원제어기의 기능을 수행한다.<ref name="접근제어를 이용하라"> 〈[https://terms.naver.com/entry.naver?docId=3432527&cid=58445&categoryId=58445 접근제어를 이용하라]〉, 《네이버 지식백과》 </ref> 웹 서비스나 [[클라우드]] 서비스 등을 개발하면서 가장 중요하게 고려해야 하는 부분 중 하나는 바로 각 사용자들이 서비스의 어느 부분까지 사용할 수 있고, 어느 부분은 사용할 수 없는지를 제어하는 것이다. 이것은 보안에 매우 밀접한 관련이 있기 때문에 올바르게 접근제어를 구현하는 것은 매우 중요하다. 서비스 개발자는 해당 서비스를 통해 어떤 기능을 제공할 것인지에 대한 고민뿐만 아니라, 서로 다른 사용자들의 서비스 접근 권한을 어떻게 제어할 것인지도 고민해야 한다. 그러기 위해서는 접근제어 모델의 종류와 그 구현 방법들을 아는 것이 매우 중요하다. 접근제어 모델에서 인가를 받으려는 사용자를 주체(Subject)라고 한다. 주체는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. 객체(Object)는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. [[네이버 카페]]의 게시판이 객체의 예이다. [[권한]](Permission)은 객체에 허용된 주체가 수행할 수 있는 행위의 목록을 말한다. 보통 권한에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다. 결국 접근제어라는 것은 객체에 접근하고자 하는 주체가 해당 객체에 접근할 수 있는 권한을 가지고 있는지 판단하는 것이다.<ref name="Luniverse"> Luniverse 공식 홈페이지 - https://www.luniverse.io/2021/02/26/access-control-models/?lang=ko </ref> | |
| − | ==종류== | + | == 종류 == |
| − | ===강제적 접근제어 | + | === 강제적 접근제어 === |
| − | 강제적 접근제어 | + | [[강제적 접근제어]](MAC: Mandatory Access Control)는 어떤 주체가 특정 객체에 접근할 때, 양자의 보안 레벨에 기초하여 낮은 수준의 주체가 높은 수준의 객체정보에 접근하는 것을 강제적으로 제한하는 방법이다. 컴퓨터의 모든 자원(중앙처리장치, 메모리, 프린터, 모니터, 저장장치 등)을 객체로 하고, 그 객체를 사용하고자 하는 것을 주체(사용자 및 모든 프로세스)로 설정하여, 각 객체 파일의 비밀 등급과 각 주체의 허가 등급을 부여한다. 이후 주체가 객체를 읽거나 기록하거나 실행시키고자 할 때마다 그 주체가 그 객체에 대한 권한을 가지고 있는지를 확인하는 방식이다.<ref name="접근제어를 이용하라"></ref> 대표적인 예로 [[네이버㈜]]나 [[다음카페]]에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다. 강제적 접근제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다. 이러한 강제적 접근제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.<ref name="Luniverse"></ref> |
| − | ===임의적 접근제어 | + | === 임의적 접근제어 === |
| − | 임의적 접근제어 | + | [[임의적 접근제어]](DAC: Discretionary Access Control)는 자원의 소유자 혹은 관리자가 보안 관리자의 개입 없이 자율적 판단에 따라 접근 권한을 다른 사용자에게 부여하는 기법을 말한다. 따라서 자원의 보호보다는 자원의 공동 활용이 더 중요시되는 환경에 적합하며, 기업 환경에는 자원의 유출 가능성을 내포하고 있다. 임의적 접근제어는 특별한 사용자나 그들이 소속되어 있는 그룹들의 식별자(ID)에 근거하여 객체에 대한 접근을 제공한다. 접근제어는 객체의 소유자에 의하여 임의적으로 이루어진다. 그러므로 특정 객체에 대한 접근 허가를 가지고 있는 한 주체는 임의의 다른 주체에게 자신의 허가를 넘겨줄 수 있다. 즉 추가적인 접근제어는 그 사용자에게 일임하는 방식이다. 따라서 임의적 접근제어 방식은 하나의 주체 대 객체 단위로 접근 제한을 설정할 수 있고, 이러한 접근 제한은 모든 주체 및 객체들 간에 동일하지 않다. 즉 한 주체가 특정한 비밀 등급의 한 객체에 대한 접근을 허가하지 않는 임의적 접근제어 정책을 수립해도 그 주체가 그러한 비밀 등급을 갖는 다른 객체들에게 접근하는 것은 방지할 수 없다.<ref name="접근제어를 이용하라"></ref> 대표적인 예는 전통적인 [[유닉스]]나 [[윈도우]] 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근제어를 설정할 수 있다. 여기서 임의적(Discretionary)이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다. 대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근제어에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근제어가 어렵다. 또한 접근제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다. 임의적 접근제어를 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.<ref name="Luniverse"></ref> |
====접근제어 행렬==== | ====접근제어 행렬==== | ||
| − | 접근제어 행렬(Access Control Matrix)은 | + | [[접근제어 행렬]](Access Control Matrix)은 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 예를 들어 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.<ref name="Luniverse"></ref> |
====접근제어 목록==== | ====접근제어 목록==== | ||
| − | 접근제어 목록(Access Control List | + | [[접근제어 목록]](ACLs: Access Control List)은 가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여 받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.<ref name="Luniverse"></ref> |
====가용성 티켓==== | ====가용성 티켓==== | ||
| − | 가용성 티켓 (Capability Tickets)은 접근제어 | + | [[가용성 티켓]](Capability Tickets)은 접근제어 목록과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 예를 들어 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근제어 목록 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.<ref name="Luniverse"></ref> |
====권한 테이블==== | ====권한 테이블==== | ||
| − | 권한 테이블 (Permission Table)은 관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한 가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.<ref name="Luniverse"></ref> | + | [[권한 테이블]](Permission Table)은 관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한 가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.<ref name="Luniverse"></ref> |
===역할 기반 접근제어 방식=== | ===역할 기반 접근제어 방식=== | ||
| − | 역할 기반 | + | [[역할 기반 접근제어]](RBAC: role-based access control)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근제어를 하는 방식이다. 임의적 접근제어과 강제적 접근제어의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다. 권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근제어 방법으로 강제적 접근제어과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다. 사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.<ref name="Luniverse"></ref> 역할 기반 접근제어 방식의 핵심 개념은 권한을 역할과 연관시키고, 사용자들이 적절한 역할을 할당받도록 하는 것이다. 역할 기반 접근제어는 최소한의 보안 특권을 부여하는 보안 원리에 따라 유지되며, 그것은 어떤 사용자도 그 사람의 일을 수행하는 데 필요한 권한 이상을 가지지 않는다. 또한 한 조직이 슈퍼 유저의 능력들을 분리할 수 있게 해주고, 특정 개인들을 그들의 일의 필요에 따라 할당하기 위한 특별 사용자 계정 혹은 역할로 포장할 수 있게 해 준다. 따라서 다양한 보안 정책이 가능하다. 계정들은 [[보안]], [[네트워킹]], [[방화벽]], [[백업]], 그리고 시스템 운영과 같은 영역에서 특정 목적의 관리자를 위해 설정될 수 있다. 한 명의 강력한 관리자를 선호하고 사용자들이 그들 자신의 시스템 일부를 고칠 수 있기를 원하는 사이트는 [[상급 사용자]](Advanced User) 역할을 설정할 수 있다. 보안 측면에서 역할 기반 접근제어는 기술만이 아니라 산업에 적용되는 방식이기도 하다. 역할 기반 접근제어은 시스템 제어를 재할당하는 수단을 제공하지만, 구현을 결정하는 것은 그 조직이다. 역할 기반 접근제어 모델은 2004년에 ANSI 표준으로 등재되었으며, 모델의 설명·기능·스펙까지 표준문서에 정리되어 있어 개발자에게 좋은 가이드가 될 것이다. 표준에서는 역할 기반 접근제어를 핵심(Core) 역할 기반 접근제어 모델, 계층적(Hierarchical) 역할 기반 접근제어 모델, 한정된(Constrained) 역할 기반 접근제어 모델 세 가지 모델로 구분하고 있다.<ref name="접근제어를 이용하라"></ref> |
| − | + | ===속성 기반 접근제어 모델=== | |
| − | + | [[속성 기반 접근제어]](ABAC: Attribute Based Access Control)는 객체와 주체의 속성에 대한 조건을 기술하여 접근제어를 하는 방식이다. 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근제어를 수행한다. 예를 들어 파일 1에 접근하기 위해서는 사용자의 타입 속성에 'admin'이라는 태그가 달려 있어야 한다고 정의할 수 있다. 시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋은 것이 장점이지만, 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다. 속성을 일일이 수동으로 정의하기 힘들기 때문에 접근제어를 정의하기 위한 언어인 [[XACML]](eXtensible Access Control Markup Language)을 별도로 제공한다.<ref name="Luniverse"></ref> | |
| − | |||
| − | === | + | ===정보보호/보안=== |
| − | + | 보안 상 위험으로부터 제발 시설 및 환경을 보호하는 보안 대책이다. | |
| + | *'''인증 접근제어''': [[비인가자]] 또는 [[단말]]의 사용을 막는 접근 통제이다. | ||
| + | *'''패킷 접근제어''': 불필요 [[패킷]]을 걸러내거나 입출을 제한한다.<ref name="정보통신기술용어해설"> 〈[http://www.ktword.co.kr/abbr_view.php?nav=2&opt=&m_temp1=2250&id=767 Access Control 접근 제어, 접근 통제]〉, 《정보통신기술용어해설》, 2021-03-17 </ref> | ||
| − | ===접근제어 | + | ===매체 접근제어=== |
| − | 강제적 접근제어 방식은 사용자와 객체에게 부과된 보안 등급(Security Level)을 기반으로 접근 통제를 수행하며, 임의적 접근제어 방식은 객체에 부여된 허가, 거부 정책에 기반하여 객체에 대한 접근을 통제한다. 상용 환경에서는 정보의 변경 가능성이 불법 사용자에 의한 정보의 접근 가능성인 비밀성보다 더 중요한 관심사가 될 수 있다. 예를 들어 은행 업무에서 예금계좌의 정보변경이 예금계좌와 관련된 정보의 접근보다 더 위협적일 수 있다. 강제적 접근제어 방식은 등급화된 정보 기밀성을 위한 보안에 초점이 맞춰져 있고, 임의적 접근제어 방식은 접근권한이 객체의 소유자(owner)에 의해 임의로 변경될 수 있기 때문에 기업이나 정부 조직과 같이 무결성을 요구하는 상업적 응용의 정보 보안에는 부적절하다. 이러한 이유로 무결성 제어가 필요한 상용 환경에서는 역할 기반 접근제어 방식이 대안으로 주목받고 있다. 역할 기반 접근제어 방식은 필요할 때 강제적 접근제어 방식, 임의적 접근제어 방식과 함께 사용될 수 있는 접근 통제의 독자적인 요소이다. 이것은 세 가지 접근제어 방식에 의해 모두 허가되었을 경우에 허락된다.<ref name=" | + | [[매체 접근제어]]는 공유 링크 상에 대한 제어권을 어떤 장치가 가지는가에 대항 결정하는 방식이다.<ref name="정보통신기술용어해설"></ref> |
| + | |||
| + | === 비교 === | ||
| + | 강제적 접근제어 방식은 사용자와 객체에게 부과된 보안 등급(Security Level)을 기반으로 접근 통제를 수행하며, 임의적 접근제어 방식은 객체에 부여된 허가, 거부 정책에 기반하여 객체에 대한 접근을 통제한다. 상용 환경에서는 정보의 변경 가능성이 불법 사용자에 의한 정보의 접근 가능성인 비밀성보다 더 중요한 관심사가 될 수 있다. 예를 들어 은행 업무에서 예금계좌의 정보변경이 예금계좌와 관련된 정보의 접근보다 더 위협적일 수 있다. 강제적 접근제어 방식은 등급화된 정보 기밀성을 위한 보안에 초점이 맞춰져 있고, 임의적 접근제어 방식은 접근권한이 객체의 소유자(owner)에 의해 임의로 변경될 수 있기 때문에 기업이나 정부 조직과 같이 무결성을 요구하는 상업적 응용의 정보 보안에는 부적절하다. 이러한 이유로 무결성 제어가 필요한 상용 환경에서는 역할 기반 접근제어 방식이 대안으로 주목받고 있다. 역할 기반 접근제어 방식은 필요할 때 강제적 접근제어 방식, 임의적 접근제어 방식과 함께 사용될 수 있는 접근 통제의 독자적인 요소이다. 이것은 세 가지 접근제어 방식에 의해 모두 허가되었을 경우에 허락된다.<ref name="접근제어를 이용하라"></ref> | ||
==인증 vs 인가== | ==인증 vs 인가== | ||
| − | [[인증]]과 [[인가]]를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다. | + | [[인증]]과 [[인가]]를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다. 인증은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가에 해당한다. 당연하게도 인가를 수행하기 위해서는 인증이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.<ref name="Luniverse"></ref> |
| + | ==접근통제== | ||
| + | [[접근통제]]는 조직의 민감한 정보들이 권한 없는 사용자에 의해 외부로 누출, 변조, 파괴될 위험성을 차단하기 위한 보안 기술이다. 비인가자에 의한 자원 접근을 차단하고 정당한 사용자가 허가되지 않은 방법으로, 자원에 접근하는 것을 제한함으로써 정당한 사용자가 허가된 방식만으로 자원에 접근하는 것이다. 자원에 대한 비인가된 접근을 감시, 접근을 요구하는 이용자를 식별, 사용자의 접근 요구가 정당한 것인지를 확인, 기록하는 행위를 포함한다. 보안 정책에 근거하여 접근을 승인하거나 거부함으로써 비인가자에 의한 불법적인 자원 접근 및 파괴를 예방하는 행동이다. 또한, 접근 통제 기능을 수행하는 하드웨어, 소프트웨어 및 행정적인 관리를 총칭한다. 주체와 객체간의 정보의 흐름, 주체는 능동적인 성질을 갖고 객체는 수동적인 성질을 가진다.<ref name="어리버리"> 어리버리, 〈[https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=nologout&logNo=220957149200 접근 통제 정의, 절차, 원칙]〉, 《네이버 블로그》, 2017-03-13 </ref> | ||
| + | |||
| + | ===절차=== | ||
| + | 식별과 인증, 인가(접근제어 정책, 메커니즘)의 절차를 가진다. | ||
| + | |||
| + | #식별: 아이디 입력 | ||
| + | ##시스템에게 주체의 식별자를 요청하는 과정으로, 즉 본인이 누구라는 것을 밝히는 것이다. | ||
| + | ##각 시스템 사용자들은 시스템이 식별할 수 있는 유일한 식별자 혹은 아이디를 갖는다. | ||
| + | ##개인 식별자는 유일해야 하며, 공유되어서는 안된다. | ||
| + | ##스스로를 확인시키기 위해 정보를 공급하는 주체의 활동이다. | ||
| + | ##사용자명, 계정 번호, 메모리 카드 | ||
| + | #인증: 패스워드 입력 | ||
| + | ##임의의 정보에 접근할 수 있는 주체의 능력이나 자격을 검증하는 것으로 사용자의 신분과 정보의 출처를 확인하는 절차로 [[지식 기반]], [[소유 기반]], [[생체 기반]]의 인증 방식이 있다. 이는 정보 보안 관리를 말한다. | ||
| + | ##전자서명 생성정보가 가입자에세 유일하게 속한다는 사실을 확인하고, 이를 증명하는 행위이다. | ||
| + | ##어떤 사람이나 사물이 실제로 그 자신인지를 판단하는 과정이다.<br>예시: 패스워드, PIN, 토큰, 스마트 카드, 생체 인증 등 | ||
| + | #인가: 로그인 완료 및 [[ACL]]이나 [[보안 등급]]에 따른 주체의 활동 보장 | ||
| + | ##사용자, 프로그램, 프로세스 등 자원에 대한 허가 권한이다. | ||
| + | ##전송 주체가 되는 송,수신자가 정당한지 확인, 정당한 권한을 가진 사람인가를 확인하는 절차이다.<ref name="어리버리"></ref> | ||
| + | |||
| + | ===원칙=== | ||
| + | #최소 권한 정책: 시스템 주체들에 대해 권한 부여 시 자신들의 업무에 필요한 최소한의 권한만 부여한다.<br>예시: 스크립트나 바이너리는 루트 계정만 주로 이용하므로, 기타 계정에 있는 권한을 제거하거나, 웹 서버를 실행하는 아파치 계정은 웹 서버 실행 권한을 주고 원격 로그인이 필요 없으므로 쉘 사용 권한을 제거한다. | ||
| + | #직무 분리: 업무 발생부터 승인, 수정, 확인, 완료 등이 처음부터 끝까지 한 사람에 의해 처리될 수 없게 하는 보안 정책이다. | ||
| + | #최대 권한 정책: 데이터 공유의 장점을 증대시키기 위해 최대 가용성 원리를 기반으로 하는 정책이다. | ||
| + | #개체 기반 정책: 어떤 주체가 어떤 행동을 할 수 있는지 각 타겟 별로 목록을 표현한다. | ||
| + | #그룹 기반 정책: 다수의 사용자가 하나의 타겟에 대해 동일한 권한을 부여받는 정책이다.<ref name="어리버리"></ref> | ||
{{각주}} | {{각주}} | ||
== 참고자료 == | == 참고자료 == | ||
| + | * Luniverse 공식 홈페이지 - https://www.luniverse.io/2021/02/26/access-control-models/?lang=ko | ||
* 〈[https://terms.naver.com/entry.naver?docId=3431851&cid=58437&categoryId=58437 접근 제어]〉, 《네이버 지식백과》 | * 〈[https://terms.naver.com/entry.naver?docId=3431851&cid=58437&categoryId=58437 접근 제어]〉, 《네이버 지식백과》 | ||
| − | * 〈[https://terms.naver.com/entry.naver?docId=3432527&cid=58445&categoryId=58445 | + | * 〈[https://terms.naver.com/entry.naver?docId=3432527&cid=58445&categoryId=58445 접근제어를 이용하라]〉, 《네이버 지식백과》 |
| − | * | + | * 〈[http://www.ktword.co.kr/abbr_view.php?nav=2&opt=&m_temp1=2250&id=767 Access Control 접근 제어, 접근 통제]〉, 《정보통신기술용어해설》, 2021-03-17 |
| + | * 어리버리, 〈[https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=nologout&logNo=220957149200 접근 통제 정의, 절차, 원칙]〉, 《네이버 블로그》, 2017-03-13 | ||
| + | |||
== 같이 보기 == | == 같이 보기 == | ||
* [[접근]] | * [[접근]] | ||
| + | * [[제어]] | ||
| + | * [[접근권한]] | ||
| + | * [[접근차단]] | ||
* [[권한]] | * [[권한]] | ||
* [[보안]] | * [[보안]] | ||
{{보안|검토 필요}} | {{보안|검토 필요}} | ||
2021년 10월 16일 (토) 19:27 기준 최신판
접근제어(access control)는 적절한 권한을 가진 인가자만 특정 시스템이나 정보에 접근할 수 있도록 제어하는 것이다. 접근제어는 시스템의 보안 수준을 갖추기 위한 가장 기본적 방법이다.[1]
목차
개요[편집]
시스템 및 네트워크에 대한 접근제어의 가장 기본적인 수단은 아이피(IP)와 서비스 포트이다. 운영체제, 데이터베이스, 응용프로그램 및 네트워크 장비에서 각각 접근제어된다.[1] 데이터 저장장치에 접근하는 권한을 정의하거나 제한하고, 권한 있는 자 및 프로그램, 기타 시스템만이 시스템 자원정보에 접근할 수 있도록 제한하며, 사용자 요청에 따라 시스템 자원을 지정하는 자원제어기의 기능을 수행한다.[2] 웹 서비스나 클라우드 서비스 등을 개발하면서 가장 중요하게 고려해야 하는 부분 중 하나는 바로 각 사용자들이 서비스의 어느 부분까지 사용할 수 있고, 어느 부분은 사용할 수 없는지를 제어하는 것이다. 이것은 보안에 매우 밀접한 관련이 있기 때문에 올바르게 접근제어를 구현하는 것은 매우 중요하다. 서비스 개발자는 해당 서비스를 통해 어떤 기능을 제공할 것인지에 대한 고민뿐만 아니라, 서로 다른 사용자들의 서비스 접근 권한을 어떻게 제어할 것인지도 고민해야 한다. 그러기 위해서는 접근제어 모델의 종류와 그 구현 방법들을 아는 것이 매우 중요하다. 접근제어 모델에서 인가를 받으려는 사용자를 주체(Subject)라고 한다. 주체는 특정 사용자 개인이 될 수도 있고, 특정 사용자 그룹이 될 수도 있으며, 또는 전체 사용자를 가리킬 수도 있다. 객체(Object)는 사용자가 접근하고자 하는 서비스나 자원, 정보와 같은 접근 대상을 말한다. 네이버 카페의 게시판이 객체의 예이다. 권한(Permission)은 객체에 허용된 주체가 수행할 수 있는 행위의 목록을 말한다. 보통 권한에는 읽기, 쓰기, 생성, 삭제, 실행, 검색 등과 같은 권한이 존재할 수 있다. 결국 접근제어라는 것은 객체에 접근하고자 하는 주체가 해당 객체에 접근할 수 있는 권한을 가지고 있는지 판단하는 것이다.[3]
종류[편집]
강제적 접근제어[편집]
강제적 접근제어(MAC: Mandatory Access Control)는 어떤 주체가 특정 객체에 접근할 때, 양자의 보안 레벨에 기초하여 낮은 수준의 주체가 높은 수준의 객체정보에 접근하는 것을 강제적으로 제한하는 방법이다. 컴퓨터의 모든 자원(중앙처리장치, 메모리, 프린터, 모니터, 저장장치 등)을 객체로 하고, 그 객체를 사용하고자 하는 것을 주체(사용자 및 모든 프로세스)로 설정하여, 각 객체 파일의 비밀 등급과 각 주체의 허가 등급을 부여한다. 이후 주체가 객체를 읽거나 기록하거나 실행시키고자 할 때마다 그 주체가 그 객체에 대한 권한을 가지고 있는지를 확인하는 방식이다.[2] 대표적인 예로 네이버㈜나 다음카페에서는 회원 등급에 따라 접근할 수 있는 게시판과 접근할 수 없는 게시판이 있는 것처럼 말이다. 각 회원(주체)마다 부여된 보안 등급이 있고, 각 게시판(객체)마다 접근할 수 있는 허용 등급이 정해져 있기 때문에 객체와 주체 사이의 권한 등급을 직접 비교하여 접근 허용 여부를 결정하는 것이다. 강제적 접근제어 모델에서는 높은 보안 수준을 요구하는 정보는 낮은 보안 수준을 가진 주체가 접근할 수 없다. 시스템 관리자가 이러한 권한 수준을 제어하며, 사용자들은 어떠한 접근 권한 수준도 설정할 수 없다. 다시 말해, 객체의 소유자라고 할지라도 그 객체에 접근할 수 있는 보안 등급을 부여받지 못하면 그 객체에 접근할 수 없다. 이러한 강제적 접근제어 모델은 중앙 집권적인 관리자에 의해 제어되기 때문에 보안성이 높은 편이어서 주로 군(military)이나 방화벽처럼 강력한 보안이 필요한 곳에서 주로 사용한다. 하지만 권한 관리 기능이 단순하고 제한적이어서 주체별로 접근제어를 다르게 적용할 수 없으며, 모든 주체와 객체에 일일이 허용 등급 설정을 해주어야 하므로 설정이 복잡하다는 단점이 있다.[3]
임의적 접근제어[편집]
임의적 접근제어(DAC: Discretionary Access Control)는 자원의 소유자 혹은 관리자가 보안 관리자의 개입 없이 자율적 판단에 따라 접근 권한을 다른 사용자에게 부여하는 기법을 말한다. 따라서 자원의 보호보다는 자원의 공동 활용이 더 중요시되는 환경에 적합하며, 기업 환경에는 자원의 유출 가능성을 내포하고 있다. 임의적 접근제어는 특별한 사용자나 그들이 소속되어 있는 그룹들의 식별자(ID)에 근거하여 객체에 대한 접근을 제공한다. 접근제어는 객체의 소유자에 의하여 임의적으로 이루어진다. 그러므로 특정 객체에 대한 접근 허가를 가지고 있는 한 주체는 임의의 다른 주체에게 자신의 허가를 넘겨줄 수 있다. 즉 추가적인 접근제어는 그 사용자에게 일임하는 방식이다. 따라서 임의적 접근제어 방식은 하나의 주체 대 객체 단위로 접근 제한을 설정할 수 있고, 이러한 접근 제한은 모든 주체 및 객체들 간에 동일하지 않다. 즉 한 주체가 특정한 비밀 등급의 한 객체에 대한 접근을 허가하지 않는 임의적 접근제어 정책을 수립해도 그 주체가 그러한 비밀 등급을 갖는 다른 객체들에게 접근하는 것은 방지할 수 없다.[2] 대표적인 예는 전통적인 유닉스나 윈도우 등의 운영체제에서 각 파일이나 디렉토리에 대해 접근제어를 하는 방식이다. 유닉스에서 각 파일은 파일의 소유자가 그 파일에 대한 접근제어를 설정할 수 있다. 여기서 임의적(Discretionary)이라는 말은 객체 소유자의 판단에 따라 권한을 줄 수 있다는 뜻이다. 대체적으로 구현이 용이하고 사용이 간단하다는 장점이 있다. 또한 객체별로 세분화된 접근제어가 가능해 융통성이 넓다. 하지만 소유자 임의로 접근을 허용할 수 있어 강제적 접근제어에 비해 상대적으로 보안성이 취약하고 시스템 차원의 일관성 있는 접근제어가 어렵다. 또한 접근제어를 신분에 의존하다 보니 다른 주체의 신분을 도용한 경우 중대한 결함이 발생할 수 있다. 임의적 접근제어를 구현하는 방법은 여러 가지가 있지만, 대표적으로 다음 4가지의 구현 방법이 있다.[3]
접근제어 행렬[편집]
접근제어 행렬(Access Control Matrix)은 전체 주체와 전체 객체에 대한 권한 관계를 2차원 배열로 관리하는 구현 방법이다. 각 행은 각 주체를 나타내며 각 열은 각 객체를 나타낸다. 예를 들어 사용자 A는 파일 1에 대해 소유하고 있으며 따라서 읽기와 쓰기가 가능하다. 사용자 B는 파일 1에 대해 읽기만 가능하며, 파일 3에 대해서는 쓰기도 가능하다. 이처럼 주체와 객체를 알고 있으면 어떤 권한을 가지고 있는지 바로 알아낼 수 있지만, 주체의 수나 객체의 수가 많아지면 쓸데없이 사용되는 메모리 공간이 많아지는 단점을 가지고 있다.[3]
접근제어 목록[편집]
접근제어 목록(ACLs: Access Control List)은 가장 많이 사용하는 구현 방법으로 위 그림에서와 같이 각 객체에 대해 권한을 가지고 있는 주체를 리스트 형태로 관리하는 구현 방법이다. 위 그림에서 파일 1은 사용자 A, B, C가 권한을 가지고 있으며, 사용자 A는 파일 1을 소유했고 따라서 읽기와 쓰기가 가능하다. 사용자 B는 읽기만 가능하며 사용자 C는 읽기와 쓰기가 가능하다. 이처럼 각 객체에 대해 권한을 부여 받은 관리자 목록만 관리하기 때문에 낭비되는 메모리가 적지만, 어느 한 객체에 대해 많은 사용자가 권한을 부여받았을 경우에는 리스트가 길어져 탐색이 오래 걸리는 단점이 있다.[3]
가용성 티켓[편집]
가용성 티켓(Capability Tickets)은 접근제어 목록과는 반대로 각 주체에 대해 접근 가능한 객체를 리스트 형태로 관리하는 구현 방법이다. 예를 들어 사용자 C는 파일 1에 대해 읽기와 쓰기가 가능하며 파일 2에 대해서는 읽기만, 파일 4에 대해서는 소유하고 있기 때문에 읽기와 쓰기가 가능하다. 접근제어 목록 구현 방법과 비슷하게 메모리 낭비가 적지만, 한 사용자에 대해 접근할 수 있는 객체가 많아지면 탐색이 오래 걸릴 수 있다.[3]
권한 테이블[편집]
권한 테이블(Permission Table)은 관계형 데이터베이스의 테이블을 이용하여 주체와 객체 목록과 권한 목록을 관리하는 구현 방법이다. 테이블에는 주체 테이블, 객체 테이블, 권한 테이블이 있다. 권한 테이블의 한 레코드에는 하나의 자원에 대한 한 주체의 한 가지 접근 권한이 명시된다. 관계형 데이터베이스의 인덱스 기능을 이용하면 한 사용자에 대한 객체 접근 권한을 빠르게 조회할 수 있는 장점이 있다.[3]
역할 기반 접근제어 방식[편집]
역할 기반 접근제어(RBAC: role-based access control)는 권한을 사용자 개인이 아닌 역할 그룹에 부여하고, 사용자에게 역할을 할당하여 접근제어를 하는 방식이다. 임의적 접근제어과 강제적 접근제어의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다. 이는 사용자 정보는 자주 바뀌어도 역할 정보는 자주 바뀌지 않는다는 것에 착안한 모델이다. 실제로 많은 서비스들이 회원 가입과 탈퇴는 빈번하게 일어나지만, 그 회원들이 부여받을 수 있는 역할의 종류와 역할과 객체 사이의 권한 관계는 잘 변하지 않는다. 권한 관리자는 다수의 사용자에 대해 일일이 접근 권한을 관리하지 않아도 되고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어든다. 일반적으로 직무를 기반으로 하는 서비스들에서 많이 사용되는 접근제어 방법으로 강제적 접근제어과 비슷하게 각 주체에 허용된 접근 수준(Clearance)과 객체에 부여된 허용등급(Classification)에 근거하여 접근제어가 이루어진다. 다양한 권한 요소를 고려하다 보면 권한 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있으므로 역할을 개수를 적절히 유지하는 것이 중요하다. 사용자와 역할 사이의 관계는 보통 다대다(N:M) 관계이기 때문에 한 사용자가 여러 개의 역할을 부여받을 수 있다. 또한 역할과 객체 사이의 관계도 다대다(N:M) 관계이기 때문에 한 역할이 여러 객체에 대한 접근 권한을 부여받을 수 있다.[3] 역할 기반 접근제어 방식의 핵심 개념은 권한을 역할과 연관시키고, 사용자들이 적절한 역할을 할당받도록 하는 것이다. 역할 기반 접근제어는 최소한의 보안 특권을 부여하는 보안 원리에 따라 유지되며, 그것은 어떤 사용자도 그 사람의 일을 수행하는 데 필요한 권한 이상을 가지지 않는다. 또한 한 조직이 슈퍼 유저의 능력들을 분리할 수 있게 해주고, 특정 개인들을 그들의 일의 필요에 따라 할당하기 위한 특별 사용자 계정 혹은 역할로 포장할 수 있게 해 준다. 따라서 다양한 보안 정책이 가능하다. 계정들은 보안, 네트워킹, 방화벽, 백업, 그리고 시스템 운영과 같은 영역에서 특정 목적의 관리자를 위해 설정될 수 있다. 한 명의 강력한 관리자를 선호하고 사용자들이 그들 자신의 시스템 일부를 고칠 수 있기를 원하는 사이트는 상급 사용자(Advanced User) 역할을 설정할 수 있다. 보안 측면에서 역할 기반 접근제어는 기술만이 아니라 산업에 적용되는 방식이기도 하다. 역할 기반 접근제어은 시스템 제어를 재할당하는 수단을 제공하지만, 구현을 결정하는 것은 그 조직이다. 역할 기반 접근제어 모델은 2004년에 ANSI 표준으로 등재되었으며, 모델의 설명·기능·스펙까지 표준문서에 정리되어 있어 개발자에게 좋은 가이드가 될 것이다. 표준에서는 역할 기반 접근제어를 핵심(Core) 역할 기반 접근제어 모델, 계층적(Hierarchical) 역할 기반 접근제어 모델, 한정된(Constrained) 역할 기반 접근제어 모델 세 가지 모델로 구분하고 있다.[2]
속성 기반 접근제어 모델[편집]
속성 기반 접근제어(ABAC: Attribute Based Access Control)는 객체와 주체의 속성에 대한 조건을 기술하여 접근제어를 하는 방식이다. 어떤 객체에 접근하기 위해 만족시켜야 하는 속성에 대해 정의하고, 그 객체에 접근하려는 주체가 그 속성을 가지고 있는지를 검사하여 접근제어를 수행한다. 예를 들어 파일 1에 접근하기 위해서는 사용자의 타입 속성에 'admin'이라는 태그가 달려 있어야 한다고 정의할 수 있다. 시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋은 것이 장점이지만, 큰 규모의 시스템에서는 일일이 속성을 적용하기 어렵고 각 객체 접근마다 복잡한 속성 조건을 계산해야 하기 때문에 성능이 다소 느리다. 속성을 일일이 수동으로 정의하기 힘들기 때문에 접근제어를 정의하기 위한 언어인 XACML(eXtensible Access Control Markup Language)을 별도로 제공한다.[3]
정보보호/보안[편집]
보안 상 위험으로부터 제발 시설 및 환경을 보호하는 보안 대책이다.
매체 접근제어[편집]
매체 접근제어는 공유 링크 상에 대한 제어권을 어떤 장치가 가지는가에 대항 결정하는 방식이다.[4]
비교[편집]
강제적 접근제어 방식은 사용자와 객체에게 부과된 보안 등급(Security Level)을 기반으로 접근 통제를 수행하며, 임의적 접근제어 방식은 객체에 부여된 허가, 거부 정책에 기반하여 객체에 대한 접근을 통제한다. 상용 환경에서는 정보의 변경 가능성이 불법 사용자에 의한 정보의 접근 가능성인 비밀성보다 더 중요한 관심사가 될 수 있다. 예를 들어 은행 업무에서 예금계좌의 정보변경이 예금계좌와 관련된 정보의 접근보다 더 위협적일 수 있다. 강제적 접근제어 방식은 등급화된 정보 기밀성을 위한 보안에 초점이 맞춰져 있고, 임의적 접근제어 방식은 접근권한이 객체의 소유자(owner)에 의해 임의로 변경될 수 있기 때문에 기업이나 정부 조직과 같이 무결성을 요구하는 상업적 응용의 정보 보안에는 부적절하다. 이러한 이유로 무결성 제어가 필요한 상용 환경에서는 역할 기반 접근제어 방식이 대안으로 주목받고 있다. 역할 기반 접근제어 방식은 필요할 때 강제적 접근제어 방식, 임의적 접근제어 방식과 함께 사용될 수 있는 접근 통제의 독자적인 요소이다. 이것은 세 가지 접근제어 방식에 의해 모두 허가되었을 경우에 허락된다.[2]
인증 vs 인가[편집]
인증과 인가를 종종 같은 의미로 사용하는 경우가 많다. 하지만 인증(Authentication)과 인가(Authorization)는 엄연히 다른 개념으로 둘의 차이점을 명확히 알고 있어야 한다. 인증은 사용자가 누구인지 판별하는 것을 말한다. 보통 서비스에 로그인하는 과정이 이에 해당한다. 그 사용자가 서비스에 회원 가입을 한 사용자이며 그 사용자가 누구인지 판별하는 것이다. 인가는 어떤 사용자가 어떤 행위(action)을 수행할 권한을 가지고 있는지를 판별하는 것을 말한다. 예를 들어 네이버 카페 같은 곳에 가입을 하면 회원 등급에 따라 특정 게시판에 글을 읽을 수는 있지만 쓸 수는 없는 경우가 있는데 이러한 경우가 바로 인가에 해당한다. 당연하게도 인가를 수행하기 위해서는 인증이 선행되어야 한다. 먼저 그 사용자가 누구인지 판별이 되어야 그 사용자에 대한 권한을 판별할 수 있기 때문이다.[3]
접근통제[편집]
접근통제는 조직의 민감한 정보들이 권한 없는 사용자에 의해 외부로 누출, 변조, 파괴될 위험성을 차단하기 위한 보안 기술이다. 비인가자에 의한 자원 접근을 차단하고 정당한 사용자가 허가되지 않은 방법으로, 자원에 접근하는 것을 제한함으로써 정당한 사용자가 허가된 방식만으로 자원에 접근하는 것이다. 자원에 대한 비인가된 접근을 감시, 접근을 요구하는 이용자를 식별, 사용자의 접근 요구가 정당한 것인지를 확인, 기록하는 행위를 포함한다. 보안 정책에 근거하여 접근을 승인하거나 거부함으로써 비인가자에 의한 불법적인 자원 접근 및 파괴를 예방하는 행동이다. 또한, 접근 통제 기능을 수행하는 하드웨어, 소프트웨어 및 행정적인 관리를 총칭한다. 주체와 객체간의 정보의 흐름, 주체는 능동적인 성질을 갖고 객체는 수동적인 성질을 가진다.[5]
절차[편집]
식별과 인증, 인가(접근제어 정책, 메커니즘)의 절차를 가진다.
- 식별: 아이디 입력
- 시스템에게 주체의 식별자를 요청하는 과정으로, 즉 본인이 누구라는 것을 밝히는 것이다.
- 각 시스템 사용자들은 시스템이 식별할 수 있는 유일한 식별자 혹은 아이디를 갖는다.
- 개인 식별자는 유일해야 하며, 공유되어서는 안된다.
- 스스로를 확인시키기 위해 정보를 공급하는 주체의 활동이다.
- 사용자명, 계정 번호, 메모리 카드
- 인증: 패스워드 입력
- 인가: 로그인 완료 및 ACL이나 보안 등급에 따른 주체의 활동 보장
- 사용자, 프로그램, 프로세스 등 자원에 대한 허가 권한이다.
- 전송 주체가 되는 송,수신자가 정당한지 확인, 정당한 권한을 가진 사람인가를 확인하는 절차이다.[5]
원칙[편집]
- 최소 권한 정책: 시스템 주체들에 대해 권한 부여 시 자신들의 업무에 필요한 최소한의 권한만 부여한다.
예시: 스크립트나 바이너리는 루트 계정만 주로 이용하므로, 기타 계정에 있는 권한을 제거하거나, 웹 서버를 실행하는 아파치 계정은 웹 서버 실행 권한을 주고 원격 로그인이 필요 없으므로 쉘 사용 권한을 제거한다. - 직무 분리: 업무 발생부터 승인, 수정, 확인, 완료 등이 처음부터 끝까지 한 사람에 의해 처리될 수 없게 하는 보안 정책이다.
- 최대 권한 정책: 데이터 공유의 장점을 증대시키기 위해 최대 가용성 원리를 기반으로 하는 정책이다.
- 개체 기반 정책: 어떤 주체가 어떤 행동을 할 수 있는지 각 타겟 별로 목록을 표현한다.
- 그룹 기반 정책: 다수의 사용자가 하나의 타겟에 대해 동일한 권한을 부여받는 정책이다.[5]
각주[편집]
- ↑ 1.0 1.1 〈접근 제어〉, 《네이버 지식백과》
- ↑ 2.0 2.1 2.2 2.3 2.4 〈접근제어를 이용하라〉, 《네이버 지식백과》
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Luniverse 공식 홈페이지 - https://www.luniverse.io/2021/02/26/access-control-models/?lang=ko
- ↑ 4.0 4.1 〈Access Control 접근 제어, 접근 통제〉, 《정보통신기술용어해설》, 2021-03-17
- ↑ 5.0 5.1 5.2 어리버리, 〈접근 통제 정의, 절차, 원칙〉, 《네이버 블로그》, 2017-03-13
참고자료[편집]
- Luniverse 공식 홈페이지 - https://www.luniverse.io/2021/02/26/access-control-models/?lang=ko
- 〈접근 제어〉, 《네이버 지식백과》
- 〈접근제어를 이용하라〉, 《네이버 지식백과》
- 〈Access Control 접근 제어, 접근 통제〉, 《정보통신기술용어해설》, 2021-03-17
- 어리버리, 〈접근 통제 정의, 절차, 원칙〉, 《네이버 블로그》, 2017-03-13
같이 보기[편집]
