요약
Trigger.dev는 공격자가 일부 고객 조직의 환경 변수에 무단으로 접근했다고 밝혔습니다.
Trigger.dev CTO 에릭 앨럼이 11월 1일 회사 블로그에 올린 보안 사고 공지입니다. 공격 경로나 피해 규모는 밝히지 않았습니다. 공격을 막았다는 사실과 고객 안내 방법만 다섯 문단으로 짧게 알렸습니다.
왜 중요한가
- 피해를 본 고객은 회사가 이메일로 보낸 안내에 따라 직접 대응 조치를 해야 합니다.
- 공지에 공격 방식과 피해 범위가 빠져 있어, 고객은 자신이 얼마나 위험한지 스스로 가늠하기 어렵습니다.
핵심 내용
- 공격자는 일부 조직의 환경 변수에 무단으로 접근했고, 모든 고객이 피해를 본 것은 아니라고 했습니다.
- 회사는 공격자가 쓴 익스플로잇(취약점을 파고드는 공격 수법)을 이미 막았다고 밝혔습니다.
- 피해를 본 계정 소유자 전원에게 대응 절차를 담은 이메일을 보냈다고 했습니다.
- 이후 소식은 상태 페이지에 올리고, 문의는 연락처 페이지로 받는다고 했습니다.
- 공격 방식, 피해 조직 수, 사고를 알아챈 시점은 공지에 나오지 않습니다.
HN 반응
- 상태 페이지의 사고를 곧바로 '해결됨'으로 바꾼 데 대해, 사후 분석도 없이 성급하다는 비판과 취약점을 막고 고객에게 알렸으면 충분하다는 반론이 맞섰습니다.
- 노스플랭크·레일웨이 사고에 이어 AWS 같은 대형 클라우드 업체로 돌아갈 것이라는 전망과, 아예 직접 호스팅하겠다는 이용자들의 목소리가 함께 나왔습니다.
Northflank 침해 사고 글에서도 말씀드렸지만요.
인프라 스타트업 입장에서는 안타깝게도, 이번 같은 사고와 Railway 사고 때문에 결국 하이퍼스케일러로 되돌아가는 흐름이 나올 것 같아요.
아무리 "쓰기 편해도" 보안을 대신할 수는 없어요. 적어도 기업에 판매할 때는 확실히 그래요.
그리고 요즘 제가 쓰는 요령이 하나 있는데, 환경 변수를 암호화한 다음 복호화 키를 코드에 하드코딩해 두는 거예요.
하이퍼스케일러(대기업)가 작은 회사보다 이런 일을 항상 더 잘할 거라는 뜻인가요?
회사에 돈이 더 많다고 해서 그 돈을 제대로 쓰는 건 아니잖아요. 돈을 제대로 쓰더라도 엉뚱한 사람에게 쓰면 결국 사고가 납니다.
AWS Secrets Manager에 자격 증명을 넣었다고 해고된 사람은 없습니다. 저라면 언제든 하이퍼스케일러를 택하겠습니다. 무슨 일이 생기더라도 충분히 변명할 수 있는 결정이니까요.
HSM을 켜 두면 아마 더 안전할 겁니다.
규정 준수가 보안을 실제로 높여 줄 때도 있습니다. 하이퍼스케일러는 그럴 만한 자원이 있고, 보안도 잘합니다. 하이퍼스케일러는 핵심 기반 시설로 취급되기도 하고요.
직원 한 명의 기기가 뚫린다고 조직 전체가 무너지지는 않습니다.
꼭 항상 그런 건 아니지만요(Azure는 어떻습니까?), 나머지 업체들은 분명히 그렇습니다.
네, 자체 하드웨어 보안 모듈(HSM)을 감당하지 못하는 인프라 업체라면 민감한 고객 데이터는 저장하지 않는 편이 맞다고 봅니다.
안타깝지만 HSM 비용은 두 대 값에서 끝나지 않습니다. 앞으로 몇 년간 예상 수요보다 넉넉하게 장비를 갖춰야 하고, 보안 설계도 알고 문제가 생겨도 모든 접근 권한을 잃지 않게 안전하게 운영할 줄 아는 인력까지 있어야 합니다.
HSM이 있다고 끝나는 게 아닙니다. 보안을 유지하려면 그에 맞는 절차도 갖춰야 합니다. 클라우드 HSM 솔루션을 쓰는 방법도 있고요.
죄송한데, 이게 "해결됨"이라고요? 어떻게 이 상황에서 해결됨으로 표시할 수 있죠? 환경 변수는 노출됐지만 이메일로 알렸으니 다 괜찮다는 건가요... 어떻게, 얼마나 노출됐는지도 모르면서요.
사고 대응팀이 상태 페이지에서 사고를 해결됨으로 표시하려면 어떻게 하는 게 적절하다고 보십니까?
해결됨으로 두지 않는 거죠.
왜요? 영원히 열려 있는 사고가 무슨 소용이 있죠?
더 잘해야 한다는 걸 영원히 상기시켜 주는 용도죠. 역사에서 배우지 못하는 자는 그것을 되풀이할 수밖에 없다잖아요?
영원은 아주아주 긴 시간이에요. "프로그래밍 가능한 전자식 컴퓨팅 및 데이터 저장 기계" 산업 전체의 역사(따지자면)인 80년보다도 훨씬 길죠.
그러니 버그 트래커에 이슈를 영원히 열어 두는 건 가능하지도 않다고 생각해요. 상기시켜 주는 역할도 못 하고요. 장수한 회사 대부분은 Jira든 요즘 쓰는 뭐든, "X년 넘은 열린 이슈는 무시" 필터가 기본으로 켜져 있다고 장담합니다. 그런 건 임원진이 아이디어가 바닥났을 때 일 년에 한 번 들여다볼까 말까예요.
상태 페이지는 역사 기록이 아닙니다.
적어도 사후 분석이나 뭐가 잘못됐는지에 대한 설명은 있어야 시작이라도 되겠죠.
해결됨 = 이제 당신 문제라는 뜻인가요?
맞춤 개발 소프트웨어를 만들어야 하는 가장 큰 이유는 공격 표면이 줄고, 한 사람을 해킹해서는 돈이 되지 않는다는 점입니다. 꼭 필요하지 않다면 인터넷에 아예 노출하지 말고 Tailscale만 쓰세요.
저는 맞춤 개발 소프트웨어가 현실적인 대안이라고 생각하지 않습니다. 취약점 탐색은 하루가 다르게 싸지고 있고, 대규모 병렬 처리도 가능하니까요.
누군가는 반드시 abliterated 파레토 곡선 모델을 돌리는 에이전트를 잔뜩 띄워서 인터넷 전체에 풀어 놓을 겁니다.
게다가 직접 만든 도구는 그 분야의 기존 업체 제품보다 보안이 훨씬 허술할 가능성이 높습니다.
방금 사람들이 왜 인프라를 빌려 쓰는지 직접 설명하신 것 같네요.
필요하지 않으면 절대 노출하지 말라는 데 동의합니다.
그리고 개인이 직접 호스팅하는 서비스는 비공개용과 공개용을 서로 다른 환경으로 분리해서 운영하세요.
제 개인 생활에 한해서는, 당분간 제가 직접 통제하지 못하는 SaaS에 뭔가를 '빌드해서 배포'할 일은 솔직히 없을 것 같습니다.
와, 저도 요즘 같은 생각을 하고 있었어요. SaaS는 끝났어요. 적어도 개발자용 SaaS는 확실히요. 제가 의존하는 건 직접 셀프 호스팅하는 git(웹에 공개 안 함)뿐이에요. 나머지 "개발자용 SaaS"는 전부 Claude로 직접 만든 버전으로 바꿨어요. 아마 해킹에서 안전하진 않겠지만, 온갖 "SaaS 플랫폼"이 제 데이터를 다 저장하다가 월요일, 금요일마다 해킹당하는 것보다는 누군가 저를 콕 집어 노리는 위험을 감수하겠어요.
맞아요, 그 말을 듣고 생각났는데, 제가 호스팅하던 마지막 공개 서비스(핵심은 아니에요)를 사소한 편의 때문에 서드파티 SaaS 안에 두고 있었거든요. 그걸 옮겨야겠어요.
상태 페이지의 사고를 해결됨으로 바꾼 건 배짱이 두둑하네요.
취약점을 고쳤다면 어떻게 하길 바라시는 건가요? 해결됨으로 바꾸기 전에 임의로 정한 시간만큼 기다려야 하나요?
말씀에 반대하는 건 아니지만, 보통 실수 때문에 사용자 데이터가 유출된 경우에는 답이 조금 더 감정적인 쪽으로 흘러요. 그런 일이 생기면 사람들이 화를 내는 게 당연하고, 서비스들은 대개 "고객과 협력해서 어쩌고저쩌고" 하는 동안 사고를 "완화됨" 상태로 둡니다. 제가 일해 본 곳은 전부 완화됨에서 해결됨으로 넘어갈 때 사후 분석 공개, 보완 작업, 그리고 이번 일에서 얻은 교훈을 바탕으로 같은 문제가 재발하지 않을 거라는 전반적인 보장이나 안전장치가 따랐습니다. 다만 업계 전체로 보면 완화와 해결을 가르는 기준이 표준으로 정해져 있지는 않아요.
그러니까 진행 중이던 사고는 이제 고쳐졌고 영향받은 고객에게도 이미 연락했는데, 더 자세한 블로그 글을 아직 안 올렸다는 이유로 해결됨으로 표시하면 안 된다는 건가요?
표시할 수 없다는 게 아닙니다. 그렇게 하는 게 사업적으로 좋지 않다는 거죠.
사고를 어떻게 알리느냐는 원인을 바로잡는 것만큼이나 중요합니다.
이렇게 처리한다는 사실 하나만으로도 저는 이 서비스를 앞으로 쓰지도, 다른 사람에게 추천하지도 않을 것 같습니다.