Swift 시니어 보안 기술면접
새 면접Q. iOS 앱에서 JWT 토큰 기반 인증을 구현할 때, 토큰 저장소로 Keychain, UserDefaults, 메모리 중 어떤 것을 선택해야 하며, 각각의 보안 위험성과 트레이드오프는 무엇인가요? 또한 Refresh Token 전략을 어떻게 설계하시겠습니까?
각 저장소의 데이터 지속성, 암호화 여부, 백업 정책, 접근 제어를 고려해보세요.
Access Token은 Keychain에 저장해야 합니다. Keychain은 하드웨어 기반 암호화를 제공하고 앱 삭제 시에도 데이터가 남아있으며, kSecAttrAccessible 속성으로 접근 제어가 가능합니다. UserDefaults는 평문으로 저장되어 탈옥된 기기에서 쉽게 노출되므로 절대 사용하면 안 됩니다. 메모리 저장은 앱 종료 시 사라지므로 UX가 나쁩니다. Refresh Token은 Keychain에 kSecAttrAccessibleWhenUnlockedThisDeviceOnly로 저장하여 iCloud 백업을 방지하고, 기기 잠금 해제 시에만 접근 가능하도록 해야 합니다. Token rotation 전략을 구현하여 Refresh Token 사용 시마다 새로운 토큰을 발급받고, 서버에서 이전 토큰을 무효화하여 탈취 위험을 최소화해야 합니다.
- • Keychain의 하드웨어 기반 암호화와 kSecAttrAccessible 속성 활용
- • UserDefaults는 평문 저장으로 보안에 부적합
- • Refresh Token은 kSecAttrAccessibleWhenUnlockedThisDeviceOnly로 iCloud 백업 방지
- • Token rotation 전략으로 탈취 위험 최소화
금융앱이나 의료앱에서 사용자 인증 정보를 안전하게 저장하고 세션을 관리할 때 필수적입니다.
Keychain Sharing을 사용하여 여러 앱 간 토큰을 공유해야 하는 경우, 보안을 어떻게 강화하시겠습니까?
Q. iOS 앱에서 사용자의 민감한 개인정보(주민등록번호, 카드번호 등)를 로컬에 저장해야 하는 상황입니다. CryptoKit을 사용한 암호화 전략을 설계할 때, 암호화 키 관리 방법과 키 유도 함수(KDF) 선택, 그리고 데이터 마이그레이션 시나리오를 어떻게 처리하시겠습니까?
사용자 비밀번호나 생체인증을 키 소스로 활용하고, Secure Enclave의 역할을 고려해보세요.
CryptoKit의 AES-GCM을 사용하여 AEAD(인증된 암호화)를 구현해야 합니다. 암호화 키는 Secure Enclave에 저장된 개인키로 보호하며, 사용자 생체인증을 통해서만 접근 가능하도록 SecAccessControl을 설정합니다. 직접적인 사용자 비밀번호를 키로 사용하지 않고, PBKDF2나 CryptoKit의 HKDF를 사용하여 키를 유도해야 합니다. 데이터 암호화 키(DEK)와 키 암호화 키(KEK) 이중 구조를 사용하여, 비밀번호 변경 시 DEK는 유지하고 KEK만 재생성하면 됩니다. 앱 업데이트로 암호화 알고리즘이 변경되는 경우, 버전 메타데이터를 함께 저장하고 lazy migration 전략으로 사용자가 데이터 접근 시점에 점진적으로 마이그레이션합니다. 모든 암호화 작업은 백그라운드 큐에서 수행하여 메인 스레드 블로킹을 방지해야 합니다.
- • AES-GCM으로 AEAD 구현하여 무결성과 기밀성 동시 보장
- • Secure Enclave와 생체인증 기반 키 보호
- • DEK/KEK 이중 구조로 비밀번호 변경 시 재암호화 비용 최소화
- • 버전 메타데이터와 lazy migration으로 안전한 알고리즘 전환
금융앱에서 카드정보나 계좌정보를 오프라인에서도 사용할 수 있도록 안전하게 저장할 때 사용됩니다.
양자컴퓨터 시대를 대비한 Post-Quantum Cryptography 전환을 고려한다면 어떤 준비가 필요할까요?
Q. iOS 앱에서 Certificate Pinning을 구현할 때, Public Key Pinning과 Certificate Pinning의 차이점과 각각의 장단점을 설명하고, 인증서 갱신 시나리오에 대비한 안전한 업데이트 전략을 제시해주세요. 또한 URLSession의 어떤 delegate 메서드를 활용해야 하나요?
인증서 만료 주기와 앱 배포 주기의 불일치 문제를 고려해보세요.
Certificate Pinning은 전체 인증서를 검증하므로 구현이 간단하지만, 인증서 갱신 시(보통 1년 주기) 앱 업데이트가 필수입니다. Public Key Pinning은 공개키만 검증하므로 인증서가 갱신되어도 같은 키 쌍을 사용하면 앱 업데이트가 불필요합니다. URLSessionDelegate의 urlSession(_:didReceive:completionHandler:) 메서드에서 challenge.protectionSpace.authenticationMethod가 NSURLAuthenticationMethodServerTrust인 경우 SecTrust를 검증합니다. 안전한 업데이트 전략으로는 첫째, 주 인증서와 백업 인증서 여러 개를 함께 pinning하고, 둘째, 원격 설정(Firebase Remote Config 등)으로 pin 목록을 동적으로 업데이트하되 서명 검증을 필수로 하며, 셋째, 인증서 만료 3개월 전부터 새 인증서를 미리 배포하는 overlapping 전략을 사용해야 합니다. 또한 pinning 실패 시 fallback 로직과 kill switch를 구현하여 긴급 상황에 대응할 수 있어야 합니다.
- • Public Key Pinning이 인증서 갱신에 더 유연함
- • urlSession(_:didReceive:completionHandler:)에서 SecTrust 검증
- • 주 인증서와 백업 인증서 복수 pinning
- • 원격 설정과 overlapping 전략으로 안전한 업데이트
뱅킹앱이나 결제앱에서 API 서버와의 통신을 보호하여 중간자 공격을 방지할 때 필수적으로 구현합니다.
중간자 공격을 탐지하기 위해 앱에서 추가로 구현할 수 있는 보안 메커니즘은 무엇이 있을까요?
Q. 대규모 사용자를 보유한 iOS 앱에서 사용자 행동 로그를 수집할 때, GDPR과 개인정보보호법을 준수하면서도 효과적인 분석이 가능하도록 하는 데이터 수집 아키텍처를 설계해주세요. 특히 민감정보 필터링과 익명화 처리 전략을 중심으로 설명해주세요.
개인 식별 가능 정보(PII)와 가명처리, 그리고 사용자 동의 관리를 중심으로 생각해보세요.
로그 수집 시스템에 다층 필터링 아키텍처를 구현해야 합니다. 첫 번째 레이어에서 이메일, 전화번호, 주민번호 등 PII를 정규식으로 탐지하여 자동으로 마스킹하거나 제거합니다. 두 번째 레이어에서 사용자 ID는 SHA-256 해싱과 솔트를 사용하여 가명처리하되, 세션별로 다른 솔트를 사용하여 크로스 세션 추적을 방지합니다. 사용자 동의 상태를 ConsentManager 싱글톤으로 관리하고, 필수/선택/마케팅 등 목적별로 세분화된 동의를 받아 UserDefaults와 서버에 이중으로 저장합니다. 민감한 화면(비밀번호 입력, 카드정보 등)에서는 자동 로깅을 비활성화하는 allowlist 방식을 사용하고, 로그 전송 전 로컬에서 PII 검출 엔진을 한 번 더 실행합니다. 또한 데이터 보관 기간을 명시하고 자동 삭제 정책을 구현하여 불필요한 데이터 축적을 방지해야 합니다.
- • 다층 필터링으로 PII 자동 탐지 및 제거
- • SHA-256 해싱과 세션별 솔트로 가명처리
- • 목적별 세분화된 동의 관리 시스템
- • 민감 화면 allowlist와 자동 삭제 정책
글로벌 서비스를 제공하는 앱에서 EU 사용자의 개인정보를 수집할 때 법적 리스크를 최소화하기 위해 필수적입니다.
사용자가 데이터 삭제 요청(Right to be Forgotten)을 했을 때, 이미 수집된 로그와 분석 데이터를 어떻게 처리하시겠습니까?
Q. Swift로 작성된 iOS 앱의 바이너리를 리버스 엔지니어링으로부터 보호하기 위한 다층 방어 전략을 설계해주세요. 난독화, 무결성 검증, 탈옥 탐지, 디버거 감지 등을 포함하여 설명하고, 각 기법의 한계점도 함께 언급해주세요.
완벽한 보호는 불가능하므로 공격 비용을 높이는 것이 목표임을 고려하세요.
첫째, SwiftShield나 상용 도구로 클래스명과 메서드명을 난독화하되, Swift의 동적 특성상 완전한 난독화는 불가능하므로 핵심 비즈니스 로직만 선별적으로 적용합니다. 둘째, 앱 시작 시 Mach-O 파일의 해시값을 계산하여 서버의 값과 비교하는 무결성 검증을 구현하되, 검증 코드 자체도 난독화해야 합니다. 셋째, stat 함수로 /Applications/Cydia.app 존재 여부 확인, fork 함수 호출 성공 여부, dyld_get_image_name으로 수상한 라이브러리 로드 탐지 등으로 탈옥을 감지합니다. 넷째, sysctl로 P_TRACED 플래그를 확인하거나 ptrace(PT_DENY_ATTACH)를 호출하여 디버거 부착을 방지합니다. 다섯째, 민감한 상수값은 코드에 직접 하드코딩하지 않고 XOR이나 간단한 알고리즘으로 인코딩하여 저장합니다. 하지만 이 모든 기법은 숙련된 공격자에게는 우회 가능하므로, 서버 사이드 검증과 비즈니스 로직의 서버 이관을 병행해야 합니다.
- • 선별적 난독화로 핵심 로직 보호
- • Mach-O 해시 기반 무결성 검증
- • 다중 기법 조합으로 탈옥과 디버거 탐지
- • 클라이언트 보안의 한계 인정하고 서버 사이드 검증 병행
금융앱이나 DRM이 적용된 콘텐츠 앱에서 핵심 비즈니스 로직과 암호화 키를 보호할 때 사용됩니다.
런타임에 메모리 덤프를 통해 민감한 데이터가 노출되는 것을 방지하기 위한 추가 기법은 무엇이 있을까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!