Keyword
- Defense in depth
- API
- MS-SBOM, SPDX
- low-code, 4GL
—
Contents
1.“더 나은 보안을 위한 종합적인 접근” 심층 방어의 이해
심층 방어란 하나가 실패하면 다른 것이 버틸 것이라 가정해 도구, 매커니즘, 정책을 배치하는 보안 전략
즉 다양한 도구를 통해 다양한 위협이 아닌 공격자가 하나의 도구를 우회할 때 다른 도구로 이를 대응하는 것
(각 도구는 최종 방어선이라는 가저하에 구축해야 함)
심층방어는 제로 트러스트와도 부합하며 전통적인 경계 방어 모델은 점차 현실과 멀어지는 상황
심층방어는 3가지 주요 범주로 나뉨
1.관리 컨트롤: 위험 관리 프레임워크
2.물리적 컨트롤: 현실에서의 액세스 보안 및 물리적 침입
3.기술적 컨트롤: h/w, s/w, network 보안 도구 레이어
2.수치로 보는 사이버 위협 트렌드 5가지와 기본 대책
히스콕스 사이버 보안 실태 보고서 2022에서 미국과 유럽 전역의 기업 절반(48%)가 사이버 공격을 당함
(보안 지출을 늘렸음에도 공격 사건이 더 증가)
기업의 보안 관리 비용을 증가시키는 5가지 큰 동향 소개
1.디지털 전환과 원격근무(맥킨지 보고서에 따르면 디지털혁신이 약 7년 가까이 앞당겨졌다고 기술)
2.생태계로 변모: 현대 기업은 회사의 인프라와 자원을 광범위하게 개방(사이버 보안망이 회사의 통제권을 벗어남)
3.하이브리드 위협 환경(사이버 공격이 물리적 세계에도 영향을 미침)
4.새로운 기술, 새로운 위험(사물인터넷, 에지 컴퓨팅 등이 공격 대상으로 변모)
5.다분화되고 난해해지는 규제(정부의 역할이 점점 커지고 있으며 각 국가별 나름의 데이터 보호 또는 개보법 제정 중)
3.마이크로소프트의 오픈소스 SBOM 생성기 살펴보기
MS는 자체 문서 도구를 통해 SPDX 기술을 개발 및 구축 파이프라인 전반에 걸쳐 활용하여 SBOM을 만듬
(누구나 이용이 가능하며 다양한 플랫폼을 지원해야 함)
개발 도구 또는 CI/CD 파이프라인에 연결해 사용
깃허브에서 볼 수 있고 코드의 출처뿐만 아니라 코드 베이스에 적용된 의존성도 확인 가능
(NuGet이나 npm을 이용하다 보면 의존하는 코드에 대한 정보 확인이 어려움) SBOM 도그의 핵심 구성요소 중 하나는 Component Detction이며 단독으로 Visual studio 안에서 실행 가능.
MS SBOM은 CI/CD 파이프라인에 SBOM 도구를 넣고 빌드 과정에서 SBOM을 생성하고 파일을 스캔해 의존성 및 구성요소 확인 가능
결과물은 SPDX JSON 문서로 나옴. 
또한 계층화된 빌드를 지원해 서로 다른 애플리케이션의 구성요소에서 SBOM을 작성
구성요소가 빌드될 때는 의존성 트리와 SBOM이 각각 생성되며 최종 빌드 단계에서 패키지화 되면 SBOM 도구는
따로 생성된 SBOM을 결합해 사용자에게 공유(개별 SBOM은 최종 목록에서 확인 가능)
b는 manifest 파일이 떨어질 경로, bc는 build components 경로, pn은 패키지 이름
pv는 패키지 버전, nsb는 namespace uri base
(해당 컴포넌트는 npm으로 설치된 루비 기반 웹 서버)
Scan Manifest 파일(temp)에서 필요한 항목과 해시 파일만 drop 경로에 저장됨
spdx 파일을 확인해 보면 4개의 주요 섹션이 존재
1.문서 작성 정보: s/w이름, spdx 라이선스, spdx 버전, 작성한 사람, 시간 등 일반 정보
2.파일 섹션: 소프트웨어를 구성하는 파일 목록(해시를 비롯한 속성)
3.패키지 섹션: 빌드할 때 사용되는 패키지 목록(패키지 이름, 버전, 해시 등)
4.관계 섹션: 파일 및 패키지와 같은 SBOM의 다양한 요소 관계 목록
4.커지는 API 보안위협, 대응방안 집중탐구
API 사용량이 늘면서 OWASP에서는 2019년 API top10 발표
1.Broken Object Level Authorization: api가 서로 통신 할 때 객체 수준의 권한 검사가 없으면 데이터 유출 가능성 존재
2.Broken User Authentication: 인증 메커니즘이 잘못 구현되어 인증 토큰을 악용하여 다른 사용자 ID 추정
3.Excessive Data Exposure: 개발자가 데이터 필터링을 클라이언트에게 의존해 각각의 민감도를 고려하지 않아 모든 객체 속성을 노출
4.Lack of Resources & Rate Limiting: 클라이언트가 요청할 수 있는 리소스에 제한을 두지 않아 API 서버에 DDOS 공격 가능성
5.Broken Function Level Authorization: 복잡한 접속 관리 정책으로 관리 기능과 일반 기능이 불분명하게 부여
6.Mass Assignment: 사용자가 보내준 데이터를 그대로 데이터를 만드는데 사용하는 경우
7.Security Misconfiguration: 보안 설정 오류(오류 메세지를 보안 구성으로 적용하는 등)
8.Injection: sql 인젝션과 같은 공격
9.Improper Assets Management: API가 기존 엔드포인트를 더 많이 외부로 노출하는 경우 공격할 수 있는 취약점
10.Insufficient Logging & Monitoring: 불충분한 모니터링
API 보안문제로 4가지로 요약
1.서드 파티 리스크(API는 3자에게 접근을 개방할 수 있으므로 데이터 소유권과 책임이 모호해짐)
2.보안을 고려하지 않은 개발
3.API Gateway, Other Protocol(수많은 API 게이트웨이)
4.취약점
5.로우 코드 플랫폼이 갖추어야 할 조건
90년대 초반 중앙 집중 방식의 메인프레임에서 PC, Window를 활용한 CS 아키텍처로의 전환 시작
당시 코볼이나 유사한 언어를 이용하다가 CS 환경에서는 윈도우 GUI 환경하에서 SDK라는 라이브러리를 이용하여
C언어를 사용했으며 서버와 통시을 위해 SQL Net과 같은 db연결 드라이버를 활용해야 함
(새로운 환경에서의 개발을 의미하며 개발 난이도는 메인 프레임에서의 단순한 비즈니스 로직개발과는 차원이 달라짐)
이 때 등장한 4세대 프로그래밍 언어(4GL) EX.파워빌더, 델파이, 비주얼 베이직 등
이들은 GUI 에디터를 기반으로 각종 객체를 드래그 앤 드롭 방식으로 디자인 할 수 있었고 비즈니스 로직은 자체 스크립트 언어를 통해 구현이 가능해짐
(이는 C,SDK를 이용한 개발과 비교해 엄청나게 낮은 개발 난이도를 제공)
하지만 오늘날 3티어 이상의 아키텍처로 파워빌더와 같은 툴들은 사용하지 않았고 오히려 지금까지 남아있는 파워빌더 기반의 정보시스템은 기업에게 막대한 기술부채를 남겨주는 상황
기사에서는 오늘날 언급되는 로우 코드 개발 플랫폼 또한 파워빌더와 같은 과거 개발도구의 절차를 밟을까봐 우려
Notaion
프레젠테이션 계층: 사용자 인터페이스 지원(ex. browser)
어플리케이션 계층: 비즈니스 로직 계층 또는 트랜잭션 계층(ex. php, java)
데이터 계층: 백엔드 혹은 데이터 계층 (DBMS ex. Mysql,MongoDB)
1Tier architecture: 새로운 물리적인 장비로 변경시 모든 구성 새로 변경
2Tier architecture: 클라이언트 계층과 데이터 계층이 서로 영향 받지 않음
3Tier architecture: 서로 독립적인 운영(합리적인 스케일업, 이중화, 백업 가능하지만 장애 발생 포인트의 증가 및 비용 증가)
3Tier architecture: 개발, 테스트, 라이브 형태로 구성한 3계층으로 실제 서비스 전 테스트 서버(Staging)단계에서 내부 테스트를 거친 후 라이브 서버로 이전하여 서비스 가능
각각의 단계가 서로 백업을 해주는 구성이며 각 기능 테스트를 거치고 업데이트를 하는 버전 관리 구성도 가능