042. SABSA (Sherwood Applied Business Security Architecture)

⚠️ 이 문서는 조직의 비즈니스 요구사항으로부터 출발하여 논리적, 물리적, 그리고 컴포넌트 레벨의 보안 통제까지 수직적으로 정렬시키는 엔터프라이즈 보안 아키텍처 프레임워크인 SABSA를 다룹니다.

핵심 인사이트 (3줄 요약)

1. 본질: SABSA는 Zachman Framework의 6x6 매트릭스 구조(6하원칙 × 6개 관점)를 차용하되, 그 속을 순수하게 '보안(Security)'과 '위험 관리(Risk Management)' 관점으로 100% 특화시킨 비즈니스 주도형 보안 아키텍처이다.
2. 가치: 보안을 'IT 부서의 귀찮은 통제'가 아닌 '비즈니스 목표 달성을 위한 조력자'로 재정의하며, 최상위 비즈니스 전략이 최하위 방화벽 룰이나 암호화 알고리즘까지 논리적으로 연결되는 완벽한 추적성(Traceability)을 제공한다.
3. 융합: SABSA 매트릭스의 빈칸을 채우기 위한 프로세스나 개발 방법론으로는 TOGAF나 ITIL을 융합하여 사용하며, 클라우드 이전이나 제로 트러스트 도입 시 전사적인 보안 청사진을 그리는 표준 모델로 널리 쓰인다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

과거의 정보보안은 비즈니스 부서에서 새로운 서비스를 기획하면, 막판에 IT 보안팀이 들어와 방화벽 포트를 뚫고 패스워드 정책을 끼워 넣는 사후 덧대기(Bolt-on) 방식이었다. 이렇게 되면 보안이 비즈니스의 발목을 잡거나, 반대로 보안에 심각한 구멍이 생겨도 아무도 책임지지 않는 사일로(Silo) 현상이 발생한다.

**SABSA (Sherwood Applied Business Security Architecture)**는 이를 타파하기 위해 1995년 존 셔우드(John Sherwood)가 제안한 프레임워크다. 비즈니스의 'Why(왜 보호해야 하는가)'에서 출발하여 논리적, 물리적 설계(How, What)로 하향식(Top-Down) 전개를 강제함으로써, 모든 보안 투자가 비즈니스 요구사항과 1:1로 정렬되도록 만든다.

📢 섹션 요약 비유: 집을 다 짓고 나서 도둑이 들까 봐 급하게 창문에 쇠창살을 박는 것이 과거의 보안이라면, SABSA는 애초에 도면을 그릴 때부터 가족의 안전(비즈니스 목표)을 고려해 방탄유리와 이중 잠금장치를 설계에 녹여 넣는 '보안 내재화 설계도'입니다.

Ⅱ. SABSA 프레임워크 구조 (6×6 매트릭스)

SABSA는 Zachman Framework와 마찬가지로 세로축에 6하원칙(What, Why, How, Who, Where, When)을, 가로축에 6가지 관점을 둔다.

1. 6가지 관점 (Architectural Layers)

1. Contextual (비즈니스 뷰): 경영진의 관점. 비즈니스의 목표, 위험 허용도, 핵심 자산 목록.
2. Conceptual (아키텍트 뷰): 보안 최고 책임자의 관점. 보안 전략, 위험 관리 프레임워크 설계.
3. Logical (설계자 뷰): 정보보안 설계자의 관점. 정보의 흐름, 보안 정책 매핑 (예: 접근 통제 모델).
4. Physical (빌더 뷰): 시스템 엔지니어의 관점. 물리적 데이터 센터, 네트워크 세그멘테이션, 보안 솔루션 배치.
5. Component (하청업체 뷰): 개발자의 관점. 구체적인 암호화 알고리즘(AES-256), WAF 룰셋, 코드 레벨의 방어.
6. Operational (운영자 뷰): 관제 센터(SOC)의 관점. 보안 모니터링, 사고 대응(IR), 패치 관리.

2. 양방향 추적성 (Traceability)

SABSA의 핵심은 **'상하위 계층 간의 추적성'**이다.

• 하향식 (Top-Down): 경영진이 "고객 개인정보 보호(Contextual-What)"를 지시하면, 이는 논리적 계층의 "DB 암호화 설계(Logical-How)"로 이어지고, 컴포넌트 계층의 "AES-256 적용(Component-How)"으로 강제된다.
• 상향식 (Bottom-Up): 운영자가 방화벽 룰을 추가할 때, "이 룰(Operational)은 어떤 비즈니스 목표(Contextual)를 보호하기 위해 존재하는가?"를 역추적하여 증명할 수 있다.

📢 섹션 요약 비유: 6층짜리 결재 서류철입니다. 6층(경영진)이 "현금 수송 보안 강화"라는 도장을 찍으면, 5층은 "수송차량 경로 설계"를, 1층(경비원)은 "가스총 장전"을 준비합니다. 1층의 경비원은 자신이 왜 가스총을 차고 있는지 6층의 목표를 명확히 알고 있습니다.

Ⅲ. 실무 시나리오: 제로 트러스트 기반 클라우드 이전 설계

전통적인 망 분리 환경(On-Premise)에서 운영되던 금융 시스템을 퍼블릭 클라우드(AWS/Azure)로 이전하며 제로 트러스트를 도입할 때 SABSA를 활용한 의사결정 사례다.

• Contextual (Why): 클라우드에서도 금융 규제(전자금융감독규정)를 완벽히 준수하면서 원격 근무자의 업무 효율성을 높여야 한다.
• Conceptual (How): 경계 기반 보안을 폐기하고, "모든 접근은 불신한다(Zero Trust)"는 개념적 보안 아키텍처를 수립한다.
• Logical (Who/Where): 논리적인 '마이크로 세그멘테이션'을 설계하고, '사용자 신원'과 '디바이스 무결성'을 기반으로 하는 동적 접근 통제(ABAC) 맵을 그린다.
• Physical (What/Where): AWS Security Group, 클라우드 네티브 IAM, ZTNA(Zero Trust Network Access) 게이트웨이를 물리적 네트워크 토폴로지에 배치한다.
• Component (How): 구체적인 인증 프로토콜(SAML 2.0, OIDC)과 토큰 만료 시간(15분), mTLS(상호 TLS) 인증서 발급 코드를 짠다.

이처럼 SABSA 매트릭스를 채워나가면, 개발자가 mTLS를 귀찮다고 빼먹으려 할 때 "이것이 빠지면 1층의 비즈니스 목표인 규제 준수에 실패한다"는 명백한 근거로 설득할 수 있다.

📢 섹션 요약 비유: 건물을 짓기 전 "왜 클라우드로 이사 가는가?(Contextual)"부터 "출입문 키패드는 어떤 모델을 쓸 것인가?(Component)"까지 모든 의사결정이 거미줄처럼 이어져, 나중에 불필요한 공사를 하거나 중요한 보안 장치를 빼먹는 실수를 원천 차단합니다.

Ⅳ. 유사 프레임워크와의 융합 및 한계

SABSA는 완벽한 '구조도(What)'를 제공하지만, 그 구조도를 '어떤 순서로 그릴 것인가(How to do)'에 대한 방법론은 부족하다.

• 한계점: 철저한 하향식 모델이다 보니 초기 도입 시 문서화의 부담이 극심하며, 민첩성이 생명인 현대의 애자일(Agile) 조직이나 스타트업 환경에서는 무겁고 굼뜬 프레임워크로 여겨질 수 있다.

📢 섹션 요약 비유: SABSA가 '완성된 집의 청사진'이라면, TOGAF는 '포크레인을 부르고 시멘트를 붓는 공사 순서도'입니다. 청사진만으로는 집을 지을 수 없으니, 반드시 공사 순서도(TOGAF)와 짝을 이뤄야 멋진 보안 빌딩이 완성됩니다.

📌 관련 개념 맵

• 상위 개념: 보안 아키텍처 (Security Architecture)
• 기반/유래 모델: Zachman Framework
• 융합/상호보완 모델: TOGAF (The Open Group Architecture Framework), ITIL
• 관련 구현 개념: 제로 트러스트 아키텍처(ZTA), 마이크로 세그멘테이션, 보안 내재화(Security by Design)

👶 어린이를 위한 3줄 비유 설명

1. 거대한 성을 지킬 때, 왕은 "금고를 지켜라!"라고 명령하고, 대장장이는 "단단한 자물쇠"를 만들고, 병사는 "경계"를 섭니다.
2. 각자 생각하는 '보안'이 다르기 때문에, 왕의 명령이 병사의 행동까지 똑같이 이어지도록 6단계로 나눈 완벽한 계획표가 필요해요.
3. 이 6단계 계획표의 이름이 바로 SABSA랍니다. 이 표를 쓰면 막내 병사도 자기가 왜 여기서 창을 들고 서 있는지 정확히 알 수 있어요!