[정보보호론] Lecture4. Authorization

※ 이 카테고리의 글들은 knu JY.Lee 교수님의 <정보보호론> 수업을 듣고 나름대로 필자가 정리한 글입니다.

※ 부족한 설명이 있거나, 잘못 알고 작성한 부분이 보인다면 편하게 댓글로 알려주시면 정말 감사하겠습니다😊

 

Recap _ 3장 내용을 복습해 봅시다!

• 인증 authentication: 인증은 사용자가 누구인지 확인하는 과정으로, 다양한 방식이 존재합니다. 
• 비밀번호 기반 인증: 비밀번호는 여전히 가장 널리 사용되는 인증 수단 중 하나입니다.
  • 해시와 솔트 사용: 비밀번호를 단순히 저장하는 대신, 해시 함수(hash function)를 이용해 암호화하고, 추가적으로 솔트(salt)를 사용하여 보안을 강화하는 것이 권장됩니다. 솔트는 각 비밀번호에 고유한 무작위 값을 추가해 동일한 비밀번호가 같은 해시 값을 가지지 않도록 하는 역할을 합니다. 이는 공격자가 해시된 비밀번호 데이터베이스를 역으로 추측하는 것을 어렵게 만듭니다.
  • 응답 메시지 표시 주의: 사용자가 로그인할 때 잘못된 비밀번호나 ID를 입력했을 때 표시되는 응답 메시지에 주의해야 합니다. 잘못된 정보 제공은 공격자에게 유용한 정보를 줄 수 있기 때문에, "잘못된 비밀번호" 또는 "존재하지 않는 사용자"와 같은 구체적인 메시지보다는 일반적인 오류 메시지를 사용하는 것이 좋습니다.
• 강력한 비밀번호의 요구 사항: 비밀번호는 짧고 단순할수록 쉽게 추측당할 수 있기 때문에, 복잡하고 긴 비밀번호를 사용하는 것이 중요합니다. 일반적으로 대문자, 소문자, 숫자, 특수문자를 포함한 조합을 사용해야 하며, 충분히 길어야(최소 8 자 이상) 안전성을 높일 수 있습니다.
• 다중 인증(MFA): 다중 인증은 한 가지 이상의 인증 요소를 요구하는 방식입니다. 예를 들어, 비밀번호뿐만 아니라 추가적으로 OTP(일회용 비밀번호)나 생체 정보(지문, 얼굴 인식 등)를 요구하는 방식입니다. 이렇게 하면 한 가지 인증 수단이 탈취되더라도 추가적인 보안 레이어가 있어 안전성을 높일 수 있습니다.

---

1. What is authorization

Access Control: 접근 제어는 특정 정보나 자원에 대해 누가 접근할 수 있는지를 결정하는 방법입니다. 이는 보안을 위해 첫 번째로 방어해야 할 중요한 영역입니다. 만약 올바른 접근 제어가 설정되지 않으면, 권한이 없는 사용자가 중요한 데이터나 시스템 자원에 접근하여 공격을 시도할 수 있습니다.

 

❗Authentication 인증 vs Authorization 권한 부여

Authentication: 인증은 누가 시스템에 접근할 수 있는지를 결정하는 과정입니다. 즉, 사용자가 주장하는 신원이 실제로 맞는지를 확인하는 절차입니다.

Authorization: 권한 부여는 인증을 통과한 사용자가 어떤 작업을 수행할 수 있는지를 결정하는 과정입니다. 즉, 사용자가 특정 리소스나 데이터를 액세스 하거나 시스템에서 특정 작업을 수행할 수 있는 권한이 있는지 확인합니다.

• Authorization(권한 부여)는 access control(접근 제어)의 한 형태입니다. 접근 제어는 인증된 사용자에 대해 어떤 자원에 접근할 수 있는지를 결정하는 것을 의미하며, 권한 부여를 통해 각 사용자의 권한을 세밀하게 관리할 수 있습니다.
• Principle of Least Privilege: 최소 권한 원칙은 시스템에서 사용자나 프로세스가 수행할 수 있는 작업을 필요한 최소한의 권한으로 제한하는 것을 말합니다. 사용자는 업무를 수행하기 위해 꼭 필요한 권한만을 가져야 하며, 그 이상은 부여되지 않아야 합니다.

>> 인증과 권한 부여의 차이: 인증이 사용자가 누구인지를 확인하는 절차라면, 권한 부여는 인증된 사용자가 시스템 내에서 무엇을 할 수 있는지를 제한하는 과정입니다. 이 두 개념은 시스템 보안의 기본적인 기초를 이루며, 인증이 선행된 후 권한 부여가 이루어집니다

---

2. Representations of access control

❗접근 제어에서 사용되는 기본적인 용어에 대해 알아봅시다.

• Subjects (주체):
  • 사용자가 될 수 있으며, 그룹 또는 작업을 수행할 수 있는 프로세스입니다.
• Objects (객체):
  • 파일, 디렉토리, 문서, 장치 등 접근 권한을 설정해야 하는 자원입니다.
• Rights (권한):
  • 객체에 대해 허용되는 다양한 접근 모드입니다. 예를 들어, 읽기(read), 쓰기(write), 실행(execute), 삭제(delete) 등이 있습니다.
• Principals (원칙):
  • 접근 제어의 단위로, 한 컨텍스트 내(특정한 상황이나 환경)에서 인증된 사용자입니다. 사용자는 여러 컨텍스트에서 여러 가지 역할을 가질 수 있습니다.
  • 사용자와 주체 간의 관계는 하나의 원칙이 여러 사용자를 가질 수 있다는 의미로 설명됩니다.

 

❗Reference Monitor 참조 모니터

사용자(주체)는 자원(객체)에 접근할 때 참조 모니터(빨간색으로 표시된 영역)을 거친다.

 

 

참조 모니터의 역할에는 Policy(정책)과 Enforcement(집행)이 있습니다.

• Policy: 누가 어떤 자원에 접근할 수 있는지 결정합니다.
• Enforcement: 정의된 접근 제어 정책에 따라 승인된 접근만 허용됩니다.

 

참조 모니터의 세 가지 핵심 속성:

• 완전한 중재(Complete Mediation): 모든 접근 시도는 참조 모니터를 거쳐야 합니다.
• 격리(Isolation): 참조 모니터는 승인되지 않은 변경으로부터 보호되어야 합니다.
• 검증(Verification): 정책이 보안 규칙을 준수하는지 확인할 수 있어야 합니다.

 

 

❗그럼 이제 시스템 상에서 접근 제어를 어떻게 표현하고 관리하는지 알아봅시다.

(1) Access Control Matrix (ACM)

ACM

접근 제어와 관련된 상태를 추상화한 표로, 사용자가 자원에 대해 어떤 권한을 가졌는지 정보가 나타나 있습니다.

ACM은 시스템 내의 자원에 대한 접근 권한을 체계적으로 나타내는 중요한 도구이지만, 이 매트릭스가 커지면 공간적인 문제가 발생할 수 있으며, 이를 효과적으로 시스템 내에서 어떻게 표현할 것인지가 중요합니다.

 

(2) Access Control Lists (ACLs)

ACLs

 

각 객체마다 ACL이 존재하며, 각 ACL은 해당 객체에 대해 어떤 주체가 어떤 권한을 가질 수 있는지 나타냅니다. 따라서 주체가 해당 객체에 대해 권한을 가지고 있는 경우에만 요청이 승인됩니다.

 

❗Confused Deputy Problem

Confused Deputy Problem은 권한을 올바르게 관리하지 못할 때 발생하는 문제입니다. 주체(Deputy)는 원래 의도와 다른 작업을 수행할 수 있는 권한을 가진 경우가 생길 수 있습니다. 이를 예방하기 위해서 주체가 객체에 대해 가질 수 있는 권한을 제한하고, 주체가 올바른 작업을 수행하는지 검증하는 메커니즘이 필요합니다.

grade.txt에 접근해서는 안되지만 권한을 가지고 접근하는 모습

 

 

❗Preventing Confused Deputy Attack

• Confused Deputy Attack은 프로그램이나 시스템이 권한을 부적절하게 사용할 수 있도록 속이는 공격입니다.
• 이 공격을 방지하기 위해 시스템은 다음과 같은 접근 방식을 사용해야 합니다:
  • 각 요청이 명시적 권한을 통해 수행되도록 설정합니다.
  • 권한 전달을 엄격히 제한하여 대리인이 잘못된 권한을 행사하지 않도록 해야 합니다.

권한 전달을 제한하여 권한 남용을 억제할 수 있습니다.

 

❗Ambient Authority

Ambient Authority란 주체가 명시적으로 선택하지 않아도 자동으로 행사되는 권한을 의미하며, Access Control List (ACL)와 같은 기존 접근 제어 방식에서 자주 발생하는 문제입니다. 이러한 Ambient Authority는 보안에 있어 최소 권한 원칙(Principle of Least Privilege)을 위반하는 상황을 초래할 수 있습니다. (즉, 사용자가 작업을 수행하는 데 필요한 것보다 더 많은 권한을 가질 수 있게 되어 잠재적인 보안 위험이 발생할 수 있습니다.)

Ambient Authority

 

(3)  Capability-based Approach 능력 기반 접근 제어

능력 기반 접근 제어에서 Capabilities(능력)은 객체에 대한 특정 작업을 수행할 수 있는 권리를 뜻하며, 이러한 권리는 주체에게 전달 가능합니다. 이 방식은 객체와 해당 객체에 대한 권한을 묶어서 관리합니다. 즉, 객체에 접근할 때 해당 권한이 함께 전달됩니다.

• 예시: int fd = open("/etc/passwd", O_RDWR);에서 fd는 파일에 대한 권한을 설명하며, 해당 프로그램이 데이터를 받을 때처럼 권한도 함께 받습니다.
• 이러한 접근 방식은 KeyKOS와 같은 보안 중심 운영 체제에서 많이 사용됩니다.

 

✨ ACL vs Capability

• ACL (Access Control List): "각 객체에 대해, 어떤 주체가 권한을 가지고 있는가?"를 관리하는 방식입니다.
  • 이 방식은 Confused Deputy Problem에 취약할 수 있습니다.
  • 객체를 기준으로 접근 권한을 설정하는 방식으로, 보안 관리가 쉬운 대신 특정 시나리오에서 취약할 수 있습니다.
• Capabilities: "각 주체에 대해, 어떤 객체에 접근할 수 있는가?"를 관리하는 방식입니다.
  • 더 보안적이며, Confused Deputy 문제를 방지할 수 있습니다.
  • 각 주체가 객체에 대한 명확한 권한을 가지고 있으므로, 자원에 대한 접근이 보다 안전하게 관리됩니다.

 

접근 제어 모델 선택에 있어 영향을 미치는 요소들 : 효율성(Efficiency), 책임성(Accountability), 권한 철회(Revocation)

• 책임성(Accountability): 누가 해당 파일에 접근할 수 있는지 명확히 관리하는 것
• 철회(Revocation): 파일 소유자가 다른 사용자의 접근을 철회할 수 있는지 여부

 

---

3. Access Control Policy

사용자가 어떻게 적절한 수준의 권한을 부여받을 수 있을까요? 여러 모델을 알아봅시다!

Discretionary Access Control (DAC):

• 사용자가 자신이 소유한 자원에 대해 다른 사용자에게 어떤 권한을 부여할지 선택할 수 있는 방식입니다. 즉, 자원의 소유자가 권한을 통제합니다.
• 예: 파일의 소유자가 특정 사용자에게 읽기, 쓰기 권한을 직접 부여하는 경우.
• 문제점:
  • 데이터 공유 방식에 대한 제한: 사용자는 특정 데이터가 어떻게 공유될지 세세하게 제어하기 어렵습니다.
  • 정보 흐름 제어 불가능 (cannot control information flow): 파일을 공유받은 사용자가 해당 파일을 다른 사람에게 다시 공유할 가능성을 제어할 수 없습니다. 즉, 정보의 흐름을 통제하는 데 한계가 있습니다.
• 이러한 문제를 해결하기 위해 대안으로 아래의 MAC가 제안됩니다.

 

Mandatory Access Control (MAC):

• 오직 시스템 관리자만이 권한을 설정하고 부여할 수 있는 방식입니다. 사용자 스스로는 권한을 조정할 수 없습니다.
• Discretionary Access Control (DAC)보다 더 제한적이고 보안성이 높습니다. 이는 MAC이 데이터 접근과 관련된 위험을 더 잘 통제할 수 있다는 의미입니다.
• 주요 개념: 시스템이 주체(subject)와 객체(object)에 특정한 보안 속성을 할당하여 접근을 통제합니다. 즉, 주체와 객체가 각각의 보안 속성에 따라 접근 권한이 결정됩니다.
• 보안이 매우 중요한 환경에서 사용되며, 군사 시스템에서 흔히 사용됩니다.
• 예: 보안 등급이 다른 문서에 접근하기 위해 반드시 관리자의 승인이 필요한 경우.

 

❗MAC의 구현 방법: Multi-level security

• 사용자와 문서의 보안 레벨:
  • 사용자와 문서 모두 특정 보안 레벨이 할당됩니다. 이 보안 레벨은 문서의 민감도와 사용자의 보안 인가 상태에 따라 다릅니다.
  • 문서에는 민감도(sensitivity)나 분류(category)가 부여되고, 사용자는 보안 인가(clearance)나 필요성(need-to-know requirements)에 따라 분류됩니다.
• 접근 허용 조건:
  • 사용자가 접근하려는 대상(문서, 정보 등)의 보안 레벨보다 사용자의 보안 레벨이 같거나 높을 때 접근이 허용됩니다. 

Security Label

 

위 이미지는 보안 레이블에 관한 것으로, 두 가지 속성을 가지고 있습니다.

 

• Security level(보안 등급):
  • 보안 등급은 문서나 데이터의 민감도를 나타내며, 계층적으로 정렬된 집합으로 표현됩니다.
  • 예시: UNCLASSIFIED(비밀 아님) < CONFIDENTIAL(기밀) < SECRET(비밀) < TOP SECRET(최고 비밀). 이 순서는 민감도에 따라 정렬된 것입니다.
  • 더 높은 보안 등급을 가진 데이터는 더 많은 보호가 필요합니다.
• Compartment(구획):
  • 구획은 데이터의 성격을 분류하는 카테고리 집합을 설명합니다.
  • 예시로는 군사(Army), 핵(Nuclear), 화학(Chemical) 같은 범주들이 있습니다. 이는 데이터가 속하는 특정 분야를 나타냅니다.

 

❗보안 레이블의 비교

보안 레이블은 방금 설명했듯이, 보안 등급과 구획으로 이루어져 있습니다.

보안 레이블 간의 비교에는 다음의 조건을 따릅니다.

comparing label

 

• 보안 레벨(S):
  • 보안 레벨은 완전히 순서가 정해진 구조로, 상위 레벨이 하위 레벨보다 더 높은 보안을 요구합니다.
  • 예: TOP SECRET(TS) > SECRET(S) > CONFIDENTIAL(C) > UNCLASSIFIED(U).
• 구획(C):
  • 구획은 부분적으로만 순서가 정해질 수 있는 집합입니다. 즉, 구획 간에 비교가 어려운 경우가 있을 수 있습니다.

 

 

문제를 하나 풀어봅시다!

먼저, l1은 l2보다 높은 등급이 맞습니다. 보안 등급이 l1이 l2보다 높으면서 l1이 l2의 구획을 모두 포함하고 있기 때문입니다.

하지만, l1은 l3와 비교하기 어렵습니다. 보안등급은 l1이 l3보다 높지만, l1의 구획이 l3의 구획과 완전히 겹치지 않기 때문입니다.

 

Role-Based Access Control (RBAC):

• 사용자의 접근 권한이 그들이 맡은 역할에 따라 결정됩니다. 즉, 역할이 권한을 정의하고, 사용자는 역할에 따라 권한을 부여받습니다.
• 예: 회사의 '관리자' 역할이 시스템의 설정을 변경할 수 있는 권한을 갖고, '일반 사용자'는 읽기 권한만 가지는 경우.

 

Attribute-Based Access Control (ABAC):

• 개체의 속성을 기반으로 접근 결정을 내리는 방식입니다. 개체나 사용자에 대해 정의된 속성(예: 부서, 나이, 시간대 등)에 따라 권한이 부여됩니다.
• 예: 특정 시간에만 특정 자료에 접근할 수 있는 정책.

---

(1) The Bell-LaPadula Model (BLP)

BLP 모델은 1973년에 제안된 다단계 보안 시스템의 첫 번째 수학적 모델로, 정보 유출을 방지하는 데 중점을 둡니다. 이 모델의 주요 목표는 기밀성(confidentiality)을 보호하는 것입니다. (기밀성 - 허가되지 않은 접근이나 정보 노출을 방지)

주요 개념:

• NO READ UP (Simple Property):

• 낮은 보안 레벨의 사용자는 더 높은 보안 레벨의 객체를 읽을 수 없습니다.
• 예를 들어, Unclassified(비밀 아님) 프로세스는 Secret(비밀) 파일을 읽을 수 없습니다.

• NO WRITE DOWN (*-Property):

• 높은 보안 레벨의 사용자는 더 낮은 보안 레벨의 객체에 쓸 수 없습니다.
• 예를 들어, Secret(비밀) 프로세스는 Unclassified(비밀 아님) 파일에 쓸 수 없습니다.

 

(2) The Biba Model

Biba 모델은 무결성(integrity)을 보호하기 위한 접근 제어 모델로, Bell-LaPadula 모델(BLP)의 반대 개념을 따릅니다. BLP가 기밀성을 보장하기 위해 설계된 반면, Biba 모델은 데이터의 무결성을 유지하는 데 중점을 둡니다. (무결성 - 정보가 허가되지 않은 방법으로 변경되거나 손상되지 않도록 보장하는 것)

주요 개념:

• NO READ DOWN (*-Property):
  • 높은 보안 레벨을 가진 주체는 더 낮은 레벨의 객체를 읽을 수 없습니다. 이는 무결성을 보장하기 위한 규칙으로, 낮은 신뢰도의 데이터를 읽는 것이 금지됩니다.
  • 예: Secret(비밀) 프로세스는 Unclassified(비밀 아님) 파일을 읽을 수 없습니다.
  • 왜 높은 등급의 사용자가 읽지도 못하게 할까요? 만약 높은 신뢰도를 요구하는 주체(사용자)가 낮은 신뢰도를 가진 데이터에 접근해서 그 데이터를 참조하거나 의사결정에 사용하게 된다면, 신뢰성이 낮은 정보가 높은 등급의 의사결정에 영향을 미치게 됩니다. 이는 전체 시스템의 무결성을 해칠 수 있습니다.
• NO WRITE UP (Simple Property):
  • 낮은 보안 레벨을 가진 주체는 더 높은 레벨의 객체에 쓸 수 없습니다. 이는 낮은 신뢰도의 데이터가 높은 신뢰도의 데이터로 기록되지 않도록 방지하는 규칙입니다.
  • 예: Unclassified(비밀 아님) 프로세스는 Secret(비밀) 파일에 쓸 수 없습니다.

---

보안 레이블이 사용되는 예시를 알아봅시다

1. 군사 환경(DoD, Department of Defense 모델):
   • 군사 시스템에서는 보안 레이블이 보안 인가 수준(clearance level)과 구획(compartment)을 포함합니다.
   • 이러한 시스템은 정보의 기밀성을 보호하고, 정보 접근이 엄격하게 관리됩니다.
2. 상업 환경(Commercial 모델):
   • 상업 환경에서는 보안 레이블이 이해 상충(conflict-of-interest)이나 직무 분리(separation-of-duty)와 같은 다른 속성들을 관리하는 데 사용됩니다.
   • 상업 환경에서는 사용자 인가 수준(user clearance)이 흔하지 않습니다. 즉, 군사 시스템처럼 엄격한 보안 인가 절차는 덜 적용되는 경우가 많습니다.

 

❗Chinese Wall Policy 중국의 장벽 정책

이 정책의 주요 목적은 이해 상충(conflict-of-interest)을 방지하는 것입니다. 

 

• 예를 들어, 한 사용자가 CD1(Company Datasets 1)의 객체인 O1, O2, O3에 접근했다면, 동일한 이해 상충 클래스(CIC)에 속하는 CD2(Company Datasets 2)의 객체 O4에 접근할 수 없습니다.
• 이를 통해 사용자가 두 개 이상의 경쟁 회사의 데이터에 접근하여, 정보의 유출이나 이익 충돌을 막는 데 중점을 둡니다.

---

Summary

• Access Control(접근 제어):
  • 사용자가 어떤 권한을 가지는지를 결정하는 보안 절차입니다.
• ACLs(Access Control Lists)와 C-Lists(Capability Lists):
  • 접근 제어를 구현하는 두 가지 방법입니다.
  • ACL 기반은 사용이 더 편리하지만, C-List 기반은 보안이 더 강화됩니다.
• Discretionary Access Control(DAC):
  • 자원의 소유자가 접근 권한을 결정할 수 있는 방식입니다. 즉, 소유자가 자유롭게 권한을 설정합니다.
• Mandatory Access Control(MAC):
  • 관리자가 접근 권한을 통제하는 방식입니다. 시스템 관리자에 의해 정책이 설정되고, 사용자는 이를 따릅니다.
• BLP vs Biba (MAC 모델):
  • **BLP 모델(Bell-LaPadula Model)**은 기밀성(confidentiality)을 보호하기 위한 모델로, 정보 유출을 방지하는 데 중점을 둡니다.
  • Biba 모델은 무결성(integrity)을 보장하기 위한 모델로, 정보의 변조를 방지하는 데 초점을 맞춥니다.
• 모델 선택:
  • 시스템의 요구 사항과 목표에 따라, 적절한 접근 제어 모델 또는 모델의 조합을 선택해야 합니다.

 

다음 글에서는 암호학에 대해 배워봅시다😆