[1] 배경 및 초기 문제 상황

Astro CLI(

astro dev start

)를 통해 로컬 Airflow 환경을 띄우고, 외부 Docker Container로 Spark를 실행하여 연동하려는 시도를 했음. 그러나 다음과 같은 두 가지 치명적인 네트워크/환경 문제에 봉착함.

1. Docker Image Pull 실패:  등의 외부 이미지를 받아오려 했으나,  에러가 발생하며 이미지를 찾지 못함.

    bitnami/spark:latest

    manifest unknown

2. SSL Handshake 및 Proxy 에러: 사내망의 SSL Inspection(패킷 감청) 장비 또는 Proxy로 인해  등 외부 레지스트리 접속 시  네트워크 에러 발생함.

    quay.io

    connectex

결정 사항: 외부에서 별도의 Spark 클러스터 이미지를 가져오는 것은 네트워크 제약상 유지보수가 어렵다고 판단함. 따라서 Airflow 컨테이너 내부(Local)에 Spark 엔진을 내장(Embedded)시켜 네트워크 의존성을 제거하고 구성을 단순화하기로 결정함.

[2] Dockerfile: Airflow 컨테이너에 Java와 Spark 내재화

Spark는 JVM 기반으로 동작하므로 Java 런타임이 필수적임. 또한 Airflow에서 별도의 설정을 최소화하기 위해

pip을 통해 pyspark 라이브러리를 설치하면 Spark 바이너리까지 함께 포함되어 설치된다는 점을 이용함.

아래는 수정한 Dockerfile의 내용임.

dockerfile

FROM quay.io/astronomer/astro-runtime:12.6.0

USER root

# 1. Java 17(JDK) 및 필수 유틸리티 설치
# Spark 구동을 위해 OpenJDK 17을 설치하고 불필요한 캐시는 제거함
RUN apt-get update && \
    apt-get install -y --no-install-recommends openjdk-17-jdk wget && \
    rm -rf /var/lib/apt/lists/*

# 2. PySpark 설치 (Airflow 환경 내 Spark 엔진 포함)
# pip로 설치 시 Spark 엔진이 내장되므로 별도로 Spark 바이너리를 다운받을 필요가 없음
RUN pip install --no-cache-dir pyspark

# 3. 환경 변수 설정
# 시스템이 Java와 Spark의 위치를 인지할 수 있도록 경로를 지정함
ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
ENV PATH=$PATH:$JAVA_HOME/bin

# 보안상 다시 airflow 유저로 권한을 돌려줌
USER airflow

핵심 포인트: 외부 Spark 클러스터와 통신하는 복잡한 설정(Hadoop XML 등)을 제거하고, Docker 이미지 하나에 실행 환경을 모두 패키징하여 이식성을 높였음.

[3] docker-compose.override.yml: 환경 변수 전파 문제 해결

Dockerfile에서

JAVA_HOME

을 선언했지만, Astro CLI가 컨테이너를 실행할 때

scheduler

,

webserver

,

triggerer

등 각 서비스 컨테이너에 환경 변수가 제대로 전파되지 않는 문제가 발생함. 이로 인해

Java not found

에러가 발생할 수 있음.

이를 해결하기 위해

docker-compose.override.yml에서 각 서비스에 명시적으로 환경 변수를 주입함.

yaml

# version: "3.1"  <-- 경고 메시지를 유발하는 구식 속성이므로 제거함

services:
scheduler:
environment:
      -JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
webserver:
environment:
      -JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
triggerer:
environment:
      -JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64

해결 원리: Docker Compose 오버라이드 기능을 통해 Airflow의 모든 구성 요소가 동일한 Java 런타임 경로를 바라보도록 강제하여 실행 환경의 일관성을 확보함.

[4] 의존성 관리: Provider 설치 및 DAG Import Error 해결

환경 구축 후 DAG를 실행하려 하자 다음과 같은 에러가 발생함.

ModuleNotFoundError: No module named 'airflow.providers.apache'

원인은 Airflow 기본 이미지에 Spark 연동을 위한 Provider 패키지가 포함되어 있지 않기 때문임.

requirements.txt에 해당 패키지를 명시해야 함.

text

# requirements.txt

# DB 연결을 위한 Provider
apache-airflow-providers-microsoft-mssql

# Spark Core 엔진
pyspark

# Airflow와 Spark를 연결해주는 핵심 Provider (SparkSubmitOperator 포함)
apache-airflow-providers-apache-spark

주의 사항: 사내망 환경에서는

pyspark와 같은 대용량 패키지(약 300MB 이상)를 다운로드할 때 Proxy나 네트워크 속도 문제로 빌드 시간이 10분 이상 소요될 수 있음. 타임아웃이 발생하지 않도록 인내심을 갖고

astro dev restart

를 수행해야 함.

[5] DAG 코드 무결성 검증 및 경로 수정

환경 설정이 끝난 후 코드 레벨에서

SparkSubmitOperator

를 찾을 수 없다는(

NameError

) 에러가 발생함. 디버깅 결과 Import 구문이 누락되었고, 실행하려는 Python 파일의 경로가 실제와 다른 것을 확인함.

수정 전 (에러 발생 코드):

python

# Import 누락됨
# 파일명 불일치: ncst_to_mssql.py (실제 파일은 ncst_json_to_mssql.py)
spark_to_mssql = SparkSubmitOperator(
    application="/usr/local/airflow/include/spark_jobs/ncst_to_mssql.py",
    ...
)

수정 후 (정상 코드):

python

import pendulum
# [중요] Operator를 사용하기 위해 반드시 Import 해야 함
from airflow.providers.apache.spark.operators.spark_submitimport SparkSubmitOperator

...

spark_to_mssql = SparkSubmitOperator(
    task_id="spark_ncst_to_mssql",
# [중요] 실제 Docker 컨테이너 내부의 파일 경로와 정확히 일치시켜야 함
    application="/usr/local/airflow/include/spark_jobs/ncst_json_to_mssql.py",
    verbose=True,
    env_vars={
"MSSQL_HOST":"host.docker.internal",# Docker에서 호스트 OS(Localhost) 접근
        ...
    },
    ...
)

[6] 트러블 슈팅 요약 및 결론

1. 폐쇄망 대응: 외부 이미지를 Pull 하는 방식은 사내망에서 매우 취약함. Dockerfile 커스터마이징을 통해 필요한 런타임(Java, Spark)을 이미지 내부에 포함하는 것이 가장 안정적임.

2. 환경 변수: Dockerfile의  설정이 런타임(Docker Compose)까지 보장되지 않을 수 잇으므로, override.yml 파일에서 확실하게 주입하는 것이 안전함.

    ENV

3. 정확한 경로 설정: Airflow Operator에서 호출하는 파일 경로는 로컬 PC 경로()가 아니라 Docker 컨테이너 내부 경로() 기준이어야 함.

    C:\...

    /usr/local/airflow/...

이 과정을 통해 네트워크 제약이 심한 Windows 환경에서도 안정적인 Airflow-Spark 데이터 파이프라인 개발 환경을 성공적으로 구축하였음.

• 기상청 초단기 실황 API(getUltraSrtNcst)를 주기적으로 호출
• Airflow DAG으로 스케줄링하여 시간 단위 데이터 자동 수집
• 수집 결과를 JSON 파일로 저장하여 이후 Spark/분석 파이프라인과 연계

[2] 파이프라인 전체 흐름

1. Airflow Scheduler가 매 정시 + 15분에 DAG 실행
2. 실행 시점의 data_interval_end를 기준으로 조회 시간 계산
3. Airflow Variable에 저장된 API Key를 사용해 기상청 API 호출
4. 응답 결과를 JSON 파일로 로컬 디렉토리에 저장
5. API 제약(과거 데이터 미제공)은 에러가 아닌 정상 스킵으로 처리

[3] 설계 시 고려사항

[3-1] 왜 Airflow를 사용했는가

• 단순 크론이 아닌 데이터 파이프라인 단위 관리
• 실행 이력, 재시도, 실패 로그를 UI에서 명확히 확인 가능
• 이후 Spark, DB 적재, 후속 DAG과 자연스럽게 연결 가능

[3-2] 초단기예보 API의 제약 사항

• 기상청 초단기 실황 API는 과거 일정 시점 이전 데이터 미제공
• catchup 실행 시 과거 시간대 요청은 실패 가능
• 따라서 “실패”가 아니라 “정상적으로 건너뜀”으로 처리해야 함

[4] DAG 핵심 설계 요소

[4-1] 시간 처리 전략

• Airflow의 data_interval_end를 기준 시점으로 사용
• 실제 API 호출 시각은 Asia/Seoul 타임존으로 변환

now = data_interval_end.in_timezone("Asia/Seoul")

이 방식의 장점:

• 실행 시점과 데이터 기준 시점을 명확히 분리
• catchup 실행 시에도 시간 계산 로직이 일관됨

[4-2] API Key 관리 방식

• 코드에 하드코딩하지 않고 Airflow Variable 사용

api_key = Variable.get("weather_decoding_api_key")

이유:

• Git 저장소에 민감 정보 노출 방지
• 환경별(API Key 교체) 관리 용이
• 운영 환경으로 확장 시에도 동일한 방식 유지 가능

[4-3] 데이터 저장 구조

• Airflow 컨테이너의 include 디렉토리 사용
• 시간 단위 파일명으로 저장

/usr/local/airflow/include/ultra_srt_weather/
└── ncst_YYYYMMDD_HH00.json

이유:

• Airflow에서 공식적으로 권장되는 공유 경로
• Spark, 후속 파이프라인에서 동일 경로 사용 가능

[5] DAG 코드 구조

[5-1] PythonOperator 기반 Task 구성

• 단일 Task에서 API 호출 + 파일 저장 수행
• 이후 Spark 처리 Task를 downstream으로 확장 가능

fetch_task = PythonOperator(
    task_id="fetch_ncst_step",
    python_callable=fetch_ultra_srt_ncst
)

[5-2] 스케줄링 설정

schedule="15 * * * *"
catchup=True

• 매 정시 + 15분 실행
• 장애 복구 시 과거 실행도 가능하도록 catchup 활성화
• 과거 데이터 미제공 구간은 내부 로직에서 자동 스킵

[6] 전체 코드

from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.decorators import dag, task

from airflow.models import Variable
from datetime import datetime, timedelta
import requests
import json
import os
import pendulum

local_tz = pendulum.timezone("Asia/Seoul")

def fetch_ultra_srt_ncst(data_interval_end, **kwargs):
    now = data_interval_end.in_timezone("Asia/Seoul")
    api_key = Variable.get("weather_decoding_api_key")
    url = 'http://apis.data.go.kr/1360000/VilageFcstInfoService_2.0/getUltraSrtNcst'
    save_dir = "/usr/local/airflow/include/ultra_srt_weather"
    os.makedirs(save_dir, exist_ok=True)

    params = {
        'serviceKey': api_key,
        'pageNo': '1', 'numOfRows': '1000', 'dataType': 'JSON',
        'base_date': now.strftime("%Y%m%d"),
        'base_time': now.strftime("%H00"), 
        'nx': '60', 'ny': '127'
    }

    response = requests.get(url, params=params, timeout=30)
    data = response.json()
    header = data['response']['header']

    if header['resultCode'] == '00':
        file_path = os.path.join(save_dir, f"ncst_{now.strftime('%Y%m%d_%H00')}.json")
        with open(file_path, 'w', encoding='utf-8') as f:
            json.dump(data, f, ensure_ascii=False, indent=4)
        print(f"저장 완료: {file_path}")
    else:
        # 1일이 지난 데이터는 기상청에서 주지 않으므로 에러로 처리하지 않고 그냥 넘어감
        print(f"건너뜀: {header['resultMsg']} ({now.strftime('%Y%m%d %H00')})")

with DAG(
    dag_id='kma_ultra_srt_ncst_collector_v4', # 새로운 ID
    default_args={'owner': 'user', 'retries': 1},
    # 현재 시간 기준 최근 12시간 전부터만 시도 (API 제약 고려)
    start_date=pendulum.now(local_tz).subtract(hours=12),
    schedule='15 * * * *', 
    catchup=True,
    tags=['kma', 'fixed']
) as dag:

    fetch_task = PythonOperator(
        task_id='fetch_ncst_step',
        python_callable=fetch_ultra_srt_ncst
    )

[7] 실제로 겪은 문제와 해결 과정

[7-1] 문제 1: Airflow Variable 미등록

증상

KeyError: Variable weather_decoding_api_key does not exist

원인

• Airflow Variable이 등록되지 않은 상태에서 Variable.get() 호출

해결

• Airflow UI 또는 CLI로 Variable 등록

airflow variablesset weather_decoding_api_key"<API_KEY>"

[7-2] 문제 2: 동적 start_date 설정으로 인한 설계 문제

start_date=pendulum.now(local_tz).subtract(hours=12)

문제점

• DAG 파싱 시점마다 start_date가 변경됨
• 스케줄 계산 및 catchup 동작이 예측 불가능해짐

교훈

• start_date는 반드시 고정된 시점으로 설정
• “최근 n시간만 처리” 같은 정책은 DAG 내부 로직으로 해결해야 함

[8] 현재 DAG의 핵심 특징 요약

• Airflow Variable 기반 API Key 관리
• data_interval_end 기준 시간 계산
• API 미제공 구간은 실패가 아닌 정상 스킵 처리
• JSON 파일 기반 결과 저장 구조
• Spark/DB 파이프라인으로 확장 가능한 설계

[9] 정리 및 배운 점

• Airflow는 단순 스케줄러가 아닌 데이터 파이프라인 오케스트레이터
• 시간 개념(data_interval)을 정확히 이해하는 것이 핵심
• 외부 API 연동 시 “실패”와 “정상적인 미제공”을 구분해야 함
• Variable/Connection 관리가 운영 안정성에 직결됨
• 처음부터 확장 가능한 구조로 DAG를 설계하면 이후 작업 비용이 크게 줄어듦

• Docker Container 환경에 Airflow & Spark 환경을 같이 구성할 것임
• 사내 노트북 환경에서는 SSL Certi가 없기 때문에 의존성 설치 시 핫스팟 사용
• 목표:
  • 로컬 윈도우 환경에서 Airflow DAG 실행
  • DAG 내부에서 PySpark 기반 데이터 처리 가능
  • Docker 기반으로 환경 통제, 로컬 개발/테스트 가능하도록 구성

[1] 설치 아키텍쳐

• 실행 방식: Docker + Astro CLI
• Airflow Runtime: quay.io/astronomer/astro-runtime:12.6.0
• Airflow Version: 2.10.4+astro.1
• Spark 사용 방식:
  • Airflow 컨테이너 내부에 pyspark 설치
  • DAG Task에서 PythonOperator를 통해 Spark 로직 실행

[2] 사전 준비

2.1 필수 도구

• Docker Desktop (Windows)
• Python (로컬 venv용)
• Astro CLI

2.2 Astro CLI 설치

pip install astro-cli

[3] Airflow 프로젝트 생성

astro dev init airflow-spark
cd airflow-spark

생성되는 주요 구조:

airflow-spark/
├─ dags/
├─include/
├─ Dockerfile
├─ requirements.txt

[4] Dockerfile 커스터마이징 (Java + PySpark 설치)

4.1 핵심 포인트

• PySpark는 Java 의존성 필요
• Airflow Runtime 이미지는 기본적으로 Java 미포함
• USER airflow 전환 시점 주의 (없는 유저일 수 있음)

4.2 최종 Dockerfile

FROM quay.io/astronomer/astro-runtime:12.6.0

USER root

# Java 17 및 필수 도구 설치
RUN apt-get update && \
    apt-get install -y --no-install-recommends openjdk-17-jdk wget && \
    rm -rf /var/lib/apt/lists/*

# MSSQL JDBC 드라이버 (Spark 연동 대비)
RUN mkdir -p /opt/airflow/jars && \
    wget -O /opt/airflow/jars/mssql-jdbc-12.4.2.jre11.jar \
    https://repo1.maven.org/maven2/com/microsoft/sqlserver/mssql-jdbc/12.4.2.jre11/mssql-jdbc-12.4.2.jre11.jar && \
    chmod 644 /opt/airflow/jars/mssql-jdbc-12.4.2.jre11.jar

ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
ENV PATH=$PATH:$JAVA_HOME/bin

# PySpark 설치
RUN pip install --no-cache-dir pyspark

4.3 최종 docker-compose.yml 파일

version: "3.1"
services:
  scheduler:
    environment:
      - JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
      - SPARK_HOME=/home/airflow/.local/lib/python3.11/site-packages/pyspark
    volumes:
      - ./jars:/opt/airflow/jars

[5] 최종 DAG 코드 핵심 포인트

Variable 안전 처리

api_key = Variable.get(
"weather_decoding_api_key",
    default_var=os.getenv("WEATHER_DECODING_API_KEY")
)
ifnot api_key:
raise ValueError("Missing API key")

data_interval_end 사용 방식

deffetch_ultra_srt_ncst(**context):
    data_interval_end = context["data_interval_end"]

start_date는 반드시 고정값

[*] Airflow 설치 TroubleShooting

문제 1: airflow user 관련 에러

에러

unableto finduser airflow:no matching entriesin passwd file

원인

• USER airflow가 Dockerfile에 있으나,
• 해당 Runtime 이미지에는 airflow 유저가 존재하지 않음

해결

• PySpark 설치는 root에서 수행
• 명시적 USER airflow 제거
• Runtime 기본 유저에 맡김

문제 2: Webserver health check timeout

증상

webserver healthcheck timedoutafter1m0s

로그 핵심

ERROR: You needto upgrade the database.
AttributeError: execution_date

원인

• 기존 Postgres 볼륨에 이전 Airflow 메타DB 스키마가 남아 있음
• 현재 Airflow 2.10.x 스키마와 불일치

해결 (로컬 개발 기준 정답)

1. Astro 스택 종료

astro dev stop

1. 컨테이너 및 볼륨 완전 삭제

docker ps -aq --filter"name=airflow-spark" | ForEach-Object { dockerrm -f$_ }
docker volumels --format"{{.Name}}" | findstr airflow-spark | ForEach-Object { docker volumerm$_ }

1. 재기동

astro dev start --wait 5m

문제 3. DAG Import Error 해결

1. 잘못된 import 경로

에러

ModuleNotFoundError: airflow.providers.standard
ModuleNotFoundError: airflow.sdk

원인

• DAG 코드가 다른 Airflow 버전 기준으로 작성됨

수정 기준 (Airflow 2.10.x 호환)

from airflow.operators.pythonimport PythonOperator
from airflow.decoratorsimport dag, task
from airflow.datasetsimport Dataset

문제 4. DAG 실행 중 Runtime 에러 (Variable)

에러

KeyError:'Variable weather_decoding_api_key does not exist'

원인

• Airflow Variable이 등록되지 않은 상태에서 Variable.get() 호출

해결

• Admin → Variables
• Key: weather_decoding_api_key
• Value: 실제 API Key

astro dev run airflow airflow variablesset weather_decoding_api_key"<API_KEY>"

start_date=pendulum.datetime(2026,1,16, tz=local_tz)

• 여러 작업을 정해진 순서와 규칙에 따라 자동으로 실행&관리하기 위한 워크플로우 오케스트레이션 도구임

  • 데이터 처리나 시스템 작업을 언제, 어떤 순서로, 실패 시 어떻게 실행할지를 코드로 정의하는 도구

  • 작업을 실행하도록 지시하고, 상태를 추적하며, 실패를 관리하는 역할을 함

[2] 왜 필요한가?

현실의 데이터는 다음과 같은 문제를 가지고 있음

• 데이터를 가져오는 시간이 반복됨
• 데이터를 가져오는 순서가 중요함
• 중간 과정에 실패가 발생할 수 있음
• 사람이 수동으로 관리하기 어려움

이것을 스크립트로만 관리하면

• 실패 시 어디서 멈췄는지 알기 어려움
• 재시도, 알림, 의존성 관리가 매우 번거로워 짐

→ Airflow는 이 문제들을 중앙에서 통제하기 위해 등장함

[3] 주요 사용처

• ETL / ELT : 여러 소스에서 데이터를 가져와 가공 및 저장하는 전 과정 자동화
• MLOps : 머신러닝 모델 학습 데이터 준비부터 학습, 평가, 배포까지의 단계를 연결
• 인프라 관리 : 특정 시간에 클라우드 자원을 생성 혹은 삭제하는 작업 관리

[4] 핵심 용어

① DAG (Directed Acyclic Graph)

• 정의: '방향성이 있고 순환하지 않는 그래프'입니다. Airflow에서 작성하는 하나의 전체 작업 흐름(Workflow) 단위입니다.
• 사용 방식: Python 파일 하나가 보통 하나의 DAG가 됩니다. 이 안에 어떤 작업들이 어떤 순서로 연결될지 정의합니다.

② Operator (오퍼레이터)

• 정의: 실제로 실행할 작업의 종류를 정의하는 템플릿입니다.
• 사용 방식: Python 함수를 실행하고 싶으면 PythonOperator, SQL 쿼리를 실행하고 싶으면 PostgresOperator를 선택하여 사용합니다.

③ Task (태스크)

• 정의: Operator가 구체적인 설정값과 결합하여 DAG 안에 배치된 상태, 즉 '작업의 최소 단위'입니다.
• 사용 방식: DAG라는 도면 위에 배치된 하나하나의 공정 단계라고 이해하면 됩니다.

④ Scheduler (스케줄러)

• 정의: 모든 DAG와 Task를 감시하며 실행 시점이 된 작업을 실행기로 보내는 '두뇌' 역할의 프로세스입니다.
• 사용 방식: 사용자가 직접 조작하기보다, 백그라운드에서 설정된 시간에 맞춰 작업을 트리거하는 역할을 수행합니다.

⑤ XCom (Cross-Communication)

• 정의: Task와 Task 사이에서 작은 데이터를 공유하기 위한 메커니즘입니다.
• 사용 방식: 첫 번째 Task에서 생성된 특정 ID나 결과값을 두 번째 Task의 입력값으로 넘겨줄 때 사용합니다.

[5] 실무 적용 시 유의사항

• 데이터 전송의 한계: XCom은 매우 작은 메타데이터 공유용입니다. 수 GB의 데이터를 Task 간에 직접 주고받으려 하면 DB가 마비됩니다. 큰 데이터는 반드시 외부 저장소(S3, GCS)를 거쳐야 함
• 리소스 관리: Airflow 자체는 계산기가 아님. 무거운 AI 연산(예: 모델 학습)은 Airflow 서버가 아닌 별도의 Worker나 Kubernetes 클러스터에서 실행되도록 설계해야 함.

글로벌 다이렉트 인덱싱과 AI로 ETF를 뛰어넘는 포트폴리오를 만들어보세요

ETF 제작소 🔗 www.miraeasset-etfmaker.com 다이렉트 인덱싱과 AI로 당신만의 투자 성공 스토리를 만들어 보세요.

*글로벌 테마 ETF를 내 마음대로 편집 *

• 관심있는 테마 ETF를 고른 후, 종목 편집과 비중 조절을 통해 나만의 ETF를 만들어보세요

*AI가 알려주는 글로벌 테마 주요 이슈 *

• 글로벌 테마에 가장 많은 영향을 끼치는 기업들의 이슈를 생성형AI가 번역·요약해줘요

*여러분의 의견을 들려주세요 *

• 투자하기 버튼을 클릭하신 후, 나타나는 구글폼에 간단한 답변을 부탁드려요 😭☝ . 여러분의 소중한 의견으로 서비스를 더욱 개선하고 싶어요!

1장 데이터 모델링의 이해

데이터 모델링의 중요성 및 유의점

• 중복: 같은 시간 같은 데이터 제공
• 비유연성: 사소한 업무 변화에 데이터 모델이 수시로 변경되면 안됨. 데이터 정의를 사용 프로세스와 분리한다.
• 비일관성: 데이터 간 상호 연관 관계에 대해 명확히 정의해야 한다.

데이터 모델링

개념적 논리적 물리적 데이터 모델링

데이터 독립성 요소

• 외부 스키마: 개개 사용자가 보는 개인적 DB 스키마
• 개념 스키마: 모든 사용자 관점을 통합한 전체 DB
• 내부 스키마: 물리적 장치에서 데이터가 실제적 저장

데이터 독립성

• 논리적 독립성: 개념스키마 변경, 외부스키마에 영향 안준다
• 물리적 독립성: 내부스키마 변경, 외부/개념 스키마에 영향 안준다

Mapping(사상)

• 상호 독립적인 개념을 연결시켜주는 다리
• 논리적 사상: 외부 스키마 - 개념 스키마
• 물리적 사상: 개념 스키마 - 내부 스키마

데이터 모델링의 3요소

• 어떤 것(Things)
• 성격 (Attributes)
• 관계 (Relationships)

모델링의 특징

(현실세계) -> 추상화, 단순화, 정확화 -> (모델)

데이터 모델 표기법

1796년 피터첸이 Entity Relationship Model 개발

• IE, Baker 기법이 많이쓰임
• 엔티티, 관계, 속성으로 이뤄짐

ERD 작업순서

1. 엔티티 그리기
2. 엔티티 배치
3. 엔티티 관계설정
4. 관계명 기술
5. 관계의 참여도 기술
6. 관계필수여부

좋은 데이터 모델의 요소

1. 완전성: 업무에 필요한 모든 데이터가 모델에 정의
2. 중복 배제: 하나의 DB내에 동일한 사실은 한번만
3. 업무규칙: 많은 규칙을 사용자가 공유하도록 제공
4. 데이터 재사용: 데이터가 독립적으로 설계되어야 함.
5. 의사소통: 업무규칙은 엔티티, 서브타입, 속성, 관계등의 형태로 최대한 자세히 표현
6. 통합성: 동일한 데이터는 한번만 정의, 참조 활용

엔티티

업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것, 보이지 않는 개념 포함

엔티티의 특징

1. 반드시 해당 업무에서 필요하고 관리하고자 함
2. 유일한 식별자에 의해 식별 가능
3. 두 개 이상의 인스턴스의 집합
4. 업무 프로세스에 의해 이용되어야 함
5. 반드시 속성이 있어야 함
6. 다른 엔티티와 최소 1개 이상의 관계가 있어야 함 -> 통계성/코드성 엔티티는 관계 생략 가능

엔티티의 분류

유무형에 따른 분류

유형, 개념, 사건 엔티티

• 유형: 물리적 형태 ex) 사원, 물품, 강사
• 개념: 개념적 정보 ex) 조직, 보험상품
• 사건: 업무수행시 발생 ex) 주문 , 청구, 미납

발생시점에 따른 분류

기본/키, 중심, 행위 엔티티

• 기본: 그 업무에 원래 존재하는 정보, 타 엔티티의 부모역할, 자신의 고유한 주식별자 가짐 ex)사원, 부서
• 중심: 기본 엔티티로부터 발생, 다른 엔티티와의 관계로 많은 행위 엔티티 생성 ex) 계약, 사고, 주문
• 행위: 2개 이상의 부모 엔티티로부터 발생, 자주 바뀌거나 양이 증가 ex) 주문목록, 사원변경이력

엔티티의 명명

현업 업무에서 사용하는 용어 사용, 약어 사용 금지, 단수명사 사용, 고유한 이름 사용, 생성의미대로 부여

속성

업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 분리되지 않는 최소의 데이터 단위

• 한 개의 엔티티는 2개 이상의 인스턴스 집합
• 한개의 엔티티는 2개 이상의 속성을 가짐
• 한개의 속성은 1개의 속성값을 가짐

구성 방식의 분류

PK, FK, 일반 속성

속성의 분류

기본, 설계, 파생 속성

• 기본: 업무로부터 추출한 모든 일반적인 속성
• 설계: 업무를 규칙화하기 위해 새로 만들거나 변형, 정의하는 속성 ex) 일련번호
• 파생: 다른 속성에 영향을 받아 발생하는 속성, 빠른 성능을 낼 수 있도록 원래 속성의 값을 계산, 적을수록 좋음 ex) 합

도메인

속성에 대한 데이터 타입, 크기, 제약사랑 지정

속성의 명명

1. 해당업무에서 사용하는 이름 부여
2. 서술식 속성명을 사용 금지
3. 약어 사용 금지
4. 구체적으로 명명하여 데이터 모델에서 유일성 확보

관계

엔티티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태, 관계 페어링의 집합 ex) 강사 - 가르친다(관계) - 수강생

페어링

엔티티 안에 인스턴스가 개별적으로 관계를 가지는 것

UML(통합모델링 언어)에서의 관계

• 연관관계 (실선): 항상 이용하는 관계 ex) 소속된다.
• 의존관계 (점선): 상대 행위에 의해 발생하는 관계 ex) 주문한다.

관계의 표기법

관계명: 관계의 이름 관계차수: 1;1, 1;M, M;N 관계선택성(관계선택사양): 필수관계, 선택관계

관계 체크사항

1. 2개의 엔티티 사이에 관심있는 연관 규칙이 있나?
2. 2개의 엔티티 사이에 정보의 조합이 발생하나?
3. 업무 기술서, 장표에 관계연결에 대한 규칙이 서술되어 있나?
4. 업무기술서, 장표에 관계 연결을 가능케 하는 동사가 있나?

식별자

엔티티 내에서 인스턴스를 구분하는 구분자 식별자는 논리적, Key는 물리적 데이터 모델링 단계에 사용

식별자의 특징

유일성, 최소성, 불변성, 존재성

• 유일성: 주식별자에 의해 모든 인스턴스들이 유일하게 구분
• 최소성: 주식별자를 구성하는 속서으이 수는 유일성을 만족하는 최소의 수가 되어야 함
• 불변성: 지정된 주식별자의 값은 자주 변하지 않아야 함. 변하면 이전 기록 말소됨
• 존재성: 주식별자가 지정되면 반드시 값이 들어와야 함

식별자 분류

대표성여부

주식별자, 보조식별자

• 주식별자: 엔티티 내에서 각 occurance를 구분할 수 있는 구분자, 타 엔티티와 참조관계를 연결한다.
• 보조연결자: 구분자이지만 대표성과 참조관계 연결이 없다

스스로 생성 여부

내부식별자, 외부식별자

• 내부식별자: 스스로 생성되는 식별자
• 외부식별자: 타 엔티티로부터 받아오는 식별자

속성의 수

단일식별자, 복합식별자

• 단일식별자: 하나의 속성으로 구성
• 복합식별자: 2개 이상의 속성으로 구성

대체 여부

본질식별자, 인조 식별자

• 본질식별자: 하나의 속성으로 구성
• 인조식별자: 인위적으로 만든 식별자

주식별자 도출기준

• 해당 업무에서 자주 이용되는 속성임

2. 명칭, 내역등과 같이 이름으로 기술되는 것들은 안된다.
3. 복합적으로 주식별자로 구성할 경우 너무 많은 속성 X

-> 너무 많으면 인조식별자 생성한다.

식별자 관계

주식별자

자신의 주식별자로 부모의 주식별자 상송

• 부모로부터 받은 식별자를 자식엔티티의 주식별자로 이용하는 경우
• 강한 연결관계 표현, 실선 표기
• 식별자 관계로만 설정 시 주식별자 증가로 오류 유발

비식별자

부모 속성을 자식의 일반 속성으로 사용

1. 부모 없는 자식이 생성될수 있는 경우
2. 부모롸 자식의 생명주기가 다른경우 (별도로 소명)
3. 여러개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔티티가 별도의 관계를 가진 경우
4. 자식 엔티티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
5. SQL 문장이 길어져 복잡성이 증가되는 것 방지
   • 약한 연결관계 표현, 점선 표기
   • 비식별자 관계로만 설정 시 부모 엔티티와 조인하여 성능 저하

2장. 데이터 모델과 성능

성능 데이터 모델링

DB 성능 향상을 목적으로 설계단계의 데이터 모델링 때부터 정규화, 반정규화, 테이블통합, 테이블분할, 조인구조, PK, FK 등 여러가지 성능과 관련된 상항이 데이터 모델링에 반영될 수 있도록 하는 것

분석/설계 단계에서 데이터 모델에 성능을 고려한 데이터 모델링을 수행할 경우 성능 저하에 따른 재업무 비용을 최소화 할 수 있음

데이터의 증가가 빠를수록 성능 저하에 따른 성능 개선 비용은 기하급수적으로 증가하게 된다.

성능 데이터 모델링 고려사항 순서

1. 데이터 모델링을 할 때 정규화를 정확하게 수행
2. DB 용량산정을 수행한다.
3. DB에 발생되는 트랜잭션의 유형을 파악하낟.
4. 용량과 트랜잭션의 유형에 따라 반정규화를 수행
5. 이력모델의 조정, PK/FK조정, 슈퍼/서브타입 조정,
6. 성능 관점에서 데이터 모델을 검증한다.

함수적 종속성

데이터들이 어떤 기준 값에 의해 종속되는 현상

(-) 정규화

반복적인 데이터를 분리하고 각 데이터가 종속된 테이블에 적절하게 배치되도록 하는 것

• 1차 정규화: 같은 성격, 내용 컬럼이 연속될 때 칼럼 제거, 테이블 생성
• 2차 정규화: PK 복합키 구성일 때 부분적 함수 종속 관계 데이터 분리
• 3차 정규화: PK가 아닌 일반 칼럼에 의존하는 칼럼 분리

(+) 반정규화

정규화된 엔티티, 속성, 관계에 대해 시스템의 성능향상과 개발과 운영의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링의 기법

조회 시 디스크 I/O가 많거나 경로가 멀어 조인에 의한 성능 저하를 막기 위해 수행

일반적으로 정규화시 입력./수정/삭제 성능이 향상되며 반정규화시 조인 성능이 향상된다.

반정규화 절차

1. 반정규화 대상조사 (범위처리 빈도수, 범위, 통계성)

   • 자주 사용되는 테이블에 접근하는 프로세스 수가 많고 항상 일정한 범위만을 조회하는 경우
   • 테이블에 대량의 데이터가 있고 대량의 데이터 범위를 자주 처리하는 겨웅에 처리범위를 일정하게 줄이지 않으면 성능을 보장할 수 없는 경우
   • 통계성 프로세스에 의해 통계 정보를 필요로 할 때 별도의 통계테이블을 생성한다.
   • 테이블에 지나치게 많은 조인이 거렬 데이터를 조회하느 ㄴ작업이 기술적으로 어려울 경우

2. 다른 방법유도 검토 (뷰, 클러스터링, 인덱스 조정)

   • VIEW 사용: 지나치게 많은 조인이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우 뷰를 사용한다. 뷰가 성능향상을 시키는것은 아니다.
   • 클러스터링: 대량의 데이터처리나 부분처리에 의해 성능이 저하되는 경우 클러스터링을 적용하거나 인덱스를 조정함 (조회가 대부분일 때 클러스터링 적용)
   • 파티셔닝: 대향의 데이터는 PK의 성격에 따라 부분적인 테이블로 분리할 수 있다. 파티셔닝 키에 의해 물리적 저장공간 분리
   • 캐시: 응용 어플리케이션에서 로직을 구사하는 방법을 변경함으로써 성능을 향상시킬 수 있다.

3. 반정규화 적용

1. 테이블 반정규화

   테이블 병합 (1:1 관계, 1:M 관계, 슈퍼/서브타입)

   1. 1:1관계를 통합하여 성능향상
   2. 1:M관계를 통합하여 성능향상
   3. 슈퍼 서브 관계를 통합하여 성능향상

   테이블분할 (수직분할, 수평분할)

   1. 수직분할: 칼럼단위 테이블을 디스크 I/O를 분산처리하기 위해 테이블을 1:1로 분리하여 성능 향상
   2. 수평분할: 로우단위로 집중 발생되는 트랜잭션을 분석하여 디스크 I/O 및 데이터 접근의 효율성을 높여 성능을 향상하기 위해 로우 단위로 테이블을 쪼갬

   테이블 추가

   1. 중복: 다른 업무이거나 서버가 다른 경우 동일한 테이블구조를 중복하여 원격 조인을 제거하여 성늘 향상
   2. 통계: SUM, AVG 등을 미리 수행하여 계산해 줌으로써 조회시 성능을 향상
   3. 이력: 이력테이블 중에서 마스터 테이블에 존재하는 리코드를 중복하여 이력테이블에 존재시켜 성능 향상
   4. 부분: 하나의 테이블의 전체 칼럼 중 자주 이용하는 집중화된 칼럼들이 있을 때 디스크 I/O를 줄이기 위해 해당 칼럼들을 모아놓은 별도의 반정규화된 테이블을 생성

2. 칼럼 반정규화

   1. 중복칼럼 추가: 조인에 의해 처리할 때 성능저하를 예발하기 위해 중복된 칼럼을 위치시킴
   2. 파생칼럼 추가: 트랜잭션이 처리되는 시점에 계산에 의해 발생되는 성능 저하를 예방하기 위해 미리 값을 계산하여 칼럼에 보관
   3. 이력테이블 칼럼추가: 대량의 이력데이터를 처리할 때 불특정 날 조회나 최근 값을 조회할 때 나타날 수 있는 성능저하를 예벙허가 위해 이력테이블에 기능성칼럼 (최근값여부, 시작과 종료일자 등)을 추가함
   4. 응용시스템 오작동을 위한 칼럼 추가: 업무적으로는 의미가 없지만 사용자의 실수로 원래 값으로 복구하기 원하느 경우 이전 데이터를 임시적으로 중복하여 보관하는 기법
   5. PK에 의한 컬럼 추가: 단일 PK안에서 특정 값을 별도로 조회하는 경우 성능 저하 발생할 수 있어 일반 속성으로 추가함

3. 관계 반정규화: 무결성 유지

   • 중복관계 추가: 데이터를 처리하기 위한 여러 경로를 거쳐 조인이 가능하지만 이 때 발생할 수 있는 성능저하를 예방하기 위해 추가적인 관계를 맺는 방법

로우 체이닝

로우의 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고 두 개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태

로우 마이그레이션:

데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장하는 방식

로우 체이닝과 로우 마이그레이션이 발생하여 많은 블록에 데이터가 저장되면 DB 메모리에서 디스크 I/O가 발생할때 많은 I/O가 발생하여 성능저하 발생 트랜잭션을 분석하여 적절하게 1:1 관계로 분리함으로써 성능 향상이 가능하도록 해야 한다.

PK에 의해 테이블을 분할하는 방법 (파티셔닝)

1. RANGE PARTITION: 대상 테이블이 날짜 또는 숫자값으로 분리가 가능하고 각 영역별로 트랜잭션이 분리되는 경우 ex)요금_0401

2. LIST PARTITION: 지점, 사업소등 핵심적인 코드값으로 PK가 구성되어 있고 대량의 데이터가 있는 테이블의 경우 ex) 고객_서울

3. HASH PARITION: 지정된 해쉬 조건에 따라 해시 알고리즘이 적용되어 테이블이 분리

테이블에 대한 수평/수직분할의 절차

1. 데이터 모델링을 완성한다.
2. DB 용량산정을 한다.
3. 대량 데이터가 처리되는 테이블에 대해 트랜잭션 처리 패턴을 분석한다.
4. 칼럼 단위로 집중화된 처리가 발생하는지, 로우 단위로 집중화된 처리가 발생하는지 분석하여 집중화된 단위로 테이블을 분리하는것을 검토한다.
   • 칼럼 많음 -> 1:1 분리
   • 데이터 많음 -> 파티셔닝

슈퍼/서브 타입 모델

업무를 구성하는 데이터를 공통과 차이점의 특징을 고려하여 효과적 표현. 논리적 모델이다

• 슈퍼타입: 공통부분
• 서브타입: 공통으로부터 상속받아 다른 엔티티와 차이가 있는 속성

슈퍼/서브 타입 데이터 모델의 변환 기술

1. 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성 (OneToOne Type)
2. 슈퍼타입 + 서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼+서브타입 테이블로 구성 (Plus Type)
3. 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성 (Single Type, All in One Type)

인덱스 특성을 고려한 PK/FK DB 성능 향상

인넥스의 특징은 여러 개의 속성이 하나의 인덱스로 구성되어 있을 떄 앞쪽에 위치한 속성의 값이 비교자로 있어야 좋은 효율을 나타낸다. 앞쪽에 위치한 속성의 값이 가급석 '=' 아니면 최소한 범위 'BETWEEN' '<>' 가 들어와야 효율적이다.

분산 DB

1. 여러 곳으로 분산되어 있는 DB를 하나의 가상 시스템으로 사용할 수 있도록 한 DB
2. 논리적으로 동일한 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터 집합

분산 DB를 만족하기 위한 가지 투명성

1. 분할 투명성 (단편화) 하나의 논리적 Relaion이 여러 단편으로 분할되어 각 사본이 여러 site에 저장.
2. 위치 투명성 사용하려는 데이터의 저장 장소 명시 불필요. 위치정보가 시스템 카탈로그에 유지
3. 지역사상 투명성 지역 DBMS와 물리적 DB 사이의 매핑 보장
4. 중복 투명성 DB 객체가 여러 site에 중복 되어 있는지 알 필요가 없는 성질
5. 장애 투명성 구성요소의 장애에 무관한 트랜잭션의 원자성 유지
6. 병행 투명성 다수 트랜잭션 동시 수행 시 결과의 일관성 유지, Timestamp, 분산 2단계 Locking 이용

2023-07-05

총 점 72점으로 합격이닷!

문제 설명

다음은 어느 자동차 대여 회사의 자동차 대여 기록 정보를 담은 CAR_RENTAL_COMPANY_RENTAL_HISTORY 테이블입니다. CAR_RENTAL_COMPANY_RENTAL_HISTORY 테이블은 아래와 같은 구조로 되어있으며, HISTORY_ID, CAR_ID, START_DATE, END_DATE 는 각각 자동차 대여 기록 ID, 자동차 ID, 대여 시작일, 대여 종료일을 나타냅니다.

문제

CAR_RENTAL_COMPANY_RENTAL_HISTORY 테이블에서 평균 대여 기간이 7일 이상인 자동차들의 자동차 ID와 평균 대여 기간(컬럼명: AVERAGE_DURATION) 리스트를 출력하는 SQL문을 작성해주세요. 평균 대여 기간은 소수점 두번째 자리에서 반올림하고, 결과는 평균 대여 기간을 기준으로 내림차순 정렬해주시고, 평균 대여 기간이 같으면 자동차 ID를 기준으로 내림차순 정렬해주세요.

답안

SELECT CAR_ID, ROUND(AVG(DATEDIFF(END_DATE, START_DATE)+1),1) AS AVERAGE_DURATION
FROM CAR_RENTAL_COMPANY_RENTAL_HISTORY
GROUP BY CAR_ID
HAVING AVG(DATEDIFF(END_DATE, START_DATE)+1)>=7
ORDER BY AVERAGE_DURATION DESC, CAR_ID DESC

문제설명

다음은 중고 거래 게시판 정보를 담은 USED_GOODS_BOARD 테이블과 중고 거래 게시판 첨부파일 정보를 담은 USED_GOODS_FILE 테이블입니다. USED_GOODS_BOARD 테이블은 다음과 같으며 BOARD_ID, WRITER_ID, TITLE, CONTENTS, PRICE, CREATED_DATE, STATUS, VIEWS는 게시글 ID, 작성자 ID, 게시글 제목, 게시글 내용, 가격, 작성일, 거래상태, 조회수를 의미합니다.

USED_GOODS_USER 테이블은 다음과 같으며 USER_ID, NICKNAME, CITY, STREET_ADDRESS1, STREET_ADDRESS2, TLNO는 각각 회원 ID, 닉네임, 시, 도로명 주소, 상세 주소, 전화번호를 의미합니다.

문제

USED_GOODS_BOARD와 USED_GOODS_USER 테이블에서 중고 거래 게시물을 3건 이상 등록한 사용자의 사용자 ID, 닉네임, 전체주소, 전화번호를 조회하는 SQL문을 작성해주세요. 이때, 전체 주소는 시, 도로명 주소, 상세 주소가 함께 출력되도록 해주시고, 전화번호의 경우 xxx-xxxx-xxxx 같은 형태로 하이픈 문자열(-)을 삽입하여 출력해주세요. 결과는 회원 ID를 기준으로 내림차순 정렬해주세요.

답안

SELECT DISTINCT
U.USER_ID, 
U.NICKNAME, 
CONCAT_WS(" ", U.CITY,U.STREET_ADDRESS1,U.STREET_ADDRESS2) AS 전체주소, 
CONCAT_WS("-", SUBSTRING(TLNO, 1, 3), SUBSTRING(TLNO, 4, 4), SUBSTRING(TLNO, 8, 4)) AS 전화번호
FROM USED_GOODS_BOARD AS B
JOIN USED_GOODS_USER AS U 
ON B.WRITER_ID = U.USER_ID
WHERE U.USER_ID IN (SELECT WRITER_ID 
        FROM USED_GOODS_BOARD
        GROUP BY WRITER_ID
        HAVING COUNT(*) >= 3)
ORDER BY U.USER_ID DESC;

문제 설명

당신은 폰켓몬을 잡기 위한 오랜 여행 끝에, 홍 박사님의 연구실에 도착했습니다. 홍 박사님은 당신에게 자신의 연구실에 있는 총 N 마리의 폰켓몬 중에서 N/2마리를 가져가도 좋다고 했습니다. 홍 박사님 연구실의 폰켓몬은 종류에 따라 번호를 붙여 구분합니다. 따라서 같은 종류의 폰켓몬은 같은 번호를 가지고 있습니다. 예를 들어 연구실에 총 4마리의 폰켓몬이 있고, 각 폰켓몬의 종류 번호가 [3번, 1번, 2번, 3번]이라면 이는 3번 폰켓몬 두 마리, 1번 폰켓몬 한 마리, 2번 폰켓몬 한 마리가 있음을 나타냅니다. 이때, 4마리의 폰켓몬 중 2마리를 고르는 방법은 다음과 같이 6가지가 있습니다.

첫 번째(3번), 두 번째(1번) 폰켓몬을 선택 첫 번째(3번), 세 번째(2번) 폰켓몬을 선택 첫 번째(3번), 네 번째(3번) 폰켓몬을 선택 두 번째(1번), 세 번째(2번) 폰켓몬을 선택 두 번째(1번), 네 번째(3번) 폰켓몬을 선택 세 번째(2번), 네 번째(3번) 폰켓몬을 선택 이때, 첫 번째(3번) 폰켓몬과 네 번째(3번) 폰켓몬을 선택하는 방법은 한 종류(3번 폰켓몬 두 마리)의 폰켓몬만 가질 수 있지만, 다른 방법들은 모두 두 종류의 폰켓몬을 가질 수 있습니다. 따라서 위 예시에서 가질 수 있는 폰켓몬 종류 수의 최댓값은 2가 됩니다. 당신은 최대한 다양한 종류의 폰켓몬을 가지길 원하기 때문에, 최대한 많은 종류의 폰켓몬을 포함해서 N/2마리를 선택하려 합니다. N마리 폰켓몬의 종류 번호가 담긴 배열 nums가 매개변수로 주어질 때, N/2마리의 폰켓몬을 선택하는 방법 중, 가장 많은 종류의 폰켓몬을 선택하는 방법을 찾아, 그때의 폰켓몬 종류 번호의 개수를 return 하도록 solution 함수를 완성해주세요.

제한사항

nums는 폰켓몬의 종류 번호가 담긴 1차원 배열입니다. nums의 길이(N)는 1 이상 10,000 이하의 자연수이며, 항상 짝수로 주어집니다. 폰켓몬의 종류 번호는 1 이상 200,000 이하의 자연수로 나타냅니다. 가장 많은 종류의 폰켓몬을 선택하는 방법이 여러 가지인 경우에도, 선택할 수 있는 폰켓몬 종류 개수의 최댓값 하나만 return 하면 됩니다.

입출력 예

nums result [3,1,2,3] 2 [3,3,3,2,2,4] 3 [3,3,3,2,2,2] 2

def solution(nums):
    choose=int(len(nums)/2)
    nums=set(nums)

    answer=min(len(nums),choose)

    return answer

입력은 항상 짝수로 주어지기 때문에 만약 모든 폰켓몬의 종류가 다르면 고를 수 있는 가장 많은 수의 폰켓몬의 수는 num/2이다.

폰켓몬의 종류가 중복되는 경우를 고려해 set함수를 사용하여 중복을 제거했다.

둘 중 더 작은 수를 반환해야되기 때문에 min함수를 사용했다.

문제설명

BOOK 테이블에서 2021년에 출판된 '인문' 카테고리에 속하는 도서 리스트를 찾아서 도서 ID(BOOK_ID), 출판일 (PUBLISHED_DATE)을 출력하는 SQL문을 작성해주세요. 결과는 출판일을 기준으로 오름차순 정렬해주세요.

정답

```sql

SELECT BOOK_ID, DATE_FORMAT(PUBLISHED_DATE, '%Y-%m-%d') AS PUBLISHED_DATE FROM BOOK WHERE CATEGORY='인문' AND DATE_FORMAT(PUBLISHED_DATE, '%Y')='2021' ORDER BY PUBLISH_DATE

문제 설명

다음은 중고거래 게시판 정보를 담은 USED_GOODS_BOARD 테이블과 중고거래 게시판 첨부파일 정보를 담은 USED_GOODS_REPLY 테이블입니다. USED_GOODS_BOARD 테이블은 다음과 같으며 BOARD_ID, WRITER_ID, TITLE, CONTENTS, PRICE, CREATED_DATE, STATUS, VIEWS은 게시글 ID, 작성자 ID, 게시글 제목, 게시글 내용, 가격, 작성일, 거래상태, 조회수를 의미합니다.

USED_GOODS_REPLY 테이블은 다음과 같으며 REPLY_ID, BOARD_ID, WRITER_ID, CONTENTS, CREATED_DATE는 각각 댓글 ID, 게시글 ID, 작성자 ID, 댓글 내용, 작성일을 의미합니다.

문제

USED_GOODS_BOARD와 USED_GOODS_REPLY 테이블에서 2022년 10월에 작성된 게시글 제목, 게시글 ID, 댓글 ID, 댓글 작성자 ID, 댓글 내용, 댓글 작성일을 조회하는 SQL문을 작성해주세요. 결과는 댓글 작성일을 기준으로 오름차순 정렬해주시고, 댓글 작성일이 같다면 게시글 제목을 기준으로 오름차순 정렬해주세요.

*답안 *

sql SELECT TITLE, BOARD.BOARD_ID, REPLY_ID, REPLY.WRITER_ID, REPLY.CONTENTS, DATE_FORMAT(REPLY.CREATED_DATE, '%Y-%m-%d') AS CREATED_DATE FROM USED_GOODS_REPLY AS REPLY LEFT JOIN USED_GOODS_BOARD AS BOARD ON REPLY.BOARD_ID=BOARD.BOARD_ID WHERE DATE_FORMAT(BOARD.CREATED_DATE, '%Y-%m') = '2022-10' ORDER BY REPLY.CREATED_DATE, TITLE

VPN은 인터넷에 가상의 전용선 공간을 만들어 놓아 거점 간을 안전하게 연결하기 위한 기술 또는 이를 사용하여 구축한 네트워크를 가리킨다.

VPN은 공인 인터넷을 사이에 둔 사설망과 사설망이 공인 IP로의 NAT와 같은 제약 없이 사설 IP를 이용해 통신가능하도록 지원하며 데이터의 암호화를 제공한다. 이를 실현하기 위해 VPN은 공인 인터넷에서 IP packet을 캡슐화함과 동시에 데이터의 암호화/인증방식을 협상하게 된다.이 협상 과정을 거친 후에는 캡슐화된 패킷이 오고가기 때문에 아무리 공인 인터넷상이라 하더라도 외부인이 이 패킷ㅇ르 쉽게 탈취할 수 없다. 이 기술을 Tunneling 이 하며 이에 사용된 프로토콜을 Tunneling Protocol이라 부른다 .

VPN 장비를 사용하게 되면, 별도의 전용선을 사용하으로 발생되는 망 임대료를 절감할 수 있고, 인터넷을 사용함으로 인한 낮은 비용 대비 높은 통신 속도를 장점으로 누릴수 있다.

위 그림의 빨간색 선은 실제로 터널을 만드는것이 아니라 VPN 장비 간에 트래픽을 주고받을 때 트래픽이 암호화되어 전송되는 것을 논리적으로 표현한 것이다.

Site-to-Site VPN

두 개의 네트워크 도메인이 가상의 사설 네트워크 연결을 사용하여 프라이빗 통신을 가능하게 하는 서비스로 표준 IPSec VPN만 지원한다.

개념

• VPN 연결: 온프레미스 장비와 VPC 간의 보안 연결

• VPN 터널: 데이터가 고객 네트워크에서 AWS와 주고받을 수 있는 암호화된 링크

• 각 VPN 연결에는 고가용성을 위해 동시에 사용할 수 있는 두 개의 VPN 터널이 포함되어 있다

• 고객 게이트웨이: 고객 게이트웨이 디바이스에 대한 정보를 AWS에 제공하는 AWS 리소스이다

• 고객 게이트웨이 디바이스: Site-to-Site VPN 연결을 위해 고객 측에 설치된 물리적 디바이스 또는 소프트웨어 애플리케이션이다

• 대상 게이트웨이(Target gateway): 사이트 간 VPN 연결의 Amazon 측 VPN 엔드포인트를 일컫는 일반적인 용어

• 가상 프라이빗 게이트웨이(Virtual private gateway): 가상 프라이빗 게이트웨이는 단일 VPC에 연결할 수 있는 사이트 간 VPN 연결의 Amazon 측 VPN 엔드포인트

• 전송 게이트웨이(Transit gateway): 사이트 간 VPN 연결의 Amazon 측 VPN 엔드포인트로 여러 VPC와 온프레미스 네트워크를 상호 연결하는 데 사용될 수 있는 전송 허브

IPSec VPN

IPSec VPN은 주로 site-to-site 방식으로 사용되는 VPN이다. 또한 패킷을 암호화함으로써 LAYER 3의 단점인 데이터 암호화를 해결한다.

이는 IPSec이라 불리는 Tunneling Protocol이 있기에 가능한 것이다.

패킷의 이동과 암호화는 전적으로 VPN이 책임지기 때문에 VPN 하단의 장비와 PC들은 패킷 이동과 암호화를 신경 쓰지 않고 Routing을 통해 상대편 네트워크로 이동할 수 있다.

IPSec은 통신 세션의 각 IP패킷을 암호화하고 인증하고 안전한 인터넷 프로토콜 (IP)통신을 위한 인터넷 프로토콜 스위트이다. 이 보안은 통신 세션의 개별 IP 패킷을 인증하고 암호화함으로써 처리된다. IPSec은 세션으 ㅣ시작에서 에이전트들 사이에서 상호 인증을 확립하거나 세션을 맺는 중에 사용될 암호화 키의 협상을 위한 프로토콜을 포함한다.

여기서 IPSec의 역할은 인터넷 경유 구간에서 안전한 터널을 생성하고 패킷을 인증할 수단을 제공하며 패킷을 암호화할 키를 관리하고 제공하는 것이다.

운용모드

전송모드: IP Header를 변형하지 않고 그대로 사용하면서 IP Header를 제외한 데이터 부분만을 인증 혹은 보호하며 단말이 미 모든 과정을 담당하기에 단말과 단말 강 통신이 가능하다는 특징

터널모드: New IP Header (공인 IP)를 추가적으로 씌워 Origin IP Header (사설 IP)를 캡슐화 하고 IP패킷 전체를 인증 혹은 보호하며, VPN 장비가 이를 도맡아 하므로 사설 네트워크와 사설 네트워크 간 통신을 가능테 한다. 현재 사용하고 있는 IPSec VPN 대부분은 터널 모드를 사용한다.

Authentication Header (AH)와 Encapsulating Security Payload (ESP)는 IP 패킷의 보안성을 부여하기 위한 프로토콜 헤더로 패킷을 암호화/인증하는 역할을 한다. 이 둘을 사용하는 이유는 IPSec 터널 내를 흐르는 데이터 패킷을 암호화하고 인증하여 외부침입으로부터 보호하는 것이다.

인터넷 프로토콜 설계 시 패킷의 암호화에 대한 고려가 전혀 반영되어있지 않지 때문에 프로토콜 헤더를 추가로 부착하는 방법을 사용해 IP 패킷의 암호화를 실현하는 것이다.

AH

AH는 IP패킷의 무결성을 입증하기 위한 프로토콜 헤더이다. 패킷의 데이터 부분에 해당하는 IP payload와 IP 헤더를 인증한 후 인증 데이터를 생성하여 AH 헤더에 이를 포함시켜 패킷에 부착한다. 그리고 New IP Header (공인 IP)를 추가로 씌어 기존 AH 헤더, IP 헤더와 IP Payload를 캡슐화한다.

Integrity Check Value는 사설 IP에 대한 정보가 있는 IP헤더와 IP Payload 그리고 New Ip Header를 해쉬 알고리즘을 이용해 고정 크기의 블록으로 만든것이다. 공격자가 IP Payload 혹은 IP Header에 조작한다면 조작된 데이터에 해쉬 알고리즘을 적용 시 헤더 내 인증 데이터와 일치하지 않을테니 외부의 개입 여부를 단번에 알 수 있다.

페이로드 내부의 프로토콜 헤더를 알려주는 'Next HEader', 페이로드의 길이를 정의하는 'Payload Length'등이 있다.

AH는 인증에 관한 작업을 수행할 뿐 패킷의 암호화에는 전혀 관여하지 않는다. 그렇기 때문에 데이터가 쉽게 노출되어 안전하지 않아 잘 사용되지 않는다.

ESP

ESP 헤더는 AH 헤더의 인증 기능에 더해 AH 헤더의 약점인 패킷 암호화 기능을 갖춘 프로토콜 헤더이다.

암호 알고리즘 (DES, 3DES, AES)과 함께 암호화 키를 사용하여 패킷을 암호화한다.

ESP는 패킷의 페이로드와 IP header를 암호화 하고 ESP헤더와 선택사항인 인증 데이터를 부착한 후, New IP Header를 씌워 패킷을 캡슐화한다.

IP Sec 터널을 통과하는 패킷은 아래 패킷과 같은 모습으로 통과한다.

ESP Trailer는 패킷을 암호화하면 필수적으로 생성되는, 페이로드와 인증 데이터를 구분하기 위한 padding 과 내부 프로토콜 헤더에 관한 정보를 담고 있다.

ESP Header는 IP Header와 IP Payload 그리고 ESP Trailer를 암호화 한다.

이 암호화 한 IP Header & Payload, Trailer에 해쉬 알고리즘을 적용하여 인증 데이터인 ESP Auth를 생성하여 부착한다 ESP Trailer와 ESP Auth가 필수적인 역할을 담당하다 보니 ESP Header는 많은 정보를 담고 있지 않다.

SPI는 Security Association(SA)의 식별번호이다. SA란 VPN과 VPN이 데이터를 안전하게 교환하기 위해 쌍방 간 합의되는 사항을 의미한다.

네트워크 분야에서 방화벽은 네트워크 상에서 공격자의 침입이나 바이러스 등으로부터 발생하는 보안 사고 및 문제가 더 이상 확대되는 것을 차단하고 격리하는 벽을 역할을 하는 하드웨어나 소프트웨어를 뜻한다.

네트워크 상 보안 사고를 방지하는 방법은?:

• 권한없는 트래픽을 차단한다.
• 방화벽 내에서 정해진 정책을 따라 트래픽을 통제한다.

Packet Filter (패킷 필터)

패킷 필터는 방화벽 1세대로써, 현재는 잘 사용하지 않지만 초창기에 많이 사용된 방화벽 방식이다.

패킷 필터링은 OSI 7계층 구조에서 전송 계층과 네트워크 계층에서 동작라며, 지나가는 패킷의 헤더안의 IP address 와 Port address만을 단순 검색하여 통제한다.

패킷 필터 방화벽은 인터넷 내부 네트워크의 경계에 설치해서 패킷의 IP주소와 포트번호 등의 조건으로 통신을 허가하거나 거부를 한다. 이렇게 패킷 필터링은 미리 정해놓은 정책에 따라 전송을 허용한다.

패킷 필터링 정책의 예시:

• 명시적으로 금지되지 않은 통신 모두 허용
• 명시적으로 금지되지 않은 통신 모두 거부 (Default Deny)
  • 이 방식이 더 안전하다
• 위 두가지가 혼합된 방식

Stateful Inspection 방식이나 Application gateway 방식에 비하여 처리 속도가 빠르고 적용/운용이 쉽다. ** 패킷 필터의 구성요소:**

• Input Interface
• IP destination and source address
• Utilized transport protocol
• Flags e.g. from TCP header
• Time and date
• Application via transport protocols and server-side port numbers

단점:

• 하나의 서비스를 허용하기 위해서는 패킷이 들어오느 방향과 나가는 방향에 대한 접근규칙을 정의해야 하므로 두 개 이상의 정책 설정이 필요하다.
• Protocol Tunneling의 경우나 암호화 된 메세지가 네트워크 안으로 들어왔을 때 처리하기 어렵다.
• 가변적인 통신포트를 사용하는 서비스나 FTP 처럼 다중 포트를 사용하는 서비스를 처리하기 매우 어렵다.
• 전송중인 데이터가 응용 프로그램에 부정적인 영향을 미칠지 여부를 미리 정의된 정책이 없다면 확인할 수 없다.
• 신뢰할 수 있는 소스 주소에서 허용된 악의적인 행위로 인해 데이터베이스가 삭제되더라도 방화벽은 확일할 방법이 없다.
• 전송되는 모든 패킷을 정책과 비교해야 하기 때문에 전송 속도가 느려지고, 패킷의 헤더를 조작하는 방식으로 우회로 접근할 수 있다. _ Protocol Tunneling이란?:_ 한 네트워크에서 다른 네트워크로 데이터를 이동할 수 있도록 하는 통신 프로토콜이다. 캡슐화 되어 전송되기 때문에 packet filtering에 적합하지 않다.

Static packet filter

Stateless

• 정적 패킷 필터는 당장 표시된 패킷 헤더만을 기반으로 동작한다.

Dynamic packet filter

Stateful

• 한번 허용된 패킷은 잠깐 세션을 저장하여, 후속 패킷들은 그대로 통과시킨다.
• Application 계층까지 분석하고, 네트워크 연결 상태를 추적한다.
• 이 방식이 요즘날 쓰이는 방식이다.
• Static paket filtering 보다는 더 넓은 트래픽을 볼 수 있어 다양한 계층 공격에 대응할 수 있지만 속도는 상대적으로 떨어질 수 있다.
• Load balancing이나 다른 방화벽으로 전환하는 것이 어렵다.

Network Address Translation

가장 추천하는 combination: NAT-Gateway & packet filter

Symmetric NAT

IP:PORT 검증

Symmetric NAT은 연결된 Destination에 따라 다른 외부 IP:PORT 로 매핑된다는 특징을 갖는다.

외부 네트워크 통신에서의 제약사항은 Port Restricted Cone NAT과 동일하게 적용된다.

Host의 Private NAT에 대해 NAT 장비가 매핑하는 정보가 통신 대상에 따라 달라진다.

고정 매핑 방식이 아니라 가변적인 매핑 방식으로 이해할 수 있다.

• 매핑 테이블:

  <internal private IP address, internal port, externally used IP address, externally used port, IP address of the communication partner in the Internet, port of the communication partner in the Internet, transport protocol>

• 들어오는 패킷들을 자동적으로 블락하기 때문에 VoIP는 사용하기 까다롭다.

  Cone NAT

Cone NAT은 NAT 장비가 NAT 네트워크의 Host에 대해 공인 IP:PORT로 매핑한 주소가 변하지 않는다는 특징을 갖는다.

• 매핑 테이블:

  <internal private IP address, internal port, externally used IP address, externally used port, transport protocol>

Full Cone NAT

제한사항 없음

가장 개방적인 형태의 NAT 방식으로 외부 네트워크 누구든지 NAT 장비에 매핑된 Public IP:PORT로 접근 시 내부 네트워크 Host에 통신을 시도할 수 있다.

Restricted Cone NAT

IP 검증 이전에 Host가 외부로 데이터를 전송한 적이 있는 ip만 허용한다. 따라서 통신한 적이 없는 주소로부터 패킷을 받으면 드랍한다.

Port Restricted Cone NAT

IP/PORT 검증

이전에 통신하던 IP주소와 PORT가 일치해야만 패킷을 수신할 수 있다.

Linux Packet Filter

netfilter

• 리눅스 커널 내부의 네트워크 관련 프레임워크
• 다양한 네트워크 관련 연산을 핸들러 형태로 구현할 수 있도록 훅(hook) 제공
• 네트워크 주소 변환, 패킷 필터링 및 패킷 분해 등을 용이하게 해준다.
• iptable을 통해 접근 권한 제어

iptable이란?

• 리눅스 OS 방화벽
• 방화벽, 라우터, 브리지 역할을 한다.
• IP Packet Filtering, NAT 관리 도구
• 여러개의 netfilter 모듈로 구현된다.

기능:

• 상태추척 : iptables 경유 패킷들에 대한 연결상태 추적 기능
• 매칭 : 출발지와 목적지 IP, 출발지와 목적지 PORT, 프로토콜 등을 통한 매칭 기능
• 로그 : 매칭 패킷의 로그 저장
• 포트 포워딩 : NAT 기능 포함

Application Level Gateway (ALG)

프록시 (Proxy) 또는 Session Border Controller (SBC) 라고도 불린다.

프록시(Proxy)는 "대리"의 의미로, 인터넷과 관련해서 쓰이는 경우, 특히 내부 네트워크에서 인터넷 접속을 할 때에, 빠른 액세스나 안전한 통신등을 확보하기 위한 중계서버를 "프록시 서버"라고 일컫는다. 클라이언트와 Web서버의 중간에 위치하고 있어, 대신 통신을 받아 주는 것이 프록시 서버이다.

서버의 IP를 숨기는 기능과 외부로부터 위험을 막아주는 역할을 한다.

• 프록시 서버에는 캐시가 있는데 이는 이전에 했던 요청들을 프록시 서버에 저장해두어 다음 번에 재요청을 보낼 때 서버를 거치지 않고 데이터를 주고 받을 수 있도록 한다 -> 더 빠른 연결 속도!

• 프록시 서버를 사용하면 사용자의 IP주소를 감출 수 있는데 이 때문에 어느 곳에서 접속한지를 숨길 수 있다.

패킷 필터링과 다른점:

• application 기능과 사용자 사이에서 communication이 제한되어 있다.
• 사용자가 rule을 지정할 수 있다.
• content checking
• 사용자는 communiation partner와 직접적으로 communication을 하지 않는다.
• Applcation Level 에서 작동한다.

주로 패킷 필터링과 함께 쓰인다.

단점:

• 특정 application에게 강하게 의존적이다.
• host와 직접적으로 연결되어 있기 때문에 easier to discover.

네트워크 보안: 네트워크를 통한 통신에 관한 위협을 대비한 보안

• Intercept: 메세지, 통신 내용에 대한 엑세스
• Manipulate: 메세지
• Spoof: 공격자가 발신자, 수신자 또는 둘 전부에게 신원을 위조
• Disrupt: 통신 링크

OSI 계층 별 발생 가능한 공격

Packet Sniffing

스니핑은 네트워크상에서 전송자와 수신자 사이에 주고 받는 데이터를 패킷 수준으로 분석하여 계정, 비밀번호, 프로토콜, 시스템 정보 등 유의미한 내용을 알아내기 위한 해킹기법이다.

• OSI의 모든 계층에서 발생 가능
• End Systems 과 relay(e.g. switch, router..)에서 발생 가능
• 공격을 탐지하는데에도 사용됨.

보호 방법:

• 암호화: packet sniffing을 해도 공격자가 그 안의 데이터 보지 못하도록
• 인증: 사용자 인증을 통해 데이터 변경 혹은 spoofing으로부터 보호
• packet sniffing을 방해하는 행위는 어렵다.

라우팅 조작

• 공격자가 제어하는 컴퓨터를 통해 트래픽 유도
• 라우팅 방해
• 예: 가짜 라우팅 프로토콜 메세지 -> 인증 전송
• 예: ICMP redirection 메시지
• 예: 소스 라우팅

MAC address Spoofing

MAC Spoofing 이란?: NIC (Network Interface Card) 의 유일한 MAC address를 악의적인 목적으로 위조하는 공격 방식

MAC address 란?: MAC address는 통신을 하기 위해서 필요한 각 장비에 부여된 48bit로 이루어진 물리적인 주소이다.

MAC address를 위조하여 사용자로 둔갑하여 인증을 받아낼 수 있다. 예: DHCP 서버, WLAN AP, 서비스 제공업체에 엑세스

• Spoofinf 감지가 거의 불가능하다.

ARP Spoofing

MAC address를 IP로 변환하는 프로토콜로서 ARP스푸핑 공격은 통신하는 두 대상의 MAC address를 공격자 자신의 MAC address로 바꾸어 중간에서 패킷을 가로채는 공격이다.

가정: 통신중에 있는 A와 B의 정보가 궁금한 공격자는 ARP 스푸핑 공격을 하기로 한다.

• 공격자는 A와 B의 통신 중간에 들어가, A와 B에게 각각 자신의 MAC address를 알려준다
• A와 B는 공격자를 서로 통신하는 대상으로 인식하여 공격자에게 통신 정보를 전송하게 되며, A와 B의 통신내용을 공격자가 모두 볼 수 있게 된다.

또한 통신내용을 보고나서 다시 그 정보를 원래 목적지로 보내거나, 패킷을 일부 변조하여 보낼수도 있다.

패킷을 변조해서 보내는 경우에는 보통 목적이 PC를 감염시켜 좀비 PC로 만들기 위함이다.

ARP 스푸핑을 통한 공격

• 서비스 거부 공격: DoS, DDoS 공격은 종종 ARP 스푸핑을 활용하여 여러 IP 주소를 단일 대상의 MAC address와 연결한다. 결과적으로 다양한 IP 주소를 대상으로 하는 트래픽이 대상인 MAC 주소로 리디렉션 되어 트래픽으로 대상에 과부하가 걸린다.

• Session Hijacking: 세션 하이잭킹은 ARP 스푸핑을 사용하여 세션 ID를 훔쳐 공격자에게 개인 시스템 및 데이터에 대한 엑세스 권한을 부여할 수 있다.

• Man in the Middle: MITM 중간자 공격은 ARP 스푸핑에 의존하여 피해자 간의 트래픽을 가로채고 수정할 수 있다.

ARP 스푸핑 탐지 및 공격 예방 방법

• 패킷 필터링: 패킷 필터는 충동하는 소스 주소 정보가 있는 패킷을 필터링하고 차단할 수 있기 때문에 ARP 스푸핑 방지에 유용하다.
• 신뢰 관계 피하기: 신뢰 관계는 인증을 위해 IP 주소에만 의존하므로 공격자가 ARP 스푸핑 공격이 있을 때 훨씬 더 쉽게 실행 할 수 있다.
• ARP 스푸핑 탐지 소프트웨어 사용
• 암호화 네트워크 프로토콜 사용
• 자체 IP 주소에 대한 ARP 쿼리의 불일치 테스트

IP Spoofing

IP 스푸핑(IP Spoofing)이란 IP(Internet Protocol) 자체의 보안 취약성을 악용한 것으로 자신의 IP 주소를 속여서 접속하는 공격을 말한다. 신뢰 관계에 있는 두 시스템 사이에서 허가받지 않은 자가 자신의 IP 주소를 신뢰 관계에 있는 호스트의 IP 주소로 바꾸어 속이는 것으로 rlogin, rsh 와 같이 IP 주소로 인증하는 서비스를 무력화시킬 수 있다. 즉 공격자가 마치 신뢰성 있는 자가 송신한 것처럼 패킷의 소스 IP 주소를 변조하여 접속을 시도하는 침입 형태를 말한다.

IP 스푸핑은 주로 IP 주소나 호스트 이름에 의존하는 인터넷 서비스들을 대상으로 자행된다.

IP Spoofing 공격 방법

1. 클라이언트(1.1.1.2) 를 DOS 공격한다.
2. 공격자가 소스 IP 를 1.1.1.2 로 변조 후 SYN 패킷을 서버에 보낸다.
3. 서버는 1.1.1.2 에게 ACK/SYN 패킷으로 응답한다.
4. 공격자는 서버에 ACK 를 보내 클라이언트(1.1.1.2) 인 것처럼 연결을 성립한다.

IP Spoofing 공격 대응 방안

• 라우터에서 source routing 허용 않기
• Sequence Number를 랜덤하게 발생시키도록 함
• DoS 취약성 제거
• IP로 인증하는 서비스들 가능하면 사용하지 않도록 한다.

TCP Sequence Number Attack

서버측 초기 시퀀스 번호 추측 -> TCP handshake 위조 가능, 위조 IP로 TCP 연결

예를 들어,

1. 공격자A는 IP주소 C로 TCP 연결을 시작한다.
2. B는 C에 응답하지만 초기 시퀀스 번호가 올바르게 주측된 경우 A는 TCP 연결을 가진다.

DNS Spoofing

DNS는 도메인를 IP 주소로 변환하는 역할을 한다.

DNS 스푸핑이란 DNS 서버로 보내는 쿼리를 가로채서 변조된 결과를 보내주는 것으로 일종의 MITM 공격이다.

1. 공격자는 ARP 스푸핑을 통해 클라이언트가 DNS 서버로 보내는 DNS 쿼리 패킷을 탐지한다.
2. 공격자는 로컬에 존재하기 때문에 정상적인 DNS 서버가 보내는 응답 패킷보다 변조된 DNS 응답 패킷을 먼저 보낼 수 있다. 클라이언트는 변조된 DNS 응답 패킷을 신뢰하고, 이후 도착한 정상적인 DNS 응답 패킷은 폐기한다.
3. 이로 인해 클라이언트는 공격자가 유도하는 피싱 사이트에 접속하게 된다.

Classes of Authentication

인증을 하는 방법은 여러가지가 있다.

• 지식을 통한 인증: 비밀번호, PIN, Cryotographic key, TAN
• 소유물을 통한 인증: 스마트 카드, USB-Token, SIM 카드
• 생체정보를 이용한 인증: 지문, 홍채, DNA
• 행동을 통한 인증: 목소리, 걸음걸이
• 여러 요소를 혼합한 인증: ex. banking card and PIN

Password Security

비밀번호의 안정성은 다음에 따라 결정된다:

• 비밀번호의 길이, 조합, 정책
• 비밀번호를 저장하는 시스템의 안전성 및 사용자가 비밀번호를 얼마나 안전하게 보관하는지.
• 비밀번호 입력/전소 시 보안

비밀번호 도메인의 크기는 다음과 같이 결정된다.

특수기호, 대문자, 소문자 등을 혼합하여 비밀번호를 생성했을때 비밀번호 도메인이 커지는 것을 확인할 수 있다.

시도-응답 인증 (Challenge-Response Authentication)

기존의 ID + PASSWORD 방식은 재전송 공격에 취약하다. 시도-응답 인증은 이런 취약점을 보완하기 위해 대칭키 기반의 소지기반 보안을 추가한 일회성 인증 방법이다.

시도-응답 인증에서 중요한 개념은 일회성 인증이다. 은행의 시크리트 카드보다 OTP가 보안성이 훨씬 좋은 것과 같은 맥락이다. 사용지가 인증을 원할 경우 서버에선 사용자에게 일회성 Challenge를 보낸다. 사용자는 이를 비밀키로 암호화하여 서버에 Response 한다. Challenge 는 일회성으로 난수로 예측할 수 없고 매번 다른 값으로 바뀌어야 한다.

이런 방식이라면 해커가 중간에 Response를 스니핑 하더라도 이를 재사용 할 수 없다. 이미 한번 쓰였던 일회용 값이기 때문이다.

이러한 인증 방법을 사용하려면 서버와 클라이언트만 알고 있는 대칭키(비밀키)가 필요하다.

대칭키를 이용한 인증 (Authentication by Symmetric Key)

대칭 암호화를 위한 비밀키가 이미 사용자 사이에서 공유가 되었을 때 인증방법.

1. 사용자A는 사용자B에게 인증을 받고자 한다.
2. 사용자B는 난수 x를 생성한다.
3. 사용자B는 사용자A에게 난수 x를 대칭키를 이용해 암호화하라고 요청한다.
4. 사용자A가 암호화 된 x를 사용자B에게 전송한다.
5. 사용자B가 자신의 대칭키로 x를 암호화한 결과와 비교한다. 같다면 인증 완료.

공개키를 이용한 인증 (Authentication by Public Key)

사용자B가 사용자A의 공개키를 알고있을 때 사용가능한 인증방법

1. 사용자A는 사용자B에게 인증을 받고자 한다.
2. 사용자B는 난수 x를 생성한다.
3. 사용자B는 사용자A에게 난수 x를 개인키를 이용해 암호화하라고 요청한다.
4. 사용자A가 암호화 된 x를 사용자B에게 전송한다.
5. 사용자B는 자신이 아는 사용자A의 공개키로 x를 암호화한 결과와 비교한다. 같다면 인증 완료.

장점:

• 서버와 클라이언트가 사전에 비밀을 합의할 필요가 없음
• 공개키가 진짜인지 확인해야 함. 따라서 Public Key Infrastructure (PKI)가 필요하다.
• 또한 서버는 저장된 공개키의 무결성을 보장하여 공격자가 위조된 키와 교환할 수 없도록 해야한다.

대안: 서버는 응답 외에 로그인 할 때마다 클라이언트로부터 유효한 인증서를 요청할 수 있으며, 이를 기반으로 공개 및 개인 키의 유효성을 확인한다.

전자 서명 (Signature)

서명과정:

1. 사용자A는 공개키와 개인키의 쌍을 생성한다.
2. 전자문서(원문)을 해시함수에 통과시켜 고정된 길이의 출력값으로 변환한다.
3. 출력값을 사용자의 개인키로 암호화한다. 이는 "내 개인키로 원문의 사실에 서명한다" 라는 의미를 가지게 되는데 이렇게 개인키에 의해 암호화 생성된 메시지가 전자서명이다.

검증과정:

1. 사용자B는 사용자A의 공개키를 이용하여 사용자A의 전자서명을 복호화한다.
2. 생성 과정 때와 마찬가지로 전자문서(원문)을 해시함수에 통과시켜 축약 메시지를 만들어 낸다.
3. 축약된 메시지의 값이 복호화된 전자서명과 일치하는지 대조하여 전자서명을 검증한다.

전자서명 5가지 필수 원칙:

• 위조 불가 조건: 합법적인 서명자만이 전자문서에 대한 전자서명을 생성할 수 있음
• 서명자 인증 조건: 전자서명의 서명자를 누구든지 검증할 수 있음
• 부인 불가 조건: 서명자는 서명 후에 자신의 서명 사실을 부인할 수 없음
• 변경 불가 조건: 서명한 문서의 내용은 변경할 수 없음
• 재사용 불가 조건: 전자문서의 서명은 다른 전자문서의 서명으로 사용될 수 없음

Creation of Trust

Certification Authority (CA)로 부터 인증 완료된 public key를 받는 행위

Certification Authority (인증기관): 디지털 서명을 이용한 전자상거래 등에 있어서 누구나가 객관적으로 신뢰할 수 있는 제 3자를 의미한다.

구현 방식으로는 Direct Trust, Web of Trust, Hierarchical Trust 가 존재하는데 Hierarchial Trust 방법을 채택하는 경우가 대다수이다.

Public Key Infrastructure (PKI)

공개키 기반 구조.

• 공인된 인증기관이 인터넷상에서 사용자간에 법적 효력이 있는 인증서를 전자적으로 분배, 전달, 제공함으로써 비인가된 자로부터 개인 정보보호, 전자상거래 위변조 방지 등을 할 수 있게 한다.

• 목적: 누구나 안전하게, 편리하게, 효율적으로 공개키를 휙득 사용하게 하는 것

PKI 주요 구성 요소

• 인증서 (Certificate)
• 인증기관 (Certification Authority)
  • Issues certificates and signs them
  • Publishes current certificates
  • Creates and publishes lists of invalid certificates, Certificate Revocation List (CRL)
  • Provides Online Certificate Status Protocol (OCSP) for clients
• 등록기관 (Registration Authority)
  • 소유자와 공개키가 연결이 잘 되도록 해준다
• 저장소 (Repository)
• 인증서 관리 시스템
• 사용자
• Timestamp
  • 유효기간, 등등
• Personalization
  • Transmission of keys (secret key) and certificates

인증서 (Certificates)

공개키나 공개키 관련 정보를 포함한다.

• 주로 X.509 v3 표준 형식에 기반한다.

인증서 계층구조 (Certificate Hierarchies)

• 상위 CA는 하위 CA에게 인증서 제공한다.
• Root CA는 최상위 CA이다. ex. Regulatory Authority for Telecommunications
• 인증서 유효성 검사 -> 인증 경로

Virus: 다른 프로그램을 infect할 수 있는 piece of software Trojan: 좋은 function의 프로그램인줄 알았는데 알고보니 이상한 프로그램 Worm: 네트워크 통해서 전파되는 프로그램. 자기복제 가능

Viruses

• Parasitic virus: executeable file에 붙어서 자가복제하는 바이러스
• Memory-resident virus: 메인 메모리에 붙어있어서 실행하는 모든 프로그램 infect 시킨다.
• Boot sector virus: Master boot record를 감염시켜 부팅 할 때마다 감염
• Stealth virus: anti-virus 프로그램인 척 그 안에 숨어 있는 바이러스
• Polymorphic virus: 매 감염마다 약간 달라진다.
• Metamorphic virus: polymorphic과 다르게 완전히 달라져서 바이러스 찾기 더욱 어렵게 한다.
• Retrovirus: antivirus program만 공격하는 바이러스
• Macrovirus: platform independant. ex) .doc 파일 감염시키면 이 확장자 지원하는 시스템 감염시키기

Worm

바이러스와 달리 네트워크 통해 전파되기 때문에 사용자의 잘못이 아니다. Major issue is lack of security of permanent connected systems

Trojan Horse

program with hidden side-effects

Malicious Software

• Spyware: ex) key looger to steal PIN
• Adware: 사용자에게 원치 않은 광고 보여주기
• Ransomeware: 사용자 documents 복호화하기 위해 돈을 요구함
• Zombie: 다른 권한없는 제 3자에 의해 컴퓨터가 돌아가게 됨 ex)Botnet
• Backdoor (Trapdoor): Modification을 하여 공격자가 시스템에 접근할 수 있도록 함.

블록체인이란 다수의 거래내역을 묶어 블록을 구성하고, 해시를 이용하여 여러 블록들을 체인처럼 연결한 뒤, 다수의 사람들이 복사하여 분산 저장하는 알고리즘이다.

블록체인의 장점

• decentralization 탈중앙화
• transparency 투명성
• immutability 불변성
• redundancy 중복성

데이터의 위변조가 불가능하여 권위있는 중개기관이 없더라도 신뢰할 수 있는 안전한 거래와 데이터처리를 할 수 있다.

블록체인이 쓰이는 곳

• Smart Contracts:블록체인 기술은 암호화폐에만 사용할 수 있는 것이 아니라 위변조 방지가 필요한 각종 계약서 작성에 활용할 수 있다. 특히 일정한 조건이 만족되면 자동으로 계약 내용이 실행되도록 하는 스마트 계약 기능에 사용할 수 있다.
• Cryptocurrencies
• Electronical Auction
• Supply Chain: 거래내역의 위변조가 어려운 블록체인 기술을 활용하여 물류관리 시스템을 운영할 수 있다.
• Identity Management:블록체인에 기록된 개인 신원 데이터는 위변조가 불가능하기 때문에 전 세계적인 범위에서 작동하는 글로벌 신원확인 시스템에 사용될 수 있다.
• Diamond Trade: 에버레저(EverLedger)는 전 세계 120만 개가 넘는 다이아몬드에 대해 광산에서 채굴될 때부터 감정회사와 도매상, 소매상을 거쳐 소비자에게 전달될 때까지 모든 거래내역과 다이아몬드의 일련번호, 색, 투명도, 컷, 캐럿, 크기 등 제품 상세정보를 블록체인에 기록하여 관리하겠다고 밝혔다.
• Internet of Things
• Government: 블록체인 기술을 활용하여 정부, 기업, 교육기관, 의료기관 등에서 발급하는 각종 문서를 위변조 없이 안전하게 관리할 수 있다. 개별 문서에 담긴 내용을 해시로 변환하여 블록체인에 저장한 뒤 여러 곳에 분산 저장하면, 해당 문서에 대한 위변조가 사실상 불가능해진다.
• Health
• Media
• Finance

블록체인의 종류

Public Blockchain :

모든 사람이 관여할 수 있다. 권위 있는 조직의 승인이 없이 누구든지 인터넷에 연결된 PC, 노트북, 스마트폰, 서버컴퓨터, 채굴기 등 다양한 컴퓨터 장비를 이용하여 블록체인 네트워크에 참여할 수 있다. 이러한 블록체인 네트워크에 참여하는 개별 컴퓨터를 노드(node)라고 부르는데, 각 노드들은 블록체인에 저장된 데이터를 복사하여 저장하고, 해시 연산을 통해 새로운 블록의 생성에 참여할 수 있다. 또한 각 노드들은 언제든지 자신의 컴퓨터를 블록체인 네트워크에 연결하지 않고 접속을 차단함으로써 자유롭게 탈퇴할 수 있다. 블록체인 네트워크에 참여 또는 탈퇴하는 것은 권위 있는 조직의 승인이 필요 없이, 전적으로 해당 노드 참여자의 자유로운 의사에 따라 결정할 수 있다. 비트코인, 이더리움, 비트코인캐시, 이오스, 스텔라루멘, 스팀, 모네로 등 대부분의 암호화폐는 퍼블릭 블록체인 방식으로 운영된다

Private Blockchain :

프라이빗 블록체인(private blockchain)이란 미리 정해진 조직이나 개인들만 참여할 수 있는 폐쇄형 블록체인 네트워크를 말한다. 사적 블록체인, 폐쇄형 블록체인, 허가형 블록체인, 기업형 블록체인 또는 엔터프라이즈 블록체인(enterprise blockchain)이라고 한다. 프라이빗 블록체인에 참여하려면 반드시 권위 있는 조직의 승인을 받아야 한다. 프라이빗 블록체인 운영자의 승인을 받지 못한 조직이나 개인은 해당 블록체인 네트워크의 운영에 참여할 수 없다.

Hybrid Blockchain :

하이브리드 블록체인(hybrid blockchain)이란 퍼블릭 블록체인과 프라이빗 블록체인을 서로 연결하거나 섞은 혼합형 블록체인을 말한다. 더블체인(double chain)은 퍼블릭 블록체인과 프라이빗 블록체인을 연결한 체인이다. 컨소시엄 블록체인(consortium blockchain)이란 동일한 목적이나 가치를 가지고 있는 다수의 기업과 단체들이 하나의 컨소시엄을 구성하고 그 안에서 작동하도록 만든 블록체인이다. 예를 들어 리눅스재단이 주도하고 IBM 등이 참여하여 만든 하이퍼레저 패브릭(hyperledger fabric) 프로젝트가 있다.

블록체인의 구성요소

1. Cryptography
2. P2P Network
3. Validiay Rules
4. Consensus Mechanism
5. Ledger

블록체인 실행도

새로운 노드 추가

• 새로운 노드를 추가하기 위해선 노드를 추가하고자 하는 장치가 인터넷에 연결이 되어있고 블록체인을 네트워크에 유지시켜놔야 한다.
• 요구조건:
  • transaction를 송신/수신 하기 위해 public address와 함께 private/public key 쌍을 알아야 한다.
  • 블록체인에 이미 존재하는 node가 필요하다

Public Address

1. 사용자가 wallet에 접근한다.
2. wallet에서 16진수로 된다 256bit 난수를 생성하여 private key를 생성한다.
3. private key에서 Eliptic Curve Cryptography를 사용하여 Public key를 생성한다.
4. Public key에서 hashing, RIPEMD-160, check encoding을 실행하여 Public Address를 얻는다.

트랜잭션

*트랜잭션이란 여러개의 작업을 하나로 묶은 일련의 실행유닛이다. *

더 이상 쪼갤 수 없는 업무 처리의 최소 단위!

각 트랜잭션들은 특정 작업으로 시작해서 연결된 모든 작업을 완료해야 정상적으로 종료되게 된다. 만약 트랜젝션에 속한 여러 작업 중 하나의 작업이라도 실패하는 경우 모든 트랜젝션이 실패한 것으로 간주한다.

비트코인의 트랜잭션 구조

• 버전번호: 채굴자, 노드들이 트랜잭션 처리시 지켜야 할 규칙 지정
• 입력 카운터: 트랜잭션에 포함된 입력의 개수
• 입력 리스트: 블록의 첫 트랜잭션은 코인베이스 트랜젝션이 된다. 입력 리스트에는 최소 하나 이상의 트랜잭션 입력이 포함된다.
• 출력 카운터: 출력의 갯수를 의미
• 출력 리스트: 트랜잭션에 포함되는 출력 리스트
• 로크 시간: 트랜잭셔닝 유효해지는 최단 시간을 정의

Merkel Tree

블록안에 있는 트랜잭션은 Merkel Tree 안에 저장된다.

Merkel Tree는 이진트리라는 이름으로도 알려져 있다. 이 때 이진트리는 쉽게 말해 거래를 두 개씩 묶는다는 뜻이다.

이렇게 두 개씩 트랜잭션을 묶어서 올라가게 되면 거래량이 기하급수적으로 늘어나도 특정 거래를 찾는 경로는 단순하다는 이점이 있다.

거래의 건수의 N이 증가할 때마다 특정 거래의 경로를 찾는 수는 $log_2(N)$ 으로 늘어나기 때문이다.

거래 내역을 위조하려는 시도가 있어도 머클 트리의 경로를 따라가면 해시값이 다른 것이 나오게 되어 거래의 위변조도 쉽고 바르게 알 수 있게 되고 이를 방지 할 수 있다.

블록

• 루트해시란? 모든 하위 hash들을 다시 hash 함수로 변환한 최종 hash 값. 256bit로 고정되어 있다. 하나의 block에는 모조건 하나의 root hash가 있는데 이때 하위hash가 하나라도 변경되면 root hash도 바뀌게 된다.

• 왜 이전 hash에 연결하는것이 힘들까? 새로운 블록을 기존 블록에 연결하기 위해선 hash값을 찾아야 하는데 새로운 블록의 hash는 반드시 미리 정해진 목표값보다 작아야 하기 때문이다. 이 해위를 작업 증명(PoW)라고 한다. 이것의 대가로 일정한 개수의 암호화폐를 지급받는 것을 채굴(mining)이라고 한다.

Consensus (합의)

블록체인의 데이터는 중앙화된 서버 대신 전세계에 흩어져 있는 수많은 노드에 보관되기 때문에 각각의 노드들은 블록에 기록하는 데이터가 위변조되지 않은 원본이라는 것을 상호간에 합의하는 과정이 필요하다.

만약 블록을 생성하는 특정 노드가 악의를 품고 조작된 데이터를 저장하거나 네트워크에 전파한다면 시스템 전체의 신뢰도가 떨어지게 된다.

이런 악의적인 상황이 발생하더라도 네트워크를 올바른 방향으로 이끌고자하는 다수의 노드들이 상호 검증을 거쳐 올바른 블록 생성을 이끌어내는 프로세스와 알고리즘을 바로 Consensus라고 한다.

• PoW (Proof-of-Work) : 작업증명 블록 생성 시간동안 가장 많은 해시파워를 제공한 노드가 블록을 생성할 수 있도록 설계한다.

  컴퓨팅 파워를 통해 블록체인 네트워크에 전송된 암호화된 거래정보를 푼 뒤, 새로운 블록을 체인에 연결하는 작업을 하는 것을 의미한다.

  현재 높은 시장 가치를 형성하고 있는 주류 코인들이 채택하고 있지만 높은 전력소모를 통해 자원을 낭비한다.

  그러나 보안성은 매우 강력하다.

• PoS (Proof-of-Stake) : 지분증명

  코인을 보유한 지분율에 따라 새롭게 생성하는 코인을 분배받는 방식의 컨센서스 알고리즘이다.

  PoW와는 다르게 일정 수 이상의 코인을 보관하고 있는 지갑을 블록체인 네트워크에 연결시켜 놓기만 하면 보상을 받을 수 있다.

  해시파워가 많이 필요하지 않으므로 경제적이고 친환경적이며 블록 생산자의 탈중앙화로 안정성을 확보할 수 있다.

  그러나 보안성이 강한지에 대한 여부가 아직까지 정확하게 검증되지 않았고 지분이 많은 이른바 고래들이 권역을 독점할 가능성이 존재한다.

• DPoS (Delegated Proof-of-Stake) : 위임된 지분증명

  DPoS는 PoS 컨센서스 알고리즘을 변형한 형태로 위임된 지분증명 방식을 말한다. 모든 노드의 자격을 가진 주주들이 블록생성에 참여하는 방식(PoS방식) 대신에 네트워크의 모든 노드의 투표 결과로 선출한 상위 노드(이를 증인* 또는 Witness라고 함.)에게 권한을 위임하여 합의하도록 하는 방식이다.

PoS에 비해 많은 트랜잭션을 빠르게 처리할 수 있다. PoW에 비해 비용이 낮다.

그러나 증인끼리 담합할 위험이 존재하고 공개된 소수의 증인에 대한 디도스 공격 위험이 있다.

블록체인 Fork

51% Attack

블록체인에 저장된 데이터들이 블록들에 합류하기 위해선 기존 블록들로부터 과반수 이상의 승인이 필요하다 -> 여기서 51% risk 발생가능!

현실화될 위험은 극히 낮지만 만약에 이런 문제가 일어나 자신이 보유한 블록체인의 가치가 껌값이 되면 경제적인 손실이 너무 크다.

Fork

Fork는 서로 추구하는 것이 다를 때 일어난다.

즉, 블록체인 환경이 업데이트다 될 때에도 포크가 일어나는데, 새로운 환경을 만들기 위해 업데이트를 하게 되는 경우 기존의 규칙을 따르려는 블록과 새로운 규칙에 따라 기록되는 블록으로 포킹된다.

Soft Fork

Soft fork는 기존의 규칙에서 큰 틀은 바꾸지 않고 부분적인 업데이트만 일어나기 때문에 forking 된 블록끼리 호환 가능하다.

기존 규칙을 따르던 블록체인에서도 노드들이 새로운 규칙을 따르기로 합의를 한다면 두 체인은 결국 합쳐진다.

예. MS office 2010 쓰다가 업데이트 한 MS office 2013 나오면 2010으로 저장된 파일이 2013에서도 사용이 가능한 것과 같다. 그러나 기능적인 면에서 몇 가지 제한이 있다.

Hard Fork

Hard fork는 블록의 규칙을 근본적으로 바꾸는 업데이트이다. 그렇기 때문에 이전 노드들과 호환이 되지 않는다.

하드포크는 전혀 다른 블록체인이 되어 합의에 도달하지 않고 서로 분리된 채 블록이 계속 쌓여나간다.

예. 아이폰의 iOS와 갤럭시의 안드로이드 운영체제가 서로 호환되지 않는것과 같다.

암호화 알고리즘의 한 종류로, 암호화와 복호화에 같은 암호 키를 사용하는 알고리즘을 말한다.

대칭 키 암호에서는 암호화와 복호화를 하는데 있어서 같은 암호 키를 공유해야 한다. (Private Key)

장점: 암호화 연산 속도가 빠르기 때문에 효율적인 암호 시스템을 구축할 수 있다.

단점: 키 전달 및 관리가 어렵다.

*대칭키 암호화 방식은 데이터를 변환하는 방식에 따라 Stream Cipher, Block Cipher 로 구분된다. *

Stream Cipher

• 초기값: Key
• Key는 plain text의 길이만큼 난수로 생성한다.
• Key 와 plain text를 XOR 연산을 하여 cipher text 생성

현재는 블록 암호만큼 인기있지는 않다.

Block Cipher

• plain text를 몇 개의 block들로 나눈다.
• block 마다 encryption key는 동일하다.

그러나 이 구조는 너무 간단하기에 보안에 취약하다.

운용방식이 일반적으로 대칭형 암호화와 관련하는 것이 일반적이지만 RSA와 같은 공개 키 암호 방식 원칙에도 적용 가능하다.

ECB (Electronic Code Book)

• 가장 간단한 구조
• 모두 같은 암호와 키를 사용하기 때문에 보안에 취약하다.
• 공격자가 비슷한 메세지를 반복적으로 암호화하는 반복공격에도 취약한 성질을 가진다. -> 비슷한 결과가 나오기 때문

CBC (Cipher Block Chaining)

• 각 블록은 암호와 되기 전에 이전 블록의 암호화 결과와 XO
• 첫 블록의 경우 초기화 벡터가 사용됨
• 같은 plain text block은 각기 다른 cipher text block을 생성한다.

OFB (Output Feedback), CFB (Cipher Feedback)

• 둘 다 block 암호를 자기 동기 스트림 암호로 변환한다.

  • 비동기식 자기 스트림 암호 (block cipher): 1비트씩 난수열을 생성하여 plaintext와 XOR function을 실행한다.

    

CTR (Counter) e.g. AES

• 각 블록마다 현재 블록이 몇 번째인지 값을 얻어 그 숫자와 nonce를 결합하여 블록 암호의 입력으로 사용한다.

• 그렇게 각 블록 암호에서 연속적으로 난수를 얻은 다음 암호화 할려는 문자열과 XOR 한다.

  • Nonce는 블록체인에서 목표값 이하늬 block hash를 찾기위해 임시로 사용되는 숫자

Asymmetric Encryption

• public key cryptography이다.
• 즉, 암호화와 복호화할 때 쓰는 key가 다른다.
• 송신자와 수신자는 key pair를 사용한다. (public & private)

Public Key Methods

• public key로 암호화 된 메세지는 무조건 private key로 복호화 하 ㄹ수 있다.
• public key를 안다고 private key를 알수 있는게 아니다.
• symmetrical encryption보다 key가 훨씬 길다.
• key는 수학적으로 생성된다.

RSA (Rivest, Shamir and Adleman)

RSA에서는 두 개의 key를 사용한다. 여기서 key란 메세지를 열고 잠그는 상수를 위미.

• RSA는 소인수 분해의 난해함에 기반하여 공개키만을 가지고는 개인키를 쉽게 짐작할 수 없도록 디자인되어 있다.
• 이 알고리즘은 두 개의 큰 소수들의 곱과 추가 연산을 통해 하나는 공개키를 구성하고 또 하나는 개인키를 구성한다.
• 이 때 사용되는 두 세트의 수 체계를 유도하는 작업이 수반된다.
• 한 번 그 키들이 만들어지면, 원래의 소수는 더 이상 중요하지 않으며, 버릴 수 있다.
• 공개 및 개인키 둘 모두는 암호화/복호화를 위해 필요하지만 오직 개인키의 소유자만 이를 알아야한다.
• RSA 시스템을 사용하면, 개인키는 절대로 인터넷을 통해 보내지지 않는다.

Hybrid Methods

1. A는 B에게 public key를 전송
2. B는 symmetrical encryption 방식을 쓰기위해 session key를 생성한다. A가 준 public key로 session key를 암호화 한 다음에 A에게 전송.
3. A는 session key를 사용하여 symmetrical encryption하여 암호화 된 메세지 B에게 전송

Hash Function

• Hash function은 데이터의 무결성을 제공하는 알고리즘 중 하나로 메세지 인증 알고리즘 이라고도 한다.
• 임의의 길이의 메시지를 일정한 길이의 출력으로 변환하는 함수로 메세지 무결성이나 사용자 인증을 중요시하는 전자서명에서는 해시 함수가 필수적인 역할을 하고 잇따.
• data가 변하면 hash 값도 변경된다. 그러므로 collision resistance

Message Authentication Code (MAC)

• 데이터가 변조 (수정, 삭제, 삽입 등) 되었는지 검증할 수 있도록 데이터에 덧붙이는 코드이다.

1.송신자 앨리스와 수신자 밥은 사전에 키를 공유해 둔다.

2. 송신자 앨리스는 송금 의뢰 메시지를 기초로 해서 MAC 값을 계산한다(공유 키를 사용).

3. 송신자 앨리스는 수신자 밥에게 송금 의뢰 메시지와 MAC 값을 보낸다.

4. 수신자 밥은 수신한 송금 의뢰 메시지를 기초로 해서 MAC 값을 계산한다(공유 키를 사용).

5. 수신자 밥은 앨리스로부터 수신한 MAC 값과 계산으로 얻어진 MAC 값을 비교한다.

6. 수신자 밥은 2개의 MAC 값이 동일하면 송금 의뢰가 틀림없이 앨리스로부터 온 것이라고 판단한다(인증 성공). 동일하지 않다면 앨리스로부터 온 것이 아니라고 판단한다(인증 실패).

• 메세지 암호화/복호화
• 기밀성 이외에도 데이터 무결성, non-repudiaiton, 인증 등이 포함될 수 있다.

** Cryptology = Cryptography + Cryptoanalysis (break cryptographic techniques)**

• 암호학 모델

Steganography

• 데이터를 다른 데이터에 삽입해서 데이터를 보호한다.
• 크립토그라피는 내용을 못 읽게 하는 반면 이 기술은 존재 자체를 숨긴다.

Linguistical Steganography

• Open Codes: 공개된 메세지 안에 숨겨진 메세지 ex. 퀴즈쇼에서 기침하기
• Jargon codes: 특수용어 ex. weed, Mary Jane
• Cue: 어떤 문장을 미리 합의하에 결정하기. ex. HIGASHI => WAR
• Null Cipher: ex. 문장 부호 뒤에 나오는 letter들 모으면 새로운 메세지 탄생
• Grille Cipher: masking 기법을 사용해서 숨겨진 메세지 찾기

Technical Steganography

• Technical Steganography: ex. invisible ink,miniatureization.

• Steganography의 가장 유명한 예는 RGB값 살짝 바꿔서 이미지 큰 변화 없지만 message 넣을 수 있게 하는 것이다.

암호화 방법

Substitution Cipher

Caesar Cipher

알파벳을 오륵쪽 혹은 왼쪽 shift 하여 새로운 알파벳 순서쌍을 만든다.

Transposition Cipher

Scytale Cipher

문자의 형태는 그대로 유지되지만 transposition에 따라 문자 순서쌍이 달라진다.

고대 그리스에서 많이 쓰던 방법이다.

Crypto Analysis

Brute Force Attack

key를 찾을 때까지 가능한 모든 조합을 사용하여 key를 푼다.

cost expensive하며 시간이 많이 걸린다는 단점.

ex. 찾고자 하는 binary key의 길이가 n bit 이면 가능한 key의 조합은 $2^n$ 개 이다.

컴퓨터는 1초에 1,000,000 key를 test할 수 있기 때문에 key를 풀기 위해선 $2^n/1,000,000$ seconds 가 필요하다.

Statistical Analysis

치환 암호는 측정 글자를 다른 글자로 치환함으로서 암호를 생성하는 방법이다.

위의 예시에선 단일 치환 암호화 기법을 통해 plain text를 encryted text로 변환시켰다.

이때 암호화 된 암호문을 해독하는 가장 고전적인 방법 중 하나는 통계적인 분석을 통해 해독하는 것이다.

plain text에서 각 알파벳의 빈도수를 알아 낸 뒤, 이 알파벳의 빈도수와 영어 문학에서 나타나는 알파벳의 빈도수를 비교하여 암호문의 알파벳이 원래 어떤 알파벳이었는지 알아낼 수 있다.

One-Time-Pad

일회성 패드는 절대적 보안 기능을 제공한다. 일회성 패드는 패드라는 임의 데이터 블록을 이용하는 암호 시스템이다.

생성 방법

plain text와 길이가 같은 일회성 패드를 만든다. 일회성 패드에 있는 임의 데이터는 확실히 무작위로 있어야한다. 또한 송신자와 수신자가 같은 패드를 가지고 있어야 한다.

메세지가 어떻게 보내지더라도, 메세지를 받는 사람은 패드가 없으면 복호화할 수 없기 때문에 암호에 어떤 의미가 담겨있는지, 평문을 절대 알 수 없다,

• Bad design: access control의 부재, 보안이 약한 비밀번호 or 인증
• Implementation Error: Buffer Overflow, weak random number generator
• Administrative Error: 비밀번호의 부재, 개방된 port가 너무 많은 경우 (방화벽)
• Missing Awareness: 잘못된 보안 지식, 사회공학적으로 잘못된 지식

IT Security가 필요한 이유

• Data espionage: 보안에 민감한 데이터를 갈취해 타 경쟁 회사에 팔거나 금전전인 이익을 얻는것
• Data manipulation
• Temporary malfunctioning (Dos, DDoS)
• Permanent malfunctioning (Earthquake, Fire ….)
• Attackers who want to know when and who is using the system
• Protection of information and informit ation systems

What is IT Security?

정보기술 보안은 네트워크 보안, 인터넷 보안, 엔드포인트 보안, API 보안, 크랄우드 보안, 애플리케이션 보안, 컨테이너 보안 등이 포함된다.

IT 보안은 컴퓨터 시스템, 네트워크 및 데이터와 같은 정보 기술의 무결성을 시스템 공격이나 손상 또는 무단 엑세스로부터 보호한다.

IT Security Aims

• Integrity: 허가없는 수정에 대한 보호
• Confidentiality: 허가없는 access에 대한 보호
• Availability: 기능과 서비스의 장애에 대한 보호
• Accountability: 실행했던 action을 부인하지 말아야 함
• Authenticity: identity 가 신용가능해야 함.

Weakness, Vulnerability, and Threat

• Weakness: 시스템에서 취약한 부분. 이는 나중에 시스템에서 취약점이 된다.
• Vulnerability: 시스템 내에서 인증 없이 우회, 변경, 속임을 통해 보안 시스템의 취약점이 되는 곳.
• Threat: 보안을 위반하고 해를 입힐 수 있는 상황, 기능, 조치 또는 사건이 있을 때 존재하는 보안 위반 가능성

Hazard Factors

• 자연재해: 천둥번개, 불, 홍수,지진,,,등등
• 과실: 오류, 오작동, 부적절한 대처
• 기술적 결함: 블랙아웃, 하드웨어 결함, 오작동
• 악의적인 위험: 해킹, 강도, 공공 기물 파손, 염탐, 사보타주
• 조직의 결함: 인증없는 access, 불법 복제물, 미숙련된 직원

Decision making

risk가 발생할 확률과 그로 인해 생기는 겨엦적 피해는 예측하기 매우 어렵다.

그러므로 lowest expected mean cost를 창출해내는 방법을 탖아내야 한다 .

1. immediate fix → 10,000유로
2. wait for patch → 0.260,000 + 0.80 = 12,000유로
3. shutdown → 14,000유로

이 경우에 immediate fix가 가장 작은 값을 내고 있으니 당장 시스템을 고치는 것이 경제적으로 이득이다.

Attacks

1. Passive Attack
   1. 공격자가 적극적으로 참여하지 않음
   2. 예. Sniffing, 도청, 등등
   3. 발견하기 어렵다
   4. 능동적 공뎓에 대한 예방적 보호 수단으로도 쓰임
2. Active Attack
   1. 공격자가 시스템 또는 데이터를 적극적으로 조작함
   2. 데이터 또는 시스템 조작
   3. 공격자는 종종 흔적을 남김
   4. 예방 및 탐지 가능

Social Engineering

사회 공학: 기술이 아닌 사용자를 대상으로 공격

타겟의 예시:

• 정보 수집이라 하면서 접근
• 사용자는 공격자가 원하는 작업 수행

다음과 같은 인간의 특성을 이용한다:

• 도움
• 자신감
• 불안
• 권한에 대한 존중
• 호기심, 게으름, 수치심, 죄책감, 분노,,,등등
• 인간의 약점은 악용될 수 있다.

수동적 사회 공학적 공격

• 피해자와의 상호작용 없음
• 대화 도청
• Shoulder surfing (어꺠 너머로 정보 캐내기)
• Dumpster diving (휴지통에서 정보 캐내기)
• 미끼 (준비된 USB 남겨두기)

적극적 사회 공학적 공격

• IT 직원인 척
• phishing
• 가짜 계정을 통한 인터넷 우정

IT Security Process