728x90
1. 화면설계

보통 화면설계는 스토리보드와 동일 시 하는 경향이 있다.

그러나 그 기능은 분명히 다르다.

화면설계는, 화면을 설계 하는 사람(기획자건 프로그래머건 디자이너건)이 해당 사이트의 분석 결과를 화면으로 옮기는 결과물이다.

예를 들어보자.

가령 쇼핑몰일 경우

이벤트를 띄우는 경우, 특정상품군을 띄우는 경우 또는 여러 상품을 띄우는 경우와 같이 end user에게 가장 잘 어필해야 하는 컨텐츠군을 뽑아내어 정의 한다.

이 경우, 화면설계자는 쇼핑몰이 가지고 있는 컨텐츠(또는 DB)를 분석해야 한다.

더불어 어떠한 서비스를 할지 결정을 내려야 한다.

가장 많이 찾는 상품군은 어떠한 것이며, 회사차원에서 프로모션할 상품군은 무엇인지를 찾아내어 노출해야 한다.

때로는 회사가 가지고 있는 컨텐츠(또는 DB)중 사이트에는 노출되지 않고 있는 컨텐츠를 찾아내서 상품의 가치가 있는지 아니면, 사장시켜버려야 하는지를 판단해야 할 때도 있다.

ISP사업에서 특히나 이런 경우들이 많이 발생한다.

복잡다양한 카테고리를 구성하고, 그 안에 수많은 자료를 가지고 있다보면 정작 end user가 원하는 자료는 찾아보기 힘들거나 아예 노출이 안되는 경우도 발생한다.

따라서, end user에게 정확한 정보 전달의 실패가 일어나지 않도록 설계자는 분석에 의한 판단이 절실히 필요하다.

2. 스토리보드(Storyboard)

흔히 스토리보드는 화면에서 보여지는 그대로 그려진다고 생각을 한다.

50%짜리 정답이라고 생각한다.

스토리보드를 그리기 전에 설계자는 요건정의서, 기능정의서, 화면설계서 그리고 뒤에 얘기할 UI설계서를 파악해야 한다.

어느 화면에 어떠한 컨텐츠와 어떤 기능이 담겨야 하는지를 알고 있어야 한다.

하다못해, '글쓰기 버튼'이 늘상 리스트 하단에만 박혀 있어야 할 필요는 없다.

때로는 sorting기준에 따라 50줄이나 100줄이 나올수도있는 리스트 화면도 존재할 수 있다.

이럴 때는 스크롤 바가 이미 한 없이 내려가 있을 수도 있다.

만약, end user가 상단 1,2줄의 리스트만 확인하고 글쓰기를 원하다면 한없이 하단으로 스크롤바를 내려야만 할까?

리스트가 20줄, 30줄 이상일 때는 상단에도 '글쓰기 버튼'이 존재한다면 end user로써는 스크롤바를 열심히 내려야 하는 불편함이 사라지기에 감사함을 느낄 수도 있다.

바로 이와 같은 고민이 병행되어야 할 문서가 스토리보드라 생각된다.

그러나 많은 설계자들이 너무 쉽게 스토리보드를 그려내고 있다. copy & paste...

3. UI기획(설계)

자아, 이 부분이 참으로 애매하다.

UI는 User Interface라는 걸 누구나 다 안다.

결국 같은거 아닌가??? 맞다. 의미상 분명히 같다.

그러나 UI설계는 화면설계를 기초하여 설계되어져야 한다.

예를 들어보자. 위에서 쇼핑몰을 예로 들었으니 이어서...

화면설계에서 이벤트, 특정상품군, 여러상품 또는 프로모션 상품을 메인에서 노출시켜야 한다고 정의를 내렸다고 치자.

센터 상단에 대한 UI설계를 할 경우, 이벤트가 들어가는 웹사이트와 특정상품군을 띄우는 경우 또는 여러 상품을 띄우는 경우와 같이 end user에게 가장 잘 어필해야 하는 컨텐츠군을 배치한다.

컨텐츠의 배치 결정을 내려야 하는 것이 UI설계단에서 이뤄져야 하는 가장 중요한 부분이다.

센터는 몇 단으로 쪼갤 것인가...

어필하고자 하는 상품은 센터의 상, 중, 하단 어느 곳에 배치할 것인가...


마지막으로 GUI

원래 GUI는 텍스트위주의 DOS체제 화면을 그래픽으로 전환하면서 나타났다.

이후, 서비스의 다양성으로 웹사이트 서비스에서의 GUI로 확대되기 시작했다.

결국 용어에서도 말했듯이 그래픽을 통한 end user의 시선과 마우스 움직임을 사로 잡을 수 있도록 하는 것이다.

가령 상품 A와 B를 센터 상, 하단에 배치 하였다고 치자.

실제 중요도는 A상품인데 B상품의 그래픽이 더 화려하게 시선을 잡아 끈다면

A상품의 노출 전략은 실패한 것이 되어 버린다.

따라서, GUI는 컨텐츠의 중요도를 파악하여 어떠한 그래픽 요소(색상, 이미지, 아이콘 때로는 소리, 영상 등)를 통해 노출을 할 것인가를 결정 지어야 한다.

출처 : http://www.nterplan.com/36

'참고자료 > 소프트웨어공학' 카테고리의 다른 글

DA# Planner 1  (0) 2009.07.17
개괄적 데이터 모델링  (0) 2009.07.17
데이터 아키텍처(Data Architecture)의 계층구성  (0) 2009.07.17
Data Architecture 개요  (0) 2009.07.17
프로젝트 산출물 정의  (0) 2009.04.06
728x90

1. 분석
   1.1. 현업요구사항정의서
        : 해당 프로젝트를 수행하는 가장 기본이 되며 고객의 needs을 담고 있는 문서입니다.

          이를 통해 다양한 스펙산정이 가능합니다. 이부분에서 요구ID를 도출합니다.
   1.2. 기능챠트
        : 현업요구사항을 근간으로 큰 카테고리를 만들어 한눈에 해당 프로젝트가 무슨 일을 하는

          것인지 보여줄 있습니다.
          * 이부분은 개발방법론에 따라 유스케이스다이어그램으로 대치할 수도 있을 것으로

            판단되어지고, 기능챠트와 같이 가도 무관하다는 판단입니다.
   1.3. 프로세스 정의서
        : 기능챠트를 기준으로 각각의 프로세스를 보여줍니다. 때에 따라 확대된 프로세스의

         표현도 가능합니다.
         * 개발방법론에 따라 시퀀스다이어그램을 넣어도 무방하다는 판단입니다.
   1.4. 인터페이스정의서
        : 상기 현업요구사항정의서,기능챠트,프로세스정의서를 근간으로하여 레가시 및 대외계

          시스템, 웹서비스 등 어떤식으로 인터페이스를 해야 한다는 정의를 담고 있습니다.
   1.5. 기타


2. 설계
   2.1. UI(화면)설계서
        : 웹App 혹은 CS App 든 간에 고객이 사용하고자 하는 화면단을 보여주는 문서입니다.
   2.2. ERD
        : 해당 업무의 DB를 생성하고 테이블관의 상관 관계를 표현하는 문서로 더이상 설명이

          필요없으리라 믿습니다.
   2.3. 테이블목록
        : 테이블정의서도 있지만, 테이블목록은 관리자가 한눈에 시스템을 구성하고 있는 DB

          테이블을 보여준다는 측면에서 필수라는 판단입니다.
   2.4. 테이블정의서
        : 테이블필드 value와 설명, 바이트수 등을 표기합니다.

   2.5. 프로그램 목록
        : 실직적으로 설계단계에 프로그램목록이 나오지 않지만 일단 설계 단계에 넣는 것이

          타당한 것 같습니다.
          * 개발방법론에 따라 클래스다이어그램, 컨포넌트명세서, 클래스정의서 등도 포함 될 수

            있을 것 같습니다.
   2.6. 개발표준 정의서
        : 변수명, brace, 클래스네임,파일명,규칙등 코딩관련 규칙을 정의함으로써 일선 담당자가

          소스코드를 확인해도 눈에 익숙할 수 있게 하기위한 문서입니다.
   2.7. 단위테스트 시나리오
        : 분석,설계의 기본적인 요건이 충적되면 이쯤하여 단위테스트시나리오가 나와야 할 것

          같습니다. 아마도 고객의 싸인이 필요한 부분일 것입니다.
   2.8. 통합테스트 시나리오
        : 설계단에서 하기는 많은 어려움이 있지만, 단위테스트를 근간으로 고객의 요청을 좀더

          보완하여 통합테스트시나리오를 작성합니다. 고객의 싸인은 필수입니다.
   2.9. 기타
 
3. 개발
   3.1. 소스코드(개발원시코드)
        : 말그대로 오류수정까지 끝난 원시코드 자체를 말합니다.
   3.2. 단위테스트 결과서
        : 단위테스트시나리오를 기준으로 테스트한 결과를 보여줍니다. 아마도 많은 문제점을

          안고 있고, 이 과정을 통해 고객의 요구사항도 많은 변동이 있는 시점입니다.
          * 변경요청서도 필요할 시점입니다.
   3.3. 결함/오류보고서
        : 단위테스트를 통해 알게된 에러의 원인과 수정에 대한 내용을 나타냅니다.

          이를 통해 오류코드정의서를 뽑아내고 보완합니다.
   3.4. 오류코드 정의서
        : 해당시스템에서 발생할 수 있는 오류들을 코드화하여 보여줍니다.
   3.5. 통합테스트 결과서
        : 단위테스트를 통해 보완된 내용들을 포함하고, 통합테스트시나리오의 보완을 통해

          실시된 통합테스트 결과를 보여줍니다. 개발을 완료했냐 안했냐의 잣대가 되는 문서로서

          고객의 싸인이 가장 필요한 부분입니다. 이부분에서 반려가 일어나면 위의과정을 반복해야

          합니다.
   3.6. 시스템 이행계획서
        : 통합테스트가 끝나면 Standby하고 있는 시스템에 소프트웨어,하드웨어 기타 등을 몇월,

          며칠, 몇시에 누구누구가 무엇을 가지고 옵져버는 누구이며 어떻게 이행을 할 것인지

          등을 표현합니다.
   3.7. 기타
 
4. 구현
   4.1. 시스템 이행결과서
        : 시스템 이행계획서를 통해 이행된 결과를 확인받는 문서입니다.
   4.2. 사용자매뉴얼
        : 사용자화면이 있을 경우 나오는 매뉴얼입니다.일반적인 조작법을 기록하며, 화면 등을

          예시합니다.
   4.3. 운영자매뉴얼
        : 시스템전반에 관한 모든 내용을 담고 있습니다. 분석,설계,개발 절차에서 나오는 문서를

          담고 있습니다.
   4.4. 교육(인수)명세서
        : 사용자매뉴얼 및 운영자매뉴얼을 중심으로 해당 담당자 및 사용자에게 시스템전반 및

          세부사항을 교육/인수한후 싸인받는 문서입니다.
   4.5. 개발산출물별 검사리스트
        : 예시된 산출물들이 이상없이 인수되었는지를 개별로 체크한후 고객의 싸인을 받는

          문서입니다.
   4.6. 프로젝트 완료보고서
        : 최종적으로 개발한 내용, 인도물, 하드웨어, 고객대표, 개발자대표싸인을 받음으로써

          명실상부한 프로젝트 완료보고서입니다.
   4.7. 기타


출처 : http://blog.naver.com/ywjmkim/60022461415

'참고자료 > 소프트웨어공학' 카테고리의 다른 글

DA# Planner 1  (0) 2009.07.17
개괄적 데이터 모델링  (0) 2009.07.17
데이터 아키텍처(Data Architecture)의 계층구성  (0) 2009.07.17
Data Architecture 개요  (0) 2009.07.17
화면설계,스토리보드,UI설계  (0) 2009.04.06
728x90

일종의 체크리스트입니다.

1. 통신망

  • 웹서버는 올바른 DMZ 구성이 되어 있는가?
  • DMZ 방화벽에는 웹서비스 포트外 다른 포트가 Open되어 있는가?
    - 웹서비스포트外 다른 서비스가 Open될 경우, 사용서비스 포트와 접속IP 주소를 고정하여 사용하는지 확인(SMTP,DNS사용의 경우 별도 예외)
    - 내부에서 외부로 나가는 Outbound 포트도 필요한 포트外 차단하였는지 확인
  • 방화벽 접속로깅을 하고 있으며 보관기간은 충분한가?
    - 방화벽 접속로깅은 6개월 이상 보관 권고
  • 침입탐지시스템(IDS) 또는 침입방지시스템(IPS)이 가동 중인가?
    - 근래는 외부 트랙픽 보다 외부 트래픽에 의한 문제가 더 많은 만큼 내부 트래픽에 대한 검출이 중요
  • 침입탐지시스템(IDS) 또는 침입방지시스템(IPS)의 로그 파일 중 비정상적인 로그가 방치되고 있는가?
    - 이상 로그 발생에 대한 SMS 연동 등 관리체계 수립 및 다양한 패턴D/B의 유지보수가 필요

2. 서버

  • 서버에 해킹취약서비스가 제거 되었는가?
    - ttdb, cmsd, sadmind, snmpXdmid, ypbind, xntpx 등의 제거
  • 서버에 불필요서비스가 존재하는가?
    - RPC 서비스 : rusers, rexd, statd, rquotad, walld, snmp(100122), snmpv2(100138), kcms_server, metad, metamhd
      - finger, systat, netstat, tftp, comsat, talk, uucp, auth, printer, echo, discard, time, daytime, chargen, dtspcd, snmpd, snmptrapd, pdnsd, cachefsd
  • 서버에 최신 패치 또는 대체 방안을 적용했는가?
    - 각 서버 밴더에서 제공하는 공식 보안 패치를 주기적으로 검토하여 적용
  • 서버 내 설치되는 별도 프로그램 또는 패키지의 샘플 및 테스트용 파일, 디렉토리들을 제거 했는가?
    - 아래에 나열된 샘플 디렉토리 이외에도 디폴트로 설치되거나 테스트 목적으로 설치되는 모든 샘플 파일들은 모두 제거되어야 함
          예) \Inetpub\iissamples 제거
               \Inetpub\iissamples\sdk 제거
               \Inetpub\AdminScripts 제거
               \Inetpub\Scripts\Samples 제거
               \Program Files\Common Files\System\msadc\Samples 제거
               \Winnt\System32\Inetsrv\Iisadmpwd
  • 리눅스 O/S사용시 Secure O/S를 설치했는가?
    - 핵심 정보자산을 운영하는 시스템은 리눅스 사용을 권고하지 않음
  • 웹서버의 관리자 디폴트 패스워드를 변경 하였는가?
    예) iPlanet(Netscape):  admin/admin
         Weblogic: system/weblogic
  • 웹서버의 디렉토리 리스팅 금지 기능이 적용되어 있는가?
  • 웹서버에 취약한 옵션이 제거 되었는가?
    - PUT, DELETE, MKDIR, RMDIR 등

3. 프로그램

  • 웹서버 사용시 취약한 버전은 패치되었는가?
    - 웹서버 밴더에서 제공하는 공식 패치를 주기적으로 최신 패치 수행 권고
  • 중간 페이지 접속 취약점이 존재하여 권한 없는 페이지에 접속이 가능한가?
    - browser-보기-탐색 창-열어 본 페이지 접속후 확인
    - URL, 변수값 조작으로 권한이 없는 페이지 접속 및 실행가능 여부 확인
         ex) http://localhost/view.asp?id=1http://localhost/edit.asp?id=1
  • 인증 프로그램 구현시 스크립트를 우회 할수 있는가?
    - 브라우저에서 스크립트 비활성화를 이용한 인증우회 가능여부 체크
  • CGI 프로그램 작성시 meta character를 체크하지 않아 시스템 명령어를 수행 혹은
    시스템 정보가 노출되지 않는가?
  • 파일 접근시 경로를 조작하여 시스템 파일에 접근 불가능 한가?
      ex) http://localhost/download.jsp?file=../. ··· 2Fpasswd
           http://localhost/download.jsp?file=../. ··· load.jsp
  • 중요 정보가 쿠키, 프로그램 소스, URL에서 표시된 Key 값을 변조가능한지 확인
    - 해당 key값을 변조하여 타인,타 부서의 정보를 조회할 수 없는지 테스트
       ※ Key값: ID, 주민번호, 사업자번호, 계약번호, 증권번호, 부서코드, Primary key 등
  • 중요 정보가 쿠키, 프로그램 소스, URL에서 평문형태로 조회되는지 확인
     - 쿠키: javascript:(document.cookie);
     - 소스: HTML 소스보기로 중요정보 노출확인 (hidden정보 등)
  • 응용프로그램에서 사용하는 DB계정은 DBA권한이 아닌 일반권한을 사용하고 있는가?
    - MS-SQL의 경우 sa 계정 사용 금지
  • php,jsp,asp등의 소스의 백업(zip, bak, tar, bk 등)은 웹 디렉토리가 아닌 별도의 디렉토리에 보관되어 URL로 접근이 불가한가?
  • 게시판 등 사용자 입력 부분에 관리자가 아닌 사용자로부터 html tag입력이 불가능 하도록 설정되어 있는가?
    - 사용을 허용할 html tag를 정리하여 제한적으로 제공할 것으로 권고
  • 사용자 인증, 검색, 게시판 보기화면 등 DB연결시 SQL조건문 조작을 통한 해킹이 불가능한가?
    - 가능한 다양한 SQL Injection 코드로 점검을 요함
  • 원격에서 명령어 실행이 가능한 악의의 소스를 업로드하여 명령어 실행이 불가하도록 차단 되어 있는가?
    - 업로드 파일의 확장자 체크는 무의미하며 php, jsp, asp, bak, inc 등의 실행불가 여부확인
  • 중요문서(대외비 이상 또는개인정보가 포함된 문서)는 웹경로상에서 직접 접근이 불가능 한가?
    - 웹서버 등의 .doc, .pdf, .xls 등 문서 파일을 검색하여 불필요한 파일은 삭제
    - Google 등의 검색엔진을 통해 중요 문서가 검색되는지 여부 확인
  • 게시판 구현시 공개된 프로그램을 사용하지 않는가?
    - 테크노트, Crazy보드, Zero보드, 그누보드 등 공개 프로그램 사용금지
  • php 사용시 세션정보를 안전하게 저장하고 있는가?
    - php.ini 중 세션 설정 디렉토리(session.save_path=/tmp 가 디폴트)를 따로 만들고(session.save_path=/tmp/session) user와 group값을 nobody로 설정하고 퍼미션을 750으로 조정했는지 확인
  • Php.ini 환경파일을 안전하게 운영하고 있는가?
    - allow_url_fopen  : off (디폴트 on)
    - register_globals  : off (디폴트 on)
    - magic_quotes_gpc : on
    - display_errors = off
  • 웹 서버 설치시 최소한의 권한으로 설치 되었는가?
    - root 권한으로 설치금지
  • 중요정보를 입력 Form의 자동완성 기능을 Off 했는가?
    예) <form name="input" method="post" action="input.php" autocomplete=off>
  • 중요정보가 있는 페이지의 경우는 CACHE가 불가능하도록 response의 header에 no-cache로 설정하여 로그아웃 이후에 뒤로가기로 정보 조회가 불가능 한가?
  • 클라이언트측 소스에 불필요한 주석(Comment)를 사용하여 시스템 정보를 노출하고 있지 않은가?
    - HTML 소스 보기를 통해 테스트 계정,패스워드, 테스트 서버IP, 개발자명 等와 같은 불필요 정보 존재하는지 확인
  • 예외 처리시 에러페이지를 지정하지 않아 웹서버의 시스템 정보가 노출되지 않는가?
    - SQL문, SQL 에러, Web서버 절대경로 노출 금지
    - 웹서버에서 404 Error 등의 표시를 기본 설정으로 하지 않고 별도 페이지로 연결 설정
  • 자바 클래스를 안전하게 운영하는가?
    - 자바 애플릿의 디컴파일러를 이용하여 소스를 원복하여 관리 권한과 같은 중요로직이 노출되거나 조작이 가능한지 확인
    - 자바를 이용하여 웹서버를 구성한 경우 웹브라우저를 이용하여 서버에서 실행되는  class위치에 접근, 다운가능한지 확인
      (확인방법)
      . http://대상URL/WEB-INF/classes/해당디렉토리/클래스명을  입력하여 서버측 클래스가 다운로드 가능한지 확인
  • 로그인 패스워드 정책 및 암호화 전송 기준이 있는가?
    - 회원가입, 사용자 정보 변경 시 단순 패스워드를 사용하지 못하도록 하는 검증 프로그램을 운영
    - 중요정보의 전송 시 128bit 이상의 SSL 적용
    - 개인 정보(ID/Password)분실 시 복구절차가 자동화되어 내부 사용자의 접근이 불가능하도록 설정
  • CMS 등 웹사이트 관리자화면은 안전하게 관리되는가?
    - 관리자화면 접근 IP를 제한하거나 내부망에서만 접근가능하도록 조치
4. 접근 및 관리 통제
  • 서버에 접근 가능한 IP 주소를 통제하는가?
    - O/S에서 제공하는 Trust Mode 설정화면에서 통제 관리
    - 보안 툴이 설치된 경우 관리자 화면에서 통제 관리
  • 서버 접속시 패스워드 정책을 관리하고 준수하는가?
    - 패스워드 설정규칙(6자 이상 사용,영숫자 혼용,연속문자열 4자 이상 사용금지 권고) 적용
    - 주기적(분기 1회 권고)패스워드 변경실시
  • root의 FTP을 사용 금지 옵션을 적용 했는가?
    - /etc/ftpusers 파일 내 root가 있는지 확인
  • 일반 사용자가 root권한을 갖는가?
    - /etc/passwd 파일 내 root외 UID=0 사용자 존재 확인
  • 서버 및 웹서버의 접속 로깅을 실시하는가?
    - 웹서버 로그, last 로그(wtmp), messages 파일, syslog 파일, 사용자 history 파일 별도보관 확인
       (단, /dev/null로 링크한 경우도 인정함)
    - 주기적인 모니터링 및 6개월 이상 별도 보관 권고
  • 웹서비스를 위한 서버의 설치 장소가 통제구역으로 관리되고, 출입 제한절차가 있는지 확인한다.
    - 물리적 출입 보안 체계 수립 및 유지
    - 출입 시 출입 대장관리
5. 데이터베이스
  • 데이타베이스 접속 ID/패스워드가 관리되고 있는가?
    -  사용자 ID별 사용자를 지정
    - 디폴트 ID/Password 사용금지
    예) 오라클 Default Password :
         scott/tiger,system/manager,dbsnmp/dbsnmp,sys/change_on_install,
         tracesvr/trace,demo/demo,ctxsys/ctxsys,mdsys/mdsys,
         ctxdemo/ctxdemo,apps/apps,applsys/fnd,po8/po8,names/names,
         sysadm/sysadm, ordplugins/ordplugins,outln/outln,adams/wood,
         blake/paper, jones/steel, clark/cloth,aurora$orb$unauthenticated/invalid
         (oracle 9i 추가) wksys/wksys, olapsys/manager, olapdba/olapdba,
         LBACSYS/LBACSYS, olapsvr/instance
         MS SQL Default Password : sa/null,probe/null
    - 패스워드 설정규칙 적용
      ( 6자 이상 사용, 영숫자 혼용, 연속문자열 4자 이상, ID가 포함된 패스워드 사용 금지 )
    - 주기적(분기 1회)패스워드 변경실시
  • 중요 정보(개인정보,거래정보)에 대한 사용권한이 지정되어 있는가?
    - ID별 사용권한(읽기,쓰기) 및 범위를 지정
    - ID는 운영에 필요한 최소한의 사용자에게만 부여
  • 데이타베이스 관련 파일에 대해서 접근권한이 통제되는가?
    - UNIX인 경우 : DBA에게만 파일 모드 644 허용
    - NT인 경우    : DBA에게만 읽기,쓰기 허용
  • DB취급자를 최소한으로 하고 허용 대상자를 통제, 관리하고 있는가?
    - 접속 가능한 IP 주소 및 Port를 제한하였는지 확인
  • 중요정보(개인정보,거래정보)의 조회,삭제,수정 등 이력을 기록하는가?
    - 접속 ID, 접속 프로그램, 접속일시, 명령어 수정내역 등의 이력을 기록
  • 데이타베이스가 존재하고 있는 서버의 접속 이력을 기록하는가?
    - 서버 로그 및 DB 리스너 로그 포함
    - 로그인 ID, 접속일시, 접속IP 등의 이력 관리
  • 고객/거래정보 데이터베이스는 통신망 내부망에 위치하여 외부에서 직접 접속이 불가능 한가?
    - WEB/WAS와 DB의 분리 운영 및 내/외 통신망의 분리
  • 데이터베이스에 고객/거래정보가 암호화 저장 되는가?
    - 패스워드, 주민번호, 신용카드번호, 은행계좌번호 등의 중요 정보를 암호화 하여 저장
    - 패스워드 암호화의 경우 단방향 알고리즘(MD5, SHA-1 등)을 사용
    - 공인된 암호 알고리즘(SEED 등)을 사용
    - 문자열의 재배열, 단순치환, ASCII코드값 변환, URL Encode, Base64 Encode 사용금지
    - DB link 등을 이용한 내부 DB와 연결 시 동일한 수준의 암호화 유지
기타 전반적인 보안가이드는 KISA에서 발행한 정보보안가이드를 참조
(http://www.kisa.or.kr)

'참고자료' 카테고리의 다른 글

User Attributes - Inside Active Directory  (0) 2013.12.20
국내 주요 오픈코스웨어 사이트  (0) 2013.02.26

+ Recent posts