정말 정신없는 한 주였다. 숫자 4가 여기저기서 문제를 일으켰고, Railway는 누구나 최악으로 꼽을 만한 침해 사고를 수습하고 있다. Zeabur는 대규모 침해 사고 뒤 서비스를 종료한다. 인터넷이 얼마나 PHP에 의존하는지도 다시 확인했다. 여기에 GitLab과 Node.js의 심각한 취약점, LiteLLM과 OVH의 공급망 공격, OpenCode의 키 유출 등이 이어졌다. 보안 사고 소식이 너무 많아 최신 동향을 모아 보여주는 프로젝트와 서비스까지 여럿 생겼다.
사고 자체를 넘어 “AI 때문에 이제 시작일 뿐”이라거나 “모든 것이 달라졌으니 지금까지 알던 것을 잊으라”는 해설도 나온다. 압도되고 불안해질 수 있으며, 두려움을 느낄 수도 있다. 이런 상황에서 어떻게 대응해야 할까?
상황이 급박할수록 서로 연대하고 돌보는 일이 중요하다. 사고 한가운데 있는 사람들에게 이번 주는 아드레날린이 치솟는 고된 시간이었을 것이다. Miren은 인프라 기업 안팎에서 여러 해 일해 온 엔지니어와 운영자로 팀을 꾸렸으며, 한밤중의 사고 대응 회의와 떨리는 손으로 상태 페이지를 업데이트하는 일을 잘 안다고 말한다. 힘들고 보답받기 어려운 일이다.
Miren은 사고 대응과 수정, 후속 조치에 힘을 쏟는 수백 명에게 HugOps를 보낸다고 밝혔다. 사고가 잦아든 뒤에는 무엇을 배우고 어떻게 개선해 더 강해질지도 논의해야 한다. 마지막 순간의 영웅적 대응에 기대야 하는 상황을 줄여 미래의 우리를 돌보는 일도 그 실천의 일부라는 설명이다.
사고에서 드러난 세 가지 구조적 문제
소프트웨어는 특정 환경에서 작동하며, 목표를 달성하는 동시에 그 환경의 위험에 대응하도록 만들어야 한다. Miren은 이번 사고들을 시스템 설계의 세 가지 문제로 나눈다.
- 한 곳에 모인 비밀 정보: Railway, Zeabur, OpenCode의 사고는 중앙화된 플랫폼에서 발생했다. 한곳이 뚫리면 여러 사용자의 데이터에 접근할 수 있다. 비밀 정보가 한 바구니에 모이면 그 바구니는 공격의 표적이 되고, 침해됐을 때 피해도 커진다.
- 수많은 곳에 적용해야 하는 수정 사항: PHP, eMudhra, 자체 관리형 GitLab, Node.js의 취약점은 중앙에서 관리되지 않는 시스템에서 발견됐다. 이를 고치려면 수동 조율이 필요하다. eMudhra 취약점의 경우 Firefox는 빠른 업데이트 채널을 통해 몇 시간 안에 악성 인증서를 차단했다. 반면 업데이트가 어려운 소프트웨어에서는 취약한 시스템이 오랫동안 남을 수 있다.
- 수많은 대상에 영향을 미치는 악성 수정 사항: LiteLLM과 OVH는 공급망 공격을 받았다. 공격자는 업데이트 시스템을 탈취해 피해자가 스스로 시스템을 침해하도록 만들었다. 앞의 문제와 반대로, 업데이트 채널 자체가 공격자의 손에 들어가면 공격 경로가 된다.
Miren은 이를 비밀 정보가 어디에 저장되는지, 누가 수정 사항을 적용하는지, 수정 사항을 전달하는 채널이 무엇을 신뢰하는지라는 설계 문제로 요약한다. 배포 플랫폼인 Miren도 이 문제들을 직접 해결해야 한다고 말한다.
Miren이 선택한 배포 방식
Miren은 좋은 개발자 경험을 위해 기업용 불투명 플랫폼과 복잡한 직접 구축 방식 중 하나를 고를 필요가 없어야 한다고 본다. 도구가 개발을 방해하지 않는 것도 중요하지만, 소프트웨어가 프로토타입에서 실제 서비스까지 이어지도록 뒷받침할 기반도 필요하다는 설명이다.
Miren이 내세우는 설계 선택은 다음과 같다.
- 직접 실행할 수 있는 런타임: Miren의 런타임은 오픈소스 소프트웨어이며, Linux 컴퓨터에서 실행할 수 있다. Miren은 이 방식으로 비밀 정보를 사용자가 관리하는 기기에 둘 수 있다고 설명한다. 편의를 위해 Miren이 클러스터를 호스팅하는 선택지도 있지만, 업체는 이 경우 보안 일부를 편의와 맞바꾸게 된다고 말한다.
- 위험을 불필요하게 키우지 않는 제어 영역: Miren은 Miren Cloud가 비밀 정보를 저장하지 않으며, Miren 클러스터와 클라우드 사이의 통신 방식을 설계해 Miren에 장애가 발생해도 앱을 계속 실행하고 배포할 수 있다고 밝혔다. 보안을 더 중시한다면 네트워크와 연결되지 않은 클러스터를 운영할 수도 있지만, 편의성은 낮아진다.
- 공개된 소프트웨어: 사용자의 컴퓨터에서 실행되는 소프트웨어가 모두 오픈소스이므로 감사를 받을 수 있다고 Miren은 설명한다. 사용자는 소프트웨어 실행 방식과 각 클러스터가 Miren Cloud와 주고받는 내용을 살펴볼 수 있다.
- 조정 가능한 자동 업데이트: Miren Cloud는 클러스터의 자동 업데이트를 진행할 수 있다.
stable채널에는 1주일의 대기 기간이 있으며, 사용자가 정한 유지보수 일정에 따라 업데이트하고 실패하면 자동으로 롤백한다.
Miren은 사용자 데이터의 분산 관리, 자동 패치, 지속적으로 보강할 수 있는 공급망이 이번 사고에서 드러난 구조적 위험에 대응하는 최선의 설계라고 본다.
남은 공급망 위험
Miren은 이 구조에서도 공급망이 완전히 없앨 수 없는 위험으로 남는다고 인정한다. 시스템을 쉽게 바꾸면 취약점을 고치기 좋지만 공격도 쉬워지고, 바꾸기 어렵게 만들면 공격을 막기 쉬운 대신 수정도 어려워지는 상반된 선택지가 있다는 것이다. Miren은 빠른 패치와 방어된 배포 채널이 현재 보안 분야에서 가장 나은 절충안으로 여겨지는 듯하다고 말한다.
오픈소스이면서 자체 호스팅할 수 있는 소프트웨어는 직접 빌드해 다른 절충안을 선택할 수 있게 한다. 물론 더 많은 작업이 필요하지만, 기기에서 실행되는 코드 전체를 감사할 수 있다.
Miren은 공급망 보안을 더 강화할 방법이 남아 있다고 말한다. 한 가지 논의 중인 사례는 자동 업데이트다. 현재 Miren Cloud의 자동 업그레이드는 클러스터가 잠시 중단되므로 사용자가 적절한 유지보수 시간을 고르도록 선택 기능으로 제공한다. 클러스터를 중단 없이 업그레이드할 수 있게 되면 기본 설정을 바꿔 새 클러스터가 자동으로 업데이트되도록 할 수 있다. Miren은 이를 앞두고 어떤 빌드 무결성 검사를 적용해야 할지 논의하고 있다고 밝혔다.
Miren은 커뮤니티와 함께 제품을 만들고 있다며, 어떤 요소가 중요한지 의견을 요청한다. 여러 접근 방식이 공존할 수 있지만, Miren은 현대적인 소프트웨어 배포에서 데이터는 분산하고 수정은 중앙에서 관리하는 방식이 올바른 방향이라고 주장한다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요