보안 관련 백엔드 면접 질문 정리 - 실무 보안 완벽 가이드

웹 애플리케이션 보안은 백엔드 개발자가 반드시 알아야 할 필수 지식입니다. 한 번의 보안 사고로 회사 전체가 큰 타격을 받을 수 있기 때문에, 면접에서도 보안 관련 질문을 중요하게 다룹니다. 실무에서 자주 마주치는 보안 위협과 대응 방법을 정리해보겠습니다.

1. OWASP Top 10에 대해 설명해주세요.

답변: OWASP Top 10은 웹 애플리케이션에서 가장 위험한 보안 취약점 10가지를 정리한 국제 표준입니다. 매 3-4년마다 업데이트되는데, 최신 버전의 주요 항목들을 말씀드리겠습니다.

첫 번째는 인젝션 공격입니다. SQL, NoSQL, OS 명령어 등의 악성 코드를 삽입하는 공격이에요. 예를 들어 로그인 폼에서 사용자명에 admin'; DROP TABLE users; --를 입력해서 데이터베이스를 삭제하려는 시도가 있죠.

두 번째는 인증 및 세션 관리 취약점입니다. 약한 비밀번호 정책이나 세션 하이재킹 같은 문제들이 여기에 해당합니다.

세 번째는 민감 데이터 노출로, 개인정보나 신용카드 정보 같은 중요한 데이터가 암호화되지 않고 저장되거나 전송되는 문제입니다.

실제 프로젝트에서는 이런 취약점들을 방지하기 위해 입력값 검증, PreparedStatement 사용, HTTPS 적용 등의 대책을 적용했습니다.

2. SQL Injection 공격을 방어하는 방법은 무엇인가요?

답변: SQL Injection은 사용자 입력을 그대로 SQL 쿼리에 삽입할 때 발생하는 가장 위험한 공격 중 하나입니다.

주요 방어 방법을 설명드리겠습니다:

첫 번째로 Prepared Statement를 사용합니다. 이는 쿼리 구조를 미리 컴파일하고 파라미터만 따로 바인딩하는 방식이에요. 사용자 입력이 SQL 구문으로 해석되지 않기 때문에 가장 효과적인 방법입니다.

두 번째는 입력값 검증입니다. 화이트리스트 방식으로 허용되는 문자만 받아들이고, 길이 제한을 두며, 정규표현식으로 형식을 검증합니다.

세 번째는 ORM 프레임워크 활용입니다. JPA나 MyBatis 같은 ORM을 사용하면 자동으로 파라미터 바인딩을 해주기 때문에 SQL Injection 위험이 크게 줄어듭니다.

네 번째는 데이터베이스 권한 최소화입니다. 애플리케이션용 데이터베이스 계정에는 꼭 필요한 테이블과 기능에만 접근할 수 있도록 권한을 제한합니다.

실제로 이전 프로젝트에서 레거시 코드를 점검하다가 문자열 연결로 만든 동적 쿼리를 발견해서 모두 PreparedStatement로 교체한 경험이 있어요.

3. XSS(Cross-Site Scripting) 공격에 대해 설명하고 방어 방법을 알려주세요.

답변: XSS는 악성 스크립트를 웹페이지에 삽입해서 다른 사용자의 브라우저에서 실행시키는 공격입니다.

XSS 공격 유형은 크게 3가지입니다:

저장형 XSS는 게시판이나 댓글에 악성 스크립트를 저장해두고, 다른 사용자가 해당 페이지를 볼 때마다 실행되는 방식입니다.

반사형 XSS는 URL 파라미터나 검색어에 스크립트를 포함시켜서 즉시 실행시키는 방식이에요.

DOM 기반 XSS는 클라이언트 측 자바스크립트에서 DOM을 조작할 때 발생하는 공격입니다.

방어 방법으로는 먼저 입력값 필터링과 검증을 합니다. <script> 태그나 javascript: 같은 위험한 패턴을 제거하거나 차단해요.

출력값 인코딩도 중요합니다. HTML에 출력할 때 <를 &lt;로, >를 &gt;로 변환해서 스크립트가 실행되지 않게 합니다.

CSP(Content Security Policy) 헤더를 설정해서 허용된 소스에서만 스크립트를 실행하도록 제한할 수도 있어요.

HttpOnly 쿠키를 사용하면 자바스크립트에서 쿠키에 접근할 수 없어서 세션 하이재킹을 방지할 수 있습니다.

실무에서는 템플릿 엔진의 자동 이스케이프 기능을 활용하고, 사용자가 입력한 HTML을 허용해야 할 때는 DOMPurify 같은 검증된 라이브러리를 사용했습니다.

4. CSRF(Cross-Site Request Forgery) 공격과 방어 방법을 설명해주세요.

답변: CSRF는 사용자가 자신도 모르게 다른 사이트에서 악의적인 요청을 보내도록 하는 공격입니다.

공격 시나리오를 예를 들어 설명하면, 사용자가 인터넷 뱅킹에 로그인한 상태에서 악성 사이트를 방문했다고 가정해보세요. 그 사이트에 숨겨진 폼이 있어서 자동으로 은행 사이트로 이체 요청을 보냅니다. 브라우저는 자동으로 뱅킹 사이트의 쿠키를 포함해서 요청을 보내기 때문에, 은행 서버는 정상적인 요청으로 인식하고 이체를 처리할 수 있어요.

방어 방법은 여러 가지가 있습니다:

CSRF 토큰이 가장 효과적인 방법입니다. 서버에서 예측할 수 없는 토큰을 생성해서 폼에 포함시키고, 요청이 올 때마다 이 토큰을 검증합니다. 공격자는 이 토큰을 알 수 없기 때문에 공격이 실패하게 됩니다.

SameSite 쿠키 속성을 사용하는 방법도 있어요. 이를 Strict로 설정하면 크로스 사이트 요청에서는 쿠키가 전송되지 않습니다.

Referer 검증으로 요청이 어느 사이트에서 왔는지 확인할 수도 있지만, 이 방법은 프록시나 방화벽에서 Referer 헤더를 제거할 수 있어서 완전하지 않아요.

중요한 작업에 재인증 요구하는 것도 좋은 방법입니다. 이체나 비밀번호 변경 같은 중요한 작업을 할 때는 비밀번호를 다시 입력하게 하면 CSRF 공격을 막을 수 있습니다.

실제 프로젝트에서는 Spring Security의 CSRF 보호 기능을 활용했고, API는 JWT 토큰을 사용해서 CSRF 위험을 줄였어요.

5. 인증(Authentication)과 인가(Authorization)의 차이점과 구현 방법을 설명해주세요.

답변: 인증과 인가는 보안의 핵심 개념이지만 서로 다른 역할을 합니다.

**인증(Authentication)**은 "누구인가?"를 확인하는 과정입니다. 사용자가 본인이라고 주장하는 그 사람이 맞는지 검증하는 거죠. 아파트에 들어갈 때 출입카드나 비밀번호로 주민인지 확인하는 것과 같아요.

**인가(Authorization)**는 "무엇을 할 수 있는가?"를 결정하는 과정입니다. 인증된 사용자가 특정 리소스나 기능에 접근할 권한이 있는지 확인하는 거예요. 아파트 주민이라고 해서 모든 층에 들어갈 수 있는 건 아니잖아요.

인증 구현 방법으로는 여러 가지가 있습니다:

세션 기반 인증은 전통적인 방법으로, 로그인 성공 시 서버에 세션을 생성하고 클라이언트에는 세션 ID만 전달합니다.

JWT 토큰 기반 인증은 최근에 많이 사용하는 방법으로, 사용자 정보를 암호화해서 토큰으로 만들고 이를 클라이언트가 보관합니다.

OAuth 2.0은 제3자 인증을 위한 표준으로, Google이나 Facebook 계정으로 로그인할 때 사용해요.

인가 구현 방법으로는:

**역할 기반 접근 제어(RBAC)**가 가장 일반적입니다. 사용자에게 역할을 부여하고, 각 역할마다 권한을 설정하는 방식이에요.

**속성 기반 접근 제어(ABAC)**는 더 세밀한 제어가 가능합니다. 사용자의 부서, 직급, 시간대 등 다양한 속성을 고려해서 권한을 결정할 수 있어요.

실무에서는 Spring Security를 활용해서 JWT 기반 인증과 역할 기반 인가를 구현했습니다. 관리자는 모든 데이터에 접근할 수 있고, 일반 사용자는 자신의 데이터만 볼 수 있도록 설정했어요.

6. 비밀번호 보안은 어떻게 구현해야 하나요?

답변: 비밀번호 보안은 여러 단계로 나누어서 접근해야 합니다.

저장 단계에서는 절대 평문으로 저장하면 안 됩니다. 해싱을 사용해야 하는데, 단순한 MD5나 SHA-1은 이미 안전하지 않아요. BCrypt, SCrypt, Argon2 같은 느린 해싱 알고리즘을 사용해야 합니다.

BCrypt를 예로 들면, 솔트를 자동으로 생성하고 여러 번 해싱을 반복해서 공격자가 무차별 대입 공격을 하기 어렵게 만듭니다. 해싱 강도도 조절할 수 있어서 하드웨어 성능이 향상되면 더 강한 설정으로 바꿀 수 있어요.

비밀번호 정책도 중요합니다. 최소 8자 이상, 대소문자와 숫자, 특수문자를 포함하도록 하고, 이전에 사용한 비밀번호는 재사용하지 못하게 합니다. 하지만 너무 복잡하게 만들면 사용자가 메모장에 적어두거나 더 위험한 행동을 할 수 있어서 적절한 균형이 필요해요.

계정 잠금 정책으로 브루트포스 공격을 방지할 수 있습니다. 5번 연속 실패하면 30분간 계정을 잠그는 식으로 설정하죠. 하지만 이것도 정당한 사용자를 차단할 수 있어서 IP 기반 제한과 함께 사용하는 게 좋습니다.

**다중 인증(MFA)**을 도입하는 것도 좋은 방법입니다. 비밀번호 외에 SMS나 OTP 앱을 통한 추가 인증 단계를 거치면 비밀번호가 유출되어도 계정을 보호할 수 있어요.

실제 프로젝트에서는 BCrypt를 사용해서 비밀번호를 해싱하고, 5회 실패 시 계정을 잠그는 정책을 적용했습니다. 중요한 관리자 계정에는 Google Authenticator를 이용한 2단계 인증을 추가로 설정했어요.

7. API 보안은 어떻게 구현하나요?

답변: API 보안은 여러 계층에서 접근해야 합니다.

인증과 인가가 기본입니다. API 키, JWT 토큰, OAuth 2.0 같은 방식으로 누가 API를 사용하는지 확인하고, 어떤 데이터에 접근할 수 있는지 제어해야 해요.

Rate Limiting으로 남용을 방지합니다. 같은 사용자나 IP에서 너무 많은 요청을 보내면 일시적으로 차단하는 거죠. 이는 DDoS 공격이나 데이터 크롤링을 막는 데 효과적입니다.

입력값 검증은 필수입니다. 클라이언트에서 오는 모든 데이터를 검증해야 해요. 데이터 타입, 길이, 형식, 허용되는 값의 범위 등을 모두 확인합니다.

HTTPS 사용은 기본 중의 기본입니다. 모든 API 통신을 암호화해서 중간자 공격을 방지해야 해요.

에러 메시지 관리도 중요합니다. 너무 자세한 에러 메시지는 공격자에게 시스템 정보를 제공할 수 있어서, 일반적인 메시지만 클라이언트에 전달하고 상세한 정보는 서버 로그에만 기록합니다.

로깅과 모니터링으로 이상한 패턴을 감지할 수 있어요. 평소와 다른 대량의 요청이나 실패율이 높은 경우를 실시간으로 감지해서 대응할 수 있습니다.

실무에서는 Spring Security를 사용해서 JWT 기반 인증을 구현하고, Redis로 Rate Limiting을 적용했습니다. 모든 API 요청과 응답을 로그로 기록해서 이상 징후를 모니터링했어요.

8. 데이터 암호화는 어떻게 구현하나요?

답변: 데이터 암호화는 저장 데이터와 전송 데이터로 나누어서 생각해야 합니다.

전송 중 암호화는 HTTPS/TLS를 사용하는 것이 표준입니다. 클라이언트와 서버 간의 모든 통신을 암호화해서 중간에 가로채도 내용을 알 수 없게 만들어요. 요즘은 Let's Encrypt 같은 무료 인증서도 있어서 모든 사이트에서 HTTPS를 사용할 수 있습니다.

저장 데이터 암호화는 더 복잡합니다. 개인정보, 신용카드 번호, 주민번호 같은 민감한 데이터는 반드시 암호화해서 저장해야 해요.

대칭키 암호화인 AES를 주로 사용합니다. AES-256 GCM 모드가 안전하고 성능도 좋아서 많이 선택해요. 암호화 키 관리가 가장 중요한데, 코드에 하드코딩하면 절대 안 되고 별도의 키 관리 시스템이나 환경변수로 관리해야 합니다.

필드 레벨 암호화를 구현하면 데이터베이스 관리자도 민감한 정보를 볼 수 없어요. JPA에서는 AttributeConverter를 사용해서 자동으로 암호화/복호화가 되도록 구현할 수 있습니다.

해싱과 암호화의 차이도 알아야 합니다. 비밀번호는 복구할 필요가 없으니까 해싱을 사용하고, 주민번호나 신용카드 번호처럼 나중에 복호화해야 하는 데이터는 암호화를 사용해야 해요.

**키 순환(Key Rotation)**도 중요합니다. 암호화 키를 주기적으로 바꿔줘야 보안성을 유지할 수 있어요.

실제 프로젝트에서는 개인정보 보호법 때문에 주민번호와 전화번호를 AES로 암호화해서 저장했습니다. AWS KMS를 사용해서 키를 안전하게 관리하고, 정기적으로 키를 교체하는 정책을 수립했어요.

9. 보안 로깅과 모니터링은 어떻게 해야 하나요?

답변: 보안 로깅과 모니터링은 사후 대응과 예방 모두에 중요한 역할을 합니다.

기록해야 할 보안 이벤트들이 있어요. 로그인 성공/실패, 권한이 없는 리소스 접근 시도, 비정상적인 API 호출 패턴, 대량의 데이터 다운로드, 관리자 권한 사용 등을 모두 기록해야 합니다.

로그에 포함될 정보로는 타임스탬프, 사용자 ID, IP 주소, User-Agent, 요청 URL, 응답 상태코드, 소요 시간 등이 있어요. 하지만 비밀번호나 개인정보는 절대 로그에 기록하면 안 됩니다.

실시간 모니터링도 중요합니다. 1분 동안 로그인 실패가 100번 이상 발생하거나, 같은 IP에서 대량의 요청이 오거나, 평소와 다른 시간대에 관리자 로그인이 있으면 즉시 알림을 받을 수 있도록 설정해야 해요.

로그 보안도 신경써야 합니다. 공격자가 로그를 조작하거나 삭제할 수 있으면 안 되니까, 로그 서버에 대한 접근을 제한하고 로그 파일을 암호화해서 저장하기도 해요.

SIEM(Security Information and Event Management) 도구를 사용하면 다양한 소스의 로그를 통합해서 분석할 수 있습니다. 패턴 분석으로 새로운 공격 유형도 감지할 수 있어요.

대응 프로세스도 미리 정해둬야 합니다. 특정 임계값을 넘으면 자동으로 IP를 차단하거나, 담당자에게 알림을 보내거나, 계정을 일시 잠금하는 등의 자동화된 대응을 설정할 수 있어요.

실무에서는 ELK 스택을 사용해서 모든 보안 이벤트를 수집하고 분석했습니다. Slack으로 실시간 알림을 받고, 주요 지표들은 대시보드로 만들어서 모니터링했어요. 특히 새벽 시간대 관리자 로그인이나 해외 IP에서의 접근에 대해서는 즉시 알림이 가도록 설정했습니다.

핵심 정리

웹 애플리케이션 보안은 한 번 설정하고 끝나는 것이 아니라 지속적으로 관리해야 하는 영역입니다. 방어 깊이(Defense in Depth) 전략에 따라 여러 보안 계층을 구축하는 것이 중요해요.

면접에서 중요한 포인트:

• 이론적 지식보다는 실제 구현 경험을 구체적으로 설명
• 보안과 사용성, 성능 사이의 트레이드오프를 어떻게 해결했는지
• 보안 사고 대응 경험이나 취약점을 발견하고 해결한 경험
• 최신 보안 동향에 대한 관심과 지속적인 학습 의지

보안은 개발자 혼자 할 수 있는 일이 아니라 팀 전체가 보안 마인드를 가져야 하는 영역입니다. 개발 프로세스 전반에 보안을 고려하는 시큐어 코딩의 중요성을 강조할 수 있다면 더욱 좋은 평가를 받을 수 있을 거예요.