소프트웨어 개발에 중점을 둔 보안 보증 프로세스. 2004년부터 진행하는 모든 개발 프로젝트에 필수 정책으로 사용되고 있다.

기존의 소프트웨어 개발 주기인 SDLC(Software Development Lifecycle)에 보안을 고려한 SDL(Security Development Lifecycle) 모델을

별도로 구성해 기존 개발 주기에 소프트웨어 보안 및 개인정보 보호 기능을 통합시켰다.

SW 개발 보안의 중요성을 뒷받침하는 대표적인 사례. 자체적으로 개발한 개발생명주기를 제품 개발 전 과정에 적용토록 하여

보안 취약점의 원인을 제거하도록 했다. 개발 과정에서 MS-SDL을 적용한 운영체제 및 DB서버의 보안 취약점이 감소하는 효과가 있다.



1. Pre-SDL

소프트웨어 개발팀의 구성원들이 보안의 기초와 최신 보안 동향에 대한 정보를 매년 1회 교육을 받을 수 있도록 한다.


순번

보안 교육이 포함해야 하는 내용

 1

 시큐어 설계

 2

 위협 모델링

 3

 시큐어 코딩

 4

보안 테스팅

5

프라이버시



2. 요구사항

신뢰성 있는 소프트웨어를 구축하기 위해 기본 보안 요구사항, 프라이버시 요구사항을 정의한다.


순번 

 필수 항목

 1

 SDL 방법론 적용 여부 결정

 2

 보안 책임자(Security Advisor) 선정

 3

 보안 팀(Security Champion) 선정

 4

 버그 리포팅 도구 정의

 5

 보안 버그 경계(Security bug bar) 정의

 6

 보안 위험 평가

 7

 보안 계획서 작성

 8

 버그 추적 시스템 정의



3. 설계

구현에서부터 배포에 이르는 동안 수행해야 하는 작업 계획을 수립하는 단계이다.


순번

 항목

 1

보안 설계 검토

 2

 방화벽 정책 준수

 3

 위협 모델링

 4

 위협 모델 품질 보증

 5

 위협모델 검토 및 승인

 6

 보안 설계서 문서 작성

 7

 보단 디폴트 인스톨 실행

 8

 모든 샘플 코드의 보안 검토 수행

 9

 안전하지 않은 함수와 코딩 패턴 알림

 10

 설계 변화 요구에 관한 보안 관련 사항 문서화

 11

 위협 모델을 통해 찾아진 취약성을 위한 작업 목록 작성


* 공격 표면(Attack Surface) 계획 수립

- 공격 표면이라는 개념적으로 정보 및 금융 자산, 지적 재산, 또는 비즈니스 수행 역량에 존재하는 잠재적 공격 지점을 확인하는 과정의 의미.

위협 모델링에서 공격 표면 관리는 일종의 네트워크, 애플리케이션, 시스템 등 공격자들이 데이터나 정보를 수집하는 지점을 확인하고 공격을 예방하는 것



4. 구현

보안 및 프라이버시 문제점을 발견하고 제거하기 위해 개발 Best Practice를 수립하고 따르도록 한다.


순번

 항목

 1

 최신 버전의 빌드 도구 사용

 2

 금지된 API 사용 회피

 3

 'Execute' 허가를 통한 SQL 안전하게 사용

 4

 저장된 프로시저에서의 SQL 사용

 5

 안전하게 소프트웨어를 사용하기 위해 필요한 사용자 정보 식별

 6

 사용자 중심의 보안 문서 계획

 7

 보안 형상 관리에 관한 정보 생성

 8

 자동화된 금지 API 변환 실행

 9

 프로젝트 팀 전체와 모든 모범 사례와 정책에 대해 정의, 문서화, 토론 등



5. 검증

코드가 이전 단계에서 설정한 보안과 프라이버시를 지키는지, 보안 및 프라이버시 테스팅과 보안 푸쉬(Security Push), 문서 리뷰를 통해 확인한다.

보안 푸쉬는 팀 전체에 걸쳐 위협 모델 갱신, 코드 리뷰, 테스팅에 초점을 맞춘 작업이다.


순번

 항목

 1

커널-모드 드라이버를 위한 테스팅 완료

 2

 COM 객체 테스팅 수행

 3

 인증된 사이트 크로스 도메인 스크립팅을 위한 테스팅

 4

 애플리케이션 검증 테스트 수행

 5

 파일 Fuzzing 수행

 6

 위협 모델 검토 및 수정 등

 7

 보안 테스팅 계획 완료

 8

 침투 테스팅 수행

 9

 시큐어 코드 검토

 10

 보안 푸쉬를 시작하기 전 모든 코드에 대한 우선 순위 결정

 11

 보안 문서 계획서 검토 등


1. 정의

비즈니스 요구 사항을 만족하는 시스템을 구축하기 위해 전체 시스템에 대한 구조를 정의한 문서.

시스템을 구성하는 컴포넌트와 그 컴포넌트를 구성하는 정보(데이터)를 정의.

 

소프트웨어 구성 요소와 구성 요소들이 지니고 있는 특성 중 외부에 드러나는 특성, 그리고 구성 요소들의 관계를 표현하는 시스템의 구조나 구조체.

 

소프트웨어 아키텍쳐는 현재의 요구 사항 뿐 아니라 변화되는 비지니스 전략에 대응이 가능하도록 장기적인 로드맵을 수용하여 확장 가능한 형태로 디자인 되어야 하며, 가능하면 구현하고자 하는 조직의 기술 수준, 조직의 규모와 형태 그리고 비지니스의 형태에 맞춰 설계되어야 함.

 

 

2. 시스템 아키텍쳐 설계 필수 요소

종류

설명

애플리케이션 아키텍쳐 (Application Architecture)

 애플리케이션 소프트웨어에 대한 아키텍쳐를 설계.

 컴포넌트 정의, 컴포넌트 관계, 특정 기능에 대한 컴포넌트 간의 호출 흐름, 컴포넌트 간의 통신을 위한 메세지에 대한 규격 정의를 포함.

테크니컬 아키텍쳐 (Technical Architecture)

 애플리케이션의 배포 구조 정의.애플리케이션을 배포할 하드웨어의 구조와 애플리케이션 개발에 사용하는 미들웨어(ex. DBMS, Web Server etc...) 등의 배포 구조를 함께 정의.

데이터 아키텍쳐 (Data Architecture)

 애플리케이션에서 다루는 데이터의 구조와 관계를 정의.

 

 

3. 아키텍쳐를 사용하는 이유

ㄱ. 소프트웨어 아키텍쳐가 시스템의 공통적인 추상화를 제공함으로서, 관련 이해 당사자들 간의 상호 이해와 협상, 일치, 의사 소통의 기본을 제공.

ㄴ. 시스템 분석, 설계시의 초기 결정 사항을 제공.

ㄷ. 시스템의 요약된 형태로서 향후에 상세한 시스템 구성의 기본을 제공.

=> 개발과 유지보수 비용을 줄이고 제품의 품질을 높일 수 있음

1. 웹서버 (Web Server)

- 웹 클라이언트에게 컨텐츠를 제공하는 서버.

- 정적인 html, jpg, gif, javascript 같은 이미지를 http 프로토콜을 통해 웹브라우저에 전송함.

- 서버에 있는 리소스를 전달하는게 주된 기능, 클라이언트로부터 컨텐츠를 받는 것.

 

 

2. 웹 어플리케이션 서버(Web Application Server)

- 서버 단에서 어플리케이션이 동작할 수 있도록 지원함.

- 기존 웹서버와 달리 동적인 요구에 대응하기 위해 적합한 형태로 진화하였다 (Web Client에서는 결과값만 전송함)

- 서버 단에서 http를 통해 사용자의 장치에 애플리케이션을 수행해주는 미들웨어.

- Servlet, Asp, Jsp, PHP 등의 웹 언어로 작성된 웹애플리케이션을 서버단에서 실행한 후, 실행 결과값을 사용자에게 넘겨주고, 우리가 가진 브라우저가 결과를 해석하여 화면에 표시하는 순으로 동작한다.

 

ㄱ. 역할

- 프로그램 실행 환경 + DB 접속 기능 제공

- 여러 개의 트랜젝션 관리

- 업무를 처리하는 비즈니스 로직을 수행

 

ㄴ. 종류

- Apache Tomcat

- JEVS

- Weblogic

- IIS

 

 

3. 차이

- 정적 데이터 전송 vs 동적 데이터 전송의 차이이나 Apache Tomcat의 경우 웹 애플리케이션 서버에 웹서버 기능이 포함된 서버 프로그램이다.

 

* Apache Tomcat : Tomcat에 자체 웹서버가 있어 Tomcat만 사용해도 jsp 웹 서버 구현은 가능하지만, 내장 웹서버는 아주 기본적인 기능만 하기 때문에 대용량의 콘텐츠를 전송하는 경우에는 웹서버인 Apache Tomcat을 꼭 설치해야 한다.

 

'개발지식 > 그 외' 카테고리의 다른 글

마이크로소프트의 개발생명주기(MS-SDL)  (0) 2017.06.25
아키텍쳐 (Architecture)  (0) 2016.11.07

+ Recent posts