RBAC과 ABAC

안녕하세요 항상 웃음이 나는 픠식팀 입니다. :)

이번에는 RBAC과 ABAC에 대해서 한 번 알아보겠습니다.

 

RBAC(Role-Based Access Control)

역할 기반 접근 제어는 컴퓨터 시스템에서 권한이 있는 사용자들에게 시스템 접근을 통제하는 방법 중 하나 입니다.

권한을 사용자나, 사용자가 속한 그룹에다 역할을 할당하여 접근을 제어하는 방식을 말하는데 즉 사용자가 해당하는 역할에 따라서 자원에 대한 접근을 제어한다.

임의적 접근 제어(DAC)와 강제적 접근 제어(MAC)의 단점을 보완한 방식으로써 사용자에게 정적 혹은 동적으로 역할 그룹을 할당할 수 있다.

예를 들어서 사용자에게 admin 역할을 할당 해주게 되면 해당 사용자는 관리자의 권한을 가지게되어서 관리자가 할 수 있는 모든 행동이 가능하게 됩니다.

반대로 viewer라는 역할을 사용자에게 할당 해주게 된다면 해당 사용자는 단순히 볼 수 있는 행동만 가능하게 됩니다.

장점

역할이라는 것은 정의한다면 해당 역할이 어떠한 권한을 가져야 하는지 누구나 쉽고 빠르게 알 수 있습니다. 필요한 담당자를 정의하면 해당 담당자는 해야할 일과 가져야하는 권한을 함께 정의할 수 있게 된다.

역할은 어떤 사람을 지칭하는 것이 아니기 때문에 역할을 부여하거나 변경하는 것만으로도 유연하고 효율적으로 권한을 부여하거나 회수할 수 있다.

그렇기 때문에 역할 기반 접근제어는 유연하고 직관적이며 효율적으로 통제 할 수 있고 적절한 역할만 부여해주면 되기 때문에 권한 관리 부담이 줄어들게 된다.

사용자와 역할 사이의 관계는 보통 다대다(N:M)관계이기 때문에 한 사용자는 여러개의 역할을 부여 받을 수 있습니다.

단점

역할에 따른 권한 정책을 정의하기 때문에 정책이 현실과 딱 맞아 떨어지지 않는 경우도 생길 수 있고 여러 역할에 따라 중복되는 권한이 있을 수 있고 비슷한 일이지만 약간의 다른일을 해야 한다면 별도의 역할을 또 만들어야 한다는 단점

이런식으로 역할을 지정하는 권한에 대해서 세밀하게 관리하기 어렵고 반대로 너무 큰 단위로 설계하게 되면은 보안에서는 최소한의 권한이 가장 중요한데 필요 이상의 많은 권한을 가지게 되어 보안이 취약해지게 됩니다.

 

앞에서 말한 다양한 권한에 대해서 고려하다 보면 권한의 요소, 조건이 늘어날 때마다 역할의 개수가 과도하게 늘어날 수 있는 단점이 있기 때문에 역할을 적절히 유지하는 것도 중요하다

ABAC(Attribute-Based Access Control)

속성 기반 접근 제어는 속성을 기반으로 권한을 정의하는 권한 부여 전략입니다.

객체에 접근하기 위해 속성에 대해 정의하고 그 객체에 접근 하려는 주체가 그 속성을 가지고 있는지를 검사하고 접근 제어를 수행합니다.

속성은 주체의 이름, 자원에 대한 유형 등 다양하게 있으며 지원하는 종류는 서비스 혹은 플랫폼에 따라 다릅니다.

장점

세분화된 권한을 사용할 수 있고 시스템의 다양한 요소를 반영할 수 있기 때문에 표현력과 유연성이 좋다

단점

큰 규모의 시스템에서 일일히 속성을 적용하게 되면 많은 시간이 걸리게 되고 복작한 속성 조건을 계산 해야하기 때문에 성능이 다소 느릴 수 있습니다.

 

RBAC과 ABAC을 AWS에서 쉽게 접해볼 수 있고 사용해볼 수 있습니다.

AWS로 전반적인 예시를 들게 되면은

IAM을 통해서 다양한 직무에 따라서 서로 다른 정책을 생성하여서 RBAC을 구현하고 IAM 사용자, 사용자 그룹에 연결하여 사용할 수 있습니다. 이런 기존 RBAC 모델을 사용하게 되면 직원이 새 리소스를 추가할 때마다 해당 리소스에 액세스할 수 있도록 정책을 업데이트 해야한다는 단점이 있습니다. 

하지만 AWS에서는 ABAC을 태그를 이용해서 이용하게 되면은 앞서 말한 RBAC 보다 다양한 이점등을 제공합니다.

권한은 혁신적으로 확장할 수 있고 필요한 정책 수가 적어지게 됩니다.

팀은 빠르게 변화하고 성장할 수 있게 되며, 세분화된 권한을 사용할 수 있습니다.

 

다음 포스팅때는 다른 주제로 찾아뵙겠습니다.~~ 다음에 만나요~