접근통제의 정책·메커니즘·보안모델 이해

요청을 허용하기 전에 확인해야 하는 것

접근통제(Access Control)는 중요 정보자원에 대한 접근 요구가 정당한지 확인하고, 허용 여부를 판단하며, 그 결과를 기록하는 통제 행위다. 정보시스템이나 데이터 같은 객체(Object)에 사용자·프로세스·장치 같은 주체(Subject)가 접근할 때, 정해진 수준을 벗어난 동작으로부터 자원을 보호하는 데 목적이 있다.

이 체계에는 접근을 시도하는 주체와 접근 대상 객체 외에도 요청을 판정하는 참조 모니터(Reference Monitor), 그리고 모든 접근 시도와 결과를 남기는 감사 추적(Audit Trail)이 포함된다.

접근 요청은 식별과 인증을 거쳐 권한 검증, 인가, 감사로 이어진다. 식별에는 패스워드, 스마트카드, 생체인식 등을 활용할 수 있고, 인증에는 SSO(Single Sign-On), EAM(Enterprise Access Management), IAM(Identity and Access Management) 등의 기술이 사용된다.

⤢✕

정책은 권한을 배분하는 기준이다

접근통제 정책은 누가 어떤 자원에 어떤 조건으로 접근할 수 있는지를 정하는 규칙 체계다.

임의적 접근통제(DAC, Discretionary Access Control)는 자원 소유자가 권한을 정하는 신분 기반 모델이다. 파일 소유자가 다른 사용자에게 읽기·쓰기 권한을 부여하는 방식이 이에 해당하며, 사용자 ID와 그룹 멤버십을 기준으로 통제한다. 유연성은 높지만 중앙집중적 통제에는 어려움이 있다.

강제적 접근통제(MAC, Mandatory Access Control)는 정책과 규칙을 바탕으로 시스템이 중앙에서 권한을 제어한다. 보안 레이블(Security Label)을 사용하며, 주체와 객체에 Top Secret, Secret, Confidential, Unclassified 등의 보안 레벨을 할당한다. 군사·정부 시스템에서 주로 활용된다.

역할 기반 접근통제(RBAC, Role-Based Access Control)는 사용자에게 역할(Role)을 부여하고 그 역할에 따라 권한을 부여한다. 직무와 책임을 기준으로 권한을 관리하므로 관리 효율성을 높일 수 있다. 예를 들어 회계사는 재무 데이터에, 인사 담당자는 직원 정보에 접근하도록 구성한다.

정책을 시스템에 반영하는 방식

접근제어목록(ACL, Access Control List)은 객체 관점의 메커니즘이다. 각 객체에 접근 가능한 주체와 권한을 목록화하며, 파일이나 디렉터리별 권한 설정에 쓰인다. Windows NTFS와 Unix/Linux 파일 권한처럼 대부분의 운영체제가 이를 지원한다.

능력목록(CL, Capability List)은 주체 관점에서 각 주체가 접근할 수 있는 객체와 권한을 목록으로 관리한다. 사용자나 프로세스별 접근 자원과 권한을 설정하며, 토큰 기반 인증 시스템에서 주로 활용된다.

기밀성과 무결성을 다루는 모델

Bell-LaPadula 모델은 기밀성(Confidentiality)을 중심으로 한 수학적 모델이다. "No Read Up, No Write Down" 원칙에 따라 주체는 자신의 보안 레벨보다 높은 객체를 읽을 수 없고, 낮은 레벨의 객체에 쓸 수 없다. 군사 보안 시스템에 적합하다.

Biba 모델은 무결성(Integrity)을 중심에 둔다. "No Read Down, No Write Up" 원칙을 적용하며, Bell-LaPadula와 반대 방향으로 불법적 수정을 막는다. 주체는 자신의 무결성 레벨보다 낮은 객체를 읽을 수 없고, 높은 레벨의 객체에 쓸 수 없다.

Clark-Wilson 모델은 상업 환경에 적합한 무결성 중심 모델이다. 잘 형성된 트랜잭션(Well-formed Transaction)과 직무 분리(Separation of Duty)를 강조해 데이터 일관성과 감사 가능성을 보장한다.

접근 매트릭스 모델(Access Matrix Model)은 주체와 객체의 관계를 행렬로 표현한다. 행은 사용자 같은 주체, 열은 자원 같은 객체를 나타내며 각 셀에는 해당 주체가 객체에 가진 권한을 표시한다. 논리적 표현에는 적합하지만 대규모 시스템에서는 구현 복잡성이 증가한다.

권한 설계에서 지켜야 할 원칙

최소권한 원칙(Principle of Least Privilege)은 Need to Know 기반으로 업무 수행에 필요한 최소 권한만 부여하는 방식이다. 불필요한 권한에서 비롯되는 위험을 줄이며, 회계 담당자에게 인사 시스템 접근 권한을 부여하지 않는 구성이 한 예다.

명시적으로 허용하지 않은 접근을 금지하는 Default Deny는 화이트리스트 방식이다. 특정 포트만 허용하고 나머지를 차단하는 방화벽 정책처럼 보수적이고 엄격한 통제를 구현할 수 있다. 반대로 명시적으로 금지하지 않은 접근을 허용하는 Default Allow는 블랙리스트 방식이며 사용성은 높지만 보안성은 낮다. 알려진 악성코드만 차단하는 시스템이 그 예다.

참조 모니터는 모든 접근 요청을 중개하는 보안 컴포넌트다. 우회할 수 없고, 변조할 수 없으며, 검증 가능해야 한다. 커널 또는 하드웨어 수준에서 구현할 수 있고 운영체제 보안 커널과 하이퍼바이저 보안 기능이 사례다.

권한 분리는 중요한 작업을 여러 단계로 나누어 서로 다른 주체에게 맡기는 원칙이다. 단일 주체의 오남용을 막고, 하나의 통제가 우회되더라도 다른 통제로 보호할 수 있다. 금융 시스템에서 거래 승인자와 실행자를 분리하는 구성이 이에 해당한다.

운영 환경별 접근통제

운영체제에서는 Windows의 NTFS 파일 권한, Active Directory, 그룹 정책(GPO)을 사용할 수 있다. Unix/Linux에서는 파일 권한(rwx), sudo 메커니즘, SELinux/AppArmor(MAC 구현)이 접근통제 수단이다.

데이터베이스는 사용자 계정과 역할 기반 권한, 뷰(View)를 통한 데이터 제한, 행/열 수준 보안(Row-level/Column-level Security), 저장 프로시저를 통한 간접 접근으로 통제할 수 있다.

네트워크 영역에서는 방화벽(Firewall)과 ACL 기반 필터링, NAC(Network Access Control) 솔루션, VPN과 원격 접근 통제, 제로 트러스트(Zero Trust) 아키텍처가 쓰인다.

애플리케이션에서는 사용자 인증과 세션 관리, API 게이트웨이와 토큰 기반 인증, OAuth·OIDC 같은 표준 프로토콜, RBAC 기반 메뉴·기능 접근 제어를 적용한다.

클라우드 환경에서는 AWS IAM, Azure AD, Google Cloud IAM 등의 ID 및 접근 관리 기능을 이용한다. 리소스 태그와 정책 기반 접근 제어, 다중 계정 전략(Multi-account Strategy), 최소권한 원칙을 위한 자동화된 정책 분석도 함께 고려할 수 있다.

접근 판단에 맥락을 더하는 흐름

제로 트러스트 보안 모델은 "절대 신뢰하지 말고, 항상 검증하라(Never trust, always verify)"는 원칙을 따른다. 네트워크 위치가 아니라 ID, 기기 상태, 행동 패턴 등을 함께 검증하고 마이크로 세분화된 접근통제를 구현한다.

컨텍스트 기반 접근통제(CBAC, Context-Based Access Control)는 사용자 ID 외에도 시간, 위치, 디바이스, 행동 패턴 등을 판단에 반영한다. 위험 기반 인증(Risk-Based Authentication)을 확대하고, 이상 행동 감지에 따라 권한을 동적으로 조정한다.

AI/ML 기반 접근통제는 사용자 행동 분석(UBA)으로 비정상 패턴을 탐지하고, 권한 추천과 최적화를 자동화하며, 지속적 인증(Continuous Authentication)을 구현하는 방향으로 활용된다. 양자 암호 기반 접근통제에서는 양자 키 분배(QKD) 기반 인증, 포스트 퀀텀 암호화, 양자 내성 인증 프로토콜 개발이 다뤄진다.

접근통제는 기술적 메커니즘만으로 완성되지 않는다. 명확한 정책, 지속적인 모니터링과 감사, 사용자 교육이 함께 작동해야 중요 자산을 보호하는 다층 보안 체계가 된다.