[태그:] 사이버보안

몸값을 냈는데도 파일이 돌아오지 않는다. 이건 이미 알려진 얘기다. 근데 최근엔 한 술 더 뜬다. 특정 코딩 오류로 인해 128KB를 초과하는 파일은 애초에 복구 불능 상태로 파괴되어버리는 랜섬웨어까지 나왔다. Tom’s Hardware 보도를 보면, 돈을 내든 안 내든 파일은 그냥 사라진다. 읽으면서 솔직히 좀 아찔했다. 랜섬웨어가 ‘암호화 → 인질’ 공식에서 ‘그냥 다 부숴버리기’로 진화하고 있다는 얘기다.

랜섬웨어, 이제는 암호화도 아니다

원래 랜섬웨어의 공식은 이랬다. 파일을 잠그고, 돈을 받으면 키를 준다. 범죄자 입장에서도 ‘신뢰’가 필요했으니까. 근데 그 공식이 깨지고 있다. 최근 보안 업계 보고서들을 보면 몸값 지불 후에도 복구 키가 아예 안 오는 경우가 늘었고, 기술적 결함으로 인해 파일 자체를 되살릴 수 없는 상태로 만들어버리는 변종도 확인됐다. 128KB 초과 파일을 죄다 망가뜨리는 랜섬웨어가 그 예다. 이 경우엔 몸값을 내도 아무 의미가 없다. 처음부터 복구가 불가능하니까.

결론은 단순하다. 감염되지 않는 게 최선이고, 감염됐을 때 살아남으려면 백업밖에 없다.

감염 전에 해야 할 것들

예방의 핵심은 세 가지다. 백업, 업데이트, 의심.

• 3-2-1 백업 규칙: 가장 확실한 방어선이다. 데이터 복사본 3개, 서로 다른 저장 매체 2개(PC 내장, 외장하드, 클라우드 조합), 그리고 그 중 1개는 반드시 오프라인에. 평소엔 외장하드를 PC에서 분리해놔야 한다. 랜섬웨어는 네트워크로 연결된 장치를 싹 다 감염시키기 때문이다.
  • 3개: 원본 포함 최소 3벌 보관
  • 2개: 다른 매체에 분산 — 내장 드라이브, 외장 SSD, 클라우드 중 2가지 이상
  • 1개: 네트워크 미연결 오프라인 보관. 이게 핵심이다
• OS·소프트웨어 업데이트: 귀찮아도 해야 한다. OS, 웹 브라우저, 오피스, 백신 소프트웨어 — 전부 최신 버전으로 유지해야 랜섬웨어 침투 경로를 막는다. 업데이트 미루는 습관이 보안 구멍을 열어두는 거다.
• 이메일 첨부파일 주의: 랜섬웨어 감염 경로의 상당 부분이 이메일이다. .exe, .zip, .js, .vbs 확장자 파일은 발신자를 먼저 의심해라. 링크도 클릭 전에 URL을 확인하는 습관이 필요하다.
• 강력한 비밀번호 + 2단계 인증: 계정이 털리면 끝이다. 복잡한 비밀번호에 MFA(다단계 인증)를 더하면 계정 탈취 위험이 크게 줄어든다.
• 방화벽 + 불필요한 포트 차단: 외부에서 들어오는 무단 접근을 막는 기본이다. 공유기 비밀번호를 기본값으로 쓰고 있다면 지금 당장 바꿔야 한다.

감염됐다 싶으면 이 순서대로

아무리 조심해도 감염될 여지는 있다. 그때 초기 대응이 피해 규모를 가른다.

• 네트워크 즉시 차단: 의심스러우면 일단 Wi-Fi를 끄거나 랜 케이블을 뽑아라. 랜섬웨어가 다른 기기로 번지는 걸 막고, 추가 암호화도 멈출 수 있다. 속도가 중요하다.
• 전원은 끄지 마라: 당황해서 강제 종료하면 오히려 복구 시도에 필요한 메모리 내 정보가 사라질 수 있다. 네트워크만 끊고 기기는 켜둔 채로 전문가를 기다리는 게 낫다.
• 증상 기록: 어떤 파일이 암호화됐는지, 확장자가 뭐로 바뀌었는지, 랜섬웨어 메시지는 뭐라고 나오는지 — 스크린샷이든 메모든 남겨둬라. 복구 전문가나 수사기관에 도움이 된다.
• KISA 118 상담: 한국인터넷진흥원(KISA) 118 상담센터에 신고하면 랜섬웨어 피해 복구 상담을 받을 수 있다. 혼자 끙끙대다 상황을 악화시키는 것보다 훨씬 낫다.
• 몸값 절대 내지 마라: 돈을 내도 파일을 돌려주지 않는 경우가 상당하다. 관련 연구 보고서들이 반복적으로 지적하는 내용이다. 앞서 말한 128KB 결함 랜섬웨어처럼 기술적으로 복구 자체가 불가능한 경우도 있다. 돈만 날린다.

파일 되찾기, 현실적으로 가능한가

랜섬웨어에 걸리면 복구 옵션이 몇 가지 있다. 솔직히 기대치는 낮게 잡는 게 맞다.

• 백업 복원: 제대로 된 백업이 있다면 이게 답이다. 감염된 시스템을 초기화하고 백업 데이터를 올리면 끝. 백업이 없는 경우엔 이 항목 자체가 의미 없다는 게 문제지만.
• 무료 복구 툴: 일부 랜섬웨어는 보안 업체들이 복구 툴을 만들어 무료 배포한다. ‘노모어랜섬(No More Ransom)’ 사이트에서 자신이 걸린 랜섬웨어 유형을 입력하면 복구 툴이 있는지 확인 가능하다. 단, 모든 랜섬웨어에 툴이 있는 건 아니다.
• 전문 복구 업체: 백업도 없고 무료 툴도 없다면 전문 업체에 맡기는 선택지가 남는다. 비용이 상당하고 성공을 100% 보장하지도 않는다. 그냥 현실이 그렇다.
• 손실 인정: 안타깝지만, 어떤 방법으로도 복구가 안 되는 경우가 있다. 128KB 결함 랜섬웨어처럼 처음부터 파일을 파괴해버린 경우라면 더더욱. 이게 오프라인 백업을 미리 해야 하는 이유다.

기업이라면 이것도 챙겨야 한다

기업 환경에서 랜섬웨어 피해는 규모가 다르다. 영업 자료, 고객 데이터, 내부 시스템이 한꺼번에 날아가면 회사 존립이 흔들린다. 개인용 백신 하나 설치해놓고 끝낼 수준이 아니다.

• EDR/XDR 솔루션: 엔드포인트에서 이상 징후를 실시간으로 탐지하고 대응하는 도구다. 공격이 퍼지기 전에 차단하는 데 효과적이다.
• 직원 보안 교육: 결국 사람이 뚫린다. 피싱 이메일 식별, 수상한 USB 차단, 의심스러운 사이트 접속 자제 — 정기적이고 실전적인 교육이 필요하다. 1년에 한 번 클릭만 하는 e러닝으로는 부족하다.
• 취약점 점검 + 모의 해킹: 실제로 뚫릴 수 있는 구멍이 어디 있는지 주기적으로 확인해야 한다. 모의 공격으로 방어 체계를 직접 시험해보는 것도 방법이다.
• 제로 트러스트 아키텍처: ‘아무것도 신뢰하지 않는다’는 원칙 아래, 모든 접근을 엄격히 인증하고 권한을 최소화하는 구조다. 내부자 위협과 외부 침입 양쪽 모두를 막는다.
• 보안 정책 수립: 데이터 접근 권한, 백업 주기, 사고 대응 절차 — 문서로 만들고 전 직원이 지키게 해야 한다. 정책이 없으면 사고 났을 때 우왕좌왕한다.

결국 살아남는 데이터는 오프라인 백업에서 시작된다

랜섬웨어는 계속 진화한다. 암호화에서 파괴로, 이제는 기술적 결함으로 복구 자체를 막아버리는 형태까지. 첨단 보안 솔루션도 중요하지만, 결정적으로 데이터를 지키는 건 오프라인 백업이다. 3-2-1 규칙을 생활화하고, 외장하드는 평소에 분리해놓고, 주기적으로 백업 상태를 점검해라. 완벽한 방어는 없다. 하지만 백업만 제대로 돼 있으면 랜섬웨어는 그냥 ‘불편한 사건’으로 끝난다.

출처: Reddit r/technology

삭제 버튼을 눌러도 데이터는 바로 사라지지 않는다. 메시지든 사진이든 마찬가지다. TechCrunch 보도를 보면, 아이폰과 아이패드에서 특정 메시징 앱으로 주고받은 삭제된 대화 내용이 법 집행기관의 포렌식 도구로 복구됐다는 내용이 나온다. 단순한 앱 버그가 아니다. iOS 자체의 데이터 관리 방식이 연루돼 있다. 내 스마트폰 ‘삭제’가 얼마나 믿을 만한지, 그리고 진짜로 지우려면 어떻게 해야 하는지 따져봤다.

‘삭제’가 실제로 하는 일

파일을 지울 때 데이터가 즉시 저장 공간에서 완전히 사라지는 경우는 드물다. 운영체제는 파일을 ‘삭제됨’으로 표시만 하고, 해당 공간을 ‘새 데이터를 넣을 수 있음’ 상태로 바꿔놓는다. 도서관에서 책을 폐기하는 대신 목록에서만 지우고 서가엔 그냥 꽂아두는 것과 같다. 표시만 바꿨을 뿐, 책은 그대로다.

• 포인터 제거: 파일 시스템은 파일 위치를 가리키는 ‘포인터’로 데이터를 추적한다. 삭제는 이 포인터만 없애는 행위다.
• 데이터는 남아 있음: 포인터가 사라져도 실제 데이터는 저장 장치에 물리적으로 그대로 남는다.
• 덮어쓰기 전까지 유지: 새로운 데이터가 그 공간에 써지기 전까지 원본 데이터는 유지된다.

이게 삭제된 데이터 복구의 핵심 원리다. 단순하지만 여기서 모든 게 시작된다.

아이폰에서 삭제된 메시지가 복구되는 과정

iOS는 보안이 강하다고들 하지만 이 원칙에서 벗어나진 않는다. 메시징 앱 데이터는 보통 SQLite 데이터베이스 형태로 저장된다. 사용자가 메시지를 지워도 데이터베이스 안 레코드가 ‘삭제됨’으로 표시될 뿐, 물리적 데이터 블록은 즉시 사라지지 않는 구조다. 포렌식 도구는 이 잔여물이나 캐시, 로그 파일을 뒤져 삭제된 정보를 재구성한다.

• 데이터베이스 잔여물: 메시징 앱이 쓰는 데이터베이스는 삭제된 데이터를 즉시 퍼지(purge)하지 않는 경우가 많다. 공간을 재사용할 시점까지 그냥 놔두는 구조다.
• 메모리 덤프 및 스냅샷: iOS는 여러 이유로 메모리나 저장 장치의 스냅샷을 만든다. 여기에 삭제된 데이터 흔적이 포함되기도 한다.
• 샌드박스 환경의 한계: 앱은 샌드박스 안에서 격리돼 작동하지만, iOS 자체의 데이터 관리 영역은 앱이 통제하지 못한다. 그 틈새를 포렌식 도구가 파고든다.

앱 개발사가 의도적으로 심어둔 게 아니다. 운영체제의 복잡한 데이터 관리 로직과 포렌식 기술 발전이 맞물려서 생기는 문제다.

시그널도 완벽하진 않다

시그널(Signal)을 쓰면 안전하다고 생각하는 사람이 많다. 전송 구간만 놓고 보면 틀린 말도 아니다. 종단 간 암호화(E2EE)는 메시지가 서버를 거치는 동안 제3자가 내용을 가로채지 못하게 막아준다. 근데 메시지가 기기에 도착한 다음이 문제다. 암호화는 ‘전송 중’ 보안이지, ‘저장 후’ 보안이 아니다.

• 전송 과정은 안전: E2EE는 서버를 통해 수신자에게 전달되는 구간에서 강력하게 작동한다.
• 저장된 데이터의 보안: 기기 내부에 저장된 이후로는 해당 기기의 보안 정책과 iOS 데이터 관리 방식에 따라 달라진다.
• 삭제 후 복구 문제: 기기 안에 암호화된 메시지 잔여물이 남아 있고 포렌식 도구가 이를 복구한다면, 암호화된 상태라도 잠재적 위협이다. 물론 복구된 데이터가 여전히 암호화돼 있다면 추가 해독 과정이 필요하다.

결국 암호화 메신저를 써도 기기 자체의 데이터 삭제 습관이 보안을 좌우한다. 이 부분은 앱이 대신해줄 수 없다.

민감한 데이터를 확실히 지우는 방법들

디지털 세상에서 ‘완전 삭제’는 생각보다 손이 간다. 그래도 복구 가능성을 크게 낮추는 방법은 있다.

• 데이터 덮어쓰기 (Overwriting): 파일을 삭제한 후 해당 공간에 의미 없는 데이터를 여러 번 덮어쓰는 방식이다. 화이트보드 글씨를 지운 뒤 그 위에 다른 글씨를 반복해서 써서 원본을 알아볼 수 없게 만드는 것과 같다.
  • 아이폰에서는 기기를 계속 사용하면 새 데이터가 기존 삭제 공간을 자연스럽게 덮어쓰기도 한다. 다만 이 과정을 수동으로 제어하기는 어렵다.
• 공장 초기화 + 새 데이터 쓰기: 기기를 팔거나 넘길 때 단순 공장 초기화만으로는 부족하다. 초기화 후 의미 없는 대용량 파일을 저장 공간 가득 채우고 다시 공장 초기화하는 과정을 1~2회 반복하길 권장한다. 기존 민감 데이터가 새 데이터로 덮일 확률을 높이는 방식이다.
• 앱의 ‘데이터 삭제 및 초기화’ 기능 활용: 시그널 같은 메시징 앱은 설정 안에 ‘계정 삭제’ 또는 ‘데이터 삭제 및 초기화’ 기능을 따로 제공한다. 단순히 메시지를 지우는 수준을 넘어 앱 관련 데이터 전체를 기기에서 걷어내는 방식이라 일반 삭제보다 훨씬 확실하다.
• 클라우드 백업 관리: iCloud 같은 클라우드 서비스에 민감 데이터가 올라가 있을 수 있다. 기기에서 지워도 클라우드 백업엔 그대로 남는 경우가 흔하다. 백업 설정을 정기적으로 들여다보고 불필요한 데이터를 제거하는 게 맞다.
• 강력한 암호 설정과 정기적 정리: 강한 암호 설정은 기본이다. 여기에 불필요한 앱과 데이터를 주기적으로 지워주는 습관을 더하면 데이터 잔여물이 쌓이는 걸 최소화할 수 있다.

디지털 프라이버시를 지키는 현실적인 습관

완벽한 프라이버시는 없다. 디지털 흔적은 어딘가에 남는다. 그게 현실이다. 핵심은 얼마나 덜 남기고, 남더라도 읽기 어렵게 만드느냐다.

• 의식적인 접근: 모든 디지털 활동엔 흔적이 남을 수 있다는 걸 전제로 움직이는 게 맞다.
• 신중한 공유: 민감한 정보는 처음부터 안 보내거나, 꼭 필요한 경우에만 최소한으로 공유하는 것이 최선의 보안 전략이다. 어떤 암호화 설정보다 이게 더 확실하다.
• 최신 보안 유지: iOS와 앱을 항상 최신 버전으로 업데이트하면 알려진 보안 취약점이 패치된다. 애플이 이번 포렌식 복구 관련 버그를 수정한 것처럼, 업데이트는 실질적인 방어선이다.

‘삭제’ 버튼 하나로 모든 흔적이 사라진다는 건 착각이다. 데이터의 생명 주기를 이해하고 기기 관리 습관을 바꾸는 것이 프라이버시를 지키는 훨씬 현실적인 방법이다.

자주 묻는 것들

Q: iCloud 백업에도 삭제된 메시지가 남을 수 있나요?
A: 남는다. 아이폰에서 메시지를 지워도 삭제 이전에 생성된 iCloud 백업엔 해당 메시지가 그대로 들어 있다. iCloud 설정에서 메시지 앱 백업 여부를 확인하고, 오래된 백업은 정리하는 것이 좋다.

Q: 안드로이드도 아이폰과 같은 구조인가요?
A: 기본 원리는 같다. 안드로이드도 파일 시스템이 데이터를 ‘삭제’로 표시하고 덮어쓰기를 기다리는 방식이다. 포렌식 도구를 통해 삭제된 데이터를 복구할 여지가 충분히 있다.

Q: 중고로 기기를 팔 때는 어떻게 해야 가장 안전한가요?
A: 공장 초기화 후 대용량의 의미 없는 파일(예: 긴 동영상)로 저장 공간을 꽉 채우고 다시 공장 초기화한다. 이 과정을 1~2회 반복하면 기존 데이터가 새 데이터로 여러 번 덮어쓰여져 복구 가능성이 크게 줄어든다.

출처: TechCrunch

Vercel이 해킹당했다. The Verge가 전한 바에 따르면 빌드 파이프라인이 뚫리면서 수백 개 프로젝트의 환경 변수와 API 키가 노출됐다. 소스코드는 덤이었다. “우리 같은 작은 팀은 괜찮겠지”라는 생각, 솔직히 지금도 하고 있다면 위험하다. 해커들은 오히려 보안 투자가 적은 스타트업과 1인 개발자를 더 쉬운 목표로 본다. 규모와 관계없이, 클라우드 개발 환경을 쓰는 팀이라면 지금 당장 점검해야 할 사항들이다.

클라우드 개발 플랫폼이 터지면 뭐가 문제냐

코드 저장소, 빌드 시스템, 배포 파이프라인, 운영 환경. 이 네 가지가 한 플랫폼에 몰려있다. 한 곳이 뚫리면 연쇄반응이다. 해커가 주로 노리는 건 크게 4가지다:

• 민감 데이터 탈취: API 키, 인증 토큰, 개발자 계정 정보 등.
• 소스코드 유출: 팔거나, 경쟁사에 넘기거나. 기업 핵심 자산이 통째로 노출된다.
• 파이프라인 장악: CI/CD를 건드려 악성코드를 삽입하거나 서비스 자체를 마비시킨다.
• 자원 오용: 암호화폐 채굴용으로 서버를 무단 사용. 청구 요금 폭탄은 덤이다.

금전 피해만이 아니다. 신뢰도 타격이 더 무섭다. 데이터 유출 사고 한 번에 고객사가 등 돌리는 속도는 생각보다 빠르다. 결국 클라우드 개발 플랫폼 보안은 기술 문제가 아니라 비즈니스 생존의 문제다.

인증부터 제대로: MFA 없으면 나머지는 허울이다

비밀번호 하나로 막겠다는 건 2010년대 발상이다. 지금은 최소 2단계 인증이 기본이다.

• 다단계 인증(MFA) 의무화: SMS, OTP 앱(Google Authenticator, Authy), 하드웨어 키(YubiKey) — 어느 것이든 좋다. 비밀번호가 털려도 추가 장벽에 막힌다. 개발자·관리자 계정 전부 예외 없이 적용해야 한다. “귀찮다”는 이유로 예외를 두면 그게 구멍이 된다.
• SSO(싱글 사인온) 활용: 여러 서비스를 하나의 인증 체계로 묶으면 퇴사자 계정 삭제와 권한 변경이 한 곳에서 처리된다. 대기업만의 얘기가 아니다. Okta Free나 Google Workspace 기반 SSO면 10인 팀도 충분하다. 관리 효율과 보안, 두 가지를 동시에 잡는 방법이다.
• 비밀번호 정책: 대문자+소문자+숫자+특수문자 조합, 12자 이상, 90일 주기 변경. 최소 기준이다. ‘password123’은 논외다.
• API 키·토큰 관리: 코드에 직접 박아놓는 경우를 아직도 종종 본다. 환경 변수로 분리하고, 접근 범위를 최소화하고, 주기적으로 갱신해야 한다. 자동화 프로세스에서 쓰는 토큰도 개인 계정 비밀번호만큼 중요하게 다뤄야 한다.

소스코드 저장소 보안: 핵심 자산인데 허술하게 두는 경우가 많다

GitHub, GitLab, Bitbucket — 여기가 뚫리면 게임 오버다.

• 역할 기반 접근 제어(RBAC): 프론트엔드 개발자가 DB 마이그레이션 브랜치에 직접 푸시할 이유가 없다. 각 팀원에게 딱 필요한 권한만, 나머지는 차단이다. 불필요한 접근을 철저히 막는 것이 저장소 보안의 핵심이다.
• 시크릿 스캐닝 자동화: CI/CD 파이프라인에 Gitleaks, truffleHog 같은 도구를 붙여두면 API 키나 개인정보가 커밋될 때 자동으로 잡아낸다. PR 단계에서 걸어두는 게 가장 효과적이다. 실수로 커밋되는 시크릿을 병합 전에 차단할 수 있는 실질적인 안전망이다.
• 클라우드 스토리지 암호화: 로그, 빌드 아티팩트, 임시 파일 — 클라우드 스토리지에 저장되는 모든 데이터는 암호화가 기본이다. 저장(Data at Rest)과 전송(Data in Transit) 두 경우 모두. AWS S3라면 SSE 옵션 켜는 데 5분도 안 걸린다.
• 테스트 환경 데이터 처리: 개발·테스트 환경에서 실제 사용자 데이터를 그대로 쓰는 건 습관처럼 하면 안 된다. 마스킹하거나 비식별화 처리된 데이터를 쓰면 유출 시 피해 범위가 확 줄어든다. 가장 현실적인 예방책 중 하나다.

최소 권한 원칙: 뚫려도 피해를 제한하는 법

개발자 A에게 데이터베이스 관리 권한이 필요 없다면 애초에 주지 않는다. 운영팀이 소스코드 저장소를 읽을 이유가 없다면 막는다. 단순하다. 완벽한 방어는 없다. 피해를 최소화하는 게 현실적인 목표다.

• 방화벽·보안 그룹: AWS, GCP, Azure가 제공하는 보안 그룹 기능을 적극 활용한다. 특정 IP 대역만 허용하거나, 443·22 같은 꼭 필요한 포트만 열고 나머지는 막는 식이다.
• VPN 의무화: 내부 시스템 접근에는 VPN을 기본으로 한다. 공용 와이파이에서 운영 콘솔에 직접 붙으면 중간자 공격(MITM)에 그대로 노출된다.
• 서비스 간 통신 암호화: “어차피 내부망인데”라는 생각이 구멍을 만든다. 마이크로서비스 간 통신도 HTTPS/TLS가 기본이다. 내부 통신이라고 예외를 두는 순간 공격 표면이 넓어진다.

취약점 관리: 안 하면 시간문제다

오늘 안전한 라이브러리가 내일 CVE 목록에 올라올 수 있다. 소프트웨어는 원래 완벽하지 않다.

• 정기 업데이트: 운영체제, 개발 도구, npm·pip·Maven 패키지 — 전부 최신으로 유지한다. 알려진 취약점을 막는 가장 기본적인 방법이다.
• 자동화된 취약점 스캐닝: Snyk, Trivy, Dependabot 중 하나를 CI 파이프라인에 붙여두면 PR마다 자동 검사된다. Critical·High·Medium 심각도 기준으로 우선순위를 잡고 빠르게 처리한다.
• 시크릿 관리 솔루션: HashiCorp Vault, AWS Secrets Manager 같은 전용 도구를 쓰면 API 키와 DB 자격증명을 코드 밖에서 안전하게 관리된다. 아직도 코드에 하드코딩된 시크릿이 있다면 지금 당장 옮겨야 한다. 이건 미룰 이유가 없다.

24시간 감시 체계: 이상 징후를 놓치면 이미 늦다

보안 시스템을 다 갖춰놔도 모니터링 없으면 반쪽짜리다.

• 로그 모니터링: 로그인 시도, 파일 접근, 설정·권한 변경 — 전부 수집한다. SIEM 솔루션이나 CloudWatch, Datadog을 연결해두면 비정상 패턴 감지 시 즉시 알림이 온다. 새벽 3시에 해외 IP에서 관리자 계정으로 로그인 시도가 100번 들어온다면, 아침에 출근해서야 아는 건 이미 늦은 것이다.
• 사고 대응 계획: 데이터 유출 발생 시 누가 뭘 하는지, 어떤 순서로 조사하고 보고하는지, 고객에게 어떻게 알릴지 — 사고 터진 후에 계획을 짜는 건 불가능하다. 각 담당자의 역할과 절차를 미리 명확히 정해두고, 분기 1회 정도 모의 훈련을 돌려보는 것도 생각보다 효과적이다.
• 백업 및 복구 테스트: 코드와 데이터를 정기 백업하고, 복구 시간도 주기적으로 검증한다. 백업 자체도 암호화해서 별도 위치에 보관해야 한다. 백업만 있고 복구 테스트를 안 해봤다면 없는 것과 다름없다.

결국엔 문화 문제다

기술적 솔루션을 다 갖춰도 사람이 구멍이 되면 소용없다. 아무리 강력한 MFA를 설정해놔도 피싱 메일 한 통에 속으면 끝이다.

모든 팀원이 보안의 기본을 알고, 의심스러운 상황을 즉시 보고하는 보안 문화가 필요하다. 연 1회 형식적인 보안 교육과 시큐어 코딩 원칙을 개발 프로세스에 실제로 녹이는 건 전혀 다른 얘기다. 전자는 체크박스를 채우는 것이고, 후자는 실제로 사고를 막는 것이다.

클라우드 개발 플랫폼 보안은 한 번 설정하고 잊는 게 아니다. 계속 업데이트되는 위협에 맞춰 꾸준히 점검하고 개선해야 한다. 결국 꾸준함이 전부다.

출처: The Verge

빌드 파이프라인이 코드 서명 단계에서 멈춘다. 로그를 열면 인증서 오류뿐. MS 계정에 접속하니 “비정상적인 활동이 감지됐다”는 안내가 떠 있다. 긴급 패치를 배포해야 하는데, 계정이 잠긴 상태다.

먼 나라 얘기가 아니다. TechCrunch가 2026년 4월 전한 바에 따르면, 오픈소스 WireGuard VPN 개발팀이 정확히 이 문제로 소프트웨어 업데이트 배포를 못 하는 상황을 겪었다. 코드 서명용 MS 계정 하나가 잠기면서 새 버전 출시가 통째로 막혔다.

코드 서명 인증서가 묶인 계정 잠김은 단순한 로그인 불편이 아니다. 서비스 연속성 자체가 위협받는 사고다. 왜 생기는지, 어떻게 막는지, 이미 터졌을 때 어떻게 대응하는지 실질적인 내용을 정리했다.

왜 갑자기 잠기는 걸까?

MS가 계정을 잠그는 이유는 한마디로 ‘비정상적인 활동(Unusual Activity)’ 감지다. 근데 이 ‘비정상’의 기준이 생각보다 훨씬 까다롭다. 이건 좀 억울한 면이 있다.

• 접속 환경이 갑자기 바뀔 때: 평소 한국에서만 로그인하다가 해외 클라우드 서버나 VPN을 통해 접속하면 공격 시도로 오인된다. CI/CD 파이프라인을 해외 리전으로 이전하는 타이밍에 딱 이 문제가 터진다.
• 비밀번호가 유출 목록에 걸릴 때: 내 비밀번호가 다른 서비스에서 털린 데이터베이스와 일치하면, MS는 예방 차원에서 그냥 잠가버린다. 여러 서비스에 비슷한 비밀번호를 돌려쓰는 습관이 있다면 이게 진짜 위험하다.
• 자동화 알고리즘의 오탐: 대부분의 계정 잠금은 사람이 판단하는 게 아니라 AI 기반 알고리즘이 결정한다. 단시간에 API를 여러 번 호출하는 정상적인 빌드 작업을 공격으로 잘못 읽는 경우가 꽤 있다.

결정적으로, 이 조치는 사전 경고 없이 이뤄진다. 어느 날 아침에 갑자기 로그인이 안 되는 것이다.

서명용 계정이 잠기면 파장이 다르다

모든 계정 잠김이 같은 건 아니다. 코드 서명 인증서가 붙어 있는 계정은 차원이 다른 문제다.

코드 서명은 “이 소프트웨어는 우리가 만든 것이고, 이후 변조되지 않았다”는 디지털 인감이다. 윈도우 환경에서 이 서명이 없으면 사용자 화면에 ‘알 수 없는 게시자’ 경고가 뜨거나, SmartScreen이 실행 자체를 차단해버린다. 서명 있는 프로그램과 없는 프로그램, 사용자 반응은 완전히 다르다.

계정이 잠기면 인증서 갱신도, 새 버전 서명도 불가능해진다. 긴급 보안 패치가 필요한 상황에서 계정이 잠겨 있다면? 배포 못 한다. 피해는 사용자에게 간다. 더 나쁜 시나리오도 있다. 공격자가 이 계정을 탈취해 악성코드에 정상 서명을 찍어 뿌린다면 — 보안 사고가 아니라 재앙 수준이다.

개인 계정에 묶어두면 안 되는 이유

“이건 김대리 계정으로 관리하고 있어.” 아직도 이런 팀이 있다면, 솔직히 시한폭탄이다. 특정 개인의 계정에 코드 서명 같은 핵심 자산을 걸어두면, 그 사람이 퇴사하거나 휴가 가거나 계정이 잠기는 순간 전체 배포가 멈춘다는 뜻이다. 조직 차원의 관리 체계가 없으면 버티지 못한다.

• 조직(Organization) 계정으로 전환: 개인 계정 대신 회사 차원의 조직 계정을 만들어 관리해야 한다. 관리자 권한을 2~3명에게 나눠두고, 한 명이 자리를 비워도 시스템이 돌아가는 구조가 핵심이다.
• 최소 권한 원칙(Principle of Least Privilege): CI/CD 파이프라인에는 거기에 필요한 권한만 가진 서비스 계정(Service Principal)을 별도로 만들어야 한다. 팀원 전원에게 관리자 권한을 주는 건 편해 보이지만 위험하다.
• 접근 로그 기록: 누가, 언제, 어떤 목적으로 인증서 관련 작업에 접근했는지 로그가 남아 있어야 한다. 문제가 생겼을 때 추적이 안 되면 수습 자체가 불가능해진다.

계정 잠김 예방 체크리스트

사고 후 수습보다 예방이 비용이 훨씬 적다. 아래 항목들은 반드시 점검하고 적용해야 한다.

• 앱 기반 MFA 사용: SMS 인증은 SIM 스와핑 공격에 취약하다. Microsoft Authenticator나 Google Authenticator 같은 앱 기반 OTP로 바꿔야 한다. 그리고 복구 코드는 비밀번호 관리자, 오프라인 문서, 팀 공용 금고 등 여러 곳에 반드시 백업해둬야 한다. 휴대폰 분실 시 복구 코드가 없으면 답이 없다.
• 코드 서명 전용 계정 분리: 코드 서명용 MS 계정은 이메일이나 Office 365 용도로 쓰는 계정과 완전히 분리해야 한다. 자주 쓰는 계정일수록 피싱이나 보안 위협에 노출될 가능성이 올라간다. 섞어 쓰면 안 된다.
• 고유한 비밀번호: 다른 어떤 서비스에서도 쓰지 않는 길고 복잡한 비밀번호. 기본 중의 기본인데 여전히 많이 지켜지지 않는다. 팀 차원에서 1Password나 Bitwarden 같은 비밀번호 관리 도구를 도입하는 걸 진지하게 고려해야 한다.
• 신뢰할 수 있는 IP/장치 등록: 가능하다면 특정 IP 대역이나 등록된 장치에서만 계정에 접근하도록 추가 설정을 걸어두는 것도 방어선이 된다.

이미 잠겼다면 — 복구 절차 A to Z

예방에 실패했다면 침착하게. 단, 착각하면 안 된다. 고객센터 전화 한 통으로 풀리는 문제가 아니다.

1. 공식 계정 복구 양식 제출: MS가 제공하는 공식 복구 양식을 작성해야 한다. 계정 생성 시기, 과거에 썼던 비밀번호, 최근에 보낸 이메일 제목 등 본인임을 증명할 수 있는 정보를 최대한 상세하게 적어야 한다.
2. 지속적으로 문의 업데이트: 자동화된 답변만 계속 올 수 있다. 포기하지 말고 문의(Ticket)를 계속 업데이트해야 한다. 개발자 계정이고, 코드 서명 문제로 제품 배포 자체가 막혔다는 긴급성을 명확히 전달하는 게 포인트다.
3. 공식 서류 준비: 사업자등록증, 법인 서류 등을 요구하는 경우도 있다. 미리 준비해두면 대응 시간이 크게 줄어든다.

복구 기간은 빠르면 며칠, 길면 몇 주다. 그 기간 동안 서비스 배포가 멈춘다. 한 번이라도 경험해보면 예방의 필요성을 따로 설명할 필요가 없어진다.

자주 묻는 것들

Q. YubiKey 같은 하드웨어 보안 키를 쓰면 안전한가요?
훨씬 안전하다. FIDO2 기반 하드웨어 키는 피싱에 거의 완벽하게 저항하고, 지금 쓸 수 있는 MFA 수단 중 가장 강력한 축에 든다. 조직 차원에서 도입을 검토할 가치가 있다. 다만 키 분실이나 파손에 대비한 복구 계획은 별도로 세워둬야 한다. 키 하나에만 의존하다 잃어버리면 그게 또 잠금 사태로 이어진다.

Q. Azure Key Vault 같은 서비스가 도움이 될까요?
도입할 가치가 충분하다. 코드 서명 인증서와 개인 키를 개인 PC나 빌드 서버가 아닌 Azure Key Vault나 AWS KMS 같은 클라우드 기반 HSM(하드웨어 보안 모듈)에 보관하는 건 현대적인 접근 방식이다. 개인 계정 잠금 문제에서 상당 부분 자유로워지고, 접근 제어와 감사 기능도 훨씬 세밀하다. 규모 있는 팀이라면 이쪽으로 가는 게 맞다.

개발자 계정 하나가 전체 서비스 배포를 막는다. 개인의 부주의 문제로만 볼 게 아니라, 조직 전체의 보안 인프라 문제로 봐야 한다. 체계 없이는 같은 일이 반복될 수밖에 없다.

출처: TechCrunch

블록체인 기반 투자 시장이 커지면서, 그 뒤를 바짝 쫓는 것들이 있다. 사기꾼들이다. 가짜 코인 발행이나 지갑 해킹 정도는 이제 구식이고, 사기 자체를 서비스로 제공하는 블랙마켓이 활성화된 지 꽤 됐다. 고수익 미끼 뒤에 함정이 있다는 건 알면서도, 막상 ‘이건 다르다’는 확신이 들면 판단이 흐려진다. 그래서 문제다.

사기를 돕는 시장, 그 실체

과거엔 사기꾼이 개인 투자자에게 직접 접근하는 방식이 대부분이었다. 이제는 구조가 다르다. 사기 행위를 조직적으로 돕는 음성적인 서비스 시장이 별도로 존재한다. ‘검증된 투자처’라거나 ‘안전한 거래를 보장한다’는 명목으로 접근하는 플랫폼들이 여기에 해당한다.

이들이 실제로 하는 일은 표면과 다르다. 사기 프로젝트에 신뢰도를 붙여주거나, 피해자가 자금을 회수하지 못하게 막는 데 협조한다. 가짜 신분, 조작된 거래 내역, 피해자 개인 정보까지 사고파는 구조다. Wired가 전한 바에 따르면 이런 블랙마켓 생태계는 이미 수백억 달러 규모의 자금 세탁과 맞물려 있다. 알고 나면 소름 돋는 수준의 분업이다.

꼭 알아야 할 스캠 유형 4가지

• 피싱(Phishing) 및 스푸핑(Spoofing): 가장 오래됐지만 아직도 효과적이다. 유명 거래소, 지갑 서비스, 인기 프로젝트를 정교하게 사칭한 가짜 사이트나 앱을 만들어 로그인 정보를 낚는다. 텔레그램·디스코드·이메일로 공지를 위장한 링크를 뿌리는 방식도 흔하다. 공식 주소처럼 생겼어도 URL 한 글자 차이로 전혀 다른 사이트일 수 있다. 클릭 전에 주소창을 한 번 더 보는 습관, 진짜로 중요하다.
• 러그 풀(Rug Pull): 신규 프로젝트에서 자주 터진다. 팀이 그럴듯한 백서와 로드맵을 내세워 투자금을 끌어모은 뒤, 프로젝트를 갑자기 닫고 자금을 들고 잠적하는 수법이다. DeFi 생태계에서는 유동성 풀을 구성한다는 명목으로 자금을 모은 뒤 풀을 통째로 빼가는 패턴이 대표적이다. 팀원 신원 불분명, 불투명한 자금 운용, 비현실적인 수익률 약속 — 이 세 가지가 겹치면 일단 의심해야 한다.
• 펌프 앤 덤프(Pump & Dump): 특정 코인 가격을 인위적으로 띄운 뒤 폭락시켜 수익을 빼가는 방식이다. 소셜 미디어 ‘정보방’, ‘리딩방’에서 특정 코인을 집중 추천하며 매수를 유도하고, 가격이 충분히 오르면 미리 쌓아둔 물량을 한꺼번에 던진다. 가격은 수직 낙하하고, 마지막에 들어온 일반 투자자만 손실을 떠안는다. ‘내부 정보’, ‘확실한 급등’ — 이 단어가 나오면 이미 덫이 놓인 거라 봐야 한다.
• 로맨스 스캠 및 원격 투자 사기: 감정을 이용한다는 점에서 가장 악질이다. 온라인에서 친분을 쌓고 연인 관계인 척 신뢰를 얻은 뒤, ‘비밀 투자 기회’라며 검증되지 않은 플랫폼으로 유도한다. 처음엔 소액 수익을 보여주며 안심시키고, 점차 큰돈을 요구한다. 피해자 컴퓨터에 원격 제어 프로그램을 설치해 직접 거래를 조작하는 경우도 있다. 감정이 개입된 순간, 판단력은 반쪽 이하가 된다.

사기꾼들이 파고드는 심리

기술적 취약점만 노리는 게 아니다. 사람의 심리를 먼저 건드린다. 핵심은 FOMO(Fear Of Missing Out)다. ‘나만 뒤처지는 건 아닐까’라는 조급함이 비이성적인 판단으로 이어진다. 단기 고수익 환상, 복잡한 기술에 대한 이해 부족도 빌미가 된다.

‘전문가’, ‘내부 정보’를 앞세운 접근이 통하는 것도 같은 이유다. 정보가 부족한 상태에서 확신에 찬 누군가를 만나면 쉽게 기대게 된다. 거기에 ‘지금 아니면 기회 없다’는 시간 압박까지 더해지면 — 이건 교과서적인 사기 패턴이다. 의심할 시간을 주지 않는 게 목적이다.

자산을 지키는 실제 방법

• 정보 검증을 먼저: 투자 전에 백서, 팀원 경력, 로드맵, 개발 진행 상황, 커뮤니티 활동을 직접 확인해야 한다. 팀원 이름을 검색했을 때 아무 정보도 안 나온다면, 그것만으로도 신호다.
• 공식 채널 외엔 믿지 마라: 정보는 공식 웹사이트, 공식 SNS, 공식 커뮤니티 채널에서만 확인한다. 텔레그램이나 디스코드에서 먼저 DM을 보내거나, 링크 클릭을 유도하는 메시지는 일단 차단 대상이다.
• ‘원금 보장’은 사기다: ‘확실한’, ‘초고수익’, ‘원금 보장’이라는 말이 나오면 99% 사기라고 봐도 된다. 리스크 없는 고수익 상품은 존재하지 않는다. 이 진리는 암호화폐 시장에서도 예외가 없다.
• 시드 문구는 절대 공유 금지: 지갑의 비밀번호, 시드 문구(Seed Phrase), 개인키(Private Key)를 묻는 행위는 100% 사기다. 어떤 이유로도, 누구에게도 알려줄 필요가 없다.
• 출처 모를 링크·파일은 열지 마라: 이메일이나 메시지에 달린 불분명한 링크, 첨부 파일은 클릭 전에 멈춰야 한다. 피싱이나 악성코드 감염 경로가 대부분 여기서 시작한다.
• 처음엔 소액으로: 새로운 투자처는 잃어도 되는 금액으로 먼저 테스트하는 게 맞다. 플랫폼의 실제 작동 방식과 출금 과정을 소액으로 확인한 뒤 규모를 키우는 순서가 현명하다.
• 콜드월렛 활용: 장기 보관 예정 자산은 인터넷에 연결되지 않는 콜드월렛에 옮겨두는 게 좋다. 해킹 경로 자체를 차단하는 방법이다.

피해가 의심될 때 할 일

사기 피해가 의심되는 순간, 속도가 중요하다. 먼저 해당 플랫폼과의 모든 접속을 즉시 끊는다. 그다음은 증거 확보다. 대화 내역, 입출금 기록, 사기 사이트 URL, 메신저 프로필 — 캡처할 수 있는 건 다 저장해 둬야 한다.

증거가 모이면 관계 기관에 신고한다. 경찰청(국번 없이 112 또는 사이버범죄 신고 시스템), 금융감독원(불법 사금융 피해 신고센터), 한국인터넷진흥원(KISA) 세 곳이 주요 창구다. 블록체인 상의 자금 흐름은 추적이 가능한 경우도 있으니, 블록체인 분석 전문 업체나 암호화폐 커뮤니티에 도움을 구하는 것도 방법이다. 포기하기 전에 일단 신고부터다.

스스로 공부한 사람이 결국 살아남는다

암호화폐 시장은 변동성도 크고 규제 공백도 아직 넓다. 사기꾼들이 활동하기 좋은 조건이다. 투자자의 불안과 탐욕 사이 어딘가를 정확히 파고든다.

방어 수단은 단순하다. 투자 지식과 신중함이다. ‘남들도 다 한다’는 이유로 따라가는 투자는 결국 누군가의 수익이 된다. 직접 공부하고, 직접 검증하고, 스스로 판단한 투자만이 리스크를 통제한다. 정보를 가려보는 안목 — 그게 암호화폐 투자에서 가장 현실적인 무기다.

출처: Wired

아이폰이라고 해킹 안 된다는 말, 절반만 맞다. 애플의 보안 시스템이 탄탄한 건 사실이지만, 탄탄하다고 뚫리지 않는 건 아니다. TechCrunch 보도를 보면, 과거에 유출된 해킹 도구들이 지금도 수백만 대의 구형 아이폰을 스파이웨어 공격 위험에 노출시킬 수 있다고 한다. 문자, 통화 기록, 사진, 심지어 마이크와 카메라까지 원격으로 제어당하는 상황이다. 남 얘기가 아니다.

스파이웨어가 실제로 뭘 할 수 있나

감염되면 어떤 일이 벌어질까. 생각보다 구체적이다.

• 개인 정보 유출: 금융 정보, 연락처, 사진, 메시지 — 이 네 가지가 통째로 넘어간다.
• 사생활 침해: 카메라와 마이크가 실시간으로 켜질 수 있다. 집 안에서도.
• 금전 피해: 은행 앱 로그인 정보가 유출되면 계좌에서 돈이 빠져나가는 건 시간문제다.
• 성능 저하: 백그라운드에서 스파이웨어가 계속 돌기 때문에 배터리가 이상하게 빨리 닳는다.

이 정도면 스마트폰 하나 털리는 게 아니라 삶 전체가 털리는 거다. 과장이 아니다.

내 아이폰, 이미 감염됐을 수도 있다

문제는 알림이 안 뜬다는 거다. 스파이웨어는 티 안 나게 숨어서 작동한다. 대신 이런 징후를 눈여겨봐야 한다.

• 배터리가 갑자기 빨리 닳는다: 앱을 거의 안 썼는데 하루 만에 방전 직전이라면 의심해볼 만하다. 백그라운드에서 데이터를 계속 전송하기 때문이다.
• 셀룰러 데이터 사용량이 튄다: 평소와 비슷하게 썼는데 데이터가 2~3배 나왔다면 이유 없이 소모되고 있는 거다.
• 아이폰이 쉬어도 뜨겁다: 충전도 안 하고 화면도 안 켰는데 기기가 따뜻하다면 숨겨진 앱이 풀가동 중이다.
• 모르는 앱이 깔려 있다: 설치한 적 없는 앱이 있으면 바로 삭제하고 출처를 확인해야 한다.
• 팝업 광고가 쏟아진다: 브라우저 말고 다른 앱에서도 광고가 뜬다면 애드웨어 감염을 의심해야 한다.
• 혼자 재부팅된다: 특별한 이유 없이 잦은 재부팅이 반복된다면 시스템 이상이거나 악성 코드가 개입했을 가능성이 있다.

위 증상 중 두 개 이상 겹친다면, 일단 아래 설정부터 점검하자.

기본 설정만 제대로 해도 절반은 막는다

설정 앱을 열면 보안 관련 항목이 여기저기 흩어져 있다. 챙겨야 할 것들만 추렸다.

• iOS 항상 최신 버전으로: 애플이 보안 취약점을 발견하면 업데이트로 바로 패치한다. ‘설정 > 일반 > 소프트웨어 업데이트’에서 자동 업데이트를 켜두는 게 편하다. 업데이트 미루는 습관이 제일 위험하다.
• 암호는 복잡하게: 4자리나 6자리 숫자 암호는 브루트포스 공격에 금방 뚫린다. 영문+숫자+특수문자 조합으로 설정하자. Face ID, Touch ID는 기본 중의 기본이다.
• 애플 ID 이중 인증(Two-Factor Authentication) 켜기: ‘설정 > [이름] > 암호 및 보안 > 이중 인증 켜기’에서 설정한다. 누군가 암호를 알아냈어도 신뢰 기기의 확인 코드 없이는 로그인 못 한다. 이건 무조건 켜야 한다.
• ‘나의 찾기’ 활성화: 분실 시 원격 잠금 및 데이터 삭제가 가능하다. ‘설정 > [이름] > 나의 찾기 > 나의 iPhone 찾기’에서 켜면 된다. 단순한 분실 대비가 아니라 개인 정보 유출 방어선이다.
• 잠금 화면 기능 제한: ‘설정 > Face ID 및 암호 > 잠겨 있는 동안 접근 허용’에서 Siri, 메시지 회신, 제어 센터 등 불필요한 접근을 막자. 잠금 상태에서 Siri로 연락처 조회가 되는 건 생각보다 큰 구멍이다.

좀 더 파고들고 싶다면: 고급 보안 기능

기본 설정을 마쳤다면 한 단계 더 나아갈 수 있다.

• 앱 추적 투명성(App Tracking Transparency) 차단: ‘설정 > 개인정보 보호 및 보안 > 추적’에서 모든 앱의 추적 요청을 거부할 수 있다. 광고 타겟팅에 쓰이는 데이터가 줄어드는 건 덤이다. 끄는 게 더 낫다.
• 잠금 모드(Lockdown Mode): 기자, 인권 활동가, 고위 공직자처럼 고강도 사이버 공격의 타깃이 될 수 있는 사람을 위한 기능이다. ‘설정 > 개인정보 보호 및 보안’에서 켤 수 있다. 대부분의 메시지 첨부 파일을 차단하고 특정 웹 기술을 제한하는데, 일상 사용에는 불편하다. 일반 사용자라면 굳이 필요 없지만 이런 기능이 존재한다는 정도는 알아두자.
• Safari 보안 설정: ‘설정 > Safari’에서 ‘교차 사이트 추적 방지’, ‘IP 주소 가리기’, ‘사기성 웹사이트 경고’를 모두 켜자. 각각 10초면 된다.
• 앱 권한 점검: ‘설정 > 개인정보 보호 및 보안’에서 카메라, 마이크, 위치 서비스에 접근 권한이 있는 앱 목록을 쭉 훑어봐야 한다. 왜 이 앱이 마이크에 접근하고 있지? 싶은 게 하나쯤은 나온다.

구형 아이폰 쓰고 있다면 따로 챙겨야 할 것들

최신 기종은 Apple Silicon 기반 보안 칩이 들어 있고 업데이트도 꾸준히 받는다. 구형은 다르다. 업데이트 지원이 끊기는 순간, 알려진 취약점이 그대로 열려 있는 채로 쓰는 셈이다.

• 지원하는 최신 iOS 유지: 아이폰 8은 iOS 16까지 지원한다. 그 이상은 올릴 수 없어도 iOS 16은 반드시 유지해야 한다. 하위 버전을 그냥 쓰는 건 위험하다.
• 링크와 앱 설치에 더 엄격하게: 최신 보안 패치를 못 받는 만큼, 피싱 링크나 비공식 앱 하나가 치명적이 된다. 두 배로 조심해야 한다.
• 민감한 앱은 다른 기기에서: 은행 앱, 업무용 앱은 보안 업데이트를 받는 최신 기기에서 쓰는 게 낫다. 구형 폰을 보조용으로만 쓰는 구조를 고려해볼 만하다.
• 백업 습관: iCloud나 PC에 정기적으로 백업해두자. 기기를 초기화해야 하는 상황이 생기면 백업이 없으면 낭패다.
• 교체 타이밍: 애플 공식 업데이트 지원이 완전히 끊겼다면 새 기기로 바꾸는 걸 진지하게 생각해야 한다. 더 이상 보안 패치를 못 받는 기기는 사실상 무방비 상태다. 편의와 보안 사이에서 선택해야 한다면, 정보 보호 쪽으로 기울어야 한다.

구형 아이폰의 편리함도 있지만, 내 정보의 안전이 걸린 문제라는 걸 잊으면 안 된다.

이것만 조심하면 웬만한 건 막힌다

설정보다 더 중요한 게 습관이다. 아무리 설정을 잘 해놔도 사용자가 낚이면 끝이다.

• 앱스토어 외 설치는 없다: .ipa 파일 직접 설치, 비공식 앱 스토어 우회 서비스 — 전부 안 된다. 이걸 어기는 순간 보안 설정이 무의미해진다.
• 모르는 링크는 누르지 않는다: 문자, 이메일, 채팅 앱으로 오는 출처 모를 링크는 공식 사이트에 직접 들어가서 확인하는 게 맞다. 금융기관, 공공기관을 사칭하는 링크를 특히 조심해야 한다.
• 공용 Wi-Fi에서는 은행 앱 금지: 카페나 공항 Wi-Fi는 암호화되지 않은 경우가 많다. 은행 앱 로그인이나 카드 결제는 셀룰러 데이터로 하자. 꼭 공용 Wi-Fi를 써야 한다면 VPN을 켜는 게 낫다.
• ‘아이폰 바이러스 감염’ 팝업은 전부 사기다: 절대 속으면 안 된다. 창 닫고 해당 사이트에서 나오면 된다. 거기서 뭔가 누르거나 앱을 설치하면 그게 진짜 감염의 시작이다.

자주 나오는 질문 3가지

보안 관련해서 반복되는 질문들이 있다. 짧게 정리한다.

• Q: 백신 앱 설치해야 할까요?
  A: 솔직히 필요 없다. iOS의 샌드박스 구조와 앱스토어 심사 덕분에 안드로이드처럼 앱 간 감염이 잘 안 된다. 오히려 일부 무료 백신 앱이 과도한 권한을 요구하거나 광고로 수익을 낸다. iOS 최신 버전 유지 + 의심스러운 앱 설치 안 하기가 백신 앱보다 훨씬 효과적이다. VPN이나 보안 브라우저 앱은 필요에 따라 쓸 만하다.
• Q: 공용 Wi-Fi 진짜 위험한가요?
  A: 위험하다. 같은 네트워크에 누가 있는지 모른다. 암호화 안 된 연결이라면 데이터가 그대로 노출된다. 민감한 정보를 주고받을 때는 셀룰러 데이터나 VPN을 쓰는 게 맞다.
• Q: 아이폰 탈옥(Jailbreak)은 왜 위험한가요?
  A: 탈옥은 iOS의 보안 체계를 통째로 해제하는 거다. 애플이 막아놓은 것들을 열 수 있게 되는 동시에, 악성 코드도 마음대로 들어올 수 있게 된다. 스파이웨어 감염 위험이 몇 배로 올라가고, 공식 서비스 지원도 끊긴다. 추천하지 않는다. 절대로.

보안은 한 번 설정하고 잊어버리는 게 아니다. iOS 업데이트할 때마다 새 설정이 기본값으로 바뀌어 있기도 하고, 새 앱을 설치할 때마다 권한 목록이 달라진다. 3개월에 한 번 정도는 ‘설정 > 개인정보 보호 및 보안’을 한 번씩 훑어보는 습관이 가장 현실적인 보안 관리다.

출처: TechCrunch