액세스 제어란 무엇인가요?

게이트 및 잠금 장치가 있는 출입문과 같은 물리적 액세스 제어는 물리적 위치에 대한 접근을 제어합니다. 침입 탐지 및 방지 시스템과 같은 논리적 액세스 제어는 컴퓨터 시스템에 대한 액세스를 제어합니다. 이 문서에서는 주로 논리적 액세스 제어를 다룹니다.

액세스 관리 용어에서 액세스가 필요한 엔티티는 "주체(subject)"라고 합니다. 이러한 주체에는 사람 사용자뿐 아니라 봇, 앱, 자동화된 워크로드 및 AI 에이전트와 같은 비인간 ID도 포함됩니다.

실제로 클라우드 인프라 확산, DevOps의 성장 및 고급 인공지능 툴 도입에 힘입어 후자의 범주가 급격히 증가하면서 비인간 사용자는 액세스 제어의 핵심 관리 대상으로 부상하고 있습니다.

주체가 액세스해야 하는 대상인 애플리케이션 프로그래밍 인터페이스(API), 운영 체제 설정 및 클라우드 데이터베이스 내 민감한 정보와 같은 요소는 "객체(object)"라고 합니다.

기업 네트워크에서 액세스 제어를 구현하는 작업은 일반적으로 시스템 내 각 주체의 액세스 권한을 정의하는 액세스 제어 정책을 수립하고 시행하는 과정입니다. 액세스 제어 정책은 주체가 문서와 같은 객체에 액세스할 수 있는지 여부와 해당 객체에 대해 어떤 권한을 가지는지를 정의합니다(예: 읽기 전용, 읽기 및 쓰기, 전체 관리자 권한).

액세스 제어는 ID 보안의 핵심 요소입니다.예를 들어 제로 트러스트 네트워크 아키텍처는 강력한 액세스 제어를 기반으로 승인되지 않은 액세스를 방지하는 동시에 승인된 사용자의 액세스는 간소화합니다.ID가 새로운 경계 역할을 하는 클라우드 네이티브 네트워크에서 액세스 제어는 전반적인 사이버 보안 운영에 매우 중요합니다.

동시에 액세스 제어는 많은 시스템에서 취약 지점이기도 합니다.손상된 액세스 제어는 가장 심각한 웹 애플리케이션 보안 위험 목록인 OWASP Top 10에서 1위를 차지하고 있습니다.또한 IBM® X-Force Threat Intelligence Index에 따르면 위협 행위자가 유효한 사용자 계정을 탈취해 액세스 권한을 악용하는 ID 기반 공격은 전체 침해 사고의 거의 3분의 1을 차지합니다.

따라서 액세스 관리가 조직의 보안 상태에서 핵심 역할을 수행하고 있음에도 불구하고 현재 데이터는 여전히 개선의 여지가 있음을 보여줍니다.

액세스 제어는 일반적으로 정책 기반으로 운영됩니다.시스템 관리자는 필요한 경우 다른 이해관계자와 협력해 주체의 권한을 상세히 정의하는 액세스 제어 정책을 작성합니다. ID 및 액세스 관리(IAM) 및 권한 액세스 관리(PAM) 플랫폼과 같은 액세스 제어 시스템은 이러한 보안 정책을 자동으로 시행합니다.

액세스 제어 시스템은 인증 및 권한 부여의 두 단계 프로세스를 사용해 검증된 주체만 객체에 액세스할 수 있도록 하고, 해당 주체가 승인된 방식으로만 작업을 수행할 수 있도록 지원합니다.

액세스 정책은 주체가 액세스할 수 있는 객체를 정의합니다. 예를 들어 개발자가 조회할 수 있는 S3 버킷, 애플리케이션이 호출할 수 있는 API 및 대규모 언어 모델(LLM)이 수집할 수 있는 데이터 세트 등이 이에 해당합니다.또한 액세스 정책은 개별 사용자가 객체에 대해 어떤 작업을 수행할 수 있는지도 정의합니다. LLM이 데이터 세트에 데이터를 기록할 수 있는가? 개발자가 S3 버킷 설정을 변경할 수 있는가?액세스 정책은 이러한 질문에 대한 답을 결정합니다.

정책은 시스템 및 리소스마다 다를 수밖에 없지만 대부분의 조직은 역할 기반 액세스 제어(RBAC) 또는 속성 기반 액세스 제어(ABAC)와 같은 확립된 액세스 제어 모델을 따릅니다.(자세한 내용은 "액세스 제어 유형"을 참조하세요.)

모델과 관계없이 많은 조직의 액세스 정책은 최소 권한 원칙을 따릅니다. 이는 사용자가 업무 수행에 필요한 최소 수준의 권한만 가져야 하며 작업이 끝나면 권한을 회수해야 한다는 원칙입니다.

액세스 정책은 여러 가지 방식으로 시스템 내에 "저장"될 수 있습니다.

• 정책은 애플리케이션 코드에 직접 작성될 수 있습니다.
  
  
• 일부 시스템은 각 사용자와 해당 권한을 나열하는 액세스 제어 목록(ACL)을 사용합니다.시스템 전체를 위한 중앙 집중형 ACL이 존재할 수도 있고 각 개별 객체가 자체 ACL을 가질 수도 있습니다.
  
• 기능 기반 액세스 제어 시스템에서는 각 주체에 액세스 권한이 저장된 기능 목록이 연결됩니다.
  
  
• RBAC 및 ABAC와 같은 보다 동적인 모델은 정책 엔진을 사용합니다. 정책 엔진은 정의된 로직에 따라 각 액세스 요청을 평가하는 전용 서비스입니다. 정책 엔진은 권한 부여 결정을 내릴 때 정적인 목록에만 의존하지 않고 액세스를 허용하기 전에 요청의 더 넓은 컨텍스트를 고려합니다.  

주체가 액세스 제어 시스템으로 보호되는 리소스에 액세스하려고 할 경우 먼저 인증 프로세스를 통해 자신의 ID를 검증해야 합니다.

사람 사용자의 경우 인증은 일반적으로 사용자 이름과 비밀번호 조합과 같은 자격 증명 세트를 제시하는 방식으로 이루어집니다.하지만 비밀번호는 위협 행위자가 쉽게 추측하거나 탈취할 수 있기 때문에 가장 취약한 자격 증명 중 하나로 여겨집니다.

오늘날 대부분의 시스템은 생체 인식 및 다단계 인증(MFA)과 같은 보다 강력한 수단에 의존합니다. MFA는 사용자 ID를 검증하기 위해 두 가지 이상의 증거를 요구합니다(예: 지문 스캔 및 인증 앱이 생성한 일회용 비밀번호).

장치, 워크로드, AI 에이전트 및 기타 비인간 ID는 일반적으로 인증서 및 암호화 키와 같은 자격 증명을 사용해 자신을 검증합니다. 비인간 주체는 MFA를 사용할 수 없지만 시크릿 관리 솔루션은 볼트 저장, 자동 순환 및 기타 방법을 통해 이들의 자격 증명을 보호할 수 있도록 지원합니다.

권한 부여는 검증된 주체에 적절한 수준의 액세스를 부여하는 프로세스입니다.

권한 부여 방식은 사용 중인 액세스 제어 시스템에 따라 달라집니다.

예를 들어 시스템이 ACL을 사용하는 경우 목록을 확인한 뒤 해당 주체에 기록된 권한을 부여합니다.

시스템이 정책 엔진을 사용하는 경우 엔진은 액세스 요청의 컨텍스트를 기반으로 사용자 권한을 부여합니다.

OAuth 프로토콜(애플리케이션이 최종 사용자의 보호된 리소스에 안전하게 액세스할 수 있도록 지원하는 개방형 표준 권한 부여 프레임워크)을 사용하는 시스템에서는 토큰을 통해 권한이 부여됩니다.

네트워크 내 모든 개별 객체가 자체 액세스 제어 시스템을 가질 수는 있지만 일반적으로 이는 모범 사례로 간주되지 않습니다. 이러한 시스템 간의 공백과 불일치는 공격자가 악용할 수 있는 취약점을 만들 수 있으며 승인된 사용자의 업무 수행도 방해할 수 있습니다.

대신 미국 국립표준기술연구소(NIST) 및 OWASP와 같은 기관은 중앙 집중형 액세스 제어 시스템을 구현할 것을 권장하며, 이는 종종 포괄적인 ID 패브릭의 일부로 구축됩니다.

이러한 중앙 집중형 시스템은 다음과 같은 기술 및 툴에 의존합니다.

예를 들어 조직이 고객 데이터를 포함한 기밀 데이터베이스에 대한 액세스 제어를 구축하고 시행해야 한다고 가정해 보겠습니다. 

먼저 시스템 관리자 및 기타 관련 이해관계자는 사람, 앱 및 AI 에이전트 중 어떤 주체가 데이터베이스에 액세스할 수 있어야 하는지를 결정합니다. 예를 들어 영업 또는 마케팅 역할을 가진 사용자와 고객 관계 관리(CRM) 및 마케팅 소프트웨어가 데이터에 액세스할 수 있도록 결정할 수 있습니다. 승인된 사람 사용자가 소유한 모든 AI 에이전트 역시 액세스 권한을 가질 수 있습니다. 

다음으로 이해관계자는 승인된 각 사용자가 데이터베이스 내에서 수행할 수 있는 작업을 결정합니다. 예를 들어 영업 담당자는 고객과의 관계를 장기간 구축하고 유지해야 하므로 읽기 및 쓰기 권한이 필요할 수 있습니다. 반면 마케팅 역할은 캠페인 기획에 고객 인구통계 데이터를 활용하기만 하기 때문에 데이터베이스 읽기 권한만 가질 수 있습니다. 또한 데이터베이스 업데이트 과정에 항상 사람이 개입할 수 있도록 모든 AI 에이전트는 소유자와 관계없이 읽기 전용 권한만 갖도록 설정할 수도 있습니다.

이 액세스 정책을 시행하기 위해 조직은 세부적인 액세스 제어 로직이 포함된 중앙 집중형 정책 엔진을 사용합니다. 정책 엔진은 액세스 요청을 허용할지 결정할 때 사용자 ID뿐 아니라 컨텍스트 요소도 함께 고려합니다.  

예를 들어 영업 담당자가 고객 이메일 주소를 업데이트하기 위해 데이터베이스에 액세스하려고 한다고 가정해 보겠습니다. 먼저 영업 담당자는 올바른 인증 요소를 제공해 자신의 ID를 검증합니다. 그런 다음 정책 엔진이 다음 요소를 고려해 요청을 평가합니다.

• 영업 담당자의 검증된 ID 
  
  
• 고객 기록 업데이트 권한이 포함된 영업 담당자의 권한
  
  
• 현재 시간이 오후 3시 30분이며 일반 근무 시간 내에 있다는 점 
  
  
• 패치가 최신 상태이며 멀웨어 징후가 없는 영업 담당자 장치의 상태

이러한 요소를 바탕으로 영업 담당자의 액세스 요청이 허용됩니다.

조직은 필요에 따라 다양한 유형의 액세스 제어 모델을 구현할 수 있습니다.대표적인 유형은 다음과 같습니다.

임의 액세스 제어(DAC) 시스템은 리소스 소유자가 해당 리소스의 액세스 규칙을 설정할 수 있도록 지원합니다. DAC 모델에서는 객체 소유자가 다른 사용자에게 관리자 수준 권한을 부여할 수도 있습니다. 객체 소유자가 다른 사용자에게 관리자 권한을 부여하면 해당 사용자 역시 객체에 대한 액세스 규칙을 설정할 수 있습니다.

강제 액세스 제어(MAC) 시스템은 중앙에서 정의된 액세스 제어 정책을 모든 사용자에게 적용합니다.

이러한 시스템은 정부나 군대와 같이 보안 등급 체계를 기반으로 운영되는 경우가 많습니다. 모든 주체에는 보안 등급이 부여되며 각 객체에는 이에 대응하는 보안 등급 또는 분류 수준이 지정됩니다. 주체는 자신의 보안 등급 이하에 해당하는 객체에 액세스할 수 있습니다. 

모든 주체가 이를 따라야 한다는 점에서 모든 액세스 제어는 강제적이지만 MAC에서 "강제"라는 표현은 개별 사용자가 권한을 변경하거나 부여할 수 없다는 의미를 가리킵니다. MAC는 객체 소유자가 자신의 객체에 대한 액세스 규칙을 제어할 수 있는 임의 기반 DAC 모델과 대비됩니다. 

역할 기반 액세스 제어(RBAC)에서는 사용자 권한이 조직 내 역할을 기준으로 결정됩니다.

RBAC 시스템의 역할은 직무 명칭과 동일한 개념은 아니지만 일부 구현에서는 일대일로 대응될 수도 있습니다. 하지만 여기서 "역할"은 조직 내에서 수행하는 업무와 해당 업무 수행에 필요한 권한을 의미합니다. RBAC 역할은 직무 명칭, 숙련도 수준, 책임 범위 등을 포함한 여러 기준을 기반으로 정의됩니다.

예를 들어 시스템 관리자가 네트워크 방화벽 권한을 설정한다고 가정해 보겠습니다. 영업 담당자는 해당 방화벽에 전혀 액세스할 수 없습니다. 주니어 보안 분석가는 방화벽 구성을 조회할 수는 있지만 변경할 수는 없으며, 시니어 분석가는 관리자 권한을 가질 수 있습니다.통합 보안 정보 및 이벤트 관리(SIEM) 시스템용 API는 방화벽 활동 로그를 읽을 수 있을 수 있습니다.

RBAC는 OWASP가 권장하는 두 가지 액세스 제어 모델 중 하나입니다.

OWASP가 권장하는 또 다른 액세스 제어 모델인 속성 기반 액세스 제어(ABAC)는 정책 엔진을 사용해 각 액세스 요청의 속성을 실시간으로 분석합니다. 적절한 기준을 충족하는 요청만 허용됩니다.

넓게 보면 "속성"은 요청에 포함된 주체, 객체 및 작업의 특성을 의미합니다. 속성에는 사용자 이름 및 역할, 리소스 유형, 요청된 작업의 위험 수준 및 요청 시간과 같은 요소가 포함될 수 있습니다.

예를 들어 ABAC 시스템에서는 사용자가 근무 시간 중이며 일정 수준 이상의 직급을 보유한 경우에만 민감한 데이터에 액세스할 수 있도록 설정할 수 있습니다. 

RBAC와 ABAC의 차이는 ABAC가 여러 컨텍스트 요소를 기반으로 각 요청 시점마다 액세스 권한을 동적으로 결정한다는 점입니다. 반면 RBAC는 사전에 정의된 사용자 역할에 따라 엄격하게 권한을 부여합니다.  

규칙 기반 액세스 제어(RuBAC)는 조건 및 컨텍스트 기반 규칙에 따라 액세스를 제어하는 시스템입니다. 예를 들어 "Y 시각에 주체 X로부터 요청이 들어오면 허용한다"와 같은 방식입니다. 

"규칙 기반 액세스 제어"라는 표현은 다소 모호하고 일부는 구식으로 여겨지는 용어입니다. 이 용어는 종종 ABAC의 동의어로 사용되거나 보다 초기 단계의 단순한 형태의 ABAC를 지칭하는 용도로 사용됩니다. 때로는 액세스 요청을 추가적인 로직 계층(역할 + 규칙)을 통해 처리하는 RBAC 시스템을 의미하는 데 사용되기도 합니다. 

액세스 제어는 여러 측면에서 기업 보안의 핵심 요소입니다. OWASP는 액세스 제어가 손상될 경우 가장 큰 위험 요소이며 제대로 작동할 경우에는 가장 중요한 선제적 보안 제어 수단이라고 설명합니다. 

효과적인 액세스 제어는 조직 자산을 보호하고 기업 데이터의 가치를 최대한 활용할 수 있도록 지원하며 새롭게 부상하는 AI 에이전트 기술을 안전하게 활용하고 강화하는 데 도움을 줄 수 있습니다.반대로 결함이 있는 액세스 제어는 이러한 모든 노력을 약화시키고 해커에게 시스템을 무방비 상태로 노출시킬 수 있습니다.

오늘날 보안 운영의 핵심이 ID이기 때문에 액세스 제어는 사이버 보안 자체의 기반 요소라고 할 수 있습니다.

일반적인 기업 네트워크에는 온프레미스 및 클라우드 기반 앱과 리소스에 안전하게 액세스해야 하는 사람 사용자와 비인간 사용자가 점점 더 많이 존재하며 이들은 다양한 위치에 분산되어 있습니다.

이러한 환경에서는 경계 기반 보안 조치가 효과적이지 않습니다. 대신 조직은 개별 사용자와 리소스, 즉 액세스 관리 용어로는 주체와 객체를 중심으로 보안 제어를 수행합니다.

예를 들어 네트워크 보안의 제로 트러스트 접근 방식을 생각해 볼 수 있습니다. 제로 트러스트는 사용자를 한 번만 인증하는 대신 모든 사용자의 모든 액세스 요청을 각각 인증합니다. 즉 모든 요청이 액세스 제어 계층을 통과하게 됩니다.

또한 액세스 제어가 정보 보안의 CIA 3요소를 어떻게 지원하는지도 살펴볼 필요가 있습니다.

• 기밀성: 액세스 제어는 승인된 사용자에게만 액세스를 제한함으로써 데이터 기밀성을 유지하는 데 도움을 줍니다.
  
  
• 무결성: 액세스 제어는 사용자가 자신의 액세스 권한으로 수행할 수 있는 작업을 제어함으로써 데이터 무결성을 유지하고 데이터 규정 준수를 지원하며 데이터 침해를 완화하는 데 도움을 줍니다.
  
  
• 가용성: 액세스 제어는 사용자가 업무 수행에 필요한 액세스를 확보할 수 있도록 지원하는 동시에 과도한 권한 부여 및 그에 따른 위험을 방지하는 데 도움을 줍니다. 

액세스 제어는 데이터 보안을 유지하면서 조직이 독점 데이터로부터 더 많은 가치를 창출할 수 있도록 지원할 수도 있습니다.

IBM 기업가치연구소(IBV)의 2025 CDO 연구에 따르면 CDO의 78%는 독점 데이터 활용이 조직 차별화를 위한 전략적 비즈니스 목표라고 답했습니다. 또한 CDO의 82%는 직원들이 데이터를 쉽게 활용해 데이터 기반 의사 결정을 내릴 수 없다면 데이터가 "낭비되고 있다"고 생각하는 것으로 나타났습니다.

그리고 AI 에이전트가 디지털 작업 환경에 합류함에 따라 안전한 데이터 액세스는 더욱 중요해지고 있습니다. 에이전트가 효율적이고 효과적으로 작동하려면 기업 데이터가 필요하기 때문입니다. 

효과적인 액세스 제어는 사람 사용자와 AI 에이전트 모두가 승인된 용도로 기업 데이터에 안전하게 액세스할 수 있도록 지원합니다. CDO 연구에 따르면 AI 및 데이터 투자에서 더 높은 ROI를 달성한 조직의 CDO는 일반적으로 RBAC와 같은 보안 조치를 사용해 기업 데이터에 대한 사용자 액세스를 관리합니다.  

IBM의 Security Intelligence 팟캐스트 에피소드에서 IBM 사이버 위협 관리 오퍼링 그룹의 글로벌 파트너인 Dave McGinnis는 AI 에이전트를 “가장 도움이 되는 내부 위협”이라고 표현했습니다. McGinnis는 에이전트가 엄청난 이점과 심각한 피해를 동시에 초래할 수 있는 능력을 가지고 있다는 점을 언급한 것입니다.

의미 있는 작업을 수행하려면 에이전트는 기업 시스템 및 데이터에 대한 고권한 액세스가 필요합니다. 하지만 에이전트는 비결정적인 특성도 가지고 있기 때문에 적절한 가드레일이 없으면 새로운 방식 또는 완전히 승인되지 않은 방식으로 액세스 권한을 사용할 수 있습니다.

IBM Cyber Range의 수석 자문인 Seth Glasgow는 Security Intelligence에서 다음과 같이 설명하며 AI 에이전트를 활성화하는 동시에 권한 오용 위험을 줄이기 위해서는 신중한 액세스 제어 활용이 핵심이라고 강조했습니다.

"[AI 에이전트]의 일반적인 배포 방식은 모든 것을 볼 수 있도록 하는 것입니다. 적절한 표현이 떠오르지 않지만 모든 것을 통제하는 하나의 에이전트라고 할 수 있습니다. 하지만 바로 그 순간 매우 가치가 높은 자산이 만들어집니다. 그 앱은 엄청난 양의 민감한 데이터에 액세스할 수 있도록 구성되어 있습니다. 

따라서 IAM 관점에서 가장 먼저 해야 할 일은 이를 분리하는 것입니다. 모든 것을 수행할 수 있는 단일 에이전트는 필요하지 않습니다. 에이전트는 특정 사용 사례에 더 적합하게 맞춰져야 하며 해당 에이전트가 수행해야 하는 작업에 정확히 부합하는 권한만 가져야 합니다."

손상된 액세스 제어를 초래하는 핵심 요인은 과도한 권한 부여, 중앙 집중화 부족 및 설계 결함이라는 세 가지입니다.

조직에서는 작업 중 장애를 겪지 않도록 하기 위해 주체에게 필요 이상으로 높은 권한을 부여하는 경우가 일반적입니다. 과도한 권한 부여는 워크플로 자동화에 사용되는 비인간 ID에서 특히 흔하게 나타나는데 조직은 일반적으로 이러한 시스템이 가능한 한 적은 개입만 필요로 하기를 원하기 때문입니다.

RBAC 및 ABAC와 같은 효과적인 액세스 제어는 사용자 경험, 비즈니스 운영 및 보안 요구 사항 간 균형을 맞추는 데 도움을 줄 수 있습니다. 조직은 과도한 권한을 부여하는 대신 각 주체에 정확히 필요한 수준에 맞춰 액세스 권한을 세밀하게 조정합니다. 

중앙 집중형 액세스 제어가 없는 시스템에서는 객체마다 서로 다른 제어 시스템이 적용될 수 있습니다. 이러한 시스템 간 공백은 주체가 필요한 리소스에 액세스하지 못하게 만들 수 있으며 취약한 시스템 하나만으로도 전체 네트워크가 위험에 노출될 수 있습니다.

조직은 포괄적인 ID 패브릭을 구축하고 ID 오케스트레이션 툴을 사용해 분산된 시스템을 통합함으로써 보안 공백을 줄이는 동시에 승인된 사용자의 액세스를 간소화할 수 있습니다.

마지막으로 OWASP가 지적하듯 애플리케이션의 액세스 제어 시스템에는 설계 결함이 존재하는 경우가 많습니다. 이러한 결함에는 페이지 URL 변경을 통한 제어 우회 가능성, 누락된 API 제어 및 변조에 취약한 비보안 JSON 웹 토큰과 같은 문제가 포함될 수 있습니다.

개발자 교육, 보다 엄격한 액세스 제어 요구 사항 및 DevSecOps 운영 방식은 조직이 애플리케이션 자체에 ID 보안을 내재화하는 데 도움을 줄 수 있습니다.