dsafsdfsdafsd

테스트입니다.

잘 나오네요.

그런데 왜 엔터를 칠 때마다 위로 스크롤 될까요?

그런데 왜 엔터를 칠 때마다 위로 스크롤 될까요?
그런데 왜 엔터를 칠 때마다 위로 스크롤 될까요?
그런데 왜 엔터를 칠 때마다 위로 스크롤 될까요?

test

<img src="http://groups.google.com/groups/img/3nb/groups_bar_ko.gif" width="132" height="26">

테스트.... 

 

2009년 44주(10.25~10.31일) ILI는 41.73으로 43주 대비 105.7% 증가 *  ILI(Influenza-Like Illness) : 표본감시의료기관(10.1일 현재 전국 817개소) 외래 환자 1,000명당 인플루엔자 유사 증상자수, ‘09~’10절기 유행 주의보 기준 : 2.6

또 SMS/MMS등의 문자 메시지 서비스는 명절날 폭주를 하지요. 그래서 여기저기서 서버 모아서 해당 서비스에 붙여놓습니다만 부족한 경우가 많습니다. 특정한 날의 경우야 어떻게든 다른데서 뜯어와서 메운다고 하지만 하루를 기준으로 특정 시간대에만 사용량이 많은 서비스의 경우는 어찌할 방도가 없습니다.

제정 및 개정 이력

목 차

1. 시스템 아키텍처 정의 4  

1.1. 정의. 4  

1.2. 목표. 4  

2. 하드웨어 구성 5  

2.1. 보유장비 현황. 5  

3. 소프트웨어 구성 6  

3.1. 목표 시스템 구성도. 6  

3.2. 응용 시스템 구축 목표. 6  

3.3. 소프트웨어 아키텍처 정의. 7  

3.4. 아키텍처 주요 구성요소. 7  

3.5. 웹 Application 구조. 8  

3.5.1. JDFW(JMatrix Development FrameWork)을 기반으로 한 개발. 8  

3.5.2. Framework Detail 및 동작흐름도. 8  

3.6. 소프트웨어 구성도. 9  

3.7. 도입 소프트웨어. 9  

3.8. Direct DB Connection 11  

3.9. Data Mart 구성도. 11  

4. 네트워크 구성 12  

4.1. 전체 네트워크 구성도. 12  

4.2. 네트워크 보안 지침. 12  

5. 시스템 보안 설계 13  

5.1. 목적. 13  

5.2. 보안 취약점 및 대책 항목. 13  

5.3. 접근통제. 14  

5.3.1. 개요. 14  

5.3.2. 보호 대책. 14  

A.  부적절한 파라미터. 17  

B.   취약한 세션 관리(Cookie 변조) 19  

C.   악의적인 명령 실행(XSS) 21  

D.   명령어 주입 공격(SQL Injection) 23  

E.   Upload 취약점. 25  

F.   Download 취약점. 27  

G.  기타 보안 사항. 29  

H.   User 보안 관련. 30  

6......................................................................................................................................... 백업 및 복구 32  

A.  개요. 32  

B.   용어정의. 32  

C.   백업의 종류. 35  

D.   백업 구성 방식. 39  

E.   백업 시스템 구축시 고려사항. 45  

F.   백업 주기. 46  

G.  백업 방식. 47  

H.   데이터베이스 백업모드. 48  

I.    소산 백업. 49  

J.   백업 정책. 49  

K.  시스템 복구. 50  

L.   DB 복구. 51  

1. 시스템 아키텍처 정의

1.1. 정의

시스템 아키텍처 정의서는 시스템의 설계 및 개발 시에 아키텍처를 준수하는 설계에 대한 의사결정을 가능케 하여 요구사항과 시스템간에 일관성이 유지되도록 하고, 설계상의 위험 요소를 미리 도출하여 초기에 이에 대한 고려를 할 수 있도록 한다. 즉, 시스템 전체의 일관된 아키텍처를 제공하여 시스템의 목적 및 성능에 있어서 체계적인 구조를 갖추고자 한다.

1.2. 목표

원산지정보관리시스템 구축 프로젝트는 다음 사항을 목표로 구축한다.

l 확장성 : 향후 확산 사업 시 기존의 설계를 변경하지 않고 손쉽게 확장이 가능하여야 한다.

l 통합성: 기존 레가시 시스템 및 연관 시스템과 유연하고 원활한 데이터 인터페이스가 가능하여야 한다.

l 보안성: 사용자 / 메뉴별 CRUD 권한을 제공하고 웹 어플리케이션 취약점에 대한 보안 고려하여 구축하여야 한다.

l 유지보수성 : 업무 로직을 변경하려는 경우 적은 인력으로 손쉽게 프로그램 수정이 가능해야 하며 업무간의 의존성을 적게 설계하여 변경에 대하여 해당 컴포넌트만 수정할 수 있도록 한다.

l 재사용성 : 업무변경에 따른 모듈 또는 업무 로직 변경 시 기존에 작성한 컴포넌트 또는 모듈을 재사용할 수 있어야 한다.

2. 하드웨어 구성

2.1. 보유장비 현황

3. 소프트웨어 구성

3.1. 목표 시스템 구성도

3.2. 응용 시스템 구축 목표

3.3. 소프트웨어 아키텍처 정의

원산지정보관리시스템은 Enterprise 환경에서 변화에 유연하게 대처하기 위하여 Presentation Layer와 Business Layer 소프트웨어 아키텍처를 구성한다.

3.4. 아키텍처 주요 구성요소

l 컴포넌트 변경 추가, 확장, 재사용 용이

모든 시스템의 호출이 단편적이고 Business Component가 독립적으로 수행될 수 있도록 설계하여 재사용 성을 유지한다. 각 컴포넌트 별로 잘 정의되고 문서화된 인터페이스를 가지고 있어서 하나의 계층이 다수의 Context를 재사용할 수 있다. 기본적인 아키텍처를 유지하는 한 새로운 비즈니스 컴포넌트의 추가 및 확장이 용이하다.

l 유지보수

각 컴포넌트 인터페이스 정보와 개발에 대한 코딩 표준(개발표준안). UI 표준 등 각종 표준과 지침에 대하여 문서화하여 유지 보수를 용이하도록 한다

3.5. 웹 Application 구조

3.5.1. JDFW(JMatrix Development FrameWork)을 기반으로 한 개발

         - 구조화된 프로그램 프로그램 일관성 제공, 용이한 소스 파악으로 운영 유지 보수 용이

3.5.2. Framework Detail 및 동작흐름도

사용자는 URL 이 http://www.dev.com/xxx.action 와 같이 확장자가 “.action” 인 request 를 보내면 servlet engine 은 action.xml의 name태그명에 해당하는  servlet 에게 Request 를 넘기게 되며 Request된 값들을 Property 변수에 셋팅한다.

*.vm에 연결되는 최초의 Servlet(*.java)는 Request Parameter값들을 가공하여 Property 변수에 셋팅하고(때에 따라서 Vector, hashMap에 Property를 저장해서보낸다.(Multi Transaction 일경우)) DataBase Connection 객체를 Biz클래스로 전달(호출)한다.

BiznessLogic을 담당하는 Biz Class는 Parameter로 Connection과 Request를 받아서 트랙잭션을 하나로 묵어서 DataAcess Class로 전달(호출)한다.

Data Acess Object 클래스는 실제 DB와 통신하여 트랙잭션에 대한 결과값을 받아온다.

3.6. 소프트웨어 구성도

3.7. 도입 소프트웨어

4. 네트워크 구성

4.1. 전체 네트워크 구성도

4.2. 네트워크 보안 지침

  외부 네트워크, 인터넷, 협력업체 망과 연결 시에 일정 수준 이상의 정보보호 수준을 유지하고 안정적인 IT인프라를 갖추기 위하여 고객사의 네트워크 보안 지침에 따른다.

5. 시스템 보안 설계

5.1. 목적

어플리케이션 보안 설계서는 원산지정보관리시스템 프로젝트에서 발생될 수 있는 보안 취약점에 대한 상세 설명과 함께 안전한 코드의 예를 제공함으로써 보안성이 보장된 어플리케이션 확보를 목적으로 한다.

시스템 운영 중 보안사고로 인한 업무 지연·중단 및 대외적인 신뢰도에 심각한 피해를 발생시킬 수 있는 침해사고를 예방하고, 사고 발생시 피해를 최소화 하기 위한 대응 절차 및 보고체계를 수립하여 능동적으로 대처한다.

5.2. 보안 취약점 및 대책 항목

u  접근통제 취약점

u  부적절한 파라미터

u  취약한 세션관리(Cookie 변조)

u  악의적인 명령 실행(XSS)

u  명령어 주입 공격(SQL Injection)

u  Upload 취약점

u  Download 취약점

u  기타 보안 사항

u  로그인 관련 보안 사항

5.3. 접근통제

5.3.1. 개요

접근통제는 특정 사용자들에게만 웹 콘텐츠나 기능들에 접근할 수 있도록 허가해 주는 것으로 일반적으로 관리자 페이지에 대한 접근통제가 필요하다.

관리자 페이지는 웹 서비스의 사용자나 데이터 등을 손쉽게 관리하기 위한 목적으로 다양한 기능과 권한을 갖고 있는 페이지로 일반 사용자가 관리자 페이지에 접근할 수 없도록 해야 한다.

또한 관리자 페이지가 일반적으로 추측하기 쉬운 URL(/admin, /manager, /master)을 사용하고 있어 인증을 우회하여 접근하는 위험에 노출되어 있다.

5.3.2. 보호 대책

대부분의 관리자 페이지는 http://www.xxx.com/admin 등과 같이 쉽게 추측이 가능하다.

인증 과정이 존재하더라도 SQL Injection 공격을 하거나 JavaScript 변조 등의 취약점을 이용하여 인증 과정을 우회하여 관리자 권한을 획득 할 수 있다.

1) 관리자 페이지의 주소에 쉽게 유추할 수 있는 이름을 사용하지 않는다.

예) http://www.xxx.com/admin.html

    http://www.xxx.com/admon_main.html

    http://www.xxx.com/admin/index.html

    http://www.xxx.com/master.html

    http://www.xxx.com/master/index.html

2) 인증 처리에 Client Side Script(Javascript)를 사용하면 사용자가 임의로 수정할 수 있으므로 Server Side Script(JSP)를 통하여 인증을 처리하여야 한다.

u  보안에 취약한 프로그램(Client Side Script)

         <HTML>

         <HEAD><TITLE> 관리자 페이지 </TITLE>

         <SCRIPT language="JavaScript“>

         function getCookie(name)

         var cname = name +"=";

         var dc = document.cookie;

         if(dc.length > 0)

         begin = dc.indexOf(cname);

         if(begin != -1)

         begin += cname.length;

         end = dc.indexOf(";", begin);

         if(end == -1) end = dc.length;

         retrun unescape(dc.substring(begin, end));

         return null;

         function getValue(element)

         var value = getCookie(element.name);

         if(value != null) element.value = value;

         </SCRIPT>

         </HEAD>

         <BODY>

         <SCRIPT language="JavaScript“>

         var auth;

        auth = getCookie("logged_in");

         if(auth != 1) // 인증 성공 쿠키가 없을경우 Main Page로 이동 

         window.location = "http://victim.com/login.html";

         </SCRIPT>

         관리자 페이지 내용 

u  안전한 프로그램(Server Side Script, 관리자 IP 확인)

    <%@ page contentType="text/html;charset=euc-kr" %>

    <%@ page import="java.util.* " %>

    <%@ page import="java.sql.* " %>

    <%

         HttpSession session = request.getSession(true);

         String user_ip = request.getRemoteAddr();

         // form 에서 사용자 id와 사용자 password를 아래 변수로 전달 

         if(!myfunc_userauth(userid, userpw) || !user_ip.equals("10.10.1.1"))

             //DB 에서 사용자 인증을 처리, 관리자 IP인지 확인 

             out.println "인증 실패";

             LogSave(userid, user_ip, 0)'접속에 실패한 ID 및 IP 기록 

         else

             //인증에 성공한 경우 처리 해야 되는 부분 

             session.putValue("logged_in","logok");

             session.putValue("userid",userid);

             session.putValue("user_ip", user_ip);

             LogSave(userid, user_ip);// 접속한 사용자 ID 및 IP기록 

             ...

1)  관리자 페이지는 사내 IP에서만 접근이 가능하도록 웹 서버에 설정한다.

Apache 웹 서버의 환경 설정 파일인 httpd.conf 파일에서 Directory 섹션의 AllowOverride  지시자에 AuthConfig 또는 All을 추가하고 아래와 같은 방법으로 수정하여 특정 IP에서만 관리자 페이지에 접근을 허용한다.

<Directory /home/www/admin/>

         AllowOverride AuthConfig (또는 All)

         Order deny, allow

         Deny from all

         Allow from 10.10.100.7 10.10.2.1/24

    </Directory>

A.  부적절한 파라미터 

개요

일반적으로 웹 어플리케이션은 HTTP 요청 값을 통해 다음 동작을 결정하게 되는데 공격자는 URL, 쿼리 문자열, HTTP 헤더, 쿠키, HTML FORM인자, HTML Hidden 필드 등 모든 HTML 요청을 변조할 수 있으며 이를 통하여 사이트 보안 메커니즘을 우회하고자 시도한다. 

보호 대책

파라미터 변조를 방지할 수 있는 가장 좋은 방법은 모든 파라미터에 대해 사용 전에 입력 값 검증을 수행하는 것이다.

모든 입력 값의 검증을 수행하는 하나의 컴포넌트나 라이브러리를 사용하는 것이 가장 효과적이다. 입력되는 모드 파라미터는 허용된 입력 값의 유형과 정확히 일치하는지에 대해 점검하여야 한다.

u  점검 항목은 다음과 같다.

1)   데이터 유형

2)   허용된 문자셋

3)   최대 / 최소 길이

4)   Null 값의 허용 여부

5)   반드시 필요한 인자와 그렇지 않은 인자

6)   중복 허용 여부

7)   숫자의 범위

u  보안에 취약한 프로그램

         <%@ page contentType="text/html;charset=euc-kr" %>

         <%@ page import="java.util.* " %>

         <HTML><HEAD><TITLE> 사이트 접속 불가 </TITLE>

         <META HTTP-EQUIV="Refresh" CONTENT="10;URL=http://victim.com/bye.html">

         </HEAD>

         <BODY>

         <%

                  out.print("지금 사용하고 계신 ");

               out.print(request.getHeader("USER-AGENT"));

                  out.print(" 브라우져로는 사이트 접속이 불가능 합니다.");

         %>

         </BODY>

         </HTML>

u  안전한 프로그램

         <%@ page contentType="text/html;charset=euc-kr" %>

         <%@ page import="java.util.* " %>

         <HTML><HEAD><TITLE> 사이트 접속 불가 </TITLE>

         <META HTTP-EQUIV="Refresh" CONTENT="10;URL=http://victim.com/bye.html">

         </HEAD>

         <BODY>

         <%

                  String user_agent = request.getHeader("USER-AGENT");

                  // HTTP HEADER 중 USER_AGENT를 변경 하여 크로스사이트 스크립트 공격하는 것을

                  // 차단 

               user_agent = user_agent.replaceAll("<","&lt;");// HTML tag가 있을 경우 제거 

               user_agent = user_agent.replaceAll(">","&gt;");

                  out.print("지금 사용하고 계신 ");

                  out.print(user_agent);

                  out.print(" 브라우져로는 사이트 접속이 불가능 합니다.");

         %>

         </BODY>

         </HTML>

B.  취약한 세션 관리(Cookie 변조) 

개요

Cookie는 사용자 정보를 유지할 수 없는 HTTP의 단점을 해결할 수 있는 방법의 하나로서 각 서버는 Cookie를 사용하여 브라우저가 갖고 있는 정보를 참조할 수 있다.

이와 같이 클라이언트에서 동작되는 쿠키는 암호화 등의 문제를 비롯하여 그 구조상 클라이언트 측에서의 조작으로 인한 다양한 문제점을 가지고 있다.

즉 인증을 처리하는 스크립트가 입력 값에 대한 적절한 검사를 하지 않았을 때 공격자는 Cookie 값을 변조하여 인증을 통과할 수 있다. 

보호 대책

Client Side Session 방식인 Cookie는 그 구조상 다양한 취약점에 노출될 수 있으므로 가능한 웹 서버에서 제공되는 Server Side Session을 사용하는 것이 바람직하다.

브라우저에 저장된 쿠키에만 의존하는 쿠키 방식보다는 서버 측에 일부 정보를 저장하여 상호 대조할 수 있는 세션(Session) 방식으로 대체하고 세션 방식의 경우도 서버 측에 사용자의 IP 정보 등을 함께 저장하여 유효성 여부를 확인하는 방식을 권한다.

클라이언트 자원을 사용하는 쿠키와는 달리 세션은 서버 쪽의 자원을 차지하고 있으므로 보안을 고려하여 세션방식을 채택하는 것이 바람직하다.

u  보안에 취약한 프로그램

         <%@ page contentType="text/html;charset=euc-kr" %>

         <%@ page import="java.util.*" %>

         <%@ page import="java.sql.* " %>

         //login_ok.jsp          // 사용자 로그인 처리를 하는 스크립트 

         <%

                  // form 에서 사용자 id와 사용자 password를 아래 변수로 전달 

                  if(!myfunc_userauth(userid, userpw)) //DB 에서 사용자 인증을 처리하는 부분 

                           out.println "인증 실패";