개발 보안·요구사항·SDLC
요구·설계·구현·시험·운영 단계의 보안 활동을 연결합니다.
1. 개발 보안과 인접 개념
| 구분 | 중심 질문 |
|---|---|
| 개발 보안 | 안전한 소프트웨어를 어떤 과정으로 만들고 유지할 것인가? |
| 보안 기능 | 인증·인가·암호화·감사 기능을 어떻게 제공할 것인가? |
| 시큐어 코딩 | 코드 수준의 보안약점을 어떻게 예방할 것인가? |
| 보안 시험 | 설계와 구현이 요구사항을 만족하는지 어떻게 확인할 것인가? |
| 운영 보안 | 배포된 서비스를 어떻게 설정·관찰·대응할 것인가? |
로그인 기능이 존재해도 객체 인가가 누락되거나 세션이 안전하지 않으면 취약하다. 따라서 보안 기능의 존재와 소프트웨어 전체의 안전성을 구분해야 한다.
2. 개발 방법론이 달라도 보안은 필요하다
| 모델 | 특징 | 보안 적용 시 주의점 |
|---|---|---|
| 폭포수 | 단계를 순차적으로 진행 | 초기 요구·설계 오류가 늦게 발견되지 않도록 단계별 검토 |
| 프로토타이핑 | 빠른 시제품으로 요구 확인 | 임시 계정·Debug 설정·단순 권한 모델이 운영에 남지 않게 함 |
| 나선형 | 반복 주기마다 위험을 분석 | 보안 위험을 일정·비용 위험과 함께 평가 |
| 애자일 | 작은 기능을 반복 제공 | Story와 Acceptance Criteria에 보안 요구·시험을 포함 |
| DevOps | 개발·배포·운영 피드백을 빠르게 연결 | 자동화 도구만으로 개발 보안이 완성된다고 보지 않음 |
3. 보안 요구사항의 도출 근거
보안 요구사항은 다음 근거에서 도출한다.
- 업무 목표와 허용·금지 규칙
- 보호할 데이터와 중요도
- 사용자·관리자·외부 시스템의 역할
- 예상 위협과 오용 경로
- 조직 정책과 적용 법·계약
- 과거 취약점과 사고
- 사용하는 외부 구성요소와 Service의 특성
예를 들어 “보안을 강화한다”는 요구는 검증하기 어렵다. 다음처럼 구체화한다.
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
모호한 요구: 주문정보를 안전하게 보호한다.
검증 가능한 요구:
- 사용자는 자신의 주문만 조회할 수 있어야 한다.
- 관리자 조회는 승인된 역할에만 허용해야 한다.
- 모든 주문 조회 API는 Server-side 객체 권한검사를 수행해야 한다.
- 반복되는 권한 거부는 감사 로그에 남겨야 한다.
4. Abuse Case와 Misuse Case
정상 Use Case가 “사용자가 주문을 조회한다”라면 Abuse Case는 다음과 같이 질문한다.
- 다른 사용자의 주문 ID를 입력하면 어떻게 되는가?
- 대량으로 주문을 조회하면 제한되는가?
- 관리자 기능을 일반 사용자가 직접 호출하면 어떻게 되는가?
- 삭제·환불 같은 상태 변경을 반복하면 어떻게 되는가?
Abuse·Misuse Case는 공격 Payload 목록이 아니라 정상 기능이 악용되는 경로를 찾는 방법이다.
5. 위협 모델링
위협 모델링은 설계 구조를 기준으로 자산·행위자·신뢰 경계·공격 경로를 식별하고 대응 위치를 정하는 과정이다.
기본 흐름은 다음과 같다.
- 범위와 보호 대상을 정한다.
- Data Flow와 Trust Boundary를 그린다.
- 각 경계에서 가능한 위협을 식별한다.
- 예방·탐지·복구 통제를 정한다.
- 설계가 변경되면 모델을 갱신한다.
STRIDE는 위협을 점검하는 한 가지 분류다.
| 구분 | 질문 예 |
|---|---|
| Spoofing | 다른 사용자나 시스템으로 가장할 수 있는가? |
| Tampering | 데이터·요청·설정을 변조할 수 있는가? |
| Repudiation | 행위를 부인할 수 있고 증거가 부족한가? |
| Information Disclosure | 민감정보가 노출되는가? |
| Denial of Service | 자원을 고갈시킬 수 있는가? |
| Elevation of Privilege | 더 높은 권한을 얻을 수 있는가? |
STRIDE를 사용했다는 사실보다 실제 Data Flow와 신뢰 경계를 빠뜨리지 않는 것이 중요하다.
6. 단계별 핵심 보안 활동
| 단계 | 대표 활동 |
|---|---|
| 기획 | 보호 대상·중요도·책임·기본 기준 정의 |
| 요구사항 | 인증·인가·데이터 보호·로그·가용성 요구 작성 |
| 설계 | Data Flow·Trust Boundary·위협 모델링·보안 설계 검토 |
| 구현·빌드 | 시큐어 코딩, Dependency·비밀값·빌드 설정 관리 |
| 검증 | 코드 검토, 정적·동적 시험, Abuse Case와 회귀 시험 |
| 배포 | 승인된 Artifact와 안전한 설정·비밀정보 주입 확인 |
| 운영 | Patch, Monitoring, 취약점 대응, 사고 원인의 피드백 |
| 폐기 | 데이터·계정·Key·Endpoint의 안전한 종료 |
보안은 마지막 시험 단계의 책임이 아니라 각 단계에서 다른 형태의 증거를 만든다.
스스로 확인하기
개념 확인 문제
문제를 누르면 바로 아래에서 정답과 해설을 확인할 수 있습니다.
01보안 기능이 있고 마지막 취약점 진단을 통과하면 개발 보안이 완성되는가?
정답 및 해설
아니다. 요구사항·설계부터 단계별 통제를 적용하고 운영의 취약점도 다음 개발에 반영해야 한다.
02“주문정보를 안전하게 보호한다”를 검증 가능한 요구로 바꾸면?
정답 및 해설
예: 모든 주문 조회 API는 현재 사용자의 객체 권한을 검사하고 다른 사용자의 주문 접근을 거부해야 한다. 대상·주체·조건이 구체적이어야 시험할 수 있다.