보안 문제들/개발 방법론

쥬·2023년 4월 19일

보안 (Security)과 관련된 문제들은 어떤 것이 있나요?

1. API 보안 문제

API는 내·외부 데이터를 손쉽게 제공하고, 디지털 전환 시대에 다양하게 활용되고 있다. 잘 설계된 API는 프로그램 개발을 보다 쉽게 해주기 때문에 기업에서의 API 사용은 빠르게 증가하는 추세다. 반면 보안 위협은 갈수록 커지고 있다. API 보안 인식이 부족하고, 보안이 허술하기 때문이다.
API는 웹공격, 인증정보 도용, DDoS 공격까지 광범위하게 악의적으로 활용될 수 있으며, 각각의 공격방식 및 여러 각도의 공격 면을 보호할 수 있어야 한다.

2022년 상반기 API 공격시도는 지난해보다 수백 배 급증했고, API 남용과 데이터 침해 사고는 2024년도까지 약 2배가량 증가할 것으로 예측됐다. API는 민감한 데이터가 저장된 백엔드 데이터베이스에 직접 연결되기 때문에 해커는 이를 노리고 API 기반 인프라 경로를 표적 삼아 데이터를 훔쳐낸다. API 보안사고는 데이터 유출, 데이터 스크래핑(Data Scraping), 액세스 노출, 최종 사용자 추적, 계정 탈취 등이 있으며, 기업의 상당수는 API 관련 문제를 겪고 있다.

OWASP API Security Top 10 2019

API 사용량이 늘면서 API 보안 위협이 커짐에 따라 OWASP(The Open Web Application Security Project)에서는 API 보안 위협의 심각성을 인지해 지난 2019년 API 보안 취약점 TOP 10을 발표했다.

손상된 객체 수준 인증(Broken Object Level Authorization)은 API가 서로 통신할 때, 객체 수준의 권한 검사를 하지 않으면 데이터가 유출될 수 있는 취약점이다.
손상된 사용자 인증(Broken User Authentication)은 공격자가 인증 메커니즘이 잘못 구현된 것을 노리고, 인증 토큰을 손상 시키거나 구현 결함을 악용해 다른 사용자의 ID를 추정할 수 있는 취약점이다.
과도한 데이터 노출(Excessive Data Exposure)은 API가 호출될 때 민감한 데이터를 찾아 추가적인 공격을 시행하는 취약점이다. 개발자가 데이터 필터링을 사용자에게 표시하기 전에 클라이언트에 의존해 각각의 민감도를 고려하지 않을 경우 모든 객체 속성을 노출시킬 수 있다.
리소스 부족 및 속도 제한(Lack of Resources & Rate Limiting)은 API가 네트워크, CPU, 메모리 및 스토리지와 같은 시스템 리소스를 사용한다. 그러나 클라이언트/사용자가 요청할 수 있는 리소스 크기나 수에 제한을 두지 않아 API 서버 성능에 영향을 미쳐 DDoS나 Credential Stuffing 공격 등으로 인증 및 가용성에 취약할 수 있다.

express-rate-limit 모듈이용

손상된 기능 수준 인증(Broken Function Level Authorization)은 기업의 복잡한 접속 관리 정책으로 인해 관리 기능과 일반 기능이 불분명하게 분리돼 권한 부여 결함이 발생할 수 있다. 공격자는 이를 노리고, 다른 사용자의 리소스 및 관리 기능에 액세스할 수 있다.
대량 할당(Mass Assignment)은 허용 목록에 기반해 속성 필터링 없이 클라이언트가 제공한 데이터를 데이터 모델에 바인딩하면 일반적으로 대량 할당이 발생한다. API 엔드포인트는 데이터 노출 수준과 민감도를 고려하지 않고 자동으로 클라이언트의 변수를 내부 속성으로 자동 변환하게 된다. 공격자는 이러한 취약점을 노리고 시스템의 주요 정보를 탈취할 수 있다.
보안 설정 오류(Security Misconfiguration)는 보안 강화 누락, Cross-Origin 자원 공유(CORS), 데이터 및 민감 데이터 처리 오류 메시지를 보안 구성으로 적용하는 등 취약하고 신뢰할 수 없는 구성 요소로 설정해 발생하는 취약점이다.
주입(Injection)은 SQL 등과 같은 주입 결함으로 의도하지 않은 명령을 실행하거나 공격자가 권한 없이 데이터에 액세스할 수 있다.
부적절한 자산 관리(Improper Assets Management)는 API가 기존 웹 애플리케이션보다 엔드포인트를 더 많이 외부로 노출하는 경우를 노리고 공격할 수 있는 취약점이다. 따라서 API 현황에 대해 수시로 업데이트 및 문서화 하는 게 중요하다.
불충분한 로깅 및 모니터링(Insufficient Logging & Monitoring)은 기업에 가시성을 확보하지 못하게 해 사이버공격을 당했어도 모를 수 있으며, 발 빠른 대응이 어렵다. 비효율적인 사고 대응으로 공격자는 데이터를 변조, 추출 또는 파괴할 수 있으며, 시스템을 추가로 공격하거나 지속적으로 공격할 수 있다. 기업 대부분의 침해 탐지 소요기간은 200일 이상이며, 내부 프로세스나 모니터링이 아닌 외부에 의해 탐지된다.

해결방안

개발 및 출시할 때 기존의 웹방화벽, ID 관리나 데이터보호, 그리고 API 보안에 적합한 툴을 활용할 수 있어야 한다.
API 개발팀에만 의존하지 말고, 네트워크 및 보안 운영팀, ID팀, 리스크 관리자, 보안 설계자 및 법무 준수팀 등 여러 팀과 협업해 법률준수 등과 같이 규정의 부합성을 고려해야 한다.

2. 오픈소스 활성화로 인한 보안 위험

오픈소스는 디지털 정부, 스마트 시티, 자율주행 등 다양한 산업 분야의 파괴적인 혁신을 초래하며 소프트웨어 생태계 활성화를 주도하고 있다. 빅테크 기업 주도의 오픈소스 기술 성숙도 향상은 비즈니스 생태계의 신성장 동력으로 작용하며 산업 전반에 긍정적인 영향을 미치고 있지만, 도리어 사이버 보안의 새로운 공격 벡터로 작용하고 있다.

오픈소스의 발전 현황

초기 SW 상업화에 저항하기 위해 자발적으로 참여하던 오픈소스는 저항의 굴레에서 벗어나 자생력을 가진 구조로 발전하였다. 라이선스 분화 및 커뮤니티 조직화를 통해 생태계 자생력을 확보하면서 텐서플로, 파이토치, 쿠버네티스, 아폴로 등 빅테크 기업 주도의 시드 기술과 공유의 토대가 되었다. 오픈소스의 기술적·구조적 성숙도 향상은 디지털 전환의 촉매제로 산업 간 연계와 융합이라는 빅블러를 가속화한다.

오픈소스 생태계에서 발생하는 보안 위험

소프트웨어 생태계에서 오픈소스 활용 비중이 높아지면서, 오픈소스로 인한 보안 위험을 소프트웨어의 공격 벡터로 악용될 수 있는 관계를 갖게 된다. 오픈소스는 소스코드, 라이브러리, 패키지 등 소프트웨어 구성요소가 공개 레파지토리나 비공개 레파지토리를 통해 다수의 참여자가 협업 작업을 하므로 생태계 활성화에 긍정적인 영향을 미친다. 문제는 오픈소스가 사이버 공격의 공격 벡터로 악용되거나 라이선스 이슈 등이다. 오픈소스 생태계에서 발생하는 보안 위험은 관리적 측면과 기술적 측면으로 나눌 수 있다.

2022년 9월까지 확인된 오픈소스 취약점은 작년 대비 33% 증가된 수치로, 공격자들이 오픈소스의 구성 요소들을 공격에 적극적으로 활용하고 있다는 것을 알 수 있다.

오픈소스는 참여자들이 자발적으로 소프트웨어의 라이프 사이클에 참여하고 있기 때문에 때에 따라 즉각적인 보안패치가 발생되지 않거나, 보안담당자 등이 취약점의 영향도를 확인해야 하므로 취약점에 따른 영향도 나 종속성 등이 고려되지 않을 수 있다. 이러한 점을 이용해 해킹그룹에서도 신규 취약점을 이용하기보다 기존에 발견된 패치되지 않은 취약점을 악용하는 경우들이 빈번하다.

해결방안

오픈소스로 인한 보안 위험 중 보안 취약점에 대응하기 위해서는 현행의 소프트웨어 개발 조직 및 업무절차, 도구 등을 파악해야 한다. 보안을 강화하기 위해서는 정량적·정성적 관점으로 위험을 측정해야 하고 측정하기 위해서는 위험을 유발하는 요소를 식별하는 것이 가장 중요하기 때문이다.
2022년 12월 금융감독원과 금융보안원에서는 금융회사에서 오픈소스 활용 시에 발생하는 보안 리스크를 최소화하기 위한 일환으로 ‘오픈소스 소프트웨어 활용 관리 안내서’를 배포하였다.

개발 방법론 (Development Methodology)에 대해 설명해보세요.

소프트웨어 개발 방법론

소프트웨어 개발 방법론(Software Development Methodology) 개념

소프트웨어 개발 방법론은 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법이다.
소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론이다.

소프트웨어 개발 방법론 종류

구조적 방법론(Structured Development)

전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
프로세스 중심의 하향식 방법론
구조적 프로그래밍 표현을 위해 나씨-슈나이더만(Nassi-Shneiderman) 차트 사용
- 논리의 기술에 중점을 둔 도형식 표현 방법
- 연속, 선택, 및 다중 선택, 반복 등의 제어 논리 구조로 표현
- 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합

정보공학 방법론(Information Engineering Development)

정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론

객체지향 방법론(Object-Oriented Development)

'객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론
복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론
객체, 클래스, 메시지를 사용

컴포넌트 기반 방법론(CBD; Component Based Development)

소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
개발 기간 단축으로 인한 생산성 향상
새로운 기능 추가 쉬움(확장성)
소프트웨어 재사용이 가능

애자일 방법론(Agile Development)

절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론

제품 계열 방법론(Product Line Development)

특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
임베디드 소프트웨어를 작성하는 데 유용한 방법론
영역 공학과 응용 공학으로 구분
- 영역 공학: 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역
- 응용 공학: 제품 요구분석, 제품 설계, 제품을 구현하는 영역

애자일(Agile)

애자일(Agile) 방법론의 개념

애자일 방법론은 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론이다.

개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아서 유동적으로 개발할 수 있다.

애자일은 정확히 말하자면 소프트웨어 개발에 필요한 작업을 알려주는 일련의 규정이 아닙니다. 그보다는 협업과 워크플로우를 바라보는 하나의 관점이며, 우리가 무엇을 어떻게 만들지에 관한 선택을 안내하는 가치 체계입니다.

비교 대상	애자일 방법론	전통적 방법론
계획수립	유동적 범위 설정	확정적 범위 설정
업무수행	팀 중심 업무 수행	관리자 주도적 명령과 통제 개인 단위로 업무 수행
개발/검증	반복 주기 단위로 소프트웨어를 개발/검증	분석/설계/구현/테스트를 순차적으로 수행
팀관리	업무 돌입, 팀 평가	경쟁, 개별 평가
문서화	문서화보다는 코드를 강조	상세한 문서화를 강조
성공요소	고객 가치 전달	계획/일정 준수
유형	XP, 스크럼, 린	폭포수, 프로토타입 나선형

애자일 방법론 등장 배경

기존 개발 방법론의 한계를 극복하기 위해 등장했다
- 전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어려움
- 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성 증가
소프트웨어 개발 환경의 변화
- 소프트웨어 개발 트렌드가 모바일 환경으로 변화
- 시장 적시성과 잦은 배포의 중요성 부각

애자일 방법론의 유형

1. XP(eXtreme Programming)

의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

1~3주의 반복(Iteration) 개발주기

2. 스크럼(Scrum)

매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

백로그(Backlog)
제품과 프로젝트에 대한 요구사항
스프린트(Sprint)
2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상
스크럼 미팅(Scrum Meeting)
매일 15분 정도 미팅으로 To-Do List 계획수립
데일리 미팅(Daily Meeting)이라고도 함
스크럼 마스터(Scrum Master)
프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
스프린트 회고(Sprint Retrospective)
스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
해당 스프린트가 끝난 시점이나 일정 주기로 시행
번 다운 차트(Burn Down Chart)
남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
백로그는 보통 수직축에 위치하며 시간은 수평축에 위치