보안 설계 (Security Design)

목차

보안 설계란

보안 설계(Security Design) 는 시스템이 인증되지 않은 접근, 권한 오남용, 데이터 유출, 비밀 관리 실패 같은 위험을 어떻게 줄일지 구조적으로 결정하는 작업입니다.

이 문서는 시스템 설계 관점에서 어떤 보안 경계를 먼저 세우고, 무엇을 어디서 통제할지, 그 대가가 무엇인지를 설명합니다.
구체적인 프로토콜 설정이나 플랫폼 구현 상세는 gRPC, 서비스 메시, Kubernetes 문서를 함께 보면 더 직접적입니다.

시스템 디자인 면접에서 보안은 마지막에 “HTTPS 붙이겠습니다”로 끝나지 않습니다. 보통 다음을 같이 봅니다.

  • 누가 접근하는가: 사용자, 내부 서비스, 운영자, 배치 작업
  • 무엇을 보호하는가: 계정, 토큰, 결제 정보, 개인정보, 내부 API
  • 어디서 통제하는가: 클라이언트, API Gateway, 애플리케이션, 데이터 저장소, 네트워크 경계
  • 어떤 공격을 줄일 것인가: 인증 우회, 권한 상승, 토큰 탈취, 과도한 요청, 데이터 유출

즉, 보안 설계는 기능 뒤에 붙는 부가 옵션이 아니라 시스템 경계와 신뢰 모델을 먼저 정의하는 작업에 가깝습니다.

보안 설계의 기본 원칙

보안 설계를 설명할 때는 세부 기술보다 먼저 기본 원칙을 잡는 편이 좋습니다.

  • 최소 권한 (Least Privilege): 꼭 필요한 권한만 부여합니다.1
  • 기본 거부 (Deny by Default): 허용한 요청만 통과시키는 쪽이 안전합니다.
  • 심층 방어 (Defense in Depth): 한 계층이 뚫려도 다른 계층이 막도록 설계합니다.
  • 비밀 분리: 비밀번호, 토큰, 인증서를 코드와 설정 파일에 직접 두지 않습니다.2
  • 감사 가능성: 누가 무엇을 했는지 나중에 추적할 수 있어야 합니다.

예를 들면 다음과 같습니다.

  1. API Gateway에서 인증을 검사합니다.
  2. 애플리케이션 서비스에서 권한을 다시 확인합니다.
  3. 데이터베이스 접근은 서비스 계정별로 분리합니다.
  4. 운영자 액세스는 별도 감사 로그와 MFA를 둡니다.

이런 구조는 한 곳에서 실수해도 전체 시스템이 바로 무너지지 않게 만듭니다.

면접에서는 특정 도구 이름보다 보안은 한 방에 끝나는 기능이 아니라 여러 계층의 통제 조합이라고 설명하는 편이 좋습니다.

인증과 권한 부여

보안 설계에서 가장 자주 나오는 기초 구분은 인증(Authentication) 과 권한 부여(Authorization) 입니다.

인증 설계 원칙과 흔한 실수는 OWASP의 Authentication Cheat Sheet를 기준으로 설명해도 무리가 없습니다.3

항목 인증 권한 부여
질문 누구인가 무엇을 할 수 있는가
예시 로그인, 토큰 검증, 서비스 아이덴티티 확인 관리자 권한 확인, 리소스 접근 제어
실패 시 위험 신원 위조 권한 상승, 데이터 오남용
대표 수단 세션, JWT, OAuth/OIDC, mTLS RBAC, ABAC, 리소스 소유권 검사

인증이 잘 맞는 구조를 설명할 때는 보통 다음 흐름이 안전합니다.

  • 외부 사용자는 세션 또는 토큰 기반으로 인증
  • 내부 서비스는 서비스 계정, mTLS, 서명된 토큰 등으로 신뢰 관계 확인
  • 권한 부여는 역할만 보지 말고 리소스 소유권과 요청 맥락까지 함께 판단

중요한 점은 인증을 통과했다고 모든 요청이 허용되는 것은 아니라는 점입니다.

  • 일반 사용자가 자기 주문만 조회 가능한가
  • 운영자가 읽기만 가능한가, 수정도 가능한가
  • 내부 서비스가 특정 토픽이나 테이블까지 접근 가능한가

권한 설계는 보통 다음 질문으로 정리할 수 있습니다.

  • 역할 기반으로 충분한가
  • 속성 기반 판단이 필요한가
  • 리소스 소유권 검사까지 필요한가

좋은 답변은 “JWT를 쓰겠습니다”보다 인증과 권한 부여를 별개 문제로 다루고, 어느 계층에서 각각 검사할지를 말하는 답변입니다.

API 보안

공개 API나 내부 API를 설계할 때는 인증 외에도 여러 보안 통제가 필요합니다. OWASP도 API 보안에서 인증, 권한, 입력 검증, 과도한 노출을 핵심 위험으로 봅니다.4

대표적으로 다음을 설계해야 합니다.

  • TLS 적용: 전송 구간 보호
  • 입력 검증: 파라미터, 헤더, 요청 본문 검증
  • 권한 검사: 리소스 단위 접근 제어
  • 레이트 리밋: 과도한 요청과 남용 방지
  • 오류 응답 제어: 내부 구조가 과도하게 노출되지 않도록 설계
  • 감사 로그: 민감 API 호출은 추적 가능해야 함
통제 왜 필요한가 주의점
TLS 토큰과 민감 데이터 보호 내부망이라고 생략하면 위험
레이트 리밋 남용과 브루트포스 완화 정상 사용자 경험까지 해치지 않게 설계
입력 검증 잘못된 요청과 공격 입력 차단 애플리케이션과 스키마 계층 모두에서 확인 필요
감사 로그 사고 조사와 이상 징후 분석 민감정보를 그대로 남기면 안 됨

API 보안에서는 “막는다”만큼 무엇을 드러내지 않을지도 중요합니다.

  • 로그인 실패 시 계정 존재 여부를 지나치게 노출하지 않기
  • 내부 에러 스택을 그대로 반환하지 않기
  • 과도한 응답 필드 노출을 피하기

관련된 API 설계 배경은 API 설계 문서와도 연결됩니다. 레이트 리밋의 기준 단위, 알고리즘, 429/Retry-After 계약은 레이트 리미팅 (Rate Limiting) 문서가 더 직접적인 심화 자료입니다.

데이터 암호화와 비밀 관리

보안 설계에서 자주 빠지는 부분이 저장 데이터 보호와 비밀 관리입니다.

대표 포인트는 다음과 같습니다.

  • 전송 중 암호화: TLS로 네트워크 구간 보호
  • 저장 시 암호화: 데이터베이스, 오브젝트 스토리지, 백업 암호화
  • 비밀 분리: 토큰, 비밀번호, 인증서를 코드에 두지 않기
  • 키 관리: 키 로테이션과 접근 통제
  • 민감정보 최소화: 꼭 필요한 데이터만 저장
대상 주요 설계 포인트
사용자 비밀번호 해시 저장, 평문 저장 금지
액세스 토큰 짧은 수명, 노출 최소화, 저장 위치 주의
데이터베이스 자격증명 Secret manager 또는 안전한 비밀 저장소 사용
백업 데이터 운영 데이터만큼 강하게 보호

여기서 중요한 질문은 다음입니다.

  • 이 데이터는 유출 시 영향이 큰가
  • 운영자가 평문으로 볼 필요가 있는가
  • 키를 누가, 어디서, 어떻게 교체하는가

즉, 보안 설계는 “암호화하자”에서 멈추지 않고 무엇을 암호화하고, 비밀을 누가 만질 수 있고, 로테이션을 어떻게 할지까지 포함해야 합니다.

서비스 간 통신과 네트워크 경계

시스템이 커지면 외부 사용자뿐 아니라 서비스 간 통신도 보안 경계가 됩니다.

주요 질문은 다음과 같습니다.

  • 내부 서비스 호출을 어디까지 신뢰할 것인가
  • 네트워크만 믿고 통과시킬 것인가
  • 서비스 간에도 인증과 권한 검사가 필요한가

많이 쓰는 접근은 다음과 같습니다.

  • 네트워크 분리: 공개 영역과 내부 영역 분리
  • 서비스 아이덴티티: 서비스별 신원 부여
  • mTLS: 서비스 간 트래픽 암호화와 상호 인증
  • 정책 집행: 어떤 서비스가 어떤 서비스에 접근 가능한지 제어

이 단계에서 서비스 메시나 Kubernetes 네트워크 정책 같은 구현 도구가 등장할 수 있지만, 시스템 디자인 답변에서는 왜 내부 통신도 신뢰 경계로 봐야 하는지를 먼저 설명하는 편이 좋습니다.

예를 들어:

  • 운영망 침해 시 내부 API까지 바로 열려 있지 않도록 설계
  • 결제 서비스는 아무 내부 서비스나 호출할 수 없도록 제한
  • 민감한 관리 API는 별도 네트워크와 권한 체계를 둠

관련 구현 상세는 서비스 메시, Kubernetes, gRPC 문서와 함께 보면 좋습니다.

언제 어떤 수준까지 설계할까

모든 시스템에 같은 수준의 보안 통제를 넣는 것은 현실적이지 않습니다. 보통은 자산 가치와 위협 수준에 따라 보안 강도를 조정합니다.

보안 설계를 더 강화해야 하는 신호는 다음과 같습니다.

  • 결제, 개인정보, 인증 정보처럼 민감한 자산을 다룸
  • 외부 공개 API가 많음
  • 운영자 수와 내부 시스템 접근 경로가 많음
  • 규제나 감사 요구가 있음

반대로 초기 서비스라도 최소한 다음은 기본에 가깝습니다.

  • TLS
  • 비밀번호 안전 저장
  • 토큰/비밀 분리
  • 기본 권한 검사
  • 민감 로그 마스킹

즉, 보안은 나중에 붙이는 기능이 아니라 최소 기본값은 초기에 넣고, 위험이 커질수록 점진적으로 강화하는 구조가 현실적입니다.

보안 설계의 트레이드오프

  • 장점: 사고 가능성과 피해 범위를 줄이고, 신뢰성과 감사 가능성을 높일 수 있습니다.
  • 단점: 인증 흐름, 권한 정책, 비밀 관리, 운영 절차가 복잡해집니다.
  • 주의점: 보안을 강화할수록 사용자 경험과 개발 속도, 운영 부담에 비용이 붙습니다.

특히 다음 오해를 피해야 합니다.

  • 내부망이면 안전하다고 가정하면 안 됨
  • 인증만 있으면 권한 검사는 자동 해결된다고 보면 안 됨
  • 암호화만 하면 보안 설계가 끝나는 것도 아님

좋은 답변은 무엇을 보호할지, 어느 계층에서 어떤 통제를 둘지, 그 대가로 어떤 복잡성을 감수할지를 함께 설명하는 답변입니다.

면접 포인트

  • 보안 설계의 핵심은 기술 나열이 아니라 신뢰 경계와 보호 대상 정의입니다.
  • 인증과 권한 부여는 반드시 분리해서 설명하는 편이 좋습니다.
  • API 보안에서는 TLS, 권한 검사, 레이트 리밋, 오류 노출 통제를 함께 말해야 합니다.
  • 비밀 관리와 암호화는 저장 데이터와 운영 절차까지 포함하는 문제입니다.
  • 좋은 답변은 보안 강도를 자산 가치와 위협 수준에 맞춰 조절한다고 설명합니다.

참고 자료

  1. OWASP Cheat Sheet Series, “Authorization Cheat Sheet” ↩

  2. Kubernetes Docs, “Good practices for Kubernetes Secrets” ↩

  3. OWASP Cheat Sheet Series, “Authentication Cheat Sheet” ↩

  4. OWASP API Security Project, “OWASP API Security Top 10” ↩