속성 기반 접근 제어(ABAC)란? AI 권한을 조건으로 나누는 방법

TL;DR

속성 기반 접근 제어(Attribute-Based Access Control, ABAC)는 사용자, 자원, 요청한 행동과 접속 환경의 속성을 정책과 비교해 접근 허용 여부를 정하는 인가 방식입니다. 편집자라는 역할만 확인하는 데서 끝나지 않습니다. 마케팅팀 편집자가 회사 관리 기기로 내부용 문서를 읽을 때처럼 구체적인 조건을 더합니다. AI 에이전트와 RAG가 여러 데이터와 도구를 연결할수록 세밀한 통제에 도움이 됩니다. 다만 속성값과 정책이 틀리면 잘못 허용하거나 정상 작업을 막습니다.

핵심 3줄 요약

• 핵심 1
  ABAC는 역할 하나만 보지 않습니다. 사용자·자원·행동·환경의 속성을 정책에 대입해 요청마다 접근을 판단합니다.
• 핵심 2
  AI 에이전트와 RAG에서는 조건을 조합합니다. 부서, 프로젝트, 문서 등급, 읽기·쓰기 행동, 접속 위치와 시간을 함께 봅니다.
• 핵심 3
  속성과 정책의 품질이 안전성을 좌우합니다. 오래된 태그, 예외 정책, 지원 범위를 함께 시험하고 최소 권한을 유지해야 합니다.

이 글에서 다룰 내용

속성 기반 접근 제어를 한 문장으로 정의하면 무엇인가요?

속성 기반 접근 제어(ABAC)는 접근을 요청한 주체, 보호할 자원, 요청한 행동과 환경의 속성을 정책·규칙과 비교해 허용 여부를 결정하는 인가 방식입니다.

NIST SP 800-162는 ABAC를 주체, 객체, 요청한 작업과 경우에 따라 환경 조건에 연결된 속성을 정책이나 규칙과 비교해 허용 작업을 정하는 논리적 접근 제어 방법으로 설명합니다.

여기서 주체는 사용자, 그룹, 앱이나 서비스 계정입니다. 자원은 문서, 데이터셋, 모델, API와 저장소가 될 수 있습니다. 행동은 읽기, 수정, 삭제, 실행, 공유이며 환경에는 시간, 네트워크, 기기 상태처럼 요청 당시의 조건이 들어갑니다.

한 줄 정리: ABAC는 주체의 신원만 보지 않습니다. 주체와 자원의 속성, 요청한 행동과 당시 환경을 함께 판단합니다.

쉬운 예시로 이해해 볼까요?

감자나라ai님이 AI로 광고 원고를 만들고 사내 자료를 검색하는 팀을 운영한다고 가정해 보겠습니다.

마케팅팀 구성원이 회사 관리 기기로 접속해 프로젝트가 Potato인 내부용 문서를 읽는 요청은 허용합니다. 같은 사람이 외부 기기에서 기밀 문서를 내려받거나, 자동화 서비스 계정이 승인 없이 원문을 삭제하려는 요청은 막습니다.

이때 정책은 사용자의 부서가 마케팅인지, 사용자와 문서의 프로젝트 태그가 같은지, 문서 등급이 무엇인지, 행동이 읽기인지 삭제인지, 접속 기기가 관리 대상인지 차례로 확인합니다.

쉬운 예시: RBAC가 편집자 출입카드를 확인한다면 ABAC는 담당 프로젝트, 문서 등급, 출입 시간과 기기 상태까지 확인하는 방식에 가깝습니다.

ABAC는 어떤 속성을 확인하나요?

1. 주체 속성

부서, 직무, 프로젝트, 고용 상태, 보안 교육 이수 여부처럼 요청한 사람이나 서비스의 정보를 뜻합니다. AI 자동화라면 서비스 계정 이름, 워크로드 유형과 실행 환경도 주체 속성이 될 수 있습니다.

2. 자원 속성

문서의 소유 팀, 프로젝트, 데이터 등급, 지역, 보존 상태처럼 보호할 대상의 정보를 뜻합니다. AWS는 ABAC에서 IAM 주체와 자원에 붙인 태그가 일치할 때 작업을 허용하는 예를 안내합니다.

3. 행동 속성

읽기, 쓰기, 삭제, 내보내기, 모델 실행과 도구 호출처럼 무엇을 하려는지 구분합니다. 같은 사용자라도 읽기는 허용하고 삭제는 별도 승인을 요구합니다.

4. 환경 속성

접속 시간, 네트워크, 기기, 위치와 세션 위험도처럼 요청 당시의 맥락입니다. Google Cloud IAM Conditions는 회사 네트워크에서 온 요청이나 일정 시간의 임시 접근처럼 조건부 권한을 구성하는 사례를 설명합니다.

5. 정책과 조건식

속성은 재료이고 정책은 판단 규칙입니다. 예를 들어 사용자 프로젝트와 자원 프로젝트가 같고 행동이 읽기이며 현재 시간이 승인 기간 안이면 허용한다는 조건을 만들 수 있습니다.

핵심 인사이트: ABAC의 세밀함은 속성 개수가 아니라 업무 규칙을 정확히 표현하고 꾸준히 관리하는 정책에서 나옵니다.

AI를 사용할 때 왜 중요한가요?

첫째, AI 에이전트의 도구 권한을 요청별로 좁힙니다. 조사 에이전트에는 승인된 저장소 읽기만 허용합니다. 외부 전송이나 삭제는 작업 유형과 승인 상태가 맞을 때만 엽니다.

둘째, RAG가 원본 문서의 접근 범위를 지키도록 돕습니다. 검색 결과가 관련성이 높아도 사용자의 부서나 프로젝트, 문서 등급 조건이 맞지 않으면 검색과 답변 근거에서 제외해야 합니다.

셋째, 여러 고객이 함께 쓰는 AI 서비스에서 테넌트 경계를 확인합니다. 요청 주체와 데이터의 테넌트 속성이 일치하는지 검사하면 다른 고객의 자료가 섞이는 위험을 줄이는 통제가 됩니다.

넷째, 임시 업무와 예외 접근을 정책으로 표현합니다. 장애 대응 담당자에게 승인된 시간과 프로젝트 범위 안에서만 로그 읽기 권한을 줍니다. 기간이 끝나면 조건이 더 이상 성립하지 않습니다.

다섯째, 역할이 지나치게 늘어나는 문제를 줄입니다. AWS는 속성에 맞춘 정책이 새 자원과 조직 변화에 동적으로 대응한다고 설명합니다. 역할마다 별도 정책을 만드는 부담도 줄어듭니다.

실전 팁: AI 도구를 연결할 때 주체, 자원, 행동, 환경을 네 칸으로 나누고 허용 조건과 거부 조건을 함께 적어 보세요.

헷갈리는 용어와 무엇이 다른가요?

ABAC와 RBAC

RBAC는 작성자, 검토자, 관리자 같은 역할에 권한을 묶습니다. ABAC는 사용자·자원·행동·환경의 속성을 조건식으로 평가합니다. Microsoft Azure는 RBAC 역할 할당에 속성 조건을 더해 권한을 세밀하게 좁히는 방식을 안내합니다. 두 방식을 함께 쓸 수 있습니다.

ABAC와 인증

인증은 로그인한 주체가 누구인지 확인하는 과정입니다. ABAC는 인증 뒤에 들어온 요청을 허용할지 정하는 인가 방식입니다. 신원이 확인됐다고 모든 자원과 행동이 허용되는 것은 아닙니다.

ABAC와 IAM

IAM은 사용자·서비스 계정, 인증, 역할, 정책, 권한 검토를 관리하는 전체 체계입니다. ABAC는 IAM 안에서 조건부 인가를 구현하는 한 가지 접근 제어 방법입니다.

ABAC와 최소 권한

최소 권한은 업무에 필요한 만큼만 허용하라는 원칙입니다. ABAC는 세밀한 조건으로 이 원칙을 실행하는 데 도움이 됩니다. 넓은 정책이나 잘못된 속성을 쓰면 과도한 권한이 생깁니다.

속성과 태그

속성은 접근 판단에 쓰는 정보 전체를 가리킵니다. 태그는 프로젝트=Potato처럼 키와 값으로 자원이나 주체에 붙이는 대표적인 속성 표현입니다. AWS는 ABAC 속성을 태그라고 부릅니다. Azure도 접근 제어 맥락에서 속성과 태그를 함께 설명합니다.

비교 정리: 인증은 신원을 확인합니다. IAM은 신원과 접근을 관리합니다. RBAC는 역할을 중심으로, ABAC는 여러 속성과 조건을 중심으로 권한을 결정합니다.

실전에서는 어떻게 적용하나요?

1. 보호할 자원과 행동을 먼저 나눕니다

문서, 데이터셋, 모델, 프롬프트, API와 연결 도구를 적고 읽기·쓰기·삭제·공유·실행 행동을 구분합니다.

2. 믿을 수 있는 속성만 고릅니다

조직 디렉터리, 자원 관리 시스템과 승인 워크플로처럼 책임 주체가 분명한 곳에서 속성을 가져옵니다. 사용자가 임의로 바꿀 수 있는 태그를 보안 판단에 그대로 쓰지 않습니다.

3. 기본 거부에서 필요한 조건만 엽니다

정책이 없거나 속성이 비어 있을 때 허용하지 않습니다. 읽기와 삭제, 개발과 운영, 내부와 외부 전송을 별도 조건으로 나눕니다.

4. 허용과 거부 사례를 함께 시험합니다

정상 사용자뿐 아니라 다른 프로젝트 사용자, 오래된 계정, 태그가 없는 자원, 외부 네트워크와 만료된 승인도 테스트합니다.

5. 실제 결정과 속성 변경을 기록합니다

누가 어떤 속성과 정책으로 허용·거부됐는지 감사 로그에 남깁니다. 부서 이동, 프로젝트 종료와 자원 등급 변경 뒤 정책 결과도 다시 확인합니다.

주의: ABAC는 정책을 세밀하게 만들 수 있지만 복잡한 조건을 자동으로 올바르게 만들어 주지는 않습니다. 속성의 출처, 변경 권한, 빈 값 처리와 제품별 지원 범위를 먼저 확인해야 합니다.

사용할 때 무엇을 주의해야 하나요?

첫째, 오래되거나 틀린 속성을 믿지 않습니다. 퇴사자 계정에 부서 속성이 남거나 기밀 문서에 일반 등급 태그가 붙으면 정책이 정상이어도 잘못 허용할 수 있습니다.

둘째, 예외 정책이 기본 정책을 우회하지 않는지 봅니다. 관리자, 긴급 접근과 테스트 계정의 예외가 넓으면 세밀한 조건이 무력해질 수 있습니다.

셋째, 정책이 너무 복잡해지지 않게 합니다. 조건이 많고 서로 겹치면 최종 권한을 설명하기 어렵습니다. 정책 이름, 목적, 소유자, 우선순위와 만료일을 기록합니다.

넷째, 제품마다 지원하는 속성과 행동 범위가 다릅니다. Azure 공식 문서도 조건을 붙일 수 있는 자원과 작업 범위를 따로 안내합니다. 다른 클라우드나 AI 제품에 같은 규칙이 그대로 적용된다고 가정하면 안 됩니다.

다섯째, 속성 자체의 개인정보와 보안을 지킵니다. 부서, 위치, 고용 상태와 보안 등급은 민감할 수 있습니다. 정책에 꼭 필요한 속성만 사용하고 조회·수정 권한을 제한합니다.

여섯째, ABAC만으로 AI 안전을 해결하려 하지 않습니다. 접근 통제는 환각, 유해 출력, 프롬프트 인젝션과 모델 성능을 직접 해결하지 않습니다. 평가, 가드레일, 사람 승인과 사고 대응을 함께 둡니다.

자주 묻는 질문

Q1. ABAC를 쓰면 RBAC가 필요 없나요?

아닙니다. 역할로 큰 권한 묶음을 정하고 속성 조건으로 범위를 좁히는 조합이 가능합니다. Azure ABAC는 RBAC 역할 할당에 조건을 더하는 사례입니다.

Q2. ABAC의 속성은 누가 정하나요?

조직의 신원·자원 관리 담당자가 속성 이름, 허용 값, 변경 권한과 갱신 절차를 정하는 편이 안전합니다. 보안 정책에 쓰는 값은 사용자가 임의로 바꾸지 못하게 해야 합니다.

Q3. AI 에이전트에도 ABAC를 적용할 수 있나요?

가능합니다. 에이전트나 서비스 계정을 주체로 보고 프로젝트, 도구, 행동, 실행 환경과 승인 상태를 속성으로 평가합니다. 다만 사용하는 플랫폼이 필요한 조건을 실제로 지원하는지 확인해야 합니다.

Q4. RAG에서 검색 뒤에 권한을 확인해도 되나요?

답변에 권한 없는 문서 내용이 섞일 수 있으므로 검색과 컨텍스트 구성 단계부터 접근 조건을 적용하는 편이 안전합니다. 캐시와 색인에도 권한 변경이 반영되는지 시험해야 합니다.

Q5. 태그만 잘 붙이면 ABAC가 완성되나요?

아닙니다. 태그는 속성을 표현하는 방법입니다. 신뢰할 수 있는 태그 발급·변경 절차, 정책, 기본 거부, 테스트, 감사 로그와 정기 검토가 함께 있어야 합니다.

출처

마무리

속성 기반 접근 제어는 사용자, 자원, 행동과 환경의 속성을 정책과 비교해 요청마다 접근을 결정하는 인가 방식입니다. AI 에이전트와 RAG가 여러 데이터·도구에 닿을 때 역할만으로 표현하기 어려운 프로젝트, 문서 등급, 행동과 실행 조건을 세밀하게 통제합니다.

감자나라ai님이 ABAC를 검토할 때는 세 가지를 먼저 보세요. 속성을 누가 만들고 갱신하는지, 기본값이 거부인지, 허용과 거부 결과를 실제 계정과 자원으로 시험했는지입니다. 조건의 개수보다 이 세 항목이 접근 통제의 신뢰도를 보여 줍니다.