Security - Security Policies, Models, and Trust

정현철·2023년 4월 19일
0

Security

목록 보기
3/4

기본적으로 Security Model을 만드는 과정은
Threat model ➔ security policy ➔ security mechanism ➔ security model
의 순서로 진행된다.

  1. Thread Model
    시스템이나 조직, 기관에 어떤 위협이나 공격이 가해질 수 있는지 분석하는 것. 어떤 공격자가 어떤 공격을 가할지 분석하는 것으로 이해할 수 있다.
  2. Security Policy
    Systems / Organizations / Entities에 대한 Protection goal을 정의하는 것. 어떤 데이터에 무슨 엑세스를 허용하고, 어디에는 제한하고 하는 등을 여기서 정의한다.
  3. Security Mechanism
    Security Policy를 enforce하기 위해 사용되는 구체적인 기술이나 방법. Prevention, Detection, Recovery, Awareness등 을 구현하는 기술적 방법을 사용하여 Policy를 어떻게 적용할지에 대한 내용이 이것이다.
  4. Security Model
    보안 정책과 메커니즘을 명확하게 정의하는 것. Policy를 매커니즘으로 어떻게 구현할지 설명하는 것. 그래서 시스템 보안을 분석하거나 설계, 구현 단계에서 실시한다.

Security Policy

Policy는 일반적으로 제약 조건이라고 보면 된다. 보안에 관련된 목표를 달성하기 위하여, subject가 특정한 object에 어떤 action을 할 수 있느냐/없느냐 그 제약을 설정해둔 것이 Policy.

다음 다섯 개의 요소로 구성된다.

  • Subjects: 시스템과 상호작용하는 entities
  • Objects: policy가 보호하고 있는 모든 resource
  • Actions: SubjectObject에게 할 수 있는(혹은 없는) 작업 자체
  • Permissions: Subject-Object-Action의 조합(mapping)이다. 누가, 무엇에 대해, 어떤 일을 할 수 있다(없다)를 정의하는 것
  • Protections: Policy를 시행하는 데 도움이 되는 규칙이나 메커니즘

example) Password Policy

  • Requirement when composing a password, avoiding

    • The one from previously breached corpora (e.g., “passw0rd”)
    • The one that contains a dictionary word (e.g., “house123”)
    • The one that contains repetitive letters (e.g., “aaaa”)
    • The one that contains sequential letters (e.g., “abcd”)
    • The one that holds context-specific words like a service name or user name (e.g., “facebook1”)
  • Deprecated requirement

    • Composition rule: a mixed form of upper/lower case letters, digits, and symbol characters
    • Study shows that a complex password does not the entropy of the security

Security Model

Policy를 시행하고 구체화하는 scheme.
시스템은 엄청 크고 복잡하며, 동적 요소가 많다. 그래서 manage하기 힘든데, 이에 따라 간단한 모델로 추상화하여 다룬 것이 Security Model이다.
그래서 여기서는 정확히 어떤 방식으로 구현해라(how to implement)가 아니라, policy를 적용하기 위해서 무엇이 필요하고 해야하는지(what needs to be done)를 정의한다.
Models are descriptive, not prescriptive.

e.g., Access Control(Authorization)

  • who has access to what에 대한 description.
  • Access control rights를 나타내는 방법이 필요하다. -> Model
    • Access control lists
    • Capabilities
  • 그리고 subject와 object에게 grant specific rights를 하는 방법 역시 필요하다.
    • Object: a set of protected entities(files, directories, devices, recources, ...)
    • Subject: a set of active objects(users, groups, processes, systems, ...)
    • Rights: a set of possible actions(read, write, execute, own, append, ...)

Model 1: ACM(Access Control Matrix)

Abstract representation of system's security state

  • 각 cell은 subject와 object, 그리고 그 combination에 부여되는 rights를 나타낸다.
  • Empty cell(-)은 granted right가 없음을 나타낸다.

그런데 이거 개념은 유용하지만, practical하지는 않다.
1. Size: number of subjects * objects만큼의 cell이 무조건 필요하다.
2. Efficiency: 실사용 환경에서 너무 많은 cell이 empty(no access)이거나 동일한 값을 갖게 된다(default permission)
3. Management: Subject나 Object의 addition/removal을 하기 위해서는 복잡한 작업(non-trivial operations)가 필요하다.

Model 2: ACL(Access Control List)

List of permissions attached to an object

  • 이런 방식을 Object-centered approach라 한다. enumeration of all subjects and their access for given object.
  • 그래서 permission 정보를 object와 함께 object의 메타데이터에 바로 적용해둘 수 있다.
  • No entry in the ACL -> subjects has no rights
  • 그래서 이건 access control의 column을 저장하는 거라고 볼 수 있다.

Advantage: Dramatically smaller size (empty cells are collapsed)

Disadv: No efficient way to enumerate all the rights of a given subject

이때 default permission의 facilitate를 위해 위 기본 법칙과는 다른 efficient implementation 여지가 있다.

  • 만약 특정 object에 동일한 권한을 가진 수많은 subject가 있다면, 각자 separate entries를 사용할 때 불필요한 낭비가 발생한다.
  • 그래서 wildcard를 사용하는 등으로 개선할 수 있을 것이다. match any unnamed subject인 right가 있다면 와일드카드 써버리면 됨.
  • default permission뿐만 아니라 groups of subjects에도 이러한 방법을 적용해서 개선할 수 있다.

예시로, Unix file permission이 있다.

A form of abbreviated ACL

  • A list of permissions attached to each file
  • Users are divided into three classes: owner, group, all
  • Separate read (r), write (w), and execute (x) permissions per class
  • One octal digit (3 bits) per class, with R=4, W=2, X=1
  • rw-r----- (640) Owner: RW, Group: R, All: none

이 방식을 Coarse-grained control이라고 한다.

  • 예를 들어, "bob을 제외한 모두"에게 권한을 주고 싶다고 하자.
  • Must create a group of all users except Bob.이렇게 특정 그룹에만 특정 권한을 부여하는 배열을 "Non-standard arrangement"(비표준 배열)라 한다. (cumbersome: only root can create groups)

Model 3: Capabilities

List of access rights granted to a subject

  • 그래서 이번 경우에는 subject-centered approach다.

0개의 댓글