시큐어 코딩 가이드 및 보안점검 도구를 통한 보안 취약점 점검 방법

목차는 아래의 순서에 따라 진행합니다.

 

1. 개요

 

2. 설계 예시

2-1 게시판 목록

2-2 게시물 조회

2-3 게시물 등록

2-4 게시물 수정

 

3. 보안 점검 도구

3-1 Burp Suite

3-2 Fiddler

3-3 Wireshark

 

-----------------------------------------------------------------------------

 

개요

 

OWASP에서 발표한 취약점 Top 10은 아래와 같습니다.

 

A1. 인젝션

A2. 취약한 인증

A3. 민감한 데이터 노출

A4. XML 외부 개체(XXE)

A5. 취약한 접근 통제

A6. 잘못된 보안 구성

A7. 크로스 사이트 스크립팅

A8. 안전하지 않은 역직렬화

A9. 알려진 취약점이 있는 구성요소 사용

A10. 불충분한 로깅 및 모니터링

 

취약한 인증, 취약한 접근 통제는 Top10 중에서도 상위권에 랭크되어 있으며. 주기적으로 발표하는 OWASP Top 10에서 항상 빠지지 않을 정도로 중요한 취약점 내용입니다.

 

  

한국인터넷진흥원에서 있는 시큐어 코딩 가이드에서도 관련된 내용을 확인할 수 있습니다.

 

쿠키 또는 Hidden 필드등의 외부입력 값이 보안기능을 수행하는 중요 파라미터로 사용되는 경우 프록시 서버에서 파라미터를 조작하여 부적절한 인가가 발생할 수 있다.

 

중요기능이나 리소스를 요청하는 경우 HTML 화면에서 기능을 안보이게 설정하여도 URL을 통해 접근할 수 있으므로 인증을 거치지 않고 처리할 경우 공격자에게 노출될 수 있다.

 

 

 

위의 코드는 인증대상 및 방식(SR2-1)에 대한 안전하지 않은 코드와 안전한 코드의 예시이다.

기능을 수행하기전에 로그인 세션 정보의 유무, 권한 체크등의 간단한 프로세스이지만, 개발자들은 기능개발을 중점적으로 두는 경향이 있어 간과할 때가 많습니다.

  

2. 설계예시

2-1. 게시판 목록

게시판 목록을 구현할 때, 필요한 보안 사항의 시퀀스 다이어그램과 체크리스트이다.

Coreframe에는 OWASP ESAPI 탑재되어 있어 인젝션, XSS 등의 취약점들은 모두 필터링되게 설계되어있어 나머지의 보안항목에 대해서만 설계하면 된다.

  

게시판 목록 로그인 여부 검증, 로그인 계정의 접근 권한 검증

접근 권한 체크가 존재하지 않아 URL을 통해 직접 접근할 경우 게시판에 접근이 가능하다.

jspx(컨트롤러단) 또는 jsp 페이지에서 선택하여 접근 권한 체크를 해주면 된다.

 

2-2 게시물 조회

게시물 조회 시엔 게시판의 유형에 따라 DB조회후에 로그인 세션 정보와 output의 파라미터 값이 적절한 값인지 체크해줘야 한다. 예를들어, 인사 정보와 같은 개인 정보를 조회 시에 파라미터 변조를 통해 다른 사용자의 정보를 조회할 수 있으므로 세션 정보와 output을 비교하도록 한다.

 

게시물 조회 로그인 여부 검증, 로그인 계정의 접근 권한 검증

접근 권한 체크가 존재하지 않아 URL을 통해 직접 접근할 경우 게시물에 접근이 가능하다.

jspx(컨트롤러단) 또는 jsp 페이지에서 선택하여 접근 권한 체크를 해주면 된다.

 

게시물 조회 output이 정상적인지 검증

DB에서 데이터 조회 후에 output에 대한 검증 없이 파라미터를 set하기 때문에 파라미터 변조 시 다른 사용자의 정보에 접근할 수 있다.

로그인 체크와 세션정보와 output의 비교 체크를 추가하여 타 사용자의 정보에 접근을 막는다.

 

2-3. 게시물 등록

 

 

게시물 등록 시엔 등록 페이지 접근 시, 등록 버튼 클릭 시에 접근 권한 체크를 해줘야 한다.

 

게시물 등록 로그인 여부 검증, 로그인 계정의 접근 권한 검증(페이지 이동)

게시물 등록 - 로그인 여부 검증, 로그인 계정의 접근 권한 검증(버튼 클릭)

ajax 전송방식은 POST를 해야함(GET방식으로 전송 시 URL에 데이터 노출)

에러 처리가 존재하지 않아 접근 권한이 없는 사용자가 등록을 시도해도 처리할 수가 없다.

 

 

 

2-4. 게시물 수정

게시판 수정 페이지 접근 시 파라미터 변조를 통해 타 사용자의 게시물의 수정 페이지에 접근하여 정보를 확인하고 무단으로 수정을 할 수 있으므로 로그인 세션 정보와 output을 비교하여 검증해야 한다.

 

게시물 수정 로그인 여부 검증, 로그인 계정의 접근 권한 검증(페이지 이동)

DB조회 후 output에 대한 검증이 존재하지 않아 파라미터(게시물 번호) 변조를 통해 타 사용자의 게시물에 접근 가능하다.

 게시물 수정 로그인 여부 검증, 로그인 계정의 접근 권한 검증(페이지 이동)

 

3. 보안 점검 도구

1. Burp Suite

웹 동작 시 클라이언트와 서버 사이에 프록시 서버를 구축하여 패킷을 프록시 서버를 거치게 하여 중간에서 패킷을 확인하거나 변조하여 서버에 패킷을 전달해주는 프록시 도구

 

사용법

2. Fiddler

웹 동작 시 클라이언트와 서버 사이에 프록시 서버를 구축하여 패킷을 프록시 서버를 거치게 하여 중간에서 패킷을 확인하거나 변조하여 서버에 패킷을 전달해주는 프록시 도구

 

사용법

 

* 필터링

 

* 파라미터 변조

 

3. Wireshark

네트워크 트래픽을 캡쳐하여 패킷을 분석하여 모의해킹, 취약점 분석등의 쓰이는 네트워크 분석 프로그램이다.

 

사용법

 

* No. : 패킷을 수집한 순서

* Time : 패킷을 수집한 시간

* Source : 패킷을 보낸 주소

* Destination : 패킷 도착 주소

* Protocol : 프로토콜 정보

* Length : 패킷의 길이

* Info : 패킷 정보

와이어 샤크를 통해 패킷을 캡처하게 되면 수많은 패킷들이 캡처되기 때문에 Statistics(통계)를 사용하여 요약된 정보를 통해 패킷을 분석해야 한다.

대표적으로 쓰이는 4가지 통계 자료를 살펴보도록 하겠습니다.

 

* Protocol Hierachy 프로토콜에 관련된 통계 자료를 확인할 수 있다.

 * Conversation 출발지 IP, 도착지 IP, 크기, 시간등 IP에 대한 정보를 확인할 수 있다.

 

* Packet Counter HTTP 상태 코드에 대한 통계 정보를 확인할 수 있다.

 

 * Requests Request에 응답한 페이지의 목록을 확인할 수 있다.

 

Statistics를 이용하여 대략적인 패킷의 분석이 끝났으면 필터링과 Stream을 통해 자세한 내용을 확인하면 된다.

 

* 필터링 필터링을 통해 원하는 패킷만을 추출하여 확인할 수 있다.

 

 * Stream- 패킷의 데이터를 조합하여 볼 수 있다(파일로 저장 가능)

 

 

감사합니다.

 

 

New Multi-Channel Dynamic CMS

웹 서비스 동작구조와 소켓 통신

안녕하세요.

이번 글은 웹 서비스 동작 구조와 소켓 통신을 알아보겠습니다.

 

목표

 

     Client - Server 구조

     Static Page & Dynamic Page 구분

     Server 구성 Web/Was 차이 이해

     Session & Timeout

     3-Way handshake 이해

     Apache Timeout

     WAS(Tomcat) Timeout

     Web - WAS - DB 연동

     WAS-DB 사이의 Timeout

     OS level Timeout

 


Client – Server 구조 1

Client가 Server에 요청을 하면 Server는 결과물을 Client에 응답하는데 이러한  구조를 Client - Server 구조라고 합니다.

단순화시키면 위와 같은 모습을 가집니다. 이때 요청과 응답은 클라이언트와 서버가 각각 소켓을 만들어서 주고받는데 소켓에 관해서는 아래쪽에서 알아보겠습니다.

Static Page & Dynamic Page

클라이언트가 서버에 페이지를 요청할 요청하는 인터넷 페이지에는 2가지 종류가 있습니다. Static Page와와 Dynamic Page인데인데 이름에서 있듯이 변하지 않는 페이지와 변하는 페이지입니다.

 

1.    Static Pages

             : 항상 동일한 페이지를 반환하며 image, html, css 등으로 구성된 정적인 페이지입니다.

1.    Dynamic Pages

             : 인자의 내용에 맞게 동적인 contents 반환합니다.따라서 접속할 때마다 페이지의 내용이 바뀝니다.

 

Web & WAS

서버도 Web Server와 WAS(Web Application Server)로 나누어지는데

Web Server  Static Page, WAS Dynamic Page 처리한다고 보면 됩니다.

 

1.    Web Server

      : Static Page 처리(정적인 컨텐츠 제공), 동적인 컨텐츠가 필요할 경우 해당 요청을 WAS 전달, WAS 처리한 결과를 클라이언트에게 전달

 

1.    WAS

      : Web Server + Web Container 로 구성. DB 조회나 다양한 로직 처리 동적인 컨텐츠를 제공

 

WAS Web Server + Web Container 로 이루어져 있으며 이때 Web Container 동적인 페이지를 처리합니다. WAS에도 Web Server 있기 때문에 Web Server 없이 WAS 존재하는 것도 가능합니다.

 

Web Server 와 WAS 분리

WAS 에는 Web Server 포함되어 있기 때문에 WAS 로만 서버를 구성해도 됩니다. 그러나 일반적으로 Web Server 와 WAS 분리하는 경우가 많은데 여기에는 여러 이유가 있습니다.

 

1.    서버 부하의 방지

      : WAS 정적, 동적 페이지 모두를 처리할 있다고 하지만 그만큼 WAS 부담이 많아지게 됩니다. 그래서 기능을 분리해서 서버의 부하를 줄이기 위해서 Web Server WAS 분리합니다.

 

1.    보안을 위하여

      : WAS에는 실제 Web Application 올라가기 때문에 외부와 직접 연결되면 중요한 파일이나 소스들이 노출될 있습니다. 그래서 이를 막기 위해서 Web Server WAS 앞단에 배치합니다.

 

1.    Web Server 여러개의 WAS 연결하기 위해

       : 규모가 서비스에서는 수많은 요청을 한군데가 아닌 여러 군데에서 처리하기 위해 동일한 Web Application 여러 띄웁니다. Web Server 두고 여러 WAS들을 Web Server 연결해서 Web Server 들어오는 수많은 요청을 WAS 적절하게 분배해줍니다.

 

1.    여러 Web Applications 서비스하기 위해

       : Java 서버, PHP 서버와 같이 서로 다른 서버를 하나의 Web Server 연결해서 서비스할 있습니다.

 

Client – Server 구조2

 

Web Server WAS 별도로 구성한다고 했을 위에서 단순화 시켰던 Server - Client 구조를 다시 그리면 위의 그림과 같은 구조라고 있습니다.

 

일반적으로 Web Server 는 Apache 많이 사용하며 WAS Tomcat 많이 사용합니다. Tomcat Apache Tomcat 이라고도 부르는데 Web Server 역할도 있기 때문에 Apache Tomcat 이라고 부르는 것을 있습니다.

이중화 Web Server WAS 위와 같이 구성되어 있으며 각각의 웹과 WAS 들이 이중화 되어 있습니다.

 

 Timeout

위에서 봤던 Server - Client 구조를 다시 보겠습니다.

 

Client 에서 Server 요청을 보내면 Web Server 요청이 갑니다. 그리고 해당 요청에 동적인 데이터가 필요하다면 요청을 다시 WAS 보냅니다. 그리고 WAS에서도 DB 접속을 해서 해당 데이터를 가지고 있습니다.

이렇게 클라이언트의 요청에 대해 한번의 요청이 아니라 여러 단계의 요청이 있을 있습니다.

 

그런데 통신 과정 중에 문제가 발생하면 요청과 응답이 제대로 이루어지지 않을 있습니다. 문제가 발생한 상황에서 응답을 계속해서 기다리기만 하면 무한정 대기해야 하는 상황이 생깁니다. 그래서 특정 시간이 지나도록 응답이 제대로 이루어 지지 않으면 클라이언트와 서버의 접속을 끊어야 하는데 요청을 기다리는 한계 시간을 Timeout 이라고 합니다.

 

그리고 요청과 응답에 여러 단계가 있기 때문에 Timeout 여러 종류가 있습니다.

 

 3-Way Handshake

 Client - Server 구조1 에서 서버와 클라이언트가 통신을 소켓을 이용한다고 했습니다. 서비스의 경우 TCP 소켓으로 연결을 하는데 TCP 소켓은 서버와 클라이언트의 연결을 확인하고 연결이 확인이 되었을 에서야 데이터를 전송합니다.

 

Client - Server 통신을 바로 페이지를 요청 하고 요청에 대한 응답을 받는게 아니라

1번과 2번의 단계를 통해서 Client - Server 의 통신이 가능한지 연결을 확인하고 연결이 확인 뒤에야 실제 데이터에 대한 요청인 3번과, 4번의 응답이 이루어집니다.

 

1,2번의 Client Server 연결을 확인하는 것을 3-Way HandShake 라고 합니다.

 

그림에서는 1번과 2번으로 요청과 응답의 2단계인 것으로 표현되어 있지만 실제로는 3단계 과정을 통해서 연결을 확인합니다.

 

사진과 같이 3단계 과정을 거쳐 Client Server 연결을 확인합니다.

 

     Syn : 연결을 요청하는 패킷

     Ack : 요청에 응답하는 패킷

 

1.    Client 서버에게 Syn 패킷을 보냅니다.

2.    Server 는 받은 Syn 패킷에 +1 하여 Ack 패킷으로 보냅니다. 그리고 서버도 Client에게 별도의 Syn 패킷을 보냅니다.

3.    Client Server에게서 Ack Syn 패킷을 정상적으로 받았다면 상태를 Established 변경하고 Server에게 받은 Syn 패킷에 +1 하여 다시 Server 에게 Ack 패킷으로 전송합니다. 그리고 Server Ack 받으면 Established 상태를 변경합니다.

 

  3단계의 과정을 통해서 연결이 확인 되면 그때부터 데이터가 전송됩니다. 그리고 과정이 끝이 나야 서버에 로그가 저장이 됩니다. 만약 3-Way handshake 제대로 이루어지지 않으면 서버의 로그에 기록이 남지 않은 채로 연결이 끊어집니다.

 

위의 2 단계 Server Client ack 다시 보낼 까지 대기를 하게 되는데 대기 시간을 Connection timeout 이라고 합니다.

  

SYN Flooding

3-Way handshake 의 취약점을 이용해서 서버를 공격하는 방법이 있는데 이를 SYN Flooding 이라고 합니다.  (SYN Flooding DOS 종류)

 

     SYN Floding : 3-Way handshake 2단계에서 Server Client에게 ack + syn 을 보내고 다시 Client 에게 ack 받을 때 까지 Server 대기를 해야 하는데 1단계 요청만 무수히 많이 보내서 Server 대기 중인 상태를 많이 만드는

 

이러한 공격을 막기 위해서는 여러가지 방법을 사용할 있지만 바로 위에서 봤던 Connection Timeout 시간을 조절하는 방법을 알아보겠습니다.

 

Apache Connection Timeout

 Apache Web Server 환경 설정에서 Connection Timeout 값을 설정할 있습니다.

Connection Timeout 이지만 Apache 환경설정에서는 그냥 Timeout 이라는 이름으로 되어 있습니다.

 

 

(설치경로)/httpd/conf/httpd.conf

 

해당 위치의 파일 열어서 수정하면 됩니다.

 

Timeout300

Apache Timeout 값의 기본값은 300() 설정되어 있습니다.

Client Server 상황에 맞게 값을 적절하게 조절해 줍니다. 해당 값이 너무 길다면 DDOS 공격에 취약해질 있으며 반대로 값이 너무 작으면 인터넷 속도가 느린 Client 아예 접속을 없게 됩니다.

 

 Apache Keepalive Timeout

3-Way handshake 통해서 Client Server 연결이 확인되고 나면 데이터의 요청과 전송이 이루어집니다. 그리고 전송이 끝나고 나면 Client Server 연결은 끊어지고 다음 요청 다시 3-Way handshake 해서 연결을 확인하고 데이터를 주고 받습니다.

 

그러나 요청 마다 연결을 확인하는 것은 비효율적이기 때문에 연속된 요청과 응답에 대해서 소켓을 재사용 있습니다. 이것을 Keepalive 라고 부릅니다.

 

 

KeepAlive On/Off ( 기본값 : ON)

KeepAlive Timeout 5(초)

MaxKeepAliveRequests 100

 

위의 Apache Timeout 동일한 파일에서 설정을 있습니다.

 

KeepAlive : On/Off 하여 설정 가능

KeepAlive Timeout : KeepAlive On 상태에 유효한 값이며 해당 시간() 동안 요청이 없으면 연결을 끊습니다.

MaxKeepAliveRequests : KeepAlive On 상태에서 유효한 , 최대 번의 요청까지 연결을 계속 사용할지 결정. 0 무제한

 

WAS Session Timeout (Tomcat)

 Apache 같이 Tomcat Timeout 있습니다.

 

Tomcat WebServer 역할도 같이 있기 때문에 앞선 Apache Timeout KeepAliveTimeout 있습니다. 그러나 Apache 연동하여 사용하면 Tomcat Apache 사용하지 않습니다.

 

 

Apache 에서는 Connection Timeout 그냥 Timeout 이라고 하였으나 Tomcat 에서는 Connection Timeout 으로 표기 합니다.

 

그리고 Web Server처럼 WAS 요청과 응답 시간을 설정하는 Session Timeout 이 있습니다.

 

Tomcat 기준으로 Session Timeout 설정에는 3가지 방법이 있으며 우선순위가 있습니다.(1>2>3)

 

1.    프로그램에 직접 코딩

 

<%

             session.setMaxInactiveInterval(int)

%>

 

1.    WEB/INF/web.xml 파일

 

<web-app>

             <session-config>

                           <session-timeout>15</session-timeout> //분

             <session-config>

</web-app>

 

1.    /conf/web.xml 파일

 

<session-config>

                           <session-timeout>30</session-timeout> //분

<session-config>

 

Web - WAS - DB 연동

 

 

Apache Tomcat 연동하여 사용하고 Tomcat  DB 연동해서 사용하려면 중간에 모듈이 필요합니다.

 

1번의 Apache - Tomcat 연동의 경우

1.    mod_jk

2.    mod_proxy

3.    modproxyajp

 

3가지 방법을 사용할 있으며

2번의 Tomcat Oracle DB 연동의 경우 JDBC OJDBC 라는 모듈을 사용합니다.

 

모듈을 통해서 연동을 하기 때문에 모듈과 다음 대상과의 통신에 대한 Timeout 있으나 모듈에 따라 설정이 다릅니다.

 

WAS & DBMS 통신과 Timeout

 

WAS DB 통신 사이에는 3가지 Timeout 있습니다.

타임아웃들은 계층구조를 가지고 있으며 상위 타임아웃은 하위 타임아웃에 의존성을 가지고 있습니다.

JDBC Driver Socket Timeout 정상으로 동작하지 않으면 Statement Timeout Transaction Timeout 정상으로 동작하지 않습니다.

 

그리고 JDBC Driver SocketTimeout OS SocketTimeout 설정에 영향을 받습는다. JDBC Driver SocketTimeout 설정하지 않아도 네트워크 장애 발생 이후 30분이 지나서 자동으로 복구되는 것은 OS SocketTimeout 설정 때문입니다.

 

 

1.    Transaction Timeout

             : 프레임워크나 어플리케이션 레벨에서 유효한 타임아웃, StatementTimeout x N(Statement 수행 ) + a(가비지 컬렉션 기타) 라고 합니다. 전체 Statement 수행 시간을 제한할 사용합니다.

( Statement 를 아주 많이 수행할 때의 시간제한이라고 생각하면 됩니다.)

 

1.    Statement Timeout

             : Statement 하나가 얼마나 오래 수행되어도 괜찮은지에 대한 한계 시간 입니다. Statement DB 쿼리를 보내는 객체입니다. java.sql.Statement.setQueryTimeout(int timeout) 메서드로 설정할 있습니다.

 

1.    JDBC Driver Socket Timeout

             JDBC Driver 소켓을 사용하여 DB 연결하는데 어플리케이션과 DB 사이의 Connection Timeout 처리는 DB에서 하지 않습니다. 따라서 소켓에 Timeout 설정해야 하는데 Socket Timeout JDBC Driver에서 설정할 있습니다.

 

Socket Timeout 2가지 방법이 있으며 드라이버별로 설정 방법이 다릅니다.

             3-1. Socket Connect Timeout

                           : Socket.connect(SocketAddress endpoint, int timeout) 로 설정

             3-2. Socket Read/Write Timeout

             :            Socket.setSoTimeout(int timeout) 로 설정

 

 

OS level socket timeout

위의 SocketTimeout이나 ConnectTimeout 설정하지 않으면 어플리케이션이 네트워크 장애를 감지할 없습니다. 그러나 OS level 에서도 SocketTimeout 시간을 설정할 있기 때문에 값을 통해서 네트워크 연결 끊김을 확인할 있습니다.

 

Linux Socket Timeout

Server 에는 주로 Linux 사용하기때문에 Linux Socket Timeout 설정에 대해 알아보겠습니다.

Linux Socket Timeout에는 3가지 파라미터가 있습니다.

 

1.    tcpkeepalivetime : 전송된 마지막 패킷과 첫번째 Keepalive 의 간격. keepalive 유지하는 시간을 의미하며 기본 7200초(2시간)으로 설정되어 있습니다.

 

/proc/sys/net/ipv4/tcp_keepalive_time 7200

 

 

1.    tcpkeepaliveprobes : tcpkeepalivetime 에 의해 보낸 keepalive 세그먼트를 보낼 횟수. 기본 설정 되어 있는 9회가 지나 가면 연결이 종료 됩니다.

 

/proc/sys/net/ipv4/tcp_keepalive_probes 9

 

 

1.    tcpkeepaliveintvl : keepalive 세그먼트를 보내고 다시 확인 하기 위한 시간. 처음 keepalive 를 보내고 미응답시 다음 keepalive 보낼 시간. 기본 75초로 설정되어 있습니다.

 

/procs/sys/net/ipv4/tcp_keepalive_intvl 75

 

 

서버에 기본 설정된 위의 내용을 종합해보면 Client - Server 구조에서 2시간 동안 데이터를 주고 받은 경우가 없으면 서버는 keepalive 세그먼트를 보내고, Client 미응답시 75 이후 keepalive 세그먼트를 보내고, 9 동안 미응답시 연결을 종료하게 됩니다.

 

 

정리

 

지금까지의 전체 흐름을 그려보면 위와 같습니다.

 

#과제

 

감사합니다.

 

 

 

New Multi-Channel Dynamic CMS

2020 보안기술 개발 동향

1. 서론

최근 인공지능 기술의 발전에 힘입어 사이버 공격자들은 새로운 형태의 지능화된 알고리즘을 활용한 신·변종 사이버 공격과 자동화 기술을 활용하여 대규모의 사이버 보안 공격을 시도하고 있다. 이러한 추세에 힘입어 점점 고도화되고 다양해지는 사이버 공격에 효율 적으로 대응하기에는 기존의 보안 솔루션들은 많은 한계를 보이고 있다. 사이버 위협에 능동적으로 대비하기 위해서 보안 업계에서는 인공지능을 보안 분야에 적용하는 것에 주 주목 하고 있다. 보안이 인공지능과 결합하게 되면 네트워크, 위협 인텔리전스, 취약점 분석, 악성코드 분석, 실시간 탐지 및 대응 등 다양한 보안 분야에서 보안 능력이 획기적으로 향상될 것으로 예상되고 있다

 

2. 인공지능 보안 위협

인공지능 기술은 분명 현재의 보안 기술단계를 한 단계 끌어올려, 이를 통해 안정적인 비즈니스 환경의 연속성을 보장해줄 뿐만 아니라, 효율적인 인력운용이 가능하다는 장점이 있다.

그러나 이러한 인공지능을 방어측의 전유물이라고 생각하면 큰 오산이다. 인공지능을 적용하여 창과 방패처럼 공격 측과 수비 측에 공평한 기회를 제공한다. 방어 측에서 보면 인공지능이 다양한 악성코드의 공격 유형을 머신러닝 기법을 통해 자동으로 분류 및 분석하여 대응책을 마련하듯이 공격 측에서도 현재 시스템이 가지고 있는 보안 취약점을 지속적으로 탐지하고 공격하여 보안의 허점을 찾아낸다. 또한, 공격자를 효과적으로 위장하는 데에도 사용될 수 있다.

 

3. 네트워크 기반 침입탐지

네트워크 기반 침입탐지(Network-Based Intrusion Detection: NIDS)는 인가되지 않은 사용자가 정보자원에 불법으로 접근하거나, 정보자원을 고갈시키는 행위를 검출하고 이에 대처하는 것을 말한다.

현재 사용되고 있는 네트워크 기반 침입탐지 시스템의 상용제품 대부분은 각종 공격에 대한 특징(signature)을 분석하여 이것을 자동으로 감지할 수 있는 패턴형태로 만들어 놓고, 실시간으로 네트워크 패킷을 관찰하여 동일한 패턴이 발생하면

침입(Intrusion)을 알리는 오용탐지(Misuse Detection)가 주류를 이루고 있다. 이러한 방식은 비교적 높은 정확도를 보여주고 있으며, 실제 사용에서도 어느 정도 효율적이라고 할 수 있다. 그러나, 각종 공격(Attack)을 분석하여 패턴을 만들기 위해서는 해당 분야의 특별한 전문가(Expert)가 필요하기 때문에, 패턴의 생성과 유지보수에는 높은 비용이 요구된다. 또한, 이미 패턴이 존재하던 공격이 약간 우회하여 행해지면, 기존의 패턴만으로 새롭게 변형된 공격을 감지하기가 어렵다. 그러므로 전문가 기반의 오용 탐지 기법은 새로운 유형의 공격에 대해서는 매우 취약할 수밖에 없다.

오용 탐지와는 다르게 평소 정상적인 네트워크 사용에 대한 각종 통계적인 자료를 만들어 놓고, 이 자료의 범위를 벗어나는 네트워크 상의 트래픽(Traffic)이 발생하면 침입이 발생했다고 판단하는 통계적 기반의 비정상 행위 탐지(Statistics-Based Anomaly Detection) 기법도 있다. 이 방법은 일부 공격들에 대해서는 매우 효과적이지만, 공격이 단지 몇 개의 패킷으로 구성되어 있는 경우는 효율적이지 않다.

이러한 이유로 대부분의 상용 네트워크기반 침입탐지 시스템은 전문가에 의한 오용 탐지를 주축으로 하고, 통계적 기반의 비정상 행위 탐지를 보조적으로 사용하고 있다. 그러나 이러한 방법들만으로는 다양한 유형의 공격을 완벽하게 탐지하기에는 한계가 있다.

이를 해결하기 위해 인공지능을 적용하면 정상적인 네트워크 패킷과 각종 비정상적인 네트워크 패킷을 수집하고, 이 패킷에 대해 다양한 머신러닝 알고리즘을 적용하여 학습된 지식을 기반으로, 실시간으로 생성되는 패킷들에 대해 정상 및 비정상 여부를 판단할 수 있다.

 

4. 데이터 전처리

기존 전통적인 보안 솔루션은 한계를 보이고 있고, 이를 위한 해결책이 인공지능 기술을 활용해야 한다는 것은 알겠는데, 그렇다면 “어떻게 보안에 인공지능을 적용을 할 것인가?”라는 문제가 남는다.

인공지능의 기본 동작 원리는 수십 수백만 혹은 그 이상의 데이터들을 우선 학습을 하고, 학습을 통해 나온 컴퓨터가 계산한 알고리즘을 이용한다. 가령 고양이 사진과 고양이 사진이 아닌 것을 학습시킨 뒤, 한 번도 보여주지 않은 사진을 보여주고 이것이 고양이 인지 아닌지의 판단은 학습을 통해 나온 알고리즘에게 물어보는 것이다.

정상적인 네트워크 패킷과 각종 비정상적인 네트워크 패킷을 수집하는 것이 첫번째 우선이 되어야 하며, 이 수집된 데이터들을 손실률을 줄이면서 딥러닝 알고리즘에 바로 적용할 수 있는 형태로 만들어져야 한다. 이를 데이터 전처리라고 하고, 전처리에 대한 방법은 아래와 같다.

 

 

우선 네트워크 트래픽을 pcap을 이용하여 세션 단위로 읽고 txt파일로 저장한다.

 

 

그렇게 나온 txt 저장된 데이터를 28 x 28 크기의 png 이미지로 이미지화한다.

 

 

이런 과정으로 수집된 네트워크 세션 데이터는 CNN, RNN, LSTM 등 다양한 딥러닝 알고리즘 등에 바로 적용해서 사용할 수 있다.

 

5. 딥러닝 알고리즘 사용하기 위한 라이브러리

데이터가 준비가 되었다면, CNN, RNN, LSTM 등의 다양한 딥러닝 알고리즘에 적용을 해볼 수 있을 텐데, 이때 딥러닝에 필요한 수학적 기초나 딥러닝의 이론, 신경망 구조, 그리고 사용 방법을 모두 설명하기는 거의 책 한 권에 가까운 양이다.

여기서는 딥러닝 알고리즘에 적용하기 위한 주요한 딥러닝 라이브러리를 소개를 하고자 한다.

 

 

텐서플로우는 구글이 2015년 오픈소스로 공개한 뒤로, 다양한 자료와 범용성을 기반으로 가장 널리 사용되고 있다. 2016년 바둑에서 이세돌 9단을 꺾은 알파고에 텐서플로우가 적용됐다. 일본 금융사 SMFG개 개발한 신용카드 사기 탐지 시스템이 텐서플로우로 제작이 되었다. GitHub에서 가장 많이 사용되는 딥러닝 프레임워크이기도 하다.

케라스는 모듈화, 최소주의, 확장성이 뛰어난데, 네이버 페이의 카드결제 시스템 중 이상 거래 감지 시스템에 케라스 딥러닝 기반으로 개선한 예가 있다.

파이토치는 페이스북 인공지능 연구팀이 만들었으며, 진입장벽, 유연성, 속도가 뛰어나다. 다만 자료와 예제를 구하는 것이 단점으로 꼽힌다.

Deeplearning4j 세계에서 가장 인기 있는 개발언어인 Java로 만들어졌으나, 역시나 사용자 층이 깊지 않다. 일본의 AI 솔루션 기업 넥스트리머에서 이상 거래 탐지 연구에 활용된 바 있다.

Apapche MXNet은 아마존이 공식 지원하며, 폭넓은 언어 지원과 사용범위가 강점이다. C++, 스칼라, 줄리아, 매트랩, 자바스크립트, 클로저, 펄, R 등의 언어를 지원하여, 모바일 기기부터 서버 수준까지 지원한다.

 

6. 주요 네트워크 기반 침입탐지 시스템

 

6.1 다크트레이스

- 모든 사용자 및 디바이스의 이상 징후를 머신러닝, 인공지능 기법을 활용하여 실시간으로 자동 분석하고 그 이상 여부를 판별,

  차세대 위협 감지 솔루션

- 인간의 면역체계와 유사하게 단말, 서버 등 모든 디바이스에 대한 데이터 흐름을 통해서 정상행위를 학습하고 이에 위반하는

  이상행위 판별

 

6.2 사이런스

- 기존에 수집된 악성코드의 특성을 다양한 머신러닝 알고리즘을 적용하여 학습하고, 이 학습한 데이터를 기반으로 전혀 새로운

  형태의 악성코드도 분류해 낼 수 있는 인공지능을 탑재

- 700만 개 이상의 파일 특징을 0.1초 이내에 종합하여 분석

 

7. 결론 및 시사점

최근 국내에서 열리고 있는 보안 컨퍼런스의 주제를 살펴보면, 인공지능 또는 머신러닝, 빅데이터 등이 70% 이상을 차지하고 있다. 이는 그만큼 현재 보안업계에서 인공지능에 대한 관심이 뜨겁다는 것을 보여주는 반증이라고 할 수 있다. 인공지능의 보안 분야 적용은 보안 시스템을 노리는 공격자와 방어자 모두에게 공평한 발전의 기회를 제공하고 있다.

과거의 사이버 공격은 뚜렷한 목적 없이 불특정 다수를 상대로 공격이 이루어진 것에 반해, 최근에는 금융, 교통과 전력 등 국민의 생명과 재산뿐만 아니라 국가 기반시설을 대상으로 정치, 경제적, 군사적 의도를 가지고 특정 대상을 공격하는 양상으로 변모하고 있다.

국가나 기관이 최신 보안 장비와 솔루션을 도입하여 운용하고 있고, 오랜 기간 노하우를 갖고 있음에도 불구하고, 날로 진화하는 공격을 실시간으로 막지 못해 피해를 입는 사례가 급속하게 증가하고 있으며, 때문에 인공지능의 도입은 필연이라 고 볼 수 있다.

 

8. 참고

인공지능 기술 원리의 이해 / 송경빈

인공지능 기법을 이용한 네트워크 기반 침입탐지 기술 동향 / 이창훈

인공지능을 활용한 보안기술 개발 동향 / 국경완, 공병철

인공지능 기술 및 산업 분야별 적용 사례 / 국경완

A Study of Data Preprocessing for Network Intrusion Detection based on Deep Learning / Kimoon Jeong

CNN과 RNN의 기초 및 응용 연구 / 이은주

 

 

New Multi-Channel Dynamic CMS

Secure Coding 메뉴얼 3편

안녕하세요.

이번 Secure Coding 메뉴얼 3편에서는 TestCase와 점검도구에 대해 알아보도록 하겠습니다.

Secure Coding 전편은 아래 링크를 통해 확인해주세요.

▶ Secure Coding 메뉴얼 1편

▶ Secure Coding 메뉴얼 2편

 

 

 

1. TestCase

1.1 회원가입

 

 

구분 보안요구항목 점검내용
SR1-1 DBMS 조회 및 결과 검증 중복아이디 검색을 위한 사용자ID에 쿼리를 조작할 수 있는 입력값으로 SQL 삽입공격이 시도될 수 있으므로 입력값 검증
우편번호 검색을 위한 입력값 조작하여 SQL 삽입 공격이 시도될 수 있으므로 입력값 검증 필요
SR1-5 웹 서비스 요청 및 결과 검증 회원가입을 위한 입력정보에 악의적인 스크립트가 포함 될 수 있으므로 입력값 검증 필요
SR1-6 웹 기반 중요 기능 수행 요청 유효성 검증 스크립트를 이용하여 회원가입 요청이 처리될 수 있으므로, 실제 사용자의 유효한 요청인지 여부를 확인해야함
SR1-10 업로드 다운로드 파일 검증 허가된 유형의 파일만 업로드 되도록 해야 함
SR2-3 비밀번호 관리 사용자가 입력한 비밀번호에 대해 안전한 패스워드 설정정책이 적용되어야 함
SR2-7 중요정보 저장 비밀번호는 솔트가 적용된 안전한 해시함수를 사용하여 암호화해서 저장해야 함
소스 코드 내에 중요 정보를 노출하는 주석문이 존재하지 않아야 함

 

1.2 아이디 찾기

 

구분 보안요구항목 점검내용
SR1-1 DBMS 조회 및 결과 검증 아이디/비밀번호 찾기시 검색을 위한 사용자 이름, 이메일, ID에 쿼리를 조작할 수 있는 입력값으로 SQL 삽입공격이 시도될 수 있으므로 입력값 검증이 필요함
SR1-5 웹 서비스 요청 및 결과 검증 아이디/비밀번호 찾기시 입력정보에 악의적인 스크립트가 포함될 수 있으므로 입력값 검증이 필요함
SR2-3 비밀번호 관리

비밀번호 찾기시 사전에 등록된 이메일 주소로만 임시비밀번호가 전송되도록 제한해야 함

임시 비밀번호로 첫 로그인 시 반드시 신규비밀번호로 변경하도록 관리해야 함

SR2-4 중요 자원 접근 통제 URL을 변조하여 중요페이지 접근에 대한 인증을 우회할 수 없도록 해야 함
SSI(Server‐Side Includes) 변수가 조작되어 명령실행을 통해 서버 데이터 정보가 누출되지 않도록 해야 함
SR2-7 중요정보 저장 소스코드 내에 중요정보를 노출하는 주석문이 존재하지 않아야 함
SR2-8 중요정보 전송 사용자가 입력한 정보는 암호화하여 전송하거나, 암호화된 통신 채널을 통해 전달해야 함
SR3-1 예외처리 사용자 정보 입력 및 제출과정에서 오류가 발생하는 경우 지정된 페이지로 리다이렉트 하여 에러 정보가 노출되지 않도록 해야 함
SR4-1 세션통제 세션 ID가 URL, 에러메시지, 로그 등에 노출되지 않도록 해야 함

 

1.3 상세조회

 

구분 보안요구항목 점검내용
SR1-1 DBMS 조회 및 결과 검증 목록 조회시 URL 파라미터에 쿼리를 조작할 수 있는 입력값으로 SQL 삽입공격이 시도될 수 있으므로 입력값 검증이 필요함
SR1-5 웹 서비스 요청 및 결과 검증 게시글 수정, 목록 조회시 입력정보에 악의적인 스크립트가 포함될 수 있으므로 입력값 검증이 필요함
SR1-6

웹 기반 중요기능 수행 요청 유효성 검증

스크립트를 이용하여 게시글 수정/삭제 요청이 처리될 수 있으므로, 실제 사용자의 유효한 요청여부를 확인해야 함

SR1-9 보안 기능 동작에 사용되는 입력 값 검증 쿠키·환경변수·Hidden 필드 값을 조작하여 게시글 수정/삭제 요청이 처리될 수 있으므로 실제 사용자의 유효한 요청여부를 확인해야 함
SR2-1 인증 대상 및 방식 인증이 필요한 게시판, 관리자 전용 게시판 등 중요페이지 접근시 인증 절차가 부재이거나, 부적절하게 인증 과 정을 우회할 수 있는지를 확인해야 함
SR2-4 중요자원 접근 통제 URL을 변조하여 중요페이지 또는 권한 없는 페이지 접근에 대한 인증을 우회할 수 없도록 해야 함
SSI(Server‐Side Includes) 변수가 조작되어 명령실행을 통해 서버 데이터 정보가 누출되지 않도록 해야 함
SR3-7 중요정보 저장 소스코드 내에 중요정보를 노출하는 주석문이 존재하지 않아야 함
SR3-1 예외처리 게시물 수정/삭제시 오류가 발생할 경우 지정된 페이지로 리다이렉트 하여 에러 정보가 노출되지 않도록 해야 함
SR4-1 세션통제 중복 로그인을 허용하지 않는 경우 이전에 생성된 로그인 세션을 종료하거나, 새로이 연결되는 세션을 종료해야 함
로그인 상태인 사용자를 위해 해당 페이지에 로그아웃 인터페이스를 구현함
세션 ID가 URL, 에러메시지, 로그 등에 노출되지 않도록 해야 함

 

1.4 글쓰기

 

구분 보안요구항목 점검내용
SR1-1 DBMS 조회 및 결과 검증 목록 조회시URL 파라미터에쿼리를 조작할 수 있는 입력값으로SQL 삽입공격이시도될 수 있으므로 입력값 검증이 필요함
SR1-5 웹 서비스 요청 및 결과 검증 게시글수정, 목록 조회시입력정보에 악의적인 스크립트가 포함될 수 있으므로 입력값 검증이 필요함
SR1-6

웹 기반 중요기능 수행 요청 유효성 검증

스크립트를 이용하여 게시글 수정/삭제 요청이 처리될 수 있으므로, 실제 사용자의 유효한 요청여부를 확인해야 함

SR1-9 보안 기능 동작에 사용되는 입력 값 검증 쿠키·환경변수·Hidden 필드 값을 조작하여 게시글 수정/삭제 요청이 처리될 수 있으므로 실제 사용자의 유효한 요청여부를 확인해야 함
SR1-10


업로드 다운로드 파일 검증


첨부파일 업로드시 사용자가 업로드 하는 파일의 크기, 확장자 및 콘텐츠 타입 등을 검증하여 웹셸 등이 업로드되지 않도록 해야 함
업로드 파일의 저장경로는 외부에서 직접 접근 불가능한 경로를 사용함
업로드 된 파일은 실행권한을 가지지 않도록 함
SR2-1 인증 대상 및 방식 인증이 필요한 관리자 전용 게시판 등 중요페이지 접근 시 인증 절차가 부재이거나, 부적절하게 인증 과정을 우회할 수 있는지를 확인해야 함

SR2-4
중요자원 접근통제 URL/파라미터를 조작하여 중요페이지 또는 권한 없는 페이지 접근에 대한 인증을 우회할 수 없도록 해야 함
SSI(Server‐Side Includes) 변수가 조작되어 명령실행을 통해 서버 데이터 정보가 누출되지 않도록 해야 함
SR2-7

중요정보 저장

첨부파일 업로드시 실제저장명, 파일의 저장경로 등이 노출되지 않도록 함
소스코드 내에 중요정보를 노출하는 주석문이 존재하지 않아야 함
SR3-1 예외처리 중복 로그인을허용하지 않는 경우 이전에 생성된 로그인 세션을 종료하거나, 새로이 연결되는 세션을 종료해야함
로그인 상태인 사용자를 위해 해당 페이지에 로그아웃인터페이스를구현함
세션 ID가 URL, 에러메시지, 로그 등에 노출되지 않도록해야 함
SR4-1


세션통제


중복 로그인을 허용하지 않는 경우 이전에 생성된 로그인 세션을 종료하거나, 새로이 연결되는 세션을 종료해야 함
로그인 상태인 사용자를 위해 해당 페이지에 로그아웃 인터페이스를 구현함
세션 ID가 URL, 에러메시지, 로그 등에 노출되지 않도록 해야 함

 

1.5 글조회

 

구분 보안요구항목 점검내용
SR1-1 DBMS 조회 및 결과 검증 첨부파일 다운로드를 위한 URL 파라미터에 쿼리를 조작할 수 있는 입력값으로 SQL 삽입공격이 시도될 수 있으므로 입력값 검증이 필요함
SR1-4 시스템 자원 접근 및 명령어 수행 입력 값 검증 서버에서 명령 창을 실행해두는 경우 사용자가 시스템 명령어를 입력할 가능성에 대비하여 미리 정의된 인자 값의 배열을 통해 명령어를 선택하도록 해야 함
SR1-5

웹 서비스 요청 및 결과 검증

첨부파일 다운로드시 입력정보에 악의적인 스크립트가 포함될 수 있으므로 입력값 검증이 필요함

SR1-10



업로드 다운로드 파일 검증



첨부파일 다운로드를 위해 요청되는 파일명에 경로를 조작하는 문자가 포함되어 있는지 점검해야 함
첨부파일 다운로드 시 사용자 입력 값을 검증하여 웹 루트 디렉터리를 벗어난 영역에서 파일을 다운로드 할 수 없도록 해야 함
파일 다운로드를 처리하기 전에 파일에 대한 바이러스 및 악성코드 여부를 점검하고 다운로드 받은 파일의 무결성 검사를 실행함
필요시 인증된 사용자만 파일을 다운로드 할 수 있도록 제한함
SR2-1 인증 대상 및 방식 인증이 필요한 게시판, 관리자 전용 게시판 등 중요페이지 접근시 인증 절차가 부재이거나, 부적절하게 인증 과 정을 우회할 수 있는지를 확인해야 함

SR2-4
중요자원 접근통제 URL/파라미터를 조작하여 중요페이지 또는 권한 없는 페이지 접근에 대한 인증을 우회할 수 없도록 해야 함
SSI(Server‐Side Includes) 변수가 조작되어 명령실행을 통해 서버 데이터 정보가 누출되지 않도록 해야 함
SR2-7

중요정보 저장

첨부파일 다운로드 시 실제저장명, 파일의 저장경로 등이 노출되지 않도록 함
소스코드 내에 중요정보를 노출하는 주석문이 존재하지 않아야 함
SR3-1 예외처리

첨부파일 다운로드 요청시 오류가 발생하는 경우 지정된 페이지로 리다이렉트하여 에러 정보가 노출되지 않도록 해야 함

SR4-1


세션통제


중복 로그인을 허용하지 않는 경우 이전에 생성된 로그인 세션을 종료하거나, 새로이 연결되는 세션을 종료해야 함
로그인 상태인 사용자를 위해 해당 페이지에 로그아웃 인터페이스를 구현함
세션 ID가 URL, 에러메시지, 로그 등에 노출되지 않도록 해야 함

 


2. 점검 도구

2.1 JAVA 프로그래밍 언어 기반의 공개용 분석 도구

 

자바를 지원하는 공개용 분석 도구의 각 특징

구분 FindBugs FindSecurityBugs JLint LAPSE+ PMD Yasca
진단대상 바이트코드 바이트코드 바이트코드 자바코드 자바코드 자바코드
설치/운영

이클립스

플러그인

FindBugs 모듈 CLI

이클립스

플러그인

이클립스

플러그인/CLI

CLI
라이센스 FREE FREE FREE FREE FREE FREE
자바 외 지원언어 Groovy, Scala Groovy, Scala x o x

javascript,

ASP, 

ColdFusion,

PHP,

COBOL,

.NET 등

특징

널 포인터 지연, 동기화 오류, 악성코드에 대한 취약성 등 JVM언어 분석 탐지

FindBugs의 확장 모듈로 XPath 삽입, SQL 삽입, 암호화 취약점 등 탐지

버그, 불일치, 동기화 문제 등을 탐지 웹 응용 프로그램에 있는 일반적인 유형의 보안 취약점에 대해 탐지 의심스러운 구성, 데드 코드, 중복 코드 등 탐지 매우 유연하고 확장하기 쉽도록 설계되어 새로운 규칙을 정규 표현식 작성하는 것처럼 추가 가능
개발 2012년 9월 2012년 9월 2012년 8월 2006년 9월 2006년 2월 2010년 3월

 

2.2 입력데이터 검증 및 표현 유형(SR1) 성능 분석 결과

 

o : 탐지가능

x : 탐지불가능 or 오탐

- : Juliet 코드가 없음

 

보안약점 FindBugs FindSecurityBugs JLint LAPSE+ PMD Yasca
SQL 삽입 o o x o x o
경로 조작 및 자원 삽입 o o x o x x
크로스사이트 스크립트 o o x o x x
운영체제 명령어 삽입 x o x o x x
위험한 형식 파일 업로드 - - - - - -
신뢰되지 않는 URL 주소로 자동접속 연결 x x x x x x
XQuery 삽입 - - - - - -
XPath 삽입 x x x o x x
LDAP 삽입 x x x x x x
크로스사이트 요청 위조 - - - - - -
HTTP 응답분할 o o x o x x
정수형 오버플로우 x x o x x x
보안기능 결정에 사용되는 부적절한 입력값 - - - - - -
메모리 버퍼 오버플로우 - - - - - -
포멧스트링 삽입 x x x x x x

 

 

2.3 보안약점(SR2) 성능 분석 결과

 

o : 탐지가능

x : 탐지불가능 or 오탐

- : Juliet 코드가 없음

 

보안약점 FindBugs FindSecurityBugs JLint LAPSE+ PMD Yasca
적절한 인증 없는 중요기능 허용 - - - - - -
부적절한 인가 - - - - - -
중요한 자원에 대한 잘못된 권한 설정 - - - - - -
취약한 암호화 알고리즘 사용 x o x x x o
중요정보 평문저장 - - - - - -
중요정보 평문전송 x x x x x x
하드코드된 비밀번호 o o x x x x
충분하지 않은 키 길이 사용 - - - - - -
적절하지 않은 난수 값 사용 x o x x x x
하드코드된 암호화 키 x x x x x x
취약한 비밀번호 허용 - - - - - -
사용자 하드디스크에 저장되는 쿠키를 통한 정보 노출 - - - - - -
주석문 안에 포함된 시스템 주요정보 x x x x x x
솔트 없이 일방향 해쉬함수 사용 x x x x x x
무결성 검사 없는 코드 다운로드 - - - - - -
반복된 인증시도 제한 기능 부재 - - - - - -

 

 

2.4 에러처리, 코드오류(SR3, SR4) 성능 분석 결과

 

o : 탐지가능

x : 탐지불가능 or 오탐

- : Juliet 코드가 없음

 

보안약점 FindBugs FindSecurityBugs JLint LAPSE+ PMD Yasca
오류 메시지를 통한 정보 노출 x x x x o x
오류 상황 대응 부재 x x x x o x
부적절한 예외 처리 - - - - - -
Null Pointer 역참조 o o o x x x
부적절한 자원 해제 x x x x x x
해제된 자원 사용 - - - - - -
초기화되지 않은 변수 사용 - - - - - -

 

2.5 분석도구 성능분석 결과

 

o : 탐지가능

x : 탐지불가능 or 오탐

- : Juliet 코드가 없음

 

보안약점 FindBugs FindSecurityBugs JLint LAPSE+ PMD Yasca
입력데이터 검증 및 표현 4 5 1 6 - 1
보안기능 7 1 3 - - 1
시간 및 상태 1 1 1 - - -
에러처리 2 - - - 1 -
코드오류 1 1 1 - - -
캡슐화 - - - - - 1
API 오용 - - - - - -
7 10 2 6 1 3

 

2.6 분석도구 사용 (FindBugs, PMD)

 

<설치>

 

1) eclipse > plugins 이동

 

2) FindBugs Plugin 폴더 복사

 

3) PMD 파일 복사

 

4) eclipse > configuration > org.eclipse.equinox.simpleconfigurator 이동

 

5) bundles.info 열기

 

6) FindBugs, PMD Plugin 정보 추가 (마지막 줄에 추가)

edu.umd.cs.findbugs.plugin.eclipse,3.0.1.20150306-5afe4d1,plugins/edu.umd.cs.findbugs.plugin.eclipse_3.0.1.20150306-5afe4d1/,4,false

net.sourceforge.pmd.eclipse.plugin,4.7.0.v20190915-0943,plugins/net.sourceforge.pmd.eclipse.plugin_4.7.0.v20190915-0943.jar,4,false

 

<점검>

 

1) 점검할 프로젝트 및 파일 선택

 

2) 점검

 

3) Bug Explorer 에서 내용 확인

 

4) souce 코드 확인 (FindBugs)

 

5) Bug Info 에서 솔루션 확인 (FindBugs)

 

6) souce 코드 확인 (PMD)

 

7) Violation Outline 에서 리스트 확인 (PMD) 

 

8) 상세 확인 (PMD)

 

<결론>

 

  • 모든 보안약점을 분석할 수 있는 규칙 및 성능을 보유한 분석도구는 존재하지 않음
  • 여러 개의 도구를 같이 사용하여 분석 범위를 넓히고 분석도구가 분석하지 못하는 보안약점에 대해서는 직접 수동으로 확인하는 것이 좋음
  • CoreFrame에서  jspx파일의 자바코드는 java코드로 인식을 하지 못하여 탐지가 불가능하였음

 


 

[참고 문서]

- 소프트웨어 개발 보안 가이드 (한국 인터넷 진흥원)

- 소프트웨어 개발 보안 점검 가이드 (한국 인터넷 진흥원)

- 공개용 소스 코드 보안 약점 분석 도구 개발 동향 (한국 인터넷 진흥원)

 

※ 시큐어 코딩에 대한 주요 5가지를 메뉴얼화 하였으며, 계속적으로 업그레이드가 필요함.

 

 


 

 

 

'백엔드' 카테고리의 다른 글

웹 서비스 동작구조와 소켓 통신  (1) 2021.02.02
2020 보안기술 개발 동향  (0) 2020.06.04
Secure Coding 메뉴얼 3편  (0) 2019.11.18
Secure Coding 메뉴얼 2편  (0) 2019.11.11
Secure Coding 메뉴얼 1편  (0) 2019.11.04
사내 IaaS 구축하기  (0) 2018.06.25

New Multi-Channel Dynamic CMS

Secure Coding 메뉴얼 2편

안녕하세요. 

이번 Secure Coding 2편에서는 보안 요구 사항 정의와 시큐어 코딩에 대해 알아보도록 하겠습니다.

Secure Coding 1편의 내용은 아래 링크를 통해 확인해주세요.

▶ Secure Coding 메뉴얼 1편

 

 

 

 

1. 보안 요구 사항 정의

1.1 입력 데이터 검증 및 표현 

 

1.1.1 SR1-1

구분 항목 요구 사항 내용
SR1-1 DBMS 조회 및 결과 검증

1. 애플리케이션에서 DB연결을 수행할 때 최소 권한의 계정을 사용해야 한다.

2. 외부 입력값이 삽입되어 SQL쿼리문을 동적으로 생성해서 실행하지 않도록 해야 한다.

3. 외부 입력값을 이용해 동적으로 SQL쿼리문을 생성해야 하는 경우 입려값에 대한 검증을 수행한 뒤 사용해야 한다.

▶ 데이터베이스와 연동되어 있는 어플리케이션의 입력된 데이터에 대한 유효성을 검증하지 않을 경우, 공격자가 입력 폼 및 URL에 SQL문을 삽입하여 DB로부터 정보를 열람하거나 조작할 수 있는 보안 취약점

 

[취약점 목록 및 공격 내용]

① 작은 따옴표(‘) 를 이용한 SQL Injection

: 데이터베이스에서 특수한 의미를 가지는 문자로, 공격자는 이 문자를 이용하여 SQL 구분에 임의의 SQL 구문을 삽입

 

 

② 더블 대시(--)를 이용한 SQL Injection

: 주석문과 같은 의미를 가지고 있는 문자열로 뒤에 오는 모든 SQL 구문을 주석으로 처리하여 사용자 계정을 확인

 

 

1.1.2 SR1-2

구분 항목 요구 사항 내용
SR1-2 XML 조회 및 결과 검증

XML문서를 조회하는 기능을 구현해야 하는 경우 XML 쿼리에 사용되는 파라미터는 반드시 XML쿼리를 조작 할 수 없도록 필터링해서 사용하거나, 미리 작성된 쿼리문에 입력값을 자료형에 따라 바인딩해서 사용해야 한다.

▶ XML 문서를 조회할 경우 입력 값 조작을 통해 XQurey나 XPath와 같은 쿼리문 구조를 임의로 변경하여 허가되지 않은 데이터를 조회하거나 인증 절차를 우회하는 취약점

 

[취약점 목록 및 공격 내용]

① XQuery 삽입

: XQuery를 조작할수 있는 임의의 문자열을 삽입

 

1.1.3 SR1-3

구분 항목 요구 사항 내용
SR1-3 디렉터리 서비스 조회 및 결과 검증

LDAP 인증서버를 통해 인증을 구현하는 경우 인증요청을 위해 사용되는 외부입력값은 LDAP 삽입 취약점을 가지지 않도록 필터링해서 사용해야 한다.

▶ 외부 입력값이 LDAP(Lightweight Directory Access Protocol) 조회를 수행하기 위한 필터 생성에 사용되는 경우 필터 규칙을 변경 할 수 있는 입력값에 대한 검증 작업을 수행하지 않아 발생되는 취약점

[취약점 목록 및 공격 내용]

① LDAP 삽입

: XQuery를 조작할수 있는 임의의 문자열을 삽입

 

1.1.4 SR1-4

구분 항목 요구 사항 내용
SR1-4 시스템 자원 접근 및 명령어 수행 입력 값 검증

1. 외부 입력값을 이용하여 시스템자원(IP, PORT번호, 프로세스, 메모리, 파일 등)을 식별하는 경우 허가되지 않은 자원이 사용되지 않도록 해야 한다.

2. 서버 프로그램 안에서 셀을 생성하여 명령어를 실행해야 하는 경우 외부 입력값에 의해 악의적인 명령어가 실행되지 않도록 해야  한다.

▶ 공격자가 입력값 조작을 통해 시스템이 보호하는 자원에 임의로 접근하거나, 적절한 검증절차를 거치지 않은 사용자 입력값에 의해 의도하지 않은 시스템 명령어가 실행되어 운영에 악영향을 미칠 수 있는 취약점이다.

 

[취약점 목록 및 공격 내용]

① 경로 조작 및 자원 삽입

② 운영체제 명령어 삽입

 

1.1.5 SR1-5

구분 항목 요구 사항 내용
SR1-5 입력데이터 검증 및 표현

1. 사용자로부터 입력 받은 값을 동적으로 생성되는 응답페이지에 사용하는 경우 크로스사 이트스크립트(XSS) 필터링을 수행한 뒤 사용해야 한다.

2. DB조회결과를 동적으로 생성되는 응답페이지에 사용하는 경우 HTML인코딩 또는 크로 스사이트스크립트(XSS) 필터링을 수행한 뒤 사용해야 한다.

▶ 웹 페이지에 악의적인 스크립트를 포함시켜 웹페이지를 열람하는 접속자의 권한으로 부적절한 스크립트가 수행되어 정보유출 등의 공격을 유발할 수 있다.  

 

[취약점 목록 및 공격 내용]

① 크로스사이트 스크립트

 

1.1.6 SR1-6

구분 항목 요구 사항 내용
SR1-6 웹 기반 중요기능 수행 요청 유효성 검증

시스템으로 전송되는 모든 요청에 대해 정상적인 사용자의 유효한 요청인지, 아닌지 여부를 판별할 수 있도록 해야 한다.

▶ 공격자는 세션탈취, XSS 등을 통해 자신이 의도한 행위(수정, 삭제, 등록 등)를 사이트가 신뢰하는 인 증된 사용자의 권한을 통해 실행되게 할 수 있다.

 

 

[취약점 목록 및 공격 내용]

① 요청 위조 코드 등록하여 공격 (크로스사이트 요청 위조 CSRF)

 

1.1.7 SR1-7

구분 항목 요구 사항 내용
SR1-7 HTTP 프로토콜 유효성 검증

1. 외부입력값을 쿠키 및 HTTP 헤더정보로 사용하는 경우, HTTP 응답분할 취약점을 가지지 않도록 필터링해서 사용해야 한다.

2. 외부입력값이 페이지이동(리다이렉트 또는 포워드)를 위한 URL로 사용되어야 하는 경우, 해당 값은 시스템에서 허용된 URL 목록의 선택자로 사용되도록 해야 한다.

▶ 공격자가 HTTP 요청에 삽입한 인자값이 응답헤더에 포함되어 사용자에게 전달될 때 첫 번째 응답을 종료시키고 두 번째 응답의 악의적인 코드가 실행되거나, 사용자의 입력값을 외부 사이트의 주소로 사용하여 자동으로 위험한 URL로 접속 유도

 

[취약점 목록 및 공격 내용]

① HTTP 응답 분할

② 신뢰되지 않은 URL 주소로 자동접속 연결

 

1.1.8 SR1-8

구분 항목 요구 사항 내용
SR1-8 형용된 범위 내 메모리 접근

1.C나 C++ 같이 메모리를 프로그래머가 관리하는 플랫폼을 사용하는 경우 메모리 버퍼의 경계값을 넘어서 메모리를 읽거나 저장하지 않도록 경계설정 또는 검사를 반드시 수행해야 한다.

2. 개발시, 메모리 버퍼오버플로우를 발생시킬 수 있는 취약한 API를 사용하지 않도록 통제해야 한다.

(버퍼오버플로우) 스택(Stack)이나 힙(Heap)에 할당되는 메모리에 문자열 등이 저장될 때 최초 정의된 메모리의 크기를 초 과하여 문자열을 저장하는 경우 버퍼오버플로우가 발생한다.

 

[취약점 목록 및 공격 내용]

① 버퍼오버플로우

② 포맷 스트링 삽입

 

1.1.9 SR1-9

항목 요구 사항 내용
SR1-9 보안기능 동작에 사용되는 입력값 검증

1. 사용자의 역할, 권한을 결정하는 정보는 서버에서 관리해야 한다.

2. 쿠키값, 환경변수, 파라미터값 등 외부입력값이 보안기능을 수행하는 함수의 인자로 사 용되는 경우, 입력값에 대한 검증작업을 수행한 뒤 제한적으로 사용해야 한다.

 

3. 중요상태정보나 인증, 권한결정에 사용되는 정보는 쿠키로 전송되지 않아야 하며, 불가 피하게 전송해야 하는 경우에는 해당 정보를 암호화해서 전송해야 한다.

▶ 사용자가 전달하는 쿠키, 환경변수, 히든필드의 사용자권한을 나타내는 변수를 조작한 뒤 서버로 요청하거나, 허용된 값을 넘어서도록 변조하거나, 공격자가 의도적으로 널 포인터 역참조를 발생시키는 등 오류를 발생시켜 공격

 

[취약점 목록 및 공격 내용]

① 보안기능 결정에 사용되는 부적절한 입력값

② 정수형 오버플로우

 

③ Null Pointer 역 참조

 

1.1.10 SR1-10

구분 항목 요구 사항 내용
SR1-10 업로드 · 다운로드 파일 검증

1. 업로드되어 저장되는 파일의 타입, 크기, 개수, 실행권한을 제한해야 한다.

2. 업로드되어 저장되는 파일은 외부에서 식별되지 않아야 한다.

3. 파일 다운로드 요청시, 요청파일명에 대한 검증작업을 수행해야 한다.

4. 다운로드 받은 소스코드나 실행파일은 무결성 검사를 실행해야 한다.

▶ 서버측에서 실행될 수 있는 스크립트 파일(asp, jsp, php파일 등)을 업로드를 하여, 웹을 통해 직접 실행하거나, 외부입력값에 대해 경로 조작에 사용될 수 있는 문자를 이용하여 접근제한 영역에 접근을 하거나, 원격으로부터 소스코드 또는 실행파일을 실행할 하여 서버의 변조, DNS 스푸핑 (Spoofing) 등 공격자가 악의적인 코드를 실행또는 정보를 탈취하는 취약점

 

[취약점 목록 및 공격 내용]

① 위험한 형식 파일 업로드

② 경로 조작 파일 다운로드

: ../ 등의 경로 조작하는 문자열을 삽입을 허용함으로써 접근 제한 영역에 접근

ex) download.jsp?filename=../../../config.xml

 

③ 무결성 검사 없는 코드 다운로드

 


1.2 보안기능 

 

1.2.1 SR2-1

구분 항목 요구 사항 내용
SR2-1 인증 대상 및 방식

1. 중요기능이나 리소스에 대해서는 인증 후 사용 정책이 적용되어야 한다.

2. 안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

3. 중요기능에 대해 2단계(2-factor)인증을 고려해야 한다.

▶ 중요기능이나 리소스를 요청하는 경우 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하는 경우 중요 정보나 리소스가 노출될 수 있다.

 

[취약점 목록 및 공격 내용]

① 적절한 인증 없는 중요기능 허용

1.2.2 SR2-2

구분 항목 요구 사항 내용
SR2-2 인증수행 제한

1. 로그인 기능 구현 시, 인증시도 횟수를 제한하고, 초과된 인증시도에 대해 인증제한 정책 을 적용해야 한다.

2. 실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야  한다.

▶ 로그인 시도에 대한 횟수를 체크하지 않으면 로그인 시도 횟수가 초과되었을 때 계정에 대한 보호조치가 설정되어 있지 않은 경우 패스워드 무작위 대입공격이 시도될 수 있다.

 

 

[취약점 목록 및 공격 내용]

① 반복된 인증 시도 제한 기능 부재

 

1.2.3 SR2-3

구분 항목 요구 사항 내용
SR2-3 비밀번호 관리

1. 패스워드를 설정할 때 한국인터넷진흥원의 『암호이용안내서』 의 패스워드 생성규칙을 적용해야 한다.

2. 네트워크를 통해 패스워드를 전송하는 경우 반드시 패스워드를 암호화하거나 암호화된 통신 채널을 이용해야 한다.

3. 패스워드 저장시, 솔트가 적용된 안전한 해시함수를 사용해야 하며, 해시함수 실행은 서 버에서 해야 한다.

4.패스워드 재설정/변경시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

5. 패스워드 관리 규칙을 정의해서 적용해야 한다.

▶ 회원가입 시에 안전한 패스워드 규칙이 적용되지 않아서 취약한 패스워드로 회원가입이 가능할 경 우 무차별 대입공격을 통해 패스워드가 누출될 수 있으며, 프로그램 코드 내부에 하드코드된 패스워드를 포함하고, 이를 이용하여 내부 인증에 사용하거나 외부 컴포넌트와 통신을 하는 경우, 관리자 정보가 노출될 수 있어 위험하다

 

[취약점 목록 및 공격 내용]

① 취약한 비밀번호 허용

② 하드코드된 비밀번호

 

1.2.4 SR2-4

구분 항목 요구 사항 내용
SR2-4 중요 자원 접근 통제

1. 중요 자원 및 기능에 대한 접근 통제 정책을 수립하여 적용해야 한다.

2. 관리자 페이지에 대한 접근 통제 정책을 수립하여 적용해야 한다.

▶ 인터넷을 통해 접근 가능할 경우 SQL삽입 및 접근에 대한 제어를 하지 않아 무차별대입공경에 대해 서버가 처리 하여 정보가 누출되는 취약점

 

[취약점 목록 및 공격 내용]

① 관리자 페이지 노출

: 관리자 페이지로 추정되는 URL을 이용하여 공격의 빌미를 제공하게 되는 취약점

Ex) www.aa.co.kr/admin.jsp, www.aa.co.kr/test.jsp, www.aa.co.kr/superuser.jsp

 

② SSI 삽입

: SSI(Server-side Includes)는 HTML 문서 내 변수 값으로 입력된 내용을 서버가 처리하여 명령이 수행됨에 따라 정보가 누출 되는 취약점

③ 부적절한 인가

: 프로그램이 실행 가능한 경로에 대해 완전하게 검사하지 않아 공격자가 접근 가능한 실행 경로를 통해 정보를 유출 할 수 있는 취약점

 

1.2.5 SR2-5

구분 항목 요구 사항 내용
SR2-5 암호키 관리

1. DB데이터 암호화에 사용되는 암호키는 한국인터넷진흥원의 「암호이용안내서」에서 정 의하고 있는 방법을 적용해야 한다.

2. 설정파일(xml, Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별 도의 디렉터리에 보관해야 한다.

▶ 코드 내부에 하드코드된 암호화 키, 주석문 안에 암호키를 사용하여 암호화를 수행하면 암호화된 정보가 유출될 가능성 이 높아진다.

[취약점 목록 및 공격 내용]

① 하드코드 된 암호키

 

② 주석문 안에 포함된 시스템 주요 정보

 

1.2.6 SR2-6

구분 항목 요구 사항 내용
SR2-6 암호 연산

1 .대칭키 또는 비대칭키를 이용해서 암·복호화를 수행해야 하는 경우 한국인터넷진흥원 의 『암호이용안내서』에서 정의하고 있는 암호화 알고리즘과 안전성이 보장되는 암호키 길이를 사용해야 한다.

2. 복호화되지 않는 암호화를 수행하기 위해 해시함수를 사용하는 경우 안전한 해시 알고 리즘과 솔트값을 적용하여 암호화해야 한다.

3. 난수생성시 안전한 난수 생성 알고리즘을 사용해야 한다.

▶ base64와 같은 지나치게 간단한 인코딩 함 수를 사용하면 패스워드를 안전하게 보호할 수 없고, 검증된 암호화 알고리즘을 사용하더라도 키 길이가 충분히 길지 않으면 짧은 시간 안에 키를 찾아낼 수 있고, 예측 가능한 난수를 사용하는 것은 시스템의 보안약점을 유발한다. 패스워드를 솔트 없이 저장한다면 모든 패스워드에 대해 해시값을 미리 계산하고 이를 통해 패스워드를 찾을 수 있게 된다.

 

[취약점 목록 및 공격 내용]

① 취약한 암호알고리즘 사용

 

② 충분하지 않은 키 길이 사용

 

③ 적절하지 않은 난수 사용

 

④ 솔트 없이 사용하는 일방향 해시함수

 

 

1.2.7 SR2-7

구분 항목 요구 사항 내용
SR2-7 중요 정보 저장

1. 중요정보 또는 개인정보는 암호화해서 저장해야 한다.

2. 불필요하거나 사용하지 않는 중요정보가 메모리에 남지 않도록 해야 한다.

▶ 사용자 중요정보 및 시스템 중요정보를 처리하는 과정에서 이를 평문으로 저장하거나, 영속적인 쿠키(Persistent Cookie)에 저장된다면, 공격자는 접근할 수 있는 보다 많은 기회를 가지게 되며, 이는 시스템을 취약하게 만든다.

 

[취약점 목록 및 공격 내용]

① 주요 정보 평문 저장

② 사용자 하드 디스크에 저장되는 쿠키를 통한 정보 노출

 

1.2.8 SR2-8

구분 항목 요구 사항 내용
SR2-8 중요 정보 전송

1. 인증정보와 같은 민감한 정보 전송시 안전하게 암호화해서 전송해야 한다.

2. 쿠키에 포함되는 중요정보는 암호화해서 전송해야 한다.

▶ 프로그램이 보안과 관련된 민감한 데이터를 평문으로 송·수신할 경우, 통신채널 스니핑을 통해 인가 되지 않은 사용자에게 민감한 데이터가 노출될 수 있다.

 

 

[취약점 목록 및 공격 내용]

① 주요 정보 평문 전송

: 인증 정보와 같이 중요한 정보를 전송할 경우 암호화 해서 전송해야 한다.

 


1.3 에러처리 

 

1.3.1 SR3-1

구분 항목 요구 사항 내용
SR3-1 예외처리

1. 명시적인 예외의 경우 예외처리 블럭을 이용하여 예외발생시 수행해야 하는 기능이 구현 되도록 해야 한다.

2. 런타임 예외의 경우 입력값의 범위를 체크하여 애플리케이션이 정상적으로 동작할 수 있 는 값만 사용되도록 보장해야 한다.

3. 에러가 발생한 경우 상세한 에러 정보가 사용자에게 노출되지 않게 해야 한다.

▶ 웹 서버에 별도의 에러 페이지를 설정하지 않은 경우, 에러 메시지를 통해 서버 데이터 정보 등 공격 에 필요한 정보가 노출되며, 시스템, 관리자, DB정보 등 시스템의 내부 데이터가 공개되면, 공격자에게 또 다른 공격의 빌미를 제공하게 된다.

 

[취약점 목록 및 공격 내용]

① 오류메시지를 통한 정보노출

② 시스템 정보 노출

 


1.4 세션통제 

 

1.4.1 SR4-1

구분 항목 요구 사항 내용
SR4-1 세션통제

1. 세션간 데이터가 공유되지 않도록 설계해야 한다.

2. 세션이 안전하게 관리되도록 해야 한다.

3. 세션ID가 안전하게 관리되도록 해야 한다.

▶ 인증시 일정한 규칙이 존재하는 세션ID가 발급되거나 세션 타임아웃을 너무 길게 설정한 경우 탈취 가능성이 있으며, 다중 스레드 환경에서는 싱글톤(Singleton)객체 필드에 경쟁조건(Race Condition) 발생할 수 있다.

 

[취약점 목록 및 공격 내용]

① 불충분한 세션관리

② 잘못된 세션에 의한 정보노출

 

 

2. 시큐어 코딩

2.1 SQL 삽입 (SR1-1)

 

1) 개요 : 데이터의 유효성을 검증하지 않아 공격자가 URL입력란에 SQL을 삽입하여 DB로 부터 정보를 열람하거나 조작할 수 있는 보안 취약점

 

2) 보안대책 : DB쿼리에 사용되는 외부 입력값에 대해 특수문자 및 쿼리 예약어를 필터링하고, 프레임워크를 사용하는 경우에는 외부 입력 값 검증 모듈 및 보안 모듈을 사용한다.

 

3) 코드 예제 : 외부에서 입력받은 gubun의 값으로 [ a’ or ‘a’ = ‘a ]를 입력하면 조건절이 [gubun=‘a’or’a’=‘a’]로 바뀌어 모든 데이터를 조회 할 수 있다.

 

- 안전하지 않은 코드의 예

String gubun = request.getParameter(“gubun”);

SELECT  ID, USRE_NAME, GUBUN FROM TEST

WHERE GUBUN = ‘”+  gubun +”’ “;

 

- 안전한 코드의 예

String gubun = request.getParameter(“gubun”);

SELECT  ID, USRE_NAME, GUBUN FROM TEST

WHERE GUBUN = ? ;

Pstmt.setString (1, gubun);

 

 

2.2 크로스 사이트 스크립트 (SR1-5)

 

1) 개요 : XSS 공격을 통해 정상적인 페이지와 유사한 피싱 사이트로 유도하여 개인정보를 탈취하거나 악성 사이트로 유도하여 악성 코드를 유포 / 사용자 쿠키 정보를 획득하여 Replay Attack등에 공격

 

2) 보안대책 : 외부 입력값에 스크립트가 삽입되지 못하도록 문자변환 함수또는 메서드를 사용하여 < > & “ 등을 &lt; &gt; &amp; &quot; 로 치환한다

 

3) 코드 예제 : 파라미터(id)에 <script>alert(document.cookie);</script> 와 같은 스크립트 코드가 입력되고, 이 값을 그대로 출력에 사용하는 경우, 공격자는 공격코드를 이용하여 피해자의 쿠키 정보를 빼돌릴 수 있다.

 

- 안전하지 않은 코드의 예

<% String customerID  request.getParameter(“id”); %>

요청한 사용자 : <%=customerID%>

 

- 안전한 코드의 예

예제1 – 출력값을 HTML 인코딩

String cleanData = input.replaceAll(“<“,”&lt;”).replaceAll(“>”,”&gt;”);

Out.println(cleanData);

 

예제2 – 라이브러리를 이용하여 필터링

XssFilter filter = XsssFilter.getInstance(“aaa.xml”);

Out.append(filer.doFilter(data));

 

 

2.3 취약한 암호화 알고리즘 (SR2-6)

 

1) 개요 : 표준화 되지 않은 암호화 알고리즘을 사용하는 것은 공격자가 알고리즘을 분석하여 무력화시킬 수 있는 가능성이 있으며, 컴퓨터의 성능이 향상됨에 따라 알고리즘이 해독되어 취약점이 발생 하기도 한다.

 

2) 보안대책 : 표준화된 알고리즘을 사용하고 취약하다고 알려진 DES RC5 등의 암호화 알고리즘 대신 3DES, ASE, SEED등의 안전한 암호화 알고리즘으로 대체하여 사용한다.

 

3) 코드예제 : 보안 강도가 낮은 암호 알고리즘 사용 시 암호화된 통신 내용이 유출 되는 등의 위협이 존재함에 따라, 암호 알고리즘의 보안 강도의 적절성 여부를 점검한다.

 

- Apache 서버 설정

<VirtualHost *:443>

 DocumentRoot “D:/WebServer/Apache2.2/htdocs”

 ServerName www.krx.co.kr:443

 ErrorLog “logs/error.log”

 TransferLog “logs/access.log”

 SSLEngine on

 SSLProtocol –ALL +TLSv1.2

 SSLCipherSuite ALL:+HIGH:+MEDIUM:!SSLv2:!PSK:!SRP:!ADH:!AECDH:!EXP:!RC4:!MD5:!SHA:!DES

 

- Tomcat 서버 설정

* 서버, 버전별 적용 방법은 https://mozilla.github.io/server-side-tls/ssl-config-generator/ 참고

<Connector port=“8443” protocol=“org.apache.coyote.http11.Http11NioProtocol” SSLEnabled=“true”

 maxThreads=“512” scheme=“https” secure=“true” keystoreFile=“D:\Apache2.2\keystoreFile.jks”

 keystorePass=“keystorePassword” clientAuth=“false” sslProtocol=“TLS”

 ciphers=“TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,

 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,

 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,

 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA”>

 

4) 전송시 암호화

4-1) 웹 서버와 클라이언트 간 암호화

웹 브라우저에 기본적으로 내장된 SSL/TLS 프로토콜로 접속하는 SSL방식과 웹 브라우저에 보안 프로그램을 설치하여 접속하는 응용 프로그램 방식으로 구분할 수 있다.

웹서버와 웹브라우전 간의 SSL/TLS 통신구조

4-2) 개인정보처리시스템 간 암호화

개인정처리시스템 간에 개인정보를 전송할 때 암호화르 ㄹ지원하기 위하여 공중망을 이용한 가상사설망(VPN:Virtual Private Network)를 구축할 수 있으며, VPN은 기반이 되는 보안 프로토콜의 종류에 따라 IPsec VPN, SSL VPN, SSH VPN 으로 구분할 수 있다.

 

4-3) 개인정보취급자 간 암호화

개인정보 취급자가 개인정보를 전송할 때 이메일을 이용할 경우 네트워크를 통해 전송되는 과정에서 공격자에 의해 유출되거나 위변조 될 가능성을 보호하기 위해서 PGP 또는 S/MIME를 이용하는 이메일 암호화 방식과 이메일 첨부문서 암호화 방식

 

5) 저장시 암호화

5-1) 개인정보처리시스템 암호화 방식
개인정보를 처리하고 관리하는 개인정보처리스템은 DB에 저장된 개인정보를 암호화 하여 저장함으로써 유출, 위.변조, 훼손 등 방지 

 

5-2) 업무용 컴퓨터 보조 저장 매체 암호화 방식
업무용 컴퓨터에서는 하드, 이동식 디스크 또는 보조저장매체에 저장된 개인정보의 보호를 위해 개별 문서 파일 단위 암호화, 디렉토리, 디스크 암호화 등의 방법을 상용

 

6) 암호키 관리

6-1) 암호키 수명주기

6-2) 단계별 암호키 관리

6-3) 암호키 유효기간

 

2.4 중요 정보 평문 전송 (SR2-7)

 

1) 개요 : 사용자 또는 시스템의 중요정보가 포함된 데이터를 평문으로 송.수신할 경우, 통신채널 스나핑을 통해 인가되지 않은 사용자에게 민감한 데이터가 노출될 수 있는 보안 취약점

 

2) 보안대책 : 민감한 정보를 통신채널을 통하여 내보낼 때에는 반드시 암호화 과정을 거처야 하며, 필요할 경우 SSL 또는 HTTP등과 같은 보안 채널을 사용해야 하며, 브라우저 쿠키에 중요 데이터를 저장하는 경우 쿠키 객체에 보안 속성을 설정하여야 한다.

 

3) 코드예제 : 네트워크를 통해 서버로 전송하기 전에 AES 등의 안전한 암호화 알고리즘으로 암호화한 안전한 프로그램

 

- 안전하지 않은 코드의 예

try {

 Socket s= new Socket(“Taranis”, 4444);

 PrintWriter o = new PrintWriter(s.getOutputStream().true);

 String password = getPassword();

 o.write(password);

} catch(FileNotFountException e) { }

 

- 안전한 코드의 예

try {

 Socket s= new Socket(“Taranis”, 4444);

 PrintWriter o = new PrintWriter(s.getOutputStream().true);

 Cipher c = Cipher.getInstance(“AES/CBC/PKCS5Pading”);

 String password = getPassword();

 byte[] encPassword = c.update(password.getByte());

 o.write(password);

} catch(FileNotFountException e) { }

 

 

4) 와이어샤크 이용한 점검

 

2.5 부적절한 인가 (SR2-4)

 

1) 개요 : 적절한 인증과정이 없이 중요정보(계좌이체 정보, 개인정보 등)를 열람(또는 변경)할 때 발생하는 보안약점이다.

 

2) 보안대책 : 클라이언트의 보안검사를 우회하여 서버에 접근하지 못하도록 설계하고 중요한 정보가 있는 페이지는 재인증을 적용(은행 계좌이체 등)한다. 또한 안전하다고 검증된 라이브러리나 프레임워크(OpenSSL이나 ESAPI의 보안기능 등)를 사용하는 것이 중요하다.

 

3) 코드예제 : 회원정보 수정시 수정을 요청한 사용자와 로그인한 사용자의 일치 여부를 확인하지 않고 처리하고 있다.

 

- 안전하지 않은 코드의 예

if (service.modifyMember(memberModel)) {

mav.setViewName(“redirect:/board/list.do”);

session.setAttribute(“userName”, memberModel.getUserName());

return mav

}

 

- 안전한 코드의 예

if (userId != null && requestUser != null && !userId.equals(requestUser)) {

mav.addObject(“errCode”, 1);

mav.addObject(“member”, memberModel);

mav.setViewName(“/board/member_modify”);

return mav

}

 

4) Burp Suite 이용한 점검

 

 

아래 링크를 통해 Secure Coding 3편의 내용을 확인하실 수 있습니다.

▶ Secure Coding 메뉴얼 3편

 


 

 

'백엔드' 카테고리의 다른 글

2020 보안기술 개발 동향  (0) 2020.06.04
Secure Coding 메뉴얼 3편  (0) 2019.11.18
Secure Coding 메뉴얼 2편  (0) 2019.11.11
Secure Coding 메뉴얼 1편  (0) 2019.11.04
사내 IaaS 구축하기  (0) 2018.06.25
Private Cloud 구축을 위한 DC/OS 설치  (0) 2018.02.06

New Multi-Channel Dynamic CMS

Secure Coding 메뉴얼 1편

1. 개요

 

소프트웨어 개발 보안

 

[배경]

- 인터넷상 공격의 약 75%는 SW보안취약점을 악용하는 것으로, 특히 외부에 공개되어 불특정 다수를 대상으로 사용자 정보를처리하는 Web Application 취약점으로 인한 중요 정보가 유출되는 침해 사고가 빈번하게 발생하고 있음

- 미국의 경우 국토안보부를 중심으로 시큐어코딩을 포함한 SW개발 전 과정에 대한 보안 활동 연구를 활발히 진행

- 국내의 경우 행안부 시큐어코딩이 적용되는 대상 언어는 JAVA, C, 안드로이드 이며, 소프트웨어 업체는 SQL삽입, 크로스사이트스크립트 등 43개의 보안 취약점을 제거해야 함

- 2017년 정보 시스템 등급별 보안 관리 가이드라인을 개발하였으며 2018년 3월에는 정보 시스템 등급제 적용 근거를 행안부 고시인 ‘정보 시스템 구축.운영 지침’에 포함하였음

- 전자금융감독 규정에 의거하여 금융보안원에서 자동진단솔루션 및 수동 점검을 통해 반기별 공개용 웹 서비스 모의 해킹을 지원하고 있음

 

[보악 취약점 발생 원인]

- 보안 요구 사항이 정의되지 않음

- 논리적인 오류를 가지는 설계를 수행하여 개발됨

- 기술 취약점을 가지는 코딩 규칙을 적용

- 소프트웨어 배치가 적절하지 않음

- 발견된 취약점에 대해 적절한 관리 또는 패치를 하지 않은 경우

 

1.1 용어 정의

용어 설명
Secure Coding 개발하는 과정에서 코딩 시에 개발자의 실수나 오류, 취약점이 삽입되지 않도록 프로그래밍하여 사이버 공격을 차단하기 위한 작업
유효성 검증 포맷 또는 규칙의 일치 여부를 확인하는 작업
기밀성 인가된 사용자만 정보 자산에 접근할 수 있는 것을 의미
CAPTCHA HIP(Human Interaction Proof) 기술의 일종으로 어떠한 사용자가 실제 사람인지 컴퓨터 프로그램인지 구별하기 위해 사용되는 방법
LDAP TCP/IP 위에서 디렉터리 서비스를 조회하고 수정하는 응용 프로토콜
평문전송 일반인 누구나 읽을 수 있는 문서로 암호화되지 않은 내용 또는 암호문에 해독된 내용
HTTPS HTTP의 Secure Socket 으로 공개키 암호화 방식이며 정보를 암호화 하는 SSL프로토콜을 이용하여 서버와 데이터를 주고 받는 통신 규약
DES 알고리즘 DES(Data Encryption Standard)암호는 암호화 키와 복호화 키가 같은 대칭키 암호로 64bit 블록의 암호화 알고리즘
AES AES(Advanced Encryption Standard) 미국 정부 표준으로 지정된 대칭 알고리즘. 암호 블록의 크기는 128bit 이며 알고리즘 변경 없이 256bit 까지 확장 가능하며 미국 표준 기술 연구소가 5년의 표준화 과정을 거쳐 연방 정보처리 표준으로 발표하였음
솔트 암호화 전에 문자열의 앞뒤로 난수를 생성하여 특정 문자열을 끼워 넣고, 해시를 돌려 원문을 변조하는 것
SHA 해시 알고리즘의 일종으로 MD5의 취약성을 대신하여 사용 (TLS, SSL, PGP, SSH, IPSec 등에서 사용)
Cross Site Scripting XSS라고 하며 검증되지 않은 값으로 인해 웹 브라우저에 의도하지 않은 스크립트가 실행되는 취약점
Format string 데이터의 형태와 길이에 대한 불명확한 정의로 인한 취약점

 

1.2 관련 법규

 

보안 식별의 내부 항목은 개인정보보호규정, 정보보안관련규정을 준수하고, 외부 환경 분석(법, 제도, 규정) 등을 통한 보안 식별은 개인정보보호법, 정보통신망법, 금융거래법 등, 법령, 관련지침 등을 기준으로 한다. 현재 시스템에서 처리하는 정보 중 중요 정보로 분류되어 있는 대부분은 개인정보이다.

 

개인정보보호법

조항 주요 내용
제 24조(고유식별정보의 처리제한) 3항 고유식별정보(주민번호, 여권번호, 운전면허번호, 외국인등록번호)를 처리하는 경우 그 정보가 분실, 도난, 유출, 변조 또는 훼손되지 않도록 암호화 등 안전성 확보에 필요한 조치를 해야 한다.
제 29조(안전조치의무화) 개인정보가 분실, 도난, 유출, 변조 또는 훼손되지 않도록 내부관리 계획 수립, 접속기록보관 등 안전성 확보에 필요한 기술적, 관리적, 물리적 조치를 해야 한다.
시행령 제 30조(개인정보의 안전성 확보조치) 1항 제 3호 및 제3항 개인정보를 안전하게 저장, 전송할 수 있는 암호화 기술의 적용 또는 이에 상응하는 조치를 해야 한다.

 

정보통신망 이용 촉진 및 정보보호 등에 관한 법률

조항 주요 내용
시행령 제 15조(개인정보의 보호조치)

-개인정보가 안전하게 저장, 전송될 수 있도록 다음과 같이 보안 조치를 하여야 한다.

-비밀번호 및 바이오정보(지문,홍채,음성,필적 등) 일방항 암호화 저징

-주민등록번호 및 계좌번호 등 금융정보의 암호화 저장

-개인정보 및 인증정보를 송.수신하는 경우 보안서버 구축 등의 조치

-그박의 암호화 기술을 이용한 보안 조치

법률 제 28조(개인정보의 보호조치)

-개인정보를 취급할 때에는 개인정보의 분실, 도난, 누출, 변조 또는 훼손을 방지하기 위해 기술적, 관리적 조치를 하여야 한다.

-개인정보를 안전하게 저장, 전송할 수 있는 암호화 기술 등을 이용한 보안조치

개인정보의 기술적, 관리적 보호조치 기준 제 6조(개인정보의 암호화)

-비밀번호, 바이오정보는 복호화되지 않도록 일바향 암호화하여 저장한다.

-주민등록번호, 신용카드번호 계좌번호에 대해서는 안전한 암호화 알고리즘 등으로 암호화하여 저장한다.

-웹서버에 SSL 인증서를 설치하여 전송하는 정보를 암호화하여 송.수신

-웹서버에 암호화 응용프로그램을 설치하여 전송하는 정보를 암호화하여 송.수신하는 기능

제 50조 1항(소프트웨어 개발 보안 원칙)

① 행정기관등이 영 제71조제1항에 해당하는 정보화 사업을 추진할 때에는 별표3의 소프트웨어 보안 약점이 없도록 소프트웨어를 개발
또는 변경  (이하 ‘소프트웨어 개발 보안’이라 한다) 하여야 한다.

② 제 1항에 따라 행정기관 등의 장이 정보화 사업 추진 시 적용해야 할 소프트웨어 개발 보안의 범위는 다음 각 호와 같다.

    1. 신규 개발의 경우 : 설계 단계 산출물 및 소스 코드 전체

    2. 유지 보수의 경우 : 유지 보수로 인해 변경된 설계 단계 산출물 및 소스 코드 전체

 

③ 제2항에 따라 소프트웨어 개발 보안 적용 시 상용 소프트웨어는 제외한다.

제 50조 2항(소프트웨어 개발 보안 업무의 위탁)

행정안전부장관은 보안 약점 진단, 이행 점검, 진단원 양성 등 소프트웨어 개발 보안 관련 업무의 일부를 한국인터넷진흥원 또는

한국전자통신연구원 부설 국가보안기술연구소 (이하 “국가보안기술연구소"라 한다)에 위탁할 수 있다.

제 51조(소프트웨어 개발 보안 활동)

① 행정기관 등의 장은 제안서 평가시 소프트웨어 개발보안을 위한 소프트웨어 보안 약점 진단도구 사용 여부, 개발  절차와 방법의 적절성, 제3항에 의한 교육 계획의 적정성 등을 확인하고 평가에 반영할 수 있다.

② 사업자는 제50조에 따라 소프트웨어 개발 보안을 적용하는 경우 행정안전부장관이 국가정보원장과 협의하여 공지하는 ‘소프트웨어
개발 보안 가이드‘를 참고할 수 있다.

③ 사업자는 정보화사업 착수 단계에서 ‘소프트웨어 개발 보안가이드'등 소프트웨어 개발보안 관련 교육을 실시하고 이후 투입되는 인력은 개발에 투입하기 전 소프트웨어 개발보안 관련 교육을 실시하여야 한다.

제 52조(보안 약점 진단 기준) 행정기관등 장은 소프트웨어 보안약점을 진단할 때 별표3의 소프트웨어 보안약점을 필수 진단 항목으로 포함하여야 한다.
제 53조(보안 약점 진단 절차)

① 행정 기관등의 장은 정보화사업 감리를 수행하는 경우, 감리법인으로 하여금 사업자가 별표3의 소프트웨어 보안약점을 제거하였는지
진단하도록 하여야 한다.

② 감리 법인은 제 1항에 따라 소프트웨어 보안약점을 진단할 경우 행정안전부장관이 고시한 “정보시스템 감리기준“ 제10조제1항의 세부
검사 항목에 소프트웨어 보안약점 제거 여부를 포함하여야 한다.

③ 감리법인은 소프트웨어 보안약점을 진단할 경우 행정안전부 장관이 고시한 “정보시스템 감리기준“ 제5조제3항에 따라 제54조의 진단원을 우선적으로 배치할 수 있다.

④ 감리 법인이 소프트웨어 보안약점 진단 과정에서 소프트웨어 보안 약점 진단 도구를 사용할 경우에는 과학 기술 정보통신부 장관이 고시한 “정보 보호시스템 평가 인증 지침"에 따라 국가보안기술연구소장이 인증한 보안약점 진단도구를 사용하여야 한다. 이 경우, 감리 법인은
보안 약점 진단 도구가 지원하는 진단 항목이 별표3의 소프트웨어 보안약점을 진단하는지 여부를 확인하여야 한다.

⑤ 행정 기관등 장은 영 제71조제1항에 해당하지 않는 정보화 사업에 소프트웨어 개발 보안을 적용할 경우에는 사업자로 하여금 진단 제거
토록하고 그 결과를 확인할 수 있다.

제 53조 2항(개발 보안 자료 요청 등)

행정안전부 장관은 개발 보안 제도 개선 및 적용 현황을 확인하기 위하여 행정기관 등의 장에게 자료 요청 및 현장 방문을 실시할 수 있다.

이 경우 행정 기관 등의 장은 특별한 사유가 없는 한 이에 응해야 한다.

제 54조(진단원)

① 행정안정부장관은 별표4 제1호 진단원의 자격 기준을 만족하고 별표4 제2호의 교육을 이수한 자에게 진단원 자격을 부여한다.

② 행정안정부장관은 제1항과 관련하여 진단원 및 행정 기관 등의 요청이 있을 경우 진단원 자격 유무를 확인해 줄 수 있다.

 

1.3 기타

 

국제 기준안 및 참고사이트

가이드명 설명 url
OWASP Top10 (Open Web Application Security Project) 국제 웹 보안 표준기구로 정기적으로 웹 해킹 위협의 동향을 발표

https://www.owasp.org

CWE/SANS 25 SANS와 미국방성 산하 MITRE 그리고 그 외 미국 및 유럽의 여러 소프트웨어 보안 전문가에 의해 CWE/SANS 25라는 이름으로 소프트웨어 개발자가 가장 범하기 쉬운 코드 취약점에 대해 발표 740여 가지의 다양한 언어에 대한 취약점을 권고하고 관리하고 있음

https://www.sans.org/top25-software-errors/

 CERT SecureCoding 미국 국토안보부 산하 컴퓨터 긴급대응팀, 국가 사이버 경보 시스템, 취약 정보 등 제공

https://www.securecoding.cert.org/

CWE (Common Weakness Enumeration) 발견된 정적분석 취약점을 CWE-ID로 넘버링 포맷이 되어 있는 DB 수록

http://cwe.mitre.org

 

2. 보안 항목

 

2.1 기능에 대한 보안 항목

 

분석·설계 단계에서 정보처리 시스템의 각 기능을 안정하게 서비스하기 위해 필요한 보안 요구 사항

 

  • 입력 데이터 검증 및 표현
번호 항목명 설명 비고
SR1-1 DBMS 조회 및 결과 검증 DBMS 조회를 위한 질의문 생성시 사용되는 입력값과 조회결과에 대한 검증방법 설계 및 유효하지 않은 값에 대한 처리방법 설계 입·출력값 검증
SR1-2 XML 조회 및 결과 검증 XML 조회를 위한 질의문 생성시 사용되는 입력값과 조회결과에 대한 검증방법 설계 및 유효하지 않은 값에 대한 처리방법 설계
SR1-3 디렉터리 서비스 조회 및 결과 검증 디렉터리 서비스 조회시 사용되는 입력값과 조회결과에 대한 검증방법 설계 및 유효하지 않은 값에 대한 처리방법 설계
SR1-4 시스템 자원 접근 및 명령어 수행 입력값 검증 시스템 지원접근 및 명령어 수행을 위해 사용되는 입력 값에 대한 유효성 검증방법과 유효하지 않은 값에 대한 처리방법 설계
SR1-5 웹 서비스 요청 및 결과 검증 웹 서비스 요청과 응답결과에 대한 검증방법과 적절하지 않은 데이터에 대한 처리방법 설계
SR1-6 웹 기반 중요기능 수행요청 유효성 검증 사용자 권한확인이 필요한 중요기능에 대한 웹 서비스 요청에 대한 유효성 검증방법과 유효하지 않은 요청에 대한 처리방법 설계
SR1-7 HTTP 프로토콜 유효성 검증 비정상적인 HTTP 헤더, 자동연결 URL 링크 등 사용자가 원하지 않은 결과물 생성할 수 있는 HTTP 헤더 및 응답결과에 대한 유효성 검증방법과 유효하지 않은 값에 대한 처리방법 설계
SR1-8 허용된 범위내 메모리 접근 허용된 범위의 메모리 버퍼에만 접근하여 저장 또는 읽기가 수행되어 버퍼오버플로우가 발생하지 않도록 처리방법 설계
SR1-9 보안기능 동작에 사용되는 입력값 검증 보안 기능 동작을 위해 사용되는 입력값과 함수 의 외부입력값 및 수행결과에 대한 처리방법 설계
SR1-10 업로드 · 다운로드 파일 검증 업로드 · 다운로드 파일의 무결성, 실행권한 등에 관한 유효성 검사 방법을 설계하고, 검사 실패시 대응방안 설계 파일 관리

 

  • 보안기능

인증, 접근통제, 권한관리, 비밀번호 등의 정책이 적절하게 반영될 수 있도록 설계

 

번호 항목명 설명 비고
SR2-1 인증 대상 및 방식 중요정보 · 기능과 인증방식을 정의하고, 정의된 중요정보 접근 및 중요기능 수행 허용을 위해 인증 기능이 우회되지 않고 수행 될 수 있도록 설계 인증 관리
SR2-2 인증 수행 제한 인증 반복시도 제한 및 인증실패 등에 대한 인증제한 기능 설계
SR2-3 비밀번호 관리 안전한 비밀번호 조합규칙을 설정하고, 안전한 저장 정책, 재설정 및 변경 정책, 패스워드 관리 규칙이 적용 되도록 설계
SR2-4 중요자원접근통제 중요자원을 정의하고, 정의된 중요자원에 대한 접근을 통제하는 신뢰할 수 있는 방법 및 접근통제 실패시 대응방안 설계 권한 관리
SR2-5 암호키 관리 암호키 생성, 분배, 접근, 파기 등 안전하게 암호키 생명주기를 관리할 수 있는 방법 설계 암호화
SR2-6 암호 연산 국제표준 또는 검증필 프로토콜로 등재된 안전한 암호 알고리즘을 선정하여 충분한 암호키 길이, 솔트, 충분한 난수값을 기반으로 암호연산 수행방법 설계
SR2-7 중요정보 저장 중요정보 저장시 안전한 저장 및 관리 방법 설계 중요 정보 처리
SR2-8 중요정보 전송 중요정보 전송시 안전한 전송방법 설계

 

  • 에러 처리

에러 또는 오류상황을 처리하지 않거나 불충분하게 처리되어 중요 정보 유출 등 보안 약점이 발생하지 않도록 설계

번호 항목명 설명 비고
SR3-1 예외처리 오류메시지에 중요정보가 포함되어 출력되거나, 에러 및 오류가 부적절하게 처리되어 의도치 않은 상황이 발생하는 것을 막기 위한 안전한 방안 설계  

 

  • 세션통제

다른 세션간 데이터 공유 금지 등 세션을 안전하게 관리할 수 있도록 설계

 

번호 항목명 설명 비고
SR4-1 세션통제 다른 세션간 데이터 공유금지, 세션 ID 노출금지, 로그인시 세션ID 변경, 세션종료 처리 등 세션을 안전하게 관리할 수 있는 방안 설계  

 

[구현 단계 보안약점과 분석·설계 단계의 보안 요구 항목의 연관 관계]

구분 분석·설계 단계의 보안 요구 항목 구현 단계 보안 약점

입력 데이터

검증 및 표현

SR1-1 DBMS 조회 및 결과 검증 SQL
SR1-2 XML 조회 및 결과 검증 XQuery 삽입, XPath 삽입
SR1-3 디렉터리 서비스 조회 및 결과 검증 LDAP 삽입
SR1-4 시스템 자원 접근 및 명령어 수행 입력 값 검증 경로조작 및 자원삽입, 운영체제 명령어 삽입
SR1-5 웹 서비스 요청 및 결과 검증 크로스사이트 스크립트
SR1-6 웹 기반 중요 기능 수행 요청 유효성 검증 크로스사이트 요청 위조
SR1-7 HTTP프로토콜 유효성 검증 신뢰되지 않은 URL 주소로 자동접속 연결, HTTP 응답분할
SR1-8 허용된 범위 내 메모리 접근 검증 포멧스트링 삽입, 메모리 버퍼 오버플로우
SR1-9 보안기능 동작에 사용되는 입력값 보안기능 결정애 사용되는 부적절한 입력값, 정수형 오버플로우, Null Pointer 역참조
SR1-10 업로드 · 다운로드 파일 검증 위험한 형식 파일 업로드, 무결성 검사 없는 코드 다운로드
보안 기능 SR2-1 인증대상 및 방식 적절한 인증 없는 중요 기능 허용, DNS lookup에 의존한 보안 결정
SR2-2 인증수행 제한 반복된 인증 시도 제한 기능 부재
SR2-3 비밀번호 관리 하드 코드 된 비밀 번호, 취약한 비밀 번호 허용
SR2-4 중요자원 접근통제 부적절한 인가, 중요한 자원에 대한 잘못된 권한 설정
SR2-5 암호키 관리 하드 코드 된 암호화 키, 주석문 안에 포함된 시스템 주요 정보
SR2-6 암호연산 취약한 암호화 알고리즘 사용, 충분하지 않은 키 길이 사용, 적절하지 않은 난수 값 사용, 솔트 없이 일방향 해시 함수 사용
SR2-7 중요정보 저장 중요 정보 평문 저장, 사용자 하드 디스크에 저장되는 쿠키를 통한 정보 노출
SR2-8 중요정보 전송 중요 정보 평문 전송
에러처리 SR3-1 예외처리 오류 메시지를 통한 정보 노출, 시스템 데이터 정보 노출
세션통제 SR4-1 세션통제 잘못된 세션에 의한 데이터 정보 노출

 

 

아래 링크를 통해 Secure Coding 메뉴얼 2편의 내용을 확인하실 수 있습니다.

▶ Secure Coding 메뉴얼 2편

▶ Secure Coding 메뉴얼 3편

 


 

 

New Multi-Channel Dynamic CMS

사내 IaaS 구축하기

1 오픈스택이란

IT 개발자로 일을 하다 보면 클라우드 컴퓨팅이란 단어는 한번쯤 들어 보셨을 겁니다. 클라우드 컴퓨팅이란 쉽게 말해 네트워크가 가능한 디바이스를 통해 클라우드라는 공간에서 데이터를 읽고 처리하고 관리하는 시스템을 말합니다.

클라우드 컴퓨팅의 종류로는 서비스에 따라 IaaS, PaaS, SaaS로 구분됩니다.

IaaS(Infrastructure as a Service)는 서버, 스토리지, 네트워크를 가상화 시켜 필요한만큼 인프라 자원을 사용할 수 있게 제공하는 서비스입니다. AWS(Amazon Web Service)를 생각하면 됩니다.

PaaS(Platform as a Service)는 개발을 위한 플랫폼이 미리 구축되어 있고 이 플랫폼 위에서 개발 및 배포를 

게 해주는 서비스를 말합니다. 정의를 내리기 까다로운 형태인데, 가장 유사한 서비스로는 Google App 

Engine 정도가 있습니다.

SaaS(Software as a Service)는 클라우드 상에서 서비스되고 있는 소프트웨어를 말하며, 사용자가 웹이나 앱으로 사용가능한 형태의 서비스입니다. Dropbox, Google Docs 등 수많은 소프트웨어가 있습니다.

오픈스택이란 간단히 말해 오픈소스로 이루어진 IaaS 구축 플랫폼입니다.

2010 7 RackspaceNASA가 같이 시작한 오픈소스 프로젝트로써 리눅스 OS 위에서 IaaS를 구축할 수 있도록 가상화를 지원하고 CLI 및 대시보드로 관리할 수 있도록 해줍니다.

많은 세부 프로젝트로 구성되어 있는 오픈소스 프로젝트이며 그 중 6개의 중요한 세부 프로젝트가 IaaS를 구축할 수 있게 도와줍니다.

 Nova

 서버의 가상화를 지원하고 관리

 Neutron

 네트워크 가상화를 지원하고 관리(Software Define Network)

 Swift

 Restful API로 오프젝트 스토리지 지원

 Glance

 서버 가상화에 필요한 OS 이미지 관리

 Keystone

 프로젝트 및 가상화 인증 관리

 Cinder

 블록 디바이스의 볼륨을 관리

오픈스택 시스템을 잘 다루기 위해선 각 프로젝트별로 논리 아키텍처를 이해를 하고 바탕이 되는 많은 기술들의 이해가 필요합니다. 하이퍼바이저, 오브젝트 스토리지 등 기술적 이해가 많이 필요하나 최근에 들어선 잘 다듬어진 대시보드로 인해 많이 어렵지 않게 사용 가능해졌습니다.


2 오픈스택 설치

사내 IaaS 구축을 위해 오픈스택을 설치해보도록 하겠습니다.

기본으로는 오픈스택을 각 프로젝트별로 설치하는 것이 정석이나 이 과정을 한번에 처리해주는 솔루션들이 있습니다. 대표적으로 devstack, packstack, trystack 등이 있습니다. 그 중 RedHat이 지원하는 RDO 프로젝트에서 만든 packstack으로 설치해보겠습니다.

Centos7 설치와 구성

Centos7을 설치할 때 일반적으로 설치할 때와 동일하게 설치하나 packstack을 위해 세 가지만 유의하면 됩니다.

1)   파티션을 자동으로 하지않고 수동 파티션으로 한 후 /home의 용량을 / 로 이관.

openstack은 가상화된 서버 인스턴스를 /var/lib/nova 밑의 디렉토리에 보관합니다. 따라서 해당 디렉토리의 용량이 충분하지 못하면 볼륨 생성이 불가능하여 가상 서버를 만들지 못하게 됩니다. Centos 설치 시 자동으로 파티션하게 되면 /home에 대부분의 용량을 할당하게 되므로 이를 /로 어느 정도 옮겨야 합니다.

2)   IP dhcp를 통해 자동으로 얻어오지않고 static으로 설정.

/etc/sysconfig/network-scripts/ifcfg-enp3s0 의 내용을 아래처럼 수정합니다.

  BOOTPROTO=static

  IPADDR=192.168.0.69

  NETMASK=255.255.255.0

  GATEWAY=192.168.0.1

  DNS1=192.168.0.1

  ONBOOT=yes

packstack 설치 시 정적 IP로 설정되어 있지않으면 오류 문구를 보여주며 설치가 진행되지 않습니다. 이를 정적 설정으로 변경해주면 정상 설치 됩니다.

3)   리눅스 방화벽 비활성화

  systemctl disable firewalld

  systemctl stop firewalld

  systemctl disable NetworkManager

  systemctl stop NetworkManager

  systemctl enable network

  systemctl start network

리눅스 자체 방화벽이 있는 경우, 오픈스택의 restful api가 정상 동작 하지않을 수 있습니다. 이를 비활성화 하고 오픈스택 설치 후 오픈스택의 의 보안 정책을 사용하도록 합니다.

packstack 설치

1) Software Repository 업데이트

packstackyum을 통하여 설치할 것입니다. 기본 Repository에는 packstack이 없으니 추가해줍니다.

  yum install -y https://rdoproject.org/repos/rdo-release.rpm

  yum update -y

2) packstack 설치

  yum install -y openstack-packstack

3) 네트워크 구성도 설계

이제 packstack을 이용하여 오픈스택을 설치할 준비를 마쳤습니다. 하지만 그 전에 가장 중요한 네트워크 구성도를 그려보겠습니다.

네트워크 구성도를 그려서 이해하지 않으며 오픈스택 설치 후 가상화된 서버와의 통신이 원활하지 않는 경우가 많기 때문입니다.

공유기를 통해 인터넷을 사용하는 보편적인 네트워크 망에서 오픈스택 네트워크 구성도를 그려봤습니다. 여기서 중요한 것은 네트워크 타입을 OVSPort OVSBridge로 이용하여 물리적 이더넷 포트인 enp3s0를 브릿지 포트로 지정된 br-ex와 연결하여 오픈스택의 가상 서버들이 실제 인터넷과 연결되도록 해야 합니다.

이 작업은 원래 리눅스의 이더넷 조정 및 openstack 설치 후 neutron config를 수정하는 추가 작업이 필요하나 packstack을 통해 설치하면 한번에 처리가 됩니다.

4) 오픈스택 설치

네트워크 구성이 적용되도록 오픈스택을 설치합니다. 설치, 기본 구성, 테스트까지 진행함으로 시간이 오래 걸립니다.

packstack --allinone --provision-demo=n --os-neutron-ovs-bridge-mappings=extnet:br-ex --os-neutron-ovs-bridge-interfaces=br-ex:enp3s0 --os-neutron-ml2-type-drivers=vxlan,flat

설치가 종료되면 기존의 enp3s0의 내용이 변경되고 br-ex가 생긴 것을 볼 수 있습니다.

  /etc/sysconfig/network-script/ifcfg-enp3s0

  DEVICE=enp3s0

  TYPE=OVSPort

  DEVICETYPE=ovs

  OVS_BRIDGE=br-ex

  ONBOOT=yes


  /etc/sysconfig/network-script/ifcfg-br-ex

  DEVICE=br-ex

  DEVICETYPE=ovs

  TYPE=OVSBridge

  BOOTPROTO=static

  IPADDR=192.168.0.70

  NETMASK=255.255.255.0

  GATEWAY=192.168.0.1

  DNS1=192.168.0.1

  ONBOOT=yes

5) 대시보드 접속

http://serverIp 로 접속하면 오픈스택 대시보드로 접속이 가능합니다.

기본 계정 정보는 /root 디렉토리의 packstack 설치 후 생성되는 keystonerc_admin 파일을 열어보면 정보가 있습니다.

  unset OS_SERVICE_TOKEN

      export OS_USERNAME=admin

      export OS_PASSWORD='21997a54d23c4773'

      export OS_AUTH_URL=http://192.168.0.69:5000/v3

      export PS1='[\u@\h \W(keystone_admin)]\$ '

 

  export OS_PROJECT_NAME=admin

  export OS_USER_DOMAIN_NAME=Default

  export OS_PROJECT_DOMAIN_NAME=Default

  export OS_IDENTITY_API_VERSION=3

6) 사용자 계정 및 프로젝트 생성

인증 > 프로젝트, 인증 > 사용자 화면을 이용하여 원하는 사용자 계정을 생성합니다.

대시보드가 잘 되어 있어 따로 설명하지는 않겠습니다.


Neutron 네트워크 구성

대시보드 접속하면 먼저 네트워크 구성을 해줘야 합니다. 그래야 설치 전 그렸던 네트워크 구성도대로 통신이 이루어집니다.

먼저 admin 계정으로 외부 네트워크를 생성해 줍니다.

관리 > 네트워크 > 네트워크 화면에 접속하여 네트워크 생성 버튼을 클릭합니다.

아래와 같이 진행합니다.

생성 버튼을 클릭하여 생성하면 아래와 같이 인터넷망과 연결된 외부 네트워크가 생성된 걸 볼 수 있습니다.

이제 사용자 계정으로 접속하여 사설 네트워크를 생성합니다.

프로젝트 > 네트워크 > 네트워크 화면으로 들어가 아래와 같이 진행합니다.

이제 외부 네트워크가 사설 네트워크를 연결해주는 라우터를 생성하겠습니다.

프로젝트 > 네트워크 > 라우터 화면으로 들어가 라우터 생성 버튼을 클릭하여 아래와 같이 외부네트워크를 선택하고 생성합니다.

생성된 라우터를 클릭하여 세부 화면으로 들어가 인터페이스 탭을 클릭합니다.

인터페이스 추가 버튼을 클릭하여 방금 생성한 사설 네트워크를 연결합니다.

이제 프로젝트 > 네트워크 > 네트워크 토폴로지 화면으로 들어가 네트워크 구조가 정상적으로 생성됐는지 확인합니다.


정상적으로 네트워크가 구성된 걸 볼 수 있습니다.

하지만 아직 한가지 작업이 남아 있습니다. 네트워크 생성 시 서브넷 세부 사항을 보면 Pool 주소 할당 부분이 있습니다. 내부 사설 네트워크의 경우 굳이 설정해주지 않아도 문제가 따로 발생하지 않으나 외부 네트워크의 경우 공유기의 dhcp 서버랑 충돌이 생겨 내부 가상 서버에 Floating IP 할당이 되지않아 외부 접근이 불가능한 경우가 있습니다. 따라서 Pools을 부분을 공유기의 dhcp 할당 범위에서 벗어난 범위로 지정해 주어야합니다. 화면에서 보듯이 현재는 90번부터 99번까지 할당되도록 설정을 했습니다. 공유기 역시 관리 기능을 이용하여 충돌이 나지 않도록 설정해 주어야 합니다.

이것까지 완료하면 네트워크 구성은 완전히 마쳤습니다.


Glance 이미지 추가

이제 가상 서버를 생성하기 위해 OS 이미지를 추가해보겠습니다.

오픈스택에 사용되는 OS 이미지는 기존의 물리적으로 설치하는 이미지와 다르게 cloud image로 각 OS 메이커에서 따로 배포되고 있습니다.

VM으로 생성할 이미지는 ubuntu server로 받아보겠습니다.

리눅스 서버에서 wget을 이용하여 이미지를 받습니다.

wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img

현재 ubuntu 이미지는 etc/hosts 파일에 자동으로 lock이 걸려있어 hostname DNS Server 처리를 못하는 버그가 있어 이것을 수정해야 합니다.

virt-edit -a xenial-server-cloudimg-amd64-disk1.img /etc/cloud/cloud.cfg

사용법은 vi와 동일합니다.

manage_etc_hosts: true

줄에 위의 문구를 삽입 후 저장하고 나옵니다.

그리고 변경된 이미지를 FTP를 통해 작업 PC로 내려받습니다.

대시보드에 접속하여 프로젝트 > Compute > 이미지 화면으로 이동합니다.

이미지 생성 버튼을 눌러 아래와 같이 기입 후 이미지를 생성합니다.

이미지가 생성되면 아래와 같이 생성된 이미지를 볼 수 있습니다.

Nova 인스턴스(가상 서버) 생성

이미지까지 업로드를 했으니 이제 가상 서버를 만들어 보도록 하겠습니다. 오픈스택 내에서는 가상 서버를 인스턴스라고 부릅니다.

먼저 생성 이후 외부 접근을 위해 키 페어를 만들어 둡니다.

프로젝트 > Compute > 키 페어 화면으로 들어가 키 페어를 생성합니다.

생성과 동시에 keypair.pem을 다운로드 받게 됩니다. 해당 key를 저장해 놓습니다.

프로젝트 > Compute > 인스턴스로 들어가 인스턴스 생성 버튼을 클릭합니다.

이름을 지정합니다.

이미지를 선택합니다.

가상서버에 얼만큼 자원을 할당할 건지 미리 정해놓은 세트에서 선택합니다. m1.small을 선택하여 가상 CPU1개 디스크 볼륨을 20GB로 잡습니다.

내부 네트워크 부분을 설정합니다.

생성한 키 페어로 설정합니다.

이제 인스턴스 시작을 눌러 인스턴스를 생성합니다.

몇 가지 내부 작업을 실행하고 내부 IP를 부여한 후 인스턴스가 생성되었습니다.

인스턴스명을 클릭하여 들어가면 개요, 로그 및 콘솔 등으로 인스턴스를 확인할 수 있습니다.

인스턴스 외부 접근 설정(Floating IP)

인스턴스 생성까지 진행했지만 VNC Console로 서버가 구동된 것을 확인했을 뿐 해당 서버에 직접 작업이 가능한 상태가 아닙니다.

따라서 외부에서도 접근하고 ssh를 이용할 수 있도록 설정합니다.

먼저 프로젝트 > 네트워크 > Floating IP로 들어가 프로젝트에 IP 할당 버튼을 클릭합니다.

외부에서 프로젝트 내의 인스턴스에 접근할 수 있도록 유동 IP를 할당 받는 작업입니다.

아래처럼 96IP를 할당 받았습니다.

오른쪽의 작업의 연결 버튼을 클릭하여 인스턴스랑 연결시켜 줍니다.

인스턴스 화면에서 유동 IP가 연결된 것을 볼 수 있습니다.

외부 접근이 가능하게 하려면 하나 더 작업을 해야 합니다. 바로 보안 정책입니다.

프로젝트 > 네트워크 > 보안 그룹 화면에 들어갑니다.

현재 Default 정책이 하나 있는데 규칙 관리 버튼을 클릭합니다.

규칙 추가를 눌러 ping과 관련된 ICMPSSH TCP 프로토콜을 열어 줍니다.

이제 로컬 PC에서 커맨드 창을 열어 외부에서 접속이 되는지 확인합니다.

ping 192.168.0.96

외부에서 정상적으로 ping이 가는 것을 볼 수 있습니다.

마지막으로 다운로드 받은 keypair.pem 파일을 이용하여 ssh에 접속해보겠습니다.

ssh -i keypair.pem ubuntu@192.168.0.96

SSH까지 접속이 되는 것을 확인했습니다.

마지막으로 인스턴스 안에서 인터넷이 연결되는 것을 확인해 보겠습니다.

wget google.com

index.html 파일을 잘 받아오는 것을 확인할 수 있습니다.


사내 IaaS 구축 진행과정 설명을 마치도록 하겠습니다.

감사합니다. 



New Multi-Channel Dynamic CMS

Private Cloud 구축을 위한 DC/OS 설치

 

 

DC/OS 관련돼서 아티클을 연재하고 있습니다. 이번 글에서는 DC/OS 의 설치과정에 꼭 필요한 핵심 정보 및 설치과정에 대해 알려드리도록 하겠습니다.

DC/OS는 설치방법은 크게 3가지가 있습니다. 개발용으로 개인PC에 설치하는 방법, Amazon,이나 Azure와 같은 Cloud 기반에 설치하는 방법, 그리고 마지막으로 사내 Private Cloud 환경 구축을 위한 On-premises 설치방법 입니다.

현재 DC/OS 버전은 1.10 버전이 최신이며 이번 아티클은 사내 Private Cloud 환경을 구성하는 위한 방법으로 설치해 보도록 하겠습니다.

 

전체적인 상세 설치 매뉴얼은 아래 URL을 참조하면 됩니다.

https://docs.mesosphere.com/1.10/installing/oss/

이 아티클은 매뉴얼 대체 목적이 아닌 핵심적인 주요 사항에 대해서만 알려드리며 별도의 추가사항 및 경험상 매뉴얼대로 안되었던 부분에 대한 설명이 들어가 있으면 이점 유의해서 확인해 보시고 설치해 보면 좋겠습니다.

 

Hardware Requirements

DCOS를 설치하기 크게 3가지중 한가지 역할을 맡기 위한 서버가 필요합니다. DC/OS운영을 위한 최소 서버설치대수는 3대라는 의미입니다.

 

Master nodes

 마스터 노드는 여러 Agent 노드의 교통정리를 하는 역할을 합니다. 실질적인 작업은 각 Agent node에서 수행이 되며, Agent 노드에 문제가 발생하거나 자원 재할당이 필요한 경우, 그리고 각종 주요 설정정보를 보관하고 있는 역할을 하는 서버가 Master node 역할입니다.

기본적으로 1대부터 시작할 수 있지만, 추천 대수는 3대입니다. Master node는 기본적으로 왕 역할을 하는 서버는 동작중인 master node 중 한대만 하기 때문에 왕선출을 위해 홀 수 개수의 서버를 준비해야 합니다.

 

되도록 가지고 있는 서버 중 안정적이며, CPU/RAM 자원이 충분한 서버를 Master 서버로 이용하면 됩니다. HDD 자원은 로그성만 기록되기 때문에 큰 용량의 HDD는 필요 없습니다.

 

Agent nodes

실질적으로 작업(work, process)을 하는 노드입니다. 따라서 성능이 좋으면 좋을수록 좋겠지만, 꼭 성능이 좋지 않아도 ,Master node에서 적절히 자원을 분배해 주기 때문에 2core CPU 에 메모리 16G이상만 되면 충분히 이용할 수 있습니다. 매뉴얼 상으로는 최소 16G RAM이 최소사양인데 8G만 되어도 최소 역할 수행은 가능합니다.

Docker 기반의로 각 프로세스가 실행되기 때문에 Docker Host 역할로 문제가 없는 하드웨어 사양이라면 큰 문제가 없습니다.

Hadoop(HDFS)이나 Apache Spark 와 같은 CPU RAM을 많이 사용하는 process라면 8core 이상에 32G RAM 이상을 추천합니다.

또한 Agent Node는 실행시키려는 프로그램에 따라 private agent node public agent node 이렇게 2가지로 역할이 나누어 집니다. DC/OS로 웹서비스를 구축하려 한다면 최소 agent node 2대가 필요하게 됩니다.

 

Bootstrap node

DC/OS의 설치 본 파일을 가지고 있으며 추가되는 master node agent node를 설치를 위한 부트스트랩(bootstrap) 서버 역할을 합니다.

Master node 중 하나를 bootstrap node로 해서 설치해봤는데 가능하기도 하지만 추천하지 않습니다. 사내에서 제일 성능이 좋지않은 PC를 이용해도 상관없습니다. 실제 서비스할 때는 아무런 역할을 하지 않습니다. 단지 node 추가를 위한 설치목적밖에는 역할이 없습니다.

 

위에 설명한 최소대수를 계산해 보면 bootstrap 1, master node 1, agent node 2(private/public) 4대가 필요합니다.

최소의 Fail-Over 환경을 위해서는 bootstrap 1, master node 3, private agent node 2, public agent node 2, 8대의 서버가 필요합니다.

 

Software Requirement

DC/OS설치전에 OS및 기타 소프트웨어 설치에 관련된 핵심적인 사항만 정리해 봅니다.

      * centos 7.4+ 설치

      * /var  10G 이상 free space

      * firewall 중지

 sudo systemctl stop firewalld && sudo systemctl disable firewalld

       * Disable Sudo password prompts  (/etc/shdoers 파일에 아래내용 추가

 %wheel ALL=(ALL) NOPASSWD: ALL

       * 시간동기화

 sudo yum install -y chrony

  

      * NFS 설정  (Node 별 공유 파일 영역, 필요시)

      * /etc/security/limits.conf 에 추가 (open file 갯수 증가)

*               soft    nofile          16384

*               hard    nofile          16384

 

 Docker 관련 설정

 

 OS 업데이트

sudo yum upgrade --assumeyes --tolerant

sudo yum update --assumeyes

아래 전체 복사해서 실행

sudo tee /etc/modules-load.d/overlay.conf <<-'EOF'

overlay

EOF 


reboot

 

overlay 결과 확인

lsmod | grep overlay

 

아래 전체 복사해서 실행

sudo tee /etc/yum.repos.d/docker.repo <<-'EOF'

[dockerrepo]

name=Docker Repository

baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/

enabled=1

gpgcheck=1

gpgkey=https://yum.dockerproject.org/gpg

EOF


아래 전체 복사해서 실행

sudo mkdir -p /etc/systemd/system/docker.service.d && sudo tee /etc/systemd/system/docker.service.d/override.conf <<- EOF

[Service]

ExecStart=

ExecStart=/usr/bin/dockerd --storage-driver=overlay

EOF

 

sudo yum install -y docker-engine-1.13.1 docker-engine-selinux-1.13.1

sudo systemctl start docker

sudo systemctl enable docker 

 

docker ps 명령으로 정상 설치 확인

 

DC/OS 설치 (GUI 방식)

https://docs.mesosphere.com/1.10/installing/oss/custom/gui/

 

각 서버가 준비되었으면

Boot strap 노드 컴퓨터에서 아래 명령을 수행합니다

curl -O https://downloads.dcos.io/dcos/stable/dcos_generate_config.sh

 

다음 브라우저에서 http://{bootstrap ip}:9000 으로 접속합니다.

 




Agent private IP List에는 private agent node 역할을 하는 ip 목록을 기입합니다.

Agent Public IP List에는 public agent node 역할을 하는 ip 목록을 기입합니다. 보통 public agent node에는 외부 접속을 담당하는 marathon-lb(HAPROXY) 가 설치되면 대부분의 서비스나 task private agent node 에서 실행됩니다.

 Master public ipmaster node 로 설정한 서버의 ip를 기입합니다.

 

 

모두 설치가 완료되고 경험상 각 서버 리부팅을 수행후 master node ip 로 브라우저를 접속하여 아래의 화면이 나오면 잘 설치된 것 입니다.

 

제가 위에 설명한 주요 설치과정을 빠트리지 않았다면 별 문제없이 설치되었을 것입니다. 저 경우는 각 서버의 시간 동기화가 잘 안되어 문제가 발생했는데 chrony를 설치하고 문제가 없었습니다.


추가 Node 설치

추가적인 Node를 확장하고자 하는 경우는 아래의 방법을 수행합니다.

boot 노드 서버 터미널 접속 

 

ssh-copy-id root@192.XXX.XXX.XXX    (192.XXX.XXX.XXX 는 새로 추가되는 agent node IP)

scp ~/dcos-install.tar root@192.XXX.XXX.XXX ~/dcos-install.tar

 

신규 Agent 노드 서버(192.XXX.XXX.XXX)  접속 

mkdir /opt/dcos_install_tmp

sudo tar xf dcos-install.tar -C /opt/dcos_install_tmp

sudo bash /opt/dcos_install_tmp/dcos_install.sh slave  (private node 설치인 경우)

sudo bash /opt/dcos_install_tmp/dcos_install.sh slave_public  (private node 설치인 경우)

 

 

 

설치 실패시 기존 설치 정보를 삭제하고자 하는 경우  - 아래 명령 2번 반복 후 위의 script 실행

rm -rf /opt/mesosphere

rm -rf /etc/systemd/system/dcos*

 

reboot

 위 DC/OS 설치 삭제 방법은 공식적인 방법이 아닙니다. DC/OS에서는 공식적인 uninstall을 제공하고 있지 않습니다. 따라서 OS 설치부터 다시 해야 할 수 도 있습니다.


DC/OS 운용 장점

-       사내 전체 서비스들에 대한 가시성 확보

 -> 사내 각 서비스들이 어디 어느 서버에 설치되어 있고, 잘 작동되는지 일일이 기억할 필요가 없어졌습니다.


-       안정적 서비스 인프라 스트럭처 확보

-       기타 유휴 장비 재활용

-    서비스간의 조합 및 운영 편리로 진정한 DevOps 환경 구현

-    능동적 서비스 부하 관리 및 Fail-over 관리

-       설치환경에 대한 설정정보(json)에 대해 수월한 백업 및 복구

 

사내에 DC/OS를 설치하면서부터 장점을 기술하면서 이 아티클을 마무리하겠습니다.  다음에는 각 서비스의 설치(deploy) 및 관리 노하우에 대해 설명하도록 하겠습니다. 사실 DC/OS는 docker기반의 서비스 컨테이너에 대한 orchestration 즉 조정자 역할만 하는 것이기 때문에 docker자체에 대한 기반지식이 매우 중요합니다. Docker에 대한 공부를 열심히 해두시고 다음 글에서 뵙겠습니다.

 

New Multi-Channel Dynamic CMS

Apache Ignite에 대해 알아보자 - (2)설치 및 실행

 

 

 

 

이전 포스팅에서 개념에 대해 살펴봤으니, 이번 편에서는 실제로 로컬에서 테스트를 해보려고 합니다. Ignite 사이트에 Getting started라는 메뉴에서 Ignite를 돌려볼 수 있는 몇 가지 방법에 대해 설명을 해놓았습니다. 이 포스팅에서는 binary 배포판을 다운받아서 시작하는 방법과 Maven 프로젝트를 생성해 pom 파일에서 dependency를 추가하는 방법을 다루고 있습니다.

1. 설치하기

https://ignite.apache.org/download.cgi 에서 Apache Ignite ZIP 파일을 다운로드 받아 압축을 풀고, 그 경로를 IGNITE_HOME으로 등록합니다. 가이드에는 이 스텝은 선택적(optional)이라고 나와있습니다. 이 과정을 생략하고 진행해본 결과, 디폴트 설정으로 그리드 노드를 실행하는 데에는 문제가 없습니다. 그러나 로그 설정을 위한 xml 파일에서 IGNITE_HOME 경로를 참조하고 있기 때문에 노드를 실행하며 나타나는 모든 로그를 기록하는 .log 파일을 생성하지 못했습니다. 그래서 IGNITE_HOME을 지정해주었습니다.

그리고 소스가 아니라 바이너리 릴리즈로 받는 것이 실행할 때 별도의 빌드가 필요없어 간편합니다. git 저장소에서 clone을 받아 메이븐 빌드를 하는 것도 시도해봤는데, package를 하던 중 모듈이 많아 java.lang.OutOfMemoryError: Java heap space error가 발생하여 메모리를 올려줘도 같은 에러가 계속 발생하여, 결국 포기하였습니다.(!) 저는 아래 캡처 화면과 같이 최신 버전 소스를 받았습니다.

 

다운로드 후 압축을 풀고 루트 경로를 IGNITE_HOME이라는 환경변수로 등록합니다. ignite-core 코드가 보고싶다면 git repository에서 클론을 받거나(https://git-wip-us.apache.org/repos/asf/ignite), source 배포판을 다운로드 받아서 볼 수 있습니다.

 

2. 테스트 프로젝트 생성

1) binary 배포판으로 생성

위에서 다운로드 받은 파일의 압축을 풀어보면 아래의 화면과 같은 구조를 가지고 있습니다.

bin 폴더에는 ignite 노드를 실행할 수 있는 sh, bat 파일이 들어있습니다. config 폴더에는 로그와 bean 설정 xml 파일들이 들어있고, libs 폴더에는 ignite-core jar 파일을 비롯하여 필수 및 선택적 기능의 jar파일들이 들어있습니다. 그리고 마지막으로 examples 폴더에는 예제 소스가 있습니다. 따라서 IDE툴에서 IGNITE_HOME 경로를 루트로 하는 자바 프로젝트를 생성한 후  examples\src\main\java를 소스 폴더로 등록하고 libs 폴더를 library로 설정하면 툴 내에서 예제 파일들을 그대로 실행하거나 추가 및 수정을 하면서 기능 테스트를 해볼 수 있습니다.

 

2) 메이븐 프로젝트로 생성

메이븐에 익숙한 분이라면 1번 방법보다 이 방법이 더 편하다고 느낄 것 같습니다. 메이븐으로 Ignite를 시작하기 위해서 필수적인 dependency는 ignite-core 딱 하나입니다. 가이드에는 스프링 기반의 xml 설정을 위한 ignite-spring과 SQL 쿼리를 위한 ignite-indexing도 종종 필요한 dependency로 소개하고 있습니다. IDE툴에서 메이븐 프로젝트를 하나 생성한 후 pom.xml 파일에 dependency만 추가하면 아주 간단하게 테스트 프로젝트를 생성할 수 있습니다.

<properties>
    <ignite.version>2.3.0</ignite.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.apache.ignite</groupId>
        <artifactId>ignite-core</artifactId>
        <version>${ignite.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.ignite</groupId>
        <artifactId>ignite-spring</artifactId>
        <version>${ignite.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.ignite</groupId>
        <artifactId>ignite-indexing</artifactId>
        <version>${ignite.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.ignite</groupId>
        <artifactId>ignite-log4j</artifactId>
        <version>${ignite.version}</version>
    </dependency>

</dependencies>

   

3. Ignite node 실행하기

1) Java 코드로 실행하기

전 포스팅에서 라이프사이클에 대해 소개를 하며, 그리드 노드를 생성하는 법을 언급하였습니다. 모든 설정을 default로 하고 node를 생성하는 방법은 아주아주 간단합니다. 테스트 클래스를 만들고 Ignite ignite = Ignition.start(); 코드를 실행하면 Ignite node가 시작됩니다. 설정을 변경하는 방법은 두 가지가 있습니다. 첫 째는 아래와 같이 start() 메소드에 변경하고자하는 property를 설정한 xml 파일 경로 문자열을 파라미터로 넘기면 됩니다.

Ignition.start("examples/config/persistentstore/example-persistent-store.xml")

두번째는 설정 관련 클래스인 IgniteConfiguration의 인스턴스를 생성하여 설정에 관한 set 메소드를 호출하여 원하는대로 설정한 후 start() 메소드에 xml 경로 대신 IgniteConfiguration 인스턴스를 파라미터로 넘기는 것입니다.

 

2) command창에서 실행하기

 command창에서 실행시키는 방법도 아주 간단합니다. command창을 관리자권한으로 실행시킨 후 IGNITE_HOME 경로의 bin 디렉토리로 이동합니다. 그런 후 ignite.bat 를 실행합니다. os가 리눅스라면 ignite.sh을 실행합니다. 만약 특정 설정 파일로 실행하고 싶은 경우에는 ignite.bat 뒤에 경로를 입력하고 실행하면 됩니다. 입력하지 않으면 default 설정으로 시작됩니다.

ex1. 기본 설정으로 시작하는 경우

$ cd C:\intellij\workspace\apache-ignite-fabric-2.3.0-bin\bin

$ ignite.bat

ex2. 특정 설정 파일로 시작하는 경우

$ cd C:\intellij\workspace\apache-ignite-fabric-2.3.0-bin\bin

$ ignite.bat examples/config/persistentstore/example-persistent-store.xml

 

위의 어느 방법으로 하던지, 노드를 실행하면 콘솔에 다음과 같은 로그가 찍힙니다.

로그를 보다보니 몇 가지 사실을 알게되었습니다.

  • 콘솔에 출력되는 로그 모드를 설정할 수 있습니다. 기본적으로는 Quiet mode로 설정되어 있는데, 이 경우에 콘솔에는 핵심 내용만 출력이 됩니다. 만약 전체 내용이 출력되기를 원한다면 IGNITE_HOME 경로에 bin 폴더에서 운영체제에 맞게 ignite.sh 혹은 ignite.bat 파일에 -DIGNITE_QUIET=false 를 추가해야 합니다.

  • 전체 로그 내용은 기본으로 설정된 로그 파일 경로에 별도로 저장됩니다. 경로 및 이름 설정은 아래와 같습니다. 로그 파일에는 콘솔에 찍히는 것보다 더욱 자세한 내용이 기록됩니다.

    ${IGNITE_HOME}/work/log/ignite-${sys:nodeId}.log

  • 2.3.0 버전은 가장 최신의 1.8 JVM 버전을 사용하기를 권장합니다. 처음에 프로젝트에서 사용하는 자바 버전을 1.7로 설정했더니 'Switch to the most recent 1.8 JVM version'이라는 메시지가 로그에 떴습니다. 그 이유는 가비지 콜렉터(Garbage Collector)와 관련이 있습니다. 먄약 G1 가비지 콜렉터(Garbage-First garbage collector)를 사용한다면, 성능이 계속 향상되고 있으므로 JDK 8 가장 최신 버전을 사용하기를 권장하는 것입니다. G1 가비지 콜렉터와 Ignite gc 튜닝에 대해서는 추후에 따로 정리를 해야겠습니다.

  • 실행 시 몇 가지 JVM 옵션을 추가하기를 권장합니다. JVM option을 별도로 설정하지 않고 실행했더니 로그에 몇 가지 메시지가 떴습니다. Ignite 사용 시 성능 향상을 위해 옵션 설정을 권장하는 것 같습니다. 로그에 나온 옵션을 다 추가한 후 재실행했더니 로그에 더 이상 관련 메시지가 뜨지 않았습니다.

    1. -server : JVM 서버 모드를 가능하게 할 것

    2. -Xms<size>[g|G|m|M|k|K] : JVM 힙 메모리 최대 사이즈를 설정할 것

    3. -XX:MaxDirectMemorySize=<size>[g|G|m|M|k|K] : OutOfMemory(OOME):Direct buffer memory 에러가 나면 최대 다이렉트 메모리를 크기를 설정할 것

    4.  -XX:+DisableExplicitGC : System.gc()를 호출하는 처리는 불가능하게 할 것

    5. -Xms512m -Xmx512m : 초기 힙 사이즈가 512MB보다 작아서는 안될 것

 

설치와 기본 노드 실행까지는 끝냈으니 다음 포스팅에서는 기능별 테스트를 해보도록 하겠습니다.

 


Apache Ignite 시리즈 1편에 대한 내용을 살펴보고 싶다면, 아래 링크를 클릭해주세요.

▶ Apache Ignite에 대해 알아보자 - (1)개념 이해


 

New Multi-Channel Dynamic CMS

Apache Ignite에 대해 알아보자 - (1)개념 이해

 

 

 

 

Apache Ignite는 인메모리 컴퓨팅 플랫폼(in-memory computing platform)으로 데이터 레이어와 사용자 애플리케이션 레이어 사이에 완벽하게 들어갈 수 있습니다. 기존의 디스크 기반 저장소 레이어로부터 RAM으로 데이터를 로드하여, 최대 6자리수(백만배)까지 성능을 향상시킬 수 있습니다. 클러스터에 노드를 추가하기 만하면 인메모리 데이터 용량(in-memory data capacity)을 쉽게 확장하여 페타 바이트 단위의 데이터를 처리 할 수 있습니다. 또한 기존에 사용하는 데이터베이스를 전면 교체할 필요가 없으며, RDBMS, NoSQL, 하둡 데이터 저장소와 함께 잘 작동합니다. 따라서 대용량 데이터를 높은 성능으로 빠르게 처리해야 하는 시스템에 도입을 고려해볼 수 있습니다.

 

 

 

1. 알아야 하는 개념

 

1) Persistent Storage

 

'Persistent Storage'를 말 그대로 보자면 'Persistent'는 '오래 지속되는, 영구적인'이라는 뜻이 있고 'Storage'는 저장소이기 때문에 '오래 지속되는/영구적인 저장소'라고 할 수 있습니다. 한국어의 정확한 명칭이 궁금해서 찾아봤는데, 사용되는 곳마다 '영구 저장소, 장기보관 스토리지, 지속적 저장소, 영속적 저장소' 등으로 다양했습니다. 사실 조금씩 느낌이 다른 단어들이고, 명확하게 정해진 것이 없지만 이 포스트에서는 저장소에서 데이터가 '계속 지속되며 변함이 없다'는 데에 의미를 두어 '영구 저장소'라고 칭하겠습니다. 

 

영구 저장소(Persistent storage)는 장치의 전원이 꺼진 후에도 데이터를 유지하는 모든 데이터 저장소 장치입니다. 가끔 비휘발성(non-volatile) 저장소라고 일컬어집니다. HDD와 SSD는 영구 저장소의 가장 일반적인 타입입니다. 반면, RAM과 캐시(cache)는 전형적인 비영구 저장소(Non-persistent storage)로, 전원을 끄면 데이터는 지워집니다. 그러나, 비휘발성 RAM이나 플래시기반의(flash-based) RAM은 지속성이 있습니다. 지속성은 충돌이나 리부팅을 했을 때, 데이터가 상실되지 않는다는 이점이 있습니다.

 

2) In-memory Database

 

'In-memory Storage'는 컴퓨터의 메인 메모리에 데이터를 저장하는 저장소입니다. 디스크에 저장된 데이터에 접근하는 것보다 더 빠른 시간내에 데이터에 접근할 수 있습니다. 그렇기 때문에 데이터를 조회할 때 시간이 단축되며 더 나은 성능을 기대할 수 있습니다. 인메모리 저장소는 RAM이 휘발성이기 때문에, 장치의 전원이 나가거나 리부팅이 될 때 휘발성 RAM에 저장된 데이터가 날라간다는 기술적인 한계가 있었습니다. 그러나 비휘발성 RAM 기술의 등장으로 이런 단점을 극복하고 있습니다.

 

'In-memory Database'(IMDB)는 컴퓨터의 데이터 저장을 위해 메인 메모리에 주로 의존하는 DBMS(Database Management System)입니다. 디스크 저장 메커니즘을 사용하는 DBMS보다 데이터 조회 시 탐색 시간이 짧고 디스크에 액세스(access)하는 것보다 메모리에 액세스하는 것이 더 빨라서 통신 네트워크 장비, 모바일 광고 네트워크를 실행하는 등 응답시간이 중요한 애플리케이션에서 주로 사용됩니다.

 

메인 메모리 데이터베이스는 휘발성 메모리 장치에 데이터를저장합니다. 이 장치는 전원이 나가거나 리셋될 때 저장된 모든 데이터를 상실합니다. 이 경우 IMDB는 데이터베이스 트랜잭션이 보증해야할 ACID(atomicity, consistency, isolation, durability; 원자성, 일관성, 고립성, 지속성) 속성 중 '지속성(durability)'에 대한 지원이 부족하다고 할 수 있습니다. 휘발성 메모리 베이스 IMDB는 다른 세 가지 속성을 대체로 지원을 할 수 있으며 많은 IMDB들이 스냅샷 파일, 체크포인트 이미지, 트랜잭션 로깅, 비휘발성 메모리, 데이터베이스 복제와 같은 메커니즘을 통해 지속성을 보장합니다.

 

 

 

2. Apach Ignite란?

 

Apache Ignite는 강력한 SQL, key-value 그리고 프로세싱 API를 가진 지속성이 있고(durable), 강력하게 일관성을 유지하는(strongly consistent) 고가용성(highly available)의 인메모리 컴퓨팅 플랫폼입니다. Ignite는 Native persistence기능을 껐다 켜는 것만으로 퍼시스턴트 스토리지가 될 수도 순수한 인메모리 스토리지가 될 수도 있습니다. 또한 Ignite의 데이터는 다수 노드의 클러스터를 통해 파티션되거나(partitioned) 복제될(replicated) 수 있는 분산 데이터베이스입니다.

 

Ignite가 SQL을 지원하기는 하지만 완전한 관계형 SQL 데이터베이스라고 할 수는 없습니다. 관계형 SQL데이터베이스처럼 동작하는 것을 지향하면서도, 제약조건이나 인덱스를 처리하는 데에 있어 약간의 차이점이 있기 때문입니다. Ignite는 primary와 secondary 인덱스를 지원하지만, 고유성(uniqueness)은 primary 인덱스에만 강제할 수 있습니다. 또한 Ignite는 외래키 제약조건을 지원하지 않습니다. 본질적으로, Ignite는 의도적으로 각 업데이트에 대한 클러스터 브로드캐스트 메시지(cluster broadcast message)를 수반하거나 심각하게 시스템의 확장성 및 성능에 악영향을 주는 어떤 제약조건도 지원하지 않습니다.

 

 

 

3. Apache Ignite 주요특징

 

1) 지속되는 메모리(durable memory)

 

Ignite의 지속되는 메모리 컴포넌트(durable memory component)는 RAM을 단지 캐싱 레이어(caching layer)가 아니라 모든 기능을 완전히 하는 저장 레이어(storage layer)로 다룹니다. 이는 사용자가 필요에 따라 persistence를 켜거나 끌 수 있다는 것을 의미합니다. 즉, Ignite는 persistence의 on/off 상태에 따라서 영구 저장소(persistent storage)될 수도 순수하게 인메모리 저장소(in-memory storage)가 될 수도 있습니다.

 

만약 persistence가 꺼져있다면, Ignite는 순수한 인메모리 저장소가 되며 SQL와 key-value API중 어떤 것을 사용하기를 선호하는 지에 따라서 분산된 인메모리 데이터베이스(IMDB)나 인메모리 데이터 그리드(IMDG) 역할을 합니다.

 

만약 persistence가 켜져 있다면, Ignite는 *메모리 중심적*인 시스템처럼 기능하기 시작하는데, 프로세싱의 대부분이 메모리에서 일어나지만 데이터와 인덱스는 디스크에 보관됩니다. 또한 모든 데이터의 일관성을 보장하고 모든 클러스터(cluster) 실패에 대해 회복력이 있는 분산되고 수평적으로 확장가능한 데이터베이스가 됩니다. 여기서 전통적인 디스크 중심 RDBMS나 NoSQL 시스템과 크게 다른 점은 Ignite는 강력히 일관되고, 수평적으로 확장가능하며, SQL과 key-value 처리 API를 지원한다는 점입니다. 

 

Apache Ignite는 Ignite Native Persistence가 가능할 때 데이터와 인덱스를 저장하고 처리하는 것을 메모리와 디스크에서 둘 다 할 수 있게 하는 '지속되는 메모리' 아키텍쳐에 기반을 두고 있습니다. '지속되는 메모리' 아키텍처는 디스크 지속성(durability)과 한 시스템에서의 강력한 일관성과 함께 인메모리 컴퓨팅의 성능과 규모를 달성하는 데 도움이 됩니다.

 

Ignite의 지속되는 메모리는 리눅스같은 운영 시스템의 가상 메모리와 유사한 방식으로 작동합니다. 그러나, 이 둘의 한 가지 큰 차이점은 지속되는 메모리는 전체 혹은 부분적인 데이터 셋을 메모리에 보관하는 데다가, 항상 디스크상에 인덱스를 포함한 전체 데이터 셋을 유지하는 반면, 가상 메모리는 RAM이 부족할 때 교환의 목적으로만 디스크를 사용합니다.

 

*메모리 중심적(memory centric): Ignite는 디스크 지속성과 한 시스템 내에서의 강력한 일관성과 함께 성능과 인메모리 컴퓨팅의 규모를 결합한 메모리 중심적 아키텍처를 기반으로 합니다. 메모리 중심적인 접근과 전통적인 디스크 중심적인 접근의 가장 큰 차이점은 메모리를 완전히 기능하는 저장소로 다루는지 아니면 단지 대부분의 데이터베이스들이 그렇듯이 caching 레이어로 다루는지 입니다. Ignite는 순수한 인메모리 모드에서 기능을 수행할 수 있으며, 이 경우 인메모리 데이터베이스(IMDB)나 인메모리 데이터 그리드(IMDG)처럼 다뤄질 수 있습니다.

 

 

 

2) Ignite Native Persistence

 

Ignite native persistence는 ACID(Atomicity, Consistency, Isolation, Durability - 원자성, 일관성, 고립성, 지속성) 속성을 가지며,  SQL 호환성이 있는 분산 디스크 저장소로 Ignite의 '지속되는 메모리'와 함께 투명하게 통합할 수 있습니다. Ignite persistence는 부가적이며 껐다 켰다할 수 있습니다. 꺼져있을 때, Ignite는 순수하게 인메모리 저장소가 됩니다.

 

가능한 native persistence와 함께, Ignite는 항상 디스크와 가능한만큼의 RAM에 데이터의 상위집합(superset)을 저장합니다. 예를 들어, 100개의 엔트리가 있고 RAM이 오직 20개를 저장할 수 있는 용량을 가지고 있다면, 100개 모두 디스크상에 저장되며 오직 20개만 더 나은 성능을 위해서 RAM에 캐싱됩니다.

 

native persistence는 다음과 같은 중요한 특징이 있습니다.

  • 메모리와 디스크 양쪽에 걸쳐있는 모든 데이터 셋에 대한 SQL 쿼리. 이는 Apache Ignite가 메모리 중심의 분산된 SQL 데이터베이스처럼 사용될 수 있다는 것을 의미합니다.

  • 메모리에 모든 데이터를 가지고 있을 필요가 없습니다. Ignite persistence는 데이터의 상위 집합을 디스크에 저장하고 오직 가장 빈번하게 하용되는 하위 집합(subset)만 메모리에 저장하도록 합니다.

  • 즉각적인 클러스터 재시작. Ignite는 클러스터가 시작 혹은 재시작하면 즉시 디스크로부터 완전히 작동하게 됩니다. 미리 로드하거나 인메모리 캐시에서 준비를 할 필요가 없습니다. 데이터가 액세스되면 데이터는 인메모리에 천천히 로드됩니다.

  • 데이터와 인덱스는 메모리와 디스크 양쪽에 비슷한 포맷으로 저장됩니다. 이는 메모리와 디스크 간 데이터를 이동할 때 발생하는 값비싼 변형작업을 피할 수 있게 도와줍니다.

  • third party 솔루션을 플러그인으로 사용하여 전체 혹은 증가하는 클러스터 스냅샷을 생성할 수 있는 기능이 있습니다.

 

Write-Ahead 로그: 데이터가 메모리에 업데이트될 때마다, 업데이트 작업은 미리쓰기로그(write-ahead log;WAL) 의 끝(tail)에 붙습니다. WAL의 목적은 가능하면 가장 빠른 방법으로 디스크에 업데이트를 전파하고 전체 클러스터 실패를 지원하는 일관된 복구 매커니즘을 제공하는 것입니다.

 

전체 WAL은 연속하여 채워지는 세그먼트(segment)라고 불리는 몇개의 파일로 나뉘어집니다. 하나의 세그먼트가 다 차면, 컨텐트는 WAL 아카이브에 복사되어 설정 가능한 시간 동안 보존될 것입니다. 세그먼트가 복사되는 동안, 다른 세그먼트가 활성화된 WAL 파일로 취급됩니다.

 

클러스터는 언제나 가장 최근에 커밋이 성공된 트랜젝션의 상태로 복구될 수 있습니다.

 

checkpointing: WAL이 커짐에 따라, 주기적으로 메인 저장소에 체크포인트됩니다(checkpointed). 체크포인팅이란 메모리로부터 디스크의 파티션 파일로 'dirty page'를 복사하는 프로세스입니다. dirty page란 메모리에서 업데이트가 되어 WAL에는 추가되었지만, 디스크의 각각의 파티션 파일에는 아직 쓰이지 않은 페이지를 의미합니다. 

 

 

 

3) 분산 SQL 데이터베이스

 

Ignite는 ANSI-99와 호환되며, 수평적으로 확장 가능한 고장 방지의(fault-tolerant) 분산 SQL 데이터베이스를 함께 제공합니다. 사용 환경에 따라 클러스터 노드를 통해 데이터를 분할함으로써 혹은 전체 복제(full replication)를 함으로써 분배할 수 있습니다. 다른 분산 SQL 데이터베이스와 달리, Ignite durable memory는 활성화된 저장소 계층(tier)으로 메모리와 디스크 둘 다 취급합니다. native persistence로 알려진 디스크 계층은 기본적으로 비활성화되어있으며, 이 경우 Ignite는 순수한 인메모리 데이터베이스가 됩니다.

 

표준 JDBC 또는 ODBC 연결을 사용하여 다른 SQL 스토리지와 마찬가지로 Ignite와 상호 작용할 수 있습니다. Ignite는 또한 Java, .NET, C++ 개발자에게 더 나은 성능을 위한 native SQL API를 제공합니다.

 

Ignite의 구별되는 특징들 중 하나는 분산 SQL JOIN을 위한 완전한 지원입니다. Ignite는 배치된(collocated) 혹은 그렇지 않은 방식으로 데이터를 join할 수 있습니다. 배치되었을 때, 네트워크를 통해 큰 데이터 셋을 옮길 필요없이 각 노드에서 가능한 로컬 데이터에서 실행됩니다. 이러한 접근법은 분산 데이터베이스에서 최고의 확장성과 성능을 제공합니다.

 

collocated processing(배치 처리): RDBMS 혹은 NoSQL처럼 디스크 중심적인 시스템은 일반적으로 클라이언트-서버 방식으로 작동하는데, 이 전통적인 클라이언트-서버 접근법은 데이터가 서버로부터 클라이언트 사이드로 전달되고 여기서 데이터가 처리되며 그런 후 보통은 폐기됩니다. 이 접근법은 규모를 잘 확장하지 않는데 네트워크 상으로 데이터를 이동하는 것이 분산 시스템에서 가장 비용이 많이 드는(expensive) 작업이기 때문입니다.

 

보다 확장 가능한 접근법은 데이터가 실제로 존재하는 서버쪽으로 계산(computations)을 가져옴으로써 흐름을 역전시킨 배치 처리(collocated processing)입니다. 이 접근법은 값비싼 직렬화나 네트워크 이동을 피하면서 데이터가 저장된 위치에서 고급 로직이나 JOIN을 포함한 분산 SQL을 실행하게 해줍니다.

 

예를 들어, 뉴욕에 눈보라가 쳐서 약 8만명에게 경보 문자 메시지를 보낸다고 가정해보겠습니다. 8만건의 정보를 데이터베이스에서 문자메시지 애플리케이션으로 가져오는 것이 아니라, 문자메시지 로직을 뉴욕거주자 정보를 담고있는 클러스터 노드로 보냅니다. 결과적으로 8만건의 정보를 네트워크로 전송하는 대신 1개의 계산만 이동하게 되어 퍼포먼스가 훨씬 좋습니다.

 

 

 

4) 인메모리 데이터 그리드(In-Memory Data Grid)

 

Ignite 인메모리 데이터 그리드는 처음부터 수평적인 규모(horizontal scale)의 개념과 실시간으로 필요할 때 노드를 추가할 수 있는 능력을 바탕으로 만들어졌습니다. 데이터그리드는 *데이터 로컬리티(data locality)*와 불필요한 데이터 잡음(data noise)을 줄이기 위한 관련성 데이터 라우팅(affinity data routing)을 위해 강력한 시맨틱을 가지고 선형적으로 수백개의 노드로 확장할 수 있게 설계되었습니다.

 

Ignite 데이터 그리드는 인메모리 분산 key-value 저장소로 전체 데이터의 일부를 소유하고 있는 모든 클러스터 노드를 분산된 분할 해시맵으로 볼 수 있습니다. 이렇게하면 더 많은 클러스터 노드를 추가할수록 더 많은 데이터를 캐시할 수 있습니다. 다른 key-value 저장소와는 다르게, Ignite는 장착형 해싱 알고리즘(pluggable hashing algorithm)을 사용하여 데이터 로컬리티를 결정합니다. 모든 클라이언트는 해싱 함수에 키를 연결함으로써 별도의 매핑 서버나 네임 노드(name nodes)를 필요로 하지 않고, 어떤 노드에 키를 속하게 할 지 결정할 수 있습니다.

또한 Ignite 데이터 그리드는 분산 트랜잭션 key-value 저장소로, 다른 인메모리 데이터 그리드와 다르게 Ignite는 데이터를 메모리와 디스크 둘 다에 저장할 수 있게 합니다. 표준 key-value 데이터 동작 외에, ACID 트랜잭션과 모든 JCache 기능을 포함하며, 또한 데이터에 대해 분산 조인과 더불어 SQL 쿼리를 지원합니다.

 

 

 

Ignite 데이터 그리드는 현재 분산 클러스터에서 ACID 트랜잭션 또는 원자 데이터 업데이트를 가장 빠르게 구현한 것 중 하나입니다. 데이터 그리드에 있는 데이터는 순수하게 메모리에 저장될 수도, 디스크에서 지속될 수도 있습니다. 만약 Ignite native persistence가 가능하면, 데이터와 인덱스는 모든 클러스터 노드에 기본적으로 유지됩니다. 이 경우, 메모리는 오직 전체 유지되는 데이터 셋의 작은 캐싱 레이어와 같은 역할을 합니다. 모든 쿼리와 트랜잭션은 디스크에 저장된 전체 데이터셋에 걸쳐있습니다.

 

인메모리 데이터 그리드는 또한 RDBMS와 NoSQL, 하둡 기반의 저장소과 같은 3rd party 데이터베이스와 함께 통합함으로써 성능과 확장 가능성을 향상시킵니다. 이 접근법은 기존 데이터의 전면적인 교체를 요구하지 않지만, 한계를 가지고 있습니다. 예를 들어, SQL 혹은 검색 쿼리(scan queries)는 Ignite가 외부 데이터에 대한 어떤 지식도 없기 때문에 외부 데이터베이스가 아니라 오직 메모리에 저장된 결과만을 포함합니다. 

 

*데이터 로컬리티(data locality): 큰 데이터를 계산하는 쪽으로 이동시키는 대신, 실제 데이터가 존재하는 노드쪽으로 계산을 보내는 능력을 의미합니다. (참조링크)

 

 

 

5) 클러스터링(clustering)

 

Ignite는 논리적 클러스터 그룹과 자동 발견(auto-discovery)를 포함한 향상된 클러스터링 능력을 가지고 있습니다. Ignite의 노드는 자동적으로 서로 발견할 수 있습니다. 이는 필요할 때 전체 클러스터의 재시작 없이 클러스터의 규모를 확장하는 데에 도움을 줍니다. 개발자는 또한 Ignite의 개인 클라우드(private clouds)와 아마존 웹 서비스와 같은 공용 클라우드(public clouds) 간 연결을 구축하게 해주는 하이브리드 클라우드를 활용하여, 각각의 장점을 모두 제공할 수 있습니다.

 

 

 

4. Ignite 라이프사이클

 

Ignite는 JVM기반입니다. 하나의 JVM은 하나의 혹은 다수의 논리적인 Ignite 노드를 나타냅니다. (그러나, 대부분의 경우 하나의 JVM이 하나의 Ignite 노드를 실행합니다.) Ignite 문서 처음부터 끝까지, 용어 'Ignite runtime'과 'Ignite node'를 대부분 교환 가능하게 사용하였습니다. 예를 들어, "이 호스트에서 5개의 노드를 실행할 수 있다"고 말한다면, 대부분의 경우 이것은 기술적으로 호스트에서 각각 하나의 Ignite 노드를 실행하는 5개의 JVM을 시작할 수 있다는 것을 의미합니다. Ignite는 또한 하나의 JVM에서 다수의 노드를 지원합니다. 사실, Ignite에 대한 대부분의 내부 테스트를 그 방식으로 실행합니다.

 

1) Ignition 클래스

 

Ignition 클래스는 네트워크 토폴로지(network topology)에서 개개의 Ignite 노드를 시작합니다. (네트워크 상의 컴퓨터와 같은) 물리적인 서버는 그 위에서 실행하는 다수의 Ignite 노드를 가질 수 있습니다. 모든 설정을 default로 하고 그리드 노드를 논리적으로 실행하는 방법은 Java 코드로 다음과 같습니다.

Ignite ignite = Ignition.start();

 

혹은 설정 파일의 경로를 파라미터로 넘겨서 시작할 수도 있습니다. 경로는 절대경로가 될 수도 있고 IGNITE_HOME 혹은 클래스패스의 META-INF 폴더의 상대경로가 될 수도 있습니다.

 

2) 라이프사이클빈(LifecycleBean)

 

때로는 Ignite노드를 시작하거나 멈출 때 특정한 액션을 수행해야 하는 경우가 있습니다. 이는 LifecycleBean 인터페이스를 구현함으로써 가능하며, 스프링 XML 파일에서 IgniteConfiguration의 lifecycleBeans property에서 구현한 bean을 구체화할 수 있습니다.

<bean class="org.apache.ignite.IgniteConfiguration">
    ...
    <property name="lifecycleBeans">
        <list>
            <bean class="com.mycompany.MyLifecycleBean"/>
        </list>
    </property>
    ...
</bean>

 

또한 프로그래밍적으로 LifeCycleBean을 설정할 수도 있습니다.

 

 

 

 

 

Apache Ignite에 대해 간단하게 개념과 특징에 대해 살펴보았습니다. 내용은 https://ignite.apache.org 사이트와 https://apacheignite.readme.io/docs/ 사이트를 참조하였습니다. 제가 쓴 내용 외에 더 많은 특징에 대한 자세한 설명은 하단에 명시한 사이트에서 보실 수 있습니다. 맨 아래 링크를 건 페이지에서는 Apache Ignite에 대한 설명, 주요 특징, 설계에 대해 자세히 잘 정리된 글(영문)이니 읽어보시면 많은 도움이 될 것 같습니다. 그리고 다음 포스팅에서는 실제로 테스트를 해보는 내용을 올릴 예정입니다.

 

* 참조사이트

https://ignite.apache.org/features/durablememory.html

https://apacheignite.readme.io/docs/ignite-facts

 

https://www.infoworld.com/article/3135070/data-center/fire-up-big-data-processing-with-apache-ignite.html

 


Apache Ignite에 대한 더 자세한 내용을 살펴보고 싶다면, 아래 링크를 클릭해주세요.

▶ Apache Ignite에 대해 알아보자 - (2)설치 및 실행


 

 

사이버이메지네이션 회사 소개

 

New Multi-Channel Dynamic CMS