Vercel 보안 점검소

Hacker News 의견들

• 글이 AI 생성물처럼 너무 강하게 느껴짐. 일부러 문법을 어색하게 섞어 숨기려 한 것 같지만, 그게 내용의 정확성과는 별개인지까지는 확신이 안 듦

  • 나는 읽다가 중간에 멈췄음. 이제 LLM 말투에 너무 민감해져서, 이건 사실상 “ChatGPT야 이 기사 읽고 캐주얼하게 다시 써줘” 수준으로 보였고 실제 저자성이 거의 안 느껴졌음. 이런 종류의 글은 HN에서 가능하면 1차 출처를 가져오는 쪽이 맞다고 봄
  • 왜 비추천을 받는지 모르겠음. 이 글은 AI 블로그 스팸에 가깝고, https://www.darkreading.com/application-security/vercel-employees-ai-tool-access-data-breach 같은 기사보다 사실 정보가 더 많은 것도 아니며, 텅 빈 LLM식 표현으로 가득해 보였음. 이런 글을 사람들이 기꺼이 읽는 분위기가 좀 우울하게 느껴짐
  • 작성자 사이트가 Vercel 위에 올라가 있는 걸 봤음. 그래서 이 이슈에 실제 노출돼 있었고 이해관계도 있는 사람이라고 생각함. 그 점만으로도 AI 단독 생성물보다는 한 단계 낫다고 봄
  • 문체는 분명 LLM 산문 같지만, 전부가 그렇지는 않아 보였음. 아마 일부만 다시 쓴 것 같음. 더 걱정되는 건 HN처럼 LLM에 익숙한 사람이 많은 곳에서도 이런 글이 그냥 통과된다는 점임. 이게 표준이 되는 건 싫지만, AI 생성 글이 진지한 반응을 많이 받는 HN 사례가 이번이 처음도 아니라는 점이 더 신경 쓰임. 코드에 AI를 쓰는 건 사람이 충분히 검증하면 괜찮다고 보지만, LLM 산문이 프런트 페이지를 점점 더 점령하는 건 정말 별로라고 느낌
  • 나도 똑같이 느꼈음. 보통 사람은 저런 식으로 쓰지 않음

• 여기서 말하는 “sensitive” 해석은 틀렸다고 봄. 내가 알기로 Vercel의 env var는 전부 저장 시점에는 암호화되어 있고, sensitive 체크박스는 개발자가 UI에서 그 값을 다시 볼 수 없게 만드는 의미임. 즉 write-only에 가까운 개념이고, 앱은 env var를 통해 값을 볼 수 있어야 하니 앱도 못 읽게 암호화하는 건 애초에 무의미함. 체크를 안 하면 프로젝트 UI에서 값을 볼 수 있고, DEFAULT_TIME_ZONE 같은 일반 설정값에는 그 편이 더 실용적임. 그래서 sensitive는 암호화 여부가 아니라 UI 노출 여부를 뜻한다고 이해함. Vercel 직원은 아니지만 좀 써봤고, 이 부분을 비판하는 건 허수아비 논증처럼 보임

  • 맞음, 나도 그 부분이 헷갈렸음. 프로그램이 실제로 써야 하는 env var는 평문 주입될 수밖에 없음. 저장 시 암호화는 가능해도 실행 전에 결국 복호화돼야 하고, 이건 Vercel 문제가 아니라 시스템 구조 자체의 한계임. 언젠가 완전 동형암호로 개선될 수도 있겠지만 전체 프로그램에 오버헤드가 너무 커서 아직은 현실적이지 않음
  • 유출 사고만 나면 “암호화했어야지”라고 외치는 경우가 많은데, 정작 암호화의 한계를 원리와 실무 양쪽에서 이해하지 못하는 경우가 많다고 느낌. 암호화는 secure나 safe의 동의어가 아님
  • Vercel에서 정확히 어떻게 동작하는지는 모르지만, 다른 플랫폼에서는 보통 이 표시가 있으면 로그에서도 마스킹되는 의미인 경우가 많았음
  • 내가 일하는 곳은 Vault를 쓰기 시작했고, vault key 조회용 키는 일반적인 비숨김 env var에 넣음. 이 방식이 아마 더 탄탄한 구조라고 생각함
  • 이건 다른 클라우드도 비슷하게 함. 예를 들면 DigitalOcean도 같은 식임

• 쉬운 희생양 만들기를 하고 싶진 않지만, 그래도 Context.ai 직원이 업무용 장비에서 게임을 하고, 거기에다가 출처가 의심스러운 치트 프로그램까지 설치한 건 어떻게 봐야 하나 싶음. defense in depth나 보안 계층 얘기는 당연히 맞지만, 여기에는 개인 책임도 분명 있다고 봄. Vercel 쪽 실수는 회사와 경영진 차원의 방어 실패로 볼 수 있어도, 치트 설치는 정말 별개로 심각해 보임

  • AI를 도입하는 회사들 전반에서 OpSec 수준이 낮다고 봄. 지금은 보안이 의사결정의 핵심 기능이 아니기 때문임. 2년 전 McDonalds 침해 사례만 봐도 비슷한 흐름이 보임
  • 그 직원이 정말 업무용 장비에 그걸 설치했는지는 아직 모른다고 봄. 적어도 이 기사에는 없고 다른 출처에서도 못 찾았음. 많은 회사가 사내망 VPN 접속이나 일부 내부 시스템의 인터넷 직접 로그인을 허용하기도 하는데, 바람직하진 않아도 생각보다 흔한 일임. Disney 해킹도 개인 PC에 설치한 손상된 소프트웨어에서 시작됐던 걸 떠올리게 됨. 내가 직접 봐온 바로는 많은 회사의 IT는 생각보다 훨씬 허술함
  • 나는 오히려 사용자가 임의 소프트웨어를 설치할 수 있게 둔 IT 부서를 더 탓하겠음
  • 나도 전적으로 동의함. 업무와 사적 용도를 한 대의 노트북에서 같이 처리한다는 발상 자체가 이미 꽤 무리라고 느낌. 시가총액 세계 상위 10위권 기업 중 하나에서는 엔지니어 책상에 인터넷이 안 되는 업무용 컴퓨터와, 다른 네트워크에 연결된 인터넷용 컴퓨터를 따로 두는 구조를 썼음. 내 주 작업 장비는 소리도 안 남. 사운드조차 없음. 대부분 사람은 소리 안 나는 메인 업무 컴퓨터로도 충분히 일할 수 있다고 봄. 나는 기술 혐오자도 아니고 NUC, Raspberry Pi, 노트북도 많이 쓰지만, 메인 업무 장비로 YouTube를 보거나 게임을 할 필요는 전혀 없음. 회의용은 다른 노트북, 영상 시청도 다른 노트북이면 됨. 커피숍에도 들고 가고 회사에도 들고 가는 그 노트북으로 게임까지 하는 문화가 Vercel을 무너뜨렸고, 앞으로도 많은 회사를 무너뜨릴 거라고 봄
  • 그건 여러 원인 중 하나일 뿐이라고 봄. 물론 나쁜 선택이지만, 다른 시스템의 보안이 “업무용 노트북이 절대 해킹당하지 않을 것”에만 의존해서는 안 됨. 그게 유일한 방어선이면 결국 문제를 맞게 됨

• 이 기사에는 부정확한 부분이 있다고 봄. Vercel env var는 모두 at rest 암호화되어 있고, sensitive 체크는 설정 후 값을 다시 조회할 수 없게 만드는 의미라서 이번 같은 상황에선 오히려 도움이 됐을 것 같음. 그리고 출처 링크 하나 없이 이런 글을 읽는 것도 꽤 거슬렸음

  • 여기 UI 결정은 좀 흥미로움. 환경 변수 목록이 마치 비밀번호처럼 가려져 있고 보기 버튼도 있어서, advisory를 읽기 전에는 sensitive 플래그가 얼마나 중요한지 바로 눈에 잘 안 들어왔음. 우리도 민감 표시가 안 된 비밀값들이 있어서 지금 회전 작업을 바쁘게 하고 있음
  • 그런데 일부 고객 env var가 실제로 노출된 건 맞으니, 그럼 암호화 안 된 것 아닌가 하는 생각도 들었음

• 지난 1년 동안 내가 직접 승인한 AI 도구를 대략 12개 점검해봤는데, 그중 9개가 Google Workspace에서 모든 이메일 읽기와 Drive 전체 접근 권한을 요구하고 있었음. 게다가 나는 온보딩 중에 바빠서 권한도 제대로 안 읽고 전부 승인했음. 기술에 익숙한 사람들도 진짜 이렇게 하는지 궁금함. 나는 누군가에게 이메일과 Google Drive 접근을 주는 건 밤잠 설칠 정도로 꺼려지고, 권한도 최대한 세분화해서 주며 안 쓰는 앱은 바로 철회하려고 함. 저 정도면 메일 속 NDA 정보나 기밀은 이미 유출됐다고 가정해야 맞다고 느낌

  • 내 직장에서 다른 팀이 산 AI 회의록 도구와 Google Workspace를 연동하는 일을 도와달라는 요청을 받았음. 벤더는 이메일과 Drive 파일 읽기·쓰기를 위해 Domain-wide Delegation을 설정하라고 했고, 그렇게 하면 조직 전체 사용자가 자동으로 opt-in되며 거부도 불가능했음. 그래서 나는 벤더에 연락해 사용자가 직접 로그인하고 OAuth 권한창을 수락하는 “덜 권장되는” 방식을 따로 열어달라고 요청했음. 그런데 그 과정 내내 벤더와 우리 조직 모두 이걸 시간 낭비처럼 취급했음. 누가 넓은 권한을 자발적으로 주고 싶다면 그건 각자 선택이지만, 핵심 도구도 아닌데 전 직원에게 거부권 없이 켜버리는 건 비윤리적이라고 느낌. 보안 우려는 말할 것도 없음. 더 무서운 건 AI와 조금이라도 관련되면 사람들이 생각을 멈춘다는 점임. 5년 전만 해도 이런 요청을 안 했을 똑똑한 사람들이 이제는 남들도 다 하니까 괜찮다고 여김
  • 나는 개인적으로 그렇게 안 함. 며칠 전 본 “안전하려는 사람은 결국 Stallman식 수도원 컴퓨팅으로 수렴한다”는 말이 머릿속에 남아 있음. https://news.ycombinator.com/item?id=47796469#47797330 정말 웃기면서도 사실 같음. 내 개인 데이터를 마음껏 다루는 에이전트 자동화의 이득을 누리고 싶긴 하지만, 나는 참고 있음. 놓치는 멋진 기능들이 아쉽긴 해도 권한은 현재만의 문제가 아님. 한 번 주면 사실상 계속 가지게 됨
  • 그런 일은 아주 흔하다고 확신함. 권한 피로감과 팝업 피로는 현실임. 요즘 앱과 웹사이트는 사용자가 원래 하려던 일에 도달하기 전에 수십 개 팝업을 던지고, 그중 상당수는 마케팅이고 일부는 멍청한 법무 요구이며 일부만 중요함. 결국 사람은 “그래, 알았으니까 그냥 진행”을 누르게 되고 보안은 창밖으로 날아감. 늘 기억하는 건, 컴퓨터 보안이라는 건 사실상 환상에 가깝고 네트워크에 연결된 컴퓨터의 데이터는 준공개 정보처럼 취급해야 한다는 점임. 인터넷 연결된 컴퓨터 위에 현대 인프라 대부분이 올라가 있다는 사실은 굳이 깊게 생각하지 않는 편이 정신 건강에 좋음
  • 현실은 이렇다고 느낌. 상사는 “오늘 오후 큰 회의 전에 일단 대충 만들어”라고 하고, 엔지니어는 설정 중에 전부 동의한 뒤 나중에 정리하면 된다고 생각함. 그리고 6개월 뒤 그 급조 데모가 그대로 프로덕션이 됨
  • 나는 그걸 “바빠서 읽지 않고 승인했다”로 보지 않음. 실제로는 온보딩이 권한을 요구했고, 거절할 기회 자체가 없었기 때문이라고 봄. 거절하면 앱을 못 쓰게 되니까 사실상 강요임. 이 개념 자체가 잘못됐다고 느낌. 사용자는 “거부”를 눌러도 앱에 거부 사실이 전달되지 않고, 그저 요청 데이터가 비어 있는 것처럼 보여야 맞음. 그러면 앱은 원하는 권한을 물어볼 수 있고, 사용자는 권한을 주지 않은 채 앱도 계속 쓸 수 있음. 그게 진짜 해결책이라고 봄

• 추측하자면 이건 아무 Google Workspace 앱이 아니라 아마 Gmail 접근권 문제였을 가능성이 큼. 공격자가 피해자의 받은편지함에 넓게 접근했고, 그 뒤 magic link나 일회용 코드로 일부 내부 시스템에 로그인했을 것 같음. 그렇다면 왜 2FA가 없었는지, 그리고 애초에 왜 그렇게 광범위한 접근을 허용했는지가 궁금해짐. 그게 아니라면 다른 가능성은 Google Workspace 안에 API 자격증명을 저장해뒀던 경우 정도인데, 가능은 해도 꽤 이상한 구조라고 느낌

• 고작 Roblox 치트였다니 어이가 없음. 우리 아들도 Roblox 치트 때문에 계정이 털린 적 있어서 심각하다고 느꼈는데, 그때는 Gamepass 쿠키를 빼가서 Minecraft 라이선스 4개를 샀고 Microsoft가 빨리 환불해준 정도였음

  • 이 말은 사실상 Vercel이 10대 스크립트 키디들에게 뚫렸다는 뜻처럼 들림. 다만 긍정적으로 보자면 체포 소식도 곧 나올 수 있다고 기대함
  • 나는 애초에 왜 게임 치트가 실행 가능했는지가 궁금함. 이런 회사들은 디바이스 통제가 없거나, 있어도 신경을 안 쓰는 건가 싶음. 직원이 LastPass Plex 사건 같은 실수를 반복한 느낌임

• 이 기사에서 브라우저 검증 실패 오류가 뜨고 있음

  • 아이러니하게도 그 사이트가 Vercel 호스팅이라는 점이 웃김

• “그 체크박스가 있는 줄 개발자 몇 명이나 알았을까, 그리고 DB 자격증명과 API 키가 기본 암호화라고 몇 명이나 가정했을까”라는 문장을 보고 나는 반대로 생각했음. 비밀값 입력칸에 별표가 안 보이면 저장 버튼부터 안 누름. 혹시 프로그래밍 방식으로 넣었을 수도 있겠지만, 그 경우에도 최소한 secret 플래그 비슷한 건 명시했어야 한다고 봄. Vercel 같은 회사에서 이런 문제가 나왔다는 것 자체가 좀 이상하게 느껴짐

  • 이런 입력칸에는 누군가가 민감 정보를 넣을 거라고 기본 가정해야 함. 그래서 기본 암호화가 유일하게 합리적인 선택이라고 봄
  • 다리 엔지니어에게 “혹시 교각 보강 빼먹으셨어요?”라고 묻지는 않듯이, 보안 지식이 부족했을 때조차 이런 건 기본 중 기본이라고 생각했음. 평문으로 민감 정보를 저장했다가 되돌아온 결과를 맞은 사람들이 화내는 건 이해하지만, 결국 자기 관행의 대가를 치른 면도 있음. 그렇다고 피해자 비난만 하자는 건 아니고, Vercel도 이 황당한 상황에 대한 책임을 분명 져야 한다고 봄. 그래도 결국 FAFO라는 느낌이 남음

• 정말 아이러니하게도, 이제는 보안 체크를 더 강화한 것 같음. 구버전 Firefox로 원문을 읽으려 하니 Failed to verify your browser와 Code 11, Vercel Security Checkpoint 메시지만 나왔음. 솔직히 꽤 짜증났음