속성 기반 접근 제어(ABAC)란 무엇인가요?

속성 기반 접근 제어(ABAC) 개요

• 속성 기반 접근 제어(ABAC)는 사용자, 리소스, 작업, 환경 등의 다양한 속성을 기반으로 정책을 평가하여 접근을 허용하거나 거부하는 동적이고 맥락 기반의 접근 제어 모델입니다.
• ABAC는 if-then 형태의 정책 규칙을 활용하여 부서, 역할, 위치, 시간, 디바이스 상태 등 여러 조건을 종합적으로 평가해 세분화된 권한 관리를 가능하게 합니다.
• IAM, ERP, HR 시스템, CRM, LDAP 등 다양한 데이터 소스에서 수집된 속성을 활용하여 사용자와 리소스 간의 관계를 기반으로 정교한 접근 제어를 수행합니다.
• 조직은 ABAC를 통해 데이터 보호, API 및 애플리케이션 보안 강화, 동적 네트워크 제어, 규제 준수 등 복잡한 보안 요구 사항을 효과적으로 대응할 수 있습니다.
• ABAC는 높은 유연성과 확장성을 제공하지만, 속성 관리, 정책 설계, 거버넌스 구축, 시스템 통합 등 초기 구현 과정에서 상당한 계획과 관리 노력이 필요합니다.

속성 기반 접근 제어(ABAC)는 정책 기반 접근 제어(PBAC) 또는 클레임 기반 접근 제어(CBAC)라고도 불리며, 부서, 위치, 관리자, 시간대와 같은 다양한 특성을 기반으로 정책을 설정하고 적용하는 권한 부여 방식입니다. ABAC는 불리언 논리를 활용하여 사용자, 요청, 리소스, 그리고 작업을 정의하는 if-then 문 형태의 접근 규칙을 생성합니다. 예를 들어, 요청자가 영업 담당자인 경우 고객 관계 관리(CRM) 솔루션에 대한 읽기-쓰기 권한이 부여되며, 관리자는 보고서 생성을 위해 조회 권한만 제공받을 수 있습니다.

ABAC를 활용하면 점점 더 복잡해지는 IT 요구 사항을 충족하기 위해 동적이고 상황 인식형 보안을 제공할 수 있습니다. ABAC의 주요 활용 사례는 다음과 같습니다.

- 무단 사용자 또는 행위로부터 데이터, 네트워크 장비, 클라우드 서비스 및 IT 자원을 보호

- 민감한 거래 노출을 방지하기 위한 마이크로서비스 및 애플리케이션 프로그래밍 인터페이스(API) 보안 강화

- 사용자별 정책 결정이 가능한 동적 네트워크 방화벽 제어 구현

ABAC의 구성 요소

속성이란 접근 이벤트에서 사용되는 구성 요소의 특성 또는 값을 의미합니다. 이러한 속성은 아이덴티티 및 접근 관리(IAM) 시스템, 전사적 자원 관리(ERP) 시스템, 내부 인사 시스템의 직원 정보, CRM의 고객 정보, 경량 디렉터리 액세스

프로토콜(LDAP) 서버 등 다양한 데이터 소스에서 추출할 수

있습니다.

속성 기반 접근 제어는 여러 속성을 조합하여 권한을 부여함으로써 세분화된 접근 제어를 실현할 수 있으며, 예를 들어 직무 분리(SoD)와 같은 정책 적용이

가능합니다.

접근 허용 또는 거부 결정에 활용할 수 있는 주요 특성은 다음과 같습니다.

- 주체 또는 사용자 속성: 리소스에 접근하여 작업을 수행하려는 사용자를 식별하는 기준

- 객체 또는 리소스 속성: 접근 요청을 받은 파일, 애플리케이션, 서버, API 등의 특성

- 환경 또는 컨텍스트 속성: 접근 요청의 더 넓은 맥락을 나타내는 정보

- 작업 속성: 사용자가 리소스와 상호작용하려는 방식을 나타내며, 단독 또는 복합적으로 활용되어 복잡한 시나리오에 대응할 수 있습니다.

속성 기반 접근 제어의 작동 방식

ABAC(속성 기반 접근 제어)는 사용자의 행동이 아니라, 사용자의 속성에 따라 권한을 부여하여 세분화된 제어가 가능합니다. 다양한 속성을 분석해 환경 내 상호작용을 평가하고, 관계에 따라 규칙을 적용합니다.일반적으로 다음과 같은 절차로 진행됩니다:

1. 접근 요청이 발생합니다.
2. 속성 기반 접근 제어 도구가 사용자 속성을 스캔하여 기존 정책과 일치하는지 확인합니다.
3. ABAC 도구의 분석 결과에 따라 접근 권한이 승인되거나 거부됩니다.

속성 기반 접근 제어 구현: 정책, 시스템, 인프라

ABAC(속성 기반 접근 제어)는 주체, 리소스, 작업, 환경에 대한 동적 속성을 평가하여 접근을 제어합니다. 주요 구현 단계는 다음과 같습니다:

• 정책 목표 및 속성 정의: ABAC가 보호할 시스템, 데이터 유형, 비즈니스 프로세스를 포함하여 정책의 목적과 범위를 명확히 설정합니다.

• 위험 기반 우선순위 설정: 고위험 데이터와 프로세스를 우선적으로 선정하여 즉각적인 ABAC 적용 범위에 포함합니다.

• 속성 명칭, 유형, 용어 표준화: subject.role, subject.clearance, resource.sensitivity, env.device_posture 등과 같은 속성 명칭과 유형, 용어를 표준화하여 속성 카탈로그에 등록합니다.
정책 설계

• 정책은 명확한 의도를 기반으로 하며, 비즈니스 요구와 직접적으로 연계합니다.

• 정책의 비즈니스 목적, 완화되는 위험, 관련 컴플라이언스 요구사항을 문서화합니다.

• 정책별 속성 수는 최소화하며(규칙당 2~4개의 핵심 속성으로 시작), 공통 패턴(예: 읽기 전용 접근, 관리자 작업, 테넌트 간 지원, 비상 접근)에 대한 템플릿을 만듭니다.

• 안전한 기본값(예: 기본 거부, 명시적 허용 규칙 적용)을 설정합니다.

• 정책에는 기계가 읽을 수 있는 의무사항(예: 다중 인증(MFA) 요구, 세션 기록)과 사람이 이해할 수 있는 집행 가이드라인을 포함합니다.

속성 정의

• 주체 속성: userId, 역할, 그룹, 부서, 보안 등급, 고용 상태, 인증 강도, 위험 점수 등

• 리소스 속성: resourceId, 리소스 유형, 소유자, 민감도/분류, 테넌트 ID, 생성자 등

• 작업 속성: 작업(읽기/쓰기/실행/승인), 채널(API/콘솔/GUI), 거래 금액 등

• 환경 속성: 시간, 위치, 디바이스 상태, IP 평판, 네트워크 존, 위협 수준 등

• 입력/컨텍스트 속성: 거래별 값(주문 금액, 계좌 번호), 티켓 ID, 동의 플래그, IRB 상태 등

• 속성 소스: IDaaS(아이덴티티 서비스), HRIS(인사 시스템), CMDB(구성 관리 DB), 디바이스 상태 에이전트, 사기 탐지 엔진, 파트너 시스템, 테넌트 메타데이터 등

정책 거버넌스 및 작성 프로세스 구축

• 정책 위원회 구성

• 정책 소유자 지정

• 정책 라이프사이클 개발

• 변경 관리 프로세스 수립

• 버전 이력과 검토자가 포함된 정책 레지스트리 관리

정책 아키텍처 배포

• 정책 관리(PAP), 정책 결정(PDP), 정책 집행(PEP), 정책 정보 제공(PIP) 지점을 포함한 정책 아키텍처 구축

• 정책 아키텍처와 속성 소스 통합

• 모든 구성요소 동기화 및 적절한 정책 배포로 지연 방지

테스트

• 신규 정책 및 변경 사항 단위 테스트

• 실제 접근 로그를 활용한 정책 시뮬레이션

• 스테이징 후 일부 사용자와 애플리케이션에 정책 단계적 적용

• 우회 시나리오(속성 위조, 캐싱 공격, 재생 공격 등) 점검을 위한 침투 및 레드팀 테스트 수행

로깅

• 결정 로그(결정 ID, 정책 버전, 사용된 모든 속성 값, 요청자, 리소스, 타임스탬프, PDP 판정, 의무사항 등) 기록 및 저장

• WORM 또는 불변 S3+KMS 등 변조 방지 스토리지에 로그 보관, 포렌식 및 감사 목적 지원

• 감사자가 정책부터 속성 값, 집행 조치까지 추적 가능하도록 결정 ID와 증거 자료 연계

• 이상 탐지, 실패율, 비정상적 허용 조건 등을 SIEM 또는 UEBA 시스템에 자동 전달하여 분석 및 경보 자동화

파일럿 롤아웃

• 1~2개의 핵심 애플리케이션을 대상으로 PEP, PDP 및 3~5개의 정책을 적용해 파일럿 수행

• 2~6주간 모니터링 전용 모드로 운영하며 결정 로그를 수집, 속성 및 규칙을 개선

• 자문 의무사항(예: 사유 입력 요구) 등 소프트 집행부터 점진적으로 거부/허용 및 의무사항 집행으로 확대

전체 롤아웃

• 비즈니스 유닛 온보딩

• 애플리케이션 추가

• 속성 파이프라인 자동화

운영 및 유지 관리

• 정책 라이프사이클 관리 프로그램 운영

• 속성 소유자 및 신선도/정확성 보장 위한 SLA 정의

• 성능 및 SLA 모니터링

• 사고 대응 플레이북에 따라 속성 회수, 토큰 교체, 긴급 정책 적용

• 정책 작성 워크숍, 헬프데스크 교육 등 사용자 교육 실시

• 분기별 검토 및 정책 정비를 통해 지속적 개선

실행 가능한 ABAC 구현 체크리스트

이 간단한 체크리스트는 ABAC 구현 프로세스를 요약하여 프로젝트의 범위와 규모를 한눈에 파악할 수 있도록 합니다.
• 초기 사용 사례 및 범위 정의(일반적으로 1~2개 애플리케이션)• 정책 거버넌스 수립(정책 소유자 및 검토자 지정 등)• 속성 카탈로그 작성 및 소유자, SLA 지정• 파일럿 애플리케이션에 대한 결정 및 집행 지점 배포• IDaaS(아이덴티티 서비스), HRIS(인사 시스템), CMDB(구성 관리 DB), 디바이스 상태 등 정책 커넥터 구현• 초기 정책(보통 5~10개) 작성 및 테스트• 최근 로그를 활용한 정책 시뮬레이션(2~4주 운영)• 모니터링 전용 로깅 활성화 및 SIEM으로 전달해 평가• 정책 점진적 소프트 집행 후, 전체 집행으로 전환• 결정 로깅을 불변 스토리지에 기록하고, 감사와 통합• 분기별 검토 및 개선, 점진적으로 애플리케이션 추가

속성 기반 접근 제어의 주요 과제

ABAC는 일단 도입이 완료되면 손쉽게 확장 및 보안 프로그램에 통합할 수 있습니다. 그러나 초기 도입 단계에서는 상당한 노력이 필요합니다. 많은 이들이 ABAC의 이점을 인정하지만, 그에 따른 과제 역시 충분히 이해해야 합니다.
관리자를 위한 ABAC 도입 과제ABAC를 효과적으로 관리하려면 다음과 같은 복잡성이 수반되어 관리자는 여러 과제에 직면하게 됩니다:- 모든 구성 요소에 속성을 지정해야 합니다.- 다양한 조건(예: X이면 Y) 기반으로 속성의 권한을 결정하는 중앙 정책 엔진을 구축해야 합니다.- 모든 속성을 정의해야 합니다.- 모든 속성과 규칙이 완전히 적용되기 전에도 특정 사용자에게 부여된 권한을 파악해야 합니다.- 접근을 관리할 포괄적인 정책 세트를 수립하기 위해 권한 정책을 매핑해야 합니다.
산업 전반의 ABAC 과제- 부정확하거나 불확실한 속성 소스는 잘못된 접근 결정으로 이어질 수 있습니다.- 오래되거나 갱신되지 않은 속성(예: 역할 변경이나 퇴사 미반영)은 과도하거나 부족한 접근 권한을 초래할 수 있습니다.- 정책의 복잡성과 속성의 급증으로 인해 ABAC 관리가 어려워집니다.- 원격 또는 복잡한 속성 평가로 인한 지연이 발생할 수 있습니다.- 접근 결정의 근거를 설명하기 어렵습니다.- 속성 자체가 민감정보일 수 있어 법적·컴플라이언스 위험이 발생할 수 있습니다.- 기존 애플리케이션은 RBAC 기반으로 설계되어 ABAC의 다양한 속성을 활용할 수 없습니다.- 속성 모델링, 테스트, 거버넌스가 운영 부담을 가중시킵니다.
산업별 ABAC 과제의료(병원, 클리닉, EHR 시스템 등)- 과제: 동의, 맥락, 긴급(예: break-glass) 상황 충돌 처리의 복잡성- 예시: 긴급 상황에서 정책이 안전하게 예외를 처리하지 못하면, 의료진이 평소 접근할 수 없는 의료 기록에 즉시 접근해야 할 때 치료 지연이나 개인정보 침해가 발생할 수 있습니다.금융 서비스(은행, 트레이딩 플랫폼 등)- 과제: 엄격한 규제 감사 요구사항 충족을 위한 세분화된 직무 분리(SoD) 추적의 어려움(거래 금액, 계좌 민감도, 거래 유형, 승인 등 속성의 복합 평가 필요)- 예시: 잘못된 속성 소스는 비인가 이체를 허용하거나 합법적 컴플라이언스 작업을 차단할 수 있습니다.공공부문- 과제: 다양한 보장 수준, 분리, 기존 분류 시스템에서 분류 등급, 국적, 특별 인가 준수의 어려움- 예시: 속성이 검증된 아이덴티티와 연계되지 않으면 도메인 간 접근 실패나 정보 유출 위험이 발생할 수 있습니다.제조업- 과제: 연결이 없거나 간헐적인 장치는 PDP 쿼리나 복잡한 속성 처리가 불가- 예시: 접근 문제가 평가·해결되지 않으면 생산 중단이 발생할 수 있습니다.에너지 및 유틸리티- 과제: 지역별·시간 기반 접근 제한과 긴급 예외 처리를 안전, 중요 접근, 규제 준수와 균형 있게 관리해야 함- 예시: 표준 ABAC 정책이 지역 규정이나 긴급 프로토콜을 반영하지 않으면 안전사고나 비준수 벌금이 발생할 수 있습니다.리테일 및 이커머스- 과제: 구매 이력, 멤버십 등급, 쿠키 기반 신호 등 속성이 변동성이 크고 개인정보 보호 이슈가 존재- 예시: ABAC는 온라인 사용자 맞춤화와 개인정보 보호의 균형을 어렵게 만들어 고객 데이터 노출 또는 불일치한 쇼핑 경험을 초래할 수 있습니다.클라우드 및 SaaS 제공업체- 과제: 대규모 테넌트 간 속성 평가와 교차 테넌트 데이터 유출 방지 필요- 예시: 장시간 ABAC 정책 평가 중 교차 테넌트 데이터 접근이나 불가피한 지연이 발생할 수 있습니다.통신- 과제: 모바일 기기 사용자의 네트워크 간 이동- 예시: 위치 속성이 빠르게 변할 때 세션 핸드오프가 거부되거나 부적절하게 허용될 수 있습니다.교육- 과제: 학생/교직원의 빈번한 변동, 혼합된 역할, 미성년자 개인정보 보호 등으로 인한 ABAC 관리의 어려움- 예시: 속성이 학기마다 변경되고 일부 기록이 보호 대상일 경우, 성적부, 연구 데이터, 학생 건강 기록이 잘못 접근되거나 노출될 위험이 커집니다.

ABAC의 주요 이점

속성 기반 접근 제어(ABAC)는 상황별 변수를 정교하게 통제하여 정책 입안자가 세분화된 접근 권한을 구현할 수 있도록 지원합니다. ABAC의 권한 부여 모델은 다음과 같은 조직의 강력한 이점을 제공합니다.

산업 전반의 ABAC 이점

- 다양한 정책 수립 가능: ABAC는 속성과 조건만 정의할 수 있다면 거의 모든 유형의 정책을 만들 수 있습니다. 이를 통해 관리자는 맥락에 맞는 지능형 보안, 개인정보 보호, 컴플라이언스 결정을 내릴 수 있습니다. 예를 들어, 특정 직원 그룹이 특정 시간이나 위치에서만 일부 정보에 접근하도록 제한할 수 있습니다.

- 사용 편의성: ABAC는 기술적인 권한 설정을 직관적인 인터페이스로 감춥니다. 적절한 권한이 있는 사용자는 사용자 프로필을 업데이트할 수 있으며, 속성이 최신이면 필요한 접근이 자동으로 보장됩니다. 또한 관리자는 사용자와 객체 간의 관계를 일일이 지정하지 않아도 최대한 많은 사용자에게 최대한의 리소스 접근을 제공할 수 있습니다.

- 신속한 신규 사용자 온보딩: 관리자는 정책을 생성하고 속성을 할당함으로써 신규 직원이나 외부 파트너의 리소스 접근을 빠르게 지원할 수 있습니다. 기존 규칙이나 객체 특성을 변경하지 않고도 접근 권한을 부여할 수 있습니다.

- 유연성: ABAC는 거의 모든 속성을 표현할 수 있으며, 사용자가 접근하는 애플리케이션이나 데이터 유형, 제출 가능한 거래, 수행 가능한 작업 등 맥락에 따라 속성을 자동으로 변경할 수 있습니다.

- 규제 준수: ABAC의 세분화된 권한 및 통제는 개인정보(PII) 및 기타 민감 데이터 보호 관련 법률(HIPA, GDPR, PCI DSS 등) 준수를 지원합니다.

- 확장성: ABAC를 구축한 후에는 유사한 구성 요소나 사용자 직무에 속성을 복사·재사용할 수 있어 정책 유지 및 신규 사용자 온보딩이 간소화됩니다.

산업별 ABAC 이점

의료

- 이점: ABAC는 사용 목적과 동의를 강제하여 임상 인력이 치료 목적으로 환자 동의가 있는 경우에만 기록에 접근하도록 제한합니다.

- 예시: 간호사는 “role=nurse”, “purpose=treatment”, “patientConsent=true” 조건에서 환자 차트를 즉시 열람할 수 있지만, 연구원은 별도의 동의와 IRB 승인이 없으면 식별 가능한 기록에 접근할 수 없습니다.

금융 서비스

- 이점: ABAC는 사용자 역할과 거래 맥락을 결합해 위험 거래를 방지하고, SOX 직무분리 요건을 지원합니다.

- 예시: 주니어 트레이더는 본사에서 일정 금액까지 거래를 실행할 수 있지만, 한도를 초과하는 주문은 자동으로 시니어 트레이더 승인과 추가 인증을 거쳐야 합니다.

공공부문

- 이점: ABAC는 인가 등급과 필요성(need-to-know)을 함께 적용하여 관련 프로젝트에 배정된 인가자만 기밀 정보에 접근할 수 있도록 제한합니다.

- 예시: 탑시크릿 인가를 가진 분석가라도 프로젝트 팀이 아니면 문서를 열람할 수 없고, 인가된 팀원만 보안 네트워크에서 접근할 수 있습니다.

제조업

- 이점: ABAC는 작업자가 인증을 받고 장비가 안전한 상태일 때만 제어 작업을 허용하여 안전과 생산 무결성을 보호합니다.

- 예시: 기술자는 “operatorCertification=valid”, “assetState=maintenance” 조건에서만 PLC 설정을 변경할 수 있어, 실시간 생산 중에는 변경이 불가합니다.

에너지 및 유틸리티

- 이점: ABAC는 지역 및 위협 수준에 따라 운영 통제 및 가시성을 제한하여 그리드에 대한 무단 행위 위험을 줄입니다.

- 예시: 현장 엔지니어는 지정 구역 내 장치에 한해, “threatLevel=normal” 및 원격 워크스테이션이 기기 상태 점검을 통과한 경우에만 그리드 조정이 가능합니다.

리테일 및 이커머스

- 이점: ABAC는 주문 금액, 사기 점수 등 맥락 신호 기반으로 환불이나 고액 거래를 제한해 사기와 재정 손실을 줄입니다.

- 예시: 고객 서비스 담당자는 소액 환불을 자동 처리할 수 있지만, 일정 금액 이상 또는 사기 점수가 높은 경우에는 관리자 승인과 추가 검증이 필요합니다.

클라우드 및 SaaS 제공업체

- 이점: ABAC는 커스텀 코딩 없이 테넌트별 정책을 적용하여 하나의 제품으로 다양한 고객의 권한을 안전하게 관리할 수 있습니다.

- 예시: 지원 담당자는 테넌트 ID가 일치하고 지원 접근이 명시적으로 허용된 경우에만 해당 테넌트 대시보드를 볼 수 있어, 교차 테넌트 데이터 노출을 방지합니다.

통신

- 이점: ABAC는 네트워크 변경 전 티켓, 맥락 검증, 역할 확인을 요구해 부적절한 프로비저닝을 방지합니다.

- 예시: 기술자는 “ticketStatus=approved”, 장치 ID 일치, 해당 장치 클래스에 대한 권한이 있을 때만 펌웨어 업데이트를 실행할 수 있습니다.

교육

- 이점: ABAC는 프로젝트 멤버십, IRB 승인, 계약 조건에 따라 데이터셋 접근을 제한해 보안성과 기간 기반 협업을 지원합니다.

- 예시: 방문 연구원은 “IRBApproval=true”, “projectMembership=active” 조건에서만 프로젝트 기간 동안 민감 데이터셋에 접근할 수 있으며, 프로젝트 종료 시 접근 권한이 자동 만료됩니다.

ABAC, RBAC, PBAC 비교

속성 기반 접근 제어(ABAC)와 역할 기반 접근 제어(RBAC)는 모두 널리 사용되는 접근 관리 방식입니다. RBAC는 평면적이거나 계층적인 역할에 따라 접근 권한을 부여하며, 각 역할은 권한 또는 권리의 집합을 나타냅니다. 반면, ABAC는 사용자, 리소스, 작업, 환경 속성 등을 평가해 상황에 맞는 세분화된 접근 결정을 내립니다.

정책 기반 접근 제어(PBAC) 또는 정책-코드화 방식은 이러한 모델을 보완하고 발전시킨 방식으로, 권한 부여 논리를 선언적이고 버전 관리가 가능한 정책으로 구현합니다. PBAC 정책은 역할과 속성뿐만 아니라 위험 점수, 위치, 시간과 같은 외부 신호도 참조할 수 있습니다. 중앙 집중화된 정책 엔진이 이러한 입력값을 평가하여 모든 시스템에서 일관되고 검증 가능하며 감사 가능한 접근 결정을 제공합니다.

ABAC를 통한 조직 보안 강화

속성 기반 접근 제어(ABAC)는 많은 조직에서 선호하는 권한 부여 모델로 널리 채택되고 있습니다. ABAC는 강력한 보안 기능을 제공할 뿐만 아니라 보안 관리의 부담을 완화하는 데에도 효과적입니다.

면책 조항: 본 문서의 정보는 참고용이며, 법적 자문을 제공하기 위한 것이 아닙니다. SailPoint는 법적 자문을 제공하지 않으므로 관련 법적 이슈에 대해서는 반드시 법률 전문가와 상담하시기 바랍니다.