정보보안 개론 정리 — Day 3 ~ Day 5

---

Day 3 — 정보보안의 탄생과 기본 개념

1. 정보보안의 시작

정보보안의 문제는 Computer나 Hacker가 등장하기 이전부터 존재했다.

보안의 근본적인 질문은 다음과 같다.

누가 정보를 볼 수 있는가?
정보가 바뀌지 않았는가?
필요할 때 사용할 수 있는가?

암호는 오래전부터 군사, 외교와 상거래에서 중요한 정보를 보호하기 위해 사용되었다.

현대 정보보안은 Computer, Network, Web과 Data가 등장하면서 보호해야 할 대상이 계속 확대된 결과라고 볼 수 있다.

2. Enigma와 정보전

제2차 세계대전 당시 독일군은 Enigma라는 기계식 암호장비를 사용했다.

Enigma를 분석하는 과정에서는 단순한 암호 기술만 사용된 것이 아니다.

수학
+
암호 분석
+
기계
+
협업
+
정보 판단

Alan Turing과 Bletchley Park의 사례를 통해 보안 문제를 해결하기 위해서는 기술뿐만 아니라 여러 사람의 협업과 정보 분석이 필요하다는 점을 확인할 수 있다.

3. Midway와 정보 분석

미드웨이 해전에서는 암호통신에서 등장한 AF가 어느 지역을 의미하는지를 추론하고 검증하는 과정이 중요했다.

암호 통신 분석
    ↓
AF의 의미 추정
    ↓
가설 수립
    ↓
정보를 이용한 검증
    ↓
판단
    ↓
행동

즉 정보를 많이 가지고 있는 것만큼 수집한 정보를 어떻게 분석하고 판단하는가도 중요하다.

4. Diffie-Hellman과 RSA

인터넷에서는 서로 직접 만나지 않은 사람끼리 안전하게 통신해야 한다.

이 과정에서 중요한 문제가 Key를 어떻게 안전하게 공유할 것인가이다.

Diffie-Hellman은 공개된 값을 주고받으면서도 양측이 동일한 비밀값을 만들어낼 수 있도록 하는 Key Exchange 방식이다.

RSA는 Public Key와 Private Key를 사용하는 대표적인 비대칭키 암호 방식이다.

기밀성을 위한 기본적인 관계는 다음과 같이 볼 수 있다.

Public Key로 암호화
        ↓
Private Key로 복호화

전자서명에서는 Private Key를 이용해 Signature를 만들고 Public Key로 이를 검증할 수 있다.

Rabin과 같은 암호체계도 존재하며 실제 환경에서는 보안성뿐만 아니라 성능과 운영 편의성을 함께 고려해야 한다.

5. 접근 통제

여러 사용자가 하나의 System을 사용하게 되면서 누가 어떤 Resource에 접근할 수 있는가를 관리하는 문제가 중요해졌다.

대표적인 접근통제 방식은 다음과 같다.

방식	의미
DAC	임의적 접근통제
MAC	강제적 접근통제
RBAC	역할 기반 접근통제

DAC에서는 Resource Owner가 다른 사용자에게 접근 권한을 부여한다.

MAC에서는 사용자가 임의로 권한을 변경하기보다 정해진 보안 정책에 따라 접근을 통제한다.

RBAC은 사용자가 수행하는 Role을 기준으로 권한을 부여한다.

6. DevSecOps

DevSecOps는 Development, Security, Operations를 결합한 개념이다.

개발 이후에만 보안을 검사하는 것이 아니라 개발 과정에서부터 다음을 고민한다.

어느 부분에서 보안 문제가 발생할 수 있는가?
어떻게 보안성을 확보할 수 있는가?
개발 과정에서 어떻게 보안을 적용할 수 있는가?

즉 보안을 개발과 운영의 별도 과정이 아니라 전체 Lifecycle에 포함시키는 관점이다.

7. 조직적 보안 통제

기술적인 보안 통제뿐만 아니라 조직의 업무 방식도 중요하다.

• 직무 분리: 중요한 업무 권한이 한 사람에게 집중되지 않도록 한다.
• 직무 순환: 여러 사람이 다양한 업무를 경험하도록 업무를 변경한다.
• 책임추적성: 누가 언제 어떤 행동을 했는지 기록하고 식별할 수 있어야 한다.
• 강제휴가: 특정 업무 담당자를 일정 기간 업무에서 분리해 내부 이상행위를 발견할 수 있도록 한다.

책임추적성을 위해서는 System Log와 사용자의 행동 기록이 중요하다.

8. 정보보안에서 무엇을 공부해야 하는가

정보보안을 공부할 때 중요한 질문은 다음과 같다.

무엇을 보호할 것인가?
누가 접근하는가?
무슨 일이 발생했는가?
사고가 발생하면 어떻게 대응할 것인가?

단순히 특정 기술을 사용해본 경험보다 해당 기술을 실제 환경에 어떻게 적용할 것인지 생각하는 능력이 중요하다.

Day 3 한 줄 정리

정보보안은 정보를 숨기는 암호에서 시작해 사용자와 시스템의 접근을 통제하고, 발생한 행위를 추적하고 대응하는 영역으로 확장되어 왔다.

---

Day 4 — 암호화와 Digital Trust

1. 대칭키 암호화

대칭키 암호는 Sender와 Receiver가 동일한 Secret Key를 사용하는 암호화 방식이다.

대표적인 알고리즘은 다음과 같다.

• DES
• Triple DES
• AES

장점:

• 연산 속도가 빠름
• 대용량 Data 암호화에 적합
• 구현이 비교적 단순

단점:

• Key를 먼저 안전하게 공유해야 함
• 사용자가 많아지면 Key 관리가 복잡해짐
• Key가 유출되면 암호화된 Data가 위험해짐

2. Key Distribution 문제

대칭키 암호에서는 양쪽 사용자가 동일한 Key를 가져야 한다.

하지만 암호화되지 않은 Network를 통해 Key 자체를 전달하면 공격자가 Key를 탈취할 수 있다.

이를 해결하기 위한 방법에는 다음과 같은 방식이 있다.

• Key 사전 공유
• Key Distribution Center
• Diffie-Hellman Key Exchange
• 비대칭키 암호

3. 비대칭키와 Hybrid Encryption

비대칭키 암호는 Public Key와 Private Key라는 서로 다른 두 Key를 사용한다.

이를 통해 Key Exchange, Digital Signature와 Certificate 등의 기술을 구현할 수 있다.

다만 비대칭키 암호는 대칭키보다 연산량이 크기 때문에 실제 통신에서는 두 방식을 함께 사용한다.

비대칭키 기반 인증·Key Exchange
          ↓
Session Key 생성
          ↓
대칭키로 실제 Data 암호화

이와 같이 두 암호 방식을 함께 사용하는 것을 Hybrid Encryption이라고 한다.

4. 국내 대칭키 알고리즘

SEED

국내에서 개발된 대칭키 Block Cipher이다.

• 128-bit Block 사용
• 국내 인터넷, 전자상거래 등의 정보 보호 목적으로 개발
• Feistel 구조 기반

ARIA

국가보안기술연구소를 중심으로 개발된 국내 Block Cipher이다.

지원하는 Key Size는 다음과 같다.

• 128 bit
• 192 bit
• 256 bit

Block Size는 128 bit이다.

5. Digital Signature

전자서명은 다음을 확인하기 위해 사용한다.

• 누가 보낸 Data인가?
• Data가 중간에 변경되지 않았는가?
• 서명자가 해당 행위를 부인할 수 있는가?

일반적인 흐름은 다음과 같다.

Message
   ↓
Hash
   ↓
Private Key를 이용한 Signature
   ↓
Digital Signature

수신자는 Public Key를 이용해 Signature를 검증한다.

6. Certificate와 PKI

Public Key 자체만 가지고는 해당 Key가 실제로 누구의 것인지 판단하기 어렵다.

Certificate는 Identity와 Public Key를 연결하는 역할을 한다.

PKI(Public Key Infrastructure)는 Certificate를 발급하고 검증하며 상태를 관리하는 전체 구조이다.

구성 요소	역할
신청자	Certificate 신청 및 사용
RA	신원, Domain, 조직 확인
CA	Certificate 발급 및 서명
Repository	Certificate와 상태 정보 제공
Relying Party	Certificate를 검증하고 사용

7. CRL과 OCSP

Certificate가 발급된 이후 Private Key 유출 등의 문제가 발생하면 더 이상 해당 Certificate를 신뢰해서는 안 된다.

CRL(Certificate Revocation List)은 폐기된 Certificate 목록을 제공한다.

OCSP(Online Certificate Status Protocol)는 Certificate의 현재 상태를 Online으로 확인한다.

Client
  ↓
Certificate 상태 질의
  ↓
OCSP Responder
  ↓
Good / Revoked / Unknown

8. 인증 시스템의 오류

인증 시스템에서는 정상 사용자와 비정상 사용자를 잘못 판단하는 오류가 발생할 수 있다.

• Type 1 Error: 정상 사용자를 잘못된 사용자로 판단하여 거부
• Type 2 Error: 잘못된 사용자를 정상 사용자로 판단하여 허용

특히 잘못된 사용자를 허용하는 오류가 증가하면 인증 수단으로 사용하기 어렵다.

9. PGP와 SET

PGP(Pretty Good Privacy)는 메시지를 암호화하여 수신자만 읽을 수 있도록 하고 Digital Signature를 이용해 송신자를 확인할 수 있도록 한다.

SET(Secure Electronic Transaction)은 PKI 기반의 신용카드 결제용 보안 Protocol이다.

SET의 Dual Signature는 주문 정보와 결제 정보를 분리한다.

Order Information   → Merchant
Payment Information → Bank

각 주체가 필요한 정보만 확인하도록 구성한다.

10. 7.7 DDoS와 Ransomware

2009년 7월 7일부터 국내·외 주요 Website를 대상으로 대규모 DDoS 공격이 발생했다.

해당 공격에서는 C&C Server에서 매 순간 명령을 받는 구조뿐만 아니라 미리 설정된 시간에 공격을 수행하도록 Scheduling된 Malware도 사용되었다.

Ransomware는 사용자의 Data를 사용할 수 없도록 만든 뒤 금전을 요구하는 형태의 Malware이다.

악성코드와 Bot 등의 기술이 결합되면서 공격 방법도 발전해왔다.

11. HSTS

HSTS(HTTP Strict Transport Security)는 Website가 Browser에게 HTTPS 연결만 사용하도록 요구하는 보안 정책이다.

주요 목적은 다음과 같다.

• HTTPS 사용 강제
• 중간자 공격 위험 감소
• HTTP로의 연결 전환 방지

12. BCP, DRP와 RTO·RPO

BCP(Business Continuity Plan)는 장애 상황에서도 업무를 어떻게 지속할 것인지 다룬다.

• 사람
• 절차
• 대체 업무
• 고객 안내
• 대체 센터

DRP(Disaster Recovery Plan)는 IT Infrastructure를 어떻게 복구할 것인지 다룬다.

• Server
• DB
• Network
• Backup
• DR Center

복구 목표는 RTO와 RPO로 표현할 수 있다.

• RTO: Service 복구까지 허용되는 시간
• RPO: 장애 발생 시 허용할 수 있는 Data Loss 범위

Day 4 한 줄 정리

대칭키와 비대칭키를 결합해 데이터를 안전하게 전달하고, Digital Signature와 PKI를 이용해 통신 상대와 Public Key에 대한 신뢰를 구성할 수 있다.

---

Day 5 — Digital Identity와 접근 통제

1. 식별, 인증, 인가와 책임추적

Access Control 과정에서는 다음 개념을 구분해야 한다.

단계	질문	예시
식별	나는 누구인가?	ID, Email, 사번
인증	실제 그 사람이 맞는가?	Password, OTP
인가	무엇을 할 수 있는가?	Read, Write, Admin
책임추적	무엇을 했는가?	Log, Audit

전체 흐름은 다음과 같다.

Identification
      ↓
Authentication
      ↓
Authorization
      ↓
Resource Access
      ↓
Logging / Accountability

2. MFA

MFA(Multi Factor Authentication)는 단순히 인증 방법을 두 개 사용하는 것이 아니라 서로 다른 종류의 인증 요소를 결합해야 한다.

대표적인 인증 요소는 다음과 같다.

• Knowledge: Password, PIN 등 사용자가 알고 있는 것
• Possession: OTP Device, Smartphone 등 사용자가 가지고 있는 것
• Inherence: Fingerprint 등 사용자의 신체적 특징

따라서:

Password + PIN
= Knowledge + Knowledge
→ MFA가 아님

반면:

Password + OTP
= Knowledge + Possession
→ MFA

또는:

Employee Card + Fingerprint
= Possession + Inherence
→ MFA

가 된다.

3. Asset Identification

보안 담당자가 가장 먼저 해야 하는 일 중 하나는 보호해야 할 Asset을 파악하는 것이다.

다음 질문에 답할 수 있어야 한다.

회사에는 어떤 자산이 있는가?
어떤 자산이 중요한가?
자산들은 어떻게 연결되어 있는가?
어떤 Data를 가지고 있는가?
누가 접근할 수 있는가?

보안 기술을 적용하기 전에 먼저 보호할 대상을 명확하게 이해해야 한다.

4. 접근 경로와 Network Flow

중요한 Asset까지 어떤 경로로 접근할 수 있는지도 파악해야 한다.

Internet
   ↓
Network
   ↓
Server
   ↓
Application
   ↓
Important Data

이 과정에서 Inbound와 Outbound Traffic, 중요 정보가 이동하는 경로와 접근통제 정책을 함께 확인해야 한다.

5. 기존 보안과 새로운 Infrastructure

Container, Cloud와 Kubernetes 같은 새로운 기술이 등장해도 기존 보안 원칙이 사라지는 것은 아니다.

기존의 Server와 Network Security 위에 새로운 보안 영역이 추가된다.

기존 Security
      +
Container Security
      +
Cloud Security
      +
Kubernetes Security

즉 기존 보안 기준이 소멸하는 것이 아니라 확장된다고 볼 수 있다.

6. Scale Up과 Scale Out

Infrastructure에서는 Service 사용량에 따라 Resource를 확장하거나 줄일 수 있다.

방식	의미
Scale Up	한 Server의 Resource 증가
Scale Down	한 Server의 Resource 감소
Scale Out	Server Instance 수 증가
Scale In	Server Instance 수 감소

Kubernetes와 Cloud 환경에서는 이러한 Scaling을 자동으로 수행하는 구조를 사용할 수 있다.

7. SBOM

SBOM(Software Bill of Materials)은 Software를 구성하는 Component 목록이다.

Application
├── Framework
├── Library A
├── Library B
└── OpenSSL

특정 Library에 Vulnerability가 발생했을 때 SBOM을 통해 다음을 파악할 수 있다.

우리 Service가 해당 Library를 사용하는가?
어떤 Version인가?
어느 System에서 사용되는가?

Software Supply Chain을 관리하는 데 중요한 정보가 된다.

8. Log와 Runtime Security

전통적으로 System에 문제가 발생했는지를 확인하는 대표적인 방법은 Log Analysis이다.

Infrastructure가 Container 기반으로 변화하면서 Application Log뿐만 아니라 Process의 Runtime Event도 중요해졌다.

예를 들어 정상적인 Web Application에서 Child Process로 Shell이 실행된다면 이상행위로 탐지할 수 있다.

Web Application
      ↓
Child Process
      ↓
Shell 실행

Runtime 환경에서는 다음과 같은 Event를 관찰할 수 있다.

• Process 실행
• Child Process 생성
• File 접근
• Network 통신
• System Event

9. Log Data의 가공

모든 Event를 무조건 기록하면 매우 많은 양의 Log가 발생할 수 있다.

따라서 필요한 Event를 선별하여 분석 가능한 Data로 가공해야 한다.

Raw Log
   ↓
Filtering
   ↓
Parsing
   ↓
필요한 Event 추출
   ↓
Detection

보안에서는 단순히 Data를 많이 수집하는 것보다 필요한 Data를 잘 가공하는 능력이 중요하다.

10. Automation

보안 업무에서는 반복적인 작업을 자동화하는 능력이 중요하다.

예를 들어 다음과 같은 흐름을 생각할 수 있다.

Security Event 발생
        ↓
Log 분석
        ↓
필요한 정보 추출
        ↓
협업 Tool 전달
        ↓
담당자 대응

Ansible 등의 Tool을 이용해 System 설정을 자동화하거나 여러 협업 Tool과 API를 연결해 반복적인 보안 업무를 자동화할 수 있다.

AI 역시 단순히 사용하는 것보다 보안 업무의 어느 부분을 자동화할 수 있는가를 고민하는 것이 중요하다.

11. 보안 분석과 개발 단계의 Tool

Windows 환경에서는 Sysmon 등을 이용해 System Event를 기록할 수 있다.

Source Code 단계에서는 다음과 같은 Tool을 사용할 수 있다.

• Semgrep
• CodeQL

이를 통해 Software가 운영 환경에 배포되기 전부터 보안 문제를 찾아볼 수 있다.

12. 앞으로의 학습 관점

운영체제를 학습할 때는 Linux 자체뿐만 아니라 다음 기술과 연결해서 볼 필요가 있다.

• Container
• IaC
• Kubernetes

Cloud에서는 실제 Infrastructure를 구성하는 실습이 중요하다.

Hacking을 공부할 때도 단순히 공격에 성공하는 것으로 끝내지 않고 다음을 함께 생각해야 한다.

공격이 발생하면 어떤 Log가 남을까?
어떤 Event를 이용해 탐지할 수 있을까?
탐지와 대응을 어떻게 자동화할 수 있을까?

Day 5 한 줄 정리

보안은 Asset을 식별하고 적절한 접근 권한을 부여하는 것에서 시작하며, 현대 환경에서는 Runtime Log와 Data 분석, Automation까지 함께 고려해야 한다.

---

전체 흐름 정리

Day 3부터 Day 5까지 학습한 정보보안 개론의 흐름을 연결하면 다음과 같다.

1. 중요한 정보를 보호하기 위한 필요에서 암호와 정보보안이 발전했다.
2. Network와 Multi-user System이 등장하면서 Identity와 Access Control이 중요해졌다.
3. 대칭키와 비대칭키를 이용해 Data의 기밀성을 보호할 수 있다.
4. Digital Signature와 PKI를 이용해 통신 상대와 Public Key를 신뢰할 수 있는 구조를 만든다.
5. System에서는 식별 → 인증 → 인가 과정을 통해 Resource 접근을 통제한다.
6. 보안을 적용하려면 먼저 조직에서 보호해야 할 Asset과 Data Flow를 파악해야 한다.
7. System과 Application에서 발생하는 Log와 Runtime Event를 분석해 이상행위를 탐지한다.
8. 반복적인 분석과 대응 과정은 Automation을 통해 효율화할 수 있다.

정보보안을 전체적으로 보면 다음과 같은 흐름으로 연결할 수 있다.

Asset 식별
   ↓
Identity 확인
   ↓
Authentication
   ↓
Authorization
   ↓
Data 보호
   ↓
Logging
   ↓
Detection
   ↓
Incident Response
   ↓
Recovery

정보보안에서 중요한 것은 개별 기술을 외우는 것뿐만 아니라 각 기술이 어떤 문제를 해결하고 실제 환경의 어느 부분에 적용되는지 연결해서 이해하는 것이다.