Zephyr...Gentle Breeze

[Unix] vi/vim 단축키 모음

서풍의신 재령 — Tue, 15 May 2012 14:18:40 +0900

▲ 클릭하면 커져요

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑨ 직무역량강화 > Unix' 카테고리의 다른 글

[Unix] vi/vim 단축키 모음 (0)	2012/05/15
[Unix] tar/untar (1)	2012/02/15
[Unix] 유닉스 명령어 (Network & Others) (0)	2011/12/14
[Unix] 유닉스 명령어 (HP-UX) (0)	2011/12/14
[Unix] 유닉스 명령어 (IBM AIX) (0)	2011/12/14
[Unix] 유닉스 명령어 (SUN SOLARIS) (0)	2011/12/14

[JAVA] LOG4J

서풍의신 재령 — Wed, 29 Feb 2012 13:57:03 +0900

=============================================
본문서는 자유롭게 배포/복사 할수 있지만
이문서의 저자에 대한 언급을 삭제하시면 안됩니다

저자 : GoodBug (unicorn@jakartaproject.com)
최초 : http://www.jakartaproject.com
=============================================

LOG4J

I. 들어가면서.. 그리고 log4j

log4j는 자바 어플리케이션에서 빠르고 효과적으로 로깅 할 수 있도록 도와주는 오픈 소스 프로젝트입니다.

로깅(logging)은 코드의 가독성을 떨어뜨리는 단점이 있지만 애플리케이션에 문제가 있을 때 개발자가 자세한 상황을 파악할 수 있도록 해 주며 테스팅시 빠질 수 없는 요소입니다.

아마도 여러분들은 여러 어플리케이션이 추가되면서 각 개발자들만의 독특한 로깅방식이 서로 섞이고 얽혀서 화면에 나타나는것을 많이 봤을겁니다. 즉, 로깅방법을 통일할 필요가 있는것이죠. 모든 개발자가 특정 포맷에 맞추어서 로깅 한다면 한결 로깅하기도 편하겠지요.

오픈 소스 프로젝트인 Log4j는 개발자들이 매우 손쉽고 다양한 형태로 로깅을 할 수 있도록 도와줍니다. 성능 또한 우수해 더이상 System.out.println을 사용할 필요가 없습니다.

II. 다운로드

다운로드 http://logging.apache.org/log4j/docs/download.html
매뉴얼 http://logging.apache.org/log4j/docs/documentation.html
API spec http://logging.apache.org/log4j/docs/api/index.html

III. LOG4J 구조

일단 log4j를 잘 모르지만 그 구조만 살짝 살펴보고 넘어갑시다

log4j는 크게 3가지 요소로 구성되며 그 구조는 다음과 같습니다

① Logger(Category) : 로깅 메세지를 Appender에 전달합니다.
② Appender : 전달된 로깅 메세지를 파일에다 기록할 것인지, 콘솔에 출력할 것인지 아니면 DB에 저장할 것인지 매개체 역할을 합니다.
③ Layout : Appender가 어디에 출력할 것인지 결정했다면 어떤 형식으로 출력할 것인지 출력 layout을 결정합니다.

IV. LOG4J 로깅 레벨

log4j는 다양한 로깅레벨을 지원합니다.

① FATAL : 가장 크리티컬한 에러가 일어 났을 때 사용합니다.
② ERROR : 일반 에러가 일어 났을 때 사용합니다.
③ WARN : 에러는 아니지만 주의할 필요가 있을 때 사용합니다.
④ INFO : 일반 정보를 나타낼 때 사용합니다.
⑤ DEBUG : 일반 정보를 상세히 나타낼 때 사용합니다.

만약 로깅 레벨을 WARN 으로 설정하였다면 그 이상 레벨만 로깅하게 됩니다.

즉 WARN, ERROR, FATAL 의 로깅이 됩니다.

V. 샘플코드 1

jsp에서 사용하는 예제가 없어 만들어 봤습니다.

test.jsp

<%@ page contentType="text/html;charset=MS949"
　 import!="org.apache.log4j.Logger" %>

<%!
　static Logger logger = Logger.getLogger("test.jsp");
%>

<%
　logger.fatal("fatal!!");

　logger.fatal("fatal2!!", new NullPointerException("널입니다요"));

　logger.error("error!", new NumberFormatException());

　logger.error("error!2");

　logger.warn("warn");

　logger.info("info");

　logger.debug("debug");
%>

결과 콘솔화면

① static Logger logger = Logger.getLogger("test.jsp");

static 메소드 getLogger를 통해 logger 인스턴스를 가져옵니다.
getLogger에는 파라미터로 스트링 혹은 클래스를 사용하는데 jsp에서는 클래스를 파라미터로 주기에는 좀 애매합니다. 그냥 스트링으로 주도록 하지요

② logger.fatal("fatal!!");

logger.fatal("fatal2!!", new NullPointerException("널입니다요"));

logger에 fatal 레벨의 메세지를 전달합니다.

다음 두가지 메소드를 지원하는군요

fatal(Object message)
fatal(Object message, Throwable t)

각 레벨마다 위처럼 두가지 메소드를 지원합니다.

지원 메소드
logger.fatal(Object message)	logger.fatal(Object message, Throwable t)
logger.error(Object message)	logger.error(Object message, Throwable t)
logger.warn(Object message)	logger.warn(Object message, Throwable t)
logger.info(Object message)	logger.info(Object message, Throwable t)
logger.debug(Object message)	logger.debug(Object message, Throwable t)

VI. 샘플코드 2

서블릿의 경우 다음과 같이 코딩하면 되겠군요

TestServlet.java

import! javax.servlet.*;
import! javax.servlet.http.*;
import! org.apache.commons.logging.Log;
import! org.apache.commons.logging.LogFactory;

public class TestServlet extends HttpServlet {
static Logger logger = Logger.getLogger(TestServlet.class);

     public void init(ServletConfig config) throws ServletException {
          super.init(config);
     }

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

          try {
               ...
               logger.info("Hellow World~");
               ...
          } catch (Exception e) {
               logger.error("Error at TestServlet", e);
          }
     }
}

VII. LOG4J 설정

log4j 설정은 프로그램 내에서 할 수 있지만 설정파일을 사용함으로서 좀더 유연하게 log4j환경을 만들 수 있습니다.

① 프로그램에서 설정

<%@ page contentType="text/html;charset=MS949"
　 import!="org.apache.log4j.*,java.io.* "
%>

<%!
　static Logger logger = Logger.getLogger("log4j.jsp");
%>

<%
　String layout = "%d %-5p [%t] %-17c{2} (%13F:%L) %3x - %m%n";
　String logfilename = "DailyLog.log";
　String datePattern = ".yyyy-MM-dd ";

　PatternLayout patternlayout = new PatternLayout(layout);
　 DailyRollingFileAppender appender = new DailyRollingFileAppender(patternlayout, logfilename, datePattern);
　 logger.addAppender(appender);
　logger.setLevel(Level.INFO);
　 logger.fatal("fatal!!");
%>

② property 파일에 설정

log4j.properties를 만들어 /WEB-INF/classes 밑에 놓으세요.

log4j.rootLogger=INFO, stdout, rolling
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %-5p [%t] %-17c{2} (%13F:%L) %3x - %m%n
log4j.appender.rolling=org.apache.log4j.DailyRollingFileAppender
log4j.appender.rolling.File=output.log
log4j.appender.rolling.Append=true
log4j.appender.rolling.MaxFileSize=500KB
log4j.appender.rolling.DatePattern='.'yyyy-MM-dd
log4j.appender.rolling.layout=org.apache.log4j.PatternLayout
log4j.appender.rolling.layout.ConversionPattern=%d %-5p [%t] %-17c{2} (%13F:%L) %3x - %m%n

#최상위 카테고리에 INFO로 레벨 설정 및 appender로 stdout, rolling을 정의
log4j.rootLogger=INFO, stdout, rolling

#stdout 어펜더는 콘솔에 뿌리겠다는 정의
log4j.appender.stdout=org.apache.log4j.ConsoleAppender

#stdout 어펜더는 patternlayout을 사용하겠다는 정의
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

#패턴은 다음과 같이 포맷팅 하겠다는 것을 정의
log4j.appender.stdout.layout.ConversionPattern=%d %-5p [%t] %-17c{2} (%13F:%L) %3x - %m%n

#역시나 rolling 어펜더는 파일로 처리한다라고 정의
log4j.appender.rolling=org.apache.log4j.DailyRollingFileAppender

#로그 파일 이름은 output.log
log4j.appender.rolling.File=output.log

#true면 톰캣을 내렸다 올려도 파일이 리셋되지 않습니다.
log4j.appender.rolling.Append=true

#파일 최대 사이즈는 500KB로 설정
log4j.appender.rolling.MaxFileSize=500KB

#파일 포맷은 output.log.2005-03-10 으로 관리하겠다고 정의
log4j.appender.rolling.DatePattern='.'yyyy-MM-dd

#역시나 rolling 어펜더는 패턴 레이아웃을 사용하겠다고 정
log4j.appender.rolling.layout=org.apache.log4j.PatternLayout

#rolling 어펜더는 패턴 레이아웃 포맷
log4j.appender.rolling.layout.ConversionPattern=%d %-5p [%t] %-17c{2} (%13F:%L) %3x - %m%n

VIII. 설정 포맷

① 로그파일명 포맷 (DatePattern)
로그파일명 포맷입니다. 날짜, 시간 및 분단위로까지 로그 파일을 분리할 수 있습니다.

형식	설명
'.'yyyy-MM	매달 첫번째날에 로그파일을 변경합니다
'.'yyyy-ww	매주의 시작시 로그파일을 변경합니다.
'.'yyyy-MM-dd	매일 자정에 로그파일을 변경합니다.
'.'yyyy-MM-dd-a	자정과 정오에 로그파일을 변경합니다.
'.'yyyy-MM-dd-HH	매 시간의 시작마다 로그파일을 변경합니다.
'.'yyyy-MM-dd-HH-mm	매분마다 로그파일을 변경합니다.

② PatternLayout 포맷
로그자체를 어떤 포맷으로 남길지 결정합니다.

layout에는 HTMLLayout, PatternLayout, SimpleLayout, XMLLayout등이 있으며 PatternLayout이 일반적으로 가장 많이 쓰입니다.

형식	설명
%p	debug, info, warn, error, fatal 등의 priority 가 출력된다.
%m	로그내용이 출력됩니다
%d	로깅 이벤트가 발생한 시간을 기록합니다. 포맷은 %d{HH:mm:ss, SSS}, %d{yyyy MMM dd HH:mm:ss, SSS}같은 형태로 사용하며 SimpleDateFormat에 따른 포맷팅을 하면 된다
%t	로그이벤트가 발생된 쓰레드의 이름을 출력합니다.
%%	% 표시를 출력하기 위해 사용한다.
%n	플랫폼 종속적인 개행문자가 출력된다. \r\n 또는 \n 일것이다.
%c	카테고리를 표시합니다 예) 카테고리가 a.b.c 처럼 되어있다면 %c{2}는 b.c가 출력됩니다.
%C	클래스명을 포시합니다. 예) 클래스구조가 org.apache.xyz.SomeClass 처럼 되어있다면 %C{2}는 xyz.SomeClass 가 출력됩니다
%F	로깅이 발생한 프로그램 파일명을 나타냅니다.
%l	로깅이 발생한 caller의 정보를 나타냅니다
%L	로깅이 발생한 caller의 라인수를 나타냅니다
%M	로깅이 발생한 method 이름을 나타냅니다.
%r	어플리케이션 시작 이후 부터 로깅이 발생한 시점의 시간(milliseconds)
%x	로깅이 발생한 thread와 관련된 NDC(nested diagnostic context)를 출력합니다.
%X	로깅이 발생한 thread와 관련된 MDC(mapped diagnostic context)를 출력합니다.

예시) (같은 색끼리 보시면 됩니다)

위의 test.jsp를 다음 포맷으로 출력해본다면

[%c] [%C] [%d] [%F] [%l] [%L] [%m] [%M] [%n] [%p] [%r] [%t] [%x] [%X]는 다음과 같다

[test.jsp] [org.apache.jsp.test_jsp] [2005-03-10 12:37:23,561] [test_jsp.java] [org.apache.jsp.test_jsp._jspService(test_jsp.java:64)] [64] [fatal!!] [_jspService] [개행] [FATAL] [765567] [http-8080-Processor25] [] []

=============================================================

기본적인 log4j.properties와 간단한 사용법

기본적인 log4j.properties

아래 로그설정은 로깅 메시지를 화면에도 출력하고 파일로도 출력한다. 파일의 경우에는 매일매일 날짜별로 다른 파일을 사용하므로 한개의 로그 파일이 무한정 커지는 것을 걱정할 필요는 없다.

이 설정대로 하면 로깅 메시지에 로그를 남긴 소스파일의 이름과 소스에서 메소드 이름과 줄 번호까지 출력된다. System.out.println()으로는 꿈도 못꾸는 기능들이다.

log4j.rootLogger = DEBUG, stdout, dailyfile
log4j.appender.stdout = org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout = org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p (%F[%M]:%L) [%d] - %m%n
log4j.appender.dailyfile.Threshold = DEBUG
log4j.appender.dailyfile = org.apache.log4j.DailyRollingFileAppender
log4j.appender.dailyfile.File = logfile.log
log4j.appender.dailyfile.layout = org.apache.log4j.PatternLayout
log4j.appender.dailyfile.layout.ConversionPattern=%5p (%F[%M]:%L) [%d] - %m%n

저기서 logfile.log 가 로그의 내용을 출력할 파일 이름이다.
적당히 다른 이름으로 바꾼다. 절대경로로 줘도되고 위와 같이 상대경로로 줘도 된다.
위 파일을 클래스패스가 걸린 디렉토리에 두면 된다.
웹 어플리케이션은 WEB-INF/classes에 두면 된다.

로그는 어떻게 남기지?
각 클래스에서 로그를 남길 때는 다음과 같이...

// 로거 임포트하기
import org.apache.log4j.Logger;

public class ClassName {

     /** Log4J 로거 얻기 */
  private Logger log = Logger.getLogger(ClassName.class);

public void method() {
      if (log.isDebugEnabled()) {
      log.debug("디버깅용 메시지");
}

log.info("정보를 남기기위한 메시지");

  try {
       // 어쩌구 저쩌구 실행...
  } catch (Exception ex) {
      // 로그에 예외 메시지도 함께 남기기
      log.error("예외가 발생했어요~~", ex);
  }
}
}

ClassName.class는 로거가 출력할 클래스의 이름이다.
그냥 항상 (클래스이름.class)로 하면 된다.

만약 static 메소드에서 로거를 사용해야 한다면 로거를 생성하는 부분을

private static Logger log = Logger.getLogger(ClassName.class);

위와 같이 static 으로 선언하면 된다.

실제로 로그 메시지 출력이 어떻게 되는지는 직접 확인해보면 알 수 있을 것이다.

출처 : http://kwon37xi.egloos.com/2176487

=============================================================

Log4j를 이용하여 로그를 기록하자!

오픈 소스 프로젝트인 Log4j를 이용하여 자바 어플리케이션에서 빠르고 효과적인 로그 서비스를 구축할 수 있다.

요약

오픈 소스 프로젝트인 Log4j는 카테고리, 어펜더, 레이아웃을 통해 개발자들이 매우 손쉽게 다양한 형태의 로깅을 할 수 있도록 해준다.

또, Log4j는 설정 파일을 이용함으로써 소스 코드를 재컴파일 할 필요 없이 런타임에 로그 정보를 변경할 수 있도록 해 주며, NDC(nested Diagnostic contexts)를 이용하여 좀 더 분석이 용이한 로그를 남길 수 있도록 해 준다.

Log4j

오늘날 프로젝트에서 많이 사용되는 웹서버, 어플리케이션 서버, DBMS를 비롯한 대부분의 상업용 어플리케이션은 그 어플리케이션에서 발생하는 사건들을 기록하기 위해 로그를 남기고 있다.

특히, 경험 많은 개발자들은 로깅은 어플리케이션 개발 및 유지보수에 있어 중요한 요소임을 지적한다.

실제로 로그 기록을 남김으로써 몇가지 장점을 얻을 수 있다. 무엇보다도 로그는 어플리케이션이 실행되는 동안의 정확한 상황과 상태 정보를 제공한다. 둘째로, 로그 출력을 파일이나 DB와 같은 곳에 기록하여 나중에 로그 결과를 분석할 수 있다. 마지막으로, 개발 기간 중에 로그 패키지를 문제 검사 툴로 사용할 수도 있다.

카테고리, 어펜더 그리고 레이아웃

Log4j는 세 개의 주요 컴포넌트를 갖고 있다.

카테고리(Category)
어펜더(Appender)
레이아웃(Layouts)

개발자는 메시지 타입과 우선순위에 따라 메시지를 기록하고 런타임에 이 메시지들의 포맷을 어떻게 작성하고 어디에 출력할지를 제어할 수 있도록 하기 위해 이 세개의 컴포넌트를 함께 사용한다.

이 세 가지 컴포넌트에 대해 차례대로 알아보도록 하자.

카테고리 계층(Category hierarchy)

몇몇 로깅 API의 가장 좋은 장점은 특정한 기준에 따라 로그를 기록할지의 여부를 결정할 수 있다는 점이다.

이것은 로그에 기록될 모든 문장들이 로깅 API 개발자가 정해 놓은 기준에 따라 분류된다는 것을 의미한다.

Log4j 역시 org.apache.log4j.Category 클래스를 통해서 이러한 분류 기준을 제시하고 있다.

Category 클래스는 org.apache.log4j 패키지의 핵심 클래스이며, 카테고리를 나타낸다. 카테고리는 이름을 가진 개체이다. 카테고리의 이름은 자바의 패키지 이름과 비슷한 구조를 갖는다. 즉, 카테고리 이름은 com.javacan과 같은 형태를 가진다.

이 이름에 따라 카테고리는 부모 카테고리와 자식 카테고리로 구분된다.

예를 들어, com.javacan의 부모 카테고리의 이름은 com 이며, 이름이 com.javacan.article인 카테고리는 com.javacan의 자식 카테고리가 되는 것이다. 따라서, 카테고리 사이에는 계층이 형성된다. 계층의 가장 상위에 있는 카테고리를 루트 카테고리라고 하며, 루트 카테고리는 다음과 같은 특징을 갖고 있다.

1. 루트 카테고리는 항상 존재한다.
2. 이름을 사용하여 루트 카테고리를 읽어올 수 없다.
3. Category 클래스의 static 메소드인 getRoot() 메소드를 사용하여 루트 카테고리를 구할 수 있다.

static 메소드인 getInstance() 메소드는 모든 다른 카테고리의 인스턴스를 생성한다.
getInstnace() 메소드는 원하는 카테고리의 이름을 파라미터로 입력받는다.

Category 클래스의 몇몇 기본 메소드는 다음과 같다.

package org.apache.log4j;

public class Category {

// Creation & retrieval! methods:
public static Category getRoot();
public static Category getInstance(String name);

// printing methods:
public void debug(String message);
public void info(String message);
public void warn(String message);
public void error(String message);

// generic printing method:
public void log(Priority p, String message);
.......
}

카테고리마다 org.apache.log4j.Priority 클래스에 정의된 값을 사용하여 우선순위를 지정할 수 있다.

현재 Priority 클래스에는 FATAL, ERROR, WARN, INFO, DEBUG의 5개의 우선순위가 정의되어 있다. 나열한 순서대로 우선 순위가 낮아진다.

겉으로 보기에 제한된 집합을 갖도록 한 이유는 정적인 우선순위 집합보다 더욱 더 유연한 카테고리 계층을 만들 수 있도록 하기 위해서이다.

하지만, Priority 클래스를 상속받아서 자신만의 우선순위를 정의할 수도 있다.

만약 주어진 카테고리가 할당된 우선순위를 갖고 있지 않다면, 카테고리 계층도에서 할당된 우선순위를 갖고 있는 가장 가까운 상위 카테고리로부터 우선순위를 상속받는다.

따라서 루트 카테고리가 할당된 우선순위를 갖고 있을 경우 결과적으로 모든 카테고리가 그 우선순위를 상속받게 된다. 로깅 요청은 카테고리 인스턴스의 출력 메소드 중 하나를 호출하면 된다.

출력 메소드는 다음과 같다.

error()
warn()
info()
debug()
log()

출력 메소드는 로깅 요청의 우선순위를 결정한다.

예를 들어, cat가 카테고리 인스턴라고 할 경우,
cat.info("....")는 INFO 우선순위로 로깅을 요청한다.

만약 현재 요청한 로깅의 우선순위가 카테고리의 우선순위와 같거나 높으면 그 로깅 요청이 가능하다고 말한다. 그렇지 않을 경우 그 요청은 불가능하다고 한다.

다음은 로깅 요청의 가능/불가능 여부가 어떻게 처리되는 지를 보여주는 예이다.

// 이름이 "com.foo"인 카테고리 인스턴스를 구한다.
Category cat = Category.getInstance("com.foo");

// 카테고리의 우선순위를 설정한다.
cat.setPriority(Priority.INFO);

// WARN >= INFO 이기 때문에, 이 요청은 가능하다.
cat.warn("Low fuel level.");

// DEBUG < INFO 이기 때문에, 이 요청은 불가능하다.
cat.debug("Starting search for nearest gas station.");

// 이름이 "com.foo.Bar"인 카테고리의 인스턴스를 생성한다.
// 이 카테고리는 이름이 "com.foo"인 카테고리를 상속 받는다.
// 따라서 이 카테고리 인스턴스는 INFO 우선순위를 갖는다.
Category barcat = Category.getInstance("com.foo.Bar");

// INFO >= INFO 이므로, 이 요청은 가능하다.
barcat.info("Located nearest gas station.");

// DEBUG < INFO 이므로, 이 요청은 불가능하다.
barcat.debug("Exiting gas station search");

같은 이름을 사용하여 getInstance() 메소드를 호출하면 항상 같은 카테고리 오브젝트에 대한 레퍼런스를 리턴한다.

따라서, 일단 특정한 이름을 갖는 카테고리 인스턴스를 설정하면, 그 인스턴스의 레퍼런스를 전달할 필요 없이 프로그램내의 어떤 곳에서든지 그 카테고리의 인스턴스를 읽어올 수 있으며, 특정한 순서없이 카테고리를 생성 및 설정할 수 있다.

또한, 자식 카테고리를 생성한 이후에 부모 카테코리를 찾고 연결할 수 있다.

Log4j 환경은 일반적으로 어플리케이션을 초기화할 때 설정하는데, 설정 파일을 읽어오는 시점에서 설정하는 경우가 많다.

Log4j에서 카테고리의 이름은 그 카테고리의 인스턴스를 생성할 때 사용한 클래스의 완전한 이름과 동일하게 짓는 것이 카테고리를 정의하는 직관적인 방법이다.

로그에는 카테고리를 생성할 때 사용한 이름이 기록되기 때문에, 카테고리의 이름이 클래스의 이름과 일치하도록 하는 방법은 로그 메시지의 출처를 구분하는 데에도 도움을 준다.

이러한 방법이 일반적이지만, 이외에도 다양한 방법을 사용하여 카테고리의 이름을 지을 수 있다.

Log4j는 가능한 카테고리의 집합을 제한하고 있지 않으며, 개발자는 카테고리의 이름을 원하는 대로 지을 수 있다.

어펜더와 레이아웃

Log4j는 카테고리에 기반하여 로깅 요청의 가능/불가능 여부를 결정하는 기능 뿐만 아니라, 로깅 요청을 다중의 어펜더(appender)에 출력할 수 있다.

여기서 어펜더는 출력의 목적지를 나타낸다.

현재 콘솔, 파일, GUI 컴포넌트, 원격 소켓 서버, NT 이벤트 로거 그리고 원격 유닉스 시스로그 데몬으로 연결되는 어펜더가 존재한다.

카테고리는 다중의 어펜더를 참조할 수 있다.

카테고리에 들어온 각각의 가능한 로깅 요청은 그 카테고리에 있는 모든 어펜더에 전달되며, 뿐만 아니라 카테고리 계층의 상위에 있는 어펜더에도 전달된다.

즉, 어펜더는 카테고리 계층으로부터 상속된다.

예를 들어, 루트 카테고리에 콘솔 어펜더를 추가했다면, 모든 가능한 로깅 요청은 적어도 콘솔에 로그 메시지를 출력할 것이다.

만약 C라고 불리는 카테고리에 파일 어펜더를 추가했다면, C와 C의 자식 카테고리에 대한 가능한 로깅 요청은 콘솔과 파일에 메시지를 출력할 것이다. 또한 출력 목적지 뿐만 아니라 출력 형식도 변경할 수 있다.

각각의 어펜더는 그 어펜더에 출력될 메시지의 형식을 가지고 있으며, 이는 그 어펜더와 특정 레이아웃(layout)을 관련시킴으로써 가능해진다.

레이아웃은 사용자가 지정한 값에 따라 로깅 요청의 포맷을 결정하고, 어펜더는 레이아웃을 통해 포맷된 로그 내용를 그것의 목적지에 출력한다.

Log4j의 표준 배포판에 있는 PatternLayout은 사용자가 C 언어의 printf() 함수와 비슷한 변환 패턴에 따라 출력 포맷을 지정할 수 있도록 해준다.

예를 들어, 변환 패턴이 %r [%t]% -5p %c - %m%n 인 PatternLayout은 다음과 비슷한 결과를 출력한다.

176 [main] INFO org.foo.Bar - Located nearest gas station.

위의 출력 결과는 다음과 같다.

첫번째 필드는 프로그램이 시작한 이후 경과한 시간(1/1000초 단위)을 나타낸다.
두번째 필드는 로그 요청을 한 쓰레드를 나타낸다.
세번째 필드는 로그의 우선순위를 나타낸다.
네번째 필드는 로그 요청과 관련된 카테고리의 이름을 나타낸다.
나머지는 로그에 기록할 메시지이다.

--------------------------------------------------------------------------------
프로바이더 mailto: madvirus@madvirus.net
현재 티페이지 글로벌(주)의 기술연구소에 있으며,
'JSP 웹 어플리케이션 개발(가메출판사)'을 이동훈씨와 함께 저술한 바 있다.
--------------------------------------------------------------------------------
관련링크
Log4j 프로젝트 홈페이지
http://jakarta.apache.org/log4j/index.html
Sun 의 로깅 API 규약
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_047_log.html
--------------------------------------------------------------------------------

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑨ 직무역량강화 > 기타' 카테고리의 다른 글

[JAVA] LOG4J (0)	2012/02/29
[JAVA] javac options (0)	2012/02/15
[보안] CC(Common Criteria) (0)	2012/01/12
[보안] httpOnly Cookie (0)	2012/01/11
[MS-DOS] MS-DOS창에서 코드 페이지 변경하는 방법 (0)	2011/11/04
[성능] MIPS (0)	2010/02/12

[Unix] tar/untar

서풍의신 재령 — Wed, 15 Feb 2012 15:12:41 +0900

Unix 환경에서 tar 묶고 풀 일이 없다보니 가끔 쓸 때마다 옵션이 맨날 헛갈려서 가져옴.

- tar 풀기 (untar)

1) tar xvf xxx.tar -C /home/directory/

2) tar xvf /home/directory/ xxx.tar

** -C 는 디렉토리를 경로를 가리키며 -C 로 경로를 만들어 놓으면 그 경로에 xxx.tar 가 풀리게 됨

- tar 묶기 (tar)

tar cvf xxxx.tar yyyy

yyyy 라는 폴더를 xxxx.tar 로 묶는다는 것. (하위 디렉토리 포함)

- tar options

-x, --extract, --get 아카이브에서 파일을 추출합니다

-v, --verbose verbosely list files processed

--checkpoint print directory names while reading the archive

--check-links print a message if not all links are dumped

--totals print total bytes written while creating archive

--index-file=FILE send verbose output to FILE

--utc print file modification dates in UTC

-f, --file=ARCHIVE use archive file or device ARCHIVE

--force-local archive file is local even if has a colon

--rmt-command=COMMAND use given rmt COMMAND instead of /etc/rmt

--rsh-command=COMMAND use remote COMMAND instead of rsh

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑨ 직무역량강화 > Unix' 카테고리의 다른 글

[Unix] vi/vim 단축키 모음 (0)	2012/05/15
[Unix] tar/untar (1)	2012/02/15
[Unix] 유닉스 명령어 (Network & Others) (0)	2011/12/14
[Unix] 유닉스 명령어 (HP-UX) (0)	2011/12/14
[Unix] 유닉스 명령어 (IBM AIX) (0)	2011/12/14
[Unix] 유닉스 명령어 (SUN SOLARIS) (0)	2011/12/14

[JAVA] javac options

서풍의신 재령 — Wed, 15 Feb 2012 14:30:23 +0900

- 출처 : http://letmelove.net/blog/entry/javac-%EC%98%B5%EC%85%98%EA%B3%BC-java%EC%98%B5%EC%85%98

javac

- 자바 컴파일러로서 자바코드를 작성한 소스파일(.java)을 자바 가상머신이 인식할수 있는 바이트 코드(.class)

타입으로 변환시켜주는 명령어 입니다.

- 사용법

javac <options> <souce files>

예를들어, Hello.java, Greeting.java 두개의 파일이 존재한다면,

javac Hello.java Greeting.java

javac *.java (*을 사용해서, 모든 확장자가 .java인 파일을 컴파일할수 있다.)

1) 옵션

a) -classpath

-classpath(cp) path(파일 절대 경로)

컴파일러가 컴파일 하기 위해서 필요로 하는 참조할 클래스 파일들을 찾기 위해서 컴파일시 파일 경로를 지정해주는

옵션. 예를 들어, Hello.java파일이 C:\Java 디렉터리에 존재하고, 필요한 클래스 파일들이 C:\Java\Engclasses에 위치한다면

javac -classpath C:\Java\Engclasses C:\Java\Hello.java

로 해주면 된다. 만약 참조할 클래스 파일들이 C:\Java\Engclasses 외의 다른 디렉토리에도 존재 한다면
C:\Java\Korclasses 일 경우

javac -classpath C:\Java\Engclasses;C:\Java\Korclasses C:\Java\Hello.java

그리고 현재 디렉토리 역시 포함하고 싶다면

javac -classpath .;C:\Java\Engclasses;C:\Java\Korclasses C:\Java\Hello.java

기본적으로 dos 에서는 .는 현재 디렉토리를 의미하고 ..는 현재 디렉토리의 상위디렉토리를 의미한다.

또한 classpath 대신 단축어인 cp를 사용해도 된다.

javac -cp C:\Java\Engclasses C:\Java\Hello.java

** 유닉스에서 클래스 경로(classpath) 항목은 콜론(:) 으로 구분한다.
** 윈도우에서 클래스 경로(classpath) 항목은 세미콜론(;) 으로 구분한다.

b) -d

-d directory

클래스 파일을 생성할 Root 디렉토리를 지정한다.

기본적으로 컴파일러는 -d 옵션을 주지 않으면 소스파일이 위치한 디렉토리에 클래스 파일을 생성시킨다.

예를 들어 Hello.java파일이 C:\Java 디렉토리에 존재하고 클래스 파일의 Root 디렉토리를 C:\Java\Classfiles 라고 하면

javac -d C:\Java\Classfiles C:\Java\Hello.java

이다.

만약 -d 옵션을 사용하려고 하는데 Root 디렉토리(위예에서는 C:\Java\Classfiles) 가 존재 하지 않는다면

"The system cannot find the path specified"라는 에러 메시지를 보게 된다.

현재 작업 디렉토리가 C:\Java\Classfiles 에 위치하면

javac -d .\Classfiles Hello.java 와 같이 상대 디렉토리로 표현할수 있다.

java class내에서 package를 선언한 경우 package별 폴더를 생성하고 해당 폴더에(package) compile 한다.

c) -encoding

-encoding encoding name

소스 파일에 사용된 문자열 인코딩을 설정한다.

만약 위 옵션이 설정되어 있지 않으면 플랫폼의 기본적인 컨버터가 사용되어 진다.

d) -g

모든 디버깅 정보를 생성시킨다.

만약 위 옵션이 설정되어 있지 않으면 기본적으로 라인넘버만 생성시킨다.

-g:none

디버깅 정보를 전혀 생성 시키지 않는다.

-g:{lines, vars, source}

위처럼 명시적으로, 몇몇 디버깅 정보를 생성시킬수 있다.

lines은 라인정보, vars는 지역변수, sounce는 소스 파일 정보를 나타낸다.

e) -nowarn

경고 메시지 (warning message)를 생성시키지 않는다.

f) -verbose

컴파일러와 링커가 현재 어느 소스파일이 컴파일되고 있고, 어느 파일이 링크되고 있는지 그 정보를 출력한다.

h) -deprecation

소스 코드 내에서 사용되어진 deprecated API의 위치를 출력한다.

eg)

C:\Java> javac World.java

Note: World.java uses a deprecated API. Recompile with "-deprecation" for details.

1 warning

C:\Java> javac -deprecation World.java

World.java:52: Note: The method java.awt.Dimension size() in class java.awt.Compon

ent has been deprecated.

Dimension d = size();

Note: World.java uses a deprecated API. Please consult the documentation for a be

tter alternative.

i) -sourcepath

-sourcepath 소스패스

소스파일의 위치를 지정한다.

j) -target

-target 자바 가상머신버전

지정된 자바 가상머신 버전의 VM에서 작동되어지도록 클래스 파일을 생성시킨다.

1.1

jvm 1.1 버전에서 호환되어 질 수 있는 클래스 파일생성

1.2

jvm 1.2 버전에서 호환되어 질 수 있는 클래스 파일생성

1.3

jvm 1.3 버전에서 호환되어 질 수 있는 클래스 파일 생성

ex)

javac -target 1.2 Helloworld.java

k) -bootclasspath 패스

특정한 bootstrap 또는 확장 클래스를 지정할 수 있다.

기본적으로 자바 컴파일러는 javac 가 설치된 플랫폼의 bootstrap과 확장 클래스들을 통해서 컴파일 작업을 수행하지만 bootclasspath 옵션을 사용하면 cross-compiling 이라고 해서 다른 JAVA 플랫폼의 bootstrap과 확장 클래스들을 통해서 compile 할 수 있는 기능을 지원한다.

예를들어

javac -target 1.1 -bootclasspath jdk1.1.7/lib/classes.zip -extdirs "" OldCode.java

컴파일러에게 현재 자신의 bootstrap을 사용하지 말고 jdk1.1.7/lib/classes.zip bootstrap 클래스들을 사용해서 컴파일 하라고 명령하는것이다.

참고로 mobile JAVA에서 모바일폰에 설정 된 jvm에 맞도록 소스코드를 컴파일하기 위해서 주로 사용되어지는 옵션이다.

l) -extdirs 디렉토리

특정한 확장 디렉토리를 지정한다. cross-compiling 시 주로 사용되어지는 옵션이면 각 디렉토리들은 콜론(:)에 의해서 분리되어진다. 컴파일 시점에 기술한 디렉토리의 클래스 파일을 참조한다.

M) package 선언된 Java class 실행

java package.class명 (현 위치 아래에 package폴더가 존재)

package 위치는 CLASSPATH 하위 폴더부터로 인식한다. 따라서 Package 폴더의 Root가 ClassPath에 지정되든지 .(현 위치)를 ClassPath에 등록 후 현 위치 아래서부터 package의 위치를 지정한다.

java com.test.SampleMain

###################################################################

javac options

###################################################################

Usage: javac <options> <source files>

where possible options include:

-g Generate all debugging info

-g:none Generate no debugging info

-g:{lines,vars,source} Generate only some debugging info

-nowarn Generate no warnings

-verbose Output messages about what the compiler is doing

-deprecation Output source locations where deprecated APIs are used

-classpath <path> Specify where to find user class files and annotation processors

-cp <path> Specify where to find user class files and annotation processors

-sourcepath <path> Specify where to find input source files

-bootclasspath <path> Override location of bootstrap class files

-extdirs <dirs> Override location of installed extensions

-endorseddirs <dirs> Override location of endorsed standards path

-proc:{none,only} Control whether annotation processing and/or compilation is done.

-processor <class1>[,<class2>,<class3>...]

Names of the annotation processors to run; bypasses default discovery process

-processorpath <path> Specify where to find annotation processors

-d <directory> Specify where to place generated class files

-s <directory> Specify where to place generated source files

-implicit:{none,class} Specify whether or not to generate class files for implicitly referenced files

-encoding <encoding> Specify character encoding used by source files

-source <release> Provide source compatibility with specified release

-target <release> Generate class files for specific VM version

-version Version information

-help Print a synopsis of standard options

-Akey[=value] Options to pass to annotation processors

-X Print a synopsis of nonstandard options

-J<flag> Pass <flag> directly to the runtime system

Usage: java [-options] class [args...]

(to execute a class)

or java [-options] -jar jarfile [args...]

(to execute a jar file)

where options include:

-client to select the "client" VM

-server to select the "server" VM

-hotspot is a synonym for the "client" VM [deprecated]

The default VM is client.

-cp <class search path of directories and zip/jar files>

-classpath <class search path of directories and zip/jar files>

A ; separated list of directories, JAR archives, and ZIP archives to search for class files.

-D<name>=<value>

set a system property

-verbose[:class|gc|jni]

enable verbose output

-version print product version and exit

-version:<value>

require the specified version to run

-showversion print product version and continue

-jre-restrict-search | -jre-no-restrict-search

include/exclude user private JREs in the version search

-? -help print this help message

-X print help on non-standard options

-ea[:<packagename>...|:<classname>]

-enableassertions[:<packagename>...|:<classname>]

enable assertions

-da[:<packagename>...|:<classname>]

-disableassertions[:<packagename>...|:<classname>]

disable assertions

-esa | -enablesystemassertions

enable system assertions

-dsa | -disablesystemassertions

disable system assertions

-agentlib:<libname>[=<options>]

load native agent library <libname>, e.g. -agentlib:hprof

see also, -agentlib:jdwp=help and -agentlib:hprof=help

-agentpath:<pathname>[=<options>]

load native agent library by full pathname

-javaagent:<jarpath>[=<options>]

load Java programming language agent, see java.lang.instrument

-splash:<imagepath>

show splash screen with specified image

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑨ 직무역량강화 > 기타' 카테고리의 다른 글

[JAVA] LOG4J (0)	2012/02/29
[JAVA] javac options (0)	2012/02/15
[보안] CC(Common Criteria) (0)	2012/01/12
[보안] httpOnly Cookie (0)	2012/01/11
[MS-DOS] MS-DOS창에서 코드 페이지 변경하는 방법 (0)	2011/11/04
[성능] MIPS (0)	2010/02/12

[Windows 7] GodMode

서풍의신 재령 — Mon, 30 Jan 2012 09:14:38 +0900

새 폴더 생성 후 폴더 이름을 GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} 로 바꿈

GodMode 는 생성되는 폴더의 이름이 되기 때문에 사용자 취향대로 바꾸어 사용이 가능

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑤ Tips & Info > IT Tips' 카테고리의 다른 글

[Windows 7] GodMode (0)	2012/01/30
[ER-win] Notation 표기법 변경 (0)	2010/04/13
[IT] Autonomous System (AS) (0)	2008/11/10
Shift 키의 숨겨진 10가지 기능 (0)	2008/10/09
[Tip] Windows XP 에서 C$ 접근 및 net send 실행 (0)	2008/08/19

[Design Pattern] Observer Pattern

서풍의신 재령 — Wed, 18 Jan 2012 23:00:30 +0900

옵저버 패턴 (Observer Pattern)

Type - Behavioral

한 객체(Subject)의 상태가 바뀌면 그 객체에 의존하는 다른 객체(Observer)들 에게 연락이 가고 자동으로 내용이 갱신되는 1:n (one-to-many) 의존성을 정의함

적용 예시 )

1. Observer Pattern 적용

2. JDK 내장 Observable Class, Observer Interface 사용

- Java 구현 Src

observer.zip

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑨ 직무역량강화 > Design Patterns' 카테고리의 다른 글

[Design Pattern] Observer Pattern (0)	2012/01/18
[Design Pattern] Strategy Pattern (0)	2012/01/18

[Design Pattern] Strategy Pattern

서풍의신 재령 — Wed, 18 Jan 2012 22:06:11 +0900

스트래티지 패턴 (Strategy Pattern)

Type - Behavioral

동일 계열의 알고리즘군을 정의하고 각각의 알고리즘을 캡슐화하여 이들을 상호 교환해서 사용할 수 있도록 만든다. 스트래티지를 활용하면 알고리즘을 사용하는 클라이언트와는 상관없이 독립적으로 알고리즘을 다양하게 변경할 수 있다.

적용 예 )

- 패턴 적용

- Java 구현 Src

strategy.zip

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑨ 직무역량강화 > Design Patterns' 카테고리의 다른 글

[Design Pattern] Observer Pattern (0)	2012/01/18
[Design Pattern] Strategy Pattern (0)	2012/01/18

[CISSP] Domain 10. 물리적 통제

서풍의신 재령 — Fri, 13 Jan 2012 15:16:59 +0900

▶ 컴퓨팅 시설 설계 시 요구사항
- 위치 선정 이슈
      - 가시성 : 낮은 가시성(눈에 잘 띄지 않는 곳), 건물 표시 및 간판
      - 지역 환경 : 주위 환경의 위험, 범죄율, 인구밀도, 자연재해
      - 교통 : 접근성 확보, 과도한 교통량은 피함, 다른 교통수단과의 인접성
      - 기타 : 응급서비스의 인접성, 공동 소유 시 비상 상황에 대한 통제 고려

- 사이트 설계 및 구축 시 이슈
      - 벽 : 일반적인 경우 화재에 대하여 기본적으로 1시간을 버틸 수 있어야 함
              미디어나 문서 등 중요정보를 보관 시 2시간을 버틸 수 있어야 함
              바닥부터 천장까지 완전히 밀폐 되어야 함
              물리적 침투나 관통을 막을 수 있어야 함

      - 천장 : 방수가 되어야 함
                 벽과 같은 정도의 방화등급이 필요

      - 바닥 : 적절한 하중(1Sq당 150파운드)을 지탱할 수 있어야 함
                 표면에 불에 타지 않는 재질이어야 함
                 이중바닥은 정전기 방지를 위해 접지되어 있어야 하며 표면도 정전기 방지용 소재 사용

      - 출입문 : 외부에서 안으로 강제적으로 진입할 수 없어야 함
                    비상구를 분명히 표시 하여야 함
                    비상시 탈출을 대비하여 안에서 밖으로 열리도록 설계 되어야 함
                    (경첩은 문의 바깥쪽으로 보이도록 붙어있어야 함)
                    비상 시 사용이 용이하게 문의 안쪽에 Panic Bar를 설치하여야 함
                    전기 잠금장치가 설치될 경우 비상 시 안전한 탈출을 위해 자동으로 문이 열리도록 설계(Fail-Soft)
                    문에 유리 사용 시 비산 방지용과 방탄용이 사용될 수 있음(Shatterproof)
                    보안 강화를 위해 회전문(Turnstile), Mantrap(한번에 한명씩 통과하도록 설계)을 설치할 수 있음

      - 창문 : 데이터 센터에는 청문이 허용되지 않음
                 불가피한 경우 창을 열수 없는 고정 창으로 설계함(Fixed)
                 불투명이나 반투명(Translucent) 유리를 사용해야 함(Opaque)

      - 급수, 스팀, 가스관 : 자동 혹은 수동으로 차단 할 수 있는 밸브 설치
                                    외부로부터 오염된 물질(물, 공기)이 역류되어 들어올 수 없도록 Positive Flow 유지

      - 난방, 통풍, 공기조절기(HVAC : Heat, Ventilation, Air Conditioner)
                                        외부로부터 오염된 공기가 역류되어 들어올 수 없도록 Positive Air Pressure 유지
                                        공기 흡입구의 경우 외부 유해가스, 먼지가 들어오는 것을 방치
                                        에어컨의 경우 전용 전력공급을 받아야 함(Dedicated Power Lines)

- 주요 고려사항
      - 건축 자재 : 적절한 방화등급을 가지고 있어야 함

      - 내부 칸막이 : 칸막이와 천장 사이의 공간(Hung Ceiling) 다 막혀 있어야 함

      - 외장재 : 정전기 방지용 외장재를 사용하여야 함
                    모든 외장재는 정전기 방지용 이외에는 사용할 수 없음

      - 전산실 배치 : 지하의 경우 홍수시 침수의 피해가 예상되어 적절하지 않음
                           맨 위층의 경우 화재 시 큰 피해가 예상되므로 적절하지 않음
                           지하와 맨 위층은 실내 온도 조절이 힘들어 적합하지 않음
                           중간층이 적절함(5층 건물의 3층정도 위치)
                           기업 내 가장 핵심적이고 안전한 지역에 위치함
                           반드시 단 하나의 출입문을 통해서만 진입이 가능해야 함

      - 정상적 배출

▶ 위협 정의
- 전력 취약점
      - 완전 정전(blackout) : UPS나 백업 전원이 필요
      - 전압의 심각한 감소(brownout) : Auto Voltage Regulator(AVR, 자동 전압 조절기) 필요
      - 단기적인 전압 상승/하락(sags, spikes, surges)
          - 과전압(surge) : 매우 빨리 큰 피해를 줄 수 있음
                                   Electronic Surge Protector(ESP)로 통제

- 노이즈(Noises)
      - Clean Power : 불안정하지 않은 전력
      - Transient Noise : 일시적인 전력 불안정
      - Ground : 과전압 방지를 위해 지면에 접지하는 회선

      - 전자파 장애(EMI, Eloctromagnetic Interference)
      - 무선 주파수 장애(RFI, Radio Frequency Interference)

- 습도
      - 컴퓨팅 설비의 운영에 적합한 습도 40~60%
      - 낮은 습도(40% 이하)의 경우 정전기로 인한 손상 가능성, 20,000V 이상의 전하랑이 만들어 짐
      - 높은 습도(60% 이상)의 경우 부식이나 누전이 발생

▶ 통제
- 전력 보호 대책
      - UPS(Uninterrupted Power Supply, 무정전 전원 공급장치)
          - 안전한 전원 종료를 위해 전기를 공급하는 UPS
          - 계속해서 시스템을 운영하기 위한 UPS
          - 평상시 축전지에 충전시켰다가 비상 시 일정 시간동안 전원 공급
          - 장시간 전원 공급의 경우 발전기가 필요
          - 평상시 교류를 직류로 전환하여 축전지에 충전하였다가 사고 시 인버터로 교류로 재변환시켜 전원공급

      - 백업 전원 : Backup Sources, 비상 발전기

      - 전력 조절기 : Power Conditioner, Line Conditioner
                          전원 공급장치와 컴퓨터 사이에 설치되어 안정된 전력을 공급

- 노이즈 예방 대책
      - Power Conditioner 사용
      - 적절한 접지 필요
      - 케이블 shielding
      - 연장 코드 사용 최소화

- 정전기 예방 대책
      - 적절한 습도 유지
      - 정전기 방지 소재를 이용
      - 적절하게 접지하여야 함

- 기타 예방 대책
      - 두가닥 콘센트는 적절한 잡지를 위해 세가닥 콘센트로 대치 해야 함
      - 진공청소기, 전열장치는 전력소모량이 많아 과부하가 걸릴 위험이 있어 컴퓨팅 장치와 함께 연결하지 않음

▶ 난방, 환기와 에어컨
- 난방(Heating)
      - 시스템 운영에 가장 적절한 온도 : 70~74℉ (21~23℃)
      - 75℉ 이상 고온 지속 시 과열로 인해 운영 중단 가능성
      - 70℉ 미만 저온 지속시 시스템 활동을 느리게 하여 중단 가능성

- 환기와 에어컨
      - 공기의 질은 컴퓨팅 설비에 영향을 미침
      - 먼지는 팬에 붙어 기기의 성능을 저하시킴
      - Positive Pressure : 실내 공기가 밖으로 나가기만 하고 외부 공기 유입시 반드시 여과장치를 거치도록 함
      - 폐회로 공기 순환 시스템을 이용 : 실내 공기를 순환시켜 사용
      - 공기 흡입구 보호 : 반드시 필터링(여과장치)
      - 기타 환경 통제 : 환기와 에어컨은 전용 전원을 사용하여야 함

▶ 화재 탐지 및 진화
- 화재 탐지
      - 탐지기는 연기(smoke), 고열(heat), 화염(flame), 유독가스(gas)를 이용해 화재를 탐지
      - 천장, 천장 틈(Suspended Ceiling 위), 바닥(Raised Floor) 밑, 공기 통풍구(Air Vent) 등 여러곳에 설치

      - 연기 탐지기 : Smoke Detector
                           연기의 조기 탐지가 가능한 통풍구에 주로 설치
                           광전자 연기 탐지기 - 적외선이나 빔을 발사하여 감지
                           방사능 연기 탐지기 - 연기와 열에 의해 동요된 방사성 물질로 이온하 기류를 감지

      - 열 탐지기 : Heat Detector
                        온도가 일정 수준에 도달하거나 빠르게 상승하는 경우 화재 인지
                        고정 온도 센서 - 일정 수준에 도달하면 탐지
                        온도 상승 속도 센서 - 온도가 빠르게 상승하는 경우 탐지

      - 화염 탐지기 : Flame Detector, 고비용
                           화염에서 발생하는 파동이나 자/적외선 감지

      - 자동 통보 경보장치 : Automatic Dial-Up Alarm, 저비용

- 화재 진화
      - 산화를 위한 3요소 : 산소(Oxygen), 열(Heat), 연료(Fuel)
      - 진화 시 세가지 요소 중 한가지 혹은 그 이상의 공급을 차단

      - 진화 매체
          - 물(Water) : 온도를 저하시켜 화재를 진화 함

          - 소다산(Soda Acid, 탄산 나트륨) : 연료 공급 차단

          - 이산화탄소 : 산소 공급 차단, 사람이 상주하지 않는 무인 시설에만 사용
                              이산화탄소의 방출을 취소할 수 있는 기능이 있어야 함

          - 할론(Halon) : 오존 파괴 물질로 지정되어 생산이 중단 됨
                                인체와 장비에 미치는영향이 적고 빨리 퍼지는 특성
                                FM-200(매우 고비용), Argon 또는 Argonite 등 을 대체물질로 지정

      - 진화 시스템(Water Sprinkler System)
          - 습식(Wet Pipe) : 항상 파이프 안에 물을 보유하고 있는 시스템
                                    폐쇄 헤드 시스템(Close Head System)
                                    주기적인 점검이 필요, 누수 및 동파의 위험

          - 건식(Dry Pipe) : 항상 파이프 안에 압축된 공기를 보유하고 있는 시스템
                                    물탱크에 물을 보유
                                    습식에 비해 화재에 신속한 대응이 불가

          - 사전 작동식(Preaction) : 습식과 건식을 결합한 형식

          - 범람식(Deluge) : 개방형 헤드를 가지고 있어 단시간에 특정 지역에 많은 양의 물을 살포(건식)

          - 진화 시스템(Gas Discharge System) : 압축된 비활성 가스를 사용
                                                                  Argon 또는 Argonite가 가장 이상적인 매체
                                                                  주로 Raise Floor 에 설치

          - 각종 소화기

▶ 컴퓨팅 시설 통제 요구사항
- 담장(Fences) : 일반적으로 출입문, 회전문, 맨트랩과 함께 접근 통제 수단으로 사용
                          침입 의사 없이 경계를 넘어 오는 것을 방치
                          의도적 침입자를 막을수 없지만 지연 가능
                          군중의 대규모 진입을 방지

                          3~4 ft (1m) → 충동적 침입 저지 (Deter Casual Trepassing)
                          6~7 ft (2m) → 쉽게 넘기 어려운 높이 (Too High to Climb Easily)
                          8 ft (2.4m) + 철조망 → 의도적 침입 저지 (Deter Determined Intruder)

- 조명(Lighting) : 흔히 사용되는 주변 경계 보호 수단
                           핵심적인 건물에 대해서는 8 feet 높이, 2 촉광(feet candle) 이상으로 조명을 비추어야 함

- 잠금장치(Locks) : 침입 지연 수단
                              보안요원과 함께 사용

- 감시장치(Surveillance Devices) : 보안요원, CCTV, 보안견 등을 통해 가능, 다른 보안 매커니즘과 결합 사용
      - 보안요원 : 가장 고전적이며 최상의 보안 방안
                       모든 물리적 보안 장치들은 결국 사람의 행동이 필요함
                       다른 Hardware 나 보안장치에 배히 융통성있고 훌륭한 방해물로 작용
                       비상상황 시 인명 대피에 가장 좋은 수단
                       다른 보안요소의 요청에 즉각적이고 식별력있는 판단이 요구되는 상황에 적합

      - 보안견 : 무단 침입이나 이상 상황을 감시하는데 유용
                    비싼 유지비용, 관리의 어려움, 짧은 수명

      - CCTV : Closed Circuit TV
                   보안요원의 감시능력을 확장시켜 줌
                   보안요원의 실수, 근무 태만을 대비해 다른 시스템(IDS, Alarm System) 과 결합하여 사용

▶ 컴퓨팅 시설 접근 통제 및 침입 탐지
- 접근 통제(Personal Access Controls)
      - 보안 접근 카드 : 더미카드(정보를 가지고 있지 않음), 마그네틱카드(정보를 저장)

      - 무선 근접 판독기 : RFID를 주로 사용
                                  사용자 반응형, 시스템 감지형(수동장치, 전류유도장치, 송수신장치)

- 침입 탐지(Intrusion Detection) : 비디오 동작 탐지기
                                                 전자기 접촉 스위치
                                                 소음 탐지기
                                                 파장 탐지기
                                                 근접 탐지 시스템 (전기장의 전하량 탐지)
                                                 광전/광도 측정 시스템 (전기적 장애물)

- 경보(Alarm) : 로컬 경보 시스템 (일반적으로 400 ft 거리까지 경보를 울림)
                        중앙 스테이션 시스템 (경보 후 얼마나 빨리 도착하여 대응하는가가 이슈)
                        단독 시스템 (고객이 직접 운영하는 전용 시스템)
                        보조 스테이션 시스템
                        감금 경보
                        라인 감시 (침입자가 탐지당하지 않기 위한 행동을 탐지)
                        알람용 전원 (라인 감시를 위한 백업 전원을 별도로 확보)

▶ 컴퓨팅 자원 통제
- PC 통제
      - 케이블 잠금 장치 : 비닐로 덮인 강철 케이블로 책상에 연결
      - 포트 통제 : 외부 저장 매체 사용을 차단
      - 디스크 잠금 장치
      - PC, 주변기기용 잠금장치 : 스위치 통제, 키보드 통제, 커버 잠금 장치
      - 랩탑 통제 : 물리적 잠금장치, 각종 패스워드 보안과 기밀 데이터 암호화 및 백업

- 저장매체 통제
      - 사용 후 적절한 폐기 절차를 요구 함
      - 저장매체 폐기 및 데이터 삭제 시 절차를 마련하고 보안 허가(clearance)를 가진 직원에 의해 수행
      - 데이터 잔상(Remanence)를 남기지 않기 위해 오렌지북에서는 재사용 및 폐기 시 7번 이상 포맷 권장
      - 종이로 된 문서 폐기 시 파쇄기를 이용해 폐기, 소각
      - OS를 통해 삭제된 데이터는 복구가 가능, 자성제거나 7번 이상 포맷하여 데이터를 완전 삭제
      - 허가 및 검증 받은 전문 요원에 의해 데이터 삭제 과정을 진행

      - 데이터 삭제의 유형
          - Clearing : 일반 사용자가 복구할 수 없도록 데이터 저장 매체를 덮어 쓰는 것
          - Purging : 전문가에 의해 실험실에서도 복구할 수 없을 정도로 데이터 저장매체를 덮어쓰거나 자성 제거
          - Destruction : 물리적 파괴

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑨ 직무역량강화 > CISSP' 카테고리의 다른 글

[CISSP] Domain 10. 물리적 통제 (1)	2012/01/13
[CISSP] Domain 9. 법조사 윤리 (0)	2012/01/13
[CISSP] Domain 8. BCP DRP (0)	2012/01/12
[CISSP] Domain 7. 보안 아키텍처 모델 (0)	2012/01/12
[CISSP] Domain 6. 암호학 (III) (0)	2012/01/12
[CISSP] Domain 6. 암호학 (II) (0)	2012/01/11

[CISSP] Domain 9. 법조사 윤리

서풍의신 재령 — Fri, 13 Jan 2012 11:44:49 +0900

▶ 지적 재산권 법(Intellectual Property Law)
- 상표권 (Trademark)
      - 식별을 위해 만든 심볼

- 특허권 (Patent)
      - 지정된 기간동안 특허 권리 침해에 대해 법적으로 배타적 권리를 가짐
      - 발명특허 : 과학, 기술 공학을 이용한 고도의 창작물을 보호
                       Protects the Precess of How To Build the Product of the Idea
      - 실용신안특허
      - 혁신적이고, 산업상 유용하고, 누구나 알아낼 수 있는것이 아니어야 하며 가장 먼저 출원되어야 함

- 저작권 (Copyrignt)
      - 저자의 생각이 표현된 작품(Idea, 창작물)을 보호 (Protect How the Idea is Expressed)
      - 컴퓨터 프로그래밍과 관련된 저작권 보호 : OS, Source Code, DB, 프로그램 Structure 등
      - 메뉴 화면에 대해서는 저작권법의 보호를 받을 수 없음
      - 전자 정보는 접근 권한을 획득되는 순간 그 정보에 접근, 사용 한 것으로 간주함

- 기업기밀 (Trade Secret)
      - 소유자에게 유용하게 사용될 수 있도록 기밀이 보호되어야 할 독점기술, 사업정보
      - 기업기밀의 요건 : 소유자가 정보 개발을 위해 자원을 투자
                                 소유자 사업에 가치가 있어야 함
                                 경쟁사에도 가치가 있어야 함
                                 정보 보호를 위해 적합한 노력을 기울여야 함
      - 기업기밀을 보호하기 위한 방법 : 문서 복사본에 관리번호 부여
                                                     복사본 생성 제한
                                                     문서 관리 대장을 통해 문서 배포 통제
                                                     통제된 저장소에 보관
                                                     컴퓨터 파일과 단말기를 점검 (보안 SW 설치)

▶ 정보 사생활 보호법 (Information Privacy Law)
- 의도적, 의도되지 않은 노출이나 오용으로부터 개인의 사생활 관련 정보를 보호
- 전자 모니터링 (Electronic Monitoring)
      - 종류 : Keystroke, Email, 감시카메라, 마그네틱 엔트리 카드 모니터링 등
      - 적법한 방법으로 모니터링을 수행해야 함
      - 모니터링에 대해 직원이 동의하고 사용, 보안 정책 위반 시 처벌에 복종하도록 해야 함
      - 모든 직원에게 동일하게 적용됨을 알려야 함
      - 모니터링 대상이 얼마나 오래 백업되는지 설명해야 함
      - 개인 정보 수집 시 반드시 수집 목적을 밝혀야 하고 수집된 정보는 미리 고지된 목적 이 외 사용 불가

▶ 법적 책임
- 주의 의무 (Due Care)
      - 사회적으로 통용되는 자산에 대한 통상적 보호 노력
      - 공공부문은 관련 법령에 따라, 민간부문은 사업 영역에 따라 기준을 반영
      - 주의 의무 이행 시 조직의 보안에 문제가 생기더라도 전적으로 책임을 지지 않을 수 있음
      - 주의 의무 이행을 위한 보호방안을 수립

- 지속적 노력 의무 (Due Diligence)
      - 주의 의무에 대한 성실한 관리와 이행 (1회성이 아님)
      - 정보 보안이 지속적으로 적합하게 유지되고 있음을 보증하기 위한 지속적 노력

▶ 윤리강령
- 규정(Canon) : 강제적인 규정
      - 사회와 국가 기간 시설 보호
      - 정직, 공정, 책임감, 합법적 행동
      - 고객에게 근면하고 경쟁력있는 서비스 제공
      - 직업적 명성 보호 및 지속적인 전진

- 안내(Guidance) : 권고 사항

- OECD 개인정보보호 8대 원칙
      - 수집제한의 원칙
      - 정보 내용의 원칙
      - 목적 명확화의 원칙
      - 이용 제한의 원칙
      - 안전보호의 원칙
      - 공개의 원칙
      - 개인참가의 원칙
      - 책임의 원칙

▶ 사고조사 기법
- 단계 : 사전 준비 → 침해사고 식별 → 피해 억제 → 원인 근절(제거) → 원상회복

- 사전 준비

- 침해사고 식별
      - 조기에 침해사고를 발견 시 현장 보존 후 침해사고에 대한 공지와 경고
      - 현장 보존이 최우선 단계
      - 보고대상 : 조직관리자, 보안담당자, 침해사고 처리팀
      - 침해사고 보고 순서 : 관리자 → 내부신고 연락처 → 지역(국가단위) 침해사고 처리팀

- 피해 억제
      - 보고 받은 즉시 현장으로 처리팀을 파견하거나 보안 담당자에게 초기 조치 방안을 전달
      - 시스템을 네트워크에서 분리
      - 시스템을 백업(2개 이상 이미지 백업, 4개 권장)
      - 작은 증거라도 훼손되지 않도록 보존
      - 백업받은 시스템을 분석, 보고
      - 지속적인 위험 존재의 파악을 위해 주변 시스템들에 대한 로그 분석

- 원인 근절(제거)
      - 침해 사고의 원인과 징후를 분석
      - 보안대책 수립, 시행
      - 침해 사고의 원인을 제거

- 원상 회복
      - 운영 재개 후 시스템을 모니터링

▶ 증거
- 최상의 증거 : 신뢰성 있는 최우선 증거, 문서화 된 증거(계약서)

- 2차증거 : 최상의 증거에 못미치는 증거, 구두 증언이나 원본의 사본

- 직접증거 : 가정이나 추론의 필요 없이 그 자체로 사실을 증명하는 증거(목격자의 증언)

- 정황증거 : 직접 증거는 될 수 없으나 다른 사실의 존재를 추론, 가정, 증명할 때 이용되는 증거

- 결정적 증거 : 더 이상의 이견이 필요없는 한가지 결론을 도출하여 반박, 부인할 수 없는 증거

- 보강증거 : 어떤 생각이나 사건의 논리를 돕는 다른 성격의 추가적 증거

- 의견증거 : 사실에 대한 본인의 의견이 아닌 단지 보고 들은 사실에 대해서만 증언한 것
                    전문가의 증언인 경우 개인적 전문성과 사실에 따라 의견을 말할 수 있음

- 풍문증거, 간접증거 : 다른 원천으로부터 수집된 증거(단순 로그), 법정에서 받아들여지지 않음
                                 컴퓨터에 의해 생성된 정보는 정확성과 신뢰성을 입증할 수 없어 풍문증거의 범주에 속함

▶ 증거의 법칙
- 최상의 증거 원칙 : 법원에서 허용되는 증거는 원본이어야 함
                              증거의 변조를 방지하기 위한 원칙
                              천재지변, 정상적 업무절차에 따라 원본이 파괴된 경우 복사본 허용
                              법원의 소환에 따를 의무가 없는 제 3자가 원본을 소유한 경우 복사본 허용

- 증거 배제의 원칙 : 법으로 규정한 압수 및 수색 절차에 따라 획득 되어야 함, 그렇지 않을경우 법적 인정 불가
                              직원들에게 사전공지 없이 획득한 모니터링 자료는 증거 배제

- 풍문 증거의 원칙 : 풍문 증거는 법정에서 인정되지 않음
                              컴퓨터에서 생성된 대부분의 증거

- 풍문증거가 법원에서 인정받기 위한 조건
      - 일회성 데이터 수집이 아니라 정상적인 업무 도중에 수집된 증거
      - 정상적인 업무 절차에 따라 수집된 증거
      - 전문적 지식을 가진 직원에 의해 수집된 증거
      - 법률적 조건을 갖춘 관리자나 증인의 증언을 통해 입증된 증거

▶ 증거의 법정 허용
- 법원에서 인정받기 위한 증거의 요건
    - 논리적 연관성 : 논리적으로 실제 사실을 입증 가능해야 함
    - 신뢰성 : 증거에 대한 신뢰성
      - 충분성 : 다른 어느 누구도 반론할 수 없는 설득력이 있어야 함

- 증거 보관 절차 (Chain of Evidence)
      - 증거가 수집, 분석, 이동되고 법정에서 제시될 수 있도록 보존되는 것을 보여주는 기록
      - 법원에 증거 제출 시 원본과 똑같은 상태임을 보여주어야 함(무결성)
      - 증거에 대한 신뢰성을 입증

- 증거의 Life Cycle
      - 발견과 인지
      - 보호 : 증거가 훼손되지 않도록 보존
      - 기록 : 현장과 증거에 대해 기록, 사진이나 비디오 촬영
      - 수집 : 전원을 끄기 전에 HDD 이미지와 메모리 Dump
      - 식별 : 수집된 증거에 날짜, 시간, 수집자 이니셜, 사건번호 등을 마킹
                 펠트펜을 제외하고 표면에 아무것도 마킹하지 않음
                 릴투릴 마그네틱 테이프는 앞부분 10~15피트 이내의 윤이나지 않는 부분에 마킹 가능
                 출력물의 경우 적절한 컨테이너에 담아 밀봉 후 마킹
      - 보존
      - 전송
      - 법정에 제시
      - 소유자에 반환

▶ 컴퓨터 범죄 수사 기법
- 법원이 인정할만한 컴퓨터 관련 증거를 수집, 보존, 분석하여 법원에 제출, 결정적 근거로 활용하는 기술

- 기본 기술
      - 원본 데이터를 변형 없이 증거로 수집
      - 보관한 증거가 원본 데이터와 다르지 않음을 입증
      - 데이터 분석 시 변조됨 없이 분석

- 작업 절차
      1. 디스크 이미지 백업 : 메모리 덤프 후 원본 컴퓨터에서 HDD를 분리
                                     원본 HDD를 이미지 백업시 최소 2 Copy, 권장 4 Copy 를 받음
      2. 검사 컴퓨터에서 데이터 분석 : 숨겨지거나 삭제, 암호화 된 파일, 디렉토리를 분석
      3. 원본 컴퓨터를 복제 HDD로 다시 조립해 부팅하며 분석
      4. 각종 저장매체에 있는 데이터를 복제, 분석
      5. 분석 결과를 정리

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑨ 직무역량강화 > CISSP' 카테고리의 다른 글

[CISSP] Domain 10. 물리적 통제 (1)	2012/01/13
[CISSP] Domain 9. 법조사 윤리 (0)	2012/01/13
[CISSP] Domain 8. BCP DRP (0)	2012/01/12
[CISSP] Domain 7. 보안 아키텍처 모델 (0)	2012/01/12
[CISSP] Domain 6. 암호학 (III) (0)	2012/01/12
[CISSP] Domain 6. 암호학 (II) (0)	2012/01/11

[CISSP] Domain 8. BCP DRP

서풍의신 재령 — Thu, 12 Jan 2012 17:20:33 +0900

▶ 용어 정의
- BCP : Business Continuity Plan (사업 지속 계획)
- DRP : Disaster Recovery Plan (재난 복구 계획)
- BIA : Business Impact Analysis (업무 영향 평가 분석)

▶ 비상 계획 개요
- 필요성 : 위험요소 (일반재해, 시스템 장애, 사고/과실)
                손실 (직접적손실 - 인적자원이 가장 중요, 간접적 손실 - Business, 잠재적 손실)

- 재해의 정의
      - 장애(Non-Disaster) : Down-Time(업무 지장시간)이 짧은 경우
      - 재해(Disasters) : 하루 이상의 중단이 있는 경우

- 위험관리
      - 위험 요인의 영향을 감소시키는 것이 목적
      - 정보 자원에 대한 위협 요인의 분석을 실시, 통제

- 비상 계획
      - 잠재 위협에 대한 복구 방안의 수립이 목적
      - 경영진에게 책임이 있음
      - BCP / DRP 로 나뉨 (BCP가 더 큰 개념, 하나의 BCP에 달린 여러개의 DRP가 존재)

      - BCP : 기업 전체 business 운영에 대한 비상 계획
      - DRP : 기업의 각각의 세부 시스템 별 복구 계획

- BCP : 심각한 파괴로부터 복구를 시행하는 동안 핵심 업무의 운영을 유지하기 위한 절차 제공
             모든 시스템의 복구가 목적이 아님
             모든 비상 계획을 포함하는 포괄적 표현

- BRP : 사업 복구 계획
             재해에 따른 Business 운영을 재개하기 위한 절차
             기술(IT) 관점이 아닌 관리적/절차적 부분에서 재난 발생 이후 즉각적인 복구방안에 중점

- COOP : 운영 지속 계획
                조직의 핵심 기능을 대체 사이트에서 최대 30일까지 운영하는 절차, 기능 제공
                본사 관점의 핵심 기능에 대해서 논의 (비 IT 관점)

- CSP / ICP : 지원 지속 계획
                      일반 지원 시스템 및 주요 응용 프로그램의 복구 절차
                      IT 비상 계획. (IT 관점)
                      Business 절차는 논의하지 않음

- CCP : 위기 통지 계획
             일반 및 대중에게 상황을 통지하는 절차
             내외부 보고절차 및 언론 보도와 관련
             경영진의 승인과 주도하에 시행 (비 IT 관점)

- CIRP : 침입 대응 계획
              악성 사이버 공격의 영향을 최소화 하기 위해 이를 감지, 대응하는 절차
              CIRT / CERT 조직 구성

  - DRP : 재난 복구 계획
             장기간의 장애 복구로 국한 (단시간 장애의 경우가 아님)
             대체 사이트 운영방안 정의 (IT 관점)

- OEP : 인명 비상 계획
             IT 관련 인명과 특정 설비를 대상으로 위협에서 자산 보호

▶ 비상 계획 수립
- 비상계획 수립 절차
      1. 비상계획 정책 수립 - 비상계획 정책의 범위와 계획을 정의, 경영진 승인
      2. BIA 산정 - 복구 대상 절차, 자원 및 MTD, 우선순위 분석
      3. 예방활동 정의 - 재해 발생 예방 활동
      4. 복구 전략 수립 - 재해 발생 시 복구를 위한 방법 산정
      5. 복구 계획 수립 - 재해복구 전략의 구체(문서)화, 기술적인 내용
      6. 훈련, 테스트 실행 - 훈련 후 테스트 실시
      7. 계획 유지 보수 - 주기적인 검토, 수정

- 업무 영향 분석 (BIA)
      - 재해 발생 시 각 업무에 미치는 영향 및 피해액 산정
      - 업무별 중요도(유무형의 피해액이 클 수록 더 중요)에 따라 복구 우선 순위 결정
      - 재해 복구 시스템의 용량 산정 및 복구절차 수립의 기초 자료(MTD, MTTR) 제공
      - 정성/정량적 요인을 모두 반영하여 산정

      - BIA 산정 시 도출요소
            - 핵심 사업 절차 및 IT 시스템 파악
            - MTD(Maximum Tolerable Down-time) 산정 : 사업 유지를 위한 최대 허용 장애 시간
            - MTTR : 평균 장애복구 수리 시간으로 짧을 수록 좋음
            - MTTF : 평균 장애 시간으로 길 수록 좋음
            - 시스템 복구 우선 순위

      - 업무 중요도에 따른 시스템 분류
            - 핵심(Critical) : MTD가 제일 짧음, 동일 수준의 장비로 즉시 대체하지 않으면 수행 불가
                                   일반적으로 시스템을 2중화
            - 중요(Vital) : MTD가 대체로 짧음, 짧은 시간동안 수작업 대체 가능
            - 민감(Sensitive) : MTD가 다소 긴 경우
            - 비핵심(Non-critical) : MTD가 긴 경우에도 Business에 영향이 적을경우

- 복구 전략 수립
      - 백업 정책
           - 지역 : 너무 가까운 지역에 백업 사이트를 두지 말 것 (100km 이상 떨어진 곳을 권장)
           - 접근성 : 교통 편리
           - 보안성 : 자료의 중요도에 따라 보관 장소의 노출을 피할 것
           - 환경 : 시설에 영향을 줄 수 있는 환경을 피할 것
           - 비용 : 복구 비용이 과다하게 소모하여서는 안 됨

      - 장비 확보 방안
           - 유사 장비 사용
           - 장비 제조 업체와의 특별 협약

      - 대체 사이트
           - 독자 구축형 : 이중화 된 설비
           - 상호 이용형 : 상호 협약
           - 공동 이용형
           - 외부 위탁형
                 - Mirror Site : 주 센터와 복구 센터간 데이터 이중화, 재해 직전 데이터로 2시간 이내 복구
                                    내부 소유 복구센터
                 - Hot Site : 복구 센터에 데이터 변경 LOG를 전송, 재해 직전 데이터로 24시간 이내 복구
                                 외부 소유 복구센터
                 - Warm Site : 복구 센터에 일일 백업 테이프를 원거리 지역의 백업 사이트로 이동
                                    최종 백업 시점(전일자) 원장으로 1일 ~ 수주에 걸쳐 복구
                 - Cold Site : 복구 센터에 일일 백업 테이프를 원거리 지역의 백업 사이트로 이동
                                   구축된 H/W 장비나 네트워크가 없음, 재해 시 시스템 및 네트워크 구축 필요
                                   최종 백업 시점의 데이터로 1개월여에 걸쳐 복구
                 - Mobile Site : 대형 트레일러에 전산 장비를 구비하고 재난 발생시 원하는 위치에서 복구
                                      군사, 제조업 조직에서 사용

      - 조직원의 책임과 역할 : 실행조직 구성/훈련
                                        비상 조치팀이 초기 대응팀으로 가장 빨리 대응 함 (인명 보호)
      - 복구 비용 : 예산 확보 및 비용 반영

- 복구 계획 수립
      - 통보 및 활동 단계 : 장애나 재난 발생 시 수행 되어야 하는 통보, 피해조사, 계획 시행의 초기 대응
      - 복구 시행 단계 : 임시적으로라도 IT자원 가동에 집중, 비상 계획에 정의된 수준으로 복구
      - 재복원 시행 단계 : 복구 행위 종료 후 원상 복구 절차, On Site 복귀 후 재난 복구 종료 선언

- 비상 계획 테스트 및 훈련
      - 체크리스트 : 문서 테스트, 관련 부서에 비상계획 전달 후 검토
      - 구조적 점검 테스트 : Structured Walk-Through Test
                                     문서 테스트, 담당자 모임에서 활동에 대한 논의
      - 전 시스템 중단 테스트 : Full Interruption Test
                                         실행 테스트, 원래 사이트 중단 후 대체 사이트 운영
                                         경영진의 승인을 득한 후 시행, 가장 효과적인 테스트

- 비상 계획 유지 보수 : 적어도 연 1회 테스트에 참가 한 후 경영진에 30일 내에 결과를 보고

- 사업 지속 계획에 영향을 주는 요구 사항 : 조직 변경, 신규 SW 도입, 사업 전략 변경, SW/HW 환경 변경

▶ 비상계획 관련 IT 기술
- 백업
      - Full Backup (전체 백업)
      - Incremental Backup (증분 백업) - 매 번 증가분을 고려하지 않은 백업
      - Differential Backup (차등 백업) - 매 번 증가분을 고려하는 백업, 전체 백업 + 최종 백업본을 복구에 사용
      - Archiving Backup (소산 백업)

      - Network 기반 Topology를 이용해 백업 (DAS, NAS, SAN)

- RAID (RAID0, RAID1, RAID0+1, RAID5, RAID6)

raid_종류.pdf

      - Redundant Array of Inexpensive Disks

      - RAID0 : Disk striping without parity(= fault tolerance)
                   디스크를 분산해 차곡차곡 쌓아둠
                   복구 기능이 없음

      - RAID1 : Disk 2개를 나란히 놓고 동기화
                    Disk mirroring

      - RAID0+1 : RAID0 을 RAID1 처럼 두고 동기화

      - RAID5 : Disk striping with parity
                   parity를 분산 저장
                   Disk 가 동시에 2개 이상 깨져 나가면 복구가 불가

      - RAID6 : parity 를 2곳에 분산 저장
                   Disk 가 동시에 2개가 깨져 나가도 복구 가능

- 시스템 이중화
      - Active - Standby
      - Active - Active (Mutual Active) : Lock Disk 가 필요

- Load Balancing : L4 Switch / NLB (Networl Load Balancing)
                             장애 극복, 부하 분산

- 전자 금고 : Electronic Vaulting
                    Data를 저장하는 원격지 저장소
                    Batch 작업을 통해 대량의 데이터를 전달
                    전송 주기가 배치성 (원격 저널링과 구분)

- 원격 저널링 : Remote Journaling
                       DBMS의 로그를 실시간으로 원격지의 백업 센터로 전송하는 기술
                       최소한 Warm Site로 구성되어야 함

- 원격지 디스크 미러링

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'⑨ 직무역량강화 > CISSP' 카테고리의 다른 글

[CISSP] Domain 10. 물리적 통제 (1)	2012/01/13
[CISSP] Domain 9. 법조사 윤리 (0)	2012/01/13
[CISSP] Domain 8. BCP DRP (0)	2012/01/12
[CISSP] Domain 7. 보안 아키텍처 모델 (0)	2012/01/12
[CISSP] Domain 6. 암호학 (III) (0)	2012/01/12
[CISSP] Domain 6. 암호학 (II) (0)	2012/01/11