객체지향 시니어 보안 기술면접

JWT 탈취 방어를 위해서는 Access Token의 짧은 만료시간(15분 이내)과 Refresh Token Rotation 전략을 결합해야 합니다. Refresh Token Rotation은 매번 토큰 갱신 시 새로운 Refresh Token을 발급하고 기존 토큰을 무효화하여, 탈취된 토큰 사용 시 즉시 탐지할 수 있습니다. Token Binding은 토큰을 특정 디바이스나 세션에 바인딩하여 다른 환경에서의 사용을 차단하며, TLS 레벨의 채널 바인딩이나 디바이스 fingerprinting을 활용합니다. 추가로 Redis 같은 인메모리 저장소에 토큰 블랙리스트를 관리하고, 이상 행위 탐지 시스템을 구축하여 동시 다중 위치 접속이나 비정상적인 API 호출 패턴을 모니터링해야 합니다. 마이크로서비스 환경에서는 API Gateway에서 중앙화된 토큰 검증과 Rate Limiting을 수행하여 방어 계층을 추가합니다.

Nonce 기반 CSP는 서버가 매 요청마다 고유한 난수를 생성하여 허용된 스크립트에 nonce 속성을 부여하는 방식으로, 동적 콘텐츠에 유연하지만 서버 사이드 렌더링이 필요합니다. Hash 기반 CSP는 스크립트 내용의 해시값을 미리 계산하여 정책에 포함시키는 방식으로, 정적 리소스에 적합하지만 코드 변경 시마다 해시 재계산이 필요합니다. SPA 환경에서는 Nonce 기반이 더 적합한데, 빌드 타임에 생성되는 번들 파일과 런타임에 동적으로 로드되는 chunk 파일들을 모두 커버할 수 있기 때문입니다. 구현 시 SSR이나 Edge Function에서 HTML에 nonce를 주입하고, React나 Vue의 helmet 같은 라이브러리로 meta 태그를 동기화합니다. Strict-dynamic 지시어를 함께 사용하면 신뢰된 스크립트가 로드하는 하위 스크립트도 자동으로 허용되어 관리 복잡도가 낮아집니다.

비밀번호처럼 원본 복구가 불필요한 데이터는 bcrypt, scrypt, Argon2 같은 단방향 해싱을 사용하며, 충분한 cost factor와 salt를 적용하여 Rainbow Table 공격을 방어합니다. 주민등호나 카드번호처럼 업무상 복호화가 필요한 데이터는 AES-256-GCM 같은 양방향 암호화를 사용하되, 암호화 키는 절대 애플리케이션 코드나 DB에 저장하지 않고 AWS KMS, HashiCorp Vault 같은 별도의 키 관리 시스템에서 관리합니다. 키 계층 구조를 설계하여 마스터 키로 데이터 암호화 키(DEK)를 암호화하는 Envelope Encryption 패턴을 적용하고, 키 로테이션 정책을 수립하여 주기적으로 키를 갱신합니다. 추가로 필드 레벨 암호화와 TDE(Transparent Data Encryption)를 함께 적용하여 다층 방어 체계를 구축하며, 암호화된 필드는 인덱싱이 불가하므로 검색 가능 암호화(Searchable Encryption)나 토큰화를 고려해야 합니다.

RBAC은 사용자에게 역할을 부여하고 역할에 권한을 매핑하는 방식으로 구조가 단순하고 이해하기 쉬우나, 역할이 많아지면 역할 폭발(Role Explosion) 문제가 발생합니다. ABAC은 사용자 속성, 리소스 속성, 환경 속성을 조합한 정책 기반 접근 제어로, 시간대별 접근, 지역 기반 제한, 데이터 민감도에 따른 동적 권한 부여가 가능하여 유연성이 높습니다. 복잡한 엔터프라이즈 환경에서는 하이브리드 접근이 효과적인데, 기본 권한 구조는 RBAC으로 설계하고 동적 제약사항은 ABAC 정책으로 보완하는 방식입니다. 구현 시 XACML이나 OPA(Open Policy Agent) 같은 정책 엔진을 사용하여 비즈니스 로직과 권한 로직을 분리하고, 정책 변경이 코드 배포 없이 가능하도록 설계합니다. 성능을 위해 권한 결정 결과를 캐싱하되, 속성 변경 시 즉시 무효화되는 메커니즘을 구축해야 합니다.

ORM을 사용해도 동적 정렬 조건, 복잡한 검색 필터, 대량 업데이트 같은 경우 Raw Query나 Native Query를 사용하게 되면 SQL 인젝션 위험이 있습니다. 특히 문자열 보간으로 WHERE 절이나 ORDER BY 절을 구성하거나, LIKE 패턴에 사용자 입력을 직접 결합하는 경우가 취약합니다. 코드 리뷰 시에는 createNativeQuery, executeQuery 같은 메서드 사용 부분을 중점 검토하고, 파라미터 바인딩 대신 문자열 연결을 사용하는지 확인해야 합니다. 안전한 구현을 위해서는 Parameterized Query나 Prepared Statement를 필수로 사용하고, 동적 정렬이 필요한 경우 화이트리스트 기반 검증을 적용하며, JPA Criteria API나 QueryDSL 같은 타입 안전 쿼리 빌더를 활용합니다. 추가로 DB 권한을 최소화하여 애플리케이션 계정은 DDL 실행이나 시스템 테이블 접근을 못하도록 제한해야 합니다.

세션 고정 공격은 공격자가 미리 알고 있는 세션 ID를 피해자에게 강제로 사용하게 만든 후, 피해자가 로그인하면 해당 세션으로 접근하는 공격입니다. 방어를 위해서는 로그인 성공 시 반드시 새로운 세션 ID를 생성하고 기존 세션을 무효화해야 하며, 대부분의 웹 프레임워크에서 제공하는 session regeneration 기능을 활용합니다. 세션 하이재킹은 네트워크 스니핑이나 XSS로 유효한 세션 ID를 탈취하는 공격으로, HTTPS 강제 사용과 Secure, HttpOnly, SameSite 쿠키 속성 설정으로 방어합니다. 추가로 세션에 사용자 IP나 User-Agent를 바인딩하여 이상 징후를 탐지하고, 세션 타임아웃을 적절히 설정하며, 중요 작업 수행 시 재인증을 요구하는 다층 방어를 구축합니다. 로그아웃 시에는 서버와 클라이언트 양쪽에서 모두 세션을 완전히 제거해야 합니다.

SPA 환경에서는 전통적인 CSRF 토큰 대신 여러 전략을 사용할 수 있습니다. 첫째, JWT를 LocalStorage에 저장하고 Authorization 헤더로 전송하면 쿠키가 자동으로 전송되지 않아 CSRF 공격이 원천적으로 불가능하지만, XSS 취약점에는 더 노출됩니다. 둘째, SameSite 쿠키 속성을 Strict나 Lax로 설정하면 크로스 사이트 요청 시 쿠키가 전송되지 않아 CSRF를 방어할 수 있으나, 레거시 브라우저 지원 문제가 있습니다. 셋째, Double Submit Cookie 패턴은 쿠키와 커스텀 헤더에 동일한 토큰을 넣어 전송하고 서버에서 비교하는 방식으로, 상태 관리가 불필요하지만 서브도메인 공격에 취약할 수 있습니다. 실무에서는 SameSite=Lax를 기본으로 설정하고, 중요 작업에는 추가로 CSRF 토큰이나 재인증을 요구하는 다층 방어가 효과적입니다. API 서버에서는 Origin과 Referer 헤더 검증을 추가하여 방어 계층을 강화합니다.

마이크로서비스에서는 각 서비스가 필요한 최소한의 개인정보만 보유하도록 데이터 경계를 명확히 설계해야 합니다. Claims-based 인증을 사용하여 JWT에 필요한 최소 속성만 포함시키고, 민감 정보는 별도의 API 호출로만 조회 가능하게 합니다. 서비스 간 통신 시에는 개인정보 대신 익명화된 ID나 가명 정보를 전달하고, 필요 시에만 PII(Personally Identifiable Information) 서비스에 질의하는 패턴을 적용합니다. 로깅 시에는 구조화된 로깅 라이브러리에 필드 레벨 마스킹 정책을 설정하여 이메일, 전화번호, 주민번호 같은 패턴을 자동으로 마스킹하며, 로그 수집 파이프라인에서도 2차 검증을 수행합니다. APM이나 모니터링 도구에 전송되는 메트릭에도 개인정보가 포함되지 않도록 주의하고, 에러 메시지에 사용자 입력값이 노출되지 않도록 예외 처리를 설계합니다. GDPR이나 개인정보보호법 준수를 위해 데이터 보유 기간을 설정하고 자동 삭제 정책을 구현해야 합니다.

API 보안은 다층 Rate Limiting 전략으로 구현해야 하며, IP 기반 전역 제한, API Key 기반 사용자별 제한, 엔드포인트별 세밀한 제한을 계층적으로 적용합니다. Redis나 Memcached를 사용한 Token Bucket이나 Sliding Window 알고리즘으로 분산 환경에서도 정확한 제한을 보장하며, API Gateway 레벨에서 1차 방어를 수행합니다. API Key는 최소 32바이트 이상의 암호학적으로 안전한 난수로 생성하고, 해싱하여 저장하며, Key Rotation 정책을 수립하여 주기적 갱신을 강제합니다. Quota 관리는 시간 단위(분당, 일당, 월당)별로 다르게 설정하고, 티어별 차등 적용하여 비즈니스 모델을 지원합니다. DDoS 방어를 위해 이상 트래픽 패턴을 실시간 탐지하여 동적으로 제한을 강화하고, CAPTCHA나 추가 인증을 요구하며, CDN과 WAF를 함께 활용합니다. 정상 사용자 보호를 위해 429 응답 시 Retry-After 헤더를 제공하고, 제한 임박 시 경고를 주며, 버스트 트래픽을 허용하는 유연한 정책을 설계합니다.

Zero Trust는 '절대 신뢰하지 말고 항상 검증하라'는 원칙으로, 네트워크 위치와 무관하게 모든 접근을 인증하고 인가합니다. 핵심 요소는 강력한 신원 확인, 최소 권한 원칙, 마이크로 세그멘테이션, 지속적인 검증입니다. 레거시 시스템에서 전환 시 첫 단계로 모든 사용자와 디바이스의 인벤토리를 구축하고 IAM 시스템을 중앙화합니다. 두 번째로 중요 자산과 데이터 흐름을 매핑하여 보호 우선순위를 정하고, API Gateway나 Service Mesh를 도입하여 서비스 간 통신을 제어합니다. 세 번째로 VPN을 ZTNA(Zero Trust Network Access)로 대체하여 애플리케이션 레벨 접근 제어를 구현하고, 네트워크 세그멘테이션을 마이크로 세그멘테이션으로 전환합니다. 네 번째로 모든 트래픽을 로깅하고 분석하여 이상 행위를 탐지하는 SIEM이나 UEBA를 구축합니다. 점진적 전환을 위해 파일럿 프로젝트로 특정 서비스부터 적용하고, 성공 사례를 기반으로 확산하며, 레거시와 신규 시스템이 공존하는 하이브리드 기간을 관리합니다.