Java 시니어 보안 기술면접
새 면접Q. 대규모 MSA 환경에서 OAuth 2.0 기반 인증 시스템을 구축할 때, Authorization Code Flow와 Client Credentials Flow의 선택 기준을 설명하고, Refresh Token의 저장 위치(DB, Redis, In-memory)에 따른 보안 트레이드오프를 분석해주세요. 또한 Token Rotation 전략과 Refresh Token Reuse Detection을 통해 토큰 탈취 공격을 방어하는 메커니즘을 설명해주세요.
각 플로우의 사용 주체(사용자 vs 서비스)와 토큰 저장소의 성능-보안-가용성 측면을 고려해보세요.
Authorization Code Flow는 사용자 컨텍스트가 필요한 웹/모바일 애플리케이션에 적합하며, Client Credentials Flow는 서비스 간 통신(M2M)에 사용합니다. Refresh Token을 DB에 저장하면 강력한 감사와 즉시 무효화가 가능하지만 조회 오버헤드가 발생하고, Redis는 빠른 검증과 TTL 관리가 용이하나 영속성이 약하며, In-memory는 성능은 최고지만 서버 재시작 시 모든 세션이 무효화됩니다. Token Rotation은 Refresh Token 사용 시마다 새로운 토큰을 발급하고 기존 토큰을 무효화하여, 탈취된 토큰이 재사용되면 Reuse Detection으로 탐지하여 해당 토큰 패밀리 전체를 무효화함으로써 공격을 차단합니다. 실무에서는 Redis에 토큰 해시값과 메타데이터를 저장하고, 중요 이벤트는 DB에 감사 로그로 남기는 하이브리드 방식을 많이 사용합니다.
- • Authorization Code Flow는 사용자 인증, Client Credentials는 서비스 간 인증에 사용
- • 토큰 저장소별 성능-보안-가용성 트레이드오프 이해
- • Token Rotation과 Reuse Detection을 통한 토큰 탈취 방어
- • 하이브리드 저장 전략으로 장점 결합
금융권 MSA 시스템에서 사용자 인증과 서비스 간 인증을 분리하고, 토큰 탈취 시 피해를 최소화하기 위한 아키텍처 설계에 활용됩니다.
MSA 환경에서 각 마이크로서비스가 독립적으로 토큰을 검증해야 할 때, JWT의 Self-contained 특성과 중앙 집중식 토큰 검증 방식 중 어떤 것을 선택하시겠습니까? 각각의 보안 및 성능 트레이드오프를 설명해주세요.
Q. 개인정보를 데이터베이스에 암호화하여 저장하는 시스템을 설계할 때, 대칭키 암호화(AES)와 비대칭키 암호화(RSA)의 선택 기준을 설명하고, Envelope Encryption 패턴의 동작 원리와 장점을 설명해주세요. 또한 암호화 키를 안전하게 관리하기 위해 HSM, KMS(AWS KMS, HashiCorp Vault) 같은 키 관리 시스템을 도입할 때 고려해야 할 사항과, 키 로테이션 전략 및 암호화된 데이터의 재암호화 프로세스를 설명해주세요.
대용량 데이터 암호화의 성능 이슈와 키 노출 시 영향 범위를 최소화하는 계층적 접근을 생각해보세요.
대칭키(AES)는 빠르고 대용량 데이터 암호화에 적합하지만 키 분배가 어렵고, 비대칭키(RSA)는 키 교환에 유리하나 느려서 대용량 데이터에 부적합합니다. Envelope Encryption은 데이터를 DEK(Data Encryption Key)로 암호화하고, DEK를 다시 KEK(Key Encryption Key)로 암호화하는 이중 구조로, 데이터마다 다른 DEK를 사용하여 키 노출 시 피해 범위를 제한하고 KEK만 안전하게 관리하면 되므로 키 관리가 단순해집니다. KMS 도입 시에는 키 접근 권한 관리(IAM), 감사 로깅, 리전별 키 복제, 장애 시 대체 키 접근 방법을 고려해야 합니다. 키 로테이션은 주기적으로 새 KEK를 생성하고 새 데이터는 신규 키로 암호화하며, 기존 데이터는 lazy re-encryption(접근 시점 재암호화) 또는 batch re-encryption(일괄 재암호화) 전략을 선택하여 점진적으로 마이그레이션합니다.
- • 대칭키는 성능, 비대칭키는 키 교환에 유리
- • Envelope Encryption으로 키 노출 피해 최소화 및 관리 단순화
- • KMS 도입 시 권한 관리, 감사, 가용성 고려
- • 키 로테이션 시 점진적 재암호화 전략 필요
전자상거래 플랫폼에서 신용카드 정보, 주민등록번호 등 민감 정보를 안전하게 저장하고 규제 준수를 위한 키 관리 체계 구축에 활용됩니다.
GDPR의 '잊혀질 권리' 요구사항을 충족하기 위해 특정 사용자의 데이터만 완전히 삭제 불가능하게 만들어야 할 때, 암호화 키 관리 전략을 어떻게 설계하시겠습니까?
Q. Spring 기반 웹 애플리케이션에서 CSRF(Cross-Site Request Forgery) 공격의 원리를 설명하고, SameSite Cookie 속성(Strict, Lax, None)의 차이점과 CSRF 토큰 검증 방식을 비교해주세요. 또한 RESTful API 환경에서 stateless 인증(JWT)을 사용할 때 CSRF 방어가 필요한지 여부와 그 이유를 설명하고, XSS와 CSRF의 관계 및 방어 전략의 차이점을 설명해주세요.
공격이 성립하는 조건(쿠키 자동 전송)과 인증 방식별 차이를 생각해보세요.
CSRF는 사용자가 인증된 상태에서 공격자가 만든 악의적인 요청을 브라우저가 자동으로 쿠키를 포함하여 전송하게 만드는 공격입니다. SameSite=Strict는 cross-site 요청 시 쿠키를 전혀 보내지 않아 가장 안전하지만 사용성이 떨어지고, Lax는 GET 같은 안전한 메서드만 허용하며, None은 모든 요청에 쿠키를 전송하므로 HTTPS 필수입니다. CSRF 토큰 방식은 서버가 생성한 토큰을 폼에 포함시켜 요청 시 검증하는 방식으로, 공격자는 토큰을 알 수 없어 방어됩니다. JWT를 Authorization 헤더에 담아 사용하면 브라우저가 자동으로 전송하지 않아 CSRF 위험이 없지만, JWT를 쿠키에 저장하면 CSRF 방어가 필요합니다. XSS는 악의적 스크립트 실행으로 토큰이나 쿠키를 탈취할 수 있어 CSRF 토큰도 무력화되므로, HttpOnly/Secure 쿠키, CSP, 입력 검증 등 다층 방어가 필요합니다.
- • CSRF는 브라우저의 쿠키 자동 전송을 악용한 공격
- • SameSite 속성으로 쿠키 전송 범위 제한 가능
- • JWT를 헤더에 담으면 CSRF 위험 없음, 쿠키 저장 시 방어 필요
- • XSS 방어가 선행되어야 CSRF 방어도 유효
온라인 뱅킹이나 전자상거래 결제 시스템에서 사용자 동의 없는 자금 이체나 구매를 방지하기 위해 필수적으로 적용됩니다.
Single Page Application(SPA)에서 API 서버와 다른 도메인으로 통신할 때, CORS 설정과 인증 방식(쿠키 vs 토큰)에 따른 보안 고려사항은 무엇인가요?
Q. 엔터프라이즈 애플리케이션에서 세밀한 권한 관리가 필요할 때, RBAC(Role-Based Access Control)과 ABAC(Attribute-Based Access Control)의 차이점을 설명하고 각각의 장단점을 비교해주세요. 또한 Spring Security에서 Method Security(@PreAuthorize, @PostAuthorize)를 사용하여 동적 권한 검증을 구현할 때, SpEL 표현식의 성능 이슈와 최적화 방법, 그리고 대규모 권한 규칙을 관리하기 위한 외부 정책 엔진(OPA, Casbin) 도입 시 고려사항을 설명해주세요.
권한 규칙의 복잡도와 변경 빈도, 성능 요구사항에 따른 선택 기준을 생각해보세요.
RBAC은 사용자에게 역할을 부여하고 역할에 권한을 매핑하는 방식으로 구조가 단순하고 관리가 쉬우나, 역할이 많아지면 역할 폭발(role explosion) 문제가 발생합니다. ABAC은 사용자, 리소스, 환경 속성을 기반으로 동적 권한 결정이 가능하여 복잡한 비즈니스 규칙을 표현할 수 있지만, 정책 설계가 복잡하고 성능 오버헤드가 있습니다. Spring Security의 @PreAuthorize에서 SpEL은 매 요청마다 파싱되므로, 자주 사용되는 표현식은 커스텀 PermissionEvaluator로 캐싱하거나 컴파일하여 성능을 개선할 수 있습니다. 대규모 정책 관리가 필요하면 OPA 같은 외부 정책 엔진을 사용하여 정책을 중앙 집중화하고 버전 관리할 수 있으나, 네트워크 레이턴시와 장애 시 대체 전략(fail-open vs fail-closed), 정책 캐싱 전략을 고려해야 합니다. 실무에서는 기본 권한은 RBAC으로, 복잡한 비즈니스 규칙은 ABAC으로 하이브리드 구현하는 경우가 많습니다.
- • RBAC은 단순하지만 역할 폭발, ABAC은 유연하지만 복잡
- • SpEL 성능 이슈는 PermissionEvaluator와 캐싱으로 해결
- • 외부 정책 엔진 도입 시 레이턴시, 장애 대응, 캐싱 전략 필요
- • 하이브리드 접근으로 장점 결합
대규모 ERP 시스템이나 헬스케어 플랫폼에서 부서, 직급, 데이터 민감도에 따라 세밀한 접근 제어가 필요할 때 적용됩니다.
멀티테넌트 SaaS 환경에서 테넌트별로 격리된 데이터 접근 제어를 구현하려면, Row-Level Security와 애플리케이션 레벨 필터링 중 어떤 방식을 선택하시겠습니까?
Q. MyBatis와 JPA를 사용하는 Java 애플리케이션에서 SQL 인젝션 공격이 발생하는 원인과 방어 방법을 설명해주세요. 특히 MyBatis의 #{} 와 ${} 차이점, JPA의 JPQL과 Native Query에서의 파라미터 바인딩 방식, 그리고 동적 쿼리 생성 시 안전하게 처리하는 방법을 설명하고, Criteria API나 QueryDSL 같은 타입 세이프 쿼리 빌더의 보안상 장점을 설명해주세요. 또한 Stored Procedure 사용이 SQL 인젝션을 완전히 방어할 수 있는지 여부도 함께 설명해주세요.
사용자 입력이 SQL 구문의 일부로 해석되는 것을 막는 방법들을 생각해보세요.
SQL 인젝션은 사용자 입력이 SQL 쿼리 구문으로 해석되어 의도하지 않은 쿼리가 실행되는 공격입니다. MyBatis에서 #{}는 PreparedStatement의 파라미터 바인딩을 사용하여 안전하지만, ${}는 문자열 치환으로 인젝션에 취약하므로 테이블명/컬럼명 같은 제한된 용도로만 화이트리스트 검증 후 사용해야 합니다. JPA의 JPQL은 setParameter로 바인딩하면 안전하지만 문자열 연결로 쿼리를 만들면 위험하며, Native Query도 동일하게 파라미터 바인딩을 사용해야 합니다. 동적 쿼리는 Criteria API나 QueryDSL을 사용하면 컴파일 타임에 타입 체크가 되고 쿼리가 객체로 구성되어 인젝션이 원천 차단됩니다. Stored Procedure도 내부에서 동적 SQL을 문자열 연결로 생성하면 인젝션에 취약하므로, 프로시저 내에서도 파라미터 바인딩을 사용해야 완전히 방어할 수 있습니다.
- • MyBatis #{}는 안전, ${}는 위험하므로 제한적 사용
- • JPA/JPQL도 파라미터 바인딩 필수, 문자열 연결 금지
- • Criteria API/QueryDSL로 타입 세이프하게 쿼리 구성
- • Stored Procedure도 내부에서 동적 SQL 사용 시 바인딩 필요
전자상거래나 금융 시스템에서 사용자 입력을 받아 검색, 필터링하는 기능에서 데이터 유출이나 무단 조작을 방지하기 위해 필수적으로 적용됩니다.
NoSQL 데이터베이스(MongoDB, Elasticsearch)를 사용할 때도 인젝션 공격이 가능한가요? 가능하다면 어떤 방식으로 방어해야 하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!