[태그:] 윈도우

빌드 파이프라인이 코드 서명 단계에서 멈춘다. 로그를 열면 인증서 오류뿐. 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