diff --git a/content/ko/guide/finance-oss-guide/0-closed-network/_index.md b/content/ko/guide/finance-oss-guide/0-closed-network/_index.md new file mode 100644 index 0000000000..6e021be8bc --- /dev/null +++ b/content/ko/guide/finance-oss-guide/0-closed-network/_index.md @@ -0,0 +1,304 @@ +--- +title: "폐쇄망 운영과 망분리 전환" +linkTitle: "0. 폐쇄망 운영" +weight: 10 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "망분리", "폐쇄망", "공급망 보안"] +description: > + 금융권 폐쇄망에서 오픈소스를 반입·미러·점검하는 공통 인프라와, 자율보안으로 전환 중인 + 망분리 규제 환경에서 자체 위험평가를 문서화하는 방법을 다룬다. +--- + +{{% alert title="이 페이지의 위치" color="info" %}} +이 가이드는 금융권의 오픈소스 활용·관리를 다룬다. 그 출발점이 폐쇄망이다. +반입·사내 미러·오프라인 취약점 관리는 식별, 사용 승인, 관리 등 모든 단계의 전제가 되므로, +여기에서 한 번 설명하고 각 단계 페이지에서는 "폐쇄망 적용 시" 박스로 이 페이지를 가리킨다. + +여기서 만드는 문서: 반입 절차서와 반입 승인 기록, 망분리 예외 자체 위험평가서. +{{% /alert %}} + +## 왜 폐쇄망을 먼저 다루는가 + +일반적인 오픈소스 실무는 인터넷 연결을 전제한다. 패키지 관리자로 의존성을 내려받고, +온라인 취약점 데이터베이스를 조회하며, 클라우드 기반 스캐너를 쓴다. 금융권의 중요 업무망과 +핵심 시스템에서는 이 전제가 성립하지 않는다. 외부 통신이 차단된 환경에서는 오픈소스를 +들여오는 일 자체가 통제 대상이 되고, 취약점 정보를 어떻게 얻을지가 먼저 풀어야 할 문제가 된다. + +금융분야 오픈소스 소프트웨어 활용·관리 안내서(금융감독원·금융보안원, 2022, 이하 FSEC +안내서)는 관리 절차를 +식별, 이슈 파악 및 해결, 사용 승인, 관리 네 단계로 제시한다. 그러나 폐쇄망에서는 "식별"보다 +앞서 "어떻게 들여올 것인가"라는 관문을 먼저 통과해야 한다. 이 가이드가 폐쇄망을 0번 섹션으로 +끌어올린 이유다. + +{{% alert title="본 가이드의 성격" color="warning" %}} +이 가이드는 FSEC 안내서를 대체하지 않는 보조 자료이고, 권고는 법적 의무가 아니라 모범 +실무다([개요의 성격과 범위](../) 참고). 이 페이지의 폐쇄망 절차는 대부분 표준이 직접 +요구하지 않는 **[본 가이드 권고]**이며, 표준이나 규제가 직접 요구하는 지점만 **[ISO 요구]**, +**[FSEC 안내서]**로 출처를 구분해 표시한다. +{{% /alert %}} + +## 함께 다뤄야 할 두 가지 현실 + +폐쇄망을 "고정된 물리적 망분리"로만 전제하면 가이드가 곧 낡는다. 규제 환경이 전환 중이기 +때문이다. 금융위원회는 금융분야 망분리 개선 로드맵(2024-08-13)을 발표했고, 이어 전자금융감독규정과 +시행세칙 개정이 2025-02-05에 시행됐다. 이 개정으로 오랫동안 유지되던 물리적 망분리 중심 +규제가 자율보안·위험기반 접근으로 바뀌기 시작했다. 고유식별정보와 개인신용정보를 +처리하지 않는 연구·개발 목적 업무는 금융회사가 자체 위험평가와 망분리 대체 정보보호통제 적용, +정보보호위원회 승인을 거쳐 망분리 예외를 적용할 수 있다. 내부 업무망에서 클라우드 기반 +응용소프트웨어(SaaS, Software as a Service)를 쓰는 범위 확대 등 그 밖의 완화는 로드맵의 후속 +단계로 추진 중이다. + +따라서 금융권 담당자는 두 현실을 동시에 안고 일한다. + +첫째, 중요 업무와 핵심 시스템에는 폐쇄망이 그대로 남아 있다. 반입 통제, 사내 미러, 오프라인 +취약점 관리가 여전히 필요하다. + +둘째, 연구·개발 등 예외가 열린 영역에서는 망분리 없이 일할 수 있게 됐다. 다만 규제 완화가 통제 면제를 +뜻하지는 않는다. 망분리에 기대 자동으로 보호받던 부분을, 이제는 스스로 위험을 평가하고 통제를 +설계하고 그 이행을 입증해야 한다. 책임이 규칙 준수에서 자율 입증으로 옮겨 갔다. + +## 반입 통제 + +폐쇄망에서 오픈소스를 들여오는 경로는 외부 구간에서 받아 검증하고 격리한 뒤 망연계 시스템(망간 +자료전송)으로 내부망에 이관하는 흐름이다. + +```mermaid +flowchart LR + subgraph EXT["외부 구간 (인터넷 연결)"] + A["공식 배포처에서 수령"] --> B["무결성 검증
(체크섬 대조)"] + B --> C["SBOM 생성
취약점 사전 점검"] + end + C --> D["반입 묶음 구성
악성코드 검사"] + D --> E["망간 자료전송"] + subgraph INT["내부망"] + F["해시 재확인
결과 검토"] --> G["사내 미러 등록"] + G --> H["반입 승인 기록
(감사 증적)"] + end + E --> F + + style EXT fill:#f7fafc,stroke:#a0aec0 + style INT fill:#f7fafc,stroke:#a0aec0 + style D fill:#744210,color:#fff + style E fill:#2d3748,color:#fff + style H fill:#276749,color:#fff +``` + +반입 절차는 다음을 포함한다. + +- 무결성 검증: 내려받은 산출물의 해시값을 공식 배포처가 게시한 값과 대조한다. +- 악성코드 검사: 반입 구간에서 백신·악성코드 검사를 거친다. +- 구성요소 식별: 들여오는 산출물의 구성요소를 SBOM(Software Bill of Materials)으로 기록한다. + 이 SBOM은 ISO/IEC 5230의 SBOM 관리(§3.3.1)가 요구하는 입증자료가 된다. **[ISO 요구]** +- 반입 승인 기록: 누가 무엇을 왜 반입했는지, 검증 결과와 함께 남긴다. 이 기록은 감사 증적이 된다. + +### 반입 절차 예제 + +한 라이브러리를 외부 구간에서 받아 내부망으로 옮기는 과정을 예로 든다. 도구 이름은 예시이며, +조직이 이미 쓰는 동급 도구로 바꿔도 된다. + +외부 구간(인터넷 연결 가능 구역)에서 산출물을 받고 무결성을 확인한다. + +```bash +# 1) 공식 배포처에서 산출물과 서명·체크섬을 함께 받는다 +curl -LO https://example.org/lib/foo-1.2.3.tar.gz +curl -LO https://example.org/lib/foo-1.2.3.tar.gz.sha256 + +# 2) 게시된 해시와 대조해 무결성을 검증한다 +sha256sum -c foo-1.2.3.tar.gz.sha256 + +# 3) 반입 단위의 구성요소를 SBOM으로 기록한다 (CycloneDX 형식) +syft foo-1.2.3.tar.gz -o cyclonedx-json > foo-1.2.3.sbom.json + +# 4) 외부 구간에서 취약점을 미리 점검해 결과를 함께 반입 대상에 포함한다 +grype sbom:foo-1.2.3.sbom.json -o json > foo-1.2.3.vuln.json +``` + +이 단계의 SBOM은 반입하는 산출물 자체를 식별하는 기록이다. 단일 소스 묶음에는 그 라이브러리가 +의존하는 다른 컴포넌트가 동봉되지 않으므로, 전이 의존성은 이 명령으로 펼쳐지지 않는다. 전이 +의존성은 각각 별도의 반입 단위로 들어와 사내 미러에 등록되고, 프로젝트 전체의 의존성은 빌드 +시점에 프로젝트를 대상으로 SBOM을 생성해 식별한다(2번 섹션). + +산출물, SBOM, 취약점 점검 결과, 체크섬을 하나의 반입 묶음으로 만들어 악성코드 검사를 거친 뒤 +망간 자료전송으로 내부망에 옮긴다. 내부망에서는 해시를 다시 확인하고, SBOM과 취약점 결과를 +검토한 뒤 사내 미러 저장소에 등록한다. 이때 반입 승인 기록을 함께 남긴다. + +{{% alert title="신설 조직이 먼저 할 일과 운영 조직의 고도화" color="success" %}} +처음 체계를 세우는 조직은 반입 경로를 하나로 단일화하고, 반입 묶음에 무엇을 포함할지(산출물, +해시, SBOM, 취약점 결과, 승인 기록)를 표준 양식으로 정하는 일부터 시작한다. + +이미 운영 중인 조직은 반입 절차를 자동화하고, 사전 승인된 컴포넌트만 미러를 통해 공급되도록 +강제하며, 반입 기록을 감사 증적 체계와 연동한다. +{{% /alert %}} + +## 사내 미러 저장소 + +폐쇄망 내부에 오픈소스를 공급하는 사내 미러 저장소를 둔다. Nexus, Artifactory 등 저장소 +관리 도구를 온프레미스로 운영하거나, 언어별 패키지 저장소를 내부에 미러링한다. 개발자는 +인터넷이 아니라 이 사내 미러에서만 의존성을 받는다. + +미러는 오픈소스를 보관하는 저장소이면서, 무엇을 어떤 버전으로 쓸지 통제하는 지점이다. + +- 반입 단계에서 만든 SBOM을 미러에 함께 등록해, 어떤 버전이 들어와 있는지 고정한다. +- 전이 의존성(직접 선언하지 않았지만 따라 들어오는 하위 의존성)까지 포함해 식별한다. +- 사전 승인되지 않은 컴포넌트는 미러에 올리지 않아, 승인 절차를 우회한 사용을 막는다. + +사내 미러가 있으면 개발자가 무엇을 쓰는지 한곳에서 파악되고, 식별(2번 섹션)과 사용 승인(4번 +섹션)의 기반이 된다. + +## 오프라인 취약점 관리 + +폐쇄망에서는 실시간 취약점 정보를 받을 수 없다. 신규 취약점(CVE, Common Vulnerabilities and +Exposures)을 인지하는 시점이 늦어지는 구조적 한계가 있으므로, 취약점 데이터를 정기적으로 +들여오는 절차를 따로 마련한다. + +접근 방식은 두 가지다. + +- 외부망에서 스캔한 결과만 반입한다. 인터넷 연결이 가능한 구역에서 SBOM을 대상으로 취약점을 + 점검하고, 그 결과 보고서를 내부망으로 옮긴다. +- 오프라인 취약점 데이터베이스를 정기적으로 동기화한다. 취약점 점검 도구가 참조하는 데이터베이스를 + 외부에서 내려받아 내부 미러에 반입하고, 내부 도구가 그 미러를 바라보게 한다. + +Grype와 Trivy는 취약점 데이터베이스를 캐시 디렉터리 단위로 받아 옮기는 방식으로, 물리적으로 +분리된 폐쇄망(air-gap) 환경의 오프라인 갱신을 지원한다. Dependency-Track은 참조하는 취약점 +데이터 소스(국가 취약점 데이터베이스, OSV, GitHub Advisories 등)의 주소를 설정으로 바꿔 내부 +미러를 바라보게 할 수 있는데, 데이터 소스별로 미러를 따로 구성해야 해서 난도가 높다. 도입 +전에 소규모 구성 검증을 거치기를 권한다. 도구가 오프라인 갱신을 지원하는지가 폐쇄망 취약점 +관리의 핵심이다. + +### 오프라인 취약점 데이터베이스 반입 예제 + +취약점 데이터베이스만 외부에서 받아 내부로 옮기는 흐름을 예로 든다. + +외부 구간에서 데이터베이스를 내려받는다. + +```bash +# 외부 구간: 취약점 DB 아카이브를 내려받는다 (도구별 명령은 예시) +grype db update # 최신 취약점 DB를 로컬 캐시에 받는다 +grype db status # 받은 DB의 버전·생성 시각을 확인한다 + +# 받은 DB 캐시 디렉터리를 아카이브로 묶어 반입 대상으로 만든다 +tar czf grype-db-$(date +%Y%m%d).tar.gz -C ~/.cache/grype/db . +``` + +아카이브의 해시를 확인하고 악성코드 검사를 거쳐 내부망으로 옮긴 뒤, 내부 점검 도구가 이 +데이터베이스를 참조하도록 설정한다. + +```bash +# 내부망: 반입한 DB 아카이브를 점검 도구가 참조하는 위치에 풀어 둔다 +tar xzf grype-db-YYYYMMDD.tar.gz -C /opt/grype/db + +# 오프라인 모드로 점검한다 (반입한 DB의 위치를 지정하고, 네트워크 갱신을 끈다) +GRYPE_DB_CACHE_DIR=/opt/grype/db GRYPE_DB_AUTO_UPDATE=false grype sbom:foo-1.2.3.sbom.json +``` + +Trivy는 데이터베이스를 받는 명령이 다를 뿐 흐름은 같다. 외부 구간에서 캐시를 받아 묶고, +내부에서 풀어 캐시 위치를 지정해 점검한다. + +```bash +# 외부 구간: Trivy 취약점 DB를 로컬 캐시에 받아 아카이브로 묶는다 +trivy image --download-db-only +tar czf trivy-db-$(date +%Y%m%d).tar.gz -C ~/.cache/trivy . + +# 내부망: 캐시를 풀고, 갱신 없이 반입한 DB로 점검한다 +tar xzf trivy-db-YYYYMMDD.tar.gz -C /opt/trivy +trivy sbom foo-1.2.3.sbom.json --skip-db-update --cache-dir /opt/trivy +``` + +자바 프로젝트를 점검하려면 별도의 자바 인덱스 데이터베이스가 필요하므로, 외부 구간에서 +`trivy image --download-java-db-only`로 함께 받아 같은 캐시에 포함한다. + +데이터베이스 동기화 주기와 책임자를 정하고, 동기화가 늦어지는 동안 발생할 수 있는 인지 지연을 +관리한다. Dependency-Track에 운영 시스템의 SBOM을 등록해 두면, 데이터베이스를 갱신할 때마다 +이미 운영 중인 시스템에 영향을 주는 신규 취약점을 자동으로 다시 평가한다. 지속 모니터링은 5번 +섹션에서 자세히 다룬다. + +## 폐쇄망에 맞는 도구 선택 + +폐쇄망에서는 클라우드 기반 스캐너를 쓸 수 없으므로 온프레미스로 설치하는 도구를 쓴다. 도구 +자체가 오픈소스라면 그 도구도 반입 대상이 된다. + +이 가이드가 도구 페이지에서 다루는 도구는 대부분 오픈소스이고 온프레미스 설치가 가능하다. +SBOM 생성에는 Syft, cdxgen, OSV-SCALIBR을, 라이선스 점검에는 FOSSology, SCANOSS를, 취약점 +점검과 지속 감시에는 Dependency-Track, Grype, Trivy를 쓸 수 있다. 자세한 설치와 사용법은 +[도구 페이지](../../tools/)를 참고한다. + +특정 제품을 단독으로 권하지는 않는다. 폐쇄망에서 도구를 고를 때는 다음 기준으로 본다. + +- 온프레미스 설치형으로 제공되는가. +- 취약점 데이터베이스를 오프라인으로 갱신할 수 있는가. +- SBOM 표준 형식(SPDX, CycloneDX)을 입출력하는가. +- 도구 자체의 라이선스가 사내 운영에 문제를 일으키지 않는가. + +마지막 기준은 실제로 걸린다. 예를 들어 FOSSLight는 AGPL-3.0이다. 도구를 개조한 버전을 +네트워크로 기능을 제공하는 방식으로 쓰면 소스 공개 의무가 생길 수 있으므로 법무 검토 항목으로 둔다. + +{{% alert title="상용 도구 검토" color="info" %}} +금융권은 지원 약정(SLA, Service Level Agreement), 한글 지원, 책임 소재 때문에 상용 소프트웨어 +구성 분석(SCA, Software Composition Analysis) 도구를 함께 검토하는 경우가 많다. 이 가이드는 +특정 상용 제품을 추천하지 않고, 위 선택 기준에 더해 폐쇄망 설치 제공 여부, 오프라인 데이터베이스 +갱신, 국내 지원, 표준 출력 지원을 함께 따지도록 안내한다. 오픈소스 스택을 기본 권장안으로 두고, +상용 도구는 조직의 요구에 따라 보완하는 선택지로 본다. +{{% /alert %}} + +## 패치 지연 관리 + +폐쇄망에서는 취약점 패치도 반입 절차를 다시 거쳐야 하므로 즉시 대응이 어렵다. 신규 취약점이 +공개돼도 패치를 받아 검증하고 내부로 옮기는 데 시간이 걸린다. 이 지연을 관리하는 장치를 둔다. + +- 사전 승인된 미러로만 패치를 수급해, 출처가 불분명한 긴급 패치의 직접 반입을 막는다. +- 패치를 적용하기 전까지의 임시 완화책(영향 받는 기능 차단, 접근 제한 등)을 절차에 포함한다. +- 취약점의 심각도와 노출 정도에 따라 대응 기한을 정해, 지연이 방치되지 않게 한다. + +## 망분리 예외 시 자체 위험평가 + +연구·개발 목적 업무에서 망분리 예외를 적용하면 폐쇄망의 자동 보호가 사라진다. 이때 +오픈소스에 대한 위험을 스스로 평가하고 통제를 설계해 문서로 남겨야 한다. + +자체 위험평가 문서에는 다음을 담는다. + +- 대상 업무가 연구·개발 목적에 해당하며 고유식별정보와 개인신용정보를 처리하지 않는다는 판단 근거. +- 망분리 예외 구간에서 쓰는 오픈소스의 목록(SBOM)과 그 취약점·라이선스 위험. +- 금융감독원장이 정하는 망분리 대체 정보보호통제의 적용 내역. +- 인터넷 연결이 열린 만큼 추가되는 위험과 그에 대응하는 보안 통제(반입 검증을 대신할 통제). +- 통제의 이행을 확인하는 방법과 재평가 주기. + +망분리 예외의 승인은 오픈소스 조직이 아니라 전사 보안 거버넌스의 소관이다. 이 문서는 +정보보호위원회(또는 정보보호최고책임자, CISO)의 승인을 받는다. 승인된 평가서는 오픈소스 +사용 승인 단계(4번 섹션)의 근거 자료가 되고, 정기 재평가(5번 섹션)의 대상이 된다. +양식은 산출물로 제공하는 [망분리 예외 자체 위험평가서 +템플릿](../artifacts/2-policy-templates/#망분리-예외-자체-위험평가서)을 참고한다. + +{{% alert title="제3자·외주 적용 시" color="info" %}} +전자금융보조업자나 외주 개발사가 폐쇄망 안에서 작업하거나 그들이 만든 산출물을 반입할 때도 +같은 반입 통제가 적용된다. 외주 산출물에 SBOM과 취약점 점검 결과를 요구하는 방법은 식별(2번 +섹션)과 사용 승인(4번 섹션)에서 다룬다. +{{% /alert %}} + +## FSEC 안내서·ISO 표준과의 연결 + +폐쇄망 운영은 안내서의 식별·관리 단계에 앞서는 전제 조건이면서, 동시에 두 단계의 품질을 +좌우한다. 이 페이지의 폐쇄망 절차가 표준 입증자료·안내서 절차·규제와 어떻게 이어지는지는 +다음과 같다. + +| 폐쇄망 절차 | 연결되는 표준·규제 | 안내서 절차 | +|------|------|------| +| 반입 단계 SBOM 생성 | ISO/IEC 5230 §3.3.1 SBOM 관리 | 식별 | +| 사내 미러 구성요소 고정 | ISO/IEC 5230 §3.3.1 컴포넌트 기록 | 식별 | +| 오프라인 취약점 관리 | ISO/IEC 18974 취약점 탐지·해결 | 이슈 파악 및 해결 | +| 패치 지연 관리 | ISO/IEC 18974 취약점 조치 | 이슈 파악 및 해결 / 관리 | +| 망분리 예외 자체 위험평가 | 전자금융감독규정 자율보안(2025-02-05) | 사용 승인 | + +표준별 입증자료와 안내서 절차의 전체 대조는 [가이드 개요의 매핑표](../)에서 확인한다. + +{{% alert title="현장 사례 — 카카오뱅크의 컴플라이언스 자동화" color="success" %}} +카카오뱅크는 KWG 12차 정기 미팅(2021-12)에서 컴플라이언스 검사를 개발 단계로 앞당기는 +자동화 사례를 공유했다. 웹 서비스로만 제공되는 검사 도구는 금융권 보안 요건상 사내망에서 +쓰기 어려워, 명령줄 도구로 대응하는 방향을 제시했다. 폐쇄망의 도구 제약을 보여 주는 사례다. + +출처: 하헌관(카카오뱅크), "Shift-left and Automate Compliance Checks", [KWG 12차 미팅(2021-12) 발표자료](https://github.com/OpenChain-Project/OpenChain-KWG/releases/download/meeting-slides-2021/Shift-Left_and_Automate_Compliance_Checks.pdf). +{{% /alert %}} + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/1-governance/_index.md b/content/ko/guide/finance-oss-guide/1-governance/_index.md new file mode 100644 index 0000000000..265648fe52 --- /dev/null +++ b/content/ko/guide/finance-oss-guide/1-governance/_index.md @@ -0,0 +1,118 @@ +--- +title: "거버넌스: 관리 조직과 승인 체계" +linkTitle: "1. 거버넌스" +weight: 20 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "거버넌스", "OSPO", "OSRB"] +description: > + 금융권 오픈소스 관리 조직(OSPO)과 검토 위원회(OSRB)를 어떻게 구성하고 역할을 나누며, + 법무·보안·기술이 함께 참여하는 승인 거버넌스를 어떻게 세우는지 다룬다. +--- + +{{% alert title="이 페이지의 위치" color="info" %}} +거버넌스는 오픈소스 관리의 기반이다. 누가 책임지고, 누가 검토하며, 누가 승인하는지를 먼저 +정해야 식별, 사용 승인, 관리 단계가 작동한다. FSEC 안내서도 관리 절차에 앞서 관리 조직 +구성과 역할을 별도로 다룬다. + +여기서 만드는 문서: 오픈소스 정책, 역할·책임 목록과 담당자 지정 기록. +{{% /alert %}} + +## 금융권 거버넌스의 출발점 + +금융분야 오픈소스 소프트웨어 활용·관리 안내서(금융감독원·금융보안원, 2022, 이하 FSEC +안내서)는 관리 조직의 구성과 +운영, 역할 사례를 제시한다. ISO/IEC 5230은 이를 입증자료로 요구한다. 문서화된 정책(3.1.1.1), +역할과 책임 목록(3.1.2.1), 역할 담당자 명시(3.2.2.1), 법률 자문 접근 방법(3.2.2.3)이 그것이다. +거버넌스는 이 입증자료들을 만들어 내는 활동이다. + +금융권은 여기에 두 가지 조건이 더 붙는다. 첫째, 법무·보안·기술이 분리된 큰 조직 구조에서 +오픈소스 결정을 누가 내리는지가 분명해야 한다. 둘째, 감독 검사와 내외부감사에 대비해 결정의 +근거와 책임 소재를 기록으로 남겨야 한다. + +## 오픈소스 프로그램 조직(OSPO) + +오픈소스 프로그램 조직(OSPO, Open Source Program Office)은 오픈소스 활용과 관리를 총괄하는 +조직이다. 전담 부서를 두는 큰 회사도 있고, 기존 보안·개발 조직에 역할을 겸하게 하는 회사도 +있다. 규모가 어떻든 책임과 권한은 한곳에 모여야 한다. **[FSEC 안내서]** + +OSPO가 맡는 역할은 다음과 같다. + +- 오픈소스 정책을 수립하고 갱신한다. +- 오픈소스 사용 승인 절차를 운영하고 검토 위원회를 소집한다. +- 식별·취약점·라이선스 관리에 쓰는 도구와 절차를 책임진다. +- 감사와 감독 검사에 필요한 증적을 관리한다. +- 법무·보안·개발 부서 사이의 협의를 조정한다. + +역할을 정하면 담당자의 이름과 연락처, 지정일을 문서로 남긴다. 이것이 ISO/IEC 5230의 역할 +담당자 명시(3.2.2.1)와 ISO/IEC 18974의 참여자 목록·역할 매핑(4.1.2.3) 입증자료가 된다. +**[ISO 요구]** + +{{% alert title="신설 조직이 먼저 할 일과 운영 조직의 고도화" color="success" %}} +처음 체계를 세우는 조직은 전담 부서를 갖추기 어렵다. 먼저 오픈소스 관리의 단일 책임자를 +지정하고, 법무·보안·개발에서 한 명씩 겸임으로 참여하는 최소 구성으로 시작한다. 역할과 +담당자를 문서로 남기는 것만으로도 ISO 입증자료 요건을 충족한다. + +이미 운영 중인 조직은 역할별 필요 역량을 정의하고, 정기적으로 조직 구성과 역할을 검토해 +변경 이력을 남기며, 성과 지표로 프로그램의 효과를 측정한다. +{{% /alert %}} + +## 오픈소스 검토 위원회(OSRB) + +오픈소스 검토 위원회(OSRB, Open Source Review Board)는 오픈소스 도입과 사용을 검토하고 +승인하는 협의 기구다. 금융권에서 특히 중요한 이유는, 오픈소스 도입 결정에 라이선스 위험, +보안 취약점, 운영 영향이 함께 걸려 있어 한 부서가 단독으로 판단하기 어렵기 때문이다. + +위원회는 보통 다음 관점을 함께 본다. + +- 법무: 라이선스 의무와 계약·지식재산권 위험. +- 보안: 취약점, 공급망 위험, 유지보수 상태. +- 기술·개발: 기술 적합성, 대체 가능성, 운영 부담. + +위원회의 결정과 그 근거를 기록으로 남긴다. 이 기록은 사용 승인 단계(4번 섹션)의 핵심 증적이며, +감사 대응(5번 섹션)에서 다시 쓰인다. 위원회를 매번 소집하기 어렵다면 위험 수준별로 검토를 +차등한다. 구체적 방법은 [사용 승인](../4-approve/)에서 다룬다. **[본 가이드 권고]** + +## 법률 자문과 예산 + +ISO/IEC 5230은 법률 자문에 접근하는 방법(3.2.2.3)과 인원 배치 및 예산 확인(3.2.2.2)을 입증자료로 +요구한다. 금융권은 사내 법무 조직이 있는 경우가 많으므로, 오픈소스 라이선스 사안을 어느 +경로로 법무에 올리는지를 정해 문서로 남긴다. 외부 전문 자문이 필요한 사안의 판단 기준도 +함께 정한다. **[ISO 요구]** + +예산은 도구 구축과 운영, 교육, 외부 자문에 든다. 신설 조직은 오픈소스 도구가 대부분 +오픈소스이고 온프레미스로 설치 가능하다는 점을 활용해 초기 비용을 낮출 수 있다. 도구 +선택은 [폐쇄망 운영](../0-closed-network/#폐쇄망에-맞는-도구-선택)과 [관리](../5-manage/)에서 다룬다. + +{{% alert title="제3자·외주 적용 시" color="info" %}} +전자금융보조업자나 외주 개발사가 만든 산출물에 포함된 오픈소스도 거버넌스의 대상이다. +위원회는 외주 계약에 오픈소스 관리 요구사항(SBOM(Software Bill of Materials) 제출, 라이선스 +고지, 취약점 대응)을 넣을지 +판단하고, 그 책임을 누가 지는지 정한다. 계약과 제안요청서 관리는 [사용 승인](../4-approve/)에서 +구체적으로 다룬다. +{{% /alert %}} + +## FSEC 안내서·ISO 표준과의 연결 + +| 거버넌스 활동 | ISO/IEC 5230 | ISO/IEC 18974 | FSEC 안내서 | +|------|------|------|------| +| 정책 수립·전파 | 3.1.1.1 정책, 3.1.1.2 전파 절차 | — | 거버넌스 | +| 역할·책임 정의 | 3.1.2.1 역할·책임 목록 | 4.1.2.3 참여자·역할 매핑 | 거버넌스 | +| 담당자 명시 | 3.2.2.1 담당자 문서 | — | 거버넌스 | +| 법률 자문 접근 | 3.2.2.3 법률 자문 방법 | — | 거버넌스 | +| 예산·인원 배치 | 3.2.2.2 인원·예산 확인 | — | 기타 | +| 미준수 검토·수정 | 3.2.2.5 미준수 검토 절차 | — | 기타 | + +조직과 역할의 일반 실무는 기존 [기업 오픈소스 관리 가이드의 조직 섹션](../../opensource_for_enterprise/1-teams/)에서 +더 자세히 다룬다. 이 페이지는 그 위에 금융권의 검토 위원회와 감사 대비 기록을 더한 것이다. + +{{% alert title="현장 사례 — 카카오뱅크의 ISO/IEC 5230 인증" color="success" %}} +카카오뱅크는 KWG 13차 정기 미팅(2022-03)에서 ISO/IEC 5230 인증 사례를 공유했다. 금융권 +규제 환경에서 오픈소스 관리 체계를 세우고 인증까지 이른 거버넌스 구축 사례다. + +출처: 하헌관·이민애(카카오뱅크), 13차 공동 세션 "카카오와 카카오뱅크의 ISO/IEC 5230 인증 사례 공유" 중 카카오뱅크 발표분, [KWG 13차 미팅(2022-03) 발표자료](https://github.com/OpenChain-Project/OpenChain-KWG/releases/download/meeting-slides-2022/KakaoBank_ISO_IEC_5230_certification_case.pdf). +{{% /alert %}} + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/2-identify/_index.md b/content/ko/guide/finance-oss-guide/2-identify/_index.md new file mode 100644 index 0000000000..0bc5d5b566 --- /dev/null +++ b/content/ko/guide/finance-oss-guide/2-identify/_index.md @@ -0,0 +1,123 @@ +--- +title: "식별: 쓰고 있는 오픈소스를 빠짐없이 찾기" +linkTitle: "2. 식별" +weight: 30 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "SBOM", "식별", "공급망"] +description: > + 신규로 들어오는 오픈소스와 이미 운영 중인 레거시, 외주 산출물까지 빠짐없이 식별하고 + SBOM으로 기록하는 방법, 그리고 금융권 공급망 보안 플랫폼과의 연계를 다룬다. +--- + +{{% alert title="이 페이지의 위치" color="info" %}} +식별은 관리의 출발점이다. 무엇을 쓰는지 모르면 취약점도 라이선스 의무도 관리할 수 없다. +FSEC 안내서의 첫 절차이고, ISO/IEC 5230의 SBOM 관리(3.3.1)가 요구하는 활동이다. + +여기서 만드는 문서: SBOM, 운영 자산 인벤토리. +{{% /alert %}} + +## 무엇을 식별하는가 + +오픈소스를 식별한다는 것은 세 종류를 모두 찾아낸다는 뜻이다. + +- 신규로 들여오는 오픈소스. 개발자가 새로 도입하는 라이브러리와 그 의존성. +- 이미 운영 중인 시스템에 들어 있는 오픈소스. 도입 시점에 기록하지 못한 레거시. +- 외주 개발사나 전자금융보조업자가 만든 산출물에 포함된 오픈소스. 외주 개발사(업무를 위탁받은 + 수탁자)와 전자금융보조업자(전자금융거래법상 금융회사를 위해 전자금융거래를 보조하는 자)는 + 법적으로 다른 범주지만, 산출물의 오픈소스를 식별해야 한다는 점은 같다. + +직접 선언한 의존성만이 아니라 그것이 끌어오는 전이 의존성까지 펼쳐야 한다. 실제 위험은 +대부분 직접 보지 않는 하위 의존성에 숨어 있다. + +금융권에서는 여기에 규제 근거가 붙는다. 2025-02-05 개정 전의 전자금융감독규정 제21조는 +정보처리시스템 구축과 전자금융거래 계약에서 제품의 소유권, 저작권, 지식재산권 귀속을 명확히 +하도록 명시했고, FSEC 안내서도 이를 근거로 안내한다. 개정된 현행 제21조는 이를 포함한 계약 +관련 내부통제 절차의 수립과 운용을 요구한다. 오픈소스의 출처와 라이선스를 식별하는 일은 이 +요구를 충족하는 첫걸음이다. **[FSEC 안내서]** + +## SBOM 작성과 기록 + +식별 결과는 SBOM(Software Bill of Materials)으로 기록한다. SBOM은 소프트웨어를 구성하는 모든 +오픈소스 컴포넌트와 그 버전, 라이선스, 의존 관계를 담은 목록이다. 표준 형식으로는 SPDX와 +CycloneDX가 널리 쓰인다. **[ISO 요구]** + +SBOM 작성에는 [Syft](../../tools/6-syft/), [cdxgen](../../tools/5-cdxgen/), +[OSV-SCALIBR](../../tools/4-osvscalibr/) 같은 오픈소스 도구를 쓸 수 있다. 모두 온프레미스로 +설치 가능하고 표준 형식으로 출력한다. 도구 전체 목록은 [도구 페이지](../../tools/)에서 다룬다. SBOM을 만들고 관리하는 절차는 ISO/IEC 5230의 SBOM 관리(3.3.1.1)와 컴포넌트 기록(3.3.1.2) +입증자료가 된다. + +{{% alert title="폐쇄망 적용 시" color="info" %}} +폐쇄망에서는 오픈소스를 반입하는 단계에서 SBOM을 만들어 사내 미러에 함께 등록한다. 이렇게 +하면 무엇이 어떤 버전으로 들어와 있는지 한곳에서 파악된다. 반입 절차와 사내 미러 구성은 +[폐쇄망 운영](../0-closed-network/#반입-통제)에서 다룬다. +{{% /alert %}} + +## 운영 중인 시스템의 식별 + +신규 도입만 관리하면 절반만 보는 것이다. 이미 가동 중인 사내 시스템과 서버에도 오래전 도입한 +오픈소스가 들어 있고, 그중 상당수는 도입 기록이 없다. 이 레거시를 SBOM으로 식별하는 일이 +금융권에서 특히 중요하다. 운영 시스템의 취약점은 상시적 위험이기 때문이다. + +운영 중인 시스템의 식별은 한 번으로 끝나지 않는다. 자산 인벤토리를 만들어 어떤 시스템에 어떤 +오픈소스가 들어 있는지 지속적으로 갱신한다. 이 인벤토리는 지속 모니터링([관리](../5-manage/))의 +기반이 된다. **[본 가이드 권고]** + +## 제3자와 외주 산출물 식별 + +FSEC 안내서는 전자금융보조업자가 사용하는 오픈소스의 식별을 점검 항목으로 둔다. 금융권은 +외주 개발과 위탁이 많아, 내가 직접 도입하지 않은 오픈소스가 외주 산출물을 통해 들어온다. +이를 식별하지 못하면 관리 범위에 구멍이 생긴다. **[FSEC 안내서]** + +방법은 외주 산출물에 SBOM 제출을 요구하는 것이다. 계약 단계에서 SBOM 제공을 의무로 넣고, +받은 SBOM을 검증한다. 계약과 제안요청서에 넣을 구체적 요구사항은 [사용 승인](../4-approve/)에서 +다룬다. + +{{% alert title="제3자·외주 적용 시" color="info" %}} +외주사가 제출한 SBOM은 그대로 믿지 말고 검증한다. 받은 SBOM이 실제 산출물과 일치하는지, +누락된 컴포넌트는 없는지 점검 도구로 다시 확인한다. 외주사가 SBOM을 만들 역량이 없다면, +산출물을 직접 스캔해 SBOM을 생성하는 방법을 병행한다. +{{% /alert %}} + +## 공급망 보안 플랫폼과의 연계 + +금융보안원의 금융권 소프트웨어 공급망 보안 플랫폼이 2026년부터 본격 운영된다(개요는 +[가이드 개요](../) 참고). 금융사는 이 플랫폼에 참여하기 위해 SBOM을 산출하고 제출하는 +형식을 미리 갖춰 두는 것이 좋다. + +해외에서는 미국과 유럽이 SBOM 제출 의무화를 진행 중이고, 국내 정부도 SW 공급망 보안 +가이드라인 1.0(2024-05-13)을 통해 단계적 제도화 방향을 밝혔다. 정부는 2027년 공공부문 SBOM +제출 의무화를 목표로 추진하고 있어, 그 흐름이 금융권으로 확산될 전망이다. 현재 국내 금융권에 +SBOM 제출이 일률적으로 의무화된 것은 아니지만, 이 흐름에 선제적으로 대비하는 것이 합리적이다. +**[본 가이드 권고]** + +{{% alert title="신설 조직이 먼저 할 일과 운영 조직의 고도화" color="success" %}} +처음 체계를 세우는 조직은 새로 도입하는 오픈소스부터 SBOM을 만들어 기록하기 시작하고, +표준 형식(SPDX 또는 CycloneDX) 하나를 정해 일관되게 쓴다. + +이미 운영 중인 조직은 레거시 시스템까지 자산 인벤토리로 식별 범위를 넓히고, 외주 산출물에 +SBOM 제출을 요구하며, 공급망 보안 플랫폼 제출 형식에 맞춰 SBOM 산출을 자동화한다. +{{% /alert %}} + +## FSEC 안내서·ISO 표준과의 연결 + +| 식별 활동 | ISO/IEC 5230 | FSEC 안내서 | +|------|------|------| +| 적용 범위 정의 | 3.1.4.1 프로그램 적용 범위 | 식별 | +| SBOM 작성·관리 | 3.3.1.1 SBOM 관리 절차 | 식별 | +| 컴포넌트 기록 | 3.3.1.2 오픈소스 컴포넌트 기록 | 식별 | +| 제3자·외주 식별 | 3.3.1.1 준용 | 식별(전자금융보조업자) | + +SBOM 작성의 일반 실무와 도구 활용은 기존 [기업 오픈소스 관리 가이드의 도구 섹션](../../opensource_for_enterprise/4-tool/)과 +[ISO/IEC 5230 준수 가이드의 SBOM 조항](../../iso5230_guide/3-content-review/1-sbom/)에서 더 자세히 다룬다. + +{{% alert title="현장 사례 — 금융결제원의 ISO/IEC 5230 준수" color="success" %}} +금융결제원은 KWG 25차 정기 미팅(2025-03)에서 결제 인프라를 대상으로 ISO/IEC 5230:2020을 +준수한 사례를 공유했다. 금융 결제 시스템의 오픈소스를 식별하고 관리 체계를 적용한 사례다. + +출처: 유대열(금융결제원), "금융결제원의 ISO/IEC 5230:2020 준수 사례", [KWG 25차 미팅(2025-03) 발표자료](https://github.com/OpenChain-Project/OpenChain-KWG/releases/download/meeting-slides-legacy/20250325_KFTC_OpenChain-KWG_25th_ko.pdf). +{{% /alert %}} + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/3-issue-resolve/_index.md b/content/ko/guide/finance-oss-guide/3-issue-resolve/_index.md new file mode 100644 index 0000000000..ce161730c1 --- /dev/null +++ b/content/ko/guide/finance-oss-guide/3-issue-resolve/_index.md @@ -0,0 +1,161 @@ +--- +title: "이슈 파악과 해결: 취약점과 라이선스" +linkTitle: "3. 이슈 파악·해결" +weight: 40 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "취약점", "CVE", "라이선스"] +description: > + 식별한 오픈소스의 취약점을 탐지·평가·조치하고 그 기록을 남기는 절차, 라이선스 이슈를 + 해결하는 방법, 폐쇄망의 패치 지연을 관리하는 방법을 다룬다. +--- + +{{% alert title="이 페이지의 위치" color="info" %}} +식별로 무엇을 쓰는지 파악했다면, 그다음은 거기서 나오는 이슈를 풀어야 한다. 이슈는 두 +종류다. 보안 취약점과 라이선스 의무다. FSEC 안내서의 두 번째 절차이고, ISO/IEC 18974의 +취약점 탐지·해결(4.3.2)과 ISO/IEC 5230의 라이선스 사용 사례 처리(3.3.2)에 대응한다. + +여기서 만드는 문서: 취약점 조치 기록(VEX 포함), 심각도별 대응 기한 기준. +{{% /alert %}} + +## 취약점 탐지에서 조치까지 + +ISO/IEC 18974는 SBOM(Software Bill of Materials)에 담긴 각 오픈소스 컴포넌트에 보안 보증 +활동을 적용하도록 요구한다. 탐지부터 해결까지의 전 과정을 절차로 만들고, 각 취약점에 대한 +수행 기록을 남겨야 한다. 절차는 다음 흐름을 따른다. **[ISO 요구]** + +- 탐지: SBOM의 각 컴포넌트에 알려진 취약점(CVE, Common Vulnerabilities and Exposures)이 + 있는지 점검한다. +- 평가: 탐지된 취약점에 위험·영향 점수를 매긴다. 공통 취약점 등급 체계(CVSS, Common + Vulnerability Scoring System)를 쓴다. +- 조치 결정: 각 취약점에 필요한 수정 또는 완화 단계를 정하고 문서로 남긴다. 조치가 필요 + 없다고 판단한 경우 그 판단 근거도 기록한다. +- 조치 수행: 위험 점수에 따라 패치, 버전 교체, 완화 설정 등을 수행한다. +- 지속 대응: 운영 중 새로 공개되는 취약점을 모니터링하고 영향받는 시스템에 대응한다. + +```mermaid +flowchart LR + A["탐지
(SBOM 대조)"] --> B["평가
(CVSS 점수)"] + B --> C{"조치가
필요한가?"} + C -- 예 --> D["조치 수행
패치·교체·완화"] + C -- 아니오 --> E["불필요 판단 근거 기록
(VEX)"] + D --> F["조치 기록"] + E --> G["지속 대응
(신규 취약점 모니터링)"] + F --> G + G --> A + + style A fill:#2b6cb0,color:#fff + style D fill:#c53030,color:#fff + style E fill:#744210,color:#fff + style F fill:#276749,color:#fff + style G fill:#2d3748,color:#fff +``` + +이 절차가 ISO/IEC 18974의 취약점 탐지·해결 절차(4.3.2.1)이고, 그 수행 기록이 취약점·조치 +기록(4.3.2.2)이다. 조치가 필요 없다고 판단한 결과를 VEX(Vulnerability Exploitability +eXchange) 형식으로 남기면, 같은 취약점을 반복 검토하지 않아도 된다. + +### 취약점 점검과 지속 감시 예제 + +SBOM을 취약점 관리 도구에 등록하면, 도구가 새로운 취약점이 공개될 때마다 영향받는 컴포넌트를 +다시 알려 준다. Dependency-Track에 운영 시스템의 SBOM을 등록하는 방식을 예로 든다. 도구는 +예시이며 동급 도구로 바꿔도 된다. + +```bash +# SBOM을 Dependency-Track 프로젝트에 업로드한다 (API 예시) +curl -X POST "https://dtrack.internal/api/v1/bom" \ + -H "X-Api-Key: $DT_APIKEY" \ + -F "project=$PROJECT_UUID" \ + -F "bom=@foo-1.2.3.sbom.json" +``` + +업로드 후에는 도구가 취약점 데이터베이스와 대조해 취약점 목록을 만든다. 폐쇄망에서는 이 +데이터베이스를 오프라인으로 갱신한다. 한 번의 점검으로 끝나는 것이 아니라, 데이터베이스를 +갱신할 때마다 이미 등록된 SBOM이 다시 평가돼 신규 취약점이 자동으로 드러난다. 운영 시스템의 +지속 모니터링은 [관리](../5-manage/)에서 더 다룬다. + +명령줄에서 한 번 점검할 때는 Grype나 Trivy를 쓸 수 있다. + +```bash +# SBOM을 입력으로 취약점을 점검한다 +grype sbom:foo-1.2.3.sbom.json +``` + +## 대응 기한 + +탐지만으로는 부족하다. 심각도에 따라 언제까지 조치할지 기한을 정해 두어야 지연이 방치되지 +않는다. 심각도와 노출 정도를 함께 보아 우선순위를 매기고, 등급별 대응 기한을 정책에 +명시한다. 아래는 기한을 정하는 예시이며, 조직의 위험 수용 수준에 맞춰 조정한다. **[본 가이드 권고]** + +| 심각도(CVSS) | 인터넷 노출 시스템 | 내부 시스템 | +|------|------|------| +| 심각(9.0~10.0) | 즉시 ~ 수일 내 | 수일 ~ 1주 내 | +| 높음(7.0~8.9) | 1주 내 | 2주 ~ 1개월 내 | +| 중간(4.0~6.9) | 정기 점검 주기 내 | 정기 점검 주기 내 | + +기한 내 조치가 어려운 경우의 임시 완화책과 예외 승인 절차도 함께 정한다. + +{{% alert title="폐쇄망 적용 시 — 패치 지연 관리" color="info" %}} +폐쇄망에서는 패치도 반입 절차를 거치므로 즉시 적용이 어렵다. 사전 승인된 미러로만 패치를 +수급하고 적용 전까지의 임시 완화책을 절차에 넣는 방법은 [폐쇄망 +운영](../0-closed-network/#패치-지연-관리)에서 다룬다. +{{% /alert %}} + +## 라이선스 이슈 해결 + +취약점과 함께 풀어야 할 다른 이슈는 라이선스다. 식별한 오픈소스의 라이선스 의무를 확인하고, +의무를 충족하지 못하는 사용을 찾아 해결한다. ISO/IEC 5230은 이를 라이선스 사용 사례 처리 +절차(3.3.2.1)로 요구한다. **[ISO 요구]** + +금융권에서 라이선스 이슈는 배포 여부에 따라 성격이 달라진다. 이 가이드는 두 경우를 나눠 본다. + +- 외부로 배포하는 소프트웨어(대외 서비스, 고객 앱): GPL 계열 등 배포 기반 라이선스의 + 의무(고지, 경우에 따라 소스 공개)가 발생한다. 라이선스 의무를 충족하는 절차를 갖춰야 한다. +- 외부로 배포하지 않는 사내 운영 시스템: 배포가 없어 GPL 등의 소스 공개 의무는 약하지만, + 라이선스 호환성과 사용 조건은 여전히 확인한다. + +FSEC 안내서도 외부 배포 시 GPL 계열 사용에 대한 소스 공개정책 마련을 점검 항목으로 둔다. +배포 소프트웨어와 사내 운영 시스템의 범위 구분은 [관리](../5-manage/)에서 더 다룬다. + +라이선스 점검에는 FOSSology, SCANOSS 같은 오픈소스 도구를 쓸 수 있다. 다만 도구 자체의 +라이선스도 확인한다. FOSSLight(AGPL-3.0)의 사례는 [폐쇄망 운영의 도구 +선택](../0-closed-network/#폐쇄망에-맞는-도구-선택)에서 다룬다. + +{{% alert title="제3자·외주 적용 시" color="info" %}} +외주 산출물에서 발견한 취약점과 라이선스 이슈는 책임 소재를 먼저 정한다. 계약에 취약점 +대응 의무와 라이선스 의무 이행을 명시했는지 확인하고, 외주사가 대응하지 못하는 경우의 +처리 방법을 정한다. 계약 단계의 요구사항은 [사용 승인](../4-approve/)에서 다룬다. +{{% /alert %}} + +{{% alert title="신설 조직이 먼저 할 일과 운영 조직의 고도화" color="success" %}} +처음 체계를 세우는 조직은 인터넷에 노출된 시스템의 심각 취약점부터 점검해 대응하고, +배포하는 소프트웨어의 라이선스 의무부터 확인한다. 위험이 큰 곳부터 좁혀 들어간다. + +이미 운영 중인 조직은 8가지 취약점 처리 방법(위협 식별, 취약점 탐지, 후속 조치, 고객 통보, +배포 후 신규 취약점 분석, 지속적 보안 테스트, 위험 해결 검증, 위험 정보 보고)을 모두 절차로 +갖추고, 취약점 대응을 자동화하며, VEX로 판단 기록을 재사용한다. +{{% /alert %}} + +## FSEC 안내서·ISO 표준과의 연결 + +| 이슈 해결 활동 | ISO/IEC 5230 | ISO/IEC 18974 | FSEC 안내서 | +|------|------|------|------| +| 취약점 처리 방법 정의 | — | 4.1.5.1 8가지 처리 방법 | 이슈 파악 및 해결 | +| 취약점 탐지·해결 절차 | — | 4.3.2.1 탐지·해결 절차 | 이슈 파악 및 해결 | +| 취약점·조치 기록 | — | 4.3.2.2 취약점·조치 기록 | 이슈 파악 및 해결 | +| 라이선스 사용 사례 처리 | 3.3.2.1 라이선스 사용 사례 처리 | — | 이슈 파악 및 해결 | + +취약점 대응 절차의 조항별 상세는 [ISO/IEC 18974 준수 가이드의 보안 보증 조항](../../iso18974_guide/3-content-review/2-security-assurance/)에서, +8가지 처리 방법은 [표준 관행 구현 조항](../../iso18974_guide/1-program-foundation/5-standard-practice/)에서 +더 자세히 다룬다. + +{{% alert title="현장 사례 — 카카오뱅크의 보안 보증 준비" color="success" %}} +카카오뱅크는 KWG 20차 정기 미팅(2023-11)에서 ISO/IEC 18974 오픈소스 보안 보증을 준비한 +사례를 공유했다. 취약점 탐지와 대응을 체계화한 금융권 보안 보증 사례다. + +출처: 하헌관·이민애(카카오뱅크), "카카오뱅크 오픈소스 보안 보증 준비 사례 공유", [KWG 20차 미팅(2023-11) 발표자료](https://github.com/OpenChain-Project/OpenChain-KWG/releases/download/meeting-slides-legacy/kakaobank-ISO18974-conformance-case-study.pdf). +{{% /alert %}} + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/4-approve/_index.md b/content/ko/guide/finance-oss-guide/4-approve/_index.md new file mode 100644 index 0000000000..db94e39a4f --- /dev/null +++ b/content/ko/guide/finance-oss-guide/4-approve/_index.md @@ -0,0 +1,137 @@ +--- +title: "사용 승인: 무엇을 어떤 근거로 허용하는가" +linkTitle: "4. 사용 승인" +weight: 50 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "사용 승인", "위험평가", "계약"] +description: > + 오픈소스 사용을 승인하는 워크플로, 망분리 예외 시 자체 위험평가, 외주 계약과 제안요청서에 + 넣을 오픈소스 요구사항을 다룬다. +--- + +{{% alert title="이 페이지의 위치" color="info" %}} +식별과 이슈 해결을 거친 오픈소스를 실제로 쓸지 결정하는 단계다. 승인은 한 사람의 판단이 +아니라 정해진 절차와 기록으로 이뤄져야 한다. FSEC 안내서의 세 번째 절차이고, ISO/IEC 5230의 +라이선스 의무 검토(3.1.5)와 거버넌스에 연결된다. + +여기서 만드는 문서: 승인 신청·검토·결정 기록, 외주 계약의 오픈소스 요구 조항. +{{% /alert %}} + +## 사용 승인 워크플로 + +사용 승인은 "이 오픈소스를 이 용도로 써도 되는가"에 답하는 절차다. 답의 근거는 앞 단계에서 +나온다. 식별로 무엇인지 알고, 이슈 파악·해결로 취약점과 라이선스 의무를 파악한 뒤, 그 결과를 +놓고 승인 여부를 정한다. + +기본 흐름은 요청, 검토, 결정, 기록이다. + +- 요청: 사용하려는 오픈소스와 용도, 배포 여부를 신청한다. +- 검토: 라이선스 의무, 보안 취약점, 기술 적합성을 함께 본다. 검토 주체는 거버넌스에서 정한 + 오픈소스 검토 위원회(OSRB, Open Source Review Board)다. +- 결정: 승인, 조건부 승인(완화 조치를 전제로 허용), 반려 중 하나로 정한다. +- 기록: 결정과 그 근거를 남긴다. 이 기록이 감사 증적이 된다. + +```mermaid +flowchart LR + A["요청
(오픈소스·용도·배포 여부)"] --> B{"위험이
낮은가?"} + B -- "예 (사전 기준 충족)" --> C["자동 승인"] + B -- 아니오 --> D["OSRB 검토
법무·보안·기술"] + D --> E["승인"] + D --> F["조건부 승인
(완화 조치 전제)"] + D --> G["반려"] + C --> H["결정·근거 기록
(감사 증적)"] + E --> H + F --> H + G --> H + + style C fill:#276749,color:#fff + style D fill:#2b6cb0,color:#fff + style G fill:#c53030,color:#fff + style H fill:#2d3748,color:#fff +``` + +망분리 예외가 걸린 사용은 이 워크플로와 별도로, 자체 위험평가서에 대한 +정보보호위원회(CISO)의 승인이 먼저 필요하다. 아래 절에서 다룬다. + +모든 사용을 같은 무게로 검토할 필요는 없다. 위험이 낮은 사용은 사전에 정한 기준으로 자동 +승인하고, 배포 소프트웨어에 들어가거나 라이선스 의무가 큰 사용만 위원회에 올리는 식으로 +차등한다. ISO/IEC 5230은 라이선스 의무사항 검토 절차(3.1.5.1)를 입증자료로 요구한다. +**[ISO 요구]** + +{{% alert title="신설 조직이 먼저 할 일과 운영 조직의 고도화" color="success" %}} +처음 체계를 세우는 조직은 승인 신청 양식과 검토 기준을 정하는 일부터 시작한다. 누가 신청하고 +누가 검토하며 누가 최종 승인하는지를 정해 문서로 남긴다. + +이미 운영 중인 조직은 위험 수준별 자동 승인 기준을 마련해 검토 부담을 줄이고, 승인 기록을 +식별 자산 인벤토리·감사 증적과 연동한다. +{{% /alert %}} + +## 망분리 예외 시 자체 위험평가 + +전자금융감독규정 개정(2025-02-05 시행)으로 고유식별정보와 개인신용정보를 처리하지 않는 +연구·개발 목적 업무는 자체 위험평가와 망분리 대체 정보보호통제 적용을 거쳐 망분리 예외를 +적용할 수 있다. 망분리 예외 자체의 승인은 오픈소스 검토 위원회가 아니라 전사 보안 +거버넌스, 곧 정보보호위원회(또는 정보보호최고책임자, CISO)의 소관이다. + +오픈소스 사용 승인은 이 절차와 맞물린다. 위험평가서에 들어가는 오픈소스 위험 정보(SBOM, +취약점, 라이선스)는 식별과 이슈 파악·해결 단계에서 나오므로, 오픈소스 관리 조직은 그 +정보를 제공하고 검토를 지원한다. 망분리 예외 구간에서 쓸 오픈소스의 사용 승인을 검토할 +때는 승인된 위험평가서를 근거 문서로 함께 보고, 그 결정을 기록한다. 평가서에 무엇을 +담는지는 [폐쇄망 운영의 자체 +위험평가](../0-closed-network/#망분리-예외-시-자체-위험평가)에서 다룬다. **[본 가이드 권고]** + +{{% alert title="폐쇄망 적용 시" color="info" %}} +폐쇄망 안에서 쓰는 오픈소스는 반입 승인과 사용 승인이 맞물린다. 반입 단계의 검증 결과(무결성, +악성코드 검사, SBOM, 취약점 점검)를 사용 승인 검토에 함께 쓰면 절차가 중복되지 않는다. +반입 절차는 [폐쇄망 운영](../0-closed-network/#반입-통제)을 참고한다. +{{% /alert %}} + +## 외주 계약과 제안요청서 + +금융권은 외주 개발과 위탁이 많아, 사용 승인은 계약 단계로 거슬러 올라간다. 외주 산출물에 +포함될 오픈소스를 통제하려면, 계약과 제안요청서에 오픈소스 관리 요구사항을 미리 넣어야 한다. + +계약에 넣을 요구사항은 다음과 같다. + +- SBOM(Software Bill of Materials) 제출: 산출물에 포함된 오픈소스의 목록을 표준 형식으로 제출하도록 요구한다. +- 라이선스 의무 이행: 라이선스 고지와 의무 이행의 책임을 명시한다. +- 취약점 대응: 취약점이 발견됐을 때의 대응 의무와 기한을 정한다. +- 소유권·권리 귀속: 산출물의 소유권, 저작권, 지식재산권 귀속을 명확히 한다. + +마지막 항목은 전자금융감독규정 제21조와 닿는다. 2025-02-05 개정 전의 제21조는 정보처리시스템 +구축과 전자금융거래 계약에서 제품의 소유권·저작권·지식재산권 귀속을 명확히 하도록 명시했고, +FSEC 안내서도 이를 근거로 권리 귀속 관리를 안내한다. 개정된 현행 제21조는 세부 항목을 +나열하는 대신 계약의 안전성과 신뢰성, 공정성을 확보하기 위한 내부통제 절차를 수립하고 +운용하도록 요구하는데, 권리 귀속 명확화는 그 내부통제의 핵심 내용으로 여전히 유효한 실무다. 외주 계약에 오픈소스 관련 권리 +귀속을 분명히 적는 것은 이 요구를 충족하는 일이다. **[FSEC 안내서]** + +{{% alert title="제3자·외주 적용 시" color="info" %}} +전자금융보조업자가 사용하는 오픈소스도 같은 승인 체계 안에 둔다. 외주사가 제출한 SBOM과 +취약점 점검 결과를 검토해 승인하고, 그 책임을 누가 지는지 계약에 적는다. 외주사가 관리 +역량을 갖추지 못한 경우의 보완 방법(직접 스캔, 대체 컴포넌트 요구)도 정한다. +{{% /alert %}} + +## FSEC 안내서·ISO 표준과의 연결 + +| 사용 승인 활동 | ISO/IEC 5230 | FSEC 안내서 | +|------|------|------| +| 라이선스 의무 검토 | 3.1.5.1 라이선스 의무사항 검토 절차 | 사용 승인 | +| 승인 결정·기록 | 3.1.5.1 검토·기록 절차(3.3.1.1 승인 절차 준용) | 사용 승인 | +| 망분리 예외 위험평가 | — (전자금융감독규정 자율보안) | 사용 승인 | +| 외주 계약 권리 귀속 | — (전자금융감독규정 제21조 내부통제) | 사용 승인(전자금융보조업자) | + +승인 프로세스의 일반 실무는 기존 [기업 오픈소스 관리 가이드의 프로세스 섹션](../../opensource_for_enterprise/3-process/)에서 +더 자세히 다룬다. 정책·절차 양식은 [정책·절차 템플릿](../../templates/)을 금융 맥락으로 보강해 +쓰며, 보강한 골격은 산출물의 [금융 정책·절차 템플릿](../artifacts/2-policy-templates/)으로 제공한다. + +{{% alert title="현장 사례 — 카카오뱅크의 인증과 승인 체계" color="success" %}} +카카오뱅크는 KWG 13차 정기 미팅(2022-03)에서 ISO/IEC 5230 인증 사례를 공유하며, 오픈소스 +사용을 검토하고 승인하는 체계를 함께 소개했다. 금융권에서 승인 거버넌스를 세운 사례다. + +출처: 하헌관·이민애(카카오뱅크), 13차 공동 세션 "카카오와 카카오뱅크의 ISO/IEC 5230 인증 사례 공유" 중 카카오뱅크 발표분, [KWG 13차 미팅(2022-03) 발표자료](https://github.com/OpenChain-Project/OpenChain-KWG/releases/download/meeting-slides-2022/KakaoBank_ISO_IEC_5230_certification_case.pdf). +{{% /alert %}} + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/5-manage/30th-s1-claude-code.png b/content/ko/guide/finance-oss-guide/5-manage/30th-s1-claude-code.png new file mode 100644 index 0000000000..da5e7ea9c0 Binary files /dev/null and b/content/ko/guide/finance-oss-guide/5-manage/30th-s1-claude-code.png differ diff --git a/content/ko/guide/finance-oss-guide/5-manage/_index.md b/content/ko/guide/finance-oss-guide/5-manage/_index.md new file mode 100644 index 0000000000..08ed2eab9d --- /dev/null +++ b/content/ko/guide/finance-oss-guide/5-manage/_index.md @@ -0,0 +1,154 @@ +--- +title: "관리: 사내 운영 시스템의 지속 점검과 감사 대응" +linkTitle: "5. 관리" +weight: 60 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "모니터링", "감사", "운영 복원력"] +description: > + 외부로 배포하지 않는 사내 운영 시스템의 오픈소스를 지속적으로 점검·모니터링하고, 정기 + 재평가와 감사 증적 관리로 운영 단계의 위험을 관리하는 방법을 다룬다. +--- + +{{% alert title="이 페이지의 위치" color="info" %}} +도입 시점에 한 번 점검하고 끝내면 관리가 아니다. 오픈소스 위험은 운영 내내 이어지고, +새 취약점은 도입 뒤에 공개된다. FSEC 안내서의 마지막 절차인 관리(모니터링) 단계이고, ISO/IEC +18974의 지속 모니터링에 대응한다. 금융권에서 비중이 가장 큰 단계다. + +여기서 만드는 문서: 정기 재평가 기록, 감사 증적 묶음. +{{% /alert %}} + +## 배포 소프트웨어와 사내 운영 시스템의 구분 + +오픈소스 관리의 초점은 흔히 외부로 배포하는 소프트웨어에 맞춰진다. 배포가 라이선스 의무를 +일으키기 때문이다. 그러나 금융권에서 오픈소스가 가장 많이 쓰이는 곳은 외부로 배포되지 않는 +사내 운영 시스템이다. 계정계와 정보계, 사내 금융 관리 시스템, 내부 서버가 그렇다. 이 가이드는 +두 범위를 나눠 다룬다. + +- 배포 소프트웨어(대외 서비스, 고객 앱): 라이선스 의무(고지, 경우에 따라 소스 제공)가 중심이다. + ISO/IEC 5230의 영역이다. +- 사내 운영 시스템과 서버(비배포): 외부 배포가 없어 소스 공개 의무는 약하지만, 보안 취약점과 + 공급망 위험은 오히려 크고 상시적이다. 취약점 지속 점검, 자산 인벤토리, 정기 재평가가 + 중심이다. ISO/IEC 18974와 운영 복원력의 영역이다. + +이 페이지는 두 번째 범위, 곧 사내 운영 시스템의 관리에 집중한다. 금융권 특유의 강조점이기 +때문이다. 유럽연합의 디지털 운영 복원력법(DORA, Digital Operational Resilience Act)이 ICT +운영 복원력과 오픈소스 취약점·패치 관리를 요구하는 것도 같은 맥락이다. **[본 가이드 권고]** + +## 운영 자산 인벤토리 + +지속 점검의 출발은 무엇이 가동 중인지 아는 것이다. 운영 중인 사내 시스템과 서버에 어떤 +오픈소스가 들어 있는지 목록으로 만든다. 신규 도입만이 아니라 이미 오래 운영 중인 레거시까지 +SBOM(Software Bill of Materials)으로 식별한다. 도입 기록이 없는 레거시를 빠뜨리면 점검 범위에 +구멍이 생긴다. + +운영 자산 인벤토리는 식별 단계([식별](../2-identify/))에서 만든 SBOM을 운영 시스템 기준으로 +모은 것이다. 어떤 시스템이 어떤 컴포넌트를 쓰는지 연결해 두면, 신규 취약점이 공개됐을 때 +영향받는 시스템을 곧바로 찾을 수 있다. + +## 지속 취약점 모니터링 + +운영 단계의 핵심은 상시 감시다. 신규 취약점(CVE, Common Vulnerabilities and Exposures)이 +공개될 때마다 영향받는 운영 시스템을 역추적하는 구조를 갖춘다. 이는 ISO/IEC 18974의 취약점 +탐지·해결 절차(4.3.2.1)를 운영 단계로 이어 가는 활동이다. **[ISO 요구]** + +방법은 운영 시스템의 SBOM을 취약점 관리 도구에 등록해 두는 것이다. Dependency-Track에 SBOM을 +등록하면, 취약점 데이터베이스가 갱신될 때마다 등록된 모든 SBOM이 다시 평가돼 신규 취약점이 +자동으로 드러난다. 서버와 컨테이너, 파일시스템은 Trivy로 주기적으로 스캔한다. + +![Dependency-Track에 시스템별로 SBOM을 등록한 프로젝트 목록](./dt-projects.png) + +*그림: 운영 시스템별로 SBOM을 등록한 Dependency-Track 프로젝트 목록. 신규 취약점이 공개되면 +이 목록에서 영향받는 시스템이 드러난다. 화면은 [cdxgen·Dependency-Track +튜토리얼](../../tools/8-cdxgen-dt/)의 캡처를 재사용했다.* + +### 주기 스캔 예제 + +운영 서버를 정기적으로 스캔해 결과를 남기는 흐름을 예로 든다. 도구는 예시이며 동급 도구로 +바꿔도 된다. + +```bash +# 운영 서버의 파일시스템을 스캔해 결과를 날짜별로 보관한다 +trivy fs --format json --output /var/log/oss-scan/$(date +%Y%m%d).json /opt/app + +# 폐쇄망에서는 취약점 DB를 오프라인으로 갱신해 두고 자동 갱신을 끈다 +TRIVY_SKIP_DB_UPDATE=true trivy fs /opt/app +``` + +폐쇄망에서는 취약점 데이터베이스를 오프라인으로 갱신한다. 갱신 절차는 [폐쇄망 +운영](../0-closed-network/#오프라인-취약점-관리)에서 다룬다. 스캔 결과는 다음에서 다룰 감사 +증적으로 보관한다. + +{{% alert title="폐쇄망 적용 시" color="info" %}} +폐쇄망의 운영 시스템은 실시간 취약점 정보를 받지 못하므로, 오프라인 취약점 데이터베이스의 +동기화 주기가 곧 신규 취약점 인지 주기가 된다. 동기화 주기와 책임자를 정하고, 인지 지연 +구간에 발생할 수 있는 위험을 관리한다. 자세한 절차는 [폐쇄망 운영](../0-closed-network/#오프라인-취약점-관리)을 참고한다. +{{% /alert %}} + +## 정기 재평가 + +지속 모니터링이 자동 감시라면, 정기 재평가는 사람이 주기적으로 점검 체계 자체를 다시 보는 +활동이다. 분기나 반기 같은 정기 점검과 함께, 시스템 변경 시점의 재점검을 절차로 만든다. +ISO/IEC 18974는 프로그램의 주기적 검토와 변경 증거(4.1.2.5)를 입증자료로 요구한다. **[ISO 요구]** + +망분리 예외를 적용한 시스템은 자체 위험평가를 정기적으로 갱신한다. 규제 완화로 망분리에서 +벗어난 만큼, 자율보안의 책임이 재평가 주기와 함께 이어진다. 자체 위험평가서는 [사용 +승인](../4-approve/#망분리-예외-시-자체-위험평가)에서 다룬다. + +## 감사 증적 관리 + +금융권은 내외부감사와 금융감독원의 정보기술(IT) 검사에 대비해야 한다. 관리 단계의 점검 +기록은 그 자체로 감사 증적이 된다. 무엇을 언제 점검했고 어떤 취약점에 어떻게 대응했는지의 +기록을 보관하면, 감사와 검사에서 요구하는 증적을 따로 만들 필요가 없다. + +ISO 입증자료 체계를 감사 증적으로 재활용하는 것이 효율적이다. ISO/IEC 18974가 요구하는 +취약점·조치 기록, ISO/IEC 5230이 요구하는 컴플라이언스 산출물 생성·보관(3.4.1.1, 3.4.1.2)이 +그대로 감사 대응 자료가 된다. 증적을 어디에 얼마나 보관할지 정하고, 위변조를 막는 기록 +방식을 갖춘다. **[본 가이드 권고]** + +무엇을 보관할지의 체크리스트와 보관 위치 명세는 산출물로 제공하는 [감사 증적 +목록](../artifacts/3-audit-evidence/)을 쓴다. + +{{% alert title="신설 조직이 먼저 할 일과 운영 조직의 고도화" color="success" %}} +처음 체계를 세우는 조직은 인터넷에 노출된 운영 시스템부터 SBOM을 등록해 지속 모니터링을 +시작하고, 점검 기록을 한곳에 보관하는 것부터 한다. + +이미 운영 중인 조직은 레거시까지 자산 인벤토리를 넓히고, 정기 재평가 주기를 절차화하며, +금융권 공급망 보안 플랫폼과 연계해 취약점 정보를 공유하고, 감사 증적을 위변조 방지 형태로 +관리한다. +{{% /alert %}} + +## FSEC 안내서·ISO 표준과의 연결 + +| 관리 활동 | ISO/IEC 5230 | ISO/IEC 18974 | FSEC 안내서 | +|------|------|------|------| +| 지속 취약점 모니터링 | — | 4.3.2 출시 후 모니터링 | 관리 | +| 정기 재평가 | — | 4.1.2.5 주기적 검토·변경 증거 | 관리 | +| 산출물 생성·보관 | 3.4.1.1 생성, 3.4.1.2 보관 | — | 관리 | +| 감사 증적 | 3.4.1.2 보관 준용 | 4.3.2.2 취약점 및 조치 기록 | 관리 | + +지속 모니터링과 보안 보증의 조항별 상세는 [ISO/IEC 18974 준수 가이드](../../iso18974_guide/)에서 +더 자세히 다룬다. + +{{% alert title="현장 사례 — 카카오뱅크의 감사 대응과 AI 활용" color="success" %}} +카카오뱅크는 KWG 30차 정기 미팅(2026-06)에서 금융권 감사 대응 경험을 공유했다. 금융감독원의 +IT리스크 계량평가와 경영실태평가, 한국은행의 연간 금융정보화 추진현황 조사 등 여러 기관의 +점검과 자료요청에 대응해 왔는데, 기관이 공통으로 확인하는 것은 오픈소스 현황 관리 여부, +현황 전체 목록, 관리 인력 구성, 정책 수립과 내규, 보안취약점 점검 절차의 다섯 가지였다. +분기마다 자체 점검을 하고 취약점을 지속 모니터링하는 평소 기록이 그대로 대응 자료가 됐다. + +같은 미팅에서 AI 코딩 에이전트로 라이선스 식별과 호환성 분석, SBOM 생성, 고지문 작성을 +자동화해 릴리스마다 반복되던 검증 작업을 줄인 사례도 소개했다. + +![AI 코딩 에이전트를 오픈소스 거버넌스에 활용한 발표 슬라이드](./30th-s1-claude-code.png) + +*그림: AI 코딩 에이전트의 오픈소스 거버넌스 활용. 하헌관(카카오뱅크) 발표자료 7쪽. +슬라이드 이미지는 발표자 저작물로, 본문의 CC BY 4.0 적용 대상이 아니다.* + +출처: 이민애(카카오뱅크), "금융회사로서의 오픈소스 관련 업무 대응 후기", [발표자료](https://github.com/OpenChain-Project/OpenChain-KWG/releases/download/meeting-slides-2026/30th-session3-finance-oss-report.pdf); +하헌관(카카오뱅크), "AI-driven Open Source Governance", [발표자료](https://github.com/OpenChain-Project/OpenChain-KWG/releases/download/meeting-slides-2026/30th-session1-ai-driven-oss-governance.pdf). KWG 30차 미팅(2026-06). +{{% /alert %}} + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/5-manage/dt-projects.png b/content/ko/guide/finance-oss-guide/5-manage/dt-projects.png new file mode 100644 index 0000000000..ca29a8f4d4 Binary files /dev/null and b/content/ko/guide/finance-oss-guide/5-manage/dt-projects.png differ diff --git a/content/ko/guide/finance-oss-guide/6-self-check/_index.md b/content/ko/guide/finance-oss-guide/6-self-check/_index.md new file mode 100644 index 0000000000..0fbd93a5f1 --- /dev/null +++ b/content/ko/guide/finance-oss-guide/6-self-check/_index.md @@ -0,0 +1,114 @@ +--- +title: "자가점검: 우리 체계의 빈 곳 찾기" +linkTitle: "6. 자가점검" +weight: 70 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "자가점검", "체크리스트", "입증자료"] +description: > + FSEC 안내서 다섯 분류의 취지를 참고해 이 가이드의 표현으로 새로 쓴 점검 항목을 ISO + 입증자료, 권장 도구, 가이드 섹션과 연결해, 자사 오픈소스 관리 체계의 빠진 곳을 찾을 수 + 있게 한다. +--- + +{{% alert title="이 페이지의 위치" color="info" %}} +앞의 여섯 단계를 점검표로 모은 자리다. 항목을 하나씩 짚어 자사 체계의 빈 곳을 찾고, 부족한 +부분을 다루는 섹션으로 이동한다. 분류는 FSEC 안내서의 자가점검 체크리스트(별첨1)를 참고했다. + +여기서 만드는 문서: 자가점검 워크북(점검 결과와 개선 계획). +{{% /alert %}} + +## 자가점검을 쓰는 방법 + +이 점검표는 통과·불합격을 가리는 시험이 아니다. 자사가 어디까지 갖췄는지 가늠하고 다음에 +무엇을 할지 찾는 도구다. FSEC 안내서가 비규제 자율 점검이듯, 이 점검표도 모범 실무 기준이다. +**[FSEC 안내서]** + +각 항목은 관련 ISO 입증자료, 권장 도구, 자세히 다루는 가이드 섹션과 연결돼 있다. 충족하지 +못한 항목이 있으면 연결된 섹션으로 가서 방법을 확인한다. FSEC 안내서가 쓰는 다섯 분류, 곧 +식별, 이슈 파악 및 해결, 승인, 관리, 기타의 순서를 따른다. + +{{% alert title="신설 조직이 먼저 할 일과 운영 조직의 고도화" color="success" %}} +처음 체계를 세우는 조직은 전 항목을 한 번에 점검하려 하지 말고, 기반에 해당하는 기타 +분류와 출발점인 식별 분류부터 점검해 무엇부터 갖출지 정한다. + +이미 운영 중인 조직은 전 항목을 점검한 뒤, 미충족 항목을 [자가점검 +워크북](../artifacts/1-workbook/)의 개선 계획(담당자, 목표 기한)으로 옮겨 관리한다. +{{% /alert %}} + +{{% alert title="저작권 안내" color="warning" %}} +아래 점검 항목은 FSEC 안내서의 체크리스트 문항을 옮긴 것이 아니라, 다섯 분류의 취지를 +참고해 이 가이드의 표현으로 새로 작성한 것이다. 안내서 원문을 함께 확인하려면 [금융보안원 +게시 자료](https://www.fsec.or.kr/bbs/detail?menuNo=222&bbsNo=11166)를 참고한다. +{{% /alert %}} + +## 식별 + +| 점검 항목 | 관련 ISO 입증자료 | 권장 도구 | 가이드 섹션 | +|------|------|------|------| +| 오픈소스 관리의 적용 범위가 문서로 정의돼 있다 | 5230 3.1.4.1 | — | [식별](../2-identify/) | +| 새로 도입하는 오픈소스와 그 의존성을 빠짐없이 파악한다 | 5230 3.3.1.1 | Syft, cdxgen | [식별](../2-identify/) | +| 전이 의존성까지 펼쳐 식별한다 | 5230 3.3.1.1 | Syft, OSV-SCALIBR | [식별](../2-identify/) | +| 이미 운영 중인 시스템의 레거시 오픈소스를 식별한다 | 5230 3.3.1.1 | Trivy, Dependency-Track | [식별](../2-identify/#운영-중인-시스템의-식별) | +| 식별 결과를 표준 형식 SBOM으로 기록한다 | 5230 3.3.1.2 | cdxgen, Syft | [식별](../2-identify/#sbom-작성과-기록) | +| 외주·전자금융보조업자 산출물의 오픈소스를 식별한다 | 5230 3.3.1.1 준용 | (SBOM 제출 요구) | [식별](../2-identify/#제3자와-외주-산출물-식별) | + +## 이슈 파악 및 해결 + +| 점검 항목 | 관련 ISO 입증자료 | 권장 도구 | 가이드 섹션 | +|------|------|------|------| +| SBOM의 각 컴포넌트에 알려진 취약점이 있는지 점검한다 | 18974 4.3.2.1 | Dependency-Track, Grype, Trivy | [이슈 파악·해결](../3-issue-resolve/) | +| 취약점에 위험 점수를 매기고 심각도별 대응 기한을 정한다 | 18974 4.3.2.1 | Dependency-Track, Grype | [이슈 파악·해결](../3-issue-resolve/#대응-기한) | +| 취약점 조치 결과를 기록한다(조치 불필요 판단 포함) | 18974 4.3.2.2 | Dependency-Track(VEX) | [이슈 파악·해결](../3-issue-resolve/) | +| 라이선스 의무를 확인하고 충돌을 해결한다 | 5230 3.3.2.1 | FOSSology, SCANOSS | [이슈 파악·해결](../3-issue-resolve/#라이선스-이슈-해결) | +| 외부 배포 시 GPL 계열 소스 공개 정책을 갖춘다 | 5230 3.3.2.1 | — | [이슈 파악·해결](../3-issue-resolve/#라이선스-이슈-해결) | + +## 승인 + +| 점검 항목 | 관련 ISO 입증자료 | 권장 도구 | 가이드 섹션 | +|------|------|------|------| +| 오픈소스 사용 승인 절차와 검토 주체가 정해져 있다 | 5230 3.1.5.1 | SW360, Dependency-Track(정책) | [사용 승인](../4-approve/) | +| 승인 결정과 그 근거를 기록한다 | 5230 3.1.5.1 | SW360, Dependency-Track | [사용 승인](../4-approve/#사용-승인-워크플로) | +| 망분리 예외 시 자체 위험평가서로 승인 근거를 남긴다 | (전자금융감독규정) | — | [사용 승인](../4-approve/#망분리-예외-시-자체-위험평가) | +| 외주 계약에 SBOM·라이선스·취약점·권리 귀속 요구를 넣는다 | (권리 귀속은 전자금융감독규정 제21조, 그 외는 본 가이드 권고) | — | [사용 승인](../4-approve/#외주-계약과-제안요청서) | + +## 관리 + +| 점검 항목 | 관련 ISO 입증자료 | 권장 도구 | 가이드 섹션 | +|------|------|------|------| +| 운영 시스템의 SBOM을 등록해 지속적으로 취약점을 감시한다 | 18974 4.3.2 | Dependency-Track | [관리](../5-manage/#지속-취약점-모니터링) | +| 신규 취약점 공개 시 영향받는 시스템을 역추적한다 | 18974 4.3.2 | Dependency-Track | [관리](../5-manage/#지속-취약점-모니터링) | +| 정기 재평가 주기가 정해져 있다 | 18974 4.1.2.5 | — | [관리](../5-manage/#정기-재평가) | +| 점검 기록을 감사 증적으로 보관한다 | 5230 3.4.1.2 | — | [관리](../5-manage/#감사-증적-관리) | + +## 기타 + +기타 분류는 앞의 네 단계를 떠받치는 기반이다. FSEC 안내서도 선택 기준, 예외 승인, 역할 문서, +인력, 예산, 정책 인식, 법률 자문을 별도 분류로 둔다. + +| 점검 항목 | 관련 ISO 입증자료 | 권장 도구 | 가이드 섹션 | +|------|------|------|------| +| 오픈소스 선택 기준과 예외 승인 절차가 있다 | 5230 3.1.1.1 | — | [거버넌스](../1-governance/) | +| 역할과 책임이 문서화돼 있다 | 5230 3.1.2.1, 18974 4.1.2.3 | — | [거버넌스](../1-governance/#오픈소스-프로그램-조직ospo) | +| 담당 인력과 예산이 확보돼 있다 | 5230 3.2.2.2 | — | [거버넌스](../1-governance/#법률-자문과-예산) | +| 정책이 구성원에게 전파된다 | 5230 3.1.1.2 | — | [거버넌스](../1-governance/) | +| 법률 자문에 접근하는 경로가 있다 | 5230 3.2.2.3 | — | [거버넌스](../1-governance/#법률-자문과-예산) | + +## 자가점검 워크북 + +위 점검 항목을 점검 결과 기록, ISO 입증자료, 담당자, 목표 기한과 함께 한 시트로 묶은 +[자가점검 워크북](../artifacts/1-workbook/)을 산출물로 제공한다. 항목별 권장 도구는 +이 페이지의 표에서 확인한다. + +## ISO 입증자료와의 교차 참조 + +이 점검표의 항목은 ISO/IEC 5230과 18974의 입증자료에 연결된다. 점검 항목을 충족하면서 +근거 문서를 남기면, 그 문서가 그대로 ISO 자가 인증의 입증자료가 된다. 전 항목 점검을 마친 +뒤 모든 요구사항의 충족을 확인하는 문서를 작성하면, 그 문서는 ISO/IEC 5230의 요구사항 충족 +확인(3.6.1.1) 입증자료가 된다. 입증자료의 조항별 +상세는 [ISO/IEC 5230 준수 가이드](../../iso5230_guide/)와 [ISO/IEC 18974 준수 가이드](../../iso18974_guide/)에서, +전체 매핑은 [가이드 개요의 대조표](../#fsec-안내서-iso-표준-kwg-가이드-대조표)에서 확인한다. + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/_index.md b/content/ko/guide/finance-oss-guide/_index.md new file mode 100644 index 0000000000..e949d39d13 --- /dev/null +++ b/content/ko/guide/finance-oss-guide/_index.md @@ -0,0 +1,176 @@ +--- +title: "금융분야 오픈소스 관리 실무 가이드" +linkTitle: "금융 오픈소스 가이드" +weight: 45 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "컴플라이언스", "공급망 보안", "망분리"] +description: > + 금융분야 오픈소스 소프트웨어 활용·관리 안내서의 절차를 국제표준(ISO/IEC 5230·18974)과 + 연결해 실제로 운영 가능하게 만드는 금융권 특화 실무 가이드다. +--- + +{{% pageinfo %}} + +금융권은 오픈소스를 점점 더 많이 쓰면서도 폐쇄망, 망분리 규제, 공급망 보안, 감사 대응이라는 +고유한 조건 아래에서 관리해야 한다. 이 가이드는 금융분야 오픈소스 소프트웨어 활용·관리 +안내서(금융감독원·금융보안원, 2022)가 제시한 관리 절차를 국제표준 ISO/IEC 5230·18974의 +입증자료, 그리고 기존 KWG 실무 가이드와 연결해, 담당자가 무엇을 어떤 순서로 갖춰야 하는지를 +실행 가능한 형태로 안내한다. + +**Author : OpenChain Korea Work Group / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)** + +{{% /pageinfo %}} + +{{% alert title="본 가이드의 성격과 범위" color="warning" %}} +이 가이드는 금융분야 오픈소스 소프트웨어 활용·관리 안내서(이하 FSEC 안내서)를 대체하지 +않는다. 안내서가 정한 절차를 실제로 운영하도록 돕는 보조 자료다. 안내서가 비규제 자율 +안내이듯, 이 가이드의 권고도 법적 의무가 아니라 모범 실무다. + +범위는 안내서와 같다. 오픈소스의 활용과 관리(라이선스 준수, 보안 관리)에 집중하고, 자체 +소프트웨어의 외부 공개나 오픈소스 프로젝트 기여는 다루지 않는다. 금융권의 공개 소극성을 +반영한 결정이다. +{{% /alert %}} + +## 금융권이 놓인 규제 환경 + +금융권 오픈소스 관리는 일반 기업과 다른 규제 환경 위에서 이뤄진다. + +오픈소스 관리의 준거는 FSEC 안내서다. 금융감독원과 금융보안원이 2022년에 공동 발간했고(2023년 +2월 개정본 존재), 식별, 이슈 파악 및 해결, 사용 승인, 관리의 네 단계로 최소한의 보안관리 +절차를 제시한다. 비규제 자율 안내이며, 자가점검 체크리스트(식별, 이슈 파악 및 해결, 승인, +관리, 기타의 5개 분류)와 주요 관리도구, 운영 사례를 부속 자료로 담았다. + +규제 환경은 전환 중이다. 금융위원회의 금융분야 망분리 개선 로드맵(2024-08-13)에 이어 +전자금융감독규정과 시행세칙 개정이 2025-02-05에 시행되면서, 물리적 망분리 중심 규제가 +자율보안과 위험기반 접근으로 바뀌기 시작했고 연구·개발 목적 업무의 망분리 예외가 열렸다. +예외 적용 요건과 후속 완화, 대응 방법은 [폐쇄망 운영과 망분리 +전환](./0-closed-network/)에서 다룬다. + +공급망 보안의 비중이 커지고 있다. 금융보안원은 금융권 소프트웨어 공급망 보안 플랫폼을 +구축해 2025년 말 시범 운영을 거쳐 2026년부터 본격 운영한다. 금융권 취약점 통합관리, SBOM(Software +Bill of Materials) 관리체계, 버그바운티 운영 효율화를 제공한다. 정부도 SW 공급망 보안 가이드라인 1.0(과학기술정보통신부· +국가정보원·디지털플랫폼정부위원회, 2024-05-13)을 발표하고, 2027년 공공부문 SBOM 제출 +의무화를 목표로 단계적 제도화를 추진하고 있다. 해외에서는 미국과 유럽이 SBOM 제출 의무화를 +진행 중이며, 유럽연합의 디지털 +운영 복원력법(DORA, Digital Operational Resilience Act)은 2023년 발효돼 2025-01-17부터 적용되며 ICT 제3자 +위험관리와 오픈소스 취약점·패치 관리를 요구한다. 유럽에서 영업하거나 진출하는 금융사에 +직접 영향을 준다. + +## 이 가이드를 읽는 방법 + +오픈소스 관리 체계의 성숙도에 따라 읽는 방식이 다르다. 각 섹션은 신설 조직이 먼저 할 일과 +운영 조직의 고도화를 구분해 서술하므로, 자사 위치를 가늠한 뒤 해당 부분을 골라 읽으면 된다. + +처음 체계를 세우는 조직은 [폐쇄망 운영](./0-closed-network/)으로 환경을 정리한 뒤, +[거버넌스](./1-governance/)에서 [관리](./5-manage/)까지 순서대로 따라가며 각 단계가 안내하는 +문서와 절차를 하나씩 만든다. + +이미 운영 중인 조직은 [자가점검](./6-self-check/)으로 현재 상태를 평가하고, 부족한 단계로 +돌아가 고도화한다. + +### 성숙도 사다리 + +FINOS(Fintech Open Source Foundation, 핀테크 오픈소스 재단)의 오픈소스 성숙도 모델(Open +Source Readiness)은 조직의 단계를 +Usage, Compliance, Contribution, Hosting, Strategic Leverage로 구분한다. 이 가이드는 +활용·관리 범위에 집중하므로 앞의 두 단계, 곧 오픈소스를 쓰는 Usage와 컴플라이언스를 갖춘 +Compliance에 대응한다. 기여 이상 단계는 다루지 않는다. + +| 단계 | 상태 | 이 가이드에서 할 일 | FINOS 대응 | +|------|------|------|------| +| 신설 | 오픈소스를 쓰지만 관리 체계가 없다 | 폐쇄망 환경 정리, 거버넌스 수립, 식별 시작 | Usage | +| 운영 | 식별·승인·관리 절차가 돌아간다 | 취약점 대응 절차화, 사용 승인 체계화, 지속 모니터링 | Compliance | +| 고도 | 절차가 자동화되고 감사에 대응한다 | 공급망 플랫폼 연계, 감사 증적 체계, 정기 재평가 | Compliance(심화) | + +## FSEC 안내서, ISO 표준, KWG 가이드 대조표 + +FSEC 안내서의 절차가 ISO/IEC 5230·18974의 어떤 입증자료에 대응하고, 기존 KWG 가이드의 +어느 페이지에서 구체적 방법을 찾을 수 있으며, 이 가이드의 어느 섹션이 다루는지를 한 표로 +잇는다. 자가 인증 준비의 출발 자료다. + +| FSEC 절차 | 본 가이드 섹션 | ISO/IEC 5230 입증자료 | ISO/IEC 18974 입증자료 | 기존 KWG 가이드 | +|------|------|------|------|------| +| (거버넌스) | [1. 거버넌스](./1-governance/) | 3.1.1.1 정책, 3.1.2.1 역할·책임, 3.2.2.1 담당자 | 4.1.2.3 참여자·역할 매핑 | [조직](../opensource_for_enterprise/1-teams/) | +| 식별 | [2. 식별](./2-identify/) | 3.1.4.1 적용 범위, 3.3.1.1 SBOM 관리, 3.3.1.2 컴포넌트 기록 | — | [SBOM·도구](../opensource_for_enterprise/4-tool/), [§3.3.1](../iso5230_guide/3-content-review/1-sbom/) | +| 이슈 파악 및 해결 | [3. 이슈 파악·해결](./3-issue-resolve/) | 3.3.2.1 라이선스 사용 사례 처리 | 4.3.2.1 취약점 탐지·해결 절차, 4.3.2.2 취약점·조치 기록 | [iso18974 가이드](../iso18974_guide/) | +| 사용 승인 | [4. 사용 승인](./4-approve/) | 3.1.5.1 라이선스 의무 검토 절차 | — | [프로세스](../opensource_for_enterprise/3-process/) | +| 관리 | [5. 관리](./5-manage/) | 3.4.1.1 산출물 생성, 3.4.1.2 산출물 보관 | 4.1.2.5 주기적 검토·변경 증거 | [iso18974 가이드](../iso18974_guide/) | +| (전 단계 점검) | [6. 자가점검](./6-self-check/) | 3.6.1.1 요구사항 충족 확인 | — | [준수선언](../opensource_for_enterprise/6-conforming/) | + +ISO/IEC 5230은 13개 조항 25개 입증자료로, ISO/IEC 18974는 보안 보증 관점의 25개 입증자료(이 중 +18974 전용 9개)로 구성된다. 입증자료의 조항별 상세는 [ISO/IEC 5230 준수 가이드](../iso5230_guide/)와 +[ISO/IEC 18974 준수 가이드](../iso18974_guide/)에서 확인한다. + +## 가이드 구성 + +섹션 2~5가 FSEC 안내서의 네 단계(식별, 이슈 파악 및 해결, 사용 승인, 관리)에 대응하고, +그 앞뒤에 금융권 공통 전제인 폐쇄망 운영(0)과 거버넌스(1), 전 단계를 점검하는 +자가점검(6)을 두었다. + +```mermaid +flowchart LR + P0["0. 폐쇄망 운영
(공통 전제)"] --> P1["1. 거버넌스
(관리 조직)"] + P1 --> P2["2. 식별"] + P2 --> P3["3. 이슈
파악·해결"] + P3 --> P4["4. 사용 승인"] + P4 --> P5["5. 관리
(지속 모니터링)"] + P5 --> P6["6. 자가점검"] + P6 -. "부족한 단계로 돌아가 보완" .-> P2 + + style P0 fill:#2d3748,color:#fff + style P1 fill:#2d3748,color:#fff + style P2 fill:#2b6cb0,color:#fff + style P3 fill:#2b6cb0,color:#fff + style P4 fill:#2b6cb0,color:#fff + style P5 fill:#2b6cb0,color:#fff + style P6 fill:#276749,color:#fff +``` + +| 섹션 | 다루는 내용 | +|------|------| +| [0. 폐쇄망 운영](./0-closed-network/) | 반입 통제, 사내 미러, 오프라인 취약점 관리, 망분리 예외 자체 위험평가 | +| [1. 거버넌스](./1-governance/) | 관리 조직·역할, 오픈소스 검토 위원회(OSRB, Open Source Review Board), 승인 거버넌스 | +| [2. 식별](./2-identify/) | 인입 오픈소스·레거시 식별, SBOM, 제3자·외주 식별, 공급망 플랫폼 연계 | +| [3. 이슈 파악·해결](./3-issue-resolve/) | 취약점 평가·대응, 라이선스 이슈 해결, 패치 지연 관리 | +| [4. 사용 승인](./4-approve/) | 승인 워크플로, 망분리 예외 위험평가, 계약(제안요청서) 관리 | +| [5. 관리](./5-manage/) | 사내 운영 시스템 지속 모니터링, 정기 재평가, 감사 증적 | +| [6. 자가점검](./6-self-check/) | 자가점검 워크북(점검 항목·입증자료·도구 연결) | + +## 자가점검으로 시작하기 + +자사가 어느 단계에 있는지 모르겠다면 [자가점검](./6-self-check/)부터 본다. FSEC 안내서 +다섯 분류의 취지를 참고해 이 가이드의 표현으로 새로 쓴 점검 항목을 ISO 입증자료, 권장 +도구와 연결해, 빠진 부분을 찾고 그 부분을 다루는 섹션으로 이동할 수 있다. + +{{% alert title="표기 규칙" color="info" %}} +각 페이지는 출처를 다음 표기로 구분한다. + +- **[ISO 요구]** — ISO/IEC 5230·18974 표준이 입증자료로 명시적으로 요구하는 사항. +- **[FSEC 안내서]** — FSEC 안내서가 절차로 제시한 사항. 안내서는 비규제 자율 안내다. +- **[본 가이드 권고]** — 표준·안내서에 없으나 실무·금융 규제 환경을 근거로 권장하는 사항. + 채택은 조직 재량이다. +{{% /alert %}} + +{{% alert title="다른 KWG 가이드와의 관계" color="success" %}} +이 가이드는 기존 가이드 위에서 작동한다. 조직, 정책, 프로세스, 도구, 교육의 일반 실무는 +[기업 오픈소스 관리 가이드](../opensource_for_enterprise/)에서, 표준 입증자료의 조항별 +상세는 [ISO/IEC 5230 준수 가이드](../iso5230_guide/)와 [ISO/IEC 18974 준수 가이드](../iso18974_guide/)에서 +다룬다. 이 가이드는 그 위에 금융권의 폐쇄망, 망분리, 공급망, 감사 맥락을 더한다. +{{% /alert %}} + +## 출처 + +- 금융분야 오픈소스 소프트웨어 활용·관리 안내서(금융감독원·금융보안원, 2022). [금융보안원 게시](https://www.fsec.or.kr/bbs/detail?menuNo=222&bbsNo=11166) +- 금융분야 망분리 개선 로드맵(금융위원회, 2024-08-13). [금융위원회 보도자료](https://www.fsc.go.kr/no010101/82885) +- 전자금융감독규정·시행세칙 개정(금융위원회, 2025-02-05 시행). +- 금융권 소프트웨어 공급망 보안 플랫폼(금융보안원, 2026 본격 운영). [데일리시큐 보도](https://www.dailysecu.com/news/articleView.html?idxno=204828) +- SW 공급망 보안 가이드라인 1.0(과학기술정보통신부·국가정보원·디지털플랫폼정부위원회, 2024-05-13). [정책브리핑](https://www.korea.kr/news/policyNewsView.do?newsId=148929111) +- 공공부문 SBOM 제출 의무화 추진(2027 목표·계획). [데이터넷 보도](https://www.datanet.co.kr/news/articleView.html?idxno=208920) +- EU DORA(디지털 운영 복원력법, 2025-01-17 적용). [EIOPA 안내](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) +- [FINOS Open Source Readiness](https://osr.finos.org/docs/bok/introduction) +- [ISO/IEC 5230](https://www.iso.org/standard/81039.html), [ISO/IEC 18974](https://www.iso.org/standard/86450.html) + +--- + +*최종 검토일: 2026-06-10. 이 가이드는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/artifacts/1-workbook/_index.md b/content/ko/guide/finance-oss-guide/artifacts/1-workbook/_index.md new file mode 100644 index 0000000000..f8bb7f0ff8 --- /dev/null +++ b/content/ko/guide/finance-oss-guide/artifacts/1-workbook/_index.md @@ -0,0 +1,83 @@ +--- +title: "자가점검 워크북" +linkTitle: "자가점검 워크북" +weight: 10 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "자가점검", "워크북"] +description: > + 다섯 분류의 점검 항목을 충족 여부, 근거 문서, 담당자, 목표 기한과 함께 기록하는 워크북 + 양식이다. 자가점검 페이지의 항목을 개선 계획으로 옮길 때 쓴다. +--- + +이 워크북은 [자가점검](../../6-self-check/) 페이지의 점검 항목을 기록용 양식으로 옮긴 것이다. +점검만 하고 끝내지 않고, 부족한 부분의 담당자와 기한을 적어 개선 계획으로 잇기 위한 것이다. + +## 쓰는 방법 + +각 항목의 충족 상태를 세 단계로 표시한다. + +- 미충족: 관련 활동이나 문서가 없다. +- 부분 충족: 활동은 있으나 문서나 기록이 부족하다. +- 충족: 활동과 근거 문서를 모두 갖췄다. + +부분 충족이나 미충족 항목에는 근거 문서가 무엇이어야 하는지, 누가 언제까지 갖출지를 적는다. +충족 항목에는 근거 문서의 이름과 위치를 적어, 그대로 ISO 자가 인증의 입증자료로 쓸 수 있게 한다. + +아래 표를 복사해 조직의 점검 기록으로 채운다. 상태 칸에는 미충족·부분·충족 중 하나를 적는다. + +## 식별 + +| 점검 항목 | ISO 입증자료 | 상태 | 근거 문서·위치 | 담당자 | 목표 기한 | +|------|------|------|------|------|------| +| 오픈소스 관리의 적용 범위가 문서로 정의돼 있다 | 5230 3.1.4.1 | | | | | +| 새로 도입하는 오픈소스와 그 의존성을 빠짐없이 파악한다 | 5230 3.3.1.1 | | | | | +| 전이 의존성까지 펼쳐 식별한다 | 5230 3.3.1.1 | | | | | +| 이미 운영 중인 시스템의 레거시 오픈소스를 식별한다 | 5230 3.3.1.1 | | | | | +| 식별 결과를 표준 형식 SBOM으로 기록한다 | 5230 3.3.1.2 | | | | | +| 외주·전자금융보조업자 산출물의 오픈소스를 식별한다 | 5230 3.3.1.1 준용 | | | | | + +## 이슈 파악 및 해결 + +| 점검 항목 | ISO 입증자료 | 상태 | 근거 문서·위치 | 담당자 | 목표 기한 | +|------|------|------|------|------|------| +| 각 컴포넌트의 알려진 취약점을 점검한다 | 18974 4.3.2.1 | | | | | +| 위험 점수를 매기고 대응 기한을 정한다 | 18974 4.3.2.1 | | | | | +| 취약점 조치 결과를 기록한다 | 18974 4.3.2.2 | | | | | +| 라이선스 의무를 확인하고 충돌을 해결한다 | 5230 3.3.2.1 | | | | | +| 배포 시 GPL 계열 소스 공개 정책을 갖춘다 | 5230 3.3.2.1 | | | | | + +## 승인 + +| 점검 항목 | ISO 입증자료 | 상태 | 근거 문서·위치 | 담당자 | 목표 기한 | +|------|------|------|------|------|------| +| 사용 승인 절차와 검토 주체가 정해져 있다 | 5230 3.1.5.1 | | | | | +| 승인 결정과 근거를 기록한다 | 5230 3.1.5.1 | | | | | +| 망분리 예외 시 자체 위험평가서를 남긴다 | (전자금융감독규정) | | | | | +| 외주 계약에 오픈소스 요구사항을 넣는다 | (권리 귀속은 전자금융감독규정 제21조, 그 외는 본 가이드 권고) | | | | | + +## 관리 + +| 점검 항목 | ISO 입증자료 | 상태 | 근거 문서·위치 | 담당자 | 목표 기한 | +|------|------|------|------|------|------| +| 운영 시스템 SBOM을 등록해 지속 감시한다 | 18974 4.3.2 | | | | | +| 신규 취약점 공개 시 영향 시스템을 역추적한다 | 18974 4.3.2 | | | | | +| 정기 재평가 주기가 정해져 있다 | 18974 4.1.2.5 | | | | | +| 점검 기록을 감사 증적으로 보관한다 | 5230 3.4.1.2 | | | | | + +## 기타 + +| 점검 항목 | ISO 입증자료 | 상태 | 근거 문서·위치 | 담당자 | 목표 기한 | +|------|------|------|------|------|------| +| 선택 기준과 예외 승인 절차가 있다 | 5230 3.1.1.1 | | | | | +| 역할과 책임이 문서화돼 있다 | 5230 3.1.2.1, 18974 4.1.2.3 | | | | | +| 담당 인력과 예산이 확보돼 있다 | 5230 3.2.2.2 | | | | | +| 정책이 구성원에게 전파된다 | 5230 3.1.1.2 | | | | | +| 법률 자문 접근 경로가 있다 | 5230 3.2.2.3 | | | | | + +각 점검 항목을 자세히 다루는 가이드 섹션은 [자가점검](../../6-self-check/) 페이지의 표에서 +링크로 연결돼 있다. + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/artifacts/2-policy-templates/_index.md b/content/ko/guide/finance-oss-guide/artifacts/2-policy-templates/_index.md new file mode 100644 index 0000000000..e9b0494a6c --- /dev/null +++ b/content/ko/guide/finance-oss-guide/artifacts/2-policy-templates/_index.md @@ -0,0 +1,186 @@ +--- +title: "정책·절차 템플릿" +linkTitle: "정책·절차 템플릿" +weight: 20 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "정책", "템플릿", "망분리"] +description: > + 금융 변형 오픈소스 정책, 반입 절차서, 사용 승인 양식, 망분리 예외 자체 위험평가서의 + 골격을 제공한다. 조직에 맞게 채워 쓴다. +--- + +여기 담은 양식은 금융권 고유 항목을 보강한 골격이다. 일반 오픈소스 정책과 프로세스 양식은 +기존 [정책·절차 템플릿](../../../templates/) 가이드를 쓰고, 금융권에서 추가로 필요한 반입 +통제, 망분리 예외 위험평가, 외주 SBOM 요구는 아래 양식으로 채운다. + +{{% alert title="활용 안내" color="info" %}} +아래 골격은 그대로 쓰는 완성본이 아니라 채워 넣을 틀이다. 대괄호로 표시한 부분은 조직 +상황에 맞게 바꾼다. 발행 전 사내 법무·보안 검토를 거친다. +{{% /alert %}} + +## 금융 오픈소스 정책 (보강 항목) + +기존 오픈소스 정책에 금융권 고유 항목을 더한다. 아래는 정책에 포함할 항목의 골격이다. + +```text +1. 목적과 적용 범위 + - 배포 소프트웨어와 사내 운영 시스템을 모두 포함한다. + - 폐쇄망과 망분리 예외 구간을 구분해 적용한다. + +2. 식별 + - 신규·레거시·외주 산출물의 오픈소스를 SBOM으로 식별한다. + +3. 이슈 파악 및 해결 + - 취약점 심각도별 대응 기한: [조직이 정한 기한]. + - 외부 배포 시 GPL 계열 소스 공개 정책: [정책 내용]. + +4. 사용 승인 + - 승인 주체(오픈소스 검토 위원회) 구성과 권한. + - 위험 수준별 승인 단계(자동 승인 기준과 위원회 상정 기준). + +5. 관리 + - 운영 시스템 지속 모니터링과 정기 재평가 주기: [분기/반기 등]. + - 감사 증적 보관 기간: [조직이 정한 기간]. + +6. 망분리 예외 + - 자체 위험평가 의무와 재평가 주기. + +7. 역할과 책임, 예산, 법률 자문 접근, 정책 전파 +``` + +## 오픈소스 반입 절차서 (폐쇄망) + +폐쇄망에 오픈소스를 들여오는 절차의 골격이다. 자세한 설명은 [폐쇄망 +운영](../../0-closed-network/#반입-통제)을 참고한다. + +```text +반입 신청 + - 신청자, 대상 오픈소스와 버전, 용도, 반입 사유 + +외부 구간 검증 + - 공식 배포처 확인, 체크섬 대조(무결성) + - 악성코드 검사 + - SBOM 생성 + - 취약점 사전 점검 + +반입 승인 + - 검증 결과 검토, 승인 여부 결정 + - 승인자, 승인 일시 기록 + +내부 이관 + - 망간 자료전송, 내부망에서 해시 재확인 + - 사내 미러 등록(SBOM 함께 등록) + +기록 보관 + - 위 전 과정을 감사 증적으로 보관 +``` + +## 사용 승인 신청·검토 양식 + +```text +[신청] + - 신청자 / 소속 / 신청일 + - 대상 오픈소스 / 버전 / 라이선스 + - 사용 용도 / 배포 여부(대외 배포 / 사내 운영) + - 첨부: SBOM, 취약점 점검 결과 + +[검토] (오픈소스 검토 위원회) + - 법무: 라이선스 의무·계약·권리 귀속 검토 의견 + - 보안: 취약점·공급망·유지보수 상태 검토 의견 + - 기술: 적합성·대체 가능성 검토 의견 + +[결정] + - 승인 / 조건부 승인(조건: ___) / 반려 + - 결정자 / 결정일 / 근거 +``` + +{{% alert title="기재 예시 (가상 사례)" color="info" %}} +아래는 양식을 어떻게 채우는지 보여 주는 가상 사례다. OO은행과 등장 시스템·일자는 모두 +지어낸 것으로, 실존 기관·시스템과 무관하다. +{{% /alert %}} + +```text +[신청] + - 신청자: 김OO / 디지털채널개발팀 / 2026-05-12 + - 대상 오픈소스: Apache Kafka / 3.9.x / Apache-2.0 + - 사용 용도: 사내 이벤트 스트리밍(거래 알림 적재) / 사내 운영(비배포) + - 첨부: kafka-3.9.sbom.json, 취약점 점검 결과(심각 0, 높음 0) + +[검토] (오픈소스 검토 위원회, 2026-05-19) + - 법무: Apache-2.0, 비배포 사용으로 고지 의무 없음. 이상 없음. + - 보안: 알려진 심각 취약점 없음. 사내 미러 경유 반입 확인. 이상 없음. + - 기술: 기존 메시징 표준과 부합. 운영팀 운영 역량 확보 확인. + +[결정] + - 조건부 승인 (조건: 운영 시스템 SBOM을 Dependency-Track에 등록해 지속 모니터링 대상에 포함) + - 결정자: 오픈소스 검토 위원회 / 2026-05-19 / 검토 의견 3건 종합 +``` + +## 망분리 예외 자체 위험평가서 + +전자금융감독규정 개정(2025-02-05 시행)에 따라 고유식별정보와 개인신용정보를 처리하지 않는 +연구·개발 목적 업무에 망분리 예외를 적용할 때 작성한다. 자세한 설명은 [폐쇄망 운영의 자체 +위험평가](../../0-closed-network/#망분리-예외-시-자체-위험평가)를 참고한다. + +```text +1. 대상 업무 + - 업무명 / 시스템명 + - 연구·개발 목적 해당 여부와 판단 근거 + - 고유식별정보·개인신용정보 미처리 확인 + +2. 사용 오픈소스 + - SBOM(대상 구간에서 쓰는 오픈소스 목록) + - 취약점·라이선스 위험 평가 + +3. 추가 위험과 통제 + - 인터넷 연결로 추가되는 위험 + - 망분리 대체 정보보호통제 적용 내역 + - 반입 검증을 대신할 보안 통제 + +4. 이행 확인과 재평가 + - 통제 이행 확인 방법 + - 재평가 주기: [조직이 정한 주기, 통상 연 1회 이상] + +5. 검토와 승인 + - 작성자 / 작성일 + - 검토: 정보보호 부서, 오픈소스 관리 조직(위험 정보 확인) + - 승인: 정보보호위원회 또는 정보보호최고책임자(CISO) / 승인일 +``` + +{{% alert title="기재 예시 (가상 사례)" color="info" %}} +아래는 양식을 어떻게 채우는지 보여 주는 가상 사례다. OO은행과 등장 업무·일자는 모두 지어낸 +것으로, 실존 기관·시스템과 무관하다. +{{% /alert %}} + +```text +1. 대상 업무 + - 업무명: 사기거래 탐지 모델 연구 / 시스템명: FDS 연구 검증 환경 + - 연구·개발 목적 해당: 예 — 운영 서비스와 분리된 모델 연구·검증 전용 환경 + - 고유식별정보·개인신용정보 미처리: 확인 — 비식별 처리된 표본 데이터만 사용 + +2. 사용 오픈소스 + - SBOM: fds-research-env.sbom.json (Python 계열 187개 컴포넌트) + - 위험 평가: 심각 취약점 0건, 카피레프트 라이선스 0건(전부 Apache-2.0·BSD·MIT) + +3. 추가 위험과 통제 + - 추가 위험: 외부 패키지 저장소 직접 접근으로 인한 미검증 컴포넌트 유입 + - 대체 정보보호통제: 망분리 대체 정보보호통제 기준에 따른 단말 통제·접근 기록 + - 보안 통제: 사내 미러 우선 사용, 주 1회 환경 전체 취약점 스캔 + +4. 이행 확인과 재평가 + - 이행 확인: 분기별 통제 운영 점검(정보보호 부서) + - 재평가 주기: 연 1회 및 환경 구성 변경 시 + +5. 검토와 승인 + - 작성자: 박OO(FDS연구팀) / 2026-04-02 + - 검토: 정보보호 부서(2026-04-09), 오픈소스 관리 조직(SBOM·위험 평가 확인) + - 승인: 정보보호위원회 / 2026-04-16 +``` + +이 평가서는 [사용 승인](../../4-approve/#망분리-예외-시-자체-위험평가)의 승인 근거가 되고, +[관리](../../5-manage/#정기-재평가)에서 정기적으로 갱신한다. + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/artifacts/3-audit-evidence/30th-s3-key-questions.png b/content/ko/guide/finance-oss-guide/artifacts/3-audit-evidence/30th-s3-key-questions.png new file mode 100644 index 0000000000..e596af8352 Binary files /dev/null and b/content/ko/guide/finance-oss-guide/artifacts/3-audit-evidence/30th-s3-key-questions.png differ diff --git a/content/ko/guide/finance-oss-guide/artifacts/3-audit-evidence/_index.md b/content/ko/guide/finance-oss-guide/artifacts/3-audit-evidence/_index.md new file mode 100644 index 0000000000..53d83a60ee --- /dev/null +++ b/content/ko/guide/finance-oss-guide/artifacts/3-audit-evidence/_index.md @@ -0,0 +1,69 @@ +--- +title: "감사 증적 목록" +linkTitle: "감사 증적 목록" +weight: 30 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "감사", "증적"] +description: > + 내외부감사와 금융감독원 정보기술 검사에서 요구되는 오픈소스 관리 증적을 체크리스트로 + 정리하고, 각 증적이 어느 활동에서 생성되고 어디에 보관되는지 명세한다. +--- + +금융권은 내외부감사와 금융감독원의 정보기술(IT) 검사에 대비해 오픈소스 관리 활동의 증적을 +보관해야 한다. 관리 단계의 점검 기록이 그대로 증적이 되므로, 따로 만들지 말고 평소 활동에서 +나오는 기록을 체계적으로 모은다. 자세한 맥락은 [관리](../../5-manage/#감사-증적-관리)를 참고한다. + +## 증적 체크리스트 + +아래 증적은 ISO/IEC 5230·18974의 입증자료와 겹친다. ISO 자가 인증을 준비하며 만든 문서가 +그대로 감사 증적이 된다. 보관 위치와 기간은 조직 규정에 맞게 정한다. + +| 증적 | 생성 활동 | 관련 ISO 입증자료 | 보관 위치(예시) | 비고 | +|------|------|------|------|------| +| 오픈소스 정책 문서와 개정 이력 | 거버넌스 | 5230 3.1.1.1 | 문서 관리 시스템 | 버전 이력 포함 | +| 역할·책임 문서, 담당자 지정 기록 | 거버넌스 | 5230 3.1.2.1, 3.2.2.1 | 문서 관리 시스템 | | +| SBOM과 갱신 이력 | 식별 | 5230 3.3.1.1, 3.3.1.2 | SBOM 관리 도구 | 시스템별 | +| 취약점 점검 결과 | 이슈 파악·해결 | 18974 4.3.2.1, 4.3.2.2 | 취약점 관리 도구 | 날짜별 | +| 취약점 조치 기록(조치 불필요 판단 포함) | 이슈 파악·해결 | 18974 4.3.2.2 | 취약점 관리 도구 | VEX 포함 | +| 라이선스 검토 기록 | 이슈 파악·해결 | 5230 3.3.2.1 | 문서 관리 시스템 | | +| 사용 승인 신청·검토·결정 기록 | 사용 승인 | 5230 3.1.5.1 | 승인 관리 도구 | 위원회 결정 근거 | +| 망분리 예외 자체 위험평가서 | 사용 승인 | (전자금융감독규정) | 문서 관리 시스템 | 정보보호위원회(CISO) 승인 이력, 재평가 이력 | +| 반입 승인 기록 | 폐쇄망 운영 | — | 문서 관리 시스템 | 검증 결과 포함 | +| 정기 재평가 결과 | 관리 | 18974 4.1.2.5 | 문서 관리 시스템 | 주기별 | +| 컴플라이언스 산출물(고지문 등) | 관리 | 5230 3.4.1.1, 3.4.1.2 | 배포 산출물 저장소 | 배포 소프트웨어 | +| 외주 계약의 오픈소스 요구 조항과 제출 SBOM | 사용 승인 | (전자금융감독규정 제21조 내부통제) | 계약 관리 시스템 | 전자금융보조업자 | + +## 보관·관리 원칙 + +증적은 만드는 것만큼 지키는 것이 중요하다. + +- 보관 기간을 정한다. 감사 주기와 규정 요구를 고려해 정하고, 전자금융거래 기록 보존 기간 등 + 규정상 보존 기간과 어긋나지 않는지 확인한 뒤, 산출물 보관 절차(ISO/IEC 5230 + 3.4.1.2)에 명시한다. +- 위변조를 막는다. 기록을 나중에 고칠 수 없는 방식(추가만 가능한 로그, 접근 통제)으로 남긴다. +- 추적할 수 있게 한다. 누가 언제 무엇을 했는지 알 수 있도록 기록에 행위자와 시각을 남긴다. +- 검사 대응을 미리 점검한다. 정기 재평가 때 증적이 빠짐없이 보관되는지 함께 확인한다. + +{{% alert title="현장 사례 — 카카오뱅크의 감사 대응" color="success" %}} +카카오뱅크는 KWG 30차 정기 미팅(2026-06)에서 금융감독원 IT리스크 계량평가와 경영실태평가, +한국은행의 연간 금융정보화 추진현황 조사, 예금보험공사 자료요청에 대응한 경험을 공유했다. +기관이 공통으로 묻는 것은 오픈소스 현황 관리 여부, 현황 전체 목록, 관리 인력 구성, 정책 +수립과 내규, 보안취약점 점검 절차의 다섯 가지로, 위 증적 체크리스트와 대부분 겹친다. + +![검사·자료요청에서 기관이 공통으로 확인하는 다섯 가지를 정리한 발표 슬라이드](./30th-s3-key-questions.png) + +*그림: 기관이 공통으로 확인하는 다섯 가지. 이민애(카카오뱅크) 발표자료 5쪽. 슬라이드 +이미지는 발표자 저작물로, 본문의 CC BY 4.0 적용 대상이 아니다.* + +지원이 끝난(deprecated) 컴포넌트의 활용 목적과 사유를 묻는 질의에는, 평소 남겨 둔 관리 +기록(사용 목적, 보안취약점 부재 확인)으로 답할 수 있었다. 오래된 컴포넌트의 존재 자체보다 +그것을 알고 관리하고 있다는 기록이 중요함을 보여 주는 사례다. 다만 기관마다 요구하는 +목록의 범위와 양식이 달라, SBOM을 갖춰도 요청 양식에 맞춰 변환하는 작업은 남는다. + +출처: 이민애(카카오뱅크), "금융회사로서의 오픈소스 관련 업무 대응 후기", [KWG 30차 미팅(2026-06) 발표자료](https://github.com/OpenChain-Project/OpenChain-KWG/releases/download/meeting-slides-2026/30th-session3-finance-oss-report.pdf). +{{% /alert %}} + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/artifacts/4-tool-recipe/_index.md b/content/ko/guide/finance-oss-guide/artifacts/4-tool-recipe/_index.md new file mode 100644 index 0000000000..c96aa56b34 --- /dev/null +++ b/content/ko/guide/finance-oss-guide/artifacts/4-tool-recipe/_index.md @@ -0,0 +1,132 @@ +--- +title: "도구 구축 레시피" +linkTitle: "도구 구축 레시피" +weight: 40 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "도구", "Dependency-Track", "폐쇄망"] +description: > + 폐쇄망 온프레미스 환경에서 SBOM 생성과 지속 취약점 감시를 구축하는 docker-compose 예제와 + 연동 절차다. cdxgen으로 SBOM을 만들어 Dependency-Track에 등록하는 흐름을 보여 준다. +--- + +이 레시피는 폐쇄망에서 SBOM(Software Bill of Materials) 생성과 지속 취약점 감시를 구축하는 +예제다. 빠른 출발점으로 기존 [cdxgen과 Dependency-Track 파이프라인 튜토리얼](../../../tools/8-cdxgen-dt/)을 +금융권 기준으로 정리했다. 특정 제품을 권하기보다, 오픈소스·온프레미스 도구로 구축하는 방법을 +보여 주는 것이 목적이다. + +{{% alert title="폐쇄망 전제" color="warning" %}} +아래 예제는 도구 이미지를 내려받는 단계를 포함한다. 폐쇄망에서는 이미지와 취약점 +데이터베이스를 외부에서 받아 사내 컨테이너 레지스트리와 미러로 옮긴 뒤 내부에서만 받도록 +구성한다. 반입 절차는 [폐쇄망 운영](../../0-closed-network/#반입-통제)을 참고한다. +{{% /alert %}} + +## Dependency-Track 구축 + +Dependency-Track은 SBOM을 등록해 두면 취약점 데이터베이스가 갱신될 때마다 영향받는 컴포넌트를 +자동으로 다시 평가한다. 운영 시스템의 지속 모니터링에 쓴다. 아래는 API 서버와 프런트엔드를 +함께 띄우는 docker-compose 예제다. + +```yaml +# docker-compose.yml +volumes: + dependency-track: + +services: + dtrack-apiserver: + image: dependencytrack/apiserver:latest + deploy: + resources: + limits: + memory: 12288m + reservations: + memory: 8192m + ports: + - "8081:8080" + volumes: + - "dependency-track:/data" + restart: unless-stopped + + dtrack-frontend: + image: dependencytrack/frontend:latest + depends_on: + - dtrack-apiserver + environment: + - API_BASE_URL=http://localhost:8081 + ports: + - "8080:8080" + restart: unless-stopped +``` + +폐쇄망에서는 `image` 값을 사내 레지스트리 주소로 바꾼다. 예를 들어 `dependencytrack/apiserver:latest` +대신 `registry.internal/dependencytrack/apiserver:4.x`처럼 사내에 미러링한 이미지를 가리킨다. +버전 태그는 `latest` 대신 검증한 고정 버전을 쓰는 것이 안전하다. + +`API_BASE_URL`은 사용자의 브라우저가 API 서버를 호출할 때 쓰는 주소이므로, 사내 서버에 +올릴 때는 `localhost` 대신 그 서버의 호스트명으로 바꾼다(예: `http://dtrack.internal:8081`). + +띄운 뒤 접속해 첫 관리자 비밀번호를 바꾸고, SBOM 업로드에 쓸 API 키를 발급한다. + +```bash +# 서비스를 올린다 +docker compose up -d + +# 상태를 확인한다 +docker compose ps +``` + +환경에 따라 `docker compose`(플러그인) 대신 `docker-compose`(하이픈) 명령을 써야 할 수 있다. +하이픈 명령(구버전 v1)은 예제의 `deploy.resources` 메모리 제한을 무시하므로, 제한을 +적용하려면 `--compatibility` 옵션을 함께 준다. + +![구축 후 Dependency-Track 대시보드 화면](./dt-dashboard.png) + +*그림: 구축을 마치고 SBOM을 등록하면 보게 되는 Dependency-Track 대시보드. 화면은 +[cdxgen·Dependency-Track 튜토리얼](../../../tools/8-cdxgen-dt/)의 캡처를 재사용했다. +계정 설정과 API 키 발급의 단계별 화면도 그 튜토리얼에 있다.* + +## SBOM 생성과 등록 연동 + +cdxgen으로 프로젝트의 SBOM을 만들고, 그 결과를 Dependency-Track에 업로드한다. 업로드된 SBOM은 +이후 취약점 데이터베이스가 갱신될 때마다 자동으로 재평가된다. cdxgen은 언어 생태계에 따라 +의존성을 해석하면서 빌드 도구와 패키지 저장소에 접근하므로, 폐쇄망에서는 npm·Maven 등의 +저장소 설정이 사내 미러를 가리키도록 해 둔 상태에서 실행한다. + +```bash +# 1) cdxgen으로 CycloneDX 형식 SBOM을 생성한다 +# -r 은 하위 디렉터리의 여러 매니페스트를 재귀로 수집한다 +cdxgen --spec-version 1.6 -r -o sbom.json /path/to/project + +# 2) Dependency-Track 프로젝트에 SBOM을 업로드한다 +curl -X POST "http://localhost:8081/api/v1/bom" \ + -H "X-Api-Key: ${DT_API_KEY}" \ + -F "projectName=my-service" \ + -F "projectVersion=1.0.0" \ + -F "autoCreate=true" \ + -F "bom=@sbom.json" +``` + +cdxgen 최신 버전은 CycloneDX 1.7을 기본으로 생성하는데, Dependency-Track 버전에 따라 1.6까지만 +받는 경우가 있다. 업로드가 거부되면 위처럼 `--spec-version 1.6`을 지정해 형식을 맞춘다. +`autoCreate=true`는 같은 이름·버전의 프로젝트가 없으면 새로 만든다. 운영 시스템마다 프로젝트를 +두고 SBOM을 등록하면, 신규 취약점이 공개될 때 영향받는 시스템을 한곳에서 파악할 수 있다. 이 흐름은 +[관리](../../5-manage/#지속-취약점-모니터링)에서 다룬 지속 모니터링을 구현한 것이다. + +## 오프라인 취약점 데이터베이스 + +폐쇄망에서는 Dependency-Track이 참조하는 취약점 데이터 소스의 주소를 관리 화면에서 내부 +미러로 바꿔 구성한다. 데이터 소스별 미러 구성의 난도와 사전 검증, 명령줄 점검 도구(Grype, +Trivy)의 캐시 반입 방식은 +[폐쇄망 운영의 오프라인 취약점 관리](../../0-closed-network/#오프라인-취약점-관리)에서 다룬다. + +## 도구 선택 기준 + +이 레시피는 cdxgen과 Dependency-Track을 예로 들었으나, 같은 일을 하는 다른 오픈소스 도구로 +바꿔도 된다. 도구를 고를 때는 [폐쇄망 운영](../../0-closed-network/#폐쇄망에-맞는-도구-선택)에서 +제시한 기준(온프레미스 설치, 오프라인 데이터베이스 갱신, 표준 형식 입출력, 도구 자체의 라이선스)을 +따른다. 도구별 설치와 +사용법은 [도구 페이지](../../../tools/)에 정리돼 있다. + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/finance-oss-guide/artifacts/4-tool-recipe/dt-dashboard.png b/content/ko/guide/finance-oss-guide/artifacts/4-tool-recipe/dt-dashboard.png new file mode 100644 index 0000000000..4c29dc34dd Binary files /dev/null and b/content/ko/guide/finance-oss-guide/artifacts/4-tool-recipe/dt-dashboard.png differ diff --git a/content/ko/guide/finance-oss-guide/artifacts/_index.md b/content/ko/guide/finance-oss-guide/artifacts/_index.md new file mode 100644 index 0000000000..2ba781728d --- /dev/null +++ b/content/ko/guide/finance-oss-guide/artifacts/_index.md @@ -0,0 +1,32 @@ +--- +title: "산출물: 바로 쓰는 양식과 레시피" +linkTitle: "산출물" +weight: 80 +type: docs +categories: ["guide"] +tags: ["금융", "오픈소스", "템플릿", "워크북", "감사"] +description: > + 가이드 본문과 함께 제공하는 네 가지 실무 산출물을 모은다. 자가점검 워크북, 정책·절차 + 템플릿, 감사 증적 목록, 도구 구축 레시피다. +--- + +이 가이드는 본문과 함께 바로 쓸 수 있는 네 가지 산출물을 제공한다. 본문이 "무엇을 왜 +하는지"를 설명한다면, 산출물은 "그것을 어떤 양식으로 남기는지"를 채워 준다. 각 산출물은 +조직 상황에 맞게 고쳐 쓰는 것을 전제로 한다. + +| 산출물 | 쓰임 | +|------|------| +| [자가점검 워크북](./1-workbook/) | 점검 항목, ISO 입증자료, 충족 상태·담당자·기한을 한 시트로 묶어 자사 체계의 빈 곳을 찾는다 | +| [정책·절차 템플릿](./2-policy-templates/) | 금융 변형 정책, 반입 절차, 사용 승인 양식, 망분리 예외 자체 위험평가서의 골격을 제공한다 | +| [감사 증적 목록](./3-audit-evidence/) | 내외부감사와 감독 검사에서 요구되는 증적과 보관 위치를 체크리스트로 정리한다 | +| [도구 구축 레시피](./4-tool-recipe/) | 폐쇄망 온프레미스 SBOM·취약점 도구를 docker-compose로 구축·연동하는 예제를 제공한다 | + +{{% alert title="활용 안내" color="info" %}} +산출물은 기존 [정책·절차 템플릿](../../templates/) 가이드를 금융 맥락으로 보강한 것이다. +일반 실무 양식은 기존 템플릿을, 금융권 고유 항목(반입 통제, 망분리 예외 위험평가, 외주 +SBOM 요구)은 이 산출물을 함께 쓴다. +{{% /alert %}} + +--- + +*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.* diff --git a/content/ko/guide/iso5230_guide/_index.md b/content/ko/guide/iso5230_guide/_index.md index 66cb317260..f0e96d4da0 100644 --- a/content/ko/guide/iso5230_guide/_index.md +++ b/content/ko/guide/iso5230_guide/_index.md @@ -249,3 +249,10 @@ ISO/IEC 5230은 ISO/IEC 18974(보안 보증)·42001(AI 관리 시스템)과 함 세 표준의 관계, SC 42 패밀리 매핑, 동시 운영 시 공통 기반을 확인할 수 있다. {{% /alert %}} + +{{% alert title="금융권 담당자를 위한 안내" color="success" %}} +은행, 보험, 증권 등 금융권은 ISO/IEC 5230과 함께 금융분야 오픈소스 소프트웨어 활용·관리 +안내서(금융감독원·금융보안원)를 준거로 삼는다. 폐쇄망 운영, 망분리 규제 전환, 공급망 보안 +플랫폼, 감사 대응 같은 금융권 고유 맥락은 [금융분야 오픈소스 관리 실무 가이드](../finance-oss-guide/)에서 +다룬다. 이 가이드의 입증자료를 금융 절차와 연결한 대조표를 함께 제공한다. +{{% /alert %}} diff --git a/content/ko/guide/opensource_for_enterprise/2-policy/_index.md b/content/ko/guide/opensource_for_enterprise/2-policy/_index.md index 0de08f650b..062a59c56b 100644 --- a/content/ko/guide/opensource_for_enterprise/2-policy/_index.md +++ b/content/ko/guide/opensource_for_enterprise/2-policy/_index.md @@ -13,6 +13,12 @@ description: > **ISO/IEC 18974**: 4.1.1.1, 4.1.4.1, 4.1.4.2, 4.1.4.3, 4.2.1.1, 4.2.2.2, 4.2.2.3, 4.2.2.4 {{% /alert %}} +{{% alert title="금융권이라면" color="info" %}} +금융권은 정책에 폐쇄망 반입 통제, 망분리 예외 자체 위험평가, 외주·전자금융보조업자의 SBOM +제출 요구 같은 고유 항목을 더해야 한다. 금융 변형 정책의 골격과 절차는 [금융분야 오픈소스 +관리 실무 가이드](../../finance-oss-guide/)에서 다룬다. +{{% /alert %}} + ## 1. 오픈소스 정책 문서화 기업은 공급 소프트웨어 개발, 서비스, 배포에 관여하는 조직이 올바르게 오픈소스를 활용하기 위한 원칙으로 구성된 오픈소스 정책을 수립하여 문서화하고 이를 조직 내 전파해야 합니다.