정보보안기사 필기_3과목 어플리케이션 보안 요약 정리

1. 인터넷 응용보안(10문제/20문제)

(1) FTP 보안

1) FTP 개념

- FTP(File Transfer Protocol)

--TCP/IP 네트워크상에서 한 호스트에서 다른 호스트로 데이터 파일을 전송하는데 사용하는 표준 프로토콜(IETF RFC 959)

- Transfer Layer 프로토콜로로 TCP를 사용하며, 서버-클라이언트 모델을 구성하고 있음

- FTP 세션은 암호화되지 않기에, 사샐활 보호 또는 개인정보 보호기능을 제공하지 않음

-- 인증정보 또한 평문으로 전달되어 스니핑 당하면 인증정보가 유출될 수 있음

2) FTP 서비스 운영

- FTP는 제어를하기 위한 연결과 데이터 전송을 위한 연결을 따로 사용해서 효율적이고 신뢰성있는 데이터 전송을 제공

-- PI(Protocol Interpreter) : 제어 명령 송/수신하는 역할

-- DTP(Data Transmission Process) : 데이터를 송/수신하는 역할

- FTP는 제어를 위한 연결을 할 때엔 21번 포트를 사용 / FTP 세션 동안 계속 유지

- FTP는 데이터 전송을 위한 연결을 할 때엔 20번 포트를 사용 / 파일 전송하는 동안 유지

- Active Mode

-- 많이 쓰이는 방식으로, 클라이언트가 서버에게 자신이 어떤 포트로 데이터를 전송할지 알려주는 방식(클라이언트가 원하는 포트 사용)

-- 1) 클라이언트가 서버의 Command Port(21번)로 데이터전송을 위해 사용할 포트를 알려줘

-- 2) 서버가 Command Port(21번)에서 클라이언트로 ACK 신호를 보냄

-- 3) 서버가 Data Port(20번)에서 클라이언트가 알려준 포트로 연결을 시도

-- 4) 클라이언트가 서버의 Data Port(20번)로 ACK 신호를 보냄

-- ※ 클라이언트는 1024 이상의 임의의 포트를 사용

-- ※ 3)에서 서버가 클라이언트로 연결시도한다는 점에서 문제점이 발생(방화벽 등에 막힐 수 있음) → Passive Mode의 사용

http://learnwithrahul.blogspot.kr/

- Passive Mode

-- 방화벽과 같은 보안솔루션 때문에 방화벽을 통해 FTP를 사용해야하는 문제점을 해결

-- Active Mode와 달리, 서버가 클라이언트로 자신이 데이터를 보내고자하는 포트를 정하는 방식

-- 1) 클라이언트가 서버의 Command Port(21번)로 Passive Mode로 접속하겠다고 ㅇ

-- 2) 서버가 Command Port(21번)에서 클라이언트에게 데이터전송을 위해 사용할 포트를 알려줘

-- 3) 클라이언트가 서버가 알려준 포트로 연결을 시도

-- 4) 서버가 클라이언트로 ACK신호를 보냄

-- ※ 클라이언트는 1024 이상의 임의의 포트를 사용

-- ※ 서버가 1024 이상의 포트를 열어둬야 된다는 점에서 보안적인 문제점이 있을 수 있지

http://learnwithrahul.blogspot.kr/

- Anonymous FTP(익명 FTP)

-- 사용자들이 할당 받은 ID 없이도 FTP 서버에 접근하고 서비스를 이용할 수 있게 해줌

-- FTP 서버에 접속 후, 사용자 아이디에는 Anonymous, 패스워드에는 아무내용 넣어도 상관없으나 자신의 이메일적는게 예의

- TFTP(Trivial File Transfer Protocol)

-- FTP보다 간단하고 최소한의 기능만 제공해주는 프로토콜

-- FTP는 TCP를 이용하는반면, TFTP는 UDP를 사용함

-- 디렉토리나 파일의 목록을 보는 명령이 없기에, 파일명을 모르는 사용자는 해당 파일 다운받지 X

--- 물론, Brute Force Attack 등으로 가능하긴 함

-- 인증절차가 없기에, 설정이 잘못되어 있으면 누구나 파일에 접근이 가능

- Unix/Linux에서 사용자 별로 FTP Server에 접근 제어를 하려면 /etc/ftpusers에 등록함(등록되면 접근이 거부됨)

- Windows에서는 FTP Server를 만드려면 IIS가 설치되어야 함

3) FTP 공격 유형

- FTP Bounce Attack

-- FTP 서버가 데이터를 전송할 때, 목적지를 검사하지 않는 설계상의 문제점을 이용한 공격

-- 공격자가 FTP 서버를 거쳐 간접적으로 임의의 호스트에 접근하거나 존재 여부를 파악가능

-- 포트 스캐닝에 쓰일 수 있음

-- 대응 방법

--- FTP의 설계상의 문제이므로, 원래 규약을 어느정도 제한하는 방법

--- 공격에 사용되는 FTP 서버는 주로 Anonymous FTP 서버이기에, 꼭 필요한 경우가 아니면 Anonymous FTP는 사용하지 X

--- FTP 서버에 접속가능한 IP주소를 필터링 / 익명 사용자는 파일 업로드 못하도록 제한

http://www.networkuptime.com/nmap/page3-20.shtml

- Anonymous FTP Attack

-- Anonymous 계정 허용하는게 위험해

-- Anonymous 계정을 위한 디렉토리 따로 만들고 / 소유자는 관리자 / 읽기 권한만 줌

-- 로그 파일 정기적으로 확인

- TFTP Attack

-- 위에서 언급했드시, Brute Force Attack이나 Dictionary Attack등으로 파일명 알아내 다운로드

-- TFTP 데몬을 Secure Mode로 작동하게 설정

-- TFTP 데몬을 필요없으면 제거해

4) FTP 보안대책

- FTP 서버 접속 시, /(Root)로 접속하는 것을 차단

- Anonymous FTP 서버의 경우, 디렉토리 소유자와 퍼미션 관리를 철저히

- 불필요한 TFTP는 제거

- FTP 자체의 취약점은 없는지 주기적으로 업데이트

(2) MAIL 보안

1) MAIL 개념

- 인터넷에 연결되어 있는 서버를 통해 메시지를 보내거나 받은 메시지 교환 방식

2) MAIL 서비스 운영

- MUA(Mail User Agent) : 사용자가 메일을 송수신하기 위해 사용하는 프로그램

- MTA(Mail Transfer Agent) : MUA로 부터 전달받은 메일을 다른 MTA로 전송하는 서버프로그램(목적지는 수신자의 MTA)

-- MTA는 STMP(TCP 25)를 이용해 다른 MTA로 메일을 전달함(STMP 서버라고도 함)

- MDA(Mail Delivery Agent) : 최종 MTA에 도착한 후, 수신된 메일을 사용자의 메일함에 저장하는 프로그램(POP과 IMAP방식)

-- 최종 MTA가 MDA의 역할을 한다고 생각하면될 듯

- MRA(Mail Retrieval Agent) : MDA가 저장한 메일을 MUA로 가져오는 프로그램(및에 사진엔 없네) / 아이디와 패스워드로 사용자 인증도함

-- POP3(Post Office Protocol 3 ; TCP 110)

--- 기본적으로 MRA가 가져간 메일은 서버에서 삭제됨

--- 추가적인 옵션을 통해, 삭제를 안시킬 수는 있음

--- 선택적으로 메일을 가져올 수가 X

-- IMAP(Internet Message Access Protocol ; TCP 143)

--- POP3와 유사한 역할을 하지만, 더 많은 기능을 제공

--- 기본적으로 MRA가 메일을 가져가도 서버에 계속 존재

--- 메일의 제목 / 본문의 일부 등의 내용만 볼 수 있음

--- 메일함이 폴더 형태로 구성되어 있어서, 모바일 장치에서도 사용하기 편함

http://en.kioskea.net/contents/116-how-email-works-mta-mda-mua

- MIME(Multipurpose Internet Mail Extensions)

-- 이메일을 위한 인터넷 표준 포맷

-- STMP가 7Bit ASCII 문자만을 지원하기에, 이 외의 형태를 가지는 데이터는 제대로 전송되지 X

-- 8Bit 이상의 코드를 가지는 문자나 파일들은, 이메일 프로그램이나 서버에서 자동으로 MIME형식으로 변환해 전달

3) MAIL 서비스 공격유형

- Active Contents Attack(기출 빈도 높대!)

-- 메일 열람시, CSS(Client Side Script)가 실행되 컴퓨터 정보를 유출하거나 악성프로그램을 실행시키는 공격

-- 대응 : 스크립팅 기능을 제거 / 스크립트 태그를 다른 이름으로 바꾸어 저장

- Malware Attack

-- 이메일 첨부파일을 실행하도록 유도해서 악성 프로그램이 실행되도록 하는 공격

-- 자극적이거나 업무와 관련된 파일인척 문서파일을 열람하게 만듬

-- 대응 : 걍 보지ㅁ마

- 딴거도 많은데 딱히... 특별한 공격은 아니라 생략

4) SPAM 대책 / 5) 악성 MAIL 및 웜 대책

- ※ SPAM의 유형

-- Incoming SPAM : 자신의 메일 서버를 이용해 전송

-- Relay SPAM : 중계 메일 서버를 이용해 전송

- 메일 서버 자체의 보안 및 보호

-- 하나의 서버에 메일 서버, 웹 서버 등을 같이 운영을 많이 하는데, 규모가 커지면 메일 서버를 따로 두는게 바람직함

-- 메일 서버를 따로두고, 리눅스나 윈도우즈의 취약점 제거에 힘쓰는게 좋음

- access DB의 활용

-- 위에 SPAM의 유형에서 Relay SPAM이라는게 있는데, 메일 서버를 Relay 서버(중계 서버)로 사용할 것이냐에 대한 정책임

-- /etc/mail/access 파일에 기술하면됨

-- 특정 호스트나 도메인에 대한 접근제어를 해서, 무조건 적인 허용은 피하는게 좋음

- SPAM Assassin

-- 메일의 헤더와 내용을 실시간으로 분석해 스팸메일여부를 판단

-- 판단 기준은 RBL(차단 리스트)를 참고해 몇 가지 룰에 매칭될 때마다 점수를 줘서, 기준 점수이상이면 스팸메일이됨

- Inflex

-- 메일 서버에, 로컬이나 외부로 나가는 이메일을 검사하여 Inbound, Outbound 정책을 세워 필터링 해주는 도구

-- 2004년 이후 업데이트가 안되고 있음

6) Mail 보안 기술

- 전자메일에서 필요로 하는 보안 기술

-- 기밀성 / 메시지 인증 / 사용자 인증 / 송수신 부인방지 / 메시지 재전송 방지

- PGP(Pretty Good Privacy)

-- MIME 포멧에 암호화와 전자서명을 추가

-- 전자메일에 기밀성 / 메시지 무결성 / 사용자 인증/ 송신 부인방지를제공(수신 부인방지는 X !!!!!!!!!!!!!!!!!!!!)

-- 메시지의 암호화 : IDEA / RSA / 등

--- 메시지를 IDEA(대칭키 암호화)로 암호화

--- IDEA의 키를 수신자의 공개키로 암호화

--- 암호화된 메시지와 암호화한 IDEA키를 함께 보냄

-- 메시지 인증과 사용자 인증(디지털 인증) : RSA / MD5

--- 메시지의 해시값을 송신자의 공개키로 암호화해서 

-- 압축 : 전자서명 후, 메시지를 압축함(옵션적인 요소라 필수는 X)

-- 키관리 : RSA

-- 볼품 없게 정리했지만 알짜배기 : http://math88.com.ne.kr/crypto/text/chap10/10-4.htm

http://en.wikipedia.org/wiki/Pretty_Good_Privacy

- PEM(Privacy Enhanced Mail)

-- IETF에 의해 만들어진 인터넷 표준안으로 PGP보다 보안 능력이 뛰어난 편

-- 전송하기 전 자동으로 암호화하여 전동 도중 스니핑당해도 내용은 확인 불가능한 방식(PGP도 그러한데???)

-- 중앙집중식 키 인증 방식으로 널리 사용되기에 어려움

- S/MIME(Secure/MIME)

-- Application Layer에서 보안을 제공하는 대표적인 프로토콜

-- MIME 객체에 암호화와 전자서명을 기능을 추가함

-- PKI 인증서를 사용(인증기관에서 공개키를 보증하는 인증서 발급받아야한다는 의미)

-- S/MIME v2, S/MIME v3의 비교는 생략

- PGP, PEM, PGP/MIME, S/MIME의 비교도 생략

(3) Web 보안

1) WEB 개념

- HTTP 프로토콜을 이용하는 정보 공유 시스템?

- 걍 생략

2) WEB 서비스 운영

- Linux Apache Web Server

-- 설치 방식

--- DSO(Dynamic Share Object) : 동적 모듈 적재 방식으로 Apache 설치 이후에 필요한 모듈 추가 설치

--- Static : Apache 설치할 때, 모든 모듈 설치

-- 주요 환경 설정 파일 경로 : /etc/httpd/conf/

--- 특히 /etc/httpd.conf에서 Web Server에 대한 설정 다 함

- Windows IIS Web Server

3) WEB 로그 보안

- Web Server의 로그는 대표적으로 access_log와 error_log로 나눠짐

- access_log : Web Service하면서 접속한 로그에 대한 내용

- error_log : Web Server의 요청 처리과정에서 발생하는 각종 에러에 대한 기록

-- 위험도에 따라 8가지로 분류

-- Emerg > Alert > Crit > Error > Warn > Notice > Info > Debug

-- 기본값은 Warn이며, Warn이상의 에러가 로그에 남음

4) WEB 서비스공격 유형

- OWASP TOP 10 2013

-- A1 Injection

-- A2 인증 및 세션 관리 취약점

-- A3 XSS

-- A4 취약한 직접 객체 참조

-- A5 보안 설정 오류

-- A6 민감한 데이터노출

-- A7 기능 수준의 접근통제 누락

-- A8 CSRF(크로스 사이트 요청 변조)

-- A9 알려진 취약점 있는 컴포넌트 사용

-- A10 검증되지 않은 리다이렉트 및 포워드

- Directory Listing

-- 웹 서버 설정만 해주면 대응이되(Apache는 httpd.conf / IIS는 걍 설정)

- SQL Inejction

-- 공격에 사용될수 있는 문자나 패턴을, 웹 방화벽이나 Secure Coding을 통해 필터링

-- 자세한 오류 메시지를 보내주지 않음으로 DB정보를 흘리지 않기

- XSS(Cross Site Scripting)

-- 공격자가 작성한 악성 CSS(Client Side Script)를 일반사용자가 읽음으로써 실행되게 하는 공격

-- 서버를 공격하는게 아니라, 서버를 경유해 클라이언트를 공격하는 것

-- 사용자로부터 입력된 데이터를 철저히 검증함( '<', '>' 이런걸 바꿔) 으로써 검증

- CSRF(Cross Site Request Forgery ; 크로스 사이트 요청 변조)

-- XSS와 공격과정은 동일하지만, 공격 타겟이 서버인게 다름

-- 웹 사이트에서 제공하는 모든 기능을 대상으로, 신뢰된 사용자의 권한으로 요청하도록 하는 공격

-- XSS 취약점을 없도록해야함 / 중요한 기능은 재인증을 요구하는게 좋음

5) WEB 보안 개발

- Secure Coding : 개발 단계에서 보안을 고려하는 것 / [정보시스템 구축/운영 지침]으로 법제화 되어있음

6) WEB 방화벽

- WebKnight : Windows IIS Web Server용 Web 방화벽

- mod_security : Apache 보안 모듈로써, 침입탐지 및 차단 기능을 가짐

(4) DNS 보안

1) DNS 개념

- DNS(Domain Name Service)

- 계층구조를 가지는 분산 데이터베이스

-- 각 영역을 구분해 주는 도메인 이름을 관리하는 DNS Server들이 모여서 하나가 됨

- FQDN(Fully Qualified Domain Name) : DNS에서 사용되는 이름 표기 법

-- FQDN : www.nvaer.com

2) DNS 서비스 운영

- DNS 요청

-- Recursive Query : 로컬 DNS 서버에 이름 분석 결과만 달라고 요청

-- Iterative Quer

--- Query에서 요구하는 IP주소가 있으면, 질의한 호스트에게 결과를 반환

--- 없으면, 해당 도메인을 관리하는 DNS Server에게 같은 Query를 보냄

- DNS Zone

-- Zone은 DNS Server가 관리하는 Domain에 대한 정보가 저장되어 있는 DNS Database

-- 정방향 조회 영역 : FQDN으로 IP주소 알아올 때

-- 역방향 조회 영역 : IP주소로 FQDN알아올 때

- Zone의 종류

-- 주 영역 : 해당 DNS가 직접 관리하며 모든 권한을 가지고 있는 영역

-- 보조 영역 : 다른 DNS Server의 주 영역을 읽기 전용 데이터로 복사 해온것

--- 복사해 오는 행위를 Zone Transfer라고 함

-- 스텁 영역 : 다른 DNS Server의 정보가 있는 영역(해당 영역에 대한 권한은 없음)

- Resource Record Type(RR) : 각 Zone은 Resource Record Type으로 정의된 데이터를 가짐

-- SOA(Start Of Authority) : 주 DNS Server 와 Zone에 대한 정보

-- A(Host Address) : IPv4 주소

-- AAAA : IPv6 주소

-- CNAME : 별칭으로써 IP 하나에 여러 개의 별칭을 부여하기 위해 사용

-- MX(Mail eXchanger) : 메일 시스템에 대한 정보

-- PTR(Pointer) : 역방향 조회 영역에서 사용됨(A 레코드의 반대)

- DNS Server Caching

-- 다른 DNS Server로 부터 알아 온 정보는, 버리지 않고 DNS Server Cache에 임시로 저장

-- SOA Record의 TTL에서 지정한 기간 만큼

3) DNS 보안 취약성

- DNS Spoofing

-- 공격자가 호스트의 Query를 스니핑하고, DNS Server보다 먼저 조작된 IP주소가 담긴 응답을 보냄

-- DNS는 Query에 대한 인증을 수행하지 않기에, 피해자는 조작된 IP주소로 접속하게 됨(UDP를 사용함)

- DNS Cache Poisoning

-- DNS Server에 조작된 응답을 전송하는 것으로, 조작된 정보를 DNS Server가 Cache에 저장하게 됨

-- DNS Query시 부여되는 Transaction ID와 출발지/목적지 포트가 예상하기 쉬운 값을 사용하게 되면 공격이 가능

-- 강력한 난수 생성기 써도, 공격시간을 지연시킬 뿐

4) DNSSEC 기술

- DNSSEC(DNS Security Extentions) : 기존의 DNS를 대체하는게 아니라, DNS에 공개키 암호화 방식의 전자서명을 추가 부여하는 역할

- DNS 프로토콜 자체가 데이터의 위조 변조에 취약함

- DNSSEC으로 인해, DNS Data 원본을 가지고 있는 DNS Server는, 각 DNS Data에 대한 서명데이터가 추가됨

-- IPv4인 경우, A 레코드에 대한 전자서명으로 RRSIG 레코드가 생성되 함꼐 설정

- DNSSEC으로 인해, DNS Query의 응답으로 A 레코드와 함께 RRSIG 레코드도 함께 응답됨

- ※ 피싱(Phishing), 파밍(Pharming), 스미싱(Smishing)

-- 피싱(Phishing) : 실제 도메인과 비슷한 가짜 도메인 명을 사용해 공격

-- 파밍(Pharming) : DNS Server나 사용자 컴퓨터의 DNS Cache를 변조해서 공격

--- DNSSEC으로 예방가능한건 파밍

-- 스미싱(Smishing) : 문자메시지를 이용하는 공격

(5) DB 보안

※ DB보안은 크게 DB 데이터 보안과 DB 관리자 권한 보안으로 나뉨

※ 세세하게 외울게 아니라 이런게 있다고만 알고있어도 될듯(워낙 DB 보안이란게 DBMS에 따라서도 다르고 넓어서 다루기 힘들듯)

1) DB 데이터보안 / 2) DB 관리자 권한 보안

- DB 보안 유형

-- 물리적 보호 : 말 그대로 물리적인 위험으로부터 DB를 보호하는 것

-- 권한 보호 : 권한을 가진 사용자만이 특정 접근 모드로 DB에 접근할 수 있도록

-- 운영 보호 : DB 무결성에 대한 사용자 실수의 영향 최소화하거나 제거

- DB 보안 요구 사항

-- 부적절한 접근 방지 : 인가된 사용자에게만 접근이 허락 / 모든 접근 요청은 DBMS가 검사

-- 추론 방지 : 기밀이 아닌 데이터로부터 기밀 정보를 얻어내는 가능성을 막는 것

-- 데이터 무결성 : 의도치 않은 데이터 변경이나 삭제, 시스템 오류, 고장으로 부터 DB를 보호하는 것

-- 감사 기능 : DB에 대한 모든 접근에 대해 감사 기록으 생성되어야 함

-- 사용자 인증 : 별도의 엄격한 사용자 인증 방식이 필요

-- 다단계 보호 : 데이터를 등급으로 분류함을 통해 기밀성과 무결성을 보장

- DB 관리자 보안

-- DBA들은 보다 더 안전한 인증 과정을 받는게 안전

--- 운영 시스템에 의한 인증 / 네트워크 인증 서비스(커버로스 등)에 의한 인증

3) DBMS 운영 보안

- DBMS 보안 기능

-- 접근 제어(Access Control) : 로그인 과정을 통제하기 위해 ID/PW를 관리함

-- 보안 및 권한관리 : 특정 사용자와 그룹이 지정된 DB 영역만 접근하게 통제

- DB 보안 통제 : 접근제어, 추론통제, 흐름통제를 통해 인가된 사용자에게 암호화된 DB를 가용하게 하여 제공하는 것

-- 접근제어 : 인가된 사용자에게만 허가된 범위 내에서 접근을 허용하는 것

--- 접근 제어 정책과 규칙 집합 : 접근 제어를 어떻게 할껀지 정의

--- 접근 제어 메카니즘 : 정의된 내용으로, 접근 요청에 대해서 수락할껀지 거부할 껀지 판단

-- 추론통제 : 일반적인 데이터를 이용해 비밀정보나 민감한 정보를 획득하는 걸 제어

--- 예를 들어, 레코드 삽입 시 동일한 키를 가진 레코드가 있으면 에러가 나는걸 통해서 키의 값을 추론가능

--- 데이터의 암호화 등을 통해 해결해야 함(컬럼단위로 암호화)

-- 흐름통제 : 접근 가능한 객체들 간의 정보의 흐름을 조정

--- 예를 들어 보안등급이 높은 객체에서 낮은 객체로의 정보흐름을 제어

- DBMS마다 제공하는 보안기능이 다 다르기에 나머진 생략

4) DB 보안 개발

- Secure Coding이 의무화 되면서 개발 초기부터 보안을 고려한 개발을 해야 함

- DB 어플리케이의 개발(Web을 통한 SQL Injection 공격 방지에 대해서)

-- 원시 ODBC 에러를 띄우지 않음(물론 개발 과정에서는 쓰는게 편하겠지?)

-- DB 어플리케이션에 최소한의 권한만 줌

-- DB 내장 프로시저를 사용

-- 테이블 이름 / 칼럼 이름 / SQL 구조 등이 외부 HTML에 포함되어 나타나서는 X

2. 전자상거래 보안(5~6문제/20문제)

(1) 전자상거래 보안

1) 지불게이트웨이

- Payment Gateway(지불게이트웨이/지불중계기관)

-- 가맹점 및 다양한 금융시스템의 거래 사이에서, 중재자 역할

-- SET에서는 판매자가 요청한 고객의 카드정보로, 금융기관에 승인 및 결재를 요청하는 자로 쓰임

2) SET 프로토콜

- SET(Secure Electronic Transaction) Protocol

-- VISA와 Master Card에서 공동 개발한 신용카드 기반의 전자지불 프로토콜

-- 지불시스템에 대한 기술 표준

- SET Protocol의 구성 요소

-- 고객(Customer/Card Holder)

-- 상점(Merchant)

-- 지불게이트웨이(Payment Gateway)

-- 발급사(Issuer) : 고객의 계좌를 개설하고 카드를 발행하는 금융기관

-- 매입사(Acquirer) : 상점의 계좌가 개설된 금융기관

-- 인증기관(CA) : 전자적인 인증서를 발급하는 기관

- SET의 동작과정

-- 1) 상점과 지불게이트웨이, 금융기관은 인증기관으로부터 인증서를 발급받음

-- 2) 고객이 상점의 웹 사이트에서 물건을 고르고 결재를 위해 전자지갑 S/W를 다운받고 실행함

-- 3) 전자지갑에 자신의 신용카드를 등록하고 인증기관으로부터 인증서를 발급받고 결재를 함

-- 4) 전자지갑을 통해 결재정보가 상점으로 감

-- 5) 상점에서 지불게이트웨이로 결재정보를 넘겨줌(상점은 주문정보만 확인함 ; 이중서명)

-- 6) 지불게이트웨이는 결재정보를 금융기관에 전달

-- 7) 금융기관이 상점에 대금 결제를 함

-- 8) 상점은 고객에게 상품을 줌

-- 9) 금융기관이 고객에게 나중에 돈을 요구

-- ※ 아래 사진이랑 쫌 다르지만 전반적인 내용은 동일

http://wiki.cas.mcmaster.ca/index.php/File:Wikiimage1.jpeg

- SET에서의 암호화

-- 전자봉투(Digital Envelope) 

--- 전자서명에 대칭키 암호화를 넣어 기밀성 까지 얻는 방식

---- 전자서명 : 문서의 해시값을 송신자의 사설키로 암호화해서 문서, 공개키와 함께 보냄

----- 문서의 해시값을 암호화한걸 전자서명이라고도 하는듯

---- 전자서명을 대칭키로 암호화하고, 대칭키를 수신자의 공개키로 암호화해서 같이 보냄

----- 대칭키를 수신자의 공개키로 암호화한걸 전자봉투라고도 하는듯

--- 대칭키 암호화(DES) + 공개키 암호화(RSA) + 전자서명(RSA) + 해쉬 함수(SHA-1)

-- 이중 서명(Dual Signature)

--- ( (주문정보의 해쉬값) + (지불정보의 해쉬값) )의 해쉬값을 고객의 개인키로 암호화한 것

--- 어디서는 주문정보를 상점의 공개키로, 지불정보는 금융기관의 공개키로 암호화 한다고 하는데, 이중 서명에 대한 설명은 아닌듯??

- 특징

-- 현재 쓰이고 있진 않지만, 신용카드 지불 시스템의 기반이 됨

-- 너무 복잡하고 RSA, 알고리즘이 전체적인 속도를 저하 시킴

-- 고객이 전자지갑 S/W를 설치해야 함

-- 상점 또한 별도의 S/W를 설치해야 함

-- 고객(카드소지자)와 상인(상점)에 대한 인증

-- 지불 정보에 대한 비밀성 / 무결성 / 부인방지 기능

3) SSL 프로토콜

- SSL(Secure Socket Layer ; TCP 443)

-- 인터넷을 통한 메시지 전송을 안전하게 하기 위해, Netscape에서 개발한 암호화 통신 프로토콜

-- SSL 3.0에 대한 수정 보완을 거쳐 TLS(Transparent Layer Security)라는 이름으로 표준화

-- 암호화 통신을 위한 세션키 생성을 위해 인증서 기반의 공개키 알고리즘을 이용

-- OSI 7 Layer 기준으로, TCP 위에 위치(4 ~ 7 Layer)(실제로 지원 가능한 프로토콜은 별로 없음 ; HTTP, IMAP, NNTP 등)

--- 주로 HTTP와 같이 쓰이며, 이 경우에 SSL-enabled HTTP를 표시하기 위해 HTTPS라고 표기함

- SSL의 기능 : 사이트 인증(Site Authentication) / 데이터 기밀성 / 메시지 무결성 (※ 부인방지는 없어)

- SSL Handshake Protocol : 서버와 클라이언트 사이의 인증 / 암호화 알고리즘, 암호키, 무결성 알고리즘 등의 보안 협상

-- SSL Protocol에서 가장 복잡한 부분

http://blogs.msdn.com/b/kaushal/archive/2013/08/03/ssl-handshake-and-https-bindings-on-iis.aspx

- SSL 버전별 비교

-- SSL 2.0

--- MITM 공격에 매우 취약 / 취약한 MAC / 수출용은 40bit Key

--- 연결 초기에만 Handshake 가능

-- SSL 3.0

--- 해시값으로 메시지를 유지하며 MITM 방어 가능 / 수정한 MAC 사용 / 수출용은 128bit Key

--- 연결 이후에도 Handshake 가능

-- TLS 1.0은 SSL 3.1과 같음

4) OTP(One Time Password)

- 무작위로 생성되는 난수의 일회용 패스워드를 이용하는 사용자 인증방식

- 원격 사용자 인증시 패스워드의 재사용 공격을 사전에 방어하기 위한 방법

- 일반 적으로 H/W 장치로 많이 사용

- OTP 생성 원리

-- 1) 연계 정보 생성 : 시간, 이벤트 정보 등의 난수를 이용해 연계 정보를 생성

--- 정보를 수집할 때마다, 다른 정보를 수집할 수 있어야 함

--- 특정한 조건에서 생성되는 연계 정보는 동일해야 함(인증서버와 동일한 값 얻기 위해서)

-- 2) 생성 알고리즘 : 연계 정보를 생성알고리즘을 통해 암호문을 생성함

--- 동일한 연계 정보로 부터 동일한 암호문 생성해야 함

-- 3) 추출 알고리즘 : 암호문에서 일회용 패스워드를 추출함

--- 동일한 암호문으로부터 동일한 일회용 패스워드 추출해야 함

--- 정적 추출 알고리즘 / 동적 추출 알고리즘

- OTP 구현 방식에 따른 분류

-- 동기화 방식

--- OTP 토큰과 인증 서버 간의 미리 공유된 비밀정보와 동기화 정보에 의해 OTP 생성

--- 반드시 OTP 토큰과 인증 서버 간의 동기화가 이루어져 있어야 됨

--- 비동기화 방식에 비해 호환성이 전반적으로 높음(호환성이란 기존의 ID/PW 어플리케이션과의 호환이 잘되느냐에 대한 것)

--- 시간 동기화 방식

---- 시간을 이용해 OTP를 생성 / 특정 시간 간격으로 OTP를 생성함

--- 사건 동기화 방식(계수기 방식)

--- 시간 정보 대신 카운터를 이용해 OTP를 생성 / OTP 토큰과 인증 서버간의 카운터 값이 동기화 되어야 함

--- OTP 값을 생성한 후, 다음번 OTP 생성 요청까지 재생성이 없기에 사용자에게는 편리함

---- 실수로, 여러번 OTP값을 생성시키고나면 다시 동기화를 시켜야한다는 단점

--- 조합 방식

---- 시간 동기화 방식과 사건 동기화 방식을 조합하여 구성항 방식

---- 시간 동기화 중심의 조합 방식

----- 특정 시간간격으로 OTP가 생성되며, 같은 시간 간격내에 재시도시에 카운트 값을 증가시켜 OTP를 변경되도록 하는 방식

----- 시간 동기화 방식과는 다르게 특정 시간 간격 이내에도 계속 다른 OTP를 생성 가능

---- 사건 동기화 중심의 조합 방식

----- 특정 시간에 발생한 카운터 값을 기준으로 OTP가 생성

----- 사용자가 생성 요청을 할 때마다 매번 OTP가 변경

-- 비동기화 방식

--- 질의 응답 방식을 사용 / 인증 서버가 제시한 질의 값에 대한 응답값을 전달하는 방식

--- 구조가  비교적 간단하고, OTP 토큰과 인증 서버 간의 동기화가 필요 없음

--- 사용자가 질의에 대한 응답값을 직접 입력해야 하므로 번거로움

--- 매번 다른 질의값을 생성하는건 인증 서버에게 부담이 될 수 있음

(2) 전자상거래 프로토콜

1) 전자지불 방식별 특징

- 전자 지불 시스템

-- 전자지갑, 신용카드, 전자화폐, 인터넷 뱅킹 등을 이용해 전자상거래에서 발생하는구매 대금을 안전하고 효과적으로 지불, 결재하는 시스템

- 전자화폐(Electronic Cash) 시스템

-- 독립적인 신용구조를 가지고 현금과 유사한 개념의 전자적 지불 수단(실제 화폐를 대치할 수 있음)

-- IC카드형-Mondex, E-Cash, Milicent, Net Cash, Proton 등

-- 사용자의 프라이버시를 보호 / 기밀정보의 노출 위험성의 제거

-- 몇 가지 이론적인 문제좀도 남아있고, 전자화폐 시스템을 지원할 수 있는 H/W기술이 부족

- 지불브로커(Payment Broker) 시스템

-- 독립적인 신용구조 없이 신용카드나 은행계좌를 이용한 전자적 지불 수단

-- 미리 신용카드나 은행계좌 정보등을 지불브로커에 등록하고, 거래가 성립될 때 지불브로커를 통해 대신 지불을 처리

-- SET, Cyber Cash, First Virtual 등

-- 현실적인 전자지불 시스템이지만, 사용자의 거래 추적 가능성으로 프라버시 침해의 우려와 기밀정보의 노출 위험성이 있음

2) 전자지불/화폐 프로토콜

- 전자 화폐 : 은행의 전자서명을 수행한 화폐가치를 가지는 디지털 데이터

-- 독립적인 신용 구조를 가지며,거래 시 제3기관으로 부터 거래 승인이 없음

- 전자 화폐의 분류

-- 지불 시점

--- 후불형 : 거래가 이루어지고 난 후, 그 시점에 은행 계좌로 부터 인출되는 방식

--- 선불형 : 거래가 이루어지기 전에, 미리 은행 계좌에서 인출해 거래가 일어나면 지불

-- 거래 방식

--- IC카드형 : IC카드에 화폐가치를 저장함 / Mondex, Visa Cash, PC pay

---- 기술개발과 이용이 활발한 유럽에서 활성화

--- 네트워크형 : S/W전자지갑을 다운로드 받아서 사용하는 방법(네트워크를 이용해 화폐를 주고 받음) / ECash, NetCash, PayWord

---- 컴퓨터의 높은 보급률과 통신망이 잘 발달한 미국에서 활성화

-- 유통 형태

--- 폐쇄형 : 이용자가 상점에서 이용 후, 즉시 발행기관으로 돌아가는 형태 / 대부분의 전자화폐

--- 개방형 : 화폐가치가 이용자로 부터 다른 이용자로 유통되는 형태 / 대표적으로 Mondex

- 전자 화폐의 종류

-- Mondex : IC카드형 전자화폐 / Off-Line 시스템 / 현금 지불의 장점과 카드 지불의 편리함을 결합

--- 5개국 화폐를 동시에 저장하며 거래 내역의 기록이 가능

--- 은행을 거치지 않고 카드와 개인 간의 화폐 교환이 가능

-- Visa Cash : Visa에서 개발한 선불카드 개념의 화폐

-- PC pay : 스마트 카트와 카드리더기로 구성된 전자 화폐

-- Millicent : 브로커, 상점, 고객으로 구성

--- 브로커는 상점과 고객의 계정의 관리하며 실제로 돈을 취급함

--- 상점은 고객으로부터 스크립을 받고 정보나 서비스를 제공하고, 거스름 스크립을 발행

--- 고객은 스크립을 구매해서, 스크립으로 상점에서 거래를 함

--- ※ 스크립이 화폐 가치를 말하는 것 같음

-- Bitcoin : 통화를 발행하고 관리하는 중앙 기관이 없는 대신, P2P 기반 분산 데이터베이스에 의해 거래가 이루어짐

--- 공개키 암호 방식을 사용함

--- 익명성과 공개성을 지니며, 화폐가 컴퓨터에 파일 형태로 보관된다는 취약점을 가짐

3) 전자입찰 프로토콜

- 전자입찰 : 말 그대로 입찰을 네트워크를 통해 하겠다라는 개념

-- 전자입찰 시스템 / 입찰공고자 / 입찰자로 구성

- 전자입찰의 문제점 : 네트워크를 이용하기에 정보의 유출과 누락 변조 등으로 인해 생김

-- 네트워크상에 메시지 유출 : 입찰자와 입찰공고자의 정보가 유출될 수 있음 / 암호화하거나 도청에 대응

-- 입찰자와 서버 사이의 공모

-- 입찰자와 입찰공고자간의 공모

-- 입찰자간의 공모

-- 서버의 독단 : 서버가 특정 입찰자를 위해 나머지 입찰자의 정보를 누락하거나 변조할 가능성 / 서버의 모든 정보가 투명해야됨

- 전자입찰 시스템을 구축하는데 있어서 해결해야할 것(위의 문제점을 해결하는 데 초첨 / 하나라도 해결못하면 안전성 보장X)

-- 독립성 : 입찰자와 입찰공고자로 부터 독립해야 함(공모 등을 막기 위해 ; 삼권 분립??ㅋ)

-- 비밀성 : 네트워크 상의 각 구성 요소들의 정보는 누출되면 X

-- 무결성 : 누락 및 변조여부를 막음

-- 공평성 : 입찰이 수행될 때, 모든 정보가 공개되어야 함

-- 안정성 : 각 구성 요소들의 공모와 서버의 독단 등이 일어나서는 X

- 전자입찰 프로토콜 방식(일단 생략 정보가 검색도 안되고ㅋ)

-- LKR 방식 : 안전한 전송로를 구축함으로써 도청과 변조를 방지하고, 입찰자의 전자서명으로 무결성과 부인방지

-- PL 방식 : ??

4) 전자투표 프로토콜

- 선거인이 투표소에 직접안가고 온라인 시스템으로 투표하는 방식

- 요구사항

-- 정확성(Accuracy)

-- 비밀성(Privacy) : 비밀투표

-- 위조 불가능성(Unforgeability)

-- 단일성(Singularity) : 단지 한 번의 투표권만 행사

-- 합법성(Eligibility) : 합법적인 절차를 통해 투표권을 얻은 사람만 투표에 참여 가능

-- 공정성(Fairness) : 투표 진행과정에서, 다른 사람의 투표권 행사에 영향 끼치면 X / 중간 투표결과 같은거 비공개
-- 확인성(Verifiability) : 투표자가 올바르게 투표했는지 확인가능해야함

-- 투표권 매매방지(Untradability) : 투표권을 타인에게 매매할 수 없음

-- 완전성(Completeness) : 투표자들이나 집계자의 부정으로, 투표 시스템의 모든 투표 진행이 정지되거나 불완전한 결과 초래하면 X

- 전자투표 방식의 분류

-- PSEV(Poll SIte E-Voting)

--- 지정된 투표소에서 전자 투표를 하는 방식 / 기기를 선거인단이 관리하기에 안정성이 높고 국민투표 활용 가능성이 큼

-- 키오스크(Kiosk) 방식

--- 군중이 밀집한 지역에 키오스크 투표기기가 설치해서 유권자가 투표를 할 수 있는 무인 투표시스템

--- 편리성과 효율성만 만족시키지, 공공망을 통해 집계되기에 악의적인 공격의 가능성이 큼

-- REV(Remote E-Voting)

--- 인터넷 투표를 하는 방식으로 다양한 기술 수단을 통해 원겨으로 자유롭게 투표하는 방식

--- 가장 이상적이지만, 비밀투표를 충족하기 어렵고, 투표권의 매매 위험이 존재함

- 전자투표의 암호화 기법

-- 공개키/개인키를 이용한 암호화

-- 전자서명

-- 은닉서명 : 투표자와 투표결과 쌍을 이을 수 없도록 함

(3) 무선 플랫폼에서의 전자상거래 보안

1) 무선플랫폼에서의 전자상거래 보안

- WPKI(Wireless Public Key Infrastructure)

-- WAP(Wireless Application Protocol)에서 서버와 클라이언트 간의 인증을 위해 사용되는 무선 환경에서의 공개키 기반 구조

-- 인증기관 / 등록기관 / Client 시스템 / PKI 디렉토리

- 신용카드기반 전자지불 시스템

-- 보안프로토콜 : End-To-End  간의 발생하는 트랜젝션의 안정성

-- S-HTTP/ SSL / TSL

-- 지불프로토콜 : 전자상거래의 모든 구성원들 간의 트랜젝션 정의를 위한 별도의 프로토콜

-- SET / InstaBuy(cyber Cash)

- 전자화폐기반 전자지불 시스템

-- 네트워크형 프로토콜 : 인터넷 같은 네트워크 환경에서 사용자의 PC나 서버의 계좌 등에 전자화폐를 저장하고 사용

--- Milicent(DEC) / NetBill(CMU) / Payword(MIT) 등

-- 가치저장형 프로토콜 : 스카트카드 내에 전자화폐를 저장해서 사용(실생활의 화폐 대용이 목적)

--- Mondex(master Card) / Visa Cash(Visa International) / Proton(Banksys) / K-cash(국내)

- 전자수표 기반 전자지불 시스템

-- 실제 수표와 유사한 형태로, 전자서명 같은 암호화를 통해 배서(어음이나 증권의 양도) 등의 효과를 제공

-- Echeck(FSTC) / NetCheque(USC) / Paynow(CyberCash)

(4) 전자상거래 응용보안

1) e-biz를 위한 ebXML 보안

- ebXML(e-business using XML) : 비즈니스 데이터를 안전하게 교환하는데 XML을 사용한 개방형 표준

- 구성요소

-- 비즈니스 프로세스

--- 다양한 비즈니스 거래절차에 대한 내용을 표준화된 방법으로 모델링해서, 시스템이 자동으로 처리할 수있도록 표현하는 방법을 정의

-- 핵심 컴포넌트

--- 비즈니스에서 교환되는 전자문서를 이루는 항목을 미리 잘 정의해 재사용가능하도록 표준화 작업

-- 등록저장소

--- 거래 상대자들에 의해 제출된 정보를 저장하는 안전한 저장소(제일 중요)

-- 거래 당사자

--- 각종 정보 및 협업을 위한 프로파일을 통일된 규칙을 통해

--- CPP(협업 규약프로파일;거래당사자정보), CPA(협업규악약정서; 거래 당사자간의 협약)를 표현

-- 전송, 교환 및 패키징

--- ebXML 메시지 서비스를 제공하여, 메시지를 상호 운영성과 보안을 유지하면서 어떻게 전송할 것인가에 대한 표준

- ebXML의 개요

http://www.ibm.com/developerworks/library/x-ebxml/

- ebXML 보안 : XML에서 사용되는 보안의 대부분이 ebXML에서 사용됨

-- XML 전자서명 / XML 암호화 / XKMS / SAML / XACML 등

3. 기타 어플리케이션 보안(잘안나올껄?)

(1) 응용프로그램 보안개발방법

1) 취약점 및 버그방지 개발 방법

- 소프트웨어 개발생명주기(SDLC ; Software Development Life Cycle)

-- 소프트웨어를 개발하기 위한 계획부터 구현 및 폐기 까지 전과정을 단계적으로 분류하여 정의한 것

-- 한정된 예산과 자원으로 최선의 개발 환경과 방법을 찾아 높은 품질의 소프트웨어를 만들기 위한 개발 프로세스

- SDLC 모형의 종류

-- 폭포수 모델 : 각 단계 별로 개발 완료 한 후, 다음 단계를 실행 / 개발의 유연성이 떨어짐(개발과정 중의 새로운 요구 반영힘듬)

-- 원형 모델 : 사용자의 요구분석을 위해, 소프트웨어 모델을 사전에 만듬

-- 나선형 모델 : 폭포수 모델의 장점 + 원형 모델의 장점 + 위험 분석

-- 점증적 모델 : 개발되어 운영 중인 시스템과 개발이 진행 중인 시스템이 공존

- 보안이 강화된 SDLC(Secure SDLC)

-- 반복적인 위험 평가 / 영향분석 및 보안 모델링 / 구성요소의 보안 평가 / Secure Coding

- 취약점 및 버그 방지 개발

-- SUID/EUID 보안 프로그래밍

-- 새로운 프로세스 생성 보안

-- BufferOverflow 방지

(2) 보안기술

1) SSO(Single Sign On)

- 통합인증(SSO) : 사용자가 한 번의 로그인 인증으로, 다양한 서비스에 재 인증 절차없이 접근할 수 있도록 하는 통합 솔루션

-- 로그인 서버가 사용자 정보 저장소와 연동해 로그인 검증을 하고, 유효한 경우 토큰을 발급함

-- 사용자는 토큰을 기반으로한 인증 요청으로 다른 서비스를 사용가능함

--- 토큰을 받은 다른 서버들은 정책서버로 토큰 검증이라는 과정을 거치긴함

- SSO 보안 위협 : 사칭 위협 / 인증정보노출 / 인증정보 재사용 / 키관리 위협 / 세션관리 위협

- 장점 : 운영비용감소(한곳에 사용자정보 관리) / 보안성 강화 / 사용자 편의성 강화 / 중앙집중관리로 인해 효율적 관리

- 단점 : SSO 서버가 단일 실패지점 / SSO 서버가 침입당하면 모든 서버에 보안문제

- 커버로스(Kerberos) : SSO 인증방식

-- 대칭키 암호화 기법에 바탕을둔 티켓기반 인증 프로토콜

-- 유닉스와 윈도우 서버에서 기본으로 사용하는 인증기법

-- 인증과정

--- 1) 클라이언트는 KDC(Key Distribution Center)에 접속해 함

--- 2) KDC의 AS(Authentication Server)로 부터 인증을 받고 TGT(Ticket Granting Ticket)을 받음

--- 3) 클라이언트는 TGT를 이용해 KDC의 TGS(Ticket Granting Server)로 부터 세션키와, 세션키로 암호화된 서비스 티켓 받음

--- 4) 클라이언트는 접속을 원하는 서버에, 서비스 티켓을 이용해 인증 받음

--- 5) 티켓의 타임스탬프는 이용시간을 제한하는 용도로 사용하며 이는 제3자가 티켓을 복사해 사용하는 것을 방지함

http://www.zeroshell.org/kerberos/Kerberos-operation/

-- 장점 : 데이터의 기밀성(대칭키)과 무결성 / 재사용예방 / 이기종 간의 자유로운 서비스 인증

-- 단점 : 세션키가 단말에 임시로 저장되, 공격자에 의해 탈취 당할 수 있음 / 타임스탬프가 시간동기화가 필요 / KDC가 단일 실패지점

2) HSM(Hardware Security Module)

- 보안토큰으로써 암호화와 관련된 일련의 과정들을 빠르게 수행하고 생성 및 안전안 보관이 가능한 하드웨어 장치

-- 내부적으로 암호화, 복호화, 전자서명을 위한 프로세스 및 연산장치가 내장

- HSM의 분류

-- 인터페이스에 따른 분류 : 접촉식 / 비접촉식(유선, 안테나가 필요)

-- 매체에 따른 분류 : 스마트카트(따로 리더기가 필요) / USB방식(스마트카드칩을 내장)

- 특징

-- 인증서 보관을 PC가 아닌 HSM에 저장하기에 유출의 위험이 낮음

-- 전자서명을 PC가 아닌 HSM 내부에서 생성

-- HSM 비밀번호 설정과과 초기화, 비밀번호 오류 입력 횟수를 제한

-- HSM 구동 프로그램의 무결성 및 구현 적합성을 스스로 확인

3) DRM(Digital Right Management)

- 전자매체의 불법적이거나 비인가된 사용을 제한할 수 있는 정보보호기술

- DRM 구성요소

-- 콘텐츠(Content) : 암호화된 상태로 유통되는 데이터

-- 사용자(User) : 권한과 조건에 따라 컨텐츠를 사용하는 주체

-- 권한(Permission) : 콘텐츠별로 부여된 이용권리 범위를 명시하여, 사용자가 콘텐츠를 이용하는데 따르는사용 범위를 제한

-- 조건(Condition) : 권한이 수행되기 위한 요구 조건 및 제한 요소

- 자세한 DRM 세부 기술 내용은 다루지 않을래(구성요소정도만 알아도 될듯)

 

출처 : http://kit2013.tistory.com/209

해당 블로그에서 보고 공부했는데 정리가 잘되어 있는거 같아 퍼왔습니다.