보안 설계 원칙

Secure Design Principles; 보안 설계 원칙, 안전한 설계 원칙
시스템을 설계·구현하는 단계부터 보안을 내재화하기 위해 따르는 공통 원칙의 묶음. 최소 권한, 심층 방어, 안전한 기본값, 안전한 실패, 직무 분리, 단순성, 제로 트러스트, 개인정보 보호 중심 설계, 공동 책임 등이 포함된다

보안 설계 원칙은 특정 제품이나 기술이 아니라 "어떻게 설계하면 결함이 적고, 결함이 있어도 피해가 작은가"에 대한 경험 법칙이다. 운영 단계에서 덧붙이는 통제는 비용이 크고 우회되기 쉽기 때문에, 요구사항·아키텍처 단계에서 원칙을 적용해 위험을 줄이는 것이 가장 경제적이다. 출발점은 1975년 솔처(Jerome H. Saltzer)와 슈뢰더(Michael D. Schroeder)가 발표한 논문 "The Protection of Information in Computer Systems"의 8가지 설계 원칙이며, 오늘날 NIST SP 800-160 Vol. 1(시스템 보안 공학), 제로 트러스트 아키텍처(NIST SP 800-207), CISA의 Secure by Design 지침 등이 이 원칙들을 현대 환경에 맞게 다시 정리하고 있다.

CISSP 출제 기준에서는 도메인 3의 첫 항목(3.1)이 "보안 설계 원칙을 적용한 엔지니어링 프로세스를 조사·구현·관리한다"이며, 위협 모델링, 최소 권한, 심층 방어, 안전한 기본값, 안전한 실패, 직무 분리(SoD), 단순하고 작게 유지, 제로 트러스트 또는 신뢰하되 검증, 개인정보 보호 중심 설계, 공동 책임, SASE를 하위 주제로 든다. 이 문서는 각 원칙을 짧게 정리하고 자세한 내용은 개별 문서로 연결한다.

솔처와 슈뢰더의 8원칙

1975년 논문은 "보호 메커니즘에 특히 적용되는 설계 원칙의 여덟 가지 예"를 제시했다. 50년이 지난 지금도 대부분의 보안 설계 원칙은 이 표의 변형이다.

원칙 (원문)	뜻	오늘날의 예
메커니즘의 경제성(Economy of mechanism)	설계를 가능한 한 단순하고 작게 유지한다. 작아야 한 줄씩 검사할 수 있다	작은 보안 커널, 공격 표면 축소, 단순성
안전한 기본값(Fail-safe defaults)	접근 결정은 배제가 아니라 허가에 근거한다. 기본 상태는 "접근 없음"이다	기본 거부(default deny) 방화벽 규칙, 화이트리스트
완전한 중재(Complete mediation)	모든 객체에 대한 모든 접근을 매번 권한 검사한다. 검사 결과를 캐시해 재사용하는 것을 의심한다	참조 모니터, 제로 트러스트의 요청 단위 검증
공개 설계(Open design)	설계는 비밀이어서는 안 된다. 보호는 공격자의 무지가 아니라 키·비밀번호 보유에 의존해야 한다	공개 암호 알고리즘(케르크호프스 원칙), 공개 검증
권한 분리(Separation of privilege)	두 개의 열쇠가 있어야 열리는 장치가 하나로 열리는 장치보다 견고하다	직무 분리, 이중 승인, 다중 인증
최소 권한(Least privilege)	모든 프로그램과 사용자는 작업에 필요한 최소한의 권한으로 동작한다	최소 권한 원칙, 알 필요(need-to-know)
최소 공통 메커니즘(Least common mechanism)	여러 사용자가 공유하고 모두가 의존하는 메커니즘을 최소화한다. 공유 메커니즘은 정보 경로가 된다	테넌트 격리, 공유 라이브러리·공유 메모리 최소화
심리적 수용성(Psychological acceptability)	사람이 일상적으로, 자동으로, 올바르게 쓰도록 인터페이스를 쉽게 설계한다	패스키, SSO, 안전한 기본 설정

논문은 이어서 물리 보안에서 빌려 온 두 원칙, 즉 작업량(work factor)(우회 비용을 공격자 자원과 비교)과 침해 기록(compromise recording)(완전 차단 대신 침해 사실을 확실히 기록)도 소개하지만 "컴퓨터 시스템에는 불완전하게만 적용된다"고 단서를 달았다.

원칙별 정리

위협 모델링

설계 단계에서 "무엇을 만드는가, 무엇이 잘못될 수 있는가, 어떻게 대응하는가, 잘 했는가"를 체계적으로 묻는 활동이다. STRIDE, PASTA, 공격 트리 같은 기법을 쓴다. 다른 원칙들을 어디에 얼마나 적용할지 정하는 입력이 되므로 3.1의 첫 번째 항목으로 나온다. 자세한 내용은 위협 모델링에서 다룬다.

최소 권한

주체(사용자, 서비스 계정, 프로세스, AI 에이전트)에게 업무 수행에 필요한 최소한의 권한만 필요한 기간 동안 부여한다. 사고나 오류, 침해가 일어났을 때 피해 범위(blast radius)를 줄이는 것이 목적이다. 정보 접근을 업무상 필요로 제한하는 알 필요 원칙과 짝을 이룬다. 자세한 내용은 최소 권한 원칙에서 다룬다.

심층 방어

하나의 통제가 실패해도 다른 통제가 막도록 서로 독립적인 여러 겹의 통제(관리·기술·물리, 네트워크·호스트·애플리케이션·데이터)를 배치한다. 자세한 내용은 심층 방어에서 다룬다.

안전한 기본값

제품이나 시스템이 설치 직후 아무것도 바꾸지 않은 상태에서 안전해야 한다는 원칙이다(secure by default). 솔처와 슈뢰더의 fail-safe defaults(접근 결정을 허가 기반으로 하고 기본은 거부)에서 시작해, 오늘날에는 다음을 포함하는 넓은 뜻으로 쓴다.

접근 통제는 기본 거부(default deny)로 시작하고 필요한 것만 명시적으로 허용한다.
공통 기본 비밀번호를 두지 않고 최초 실행 때 고유 자격 증명을 설정하게 한다.
쓰지 않는 서비스·포트·계정은 기본으로 꺼 둔다.
로깅, 다중 인증, 암호화 같은 보안 기능을 추가 비용 없이 기본으로 켠다.
개인정보 공유 설정은 기본으로 비공개로 둔다(개인정보 보호 중심 설계의 privacy as the default).

CISA와 여러 나라 기관이 공동 발간한 Secure by Design 지침은 보안 설정 부담을 고객이 아니라 제조사가 져야 한다고 보고, 안전한 기본값을 제조사 책임의 핵심으로 든다. 조직 내부에서는 보안 기준선과 형상 관리가 안전한 기본값을 유지하는 수단이다.

안전한 실패

안전한 실패(fail securely)는 구성 요소가 고장 나거나 예외가 발생해도 시스템이 보안 상태를 잃지 않도록 설계하는 원칙이다. 예를 들어 인증 서버에 연결할 수 없으면 로그인을 허용하지 않고, 예외 처리 중에 권한 검사를 건너뛰지 않으며, 오류 메시지에 내부 정보를 노출하지 않는다.

여기서 혼동하기 쉬운 용어가 페일 시큐어(fail-secure)와 페일 세이프(fail-safe)이다. IETF RFC 4949를 인용한 NIST 용어집 정의에 따르면 fail-secure는 고장 시 보안 상태의 상실을 막는 종료 방식(대신 일부 자원이 손상될 수 있음)이고, fail-safe는 고장 시 데이터·재산·생명 같은 지정된 자원의 손상을 막는 종료 방식(대신 보안이 침해될 수 있음)이다. 즉 두 개념은 무엇을 우선 보호하느냐가 다르다.

구분	페일 시큐어(fail-secure, fail-closed)	페일 세이프(fail-safe) / 페일 오픈(fail-open)
우선 보호 대상	기밀성·무결성, 보안 상태	사람의 생명·안전, 가용성
정전 시 출입문	잠긴 상태 유지	잠금이 풀림(사람이 대피 가능)
방화벽·IPS 장애	트래픽 차단	트래픽 통과(검사 없이 우회)
적합한 곳	금고, 서버실 내부 문, 기밀 시스템	비상 출구, 화재 대피 경로, 생명 유지 설비

CISSP에서는 인명 안전이 언제나 최우선이므로 사람이 드나드는 비상구는 페일 세이프여야 하고, 자산만 보호하는 공간의 문은 페일 시큐어로 설계한다. 산업 안전 분야의 페일세이프 개념(고장 시 기계가 안전 상태로 정지)과 같은 뿌리이다. 페일 세이프 출입문이라도 밖에서 들어오는 것은 막고 안에서 나가는 것만 허용하는 식으로 두 요구를 함께 만족시키는 설계가 일반적이다.

직무 분리

중요한 업무를 한 사람이 처음부터 끝까지 처리하지 못하게 나누어 부정과 오류를 막는다(Segregation/Separation of Duties). 솔처와 슈뢰더의 권한 분리를 사람과 조직 차원으로 확장한 것이다. 설계 단계에서는 개발자와 운영 배포 권한 분리, 보안 로그 관리자와 시스템 관리자 분리, 결제 생성과 승인 분리로 구현한다. 자세한 내용은 직무 분리에서 다룬다.

단순성

단순하고 작게 유지(keep it simple and small)는 솔처와 슈뢰더의 메커니즘의 경제성 원칙을 그대로 옮긴 것이다. 설계 오류로 생긴 비정상 접근 경로는 정상 사용 중에는 드러나지 않으므로, 코드를 한 줄씩 검사하고 하드웨어를 직접 점검할 수 있을 만큼 보호 메커니즘이 작고 단순해야 한다. 실무에서는 다음으로 나타난다.

공격 표면(attack surface) 축소: 불필요한 기능·서비스·포트·계정·의존 패키지를 제거한다.
보안 기능을 작은 구성 요소(보안 커널, 인증 모듈)에 모으고 나머지와 분리한다. 신뢰 컴퓨팅 기반을 작게 유지하는 것과 같은 이유이다.
직접 구현한 암호나 인증 대신 검증된 표준 구성 요소를 쓴다.
예외 규칙과 특례가 쌓인 방화벽 정책·권한 체계를 주기적으로 정리한다.

복잡성은 보안의 적이라는 말이 이 원칙의 요약이며, 단순한 설계일수록 검증·운영·감사가 쉽다.

제로 트러스트, 신뢰하되 검증

네트워크 위치(내부망)만으로 신뢰를 주지 않고 모든 요청을 신원·기기 상태·맥락에 따라 매번 검증한다. 솔처와 슈뢰더의 완전한 중재를 네트워크 규모로 확장한 것으로 볼 수 있다. 출제 기준은 "zero trust or trust but verify"로 함께 쓰는데, 신뢰하되 검증(trust but verify)은 신뢰 관계를 인정하되 로그·감사·모니터링으로 사후 확인하는 전통적 접근이고, 제로 트러스트는 암묵적 신뢰 자체를 없애는 더 엄격한 접근이다. 자세한 내용은 제로 트러스트에서 다룬다.

개인정보 보호 중심 설계

개인정보 보호를 사후 조치가 아니라 설계 요구사항으로 넣는다. 앤 카부키언의 7원칙, GDPR 제25조의 data protection by design and by default가 대표적이다. 자세한 내용은 개인정보 보호 중심 설계에서 다룬다.

공동 책임

클라우드나 외주 서비스에서는 보안 책임이 제공자와 이용자 사이에 나뉜다. IaaS에서 PaaS, SaaS로 갈수록 제공자 책임이 늘지만 데이터, 계정·접근 권한, 설정에 대한 책임은 어느 모델에서든 이용자에게 남는다. 설계 단계에서 책임 경계를 계약·SLA·책임 매트릭스로 문서화해야 공백이 생기지 않는다. 서비스 모델별 책임 표는 클라우드 보안, 아마존 웹 서비스 사례는 AWS 공동 책임 모델에서 다룬다.

SASE

SASE(Secure Access Service Edge)는 SD-WAN과 SWG·CASB·ZTNA·FWaaS 같은 보안 기능을 클라우드 서비스로 묶어 사용자 가까운 곳에서 같은 정책을 적용하는 아키텍처이다. 제로 트러스트와 심층 방어를 분산된 사용자·SaaS 환경에서 구현하는 방법으로 3.1에 포함되었다.

원칙 간 관계

원칙	주로 줄이는 것	대표 통제
최소 권한	침해 시 피해 범위	RBAC, 적시 권한 부여, 권한 검토
심층 방어	단일 통제 실패의 영향	다계층 통제, 이기종 제품
안전한 기본값	설정 실수, 기본 계정 악용	기본 거부, 보안 기준선
안전한 실패	장애·예외 시 우회	fail-closed 설계, 예외 처리 검토
직무 분리	내부 부정, 단독 실수	이중 승인, 역할 분리
단순성	설계 결함, 공격 표면	기능 최소화, 작은 보안 커널
제로 트러스트	내부망 측면 이동	요청 단위 인증·인가, 마이크로 세그멘테이션
개인정보 보호 중심 설계	과잉 수집, 목적 외 이용	최소 수집, 가명처리, 기본값 비공개

AI 시스템에도 같은 원칙이 적용된다. 도구를 호출하는 AI 에이전트에는 최소 권한과 완전한 중재를, 학습 데이터 파이프라인에는 무결성 검증과 직무 분리를, 모델 서빙 환경에는 안전한 기본값과 공격 표면 축소를 적용한다.

시험 포인트

보안은 설계 단계에서 넣는 것이 가장 싸고 효과적이다. "가장 먼저 할 일"을 묻는 문제에서 요구사항·설계 단계의 통제(위협 모델링, 보안 요구사항 정의)를 고른다.
솔처와 슈뢰더 8원칙의 이름과 뜻을 짝지을 수 있어야 한다. 특히 fail-safe defaults는 "기본은 접근 거부"라는 뜻이며 출입문의 fail-safe와 다른 개념이다.
출입문은 인명 안전이 걸리면 페일 세이프(정전 시 열림), 자산만 보호하면 페일 시큐어(정전 시 잠김)를 고른다. 흔한 오답: 보안을 위해 비상구를 잠그는 선택.
공개 설계는 "보안은 비밀 유지된 설계에 기대지 않는다"는 뜻이다. 모호성에 의한 보안(security through obscurity)만으로 보호하는 선택지는 오답이다.
공동 책임 모델에서 데이터와 접근 권한 관리 책임은 SaaS에서도 이용자에게 남는다.
단순성(공격 표면 축소)과 심층 방어는 충돌하지 않는다. 각 계층은 단순하게, 계층은 여러 겹으로 구성한다.

같이 보기

참고 문헌