본문 바로가기
보안(Security)

단계별 내부통제항목 - 예방(5)

by 카르막 2022. 7. 20.

 

단계별 내부통제항목 - 예방(5)

 

⑤ 개발과 운영 환경 분리
“개발 및 테스트 환경”은 “운영 환경”과 분리하여야 한다. 환경 분리는 개발 및 테스트 서버와 운영 서버를 분리하는 것뿐만 아니라 네트워크의 분리도 함께 이루어져야 한다. 만약 불가피하게 분리할 수 없을 경우에는 “모니터링 강화”, “개발 및 변경 사항 승인”, “책임추적성(Accountability) 확보”를 위한 “변경 내용 저장” 등과 같은 “보완통제”를 마련하여야 한다. 

관련표준 및 지침

K-ISMS 8.2.2 개발과 운영 환경 분리
ISO/IEC 27002:2013 A.12.1.4 Separation of development, testing and operational environments
NIST SP 800-53 CM-2, CM-4, CM-9, SA-10

 

 

⑥ 운영환경 이관
운영환경 이관 절차를 수립하고 이행하여야 하며, 운영환경에 이관되는 “실행 코드”는 “사용자 인수 테스트(User Acceptance Test)”를 통하여 테스트가 완료된 “실행 코드”여야 한다. 또한 “소스 코드” 및 “승인되지 않은 실행 코드”는 이관되어서는 아니 된다. 

관련표준 및 지침

K-ISMS 8.2.3 운영환경 이관
ISO/IEC 27002:2013 A.14.2.3 Technical review of applications after operating platform changes
NIST SP 800-53 CM-3, CM-4, CM-9

 

 

⑦ 테스트 데이터 보안
테스트 과정에서 실제 운영데이터의 유출을 예방하기 위하여 “테스트 데이터 생성”, “이용”, “관리”, “파기” 및 “보안 조치”에 관하여 절차를 수립하고 이행하여야 한다. 특히 개인정보와 같은 민감정보 혹은 중요정보는 ‘표시 제한 보호 조치’를 취하여야 한다. 불가피하게 운영 데이터를 테스트 데이터로 사용할 경우에는 적절한 “승인 절차”를 수립하고 이행하여야 한다. 

관련표준 및 지침

K-ISMS 8.2.4 시험데이터보안
ISO/IEC 27002:2013 A.14.3.1 Protection of test data
NIST SP 800-53 SA-15

 

 

⑧ 소스 코드 보안
소스 코드에 대한 “변경이력”을 관리하고 “비인가자의 접근통제”를 위한 “절차를 수립”하고 이행하여야 한다. 소스 코드는 “운영환경”이 아닌 별도의 환경에 분리 보관하여야 하며, “인가된 담당자만이 접근”해야 한다. 

관련표준 및 지침

K-ISMS 8.2.5 소스 프로그램 보안
ISO/IEC 27002:2013 N/A
NIST SP 800-53 N/A

 

 

⑨ 외주 개발 보안
정보시스템 개발을 “외주 위탁”하는 경우 준수해야 할 “보안 요구사항”을 정의하고 “계약서에 명시”하여서 하며, 외주 위탁업체가 “보안 요구사항을 준수하는 여부를 관리·감독”하여야 한다. 또한 개발이 완료된 소스 코드에 대해서는 “보안취약점을 진단하여 취약점 조치 등을 확인 후에 검수 및 인수”하여야 한다. 

 

관련표준 및 지침

K-ISMS 8.3.1 외주개발보안
ISO/IEC 27002:2013 A.14.2.7 Outsourced development
NIST SP 800-53 SA-1, SA-4, SA-9, SA-10, SA-11, SA-12, SA-13, SA-15

 

 

[참고]

- 책임추적성(Accountability): 시스템 내의 각 개인은 유일하게 식별되어야 한다는 정보 보호 원칙. 이 원칙에 의해서 정보 처리 시스템은 정보 보호 규칙을 위반한 개인을 추적할 수 있고, 각 개인은 자신의 행위에 대해서 책임을 진다. (IT용어사전, 한국정보통신기술협회)

- 인수 테스트(acceptance test)는 시스템이 예상대로 동작하는지 확인하고, 요구 사항에 맞는지 확신하기 위해 하는 테스트이다. 그래서 시스템을 인수하기 전 요구 분석 명세서에 명시된 대로 모두 충족시키는지를 사용자가 테스트한다. 인수 테스트가 끝나면 사용자는 인수를 승낙한 것이다. 시스템이 사용자에게 정상적으로 인수되면 프로젝트는 종료된다. 인수 테스트 시 인수 테스트 계획서는 사용자가 직접 작성하거나, 개발자가 작성한 것을 사용자가 승인한다. 인수 테스트는 사용자 주도로 이루어지며, 오류 발견보다는 제품의 출시 여부를 판단하는 것이 주 목적이다. 인수 테스트 결과에 따라 시스템을 출시할지, 출시 시기를 늦추더라도 보완할지를 결정한다. V & V의 검증(validation)에 해당된다. 사용자가 개발자에게 프로젝트를 발주하고 개발 완료된 것을 테스트할 때는 위와 같은 방법으로 인수 테스트를 하지만, 일반인을 대상으로 제품을 만들어 판매하는 경우에는 알파 테스트와 베타 테스트를 수행한다. (쉽게 배우는 소프트웨어 공학, 김치수)

- 한국인터넷진흥원(2013), “ISMS 인증기준 세부점검항목”, 한국인터넷진흥원
- ISO (2012), “Information technology - Security techniques - Code of practice for information security controls,” ISO.
- Ross, Ronald S (2013), “Security and Privacy Controls for Federal Information Systems and Organizations,”

 

댓글