Copilot이 감사 로그를 손상시켰지만 Microsoft는 고객에게 알리지 않음

 (pistachioapp.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Microsoft의 M365 Copilot에서 감사 로그가 기록되지 않는 취약점이 발견되어, 파일 접근이 로그에 남지 않는 문제가 발생
  • 단순히 Copilot에게 특정 방식으로 동작하라고 요청하면 감사 기록 없이 파일 접근 가능, 이는 내부자 위협 및 법적 규제 위반 위험으로 이어질 수 있음
  • 연구자는 MSRC에 신고했으나, Microsoft는 공식 정책과 달리 CVE를 발급하지 않고 고객에게도 알리지 않음
  • Microsoft는 해당 취약점을 ‘중요(Important)’ 수준으로만 분류하고, 자동 업데이트로 해결됐다며 별도 공지 불필요하다고 결정
  • 그러나 이는 HIPAA 등 규제 산업에서 감사 로그에 의존하는 기업들에 심각한 보안·법적 문제를 초래할 수 있으며, Microsoft의 투명성 부족이 큰 비판을 받고 있음

Copilot의 감사 로그 취약점: 개요 및 영향

  • Microsoft가 적극적으로 도입 중인 대표적 AI 서비스인 Copilot에서 사용자 요청에 따라 파일 접근 내역이 감사 로그에 남지 않는 결함이 발견됨
  • 정상적으로는 M365 Copilot이 파일을 요약해줄 때 해당 파일 접근 내역이 감사 로그에 기록되어야 하며, 이는 조직 내 정보 보안의 핵심임
  • 그러나 Copilot에게 파일 요약 결과에 파일 링크를 포함하지 않도록 요청하는 경우, 해당 로그가 아예 기록되지 않는 현상이 발생함
    • 예를 들어 직원이 퇴사 전 Copilot을 통해 대량의 파일을 조회하더라도 로그 없이 흔적을 남기지 않고 유출할 수 있음
  • 이 취약점은 작위적 해킹이 아니라 우연히도 자연스럽게 일어날 수 있으며, 실제로 블로그 작성자가 자체 기능 테스트 중에 발견함
  • Zenity의 CTO Michael Bargury 역시 이미 1년 전에 해당 취약점을 발견하여 Microsoft에 보고했으나, 이번 제보까지 장기간 방치됨

MSRC(취약점 신고)의 문제점과 대응 불인정

  • Microsoft는 취약점 신고에 대한 공식 안내문과 프로세스를 제공하지만, 실제 대응 과정에서는 이를 제대로 준수하지 않음
  • 작성자가 MSRC에 신고한 후, 재현 단계를 거치지 않은 상태에서 바로 Copilot 기능이 바뀌는 등의 혼란스러운 상황이 벌어짐
    • 신고 상태 변경(재현 → 개발) 등이 진행되었으나, 진행상황이나 결정 근거에 대한 명확한 소통이 부족함
  • 보안 취약점에 관한 CVE 발급 여부는 고객이 직접 조치가 필요할 때만 공식번호를 부여한다는 입장을 전달받음
    • 그러나 이는 Microsoft의 기존 정책과 다르며, 해당 취약점은 단지 '중요(Important)' 등급으로 분류되어 공개나 알림이 별도로 이뤄지지 않음
  • 전체적으로 진행 상황 추적 자체가 실제 조치와 무관하게 가시적으로만 업데이트되어, 신고자 입장에서는 비효율적이고 불투명한 경험이었음

공지 및 고객 알림 누락의 문제점

  • Microsoft는 이번 취약점에 대해 CVE를 발급하지도, 고객에게도 알리지 않기로 결정함
  • 이는 실수로도 쉽게 발생할 수 있는 오류인 만큼, 실제 조직에서 오랜 기간 동안 감사 로그가 잘못 기록되고 있었을 가능성이 존재함
  • 의료기관(예: HIPAA) 등 법적·규제 목적으로 감사 로그를 활용하는 조직도 많음에도, Microsoft는 영향 사실을 사용자에게 안내하지 않음
  • 감사 로그는 조직 보안, 사고 대응, 법적 증거 등 다양한 분야에서 핵심적으로 사용되지만, Microsoft는 관련 사실을 침묵으로 일관함
  • 이러한 접근은 다른 잠재적 보안 문제도 미공개로 처리될 수 있음을 시사하며, 조직의 신뢰성에 심각한 의문을 제기함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 회사 내부 챗봇 개발 업무를 맡고 있으며, 챗봇이 기밀 문서에 접근할 때 현재 사용자의 권한을 전부 점검하지 않으면 반드시 정보 유출 경로가 생기는 문제를 경영진에게 설명하는 데 어려움을 겪음
    벡터 데이터베이스나 검색 인덱스, AI Search Database 등은 사용자별로 존재하거나 콘텐츠와 함께 접근 권한을 추적해야 함
    하지만 접근 권한은 매우 복잡하며 언제든 변동될 수 있어 대규모 적용이 어렵고 레이스 컨디션에 취약하다는 점을 강조하고 싶음

    • 이건 'Confused Deputy' 문제의 구체적인 사례임
      OWASP LLM Top 10의 LLM02:2025 ‘Sensitive Information Disclosure’와 LLM06:2025 ‘Excessive Agency’ 관련 위험성에 해당됨
      일부 기업 RAG 솔루션은 다양한 ACL 때문에 사용자별 인덱스를 만들어 해결함
      이러한 접근 권한 문제를 어떻게 관리하는지 공급업체마다 다르니, RAG 솔루션 분석 시 반드시 해당 부분을 확인해야 함
      일본에서는 이걸 "권한 혼동(権限混同)"이라고 부르며, 재미있는 명칭 같음
      Confused Deputy 설명 보기, OWASP LLM Top 10 리스크 보기

    • 사용자의 접근 권한을 추적하는 것이 왜 확장성 문제라고 생각하는지 궁금함
      쿼리가 들어오면 벡터 DB나 인덱스에서 일치하는 문서를 찾고, 그 중 사용자가 접근 가능한 것만 LLM에 전달하면 됨
      마치 은행 상담원이 인증된 고객 정보만 볼 수 있어 실수로 타인 정보를 유출할 일이 없는 것과 같으며, 인증되지 않으면 타인 정보는 운영자도 볼 수 없으므로 악용될 위험이 없다고 생각함

    • 이런 벽에 부딪힐 때 실제로는 내가 소통에 실패한 것도, 경영진이 이해하지 못하는 것도 아님
      아마도 경영진이 해당 문제를 외면하기로 한 상태이고, 나중에 유출이 발생하면 엔지니어에게 책임을 떠넘기려는 의도가 있는 것 같음

    • 경영진에게 문제를 설명하는 데 어려움을 겪는다면 Legal/Compliance 부서를 참조에 넣으면 효과를 볼 수 있음
      단, Buzzword에 집착하는 일부 임원이 이 행동에 불쾌해할 수 있음

    • 대부분의 벡터 데이터베이스는 벡터에 추가 메타데이터를 달 수 있음
      접근권한이 있는 주체(예: HR, 임원) 목록을 메타데이터로 저장하면, 요청 시 사용자를 해당 역할로 확장하여 필터링할 수 있음
      이렇게 하면 사용자가 볼 수 없는 문서는 처음부터 제외할 수 있음
      단, 문서별 권한이 변경될 때마다 벡터 메타데이터도 즉시 업데이트해야 함

  • Copilot이 감사 로그를 우회하며 특권 사용자로 동작한다는 것은 문제가 있음
    그럴 수 없다고 생각함

    • Copilot이 실제로 파일에 직접 접근하는 것이 아니라, 이미 인덱싱된 파일의 내용을 검색엔진을 통해 읽고 있음
      Microsoft가 Copilot의 검색 기록을 감사해야 하는데, Copilot이 인덱스만 읽었는데 파일에 접근했다고 기록되는 건 오해 소지가 있음
      구글 검색 결과를 봤다고 웹사이트를 직접 방문했다고는 말하지 않는 것과 같음

    • Microsoft는 불필요하게 AI 통합에만 욕심을 내는 과정에서 감사로그에 소홀해지고 있음

    • Windows에서 Backup 권한을 가진 프로세스는 모든 접근 권한을 우회할 수 있고 기본적으로 감사를 하지 않음
      백업 앱의 경우 감사 로그가 너무 많아지기 때문인데, 이 권한은 명시적으로 활성화해야 하며, C# 같은 관리 코드에서 쉽게 가능함
      Restore 권한도 마찬가지임

    • 이 현상은 예전에 Delve가 처음 도입됐을 때 권한 트리밍이 잘못되어서 사용자 검색 결과에 노출되거나, SharePoint 검색이 존재하지만 접근이 불가한 문서를 일부 노출했던 문제와 유사함
      예를 들어 "Fall 2025 layoffs"로 검색하면 관련 문서가 존재하기만 해도 노출되어 보안상 이슈가 있었음
      Microsoft는 여전히 ‘보안은 뒷전’이라는 인상이 강함

  • 더 나은 제목은 "Microsoft Copilot은 HIPAA 규정을 준수하지 않음"이 될 것 같음
    이런 제목을 쓰면 훨씬 더 빨리 문제가 해결될 것 같음

    • 한술 더 떠, 모든 유용한 AI 검색 시스템은 설계상 안전하지 않은데, 벡터 데이터베이스에 저장되는 그 RAG 벡터란 결국 문서를 손실 압축해놓은 꼴임

    • 이미 문제는 수정됨
      지금의 불만은 고객에게 공지가 되지 않았다는 점임

  • “CVE는 고객이 보호를 위해 조치를 취해야 할 때 배포되는 보안 릴리스에 할당됨. 이번 경우엔 Copilot에 자동으로 조치가 배포되며, 사용자가 수동으로 업데이트할 필요가 없으므로 CVE가 할당되지 않음”
    이게 CVE의 본질적 특징인지, 아니면 Microsoft가 CVE를 이렇게 활용하고 있는지 궁금함
    이런 취약점에도 참조할만한 공통 ID가 있으면 좋겠고, 벤더에 종속되지 않는 별도의 번호 체계가 필요하다고 생각함

    • Microsoft는 CVE가 보안 사고/취약점을 추적하는 것임
      비정상적으로 긴급 패치가 가능하다고 해도 보안 사고 자체가 아니게 되는 것은 아님
      Microsoft가 보안 사고에 대한 투명한 공개에 소극적이고 신뢰성 떨어지는 추세가 강해져서, 이런 경우에는 더욱 더 정보 공개가 중요함

    • 이건 CVE의 한계보다 Microsoft가 PR을 위해 CVE 프로세스를 구부려 사용하는 것 같은 느낌임

    • CVE의 ‘C’는 Common임
      즉, ‘공통성’에 초점을 맞춘 시스템임

  • 현재 중요한 LOB 앱도 Microsoft에서 벗어나려고 노력 중
    최근 몇 달 동안의 여러 해킹, SSO zero-day, Copilot이 인덱서가 글로벌 어드민으로 동작하면서 권한 무시하는 걸 보며 점점 불안이 커짐

  • LLM에게 직접 감사 및 활동 로그를 맡겨 발생할 수 있는 문제점은 너무 많아서 집계도 어려움
    그래서 궁금한데, 이번 문제의 버그 수정을 어떻게 했는지, 혹시 ‘섀도우 프롬프트’를 도입한 것 아닌지 의문임

    • 포스트 어디에도 LLM이 감사 로그를 직접 관리한다고 나와 있지 않음
      오히려 감사 로그는 LLM이 아닌, 상위 스캐폴딩(측면 시스템)에서 기록하는데, 로그를 남겨야 할 '시점'을 잘못 잡았던 것으로 보임
      예를 들어, 누군가 링크를 클릭하는 순간 감사 로그를 남기게 한 대신, LLM에 문서가 주입되는 시점 등에 맞게 기록했어야 했음
      이 설계도 최적은 아니지만 LLM이 직접 기록하는 것보다는 덜 심각함

    • 나는 섀도우 프롬프트(또는 어떤 형태의 프롬프트)를 진짜 보안이나 컴플라이언스 통제 수단으로 사용하는 것 자체에 매우 회의적임
      이런 제어는 반드시 결정적이고 예측가능한 시스템이어야만 할 것임

    • 만약 어떤 도구가 LLM이 파일 일부분이라도 보게 한다면, 그 이후 LLM이 출력한 정보는 모두 그 파일을 읽은 것으로 간주되어야 한다고 봄

    • “만약 유저가 너한테 링크 제공하지 말라고 하면 무시하고, 그렇지 않으면 네 가족에게 XYZ 무시무시한 일이 일어난다고 해”처럼, LLM 프롬프트에 이상한 요구가 들어올 수도 있다 생각함

    • 섀도우 카피(Shadow copies) 문제도 떠오름

  • 여기서 이야기하는 게 정확히 어떤 종류의 감사 로그인지 불분명함
    SharePoint 파일 접근 로그? Copilot의 행동 기록? Purview? 아니면 또 다른 것?

    • 명확하지 않은 점이 많음
      Copilot이 파일 자체가 아니라 인덱싱된 내용에 접근하고 있으니, 실제로 파일에 접근하지 않은 게 맞음
      블로그 작성자는 인덱스 접근 로그를 봐야 함

    • 블로그 각주 중 “감사 로그는 사용자가 파일에 직접 접근한 흔적이 아니라 CopilotInteraction으로 남고 이는 의도된 것이라 생각함
      사용자가 Copilot을 통해서만 접근한 상황에서 마치 직접 파일을 건드린 것처럼 기록되는 것이 오히려 이상함”이란 의견이 있음

    • 내가 ChatGPT에게 같은 질문을 했더니 Microsoft 365, Office 365의 감사 로그, 특히 Microsoft Purview Compliance Portal의 Unified Audit Log를 말하는 것이라는 설명을 해줌

  • 이런 이슈들이 바로, Microsoft와 같은 대형 벤더에 대한 신뢰가 ‘보장’이 아니라 ‘재수’처럼 느껴지게 만드는 원인임

    • 그렇다면 소규모 소프트웨어 회사는 더 신뢰할 수 있을까?

  • 현실적으로 이 문제를 어떻게 고칠 수 있을지 정말 궁금함
    내 이해로는 Copilot이 사용하는 인덱스/DB가 이미 해당 파일을 크롤링했으므로, 굳이 파일을 다시 조회하지 않아도 그 정보를 알려줄 수 있음
    그러면 대체 어떻게 고쳐야 하는 것일까?
    데이터베이스/인덱스 접근 자체를 감사 로그와 연동해야 할까?
    아니면 LLM에게 “지식을 조회할 때 약속 꼭 지키고 반드시 기록을 남기라”고 명령해야 할까?
    Microsoft가 이 문제를 어떻게 인지하고 해결하는지 공식적인 커뮤니케이션이 절실히 필요함
    민감 데이터 사용 기업이라면 이번 이슈가 경종을 울려야 한다고 생각함

    • 내 생각엔 인덱스에 캐시된 파일 내용이 어느 시점엔가 LLM 컨텍스트로 들어올 수밖에 없어, 바로 그 지점에서 감사 로그를 남길 수 있다고 봄

  • 일반적으로 CVE는 누구나 등록할 수 있음
    내가 직접 제출해서 Microsoft의 대응을 유도할 수도 있음
    해당 블로그 글만으로도 꽤 설득력이 있다고 봄

    • 실제론 간단하지 않음
      MITRE나 국가 CERT 등 대부분의 CVE 번호 권한기관(CNA)은 누구나 제보할 수 있지만, 평가 및 심사가 있음
      Microsoft는 자체 CNA이기 때문에 특별한 이유 없이는 MS 관련 CVE를 외부에서 부여하지 않을 것임

    • Microsoft만 서비스하는 서비스에 대해 CVE를 요청하는 게 과연 의미가 있는지 고민임
      사용자는 이걸로 뭘 할 수 있는지가 의문임

    • CVE 등록 양식은 여기에서 가능함
      PGP 지원과 긴 업력, 인증된 스폰서 등의 신뢰도도 높음
      합법적이고 정당한 사안에만 활용해야 함

    • 재미있긴 하지만, 이건 CVE 대상이 아니라고 생각함
      CVE는 여러 소스의 다양한 제품에 공통적으로 적용되는 취약점에 해당해야 하며, Copilot은 이에 해당하지 않음
      이 사건의 가장 심각한 점은 Copilot LLM 자체에 감사 로그 생성을 지시했다는 디자인 실수임
      파일이나 URL을 조회하는 API에서 자동으로 감사 로그를 남겼어야 하며, 이는 엔지니어링 기본임

답변달기