11편에서 버퍼 오버플로우·인젝션·XSS 같은 개별 취약점의 정체를, 17편에서 네트워크 보안 장비를 다뤘다. 이 편은 시야를 넓혀 “취약점이 애초에 왜 시스템에 심어지는가”, “이미 운영 중인 시스템의 취약점을 어떻게 관리하는가”를 다룬다. 독학사 출제기준의 “안전한 개발·운영” 영역은 특정 취약점의 원리보다 개발수명주기 전체에서 보안을 어느 단계에 배치하는가, 운영 단계의 변경·구성관리 절차를 묻는 문제가 많다.

왜 개발 초기부터 보안을 넣어야 하는가

쉽게 말하면: 설계 단계에서 못 찾은 결함은 운영 단계에서 고치려면 수십 배 더 비싸다.

전통적인 개발 방식은 시스템을 다 만든 뒤 마지막에 보안 점검을 하는 방식이었다. 이 방식의 문제는 결함을 늦게 발견할수록 수정 비용이 기하급수적으로 커진다는 점이다. 설계 단계에서 보안 요구사항을 놓치면, 그 결함은 구현·테스트를 거쳐 운영 단계까지 그대로 흘러가고, 운영 중인 시스템의 구조적 결함을 고치려면 재설계에 가까운 작업이 필요해진다.

이런 문제의식에서 나온 것이 Secure SDLC(Secure Software Development Life Cycle, 보안이 내재된 소프트웨어 개발수명주기)다. 핵심 아이디어는 보안을 마지막 점검 단계 하나에 몰아넣지 않고, 요구사항 정의부터 운영·유지보수까지 모든 단계에 보안 활동을 분산 배치하는 것이다.

단계별 보안 활동

쉽게 말하면: 각 개발 단계마다 그 단계에 맞는 보안 질문을 던지고 답을 남겨야 한다.

각 단계는 독립적이지 않고 피드백 순환을 이룬다. 운영 중 발견된 취약점은 다시 요구사항·설계 단계에 반영되어 다음 개발 주기를 개선한다.

안전한 코딩 원칙

쉽게 말하면: 입력을 믿지 말고, 필요한 권한만 주고, 실패했을 때는 안전한 쪽으로 실패하게 만든다.

구현 단계에서 지켜야 할 핵심 원칙 몇 가지는 다음과 같다. 개별 취약점(SQL 인젝션, XSS 등)의 원리는 11편에서 이미 다뤘으므로, 여기서는 그 취약점들을 예방하는 공통 설계 원칙에 집중한다.

• 입력값 검증(input validation): 외부에서 들어오는 모든 데이터는 일단 의심하고, 허용된 형식·범위인지 검증한 뒤 사용한다. 인젝션·XSS 계열 취약점 대부분이 이 원칙을 지키지 않아서 발생한다(자세한 내용은 11편 참고).
• 최소권한 원칙(least privilege): 프로그램이나 계정에는 업무 수행에 꼭 필요한 최소한의 권한만 부여한다. 관리자 권한으로 실행되는 프로세스는 취약점이 발견되었을 때 피해 범위가 그만큼 커진다.
• 안전한 실패(fail-safe / fail-secure): 오류나 예외가 발생했을 때 시스템이 “허용” 쪽으로 열리지 않고 “차단” 쪽으로 닫히도록 설계한다. 예를 들어 인증 서버 응답이 지연되어 타임아웃이 나면 접근을 자동으로 허용하는 것이 아니라 거부해야 한다.
• 심층 방어(defense in depth): 하나의 방어선이 뚫려도 다음 방어선이 막을 수 있도록 여러 겹의 통제를 배치한다(17편의 방화벽·IPS·VPN을 겹쳐 배치하는 것도 심층 방어의 한 예다).
• 민감정보 최소 노출: 오류 메시지·로그에 비밀번호·주민등록번호 같은 민감정보나 시스템 내부 구조가 그대로 노출되지 않도록 한다.

변경관리와 형상관리

쉽게 말하면: 운영 중인 시스템을 함부로 바꾸지 못하게 하고, 지금 무엇이 어떤 상태로 돌아가고 있는지 항상 기록해 둔다.

변경관리(change management)는 운영 중인 시스템에 변경(패치 적용, 설정 변경, 코드 배포 등)을 가할 때 승인 절차 없이 임의로 바꾸지 못하게 통제하는 절차다. 변경을 요청 → 검토 → 승인 → 적용 → 검증의 순서로 진행하고, 각 단계의 기록을 남긴다. 이 절차가 없으면 담당자 한 사람의 실수나 임의 조치로 전체 서비스가 장애를 일으킬 수 있다.

형상관리(configuration management)는 시스템을 구성하는 요소(하드웨어, 소프트웨어 버전, 설정값, 네트워크 구성 등)의 현재 상태를 기준선(baseline, 정상으로 승인된 표준 상태)으로 정해 놓고 관리하는 것이다. 이 기준선이 있어야 “지금 시스템이 승인된 상태에서 벗어났는지”를 판단할 수 있고, 침해사고 발생 시 “무엇이 바뀌었는가”를 빠르게 확인할 수 있다(18편의 분석 단계와 직결된다). 형상 정보를 모아 두는 저장소를 CMDB(Configuration Management Database, 형상관리 데이터베이스)라 부른다.

변경관리와 형상관리는 서로 맞물려 돌아간다. 변경관리는 “바꾸는 절차”를 통제하고, 형상관리는 “바뀐 결과가 기준선과 일치하는지”를 확인한다.

운영 중 취약점 관리와 패치관리

쉽게 말하면: 시스템은 배포 후에도 계속 새로운 취약점이 발견되므로, 발견 → 평가 → 적용 → 확인의 반복 절차가 필요하다.

운영 단계에서는 새로운 취약점이 지속적으로 공개된다. 취약점 관리(vulnerability management)는 이를 체계적으로 다루는 절차이며, 보통 다음 순서를 따른다.

1. 취약점 스캐닝: 자동화된 도구로 시스템의 알려진 취약점을 주기적으로 점검한다.
2. 위험 평가: 발견된 취약점이 실제로 얼마나 위험한지(19편의 위험분석 방법을 적용) 심각도를 매긴다. 흔히 CVSS(Common Vulnerability Scoring System, 취약점 심각도를 점수화하는 국제 표준 체계) 점수를 참고한다.
3. 패치 적용: 심각도가 높은 취약점부터 우선순위를 정해 패치를 적용한다. 이때 변경관리 절차를 반드시 거쳐야 한다 — 패치 자체도 시스템 변경이기 때문이다.
4. 검증: 패치 적용 후 취약점이 실제로 해소되었는지, 다른 기능에 부작용은 없는지 재점검한다.

패치를 즉시 적용하지 못하는 경우(운영 중단이 어려운 시스템, 호환성 문제 등)에는 임시 완화조치(mitigation, 예: 해당 포트를 방화벽에서 임시 차단)를 먼저 적용하고, 정식 패치는 계획된 점검 시간에 반영하는 방식으로 위험을 관리한다.

자주 틀리는 점

• 보안 점검을 테스트 단계에만 하면 충분하다고 착각한다. Secure SDLC의 핵심은 요구사항·설계 단계부터 보안을 반영하는 것이며, 테스트 단계에서만 점검하면 구조적 결함은 이미 늦게 발견된다.
• 변경관리와 형상관리를 같은 것으로 혼동한다. 변경관리는 “바꾸는 절차의 통제”, 형상관리는 “현재 상태를 기준선으로 관리하는 것”이라는 차이가 있다.
• 패치를 발견 즉시 무조건 적용해야 한다고 생각한다. 패치도 시스템 변경이므로 변경관리 절차(영향도 검토·승인)를 거쳐야 하며, 심각도에 따라 우선순위를 정해 적용하는 것이 원칙이다.
• 최소권한 원칙을 계정에만 적용한다고 생각한다. 사람의 계정뿐 아니라 프로세스·서비스 계정에도 최소권한 원칙이 적용되어야 한다.

핵심 정리

• Secure SDLC는 보안을 테스트 단계에 몰아넣지 않고 요구사항–설계–구현–테스트–배포–운영 전 단계에 분산 배치하는 개발 방법론이다.
• 안전한 코딩 원칙에는 입력값 검증, 최소권한, 안전한 실패, 심층 방어, 민감정보 최소 노출이 있다.
• 변경관리는 시스템 변경의 승인 절차를 통제하고, 형상관리는 시스템의 현재 상태를 기준선으로 관리한다.
• 운영 중 취약점 관리는 스캐닝 → 위험 평가 → 패치 적용 → 검증의 순서로 반복되며, 패치 적용도 변경관리 절차를 거쳐야 한다.

마무리 복습

참고 자료

• 국가평생교육진흥원 독학학위제 시험안내 
• NIST Computer Security Resource Center 
• OWASP