0x03 접근 제어 (Access Control)

접근 제어의 전제 조건

사용자 인증 성공 (Lecture 0x02)
         ↓
완전한 중재 원칙 적용 (Lecture 0x01)
         ↓
접근 제어 메커니즘 동작

완전한 중재 (Complete Mediation)

모든 자원에 대한 모든 접근은 시스템의 접근 제어 메커니즘을 통해야 함

메모리 접근 제어

커널이 페이지 테이블 유지 관리:
┌─────────────┬─────────────┐
│ 커널용      │ 사용자 프로세스용 │
│ 페이지 테이블 │ 페이지 테이블   │
└─────────────┴─────────────┘
         ↓
메모리 권한 제어
• 코드: 수정 불가
• 읽기 전용 데이터: 수정 불가

시스템 콜 접근 제어

┌─────────────────────────────┐
│      User Space            │ ← Ring 3
├─────────────────────────────┤
│      Kernel Space          │ ← Ring 0
├─────────────────────────────┤
│       Hardware            │
└─────────────────────────────┘

커널 권한:              사용자 권한:
• 하드웨어 직접 접근     • 시스템 콜로만 접근
• 시스템 상태 변경 가능  • 시스템 상태 변경 불가

1. 접근 제어 정책 (Access Control Policies)

1.1 기밀성 정책 모델 (Confidentiality Policy Model)

목표

• 정보의 무단 공개 방지 (정보 흐름 통제)
• 다단계 보안(MLS) 모델이 대표적 예시

Bell-LaPadula 모델 (BLP)

보안 분류 체계 (높은 순):
Top Secret(TS) > Secret(S) > Confidential(C) > Unclassified(U)
      4            3              2                1

BLP의 핵심 원칙

주체(Subject) S, 객체(Object) O
L(S): 주체의 보안 허가 등급
L(O): 객체의 보안 분류 등급

1. No Read Up (읽기 제한)

S가 O를 읽을 수 있는 조건: L(O) ≤ L(S)
낮은 등급만 읽기 가능 (Read Down만 허용)

2. No Write Down (쓰기 제한)

S가 O에 쓸 수 있는 조건: L(S) ≤ L(O)
높은 등급에만 쓰기 가능 (Write Up만 허용)

실제 사례

No Read Up 예시

Private Ryan (L(S)=1) 
    ↓ 접근 불가
핵 미사일 위치 정보 (L(O)=4)

No Write Down 예시

Private Ryan이 외계인 발견
    ↓
Top Secret 보고서 작성 (L(O)=4)
    ↓
대통령만 읽기 가능 (L(S)=4)
    ↓
대통령은 보도자료 작성 불가 (L(O)=1)
(기밀 정보 누출 위험)

💡 추가 정보: Bell-LaPadula 모델은 군사 및 정부 기관에서 수십 년간 사용되어 온 검증된 모델이며, 현재도 기밀 정보를 다루는 시스템의 기본 설계 원칙으로 활용됩니다.

2. 접근 제어 정책 유형

2.1 임의 접근 제어 (DAC: Discretionary Access Control)

특징:
• 사용자 신원 기반 접근 제한
• 객체 소유자가 접근 권한 제어
• 유연하고 사용하기 쉬움

예시: $ chmod 777 myfile

장점:

• 구현이 간단
• 사용자 친화적
• 대부분의 운영체제에서 지원

단점:

• 정보 유출 위험
• 중앙 통제 어려움

2.2 강제 접근 제어 (MAC: Mandatory Access Control)

특징:
• 객체 소유자가 접근 제어 불가
• 중앙 관리자만 접근 권한 제어
• 보안 정책 강제 적용

사용 예: 군사기관, 정부기관, icampus(?)

장점:

• 강력한 보안
• 일관된 정책 적용
• 정보 유출 위험 최소화

단점:

• 복잡한 관리
• 사용자 불편
• 구현 비용 높음

2.3 역할 기반 접근 제어 (RBAC: Role-Based Access Control)

RBAC 구조:
사용자 → 역할 → 권한 → 자원
User → Role → Permission → Resource

RBAC의 주요 특징

1. 권한 관리: 사용자를 역할에 할당하고 역할에 권한 부여
2. 계층적 역할: 역할 계층에 따른 권한 상속
3. 최소 권한: 특정 작업에 필요한 최소 권한으로 로그인
4. 직무 분리: 단일 사용자에게 과도한 권한 부여 방지
5. 객체 분류: 분류에 따른 객체 그룹화

예시 역할 계층:
     CEO
      ↓
   Manager
      ↓
   Employee
      ↓
    Guest

권한 상속: 상위 역할은 하위 역할의 모든 권한 포함

💡 추가 정보: RBAC는 현대 엔터프라이즈 시스템에서 가장 널리 사용되는 접근 제어 모델입니다. 조직의 구조와 업무 프로세스를 반영하여 효율적인 권한 관리가 가능합니다.

3. 접근 제어 구현 방법

3.1 접근 제어 행렬 (Access Control Matrix)

Butler W. Lampson (1971) 제안

접근 제어 행렬:
        Insurance  Medical   Payroll
Alice      read     read      -
Bob        read      -       read
Charlie     -       read     read

• 행 (Rows): 주체 (사용자)
• 열 (Columns): 객체 (자원)
• 셀: 권한 (read, write, execute 등)

3.2 접근 제어 목록 (ACL: Access Control Lists)

ACL = 접근 제어 행렬을 열 기준으로 저장

Insurance 파일의 ACL:
┌─────────┬──────────┐
│ Alice   │ read     │
│ Bob     │ read     │
│ Charlie │ (none)   │
└─────────┴──────────┘

질문: "누가 Insurance 데이터에 접근할 수 있는가?"

특징:

• 파일 중심적 관점
• 특정 자원의 접근 권한 확인 용이
• 권한 변경 시 해당 자원의 ACL만 수정

3.3 능력 (Capabilities)

Capability = 접근 제어 행렬을 행 기준으로 저장

Alice의 Capability List:
┌───────────┬──────────┐
│ Insurance │ read     │
│ Medical   │ read     │
│ Payroll   │ (none)   │
└───────────┴──────────┘

질문: "Alice가 무엇에 접근할 수 있는가?"

능력의 구현

• 위조 불가능한 토큰 형태
• 중앙 접근 제어기가 검증:
  1. 토큰의 유효성
  2. 토큰의 권한

특징:

• 사용자 중심적 관점
• 권한 위임 용이
• 새 사용자 추가/삭제 쉬움

3.4 UNIX 접근 제어 모델

파일 권한 예시:
-rwxr-xr-- 1 alice staff 1024 Jan 1 12:00 myfile
│││││││││
│││││││└─ others 권한: read
│││││└─── others 권한: 없음
││││└──── group 권한: execute
│││└───── group 권한: read
││└────── owner 권한: execute
│└─────── owner 권한: write
└──────── owner 권한: read

3.5 ACL vs Capabilities 비교

ACL (Access Control Lists)          Capabilities
─────────────────────              ────────────────
파일 → 사용자 연관                   사용자 → 파일 연관
"누가 이 파일에 접근?"               "내가 뭘 할 수 있나?"
권한 변경 쉬움                      권한 위임 쉬움
데이터 중심 보호                    Confused Deputy 문제 방지

ACL의 장점

• 사용자가 자신의 파일 관리
• 데이터 중심적 보호
• 자원별 권한 변경 용이

Capabilities의 장점

• 권한 위임 용이
• Confused Deputy 공격 방지
• 사용자 추가/삭제 쉬움
• "정보 보안의 선(禪)" 구현

💡 학계의 선호: Capabilities는 학계에서 더 선호되며, "Capability Myths Demolished" 논문이 유명합니다.

4. Confused Deputy 문제

4.1 문제 시나리오

자원:
• Compiler (컴파일러)
• BILL 파일 (과금 정보)

권한 행렬:
           Compiler   BILL
Alice         x        -
Compiler     rx       rw

상황:

• Alice가 컴파일러를 디버그 파일명과 함께 실행
• Alice는 BILL 파일에 직접 쓸 권한 없음
• 컴파일러는 BILL 파일에 쓸 권한 있음

4.2 ACL에서의 문제

Alice → Compiler → BILL 파일
      (Deputy)    (무단 접근)

문제점:

• 컴파일러가 Alice를 대신해서 동작 (Deputy)
• 컴파일러가 자신의 권한과 Alice의 권한을 혼동
• Alice가 직접 접근할 수 없는 BILL 파일에 간접적으로 접근

4.3 Confused Deputy 해결

ACL의 한계

• 권한과 사용 목적의 분리가 어려움
• 이런 문제 방지가 더 어려움

Capabilities의 해결책

권한과 목적 간의 연관성 유지:
Alice의 Capability → Compiler → 해당 권한으로만 동작

핵심:

• 권한과 사용 목적 간 연관성 유지 필수
• Capabilities에서는 권한 위임이 명시적
• 더 견고한 Confused Deputy 공격 방어

💡 토론 주제: "Capability 기반 시스템이 Confused Deputy 공격에 더 견고한 이유는 무엇일까요?"

5. 특권 프로그램 (Privileged Programs)

5.1 특권 프로그램의 필요성

패스워드 딜레마

/etc/shadow 파일 권한:
-rw------- 1 root root 1234 Jan 1 12:00 /etc/shadow
           ↑
    root만 읽기/쓰기 가능

문제: 일반 사용자가 어떻게 패스워드를 변경할까?

5.2 2단계 접근법 (Two-Tier Approach)

레벨 1: 운영체제
    ↓ (복잡한 세부 접근 제어는 부담)
레벨 2: 특권 프로그램 (확장 프로그램)
    ↓
세밀한 접근 제어 구현

이유: OS에서 모든 세밀한 접근 제어를 구현하면 과도하게 복잡해짐

5.3 특권 프로그램 유형

1. 데몬 (Daemons)

특징:
• 백그라운드에서 실행되는 프로그램
• root 또는 다른 특권 사용자로 실행 필요

예시: httpd, sshd, mysqld

2. Set-UID 프로그램

특징:
• UNIX 시스템에서 널리 사용
• 특별한 비트로 표시된 프로그램
• 일시적으로 상승된 권한으로 실행

예시: passwd, sudo, ping

5.4 Set-UID 개념

기본 개념

• 목적: 사용자가 프로그램 소유자의 권한으로 실행
• 효과: 일시적으로 상승된 권한 제공

passwd 프로그램 예시

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 41284 Sep 12 2012 /usr/bin/passwd
   ↑
Set-UID 비트 (s)

프로세스의 두 가지 사용자 ID

RUID (Real UID):
• 프로세스의 실제 소유자 식별
• 프로세스를 실행한 사용자

EUID (Effective UID):
• 프로세스의 권한 식별
• 접근 제어는 EUID 기준

일반 프로그램: RUID = EUID
Set-UID 프로그램: RUID ≠ EUID

Set-UID 설정 방법

# 1. 파일 소유자를 root로 변경
$ chown root myprogram

# 2. Set-UID 비트 설정 전
$ ls -l myprogram
-rwxr-xr-x 1 root root 1234 Jan 1 12:00 myprogram

# 3. Set-UID 비트 설정 후
$ chmod u+s myprogram
$ ls -l myprogram
-rwsr-xr-x 1 root root 1234 Jan 1 12:00 myprogram

동작 원리

Set-UID 프로그램 = 일반 프로그램 + Set-UID 비트
                  (단일 비트 표시)

5.5 Set-UID 프로그램 공격

공격 가능성

가정: 사용자는 코딩된 내용만 실행
현실: 개발자의 코딩 결함 존재

Superman 공격 예시:
1. 북쪽으로 날아가서 왼쪽으로 회전 (정상 경로)
2. 북쪽으로 날아가서 서쪽으로 회전 (악용 경로)

공격 표면

Set-UID 프로그램의 공격 벡터:
┌─────────────────┐
│   User Inputs   │ ← 명시적 입력
├─────────────────┤
│   Environment   │ ← 환경 변수
│   Variables     │
├─────────────────┤
│  Implicit       │ ← 암시적 입력
│   Inputs        │
└─────────────────┘

사용자 입력을 통한 공격

1. 명시적 입력 공격

• Buffer Overflow (Chapter 4에서 상세 설명)
  - 버퍼 오버플로우로 악성 코드 실행

• Format String Vulnerability (Chapter 6에서 상세 설명)
  - 사용자 입력을 포맷 스트링으로 사용하여 프로그램 동작 변경

2. CHSH 공격 사례

CHSH (Change Shell) 프로그램:
• 기본 셸 프로그램 변경 기능
• 셸 정보는 /etc/passwd에 저장

취약점:
• 사용자 입력 검증 실패
• 공격자가 새로운 root 계정 생성 가능

💡 추가 정보: Set-UID 프로그램은 강력한 보안 기능이지만, 잘못 구현되면 시스템 전체를 위험에 빠뜨릴 수 있습니다. 따라서 입력 검증, 환경 변수 처리, 권한 최소화 등 다양한 보안 고려사항이 필요합니다.

6. 다층 접근 제어 구현

6.1 하드웨어 레벨 접근 제어

x86 CPU 실행 권한

x86 권한 링:
Ring 0 (커널)     ← 최고 권한
Ring 1 (사용 안함)
Ring 2 (사용 안함)  
Ring 3 (사용자)   ← 최저 권한

특권 명령어:

• 하드웨어 구성 변경
• 메모리 보호 비활성화/활성화
• 새 페이지 테이블 로드
• Ring 0에서만 실행 가능

Supervisor 페이지:

• Ring 0~Ring 2만 접근 가능
• 사용자 프로세스 접근 차단

페이징 시스템

페이지 테이블 엔트리 플래그:
┌─────┬─────┬─────┬─────┐
│  P  │ R/W │ XD  │ ... │
└─────┴─────┴─────┴─────┘
  │     │     │
  │     │     └─ Execute Disable
  │     └─ Read/Write
  └─ Present

P bit: 페이지 접근 가능 여부
R/W bit: 페이지 수정 가능 여부  
XD bit: 코드 실행 가능 여부

기능:

• 물리 메모리 위에 가상 메모리 생성
• 페이지별 접근 제어 적용

6.2 OS 커널 레벨 접근 제어

메모리 접근 제어

커널 vs 사용자 분리

커널 (Ring 0):
• 자신을 Supervisor 페이지로 매핑
• 사용자 프로세스로부터 보호
• 특권 명령어 실행 가능

사용자 (Ring 3):
• 특권 명령어 실행 불가
• 커널 영역 접근 불가

프로세스별 주소 공간 분리

Process A     Process B     Process C
┌─────────┐   ┌─────────┐   ┌─────────┐
│ Virtual │   │ Virtual │   │ Virtual │
│ Memory  │   │ Memory  │   │ Memory  │
│ Space   │   │ Space   │   │ Space   │
└─────────┘   └─────────┘   └─────────┘
     ↓             ↓             ↓
┌─────────────────────────────────────┐
│        Physical Memory             │
└─────────────────────────────────────┘

효과:

• 각 프로세스의 개별 주소 공간
• 프로세스 간 임의적 메모리 접근 차단

파일 시스템 접근 제어

파일/디렉토리별 ACL 유지:
사용자 요청 → 시스템 콜 → 커널 권한 확인 → 접근 허용/거부

관련 시스템 콜:
fopen(), fprintf() → 내부적으로 커널에 권한 요청

6.3 애플리케이션 레벨 접근 제어

애플리케이션별 접근 제어

애플리케이션 개발자가 정의해야 할 사항:
1. 무엇을 보호해야 하는가?
2. 누가 접근할 수 있어야 하는가?
3. 어떤 조건에서 접근이 불법인가?
4. 어떤 접근 제어 방식을 적용할 것인가?
5. 접근 제어 방식에 허점은 없는가?

애플리케이션별 접근 제어 방식

각 애플리케이션의 요구사항에 따라 고유한 접근 제어 방식 설계 필요

💡 추가 정보: 현대의 클라우드 환경에서는 제로 트러스트(Zero Trust) 아키텍처가 주목받고 있으며, 이는 모든 접근을 검증하는 다층 보안 접근법입니다.

예상 시험문제

1. Bell-LaPadula 모델 분석

문제: Bell-LaPadula 모델의 "No Read Up, No Write Down" 원칙을 설명하고, 다음 시나리오가 BLP 원칙을 위반하는지 판단하시오.

• 시나리오: Secret(L=3) 등급의 사용자가 Confidential(L=2) 문서를 읽고, Top Secret(L=4) 보고서에 내용을 작성

모범답안:

BLP 원칙:

1. No Read Up: L(O) ≤ L(S), 자신보다 높은 등급 읽기 금지
2. No Write Down: L(S) ≤ L(O), 자신보다 낮은 등급 쓰기 금지

시나리오 분석:

• 읽기: Secret 사용자(3)가 Confidential 문서(2) 읽기
  • L(O)=2 ≤ L(S)=3 → 허용 (Read Down)
• 쓰기: Secret 사용자(3)가 Top Secret 보고서(4)에 쓰기
  • L(S)=3 ≤ L(O)=4 → 허용 (Write Up)

결론: 두 동작 모두 BLP 원칙을 준수합니다.

BLP 원칙의 의의: 정보가 높은 등급에서 낮은 등급으로 흘러나가는 것을 방지하여 기밀성 보장

2. ACL vs Capabilities 비교 분석

문제: Confused Deputy 문제를 예시로 들어 ACL과 Capabilities의 차이점을 설명하고, 왜 Capabilities가 이 문제에 더 견고한지 서술하시오.

모범답안:

Confused Deputy 시나리오:

권한 행렬:        Compiler   BILL
Alice               x         -
Compiler           rx        rw

ACL에서의 문제:

1. Alice가 컴파일러를 호출 (자신의 권한으로)
2. 컴파일러가 자신의 권한으로 BILL 파일에 접근
3. Alice가 의도하지 않게 BILL 파일 조작 가능
4. 문제점: 권한과 사용 목적의 분리 어려움

Capabilities에서의 해결:

1. Alice가 컴파일러에게 자신의 capability 전달
2. 컴파일러는 Alice가 제공한 권한으로만 동작
3. BILL 파일에 대한 capability가 없으면 접근 불가
4. 해결책: 권한과 목적의 명시적 연관성 유지

결론: Capabilities는 권한 위임이 명시적이므로 Confused Deputy 문제를 구조적으로 방지

3. Set-UID 프로그램의 보안 위험

문제: Set-UID 프로그램의 동작 원리를 RUID/EUID 개념으로 설명하고, 주요 공격 벡터 3가지와 각각의 대응 방안을 제시하시오.

모범답안:

Set-UID 동작 원리:

일반 프로그램:     RUID = EUID = 실행 사용자 ID
Set-UID 프로그램:  RUID = 실행 사용자 ID
                  EUID = 프로그램 소유자 ID

접근 제어 기준: EUID 사용

주요 공격 벡터와 대응 방안:

1. Buffer Overflow

   • 공격: 입력 버퍼 오버플로우로 악성 코드 실행
   • 대응: 입력 길이 검증, 스택 보호 기법 사용

2. Format String Attack

   • 공격: 사용자 입력을 포맷 스트링으로 사용하여 메모리 조작
   • 대응: 정적 포맷 스트링 사용, 사용자 입력 검증

3. Environment Variable Manipulation

   • 공격: PATH, LD_LIBRARY_PATH 등 환경 변수 조작
   • 대응: 환경 변수 초기화, 절대 경로 사용

추가 보안 원칙:

• 최소 권한 원칙 적용
• 가능한 빨리 권한 포기
• 입력 검증 및 출력 인코딩

4. 다층 접근 제어 아키텍처

문제: 하드웨어부터 애플리케이션까지의 다층 접근 제어 구조를 설명하고, 각 층의 역할과 보안 메커니즘을 서술하시오.

모범답안:

다층 접근 제어 구조:

┌─────────────────────────────┐
│   Application Level         │ ← 애플리케이션별 맞춤 정책
├─────────────────────────────┤
│   OS Kernel Level          │ ← 파일/메모리 접근 제어
├─────────────────────────────┤
│   Hardware Level           │ ← CPU 권한 링, 페이징
└─────────────────────────────┘

각 층의 역할:

1. 하드웨어 레벨:

   • CPU 권한 링: Ring 0(커널) vs Ring 3(사용자)
   • 특권 명령어: 하드웨어 구성 변경 권한 제어
   • 페이징 시스템: 메모리 페이지별 R/W/X 권한
   • Supervisor 페이지: 커널 메모리 보호

2. OS 커널 레벨:

   • 메모리 보호: 프로세스별 가상 주소 공간 분리
   • 파일 시스템: 파일/디렉토리별 ACL 관리
   • 시스템 콜: 모든 자원 접근의 중재점
   • 프로세스 격리: 프로세스 간 무단 접근 방지

3. 애플리케이션 레벨:

   • 도메인별 정책: 각 애플리케이션의 고유 요구사항 반영
   • 사용자 인터페이스: 최종 사용자 접근 제어
   • 비즈니스 로직: 업무 규칙에 따른 접근 제어
   • 데이터 분류: 민감도에 따른 데이터 보호

상호 작용: 각 층이 서로 보완하여 완전한 보안 제공

5. 접근 제어 정책 선택 기준

문제: DAC, MAC, RBAC 중에서 다음 시나리오에 가장 적합한 정책을 선택하고 그 이유를 설명하시오.

• 시나리오 1: 개인 클라우드 저장소 서비스
• 시나리오 2: 군사 기밀 문서 관리 시스템
• 시나리오 3: 대기업 ERP 시스템

모범답안:

시나리오 1: 개인 클라우드 저장소 → DAC

• 이유:
  • 사용자가 자신의 파일을 자유롭게 관리
  • 유연한 공유 기능 필요
  • 중앙 집중식 제어 불필요
• 장점: 사용 편의성, 구현 단순성
• 고려사항: 사용자 교육을 통한 보안 인식 향상

시나리오 2: 군사 기밀 문서 → MAC

• 이유:
  • 엄격한 보안 등급 체계 필요
  • 정보 유출 방지가 최우선
  • 중앙 집중식 정책 강제 적용
• 장점: 강력한 보안, 일관된 정책
• 구현: Bell-LaPadula 모델 적용

시나리오 3: 대기업 ERP → RBAC

• 이유:
  • 조직 구조와 업무 프로세스 반영
  • 효율적인 권한 관리 필요
  • 직무 분리 원칙 적용
• 장점: 관리 효율성, 확장성
• 구현: 부서별/직급별 역할 정의

6. 접근 제어 매트릭스 구현 방식

문제: 접근 제어 매트릭스를 ACL과 Capabilities로 구현할 때의 장단점을 비교하고, 각각이 적합한 사용 사례를 제시하시오.

모범답안:

접근 제어 매트릭스:

        File1   File2   File3
Alice    rw      r       -
Bob      r       rw      r
Charlie  -       r       rw

ACL 구현 (열 기준):

File1 ACL: [Alice:rw, Bob:r]
File2 ACL: [Alice:r, Bob:rw, Charlie:r]
File3 ACL: [Bob:r, Charlie:rw]

Capabilities 구현 (행 기준):

Alice: [File1:rw, File2:r]
Bob: [File1:r, File2:rw, File3:r]
Charlie: [File2:r, File3:rw]

ACL의 장단점:

• 장점:
  • 자원별 권한 관리 용이
  • 특정 파일의 접근자 확인 쉬움
  • 권한 변경 시 해당 ACL만 수정
• 단점:
  • 사용자별 권한 현황 파악 어려움
  • Confused Deputy 문제 취약
  • 권한 위임 복잡

Capabilities의 장단점:

• 장점:
  • 사용자별 권한 현황 명확
  • 권한 위임 간단
  • Confused Deputy 방지
  • 분산 시스템에 적합
• 단점:
  • 자원별 접근자 확인 어려움
  • 토큰 관리 복잡
  • 취소(revocation) 어려움

적합한 사용 사례:

• ACL: 파일 시스템, 데이터베이스, 전통적 OS
• Capabilities: 분산 시스템, 마이크로서비스, 모바일 앱

핵심 요약

• 접근 제어는 인증 후 단계로, 완전한 중재 원칙에 따라 모든 접근을 제어
• Bell-LaPadula 모델은 기밀성 중심의 다단계 보안 모델의 기초
• DAC, MAC, RBAC는 각각 다른 보안 요구사항에 적합한 정책 모델
• ACL과 Capabilities는 접근 제어 매트릭스의 두 가지 구현 방식
• Confused Deputy 문제는 권한 위임 시 발생하는 보안 취약점
• Set-UID 프로그램은 강력하지만 다양한 공격 벡터 존재
• 다층 접근 제어는 하드웨어부터 애플리케이션까지의 종합 보안 구조

💡 중요: 접근 제어는 단일 메커니즘이 아닌 다층 방어 전략으로 구현해야 하며, 각 층의 보안 메커니즘이 상호 보완하여 전체적인 보안을 달성합니다. 특히 권한 상승 프로그램의 보안은 시스템 전체 보안에 직결되므로 신중한 설계와 구현이 필요합니다.