본문으로 건너뛰기

LBAC란? Casbin에서의 격자 기반 접근 제어

LBAC이란?​

**LBAC(격자 기반 접근 제어)**는 기밀성과 무결성을 하나의 프레임워크 내에서 모두 적용할 수 있는 공식 모델입니다. 이 페이지에서는 하나의 Casbin 공식을 보여줍니다: 주체와 객체는 각각 기밀성 수준과 무결성 수준을 가지며, matcher는 두 차원에서 읽기/쓰기 규칙을 적용합니다.

모델​

[request_definition]
r = sub, subject_confidentiality, subject_integrity, obj, object_confidentiality, object_integrity, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = (r.act == "read" && r.subject_confidentiality >= r.object_confidentiality && r.subject_integrity >= r.object_integrity) || (r.act == "write" && r.subject_confidentiality <= r.object_confidentiality && r.subject_integrity <= r.object_integrity)

주체의 기밀성과 무결성이 모두 객체의 수준 이상일 때 읽기가 허용되고, 둘 다 객체의 수준 이하일 때 쓰기가 허용됩니다. 따라서 기밀성은 BLP와 유사한 규칙을 따르고 무결성은 Biba와 유사한 규칙을 따르며, 이는 단일 matcher에서 이루어집니다.

예제 요청​

다음 예제는 이 LBAC 구현이 요청을 평가하는 방식을 보여줍니다:

# Normal read operations (ALLOWED)
admin, 5, 5, file_topsecret, 3, 3, read      # admin (conf:5, int:5) reads file_topsecret (conf:3, int:3) - ALLOWED
manager, 4, 4, file_secret, 4, 2, read       # manager (conf:4, int:4) reads file_secret (conf:4, int:2) - ALLOWED
staff, 3, 3, file_internal, 2, 3, read       # staff (conf:3, int:3) reads file_internal (conf:2, int:3) - ALLOWED
guest, 2, 2, file_public, 2, 2, read         # guest (conf:2, int:2) reads file_public (conf:2, int:2) - ALLOWED

# Read operation violations (DENIED)
staff, 3, 3, file_secret, 4, 2, read         # staff (conf:3, int:3) reads file_secret (conf:4, int:2) - DENIED (conf < obj.conf)
manager, 4, 4, file_sensitive, 3, 5, read    # manager (conf:4, int:4) reads file_sensitive (conf:3, int:5) - DENIED (int < obj.int)
guest, 2, 2, file_internal, 3, 1, read       # guest (conf:2, int:2) reads file_internal (conf:3, int:1) - DENIED (conf < obj.conf)
staff, 3, 3, file_protected, 1, 4, read      # staff (conf:3, int:3) reads file_protected (conf:1, int:4) - DENIED (int < obj.int)

# Normal write operations (ALLOWED)
guest, 2, 2, file_public, 2, 2, write        # guest (conf:2, int:2) writes file_public (conf:2, int:2) - ALLOWED
staff, 3, 3, file_internal, 5, 4, write      # staff (conf:3, int:3) writes file_internal (conf:5, int:4) - ALLOWED
manager, 4, 4, file_secret, 4, 5, write      # manager (conf:4, int:4) writes file_secret (conf:4, int:5) - ALLOWED
admin, 5, 5, file_archive, 5, 5, write       # admin (conf:5, int:5) writes file_archive (conf:5, int:5) - ALLOWED

# Write operation violations (DENIED)
manager, 4, 4, file_internal, 3, 5, write    # manager (conf:4, int:4) writes file_internal (conf:3, int:5) - DENIED (conf > obj.conf)
staff, 3, 3, file_public, 2, 2, write        # staff (conf:3, int:3) writes file_public (conf:2, int:2) - DENIED (both > obj)
admin, 5, 5, file_secret, 5, 4, write        # admin (conf:5, int:5) writes file_secret (conf:5, int:4) - DENIED (int > obj.int)
guest, 2, 2, file_private, 1, 3, write       # guest (conf:2, int:2) writes file_private (conf:1, int:3) - DENIED (conf > obj.conf)

보안 수준​

이 구현에서는 기밀성과 무결성을 모두 정수로 표현하며, 값이 높을수록 보안 수준이 높음을 나타냅니다:

기밀성 수준​

  • 레벨 1: 공개/비밀 없음(Public/Unclassified)
  • 레벨 2: 비밀(Confidential)
  • 레벨 3: 극비(Secret)
  • 레벨 4: 최상위 기밀(Top Secret)

무결성 수준​

  • 레벨 1: 낮은 무결성 (예: 공개 데이터, 사용자 생성 콘텐츠)
  • 레벨 2: 중간 무결성 (예: 검증된 데이터, 신뢰할 수 있는 출처)
  • 레벨 3: 높은 무결성 (예: 시스템 데이터, 관리자 콘텐츠)
  • 레벨 4: 중요한 무결성 (예: 보안 정책, 시스템 구성)

적용 가능한 시나리오​

이 LBAC 구현은 다음에 적합합니다:

  • 다중 레벨 보안 환경
  • 데이터 보호와 데이터 정확성 모두 중요한 애플리케이션

구현 참고 사항​

  • 이 모델은 이중 보안 속성을 가진 강제 접근 제어(MAC)를 구현합니다
  • 시스템 관리자가 보안 수준을 할당합니다
  • 접근 결정은 기밀성 및 무결성 수준을 모두 고려합니다
  • Model은 정보 유출 및 데이터 손상을 방지합니다

FAQ​

LBAC과 MAC의 차이점은 무엇인가요? MAC은 카테고리입니다: 접근 권한은 리소스 소유자가 아닌 시스템이 할당한 레이블에 의해 결정됩니다. LBAC은 보안 수준의 격자(lattice)를 사용하여 MAC을 구현하는 한 가지 방법입니다. 이 페이지의 Model은 기밀성 및 무결성 수준을 동일한 격자에 포함시킵니다.

LBAC은 RBAC과 어떻게 다른가요? RBAC은 사용자가 보유한 역할에 권한을 부여하지만, LBAC은 역할에 아무것도 부여하지 않습니다. 모든 요청에는 주체(subject)와 객체(object)의 수준이 포함되며, matcher가 이를 비교하므로 사용자별 정책을 유지할 필요가 없습니다.

LBAC과 RBAC을 결합할 수 있나요? 예. RBAC의 역할 검사를 유지하고 동일한 matcher에 수준 비교를 추가하세요. access control models 페이지는 RBAC과 ABAC에 대해 동일한 개념을 보여줍니다.

Comments are powered by giscus and GitHub Discussions. They load from giscus.app and GitHub only after you click the button below.