A.8.26
애플리케이션 보안 요구사항
기술적 통제확인사항 6증적 6사례 6
통제 목적
애플리케이션 개발/도입 시 정보 민감도, 노출 환경, 인증/접근 특성과 거래 성격에 따라 보안 요구사항을 식별하고 승인하여 설계와 검증에 반영하는 통제입니다. 요구사항을 초기에 구체화하면 설계 누락과 재작업을 줄일 수 있습니다. 공개 네트워크 통신과 전자거래에는 기밀성, 무결성, 중복/재전송 방지 등을 위험에 맞게 적용하고, 행위 증명이 필요한 거래는 서명과 감사 추적 등 추가 요건을 정합니다.
주요 확인사항
- 애플리케이션 개발/도입 시 처리 정보의 민감도와 노출 환경(내부망/공개망)에 따라 보안 요구사항을 식별/문서화하고 승인하는 절차가 있는가?
- 인증/인가/세션 관리/접근통제에 대한 요구사항이 요구사항 정의서에 구체적으로 반영되어 있는가?
- 입력 검증, 출력 인코딩, 안전한 오류 처리, 인젝션/변조 방지 등 애플리케이션 취약점 대응 요구사항이 정의되어 있는가?
- 공개망 통신/거래의 암호화, 무결성, 누락/중복/재전송/오전달 방지와 필요한 행위 증명 요건을 거래 성격과 위험에 맞게 정하는가?
- 개인정보/결제정보 처리에 관한 법적/계약적 요구사항과 로깅/감사 추적 요구사항이 반영되어 있는가?
- 정의된 보안 요구사항이 설계/구현/시험 단계에서 검증/시험되고 릴리스 전에 승인되는가?
이행 지침
- 애플리케이션 유형(웹/모바일/API/전자거래 등)과 처리 정보 등급, 노출 환경을 기준으로 보안 요구사항 카탈로그/체크리스트를 마련하고, 프로젝트 착수 단계에서 위험평가 결과에 따라 요구사항을 선정합니다.
- 인증(다중 인증 포함), 인가 및 권한 최소화, 세션 관리, 접근통제 요구사항을 명세하고, 신뢰수준이 다른 사용자/시스템 간 상호작용에 대한 통제 요구사항을 정의합니다.
- 입력 검증, 출력 인코딩/이스케이프, 안전한 오류 처리, 인젝션/XSS/CSRF/안전하지 않은 역직렬화 방지 등 알려진 취약점 대응 요구사항을 안전한 코딩 표준(A.8.28)과 연계하여 정의합니다.
- 공개망 통신에는 적절한 전송 보호를 적용하고, 거래 특성에 따라 무결성, 중복/재전송 방지, 결제 검증 등의 요건을 정합니다. 부인 방지를 위한 증명이 필요하면 검증 가능한 서명, 주체와 거래의 연결, 보호된 감사 기록과 시간 근거를 함께 설계합니다. 타임스탬프만으로 행위자를 증명할 수 있다고 가정하지 않습니다.
- 개인정보 및 결제정보를 처리하는 경우 관련 법규/기준(개인정보 보호법, PCI DSS 등)과 데이터 보관/파기, 로깅/감사 추적 요구사항을 반영합니다.
- 정의한 보안 요구사항은 추적성(요구사항 ID)을 확보하여 설계/구현/시험(A.8.29)에서 검증하고, 도입(구매/SaaS) 제품의 경우 공급자의 보안 기능이 요구사항을 충족하는지 평가/승인합니다.
증적자료
- 애플리케이션 보안 요구사항 정의서/체크리스트 및 승인 기록
- 요구사항 도출 근거가 되는 위험평가 및 데이터 등급 분류 결과
- 인증/인가/접근통제/세션 관리 설계 문서
- 공개망/전자거래 요구사항(전송 암호화, 거래 무결성, 부인 방지 등) 명세 및 적용 내역
- 보안 요구사항에 대한 시험/검증 결과(설계 검토, 보안 시험 보고서)
- 도입 애플리케이션의 공급자 보안 요구사항 충족 평가 및 승인 문서
부적합 사례
- 애플리케이션 개발/도입 시 보안 요구사항을 별도로 정의하지 않고 기능 요구사항만으로 진행한 경우
- 공개망 거래의 위험과 적용되는 의무를 검토하지 않아 필요한 전송 보호, 무결성 또는 행위 증명 요건이 누락된 경우
- 입력 검증/인젝션 방지 등 취약점 대응 요구사항이 없어 동일 유형의 취약점이 반복 발생하는 경우
- 개인정보/결제정보 처리에 대한 법적 요구사항이 보안 요구사항에 반영되지 않은 경우
- 정의된 보안 요구사항이 시험/검증 단계에서 확인되지 않은 채 제품이 릴리스된 경우
- 도입(구매/SaaS) 애플리케이션의 보안 기능이 요구사항을 충족하는지 평가하지 않은 채 해당 애플리케이션을 도입한 경우