위협 지형도

먼저 센 이유

무엇이 실제로 터지는지 모르는 채 대응책부터 모으면 카탈로그만 두꺼워지고 우선순위는 생기지 않는다. 무엇을 먼저 막을지가 이후 모든 설계의 입력이다. 그래서 대응을 만들기 전에 위협을 먼저 셌다.

세 면으로 갈랐다

“에이전트 보안”이라는 말이 가리키는 대상이 최소 셋이라 한 목록에 담으면 우선순위가 안 나온다.

면	무엇에 관한 위협인가
A 운영면	에이전트를 쓰는 과정에서 나는 사고. 시크릿, 권한, 훅, 기록
B 생산물면	에이전트가 만든 것의 보안. 인증, OAuth, 웹, 데이터
C 제품면	프레임워크로 만든 에이전트 자체의 보안

셋 중 A면만 깊게 팠다. 매일 일어나는 일이고, 여기서 새면 나머지 둘을 아무리 잘해도 소용이 없기 때문이다. B·C 는 같은 분류 틀을 재사용해 나중에 판다.

A면에서 나온 것

위협 19건. 실사고 사례를 근거로 목록을 만들고, 내 실제 구성을 실측해 해당 여부를 갈랐다. 그다음 이미 도는 보호 장치와 대조해, 남은 공백을 선순위 · 후순위 · 대상 아님 셋 중 하나로 전부 귀결시켰다. 애매한 채로 남긴 항목은 두지 않았다.

선순위로 고른 넷

무엇	왜 먼저인가
시크릿이 커밋에 실린다	되돌리기가 사실상 불가능하다. 이력에 남으면 키를 갈아야 한다
시크릿이 파일에 쓰인다	커밋 이전 단계라 커밋 차단만으로는 못 잡는다
권한 게이트가 뚫린다	에이전트가 자기 경계를 스스로 넓히면 나머지 장치가 무의미해진다
무엇이 막혔는지 기록이 없다	사고 후에 무슨 일이 있었는지 재구성할 수 없다

조사에서 예상이 틀린 것

감사 기록은 장치가 없는 게 아니라 안 켜져 있었다. 도구 결정 이벤트와 권한 모드 변경 이벤트가 이미 존재하는데 내보내기가 꺼져 있을 뿐이었다. 같은 결론이 조사 내내 세 번 반복됐다 — 장치가 있는 것과 그 장치가 지금 도는 것은 다른 일이다. 3차 상태 점검이 존재하는 이유가 이것이다.

두 에이전트 도구의 차단 신호가 같았다. 도구마다 다를 것으로 예상하고 설계했는데 아니었다. 그래서 판정 본체를 하나로 두고 어댑터는 설정 형식과 배선만 흡수하게 바꿨다.

두 번째 어댑터가 첫 어댑터의 추상을 깨뜨렸다. 직렬화·파싱이 첫 도구 형식으로 하드코딩돼 있었고, 두 번째를 실제로 붙여 보기 전에는 안 보였다. 어댑터 하나의 한계 비용은 100줄 안팎으로 측정됐다.

대응은 조사해서 판정했다

선순위 넷에 대해 막아야 할 것과 막으면 안 되는 것을 요구사항 6건으로 먼저 적었다. “막으면 안 되는 것”을 같이 적은 이유는, 그것을 안 적으면 오탐을 설계 실패로 셀 수 없기 때문이다.

그다음 요구사항마다 기존 도구·표준·구현을 조사해 레퍼런스 24건을 출처와 함께 모으고 넷 중 하나로 판정했다.

판정	건수	뜻
채택	11	그대로 쓰거나 구조를 가져온다
조건부	4	조건이 맞을 때만
기각	2	안 쓴다
참고	7	결정의 근거로만

후순위와 대상 아님

선순위 넷을 구현한 뒤 후순위 9건을 다시 판정했다. 다시 볼 때 기준은 하나였다 — 1·2차 층이 실제로 돌기 시작하면서 이 위협의 성격이 바뀌었나.

바뀐 것들은 새 묶음으로 승격했다. 기기·계정 경계에 관한 것들(외부 서버 연결, 확장, 패키지 설치, 저장소 신뢰, 대화 기록 잔류)이 그렇다. 이것들은 저장소 안에서 막는 문제가 아니라 그 기기와 계정에서 막는 문제라 성격이 달랐다.

“대상 아님”으로 보낸 것은 왜 대상이 아닌지를 함께 적었다. 나중에 전제가 바뀌면 그 줄을 보고 다시 판정할 수 있어야 하기 때문이다.

지금 안 잰 것

정직하게 적는다. 아래는 아직 숫자가 없다.

• 임의의 남의 저장소에서의 설치 성공률. 지금까지는 내 저장소와 임시 저장소에서만 확인했다.
• 환경 전제가 몇 개나 잠입해 있는지. 내 기기에서만 도는 가정이 코드에 섞여 있을 수 있고, 그것을 세는 일이 아직 안 끝났다.
• 오탐률. 정상 작업을 잘못 세우는 비율을 실사용 규모로 재지 않았다.
• 외부 스캐너를 함께 돌렸을 때의 판정 차이.

이 넷을 재는 것이 다음 순서이고, 결과는 첫 화면의 실측 자리에 그대로 적는다.