SEAL 인증이란? 암호화폐 운영 보안 보장

SEAL Certifications는 Security Alliance(SEAL)가 공개한 오픈소스 운영 보안 인증 프로그램입니다. 현재 v0.0.1 기준선은 통제 항목이라고 부르는 99개의 구체적인 운영 요구사항을 6개 모듈로 구성하며, 암호화폐 프로토콜과 관련된 인력, 계정, 서명자, 도메인, 인프라, 재무 운영 절차, 대응 역량을 다룹니다 [1, 2].

BlockSec은 이 프로그램의 초기 공인 평가기관 중 하나이며, 현재 아시아에 본사를 둔 유일한 공인 평가기관입니다. SEAL 공인 평가기관으로서 저희는 고객과 함께 범위를 정하고, 선정된 통제 항목과 증거를 평가하고, 미비점을 문서화하며, 정해진 범위의 요구사항이 충족되었는지 판단합니다. 요구사항이 충족되면 SEAL 공인 자격에 따라 온체인 증명을 발급합니다 [4].

이 글에서는 조직이 SEAL 인증을 추진하는 이유, 인증 결과의 의미, 적용될 수 있는 모듈, 저희의 평가 방식, 팀이 평가 참여를 준비하는 방법을 설명합니다.

1. SEAL 인증을 추진하는 이유

SEAL에 따르면, 이 프레임워크의 근거는 암호화폐 분야에서 익스플로잇의 주된 원인이 스마트 계약 취약점에서 운영상의 실패로 옮겨갔다는 점입니다 [1]. 따라서 평가에서는 서명자, 다중 서명, 도메인, 자격 증명, 인프라 모니터링, 사고 대응과 관련된 통제 항목에 주목합니다. SEAL 인증 평가는 이러한 통제가 실제로 작동하고 이를 증거로 입증할 수 있는지 확인하여, 암호화폐 조직이 어떤 통제 항목이 기준선을 충족하고 어디에 미비점이 남아 있는지 독립적으로 파악할 수 있게 합니다 [1, 3].

SEAL 인증은 하나의 보증 질문에 답합니다. 합의된 범위 내의 운영 통제 항목이 독립적으로 평가되어, 공개된 암호화폐 분야 맞춤형 운영 보안 기준선을 충족하는 것으로 확인되었는가? 프로토콜, 거래소, 결제 플랫폼, 수탁기관과 같은 암호화폐 조직은 투자자, 상장 심사팀, 규제 준수 관계자, 내부 거버넌스 기구, 보험사 또는 실사 검토자가 운영 통제에 관한 독립적인 증거를 요구할 때 이러한 보증이 필요할 수 있습니다. 결과에는 평가한 모듈과 경계가 명시되며, 해당 범위가 기준선을 충족했는지가 기록됩니다 [5, 6].

이러한 보증의 범위는 관련 보안 활동과 비교하면 더 명확해집니다. 평가에서는 저장소, CI/CD, 인프라 통제와 관련된 코드 운영 증거인 권한, 브랜치 보호 설정, 코드 검토 기록, 보안 스캔 결과, 파이프라인 통제, 인프라 구성을 검토할 수 있습니다 [7]. 하지만 구현 취약점을 찾거나 프로토콜 로직이 올바른지 판단하기 위해 소스 코드를 검토하지는 않습니다 [1]. 이러한 목적과 관련 목적은 다른 보안 활동에서 다룹니다. 코드 감사는 소스 코드의 구현 취약점과 프로토콜 로직 결함을 평가하고, 침투 테스트는 합의된 환경에서 악용 가능한 경로를 재현할 수 있는지 평가합니다. 버그 바운티는 외부에서 발견한 문제를 지속적으로 접수하는 경로를 제공하며, 지속적 모니터링은 상시 탐지와 대응을 지원합니다.

SEAL 인증은 독립적인 평가 프로그램입니다. 인증은 선정된 범위가 SEAL의 요구사항을 충족할 때만 발급됩니다 [6]. 코드 감사, 침투 테스트, 버그 바운티, 지속적 모니터링은 별개의 활동이며, 어느 것도 인증의 필수 선행 조건이 아닙니다.

더 폭넓은 보증 표준에도 같은 구분이 적용됩니다. SEAL의 의견 요청 게시물에 따르면, SOC 2와 ISO 27001은 여전히 가치가 있고 궁극적으로 많은 조직에 필요하지만, 상당한 온체인 자산을 관리하는 소규모 분산 팀과 같은 암호화폐 분야 특유의 운영 모델을 염두에 두고 설계되지는 않았습니다 [5]. SEAL 프레임워크는 암호화폐 운영 통제를 위한 더 집중적인 출발점을 제공하며, 이러한 폭넓은 표준과 함께 활용할 수 있습니다.

2. 인증으로 입증되는 것

SEAL 인증 결과는 평가를 위해 선정된 운영 통제 항목, 모듈, 경계에 적용됩니다. 선정된 통제 항목이 SEAL의 요구사항을 충족하면 BlockSec과 같은 SEAL 공인 평가기관이 공인 자격에 따라 Ethereum Attestation Service를 통해 해당 SEAL 배지와 함께 온체인 증명을 발급합니다 [4]. 증명은 공개되지만, 상세 평가 보고서와 증거는 평가기관과 고객 사이에서 기밀로 유지됩니다 [1]. 아래 표는 통과 결과가 뒷받침하는 결론과 범위 밖에 있는 주장을 구분합니다.

이러한 한계는 발급 후에도 계속 적용됩니다. SEAL 증명은 프로토콜에 보안 문제가 없음을 의미하지 않습니다 [1]. 증명은 유효 기간이 제한되어 있고 정기적인 재평가가 필요하며, 부적합 상태가 지속되면 철회될 수 있습니다. SEAL은 고정된 유효 기간을 공개하지 않습니다 [1].

3. 프레임워크가 다루는 범위

6개 모듈은 개별적으로 또는 함께 평가할 수 있습니다. 현재 기준선에는 99개의 통제 항목이 있습니다 [1, 2]. 적용될 수 있는 경우 열은 모듈 정의를 바탕으로 작성한 참고 안내이며, SEAL의 공식 범위 설정 규칙이 아닙니다. 최종 범위는 평가 과정에서 고객과 확인합니다.

모듈을 개별적으로 평가하더라도 운영상으로는 서로 연결되어 있습니다. DevOps 및 인프라, DNS 및 등록기관의 일부 통제 항목은 신원 및 계정에 정의된 계정 보안 관행에 의존합니다. 사고 대응 요구사항도 사고 중 다중 서명 서명자를 조율하거나 계정을 복구하는 경우처럼 여러 모듈에 나타납니다 [2].

이러한 모듈 간 참조는 범위 내 통제 항목에 필요한 증거에 영향을 주지만, 참조된 모듈을 자동으로 인증하거나 필수 인증 순서를 만들거나 평가 범위를 확대하지는 않습니다. DNS 통제 항목이 계정 보안 관행에 의존한다는 이유만으로 DNS 및 등록기관 증명이 신원 및 계정 증명이 되지는 않습니다. 증명은 범위에 명시된 모듈과 경계에만 적용됩니다 [1, 6].

4. 평가 진행 방식

SEAL은 프레임워크를 유지 관리하고 인증 프로그램을 운영합니다. SEAL 공인 평가기관으로서 저희는 고객별 평가를 다음 다섯 단계로 진행합니다 [1, 4]:

그림 1. SEAL 인증 평가는 합의된 범위에서 시작하여 증거 검토, 미비점 개선, 재평가를 거친 뒤 증명 발급으로 이어집니다.

1. 범위 설정. 고객과 함께 어떤 모듈, 통제 항목, 시스템, 운영 활동, 조직의 경계를 범위에 포함할지 합의합니다.

2. 증거 수집. 고객은 범위 내 통제 항목이 어떻게 설계되고, 담당자가 지정되고, 운영되고, 검토되는지 보여주는 자료를 제공합니다.

3. 평가. 해당 증거를 SEAL의 공개 요구사항에 비추어 평가하고, 누락되었거나 충분하지 않은 입증 자료를 확인합니다.

4. 필요시 미비점 개선. 합의된 범위가 기준선을 충족하지 못하면 미비점 보고서를 제공합니다. 고객은 확인된 미비점을 개선하고, 재평가를 위해 갱신된 증거를 제출합니다.

5. 인증. 합의된 범위가 기준선을 충족하면 SEAL 공인 자격에 따라 공식 온체인 증명을 발급합니다.

증거 수집과 평가는 함께 이루어집니다. 고객이 입증 자료를 제공하면 BlockSec은 그 자료가 각 통제 항목이 실제로 작동함을 보여주는지 평가합니다. SEAL의 인증 가이드라인은 입증 증거를 다섯 범주로 나눕니다. 아래에는 가이드라인과 모듈 기준선의 예시를 함께 요약했습니다 [2, 3, 7]:

BlockSec은 이러한 증거를 바탕으로 범위 내 각 통제 항목의 상태를 구현 완료, 부분 구현, 미구현 또는 근거가 제시된 해당 없음(N/A)으로 기록합니다. 공식 인증을 받으려면 합의된 범위의 통제 항목이 구현 완료 상태이거나, 증거로 뒷받침되는 근거를 제시하여 N/A로 인정되어야 합니다. 따라서 기초 평가는 통제 항목별로 이루어지지만, 합의된 전체 범위에 대한 최종 인증 결정은 통과 또는 실패로 나뉩니다 [3, 6].

5. 준비 방법

SEAL 인증 평가를 시작하기 전에 다음 네 가지를 준비하세요.

1. 제안 범위: 인증을 통해 입증하려는 내용과 관련된 모듈, 시스템, 법인 또는 조직 단위, 팀, 경계.

2. 통제 항목별 자체 평가: 각 요구사항이 구현 완료, 부분 구현, 미구현 또는 N/A 중 어디에 해당하는지와 각 판단의 근거.

3. 증거 목록: 제안 범위에 연결한 기존 절차, 운영 기록, 테스트 결과, 담당자 기록, 기술 자료.

4. 담당자 지정: 범위 결정, 증거 수집, 미비점 개선 조율을 담당할 사람.

프레임워크와 체크리스트가 공개되어 있으므로 팀은 공식 평가를 시작하기 전에도 이 작업에 착수할 수 있습니다. 자체 평가는 문서화되지 않은 절차, 부족한 운영 증거, 담당자가 지정되지 않은 통제 항목, 이미 파악된 개선 과제를 찾는 데 유용합니다. 다만 이는 내부 점검 단계일 뿐, 독립적으로 검증되지 않으며 SEAL 증명을 발급하지도 않습니다 [1, 3].

이 네 가지는 초기 범위 설정에 도움이 됩니다. 상세한 자료 요청은 선정한 모듈에 따라 달라집니다. 위 모듈명은 주제 영역을 정의할 뿐, 필수 인증 순서를 뜻하지 않습니다. 모듈별 통제 항목에 관한 상세 안내는 별도 글로 순차적으로 제공할 예정입니다. 모듈 선택, 증거 준비 상태, 평가 범위를 논의하려면 문의해 주세요 [需实证:CONTACT_OR_RELEVANT_PAGE_URL].

참고 자료

1. Security Alliance, SEAL 인증 프레임워크: 개요. 프레임워크의 근거, 모듈, 독립적인 범위 설정, 평가 절차, 자체 평가, 증명과 배지, 기밀 유지, 재평가, 철회. https://frameworks.securityalliance.org/certs/overview/

2. Security Alliance, 모든 인증 항목 내보내기(XLSX). 현재 모듈별 통제 항목 수와 모듈 간 참조. SEAL 인증 프레임워크 개요에서 제공하는 공식 내보내기 자료와 대조하여 확인함. 2026년 9월 열람. https://frameworks.securityalliance.org/certs/overview/

3. Security Alliance, 인증 가이드라인. 통제 항목별 상태, 인증 기준, 증거 범주. https://frameworks.securityalliance.org/certs/certification-guidelines/

4. Security Alliance, 평가기관 공인 및 SEAL Certifications. 공인 절차, 평가기관의 책임, 프로그램 현황, 현재 공개된 파트너 정보. https://frameworks.securityalliance.org/certs/certified-partners/ 및 https://securityalliance.org/our-work/certifications

5. Security Alliance Radar, 의견 요청: SEAL Certifications. 계약 보안 성숙도, SOC 2와 ISO 27001의 위치, 모듈 구성, 검증 가능성의 근거. https://radar.securityalliance.org/request-for-comments-seal-certifications/

6. Security Alliance Radar, SEAL Certifications: 서비스 시작(Isaac Patka, 2026년 6월 2일). 6개 영역 개요와 합의된 범위 전체에 대한 단일 통과/실패 결정. https://radar.securityalliance.org/seal-certifications-auditor-accreditations-protocol-assessments/

7. Security Alliance, SFC: DevOps 및 인프라. 저장소 권한, 브랜치 보호, 코드 검토 및 스캔 통제, CI/CD, 공급망 관리, 인프라 구성에 관한 공개 기준선. https://frameworks.securityalliance.org/certs/sfc-devops-infrastructure/